8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January http://slidepdf.com/reader/full/3gpp2-ns0015-version-100-version-date-january 1/201 3GPP2 N.S0015 Version 1.0.0 Version Date: January 28, 2000 ANSI-41-D Miscellaneous Enhancements Revision: 0 COPYRIGHT 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 [email protected]. Requests to reproduce individual Organizational Partner’s documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
5.X1 Successful Handoff-Back with Tandem via FacilitiesDirective (PathMinimization is not supported). ..... ...... ..... ...... ..... ...... ..... ...... ..... ...... ..... ... 4
5.X2 Successful Handoff-Back with Tandem via FacilitiesDirective when themethod of Handoff-To-Third with Tandem and Path Minimization isinvolved ................................................. ............................................. 6
5.X3 Successful Handoff-Back with Tandem via HandoffToThird when the methodof Handoff-To-Third with Tandem and Path Minimization is involved .. .. .. .. .. .. .7
5.6 Successful HandoffToThird with Tandem and Path Minimization....................9
5.4.x1 VLR Initiated Unique Challenge When SSD is Shared, Unique ChallengeFails.......................... ........................................................ ............... 32
5.4.2 Origination with Authentication............................................................. 33
6.1.5a CD Invocation with No Answer or No Page Response plus Transfer to HLRInhibited.................................................................... ........................ 34
6.1.5b CD Invocation with No Answer or No Page Response plus Transfer to HLRInhibited and Serving MSC Identified Announcements................................ 34
6.1.5c CD Invocation with No Answer or No Page Response plus Transfer ToHLR Inhibited and Serving System Identified Announcements in the CalledParty Preferred Language.............. ............. ............ ............ ............. ....... 34
6.1.9 TLDN Call Arrival with Intersystem Paging ............................. ............... 35
6.1.13a CD Invocation with improved Intersystem Paging to an Idle MS.................. 35
6.1.13b CD to a Non-Public System.................................................................. 35
6.1.13c Non-Public Registration with Public Re-registration.................................. 38
6.8.x CNIP Invocation to a Forwarded-To Subscriber...... ..... ..... ..... ...... ..... ...... ... 39
6.13.4 MWN via an MS Indication or Message Count or Both... ..... ..... ..... ..... ..... .. 39
6.13.X1 Message Waiting Update from a Voice Mail System (proprietary interface) .. . 40
6.13.X2 Message Waiting Update from a Message Center or Voice Mail System.. .. .. . 406.13.X3 Message Waiting Update from a Voice Mail System............................... .. 40
6.14.6 MAH Invocation with a No Answer MAH Group Member.......................... 40
7.x+0 Short Message from MS-Based SME in Anchor System and AcknowledgedAfter Handoff............................................................... ....................... 42
7.x+1 Short Message from MS-Based SME in Tandem System and AcknowledgedAfter Handoff (via a Tandem System).. ..... ..... ...... ..... ...... ..... ...... ..... ...... ... 42
7.x+2 Short Message from MS-Based SME in Anchor System and AcknowledgedAfter Handoff (via a Tandem System).. ..... ..... ...... ..... ...... ..... ...... ..... ...... ... 43
7.x+3 Short Message from MS-Based SME in Serving System and AcknowledgedAfter Handoff Back ..... ..... ...... ..... ...... ..... ...... ..... ...... ..... ...... ..... ...... ..... .. 43
7.x+4 Short Message from MS-Based SME in Serving System and AcknowledgedAfter Handoff Back (via a Tandem System).................... ................ ........... 43
7.x+5 Short Message from MS-Based SME in Serving System and AcknowledgedAfter Handoff To Third to a New Serving System................................... ... 44
Figure X1 Successful Handoff-Back with Tandem via FacilitiesDirective (PathMinimization is not supported).... ...... ..... ...... ..... ...... ..... ...... ..... ...... ..... ..5
Figure X2 Successful Handoff-Back with Tandem via FacilitiesDirective when themethod of Handoff-To-Third with Tandem and Path Minimization isinvolved ................................. ................................. .........................7
Figure X3 Successful Handoff-Back with Tandem via HandoffToThird when themethod of Handoff-To-Third with Tandem and Path Minimization isinvolved ................................. ................................. .........................8
Figure 23 Successful HandoffToThird with Tandem and Path Minimization.................9
Figure 1 Initiate SSD Update (New SSD shared for SSD Update)...........................11
Figure 4.34.T1 Successful SMSRequest during OTASP: MS-Based SME.. ..... ..... ..... ..... .. 28Figure 8.TT.5 Serving MSC Attachment to the OTAF: Reprogramming........................ 29
Figure 5.4.x Authentication on Voice Channel, Access Denied, HLR/AC givesdirective to route call............... ............ ............. ............ ............ ......... 30
Figure 5.4.x1 VLR Unique Challenge When SSD is Shared, Unique Challenge Fails.. .... . 32
Figure 94 Origination with Authentication.......................................................... 33
Figure 117a CD Invocation with No Answer or No Page Response plus Transfer ToHLR Inhibited ............................ .................................. ................... 34
Figure 117b CD Invocation with No Answer or No Page Response plus Transfer ToHLR Inhibited and Serving System Identified Announcements .. .. .. .. .. .. .. .. .. 34
Figure 117c CD Invocation with No Answer or No Page Response plus Transfer ToHLR Inhibited and Serving System Identified Announcements in theCalled Party Preferred Language ..... ..... ..... ..... ...... ..... ...... ..... ...... ..... ..... 34
Figure 6.1.13a CD Invocation with Improved Intersystem Paging to an Idle MS............... 35
Figure 6.1.13b CD to a Non-Public System............................................................... 36
Figure 6.1.13c Non-Public Registration with Public Re-registration............................... 38
Figure 6.8.x CNIP Invocation to a Forwarded-To Subscriber...................................... 39
Figure 160 MWN via an MS Indication or Message Count or Both...........................39
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
PN-3590 (ANSI-41-E) (Unofficial Tracking Document - Subject To Change) TR45.2.III/2000.01.12#___
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
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
ix List Of Figures
Figure 6.13.X1 Message Waiting Update from a Voice Mail System (proprietaryinterface)......................................................................................... 40
Figure 6.13.X2 Message Waiting Update from a Message Center or a Voice Mail System.. . 40
Figure 6.13.X3 Message Waiting Update from a Voice Mail System.... ..... ..... ..... ..... ..... .. 40
Figure 167 MAH Invocation with a No Answer MAH Group Member....................... 40
Figure 175 PL Registration (variable option)........................................................41Figure x+0 Short Message f rom MS-Based SME in Anchor System and
Acknowledged After Handoff............................................. .................. 42
Figure x+1 Short Message from MS-Based SME in Tandem System andAcknowledged After Handoff (via a Tandem System) .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . 43
Figure x+2 Short Message f rom MS-Based SME in Anchor System andAcknowledged After Handoff (via a Tandem System) .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . 43
Figure x+3 Short Message from MS-Based SME in Serving System andAcknowledged After Handoff Back ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... . 43
Figure x+4 Short Message from MS-Based SME in Serving System andAcknowledged After Handoff Back (via a Tandem System)................. ....... 43
Figure x+5 Short Message from MS-Based SME in Serving System and
Acknowledged After Handoff To Third to a New Serving System............. .. 44Figure 216a Postponed MSC SMSNotification with Multiple SMDPPs..................... 44
Figure 8.CC.9 Registration Following Successful OTA............................................... 46
Figure 8.CC.10 Notification of Newly Assigned MIN (or IMSI M) or IMSI or BothFollowing Successful OTA. ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ...... ..... .. 48
Figure x+0 Short Message f rom MS-Based SME in Anchor System andAcknowledged in new Serving System after Handoff .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..173
Figure x+1 Short Message f rom MS-Based SME in Anchor System andAcknowledged in new Serving System after Handoff (via a TandemSystem).........................................................................................174
Figure x+2 Short Message from MS-Based SME in Tandem System andAcknowledged in new Serving System after Handoff (via TandemSystem).........................................................................................175
Figure x+3 Short Message from MS-Based SME in Serving System andAcknowledged in Anchor System after Handoff Back..............................176
Figure x+4 Short Message from MS-Based SME in Serving System andAcknowledged in Anchor System after Handoff Back (via a TandemSystem).........................................................................................177
Figure x+5 Short Message from MS-Based SME in Serving System andAcknowledged in new Serving System after Handoff To Third..................178
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
TR45.2.III/2000.01.12#___ (Unofficial Tracking Document - Subject To Change) PN-3590 (ANSI-41-E)
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
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
Contribution History XVI
10.3 TR45.2/99.05.17.5
T1S1 liaison
Incorporate into Chapter.5 identification of SSN values inANSI T1.112 that have been reserved to align with theITU-T. (Note: deleted as per agreement.)
TR45.2/99.06.14#14
Motorola
Provide Numbering Plan variant text clarification(remanded PN-4197 ballot response comments).
TR45.2/99.06.14#19
Lucent Technologies
DisplayText2 parameter enhancement to support multiple
character sets per message and support for additionalcharacter sets.
This is a change to Miscellaneous-10 .
TR45.2.2/99.06.16#19
LG Sansys
Provide error correction to IS-778 “Wireless AuthenticationEnhancements Descriptions”; Chapter 3, Section 5.4.2and correction to IS-778 Chapter 5, Section 6.5.2.154.
This is a change to IS-778.
TR45.2.2/99.06.16#20
LG Sansys
Provide clarification note to ASREPORT Stage-2.
TR45.2.2/99.06.16#21
LG Sansys
Provide parameters passed on authreq responseclarification.
Portions are a change to IS-778.
TR45.2.3/98.08.19#16
Ericsson
Enhancement to support SMDPP acknowledgmentdelivery to a mobile station after handoff.
TR45.2.3/99.06.17#4
Ericsson
Provide the AC/HLR with a mechanism to direct callrouting at the Serving MSC/VLR when authenticationprocedure fail.
TR45.2.3/99.06.17#16
Lucent Technologies
Provide clarifications and corrections for the PreferredLanguage - Variable Option.
Portions are a change to Miscellaneous 10 .
TR45.2.3/99.08.19#19
LG Sansys
Enhancement to support the AC including theTerminalType parameter in afreport operations todistinguish the type of AC (TSB51 or IS-41-C or later).
TR45.2.3/99.06.17#20
LG Sansys
Correction to authentication procedures to support ACs
not sending COUNT during SSD update.
Portions are a change to IS-778 , IS-725-A and toMiscellaneous 10 .
PN-3590 (ANSI-41-E) (Unofficial Tracking Document - Subject To Change) TR45.2.III/2000.01.12#___
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
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
XIX Contribution History
10.7 TR45.2.2/99.10.12#10
GTE
Align AuthenticationDirective Stage-2 with Stage-3procedures that support a VLR returning COUNT in anAUTHDIR response.
TR45.2.2/99.10.13#22
Lucent Technologies
Eliminate the MSC from rescinding “MIN/IMSI & ESN” inan smsreq RETURN RESULT, the parameters“MIN/IMSI & ESN” were initially sent by the OTAF inthe SMSREQ INVOKE.
This is a change to TIA/EIA/IS-725-A OTASP & OTAPA.
10.8 TR45.2.3/99.10.13#15
Qualcomm
Provide a new TerminalType parameter value for IS-2000mobile stations.
PN-3590 (ANSI-41-E) (Unofficial Tracking Document - Subject To Change) TR45.2.III/2000.01.12#___
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
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 Introduction
1. INTRODUCTION
1.1 OBJECTIVE
This document is intended to identify TIA/EIA-41-D technical enhancement ortechnical correction contributions that have been supported for incorporation into PN-3590 (TIA/EIA-41-E ) but are not expected to be published in a TIA/EIA-41-Denhancement Interim Standard (IS).
1.2 SCOPE
This document is for tracking purposes only, there is no intention of publishing thecontents of this document independent of ANSI/TIA/EIA-41-E .
1.3 ORGANIZATION
This document is organized per individual TIA/EIA-41-D accepted contributions;there has been no attempt to integrate multiple contributions or to resolve individualcontribution collisions (contributions modifying the identical TIA/EIA-41-D text.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Note: the omitted existing text is retained without modification.
• Handoff-Back with Tandem. The Handoff-Back process when more than twoMSCs are involved.
• Handoff-Back with Tandem via FacilitiesDirective (Path Minimization is
not supported). The Handoff-Back process when more than two MSCs are
involved but Path Minimization process is not supported.
• Handoff-To-Third with Path Minimization. The handoff of a call fromServing MSC to Target MSC, where the Target MSC is not already on thecall path (i.e., is not the Anchor or a tandem MSC) and path minimizationis applied.
• Handoff-Back with Tandem via FacilitiesDirective when the method of Handoff-To-Third with Tandem and Path Minimization is involved . The
handoff of a call from Serving MSC to Target MSC, where the Target MSC
is already on the call path (that is, as an Anchor or a Tandem MSC) and
path minimization can not be performed.
• Handoff-Back with Tandem via HandoffToThird when the method of
Handoff-To-Third with Tandem and Path Minimization is involved . The
handoff of a call from Serving MSC to Target MSC, where the Target MSC
is already on the call path (that is, as an Anchor or a Tandem MSC) and
path minimization is applied.
• Handoff-To-Third with Tandem and Path Minimization. The Handoff-To-Third with Path Minimization process when more than two MSCs are
involved.
Note: the remainder of this section is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
PN-3590 (ANSI-41-E) (Unofficial Tracking Document - Subject To Change) TR45.2.III/2000.01.12#___
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
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
TIA/EIA-41.2.D (Stage 2) 5 Intersystem Handoff
Figure X1 Successful Handoff-Back with Tandem via FacilitiesDirective(Path Minimization is not supported)
a-c. Same as Section 5.1. Steps a-c.
d. The Serving MSC determines that the call should be handed off to the candidate(now Target) MSC. It sends a FACDIR to the Target MSC, directing the Target
MSC to initiate a Handoff-Forward task. If the Serving MSC counts tandemsegments, then increment the Segment Counter by one in the BillingIDparameter.
e. The necessary facilities on the designated Target MSC are available; therefore,the Target MSC increases the Segment Counter in the received BillingIDparameter by one and uses the new BillingID for the new call segment. TheTarget MSC returns a facdir to the requesting MSC.
f. On receipt of the facdir, the Serving MSC sends a Mobile Handoff Order tothe served MS.
g. The MS is received on the designated traffic channel; therefore, ...
h. ...the Target MSC completes the path between the traffic channel and the inter-
MSC trunk and sends a MSONCH to the initiator of the Handoff-Forward task.i. If the Target MSC had already an associated inter-MSC trunk with the MS (e.g.
BillingID or MSID is already used in the call, and therefore the Target MSC isalso the Anchor or Tandem MSC in the call path), then the Target MSCrequests release of the inter-MSC trunk to the previous Serving MSC. TheTarget MSC sends a FACREL via the call path, with the reason for releaseindicating ‘HandoffSuccessful.’
j. The Tandem MSC forwards the FACREL toward the previous Serving MSC.
k. The previous Serving MSC sends a FACREL to the previous Target MSC inorder to release the Inter-MSC trunks which were established in the steps d-e.
l. The Anchor MSC marks the inter-MSC trunk as idle and returns a facrel to
the previous Serving MSC which then also marks the inter-MSC trunk as idle.m. The previous Serving MSC marks the inter-MSC trunk as idle and returns a
facrel to the Anchor MSC via the call path which then also marks the inter-MSC trunk as idle.
n. When the facrel is received, the Tandem MSC marks the inter-MSC trunk as idle and returns a facrel to the Anchor MSC via the call path which thenalso marks the inter-MSC trunk as idle.
o. The handoff-back process is complete.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
TR45.2.III/2000.01.12#___ (Unofficial Tracking Document - Subject To Change) PN-3590 (ANSI-41-E)
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
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
Intersystem Handoff 6 TIA/EIA41.2-D (Stage 2)
5.X2. Successful Handoff-Back with Tandem viaFacilitiesDirective when the method of Handoff-To-Third with Tandem and Path Minimization isinvolved
(TIA/EIA-41-D Chapter 2, page 2-60)
This scenario describes a successful Handoff-Back via FACDIR when the method of Handoff-To-Third with Path Minimization and more than two MSCs are involved. Inthis case, the Anchor MSC performs the Handoff-Back function.
facrel
HTTT
Initial ConnectionsA B
XY
C
Anchor
TargetSystem
A
TandemSystem
B
MSC MSC
ServingSystem
C
MSC
a
b
c
MS
Served MSX
HANDMREQ
LMMRT
call in progress
handmreq
dHANDTHIRD
ehandthird RETURN ERROR
j
i
f
g
h
FACDIR
HOT facdir
MSONCH
handoff order
MHOT
MAT
X arrives on new channel
l
CTT
FACREL
mFACREL
kFACREL
n
ofacrel
q
A
XY
Resulting Connections
handoff-back complete
pfacrel
CTT CTT
QUERY w/ PERMISSION
CONV w/ PERMISSION
RESPONSE
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
PN-3590 (ANSI-41-E) (Unofficial Tracking Document - Subject To Change) TR45.2.III/2000.01.12#___
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
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
TIA/EIA-41.2.D (Stage 2) 7 Intersystem Handoff
Figure X2 Successful Handoff-Back with Tandem via FacilitiesDirectivewhen the method of Handoff-To-Third with Tandem and Path
Minimization is involved
a-c. Same as Section 5.1. Steps a-c.
d. The Serving MSC determinates that the call should be handed off to the targetsystem and that path minimization may be possible. It sends a HANDTHIRD to
the MSC which had previously handed off the call to the Serving MSC (i.e., theTandem MSC), requesting that MSC to perform a handoff with pathminimization.
e. The Tandem MSC does not support the HANDTHIRD message (e.g., Does nothave and inter-MSC trunk to the Target MSC, congestion, or the message is notsupported) and returns a handthird RETURN ERROR.
f. When the serving MSC receives a handthird RETURN ERROR, REJECT,or the (HTTT) expires, it sends a FACDIR to the Target MSC, directing theTarget MSC to initiate a Handoff-Forward task. If the Serving MSC countstandem segments, then increment the Segment Counter by one in the BillingID
parameter.g-q. Same as Section 5.X1. Steps e-o.
5.X3. Successful Handoff-Back with Tandem viaHandoffToThird when the method of Handoff-To-Third with Tandem and Path Minimization isinvolved
(TIA/EIA-41-D Chapter 2, page 2-60)
This scenario describes a successful Handoff-Back via HANDTHIRD when themethod of Handoff-To-Third with Path Minimization and more than two MSCs are
involved. In this case, the Anchor MSC performs the Handoff-Back function.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
TR45.2.III/2000.01.12#___ (Unofficial Tracking Document - Subject To Change) PN-3590 (ANSI-41-E)
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
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
Intersystem Handoff 8 TIA/EIA41.2-D (Stage 2)
FACREL
HANDTHIRD
Initial ConnectionsA B
XY
C
Anchor
Target
System
A
Tandem
System
B
MSC MSC
Serving
System
C
MSC
a
b
c
MS
Served
MS X
HANDMREQ
LMMRT handmreq
dHANDTHIRD
e
j
i
f
g
hhandoff order
MHOT
MAT
l
m
k
FACREL
n
facrel
facrel
handthird
HTTT
A
XY
Resulting Connections
CTT CTT
HTTT
call in progress
handthird
X arrives on new channel
handoff-back complete
Figure X3 Successful Handoff-Back with Tandem via HandoffToThird
when the method of Handoff-To-Third with Tandem and PathMinimization is involved
a-c. Same as Section 5.1, Steps a-c.
d. The Serving MSC determines that the call should be handed off to the targetsystem and that path minimization may be possible. It sends a HANDTHIRD tothe MSC which had previously handed off the call to the Serving MSC (i.e.,the Tandem MSC), requesting MSC to perform a handoff with pathminimization.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
PN-3590 (ANSI-41-E) (Unofficial Tracking Document - Subject To Change) TR45.2.III/2000.01.12#___
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
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
TIA/EIA-41.2.D (Stage 2) 9 Intersystem Handoff
e. The Tandem MSC stores the proper information, adjusts the relevant parametersin the HANDTHIRD, and transits the message toward the Anchor MSC.
f. If the Target MSC is also the Anchor or Tandem MSC, and a traffic channel onthe designated target cell is available. Then, the Target MSC increases theSegment Counter in the received BillingID parameter by one and uses the newBillingID for the new call segment, it returns a handthird to the requesting
MSC.
g. The Tandem MSC stores the proper information, adjusts the relevant parametersin the handthird, and transits the message toward the Serving MSC.
h. On receipt of the handthird, the Serving MSC sends a Mobile Handoff Order to the served MS.
i. The MS is received on the designated traffic channel; therefore, ...
j. If the Target MSC is also the Anchor or Tandem MSC in the call path, thenthe Target MSC requests release of the inter-MSC trunk to the previousServing MSC by sending a FACREL via the call path, with the reason forrelease indicating ‘HandoffSuccessful.’
k. The Tandem MSC forwards the FACREL toward the previous Serving MSC.
l. The previous Serving MSC marks the inter-MSC trunk as idle and returns afacrel to the Anchor MSC via the call path. It then also marks the inter-MSC trunk as idle.
m. When the facrel is received, the Tandem MSC marks the inter-MSC trunk as idle and returns a facrel to the Anchor MSC via the call path. The AnchorMSC then also marks the inter-MSC trunk as idle.
n. The handoff-back is complete.
5. 6 Successful HandoffToThird with Tandem and PathMinimization(TIA/EIA-41-D Chapter 2, page 2-51)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure 23 Successful HandoffToThird with Tandem and PathMinimization
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
3. TIA/EIA-41.3-D Stage 2
Automatic Roaming Information Flows Enhancements
Note: the omitted existing text is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Provide parameters passed on authreq response clarification.
This is a change to IS-778.
3.2 AUTHENTICATION ON SUSPICIOUS CALL
ORIGINATION(new for TIA/EIA/IS-778 , page 8)
The following TIA/EIA-41.3-D Section 4.4 modifications enhance authenticationwhen SSD is not shared, a call origination occurs and the dialed digits are determinedto be suspicious. A new optional parameter (SuspiciousAccess) indicates that theserving system has determined that the dialed digits are suspicious, indicating to theAC (or the VLR) that a unique challenge may be necessary.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
a. The AC determines that the SSD in the MS must be updated. The AC sends anAUTHDIR to the HLR associated with the MS.
Parameters Usage Type
MIN Served MS MIN. R
ESN Served MS ESN. R
RANDSSD Random number generated by AC to producenew SSD.
R
NewSSDInfo: New SSD information:
[Authentication-AlgorithmVersion]
Include to select authentication algorithmother than default.
O
[SSD] Pending value of VLR and AC shared secretdata for SSD Update.
R
b. The HLR forwards the AUTHDIR to the VLR currently serving the identifiedMS. Parameters are as in Step-a.
c. The Serving VLR sends an AUTHDIR to the Serving MSC.
Parameters are as in Step-a, with the following additions:
Parameters Usage Type
LOCID Location Area ID. Include if available. O
RANDU Random number generated by VLR to produceAUTHU.
R
AUTHU Expected MS response to Unique ChallengeOrder as calculated by VLR.
R
d. The Serving MSC returns an empty authdir to the Serving VLR to indicatethat the directive has been accepted. Confirmation that SSD updating has beenattempted or completed is provided later since the MSC may not be able toinitiate the SSD update air interface procedure at this time.
e. The Serving VLR forwards the authdir to the HLR.
Parameters Usage Type
COUNT Value of event counter used for clone detection
as stored at VLR. Include if SSD is shared
with the VLR and COUNT is available.
O
f. The HLR forwards the authdir to the AC.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Provide parameters passed on authreq response clarification.
4. 4. 6 Successful Authentication on Call Origination (SSDshared)
(TIA/EIA-41-D Chapter 3, page 3-33)
Note: the omitted existing text is retained without modification.
Figure 14 Successful Authentication on Call Origination (SSD shared)
Note: the omitted existing text is retained without modification.
b. The Serving VLR determines that the MS is valid. The VLR sends anauthreq to the Serving MSC.
Parameters Usage Type
AuthReqParameters2: Set of parameters in authreq:
[CallHistoryCount] Event counter used for clone detection.Included if SSD is shared.
O
[RANDU] Random number generated by VLR to produceAUTHU. Included if a Unique Challenge tothe MS should be initiated by the servingsystem.
O
[AUTHU] Expected MS response to Unique ChallengeOrder as calculated by VLR. Included if aUnique Challenge to the MS should beinitiated by the serving system.
O
[UpdateCount] Indicates that the COUNT update procedureshould be initiated by the serving system.
O
EncryptionInformation
[CDMAPLCM] CDMAPrivateLongCodeMask. Include if available and MS is subscribed to VoicePrivacy.
O
[SMEKEY] SignalingMessageEncryptionKey. Include if available.
O
[VPMASK] VoicePrivacyMask. Include if available and MSis subscribed to Voice Privacy.
O
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Add an IS-778 enhancement scenario for authentication on suspicious Call Origination (SSD Shared).
4. 4. X1 Authentication on Suspicious Call Origination
(SSD Shared) (new for TIA/EIA-41-D Chapter 3, page 3-35)
(new for TIA/EIA/IS-778 , page 9)
This operation scenario describes the use of the AuthenticationRequest operation toauthenticate an MS which is attempting a suspicious call origination on a servingsystem that is sharing SSD with the AC. The MS is aware that authentication isrequired on all system access. The result of the operation is to allow origination andto initiate a Unique Challenge
Figure 4.4.X1 Authentication on Suspicious Call Origination (SSD shared)
a. On a call origination attempt by an MS, the Serving MSC sends an AUTHREQto the Serving VLR.
Parameters are as in Section 4.4.1, Step-a, with the following addition andmodifications:
Parameters Usage Type
AuthReqParameters1: Set of parameters in AUTHREQ:
[SystemAccessType] Type of system access = call origination. R
[SUSACC] SuspiciousAccess. Type of suspicious access,(e.g., Anomalous Digits).
R
DGTSDIAL Digits, entered by served MS, which identifythe called party.
R
AUTHDATA The authentication data used by the MS tocompute AUTHR for call origination.
O
b. The VLR determines that a Unique Challenge is required. TheVLR sends an authreq to the Serving MSC with parameters arein as Section 4.4.6, Step-b with the exception that the COUNTparameter is not included and RANDU and AUTHU are requiredfor this scenario.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
[DestinationDigits] DN for use in call routing if applicable. O
[Rout ingDigit s] Special routing instructions. Include if
applicable.
O
[CarrierDigits] Called subscriber’s PIC. Include if
applicable.
O
The HLR may optionally include RoutingInfo parameters when the DenyAccess
parameter is present.
f. The Serving VLR forwards the asreport to the Serving MSC. Parametersare as in Step-d, with the exception that the SSD, AAV, NOSSD and COUNT
and NOSSD parameters are not included.
The VLR may optionally include RoutingInfo parameters when the DenyAccess
parameter is present.
TR45.2.2/99.06.16#19; [LG Sansys]
Provide an empty response clarification note to ASREPORT Stage-2.
4.5 .2 Report of VLR-initiated Action(TIA/EIA-41-D Chapter 3, page 3-40)
Note: the omitted existing text is retained without modification.
Figure 18 Report of VLR-initiated action
Note: the omitted existing text is retained without modification.
b. If the ASREPORT indicates completion of an operation initiated by the ServingVLR, then the Serving VLR sends an asreport , with appropriateparameters, to the Serving MSC.
Note: the VLR shall send an empty asreport if the VLR is not initiating
additional authentication operations.
Note: the remainder of this section is retained without modification.
Information Returned (TIA/EIA-41-D Chapter 3, page 3-60)
Note: the omitted existing text is retained without modification.
Figure 29 Successful InterSystemPage: Border MSCRouting Information Returned
a. The Serving MSC sends an ISPAGE to the Border MSC, including anindication of the area where the MS’s presence was last detected, an indicationof whether to page or just listen for an unsolicited page response, and otherrelevant parameters.
Parameters Usage Type
ISPageID: Set of identification parameters in ISPAGE:
[BillingID] Originating Call ID. Used for billing andredirection purposes when ISPAGE results incall routing.
R
[MIN], [MSID] Served MS MIN and IMSI (include all that are
known).
R
[ESN] Served MS ESN. R
[MSCID] Originating MSC MSCID. R
[LocationAreaID] Served MS LocationAreaID for pagingpurposes. Included if available.
O
[ExtendedSystemMy-
TypeCode]
Serving MSC vendor identification. O
[ExtendedMSCID] Serving MSC MSCID. O
[MSIDUsage] For TDMA, identifies the MSID last used by
the Serving System to calculate the control
channel and paging slot.
O
[SystemMyTypeCode] Originating MSC vendor identification. O
[MSCIN] Identifies Originating MSC. O
[PC_SSN] Originating MSC PC_SSN. Include if SS7carriage services are used.
O
Note: the omitted existing text is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Provide an indicator for IntersystemPage and IntersystemPage2 to identify system supportof the MIN, IMSI or both parameters.
4. 15 .1 Successful InterSystemPage2: MS Presence Confirmed
in Border MSC (TIA/EIA-41-D Chapter 3, page 3-65)
Note: the omitted existing text is retained without modification.
Figure 32 Successful InterSystemPage2: MS PresenceConfirmed in Border MSC
a. The Serving MSC sends an ISPAGE2 to the Border MSC, including anindication of the area where the MS’s presence was last detected, an indicationof whether to page or just listen for an unsolicited page response, and otherrelevant parameters. If the MS is a CDMA MS, appropriate parametersnecessary for paging the MS are included.
Parameters Usage Type
ISPage2ID: Set of identification parameters in ISPAGE2:
[BillingID] Originating Call ID. Used for billing andredirection purposes when ISPAGE2 resultsin call routing.
R
[MIN], [MSID] Served MS MIN and IMSI (include all that are
known).
R
[ESN] Served MS ESN. R
[LocationAreaID] Served MS LocationAreaID for pagingpurposes. Included if available.
O
[MSIDUsage] For TDMA, identifies the MSID last used by
the Serving System to calculate the control
channel and paging slot.
O
PAGEIND Type of page request. Include if listen only. O
ALRTCODE Type of alert signal to apply. Include if specialalerting is to be applied to the MS.
O
MDN Mobile directory number. Include if available. O
Note: the omitted existing text is retained without modification.
Eliminate the MSC from rescinding “MIN/IMSI & ESN” in an smsreq RETURN RESULT, the parameters “MIN/IMSI & ESN” were initially sent by the OTAF in the SMSREQ INVOKE.
This is a change to TIA/EIA/IS-725-A OTASP & OTAPA.
4.3 4.T 1 Successful SMSRequest during OTASP: MS-BasedS M E (new for TIA/EIA-41-D , Chapter 3)
(change to TIA/EIA/IS-725-A, Chapter 3, page 268)
Note: the omitted existing text is retained without modification.
a
b
d
e
HLR VLROTAF MSC
SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]
c
Destination
Home SystemDestination
Serving System
SRT
f
SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]
SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]
smsreq [MIN, ESN, SMSADDR]
SRT SRT
smsreq [MIN, ESN, SMSADDR]
smsreq [MIN, ESN, SMSADDR]
Figure 4.34.T1 Successful SMSRequest during OTASP: MS-Based SME
Note: the omitted existing text is retained without modification.
d. The Serving MSC returns an smsreq to the VLR indicating the currentnetwork address that can be associated with the indicated MS-based SME.
Parameters Usage Type
MSID MS's MSID. R
ESN MS's ESN. R
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
SMSADDR Temporary routing address that can be used todeliver OATS or OPTS messages to the MS.
R
Note: the remainder of this section is retained without modification.
TR45.2.2/99.10.13#22; [Lucent Technologies
Eliminate the MSC from rescinding “MIN/IMSI & ESN” in an smsreq RETURN RESULT, the parameters “MIN/IMSI & ESN” were initially sent by the OTAF in the SMSREQ INVOKE.
This is a change to TIA/EIA/IS-725-A OTASP & OTAPA.
8.TT.5 Serving MSC Attachment to the OTAF:Reprogramming (new for TIA/EIA-41-D , Chapter 3)
(change to TIA/EIA/IS-725-A, Chapter 3, page 281)
Note: the omitted existing text is retained without modification.
a
b
d
e
HLR VLROTAF MSC
SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]
c
Destination
Home SystemDestination
Serving System
SRT
f
SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]
SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]
smsreq [MIN, ESN, SMSADDR]
SRT SRT
smsreq [MIN, ESN, SMSADDR]
smsreq [MIN, ESN, SMSADDR]
Figure 8.TT.5 Serving MSC Attachment to the OTAF: Reprogramming
Note: the remainder of this section is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Provide the AC/HLR with a mechanism to direct call routing at the Serving MSC/VLR when authentication procedure fail.
5.4 .x Authentication on Voice Channel, Access Denied,HLR/AC gives directive to route call
(new for TIA/EIA-41-D Chapter 3, page 3-37)
This scenario describes the intersystem message flow required for systems thatsupport authentication on the voice or traffic channel, authentication fails and call isrouted to directory number specified by HLR/AC.
q
o
p
i
g
a
b
c
d
e
f
h
j
k
l
m
n
Serving System
MSC VLR HLRMS AC
ASRRT
ART
omt (AUTH=0)
AUTHREQ
system access
ASREPORT [UCHALRPT]
ASRT ASRT
ART
ASRRT
AUTHREQ
AUTHREQ
authreq [AUTHU, RANDU]
authreq [AUTHU, RANDU]
authreq [AUTHU, RANDU]
Note: Voice/traffic channel
shall be assigned by this time
challenge response (AUTHU)
ASREPORT [UCHALRPT]
ASREPORT [UCHALRPT]
asreport [DenyAccess, RoutingInfo]
asreport [DenyAccess, RoutingInfo]
asreport [DenyAccess]
ART
ASRT
unique challenge (RANDU)
The call is established based on HLR/AC information
Home System
Figure 5.4.x Authentication on Voice Channel, denied access,
call routed to directory number
a. The MS determines from the Overhead Message Train (OMT) thatauthentication is not required on system accesses (AUTH=0).
b. The MS sends a system access message (origination or page response) to theServing MSC, providing its MIN and ESN only.
c. The Serving MSC sends an AUTHREQ to the Serving VLR with theSystemAccessType set to ‘Unspecified’.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
d. If SSD is shared with the current serving system, then the VLR shall generatethe RANDU locally, calculate AUTHU by executing CAVE, and proceed toStep-h; otherwise, the VLR forwards the AUTHREQ to the HLR associatedwith the MIN.
e. The HLR forwards the AUTHREQ to its AC.
f. The AC verifies the MIN and ESN reported by the MS. The AC chooses aUnique Random Variable (RANDU) and executes CAVE using the SSD-Acurrently stored, ESN, MIN1 and MIN2 associated with the MS to produce aUnique Authentication Response (AUTHU).
The AC sends an authreq to the HLR including RANDU and the expectedAUTHU result.
g. The HLR forwards the authreq to the Serving VLR.
h. The Serving VLR sends an authreq to the Serving MSC, containing the valuesof AUTHU and RANDU received in the authreq from the HLR (if SSD is notshared), or the values calculated locally (if SSD is shared).
The Serving MSC assigns the MS to an analog voice channel or a digital traffic
channel.
i. The Serving MSC sends a Unique Challenge order to the MS using theRANDU provided in the authreq.
j. The MS executes CAVE using RANDU and the SSD-A currently stored, ESN,MIN1 and MIN2 to produce an Authentication Result (AUTHU) which is thensent to the Serving MSC.
The Serving MSC compares the value of AUTHU provided in the authreq withthat received from the MS.
k. The Serving MSC sends an ASREPORT to the Serving VLR indicating failureof the unique challenge.
l. If SSD is not shared, the VLR shall forward the ASREPORT to the HLR. If SSD is shared and the Unique Challenge failed, the VLR shall send anAFREPORT to the HLR. For this scenario, we assume that SSD is notshared.
m. The HLR forwards the ASREPORT to its AC.
n. The AC responds with an asreport that may deny access according to the AClocal administrative practices (see Sections 5.4.6 and 5.4.7).
o. If the access is denied, the HLR may choose to include directives of how toroute call (to HLR defined or MSC defined directory number) according to theHLR local administrative practices (see section 3.X.1) and forwards the asreportto the Serving VLR.
p. The Serving VLR sends an asreport to the Serving MSC. If call is to be routedto HLR defined directory number, parameters such as DestinationDigits,CarrierDigits, or RoutingDigits are included in parameter list
q. MSC routes call based on HLR/AC information.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Provide the AC/HLR with a mechanism to direct call routing at the Serving MSC/VLR when authentication procedure fail.
5.4.x1 VLR Initiated Unique Challenge When SSD is Shared,
Unique Challenge Fails (new for TIA/EIA-41-D Chapter 3, page 3-37)
This scenario describes the intersystem message flow required to support a UniqueChallenge when SSD is shared.
a
b
c
d
e
f
MS
Serving System
AFRT
asreport
ASREPORT [UCHALRPT]
ASRT
AUTHDIR [RANDU, AUTHU]
authdir
unique challenge (RANDU)
challenge response (AUTHU)ASRRT
MSC VLR HLR AC
AFRT
g
h
i
j
AFREPORT [UCHALRPT]
AFREPORT [UCHALRPT]
afreport
afreport [DenyAccess, RoutingInfo]
kAUTHDIR [DenyAccess, RoutingInfo]
lauthdir ADT
Home System
ADT
Figure 5.4.x1 VLR Initiated Unique Challenge When SSD is Shared,Unique Challenge Fails
a. The Serving VLR chooses a Unique Random Variable (RANDU) and executesCAVE using the SSD-A currently stored, ESN, MIN1 and MIN2 associatedwith the MS to produce an Authentication Response for Unique Challenge(AUTHU).
The VLR sends an AUTHDIR to the current Serving MSC.
b. The authdir from the Serving MSC to the VLR serves only to inform the VLRthat the Serving MSC has accepted the directive.
c. The Serving MSC sends a Unique Challenge order to the MS using theRANDU provided in the AUTHDIR (Step-a).
d. The MS executes CAVE using RANDU and the SSD-A currently stored, ESN,MIN1, and MIN2 to produce a Unique Challenge Response (AUTHU) which isthen sent to the Serving MSC.
e. The Serving MSC compares the value of AUTHU provided in the AUTHDIR(Step-a) with that received from the MS.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
The Serving MSC sends an ASREPORT to the VLR indicating that the UniqueChallenge has been completed.
f. The Serving VLR returns an asreport to the Serving MSC.
g. If the operation failed, the Serving VLR sends an AFREPORT to the HLR.
h. The HLR forwards the AFREPORT to the AC.
i. The AC sends an afreport to the HLR, indicating the action to be requested of the VLR.
j. If the action is to deny access then the HLR can optionally add in theDestinationDigits, CarrierDigits, or RoutingDigits parameter to indicate to theMSC where to route the call to. The HLR forwards the afreport to the VLR.
k. If the action is to deny access then VLR sends an AUTHDIR to the servingMSC with the received routing information.
Parameters Usage Type
RoutingInfo: Call routing information:
[DestinationDigits] DN for use in call routing if applicable. O
[RoutingDigits] Special routing instructions. Include if applicable..
O
[CarrierDigits] Called subscriber's PIC. Include if applicable. O
l. The serving MSC returns an authdir to the serving VLR, and act accordingly toinformation received.
TR45.2.2/99.06.16#9; [LG Sansys]
Provide error correction to IS-778 “Wireless Authentication Enhancements Descriptions”; Chapter 3, Section 5.4.2 and correction to IS-778 Chapter 5, Section 6.5.2.154.
This is a change to IS-778.
5.4 .2 Origination with Authentication
(TIA/EIA/IS-778 Chapter 3, page 12)
(TIA/EIA-41-D Chapter 3, page 3-175)
Note: the omitted existing text is retained without modification.
Fi gur e 94 Originat ion with Authentication
Note: the omitted existing text is retained without modification.
h. If SSD is presently shared with VLR-2, the VLR-2 authenticates shall perform
validation of the MS as described in Section 4.4.6 [Successful Authentication
on Call Origination (SSD shared)] 5.4.10 (Origination with Shared SSD), and
proceeds go on to Step-p, step-l; otherwise, VLR-2 forwards the AUTHREQ to
the HLR associated with the MIN.
Note: the remainder of this section is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
6. 1. 5a CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited
(new for TIA/EIA-41-D Chapter 3, page 3-220, line 51)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure 117a CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
6.1. 5b CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited andServing MSC Identified Announcements
(new for TIA/EIA-41-D Chapter 3, page 3-220, line 51)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure 117b CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited andServing MSC Identified Announcements
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
6.1.5c CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited andServing MSC Identified Announcements in theCalled Party Preferred Language
(new for TIA/EIA-41-D Chapter 3, page 3-220, line 51)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure 117c CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited and
Serving MSC Identified Announcements in theCalled Party Preferred Language
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
6.1 .13 a CD Invocation with improved Intersystem Paging toan Idle MS
(new for TIA/EIA-41-D Chapter 3, page 3-235)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure 6.1.13.a CD Invocation with improved Intersystem Pagingto an Idle MS
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.2/98.04.21#23; [SBC Technology Resources]
Support intersystem registration and call delivery for mobile stations in Non-Public systems without ANSI-41 connectivity.
6 .1 .13b CD to a Non-Public System(new for TIA/EIA-41-D Chapter 3, page 3-235)
This scenario describes a method for the Mobile Station (MS) to obtain a directorynumber to be used for call delivery to the MS that is receiving service on an Non-Public (NP) system which has no intersystem support.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
a. MS registers with an NP System with a normal Registration or a TestRegistration.
b. Registration Response provides the MS with a directory number (DN), if this isan initial registration and the MS is authorized for service on this NP System.
c. MS de-registers with the Serving System and provides the DN received in Step-b.
d. Serving System sends a response to the MS and the MS rescans to the NP controlchannel.
e. The Serving System sends an MSINACT to the VLR including the DN received inStep-c.
f. The VLR sends an MSINACT to the HLR. The HLR stores the DN for callforwarding to the NP system.
g. The MS’s HLR sends an msinact to the Serving System VLR.
h. The VLR sends an msinact to the Serving System MSC.
i. A call is received at the Originating System.
j. The Originating System sends a LOCREQ to the MS’s HLR.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Support intersystem registration and call delivery for mobile stations in Non-Public systems without ANSI-41 connectivity.
6.1.13c Non-Public Registration with Public Re-registration
(new for TIA/EIA-41-D Chapter 3, page 3-235)This scenario describes an Mobile Station (MS) registering on an Non-Public (NP)system and obtains a directory number for call delivery, and sometime later re-registers on the public system.
a
b
c
d
e
f
g
h
i
MSIT
MSC HLR VLR MSC
Serving SystemOriginating System
MSINACT [MIN, DGTS]
MSINACT [MIN, DGTS]
msinact
msinact
j
k
NP MS
Registration
Response [DN]
De-Registration [DN]
Response
MSIT
Registration
l
REGNOT
m
RNT
RNT
REGNOT
n
Response
regnot
regnot
Figure 6.1.13c Non-Public Registration with Public Re-registration
a. MS registers with an NP System with a normal Registration or a TestRegistration.
b. Registration Response provides the MS with a directory number (DN), if this isan initial registration and the MS is authorized for service on this NP System.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Correction to scenario 6.16.1 to remove the PreferredLanguageIndicator parameter from theFeatureRequest RETURN RESULT (PLANGIND is not a valid featreq parameter).
6. 16 .1 PL Registration (variable option)
(TIA/EIA-41-D Chapter 3, page 3-341, line 12)
This scenario describes the successful registration of PL by an MSauthorized for the variable PL option.
FRRT
MS MSC HLR
Serving System
featreq [PLIND]
*FC+LanguageIndicatorDigits+ SEND
feature confirmation
call release
QUALDIR [PLIND]
qualdir QDT
qualdirQDT
a
b
d
e
f
g
h
i
c
VLR
FEATREQ [DGTSDIAL]
QUALDIR [PLIND]
Figure 175 PL Registration (variable option)
a. Dialed digits are received by the Serving MSC. During analysis of the dialeddigits, the Serving MSC detects a feature code string.
b. The dialed digits are included in a FEATREQ and sent from the Serving MSC to
the HLR associated with the MS.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
c. The HLR detects the authorized Preferred Language request and sends afeatreq to the Serving MSC. The featreq includes an indication of success the new preferred language. The Serving MSC stores the new preferred
language information.
Additional Parameters Usage Type
PLIND PLANGIND Indication of new preferred language. R
FEATRESULT Feature request result set to indicate success. R
d. The Serving MSC provides treatment to the served MS as indicated in thefeatreq. In this case, the treatment is to provide feature confirmation.
e. The Serving MSC releases the call.
f. The HLR reports the change in the MS’s service profile by sending aQUALDIR to the VLR where the MS is registered.
Additional Parameters Usage Type
PLIND PLANGIND Indication of new preferred language. R
g. The VLR sends a qualdir to the HLR.
h. The VLR reports the change in the MS’s service profile by sending aQUALDIR to the Serving MSC.
i. The Serving MSC sends a qualdir to the VLR. The Serving MSC stores
the new preferred language information.
7.x+0 Short Message from MS-Based SME in AnchorSystem and Acknowledged After Handoff
(new for TIA/EIA-41-D Chapter 3, page 3-373)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure x+0 Short Message from MS-Based SME in AnchorSystem and Acknowledged after Handoff
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
7.x+1 Short Message from MS-Based SME in AnchorSystem and Acknowledged After Handoff (via aTandem System)
(new for TIA/EIA-41-D Chapter 3, page 3-373)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
7.x+5 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff To Thirdto a New Serving System
(new for TIA/EIA-41-D Chapter 3, page 3-373)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure x+5 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff To Thirdto a New Serving System
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
7. 20 a Postponed MSC SMSNotification with Multiple
SMDPPs(new for TIA /EIA-41-D Chapter 3, page 3-406)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Figure 216a Postponed MSC SMSNotification with Mult ipleSMDPPs
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.2/99.12.14#3; [NORTEL NETWORKS]
Correct IS-771 Stage-2 scenario problem in section 8.3.7.1. This is a change to IS-771.
8.3. 7. 1 ICS with Called Party Location (HLR-based SIM)(change to TIA/EIA/IS-771, Chapter 4, page 4-118)
The omitted existing text is retained without modification.
c. The HLR determines the subscriber has ICS active on an SCP and sends aSERVREQ that includes the Serving MSCID parameter to the SCP. TheSRVID parameter indicates which service to execute. The WINCAP parameterindicates the HLR supports the Search operation.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Figure 8.CC.9 Registrat ion Following Successful OTA
a. After a successful OTASP or OTAPA session in which a new MSID wasassigned to the MS, the OTAF may determine that the Serving System shouldregister the MS with new MSID and that the Serving System should deleteinformation corresponding to the old MSID and perform the MSINACT
operation1.
The OTAF sends to the Serving MSC an SMDPP containing NEWMIN(supplemented by NEWMINEXT if a new IMSI_M was assigned) or NEWIMSI
or both and ACTCODE, instructing the Serving MSC to initiate registration.
Steps b-e will be initiated only if a successful registration had occurred with theold MIN or IMSI or both.
b. The Serving MSC sends to the VLR containing the old MSID an MSINACT,including a DeregistrationIndicator parameter. The MSC removes all record of the old MIN (or IMSI_M) or IMSI or both.
1If successful registration had occurred with the old MSID.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
c. The VLR, upon receipt of the MSINACT containing the DeregistrationTypeparameter, sends an empty msinact to the Serving MSC and removes allrecord of the old MSID.
d. The VLR then sends an MSINACT, including a DeregistrationType parameter tothe old HLR.
e. The old HLR deregisters the MS (i.e. clears the pointer to the VLR) and sendsan empty msinact to the VLR.
f. The Serving MSC sends a REGNOT using the NEWMSID value to the VLR.
g. The VLR forwards the REGNOT to the appropriate HLR.
h. The HLR registers the MS and returns a regnot to the VLR.
i . The VLR forwards the regnot to the Serving MSC.
j . The Serving MSC sends an smdpp to the OTAF indicating that the actionsspecified in ACTCODE were successfully initiated.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
IS-725-A (OTAPA) enhancement supporting the OTAF to notify the Serving MSC that an MS’s IMSI_M and IMSI_T have been programmed (or re-programmed).
8. CC .1 0 Notification of Newly Assigned MIN (or IMSI_M) or
IMSI or Both Following Successful OTA(change to TIA/EIA/IS-725-A, Chapter 3, page 3-72)
This scenario describes notification of a newly assigned MIN (or IMSI_M) or IMSI
or both to the MSC following a successful OTASP or OTAPA session when a newMIN (or IMSI_M) or IMSI or both are assigned.
The new MIN (or IMSI_M) and/or IMSI is transferred to the Serving MSC in an
SMDPP operation with the ActionCode instructing the Serving MSC to record theMSID. The MSC, then may perform necessary action associated with the MS and itsnew MIN (or IMSI_M) and/or IMSI. The exact procedure as to what an MSC should
9.CC.2 OTA Parameter Administration - MS is Available
(change to TIA/EIA/IS-725-A, Chapter 3, page 3-76)
Note: the omitted existing text is retained without modification.
c. The OTAF encapsulates an air-interface OTASP data message (OTAPA Request ) in the SMS_BearerData parameter, and sends it, along with the MS'sMIN and ESN, the SRVIND, and the ACTCODE in an SMDPP to the Serving
MSC. The OTAF is able to determine the destination address using theSMSADDR received in the previous step.
The SRVIND is set to CDMA OTAPA which enables the Serving MSC to set
the service option over the air interface to the MS..
Parameters Usage Type
MSID The MS’s MSID. When the MS has both theMIN & the IMSI at the start of the OTAPAsession then the MIN form of the MSID isused.
R
ESN MS’s ESN. R
SMS_BearerData It encapsulates an air interface OTAPA Request message with START indicator.This will request the MS to initiate anOTAPA session.
R
SMS-TID This parameter is empty. It is included tocomply with TIA/EIA-41 backwardcompatibility rules.
Provide the appropriate modifications to IS-771 (WIN) ANSI-41.5-D enhancements that were impacted by the T1S1 and TR-45.2 GTT agreement to use GTT-14 instead of GTT-10.
5. 1. 2 Signaling Connection Control Part
(TIA/EIA-41-D Chapter 5, page 5-8)
(TIA/EIA/IS-771 Chapter 5, page 5-3)
For TIA/EIA-41 applications, the SCCP is defined in ANSI T1.112, with thefollowing exceptions and limitations:
• SCCP Class 0 connectionless service is used.
Note: the omitted existing text is retained without modification.
• Global Title Translation on Mobile Identification Number can be used forcommunication with a Message Center. Global Title Indicator type 2 (0010)is used. A translation type value of 12 is used for Short Message Service for“MIN to MC” translation. The encoding scheme is BCD. Each addresssignal is coded as described in Section 3.4.2.3.1 of the ANSI T1.112
specification.
• Global Title Translation can be used for communication with a Service
Control Point (SCP). Global Title Indicator type 2 (0010) is used. A
translation type value of 8 is used for SCP Assisted Call Processing. The
Global Title address is coded as described in Annex B.8 of the ANSI T1.112
specification.
• Global Title Translation on an E.164 dialable number can be used for
communication with the HLR. Global Title Indicator type 2 (0010) is used.
A translation type value of 14 is recommended for use. A translation type
value of 10 is used for “PCS Call Delivery” translation. The global title
address information field contains the E.164 number. The encoding scheme
is BCD. The global title address is coded as described in Annex B of the ANSI T1.112 specification.
• Use of signaling point codes, global titles, and subsystem numbers mustmeet ANSI T1.112 requirements; such that, any allowable combination of these addressing elements is supported. For example, as stated in T1.112.3,Section 3.4.1:
Note: the remainder of this section is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Clarify that the BillingID parameter, which is a mandatory parameter in the FACDIR, FACDIR2,InterSystemPage2 and InterSystemSetup operations, represents the identifier that was originally assigned by the Anchor MSC .
TR45.2.2/98.12.16#17; [Lucent Technologies]
Provide NP (Non-Public) mode operation Stage-3 pr.
The FacilitiesDirective2 operation is used to request that the Target MSC initiate theHandoff-Forward task. This operation differs from the FacilitiesDirective operation inits addition of support for CDMA, NAMPS and multi-band TDMA and NAMPS
MSs.
The FacilitiesDirective2 operation is initiated with a TCAP INVOKE (LAST). Thisis carried by a TCAP QUERY WITH PERMISSION package. The Parameter Set isencoded as follows:
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
a. For CDMA, the ServingCellID and CDMAServingOneWayDelayparameters correspond to the active set member having the shortest signalpath to the MS (time reference cell).
b. Include if AMPS, NAMPS, or TDMA handoff.
c. Include if CDMA handoff.
Note: the omitted existing text is retained without modification.
q. This parameter shall be provided if the MS supports TDMA and is
authorized to have Voice Privacy and the VoicePrivacyMask (VPMASK)parameter is available.
r. The first six octets are assigned by the Anchor MSC but the segment
counter is modified as the call is handed off.
s. Include if MS is alerting to specify special alerting treatment.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Note: the omitted existing text is retained without modification.
d. Include if applicable.
Note: the omitted existing text is retained without modification.
f. Include if digits remain to be analyzed by the MSC.
g. Include if applicable and for recording purposes (see DMH ),
Note: the omitted existing text is retained without modification.
l. Include for local termination to an MS if a related feature is active.
m. Include only one of these mutually exclusive parameters.
n. Include to identify the Preferred Language.
o. This parameter may only be included if the AnnouncementList parameter is
present.
6 . 4 . 2 . 1 6 HandoffBack2
(TIA/EIA-41-D Chapter 5, page 5-55)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Table 41 HandoffBack2 INVOKE Parameters
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.3/99.03.18#9; [NORTEL NETWORKS]
Remove the IS-730 added but unused TDMATerminalCapability parameter from the MeasurementRequest2 INVOKE operation.
This is a change to IS-730 “Intersystem Operations Support for the IS-136 Digital Control Channel”.
6 . 4 . 2. 1 8 HandoffMeasurementRequest2
(TIA/EIA-41-D Chapter 5, page 5-56)
The HandoffMeasurementRequest2 operation is sent by the Serving MSC to anyadjacent MSCs to request a signal quality measurement on the specified channel. Thisoperation differs from the HandoffMeasurementRequest operation in its addition of support for CDMA, NAMPS and multi-band TDMA and NAMPS MSs.
The HandoffMeasurementRequest2 operation is initiated with a TCAP INVOKE(LAST). This is carried by a TCAP QUERY WITH PERMISSION package. TheParameter Set is encoded as follows:
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
The HandoffToThird2 operation is used by the Serving MSC (non-Anchor) to initiatea handoff with path minimization. This operation differs from the HandoffToThirdoperation in its support of dual-mode CDMA and NAMPS and multi-band TDMA
MSs.
The HandoffToThird2 operation is initiated with a TCAP INVOKE (LAST). This iscarried by a TCAP QUERY WITH PERMISSION package. The Parameter Set isencoded as follows:
Table 49 HandoffToThird2 INVOKE Parameters
HandoffToThird2 INVOKE Parameters Timer: HTTTField Value Type Reference Notes
Identifier SET [NATIONAL 18] M 6.3.2.1
Length variable octets M 6.3.2.1
Contents
BillingID M 6.5.2.16
• • • • • • • • • • • •
TDMAChannelData (Serving) O 6.5.2.153 o
TDMAVoiceCoder O 6.5.2.k r
UserZoneData O 6.5.2.am
(IS-730)
s
VoicePrivacyMask O 6.5.2.167 p
Notes:
Note: the omitted existing text is retained without modification.
Note: the following “Note” change is also a modification to IS-730.
r. Include to indicate subscriber or network preferences for Voice Coder
selection when multiple voice coders exist. If not included, or if
preferences can not be supported, the receiving system will select Voice
Coder based on TerminalCapability.
s. Include if MS user is authorized for User Zone Service. Include to permitTarget MSC to validate MS selection of User Zone.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Note: the omitted existing text is retained without modification.
h. Include if request is to listen only. May include if request is to page.
i. Include if available for subsequent call redirection.
Note: the omitted existing text is retained without modification.
m. Include to indicate the recommended number of sequential paging attempts
that the receiving system is expected to do.
n. Include to indicate the maximum time that the receiving system has to
respond to this message.
o. Include only one of these mutually exclusive parameters.
p. Include if available. At least one parameter should be present.
q. For TDMA, identifies the MSID last used to calculate the control channel
and paging slot.
Note: the remaining portion of this section is retained unchanged.
TR45.2.3/99.07-15#10; [Ericsson]
Provide an indicator for IntersystemPage and IntersystemPage2 to identify system support of the MIN, IMSI or both parameters.
TR45.2.3/99.07-15#33; [Nortel Networks]
Non-Public Mode Service support for User Zones (or PSIDs/RSIDs) that span multiple MSCs.
TR45.2.3/99.05.20.10; [Ericsson]
IS-764 enhancement adding parameter DisplayTect2 to many operations to support Multiple Language coded character set display characters.
This is a change to IS-764 “Calling Party Name Presentation and Calling Party Name Restriction (CNAP/CNAR)”.
TR45.2.III/98.07.08#8; [Northern Telecom]
Clarify that the BillingID parameter, which is a mandatory parameter in the FACDIR, FACDIR2,InterSystemPage2 and InterSystemSetup operations, represents the identifier that was originally assigned by the Anchor MSC .
6 .4 .2 .2 5 InterSystemPage2
(TIA/EIA-41-D Chapter 5, page 5-74)
(TIA/EIA/IS-764 Chapter 5, page-54)
(TIA/EIA-41-D Miscellaneous 10, page-54)
Note: the omitted existing text is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Table 6 .4.2.V Release INVOKE Parameters
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Table 6.4.2.V1 Release RETURN RESULT Parameters
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.3/99.05.20.10; [Ericsson]
IS-764 enhancement adding parameter DisplayTect2 to many operations to support Multiple Language coded character set display characters.
This is a change to IS-764 “Calling Party Name Presentation and Calling Party Name Restriction (CNAP/CNAR)”.
TR45.2.3/97.05.22#7; [ERICSSON]; Stage 3.
Enhancement to call delivery redirection treatment supporting the Originating MSC providing Serving MSC identified announcements in the preferred language of the called party.
6 . 4. 2. 40 RoutingRequest
(TIA/EIA-41-D Chapter 5, page 5-99)
(TIA/EIA/IS-764 Chapter 5, page-61)
(TIA/EIA-41-D Miscellaneous 10, page-59)
Note: the omitted existing text is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
TransactionCapability (Originating MSC) O M 6.5.2.160 r
VoiceMailboxNumber O 6.5.2.164 p
VoiceMailboxPIN O 6.5.2.165 q
Notes:
a. Required to identify originating call.
Note: the omitted existing text is retained without modification.
c. Include if related feature is active.
d. Optionally include if TerminationTreatment parameter value is Dialogue, toselect a dialogue or to provide information to a dialogue.
e. Optionally include if TerminationTreatment parameter value isVoiceMailRetrieval or VoiceMailStorage to select the voice mail system.
f. Include if available and if TerminationTreatment parameter value is MStermination.
Note: the omitted existing text is retained without modification.
p. Include if the TerminationTreatment parameter value is VoiceMailRetrievalor V o i c e M a i l S t o r a g e and the mailbox is not theMobileIdentificationNumber.
q. Optional, if the TerminationTreatment parameter value isVoiceMailRetrieval or VoiceMailStorage.
r. Include to inform the serving system of the Originating MSC capabilities.
s. Include only one of these mutually exclusive parameters.
Note: the remaining portion of this section is retained unchanged.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
The ServiceRequest operation success is reported with a TCAP RETURN RESULT(LAST). This is carried by a TCAP RESPONSE package. The Parameter Set isencoded as follows:
Table 6.4.2.H-2 ServiceRequest RETURN RESULT Parameters
ServiceRequest RETURN RESULT Parameters
Field Value Type Reference Notes
Identifier SET [NATIONAL 18] M 6.3.2.2
Length variable octets M 6.3.2.2
Contents
DisplayText O 6.5.2.bx a, b
DisplayText2 O 6.5.2.ec a, b
Notes:
a. Include if applicable.
b. Include only one of these mutually exclusive parameters.
6 . 4. 2 .4 1 SMSDeliveryBackward
(TIA/EIA-41-D Chapter 5, page 5-102)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Table 91 SMSDeliveryBackward RETURN RESULT Parameters
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
a. Include if known pending the direction of the message (i.e., include on
MS-to-MC deliveries to identify notify the originating MS-based SME; or
include on MC-to-MS deliveries to notify the MS-based SME); or include if
the operation is used for CDMA OTASP or CDMA OTAPA.
Include if known and the destination is an MS-based SME.
Include if known and either the destination is an MS-based SME or the
operation is used for CDMA OTASP or CDMA OTAPA.
b. Include if applicable. If not received, charge the message originator.
c. May be included if not carried by the underlying data transport. May requirean interconnection agreement to facilitate interworking between network types.
d. Include if applicable. If not received, assume value 0.
e. Include if no notification is necessary. If not received, assume notification is
requested.
f. Include if different than the destination address (SMS_DestinationAddress,MobileIdentificationNumber, or the underlying data transport destination).
g. Include if applicable.
h. Include if not the same as the originating address (SMS_OriginatingAddressor the underlying data transport originating address).
i. Include for CDMA OTASP or CDMA OTAPA if action to be performed is
not implied through presence of other parameters.
j Include for CDMA OTASP or CDMA OTAPA in requests to initiate MSC
procedures2 if a value has been assigned for the MS during the current
OTASP or OTAPA session.
k. Include for CDMA OTASP or CDMA OTAPA.
l. Include for CDMA OTASP when requesting MSC attachment to the OTAF
to provide a correlation between the OTASP voice and data connections.
m. For CDMA OTASP, contains the Activation_MIN. For CDMA OTAPA,
contains the MS’s MSID at the start of the OTAPA session. When the MS
has both the MIN & the IMSI at the start of the OTAPA session then the
MIN form of the MSID is used. (See IS-751 for additional information).
2The MSC procedures are “Registration Following Successful OTASP or OTAPA”
and “Notification of Newly Assigned MSID MIN (or IMSI_M) or IMSI or Both
Following Successful OTASP or OTAPA” in Section 7C.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
The SMSRequest operation is used to request an MS’s current SMS routing addresswith a default to request notification when the MS becomes available if the MS isnot currently available.
The SMSRequest operation is initiated with a TCAP INVOKE (LAST). This is
carried by a TCAP QUERY WITH PERMISSION package. The Parameter Set isencoded as follows:
Table 98 SMSRequest INVOKE Parameters
SMSRequest INVOKE Parameters Timer: SRT
Field Value Type Reference Notes
Identifier SET [NATIONAL 18] M 6.3.2.1
Length variable octets M 6.3.2.1
Contents
MSID M 6.5.2.bv c, d, f
MobileIdentificationNumber O 6.5.2.81ElectronicSerialNumber O 6.5.2.63 a
MobileDirectoryNumber O 6.5.2.80 e
ServiceIndicator O 6.5.2.wB d
SMS_NotificationIndicator O 6.5.2.130 b
SMS_TeleserviceIdentifier O 6.5.2.137 c
Notes:
a. Include if known.
b. Include to specify notification requirements. If not included, impliesnotification shall be sent when MS becomes available (default).
c. Include if applicable.
d. Include [for CDMA OTA] to identify CDMA OTAPA service.
e. One parameter must be present ( i .e . , e ither MSID or
MobileDirectoryNumber).
f. Include the mobile station identifier that should be used for SMS delivery.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
IS-764 enhancement adding parameter DisplayTect2 to many operations to support Multiple Language coded character set display characters.
This is a change to IS-764 “Calling Party Name Presentation and Calling Party Name Restriction (CNAP/CNAR)”.
TR45.2.II/98.06.09#6; [Northern Telecom]
Calling Number Identification Presentation (CNIP) support for adding the calling party number and redirecting party number related parameters to the TransferToNumberRequest (TRANUMREQ) INVOKE for supporting the CNIP feature during redirection and during Mobile Access Hunting (MAH), as:
6 . 4 . 2. 4 6 TransferToNumberRequest
(TIA/EIA-41-D Chapter 5, page 5-110)
(TIA/EIA/IS-764 Chapter 5, page-64)
(TIA/EIA-41-D Miscellaneous 10, page-64)
Note: the omitted existing text is retained without modification.
The CDMAChannelData (CDMADATA) parameter contains the CDMA ChannelNumber field, the Frame Offset field and a Long Code Mask field associated with theCDMA Traffic channel in use. The CDMA Channel Number is an 11-bit numbercorresponding to the CDMA frequency assignment. This number specifies thechannel number for the CDMA Channel center frequency (see CDMA for details).
The Frame Offset is a 4-bit binary number that contains the time skew of TrafficChannel frames in units of 1.25 ms. The maximum frame offset is 18.75 ms whichis 15 times 1.25 ms. The valid values in the Frame Offset field are 0 through 15.
The Long Code Mask is a 42-bit binary number that contains the long code mask inuse at the Serving MSC. The Long Code Mask creates a unique identity of the MS’s
long code which is a Pseudo Random Number sequence with period of 2 42-1 that isused for scrambling on the Forward CDMA Channel and spreading on the ReverseCDMA Channel.
The Band Class indicates the frequency band to which the MS is being redirected.
NP_EXT is a flag sent from the Base Station to the MS to indicate that the
correction factor in Nominal Power is in the range of - 9 dB to - 24 dB inclusive.
Nominal Power is the nominal transmit power offset that the Base Station sends to
the MS set to the correction factor to be used in the open loop power estimate. If the
range of the correction factor is - 8 dB to 7 dB inclusive, the NP_EXT is set to 0 (or
not included). If the range of the correction factor is - 9 dB to - 24 dB inclusive, theNP_EXT is set to 1.
Number Preamble is sent from the Base Station to the MS and is set to the number
of Traffic Channel preamble frames the MS should send during handoff.
The Base Station Protocol Revision indicates the air interface revision supported by
the controlling base station.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
DisplayText2 parameter enhancement to support multiple character sets per message and support for additional character sets.
This is a change to Miscellaneous-10.
TR45.2.III/98.06.10#___; [Rogers Cantel]
IS-764 enhancement to support Coded Character Set display characters.
6 . 5 .2 . ec DisplayText2
(new for TIA/EIA-41.5-D , page 5-190)
The DisplayText2 (DISPTEXT2) parameter carries information to be sent to the MSfor display. This parameter is based on the Display Text information element definedin Annex D (normative) of ANSI T1.610.
Field Value Type Reference Notes
Identifier DisplayText2IMPLICIT OCTET STRING
M 6.5.1.2
Length variable octets M 6.5.1.1
Contents
H G F E D C B A octet Notes
Display Character Set 1 d
Display Type 2 a, d
Display Tag 3 a, b, d
Display Length 4 a, b, d
1st Displayed Character 5 b, c, d
2nd Displayed Character 6 b, c, d
• • • • • •
n th Displayed Character n b, c, d
Figure 6.5.2.ec DisplayText2 parameter
Notes:
a. Refer to ANSI T1.610 for field encoding.
b. One or more groups of Display information may be included depending onspecific service requirements.
c. For display procedures, refer to ANSI T1.610 or to the display proceduresfor the specific coded character set.
Editor’s Note: the encoding of 7-bit characters needs further study.
d. This group of octets may be repeated within one parameter each time it is
required to change character sets.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Figure 6.5.2.ec1 DisplayText2 parameter for 16-bitDisplayed Characters
Notes:
a. Refer to ANSI T1.610 for field encoding.
b. A “Display Group” shall include a Display Tag octet, a Display Lengthoctet, and one or more Displayed Character octets. One or more groups of Display information may be included depending on specific servicerequirements.
c. For display procedures, refer to ANSI T1.610 or to the display proceduresfor the specific coded character set.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
(new for TIA/EIA-41.5-D , page 5-204)(new for TIA/EIA/IS-725-A CDMA, page 5-125)
The InterMessageTime (IMTIME) parameter is used to indicate the desired inter-message guard timer value (in 10s of seconds) at the receiving node when the timervalue is to be different than the system default.
Field Value Type Reference Notes
Identifier InterMessageTimeIMPLICIT OCTET STRING
M 6.5.1.2
Length 1 octet M 6.5.1.1
Contents
H G F E D C B A octet Notes
Timer value (in 10s of seconds) 1 a
Figure 6.5.2.fd InterMessageTime parameter
Notes:
a. Timer value is specified in 10s of seconds (e.g., a value of ‘1’ is 10 seconds;a value of ‘2’ is 20 seconds, etc.).
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
The NewMINExtension (NEWMINEXT) parameter contains the IMSI_M_CLASS,IMSI_M_ADDR_NUM, MCC_M, and IMSI_M_11_12 of an IMSI_M assignedduring a successful CDMA OTA session.
Field Value Type Reference Notes
Identifier NewlyAssignedMIN
IMPLICIT MINType
M 6.5.1.2
Length 3 octets M 6.5.1.1
Contents
H G F E D C B A octet Notes
Digit 1 ADDR_NUM CLASS 1 a, b, c
Digit 3 Digit 2 2 cDigit 5 Digit 4 5 c
Figure ff NewlyAssignedMIN parameter
Notes:
a. Bit A of octet 1 is the IMSI_M_CLASS of the newly assigned IMSI_M.(See CDMA for the definition of the IMSI_M_CLASS and the encoding of this bit.)
b. Bits DCB of octet 1 is the IMSI_M_ADDR_NUM of the newly assignedIMSI_M. (See CDMA for the definition of IMSI_M_ADDR_NUM and theencoding of this field.)
c. Digits 1, 2 and 3 are the digits of the newly assigned MCC_M, digit 1being the most significant digit of the newly assigned MCC_M and digit 3being the least significant digit of the newly assigned MCC_M. Digits 4and 5 are the digits of the newly assigned IMSI_11_12, digit 4 being themost significant digit of the newly assigned IMSI_M_11_12 and digit 5being the least significant digit of the newly assigned IMSI_M_11_12.(See CDMA for the definitions of MCC_M and IMSI_M_11_12)
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
The Profile is a collection of the subscriber’s calling profile information. Thisinformation is a list of optional parameters. The Profile macro has been definedsolely for editorial convenience, and does not affect the encoding in any way.
PROFILE
Type Reference Notes
Contents
AuthenticationCapability O 6.5.2.8 a
CallingFeaturesIndicator O 6.5.2.20 b
CarrierDigits O 6.5.2.28 c
DMH_AccountCodeDigits O 6.5.2.59 d
DMH_AlternateBillingDigits O 6.5.2.60 d
DMH_BillingDigits O 6.5.2.61 d
GeographicAuthorization O 6.5.2.68 e
MessageWaitingNotificationCount O 6.5.2.78 fMessageWaitingNotificationType O 6.5.2.79 g
MobileDirectoryNumber O 6.5.2.80 d
OriginationIndicator O 6.5.2.89 h
OriginationTriggers O 6.5.2.90 i
PACAIndicator O 6.5.2.91 j
PreferredLanguageIndicator O 6.5.2.96 k
QOSPriority O 6.5.2.xx t
RestrictionDigits O 6.5.2.113 l
RoutingDigits O 6.5.2.114 m
SMS_OriginationRestrictions O 6.5.2.136 nSMS_TerminationRestrictions O 6.5.2.138 o
SPINIPIN O 6.5.2.139 p
SPINITriggers O 6.5.2.140 q
TerminationRestrictionCode O 6.5.2.157 r
TerminationTriggers O 6.5.2.159 s
Figure 105 Profi le Macro
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Profile changes to support non-assured packet data service radio-link QoS.
6.5 .2 .xx QOSPrior ity
(TIA/EIA-41.5-D page 5-236)
The QOSPriority (QOSPRI) parameter indicates the relative priority with which totreat a MS subscriber's requests for radio resources related to packet data services.The priority level is applicable to user admission, Media Access Control (MAC)state transition control, and burst allocation.
Field Value Type Reference Notes
Identifier QOSPriorityIMPLICIT OCTET STRING
M 6.5.1.2
Length variable octets M 6.5.1.1
Contents
H G F E D C B A octet Notes
Reserved Non-Assured Priority 1 a
• • • n b
Figure 6 .5 .2 .xx QOSPriority parameter
Notes:
a. Reserved bits shall be ignored on receipt and set to zero on sending.
b. Ignore extra octets, if received. Send only defined (or significant) octets.
Provide a new TerminalType parameter value for TIA/EIA-136 Revision B mobile stations.
TR45.2.3/99.10.13#15; [Qualcomm]
Provide a new TerminalType parameter value for IS-2000 mobile stations.
TR45.2.2/99.09.15#11; [Nortel Networks]
Add “TIA/EIA-136 Revision-0” to TerminalType value=5, and add a new TerminalType value=6
for “TIA/EIA-136-A”.TR45.2.2/99.06.16#19; [LG Sansys]
Provide error correction to IS-778 “Wireless Authentication Enhancements Descriptions”; Chapter 3, Section 5.4.2 and correction to IS-778 Chapter 5, Section 6.5.2.154.
This is a change to IS-778.
This is a change to Miscellaneous Revision 10.
TR45.2.3/97.09.10.___; [NORTEL]
Provide ANSI-41-D Chapter 5 TerminalType parameter value assignments for TIA/EIA-553Aand TIA/EIA-91A Mobile Stations.
6 .5 .2 .1 54 TerminalType
(TIA/EIA/IS-778 Chapter 4, page 23)
(Miscellaneous Revision--10, page 91)
(TIA/EIA-41-D Chapter 5, page 5-307)
The TerminalType (TERMTYP) parameter identifies the radio frequency interfacestandard supported by the associated MS. The values of this parameter are derivedfrom the Mobile Protocol Capability Indicator (see AMPS, TDMA, NAMPS, orCDMA MPCI) over the analog control channel, the CDMA control channel MobileProtocol Revision Level (see CDMA MOB_P_REV), or other means.
On mobile station power up provide an update to the message waiting notification information because some mobile station implementations do not remember the last received information.
3.1. 1 Autonomous or Power-On Registration(TIA/EIA-41-D Chapter 6, page 6-9)
When the MSC becomes aware of the presence of an MS through registration, theServing MSC should do the following:
Note: the omitted existing text is retained without modification; see IS-730.
3 IF the MS is not registered:
3-1 Execute the “MSC Initiating MS Registration” task (see 4.38.1).
3-2 IF the MS is not authorized:
3-2-1 Execute “Local Recovery Procedures” task (see 3.5.1).
3-3 ENDIF.
4 ENDIF.
4X IF the last received MessageWaitingNotificationType is MWI ON and the
MessageWaitingNotificationCount indicates that at least one message is waiting:
4X-1 Execute the “MSC MWN Status Change Invocation” task indicating that
message waiting notification is required.
4Y ENDIF.
5 Exit this task.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.III/99.06.17#20 [LG Sansys]
Correction to authentication procedures to support ACs not sending COUNT during SSD update.
Portions of this recommendation are a change to IS-778 and IS-725-A.
TR45.2.III/98.08.19#15 [Motorola]
Align Chapter 6 “Error Code Tables” with the recommendations in Chapter 5 “Table 200 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters”.
Note: the omitted existing text is retained without modification.
1-3-5 IF the SharedSecretData (SSD) parameter is received:
1-3-5-1 Store the pending SharedSecretData (SSD) value.
1-3-5-2 IF the Authenticat ionAlgorithmVersion (AAV) parameter isreceived:
1-3-5-2-1 Store the received AuthenticationAlgorithmVersion (AAV)value.
1-3-5-3 ENDIF.
1-3-5-4 IF the CallHistoryCount (COUNT) parameter is received:
1-3-5-4-1 Store the received CallHistoryCount (COUNT) value.
1-3-5-5 ENDIF.
1-3-5-6 Select a RandomVariableUniqueChallenge (RANDU) and executeCAVE using the value of the pending SSD to produce anAuthenticationResponseUnique (AUTHU).
1-3-5-7 Include the RandomVariableUniqueChal lenge (RANDU) andAuthenticationResponseUnique (AUTHU) parameters.
1-3-5-8 Mark the MS pending Unique Challenge.
Note: the omitted existing text is retained without modification.
1-10 ELSE (the MS is marked pending SSD update, OR the MS is marked
pending Unique Challenge, OR the MS is marked pending COUNT update):
1-10-X Relay received MobileStationIDentity and ElectronicSerialNumber
parameters.
1-10-1 Include the SenderIdentificationNumber set to the identification numberof the VLR.
1-10-2 Send an AuthenticationDirective INVOKE to the MSC currentlyserving the MS.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
When an MSC determines that an Authentication Failure Report is necessary, it shallperform the following:
X Include the MS’s MobileStationIDentity and ElectronicSerialNumber parameters
required to perform the authentication process.
1 Include the ReportType parameter set to the value indicated by the calling task.
2 Include the SystemAccessType parameter indicating the type of access triggeringthis report (e.g., Autonomous registration, Power down registration, Callorigination, Page response, Flash request ).
Note: the remainder of this section is retained without modification.
TR45.2.III/99.06.17#20 [LG Sansys]
Correction to authentication procedures to support ACs not sending COUNT during SSD update.
Portions of this recommendation are a change to IS-778 and IS-725-A.
TR45.2.III/98.08.19#15 [Motorola]
Align Chapter 6 “Error Code Tables” with the recommendations in Chapter 5 “Table 200 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters”.
Note: the omitted existing text is retained without modification.
1-7-2-2-5-5 IF the SharedSecretData (SSD) parameter is received:
1-7-2-2-5-5-1 IF the AuthenticationAlgorithmVersion (AAV)parameter is received:
1-7-2-2-5-5-1-1 Store the AuthenticationAlgorithmVersion(AAV) value.
1-7-2-2-5-5-2 ENDIF.
1-7-2-2-5-5-3 IF the CallHistoryCount (COUNT) parameter is
received:1-7-2-2-5-5-3-1 Store the pending CallHistoryCount (COUNT)
value.
1-7-2-2-5-5-4 ENDIF.
1-7-2-2-5-5-5 Store the pending SSD value.
1-7-2-2-5-5-6 Select a RandomVariableUniqueChallenge (RANDU)and execute CAVE using the value of the pendingSSD to produce an AuthenticationResponseUnique(AUTHU).
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Note: the omitted existing text is retained without modification.
T ab l e 5 VLR AuthenticationFailureReport Response
Note: the omitted existing text is retained without modification.
Problem Detections:
Note: the omitted existing text is retained without modification.
5. A supplied parameter value is unrecognized or has nonstandard values (e.g., Not used ,SystemCapabilities (SYSCAP) parameter indicated authentication is not supported (AUTH is0) but this AuthenticationFailureReport was received).
Note: the remainder of this section is retained without modification.
4. 11 .1 Serving MSC Initiating a Facilities Directive
(TIA/EIA-41-D Chapter 6, page 6-115, line 52)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.2/99.08.17#6; [ERICSSON]
Provide an enhanced FACDIR or FACDIR2 method for Handoff Back; Stage 3:
TR45.2.2/98.12.16#17; [Lucent Technologies]
Provide NP (Non-Public) mode operation Stage-3 procedures.
TR45.2.2/99.01.06#8; [Ericsson]
Correct differences between Stage-2 scenarios and Stage-3 procedures regarding parameters TANDEMDEPTH and MAXHANDOFF.
4. 11 .2 Target MSC Receiving a FacilitiesDirective INVOKE
(TIA/EIA-41-D Chapter 6, page 6-120, line 29)
When the Target MSC receives a FACDIR (FacilitiesDirective orFacilitiesDirective2) INVOKE, the MSC shall do the following:
1 IF the received message can be processed:
X-1 IF the Target MSC has an inter-MSC trunk for the MS (e.g., the BillingID
or MSID is already used in the call. Therefore, the Target MSC was already
in the call path, in other words, the Target MSC is also an Anchor or
Tandem MSC for the call.):
X-1-1 Ignore the received InterSwitchCount.
X-1-2 Restore the InterSwitchCount value stored at the Target MSC.
X-2 ENDIF.
1-1 IF InterSwitchCount value at the Target MSC is greater than or equal to MAXHANDOFF (see 2.1):
1-1-1 Send a RETURN ERROR with Error Code OperationSequenceProblem .
1-1-2 Exit this task.
1-2 ENDIF.
1-3 Identify the target voice or traffic channel and associated transmission modesbased upon the received ChannelData, NAMPSChannelData,TDMAChannelData, and CDMAChannelData, parameters.
1-4 IF voice/traffic channels are available on any of the designated cell(s) and an
inter-MSC trunk toward the Serving MSC is available:
1-4-1 IF the Segment Counter field value in the received BillingID parameteris FF
16(indicating Unspecified ):
1-4-1-1 Do not change the value.
1-4-2 ELSE:
1-4-2-1 Increment the Segment Counter field value in the receivedBillingID parameter by 1 (to be associated with the air segmentbeing created).
1-4-3 ENDIF.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Note: the omitted existing text is retained without modification.
1-4-8 CDMA (FacilitiesDirective2 only):
1-4-8-1 Include the CDMAChannelData parameter.
1-4-8-2 Inc lude the CDMACodeChannelLis t parameter inc ludingCDMACodeChannelInformation parameters including aTargetCellID parameter and a CDMACodeChannel parameter.
1-4-8-3 Include the CDMASearchWindow parameter.
1-4-8-4 Include the ConfidentialityModes (CMODES-Actual) parameter.
1-4-8-5 Set the actual Signaling Message Encrypt ion f ield of theConfidentialityModes (CMODES-Actual) parameter based on thepresence of the SignalingMessageEncryptionKey (SMEKEY)parameter and the Target MSC preferences.
1-4-8-6 Set the actual Voice Privacy field of the ConfidentialityModes(CMODES-Actual) parameter based on the presence of theCDMAPrivateLongCodeMask (CDMAPLCM) parameter, thedesired state (as indicated by the ConfidentialityModes (CMODES-desired) parameter), and the capabilities of the allocated channel(s).
1-4-8-7 Set the Non-Public Info Display field to the value received in the
NonPublicData parameter.
1-4-9 TDMA:
1-4-9-1 Include the TDMAChannelData parameter.
1-4-9-2 Include the ConfidentialityModes (CMODES-Actual) parameter.
1-4-9-3 IF applicable:
1-4-9-3-1 Include the TDMABurstIndicator parameter.
1-4-9-4 ENDIF.
1-4-9-5 Set the actual Signaling Message Encrypt ion f ield of theConfidentialityModes (CMODES-Actual) parameter based on thepresence of the SignalingMessageEncryptionKey (SMEKEY)
parameter and the Target MSC preferences.
1-4-9-6 Set the actual Voice Privacy field of the ConfidentialityModes(CMODES-Actual) parameter based on the presence of theVoicePrivacyMask (VPMASK), the desired state (as indicated bythe ConfidentialityModes (CMODES-desired) parameter), and thecapabilities of the allocated channel(s).
1-4-9-7 Set the Non-Public Info Display field to the value received in the
NonPublicData parameter.
1-4-10 ENDCASE.
1-4-11 Send a RETURN RESULT.
1-4-Y IF the Target has an associated inter-MSC trunk for the MS (e.g., the
BillingID or MSID is already used in the call. Therefore, the Target
MSC was already in the call path, in other words, the Target MSC is
also an Anchor or Tandem MSC for the call.):
1-4-Y-1 Execute the "Target MSC Handoff Back" task (see 4.16.3).
1-4-Y-2 Exit this task.
1-4-Z ENDIF.
1-4-12 Execute the "Target MSC Handoff Forward" task (see 4.11.3).
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Align Chapter 6 “Error Code Tables” with the recommendations in Chapter 5 “Table 200 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters”.
Note: the omitted existing text is retained without modification.
Tab le 42 VLR Orig inationDirective Response(TIA/EIA-41.6-D page 6-207)
Note: the omitted existing text is retained without modification.
Problem Detections:
5. A supplied parameter value is unrecognized or has nonstandard values (e.g., Not used , asupplied Digits parameter does not have an expected number of digits, a Digits parametercontains a Code 11, a Code 12, or an ST digit, a Digits parameter is using anunrecognized value for numbering plan, encoding, or type of digit), theOriginationIndicator is set to Prior agreement and an agreement does not exist).
Note: the omitted existing text is retained without modification.
8. An expected, or required, optional parameter (e.g., AuthorizationDenied,AuthorizationPeriod, OriginationIndicator, TerminationRestrictionCode,CallingFeaturesIndicator, or a Digits (Carrier)) was not received. A received optionalparameter required the VLR to expect an additional optional parameter that was notreceived (e.g., OriginationIndicator value set to Selected NPA-NXX , but the expectedDigits (Destination) parameter was not received).
Note: the remainder of this section is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Align Chapter 6 “Error Code Tables” with the recommendations in Chapter 5 “Table 200 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters”.
Note: the omitted existing text is retained without modification.
Problem Detections:
5. A supplied parameter value is unrecognized or has nonstandard values (e.g., Not used , asupplied Digits parameter does not have an expected number of digits, a Digits parametercontains a Code 11, a Code 12, or an ST digit, a Digits parameter is using an
unrecognized value for numbering plan, encoding, or type of digit), theOriginationIndicator is set to Prior agreement and an agreement does not exist).
Note: the omitted existing text is retained without modification.
8. An expected, or required, optional parameter (e.g., AuthorizationDenied,AuthorizationPeriod, OriginationIndicator, TerminationRestrictionCode,CallingFeaturesIndicator, Digits (Carrier)) was not received. A received optional parameterrequired the MSC to expect an additional optional parameter that was not received (e.g.,OriginationIndicator value set to Selected NPA-NXX but the expected Digits(Destination) parameter was not received).
Note: the remainder of this section is retained without modification.
Align Chapter 6 “Error Code Tables” with the recommendations in Chapter 5 “Table 200 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters”.
Note: the omitted existing text is retained without modification.
7. An expected, or required, optional parameter (e.g., AuthorizationDenied,AuthorizationPeriod, OriginationIndicator, TerminationRestrictionCode,CallingFeaturesIndicator, or a Digits (Carrier)) was not received. A received optionalparameter required the VLR to expect an additional optional parameter that was not
received (e.g., OriginationIndicator value set to Selected NPA-NXX , but the expectedDigits (Destination) parameter was not received).
Note: the remainder of this section is retained without modification.
Align Chapter 6 “Error Code Tables” with the recommendations in Chapter 5 “Table 200 Forward Compatibility Guidelines for Handling Incoming Messages and Parameters”.
Tab le 45 HLR QualificationRequest Response(TIA/EIA-41.6-D page 6-217)
Note: the omitted existing text is retained without modification.
Problem Detections:
5. A supplied parameter value is unrecognized or has nonstandard values (e.g., Not used ).
Note: the omitted existing text is retained without modification.
7. An expected, or required, optional parameter (e.g., AuthorizationDenied,AuthorizationPeriod, OriginationIndicator, TerminationRestrictionCode,CallingFeaturesIndicator, or a Digits (Carrier)) was not received. A received optionalparameter required the VLR to expect an additional optional parameter that was notreceived (e.g., OriginationIndicator value set to Selected NPA-NXX , but the expectedDigits (Destination) parameter was not received).
Note: the remainder of this section is retained without modification.
When TLDNs are exhausted., use error code "Unavailable" to prevent the MS from beingmarked inactive.
TR45.2.II/98.10.20#8; [GTE]
TR45.2.III/99.01.07#6; [GTE]
Provide Chapter 6 corrections to eliminate registration procedure collisions/race-conditions
regarding RegistrationCancellation, as originally identified by LG Sansys.
4. 41 .1 HLR Initiating a Routing Request(TIA/EIA-41-D Chapter 6, page 6-350, line 7)
When an HLR requires a temporary routing address to a termination, such as, an MS,a mail box on a voice mail system, an interaction dialog, or other voice resource, itshall perform the following (termination specific parameter should already beincluded):
Note: the omitted existing text is retained without modification.
19 WHEN a RETURN RESULT is received:
19-1 Stop timer (RRT).
19-2 IF the message cannot be processed:
19-2-1 Execute “Local Recovery Procedures” task (see 3.5.1).
19-2-2 Include the AccessDeniedReason parameter set to Unavailable
Termination Denied .
19-3 ENDIF.
20 WHEN a RETURN ERROR or REJECT is received:
20-1 Stop timer (RRT).
20-2 Execute “Local Recovery Procedures” task (see 3.5.1).
20-3 Include the AccessDeniedReason parameter set to Unavailable Termination
Denied .
20-4 IF the Error Code indicates UnrecognizedMIN OR IF the Error Codeindicates OperationNotSupported:
20-4-1 IF the VLR from which the RETURN ERROR was received is the
VLR serving the MS:
20-4-1-1 Clear the HLR’s pointer to the VLR serving the MS.
20-4-2 ENDIF.
20-4-1 Clear the HLR’s pointer to the VLR serving the MS.
20-5 ENDIF.
21 WHEN timer (RRT) expires:
21-1 Execute “Local Recovery Procedures” task (see 3.5.1).
21-2 Include the AccessDeniedReason parameter set to Unavailable Termination Denied .
22 ENDWAIT.
23 Return to the calling task.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
Enhancement to support SMDPP acknowledgment delivery to a mobile station after handoff .
4.4 6.X1 MSC Initiating SMS Delivery Point To Point Ack(new for TIA/EIA-41.6-D page 6-284, line 45)
Upon request to send a Short Message acknowledgment to an MS originated shortmessage, when an MS undergoes handoff after initiating an SMS origination:
1 Relay included parameters.
2 Set the underlying transport destination address and the message destination tothe next MSC in the handoff chain.
3 Include InterMSCCircuitID parameter set to the trunk used in the directiontoward the Serving MSC.
4 Include SMS_TransactionID parameter to identify the MS which originated theSMS.
5 IF either the IMSI parameter or the MobileIdentificationNumber parameter isavailable:
5-1 Include the IMSI parameter, or the MobileIdentificationNumber parameter,or both parameters.
6 ENDIF.
7 Send a SMSDeliveryPointToPointAck INVOKE message toward the destinationaddress.
8 Exit this task.
TR45.2.3/99.08.19#16; [Ericsson]
Enhancement to support SMDPP acknowledgment delivery to a mobile station after handoff .
4. 4 6. X 2 MSC Receiving an SMSDeliveryPointToPointAck INVOKE
(new for TIA/EIA-41.6-D page 6-284, line 45)
Upon receipt of an SMSDeliveryPointToPointAck INVOKE, the MSC shall do thefollowing:
1 IF the received message can be processed:
1-1 IF the MSC is a Serving MSC:
1-1-1 Relay parameters received to the MS.
1-1-2 IF the MS is still being served:
1-1-2-1 IF the SMS delivery was successful:1-1-2-1-1 Relay parameters received to the MS.
1-1-2-1-2 Send a SMD-ACK to the MS based SME.
1-1-2-2 ELSE:
1-1-2-2-1 Relay the indicated SMS_CauseCode.
1-1-2-2-2 Send an SMD-NAK to the MS based SME.
1-1-2-3 ENDIF.
1-1-3 ELSE:
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
4. 47 .3 MC Receiving an SMSNotification INVOKE(TIA/EIA-41-D Chapter 6, page 6-286)
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
Tab l e 56 MC SMSNotification Response
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2/99.08.16#13; [WNP PH3 editor].
Internationalize 4.48.1 MC Initiating SMS Request; this is an enhancement to TIA/EIA/IS-751
4.48. 1 MC Initiating SMS Request(TIA/EIA-41-D Chapter 6, page 6-288)
Upon request to obtain a routing address for an MS-based SME (this request may beaccepted , postponed , unavailable, or denied ), the MC shall do the following:
1 IF the ESN is known for the MS:
1-1 Include the ElectronicSerialNumber parameter set to identify the MS.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.
TR45.2.2/99.04.14#7; [Alcatel]
On mobile station power up provide an update to the message waiting notification information because some mobile station implementations do not remember the last received information.
5. 13 .9 MSC MWN Status Change Invocation(TIA/EIA-41-D Chapter 6, page 6-369, line 32)
Upon request, the MSC shall do the following:
1 IF a MessageWaitingNotificationCount or MessageWaitingNotificationTypeparameter is received or if it is otherwise indicated that message waiting
notification is required:
1-1 IF the MS is served by the current system:
1-1-1 IF the MessageWaitingNotificationCount parameter was received:
1-1-1-1 Order the MS to update its message waiting notificationcount(s).
1-1-2 ENDIF.
Note: the remainder of this section is retained without modification; see IS-730.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
OTAPA Data Message Exchange(TIA/EIA/IS-725-A, page 6-212)
Upon receipt of an SMDPP INVOKE with ServiceIndicator parameter indicatingeither CDMA OTASP Service or CDMA OTAPA Service AND SMS_BearerData
parameter with non-zero length, the MSC shall do the following:
Note: the omitted portion of this section is retained without modification.
1-3 CDMA OTAPA Service:
Note: the omitted portion of this section is retained without modification.
1-3-3-1-1-3 IF the MS mobile is idle:
1-3-3-1-1-3-1 Allocate a traffic channel to enable the delivery of OTASP Data messages to the MS and retain thetraffic channel until further instructions.
1-3-3-1-1-3-2 IF a traffic channel is not successfully allocated:
1-3-3-1-1-3-2-1 Include the SMS_CauseCode parameter set to theappropriate value (e.g., No page response).
1-3-3-1-1-3-2-2 Send an SMDPP RETURN RESULT to therequesting OTAF.
1-3-3-1-1-3-2-3 Exit this task.
1-3-3-1-1-3-3 ENDIF.
1-3-3-1-1-4 ENDIF.
1-3-3-1-1-5 IF the InterMessageTime parameter is present AND the
MSC supports variable inter-message guard timing:
1-3-3-1-1-5-1 Use the received parameter value for inter-
message guard timing for this OTAPA session.
1-3-3-1-1-6 ENDIF.
1-3-3-1-2 ELSE (ActionCode parameter is not Allocate Resources):
Note: the remainder of this section is retained without modification.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
5 Include the ServiceIndicator parameter set to either the CDMA OTASP Serviceor the CDMA OTAPA Service value, as appropriate.
6 Include the ActionCode parameter set to indicate Initiate Registration Notification.
8 Send an SMDPP INVOKE to the Serving MSC.
9 Start the SMDPP timer (SMTcm).
10 WAIT for an SMDPP response:
11 WHEN a RETURN RESULT is received:
11-1 Stop the timer (SMTcm).
11-2 IF the message can not be processed:
11-2-1 Execute the “OTAF Recovery Procedure” task (see 5.C6.1).
11-3 ELSE:
11-3-1 IF the message contains an SMS_CauseCode parameter:
11-3-2 Record the failure result and the SMS_CauseCode value.
11-3-3 ELSE:
11-3-4 Record the successful result.
11-3-5 ENDIF.
11-3-6 Return the results to the invoking task.
11-4 ENDIF.
12 WHEN a REJECT is received:
12-1 Stop the timer (SMTcm).
12-2 Execute “OTAF Recovery Procedure” task (see 5.C6.1).
13 WHEN the timer (SMTcm) expires:
13-1 Execute “OTAF Recovery Procedure” task (see 5.C6.1).
14 ENDWAIT.
15 Exit this task.
TR45.2.2/99.08.16#12; [GTE];
IS-725-A enhancement supporting the OTAF to notify the Serving MSC that an MS’s IMSI_M and IMSI_T have been programmed (or re-programmed).
5. C4. 2 MSC Receiving SMDPP INVOKE for Registration ofM S
(TIA/EIA/IS-725-A, page 6-201)
Upon receipt of an SMDPP INVOKE with the ActionCode parameter indicating Initiate Registration Notification and the ServiceIndicator parameter indicates eitherCDMA OTASP Service or CDMA OTAPA Service, the MSC shall do thefollowing:
1 IF the received message can be processed:
1-1 IF the OTASPCallEntry is found OR (IF the ServiceIndicator parameterindicates CDMA OTAPA Service AND IF an OTAPA session is active):
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
IS-725-A enhancement supporting the OTAF to notify the Serving MSC that an MS’s IMSI_M and IMSI_T have been programmed (or re-programmed).
5. C4. 3 OTAF Initiating SMDPP INVOKE to Record New
MS ID (TIA/EIA/IS-725-A, page 6-201)
When triggered (the trigger must include the newly assignedMobileIdentificationNumber or IMSI or both value(s) ), the OTAF shall do thefollowing:
1 Include the SMS_BearerData parameter with its length set equal to zero.
2 Include the SMS_TeleserviceIdentifier parameter with its length set equal to zero.
3 Include the ElectronicSerialNumber parameter set to the MS'sElectronicSerialNumber value returned from the Serving MSC.
a IF CDMA OTASP Service:
a-1 Include the MobileIdentificationNumber parameter set to the
Activation_MIN value.b ENDIF.
c IF CDMA OTAPA Service:
c-1 Include the MSID parameter set to the value of the MS's MIN or IMSI atthe start of the OTAPA session. (When the MS has both the MIN & theIMSI at the start of the OTAPA session then the MIN form of the MSID isused.)
d ENDIF.
5 Include the ServiceIndicator parameter, set to either the CDMA OTASP Serviceor the CDMA OTAPA Service value, as appropriate.
6 Include the ActionCode parameter set to indicate Record NEWMSID.
u IF the MIN or IMSI_M has been assigned:u-1 Include the NewlyAssignedMIN parameter set to the MIN6 value.
u-2 IF the IMSI_M has been assigned:
u-2-1 Include the NewMINExtension parameter set to the IMSI_M_CLASS,
IMSI_M_ADDR_NUM, MCC_M, and IMSI_M_11_12 of the
IMSI_M.
u-3 ENDIF.
v ENDIF.
w IF the IMSI has been assigned:
w-1 Include the NewlyAssignedIMSI parameter set to the IMSI value.
6If the IMSI_M has been assigned, the IMSI_M_S is used as the MIN value.
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January
11-2-1 Execute the “OTAF Recovery Procedure” task (see 5.C6.1).
11-3 ELSE:
11-3-1 IF the message contains an SMS_CauseCode parameter:
11-3-1-1 Record the failure result and the SMS_CauseCode.
11-3-2 ELSE:
11-3-2-1 Record the successful result.
11-3-3 ENDIF.
11-3-4 Relay the results to invoking task.
11-4 ENDIF.12 WHEN a REJECT is received:
12-1 Stop the timer (SMTcs).
12-2 Execute “OTAF Recovery Procedure” task (see 5.C6.1).
13 WHEN the timer (SMTcs) expires:
13-1 Execute “OTAF Recovery Procedure” task (see 5.C6.1).
14 ENDWAIT.
15 Exit this task.
TR45.2.2/99.08.16#12; [GTE];
IS-725-A enhancement supporting the OTAF to notify the Serving MSC that an MS’s IMSI_M and IMSI_T have been programmed (or re-programmed).
5. C4. 4 MSC Receiving SMDPP INVOKE to Record NEWMS ID
(TIA/EIA/IS-725-A, page 6-201)
Upon receipt of an SMDPP INVOKE with the ActionCode parameter indicating Record NEWMSID and the ServiceIndicator parameter indicates either CDMAOTASP Service or CDMA OTAPA Service, the MSC shall do the following:
1 IF the received message can be processed:
1-1 IF the OTASPCallEntry is found OR (IF the ServiceIndicator parameterindicates CDMA OTAPA Service AND IF an OTAPA session is active):
1-1-1 IF NewlyAssignedMIN is received:
1-1-1-1 Record the received NewlyAssignedMIN value.
1-1-2 ENDIF.
1-1-x IF a NewMINExtension is received:
8/14/2019 3GPP2 N.S0015 Version 1.0.0 Version Date: January