WO2013102346A1 - 成员资源的访问方法、群组服务器和成员设备 - Google Patents

成员资源的访问方法、群组服务器和成员设备 Download PDF

Info

Publication number
WO2013102346A1
WO2013102346A1 PCT/CN2012/078531 CN2012078531W WO2013102346A1 WO 2013102346 A1 WO2013102346 A1 WO 2013102346A1 CN 2012078531 W CN2012078531 W CN 2012078531W WO 2013102346 A1 WO2013102346 A1 WO 2013102346A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
group
multicast
uri
multicast address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2012/078531
Other languages
English (en)
French (fr)
Inventor
张永靖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to RU2014131902/08A priority Critical patent/RU2598582C2/ru
Priority to JP2014550612A priority patent/JP5891551B2/ja
Priority to CA2859059A priority patent/CA2859059C/en
Priority to EP12864225.3A priority patent/EP2782367B1/en
Priority to EP17201988.7A priority patent/EP3367709A1/en
Priority to KR1020147017218A priority patent/KR101571376B1/ko
Priority to IN4375CHN2014 priority patent/IN2014CN04375A/en
Publication of WO2013102346A1 publication Critical patent/WO2013102346A1/zh
Priority to US14/305,745 priority patent/US9450772B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present invention relates to the field of Machine-to-Machine Communications (M2M) technology, and in particular, to a method for accessing member resources, a group server, and a member device.
  • M2M Machine-to-Machine Communications
  • Machine-to-Machine Communications is a networked application and service centered on machine intelligent interaction.
  • M2M technology enables data communication without manual intervention by embedding wireless or wired communication modules and application processing logic inside the machine to meet the information needs of users for monitoring, command scheduling, data acquisition and measurement.
  • various M2M terminals such as sensors, microcontrollers, etc.
  • M2M application servers such as power meter reading, intelligent transportation, etc.
  • a resource-oriented group communication method is described in the prior art.
  • all local applications and data objects running on the M2M application server, the M2M platform, the M2M terminal, the M2M gateway, and the M2M terminal and the M2M gateway are regarded as a RESTfuK Representational.
  • State Transfer a stateful resource transfer, and uniquely identified by a URI (Universal Resource Identifier).
  • URI Universal Resource Identifier
  • the group resource includes related information of each member resource, such as an access path of the member resource, a name of the device to which the device belongs, an access address, and the like, and the grouping of the plurality of member resources is realized.
  • the M2M application server may be an entity that maintains the group resources (hereinafter referred to as a group server, which may be an M2M platform, an M2M gateway, or an M2M terminal).
  • the specific communication protocol used by the method may be an HTTP (HyperText Transfer Protocol) protocol or a Cooperative (Constrained Application Protocol) protocol.
  • the existing method of group communication applied to M2M only saves communication between the M2M application server and the group server, and the group server still needs to separately send a request to each M2M device. If the group server has limited capacity (such as an M2M gateway), or if the network bandwidth between the group and the M2M device is small or the communication cost is high, communication between the group server and the M2M device in the method is not economical.
  • the method for accessing member resources, the group server, and the member device provided by the embodiment of the present invention can implement a unicast access request for each member device, thereby saving network overhead.
  • An aspect of the present invention provides a method for accessing member resources, including:
  • the fan-out URI is used to indicate an access path of the member resource on the member device, and send a member resource access request to the member device to which the member resource belongs according to the multicast address, where the member resource access request is
  • the destination URI includes a fan-out URI corresponding to the member resource, so that the member device to which the member resource belongs performs the operation indicated by the member resource access request according to the access path of the member resource indicated by the fan-out URI on the member device.
  • the method further includes: receiving a group resource creation request, where the group resource creation request includes each member resource, where the member resource includes a member device to which the member resource belongs and member resources are on the member device.
  • the access path is configured to allocate a multicast address to the member resource according to the member device to which the member resource belongs and the access path of the member resource on the member device; and establish the multicast address and the location according to the access path of the member resource on the member device.
  • the member device is configured to allocate a multicast address to the member resource according to the member device and the access path of the member resource on the member device, and the multicast address is established according to the access path of the member resource on the member device.
  • the mapping relationship between the fan-out URIs is specifically: assigning a multicast address to a member resource having the same access path on the member device, and establishing a mapping relationship between the multicast address and the fan-out URI; a fanout URI is an access path of the member resource on the member device; and/or a virtual identifier is allocated to at least one member resource having different access paths on the member device, and a multicast address is allocated to the at least one member resource, and And establishing a mapping relationship between the multicast address and the virtual identifier and a mapping relationship between the virtual identifier and the member resource; and setting the virtual identifier as the fanout URI.
  • the method further includes: sending a group advertisement to join the multicast group to the member device to which the member resource belongs according to the mapping relationship between the multicast address and the fan-out URI, where the group joining the multicast group
  • the advertisement carries the multicast address, so that the member device to which the member resource belongs is added to the multicast group corresponding to the multicast address according to the group advertisement that joins the multicast group.
  • the group advertisement that is added to the multicast group further carries the mapping relationship between the fanout URI and the member resource, so that the member device to which the member resource belongs stores the fanout URI and the a multicast address mapping relationship, and a mapping relationship between the member resource and the multicast address; the access path of the member resource that the member resource belongs to the member device according to the fanout URI
  • the operation of the member resource access request indication is specifically: after the member device to which the member resource belongs receives the access request carrying the fan-out URI, according to the received fan-out URI and according to the fan-out
  • the URI and the member resource mapping relationship determine the access path of the member resource on the member device, and execute the corresponding member resource access request according to the determined access path of the member resource on the member device.
  • the allocating the multicast address to the member resource according to the member device to which the member resource belongs and the access path of the member resource on the member device is: determining, according to the member device to which the member resource belongs, the member resource The member device belongs to the first group server, and allocates a multicast address of the local multicast domain to the member device to which the member resource belongs; or determines a member to which the member resource of the group resource belongs according to the member device to which the member resource belongs The device does not belong to the first group server, allocates the multicast address of the global multicast domain to the member device to which the member resource belongs, or requests to allocate the remote multicast to the member device to which the member resource not belonging to the first group server belongs.
  • the multicast address of the domain is: determining, according to the member device to which the member resource belongs, the member resource The member device belongs to the first group server, and allocates a multicast address of the local multicast domain to the member device to which the member resource belongs; or determines a member to which the member resource of the group
  • the allocating the multicast address of the global multicast domain to the member device to which the member resource belongs is: requesting, by the group server having the multicast address of the global multicast domain, the multicast address of the global multicast domain, The member device to which the member resource belongs is assigned a multicast address of the global multicast domain of the application; the multicast address of the remote multicast domain to which the member device belongs to the member resource that is not attributed to the first group server is specifically: The member device to which the member resource not belonging to the first group server belongs belongs to the second group server, and sends a second group resource request to the second group server, where the second group resource request carries the first a group resource identifier and a member resource, where the member resource includes a member device to which the member resource belongs and an access path of the member resource on the member device; the second group server creates the second group resource according to the member device to which the member resource belongs And assign a multicast address to member resources.
  • the member device and the member resource according to the member resource are on the member device.
  • the accessing the multicast resource for the member resource is specifically: determining, according to the member device to which the member resource belongs, the member device to which the member resource belongs and the network to which the member device belongs, and for the member resource allocation
  • the method further includes: storing a member resource corresponding to the member device that does not have the multicast capability, so that the group server unicasts the access request for the member resource for the member device that does not have the multicast capability.
  • the method further includes: setting a destination address of the access request for the member resource to a multicast address corresponding to the fanout URI, and using the member resource
  • the destination URI of the access request is set to the fan-out URI corresponding to the member resource to generate a member resource access request; and the member resource access request carrying the fan-out URI corresponding to the member resource is sent by using the multicast address.
  • the method further includes: determining that the destination URI in the access request to the member resource further includes a suffix; setting a destination address of the access request for the member resource For the multicast address corresponding to the fanout UIR, the destination URI is set to the fanout URI corresponding to the member resource, and the suffix included in the destination URI is added after the fanout URI to generate a member. Resource access request.
  • the method further includes: receiving a group resource update request for adding a member resource, where the group resource update request for adding the member resource carries the identifier of the group resource and the member resource that needs to join the group resource,
  • the member resources to be added to the group resource include the member device to which the member resource belongs and the access path of the member resource on the member device; and the access path of the member resource to be added to the group resource on the member device according to the identifier of the group resource
  • the fan-out URI in the mapping relationship between the multicast address and the fan-out URI in the group resource corresponding to the identifier of the group resource is the same, and the member device to which the member resource to be added to the group resource belongs is sent to carry the Adding a group advertisement of a multicast group to a multicast address in a mapping relationship between a multicast address and a fan-out URI, so that a member device to which a member resource that needs to join the group resource belongs is added to the multicast through the multicast address.
  • the fan-out URI in the mapping relationship between the multicast address and the fan-out URI is different; adding the group to be added to the mapping relationship between the fan-out URI and the member resource in the group resource corresponding to the identifier of the group resource
  • a member resource of the resource is sent to the member device to which the member resource to be added to the group resource belongs to send the group advertisement to join the multicast group, and the group advertisement that joins the multicast group carries the group resource corresponding to the identifier of the group resource.
  • the access path of the member resource on the member device is determined according to the mapping relationship between the received fan-out URI and the member resource, and the determined member is determined according to the member. Access path on a member device to perform the appropriate member resource access request.
  • the method further includes: receiving a group resource update request for deleting a member resource, where the group resource update request of the deleted member resource carries an identifier of a member resource and a group resource that need to leave the group resource, where The member resources that need to leave the group resource include the member device to which the member resource belongs and the access path of the member resource on the member device; determine a fan-out URI corresponding to the member resource that needs to leave the group resource according to the identifier of the group resource, And mapping the fan-out URI and the multicast address corresponding to the member resource that needs to leave the group resource, and deleting the mapping relationship between the fan-out URI and the multicast address corresponding to the member resource that needs to leave the group resource Leave the member resource of the group resource, and send the leaving multicast group of the multicast address in the mapping relationship between the fanout URI and the multicast address corresponding to the member resource that needs to leave the group resource to the member device to which the member resource to be removed belongs.
  • the group resource update request of the resource carries the identifier of the member resource and the group resource of the group resource to be reserved, and the member resource of the group resource to be reserved includes the member device to which the member resource belongs and the member resource is on the member device.
  • Access path determine the member resources and fan-out UIRs that need to leave the group resource according to the identity of the group resource
  • the member relationship between the member resource that needs to leave the group resource and the member resource of the fanout UIR is updated by using the member resource of the group resource to be reserved, and the member relationship device to which the member resource to be removed belongs is sent in the mapping relationship.
  • the group advertisement of the multicast address leaving the multicast group so that the member device to which the member resource to be removed belongs belongs to the multicast group indicated by the multicast address.
  • the method further includes: determining, according to the identifier of the group resource that the group resource update request of the member resource is deleted, the access path of the member resource that needs to leave the group resource on the member device and the member resource that needs to leave The fanout URI is different; the group advertisement leaving the multicast group further includes the fanout URI corresponding to the member resource that needs to leave the group resource; so that the member device to which the member resource that needs to leave the group resource belongs Decoding the multicast group indicated by the multicast address, and deleting the group resource update request from the member device and deleting the member resource according to the fan-out URI in the member resource that needs to leave the group resource and the group advertisement leaving the multicast group The member resource of the multicast group information corresponding to the identifier of the group resource.
  • another aspect of the present invention provides a method for accessing a group resource, including: receiving a member resource access request sent by a group server, where the member resource access request is a multicast member resource access request, and the member
  • the resource access request includes a fan-out URI corresponding to the member resource, where the fan-out URI is used to indicate an access path of the member resource on the member device, and the access path of the member resource on the member device is determined according to the fan-out URI. And performing an operation of the access request according to the access path of the member resource on the member device.
  • the method further includes: receiving a group advertisement that is added to the multicast group, where the group advertisement that joins the multicast group carries a multicast address, and joins the multicast according to the group advertisement that joins the multicast group.
  • the multicast group corresponding to the address.
  • the group advertisement that is added to the multicast group further carries a mapping relationship between the fanout URI and the member resource; the method further includes: storing a mapping relationship between the multicast address and the fanout URI And a mapping relationship between the member resource and the multicast address.
  • the method further includes: determining that the destination address of the member resource access request is a multicast address.
  • the determining, by the fanout URI, the access path of the member resource on the member device is specifically:
  • the fan-out URI with the same destination URI in the request determines the access path of the member resource corresponding to the fan-out URI on the member device in the multicast group information.
  • the performing the access request according to the access path of the member resource on the member device is specifically:: using a fanout URI included in the destination URI in the member resource access request with the determined member resource in the member device The access path is replaced, and the operation of the access request is performed for the member resource corresponding to the determined access path of the member resource on the member device.
  • the method further includes: receiving a group advertisement leaving the multicast group, where the group advertisement leaving the multicast group carries a multicast address; deleting a plurality of group advertisements of the stored and leaving multicast groups Multicast group information corresponding to the multicast address with the same address is broadcasted, and the multicast group corresponding to the multicast address in the group advertisement leaving the multicast group is exited.
  • the method further includes: receiving a group advertisement that leaves the multicast group, where the group advertisement leaving the multicast group carries a multicast address corresponding to the multicast group to leave and a member that needs to leave the group resource
  • the member resource that needs to leave includes the member device to which the member resource that needs to leave the group resource belongs and the access path of the member resource on the member device; deleting the stored group notification with the leaving multicast group
  • the multicast group information of the multicast address with the same address needs to leave the member resource of the group resource; delete the stored multicast group with the same multicast address as the multicast address in the group advertisement of the leaving multicast group Information, and exiting the multicast group corresponding to the multicast address in the group announcement leaving the multicast group.
  • the method further comprises: determining that the fanout URI in the multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group does not correspond to the member resource.
  • the present invention further provides a group server, including: a receiving module, configured to receive an access request for a member resource, where the access request for the member resource carries a member a group resource identifier of the group resource to which the source belongs; an obtaining module, configured to acquire, according to the group resource identifier, a fan-out URI corresponding to the member resource in the group resource, and a multicast address corresponding to the fan-out URI,
  • the fanout URI is used to indicate an access path of the member resource on the member device, and the sending module is configured to send, according to the multicast address, a member resource access request to the member device to which the member resource belongs, the member resource access request
  • the destination URI includes a fanout URI corresponding to the member resource, so that the member device to which the member resource belongs performs the member resource access request indication according to the access path of the member resource indicated by the fanout URI on the member device. operating.
  • the receiving module is further configured to receive a group resource creation request, where the group resource creation request includes a member resource, where the member resource includes a member device to which the member resource belongs and a member resource is a member device.
  • the access server; the group server further includes: a processing module, configured to allocate a multicast address to the member resource according to the member device to which the member resource belongs and an access path of the member resource on the member device; The access path of the resource on the member device establishes a mapping relationship between the multicast address and the fan-out URI.
  • the processing module is specifically configured to: allocate a multicast address for a member resource having the same access path on the member device, and establish a mapping relationship between the multicast address and the fan-out URI;
  • the URI is an access path of the member resource on the member device; and/or is configured to allocate a virtual identifier for at least one member resource having different access paths on the member device, and allocate a multicast address for the at least one member resource, And establishing a mapping relationship between the multicast address and the virtual identifier and a mapping relationship between the virtual identifier and the member resource; setting the virtual identifier as the fan-out URI.
  • the sending module is further configured to: send, according to the mapping relationship between the multicast address and the fan-out URI, a group advertisement that joins a multicast group to a member device to which the member resource belongs, where the joining the multicast group
  • the group advertisement carries the multicast address, so that the member device to which the member resource belongs is added to the multicast group corresponding to the multicast address according to the group advertisement that joins the multicast group.
  • the processing module allocates a multicast address to the member resource according to the member device to which the member resource belongs and the access path of the member resource on the member device, according to the member:
  • the member device to which the resource belongs determines that the member device to which the member resource belongs belongs to the first group server, and allocates a multicast address of the local multicast domain to the member device to which the member resource belongs; or determines according to the member device to which the member resource belongs.
  • the member devices to which the member resources of the group resource belong are not all attributed to the first group server, and the multicast device of the global multicast domain is assigned to the member device to which the member resource belongs or the request is not attributed to the first group server.
  • the member device to which the member resource belongs is assigned the multicast address of the remote multicast domain.
  • the processing module allocates a multicast address of the global multicast domain to the member device to which the member resource belongs, and specifically: requesting, by the group server having the multicast address of the global multicast domain, the multicast address of the global multicast domain. And allocating a multicast address of the requested global multicast domain to the member device to which the member resource belongs; the multicast address of the remote multicast domain allocated by the member device to which the member resource not belonging to the first group server belongs is Determining that the member device to which the member resource not belonging to the first group server belongs belongs to the second group server, and sending a second group resource request to the second group server, where the request for creating the second group resource is carried
  • the first group resource identifier and the member resource, the member resource includes the member device to which the member resource belongs and the access path of the member resource on the member device; the second group server is based on the member device to which the member resource belongs and the member resource is in the member device
  • the access path on the second creates a second group resource and assigns a multi
  • the processing module allocates a multicast address to the member resource according to the member device to which the member resource belongs, as follows: determining, according to the member device to which the member resource belongs, the network device to which the member device and the member device to which the member resource belongs Multicasting, and allocating a multicast address to the member resource; the processing module is further configured to: store a member resource corresponding to the member device that does not have the multicast capability, so that the group server is a member device that does not have the multicast capability Unicast access requests to member resources.
  • the processing module is further configured to: set a destination address of the access request for the member resource to a multicast address corresponding to the fanout URI, and set a destination URI of the access request for the member resource to the a fanout URI corresponding to the member resource to generate a member resource access request, and also used And transmitting, by using the multicast address, a member resource access request that carries the fanout URI corresponding to the member resource.
  • the processing module is further configured to: determine that the destination URI in the access request for the member resource further includes a suffix; and set a destination address of the access request for the member resource to a multicast address corresponding to the fanout UIR
  • the destination URI of the access request for the member resource is set to the fan-out URI corresponding to the member resource, and the suffix included in the destination URI is added after the fan-out URI to generate a member resource access request.
  • the receiving module is further configured to receive a group resource update request for adding a member resource, where the group resource update request for adding the member resource carries the identifier of the group resource and the member resource that needs to join the group resource, where the The member resources of the group resource include the member device to which the member resource belongs and the access path of the member resource on the member device;
  • the processing module is further configured to determine, according to the identifier of the group resource, an access path of the member resource that needs to join the group resource on the member device, and the multicast address and the fan in the group resource corresponding to the identifier of the group resource.
  • the fan-out URI in the mapping relationship of the URI is the same, and the member device to which the member resource to be added to the group resource belongs is sent to the multicast group that carries the multicast address in the mapping relationship between the multicast address and the fan-out URI.
  • a group advertisement so that a member device to which a member resource that needs to join the group resource belongs to join the multicast group through the multicast address, and receive a member resource access request sent through the multicast address; or
  • the processing module is further configured to determine, according to the identifier of the group resource, an access path of the member resource that needs to join the group resource on the member device, and the multicast address and the fan in the group resource corresponding to the identifier of the group resource.
  • the fan-out URIs in the mapping relationship of the URIs are different.
  • the member resources that need to be added to the group resources are added to the mapping relationship between the fan-out URI and the member resources in the group resource corresponding to the identifier of the group resource.
  • the member device to which the member resource of the group resource belongs sends a group advertisement that joins the multicast group, and the group advertisement that joins the multicast group carries the multicast address and the fan in the group resource corresponding to the identifier of the group resource.
  • URI mapping, and fanout URI and membership The mapping relationship of the access path of the source device on the member device; after the member device receives the access request carrying the fan-out URI, determining the member resource in the member device according to the mapping relationship between the received fan-out URI and the member resource
  • the access path is executed, and the corresponding member resource access request is executed according to the determined access path of the member resource on the member device.
  • the receiving module is further configured to receive a group resource update request for deleting the member resource, where the group resource update request for deleting the member resource carries the identifier of the member resource and the group resource that need to leave the group resource,
  • the member resource that needs to leave the group resource includes the member device to which the member resource belongs and the access path of the member resource on the member device;
  • the processing module is further configured to: determine, according to the identifier of the group resource, the group to leave the group The fan-out URI corresponding to the member resource of the resource, and the mapping relationship between the fan-out URI and the multicast address corresponding to the member resource that needs to leave the group resource, and deleting the member resources in the mapping relationship that need to leave the group resource,
  • the member device to which the member resource is to be sent sends a group advertisement of the leaving multicast group carrying the multicast address in the mapping relationship between the fan-out URI and the multicast address corresponding to the member resource that needs to leave the group resource, so as to be required to leave.
  • the receiving module is further configured to receive a group resource update request for deleting the member resource, where the group resource update request of the deleted member resource carries the identifier of the member resource and the group resource of the group resource to be reserved, and the The member resource of the reserved group resource includes the member device to which the member resource belongs and the access path of the member resource on the member device.
  • the processing module is further configured to determine, according to the identifier of the group resource, the member resource and the fan that need to leave the group resource.
  • the member relationship between the member resource that needs to leave the group resource and the fan-out UIR is updated by using the member resource of the group resource to be reserved; and the member device to which the member resource to be removed belongs is sent
  • the processing module is further configured to: determine, according to the identifier of the group resource that the group resource update request of the member resource is deleted, the access path of the member resource that needs to leave the group resource on the member device and the member resource that needs to leave The corresponding fanout URI is different; the group announcement leaving the multicast group is still Include the fan-out URI corresponding to the member resource that needs to leave the group resource; the member device to which the member resource that needs to leave the group resource belongs to the multicast group indicated by the multicast address, and leave according to the need
  • the member resource of the group resource and the fan-out URI in the group advertisement leaving the multicast group delete the member resource in the multicast group information corresponding to the identifier of the group resource of the group resource update request for deleting the member resource .
  • a further aspect of the present invention provides a member device, including: a receiving module, configured to receive a member resource access request sent by a group server, where the member resource access request is a multicast member resource access request,
  • the member resource access request includes a fan-out URI corresponding to the member resource, where the fan-out URI is used to indicate an access path of the member resource on the member device, and the operation module is configured to determine, according to the fan-out URI, the member resource An access path on the member device, and an operation of performing an access request according to the access path of the member resource on the member device.
  • the receiving module of the member device is further configured to: receive a group advertisement that joins the multicast group, where the group advertisement that joins the multicast group carries a multicast address, and according to the group advertisement that joins the multicast group A multicast group corresponding to the multicast address is added.
  • the group advertisement that is added to the multicast group further carries the mapping relationship between the fanout URI and the member resource
  • the member device further includes: a storage module, configured to store the fanout URI and the A multicast address mapping relationship and a mapping relationship between the member resource and the multicast address.
  • the member device further includes: a determining module, configured to determine that the destination address of the member resource access request is a multicast address.
  • the operation module of the member device determines, according to the fanout URI, an access path of the member resource on the member device, where: determining a multicast group that includes a multicast address that is the same as the destination address in the member resource access request.
  • the information, the multicast group information that determines the multicast address that is the same as the destination address in the member resource access request includes the same fanout URI as the destination URI in the member resource access request, and determines the fan group in the multicast group information.
  • the access path of the member resource corresponding to the URI on the member device.
  • the operation module of the member device accesses the member device according to the member resource.
  • the operation of the request path to perform the access request is specifically: replacing the fan-out URI included in the destination URI in the member resource access request with the access path of the determined member resource on the member device, and targeting the determined member resource on the member device.
  • the member resource corresponding to the access path performs an operation of accessing the request.
  • the receiving module of the member device is further configured to: receive a group advertisement that leaves the multicast group, where the group advertisement that leaves the multicast group carries a multicast address; and the storage module of the member device further uses And deleting the stored multicast group information corresponding to the multicast address in the group advertisement leaving the multicast group, and exiting the multicast address in the group advertisement of the leaving multicast group. Multicast group.
  • the receiving module of the member device is further configured to: receive a group advertisement that leaves the multicast group, where the group advertisement that leaves the multicast group carries a multicast address and a member resource that needs to leave, and the The member resource of the member device includes the member device to which the member resource that belongs to the group resource belongs and the access path of the member resource on the member device.
  • the storage module of the member device is further configured to delete the stored group with the leaving multicast group.
  • the multicast group information of the multicast address with the same multicast address in the group advertisement needs to leave the member resource of the group resource; and delete the stored multicast address in the group advertisement of the leaving multicast group.
  • the storage module of the member device is further configured to determine that a fanout URI in the multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group does not correspond to Member resources.
  • the member device in which the member resource in the group resource is located can be multicasted. Sending a member resource access request, and including the fan-out URI in the member resource access request, so that the member device to which the member resource belongs is executed according to the access path of the member resource indicated by the fan-out URI on the member device. The operation indicated by the member access request. Therefore, the group server does not need to unicast access requests to member devices, saving network Overhead.
  • FIG. 1 is a flowchart of a method for accessing a group resource according to an embodiment of the present invention
  • 2A is a flowchart of establishing a multicast group according to an embodiment of the present invention.
  • FIG. 2B is a schematic structural diagram of an M2M network connection relationship according to an embodiment of the present invention
  • FIG. 2C is a flowchart of allocating a multicast address to a member device and establishing a mapping relationship according to an embodiment of the present invention
  • Figure 2-D is a schematic structural diagram of an M2M network connection relationship according to an embodiment of the present invention
  • Figure 2-E is a schematic structural diagram of an M2M network connection relationship provided by an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a multicast group resource stored by a member device according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a method for accessing a group resource according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a method for processing, by a member device, a received member resource access request according to an embodiment of the present disclosure
  • FIG. 4 is a flowchart of a method for accessing a group resource by directly allocating a multicast address according to an embodiment of the present invention
  • FIG. 5 is a flowchart of a method for accessing a group resource of a global multicast address by using an application according to an embodiment of the present disclosure
  • FIG. 6 is a flowchart of a method for accessing a group resource by using a remotely allocated multicast address according to an embodiment of the present invention
  • Step 101 Receive an access request for a member resource, where the access request for the member resource carries a group resource identifier of a group resource to which the member resource belongs;
  • the first group server receives an access request for the member resource.
  • the first group of servers receives an access request for a member resource whose group resource ID is Grp4: GET http: ⁇ gl.example.org/groups/grp4/membersContent/data HTTP/1.1.
  • grp4 is the group resource identifier
  • the "membersContent” part indicates that the request is an operation for all member resources in the group resource corresponding to grp4
  • “data” is an instance of the suffix to indicate that the request should be specifically accessed. "data" data for each member resource.
  • Step 102 Acquire, according to the group resource identifier, a fan-out URI corresponding to the member resource in the group resource, and a multicast address corresponding to the fan-out URI, where the fan-out URI is used to indicate that the member resource is in the member The access path on the device.
  • the first group server receives the access request for the member resource, first, according to the group resource identifier in the access request for the member resource, check whether the group resource is a mapping relationship between the multicast address and the fanout URI. And further establishing a mapping relationship between the fanout URI and the member resource. If a mapping relationship between the multicast address and the fanout URI is established, the member resource access request is sent according to the mapping relationship between the multicast address and the fanout URI. To each member device, the first access request for the member resource is sent one by one in a unicast manner according to the method in the prior art.
  • the destination address of the member resource access request should be set to be multiple.
  • the multicast address in the mapping relationship between the broadcast address and the fanout URI that is, the multicast address assigned by the group server to the member resource
  • the destination URI is set to the fanout URI.
  • the group resource includes a mapping relationship between multiple sets of multicast addresses and fanout URIs
  • a member resource access request should be sent according to the above method for the mapping relationship between each group of multicast addresses and fanout URIs.
  • the first group server If the destination URI in the access request for the member resource received by the first group server further includes any suffix (such as a sub-resource, an attribute, a parameter, etc. for accessing internal information in the member resource), the first group server The destination URI in the sent member resource access request should also add a corresponding suffix after the fanout URI. Specifically, the first group server needs to determine that the destination URI in the access request for the member resource further includes a suffix; and the first group server further needs the destination URI to be set to the fanout corresponding to the member resource. The URI and the suffix included in the destination URI are added after the fan-out URI to generate a member resource access request.
  • suffix such as a sub-resource, an attribute, a parameter, etc. for accessing internal information in the member resource
  • the first group server or other group server maps the mapping relationship between the multicast address and the fan-out URI as shown in Table 1 and the fan-out RUI and member resources.
  • Table 1 Group Resource Mapping Table
  • Grp4 is the group resource identifier; member resource m41, m42, multicast address: [FF32:30:3FFE:FFFF:1::1231] is the multicast resource assigned to the member resource m41, m42 in the group resource Grp4.
  • the fanout URI: /xxx/temp 1 is the access path of the member resource m41, m42 on the member device to which the member resource belongs.
  • at least two member resources correspond to one multicast address and fanout URI. .
  • the member resource column in Table 1 may not include m41, m42. Then the table contains a fanout URI and more Broadcast address mapping
  • Step 103 Send a member resource access request to the member device to which the member resource belongs according to the multicast address, where a destination URI of the member resource access request includes a fanout URI corresponding to the member resource, so that the member resource is used.
  • the member device belongs to perform the operation indicated by the member resource access request according to the access path of the member resource indicated by the fanout URI on the member device.
  • the first group server sends the following member resource access request to the member device according to the mapping relationship between the fanout URI and the multicast address in Table 1:
  • the URI carried in the GET command is the fanout URI "/xxx/templ/data" with the suffix data added, and the host header field carries the multicast address as the destination address (that is, the first group server is the group resource Grp4).
  • the member devices to which the member resources m41, m42 belong receive the GET /xxx/templ/data HTTP/1.1 request after the multicast address [FF32:30:3FFE:FFFF:1::1231]
  • the data of the member devices D1 and D2 whose path is suffixed as /xxx/templ may be sent to the first group server, so that the first group server does not need to send the member resource access request to the member in the form of unicast.
  • Devices D1 and D2 save network traffic.
  • the first group server before the first group server receives the access request for the member resource, the first group server further receives the group resource creation request, where the group resource creation request carries each member resource, and the member resource includes the The member device to which the member resource belongs and the access path of the member resource on the member device; the member device to which the member resource belongs and the access path of the member resource on the member device allocate at least one multicast address to the member device to which the member resource belongs And establishing, according to the access path of the member resource on the member device, a mapping relationship between the multicast address and the fan-out URI, where the fan-out URI is used to indicate an access path of the member resource on the member device.
  • the first group server creates a group resource and establishes a mapping relationship between the multicast address and the fan-out URI.
  • the method includes the following steps: Step 201: The first group server receives the group resource creation request, where the group resource creation request carries each member resource, where the member resource includes the member device to which the member resource belongs and the member resource accesses on the member device. path.
  • Step 202 The first group server acquires the characteristics of each member resource according to the member device to which the member resource belongs and the access path of the member resource on the member device, and determines whether the multicast group needs to be established according to the feature of the member resource; For the method for the first group server to determine whether a multicast group needs to be established, refer to the description in Figure 2-A, including the following steps:
  • Step 202-1 The first group server parses the group resource creation request, and obtains a group resource feature description and a feature description of the member resource, including but not limited to a group resource type attribute (eg, whether it is static or dynamic) Or a temporary group), the purpose of the group resource (whether a reliable request response is required), the access path of the member resource on the member device, the access interface of the member resource, the member device to which the member resource belongs, and the network feature (whether or not the support is supported. Broadcasting and other features.
  • a group resource type attribute eg, whether it is static or dynamic
  • a temporary group e.g., whether it is static or dynamic
  • the purpose of the group resource whether a reliable request response is required
  • the access path of the member resource on the member device e.g, whether it is static or dynamic
  • the access interface of the member resource e.g., whether it is static or dynamic
  • the member device to which the member resource belongs e.g., whether it is static or dynamic
  • the network feature whether
  • the feature description for the group resource can be obtained from the group resource description content carried by the group resource creation request.
  • the group resource description content includes the type attribute and the use of the group resource; and the feature description of the member resource may be obtained by using the URI information of the member resource included in the group resource description, including the URI structure of the member resource,
  • the member interfaces of the member resources can access the member devices of the member resources and further obtain the network features of the member devices and the network features to which the member devices belong.
  • Step 202-2 Determine, according to the group description of the group resource creation request, whether the created group resource is a relatively static group, or a dynamic group that changes frequently, and if it is a relatively static group, perform The subsequent judgment process; if it is a dynamic group, does not create a multicast group and end the process for the group resource, thereby avoiding the multicast group creation and maintenance overhead caused by the frequent changes of the group.
  • the relatively static group may be: a group description includes a specific member resource list and the change of the member is controlled by the first group server by a group management command (such as adding/removing members);
  • the dynamic group includes but is not limited to:
  • the member resource included in the group is a resource set that satisfies a specific condition, such as a member resource within a specified geographical range, or has other phases.
  • Member resources of the same feature, and changes in group members can be triggered automatically based on changes in the characteristics of the member resources themselves (such as members leaving or entering a geographic area, the group selecting a channel).
  • Step 202-3 Determine, according to the access interface of the member resource carried in the group resource creation request, whether the access interfaces of the member resources are consistent. If the subsequent judgment process is performed, the multicast group is not created for the group resource and the process ends. Whether the member resource access interfaces are consistent or not can be accessed by using the same multicast packet (such as IPv4 or IPv6). For example, if the URI for accessing multiple member resources follows the same protocol and access port number, and the URIs of the plurality of member resources are the same on different member devices, the multiple member resources may be considered to have The same resource access interface. In an actual system, the URI can be represented by a URL (Uniform Resource Locator), and the basic structure of the URL includes:
  • ⁇ 8 (11 ⁇ 21116> partially determines the protocol (such as http or coap) used to access the corresponding resource of the URL; ⁇ authority> part determines the address (such as IP address or domain name) of the member device to which the member resource belongs; ⁇ port > As an option, indicates the protocol access port number; ⁇ path>? ⁇ query># ⁇ fragment> indicates the access path of the resource on the device.
  • protocol such as http or coap
  • ⁇ scheme> uses the same coap protocol, and the access path on member devices (here dl and gl) is /xxx/templ; conversely, the access path of ml2 on member device dl is /yyy/temp2, and ml4 ⁇ scheme> ⁇ 7 http protocol, so ml2 and ml4 do not have the same resource access interface as other member resources.
  • Step 202-4 The first group server determines whether the member device and the member device to which each member resource belongs and the network to which each member device belongs support multicast. If the subsequent judgment process is supported, the group resource is not created. Broadcast group and end process. Whether the member resource supports multicast or not depends on whether the URL corresponding to the member resource supports multicast protocol access (for example, the HTTP protocol does not support, but the CoAP protocol supports); whether the member device to which the member resource belongs and the network to which the member device belongs To support the multicast, the first group server may further obtain the resource information of the member and the related resource representation information of the member device to which the member resource belongs, such as registration information, and determine the resource description information, such as the registration information.
  • the resource information of the member and the related resource representation information of the member device to which the member resource belongs such as registration information
  • the resource description information such as the registration information.
  • the registration information of the member device D1 of the member resource mil on the M2M platform N1 can be accessed by the URL under the mouth: http://nl.example.com/scls/dl ,
  • the first group server can obtain the content of the resource corresponding to the URL by sending an HTTP GET request to N1.
  • whether multicast is supported for D1 can be represented by a special attribute (such as "multicastEnabled"). If the value is TRUE, it means multicast is supported. If the value is FALSE, it means that multicast is not supported.
  • the first group server is the M2M device D1
  • the group resource Grp2 includes the member resource m21 on the M2M platform, and the D1 accesses the m2 through the M2M gateway G1.
  • D1 can multicast the request to G1, and then G1 converts it to unicast (such as HTTP protocol) to access N1. M21. At this time, it can be considered that access to the member resource m21 supports multicast.
  • Step 202-5 the first group server determines that the member resource that meets the above conditions belongs to Whether the device reaches a certain number, if yes, the subsequent steps are performed, otherwise the ending process does not create a multicast group for the group resource.
  • a quantity may be determined by a pre-configured policy or parameter as a threshold for establishing a multicast group. When the threshold is less than this threshold, a multicast group is not required to be established for the member resources to save management overhead of the multicast group.
  • the steps 202-2 to 202-5 above are not strictly chronological, and the first group of servers may only perform one or more between 202-2 and 202-5 depending on the configured policy or capability.
  • the embodiments of the present invention are not limited herein.
  • the first group server may also determine whether the member access for the group resource requires a reliable response. If yes, the end process does not create a multicast group for the group resource, otherwise the subsequent determination process is performed.
  • the requesting reliable response means that the member device of the member resource must return a response message indicating that the operation succeeds or fails after receiving the member resource access request.
  • the Request message of the Confirmable (CON) type in the CoAP protocol is a member resource access request that requires a reliable response, and the receiver of the member resource access request is required to return an Acknowledgement (ACK) or a Reset (RST) type.
  • the response message; the request message of the Non-Confirmable (NON) type does not require the message recipient to return any response message.
  • Step 203 Allocate a multicast address to the member resource according to the member device to which the member resource belongs and the access path of the member resource on the member device, and establish the multicast according to the access path of the member resource on the member device.
  • the mapping relationship between the address and the fanout URI please refer to the description in Figure 2-C, including the following steps:
  • the first group server analyzes the multicast domain to which the member device (hereinafter referred to as the member device) to which the member resource that meets the conditions in the step 202 belongs, and whether the member devices belong to the local multicast domain. If yes, go to step 203-4. Otherwise, perform step 203-2.
  • the multicast domain may be divided into a local multicast domain, a remote multicast domain, and a global multicast domain.
  • the local multicast domain refers to the area of the network address managed by the first group server, and the first group server can allocate the multicast address of the local multicast domain (local multicast address;) to the member devices in the area.
  • Packets destined for the local multicast address can then be received by all member devices that have joined the local multicast group.
  • the remote multicast domain is an area other than the area of the network address managed by the first group server.
  • the group server cannot allocate the local multicast address to the remote multicast domain, and the member devices in the local multicast domain cannot receive the area. Packets destined for the multicast address (remote multicast address) of the remote multicast domain (even if the address multicast address and the remote multicast address are the same, because different multicast domains can reuse the same address space), and vice versa Of course.
  • a global multicast domain is an area of the entire network that includes a local multicast domain and a remote multicast domain. Therefore, regardless of the local network device or the remote network device, the multicast packet addressed to the global multicast address can be received as long as the multicast group indicated by the multicast address (global multicast address) in the global multicast domain is added.
  • Global multicast addresses may be managed by a global network entity, or they may be assigned to certain group servers in advance according to a certain address plan. For guidance on the allocation scheme of IPv4 and IPv6 multicast address space, refer to the standard documents such as [RFC3171] and [RFC 4291]. Which multicast domain a member device belongs to can be judged according to the connection relationship between the member device and the group server.
  • a member device such as an M2M device
  • the first group server such as an M2M gateway
  • the member can be considered as a member.
  • the device belongs to the local multicast domain of the group server.
  • the member device registers with other entities (such as another M2M gateway) or higher level (such as the M2M platform) that are level with the first group server (ie, the M2M platform)
  • the member device can be considered to belong to the remote multicast domain. That is, the first group server acquires the registration information of each member device according to the member address in the created group resource request, and then determines whether it belongs to the local multicast domain according to the registration information.
  • the first group server determines whether a global multicast address can be allocated to the member device of the group resource. If yes, step 203-5 is performed; otherwise, step 203-3 is performed.
  • the global multicast address may be pre-assigned to certain group servers according to a certain address planning policy. Therefore, when the first group server determines that the member devices of the group resource do not all belong to the local multicast domain under the jurisdiction of the first group server, the first group server searches for the pre-allocated global multicast address space. There is also a global multicast address that has not been assigned, or the first group server is globally assigned to manage the global multicast address. The entity issues an address allocation request. For the first group server, an address allocation request is sent by the global multicast address management entity responsible for managing the global multicast address allocation, and the specific implementation manner is as follows:
  • the global multicast address management entity is the M2M platform N1, and the resource URL for allocating the global multicast address on N1 is: http: ⁇ nl.example.com/mcAddrPool, then the first group server can pass an HTTP The GET request accesses the resource http://nl.example.com/mcAddrPool. If N1 returns a successful response, the global multicast address requested by the first group server may be obtained from the message body of the response message. If the failure response is returned by N1, it means that the M2M platform N1 cannot be the member device. Assign a global multicast address.
  • the first group of servers can also request a remote or global multicast address to be assigned to other entities (such as other group servers) responsible for managing local or remote multicast address allocation in a similar manner, with the implementation of the N2M platform N1.
  • entities such as other group servers
  • the manner in which the global multicast address is applied is similar, and the present invention is not described in detail.
  • the first group server determines whether the member device (non-local member device) that is not in the local multicast domain can be accessed by the second group server, if yes, step 203-6 is performed; otherwise, step 203- 7.
  • the first group server is the first M2M gateway G1
  • the group resource Grp3 has non-local member resources m31, m32, m33, m34 as follows:
  • the member devices of the B'm m31 and m32 are M2M devices D2, and the member devices of m33 and m34 are M2M devices D3 and D4, respectively, and D2, D3, and D4 are not attributed to the local multicast domain of G1. 4.
  • the D3 and D4 can be accessed through the second M2M gateway G2, and the network connection relationship is as shown in FIG. 2-D. Therefore, members (m31, m32) can be considered to be accessible through the second group server (M2M device D2 in Figure 2-D), while members (m33, m34) can be served through the third group.
  • the server (M2M gateway G2 in Figure 2-D) is accessed.
  • the first group server (M2M in the 2-D of FIG. 2-D)
  • step 203-6 can still be executed to create a group resource for the member resource m31.
  • the first group server may determine a threshold number of members according to a pre-configured policy or parameter. If the threshold is less than the threshold, the first judgment condition is not satisfied, and step 203-7 is performed. Step 203-6 is not performed to save group management overhead.
  • the first group server allocates a local multicast address to a local member device supporting multicast.
  • the first group server allocates a global multicast address to all member devices supporting multicast.
  • the first group server requests the second group server to create a second group resource on the second group server according to the determination result of step 203-3, where the second group resource includes the A member resource that is not managed by the second group server accessed by the second group server. Thereafter, the second group server performs the related process from the step 201 in FIG. 2 according to the method disclosed in the present invention, and the embodiment of the present invention is not described in detail herein.
  • the first group server records a list of non-local member resources that cannot be accessed by the second group server, so as to be subsequently accessed by unicast.
  • 203-8 determines whether the second group server (such as G2 in FIG. 2-D) is a local multicast domain device (that is, whether it is accessed through the first group server), if the first group server is executed in step 203-9.
  • the second group server may be allocated a local multicast address and step 203-10 is performed, otherwise the mapping relationship between the member resource and the second group server is established, and the second group server is accessed according to the default unicast mode; In the example of -D, the second group server D2 or G2 does not belong to the first Local multicast device of group server G1.
  • Step 203-10 according to the allocation result of the multicast address in step 203-4, 203-5 or 203-9, or the access address of the second group server in 203-8, or the member device in 203-7
  • the address is established in the first group server to establish a mapping relationship for the group resource.
  • the member resources in the same multicast domain can share one multicast address.
  • multiple mapping relationships can be established for the group resources.
  • the group resource identifier needs to be associated with the assigned multicast address, and the mapping relationship between the multicast address and the "fanout URI" is established.
  • the fanout URI is: when the first group server receives the access request for the member resource of the group resource, the destination URI of the member resource access request is sent to the member device.
  • the fanout URI is an access path of the member resource on the member device; when the URI follows The same protocol and access port number, but when the access path on the member device is different, the fanout URI is set to a virtual resource identifier (which may be a group resource identifier or other form of resource identifier).
  • a virtual resource identifier which may be a group resource identifier or other form of resource identifier.
  • the member resources of the group resource have the same access path on the member device.
  • Grp4 http: ⁇ gl .example.org/groups/grp4
  • the member resources contained in it are m41 on M2M device D1 and m42 on M2M device D5:
  • the IPv6 multicast address assigned by the first group server (in this example, the M2M gateway G1) to the member resources m41 and m42 of the group resource Grp4 is [FF32:30:3FFE:FFFF:1::1231], and The network connection relationship between devices is shown in Figure 2-E (that is, the membership resources m41 and m42 belong to The device devices D1 and D2 are all attributed to the M2M gateway G1); the multicast address of the group resource Grp4 ([FF32:30:3FFE:FFFF: 1:: 1231]) and the fanout URI (/xxx/templ)
  • the mapping relationship, and the mapping relationship between the member resources (m41 and m42) of the group resource Grp4 and the fanout URI (/xxx/templ) are as shown in Table 1.
  • the mapping relationship may also be only the group resource.
  • the mapping relationship between the multicast address of the Grp4 and the fanout URI does not need to record the mapping relationship between the member resources of the group resource and the fanout URI.
  • the same group server usually includes multiple group resources, and the member resource characteristics of each group resource are inconsistent, for the uniformity of recording, even if it is not necessary to record the mapping relationship of the fan-out URI of the member resources, Map relationship record member resources in the list, or retain related attributes.
  • the member resource of the group resource represents the member device where it is located.
  • Grp5 http://gl .example.org/groups/grp5
  • the member resources contained therein are respectively mm, m52 on the devices D1, D5, and D6.
  • M53
  • the assigned IPv6 multicast address is [FF32:30:3FFE:FFFF:1::1232], and the network connection relationship between devices is still shown in Figure 2-E (that is, the members to which member resources m51, m52, and m53 belong respectively)
  • the devices D1, D5, and D6 are all attributed to the M2M gateway G1), and the fanout URI corresponding to the member resources m51, m52, and m53 is the root symbol ", and the multicast address of the group resource Grp5 ([FF32:30:3FFE
  • the mapping relationship between :FFFF:1::1232]) and fanout URI(/) and the mapping relationship between member resources (m51, m52, and m53) and fanout URI(/) are shown in Table 2.
  • the fanout URI information can also be omitted.
  • it can also be called the multicast address of the group resource ([FF32:30:3FFE:FFFF:1::1232]) and the fan.
  • the mapping relationship between the URI (/) and the member resources (m51, m52, and m53) is shown in the embodiment of the present invention without special explanation.
  • the shot relationship refers to the mapping relationship between the multicast address, the member resource, and the fanout URI.
  • the member resources of the group resource have different access paths on the respective member devices.
  • Grp6 htt ://g 1.example.org/groups/grp6 , where the member resources of the group resource Grp6 are respectively m61 on the M2M device D5 and (m62, m63) on the M2M device D6:
  • the IPv6 multicast address assigned to Grp6 by the first group server is [FF32:30:3FFE:FFFF: 1:: 1233], and the network connection between devices
  • the relationship is as shown in Figure 2-E (that is, the member device D5 and the member resource m62 to which the member resource m61 belongs, and the member device D6 to which the m63 belongs belong to the M2M gateway G1), and the first group server needs to be the group resource Grp6.
  • Each member resource is assigned a virtual fanout URI (the specific allocation method may be determined by the first group server, which is not limited herein), for example, wdl-know/grp6,.
  • the virtual fanout URI ( /well-know/grp6 ) does not directly correspond to the member resource on any member device, but each member device needs to associate it with the member resource corresponding to the virtual fanout URI.
  • member resources of the device refer to the related description in Figure 2-G.
  • an appropriate namespace division may be adopted between different group servers, or directly using a unique ']
  • a group URI (eg /g Lexample.org/groups/grp6 ) is included as part or all of the virtual fanout URI.
  • mapping relationship between the member resources m61, m62, and m63 of the group resource Grp6, and the fanout URI ( /well-know/grp6 ), and the multicast address ([FF32:30:3FFE:FFFF: 1::1233])
  • the fanout URI ( /wdl-know/grp6 )
  • the access interface part of the member resource is the same.
  • the member resources with the same access interface can be divided into the first group (there can be multiple groups)
  • the member resources with different access interfaces are divided into the second group, and then each group member resource, multicast address and fanout URI are mapped according to the above method, thereby forming multiple sets of mapping relationships.
  • the group server can assign different multicast addresses to each group member resource, or assign the same multicast address to it. For the latter, the "fanout URT" for each group is required to be different.
  • Grp7 http://gl .example.org/groups/grp7 , where the member resources included in the group resource Grp7 are respectively m71 on the M2M device D1.
  • the first group server assigns the IPv6 multicast address to the group resource Grp7 as [FF32:30:3FFE:FFFF: 1 :: 1234], and the device room
  • the network connection relationship is as shown in Figure 2-E (that is, the member devices D1, D5, D6, D7, D8, and D9 to which the member resources m71, m72, m73, m74, m75, and m76 belong are all attributed to the M2M gateway G1).
  • the member resources (m71, m72) correspond to the same fan-out URI xx/aa/"
  • (m73, m74) corresponds to the same fan-out URI yy bb/”
  • (m75, m76) needs to allocate a virtual fan-out.
  • the URI such as wdl-known/grp7/” establishes the mapping relationship for each member resource of the group resource Grp7 as shown in Table 2, that is, member resources (m71, m72) and fanout URI (/xx/aa).
  • mapping relationship and mapping relationship between multicast address [FF32:30:3FFE:FFFF: 1 :: 1234]) and fanout URI (/xx/aa), member resource ( m73, m74 ) and fanout URI (/yy /bb) mapping relationship and multicast address ([FF32:30:3FFE:FFFF:1:: 1234] ) and the fanout URI (/yy bb), the mapping of member resources ( m75, m76 ) and fanout URI ( /wdl-known/grp7 ) and Broadcast address
  • fan-out URI /wdl-known/grp7 mapping, member resource ( m77 ), unicast address ( [3FFE:2A00: 100:7031 The mapping between ::1] ) and the fanout URI (/abc).
  • the group resource also contains member resources that do not support multicast
  • the unicast access methods in the prior art are separately adopted for the member resources that do not support multicast. Processing does not need to join the above member address mapping table.
  • the unicast access address and fan-out URI of these member resources can also be separately listed in the member address mapping table. In this case, you need to fill in the unicast address into the multicast address bar and fill the access path on the member device into the fanout URI column. For example, suppose the above Grp7 also contains the member m77 as:
  • the first group server in this example, the M2M gateway G1 in FIG. 2-E
  • the M2M gateway G1 in FIG. 2-E may be respectively at D2 and G2.
  • Grp8 contains (m31, m32)
  • Grp9 contains (m33, m34), for example:
  • the group resource URI (or its access path on the member device) is filled in the fanout URI column, as shown in Table 2.
  • Table 2 group resource mapping table
  • the group resource mapping table 1 and table 2 may perform maintenance operations through a general database inside the first group server, or register to a DNS (Domain Name System) server, or Expressed as a RESTful resource.
  • the RESTful resource can be used as part of the group resource representation, as shown in Figure 2-F.
  • ⁇ group> is a group resource representation defined in the prior art ETSI M2M specification TS 102 690, and includes a members attribute mainly for describing each member resource URI, which is used to refer to all member resources.
  • the symbol " ⁇ >" means that there may be multiple instances of the same type of attribute or sub-resource, and the string name of each instance can be arbitrarily set.
  • the requester can modify the member list by adding, deleting, modifying, or viewing the members attribute. You can also view the member resource list by viewing the members attribute, or by using the membersContent resource.
  • the operations of adding/removing/changing/checking, etc., implement modification or viewing of all member resources in the group resource.
  • the member resource and the fan-out URI and the multicast address for multicast management in the group resource are described by adding a fan-out group 4&1101 ⁇ 61> resource to the existing group resource.
  • Each 4&1101 ⁇ 61> can describe the fan-out URI and multicast address mapping relationship in Table 1 or Table 2, and the mapping relationship between member resources and fan-out URIs.
  • One ⁇ group> source itself corresponds to one of Table 1 or Table 2.
  • Each ⁇ f anoutSet> resource can contain the following attributes:
  • fanoutAddress Corresponds to the multicast address in Table 1 or Table 2.
  • fanoutUri Corresponds to the fanout URI information in Table 1 or Table 2. This property is optional in some cases. For example, when a ⁇ group> resource contains only one ⁇ fanoutSet> resource, and all member resources have the same access path on its member devices, the fanout URI can be explicitly obtained from the member resource URI in the members attribute. This property can be omitted at this time. Alternatively, when the fanout URI adopts the uniquely determined group URI itself, the attribute may also be omitted.
  • the addressType is optional information to describe the address type in the fanoutAdress as multicast or unicast, and information such as IPv4 or IPv6.
  • the memberList is optional. It describes the member resource list involved in the mapping relationship, that is, the member device to which each member resource belongs and the access path of each member resource on the member device, that is, the member resource in Table 1. Specifically, when all the member resources of the group resource have the same access path on the member device, all the member resources correspond to one multicast address and fan-out URL, because the members attribute already contains information about all member resources in the group resource, The memberlist attribute does not need to record the information of each member resource again.
  • step 203-2 may be performed before step 203-1 to preferentially allocate a global multicast address instead of a local multicast address, and the mapping relationship between the multicast address and the fanout RUI and the member resources in step 203-10.
  • the mapping relationship with the fanout URI can be completed with the allocation of multicast or unicast addresses among steps 203-4 through 203-9.
  • the group resource is updated, if the composition of the member resource changes (if the original member is deleted, or the new member is added), the first group server should also be executed as described above. And reassign the multicast address and update the corresponding mapping as needed.
  • Step 204 The first group server sends a group advertisement that joins the multicast group to the member device to which the member resource belongs according to the mapping relationship between the multicast address and the fan-out URI, and the group advertisement that joins the multicast group carries the multicast
  • the member device to which the member resource belongs is advertised to join the multicast group corresponding to the multicast address according to the group notification of joining the multicast group.
  • the first group server sends the group advertisement to join the multicast group to the member device supporting the multicast according to the mapping relationship between the established multicast address and the fanout URI.
  • the group advertisement that joins the multicast group carries the assigned multicast address to indicate that the member device supporting the multicast joins the multicast group corresponding to the multicast address.
  • a group resource (such as Grp7) includes a mapping relationship between multiple multicast addresses and a fan-out URI.
  • the first group server needs to respectively correspond to member devices corresponding to member resources in a mapping relationship with a fan-out URI.
  • the group advertisement added to the multicast group includes a multicast address corresponding to the multicast group to which the member device belongs, and the group advertisement added to the multicast group may further include a fan-out URI and a mapping relationship of the member resources.
  • the group advertisement added to the multicast group may only need to be included.
  • Multicast address information when the access paths of the member resources in the group are not exactly the same on the member devices (such as Grp6, Grp7 in Table 2), the group advertisement added to the multicast group should also include the fanout URI and a mapping relationship of the member resources, so that the member device to which the member resource belongs stores the fan-out URI and the multicast address mapping relationship, and a mapping relationship between the member resource and the multicast address.
  • Group advertisements added to a multicast group can be sent to member devices in various ways such as unicast, multicast, or broadcast according to a prior configuration. Specifically, when the unicast mode is adopted, the first group server sends the unicast address to the unicast address of the member device to which each member resource belongs (for example, ⁇ ⁇ 4 or IPv6 unicast address) to join the multicast group.
  • the unicast address for example, ⁇ ⁇ 4 or IPv6 unicast address
  • the group server uses multicast or broadcast messages to a pre-agreed multicast or broadcast address (such as IPv4) Or the IPv6 multicast address is sent to the group advertisement of the multicast group, and the corresponding member device is required to join the multicast/broadcast group corresponding to the specific multicast or broadcast address in advance (for example, by using IGMP or MLD, etc.)
  • the IP multicast management protocol is implemented in a manner, and the group advertisement added to the multicast group should also include the identifier (URI) or member resource URI of the member device to indicate the identifier (URI) or member resource of the member device.
  • the member device corresponding to the URI receives and processes the group advertisement that joins the multicast group, and the other member devices ignore the group advertisement that joins the multicast group.
  • the embodiment of the present invention does not limit the transmission protocol (such as HTTP, CoAP, or SIP, etc.) used by the unicast, multicast, or broadcast mode to send a group advertisement to join the multicast group, and the message format itself may also adopt different encapsulation methods. (eg XML or binary encoding, etc.). Only a preferred embodiment of a group announcement using RESTful transmission to join a multicast group is given below.
  • a member device stores a mcGroups resource in which a member resource is added to a multicast group, and is used to store 0 to any plurality of multicast group resources ⁇ mcGroup>, and each ⁇ mcGroup> resource describes that the member device joins
  • the multicast group information as shown in Figure 2-G, the ⁇ mcGroup> resource contains the following attributes:
  • Mc Address The multicast address of the multicast group to which the member device is added.
  • fanoutUri The fanout URI corresponding to the multicast group that the member device joins.
  • memberList A list of local member resources corresponding to the fanout URI, which may be the full URI of the member resource or only the access path of the member resource on the member device.
  • the first group server may send a multicast group resource ⁇ mcGroup ⁇ request for adding, deleting, or modifying the multicast group resource ⁇ mcGroup ⁇ request to the corresponding member device by using a unicast or multicast or broadcast RESTful request, thereby implementing group notification of joining the multicast group. send.
  • the first group server indicates that the member device is added to the multicast group by adding the group advertisement of the multicast group, the following processing is performed:
  • Vxxx/mcGroups indicates the access path of the mcGroups resource on Dl
  • "HTTP/1. ⁇ indicates the protocol version number
  • the Host header field carries the domain name or IP address of Dl. If the group advertisement of the multicast group is sent by using the CoAP protocol supporting the multicast, the Host header field may carry a multicast group address that D1 has previously joined, and the Host header field and the parts of the request message are according to the prior art. The method is converted to the corresponding field in the CoAP protocol.
  • the message header fields or message body contents of other POST requests that are not related to the present invention are not exhaustively listed.
  • member device D1 When member device D1 successfully receives the POST request and adds the ⁇ mcGroup> resource locally, it returns an HTTP success response to the first group server, as follows:
  • the group server can also directly write a ⁇ 1 ⁇ 0 0 ⁇ > resource named mcGrpl in the member device D1 by sending an HTTP PUT request, for example:
  • the member device Dl directly returns a successful response: HTTP/1.1 200 0K
  • the group advertisement leaving the multicast group may be sent by using a method similar to sending the group advertisement of joining the multicast group. Processing as follows:
  • the first group of servers may also use other RESTful methods or other protocols (such as CoAP) to send the group announcements that join or leave the multicast group.
  • RESTful methods or other protocols such as CoAP
  • the NTP, POST, or DELETE method directly modifies the existing ⁇ mcGroup> resource table (or some of its attributes) on the member device to indicate the notification of the member device joining or leaving a multicast group.
  • the member equipment After receiving the group advertisement of joining or leaving the multicast group, the member equipment shall join or leave the corresponding multicast according to the multicast management protocol such as IGMP or MLD according to the indication in the group advertisement of joining or leaving the multicast group.
  • the group maintains the multicast group resource ⁇ mcGroup> stored in the member device at the same time to process subsequent group member access requests from the group server.
  • the second group server needs to be regarded as a member device, and the group notification of sending the joining or leaving the multicast group is performed. The same processing, no longer repeat here.
  • the first group server can also receive an update request for the group resource sent by the application server, such as adding a group resource update request of the member resource, and deleting the member resource.
  • an update request for the group resource sent by the application server such as adding a group resource update request of the member resource, and deleting the member resource.
  • the group resource update request that adds the member resource carries the identifier of the group resource and the member resource that needs to join the group resource, and the member resource that needs to join the group resource includes the member.
  • the first group server determines, according to the identifier of the group resource, the access path of the member resource that needs to join the group resource on the member device and the group corresponding to the identifier of the group resource.
  • the fan-out URI in the mapping relationship between the multicast address and the fan-out URI in the group resource is the same, and the mapping relationship between the multicast address and the fan-out URI is sent to the member device to which the member resource to be added to the group resource belongs.
  • the first group server receives the group resource update request for adding the member resource, determining, according to the identifier of the group resource, the access path of the member resource that needs to join the group resource on the member device and the group resource Identifying a fanout URI in the mapping relationship between the multicast address and the fanout URI in the corresponding group resource; the group corresponding to the identifier of the group resource Adding the member resource to be added to the group resource to the member device to which the member resource to be added to the group resource belongs, and adding the group advertisement to join the multicast group to the member device to which the member resource to be added to the group resource belongs to
  • the group advertisement of the multicast group carries the mapping relationship between the multicast address and the fan-out URI in the group resource corresponding to the identifier of the group resource
  • the description information of the stored group resource needs to be replaced according to the group description in the request for modifying the group resource description information, and according to the updated group.
  • the description information of the group resource updates the established group resource.
  • the group resource update request for deleting the member resource carries the identifier of the member resource and the group resource that are required to leave the group resource, and the member resource that needs to leave the group resource includes the member device and the member to which the member resource belongs.
  • a member resource of a resource includes a member device to which the member resource belongs and an access path of the member resource on the member device; determining according to the identifier of the group resource The member resource of the group resource and the fan-out UIR of the group resource are required to be updated, and the member resource
  • the first group server determines, according to the identifier of the group resource that the group resource update request of the member resource is deleted, the access path of the member resource that needs to leave the group resource on the member device and the fanout corresponding to the member resource that needs to leave.
  • the URI of the leaving the multicast group further includes the fan-out URI corresponding to the member resource that needs to leave the group resource, so that the member device to which the member resource that needs to leave the group resource belongs to leave the Broadcasting the multicast group indicated by the address, and deleting the group resource request request for deleting the member resource from the member resource according to the fan-out URI in the group advertisement that leaves the group resource and the group advertisement leaving the multicast group.
  • the member resource of the multicast group information corresponding to the identifier of the group resource.
  • a method for accessing a group resource includes the following steps:
  • Step 301 Receive a member resource access request sent by the group server, where the member resource visits The request is a member resource access request of the multicast, and the member resource access request includes a fanout URI corresponding to the member resource.
  • the member resource access request sent by the first group server is received by the multicast group.
  • the member resource access request refers to the description in step 103.
  • the embodiment of the present invention is not described in detail herein.
  • the member device may further receive a group advertisement that joins the multicast group, where the group advertisement that joins the multicast group carries a multicast address, and joins and multicast addresses according to the multicast address.
  • the corresponding multicast group receives the group advertisement that is sent by the first group server and joins the multicast group.
  • the group advertisement that is sent by the first group server to join the multicast group refer to the related description of step 204, which is not described in detail in this embodiment of the present invention.
  • 302. Determine, according to the fanout URI, an access path of the member resource on the member device, and perform an operation of the member resource access request according to the access path of the member resource on the member device.
  • the member device after receiving the member resource access request sent by the first group server by using the multicast group, the member device obtains the fanning URI carried in the member resource access request, and the member device receives the joining multicast group in step 204.
  • the member device of the member resource may further receive the group advertisement leaving the multicast group after joining the multicast group, where the group advertisement leaving the multicast group carries the multicast address; After receiving the group advertisement leaving the multicast group, deleting the stored multicast group information corresponding to the multicast address in the group advertisement leaving the multicast group, and exiting the group leaving the multicast group.
  • the multicast group corresponding to the multicast address in the group advertisement After receiving the group advertisement leaving the multicast group, deleting the stored multicast group information corresponding to the multicast address in the group advertisement leaving the multicast group, and exiting the group leaving the multicast group.
  • the group advertisement that leaves the multicast group may further carry a member resource that needs to leave the group resource, where the member resource that needs to leave includes a member device and a member resource to which the member resource that needs to leave the group resource belongs.
  • Member device is receiving a multicast broadcast After the group notification of the group, deleting the stored member resources of the multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group; and leaving the stored resource of the group resource; Multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group, and exits the multicast group corresponding to the multicast address in the group advertisement leaving the multicast group.
  • the member device deletes the multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group, and exits the leaving multicast. Before the multicast group corresponding to the multicast address in the group advertisement of the group, it is also required to determine the stored multicast group information in the same multicast address as the multicast address in the group advertisement of the leaving multicast group.
  • the fanout URI does not correspond to member resources.
  • the member device can receive the member resource access request sent by the first group server through the multicast group, so that the first group server does not need to separately send the member resource access request to the multicast group.
  • Each member device saves network traffic.
  • FIG. 3 is a flowchart of a method for a member device to process a received member resource access request according to an embodiment of the present invention, including the following steps:
  • Step 302-1 Receive a member resource access request.
  • the member device receives the member resource access request, and the member resource access request may be a unicast member resource access request, or may be a multicast member resource access request.
  • Step 302-2 The member device determines whether the member resource access request is a multicast request, and if yes, step 302-4 is performed; otherwise, step 302-3 is performed;
  • the member device resolves the member resource access request. If the destination address of the member resource access request is a multicast address, the member resource access request is obtained by multicast, that is, a multicast request. On the other hand, if the destination address of the member resource access request is the unicast address of the member device, it is not obtained through multicast, that is, the member resource access request is not a multicast request.
  • Step 302-3 The member device directly returns an operation result of the local member resource corresponding to the destination URI in the request according to the specific type of the request method, and the step is processed according to the prior art;
  • Operations on member resources include at least one of several basic types of operations, including RESTful Create (Create, corresponding to POST request in HTTP or CoAP protocol), Get (Retrieve, corresponding to GET request in HTTP or CoAP protocol), Update (Update, corresponding to PUT request in HTTP or CoAP protocol), Delete ( Delete, corresponding to the DELETE request in the HTTP or CoAP protocol, so the corresponding operation result is the status response code of whether the above operation is successful, and the content description including the created sub-resource, the content description of the acquired resource, and the updated resource respectively. The content description, the success of the deleted operation, etc.
  • step 302-4 the member device determines whether the local multicast group information includes the access path of the member resource indicated by the fanout URI included in the destination URI in the member resource access request on the member device, and if yes, step 302- 8, otherwise perform step 302-5;
  • Step 302-5 The member device determines the multicast group information that includes the multicast address that is the same as the destination address in the member resource access request, and refers to the multicast group resource ⁇ mcGroup> shown in Figure 2-G.
  • Step 302-6 The member device determines whether the multicast group information of the multicast address that is the same as the destination address in the member resource access request includes the fanout URI information related to the destination URI. If yes, step 302-7 is performed; otherwise, step 302-7 is performed. 9.
  • the fan-out URI related to the destination URI is specifically: the destination URI is the same as the fan-out URI in the multicast group information, or the destination URI includes the fan-out URI in the multicast group information.
  • Step 302-7 The member device replaces the fan-out URI part in the destination URI with the fan-out URI in the multicast group information according to the access path of the member resource corresponding to the fan-out URI on the member device in the multicast group information.
  • the access path of the member resource on the member device with the exception of the fanout URI in the destination URI as a suffix, adding the member resource behind the access path on the member device, thereby constructing an access request for the local member resource.
  • an access request to the local member resource needs to be constructed separately for each member resource.
  • Step 302-8 The member device operates the member resource according to a method in the member resource access request (such as HTTP GET/PUT/POST/DELETE), and returns the operation result.
  • a member device can merge multiple local member resources into one operation and return it to the group server. Do not return multiple operation results.
  • Step 302-9 The member device discards or ignores the member resource access request.
  • the member devices D1 and D5 have joined the multicast address. [FF32:30:3FFE:FFFF:1::1231]
  • the corresponding multicast group will receive the same access request as follows:
  • the member devices D1 and D5 will find the local member resource indicated by the URI according to the destination URI "/xxx/templ/data", and return the corresponding resource content according to the GET request method.
  • the first group server sends an access request for the member resources of the group resource Grp7 in Table 2, and the member devices D8 and D9 have joined because
  • the multicast group corresponding to the multicast address [FF32:30:3FFE:FFFF: 1 : : 1234] will receive the same member resource access request as follows:
  • Dl and D5 can't find the member resource whose access path is wdl-known/grp7 on the member device according to the destination URI well-known/grp7, but can find the fan-out URI in the locally stored multicast group resource information.
  • the record of well-known/grp7 as shown in Table 3, of course, the record of the fan-out URI wdl-known/grp7" may also be as shown in Figure 2-G, which is not limited herein.
  • Table 3 Member Resource Mapping Table
  • D1 and D5 respectively replace the fan-out URI part in the destination URI with the record in the corresponding local member resource list memberList, thereby constructing the corresponding local member resource access URIs as cc/data" and dd/data" respectively, and then according to The GET request method returns the corresponding resource content.
  • FIG. 4 is a flowchart of a method for accessing a group resource by directly allocating a multicast address according to an embodiment of the present invention, including the following steps:
  • Step 401 The network application server NA1 requests to create a group resource GrplO on the M2M platform N1 (ie, the first group server in the embodiment of the present invention), and send a group resource creation request to the N1.
  • the member resources mlOl and ml02 are included in the group resource creation request.
  • the member resources mlOl and ml02 are located on the two M2M devices D1 and D2 under the M2M gateway G1.
  • Step 402 N1 creates a group resource GrplO locally.
  • Step 403 N1 analyzes the group resource GrplO and its member resources mlOl and ml02, and determines that a multicast group can be established for the member resources mlOl and ml02. Specifically, the analysis of the group resource GrplO and its member resources mlOl and ml02 by N1 can be referred to the description of FIG. 2-A and the above embodiment and FIG. 2-A, and the embodiment of the present invention is not described in detail herein;
  • N1 assigns the same local or global multicast address to D1 and D2 and establishes a mapping relationship with the local or global multicast address.
  • Steps 404 and 404-a N1 send a group advertisement to the member devices D1 and D2 to join the multicast group, to indicate that D1 and D2 join the multicast group corresponding to the multicast address.
  • the group advertisements that are added to the multicast group may be sent to the D1 and the D2 one by one in a unicast manner; or may be sent to the multicast group that has been previously joined by the member devices D1 and D2 in a multicast manner.
  • step 204 refer to the related description of step 204. The embodiments of the present invention are not described in detail herein.
  • step 405 and step 405-a the member devices D1 and D2 join the multicast indicated in the multicast group advertisement by using a multicast management protocol such as MLD or IGMP according to the method in the prior art.
  • the multicast group corresponding to the address.
  • G1 is a local multicast router shared by D1 and D2, and D1 and D2 respectively send an MLD/IGMP report command to G1 to join the responding multicast group.
  • Step 406 The NA1 sends an access request to the member resource to the N1, requesting access to all member resources mlOl and ml02 in the group resource GrplO.
  • the NA1 sends an access request to the member resource to the N1, requesting access to all member resources mlOl and ml02 in the group resource GrplO.
  • Step 407 N1 determines that the group resource GrplO establishes a mapping relationship by using the group resource identifier GrplO, constructs a member resource access request, and sends the member resource access request to the multicast address of the mapping relationship (that is, the multicast address) by using multicast mode. ).
  • the multicast address of the mapping relationship that is, the multicast address
  • the multicast access request is forwarded to the local link.
  • Steps 408 and 408-a the member devices D1 and D2 receive the multicast access request, and access the local member resources mlO1 and ml02 indicated in the request, and then return the access result to N1.
  • the member devices D1 and D2 receive the multicast access request, and access the local member resources mlO1 and ml02 indicated in the request, and then return the access result to N1.
  • FIG. 3-A please refer to FIG. 3-A and the description of the foregoing embodiment and FIG. 3-A for the present step, and the embodiments of the present invention are not described in detail herein.
  • Step 409 N1 merges the received group member resource access results from D1 and D2.
  • Step 410 N1 returns the merged group member resource access result to NA1.
  • FIG. 5 is a flowchart of a method for accessing a group resource of a global multicast address by using an application according to an embodiment of the present invention, including the following steps:
  • Step 501 The network application server NA1 requests to create a group resource Grpll on the M2M gateway G1 (that is, the first group server in the embodiment of the present invention), and sends a group resource creation request to the G1.
  • the member resources ml 11 and ml 12 are included in the group resource creation request.
  • the member resources ml 11 and ml 12 are located on the two M2M devices D 1 and D2 under the M2M platform N 1 .
  • Step 502 The M2M gateway G1 locally creates the group resource Grpl0 according to the prior art.
  • Step 503 The M2M gateway G1 analyzes the group resource Grp11 and its member resources mill and Mll2, determine that a multicast group can be established for the member resources mlOl and ml02. Specifically, the analysis of the group resource GrplO and its member resources mlO1 and ml02 by the M2M gateway G1 can be referred to in FIG. 2-A and the description corresponding to the above embodiment and FIG. 2-A, and the embodiment of the present invention is not described in detail herein;
  • the M2M gateway G1 determines that the member devices D1 and D2 do not belong to its local multicast domain, and the M2M gateway G1 cannot directly allocate the global multicast address, and thus to the M2M platform N1 having the global multicast address allocation capability (the second group server) Request to assign a global multicast address to D1 and D2.
  • the M2M platform N1 having the global multicast address allocation capability (the second group server) Request to assign a global multicast address to D1 and D2.
  • Step 504 The M2M platform N1 returns an allocated global multicast address according to the request of G1.
  • Step 505 The M2M gateway G1 allocates the global multicast address applied from the N1 to D1 and D2, and establishes a mapping relationship related to the global multicast address.
  • the M2M gateway G1 allocates the global multicast address applied from the N1 to D1 and D2, and establishes a mapping relationship related to the global multicast address.
  • Steps 506 and 506-a the M2M gateway G1 sends a group advertisement to the member devices D1 and D2 to join the multicast group, to indicate that D1 and D2 join the multicast group corresponding to the multicast address.
  • the group advertisements added to the multicast group may be sent to the D1 and the D2 one by one in a unicast manner; or may be sent to the multicast group that has been previously joined by the member devices D1 and D2 in a multicast manner.
  • step 204 refer to the related description of step 204, and the embodiments of the present invention are not described in detail herein.
  • step 507 and step 507-a the member devices D1 and D2 join the multicast group corresponding to the multicast address indicated in the multicast group advertisement by using a multicast management protocol such as MLD or IGMP according to the method in the prior art.
  • MLD multicast management protocol
  • IGMP multicast management protocol
  • Step 508 The group resource identifiers in steps 406-410 are replaced by Grpll, and the member resources are mill, mll2, and the rest are the same.
  • FIG. 6 is a group resource access by using a remotely allocated multicast address according to an embodiment of the present invention.
  • the flow chart of the method includes the following steps:
  • Steps 601-602 are the same as steps 501 and 502, and embodiments of the present invention are not described in detail herein.
  • the M2M gateway G1 determines that the member devices D1 and D2 to which the member resources mlO1 and ml02 belong belong to the M2M platform N1 (ie, D1 and D2 are registered to N1), requesting to create a second group on the M2M platform N1 (second group server).
  • the group resource Grpl2 the second group resource Grpl2 contains the member resources mill and mll2 on the member devices D1 and D2.
  • N1 acts as a remote group server (ie, a second group server).
  • Step 604 The M2M platform N1 locally creates the group resource Grpl2 according to the prior art.
  • Step 605 The M2M platform N1 returns to the M2M gateway G1 to create a group resource Grpl2 to create a successful response, which includes the access identifier URI of Grpl2.
  • Step 606 The M2M gateway G1 establishes a mapping relationship for the member resources, and uses the URI of Grpl2 as the fanout URI of the member resources mill and mll2 in the Grpll, and uses the network address of N1 (which may be unicast or multicast) as its multicast address. .
  • N1 which may be unicast or multicast
  • G1 can allocate a local multicast address for N1
  • the multicast address in the mapping relationship can be set to the allocated local multicast address.
  • Step 607 The M2M platform N1 allocates the same local or global multicast address to the member devices D1 and D2, and establishes a mapping relationship related to the local or global multicast address. Specifically, refer to the related description of Figure 2-C.
  • the M2M platform N1 needs to analyze the characteristics of the created group resource Grpl2 and its member resources mill and mll2, and determine that a multicast group can be established for it. .
  • the M2M platform N1 needs to analyze the characteristics of the created group resource Grpl2 and its member resources mill and mll2, and determine that a multicast group can be established for it. .
  • Step 607 may be performed after step 605, or may be performed before step 605, and may also be performed at the same time. Detailed.
  • Steps 608 and 608-a the M2M platform N1 sends a group advertisement to the member devices D1 and D2 to join the multicast group, to indicate that D1 and D2 join the multicast group corresponding to the multicast address.
  • the group advertisements added to the multicast group may be sent to the D1 and the D2 one by one in a unicast manner; or may be sent to the multicast group that has been previously joined by the member devices D1 and D2 in a multicast manner.
  • step 204 refer to the related description of step 204, and the embodiments of the present invention are not described in detail herein.
  • Step 609 and step 609-a are the same as step 507 and step 507-a, and the present invention will not be described in detail herein.
  • Step 610 The network application server NA1 sends an access request to the member resource to the M2M gateway G1, requesting access to all member resources mill and mll2 in the group resource Grpll.
  • the network application server NA1 sends an access request to the member resource to the M2M gateway G1, requesting access to all member resources mill and mll2 in the group resource Grpll.
  • Step 611 The M2M gateway G1 determines that the member resources of the group resource Grp11 are mapped by the group resource identifier Grp11, constructs a first member resource access request, and sends the member resource access request to the mapping relationship by using a multicast manner.
  • the broadcast address (the network address of the M2M platform N1), and the fanout URI of the first member resource access request is the URI of the Grpll. If Grpll also includes other local member resources, the M2M gateway G1 can send unicast or multicast access requests to other local member devices, and details are not described here.
  • Step 612 The M2M platform N1 determines, according to the fan-out URI of the first member resource access request (that is, the URI of the Grpll), that a mapping relationship is established for the member resources of the Grpll, and constructs a second member resource access request according to the established mapping relationship, and then adopts multiple The broadcast mode is sent to the multicast address corresponding to Grpll. Specifically, the execution of this step is the same as that of step 407, and the embodiments of the present invention are not described in detail herein.
  • Steps 613-615 are the same as described in steps 408-410, except for specific member resources and receipts.
  • the embodiments of the present invention are not described in detail herein except that the member devices that send messages are different.
  • Steps 615-617 are the same as those described in steps 409-410, and embodiments of the present invention are not described in detail herein.
  • FIG. 7 is a group server according to an embodiment of the present invention.
  • the group server in the M2M may be an M2M platform, an M2M gateway, or an M2M device. That is, in the M2M network, as long as there is a service middleware, devices, gateways, and peace stations that can store and maintain group resources can be used as group servers.
  • the group server shown in FIG. 7 includes a receiving module 701, an obtaining module 702, a sending module 703, and a processing module 704. specific,
  • the receiving module 701 is configured to receive an access request for the member resource, where the access request for the member resource carries the group resource identifier of the group resource to which the member resource belongs, and the obtaining module 702 is configured to obtain, according to the group resource identifier a fan-out URI corresponding to the fan-out URI, and a multicast address corresponding to the member resource, where the fan-out URI is used to indicate an access path of the member resource on the member device, and a sending module 703, configured to: Sending a member resource access request to the member device to which the member resource belongs according to the multicast address, where the destination URI of the member resource access request includes a fan-out URI corresponding to the member resource, so that the member to which the member resource belongs The device performs an operation indicated by the member resource access request according to an access path of the member resource indicated by the fanout URI on the member device.
  • the receiving module 701 is further configured to receive a group resource creation request, where the group resource creation request includes a member resource, where the member resource includes a member device to which the member resource belongs and member resources are on the member device.
  • the grouping server further includes a processing module 704, configured to allocate a multicast address to the member resource according to a member device to which the member resource belongs and an access path of the member resource on the member device, and the member device according to the member resource The upper access path establishes a mapping relationship between the multicast address and the fan-out URI.
  • the processing module 704 is specifically configured to: allocate a multicast address for a member resource having the same access path on the member device, and establish a mapping between the multicast address and the fan-out URI.
  • the fanout URI is an access path of the member resource on the member device; and/or is configured to allocate a virtual identifier to the at least one member resource for the at least one member resource having different access paths on the member device. Allocating a multicast address, and establishing a mapping relationship between the multicast address and the virtual identifier and a mapping relationship between the virtual identifier and a member resource; setting the virtual identifier as the fan-out URI.
  • the sending module 703 is further configured to: send, according to the mapping relationship between the multicast address and the fan-out URI, a group advertisement that joins the multicast group to the member device to which the member resource belongs, where the group that joins the multicast group The advertisement carries the multicast address, so that the member device to which the member resource belongs is added to the multicast group corresponding to the multicast address according to the group advertisement that joins the multicast group.
  • the processing module 704 allocates a multicast address to the member resource according to the member device to which the member resource belongs and the access path of the member resource on the member device, where the member resource is determined according to the member device to which the member resource belongs.
  • the member device belongs to the first group server, and the member device to which the member resource belongs is assigned a multicast address of the local multicast domain; or the member device to which the member resource belongs is determined that the member devices to which the member resource belongs are not all attributed to the first
  • a group server allocates a multicast address of the global multicast domain to the member device to which the member resource belongs or requests to allocate a multicast address of the remote multicast domain to the member device to which the member resource not belonging to the first group server belongs.
  • the processing module 704 allocates a multicast address of the global multicast domain to the member device to which the member resource belongs, specifically: requesting, by the group server having the multicast address of the global multicast domain, a multicast address of the global multicast domain, The multicast address of the global multicast domain of the application is allocated to the member device to which the member resource belongs; the multicast address of the remote multicast domain that is requested by the member device that is not attributed to the member resource of the first group server is specifically: Determining that the member device to which the member resource not belonging to the first group server belongs belongs to the second group server, and sending a second group resource request to the second group server, where the second group resource request is carried a group resource identifier and a member resource, where the member resource includes a member device to which the member resource belongs and an access path of the member resource on the member device; the second group server is based on the member device to which the member resource belongs and The access path of member resources on the member device creates a second group resource and assigns a
  • the processing module 704 allocates a multicast address to the member resource according to the member device to which the member resource belongs, and the method includes: determining, according to the member device to which the member resource belongs, the network device to which the member device and the member device to which the member resource belongs Broadcasting, and allocating a multicast address to the member resource; the processing module 704 is further configured to: store a member resource corresponding to the member device that does not have the multicast capability, so that the group server is a member device that does not have the multicast capability Unicast access requests to member resources.
  • the processing module 704 is further configured to: set a destination address of the access request for the member resource to a multicast address corresponding to the fanout URI, and set a destination URI of the access request for the member resource to the a fanout URI corresponding to the member resource, to generate a member resource access request, and also used to send, by using the multicast address, a member resource access request that carries the fanout URI corresponding to the member resource.
  • the processing module 704 is further configured to: determine that the destination URI in the access request for the member resource further includes a suffix; and set a destination address of the access request for the member resource to a multicast address corresponding to the fanout UIR, The destination URI of the access request for the member resource is set to the fan-out URI corresponding to the member resource, and the suffix included in the destination URI is added after the fan-out URI to generate a member resource access request.
  • the receiving module 701 is further configured to receive a group resource update request for adding a member resource, where the group resource update request for adding the member resource carries the identifier of the group resource and the member resource that needs to join the group resource, where The member resources that need to be added to the group resource include the member device to which the member resource belongs and the access path of the member resource on the member device.
  • the processing module 704 is further configured to determine, according to the identifier of the group resource, that the group resource needs to be added.
  • the member resource is the same as the fan-out URI in the mapping relationship between the multicast address and the fan-out URI in the group resource corresponding to the identifier of the group resource, and is required to join the group resource.
  • the member device to which the member resource belongs sends the multicast address in the mapping relationship carrying the multicast address and the fanout URI. Entering a group advertisement of the multicast group, so that the member device to which the member resource that needs to join the group resource belongs to join the multicast group through the multicast address, and receiving the member resource access request sent by using the multicast address;
  • the processing module 704 is further configured to determine, according to the identifier of the group resource, the access path of the member resource that needs to join the group resource on the member device, and the multicast resource in the group resource corresponding to the identifier of the group resource.
  • the fan-out URI in the mapping relationship between the address and the fan-out URI is different.
  • the member resources to be added to the group resource are added to the mapping relationship between the fan-out URI and the member resource in the group resource corresponding to the identifier of the group resource.
  • the member device to which the member resource to be added to the group resource belongs sends a group advertisement that joins the multicast group, and the group advertisement that joins the multicast group carries the multicast in the group resource corresponding to the identifier of the group resource.
  • a mapping relationship between the address and the fanout URI, and a mapping relationship between the fanout URI and the access path of the member resource on the member device so that the member device receives the access request carrying the fanout URI, according to the received fan
  • the mapping relationship between the URI and the member resource determines the access path of the member resource in the member device, and performs the access path according to the determined member resource on the member device. Should a member resource access request.
  • the receiving module 701 is further configured to receive a group resource update request for deleting the member resource, where the group resource update request for deleting the member resource carries the identifier of the member resource and the group resource that needs to leave the group resource, where The member resource that needs to leave the group resource includes the member device to which the member resource belongs and the access path of the member resource on the member device.
  • the processing module is further configured to: determine, according to the identifier of the group resource, that the group resource needs to leave The fan-out URI corresponding to the member resource, and the mapping relationship between the fan-out URI and the multicast address corresponding to the member resource that needs to leave the group resource, and delete the member resource in the mapping relationship that needs to leave the group resource, and leave the group resource
  • the member device to which the member resource belongs sends a group advertisement of the leaving multicast group carrying the multicast address in the mapping relationship between the fan-out URI and the multicast address corresponding to the member resource that needs to leave the group resource, so as to facilitate the member to leave
  • the member device to which the resource belongs leaves the multicast group indicated by the multicast address;
  • the receiving module is further configured to receive a group resource update request for deleting the member resource, where the group resource update request of the deleted member resource carries the member resource of the group resource to be reserved An identifier of the group resource, where the member resource of the group resource to be reserved includes a member device to which the member resource belongs and an access path of the member resource on the member device; the processing module is further configured to determine, according to the identifier of the group resource And the member resource of the member resource that needs to leave the group resource and the member resource of the fanout UIR are updated by using the member resource of the group resource that needs to be reserved; The member device to which the member resource belongs sends a group advertisement of the leaving multicast group carrying the multicast address in the mapping relationship, so that the member device to which the member resource to be removed belongs belongs to the multicast group indicated by the multicast address.
  • the processing module 704 is further configured to: determine, according to the identifier of the group resource that the group resource update request of the member resource is deleted, the access path of the member resource that needs to leave the group resource on the member device and the member resource that needs to leave The fanout URI is different; the group advertisement leaving the multicast group further includes the fanout URI corresponding to the member resource that needs to leave the group resource; so that the member device to which the member resource that needs to leave the group resource belongs The multicast group indicated by the multicast address, and the group resource update of the member device and the deleted member resource are deleted according to the fan-out URI in the member resource that needs to leave the group resource and the group advertisement that leaves the multicast group.
  • the member resource in the multicast group information corresponding to the identifier of the requested group resource.
  • FIG. 8 is a member device according to an embodiment of the present invention, which may be an M2M platform, an M2M gateway, or an M2M device. That is, in an M2M network, devices, gateways, and platforms that store resources can be used as member devices.
  • the member device includes: a receiving module 801 and an operating module 802.
  • the receiving module 801 is configured to receive a member resource access request sent by the group server, where the member resource access request is a multicast member resource access request, where the member resource access request includes the member resource corresponding to the member resource.
  • a fanout URI the fanout URI is used to indicate an access path of the member resource on the member device
  • the operation module 802 is configured to determine, according to the fanout URI, an access path of the member resource on the member device, and according to the member The access path of the resource on the member device performs the operation of the access request.
  • the receiving module 801 is further configured to: receive a group advertisement that joins the multicast group, where The group advertisement that joins the multicast group carries the multicast address, and joins the multicast group corresponding to the multicast address according to the group advertisement added to the multicast group.
  • the group advertisement that is added to the multicast group further carries the mapping relationship between the fanout URI and the access path of the member resource on the member device, where the member device further includes a storage module 803, configured to store the fan. And mapping the URI to the multicast address and the mapping relationship between the member resource and the multicast address.
  • the member device further includes a determining module 804, configured to determine that the destination address of the member resource access request is a multicast address.
  • the operation module 802 determines, according to the fanout URI, an access path of the member resource on the member device, specifically: determining multicast group information that includes the same multicast address as the destination address in the member resource access request,
  • the multicast group information that determines the multicast address that is the same as the destination address in the member resource access request includes the same fan-out URI as the destination URI in the member resource access request, and determines that the multicast group information corresponds to the fan-out URI.
  • the access path of member resources on member devices specifically: determining multicast group information that includes the same multicast address as the destination address in the member resource access request.
  • the multicast group information that determines the multicast address that is the same as the destination address in the member resource access request includes the same fan-out URI as the destination URI in the member resource access request, and determines that the multicast group information corresponds to the fan-out URI.
  • the access path of member resources on member devices specifically: determining multicast group information that includes the same multicast address as the destination
  • the operation module 802 performs an operation of performing an access request according to the access path of the member resource on the member device, where the fan URI included in the destination URI in the member resource access request is determined by using the determined member resource.
  • the access path on the device is replaced, and the operation of the access request is performed for the member resource corresponding to the determined access path of the member resource on the member device.
  • the receiving module 801 is further configured to: receive a group advertisement that leaves the multicast group, where the group advertisement that leaves the multicast group carries a multicast address; the storage module 803 is further configured to: delete the stored and left And multicast group information corresponding to the multicast address with the same multicast address in the group advertisement of the broadcast group, and exiting the multicast group corresponding to the multicast address in the group advertisement leaving the multicast group.
  • the receiving module 801 is further configured to: receive a group advertisement that leaves the multicast group, where the group advertisement that leaves the multicast group carries a multicast address and a member resource that needs to leave, and the member resource that needs to leave The member device that belongs to the member resource that needs to leave the group resource and the access path of the member resource on the member device; the storage module 803 is further configured to delete the stored and the leaving The multicast group information of the multicast address having the same multicast address in the group advertisement of the multicast group needs to leave the member resource of the group resource; and deleting the stored group notification with the leaving multicast group Multicast group information of the same multicast address is broadcasted, and the multicast group corresponding to the multicast address in the group advertisement leaving the multicast group is exited.
  • the storage module 803 deletes the stored multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group, and exits the group advertisement of the leaving multicast group. Before the multicast group corresponding to the multicast address, it is also required to determine that the fan-out URI in the multicast group information of the multicast address that is the same as the multicast address in the group advertisement of the leaving multicast group does not correspond to the member.
  • the M2M platform may be a computer, a device having a processor.
  • the M2M gateway and the M2M terminal are not strictly distinguished on the device.
  • the gateway device can also be used as a terminal, and also for various terminal devices, such as mobile phones, computers, PDAs, notebook computers, remote controllers, household appliances, various Instrumentation, sensors, etc. can be used as gateways or terminals for M2M networks.
  • the included units are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be implemented; in addition, the specific names of the functional units are only for convenience. They are distinguished from each other and are not intended to limit the scope of protection of the present invention.
  • the method for implementing the member device and the function of each function module of the member device can be completed by the processor of the member device, and the method for implementing the group server and the function of each function module of the group server can be performed by the group server.
  • the processor is complete.
  • the mapping relationship between the access path of the member resource on the member device and the fanout URI is established, and the fanout URI is included in the member access request.
  • the member device to which the member resource belongs performs the operation indicated by the member access request according to the access path of the member resource indicated by the fanout URI on the member device. So that different member devices can use the fanout URI by using multicast technology, and parse multiple Broadcast access requests to member resources, and subsequent operations on access requests. Therefore, the group server does not need to unicast access requests to member devices, thereby saving network overhead.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Selective Calling Equipment (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明提供了一种成员资源的访问方法，群组服务器和成员设备，通过建立的群组资源中多播地址与扇出URI的映射关系，可以向群组资源中的成员资源所在的成员设备通过多播的方式发送成员资源访问请求，并在成员资源访问请求中包含所述扇出URI；以便所述成员资源所属的成员设备根据所述扇出URI指示的所述成员资源在成员设备上的访问路径执行所述成员访问请求指示的操作。从而使得群组服务器不需要对各成员设备单播访问请求，节省网络开销。

Description

成员资源的访问方法、 群组服务器和成员设备 本申请要求于 201 2年 01月 6 日提交中国专利局、 申请号为
20121 00041 35. 6 , 发明名称为 "成员资源的访问方法、 群组服务器和成员 设备"， 的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域 本发明涉及机器通信 ( Machine-to-Machine Communications, M2M )技 术领域， 尤其涉及成员资源的访问方法、 群组服务器和成员设备。
背景技术 机器通信 ( Machine-to-Machine Communications, M2M )是一种以机器 智能交互为核心的、 网络化的应用与服务。 M2M技术通过在机器内部嵌入 无线或有线通信模块以及应用处理逻辑， 实现无需人工干预的数据通信， 以满足用户对监控、 指挥调度、 数据采集和测量等方面的信息化需求。 在 M2M系统架构中， 各种 M2M终端 （如传感器、 微控制器等） 直接或经过 M2M网关远程接入到 M2M业务平台，而各种 M2M应用服务器（如电力抄表、 智能交通等 )则通过 M2M业务平台所提供的业务能力获取 M2M终端采集的 数据或对 M2M终端进行远程的控制和管理。
然而， 在一些常见的 M2M业务中， 往往需要同时对大量的 M2M终端 / 网关进行相同的业务操作， 比如同时读取一个小区内所有住户家中的电表 读数， 或者同时控制开关一栋建筑内的所有照明或者空调设施等。 在这种 情况下，由于群组通信能够避免 M2M应用向各 M2M终端 /网关重复发送相同 的业务操作请求， 从而节约大量的通信开销， 而变得尤其重要。
现有技术中描述了一种面向资源的群组通信方法。 该方法中， M2M应 用月良务器、 M2M平台、 M2M终端、 M2M网关、 包括 M2M终端和 M2M网关 上所运行的所有本地应用、数据对象均被看做一种 RESTfuK Representational State Transfer, 表述性状态转移） 资源， 并由一个 URI ( Universal Resource Identifier, 通用资源标识符）唯一标识。 通过构建以上述各种资源为成员资 源的群组资源， 能够实现对多个成员资源的群组化操作。 也就是说， 通过 构成群组资源， 所述的群组资源包含各成员资源的相关信息， 如成员资源 的访问路径， 所属设备的名称， 访问地址等， 实现对多个成员资源的群组 化操作。 例如， 将所有目标电表（M2M设备）上的读数资源作为群组的成 员资源， 则 M2M应用服务器可以向维护群组资源的实体（以下称群组服务 器， 可以是 M2M平台、 M2M网关、 M2M终端中的任意一个）发送针对该群 组资源的一个读取请求， 群组服务器负责将请求逐一转发到每个目标电表 上，并将读取结果合并为一个响应消息返回给 M2M应用服务器。这样， M2M 应用服务器可通过一次性读取该群组资源来获得所有成员资源 （即电表读 数内容） 。 该方法所采用的具体通信协议可以是 HTTP ( HyperText Transfer Protocol, 超文本传输协议 )协议或 CoAP ( Constrained Application Protocol, 受限应用协议）协议。
然而， 现有的应用于 M2M的群组通信的方法， 仅仅节约了 M2M应用服 务器与群组服务器之间的通信， 而群组服务器仍然需要对每个 M2M设备单 独发送请求。 如果群组服务器能力有限（比如 M2M网关） ， 或者其与 M2M 设备间的网络带宽较小或通信费用较高， 则该方法中群组服务器与 M2M设 备间的通信并不经济。
发明内容
本发明的实施例提供的成员资源的访问方法、 群组服务器和成员设备， 能够实现不需要对各成员设备单播访问请求， 节省网络开销。
本发明的一方面提供了一种成员资源的访问方法,包括：
接收对成员资源的访问请求， 所述对成员资源的访问请求中携带成员 资源所属群组资源的群组资源标识； 根据所述群组资源标识获取群组资源 中与成员资源对应的扇出通用资源标识符 URI, 以及与所述扇出 URI对应的 多播地址， 所述扇出 URI用于指示成员资源在成员设备上的访问路径； 根据 所述多播地址向所述成员资源所属的成员设备发送成员资源访问请求， 所 述成员资源访问请求的目的 URI包含与所述成员资源对应的扇出 URI; 以便 所述成员资源所属的成员设备根据所述扇出 URI指示的成员资源在成员设 备上的访问路径执行所述成员资源访问请求指示的操作。
可选的， 该方法进一步包括： 接收群组资源创建请求， 所述群组资源 创建请求中携带各成员资源， 所述成员资源包括所述成员资源所属的成员 设备以及成员资源在成员设备上的访问路径； 根据所述成员资源所属的成 员设备以及成员资源在成员设备上的访问路径为所述成员资源分配多播地 址； 根据成员资源在成员设备上的访问路径建立所述多播地址和所述扇出 URI的映射关系。
可选的， 所述根据成员资源所属的成员设备以及成员资源在成员设备 上的访问路径为所述成员资源分配多播地址， 以及根据成员资源在成员设 备上的访问路径建立所述多播地址及所述扇出 URI之间的映射关系具体为： 为在成员设备上具有相同访问路径的成员资源分配多播地址， 并建立所述 多播地址及所述扇出 URI的映射关系； 所述扇出 URI为所述成员资源在成员 设备上的访问路径； 和 /或为在成员设备上具有不同访问路径的至少一个成 员资源分配虚拟标识， 为所述至少一个成员资源分配多播地址， 并为建立 所述多播地址及所述虚拟标识的映射关系以及所述虚拟标识和成员资源的 映射关系； 将所述虚拟标识设为所述扇出 URI。
可选的， 该方法进一步包括： 根据所述多播地址及所述扇出 URI的映射 关系向成员资源所属的成员设备发送加入多播组的群组通告， 所述加入多 播组的群组通告中携带多播地址， 以便于成员资源所属的成员设备根据加 入多播组的群组通告加入与所述多播地址对应的多播组。
可选的， 所述加入多播组的群组通告中还携带所述所述扇出 URI和成员 资源的映射关系，以便所述成员资源所属的成员设备存储所述扇出 URI和所 述多播地址映射关系， 以及所述成员资源和所述多播地址的映射关系； 所 述以便所述成员资源所属的成员设备根据所述扇出 URI指示的成员资源在 成员设备上的访问路径执行所述成员资源访问请求指示的操作具体为： 所 述成员资源所属的成员设备在接收到携带所述扇出 URI的访问请求后，根据 接收到的所述扇出 URI以及根据所述扇出 URI和成员资源映射关系确定成 员资源在成员设备上的访问路径， 并根据确定的成员资源在成员设备上的 访问路径执行相应的成员资源访问请求。
可选的， 所述根据成员资源所属的成员设备以及成员资源在成员设备上 的访问路径为所述成员资源分配多播地址具体为： 根据所述成员资源所属 的成员设备确定所述成员资源所属的成员设备归属于第一群组服务器， 为 成员资源所属的成员设备分配本地多播域的多播地址； 或根据所述成员资 源所属的成员设备确定所述群组资源的成员资源所属的成员设备并不都归 属于第一群组服务器， 为成员资源所属的成员设备分配全局多播域的多播 地址或请求为不归属于第一群组服务器的成员资源所属的成员设备分配远 程多播域的多播地址。
可选的， 所述为成员资源所属的成员设备分配全局多播域的多播地址具 体为： 向具有全局多播域的多播地址的群组服务器申请全局多播域的多播 地址， 为成员资源所属的成员设备分配申请的全局多播域的多播地址； 所 述请求为不归属于第一群组服务器的成员资源所属的成员设备分配远程多 播域的多播地址具体为： 确定不归属于第一群组服务器的成员资源所属的 成员设备归属于第二群组服务器， 向第二群组服务器发送创建第二群组资 源请求， 所述创建第二群组资源请求携带第一群组资源标识以及成员资源， 所述成员资源包含成员资源所属的成员设备以及成员资源在成员设备上的 访问路径； 第二群组服务器根据所述成员资源所属的成员设备创建第二群 组资源以及为成员资源分配多播地址。
可选的， 所述根据成员资源所属的成员设备以及成员资源在成员设备上 的访问路径为所述成员资源分配多播地址具体为： 根据所述成员资源所属 的成员设备确定所述成员资源所属的成员设备和成员设备所属的网络支持 多播， 并为所述成员资源分配多播地址； 所述方法还包括： 存储不具有多 播能力的成员设备对应的成员资源， 以便于群组服务器为不具有多播能力 的成员设备单播对成员资源的访问请求。 扇出 URI以及与所述扇出 URI对应的多播地址之后， 该方法还包括： 将对成 员资源的访问请求的目的地址设置为与所述扇出 URI对应的多播地址，将对 成员资源的访问请求的目的 URI设为所述与成员资源对应的扇出 URI, 以生 成成员资源访问请求； 利用所述多播地址发送携带所述与成员资源对应的 扇出 URI的成员资源访问请求。 扇出 URI以及与所述扇出 URI对应的多播地址之后， 该方法还包括： 确定所 述对成员资源的访问请求中的目的 URI还包含后缀；将对成员资源的访问请 求的目的地址设置为与所述扇出 UIR对应的多播地址， 将所述目的 URI设为 所述与成员资源对应的扇出 URI以及在所述扇出 URI后面添加所述目的 URI 包含的后缀， 以生成成员资源访问请求。
可选的， 该方法还包括： 接收增加成员资源的群组资源更新请求， 所述 增加成员资源的群组资源更新请求中携带群组资源的标识以及需加入群组 资源的成员资源， 所述需加入群组资源的成员资源包括所述成员资源所属 的成员设备以及成员资源在成员设备上的访问路径； 根据群组资源的标识 确定需加入群组资源的成员资源在成员设备上的访问路径和与群组资源的 标识对应的群组资源中的所述多播地址和扇出 URI的映射关系中的扇出 URI相同，向需加入群组资源的成员资源所属的成员设备发送携带所述多播 地址和扇出 URI的映射关系中的多播地址的加入多播组的群组通告，以便于 需加入群组资源的成员资源所属的成员设备通过所述多播地址加入多播 组， 以及接收通过多播地址发送的成员资源访问请求； 或根据群组资源的 标识确定需加入群组资源的成员资源在成员设备上的访问路径和与群组资 源的标识对应的群组资源中的所述多播地址和扇出 URI的映射关系中的扇 出 URI不同； 在与群组资源的标识对应的群组资源中的扇出 URI和成员资源 的映射关系中增加需加入群组资源的成员资源， 向需加入群组资源的成员 资源所属的成员设备发送加入多播组的群组通告， 所述加入多播组的群组 通告携带与群组资源的标识对应的群组资源中的所述多播地址和扇出 URI 的映射关系，和与群组资源的标识对应的群组资源中的扇出 URI和成员资源 的映射关系； 以便于成员设备在接收到携带所述扇出 URI的访问请求后，根 据接收到的扇出 URI与成员资源的映射关系确定成员资源在成员设备上的 访问路径， 并根据确定的成员资源在成员设备上的访问路径执行相应的成 员资源访问请求。
可选的， 该方法还包括： 接收删除成员资源的群组资源更新请求， 所述 删除成员资源的群组资源更新请求中携带需离开群组资源的成员资源和群 组资源的标识， 所述需离开群组资源的成员资源包括所述成员资源所属的 成员设备以及成员资源在成员设备上的访问路径； 根据群组资源的标识确 定与需离开群组资源的成员资源对应的扇出 URI,以及与需离开群组资源的 成员资源对应的扇出 URI和多播地址的映射关系，删除所述与需离开群组资 源的成员资源对应的扇出 URI和多播地址的映射关系中的需离开群组资源 的成员资源， 向需离开的成员资源所属的成员设备发送携带与需离开群组 资源的成员资源对应扇出 URI和多播地址的映射关系中的多播地址的离开 多播组的群组通告， 以便于需离开的成员资源所属的成员设备离开所述多 播地址指示的多播组； 或删除成员资源的群组资源更新请求中携带需保留 的群组资源的成员资源和群组资源的标识， 所述需保留的群组资源的成员 资源包含成员资源所属的成员设备以及成员资源在成员设备上的访问路 径；根据群组资源的标识确定与需离开群组资源的成员资源和扇出 UIR的映 射关系， 利用需保留的群组资源的成员资源更新所述需离开群组资源的成 员资源和扇出 UIR的映射关系中成员资源，向需离开的成员资源所属的成员 设备发送携带映射关系中的多播地址的离开多播组的群组通告， 以便于需 离开的成员资源所属的成员设备离开所述多播地址指示的多播组。
可选的， 该方法进一步包括： 根据删除成员资源的群组资源更新请求 的群组资源的标识确定需离开群组资源的成员资源在成员设备上的的访问 路径和需离开的成员资源对应的扇出 URI不同；所述离开多播组的群组通告 还包括与需离开群组资源的成员资源对应的所述扇出 URI; 以便于需离开群 组资源的成员资源所属的成员设备离开所述多播地址指示的多播组， 并根 据所述需离开群组资源的成员资源和离开多播组的群组通告中的扇出 URI 删除成员设备中与删除成员资源的群组资源更新请求的群组资源的标识对 应的多播组信息中的成员资源。
此外， 本发明另一方面还提供了一种群组资源的访问方法， 包括： 接收 群组服务器发送的成员资源访问请求， 所述成员资源访问请求为多播的成 员资源访问请求， 所述成员资源访问请求中包含与所述成员资源对应的扇 出 URI, 所述扇出 URI用于指示成员资源在成员设备上的访问路径； 根据所 述扇出 URI确定成员资源在成员设备上的访问路径，以及根据所述成员资源 在成员设备上的访问路径执行访问请求的操作。
可选的， 该方法进一步包括： 接收加入多播组的群组通告， 所述加入多 播组的群组通告中携带多播地址， 根据加入多播组的群组通告加入与所述 多播地址对应的多播组。
可选的， 所述加入多播组的群组通告中还携带所述扇出 URI和成员资源 的映射关系； 所述方法进一步包括： 存储所述多播地址和所述扇出 URI的 映射关系， 以及所述成员资源和所述多播地址的映射关系。
可选的， 该方法进一步包括： 确定成员资源访问请求的目的地址为多播 地址。 可选的， 所述根据所述扇出 URI确定成员资源在成员设备上的访问路径 具体为：
确定包含与成员资源访问请求中的目的地址相同的多播地址的多播组 信息， 确定与成员资源访问请求中的目的地址相同的多播地址的多播组信 息中包含与所述成员资源访问请求中的目的 URI相同的扇出 URI, 确定多播 组信息中与扇出 URI对应的成员资源在成员设备上的访问路径。
可选的， 所述根据所述成员资源在成员设备上的访问路径执行访问请求 的操作具体为： 将所述成员资源访问请求中的目的 URI包含的扇出 URI用确 定的成员资源在成员设备上的访问路径替换， 并针对与确定的成员资源在 成员设备上的访问路径对应的成员资源执行访问请求的操作。
可选的， 该方法进一步包括： 接收离开多播组的群组通告， 所述离开多 播组的群组通告中携带多播地址； 删除存储的与离开多播组的群组通告中 的多播地址相同的多播地址对应的多播组信息， 并退出所述离开多播组的 群组通告中的多播地址对应的多播组。
可选的， 该方法进一步包括： 接收离开多播组的群组通告， 所述离开多 播组的群组通告中携带需离开的多播组对应的多播地址以及需离开群组资 源的成员资源， 所述需离开的成员资源包含需离开群组资源的成员资源所 属的成员设备以及成员资源在成员设备上的访问路径； 删除存储的与所述 离开多播组的群组通告中的多播地址相同的多播地址的多播组信息中需离 开群组资源的成员资源； 删除存储的与所述离开多播组的群组通告中的多 播地址相同的多播地址的多播组信息， 并退出所述离开多播组的群组通告 中的多播地址对应的多播组。
可选的， 该方法进一步包括： 确定存储的与所述离开多播组的群组通告 中的多播地址相同的多播地址的多播组信息中的扇出 URI不对应成员资源。
此外， 本发明另一方面还提供了一种群组服务器， 包括： 接收模块， 用 于接收对成员资源的访问请求， 所述对成员资源的访问请求中携带成员资 源所属群组资源的群组资源标识； 获取模块， 用于根据所述群组资源标识 获取群组资源中与成员资源对应的扇出 URI, 以及与所述扇出 URI对应的多 播地址， 所述扇出 URI用于指示成员资源在成员设备上的访问路径； 发送模 块， 用于根据所述多播地址向所述成员资源所属的成员设备发送成员资源 访问请求，所述成员资源访问请求的目的 URI包含与所述成员资源对应的扇 出 URI; 以便所述成员资源所属的成员设备根据所述扇出 URI指示的成员资 源在成员设备上的访问路径执行所述成员资源访问请求指示的操作。
可选的， 所述接收模块进一步用于接收群组资源创建请求， 所述群组资 源创建请求中携带各成员资源， 所述成员资源包括所述成员资源所属的成 员设备以及成员资源在成员设备上的访问路径； 所述群组服务器还包括： 处理模块， 用于根据所述成员资源所属的成员设备以及成员资源在成员设 备上的访问路径为所述成员资源分配多播地址； 以及根据成员资源在成员 设备上的访问路径建立所述多播地址及所述扇出 URI之间的映射关系。
可选的， 所述处理模块具体为： 用于为在成员设备上具有相同访问路径 的成员资源分配多播地址， 并建立所述多播地址及所述扇出 URI的映射关 系； 所述扇出 URI为所述成员资源在成员设备上的访问路径； 和 /或用于为 在成员设备上具有不同访问路径的至少一个成员资源分配虚拟标识， 为所 述至少一个成员资源分配多播地址， 并建立所述多播地址及所述虚拟标识 的映射关系以及所述虚拟标识和成员资源的映射关系； 将所述虚拟标识设 为所述扇出 URI。
可选的， 所述发送模块进一步用于： 根据所述多播地址及所述扇出 URI 的映射关系向成员资源所属的成员设备发送加入多播组的群组通告， 所述 加入多播组的群组通告中携带多播地址， 以便于成员资源所属的成员设备 根据加入多播组的群组通告加入与所述多播地址对应的多播组。
可选的， 所述处理模块根据成员资源所属的成员设备以及成员资源在成 员设备上的访问路径为所述成员资源分配多播地址具体为： 根据所述成员 资源所属的成员设备确定所述成员资源所属的成员设备归属于第一群组服 务器， 为成员资源所属的成员设备分配本地多播域的多播地址； 或根据所 述成员资源所属的成员设备确定所述群组资源的成员资源所属的成员设备 并不都归属于第一群组服务器， 为成员资源所属的成员设备分配全局多播 域的多播地址或请求为不归属于第一群组服务器的成员资源所属的成员设 备分配远程多播域的多播地址。
可选的， 所述处理模块为成员资源所属的成员设备分配全局多播域的多 播地址具体为： 向具有全局多播域的多播地址的群组服务器申请全局多播 域的多播地址， 为成员资源所属的成员设备分配申请的全局多播域的多播 地址； 所述请求为不归属于第一群组服务器的成员资源所属的成员设备分 配远程多播域的多播地址具体为： 确定不归属于第一群组服务器的成员资 源所属的成员设备归属于第二群组服务器， 向第二群组服务器发送创建第 二群组资源请求， 所述创建第二群组资源请求携带第一群组资源标识以及 成员资源， 所述成员资源包含成员资源所属的成员设备以及成员资源在成 员设备上的访问路径； 第二群组服务器根据成员资源所属的成员设备以及 成员资源在成员设备上的访问路径创建第二群组资源以及为成员资源分配 多播地址。
可选的， 所述处理模块根据成员资源所属的成员设备为所述成员资源分 配多播地址具体为： 根据成员资源所属的成员设备确定所述成员资源所属 的成员设备和成员设备所属的网络支持多播， 并为所述成员资源分配多播 地址； 所述处理模块还用于： 存储不具有多播能力的成员设备对应的成员 资源， 以便于群组服务器为不具有多播能力的成员设备单播对成员资源的 访问请求。
可选的， 所述处理模块还用于： 将对成员资源的访问请求的目的地址设 置为与所述扇出 URI对应的多播地址， 将对成员资源的访问请求的目的 URI 设为所述与成员资源对应的扇出 URI, 以生成成员资源访问请求， 以及还用 于利用所述多播地址发送携带所述与成员资源对应的扇出 URI的成员资源 访问请求。
可选的， 所述处理模块还用于确定所述对成员资源的访问请求中的目的 URI还包含后缀； 将对成员资源的访问请求的目的地址设置与所述扇出 UIR 对应的多播地址，将对成员资源的访问请求的目的 URI设为所述与成员资源 对应的扇出 URI以及在所述扇出 URI后面添加所述目的 URI包含的后缀， 以 生成成员资源访问请求。
32、 如权利要求 25-31任一所述的群组服务器， 其特征在于，
所述接收模块还用于接收增加成员资源的群组资源更新请求， 所述增加 成员资源的群组资源更新请求中携带群组资源的标识以及需加入群组资源 的成员资源， 所述需加入群组资源的成员资源包括所述成员资源所属的成 员设备以及成员资源在成员设备上的访问路径；
所述处理模块还用于根据群组资源的标识确定需加入群组资源的成员 资源在成员设备上的访问路径和与群组资源的标识对应的群组资源中的所 述多播地址和扇出 URI的映射关系中的扇出 URI相同， 向需加入群组资源的 成员资源所属的成员设备发送携带所述多播地址和扇出 URI的映射关系中 的多播地址的加入多播组的群组通告， 以便于需加入群组资源的成员资源 所属的成员设备通过所述多播地址加入多播组， 以及接收通过多播地址发 送的成员资源访问请求； 或
所述处理模块还用于根据群组资源的标识确定需加入群组资源的成员 资源在成员设备上的访问路径和与群组资源的标识对应的群组资源中的所 述多播地址和扇出 URI的映射关系中的扇出 URI不同； 在与群组资源的标识 对应的群组资源中的扇出 URI和成员资源的映射关系中增加需加入群组资 源的成员资源， 向需加入群组资源的成员资源所属的成员设备发送加入多 播组的群组通告， 所述加入多播组的群组通告携带与群组资源的标识对应 的群组资源中的所述多播地址和扇出 URI的映射关系， 和扇出 URI与成员资 源在成员设备上的访问路径的映射关系； 以便于成员设备在接收到携带所 述扇出 URI的访问请求后， 根据接收到的扇出 URI与成员资源的映射关系确 定成员资源在成员设备的访问路径， 并根据确定的成员资源在成员设备上 的访问路径执行相应的成员资源访问请求。
可选的， 所述接收模块还用于接收删除成员资源的群组资源更新请求， 所述删除成员资源的群组资源更新请求中携带需离开群组资源的成员资源 和群组资源的标识， 所述需离开群组资源的成员资源包括所述成员资源所 属的成员设备以及成员资源在成员设备上的访问路径； 所述处理模块还用 于： 根据群组资源的标识确定与需离开群组资源的成员资源对应的扇出 URI, 以及与需离开群组资源的成员资源对应扇出 URI和多播地址的映射关 系， 删除所述映射关系中的需离开群组资源的成员资源， 向需离开的成员 资源所属的成员设备发送携带与需离开群组资源的成员资源对应扇出 URI 和多播地址的映射关系中的多播地址的离开多播组的群组通告， 以便于需 离开的成员资源所属的成员设备离开所述多播地址指示的多播组； 或
所述接收模块还用于接收删除成员资源的群组资源更新请求， 所述删除 成员资源的群组资源更新请求中携带需保留的群组资源的成员资源和群组 资源的标识， 所述需保留的群组资源的成员资源包含成员资源所属的成员 设备以及成员资源在成员设备上的访问路径； 所述处理模块还用于根据群 组资源的标识确定需离开群组资源的成员资源和扇出 UIR的映射关系，利用 需保留的群组资源的成员资源更新所述需离开群组资源的成员资源和扇出 UIR的映射关系中成员资源；向需离开的成员资源所属的成员设备发送携带 映射关系中的多播地址的离开多播组的群组通告， 以便于需离开的成员资 源所属的成员设备离开所述多播地址指示的多播组。
可选的， 所述处理模块还用于： 根据删除成员资源的群组资源更新请求 的群组资源的标识确定需离开群组资源的成员资源在成员设备上的访问路 径和需离开的成员资源对应的扇出 URI不同；所述离开多播组的群组通告还 包括与需离开群组资源的成员资源对应的所述扇出 URI;以便于需离开群组 资源的成员资源所属的成员设备离开所述多播地址指示的多播组， 并根据 所述需离开群组资源的成员资源和离开多播组的群组通告中的扇出 URI删 除成员设备中与删除成员资源的群组资源更新请求的群组资源的标识对应 的多播组信息中的成员资源。
此外， 本发明又一方面还提供了一种成员设备， 包括： 接收模块， 用于 接收群组服务器发送的成员资源访问请求， 所述成员资源访问请求为多播 的成员资源访问请求， 所述成员资源访问请求中包含与所述成员资源对应 的扇出 URI, 所述扇出 URI用于指示成员资源在成员设备上的访问路径； 操 作模块， 用于根据所述扇出 URI确定成员资源在成员设备上的访问路径， 以 及根据所述成员资源在成员设备上的访问路径执行访问请求的操作。
可选的， 所述成员设备的接收模块进一步用于： 接收加入多播组的群组 通告， 所述加入多播组的群组通告中携带多播地址， 根据加入多播组的群 组通告加入与所述多播地址对应的多播组。
可选的， 所述加入多播组的群组通告中还携带所述扇出 URI和成员资源 的映射关系， 所述成员设备进一步包括： 存储模块， 用于存储所述扇出 URI 和所述多播地址映射关系以及所述成员资源和所述多播地址的映射关系。
可选的， 成员设备进一步包括： 确定模块， 用于确定成员资源访问请求 的目的地址为多播地址。
可选的， 所述成员设备的操作模块根据所述扇出 URI确定成员资源在成 员设备上的访问路径具体为： 确定包含与成员资源访问请求中的目的地址 相同的多播地址的多播组信息， 确定与成员资源访问请求中的目的地址相 同的多播地址的多播组信息中包含与所述成员资源访问请求中的目的 URI 相同的扇出 URI, 确定多播组信息中与扇出 URI对应的成员资源在成员设备 上的访问路径。
可选的， 所述成员设备的操作模块根据所述成员资源在成员设备上的访 问路径执行访问请求的操作具体为：将所述成员资源访问请求中的目的 URI 包含的扇出 URI用确定的成员资源在成员设备上的访问路径替换，并针对与 确定的成员资源在成员设备上的访问路径对应的成员资源执行访问请求的 操作。
可选的， 所述成员设备的接收模块进一步用于： 接收离开多播组的群组 通告， 所述离开多播组的群组通告中携带多播地址； 所述成员设备的存储 模块进一步用于， 删除存储的与离开多播组的群组通告中的多播地址相同 的多播地址对应的多播组信息， 并退出所述离开多播组的群组通告中的多 播地址对应的多播组。
可选的， 所述成员设备的接收模块进一步用于： 接收离开多播组的群组 通告， 所述离开多播组的群组通告中携带多播地址和需离开的成员资源， 所述需离开的成员资源包含需离开群组资源的成员资源所属的成员设备以 及成员资源在成员设备上的访问路径； 所述成员设备的存储模块进一步用 于删除存储的与所述离开多播组的群组通告中的多播地址相同的多播地址 的多播组信息中需离开群组资源的成员资源； 以及删除存储的与所述离开 多播组的群组通告中的多播地址相同的多播地址的多播组信息， 并退出所 述离开多播组的群组通告中的多播地址对应的多播组。
可选的， 所述成员设备的存储模块进一步用于确定存储的与所述离开多 播组的群组通告中的多播地址相同的多播地址的多播组信息中的扇出 URI 不对应成员资源。
由上述本发明的实施例提供的技术方案可以看出， 通过建立群组资源 中多播地址与扇出 URI的映射关系，可以向群组资源中的成员资源所在的成 员设备通过多播的方式发送成员资源访问请求， 并在成员资源访问请求中 包含所述扇出 URI; 以便所述成员资源所属的成员设备根据所述扇出 URI指 示的所述成员资源在成员设备上的访问路径执行所述成员访问请求指示的 操作。 从而使得群组服务器不需要对各成员设备单播访问请求， 节省网络 开销。 附图说明 为了更清楚地说明本发明实施例的技术方案， 下面将对实施例描述中 所需要使用的附图作筒单地介绍， 显而易见地， 下面描述中的附图仅仅是 本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳 动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明的实施例提供的群组资源访问方法的流程图；
图 2为本发明的实施例提供的创建群组资源的流程图；
图 2-A为本发明的实施例提供的建立多播组的流程图；
图 2-B为本发明的实施例提供的 M2M网络连接关系的架构示意图； 图 2-C为本发明的实施例提供的为成员设备分配多播地址并建立映射 关系的流程图；
图 2-D为本发明的实施例提供的 M2M网络连接关系的架构示意图； 图 2-E为本发明的实施例提供的 M2M网络连接关系的架构示意图； 意图；
图 2-G为本发明的实施例提供的成员设备存储的多播组资源的示意图； 图 3为本发明的实施例提供的群组资源访问方法的流程图；
图 3-A为本发明实施例提供的成员设备对接收的成员资源访问请求的 处理的方法流程图；
图 4为本发明实施例提供的通过直接分配的多播地址的群组资源访问 方法的流程图；
图 5为本发明实施例提供的通过申请的全局多播地址的群组资源访问 方法的流程图； 图 6为本发明实施例提供的通过远程分配的多播地址的群组资源访问 方法的流程图；
具体实施方式 下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进 行清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没 有作出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的 范围。 步骤 101、 接收对成员资源的访问请求， 所述对成员资源的访问请求中 携带成员资源所属群组资源的群组资源标识；
具体的， 第一群组服务器接收对成员资源的访问请求。 例如： 第一群 组服务器接收到针对群组资源标识为 Grp4 的成员资源的访问请求： GET http：〃 gl.example.org/groups/grp4/membersContent/data HTTP/1.1。 其中 grp4 为群组资源标识， "membersContent"部分表明此请求为针对 grp4对应的群 组资源中所有成员资源的操作， "data"即为所述后缀的一个实例， 用以表明 该请求具体应该访问每个成员资源的 "data"数据。
步骤 102,根据所述群组资源标识获取群组资源中与成员资源对应的扇 出 URI, 以及与与所述扇出 URI对应的多播地址， 所述扇出 URI用于指示 成员资源在成员设备上的访问路径。
具体的， 当第一群组服务器接收对成员资源的访问请求时， 首先根据 对成员资源的访问请求中的群组资源标识检查群组资源是否为建立了多播 地址及扇出 URI的映射关系， 和进一步建立了所述扇出 URI和成员资源的映 射关系， 若建立了多播地址及扇出 URI的映射关系， 则按照所述多播地址及 扇出 URI的映射关系发送成员资源访问请求到各成员设备，否则按现有技术 中的方法采用单播方式逐一发送对成员资源的第一访问请求。 对于建立了多播地址及扇出 URI的映射关系的情形， 第一群组服务器按 照所述映射关系发送成员资源访问请求到各成员设备时， 应将对成员资源 访问请求的目的地址设为多播地址及扇出 URI的映射关系中的多播地址（即 群组服务器为成员资源分配的多播地址） ， 将目的 URI设为扇出 URI。 当群 组资源包含多组多播地址及扇出 URI的映射关系时，则应针对每组多播地址 及扇出 URI的映射关系按上述方法发送一个成员资源访问请求。若第一群组 服务器所接收的对成员资源的访问请求中的目的 URI还包含任何后缀（如子 资源、 属性， 参数等用于访问成员资源中的内部信息） ， 则第一群组服务 器所发送的成员资源访问请求中的目的 URI也应在扇出 URI后面添加相应 的后缀。 具体的， 第一群组服务器需要确定所述对成员资源的访问请求中 的目的 URI还包含后缀； 则还第一群组服务器还需要所述目的 URI设为所述 与成员资源对应的扇出 URI以及在所述扇出 URI后面添加所述目的 URI包含 的后缀， 以生成成员资源访问请求。
具体的，第一群组服务器或其它的群组服务器针对各群组存储的如表 1 所示的多播地址及扇出 URI的映射关系， 和扇出 RUI和成员资源的映射关 系。
表 1: 群组资源映射表
Figure imgf000019_0001
其中， Grp4为群组资源标识； 成员资源 m41, m42 , 多播地址： [FF32:30:3FFE:FFFF:1::1231]为群组资源 Grp4中的成员资源 m41, m42分配 的多播地址； 扇出 URI: /xxx/temp 1为成员资源 m41 , m42在成员资源所属的 成员设备上的访问路径， 通常， 如表 1所示， 至少两个成员资源对应一个 多播地址和扇出 URI。
在表 1所述的实施例中， 如果群组资源 Grp4仅包含成员 m41, m42, 则表 1中的成员资源一列还可以不用包含 m41, m42。 则表一只包含扇出 URI和多 播地址的映射关系
步骤 103, 根据所述多播地址向所述成员资源所属的成员设备发送成员 资源访问请求，所述成员资源访问请求的目的 URI包含与所述成员资源对应 的扇出 URI; 以便所述成员资源所属的成员设备根据所述扇出 URI指示的成 员资源在成员设备上的访问路径执行所述成员资源访问请求指示的操作。
具体的， 第一群组服务器根据表 1中的扇出 URI和多播地址的映射关 系， 向成员设备发送如下成员资源访问请求：
GET /xxx/templ/data HTTP/1.1
Host: [FF32:30:3FFE:FFFF:1::1231]
其中， GET命令中携带的 URI为添加了后缀 data的扇 出 URI "/xxx/templ/data" , 而 Host头域作为目的地址携带多播地址（即第一群组 服务器为群组资源 Grp4中的成员资源 m41, m42所分配的 IPv6多播地址 ) 。
从而， 成员资源 m41, m42所属的成员设备（假设为 Dl , D2 )通过多 播地址 [FF32:30:3FFE:FFFF:1::1231]接收到 GET /xxx/templ/data HTTP/1.1 请求后，可以将成员设备 Dl和 D2中路径为 /xxx/templ下后缀为 data的数 据发送给第一群组服务器， 从而第一群组服务器不需要以单播的形式将成 员资源访问请求发送给成员设备 D1和 D2, 从而节省了网络流量。
此外， 在第一群组服务器接收对成员资源的访问请求之前， 第一群组 服务器还接收群组资源创建请求 ,所述群组资源创建请求中携带各成员资 源， 所述成员资源包括所述成员资源所属的成员设备以及成员资源在成员 设备上的访问路径； 所述成员资源所属的成员设备以及成员资源在成员设 备上的访问路径为所述成员资源所属的成员设备分配至少一个多播地址， 并根据所述成员资源在成员设备上的访问路径建立多播地址和所述扇出 URI的映射关系， 所述扇出 URI用于指示成员资源在成员设备上的访问路 径。 具体的， 第一群组服务器创建群组资源以及建立多播地址和所述扇出 URI的映射关系， 请参考图 2的描述， 包括如下步骤： 步骤 201、 第一群组服务器接收群组资源创建请求， 所述群组资源创建 请求中携带各成员资源， 所述成员资源包括所述成员资源所属的成员设备 以及成员资源在成员设备上的访问路径。
步骤 202、 第一群组服务器根据成员资源所属的成员设备以及成员资源 在成员设备上的访问路径获取各成员资源的特征， 并根据所述成员资源的 特征判断是否需要建立多播组;具体的， 第一群组服务器判断是否需要建立 多播组的方法请参考图 2-A的描述， 包括以下步骤：
步骤 202-1、 第一群组服务器解析所述群组资源创建请求， 获取群组资 源特征描述及其成员资源的特征描述， 包括但不限于群组资源的类型属性 (如是否为静态、 动态或临时群组）、 群组资源的用途（是否需要可靠的请 求响应）、 成员资源的在成员设备上的访问路径、 成员资源的访问接口、 成 员资源所属的成员设备及网络特性（是否支持多播）等特征。
例如， 对于群组资源的特征描述可以从群组资源创建请求所携带的群 组资源描述内容获得。 其中群组资源描述内容包括群组资源的类型属性、 用途； 而对于成员资源的特征描述则可以通过群组资源描述中所包含的成 员资源的 URI信息来获得， 其中包括成员资源的 URI结构、 成员资源的访 问接口等， 还可以根据成员资源的 URI来访问成员资源的成员设备从而进 一步获取成员资源的成员设备及成员设备所属的网络特性等特征。
步骤 202-2、根据所述群组资源创建请求的群组描述判断所创建的群组 资源是否为相对静态的群组， 或是变化较为频繁的动态群组， 若是相对静 态的群组， 执行后续判断流程； 若是动态群组， 不为群组资源创建多播组 以及结束流程， 从而避免由于群组频繁变化所带来的多播组创建和维护开 销。 所述相对静态的群组可以为： 群组描述中包含了具体的成员资源列表 且成员的变化由第一群组服务器通过群组管理命令（如增加 /删除成员 ) 来 控制的群组； 所述动态群组包括但不限于： 群组所包含的成员资源是满足 特定条件的资源集合， 例如在指定地理范围内的成员资源、 或具有其他相 同特征的成员资源， 而群组成员的变化可根据成员资源自身特征的改变而 自动触发（如成员离开或进入某个地理范围， 群组选择某个频道）。
步骤 202-3、根据群组资源创建请求携带的成员资源的访问接口判断各 成员资源的访问接口是否一致， 若是执行后续判断流程， 否则不为群组资 源创建多播组以及结束流程。 所述成员资源访问接口是否一致具体为能否 用相同的多播数据包（如 IPv4或 IPv6 )进行访问。 例如， 若用于访问多个 成员资源的 URI遵循相同的协议和访问端口号、且所述多个成员资源的 URI 在不同成员设备上的访问路径相同， 则可以认为所述多个成员资源具有相 同的资源访问接口。 在一个实际系统中， 所述 URI 可用 URL ( Uniform Resource Locator,统一资源定位符 )来进行表示， 而 URL的基本结构包括：
<scheme>：〃 <authority>:<port>/<path>?<query>#<fragment>
其中， <8(1½1116>部分确定了访问该 URL对应资源所采用的协议（如 http或 coap ); <authority>部分确定了成员资源所属的成员设备的地址（如 IP 地址或域名 ）； <port>作为可选项， 表明了协议访问端口号； <path>?<query>#<fragment>表示该资源在设备上的访问路径。
作为一个例子， 4叚设 M2M平台 Nl、 M2M设备 D1和 M2M网关 G1 ό 域名分另1 J为： nl.example.com、 dl.example.com、 gl.example.com, 贝1] N1 上的 Grpl群组资源 URL为：
Grpl = http://nl.example.com/groups/grpl
其所包含的成员资源 mll、 ml2、 ml3、 ml4的 URL分别为： mil = coap://dl .example.com/xxx/templ
ml2 = coap://dl. example.com/yyy/temp2
ml 3 = coap://gl. example.com/xxx/templ
ml4 = http://nl.example.com/xxx/templ
则上述 4个成员资源中 mil和 ml3具有相同的资源访问接口， 因为其
<scheme>采用了相同的 coap协议， 且在成员设备 (此处为 dl和 gl )上访 问路径均为 /xxx/templ ; 相反的， ml2 的在成员设备 dl 的访问路径为 /yyy/temp2, 而 ml4 ^<scheme>^7 http协议， 因此 ml2与 ml4与其他成员 资源不具有相同的资源访问接口。 在此示例中， 可以为 mil和 ml3建立多 播组， 而不包含 ml2与 ml4。
步骤 202-4、第一群组服务器判断各成员资源及其各成员资源所属的成 员设备和各成员设备所属的网络是否支持多播， 若支持执行后续判断流程， 否则不为群组资源创建多播组以及结束流程。 对于成员资源是否支持多播 可根据该成员资源对应的 URL是否支持多播协议访问（例如 HTTP协议不 支持， 而 CoAP协议支持）来判断； 对于成员资源所属的成员设备及成员 设备所属的网络是否支持多播， 则可能需要第一群组服务器进一步获取该 成员资源及该成员资源所属的成员设备的相关资源表述信息如注册信息， 并根据资源表述信息如注册信息确定。
作为一个例子， 成员资源 mil所在的成员设备 D1在 M2M平台 N1上 的注册信息可由 ^口下 URL访问： http://nl .example.com/scls/dl ,
则第一群组服务器可以通过向 N1 发送一个 HTTP GET请求获取该 URL所对应的资源表述内容。 在资源表述内容中， 对于 D1是否支持多播 可由一个专门的属性（如" multicastEnabled" ) 来表示， 若其取值为 TRUE 则表示支持多播， 若取值为 FALSE则表示不支持多播。
可选的， 即使成员资源的所在的成员设备不支持多播， 但访问该成员 资源需要经过一个支持多播的其他设备时， 也可以判断为该成员资源所属 的成员设备资源支持多播。 如图 2-B所示， 第一群组服务器为 M2M设备 D1 , 且群组资源 Grp2中包含一个 M2M平台上的成员资源 m21 , 而 D1访 问 m21时需要经过 M2M网关 Gl。
若 D1与 G1间的通信链路支持多播（如 CoAP协议 ), 则 D1可以采用 多播的方式发送请求给 G1 , 然后 G1将其转换为单播的方式（如 HTTP协 议）访问 N1上的 m21。 此时， 可以认为对成员资源 m21的访问支持多播。
步骤 202-5, 第一群组服务器 判断满足上述条件的成员资源所属的成 员设备是否达到一定数量， 若是则执行后续步骤， 否则结束流程并不为群 组资源创建多播组。 这里， 可以通过预先配置的策略或参数来确定一个数 量作为建立多播组的门限， 少于此门限时， 则不需要为上述成员资源建立 多播组， 以节约多播组的管理开销。
值得注意的是， 上述 202-2到 202-5的步骤并没有严格的时间顺序， 并 且第一群组服务器可能根据配置的策略或能力只执行 202-2到 202-5之间的 一个或多个步骤， 本发明实施例在此并不做限定。 此外， 第一群组服务器 还可以判断针对该群组资源的成员访问是否要求可靠响应， 若是， 结束流 程并不为群组资源创建多播组， 否则执行后续判断流程。
所述要求可靠响应是指所述成员资源的成员设备在接收到成员资源访 问请求后， 必须返回操作成功或失败的响应消息。 具体来说， CoAP协议中 的 Confirmable (CON) 类型的请求消息就是一种要求可靠响应的成员资源 访问请求， 其要求成员资源访问请求的接收者必须返回 Acknowledgement (ACK)或者 Reset (RST)类型的响应消息； 而 Non- Confirmable (NON)类型的 请求消息则不要求消息接收者返回任何响应消息。
步骤 203、根据所述成员资源所属的成员设备以及成员资源在成员设备 上的访问路径为所述成员资源分配多播地址， 并根据成员资源在成员设备 上的访问路径建立所述所述多播地址及所述扇出 URI之间的映射关系。 具 体的请参考图 2-C的描述， 包括以下步骤：
步骤 203-1、第一群组服务器分析满足步骤 202中各条件的成员资源所 属的成员设备（以下筒称成员设备）所属的多播域情况， 所述成员设备是 否都属于本地多播域， 如是， 执行步骤 203-4, 否则， 执行步骤 203-2; 具体的， 在本发明实施例中， 多播域可分为本地多播域、 远程多播域 和全局多播域。 本地多播域是指第一群组服务器所管辖的网络地址的区域， 第一群组服务器能够为该区域中的成员设备分配本地多播域的多播地址 (本地多播地址；)， 当该区域中的设备加入了本地多播地址所指示的多播组 后， 发往本地多播地址的数据包可以被所有已加入该本地多播组的成员设 备接收。 而远程多播域则是第一群组服务器所管辖的网络地址的区域以外 的区域， 群组服务器不能够为远程多播域分配本地多播地址， 且本地多播 域中的成员设备无法接收发往远程多播域的多播地址（远程多播地址） 的 数据包（即使本地址多播址和远程多播地址相同， 因为不同的多播域可以 重复使用相同的地址空间）， 反之亦然。 全局多播域是指包含了本地多播域 以及远程多播域在内的整个网络的区域。 因此， 无论本地网络设备或远程 网络设备， 只要加入了一个全局多播域中的多播地址（全局多播地址）所 指示的多播组， 都可以接收发往全局多播地址的数据包。 全局多播地址可 能由一个全局网络实体统一管理分配， 也可以按一定的地址规划事先分配 到某些群组服务器中。关于 IPv4和 IPv6的多播地址空间的分配方案指导可 参考 [RFC3171]和 [RFC 4291]等标准文献。 一个成员设备具体属于哪个多播 域可根据该成员设备与群组服务器的连接关系判断， 例如若成员设备（如 M2M设备 )注册到第一群组服务器（如 M2M网关）， 则可认为该成员设备 属于该群组服务器的本地多播域， 若成员设备注册到其它与该第一群组服 务器平级（如另一个 M2M网关）或更高一级的实体（如 M2M平台）时（即 归属于第二群组服务器）， 则可认为该成员设备属于远程多播域。 即， 第一 群组服务器根据创建群组资源请求中的成员地址获取各成员设备的注册信 息， 然后根据注册信息来判断是否是属于本地多播域。
203-2、 第一群组服务器判断能否为群组资源的成员设备分配全局多播 地址， 若是则执行步骤 203-5, 否则执行步骤 203-3。
具体的，如步骤 203-1中所述，全局多播地址可以按一定的地址规划策 略预先分配到某些群组服务器中。 因此， 第一群组服务器在确定群组资源 的成员设备不全都属于第一群组服务器所管辖的本地多播域时， 在第一群 组服务器中查找被预先分配的全局多播地址空间是否还有尚未分配的全局 多播地址， 或者第一群组服务器通过向负责管理全局多播地址分配的全局 实体发出地址分配请求。 对于第一群组服务器通过向负责管理全局多播地 址分配的全局多播地址管理实体发出地址分配请求， 具体实施方式如下：
4叚设全局多播地址管理实体为 M2M平台 N1 , 且 N1上用于分配全局 多播地址的资源 URL为： http：〃 nl.example.com/mcAddrPool,则第一群组服 务 器 可 通 过 一 个 HTTP GET 请 求 访 问 资 源 http://nl.example.com/mcAddrPool。 若 N1返回的是成功响应， 则可以从响 应消息的消息体中获取第一群组服务器所申请的全局多播地址，若 N1返回 的是失败响应， 则意味着 M2M平台 N1不能为所属成员设备分配全局多播 地址。
实际上， 第一群组服务器也可以用类似的方法向负责管理本地或远程 多播地址分配的其它实体（如其它群组服务器）请求分配远程或全局多播 地址， 实现方式与向 M2M平台 N1申请全局多播地址的方式类似， 本发明 不在详述。
203-3、 第一群组服务器判断不归属于本地多播域的成员设备（非本地 成员设备）是否可通过第二群组服务器进行访问， 若是则执行步骤 203-6, 否则执行步骤 203-7。 例如， 假设第一群组服务器为第一 M2M网关 G1 , 而 群组资源 Grp3有非本地成员资源 m31、 m32、 m33、 m34如下：
m31 = http://d2.example.com/xxx/templ
m32 = http://d2.example.com/xxx/temp2
m33 = coap://d3.example.com/xxx/templ
m34 = coap://d4.example.com/xxx/templ
贝' J m31和 m32的成员设备为 M2M设备 D2, 而 m33和 m34的成员设 备分别为 M2M设备 D3和 D4, 且 D2、 D3、 D4均不归属于 G1的本地多播 域。 4叚设 D3和 D4可通过第二 M2M网关 G2的进行访问， 其网络连接关 系如图 2-D所示。 因此， 可以认为成员（m31, m32)可以通过第二群组服务器 (图 2-D中的 M2M设备 D2 )访问， 而成员（m33, m34)可通过第三群组服 务器（图 2-D中的 M2M网关 G2 )访问。 但是， 若 D2或 G2由于设备能力 等原因无法充当群组服务器， 则可认为 (m31 , m32)或 (m33, m34)无法通过另 一群组服务器访问。 具体的， 本发明实施例中第一群组服务器（图 2-D 中 的 M2M关 G1 )
需要说明的是， 即使只有 1个成员资源 （如仅有 m31而没有 m32 )可 通过另一群组服务器访问时， 仍然可以执行步骤 203-6为成员资源 m31创 建一个群组资源。 然而从提高效率的角度出发， 第一群组服务器可以根据 预先配置的策略或参数来确定一个成员数量门限， 少于此门限时， 则认为 不满足上述判断条件， 从而执行步骤 203-7, 而不执行步骤 203-6, 以节约 群组管理开销。
203-4、 第一 群组服务器为支持多播的本地成员设备分配本地多播地 址。
203-5、 第一 群组服务器为支持多播的所有成员设备分配全局多播地 址。
203-6、 第一群组服务器根据步骤 203-3的判断结果， 请求第二群组服 务器在第二群组服务器上创建第二群组资源， 其中第二群组资源包含能够 通过所述第二群组服务器访问的非第一群组服务器管辖的成员资源。 此后， 所述第二群组服务器按本发明所揭示的方法， 从图 2中的步骤 201开始执 行相关流程， 本发明实施例在此不再详述。
203-7、 第一群组服务器记录无法通过第二群组服务器访问的非本地成 员资源列表， 以便后续按单播方式对其进行访问。
203-8确定第二群组服务器（如图 2-D中的 G2 )是否为本地多播域设 备（即是否通过第一群组服务器访问 ) ，如是执行步骤 203-9第一群组服务 器还可以为第二群组服务器分配本地多播地址并执行步骤 203-10, 否则建 立成员资源与第二群组服务器的映射关系， 并按默认的单播方式访问第二 群组服务器； 在图 2-D的示例中， 第二群组服务器 D2或 G2都不属于第一 群组服务器 G1的本地多播设备。
步骤 203-10、 根据步骤 203-4、 203-5或 203-9中的多播地址的分配结 果， 或 203-8中的第二群组服务器的访问地址， 或 203-7中的成员设备的地 址， 在第一群组服务器中建立为群组资源建立映射关系。
具体的， 在同一多播域中的成员资源可以共享一个多播地址， 然而根 据成员资源本身的访问接口是否一致， 可以为群组资源建立多种的映射关 系。 具体来说， 无论成员资源的访问接口是否相同， 都需要将群组资源标 识与所分配的多播地址进行关联， 并建立多播地址和 "扇出 URI" 的映射 关系。 所述扇出 URI为： 当第一群组服务器接收对群组资源的成员资源的 访问请求时， 向成员设备发送成员资源访问请求的目的 URI。 具体的， 当 成员资源的 URI遵循相同的协议和访问端口号， 且成员资源在成员设备上 的访问路径相同时，所述扇出 URI为在成员资源在成员设备上的访问路径； 当 URI遵循相同的协议和访问端口号，但在成员设备上的访问路径不同时， 所述扇出 URI设为一个虚拟资源标识（可以是群组资源标识或其它形式的 资源标识）。。 其中， 建立多播地址与扇出 URI的映射关系请参照如下几种 情况：
第一种情况： 群组资源的各成员资源的在成员设备上的访问路径相同。 作为一个例子， 假设 M2M 网关 G1 上的群组资源 Grp4为： Grp4 = http：〃 gl .example.org/groups/grp4
其中包含的成员资源为 M2M设备 D1上的 m41和 M2M设备 D5上的 m42:
m41 = coap://dl .example.org/xxx/templ
m42 = coap://d5.example.org/xxx/temp 1
第一群组服务器（此例中为 M2M网关 G1 )为群组资源 Grp4下的成员 资源 m41和 m42所分配的 IPv6多播地址为 [FF32:30:3FFE:FFFF:1::1231] , 且设备间的网络连接关系如图 2-E所示（即成员资源 m41和 m42所属的成 员设备 Dl和 D2都归属于 M2M网关 G1 ); 则群组资源 Grp4的多播地址 ([FF32:30:3FFE:FFFF: 1：： 1231])及扇出 URI(/xxx/templ)的的映射关系， 以及 群组资源 Grp4的成员资源 (m41和 m42)、 和扇出 URI(/xxx/templ)的映射关 系如表 1 所示。 当然， 在此种情况下， 由于群组资源的所有成员资源在成 员设备上的访问路径相同， 因此所有成员资源对应一个多播地址和扇出 URI , 因此， 映射关系还可以仅为群组资源 Grp4的多播地址和扇出 URI的 映射关系， 而无需记录群组资源的成员资源和扇出 URI的映射关系。 然而， 由于同一群组服务器中通常包括多个群组资源， 而每个群组资源的成员资 源特性不一致， 因此为了记录的统一性，即便无需记录成员资源的扇出 URI 的映射关系， 也可以在列表中映射关系记录成员资源， 或保留相关的属性。
第二种情况， 群组资源的成员资源即代表其所在的成员设备。
例如， 假设 M2M 网关 G1 上的群组资源 Grp5 为： Grp5 = http://gl .example.org/groups/grp5 , 其中包含的成员资源分别为 Μ2Μ设备 Dl、 D5、 D6上的 m51、 m52、 m53:
m51 = coap://dl. example.org/
m52 = coap://d5.example.org/
m53 = coap://d6.example.org/
所分配的 IPv6多播地址为 [FF32:30:3FFE:FFFF:1::1232] ,且设备间的网 络连接关系仍然图 2-E所示 （即成员资源 m51、 m52和 m53各自所属的成 员设备 Dl、 D5、 D6均归属于 M2M网关 G1 ), 则与成员资源 m51、 m52 和 m53对应的扇出 URI则为根符号 " , 则群组资源 Grp5 的多播地址 ([FF32:30:3FFE:FFFF:1::1232])及扇出 URI(/)的映射关系， 以及成员资源 (m51、 m52和 m53)和扇出 URI(/)的映射关系如表 2所示。 在这种情况下， 也可以筒化省略扇出 URI信息。 此外， 在此种情况下， 也可以称之为君组 资源的多播地址（[FF32:30:3FFE:FFFF:1::1232])及扇出 URI(/)和成员资源 (m51、 m52和 m53)的映射关系。 本发明实施例在无特别说明的情况下， 映 射关系均指多播地址、 成员资源和扇出 URI的映射关系。
第三种情况， 群组资源的各成员资源在各自的成员设备上的访问路径 不同。
作为一个例子， 假设 M2M 网关 G1 上的群组资源 Grp6为： Grp6 = htt ://g 1.example.org/groups/grp6 , 其中群组资源 Grp6 的成员资源分别为 M2M设备 D5 上的 m61和 M2M设备 D6上的 (m62, m63):
m61 = coap://d5.example.org/xx
m62 = coap : //d6.example, org/yy
m63 = coap://d6.example.org/zz
第一群组服务器（此例中为图 2-E中 M2M网关 G1 )为 Grp6所分配的 IPv6多播地址为 [FF32:30:3FFE:FFFF: 1：： 1233] , 且设备间的网络连接关系如 图 2-E所示（即成员资源 m61所属的成员设备 D5和成员资源 m62, m63所 属的成员设备 D6均归属于 M2M网关 G1 ), 则第一群组服务器需要为群组 资源 Grp6的各成员资源分配一个虚拟的扇出 URI (具体的分配方法可由第 一群组服务器确定，本发明实施例在此不在限定），例如 wdl-know/grp6，，。 此虚拟的扇出 URI ( /well-know/grp6 )并不直接对应任何成员设备上的成员 资源， 但是各成员设备需要将其关联到与该虚拟的扇出 URI对应群组资源 中属于该成员设备的成员资源， 具体的关联方法见后续图 2-G的相关描述。 另外， 为了避免此不同群组服务器所分配的虚拟扇出 URI在同一成员设备 上的命名沖突， 可以在不同的群组服务器间采取恰当的命名空间划分， 或 者直接使用具有唯一' ]·生的群组 URI (例如 /g Lexample.org/groups/grp6 )作为 该虚拟扇出 URI的一个组成部分或全部。对群组资源 Grp6的成员资源 m61、 m62 和 m63 , 和扇出 URI ( /well-know/grp6 ) 的映射关系， 和多播地址 ( [FF32:30:3FFE:FFFF: 1::1233] )及扇出 URI ( /wdl-know/grp6 )建立的映 射关系请参考表 2所示。
第四种情况， 成员资源的访问接口部分相同。 作为一个例子， 当有部分成员资源的访问接口相同， 而其余成员资源 的访问接口不同时， 除了可以采用上述方法外， 还可以将访问接口相同的 成员资源分为第一组（可以有多组）， 将具有不同访问接口的成员资源分为 第二组， 然后按上述方法分别对每组成员资源， 多播地址及扇出 URI进行 映射， 从而形成多组映射关系。 群组服务器可以为每组成员资源单独分配 不同的多播地址， 也可以为其分配相同的多播地址。 对于后者， 则要求每 组的 "扇出 URT 不同。
例如， 4叚设 M2M 网关 G1 上的群组资源 Grp7 为： Grp7 = http://gl .example.org/groups/grp7 , 其中群组资源 Grp7包含的成员资源分别 为 M2M设备 D1上的 m71 , D5上的 m72, D6上的 m73 , D7上的 m74, D8上的 m75 , D9上的 m76, N1上的 m77:
m71 = coap://dl. example.org/xx/aa
m72 = coap://d5.example.org/xx/aa
m73 = coap://d6.example.org/yy/bb
m74 = coap://d7.example.org/yy bb
m75 = coap://d8.example.org/cc
m76 = coap://d9.example.org/dd
第一群组服务器（此例中为图 2-E中 M2M网关 G1 )为群组资源 Grp7 所分配的 IPv6多播地址为 [FF32:30:3FFE:FFFF: 1 :: 1234] ,且设备间的网络连 接关系如图 2-E所示（即成员资源 m71、 m72、 m73、 m74、 m75和 m76各 自所属的成员设备 Dl、 D5、 D6、 D7、 D8、 D9均归属于 M2M网关 Gl ), 则成员资源 (m71, m72)对应相同的扇出 URI xx/aa/" , (m73, m74)对应相同 的扇出 URI yy bb/" , 而 (m75, m76)则需要分配一个虚拟的扇出 URI, 如 wdl-known/grp7/"， 则为群组资源 Grp7的各成员资源建立的映射关系如 表 2所示,即成员资源 (m71, m72)和扇出 URI(/xx/aa)的映射关系以及多播地 址（ [FF32:30:3FFE:FFFF: 1 :: 1234] )和扇出 URI(/xx/aa)的映射关系， 成员资 源 （ m73, m74 ) 和扇 出 URI(/yy/bb)的映射关系 以及多播地址 ( [FF32:30:3FFE:FFFF:1:: 1234] )和扇出 URI(/yy bb),成员资源（ m75, m76 ) 和扇 出 URI ( /wdl-known/grp7 ) 的 映射 关 系 以 及多 播地址
( [FF32:30:3FFE:FFFF:1:: 1234] )和扇出 URI ( /wdl-known/grp7 )的映射关 系，成员资源（ m77 )、单播地址（ [3FFE:2A00: 100:7031::1] )及扇出 URI(/abc) 之间的映射关系。
当存在部分不支持多播的成员资源时： 若群组资源中还包含不支持多 播的成员资源， 则对于这些不支持多播的成员资源单独采用现有技术中的 逐一单播的访问方式处理而不需加入上述成员地址映射表。 当然， 为了便 于群组服务器的统一处理， 也可以在成员地址映射表中单独列出这些成员 资源的单播访问地址和扇出 URI。 此时， 需将其单播地址填入多播地址栏， 而将其在成员设备上的访问路径填入扇出 URI栏。例如假设上述 Grp7中还 包含成员 m77为：
mil = http://nl.example.org/abc
由于 m77只能通过 http协议访问， 不支持多播， 因此映射关系如表 2 所示。
第五种情况， 群组资源的成员资源中存在非本地成员资源且无法分配 全局多播地址：
对于步骤 203-3中所描述的群组资源 Grp3包含了非本地成员的情形， 则第一群组月良务器（此例中为图 2-E中 M2M网关 G1 )可以在 D2和 G2分 别创建两个群组： Grp8 包含（m31, m32)和 Grp9包含 (m33, m34), 例如：
Grp8 = http://d2.example.com/groups/grp8
Grp9 = http://g2.example.com/groups/grp9
由于第一群组服务器无法为 D2和 G2分配全局多播地址， 因此只能按 上述不支持多播方式处理， 将 D2和 G2的单播地址分别填入多播地址栏， 而将 Grp8和 Grp9的群组资源 URI (或其在成员设备上的访问路径 )分别 填入扇出 URI栏， 如表 2所示。 表 2, 群组资源映射表
Figure imgf000033_0001
上述群组资源映射表 1和表 2在具体实施时， 可通过第一群组服务器 内部的一般数据库来进行维护操作， 或者注册到一个 DNS ( Domain Name System, 域名系统）服务器中， 或者也可以作为一种 RESTful资源进行表 述。 该 RESTful资源可以作为群组资源表述的一部分， 如图 2-F所示。
图 2-F中， <group>为现有技术 ETSI M2M规范 TS 102 690中所定义的 群组资源表述， 包含主要包含用于描述各成员资源 URI的 members属性， 用以指代所有成员资源的 membersContent子资源， 以及其他若干属性和子 资源（本发明在此不做详述）。 符号 "< >"表示相同类型的属性或子资源可 能有多个实例， 每个实例的字符串名称可以任意设定。 请求者可以通过对 members 属性的增加、 删除、 修改、 查看等操作实现对群组成员列表的修 改， 也可以通过对 members属性的查看操作实现对成员资源列表的查看， 也可以通过对 membersContent子资源的增 /删 /改 /查等操作实现对群组资源 中所有成员资源的修改或查看。
本发明实施例中， 通过在现有的群组资源中新增扇出组4&1101^61>资 源， 来描述群组资源中用于多播管理的成员资源与扇出 URI及多播地址的 映射关系。 每个 4&1101^61>可描述表 1或表 2中的扇出 URI及多播地址映 射关系以及成员资源和扇出 URI的映射关系，一个 <group> 源本身对应表 1或表 2中的一个群组资源，其中可能包含 0至任意多个 <fanoutSet>子资源。 每个 <f anoutSet>资源可包含如下一些属性：
fanoutAddress： 对应表 1或表 2中的多播地址。
fanoutUri: 对应表 1或表 2中的扇出 URI信息。 此属性在某些情况下 是可选的。 例如， 当一个 <group>资源中仅包含一个 <fanoutSet>资源， 且所 有成员资源在其成员设备上的访问路径都相同时， 扇出 URI 可以直接从 members属性中的成员资源 URI中明确获得， 此时该属性可以被省略。 或 者， 当扇出 URI采用唯一确定的群组 URI本身时， 该属性也可以被省略。
addressType为可选信息， 用以描述 fanoutAdress中的地址类型为多播 或单播、 以及 IPv4或 IPv6等信息。
memberList 为可选信息， 用以描述该组映射关系所涉及的成员资源列 表即各成员资源所属的成员设备以及各成员资源在成员设备上的访问路 径， 即表 1 中的成员资源。 具体的， 当群组资源的所有成员资源在成员设 备上的访问路径相同时， 所有成员资源对应一个多播地址和扇出 URL 由 于 members属性中已包含群组资源中所有成员资源的信息，因此 memberlist 属性中可以不用再次记载各成员资源的信息。
需要说明的是， 图 2-C 中的步骤的执行并没有严格的先后顺序要求， 图 2-C 所提供的流程只是一种较为优选的实施方式。 实际上， 步骤 203-2 可以先于步骤 203-1执行从而优先分配全局多播地址而非本地多播地址，而 步骤 203-10中的建立多播地址和扇出 RUI的映射关系以及成员资源和扇出 URI的映射关系可以伴随步骤 203-4到 203-9之中分配多播或单播地址而完 成。 另外， 每当群组资源被更新时， 若其中成员资源的构成发生了变化（如 原有的成员被删除， 或新的成员被加入）， 则第一群组服务器也应该按上述 方法执行， 并根据需要重新分配多播地址和更新相应的映射关系。 步骤 204、 第一群组服务器根据多播地址及扇出 URI的映射关系向成 员资源所属的成员设备发送加入多播组的群组通告， 所述加入多播组的群 组通告中携带多播地址； 以便于成员资源所属的成员设备根据加入多播组 的群组通告加入与所述多播地址对应的多播组。
具体的， 第一群组服务器根据所建立的多播地址及扇出 URI的映射关 系， 向支持多播的成员设备发送加入多播组的群组通告。 加入多播组的群 组通告中携带分配的多播地址， 以指示支持多播的成员设备加入与所述多 播地址对应的多播组。 对于不支持多播的成员设备则不必发送加入多播组 的群组通告。 以一个群组资源 （如 Grp7 ) 包括多条多播地址及扇出 URI的 映射关系为例， 第一群组服务器需要针对每条具有扇出 URI的映射关系中 的成员资源对应的成员设备分别发送加入多播组的群组通告。 此外， 上述 加入多播组的群组通告除包含成员设备所应加入的多播组对应的多播地址 以外， 加入多播组的群组通告还可以包括扇出 URI以及成员资源的映射关 系。
具体来说， 当群组资源中成员资源的在成员设备上的访问路径完全相 同时（如表 1和表 2中的 Grp4、 Grp5 ), 所述加入多播组的群组通告可以只 需要包含多播地址信息； 当群组中成员资源的在成员设备上的访问路径不 完全相同时（如表 2中的 Grp6、 Grp7 ), 则加入多播组的群组通告还应包含 扇出 URI以及成员资源的映射关系， 以便成员资源所属的成员设备存储所 述扇出 URI和所述多播地址映射关系， 以及所述成员资源和所述多播地址 的映射关系。
加入多播组的群组通告可以根据预先的配置通过单播、 多播或广播等 多种方式发送到成员设备。 具体来说， 当采用单播方式时， 第一群组服务 器采用单播消息逐一向每个成员资源所属的成员设备的单播地址（如 ιρν4 或 IPv6单播地址）发送加入多播组的群组通告； 当采用多播或广播方式时， 群组服务器采用多播或广播消息， 向事先约定的多播或广播地址（如 IPv4 或 IPv6多播地址）发送加入多播组的群组通告， 此时要求相应的成员设备 已事先加入了所述特定多播或者广播地址所对应的多播 /广播组（比如通过 IGMP或 MLD等 IP多播管理协议的方式实现）， 并且所述加入多播组的群 组通告中还应包含成员设备的标识（ URI )或成员资源 URI , 以指示与成员 设备的标识（URI )或成员资源 URI对应的成员设备接收并处理该加入多 播组的群组通告， 而其他成员设备忽略该加入多播组的群组通告。
本发明实施例并不限定单播、 多播或广播方式发送加入多播组的群组 通告所采用的传输协议（例如 HTTP、 CoAP或 SIP等）， 而消息格式本身也 可以采用不同的封装方式（例如 XML或二进制编码等）。 以下仅给出一种 采用 RESTful的发送加入多播组的群组通告的优选实施方式。
为实现本发明，成员设备中存储了成员资源加入多播组的 mcGroups资 源， 用于存储 0至任意多个多播组资源 <mcGroup>, 而每个 <mcGroup>资源 描述了该成员设备所加入的多播组信息， 如图 2-G所示， <mcGroup>资源 包含如下属性：
mc Address: 成员设备所加入多播组的多播地址。
fanoutUri: 成员设备所加入多播组对应的扇出 URI。
memberList: 与所述扇出 URI对应的本地成员资源列表， 可以是成员 资源的完整 URI或者仅保存成员资源在该成员设备上的访问路径。
第一群组服务器可以通过单播或多播或广播 RESTful请求向相应的成 员设备发送用于添加、 删除或修改上述多播组资源 <mcGroup^ 请求， 从 而实现加入多播组的群组通告的发送。
具体的， 第一群组服务器通过加入多播组的群组通告指示成员设备加 入多播组时， 进行如下处理：
当第一群组服务器需要通过加入多播组的群组通告将成员设备 D1 加 入一个多播组时，则向 D1发送 HTTP POST请求向 D1中的 mcGroups资源 下添加一个 <mcGroup>资源， 并将 mcGroup的资源表述携带在 POST请求 的消息体内：
POST /xxx/mcGroups HTTP/1.1
Host: dl.example.com
{ <mcGroup> 源表述 }
其中， Vxxx/mcGroups"表明 mcGroups 资源在 Dl 上的访问路径， "HTTP/1. Γ 表示协议版本号， 而 Host头域携带 Dl的域名或 IP地址。 若 采用支持多播的 CoAP协议发送加入多播组的群组通告， 则 Host头域可以 携带 D1事先加入的一个多播组地址， 且 Host头域及该请求消息的各部分 将按现有技术的方法转换为 CoAP协议中的相应字段。 其他与本发明不相 关的 POST请求的消息头域或消息体内容没有详尽列出。
当成员设备 D1 成功接收 POST请求并在本地添加了 <mcGroup>资源 后， 向第一 群组服务器返回 HTTP成功响应， 如下：
HTTP/1.1 201 Created
Location: http://dl .example.com/xxx/mcGroups/mcGrpl
其中" 201 Created"表明所请求资源<1^0 0叩>已被成功添加， 而 Location头域则携带所添加资源在 D1上的 URI,其中" mcGrpl"为该资源的 实例名称。
作为一种可选方式， 群组服务器还可以通过发送 HTTP PUT请求直接 在成员设备 D1中写入一个名为 mcGrpl的<1^0 0叩>资源， 例如：
PUT /xxx/mcGroups/mcGrpl HTTP/1.1
Host: dl.example.com
{ <mcGroup> 源表述 }
而成员设备 Dl则直接返回成功响应： HTTP/1.1 200 0K
第一群组服务器通过离开多播组的群组通告指示成员设备退出多播组 时， 则可以通过与发送加入多播组的群组通告类似的方法发送离开多播组 的群组通告， 进行如下处理：
当第一群组服务器需要通过离开多播组的群组通告指示成员设备 D1 离开一个多播组时， 则向 D1发送一个 HTTP DELETE请求以便从 D1中的 mcGroups资源下删除一 ^<ιηοθΓουρ>资源：
DELETE /xxx/mcGroups/mcGrp 1 HTTP/1.1
Host: dl.example.com
其他发送加入或离开多播组的群组通告的实现方式：
第一群组服务器还可以采用其它 RESTful 方法或者其他协议 （如 CoAP )来发送上述加入或离开多播组的群组通告。 比如通过 PUT、 POST 或 DELETE方法直接修改成员设备上已有的 <mcGroup>资源表（或者其中 的部分属性）来指示成员设备加入或者离开某个多播组的通告。 具体来说， 通过替换整个 <mcGroup> 源来指示离开原有的多播组， 加入新的多播组； 通过修改<11^01"0叩>资源中的 mcAddress 属性来变更多播组地址； 通过修 <mcGroup>资源的 fanoutURI属性来变更多播组对应的扇出 URI;或通过 添加、删除或修改 membersList中的成员资源列表来指示成员设备上某些成 员资源加入或离开某多播组。
成员设备在接收到上述加入或离开多播组的群组通告后， 应根据加入 或离开多播组的群组通告中的指示，采用 IGMP或 MLD等多播管理协议加 入或离开相应的多播组， 同时维护存储于该成员设备的多播组资源 <mcGroup>, 以便处理后续来自群组服务器的群组成员访问请求。
此外，对于上述步骤 203-9中分配了多播地址的第二群组服务器，则需 要将所述第二群组服务器看作成员设备， 进行上述发送加入或离开多播组 的群组通告的相同处理， 此处不再赘述。
此外， 在第一群组服务器创建群组资源后， 第一群组服务器还能收到 应用服务器发送的对群组资源的更新请求,如增加成员资源的群组资源更新 请求、 删除成员资源的群组资源更新请求或修改群组资源描述信息的请求。
具体的， 增加成员资源的群组资源更新请求中携带群组资源的标识以 及需加入群组资源的成员资源， 所述需加入群组资源的成员资源包括成员 资源所属的成员设备以及成员资源在成员设备上的访问路径。 第一群组服 务器收到增加成员资源的群组资源更新请求后， 根据群组资源的标识确定 需加入群组资源的成员资源在成员设备上的访问路径和与群组资源的标识 对应的群组资源中的所述多播地址和扇出 URI的映射关系中的扇出 URI相 同， 向需加入群组资源的成员资源所属的成员设备发送携带所述多播地址 和扇出 URI的映射关系中的多播地址的加入多播组的群组通告， 以便于需 加入群组资源的成员资源所属的成员设备通过所述多播地址加入多播组， 以及接收通过多播地址发送的成员资源访问请求； 或第一群组服务器收到 增加成员资源的群组资源更新请求后， 根据群组资源的标识确定需加入群 组资源的成员资源在成员设备上的访问路径和与群组资源的标识对应的群 组资源中的所述多播地址和扇出 URI的映射关系中的扇出 URI不同； 在与 群组资源的标识对应的群组资源中的扇出 URI和成员资源的映射关系中增 加需加入群组资源的成员资源， 向需加入群组资源的成员资源所属的成员 设备发送加入多播组的群组通告， 所述加入多播组的群组通告携带与群组 资源的标识对应的群组资源中的所述多播地址和扇出 URI的映射关系， 和 与群组资源的标识对应的群组资源中的扇出 URI和成员资源的映射关系； 以便于成员设备在接收到携带所述扇出 URI的访问请求后， 根据接收到的 扇出 URI与成员资源的映射关系确定成员资源在成员设备上的访问路径， 并根据确定的成员资源在成员设备上的访问路径执行相应的成员资源访问 请求。
如果第一群组服务器接收的是修改群组资源描述信息的请求， 则需要 根据修改群组资源描述信息的请求中的群组描述替换存储的群组资源的描 述信息， 并根据更新后的群组资源的描述信息更新建立的群组资源。
此外， 上述删除成员资源的群组资源更新请求中携带需离开群组资源的 成员资源和群组资源的标识， 所述需离开群组资源的成员资源包括所述成 员资源所属的成员设备以及成员资源在成员设备上的访问路径。 第一群组 服务器收到述删除成员资源的群组资源更新请求后， 根据群组资源的标识 确定与需离开群组资源的成员资源对应的扇出 URI, 以及与需离开群组资 源的成员资源对应的扇出 URI和多播地址的映射关系， 删除所述与需离开 群组资源的成员资源对应的扇出 URI和多播地址的映射关系中的需离开群 组资源的成员资源， 向需离开的成员资源所属的成员设备发送携带与需离 开群组资源的成员资源对应扇出 URI和多播地址的映射关系中的多播地址 的离开多播组的群组通告， 以便于需离开的成员资源所属的成员设备离开 所述多播地址指示的多播组； 或删除成员资源的群组资源更新请求中携带 需保留的群组资源的成员资源和群组资源的标识， 所述需保留的群组资源 的成员资源包含成员资源所属的成员设备以及成员资源在成员设备上的访 问路径；根据群组资源的标识确定与需离开群组资源的成员资源和扇出 UIR 的映射关系， 利用需保留的群组资源的成员资源更新所述需离开群组资源 的成员资源和扇出 UIR的映射关系中成员资源， 向需离开的成员资源所属 的成员设备发送携带映射关系中的多播地址的离开多播组的群组通告， 以 便于需离开的成员资源所属的成员设备离开所述多播地址指示的多播组。
进一步的， 第一群组服务器根据删除成员资源的群组资源更新请求的群 组资源的标识确定需离开群组资源的成员资源在成员设备上的访问路径和 需离开的成员资源对应的扇出 URI不同；所述离开多播组的群组通告还包括 与需离开群组资源的成员资源对应的所述扇出 URI; 以便于需离开群组资源 的成员资源所属的成员设备离开所述多播地址指示的多播组， 并根据所述 需离开群组资源的成员资源和离开多播组的群组通告中的扇出 URI删除成 员设备中与删除成员资源的群组资源更新请求的群组资源的标识对应的多 播组信息中的成员资源。
如图 3所示， 本发明实施例提供的一种群组资源的访问方法包括如下 步骤：
步骤 301、接收群组服务器发送的成员资源访问请求， 所述成员资源访 问请求为多播的成员资源访问请求， 所述成员资源访问请求中包含与所述 成员资源对应的扇出 URI。
具体的， 成员设备在加入到多播组以后， 通过所述多播组接收第一群 组服务器发送的成员资源访问请求。 所述成员资源访问请求中携带的信息 可参见步骤 103的描述， 本发明实施例在此不再详述。
此外， 在执行本步骤之前， 成员设备还可以接收加入多播组的群组通 告， 所述加入多播组的群组通告中携带多播地址， 以及根据所述多播地址 加入与多播地址对应的多播组。 具体的， 成员设备接收第一群组服务器发 送的加入多播组的群组通告。 其中， 第一群组服务器发送加入多播组的群 组通告可参见步骤 204的相关描述， 本发明实施例在此不再详述。
302、根据所述扇出 URI确定成员资源在成员设备上的访问路径， 以及 根据所述成员资源在成员设备上的访问路径执行成员资源访问请求的操 作。
具体的， 成员设备在收到第一群组服务器通过多播组发送的成员资源 访问请求后， 根据成员资源访问请求中携带的扇出 URI, 获取成员设备在 步骤 204中收到加入多播组的群组通告后存储的与扇出 URI对应的成员资 源， 而执行成员资源访问请求的操作。 此外， 在上述实施例中， 成员资源的成员设备还可以在加入多播组后， 接收离开多播组的群组通告， 所述离开多播组的群组通告中携带多播地址； 成员设备在收到离开多播组的群组通告后， 删除存储的与离开多播组的群 组通告中的多播地址相同的多播地址对应的多播组信息， 并退出离开多播 组的群组通告中的多播地址对应的多播组。
可选的， 上述离开多播组的群组通告中还可以携带需离开群组资源的成 员资源， 所述需离开的成员资源包含需离开群组资源的成员资源所属的成 员设备以及成员资源在成员设备上的访问路径。 成员设备在收到离开多播 组的群组通告后， 删除存储的与所述离开多播组的群组通告中的多播地址 相同的多播地址的多播组信息中需离开群组资源的成员资源； 以及删除存 储的与所述离开多播组的群组通告中的多播地址相同的多播地址的多播组 信息， 并退出所述离开多播组的群组通告中的多播地址对应的多播组。
此外， 作为一种可选实施例， 成员设备在删除存储的与所述离开多播组 的群组通告中的多播地址相同的多播地址的多播组信息， 并退出所述离开 多播组的群组通告中的多播地址对应的多播组之前， 还需要确定存储的与 所述离开多播组的群组通告中的多播地址相同的多播地址的多播组信息中 的扇出 URI不对应成员资源。
由图 3所示的实施例可知， 成员设备可以通过多播组接收到第一群组 服务器发送的成员资源访问请求， 从而第一群组服务器不需要将成员资源 访问请求分别发送给多播组的各成员设备， 从而节省了网络流量。
图 3-A为本发明实施例提供的成员设备对接收的成员资源访问请求的 处理的方法流程图， 包括如下步骤：
步骤 302-1、 接收成员资源访问请求；
具体的， 成员设备接收成员资源访问请求， 所述成员资源访问请求可 以是单播的成员资源访问请求， 也可以是多播的成员资源访问请求。
步骤 302-2、 成员设备判断成员资源访问请求是否为多播请求， 若是则 执行步骤 302-4, 否则执行步骤 302-3;
具体的， 成员设备解析成员资源访问请求， 如果成员资源访问请求的 目的地址为多播地址， 则成员资源访问请求为通过多播方式获取的， 即为 多播请求。 反之， 如果成员资源访问请求的目的地址为成员设备的单播地 址， 则不是通过多播方式获取的， 即该成员资源访问请求并不是多播请求。
步骤 302-3、 成员设备根据请求方法的具体类型， 直接返回所述请求中 目的 URI对应的本地成员资源的操作结果， 本步骤按现有技术处理；
对成员资源的操作至少包括 RESTful的几种基本操作类型之一， 包括 创建（ Create,对应于 HTTP或 CoAP协议中的 POST请求 )、获取（ Retrieve, 对应于 HTTP或 CoAP协议中的 GET请求）、 更新 ( Update, 对应于 HTTP 或 CoAP协议中的 PUT请求）、 删除（ Delete,对应于 HTTP或 CoAP协议 中的 DELETE请求），因此相应的操作结果为上述操作是否成功的状态响应 码， 以及分别包括所创建子资源的内容描述、 所获取资源的内容描述、 所 更新资源的内容描述、 所删除操作是否成功等信息。
步骤 302-4、成员设备确定本地的多播组信息中是否包含所述成员资源 访问请求中的目的 URI包含的扇出 URI指示的成员资源在成员设备上的访 问路径， 若是则执行步骤 302-8, 否则执行步骤 302-5;
步骤 302-5、成员设备确定包含与成员资源访问请求中的目的地址相同 的多播地址的多播组信息， 参考图 2-G所示的多播组资源 <mcGroup>; 步骤 302-6、成员设备判断与成员资源访问请求中的目的地址相同的多 播地址的多播组信息中是否包含与所述目的 URI相关的扇出 URI信息， 若 是则执行步骤 302-7,否则执行步骤 302-9。所述与目的 URI相关的扇出 URI 具体为： 目的 URI与多播组信息中的扇出 URI相同， 或目的 URI中包含了 多播组信息中的扇出 URI。
步骤 302-7、成员设备根据多播组信息中与扇出 URI对应的成员资源在 成员设备上的访问路径， 将目的 URI中的扇出 URI部分替换为多播组信息 中与扇出 URI对应的成员资源在成员设备上的访问路径， 将目的 URI中除 了扇出 URI的剩余部分作为后缀， 添加成员资源在成员设备上的访问路径 后面， 从而构造对本地成员资源的访问请求。 当与扇出 URI对应的成员资 源在成员设备上的访问路径为多个时， 则需要对每个成员资源分别构造对 本地成员资源的访问请求。
步骤 302-8、 成员设备根据成员资源访问请求中的方法 （比如 HTTP GET/PUT/POST/DELETE )操作成员资源， 并返回操作结果。 成员设备可以 合并多个本地成员资源的操作结果为一个， 返回给群组服务器， 也可以分 别返回多个操作结果。
步骤 302-9、 成员设备丢弃或忽略成员资源访问请求。
具体的， 根据图 3-A的描述， 假设按第一群组服务器所发送的针对表 一中的群组资源 Grp4的成员资源访问请求， 则成员设备 D1和 D5由于已 加入了与多播地址 [FF32:30:3FFE:FFFF:1 :: 1231]对应的多播组， 将收到相同 的一个访问请求如下：
GET /xxx/templ/data HTTP/1.1
Host: [FF32:30:3FFE:FFFF: 1 : : 1231 ]
则成员设备 Dl和 D5将根据目的 URI "/xxx/templ/data" 查找该 URI 所指示的本地成员资源， 并根据 GET请求方法返回相应的资源内容。
作为另一个例子， 假设按照实施例 2表 1 中的映射关系， 第一群组服 务器发送针对表二中的对群组资源 Grp7的成员资源的访问请求， 则成员设 备 D8和 D9由于已加入了多播地址 [FF32:30:3FFE:FFFF: 1 : : 1234]对应的多 播组， 将收到相同的成员资源访问请求， 如下：
GET /well-known/grp7/data HTTP/1.1
Host: [FF32:30:3FFE:FFFF: 1 :: 1234]
由于 Dl和 D5根据目的 URI well-known/grp7"无法找到在成员设备 上的访问路径为 wdl-known/grp7" 的成员资源， 但可以在本地存储的多 播组资源信息中找到包含扇出 URI well-known/grp7" 的记录， 如表 3所 示， 当然包含扇出 URI wdl-known/grp7" 的记录也可以是如图 2-G所示， 本发明实施例在此不做限定。
表 3: 成员资源映射表
<mcGroup mc Address fanoutURI member > List
D1 mcGrpX [FF32:30:3FFE:FFFF: 1 :: /well-known/grp7/ Ice
1234]
D5 mcGrpY [FF32:30:3FFE:FFFF: 1 :: /well-known/grp7/ /dd 1234]
于是 Dl和 D5分别将目的 URI中的扇出 URI部分替换为对应的本地成 员资源列表 memberList中的记录， 从而构造对应的本地成员资源访问 URI 分别为 cc/data" 和 dd/data" , 然后根据 GET请求方法返回相应的资源 内容。
图 4为本发明实施例提供的通过直接分配的多播地址的群组资源访问 方法的流程图， 包括如下步骤：
步骤 401、 网络应用服务器 NA1请求在 M2M平台 N1 (即本发明实施 例中的第一群组服务器 )上创建群组资源 GrplO, 向 N1发送群组资源创建 请求。 群组资源创建请求中包含成员资源 mlOl和 ml02。 成员资源 mlOl 和 ml02分别位于 M2M网关 G1下的两个 M2M设备 D1和 D2上。
步骤 402、 N1在本地创建群组资源 GrplO。
步骤 403、 N1分析群组资源 GrplO及其成员资源 mlOl和 ml02, 判断 可以为成员资源 mlOl和 ml02建立多播组。具体的， N1对群组资源 GrplO 及其成员资源 mlOl和 ml02的分析可参见图 2-A及上述实施例与图 2-A对 应的描述， 本发明实施例在此不在详述；
此外， N1为 D1和 D2分配相同的本地或全局多播地址， 并建立与本 地或全局多播地址相关的映射关系。 具体的， 可参见图 2-C及上述实施例 与图 2-C对应的描述， 本发明实施例在此不在详述 。
步骤 404和 404-a、 N1向成员设备 D1和 D2发送加入多播组的群组通 告， 以指示 D1和 D2加入上述多播地址对应的多播组。 所述加入多播组的 群组通告可以采用单播的方式分别向 D1和 D2逐一发送； 或者可以采用多 播的方式向成员设备 D1和 D2已经事先加入的某个多播组一次发送。 具体 的， 请参见步骤 204的相关描述， 本发明实施例在此不在详述 。
步骤 405和步骤 405-a、 成员设备 D1和 D2按照现有技术中的方法， 采用 MLD或 IGMP等多播管理协议加入所述多播群组通告中所指示的多播 地址对应的多播组。本实施例假设 G1为 D1和 D2共有的本地多播路由器， 则 D1和 D2分别向 G1发送 MLD/ IGMP report命令加入响应的多播组。
步骤 406、 NA1向 N1发送对成员资源的访问请求， 请求访问群组资源 GrplO中的所有成员资源 mlOl和 ml02。 其中， 对成员资源的访问请求携 带的信息请参考步骤 101的描述， 本发明实施例在此不在详述。
步骤 407、 N1通过群组资源标识 GrplO确定群组资源 GrplO建立了映 射关系， 构造成员资源访问请求， 并采用多播的方式将成员资源访问请求 发送到映射关系的多播地址（即多播地址）。 具体的， 本步骤的执行请参考 步骤 102的描述， 本发明实施例在此不在详述。
由于 G1在步骤 405和 405-a中获知成员设备 D1和 D2已加入了所述 多播地址对应的多播组， 因此将所述多播访问请求转发到本地链路上。
步骤 408和 408-a、 成员设备 D1和 D2接收所述多播访问请求， 并访 问所述请求中所指示的本地成员资源 mlOl和 ml02, 然后将访问结果返回 给 Nl。具体的，本步骤的请参考图 3-A及上述实施例与图 3-A对应的描述， 本发明实施例在此不在详述。
步骤 409、 N1将接收到的来自 D1和 D2的群组成员资源访问结果进行 合并。
步骤 410、 N1向 NA1返回所合并的群组成员资源访问结果。
图 5为本发明实施例提供的通过申请的全局多播地址的群组资源访问 方法的流程图， 包括如下步骤：
步骤 501、 网络应用月良务器 NA1请求在 M2M网关 G1 (即本发明实施例 中的第一群组服务器）上创建群组资源 Grpll ,向 G1发送群组资源创建请求。 群组资源创建请求中包含成员资源 ml 11和 ml 12。 成员资源 ml 11和 ml 12分 别位于 M2M平台 N 1下的两个 M2M设备 D 1和 D2上。
步骤 502、 M2M网关 G1按现有技术在本地创建群组资源 Grpl0。
步骤 503、 M2M网关 G1分析群组资源 Grpll及其成员资源 mill和 mll2, 判断可以为成员资源 mlOl和 ml02建立多播组。 具体的， M2M网 关 G1对群组资源 GrplO及其成员资源 mlOl和 ml02的分析可参见图 2-A 及上述实施例与图 2-A对应的描述， 本发明实施例在此不在详述；
此外， M2M网关 G1判断成员设备 D1和 D2不属于其本地多播域， 同 时 M2M网关 G1不能直接分配全局多播地址， 因此向具有全局多播地址分 配能力的 M2M平台 N1 (第二群组服务器 )请求为 D1和 D2分配一个全局 多播地址。 具体的， 可参考可参见图 2-C中步骤 203-2的相应描述， 本发明 实施例在此不在详述 。
步骤 504、 M2M平台 N1根据 G1的请求返回一个所分配的全局多播地 址。
步骤 505、 M2M网关 G1为 D1和 D2分配从 N1申请到的全局多播地 址， 并建立与全局多播地址相关的映射关系。 具体的， 可参见图 2-C及上 述实施例与图 2-C对应的描述， 本发明实施例在此不在详述
步骤 506和 506-a、 M2M网关 G1向成员设备 D1和 D2发送加入多播 组的群组通告， 以指示 D1和 D2加入上述多播地址对应的多播组。 所述加 入多播组的群组通告可以采用单播的方式分别向 D1和 D2逐一发送； 或者 可以采用多播的方式向成员设备 D1和 D2已经事先加入的某个多播组一次 发送。具体的，请参见步骤 204的相关描述，本发明实施例在此不在详述 。
步骤 507和步骤 507-a、 成员设备 D1和 D2按照现有技术中的方法， 采用 MLD或 IGMP等多播管理协议加入所述多播群组通告中所指示的多播 地址对应的多播组。 本实施例假设 M2M网关 N1为 D1和 D2共有的本地 多播路由器， 则 D1和 D2分别向 M2M网关 N1发送 MLD/ IGMP report命 令加入相应的多播组。
步骤 508、 将步骤 406-410中的群组资源标识换为 Grpll , 成员资源为 mill , mll2, 其余相同。
图 6为本发明实施例提供的通过远程分配的多播地址的群组资源访问 方法的流程图， 包括如下步骤：
步骤 601-602与步骤 501和 502相同， 本发明实施例在此不在详述。 步骤 603、 M2M网关 G1分析群组资源 Grpll及其成员资源 mill和 mll2, 判断可以为成员资源 mlOl和 ml02建立多播组。 具体的， M2M网 关 G1对群组资源 GrplO及其成员资源 mlOl和 ml02的分析可参见图 2-A 及上述实施例与图 2-A对应的描述， 本发明实施例在此不在详述；
此外， M2M网关 G1确定成员资源 mlOl和 ml02所属的成员设备 D1 和 D2归属于 M2M平台 N1 (即 D1和 D2注册到 N1 ), 请求在 M2M平台 N1 (第二群组服务器）上创建第二群组资源 Grpl2, 第二群组资源 Grpl2 包含成员设备 D1和 D2上的成员资源 mill和 mll2。 此时， N1作为远程 群组服务器（即第二群组服务器）。
步骤 604、 M2M平台 N1按现有技术在本地创建群组资源 Grpl2。
步骤 605、 M2M平台 N1向 M2M网关 G1返回建群组资源 Grpl2创建 成功的响应， 其中包含 Grpl2的访问标识 URI。
步骤 606、 M2M网关 G1为成员资源建立映射关系，并将 Grpl2的 URI 作为 Grpll中成员资源 mill和 mll2的扇出 URI, 将 N1的网络地址（可 以是单播或多播）作为其多播地址。 可选的， 若 G1可以为 N1分配一个本 地多播地址， 则所述映射关系中的多播地址可设为所分配的本地多播地址。 具体的， 可参考步骤 203-10的相关描述， 本发明实施例不在详述。
步骤 607、 M2M平台 N1为成员设备 D1和 D2分配相同的本地或全局 多播地址， 并建立与本地或全局多播地址相关的映射关系。 具体的， 可参 考图 2-C的相关描述。
此外， M2M平台 N1在为成员设备 D1和 D2分配相同的本地或全局多 播地址之前，还需要分析所创建群组资源 Grpl2及其成员资源 mill和 mll2 的特征， 判断可以为其建立多播组。 具体的， 可参考图 2-A及上述实施例 与图 2-A对应的描述， 本发明实施例在此不在详述。 值得说明的是， 步骤 607和步骤 605之间并没有时间上的限制， 步骤 607既可以在步骤 605之后执行，也可以在步骤 605之前执行，还可以同时 执行， 本发明实施例在此不再详述。
步骤 608和 608-a、 M2M平台 N1向成员设备 D1和 D2发送加入多播 组的群组通告， 以指示 D1和 D2加入多播地址对应的多播组。 所述加入多 播组的群组通告可以采用单播的方式分别向 D1和 D2逐一发送； 或者可以 采用多播的方式向成员设备 D1 和 D2 已经事先加入的某个多播组一次发 送。 具体的， 请参见步骤 204的相关描述， 本发明实施例在此不在详述 。
步骤 609和步骤 609-a与步骤 507和步骤 507-a相同， 本发明在此不再 详述。
步骤 610、网络应用月良务器 NA1向 M2M网关 G1发送对成员资源的访 问请求， 请求访问群组资源 Grpll中的所有成员资源 mill和 mll2。 其中， 对成员资源的访问请求携带的信息请参考步骤 101 的描述， 本发明实施例 在此不在详述。
步骤 611、 M2M网关 G1通过群组资源标识 Grpll确定群组资源 Grpll 的成员资源建立了映射关系， 构造第一成员资源访问请求， 并采用多播的 方式将成员资源访问请求发送到映射关系的多播地址（M2M平台 N1的网 络地址）， 此外， 第一成员资源访问请求的扇出 URI为 Grpll 的 URI。 若 Grpll还包含了其他本地成员资源， 则 M2M网关 G1可按向其他本地成员 设备发送单播或多播访问请求， 此处不再赘述。
步骤 612、 M2M平台 N1根据第一成员资源访问请求的扇出 URI (即 Grpll的 URI )确定为 Grpll的成员资源建立了映射关系，根据建立的映射 关系构造第二成员资源访问请求， 然后采用多播的方式发送到与 Grpll对 应的多播地址。 具体的， 本步骤的执行与步骤 407相同， 本发明实施例在 此不在详述。
步骤 613-615与步骤 408-410的描述相同，除了具体的成员资源以及收 发消息的成员设备不同以外， 本发明实施例在此不在详述。
步骤 615-617请与步骤 409-410的描述相同，本发明实施例在此不在详 述。
图 7为本发明实施例提供的群组服务器， 如前所述， M2M中的群组服 务器可以为 M2M平台， M2M网关， 也可以为 M2M设备。 即在 M2M网络 中， 只要具有业务中间件， 可以存储和维护群组资源的设备、 网关、 和平 台都可以作为群组服务器。
图 7所示的群组服务器包括接收模块 701 , 获取模块 702和发送模块 703, 处理模块 704。 具体的，
接收模块 701 , 用于接收对成员资源的访问请求， 所述对成员资源的访 问请求中携带成员资源所属群组资源的群组资源标识； 获取模块 702, 用于 根据所述群组资源标识获取群组资源中与所述扇出 URI对应的扇出 URI, 以 及与成员资源对应的多播地址，所述扇出 URI用于指示成员资源在成员设备 上的访问路径； 发送模块 703, 用于根据所述多播地址向所述成员资源所属 的成员设备发送成员资源访问请求，所述成员资源访问请求的目的 URI包含 与所述成员资源对应的扇出 URI;以便所述成员资源所属的成员设备根据所 述扇出 URI指示的成员资源在成员设备上的访问路径执行所述成员资源访 问请求指示的操作。
可选的， 接收模块 701进一步用于接收群组资源创建请求， 所述群组资 源创建请求中携带各成员资源， 所述成员资源包括所述成员资源所属的成 员设备以及成员资源在成员设备上的访问路径； 所述群组服务器还包括处 理模块 704, 用于根据成员资源所属的成员设备以及成员资源在成员设备上 的访问路径为所述成员资源分配多播地址以及根据成员资源在成员设备上 的访问路径建立所述所述多播地址及所述扇出 URI之间的映射关系。
可选的， 处理模块 704具体为： 用于为在成员设备上具有相同访问路径 的成员资源分配多播地址， 并建立所述多播地址及所述扇出 URI的映射关 系；所述扇出 URI为所述成员资源在成员设备上的访问路径； 和 /或用于为在 成员设备上具有不同访问路径的至少一个成员资源分配虚拟标识， 为所述 至少一个成员资源分配多播地址， 并建立所述多播地址及所述虚拟标识的 映射关系以及所述虚拟标识和成员资源的映射关系； 将所述虚拟标识设为 所述扇出 URI。
可选的， 发送模块 703进一步用于： 根据多播地址及所述扇出 URI的映射 关系向成员资源所属的成员设备发送加入多播组的群组通告， 所述加入多 播组的群组通告中携带多播地址， 以便于成员资源所属的成员设备根据加 入多播组的群组通告加入与所述多播地址对应的多播组。
可选的， 处理模块 704根据成员资源所属的成员设备以及成员资源在成 员设备上的访问路径为所述成员资源分配多播地址具体为： 根据成员资源 所属的成员设备确定所述成员资源所属的成员设备归属于第一群组服务 器， 为成员资源所属的成员设备分配本地多播域的多播地址； 或根据成员 资源所属的成员设备确定所述成员资源所属的成员设备并不都归属于第一 群组服务器， 为成员资源所属的成员设备分配全局多播域的多播地址或请 求为不归属于第一群组服务器的成员资源所属的成员设备分配远程多播域 的多播地址。
可选的， 处理模块 704为成员资源所属的成员设备分配全局多播域的多 播地址具体为： 向具有全局多播域的多播地址的群组服务器申请全局多播 域的多播地址， 为成员资源所属的成员设备分配申请的全局多播域的多播 地址； 所述请求为不归属于第一群组服务器的成员资源所属的成员设备分 配远程多播域的多播地址具体为： 确定不归属于第一群组服务器的成员资 源所属的成员设备归属于第二群组服务器， 向第二群组服务器发送创建第 二群组资源请求， 所述创建第二群组资源请求携带第一群组资源标识以及 成员资源， 所述成员资源包含成员资源所属的成员设备以及成员资源在成 员设备上的访问路径； 第二群组服务器根据成员资源所属的成员设备以及 成员资源在成员设备上的访问路径创建第二群组资源以及为成员资源分配 多播地址
可选的， 处理模块 704根据成员资源所属的成员设备为所述成员资源分 配多播地址具体为： 根据成员资源所属的成员设备确定所述成员资源所属 的成员设备和成员设备所属的网络支持多播， 并为所述成员资源分配多播 地址； 所述处理模块 704还用于： 存储不具有多播能力的成员设备对应的成 员资源， 以便于群组服务器为不具有多播能力的成员设备单播对成员资源 的访问请求。
可选的， 处理模块 704还用于： 将对成员资源的访问请求的目的地址设 置为与所述扇出 URI对应的多播地址， 将对成员资源的访问请求的目的 URI 设为所述与成员资源对应的扇出 URI, 以生成成员资源访问请求， 以及还用 于利用所述多播地址发送携带所述与成员资源对应的扇出 URI的成员资源 访问请求。
可选的， 处理模块 704还用于确定所述对成员资源的访问请求中的目的 URI还包含后缀； 将对成员资源的访问请求的目的地址设置与所述扇出 UIR 对应的多播地址，将对成员资源的访问请求的目的 URI设为所述与成员资源 对应的扇出 URI以及在所述扇出 URI后面添加所述目的 URI包含的后缀， 以 生成成员资源访问请求。
可选的， 接收模块 701还用于接收增加成员资源的群组资源更新请求， 所述增加成员资源的群组资源更新请求中携带群组资源的标识以及需加入 群组资源的成员资源， 所述需加入群组资源的成员资源包括所述成员资源 所属的成员设备以及成员资源在成员设备上的访问路径； 处理模块 704还用 于还用于根据群组资源的标识确定需加入群组资源的成员资源在成员设备 上的访问路径和与群组资源的标识对应的群组资源中的所述多播地址和扇 出 URI的映射关系中的扇出 URI相同， 向需加入群组资源的成员资源所属的 成员设备发送携带所述多播地址和扇出 URI的映射关系中的多播地址的加 入多播组的群组通告， 以便于需加入群组资源的成员资源所属的成员设备 通过所述多播地址加入多播组， 以及接收通过多播地址发送的成员资源访 问请求；
可选的， 处理模块 704还用于根据群组资源的标识确定需加入群组资源 的成员资源在成员设备上的访问路径和与群组资源的标识对应的群组资源 中的所述多播地址和扇出 URI的映射关系中的扇出 URI不同； 在与群组资源 的标识对应的群组资源中的扇出 URI和成员资源的映射关系中增加需加入 群组资源的成员资源， 向需加入群组资源的成员资源所属的成员设备发送 加入多播组的群组通告， 所述加入多播组的群组通告携带与群组资源的标 识对应的群组资源中的所述多播地址和扇出 URI的映射关系， 和扇出 URI与 成员资源在成员设备上的访问路径的映射关系； 以便于成员设备在接收到 携带所述扇出 URI的访问请求后， 根据接收到的扇出 URI与成员资源的映射 关系确定成员资源在成员设备的访问路径， 并根据确定的成员资源在成员 设备上的访问路径执行相应的成员资源访问请求。
可选的， 接收模块 701还用于接收删除成员资源的群组资源更新请求， 所述删除成员资源的群组资源更新请求中携带需离开群组资源的成员资源 和群组资源的标识， 所述需离开群组资源的成员资源包括所述成员资源所 属的成员设备以及成员资源在成员设备上的访问路径； 所述处理模块还用 于： 根据群组资源的标识确定与需离开群组资源的成员资源对应的扇出 URI, 以及与需离开群组资源的成员资源对应扇出 URI和多播地址的映射关 系， 删除所述映射关系中的需离开群组资源的成员资源， 向需离开的成员 资源所属的成员设备发送携带与需离开群组资源的成员资源对应扇出 URI 和多播地址的映射关系中的多播地址的离开多播组的群组通告， 以便于需 离开的成员资源所属的成员设备离开所述多播地址指示的多播组；
可选的， 接收模块还用于接收删除成员资源的群组资源更新请求， 所述 删除成员资源的群组资源更新请求中携带需保留的群组资源的成员资源和 群组资源的标识， 所述需保留的群组资源的成员资源包含成员资源所属的 成员设备以及成员资源在成员设备上的访问路径； 所述处理模块还用于根 据群组资源的标识确定需离开群组资源的成员资源和扇出 UIR的映射关系， 利用需保留的群组资源的成员资源更新所述需离开群组资源的成员资源和 扇出 UIR的映射关系中成员资源；向需离开的成员资源所属的成员设备发送 携带映射关系中的多播地址的离开多播组的群组通告， 以便于需离开的成 员资源所属的成员设备离开所述多播地址指示的多播组。
可选的， 处理模块 704还用于： 根据删除成员资源的群组资源更新请求 的群组资源的标识确定需离开群组资源的成员资源在成员设备上的访问路 径和需离开的成员资源对应的扇出 URI不同；所述离开多播组的群组通告还 包括与需离开群组资源的成员资源对应的所述扇出 URI; 以便于需离开群组 资源的成员资源所属的成员设备离开所述多播地址指示的多播组， 并根据 所述需离开群组资源的成员资源和离开多播组的群组通告中的扇出 URI删 除成员设备中与删除成员资源的群组资源更新请求的群组资源的标识对应 的多播组信息中的成员资源。
图 8为本发明实施例提供的成员设备，可以为 M2M平台， M2M网关， 也可以为 M2M设备。 即在 M2M网络中， 只要存储有资源的设备、 网关、 和平台都可以作为成员设备。 具体的， 成员设备包括： 接收模块 801 和操 作模块 802。
具体的， 接收模块 801 , 用于接收群组服务器发送的成员资源访问请求， 所述成员资源访问请求为多播的成员资源访问请求， 所述成员资源访问请 求中包含与所述成员资源对应的扇出 URI, 所述扇出 URI用于指示成员资源 在成员设备上的访问路径； 操作模块 802, 用于根据所述扇出 URI确定成员 资源在成员设备上的访问路径， 以及根据所述成员资源在成员设备上的访 问路径执行访问请求的操作。
可选的， 接收模块 801进一步用于： 接收加入多播组的群组通告， 所述 加入多播组的群组通告中携带多播地址， 根据加入多播组的群组通告加入 与所述多播地址对应的多播组。
可选的， 加入多播组的群组通告中还携带所述扇出 URI和成员资源在成 员设备上的访问路径的映射关系， 所述成员设备进一步包括存储模块 803 , 用于存储所述扇出 URI和所述多播地址映射关系以及所述成员资源和所述 多播地址的映射关系。
可选的， 成员设备进一步包括确定模块 804用于确定成员资源访问请求 的目的地址为多播地址。
可选的，操作模块 802根据所述扇出 URI确定成员资源在成员设备上的访 问路径具体为具体为： 确定包含与成员资源访问请求中的目的地址相同的 多播地址的多播组信息， 确定与成员资源访问请求中的目的地址相同的多 播地址的多播组信息中包含与所述成员资源访问请求中的目的 URI相同的 扇出 URI, 确定多播组信息中与扇出 URI对应的成员资源在成员设备上的访 问路径。
可选的， 操作模块 802根据所述成员资源在成员设备上的访问路径执行 访问请求的操作具体为：将所述成员资源访问请求中的目的 URI包含的扇出 URI用确定的成员资源在成员设备上的访问路径替换，并针对与确定的成员 资源在成员设备上的访问路径对应的成员资源执行访问请求的操作。
可选的， 接收模块 801进一步用于： 接收离开多播组的群组通告， 所述 离开多播组的群组通告中携带多播地址； 存储模块 803进一步用于， 删除存 储的与离开多播组的群组通告中的多播地址相同的多播地址对应的多播组 信息， 并退出所述离开多播组的群组通告中的多播地址对应的多播组。
可选的， 接收模块 801进一步用于： 接收离开多播组的群组通告， 所述 离开多播组的群组通告中携带多播地址和需离开的成员资源， 所述需离开 的成员资源包含需离开群组资源的成员资源所属的成员设备以及成员资源 在成员设备上的访问路径； 存储模块 803进一步用于删除存储的与所述离开 多播组的群组通告中的多播地址相同的多播地址的多播组信息中需离开群 组资源的成员资源； 以及删除存储的与所述离开多播组的群组通告中的多 播地址相同的多播地址的多播组信息， 并退出所述离开多播组的群组通告 中的多播地址对应的多播组。
进一步的， 存储模块 803在删除存储的与所述离开多播组的群组通告中 的多播地址相同的多播地址的多播组信息， 并退出所述离开多播组的群组 通告中的多播地址对应的多播组之前， 还需要确定存储的与所述离开多播 组的群组通告中的多播地址相同的多播地址的多播组信息中的扇出 URI不 对应成员资源
上述针对群组服务器或成员设备中包含的各模块的处理功能的实施方 式在之前的方法实施例中已经描述， 在此不再重复描述。 此外， 在 M2M网 络中， M2M平台可以是各计算机， 具有处理器的设备。 M2M网关和 M2M终 端在设备上没有严格的区分， 比如做网关的设备也可以做为终端， 此外为 各种终端设备， 如手机， 计算机， PDA, 笔记本电脑， 远程控制器， 家用 电器， 各种仪器仪表、 传感器等都可以做为 M2M网络的网关或终端。 在上 述模块实施例中， 所包括的各个单元只是按照功能逻辑进行划分的， 但并 不局限于上述的划分， 只要能够实现相应的功能即可； 另外， 各功能单元 的具体名称也只是为了便于相互区分， 并不用于限制本发明的保护范围。 上述实现成员设备执行的方法及成员设备各功能模块的功能均可以由成员 设备的处理器完成， 以及上述实现群组服务器执行的方法及群组服务器各 功能模块的功能均可以由群组服务器的处理器完成。
采用上述本发明的实施例提供的技术方案可以看出， 通过建立成员资 源在成员设备上的访问路径与扇出 URI的映射关系，并在成员访问请求中包 含所述扇出 URI; 以便所述成员资源所属的成员设备根据所述扇出 URI指示 的所述成员资源在成员设备上的访问路径执行所述成员访问请求指示的操 作。从而使得不同的成员设备能够通过使用多播技术利用扇出 URI, 解析多 播的对成员资源的访问请求， 以及针对访问请求进行后续的操作。 从而使 得群组服务器不需要对各成员设备单播访问请求， 节省网络开销。 以上所述， 仅为本发明较佳的具体实施方式， 但本发明的保护范围并 不局限于此， 任何熟悉本技术领域的技术人员在本发明揭露的技术范围内， 可轻易想到的变化或替换， 都应涵盖在本发明的保护范围之内。 因此， 本 发明的保护范围应该以权利要求的保护范围为准。

Claims

权利要求
1. 一种成员资源的访问方法， 其特征在于， 包括：
接收对成员资源的访问请求， 所述对成员资源的访问请求中携带成员 资源所属群组资源的群组资源标识；
根据所述群组资源标识获取群组资源中与成员资源对应的扇出通用资 源标识符 URI, 以及与所述扇出 URI对应的多播地址， 所述扇出 URI用于指 示成员资源在成员设备上的访问路径；
根据所述多播地址向所述成员资源所属的成员设备发送成员资源访问 请求， 所述成员资源访问请求的目的 URI包含与所述成员资源对应的扇出 URI; 以便所述成员资源所属的成员设备根据所述扇出 URI指示的成员资源 在成员设备上的访问路径执行所述成员资源访问请求指示的操作。
2. 如权利要求 1所述的方法， 其特征在于， 该方法进一步包括： 接收群组资源创建请求， 所述群组资源创建请求中携带各成员资源， 所述成员资源包括所述成员资源所属的成员设备以及成员资源在成员设备 上的访问路径；
根据所述成员资源所属的成员设备以及成员资源在成员设备上的访问 路径为所述成员资源分配多播地址； 根据成员资源在成员设备上的访问路 径建立所述多播地址和所述扇出 URI的映射关系。
3. 如权利要求 2所述的方法， 其特征在于， 所述根据成员资源所属的 成员设备以及成员资源在成员设备上的访问路径为所述成员资源分配多播 地址， 以及根据成员资源在成员设备上的访问路径建立所述多播地址及所 述扇出 URI之间的映射关系具体为：
为在成员设备上具有相同访问路径的成员资源分配多播地址， 并建立 所述多播地址及所述扇出 URI的映射关系； 所述扇出 URI为所述成员资源在 成员设备上的访问路径； 和 /或
为在成员设备上具有不同访问路径的至少一个成员资源分配虚拟标 识， 为所述至少一个成员资源分配多播地址， 并为建立所述多播地址及所 述虚拟标识的映射关系以及所述虚拟标识和成员资源的映射关系； 将所述 虚拟标识设为所述扇出 URI。
4. 如权利要 2或 3所述的方法， 其特征在于， 该方法进一步包括： 根据所述多播地址及所述扇出 URI的映射关系向成员资源所属的成员设 备发送加入多播组的群组通告， 所述加入多播组的群组通告中携带多播地 址， 以便于成员资源所属的成员设备根据加入多播组的群组通告加入与所 述多播地址对应的多播组。
5. 如权利要求 4所述的方法， 其特征在于，
所述加入多播组的群组通告中还携带所述所述扇出 URI和成员资源的映 射关系，以便所述成员资源所属的成员设备存储所述扇出 URI和所述多播地 址映射关系， 以及所述成员资源和所述多播地址的映射关系；
所述以便所述成员资源所属的成员设备根据所述扇出 URI指示的成员资 源在成员设备上的访问路径执行所述成员资源访问请求指示的操作具体 为： 所述成员资源所属的成员设备在接收到携带所述扇出 URI的访问请求 后， 根据接收到的所述扇出 URI以及根据所述扇出 URI和成员资源映射关系 确定成员资源在成员设备上的访问路径， 并根据确定的成员资源在成员设 备上的访问路径执行相应的成员资源访问请求。
6. 如权利要求 2-5任一所述的方法， 其特征在于， 所述根据成员资源所 属的成员设备以及成员资源在成员设备上的访问路径为所述成员资源分配 多播地址具体为：
根据所述成员资源所属的成员设备确定所述成员资源所属的成员设备 归属于第一群组服务器， 为成员资源所属的成员设备分配本地多播域的多 播地址； 或
根据所述成员资源所属的成员设备确定所述群组资源的成员资源所属 的成员设备并不都归属于第一群组服务器， 为成员资源所属的成员设备分 配全局多播域的多播地址或请求为不归属于第一群组服务器的成员资源所 属的成员设备分配远程多播域的多播地址。
7. 如权利要求 6所述的方法， 其特征在于，
所述为成员资源所属的成员设备分配全局多播域的多播地址具体为： 向 具有全局多播域的多播地址的群组服务器申请全局多播域的多播地址， 为 成员资源所属的成员设备分配申请的全局多播域的多播地址；
所述请求为不归属于第一群组服务器的成员资源所属的成员设备分配 远程多播域的多播地址具体为： 确定不归属于第一群组服务器的成员资源 所属的成员设备归属于第二群组服务器， 向第二群组服务器发送创建第二 群组资源请求， 所述创建第二群组资源请求携带第一群组资源标识以及成 员资源， 所述成员资源包含成员资源所属的成员设备以及成员资源在成员 设备上的访问路径； 第二群组服务器根据所述成员资源所属的成员设备创 建第二群组资源以及为成员资源分配多播地址。
8. 如权利要求 2-7任一所述的方法， 其特征在于， 所述根据成员资源所 属的成员设备以及成员资源在成员设备上的访问路径为所述成员资源分配 多播地址具体为：
根据所述成员资源所属的成员设备确定所述成员资源所属的成员设备 和成员设备所属的网络支持多播， 并为所述成员资源分配多播地址；
所述方法还包括：
存储不具有多播能力的成员设备对应的成员资源， 以便于群组服务器为 不具有多播能力的成员设备单播对成员资源的访问请求。
9. 如权利要求 1-8任一所述的方法， 其特征在于， 所述根据所述群组资 源标识获取群组资源中与成员资源对应的扇出 URI以及与所述扇出 URI对 应的多播地址之后， 该方法还包括：
将对成员资源的访问请求的目的地址设置为与所述扇出 URI对应的多播 地址， 将对成员资源的访问请求的目的 URI设为所述与成员资源对应的扇 出 URI, 以生成成员资源访问请求；
利用所述多播地址发送携带所述与成员资源对应的扇出 URI的成员资源 访问请求。
10. 如权利要求 1-8任一所述的方法， 其特征在于， 所述根据所述群组资 源标识获取群组资源中与成员资源对应的扇出 URI以及与所述扇出 URI对 应的多播地址之后， 该方法还包括：
确定所述对成员资源的访问请求中的目的 URI还包含后缀；
将对成员资源的访问请求的目的地址设置为与所述扇出 UIR对应的多播 地址， 将所述目的 URI设为所述与成员资源对应的扇出 URI以及在所述扇出 URI后面添加所述目的 URI包含的后缀， 以生成成员资源访问请求。
11、 如权利要求 2-10任一所述的方法， 其特征在于， 该方法还包括： 接收增加成员资源的群组资源更新请求， 所述增加成员资源的群组资源 更新请求中携带群组资源的标识以及需加入群组资源的成员资源， 所述需 加入群组资源的成员资源包括所述成员资源所属的成员设备以及成员资源 在成员设备上的访问路径；
根据群组资源的标识确定需加入群组资源的成员资源在成员设备上的 访问路径和与群组资源的标识对应的群组资源中的所述多播地址和扇出 URI的映射关系中的扇出 URI相同， 向需加入群组资源的成员资源所属的成 员设备发送携带所述多播地址和扇出 URI的映射关系中的多播地址的加入 多播组的群组通告， 以便于需加入群组资源的成员资源所属的成员设备通 过所述多播地址加入多播组， 以及接收通过多播地址发送的成员资源访问 请求； 或
根据群组资源的标识确定需加入群组资源的成员资源在成员设备上的 访问路径和与群组资源的标识对应的群组资源中的所述多播地址和扇出 URI的映射关系中的扇出 URI不同； 在与群组资源的标识对应的群组资源中 的扇出 URI和成员资源的映射关系中增加需加入群组资源的成员资源，向需 加入群组资源的成员资源所属的成员设备发送加入多播组的群组通告， 所 述加入多播组的群组通告携带与群组资源的标识对应的群组资源中的所述 多播地址和扇出 URI的映射关系，和与群组资源的标识对应的群组资源中的 扇出 URI和成员资源的映射关系； 以便于成员设备在接收到携带所述扇出 URI的访问请求后， 根据接收到的扇出 URI与成员资源的映射关系确定成员 资源在成员设备上的访问路径， 并根据确定的成员资源在成员设备上的访 问路径执行相应的成员资源访问请求。
12、 如权利要求 2-11任一所述的方法， 其特征在于， 该方法还包括： 接收删除成员资源的群组资源更新请求， 所述删除成员资源的群组资源 更新请求中携带需离开群组资源的成员资源和群组资源的标识， 所述需离 开群组资源的成员资源包括所述成员资源所属的成员设备以及成员资源在 成员设备上的访问路径； 根据群组资源的标识确定与需离开群组资源的成 员资源对应的扇出 URI, 以及与需离开群组资源的成员资源对应的扇出 URI 和多播地址的映射关系， 删除所述与需离开群组资源的成员资源对应的扇 出 URI和多播地址的映射关系中的需离开群组资源的成员资源，向需离开的 成员资源所属的成员设备发送携带与需离开群组资源的成员资源对应扇出 URI和多播地址的映射关系中的多播地址的离开多播组的群组通告，以便于 需离开的成员资源所属的成员设备离开所述多播地址指示的多播组； 或 删除成员资源的群组资源更新请求中携带需保留的群组资源的成员资 源和群组资源的标识， 所述需保留的群组资源的成员资源包含成员资源所 属的成员设备以及成员资源在成员设备上的访问路径； 根据群组资源的标 识确定与需离开群组资源的成员资源和扇出 UIR的映射关系，利用需保留的 群组资源的成员资源更新所述需离开群组资源的成员资源和扇出 UIR的映 射关系中成员资源， 向需离开的成员资源所属的成员设备发送携带映射关 系中的多播地址的离开多播组的群组通告， 以便于需离开的成员资源所属 的成员设备离开所述多播地址指示的多播组。
13、 如权利要求 12所述的方法， 其特征在于， 该方法进一步包括： 根据删除成员资源的群组资源更新请求的群组资源的标识确定需离开 群组资源的成员资源在成员设备上的的访问路径和需离开的成员资源对应 的扇出 URI不同；
所述离开多播组的群组通告还包括与需离开群组资源的成员资源对应 的所述扇出 URI; 以便于需离开群组资源的成员资源所属的成员设备离开所 述多播地址指示的多播组， 并根据所述需离开群组资源的成员资源和离开 多播组的群组通告中的扇出 URI删除成员设备中与删除成员资源的群组资 源更新请求的群组资源的标识对应的多播组信息中的成员资源。
14、 一种群组资源的访问方法， 其特征在于： 包括
接收群组服务器发送的成员资源访问请求， 所述成员资源访问请求为多 播的成员资源访问请求， 所述成员资源访问请求中包含与所述成员资源对 应的扇出 URI, 所述扇出 URI用于指示成员资源在成员设备上的访问路径； 根据所述扇出 URI确定成员资源在成员设备上的访问路径， 以及根据所 述成员资源在成员设备上的访问路径执行访问请求的操作。
15、 如权利要求 14所述的方法， 其特征在于， 该方法进一步包括： 接收加入多播组的群组通告， 所述加入多播组的群组通告中携带多播地 址， 根据加入多播组的群组通告加入与所述多播地址对应的多播组。
16、 如权利要求 15所述的方法， 其特征在于， 所述加入多播组的群组通 告中还携带所述扇出 URI和成员资源的映射关系； 所述方法进一步包括： 存储所述多播地址和所述扇出 URI的映射关系， 以及所述成员资源和所 述多播地址的映射关系。
17、如权利要求 14-16任一所述的方法，其特征在于，该方法进一步包括： 确定成员资源访问请求的目的地址为多播地址。
18、 如权利要求 17所述的方法， 其特征在于， 所述根据所述扇出 URI确 定成员资源在成员设备上的访问路径具体为： 确定包含与成员资源访问请求中的目的地址相同的多播地址的多播组 信息， 确定与成员资源访问请求中的目的地址相同的多播地址的多播组信 息中包含与所述成员资源访问请求中的目的 URI相同的扇出 URI, 确定多播 组信息中与扇出 URI对应的成员资源在成员设备上的访问路径。
19、如权利要求 14-18任一所述的方法，所述根据所述成员资源在成员设 备上的访问路径执行访问请求的操作具体为： ：
将所述成员资源访问请求中的目的 URI包含的扇出 URI用确定的成员资 源在成员设备上的访问路径替换， 并针对与确定的成员资源在成员设备上 的访问路径对应的成员资源执行访问请求的操作。
20、如权利要求 14-19任一所述的方法，其特征在于，该方法进一步包括： 接收离开多播组的群组通告， 所述离开多播组的群组通告中携带多播地 址；
删除存储的与离开多播组的群组通告中的多播地址相同的多播地址对 应的多播组信息， 并退出所述离开多播组的群组通告中的多播地址对应的 多播组。
21、如权利要求 14-20任一所述的方法，其特征在于，该方法进一步包括： 接收离开多播组的群组通告， 所述离开多播组的群组通告中携带需离开 的多播组对应的多播地址以及需离开群组资源的成员资源， 所述需离开的 成员资源包含需离开群组资源的成员资源所属的成员设备以及成员资源在 成员设备上的访问路径；
删除存储的与所述离开多播组的群组通告中的多播地址相同的多播地 址的多播组信息中需离开群组资源的成员资源；
删除存储的与所述离开多播组的群组通告中的多播地址相同的多播地 址的多播组信息， 并退出所述离开多播组的群组通告中的多播地址对应的 多播组。
22、 如权利要求 21所述的方法， 其特征在于， 该方法进一步包括： 确定存储的与所述离开多播组的群组通告中的多播地址相同的多播地 址的多播组信息中的扇出 URI不对应成员资源。
23、 一种群组服务器， 其特征在于， 包括：
接收模块， 用于接收对成员资源的访问请求， 所述对成员资源的访问 请求中携带成员资源所属群组资源的群组资源标识； 应的扇出 URI, 以及与所述扇出 URI对应的多播地址， 所述扇出 URI用于指 示成员资源在成员设备上的访问路径；
发送模块， 用于根据所述多播地址向所述成员资源所属的成员设备发 送成员资源访问请求，所述成员资源访问请求的目的 URI包含与所述成员资 源对应的扇出 URI; 以便所述成员资源所属的成员设备根据所述扇出 URI指 示的成员资源在成员设备上的访问路径执行所述成员资源访问请求指示的 操作。
24、 如权利要求 23所述的群组服务器， 其特征在于，
所述接收模块进一步用于接收群组资源创建请求， 所述群组资源创建请 求中携带各成员资源， 所述成员资源包括所述成员资源所属的成员设备以 及成员资源在成员设备上的访问路径；
所述群组服务器还包括： 处理模块， 用于根据所述成员资源所属的成员 设备以及成员资源在成员设备上的访问路径为所述成员资源分配多播地 址； 以及根据成员资源在成员设备上的访问路径建立所述多播地址及所述 扇出 URI之间的映射关系。
25、 如权利要求 24所述的群组服务器， 其特征在于，
所述处理模块具体为： 用于为在成员设备上具有相同访问路径的成员资 源分配多播地址， 并建立所述多播地址及所述扇出 URI的映射关系； 所述扇 出 URI为所述成员资源在成员设备上的访问路径； 和 /或
用于为在成员设备上具有不同访问路径的至少一个成员资源分配虚拟 标识， 为所述至少一个成员资源分配多播地址， 并建立所述多播地址及所 述虚拟标识的映射关系以及所述虚拟标识和成员资源的映射关系； 将所述 虚拟标识设为所述扇出 URI。
26、 如权利要求 24所述的群组服务器， 其特征在于，
所述发送模块进一步用于： 根据所述多播地址及所述扇出 URI的映射关 系向成员资源所属的成员设备发送加入多播组的群组通告， 所述加入多播 组的群组通告中携带多播地址， 以便于成员资源所属的成员设备根据加入 多播组的群组通告加入与所述多播地址对应的多播组。
27、 如权利要求 24-26任一所述的群组服务器， 其特征在于， 所述处理模 块根据成员资源所属的成员设备以及成员资源在成员设备上的访问路径为 所述成员资源分配多播地址具体为：
根据所述成员资源所属的成员设备确定所述成员资源所属的成员设备 归属于第一群组服务器， 为成员资源所属的成员设备分配本地多播域的多 播地址； 或
根据所述成员资源所属的成员设备确定所述群组资源的成员资源所属 的成员设备并不都归属于第一群组服务器， 为成员资源所属的成员设备分 配全局多播域的多播地址或请求为不归属于第一群组服务器的成员资源所 属的成员设备分配远程多播域的多播地址。
28、 如权利要求 27所述的群组服务器， 其特征在于， 所述处理模块为成 员资源所属的成员设备分配全局多播域的多播地址具体为： 向具有全局多 播域的多播地址的群组服务器申请全局多播域的多播地址， 为成员资源所 属的成员设备分配申请的全局多播域的多播地址；
所述请求为不归属于第一群组服务器的成员资源所属的成员设备分配 远程多播域的多播地址具体为： 确定不归属于第一群组服务器的成员资源 所属的成员设备归属于第二群组服务器， 向第二群组服务器发送创建第二 群组资源请求， 所述创建第二群组资源请求携带第一群组资源标识以及成 员资源， 所述成员资源包含成员资源所属的成员设备以及成员资源在成员 设备上的访问路径； 第二群组服务器根据成员资源所属的成员设备以及成 员资源在成员设备上的访问路径创建第二群组资源以及为成员资源分配多 播地址。
29、 如权利要求 24-28任一所述的群组服务器， 其特征在于： 所述处理模 块根据成员资源所属的成员设备为所述成员资源分配多播地址具体为： 根 据成员资源所属的成员设备确定所述成员资源所属的成员设备和成员设备 所属的网络支持多播， 并为所述成员资源分配多播地址；
所述处理模块还用于： 存储不具有多播能力的成员设备对应的成员资 源， 以便于群组服务器为不具有多播能力的成员设备单播对成员资源的访 问请求。
30、 如权利要求 24-29任一所述的群组服务器， 其特征在于， 所述处理模 块还用于：将对成员资源的访问请求的目的地址设置为与所述扇出 URI对应 的多播地址，将对成员资源的访问请求的目的 URI设为所述与成员资源对应 的扇出 URI, 以生成成员资源访问请求， 以及还用于利用所述多播地址发送 携带所述与成员资源对应的扇出 URI的成员资源访问请求。
31、 如权利要求 24-29任一所述的群组服务器， 其特征在于，
所述处理模块还用于确定所述对成员资源的访问请求中的目的 URI还包 含后缀；将对成员资源的访问请求的目的地址设置与所述扇出 UIR对应的多 播地址，将对成员资源的访问请求的目的 URI设为所述与成员资源对应的扇 出 URI以及在所述扇出 URI后面添加所述目的 URI包含的后缀， 以生成成员 资源访问请求。
32、 如权利要求 25-31任一所述的群组服务器， 其特征在于，
所述接收模块还用于接收增加成员资源的群组资源更新请求， 所述增加 成员资源的群组资源更新请求中携带群组资源的标识以及需加入群组资源 的成员资源， 所述需加入群组资源的成员资源包括所述成员资源所属的成 员设备以及成员资源在成员设备上的访问路径；
所述处理模块还用于根据群组资源的标识确定需加入群组资源的成员 资源在成员设备上的访问路径和与群组资源的标识对应的群组资源中的所 述多播地址和扇出 URI的映射关系中的扇出 URI相同， 向需加入群组资源的 成员资源所属的成员设备发送携带所述多播地址和扇出 URI的映射关系中 的多播地址的加入多播组的群组通告， 以便于需加入群组资源的成员资源 所属的成员设备通过所述多播地址加入多播组， 以及接收通过多播地址发 送的成员资源访问请求； 或
所述处理模块还用于根据群组资源的标识确定需加入群组资源的成员 资源在成员设备上的访问路径和与群组资源的标识对应的群组资源中的所 述多播地址和扇出 URI的映射关系中的扇出 URI不同； 在与群组资源的标识 对应的群组资源中的扇出 URI和成员资源的映射关系中增加需加入群组资 源的成员资源， 向需加入群组资源的成员资源所属的成员设备发送加入多 播组的群组通告， 所述加入多播组的群组通告携带与群组资源的标识对应 的群组资源中的所述多播地址和扇出 URI的映射关系， 和扇出 URI与成员资 源在成员设备上的访问路径的映射关系； 以便于成员设备在接收到携带所 述扇出 URI的访问请求后， 根据接收到的扇出 URI与成员资源的映射关系确 定成员资源在成员设备的访问路径， 并根据确定的成员资源在成员设备上 的访问路径执行相应的成员资源访问请求。
33、 如权利要求 25-32任一所述的群组服务器， 其特征在于，
所述接收模块还用于接收删除成员资源的群组资源更新请求， 所述删除 成员资源的群组资源更新请求中携带需离开群组资源的成员资源和群组资 源的标识， 所述需离开群组资源的成员资源包括所述成员资源所属的成员 设备以及成员资源在成员设备上的访问路径； 所述处理模块还用于： 根据 群组资源的标识确定与需离开群组资源的成员资源对应的扇出 URI, 以及与 需离开群组资源的成员资源对应扇出 URI和多播地址的映射关系，删除所述 映射关系中的需离开群组资源的成员资源， 向需离开的成员资源所属的成 员设备发送携带与需离开群组资源的成员资源对应扇出 URI和多播地址的 映射关系中的多播地址的离开多播组的群组通告， 以便于需离开的成员资 源所属的成员设备离开所述多播地址指示的多播组； 或
所述接收模块还用于接收删除成员资源的群组资源更新请求， 所述删除 成员资源的群组资源更新请求中携带需保留的群组资源的成员资源和群组 资源的标识， 所述需保留的群组资源的成员资源包含成员资源所属的成员 设备以及成员资源在成员设备上的访问路径； 所述处理模块还用于根据群 组资源的标识确定需离开群组资源的成员资源和扇出 UIR的映射关系，利用 需保留的群组资源的成员资源更新所述需离开群组资源的成员资源和扇出 UIR的映射关系中成员资源；向需离开的成员资源所属的成员设备发送携带 映射关系中的多播地址的离开多播组的群组通告， 以便于需离开的成员资 源所属的成员设备离开所述多播地址指示的多播组。
34、 如权利要求 33所述的群组服务器， 其特征在于，
所述处理模块还用于： 根据删除成员资源的群组资源更新请求的群组资 源的标识确定需离开群组资源的成员资源在成员设备上的访问路径和需离 开的成员资源对应的扇出 URI不同；
所述离开多播组的群组通告还包括与需离开群组资源的成员资源对应 的所述扇出 URI;以便于需离开群组资源的成员资源所属的成员设备离开所 述多播地址指示的多播组， 并根据所述需离开群组资源的成员资源和离开 多播组的群组通告中的扇出 URI删除成员设备中与删除成员资源的群组资 源更新请求的群组资源的标识对应的多播组信息中的成员资源。
35、 一种成员设备， 其特征在于， 包括：
接收模块， 用于接收群组服务器发送的成员资源访问请求， 所述成员资 源访问请求为多播的成员资源访问请求， 所述成员资源访问请求中包含与 所述成员资源对应的扇出 URI, 所述扇出 URI用于指示成员资源在成员设备 上的访问路径；
操作模块， 用于根据所述扇出 URI确定成员资源在成员设备上的访问路 径， 以及根据所述成员资源在成员设备上的访问路径执行访问请求的操作。
36、 如权利要求 35所述的成员设备， 其特征在于， 所述接收模块进一步 用于： 接收加入多播组的群组通告， 所述加入多播组的群组通告中携带多 播地址， 根据加入多播组的群组通告加入与所述多播地址对应的多播组。
37、 如权利要求 36所述的成员设备， 其特征在于， 所述加入多播组的群 组通告中还携带所述扇出 URI和成员资源的映射关系，所述成员设备进一步 包括：
存储模块， 用于存储所述扇出 URI和所述多播地址映射关系以及所述成 员资源和所述多播地址的映射关系。
38、 如权利要求 35-37任一所述的成员设备， 其特征在于， 进一步包括： 确定模块， 用于确定成员资源访问请求的目的地址为多播地址。
39、 如权利要求 38所述的成员设备， 其特征在于， 所述操作模块根据所 述扇出 URI确定成员资源在成员设备上的访问路径具体为：确定包含与成员 资源访问请求中的目的地址相同的多播地址的多播组信息， 确定与成员资 源访问请求中的目的地址相同的多播地址的多播组信息中包含与所述成员 资源访问请求中的目的 URI相同的扇出 URI, 确定多播组信息中与扇出 URI 对应的成员资源在成员设备上的访问路径。
40、 如权利要求 35-39任一所述的成员设备， 其特征在于， 所述操作模块 根据所述成员资源在成员设备上的访问路径执行访问请求的操作具体为： 将所述成员资源访问请求中的目的 URI包含的扇出 URI用确定的成员资源 在成员设备上的访问路径替换， 并针对与确定的成员资源在成员设备上的 访问路径对应的成员资源执行访问请求的操作。
41、 如权利要求 35-40任一所述的成员设备， 其特征在于， 所述接收模块 进一步用于： 接收离开多播组的群组通告， 所述离开多播组的群组通告中 携带多播地址；
所述存储模块进一步用于， 删除存储的与离开多播组的群组通告中的多 播地址相同的多播地址对应的多播组信息， 并退出所述离开多播组的群组 通告中的多播地址对应的多播组。
42、 如权利要求 35-40任一所述的成员设备， 其特征在于， 所述接收模块 进一步用于： 接收离开多播组的群组通告， 所述离开多播组的群组通告中 携带多播地址和需离开的成员资源， 所述需离开的成员资源包含需离开群 组资源的成员资源所属的成员设备以及成员资源在成员设备上的访问路 径；
所述存储模块进一步用于删除存储的与所述离开多播组的群组通告中 的多播地址相同的多播地址的多播组信息中需离开群组资源的成员资源； 以及删除存储的与所述离开多播组的群组通告中的多播地址相同的多播地 址的多播组信息， 并退出所述离开多播组的群组通告中的多播地址对应的 多播组。
43、 如权利要求 42所述的成员设备， 其特征在于，
所述存储模块进一步用于确定存储的与所述离开多播组的群组通告中 的多播地址相同的多播地址的多播组信息中的扇出 URI不对应成员资源。
PCT/CN2012/078531 2012-01-06 2012-07-12 成员资源的访问方法、群组服务器和成员设备 Ceased WO2013102346A1 (zh)

Priority Applications (8)

Application Number Priority Date Filing Date Title
RU2014131902/08A RU2598582C2 (ru) 2012-01-06 2012-07-12 Способ, групповой сервер и устройство-элемент для обеспечения доступа к ресурсам-элементам
JP2014550612A JP5891551B2 (ja) 2012-01-06 2012-07-12 メンバーリソースにアクセスするための方法、グループサーバ、およびメンバーデバイス
CA2859059A CA2859059C (en) 2012-01-06 2012-07-12 Method, group server, and member device for accessing member resources
EP12864225.3A EP2782367B1 (en) 2012-01-06 2012-07-12 Method for accessing member resources, group server and member device
EP17201988.7A EP3367709A1 (en) 2012-01-06 2012-07-12 Method, group server, and member device for accessing member resources
KR1020147017218A KR101571376B1 (ko) 2012-01-06 2012-07-12 구성원 자원에 액세스하는 방법, 그룹 서버 및 구성원 장치
IN4375CHN2014 IN2014CN04375A (zh) 2012-01-06 2012-07-12
US14/305,745 US9450772B2 (en) 2012-01-06 2014-06-16 Method, group server, and member device for accessing member resources

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201210004135.6 2012-01-06
CN201210004135.6A CN103200209B (zh) 2012-01-06 2012-01-06 成员资源的访问方法、群组服务器和成员设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/305,745 Continuation US9450772B2 (en) 2012-01-06 2014-06-16 Method, group server, and member device for accessing member resources

Publications (1)

Publication Number Publication Date
WO2013102346A1 true WO2013102346A1 (zh) 2013-07-11

Family

ID=48722566

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/078531 Ceased WO2013102346A1 (zh) 2012-01-06 2012-07-12 成员资源的访问方法、群组服务器和成员设备

Country Status (10)

Country Link
US (1) US9450772B2 (zh)
EP (3) EP2782367B1 (zh)
JP (1) JP5891551B2 (zh)
KR (1) KR101571376B1 (zh)
CN (1) CN103200209B (zh)
CA (1) CA2859059C (zh)
ES (1) ES2657805T3 (zh)
IN (1) IN2014CN04375A (zh)
RU (1) RU2598582C2 (zh)
WO (1) WO2013102346A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5844440B1 (ja) * 2014-08-08 2016-01-20 ソフトバンク株式会社 通信端末装置及び通信システム

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI125254B (en) * 2012-07-17 2015-08-14 Arm Finland Oy Method and device in a network service system
CN108990063A (zh) * 2013-06-28 2018-12-11 日本电气株式会社 通信系统、网络和用户设备及其通信方法
CN105659565B (zh) * 2013-09-20 2020-01-10 康维达无线有限责任公司 基于兴趣的增强型m2m内容管理
KR102035359B1 (ko) * 2013-10-14 2019-10-24 전자부품연구원 리소스 접근 방법 및 이를 적용한 시스템
CN103605480B (zh) * 2013-10-29 2016-08-17 新浪网技术(中国)有限公司 Web服务器及其磁盘资源访问控制方法
CN105745867B (zh) * 2013-12-01 2019-05-31 Lg电子株式会社 用于在无线通信系统中管理特定资源的方法和设备
CN104936199A (zh) * 2014-03-20 2015-09-23 中兴通讯股份有限公司 一种资源通告管理的方法及公共业务实体
US9887939B2 (en) 2015-03-11 2018-02-06 International Business Machines Corporation Transmitting multi-destination packets in overlay networks
WO2016008102A1 (zh) * 2014-07-15 2016-01-21 华为技术有限公司 对群组资源中成员资源的操作请求的处理方法及装置
KR101964532B1 (ko) * 2014-07-18 2019-04-01 콘비다 와이어리스, 엘엘씨 복수의 디바이스들 상에서 복수의 명령들의 실행을 허용하는 것에 의해 강화되는, m2m 시스템에서의 서비스 레이어와 관리 레이어 사이의 동작들
WO2016047864A1 (ko) * 2014-09-23 2016-03-31 엘지전자 주식회사 무선 통신 시스템에서 그룹 리소스를 재배치하기 위한 방법 및 장치
EP3001704A1 (en) * 2014-09-29 2016-03-30 Alcatel Lucent Method, network node, distributed system and communication network for providing data from machine devices to a first network node
CN105577564B (zh) * 2014-10-15 2019-02-01 青岛海尔智能家电科技有限公司 一种信令高效传输的方法和装置
WO2016064235A2 (ko) * 2014-10-24 2016-04-28 엘지전자 주식회사 무선 통신 시스템에서 그룹 멤버의 자식 자원을 관리하기 위한 방법 및 이를 위한 장치
US10990449B2 (en) 2014-10-31 2021-04-27 Convida Wireless, Llc Managing application relationships in machine-to-machine systems
WO2016072889A1 (en) * 2014-11-04 2016-05-12 Telefonaktiebolaget L M Ericsson (Publ) Analysis of connection patterns in a communication network
US11088893B2 (en) 2014-11-12 2021-08-10 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for negotiating session descriptor parameters
CN105874764B (zh) * 2014-12-10 2019-03-19 华为技术有限公司 计算机及设备访问方法
US10193788B2 (en) * 2014-12-19 2019-01-29 Disrupter LLC Systems and methods implementing an autonomous network architecture and protocol
CN104717132B (zh) * 2015-02-13 2017-10-13 腾讯科技（深圳）有限公司 消息发送方法、装置和系统
CN106034281B (zh) 2015-03-17 2018-08-14 中兴通讯股份有限公司 一种基于m2m网关的末梢网络建立方法、装置和系统
CN104955153B (zh) * 2015-05-29 2022-03-11 青岛海尔智能家电科技有限公司 一种发现资源的方法、装置及设备
US20160381136A1 (en) * 2015-06-24 2016-12-29 Futurewei Technologies, Inc. System, method, and computer program for providing rest services to fine-grained resources based on a resource-oriented network
EP3320668B1 (en) 2015-07-10 2020-07-01 Telefonaktiebolaget LM Ericsson (PUBL) Discovery of resources in a local network
JP6561656B2 (ja) * 2015-07-29 2019-08-21 株式会社リコー 端末およびマルチキャスト・アドレス配布サーバ
JP6661931B2 (ja) * 2015-09-17 2020-03-11 沖電気工業株式会社 情報配信装置、情報配信プログラム及び情報配信システム
JP6637166B2 (ja) 2015-09-23 2020-01-29 コンヴィーダ ワイヤレス， エルエルシー 強化ＲＥＳＴｆｕｌ動作
CN111193805B (zh) * 2015-11-19 2021-12-31 华为技术有限公司 一种资源发现的方法及装置
CN111885508B (zh) * 2015-12-15 2022-04-12 华为云计算技术有限公司 一种群组多播和群组创建的方法以及移动网络平台
WO2017106450A1 (en) * 2015-12-15 2017-06-22 Convida Wireless, Llc Methods and nodes for enabling context-awareness in coap
CN106937240B (zh) * 2015-12-31 2020-10-09 华为技术有限公司 一种获取资源的方法和装置
WO2018004677A1 (en) * 2016-07-01 2018-01-04 Intel IP Corporation Communications in internet-of-things devices
EP3282618A1 (en) * 2016-08-09 2018-02-14 Panasonic Intellectual Property Corporation of America Improved initial and retransmissions of data for v2x transmissions
CN109997114B (zh) * 2016-10-07 2023-09-29 康维达无线有限责任公司 用于通用互通和可扩展性的服务层资源管理
WO2018071773A2 (en) * 2016-10-13 2018-04-19 Convida Wireless, Llc Enabling multicast for service layer group operation
CN108075908B (zh) * 2016-11-11 2023-01-17 京东方科技集团股份有限公司 处理操作请求的方法及装置
CN106873553B (zh) * 2017-02-09 2020-01-21 北京东土科技股份有限公司 基于工业互联网操作系统的现场设备控制管理方法及装置
CN108206992B (zh) * 2017-12-05 2022-07-15 中兴通讯股份有限公司 一种多播组信息的传递方法、装置和系统
CN109874113B (zh) * 2017-12-05 2022-03-18 中兴通讯股份有限公司 一种多播组信息的处理方法、装置和系统
CN109905431B (zh) 2017-12-08 2021-01-26 京东方科技集团股份有限公司 消息处理方法及系统、存储介质、电子设备
CN112189360B (zh) * 2018-03-20 2024-03-22 瑞典爱立信有限公司 用于操作和管理网络内的受限设备的方法和装置
CN108762950A (zh) * 2018-05-23 2018-11-06 山东浪潮商用系统有限公司 一种规范化RESTful微服务交互方法
US11424961B2 (en) * 2018-09-14 2022-08-23 Hewlett Packard Enterprise Development Lp Exporting the device sharing attribute for host devices from a wireless controller to a switch
CN110472378B (zh) * 2019-04-22 2020-04-17 山东汇佳软件科技股份有限公司 共享大数据现场保护平台
US11032093B2 (en) * 2019-07-17 2021-06-08 Juniper Networks, Inc. Multicast group membership management
KR102137914B1 (ko) * 2019-11-20 2020-07-24 전자부품연구원 IoT/M2M 플랫폼에서 그룹 통지 취합 방법
WO2021209125A1 (en) * 2020-04-15 2021-10-21 Telefonaktiebolaget Lm Ericsson (Publ) Orchestrating execution of a complex computational operation
KR102939160B1 (ko) * 2020-04-16 2026-03-12 세종대학교산학협력단 사물인터넷 플랫폼 간 연동 방법 및 장치
CN111988298B (zh) * 2020-08-13 2023-05-30 山东伏羲智库互联网研究院 数据处理方法、装置及设备
CN115226218B (zh) * 2021-04-21 2025-12-19 维沃移动通信有限公司 资源释放方法、装置、网络节点及存储介质
CN113923181B (zh) * 2021-09-30 2023-08-22 北京字跳网络技术有限公司 一种群消息处理方法、装置、系统及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101827309A (zh) * 2009-03-06 2010-09-08 华为技术有限公司 一种推送消息的发送方法、终端、服务器及系统
CN102111741A (zh) * 2009-12-23 2011-06-29 中兴通讯股份有限公司 计费实现方法及装置
CN102130773A (zh) * 2011-02-25 2011-07-20 华为技术有限公司 群组通信的方法和用于群组通信的装置
US20110201365A1 (en) * 2010-02-15 2011-08-18 Telefonaktiebolaget L M Ericsson (Publ) M2m group based addressing using cell broadcast service

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2118051C1 (ru) * 1996-04-30 1998-08-20 Лихачев Александр Геннадьевич Способ доступа к ресурсам "всемирной паутины" через шлюзы-представители
US6654796B1 (en) * 1999-10-07 2003-11-25 Cisco Technology, Inc. System for managing cluster of network switches using IP address for commander switch and redirecting a managing request via forwarding an HTTP connection to an expansion switch
US6917626B1 (en) * 1999-11-30 2005-07-12 Cisco Technology, Inc. Apparatus and method for automatic cluster network device address assignment
TW472208B (en) * 2000-07-03 2002-01-11 Nat Science Council An indexing method for mapping multiple segments of coded fields into a table-structure field
KR100445226B1 (ko) 2002-07-24 2004-08-21 한국전력공사 분류형 데이터 구조를 이용한 원격 검침 시스템
KR100864296B1 (ko) * 2004-08-16 2008-10-23 콸콤 인코포레이티드 그룹 통신을 위한 그룹 멤버십을 관리하기 위한 방법 및장치
FI20041169A0 (fi) * 2004-09-08 2004-09-08 Nokia Corp Ryhmäpalveluiden ryhmätiedot
US8014321B2 (en) * 2004-10-22 2011-09-06 Microsoft Corporation Rendezvousing resource requests with corresponding resources
WO2006086939A1 (de) * 2005-02-17 2006-08-24 Infineon Technologies Ag Verwaltung dynamischer gruppen in einem push-to-talk over cellular kommunikationssystems
US8230435B2 (en) * 2008-02-12 2012-07-24 International Business Machines Corporation Authenticating a processing system accessing a resource
CN101959133A (zh) * 2009-07-15 2011-01-26 华为技术有限公司 M2m用户设备的操作控制方法、系统和m2m用户设备
US20120066396A1 (en) * 2010-09-10 2012-03-15 Samsung Electronics Co. Ltd. Apparatus and method for supporting periodic multicast transmission in machine to machine communication system
CN102136933B (zh) * 2010-09-30 2013-08-28 华为技术有限公司 设备管理方法、中间件及机器通信平台、设备和系统
KR101682956B1 (ko) * 2010-10-14 2016-12-07 삼성전자주식회사 기기 간 통신 시스템에서 페이징된 기기에서의 억세스 오버헤드를 감소하기 위한 방법 및 장치
US9426222B2 (en) * 2011-02-11 2016-08-23 Interdigital Patent Holdings, Inc. Systems, methods and apparatus for managing machine-to-machine (M2M) entities
WO2013066384A1 (en) * 2011-11-04 2013-05-10 Intel Corporation Techniques for traffic delivery to a group of devices
FI20116299L (fi) * 2011-12-21 2013-06-22 Sensinode Oy Menetelmä, laite ja järjestelmä resurssien osoittamiseksi
WO2014193940A1 (en) * 2013-05-28 2014-12-04 Convida Wireless, Llc Load balancing in the internet of things

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101827309A (zh) * 2009-03-06 2010-09-08 华为技术有限公司 一种推送消息的发送方法、终端、服务器及系统
CN102111741A (zh) * 2009-12-23 2011-06-29 中兴通讯股份有限公司 计费实现方法及装置
US20110201365A1 (en) * 2010-02-15 2011-08-18 Telefonaktiebolaget L M Ericsson (Publ) M2m group based addressing using cell broadcast service
CN102130773A (zh) * 2011-02-25 2011-07-20 华为技术有限公司 群组通信的方法和用于群组通信的装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2782367A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5844440B1 (ja) * 2014-08-08 2016-01-20 ソフトバンク株式会社 通信端末装置及び通信システム

Also Published As

Publication number Publication date
JP5891551B2 (ja) 2016-03-23
ES2657805T3 (es) 2018-03-06
EP2782367B1 (en) 2016-06-15
CA2859059C (en) 2016-09-06
RU2598582C2 (ru) 2016-09-27
EP3094117B1 (en) 2017-12-13
KR101571376B1 (ko) 2015-11-24
US9450772B2 (en) 2016-09-20
EP3094117A1 (en) 2016-11-16
EP2782367A4 (en) 2015-03-25
JP2015511417A (ja) 2015-04-16
CN103200209B (zh) 2018-05-25
EP2782367A1 (en) 2014-09-24
KR20140095571A (ko) 2014-08-01
US20140369251A1 (en) 2014-12-18
CN103200209A (zh) 2013-07-10
CA2859059A1 (en) 2013-07-11
EP3367709A1 (en) 2018-08-29
IN2014CN04375A (zh) 2015-09-04
RU2014131902A (ru) 2016-02-20

Similar Documents

Publication Publication Date Title
CN103200209B (zh) 成员资源的访问方法、群组服务器和成员设备
US10044815B2 (en) Location-based domain name system service discovery
CN106797409B (zh) 用于在物联网(iot)中的设备位置注册的服务器
US10798779B2 (en) Enhanced CoAP group communications with selective responses
WO2012113218A1 (zh) 群组通信的方法和用于群组通信的装置
CN107948073B (zh) 基于ndn架构的无线数据传输方法、装置及系统
CN114827908A (zh) Vn组通信方法、装置、设备及存储介质
WO2011072610A1 (zh) 一种内容发布与获取的方法、装置和系统
Helgason et al. A middleware for opportunistic content distribution
Gulati et al. Software-defined content dissemination scheme for Internet of healthcare vehicles in COVID-like scenarios
US9451021B2 (en) System and method for providing content-centric services using ultra-peer
WO2012029248A1 (ja) データ転送システム
CN107801207B (zh) 无线多媒体传感网络中的数据传输方法及系统
CN112994996B (zh) 家庭网络共享方法、mec服务器、计算机设备及介质
Katsaros et al. On information exposure through named content
Qin et al. Lehigh explorer: A real time video streaming application with mobility support for content centric networks
Alassery Fast Packets Delivery Techniques for Urgent Packets in Emergency Applications of Internet of Things
CN102957668A (zh) 标识网中获取位置信息的方法和接入服务路由器
Nazeeruddin et al. An efficient and robust service discovery protocol for dynamic MANETs
Guardado et al. Ndnwifi: Named data networking enabled wifi in challenged communication environments
Islam Information Centric Networking for the Challenged Internet
He et al. Multicast Gateway for Service Location in Heterogeneous Ad Hoc Communication
Bosunia et al. Efficient Data Delivery based on Content-Centric Networking for IoT Applications
Lo et al. Design of a context-aware mobile guiding application
Mukherjee et al. Enabling Advanced Network Services in the Future Internet Using Named Object Identifiers and Global Name Resolution

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12864225

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2859059

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2012864225

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20147017218

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2014550612

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2014131902

Country of ref document: RU

Kind code of ref document: A