Transcript ARC-2016-0438 - FTP

3GPP R13 Small Data Delivery
Group Name: ARC#25
Source: Catalina Mladin, InterDigital, [email protected]
Mike Starsinic, InterDigital, [email protected]
James Hu, AT&T, [email protected]
Meeting Date: 2016-10-17
Agenda Item: TBD
BACKGROUND
•
In the Rel-13 CIoT specification, the SCEF exposes the following capabilities:
1.
2.
3.
Configuring Communication Patterns
Configuring Session QoS
Configuring Session Sponsorship
•
4.
Background Data Transfer
•
5.
Configuring a Monitoring Event, Deleting a Monitoring Event, Receiving a Monitoring Report
Support for High Latency Communication
Mobile Core Network Issue Reports
•
8.
Requesting a Time Window, Identifying the Selected Time Window
Monitoring
•
6.
7.
Starting and stopping sponsorship at session start up and during the session
Requesting Reports, Receiving Reports, Stopping Reports
SMS Based Device Triggering
•
Requesting, Recalling, and Replacing
9. Group Messaging (via MBMS)
10. 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
AS / IN-AE
The IN-CSE may
alternatively be
placed in the
Mobile Core
Network.
UDP Wrapper or Tunnel
SCS / IN-CSE
Internet
API
P-GW
SCEF
MME
NIDD via
NIDD
SCEF, Control via P-GW,
Plane
Control Plane
New Control
Plane Options
S-GW
IP-Data
Delivery,
Control
Plane
Mobile
Core
Network
IP-Data
Delivery,
User Plane
Existing
(Pre-Rel-13)
User Plane Option
IP Data using
Control Plane C-IoT Optimizations
IP Data, via the P-GW
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.
NAS transport is used to
send IP packets.
Mobile Core Network
MME
Internet
S-GW
No S1-U connection to the
S-GW is needed.
P-GW
Data is sent between MME and S-GW and
between S-GW and P-GW via GTP-U
tunnels
AS /
MTC Server /
SCS
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.
1
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.
NAS transport is used to
send Non-IP packets.
Mobile Core Network
MME
Internet
P-GW
S-GW
0Provisioned 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
AS /
MTC Server /
SCS
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
0Provisioned 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.
3
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.
HSS
SCEF
MME
AS /
MTC Server /
SCS
Mobile Core Network
2
3
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.
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
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?
–
–
–
–
–
•
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?
–
•
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).
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 TS0026 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.
– Whether it supports sending data over the user plane.
– Whether it supports attaching without a PDN connection.
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.
UE
•
•
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.
MME/
C-SGN
HSS
SCEF
SCS/AS
SCS/AS decides to
configure NIDD
NIDD Config.
Req.
Authentication and
authorization
S6t: NIDD Info Req.
(ext-ID, supported
features, NIDD auth req)
3
S6t: NIDD Info Answ.
(result, UE-id, NIDD suth
resp, supported features)
4
1
2
New: NIDD Config.
Resp
5
0
NIDD via SCEF (T6a Establishment )
•
When UE establishes the PDN
connection (with PDN type of "NonIP“) 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
UE
MME
P-GW
HSS
SCS/AS
SCEF
NIDD Configuration
UE attach or
UE req PDN connectivity or
PDP context activation
(APN is assoc with an “Invoke SCEF
selection” ind and SCEF ID)
UE indicates “Non-IP PDN type”
0
1
T6a: Connection Management Request (User Identity, EBI, SCEF ID,
APN, APN Rate Control, PLMN , Nof PDN Connections, charging, etc)
2
Check user ID
Check valid NIDD config
Creates SCEF EPS
Bearer Context
Store MME info
T6a: Conn Management Answer
(Result, NIDD charging ID, etc.)
4
3
3GPP Standard References
•
TS 23.401 v.13.7.0 (2016-06) GPRS enhancements for E-UTRAN
–
–
–
–
–
–
•
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
–
–
•
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
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