8 Node functionality

23.0403GPPRelease 17Technical realization of the Short Message Service (SMS)TS

The overall requirements to the MSC, SMS-GMSC, SMS-IWMSC, SGSN and SMS Router with respect to handling of the Short Message Service is to cater for the routing and necessary intermediate buffering of the short messages.

8.1 Node functionality related to SM MT

8.1.1 Functionality of the SMS‑GMSC

When receiving a short message TPDU from the SC, the SMS‑GMSC is responsible for the following operations:

‑ reception of the short message TPDU;

‑ inspection of the parameters.

NOTE 1: The SMS‑GMSC may be identical to the MSC.

if parameters are incorrect:

‑ returning the appropriate error information to the SC in a failure report (see clauses 9 and 10);

if errors are not found within parameters:

‑ interrogating the HLR ("sendRoutingInfoForShortMsg", see clause 10); retrieving routing information or possible error information;

NOTE 2: The SMS-GMSC indicates if the short message is a Single-shot SM by setting an indication in the "sendRoutingInfoForShortMsg" as specified in 3GPP TS 29.002 [15].

if HLR is returning error information:

‑ returning the appropriate error information to the SC in a failure report (see clauses 9 and 10);

if no errors are indicated by the HLR:

‑ transferring the short message TPDU to the MSC or SGSN using the routing information obtained from the HLR ("forwardShortMessage", see clause 10);

NOTE 3: In case where two addresses (SGSN and MSC) are received from HLR, the SMS-GMSC may choose (operator dependant) via which nodes (SGSN or MSC) the SMS is first to be sent. The SMS delivery via the SGSN is normally more radio resource efficient than the SMS delivery via the MSC.

if one address (SGSN or MSC) is received from HLR:

– When receiving the report associated with the short message from the MSC or SGSN (positive or negative outcome of "forwardShortMessage", see clause 10), the SMS‑GMSC is responsible for the following operations;

if the report indicates successful delivery:

‑ notifying the HLR of the successful delivery via the MSC or the SGSN, which shall cause the HLR to alert any service centres whose addresses are stored in the MWD for the MS;

‑ creating and sending the successful report to the SC;

if the report is a failure report indicating "absent subscriber" via the MSC or the SGSN (see clause 3.3):

‑ requesting the HLR to insert the address of the originating SC into the MWD (if implemented) with cause Absent Subscriber ("SM_DeliveryReportStatus", see clauses 9 and 10) for non Single-shot SM;

NOTE 4: The SMS-GMSC indicates if the short message is a Single-shot SM by setting an indication in the "SM_DeliveryReportStatus" as specified in 3GPP TS 29.002 [15].

– informing the HLR of the reason for the MS being absent via the MSC or the SGSN (if this information is available);

‑ establishing, where necessary, a link with the addressed SC (see clause 5);

‑ creating and sending the negative report to the SC which should include the reason for the MS being absent (if this information is available) so that the SC may adjust any retry algorithm appropriately (see clauses 9 and 10);

if the report is a failure report indicating "MS memory capacity exceeded" via the MSC or the SGSN (see clause 3.3):

‑ requesting the HLR to insert the address of the originating SC into the MWD (if implemented) with cause MS Memory Capacity Exceeded via the MSC or the SGSN ("SM_DeliveryReportStatus" , see clauses 9 and 10) for non Single-shot SM;

‑ establishing, where necessary, a link with the addressed SC (see clause 5);

‑ creating and sending the report to the SC (see clauses 9 and 10).

if two addresses (SGSN and MSC) are received from HLR:

– When receiving the first report associated with the short message from the MSC or SGSN (positive or negative outcome of "forwardShortMessage", see clause 10), the SMS‑GMSC is responsible for the following operations:

if the first report indicates successful delivery:

‑ notifying the HLR of the successful delivery via the MSC or the SGSN, which shall cause the HLR to alert any service centres whose addresses are stored in the MWD for the MS;

‑ creating and sending the successful report to the SC;

if the first report is a failure report indicating:

– Unidentified subscriber;

– Facility not supported;

– Absent subscriber with indication: GPRS or IMSI Detach;

– System failure;

– Unexpected data value;

– Data missing;

– GPRS connection suspended (see 3GPP TS 29.002 [15]);

– SM Delivery Failure with indication: equipment Not SM Equipped:

‑ transferring the short message TPDU to the second path using the routing information obtained from HLR.

if the second report indicates successful delivery:

‑ notifying the HLR of the successful delivery of the second transfer via the MSC or SGSN, which shall cause the HLR to alert any service centres whose addresses are stored in the MWD for the MS;

– notifying the HLR of the unsuccessful delivery at first transfer only with cause "absent subscriber";

– notifying the HLR of the reason for the MS being absent via the MSC or the SGSN (if this information is available);

– establishing, when necessary, a link with the addressed SC (see clause 5);

‑ creating and sending the successful report to the SC;

if the second report is a failure report:

‑ requesting the HLR to insert the address of the originating SC into the MWD (if implemented) only if at least one of the first or second report failed due to "MS Memory Capacity Exceeded" or "Absent Subscriber" ("SM_DeliveryReportStatus", see clauses 9 and 10) for non Single-shot SM;

– notifying the HLR only with the causes "Absent Subscriber", "Memory Capacity Exceeded" via the MSC or the SGSN, or both;

– notifying the HLR of the reason for the MS being absent via the MSC, SGSN or both (if this information is available);

‑ establishing, where necessary, a link with the addressed SC (see clause 5);

‑ creating and sending the negative report to the SC with errors from first and second path (see clauses 9 and 10).

8.1.2 Functionality of the MSC

When receiving a short message TPDU from the SMS‑GMSC ("forwardShortMessage", see clause 10), the MSC is responsible for the following operations:

‑ reception of the short message TPDU;

– the receiving network may verify if the received SM-SC address (contained in RP-OA IE) and SCCP Calling Party Address are of the same PLMN;

‑ retrieving information from the VLR ("sendInfoFor‑MT‑SMS", see clause 10); location area address and, when appropriate, error information;

if errors are indicated by the VLR:

‑ returning the appropriate error information to the SMS‑GMSC in a failure report (negative outcome of "forwardShortMessage" see clauses 10 and 11);

if no errors are indicated by the VLR:

‑ transferring the short message to the MS (see 3GPP TS 24.011 [13]).

When receiving a confirmation that the message is received by the MS (see 3GPP TS 24.011 [13]):

‑ relaying the delivery confirmation to the SMS‑GMSC in a delivery report (positive outcome of "forwardShortMessage", see clauses 10 and 11).

When receiving a failure report of the short message transfer to the MS (see 3GPP TS 24.011 [13]):

‑ returning the appropriate error information to the SMS‑GMSC in a failure report (negative outcome of "forwardShortMessage", see clause 10).

When receiving a notification from the MS that it has memory available to receive one or more short messages (see 3GPP TS 24.011 [13]):

‑ relaying the notification to the VLR ("mSMemoryCapacityAvailable", see clause 10);

if errors are indicated by the VLR:

‑ returning the appropriate error information to the MS in a failure report (negative outcome of "ReadyForSM", see clauses 10 and 11).

When there is an ongoing MT-SMS transfer to the MS (see 3GPP TS 24.011 [13]), or other busy condition for MT-SMS, the MSC has the option to store the TPDU in a queue for a short time (which must be shorter than the supervision timer defined in 3GPP TS 29.002 [15]). The maximum time that a message may be queued is related to the permitted delay for the MSC to respond to the SMS-GMSC. When the MS becomes available for MT-SMS transfer, the stored TPDUs are delivered to the MS on a first-in first-out basis. If a message is not successfully transferred to the MS within the permitted time, the MSC returns an appropriate error to the SMS-GMSC.

NOTE: The reaction of MSC when the message verification failed is operator specific and not specified in 3GPP specifications.

8.1.3 Functionality of the SGSN

When receiving a short message TPDU from the SMS‑GMSC ("forwardShortMessage", see clause 10), the SGSN is responsible for the following operations:

‑ reception of the short message TPDU;

– the receiving network may verify if the received SM-SC address (contained in RP-OA IE) and SCCP Calling Party Address are of the same PLMN.

if errors are detected by the SGSN:

‑ returning the appropriate error information to the SMS‑GMSC in a failure report (negative outcome of "forwardShortMessage" see clauses 10 and 11);

if no errors are detected by the SGSN:

‑ transferring the short message to the MS (see 3GPP TS 24.011 [13]).

When receiving a confirmation that the message is received by the MS (see 3GPP TS 24.011 [13]):

‑ relaying the delivery confirmation to the SMS‑GMSC in a delivery report (positive outcome of "forwardShortMessage", see clauses 10 and 11).

When receiving a failure report of the short message transfer to the MS (see 3GPP TS 24.011 [13]):

‑ returning the appropriate error information to the SMS‑GMSC in a failure report (negative outcome of "forwardShortMessage", see clause 10).

When receiving a notification from the MS that it has memory available to receive one or more short messages (see 3GPP TS 24.011 [13]):

if errors are detected by the SGSN:

‑ returning the appropriate error information to the MS in a failure report (negative outcome of "ReadyForSM", see clauses 10 and 11).

if no errors are detected by the SGSN:

– notifying the HLR of memory available in the MS via the SGSN with "ReadyForSM" (see clauses 10 and 11).

When the MS is becoming reachable again (see 3GPP TS 24.008 [12]):

– notifying the HLR of MS being reachable via the SGSN (and via the MSC if any) with "ReadyForSM" (see clauses 10).

When there is an ongoing MT-SMS transfer to the MS (see 3GPP TS 24.011 [13]), or other busy condition for MT-SMS, the SGSN has the option to store the TPDU in a queue for a short time (which must be shorter than the supervision timer defined in 3GPP TS 29.002 [15]). The maximum time that a message may be queued is related to the permitted delay for the SGSN to respond to the SMS-GMSC. When the MS becomes available for MT-SMS transfer, the stored TPDUs are delivered to the MS on a first-in first-out basis. If a message is not successfully transferred to the MS within the permitted time, the SGSN returns an appropriate error to the SMS-GMSC.

NOTE: The reaction of SGSN when the message verification failed is operator specific and not specified in 3GPP specifications.

8.1.4 Functionality of the SMS Router

When receiving a routing information retrieval ("sendRoutingInfoForShortMsg", see clause 10), the SMS Router is responsible for the following operations:

‑ interrogating the HLR ("sendRoutingInfoForShortMsg", see clause 10); retrieving routing information or possible error information. This interrogation may be omitted if a parameter within the "sendRoutingInfoForShortMsg" explicitly indicates that delivery of a short message is not intended and only MCC+MNC are requested.

if HLR is returning error information:

‑ forwarding the returned error information transparently to the SMS-GMSC;

if no errors are indicated by the HLR:

‑ creating an MT Correlation ID;

– storing against the MT Correlation ID: the IMSI, the MSC address and/or the SGSN address. The address of the SMS‑GMSC and the destination MSISDN may also be stored. Creating an MT Correlation ID and storing these data against the MT Correlation ID may be omitted if a parameter within the "sendRoutingInfoForShortMsg" explicitly indicates that delivery of a short message is not intended;

– forwarding the returned information to the SMS-GMSC populating the IMSI IE with the MT Correlation ID and either:

a) the MSC address and/or SGSN address with the address of the SMS Router; or

NOTE 1: In this case if two addresses (SGSN and MSC) are received from HLR, the SMS-GMSC chooses (operator dependant) via which node (SGSN or MSC) the SM is first to be sent, not the SMS Router.

b) the address of the SMS Router. In this case the SMS Router delivers the SM as described in 3GPP TS 23.204 [42] for the IP-SM-GW. This option is mandatory when the SMS Router is deployed together with an IP-SM-GW.

NOTE 2: In this case if two addresses (SGSN and MSC) are received from HLR, the SMS Router chooses via which node (SGSN or MSC) the SM is first to be sent, i.e. the SMS Router delivers the SM as an IP-SM-GW.

If a parameter within the "sendRoutingInfoForShortMsg" explicitly indicates that delivery of a short message is not intended and that only IMSI or only MCC+MNC are requested, the IMSI IE may be populated with IMSI or MCC+MNC+dummy MSIN, respectively, and the MSC address and/or SGSN address with a dummy network node address.

if HLR is returning an Inform-Service-Centre information:

– fowarding the received information transparently to the SMS-GMSC.

When receiving a short message TPDU from the SMS‑GMSC ("forwardShortMessage", see clause 10), the SMS Router is responsible for the following operations:

‑ receiving the short message TPDU;

‑ forwarding the trigger SMS to filtering infrastructure to filter and block all trigger SMS that does not originate from SMS-GMSC in the HPLMN;

– checking validity of the MT Correlation ID received in the IMSI field

SMS Router can use the TP-Protocol-Identifier containing a Device Triggering Short Message code as an indication of trigger SMS and compare list of known SMS-GMSC against the SMS-GMSC in the RP-OA field of received short message to filter and block all short messages that do not originate from SMS-GMSC in the HPLMN.

The MT Correlation ID shall be considered invalid if the MT Correlation ID is unknown. Optionally, the MT Correlation ID may also be considered invalid if the CC and NDC of the address of the SMS-GMSC from which the forwardShortMessage was received is different from the CC and NDC of the SMS‑GMSC address stored above i.e. the forwardShortMessage has originated from a different network than that which issued the sendRoutingInfoForShortMsg.

If the received MT Correlation ID is deemed invalid by the SMS Router:

‑ returning the error "System failure" to the SMS‑GMSC in a failure report (negative outcome of "forwardShortMessage" see clauses 10 and 11).

If the received MT Correlation ID is deemed valid by the SMS Router:

‑ transferring the short message TPDU to the MSC (if the called party SSN in the received message is for MSC) or to the SGSN (if the called party SSN in the received message is for SGSN) using the stored routing information and replacing the MT Correlation ID with the stored IMSI (obtained from the HLR, above);

– support for service execution, lawful interception, and number portability if required;

– forwarding the delivery confirmation or failure report from the MSC or SGSN (which may have originally come from the MS) transparently to the SMS-GMSC; and

– if the SMS Router finds that SMS delivery is to be performed towards serving MSC or SGSN in a different PLMN, the SMS Router may replace the SMS-SC address in RP OA with an address containing the PLMN ID of the PLMN in which the SMS-Router is located before the SMS router forwards the request to the serving MSC or SGSN.

NOTE 3: This option can be used if the PLMN that deploys the SMS-router wants to ensure the delivery of a MT-SMS to a UE roaming in a different PLMN and this PLMN is known to deploy PLMN ID check on both RP-OA IE and SCCP Global Title.

NOTE 4: When using this functionality, the PLMN deploying the SMS-Router must be aware that reply path functionality offered by the originating SMS-SC cannot be used.

8.1.5 Functionality of the IP-SM-GW

The IP-SM-GW is described in 3GPP TS 23.204 [42], it provides:

– protocol interworking for delivery of short message between the IP-based UE and the SMSC;

– delivery of short message to the IP-based UE for cases with or without MSISDN;

– delivery of the SM to the MSC/SGSN if needed as described in 3GPP TS 23.204 [42]; and

– support for service execution, lawful interception, and number portability if required.

8.2 Node functionality related to SM MO

8.2.1 Functionality of the MSC

When receiving a short message TPDU from the MS, the MSC is responsible for the following operations:

‑ reception of the short message TPDU (see 3GPP TS 24.011 [13]);

‑ retrieving information from the VLR ("sendInfoForMO‑SMS", see clause 10); the MSISDN of the MS and, when appropriate, error information. The retrieval of information from the VLR is followed by the VLR investigating the MNRF (to be used in the alerting procedure, see clause 10)

if errors are indicated by the VLR:

‑ returning the appropriate error information to the MS in a failure report (negative outcome of "sendInfoForMO‑SMS" see clauses 10 and 11);

if no errors are indicated by the VLR:

‑ inspection of the RP-DA parameter;

if parameters are incorrect:

‑ returning the appropriate error information to the MS in a failure report (see 3GPP TS 24.011 [13]);

if no parameter errors are found:

NOTE: The SMS‑IWMSC may be identical to the MSC.

‑ transferring the short message TPDU to the SMS‑IWMSC ("forwardShortMessage", see clause 10).

When receiving the report of the short message from the SMS‑IWMSC (positive or negative outcome of the "forwardShortMessage", see clause 10), the MSC is responsible for the following operations:

‑ relaying the report to the MS (see 3GPP TS 24.011 [13]).

8.2.2 Functionality of the SMS‑IWMSC

When receiving a short message TPDU from the MSC, IP-SM-GW or SGSN ("forwardShortMessage", see clause 10), the SMS‑IWMSC is responsible for the following operations:

‑ reception of the short message TPDU;

‑ optionally, interrogating the HLR ("sendRoutingInfoForShortMsg", see clause 10); retrieving the recipient’s IMSI in order to check for the existence of an SMS Interworking agreement before establishing a link with the addressed SC;

if HLR returns error information:

‑ returning the appropriate error information to the MSC or SGSN in a failure report (negative outcome of "forwardShortMessage", see clause 10);

if no errors are indicated by the HLR:

‑ inspecting the IMSI parameter and ignoring the other routing information;

if the received parameter is unacceptable to the SMS-IWMSC (due to lack of an SMS Interworking agreement):

‑ returning SM Delivery Failure with indication: invalid SME-address to the MSC or SGSN;

if the parameter is acceptable to the SMS-IWMSC (due to the existence of an SMS Interworking agreement) or the SMS-IWMSC didn’t apply the optional HLR interrogation:

‑ establishing, where necessary, a link with the addressed SC (see clause 5);

‑ transferring the short message TPDU to the SC (if the address is valid);

if a report associated with the short message is received from the SC, the SMS‑IWMSC is responsible for the following operations:

‑ relaying of the report to the MSC or SGSN (positive or negative outcome of "forwardShortMessage", see clause 10);

if a report associated with the short message is not received from the SC before a timer expires or if the SC address is invalid, the SMS‑IWMSC is responsible for the following operations:

‑ returning the appropriate error information to the MSC or SGSN in a failure report (negative outcome of "forwardShortMessage", see clause 10).

The value of the timer is dependent on the protocol between the SC and the SMS‑IWMSC.

8.2.3 Functionality of the SGSN

When receiving a short message TPDU from the MS, the SGSN is responsible for the following operations:

‑ reception of the short message TPDU (see 3GPP TS 24.011 [13]);

‑ inspection of the RP-DA parameter;

if parameters are incorrect:

‑ returning the appropriate error information to the MS in a failure report (see 3GPP TS 24.011 [13]);

if no parameter errors are found:

‑ transferring the short message TPDU to the SMS‑IWMSC ("forwardShortMessage", see clause 10).

When receiving the report of the short message from the SMS‑IWMSC (positive or negative outcome of the "forwardShortMessage", see clause 10), the SGSN is responsible for the following operations:

‑ relaying the report to the MS (see 3GPP TS 24.011 [13]).

8.2.4 Functionality of the IP-SM-GW

The IP-SM-GW is described in 3GPP TS 23.204 [42], it provides:

– Successful SM MO delivery procedure with IP-SM-GW is described in 3GPP TS 23.204 [42] (see clause 6.3); and

– Successful SM MO delivery procedure with IP-SM-GW, without MSISDN (see clause 6.3a).

8.3 SMS‑IWMSC functionality related to alerting

When receiving an alert from the HLR ("alertServiceCentre", see clause 10), the SMS‑IWMSC is responsible for the following operations:

‑ inspect the SC address;

‑ generate an RP‑Alert‑SC (see clause 9);

‑ transferring the RP‑Alert‑SC to the SC.

NOTE: If the SC address is not valid, then no further action shall be taken.