1. Discussion oneM2M WG2 contributions to address Network Optimization Group Name: WG2 Source: Takanori Iwai, NEC, (t-iwai@hx.jp.nec.com)t-iwai@hx.jp.nec.com Tetsuo Inoue, NEC, (t-inoue@fp.jp.nec.com)t-inoue@fp.jp.nec.com Ataru Kobayashi, NEC, (a-kobayashi@df.jp.nec.com)a-kobayashi@df.jp.nec.com JaeSeung Song, NEC Lab Europe, (JaeSeung.Song@neclab.eu)JaeSeung.Song@neclab.eu Joerg Swetina, NEC Lab Europe, (Joerg.Swetina@neclab.eu)Joerg.Swetina@neclab.eu Meeting Date: 2013-10-14 Agenda Item: oneM2M-ARC-2013-0414-Network_Optimization_Discussion_Doc

2. Agenda Backgrounds – oneM2M Use Case, Requirements and LS (oneM2M  3GPP) Drafting Contributions – Overview – X Reference Point (AE  CSE: Request ) – Functions in Common Services Entity (CSE) – Z Reference Point (CSE  NSE: Request) – Sequence (or information flow) References – State of the art; M2M network optimization capability in 3GPP (SA1/SA2) Page 2

3. Backgrounds Looking back at oneM2M Use Case, Requirements and LS (oneM2M -- 3GPP) Page 3

4. Concept & Benefits This mechanism allows a M2M service provider to take advantage of network optimization capability of underlying communication networks. It can optimize connection and mobility managements in the communication network based on the characteristics of device for communication and mobility. This mechanism involves authentication, charging, detecting characteristics of device for communication and mobility by M2M service provider and notifying the characteristics to appropriate underlying network. Interworking between M2M service platform and underlying network is required. – Benefit; It could offer to reduce load and improve reliability of underlying network. Page 4

5. Use case (1) Optimized M2M interworking with mobile networks (Optimizing connectivity management parameters) This use case illustrates detection of a change of data transmission interval on service layer and notification to the mobile network by interworking between the M2M service platform and the mobile network. Page 5

6. Use case (2) Optimized M2M interworking with mobile networks (Optimizing mobility management parameters) This use case illustrates detection of a change of mobility characteristics on service layer (through the M2M Application) and notification (through the oneM2M Service Capabilities) to the mobile network by interworking between the M2M service platform and the mobile network. Page 6

7. Requirements Approved oneM2M-TS-Requirements-V-0.5.2 oneM2M Requirements Technical Specification – Requirements to be addressed Requirement IDDescriptionRelease OPR-005 The M2M System shall be able to exchange information with M2M Applications related to usage and traffic characteristics of M2M Devices or M2M Gateways by the M2M Application. This information includes the following features for a M2M Device: - Time controlled devices to send or receive data only during defined time intervals Note: “Low mobility” and “Time controlled” are equivalent to the MTC Features specified in [i.x] (section 7.2 of 3GPP TS 22.368) OPR-006Depending on availability of suitable interfaces provided by the Underlying Network the M2M System shall be able to provide information related to usage and traffic characteristics of M2M Devices or M2M Gateways to the Underlying Network. Page 7

8. Requirements Approved (Cont.) – The other relevant requirements Requirement IDDescriptionRelease OSR-006 The M2M System shall be able to reuse the services offered by underlying networks to M2M Applications and/or M2M Service Layer, by means of open access models (e.g. OMA, GSMA OneAPI framework). An example of available services is:  IP Multimedia communications  Messaging  Location  Charging and billing services  Device information and profiles  Configuration and management of devices  Triggering, monitoring of devices  Small data transmission  Group management The set of features or APIs to be supported depends on the M2M Service Capabilities and access to available APIs. Page 8

9. LS (OneM2M  3GPP) oneM2M-TP-2013-0307R01 LS on interfaces of oneM2M with Underlying Networks (Outgoing LS to 3GPP, Aug 2013) oneM2M considers it beneficial to establish an on-going collaborative exchange of information between oneM2M and 3GPP. Some of the features that oneM2M is working on that could require interworking with 3GPP Rel-12 and Rel-13 are listed below: 1.An M2M Service provider and a Network Operator may exchange information related to characteristics of M2M Devices or M2M Gateways, such as indications for small data, transmission scheduling parameters, mobility characteristics, etc.. Page 9

10. Drafting contributions, Overview Page 10

11. Points to be standardized; Network Optimize （ exchange information related to characteristics of M2M Devices ） In 3GPP, A mobile network will change parameters and process for specified device based on the information from service platform for transition of device’s behavior. Interfaces to be newly added or extended with additional parameters CSE – MTC-IWF  Tsp or new one MTC-IWF – MME/HSS  T5b, S6m Any other relevant interfaces Nodes to implement additional features MTC-IWF, MME, HSS, any other relevant nodes Overview The whole mechanism should be standardized which involves authentication, charging, detecting characteristics of device for communication and mobility by M2M service provider and notifying the characteristics to appropriate underlying network. Interworking between M2M service platform and underlying network is required.  Benefit; It could offer to reduce load and improve reliability of underlying network. In oneM2M, A M2M service platform will detect or receive transition of device’s behavior from apps and inform underlying network the information such as mobility or connectivity characteristics. Interfaces to be newly added or extended with additional parameters App – CSE  X reference point CSE – MTC-IWF  Z reference point Any other relevant interfaces Nodes to implement additional features NSE CSF and any other relevant CSFs or nodes MTC-IWF Mobile NW （ 3GPP ） Tsp I/F CSE Service PF （ oneM2M ） Applications HSS X Reference Point Z Reference Point MME T5b S6m Page 11

12. Points to be standardized in oneM2M Application Entity (AE) Application Entity (AE) Common Services Entity(CSE) ▐ Interface for AE to request to notify the usage and traffic characteristics of M2M devices (AE  CSE) Common request format (?) Dedicated request format for this functionality ▐ Functions to be implemented in CSE Functions to receive a request from an AE. Authenticate the originator (=AE) Validate and authorize the request (Optional) Charge the request Functions to send a request to NSEs Select appropriate NSEs (according to the request parameters and capability of NSEs) Transfer the request in the suitable form to the selected NSEs. (Optional) Accept the receipt from the NSE ▐ Interface for CSE to request to notify the usage and traffic characteristics of M2M devices (CSE  NSE ） Reference message flow and parameters (=data elements) sent/received through Z, though request formats depend on NSEs. Underlying Network Service Entity(NSE) Underlying Network Service Entity(NSE) Z Reference Point X Reference Point Common Service Functions （ CSFs) Common Service Functions （ CSFs) OPR-005 OPR-006 Page 12

13. Drafting contributions, X Reference Point （ A request from AE to CSE ） Page 13

14. Common request format (expected) Destination ID of CSE – ID defined by oneM2M (= CSE-ID? and/or M2M-Node-ID?) Source ID of AE – ID defined by oneM2M (= App-Inst-ID? and/or M2M-Node-ID?) Page 14

15. Dedicated request format for this functionality Mandatory items – Device ID Identifier of target device for transition of behavior (characteristics of device’s behavior). ex) IMSI or External ID of 3GPP. Optional items – Mobility characteristics Stop, Low Mobility, High Mobility Mobility area, Destination – Connectivity characteristics Average bandwidth of usage Average time of communication (or manipulation) Average interval between communications Schedule of communications Available delay time – Device power consumption information Remained power (percentage) Power saving mode, Power charging – Other options Booted application information Radio signal reception information Page 15

16. Drafting contributions, Functions in Common Services Entity (CSE) Page 16

17. List of functions Functions to receive a request from an AE – Authenticate the originator (=AE) – Validate and authorize the request (from technical and contractual aspects) – (Optional) Charge the request Functions to send a request to NSEs – Select appropriate NSEs (according to the request parameters and capability of NSEs) – Transfer the request in the suitable form to the selected NSEs. It may involve format conversion. – (Optional) Accept the receipt from the NSE (Optional) Charge the request and/or charge based on execution condition of NSE Page 17

18. Drafting contributions, Z Reference Point A request from CSE to NSE Page 18

19. Common request format Destination ID of NSE – ID defined and shared by oneM2M and 3GPP (?) Source ID of CSE – ID defined by oneM2M (= CSE-ID? and/or M2M-Node-ID?) Page 19

20. Dedicated request format for this functionality Mandatory items – Device ID Identifier of target device for transition of behavior (characteristics of device’s behavior). ex) IMSI or External ID of 3GPP. Optional items – Mobility characteristics Stop, Low Mobility, High Mobility Mobility area, Destination – Connectivity characteristics Average bandwidth of usage Average time of communication (or manipulation) Average interval between communications Schedule of communications Available delay time – Device power consumption information Remained power (percentage) Power saving mode, Power charging – Other options Booted application information Radio signal reception information Page 20

21. Drafting contributions Sequence (Message Flow) Page 21

22. Basic Sequence (request from AE to send data) CSE NSE AE Check the request Select appropriate NSEs Convert the format of the request Request to notify M2M device information Execute optimized processing Response Response (ACK) Page 22

23. References Page 23

24. State of the art; network processing optimization in 3GPP (SA1/SA2) Page 24

25. Service requirements for Machine-Type Communications (MTC); Stage 1 for Rel-12 (3GPP TS 22.368) 3GPP SA1 has defined the requirements below in TS 22.368 – 6 Categories of features for Machine-Type Communications Machine Type Communication (MTC) applications do not all have the same characteristics. This implies that not every system optimisation is suitable for every MTC application. Therefore, MTC Features are defined to provide structure for the different system optimisation possibilities that can be invoked. MTC Features provided to a particular subscriber are identified in the subscription. MTC Features can be individually activated. The following MTC Features have been defined: – Low Mobility – Time Controlled – Small Data Transmissions – Infrequent Mobile Terminated – MTC Monitoring – Secure Connection – Group Based MTC Features – Group Based Policing – Group Based Addressing Page 25

26. 3GPP SA1 has defined the requirements below in TS 22.368 – 7.2.1Low mobility The MTC Feature Low Mobility is intended for use with MTC Devices that do not move, move infrequently, or move only within a certain region. For the Low Mobility MTC Feature: – The network operator shall be able to change the frequency of mobility management procedures or simplify mobility management per MTC Device. – The network operator shall be able to define the frequency of location updates performed by the MTC Device. Service requirements for Machine-Type Communications (MTC); Stage 1 for Rel-12 (3GPP TS 22.368) Page 26

27. 3GPP SA1 has defined the requirements below in TS 22.368 – 7.2.2Time controlled The MTC Feature Time Controlled is intended for use with MTC Applications that can tolerate to send or receive data only during defined time intervals and avoid unnecessary signalling outside these defined time intervals. The network operator may allow such MTC Applications to send/receive data and signalling outside of these defined time intervals but charge differently for such traffic. Page 27 Service requirements for Machine-Type Communications (MTC); Stage 1 for Rel-12 (3GPP TS 22.368)

28. 3GPP SA1 has defined the requirements below in TS 22.368 – 7.2.5Small data transmissions The MTC Feature Small Data Transmissions is intended for use with MTC Devices that send or receive small amounts of data. For the Small Data Transmissions MTC Feature: – -The system shall support transmissions of small amounts of data with minimal network impact (e.g. signalling overhead, network resources, delay for reallocation). – -Before transmission of small amount of data, the MTC Device may be attached or detached to/from the network. Note:“Transmission” implies either sending or receiving small amount of data. – -The 3GPP system shall be able to count the number of small data transmissions per subscription e.g. for charging or statistical purposes. Note 1: observed size of many of the instances of data exchanges is on the order of 1K (1024) octets Note 2: Charging and accounting of small data transmissions between operators can be done on a bulk basis. Service requirements for Machine-Type Communications (MTC); Stage 1 for Rel-12 (3GPP TS 22.368) Page 28

29. New Work Item for Rel-13 agreed on SA1: WID for Service Exposure and Enablement Support (SEES) 3GPP SA1 has agreed new WID for Service Exposure and Enablement Support (SEES) 3Justification * – This work item allows 3 rd parties to interact with the 3GPP System to use 3GPP functions to provide 3 rd party services to their customers. Since M2M services and other Application services often have the same or similar requirements on the 3GPP System these are addressed jointly in this work item. – The following service scenarios are considered in this work item: – M2M services: Standardization work related to M2M service enablement is on-going in standardization organisations outside 3GPP (e.g. ETSI TC M2M and the oneM2M Global Initiative). These SDOs work under the assumption that M2M service enablement can be offered by a network operator but can also be provided by third parties that have business agreements with operators. In addition, these SDOs want to use 3GPP capabilities beyond pure IP based data transmission that can be offered by 3GPP networks. On the other hand, 3GPP architecture work on MTC has started in Rel-10 and in Rel-12 SA2 is working on Small Data Transmissions and Low Power Consumption UEs. Some information (e.g. on transmission scheduling or indications for small data, device triggering...) may need to be provided by M2M service enablement. In Rel-11, 3GPP defined an interface (Tsp) between the 3GPP Core Network and M2M service enablement platforms.. Additionally, 3GPP has defined other interfaces (Le, Rx, Mo, Mf, and Mh) between the 3GPP Core Network and application platforms; these interfaces may also be used by M2M service enablement platforms. This work item extends the scope for this interworking. Explain in sufficient detail why this work is needed. Page 29

30. New Work Item for Rel-13 agreed on SA1: WID for Service Exposure and Enablement Support (SEES) 3GPP SA1 has agreed new WID for Service Exposure and Enablement Support (SEES) 4Objective * – Stage 1 objectives: – Study and specify service requirements for the support of exposing selected 3GPP functions to – M2M service enablement layers (e.g. ETSI TC M2M and oneM2M). Use cases of oneM2M are contained in oneM2M TR 0001- oneM2M Use Case collection. Functions that may require such interworking have been identified by oneM2M should e.g. allow for: An M2M Service provider may request QoS and Prioritization for M2M communications to/from individual devices or groups of devices. A device may request QoS and Prioritization for M2M communications to/from the M2M Service Provider. – Note: For M2M communications initiated by the device QoS may be covered by existing call setup procedures. An M2M Service provider and a Network Operator may exchange information related to individual M2M Devices or Gateways, such as transmission scheduling or indications for small data, device triggering, etc. A Network Operator may request the M2M Service Provider to schedule traffic via the Operator Network (e.g. to delay specific M2M traffic when the 3GPP Network experiences high traffic load). Provide mechanisms to correlate the oneM2M Service Enablement Framework identifier of M2M Devices with the External Identifier used by the 3GPP network for the same MTC client. Upon request by the one M2M Service enablement Framework provide the oneM2M Service Enablement Framework with information regarding whether a M2M Device is authorized to access the 3GPP Operator Network. An M2M Service provider and a Network Operator may need to exchange information on charging and subscriptions to support interworking with M2M Service providers. Provide 3GPP security capabilities such as GBA for the benefit of oneM2M Services and Applications. Conversely provide mechanisms to leverage oneM2M security capabilities for the benefit of the 3GPP Operator Network security. An M2M Service provider and a Network Operator may exchange information related to location information of M2M Devices or M2M Gateways. – In order to avoid overlapping specifications, close cooperation with ETSI TC M2M and oneM2M is envisaged. Page 30

31. Analysis and proposal to 3GPP MTC for Rel-13 Page 31

32. Analysis and proposal to 3GPP MTC for Rel-13 Analysis on existing 3GPP MTC features – Currently, device characteristics such as Low Mobility, Time Controlled, Small Data Transmissions would be decided based on device subscription information which is statically provisioned on HSS or some other entities related to device subscription database. Future market expectation – It is expected increasing devices which might change its characteristic automatically depends on situations. – Examples of changing the characteristic are, stationary(low mobility) or mobile(High mobility) long interval or short interval permit delay or forbid delay Existing Key Issue – Dynamically change of device characteristics function is needed. ▐ Proposed features – To provide MTC features based on device characteristics which are dynamically changing Mechanism of detection and notification for transition of device characteristics Mechanism of selection for MTC features to be used based on transition of device characteristics Page 32

33. Low Mobility – The MTC Feature Low Mobility is intended for use with MTC Devices that do not move, move infrequently, or move only within a certain region. (Reference TS 22.238 7.2.1) – It can be used for “Smart meter”. But it can not be used for “Car / Cargo”. – Because “Car / Cargo” usually move any region, and sometime “ Car” at home, “Cargo” in freight distribution center. Example of Static versus Dynamic of Mobility characteristic Network Parking or Moving Always stopping Provide Low Mobility Static Dynamic Detect device behavior And Provide Mobility characteristic Page 33