GB/Z 41384-2022Technical requirements for M2M service platform (English PDF)

Foreword

This document was drafted in accordance with the rules given in GB/T 1.1-2020, Directives for standardization - Part 1: Rules for the structure and drafting of standardizing documents.

This document is one of the M2M service series of documents. The structure and names of the series are as follows: GB/Z 41385, General technical requirements for M2M service; GB/Z 41383, Technical requirements for M2M application communication protocol; GB/Z 41384, Technical requirements for M2M service platform; GB/T 37294, Technical requirements for M2M terminal device service capability.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The issuing body of this document shall not be held responsible for identifying any or all such patent rights.

This document was proposed by the Ministry of Industry and Information Technology of the People's Republic of China and is under the jurisdiction of the Ministry of Industry and Information Technology (Telecommunications).

The drafting organizations of this document are China Academy of Information and Communications Technology, China Mobile Communications Group Co., Ltd., China United Network Communications Group Co., Ltd., Huawei Technologies Co., Ltd., ZTE Corporation and Datang Telecom Technology and Industry Group.

The main drafters of this document are Liu Rongduo, Du Jiadong, Zhang Yong, Jia Xueqin, Mao Junling, Gao Ying, Sun Aifang, Yang Kun, Wu Hao and Xu Hui.

1 Scope

This document specifies the technical requirements for the M2M service platform, including the system architecture, functions, performance and interface technical requirements of the M2M service platform.

This document applies to M2M service platform equipment used in M2M communication.

2 Normative references

The contents of the following documents constitute indispensable provisions of this document through normative references in the text. For dated references, only the edition cited applies to this document. For undated references, the latest edition (including all amendments) applies to this document.

YD/T 2398-2012, General technical requirements for M2M service.

ETSI TS 102 690 V1.1.11, Machine-to-Machine communications (M2M); Functional architecture.

3 Terms and definitions

For the purposes of this document, the following terms and definitions apply.

3.1 M2M service platform: platform that manages M2M services.

3.2 M2M applications: applications that contain service logic and whose service capabilities can be accessed through open interfaces.

3.3 M2M device peripherals: devices that host M2M applications but have neither M2M service capabilities nor network communication functions.

3.4 M2M gateway: terminal device that uses M2M service capabilities to connect and interact M2M device peripherals with the network and applications; it may also host M2M applications.

3.5 M2M terminal: device having M2M device application capabilities and network communication functions. Note: an M2M terminal contains at least one M2M application and one communication module; it may also contain one or more applications and one or more M2M communication modules.

4 Abbreviations

For the purposes of this document, the following abbreviations apply: AE-ID - Application Entity Identity; API - Application Programming Interface; CDR - Charging Data Record; CoAP - Constrained Application Protocol; FTP - File Transfer Protocol; HTTP - Hypertext Transfer Protocol; M2M - Machine to Machine; SP - Service Provider; UICC - Universal Integrated Circuit Card; URI - Uniform Resource Identifier; USIM - Universal Subscriber Identity Module.

5 M2M service platform architecture

The architecture of the M2M service platform is shown in Figure 1. The figure shows four layers: the M2M application layer (M2M applications), connected through the Mca interface to the common service capability layer, which contains the M2M service platform; the network capability layer (core network, cellular network, fixed access, WLAN), connected to the platform through Mcn interfaces; and the sensing extension layer (M2M gateway with M2M capillary network, M2M terminals and terminal peripherals; M2M terminal with terminal peripherals). A management support system with a network management system and a charging system sits beside the layers. Inside the platform, the service capability set comprises device management, group management, external capability invocation, resource management, data storage and forwarding, and access control; the common capability set comprises identifier management and addressing, charging, security and admission control.

The service capabilities implemented by the M2M service platform are divided by function as follows. a) Common capabilities: security - supports security mechanisms such as authentication, authorization and key handling; charging - charges for the use of the service capabilities of the M2M service platform and generates charging records; identifier management and addressing - assigns identifiers to M2M terminals, M2M gateways and M2M applications at the service level and the transport control level and keeps the identifiers unique; admission control - implements registration, re-registration and deregistration of M2M terminals, M2M gateways and M2M applications.

b) Service capabilities: access control - sets and updates the access rights of M2M terminals, M2M gateways and M2M applications; data storage and forwarding - the platform aggregates and stores data collected by terminal peripherals, registration information, device management information and other information, and provides data forwarding where the access rights allow; group management - creates, updates and deletes groups and supports batch access to group members; device management - supports one or more management protocols (such as YD/T 2398-2012) and manages M2M terminal peripherals, M2M terminals and M2M gateways through a unified interface; external capability invocation - invokes network capabilities, support capabilities and existing network service capabilities; resource management - provides a unified resource description and modelling method for M2M service capabilities, M2M applications, M2M terminals and M2M gateways, supporting mutual discovery and shared invocation of heterogeneous devices and service resources.

The M2M service platform shall provide the Mca and Mcn interfaces. The Mca interface is the interface through which applications access the M2M service platform and provides security, M2M application admission control, data forwarding and other functions. The Mcn interface is the interface through which the service capabilities in an M2M device or M2M gateway communicate with the service capabilities in the M2M service platform and provides security, M2M terminal and M2M gateway admission control, data forwarding and other functions.

On this basis the Mca and Mcn interfaces are extended as follows: the Mca interface extends security, M2M application admission control and data forwarding, and supports access control of M2M application data, M2M application data storage, management of and access to groups, and device management; the Mcn interface extends security, M2M terminal and M2M gateway admission control and data forwarding, and supports access control of M2M terminal and M2M gateway data, data storage, management of and access to groups, and device management.

6 Service capability requirements of the M2M service platform

6.1 General. The M2M service platform follows the unified rules of the M2M system and provides functions to device users and M2M applications in the form of functional modules, including admission control, access control, data storage and forwarding, group management and device management. As the key intermediate entity between the core network and upper-layer applications, the M2M service platform shall be capable of abstracting and managing core network capabilities, and shall provide supporting functions for security and privacy protection, charging, identifier management and addressing, external capability invocation and resource management.

6.2 Access control. The M2M service platform sets different usage or management rights on services and terminal devices for different users, ensuring that legitimate users perform only operations matching their rights. M2M applications and M2M device users are subject to access control when using the platform; the platform performs access control on them based on subscription information, local policy and user configuration, and creates and maintains multiple access rights for data on that basis. When an M2M application or M2M device user accesses platform data, the platform allows other M2M applications or device users to access the data according to the authorized access subjects and authorized operation types (such as retrieve and modify) set in these access rights.

6.3 External capability invocation. External capability invocation means that, in addition to the capabilities defined in this document, the M2M service platform can invoke capabilities outside the platform, mainly those of the underlying 3GPP network, divided by function into network capabilities, support capabilities and existing network service capabilities. The platform can invoke network capabilities, opening to M2M devices access modes such as 2G, 3G, 4G, fixed access and WLAN and giving the platform the means to invoke network capabilities. The platform can provide management support capabilities, implementing charging, security and network management to support its operation.

The platform can provide interfaces for invoking existing network service capabilities (such as location services). According to the needs of M2M applications, it can invoke the location service interface of the existing network (such as the Le interface defined by 3GPP) to obtain location information from the location server and pass it to the M2M application; if the M2M terminal has positioning capability, the location can also be queried directly from the terminal through the platform. To protect the privacy of user location information, the platform performs privacy protection after receiving an access request from an M2M application; according to the configuration of the M2M device user, privacy protection can also be performed by the M2M terminal or M2M gateway to confirm whether their own location information may be accessed.

6.4 Data storage and forwarding. The M2M service platform stores various data, including device description information, application description information and terminal peripheral data, and provides data storage, forwarding and traffic offloading. According to the needs of M2M applications and device users, it receives their access requests and provides data; if the requested data is stored in another M2M terminal or M2M gateway and the platform stores a link to the data, the platform forwards the resource access request to that terminal or gateway and forwards the corresponding response to the M2M application or device user. Data with specific requirements is transparently transmitted through the platform; for data not requiring transparent transmission through the platform, management data and service data are handled with split (offloaded) management.

6.5 Device management. The M2M service platform shall maintain the mapping between device management object resource data and the management object information in remote M2M terminals or gateways, and the mapping between resource access requests and the management commands of the specific device management protocols. It receives access requests for device management object resources from M2M applications, converts them according to the preset mapping into device management commands supported by the target terminal or gateway, converts the accessed resource data into the management object information operated on by those commands, sends the adapted commands to the target terminal or gateway, and returns the execution results received from it to the M2M application.

6.6 Group management. Groups are created according to the needs of M2M applications and device users and managed through a unified interface. A group may contain sub-groups, which may be created by the M2M application or by the platform. Groups are managed according to these needs, including batch access to group members for create, query, update and delete, and batch access requests to member resources (such as batch retrieval of sensing data or control of devices). The group management module is also responsible for avoiding duplicate and circular access to group members. To avoid congestion, each group is allocated a certain traffic volume and group traffic is controlled: traffic policies are configured on the platform according to user subscription information, and the size of the group membership is limited during group creation or update.

6.7 Resource management. The resource management function mainly implements the functions offered by the platform through create, retrieve, update and delete operations on different types of service resources, which may include terminal device resources, data resources, network resources, group resources and user resources; for example, group management is achieved by operating on group resources. It shall also provide a unified description and modelling method for resources, supporting mutual discovery and shared invocation of heterogeneous devices and service resources. Besides individual service resources, resource management shall include management of collection resources, which hold a series of service resources of the same type, such as terminal device collections and group collections, enabling classified storage and shared invocation. Service resources are stored in the platform, the M2M gateway or the M2M terminal device and opened to M2M applications for shared invocation. Resource management opens an API to M2M applications, with operations carried over protocols such as HTTP or CoAP.

7 Admission control

M2M applications register with the M2M service platform so that other M2M applications or device users can find or discover them through the platform. The platform receives the registration requests of M2M applications passed through the application interface, stores locally the application description information carried in the request, and assigns a globally unique application identifier to each registered application.

M2M terminals and M2M gateways register with the platform so that other M2M applications or device users can find or discover the devices through the platform. The platform receives their registration requests passed through the device interface, stores locally the device description information carried in the request, and assigns a globally unique device identifier to each registered terminal or gateway.

Admission control of the M2M service platform may comprise service registration and terminal registration. The service registration flow (Figure 2, between the service platform and the application/service) is: 1) the application server submits a registration request to the platform together with its identity and capability requirements for terminals; 2) the platform responds to the service registration request and obtains the identity and capability requirements; 3) the platform extracts the information of the authorized terminals according to the service and uploads it to the corresponding application server; 4) the application server receives and responds to terminal service access requests passed through the platform and may transmit the service directly to the terminal.

The terminal registration flow (Figure 3, between terminal, service platform and application/service) is: 1) after service registration, the M2M terminal submits a terminal registration request; 2) the platform responds; 3) the terminal submits its registration information; 4) the terminal logs in for the first time and an access authentication request is sent; 5) the terminal logs in, passes access authentication using credentials such as a digital certificate issued by the platform, and uploads its capability information; the platform obtains the identity and capability information of each terminal in the terminal group and, for example by comparing each terminal's capabilities with the service's capability requirements, builds a terminal-service mapping table indicating which services each terminal may access; the table can be updated as services change, and changed terminals are re-authorized.

6) The information of the authorized terminals is uploaded to the corresponding application server; 7) the platform notifies the terminal of the authorization obtained; 8) the terminal submits a service access request to the platform; 9) the platform checks against the terminal-service mapping table whether the terminal has access rights; if so, it sends the request to the corresponding application server to serve the terminal, otherwise it blocks the access; the platform uploads the identity information, or the identity and capability information, of terminals with service access rights to the corresponding application server; 10) the application server sends the service request response directly to the terminal.

8 Identifier management and addressing

8.1 General. The identifiers of M2M terminals, M2M gateways and M2M applications are managed in a unified way to ensure global uniqueness. The M2M service platform stores and manages identifiers related to M2M services to implement the binding between entities and services and the rights mapping between roles and services.

8.2 M2M application identifier. The M2M application identifier App-ID uniquely identifies an M2M application within a given context.

8.3 M2M application entity identifier. The AE-ID uniquely identifies an application entity running in an M2M node, or an application entity that needs to interact with an M2M node. The AE-ID shall be globally unique; within a specific M2M SP domain it may be unique only within that domain, and when used outside the M2M SP domain it shall be extended by the M2M service platform to be globally unique.

8.4 M2M service provider identifier. The M2M-SP-ID is a static value assigned to an M2M service provider that uniquely identifies it.

8.5 M2M service subscription identifier. The M2M service provider uses the M2M-Sub-ID to bind applications, M2M nodes and M2M service platform functions, together with the corresponding services, to a specific M2M service subscription. The M2M-Sub-ID shall: a) be owned and assigned by the M2M service provider; b) indicate the subscribed M2M service provider; c) allow communication with the M2M service provider through it; d) be distinguishable from the M2M underlying network subscription identifier. Each M2M underlying network subscription may correspond to multiple M2M service subscription identifiers.

8.6 M2M node identifier. The M2M-Node-ID uniquely identifies an M2M node.

8.7 M2M service identifier. The M2M-Serv-ID identifies a service offered by the M2M service provider; it is provided by the service provider, corresponds to the subscribed service and is stored in the M2M service subscription.

8.8 Underlying network identifier. The UNetwork-ID identifies an underlying network; it is a static value and is unique within the M2M service provider domain.

8.9 Service role identifier. The SRole-ID identifies an M2M service role. In each M2M service, the M2M service provider shall define one or more M2M service roles; an M2M service role is a set of rights related to M2M service resources.

9 Security requirements

9.1 M2M keys. 9.1.1 M2M root key Kmr. Kmr is used for mutual authentication and key agreement between the M2M terminal/M2M gateway and the M2M service provider. During authentication and key agreement between the M2M terminal/gateway and the M2M service platform, this key is used to derive the M2M connection key (Kmc). Kmr shall be tightly bound, through the M2M-Node-ID, to a unique M2M terminal/gateway and M2M service provider, and may be obtained in different ways depending on the trust relationships between stakeholders in the M2M business model. On the platform side, Kmr shall be kept in the secure environment of the M2M authentication server, which shall protect this security information against unauthorized access or copying. In the M2M terminal/gateway, Kmr shall be kept in a secure environment domain controlled by the M2M service provider, with one Kmr for each trust set of the terminal/gateway. If a trusted relationship exists between the M2M service provider and the access network provider (for example, they are the same entity), access network credentials may also be used as Kmr.

9.1.2 M2M connection key Kmc. Kmc is derived from Kmr after successful mutual authentication. During derivation, Kmc shall be obtained from the M2M authentication server (in the same secure environment as Kmr) and passed to the M2M service platform, where it is kept in a local secure environment domain. Kmc expires when the associated M2M service connection terminates, and its lifetime shall be less than or equal to that of Kmr. A different Kmc is generated for each new M2M service connection. Kmc is used as the symmetric shared key when establishing secure application data sessions between the platform and the M2M terminal/gateway; keys derived from Kmc during security association establishment may be used for secure data transmission on the mId interface. Secure transport sessions established with Kmc always terminate at the platform and at the M2M terminal/gateway.

9.2 Secure environment domain. Secure environment domains are securely isolated from logical entities and may reside in different secure environments or in the same one. Sensitive functions (including storage and processing of sensitive data such as credentials and keys) shall be protected in a secure environment domain controlled by its owner. The service provider owning the M2M service platform and the M2M terminal/gateway shall control its own secure environment domain; the provider of an M2M application may control an independent secure environment domain on the terminal/gateway. An M2M terminal/gateway may include a secure environment domain owned by another party (such as an access network operator, for example the USIM on a 3GPP UICC); if there is a relevant agreement between the owners, credentials stored in that environment may be used.

9.3 M2M security architecture. The security architecture of the M2M system is shown in Figure 4: the security capability in the M2M service platform interacts through the Em interface with the security capability in the M2M service capability layer of the M2M terminal/gateway; the platform, with its common capability set (identifier management and addressing, security, charging, admission control) and service capability set, connects upward to M2M applications and downward through the core network interface to core networks A and B. The platform performs mutual authentication with M2M terminal/gateway devices and derives the keys for establishing secure transport sessions with them; it can obtain the M2M connection key (Kmc) from the M2M authentication server.

During the M2M service connection, the platform shall: perform the M2M service connection procedure with the M2M terminal/gateway, providing mutual authentication and agreement of the connection key (Kmc), in which the M2M root key obtained during bootstrap or pre-provisioned may serve as the permanent shared key between the terminal/gateway and the M2M authentication server; control admission of M2M terminals/gateways to the platform according to policies defined by the M2M authentication server; interact with the M2M authentication server to obtain the information needed for mutual authentication and key agreement; and establish secure transport data sessions on the Em interface.

For the integrity validation function of M2M terminals/gateways, the platform shall: confirm whether the terminal/gateway supports integrity validation; if it does, perform integrity validation according to the integrity validation status and the relevant security policy, and then trigger follow-up actions according to the policy, namely admission control (full, partial or no access) and upgrade, patch or rollback of firmware or software in the terminal/gateway; and use pre-provisioned keys to sign the integrity validation related to policy information.

10 Charging

The charging module has the following capabilities: a) the M2M service platform collects, interprets and processes the usage of session interactions, data storage and network resources (such as SMS, MMS and packet bearer services), compiles charging data and sends it to the charging server; b) the platform supports multiple charging modes, including charging based on M2M service traffic, events, service duration and application type; c) the platform supports both online and offline charging.

The platform manages access according to user subscription information (for example management of subscribed M2M terminals and gateways and the ability to use network resources). The charging module can configure charging parameters for chargeable events according to operator policy and subscription information, and collect session interactions and network resource usage. Charging parameters may include the request originator (M2M application, device user), service type, the request receiver (M2M application, M2M terminal, gateway), network resource usage and timestamp. The charging function determines the charging CDR of an access request and sends it to the charging server so that the originator of the request can be charged; it also determines the CDR for data storage, periodically collecting data storage information including M2M application and device user, storage space and duration, and sends it to the charging server.

Chargeable events fall into three categories: invocation of service functions, resource usage and network usage. Configurable chargeable events include: a) an M2M application or device user using service function modules of the platform such as device management, subscription notification, access control and group management - receipt or initiation of an access request message by the platform indicates a chargeable event; b) an M2M application or device user using platform resources for data storage, a chargeable event triggered by a timer; c) an M2M application using network resources for communication, including SMS, MMS, packet domain bearer, short-range wireless communication and wired communication.

The charging module may configure one or more chargeable events at the same time, configure charging parameters per event and record each parameter when a chargeable event occurs, as shown in Table 1. The platform obtains charging data from the records as needed and records it as a CDR (charging data record); the charging module then passes the data to the charging server, over an interface that may follow protocols such as FTP or Diameter or rely on the operator's internal interface.

Table 1 (Charging parameters) lists: for the service function event - request originator identifier (M2M application identifier or device user identifier), request receiver identifier (M2M service platform identifier or device user identifier), service function identifier (device management, subscription notification, access control, group management, etc.), timestamp (time of charging), traffic volume (consumed by the access request and response), response result (status code in the access response) and protocol type (such as HTTP or CoAP); for the resource usage event - timestamp and data storage capacity in Kbytes; for the network usage event - network communication type (SMS, MMS, packet domain bearer, short-range wireless, wired, etc.) and access network identifier.

The charging management flow (Figure 5, between charging server, charging module and service function module of the platform, and M2M application) is: 1) the charging module configures chargeable events and charging parameters; 2) the service function module receives the access request of the M2M application or device user for service resources and sends it to the charging module; 3) the charging module records and compiles charging data: 3a) when it determines from the configured events that a chargeable event has occurred, it shall determine and record the charging data related to the request according to the configured parameters, which may include the M2M application or device user identifier, service function identifier and traffic volume; 3b1) for online charging, it shall send the charging data (which may include service function identifier and charging unit) to the charging server so that the server can confirm whether access to the service resource is allowed; 3b2) the charging server returns a response allowing the access.

4) The service function module processes the access and generates a response; 5) it sends the response to the M2M application and to the charging module; 6) when the charging module confirms that the access succeeded, it shall determine and record the charging data related to the response, which may include timestamp, retrieved resource result, duration and traffic volume; 7) the charging module transfers the charging data to the charging server for rating and generation of the bill: 7a1) it sends the charging data related to the request and response, which shall also include information such as message sequence number and end marker to distinguish different charging data; 7a2) the charging server returns a response confirming successful transmission.

11 Network management

The M2M service platform shall provide a northbound interface towards the network management system to cooperate in configuration management, performance management, fault management and security management of devices.

12 Implementation of M2M service platform capabilities

12.1 Data storage and forwarding. The M2M service platform provides data storage, forwarding and offloading functions to store the registration information and data of M2M applications, M2M devices and M2M gateways, and, according to the access rights of the data, provides data retrieval and exchange between M2M applications, M2M terminals and M2M gateways. Data stored on the platform is data in a broad sense: raw data sent by M2M applications, terminals and gateways, processed data, and also device description, application description, geographic location and subscription information. Data is thus a concrete form of resource, and the platform supports create, retrieve, update and delete operations on it.

Specifically, the platform: a) receives and stores data sent by M2M applications, devices and gateways, and can support replacement of M2M terminals and gateways and migration of terminal peripherals based on the stored data; b) supports sending data to M2M applications, devices and gateways, receives read requests from them and provides the data in the response; if the requested data is stored in another M2M terminal or gateway and the platform stores a link to it (such as a URI), the platform forwards the request to that terminal or gateway and forwards the response to the requester.

The platform supports forwarding the data of a terminal peripheral between different M2M gateways (i.e. gateway service capability layers), as shown in Figure 6, where M2M gateway 1 serves the peripheral after it changes its serving gateway and M2M gateway 2 served it before and holds its data; both gateways are registered with the platform. The flow is: 1) the peripheral determines that it must change its serving gateway from gateway 2 to gateway 1 and obtains the location of its data in gateway 2, such as the storage path or URI; 2) the peripheral registers with gateway 1; 3) after successful registration it sends gateway 1 a data transfer request containing a migration identifier (indicating that the peripheral changes its serving gateway service capability layer) and the location of its data in gateway 2; 4) gateway 1 sends the platform a read request containing that location; 5) the platform determines that the data is stored in gateway 2 and forwards the read request; 6) gateway 2 reads the data and sends it to the platform; 7) the platform sends gateway 1 a read response containing the data; 8) gateway 1 stores the data and notifies the peripheral that the data has been transferred from gateway 2 to gateway 1.

Data offloading: for forwarded data whose management data and service data are to be managed separately, bearer links can be established between the terminal-side and application-side interfaces of the platform, and data flows entering the platform over them are distinguished, identified and forwarded according to their identifiers. Uplink and downlink flows generated between the application server and terminals during service execution are identified as service data flows and encapsulated with the corresponding interface address information; other flows such as management configuration, fault reports and software/hardware upgrades are identified as management control data flows and encapsulated with the address of the management control module on the platform. Service data flows are sent to the application-side or terminal-side interface according to their identifier and interface address; management control data flows are offloaded to the management control module.

12.2 Device management. The platform can manage terminals, gateways and terminal peripherals of the sensing extension layer. Device management functions include: a) remote configuration management, fault management, performance management and software/firmware upgrade of M2M terminal peripherals, terminals and gateways; b) remote wake-up triggering and configuration bootstrap of them; c) maintenance of the mapping between their management object information and management object resource data; d) adaptation of the various device management command functions into a unified resource access API offered to M2M applications; e) maintenance of device management sessions between the platform and them. The platform maintains the mappings described in 6.5 and converts access requests from M2M applications into device management commands for the target terminal or gateway, returning the results to the application.

The platform sends device management commands to terminal peripherals, terminals and gateways using specific device management protocols for configuration, fault and performance management and software/firmware upgrade. When a command is sent to an M2M gateway, the device range information in it can be converted into the specific commands supported by the target terminals or peripherals, so that a group of terminals or peripherals attached to the gateway (such as zigbee nodes) complete device management simultaneously or independently. The platform can also perform network management of peripherals (such as network topology) through the gateway.

The device management flow (Figure 7) is: 1) peripherals, terminals and gateways register with the platform, which obtains their management object information and builds the mappings to management object resource data and to protocol commands; 2) the platform receives an access request for management object resource data carrying the M2M application URI and the management object URI, and checks device management access rights according to the application URI and request type; 3) according to the preset mapping it converts the request into the corresponding command and determines the management object information for the accessed URI; 4) it establishes a device management session and sends the command to the relevant peripheral, terminal or gateway to operate on the management object information; 5) it receives the result, maps it to a resource access response and returns it to the M2M application.

12.3 Group management. Group management comprises group operations and group member operations. Group operations - create, retrieve, update and delete group - follow Figure 8: 1) the M2M service platform/gateway receives an operation request on the group resource from an M2M application or device; 2) it invokes the group management function for local processing; 3) it sends a response message to the application or device.

Batch access to group members (Figure 9) proceeds as follows: 1) according to the needs of the application or device user, the originator (M2M application or device) initiates an access request to members (create, query, update, delete) providing a URI parameter of the content of the members of an existing group, including the originator URI and group URI, so that the request is applied in batch to the members; 2) the group management function of the entity hosting the group receives, parses and processes the request: it checks the originator's rights on the group according to the originator URI and request type, validates the request parameters and continues processing; after successful validation it obtains the group information from the group URI, including the member list and all member URIs, and fans the request out to each member. Where a member URI indicates a sub-group, it may generate a request identifier sent with the member requests and stored by the member hosting entity, which then ignores later member requests carrying the same identifier. It may also, from the member URIs, identify members located on the same M2M gateway or terminal and create a sub-group for them, so that a single access request reaches the sub-group and thereby its members.

3) The group management function fans out the batch request to each member; 4) the group management function of the member hosting entity processes the request: it checks whether a request identifier is carried and compares it with locally stored identifiers, ignoring the request on a match, otherwise storing the identifier locally and continuing validation and processing; 5) the member hosting entity returns its response to the group service capability layer; 6) the group hosting entity aggregates all member responses into one response; 7) this response is returned to the originator.

Handling of failed batch member operations (Figure 10): 1) the originator sends an operation request on member resources to the group service capability layer (see step 1 of the member operation flow); 2) the layer fans it out to each member resource (steps 2 and 3); 3) member resources execute the operation and return responses indicating success or failure (steps 4, 5 and 6); 4) for failed responses, the layer generates and stores locally a member resource list recording the members whose execution failed and a record identifier of the operation request; 5) it sends the group member operation response to the originator (step 7); 6) the originator resends the request including the record identifier; 7) the layer, using the member resource list and record identifier, fans the resent request out only to the recorded members; 8) these members execute the operation and return success or failure; 9) the layer maintains the member resource attributes, including the member resource list and record identifier, according to the responses; 10) it returns the batch operation response to the originator.

12.4 Resource management. 12.4.1 General. Resource management implements data storage and forwarding, device management, group management and access control by managing the related resources, providing resource access request and response flows for creating, retrieving, updating and deleting resources. 12.4.2 Create resource. According to the needs of the application or device user, the originator issues a create command providing parameters such as the originator URI and the collection resource URI, received by the service capability layer. It first determines from the collection resource URI whether the target is local; if so it continues, otherwise it forwards the request to the relevant service capability layer and relays the response to the originator. It then checks the originator's create rights on the collection resource according to the originator URI and request type, validates the parameters and, after successful validation, creates the new resource in the collection and returns a response carrying the URI of the new resource.

12.4.3 Retrieve resource. The originator issues a query command with the originator URI and target resource URI. The service capability layer checks whether the target is local (otherwise forwarding the request and relaying the response), checks read rights on the target resource, continues processing and, after successful validation, returns the target resource in the response. Resource management shall support combined queries on attributes of resource objects. 12.4.4 Update resource. The originator issues an update command with the originator URI, target resource URI and new resource parameters; after the locality check, write-rights check and parameter validation, the resource is updated and a response returned. 12.4.5 Delete resource. The originator issues a delete command with the originator URI and target resource URI; after the locality check and delete-rights check, and successful validation, the resource is deleted and a response returned.

13 Interface technical requirements

13.1 Interface technical requirements between the M2M service platform and M2M applications. The interface between the platform and M2M applications shall be able to be provided by the service platform provider, or negotiated between the service platform provider and the service user. The interface requirements and implementation between the platform and M2M applications follow YD/T 2398-2012 and ETSI TS 102 690 V1.1.11; in addition the interface provides the following functions.

a) Common capability support: the platform shall provide M2M applications with common capabilities and support through unified open interfaces. After data processing achieved through collaborative service download to multiple terminals via the platform, and data processing of services offered directly to users, application services meeting individual user needs are provided through aggregation, reconstruction and dynamic adaptation according to the users' different service needs, so that applications can access and use network resources and capabilities such as terminal or device information, service information and radio resource information.

b) Event driven: the interface shall support an event-driven architecture so that M2M applications can respond promptly to massive numbers of events. Through the platform, multiple service requests from multiple user terminals are authenticated; authenticated requests are analysed and statistically processed to determine the services requested, where a request carries one or more of service type, service content, originating terminal type and user ID. The service data requested is then obtained from the relevant application servers - directly, based on the service context information stored in the application server, or from other terminals or servers and sent to the relevant application server - and the data for each terminal request is extracted and sent to the respective terminal. Batch processing of service requests achieves dynamic adaptation, improving response speed and user experience even when many terminals of many users issue requests simultaneously.

c) Service composition and adaptation: the interface shall support dynamic adaptation to users' different service needs. A user requests service transmission through a terminal group; user context, terminal context and service context information are obtained from the request message and a service adaptation policy is formulated and executed to complete collaborative adaptation. Using the user's service and terminal preferences, user context and the service context from the database server found by service ID, information on each sub-service is obtained and service composition information generated; from the terminal context (capability information), collaborating terminals able to present the service are selected from the group as service components and combined according to user context into service component set information, including the device IDs and capabilities of the collaborating terminals. A service deployment configuration file is generated from the composition and component set information, completing the policy. Executing the policy includes requesting each sub-service resource from each database server according to the sub-service ID and database server information, and splitting the policy and delivering it to the corresponding collaborating terminals.

13.2 Interface technical requirements between the M2M service platform and the M2M terminal service layer. The interface shall be able to be provided by the service platform provider, or negotiated between the provider and the service user. Its requirements and implementation follow YD/T 2398-2012 and ETSI TS 102 690 V1.1.11; in addition it provides the following functions. a) Heterogeneity shielding: the platform-terminal interface shall provide a direct access interface for terminals and gateways that shields the heterogeneity of terminal access modes. An interface device compatible with multiple terminals may be used, including radio frequency, data processing and short-range communication protocol modules and a custom protocol module that parses data of different formats from different terminals, encapsulates it into custom protocol packets, converts these into short-range communication protocol packets and sends them to sensor network node devices; or converts short-range protocol packets returned by sensor nodes into custom protocol packets, decapsulates them and converts the data into the format of the corresponding terminal before sending it.

b) Multi-stream concurrent transmission: in the M2M architecture multiple heterogeneous network terminals work together to fulfil user service needs, requiring the platform and terminals to cooperate on service offloading and transmission, so the interface shall also support multi-stream concurrent transmission. A user requests service transmission through a terminal group; user, terminal and service context information is obtained from the request and a service offloading policy formulated and executed to complete collaborative offloaded transmission. During transmission, when a flow switching condition is determined to be triggered from network and terminal context, the offloading and/or adaptation policy is updated according to the switching type and the transmission path of the sub-service flows is redirected to complete the switch.

In the multi-stream transmission, the request message shall contain at least the requesting user ID, the device ID and IP address of each collaborating terminal in the group, the port information used by each terminal for the service, and the requested service ID. Switching conditions include changes in the state of a specific terminal or in network availability of the terminal group, or environmental changes meeting the user's terminal preferences, with the user's predefined rules applying when triggered. Executing the offloading policy includes integrating sub-service resources into the requested service resource, dividing it into sub-service flows, assigning a flow ID to each and delivering each flow to the corresponding terminal over the interface link mapped to its flow ID.

In addition, to support multi-terminal service collaboration and offloaded service transmission, M2M terminal devices shall also support input and output of multiple service flows: service instructions received from multiple terminal interfaces are converted into a uniform format recognizable by the terminal, buffered and scheduled according to a preset policy. Priorities are set according to network load and/or the time the instruction needs the interface, and scheduling follows the preset priority order, and/or instructions are adapted to interfaces of the corresponding type. Where the service data of an instruction is stored locally on the terminal, that instruction has priority over other instructions; where none of the service data is stored locally, instructions from the terminal itself have priority over collaborative instructions from other terminals. Converted instructions are formatted for external communication through the interface and scheduled, achieving simultaneous input and output of multiple service flows.