9 SMS
34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification
9.1 Mobile Originating SMS / 5GS
9.1.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE is made to send an SMS over IP }
then { UE sends a SIP MESSAGE request containing a short message }
}
(2)
with { UE having sent a SIP MESSAGE request containing a short message }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a submission report }
then { UE sends a 200 OK response }
}
(3)
with { UE having sent a 200 OK response for submission report }
ensure that {
when { UE receives a SIP MESSAGE request containing a status report }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery report for status report }
}
9.1.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.341, clause 5.3.1.2]:
When an SM-over-IP sender wants to submit an SM over IP, the SM-over-IP sender shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the PSI of the SC of the SM-over-IP sender;
NOTE 1: The PSI of the SC can be SIP URI or tel URI based on operator policy. The PSI of the SC can be obtained using one of the following methods in the priority order listed below:
1) provided by the user;
2) if UICC is used, then:
– if present in the ISIM, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM of the ISIM as per 3GPP TS 31.103 [18];
– if not present on the ISIM, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM of the USIM as per 3GPP TS 31.102 [19]; or
– if neither present on the ISIM nor on the USIM, then the PSI of the SC contains the TS‑Service-Centre-Address stored in the EFSMSP in DF_TELECOM as per 3GPP TS 31.102 [19]. If the PSI of the SC is based on the E.164 number from the TS‑Service-Centre-Address stored in the EFSMSP in DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter format).
3) if SIM is used instead of UICC, then the PSI of the SC contains the TS‑Service Centre Address stored in the EFSMSP in DF_TELECOM as per 3GPP TS 51.011 [20]. If the PSI of the SC is based on the E.164 number from the TS‑Service-Centre-Address stored in the EFSMSP in DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter format); or
4) if neither the UICC nor SIM is used, then how the PSI of the SC is configured and obtained is through means outside the scope of this specification.
b) the From header, which shall contain a public user identity of the SM-over-IP sender;
NOTE 2: The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF.
NOTE 3: The SM-over-IP sender has to store the Call-ID of the SIP MESSAGE request, so it can associate the appropriate SIP MESSAGE request including a submit report with it.
c) the To header, which shall contain the SC of the SM-over-IP sender;
d) the Content-Type header, which shall contain "application/vnd.3gpp.sms"; and
e) the body of the request shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].
NOTE 4: The address of the SC is included in the RP-DATA message content. The address of the SC included in the RP-DATA message content is stored in the EFSMSP in DF_TELECOM of the (U)SIM of the SM-over-IP sender.
NOTE 5: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
NOTE 6: Both the address of the SC and the PSI of the SC can be configured in the EFPSISMSC in DF_TELECOM of the USIM and ISIM respectively using the USAT as per 3GPP TS 31.111 [21].
The SM-over-IP sender may request the SC to return the status of the submitted message. The support of status report capabilities is optional for the SC.
When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP sender shall:
– if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response according to RFC 3428 [14].
if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request does not correspond to a short message submitted by the SM-over-IP sender, a 488 (Not Acceptable here) SIP response according to RFC 3428 [14].
– if SM-over-IP sender does not support In-Reply-To header usage, generate a 200 (OK) SIP response according to RFC 3428 [14]; and extract the payload encoded according to 3GPP TS 24.011 [8] for RP-ACK or RP-ERROR.
[TS 24.341 clause 5.3.1.3]:
When a SIP MESSAGE request including a status report in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP sender shall:
– generate a SIP response according to RFC 3428 [14];
– extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and
– create a delivery report for the status report as described in subclause 5.3.2.4. The content of the delivery report is defined in 3GPP TS 24.011 [8].
[TS 24.341 clause 5.3.2.4]:
When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the IP-SM-GW;
NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message.
b) the From header, which shall contain a public user identity of the SM-over-IP receiver.
c) the To header, which shall contain the IP-SM-GW;
b) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
c) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].
NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
9.1.3 Test description
9.1.3.1 Pre-test conditions
System Simulator:
– 1 NR Cell connected to 5GC, default parameters.
UE:
– UE contains either ISIM and USIM applications or only USIM application on UICC.
– UE is configured to register for IMS after switch on.
Preamble:
– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.
9.1.3.2 Test procedure sequence
Table 9.1.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||||
|
U – S |
Message |
||||||||||
|
1 |
UE is made to attempt a Mobile Originating SMS over IMS |
– |
– |
– |
– |
||||||
|
1A-1F |
Steps 2-7 of generic procedure specified in Table 4.9.19.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
||||||
|
– |
EXCEPTION: In parallel with Step 2, parallel behaviour defined in table 9.1.3.2-2 takes place |
– |
– |
– |
– |
||||||
|
2 |
Check: Does UE send a SIP MESSAGE request including a vnd.3gpp.sms payload that contains a short message? |
–> |
SIP MESSAGE |
1 |
P |
||||||
|
3 |
SS responds with 202 Accepted |
<– |
202 Accepted |
– |
– |
||||||
|
4 |
SS sends a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the short message submission report indicating a positive acknowledgement of the short message sent by the UE at Step 2 |
<– |
SIP MESSAGE |
– |
– |
||||||
|
5 |
Check: Does UE respond with 200 OK? |
–> |
200 OK |
2 |
P |
||||||
|
6 |
SS sends a SIP MESSAGE request including a vnd.3gpp.sms payload that contains a status report |
<– |
SIP MESSAGE |
– |
– |
||||||
|
7 |
Check: Does UE respond with 200 OK? |
–> |
200 OK |
3 |
P |
||||||
|
8 |
Check: Does UE send a SIP MESSAGE request including a vnd.3gpp.sms payload that contains an acknowledgement for the status report received at Step 6? |
–> |
SIP MESSAGE |
3 |
P |
||||||
|
9 |
SS responds with 202 Accepted |
<– |
202 Accepted |
– |
– |
||||||
Table 9.1.3.2-2: Parallel behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The UE transmits an RRCReconfigurationComplete message. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
9.1.3.3 Specific message contents
Table 9.1.3.3-1: SIP MESSAGE (step 2, table 9.1.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.3, Condition A5 |
Table 9.1.3.3-2: 202 Accepted (step 3 and 9, table 9.1.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
Table 9.1.3.3-3: SIP MESSAGE (step 4, table 9.1.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.4 |
Table 9.1.3.3-4: 200 OK (step 5 and 7, table 9.1.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5 and A22 |
Table 9.1.3.3-5: SIP MESSAGE (step6, table 9.1.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.5 |
Table 9.1.3.3-6: SIP MESSAGE (step 8, table 9.1.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.6 |
9.2 Mobile Terminating SMS / 5GS
9.2.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE receives a SIP MESSAGE request containing a short message }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery report }
}
9.2.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.341, clause 5.3.2.3]
When a SIP MESSAGE request including a short message in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP receiver shall:
– generate a SIP response according to RFC 3428;
– extract the payload encoded according to 3GPP TS 24.011 for RP-DATA; and
– create a delivery report as described in subclause 5.3.2.4. The content of the report is defined in 3GPP TS 24.011.
[TS 24.341, clause 5.3.2.4]
When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the IP-SM-GW;
NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message.
b) the From header, which shall contain a public user identity of the SM-over-IP receiver.
c) the To header, which shall contain the IP-SM-GW;
b) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
c) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].
NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
9.2.3 Test description
9.2.3.1 Pre-test conditions
System Simulator:
– 1 NR Cell connected to 5GC, default parameters.
UE:
– UE contains either ISIM and USIM applications or only USIM application on UICC.
– UE is configured to register for IMS after switch on.
Preamble:
– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.
9.2.3.2 Test procedure sequence
Table 9.2.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
0A-0H |
Steps 1-8 of generic procedure specified in Table 4.9.20.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
|
1 |
The SS sends a Short Message. |
<– |
SIP MESSAGE |
– |
– |
|
2 |
Check: Does the UE send a 200 OK response? |
–> |
200 OK |
1 |
P |
|
3 |
Check: Does the UE respond with a delivery report? |
–> |
SIP MESSAGE |
1 |
P |
|
4 |
The SS sends a 202 ACCEPTED response. |
<– |
202 ACCEPTED |
– |
– |
9.2.3.3 Specific message contents
Table 9.2.3.3-1: SIP MESSAGE (step 1, table 9.2.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.1 |
Table 9.2.3.3-2: 200 OK (step 2 table 9.2.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5 and A22 |
Table 9.2.3.3-3: SIP MESSAGE (step 3, table 9.2.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.2 |
Table 9.2.3.3-4: 202 Accepted (step 4, table 9.2.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
9.3 Mobile Originating Concatenated SMS / 5GS
9.3.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE is made to send a concatenated SMS over IP }
then { UE sends a SIP MESSAGE request containing the first segment of the concatenated SMS }
}
(2)
with { UE having sent a SIP MESSAGE request containing the first segment of the concatenated SMS }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a submission report for the first segment }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing the second segment of the concatenated SMS }
}
(3)
with { UE having sent a SIP MESSAGE request containing the second segment of the concatenated SMS }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a submission report for the second segment }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing the third segment of the concatenated SMS }
}
(4)
with { UE having sent a SIP MESSAGE request containing the third segment of the concatenated SMS }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a submission report for the third segment }
then { UE sends a 200 OK response }
}
9.3.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 23.040, clause 9.2.3.23]:
The TP‑User‑Data‑Header‑Indicator is a 1 bit field within bit 6 of the first octet of the following six PDUs:
– SMS‑SUBMIT,
– SMS-SUBMIT-REPORT,
– SMS‑DELIVER,
– SMS-DELIVER-REPORT,
– SMS-STATUS-REPORT,
– SMS-COMMAND.
TP-UDHI has the following values.
Bit no. 6 0 The TP‑UD field contains only the short message
1 The beginning of the TP‑UD field contains a Header in addition to the short message.
[TS 23.040, clause 9.2.3.24]:
The length of the TP-User-Data field is defined in the PDU’s of the SM-TL (see clause 9.2.2).
The TP‑User‑Data field may comprise just the short message itself or a Header in addition to the short message depending upon the setting of TP‑UDHI.
Where the TP‑UDHI value is set to 0 the TP‑User‑Data field comprises the short message only, where the user data can be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2 [24]) data.
Where the TP‑UDHI value is set to 1 the first octets of the TP‑User‑Data field contains a Header in the following order starting at the first octet of the TP‑User‑Data field.
Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire TPDU exactly as received.
FIELD LENGTH
Length of User Data Header 1 octet
Information‑Element‑Identifier "A" 1 octet
Length of Information‑Element "A" 1 octet
Information‑Element "A" Data 0 to "n" octets
Information‑Element‑Identifier "B" 1 octet
Length of Information‑Element "B" 1 octet
Information‑Element "B" Data 0 to "n" octets
Information‑Element‑Identifier "X" 1 octet
Length of Information‑Element "X" 1 octet
Information‑Element "X" Data 0 to "n" octets
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
Figure 9.2.3.24 (a)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed 8 bit data or uncompressed UCS2 data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
Figure 9.2.3.24 (b)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for compressed GSM 7 bit default alphabet data, compressed 8 bit data or compressed UCS2 data. The UDHL field is the first octet of the TP‑User-Data content of the Short Message.
Figure 9.2.3.24 (c)
The definition of the TP‑User‑Data‑Length field which immediately precedes the "Length of User Data Header" is unchanged and shall therefore be the total length of the TP‑User‑Data field including the Header, if present. (see 9.2.3.16).
The "Length‑of‑Information‑Element" fields shall be the integer representation of the number of octets within its associated "Information‑Element‑Data" field which follows and shall not include itself in its count value.
The "Length‑of‑User‑Data‑Header" field shall be the integer representation of the number of octets within the "User‑Data‑Header" information fields which follow and shall not include itself in its count or any fill bits which may be present (see text below).
Information Elements may appear in any order and need not follow the order used in the present document. Information Elements are classified into 3 categories as described below.
– SMS Control – identifies those IEIs which have the capability of dictating SMS functionality.
– EMS Control – identifies those IEIs which manage EMS Content IEIs.
– EMS Content – identifies those IEIs containing data of a unique media format.
It is permissible for certain IEs to be repeated within a short message, or within a concatenated message. There is no restriction on the repeatability of IEs in the EMS Content classification. The repeatability of SMS Control and EMS Control IEs is determined on an individual basis. See the IE table below for the repeatability of each IE.
In the event that IEs determined as not repeatable are duplicated, the last occurrence of the IE shall be used. In the event that two or more IEs occur which have mutually exclusive meanings (e.g. an 8bit port address and a 16bit port address), then the last occurring IE shall be used.
If the length of the User Data Header is such that there are too few or too many octets in the final Information Element then the whole User Data Header shall be ignored.
If any reserved values are received within the content of any Information Element then that part of the Information Element shall be ignored.
The support of any Information Element Identifier is optional unless otherwise stated.
The Information Element Identifier octet shall be coded as follows:
|
VALUE (hex) |
MEANING |
Classification |
Repeatability |
|
00 |
Concatenated short messages, 8-bit reference number |
SMS Control |
No |
|
01 |
Special SMS Message Indication |
SMS Control |
Yes |
|
02 |
Reserved |
N/A |
N/A |
|
03 |
Value not used to avoid misinterpretation as <LF> character |
N/A |
N/A |
|
04 |
Application port addressing scheme, 8 bit address |
SMS Control |
No |
|
05 |
Application port addressing scheme, 16 bit address |
SMS Control |
No |
|
06 |
SMSC Control Parameters |
SMS Control |
No |
|
07 |
UDH Source Indicator |
SMS Control |
Yes |
|
08 |
Concatenated short message, 16-bit reference number |
SMS Control |
No |
|
09 |
Wireless Control Message Protocol |
SMS Control |
Note 3 |
|
0A |
Text Formatting |
EMS Control |
Yes |
|
0B |
Predefined Sound |
EMS Content |
Yes |
|
0C |
User Defined Sound (iMelody max 128 bytes) |
EMS Content |
Yes |
|
0D |
Predefined Animation |
EMS Content |
Yes |
|
0E |
Large Animation (16*16 times 4 = 32*4 =128 bytes) |
EMS Content |
Yes |
|
0F |
Small Animation (8*8 times 4 = 8*4 =32 bytes) |
EMS Content |
Yes |
|
10 |
Large Picture (32*32 = 128 bytes) |
EMS Content |
Yes |
|
11 |
Small Picture (16*16 = 32 bytes) |
EMS Content |
Yes |
|
12 |
Variable Picture |
EMS Content |
Yes |
|
13 |
User prompt indicator |
EMS Control |
Yes |
|
14 |
Extended Object |
EMS Content |
Yes |
|
15 |
Reused Extended Object |
EMS Control |
Yes |
|
16 |
Compression Control |
EMS Control |
No |
|
17 |
Object Distribution Indicator |
EMS Control |
Yes |
|
18 |
Standard WVG object |
EMS Content |
Yes |
|
19 |
Character Size WVG object |
EMS Content |
Yes |
|
1A |
Extended Object Data Request Command |
EMS Control |
No |
|
1B-1F |
Reserved for future EMS features (see subclause 3.10) |
N/A |
N/A |
|
20 |
RFC 5322 E-Mail Header |
SMS Control |
No |
|
21 |
Hyperlink format element |
SMS Control |
Yes |
|
22 |
Reply Address Element |
SMS Control |
No |
|
23 |
Enhanced Voice Mail Information |
SMS Control |
No |
|
24 |
National Language Single Shift |
SMS Control |
No |
|
25 |
National Language Locking Shift |
SMS Control |
No |
|
26 – 6F |
Reserved for future use |
N/A |
N/A |
|
70 – 7F |
(U)SIM Toolkit Security Headers |
SMS Control |
Note 1 |
|
80 – 9F |
SME to SME specific use |
SMS Control |
Note 2 |
|
A0 – BF |
Reserved for future use |
N/A |
N/A |
|
C0 – DF |
SC specific use |
SMS Control |
Note 2 |
|
E0 – FF |
Reserved for future use |
N/A |
N/A |
|
Note 1: The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability is not within the scope of this document and will not be determined here. Note 2: The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and therefore, are not within the scope of this technical specification. Note 3: The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not within the scope of this document and will not be determined here. |
|||
A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the IEI is Reserved or not supported. The receiving entity calculates the start of the next information element by looking at the length of the current information element and skipping that number of octets.
The SM itself may be coded as 7, 8 or 16 bit data.
If 7 bit data is used and the TP‑UD‑Header does not finish on a septet boundary then fill bits are inserted after the last Information Element Data octet up to the next septet boundary so that there is an integral number of septets for the entire TP‑UD header. This is to ensure that the SM itself starts on an septet boundary so that an earlier Phase mobile shall be capable of displaying the SM itself although the TP‑UD Header in the TP‑UD field may not be understood.
It is optional to make the first character of the SM itself a Carriage Return character encoded according to the default 7 bit alphabet so that earlier Phase mobiles, which do not understand the TP‑UD‑Header, shall over‑write the displayed TP‑UD‑Header with the SM itself.
If 16 bit (USC2) data is used then padding octets are not necessary. The SM itself shall start on an octet boundary.
If 8 bit data is used then padding is not necessary. An earlier Phase mobile shall be able to display the SM itself although the TP‑UD header may not be understood.
It is also possible for mobiles not wishing to support the TP‑UD header to check the value of the TP‑UDHI bit in the SMS‑Deliver PDU and the first octet of the TP‑UD field and skip to the start of the SM and ignore the TP‑UD header.
[TS 23.040, clause 9.2.3.24.1]:
This facility allows short messages to be concatenated to form a longer message.
In the case of uncompressed 8‑bit data, the maximum length of the short message within the TP‑UD field is 134 (140‑6) octets.
In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the TP‑UD field is 153 (160‑7) characters. A character represented by an escape-sequence shall not be split in the middle.
In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP‑UD field is 67 ((140‑6)/2) characters. A UCS2 character shall not be split in the middle; if the length of the User Data Header is odd, the maximum length of the whole TP-UD field is 139 octets.
In the case of compressed GSM 7 bit default alphabet data, 8 bit data or UCS2 the maximum length of the compressed short message within the TP-UD field is 134 (140-6) octets including the Compression Header and Compression Footer, both or either of which may be present (see clause 3.9).
The maximum length of an uncompressed concatenated short message is 39015 (255*153) default alphabet characters, 34170 (255*134) octets or 17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170 (255*134) octets including the Compression Header and Compression Footer (see clause 3.9 and figure 9.2.3.24.1(a) below).
Figure 9.2.3.24.1 (a): Concatenation of a Compressed short message
The Information‑Element‑Data field contains information set by the application in the SMS‑SUBMIT so that the receiving entity is able to re‑assemble the short messages in the correct order. Each concatenated short message contains a reference number which together with the originating address and Service Centre address allows the receiving entity to discriminate between concatenated short messages sent from different originating SMEs and/or SCs. In a network which has multiple SCs, it is possible for different segments of a concatenated SM to be sent via different SCs and so it is recommended that the SC address should not be checked by the MS unless the application specifically requires such a check.
The TP elements in the SMS‑SUBMIT PDU, apart from TP‑MR, TP-SRR, TP‑UDL and TP‑UD, should remain unchanged for each SM which forms part of a concatenated SM, otherwise this may lead to irrational behaviour. TP-MR must be incremented for every segment of a concatenated message as defined in clause 9.2.3.6. A SC shall handle segments of a concatenated message like any other short message. The relation between segments of a concatenated message is made only at the originator, where the message is segmented, and at the recipient, where the message is reassembled. SMS‑COMMANDs identify messages by TP-MR and therefore apply to only one segment of a concatenated message. It is up to the originating SME to issue SMS-COMMANDs for all the required segments of a concatenated message.
The Information‑Element‑Data octets shall be coded as follows.
Octet 1 Concatenated short message reference number.
This octet shall contain a modulo 256 counter indicating the reference number for a particular concatenated short message. This reference number shall remain constant for every short message which makes up a particular concatenated short message.
Octet 2 Maximum number of short messages in the concatenated short message.
This octet shall contain a value in the range 0 to 255 indicating the total number of short messages within the concatenated short message. The value shall start at 1 and remain constant for every short message which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore the whole Information Element.
Octet 3 Sequence number of the current short message.
This octet shall contain a value in the range 0 to 255 indicating the sequence number of a particular short message within the concatenated short message. The value shall start at 1 and increment by one for every short message sent within the concatenated short message. If the value is zero or the value is greater than the value in octet 2 then the receiving entity shall ignore the whole Information Element.
The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.
[TS 24.341, clause 5.3.2.3]
When a SIP MESSAGE request including a short message in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP receiver shall:
– generate a SIP response according to RFC 3428;
– extract the payload encoded according to 3GPP TS 24.011 for RP-DATA; and
– create a delivery report as described in subclause 5.3.2.4. The content of the report is defined in 3GPP TS 24.011.
[TS 24.341, clause 5.3.2.4]
When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the IP-SM-GW;
NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message.
b) the From header, which shall contain a public user identity of the SM-over-IP receiver.
c) the To header, which shall contain the IP-SM-GW;
b) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
c) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].
NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
9.3.3 Test description
9.3.3.1 Pre-test conditions
System Simulator:
– 1 NR Cell connected to 5GC, default parameters.
UE:
– UE contains either ISIM and USIM applications or only USIM application on UICC.
– UE is configured to register for IMS after switch on.
– SMS over IP is enabled.
Preamble:
– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.
9.3.3.2 Test procedure sequence
Table 9.3.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
UE is made to send a Concatenated SMS over IP (The length of SMS text is determined so that the amount of segments of the concatenated SMS is three). |
– |
– |
– |
– |
|
1A-1F |
Steps 2-7 of generic procedure specified in Table 4.9.19.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
|
– |
EXCEPTION: In parallel with Step 2, parallel behaviour defined in table 9.3.3.2-2 takes place |
– |
– |
– |
– |
|
2 |
Check: Does the UE send a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the first segment of the concatenated SMS? |
–> |
SIP MESSAGE request |
1 |
P |
|
3 |
SS responds with 202 Accepted. |
<– |
202 Accepted |
– |
– |
|
4 |
SS sends a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the short message submission report indicating a positive acknowledgement of the first segment of the concatenated SMS sent by the UE at Step 2. |
<– |
SIP MESSAGE request |
– |
– |
|
5 |
Check: Does the UE respond with 200 OK? |
–> |
200 OK |
2 |
P |
|
6 |
Check: Does the UE send a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the second segment of the concatenated SMS? |
–> |
SIP MESSAGE request |
2 |
P |
|
7 |
SS responds with 202 Accepted. |
<– |
202 Accepted |
– |
– |
|
8 |
SS sends a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the short message submission report indicating a positive acknowledgement of the second segment of the concatenated SMS sent by the UE at Step 6. |
<– |
SIP MESSAGE request |
– |
– |
|
9 |
Check: Does the UE respond with 200 OK? |
–> |
200 OK |
3 |
P |
|
10 |
Check: Does the UE send a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the final segment of the concatenated SMS? |
–> |
SIP MESSAGE request |
3 |
P |
|
11 |
SS responds with 202 Accepted. |
<– |
202 Accepted |
– |
– |
|
12 |
SS sends a SIP MESSAGE request including a vnd.3gpp.sms payload that contains the short message submission report indicating a positive acknowledgement of the final segment of the concatenated SMS sent by the UE at Step 10. |
<– |
SIP MESSAGE request |
– |
– |
|
13 |
Check: Does the UE respond with 200 OK? |
–> |
200 OK |
4 |
P |
Table 9.3.3.2-2: Parallel behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The UE transmits an RRCReconfigurationComplete message. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
9.3.3.3 Specific message contents
Table 9.3.3.3-1: MESSAGE for MO SMS (step 2, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.3 |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
– TP-UDHI=’1’B (The beginning of the TP UD field contains a Header in addition to the short message.) – TP-MR=any allowed value – TP-UD – Length of User Data Header (UDHL)=5 – Information Element Identifier (IEI)=0x00 (Concatenated short messages, 8-bit reference number) – Length of Information Element (IEIDL)=3 – Concatenated short message reference number=any allowed value – Maximum number of short messages in the concatenated short message=3 – Sequence number of the current short message=1 |
TS 24.011 [25] TS 23.040 [24] |
||
Table 9.3.3.3-2: 202 ACCEPTED (step 3, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
Table 9.3.3.3-3: Short message submission report for MO SMS (step 4, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.4 |
Table 9.3.3.3-4: 200 OK for other requests than REGISTER or SUBSCRIBE (step 5, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5, A22 |
Table 9.3.3.3-5: MESSAGE for MO SMS (step 6, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.3 |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
– TP-UDHI=’1’B (The beginning of the TP UD field contains a Header in addition to the short message.) – TP-MR= The value sent in the step1 + 1 (incremented) – TP-UD – Length of User Data Header (UDHL)=5 – Information Element Identifier (IEI)=0x00 (Concatenated short messages, 8-bit reference number) – Length of Information Element (IEIDL)=3 – Concatenated short message reference number= The same value sent in the step1 – Maximum number of short messages in the concatenated short message=3 – Sequence number of the current short message=2 |
TS 24.011 [25] TS 23.040 [24] |
||
Table 9.3.3.3-6: 202 ACCEPTED (step 7, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
Table 9.3.3.3-7: Short message submission report for MO SMS (step 8, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.4 |
Table 9.3.3.3-8: 200 OK for other requests than REGISTER or SUBSCRIBE (step 9, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5, A22 |
Table 9.3.3.3-9: MESSAGE for MO SMS (step 10, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.3 |
||||
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
– TP-UDHI=’1’B (The beginning of the TP UD field contains a Header in addition to the short message.) – TP-MR= The value sent in the step5 + 1 (incremented) – TP-UD – Length of User Data Header (UDHL)=5 – Information Element Identifier (IEI)=0x00 (Concatenated short messages, 8-bit reference number) – Length of Information Element (IEIDL)=3 – Concatenated short message reference number= The same value sent in the step5 – Maximum number of short messages in the concatenated short message=3 – Sequence number of the current short message=3 |
TS 24.011 [25] TS 23.040 [24] |
||
Table 9.3.3.3-10: 202 ACCEPTED (step 11, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
Table 9.3.3.3-11: Short message submission report for MO SMS (step 12, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.4 |
Table 9.3.3.3-12: 200 OK for other requests than REGISTER or SUBSCRIBE (step 13, table 9.3.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5, A22 |
9.4 Mobile Terminating Concatenated SMS / 5GS
9.4.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE receives a SIP MESSAGE request containing a first segment of a concatenated SMS }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery report for the first segment }
}
(2)
with { UE having sent a SIP MESSAGE request containing a delivery report for the first segment }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a second segment of a concatenated SMS }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery report for the second segment }
}
(3)
with { UE having sent a SIP MESSAGE request containing a delivery report for the second segment }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing a third segment of a concatenated SMS }
then { UE sends a 200 OK response, followed by a SIP MESSAGE request containing a delivery report for the third segment }
}
9.4.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 23.040, clause 9.2.3.23]:
The TP‑User‑Data‑Header‑Indicator is a 1 bit field within bit 6 of the first octet of the following six PDUs:
– SMS‑SUBMIT,
– SMS-SUBMIT-REPORT,
– SMS‑DELIVER,
– SMS-DELIVER-REPORT,
– SMS-STATUS-REPORT,
– SMS-COMMAND.
TP-UDHI has the following values.
Bit no. 6 0 The TP‑UD field contains only the short message
1 The beginning of the TP‑UD field contains a Header in addition to the short message.
[TS 23.040, clause 9.2.3.24]:
The length of the TP-User-Data field is defined in the PDU’s of the SM-TL (see clause 9.2.2).
The TP‑User‑Data field may comprise just the short message itself or a Header in addition to the short message depending upon the setting of TP‑UDHI.
Where the TP‑UDHI value is set to 0 the TP‑User‑Data field comprises the short message only, where the user data can be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2 [24]) data.
Where the TP‑UDHI value is set to 1 the first octets of the TP‑User‑Data field contains a Header in the following order starting at the first octet of the TP‑User‑Data field.
Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire TPDU exactly as received.
FIELD LENGTH
Length of User Data Header 1 octet
Information‑Element‑Identifier "A" 1 octet
Length of Information‑Element "A" 1 octet
Information‑Element "A" Data 0 to "n" octets
Information‑Element‑Identifier "B" 1 octet
Length of Information‑Element "B" 1 octet
Information‑Element "B" Data 0 to "n" octets
Information‑Element‑Identifier "X" 1 octet
Length of Information‑Element "X" 1 octet
Information‑Element "X" Data 0 to "n" octets
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
Figure 9.2.3.24 (a)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed 8 bit data or uncompressed UCS2 data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.
Figure 9.2.3.24 (b)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for compressed GSM 7 bit default alphabet data, compressed 8 bit data or compressed UCS2 data. The UDHL field is the first octet of the TP‑User-Data content of the Short Message.
Figure 9.2.3.24 (c)
The definition of the TP‑User‑Data‑Length field which immediately precedes the "Length of User Data Header" is unchanged and shall therefore be the total length of the TP‑User‑Data field including the Header, if present. (see 9.2.3.16).
The "Length‑of‑Information‑Element" fields shall be the integer representation of the number of octets within its associated "Information‑Element‑Data" field which follows and shall not include itself in its count value.
The "Length‑of‑User‑Data‑Header" field shall be the integer representation of the number of octets within the "User‑Data‑Header" information fields which follow and shall not include itself in its count or any fill bits which may be present (see text below).
Information Elements may appear in any order and need not follow the order used in the present document. Information Elements are classified into 3 categories as described below.
– SMS Control – identifies those IEIs which have the capability of dictating SMS functionality.
– EMS Control – identifies those IEIs which manage EMS Content IEIs.
– EMS Content – identifies those IEIs containing data of a unique media format.
It is permissible for certain IEs to be repeated within a short message, or within a concatenated message. There is no restriction on the repeatability of IEs in the EMS Content classification. The repeatability of SMS Control and EMS Control IEs is determined on an individual basis. See the IE table below for the repeatability of each IE.
In the event that IEs determined as not repeatable are duplicated, the last occurrence of the IE shall be used. In the event that two or more IEs occur which have mutually exclusive meanings (e.g. an 8bit port address and a 16bit port address), then the last occurring IE shall be used.
If the length of the User Data Header is such that there are too few or too many octets in the final Information Element then the whole User Data Header shall be ignored.
If any reserved values are received within the content of any Information Element then that part of the Information Element shall be ignored.
The support of any Information Element Identifier is optional unless otherwise stated.
The Information Element Identifier octet shall be coded as follows:
|
VALUE (hex) |
MEANING |
Classification |
Repeatability |
|
00 |
Concatenated short messages, 8-bit reference number |
SMS Control |
No |
|
01 |
Special SMS Message Indication |
SMS Control |
Yes |
|
02 |
Reserved |
N/A |
N/A |
|
03 |
Value not used to avoid misinterpretation as <LF> character |
N/A |
N/A |
|
04 |
Application port addressing scheme, 8 bit address |
SMS Control |
No |
|
05 |
Application port addressing scheme, 16 bit address |
SMS Control |
No |
|
06 |
SMSC Control Parameters |
SMS Control |
No |
|
07 |
UDH Source Indicator |
SMS Control |
Yes |
|
08 |
Concatenated short message, 16-bit reference number |
SMS Control |
No |
|
09 |
Wireless Control Message Protocol |
SMS Control |
Note 3 |
|
0A |
Text Formatting |
EMS Control |
Yes |
|
0B |
Predefined Sound |
EMS Content |
Yes |
|
0C |
User Defined Sound (iMelody max 128 bytes) |
EMS Content |
Yes |
|
0D |
Predefined Animation |
EMS Content |
Yes |
|
0E |
Large Animation (16*16 times 4 = 32*4 =128 bytes) |
EMS Content |
Yes |
|
0F |
Small Animation (8*8 times 4 = 8*4 =32 bytes) |
EMS Content |
Yes |
|
10 |
Large Picture (32*32 = 128 bytes) |
EMS Content |
Yes |
|
11 |
Small Picture (16*16 = 32 bytes) |
EMS Content |
Yes |
|
12 |
Variable Picture |
EMS Content |
Yes |
|
13 |
User prompt indicator |
EMS Control |
Yes |
|
14 |
Extended Object |
EMS Content |
Yes |
|
15 |
Reused Extended Object |
EMS Control |
Yes |
|
16 |
Compression Control |
EMS Control |
No |
|
17 |
Object Distribution Indicator |
EMS Control |
Yes |
|
18 |
Standard WVG object |
EMS Content |
Yes |
|
19 |
Character Size WVG object |
EMS Content |
Yes |
|
1A |
Extended Object Data Request Command |
EMS Control |
No |
|
1B-1F |
Reserved for future EMS features (see subclause 3.10) |
N/A |
N/A |
|
20 |
RFC 5322 E-Mail Header |
SMS Control |
No |
|
21 |
Hyperlink format element |
SMS Control |
Yes |
|
22 |
Reply Address Element |
SMS Control |
No |
|
23 |
Enhanced Voice Mail Information |
SMS Control |
No |
|
24 |
National Language Single Shift |
SMS Control |
No |
|
25 |
National Language Locking Shift |
SMS Control |
No |
|
26 – 6F |
Reserved for future use |
N/A |
N/A |
|
70 – 7F |
(U)SIM Toolkit Security Headers |
SMS Control |
Note 1 |
|
80 – 9F |
SME to SME specific use |
SMS Control |
Note 2 |
|
A0 – BF |
Reserved for future use |
N/A |
N/A |
|
C0 – DF |
SC specific use |
SMS Control |
Note 2 |
|
E0 – FF |
Reserved for future use |
N/A |
N/A |
|
Note 1: The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability is not within the scope of this document and will not be determined here. Note 2: The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and therefore, are not within the scope of this technical specification. Note 3: The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not within the scope of this document and will not be determined here. |
|||
A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the IEI is Reserved or not supported. The receiving entity calculates the start of the next information element by looking at the length of the current information element and skipping that number of octets.
The SM itself may be coded as 7, 8 or 16 bit data.
If 7 bit data is used and the TP‑UD‑Header does not finish on a septet boundary then fill bits are inserted after the last Information Element Data octet up to the next septet boundary so that there is an integral number of septets for the entire TP‑UD header. This is to ensure that the SM itself starts on an septet boundary so that an earlier Phase mobile shall be capable of displaying the SM itself although the TP‑UD Header in the TP‑UD field may not be understood.
It is optional to make the first character of the SM itself a Carriage Return character encoded according to the default 7 bit alphabet so that earlier Phase mobiles, which do not understand the TP‑UD‑Header, shall over‑write the displayed TP‑UD‑Header with the SM itself.
If 16 bit (USC2) data is used then padding octets are not necessary. The SM itself shall start on an octet boundary.
If 8 bit data is used then padding is not necessary. An earlier Phase mobile shall be able to display the SM itself although the TP‑UD header may not be understood.
It is also possible for mobiles not wishing to support the TP‑UD header to check the value of the TP‑UDHI bit in the SMS‑Deliver PDU and the first octet of the TP‑UD field and skip to the start of the SM and ignore the TP‑UD header.
[TS 23.040, clause 9.2.3.24.1]:
This facility allows short messages to be concatenated to form a longer message.
In the case of uncompressed 8‑bit data, the maximum length of the short message within the TP‑UD field is 134 (140‑6) octets.
In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the TP‑UD field is 153 (160‑7) characters. A character represented by an escape-sequence shall not be split in the middle.
In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP‑UD field is 67 ((140‑6)/2) characters. A UCS2 character shall not be split in the middle; if the length of the User Data Header is odd, the maximum length of the whole TP-UD field is 139 octets.
In the case of compressed GSM 7 bit default alphabet data, 8 bit data or UCS2 the maximum length of the compressed short message within the TP-UD field is 134 (140-6) octets including the Compression Header and Compression Footer, both or either of which may be present (see clause 3.9).
The maximum length of an uncompressed concatenated short message is 39015 (255*153) default alphabet characters, 34170 (255*134) octets or 17085 (255*67) UCS2 characters.
The maximum length of a compressed concatenated message is 34170 (255*134) octets including the Compression Header and Compression Footer (see clause 3.9 and figure 9.2.3.24.1(a) below).
Figure 9.2.3.24.1 (a): Concatenation of a Compressed short message
The gNB-DU controlling a UE-associated logical F1-connection initiates the procedure by generating a UE The Information‑Element‑Data field contains information set by the application in the SMS‑SUBMIT so that the receiving entity is able to re‑assemble the short messages in the correct order. Each concatenated short message contains a reference number which together with the originating address and Service Centre address allows the receiving entity to discriminate between concatenated short messages sent from different originating SMEs and/or SCs. In a network which has multiple SCs, it is possible for different segments of a concatenated SM to be sent via different SCs and so it is recommended that the SC address should not be checked by the MS unless the application specifically requires such a check.
The TP elements in the SMS‑SUBMIT PDU, apart from TP‑MR, TP-SRR, TP‑UDL and TP‑UD, should remain unchanged for each SM which forms part of a concatenated SM, otherwise this may lead to irrational behaviour. TP-MR must be incremented for every segment of a concatenated message as defined in clause 9.2.3.6. A SC shall handle segments of a concatenated message like any other short message. The relation between segments of a concatenated message is made only at the originator, where the message is segmented, and at the recipient, where the message is reassembled. SMS‑COMMANDs identify messages by TP-MR and therefore apply to only one segment of a concatenated message. It is up to the originating SME to issue SMS-COMMANDs for all the required segments of a concatenated message.
The Information‑Element‑Data octets shall be coded as follows.
Octet 1 Concatenated short message reference number.
This octet shall contain a modulo 256 counter indicating the reference number for a particular concatenated short message. This reference number shall remain constant for every short message which makes up a particular concatenated short message.
Octet 2 Maximum number of short messages in the concatenated short message.
This octet shall contain a value in the range 0 to 255 indicating the total number of short messages within the concatenated short message. The value shall start at 1 and remain constant for every short message which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore the whole Information Element.
Octet 3 Sequence number of the current short message.
This octet shall contain a value in the range 0 to 255 indicating the sequence number of a particular short message within the concatenated short message. The value shall start at 1 and increment by one for every short message sent within the concatenated short message. If the value is zero or the value is greater than the value in octet 2 then the receiving entity shall ignore the whole Information Element.
The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.
[TS 24.341, clause 5.3.2.3]
When a SIP MESSAGE request including a short message in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP receiver shall:
– generate a SIP response according to RFC 3428 [14];
– extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and
– create a delivery report as described in subclause 5.3.2.4. The content of the report is defined in 3GPP TS 24.011 [8].
[TS 24.341, clause 5.3.2.4]
When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the IP-SM-GW;
NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message.
b) the From header, which shall contain a public user identity of the SM-over-IP receiver.
c) the To header, which shall contain the IP-SM-GW;
d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that was received in the received short message;
e) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
f) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].
NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
9.4.3 Test description
9.4.3.1 Pre-test conditions
System Simulator:
– 1 NR Cell connected to 5GC, default parameters.
UE:
– UE contains either ISIM and USIM applications or only USIM application on UICC.
– UE is configured to register for IMS after switch on.
Preamble:
– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.
9.4.3.2 Test procedure sequence
Table 9.4.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
0A-0H |
Steps 1-8 of generic procedure specified in Table 4.9.20.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
|
1 |
SS sends a first segment of a concatenated SMS in the message-body of SIP_MESSAGE. |
<– |
SIP MESSAGE request |
||
|
2 |
Check: Does the UE respond with a 200 OK? |
–> |
200 OK |
1 |
P |
|
3 |
Check: When the payload is extracted, does the UE respond with a delivery report included in the message-body of MESSAGE? |
–> |
SIP MESSAGE request |
1 |
P |
|
4 |
SS responds with a 202 ACCEPTED. |
<– |
202 ACCEPTED |
||
|
5 |
SS sends a second segment of a concatenated SMS in the message-body of SIP_MESSAGE. |
<– |
SIP MESSAGE request |
||
|
6 |
Check: Does the UE respond with a 200 OK? |
–> |
200 OK |
2 |
P |
|
7 |
Check: When the payload is extracted, does the UE respond with a delivery report included in the message-body of MESSAGE? |
–> |
SIP MESSAGE request |
2 |
P |
|
8 |
SS responds with a 202 ACCEPTED. |
<– |
202 ACCEPTED |
||
|
9 |
SS sends a final segment of a concatenated SMS in the message-body of SIP_MESSAGE. |
<– |
SIP MESSAGE request |
||
|
10 |
Check: Does the UE respond with a 200 OK? |
–> |
200 OK |
3 |
P |
|
11 |
Check: When the payload is extracted, does the UE respond with a delivery report included in the message-body of MESSAGE? |
–> |
SIP MESSAGE request |
3 |
P |
|
12 |
SS responds with a 202 ACCEPTED. |
<– |
202 ACCEPTED |
||
9.4.3.3 Specific message contents
Table 9.4.3.3-1: MESSAGE for MT SMS (step 1, table 9.4.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.1 |
||||
|---|---|---|---|---|
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
– TP-RP=’0’B (TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER) – TP-MMS=’0’B (More messages are waiting for the MS in this SC) – TP-UDHI=’1’B (The beginning of the TP UD field contains a Header in addition to the short message.) – TP-PID=’00000000’B – TP-UD – Length of User Data Header (UDHL)=5 – Information Element Identifier (IEI)=0x00 (Concatenated short messages, 8-bit reference number) – Length of Information Element (IEIDL)=3 – Concatenated short message reference number=any allowed value – Maximum number of short messages in the concatenated short message=3 – Sequence number of the current short message=1 |
TS 24.011 [25] TS 23.040 [24] |
||
Table 9.4.3.3-2: 200 OK for other requests than REGISTER or SUBSCRIBE (step 2/6/10, table 9.4.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A22 |
Table 9.4.3.3-3: MESSAGE for delivery report (step 3/7/11, table 9.4.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.7.2 |
Table 9.4.3.3-4: 202 ACCEPTED (step 4/8, table 9.4.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
Table 9.4.3.3-5: MESSAGE for MT SMS (step 5, table 9.4.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.1 |
||||
|---|---|---|---|---|
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
– TP-RP=’0’B (TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER) – TP-MMS=’0’B (More messages are waiting for the MS in this SC) – TP-UDHI=’1’B (The beginning of the TP UD field contains a Header in addition to the short message.) – TP-PID=’00000000’B – TP-UD – Length of User Data Header (UDHL)=5 – Information Element Identifier (IEI)=0x00 (Concatenated short messages, 8-bit reference number) – Length of Information Element (IEIDL)=3 – Concatenated short message reference number=The same value sent in the step1 – Maximum number of short messages in the concatenated short message=3 – Sequence number of the current short message=2 |
TS 24.011 [25] TS 23.040 [24] |
||
Table 9.4.3.3-6: MESSAGE for MT SMS (step 9, table 9.4.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.1 |
||||
|---|---|---|---|---|
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
– TP-RP=’0’B (TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER) – TP-MMS=’0’B (More messages are waiting for the MS in this SC) – TP-UDHI=’1’B (The beginning of the TP UD field contains a Header in addition to the short message.) – TP-PID=’00000000’B – TP-UD – Length of User Data Header (UDHL)=5 – Information Element Identifier (IEI)=0x00 (Concatenated short messages, 8-bit reference number) – Length of Information Element (IEIDL)=3 – Concatenated short message reference number=The same value sent in the step1 – Maximum number of short messages in the concatenated short message=3 – Sequence number of the current short message=3 |
TS 24.011 [25] TS 23.040 [24] |
||
9.5 Mobile Originating SMS / RP-ERROR / 5GS
9.5.1 Test Purpose (TP)
(1)
with { UE being registered to IMS }
ensure that {
when { UE is made to send an SMS over IP }
then { UE sends a SIP MESSAGE request containing a short message }
}
(2)
with { UE having sent a SIP MESSAGE request containing a short message }
ensure that {
when { UE receives a 202 Accepted response, followed by a SIP MESSAGE request containing an RP-ERROR message }
then { UE sends a 200 OK response }
}
9.5.2 Conformance Requirements
The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.
[TS 24.341, clause 5.3.1.1]:
In addition to the procedures specified in subclause 5.3.1, the SM-over-IP sender shall support the procedures specified in 3GPP TS 24.229 [10] appropriate to the functional entity in which the SM-over-IP sender is implemented. The SM-over-IP sender shall build and populate RP-DATA message, containing all the information that a mobile station submitting an SM according to 3GPP TS 24.011 [8] would place, for successful delivery. The SM-over-IP sender shall parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 [8] would see, in a SM submission or status report.
NOTE 1: If the SM-over-IP sender uses SMR entity timers as specified in 3GPP TS 24.011 [8], then TR1M is set to a value greater than timer F (see 3GPP TS 24.229 [10]).
NOTE 2: If the SM-over-IP sender expects to receive a SM submit report will include the "+g.3gpp.smsip" parameter in the Contact header field when sending a REGISTER request.
[TS 24.341, clause 5.3.1.2]:
When an SM-over-IP sender wants to submit an SM over IP, the SM-over-IP sender shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the PSI of the SC of the SM-over-IP sender;
NOTE 1: The PSI of the SC can be SIP URI or tel URI based on operator policy. The PSI of the SC can be obtained using one of the following methods in the priority order listed below:
1) provided by the user;
2) if UICC is used, then:
– if an ISIM is present, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM as per 3GPP TS 31.103 [18];
– if an ISIM is not present, then the PSI of the SC is obtained from the EFPSISMSC in DF_TELECOM as per 3GPP TS 31.102 [19]; or
– if the PSI of the SC is not available in EFPSISMSC in DF_TELECOM, then the PSI of the SC contains the TS‑Service-Centre-Address stored in the EFSMSP in DF_TELECOM as per 3GPP TS 31.102 [19]. If the PSI of the SC is based on the E.164 number from the TS‑Service-Centre-Address stored in the EFSMSP in DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter format).
3) if SIM is used instead of UICC, then the PSI of the SC contains the TS‑Service Centre Address stored in the EFSMSP in DF_TELECOM as per 3GPP TS 51.011 [20]. If the PSI of the SC is based on the E.164 number from the TS‑Service-Centre-Address stored in the EFSMSP in DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter format); or
4) if neither the UICC nor SIM is used, then how the PSI of the SC is configured and obtained is through means outside the scope of this specification.
b) the From header, which shall contain a public user identity of the SM-over-IP sender;
NOTE 2: The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF.
NOTE 3: The SM-over-IP sender has to store the Call-ID of the SIP MESSAGE request, so it can associate the appropriate SIP MESSAGE request including a submit report with it.
c) the To header, which shall contain the PSI of the SC of the SM-over-IP sender;
d) the Content-Type header, which shall contain "application/vnd.3gpp.sms"; and
e) the body of the request shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].
NOTE 4: The address of the SC is included in the RP-DATA message content. The address of the SC included in the RP-DATA message content is stored in the EFSMSP in DF_TELECOM of the (U)SIM of the SM-over-IP sender.
NOTE 5: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
NOTE 6: Both the address of the SC and the PSI of the SC can be configured in the EFPSISMSC in DF_TELECOM of the USIM and ISIM respectively using the USAT as per 3GPP TS 31.111 [21].
The SM-over-IP sender may request the SC to return the status of the submitted message. The support of status report capabilities is optional for the SC.
When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP sender shall:
– if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response according to RFC 3428 [14].
if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request does not correspond to a short message submitted by the SM-over-IP sender, a 488 (Not Acceptable here) SIP response according to RFC 3428 [14].
– if SM-over-IP sender does not support In-Reply-To header usage, generate a 200 (OK) SIP response according to RFC 3428 [14]; and extract the payload encoded according to 3GPP TS 24.011 [8] for RP-ACK or RP-ERROR.
[TS 24.341 clause 5.3.1.3]:
When a SIP MESSAGE request including a status report in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP sender shall:
– generate a SIP response according to RFC 3428 [14];
– extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and
– create a delivery report for the status report as described in subclause 5.3.2.4. The content of the delivery report is defined in 3GPP TS 24.011 [8].
[TS 24.341 clause 5.3.2.4]:
When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:
a) the Request-URI, which shall contain the IP-SM-GW;
NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message.
b) the From header, which shall contain a public user identity of the SM-over-IP receiver.
c) the To header, which shall contain the IP-SM-GW;
d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that was received in the received short message;
e) the Content-Type header shall contain "application/vnd.3gpp.sms"; and
f) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].
NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.
[TS 24.011 clause 8.2.5.4]:
This element is a variable length element always included in the RP‑ERROR message, conveying a negative result of a RP‑DATA message transfer attempt or RP‑SMMA notification attempt. The element contains a cause value and optionally a diagnostic field giving further details of the error cause.
The coding of the cause value is given in table 8.4/3GPP TS 24.011. The mapping between error causes in 3GPP TS 24.011 and 3GPP TS 29.002 (MAP) is specified in 3GPP TS 23.040. Parameters included in the return error from MAP (e.g. System Failure) are mapped directly into the diagnostic field.
|
8 7 6 5 4 3 2 1 |
||
|
0 |
1 0 0 0 0 1 0 RP‑Cause IEI |
1 octet |
|
Length indicator |
1 octet |
|
|
0 ext |
Cause value |
1 octet |
|
Diagnostic field |
1 octet * |
|
Figure 8.8/3GPP TS 24.011: RP‑Cause element layout
Table 8.4/3GPP TS 24.011 (part 1): Cause values that may be contained in an RP‑ERROR message
in a mobile originating SM‑transfer attempt
|
Cause value |
Cause number |
Cause |
|
7 6 5 4 3 2 1 |
# |
|
|
0 0 0 0 0 0 1 |
1 |
Unassigned (unallocated) number |
|
0 0 0 1 0 0 0 |
8 |
Operator determined barring |
|
0 0 0 1 0 1 0 |
10 |
Call barred |
|
0 0 0 1 0 1 1 |
11 |
Reserved |
|
0 0 1 0 1 0 1 |
21 |
Short message transfer rejected |
|
0 0 1 1 0 1 1 |
27 |
Destination out of order |
|
0 0 1 1 1 0 0 |
28 |
Unidentified subscriber |
|
0 0 1 1 1 0 1 |
29 |
Facility rejected |
|
0 0 1 1 1 1 0 |
30 |
Unknown subscriber |
|
0 1 0 0 1 1 0 |
38 |
Network out of order |
|
0 1 0 1 0 0 1 |
41 |
Temporary failure |
|
0 1 0 1 0 1 0 |
42 |
Congestion |
|
0 1 0 1 1 1 1 |
47 |
Resources unavailable, unspecified |
|
0 1 1 0 0 1 0 |
50 |
Requested facility not subscribed |
|
1 0 0 0 1 0 1 |
69 |
Requested facility not implemented |
|
1 0 1 0 0 0 1 |
81 |
Invalid short message transfer reference value |
|
1 0 1 1 1 1 1 |
95 |
Semantically incorrect message |
|
1 1 0 0 0 0 0 |
96 |
Invalid mandatory information |
|
1 1 0 0 0 0 1 |
97 |
Message type non‑existent or not implemented |
|
1 1 0 0 0 1 0 |
98 |
Message not compatible with short message protocol state |
|
1 1 0 0 0 1 1 |
99 |
Information element non‑existent or not implemented |
|
1 1 0 1 1 1 1 |
111 |
Protocol error, unspecified |
|
1 1 1 1 1 1 1 |
127 |
Interworking, unspecified |
|
Note: All other cause values shall be treated as cause number 41, "Temporary Failure" |
||
9.5.3 Test description
9.5.3.1 Pre-test conditions
System Simulator:
– 1 NR Cell connected to 5GC, default parameters.
UE:
– UE contains either ISIM and USIM applications or only USIM application on UICC.
– UE is configured to register for IMS after switch on.
– SMS over IP is enabled.
Preamble:
– The UE is in test state 1N-A (TS 38.508-1 [21]) and registered to IMS.
9.5.3.2 Test procedure sequence
Table 9.5.3.2-1: Main Behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|||||||
|
U – S |
Message |
||||||||||
|
1 |
UE is made to send an SMS over IP. |
||||||||||
|
1A-1F |
Steps 2-7 of generic procedure specified in Table 4.9.19.2.2-1 of TS 38.508-1 [21] are performed. |
– |
– |
– |
– |
||||||
|
– |
EXCEPTION: In parallel with Step 2, parallel behaviour defined in table 9.5.3.2-2 takes place |
– |
– |
– |
– |
||||||
|
2 |
Check: Does the UE send a SIP MESSAGE request including a vnd.3gpp.sms payload that contains a short message? |
–> |
SIP MESSAGE request |
1 |
P |
||||||
|
3 |
SS responds with 202 Accepted. |
<– |
202 ACCEPTED |
||||||||
|
4 |
SS sends a SIP MESSAGE request including a vnd.3gpp.sms payload and RP-ERROR message. |
<– |
SIP MESSAGE request |
||||||||
|
5 |
Check: Does the UE respond with 200 OK? |
–> |
200 OK |
2 |
P |
||||||
Table 9.5.3.2-2: Parallel behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The UE transmits an RRCReconfigurationComplete message. |
–> |
NR RRC: RRCReconfigurationComplete |
– |
– |
9.5.3.3 Specific message contents
Table 9.5.3.3-1: Message for MO SMS (step 2, table 9.5.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.3, Condition A2, A5 |
Table 9.5.3.3-2: 202 ACCEPTED (step 3, table 9.5.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.3 |
Table 9.5.3.3-3: Short message submission report for MO SMS (step 4, table 9.5.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in annex A.7.4 |
||||
|---|---|---|---|---|
|
Header/param |
Cond |
Value/remark |
Rel |
Reference |
|
Message-body |
RP-ERROR message with RP‑Cause Data: Extension: not extended Cause value: 38 (Network out of order) |
TS 24.011 [25] TS 23.040 [24] |
||
Table 9.5.3.3-4: 200 OK for other requests than REGISTER or SUBSCRIBE (step 5, table 9.5.3.2-1)
|
Derivation Path: TS 34.229-1 [2], Table in subclause A.3.1, Condition A5, A22 |