5 Services offered by the SMSF

29.5403GPP5G SystemRelease 18SMS ServicesStage 3TS

5.1 Introduction

The SMSF supports the following services.

Table 5.1-1: NF Services provided by SMSF

Service Name

Description

Example Consumer

Nsmsf_SMService

This service allows AMF to authorize SMS and activate SMS for the served user on SMSF.

This service also allows the SMS-GMSC, SMS Router and IP-SM-GW to send the SMS payload in downlink direction to the SMSF.

AMF, SMS-GMSC, SMS Router, IP-SM-GW

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

Nsmsf_SMService

6.1

SMSF SMService

TS29540_Nsmsf_SMService.yaml

nsmsf-sms

A.2

5.2 Nsmsf_SMService Service

5.2.1 Service Description

The Nsmsf_SMService service provides the service capability for the NF Service Consumer (e.g. AMF) to authorize SMS and activate SMS for a service user on SMSF, for the NF Service Consumer (e.g. SMS GMSC, SMS Router and IP-SM-GW) to send the SMS payload in downlink direction to the SMSF. The following are the key functionalities of this NF service:

– Activation or deactivation of SMS service for a given service user, which results in creating/updating/deleting an UE Context for SMS in SMSF;

– Send SMS payload in uplink direction to SMSF;

– Send SMS payload in downlink direction to SMSF.

The Nsmsf_SMService service supports the following service operations.

Table 5.2.1-1: Service operations supported by the Nsmsf_SMService service

Service Operations

Description

Operation

Semantics

Example Consumer(s)

Activate

Activate SMS service for a given service user, which results in creating or updating a UE Context for SMS in SMSF.

Request/Response

AMF

Deactivate

Deactivate SMS service for a given service user, which results in deleting or updating a UE Context for SMS in SMSF.

Request/Response

AMF

UplinkSMS

Send SMS payload in uplink direction to SMSF.

Request/Response

AMF

MtForwardSm

Send SMS payload in downlink direction to SMSF.

Request/Response

SMS-GMSC, SMS Router, IP-SM-GW

5.2.2 Service Operations

5.2.2.1 Introduction

This clause introduces the related procedures using Nsmsf_SMService service operations for supporting SMS service.

5.2.2.2 Activate

5.2.2.2.1 General

The Activate service operation shall be used by the NF Service Consumer (e.g. AMF) to activate SMS service for a given service user, which results in creating or updating an individual UE Context for SMS in the SMSF, in the following procedures:

– Registration Procedure for SMS over NAS (see clause 4.13.3.1 of 3GPP TS 23.502 [3]);

– Registration Update Procedure for SMS over NAS due to AMF change (see clause 4.13.3.1 of 3GPP TS 23.502 [3]);

– Registration Update Procedure for SMS over NAS to add authorization for SMS over a new additional Access Type;

– AMF initiated modification to UE Context in SMSF, e.g. modify the backup AMF information.

There shall be only one individual UE Context for SMS per service user.

5.2.2.2.2 Registration procedure using Activate service operation

The NF Service Consumer (e.g. AMF) shall activate SMS service for a given service user by using the HTTP PUT method as shown in Figure 5.2.2.2.2-1.

Figure 5.2.2.2.2-1: Activation of SMS service

1. The NF Service Consumer (e.g. AMF) shall send a PUT request to the resource representing the UE Context for SMS (i.e. …/ue-contexts/{supi}) in the SMSF to activate SMS service for a given service user. The payload body of the PUT request shall contain a representation of the individual UE Context resource to be created or updated.

Depending on whether the target UE Context for SMS has already been created, the SMSF performs 2a or 2b:

2a. If the target UE Context for SMS is not created in SMSF, the SMSF registers itself in UDM for the Access Type(s) provided, retrieves subscription data from the UDM, performs service authorization for the given UE, and create UE Context for SMS for this UE.

If successful, "201 Created" shall be returned, the payload body of the PUT response shall contain the representation of the created resource and the "Location" header shall contain the URI of the created resource.

2b. If the target UE Context for SMS has already been created, the SMSF updates the UE Context for SMS with the NF Service Consumer (e.g. AMF) provided parameters.

If successful, "204 No Content" shall be returned.

2c. If the target UE Context for SMS has already been created and the NF Service Consumer (e.g. AMF) provided parameters contains 2 access types (i.e. an additional Access Type), the SMSF registers itself in UDM for the new Access Type for the given UE, performs service authorization for the given UE for the new Access Type and updates the UE context for SMS for this UE with the new additional Access Type.

If successful, "204 No Content" shall be returned.

2d. On failure, the appropriate HTTP status code (e.g. "403 Forbidden") indicating the error shall be returned.

A ProblemDetails IE shall be included in the payload body of PUT response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.1.7.3-1.

2e. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned.

A RedirectResponse IE may be included in the payload body of PUT response, as specified in table 6.1.3.3.3.1-3.

5.2.2.2.3 Modify UE Context in SMSF using HTTP PATCH Method

The NF Service Consumer (e.g. AMF) may update UE context in SMSF for a given service user by using the HTTP PATCH method as shown in Figure 5.2.2.2.3-1.

Figure 5.2.2.2.3-1: Modify UE Context in SMSF using HTTP PATCH Method

1. The NF Service Consumer (e.g. AMF) shall send a PATCH request to the resource representing the UE Context for SMS (i.e. …/ue-contexts/{supi}) in the SMSF to modify the UE Context in SMSF for a given service user. The request body shall contain a list of PatchItem for each the JSON pointer is set to the attribute to be modified.

2a. On success, the request is accepted, and all the modification instructions in the PATCH request have been implemented, the SMSF shall respond with "204 No Content".

2b. On partial success, the request is accepted, but some of the modification instructions in the PATCH request have been discarded:

– the SMSF shall respond with "200 OK" including PatchResult to indicate the failed modifications, if the NF service consumer has included in the supported-feature query parameter the "PatchReport" feature; or

-the SMSF shall respond with "200 OK" with the response body containing UeSmsContextData, if the NF service consumer does not support the "PatchReport" feature.

2c. On failure, the appropriate HTTP status code (e.g. "403 Forbidden") indicating the error shall be returned. A ProblemDetails IE shall be included in the payload body of PATCH response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.1.7.3-1.

If the modification is not allowed, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in the "ProblemDetails" element).

If the resource does not exist, e.g. the attribute to be modified cannot be found, HTTP status code "404 Not Found" should be returned including additional error information in the response body (in the "ProblemDetails" element).

2d. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned. A RedirectResponse IE may be included in the payload body of PATCH response, as specified in table 6.1.3.3.3.1-3.

5.2.2.3 Deactivate

5.2.2.3.1 General

The Deactivate service operation shall be used by the NF Service Consumer (e.g. AMF) to deactivate SMS service for a given service user, which results in deleting or updating an individual UE Context for SMS in the SMSF, in the following procedures:

– De-Registration Procedure to remove SMS service authorization from SMSF for SMS over NAS (see clause 4.13.3.2 of 3GPP TS 23.502 [3]);

– De-Registration procedure to remove SMS service authorization from SMSF for one of the registered Access Type (see clause 4.13.3.2 of 3GPP TS 23.502 [3]);

5.2.2.3.2 De-Registration procedure to remove SMS service authorization from SMSF

The NF Service Consumer (e.g. AMF) shall deactivate SMS service for a given service user by using the HTTP DELETE method as shown in Figure 5.2.2.3.2-1.

Figure 5.2.2.3.2-1: Deactivation of SMS service

1. The NF Service Consumer (e.g. AMF) shall send a DELETE request to the resource representing the UE Context for SMS (i.e. …/ue-contexts/{supi}) in the SMSF.

2a. The SMSF deactivates the SMS service for the service user, and deletes the UE context for SMS from the SMSF.

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

2b. On failure, the appropriate HTTP status code (e.g. "404 Not Found") indicating the error shall be returned.

A ProblemDetails IE shall be included in the payload body of DELETE response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.1.7.3-1.

2c. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned.

A RedirectResponse IE may be included in the payload body of DELETE response, as specified in table 6.1.3.3.3.2-3.

5.2.2.3.3 De-Registration procedure to remove SMS service authorization from SMSF for one of the registered Access Type

When the UE has SMS service activated on both of the Access Types and the NF Service Consumer (e.g. AMF) wants to deactivate SMS service for the given UE for one of the affected Access Type, the NF Service Consumer (e.g. AMF) shall use HTTP PUT method as shown in Figure 5.2.2.3.3-1.

Figure 5.2.2.3.3-1: Removal of SMS service authorization over one of the access types

1. The NF Service Consumer (e.g. AMF) shall send a PUT request to the resource representing the UE Context for SMS (i.e. …/ue-contexts/{supi}) in the SMSF. The payload body of the PUT request shall contain a representation of the individual UE Context resource to be updated. Only one Access Type that is allowed for SMS service shall be included in the PUT request payload body.

2a. Since the target UE Context for SMS was already created at the SMSF with both 3GPP and non-3GPP Access Types for the same NF Service Consumer (e.g. AMF) and the NF Service Consumer provided parameters contains only one Access Type, the SMSF deregisters itself in the UDM for the affected Access Type (i.e. the access type not included in the PUT request) for the given UE and updates the UE context for SMS by removing the affected Access Type.

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

2b. On failure, the appropriate HTTP status code (e.g. "403 Forbidden") indicating the error shall be returned.

A ProblemDetails IE shall be included in the payload body of PUT response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.1.7.3-1.

2c. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned.

A RedirectResponse IE may be included in the payload body of PUT response, as specified in table 6.1.3.3.3.1-3.

5.2.2.4 UplinkSMS

5.2.2.4.1 General

The UplinkSMS service operation shall be used by NF Service Consumer (e.g. AMF) to send SMS payload (e.g. SMS message or Ack) in the uplink direction to SMSF, in the following procedures:

– MO SMS delivery procedure (see clause 4.13.3.3-4.13.3.5 of 3GPP TS 23.502 [3]);

– MT SMS delivery procedure (see clause 4.13.3.6-4.13.3.8 of 3GPP TS 23.502 [3]);

5.2.2.4.2 Procedures of sending SMS payload in uplink direction using UplinkSMS service operation

The NF Service Consumer (e.g. AMF) shall send SMS payload in uplink direction by using the "sendsms" custom operation as shown in Figure 5.2.2.4.2-1.

Figure 5.2.2.4.2-1: Send SMS payload in uplink direction

1. The NF Service Consumer (e.g. AMF) shall send a POST request to the resource representing the UEContext (i.e. …/ue-contexts/{supi}/sendsms) of the SMSF. The payload body of the POST request shall contain the SMS record to be sent.

2a. On success, "200 OK" shall be returned with "SmsRecordDeliveryData" object in the response body.

The SMSF may immediately respond to the NF service consumer, after successful inspection of the SMS payload, and set the "deliveryStatus" attribute to "SMS_DELIVERY_SMSF_ACCEPTED"; the SMSF may also attempt to forward the SMS payload to SMS-GMSC/IWMSC/IP-SM-GW/SMS Router.

If successful, "200 OK" shall be returned. If needed, the payload body of the POST response shall contain the status of SMS record delivery attempts at the SMSF.

2b. On failure, the appropriate HTTP status code (e.g. "403 Forbidden") indicating the error shall be returned.

A ProblemDetails IE shall be included in the payload body of POST response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.1.7.3-1.

2c. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned.

A RedirectResponse IE may be included in the payload body of POST response, as specified in table 6.1.3.3.4.2.2-2.

5.2.2.5 MtForwardSm

5.2.2.5.1 General

The MtForwardSm service operation shall be used by NF Service Consumer (e.g. SMS GMSC, SMS Router and IP-SM-GW) to send SMS payload (e.g. SMS message) in the downlink direction to SMSF, in the following procedures:

– Successful Mobile Terminated short message transfer as defined in 3GPP TS 23.540 [21] clause 5.1.2, clause 5.1.3 and clause 5.1.4.

– Unsuccessful Mobile Terminated short message transfer as defined in 3GPP TS 23.540 [21] clause 5.1.5, clause 5.1.6 and clause 5.1.9.

5.2.2.5.2 Procedures of sending SMS payload in downlink direction using MtForwardSm service operation

The NF Service Consumer (e.g. SMS GMSC, SMS Router and IP-SM-GW) shall send SMS payload in downlink direction by using the "send-mt-sms" custom operation as shown in Figure 5.2.2.5.2-1.

Figure 5.2.2.5.2-1: Send SMS payload in downlink direction

1. The NF Service Consumer (e.g. SMS GMSC, SMS Router and IP-SM-GW) shall send a POST request to the resource representing the UEContext (i.e. …/ue-contexts/{supi}/send-mt-sms) of the SMSF. The payload body of the POST request shall contain the MT SMS record to be sent.

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

2b. On failure, the appropriate HTTP status code (e.g. "403 Forbidden") indicating the error shall be returned.

A ProblemDetails IE shall be included in the payload body of POST response, with the "cause" attribute of ProblemDetails set to application error codes specified in table 6.1.7.3-1.

2c. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned.

A RedirectResponse IE may be included in the payload body of POST response, as specified in table 6.1.3.3.4.x.2-2.