3GPP R13 Small Data Delivery Group Name: ARC#25 Source: Catalina Mladin, InterDigital, Catalina.Mladin@InterDigital.com Mike Starsinic, InterDigital, Michael.Starsinic@InterDigital.com James Hu, AT&T, James.Hu@att.com Meeting Date: 2016-10-17 Agenda Item: TBD

BACKGROUND In the Rel-13 CIoT specification, the SCEF exposes the following capabilities: Configuring Communication Patterns Configuring Session QoS Configuring Session Sponsorship Starting and stopping sponsorship at session start up and during the session Background Data Transfer Requesting a Time Window, Identifying the Selected Time Window Monitoring Configuring a Monitoring Event, Deleting a Monitoring Event, Receiving a Monitoring Report Support for High Latency Communication Mobile Core Network Issue Reports Requesting Reports, Receiving Reports, Stopping Reports SMS Based Device Triggering Requesting, Recalling, and Replacing Group Messaging (via MBMS) Control Plane Data Delivery ARC-2015-2270 discusses items 1-9 Thus far, only item #1, Communication Patterns, is supported in the oneM2M specifications. This presentation focuses on item #10, Control Plane Data Delivery.

BACKGROUND In Rel-13 CIoT specification, 3GPP added the ability to send data over the control plane. Control Plane (CP) CIoT Optimizations refer to sending user data via the control plane (MME/SGSN) in a NAS message, thus reducing the total number of CP messages required for Small Data Delivery. 3 Types of “Control Plane” data are supported: IP Data, terminated at the P-GW Non-IP Data, terminated at the P-GW Non-IP Data, terminated at the SCEF The purpose of this presentation is to give an overview of how these 3 data delivery methods are used so that oneM2M can consider how they might be applied.

BACKGROUND

IP Data using Control Plane C-IoT Optimizations

NAS transport is used to send IP packets. IP Data, via the P-GW NAS transport is used to send IP packets. Since the IP data is being sent via NAS, it is transparent to the eNodeB. Header compression of MT data must be done in the MME instead of the eNodeB. Mobile Core Network Internet MME AS / MTC Server / SCS S-GW P-GW No S1-U connection to the S-GW is needed. Data is sent between MME and S-GW and between S-GW and P-GW via GTP-U tunnels

How is this feature used? When the UE attaches or requests a PDN connection: The UE indicates that it wants a PDN Connection of type IP (IPv4 or IPv6 or IPv4/6) The UE indicates if it supports header Compression When the UE AE/CSE establishes a connection, it needs to decide if it wants to use the control plane or user plane. This indication is carried in the Attach or PDN connection request. Note: IP Packets are delivered to the UE via NAS signaling IN-CSE/SCS is not aware if the IP packets are delivered via User or Control Plane

Non-IP Data Delivery (NIDD) via the P-GW

Non-IP Data Delivery via the P-GW 3 3 MO Data. The P-GW maps the UE ID and APN to Source and Destination (IP Address/ Port Number). This mapping is provisioned. Non-IP Data is wrapped in a UDP packet by the P-GW and sent to the IP Address and Port Number. MT Data. In order to get the Non-IP data to the P-GW, the AS needs IP Address and Port Number associated with the UE. How the AS knows this is out of scope in 3GPP. Possibilities: Use IP Address & Port that was used as the source address by the P-GW in previous MO Data or use a provisioned IP Address & Port. Non-IP Data is wrapped in UDP packet and sent to the IP Address and Port Number. 1 NAS transport is used to send Non-IP packets. Mobile Core Network Internet MME AS / MTC Server / SCS S-GW P-GW Provisioned with an APN., which is associated with an AS. A PDN connection is established with the APN. Non-IP Packets will be sent to the SCS/AS. No S1-U connection to the S-GW is needed. 2

How is this feature used? Before the UE is turned on: The UE’s subscription is provisioned with an APN that may be used for sending non-IP data to an AS via the P-GW. The APN Configuration (in the HSS) indicates if Non-IP Data is sent via the SCEF or P-GW. P-GW is provisioned with a source and destination IP Address & Port number to associated with the UE’s PDN Connection to the APN. The source/destination addresses are used to send/receive the non-IP data to the IN-CSE/SCS. When then UE attaches or requests a PDN connection: The UE indicates that it wants a PDN Connection of type non-IP The network uses the APN that UE provides or, if the UE provided no APN, the UE’s default non-IP APN The UE’s subscription (in the HSS) can have one default APN of type IP and one default APN of type non-IP. The network uses the APN configuration to determine if the non-IP data goes to the P-GW or SCEF. (P-GW in this example) P-GW send the max packet size to the UE The max size is sent via the MME in ESM NAS messaging. It may be as small as 128 bytes. Non-IP Packets are send via NAS messaging

Non-IP Data Delivery (NIDD) via the SCEF

NIDD via the SCEF 3 1 Mobile Core Network HSS MME SCEF 2 3 AS / MO Data. UE sends the non-IP data to the MME. MME uses (IMSI, EBI) to identify PDN connection to SCEF. SCEF maps IMSI and EBI to external ID, SCS, and APN. The data, external ID, and APN are sent to the SCS. 1 AS initiates NIDD configuration The SCEF checks that the AS is allowed to do NIDD with the UE. The SCEF is Configured with the IMSI-External ID Mapping. The SCEF learns what APN is associated with the AS-UE connection. Provisioned with an APN., which is associated with an AS. A PDN connection is established with the APN. Non-IP Packets will be sent to the AS. Mobile Core Network HSS AS / MTC Server / SCS MME SCEF 2 MT Data: AS has a Non-IP packet to sent to the UE. AS sends the non-IP Data and the External ID to the SCEF. SCEF uses SCS/AS ID and UE ID to identify PDN connection SCEF sends the IMSI, EBI, and non-IP data to the MME MME forwards non-IP data to the UE Connection Establishment (When PDN Connection is Established) The MME tells the SCEF that PDN connection is Established. The MME provides an IMSI, APN, and EBI The SCEF now knows what MME the UE is attached to. 3

How is this feature used? Before the UE is turned on: The UE’s subscription is provisioned with an APN that may be used for sending non-IP data to an IN-CSE/SCS via the SCEF. The APN Configuration (in the HSS) indicates if Non-IP Data is sent via the SCEF or P-GW. SCEF-ID is also part of the APN configuration. When then UE attaches or requests a PDN connection: The UE indicates that it wants a PDN Connection of type non-IP The network uses the APN that UE provides or, if the UE provided no APN, the UE’s default non-IP APN The UE’s subscription (in the HSS) can have one default APN of type IP and one default APN of type non-IP. The network uses the APN configuration to determine if the non-IP data goes to the P-GW or SCEF. (SCEF in this example) SCEF send the max packet size to the UE (via the MME in ESM NAS messaging, may be as small as 128 bytes) Non-IP Packets are send via NAS

Points to Consider

Points to Consider (1) NIDD (SCEF and P-GW options): Non-IP data is opaque to the 3GPP Network Guaranteed delivery needs to be done by higher layers When data gets to the IN-CSE or UE hosted AE/CSE, what happens? It needs to be segmented or re-segmented. A max packet size will be signalled from the network (may be as low as 128 Bytes). Larger packets will need to be segmented accordingly. The UE hosted application (AE/CSE) and IN-CSE/SCS need to handle segmentation (or never go over 128 Bytes). The SCEF may handle segmentation instead of IN-CSE/SCS. If the IN-CSE/SCS is handling segmentation, the SCEF needs to tell the IN-CSE/SCS the maximum packet size (or the maximum packet size needs to be provisioned). How is non-IP data transported to the SCEF? OMA API’s, Custom API’s, etc..? How is non-IP data transported to the P-GW? Wrapped in a UDP packet or via a tunneling protocol. Dedicated bearers are not supported for Non-IP data PDN connections and there is no concept of Port ID. If one UE hosted application (AE/CSE) uses NIDD to talk to more than one IN-CSE/SCS, then the UE needs to be provisioned with an APN for each IN-CSE/SCS. Separate PDN connections must be used for each IN-CSE/SCS. If more than one UE hosted application (AE/CSE) uses NIDD, then each UE hosted application (AE/CSE) needs to be provisioned with its own APN and to establish its own PDN connection.

Points to Consider (2) NIDD via (SCEF Option): The NIDD Configuration procedure at the SCEF is optional; the SCEF could be configured to know that the IN-CSE/SCS is allowed to do NIDD with the UE, configured with the IMSI-External ID Mapping, and configured to know what APN is associated with the SCS/AS-UE connection. IP-Data using C-IoT CP Optimisations: When a UE hosted application (AE/CSE) is sending IP Data, the UE needs to decide if the application behaviour is better suited for control plane or data plane delivery. There may be no impact on oneM2M to implement this feature (?) IN-CSE/SCS is not aware if the IP packets are delivered via User or Control Plane For all C-IoT CP Optimizations: In oneM2M terms, this feature can be used by any of the following, when hosted on UEs: ADN-AE, MN-CSE, or ASN-CSE.

Points to Consider (3) oneM2M shold use Non-IP data to send & receive regular messages. If so, how do we deal with segmentation (messages larger than the max packet size) oneM2M should use Non-IP messaging for triggers. To be able to receive NIDD trigger so they can then establish IP connection If the UE is in a deep sleep (i.e. due to eDRX or PSM), the SCEF may buffer MT data. What considerations are needed from a oneM2M perspective, to account for the fact that the SCEF may buffer MT non-IP data for a long time?

Next Steps Treat ARC-2016-0439 for sec 5 and 6.1 of TS-0026 and achieve agreement on: High-level architecture Small data delivery description and flows

Back-Up

CP CIoT Optimizations - Deployments For NB-IoT: The Network is required to support sending data over the control plane. UEs are required to support sending data over the control plane. UEs may support sending data over the user plane, but are not required to support it. Deployment Option: May have a massive deployment of UEs that only send data over the control plane and connect to a network that supports data only over the control plane. This network would have no S1-U connection from the S-GW to the UE. For WB: A WB-E-UTRAN Network may support sending data over the control plane, and will broadcast whether or not it is supported A WB-UE may support sending data over the control plane.

CP CIoT Optimizations - IEs At attachment or TAU (MME change), the UE and MME exchange information. The “Preferred Network Behaviour” information element is used by the UE to indicate: Whether it supports sending data over the control plane. Note: UEs supporting NB-IoT shall always indicate support for CP CIoT EPS optimisation. Whether it supports sending data over the user plane. Whether it supports IP header compression when sending IP data over the control plane. Whether it supports attaching without a PDN connection. Note: As of Rel-13 LTE UEs may be attached and not have a PDN connection, so they might be attached and not have an IP address. The “Supported Network Behaviour” information element is used by the MME to indicate: Whether it supports sending data over the control plane. Whether it supports header compression when sending IP data over the control plane.

Configuration for NIDD via SCEF There is an optional NIDD Configuration procedure the SCS may execute.  This procedure is used to allow SCEF to: Know the IMSI-External ID mapping . Check that the SCS is authorized to send Non-IP Data to/from the UE. Learn the APN that is associated with the SCS. The NIDD Configuration procedure is optional because the SCS can be provisioned with this information. Otherwise, it is performed by the SCS/AS prior to the UE's attachment to the network and may include MT data as well. The SCS/AS is expected to be configured to use the same SCEF as the one selected by the MME/SGSN during the UE's attachment to the network.

NIDD via SCEF (T6a Establishment ) When UE establishes the PDN connection (with PDN type of "Non-IP“) the SCEF signals the max packet size to the UE (in ESM NAS messaging, may be as small as 128 bytes) MME maps the APN to an SCEF. The APN used for SCEF based delivery is an FQDN, which either resolves to an SCEF hostname or to an SCEF IP address. MME initiates a “SCEF Connection” (T6a/T6b) and allocates EPS Bearer Identity (EBI). MME informs SCEF about the new connection with the UE and provides SCEF with: UE ID, EBI, APN Note: SMS service is always supported for CIoT EPS optimisations, i.e. can be used simultaneously with Non-IP and IP data

3GPP Standard References TS 23.401 v.13.7.0 (2016-06) GPRS enhancements for E-UTRAN 4.3.3.2 Section about the header compression 4.3.5.10 Section that describes the “Preferred Network Behaviour” and “Supported Network Behaviour” information elements 4.10 Section on User Plane and Control Plane CIoT Optimizations 4.11 Section on CIoT User Plane Optimizations 4.3.17 Support for NIDD 4.7.7 Support of rate control of user data using CIoT EPS optimisation TS 23.682 v.13.6.0 (2016-06) Enhancements for communications to PDN and applications 4.5.14 Section about NIDD 5.3.2 SCEF EPS Bearer context 5.13 NIDD Procedures TS 29.128 v.13.1.0(2016-06) MME-and-SGSN interfaces for interworking with PDNs 5.5-5.6 MO, MT Data 5.7-5.8 Connection Management TS 29.336 v.13.4.0 (2016-06) HSS diameter interfaces S6m/S6n/S6t for interworking with PDNs and application 6.2.3-6.2.4 Subscriber Info 8.2 commands