Patent Description:
European Telecommunications Standards Institute (ETSI) machine-to-machine (M2M) standard contains an overall end-to-end M2M functional architecture. The ETSI M2M standard describes a resources-based architecture that can be used for the exchange of data and events between machines.

<FIG> shows a conventional ETSI M2M architecture. The M2M architecture includes M2M devices including D devices <NUM> and/or D' devices <NUM>, an M2M gateway(s) <NUM>, and a network domain <NUM>. An M2M device <NUM>/<NUM> is a device that runs M2M application(s) using M2M service capabilities. The M2M devices <NUM>/<NUM> may connect to the network domain <NUM> either directly or via the M2M gateway <NUM>. A D device <NUM> may provide M2M service capability (i.e., device service capability layer (DSCL)) that communicates to a network service capability layer (NSCL) using an mId reference point and to a device application (DA) using a dIa reference point. A D' device <NUM> may host a DA that communicates to a gateway service capability layer (GSCL) using a dIa reference point. A D' device <NUM> does not implement ETSI M2M service capabilities. There may be a non-ETSI M2M compliant device ('d' device) that connects to the service capability layer (SCL). The d devices do not use ETSI M2M defined reference points.

An M2M gateway <NUM> runs M2M application(s) using M2M service capabilities. The M2M gateway <NUM> may act as a proxy between M2M devices <NUM>/<NUM> and the network domain <NUM>. The M2M gateway <NUM> may provide a service to other devices (e.g., d devices) connected to it that are hidden from the network domain. The M2M gateway <NUM> may provide M2M service capabilities (i.e., GSCL) that communicates to the NSCL using the mId reference point and to a gateway application (GA) using the dIa reference point.

The network domain <NUM> comprises an access network and a core network. The access network is a network which allows the M2M device and the gateway to communicate with the core network. The access network includes, but is not limited to, x-Digital Subscriber Line (xDSL), GPRS EDGE Radio Access Network (GERAN), UMTS Terrestrial Ratio Access Network (UTRAN), Evolved UTRAN (E-UTRAN), wireless local area network (WLAN), WiMAX, etc. The core network provides Internet protocol (IP) connectivity, service and network control functions, interconnection with other networks, roaming, etc. The core network includes, but is not limited to, Third Generation Partnership Project (3GPP) core network, ETSI Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) core network, 3GPP2 core network, etc..

The ETSI M2M defines <NUM> reference points (mIa, dIa, and mId) as shown in <FIG>. The mIa reference point offers generic and extendable mechanism for network applications interactions with the NSCL. The dIa reference point offers generic and extendable mechanism for DA/GA interactions with the DSCL or GSCL. The mId reference point offers generic and extendable mechanism for SCL interactions.

A method and apparatus for distributed services and data in an M2M communication network are disclosed. A network server, an M2M gateway, and M2M devices that comprise an M2M network architecture. The network server, the M2M gateway, and the M2M device may comprise a processor that is configured to implement an M2M service capability layer for supporting M2M service capabilities. Reference points may be defined in the M2M network architecture for interactions between network service capability layers, between gateway service capability layers, between a gateway service capability layer and a device service capability layer of an M2M device, between M2M device applications, and/or between a network/gateway/device service capability layer and an M2M application.

The network server may be split into a control server and a data server at the service capability layer to provide service capabilities for control functions and service capabilities for data functions, respectively. Reference points for control functions and data functions may be separately provided between network service capability layers; between gateway service capability layers; between a gateway service capability layer and a device service capability layer; between M2M device applications; and/or between a network/gateway/device service capability layers and an M2M application at the service capability layer level. The data server may be configured to interact with another data server to push or pull data or resources either directly or indirectly via the control server.

The control server and the data server may have a resource for storing a list of registered data servers or control servers. The network server and/or the gateway may have a capabilities resource for storing information for sharing of capabilities with another network server or another gateway. Each instance of the capabilities resource may include sub-resources for storing information regarding supported capabilities, capabilities shared with other service capability layers, and capabilities shared from other service capability layers.

It is an object of the present invention to eliminate or at least alleviate the described problems. This object is achieved by a first service entity and corresponding method in accordance with the appended claims <NUM> and <NUM>.

As shown in <FIG>, the communications system <NUM> may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) <NUM>, a core network <NUM>, a public switched telephone network (PSTN) <NUM>, the Internet <NUM>, and other networks <NUM>, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

The communications systems <NUM> may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network <NUM>, the Internet <NUM>, and/or the networks <NUM>. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like.

The base station 114a may be part of the RAN <NUM>, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

For example, the core network <NUM> may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication.

<FIG> is a system diagram of an example WTRU <NUM>. As shown in <FIG>, the WTRU <NUM> may include a processor <NUM>, a transceiver <NUM>, a transmit/receive element <NUM>, a speaker/microphone <NUM>, a keypad <NUM>, a display/touchpad <NUM>, non-removable memory <NUM>, removable memory <NUM>, a power source <NUM>, a global positioning system (GPS) chipset <NUM>, and other peripherals <NUM>.

The RAN <NUM> may include eNode-Bs 140a, 140b, 140c, though it will be appreciated that the RAN <NUM> may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 140a, 140b, 140c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface <NUM>. In one embodiment, the eNode-Bs 140a, 140b, 140c may implement MIMO technology. Thus, the eNode-B 140a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

Each of the eNode-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in <FIG>, the eNode-Bs 140a, 140b, 140c may communicate with one another over an X2 interface.

The MME <NUM> may be connected to each of the eNode-Bs 142a, 142b, 142c in the RAN <NUM> via an S1 interface and may serve as a control node. The MME <NUM> may also provide a control plane function for switching between the RAN <NUM> and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

The serving gateway <NUM> may be connected to each of the eNode Bs 140a, 140b, 140c in the RAN <NUM> via the S1 interface. The serving gateway <NUM> may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway <NUM> may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

Hereafter, the terms "SCL" and "service capabilities" will be used interchangeable, unless it explicitly states that service capabilities mean a specific service capability. The terms "M2M server" and "server", "M2M control server" and "control server", "M2M data server" and "data server", "M2M gateway" and "gateway", and "M2M device" and "device" will be used interchangeably, respectively.

M2M service capabilities provide M2M functions that are to be shared by different applications. The M2M service capabilities expose functions through a set of open interfaces, use core network functionalities, and simplify and optimize application development and deployment through hiding of network specificities. The M2M service capabilities in the network domain, the gateway, and the device include application enablement, generic communication, reachability, addressing and repository, communication selection, remote entity management, security, history and data retention, transaction management, compensation broker, telco operator exposure, interworking proxy, etc. M2M applications are applications that run a service logic and use M2M service capabilities accessible via an open interface.

In the case where M2M devices reside behind an M2M gateway, the service capabilities may be distributed over the M2M system in a form of hierarchy. This hierarchical architecture may be generalized further if one considers that M2M gateways may exist behind other M2M gateways, and that network service capabilities may be replicated and shared between many M2M service providers. Sharing service capabilities may provide benefits such as reducing device overhead (e.g., an M2M device with limited hardware capacity would not need to support complex service capability functionalities and may make use of other service capabilities in the network).

The ETSI M2M standard uses RESTful architecture such that information is represented by resources which are structured as a tree. Representational state transfer (REST) is a style of software architecture for distributed systems such as World Wide Web. A RESTful architecture is about the transfer of representations of uniquely addressable resources. A resource is a uniquely addressable entity in the RESTful architecture. When handling resources in a RESTful architecture, there are four basic methods (called "verbs"). A CREATE method creates child resources. A RETRIEVE method reads the content of the resource. An UPDATE method writes the content of the resource. A DELETE method deletes the resource.

A resource has a representation that may be transferred and manipulated with the verbs. A resource may be addressed using a Universal Resource Identifier (URI). A sub-resource is a resource that has a containment relationship with the addressed (parent) resource. A sub-resource may be called a child resource. The parent resource representation contains references to the child resource. A hosting SCL is the SCL where the addressed resource resides. An issuer is the actor performing a request. An issuer may be either an application or an SCL.

The notation <resourceName> in the following description and the drawings means a placeholder for an identifier of a resource of a certain type, and the actual name of the resource is not predetermined. The notation "attribute" denotes a placeholder for one or more fixed names. Without the delimiters < and > or "and", names appearing in boxes in drawings may be literals for fixed resource names or attributes.

<FIG> shows an example sclBase resource structure. An sclBase resource <NUM> is the root of all other resources and contains all other resources of the hosting SCL. The sclBase resource <NUM> may be represented by an absolute URI. All other resources hosted in the SCL may be identified by a URI.

Attribute <NUM> is meta-data that provides properties associated with a resource representation.

An SCL resource <NUM> may represent an associated (remote) SCL that is authorized to interact with the hosting SCL. In order to be authorized to interact with the hosting SCL, the remote SCL may go through an M2M service registration procedure. An SCL resource <NUM> may be created as a result of a successful registration of the remote SCL with its local SCL, or vice-versa.

An application resource <NUM> may store information about the application. The application resource <NUM> may be created as a result of successful registration of an application with the local SCL.

A container resource <NUM> is a generic resource that may be used to exchange data between applications and/or SCLs by using the container as a mediator that takes care of buffering the data.

A group resource <NUM> may be used to define and access groups of other resources. For example, a group resource may be used to write the same content to a group of M2M container resources.

An accessRight resource <NUM> may store a representation of permissions. An accessRight resource <NUM> is associated with resources that may be accessible to entities external to the hosting SCL.

A subscription resource <NUM> may be used to keep track of status of active subscription to its parent resource. A subscription represents a request from the issuer to be notified about modifications on the parent resource.

A discovery resource <NUM> may be used to allow discovery. It may be used to retrieve the list of URI of resources matching discovery filter criteria.

In the conventional ETSI M2M functional architecture, control and data paths are not separated and supposed to use the same transmission mechanism. Such approach may make control and data paths impact each other. For example, if there is a big volume of data stream between two M2M devices that is routed via an M2M server, it may delay other M2M devices to register with the M2M server. On the other hand, if there are many new M2M devices (normal or malicious) to register with the M2M server, the existing data transmission on the data path may be impacted and even stopped in the worst case.

The conventional ETSI M2M SCL registration is network-centric (i.e., NSCL-centric) and is limited to a DSCL registration to an NSCL and a GSCL registration to an NSCL. The impact of such limit is that the NSCL serves as an anchor point and there is no direct communication between some SCLs, such as DSCL to DSCL, DSCL to GSCL, GSCL to GSCL, or NSCL to NSCL.

The M2M servers (e.g., NSCLs in the ETSI M2M framework) may be owned by different businesses and a service provider. They may offer different service capability functionalities, and offer a complete service jointly. Therefore, NSCL-to-NSCL interaction is needed.

The M2M gateways belonging to the same service providers may need to have interactions to exchange control and user data. Such information does not need to go through their common NSCL for efficiency. In mobility scenarios, for example, when a device moves from one gateway to another, a direct communication between the gateways is needed.

In the case where multiple verticals are involved, a full scale of and diverse SCL interactions is needed. For example, a monitor in an eHealth system detected an emergency issue. The home gateway sends a message to the eHealth system to report the emergency. The eHealth system contacts emergency medical services (EMS) for an ambulance, and the ambulance system contacts the city traffic control system for route information. Here, there are three different kinds of SCLs: one for eHealth, one for EMS, and one for city traffic control system. Interactions among them are needed to perform necessary coordination to support the use case.

In one embodiment, new reference points and/or new operations on the reference points are defined to support SCL interactions based on the ETSI M2M architecture. Conventional reference points and application programming interface (API) operations may be supported and re-used.

<FIG> shows an example M2M architecture with new reference points in accordance with one embodiment. The M2M architecture includes M2M devices <NUM>/<NUM>, M2M gateways <NUM>, and M2M servers <NUM>. The M2M devices may be a WTRU. New reference points mIm, dId, dIa, and aIa are defined.

mIm is a reference point between two M2M servers <NUM> (i.e., NSCLs). Within the M2M architecture, the mIm reference point resides between two NSCLs to provide new service capability sharing and configuration functions. Within the scalable M2M architecture (SMA), which will be explained below, the mIm reference point may reside between two M2M control servers, between an M2M control server and an M2M data server, or between two M2M data servers to provide new functions, such as resource copy/move and charging.

dId is a reference point between a GSCL and a GSCL, or between a DSCL and a GSCL, or between a DSCL and a DSCL that is defined to support new functions such as capability sharing and resource copy/move.

dIa is a reference point between a DSCL and D' devices <NUM> that is defined to enable direct communications between a DSCL and D' devices <NUM> by leveraging dIa reference points with enhanced application registration.

aIa is a reference point between D' devices <NUM>. For example, D' devices may register with an M2M gateway <NUM> but the data may be exchanged between the D' devices <NUM> directly. Alternatively, one D' device may register with the M2M gateway <NUM> and other D' devices may register with the M2M gateway <NUM> through the D' device registered with the M2M gateway <NUM>. The D/D' devices may exchange data directly with other D/D' devices.

In another embodiment, instead of introducing new reference points, the conventional mId reference point may be re-used with extensions. <FIG> shows an example M2M architecture wherein mId reference points with extensions are used. For example, the mId reference point with extensions may be used for interactions between M2M servers <NUM>.

In another embodiment, a scalable M2M architecture (SMA) may be implemented. In the SMA, the M2M server is split to an M2M data server and an M2M control server. One M2M control server may control one or multiple M2M data servers. The control path and the data path may be separated. The SMA may eliminate drawbacks in the conventional M2M functional architecture and may achieve better system reliability, scalability, and manageability.

In SMA, functions and procedures in the ETSI M2M architecture may be categorized into control functions and data functions. The control functions include, but are not limited to, M2M bootstrap, M2M SCL registration, M2M application registration, M2M resource discovery, and M2M remote entity management (REM), or the like. The data functions include other regular resource access such as operations on containers and groups resources.

<FIG> shows an example scalable M2M architecture (SMA). The M2M network includes M2M devices (D devices <NUM> and/or D' devices <NUM>), an M2M gateway(s) <NUM>, an M2M control server(s) <NUM>, and an M2M data server(s) <NUM>. An M2M server is split into the M2M control server <NUM> and the M2M data server <NUM>. Both the M2M control server <NUM> and the M2M data server <NUM> are logical entities. The M2M control server <NUM> has service capabilities for performing control functions including, but not limited to, bootstrapping, registration, resource discovery and management, and the like. The M2M data server <NUM> has service capabilities for M2M data functions and handles data path transmissions such as M2M data access and storage, etc. There are interactions between the M2M control server <NUM> and the M2M data server <NUM> via a reference point (e.g., mIm reference point). The M2M control server <NUM> may configure, monitor, and change the behaviors of the M2M data server <NUM>.

In <FIG>, the suffix "_d" stand for data path, and the suffix "_c" stands for control path. Control reference points and data reference points may use different transport protocol. For example, Transmission Control Protocol (TCP) and Stream Control Transmission Protocol (SCTP) may be used for control reference points to provide reliable transmission, while User Datagram Protocol (UDP) may be used for data reference points to provide lower overhead and latency.

mIm is a reference point between two M2M servers. The mIm reference point may be used for registration, authorization, subscription/notification between M2M servers, M2M point of contact (PoC) operations, management functions, capability/functionality sharing, SCL and application registration, copy or move resources, billing (e.g., requested services, traffic statistics, etc.), or the like.

dId_d is a reference point between two D devices or two M2M gateways for non-control operations. The dId_d reference point may be used for DSCL/GSCL retrieve and update on DSCL/GSCL container, content instances collection management, group management, group collection management, capability/functionality sharing, and the like.

dId_c is a reference point between two D devices or two M2M gateways for control operations. The dId_c reference point may be used for DSCL/GSCL gateway or device bootstrapping, SCL management, access right management, resource discovery, notification channels collection management, notification channel management, M2M PoCs and M2M PoCs collection management, capability/functionality sharing, or the like.

aIa_d is a reference point between two D' devices for data operations. The aIa_d reference point may be used for billing (e.g., traffic statistics), multi-hop data relaying, or the like.

aIa_c is a reference point between two D' devices for control operations. The aIa_c reference point may be used for DA bootstrapping operations, remote triggering, registration, resource discovery on DA, capability/functionality sharing, or the like.

mIa_d is a reference point between an NA and an M2M data server. The mIa_d reference point may be used for NA announce/de-announce, retrieve and update application, containers, content instances management and groups collection management, billing (e.g., traffic statistics), or the like.

mIa_c is a reference point between an NA and an M2M control server. The mIa_c reference point may be used for NA registration, authorisation, announce/de-announce, subscription and subscription collection management, access right management, resource discovery and remote entity management, capability/functionality sharing, application registration, or the like.

mId_d is a reference point between a DSCL/GSCL and an M2M data server. The mId_d reference point may be used for DSCL/GSCL, containers and content instances management, group and groups collection management, copy or move resources, billing (e.g., traffic statistics), or the like.

mId_c is a reference point between a DSCL/GSCL and an M2M control server and between a DSCL and a GSCL. The mId_c reference point may be used for DSCL/GSCL gateway or device bootstrapping, SCL management, access right management, resource discovery, notification channels collection management and notification channel management, M2M PoCs and M2M PoCs collection management, SCL registration, billing (e.g., requested services), capability or functionality sharing, or the like.

dIa_d is a reference point between a DA/GA and a DSCL/GSCL for non-control operations. The dIa_d reference point may be used for DA/GA announce/de-announce, containers and content instances management, group and groups collection management on DSCL/GSCL, billing (e.g., traffic statistics), or the like.

dIa_c is a reference point between a DA/GA and a DSCL/GSCL for control operations. The dIa_c reference point may be used for DA/GA bootstrapping operations, remote triggering, registration, resource discovery and remote entity management M2M PoCs and M2M PoCs collection management on DSCL/GSCL, capability/functionality sharing, application registration, or the like.

<FIG> shows an example structure that one M2M control server <NUM> controls multiple M2M data servers <NUM>. As shown in <FIG>, one M2M control server <NUM> may control multiple M2M data servers <NUM>. An M2M control server may direct M2M devices or gateways from one M2M data server to another M2M data server for purposes such as load balancing or group operations. There may be security exchanges between the M2M control server <NUM> and the M2M data server <NUM>, so that interactions between the M2M control server <NUM> and the M2M data server <NUM> may be secured and communications between the M2M data server <NUM> and the M2M devices, gateways, and applications may be secured. One M2M data server <NUM> may register itself with multiple M2M control servers <NUM>.

Multiple M2M devices and/or gateways may operate in a group, for example where devices provide the same services or where devices are deployed for the same company. If the M2M devices are currently not under the same M2M data server, it may be difficult to perform a group operation efficiently. Therefore, the M2M control server may move a group of M2M devices/gateways to the same M2M data server.

If an M2M data server is at the risk of congestion, the M2M control server may move some M2M devices from the current M2M data server to other M2M data server. If one M2M data server goes down, M2M devices may move to another M2M data server. An M2M data server(s) may be used to back-up each other and have consistent images of each other, for example, using the mIm reference point.

In order to manage multiple M2M data servers, the M2M control server may maintain an M2M data server inventory to have a list of currently active M2M data servers. In one embodiment, each M2M data sever may register or attach itself to an M2M control server once it becomes online or active. In addition, the M2M control server and the M2M data server may periodically exchange messages so that the M2M control server may have real-time information about each M2M data server. In another embodiment, an M2M control server may dynamically discover M2M data servers using service discovery mechanism such as domain name system-service discovery (DNS-SD).

Splitting an M2M server into an M2M control server and an M2M data server may be extended to a GSCL and/or a DSCL. For example, a GSCL may be split to one control gateway (i.e., CGSCL) and one or more data gateway (i.e., DGSCL). The CGSCL may handle control-related GSCL functions, while the DGSCL may handle data-related GSCL functions. The CGSCL may register with the M2M control server (i.e., CNSCL), while the DGSCL may communicate with the M2M data server (i.e., DNSCL) directly. The same scheme may be applied to the DSCL.

The mIm reference point may handle interactions between M2M servers or between an M2M control server and an M2M data server. The mIm reference point may also handle interactions between two M2M data servers or between two M2M control servers.

The M2M control server may manage a set of M2M data servers. The M2M control server may enable direct communications between two M2M data servers. For example, the M2M control server may trigger to move data or resources from one M2M data server to another M2M data server. The M2M control server may pass M2M devices and gateways registration-related information to M2M data servers, so that the M2M data servers may authenticate messages and operations from the M2M devices and gateways.

For interactions between the M2M control server and the M2M data server, each M2M data server may first register with the M2M control server. <FIG> is a flow diagram of an example procedure for M2M data server registration with an M2M control server. The M2M data server <NUM> sends a registration request to the M2M control server <NUM> (<NUM>). The M2M control server <NUM> sends a registration response to the M2M data server <NUM> (<NUM>). After establishment of the registration (association), the M2M data server <NUM> and the M2M control server <NUM> may exchange periodic messages to maintain the association (<NUM>). The M2M control server <NUM> may configure, control, manage the behavior of the M2M data server <NUM> (<NUM>).

The configuration, control, and management operations may be performed through RESTful operations. Each M2M data server may provide management objects via which it may be managed by the M2M control server.

An SCL may register with multiple SCLs. For example, a device may be connected to multiple local gateways and may use different service capability functions in each of the gateways, (e.g., one for caching and one for security and addressability). A device may be roaming and its SCL may be registered to both home and visiting network cores. One to multiple SCL registration may happen at initial SCL registration (i.e., an SCL registers with multiple SCLs at the initial registration), or it may occur incrementally (i.e., an SCL initially registers with one SCL, and subsequently registers to multiple SCLs). Upon SCL registration, an SCL resource may be created on the target SCL for the requestor SCL.

An application may have one anchor SCL, or may register to multiple SCLs. An application may request different service capability functionalities from the SCLs it registers with. The different SCLs may exchange the information of the application.

Each time when an M2M device, gateway, or application registers itself with the M2M control server, the M2M control server may assign one or more M2M data server to the M2M device or gateway. <FIG> is a flow diagram of an example procedure for SCL registration. An M2M device/gateway <NUM> sends a registration request to an M2M control server <NUM> (<NUM>). The M2M control server <NUM> obtains the status of the M2M data server (<NUM>), and selects an M2M data server (<NUM>).

The M2M control server <NUM> may notify the M2M data server <NUM> or the M2M gateway <NUM> and may create corresponding resources locally (<NUM>). The M2M control server <NUM> may create or copy such resource into the M2M data server(s) <NUM> so that the M2M data server(s) <NUM> may authenticate messages and operations from the M2M device/gateway <NUM>. The M2M control server <NUM> may send a registration response to the M2M device/gateway <NUM> (<NUM>). The M2M data server <NUM> may pass traffic statistics information to the M2M control server <NUM> for example, for charging. Alternatively, the M2M control server <NUM> may query the M2M data server <NUM> for such information.

Upon instruction from the M2M control server, an M2M data server may push or pull data or resources from another M2M data server, for example, for data replication, data mobility, etc. The direct communications between the M2M data servers may be managed and controlled by the M2M control server.

<FIG> is a signaling diagram of an example procedure for data move and copy operation wherein data is indirectly accessed between M2M data servers in accordance with one embodiment. An M2M control server <NUM> sends a retrieve request to an M2M data server <NUM> (<NUM>). The request addresses a specific resource of the hosting SCL. A hosting SCL is the SCL where the addressed resource resides. The M2M data server <NUM> returns the requested information in a response to the M2M control server <NUM> if it is verified that the requested resource exists and retrieval of the resource is allowed (<NUM>). The M2M control server <NUM> then sends a create request to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> creates a resource in a resource tree and sends a response to the M2M control server <NUM> (<NUM>). The M2M control server <NUM> sends a delete request to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> deletes the resource and sends a response to the M2M control server (<NUM>).

<FIG> is a signaling diagram of an example procedure for data move and copy operation wherein data is directly accessed between M2M data servers in accordance with one embodiment. The M2M control server <NUM> and the M2M data server <NUM> perform resource discovery (<NUM>). The resource discovery procedure allows discovering of resources residing on an SCL. The hosting SCL responds to the issuer with the appropriate URIs list of discovered resources in the hosting SCL. An issuer is the actor performing a request. An issuer may be either an application or an SCL.

Once the resource is discovered (in this example data server <NUM>), the M2M data server <NUM> sends a retrieve request to the data server <NUM> (<NUM>). The M2M data server <NUM> sends a response to the M2M data server <NUM> (<NUM>). The M2M data server may send a resource operation report to the M2M control server <NUM> (<NUM>). The M2M data server <NUM> sends a delete request to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> deletes the resource and sends a response to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> may send a resource operation report to the M2M control server <NUM> (<NUM>).

<FIG> is a signaling diagram of an example procedure for data copy and move operations wherein data is accessed indirectly between M2M data servers in accordance with another embodiment. The M2M control server <NUM> sends a create/update request to the M2M data server <NUM> with copy or copytree attribute (<NUM>).

The whole resource including a sub-tree may be moved, copied, or created by one message or operation. The "copy" attribute is used to copy the single resource. The "copytree" attribute is used to copy the whole sub-tree under the requested resource including the requested resource. The "movetree" attribute is used to move the whole sub-tree under the requested resource including the requested resource. The "createtree" attribute is used to create a sub-tree under the requested resource. The above attributes may be triggered by using CREATE or UPDATE method.

The M2M data server <NUM> sends a full representation of the requested resource in a response to the M2M control server <NUM> (<NUM>). The M2M control server <NUM> sends a create/update request to the M2M data server <NUM> with createtree attribute (<NUM>). The M2M data server <NUM> creates the resource tree and copies the resource and sends a response to the M2M control server <NUM> (<NUM>). For the movetree operation, the M2M control server <NUM> sends a create/update request with movetree attribute to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> sends a full representation of the requested resource in a response to the M2M control server <NUM> and deletes the resource and deletes the resource (<NUM>). The M2M control server <NUM> sends a create/update request with createtree attribute to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> creates the resource tree and copies the resource and sends a response to the M2M control server <NUM> (<NUM>).

<FIG> is a signaling diagram of an example procedure for data move and copy operation wherein data is accessed directly between M2M data servers in accordance with another embodiment. The M2M data server <NUM> sends a create/update request with copy or copytree attribute to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> sends a full representation of the resource in a response to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> creates a resource tree, copies the resources, and may send a resource operation report to the M2M control server <NUM> (<NUM>). For movetree operation, the M2M data server <NUM> sends a create/update request with movetree attribute to the M2M data server <NUM> (<NUM>). The M2M data server <NUM> sends a full representation of the requested resource in a response to the M2M data server <NUM> and deletes the resource (<NUM>). The M2M data server <NUM> creates a resource tree, copies the resource, and may send a resource operation report to the M2M control server <NUM> (<NUM>).

There may be some implications to resource discovery by copying and moving resources from one data server to another data server. For example, the moved resource may have been announced previously. After it is moved to another data server, the previously announced resource becomes invalid and the old data server may perform de-announcement and perform announcement update to reflect the new location of the moved resource. As shown in <FIG> and <FIG>, the data server may report the results of "resource copy/move" to the control server via a resource operation report (<NUM>, <NUM>, <NUM>, <NUM>), so that the control server may update its announced resource record.

It should be noted that even though <FIG>, <FIG> describe the procedures for resource copy and move between two data servers, the same procedures may be applied to copy or move resources between two M2M gateways or two M2M devices, (e.g., in M2M mobility).

In the context of ETSI M2M, both a control server and a data server may be treated as an NSCL. In other words, both a control server and a data server may create and maintain an sclBase tree (as shown in <FIG>), but with some differences, because they handle different functions. The control server handles control-related functionalities such as SCL registration, application registration, resource discovery, management, or the like. The data server mainly deals with data functionalities such data storage and access. The data server needs to register itself with one or more control servers.

The resources <dsclBase> and <gsclBase> (i.e., the root resource of the device and gateway, respectively) need new resources and attributes to represent the list of data servers. Each DSCL/GSCL may get a list of assigned data servers which they may access, when it registers with an M2M control server. As an alternative, the control server may update or re-assign new data server to an M2M device or gateway.

In one embodiment, a new resource "dataServers" is introduced. It is a collection of data servers assigned to the device or gateway.

The resource "dataServers" may be centralized. <FIG> shows an example resource structure including a centralized resource "dataServers" <NUM>. The resource "dataServers" <NUM> may be placed as a direct sub-resource of <dsclBase> or <gsclBase> <NUM>.

Alternatively, the resource "dataServers" may be distributed. <FIG> shows an example resource structure including distributed resource "dataServers" <NUM>. The resource "dataServers" <NUM> may be placed as a direct sub-resource of <cnscl> <NUM>. <cnscl> stands for the control server which the device/gateway registers with. If a device/gateway registers with multiple control servers, there may be multiple <cnscl> and accordingly multiple "dataServers. " The structure of resource "dataServers" is shown in <FIG>.

Referring to <FIG> and <FIG>, each <scl> <NUM>, <NUM> in <d/gsclBase> tree may have new attributes: dataServerIDs, controlServerIDs, and/or serverIndication.

dataServerIDs is the list of data server IDs assigned to the <scl>. Each dataServerID points to a data server contained in the resource "dataServers" <NUM>.

controlServerIDs is the list of control server IDs assigned to the <scl>. Each controlServerID points to a <cnscl> under <d/gsclBase/<scls>. A <scl> representing a control server may not have this attribute.

serverIndication is a flag to show if <scl> is <cnscl> or <d/gscl>. If it is a <d/gscl>, this attribute may also indicate if this <d/gscl> has server capability to support hierarchical service structure, i.e., to show if the device/gateway represented by this <scl> has other D/GSCL behind it. The serverIndication attribute may not be used.

Each <application> <NUM> in <d/gsclBase> tree may have new attributes: dataServerIDs and controlServerIDs. dataServerIDs is the list of data server IDs assigned to this <application>. Each dataServerID points to a data server contained in the resource "dataServers" <NUM>. controlServerIDs is the list of control server IDs assigned to this <application>. Each controlServerID points to a <cnscl> under <d/gsclBase/<scls>.

<FIG> and <FIG> show an example sclBase tree structure for an M2M control server (i.e., <cnsclBase>). The control server may maintain a list of data servers which are associated or registered with the control server.

In <FIG>, the <scl> resource structure is used to represent a data server by adding a new attribute "serverIndication" to show if this <scl> is a data server or not.

In <FIG>, a separate resource "dataServers" <NUM> is introduced as a sub-resource of <cnsclBase> as a collection to maintain data servers, which are associated with the control server. The structure of resource "dataServers" is shown in <FIG>.

As shown in <FIG> and <FIG>, each <d/gscl> <NUM> under <cnsclBase> may have sub-resources "dataServers"<NUM>, "requestedServices" <NUM>, and "agreedServices" <NUM>. "requestedServices" <NUM> represents which type of service a D/GSCL or an application requests. For example, a service type may stand for a set of service capabilities, a service class with flat-based charging, a service class with usage-based charging, or the like.

Each <application> <NUM> under <cnsclBase> may have sub-resources "dataServers" <NUM>, "requestedServices" <NUM>, and "agreedServices" <NUM>. <FIG> shows the structure of "requestedServices" <NUM>/<NUM>, and <FIG> shows the structure of "agreedServices" <NUM>/<NUM>. Each <scl> under <cnsclBase> may not have data-related resources such as containers.

<FIG> and <FIG> show an sclBase tree structure for data server (i.e., <dnsclBase> <NUM>). The data server may maintain a list of control servers which it registers with. In one embodiment, as shown in <FIG>, the <scl> resource structure may be used to represent a control server by adding a new attribute "serverIndication" to show if this <scl> is a control server or not.

Alternatively, as shown in <FIG>, a separate resource "controlServers" <NUM> may be introduced as a sub-resource of <dnsclBase> <NUM> as a collection to maintain data servers, which are associated with the control server.

Each <d/gscl> <NUM> under <dnsclBase> may have two sub-resources "controlServers" <NUM> and "trafficStatistics" <NUM>. Each <application> <NUM> under <dnsclBase> may have a sub-resource "controlServers" <NUM> and "trafficStatistics" <NUM>, for example, for charging purpose. Each <scl> under <dnsclBase> may have data-related resources such as containers.

<FIG> shows an example structure of resource "dataServers". dataServers is a collection resource, which includes multiple <dataServer> instances. Each <dataServer> instance <NUM> may have the following attributes: dataServerID, controlServerID, listOfDGSCLs, listOfApps, creationTime, lastmodifiedTime, and expirationTime. dataServerID stands for the ID of this <dataServer>. controlServerID stands for the ID of the control server this <dataServer> registers with. In case where the <dataServer> registers with multiple control servers, this attribute stands for a list of controlServerID. listOfDGSCLs is a list of <d/gscl> which are assigned to this <dataServer>. listOfApps is a list of <application> which are assigned to this <dataServer>.

The resource "dataServers" may be a sub-resource of <scl>, <application>, or <cnsclBase>. For the <cnsclBase>/dataServers, <dataServer> may also have sub-resources "groups" <NUM> for data server to create groups on the control server, and "containers" <NUM> for data server to create containers on the control server, so that each data server may create groups and containers on their control servers.

<FIG> shows an example structure of resource "controlServers. " controlServers is a collection resource, which includes multiple <controlServer> instances. Each <controlServer> instance <NUM> may have the following attributes: controlServerID, dataServerIDs, creationTime, lastmodifiedTime, and expirationTime. controlServerID stands for the ID of this <controlServer>, and dataServerIDs stands for the ID of the data server this <controlServer> has. In case where this <controlServer> has multiple data servers, this attribute may stand for a list of dataServerIDs.

The resource "controlServers" may be a sub-resource of <scl>, <app>, or <dnsclBase>. For the <dnsclBase>/controlServers, <controlServer> may also have sub-resources "groups" <NUM> for the control server to create groups on the data server and "containers" <NUM> for the control server to create containers on the data server, so that each control server may create groups and containers on their data servers.

<FIG> shows an example structure of resource "requestedServices. " "requestedServices" describes which service types that a <d/gscl> or an <application> requests. It is a collection of <serviceInstance>. Each <serviceInstance> <NUM> may have the following attribute: serviceType, expirationTime, startTime, and creationTime. serviceType stands for the class or the type of the service. Each service type may have some sub-attributes including performance requirements (such as delay, throughput, packet loss ratio, etc.), billing properties (such as flat-rate, usage-based, free, etc.), and usage bounds (such as maximum storage size, maximum traffic volume, etc.). expirationTime stands for the ending time, by then this <serviceInstance> will become invalid as requested. startTime stands for the starting time that this <serviceInstance> will start as requested. creationTime stands for the creation time of this <serviceInstance>.

<FIG> shows an example structure of resource "agreedServices. " "agreedServices" describes which service types are approved to a <d/gscl> or an <application>. It is a collection of <agreedServiceInstance>. Each <agreedServiceInstance> <NUM> may have the following attribute: requestedServiceID, agreedServiceType, expirationTime, startTime, and creationTime. requestedServiceID indicates the reference to a requested service instance stored in "requestedServices". agreedServiceType stands for the class or the type of the agreed service. Each agreed service type may have some sub-attributes including performance requirements (such as delay, throughput, packet loss ratio, etc.), billing properties (such as flat-rate, usage-based, free, etc.), and usage bounds (such as maximum storage size, maximum traffic volume, etc.). expirationTime stands for the time by then this <serviceInstance> will become invalid as agreed. startTime stands for the starting time that this <serviceInstance> will start as agreed. creationTime stands for the creation time of this <serviceInstance>.

<FIG> shows an example structure of "trafficStatistics" resource <NUM>. trafficStatistics may have multiple <performanceMetric> <NUM> sub-resources and one accessHistories <NUM> sub-resource. Each <performanceMetric> <NUM> may have the following attributes: name, measureMode, measurePeriod, startTime, creationTime, and expirationTime. Name indicates the name of this <performanceMetric>. It may be delay, delay jitter, throughput, packet loss ratio, or the like. measureMode stands for how this <performanceMetric> may be measured. It may be periodically or one-time up-to-date average measurement, minimum or maximum value, etc. measurePeriod stands for the period for each measurement. startTime stands for when this <performanceMetric> starts to be measured. creationTime is the time when this <performanceMetric> is created. expirationTime is the time when <performanceMetric> is expired.

Each <performanceMetric> <NUM> may have sub-resource "results" <NUM> to store measurement values. Each <resultInstance> stands for a value. Each <resultInstance> may have two attributes: startTime and endTime. startTime is the start time of the <resultInstance> and endTime is the end time of the <resultInstance>.

Each <performanceMetric> <NUM> may have sub-resource "actions" <NUM>, which has two attributes (start and stop) to start or stop the measurement by using UPDATE or CREATE method on those two attributes. Attribute start is for starting the measurement, and attribute stop is for stopping the measurement.

As alternative embodiments, the resources "requestedServices", "agreedServices", and "trafficStatistics" may be directly applied to the conventional ETSI M2M resource structure, (e.g., adding them as a sub-resource of <scl> and <application>), to provide charging and billing function.

A new attribute may be added for the application to indicate if its data may be distributed to other SCLs, besides the hosting SCL. For example, an attribute "Local" may be used. By using this attribute, the application that registered to an SCL (i.e., the hosting SCL) may indicate and decide whether its data may distributed to other SCLs besides the hosting SCL. The attribute "Local" may be a Boolean value. For example, when it is set to "<NUM>", it means the data is available only at the hosting SCL. Alternatively, the attribute may be a reference to sub-resource containers.

Privacy control may be performed when data is shared in distributed SCLs. Access rights may be created as resources, and each access right resource's URI may become the AccessRightID associated with different resources. The access right resource defines who may do what (e.g., READ, WRITE, CREATE, DELETE, DISCOVER, etc.).

When two SCLs are owned by different businesses, they may not be able to establish an access right completely. The application who creates the data on a hosting SCL may decide the general rule of whether the data may be shared.

In one embodiment, when an SCL owned by a different service provider is registered to a hosting SCL, the hosting SCL may create or update the access right resources to define the access right for the SCL belonging to another SCL. The hosting SCL may apply the AccessRightID to different resources in its resource tree.

To enhance the access right protection over distributed SCLs, (e.g., over SCLs owned by different service providers), the conventional access right permissions and flags may be extended. New "permissionFlags" values that indicates an access mode may be defined to support additional operations. Table <NUM> shows example permissionFlag values. A new "externalPermissions" attribute may be introduced to define permissions for SCLs owned by different service providers. If the attribute "externalPermissions" is absent, the entities that correspond to ancestor resources may have no permissions.

Service capabilities are the functionalities that one SCL supports. Among the various service capabilities defined by ETSI M2M standard, an SCL may not support all service capabilities and may rely on capabilities provided by different SCLs. Before sharing the detail of the service capabilities, SCLs may register with the other SCL or mutually register with each other depending on the requirement like whether both want to share the capabilities or just one SCL wants to get support from other SCL. There may be security exchanges between two SCLs that establish a shared capability. Capability sharing may be performed by NSCLs, GSCLs, and DSCLs by sharing the detail of the capabilities they support and the capabilities they want to share.

Service capability sharing may be transparent to other M2M entities such as M2M devices and M2M network applications, which use the shared service capabilities. In other words, the original SCL which shares service capabilities from other SCLs may be kept in the loop and may control related procedures. For example, suppose NSCL1 shares or gets extra service capabilities (e.g., remote entity management (REM)) from NSCL2. There is an M2M network application (NA1) and an M2M device (Dev1) registered with NSCL1. Since NSCL1 does not have REM, it may rely on the REM in NSCL2 to manage Dev1. NA1 may still issue a management command to NSCL1, and NSCL1 may forward the management command to NSCL2. From there on, NSCL2 may use its REM to manage Dev1 on behalf of NSCL1 and get a response back from Dev1. NSCL2 may forward a management response back to NSCL1 and NSCL1 may forward the response to NA1. In this process, both request and response messages may pass through, and under the control of, NSCL1, and both Dev1 and NA1 may not need to be aware of the existence of NSCL2.

In another example, DSCL1 may register with NSCL1. NSCL1 may have a shared container management service capability with NSCL2. NSCL1 and NSCL2 negotiate and configure such capability while they are registered with each other. NSCL2 may conduct container management for DSCL1 even though DSCL1 is not registered with NSCL2.

In one embodiment, capability management resources may be added to the SCL resource tree to facilitate and maintain the SCL-SCL interaction and sharing of capabilities. <FIG> shows an example resource for capability management under <sclBase>. <FIG> shows an example structure of resource "capabilities. " <FIG> shows an example structure of resource "remoteCaps. " The resource structures in <FIG> add the feature for SCLs to be able to keep the details for the capabilities/functionalities that it shared with another SCL. The SCL may track the capabilities/functionalities supported by itself.

A collection resource called "capabilities" <NUM> may be added to the resource tree <sclBase> <NUM> (as shown in <FIG>). The "capabilities" resource <NUM> may be used to track the capability sharing of the current SCL with other SCLs. Under each instance of <scl> <NUM>, there may be a resource "remoteCaps" <NUM>, which records the capabilities of the remote SCLs registered with the current SCL base.

Referring to <FIG>, the "capabilities" resource <NUM> may contain one or multiple instances called <capability>, where each <capability> instance is the capability sharing agreement with another SCL. For each instance of <capability>, it may have capSupported <NUM>, capSharedTo <NUM>, and capSharedFrom <NUM>. "capSupported" <NUM> indicates the capabilities supported by the current SCL, (e.g., registration). "capSharedTo" <NUM> indicates what capabilities that the current SCL may provide to other SCLs and to what entities these capabilities may be shared, (e.g., data management). "capSharedFrom" <NUM> indicates what capabilities that the current SCL obtained from other SCLs and from which entities respectively.

Referring to <FIG>, under the resource "remoteCaps" <NUM>, a remote SCL which registered with the current SCL may either provide its capability in a <capability> instance <NUM>, or may announce its capability by providing a link of its capability URI in the "attribute" under <capabilityAnnc> <NUM>.

Procedures for the operations of different SCL service capability configurations are described hereafter. The operations may apply to control plane reference points.

Before sharing the service capabilities, SCLs may register with the other SCL. The registration may be mutual or unidirectional depending on the requirement. For example, if only one SCL wants to share the capability with other SCL, mutual registration may not be needed. If the NSCLs that want to share capabilities belong to two different service providers, the NSCLs may perform security procedures before sharing service capabilities. For example, they may use shared password or some known key to authenticate each other during registration procedure.

<FIG> is a signaling diagram of an example procedure for capability sharing with mutual registration. NSCL-<NUM><NUM> sends a registration request (e.g., CREATE) to NSCL-<NUM><NUM> (<NUM>). In the request message, NSCL-<NUM><NUM> may include capability information, including capSupported and/or capSharedTo. NSCL-<NUM><NUM> knows the capabilities available from NSCL-<NUM><NUM> from capSharedTo. NSCL-<NUM><NUM> may perform the security checks to authenticate the communication of NSCLs and if authenticated may create a resource for NSCL-<NUM><NUM> (<NUM>). If NSCL-<NUM><NUM> is not allowed to communicate with NSCL-<NUM><NUM>, the request may be rejected. NSCL-<NUM><NUM> then sends a response to NSCL-<NUM><NUM> (<NUM>).

For mutual registration, NSCL-<NUM><NUM> sends a registration request (e.g., CREATE) to NSCL-<NUM><NUM> (<NUM>). In the request message, NSCL-<NUM><NUM> may include capability information, including capSupported and/or capSharedTo. NSCL-<NUM><NUM> knows the capabilities available from NSCL-<NUM><NUM> from capSharedTo. NSCL-<NUM><NUM> may perform the security checks to authenticate the communication of NSCL-<NUM><NUM> (<NUM>). If NSCL-<NUM><NUM> is not allowed to communicate with NSCL-<NUM><NUM>, the request may be rejected. If authenticated, NSCL-<NUM><NUM> sends a response to NSCL-<NUM><NUM> (<NUM>).

When NSCL-<NUM><NUM> needs to obtain capabilities from NSCL-<NUM><NUM> (<NUM>), NSCL-<NUM><NUM> may send a CREATE request to NSCL-<NUM><NUM> for capability sharing (<NUM>). In the request, NSCL-<NUM><NUM> indicates the capabilities it requires from NSCL-<NUM><NUM>. Once NSCL-<NUM><NUM> grants the requested capabilities, NSCL-<NUM><NUM> may create the capSharedFrom resource, for example, under the <scl2Base>\scls\<scl1>remoteCaps\<capability> resource (<NUM>). NSCL-<NUM><NUM> sends a success response to NSCL-<NUM><NUM> (<NUM>).

<FIG> is a signaling diagram of an example procedure for capability sharing without mutual registration. NSCL-<NUM><NUM> sends a registration request (e.g., CREATE) to NSCL-<NUM><NUM> (<NUM>). In the request message, NSCL-<NUM><NUM> may include capability information, including capSupported and/or capSharedTo. NSCL-<NUM><NUM> knows the capabilities available from NSCL-<NUM><NUM> from capSharedTo. NSCL-<NUM><NUM> may perform the security checks to authenticate the communication of NSCLs and if authenticated and NSCL-<NUM><NUM> is allowed to communicate with NSCL-<NUM><NUM>, NSCL-<NUM><NUM> may create a resource for NSCL-<NUM><NUM> (<NUM>). If NSCL-<NUM><NUM> is not allowed to communicate with NSCL-<NUM><NUM>, the request may be rejected. NSCL-<NUM><NUM> then sends a response to NSCL-<NUM><NUM> (<NUM>).

Without mutual registration, NSCL-<NUM><NUM> may not be aware of the capabilities supported and offered by NSCL-<NUM><NUM>. Alternatively, NSCL-<NUM><NUM> may include such information, (e.g., capSupported and/or capSharedTo), in the response to NSCL-<NUM><NUM>. Since NSCL-<NUM><NUM> is registered to NSCL-<NUM><NUM>, NSCL-<NUM><NUM> may decide if it may grant capabilities to NSCL-<NUM><NUM>.

<FIG> is a signaling diagram of an example procedure for SCL mutual registration. The issuer SCL <NUM> may send a CREATE request to the hosting SCL <NUM> for registration (<NUM>). Mutual registration may be initiated by the issuer SCL <NUM>. If so, in the CREATE request, the issuer SCL <NUM> may indicate that a mutual registration is required. The hosting SCL <NUM> may check if the issuer SCL <NUM> is authorized to create the resource for the registration (<NUM>).

If it is determined that the issuer SCL <NUM> is authorized, the hosting SCL <NUM> sends a positive respond to the request (<NUM>). If mutual registration was not requested by the issuer SCL <NUM> in the CREATE request, the mutual registration may be requested by the hosting SCL <NUM>. The hosting SCL <NUM> may indicate it in the response. The issuer SCL <NUM> may wait for the mutual registration request (<NUM>). The issuer SCL <NUM> knows that there is a mutual registration pending, since it either requested the mutual registration, or the response from the hosting SCL <NUM> indicated a mutual registration.

The hosting SCL <NUM> sends a mutual registration request (e.g., CREATE) (<NUM>). The issuer SCL <NUM> authenticates and authorizes the hosting SCL <NUM> (<NUM>). The issuer SCL <NUM> responds positively to the request (<NUM>).

The issuer SCL <NUM> may creates the scl resource in its sclBase resource tree for the hosting SCL <NUM> and the hosting SCL <NUM> may creates the scl resource in its sclBase resource tree for the issuer SCL <NUM> (<NUM>, <NUM>).

For the issuer and hosting SCL <NUM>/<NUM> to indicate that a mutual registration is needed, two primitive types for the create request may be introduced: SCL_MUTUAL_CREATE_REQUEST and SCL_MUTUAL_CREATE_RESPONSE. Tables <NUM> and <NUM> show sclCreateRequestIndication and sclCreateResponseConfirm (successful case) primitives, respectively. STATUS_ACCEPTED may be used for the hosting SCL <NUM> when sending the response back to the issuer SCL <NUM>. Alternatively, a new status code STATUS_MUTUAL_REGISTRATION_PENDING may be used.

Alternatively, an SCL may indicate that a mutual registration is required in the scl resource. For example, an attribute "mutualRegis" may be added to the <scl> resource attribute to indicate that a mutual registration is required. In this way, the indication may be discovered and retrieved by other SCLs. Alternatively, the SCL may include it as a primitive attribute in the sclCreateRequestIndication.

To facilitate an SCL to decide whether a mutual registration should be done, for example, an attribute called "sclType" may be added to the <scl> resource attribute list. The sclType attribute may indicate the SCL type: NSCL, GSCL, DSCL.

<FIG> and <FIG> are a signaling diagram of an example procedure for GSCL-GSCL capability sharing. <FIG> and <FIG> show the call flow when GSCL-<NUM><NUM> and GSCL-<NUM><NUM> are registered with NSCL-<NUM><NUM> and NSCL-<NUM><NUM>, respectively, and GSCL-<NUM><NUM> wants to communicate and share capabilities with GSCL-<NUM><NUM>. Although not shown in <FIG> and <FIG>, GSCL-<NUM><NUM> and GSCL-<NUM><NUM> may perform mutual registration.

The capability sharing procedures between GSCL-<NUM><NUM> and GSCL-<NUM><NUM> are the same as NSCL-<NUM><NUM> and NSCL-<NUM><NUM>. The additional complexity is the role of NSCLs in the communication and security. <FIG> and <FIG> show as an example that security is managed by the NSCLs, and the communication is directed between GSCLs (with initial indication from NSCL-<NUM>). If the security and trust relationship allow, a fully distributed communication between xSCLs may be achieved.

GSCL-<NUM><NUM> indicates to NSCL-<NUM><NUM> that it wants to communicate with GSCL-<NUM><NUM> (<NUM>). GSCL-<NUM><NUM> is already registered with NSCL-<NUM><NUM>, and GSCL-<NUM><NUM> is already registered with NSCL-<NUM><NUM>. NSCL-<NUM><NUM> may relay the request to NSCL-<NUM><NUM> (<NUM>), and NSCL-<NUM><NUM> may relay the request to GSCL-<NUM><NUM> (<NUM>). It is assumed that NSCL-<NUM><NUM> and NSCL-<NUM><NUM> have a trust relationship. GSCL-<NUM><NUM> sends a response which is related by NSCL-<NUM><NUM> and NSCL-<NUM><NUM> to GSCL-<NUM><NUM> (<NUM>, <NUM>, <NUM>).

GSCL-<NUM><NUM> initiates the registration procedure by sending a registration request to GSCL-<NUM><NUM> (<NUM>). In the request message, GSCL-<NUM><NUM> may include capability information, including capSupported and/or capSharedTo. GSCL-<NUM><NUM> knows the capabilities available from GSCL-<NUM><NUM> from capSharedTo. GSCL-<NUM><NUM> may perform security checks to authenticate the communication from GSCL-<NUM><NUM> (<NUM>). GSCL-<NUM><NUM> may check supported service capabilities (<NUM>).

Before sending a successful response, GSCL-<NUM><NUM> may ask for the authentication check from NSCL-<NUM><NUM> (<NUM>). If GSCL-<NUM><NUM> and GSCL-<NUM><NUM> belong to the same service provider, GSCL-<NUM><NUM> may not need to authenticate the GSCL-<NUM><NUM>. If GSCL-<NUM><NUM> and GSCL-<NUM><NUM> do not belong to the same service provider, NSCL-<NUM><NUM> may retrieve and verify GSCL-<NUM><NUM> from NSCL-<NUM><NUM> (<NUM>). NSCL-<NUM><NUM> sends response back to NSCL-<NUM><NUM> (<NUM>).

NSCL-<NUM><NUM> sends a successful response to GSCL-<NUM><NUM> if GSCL-<NUM><NUM> and GSCL-<NUM><NUM> are allowed to communicate (<NUM>). GSCL-<NUM><NUM> sends a successful response to GSCL-<NUM><NUM> (<NUM>).

When GSCL-<NUM><NUM> needs to obtain capabilities from GSCL-<NUM><NUM>, GSCL-<NUM><NUM> may send a request (e.g., CREATE) to GSCL-<NUM><NUM> for capability sharing (<NUM>, <NUM>). In the request, NSCL-<NUM><NUM> indicates the capabilities it requires from GSCL-<NUM><NUM>. In terms of the capabilities requested from GSCL-<NUM><NUM>, additional security check procedures may be performed between NSCL-<NUM><NUM> and NSCL-<NUM><NUM> (<NUM>). GSCL-<NUM><NUM> grants the requested capabilities and sends a successful response to GSCL-<NUM><NUM> (<NUM>, <NUM>). GSCL-<NUM><NUM> may update NSCL-<NUM><NUM> for the change of the capabilities, and GSCL-<NUM><NUM> may update NSCL-<NUM><NUM> for the change of the capabilities (<NUM>, <NUM>).

Currently in ETSI M2M, when SCL1 registers with SCL2, two <scl> resources are created, one in SCL1 and one in SCL2. <FIG> shows the conventional SCL resource structure. The resource on SCL1 may be like <sclBase1>/scls/<scl2>. This is a record that SCL1 keeps for itself which indicates that SCL1 is registered with SCL2. The resource on SCL2 may be like <sclBase2>/scls/<scl1>, which is the resource created on SCL2 that is related to SCL1. If there is another SCL, named SCL3, that registers with SCL1, a resource like <sclBase1>/scls/<scl3> will be created, based on the resource tree structure defined in ETSI M2M. There is no way to differentiate between scl2 and scl3.

The resource tree structure may be changed as shown in <FIG>. In one embodiment, the two kinds of SCLs may be differentiated as scls-in <NUM> and scl-out <NUM>. The scls-in <NUM> is for the incoming scls, and the scls-out <NUM> is for the outgoing scls. It should be noted that the name of the scls is provided as an example and any other name may be used. Using the same example as above, the different SCLs may be stored as: <sclBase1>/scls-out/<scl2> and <sclBase1>/scls-in/<scl3>.

In another embodiment, the same SCL resource structure may be kept without change, and a new attribute called, for example, "Direction" may be introduced. It should be noted that the name of the attribute is merely an example and any name may be used for the attribute. The "Direction" attribute indicates that if the SCL resource is the SCL where the local SCL registered to, or other SCLs that registered with the local SCL.

Claim 1:
A method implemented by a first service entity, comprising:
receiving a request message for service from a second service entity, the request message including requested service capability information for a set of services, wherein the request message further includes performance requirements for the set of services, wherein the second service entity is remote from the first service entity;
determining to grant the service based on whether the first entity can support any capability listed in the requested service capability information and whether the performance requirements can be met;
creating an entry of a resource for the granted service based on the requested service capability information, wherein the entry includes a list of granted service IDs, wherein the entry is created using RESTful architecture; and
sending a successful response message based on creating the entry.