Scoping NIDD

Scoping NIDD
1. TS 23.401
1.1. E-UTRAN Initial Attach

If the received PDN type is IPv4 or IPv6 or "Non IP", the PDN GW uses the received PDN type if it is
supported in the PDN, otherwise an appropriate error cause will be returned.
If the PDN GW has selected a PDN type different from the received PDN Type, the PDN GW indicates
together with the PDN type IE a reason cause to the UE why the PDN type has been modified, as
described in clause 5.3.1.1. The PDN GW shall either accept or reject (but not modify) the PDN type if
the PDN type is set to "Non IP". PDN Address may contain an IPv4 address for IPv4 and/or an IPv6 prefix
and an Interface Identifier, or be omitted for PDN type "Non IP".
If the PDN type is set to "Non-IP" the MME includes it in the S1-AP Initial Context Setup Request so that
the eNodeB disables header compression. In addition, if the PDN connection is established for Local IP
Access, the corresponding S1 Initial Context Setup Request message includes a Correlation ID for
enabling the direct user plane path between the HeNB and the L-GW
If the MME or PDN GW has changed the PDN Type, an appropriate reason cause shall be returned to the UE as
described in clause 5.3.1.1. If the UE has indicated PDN type "Non-IP", the MME and PDN GW shall not
change PDN type.
PDN type indicates the requested IP version (IPv4, IPv4/IPv6, IPv6). For a UE that support CIoT EPS
optimisations, the PDN type may also be "Non-IP " Protocol Configuration Options (PCO) are used
to transfer parameters between the UE and the PDN GW, and are sent transparently through the
MME and the Serving GW. The Protocol Configuration Options may include the Address Allocation
Preference indicating that the UE prefers to obtain an IPv4 address only after the default bearer
activation by means of DHCPv4. If the UE intends to send PCO which require ciphering (e.g.,
PAP/CHAP usernames and passwords) or send an APN, or both, the UE shall set the Ciphered
Options Transfer Flag and send PCO or APN or both only after authentication and NAS security
setup have been completed (see below).
For PDN type "non-IP" when Control plane CIoT EPS optimisations are enabled for the UE, if APN subscription
data indicate a SCEF connection needs to be used, then the MME allocates an EPS Bearer Identity for the
Default Bearer associated with the UE and establishes a connection to the SCEF address indicated in
subscription data as per TS 23.682 [74] and the steps 12,13,14,15,16 are not executed. The rest of the
interactions with the UE apply as specified below.
If the MME determines the PDN connection shall only use the Control Plane CIoT EPS Optimisation, the
MME shall include a Control Plane Only PDN Connection Indicator in Create Session Request.
1
1.2. Tracking Area Update Procedure
With SGW change
If the UE has PDN connection of PDN Type "non-IP", UE shall indicate EPS bearer status included in the TAU
Request message.
Based on the CIoT EPS Optimization support indication, old MME only transfers the EPS Bearer Context(s) that
the new MME supports. If the new MME does not support CIoT EPS Optimization, EPS Bearer Context(s)
of non-IP PDN connection are not transferred to the new MME. If the EPS Bearer Context(s) of a PDN
connection has not been transferred, the old MME shall consider all bearers of that PDN connection as failed
and release that PDN connection by triggering the MME requested PDN disconnection procedure specified in
clause 5.10.3. The buffered data in the old MME is discarded after receipt of Context Acknowledgement.
Without SGW change

If the UE has PDN connection of PDN Type "non-IP", UE shall indicate EPS bearer status included in the TAU
Request message.
Based on the CIoT EPS Optimization support indication, old MME only transfers the EPS Bearer Context(s) that
the new MME supports. If the new MME does not support CIoT EPS Optimization, EPS Bearer Context(s)
of non-IP PDN connection are not transferred to the new MME. If the EPS Bearer Context(s) of a PDN
connection has not been transferred, the old MME shall consider all bearers of that PDN connection as failed
and release that PDN connection by triggering the MME requested PDN disconnection procedure specified in
clause 5.10.3. The buffered data in the old MME is discarded after receipt of Context Acknowledgement.
1.3. Data Transport in Control Plane CIoT EPS optimization
If the UE and MME use the Control Plane CIoT EPS Optimisation, they can transfer data in NAS PDUs
including the EPS Bearer Identity of the PDN connection they relate to, for which there is no S1-U
bearers established (i.e. when an S1-U bearer is established the UE shall use S1-U to transfer data PDUs).
Both the IP and Non IP data types are supported. If the UE and the MME accept to use Control Plane
CIoT EPS Optimisation, then to enable SMS transfer the Service Request procedures defined in
clause 5.3.4 are not used for MO and MT SMS, but instead UE and MME shall be using Control Plane
CIoT EPS Optimisation.
This is accomplished by using the NAS transport capabilities of RRC and S1-AP protocols and the data
transport of GTP-u tunnels between MME and S-GW and between S-GW and P-GW, or if a Non-IP
connection is provided by via the MME with the SCEF, then data transfer occurs as indicated in
TS 23.682 [74].
1.4. Handover S1 based

As specified in clause 4.3.8.3, with regard to CIoT EPS Optimisations, the source MME attempts to
perform handover to a target MME that can support the UE's Preferred Network Behaviour. For a UE that
is using a Non-IP connection to a PDN Gateway, or a PDN connection to a SCEF, if these bearers cannot
be supported by the target MME, the source MME does not attempt to handover those bearers, but
instead releases them upon successful completion of the handover. If the MME does not have any bearer
for the UE that can be transferred, then the MME sends an S1-AP Handover Preparation Failure message
to the source eNB.
2
Information storage
HSS
There may be at most two default APNs for a given user. One default APN can belong to either of the
three PDN types of "IPv4", "IPv6", or "IPv4v6", and another default APN can belong to PDN
type of "Non-IP".
1.5. Throttling of NIDD Submit Requests

Under unusual circumstances (e.g. when the MME load exceeds an operator configured threshold), the
MME may restrict NIDD Submit Request messages that its SCEFs are generating on it, if configured to do
so.
1.5.1. Support for Non-IP Data Delivery (NIDD)

4.3.17.8.1 General
The support of Non-IP data is part of the CIoT EPS optimisations. A PDN Type "Non-IP" is used for Non-IP
data. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:
- Delivery using SCEF as defined in clause 4.3.17.8.3.2.
- Delivery using a Point-to-Point (PtP) SGi tunnel as defined in clause 4.3.17.8.3.3.
Non-IP data in-sequence delivery cannot be guaranteed and data PDUs may be lost requiring higher
protocol layers to ensure guaranteed delivery when needed.
The SMS service may also be used to deliver data without use of the IP protocol. The SMS service is
always supported for CIoT EPS optimisations, i.e. can be used simultaneously with Non-IP and IP data.
When only the SMS service is needed, an attach without PDN connection establishment can be used, see
clause 5.3.2.
Dedicated bearers are not supported for the Non-IP data.
4.3.17.8.2 ESM Procedures

The UE indicates in the ESM connection request, e.g. in Attach or PDN Connectivity Request, that a Non-
IP PDN type shall be used. The subscription information has a default APN for PDN Type Non-IP, which
the MME uses for the first received Non-IP connectivity request unless the UE has included an APN in
the request.
4.3.17.8.3 Delivery mechanism

4.3.17.8.3.1 General
At each PDN connectivity request, the MME decides which delivery mechanism (SCEF based delivery or
SGi based delivery) is used for delivering the Non-IP data between RAN and AS. An indication associated
with the used APN determines if SCEF based delivery or SGi based delivery shall be used.
4.3.17.8.3.2 SCEF based delivery
When the MME decides to use SCEF based delivery mechanism for Non-IP data, a PDN connection is
established towards the selected SCEF. Such a PDN Connection is also known as an "SCEF Connection".
3
The APN used for SCEF based delivery is an FQDN, which either resolves to an SCEF hostname or to an
SCEF IP addresss.
The SCEF based delivery is applicable to the Control Plane CIoT EPS Optimization (see clause 4.1).
The support of Non-IP data via the SCEF is further defined in TS 23.682 [74].
4.3.17.8.3.3 SGi based delivery
4.3.17.8.3.3.1 General
When support of Non-IP data is provided at the SGi interface, different point-to-point tunneling
techniques may be used. Point-to-point tunneling by UDP/IP encapsulation can be used as described in
clause 4.3.17.8.3.3.2 below. Other techniques as described in clause 4.3.17.8.3.3 below may be used.
Support for the SGi based delivery of Non-IP data can be used by any UE. That is, it is independent of
support for the User Plane CIoT EPS Optimization and the Control Plane CIoT EPS Optimization (see
clause 4.1).
The P-GW decides at PDN connection establishment based on pre-configuration which point-to-point
tunneling technique is used for the SGi based delivery between the P-GW and the AS.
NOTE: The pre-configuration can be done in the P-GW per APN or based on other criterion such as
SLA between operator and 3rd party application service provider, etc.
4.3.17.8.3.3.2 SGi PtP tunnelling based on UDP/IP
SGi PtP tunnelling based on UDP/IP may be used to deliver Non-IP data to AS via SGi.
A point-to-point tunnel is used by the P-GW towards the AS. The tunnel parameters (i.e. destination IP
address and UDP port) for SGi PtP tunneling based on UDP/IP are pre-configured on the P-GW. IP address
allocation procedures for PDN connections are performed locally (e.g. without involving the UE) by the P-
GW based on APN configuration and according to clause 5.3.1. Only single IP address is used (i.e. both
IPv4 and IPv6 addresses are not allocated).
The P-GW acts as a transparent forwarding node for the payload between the UE and the AS.
For uplink Non-IP data, the P-GW forwards the received data to the AS over the SGi PtP tunnel using
UDP/IP encapsulation.
For downlink Non-IP data, the AS sends the data using UDP/IP encapsulation with the IP address of the
UE and the 3GPP defined UDP port for "Non-IP" data. The P-GW decapsulates the received data (i.e.
removes the UDP/IP headers) and forwards the data to S-GW on the GTP-U tunnel identified by the IP
address of the UE (i.e. PDN connection) for delivery to the UE.
The P-GW performs the IP related operations (e.g. allocates IP address for the PDN connection), but the
IP address or IP prefix is not provided to the UE (i.e. SLAAC / Router Advertisements are not performed.
DHCP or DHCPv6 are not used). In case of IPv6 the P-GW assigns an Interface Identifier for the PDN
connection. The allocated IP address or IPv6 prefix identifies the PDN connection of the UE. The P-GW
may inform the MME of the assigned IPv6 prefix for a given UE. However, the UE is not informed about
the assigned IPv6 prefix.
4
NOTE 1: Whether the P-GW informs S-GW/MME of the assigned IP v6 prefix or not is left to stage 3
decision.
NOTE 2: It is recommended to use IPv6 for CIoT. IPv4 based addressing is deprecated for machine
type communication used over 3GPP accesses, see TS 23.221 [27].
4.3.17.8.3.3.3 Other SGi PtP tunnelling mechanisms
SGi PtP tunnelling mechanisms such as PMIPv6/GRE, L2TP, GTP-C/U, etc, may be used to deliver Non-IP
data to AS via SGi. The general handling of such delivery mechanisms is as described below.
A point-to-point tunnel is established by the P-GW towards the AS. Depending on the type of protocol
employed on the SGi PtP tunnel, the SGi PtP tunnel setup may be done at the time of Attach or at the
time of first MO datagram being sent by the CIoT UE. The P-GW selects the AS based on the P-GW
configuration (eg. per APN, or per PtP tunnel type etc). However, IP address allocation procedures for the
UE (according to clause 5.3.1) are not performed by the P-GW.
NOTE: An AS can be dedicated for handling a specific Non-IP data protocol.
The P-GW acts as a transparent forwarding node between the UE and the AS.
For uplink Non-IP data, the P-GW forwards the received data to the AS over the established SGi PtP
tunnel.
For downlink Non-IP data, the AS locates the right SGi PtP tunnel for the UE (using information such as
UE identifiers in the Non-IP protocol itself, etc) to forward the data. The AS sends the data to P-GW over
the established SGi PtP tunnel .The P-GW inturn sends the data to S-GW on the GTP-U tunnel identified
by the associated SGi PtP tunnel for delivery to the UE.
1.6. 4.3.5.10Preferred and Supported Network Behaviour
Other CIoT EPS optimisations include "Attach without PDN connection establishment"; "PDN type = non-
IP"; and "UE connection to SCEF". These features are requested by implicit and explicit signalling
described within the relevant clauses of this TS.
4.3.8.1 PDN GW selection function (3GPP accesses)

The PDN GW selection function allocates a PDN GW that shall provide the PDN connectivity for the 3GPP
access. The function uses subscriber information provided by the HSS and possibly additional criteria
such as SIPTO/LIPA support per APN configured in the SGSN/MME, CIoT EPS optimisation(s) impacting
PDN GW e.g. Non-IP support, NB-IoT RAT support (for generation of accounting information), etc.
5
1.7. 5.3.1 IP address allocation
5.3.1.1 General
The procedures of clause 5.3.1 apply to UEs activating a PDN connection of PDN Type IPv4, IPv6 or
IPv4v6. Part of it also applies for PDN Type Non-IP when SGi PtP Tunnelling based on UDP/IP, see
clause 4.3.17.8, is used.
5.10 Multiple-PDN support and PDN activation for UEs supporting "Attach
without PDN connectivity"
5.10.1General
The EPS shall support simultaneous exchange of IP traffic to multiple PDNs through the use of separate
PDN GWs or single PDN GW. If C-IoT optimisations are supported, then also "Non-IP" data is supported
and PDN connections may also be served by an SCEF or multiple SCEF connected to MMEs (see
TS 23.682 [74]). The usage of multiple PDNs is controlled by network policies and defined in the user
subscription, which includes information as to whether a PDN connection is served by a SCEF or a P-GW.
For C-IoT EPS optimisation, the "Non-IP" PDN Type PDN connections may be configured by the MME to
just use the Control Plane. For IP PDN type connections used with C-Plane Optimisations, this procedure
configures Header compression in the MME and the UE.
The EPS shall support UE-initiated connectivity establishment in order to allow multiple PDN connections
to one or more PDNs. It shall be possible for a UE to initiate disconnection from any PDN.
All simultaneous active PDN connections of a UE that are associated with the same APN shall be
provided by the same P-GW.
UE support for multiple PDN connections is optional.
1.8. 5.10.2 UE requested PDN connectivity

1. (PDN Connectivity Request) The UE initiates the UE Requested PDN procedure by the transmission of a
PDN Connectivity Request (APN, PDN Type, Protocol Configuration Options, Request Type, Header
Compression Configuration) message. If the UE was in ECM-IDLE mode, this NAS message is preceded by
the Service Request procedure if any of the exiting PDN connections were using the User Plane without EPS
C-IoT optimisation, or, if the user plane was used just with User plane C-IoT optimisations, a Connection
Resume Procedure is executed instead. PDN type indicates the requested IP version (IPv4, IPv4v6, IPv6,
Non-IP). The MME verifies that the APN provided by UE is allowed by subscription. If the UE did not
provide an APN, the MME shall use the APN from the default PDN subscription context, and, use this APN
for the remainder of this procedure. Protocol Configuration Options (PCO) are used to transfer parameters
between the UE and the Network and are sent transparently through the MME and the Serving GW. The
Protocol Configuration Options may include the Address Allocation Preference, which indicates that the UE
prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4. If the UE has
UTRAN or GERAN capabilities, it shall send the NRSU in the PCO to indicate the support of the network
requested bearer control in UTRAN/GERAN. The UE sends the ETFTU in the PCO to indicate the support
of the extended TFT filter format. The Request Type indicates "initial request" if the UE requests new
additional PDN connectivity over the 3GPP access network for multiple PDN connections, the Request Type
indicates "handover" when the UE is performing a handover from non-3GPP access and the UE has already
established connectivity with the PDN over the non-3GPP access.
The UE shall indicate Request Type "Emergency" when it requests a PDN connection for emergency
services.
If the message is being sent via a HeNB which has a collocated L-GW, it includes the L-GW address in the
Uplink NAS transport message to the MME.
6
If a UE indicated Control Plane CIoT EPS optimisation supported in Preferred Network Behavior and
supports header compression, it shall include the Header Compression Configuration, unless "Non-IP" PDN
type is indicated. The Header Compression Configuration includes the information necessary for the ROHC
channel setup. Optionally, the Header Compression Configuration may also include additional header
compression context setup parameters, if the UE already has the application traffic information, e.g. the target
server IP address.
2. (Create Session Request)For PDN type "non-IP", if the APN subscription data indicate a SCEF connection
needs to be used, then the MME allocates an EPS Bearer Identity for the Default Bearer associated with the
UE and established connection to the SCEF address indicated in subscription data according to
TS 23.682 [74] and the steps 2,3,4,5,6 are not executed. The rest of the interactions with the UE apply as
specified below.
5. If the PDN type is Non-IP, the PDN-GW uses the APN and IMSI to determine what local actions to perform
before answering the Serving GW.
7. If the PDN type is set to "Non-IP" the MME includes it in the S1-AP Initial Context Setup Request so that the
eNodeB disables header compression. In addition, if the PDN connection is established for Local IP Access,
the corresponding S1 Initial Context Setup Request message includes a Correlation ID for enabling the direct
user plane path between the HeNB and the L-GW.
In the PDN Connectivity Accept message, the MME does not include the IPv6 prefix within the PDN Address.
The MME includes the APN-AMBR and the EPS Bearer QoS parameter QCI into the Session Management
Request. Furthermore, if the UE has UTRAN or GERAN capabilities and the network supports mobility to
UTRAN or GERAN, the MME uses the EPS bearer QoS parameters to derive the corresponding PDP context
parameters QoS Negotiated (R99 QoS profile), Radio Priority, Packet Flow Id and TI and includes them in
the Session Management Request. If the UE indicated in the UE Network Capability that it does not support
BSS packet flow procedures, then the MME shall not include the Packet Flow Id. MME will not send the S1
Bearer Setup Request message until any outstanding S1 Bearer Setup Response message for the same UE has
been received or timed out. If the APN-AMBR has changed the MME may update the UE-AMBR if
appropriate. The MME may include an indication whether the traffic of this PDN Connection is allowed to be
offloaded to WLAN, as described in clause 4.3.23. If the UE has indicated PDN type "Non-IP", the MME
and PDN GW shall not change PDN type.
1.9. C-SGN
The C-SGN (CIoT Serving Gateway Node) is a combined node EPC implementation option that minimizes
the number of physical entities by collocating EPS entities in the control and user planes paths (e.g.
MME, S-GW, P-GW), which may be preferred in CIoT deployments. The external interfaces of C-SGN
implementation option are the interfaces of the respective EPC entity supported by the C-SGN, such as
MME, S-GW, and P-GW.
A C-SGN supports sub-set and necessary functionalities compared with the existing EPS core network
elements and also supports at least some of the following CIoT optimizations:
- Control plane CIoT EPS optimization for small data transmission.
- User plane CIoT EPS optimization for small data transmission.
- Necessary security procedures for efficient small data tranmission.
- SMS without combined attach for NB-IoT only UEs.
- Paging optimisations for coverage enhancements.
- Support for non-IP data transmission via SGi tunnelling and/or SCEF.
7
- Support for Attach without PDN connectivity.
8
2. TS 36.413
E-RAB Setup
8.2.1.2 Successful Operation
If the Bearer Type IE is included in the E-RAB SETUP REQUEST message and is set to “non IP”, then the
eNB shall not perform header compression for the concerned E-RAB.
If the Bearer Type IE is included in the INITIAL CONTEXT SETUP REQUEST message and is set to “non IP”,
then the eNB shall not perform header compression for the concerned E-RAB.
If the Bearer Type IE is included in the HANDOVER REQUEST message and is set to “non IP”, then the eNB
shall not perform header compression for the concerned E-RAB.
9.2.1.116 Bearer Type
This IE is used to support Non-IP data as specified in TS 23.401 [11].
IE/Group Name Presence Range IE type and Semantics description
reference
Bearer Type M ENUMERATED
(non IP, …)
9
3. TS 24.301
3.1. 5.3.15 CIoT EPS optimizations
The control plane CIoT EPS optimization enables support of efficient transport of user data (IP, non-IP) or
SMS messages over control plane via the MME without triggering data radio bearer establishment. The
support of control plane CIoT EPS optimization is mandatory for the network in NB-S1 mode and
optional in WB-S1 mode. Optional header compression of IP data can be applied to IP PDN type PDN
connections that are configured to support header compression.
If the UE indicates support of one or more CIoT EPS optimizations and the network supports one or more
CIoT EPS optimizations and decides to accept the attach or tracking area update request, the network
indicates the supported CIoT EPS optimizations to the UE per TAI list when accepting the UE request.
Network indication of support is interpreted by the UE as the acceptance to use the respective feature.
After completion of the attach or tracking area updating procedure, the UE and the network can then
use the accepted CIoT EPS optimizations for the transfer of user data (IP, non-IP and SMS).
If the UE and the network support both the control plane CIoT EPS optimization and S1-U data transfer,
then when receiving the UE's request for a PDN connection, the MME decides whether the PDN
connection should be SCEF PDN connection or SGi PDN connection as specified in 3GPP TS 23.401 [10]:
- if SCEF PDN connection is to be established for non-IP data type, the MME shall include Control plane only
indication for the requested PDN connection;
3.2. 5.5.1.2.2 Attach procedure initiation
If the UE supports NB-S1 mode or Non-IP PDN type, then the UE shall support the extended protocol
configuration options IE.
If the MME supports NB-S1 mode or Non-IP PDN type, then the MME shall support the extended
protocol configuration options IE.
3.3. 5.5.3 Tracking area updating procedure (S1 mode only)
If the UE supports NB-S1 mode or Non-IP PDN type, then the UE shall support the extended protocol
configuration options IE.
If the MME supports NB-S1 mode or Non-IP PDN type, then the MME shall support the extended
protocol configuration options IE.
5.5.3.2.2 Normal and periodic tracking area updating procedure initiation
When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an
EPS bearer context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS
10
bearer contexts are active in the UE. The UE shall include the EPS bearer context status IE in TRACKING
AREA UPDATE REQUEST message:
- for the case f;
- for the case s; and
- if the UE has established PDN connection(s) of "non IP" PDN type.
3.4. 5.6 EMM connection management procedures (S1 mode only)
5.6.1 Service request procedure

5.6.1.1 General
b) the UE, in EMM-IDLE mode, has pending user data to be sent;
m) the UE, in EMM-CONNECTED mode and has a NAS signalling connection only, is using EPS services with
control plane CIoT EPS optimization and has pending user data to be sent via user plane radio bearers.
3.4.1. For case b in subclause 5.6.1.1,

- if the UE has pending IP or non-IP user data that is to be sent via the control plane radio bearers, the Control
plane service type of the CONTROL PLANE SERVICE REQUEST message shall indicate "mobile
originating request". The UE shall include an ESM DATA TRANSPORT message in the ESM message
container IE.
3.4.2. For cases b and m in subclause 5.6.1.1,

- if the UE has pending IP or non-IP user data that is to be sent via the user plane radio bearers, the UE shall set
the Control plane service type of the CONTROL PLANE SERVICE REQUEST message to "mobile
originating request" and the "active" flag in the Control plane service type IE to 1. The UE shall not include
any ESM message container or NAS message container IE in the CONTROL PLANE SERVICE REQUEST
message.
3.5. 6.Elementary procedures for EPS session management

6.1 Overview
6.1.1 General
A dedicated EPS bearer context is always linked to a default EPS bearer context and represents additional
EPS bearer resources between the UE and the PDN. The network can initiate the activation of dedicated
EPS bearer contexts together with the activation of the default EPS bearer context or at any time later, as
long as the default EPS bearer context remains activated. However, the network shall not initiate a
dedicated bearer context activation procedure for established PDN connection(s) of "non IP" PDN type.
Default and dedicated EPS bearer contexts can be modified. Dedicated EPS bearer contexts can be
released without affecting the default EPS bearer context. When the default EPS bearer context is
released, then all dedicated EPS bearer contexts linked to it are released, too.
11
The UE can request the network to allocate, modify or release additional EPS bearer resources. The
network decides whether to fulfil a request for additional resources by activating a new dedicated EPS
bearer context or modifying an existing dedicated or default EPS bearer context. However, the network
shall not initiate a dedicated bearer context activation procedure for established PDN connection(s) of
"non IP" PDN type.
6.2.2 IP address allocation via NAS signalling
The UE shall set the PDN type IE in the PDN CONNECTIVITY REQUEST message, based on its IP stack
configuration if it requests IP connectivity (e.g. the per APN settings specified in 3GPP TS 23.401 [10]) as
follows:
a)- A UE, which is IPv6 and IPv4 capable and
- has not been allocated an IP address for this APN, shall set the PDN type IE to IPv4v6.
- has been allocated an IPv4 address for this APN and received the ESM cause #52 "single
address bearers only allowed", and is requesting an IPv6 address, shall set the PDN type IE to
IPv6.
- has been allocated an IPv6 address for this APN and received the ESM cause #52 "single
address bearers only allowed", and is requesting an IPv4 address, shall set the PDN type IE to
IPv4.
b) A UE, which is only IPv4 capable, shall set the PDN type IE to IPv4.
c) A UE, which is only IPv6 capable, shall set the PDN type IE to IPv6.
d) When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are
separated and the capability of the TE is not known in the MT), the UE shall set the PDN type IE to IPv4v6.
If the UE wants to use DHCPv4 for IPv4 address assignment, it shall indicate that to the network within
the Protocol Configuration Options IE in the PDN CONNECTIVITY REQUEST.
If the UE wants to get PDN connectivity without IP, the UE shall set the PDN type IE in the PDN
CONNECTIVITY REQUEST message to "non IP".
6.4.1.3 Default EPS bearer context activation accepted by the UE
If the UE receives non-IP Link MTU parameter or IPv4 Link MTU parameter of the protocol configuration
options IE in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE shall pass the
received Non-IP Link MTU or IPv4 Link MTU to the upper layer .
NOTE: The Non-IP Link MTU and IPv4 Link MTU size correspond to the maximum length of user
data container that can be sent in the ESM DATA TRANSPORT message and to the maximum
length of user data that can be sent via S1-U interface.
6.5.1.2 UE requested PDN connectivity procedure initiation
12
In the PDN type IE the UE shall either indicate the IP version capability of the IP stack associated with the
UE or non IP as specified in subclause 6.2.2.
6.5.1.4 UE requested PDN connectivity procedure not accepted by the network
The ESM cause IE typically indicates one of the following ESM cause values:
#58: PDN type non IP only allowed;
If the Back-off timer value IE is included and the ESM cause value is different from #26 "insufficient
resources", #50 "PDN type IPv4 only allowed", #51 "PDN type IPv6 only allowed", #57 "PDN type IPv4v6
only allowed", #58 "PDN type non IP only allowed" and #65 "maximum number of EPS bearers reached",
the network may include the Re-attempt indicator IE to indicate whether the UE is allowed to attempt a
PDP context activation procedure in the PLMN for the same APN in A/Gb or Iu mode, and whether
another attempt in A/Gb and Iu mode or in S1 mode is allowed in an equivalent PLMN.
If the ESM cause value is #50 "PDN type IPv4 only allowed", #51 "PDN type IPv6 only allowed", #57 "PDN
type IPv4v6 only allowed" or #58 "PDN type non IP only allowed", the network may include the Re-
attempt indicator IE without Back-off timer value IE to indicate whether the UE is allowed to attempt a
PDN connectivity procedure in an equivalent PLMN for the same APN in S1 mode using the same PDN
type.
6.5.1.4.3 Handling of network rejection due to ESM cause other than ESM cause
#26
If the ESM cause value is #50 "PDN type IPv4 only allowed", #51 "PDN type IPv6 only allowed", #57 "PDN
type IPv4v6 only allowed" or #58 "PDN type non IP only allowed", the UE shall ignore the Back-off timer
value IE provided by the network, if any. The UE shall not automatically send another PDN
CONNECTIVITY REQUEST message for the same APN that was sent by the UE using the same PDN type
until any of the following conditions is fulfilled:
- the UE is registered to a new PLMN, and either the network did not include a Re-attempt indicator IE in the
PDN CONNECTIVITY REJECT message or the Re-attempt indicator IE included in the message indicated
that re-attempt in an equivalent PLMN is allowed;
- the UE is registered to a new PLMN which was not in the list of equivalent PLMNs at the time when the
PDN CONNECTIVITY REJECT message was received;
- the PDN type which is used to access to the APN is changed;
- the UE is switched off; or
- the USIM is removed.
For the ESM cause values #50 "PDN type IPv4 only allowed", #51 "PDN type IPv6 only allowed", #57
"PDN type IPv4v6 only allowed" and #58 "PDN type non IP only allowed" the UE shall ignore the value of
the RATC bit in the Re-attempt indicator IE provided by the network, if any.
Furthermore as an implementation option, for the SM cause values #50 "PDN type IPv4 only allowed",
#51 "PDN type IPv6 only allowed", #57 "PDN type IPv4v6 only allowed" and #58 "PDN type non IP only
13
allowed", if the network does not include a Re-attempt indicator IE the UE may decide not to
automatically send another PDN CONNECTIVITY REQUEST message for the same APN that was sent by
the UE using the same PDN type, if the UE is registered to a new PLMN which is in the list of equivalent
PLMNs.
6.6.4.2 UE initiated transport of user data via the control plane
Upon receipt of a request to transfer user data via the control plane, if the UE is in EMM-CONNECTED
mode, the UE initiates the procedure by sending the ESM DATA TRANSPORT message including the user
data to be sent in the User data container IE. The length of the value part of the User data container IE
should not exceed the link MTU size for the respective type of user data (IPv4, IPv6 or Non-IP).
3.6.1. 8.3.14 ESM information response

Table 8.3.14.1: ESM INFORMATION RESPONSE message content
IEI Information Element Type/Reference Presence Format Length
Protocol discriminator Protocol discriminator M V 1/2
9.2
EPS bearer identity EPS bearer identity M V 1/2
9.3.2
Procedure transaction identity Procedure transaction identity M V 1
9.4
ESM information response Message type M V 1
message identity 9.8
28 Access point name Access point name O TLV 3-102
9.9.4.1
27 Protocol configuration options Protocol configuration options O TLV 3-253
9.9.4.11
7B Extended protocol configuration Extended protocol configuration O TLV-E 4-65538
options options
9.9.4.26
8.3.14.3 Protocol configuration options

This IE is included in the message when, during the attach procedure, the UE wishes to transmit security
protected (protocol) data (e.g. configuration parameters, error codes or messages/events) to the
network, in WB-S1 mode, or when the PDN Type requested is different from Non-IP.
This IE shall be included if the UE supports local IP address in traffic flow aggregate description and TFT
filter, in WB-S1 mode, or when the PDN Type requested is different from Non-IP.
This IE shall not be included if the Extended protocol configuration options IE is included in the message.
8.3.14.4 Extended protocol configuration options

network, in NB-S1 mode or when Non-IP PDN Type is requested.
14
filter, in NB-S1 mode or when Non-IP PDN Type is requested.
This IE shall not be included if the Protocol configuration options IE is included in the message.
8.3.19 PDN connectivity reject
Table 8.3.19.1: PDN CONNECTIVITY REJECT message content

9.2
9.3.2
9.4
PDN connectivity reject message Message type M V 1
identity 9.8
ESM cause ESM cause M V 1
9.9.4.4
9.9.4.11
37 Back-off timer value GPRS timer 3 O TLV 3
9.9.3.16B
6B Re-attempt indicator Re-attempt indicator O TLV 3
9.9.4.13A
33 NBIFOM container NBIFOM container O TLV 3-257
9.9.4.19
options options
9.9.4.26
8.3.19.4 Re-attempt indicator
The network may include this IE only if the ESM cause value is #50 "PDN type IPv4 only allowed", #51
"PDN type IPv6 only allowed", #57 "PDN type IPv4v6 only allowed", #58 "PDN type non IP only allowed",
or #66 "requested APN not supported in current RAT and PLMN combination", or if the network includes
the Back-off timer value IE and the ESM cause value is not #26 "insufficient resources".

This IE is included in the message when the network wishes to transmit (protocol) data (e.g.
configuration parameters, error codes or messages/events) to the UE and the extended protocol
configuration options is supported by both the UE and the network.
NOTE: The extended protocol configuration options is supported by the network if the network has
indicated support of the extended protocol configuration options IE in the mobility
management messages and the network has included the extended protocol configuration
options IE in the session management messages to the UE.
8.3.20 PDN connectivity request
15
Table 8.3.20.1: PDN CONNECTIVITY REQUEST message content
9.2
9.3.2
9.4
PDN connectivity request Message type M V 1
message identity 9.8
Request type Request type M V 1/2
9.9.4.14
PDN type PDN type M V 1/2
9.9.4.10
D- ESM information transfer flag ESM information transfer flag O TV 1
9.9.4.5
28 Access point name Access point name O TLV 3-102
9.9.4.1
9.9.4.11
C- Device properties Device properties O TV 1
9.9.2.0A
33 NBIFOM container NBIFOM container O TLV 3-257
9.9.4.19
66 Header compression configuration Header compression configuration O TLV 5-257
9.9.4.22
options options
9.9.4.26
8.3.20.4 Protocol configuration options

This IE is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration
parameters, error codes or messages/events) to the network, in WB-S1 mode, or when the PDN Type
requested is different from Non-IP.
filter, in WB-S1 mode, or when the PDN Type requested is different from Non-IP.
This IE shall not be included if the Extended protocol configuration options IE is included in the message.

network, in NB-S1 mode or when Non-IP PDN Type is requested.
filter, in NB-S1 mode or when Non-IP PDN Type is requested.
This IE shall not be included if the Protocol configuration options IE is included in the message.
16
9.9.4.9 PDN address
The PDN address information element can assign an IPv4 address to the UE associated with a packet
data network and provide the UE with an interface identifier to be used to build the IPv6 link local
address.
The PDN address information element is coded as shown in figure 9.9.4.9.1 and table 9.9.4.9.1.
The PDN address is a type 4 information element with minimum length of 7 octets and a maximum
length of 15 octets.
8 7 6 5 4 3 2 1
PDN address IEI octet 1
Length of PDN address contents octet 2
0 0 0 0 0 PDN type value octet 3
spare
octet 4
PDN address information
octet 15
Figure 9.9.4.9.1: PDN address information element
Table 9.9.4.9.1: PDN address information element

PDN type value (octet 3)
Bits
3 2 1
0 0 1 IPv4
0 1 0 IPv6
0 1 1 IPv4v6
1 0 1 non IP
All other values are reserved.
Bit 4 to 8 of octet 3 are spare and shall be coded as zero.
PDN address information (octet 4 to 15)
If PDN type value indicates IPv4, the PDN address information in octet 4 to octet 7
contains an IPv4 address. Bit 8 of octet 4 represents the most significant bit of the IPv4
address and bit 1 of octet 7 the least significant bit.
If PDN type value indicates IPv6, the PDN address information in octet 4 to octet 11
contains an IPv6 interface identifier. Bit 8 of octet 4 represents the most significant bit
of the IPv6 interface identifier and bit 1 of octet 11 the least significant bit.
If PDN type value indicates IPv4v6, the PDN address information in octet 4 to octet 15
contains an IPv6 interface identifier and an IPv4 address. Bit 8 of octet 4 represents
the most significant bit of the IPv6 interface identifier and bit 1 of octet 11 the least
significant bit. Bit 8 of octet 12 represents the most significant bit of the IPv4 address
and bit 1 of octet 15 the least significant bit.
If PDN type value indicates IPv4 or IPv4v6 and DHCPv4 is to be used to allocate the
IPv4 address, the IPv4 address shall be coded as 0.0.0.0.
If PDN type value indicates non IP, the PDN address information in octet 4 to octet 7
are spare and shall be coded as zero.
17
9.9.4.10 PDN type
The purpose of the PDN type information element is to indicate either:
- the IP version capability of the IP stack associated with the UE; or.- non IP
The PDN type information element is coded as shown in figure 9.9.4.10.1 and table 9.9.4.10.1.
The PDN type is a type 1 information element.
8 7 6 5 4 3 2 1
PDN type IEI 0 PDN type value octet 1
Spare
Table 9.9.4.10.1: PDN type information element

PDN type value (octet 1)
Bits
3 2 1
0 0 1 IPv4
0 1 0 IPv6
0 1 1 IPv4v6
1 0 0 unused; shall be interpreted as "IPv6" if received by the network
1 0 1 non IP
All other values are reserved.
Bit 4 of octet 1 is spare and shall be coded as zero.
B.1 Causes related to nature of request
Cause #58 – PDN type non IP only allowed

This ESM cause is used by the network to indicate that only PDN type non IP is allowed for the requested
PDN connectivity.
18
4. TS 24.008
4.1. 10.5.6.3 Protocol configuration options

10.5.6.3.1 General
The purpose of the protocol configuration options information element is to:
- transfer external network protocol options associated with a PDP context activation, and
- transfer additional (protocol) data (e.g. configuration parameters, error codes or messages/events) associated
with an external protocol or an application.
The protocol configuration options is a type 4 information element with a minimum length of 3 octets
and a maximum length of 253 octets.
The protocol configuration options information element is coded as shown in figure 10.5.136/3GPP TS
24.008 and table 10.5.154/3GPP TS 24.008.
8 7 6 5 4 3 2 1
Protocol configuration options IEI octet 1
Length of protocol config. options contents octet 2
1 0 0 0 0 Configuration octet 3
ext Spare protocol
Protocol ID 1 octet 4
octet 5
Length of protocol ID 1 contents octet 6
octet 7
Protocol ID 1 contents
octet m
Protocol ID 2 octet m+1
octet m+2
Length of protocol ID 2 contents octet m+3
octet m+4
Protocol ID 2 contents
octet n
octet n+1
...
octet u
Protocol ID n-1 octet u+1
octet u+2
Length of protocol ID n-1 contents octet u+3
octet u+4
Protocol ID n-1 contents
octet v
Protocol ID n octet v+1
octet v+2
Length of protocol ID n contents octet v+3
octet v+4
Protocol ID n contents
octet w
19
Container ID 1 octet w+1
octet w+2
Length of container ID 1 contents octet w+3
Container ID 1 contents octet w+4
octet x
octet x+1
...
octet y
Container ID n octet y+1
octet y+2
Length of container ID n contents octet y+3
Container ID n contents octet y+4
octet z
Figure 10.5.136/3GPP TS 24.008: Protocol configuration options information element
20
Table 10.5.154/3GPP TS 24.008: Protocol configuration options information element
21
Configuration protocol (octet 3)
Bits
321
000 PPP for use with IP PDP type or IP PDN type (see 3GPP TS 24.301 [120])
All other values are interpreted as PPP in this version of the protocol.
After octet 3, i.e. from octet 4 to octet z, two logical lists are defined:
- the Configuration protocol options list (octets 4 to w), and
- the Additional parameters list (octets w+1 to z).
Configuration protocol options list (octets 4 to w)
The configuration protocol options list contains a variable number of logical units,
they may occur in an arbitrary order within the configuration protocol options list.
Each unit is of variable length and consists of a:
- protocol identifier (2 octets);

- the length of the protocol identifier contents of the unit (1 octet); and
- the protocol identifier contents itself (n octets).
The protocol identifier field contains the hexadecimal coding of the configuration
protocol identifier. Bit 8 of the first octet of the protocol identifier field contains the
most significant bit and bit 1 of the second octet of the protocol identifier field
contains the least significant bit.
If the configuration protocol options list contains a protocol identifier that is not
supported by the receiving entity the corresponding unit shall be ignored.
The length of the protocol identifier contents field contains the binary coded
representation of the length of the protocol identifier contents field of a unit. The first
bit in transmission order is the most significant bit.
The protocol identifier contents field of each unit contains information specific to the
configuration protocol specified by the protocol identifier.
At least the following protocol identifiers (as defined in RFC 3232 [103]) shall be
supported in this version of the protocol:
- C021H (LCP);
- C023H (PAP);
- C223H (CHAP); and
- 8021H (IPCP).
The support of other protocol identifiers is implementation dependent and outside

the scope of the present document.
The protocol identifier contents field of each unit corresponds to a “Packet” as

defined in RFC 1661 [102] that is stripped off the “Protocol” and the “Padding”
octets.
The detailed coding of the protocol identifier contents field is specified in the RFC
that is associated with the protocol identifier of that unit.
Additional parameters list (octets w+1 to z)
The additional parameters list is included when special parameters and/or requests
(associated with a PDP context) need to be transferred between the MS and the
network. These parameters and/or requests are not related to a specific
22
configuration protocol (e.g. PPP), and therefore are not encoded as the "Packets"
contained in the configuration protocol options list.
The additional parameters list contains a list of special parameters, each one in a
separate container. The type of the parameter carried in a container is identified by
a specific container identifier. In this version of the protocol, the following container
identifiers are specified:
MS to network direction:
- 0001H (P-CSCF IPv6 Address Request);
- 0002H (IM CN Subsystem Signaling Flag);
- 0003H (DNS Server IPv6 Address Request);
- 0004H (Not Supported);
- 0005H (MS Support of Network Requested Bearer Control indicator);
- 0006H (Reserved);
- 0007H (DSMIPv6 Home Agent Address Request);
- 0008H (DSMIPv6 Home Network Prefix Request);
- 0009H (DSMIPv6 IPv4 Home Agent Address Request);
- 000AH (IP address allocation via NAS signalling);
- 000BH (IPv4 address allocation via DHCPv4);
- 000CH (P-CSCF IPv4 Address Request);
- 000DH (DNS Server IPv4 Address Request);
- 000EH (MSISDN Request);
- 000FH (IFOM-Support-Request);
- 0010H (IPv4 Link MTU Request);
- 0011H (MS support of Local address in TFT indicator);
- 0012H (P-CSCF Re-selection support);
- 0013H (NBIFOM request indicator);
- 0014H (NBIFOM mode);
- 0015H (Non-IP Link MTU Request);
- 0016H (APN rate control support indicator); and
- FF00H to FFFFH reserved for operator specific use.
Network to MS direction:
- 0001H (P-CSCF IPv6 Address);
- 0002H (IM CN Subsystem Signaling Flag);
- 0003H (DNS Server IPv6 Address);
23
- 0004H (Policy Control rejection code);
- 0005H (Selected Bearer Control Mode;
- 0006H (Reserved);
- 0007H (DSMIPv6 Home Agent Address) ;
- 0008H (DSMIPv6 Home Network Prefix);
- 0009H (DSMIPv6 IPv4 Home Agent Address);
- 000AH (Reserved);
- 000BH (Reserved);
- 000CH (P-CSCF IPv4 Address);
- 000DH (DNS Server IPv4 Address);
- 000EH (MSISDN);
- 000FH (IFOM-Support);
- 0010H (IPv4 Link MTU);
- 0011H (Network support of Local address in TFT indicator);
- 0012H (Reserved);
- 0013H (NBIFOM accepted indicator);
- 0014H (NBIFOM mode);
- 0015H (Non-IP Link MTU);
- 0016H (APN rate control parameters); and
- FF00H to FFFFH reserved for operator specific use.
If the additional parameters list contains a container identifier that is not supported
by the receiving entity the corresponding unit shall be ignored.
The container identifier field is encoded as the protocol identifier field and the length
of container identifier contents field is encoded as the length of the protocol
identifier contents field.
When the container identifier indicates P-CSCF IPv6 Address Request, DNS Server
IPv6 Address Request, or MSISDN Request, the container identifier contents field is
empty and the length of container identifier contents indicates a length equal to
zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates IM CN Subsystem Signaling Flag (see 3GPP
TS 24.229 [95]), the container identifier contents field is empty and the length of
container identifier contents indicates a length equal to zero. If the container
identifier contents field is not empty, it shall be ignored. In Network to MS direction
this information may be used by the MS to indicate to the user whether the
requested dedicated signalling PDP context was successfully established.
When the container identifier indicates P-CSCF IPv6 Address, the container
identifier contents field contains one IPv6 address corresponding to a P-CSCF
address (see 3GPP TS 24.229 [95]). This IPv6 address is encoded as a 128-bit
address according to IETF RFC 4291 [99]. When there is a need to include more
24
than one P-CSCF IPv6 address, then more logical units with the container identifier
indicating P-CSCF IPv6 Address are used. If more than 3 instances of the P-CSCF
IPv6 Address logical unit are received by the MS then the MS may ignore all but the
first 3 instances of the P-CSCF IPv6 Address logical unit received.
When the container identifier indicates DNS Server IPv6 Address, the container
identifier contents field contains one IPv6 DNS server address (see 3GPP TS
27.060 [36a]). This IPv6 address is encoded as a 128-bit address according to
IETF RFC 4291 [99]. When there is a need to include more than one DNS Server
IPv6 address, then more logical units with the container identifier indicating DNS
Server IPv6 Address are used.
When the container identifier indicates Policy Control rejection code, the container
identifier contents field contains a Go interface related cause code from the GGSN
to the MS (see 3GPP TS 29.207 [100]). The length of container identifier contents
indicates a length equal to one. If the container identifier contents field is empty or
its actual length is greater than one octect, then it shall be ignored by the receiver.
When the container identifier indicates MS Support of Network Requested Bearer

Control indicator, the container identifier contents field is empty and the length of
container identifier contents indicates a length equal to zero. If the container
identifier contents field is not empty, it shall be ignored.
When the container identifier indicates Selected Bearer Control Mode, the container
identifier contents field contains the selected bearer control mode, where ‘01H’
indicates that ‘MS only’ mode has been selected and ‘02H’ indicates that ‘MS/NW’
mode has been selected. The length of container identifier contents indicates a
length equal to one. If the container identifier contents field is empty or its actual
length is greater than one octect, then it shall be ignored by the receiver.
When the container identifier indicates DSMIPv6 Home Agent Address Request, the
container identifier contents field is empty and the length of container identifier
contents indicates a length equal to zero. If the container identifier contents field is
not empty, it shall be ignored.
When the container identifier indicates DSMIPv6 Home Network Prefix Request, the
When the container identifier indicates DSMIPv6 IPv4 Home Agent Address
Request, the container identifier contents field is empty and the length of container
identifier contents indicates a length equal to zero. If the container identifier
contents field is not empty, it shall be ignored.
When the container identifier indicates DSMIPv6 Home Agent Address, the
container identifier contents field contains one IPv6 address corresponding to a
DSMIPv6 HA address (see 3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]). This
IPv6 address is encoded as a 128-bit address according to IETF RFC 4291 [99].
When the container identifier indicates DSMIPv6 Home Network Prefix, the
container identifier contents field contains one IPv6 Home Network Prefix (see
3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]). This IPv6 prefix is encoded as
an IPv6 address according to IETF RFC 4291 [99] followed by 8 bits which specifies
the prefix length.
When the container identifier indicates DSMIPv6 IPv4 Home Agent Address, the
container identifier contents field contains one IPv4 address corresponding to a
DSMIPv6 IPv4 Home Agent address (see 3GPP TS 24.303 [124] and
3GPP TS 24.327 [125]).
25
When the container identifier indicates P-CSCF IPv4 Address Request, the
When the container identifier indicates DNS Server IPv4 Address Request, the
When the container identifier indicates P-CSCF IPv4 Address, the container
identifier contents field contains one IPv4 address corresponding to the P-CSCF
address to be used. When there is a need to include more than one P-CSCF IPv4
address, then more logical units with the container identifier indicating P-CSCF IPv4
Address are used. If more than 3 instances of the P-CSCF IPv4 Address logical unit
are received by the MS then the MS may ignore all but the first 3 instances of the
P-CSCF IPv4 Address logical unit received.
When the container identifier indicates DNS Server IPv4 Address, the container
identifier contents field contains one IPv4 address corresponding to the DNS server
address to be used. When there is a need to include more than one DNS Server
IPv4 address, then more logical units with the container identifier indicating DNS
Server IPv4 Address are used.
P-CSCF IPv4 Address Request, P-CSCF IPv4 Address, DNS Server IPv4 Address
Request and DNS Server IPv4 Address are applicable only in S1-mode.
When the container identifier indicates IP address allocation via NAS signalling, the
When the container identifier indicates IP address allocation via DHCPv4, the
When the container identifier indicates MSISDN, the container identifier contents
field contains the MSISDN (see 3GPP TS 23.003 [10]) assigned to the MS. Use of
the MSISDN provided is defined in subclause 6.4.
When the container identifier indicates IFOM Support Request (see

3GPP TS 24.303 [124] and 3GPP TS 24.327 [125]), the container identifier contents
field is empty and the length of container identifier contents indicates a length equal
to zero. If the container identifier contents field is not empty, it shall be ignored.
When the container identifier indicates IFOM Support, the container identifier
contents field is empty and the length of container identifier contents indicates a
length equal to zero. If the container identifier contents field is not empty, it shall be
ignored. This information indicates that the Home Agent supports IFOM.
When the container identifier indicates IPv4 Link MTU Request, the container
identifier contents field is empty and the length of container identifier contents
indicates a length equal to zero. If the container identifier contents field is not empty,
it shall be ignored.
When the container identifier indicates IPv4 Link MTU, the length of container
identifier contents indicates a length equal to two. The container identifier contents
field contains the binary coded representation of the IPv4 link MTU size in octets. Bit
8 of the first octet of the container identifier contents field contains the most
significant bit and bit 1 of the second octet of the container identifier contents field
26
contains the least significant bit. If the length of container identifier contents is
different from two octets, then it shall be ignored by the receiver.
When the container identifier indicates MS support of Local address in TFT, the
not empty, it shall be ignored. This information indicates that the MS supports Local
address in TFTs.
When the container identifier indicates Network support of Local address in TFT, the
not empty, it shall be ignored. This information indicates that the network supports
Local address in TFTs.
When the container identifier indicates P-CSCF Re-selection support, the container
it shall be ignored. This PCO parameter may be present only if a container with P-
CSCF IPv4 Address Request or P-CSCF IPv6 Address Request is present. This
information indicates that the UE supports P-CSCF re-selection based on
procedures specified in 3GPP TS 24.229 [95] subclauses B.2.2.1C, L.2.2.1C and
R.2.2.1C.
When the container identifier indicates NBIFOM request indicator, the container
it shall be ignored. This information indicates that the MS requests the NBIFOM
usage.
When the container identifier indicates NBIFOM accepted indicator, the container
it shall be ignored. This information indicates that the network accepts UE's request
of the NBIFOM usage.
When the container identifier indicates NBIFOM mode, the length of container
identifier contents indicates a length equal to one. If the length of container identifier
contents indicates length different to one, it shall be ignored. The container identifier
contents field containing value 00H indicates the UE-initiated NBIFOM mode. The
container identifier contents field containing value 01H indicates the network-
initiated NBIFOM mode. The container identifier contents field containing a value
other than 00H and other than 01H shall be ignored.
When the container identifier indicates Non-IP Link MTU Request, the container
it shall be ignored. This information indicates that the MS requests link MTU for
"non-IP" PDN connection.
When the container identifier indicates Non-IP Link MTU, the length of container
identifier contents indicates a length equal to two. The container identifier contents
field contains the binary coded representation of the link MTU size for non-IP PDN
connection in octets which is at least 128 octets. Bit 8 of the first octet of the
container identifier contents field contains the most significant bit and bit 1 of the
second octet of the container identifier contents field contains the least significant
bit. If the length of container identifier contents is different from two octets, then it
shall be ignored by the receiver.
When the container identifier indicates APN rate control support indicator, the
27
not empty, it shall be ignored. This information indicates that the MS supports APN
rate control functionality.
When the container identifier indicates APN rate control parameters, the container
identifier contents field contains parameters for APN rate control functionality. The
the container contents are coded as described in subclause 10.5.6.3.2.
When the container identifier indicates operator specific use, the Container contents
starts with MCC and MNC of the operator providing the relevant application and can
be followed by further application specific information. The coding of MCC and MNC
is as in octet 2 to 4 of the Location Area Identification information element in
subclause 10.5.1.3.
NOTE 1: The additional parameters list and the configuration protocol options list
are logically separated since they carry different type of information. The
beginning of the additional parameters list is marked by a logical unit,
which has an identifier (i.e. the first two octets) equal to a container
identifier (i.e. it is not a protocol identifier).
5. TS 23.682
28
5.1. 4.4.3 HSS/HLR
An HSS supporting non-IP data delivery via SCEF feature shall support the following functionalities:
- termination of the S6t reference point where SCEF connect to the HSS; and
- mapping of E.164 MSISDN or external identifier to IMSI.
4.4.5 SGSN/MME/MSC
- The MME and SGSN transfers non-IP data to the UE using a PDN connection to the SCEF as defined in
TS 23.401 [7] and TS 23.060 [6] respectively.
- The MME/SGSN transfers non-IP data to the (IWK-)SCEF.
4.4.8 Service Capability Exposure Function

The Service Capability Exposure Function (SCEF) provides a means to securely expose the services and
capabilities provided by 3GPP network interfaces. The SCEF provides a means for the discovery of the
exposed services and capabilities. The SCEF provides access to network capabilities through
homogenous network application programming interfaces (e.g. Network APIs) defined over T8 interface.
The SCEF abstracts the services from the underlying 3GPP network interfaces and protocols.
Individual instances of SCEF may vary depending on what service capabilities are exposed and what API
features are supported.
The SCEF is always within the trust domain. An application can belong to the trust domain or may lie
outside the trust domain.
The SCEF may support CAPIF. When CAPIF is supported, the SCEF supports the CAPIF API provider
domain functions. The CAPIF and associated API provider domain functions are specified in
TS 23.222 [43].
The functionality of the SCEF may include the following:

- Authentication and Authorization:
- Identification of the API consumer,
- Profile management,
- ACL (access control list) management.
NOTE 1: The details of security aspects of T8 interface are outside the scope of this specification.
- Ability for the external entities to discover the exposed service capabilities
- Policy enforcement:
- Infrastructural Policy: policies to protect platforms and network. An example of which maybe
ensuring that a service node such as SMS-SC is not overloaded.
- Business Policy: policies related to the specific functionalities exposed. An example may be
number portability, service routing, subscriber consent etc.
- Application Layer Policy: policies that are primarily focused on message payload or throughput
provided by an application. An example may be throttling.
29
- Assurance:
- Integration with O&M systems,
- Assurance process related to usage of APIs.

- Accounting for inter operator settlements.
NOTE 2: The details of accounting aspects of T8 interface are outside the scope of this specification.
- Access: issues related to external interconnection and point of contact
- Abstraction: hides the underlying 3GPP network interfaces and protocols to allow full network integration.
The following functions are among those that may be supported:
- Underlying protocol connectivity, routing and traffic control,
- Mapping specific APIs onto appropriate network interfaces,
- Protocol translation.
NOTE 3: Abstraction is applied only in cases where required functionality is not natively provided by
3GPP network
The services and capabilities offered by SCEF to SCS/AS include:

- Group Message Delivery (see clause 4.5.5),
- Monitoring events (see clause 4.5.6),
- High latency communication (see clause 4.5.7),
- Informing about potential network issues (see clause 4.5.8),
- Resource management of background data transfer (see clause 4.5.9),
- E-UTRAN network resource optimizations based on communication patterns provided to the MME (see
clause 4.5.10),
- Support of setting up an AS session with required QoS (see clause 4.5.11),
- Change the chargeable party at session set-up or during the session (see clause 4.5.12),
- Non-IP Data Delivery (see clause 4.5.14),
- Packet Flow Description management (see clause 4.5.15),
- Enhanced Coverage restriction control (see clause 4.5.17),
- Network Parameter Configuration (see clause 4.5.20),
- Accessing MTC-IWF Functionality via T8 (see clause 5.17),
The SCEF shall protect the other PLMN entities (e.g. HSS, MME) from requests exceeding the permission
arranged in the SLA with the third-party service provider.
When needed, the SCEF supports mapping between information exchanged with SCS/AS (e.g.
geographical identifiers) and information exchanged with internal PLMN functions (e.g. cell-Id / ENB-Id /
30
TAI / MBMS SAI , etc.). This mapping is assumed to be provided by the SCEF based on local configuration
data.
4.4.9 Interworking SCEF

The Interworking SCEF (IWK-SCEF) is optional. When deployed, the IWK-SCEF is located in the VPLMN for
inter-connection with the SCEF of the HPLMN. The Interworking SCEF receives the Monitoring Event
Reports from the underlying entities and sends them to the SCEF. The IWK-SCEF relays the non-IP data
between the MME/SGSN and the SCEF.
NOTE: In this release the only VPLMN network entities connected towards the IWK-SCEF are the
MMEs and SGSNs.
The functionality of the Interworking SCEF may include the following:

- Normalization of reports according to roaming agreement between VPLMN and HPLMN, e.g. change the
location granularity (from cell level to a level appropriate for the HPLMN) of Monitoring Event Reports
received from the underlying entities; and
- Optionally, generate charging/accounting information:
- For generation of charging/accounting information, the IWK-SCEF receives the Monitoring

configuration information as well as the Monitoring Event Report from the underlying nodes;
- For generation of charging/accounting information, the IWK-SCEF receives the NIDD charging
ID from the SCEF during the T6a/T6b Connection Establishment Procedure (see
clause 5.13.1.2),
5.2. 4.5.5 Group Message Delivery

The Group Message Delivery feature allows an SCS/AS to deliver a payload to a group of UEs. Two
methods of Group Message Delivery are specified:
- Group Message Delivery via MBMS which is intended to efficiently distribute the same content to the
members of a group that are located in a particular geographical area when MBMS is used;
- Group Message Delivery via unicast MT NIDD for UEs which are part of the same External Group Identifier.
The specific procedure handling for group message delivery using MBMS is described in clause 5.5.1. The
group message delivery using MBMS has limited applicability and does not support all the scenarios, e.g.
UEs not supporting MBMS, UEs located in areas where MBMS is not deployed. The SCS/AS may recall or
replace a previously submitted MBMS message; this is described in clause 5.5.2.
The Group MT NIDD procedure for delivering non-IP data to a group via unicast MT NIDD is described in
clause 5.5.3. The SCEF uses the SCS/AS Identifier and the External Group Identifier to determine the APN
that will be used to send the non-IP data to the group member UEs. This determination is based on local
policies. When the SCEF receives a Group MT NIDD request from the SCS/AS, the SCEF queries the HSS to
resolve the group members and forks the message by sending it in a unicast manner to all of the
individual UEs that are associated with the External Group Identifier.
NOTE: In order for the non-IP data to reach each group member UE, each group member UE must have
a PDN connection established to the APN and the SCS/AS must have performed an NIDD Configuration
Procedure for each group member UE. The NIDD configuration must have been performed with the
External Identifier that is associated with External Group Identifier in the UE's subscription
31
5.3. 4.5.14 Non-IP Data Delivery (NIDD)
4.5.14.1 General
Functions for NIDD may be used to handle mobile originated (MO) and mobile terminated (MT)
communication with UEs, where the data used for the communication is considered unstructured from
the EPS standpoint (which we refer to also as Non-IP). The support of Non-IP data is part of the CIoT EPS
optimizations. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:
- Delivery using SCEF;
- Delivery using a Point-to-Point (PtP) SGi tunnel.
The delivery using a Point-to-Point (PtP) SGi tunnel is further described in TS 23.401 [7].
NIDD via the SCEF is handled using a PDN connection to the SCEF. The UE may obtain a Non-IP PDN
connection to the SCEF either during the Attach procedure (see TS 23.401 [7] clause 5.3.2.1) or via UE
requested PDN connectivity (see TS 23.401 [7] clause 5.10.2) or via PDP Context Activation Procedure
(see TS 23.060 [6] clause 9.2.2.1).
NOTE 1: The UE is not made aware that a particular Non-IP PDN connection is provided via SCEF or
via PGW. However, the network informs the UE whether a particular Non-IP PDN connection
uses Control plane CIoT Optimization (see TS 23.401 [7]).
An association between the SCS/AS and a PDN Connection to the SCEF needs to be established to enable
transfer of non-IP data between the UE and the SCS/AS. When the Reliable Data Service is not enabled,
the SCEF determines the association based on provisioned policies that may be used to map an SCS/AS
identity and User identity to an APN. When the Reliable Data Service is enabled, the SCEF determines
the association based on port numbers and provisioned policies that may be used to map SCS/AS
identities and User identity to an APN (see clause 4.5.14.3).
NOTE 2: When more than one SCS/AS is associated with the same PDN Connection, it is permissible
for packets to or from one port number to be associated with more than one SCS/AS. Also,
any polices that are applied to the PDN Connection (e.g. APN Rate Control), apply to traffic
from all of the SCS/AS's that are associated with the PDN Connection.
NIDD via SCEF uses the User Identity, APN, and the SCS/AS identity to identify which UE a particular
T6a/T6b connection belongs to. The User Identity is the user's IMSI. The user's IMSI shall not be used on
the interface between SCEF and SCS/AS. In order to perform NIDD configuration or to send or receive
NIDD data, the SCS/AS shall use MSISDN or External Identifier to identify the user. In order to facilitate
correlation of SCS/AS requests to T6a/T6b connection for a given UE, the HSS provides to the SCEF (see
NIDD Configuration procedure in clause 5.13.2) the user's IMSI, and if available, the MSISDN (when NIDD
Configuration Request contains an External Identifier) or if available, External Identifier (when NIDD
Configuration Request contains an MSISDN).
Depending on operator configuration, the SCEF may perform buffering of MO and/or MT Non-IP data. In
this release of specification, neither the MME/SGSN nor the IWK-SCEF are expecting to buffer data
pertinent to PDN connection to the SCEF.
32
The Protocol Configuration Options (PCO) may be used to transfer parameters between the UE and SCEF
(e.g. maximum packet size). The PCO's information shall be passed transparently through the
MME/SGSN. As specified in TS 23.401 [7] and TS 23.060 [6], the PCO is sent in the EPS Session
Management signalling between UE and MME and in GPRS Session Management signalling between UE
and SGSN.
The SCEF applies rate control as described in TS 23.401 [7] clause 4.7.7.
4.5.14.2 Enhancements for reliable delivery of NIDD

To ensure reliable delivery of Non-IP data (NIDD) between UE and SCEF using the Control Plane CIoT EPS
Optimization, the following functions may be supported by the 3GPP system:
- Reliable delivery by acknowledgements on a hop-by-hop basis, i.e. the link layer protocol on each interface
used for NIDD uses acknowledgments and nodes apply retransmissions if needed to ensure reliable delivery.
- The UE may retransmit UL data that was not acknowledged by the RLC on the AS layer in the UE;
- The MME may retransmit DL data for which it got a non-delivery indication from the eNodeB (see e.g.
TS 23.401 [7], clause 5.3.4B.3, step 15);
- The MME indicates to the SCEF the status of the DL data delivery. The SCEF may forward this status to the
AS;
- Disabling/enabling of MME retransmission is handled by a subscription parameter 'Acknowledgements of

downlink NAS data PDUs'.
4.5.14.3 Reliable Data Service

The Reliable Data Service may be used by the UE and SCEF or P-GW when using PDN Connection of PDN
Type 'Non-IP'. The service provides a mechanism for the SCEF or P-GW to determine if the data was
successfully delivered to the UE and for UE to determine if the data was successfully delivered to the
SCEF. When a requested acknowledgement is not received, the Reliable Data Service retransmits the
packet. The service is enabled or disabled based on APN Configuration per SLA.
When the service is enabled, a protocol is used between the end-points of the Non-IP PDN Connection.
The protocol uses a packet header to identify if the packet requires no acknowledgement, requires an
acknowledgement, or is an acknowledgment and to allow detection and elimination of duplicate PDUs at
the receiving endpoint. Port Numbers in the header are used to identify the application on the originator
and to identify the application on the receiver.
The UE indicates its capability of supporting Reliable Data Service in the Protocol Configuration Options
(PCO) to the SCEF or P-GW. If SCEF or P-GW supports and accepts Reliable Data Service then it indicates
to the UE, in the PCO, that the Reliable Data Service shall be used if enabled in the APN configuration.
In order to prevent situations where a Reliable Data Service instance needs to interface to both the user
and control plane, the Reliable Data Service may only be used with PDN connections for which the
"Control Plane Only" indicator is set or with PDN connections using the Control Plane EPS CIoT
Optimization when the MME does not move PDN connections to the user plane. The Control Plane CIoT
EPS Optimization is defined in TS 23.401 [7].
4.5.16MSISDN-less MO-SMS via T4
33
MSISDN-less MO-SMS via T4 is subscription based. The subscription provides the information whether a
UE is allowed to originate MSISDN-less MO-SMS. Support for subscription without MSISDN is defined in
TS 23.012 [36].
NOTE: This way of communicating small data is considered an intermediate method that will
eventually be replaced by Non-IP Data Delivery (NIDD) procedures.
5.4. 4.6.3 External Group Identifier

A subscription used for MTC may have one or several IMSI-Group Identifier(s) (see TS 23.003 [4]) that are
stored in the HSS.
A subscription may have one or several External Group Identifier(s) that are stored in the HSS. The
External Group Identifier shall be formatted the same as the External Identifier that is described in
clause 4.6.2. The Local Identifier is used to derive or obtain an IMSI-Group Identifier.
The External Group Identifier is used on the interface between the SCS/AS and the SCEF and on the
interface between the SCEF and the HSS. This identifier is used in procedures such as group message
delivery, communication pattern provisioning, and monitoring event configuration and deletion. When
the External Group Identifier is used in the communication pattern provisioning or monitoring event
configuration and deletion procedures, the HSS is able to resolve the External Group Identifier to an
IMSI-Group Identifier. An External Identifier in a UE's subscription may be associated one of the External
Group Identifier(s) in the UE's subscription. The purpose of this association is to enable the SCEF to
determine what External Identifier to use and derive APN from SCS/AS Identifier and the External
Identifier to route non-IP data to the UE when non-IP data is sent to an External Group Identifier.
5.5. 5.5.3 Group Message Delivery via unicast MT NIDD
Figure 5.5.3-1: Group Message Delivery via unicast MT NIDD
1. If SCS/AS has downlink non-IP data to send to a group of UEs, the SCS/AS sends a Group MT NIDD
Submit Request (SCS/AS Identifier, External Group Identifier, TLTRI, TTRI, non-IP data, Reliable Data
Service Configuration, Maximum Latency) message to the SCEF. The SCS/AS may determine the IP
34
address(es)/port(s) of the SCEF by performing a DNS query using the External Group Identifier or using a
locally configured SCEF identifier/address. When non-IP data is sent to an External Group Identifier, the
Reliable Data Service Configuration shall indicate that no reliable data service acknowledgment is requested.
2. The SCEF sends a Group Member List Request (External Group Identifier) to the HSS to request an External
Identifier for each UE.
3. The HSS checks that the SCEF is allowed to resolve the group and sends a Group Member List Response
(External Identifier(s), cause) to provide the SCEF with the list of the individual member IDs that are
associated with the External Group Identifier.
3b. The SCEF sends a single Group MT NIDD Submit Response (TTRI, TLTRI, Cause) message to the SCS/AS
to acknowledge acceptance of the Group MT NIDD Submit Request. The SCEF provides TLTRI associated
with the Group MT NIDD Submit Request.
4. The SCEF performs this step for each External Identifier that was provided to the SCEF in step 3. The SCEF
determines the EPS Bearer Context based on the TLTRI that is associated with the SCS/AS Identifier and the
External Identifier. If an SCEF EPS bearer context corresponding to the External Identifier and SCS/AS
Identifier is found, then the SCEF checks whether the SCS/AS is authorised to send NIDD requests and that
the SCS/AS has not exceeded its rate control quota or rate of data submission to the SCEF EPS bearer. If this
check fails, or if no EPS Bearer Context is found, or if the non-IP packet size is larger than then the
Maximum Packet Size, the SCEF does nothing in this step for this UE and the Cause value that is associated
with this UE and provided to the SCS/AS in step 5 will indicate the reason for the failure condition for each
failed UE. For each UE that passes these checks, the SCEF continues with the flow by executing steps 2-9
(except steps 2b and 5) of the Mobile Terminated NIDD Procedure of clause 5.13.3.
5. After executing step 4 for all UEs, the SCEF sends an aggregated response message Group MT NIDD
Submit Indication (TTRI, TLTRI associated with the Request of step 1, TLTRI(s), Hop-by-Hop
Acknowledgment Indication(s), Re-Transmission time(s), Cause(s)). The Re-Transmission time(s) report, for
UEs that have power saving function and did not receive the MT NIDD message, how long time it will take
before they are reachable. Re-Transmission time(s) are not sent for UEs where transmission was successful.
The SCEF does not buffer the non-IP data further (if applicable) and provides TLTRI(s) associated with the
SCS/AS identifier and the External Identifier for each UE, and also provides a Hop-by-Hop
Acknowledgment Indication, and a Cause value for each UE in the response to the SCS/AS. See
clause 5.13.3 for a description of the Hop-by-Hop Acknowledgment Indication and when it is included.
NOTE: The Re-Transmission time is used to inform the SCS/AS when the UE is expected to become
reachable again, it is the expected wake up time that MME provided to SCEF when delivery
failed for UEs with long sleep time.
5.6. 5.13 Non-IP Data Delivery procedures

5.13.1T6a/T6b Connection Establishment
5.13.1.1 General
When the UE performs the EPS attach procedure (see TS 23.401 [7]) with PDN type of "Non-IP", and the
subscription information corresponding to either the default APN for PDN type of "Non-IP" or the UE
requested APN includes the "Invoke SCEF Selection" indicator, then the MME initiates a T6a/T6b
connection towards the SCEF corresponding to the "SCEF ID" indicator for that APN.
35
5.13.1.2 T6a/T6b Connection Establishment Procedure
Figure 5.13.1.2-1: T6a/T6b Connection Establishment Procedure
1. UE performs steps 1-11 of the E-UTRAN Initial Attach procedure or step 1 of the UE requested PDN
Connectivity procedure (see TS 23.401 [7]) or PDP Context Activation Procedure (see TS 23.060 [6]). The
MME/SGSN receives subscription information for a non-IP PDN connection to an APN that is associated
with an "Invoke SCEF Selection" indicator, and SCEF ID. If the MSISDN is also associated with the user's
subscription, then it is made available as User Identity to the MME/SGSN by the HSS.
2. If the subscription information corresponding to either the default APN for PDN type of "Non-IP" or the UE
requested APN includes "Invoke SCEF Selection" indicator, then instead of step 12-16 of the E-UTRAN
Initial Attach procedure (see TS 23.401 [7]) clause 5.3.2.1) or instead of step 2-6 of the UE requested PDN
connectivity procedure (see TS 23.401 [7] clause 5.10.2) or instead of step 4-8 of the PDP Context Activation
procedure (see TS 23.060 [6] clause 9.2.2.1), the MME/SGSN shall create a PDN connection towards the
SCEF and allocate an EPS Bearer Identity (EBI) (see TS 23.401 [7]) to that PDN connection. The
MME/SGSN does so by sending a Create SCEF Connection Request (User Identity, EPS Bearer Identity,
SCEF ID, APN, Serving PLMN Rate Control, PCO, Serving PLMN ID, IMEISV) message towards the
SCEF (see. TS 23.401 [7], clause 4.7.7). If the IWK-SCEF receives the Create SCEF Connection Request
message from the MME/SGSN, it shall forward it toward the SCEF.
NOTE 1: The combination of EPS Bearer Identity, APN, and User Identity allows the SCEF to uniquely
identify the PDN connection to the SCEF for a given UE.
NOTE 2: For further details of T6a/T6b interactions please refer to Stage 3 specifications.
NOTE 3: The details of how the MME/SGSN and SCEF encode the PCO's information on T6a/T6b are
left to stage 3.
If an SCS/AS has performed the NIDD Configuration procedure (see clause 5.13.2) with the SCEF for User
Identity received in step 2, then step 3 is executed. If no SCS/AS has performed the NIDD Configuration
procedure (see clause 5.13.2) with the SCEF for the User Identity, then the SCEF may:
- reject the T6a/T6b connection setup, or
- initiate a NIDD Configuration procedure with SCS/AS configured in the SCEF using
implementation specific procedures.
For E-UTRAN, if there is a Service Gap timer running in the MME for the UE and the MME is not waiting
for a MT paging response from the UE, the MME does not send a Create SCEF Connection Request but
36
instead rejects the PDN Connectivity Request or the Attach with PDN Connectivity request received from the
UE with an appropriate cause. The MME may also provide UE with a Mobility Management Back-off timer
set to the remaining value of Service Gap timer (see TS 23.401 [7], clause 4.3.17.x).
NOTE 4: The above Service Gap enforcement is for UEs that do not support Service Gap Control. UEs
that do support Service Gap Control will not invoke this procedure when the Service Gap
timer is running in the UE.
3. The SCEF creates an SCEF EPS Bearer Context (see clause 5.3.2) for the user identified via User Identity
and EBI. The SCEF sends a Create SCEF Connection Response (User Identity, EPS Bearer Identity, SCEF
ID, APN, PCO, NIDD Charging ID) message towards the MME/SGSN confirming establishment of the PDN
connection to the SCEF for the UE. If the IWK-SCEF receives the Create SCEF Connection Response
message from the SCEF, it shall forward it toward the MME/SGSN.
5.13.2NIDD Configuration
Figure 5.13.2-1 illustrates the procedure of configuring necessary information at the SCEF and HSS. The
procedure can also be used for replacing and deleting configuration information.
NOTE 1: In order to avoid MO NIDD failure, the NIDD configuration procedure should be performed
by the SCS/AS prior to the UE establishing a PDN Connection that is served by the SCEF. MT
non-IP data from the SCS/AS can be contained in the NIDD Configuration Request message.
Figure 5.13.2-1: Configuration for NIDD procedure
1. The SCS/AS sends an NIDD Configuration Request (External Identifier or MSISDN, SCS/AS Identifier,
TTRI, NIDD Duration, T8 Destination Address, TLTRI, Requested Action, PDN Connection Establishment
Option, Reliable Data Service Configuration) message to the SCEF. T8 Destination Address is an optional
parameter included by the SCS/AS to indicate that the non-IP data is to be delivered to an address different
from the address of the requesting SCS/AS. PDN Connection Establishment Option an optional field that is
used to indicate what the SCEF should do if the UE has not established the PDN connection and MT non-IP
data needs to be sent (wait for the UE to establish the PDN connection, respond with an error cause, or send a
device trigger; see step 2 of the MT NIDD Procedure in clause 5.13.3). When PDN Connection
Establishment Option is included in the Configuration of NIDD procedure, the SCEF will use the value as the
37
default preference from the SCS/AS when handling all MT non-IP packets associated with the NIDD
connection. Reliable Data Service Configuration is an optional parameter that is used to configure the
Reliable Data Service (as defined in clause 4.5.14.3) including port numbers for originator application(s) and
receiver application(s).
When MT non-IP data is included in the NIDD Configuration request message, the SCEF can send the MT
non-IP data to the UE only after a PDN connection to the SCEF is established as defined in clause 5.13.1.2.
In such cases, upon successful completion of step 6 of the NIDD Configuration procedure, steps 2-9 from
clause 5.13.3 are executed. When MT non-IP data is included in the request, the SCS/AS should also provide
the parameters in step 1 of clause 5.13.3 so that the SCEF can properly execute steps 2-9 from clause 5.13.3.
NOTE 2: It is up to the SCS/AS to determine whether and if NIDD Duration can be set to never expire.
NOTE 3: 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.
NOTE 4: A relative priority scheme for the treatment of multiple SCS/AS NIDD Configuration
Requests, e.g. for deciding which requests to serve under overload condition, can be
applied. This priority scheme is an implementation option that is used locally by the SCEF,
i.e. it is neither used nor translated in procedures towards other functions.
NOTE 5: When more than one SCS/AS is associated with a PDN connection, the parameters that are
provided in step 1 can be provisioned in the SCEF based on operator policy or configuration.
In which case, any parameters that are provided in step 1 that conflict with the provisioned
values are ignored.
2. If the Requested Action is set to "Cancel" it indicates the purpose of the request is to cancel the transaction
identified by TLTRI and the flow proceeds to step 6. If the Requested Action is set to "Update", the purpose
of the transaction is to update the parameters associated with the configuration (i.e. Reliable Data Service,
PDN Connection Establishment Option). Otherwise, the request is for a new NIDD configuration and the
SCEF stores the External Identifier or MSISDN, TLTRI, SCS/AS Identifier, T8 Destination Address, PDN
Connection Establishment Option, and NIDD Duration. If either the SCS/AS is not authorized to perform this
request (e.g. based on policies, if the SLA does not allow for it) or the NIDD Configuration Request is
malformed, the SCEF performs step 6 and provides a Cause value appropriately indicating the error.
Depending on the configuration, the SCEF may change the NIDD Duration.
3. The SCEF sends an NIDD Authorization Request (External Identifier or MSISDN, APN) message to the HSS
to authorize the NIDD configuration request for the received External Identifier or MSISDN, and to receive
necessary information for NIDD, if required.
NOTE 6: The SCEF uses the SCS/AS Identifier and External Identifier or MSISDN that was obtained in
step 1 to determine what APN will be used to enable transfer of non-IP data between the
UE and the SCS/AS. This determination is based on local policies.
4. The HSS examines the NIDD Authorization Request message, e.g. with regard to the existence of External
Identifier or MSISDN, maps the external identifier to IMSI and/or MSISDN and updates the SCEF ID field
of the PDN subscription context for the provided APN with the requesting SCEF's ID. If this check fails, the
HSS follows step 5 and provides a result indicating the reason for the failure condition to the SCEF.
5. The HSS sends an NIDD Authorization Response (IMSI and MSISDN or External Identifier, Result)
message to the SCEF to acknowledge acceptance of the NIDD Authorization Request. The IMSI and, if
available, the MSISDN (when NIDD Configuration Request contains an External Identifier) or if available,
External Identifier(s) (when NIDD Configuration Request contains an MSISDN) are returned by the HSS in
this message. This allows the SCEF to correlate the SCS/AS request received in step 1 of this procedure to
the T6a/T6b Connection established (see clause 5.13.1.2) for this user.
38
6. The SCEF sends an NIDD Configuration Response (TTRI, Maximum Packet Size, Reliable Data Service
Indication, and Cause) message to the SCS/AS to acknowledge acceptance of the NIDD Configuration
Request and the deletion of the identified NIDD configuration, if it was requested. If the NIDD Configuration
was accepted, the SCEF will create an association between the TLTRI, External Identifier or MSISDN, IMSI,
and EBI of the non-IP PDN Connection. In the MT NIDD procedure, the SCEF will use TLTRI and External
Identifier or MSISDN to determine the IMSI and EBI of the non-IP PDN Connection. In the MO NIDD
procedure, the SCEF will use the IMSI and EBI to obtain the TLTRI, External Identifier or MSISDN. The
Reliable Data Service Indication indicates if the Reliable Data Service is enabled in the APN configuration.
The Maximum Packet Size is the maximum NIDD packet size that was transferred to the UE by the SCEF in
the PCO, see clause 4.5.14.1. If no maximum packet size was provided to the UE by the SCEF, the SCEF
sends a default configured max packet size to SCS/AS.
5.13.3Mobile Terminated NIDD procedure

Figure 5.13.3-1 illustrates the procedure using which the SCS/AS sends non-IP data to a given user as
identified via External Identifier or MSISDN. This procedure assumes that procedures in clause 5.13.1 is
completed.
Figure 5.13.3-1: Mobile Terminated NIDD procedure
1. If SCS/AS has already activated the NIDD service for a given UE, and has downlink non-IP data to send to
the UE, the SCS/AS sends a MT NIDD Submit Request (External Identifier or MSISDN, TTRI, TLTRI, non-
IP data, Reliable Data Service Configuration, Maximum Latency, Priority, PDN Connection Establishment
Option) message to the SCEF. The Maximum Latency is an optional field that is used to indicate maximum
delay acceptable for downlink data as described in clause 5.6.1.4 and may be used to configure the buffer
duration; a Maximum Latency of 0 indicates that buffering is not allowed. If Maximum Latency is not
provided, the SCEF determines the acceptable delay based on local polices. Priority is an optional field that is
used to indicate the priority of the non-IP data packet relative to other non-IP data packets. If Priority is not
provided, the SCEF determines the acceptable delay based on local polices. Reliable Data Service
Configuration is an optional parameter that is used to configure the Reliable Data Service (as defined in
clause 4.5.14.3); it may be used to indicate if a Reliable Data Service acknowledgment is requested and port
39
numbers for originator application and receiver application. PDN Connection Establishment Option an
optional field that is used to indicate what the SCEF should do if the UE has not established the PDN
connection (wait for the UE to establish the PDN connection, respond with an error cause, or send a device
trigger; see step 2). If PDN Connection Establishment Option is not provided with the non-IP packet, the
SCEF uses the PDN Connection Establishment Option that was provided during NIDD Configuration to
decide how to handle the absence of a PDN connection. If an MT NIDD Submit Request is received with
non-IP data and a TTRI that is equal to a request that is already buffered, then the buffered data is replaced. If
an MT NIDD Submit Request is received with no non-IP data and a TTRI that is equal to a request that is
already buffered, then the buffered data is purged.
2. The SCEF determines the EPS Bearer Context based on the APN associated with the NIDD configuration
and the User Identity. If an SCEF EPS bearer context corresponding to the External Identifier or MSISDN
included in step 1 is found, then the SCEF checks whether the SCS/AS is authorised to send NIDD requests
and that the SCS/AS has not exceeded the quota (e.g. 200 bytes in 24hrs) or rate (e.g. 10 bytes / hour) of data
submission to the SCEF EPS bearer. When determining the quota and the rate of data submissions, the SCEF
considers the APN Rate Control pre-configured in the SCEF and the Serving PLMN Rate Control parameter
that was received from MME during the T6a/b connection establishment. The SCEF considers already
buffered data during the check of whether the quota or the rate was exceeded. If the SCEF receives additional
NIDD request(s) while already buffering data, the SCEF considers the non-IP data priority when checking the
quota and the rate and deciding whether to buffer the additional non-IP data. If this check is successful and
SCEF buffers the additional non-IP data, the SCEF continues with step 5. If this check fails or if the non-IP
packet size is larger than then the Maximum Packet Size that was provided to the SCS/AS during NIDD
Configuration, the SCEF sends a MT NIDD Submit Response (TTRI, Cause) with a cause value indicating
the reason for the failure condition and the flow stops at this step. Otherwise, the flow continues with step 3.
If no SCEF EPS bearer context is found, then the SCEF, depending on PDN Connection Establishment
Option, may either:
- send a MT NIDD Submit Response (TTRI, Cause) with appropriate error cause value. The flow
stops at this step; or
- perform device triggering towards the UE to establish a PDN Connection of type Non-IP to the
default APN by using T4 SMS device triggering to a pre-defined SMS Application Port ID (refer
to clause 5.2.2). In this case, the SCEF sends a MT NIDD Submit Response (TTRI, Buffered
Indication, Trigger Indication, cause) with an appropriate cause value. The Buffered Indication
indicates if the SCEF buffered the non-IP data. The Trigger Indication is used to indicate that a
trigger was sent in order to establish the PDN connection. If data is not buffered, the flow stops
at this step, otherwise, it proceeds to step 6. The SCEF may use Priority to configure the priority
of the device trigger and may use Maximum Latency to configure the validity period of the
device trigger; or
NOTE 1: It is left to stage 3 to reserve the SMS Application Port ID number that will be used to carry
the trigger to the UE to indicate that the UE should establish a PDN Connection of type Non-
IP to the default APN.
- accept the MT NIDD Submit Request, and execute step 5 with an appropriate cause value, and
wait for the UE to perform a procedure (see TS 23.401 [7]) causing the establishment of a PDN
connection to the SCEF (see clause 5.13.1.2). If data is not buffered, the flow stops at step 5.
NOTE 2: The duration for which the SCEF may wait for establishment of a PDN connection to the
SCEF for the given UE is implementation dependent.
3. If an SCEF EPS bearer context corresponding to the External Identifier or MSISDN included in step 1 is
found, then the SCEF sends a NIDD Submit Request (User Identity, EPS Bearer ID, SCEF ID, non-IP data,
40
SCEF Wait Time, Maximum Re-transmission time) message toward the MME/SGSN. SCEF Wait Time
indicates how long the SCEF is prepared to wait for MME/SGSN response. Maximum Re-transmission
indicates how long the SCEF is prepared to re-transmit the message.
If the IWK-SCEF receives a NIDD Submit Request message from the SCEF, it relays the message to the
MME/SGSN.
4. If the MME/SGSN can immediately deliver the non-IP data to the UE e.g. when UE is already in
ECM_CONNECTED mode, or UE is in ECM_IDLE and MME/SGSN is able to initiate paging procedure
(see TS 23.401 [7]), the procedure proceeds at step 8.
If the MME/SGSN is aware of the UE being temporarily unreachable, or if the MME/SGSN knows that the
UE is not scheduled to be reachable within the SCEF Wait Time, while using power saving functions e.g. UE
Power Saving Mode (see clause 4.5.4) or extended idle mode DRX (see clause 4.5.13), then the MME/SGSN
may send a NIDD Submit Response (Cause, Requested Re-Transmission Time) message towards the SCEF.
The Cause parameter indicates that Non-IP data was not delivered to the UE, as the UE is temporarily not
reachable due to power saving but the MME/SGSN will notify the SCEF when the MME/SGSN determines
the UE is reachable. The MME/SGSN sets the Not Reachable for NIDD flag in the EMM context for this UE
and stores the corresponding SCEF address. If the Maximum Re-transmission Time was included in the
Request, the MME may indicate in Requested Re-Transmission time IE the time when the SCEF is expected
to re-transmit the DL data to the currently unreachable UE.
5. The SCEF may send a MT NIDD Submit Response (TTRI, Requested Re-Transmission time, Cause) to the
SCS/AS informing of the received results from the MME/SGSN. If the SCEF receives from the MME/SGSN
a Cause value indicating that UE is temporarily not reachable due to power saving, the SCEF can buffer the
non-IP data requested at step 3 based on the configuration and proceed to step 6. If, in step 2, the SCEF
buffered the non-IP data and is waiting for the UE to establish a PDN connection, then the SCEF proceeds to
step 7 after T6a Connection Establishment. The Requested Re-Transmission tells the SCS/AS when the
SCEF is expected to re-transmit the DL data to the currently unreachable UE.
6. When the MME/SGSN detects that the UE is reachable (e.g. when coming out of PSM mode by performing
TAU/RAU, when initiating MO communication etc.), or when the UE is about to become reachable (e.g.
extended idle mode DRX cycle expiring, MME/SGSN anticipating MO communication pattern for the UE
etc.), and the MME/SGSN has the Not Reachable for NIDD flag set, then the MME/SGSN sends a NIDD
Submit Indication (User Identity) message towards the SCEF. The MME/SGSN clears the Not Reachable for
NIDD flag from its EMM context.
If the MME included the Requested Re-transmission-Time in the NIDD Submit Response, the MME sends a
NIDD Submit Indication (User Identity) message towards the SCEF only if the UE becomes reachable before
the Requested Re-transmission Time. The MME shall clear the Not Reachable for NIDD flag when the
Requested Re-transmission Time expires and the UE has not become reachable yet.
If the MME/SGSN sends the NIDD Submit Request message towards the SCEF as described in clause 5.13.4
or an Update Serving Node Information Request message towards the SCEF as described in clause 5.13.6,
then the MME/SGSN clears the Not Reachable for NIDD flag from its EMM context, but it need not send the
NIDD Submit Indication message. If the SCEF receives the NIDD Submit Request message or an Update
Serving Node Information Request from the MME/SGSN for this UE, the SCEF may consider it an implicit
NIDD Submit Indication, and proceed with step 7.
7. If the data has not been purged, the SCEF sends a NIDD Submit Request (User Identity, EPS Bearer ID,
SCEF ID, non-IP data, SCEF Wait Time, Maximum Re-transmission time) message toward the MME/SGSN.
8. If required, the MME/SGSN pages the UE and delivers the non-IP data to the UE using data transfer via the
MME procedure as described in clause 5.3.4B.3 of TS 23.401 [7] or the SGSN procedure as described in
clauses 9.3 and 9.6 of TS 23.060 [6]. Depending on operator configuration, the MME/SGSN may generate
the necessary accounting information required for charging.
41
9. If the MME/SGSN was able to initiate step 8, then the MME/SGSN sends a NIDD Submit Response (cause)
message towards the SCEF acknowledging the NIDD Submit Request from SCEF received in step 3 or
step 7. If the eNodeB supports acknowledgements of downlink NIDD delivery and if acknowledgements of
downlink NAS data PDUs are enabled in the subscription information for the UE and the eNodeB has
acknowledged successful delivery to the MME/SGSN (see TS 23.401 [7], clause 5.3.4B.3), the cause is set to
'Success Acknowledged Delivery' otherwise 'Success Unacknowledged Delivery'. If the delivery failed, the
cause is 'Unsuccessful delivery'.
If Reliable Data Service header indicates that acknowledgement is requested, then the UE shall respond with
an acknowledgement to the DL data that was received in step 8 following the Mobile Originated NIDD
Procedure in clause 5.13.4, steps 1 - 2 and 5.
NOTE 3: The 'Success Acknowledged Delivery' implies reliable delivery to the UE using RLC
acknowledged mode. The 'Success Unacknowledged Delivery' result does not imply the data
is successfully received at the UE, but just the MME/SGSN has sent the non-IP data in NAS
signalling to the UE. If the UE sends UL data in response to the received DL data in step 8,
then it follows the Mobile Originated NIDD Procedure in clause 5.13.4.
10. The SCEF sends an MT NIDD Submit Response (TTRI, Reliable Data Service Acknowledgement Indication,
Hop-by-Hop Acknowledgment Indication, Cause). The Reliable Data Service Acknowledgement Indication
is used to indicate if an acknowledgement was received from the UE for the MT NIDD. If the Reliable Data
Service was requested in step 1, then the MT NIDD Submit Response is sent to the SCS/AS after the
acknowledgement is received from the UE or, if no acknowledgment is received, then the MT NIDD Submit
Response is sent to the SCS/AS with a cause value indicating that no acknowledgement was received. When
the Reliable Data Service was not requested in step 1, the Hop-by-Hop Acknowledgment Indication may be
sent to the SCS/AS indicating the result of the Hop-by-Hop acknowledgment with a value of 'Success
Acknowledged Delivery', 'Success Unacknowledged Delivery' or 'Unsuccessful delivery'.
5.13.4Mobile Originated NIDD procedure
Figure 5.13.4-1: Mobile Originated NIDD procedure
1. The UE sends a NAS message with EPS bearer ID and non-IP data, the Reliable Data Service header is
included if the Reliable data service is enabled, to the MME as per the procedure described in clause 5.3.4B.2
of TS 23.401 [7] (steps 0 - 2) or the UE sends data to the SGSN (see clause 9.3 and 9.6 of TS 23.060 [6]) on a
PDP Context of PDN type Non-IP associated with a T6b interface.
2. The MME/SGSN sends NIDD Submit Request (User Identity, EBI, SCEF ID, non-IP data, MO Exception
data counter) message to the SCEF. In the roaming case, the MME/SGSN sends the message to the IWK-
SCEF which forwards the message to the SCEF over T7. The MME only includes the MO Exception data
42
counter if the RRC establishment cause is set to "MO exception data" and the UE is accessing via the NB-IoT
RAT. The MME maintains the MO Exception Data Counter and sends it to the SCEF as described in
TS 29.128 [37].
For E-UTRAN, if there is a Service Gap timer running in the MME for the UE and the MME is not waiting
for a MT paging response from the UE, the MME does not send a NIDD Submit Request but instead rejects
the request by discarding the NAS data PDU received from the UE and sends a Service Reject message to the
UE with an appropriate cause. The MME may also provide UE with a Mobility Management Back-off timer
set to the remaining value of Service Gap timer (see TS 23.401 [7], clause 4.3.17.9).
NOTE 1: The above Service Gap enforcement is for UEs that do not support Service Gap Control. UEs
that do support Service Gap Control will not invoke this procedure when the Service Gap
timer is running in the UE.
3. When the SCEF receives the non-IP data on the T6a/T6b (or T7) interface, and finds an SCEF EPS bearer
context and the related T8 Destination Address, then it sends the non-IP data to the SCS/AS that is identified
by the T8 Destination address in a MO NIDD Indication (External Identifier or MSISDN, non-IP data, TTRI,
TLTRI, Reliable Data Service Configuration). The Reliable Data Service Configuration is used to provide the
SCS/AS with additional information when the Reliable Data Service (as defined in clause 4.5.14.3) is
enabled (e.g. indicate if an acknowledgement was requested and port numbers for originator application and
receiver application). If no SCS/AS address or T8 Destination address is associated with the UE's PDN
connection, the data is discarded, MO NIDD Indication is not sent, and the flow continues at step 5.
NOTE 2: It is left to stage 3 whether or not the SCEF aggregates MO NIDD Indication messages to the
SCS/AS.
4. The SCS/AS responds to the SCEF with a MO NIDD Acknowledgement (TTRI, Cause).
5. The SCEF sends NIDD Submit Response to MME/SGSN. In the roaming case, the SCEF sends the message
to the IWK-SCEF over T7 and the IWK-SCEF forwards the message to the MME/SGSN over T6a/T6b. If the
SCEF cannot deliver the data, e.g. due to missing SCS/AS configuration, the SCEF sends an appropriate
error code to the MME/SGSN. If the Reliable Data Service is enabled in the APN configuration and the non-
IP packet indicates that an acknowledgment is requested, then the SCEF follows the Mobile Terminated
NIDD Procedure in clause 5.13.3, steps 3-9.
NOTE 3: If the SCS/AS has Downlink data to send (e.g. an application level acknowledgement for the
NIDD delivery), it follows the Mobile Terminated NIDD Procedure in clause 5.13.3.
5.7. 5.13.6 Serving node relocation procedure over T6a/T6b

5.13.6.1 General
Mobility may happen with respect to a non-IP PDN connection via the SCEF as a result of a TAU/RAU
procedure. The following procedures apply:
- Successful TAU/RAU on a new MME/SGSN,
- Failed TAU/RAU.
5.13.6.2 Successful TAU/RAU procedure with T6a/T6b

The procedure in Figure 5.13.6.2-1 applies when a T6a/T6b PDN/PDP connection exists for a UE that
executes a successful TAU procedure to a new MME or a successful RAU procedure to a new SGSN.
43
Figure 5.13.6.2-1: T6a/T6b and successful TAU/RAU procedure
1. UE performs a successful TAU/RAU procedure (see TS 23.401 [7] and TS 23.060 [6]) and the new
MME/SGSN receives subscription information for a non-IP PDN/PDP connection to an APN that is
associated with an "Invoke SCEF Selection" indicator and an associated SCEF ID.
2. If the subscription information corresponding to either the default APN for PDN type of "Non-IP" or the UE
requested APN includes "Invoke SCEF Selection" indicator, then the new MME/SGSN shall create a
PDN/PDP connection to the SCEF or to the IWK-SCEF, using the already allocated EBI. As for the "T6a/T6b
Connection Establishment Procedure", clause 5.13.1.2, the new MME/SGSN does so by sending an Update
Serving Node Information Request (User Identity, EPS Bearer Identity, SCEF ID, APN, Serving PLMN ID,
IMEISV) message towards the SCEF. If the SCEF received the Reachable for NIDD flag for the UE from old
MME/SGSN but has yet to receive the NIDD Submit Indication message from the old MME/SGSN, and the
SCEF has buffered the Non-IP data, then the SCEF may execute the procedure in clause 5.13.3 starting at
step 7.
If the IWK-SCEF receives the Update Serving Node Information Request message from the MME/SGSN, it
shall forward it to the SCEF.
3. The SCEF creates an SCEF EPS Bearer Context (see clause 5.3.2) for the user identified via User Identity.
The SCEF sends Update Serving Node Information Response (User Identity, EPS Bearer Identity, SCEF ID,
Cause, NIDD Charging ID) message toward the MME/SGSN confirming establishment of the PDN
connection to the SCEF for the UE. If the IWK-SCEF receives the Update Serving Node Information
Response message from the SCEF, it shall forward it to the MME/SGSN.
5.8.
44

Scoping NIDD

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Scoping NIDD

Caricato da

Copyright:

Formati disponibili

Scoping NIDD

1.1. E-UTRAN Initial Attach

Without SGW change

1.3. Data Transport in Control Plane CIoT EPS optimization

1.4. Handover S1 based

1.5. Throttling of NIDD Submit Requests

1.5.1. Support for Non-IP Data Delivery (NIDD)

- Delivery using a Point-to-Point (PtP) SGi tunnel as defined in clause 4.3.17.8.3.3.

Dedicated bearers are not supported for the Non-IP data.

4.3.17.8.2 ESM Procedures

4.3.17.8.3 Delivery mechanism

NOTE: An AS can be dedicated for handling a specific Non-IP data protocol.

1.6. 4.3.5.10Preferred and Supported Network Behaviour

4.3.8.1 PDN GW selection function (3GPP accesses)

UE support for multiple PDN connections is optional.

1.8. 5.10.2 UE requested PDN connectivity

- User plane CIoT EPS optimization for small data transmission.

- Necessary security procedures for efficient small data tranmission.

- SMS without combined attach for NB-IoT only UEs.

- Paging optimisations for coverage enhancements.

3.1. 5.3.15 CIoT EPS optimizations

3.2. 5.5.1.2.2 Attach procedure initiation

3.3. 5.5.3 Tracking area updating procedure (S1 mode only)

5.5.3.2.2 Normal and periodic tracking area updating procedure initiation

- for the case s; and

- if the UE has established PDN connection(s) of "non IP" PDN type.

3.4. 5.6 EMM connection management procedures (S1 mode only)

5.6.1 Service request procedure

b) the UE, in EMM-IDLE mode, has pending user data to be sent;

3.4.1. For case b in subclause 5.6.1.1,

3.4.2. For cases b and m in subclause 5.6.1.1,

3.5. 6.Elementary procedures for EPS session management

6.2.2 IP address allocation via NAS signalling

6.4.1.3 Default EPS bearer context activation accepted by the UE

6.5.1.2 UE requested PDN connectivity procedure initiation

6.5.1.4 UE requested PDN connectivity procedure not accepted by the network

- the PDN type which is used to access to the APN is changed;

- the UE is switched off; or

- the USIM is removed.

6.6.4.2 UE initiated transport of user data via the control plane

3.6.1. 8.3.14 ESM information response

8.3.14.3 Protocol configuration options

8.3.14.4 Extended protocol configuration options

8.3.19 PDN connectivity reject

Table 8.3.19.1: PDN CONNECTIVITY REJECT message content

8.3.19.5 Extended protocol configuration options

8.3.20 PDN connectivity request

8.3.20.4 Protocol configuration options

8.3.20.8 Extended protocol configuration options

Figure 9.9.4.9.1: PDN address information element

Table 9.9.4.9.1: PDN address information element

All other values are reserved.

Bit 4 to 8 of octet 3 are spare and shall be coded as zero.

PDN address information (octet 4 to 15)

The PDN type is a type 1 information element.

Table 9.9.4.10.1: PDN type information element

All other values are reserved.

Bit 4 of octet 1 is spare and shall be coded as zero.

B.1 Causes related to nature of request

Cause #58 – PDN type non IP only allowed

4.1. 10.5.6.3 Protocol configuration options

Figure 10.5.136/3GPP TS 24.008: Protocol configuration options information element

- the Configuration protocol options list (octets 4 to w), and

- the Additional parameters list (octets w+1 to z).