17695597-Layer-3-Messages.pdf

7/27/2019 17695597-Layer-3-Messages.pdf

1/37

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 Approved by Page

NTCD TSG 0073 en/1.0 Nov-96/MKo/ThB Nov-96/JNi 1(39)

Contents1. Mobile Originated Call

2. Mobile Terminated Call


2/37

3. Messages in MOC and MTC

3.1. PAGING

3.2. PAGING_COMMAND

3.3. PAGING_REQUEST

3.4. CHANNEL_REQUEST

3.5. CHANNEL_REQUIRED3.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 MSC3.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/37

3.45. ASSIGNMENT_COMMAND

3.46. SABM (Set Asynchronous Balanced Mode)


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

4.12. UA

4.13. HO_COMPLETE

4.14. RR

4.15. HO_COMPLETE

4.16. HO_PERFORMED

4.17. RF_CHANNEL_RELEASE4.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 >---------------------------------SDCCHSEIZ

ATT

CHANNEL_ACTIVATION SDCCHBUSYATT

IMMEDIATE_ASSIGNMENT_COMMAND


5/37

7 >

ESTABLISH_INDICATION

8 >--------------------------------SUCC SEIZ

ORIG

CR(CM_SERVICE_REQUEST) SUCC SEIZ

TERM

9 > SDCCHCALL

REEST

UA(SDCCH) SDCCHEMERG

CALL

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

* CIPHERING & ENCRYPTION PART *

* CALL SETUP *

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

AUTHENTICATE

SET_CIPHERING_MODE


6/37

DT1(CIPHERING_MODE_COMPLETE)

23>

ACCESS_REQUEST_ACCEPTED

DT1(SETUP) 32>

SEND_INFO_FOR_OG_CALL

33>

COMPLETE_CALL


7/37

CHANNEL_ACTIVATION TCHNORM

SEIZ

A_BSC

ASSIGNMENT_COMMAND(SDCCH)


44>

UA(FACCH)

DT1(ASSIGNMENT_COMPLETE)

47>------------------------ A_MSC

CHANNEL_RELEASE

DT1(ALERTING)


8/37

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)

--------------------B_MSC

DT1(CLEAR_COMMAND)


9/37

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

* MS STARTS LISTENING TO *

* BCCH AGAIN *

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

RELEASE_INDICATION 69>

RF_CHANNEL_RELEASE

----------------------------------B_BSC

DT1(CLEAR_COMPLETE)

72>

RLSD(SCCP_RELEASED)

2.

Mobile Terminated Call

MS BTS BSC MSC

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


10/37

* PAGING PART *

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

UDT(PAGING)

SDCCHCALL REEST

UA(SDCCH)

SDCCHEMERGCALL


11/37


12/37

26>

DT1(SETUP)

DT1(ASSIGNMENT_REQUEST)

UA(FACCH)

DT1(ASSIGNMENT_COMPLETE)

41>------- A_MSC

CHANNEL_RELEASE


13/37

CHANNEL_RELEASE_ACK.

43>

MS BTS BSC MSC

ALERTING(FACCH)

44>

DT1(ALERTING)

45>

CONNECT(FACCH)

46>

DT1(CONNECT)

47>

DT1(CONNECT_ACK.)

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

* RELEASE BY MS *

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

DISCONNECT(FACCH)

52>

DT1(DISCONNECT)

53>

DT1(RELEASE)

------ B_MSC

DT1(CLEAR_COMMAND)


14/37


15/37


16/37

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

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


17/37

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

- Failure cause: radio resource not available;

- Failure cause: radio channel already activated/allocated;

- Failure cause: protocol error and subclause, such as mandatory information

error;

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


18/37

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 request 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;


19/37

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


20/37

UA is normal Layer 2 level acknowledgement when setting up the Layer 2 level link in

LAPDm -protocol.

14. PROCESS_ACCESS_REQUESTMSC 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 incommunication 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.


21/37

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


22/37

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


23/37

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


24/37

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 conditionsexist, 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 QUEUEINGINDICATION 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.


25/37

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


26/37

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 radioresource available".


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

transparent 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 = requestedtranscoding/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


27/37

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

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


28/37

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


29/37

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


30/37

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


31/37

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


32/37

(CTTA)

************************************** (CSA)

* TCH RESERVATION AND ACTIVATION *

* IN BTS2 *

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

CHANNEL_ACTIVATION

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

* SIGNALLING ON FACCH-TCH IN BTS1 *

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

HO_COMMAND

PHYSICAL_INFO(FACCH)


11>

UA(FACCH)

RR(FACCH)

---------------- BISH

BOSH

(CSH) DT1(HO_PERFORMED) (MISH)

16> (MOSH)


33/37

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

* TCH RELEASE IN BTS1 *

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

RF_CHANNEL_RELEASE

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

In the case of the internal inter-cell handover, several cells 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.



34/37

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 BTSbefore 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 oldBTS 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


35/37

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, cipheringkey 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 theHANDOVER 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.


36/37

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


/5/ GSM Recommendation 03.20

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

/7/ GSM Recommendation 05.02


Number/Version Copyright Nokia Telecommunications Page

NTCD TSG 0073 en/1.0 Training Document 3(39)

Document Revision History

DATE ISSUE AUTHOR SUMMARY OF

CHANGES

09.02.1996 1.0 Thorsten Braas New

Distribution List


37/37

Attached documents

Number/Version Copyright Nokia Telecommunications Page

NTCD TSG 0073 en/0.1 Training Document A(1)

17695597-Layer-3-Messages.pdf

Documents