5 Services offered by the NEF for NIDD and SMS

29.5413GPP5G SystemNetwork Exposure (NE) function services for Non-IP Data Delivery (NIDD) and Short Message Services (SMS)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

The table 5.1-1 shows the NEF Services and Service Operations for NIDD and SMS:

Table 5.1-1 List of NEF Services for NIDD and SMS

Service Name	Service Operations	Operation Semantics	Example Consumer(s)	Mapped Service Operation
Nnef_SMContext	Create	Request/Response	SMF	Nnef_SMContext_Create
	Delete	Request/Response	SMF	Nnef_SMContext_Delete
	Status Notify	Subscribe/Notify	SMF	Nnef_SMContext_DeleteNotify (NOTE)
	Update	Request/Response	SMF
	Delivery	Request/Response	SMF	Nnef_SMContext_Delivery
Nnef_SMService	MoForwardSm	Request/Response	SMS-SC	Nnef_SMService_MoForwardSm
NOTE: The Status Notify service operation models the Nnef_SMContext_DeleteNotify service operation specified in 3GPP TS 23.502 [3] (see clause 5.2.2.4.2).

Table 5.1-2 summarizes the corresponding APIs defined for this specification.

Table 5.1-2: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
Nnef_SMContext	6.1	Nnef SMContext Service	TS29541_Nnef_SMContext.yaml	nnef-smcontext	A.2
Nnef_SMService	6.2	Nnef SMService Service	TS29541_Nnef_SMService.yaml	nnef-smservice	A.3

5.2 Nnef_SMContext Service

5.2.1 Service Description

The service allows a NF to manage the SM Contexts on NEF for NIDD. A NF as service consumer (e.g. SMF) can create, update or release SM Contexts for NIDD on NEF. A created SM Context for NIDD may also be released by NEF.

5.2.2 Service Operations

5.2.2.1 Introduction

The Nnef_SMContext service supports following service operations:

– Create

– Delete

– StatusNotify

– Update

– Deliver

5.2.2.2 Create Service Operation

5.2.2.2.1 General

The Create service operation is used during the following procedure:

– SMF-NEF Connection Establishment procedure (see 3GPP TS 23.502 [3], clause 4.25.2)

The Create service operation is invoked by a NF Service Consumer (e.g. a SMF) towards the NEF, when the SMF received a PDU Session establishment request from the UE with PDU Session type of "Unstructured", and the subscription information corresponding to the UE requested DNN includes the "NEF Identity for NIDD". There shall be only one individual SM context per PDU session.

The NF Service Consumer (e.g. the SMF) shall create the SM Context for NIDD on NEF by sending the HTTP POST request towards the SM Contexts Collection resource as shown in Figure 5.2.2.2.1-1.

Figure 5.2.2.2.1-1: Create Service Operation

1. The NF Service Consumer shall send a POST request to the resource representing the SM Contexts Collection resource of the NEF with a "SmContextCreateData" object in request body, including:

– SUPI of the UE;

– PDU session ID;

– S-NSSAI associated with the PDU session;

– DNN of the PDU session;

– NIDD information, such as GPSI, AF ID, etc.;

– NEF ID, indicating the provisioned identity for NIDD service;

– URI of the Individual PDU session resource for downlink data delivery (see clause 6.1.3.2 of 3GPP TS 29.542 [17]);

– Notification URI to receive the SM Context notifications;

– optionally the indication of UE capability to support Reliable Data Service (RDS);

– optionally the configuration parameters, e.g. serving PLMN rate control, small data rate control, etc.;

– optionally small data rate control status, if small data rate control is previously enabled and to be resumed

2a. On success, "201 Created" shall be returned and the "Location" header shall be present and shall contain the URI of the created Individual SM Context resource.

The payload body of the POST response shall contain a "SmContextCreatedData" object, including:

– SUPI of the UE;

– PDU session ID;

– S-NSSAI associated with the PDU session;

– DNN of the PDU session;

– NEF ID, indicating the provisioned identity for NIDD service;

– optionally the indication of NEF capability to support Reliable Data Service (RDS);

– optionally the indication of NEF capability to support Extended Buffering;

– optionally Maximum Packet Size in bytes for NIDD data packet.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.2.3.1-3 shall be returned, the response body should contain a "ProblemDetails" object with "cause" attribute set to one of the application errors listed in Table 6.1.3.2.3.1-3.

5.2.2.3 Delete Service Operation

5.2.2.3.1 General

The Delete service operation is used during the following procedure:

– SMF Initiated SMF-NEF Connection Release procedure (see 3GPP TS 23.502 [3], clause 4.25.7)

The Delete service operation is invoked by a NF Service Consumer (e.g. a SMF) towards the NEF, when the PDU Session Release is initiated and a SM context for NIDD has been previously created on NEF for the PDU session.

The NF Service Consumer (e.g. the SMF) shall delete the SM Context for NIDD on NEF by invoking the "release" custom operation on the Individual SM Context resource as shown in Figure 5.2.2.3.1-1.

Figure 5.2.2.3.1-1: Delete Service Operation

1. The NF Service Consumer shall send a HTTP POST request towards the URI of "release" custom operation on the Individual SM Context resource received from the "Location" header during a successful Create service operation invocation (See clause 5.2.2.2). The request body shall contain a "SmContextReleaseData" object.

2a. On success, "204 No Content" shall be returned if no information is to be returned to the NF service consumer; otherwise "200 OK" shall be returned with a "SmContextReleasedData" object in response body including necessary information to the NF service consumer, e.g.:

– Small Data Rate Control status, if Small Data Rate Control is enforced;

– APN Rate Status, if APN Rate Control is enforced

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.4.2-2 shall be returned, the response body should contain a "ProblemDetails" object with "cause" attribute set to one of the application errors listed in Table 6.1.3.3.4.2.2-2.

5.2.2.4 Status Notify Service Operation

5.2.2.4.1 General

The Status Notify service operation is used during the following procedure:

– NEF Initiated SMF-NEF Connection Release procedure (see 3GPP TS 23.502 [3], clause 4.25.8)

The Status Notify service operation is invoked by the NEF to inform a NF Service Consumer (e.g. a SMF), when the status of the Individual SM Context has changed.

The NEF shall inform the status change of the Individual SM Context resource by sending the HTTP POST method towards the Notification URI as shown in Figure 5.2.2.4.1-1.

Figure 5.2.2.4.1-1: Status Notify Service Operation

1. The NEF shall send a POST request towards the Notification URI received in the Create service operation request (See clause 5.2.2.2). The request body shall contain a "SmContextStatusNotification" object indicating the changed status of the Individual SM Context resource. The "smContextId" attribute shall contain the URI of the SM Context resource that triggers the notification.

2a. On success, "204 No content" shall be returned without response body.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.5.2.3.1-2 shall be returned, the response body should contain a "ProblemDetails" object.

5.2.2.4.2 Notify of Individual SM Context Release (Nnef_SMContext_DeleteNotify)

During NEF initiated SMF-NEF connection release procedure (see 3GPP TS 23.502 [3], clause 4.25.8), the NEF shall send Status Notification to inform the NF service consumer that the Individual SM Context is released.

The requirements in clause 5.2.2.4.1 shall be applied, with following additions:

1. Same as step 1 of Figure 5.2.2.4.1-1, the NEF shall set the value of "status" attribute in the request body to "RELEASED".

– If Small Data Rate Control is enforced, the response body should include the Small Data Rate Control status.

– If APN Rate Control is enforced, the response body should include the APN Rate Status.

5.2.2.5 Update Service Operation

5.2.2.5.1 General

The Update service operation is invoked by a NF Service Consumer, e.g. a SMF, towards the NEF, when the SMF detects that some of the configurations of the PDU session has changed and the related SM Context for NIDD needs to be updated accordingly.

The NF Service Consumer (e.g. the SMF) shall update the SM Context for NIDD on NEF by invoking the "update" custom operation of the Individual SM Context resource as shown in Figure 5.2.2.5.1-1.

Figure 5.2.2.5.1-1: Update Service Operation

1. The NF Service Consumer shall send a POST request to the URI of "update" custom operation on an Individual SM Context resource, with a "SmContextUpdateData" object in request body containing the attributes to be updated, e.g.:

– URI of the resource to receive downlink data delivery for NIDD;

– Notification URI to receive the SM Context notifications;

– modified configuration parameters, e.g. serving PLMN rate control, small data rate control, etc.

NOTE: If both the NEF and the NF service consumer (i.e. the SMF) supports "BIUMR" feature, the SMF can include the updated binding indication(s) for multiple PDU session resources (for NIDD downlink data delivery) and/or notification URIs (for SM Context notifications), as specified in clauses 6.12.1 and 5.2.3.2.6 of 3GPP TS 29.500 [4].

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.4.3.2-2 shall be returned, the response body should contain a ProblemDetails object with "cause" attribute set to one of the application errors listed in Table 6.1.3.3.4.3.2-2.

5.2.2.6 Deliver Service Operation

5.2.2.6.1 General

The Deliver service operation is invoked by a NF Service Consumer, e.g. a SMF, to transport Mobile Originated data packet via NEF.

The NF Service Consumer (e.g. the SMF) shall deliver Mobile Originate data via NEF by invoking the "deliver" custom operation of the Individual SM Context resource as shown in Figure 5.2.2.6.1-1.

Figure 5.2.2.5.6-1: Deliver Service Operation

1. The NF Service Consumer shall send a POST request to the URI of "deliver" custom operation on an Individual SM Context resource, with the request body containing:

– the MO data as binary body part with content type set as "application/octet-stream"; and

– a "DeliverReqData" object as another body part with "data" attribute refer to the MO data binary part.

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.4.4.2-2 shall be returned. The response body should contain a ProblemDetails object with "cause" attribute set to one of the application errors listed in Table 6.1.3.3.4.4.2-2.

5.3 Nnef_SMService Service

5.3.1 Service Description

See 3GPP TS 23.540 [18] clause 6.8.1

5.3.2.2 MoForwardSm

5.3.2.2.1 General

The MoForwardSm service operation shall be used to transmit MO SMS message via NEF.

It is used in the following procedures:

– MSISDN-less MO SMS message transfer (see clause 5.2.4 of 3GPP TS 23.540 [18]).

The NF Service Consumer (e.g. SMS-SC) shall transmit MO SMS message to NEF by using the HTTP POST method as shown in Figure 5.3.2.2.1-1.

Figure 5.3.2.2.1-1: SBI-based MO SM transfer

1. The NF Service Consumer shall send a POST request to the resource representing the UE’s Mobile Originated Short Message Information resource (i.e. …/sm-contexts/{supi}/sendsms) of the NEF. The payload body of the POST request shall contain the SMS message to be sent.

2a. On success, "200 OK" shall be returned with "SmsDeliveryData" object contains the MO SMS Delivery Report in the response body.

2b. On failure, or redirection, one of the HTTP status code listed in Table 6.2.3.2.4.2.2-2 shall be returned.