5.1 Information flow for an MO call

23.0183GPPBasic call handlingRelease 17Technical realizationTS

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 Iu interface (for UMTS) or the A interface (for GSM) 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.

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: Security procedures may be initiated at any stage after authentication; the position in this message flow diagram is an example.

NOTE 3: If ciphering is not required for a GSM connection, 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. This option is not available for a UMTS connection [ffs].

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 security procedures or explicitly after security procedures have started; this is not shown in this message flow diagram.

Figure 3: Information flow for a basic mobile originated call

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 3GPP TS 33.102 [32] for UMTS and 3GPP TS 43.020 [1] for GSM. VLRA may also initiate security procedures at this stage, as described in 3GPP TS 33.102 [32] for UMTS 3GPP TS 43.020 [1] for GSM. If the user originates one or more new MO calls in a multicall configuration, MSA sends a CM service request through the existing signalling connection for each new call.

If the MS has performed the Connection Management (CM) service request in a CSG cell, VLRA shall control if the CSG cell is allowed by the CSG subscription data stored in VLRA. If the CSG cell is not allowed, VLRA shall reject the Process Access Request.

If the MS has performed the Connection Management (CM) service request in a hybrid cell, VLRA shall set the CSG membership status in the Process Access Request ack according to the CSG subscription data stored in VLRA.

If VLRA determines that MSA is allowed service, it sends a Process Access Request ack to VMSCA. If VMSCA has received a Start security procedures message from VLRA, the Process Access Request ack message triggers a Start security procedures message towards BSSA; otherwise VMSCA sends a CM Service Accept message towards BSSA.

If BSSA receives a Start security procedures message from VMSCA, it initiates security procedures as described in 3GPP TS 33.102 [32] for UMTS and 3GPP TS 43.020 [1] for GSM; when security procedures have been successfully initiated, MSA interprets this in the same way as a CM Service Accept. If security procedures are not required at this stage, BSSA relays the CM Service Accept to MSA.

When MSA has received the CM Service Accept, or security procedures have 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 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 Alerting 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.