Content for &nbsp; TS 23.682 &nbsp; Word version:&nbsp; 18.0.0

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) or PDP Context Activation Procedure (see TS 23.060). 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.

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 clause 5.3.2.1 of TS 23.401)) or instead of step 2-6 of the UE requested PDN connectivity procedure (see clause 5.10.2 of TS 23.401) or instead of step 4-8 of the PDP Context Activation procedure (see clause 9.2.2.1 of TS 23.060), the MME/SGSN shall create a PDN connection towards the SCEF and allocate an EPS Bearer Identity (EBI) (see TS 23.401) 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 clause 4.7.7 of TS 23.401). If the IWK-SCEF receives the Create SCEF Connection Request message from the MME/SGSN, it shall forward it toward the SCEF.

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 provided by the MME, the SCEF may take the APN Rate Control Status into account when encoding the APN Rate Control parameters in Protocol Configuration Options and when enforcing the APN Rate Control as described in clause 4.7.7.3 of TS 23.401.

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.2 NIDD Configuration p. 104

Figure 5.13.2-1 illustrates the procedure of configuring necessary information at the SCEF and HSS. A NIDD Configuration is associated with a single UE or a group of UEs. The procedure can also be used for replacing and deleting configuration information.

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.2-1: Configuration for NIDD procedure

Figure 5.13.2-1: Configuration for NIDD procedure
(⇒ copy of original 3GPP image)

The SCS/AS sends an NIDD Configuration Request (External Group Identifier or External Identifier or MSISDN, SCS/AS Identifier, NIDD Duration, T8 Destination Address, TLTRI, Requested Action, PDN Connection Establishment Option, Reliable Data Service Configuration, MTC Provider Information) message to the SCEF. PDN Connection Establishment Option an optional field that is used to indicate what the SCEF should do if the UE, or group member UEs, 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 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) and the mobile terminated and mobile originated serialization format(s) that are supported by the SCS/AS for each port number. TLTRI is included in the request if the Requested Action is set to "Update" or "Cancel", otherwise TLTRI is not included in the request and the SCEF assigns a TLTRI to the NIDD Configuration.

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. MT non-IP data shall not be included in the NIDD Configuration Request when the procedure is performed on an External Group Identifier.

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 Group Identifier, 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.

The SCEF sends an NIDD Authorization Request (External Group Identifier or External Identifier or MSISDN, APN, MTC Provider Information) message to the HSS to authorize the NIDD configuration request for the UEs that belongs to the External Group Identifier, received External Identifier or MSISDN, and to receive necessary information for NIDD, if required.

The HSS examines the NIDD Authorization Request message, e.g. with regards to the existence of External Group Identifier, External Identifier or MSISDN. If an External Identifier was included in the NIDD Authorization Request, the HSS 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. Otherwise, if an External Group Identifier was included in the NIDD Authorization Request, the HSS authorizes the NIDD configuration request for the received External Group Identifier, resolves the External Group Identifier to an IMSI-Group Identifier and an External Identifier and/or MSISDN for each of the IMSIs in the IMSI-Group. If this check fails, the HSS follows step 5 and provides a result indicating the reason for the failure condition to the SCEF. If the SCEF ID is different from the one in the PDN subscription contexts for the provided APN, the HSS updates the SCEF ID at the MME/SGSN for the provided APN. If this update fails, the HSS follows step 5 and provides a result indicating the reason for the failure condition to the SCEF.

Step 5.

The HSS sends an NIDD Authorization Response (with single value or list of (IMSI and MSISDN or External Identifier), Result) message to the SCEF to acknowledge acceptance of the NIDD Authorization Request. If the HSS determines that the list size exceeds the message capacity, the HSS shall segment the list and send it in multiple messages (for details on segmentation, see TS 29.336). The IMSI(s) and, if available, the MSISDN(s) (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 each UE or each group member UE.

Step 6.

The SCEF sends an NIDD Configuration Response (TLTRI, 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 Group Identifier or 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 Group Identifier or External Identifier or MSISDN to determine the IMSI(s) and EBI(s) of the non-IP PDN Connection(s). In the MO NIDD procedure, the SCEF will use the IMSI(s) and EBI(s) 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.3 Mobile Terminated NIDD procedure p. 106

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.

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.3-1: Mobile Terminated NIDD procedure

Figure 5.13.3-1: Mobile Terminated NIDD procedure
(⇒ copy of original 3GPP image)

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, TLTRI, non-IP data, non-IP data sequence number, 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 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 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. Non-IP data sequence number is an optional field that refers to earlier MT NIDD requests, it is only included if the purpose of the MT NIDD Submit Request is to replace or purge data that is buffered in the SCEF. If an MT NIDD Submit Request is received with non-IP data and a non-IP data sequence 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 non-IP data sequence that is equal to a request that is already buffered, then the buffered data is purged.

The Maximum Latency Parameter provided by the SCS/AS in this procedure is only used by the SCEF to determine the maximum acceptable delay for associated non-IP data and is not propagated further by the SCEF.

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 (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 (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 (non-IP data sequence, Buffered Indication, Trigger Indication, cause) with an appropriate cause value. The Buffered Indication indicates if the SCEF buffered the non-IP data. The non-IP data sequence number is assigned by the SCEF and may be used by the SCS/AS to overwrite or purge the buffered data at a later time. 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) 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.

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, 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.

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), 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.

Step 5.

The SCEF may send a MT NIDD Submit Response (Requested Re-Transmission time, non-IP data sequence number, Buffered Indication, 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. The Buffered Indication indicates if the SCEF buffered the non-IP data. The non-IP data sequence number is assigned by the SCEF and may be used by the SCS/AS to overwrite or purge the buffered data at a later time. 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.

Step 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.

Step 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.

Step 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 or the SGSN procedure as described in clauses 9.3 and 9.6 of TS 23.060. Depending on operator configuration, the MME/SGSN may generate the necessary accounting information required for charging.

Step 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 see clause 5.3.4B.3 of TS 23.401), 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.

Step 10.

The SCEF sends an MT NIDD Submit Response (Reliable Data Service Acknowledgement Indication, Hop-by-Hop Acknowledgment Indication, non-IP data sequence number, 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.4 Mobile Originated NIDD procedure p. 109

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.4-1: Mobile Originated NIDD procedure

Figure 5.13.4-1: Mobile Originated NIDD procedure
(⇒ copy of original 3GPP image)

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 (steps 0 - 2) or the UE sends data to the SGSN (see clause 9.3 and 9.6 of TS 23.060) on a PDP Context of PDN type Non-IP associated with a T6b interface.

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 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.

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, 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 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.

The SCS/AS responds to the SCEF with a MO NIDD Acknowledgement (Cause).

Step 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.

5.13.5 T6a/T6b Connection Release p. 110

5.13.5.1 General p. 110

The MME releases the T6a connection(s) towards the SCEF(s) corresponding to the "SCEF ID" indicator for that APN in the following cases:

UE-initiated Detach procedure for E-UTRAN, or
MME-initiated Detach procedure, or
the HSS-initiated Detach procedure, or
UE or MME requested PDN disconnection procedure.

The SGSN releases the T6b connection(s) towards the SCEF(s) corresponding to the "SCEF ID" indicator for that APN in the following cases:

Detach Procedures (see clause 6.6 of TS 23.060), or
MS and network initiated PDP Deactivation Procedures (see clause 9.2.4 of TS 23.060).

The SCEF releases the T6a/b connection(s) towards the MME/SGSN corresponding to PDN connections in the following cases:

when an NIDD Authorization Update Request from the HSS indicates that the User is no longer authorized for NIDD, or
failure of SCEF or failure of SCS/AS connection, or
based on a request from the SCS/AS, or
based on removal of the APN associated with the T6a/b connection from the SCEF.

5.13.5.2 MME/SGSN Initiated T6a/T6b Connection Release procedure p. 111

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.5.2-1: MME/SGSN Initiated T6a/T6b Connection Release procedure

Figure 5.13.5.2-1: MME/SGSN Initiated T6a/T6b Connection Release procedure
(⇒ copy of original 3GPP image)

The UE performs step 1 of the UE-initiated Detach procedure for E-UTRAN (see clause 5.3.8.2.1 of TS 23.401), or the MME performs the MME-initiated Detach procedure (see clause 5.3.8.3 of TS 23.401), or the HSS performs step 1a of the HSS-initiated Detach procedure (see clause 5.3.8.4 of TS 23.401), or the UE/MME performs steps 1a-1b of the UE or MME requested PDN disconnection procedure (see clause 5.10.3 of TS 23.401), or a Detach Procedure specified in clause 6.6 of TS 23.060 is performed, or an MS or network initiated Deactivation Procedure specified in clause 9.2.4 of TS 23.060 is performed, for which the PDN/PDP connection to an SCEF exists.

If the MME/SGSN has an active EPS bearer context(s) or PDP Context(s) corresponding to the PDN/PDP connection to the SCEF(s), then for each active EPS bearer context/PDP Context, the MME/SGSN sends a Delete SCEF Connection Request (User Identity, EPS Bearer Identity, SCEF ID, APN) message towards the SCEF. The MME/SGSN deletes the EPS bearer context/PDP Context corresponding to the PDN connection.

The SCEF sends a Delete SCEF Connection Response (User Identity, EPS Bearer Identity, SCEF ID, APN, PCO) message towards the MME/SGSN indicating acceptance of the removal of SCEF Connection information for the UE. The SCEF deletes the SCEF EPS bearer context corresponding to the PDN connection.

If the last PDN Connection of a given APN is being released, the SCEF may send to the MME the current APN Rate Control Status (see clause 4.7.7.3 of TS 23.401). The MME stores it in the MM context.

5.13.5.3 SCEF Initiated T6a/T6b Connection Release procedure |R14| p. 112

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.5.3-1: SCEF Initiated T6a/T6b Connection Release procedure

Figure 5.13.5.3-1: SCEF Initiated T6a/T6b Connection Release procedure
(⇒ copy of original 3GPP image)

An NIDD Authorization Update request from the HSS indicates that the User is no longer authorized for NIDD, the SCS/AS indicates that the User's NIDD PDN connection is no longer needed, or the SCEF determines that it is needs to release a T6a/b connection.

The SCEF sends a Delete SCEF Connection Request (User Identity, EPS Bearer Identity, SCEF ID) message towards the MME/SGSN. The SCEF deletes the SCEF EPS bearer context corresponding to the PDN connection.

If the last PDN Connection of a given APN is being released, the SCEF may send to the MME the APN Rate Control Status (see clause 4.7.7.3 of TS 23.401). The MME stores it in the MM context.

The MME/SGSN sends a Delete SCEF Connection Response (User Identity, EPS Bearer Identity, SCEF ID, APN) message towards the SCEF acknowledging the removal of SCEF Connection information for the UE. The MME/SGSN deletes the EPS bearer context/PDP Context corresponding to the PDN connection.

The MME may perform the MME-initiated Detach procedure (see clause 5.3.8.3 of TS 23.401), or step 1b of the UE or MME requested PDN disconnection procedure (see clause 5.10.3 of TS 23.401). An SGSN may perform SGSN-Initiated Detach Procedure specified in clause 6.6.2.1 of TS 23.060, or a network initiated Deactivation Procedure specified in clause 9.2.4 of TS 23.060, for which the PDN/PDP connection to an SCEF exists.

5.13.6 Serving node relocation procedure over T6a/T6b p. 112

5.13.6.1 General p. 112

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 p. 113

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.

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.6.2-1: T6a/T6b and successful TAU/RAU procedure

Figure 5.13.6.2-1: T6a/T6b and successful TAU/RAU procedure
(⇒ copy of original 3GPP image)

UE performs a successful TAU/RAU procedure (see TS 23.401 and TS 23.060) 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.

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.

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.13.7 Void

5.13.8 NIDD Authorisation Update |R14| p. 113

Figure 5.13.8-1 illustrates the procedure of updating or revoking an existing NIDD Authorisation. The HSS may initiate the NIDD Authorisation Update procedure with the SCEF to send updated Authorisation information to the SCEF.

Copy of original 3GPP image for 3GPP TS 23.682, Fig. 5.13.8-1: NIDD Authorisation Update procedure

Figure 5.13.8-1: NIDD Authorisation Update procedure
(⇒ copy of original 3GPP image)

The HSS may send an NIDD Authorisation Update Request (IMSI and MSISDN or External Identifier, APN, Result) message to the SCEF to update a user's NIDD authorisation. The HSS shall include in the NIDD Authorisation Update Request the IMSI and either MSISDN or External Identifier or both. The SCEF initiates the SCEF Initiated T6a/T6b Connection Release Procedure.

The SCEF sends an NIDD Authorisation Update Response (cause) message to the HSS to acknowledge the authorisation update. If the authorisation is removed, the SCEF should release T6a/T6b connection as specified in clause 5.13.5.3.

The SCEF informs the SCS/AS that the User's authorisation status has changed by sending an NIDD Authorisation Notification Request (External Identifier or MSISDN, TLTRI, Result) message to the SCS/AS.