0% found this document useful (0 votes)
43 views9 pages

Call - Part4

This document describes the steps involved in GSM authentication and ciphering procedures. It involves authentication of the mobile station by the network to establish its identity and allow access. A ciphering key is also distributed to allow encryption of communications for privacy. The steps include the HLR providing authentication vectors to the VLR, challenges being passed to the MS for response, comparison of responses, and distribution of encryption keys when authentication is successful.

Uploaded by

Kedir Hassen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views9 pages

Call - Part4

This document describes the steps involved in GSM authentication and ciphering procedures. It involves authentication of the mobile station by the network to establish its identity and allow access. A ciphering key is also distributed to allow encryption of communications for privacy. The steps include the HLR providing authentication vectors to the VLR, challenges being passed to the MS for response, comparison of responses, and distribution of encryption keys when authentication is successful.

Uploaded by

Kedir Hassen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

(15). HLR forward/send authentication request to AUC.

AUC then returns to HLR an authentication


triplet [RAND, SRES, Kc.]
(16). HLR forward authentication triplets to VLR (IMSI, Kc, RAND, SRES) in SAI_ACK message
(17). VLR keeps 2 parameter Kc, SRES for later use and send message (including RAND) to MSC
for MS authentication.
(18). MSC send authentication request “MM Authentication Request" message, containing RAND,
to MS
(19). MS reads Ki from SIM, Applies RAND, Ki to algorithm (A3) and Cipher Key generation
algorithm (A8) to produce SRES and Kc, MS saves Kc and will use Kc for ciphering.
(20). MS returns the generated SRES "RIL3-MM Authentication Response" message to MSC
(21). MSC forward /send SRES to VLR,
(22). VLR compares 2 SRES. The VLR compares the SRES received from the MS to the SRES
value available within it as a result of a previous send authentication procedure with the
HLR/AuC. If both values are identical and the subscriber’s identity is authenticated.
(23). VLR acknowledges the process access request with a "MAP/B Access Request Accepted"
message to the MSC
(24). The MSC also sends the VLR a "MAP/B Authentication Complete" message to VLR

37. Authentication Response -Ki /SRES


 VLR acknowledges the process access request with a "MAP/B
Access Request Accepted" message to the MSC
 The MSC also sends the VLR a "MAP/B Authentication
Complete" message to VLR
38. Cipher mode command-Ciphering Procedure – Kc
• activation of user data encryption

 Ciphering begins with the VLR sending the MSC a "MAP/B Set
Cipher Mode" message containing the value of Kc for use.
 The MSC sends the new ciphering mode and ciphering key to the BSS in
a "BSSMAP Cipher Mode Command" message.
 The BSS in turn sends an "RIL3-RR Ciphering Mode Command"
message to the MS.
39. Cipher mode complete-Ciphering Procedure – Kc
 The MS then switches to encrypted transmission and reception and sends
back an "RIL3-RR Cipher Mode Complete" message in encrypted
mode.
 After the BSS receives this message, it too switches to encrypted
transmission for subsequent bursts. The BSS then sends a
"BSSMAP Ciphering Mode Complete" message to the MSC to
indicate that the encryption process is complete

An Equipment Identification procedure-IMEI -


Optional
Equipment Validation-IMEI [Optional]

• Equipment Validation*
(2). In networks where IMEI check is ON, the MSC/VLR invokes the identity request procedure, as described
in the previous section.
• In cases where an IMEI check is enabled, then
 MSC requests the MS to provide its IMEI by sending an identity request
message. MSC request MS to send IMIE
 The MS responds back with an identity response message, which contains the
MS’s IMEI. MS send IMEI.

 The received IMEI is compared with the IMEI stored in the EIR.MSC request
EIR to Check IMEI. EIR check that IMEI is within valid range and valid
equipment.
 EIR returns the results to MSC if results are – ve then MSC drop the call. If call
continue, then MSC inform the N/W of the event.
40. TMSI Reallocation Command -TMSI reallocation procedure
 After completing the ciphering process, the message is sent from
VLR to MSC for reallocation of the TMSI if desired ("Forward
new TMSI").
 VLR can thus allocate a TMSI to the MS via the TMSI Reallocation
Command message requests MSC to perform TMSI reallocation
with TMSI Reallocation Command (SDCCH)

41. TMSI Reallocation Complete -TMSI reallocation procedure


 A "TMSI Reallocation Complete" message is sent from MS to
BSS after reallocating a new TMSI.
 A " TMSI Reallocation Complete (SDCCH)" message is sent
from MS to MSC after reallocating a new TMSI.
42. DTAP Call Setup. [MSC --> BSC --> BTS --> MS]
SETUP (calling party nbr)

 After TMSI allocation, the MSC sends the MS a n "RIL3-CC Call


Setup" message giving the phone numbers of both the calling (MS-ISDN
number) and called (MS-ISDN number) parties and the type of service
requested to MS.
 The MS performs a comparability check and responds to MSC
with an "RIL3-CC Call Confirmation" message that is forwarded
to MSC. At this stage MSC sends a TUP/ISUP Address
Complete" message to GMSC. At this time the calling party gets
the ring tone.

 MSC inform MS that a call can be setup.

 SDCCH/I/CC SETUP [Calling Party Numbers, requested service, bearer capability]


 The MSC then sends the terminating MS an "RIL3-CC Setup" message
providing details of the call, including the calling party and the connection
services required.
 Next, the MSC sends the MS an "RIL3-CC Call Setup" message giving the
phone numbers of both the calling (PSTN or ISDN number) and called (MS-
ISDN number) parties and the type of service requested.
 SETUP informs the MS about the necessary technical preconditions (Bearer
Capabilities), which are necessary, in order to accept the connection request, and,
if active, conveys the identity of the caller transparently to the MS.
Next, the MSC sends the MS a n "RIL3-CC Call Setup" message giving the phone numbers of both the
calling (PSTN or ISDN number) and called (MS-ISDN number) parties and the type of service requested.
The MS performs a comparability check and responds to MSC with an "RIL3-CC Call Confirmation"
message that is forwarded to MSC. At this stage MSC sends a "TUP/ISUP Address Complete" message
to GMSC that in turn is sent to the PSTN/ISDN switching center. At this time the calling party gets the
ring tone.

43. Call Confirmed [MSC --> BSC --> BTS --> MS]
 After receiving a "RIL3-CC Call Confirmation" message from MS, the MSC
sends a " TUP/ISUP Address Complete" message to GMSC that in turn is sent
to Calling MSC
 At this time the calling party gets the ring tone.

When the MSC receives ACM (ISUP) for the connection set up, it either sends
an ALERT or a PROGRESS message to the MS.
ALERT is used to indicate a change of state within the MS, e.g., generation of a
ring tone. PROGRESS is used when no change of state is involved, e.g., when
the ring tone is sent “inband” from the NSS. For more differences between,
ALERT and PROGRESS,

 After receiving and checking the SETUP message, the MS confirms its
capabilities to accept this connection request by sending of a CALL_CONF. If
the MS is unable to accept the request, e.g., due to incompatibility of the Bearer
Capability, then a REL_COM is sent instead of CALL_CONF. This terminates
the connection
 The MS performs a comparability check and responds to MSC with an "RIL3-
CC Call Confirmation" message that is forwarded to MSC.

 The MS performs a comparability check and responds to MSC with an "RIL3-


CC Call Confirmation" message that is forwarded to MSC
 The MS performs a comparability check and responds to MSC
with an "RIL3-CC Call Confirmation" message that is forwarded
to MSC.
 At this stage MSC sends a TUP/ISUP Address Complete"
message to GMSC.
 At this time the calling party gets the ring tone.



 At this stage MSC sends a " TUP/ISUP Address Complete" message to GMSC
that in turn is sent to the PSTNIISDN switching center
After receiving a "RIL3-CC Call Confirmation" message from MS, the MSC sends a " TUP/ISUP
Address Complete" message to GMSC that in turn is sent to Calling MSC

"RIL3-CC Call Confirmation" message

 After receiving and checking the SETUP message, the MS confirms its
capabilities to accept this connection request by sending of a CALL_CONF. If
the MS is unable to accept the request, e.g., due to incompatibility of the Bearer
Capability, then a REL_COM is sent instead of CALL_CONF. This terminates
the connection

 The MS performs a comparability check and responds to MSC with an "RIL3-


CC Call Confirmation" message that is forwarded to MSC

 After receiving a "RIL3-CC Call Confirmation" message from MS, the MSC
sends a " TUP/ISUP Address Complete" message to GMSC that in turn is sent
to Calling MSC

 Call Confirmed- DTAP message sent by the called
MS to the MSC to confirm the attempted incoming call
setup.
TCH Assignment Procedure
The MSC sends an assignment request to the BSC
 After Call Confirmed- DTAP message sent by the
called MS to the MSC to confirm the attempted
incoming call setup.

After Call Confirmed, At the same time the MS is assigned a TCH by the previously
described channel assignment procedure. Now MS rings or buzzes to alert the subscriber of the
incoming call and
the MS sends an "RIL3-CC Alerting" message to the MSC to inform that the subscriber has been alerted.

When the mobile subscriber answers the alert by pressing the Answer Key on the MS subscriber set, the
MS sends an "RIL3-CC Connect" message to the MSC. The MSC then responds with an "RIL3-CC
Connect Acknowledge" message to the MS and simultaneously sends a "TUP/ISUP Answer" message to
the GMSC. The GMSC and the PSTNI ISDN switching center relay this message to the originating
PSTNIISDN terminal.

MTC-TCH Assignment Procedure


Establishment of traffic channel phase
 After "RIL3-CC Call Proceeding", if OACSU (Off Air Call Set Up) is not
active,MSC starts the TCH allocation by sends an Assignment Request
message to BSC,

43.1. TCH Assignment Request-[MSC --> BSC]


• TCH Assignment Request [Chn. Type, Priority, CIC,DL DTX, Queuing Flag]
43.2. Physical Context Request [ on SDCCH] [BSC --> BTS]

43.3. Physical Context Confirm [TA.MS/BS_TxPwr] [BTS --> BSC]


43.4. Channel Activation TCH [TA, MS/BS_TxPwr] [BSC --> BTS]

43.5. Channel Activation Ack. [BTS --> BSC]

43.6. Assignment Command [ on SDCCH] [BSC --> BTS --> MS]


 The BTS delivers received information further on towards the MS.
Contents: channel description, power levels, cell channel
description, channel mode (Full / Half) and mobile allocation.
 Assignment Command [MA, TS, HSN, MAIO,MS_TxPwr]
43.7. SABM (FACCH) [MS --> BTS]
 On TCH if need signaling, then use Stealing Flag transfer TCH into
FACCH
 The MS tunes to new channel and sends a SABM message over
the FACCH to indicate successful seizure of the channel.
43.8. UA [BTS --> MS]-Establish Indication [BTS --> BSC]
 As the BTS receives this message it sends a UA message to the
MS and an establishment indication message to the BSC
43.9. Assignment Complete/Allocation complete [MS --> BTS --> BSC--> MSC]
 The MS then finally sends an assignment complete message to
the MSC to indicate that the traffic channel is working
 MS tunes to TCH and transmits an assignment complete message
back to BSS. MS user phone rings. MS do not use SDCCH after
it gets TCH.

 BSS on receiving assignment complete message connects the


TCH to Trunk. SDCCH is free now and send Assignment
Complete Message to MSC.

43.10. RF Channel Release (SD) [BSC --> BTS]


 The BSC sends a message to BTS that the signaling channel is
no longer needed in the form of RF channel release a message.
The BTS sends an RF channel release message.
43.11. RF Channel Release Ack [BTS --> BSC]
 The BTS sends an RF channel acknowledgement message back
to the BSC

 Now MS (called party) rings or buzzes to alert the subscriber of the incoming call and the MS
sends an "RIL3-CC Alerting" message to the MSC to inform that the subscriber has been alerted.
 When the mobile subscriber answers the alert by pressing the Answer Key on the MS subscriber
set, the MS sends an "RIL3-CC Connect" message to the MSC.
 Alerted by ringing, the mobile subscriber accepts the call e.g., by
pressing the “ANS/OK” button and starts talking.
 Simultaneously The MSC then responds with an "RIL3-CC Connect Acknowledge" message to
the MS and simultaneously sends a "TUP/ISUP Answer" message to the GMSC
B-Party)

The MS starts ringing after traffic channel assignment (for Call Control after sending of
CALL_CONF). Simultaneously an ALERT message (never PROGRESS) is transparently sent to the
MSC.
This triggers an ACM (ISUP) towards the calling subscriber and the generation of a ring back tone.

Alerted by ringing, the mobile subscriber accepts the call e.g., by pressing the “SEND” button and
starts talking. When the users press the “Send” button, the MS transparently sends a CON message to
the MSC/VLR, that is conveyed to the peer as ANS message (ISUP). Furthermore, the MSC/VLR sends
the CON_ACK message to the MS, which indicates start of the call and also initiates charging

44. IAM-Call Proceeding [MSC --> BSC --> BTS --> MS]

 After receiving and checking the SETUP message, the MS confirms its
capabilities to accept this connection request by sending of a CALL_CONF.

 After receiving a "RIL3-CC Call Confirmation" message from MS, the MSC
sends a " TUP/ISUP Address Complete" message to GMSC that in turn is sent
to Calling MSC
 At this time the calling party gets the ring tone.

45. ACM - Alert


MOC
 Alerting – DTAP message sent by MSC to the MS to
indicate that called user alerting has begun.
 After receiving a "RIL3-CC Call Confirmation" message from MS, the MSC
sends a " TUP/ISUP Address Complete" message to GMSC that in turn is sent
to Calling MSC
 At this time the calling party gets the ring tone.
 On receiving the ISUP ACM message from the GMSC, indicating that a connection is
being set up to the called party, the MSC sends an alert message to the MS. This
results in a call progress tone being fed to the MS.

MTC

Called MS got TCH, MS begin alerting the user after if receives a TCH. A alerting message is sent to MSC

The MS starts ringing after traffic channel assignment (for Call Control after sending of
CALL_CONF). Simultaneously an ALERT message (never PROGRESS) is transparently sent to the
Called MSC. This triggers an ACM (ISUP) towards the calling subscriber and the generation of a ring
back tone.
The Called MSC sends an ACM to the Gateway-MSC, when it receives the ALERT message from the called MS.
The Gateway-MSC forwards the ACM to calling MSC. The ALERT message signals that the called mobile station is
ringing

Called MSC on getting alerting indication from called MS will generate ringing to calling party and send a N/W
alerting to GMSC

Alerted by ringing, the mobile subscriber accepts the call e.g., by pressing the “SEND” button and
starts talking. When the users press the “Send” button, the MS transparently sends a CON message to
the MSC/VLR, that is conveyed to the peer as ANS message (ISUP). Furthermore, the MSC/VLR sends
the CON_ACK message to the MS, which indicates start of the call and also initiates charging

46. Call Confirmed

47. ANM-ISUP- ANM-Connect [MSC --> BSC --> BTS --> MS]

 After receiving a "RIL3-CC Call Confirmation" message from MS, the MSC
sends a " TUP/ISUP Address Complete" message to GMSC that in turn is sent
to Calling MSC
 At this time the calling party gets the ring tone.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy