ONEM2M_TECHQUESTIONS Archives

October 2015

oneM2M_TechQuestions@LIST.ONEM2M.ORG

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
oneM2M Technical Questions <[log in to unmask]>
Date:
Tue, 13 Oct 2015 20:13:09 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (40 lines)
Thanks George.


I've checked the latest draft of above 2 docs:

[1] TS-0001 Functional Architecture-V2.2.0 
[2] TS-0004-Service_Layer_Core_Protocol-V2_1_0

Basically the tables and description in regard of resource announcement have not changed since v1.x, at least not in obvious way I could tell. And the original matter in this thread still puzzles me.

After looking into the issue more closely, I convince myself two things:
1. Announced resource is a "shadow" of original resource (in Amazon IoT term). How to "shadow" is controlled by at and aa attributes of original resource.
2. Announced resource/attributes are interests of retriever of these resources, i.e., RETRIEVE/NOTIFY operation on announced resources.



    --------                     ---------------                          ---------------  announced   ---------- 
    | AE   |-------------->| Hosting-CSE |--------------->| Remote-CSE |------------>| AE/CSE |
    --------                     ---------------                          --------------     resource     ----------
                        Mca                                    Mcc                        
                                                                           

There is no need to limit the announced resourced when Hosting-CSE creates announcement resource on Remote-CSE, on behalf of originator AE. But the announced resources/attributes should be filtered out when AE/CSE retrieve announced resource from Remote-CSE, based on what attributes/resources originator AE wants to publish, specified in aa attribute.

As such, when Hosting-CSE creates announced resource on Remote-CSE, it's very similar to what AE sends CREATE request to Hosting-CSE, with at and aa attributes, except Hosting-CSE creates AEAnnc resource type, instead of AE resource. Remote-CSE would follow the create request and store the announced resource, with local ri, rn, aei, and node link to original resource on Hosting-CSE.

When other AE/CSE retrieve announced resource, Remote-CSE would filter out the attributes/resource based on aa attributes, and the MA/OA attributes in [1]. Basically all MA attributes would be published, regardless they are in aa or not; OA attributes would be sent in response if they are in aa attribute.

This would resolve the ri, rn reuse/conflict issue during resource announcement procedure in current standard.

Comments welcomed.

Regards,
Ray Xu

########################################################################

To unsubscribe from the oneM2M_TechQuestions list, click the following link:
https://list.etsi.org/scripts/wa.exe?SUBED1=oneM2M_TechQuestions&A=1

ATOM RSS1 RSS2