5 Information flows

03.183GPPBasic call handlingRelease 1998TS

5.1 Information flow for an MO call

An example information flow for an MO call is shown in figure 3; many variations are possible. Signalling over the radio interface between MSA and BSSA or VMSCA is shown by dotted lines; signalling over the "A" interface between BSSA and VMSCA is shown by dashed lines; signalling over the B interface between VMSCA and VLRA is shown by chain lines; and ISUP signalling between VMSCA and the destination exchange is shown by solid lines.

Figure 3: Information flow for a basic mobile originated call

NOTE 1: Authentication may occur at any stage during the establishment of an MO call; its position in this message flow diagram is an example.

NOTE 2: Ciphering may be initiated at any stage after authentication; its position in this message flow diagram is an example.

NOTE 3: If ciphering is not required, the MSC may send a CM service accept towards the MS; optionally it may instead send a "start ciphering" request indicating that no ciphering is required.

NOTE 4: The network may request the IMEI from the MS, and may check the IMEI, at any stage during the establishment of an MO call, either as part of the procedure to start ciphering or explicitly after ciphering has started; this is not shown in this message flow diagram.

When the user wishes to originate a call, MSA establishes a signalling connection with BSSA, and sends a Connection Management (CM) service request to BSSA, which relays it to VMSCA. VMSCA sends a Process access request to VLRA. VLRA may then initiate authentication, as described in GSM 03.20 [3]. VLRA may also initiate ciphering at this stage, as described in GSM 03.20 [3].

If VLRA determines that MSA is allowed service, it sends a Process access request ack to VMSCA. If VMSCA has received a Set cipher mode message from VLRA, the Process access request ack message triggers a Start ciphering command message towards BSSA; otherwise VMSCA sends a CM service accept message towards BSSA.

If BSSA receives a Start ciphering command from VMSCA, it initiates ciphering as described in GSM 03.20 [3]; when ciphering is successfully initiated, MSA interprets this in the same way as a CM service accept. If ciphering is not required at this stage, BSSA relays the CM service accept to MSA.

When MSA has received the CM service accept, or ciphering has been successfully initiated, MSA sends a Set-up message containing the B subscriber address via BSSA to VMSCA. MSA also uses the Set-up message to indicate the bearer capability required for the call; VMSCA translates this bearer capability into a GSM basic service, and determines whether an interworking function is required. VMSCA sends to VLRA a request for information to handle the outgoing call, using a Send Info For Outgoing Call (SIFOC) message containing the B subscriber address.

If VLRA determines that the call should be connected, it sends a Complete Call message to VMSCA. VMSCA sends a Call Proceeding message via BSSA to MSA, to indicate that the call request has been accepted, and sends an Allocate channel message to BSSA, to trigger BSSA and MSA to set up a traffic channel over the radio interface. The Call Proceeding message includes bearer capability information if any of the negotiable parameters of the bearer capability has to be changed. When the traffic channel assignment process is complete (indicated by the Allocation complete message from BSSA to VMSCA), VMSCA constructs an ISUP IAM using the B subscriber address, and sends it to the destination exchange.

When the destination exchange returns an ISUP Address Complete Message (ACM), VMSCA sends an Alert message via BSSA to MSA, to indicate to the calling user that the B subscriber is being alerted.

When the destination exchange returns an ISUP ANswer Message (ANM), VMSCA sends a Connect message via BSSA to MSA, to instruct MSA to connect the speech path.

The network then waits for the call to be cleared.

For an emergency call, a different CM service type (emergency call) is used, and the mobile may identify itself by an IMEI. It is a network operator option whether to allow an emergency call when the mobile identifies itself by an IMEI. Details of the handling are shown in clause 7.

5.2 Information flow for retrieval of routeing information for an MT call

The information flow for retrieval of routeing information for an MT call is shown in figure 4. ISUP signalling between the originating exchange and GMSCB, and between GMSCB and VMSCB is shown by solid lines; signalling over the MAP interfaces between GMSCB and HLRB and between HLRB and VLRB is shown by chain lines.

Figure 4: Information flow for retrieval of routeing information for a basic mobile terminated call

When GMSCB receives an IAM, it analyses the called party address. If GMSCB can derive an HLR address from the B party address, it sends a request for routeing information (SRI) to HLRB. HLRB sends a request for a roaming number (PRN) to VLRB. VLRB returns the roaming number in the PRN ack, and HLRB relays the roaming number to GMSCB in the SRI ack. GMSCB constructs an IAM using the roaming number, and sends it to VMSCB.

5.3 Information flow for an MT call

An example information flow for an MT call is shown in figure 5; many variations are possible. ISUP signalling between GMSCB and VMSCB is shown by solid lines; signalling over the B interface between VMSCB and VLRB is shown by chain lines; signalling over the "A" interface between VMSCB and BSSB is shown by dashed lines; and signalling over the radio interface between VMSCB or BSSB and MSB is shown by dotted lines.

Figure 5: Information flow for a basic mobile terminated call

NOTE 1: Ciphering may be initiated at any stage after the network has accepted the page response; its position in this message flow diagram is an example.

NOTE 2: If ciphering is not required, the MSC may send a "start ciphering" request indicating that no ciphering is required.

NOTE 3: This message flow diagram assumes that the MS has already been authenticated on location registration. If this is not so (for the first MT call after VLR restoration), the network may initiate authentication after the MS responds to paging.

NOTE 4: The network may request the IMEI from the MS, and may check the IMEI, at any stage after the MS responds to paging, either as part of the procedure to start ciphering or explicitly after ciphering has started; this is not shown in this message flow diagram.

When VMSCB receives an IAM from GMSCB it sends to VLRB a request for information to handle the incoming call, using a Send Info For Incoming Call (SIFIC) message containing the roaming number received in the IAM.

If VLRB recognises the roaming number, and MSB is allowed service, it sends a request to VMSCB to page MSB. If a radio connection between the network and MSB is already established, VMSCB responds immediately to the page request. If no radio connection exists, VMSCB sends a page request to BSSB, and BSSB broadcasts the page on the paging channel. If VPLMNB supports GPRS and the Gs interface between VLRB and the SGSN is implemented (see GSM 03.60 [5]) and there is a valid association between VLRB and the SGSN for the MS, the paging signal towards the MS goes from VMSCB via VLRB and the SGSN to the BSS.

If MSB detects the page, it sends a channel request to BSSB, which responds with an immediate assignment command, to instruct MSB to use the specified signalling channel. MSB then sends a page response on the signalling channel; BSSB relays this to VMSCB. VMSCB sends a Process access request message to VLRB to indicate that MSB has responded to paging. VLRB may then initiate authentication, as described in GSM 03.20 [3]. VLRB may also initiate ciphering at this stage, as described in GSM 03.20 [3].

If VLRB determines that MSB is allowed service, it sends a Process access request ack to VMSCB. The Process access request ack message triggers a Start ciphering command message towards BSSB; if VMSCB has not received a Set cipher mode message from VLRB, the Start ciphering command indicates no ciphering.

VLRB then sends a Complete call message to VMSCB. VMSCB sends a Set-up message towards MSB. The Set-up message may include bearer capability information for the call.

When MSB receives the Set-up message from BSSB, it responds with a Call confirmed message. The Call Confirmed message includes bearer capability information if any of the negotiable parameters of the bearer capability has to be changed. When VMSCB receives the Call confirmed message via BSSB, it sends an Allocate channel message to BSSB. BSSB instructs MSB to tune to a traffic channel by sending an Assignment command. When MSB has tuned to the specified traffic channel it responds with an Assignment complete, message, which BSSB relays to VMSCB as an Allocation complete, and sends an Alerting message to indicate that the called user is being alerted. VMSCB sends an ACM to GMSCB, which relays it to the originating exchange.

When the called user answers, MSB sends a Connect message, which BSSB relays to VMSCB. VMSCB:

– responds with a Connect ack message towards MSB;

– sends an ANM to GMSCB, which relays it to the originating exchange;

– sends a Complete call ack to VLRB.

The network then waits for the call to be cleared.