3gpp2 n.s0015 version 1.0.0 version date: january

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

COPYRIGHT3GPP2 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.



Revision History

Revision Date

Rev. 0 Initial Publication December 1999

Note

None.



A-4DMisanoEnmens(19

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



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

i Contents

CONTENTS

LIST OF FIGURES ................................................... ....................................................... ..... viii

LIST OF TABLES..................................................... ....................................................... ....... xi

REVISION HISTORY.................... ........................................................ ................................ xiv

CONTRIBUTION HISTORY (Post Revision 10)................................... ............................... ........ xv

Accepted Contributions Not Included................................... ....................... ..................... xx

1. INTRODUCTION......................................................................................................... 1

1.1 OBJECTIVE ....................................................................................................1

1.2 SCOPE......... . .. . .. . . .. . .. . .. . . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. .1

1.3 ORGANIZATION.............................................................................................1

2. TIA/EIA-41.2-D Stage 2; Intersystem Handoff Information Flows Enhancements......................2

4.2.1 Successful FacilitiesDirective2.................................................................2

4.5.1 Successful HandoffBack2 ................................. ................................. ......2

4.9.1 Successful HandoffToThird2......... ................................. .......................... 2

5. BASIC INTERSYSTEM HANDOFF SCENARIOS................................................3

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

3. TIA/EIA-41.3-D Stage 2; Automatic Roaming Information Flows Enhancements .. .. .. .. .. .. .. .. .. .. . 9

3.2 AUTHENTICATION ON SUSPICIOUS CALL ORIGINATION...... ....................... 10

4.1.1 Initiate SSD Update (New SSD shared for SSD Update).............................. 11

4.1.6 Revocation of SSD Sharing ............................... ................................. .. 13

4.3.1 Successful AuthenticationFailureReport: Access Denied on InitialRegistration ................................ ................................. ...................... 14

4.4.1 Successful Authentication on Initial Access.............................................. 15

4.4.3 Successful Authentication on Call Origination (SSD not shared). ..... .... ..... ... 16

4.4.6 Successful Authentication on Call Origination (SSD shared) ..... ..... ..... ..... ... 17

4.4.X Authentication on Suspicious Call Origination (SSD not shared) ... ... ... ... ... .. 18

4.4.X1 Authentication on Suspicious Call Origination (SSD Shared) ... ... ... ... ... ... ... . 19

4.5.1 Report of AC-initiated Action................................................................ 20

4.5.2 Report of VLR-initiated Action.............................................................. 21

4.12.1 Successful Information Forward ................................. ............................ 21

4.14.1 Successful InterSystemPage: Border MSC Routing Information Returned .. .. .. 22

4.15.1 Successful InterSystemPage: MS Presence Confirmed in Border MSC........... 23



A-4DMisanoEnmens(19


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

Contents ii

4.20.2 Successful QualificationDirective: Re-authorization and Update Profile. .. .. .. .. . 23

4.21.2 Successful QualificationRequest: Authorization Confirmed and ProfileReturned..................... ........................................................ ............... 24

4.26.1 Successful RegistrationNotification: Confirmed at the VLR ... ... ... ... ... ... ... ... 24

4.32.C2 Exchange of OTASP Data Messages..... ..... ..... ..... ..... ..... ..... ...... ..... ...... ... 25

4.32.C3 OTAF Request to Initiate MSC Procedures ..... ..... ..... ..... ..... ..... ..... ...... ..... 264.34.T1 Successful SMSRequest during OTASP: MS-Based SME.. ... ... ... ... ... ... ... ... . 28

8:TT.5 Serving MSC Attachment to the OTAF: Reprogramming........................... 29

5.4.x Authentication on Voice Channel, Access Denied, HLR/AC gives directiveto route call.................................................... .................................... 30

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

6.16.1 PL Registration (variable option) ................................ ........................... 41

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

7.20a Postponed MSC SMSNotification with Multiple SMDPPs.. ..... ..... ..... ..... .. 44

8..3.7.1 ICS with Called Party Location (HLR based SIM)..................................... 44

8.CC.9 Registration Following Successful OTA............................... ................... 45




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

iii Contents

8.CC.10 Notification of Newly Assigned MIN (or IMSI M) or IMSI or BothFollowing Successful OTA. ..... ..... ..... ..... ..... ..... ...... ..... ...... ..... ...... ..... ... 48

9.CC.2 OTA Parameter Administration - MS is Available..... ..... ..... ..... ..... ..... ..... .. 49

4. TIA/EIA-41.5-D Stage 3; Signaling Protocol Enhancements ..... ..... ..... ..... ..... ..... ...... ..... ...... 50

5.1 SS7-BASED DATA TRANSFER SERVICES.....................................................50

5.1.1 Message Transfer Part.. ................................. ................................. ...... 50

5.1.2 Signaling Connection Control Part......................................................... 51

6.3.2.3.1 Error Definitions............................................. 52

6.4.1.2 Operation Specifiers........................................................... 54

6.4.2 Operation Definitions........................................................................... 54

6.4.2.i AnalyzedInformation.......................................................... 55

6.4.2.1 AuthenticationDirective...................................................... 56

6.4.2.3 AuthenticationFailureReport................................................ 57

6.4.2.4 AuthenticationRequest........................................................ 59

6.4.2.5 AuthenticationStatusReport................................................. 60

6.4.2.10 FacilitiesDirective............................................................. 61

6.4.2.11 FacilitiesDirective2............................................................61

6.4.2.m FacilitiesSelectedAndAvailable............................................. 63

6.4.2.13 FeatureRequest.................................................................. 64

6.4.2.16 HandoffBack2 ................................................................... 65

6.4.2.19 HandoffMeasurementRequest2.............................................. 65

6.4.2.20 HandoffToThird2............................................................... 67

6.4.2.21 InformationDirective.......................................................... 68

6.4.2.22 InformationForward ........................................................... 69

6.4.2.24 InterSystemPage ............................................................... 70

6.4.2.25 InterSystemPage2.............................................................. 726.4.2.26 InterSystemSetup..............................................................74

6.4.2.27 LocationRequest................................................................ 75

6.4.2.X MessageDirective .............................................................. 76

6.4.2.29 MSInactive ...................................................................... 77

6.4.2.30 OriginationRequest............................................................78

6.4.2.35 RedirectionRequest ............................................................ 79

6.4.2.V Release............................................................................ 80

6.4.2.40 RoutingRequest ................................................................ 80

6.4.2.H ServiceRequest.................................................................. 82

6.4.2.41 SMSDeliveryBackward....................................................... 836.4.2.43 SMSDeliveryPointToPoint................................................. 84

6.4.2.W SMSDeliveryPointToPointAck............................................ 86

6.4.2.44 SMSNotification............................................................... 86

6.4.2.44 SMSRequest .................................................................... 87

6.4.2.t TBusy........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .88

6.4.2.u TNoAnswer........ .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. 89

6.4.2.46 TransferToNumberRequest..... ................................. ............ 90



A-4DMisanoEnmens(19


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

Contents iv

6.4.2.51 UnsolicitedResponse.......................................................... 91

6.5.1.2 Parameter Identifiers........................................................... 93

6.5.2 Parameter Definitions........................................................................... 96

6.5.2.5 AnnouncementCode........................................................... 96

6.5.2.30 CDMAChannelData........................................................... 97

6.5.2.eb CommandCode .................................................................996.5.2.53 DeniedAuthorizationPeriod...................................... ............ 99

6.5.2.ec DisplayText2...................................................................100

6.5.2.62 DMH_RedirectionIndicator.......... ................................. ......103

6.5.2.fd InterMessageTime ............................................................103

6.5.2.78 MessageWaitingNotificationCount ............................... .......104

6.5.2.79 MessageWaitingNotificationType........................................104

6.5.2.fe MSIDUsage ....................................................................104

6.5.2.ff NewMINExtension...........................................................105

6.5.2.ad NonPublicData ................................................................106

6.5.2.89 OriginationIndicator..................................... .....................1066.5.2.ed PageCount......................................................................107

6.5.2.ee PageResponseTime...........................................................107

6.5.2.96 PreferredLanguageIndicator ................................ .................107

6.5.2.97 Profile............................................................................108

6.5.2.af PSID_RSIDIdentification (new) ................................. .........109

6.5.2.xx QOSPriority....................................................................110

6.5.2.111 ReleaseReason.......................................... .......................111

6.5.2.115 SeasureType........................................... .........................111

6.5.2.123 SMS_Address.......................................... ........................111

6.5.2.125 SMS_CauseCode ............................ .................................1126.5.2.127 SMS_DestinationAddress...................................................112

6.5.2.ef SMS_TransactionID .........................................................112

6.5.2.147 SystemMyTypeCode.........................................................113

6.5.2.152 TDMACallMode........................................ ......................115

6.5.2.j TDMATerminalCapability.................................................116

6.5.2.154 TerminalType.......................................... ........................117

6.5.2.157 TerminationRestrictionCode.................................... ...........119

6.5.2.159 TerminationTriggers ............................... ..........................119

6.5.2.160 TransactionCapability .............................. .........................119

6.5.2.p UserZoneData (new)..........................................................120

6.5.3.2 DigitsType......................................................................121

TIA/EIA-41.6-D Stage 3; Signaling Procedure Enhancements.........................................................122

2.1 INTERSYSTEM HANDOFF PROCEDURES....................................................122

3.1 REGISTRATION CALL TASKS .....................................................................122

3.1.1 Autonomous or Power-On Registration...................................... ............122

3.1.3 Loading of Profile Parameters.................. ................................. ............123




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

v Contents

3.2.4 HLR Analyze MS Dialed Number.... ................................. ....................124

3.2.8 Initialize the OneTimeFeatureIndicator Parameter......................................124

3.3.2 Wait for TLDN Call...........................................................................124

3.3.3 Page an MS Procedure.........................................................................124

4.1.2 HLR Receiving AuthenticationDirective INVOKE....................................125

4.1.3 VLR Receiving AuthenticationDirective INVOKE....................................1254.1.4 MSC Receiving AuthenticationDirective INVOKE. ..... ..... ..... ..... ..... ..... ....126

4.1.5 VLR Initiating an Authentication Directive.. ...... ..... ...... ..... ...... ..... ...... ....126

4.3.1 MSC Initiating Authentication Failure Report..... ...... ..... ...... ..... ...... ..... ...127

4.3.2 VLR Receiving AuthenticationFailureReport INVOKE ..... ..... ..... ..... ..... ....127

4.3.3 HLR Receiving AuthenticationFailureReport INVOKE ..... ..... ..... ..... ..... ....128

4.3.4 AC Receiving AuthenticationFailureReport INVOKE ..... ..... ..... ..... ..... ..... .128

4.3.5 VLR Initiating an Authentication Failure Report......................................129

4.4.1 MSC Initiating an Authentication Request. ..... ..... ..... ..... ..... ..... ..... ..... .....129

4.4.2 VLR Receiving AuthenticationRequest INVOKE ..... ..... ..... ..... ..... ..... ...... .130

4.4.3 HLR Receiving AuthenticationRequest INVOKE ..... ..... ..... ..... ..... ..... ...... .1304.4.4 AC Receiving AuthenticationRequest INVOKE ..... ..... ..... ...... ..... ...... ..... ..130

4.5.1 MSC Initiating an Authentication Status Report. ..... ..... ..... ..... ..... ..... ...... .131

4.5.2 VLR Awaiting AuthenticationStatusReport INVOKE ..... ..... ..... ..... ..... ..... .131

4.5.3 HLR Receiving AuthenticationStatusReport INVOKE ..... ..... ..... ..... ..... .....131

4.5.4 AC Awaiting AuthenticationStatusReport INVOKE .... ..... ..... ..... ..... ..... ....132

4.6.3 HLR Receiving BaseStationChallenge INVOKE ..... ..... ..... ..... ...... ..... ...... .133

4.11.1 Serving MSC Initiating a Facilities Directive... ..... ..... ..... ..... ..... ..... ...... ...134

4.11.2 Target MSC Receiving a Facilities Directive. ..... ...... ...... ..... ...... ..... ...... ...134

4.12.2 Target MSC Receiving a Facilities Directive2 ..... ...... ..... ...... ..... ...... ..... ...136

4.13.2 MSC Receiving FacilitiesRelease INVOKE ..... ..... ..... ..... ..... ..... ..... ..... ....137

4.14.1 MSC Detecting Feature Request............................................................138

4.14.3 HLR Receiving FeatureRequest INVOKE ..... ..... ..... ..... ..... ...... ..... ...... .....139

4.16.3 Target MSC Handoff Back ................................ ................................. ..139

4.17.3 Target MSC Handoff Back2..................................................................140

4.20.2 Tandem MSC Receiving HandoffToThird INVOKE ..... ..... ..... ..... ..... ..... ....137

4.24.1 MSC Awaiting InterSystemAnswer. ..... ..... ..... ..... ..... ..... ..... ..... ...... ..... ...142

4.25.1 MSC Initiating an InterSystemPage.......................................................142

4.25.2 MSC Receiving InterSystemPage INVOKE ..... ..... ..... ..... ..... ..... ..... ..... ....142

4.26.1 MSC Initiating an InterSystemPage2.... ..... ..... ..... ..... ..... ..... ...... ..... ...... ..142

4.26.2 MSC Receiving InterSystemPage2 INVOKE...........................................143

4.27.1 MSC Initiating an InterSystem Setup ..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..143

4.XX Message Directive ............................. ................................. ............................143

4.XX.1 HLR Receiving a MessageDirective INVOKE..........................................143

4.30.4 HLR Receiving MSInactive INVOKE..... ..... ..... ..... ..... ..... ..... ..... ..... ..... ..143

4.31.1 MSC Initiating an Origination Request ..... ...... ..... ...... ..... ...... ..... ...... ..... .144

4.31.2 HLR Receiving an OriginationRequest INVOKE......................................144

4.32.2 VLR Receiving QualificationDirective INVOKE.... ..... ...... ..... ...... ..... ...... .145



A-4DMisanoEnmens(19


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

Contents vi

4.32.4 MSC Receiving QualificationDirective INVOKE ..... ..... ..... ..... ..... ..... ...... .146

4.33.3 VLR Receiving QualificationRequest INVOKE........................................146

4.33.4 HLR Receiving QualificationRequest INVOKE........................................147

4.35.2 MSC Receiving RedirectionDirective INVOKE........................................147

4.36.2 MSC Receiving RedirectionRequest INVOKE ..... ...... ..... ...... ..... ...... ..... ...148

4.37.1 HLR Initiating Registration Cancellation................................................1484.37.3 VLR Initiating Registration Cancellation................................................148

4.38.2 VLR Receiving RegistrationNotification INVOKE..... ..... ..... ..... ..... ..... .....148

4.38.3 HLR Receiving RegistrationNotification INVOKE..... ..... ..... ..... ..... ..... .....148

4.41.1 HLR Initiating a Routing Request.... ..... ...... ..... ...... ..... ...... ..... ...... ..... ....149

4.41.1 HLR Initiating a Routing Request.... ..... ...... ..... ...... ..... ...... ..... ...... ..... ....150

4.XX RELEASE....................................................................................................150

4.XX.1 MSC Initiating a Release.....................................................................150

4.XX.2 MSC Receiving a Release INVOKE ..... ..... ..... ..... ..... ..... ..... ...... ..... ...... ..150

4.41.2 VLR Receiving RoutingRequest INVOKE..... ..... ..... ..... ..... ..... ...... ..... .....150

4.41.3 MSC Receiving RoutingRequest INVOKE ..... ..... ..... ..... ..... ..... ..... ...... ....1504.41.3 MSC Receiving RoutingRequest INVOKE ..... ..... ..... ..... ..... ..... ..... ...... ....151

4.44.1 MSC Initiating SMS Delivery Backward ..... ..... ..... ..... ...... ..... ...... ...... .....151

4.46.2 Initiating SMS Delivery Point-To-Point.................................................152

4.46.5 Anchor MSC Initiating SMS Delivery Point-To-Point..............................153

4.46.X1 MSC Initiating SMS Delivery Point To Point Ack.................................154

4.46.X2 MSC Receiving an SMSDeliveryPointToPointAck INVOKE... ... ... ... ... ... .154

4.47.2 MSC Initiating SMS Notification.. ..... ..... ..... ..... ..... ..... ..... ..... ...... ..... ....155

4.47.3 MC Receiving an SMSNotification INVOKE..........................................155

4.48.1 MC Initiating SMSRequest..................................................................155

4.48.2 HLR Receiving an SMSRequest INVOKE... ..... ...... ..... ...... ..... ...... ..... .....156

4.48.3 VLR Receiving an SMSRequest INVOKE... ..... ...... ..... ...... ..... ...... ..... .....157

4.48.4 MSC Receiving an SMSRequest INVOKE ..... ..... ..... ..... ..... ..... ..... ...... ....157

4.49.1 MSC Initiating a Transfer-To-Number Request ..... ..... ...... ..... ...... ..... ...... ..158

4.49.2 HLR Receiving a Transfer-To-Number Request INVOKE...........................158

4.54.2 MSC Receiving UnsolicitedResponse INVOKE....... ..... ..... ..... ..... ..... ..... ..158

5.1.3 HLR CD Incoming Call Invocation.................................... ...................158

5.8.2 HLR CNIP Redirecting Call Invocation..................................................158

5.8.4 MSC CNIP Terminating Call Invocation................................................158

5.13.6 HLR MWN Status Change Invocation ...... ..... ...... ..... ...... ..... ...... ..... ...... .159

5.13.7 MSC MWN Call Origination Invocation.... ..... ...... ..... ...... ..... ...... ...... .....159

5.13.8 MSC MWN Call Termination Invocation.... ..... ..... ...... ..... ...... ..... ...... .....159

5.13.9 MSC MWN Status Change Invocation...................................................159

5.16.1 HLR PL Language Registration....................................... .....................160

5.18.1 HLR RFC Incoming Call Invocation... ..... ..... ..... ..... ...... ..... ...... ..... ...... ..160

5.19.7 HLR SCA Incoming Call Invocation... ..... ..... ..... ..... ...... ..... ...... ..... ...... ..160

5.C3 EXCHANGE OF OTASP DATA MESSAGES ...................................................161

5.C3.1 OTAF Initiating SMDPP INVOKE for OTASP Data Message Exchange......161




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

vii Contents

5.C3.2 MSC Receiving SMDPP INVOKE for OTA Data Message Exchange... ... ... .162

5.C4 MSC Procedure Triggers for OTASP ............................... ................................. .163

5.C4.1 OTAF Initiating SMDPP INVOKE for MS Registration.. ... ... ... ... ... ... ... ... .163

5.C4.2 MSC Receiving SMDPP INVOKE for Registration of MS........................164

5.C4.3 OTAF Initiating SMDPP INVOKE to Record NewMSID... ... ... ... ... ... ... ... ..166

5.C4.4 MSC Receiving SMDPP INVOKE to Record NEW MSID. ... ... ... ... ... ... ... ..1677 Operation Timer Values...................................................................................169

8 CDMA2000 HANDOFF ENHANCEMENTS ......... . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . ..169

D ANNEX D: SMS Air Interface Delivery Point-to-Point............................. ........................170

D.4 MS-Based SME Initiating SMD-REQUEST Toward an MSC.................................171

D.5 Serving MSC Receiving an SMD-REQUEST ............................. ........................172

4. APPENDIX ......... .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. . .. . . .. . .. . .. . . .. . .. . .. . . .. .173



A-4DMisanoEnmens(19


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

List Of Figures viii

LIST OF FIGURES

Figure 9 Successful HandoffBack2 ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .2

Figure 14 Successful HandoffToThird2......... . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. .2

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 6 Revocation of SSDSharing .. .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .13

Figure 8 Access Denied on Initial Registration......... . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . 14

Figure 9 Successful Authentication on Initial Registration ......... . .. . . .. . . .. . .. . . .. . . .. . .. . 15

Figure 11 Successful Authentication on Call Origination (SSD not shared)............... 16

Figure 14 Successful Authentication on Call Origination (SSD shared).................... 17

Figure 4.4.X Authentication on Suspicious Call Origination (SSD not shared).......... .... 18

Figure 4.4.X1 Authentication on Suspicious Call Origination (SSD shared).................... 19

Figure 17 Report of AC-initiated Action............................................................. 20

Figure 18 Report of AC-initiated action.............................................................. 21

Figure 29 Successful InterSystemPage: Border MSC Routing Information Returned ... 22

Figure 32 Successful InterSystemPage2: MS Presence Confirmed in Border MSC...... 23

Figure 4.32.C3 OTAF Request to Initiate MSC Procedures ................................. .......... 26

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




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 12 AnnouncementCode parameter ........ . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . 96

Figure 37 CDMAChannelData parameter....... .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. 98

Figure 6.5.2.eb CommandCode parameter................................................................... 99

Figure 6.5.2.ec DisplayText2 parameter................ ................................. ...................100

Figure 6.5.2.ec1 DisplayText2 parameter for 16-bit Displayed Characters..........................101

Figure 70 DMH_RedirectionIndicator parameter ..................................................103

Figure 5.2.fd InterMessageTime parameter..............................................................103

Figure 5.2.fe MSIDUsage parameter......................................................................104

Figure ff NewlyAssignedMIN parameter....... .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .105

Figure 6.5.2.ad NonPublicData parameter..................................................................106

Figure 97 OriginationIndicator parameter ...........................................................106

Figure 6.5.2.ed PageCount parameter ............................. ................................. .........107

Figure 6.5.2.ee PageResponseTime parameter............................................ ................107

Figure 105 Profile Macro ......... . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .108

Figure IS-730-20 PSID_RSIDInformation parameter......................................................109

Figure xx QOAPriority parameter........ .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .110

Figure 133 SMS_Address Encoding for an IP address.............................................111

Figure 134 SMS_Address parameter for an ANSI SS7 Point Code Address ... ... ... ... ... .111

Figure 138 SMS_DestinationAddress parameter for BCD digits........... ....................112

Figure 6.5.2.ef SMS_TransactionID parameter...........................................................112

Figure 164 SystemMyTypeCode parameter..........................................................113

Figure 169 TDMACallMode parameter ...............................................................115

Figure IS-730-26 TDMATerminalCapability parameter ..... ...... ..... ...... ..... ...... ..... ...... ..... .116



A-4DMisanoEnmens(19


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

List Of Figures x

Figure 171 TerminalType parameter ...................................................................117

Figure 177 TransactionCapability parameter.........................................................119

Figure 3579-31 UserZoneData parameter.... ................................. ..............................120

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




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

xi List Of Tables

LIST OF TABLES

TIA/EIA-41.5-D

Table 1 (continued) . .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. 50

Table 52 Error Codes. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .52Table 8 (concluded) . .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. 54

Table 10 (concluded)........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .54

Table i-1 AnalizedInformation INVOKE Parameters....... . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . 55

Table 11 AuthenticationDirective INVOKE Parameters ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .56

Table 15 AuthenticationFailureReport INVOKE Parameters.................................. 57

Table 16 AuthenticationFailureReport RETURN RESULT Parameters........ . . .. . . .. . . .58

Table 18 AuthenticationRequest RETURN RESULT Parameters ....... .. . . .. . . .. . . .. . . .. . . 59

Table 20 AuthenticationStatusReport RETURN RESULT Parameters ....... .. . . .. . . .. . . .60

Table 29 FacilitiesDirective INVOKE Parameters................................................61

Table 31 FacilitiesDirective2 INVOKE Parameters....... . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . 62

Table m-2 FacilitySelectedAnsAvailable RETURN RESULTS Parameters................ 63

Table 36 FeatureRequest RETURN RESULTS Parameters ....... .. . .. . . .. . . .. . .. . . .. . . .. . .. . 64

Table 41 HandoffBack2 INVOKE Parameters...................................................... 65

Table 47 HandoffMeasurementRequest2 INVOKE Parameters................................ 66

Table 49 HandoffToThird2 INVOKE Parameters ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . 67

Table 51 InformationDirective INVOKE Parameters ....... .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . . 68

Table 53 InformationForward INVOKE Parameters.............................................. 69

Table 57 InterSystemPage INVOKE Parameters....... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .71

Table 59 InterSystemPage2 INVOKE Parameters........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .73

Table 61 InterSystemSetup INVOKE Parameters ........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .74

Table 64 LocationRequest RETURN RESULTS Parameters ........ . . .. . . .. . . .. . . .. . . .. . . .. . 75

Table 6.4.2.X FE Combinations for MSGDIR.......................................................... 76

Table 6.4.2.X1 MessageDirective INVOKE Parameters................................................. 76

Table 6.4.2.X2 MessageDirective RETURN RESULT Parameters... ..... ..... ..... ..... ..... ...... 76

Table 66 MSInactive INVOKE Parameters....... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 77

Table 69 OriginationRequest RETURN RESULT Parameters................................ 78

Table 78 RedirectionRequest INVOKE Parameters............................................... 79

Table 79 RedirectionRequest RETURN RESULT Parameters....... . .. . . .. . . .. . . .. . . .. . . .. . .79

Table 6.4.2.V Release INVOKE Parameters..............................................................80

Table 6.4.2.V1 Release RETURN RESULT Parameters .............................. ................. 80

Table 88 RoutingRequest INVOKE Parameters....... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 81

Table 6.4.2.h-1 ServiceRequest INVOKE Parameters....................................... ............. 82

Table 6.4.2.H-2 ServiceRequest RETURN RESULT Parameters ..... ..... ..... ..... ..... ..... ..... .. 83

Table 91 SMSDeliveryBackward RETURN RESULT Parameters........................... 83

Table 94 SMSDeliveryPointToPoint INVOKE Parameters ....... .. . .. . . .. . . .. . .. . . .. . . .. . .. . 84

Table 6.4.2.W SMSDeliveryPointToPointAck INVOKE Parameters...................... ........ 86

Table 98 SMSRequest INVOKE Parameters....... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 87



A-4DMisanoEnmens(19


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

List Of Tables xii

Table t-1 TBusy INVOKE Parameters ....... .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .88

Table u-1 TNoAnswer INVOKE Parameters........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. 89

Table 100 TransferToNumberRequest INVOKE Parameters..................................... 90

Table 101 TransferToNumberRequest RETURN RESULT Parameters...................... 90

Table 111 UnsolicitedResponse RETURN RESULT Parameters.............................. 91

Table 112 IS-41 MAP Parameter Identifiers (continued) ... ... ... ... ... ... ... ... ... ... ... ... ... .. 93Table 112 (concluded)........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .94

Table 6C.2.3b NewParameters Unique to CDMA ....................................................... 95

Table 117 AnnouncementCode value........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .96

Table 6.5.2.eb CommandCode value ........................................................................99

Table 136 DeniedAuthorizationPeriod value......................................................... 99

Table 6.5.2.ec DisplayText2 value..........................................................................102

Table 6.5.2.bx2 DisplayCharacterSet value..................................................... ............102

Table 140 DMH_RedirectionIndicator value........................................................103

Table 140 (concluded)........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..103

Table 147 MessageWaitingNotificationCount value .............................................104Table 148 MessageWaitingNotificationType value...............................................104

Table 6.5.2.fe MSIDUsage value...........................................................................105

Table xxc Digit value........ . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. . .. .. . .. . .. . .. . .. . .. . .. . .. . .. . ..106

Table 6.5.2.ad NonPublicData value.......................................................................106

Table 104 PreferredLanguageIndicator value ........................................................107

Table 160 (continued)........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..107

Table IS-730-6 PSID_RSIDInformation value ................................. ..........................109

Table 1xx QOSPriority value......... .. . .. .. .. . .. .. .. . .. .. . .. .. .. . .. .. .. . .. .. .. . .. .. .. . .. .. .. . .. .. . .. ..110

Table 165 ReleaseReason value......... . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .111

Table 167 SeizureType value parameter..............................................................111Table 171 SMS_CauseCode value ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. .112

Table 183 SystemMyTypeCode value................................................................114

Table 185 TDMACallMode value........ . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .115

Table IS-730-10 TDMATerminalCapability value... ...... ..... ...... ..... ...... ..... ...... ..... ...... ...116

Table 187 TerminalType value........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .118

Table 189 TerminationRestrictionCode value parameter ........................................119

Table 191 TerminationTriggers value ........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. .119

Table 192 TranactionCapability value parameter..................................................119

Table 196 (continued)........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..121

Table 200 Forward Compatibility Guidelines for Handling Incoming Messages andParameters ............................... ................................. .....................121

TIA/EIA-41.6-D

Table 1 HLR AuthenticationDirective Response......... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..125

Table 2 VLR AuthenticationDirective Response......... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..126

Table 3 MSC AuthenticationDirective Response........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .126

Table5 VLR AuthenticationFailureReport Response ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .128

Table6 HLR AuthenticationFailureReport Response ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .128




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

xiii List Of Tables

Table7 AC AuthenticationFailureReport Response ........ . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. .129

Table 8 HLR AuthenticationRequest Response ... . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. .130

Table 9 VLR AuthenticationRequest Response ... . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. .130

Table 10 MSC AuthenticationRequest Response................................................130

Table 11 VLR AuthenticationStatusReport Response ........ . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . ..131

Table 12 HLR AuthenticationStatusReport Response ........ . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . ..131Table 13 AC AuthenticationStatusReport Response ......... . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. .133

Table 22 HLR FeatureRequest Response ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .139

Table 28 Tandem MSC HandoffToThird Response ........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..142

Table 34 Border MSC InterSystemPage Response........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .142

Table 35 Border MSC InterSystemPage2 Response ......... . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .143

Table 37 HLR LocationRequest Response ........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..143

Table 4.xx1 HLR MessageDirective Response.......................................................143

Table 41 HLR OriginationRequest Response......... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..144

Table 42 VLR OriginationRequest Response......... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..145

Table 43 MSC QualificationDirective Response ........ . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . ..146Table 44 VLR QualificationDirective Response......... . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . ..146

Table 45 HLR QualificationDirective Response......... . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . ..147

Table 47 Originating MSC RedirectionDirective Response ......... . .. . . .. . . .. . .. . . .. . . .. . ..147

Table 48 Originating MSC RedirectionRequest Response........ . .. . . .. . .. . . .. . . .. . .. . . .. . . .148

Table 51 VLR RegistrationNotification Response........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .148

Table4.XX.2 MSC Release Response....................................................................150

Table 54 VLR RoutingRequest Response......... . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..150

Table 55 MSC RoutingRequest Response ........ . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . ..151

Table 56 MC SMSNotification Response......... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..155

Table 57 HLR SMSRequest Response... .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. ..157

Table 58 VLR SMSRequest Response... .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. ..157

Table 59 MSC SMSRequest Response ... .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .. . .. .. . .. .. . .. .. . .. .. .157

Table 60 HLR TransferToNumberRequest Response........ . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .158

Table 62 Neighboring MSC UnsolicitedPageResponse Response..........................158

Table 63 Operation Timer Values (continued)........ . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . ..169

Table 64 SMD-REQUEST Parameters....... .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. .170

Table 65 SMD-ACK Parameters....... .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. . .. . . .. . . .. .170



A-4DMisanoEnmens(19


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

Revision History XIV

REVISION HISTORY

Revision Date Remarks

0 March, 1998 Initial version

1 April, 1998 First Revision2 June 10, 1998 Second Revision

3 July 08, 1998 Third Revision

4 August 19, 1998 Fourth Revision

5 September 16, 1998 Fifth Revision

6 October 21, 1998 Sixth Revision

7 November 19, 1998 Seventh Revision

8 December 16, 1998 Eighth Revision

9 February 4, 1999 Ninth Revision

10 March 18, 1999 Tenth Revision (frozen)

11 April 14, 1999 Eleventh Revision (withdrawn)

10.1 May 20, 1999 Tenth Revision; First Enhancement

10.2 June 17, 1999 Tenth Revision; Second Enhancement

10.3 July 15, 1999 Tenth Revision; Third Enhancement

10.4 August 19, 1999 Tenth Revision; Fourth Enhancement

10.5 September 13, 1999 Tenth Revision; Fifth Enhancement

10.6 October 13, 1999 Tenth Revision; Sixth Enhancement

10.7 November 08, 1999 Tenth Revision; Seventh Enhancement

10.8 December 15, 1999 Tenth Revision; Eighth Enhancement

10.8a MDN based MCs Enhancements

10.8b cdma2000 Enhancements

10.8c TDMA Enhanced Privacy & Encryption

10.9 January 10, 2000 Tenth Revision; Eighth Enhancement

10.9a MDN based MCs Enhancements

10.9b cdma2000 Enhancements

10.9c TDMA Enhanced Privacy & Encryption




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

XV Contribution History

CONTRIBUTION HISTORY (Post Revision 10)

Revision Contributions Remarks

10.1 TR45.2.2/98.04.21#23

SBC TechnologyResources

Support intersystem registration and call delivery formobile stations in Non-Public systems without ANSI-41connectivity.

TR45.2.3/99.03.18.9

NORTEL NETWORKS

Remove the IS-730 added but unusedTDMATerminalCapability parameter from theMeasurementRequest2 INVOKE operation.

This is a change to IS-730 .

TR45.2.3/99.03.18.11

Motorola

Provide SMDPP INVOKE parameters Note “a” textenhancement to support MS-to-MC operations (as well asthe existing MC-to-MS description).

TR45.2/99.03.15.01

Phoenix Wireless Group

Opening Plenary communication requesting aSystemMyTypeCode parameter value assignment.

TR45.2.2/99.04.14.7

Alcatel

On mobile station power up provide an update to the

message waiting notification information because somemobile station implementations do not remember the lastreceived information.

TR45.2.3/99.04.14.7

KDD

Add AnnouncementCode parameter value assignments forCredit Card Calling.

TR45.2.3/99.04.14.13

NORTEL NETWORKS

Permit the MWNCOUNT parameter to be omitted from thePROFILE if all message counts are zero.

TR45.2.3/99.04.14.19

Ericsson

Update TDMATerminationCapability parameter values inthe “Protocol Version” field to include mobile stations thatcomply to TIA/EIA-136-A.

This is a change to IS-730 that replaced TSB76 .

10.2 TR45.2.3/99.05.20.10

Ericsson

IS-764 enhancement adding parameter DisplayTect2 to

many operations to support Multiple Language codedcharacter set display characters.

This is a change to IS-764 “Calling Party NamePresentation and Calling Party Name Restriction(CNAP/CNAR)”.

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, see 10-3)



A-4DMisanoEnmens(19


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 .

TR45.2.3/99.06.17#30Motorola

Miscellaneous nit-picky error correction (e.g., eliminateTerminationRestrictionCode recommendation).




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

XVII Contribution History

10.4 TR45.2.3/99.06.17#4

Ericsson

Provide the AC/HLR with a mechanism to direct call routingat the Serving MSC/VLR when authentication procedurefail.

Include figures: 5.4.x, 5.4.Y.

TR45.2/99.07.12#21

Nortel Networks

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 insteadof GTT-10.

TR45.2.2/99.07.12#3

LG Sansys, Inc.

Add an IS-778 enhancement scenario for authentication onsuspicious Call Origination (SSD Shared).

TR45.2.3/99.07-15#10

Ericsson

Provide an indicator for IntersystemPage andIntersystemPage2 to identify system support of the MIN,IMSI or both parameters.

TR45.2.3/99.07.15#32

Nortel Networks

Enhancement to IS-730 UserZoneData parameter andANSI-41.5-D FacilitiesDirective2 operation to supportCDMA Tiered Services.

TR45.2.3/99.07.15#33

Nortel Networks

Non-Public Mode Service support for User Zones (orPSIDs/RSIDs) that span multiple MSCs.

10.5 TR45.2/99.08.16#13 PN-441 WNP Phase-III V&V (editor)a- add MSID to SMSREQ RETURN RESULT, this is an

TIA/EIA/IS-751 enhancement.

b- Internationalize 4.48.1 MC Initiating SMS Request, thisis an TIA/EIA/IS-751 enhancement.

c- Internationalize 4.48.1 MC Initiating SMS Request

d- Internationalize 4.48.2 HLR Receiving an SMSRequestINVOKE

TR45.2.2/99.08.17#1

Motorola

This WIN remanded recommendation is a change to IS-771 “FacilitySelectedAndAvailable RETURN RESULT”.

TR45.2.2/99.08.17#1

Ericsson

This WIN remanded recommendation is an IS-771internationalization change to:

“AnalizeInformation INVOKE”.“FacilitySelectedAndAvailable INVOKE”.

“ServiceRequest INVOKE”.

“TBusy INVOKE”

“TNoAnswer INVOKE”

TR45.2.2/99.08.17#5

Ericsson

Provide an enhanced FACDIR or FACDIR2 method forHandoff Back; Stage 2.

TR45.2.2/99.08.17#6

Ericsson

Provide an enhanced FACDIR or FACDIR2 method forHandoff Back; Stage 3.



A-4DMisanoEnmens(19


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 XVIII

10.6 TR45.2.2/99.08.16#12

GTE

IS-725-A enhancement supporting the OTAF to notify theServing MSC that an MS’s IMSI_M and IMSI_T havebeen programmed (or re-programmed).

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.3/99.09.15#14DDI, Hitachi, KDD,OKI, Japan Telecom,Fujitsu, IDO, NEC,Motorola Japan,Lucent TechnologiesJapan

Reserve 10-Parameter Identifier Codes for NationalNetwork use.




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.

TR45.2.2/99.10.13#22

Lucent Technologies

IS-725-A OTAPA enhancements supporting interactivemode OTAPA sessions; InterMessageTime (IMTIME).


TR45.2.3/99.11.10#20

Nortel Networks

Enhancement supporting the transport of IS-95-B "BaseStation Protocol Revision" parameter.

This is a change to IS-735 (CDMA).

10.9 TR45.2.3/99.11.08#19

NORTEL NETWORKS

Profile changes to support non-assured packet dataservice radio-link QoS.

TR45.2.3/99.11.10#18

AT&T Wireless

Resolve Error Code collision between IS-751(Unrecognized IMSI and IS-735 (UnrecognizedTIMSI). This is a change to IS-751 and IS-735.

TR45.2.2/99.10.13#22

Lucent Technologies

Eliminate the MSC from rescinding “MIN/IMSI & ESN” inan smsreq RETURN RESULT, the parameters wereinitially sent by the OTAF in the SMSREQ INVOKE.


TR45.2.2/99.12.14#3

NORTEL NETWORKS

Correct IS-771 Stage-2 scenario problem in section8.3.7.1.

TR45.2.3/99.12.15#6

NORTEL NETWORKS

Provide a new TerminalType parameter value for TIA/EIA-136 Revision B mobile stations.

TR45.2.3/99.12.15#7GTE

Enhancement to avoid assigning MDNs to packet onlysubscribed terminals. This is a change to IS-756-A.

TR45.2.3/99.12.15#10

QUALCOMM

When TLDNs are exhausted., use error code"Unavailable" to prevent the MS from being markedinactive.

TR45.2.2/99.12.15#26

SBC TechnologyResources

Provide "Operation Specifier" and "ParameterIdentification Code" values.

10.n



A-4DMisanoEnmens(19


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 XX

Accepted Contributions Not Included ([revised] soft copy not submitted)

Contribution Source Title

TR45.2.3/98.08.19#16 Ericsson Enhancement to support SMDPPacknowledgment delivery to a mobile stationafter handoff.

Missing “4. APPENDIX” scenario event text.

TR45.2.3/99-10-13#23 Lucent need updated soft copy




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.



A-4DMisanoEnmens(19


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 2 TIA/EIA41.2-D (Stage 2)

2. TIA/EIA-41.2-D Stage 2

Intersystem Handoff Information Flows Enhancements

4.2.1 Successful FacilitiesDirective2

(TIA/EIA-41-D Chapter 2, page 2-10)See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.

Figure 9 Successful HandoffBack2

See TIA/EIA-41-D Miscellaneous Enhancements Revision 10.

4.5.1 Successful HandoffBack2(TIA/EIA-41-D Chapter 2, page 2-20)


4.9.1 Successful HandoffToThird2(TIA/EIA-41-D Chapter 2, page 2-34)


Figure 14 Successful HandoffToThird2





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) 3 Intersystem Handoff

TR45.2.2/99.08.17#5; [ERICSSON]

Provide an enhanced FACDIR or FACDIR2 method for Handoff Back; Stage 2.

5 . BASIC INTERSYSTEM HANDOFF SCENARIOS(TIA/EIA-41-D Chapter 2, page 2-42)

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.



A-4DMisanoEnmens(19


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


TR45.2.2/99.08.17#5; [ERICSSON]


5.X 1. Successful Handoff-Back with Tandem viaFacilitiesDirective (Path Minimization is not

supported) (TIA/EIA-41-D Chapter 2, page 2-60)

FACREL

facrel

RESPONSE

CONV w/ PERMISSION

QUERY w/ PERMISSION

Initial ConnectionsA B

XY

C

Anchor

TargetSystem

A

TandemSystem

B

MSC MSC

ServingSystem

C

MSC

h

g

a

b

c

d

e

MS

Served MSX

f

HANDMREQ

LMMRT

call in progress

handmreq

FACDIR

HOT facdir

MSONCH

handoff order

MHOT

MAT

X arrives on new channel

jCTT

kFACREL

iFACREL

l

mfacrel

nfacrel

o

A

XY

Resulting Connections

CTT CTT

handoff-back complete




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


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.



A-4DMisanoEnmens(19


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


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


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


l

CTT

FACREL

mFACREL

kFACREL

n

ofacrel

q

A

XY



pfacrel

CTT CTT

QUERY w/ PERMISSION

CONV w/ PERMISSION

RESPONSE




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


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


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.



A-4DMisanoEnmens(19


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


FACREL

HANDTHIRD


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


CTT CTT

HTTT

call in progress

handthird



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.




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


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)


Figure 23 Successful HandoffToThird with Tandem and PathMinimization



Automatic Roaming Information Flows Enhancements




A-4DMisanoEnmens(19


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

Automatic Roaming Scenarios 10 TIA/EIA41.3-D (Stage 2)

TR45.2.2/99.06.16#21; [LG Sansys]

Provide parameters passed on authreq response clarification.


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.




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.3.D (Stage 2) 11 Automatic Roaming Scenarios

TR45.2.2/99.10.12#10; [GTE]

Align AuthenticationDirective Stage-2 with Stage-3 procedures that support a VLR returning COUNT in an AUTHDIR response.

4.1. 1 Initiate SSD Update (New SSD shared for SSD

Update) (TIA/EIA/41-D Chapter 3, page 3-7)

This operation scenario describes the use of the AuthenticationDirective operation toinitiate a SSD update process when SSD is shared.

e

f

c

d

a

b

AC MSC

ADT

Serving System

HLR VLR

AUTHDIR [MIN, ESN, RANDSSD, NewSSDInfo]

authdir [COUNT]

authdir [COUNT]

authdir [ ]

AUTHDIR [MIN, ESN, RANDSSD, NewSSDInfo]

AUTHDIR [MIN, ESN, LOCID, RANDSSD, NewSSDInfo, RANDU, AUTHU]

ADT ADT

Figure 1 Initiate SSD Update (New SSD shared for SSD Update)



A-4DMisanoEnmens(19


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


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:


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.


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.




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


TR45.2.2/99.10.12#10; [GTE]

Align AuthenticationDirective Stage-2 with Stage-3 procedures that support a VLR returning COUNT in an AUTHDIR response.

4.1.6 Revocation of SSD Sharing

(TIA/EIA/41-D Chapter 3, page 3-16)

This operation scenario describes the use of the AuthenticationDirective operation torevoke SSD sharing.

c

d

a

b

AC

Serving System

HLR VLR

AUTHDIR [MIN, ESN, NOSSD]

authdir [COUNT]

authdir [COUNT]

AUTHDIR [MIN, ESN, NOSSD]

ADT ADT

Figure 6 Revocation of SSD Sharing

a. The AC sends an AUTHDIR to the HLR associated with the MS.


MIN Served MS MIN. R

ESN Served MS ESN. R

NOSSD Indicates that previously provided SSD is nolonger valid and should be discarded.

R

b. The HLR forwards the AUTHDIR to the VLR currently serving the identifiedMS. Parameters are as in Step-a.

c. The Serving VLR discards the current value of the SSD and returns an empty

authdir to the HLR to indicate that the revocation has been accepted.


COUNT Value of event counter used for clone detection

as stored at VLR. Include if COUNT is

available.

O

d. The HLR forwards the authdir to the AC.



A-4DMisanoEnmens(19


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


TR45.2.3/99.08.19#19; [LG Sansys]

Enhancement to support the AC including the TerminalType parameter in afreport operations to distinguish the type of AC (TSB51 or IS-41-C or later).

4. 3. 1 Successful AuthenticationFailureReport: Access Deniedon Initial Registration



a

b

c

d

e

f

Serving System

MSC VLR HLR AC

AFREPORT [AFREPORTParameters]



afreport [DenyAccess, TerminalType]

afreport [DenyAccess, TerminalType]

AFRT

afreport [DenyAccess, TerminalType]AFRT AFRT

Figure 8 Access Denied on Initial Registration


d. The AC determines that the MS should be denied access. The AC returns anafreport to the requesting HLR and includes the DenyAccess parameter.


DenyAccess Indication that MS should be denied access withreason; release of system resources allocated

for this access may be initiated by the MSC.This may include disconnection of any callin progress.

O

TerminalType Include on IS-41-C or later. O

e. The HLR forwards the afreport to the Serving VLR. Parameters are as in

Step-d.




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


Parameters are as in Step-d, with the following additions:


TerminalType Include on IS-41-C or later. O

f. The Serving VLR forwards the afreport to the Serving MSC. Parametersare as in Step-d Step-e.

TR45.2.2/99.06.16#21; [LG Sansys]


4. 4. 1 Successful Authentication on Initial Access(TIA/EIA-41-D Chapter 3, page 3-22)


Figure 9 Successful Authentication on Initial Access


f. The Serving VLR forwards the authreq to the Serving MSC. Parameters areas in Step-d, with the exception that the SSD, AAV, NOSSD and COUNT and

NOSSD parameters are not included.



A-4DMisanoEnmens(19


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


TR45.2.2/99.06.16#21; [LG Sansys]


4. 4. 3 Successful Authentication on Call Origination (SSD notshared)



Figure 11 Successful Authentication on Call Origination (SSD not shared)


d. The AC determines that the MS is valid. The AC sends an authreq to theHLR.

Parameters are as in Section 4.4.1, Step-d, with the exception that the SSD, AAV and

COUNT and AAV parameters are not included and with the following additions:

Parameters Usage TypeNOSSD SSD not shared. O

EncryptionInformation:

[CDMAPLCM] CDMAPrivateLongCodeMask. Include if generated by AC.

O

[SMEKEY] SignalingMessageEncryptionKey. Include if generated by AC.

O

[VPMASK] VoicePrivacyMask. Include if generated by AC. O

e. The HLR forwards the authreq to the Serving VLR.




NOSSD SSD not shared. 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





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


TR45.2.2/99.06.16#21; [LG Sansys]


4. 4. 6 Successful Authentication on Call Origination (SSDshared)



Figure 14 Successful Authentication on Call Origination (SSD shared)


b. The Serving VLR determines that the MS is valid. The VLR sends anauthreq to the Serving MSC.


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



A-4DMisanoEnmens(19


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


TR45.2.2/99.06.16#21; [LG Sansys]



4.4.X Authentication on Suspicious Call Origination (SSD not

shared)(New for TIA/EIA-41.3-D , Section 4.4; TIA/EIA/IS-778 , page 8)


Fi gu re 4 .4 .X Authentication on Suspicious Call Origination (SSD notshared)


d. The AC determines that a Unique Challenge is required. The AC sends anauthreq to the HLR.




RANDU Random number generated by AC to produceAUTHU.

R

AUTHU Expected MS response to the Unique ChallengeOrder as calculated by the AC.

R

NOSSD SSD not shared. O

EncryptionInformation:

[CDMAPLCM] CDMAPrivateLongCodeMask. Include if generated by AC.

O

[SMEKEY] SignalingMessageEncryptionKey. Include if generated by AC. O

[VPMASK] VoicePrivacyMask. Include if generated byAC.

O





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


TR45.2.2/99.07.14#3; [LG Sansys]

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

a

b

MSC

Serving System

VLR

AUTHREQ [AuthReqParameters1, RAND, AUTHR, COUNT, DGTSDIAL, AUTHDATA]

ART

authreq [EncryptionInformation, AuthreqParameters2, RANDU, AUTHU]

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:


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.



A-4DMisanoEnmens(19


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


TR45.2.2/99.06.16#21; [LG Sansys]


TR45.2.3/99.06.17#4; [Ericsson]

Provide the AC/HLR with a mechanism to direct call routing at the Serving MSC/VLR when authentication procedure fail.

4.5 .1 Report of AC-initiated Action(TIA/EIA-41-D Chapter 3, page 3-37)


e

f

c

d

a

b

ACMSC

Serving System

HLRVLR

ASREPORT [MIN, ESN, SYSCAP, TypeOfReport]

asreport [ReportParameterGroup, NewSSDInfo, NOSSD]

ASRT

asreport [ReportParameterGroup, NewSSDInfo, NOSSD, RoutingInfo]

asreport [ReportParameterGroup, RoutingInfo

ASRT ASRT



Figure 17 Report of AC-init iated action


e. The HLR forwards the asreport to the Serving VLR. Parameters are as inStep-d with the following additions:




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



RoutingInfo: Call routing information:

[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


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)


Figure 18 Report of VLR-initiated action


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.


4.12 .1 Successful InformationForward(TIA/EIA-41-D Chapter 3, page 3-57)




A-4DMisanoEnmens(19


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


TR45.2.3/99.07-15#10; [Ericsson]

Provide an indicator for IntersystemPage and IntersystemPage2 to identify system supportof the MIN, IMSI or both parameters.

4. 14 .1 Successful InterSystemPage: Border MSC Routing

Information Returned (TIA/EIA-41-D Chapter 3, page 3-60)


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.


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





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


TR45.2.3/99.07-157#10; [Ericsson]

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)


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.


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


4. 20 .2 Successful QualificationDirective: Re-authorization andUpdate Profile





A-4DMisanoEnmens(19


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


4. 21 .2 Successful QualificationRequest: AuthorizationConfirmed and Profile Returned



4. 26 .1 Successful RegistrationNotification: Confirmed at theVLR






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


TR45.2.2/99.10.13#22; [Lucent Technologies]

IS-725-A OTAPA enhancements supporting interactive mode OTAPA sessions; InterMessageTime (IMTIME).

4.32.C2 Exchange of OTASP Data Messages

(change to TIA/EIA/IS-725-A, Chapter 3, page 3-30)


a. The OTAF sends an SMDPP to the Serving MSC.


MIN MSID Activation_MIN used temporarily duringOTASP, or, for OTAPA, 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.

R

ESN MS's ESN. R

SRVIND Indicates CDMA OTASP service or OTAPA

service, as appropriate.

R

SMS_BearerData Contains an OTASP Data Message. R

SMS_TID This parameter is empty. It is included tocomply with TIA/EIA-41 backwardcompatibility rules.

MBC

ACTCODE Included for OTAPA when an OTAPA Request

message is encapsulated in the

SMS_BearerData

O

IMTIME Indicates the desired guard timing (different

from the system default) for this OTAPA

session. May be included for OTAPA

when ACTCODE indicates Allocate

Resources.

O




A-4DMisanoEnmens(19


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


TR45.2.2/99.08.16#12; [GTE]

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).

4.32.C3 OTAF Request to Initiate MSC Procedures

(change to TIA/EIA/IS-725-A, Chapter 3, page 3-31)This operation scenario describes the use of SMSDeliveryPointToPoint toinitiate MSC procedures.

smdpp [ ]

a

b

OTAF

SMDPP [MSID, ESN, ACTCODE, NEWMIN, NEWMINEXT,

NEWIMSI, SRVIND, SMS_BearerData, SMS_TID]

MSC

Serving SystemDesired

SMT cx

Figure 4.32.C3 OTAF Request to Initiate MSC Procedures

Note: In the above figure, SMTcx = (x=s, m: depending on the ACTCODE value).

See Section 7 for operation timer values in Table 63.




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


a. The OTAF sends an SMDPP to the Serving MSC.


MSID Activation_MIN used temporarily duringOTASP, or, for OTAPA, the MS'sMSID at the start of the OTAPA session.

When the MS has both the MIN & theIMSI at the start of the OTAPA sessionthen the MIN form of the MSID is used.

R

ESN MS’s ESN. R

ACTCODE Instructs the Serving MSC as to whichprocedures it should initiate.

R

NEWMIN The new MIN (or new IMSI_M_S)

assigned to the MS during this OTASPattempt or OTAPA session (e.g. providedto permit the MS to be registered withthe responsible HLR and to permit the

MS to be paged).

O

NEWMINEXT The new IMSI_M_CLASS,

IMSI_M_ADDR_NUM, MCC_M, and

IMSI_M_11_12 portions of a new

IMSI_M assigned to the MS during this

OTASP attempt or OTAPA session (e.g.

provided to permit the MS to be

registered with the responsible HLR).

O

NEWIMSI The new IMSI assigned to the MS duringthis OTASP attempt or OTAPA session(e.g. provided to permit the MS to be

registered with the responsible HLR).

O

SRVIND Indicates CDMA OTASP service orOTAPA service, as appropriate.

R

SMS_BearerData This parameter is empty. It is included tocomply with TIA/EIA-41 backwardcompatibility rules.

MBC

SMS_TID This parameter is empty. It is included tocomply with TIA/EIA-41 backwardcompatibility rules.

MBC

b. The Serving MSC initiates the desired procedures (e.g. RegistrationNotificationto the HLR pointed to by the NEWMIN or NEWIMSI) and sends an empty

smdpp to the OTAF.

For unsuccessful cases the Serving MSC may return the AUTHDEN parameteror the SMS_CauseCode parameter, or both parameters.



A-4DMisanoEnmens(19


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


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.


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)


a

b

d

e

HLR VLROTAF MSC

SMSREQ [MSID, ESN, SMSNOTIND, SMS_TID]

c

Destination

Home SystemDestination

Serving System

SRT

f



smsreq [MIN, ESN, SMSADDR]

SRT SRT



Figure 4.34.T1 Successful SMSRequest during OTASP: MS-Based SME


d. The Serving MSC returns an smsreq to the VLR indicating the currentnetwork address that can be associated with the indicated MS-based SME.


MSID MS's MSID. R

ESN MS's ESN. R




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


SMSADDR Temporary routing address that can be used todeliver OATS or OPTS messages to the MS.

R


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.


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)


a

b

d

e

HLR VLROTAF MSC


c

Destination

Home SystemDestination

Serving System

SRT

f




SRT SRT



Figure 8.TT.5 Serving MSC Attachment to the OTAF: Reprogramming




A-4DMisanoEnmens(19


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


TR45.2.3/99.06.17#4; [Ericsson]


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]



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’.




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


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.



A-4DMisanoEnmens(19


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


TR45.2.3/99.06.17#4; [Ericsson]


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.




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


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.


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.


5.4 .2 Origination with Authentication

(TIA/EIA/IS-778 Chapter 3, page 12)



Fi gur e 94 Originat ion with Authentication


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.




A-4DMisanoEnmens(19


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


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)


Figure 117a CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited


6.1. 5b CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited andServing MSC Identified Announcements



Figure 117b CD Invocation with No Answer or No PageResponse plus Transfer to HLR Inhibited andServing MSC Identified Announcements


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



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





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


6.1. 9 TLDN Call Arrival with Intersystem Paging

(TIA/EIA-41-D Chapter 3, page 3-228, line 3)


6.1 .13 a CD Invocation with improved Intersystem Paging toan Idle MS



Figure 6.1.13.a CD Invocation with improved Intersystem Pagingto an Idle MS


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.



A-4DMisanoEnmens(19


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


a

b

c

d

e

f

g

h

i

jLRT

MSC HLR VLR MSC

Serving SystemOriginating System

LOCREQ [DGTSDIAL]

MSINACT [MIN]

MSINACT [MIN]

msinact

msinact

locreq[TERMLIST, REDIND]

call origination

call setup

k

l

NP MS

Registration

Response [DN]

De-Registration [DN]

Response

MSINACT [MIN, DGTS]

MSIT

MSIT

MSINACT [MIN, DGTS]

Figure 6 .1 .13b CD to a Non-Public System

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.




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


k. The HLR sends a locreq to the Originating System with the DN received inStep-f. The DN is provided in the TERMLIST parameter.

l. The Originating MSC forwards the call to the MS using the DN received atStep-k.



A-4DMisanoEnmens(19


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




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.




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


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. Some time later the MS registers in the public system.

j. The Serving System responds to the registration.

k. The Serving MSC sends a REGNOT to the VLR.

l. The VLR sends aREGNOT to the HLR. The HLR clears the DN stored at Step-f.

m. The HLR sends a regnot to the VLR.n. The VLR sends a regnot to the Serving MSC.

6.8.x CNIP Invocation to a Forwarded-To Subscriber(new for TIA/EIA-41-D Chapter 3, page 3-265)


Figure 6.8.x CNIP Invocation to a Forwarded-To Subscriber


6. 13 .4 MWN via an MS Indication or Message Count or Both(TIA/EIA-41-D Chapter 3, page 3-310)


Figure 160 MWN via an MS Indication and/or MS Count




A-4DMisanoEnmens(19


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


6.13. X1 Message Waiting Update from a Voice MailSystem (proprietary interface)



Figure 6.13.X1 Message Waiting Update from a Voice Mail System(proprietary interface)


6.13.X2 Message Waiting Update from a Message Centeror Voice Mail System


Figure 6.13.X2 Message Waiting Update from a Message Centeror a Voice Mail System


6.13.X3 Message Waiting Update from a Voice Mail System


Figure 6.13.X3 Message Waiting Update from a Voice Mail System


6. 14 .6 MAH Invocation with a No Answer MAH Group Member(TIA/EIA-41-D Chapter 3, page 3-324)


Figure 167 MAH Invocation with a No Answer MAH GroupMember





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


TR45.2.3/99.06.17#16; [Lucent Technologies];

Provide clarifications and corrections for the Preferred Language - Variable Option.

Portions are a change to Miscellaneous 10

TR45.2.2/98.10.20#11; [Lucent Technologies]; Stage 2.

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)


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.



A-4DMisanoEnmens(19


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


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



Figure x+0 Short Message from MS-Based SME in AnchorSystem and Acknowledged after Handoff


7.x+1 Short Message from MS-Based SME in AnchorSystem and Acknowledged After Handoff (via aTandem System)






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


Figure x+1 Short Message from MS-Based SME in AnchorSystem and Acknowledged After Handoff (via aTandem System)


7.x+2 Short Message from MS-Based SME in TandemSystem and Acknowledged After Handoff (viaTandem System)



Figure x+2 Short Message from MS-Based SME in TandemSystem and Acknowledged After Handoff (viaTandem System)


7.x+3 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff Back



Figure x+3 Short Message from MS-Based SME in Serving

System and Acknowledged After Handoff Back


7.x+4 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff Back (viaa Tandem System)



Figure x+4 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff Back(via a Tandem System)




A-4DMisanoEnmens(19


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


7.x+5 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff To Thirdto a New Serving System



Figure x+5 Short Message from MS-Based SME in ServingSystem and Acknowledged After Handoff To Thirdto a New Serving System


7. 20 a Postponed MSC SMSNotification with Multiple

SMDPPs(new for TIA /EIA-41-D Chapter 3, page 3-406)


Figure 216a Postponed MSC SMSNotification with Mult ipleSMDPPs


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.




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


TR45.2.2/99.08.16#12; [GTE]


8. CC. 9 Registration Following Successful OTA

(change to TIA/EIA/IS-725-A, Chapter 3, page 3-69)This scenario describes registration following a successful OTASP or OTAPA

session when a new MSID is assigned.1

The new MSID is transferred to the Serving MSC in an SMDPP operation with theACTCODE instructing the Serving MSC to register the MS. In addition, the

Serving MSC is instructed to perform the MSINACT operation with the old MSID 2

and to delete old MSID from its database.

1 However, this is not invoked when the subscription is not changed i.e., an IMSI isprogrammed into an MS which originally had MIN (or IMSI_M) only.

2 If a successful registration had occurred with the old MSID.



A-4DMisanoEnmens(19


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


Home System Old System

OTAFVLR HLR HLR

SMDPP [ACTCODE, NEWMIN, NEWMINEXT, SRVIND, NEWIMSI]

f

g

h

i

MSINACT [DEREG]

MSIT

MSINACT [DEREG]

msinact [ ]

MSIT msinact [ ]

a

jsmdpp [ ]

MSC

Serving System

b

d

e

c

regnot [ ]

REGNOT

RNT

regnot [ ]

RNT

cmSMT

REGNOT

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.




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


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.



A-4DMisanoEnmens(19


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


TR45.2.2/99.08.16#12; [GTE]


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

do is vendor definable.

OTAF

SMDPP [ACTCODE, NEWMIN, NEWMINEXT, SRVIND, NEWIMSI]a

MSC

Serving System

b

SMT cssmdpp [ ]

Figure 8.CC.10 Notification of Newly Assigned MIN (or IMSI_M) or IMSI

or Both Following Successful OTA

a. After a successful OTASP or OTAPA session in which a new MIN (or

IMSI_M) or IMSI or both was assigned to the MS, the OTAF/CSC may

determine that the Serving System should be notified of the newly assignedMSIDs.

The OTAF sends to the Serving MSC an SMDPP containing the NEWMIN

(supplemented by NEWMINEXT if a new IMSI_M was assigned) and/or

NEWIMSI and the ACTCODE set to Record New MSID.

b. The Serving MSC sends an smdpp to the OTAF indicating that the actionspecified in ACTCODE was initiated.




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




9.CC.2 OTA Parameter Administration - MS is Available

(change to TIA/EIA/IS-725-A, Chapter 3, page 3-76)


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..


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.

MBC

SRVIND Indicates CDMA OTAPA. RACTCODE Allocate Resources (for multiple message

traffic channel delivery).R

IMTIME Indicates the desired guard timing (different

from the system default) for this

OTAPA session. May be included for

OTAPA when ACTCODE indicates

Allocate Resources

O




A-4DMisanoEnmens(19


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

Protocol Encoding Enhancements 50 TIA/EIA41.5-D (Stage 3)


Signaling Protocol Enhancements

5 .1 SS7-BASED DATA TRANSFER SERVICES



5 . 1 . 1 Message Transfer Part



Table 1 (continued)

TIA/EIA-41 Operation MTP Message Priority

• • • • • •

InformationForward 0

InterSystemAnswer 1 0

InterSystemPage 0

• • • • • •

LocationRequest 0

MessageDirective 0

MobileOnChannel 1

• • • • • •

RegistrationNotification 0

Release 0

RemoteUserInteractionDirective 0

• • • • • •

SMSDeliveryPointToPoint 0

SMSDeliveryPointToPointAck 0

SMSNotification 0

• • • • • •




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.5.D (Stage 3) 51 Protocol Encoding Enhancements

TR45.2.3/99.07.12#21; [Nortel Networks]

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/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.


• 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:




A-4DMisanoEnmens(19


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


TR45.2.3/99.11.10#18; [AT&T Wireless]

Resolve Error Code collision between IS-751 (Unrecognized IMSI and IS-735 (Unrecognized TIMSI). This is a modification to IS-751 and IS-735.

6 .3 .2 .3 .1 . Error Definitions



MissingParameter

a. Expected optional parameter is missing.

b. All profile parameters are expected, but some are missing.

c. All qualification parameters are expected, but some are missing.

MissingParameter errors should include exactly one FaultyParameterparameter in the parameter set (see 6.5.2.66).

Note that this Error Code is not used to indicate a missing mandatory

parameter, a REJECT message with a Problem Specifier of Incorrect Parameter is used in this case.

UnrecognizedIMSI/TMSI

a. Supplied IMSI is not currently served by the VLR.

b. Supplied IMSI is not currently served by the HLR.

c. Supplied IMSI is not currently served by the Serving MSC.

d. Supplied IMSI does not currently have an active call on an Originating

MSC.

e. Supplied TMSI is not currently served by the Old-Serving VLR. TMSIZONE may be matched, but TMSI CODE is not matched.

f. Supplied TMSI is not currently served by the Serving VLR. TMSI

ZONE may be matched, but TMSI CODE is not matched.

TMSI/VLRMismatch

a. Supplied TMSI is not resident on the Old-Serving VLR.

b. Supplied TMSI is not resident on the Serving VLR.

For TIA/EIA-41 the Error Code Identifier is coded as Private TCAP. Error Codes arecoded as follows:

Table 6 Error Codes




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


Error Code Name Error Code

H G F E D C B A

UnrecognizedMIN 1 0 0 0 0 0 0 1

UnrecognizedESN 1 0 0 0 0 0 1 0

MIN/HLRMismatch 1 0 0 0 0 0 1 1

OperationSequenceProblem 1 0 0 0 0 1 0 0

ResourceShortage 1 0 0 0 0 1 0 1

OperationNotSupported 1 0 0 0 0 1 1 0

TrunkUnavailable 1 0 0 0 0 1 1 1

ParameterError 1 0 0 0 1 0 0 0

SystemFailure 1 0 0 0 1 0 0 1

UnrecognizedParameterValue 1 0 0 0 1 0 1 0

FeatureInactive 1 0 0 0 1 0 1 1

MissingParameter 1 0 0 0 1 1 0 0

UnrecognizedIMSI/TMSI

(IS-751 modification )

1 0 0 0 1 1 0 1

TMSI/VLRMismatch

(IS-735 modification )

1 0 0 0 1 1 1 0

Other Error Codes are Reserved Reserved (Note a)

1 1 1 0 0 0 0 0

Reserved fo r Pro toco lExtension

through

(Note b) 1 1 1 1 1 1 1 1

Notes:

a. Treat a reserved value the same as value 133 (decimal), ResourceShortage.

b. Error codes 224 to 255 (decimal) shall be reserved for protocol extension. If unknown, treat the same as value 133 (decimal), Resource Shortage .



A-4DMisanoEnmens(19


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


6. 4. 1. 2 Operation Specifiers


The following table lists the TIA/EIA-41 MAP Operation Specifiers.

Table 8 (concluded)

Operation Name Operation Specifier

H G F E D C B A Decimal

• • • • • • • • •

Release 0 1 0 0 1 1 0 1 77

SMSDeliveryPointToPointAck 0 1 0 0 1 1 1 0 78

MessageDirective 0 1 0 0 1 1 1 1 79

Other Values Reserved X X X X X X X X • • •

1 1 1 0 0 0 0 0 224

Reserved for Protocol Extension through • • •

1 1 1 1 1 1 1 1 255

6.4.2 Operation Definitions(TIA/EIA-41-D Chapter 5, page 5-27)

The following table summarizes the operations defined for the TIA/EIA-41 MAP:

Table 10 (concluded)

Operation Reference

• • • • • •

MessageDirective 6.4.2.X

SMSDeliveryPointToPointAck 6.4.2.W

Release 6.4.2.V

• • • • • •




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


TR45.2.2/99.08.17#1; [Ericsson]

This WIN remanded recommendation is an IS-771 internationalization change to “AnalizedInformation INVOKE”.

6.4.2.i AnalyzedInformation

(new for TIA/EIA-41.5-D Section 6.4.2)(TIA/EIA/IS-771, page 5-34)

Table i-1 AnalyzedInformation INVOKE Parameters

AnalyzedInformation INVOKE Parameters Timer: ANZT

Field Value Type Reference Notes

Identifier SET [NATIONAL 18] M 6.3.2.1

Length variable octets M 6.3.2.1

Contents

BillingID (Originating) M 6.5.2.16 a

• • • • • • • • • • • •

MobileDirectoryNumber O 6.5.2.80 i

MobileIdentificationNumber O 6.5.2.81 g

MSCIdentificationNumber O 6.5.2.83 j

MSID O 6.5.2.bv n

• • • • • • • • • • • •

TerminationAccessType O 6.5.2.155 l

Notes:


m. Refer to IS-764.

n. Include as the service key, if applicable



A-4DMisanoEnmens(19


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


TR45.2.3/99.06.17#4; [Ericsson]


6.4 .2. 1 AuthenticationDirective



Table 11 AuthenticationDirective INVOKE Parameters

AuthenticationDirective INVOKE Parameters Timer: ADT




Contents

• • • • • • • • • • • •

CallHistoryCount O 6.5.2.18 c

CarrierDigits O 6.5.2.28 j

DenyAccess O 6.5.2.54 d

DestinationDigits O 6.5.2.56 j

LocationAreaID O 6.5.2.77 e

RandomVariableSSD O 6.5.2.103 f

RandomVariableUniqueChallenge O 6.5.2.104 b

RoutingDigits O 6.5.2.114 j

SenderIdentificationNumber O 6.5.2.116 g

• • • • • • • • • • • •

Notes:


i. Include if the MSC-V shall initiate a COUNT Update to the MS.

j. Include if authentication failed and the AC/HLR determines the call should

be redirected. These parameters may be included if the DenyAccess





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


TR45.2.3/99.09.13#17; [AT&T Wireless]

Provide the MS TerminalType prameter when known in AuthenticatiopnFailureReport INVOKE operations.

TR45.2.3/99.06.17#4; [Ericsson]


6.4 .2. 3 AuthenticationFailureReport(TIA/EIA-41-D Chapter 5, page 5-32)


Table 15 AuthenticationFailureReport INVOKE Parameters

Authent icat io nFa ilureRep or t INVOKE Paramete rs Timer: AFRT




Contents

ElectronicSerialNumber M 6.5.2.63

• • • • • • • • • • • •

SenderIdentificationNumber O 6.5.2.116 d

TerminalType O 6.5.2.154 e

Notes:


d. Include to identify message sender the functional entity sending the message.

e. Include the value received from the MS if available.



A-4DMisanoEnmens(19


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



Table 16 Authent icat ionFailureReport RETURN RESULTParameters

AuthenticationFailureReport RETURN RESULT

ParametersField Value Type Reference Notes



Contents

• • • • • • • • • • • •


CarrierDigits O 6.5.2.28 i


DestinationDigits O 6.5.2.56 i

RandomVariableSSD O 6.5.2.103 eRandomVariableUniqueChallenge O 6.5.2.104 b

RoutingDigits O 6.5.2.114 i

SSDNotShared O 6.5.2.141 f

TerminalType O 6.5.2.154 g

UpdateCount O 6.5.2.163 h

Notes:


g. Include the value provisioned for this subscription on IS-41-C or later.

Should be included for IS-41-C or later.

h. Include if the MSC-V shall initiate a COUNT Update to the MS.

i. Include if authentication failed and the AC/HLR determines the call should






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


TR45.2.3/99.06.17#4; [Ericsson]


6.4 .2. 4 AuthenticationRequest



Table 18 AuthenticationRequest RETURN RESULT Parameters

AuthenticationRequest RETURN RESULT Parameters




Contents

• • • • • • • • • • • •


CarrierDigits O 6.5.2.28 j

CDMAPrivateLongCodeMask O 6.5.2.36 d

DenyAccess O 6.5.2.54 e

DestinationDigits O 6.5.2.56 j

RandomVariableSSD O 6.5.2.103 f


RoutingDigits O 6.5.2.114 j

SharedSecretData O 6.5.2.119 c

• • • • • • • • • • • •

Notes:


i. Include if the MSC-V should initiate COUNT Update to the MS.

j. Include if authentication failed and the AC/HLR determines the call should





A-4DMisanoEnmens(19


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


TR45.2.3/99.06.17#4; [Ericsson]


6.4 .2. 5 AuthenticationStatusReport



Table 20 AuthenticationStatusReport RETURN RESULT Parameters

AuthenticationStatusReport RETURN RESULTParameters




Contents

• • • • • • • • • • • •CallHistoryCount O 6.5.2.18 c

CarrierDigits O 6.5.2.28 h


DestinationDigits O 6.5.2.56 h

RandomVariableSSD O 6.5.2.103 e


RoutingDigits O 6.5.2.114 h

SharedSecretData O 6.5.2.119 c

• • • • • • • • • • • •

Notes:


g. Include if the MSC-V shall initiate a COUNT Update to the MS.

h. Include if authentication failed and the AC/HLR determines the call should






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


6 . 4. 2 .1 0 FacilitiesDirective



Table 29 Facil it iesDirective INVOKE Parameters



Enhancement to IS-730 UserZoneData parameter and ANSI-41.5-D FacilitiesDirective2 operation to support CDMA Tiered Services.

TR45.2.3/98.02.03.03; [ERICSSON]; Stage 3.

TDMACallMode parameter text enhancements to identify mobile stations utilizing TDMA full rate VSELP and ACELP (IS-641) digital voice coders.

TR45.2.3/97.09.10.___; [NORTEL]

Enhancement to facilitate special alerting treatment for MSs in unanswered calls following intersystem handoff.

TR45.2.2/97.11.11.05; [Ericsson & Lucent Technologies]

TDMA Voice Coder Correction.

TR45.2.xx/97.xx.xx#xx; [Lucent Technologies]

TDMA Handoff Enhancement.

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 .


Provide NP (Non-Public) mode operation Stage-3 pr.

6 . 4. 2 .1 1 FacilitiesDirective2

(TIA/EIA-41-D Chapter 5, page 5-44)(Miscellaneous 10 Chapter 5, page 50)

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:



A-4DMisanoEnmens(19


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


Table 31 Facil it iesDirective2 INVOKE Parameters

FacilitiesDirective2 INVOKE Parameters Timer: HOT




Contents

BillingID (Anchor MSC) M 6.5.2.16 r


• • • • • • • • • • • •

TargetCellID O 6.5.2.148 b

AlertCode O 6.5.2.3 s

CDMACallMode O 6.5.2.29 c, d, e

• • • • • • • • • • • •

NAMPSChannelData (Serving) O 6.5.2.86 n

NonPublicData O 6.5.2.ad t

SignalingMessageEncryptionKey O 6.5.2.120 j

• • • • • • • • • • • •

StationClassMark O 6.5.2.143 i, o

TargetCellID O 6.5.2.148 b

TDMABurstIndicator (Serving) O 6.5.2.151 o

TDMACallMode O 6.5.2.152 e, p

TDMAChannelData (Serving) O 6.5.2.153 o

TDMAVoiceCoder O 6.5.2.k u

UserZoneData O 6.5.2.am

(IS-730 )

v

VoicePrivacyMask O 6.5.2.166 q

Notes:

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.


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.




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


Note: the following “Note” change and the addition of the NonPublicData parameter is also a modification to IS-730.

t. Include to provide information regarding Non-Public Information Display

(e.g., User Zone updates) at the target system.

Note: the following “Note” change is also a modification to IS-730.

u. 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.


v. Include if the MS user is authorized for User Zone Service. Include to

permit the Target MSC to validate MS selection of User Zone.

TR45.2.2/99.08.17#1; [WIN remanded Motorola];

This is a change to IS-771 “FacilitySelectedAndAvailable RETURN RESULT”.

6.4 .2. m Facil itySelectedAndAvailable

(New for TIA/EIA-41.5-D Section 6.4.2)(TIA/EIA/IS-771, page 5-43)


Table m-2 FacilitySelectedAndAvailable RETURN RESULT Parameters


Notes:

a. Include if access is denied. If included, no other optional parameters shall beincluded (with the exception of the AnnouncementList parameter).

b. Include if action to be performed is not implied through presence of otherparameters.

Note: the remaining portion of this section is retained unchanged.



A-4DMisanoEnmens(19


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




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)”.

6 . 4. 2. 13 FeatureRequest


(TIA/EIA/IS-764 Chapter 5, page-45)


Table 36 FeatureRequest RETURN RESULT Parameters

FeatureRequest RETURN RESULT Parameters




Contents

• • • • • • • • • • • •

Digits (Dialed) O 6.5.2.58 f

DisplayText O 6.5.2.bx l, m

DisplayText2 O 6.5.2.ec l, m

DMH_AccountCodeDigits O 6.5.2.59 g

• • • • • • • • • • • •

PilotNumber O 6.5.2.95 h

PreferredLanguageIndicator O 6.5.2.96 n, o

RedirectingNumberDigits O 6.5.2.107 d

• • • • • • • • • • • •




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


Notes:


d. Include if applicable.


f. Include if digits remain to be analyzed by the MSC.

g. Include if applicable and for recording purposes (see DMH ),


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



Table 41 HandoffBack2 INVOKE Parameters



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


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:



A-4DMisanoEnmens(19


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


Table 47 HandoffMeasurementRequest2 INVOKE Parameters

HandoffMeasurementRequest2 INVOKE Timer:LMMRT




Contents

ServingCellID M 6.5.2.117

• • • • • • • • • • • •

StationClassMark O 6.5.2.143 c, f

TargetCellIDList O 6.5.2.ak i

TDMACallMode O 6.5.2.152 g

TDMAChannelData (Serving) O 6.5.2.153 f

TDMATerminalCapability O 6.5.2.j h

Notes:


c. Include if an AMPS or NAMPS channel measurement is requested.


f. Include if a TDMA channel measurement is requested.

g. Include to indicate the current call mode, if other than AMPS (i.e., TDMA).

h. Include if the MS is IS-136 or later.

i. Include to indicate the list of cells and sectors on which measurements are

required. The inclusion of this parameter and the sending of theHAMDMREQ2 INVOKE is based on service related statistics gathered by the

Serving MSC regarding past handoff performance with border cells and

sectors in neighboring MSCs. See section 5.10, Successful

HandoffForward for MAHO with Measurement confirmation.





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


TR45.2.3/99.07-15#33; [NORTEL NETWORKS]

Support CDMA Tiered Services by adding the UserZoneData parameter (IS-730) into operations FacilitiesDirective2 and HandoffToThird2.

TR45.2.2/97.11.05; [Ericsson & Lucent Technologies]

TDMA Voice Coder Correction.

6 .4 .2 .2 0 HandoffToThird2


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



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:



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.



A-4DMisanoEnmens(19


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


TR45.2.3/99.05.20.10; [Ericsson]



6 . 4 . 2. 2 1 InformationDirective

(TIA/EIA-41-D Chapter 5, page 5-66



Table 51 InformationDirective INVOKE Parameters

InformationDirective INVOKE Parameters Timer: IDT




Contents


• • • • • • • • • • • •

CallingPartySubaddress O 6.5.2.25 c

DisplayText O 6.5.2.bx c, e

DisplayText2 O 6.5.2.ec c, e

RedirectingNumberString O 6.5.2.108 c

• • • • • • • • • • • •

Notes:

a. Include if the MS is to be alerted.

b. Include if one or more tones or announcements are to be applied to the MS.

c. Include if authorized and available.

d. Include to identify the functional entity sending the message.

e. Include only one of these mutually exclusive parameters.




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


TR45.2.3/99.05.20.10; [Ericsson]



6 . 4. 2 .2 2 InformationForward




Table 53 InformationForward INVOKE Parameters

InformationForward INVOKE Parameters Timer: IFT




Contents

InterMSCCircuitID M 6.5.2.72

• • • • • • • • • • • •

CallingPartySubaddress O 6.5.2.25 b

DisplayText O 6.5.2.bx c, d

DisplayText2 O 6.5.2.ec c, d

ElectronicSerialNumber O 6.5.2.63 a

• • • • • • • • • • • •

Notes:

a. Include if appropriate.

b. Include if the MS is authorized for CNIP.

c. Include if available.

d. Include only one of these mutually exclusive parameters.



A-4DMisanoEnmens(19


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


TR45.2.3/99.07-157#10; [Ericsson]

Provide an indicator for IntersystemPage and IntersystemPage2 to identify system support of the MIN, IMSI or both parameters.

TR45.2.3/99.05.20.10; [Ericsson]



TR45.2.III/98.07.08#6; [ERICSSON]

TR45.2.III/98.006.10#3 ; [ERICSSON]

TR45.2.III/98.04.21#14; [ERICSSON]

Support for improvements to intersystem paging.

6 .4 .2 .2 4 InterSystemPage(TIA/EIA-41-D Chapter 5, page 5-72)


(TIA/EIA-41-D Miscellaneous 10, page-53)





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


Table 57 InterSystemPage INVOKE Parameters

InterSystemPage INVOKE Parameters Timer: ISPRT




Contents

BillingID (Originating) M 6.5.2.16


MobileIdentificationNumber M 6.5.2.81

DMH_AccountCodeDigits O 6.5.2.59 a

• • • • • • • • • • • •

CDMAStationClassMark O 6.5.2.41 c

DisplayText O 6.5.2.bx a, o

DisplayText2 O 6.5.2.ec a, o

DMH_AccountCodeDigits O 6.5.2.59 a• • • • • • • • • • • •

ExtendedSystemMyTypeCode (Serving MSC) O 6.5.2.65 e

IMSI O 6.5.2.bu p

LegInformation O 6.5.2.75 f

• • • • • • • • • • • •

MobileDirectoryNumber O 6.5.2.80 a

MobileIdentificationNumber O 6.5.2.81 p

MSCID (Originating MSC) O 6.5.2.82 g

MSCIdentificationNumber O 6.5.2.83 f

MSIDUsage O 6.5.2.fe q

OneTimeFeatureIndicator O 6.5.2.88 f

PageCount O 6.5.2.ed n

PageIndicator O 6.5.2.92 h

PageResponseTime O 6.5.2.ee n

PC_SSN (Originating MSC) O 6.5.2.93 i

• • • • • • • • • • • •

TerminationTriggers O 6.5.2.159 a

Notes:

a. Include if available (i.e., provided in the associated RoutingRequestINVOKE).


c. Include if a CDMA channel is in use.


f. Include if known.



A-4DMisanoEnmens(19


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



h. Include if request is to listen only. May include if request is to page.

i. Include if available for subsequent call redirection.


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.


TR45.2.3/99.07-15#10; [Ericsson]


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]



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







A-4DMisanoEnmens(19


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



f. Include if request is to listen only. May include if request is to page.

g. Include to indicate the recommended number of sequential paging attempts

that the receiving system is expected to do.

h. Include to indicate the maximum time that the receiving system has torespond to this message.

i. Include only one of these mutually exclusive parameters.

j. Include if available. At least one parameter should be present.

k. For TDMA, identifies the MSID last used to calculate the control channel

and paging slot.

l. Include to provide information regarding Non-Public Information Display

(e.g., User Zone updates) in the border system.

m. For TDMA, include to indicate the list of accepted PSIDs/RSIDs for the

indicated MS.

n. The PSID_RSIDList and UserZoneData parameters are mutually exclusive.

o. Include to perform User Zone updates at the Border System.


6 .4 .2 .2 6 InterSystemSetup



Table 61 InterSystemSetup INVOKE Parameters





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


TR45.2.3/99.05.20.10; [Ericsson]



6 .4 .2 .2 7 LocationRequest




Table 64 LocationRequest RETURN RESULT Parameters

LocationRequest RETURN RESULT Parameters




Contents

ElectronicSerialNumber M 6.5.2.63 a

• • • • • • • • • • • •

Digits (Destination) O 6.5.2.58 g, h

DisplayText O 6.5.2.bx e, p

DisplayText2 O 6.5.2.ec e, p

DMH_AccountCodeDigits O 6.5.2.59 i

• • • • • • • • • • • •

RedirectingNumberDigits O 6.5.2.107 j

RedirectingNumberString O 6.5.2.108 e, fRedirectingSubaddress O 6.5.2.109 e, j

• • • • • • • • • • • •



A-4DMisanoEnmens(19


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


Notes:

a. Value is all zeroes, if unknown.


e. Include for local termination (e.g., the LocalTermination parameter is

included within the TerminationList parameter) if a related feature is active.

e. Include if feature is active and if a LocalTermination parameter is included withinthe TerminationList parameter.

f. Include if applicable.

g. Include if call is to be routed over a network.

h. Use only with system not capable of using the TerminationList parameter.

i. Include if available for recording purposes (see DMH).

j. Include if available and call redirection may apply.

k Include for multileg calls.


p. Include only one of these mutually exclusive parameters.

6 .4 .2 . X MessageDirective



Table 6.4.2.X FE Combinations for MSGDIR


Table 6.4.2.X1 MessageDirect ive INVOKE Parameters


Table 6.4.2.X2 MessageDirective RETURN RESULT Parameters





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




6 . 4 . 2 . 2 9 MSInactive



Table 66 MSInactive INVOKE Parameters

MSInactive INVOKE Parameters Timer: MSIT




Contents


MobileIdentificationNumber M 6.5.2.81CallHistoryCount O 6.5.2.18 a

DeregistrationType O 6.5.2.55 b

DestinationDigits O 6.5.2.56 f

LocationAreaID O 6.5.2.77 c

SenderIdentificationNumber O 6.5.2.116 d

SMS_MessageWaitingIndicator O 6.5.2.129 e

Notes:

a. Include if MS registration is canceled and if the SSD is shared.

b. Include from VLR to HLR and HLR to AC for MS De-registration.

c. May be included from MSC-V to VLR. Usage in the HLR is not defined.

d. Include to identify the functional entity sending this message.

e. Include to indicate that an SMS message is pending delivery.

f. Include when received from MS in De-registration.




A-4DMisanoEnmens(19


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




TR45.2.3/99.05.20.10; [Ericsson]



6 .4 .2 .3 0 OriginationRequest




Table 69 OriginationRequest RETURN RESULT Parameters

OriginationRequest RETURN RESULT Parameters




Contents

• • • • • • • • • • • •

Digits (Dialed) O 6.5.2.58 h

DisplayText O 6.5.2.bx d, e, p

DisplayText2 O 6.5.2.ec d, e, p

DMH_AccountCodeDigits O 6.5.2.59 i

• • • • • • • • • • • •

PilotNumber O 6.5.2.95 k

PreferredLanguageIndicator O 6.5.2.96 q, r

RedirectingNumberDigits O 6.5.2.107 f

• • • • • • • • • • • •




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


Notes:

a. Include if access is denied. If included, no other optional parameters shall beincluded (with the exception of the AnnouncementList parameter).


d. Include if a LocalTermination parameter is included in the TerminationListparameter.

e. Include if the related feature is active.


h. Include if digits remain to be translated by the MSC.

i. Include if available for recording purposes (see DMH ).


p. Include only one of these mutually exclusive parameters.

q. Include to identify the Preferred Language.

r. This parameter may only be included if the AnnouncementList parameter is

present.

6 .4 .2 .3 5 RedirectionRequest



Table 78 RedirectionRequest INVOKE Parameters


Table 79 RedirectionRequest RETURN RESULT Parameters




A-4DMisanoEnmens(19


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


6 . 4. 2 .V Release



Table 6 .4.2.V Release INVOKE Parameters


Table 6.4.2.V1 Release RETURN RESULT Parameters


TR45.2.3/99.05.20.10; [Ericsson]



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








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


Table 88 RoutingRequest INVOKE Parameters

RoutingRequest INVOKE Parameters Timer: RRT




Contents

BillingID (Originating) M 6.5.2.16 a

• • • • • • • • • • • •

DestinationDigits O 6.5.2.56 d, e

DisplayText O 6.5.2.bx c, s

DisplayText2 O 6.5.2.ec c, s

DMH_AccountCodeDigits O 6.5.2.59 f

• • • • • • • • • • • •

TerminationTriggers O 6.5.2.159 f

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.


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.


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.




A-4DMisanoEnmens(19


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


TR45.2.2/99.08.17#1; [Ericsson]

This WIN remanded recommendation is an IS-764 and IS-771 internationalization change to “ServiceRequest INVOKE”.

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.


6 . 4 . 2 . h S er vi ce Re qu es t

(new for TIA/EIA-41.5-D , page 5-101)(TIA/EIA/IS-764 Chapter 5, page 69)

(TIA/EIA/IS-771 Chapter 5, page 5-29)

Table 6.4.2.h-1 ServiceRequest INVOKE Parameters

ServiceRequest INVOKE Parameters Timer: SVRT




Contents

ServiceID M 6.5.2.bz

• • • • • • • • • • • •

MobileDirectoryNumber O 6.5.2.80 c, g

MobileIdentificationNumber O 6.5.2.81 c

MSCID (Invoking) O 6.5.2.82 c, h

MSCIN (Invoking) O 6.5.2.83 c, i

MSID O 6.5.2.bv p

PC_SSN O 6.5.2.93 i, j

• • • • • • • • • • • •

WINCapability O 6.5.2.di o

Notes:


f. Include to correlate service usage with call instance.

g. Include if available for recording purposes (see DMH ).

Include if MIN is available and is not the same as Digits (Dialed).

h. Include to identify invoking MSC.


o. Include to indicate the WIN capabilities supported.

p. Include as the service key, if applicable.




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


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




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



Table 91 SMSDeliveryBackward RETURN RESULT Parameters




A-4DMisanoEnmens(19


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




TR45.2.2/99.08.16#12; [GTE]


R45.2.3/99.03.18.11; [Motorola].

Provide SMDPP INVOKE parameters Note “a” text enhancement to support MS-to-MC operations (as well as the existing MC-to-MS description).

6 . 4. 2 .4 3 SMSDeliveryPointToPoint



Table 94 SMSDeliveryPointToPoint INVOKE Parameters

SMSDeliveryPointToPoint INVOKE Parameters Timer: SMT




Contents

SMS_BearerData M 6.5.2.124

SMS_TeleserviceIdentifier M 6.5.2.137

ActionCode O 6.5.2.2 i

ElectronicSerialNumber O 6.5.2.63 a

InterMessageTime O 6.5.2.fd o

MSID O 6.5.2.bv a, m

MobileIdentificationNumber 6.5.2.81

NewlyAssignedMIN O 6.5.2.rB j

NewlyAssignedIMSI O 6.5.2.dqB j

NewMINExtension O 6.5.2.ff n

ServiceIndicator O 6.5.2.wB k

SMS_ChargeIndicator O 6.5.2.126 b

SMS_DestinationAddress O 6.5.2.127 c

SMS_MessageCount O 6.5.2.128 d

SMS_NotificationIndicator O 6.5.2.130 e

SMS_OriginalDestinationAddress O 6.5.2.131 f

SMS_OriginalDestinationSubaddress O 6.5.2.132 g

SMS_OriginalOriginatingAddress O 6.5.2.133 h

SMS_OriginalOriginatingSubaddress O 6.5.2.134 g

SMS_OriginatingAddress O 6.5.2.135 c

TemporaryReferenceNumber O 6.5.2.yC l




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


Notes:

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.



A-4DMisanoEnmens(19


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


n. Include for CDMA OTASP or CDMA OTAPA in requests to initiate MSC

procedures3 if a new IMSI_M has been assigned for the MS during the

current OTASP or OTAPA session.

o. Include if applicable for CDMA OTAPA when the ActionCode value is

Allocate Resource and inter-message timing should be different from the

system default.


6.4 .2. W SMSDeliveryPointToPointAck



Table 6.4.2.W SMSDeliveryPointToPointAck INVOKE Parameters


6 .4 .2 .4 4 SMSNotification



Table 97 SMSNotification RETURN RESULT Parameters


3The 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.




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


TR45.2/99.08.16#13; [WNP PH3 editor].

Add parameter MSID to operation SMSREQ RETURN RESULT.; this is an enhancement to TIA/EIA/IS-751

6 . 4. 2 .4 5 SM SReque st



6 . 4. 2 .4 5 SM SReque st

(TIA/EIA-41-D Chapter 5, page 5-109)(TIA/EIA IS-725-A (CDMA), page 5-105)(TIA/EIA IS-725-A (TDMA), page 5-326)

(TIA/EIA-41-D Miscellaneous 10.8, page 84)

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




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.



A-4DMisanoEnmens(19


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



TR45.2.2/99.08.17#1; [Ericsson]

This WIN remanded recommendation is an IS-771 internationalization change to “TBusy INVOKE”.

6 . 4 . 2 . t TBusy



Table t-1 TBusy INVOKE Parameters

TBusy INVOKE Parameters Timer: TBT




Contents

BillingID (Invoking) M 6.5.2.16 a

• • • • • • • • • • • •

MobileDirectoryNumber O 6.5.2.80 h, i

MobileIdentificationNumber O 6.5.2.81 h

MSCIdentificationNumber O 6.5.2.83 b

MSID O 6.5.2.bv h

OneTimeFeatureIndicator O 6.5.2.88 j

• • • • • • • • • • • •

TerminationAccessType O 6.5.2.155 f

Notes:


h. Include as a service key, if applicable.

One must be present for use as a service key.


j. Include if any OneTimeFeatureIndicator status bits are set (i.e., have valueof 1).





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


TR45.2.2/99.08.17#1; [Ericsson]

This WIN remanded recommendation is an IS-771 internationalization change to “TNoAnswerINVOKE”.

6 . 4. 2 . u TNoAnswer



Table u-1 TNoAnswer INVOKE Parameters

TNoAnswer INVOKE Parameters Timer: TNAT




Contents

BillingID (Invoking) M 6.5.2.16 a

• • • • • • • • • • • •

MobileDirectoryNumber O 6.5.2.80 h, i

MobileIdentificationNumber O 6.5.2.81 h

MSCIdentificationNumber O 6.5.2.83 b

MSID O 6.5.2.bv h

OneTimeFeatureIndicator O 6.5.2.88 j

• • • • • • • • • • • •

TerminationAccessType O 6.5.2.155 f

Notes:


h. Include as a service key, if applicable.

One must be present for use as a service key.


j. Include if any OneTimeFeatureIndicator status bits are set (i.e., have valueof 1).




A-4DMisanoEnmens(19


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


TR45.2.3/99.05.20.10; [Ericsson]



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





Table 100 TransferToNumberRequest INVOKE Parameters


Table 101 TransferToNumberRequest RETURN RESULT Parameters

TransferToNumberRequest RETURN RESULTParameters




Contents

Digits (Destination) M 6.5.2.58 a• • • • • • • • • • • •

Digits (Carrier) O 6.5.2.58 g

DisplayText O 6.5.2.bx e, k

DisplayText2 O 6.5.2.ec e, k

DMH_AccountCodeDigits O 6.5.2.59 h

• • • • • • • • • • • •




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


Notes:

a. This parameter is ignored if the TerminationList parameter is provided.


e. Include if related feature is active and if a LocalTermination parameter is

included within the TerminationList parameter.


g. Include if applicable.

h. Include if available for recording purposes (see DMH ).


k. Include only one of these mutually exclusive parameters.

TR45.2.3/99.05.20.10; [Ericsson]



6 .4 .2 .5 1 UnsolicitedResponse

(TIA/EIA-41.5-D, page 5-117)(TIA/EIA/IS-764 Chapter 5, page-64)


Table 111 UnsolicitedResponse RETURN RESULT Parameters

UnsolicitedResponse RETURN RESULT Parameters




Contents

AlertCode O 6.5.2.3 a

• • • • • • • • • • • •

CallingPartySubaddress O 6.5.2.25 c

DisplayText O 6.5.2.bx g, i

DisplayText2 O 6.5.2.ec g, i

DMH_AccountCodeDigits O 6.5.2.59 d

• • • • • • • • • • • •



A-4DMisanoEnmens(19


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


Notes:

a. Include to specify special alerting treatment.


c. Include if related feature is active.

d. Include if available.


g. Include if available (e.g., provided in the associated RoutingRequestINVOKE).


i. Include only one of these mutually exclusive parameters.




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



ANSI-41-E "Operation Identifiers" and "Parameter Identifier Code" assignments.



TR45.2.3/99.09-15#14; [DDI, Hitachi, KDD, OKI, Japan Telecom, Fujitsu, IDO, NEC, Motorola Japan, Lucent Technologies Japan]

Reserve 10-Parameter Identifier Codes for National Network use.

TR45.2.2/99.08.16#12; [GTE]


6. 5. 1. 2 Parameter Identifiers


The following table lists the IS-41 MAP Parameter Identifiers.

Table 112 IS-41 MAP Parameter Identifiers (continued)

Parameter Identifier Name Parameter Identifier CodeH G F E D C B A

Reference

• • • • • • • • •

CDMAState

(IS-737 modification)

1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 1 0 1 0 1 0 1

6.5.2.ar

(287)

• • • • • • • • •

CommandCode


1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 0 1 0 1 0 1 0

6.5.2.eb

[298)

• • • • • • • • •

DisplayText2 1 0 0 1 1 1 1 11 0 0 0 0 0 1 0

0 0 1 0 1 0 1 1

6.5.2.ec(299)

• • • • • • • • •

PageCount 1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 0 1 0 1 1 0 0

6.5.2.ed

(300)

• • • • • • • • •

PageResponseTime 1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 0 1 0 1 1 0 1

6.5.2.ee

(301)

• • • • • • • • •

SMS_TransactionID


1 0 0 1 1 1 1 11 0 0 0 0 0 1 0

0 0 1 0 1 1 1 0

6.5.2.ef

(302)

1 0 1 1 1 1 1 11 0 0 0 0 0 0 10 1 0 1 1 0 0 1

6.5.2.aj

• • • • • • • • •



A-4DMisanoEnmens(19


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


InterMessageTime 1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 1 0 0 0 1 1 0

6.5.2.fd

(3xx)


Parameter Identifier Name Parameter Identifier CodeH G F E D C B A

Reference

• • • • • • • • •

MSIDUsage 1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 1 0 0 0 1 1 1

6.5.2.fe

(3xx)

• • • • • • • • •

NewMINExtension 1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 1 0 0 1 0 0 0

6.5.2.ff

(3xx)

• • • • • • • • •

QOSPriority 1 0 0 1 1 1 1 1

1 0 0 0 0 0 1 0

0 1 x x x x x x

6.5.2.xx

(3xx)

• • • • • • • • •

1 0 X 1 1 1 1 1

1 1 1 1 1 1 1 0

0 1 1 1 0 1 1 0

See Note a.

Reserved for National Network

use.• • • See Note b for

value of X.

1 0 X 1 1 1 1 1

1 1 1 1 1 1 1 0

0 1 1 1 1 1 1 1

1 0 X 1 1 1 1 1

1 1 1 1 1 1 1 10 0 0 0 0 0 0 0

See Note b for

value of X.

Reserved for Protocol Extension • • •

1 0 X 1 1 1 1 1

1 1 1 1 1 1 1 10 1 1 1 1 1 1 1

1 0 0 1 1 1 1 11 1 1 1 1 1 1 10 0 0 0 0 0 0 0

Reserved for Protocol Extension • • •

1 0 0 1 1 1 1 11 1 1 1 1 1 1 10 1 1 1 1 1 1 1




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


Notes:

a. “National Network use” parameters may be independently used by each

nation. “National Network use” parameters may be used between nations by

bilateral agreement.

b. The Parameter Identifier Code first octet’s bit=“F” is variable (e.g., set=0 for

Primitive elements and set=1 for Constructor elements), see ANSI T1.114.



TR45.2.2/99.08.16#12; [GTE]


Table 6C .2 .3 b New Parameters Unique to CDMA(TIA/EIA/IS-725-A Chapter CDMA-OTA, page 121)

Parameter Name Reference

MobileStationMIN 6.5.2.oC

MSC_Address 6.5.2.dnC

TemporaryReferenceNumber 6.5.2.yC

MobileStationIMSI 6.5.2.dpC

MobileStationMSID 6.5.2.adC

NewMINExtinsion 6.5.2.tbaC

InterMessageTime 6.5.2.fd



A-4DMisanoEnmens(19


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


6.5.2 Parameter Definitions(TIA/EIA-41-D Chapter 5, page 5-128)

TR45.2.3/99.04.14.7; [KDD]

Add AnnouncementCode parameter value assignments for Credit Card Calling.

6 . 5 . 2 . 5 A nn ou nc em en tC od e

(TIA/EIA-41.5-D page 5-133)


Figure 12 AnnouncementCode parameter


Table 117 AnnouncementCode value

Tone (octet 1)

Bits H G F E D C B A Value Meaning


Class (octet 2, bits A-D)



Standard Announcement (octet 3)


0 0 0 0 0 0 0 0 0 None. No announcement is requested, just play the tone.


1 0 0 0 1 1 0 1 141 E n t e r F e a t u r e C o d e P r o m p t . (e.g.,“Please enter a feature code.”)[TIA/EIA-664]

1 0 0 0 1 1 1 0 142 EnterEnterCreditCardNumber

Prompt . (e.g., “Please enter your credit

card number.”) [TIA/EIA-664]

1 0 0 0 1 1 1 1 143 EnterDestinationNumberPrompt.

(e.g., “Please enter the destination

number.”) [TIA/EIA-664]

X X X X X X X X Other values are reserved. Treat the sameas value 0, None.




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



Enhancement supporting the transport of IS-95-B "Base Station Protocol Revision" parameter.


6 .5 .2 .3 0 CDMAChannelData

(TIA/EIA-41.5-D page 5-164)(TIA/EIA IS-735 page 123)

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.



A-4DMisanoEnmens(19


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


The minimum length of this parameter is 8 octets.


Identifier CDMAChannelDataIMPLICIT OCTET STRING

M 6.5.1.2


Contents

H G F E D C B A octet Notes

Res'd Frame Offset MSB 1

CDMA Channel Number LSB 2 a, b

Res'd Band Class MSB 3

• • •

Long Code Mask 7 a, b, c

LSB 8

NPEXT Nominal Power Number Preamble 9 aBase Station Protocol Revision 10 d

• • • n e

Figure 37 CDMAChannelData parameter

Notes:

a. See CDMA [ IS-95-A] for definitions of these Nominal Power and Number

Preamble fields. See CDMA [ J-STD-008] for the definition of NP_EXT

field.

b. Reserved (Res’d) bits shall be ignored on receipt and set to zero on sending.

c. The bit layout is the same as that of Band Class Value Assignments definedin CDMA [TSB58].

d. See CDMA [ IS-95-B P_REV] for definitions of this field.

e. Ignore extra octets, if received. Send only defined (or significant) octets.





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


6 . 5 . 2 . e b C om ma nd Co de

(new for TIA/EIA-41.5-D , page 5-176)


Figure 6.5.2.eb CommandCode parameter


Table 6. 5.2.eb CommandCode value


6. 5 .2 .5 3 DeniedAuthorizationPeriod

(TIA/EIA-41.5-D , page 5-182)


Table 136 DeniedAuthorizationPeriod value




A-4DMisanoEnmens(19


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


TR45.2/99.06.14#19; [Lucent Technologies]

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.


Identifier DisplayText2IMPLICIT OCTET STRING

M 6.5.1.2


Contents


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.




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



Identifier DisplayText2IMPLICIT OCTET STRING

M 6.5.1.2


Contents


Display Character Set 1

Display Type 2 a

Display Tag 3 a, b

Display Length 4 a, b

51st Displayed Character

6b, c

72nd Displayed Character

8b, c

• • • • • •

n -1n th Displayed Charactern

b, c

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.



A-4DMisanoEnmens(19


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


Table 6.5.2.ec DisplayText2 value

Table 6.5.2.bx2 DisplayCharacterSet value

Display Character Set (octet 1)


0 0 0 0 0 0 0 0 0 Not used.0 0 0 0 0 0 0 1 1 ASCII .0 0 0 0 0 0 1 0 2 ITU T.50. The International Reference

Alphabet as defined in ITU-R Rec. T.50.0 0 0 0 0 0 1 1 3 User Specific.0 0 0 0 0 1 0 0 4 ISO 8859-1. The 8-bit single-byte

coded character set “Latin 1” as defined inISO/IEC Standard 8859-1.

0 0 0 0 0 1 0 1 5 ISO 10646. The Universal Multiple-Octet Coded Character Set (USC) asdefined in ISO/IEC Standard 10646.Basic Multilingual Plane only.

0 0 0 0 0 1 1 0 6 ISO 8859-8. The 8-bit single-bytecoded character set “Hebrew” as defined inISO/IEC Standard 8859-8.

0 0 0 0 0 1 1 1 7 I S - 9 1 E x t e n d e d P r o t o c o lMessage . The length is determined by

the Message Type; see TIA/EIA/IS-90,

Section 3.7.1 and T I A / E I A / I S - 9 0

Appendix B.

0 0 0 0 1 0 0 0 8 Shi f t -JIS . Variable 1-2 byte non-

modal encoding for Kanji, Kana, and

Latin character sets defined in JIS X0201

and JIS X0206.

0 0 0 0 1 0 0 1 9 KC C 5601. Variable 1-2 byte Korean

encoding method.

0 0 0 0 1 0 1 0 10

• • • through

1 1 0 1 1 1 1 1 223

Reserved. Treat reserved values the sameas value 1, ASCII.

1 1 1 0 0 0 0 0 224

• • • through

1 1 1 1 1 1 1 1 255

Reserved. If unknown, treat the same asvalue 1, ASCII.




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


6 . 5 . 2. 6 2 DMH_RedirectionIndicator



Figure 70 DMH_RedirectionIndicator parameter


Table 140 DMH_RedirectionIndicator value






6.5 .2 . fd InterMessageTime

(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.


Identifier InterMessageTimeIMPLICIT OCTET STRING

M 6.5.1.2

Length 1 octet M 6.5.1.1

Contents


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.).



A-4DMisanoEnmens(19


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


6 . 5 . 2 . 7 8 Mes sageWa iting Notificati onCount



Table 147 MessageWaitingNotif icationCount valueSee TIA/EIA-41-D Miscellaneous Enhancements Revision 10.

6 . 5 . 2 . 7 9 Me ssageWai ting Notifi catio nType



Table 148 MessageWaitingNotificationType valueSee TIA/EIA-41-D Miscellaneous Enhancements Revision 10.

TR45.2.3/99.07-157#10; [Ericsson]


6 . 5 . 2 . f e M SI DU sa ge


The MSIDUsage (MSIDUSE) parameter identifies the MSID last used to calculatethe control channel and paging slot.


Identifier MSIDUsageIMPLICIT OCTET STRING

M 6.5.1.2


Contents


Reserved M or I 1 a

• • • n b

Figure 6 .5.2. fe MSIDUsage 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.




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


Table 6 .5.2.fe MSIDUsage value

M and I Report (octet 1, bits A and B)


0 0 0 Not used.0 1 1 MIN last used.

1 0 2 IMSI last used.1 1 3 Reserved.

TR45.2.2/99.08.16#12; [GTE]


6.5.2.ff NewMINExtension(TIA/EIA-41-D Chapter 5, page 5-126)

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.


Identifier NewlyAssignedMIN

IMPLICIT MINType

M 6.5.1.2

Length 3 octets M 6.5.1.1

Contents


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)



A-4DMisanoEnmens(19


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


Table xxc Digit value

Digit n, where n={1, 2, …, 5} (octets 1-3)

Bits H G F E

or D C B A Value Meaning

0 0 0 0 0 Digit = 0 or filler.

0 0 0 1 1 Digit = 1.0 0 1 0 2 Digit = 2.0 0 1 1 3 Digit = 3.0 1 0 0 4 Digit = 4.0 1 0 1 5 Digit = 5.0 1 1 0 6 Digit = 6.0 1 1 1 7 Digit = 7.1 0 0 0 8 Digit = 8.1 0 0 1 9 Digit = 9.X X X X - Other values reserved.

6 .5 .2 .ad NonPublicData(new for TIA/EIA-41-D Chapter 5, page 5-222)


Figure 6 .5 .2 .ad NonPubl icData parameter


Table 6.5.2.ad NonPublicData value


6 . 5 . 2. 8 9 OriginationIndicator



Figure 97 OriginationIndicator parameter





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


6 . 5 . 2 . e d PageCount



Figure 6 .5 .2 .ed PageCount parameter


6 .5 .2 .e e PageResponseTime



Figure 6.5.2.ee PageResponseTime parameter


6 . 5 . 2 . 9 6 PreferredLanguageIndicator



Table 104 PreferredLanguageIndicator value(TIA/EIA-41.5-D page 5-233)


Table 160 (continued)




A-4DMisanoEnmens(19


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



Profile changes to support non-assured packet data service radio-link QoS.

TR45.2.3/99.04.14.13; [NORTEL NETWORKS]

Permit the MWNCOUNT parameter to be omitted from the PROFILE if all message counts are zero.

TR45.2.3/98.09.16#11; [NORTEL] Provide editorial improvements to existing MWN text.

TR45.2.2/97.09.16#19; [Motorola]

Provide editorial improvements to existing MWN text.

6 . 5 . 2 . 9 7 Profile

(TIA/EIA-41.5-D page 5-234)(TIA/EIA-41-D Miscellaneous 10, page-82)

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




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


Notes:


f. Include if the MWI field of the MessageWaitingNotificationType parameter

has the value MWI On. Include to indicate the type and number of

messages waiting.Include if MessageWaitingNotificationType is Message Waiting Indicationand number of messages waiting is authorized.

g. Include if Message Waiting Notification feature is active and a message iswaiting.


t. Include if packet data services are applicable to indicate relative priority for

purposes of radio resource allocation.

6. 5.2 .af PSID_RSIDInformation (new)

(TIA/EIA/IS-730, page 118)


Figure IS-730-20 PSID_RSIDInformation parameter


Table IS-730-6 PSID/RSIDInformation va lue




A-4DMisanoEnmens(19


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



Profile changes to support non-assured packet data service radio-link QoS.

6.5 .2 .xx QOSPrior ity


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.


Identifier QOSPriorityIMPLICIT OCTET STRING

M 6.5.1.2


Contents


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.

Table 6 .5.2.xx QOSPriority value

Non-Assured Priority (octet 1, bits A-D)


0 0 0 0 0 Priority Level 0. This is the lowest level.0 0 0 1 1 Priority Level 1.0 0 1 0 2 Priority Level 2.0 0 1 1 3 Priority Level 3.0 1 0 0 4 Priority Level 4.0 1 0 1 5 Priority Level 5.0 1 1 0 6 Priority Level 6.0 1 1 1 7 Priority Level 7.1 0 0 0 8 Priority Level 8.1 0 0 1 9 Priority Level 9.1 0 1 0 10 Priority Level 10.1 0 1 1 11 Priority Level 11.1 1 0 0 12 Priority Level 12.1 1 0 1 13 Priority Level 13.

1 1 1 0 14 Reserved.1 1 1 1 15 Reserved.




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


6 .5 .2 .1 11 ReleaseReason

(TIA/EIA-41.5-D page 5-246, lines 25, 35 & 40)


Table 165 ReleaseReason valueSee TIA/EIA-41-D Miscellaneous Enhancements Revision 10.

6 .5 .2 .1 15 SeizureType

(TIA/EIA-41.5-D page 5-250, lines 24, 30 & 34)


Table 167 SeizureType value parameter


TR45.2/99.06.14#14; [Motorola]

Provide Numbering Plan variant text clarification (this was a remanded PN-4197 ballotresponse).

6 .5 .2 .1 23 SMS_Address



Figure 133 SMS_Address Encoding for an IP address

Notes:


d. Numbering Plan shall be IP Address for this parameter variant.


Figure 134 SMS_Address parameter for an ANSI SS7 Point CodeAddress

Notes:


d. Numbering Plan shall be SS7 PC and SSN for this parameter variant.

e. Encoding shall be octet string for this parameter variant.



A-4DMisanoEnmens(19


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


6 .5 .2 .1 25 SMS_CauseCode



Table 171 SMS_CauseCode va lue


6 . 5 . 2 . 1 2 7 SM S_Des ti nation Address



Figure 138 SMS_DestinationAddress parameter for BCD digits


6.5 . 2 .e f SMS_TransactionID



Figure 6 .5 .2 .e f SMS_TransactionID parameter





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


TR45.2/99.03.15.01; [Phoenix Wireless Group]

Opening Plenary communication requesting a SystemMyTypeCode parameter value assignment.

6 .5 .2 .1 47 SystemMyTypeCode

(TIA/EIA-41-D Chapter 5, page 5-300)(TIA/EIA-41-D Miscellaneous 10, page-88)

The SystemMyTypeCode (MYTYP) parameter indicates the vendor of a system.


Identifier SystemMyTypeCodeIMPLICIT Unsigned Enumerated

M 6.5.1.2


Contents


Vendor Identifier 1 a, b

Figure 164 SystemMyTypeCode parameter

Notes:

a. SystemMyTypeCode identifiers may be obtained from the chairman of theTIATR-45.2 Subcommittee through the TIA.

b. The SystemMyTypeCode should be ignored unless the value is for thevendor’s own system.



A-4DMisanoEnmens(19


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


Table 183 SystemMyTypeCode value

Vendor Identifier (octet 1)


0 0 0 0 0 0 0 0 0 Not used.0 0 0 0 0 0 0 1 1 ED S.

0 0 0 0 0 0 1 0 2 Astronet .0 0 0 0 0 0 1 1 3 Lucent Technologies.0 0 0 0 0 1 0 0 4 Ericsson .0 0 0 0 0 1 0 1 5 GTE.0 0 0 0 0 1 1 0 6 Motor ol a.0 0 0 0 0 1 1 1 7 NEC.0 0 0 0 1 0 0 0 8 NORTEL.0 0 0 0 1 0 0 1 9 NovAte l .0 0 0 0 1 0 1 0 10 P l e x s y s .0 0 0 0 1 0 1 1 11 Digital Equipment Corp.0 0 0 0 1 1 0 0 12 INET.0 0 0 0 1 1 0 1 13 Be l l c or e .0 0 0 0 1 1 1 0 14 Alcatel SEL.0 0 0 0 1 1 1 1 15 Compaq. Tandem

0 0 0 1 0 0 0 0 16 QUALCOMM.

0 0 0 1 0 0 0 1 17 Al di sc on .0 0 0 1 0 0 1 0 18 Celcore .0 0 0 1 0 0 1 1 19 TELOS.0 0 0 1 0 1 0 0 20 ADI Limited. Stanil i te

0 0 0 1 0 1 0 1 21 Coral Systems.0 0 0 1 0 1 1 0 22 Synacom Technology.0 0 0 1 0 1 1 1 23 DSC .0 0 0 1 1 0 0 0 24 MC I.0 0 0 1 1 0 0 1 25 NewNet.0 0 0 1 1 0 1 0 26 Sema Group Telecoms.0 0 0 1 1 0 1 1 27 LG Information and

Communications.0 0 0 1 1 1 0 0 28 CBIS .0 0 0 1 1 1 0 1 29 Si e m e ns .0 0 0 1 1 1 1 0 30 Samsung Electronics.

0 0 0 1 1 1 1 1 31 ReadyCom Inc..0 0 1 0 0 0 0 0 32 AG Communication Systems.

0 0 1 0 0 0 0 1 33 Hughes Network Systems.

0 0 1 0 0 0 1 0 34 Phoenix Wireless Group.

0 0 1 0 0 0 1 1 35

• • • through

1 1 1 1 1 1 1 1 255

Reserved.




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


6 .5 .2 .1 52 TDMACallMode



Figure 169 TDMACallMode parameter


Table 185 TDMACal lMode value




A-4DMisanoEnmens(19


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


TR45.2.3/99.04.14#19; [Ericsson]

Update TDMATerminationCapability parameter values in the “Protocol Version” field to include mobile stations that comply to TIA/EIA-136-A.

This is a change to IS-730 that replaced TSB76.

6 . 5 .2 . j TDMATerminalCapability (new)(IS-730 , page 126 (replacing TSB76 , page 45); new for IS-41-C Chapter 5, page 299)

Note: the omitted existing text is retained without modification; see IS-730.

Figure IS-730-26 TDMATerminalCapability parameter


Table IS-730-10 TDMATerminalCapabil ity value

Supported Frequency Band (octet 1)



Voice Coder (octet 2)



Protocol Version (octet 3)Bits H G F E D C B A Value Meaning

0 0 0 0 0 0 0 0 0 EIA-553 or IS-54-A.

0 0 0 0 0 0 0 1 1 TIA/EIA-627.(IS-54-B).

0 0 0 0 0 0 1 0 2 IS-136.

0 0 0 0 0 0 1 1 3 Permanently Reserved (ANSI J-STD-011).Treat the same as value 4, IS-136-A.

0 0 0 0 0 1 0 0 4 PV 0 as published in TIA/EIA-136-0 andIS-136-A.

0 0 0 0 0 1 0 1 5 PV 1 as published in TIA/EIA-136-A.



0 0 0 0 1 0 0 0 8

• • • through

1 1 1 1 1 1 1 1 255

Reserved. Treat a reserved value the sameas value 0, EIA-553 or IS-54-A.

Asynchronous Data (ADS) (octet 4, bit A)


Note: the remainder of this section is retained without modification; see IS-730.




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



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.


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 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)


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.


Identifier TerminalTypeIMPLICIT Unsigned Enumerated

M 6.5.1.2


Contents


TerminalType 1

Figure 171 TerminalType parameter



A-4DMisanoEnmens(19


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


Table 187 TerminalType value

TerminalType (octet 1)


0 0 0 0 0 0 0 0 0 Not used.0 0 0 0 0 0 0 1 1 Not distinguished

(e.g., EIA/TIA-553, IS-54-A, IS-88, IS-91, IS-94).

0 0 0 0 0 0 1 0 2 IS-54 -B .0 0 0 0 0 0 1 1 3 IS-136 .0 0 0 0 0 1 0 0 4 J-STD-011 (rescinded 11/23/99).

0 0 0 0 0 1 0 1 5 IS-136-A or

TIA/EIA-136 Revision-0 .

0 0 0 0 0 1 1 0 6 TIA/EIA-136-A.

0 0 0 0 0 1 1 1 7 TIA/EIA-136-B.

0 0 0 0 1 0 0 0 8

• • • through

0 0 0 1 1 1 1 1 31

Reserved. Treat a reserved value the sameas value 2, IS-54-B.

0 0 1 0 0 0 0 0 32 IS-95 .0 0 1 0 0 0 0 1 33 IS-95 -A .0 0 1 0 0 0 1 0 34 J-STD-008 .

0 0 1 0 0 0 1 1 35 TIA/EIA-95-B .

0 0 1 0 0 1 0 0 36 I S - 2 0 0 0 .

0 0 1 0 0 1 0 1 37

• • • through

0 0 1 1 1 1 1 1 63

Reserved. Treat a reserved value the sameas value 33, IS-95-A.

0 1 0 0 0 0 0 0 64 IS-88 .0 1 0 0 0 0 0 1 65 IS-94 .0 1 0 0 0 0 1 0 66 IS-91 .0 1 0 0 0 0 1 1 67 J-STD-014 .

0 1 0 0 0 1 0 0 68 TIA/EIA-553-A.

0 1 0 0 0 1 0 1 69 IS-91 -A .

0 1 0 0 0 1 1 1 70

• • • through

1 1 0 1 1 1 1 1 223

Reserved. Treat the same the same asvalue 1, Not distinguished .

1 1 1 0 0 0 0 0 224

• • • through

1 1 1 1 1 1 1 1 255

Reserved for T I A / E I A - 4 1 protocolextension. If unknown, treat a reservedvalue the same as value 1, N o t distinguished .




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


6 .5 .2 .1 57 TerminationRestrictionCode

(TIA/EIA-41.5-D , page 5-310)


Table 189 TerminationRestrictionCode value parameter(TIA/EIA-41.5-D page 5-310)


6 .5 .2 . 15 9 TerminationTriggers

(TIA/EIA-41.5-D , page 5-312)


Table 191 TerminationTriggers value


6 .5 .2 .1 60 TransactionCapability

(TIA/EIA-41.5-D , page 5-315)


Figure 177 TransactionCapability parameter


Table 192 TransactionCapability value parameter


TR45.2.3/99.12.15#14; [ERICSSON]

Correct reserved range values for parameter TriggerType. This is a change to IS-771.

6 . 5 . 2 . d h T ri gg er Ty pe

(new for TIA/EIA-41.5-D , page 5-316)(introduced new by TIA/EIA/IS-771, page 5-106)




A-4DMisanoEnmens(19


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


0 1 0 0 0 1 0 0 68 T_Routable .

0 1 0 0 0 1 0 1 69

• • • through

1 1 0 1 1 0 1 1 219

Reserved. Treat reserved values the sameas value 1, ASCII.

1 1 0 1 1 1 0 0 220 Reserved for TDP-R DP Type value.

Note: the remaining portion of this section is retained without modification; see IS-730.


Enhancement to IS-730 UserZoneData parameter and ANSI-41.5-D FacilitiesDirective2 operation to support CDMA Tiered Services.

6.5 .2 . p UserZoneData (new)

(new for TIA/EIA-41.5-D , page 5-318)(introduced new by TIA/EIA/IS-730 , page 132)



Identifier UserZoneDataIMPLICIT OCTET STRING

M 6.5.1.2


Contents


1

UZ Identifier 1 2 a, g

3

Rsvd SUZ UZPAC 1 UZ Priority Indicator 1 4 b, c, h, j

• • • • • • d

(4*m-3)

UZ Identifier m (4*m-2) e, g

(4*m-1)

Rsvd SUZ UZPAC m UZ Priority Indicator m (4*m) f, h, j

• • • n i

Figure 3579-31 UserZoneData parameter

Notes:


g. User Zone Identifier values (shown in hexadecimal below):

0 = Reserved.

1-FFFFFF = valid UZ zone number.




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


If the identifier used on the air interface is less than 24 bits in length, as n

bits in length, then the first (24 - n) bits shall be set to zero.

h. Reserved bits shall be ignored on receipt and set to zero on sending.

Set reserved values to 0 when sending, ignore if received.

i. Ignore extra octets, if received. Send only defined (or significant) octets.

j. Serving User Zone (SUZ). If encoded as value one, this User Zone is the

zone in which the MS is currently receiving service. When transferring the

User Zone Data from one MSC to another, the SUZ field of at most

one UserZone should be encoded as value one. User Zone Data

should have the SUZ bit set to value = 1.

6 .5 . 3 .2 . D ig it sType



Table 196 (continued)


Table 200 Forward Compatibility Guidelines for HandlingIncoming Messages and Parameters





A-4DMisanoEnmens(19


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

Protocol Procedures Enhancements 122 TIA/EIA-41.6.D (Stage 3)

5. TIA/EIA-41.6-D Stage 3 Signaling ProcedureEnhancements

2 .1 INTERSYSTEM HANDOFF PROCEDURES



3 . 1 REGISTRATION CALL TASKS(TIA/EIA-41-D Chapter 6, page 6-9)

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.

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:


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.




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.6.D (Stage 3) 123 Protocol Procedures Enhancements

TR45.2.3/99.12.17#7; [GTE]

Enhancement to avoid assigning MDNs to packet only subscribed terminals. This is a change to IS-756-A.

TR45.2.3/99.06.17#30; [Motorola]

Miscellaneous nit-picky error correction (e.g., eliminate TerminationRestrictionCode recommendation).


Provide NP (Non-Public) mode operation Stage-3 procedures.

3.1 .3 Loading of Profile Parameters(TIA/EIA-41.6-D page 6-10)


13 ENDIF.

14 If a directory number is assigned to the subscriber, include the

MobileDirectoryNumber parameter set to the subscriber's current directory

number.

14 IF the MS is to be identified with a mobile directory number (other than itsMIN):

14-1 IF the Profile is supported for this transaction:

14-1-1 Include the MobileDirectoryNumber parameter set to the subscriber’scurrent directory number.

14-2 ELSE:

14-2-1 (Consider restricting originations and terminations or activating CNIR.)

14-3 ENDIF.

15 ENDIF.

16 Include the OriginationIndicator parameter set appropriately.


29 IF the current transaction supports local SPINI operation AND IF local SPINIoperation is desirable:

29-1 Include the SPINITriggers parameter set with the appropriate triggers forlocal SPINI operation.

29-2 Include the SPINIPIN parameter set to the SPINI PIN.

30 ENDIF.

31 Include the TerminationRestrictionCode parameter set appropriately.

32 IF termination triggers are required:

32-1 IF the Profile is supported for this transaction:

32-1-1 Include the TerminationTriggers parameter set appropriately.

32-2 ELSE:

32-2-1 (Consider restricting terminations.)

32-3 ENDIF.

33 ENDIF.

X IF the subscriber is authorized for Non-Public (NP) mode operation:

X-1 IF Profile is supported for this transaction:



A-4DMisanoEnmens(19


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


X-1-1 Include the NonPublicData parameter with the Non-Public Info Display

field set to the appropriate value for this MS.

X-2 ENDIF.

Y ENDIF.

34 Return to the calling task.



3.2.4 HLR Analyze MS Dialed Number(TIA/EIA-41.6-D page 6-19)

Upon request, the HLR shall do the following:

1 IF a Service Code (e.g., N11, *N11) was dialed:

1-1 Process the dialed Service Code into an appropriate destination including

consideration of the PreferredLanguageIndicator.

1-2 Set the PointOfReturn to PSTNTermination .


3.2. 8 Initialize the OneTimeFeatureIndicator Parameter(TIA/EIA-41.6-D page 6-23)


3.3 .2 Wait for TLDN Call(TIA/EIA-41.6-D page 6-26)


3.3 .3 Page an MS Procedure(TIA/EIA-41.6-D , page 27)





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


4.1. 2 HLR Receiving AuthenticationDirective INVOKE(TIA/EIA-41.6-D page 6-46)

Ta b l e 1 HLR AuthenticationDirective Response


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”.

4.1. 3 VLR Receiving AuthenticationDirective INVOKE(TIA/EIA-41.6-D page 6-47)


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.


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.



A-4DMisanoEnmens(19


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



Ta bl e 2 VLR AuthenticationDirective Response(TIA/EIA-41.6-D page 6-50)


Problem Detections:


5. A supplied parameter value is unrecognized or has nonstandard values (e.g., Not used ).


4.1. 4 MSC Receiving AuthenticationDirective INVOKE(TIA/EIA-41.6-D page 6-51)

Ta bl e 3 MSC AuthenticationDirective Response


TR45.2.III/99.06.17#20 [LG Sansys]



4.1. 5 VLR Initiating an Authentication Directive(TIA/EIA-41.6-D page 6-52)


3 IF a COUNT update shall be initiated:

3-1 Include the UpdateCount (UPDCOUNT) parameter.

3-2 Mark the MS pending COUNT update.

4 ENDIF.

X Include the MobileStationIDentity and ElectronicSerialNumber associated with

an MS to perform the authentication process.

5 Include the SenderIdentificationNumber set to the identification number of thesending functional entity.

6 Send an AuthenticationDirective INVOKE to the MSC serving the MS.





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


TR45.2.III/99.06.17#20 [LG Sansys]



4. 3. 1 MSC Initiating an Authentication Failure Report(TIA/EIA-41.6-D page 6-61)

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 ).


TR45.2.III/99.06.17#20 [LG Sansys]



TR45.2.III/98.08.19#15 [Motorola]


4.3. 2 VLR Receiving AuthenticationFailureReport INVOKE(TIA/EIA-41.6-D page 6-63)


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).



A-4DMisanoEnmens(19


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



T ab l e 5 VLR AuthenticationFailureReport Response


Problem Detections:


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).


4.3. 3 HLR Receiving AuthenticationFailureReport INVOKE


T ab l e 6 HLR AuthenticationFailureReport Response


TR45.2.3/99.08.19#19; [LG Sansys]

Enhancement to support the AC including the TerminalType parameter in afreport operations to distinguish the type of AC (TSB51 or IS-41-C or later).

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”.

4.3. 4 AC Receiving AuthenticationFailureReport INVOKE(TIA/EIA-41.6-D page 6-69)


1-2 ELSE (the MSCID parameter is received (the VLR is not TSB 51compliant):

1-2-1 IF the ReportType parameter indicates that an authentication failure hasbeen detected:

1-2-1-1 Execute recovery procedures according to the AC’s internal

algorithm.

1-2-2 ENDIF.

1-2-X Include the TerminalType parameter.

1-2-3 IF service shall be denied:

1-2-3-1 Include the DenyAccess parameter.

1-2-3-2 Send a RETURN RESULT.

1-2-3-3 Exit this task.




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-2-4 ENDIF.


T ab l e 7 AC AuthenticationFailureReport Response


TR45.2.III/99.06.17#20 [LG Sansys]



4. 3. 5 VLR Initiating an Authentication Failure Report(TIA/EIA-41.6-D page 6-72)

When a VLR determines that an Authentication Failure Report is necessary, it shall

perform the following:


set to the value indicated by the calling task.

1 Include the ReportType parameter set to the value indicated by the calling task.

2 Include the SystemCapabilities (SYSCAP) parameter indicating whether theVLR is able to execute CAVE.


TR45.2.III/99.06.17#20 [LG Sansys]



4.4. 1 MSC Initiating an Authentication Request(TIA/EIA-41.6-D page 6-75)

(TIA/EIA/IS-778 page 64)


3 ENDIF.

4 IF the authentication request process was started in response to a system access:

4-1 Include the SystemAccessType parameter set to indicate the type of access

triggering the request (e.g., Autonomous registration, Power downregistration, Call origination, Page response, Flash request ).

a ELSE:

a-1 Include the SystemAccessType parameter set to indicate Unspecified .



A-4DMisanoEnmens(19


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


b ENDIF.


required to perform the authentication process.

5 Include the SystemCapabilities (SYSCAP) parameter indicating whetherauthentication parameters were requested for this system access.

6 Include the MSCID parameter set to the identity of the MSC.a Include the TerminalType parameter set to the value provided by the MS.

b IF the SystemAccessType parameter indicates a Flash request and Signaling

Message Encryption is not active:


4.4. 2 VLR Receiving AuthenticationRequest INVOKE(TIA/EIA-41.6-D page 6-78)

Ta bl e 8 VLR AuthenticationRequest Response


4.4. 3 HLR Receiving AuthenticationRequest INVOKE(TIA/EIA-41.6-D page 6-85)

Ta bl e 9 HLR AuthenticationRequest Response


4.4. 4 AC Receiving AuthenticationRequest INVOKE(TIA/EIA-41.6-D page 6-87)

Tab le 10 AC Authenticat ionRequest Response





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


TR45.2.III/99.06.17#20 [LG Sansys]


Portions of this recommendation are a change to IS-778 and to IS-725-A.

4. 5. 1 MSC Initiating an Authentication Status Report(TIA/EIA-41.6-D page 6-92)

(TIA/EIA/IS-725-A page 6-18)


7 Include the SenderIdentificationNumber set to the identification number of thesending functional entity.

8 Include the SystemCapabilities (SYSCAP) parameter indicating whetherauthentication parameters were requested for this system access.

X Include the ElectronicSerialNumber parameter set to the MS’s

ElectronicSerialNumber.

e IF the MS is in a call and the call was originated using an OTASP Feature Code(*FC):

e-1 Include the ElectronicSerialNumber parameter set to the MS’s

ElectronicSerialNumber value.

e-2 Set Include the MobileIdentificationNumber parameter set to the

Activation_MIN value.

e-3 Include the ServiceIndicator parameter set to the CDMA OTASP Service

value.

f ENDIF.


4.5. 2 VLR Awaiting AuthenticationStatusReport INVOKE(TIA/EIA-41.6-D page 6-93)

Ta bl e 11 VLR Authent icat ionStatusReport Response


4.5. 3 HLR Receiving AuthenticationStatusReport INVOKE(TIA/EIA-41.6-D page 6-98)

Ta bl e 12 HLR Authent icat ionStatusReport Response




A-4DMisanoEnmens(19


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


TR45.2.III/99.06.17#20 [LG Sansys]



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”.

4.5. 4 AC Awaiting AuthenticationStatusReport INVOKE(TIA/EIA-41.6-D page 6-100)

(TIA/EIA/IS-778 page 85)


3-2-12-3 Mark the MS pending SSD update.

3-2-12-4 IF AC administrative procedures indicate that the pending

SharedSecretData (SSD) shall be shared with the VLR for the SSD

update operation AND IF the VLR’s SystemCapabilities indicates

that the VLR is able to execute the CAVE algorithm:

3-2-12-4-1 Include the SharedSecretData (SSD) parameter set to the

pending SSD value.

3-2-12-4-2 IF the AuthenticationAlgorithmVersion (AAV) parameter for

this MS is different than the default AAV value:

3-2-12-4-2-1 Include t he AuthenticationAlgorithmVersion ( AAV)

value.

3-2-12-4-2 IF the AuthenticationAlgorithmVersion (AAV) parameter is

received:

3-2-12-4-2-1 Store the AuthenticationAlgorithmVersion (AAV) value.

3-2-12-4-3 ENDIF.

3-2-12-4 IF AC adminis trat ive procedures indicate tha t the pendingSharedSecretData (SSD) shall be shared with the VLR for the SSD updateoperation:

3-2-12-4-1 IF the VLR’s SystemCapabilities indicates that the VLR is able toexecute the CAVE algorithm:

3-2-12-4-1-1 Include the SharedSecretData (SSD) parameter set to thepending SSD value.

3-2-12-4-1-2 IF the AuthenticationAlgorithmVersion (AAV) parameter isreceived:

3-2-12-4-1-2-1 Store the AuthenticationAlgorithmVersion (AAV) value.

3-2-12-4-1-3 ENDIF.

3-2-12-4-2 ENDIF.

3-2-12-5 ELSE (pending SharedSecretData (SSD) is not to be shared:


3-2-13-1 IF the SharedSecretData (SSD) shall be shared with the VLR:

3-2-13-1-1 IF the VLR’s SystemCapabilities indicates the VLR is capableof executing the CAVE algorithm:




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


3-2-13-1-1-1 Include the SharedSecretData (SSD) and CallHistoryCount(COUNT) parameters.

3-2-13-1-1-2 IF the AuthenticationAlgorithmVersion (AAV) parameter

for this MS is different than the default AAV value:

3-2-13-1-1-2-1 Include the AuthenticationAlgorithmVersion (AAV)

value.

3-2-13-1-1-2 IF the AuthenticationAlgorithmVersion (AAV) parameteris received:

3-2-13-1-1-2-1 Store the AuthenticationAlgorithmVersion (AAV)value.

3-2-13-1-1-3 ENDIF.

3-2-13-1-2 ENDIF.


Ta bl e 13 AC Authent icat ionStatusReport Response


TR45.2.III/99.06.17#20 [LG Sansys]



4.6 .3 HLR Receiving BaseStationChallenge INVOKE(TIA/EIA-41.6-D page 6-106)


1-3 Send a BaseStationChallenge INVOKE to the AC associated with the MS.

1-4 Start the Base Station Challenge Timer (BSCT).

1-5 WAIT for a Base Station Challenge response:

1-6 WHEN a RETURN RESULT is received:

1-6-1 Stop timer (BSCT).

1-6-2 IF the message can be processed:

1-6-2-X Relay all received parameters.

1-6-2-1 Send a RETURN RESULT to the requesting VLR.

1-6-2-2 Exit this task.

1-6-3 ENDIF.




A-4DMisanoEnmens(19


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


4. 11 .1 Serving MSC Initiating a Facilities Directive



TR45.2.2/99.08.17#6; [ERICSSON]

Provide an enhanced FACDIR or FACDIR2 method for Handoff Back; Stage 3:


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


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.




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-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).



A-4DMisanoEnmens(19


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-5 ELSE (there are no voice/traffic channels available on the designated cell(s)or inter-MSC trunk is unavailable):

1-5-1 Send a RETURN ERROR with Error Code ResourceShortage.

1-6 ENDIF.


TR45.2.2/99.08.17#6; [ERICSSON]


4. 12 .2 Target MSC Receiving a FacilitiesDirective2 INVOKE


When the Target MSC receives a FacilitiesDirective2 INVOKE, the MSC shall dothe following:


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-2 ENDIF.1-3 Identify the target traffic channel and associated transmission modes based

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 FF16 (indicating Unspecified ):

1-4-1-1 Do not change the value.

1-4-2 ELSE:


1-4-12 ENDCASE.


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

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-4-Y-2 Exit this task.

1-4-Z ENDIF.

1-4-14 Execute the “Target MSC Handoff Forward” task (see 4.12.3).

1-5 ELSE (there are no voice/traffic channels available on the designated cell(s)or inter-MSC trunk is unavailable):

1-5-1 Send a RETURN ERROR with Error Code ResourceShortage.1-6 ENDIF.

2 ELSE (the received message cannot be processed):

2-1 Send a RETURN ERROR with the proper Error Code value (see thefollowing table).

3 ENDIF.

4 Exit this task.

TR45.2.2/99.08.17#6; [ERICSSON]


TR45.2.3/99.08.19#16; [Ericsson]

Enhancement to support SMDPP acknowledgment delivery to a mobile station after handoff .

4. 13 .2 MSC Receiving FacilitiesRelease INVOKE(TIA/EIA-41.6-D page 6-125)

Upon receipt of a FacilitiesRelease INVOKE an MSC shall:


1-1 Mark the inter-MSC trunk as idle.

1-2 IF there is a task waiting for the indicated intersystem trunk:

1-2-1 Pass a FacilitiesRelease message to the waiting task (e.g.,“Serving MSC Initiating a Facilities Directive” task (see 4.11.1),


“MSC Initiating InterSystemAnswer” task (see 4.24.3)).

"MSC Initiating SMS Delivery Backward" task (see 4.44.1)).

1-3 ENDIF.

1-X IF the MSC is an Anchor or Tandem MSC and it is also the Serving MSC:

1-X-1 IF ReleaseReason parameter indicates HandoffSuccessful:

1-X-1-1 Send a RETURN RESULT.

1-X-2 ELSE:

1-X-2-1 Send a RETURN ERROR with proper Error Code value (see the

following table).

1-X-3 ENDIF.

1-Y ENDIF.

1-4 IF the receiving MSC is the Anchor MSC and it is not the Serving MSC:

1-4-1 IF a BillingID parameter is received:



A-4DMisanoEnmens(19


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-4-1-1 Extract the SegmentCounter field to close the audit record (see DMH for more information).

1-4-2 ELSE:

1-4-2-1 Close the DMH audit record with a unknown number of segments.

1-4-3 ENDIF.

1-4-4 Send a RETURN RESULT.1-5 ELSEIF the receiving MSC is the Serving MSC and it is not an Anchor or

Tandem MSC:

1-5-1 Include the BillingID parameter containing the number of segments.


1-6 ELSEIF the receiving MSC is a Tandem MSC and it is not the Serving

MSC:

1-6-1 IF the receiving MSC is not waiting for a FacilitiesRelease RETURNRESULT (see 4.13.1):

1-6-1-1 Relay the ReleaseReason parameter received in the INVOKE.




4.14 .1 MSC Detecting Feature Request(TIA/EIA-41.6-D page 6-127)


15-2 IF the message can be processed:15-2-1 IF the MS is still connected:

15-2-1-1 IF the AnnouncementList parameter is received:

15-2-1-1-1 Execu te the “Play All Anno uncements in theAnnouncementList” task (see 3.2.5).

15-2-1-1-a IF the PreferredLanguageIndicator parameter is received:

15-2-1-1-a-1 Use the received PreferredLanguageIndicator parameter

value instead of the profile value.

15-2-1-1-b ENDIF.

15-2-1-2 ELSEIF the FeatureResult parameter indicates Successfuloperation:

15-2-1-2-1 Provide a successful indication to the MS.





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


4. 14 .3 HLR Receiving FeatureRequest INVOKE


Tab l e 22 HLR FeatureRequest Response


TR45.2.2/99.08.17#6; [ERICSSON]


4.16 .3 Target MSC Handoff Back


After returning a FacilitiesDirective RETURN RESULT, HandoffBack RETURN

RESULT, a HandoffBack2 RETURN RESULT, a HandoffToThird RETURN

RESULT or a HandoffToThird2 RETURN RESULT to the serving system, the

Target MSC performs the following:

W IF the message returned was a FacilitiesDirective RETURN RESULT:

W-1 Start the Mobile Arrival Timer (MAT).

W-2 WAIT for MS arrival on designated voice/traffic channel:

W-3 WHEN the MS arrives on designated voice/traffic channel:

W-3-1 Stop timer (MAT).

W-3-2 Complete the voice path between the voice channel and the designated

inter-MSC trunk.

W-3-3 Send a MobileOnChannel INVOKE to the Serving MSC.

W-3-4 Include the ReleaseReason parameter set to HandoffSuccessful.

W-3-5 Execute an "MSC Initiating a Facilities Release" task through oldServing MSC via Tandem MSCs (see 4.13.1).

W-4 WHEN the timer (MAT) expires:

W-4-1 Execute "Local Recovery Procedures" task (see 3.5.1).

W-4-2 Release the reserved voice channel; however, do not send a

FacilitiesRelease INVOKE to the Serving MSC.

W-5 WHEN a FacilitiesRelease INVOKE is received (call abandonment or

facility handback release, see 4.13.2):


W-6 ENDWAIT.

X ELSE (The message returned was not a FacilitiesDirective RETURN RESULT):

X-1 IF the BillingID parameter is not received:

X-1-1 Set the Segment Counter field to FF16.

X-2 ELSEIF the value of the Segment Counter field of the BillingID parameter

is FF16 (indicating Unspecified ):

X-2-1 Do not change the value.

X-3 ELSE:



A-4DMisanoEnmens(19


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


X-3-1 Increment the Segment Counter field value of the BillingID parameter

by 1 (to be associated with the air segment being created).

X-4 ENDIF.

X-5 Include the updated BillingID parameter for the new air time segment.

X-6 Start the Mobile Arrival Timer (MAT).

X-7 WAIT for MS to arrive to the designated channel:

X-8 WHEN the MS is received on the designated voice channel:

X-8-1 Stop timer (MAT).

X-8-2 Include the ReleaseReason parameter set to HandoffSuccessful.

X-8-3 Execute an “MSC Initiating a FacilitiesRelease” (see 4.13.1).

X-9 WHEN the timer (MAT) expires:

X-9-1 Execute “Local Recovery Procedures” task (see 3.5.1).

X-9-2 Release the reserved voice channel; however, do not send a


X-10 WHEN a FacilitiesRelease INVOKE is received (call abandonment or

facility handback release, see 4.13.2):X-10-1 Stop timer (MAT).

X-11 ENDWAIT.

Y ENDIF.

11 Exit this task.

TR45.2.2/99.08.17#6; [ERICSSON]


4.17 .3 Target MSC Handoff Back2(TIA/EIA-41-D Chapter 6, page 6-148)

After returning a FacilitiesDirective2 RETURN RESULT, HandoffBack2 RETURN

RESULT, or a HandoffToThird2 RETURN RESULT to the serving system, theTarget MSC performs the following:

W IF the message returned was a FacilitiesDirective2 RETURN RESULT:

W-1 Start the Mobile Arrival Timer (MAT).

W-2 WAIT for MS arrival on designated traffic voice/traffic channel:

W-3 WHEN the MS arrives on designated traffic voice/traffic channel:


W-3-2 Complete the voice path between the traffic voice channel and the

designated inter-MSC trunk.

W-3-3 Send a MobileOnChannel INVOKE to the Serving MSC.

W-3-4 Include the ReleaseReason parameter set to HandoffSuccessful.

W-3-5 Execute an "MSC Initiating a Facilities Release" task through old

Serving MSC via Tandem MSCs (see 4.13.1).

W-4 WHEN the timer (MAT) expires:




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


W-4-1 Execute "Local Recovery Procedures" task (see 3.5.1).

W-4-2 Release the reserved traffic voice channel; however, do not send a


W-5 WHEN a FacilitiesRelease INVOKE is received (call abandonment or


W-5-1 Stop timer (MAT).W-6 ENDWAIT.

X ELSE (The message returned was not a FacilitiesDirective2 RETURN

RESULT):

X-1 IF the BillingID parameter is not received:

X-1-1 Set the Segment Counter field to FF16.

X-2 ELSEIF the value of the Segment Counter field of the BillingID parameter

is FF16 (indicating Unspecified ):

X-2-1 Do not change the value.

X-3 ELSE:

X-3-1 Increment the Segment Counter field value of the BillingID parameterby 1 (to be associated with the air segment being created).

X-4 ENDIF.

X-5 Include the updated BillingID parameter for the new air time segment.

X-6 Start the Mobile Arrival Timer (MAT).

X-7 WAIT for MS to arrive to the designated channel:

X-8 WHEN the MS is received on the designated traffic voice channel:


X-8-2 Include the ReleaseReason parameter set to HandoffSuccessful.

X-8-3 Execute an “MSC Initiating a Facilities Release” (see 4.13.1).

X-9 WHEN the timer (MAT) expires:

X-9-1 Execute “Local Recovery Procedures” task (see 3.5.1).

X-9-2 Release the reserved traffic voice channel; however, do not send a


X-10 WHEN a FacilitiesRelease INVOKE is received (call abandonment or



X-11 ENDWAIT.

Y ENDIF.

11 Exit this task.



A-4DMisanoEnmens(19


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


4. 20 .2 Tandem MSC Receiving HandoffToThird INVOKE


Tab le 28 Tandem MSC HandoffToThird Response


4. 24 .1 MSC Awaiting InterSystemAnswer INV OKE



4. 25 .1 MSC Initiating an InterSystem Page(TIA/EIA-41-D Chapter 6, page 6-175)


4.25 .2 MSC Receiving InterSystemPage INVO KE(TIA/EIA-41-D Chapter 6, page 6-177)


Tab le 34 Border MSC InterSystemPage Response(TIA/EIA-41.6-D page 6-179)


4. 26 .1 MSC Initiating an InterSystemPage2(TIA/EIA-41-D Chapter 6, page 6-182)





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


4.26 .2 MSC Receiving InterSystemPage2 INVOK E(TIA/EIA-41-D Chapter 6, page 6-182)


Ta bl e 35 Border MSC InterSystemPage2 Response(TIA/EIA-41.6-D page 6-184)


4. 27 .1 MSC Initiating an Intersystem Setup



Tab l e 3 7 HLR LocationRequest Response(TIA/EIA-41.6-D page 6-194)


4.XX Message Directive

4.XX.1 HLR Receiving MessageDirective INVOKE



Ta bl e 4. xx 1 HLR MessageDirective Response


4. 30 .4 HLR Receiving MSInactive INVOKE(TIA/EIA-41-D Chapter 6, page 6-198, line 2)




A-4DMisanoEnmens(19


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




4. 31 .1 MSC Initiating an Origination Request(TIA/EIA-41.6-D page 6-201)


11-2 IF the message can be processed:

11-2-1 IF the incoming call is still connected:

11-2-1-1 IF the AnnouncementList parameter is received:

11-2-1-1-a IF the PreferredLanguageIndicator parameter is received:

11-2-1-1-a-1 Use the received PreferredLanguageIndicator parameter

value instead of the profile value.

11-2-1-1-b ENDIF.

11-2-1-1-1 Execu te the “Play All Anno uncements in the

AnnouncementList” task (see 3.2.5).11-2-1-2 ENDIF.


4. 31 .2 HLR Receiving an OriginationRequest INVOKE(TIA/EIA-41-D Chapter 6, page 6-202, line 31)


Ta ble 41 HLR OriginationRequest ResponseSee TIA/EIA-41-D Miscellaneous Enhancements Revision 10.




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


TR45.2.3/99.06.17#30; [Motorola]


TR45.2.III/98.08.19#15 [Motorola]


4. 32 .2 VLR Receiving QualificationDirective INVOKE(TIA/EIA-41.6-D page 6-206)


Tab le 42 VLR Orig inationDirective Response(TIA/EIA-41.6-D page 6-207)


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).


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).




A-4DMisanoEnmens(19


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


TR45.2.3/99.06.17#30; [Motorola]


TR45.2.III/98.08.19#15 [Motorola]


4. 32 .4 MSC Receiving QualificationDirective INVOKE(TIA/EIA-41.6-D page 6-208)

Tab le 43 MSC Qual ificationDirective Response


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).


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).


TR45.2.3/99.06.17#30; [Motorola]


TR45.2.III/98.08.19#15 [Motorola]


4. 33 .3 VLR Receiving QualificationRequest INVOKE(TIA/EIA-41.6-D page 6-212)


Tab le 44 VLR Qual ificationRequest Response(TIA/EIA-41.6-D page 6-215)


Problem Detections:





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



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).


TR45.2.3/99.06.17#30; [Motorola]


TR45.2.III/98.08.19#15 [Motorola]


4. 33 .4 HLR Receiving QualificationRequest INVOKE(TIA/EIA-41.6-D page 6-216)

Tab le 45 HLR QualificationRequest Response(TIA/EIA-41.6-D page 6-217)


Problem Detections:



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).


4. 35 .2 MSC Receiving RedirectionDirective INVOKE(TIA/EIA-41.6-D page 6-221)

Ta bl e 47 Originating MSC RedirectionDirective Response




A-4DMisanoEnmens(19


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


4. 36 .2 MSC Receiving RedirectionRequest INVOKE(TIA/EIA-41.6-D page 6-224)

Ta bl e 48 Originating MSC RedirectionRequest Response


4. 37 .1 HLR Initiating Registration Cancellation(TIA/EIA-41-D Chapter 6, page 6-226, line 7)


4. 37 .3 VLR Initiating Registration Cancellation(TIA/EIA-41-D Chapter 6, page 6-229, line 48)


4. 38 .2 VLR Receiving RegistrationNotification INVOKE(TIA/EIA-41-D Chapter 6, page 6-235, line 6)


Ta bl e 51 VLR Registrat ionNot if icat ion Response



4. 38 .3 HLR Receiving RegistrationNotification INVOKE(TIA/EIA-41-D Chapter 6, page 6-241, line 8)





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


TR45.2.3/99.12.15#10; [QUALCOMM]

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):


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.



A-4DMisanoEnmens(19


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


4. 41 .1 HLR Initiating a Routing Request(TIA/EIA-41-D Chapter 6, page 6-350, line 7)


4.XX RELEASE(new for TIA/EIA-41-D Chapter 6, page 6-245)

4.XX.1 MSC Initiating a RELEASE(new for TIA/EIA-41-D Chapter 6, page 6-245)


4.XX.2 MSC Receiving a RELEASE INVOKE(new for TIA/EIA-41-D Chapter 6, page 6-245)


T ab le 4 .X X. 2 MSC Release Response


4. 41 .2 VLR Receiving RoutingRequest INVOKE(TIA/EIA-41-D Chapter 6, page 6-251, line 18)


Tab l e 54 VLR RoutingRequest Response(TIA/EIA-41-D Chapter 6, page 6-253, line 1)


4. 41 .3 MSC Receiving RoutingRequest INVOKE(TIA/EIA-41-D Chapter 6, page 6-254, line 10)





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


4. 41 .3 MSC Receiving RoutingRequest INVOKE(TIA/EIA-41.6-D page 6-254)


Tab l e 55 MSC RoutingRequest Response


TR45.2.3/99.08.19#16; [Ericsson]


4. 44 .1 MSC Initiating SMS Delivery Backward(TIA/EIA-41.6-D page 6-261)


10 IF the message original originating address is not the same as the originatingaddress:

10-1 Include the SMS_OriginalOriginatingAddress parameter set to the originaloriginating address.

11 ENDIF.

X Set the SMS_TransactionID parameter to the transaction identification.

12 Send a SMSDeliveryBackward INVOKE message toward the DestinationAddress.

13 Start the Short Message Backward Timer (SBT).

14 WAIT for an SMS Delivery Backward response:

15 WHEN a RETURN RESULT is received:15-1 Stop the timer (SBT).


15-X-1 IF the SMSDeliveryBackward INVOKE was initiated by an initial

Serving MSC:

15-2-X-1 IF an intersystem handoff (handoff forward) has occurred:

15-2-X-1-1 Execute the "MSC Initiating SMS Delivery Point To Point

Ack" task (see 4.46.X1).

15-2-X-1-2 Exit this task.

15-2-X-2 ENDIF.

15-2-Y ENDIF.

15-2-1 Relay all parameters received.

15-2-2 Return to the calling task as accepted.

15-3 ELSE (the message cannot be processed):

15-3-1 Return to the calling task with the SMS_CauseCode indicating Other Network Problem.

15-4 ENDIF.



A-4DMisanoEnmens(19


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


X WHEN a FacilitiesRelease INVOKE is received (see 4.13.2):

X-1 Stop the timer (SBT).

X-2 Exit this task.

16 WHEN a RETURN ERROR4 is received:

16-1 Stop the timer (SBT).


TR45.2.3/99.06.19#16; [Ericsson]


4. 46 .2 Initiating SMS Delivery Point-To-Point(TIA/EIA-41.6-D page 6-269)


18 Send a SMSDeliveryPointToPoint INVOKE message.

19 Start the SMS Delivery Timer (SMT).

20 WAIT for an SMSDeliveryPointToPoint response:


21-1 Stop the timer (SMT).


21-2-1 IF the SMSDeliveryPointToPoint INVOKE was initiated by an Anchor

MSC, in response to a SMD-Request:

21-2-1-1 IF an intersystem handoff (handoff forward) has occurred:

21-2-1-1-1 Execute the "MSC Initiating SMS Delivery Point To PointAck" task (see 4.46.X1).

21-2-1-1-2 Exit this task.

21-2-1-2 ENDIF.

21-2-2 ENDIF.

21-2-3 IF the SMSDeliveryPointToPoint INVOKE was initiated by an Anchor

MSC, in response to a SMSDeliveryBackward INVOKE:

21-2-3-1 IF an intersystem handoff (handoff back) has occurred:

21-2-3-1-1 IF the SMS delivery was successful:

21-2-3-1-1-1 Relay parameters received to the MS.

21-2-3-1-1-2 Send a SMD-ACK to the MS based SME.

21-2-3-1-1-3 Exit this task.

21-2-3-1-2 ELSE:

4The sending of an SMS DeliveryBackward RETURN ERROR is not recommendedand error tables are not supplied.




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


21-2-3-1-2-1 Relay the indicated SMS CauseCode.

21-2-3-1-2-2 Send a SMD-NAK to the MS based SME.

21-2-3-1-2-3 Exit this task.

21-2-3-1-3 ENDIF.

21-2-3-2 ENDIF.

21-2-3-3 IF an intersystem handoff (handoff to third) has occurred:

21-2-3-3-1 Execute the "MSC Initiating SMS Delivery Point To Point

Ack" task (see 4.46.X1).

21-2-3-3-2 Exit this task.

21-2-3-4 ENDIF.

21-2-4 ENDIF.

21-2-1 IF the SMS_CauseCode parameter is received:

21-2-1-1 IF the SMS_CauseCode is SMS delivery postponed :


TR45.2.3/99.06.17#30; [Motorola]

Miscellaneous nit-picky error correction.

4. 46 .5 Anchor MSC Initiating SMS Delivery Point-To-Point(TIA/EIA-41.5-D, page 6-277)


1-3 CASE SMS_OriginationRestrictions OF:

1-4 Block All:1-4-1 Include the SMS_CauseCode parameter set to value SMS origination

denied indicating SMS Origination Restriction.

1-4-2 Return to the calling task indicating denied .

1-5 Allow Specific:

1-5-1 IF the MS is not allowed to originate using direct addresses:

1-5-1-1 IF the SMS_DestinationAddress parameter is not equal to theSMS_OriginalOriginatingAddress (direct routing requested):

1-5-1-1-1 Include the SMS_CauseCode parameter set to value SMS

origination denied indicating SMS Origination Restriction.

1-5-1-1-2 Return to the calling task indicating denied .

1-5-1-2 ENDIF.1-5-2 ENDIF.

1-6 DEFAULT:

1-6-1 (Just allow it.)

1-7 ENDCASE.




A-4DMisanoEnmens(19


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


TR45.2.3/99.08.19#16; [Ericsson]


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]


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-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:




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-1-3-1 Discard the message.

1-1-4 ENDIF.

1-2 ELSE (the MSC is a Tandem MSC):

1-2-1 IF the next MSC in the handoff chain is known to support SMS:

1-2-1-1 Discard the InterMSCCircuitID parameter.

1-2-1-2 Relay all parameters received.1-2-1-3 Execute the "MSC Initiating SMS Delivery Point To Point Ack"

task (see 4.46.X1).

1-2-2 ENDIF.

1-3 ENDIF.

2 ENDIF.

3 Exit this task.

4.47 .2 MSC Initiating SMS Notification(TIA/EIA-41-D Chapter 6, page 6-285)


4. 47 .3 MC Receiving an SMSNotification INVOKE(TIA/EIA-41-D Chapter 6, page 6-286)


Tab l e 56 MC SMSNotification Response


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.



A-4DMisanoEnmens(19


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


2 ENDIF.

3 Include the MSID MobileIdentificationNumber parameter set to identify the MS.

4 Include the SMS_TeleserviceIdentifier parameter set to the appropriate teleserviceidentifier value if applicable.

5 IF notification is not required:

5-1 Include the SMS_NotificationIndicator parameter set to Do not notify whenavailable.

6 ENDIF.

7 Send a SMSRequest INVOKE message toward the HLR serving the MS-based

SME MIN.

8 Start the SMS Request Timer (SRT).

9 WAIT for an SMS Request response:


10-1 Stop the timer (SRT).


10-2-1 IF an SMS_Address is received:

10-2-1-1 Return to the calling task with the SMS_Address MSID and an

accepted indication.

10-2-2 ELSEIF an SMS_AccessDeniedReason parameter is received:

10-2-2-1 CASE SMS_AccessDeniedReason value OF:


TR45.2/99.08.16#13; [WNP PH3 editor].

Internationalize 4.48.2 HLR Receiving an SMSRequest INVOKE; this is an enhancement to TIA/EIA/IS-751

4. 48 .2 HLR Receiving an SMSRequest INVOKE(TIA/EIA-41.6-D page 6-289)


1-5-2 ELSE:

1-5-2-1 Set the SMS Delivery Pending Flag for this MS.

1-5-2-2 Include the SMS_AccessDeniedReason parameter set to Postponed .

1-5-3 ENDIF.

1-6 ENDIF.

1-X IF the MSID parameter is not present:

1-X-1 Include the MSID parameter set to the type of mobile station identifier

needed for SMS delivery.

1-Y ENDIF.

1-7 Send a RETURN RESULT.

2 ELSE (message cannot be processed):

2-1 Include the Error Code parameter set to the proper value (see the followingtable).




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


2-2 Send a RETURN ERROR.

3 ENDIF.

4 Exit this task.

T a b l e 5 7 HLR SMSRequest Response


4. 48 .3 VLR Receiving an SMSRequest INVOKE(TIA/EIA-41.6-D page 6-292)

T a b l e 5 8 VLR SMSRequest Response


TR45.2/99.08.16#13; [WNP PH3 editor].

Internationalize 4.48.4 MSC Receiving an SMSRequest INVOKE; this is an enhancement to TIA/EIA/IS-751

4. 48 .4 MSC Receiving an SMSRequest INVOKE(TIA/EIA-41.6-D page 6-294)


1-4-2 ELSE (notification was requested):

1-4-2-1 Set the SMS Delivery Pending Flag for this MS.

1-4-2-2 Include the SMS_AccessDeniedReason parameter set to Postponed .

1-4-3 ENDIF.

1-5 ENDIF.

1-X Include the MSID parameter set to the type of mobile station identifier

needed for SMS delivery.

1-6 Send a RETURN RESULT to the requesting VLR.

2 ELSE (the received message cannot be processed):

2-1 Send a RETURN ERROR with the proper Error Code value (see thefollowing table).

3 ENDIF.

4 Exit this task.

T a b l e 5 9 MSC SMSRequest Response




A-4DMisanoEnmens(19


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


4. 49 .1 MSC Initiating a Transfer-To-Number Request(TIA/EIA-41-D Chapter 6, page 6-296)


4. 49 .2 HLR Receiving TransferToNumberRequest INVOKE(TIA/EIA-41-D Chapter 6, page 6-298)


Tab le 6 0 HLR TransferToNumberRequest Response


4. 54 .2 MSC Receiving UnsolicitedResponse INVOKE(TIA/EIA-41.6-D , page 305)


Ta bl e 62 Neighboring MSC UnsolicitedPageResponse Response


5.1 .3 HLR CD Incoming Call Invocation(TIA/EIA-41-D Chapter 6, page 6-309, line 2)


5.8. 2 HLR CNIP Redirecting Call Invocation(TIA/EIA-41-D Chapter 6, page 6-333)


5.8 .4 MSC CNIP Terminating Call Invocation(TIA/EIA-41-D Chapter 6, page 6-334)





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


5. 13 .6 HLR MWN Status Change Invocation(TIA/EIA-41.6-D page 6-350)


5. 13 .7 MSC MWN Call Origination Invocation(TIA/EIA-41.6-D page 6-351)


5. 13 .8 MSC MWN Call Termination Invocation(TIA/EIA-41.6-D page 6-351)


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.



A-4DMisanoEnmens(19


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




5. 16 .1 HLR PL Language Registration(TIA/EIA-41.6-D page 6-201)

Upon request, the HLR shall do the following:

1 IF PL Variable Registration is authorized:

1-1 IF the language is acceptable:

1-1-1 Register the preferred language.

1-1-X IF an announcement is required:

1-1-X-1 Include the Announcemen tCode parameter in the

AnnouncementList parameter set to an appropriate announcement.

1-1-X-2 Include the PreferredLanguageIndicator parameter set to the preferred

language.

1-1-Y ENDIF.

1-1-2 Optionally, include the AnnouncementCode parameter in theAnnouncementList parameter set to an appropriate announcement.

1-1-3 Include the FeatureResult parameter set to Successful to indicatesuccessful feature operation.

1-2 ELSE:

1-2-1 Optionally, include the AnnouncementCode parameter in theAnnouncementList parameter set to an appropriate announcement.


5. 18 .1 HLR RFC Incoming Call Invocation(TIA/EIA-41.6-D page 6-369, line 32)


5. 19 .7 HLR SCA Incoming Call Invocation(TIA/EIA-41-D Chapter 6, page 6-379, line 36)




A-4DMisanoEnmens(19


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




5. C3. 2 MSC Receiving SMDPP INVOKE for OTASP or

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:


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):





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


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 MSC Procedure Triggers for OTASP

5. C4 .1 OTAF Initiating SMDPP INVOKE for MSRegistration

(TIA/EIA/IS-725-A, page 6-201)

When triggered (the trigger must include the newly assigned MSID value), the OTAFshall do the following:

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 the MIN or IMSI_M has been assigned:

a-1 Include the NewlyAssignedMIN parameter set to the MIN5 value.

a-2 IF the IMSI_M has been assigned:

a-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.

a-3 ENDIF.

b ENDIF.

c IF the IMSI has been assigned:

c-1 Include the NewlyAssignedIMSI parameter set to the IMSI value.

d ENDIF.

u IF CDMA OTASP Service:

u-1 Include the MobileIdentificationNumber parameter set to theActivation_MIN value.

v ENDIF.

x IF CDMA OTAPA Service:

x-1 IF the MS has MIN at the start of the session:

x-1-1 Include the MobileIdentificationNumber parameter set to the MS'sMIN.

x-2 ELSE:

x-2-1 Include the IMSI parameter set to the MS's IMSI.x-3 ENDIF.

5If the IMSI_M has been assigned, the IMSI_M_S is used as the MIN value.



A-4DMisanoEnmens(19


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


y 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 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-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:


14 ENDWAIT.

15 Exit this task.

TR45.2.2/99.08.16#12; [GTE];


5. C4. 2 MSC Receiving SMDPP INVOKE for Registration ofM S


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-1 IF the OTASPCallEntry is found OR (IF the ServiceIndicator parameterindicates CDMA OTAPA Service AND IF an OTAPA session is active):




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-1-1 Record the received NewlyAssignedMIN or NewlyAssignedIMSI orboth value(s).

1-1-x IF a NewMINExtension is received:

1-1-x-1 Record the received IMSI_M_CLASS, IMSI_M_ADDR_NUM,

MCC_M, and IMSI_M_11_12 values.

1-1-y ENDIF.

1-1-a IF a successful registration had occurred with the old MSID:

1-1-a-1 Execute “MSC initiating an MS Inactive” task (see 4.30.1).

1-1-a-2 IF the previous task was unsuccessful:

1-1-a-2-1 Set the SMS_CauseCode to indicate Other Network Problem.

1-1-a-3 ENDIF.

1-1-b ENDIF.

1-1-2 Execute “MSC Initiating MS Registration” task (see 4.38.1).

1-1-3 IF the previous task was unsuccessful:

1-1-3-1 Set the SMS_CauseCode to indicate Other Network Problem.

1-1-4 ELSE:

1-1-4-1 Include the AuthorizationDenied parameter if received.

1-1-5 ENDIF.

1-1-9 Include SMS_CauseCode parameter if set during this procedure.

1-2 ELSE:

1-2-1 Send an SMDPP RETURN RESULT to the OTAF wit hSMS_CauseCode parameter set to indicate Session not active

1-3 ENDIF.

2 ELSE (message can not be processed):

2-1 Include the SMS_CauseCode parameter set to the proper value.

3 ENDIF.

4 Send the SMDPP RETURN RESULT to the requesting OTAF.

5 Exit this task.



A-4DMisanoEnmens(19


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


TR45.2.2/99.08.16#12; [GTE];


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.




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


x ENDIF.

8 Send an SMDPP INVOKE to the Serving MSC.

9 Start the SMDPP timer (SMTcs).

10 WAIT for an SMDPP response:


11-1 Stop the timer (SMTcs).

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-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).


13 WHEN the timer (SMTcs) expires:


14 ENDWAIT.

15 Exit this task.

TR45.2.2/99.08.16#12; [GTE];


5. C4. 4 MSC Receiving SMDPP INVOKE to Record NEWMS ID


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-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:



A-4DMisanoEnmens(19


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-1-x-1 Record the received IMSI_M_CLASS, IMSI_M_ADDR_NUM,

MCC_M, and IMSI_M_11_12 values.

1-1-y ENDIF.

1-1-3 IF NewlyAssignedIMSI is received:

1-1-3-1 Record the received NewlyAssignedIMSI value.

1-1-4 ENDIF.

1-2 ELSE:

1-2-1 Send an SMDPP RETURN RESULT to the OTAF wit hSMS_CauseCode parameter set to indicate Session not active.

1-3 ENDIF.

2 ELSE (message can not be processed):

2-1 Include the SMS_CauseCode parameter set to the proper value.

3 ENDIF.

4 Send the SMDPP RETURN RESULT to the requesting OTAF.

5 Exit this task.



A-4DMisanoEnmens(19


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


TR45.2.3/99.08.19#16; [Ericsson]


D ANNEX D: SMS Air Interface Delivery Point-to-Point



T a b l e 6 4 SMD-REQUEST P arameters

SMD-REQUEST Parameters Timer: SADT orSAOT

Field Type Notes

Contents

ElectronicSerialNumber M a

• • • • • • • • •

OriginalOriginatingSubaddress O eTransactionID O h

Notes:

a. Include to identify the MS on the air interface.


e. Include if applicable.


h. Include if SMS origination initiated by the MS, for TDMA.

T a b l e 6 5 SMD-ACK Parameters

SMD-ACK Parameters

Field Type Notes

Contents

BearerData O a

TransactionID O b

Notes:

a. Include if applicable.

b. Include if SMS origination initiated by the MS, for TDMA.




A-4DMisanoEnmens(19


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


TR45.2.3/98.08.19#16; [Ericsson]


D. 5 Serving MSC Receiving an SMD-REQUEST(TIA/EIA-41-D Chapter 6, page 6-416)


13 IF the OriginalOriginationSubaddress parameter is supplied:

13-1 Set the original origination subaddress to the OriginalOriginationSubaddressparameter.

14 ENDIF.

X Set the transaction identification to the TransactionID parameter.

15 IF the MSC is the Anchor MSC for the indicated MS:

15-1 Execute the “Anchor MSC Initiating SMS Delivery Point-To-Point” task (see 4.46.5).


TR45.2.3/98.08.19#16; [Ericsson]





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


Editor’s Note: event definition text has not been received for Figures “X+0” thru “x+5”.

4. APPENDIX

SMDPPACK [SMS_TransactionID]

smdpp [ACK]

SMDPP

SMD-REQ [SMS_TransactionID]a

b

c

e

f

Destination

Home

System

MSCMC

Anchor

System

MS

SME

Origination

MSC

New

Serving

System

SAOT SMT

SMD-ACK [SMS_TransactionID]

B A

c

dhandoff

Figure x+0 Short Message from MS-Based SME in AnchorSystem and Acknowledged in new Serving System after

Handoff




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


SMDPP

a

b

c

d

e

g

Destination

Home

System

MSCMC

Anchor

System

MSSME

Origination

MSCMSC

Initial

Serving/

Tandem

System

New

Serving

System

SAOT SBT

B A

smdpp [ACK]

h

SMDPPACK [SMS_TransactionID]

smdback [SMS_TransactionID]

SMDBACK [SMS_TransactionID]

SMD-REQ [SMS_TransactionID]


SMT

fhandoff

Figure x+2 Short Message from MS-Based SME in Tandem System andAcknowledged in new Serving System after Handoff (via

Tandem System)



A-4DMisanoEnmens(19


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



smdpp [ACK]

SMDPP



b

c

d

f

Destination

Home

System

MSCMC

Anchor

System

MSSME

Origination

MSC

Initial

Serving

System

SAOT SMT

B A

handoffe

Figure x+3 Short Message from MS-Based SME in Serving System andAcknowledged in Anchor System after Handoff Back




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



smdpp [ACK]

SMDPP




b

c

d

e

g

Destination

Home

System

MSCMC

Anchor

System

MSSME

Origination

MSCMSC

Initial

Tandem

System

Initial

Serving

System

SAOT SMT

B A

handoff f

Figure x+4 Short Message from MS-Based SME in Serving System andAcknowledged in Anchor System after Handoff Back (via a

Tandem System)



nmens(19


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

smdpp [ACK]

SMDPP



b

c

Destination

Home

System

MSCMC MSSME

Origination

MSCMSC

SAOT SBT SMT smdpp [ACK]

SMDPP

a

b

c

Destination

Home

System

MSCMC

Anchor

System

MSSME

Origination

MSCMSC

SAOT SBT SMT

dd

Initial

Serving

System

New

Serving

System

B A

3gpp2 n.s0015 version 1.0.0 version date: january

Documents