Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.018  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   7…   7.2…   7.3…   8…   A…

 

5  Information flowsWord‑p. 14
In this clause and clause 7, the terms "security procedures" and "security control" denote the UMTS ciphering and integrity protection mechanism defined in TS 33.102 or the GSM ciphering mechanism defined in TS 43.020, as appropriate.

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 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.
(not reproduced yet)
Figure 3: Information flow for a basic mobile originated call
Up
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 TS 33.102 for UMTS and TS 43.020 for GSM. VLRA may also initiate security procedures at this stage, as described in TS 33.102 for UMTS TS 43.020 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 TS 33.102 for UMTS and TS 43.020 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.
Up

5.2  Information flow for retrieval of routeing information for an MT callWord‑p. 17
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, and over the B interface between VLRB and VMSCB is shown by chain lines; signalling over the Iu interface (for UMTS) or the A interface (for GSM) between VMSCB and BSSB is shown by dashed lines; and signalling over the radio interface between BSSB and MSB is shown by dotted lines.
(not reproduced yet)
Figure 4: Information flow for retrieval of routeing information for a basic mobile terminated call
Up
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. If GMSCB supports pre-paging (i.e. it is prepared to wait long enough for the SRI ack to allow pre-paging to be completed), it indicates this by an information element in the SRI message.
HLRB decides whether pre-paging is supported according to the following criteria:
  • GMSCB has indicated that it supports pre-paging; and
  • HLRB supports pre-paging (i.e. it is prepared to wait long enough for the PRN ack to allow pre-paging to be completed).
HLRB sends a request for a roaming number (PRN) to VLRB; if pre-paging is supported, it indicates this by an information element in the PRN message. If Paging Area function is supported in HLRB then HLRB sends the paging area if stored in HLR. 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.
If the GMSC performs domain selection through HLR interrogation and the HLR supports domain selection functionality, HLRB executes domain selection functionaility. The HLR shall:
  • send PRN to VLRB as defined in this section , if the result of domain selection is to handle the call in CS domain; or
  • reply with SRI ack without sending PRN to VLRB, if the result of domain selection is to transfer the call from CS domain to IMS domain.
Up

5.2.1  Mobile Terminating Roaming Retry Call after successful Retrieval of Routeing Information |R7|Word‑p. 18
The information flow for mobile terminating roaming retry call after successful retrieval of routeing information is shown in figure 4a. It applies to a mobile terminating call while the called mobile is simultaneously moving from an old to a new MSC, if the GMSC, the HLR and the old terminating VMSC support the MT Roaming Retry procedure.
In that case, upon receipt of:
  • an ISUP IAM message which was preceeded by a MAP Cancel Location procedure, or
  • a MAP Cancel Location procedure while on-going paging,
the old VMSC shall instruct the GMSC to resume terminating call procedure by sending a MAP Resume Call Handling message. The GMSC shall then release the ISUP connection to the old VMSC, terminate any open CAP dialogue, and retry the terminating call setup towards the new MSC by sending an additional SRI to the HLR. This second SRI request leads to obtaining a roaming number from the new MSC towards which the call can then be delivered (possibly after new CAMEL interactions).
An HLR supporting the "mobile terminating roaming retry" feature shall always send a MAP Cancel Location message message to the old VLR upon receipt of the MAP Update Location from the new VLR. This shall also apply if the HLR and the old VLR support Super-Charger (see TS 23.116), regardless of whether the new VLR indicates or not during the location update procedure that the previous network entity must be notified.
(not reproduced yet)
Figure 4a: Information flow for a mobile terminating roaming retry call after successful Retrieval of Routeing Information
Up
Step 1.
A GMSC supporting the "mobile terminating roaming retry" feature includes the Call Reference Number, the GMSC address and the MT Roaming Retry Supported IE in the first SRI sent to the HLR.
Step 2.
A HLR supporting the "mobile terminating roaming retry" feature includes the Call Reference Number, the GMSC address and the MT Roaming Retry Supported IE in the PRN sent to the MSC/VLR if received in the SRI.
Step 2'.
An old VLR supporting the "mobile terminating roaming retry" feature may indicate in the MAP Send Identification response sent to the new VLR whether there is a pending mobile terminating call at the old VLR.
Step 3.
Receipt of the MT Roaming Retry Supported IE in the PRN indicates that the GMSC supports the Resume Call Handling procedure and the mobile terminating roaming retry feature. Upon receipt of the ISUP IAM message which was preceeded by a MAP Cancel Location message, or upon receipt of the MAP Cancel Location message while paging, the old MSC/VLR stops paging, if paging was on-going, and if it supports the "mobile terminating roaming retry" feature and did receive the MT Roaming Retry Supported IE in the PRN, sends an RCH message to the GMSC with the MT Roaming Retry IE. The old MSC shall terminate any open CAP dialogue when receiving RCH ACK or ISUP REL message.
Step 4.
Upon receipt of the RCH message with the MT roaming retry IE, the GMSC acknowledges the RCH message, releases the call towards the old MSC/VLR, terminates T-CSI dialog with the SCP, if any exists, using T-Abandon EDP, and re-sends a new SRI to the HLR (still a 'basic call' interrogation type) using a new call reference number.
Step 5.
To avoid looping, the new SRI shall be sent without the Roaming Retry Supported IE. Furthermore, the GMSC shall use an appropriate high value for the timer supervising receipt of SRI ACK.
Note that the Suppress T-CSI field is not set since the Mobile Terminating procedure is restarted from the beginning including the handling of CAMEL interaction on T-CSI (this is because T-CSI treatments may end differently if old and new MSCs are not in the same PLMN or in the same geographical area, e.g. different charging rates or regional service subscription).
Step 6.
Upon receipt of a SRI request or PRN ack (regardless of the PRN response from the old VLR) during an on-going Update Location procedure, the HLR delays the sending of the PRN to the new VLR till completion of the Update Location procedure.
Step 7.
Receipt of the MSRN' from the new MSC/VLR enables the GMSC to relay the call towards the new MSC/VLR.
Step 8.
If the IAM message is received before the Location Update procedure is completed with the MS, the new MSC may delay the setup of the call until the completion of the Location Update procedure or start at once the normal terminating call procedure. In the former case, if the Location Update is received with the "follow-on" indication and if the VMSC supports the "follow-on" indication, the incoming IAM may either be handled as a waiting call or forwarded as Busy (CFB), depending on the state of the "follow-on" call and the subscriber's subscription data.
If no IAM message has been received at the time the Location Update procedure completes, the new MSC may shortly defer the release of the signalling connection with the MS if the old VLR indicated in the MAP Send Identification response that there is a pending mobile terminating call at the old VLR.
Similarly, a HLR supporting the "mobile terminating roaming retry" feature should wait for the completion of any on-going Location Update procedure when processing other terminating requests e.g. MAP-SEND-ROUTING-INFO-FOR-SM, MAP-SEND-ROUTING-INFO-FOR-LCS, MAP-ANY-TIME-INTERROGATION. More generally, this also applies to all TCAP transactions that the HLR may have to open toward a VLR (e.g. USSD, PSI).
Up

5.2.2  Mobile Terminating Roaming Retry Call during Retrieval of Routeing Information |R9|Word‑p. 20
The information flow for mobile terminating roaming retry call during retrieval of routing information is shown in figure 4b. It applies to a mobile terminating call while the called mobile is simultaneously moving from an old to a new MSC, if the GMSC and the HLR support the MT Roaming Retry procedure. The procedure may e.g. apply during pre-paging if the GMSC, HLR and old MSC/VLR support pre-paging.
In that case, upon receipt of:
  • a MAP Cancel Location procedure while on-going pre-paging,
the old VMSC/VLR shall return a PRN negative response to the HLR. If "Suppress T-CSI" was included in the SRI request, the HLR shall relay a SRI negative response with the error "absent subscriber" including the reason "mtRoamingRetry" to the GMSC. If "Suppress T-CSI" was not included in the SRI request, and the called party is roaming to a different MSC/VLR during the PRN procedure, the HLR may either return a SRI negative response with the error "absent subscriber" including the reason "mtRoamingRetry" to the GMSC, or instead delay the sending of a PRN request to the new VLR until completion of the Update Location procedure.
The GMSC shall release the T-CSI dialogue (if existing) and retry the terminating call setup towards the new MSC by sending an additional SRI to the HLR when receiving a SRI negative response with the error "absent subscriber" including the reason "mtRoamingRetry". This second SRI request leads to obtaining a roaming number from the new MSC towards which the call can then be delivered (possibly after new CAMEL interactions).
An HLR supporting the "mobile terminating roaming retry" feature shall always send a MAP Cancel Location message message to the old VLR upon receipt of the MAP Update Location from the new VLR. This shall also apply if the HLR and the old VLR support Super-Charger (see TS 23.116), regardless of whether the new VLR indicates or not during the location update procedure that the previous network entity must be notified.
(not reproduced yet)
Figure 4b: Information flow for a mobile terminating roaming retry call during Retrieval of Routeing Information
Up
Step 1.
A GMSC supporting the "mobile terminating roaming retry" feature includes the Call Reference Number, the GMSC address, and the MT Roaming Retry Supported IE in the first SRI sent to the HLR. The Pre-paging Supported IE is included in the SRI message if the GSMC supports the "Pre-paging" feature.
Step 2.
A HLR supporting the "mobile terminating roaming retry" feature includes the Call Reference Number and the GMSC address in the PRN sent to the MSC/VLR if received in the SRI. If GMSC and HLR support the "Pre-paging" feature, the Pre-paging Supported IE is included in the PRN message.
Step 2'.
An old VLR supporting the "mobile terminating roaming retry" feature may indicate in the MAP Send Identification response sent to the new VLR whether there is a pending mobile terminating call at the old VLR.
Step 3.
Upon receipt of the MAP Cancel Location message while pre-paging, the old MSC/VLR stops pre-paging and sends a PRN negative response message to the HLR. If meanwhile the HLR has received a new Update Location procedure from a new MSC/VLR, the HLR returns a SRI negative response with error "absent subscriber" including the reason "mtRoamingRetry" to the GMSC.
Step 4.
Upon receipt of the SRI negative response with error "absent subscriber" including the reason "mtRoamingRetry", the GMSC re-sends a new SRI to the HLR (still a 'basic call' interrogation type) using a new call reference number.
Step 5.-8.
See the same procedures from step 5 to step 8 in the figure 4a.
Similarly, a HLR supporting the "mobile terminating roaming retry" feature should wait for the completion of any on-going Location Update procedure when processing other terminating requests e.g. MAP-SEND-ROUTING-INFO-FOR-SM, MAP-SEND-ROUTING-INFO-FOR-LCS, MAP-ANY-TIME-INTERROGATION. More generally, this also applies to all TCAP transactions that the HLR may have to open toward a VLR (e.g. USSD, PSI).
Up

5.2.3  Mobile Terminating Roaming Forwarding Call after successful Retrieval of Routeing Information |R10|Word‑p. 23
The information flow for mobile terminating roaming forwarding (MTRF) call after successful retrieval of routeing information is shown in Figure 4c. It applies to a mobile terminating call while the called mobile is simultaneously moving from an old to a new MSC, if the old and the new terminating MSC/VLRs support the MT Roaming Forwarding procedure. The HLR should also support the Mobile Terminating Roaming Forwarding procedure in order to ensure that roaming forwarding can be offered in all scenarios (e.g. in case of IMSI in the LAU Request from UE).
The new terminating VLR shall include an MTRF Supported flag in the MAP Update Location message sent to the HLR. If the HLR authorises the MTRF call between the old and the new terminating MSCs, the HLR shall include the MTRF Supported And Authorized flag and the new MSC/VLR numbers in the MAP Cancel Location message sent to the old VLR. Otherwise if the HLR disallows the MTRF call between the old and the new terminating MSCs, the HLR shall include the MTRF Supported And Not Authorized flag in the MAP Cancel Location message sent to the old VLR. The new VLR may also signal the MTRF Supported flag and the new MSC/VLR numbers in the MAP Send Identification message to indicate to the old VLR that it supports MTRF.
An HLR supporting the "mobile terminating roaming forwarding" feature shall always send a MAP Cancel Location message message to the old VLR upon receipt of the MAP Update Location from the new VLR. This shall also apply if the HLR and the old VLR support Super-Charger (see TS 23.116), regardless of whether the new VLR indicates or not during the location update procedure that the previous network entity must be notified.
If the old VLR receives a MAP Send Identification message containing the MTRF Supported flag it shall not trigger any MAP Provide Roaming Number request to the new terminating VLR until is has received the MAP Cancel Location message.
Upon receipt of a MAP Cancel Location message while ongoing paging, if either of the following is true:
  • the MAP Cancel Location message includes the MTRF Supported And Authorized flag or;
  • the MAP Cancel Location message does not include the MTRF Supported And Not Authorized flag and the old VLR has received the MTRF Supported flag earlier in the MAP Send Indentification message,
the old VLR shall send a MAP Provide Roaming Number request (including the MTRF Indicator and the parameters received from the HLR in the MAP Provide Roaming Number) to the new terminating VLR. The new terminating MSC/VLR shall then allocate an MSRN to allow the call to be routed from the old MSC to the new MSC and send it to the old VLR within the MAP Provide Roaming Number response.
(not reproduced yet)
Figure 4c: Information flow for a mobile terminating roaming forwarding call after successful Retrieval of Routeing Information
Up
The sequence follows the normal MT terminating call with the following differences:
Step 1.
If the Location Update Request contains a valid TMSI/old LAI (e.g. not after the old VLR restart), a new MSC/VLR supporting the MTRF feature may include the MTRF Supported flag and the new MSC/VLR numbers in the MAP Send Identification to the old VMSC.
The new VLR shall not include the MTRF Supported flag in the MAP Send Identification message sent to the old VMSC if the Location Update message received from the MS indicates a CS fallback mobile originating call.
An old VLR supporting the MTRF feature may indicate in the MAP Send Identification response sent to the new VLR whether there is a pending mobile terminating call at the old VLR.
Step 2.
A new MSC/VLR supporting the MTRF feature includes the MTRF Supported flag in the MAP Update Location message sent to the HLR, unless the Location Update message received from the MS indicates a CS fallback mobile originating call.
Step 3.
Upon receipt of a MAP Update Location including the MTRF Supported flag, an HLR supporting the MTRF feature decides whether to authorise MTRF call between the old and the new MSCs based on roaming agreements with the old and the new MSCs. If MTRF is authorised, the HLR includes the MTRF Supported And Authorized flag and the new MSC/VLR numbers in the MAP Cancel Location message sent to the old VLR. If MTRF is not authorised, the HLR includes the MTRF Supported And Not Authorized flag in the MAP Cancel Location message sent to the old VLR.
Step 4.
Upon receipt of a MAP Cancel Location message while on-going paging and if it includes the MTRF Supported And Authorized flag or if the MAP Cancel Location message does include neither the MTRF Supported And Authorized flag nor the MTRF Supported And Not Authorized flag but the old MSC/VLR had received earlier the MTRF Supported flag at step 1, the old MSC/VLR stops paging.
Step 5.
If it supports MTRF and decides to apply MTRF based on local operator policy and optionally roaming agreements with the HLR and new MSC for MTRF, it sends a MAP Provide Roaming Number request (including the MTRF Indicator and the parameters received from the HLR in the MAP Provide Roaming Number) to the new terminating VLR.
If the the MAP Cancel Location message does not include the MTRF Supported And Authorized flag and it did not receive the MTRF Supported flag at step 1 or if the MAP Cancel Location message includes the MTRF Supported And Not Authorized flag, the old MSC/VLR may initiate the MT Roaming Retry procedure as per subclause 5.2.1.
If the old MSC supports both the MT Roaming Retry and the MT Roaming Forwarding procedures, and if the conditions for using these procedures are met, the MSC can decide based on operator policy which procedure to follow.
Step 6.
Upon receipt of the MAP Provide Roaming Number Request, the new MSC/VLR may check roaming agreements with the HLR and the old MSC for MTRF.
The new MSC/VLR may reject the MAP Provide Roaming Number Request with a cause indicating that the subscriber is busy if it has received from the MS a CM Service Request indicating a CS mobile originated call.
If the new VLR rejects the MTRF request, the new VLR returns a negative response to the old VLR.
As an option, the new MSC/VLR may check whether it also performs the GMSC function for the call by comparing the GMSC address received in the MAP Provide Roaming Number with its own MSC address. If so, the GMSC / new MSC/VLR may proceed as shown in figure 4ca to deliver the MT call directly to the UE without further involving the old MSC/VLR.
Step 7.
If the new VLR accepts the MAP Provide Roaming Number request, upon successful completion of the MAP Update Location procedure with the HLR, the new MSC/VLR allocates an MSRN to allow the call to be routed from the old MSC to the new MSC. As an implementation option, the new MSC/VLR may allocate an MSRN before completion of the MAP Update Location procedure with the HLR.
Step 8.
The new MSC/VLR sends MSRN to the old VLR within the MAP Provide Roaming Number response.
Upon receipt of the MSRN from the new MSC/VLR, the old MSC/VLR terminates any on-going Camel transaction.
Step 9.
Receipt of the MSRN from the new MSC/VLR enables the old MSC to relay the call towards the new MSC.
Step 10.
If the IAM message is received before the Location Update procedure is completed with the MS, the new MSC may delay the setup of the call until the completion of the Location Update procedure or start at once the normal terminating call procedure. In the former case, if the Location Update is received with the "follow-on" indication and if the MSC supports the "follow-on" indication, the incoming IAM may either be handled as a waiting call or forwarded as Busy (CFB), depending on the state of the "follow-on" call and the subscriber's subscription data.
The Location Update Accept message may be sent to the MS at any time after receipt of the MAP Update Location Ack from the HLR, i.e. the location update procedure with the MS is not affected by the MT Roaming Forwarding procedure.
If no MAP Provide Roaming Number request has been received at the time the Location Update procedure completes, the new MSC may shortly defer the release of the signalling connection with the MS if the old VLR indicated in the MAP Send Identification response that there is a pending mobile terminating call at the old VLR.
The MAP Update Location message and Send Identification message may include the new LMSI allocated by the new terminating MSC/VLR if the MTRF Supported flag is present in those messages. If available, the HLR shall include the new LMSI in the MAP Cancel Location message it sends to the old VLR if the MTRF Supported And Authorized flag is present in this message. If available, the old VLR shall include the new LMSI in the MAP Provide Roaming Number message it sends to the new VLR.
A VLR may also set the MTRF Supported flag in the MAP Update Location message it sends to the HLR upon establishment of an SGs association (see TS 23.272). This enables in particular mobile terminating roaming forwarding calls during the mobile terminated CS service delivery via an alternative MME in MME pool procedure when the new SGs association is established towards a new VLR (see clause 26 of TS 23.007).
The information flow for mobile terminating roaming forwarding (MTRF) call if the GSMC and the new MSC/VLR are the same node and if they support the option (in step 6) to deliver the MT call directly to the UE without further involving the old MSC/VLR is shown in Figure 4ca.
(not reproduced yet)
Figure 4ca: Information flow for a mobile terminating roaming forwarding call after successful Retrieval of Routeing Information with MTRF Optimal Routing when the GMSC and the new MSC/VLR are the same node
Up
The sequence follows the normal flow for MTRF call after successful Retrieval of Routeing Information (as specified in figure 4c) with the following differences:
Step 1.
The GMSC shall include the GMSC address and the Call reference number used by the GMSC for this call in the MAP Send Routing Information . The HLR shall include these parameters in the MAP Provide Roaming Number if received in the MAP Send Routing Information.
Step 2.
Steps 1 to 5 as specified for figure 4c.
Step 3.
The new MSC/VLR shall determine that it also performs the GMSC function for the call identified by the Call Reference Number if the GMSC address received in the MAP Provide Roaming Number matches its own MSC address.
Step 4.
In that case, the GMSC shall send a Release message to the old MSC/VLR. Upon receipt of this message, the old MSC/VLR shall return a Release Complete message to the GMSC.
Step 5.
The new MSC/VLR shall close the MAP Dialogue (initiated in step 3) locally (i.e. MAP-Close service with the release method set to "pre-arranged end"). Alternatively, the new MSC/VLR may send a MAP Abort message to the old MSC/VLR after receiving the Release Complete message. The old MSC/VLR shall release all resources associated to the call (if not already done at step 4).
Up

5.2.4  Mobile Terminating Roaming Forwarding Call during Retrieval of Routeing Information |R10|Word‑p. 29
The information flow for mobile terminating roaming forwarding (MTRF) call during retrieval of routeing information is shown in Figure 4d. It applies to a mobile terminating call while the called mobile is simultaneously moving from an old to a new MSC, if the old and the new terminating MSC/VLRs support the MT Roaming Forwarding procedure. The HLR should also support the Mobile Terminating Roaming Forwarding procedure in order to ensure that roaming forwarding can be offered in all scenarios (e.g. in case of IMSI in the LAU Request from UE); an HLR that supports Optimal Routeing shall support the requirements defined in this clause to ensure that charging requirements for optimal routeing are never contravened. The procedure may e.g. apply during pre-paging if the GMSC, HLR and old MSC/VLR support pre-paging.
The principles and requirements specified for MT Roaming Forwarding Call after successful Retrieval of Routeing Information (see clause 5.2.3) shall also apply for MT Roaming Forwarding Call during Retrieval of Routeing Information with the following modifications or clarifications.
When an MSRN is retrieved successfully from the new MSC/VLR, the old MSC/VLR shall return the received MSRN within the MAP Provide Roaming Number response to the HLR, which allows the call to be routed from the GMSC to the new MSC.
(not reproduced yet)
Figure 4d: Information flow for a mobile terminating roaming forwarding call during Retrieval of Routeing Information
Up
The sequence follows the normal MT terminating call with the following differences:
Step 1-2.
Same as steps 1 and step 2 in Figure 4c.
Step 3.
Same as step 3 in figure 4c, with the addition that the HLR shall not authorise MTRF between the old and the new MSCs if routing the call between the GMSC and the new MSC contravenes charging requirements if Optimal Routeing is supported (see TS 23.079).
Step 4.
Same as step 4 in Figure 4c, where the old MSC/VLR stops pre-paging.
Step 5.
Same as step 5 in Figure 4c.
Step 6.
Same as step 6 in Figure 4c. If the OR interrogation indicator is received in the PRN request, the new VLR shall return a PRN negative response if it does not support Optimal Routeing (see TS 23.079).
Step 7.
Same as step 7 in Figure 4c.
Step 8.
The new MSC/VLR returns to the old VLR a MAP Providing Roaming Number response including the MSRN, the new VMSC Address, and if the new MSC/VLR supports the MAP Release Resource procedure, the ReleaseResourcesSupported flag.
Step 9.
Upon receipt of the MSRN from the new VLR, the old VLR returns the PRN Ack to the HLR including the MSRN and the VMSC Address received from the new VLR, and the ReleaseResourcesSupported flag if received from the new MSC/VLR.
Step 10.
If the HLR needs to return the VMSC Address to the GMSC (as per the conditions specified in TS 29.002), and if a VMSC Address was received with an MSRN in the PRN Ack, the HLR shall pass in the SRI ack to the GMSC the MSRN and the VMSC Address received in the PRN ack.
Receipt of the MSRN from the HLR enables the GMSC to relay the call towards the new MSC.
Step 11.
Same as step 10 in Figure 4c.
Up

5.3  Information flow for an MT callWord‑p. 31
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 Iu interface (for UMTS) or the A interface (for GSM) 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.
(not reproduced yet)
Figure 5: Information flow for a basic mobile terminated call
Up
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 recognizes 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 TS 23.060) 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 TS 33.102 for UMTS and TS 43.020 for GSM. VLRB may also initiate security procedures at this stage, as described in TS 33.102 for UMTS and TS 43.020 for GSM.
If the MS is paged in a CSG cell, VLRB shall control if the CSG cell is allowed by the CSG subscription data stored in VLRB. If the CSG cell is not allowed, VLRB shall reject the the Process Access Request.
If the MS is paged 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.
VLRB may restore CSG data from CSS for a MT call after a VLRB restart.
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 security procedures message towards BSSB; if VMSCB has not received a Start security procedures message from VLRB, the Start security procedures message 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.
  • Up


    Up   Top   ToC