Professional Documents
Culture Documents
A USSD Call Flow 3gpp
A USSD Call Flow 3gpp
0
April 2012
© 2012 3GPP2
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners
may copyright and issue documents or standards publications in individual Organizational Partner's name based
on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at
secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner's documents should be directed
to that Organizational Partner. See www.3gpp2.org for more information.
3GPP2 X.S0065 v1.0
Revision History
1
Unstructured Supplementary Service Data (USSD)
2
3
4
5
TABLE OF CONTENTS
6
7 Table of Figures.....................................................................................................................................................iii
8
9 Table of Tables ...................................................................................................................................................... iv
10
11
Foreword ................................................................................................................................................................ v
12
13
1 Introduction .............................................................................................................................................. 1
14
15 1.1 Scope.......................................................................................................................................... 1
16 1.2 Requirements Language ............................................................................................................. 1
17
18
1.3 Normative References ................................................................................................................ 2
19 1.4 Informative References .............................................................................................................. 2
20
21 2 Definitions, Symbols and Abbreviations .................................................................................................. 3
22
23
2.1 Definitions ................................................................................................................................. 3
24 2.1.1 Symbols and Abbreviations ......................................................................................... 3
25
26 3 MS registration ......................................................................................................................................... 4
27
3.1 Information flows and functions ................................................................................................ 4
28
29
3.1.1 MS initiated registration .............................................................................................. 4
30
31 4 Network initiated USSD........................................................................................................................... 6
32 4.1 Handling of network initiated USSD ......................................................................................... 6
33
34
4.2 Information flows and functions ................................................................................................ 6
35 4.2.1 Information flows ........................................................................................................ 6
36 4.2.2 Invoking USSDoperation from the USSD Gateway .................................................... 9
37 4.2.3 USSD operations at the MSC .................................................................................... 10
38
4.2.4 USSD operations at the MS ....................................................................................... 10
39
40 4.3 Handoff .................................................................................................................................... 11
41
42 5 MS initiated USSD ................................................................................................................................. 12
43
5.1 Handling of an MS initiated USSD .......................................................................................... 12
44
45 5.2 Information flows and functions .............................................................................................. 12
46 5.2.1 Information flows ...................................................................................................... 12
47
5.2.1.1 MS initiated USSD Request ................................................................. 12
48
5.2.1.2 MS initiated USSD Request followed by an immediate USSD
49
50
Release ................................................................................................. 14
51 5.2.1.3 MS initiated USSD Request after an intersystem handoff ................... 16
52 5.2.2 Handling of USSD Request at the MS....................................................................... 19
53 5.2.3 Handling of USSD request at the MSC ..................................................................... 19
54
5.2.4 Processing the USSD Request at the USSD Gateway ............................................... 20
55
56 5.3 Handoff .................................................................................................................................... 20
57
58 6 Protocol procedures ................................................................................................................................ 20
59
60
i Table of Contents
X.S0065 v1.0 USSD
1
6.1 Requirements for mobile station and USSD Gateway ............................................................. 20
2
3
7 Network Signaling Protocol ................................................................................................................... 21
4
7.1 Editorial Conventions .............................................................................................................. 21 5
Table of Contents ii
USSD X.S0065 v1.0
1
2 TABLE OF FIGURES
3
4 Figure 1 Architecture for handling of USSD .................................................................................... 1
5 Figure 2 Information flow for MS initiated registration to MSC supporting USSD ......................... 4
6
Figure 3 Information flow for network initiated USSD session ........................................................ 7
7
8
Figure 4 Information flow for MS initiated USSD session ............................................................. 13
9 Figure 5 Information flow for MS initiated USSD session which is immediately released by
10 the MS............................................................................................................................... 15
11 Figure 6 Information flow for MS initiated USSD session after handoff ....................................... 17
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
1
TABLE OF TABLES 2
3
Table 1 HLR SMSRequest Response ............................................................................................ 53 4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Table of Tables iv
USSD X.S0065 v1.0
1
2
3 FOREWORD
4
5 (This Foreword is not part of this Specification.)
6
7
This document was prepared by the Third Generation Partnership Project 2 (3GPP2) TSG-X
8
Working Group. This document is a new specification.
9
10
11 This document is subject to change following formal approval procedures. Should this
12 document be modified in the future, it will be re-released with a change-of-release date and an
13 identifying change in version number as follows:
14
15
X.S0065-000-X-n
16
17 where:
18
19 X: a numerical or uppercase alphabetic character [A, B, C, …] that indicates the
20 revision level;
21
22 n: a numeric string [1, 2, 3, …] that indicates the point release level.
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
v Foreword
X.S0065 v1.0 USSD
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
This page is intentionally left blank. 29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
Foreword vi
USSD X.S0065 v1.0
1
2
3
1 Introduction
4
5
This specification is for Unstructured Supplementary Service Data (USSD) Support.
6
7
8 1.1 Scope
9
10 The Unstructured Supplementary Service Data (USSD) mechanism enables a Mobile Station
11 (MS) and Public Land Mobile Network (PLMN) operator defined application servers to
12 communicate.
13
14
Figure 1 shows the architecture for handling of USSD sessions. The MSC retrieves the USSD
15
information as part of the subscriber profile at the time of MS registration. The USSD
16
17
transactions are carried between the USSD client in the MS and the USSD Gateway (GW) via
18
the MSC.
19
20 Application
21 Server
22
23
24
25 Applications
26
Interface
27 MS MSC
28 USSD GW
29
USSD Client
30
31
32
33
Figure 1 Architecture for handling of USSD
34
35
36 This document defines the requirements for handling USSD at the MS and network entities. It
37 does not include specification of particular applications, nor does it specify how a particular
38 application is selected.
39
40
41
This document also defines architecture requirements (stage 2) and the protocol details (stage
42
3) of the USSD.
43
44
45 1.2 Requirements Language
46
47 “Shall” and “shall not” identify requirements to be followed strictly to conform to this
48 document and from which no deviation is permitted. “Should” and “should not” indicate that
49 one of several possibilities is recommended as particularly suitable, without mentioning or
50 excluding others, that a certain course of action is preferred but not necessarily required, or
51 that (in the negative form) a certain possibility or course of action is discouraged but not
52 prohibited. “May” and “need not” indicate a course of action permissible within the limits of
53 the document. “Can” and “cannot” are used for statements of possibility and capability,
54 whether material, physical or causal.
55
56
57
58
59
60
1
1.3 Normative References 2
3
References are either specific (identified by date of publication, revision identifier, and 4
version number) or non-specific. For a specific reference, subsequent revisions may not apply. 5
For a non-specific reference, the latest revision applies. 6
7
[A.S0013] 3GPP2: A.S0013-D v3.0; 3GPP2 Interoperability Specification (IOS) for cdma2000 Access 8
[X.S0004-540] 3GPP2: X.S0004-540-E v2.0, Mobile Application Part (MAP) – Operations Signaling 22
23
Protocols; July 2007.
24
[X.S0004-550] 3GPP2: X.S0004-550-E v4.0, Mobile Application Part (MAP) – Parameters Signaling 25
[X.S0004-641] 3GPP2: X.S0004-641-E v2.0, Mobile Application Part (MAP) – SMS; July 2007. 36
37
[X.S0004-691] 3GPP2: X.S0004-691-E v3.0, Mobile Application Part (MAP) – Annexes for the 6XX Series; 38
July 2007. 39
40
[TS24.080] 3GPP: TS 24.080, Mobile radio interface layer 3 supplementary services specification; 41
format and encoding (Release 10); March 2011. 42
43
[TS22.030] 3GPP: TS 22.030, Man-Machine Interface (MMI) of the User Equipment (UE) (Release 10); 44
March 2011. 45
46
[TS23.090] 3GPP: TS 23.090, Unstructured Supplementary Service Data (USSD); Stage 2 (Release 10); 47
March 2011. 48
49
[TS24.010] 3GPP: TS 24.010; 3GPP Mobile radio interface layer 3 supplementary services specification;
50
General aspects (Release 10); June 2011.
51
52
53
1.4 Informative References 54
55
None 56
57
58
59
60
1
2 2 Definitions, Symbols and Abbreviations
3
4
5
6
2.1 Definitions
7
8 USSD Request
9
10 A message requesting information sent by a USSD Client in the MS or a USSD GW. The
11 USSD Request can be used to establish a new USSD session or can be sent in an already
12 established USSD session.
13
14
15
USSD Response
16
A response to a USSD Request a USSD Notify.
17
18
19 USSD Notify
20
21 A notification sent by a USSD GW to a USSD Client in the MS. The notification conveys
22 information that the USSD Client may display to the user.
23
24
USSD operation
25
26
A USSD Request or a USSD Notify, see [TS23.090].
27
28
29 USSD session
30
31 A set of USSD messages that all share the same session identifier.
32
33
USSD Release
34
35 A message that ends the USSD session. This message is equivalent to the RELEASE
36 COMPLETE, see [TS24.080].
37
38
39 2.1.1 Symbols and Abbreviations
40
41 MMI Man Machine Interface
42 USSD Unstructured Supplementary Service Data
43
USSD GW USSD Gateway
44
45
ADDS Application Data Delivery Service
46 DBM Data Burst Message
47 IOS Interoperability Specification
48
49
50
51
52
53
54
55
56
57
58
59
60
1
2
3 MS registration 3
4
5
6
3.1 Information flows and functions 7
8
9
3.1.1 MS initiated registration 10
11
The information flow in Figure 2 is for a mobile initiated registration on a Serving MSC that 12
supports USSD functionality. 13
14
Serving Network Home Network
15
16
17
18
19
HLR/
MS BS MSC 20
AC
21
22
23
AIR: Registration Message 24
1 25
26
IOS: LOCATION UPDATING REQUEST
27
2 28
29
MAP: AUTHREQ (MIN, AUTHR, RAND )
30
3 31
32
MAP: authreq 33
4 34
35
MAP: REGNOT (MIN) 36
5 37
38
6 40
41
42
IOS: LOCATION UPDATING ACCEPT
43
7
44
45
AIR: Registration Accepted Order
46
8
47
48
49
Figure 2 Information flow for MS initiated registration to MSC supporting USSD
50
51
1. The MS initiates a registration operation by sending the Registration Message to the 52
BS. 53
54
55
2. On reception of the Registration Message, the BS constructs the Location Updating
56
Request message, places it in the Complete Layer 3 Information message, and sends
57
it to the MSC. 58
59
60
1
4 Network initiated USSD 2
3
4
1
2
3
Serving Network Home Network
4
5
6 USSD
MS BS MSC HLR
7 GW
8
9 MAP: SMSREQUEST (MDN or IMSI)
10
1
11 MAP: smsrequest(SMS_Address )
12
2
13 MAP: SMDPP (SMS_BearData=USSD DBM (USSD Request or USSD Notify) )
14 3
15 TRAFFIC CHANNEL ESTABLISHED
16 4
17 IOS: ADDS DELIVER (ADDS User Data=USSD DBM)
18 5
19
AIR: USSD Data Burst Message (USSD Request or USSD Notify)
20 6
SMT
21
AIR: Layer 2 Ack
22
7
23
24 IOS: ADDS DELIVER ACK
25
8
26
MAP: smdpp
27 9
28
AIR: USSD Data Burst Message (USSD Response)
29
10
30
AIR: Layer 2 Ack
31
11
32
33 IOS: ADDS DELIVER (ADDS User Data=USSD DBM)
34 12
35
MAP: SMDPP (SMS_BearData=USSD DBM (USSD Response) )
36 13
37
SMT MAP: smdpp
38 14
39
40 MAP: SMDPP (SMS_BearData=USSD DBM (USSD Release) )
15
41
42 IOS: ADDS DELIVER (ADDS User Data=USSD Release)
43 16
44
AIR: USSD Data Burst Message (USSD Release)
45
17
46
SMT
47 AIR: Layer 2 Ack 18
48
49 IOS: ADDS DELIVER ACK
19
50
51
MAP: smdpp
52 20
53
TRAFFIC CHANNEL TORN DOWN
54
21
55
56
57
58
Figure 3 Information flow for network initiated USSD session
59
60
1
1. If the USSD GW does not have the address of the MSC currently serving the MS, it sends
2
a SMSREQ toward the HLR.
3
2. If the HLR has the current address of the indicated MS-based USSD Client, the HLR 4
10. The BS receives a traffic channel data burst message from an MS on the traffic channel 46
with a burst type indicating USSD. The traffic channel data burst message can contain 47
48
either a USSD Response message or a USSD Release message. The USSD DBM is
49
constructed as defined in [C.S0105]. If the MS sends a USSD Release, steps 15 through
50
20 are ignored.
51
11. If a Layer 2 Ack was requested by the MS, the BS sends a Layer 2 Ack to the MS on the 52
traffic channel. 53
54
12. The BS sends an ADDS Deliver message to the MSC. The Application Data Message of 55
the ADDS User Data Informational Element contains the USSD DBM received from the 56
MS. The Data Burst Type of the ADDS User Data Informational Element is set to USSD. 57
58
59
60
1 13. The MSC constructs a MAP SMDPP INVOKE. The SMS_BearData is constructed from
2 the ADDS User Part in the ADDS Deliver message containing the USSD response
3
message as defined in [TS24.080]. The SMDPP INVOKE is sent to the cached address,
4
see step 4.. The MSC starts timer SMT.
5
6 14. The USSD GW acknowledges the MAP SMDPP INVOKE (step 13) by sending an
7 SMDPP RETURN RESULT to the MSC. Upon receiving the MAP SMDPP RETURN
8 RESULT the MSC stops timer SMT.
9
10 NOTE: The USSD GW can send several USSD Request messages which results in
11 multiple transactions. In that case, steps 3 through 14 will be repeated for each USSD
12 Request message sent by the USSD GW.
13
14 NOTE: If the USSD GW sends a USSD Notify (see step 3) then steps 4 through step 14
15 will not be repeated.
16
17
15. To terminate the USSD transaction, the USSD GW constructs a MAP SMDPP INVOKE.
18
The SMS_BearData contains a USSD Release. The SMDPP INVOKE is sent to the
19 MSC. The USSD GW starts timer SMT.
20
16. Upon receipt of the SMDPP INVOKE, the MSC constructs an IOS ADDS Deliver
21
22
message. The Data Burst Type of the ADDS User Data Informational Element is set to
23
the USSD. The SMS_BearData parameter of the MAP SMDPP INVOKE is used to
24
create the Application Data Message of the ADDS User Data Informational Element. The
25
MSC sends the IOS ADDS Deliver message to the BS.
26
17. The BS transmits the USSD Release message over the forward traffic channel. If the BS
27
does not receive an acknowledgment after transmitting the USSD data burst message, it
28
29
shall retransmit the message. The maximum number of the retransmissions is
30
configurable by the BS manufacturer. When the BS reaches the maximum number of
31
retransmissions, it declares a Layer 2 Ack failure and initiate call clearing.
32
18. The MS acknowledges delivery of the data burst message on the traffic channel with a
33
Layer 2 Ack.
34
35 19. If the MSC has requested a response by including the tag element in the ADDS Deliver
36
message, the BS replies with an ADDS Deliver Ack message when it has received an
37
acknowledgment from the MS that the USSD Release was delivered. If a Tag element
38
was included in the ADDS Deliver message, the BS includes the Tag element in the
39
ADDS Deliver Ack message, and set it to the same value as that received in the ADDS
40
Deliver message.
41
42 20. The MSC acknowledges the MAP SMDPP INVOKE message (step 15) by sending an
43
SMDPP RETURN RESULT to the USSD GW. Upon receiving the MAP SMDPP
44
RETURN RESULT, the USSD GW stops timer SMT.
45
46 21. Anytime after step 17, the MS tears down the traffic channel.
47
48
49 4.2.2 Invoking USSDoperation from the USSD Gateway
50
51 If the USSD GW does not know the MSC address for which the USSD subscriber is currently
52 registered, the USSD GW sends a location request to the HLR. The HLR response contains
53 information as to whether the subscriber is registered and if registered what MSC is presently
54 serving the USSD subscriber.
55
56
If the subscriber is registered, the USSD GW may initiate a USSD session by sending a
57
USSD operation (i.e., USSD Request or a USSD Notify) to the MSC serving the USSD
58
59
60
1
subscriber starting an application timer. If a USSD Request was sent to the USSD subscriber,
2
the USSD GW shall wait for a USSD Response.
3
4
If the application timer expires before a USSD Response has been received, the USSD GW 5
shallend the USSD session. 6
7
8
If the USSD GW receives a USSD response, the USSD GW may end the USSD session or
9
may use the same USSD session to send further USSD messages to the USSD subscriber.
10
11
The USSD GW may initiate another USSD session with the USSD subscriber after an 12
application dependent time interval has expired. The USSD GW shall end the first USSD 13
session with the USSD subscriber before initiating a new USSD session. 14
15
16
If the USSD subscriber ends the USSD session (e.g., the user ends the application), the USSD
17
GW shall inform the application server and shall end the USSD session with the USSD 18
subscriber. 19
20
Upon receipt of a USSD operation (i.e., a USSD Request or a USSD Notify) from the USSD 23
24
GW, the MSC shall determine if the USSD subscriber addressed in the USSD operation is
25
authorized to receive USSD services. If the USSD subscriber is authorized to receive USSD
26
services, the MSC shall send the USSD operation to the MS. The MSC shall not modify the
27
USSD application data.
28
29
Upon receipt of a USSD Release the MSC shall send the USSD Release towards the MS. 30
31
32
4.2.4 USSD operations at the MS 33
34
An MS may receive a USSD operation (i.e., a USSD Request or a USSD Notify) from the
35
USSD GW at any time. 36
37
If a USSD session is active and the MS receives a USSD operation associated with a new 38
If a USSD operation indicates an alphabet that is not supported by the MS, the MS shall reject 45
the USSD operation and may inform the USSD GW of the alphabets supported by the MS, 46
[TS24.080]. 47
48
49
Upon receipt of a USSD operation, the USSD client in the MS shall determine whether the 50
USSD operation is application mode or MMI mode as defined in [TS22.030]. 51
52
53
If a USSD operation is MMI mode and the USSD operation is a USSD Request the USSD
54
Client shall start timer TRooz . The USSD Client shall display the information and await an
55
MMI response. Upon receipt of an MMI response, the MS may send a USSD Response to the
56
USSD GW or terminate the USSD session by sending a USSD Release to the USSD GW. If
57
timer TRooz expires, the USSD client in the MS shall terminate the USSD session by sending a
58
USSD Release to the USSD GW.
59
60
1 If the USSD operation is a USSD Notify and the USSD operation is MMI mode, the USSD
2 client in the MS shall display the information to the user. The USSD Client shall send a
3
USSD Response back to the USSD GW.
4
5
6 If a USSD operation is application mode and the USSD operation is a USSD Request, the
7 USSD client shall pass the information to the addressed application client within the MS. The
8 USSD client shall start timer T MB. The USSD Client awaits a response from the addressed
9 application client. Upon receipt of an application client response, the USSD client may send a
10 USSD response to the USSD GW or terminate the USSD session by sending a USSD Release
11 to the USSD GW. If timer T MB expires, the USSD client in the MS shall terminate the USSD
12 session by sending a USSD Release to the USSD GW.
13
14
15
If a USSD operation is a USSD Notify and the USSD operation is application mode, the
16
USSD client in the MS shall pass the information to the addressed application client within
17
the MS. The USSD Client shall send a USSD Response back to the USSD GW.
18
19 If the USSD client has sent a USSD Response within a USSD session, the USSD client in the
20 MS shall wait for a USSD operation or a USSD Release from the USSD GW. The USSD
21 client shall not terminate a USSD session if a USSD Response has been sent to the USSD
22
GW. The USSD client shall wait for the USSD GW to terminate the USSD session. The
23
USSD client shall handle successive USSD operations within the same USSD session.
24
25
26
27
4.3 Handoff
28
29
Inter-MSC handoff shall not have any impact on the USSD services.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
1
5 MS initiated USSD 2
3
4
1
2
3
Serving Network Home Network
4
5
6 USSD
MS BS MSC HLR
7 GW
8
9 TRAFFIC CHANNEL ESTABLISHED
10 1
11 AIR: USSD Data Burst Message (USSD Request)
12 2
13 AIR: Layer 2 Ack
14 3
15 IOS: ADDS DELIVER (ADDS User Data=USSD DBM)
16 4
17 MAP: SMDPP (SMS_BearData=USSD DBM (USSD Request) )
18 5
19 MAP: smdpp SMT
20 6
21 MAP: SMDPP (SMS_BearData=USSD DBM (USSD Release) )
22 7
23 IOS: ADDS DELIVER ACK (ADDS User Data=USSD DBM)
24 8
25
AIR: USSD Data Burst Message (USSD Release)
26
9
27
AIR: Layer 2 Ack SMT
28
10
29
30 IOS: ADDS DELIVER ACK
31 11
32 MAP: smdpp
33 12
34
TRAFFIC CHANNEL TORN DOWN
35 13
36
37
38
39 Figure 4 Information flow for MS initiated USSD session
40
41
1. If the MS is not on a traffic channel, the MS sets up traffic channel as defined in
42
[A.S0013].
43
44 2. The BS receives a traffic channel data burst message from an MS on the traffic channel
45 with a burst type indicating USSD. The USSD DBM is constructed as defined in
46
[C.S0105].
47
48 3. If a Layer 2 Ack was requested by the MS, the BS sends a Layer 2 Ack to the MS on the
49 traffic channel.
50
51 4. The BS sends an ADDS Deliver message to the MSC. The Application Data Message of
52 the ADDS User Data Informational Element contains the USSD DBM received from the
53 MS. The Data Burst Type of the ADDS User Data Informational Element is set to
54 indicate USSD.
55
56 5. The MSC determines if the MS is authorized to use USSD services by examining the
57 subscriber profile. If the subscriber profile contains a USSDAddress parameter, the MSC
58 constructs an SMDPP INVOKE. The SMS_BearData is constructed from the ADDS User
59 Part in the ADDS Deliver message. The SMDPP INVOKE is sent to the USSD Address
60
1
identified by the USSD Address parameter in the Subscriber Profile. The MSC starts
2
timer SMT. If the subscriber is not authorized to use USSD services the MSC rejects the
3
USSD session setup.
4
NOTE: There is no error message that is sent back to the MS to inform the USSD client 5
timer SMT. The SMDPP RETURN RESULT can contain an error cause code indicating 11
13. The MS releases the traffic channel. See the Call Clear via Clear Request (MS Initiated) 46
1
2
3
Serving Network Home Network
4
5
6 USSD
MS BS MSC HLR
7 GW
8
9 TRAFFIC CHANNEL ESTABLISHED
10 1
11 AIR: USSD Data Burst Message (USSD Request)
12 2
13 AIR: Layer 2 Ack
14 3
15 IOS: ADDS DELIVER (ADDS User Data=USSD DBM)
16 4
17 MAP: SMDPP (SMS_BearData=USSD DBM (USSD Request) )
18 5
19 MAP: smdpp SMT
20 6
21 AIR: USSD Data Burst Message (USSD Release)
22 7
23
AIR: Layer 2 Ack
24 8
25
26 IOS: ADDS DELIVER (ADDS User Data=USSD DBM)
9
27
28 MAP: SMDPP (SMS_BearData=USSD DBM (USSD Release) )
10
29
30 MAP: smdpp SMT
31 11
32
TRAFFIC CHANNEL TORN DOWN
33 12
34
35
36
37
Figure 5 Information flow for MS initiated USSD session which is immediately released by
38 the MS
39
40 1. If the MS is not on a traffic channel, the MS sets up traffic channel as defined in
41 [A.S0013].
42
43 2. The BS receives a traffic channel data burst message from an MS on the traffic channel
44 with a burst type indicating USSD. The USSD DBM is constructed as defined in
45 [C.S0105].
46
47 3. If a Layer 2 Ack was requested by the MS, the BS sends a Layer 2 Ack to the MS on the
48 traffic channel.
49
50
4. The BS sends an ADDS Deliver message to the MSC. The Application Data Message of
51 the ADDS User Data Informational Element contains the USSD DBM received from the
52 MS. The Data Burst Type of the ADDS User Data Informational Element is set to
53 indicate USSD.
54
55
5. The MSC determines if the MS is authorized to use USSD services by examining the
56
subscriber profile. If the subscriber profile contains a USSDAddress parameter, the MSC
57
constructs an SMDPP INVOKE. The SMS_BearData is constructed from the ADDS User
58 Part in the ADDS Deliver message. The SMDPP INVOKE is sent to the USSD Address
59 identified by the USSDAddress parameter in the Subscriber Profile. The MSC starts
60
1
timer SMT. If the subscriber is not authorized to use USSD services, the MSC rejects the
2
USSD session setup.
3
6. NOTE: There is no error message that is sent back to the MS to inform the USSD client 4
1
received from the MS. The Data Burst Type of the ADDS User Data Informational
2
Element is set to USSD.
3
5. The Serving MSC constructs an SMDBACK INVOKE (see Section 7.2.1.2). The Serving 4
MSC sets the ServiceIndicator to the “USSD” value. The SMS_BearData is constructed 5
from the ADDS User Data Informational Element in the ADDS Deliver message. The 6
SMDBACK INVOKE is sent towards the Anchor MSC, via a Tandem MSC. 7
8
6. The Tandem MSC forwards the SMDBACK INVOKE to the Anchor MSC. 9
10
7. The Anchor MSC examines the subscriber profile to determine if the MS is authorized to 11
use USSD services. If the subscriber profile contains a USSDAddress parameter, the 12
Anchor MSC constructs a SMDPP INVOKE. The SMS_BearData is constructed from the 13
SMS_BearData received in the SMDBACK INVOKE. The SMDPP INVOKE is sent to 14
the USSD Address identified by the USSDAddress parameter in the Subscriber Profile. 15
The Anchor MSC starts timer SMT. 16
17
If the subscriber is not authorized to use USSD services, the Anchor MSC rejects the 18
USSD session setup and sends a SMDBACK RETURN RESULT indicating a negative 19
acknowledgment of the SMDBACK operation invocation via the inclusion of a 20
SMS_CauseCode parameter to the Serving MSC. 21
22
NOTE: There is no error message that is sent back from the Serving MSC to the MS to 23
inform the USSD client that the USSD Request was rejected by the Anchor MSC. 24
25
8. The USSD GW caches the Anchor MSC address until the USSD session is complete. The
26
USSD GW acknowledges the SMDPP INVOKE (step 7) by sending an SMDPP 27
RETURN RESULT to the Anchor MSC. Upon receiving the SMDPP RETURN 28
RESULT, the Anchor MSC stops timer SMT. The SMDPP RETURN RESULT can 29
contain an error cause code indicating that the USSD GW has rejected the USSD 30
Request. 31
32
NOTE: The USSD GW can request further information from the USSD client resulting in
33
the USSD GW sending one or more USSD Requests within the same USSD session. 34
35
9. The Anchor MSC constructs a SMDBACK RETURN RESULT indicating positive
36
acknowledgment of the operation invocation and sends it to the Tandem MSC.
37
10. The Tandem MSC forwards the SMDBACK RETURN RESULT to the Serving MSC. 38
39
11. The USSD GW constructs a SMDPP INVOKE. The SMS_BearData parameter contains a 40
USSD Response. The USSD Response is constructed as defined in [C.S0105]. The 41
SMDPP INVOKE is sent to the Anchor MSC. The USSD GW starts timer SMT. 42
43
12. The Anchor MSC caches the address which originated the SMDPP INVOKE. The 44
Anchor MSC constructs an SMDFWD INVOKE (see Section 7.2.1.1. The Anchor MSC 45
sets the ServiceIndicator to the “USSD” value. The SMS_BearData is constructed from 46
the SMS_BearData received in the SMDPP INVOKE. The SMDBACK INVOKE is sent 47
towards the Anchor MSC, via a Tandem MSC. 48
49
13. The Tandem MSC forwards the SMDFWD INVOKE to the Serving MSC. 50
51
14. The Serving MSC constructs an IOS ADDS Deliver message. The Data Burst Type of the
52
ADDS User Data Informational Element is set to USSD. The SMS_BearData parameter 53
of the SMDFWD INVOKE is used to create the Application Data Message of the ADDS 54
User Data Informational Element. The Serving MSC sends the IOS ADDS Deliver 55
message to the BS. 56
57
15. The BS transmits the USSD message over the forward traffic channel to the MS. If the
58
BS does not receive an acknowledgment after transmitting the USSD data burst message,
59
60
1
5.2.4 Processing the USSD Request at the USSD Gateway 2
3
The USSD GW may receive a USSD Request from a USSD client in the MS at any time. The
4
USSD GW shall route the USSD Request to the appropriate application server. If the
5
application server requires more information from the USSD client, the application server
6
may request the USSD GW to send a USSD Request within the same USSD session to the 7
USSD client. 8
9
Upon completion of the session by the application server, the USSD GW shall send a USSD 10
Response to the USSD client and shall release the USSD session. 11
12
13
5.3 Handoff 14
15
16
Inter-MSC handoff shall not have any impact on the USSD services.
17
18
6 Protocol procedures 19
20
21
22
6.1 Requirements for mobile station and USSD Gateway 23
24
The USSD GW and the MS shall support all the message types for the call independent 25
supplementary services control, FACILITY, REGISTER, and RELEASE COMPLETE 26
according to [TS24.080]. The USSD GW and the MS shall support all the USSD call related 27
and USSD call independent operation types defined in [TS24.080]. According to [TS24.010], 28
call related operations are supplementary service procedures occuring during the active state 29
of a call while call independent operations occur independent of the active state of a call. The 30
USSD GW and the MS shall support all the USSD related error responses defined in 31
32
[TS24.080] and shall implement all the USSD operation types and USSD error responses
33
defined in [TS24.080]. The USSD GW and the MS shall support all the USSD data types as
34
defined in [TS24.080].
35
36
The USSD messages shall be embedded in the appropriate component (Invoke, Return Result 37
or Return Error) of the Facility information element of the appropriate message (REGISTER, 38
FACILITY or RELEASE COMPLETE), as specified in [TS24.090]. 39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
1
2 7 Network Signaling Protocol
3
4
5
6
7.1 Editorial Conventions
7
The following editorial conventions are used for Section 7:
8
9 underline: is addition to pre-existing text from other specifications.
10
11 cross out: is deleted text to pre-existing text from other specifications.
12
13
14 7.2 MAP operations
15
16
17 7.2.1 Operation definitions
18
19
7.2.1.1 SMSDeliveryForward
20
21
Note: This operation definition is a modification of the “SMSDeliveryForward ” operation
22
definition in [X.S0004-540].
23
24 The SMSDeliveryForward (SMDFWD) operation is a general purpose operation that is used
25
to convey an MS-terminated short message or in general any other information or
26
encapsulated data to the Serving MSC after handoff.
27
28 The following table lists the valid combinations of invoking and responding FEs.
29
30 INVOKING FE RESPONDING FE
31
Case 1 Anchor MSC Serving MSC
32
33 Case 2 Anchor MSC Tandem MSC
34
Case 3 Tandem MSC Tandem MSC
35
36 Case 4 Tandem MSC Serving MSC
37
38
39
The SMSDeliveryForward operation is initiated with a TCAP INVOKE (LAST). This is
40
41
carried by a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as
42
follows:
43
44
45 SMSDeliveryForward INVOKE Parameters Timer: SFT
46
47 Field Value Type Reference Notes
48
Identifier SET [NATIONAL 18] [X.S0004-
49 M
520] 1.3.2.1
50
Length variable octets [X.S0004-
51 M
52
520] 1.3.2.1
53 Contents
54
InterMSCCircuitID M [X.S0004-
55
540] 2.129
56
57 SMS_BearerData M [X.S0004-
58 540] 2.233
59
60
1
SMS_TeleserviceIdentifier M [X.S0004-
2
540] 2.246
3
ElectronicSerialNumber O [X.S0004- b 4
540] 2.112 5
IMSI O [X.S0004- h 6
540] 2.127 7
8
MobileIdentificationNumber O [X.S0004- a, h 9
540] 2.140
10
ServiceIndicator O 6.3.1.1 i 11
12
SMS_ChargeIndicator O [X.S0004- c
13
540] 2.235
14
SMS_OriginalDestinationAddress O [X.S0004- e 15
540] 2.240 16
SMS_OriginalDestinationSubaddress O [X.S0004- b 17
540] 2.241 18
19
SMS_OriginalOriginatingAddress O [X.S0004- f
20
540] 2.242
21
SMS_OriginalOriginatingSubaddress O [X.S0004- b 22
540] 2.243 23
SMS_OriginatingAddress O [X.S0004- g 24
540] 2.244 25
26
Notes: 27
28
a. Include to identify the destination MS.
29
30
b. Include if applicable.
31
c. Include if applicable. If not received, charge message originator. 32
33
d. Intentionally left for future modifications. 34
35
e. Include to identify the SME to which the short message is destined (e.g., the MDN, 36
for termination to the MS-based SME). 37
38
f. Include to identify the SME from which the short message originated (e.g., the
39
MDN, if originated by an MS-based SME).
40
(LAST). This is carried by a TCAP RESPONSE package. The Parameter Set is encoded as 50
51
follows:
52
1
Length variable octets [X.S0004-
2 M
520] 1.3.2.2
3
4 Contents
5 SMS_BearerData M [X.S0004- a
6 540] 2.233
7
8
SMS_CauseCode M [X.S0004- b
540] 2.234
9
10
11
12 Notes:
13
a. Include for positive acknowledgments, when applicable.
14
15
b. Include for all negative acknowledgments.
16
17
18
7.2.1.2 SMSDeliveryBackward
19
Note: This operation definition is a modification of the “SMSDeliveryBackward” operation
20
21
definition in [X.S0004-540].
22
The SMSDeliveryBackward (SMDBACK) operation is a general purpose operation that is
23
used to convey an MS-originated short message or in general any other information or
24
encapsulated data to the Anchor MSC after handoff.
25
26 The following table lists the valid combinations of invoking and responding FEs.
27
28 INVOKING FE RESPONDING FE
29
Case 1 Serving MSC Anchor MSC
30
31 Case 2 Serving MSC Tandem MSC
32
Case 3 Tandem MSC Tandem MSC
33
34 Case 4 Tandem MSC Anchor MSC
35
36
37
The SMSDeliveryBackward operation is initiated with a TCAP INVOKE (LAST). This is
38
carried by a TCAP QUERY WITH PERMISSION package. The Parameter Set is encoded as
39
follows:
40
41
42
43 SMSDeliveryBackward INVOKE Parameters Timer: SBT
44
45 Field Value Type Reference Notes
46 Identifier SET [NATIONAL 18] [X.S0004-
M
47 520] 1.3.2.1
48
Length variable octets [X.S0004-
49 M
520] 1.3.2.1
50
51 Contents
52
InterMSCCircuitID M [X.S0004-
53
540] 2.129
54
55 MSID M [X.S0004- h
56
540] 2.153
57 SMS_BearerData M [X.S0004-
58 540] 2.233
59
60
1
SMS_TeleserviceIdentifier M [X.S0004-
2
540] 2.246
3
ElectronicSerialNumber O [X.S0004- a 4
540] 2.112 5
ServiceIndicator O 6.3.1.1 i 6
7
SMS_ChargeIndicator O [X.S0004- b 8
540] 2.235 9
SMS_DestinationAddress O [X.S0004- c 10
540] 2.236 11
12
SMS_OriginalDestinationAddress O [X.S0004- d
13
540] 2.240
14
SMS_OriginalDestinationSubaddress O [X.S0004- a 15
540] 2.241 16
SMS_OriginalOriginatingAddress O [X.S0004- e 17
540] 2.242 18
19
SMS_OriginalOriginatingSubaddress O [X.S0004- a
20
540] 2.243
21
SMS_TransactionID O [X.S0004- g 22
540] 2.248 23
24
25
26
Notes:
27
a. Include if applicable. 28
29
b. Include if applicable. If not received, charge message originator. 30
31
c. Include if an MC address is specified by the originating SME.
32
d. Include to identify the SME to which the short message is destined (e.g., the MDN, 33
34
for termination to an MS-based SME).
35
e. Include to identify the SME from which the short message originated (e.g., the 36
1
Length variable octets [X.S0004-
2 M
520] 1.3.2.2
3
4 Contents
5 SMS_BearerData O [X.S0004- a
6 540] 2.233
7
8
SMS_CauseCode O [X.S0004- b
540] 2.234
9
10 SMS_TransactionID O [X.S0004- c
11 540] 2.248
12
13
14
Notes:
15
16 a. Include for positive acknowledgments, when applicable.
17
18
b. Include for all negative acknowledgments.
19
c. Include if TDMA to identify an MS based SMS originating SME.
20
21
22
23
7.3 MAP parameters
24
25
26
7.3.1 Parameter definitions
27
28 7.3.1.1 ServiceIndicatior
29
30 Note: This parameter definition is a modification of the “ServiceIndicator” parameter
31 definition in [X.S0004-550].
32
33 The ServiceIndicator (SRVIND) parameter indicates a type of service.
34
35
Field Value Type Reference Notes
36
37 Identifer ServiceIndicator M [X.S0004-550]
38 IMPLICIT OCTET STRING
39
Length variable octets M [X.S0004-550]
40
41 Contents
42
H G F E D C B A Octet Notes
43
44 Service 1
45
n a
46
47
Notes:
48
49 a. Ignore extra octets, if received. Send only defined (or significant) octets
50
51
52
53
54 Service (octet 1)
55
56 Decimal Value Meaning
57
0 Undefined Service.
58
59
60
1
1 CDMA OTASP Service. 2
3
2 TDMA OTASP Service.
4
3 CDMA OTAPA Service. 5
6
4 See [X.S0002]
7
5 See [X.S0002] 8
9
6 See [X.S0002] 10
11
7 USSD
12
values through 223 Reserved. Treat the same as value 0, Undefined Service. 13
14
224 through 255 Reserved for IS-41 protocol extension. If unknown, treat the 15
same as value 0, Undefined Service.
16
17
18
7.3.1.2 TransactionCapability 19
20
Note: This parameter definition is a modification of the “TransactionCapability” parameter 21
definition in [X.S0004-550]. 22
23
The TransactionCapability (TRANSCAP) parameter indicates a system’s transaction 24
capability at the current time (i.e., this capability may change over time). 25
26
27
Field Value Type Reference Notes
28
Identifer TransactionCapability M [X.S0004-550] 29
IMPLICIT OCTET STRING 30
31
Length 2 or more octets M [X.S0004-550]
32
Contents 33
34
H G F E D C B A Octet Notes
35
NAMI NDSS UZCI SPINI RUI ANN BUSY PROF 1 36
37
OTAP S&R WADD TL Multiple Terminations 2
38
A R
39
parameters. 55
56
1 The system is capable of supporting the IS-41-C profile 57
parameters. 58
59
60
1
2 Busy Detection (BUSY) (octet 1, bit B)
3
4 Value Meaning
5
6
0 The system is not capable of detecting a busy condition at the
current time.
7
8 1 The system is capable of detecting a busy condition at the
9 current time.
10
11 Announcements (ANN) (octet 1, bit C)
12
13 Value Meaning
14
15 0 The system is not capable of honoring the AnnouncementList
16 parameter at the current time.
17
1 The system is capable of honoring the AnnouncementList
18
parameter at the current time.
19
20
Remote User Interaction (RUI) (octet 1, bit D)
21
22
Value Meaning
23
24 0 The system is not capable of interacting with the user.
25
26
1 The system is capable of interacting with the user.
27
28
Subscriber PIN Intercept (SPINI) (octet 1, bit E)
29
30
Value Meaning
31
0 The system is not capable of supporting local SPINI operation
32
at the current time.
33
34 1 The system is capable of supporting local SPINI operation.
35
36 UZCapabilityIndicator (UZCI) (octet 1, bit F)
37
38 Value Meaning
39
40
0 The system is not User Zone capable at the current time.
41 1 The system is User Zone capable at the current time.
42
43 NDSS Capability (NDSS) (octet 1 bit G)
44
45 Value Meaning
46
47 0 Serving System is not NDSS capable.
48
1 Serving System is NDSS capable.
49
50
51
NAME Capability Indicator (NAMI) (octet 1 bit H)
52
Value Meaning
53
54
0 The system is not CNAP/CNAR capable.
55
56 1 The system is CNAP/CNAR capable.
57
58
59
60
1
Multiple Terminations (octet 2, bits A-D) 2
3
Value Meaning 4
5
0 The system cannot accept a termination at this time 6
(i.e., cannot accept routing information). 7
8
1 through 15 The system supports the number of call legs indicated.
9
Value Meaning 12
13
0 The system is not capable of supporting the TerminationList 14
parameter at the current time. 15
16
1 The system is capable of supporting the TerminationList
17
parameter at the current time.
18
19
WIN Addressing (WADDR) (octet 2, bit F)
20
21
Value Meaning
22
parameter. 24
25
1 The system is capable of supporting the TriggerAddressList 26
parameter. 27
28
Lower Layer Segmentation and Reassembly (S&R) (octet 2, bit G) 29
30
Value Meaning 31
32
0 The system is not capable of supporting lower layer
33
segmentation and reassembly, (S&R)
34
1 The system is capable of supporting lower layer segmentation 35
and reassembly, (S&R). 36
37
Over the Air Parameter Administration OTAPA (octet 2, bit H) 38
39
Value Meaning 40
41
0 The system is not capable of supporting the CDMA Over the 42
Air Parameter Administration.
43
Parameter Administration. 45
46
Announcement Capabilities(ANCAP) (octet 3, bit B) 47
48
Value Meaning 49
50
0 The system is not capable of supporting the enhanced call 51
redirection (e.g., generating tones and announcements) at the 52
current time. 53
54
1 The system is capable of supporting the enhanced call
redirection (e.g., generating tones and announcements) at the 55
current time. 56
57
58
59
60
1
2 MIN Extension(MX) (octet 3, bit C)
3
4 Value Meaning
5
6
0 The system does not require the MIN Extension for this MS.
7 1 The system requires that the MIN Extension for this MS be
8 transmitted.
9
10 Unstructured Supplementary Service Data (USSD) (octet 3, bit D)
11
12 Value Meaning
13
14 0 The system is not capable of supporting the CDMA Unstructured
15 Supplementary Service Data.
16
1 The system is capable of supporting the CDMA Unstructured
17
Supplementary Service Data.
18
19
20
21
22
7.3.1.3 Profile
23
Note: This parameter definition is a modification of the “Profile” parameter definition in
24
25
[X.S0004-550].
26
The Profile is a collection of the subscriber’s calling profile information. This information is a
27
list of optional parameters. The Profile macro has been defined solely for editorial
28
convenience, and does not affect the encoding in any way.
29
30
31 Profile
32
33 Type Reference Notes
34
Contents
35
36 AuthenticationCapability O [X.S0004- a
37 550] 2.12
38 CallingFeaturesIndicator O [X.S0004- b
39 550] 2.38
40
41
CarrierDigits O [X.S0004- c
550] 2.47
42
43 CDMABandClass O [X.S0004- z
44 550] 2.52
45
CDMABandClassList O [X.S0004- ad
46
550] 2.54
47
48 CDMAServiceOptionList O [X.S0004- ab
49
550] 2.77
50 DMH_AccountCodeDigits O [X.S0004- d
51 550] 2.118
52
DMH_AlternateBillingDigits O [X.S0004- d
53
550] 2.119
54
55 DMH_BillingDigits O [X.S0004- d
56 550] 2.120
57
GeographicAuthorization O [X.S0004- e
58 550] 2.132
59
60
1
MessageWaitingNotificationCount O [X.S0004- f
2
550] 2.146
3
MessageWaitingNotificationType O [X.S0004- g 4
550] 2.147 5
6
MobileDirectoryNumber O [X.S0004- x
7
550] 2.149
8
OriginationIndicator O [X.S0004- h 9
550] 2.178 10
OriginationTriggers O [X.S0004- I 11
550] 2.179 12
13
PACAIndicator O [X.S0004-
14
550] 2.181
15
PreferredLanguageIndicator O [X.S0004- k 16
550] 2.189 17
PSID_RSIDList O [X.S0004- u, aa 18
550] 2.194 19
20
QoSPriority O [X.S0004- y 21
550] 2.196
22
RestrictionDigits O [X.S0004- l 23
550] 2.216 24
25
RoutingDigits O [X.S0004- m
26
550] 2.219
27
SMS_OriginationRestrictions O [X.S0004- n 28
550] 2.255 29
SMS_TerminationRestrictions O [X.S0004- o 30
550] 2.257 31
32
SPINIPIN O [X.S0004- q
33
550] 2.261
34
SPINITriggers O [X.S0004- r 35
550] 2.262 36
37
TDMADataFeaturesIndicator O [X.S0004- ac
550] 2.281 38
39
TerminationRestrictionCode O [X.S0004- s 40
550] 2.291 41
TerminationTriggers O [X.S0004- T 42
550] 2.293 43
44
TriggerAddressList O [X.S0004- w
45
550] 2.296
46
UserGroup O [X.S0004- p 47
550] 2.303 48
USSDAddress O 7.3.1.4 ae 49
50
51
52
Notes: 53
54
a. Include if available. May not be received from systems that conform to revisions
55
prior to IS-41-C.
56
1
7.3.1.4 USSDAddress
2
3
The USSDAddress (USSDADDR) parameter is used to convey the current routing address of
4
the USSD Gateway for the purpose of sending USSD messaging from the MS USSD client to
5
the USSD Gateway. If SS7 is used for international USSD message routing, this parameter
6
should be formatted as an E.212 number. If SS7 is used for national message routing, this
7
parameter may be formatted either as an SS7 point code address or as an E.212 number.
8
9
7.3.1.4.1 USSDAddress parameter for BCD digits 10
11
12
13
14
Field Value Type Reference Notes 15
16
Identifer USSDAddress M [X.S0004-550] a
IMPLICIT DigitsType 17
18
Length variable octets M [X.S0004-550] 19
20
Contents 21
22
H G F E D C B A Octet Notes
23
Type of Digits 1 b 24
25
Nature of Number 2 c 26
27
Numbering Plan Encoding 3 d,e
28
Number of Digits 4 f 29
30
2nd BCD Digit 1st BCD Digit 5 31
32
4th BCD Digit 3rd BCD Digit 6
33
••• ••• ••• 34
35
nth BCD Digit n-1st BCD Digit m
36
37
Notes: 38
a. Refer to the DigitsType parameter type see [X.S0004-551] Section 1.2 for notes and 39
field encoding. 40
41
b. Type of Digits is ignored on receipt. 42
43
c. Nature of Number shall be National. 44
45
d. Numbering Plan supported shall include include E.164, E.212, X.121, and Private
46
numbering plan.
47
1
Length variable octets M [X.S0004-550]
2
3
4 Contents
5
H G F E D C B A Octet Notes
6
7 Type of Digits 1 b
8
9
Nature of Number 2 c
10 Numbering Plan Encoding 3 d,e
11
12 MSB 4
13
5
14 IP Address
15 6
16
17 LSB 7
18
19 Notes:
20
a. Refer to the DigitsType parameter type see [X.S0004-551] Section 1.2 for notes and
21
field encoding.
22
23
b. Type of Digits is ignored on receipt.
24
25 c. Nature of Number shall be National.
26
27 d. Numbering Plan shall be SS7 PC and SSN for this parameter variant.
28
29
e. Encoding shall be octet string for this parameter variant.
30
7.3.1.4.3 USSDAddress Encoding for an ANSI SS7 Point Code Address
31
32
33
34
35 Field Value Type Reference Notes
36
37
Identifer USSDAddress M [X.S0004-550] a
38
IMPLICIT DigitsType
39 Length variable octets M [X.S0004-550]
40
41
Contents
42
43 H G F E D C B A Octet Notes
44
45
Type of Digits 1 b
46 Nature of Number 2 c
47
48 Numbering Plan Encoding 3 d,e
49
Point code--Member Number 4
50
51 Point code--Cluster Number 5
52
53
Point code--Network Number 6
54
Subsystem Number 7
55
56
Notes:
57
58 a. Refer to the DigitsType parameter type see [X.S0004-551] Section 1.2 for notes and
59 field encoding.
60
1
b. Type of Digits is ignored on receipt.
2
c. Nature of Number shall be National. 3
4
d. Numbering Plan shall be IP for this parameter variant. 5
6
e. Encoding shall be octet string for this parameter variant. 7
8
9
Contents 21
22
H G F E D C B A Octet Notes 23
24
Type of Digits 1 b
25
Nature of Number 2 c 26
27
Numbering Plan Encoding 3 d,e 28
4 f 29
30
Point Code
5 31
32
6
33
Notes: 36
37
a. Refer to the DigitsType parameter type see [X.S0004-551] Section 1.2 for notes and 38
field encoding. 39
40
b. Type of Digits is ignored on receipt.
41
1
2
7.4 MAP signaling procedures
3
4
7.4.1 Intersystem procedures
5
6
7 7.4.1.1 SMS delivery point-to-point
8
9 7.4.1.1.1 MSC receiving an SMSDeliveryPointToPoint INVOKE
10
11 Note: This procedure is a modification of the “MSC Receiving an SMSDeliveryPointToPoint
12 INVOKE” procedure in [X.S0004-641].
13
14
Upon receipt of an SMSDeliveryPointToPoint INVOKE for an intended MS or for broadcast,
15 the receiving MSC shall do the following:
16
1 IF the message can be processed:
17
18 1-1 IF the ServiceIndicator parameter set to either the CDMA OTASP Service or the
19 CDMA OTAPA Service is received:
20
1-1-1 IF the SMS_BearerData parameter has a non-zero length:
21
22 1-1-1-1 Execute the “MSC Receiving SMDPP INVOKE for OTA Data Message
23 Exchange” task (see Part 640, sec. 44.2 [X.S0004-640], section. 44.2).
24
1-1-2 ELSEIF the ActionCode parameter is received:
25
26
1-1-2-1 CASE ActionCode OF:
27 1-1-2-2 Attach MSC to OTAF:
28
1-1-2-2-1 IF the ServiceIndicator parameter is set to the CDMA OTASP Service
29
30
value:
31 1-1-2-2-1-1 Execute the “MSC Receiving SMDPP INVOKE to Attach with
32 OTAF” task (see Part 640, sec. 43.3 [X.S0004-640], section. 43.3).
33
1-1-2-2-2 ELSEIF the ServiceIndicator parameter is set to the CDMA OTAPA
34
Service value:
35
36 1-1-2-2-2-1 Include the SMS_CauseCode parameter set to indicate Unexpected
37 parameter value.
38
1-1-2-2-2-2 Send a RETURN RESULT.
39
40 1-1-2-2-3 ENDIF.
41 1-1-2-3 Initiate RegistrationNotification::
42
1-1-2-3-1 Execute the “MSC Receiving SMDPP INVOKE for Registration of
43
44
MS” task (see Part 640, sec. 45.2 [X.S0004-640], section 45.2).
45 1-1-2-4 Release TRN:
46
1-1-2-4-1 IF the ServiceIndicator parameter is set to the CDMA OTASP Service
47
value:
48
49 1-1-2-4-1-1 Execute the “MSC Receiving SMDPP INVOKE to Release TRN”
50 task (see Part 640, sec. 43.5 [X.S0004-640], section 43.5).
51
1-1-2-4-2 ELSEIF the ServiceIndicator parameter is set to the CDMA OTAPA
52
Service value:
53
54 1-1-2-4-2-1 Include the SMS_CauseCode parameter set to indicate Unexpected
55 parameter value.
56 1-1-2-4-2-2 Send a RETURN RESULT.
57
58
1-1-2-4-3 ENDIF.
59 1-1-2-5 Record NEWMSID:
60
MSID” task (see Part 640, sec. 45.4 [X.S0004-640], section 45.4). 2
3
1-1-2-6 DEFAULT: 4
parameter value. 6
7
1-1-2-6-2 Send a RETURN RESULT. 8
1-1-2-7 ENDCASE. 9
10
1-1-3 ENDIF.
11
1-1-4 Exit this task. 12
1-2 ENDIF. 13
14
1-3 IF the ServiceIndicator parameter indicating USSD (Unstructured Supplementary 15
Service Data) is received: 16
1-3-1 Execute the “MSC Receiving an SMDPP INVOKE for USSD Exchange” task 17
1-4 ENDIF; 22
23
1-5 IF the SMS_OriginalDestinationAddress parameter is received: 24
1-5-1 Set the original destination address with the address in the received 25
SMS_OriginalDestinationAddress parameter. 26
27
1-6 ELSE: 28
1-6-1 Include the SMS_CauseCode parameter set to Missing Expected Parameter. 29
30
1-6-2 Send a RETURN RESULT.
31
1-6-3 Exit this task. 32
1-7 ENDIF. 33
34
1-8 IF the SMS_OriginatingAddress parameter is received: 35
1-10-1 Set the original originating address with the address in the received 40
SMS_OriginalOriginatingAddressparameter. 41
42
1-11 ELSE: 43
1-13-1 Set the original originating subaddress with the address in the received 51
SMS_OriginalOriginatingSubaddress parameter. 52
53
1-14 ENDIF 54
1-15-7 ENDIF. 1
2
1-15-8 Send a RETURN RESULT. 3
(if available) and BroadcastPeriodicity value (if available) and execute the 5
“MSC Initiating Broadcast SMD-Request Across the Air Interface” task (see 6
Part 691, sec. 4.7 [X.S0004-691], Section 4.7) when the initial broadcast of this 7
1-15-10-1 Execute the “MSC Initiating Broadcast SMD-Request Across the Air 12
Interface” task (see Part 691, sec. 4.7 [X.S0004-691], Section 4.7) when 13
1-19 ENDIF. 28
29
1-20 IF an ElectronicSerialNumber parameter is received: 30
SMS_NotificationIndicator parameters. 45
46
1-22-1-1-1-3 IF the system is a CDMA System AND IF the MS last registered 47
in an area close to the system border AND IF the MSC is 48
configured to support border system SMS message delivery: 49
possible message.) 2
3
1-22-1-4-2-1-3 ENDIF. 4
1-22-1-4-2-2 ENDIF. 5
6
1-22-1-4-2-3 IF the SMS_MessageCount parameter was not received OR IF the 7
received SMS_MessageCountparameter is zero: 8
1-22-1-4-2-3-1 Clear the SMS Delivery Pending Flag for this MS. 9
10
1-22-1-4-2-4 ENDIF.
11
1-22-1-4-3 ENDIF. 12
1-22-1-5-2-2 Clear the SMS Delivery Pending Flag for this MS. 24
25
1-22-1-5-3 ELSEIF the SMS_CauseCode was for a temporary condition: 26
1-22-1-5-3-1 IF the SMS_NotificationIndicator parameter was present in the 27
SMSDeliveryPointToPoint INVOKE and the 28
SMS_NotificationIndicator indicates Do not notify when available: 29
30
1-22-1-5-3-1-1 Relay all received parameters.
31
1-22-1-5-3-2 ELSE (notification was requested): 32
1-22-1-5-3-2-1 Set the SMS Delivery Pending Flag for this MS. 33
34
1-22-1-5-3-2-2 Include the SMS_CauseCode parameter set to SMS Delivery 35
Postponed. 36
1-22-1-6 ENDIF. 44
45
1-22-1-7 Send a RETURN RESULT. 46
1-22-2 ELSE (MSC is not allowed to terminate a short message to the destination MS 47
48
1-22-2-1 Include the SMS_CauseCode parameter indicating termination is SMS
49
Termination Denied.
50
1-22-2-2 Send a RETURN RESULT. 51
1-22-3 ENDIF. 52
53
1-23 ELSE (MS is not anchored by this MSC: 54
address. 56
57
1-23-2 Send a RETURN RESULT. 58
1-24 ENDIF. 59
60
1-11 Return to the calling task with the received parameters and the returned indication. 5
6
2 ELSE (request cannot be processed): 7
2-1 Include the SMS_CauseCode parameter indicating the appropriate value. 8
9
2-2 Return to the calling task indicating denied.
10
3 ENDIF. 11
12
4 Exit this task.
13
14
7.4.1.2 SMS delivery point-to-point for USSD exchange 15
16
7.4.1.2.1 MSC receiving an SMDPP INVOKE for USSD exchange
17
18
1 IF the request can be processed:
19
1-1 IF the MS has performed an intersystem handoff forward: 20
section 2.1). 22
23
1-1-2 Exit this task. 24
appropriately. 30
31
1-2-2-2 Exit this task. 32
1-2-3 ENDIF. 33
34
1-3 ENDIF. 35
1-4 Execute “MSC Sending the USSD Message to the MS” (See Section 6.4.3.3). 36
37
2 ELSE (request cannot be processed):
38
2-1 Include the SMS_CauseCode parameter indicating the appropriate value. 39
40
3 ENDIF.
41
4 Exit this task. 42
43
7.4.1.2.2 MSC sending a USSD message to the MS 44
45
1 IF the Target MS is not assigned to a traffic channel:
46
1-1 Include the SMS_CauseCode parameter set to identify the failure appropriately. 47
1
1-5-1 Set the original destination address with the address in the received
2
SMS_OriginalDestinationAddress parameter.
3
1-6 ELSE: 4
5
1-6-1 Include the SMS_CauseCode parameter set to Missing Expected Parameter.
6
1-6-2 Send a RETURN RESULT. 7
1-14-3 ENDIF. 50
51
1-15 ENDIF. 52
1
2
3
4
7.4.1.4 SMSDeliveryBackward
5
7.4.1.4.1 MSC receiving an SMSDeliveryBackward INVOKE
6
7
Note: This procedure is a modification of the “MSC Receiving an SMSDeliveryBackward
8
INVOKE” procedure in [X.S0004-641].
9
10 Upon receipt of an SMSDeliveryBackward INVOKE, the MSC shall do the following:
11
12
13 1 IF the received message can be processed:
14 1-1 IF the SMS_DestinationAddress parameter is received:
15
16
1-1-1 Set the destination address with the address in the received
17
SMS_DestinationAddress parameter.
18 1-2 ENDIF.
19
1-3 IF the SMS_OriginalDestinationAddress parameter is received:
20
21 1-3-1 Set the original destination address with the address in the received
22 SMS_OriginalDestinationAddress parameter.
23
1-4 ELSE:
24
25 1-4-1 Include the SMS_CauseCode parameter set to Missing Expected Parameter.
26 1-4-2 Send a RETURN RESULT.
27
28
1-4-3 Exit this task.
29 1-5 ENDIF.
30
1-6 IF the SMS_OriginalOriginatingAddress parameter is received:
31
32 1-6-1 Set the original originating address with the address in the received
33 SMS_OriginalOriginatingAddress parameter.
34 1-7 ENDIF.
35
36
1-8 Relay all parameters received.
37 1-9 IF the MSC is the Anchor MSC:
38
1-9-1 Execute the “Anchor MSC Initiating SMS Delivery Point-To-Point” task
39
(7.4.1.1.2).
40
41 1-9-2 Relay all parameters received.
42
1-10 ELSE (the MSC is a Tandem MSC):
43
44 1-10-1 Execute the “MSC Initiating SMS Delivery Backward” task (7.4.1.4.2).
45 1-10-1-1 Discard the InterMSCCircuitID parameter.
46
47
1-10-1-2 Relay all parameters received.
48 1-10-2 ELSE (the handing-off system does not support SMS):
49
1-10-2-1 Include the SMS_CauseCode parameter set to Network failure.
50
51 1-10-3 ENDIF.
52 1-11 ENDIF.
53
54
1-12 Send a RETURN RESULT towards the Serving MSC.
55 2 ELSE (the received message cannot be processed):
56
2-1 Include the SMS_CauseCode parameter indicating the proper value.
57
58 2-2 Send a RETURN RESULT.
59
60
1
3 ENDIF.
2
4 Exit this task. 3
4
7.4.1.4.2 MSC initiating SMSDeliveryBackward 5
6
Note: This procedure is a modification of the “MSC Initiating SMS Delivery Backward”
7
procedure in [X.S0004-641]. 8
9
Upon request to send an MS-originated SMS point-to-point message up the handoff chain, the
10
MSC shall do the following:
11
12
1 Include InterMSCCircuitID parameter set to the trunk used in the direction toward the
13
Anchor MSC.
14
2 IF the MSC is the Serving MSC: 15
2-2 ENDIF. 19
20
2-3 Include the SMS_OriginalDestinationAddress parameter set to the original
21
destination address (provided by the MS). 22
2-4 IF the original originating address was provided (by the MS): 23
3-1 Include all parameters received from the calling task (see Part 540 [X.S0004-540]). 31
32
4 ENDIF. 33
5 Send a SMSDeliveryBackward INVOKE message toward the Destination Address. 34
35
6 Start the Short Message Backward Timer (SBT).
36
7 WAIT for an SMS Delivery Backward response: 37
38
8 WHEN a RETURN RESULT is received:
39
8-1 Stop the timer (SBT). 40
8-2-1-2 ENDIF. 50
51
8-2-2 ENDIF. 52
8-3-1 Return to the calling task with the SMS_CauseCode indicating Other Network 57
58
Problem.
59
60
1 8-4 ENDIF.
2
3
9 WHEN a FacilitiesRelease INVOKE is received :
4 9-1 Stop the timer (SBT).
5
9-2 Exit this task.
6
7 10 WHEN a RETURN ERROR1 is received :
8
10-1 Stop the timer (SBT).
9
10 10-2 Return to the calling task with the SMS_CauseCode indicating Other Network
11 Problem.
12 11 WHEN a REJECT is received:
13
14
11-1 Stop the timer (SBT).
15 11-2 CASE reject problem specifier OF:
16
11-3 Unrecognized component,
17
18 11-4 Incorrect component portion,
19
11-5 Badly structured component portion,
20
21 11-6 Incorrect parameter,
22 11-7 Unrecognized package type,
23
24
11-8 Incorrect transaction portion,
25 11-9 Badly structured transaction portion:
26
11-9-1 Return to the calling task with the SMS_CauseCode indicating Encoding
27
Problem.
28
29 11-10 Unrecognized operation code:
30 11-10-1 Return to the calling task with the SMS_CauseCode indicating SMS not
31 supported.
32
33
11-11 DEFAULT:
34 11-12 Return to the calling task with the SMS_CauseCode indicating Network failure.
35
11-13 ENDCASE:
36
37 12 WHEN the timer (SBT) expires:
38
12-1 Return to the calling task with the SMS_CauseCode indicating Network failure.
39
40 13 ENDWAIT.
41
42 7.4.1.5 SMS Notification
43
44 7.4.1.5.1 HLR initiating SMS Notification
45
46 Note: This procedure is a modification of the “HLR Initiating SMS Notification” procedure in
47 [X.S0004-641].
48
49 Upon request to send an SMSNotification message, the HLR shall do the following:
50
51
1 Include the ElectronicSerialNumber parameter set to the ESN of the desired MS.
52 2 Include the MSID parameter set to the MIN or IMSI of the desired MS.
53
54
3 IF the notification is being issued, for any of the TDMA teleservices, independent of a
55
postponed (previous) SMSRequest to initiate a SMS teleservice on an MS:
56
57
1
58 The sending of an SMS DeliveryBackward RETURN ERROR is not recommended and error tables are not supplied.
59
60
3-1 Include the SMSTeleserviceIdentifier parameter set to the teleservice for which the 1
5 IF MS is denied: 5
6
5-1 Include the SMS_AccessDeniedReason parameter set to Denied. 7
7-1 Include the SMS_Address parameter set to the temporary SMS routing address of the 12
13
desired MS for SMS, or set to temporary MSC routing address for CDMA OTAPA,
14
or set to temporary MSC routing address for USSD.
15
8 ENDIF. 16
9 Send an SMSNotification message toward the MS’s MC, for SMS, or toward the OTAF, 17
18
for OTAPA or toward the USSD Gateway, for USSD.
19
10 Start the SMS Notification Timer (SNT). 20
21
11 WAIT for a SMS Notification response:
22
12 WHEN a RETURN RESULT is received: 23
15 ENDWAIT. 40
41
16 Exit this task. 42
43
7.4.1.6 SMS Request 44
45
7.4.1.6.1 HLR receiving an SMSRequest INVOKE 46
47
Note: This procedure is a modification of the “HLR receiving an SMSRequest INVOKE” 48
procedure in [X.S0004-641]. 49
50
Upon receipt of a SMSRequest INVOKE, the HLR shall do the following: 51
52
1 IF the message can be processed:
53
1-1 IF CDMA service: 54
1-1-1 IF the addressed MS is not known, OR IF the MS is known, but is not 55
1-1-5-1-2 ELSE: 1
2
1-1-5-1-2-1 IF the USSD Delivery Pending Flag for this MS is not already set: 3
1-1-5-1-2-1-1 Set the USSD Delivery Pending Flag for this MS, storing the 4
was received. 12
13
1-1-5-1-2-3 ENDIF. 14
1-1-5-1-2-4 Include the SMS_AccessDeniedReason parameter set to indicate 15
Postponed. 16
17
1-1-5-1-3 ENDIF.
18
1-1-5-2 ELSE: 19
1-1-5-2-1 Include the SMS_Address parameter set to the current address for the 20
MS. 21
22
1-1-5-3 ENDIF. 23
1-1-8 ENDIF. 32
33
1-2 ELSEIF TDMA service: 34
1-2-1 IF the addressed MS is not known, OR IF the MS is known, but is not 35
authorized for SMS: 36
37
1-2-1-1 Include the SMS_AccessDeniedReason parameter set to Denied.
38
1-2-2 ELSEIF (the teleservice indicated by the SMS_TeleserviceIdentifier parameter 39
is unknown or is not supported): 40
1-4 IF the temporary SMS routing address is current (as determined by the HLR, e.g., 48
49
some time between never to until revoked) for the addressed MS:
50
1-4-1 Include the SMS_Address parameter set to the current SMS address for the MS. 51
1
3 ENDIF.
2
4 Exit this task. 3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
1
RETURN RESULT Note: Only RETURN RESULT operations needing 2
SMS_AccessDeniedReason clarification have been included. 3
Denied An HLR record exists for the supplied MSID parameter, but a 4
be resumed. 19
20
Unavailable An HLR record exists for the supplied MSID parameter but a 21
SMS routing address to the supplied MIN or IMSI has been 22
temporarily denied (e.g., no routing address, MS is busy, MS is 23
not registered, No Page Response, MS is unavailable, MS is 24
inactive, other temporary SMS delivery trouble). Also when the 25
Serving VLR (or other functional entity) responded 26
OperationNotSupported or did not respond. The HLR will not 27
notify the requesting MC when SMS delivery to the supplied 28
MSID can be resumed. 29
30
Invalid The teleservice indicated by the SMS_TeleserviceIdentifier
31
parameter is unknown or is not supported. 32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60