17695597-Layer-3-Messages.pdf

Call Phases

© Network Optimisation Call Phases Training document

Copyright © by

 NOKIA. This Document is for training purposes only - no update service Number/Version

Checked by

NTCD TSG 0073 en/1.0

Approved by

Page

Nov-96/MKo/ThB

Nov-96/JNi

Contents 1. Mobile Originated Call 2. Mobile Terminated Call

1(39)

3. Messages in MOC and MTC

3.1. PAGING 3.2. PAGING_COMMAND 3.3. PAGING_REQUEST 3.4. CHANNEL_REQUEST 3.5. CHANNEL_REQUIRED 3.6. CHANNEL_ACTIVATION 3.7. CHANNEL_ACTIVATION_ACK  3.8. IMMEDIATE_ASSIGNMENT_COMMAND 3.9. IMMEDIATE_ASSIGNMENT 3.10. CM_SERVICE_REQUEST 3.11. ESTABLISH_INDICATION 3.12. CR (CM_SERVICE_REQUEST) 3.13. UA 3.14. PROCESS_ACCESS_REQUEST 3.15. AUTHENTICATE 3.16. CC (AUTHENTICATION_REQUEST) 3.17. AUTHENTICATION_REQUEST to MS 3.18. AUTHENTICATION_RESPONSE 3.19. DT1 (AUTHENTICATION_RESPONSE) 3.20. AUTHENTICATION_RESPONSE to VLR  3.21. SET_CIPHERING_MODE 3.22. DT1 (CIPHERING_MODE_COMMAND) 3.23. ENCRYPTION_COMMAND 3.24. CIPHERING_MODE_COMMAND to MS 3.25. CIPHERING_MODE_COMPLETE 3.26. DT1 (CIPHERING_MODE_COMPLETE) to MSC 3.27. ACCESS_REQUEST_ACCEPTED 3.28. FORWARD_NEW_TMSI 3.29. TMSI_REALLOCATION_COMMAND to BSC 3.30. TMSI_REALLOCATION_COMMAND to MS 3.31. TMSI_REALLOCATION_COMPLETE to BSC 3.32. TMSI_REALLOCATION_COMPLETE to MSC 3.33. TMSI_ACK  3.34. SETUP to BSC 3.35. DT1 (SETUP to MSC) 3.36. SEND_INFO_FOR_OG_CALL 3.37. COMPLETE_CALL 3.38. DT1 (CALL_PROCEEDING to BSC) 3.39. CALL_PROCEEDING to MS 3.40. ASSIGNMENT_REQUEST 3.41. PHYSICAL_CONTEXT_REQUEST 3.42. PHYSICAL_CONTEXT_CONFIRM 3.43. CHANNEL_ACTIVATION 3.44. CHANNEL_ACTIVATION_ACK.

3. Messages in MOC and MTC

3.1. PAGING 3.2. PAGING_COMMAND 3.3. PAGING_REQUEST 3.4. CHANNEL_REQUEST 3.5. CHANNEL_REQUIRED 3.6. CHANNEL_ACTIVATION 3.7. CHANNEL_ACTIVATION_ACK  3.8. IMMEDIATE_ASSIGNMENT_COMMAND 3.9. IMMEDIATE_ASSIGNMENT 3.10. CM_SERVICE_REQUEST 3.11. ESTABLISH_INDICATION 3.12. CR (CM_SERVICE_REQUEST) 3.13. UA 3.14. PROCESS_ACCESS_REQUEST 3.15. AUTHENTICATE 3.16. CC (AUTHENTICATION_REQUEST) 3.17. AUTHENTICATION_REQUEST to MS 3.18. AUTHENTICATION_RESPONSE 3.19. DT1 (AUTHENTICATION_RESPONSE) 3.20. AUTHENTICATION_RESPONSE to VLR  3.21. SET_CIPHERING_MODE 3.22. DT1 (CIPHERING_MODE_COMMAND) 3.23. ENCRYPTION_COMMAND 3.24. CIPHERING_MODE_COMMAND to MS 3.25. CIPHERING_MODE_COMPLETE 3.26. DT1 (CIPHERING_MODE_COMPLETE) to MSC 3.27. ACCESS_REQUEST_ACCEPTED 3.28. FORWARD_NEW_TMSI 3.29. TMSI_REALLOCATION_COMMAND to BSC 3.30. TMSI_REALLOCATION_COMMAND to MS 3.31. TMSI_REALLOCATION_COMPLETE to BSC 3.32. TMSI_REALLOCATION_COMPLETE to MSC 3.33. TMSI_ACK  3.34. SETUP to BSC 3.35. DT1 (SETUP to MSC) 3.36. SEND_INFO_FOR_OG_CALL 3.37. COMPLETE_CALL 3.38. DT1 (CALL_PROCEEDING to BSC) 3.39. CALL_PROCEEDING to MS 3.40. ASSIGNMENT_REQUEST 3.41. PHYSICAL_CONTEXT_REQUEST 3.42. PHYSICAL_CONTEXT_CONFIRM 3.43. CHANNEL_ACTIVATION 3.44. CHANNEL_ACTIVATION_ACK.

3.45. ASSIGNMENT_COMMAND 3.46. SABM (Set Asynchronous Balanced Mode) 3.47. ESTABLISH_INDICATION 3.48. UA 3.49. ASSIGNMENT_COMPLETE to BSC 3.50. DT1 (ASSIGNMENT_COMPLETE to MSC) 3.51. CHANNEL_RELEASE 3.52. CHANNEL_RELEASE_ACK. 3.53. ALERTING to BSC 3.54. ALERTING to MS 3.55. DT1 (CONNECT to BSC) 3.56. CONNECT to MS 3.57. CONNECT_ACK to BSC 3.58. DT1 (CONNECT_ACK to MS) 3.59. MEASUREMENT_REPORT 3.60. MEASUREMENT_REPORT/RESULT 3.61. DISCONNECT to BSC 3.62. DT1 (DISCONNECT to MSC) 3.63. DT1 (RELEASE to BSC) 3.64. RELEASE to MS 3.65. RELEASE_COMPLETE to BSC 3.66. DT1 (RELEASE_COMPLETE to MS) 3.67. CLEAR_COMMAND 3.68. CHANNEL_RELEASE 3.69. DEACTIVATE_SACCH 3.70. DISC 3.71. UA 3.72. RELEASE_INDICATION 3.73. RF_CHANNEL_RELEASE 3.74. RF_CHANNEL_RELEASE_ACK. 3.75. CLEAR_COMPLETE 3.76. SCCP_RELEASED 3.77. SCCP_RELEASED _ACK  4. BSC Internal Handover, inter cell

4.1. MEASUREMENT_REPORT 4.2. MEASUREMENT_REPORT/RESULT 4.3. CHANNEL_ACTIVATION 4.4. CHANNEL_ACTIVATION_ACK. 4.5. HO_COMMAND from BSC to BTS1 4.6. HO_COMMAND to MS 4.7. HO_ACCESS 4.8. HO_DETECT 4.9. PHYSICAL_INFO 4.10. SABM 4.11. ESTABLISH_INDICATION

4.12. UA 4.13. HO_COMPLETE 4.14. RR  4.15. HO_COMPLETE 4.16. HO_PERFORMED 4.17. RF_CHANNEL_RELEASE 4.18. RF_CHANNEL_RELEASE_ACK. 5. References

1. Mobile Originated Call ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ MS │ │ BTS │ │ BSC │ │ MSC │ │ VLR │ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ │ │ │ │ │ │ │ │ │ │ │ │ ************************* │ │ │ │ │ │ * RADIO ACCESS PART * │ │ │ │ │ │ ************************* │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │CHANNEL_REQUEST(RACH) │ │ │ │ │ │ │1 ├─────────>┤ │ │ │ │ │ │ │ │ │ │ │CHANNEL_REQUIRED │ │ │ │ │ │ │2 ├─────────>┤---------------------------------S DCCH S EIZ  A TT 

│

│

│

│CHANNEL_ACTIVATION

│

│

│

│ S DCCH B USY 

│

│

├<─────────┤3 │

│

│

│

│ G HOST C CCH 

│ │ │ │

│ │CHANNEL_ACTIVATION_ACK. │ │ │ │ │4 ├─────────>┤ │ │ │ │ │ │ │IMMEDIATE_ASSIGNMENT_COMMAND │ │ │ ├<─────────┤5-------------------------------

 A TT 

│ R ES 

│ │ │

│

-S DCCH_ A SSIGN  │ │IMMEDIATE_ASSIGN(AGCH) │ │ │ ├<─────────┤6 │ │ │ │ │ │ │ │ │ │ │ ************************** │ │ * ESTABLISHMENT PART * │ │ ************************** │ │ │ │ │ │ │ │CM_SERVICE_REQUEST(SDCCH) │

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

│7 ├─────────>┤ │ │ │ │ │ │ │ │ │ │ │ESTABLISH_INDICATION │ │ │ │ │ │ │8 ├─────────>┤--------------------------------S UCC  S EIZ O RIG 

│

│

│

│

│

│CR(CM_SERVICE_REQUEST)

│

│ S UCC  S EIZ

│

│

│

│9 ├─────────>┤

│UA(SDCCH) │

│

│

│

│

├<─────────┤10│

│

│

│

│

│

│ S UCC  S DCCH 

│

│

│

│

│

│ U NS. S DCCH 

T ERM 

│

│

│

│ S DCCH  C ALL

R E E ST 

│

│

│

│ S DCCH  E MERG 

C ALL

│

S MS E ST 

│

│

│

│

S MS E ST 

│

│

│

│

│

│

PROCESS_ACCESS_REQUEST│

│ S DCCH LOC 

UPD 

│ │ │ │ │ │ │11├─────────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │ *********************************** │ │ │ │ * CIPHERING & ENCRYPTION PART * │ │ │ │ * CALL SETUP * │ │ │ │ *********************************** │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ AUTHENTICATE│ │ │ │ │ │ │ │ │ ├<─────────┤12│ │ │ │ │ CC(AUTHENTICATION_REQUEST) │ │ │ │ │ │ │ ├<─────────┤13│ │ │ │ │AUTHENTICATION_REQUEST(SDCCH) │ │ │ │ │ ├<─────────┼──┼──────────┤14│ │ │ │ │ │ │AUTHENTICATION_RESPONSE(SDCCH) │ │ │ │ │15├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ DT1(AUTHENTICATION_RESPONSE)│ │ │ │ │ │ │16├─────────>┤ │ │ │ │ │ │ │ │ │ AUTHENTICATION_RESPONSE│ │ │ │ │ │ │ │ │17├─────────>┤ │ │ │ │ │ │ │ SET_CIPHERING_MODE│ │ │ │ │ │ │ │ │ ├<─────────┤18│ │ │ │ │ │DT1(CIPHERING_MODE_COMMAND)│ │ │ │ │ │ │ ├<─────────┤19│ │ │ │ │ │ │ENCRYPTION_COMMAND │ │ │ │ │ │ │ ├<─────────┤20│ │ │ │ │ │ │CIPHERING_MODE_COMMAND(SDCCH) │ │ │ │

│ ├<─────────┤21│ │ │ │ │ │ │ │ │CIPHERING_MODE_COMPLETE(SDCCH) │ │ │ │ │22├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ DT1(CIPHERING_MODE_COMPLETE)│ │ │ │ │ │ │23├─────────>┤ │ │ │ │ │ │ │ │ │ ACCESS_REQUEST_ACCEPTED│ │ │ │ │ │ │ │ │ ├<─────────┤24│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ MS │ │ BTS │ │ BSC │ │ MSC │ │ VLR │ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ │ │ │ │ │ │ FORWARD_NEW_TMSI│ │ │ │ │ │ │ │ │ ├<─────────┤25│ │ │ │ │ │ TMSI_REALLOCATION_COMMAND│ │ │ │ │ │ │ ├<─────────┤26│ │ │ │ │TMSI_REALLOCATION_COMMAND │ │ │ │ │ │ ├<─────────┼──┼──────────┤27│ │ │ │ │ │ │TMSI_REALLOCATION_COMPLETE │ │ │ │ │ │28├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ │ TMSI_REALLOCATION_COMPLETE│ │ │ │ │ │ │29├─────────>┤ │ │ │ │ │ │ │ │ │ │ │TMSI_ACK │ │ │ │ │ │ │ │ │30├─────────>┤ │ │ │SETUP(SDCCH) │ │ │ │ │ │ │ │31├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ │ │DT1(SETUP)│ │ │ │ │ │ │ │ │32├─────────>┤ │ │ │ │ │ │ │ │ │ SEND_INFO_FOR_OG_CALL│ │ │ │ │ │ │ │ │33├─────────>┤ │ │ │ │ │ │ │ │COMPLETE_CALL│ │ │ │ │ │ │ │ │ ├<─────────┤34│ │ │ │ │ │ │DT1(CALL_PROCEEDING) │ │ │ │ │ │ │ ├<─────────┤35│ │ │ │ │CALL_PROCEEDING(SDCCH) │ │ │ │ │ │ │ ├<─────────┼──┼──────────┤36│ │ │ │ │ │ │ │ │ │ │DT1(ASSIGNMENT_REQUEST) │ │ │ │ │ │ │ ├<─────────┤37│ │ │ │ │ │ │PHYSICAL_CONTEXT_REQUEST│ │ │ │ │ │ │ ├<─────────┤38│ │ │ │ │ │ │ │ │PHYSICAL_CONTEXT_CONFIRM│ │ │ │ │ │ │39├─────────>┤---------------------------------T CH  R EQUEST 

│

│

│

│CHANNEL_ACTIVATION

│

│

│

├<─────────┤40│

│

│

│

│

T CH  N ORM 

S EIZ

│

│

│

│

T CH R EQ R EJ L ACK 

│ │

│ │ │

│ │CHANNEL_ACTIVATION_ACK. │ │41├─────────>┤ │ │ │ASSIGNMENT_COMMAND(SDCCH) │

│ │ │

│ │ │

│ │

+ A_BSC 

│

│

│ ├<─────────┼──┼──────────┤42│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ****************** │ │ │ │ │ │ │ * TCH SEIZED * │ │ │ │ │ │ │ ****************** │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │SABM(FACCH) │ │ │ │ │ │ │ │43├─────────>┤ │ │ │ │ │ │ │ │ │ │ │ESTABLISH_INDICATION │ │ │ │ │ │ │44├─────────>┤ │ │ │ │ │ │ │UA(FACCH) │ │ │ │ │ │ │ │ │ ├<─────────┤45│ │ │ │ │ │ │ │ │ASSIGNMENT_COMPLETE(FACCH) │ │ │ │ │ │46├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ │ │DT1(ASSIGNMENT_COMPLETE)│ │ │ │ │ │ │47├─────────>┤------------------------ A_MSC  │ │ │ │CHANNEL_RELEASE │ │ │ │ │ │ │ ├<─────────┤48│ │ │ │ │ │ │ │ │CHANNEL_RELEASE_ACK. │ │ │ │ │ │ │49├─────────>┤ │ │ │ │ │ │ │ │ │ │ │DT1(ALERTING)│ │ │ │ │ │ │ │ ├<─────────┤50│ │ │ │ │ALERTING(FACCH) │ │ │ │ │ │ │ ├<─────────┼──┼──────────┤51│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │DT1(CONNECT) │ │ │ │ │ │ │ │ ├<─────────┤52│ │ │ │ │CONNECT(FACCH) │ │ │ │ │ │ │ ├<─────────┼──┼──────────┤53│ │ │ │ │ │ │CONNECT_ACK.(FACCH) │ │ │ │ │ │ │54├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ │ │DT1(CONNECT_ACK.) │ │ │ │ │ │ │55├─────────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ MS │ │ BTS │ │ BSC │ │ MSC │ │ VLR │ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ │ │ **************************** │ │ │ │ │ │ * CONVERSATION PART * │ │ │ │ │ │ * LOGIGAL CHANNEL: TCH * │ │ │ │ │ │ **************************** │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │MEASUREMENT_REPORT(SACCH) │ │ │ │ │ │56├─────────>┤ │ │ │ │ │ │ │ │ │ │ │MEASUREMENT_REPORT/RESULT │ │ │ │ │ │57├─────────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ********************* │ │ │ │ │ │ * RELEASE BY MS * │ │ │ │ │ │ ********************* │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │DISCONNECT(FACCH) │ │ │ │ │ │ │58├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ │ │DT1(DISCONNECT) │ │ │ │ │ │ │59├─────────>┤ │ │ │ │ │ │ │ │ │DT1(RELEASE) │ │ │ │ │ │ │ │ ├<─────────┤60│ │ │ │ │RELEASE(FACCH) │ │ │ │ │ │ │ ├<─────────┼──┼──────────┤61│ │ │ │ │ │ │RELEASE_COMPLETE(FACCH) │ │ │ │ │ │ │62├──────────┼──┼─────────>┤ │ │ │ │ │ │ │ │ │ │ │DT1(RELEASE_COMPLETE) │ │ │ │ │ │ │63├─────────>┤--------------------B_MSC  │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │DT1(CLEAR_COMMAND) │ │ │ │ │ │ │ ├<─────────┤64│ │ │ │ │CHANNEL_RELEASE(FACCH) │ │ │ │ │ │ │ ├<─────────┼──┼──────────┤65│ │ │ │ │ │ │ │ │DEACTIVATE_SACCH │ │ │ │ │ │ │ ├<─────────┤66│ │ │ │ │ │ │DISC(FACCH) │ │ │ │ │ │ │ │67├─────────>┤ │ │ │ │ │ │ │ │ │UA(FACCH) │ │ │ │ │ │ │ │ │ ├<─────────┤68│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

2.

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

******************************│ │ │ │ * MS STARTS LISTENING TO *│ │ │ │ * BCCH AGAIN *│ │ │ │ ******************************│ │ │ │ │ │ │ │ │ │ │ │ │ │RELEASE_INDICATION │ │ │ │ │69├─────────>┤ │ │ │ │ │ │ │RF_CHANNEL_RELEASE │ │ │ │ │ ├<─────────┤70│ │ │ │ │ │ │RF_CHANNEL_RELEASE_ACK. │ │ │ │ │71├─────────>┤----------------------------------B_BSC  │ │ │ │DT1(CLEAR_COMPLETE) │ │ │ │ │72├─────────>┤ │ │ │ │ │ │ │RLSD(SCCP_RELEASED) │ │ │ │ │ ├<─────────┤73│ │ │ │ │ │ │RLC(SCCP_RELEASED_ACK.) │ │ │ │ │74├─────────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

Mobile Terminated Call

┌─────────┐ │ MS │ └──┬──┬───┘ │ │

┌─────────┐ ┌─────────┐ │ BTS │ │ BSC │ └──┬──┬───┘ └──┬──┬───┘ ******************* │ │

┌─────────┐ │ MSC │ └──┬──┬───┘ │ │

│ │ │ │ │ │ │ │ │ │ │ │ │4 │ │

│ * PAGING PART * │ │ │ │ │ ******************* │ │ │ │ │ │ │ │ │UDT(PAGING) │ │ │ │ │ │ ├<─────────────┤1 │ │ │ │PAGING_COMMAND│ │ │ │ │ │ ├<─────────────┤2 │ │ │ │PAGING_REQUEST(PCH) │ │ │ │ ├<─────────────┤3 │ │ │ │ │ │ ************************* │ │ │ * RADIO ACCESS PART * │ │ │ ************************* │ │ │CHANNEL_REQUEST(RACH) │ │ │ │ ├─────────────>┤ │ │ │ │ │ │ │ │CHANNEL_REQUIRED │ │ │ │ │5 ├─────────────>┤---------------------- S DCCH S EIZ

 A TT 

│

│

│

│CHANNEL_ACTIVATION

│

│ S DCCH B USY 

│

│

├<─────────────┤6 │

│

│ G HOST C CCH 

│ │ │ │

│ │7 │ │

│CHANNEL_ACTIVATION_ACK. │ │ ├─────────────>┤ │ │ │ │IMMEDIATE_ASSIGNMENT_COMMAND │ │ ├<─────────────┤8--------------------- S DCCH 

 A TT 

│ R ES 

│ │ │ │

 A SSIGN 

│ │IMMEDIATE_ASSIGNMENT(AGCH) │ │ │ │ │ ├<─────────────┤9 │ │ │ │ │ │ │ ************************** │ │ │ │ * ESTABLISHMENT PART * │ │ │ │ ************************** │ │ │ │SABM(PAGING_RESPONSE (SDCCH)) │ │ │ │ │10├─────────────>┤ │ │ │ │ │ │ │ │ │ESTABLISH_INDICATION │ │ │ │ │11├─────────────>┤---------------------- S UCC S EIZ O RIG 

│

│

│

│

CR(PAGING_RESPONSE)│

│

│

│

│12├─────────────>┤

│

│

│

│

S UCC S EIZ T ERM 

│

│

S DCCH C ALL R E E ST 

│

│UA(SDCCH)

S DCCH E MERG C ALL

│

│

│

│

├<─────────────┤13│

│

│

│

│ S UCC S DCCH 

│

│ SDCCH LOC 

S MS E ST 

│

│

***********************************

UPD 

│ │ * CIPHERING & ENCRYPTION PART * │ │ │ │ * CALL SETUP * │ │ │ │ *********************************** │ │ │ │ │ │ CC(AUTHENTICATION_REQUEST)│ │ │ │ │ │ │ ├<─────────────┤14│ │ │AUTHENTICATION_REQUEST(SDCCH) │ │ │ │ │ ├<─────────────┼──┼──────────────┤15│ │ │ │ │AUTHENTICATION_RESPONSE(SDCCH) │ │ │ │ │16├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ DT1(AUTHENTICATION_RESPONSE)│ │ │ │ │ │ │17├─────────────>┤ │ │ │ │ │ DT1(IDENTITY_REQUEST)│ │ │ │ │ │ │ ├<─────────────┤18│ │ │IDENTITY_REQUEST(SDCCH) │ │ │ │ │ ├<─────────────┼──┼──────────────┤19│ │ │

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ MS │ │ BTS │ │ BSC │ │ MSC │ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ │ │IDENTIFICATION_RESPONSE(SDCCH) │ │ │ │ │20├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ DT1(IDENTIFICATION_RESPONSE)│ │ │ │ │ │ │21├─────────────>┤ │ │ │ │ │ DT1(CIPHERING_MODE_COMMAND)│ │ │ │ │ │ │ ├<─────────────┤22│ │ │ │ │ENCRYPTION_COMMAND │ │ │ │ │ ├<─────────────┤23│ │ │ │ │CIPHERING_MODE_COMMAND(SDCCH) │ │ │ │ │ ├<─────────────┤24│ │ │ │ │ │ │CIPHERING_MODE_COMPLETE(SDCCH) │ │ │ │ │25├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ DT1(CIPHERING_MODE_COMPLETE)│ │

│ │ │ │ │26├─────────────>┤ │ │ │ │ │ │ │DT1(SETUP) │ │ │ │ │ │ │ ├<─────────────┤27│ │ │SETUP(SDCCH) │ │ │ │ │ │ │ ├<─────────────┼──┼──────────────┤28│ │ │ │ │CALL_PROCEEDING(SDCCH) │ │ │ │ │29├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ DT1(CALL_PROCEEDING)│ │ │ │ │ │ │30├─────────────>┤ │ │ │ │ │ DT1(ASSIGNMENT_REQUEST)│ │ │ │ │ │ │ ├<─────────────┤31│ │ │ │ │PHYSICAL_CONTEXT_REQUEST │ │ │ │ │ ├<─────────────┤32│ │ │ │ │ │ │PHYSICAL_CONTEXT_CONFIRM │ │ │

│

│33├─────────────>┤------------------------- T CH 

R EQUEST 

│

│

│

│CHANNEL_ACTIVATION

│

│

│

├<─────────────┤34│

│

│

│ │

│ │

T CH R EQ 

R EJ L ACK 

│

│

T CH N ORM S EIZ

│ │

│ │

│ │CHANNEL_ACTIVATION_ACK. │35├─────────────>┤ │

+

A_BSC 

│

│ASSIGNMENT_COMMAND(SDCCH)

│

│

│

│ │ ├<─────────────┼──┼──────────────┤36│ │ │ │ │ ****************** │ │ │ │ │ │ * TCH SEIZED * │ │ │ │ │ │ ****************** │ │ │ │ │ │SABM(FACCH) │ │ │ │ │ │ │37├─────────────>┤ │ │ │ │ │ │ │ │ │ESTABLISH_INDICATION │ │ │ │ │38├─────────────>┤ │ │ │ │ │UA(FACCH) │ │ │ │ │ │ │ ├<─────────────┤39│ │ │ │ │ │ │ASSIGNMENT_COMPLETE(FACCH) │ │ │ │ │40├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ DT1(ASSIGNMENT_COMPLETE)│ │ │ │ │ │ │41├─────────────>┤------- A_MSC  │ │ │ │CHANNEL_RELEASE │ │ │ │ │ │ ├<─────────────┤42│ │ │

│ │

│ │

│ │CHANNEL_RELEASE_ACK. │43├─────────────>┤ │

│ │

│ │

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ MS │ │ BTS │ │ BSC │ │ MSC │ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ └──┬──┬───┘ │ │ALERTING(FACCH) │ │ │ │ │ │44├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ │ │DT1(ALERTING) │ │ │ │ │ │ │45├─────────────>┤ │ │ │CONNECT(FACCH)│ │ │ │ │ │ │46├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ │ │DT1(CONNECT) │ │ │ │ │ │ │47├─────────────>┤ │ │ │ │ │ │DT1(CONNECT_ACK.)│ │ │ │ │ │ │ ├<─────────────┤48│ │ │CONNECT_ACK.(FACCH) │ │ │ │ │ ├<─────────────┼──┼──────────────┤49│ │ │ │ │ **************************** │ │ │ │ * CONVERSATION PART * │ │ │ │ * LOGIGAL CHANNEL: TCH * │ │ │ │ **************************** │ │ │ │MEASUREMENT_REPORT(SACCH) │ │ │ │ │50├─────────────>┤ │ │ │ │ │ │ │ │ │MEASUREMENT_REPORT/RESULT │ │ │ │ │51├─────────────>┤ │ │ │ │ │ ********************* │ │ │ │ │ * RELEASE BY MS * │ │ │ │ │ ********************* │ │ │ │ │DISCONNECT(FACCH)│ │ │ │ │ │52├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ │ DT1(DISCONNECT)│ │ │ │ │ │ │53├─────────────>┤ │ │ │ │ │ │ │DT1(RELEASE) │ │ │ │ │ │ │ ├<─────────────┤54│ │ │RELEASE(FACCH)│ │ │ │ │ │ │ ├<─────────────┼──┼──────────────┤55│ │ │ │ │RELEASE_COMPLETE(FACCH) │ │ │ │ │56├──────────────┼──┼─────────────>┤ │ │ │ │ │ │ │ DT1(RELEASE_COMPLETE)│ │ │ │ │ │ │57├─────────────>┤------ B_MSC  │ │ │ │ DT1(CLEAR_COMMAND)│ │

│ │ │ │ │ ├<─────────────┤58│ │ │CHANNEL_RELEASE(FACCH) │ │ │ │ │ ├<─────────────┼──┼──────────────┤59│ │ │ │ │ │ │DEACTIVATE_SACCH │ │ │ │ │ │ ├<─────────────┤60│ │ │ │ │DISC(FACCH) │ │ │ │ │ │ │61├─────────────>┤ │ │ │ │ │ │ │UA(FACCH) │ │ │ │ │ │ │ ├<─────────────┤62│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ****************************** │ │ │ │ * MS STARTS LISTENING TO * │ │ │ │ * BCCH AGAIN * │ │ │ │ ****************************** │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │RELEASE_INDICATION │ │ │ │ │63├─────────────>┤ │ │ │ │ │ │ │RF_CHANNEL_RELEASE │ │ │ │ │ ├<─────────────┤64│ │ │ │ │ │ │RF_CHANNEL_RELEASE_ACK. │ │ │ │ │65├─────────────>┤------------------------- B_BSC  │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ DT1(CLEAR_COMPLETE)│ │ │ │ │ │ │66├─────────────>┤ │ │ │ │ │ RLSD(SCCP_RELEASED)│ │ │ │ │ │ │ ├<─────────────┤67│ │ │ │ │ RLC(SCCP_RELEASED_ACK.)│ │ │ │ │ │ │68├─────────────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

3.

Messages in MOC and MTC

1. PAGING The MSC sends the PAGING message (MTC/1) to the BSC. The PAGING message includes the following data: message type; IMSI;

-

TMSI; Cell identifier list; Channel needed.

The cell identifier list identifies the cells where the page should be sent. The BSC is able to handle all cell identifier types. If no cell identity is included, the mobile is paged in all cells controlled by the BSC. The existence of Channel needed depends on the MSC. If TMSI is used, for security reasons it has priority one but if TMSI is not used IMSI is included only in the paging message. 2. PAGING_COMMAND The BSC uses the IMSI value received in the PAGING message to calculate the mobile's  paging group and sends the PAGING COMMAND message (MTC/2) to the BTS. The idea of the calculation is to find out in which radio time slots the BTS can send the Paging Requests out towards the MS. This is because in the network is a possibility to have at least three different kind of BCCH-TRX -radio time slot configuration and thus logical channel PCH can have at least three different kind of location. If both TMSI and IMSI are included in the PAGING message, the TMSI is used. The PAGING COMMAND includes the following data: message header; paging group; MS Identity; Channel needed. If the mobile does not answer within a given time limit, the MSC repeats the paging command. 3. PAGING_REQUEST The BTS sends PAGING_REQUEST message (MTC/3) on a PCH channel. 4. CHANNEL_REQUEST The channel required procedure offers the mobile subscriber the means to start the establishment of a mobile originating call or the answering to the PAGING REQUEST message. The CHANNEL REQUEST message (MOC/1) is used by the MS for requesting a dedicated signalling channel SDCCH. It sends the CHANNEL REQUEST message to the BTS on the RACH. It is sent in random mode and consists of the following two fields: 1. establishment cause  possible establishment causes can be: answer for paging (mobile terminated call) emergency call

call re-establishment user requests (mobile originated call, short message service, supplementary services) or other services (location update, IMSI detach indication) 2. random reference selected by the MS. is 5 bits randomly selected by MS. The usage of random reference is when two MSs access the network exactly the same time, they can be separated by using the random reference. The network uses the random reference and the MS access slot number to identify and to address the MS. The MS starts the timer T3120 and waits for its access acceptance. If the MS access is not granted within the time limit defined by the T3120, the MS makes a new attempt and sends another CHANNEL REQUEST message with a new random reference on the next time slot. A new value of timer T3120 is computed and used. The MS repeats this process either  until it is granted access or until the maximum number is reached . 5. CHANNEL_REQUIRED By sending channel required (MOC/2) message to the BSC, BTS forwards the channel request generated by MS. In practice Channel Required contains the same information as channel reqUEST with additional information add by the BTS. The CHANNEL REQUIRED message from the BTS includes the following da ta: -

message discriminator: common channel management; message type: channel required; channel nr: uplink CCCH (RACH); request reference: establishment cause, random reference received in the access request and the frame number on which it was received; access delay: delay of the access burst as measured by the BTS.

After receiving the CHANNEL REQUIRED message, the BSC starts to search for a dedicated channel. If the channel is available in the cell where the original access came from, it is reserved and the immediate assignment procedure starts. In the normal Basic Call case, the target channel is SDCCH. After receiving the ASSIGNMENT REQUEST (MOC 37/MTC 31) from the MSC, the BSC starts to search for a TCH channel. If one is available in the cell comprising the SDCCH connection, it is reserved and the assignment procedure starts. If no channel is available, the channel request may be put to a queue and when a channel in this cell is released, it is reserved for the assignment procedure.

6. CHANNEL_ACTIVATION After a successful reservation of a new SDCCH channel, the BSC activates it by sending the CHANNEL ACTIVATION message (MOC/3) to the BTS. The GSM timer T9103 is used for supervising the channel activation procedure. The BSC can activate SDCCH channel. If the BTS refuses to activate the new channel, it sends the CHANNEL ACTIVATION  NACK message to the BSC with the reason for the failure.

The CHANNEL ACTIVATION message includes the following data: -

message discriminator: dedicated channel management; message type: channel activation; channel number; activation type; channel mode: DTX control and channel type; channel identification: channel description and mobile allocation; encryption information; BS power: maximum BS power level authorised in the cell; MS power: maximum MS power level authorised in the cell; timing advance to be used by MS in subsequent communications.

7. CHANNEL_ACTIVATION_ACK  A successful case is acknowledged by the BTS with the CHANNEL ACTIVATION ACK  message (MOC/4). The BTS starts the transmission and reception on the associated SACCH using the power levels and the timing advance received in the CHANNEL ACTIVATION message. A failure case is acknowledged by the BTS with the CHANNEL ACTIVATION NACK  message. The following failure cases are possible: error; -

Failure cause: radio resource not available; Failure cause: radio channel already activated/allocated; Failure cause: protocol error and subclause, such as mandatory information Failure cause: O&M intervention in cases when the channel cannot be used for   O&M reasons; Failure cause: ciphering algorithm not supported; Equipment failure; Service or option not available.

If the BSC does not receive the ACK/NACK message within the time limit of the timer  T9103 or if it has received the CHANNEL ACTIVATION NACK message, it releases the allocated channel by sending the procedure ASSIGNMENT FAILURE to the MSC.

8. IMMEDIATE_ASSIGNMENT_COMMAND After a successful SDCCH channel activation, the BSC sends the IMMEDIATE ASSIGN COMMAND message (MOC/5) to the BTS. This message contains the IMMEDIATE ASSIGN message which is sent by the BTS to the MS. The IMMEDIATE ASSIGN COMMAND message includes the following data: message header; message type; channel number. The Immediate Assign information contains the complete Immediate Assignment message: message header; page mode: normal paging; channel description of the SDCCH allocated and the associated SACCH and hopping frequency; request reference as sent by the MS in the Channel Request; initial timing advance; mobile allocation if frequency hopping is used; rest octet only for the GSM phase 2. 9. IMMEDIATE_ASSIGNMENT The BSS informs the MS on AGCH channel about the SDCCH channel to be used by using IMMEDIATE_ASSIGNMENT message (MOC/6). In practice, this message is an order from the network to the MS to move to the SDCCH -channel defined before. Page mode, SDCCH channel description, associated SACCH and hopping frequency are included as parameters. In addition, request reference (same as establishment cause), initial timing advance and frequency allocation if frequency hopping applies are also included. The GSM timer T3101 is used to supervise the immediate assign procedure. If the SDCCH channel reservation or activation has failed, the BSC sends the IMMEDIATE ASSIGN REJECT message to the MS. 10. CM_SERVICE_REQUEST After receiving the IMMEDIATE ASSIGNMENT message, the MS tunes to the assigned SDCCH and starts to establish the signalling link across the network. The MS sends the layer 2 SABM to the BTS on the SDCCH. The SABM (CM_SERVICE_REQUEST) message (MOC/7) contains a layer 3 service request message. The MS specifies the service type required to the network from the service reque st message. The service request message includes one of the following: 1. CM Service Request - for Mobile Originated calls and Mobile originated SMS header; CM service type: mobile originated call, short message service, supplementary services, emergency call;

-

Ciphering key sequence number; MS classmark 2; mobile identity.

2. Location Update Request 3. IMSI Detach Request 4. Paging Response - mobile terminated call or SMS mobile terminated: header; Ciphering key sequence number; MS classmark 2; mobile identity. 5. CM_Re-establishment Request

11. ESTABLISH_INDICATION The BTS forwards the MS service request to the BSC in the ESTABLISH INDICATION message (MOC/8) which includes the following data: -

message discriminator - radio link layer management; message type - establishment indication; channel number - SDCCH + AGCH; link identifier - main signalling channel SDCCH; L3 Information - complete L3 service request as received from the MS.

This message indicates that MS is now on the SDCCH-channel.

12. CR (CM_SERVICE_REQUEST) The SABM (CM_SERVICE_REQUEST) message (MOC/9) is forwarded to MSC. Then BSC starts to initiate signalling connection control part (SCCP) connection for the MS after receiving the ESTABLISH INDICATION message for the SDCCH establishment from the BTS. The GSM timer T9105 is used to supervise this procedure. If the SCCP link establishment fails, the BSC releases all resources related to this transaction. 13. UA The BTS acknowledges the SABM (CM_SERVICE_REQUEST) by sending the UA (ESTABLISH_INDICATION) frame (MOC/10) to the MS. The MS expects this acknowledgement within time defined by timer T3101; otherwise it acts as described in Rec 04.08, section 2.3.2. /1/.

UA is normal Layer 2 level acknowledgement when setting up the Layer 2 level link in LAPDm -protocol.

14. PROCESS_ACCESS_REQUEST MSC forwards MS's request for access management from VLR by PROCESS ACCESS REQUEST message (MOC/11). 15. AUTHENTICATE VLR initiates authentication request by sending an AUTHENTICATE message (MOC/12) to MSC. 16. CC (AUTHENTICATION_REQUEST) As a CC (Connection Confirmed) message, the MSC sends an AUTHENTICATION REQUEST message (MOC/13) to the BSC. Transparent messages are used in communication between the MS and the MSC. The message contains the RAND (random number). 17. AUTHENTICATION_REQUEST to MS The BSC forwards the AUTHENTICATION_REQUEST message (MOC/14) via the BTS to the MS. 18. AUTHENTICATION_RESPONSE The MS responds to the Authentication Request with the Signed Response number  (SRES). The AUTHENTICATION RESPONSE message (MOC/15) is sent to the BSC via the BTS. In the MS Authentication procedure A3 algorithmis used. In the SIM -card of the MS as well as in the Authentication Centre (AuC), A3 algorithm and a 32 -digit key (KI) are stored. When MS Authentication is requested by the network, AuC/VLR sends 32 -digit RANDom Number to the MS which calculates Signed Response (SRES) and returns it  back to the VLR. VLR compares if the received SRES is same than it has received from the AuC. AuC has also calculated SRES by using its own Authentication triplet If both SRESs are identical, MS is allowed to proceed the call setup. The first 8 digits of the KI are used for Authentication and SRES calculation. The other 24 digits are reserved for Ciphering Key (Kc) calculation. 19. DT1 (AUTHENTICATION_RESPONSE) Inside the AUTHENTICATION_RESPONSE message (MOC/16), the SRES value from the MS is forwarded back to the VLR via MSC in order to finalise authentication  procedure. This and all other messages in the A-interface up to the releasing of the SCCP connection are transmitted by using SCCP DT1 (Data Form 1) messages.

20. AUTHENTICATION_RESPONSE to VLR  MSC sends a positive response to Authenticate message (MOC/17). 21. SET_CIPHERING_MODE VLR sends MSC SET CIPHERING MODE message (MOC/18) which is used for   changing MS-BTS connection to ciphering status. Ciphering is one of the security procedures designed to protect the subscriber identity and data. It is an optional procedure in GSM. When ciphering is active, all information exchanged between the mobile and the network on the dedicated radio channels is encrypted. The key previously set between the network and the MS is used to encipher and to decipher the encrypted information. The ciphering key which is used is calcualted by the network and the MS by using Ki, RAND and algorithm A8. During the Authentication procedure in which the identity of the MS is checked to prevent unauthorised use, the ciphering key Kc is set between the network and the MS. Ciphering is initiated after the cipher key is set on the dedicated signalling channel - SDCCH/ FACCH. In an MSC controlled handover, the MSC will tell the new BSS whether encryption is required (in the HANDOVER REQUEST). In a BSC controlled Handover, the BSC will pass the encryption information to the target BTS on the activation of the channels if the encryption information was received from the MSC.

22. DT1 (CIPHERING_MODE_COMMAND) The CIPHER MODE COMMAND message (MOC/19) is sent from the MSC to the BSC to indicate whether ciphering is required and if so, to indicate the ciphering key. The command contains the encryption instruction and the L3 header information to the MS. When ciphering is required, the encryption information element contains information for  the BTS to load the encryption device with the appropriate key. The CIPHER MODE COMMAND (MSC->BSC) contains the following data: message type; layer 3 header information; encryption information: permitted algorithms and key; cipher response mode. 23. ENCRYPTION_COMMAND On receiving the CIPHER MODE COMMAND the BSC selects the algorithm to be used according to the permitted algorithm list of the message and the algorithms that are supported on that particular BSS. Regardless of whether ciphering is to be activated, the BSC stores the encryption information (including selected algorithm) for use in possible subsequent handovers and passes the encryption information to the BTS in the ENCRYPTION COMMAND message (MOC/20).

The ENCRYPTION COMMAND (BSC->BTS) contains the following data: message header; encryption information; selected algorithm and key. link identifier; L3 ciphering mode command to MS; message header; cipher mode setting: no ciphering/start ciphering; cipher response. The cipher response element is used if received from the MSC. The BTS analyses the ENCRYPTION command. If encryption is required, the BTS activates the demodulator to decipher. Regardless of whether ciphering is required, the BTS sends the CIPHER MODE COMMAND to the MS. 24. CIPHERING_MODE_COMMAND to MS The BSS informs the MS about beginning of ciphering by using the CIPHERING MODE COMMAND message (MOC/21). Afterwards BTS and MS use ciphered mode on the radio path. The MS starts to decipher and to encipher using its available ciphering key and returns to the BTS, in encrypted form, the CIPHER MODE COMPLETE message or the next message it is due to send. 25. CIPHERING_MODE_COMPLETE By sending the CIPHERING MODE COMPLETE message (MOC/22) the MS acknowledges ciphering command and BTS starts enciphering. The message includes IMEI if required by the MSC. 26. DT1 (CIPHERING_MODE_COMPLETE) to MSC If the CIPHER MODE COMPLETE (see Ref. /1/) message (MOC/23) received, it is forwarded to the BSC transparently, and onto the MSC. If the ciphering procedure fails, the MSC takes the appropriate action. 27. ACCESS_REQUEST_ACCEPTED VLR sends a positive acknowledge by using ACCESS REQUEST ACCEPTED message (MOC/24) to PROCESS ACCESS REQUEST message (11/3.14.) to MSC. 28. FORWARD_NEW_TMSI VLR requests MSC to perform TMSI reallocation by sending FORWARD NEW TMSI message (MOC/25).

29. TMSI_REALLOCATION_COMMAND to BSC

The purpose of the TMSI reallocation procedure is to provide identity confidentiality. Usually the TMSI reallocation is performed at least at each change of location area (LA). MSC initiates the TMSI reallocation procedure by sending TMSI Reallocation command message to the MS. TMSI REALLOCATION COMMAND message (MOC/26) contains a new combination of TMSI and LAI allocated by the network or a LAI and the IMSI if the used TMSI shall be deleted. Usually the TMSI REALLOCATION COMMAND message is sent to the MS by using a RR connection in ciphered mode. 30. TMSI_REALLOCATION_COMMAND to MS TMSI REALLOCATION COMMAND message (MOC/27) is forwarded from BSC to MS transparently for the BTS. 31. TMSI_REALLOCATION_COMPLETE to BSC When the MS receives the TMSI Reallocation Command message, it stores the LAI in the SIM. If the received identity is the IMSI of the MS, it deletes any previously stored TMSI. If the received identity is a TMSI, the MS stores it in the SIM. In both cases the MS send a TMSI REALLOCATION COMPLETE message (MOC/28) via BSS to MSC. 32. TMSI_REALLOCATION_COMPLETE to MSC TMSI REALLOCATION COMPLETE message (MOC/29) is forwarded from BSC to MSC. 33. TMSI_ACK  MSC sends TMSI ACK message (MOC/30) as an acknowledgement of the TMSI reallocation procedure to VLR 

34. SETUP to BSC After authentication -, identification - and ciphering procedure MS is ready to start real call setup signalling. The SETUP message (MOC/31) is forwarded to the MSC. The SETUP message contains e.g. the following data.: number of the called subscriber   type of the call (speech/data or alternate data and speech service). 35. DT1 (SETUP to MSC) The BSC sends the SETUP message (MOC/32) to the MSC in order to inform the MSC about the incoming call. 36. SEND_INFO_FOR_OG_CALL MSC requests VLR by sending SEND INFO FOR OG CALL message (MOC/33) if the calling subscriber is allowed to make a call to the dialled number. The restrictions will be

controlled. If correct conditions exist to continue the call setup, the VLR will send the COMPLETE_CALL message back to MSC.

37. COMPLETE_CALL CALL COMPLETION acknowledged (MOC/34) by VLR for MOC. If correct conditions exist, the calling subscriber is allowed to make a call to the dialled number  38. DT1 (CALL_PROCEEDING to BSC) The MSC responds to the SETUP message. The CALL PROCEEDING message (MOC/ 35) is sent by the called user to the network or by the network to the calling user to indicate that the requested call establishment has been initiated and no more call establishment information will be accepted.

39. CALL_PROCEEDING to MS When the call control entity of the MS receives a CALL PROCEEDING message (MOC/ 36), it enters the Mobile originated call proceeding" state. 40. ASSIGNMENT_REQUEST The ASSIGNMENT REQUEST message (MOC/37) from the MSC involves the following: The MSC sends an ASSIGNMENT REQUEST message to the BSC for the assignment of  channels on the A interface and the radio interface and runs a supervisory timer Trr1. If the MSC fails to receive any response from the BSS within timer Trr1, i.e., the ASSIGNMENT COMPLETE, the ASSIGNMENT FAILURE or the QUEUEING INDICATION message, the MSC is expected to clear the call with a CLEAR COMMAND message. The BSS releases the MS connection with channel release procedure. The following fields are expected by the BSC in the ASSIGNMENT REQUEST message: -

channel type: radio channel required for the call message type; L3 header info; priority (optional); circuit identity code indicating the channel to use on the A interface; downlink DTX flag (optional); radio channel identity (optional); interference band to use (optional).

Within the priority element, the MSC defines whether the request is allowed to be queued and if so, defines the queueing priority level.

If the request is allowed to be queued, the request will be queued according to the priority indicated. If the priority is not indicated, the message is queued according to the priority associated with the request type, defined internally within the BSS. If the priority element is not present, it is assumed that the request can be queued when the request cannot be served immediately. If the request is queued, a QUEUEING INDICATION is returned to the MSC. The downlink DTX flag is also optional and present only when the MSC wishes to control the downlink DTX in a speech call. On analysing the ASSIGNMENT REQUEST message, the BSC will reject the request with the ASSIGNMENT FAILURE message when any one of the following situations is identified without taking any action towards the BTS. On receiving the ASSIGNMENT FAILURE message, the MSC can either issue a CLEAR COMMAND or retry. 1. If the BSC is not able to use the A channel indicated in the CIC, due to its  being in use for another call, the BSC rejects the message with the cause "requested terrestrial circuit already allocated". 2. If the BSC is not able to use the A channel indicated in the CIC, due to its  being marked as undefined, the BSC rejects the message with the cause "requested terrestrial resource unavailable". 3.

If the CIC is blocked, the BSC rejects with the ASSIGNMENT FAILURE message with the cause "requested terrestrial resource unavailable" and sends a BLOCK message to the MSC. For reasons when a circuit is blocked by the BSC, cf. GSM 08.08, 3.1.2. /3/.

4. If the MSC receives the ASSIGMENT FAILURE message with a cause indicating a CIC problem, the MSC may choose to send another ASSIGNMENT REQUEST for the same call using a different circuit. 41. PHYSICAL_CONTEXT_REQUEST The BSC first sends the PHYSICAL CONTEXT REQUEST message (MOC/38) to the BTS. In this message it requests for the timing advance of mobile transmission used in the SDCCH required by the mobile to move onto the new radio channel.

42. PHYSICAL_CONTEXT_CONFIRM On receiving the PHYSICAL CONTEXT CONFIRM message (MOC/39) the BSC searches for the relevant TCH channel using channel reservation procedure described above (SDCCH). If the BSC fails to receive the PHYSICAL CONTEXT CONFIRM message within the T9108, or the message does not contain all the information expected, the BSC returns an

ASSIGNMENT FAILURE message to the MSC with the cause "equipment failure". The MSC either aborts with a CLEAR COMMAND or retries. If the request cannot be acted on because all radio channels are reserved, the queue is full, the request has been in the queue for too long, or because of exceptional conditions such as restart/reset, then the BSC returns an ASSIGNMENT FAILURE with the cause "no radio resource available". 43. CHANNEL_ACTIVATION After a successful channel reservation, the BSC sends a CHANNEL ACTIVATION message (MOC/40) to the BTS. In this message it tells the BTS to activate the radio channel required. The BSC also starts timer T9103. The Channel Activation message contains the following data: -

message type; channel number = Lm/Bm + AGCH; activation type = normal assignment; channel mode = DTX indication and channel type. The channel type is either a speech or data channel. If it is a speech channel, GSM speech encoding algorithm is included; if it is a data channel, the transparent or the nontransparent mode is included. The data rate is also given. channel identification = channel description and mobile allocation; encryption information if received from the MSC; BS power as received in the Physical Context Confirm; MS power as received in the Physical Context Confirm; Timing advance as received in the Physical Context Confirm. When the A-bis interface is on the GSM phase 2 level, channel identification is not used. Other optional elements are always present. The CHANNEL ACTIVATION NACK message is returned in the following situations from the BTS. The BSC indicates the failure to the MSC by sending the ASSIGNMENT FAILURE message with the relevant cause value, which can be one of the following: -

Message format error: Assignment Failure cause = Radio Interface Message Failure Service requested not supported: Assignment Failure cause = requested transcoding/rate adaptation not available Radio Channel problems: Assignment failure cause = radio resource not available Radio Channel already in use: Assignment Failure cause = radio channel already activated equipment failure

-

service or option not available

If no response is received from the BTS within the timer T9103, the BSC will send the MSC an ASSIGNMENT FAILURE message with the cause "equipment failure". The MSC either aborts or retries. 44. CHANNEL_ACTIVATION_ACK. When the BTS has successfully activated the radio TCH channel, it returns the CHANNEL ACTIVATION ACKNOWLEDGEMENT message (containing the current frame number) (MOC/41) to the BSC. 45. ASSIGNMENT_COMMAND The TCH radio channel assignment involves the following: The BSC sends the ASSIGNMENT COMMAND message (MOC/42) to the MS and starts timer T3107. This command is transparent to the BTS and is transferred as the DATA REQUEST message over the A-bis. The ASSIGNMENT COMMAND gives the MS all the information necessary for it to change over to the TCH. The message consists of: -

header   channel description power command - max. MS power   cell channel description channel mode - speech full rate or data mobile allocation

On receiving the Assignment Command over the Air Interface, the MS changes over from the SDCCH to the TCH it has been assigned to. After a successful assignment procedure, the BSC releases the SDCCH channe l. 46. SABM (Set Asynchronous Balanced Mode) The MS sends a layer 2 SABM on the TCH. The purpose of this message is the same as CM_SERVICE_REQUEST message (MOC/43) for SDCCH. 47. ESTABLISH_INDICATION The BTS acknowledges the SABM with a UA frame and sends the ESTABLISH INDICATION message (MOC/44) to the BSC. Synchronisation with the transcoder starts as described in Rec 08.60 /6/ and it is at this point that the BSC connects the A-bis to the A channel and the speech path is switched through. 48. UA

UA message (MOC/45) is normal Level 2 acknowledgement of SABM when setting up the Layer 2 level link in LAPDm-protocol. 49. ASSIGNMENT_COMPLETE to BSC The MS indicates to the BSC with an ASSIGNMENT COMPLETE message (MOC/46) that it has successfully changed over to the TCH. This message is transparent to the BTS and is transferred over the A-bis as a DATA INDICATION message. 50. DT1 (ASSIGNMENT_COMPLETE to MSC) The BSS acknowledges the channel seizure to the MSC. The information is sent to the MSC in the DT1(ASSIGNMENT COMPLETE) message (MOC/47) with the RR cause "normal release". 51. CHANNEL_RELEASE By sending CHANNEL RELEASE message (MOC/48) to the BTS the release procedure is started and the SDCCH channel is released. 52. CHANNEL_RELEASE_ACK. The BTS acknowledges the release of the SDCCH channel with CHANNEL RELEASE ACK message (MOC/49). 53. ALERTING to BSC The MSC sends an ALERTING message (MOC/50) via BSS. This message is sent by the called user to the MSC and by the MSC to the calling user to indicate that called user alerting has been initiated.. This message is transferred on FACCH channel. 54. ALERTING to MS The MSC informs the MS that the called subscriber has been alerted. If the MS receives the ALERTING message element (MOC/51), it shall through-connect the speech path. In case it is not through-connect, the MS generates ringing tone in itself. 55. DT1 (CONNECT to BSC) The MSC sends a CONNECT message (MOC/52) to the MS via the BSS. This message indicates the MS that a connection has been established through the network. 56. CONNECT to MS When the MS receives a CONNECT message (MOC/53), it attaches the user connection to the radio path, returns a CONNECT ACKNOWLEDGE message, stops any locally generated alerting indication (if applied) and enters the "active" state. This message is transferred on FACCH channel. 57. CONNECT_ACK to BSC

By using the CONNECT ACK message (MOC/54), the MS informs the MSC that the MS is now in the "active" state. This message is transferred on FACCH channel. 58. DT1 (CONNECT_ACK to MS) The CONNECT ACK message (MOC/55) is forwarded to the MSC. Now the conversation  part on TCH channel starts. 59. MEASUREMENT_REPORT When call is on, the MS sends MEASUREMENT REPORT message (MOC/56) concerning mainly the quality of the speech connection two times per second.

60. MEASUREMENT_REPORT/RESULT If these measurement reports are pre-processed in the BTS then measurement results are sent towards the BSC. If the is no pre-processing in the BTS, then MEASUREMENT REPORTS/RESULT (MOC/57) are sent. In this phase, Nokia BTS does not make any pre processing. BSC processes the measurements and decides on the handover algorithm (see /3/). If  thresholds have been triggered for the handover, the BSC generates the candidate cell list and starts the handover attempt. 61. DISCONNECT to BSC This request is sent by MS. Contents: clear end-to-end connection. This message stops the charging concerning this call connection. The DISCONNECT message (MOC/58) is transferred on FACCH channel. 62. DT1 (DISCONNECT to MSC) The DISCONNECT message (MOC/59) is forwarded to the MSC. 63. DT1 (RELEASE to BSC) Actual RELEASE (MOC/60) is coming from the MSC; real call is just about to end. 64. RELEASE to MS The RELEASE (MOC/61) message is forwarded to the MS. 65. RELEASE_COMPLETE to BSC MS informs that it will release the transaction identifier, i.e. call release is proceeding. This is done by sending RELEASE COMPLETE message (MOC/62). 66. DT1 (RELEASE_COMPLETE to MS) The RELEASE COMPLETE message (MOC/63) is forwarded to the MSC. 67. CLEAR_COMMAND

The channel release procedure is used for releasing a dedicated radio channel. The channel release procedure is started either by the BSC or the MSC. If the MSC starts the channel release procedure, it sends the CLEAR COMMAND message (MOC/64) to the BSC. On receiving the CLEAR COMMAND the BSC releases the A-interface speech circuit and sends the CLEAR COMPLETE message to the MSC. The MSC releases the SCCP connection. If the BSC starts the channel release procedure, it sends the CLEAR REQUEST message to the MSC and the MSC sends the CLEAR COMMAND message to the BSC. 68. CHANNEL_RELEASE After releasing the A-interface speech circuit the BSC sends to the MS a CHANNEL RELEASE message (MOC/65) with an RR cause value "Normal Release" . In case of  normal call setup case, the release cause is 'normal'. When the MS receives the CHANNEL RELEASE message it disconnects the signalling link by sending the DISC frame. 69. DEACTIVATE_SACCH By sending this message to downlink direction, the BSC inhibits system information message sending towards the MS. When the BTS receives the DEACTIVATE SACCH message (MOC/66), the transmission of SYSTEM INFORMATION messages on SACCH are inhibited. In fact, there is no use to send/receive any information in the SACCH channel any more, so it will be deactivated. The timer T31O9 is started in the BSC to supervise the procedure.

70. DISC The MS send Layer 2 frame DISConnect (MOC/67) to uplink direction in order to inform the BTS it is stopping the traffic in the TCH/FACCH. 71. UA After receiving the DISC frame, the BTS sends a UA message (MOC/68) to the MS and a RELEASE INDICATION message to the BSC. Consequences: the MS starts to listen BCCH -channel again and all Air interface resources are released. 72. RELEASE_INDICATION When the BSC receives the RELEASE INDICATION message (MOC/69) or the T3109 timer expires, the timer T3111 is started. The expire of this timer is waited for before sending the RF CHANNEL RELEASE. When the BSC receives the RELEASE INDICATION message the BTS informs the BSC that the MS has no more any dedicated Air interface resources (i.e. TCH/FACCH) in use. 73. RF_CHANNEL_RELEASE

When the BTS receives the RF CHANNEL RELEASE message (MOC/70), it releases this dedicated radio channel and sends the RF CHANNEL RELEASE ACK message to the BSC. 74. RF_CHANNEL_RELEASE_ACK. After receiving the RF RELEASE ACK message (MOC/71), the BSC releases all radio resource allocations. 75. CLEAR_COMPLETE The CLEAR COMPLETE message (MOC/72) is an acknowledgement to the message SCCP Data CLEAR COMMAND message (64/3.67.). Now the BSC informs the MSC that all radio resources related to this call are released. (SCCP = signalling connection control part) 76. SCCP_RELEASED When all radio resources are released, BSSAP connection concerning this call is not needed any more. The SCCP RELEASED message (MOC/73) tells the BSC to release this SCCP connection. The message is sent as RLSD message. 77. SCCP_RELEASED _ACK  BSC informs MSC that now the dedicated SCCP connection concerning this call is released. The SCCP RELEASED ACK message (MOC/74) is sent as RLC message.

4.

BSC Internal Handover, inter cell

┌─────────┐┌─────────┐┌─────────┐┌─────────┐┌─────────┐ │ MS ││ BTS1 ││ BTS2 ││ BSC ││ MSC │ └──┬──┬───┘└──┬──┬───┘└──┬──┬───┘└──┬──┬───┘└──┬──┬───┘ │ │ ***************************│ │ │ │ │ * HO MEASUREMENTS AND *│ │ │ │ │ * DECISION *│ │ │ │ │ ***************************│ │ │ │ │MEASUREMENT_REPORT(SACCH) │ │ │ │ │1 ├──────>┤ │ │ │ │ │ │ │ │ │ │ │MEASUREMENT_RESULT│ │ │ │ │ │ │2 ├───────┼──┼──────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ HANDOVER DECISION │ │ │ │ │ │ │--------------- BOTTA  │ │ │ │ │ │ │ │ │ │ BOSA  │ │ │ │ │ │ │ │ │ │ BITTA  │ │ │ │ │ │ │ │ │ │ BISA 

│ │ │ │ │ │ │ │ │ │ (CTTA) │ │ **************************************│ (CSA) │ │ * TCH RESERVATION AND ACTIVATION *│ │ │ * IN BTS2 *│ │ │ **************************************│ │ │ │ │ │ │CHANNEL_ACTIVATION│ │ │ │ │ │ │ ├<──────┤3 │ │ │ │ │ │ │ CHANNEL_ACTIVATION_ACK.│ │ │ │ │ │ │4 ├──────>┤ │ │ │ │ │ *************************************** │ │ * SIGNALLING ON FACCH-TCH IN BTS1 * │ │ *************************************** │ │ │ │HO_COMMAND│ │ │ │ │ │ │ │ ├<──────┼──┼───────┤5 │ │ │ │ │HO_COMMAND(FACCH) │ │ │ │ │ │ │ ├<──────┤6 │ │ │ │ │ │ │ │ │ *************************************** │ │ * SIGNALLING ON FACCH-TCH IN BTS2 * │ │ * CONNECTION * │ │ *************************************** │ │HO_ACCESS(FACCH) │ │ │ │ │ │ │7 ├───────┼──┼──────>┤ │ │ │ │ │ │ │ │ │ │ │HO_DETECT │ │ │ │ │ │ │ │8 ├──────>┤ │ │ │ │ │PHYSICAL_INFO(FACCH) │ │ │ │ │ │ ├<──────┼──┼───────┤9 │ │ │ │ │ │ │SABM(FACCH) │ │ │ │ │ │ │10├───────┼──┼──────>┤ │ │ │ │ │ │ │ │ │ │ ESTABLISH_INDICATION│ │ │ │ │ │ │11├──────>┤ │ │ │ │ │UA(FACCH) │ │ │ │ │ │ │ │ ├<──────┼──┼───────┤12│ │ │ │ │ │ │HO_COMPLETE(FACCH)│ │ │ │ │ │ │13├───────┼──┼──────>┤ │ │ │ │ │ │ │RR(FACCH) │ │ │ │ │ │ │ │ ├<──────┼──┼───────┤14│ │ │ │ │ │ │ │ │ │ │HO_COMPLETE │ │ │ │ │ │ │15├──────>┤---------------- BISH  │ │ │ │ │ │ │ │ │ │ BOSH  │ │ │ │ │ │ │ │ │ │ ( CSH ) │ │ │ │ │ │ DT1(HO_PERFORMED)│ │ (  MISH) │ │ │ │ │ │ │16├──────>│ │ (  MOSH)

│ │ │ │ │ │ │ │ │

│ │ │ │ │ │ │ │ │

***************************│ * TCH RELEASE IN BTS1 *│ ***************************│ │ │RF_CHANNEL_RELEASE│ │ │ ├<──────┼──┼───────┤17│ │ │RF_CHANNEL_RELEASE_ACK. │18├───────┼──┼──────>┤ │ │ │ │ │ │ │ │ │ │ │ │ │

│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │

1. MEASUREMENT_REPORT When call is on, the MS sends MEASUREMENT REPORT message concerning mainly the quality of the speech connection two times per second.

2. MEASUREMENT_REPORT/RESULT If these measurement reports are pre-processed in the BTS then measurement results are sent towards the BSC. If the is no pre-processing in the BTS, then MEASUREMENT REPORTS/RESULT are sent. In this phase, Nokia BTS does not make any pre-processing. BSC processes the measurements and decides on the handover algorithm (see /3/). If  thresholds have been triggered for the handover, the BSC generates the candidate cell list and starts the handover attempt. Handover type determination If the parameter DISABLE_INTERNAL_HO is set, the external handover is started. If the parameter MSC_CONTROLLED_HO is set and the candidate cell list contains one or more cells of other BSSs, the external han dover is started. If the first cell of the candidate cell list is controlled by another BSC, the external handover  is started. If the first cell of the candidate cell list is the same cell as the serving one, the internal intra-cell handover is started. If none of the above-mentioned requirements is met, the internal inter-cell handover is started. Candidate cell determination In the case of the internal intra-cell handover, the serving cell is used as the a candidate cell. In the case of the internal inter-cell handover, several c ells can be used as candidate cells. In the case of the external handover, the parameter genHandoverReqMessage indicates how many cells are passed to the MSC in a handover inquiry.

3. CHANNEL_ACTIVATION

The BSC requests the BTS to activate a new channel by sending the CHANNEL ACTIVATION message. 4. CHANNEL_ACTIVATION_ACK. Response to the CHANNEL ACTIVATION message. If the CHANNEL ACTIVATION ACKNOWLEDGE message is received from the BTS  before time-out, the handover attempt continues. In the case of an external SDCCH handover, the HANDOVER REQUEST ACKNOWLEDGE message is sent to the MSC. If the activation of a channel fails and the BTS sends the CHANNEL ACTIVATION  NEGATIVE ACKNOWLEDGE message to the BSC, the handover attempt is terminated (in the case of the external handover, the BSC sends the HANDOVER FAILURE message to the MSC) and the call continues in the old channel. 5. HO_COMMAND from BSC to BTS1 HANDOVER COMMAND message is sent from the BSC to the BTS to change the dedicated channel configuration and timing adjustment needed. 6. HO_COMMAND to MS In the case of the internal handover, the HANDOVER COMMAND (inter-cell) or   ASSIGNMENT COMMAND (intra-cell) message is sent to the MS on the old channel. In the case of the external handover, the information needed in the HANDOVER   COMMAND message is sent to the MSC inside the HANDOVER REQUEST ACKNOWLEDGE message after the channel has been activated at the target BSC. The MSC sends the HANDOVER COMMAND message to the source BSC and passes it to the MS in the old channel. If the MS fails to move into a new channel, it is possible that it returns to the old channel  by sending the HANDOVER FAILURE or ASSIGNMENT FAILURE message to the old BTS which passes it to the BSC. In the case of an external handover, the BSC sends the HANDOVER FAILURE message to the MSC. The handover attempt is terminated and the call continues in the old channel. If the MS fails to move into the new channel and does not return to the old channel, the handover attempt is terminated and the call is cleared. 7. HO_ACCESS The MS sends a HANDOVER ACCESS message in random mode to the new BTS. 8. HO_DETECT The new BTS informs the BSC, that it has detected a handover access message. After receiving an access burst from the MS, the BTS sends the HANDOVER   DETECTION message to the BSC. In the case of an external handover, the HANDOVER DETECTION message is sent to the MSC. 9. PHYSICAL_INFO

The PHYSICAL INFORMATION message contains various physical layer related information, allowing a proper transmission by the MS. 10. SABM This is Layer 2 message and contains some Layer 3 information from MS to BTS. SABM (Set Asynchronous Balanced Mode). Content of this message: service request, ciphering key sequence, mobile station classmark and mobile identity. 11. ESTABLISH_INDICATION BTS acknowledges the HANDOVER COMMAND message by returning ESTABLISH INDICATION message. The ESTABLISH INDICATION message points out that from the BTS point of view, the MS is now on the SDCCH or TCH channel (depending on the type of handover, SDCCH handover or TCH handover). 12. UA UA is normal Layer 2 level acknowledgement from BTS to MS when setting up the Layer  2 level link in LAPDm -protocol.

13. HO_COMPLETE After the MS has established the main signalling link successfully, it sends the HANDOVER COMPLETE (internal inter-cell) or the ASSIGNMENT COMPLETE (internal intra-cell) message on the new channel. 14. RR  The BTS sends a RECEIVE READY message to the MS. This is an acknowledge to the HANDOVER COMPLETE message from BTS to MS. 15. HO_COMPLETE The HANDOVER COMPLETE message is forwarded to BSC. 16. HO_PERFORMED In the case of the internal handover, the HANDOVER PERFORMED message, and in the case of the external handover, the HANDOVER COMPLETE message is sent to the MSC. After the HANDOVER COMPLETE message is received, the network releases the old channels. 17. RF_CHANNEL_RELEASE After the MS has completed the handover, in the case of an internal handover, the BSC releases the old channel by sending the RF CHANNEL REL message to the BTS. In the case of an external handover, the MSC requests the source BSC to release the old channel  by sending the CLEAR COMMAND message.

The old channel is released by sending RF CHANNEL REL message to the BTS and the CLEAR COMPLETE message is sent to the MSC.

18. RF_CHANNEL_RELEASE_ACK. The BTS acknowledges the CHANNEL RELEASE message.

5.

References /1/

GSM Recommendation 04.08, ver. 4.7.0

/3/

GSM Recommendation 08.08, ver. 4.6.0

/4/

GSM Recommendation 08.58, ver. 4.5.0

/5/

GSM Recommendation 03.20

/6/

ETR 09.90 Technical Report (ETSI STC SMG3 Tdoc SMG 300/93)

/7/

GSM Recommendation 05.02

/8/

GSM Recommendation 08.06, ver. 4.3.0

 Number/Version  NTCD TSG 0073 en/1.0

Copyright © Nokia Telecommunications Training Document

Page

3(39)

Document Revision History DATE

ISSUE

AUTHOR

09.02.1996

1.0

Thorsten Braas

SUMMARY OF CHANGES New

Distribution List