Group multicast fanOut Procedure 改一改Source和date Group Name: ARC Source: Bei(Echo) Xu, Huawei Technologies Co., Ltd. Echo.xubei@huawei.com Meeting Date: 2017-02-25 Agenda Item: TBD
Background This contribution introduce the multicast group management procedure if oneM2M support group multicast. To understand the solution better, there is one example for IP multicast group of protocol binding which is out of this scope. After the solution is approved, we will provide detail protocol binding of TS.
Resource structure <remoteCSE> Member Hosting CSE registration information are used to support group Hosting CSE to create the multicast group. <remoteCSE> It is a list of underlying network external globally unique IDs which is mapping with a network internal globally unique ID including a set of underlying network identifiers from a given network that are grouped together for one specific group related services. externalGroupID multicastCapability Indicates the oneM2M node multicast Capability, pre-defined values are: MBMS IP 可能需要考虑一下,目前的资源架构,对于MBMS和IP多播是可以支持的,但是如果后续有新的多播技术,这个架构是否还能够适用。我们可能需要一个回答。 multicastCapability应该是圆角框,具体的multicastCapability是什么样的?一个CSE是否有可能同时支持MBMS和IP多播?一个List?
<localMulticastGroup> Resource structure <CSEbase> Member Hosting CSE: the <localMulticastGroup> resource of member device is to indicate that if the CSE is part of a multicast group. When the multicastType is 3GPP_MBMS_group, the externalGroupID is a 3GPP network external globally unique ID which is mapping with a network internal globally unique ID which identifies a set of IMSIs (e.g. MTC devices) from a given network that are grouped together for one specific group related services. <localMulticastGroup> externalGroupID multicastAddress List of member resource IDs referred to in the multicast group of local device. memberList It is virtual identifier and is used to indicate an access path of the member resource on a member device. When receiving the message, the group member host CSE checks whether the multicastGroupFanOutURI is aveable, if not, replace the fanout URI included in the destination URI in the member resource access request with the member list of access path of the member resource on the member device fanOutURI 可能需要考虑一下,目前的资源架构,对于MBMS和IP多播是可以支持的,但是如果后续有新的多播技术,这个架构是否还能够适用。我们可能需要一个回答。 multicastCapability应该是圆角框,具体的multicastCapability是什么样的?一个CSE是否有可能同时支持MBMS和IP多播?一个List? responseURI This attribute shall be configured as one targets that the member Hosting CSE shall send notifications to after finishing the operation in the group multicast request message.
multicast group information In case the multicast mechanism is used to fan-out group operations to members, the group hosting CSE shall maintain the necessary information pertaining to the multicast group(s) that belong to the addressed group, such as the mapping relationship between the member resources and the multicast address(es) and the target URI(s) in the fanout requests. For each multicast group of a <group> resource, the group hosting CSE shall maintain the information as specified as below: Information Multiplicity Description multicastType 1 Indicating the underlying networks multicast capability of the group members, the value shall be one of the following: 3GPP_MBMS_group, IP_mulicast_group. externalGroupID 0..1 When the multicastType is 3GPP_MBMS_group, the externalGroupID is the External-Group-ID as specified in 3GPP TS23.682[i.14] clause 4.6.3 multicastAddress The multicast address allocated to the members in the memberlist. If the multicastType is 3GPP_MBMS_group, the multicastAddress shall be the address of 3GPP group service server (e.g. SCEF); if the multicastType is IP_mulicast_group, the multicastAddress shall be the multicast address shared by the members of this multicast group. addressType It is used to describe the address type of the multicastAddress, e.g. IPv4 or IPv6. fanOutURI Used as the target URI of the fanout request sending to the members. It is a virtual identifier allocated by the group hosting CSE corresponding to the access paths (i.e. Resource-IDs, which may be different) of the member resources on the member hosting CSEs. memberList 1(L) List of all member resource IDs in the multicast group, referred to in the remaining of the present document as memberID. Each ID (memberID) should refer to a member resource.
Request/Response Model for Multicast Fanout The message mechanism between Group hosting CSE and Member hosting CSE is the same with Asynchronous Case no matter what the Response Type between IN-AE and Group hosting CSE is. The Request Identifier in the notification message from member hosting CSE should be the same with the Request Identifier in the multicast request message to be used to match notification to multicast requests. The From parameter should be mandatory in the notification message from member hosting CSE to be used to detect duplicates by the Group hosting CSE. The value of From is Member hosting CSE-ID. 字体调整大一点,Restriction里面的语句描述可以改一改,现在的感觉比较绕。 第6步,如果是配置群组的过程,不需要对成员的响应进行汇聚,因为应用对这个不感兴趣。如果第5步都是成功,第6步成功就行了。如果第5步有一个失败,可能失败的那个要回到单播里去。这部分流程目前还没有体现。
IP Multicast Group – Fan Out procedure example Step001: IN-AE/CSE send the retrieve request to Group hosting CSE to get the temperature information. Step002: Group hosting CSE sends the multicast message to multicast address and sets the value of to parameter as fanoutURI, which is virtual identifier and could be accessed as a virtual resource. Step003: Member hosting CSE receive the multicast message from multicast address, compare the value of to parameter with fanOutURI of <localMulticast> from the request message, determine the access the local member resource by mapping the member list and fanOutURI and execute the retrieve operation. Step004: Finishing the operation in the request, Member hosting CSE composes the notification for Group hosting CSE about the result: set the From parameter value as the Member hosting CSE-ID, set the Request Identifier as the same with the request ID in the request message and set the to parameter value as the response URI which is used as the notification URI Step005: Member hosting CSE sends the notification request to Group hosting CSE. Step006: Group hosting CSE aggregates the result according to the From and Request Identifier in notification messages Step007: Group hosting CSE sends the response message to IN-AE/CSE. 字体调整大一点,Restriction里面的语句描述可以改一改,现在的感觉比较绕。 第6步,如果是配置群组的过程,不需要对成员的响应进行汇聚,因为应用对这个不感兴趣。如果第5步都是成功,第6步成功就行了。如果第5步有一个失败,可能失败的那个要回到单播里去。这部分流程目前还没有体现。
Multicast Group Management Procedures-Creation Restriction The current group based multicast can only be used when member hosting CSE and Group Hosting CSE have direct registration relationship. The current group based multicast can only be applied between CSEs, multicast to ADN is FFS 字体调整大一点,Restriction里面的语句描述可以改一改,现在的感觉比较绕。 第6步,如果是配置群组的过程,不需要对成员的响应进行汇聚,因为应用对这个不感兴趣。如果第5步都是成功,第6步成功就行了。如果第5步有一个失败,可能失败的那个要回到单播里去。这部分流程目前还没有体现。
Multicast Group Management Procedures-Fanout Restriction The detailed 3GPP MBMS group message delivery procedure is another thread and will be introduced in 3GPP interworking specification.
Questions and comments