GSM CALL PATH COURSE

CALL DELIVERIES, VMSC DEFINITION OF VMSC NETWORK SIGNALLING FLOW FOR CALL DELIVERY TO THE VMSC EXAMPLE OF CALL DELIVERY IN THE VMSC Assumptions Steps for the MAP signalling phase in the VMSC MAP-PRN Message Received Analysis of BC Assignment of an MSRN MAP-PRN-Ack Message Sent Signalling Flow on A-interface for a Speech Call To an MS Steps for the call set up in the VMSC OIP-IAM Received and Initiation of Call Path Analysis of BC Seizure of Connection Service, Charging and CC layer Paging Preparation and Paging Message Sent Paging Response Message Received Paging Response Process Finds Paging Request Process Security Related Functions Joining of Call Paths and Verification of Features Setup Message Sent and Call Confirmed Message Received Channel Assignment Alerting Message Received, OIP-ACM Sent Connect Message Received, OIP-ANM Sent Mobile Terminated Call Path

CALL DELIVERY, VMSC Definition of VMSC

The VMSC (Visited Mobile Switching Center) is the MSC within a mobile call delivery scenario where an MS (Mobile Station) receives a call, i.e. where the terminating mobile call path is set up. The VMSC is the MSC where the MS last registered and is pointed to by the subscriber location within the HLR at call delivery. The VMSC is also known as the MSC/VLR; hence these two terms will be used interchangeably in this document.

Network Signalling Flow for Call Delivery to the VMSC

A. The GMSC call scenario is initiated by a TRAM (TRansit AM) receiving an OIP-IAM (Initial Address Message) message and the B- number analysis associated to this message leads to the seizure of a GRI (Gmsc Roaming Interrogation) route. The OIP-IAM is sent to TRAM by its incoming side, which can be an ISUP trunk, an originating mobile or any device/subsystem that can initiate a call process. In the case of a trunk, the call (most probably) originated in another node. Therefore, INC in figure 1 above represents the TRAM and any GMSCHLRA.IAM (or equivalent message) ISUP (or OIP or other protocol) OUT/INCINCVMSCC.Provide Roaming NumberMAP E.Send Routing Information Ack. MAP F.IAM (or equivalent message) ISUP (or OIP or other protocol) F.IAM (or equivalent message) ISUP (or OIP or other protocol) G.ACM (or equivalent message) ISUP (or OIP or other protocol) G.ACM (or equivalent message) ISUP (or OIP or other protocol) H.ACM (or equivalent message) ISUP (or OIP or other protocol) I.ANM (or equivalent message) ISUP (or OIP or other protocol) I.ANM (or equivalent message) ISUP (or OIP or other protocol) J.ANM (or equivalent message)

ISUP (or OIP or other protocol) MAP B.Send Routing InformationMAP D.Provide Roaming Num Ack potential incoming side to the TRAM, as well as any previous node involved in this call. B. Using the MSISDN (dialled digits), the GMSC contacts the HLR for information about the subscriber being called in order to determine how to route the call. The GMSC sends a MAP-SRI (Send Routing Information) message to the HLR for this purpose. The assumption in this example is that the MS is in idle state and IMSI attached to a VMSC (MSC/VLR) and thus the location in the HLR is set. C. Upon reception of the MAP-SRI message, the HLR uses the MSISDN within the message to find the subscriber profile within its database. The HLR profile contains all the relevant subscriber data. After a list of checks to determine if certain features that need to be triggered prior to call delivery are applicable, the HLR sends a MAP-PRN (Provide Roaming Number) to the VMSC pointed to by the location data within the subscriber profile. D. Upon receiving the MAP-PRN message, the VMSC (MSC/VLR) assigns an MSRN (Mobile Station Roaming Number) to this call. The MSRN temporarily represents the called subscriber within the VMSC and thus will allow the call to be routed from the GMSC to the VMSC. Note that the GMSC and VMSC parts of a call delivery scenario can be located within the same node. The VMSC returns the MSRN within the MAP-PRN-Ack message to the HLR. E. The HLR in turn forwards the MSRN to the GMSC within the MAP-SRI-Ack message. F. The GMSC then seizes a new TRAM on its outgoing side and sends it an OIP-IAM with the MSRN as the dialled digits. Analysis of this OIP-IAM within the TRAM should lead to either an outgoing trunk route or to a mobile termination if the GMSC and VMSC are within the same MSC. Note the OUT in figure 1 above represents the TRAM and any potential outgoing side to the TRAM, as well as any transit node that may exists between the GMSC and VMSC for this call. If the GMSC and VMSC are within the same node, then OUT is simply the TRAM. G. Eventually it is assumed that as a result of the OIP-IAM and any subsequent signalling, such as an ISUP-IAM, the call successfully progresses to the VMSC. Once the call reaches its destination and the subscriber is found to be idle, an ACM (Address Complete Message) type message is expected to make its way back through the call chain. Eventually the GMSC receives an ACM type message. H. Upon receiving the ACM type message, the GMSC stores certain data found within the ACM (i.e. billing data) and transits the ACM to its incoming side, INC. I. It is also assumed that the call is eventually answered. As a result, an ANM (ANswer Message) type message is expected to makes its way back through the call chain. Eventually the GMSC receives an ANM type message.

J. Upon receiving the ANM type message, the GMSC stores certain data found within the ANM (i.e. billing data) and transits the ANM to its incoming side, INC.

Example of Call Delivery in the VMSC

This section describes the call delivery process in the VMSC for a call delivery to an idle MS.

Assumptions

While there could be several reasons for a terminating call process to fail in the VMSC, this example assumes that all goes well. Some of these failure reasons are mentioned at the appropriate points in the process, but the details are never shown for it is assumed that the process proceeds successfully. There are several features and services that can be triggered during a call delivery process. Some of the trigger points for these features and services are mentioned at the appropriate points in the process but most details are not shown for it is assumed the most features or services are not applicable to this call scenario. In the example below, it is assumed that the MS (Mobile Station) already has a VLR record in the VMSC at the time of the call delivery. This is obviously the most common scenario for a terminating call and implies the mobile has previously registered (IMSI attach or Location Update) in this MSC. It is also assumed that the MS is not involved in any other process (e.g. registration, call origination, SMS, etc.) other than the call termination. This process takes place in an ANSI signalling environment. In other signalling environments (ITU, MPT, TTC, etc.) the TCCSE interface would be a little different. Note that there are two main phases in call delivery process within the VMSC. The first phase is the MAP signalling phase where the VMSC assigns an MSRN (Mobile Station Roaming Number) and the second phase is the call set up to the VMSC.

Steps for the MAP signalling phase in the VMSC

The call delivery process in the VMSC begins with the reception of the MAP-PRN message. The lower layers of the CCS (Common Channel Signalling) subsystem within the VMSC, MTP and SCCP, forward the message to the TCAP (Transaction Capabilities Application Part) layer. Then the TCCSE (Transaction

Capabilities application part SErvice) initiates a session with the appropriate TCuser for the MAP-PRN message. The main steps in the process are numbered in all the figures and correspond to the written explanations. Note that most but not all of the signals involved in the process are mentioned in the diagrams and explanations. Also note that the signal sequence is preserved as best as possible. However, there are cases where for simplicity and clarity purposes, the signals are not presented in the exact order.

MAP-PRN Message Received

1. Upon receiving the TCAP message associated with the MAP-PRN message, the TCCSE (Transaction Capabilities application part SErvice) initiates a session with a TC-user, which it identifies (via the SSN (SubSystem Number) as MAPTC1. Block C7TCP2 sends G7BEGININD to MAPTC requesting the seizure of an internal dialogue (i.e. link). This signal indicates the reception of a begin transaction message from a remote node. MAPTC verifies that the called and calling addresses included in this signal are valid and then seizes an individual. The term dialogue here is not to be confused with the dialogue portion of a TCAP message. 2. MAPTC asks C7TCP to change the calling address for the return message (i.e. own address) to the same format (national or international) of the called address for the return message (i.e. HLR address) so that both addresses have the same nature in the return message. This is accomplished with combined signal pair G7CHANGEADDR/ACK. MAPTCCCSC7TCPHLRMRNAP1G7BEGININD2G7CHANGEADDR / ACK3C7DPINFCBREQ / ACK4C7DIALCBINDR6aMDIALSEIZREQ6eMDIALGRANTED5C7INVOKECBINDMSNAN MTV7bMINVOKECBINDMAP Provide Roaming Number TCAP Begin & Invoke & Dial.Req. SCCP UDT (Connectionless) MABCMUABC7aC7CHTCUREF / ACK8C7OPCBINDR9aFORWARDPLMNBC9bFORWARDPLMNBCMTECA10cMPRNTSA / ACK 10bABCPRN 11aIDENTIFYSUB 12bIDENTIFYSUBR 11bIDENTIFYMS / ACK 12aPREVENTDISC / ACK 6b/dSEIZEMABC / ACK6cSEIZEMUABC / ACK MAPTC10aCONTINUEB 1 MAPTC - Mobile telephony Application Part incoming Transaction Coordinator

MAPTC is an MDS block that contains functions for the following: setup of incoming dialogues for Mobile Application Part (MAP) operations, management of the international and national own calling addresses for MAP in the MSC/VLR, initiation of policing for MAP operations received in the MSC/VLR, SMS-GMSC and SMS-IWMSC. 2 C7TCP Ccitt 7 Transaction Capabilities Procedure C7TCP is a CCS block that controls all procedures on Dialogue/Transaction and Operation level. It takes all the decisions that are related to the TC protocol. It handles the complete interface to both the TC-user and the SCCP layer. 3 MAPTC asks C7TCP to send information from the dialogue portion of the TCAP message with forward combined signal C7DPINFCBREQ. MAPTC is interested in the ACN (Application Context Name). C7TCP provides the CB512 (Communication Buffer - 512bytes) pointer within which the ACN is located with backward combined signal C7DPINFCBREQACK. MAPTC reads the ACN, which later will be used at step 5 to determine the signalling user in the VMSC for this message. 4. MAPTC then acknowledges the establishment of an internal dialogue (i.e. link) to C7TCP by providing its pointer in signal C7DIALCBINDR. Note this is a return signal to G7BEGININD at step 1 above. The C7DIALCBINDR signal returns control of the CB512 back to C7TCP and also informs TCCSE that the TCuser (MAPTC) is ready to receive the component portion of the TCAP message. Once again, the term dialogue here is not to be confused with the dialogue portion of a TCAP message. 5. MAPTC then receives the component portion of the message in signal C7INVOKECBIND. As the signal name implies, it is an invoke component type message. This signal provides the CB512 pointer (same as in previous step) of where the message is stored. MAPTC first reads the MOPCODE (Mobile OPeration CODE, number specifying MAP message type) and then uses this MOPCODE and the ACN acquired at step 3 to determine the VMSC signalling user for this message, MRNAP3. 6. MAPTC orders the seizure on an internal dialogue (i.e. a link) to MRNAP with signal MDIALSEIZREQ. The MRNAP block seizes one of its own individuals and then immediately seizes an MABC4 individual as a side link with combined signal pair SEIZEMABC/ACK. MABC in turns uses nested combined signal pair SEIZEMUABC/ACK to seize its corresponding MUABC5 individual. Note the MABC and MUABC individuals share the same pointer, hence the same file size. MRNAP responds to MAPTC with its pointer in signal MDIALGRANTED. Once again the term dialogue here is not to be confused with the dialogue portion of a TCAP message. MAPTC has identified and seized the appropriate signalling user block for this

message. From this point onwards MAPTC is no longer required. MAPTC will link out, thus making MRNAP the TC-user. 7. MAPTC asks the TCCSE to change link to MRNAP with combined signal pair C7CHTCUREF/ACK to C7TCP. This action replaces MAPTC with MRNAP as the 3 MRNAP Mobile telephony Roaming Number provision mAP MRNAP is an MDS block that handles the MAP-PRN message from the HLR for MAP version 3, version 2 and version 1. It also coordinates roaming number provision when an MS in the MSC/VLR is called. 4 MABC - Mobile telephony Analysis of Bearer Capabilities (GSM) MABC is an MSS (Mobile Switching Subsystem) block that is responsible for the PLMN Bearer Capability and Basic Service Code handling in the MSC/VLR. MABC includes the radio channel parameter handling for traffic channel assignment. 5 MUABC - Mobile telephony Analysis of Bearer Capabilities (UMTS) MUABC is an MSS (Mobile Switching Subsystem) block that is responsible for the bearer capability handling and basic service code handling in the MSC/VLR server for UMTS calls. TC-user. MAPTC forwards the CB512 pointer that contains the component portion of the TCAP message to MRNAP with signal MINVOKECBIND. After sending this signal, MAPTC drops off to idle. 8. MRNAP locally stores all the parameters found within the CB512. MRNAP then acknowledges signal C7INVOKECBIND with signal C7OPCBINDR directly to C7TCP, indicating that the complete TCAP message and its associated CB512 can now be released. 9. MRNAP validates the parameters received to ensure that they are in the correct format. This process can be lengthy and thus may require phase division with CONTINUEB signals. In this example the GSM/PLMN BC (Bearer Capability) parameter is received, which MRNAP sends to MABC and then onwards to MUABC with signal FORWARDPLMNBC. 6.3.2.2 Analysis of BC

Analysis of bearer capabilities

Analysis of bearer capabilities is partly the negotiation of the BC (Bearer Capabilities) between the MSC/VLR and the MS. During this process the MSC/VLR determines the final values of certain PLMN bearer capability parameters taking into account the MSs capabilities and preferences (e.g.

classmark) and the MSCs capabilities. The analysis of bearer capabilities also involves the determination of the BASC (BAsic Service Code, either a teleservice or bearer service) that is checked against the subscribed BASCs. 10. After sending itself the final CONTINUEB signal, MRNAP initiates the early analysis of the bearer capabilities received in the MAP-PRN message by sending signal ABCPRN to MABC. MABC then uses the BC received to generate a BASC (BAsic Service Code, either a teleservice or bearer service), which in this case turns out to be teleservice telephony. MABC then asks MTECA6 to analyze telecommunication services based on the BASC with combined signal pair MPRNTSA/ACK. MTECA determines whether the telecommunication service requested by the MS is available in the system. 11. MABC orders the identification of the subscriber with signal IDENTIFYSUB to MRNAP. MRNAP then uses the mandatory parameter IMSI received in the MAPPRN message to identify the VLR record with combined signal pair IDENTIFYMS/ACK to block MSNAN7. MSNAN performs mobile digit analysis on the IMSI in order to find the MTV8 individual assigned to the subscriber. 6 MTECA Mobile telephony TeleCommunication service Analysis MTECA is an MSS block that performs telecommunication service analysis (TSA) for single-slot and multi-slot services, stores the TSA related data and performs compatibility check for mobile terminating calls. 7 MSNAN - Mobile telephony Subscriber Number ANalysis MSNAN is an MDS (Mobile Data Subsystem) block that translates an IMSI of an MS into an internal address pointing to the data of that subscriber, i.e. MTV pointer. 8 MTV - Mobile Telephony Visiting subscriber MTV is an MDS block that handles mobile subscriber data stored within MSC/VLR. Some of MTVs functions are: handles the registration of new mobile subscriber entering the area of MSC/VLR, stores mobile subscriber general data, answers requests for information, deregistering of mobile subscribers from the VLR and marking the state of the subscriber to detach/attach. If the VLR is not found, then a new VLR is seized and the subscriber profile is fetched from the HLR before proceeding.

12. MRNAP uses combined signal pair PREVENTDISC/ACK to remove MTV from the suitable list and thus ensure the MTV will not be disconnected during this process. An MTV may be disconnected and used by another MS when not enough MTV records exist within the VLR, a process known as recycling. MRNAP replies to MABC with signal IDENTIFYSUBR containing the MTV pointer. MAP-PRN (Provide Roaming Number) Parameters The MAP-PRN message (3GPP TS 29.002 Rel. 5) contains several mandatory and many conditional parameters. Only the parameters that are mentioned in this example are presented below. IMSI - is the International Mobile Station Identity, a number that uniquely identifies a subscriber within the PLMN network. IMSI is a mandatory parameter. VMSC Number - this mandatory parameter is the ISDN number assigned to the MSC currently serving the MS. The MSC number is stored in the HLR as provided at location updating. The Ericsson MSC/VLR ignores this parameter. MSISDN - it is the Mobile Subscriber ISDN number assigned to the called subscriber. LMSI - the Local MS Identity parameter refers to a local identity allocated by the MSC/VLR to a given subscriber for internal management of data in the MSC/VLR. The Ericsson MSC/VLR does not use this parameter and thus the LMSI will never exist for a MS roaming within an Ericsson MSC/VLR. GSM Bearer Capability - this optional parameter whose purpose is to describe a bearer service. The GSM Bearer Capability information element is used for compatibility checking. Call Reference Number - this parameter refers to a call reference number allocated by a call control MSC, described after step 18 below as the NCR number. This parameter is obtained from the GMSC in the MAP-SRI message. GMSC Address - this conditional parameter refers to the E.164 address of a GMSC. OR Not Supported in GMSC - this optional parameter indicates that the GMSC does not support the OR (Optimal Routing) functionality. Supported Camel Phase in interrogating node - this optional IE lists the supported CAMEL phases in the GMSC. This parameter is obtained from the GMSC in the MAP-SRI message. Calling Party Number and Category - the sending of this private parameter in the protocol extension area is an Ericsson proprietary service; see FSs

(Function Specifications) Protocol Specification for Sending of Calling Party Number and Category in GMSC and Sending of Calling Party Number and Category to HLR at Mobile Terminating Call in GMSC for more details. 13. MABC proceeds with the analysis of the bearer capabilities by doing a subscription check. MABC fetches the MSs subscribed BASC list. This is accomplished by using combined signal pair FETCHSUBSCR/ACK to MRNAP. MRNAP then sends nested combined signal pair SUBSCRANA/ACK to MTV. MTV in turns sends another nested combined signal pair, CHKSUBSCRBSG/ACK, to MTVS9. MTVS returns a list of bearer services and teleservices that the MS is subscribed to. MABC performs a subscription check to determine if the MS is subscribed to the BASC required for this call. MABC returns the final result of analysis of bearer capabilities in signal ABCPRNR to MRNAP. This is the return signal to ABCPRN at step 10. CCSC7TCPHLRMRNAPMTVMABCMUABC13fABCPRNR MTVS15aZCFRRCHK15bFETCHZCDATA / ACK15cZCFRRCHKR13cCHKSUBSCRBSG/ ACK 13b/dSUBSCRANA/ ACK14bFETCHSSALL/ ACK 14a/cREADMTVDA1 / ACK13a/eFETCHSUBSCR/ ACK MZONEMZONE Note that for simplicity purposes the side links to MTV, such as MTVS, are only shown in the figures when information from these side links is accessed. 14. MRNAP reads more subscriber data from MTV with combined signal pair READMTVDA1/ACK in order to check if the MS is attached or detached. If detached, MRNAP then checks local parameter PROVONDETACH to determine 9 MTVS Mobile Telephony Visiting Subscriber services MTVS is an MDS block that handles data concerning the basic and the supplementary services of the visiting mobile subscriber. An MTVS individual shares the same pointer and file size as MTV. if it still needs to send an MSRN back to the GMSC or an absent subscriber indication. It is assumed in this example that the MS is attached. MTV fetches some of required data from MTVS with nested combined signal pair FETCHSSALLACK. MRNAP stores the MSISDN and the various roaming restriction features information received in READMTVDA1ACK. 15. If the MS is attached and has no roaming restrictions and if any of the regional services (local subscription, regional subscription and subscription with tariff areas) are supported in the MSC, MRNAP orders MZONE10 to check

roaming restrictions due to regional services with signal ZCFRRCHK. MZONE dedicates an individual to this task. This individual then fetches the zone code set from the MTV with combined signal pair FETCHZCDATA/ACK. The VLR zone code data is stored in block MTVZONE11; however in this example, since the MTV individual has no link to MTVZONE, it knows there is no zone code data and indicates this to MRNAP with signal ZCFRRCHKR. As a result, the process successfully proceeds. See FSs (Function Specifications) Local Subscription in MSC/VLR Server, Regional Subscription in MSC/VLR Server, Subscription with Tariff Areas in MSC/VLR Server and Regional Services in HLR for more details on the regional services feature. 10 MZONE - Mobile telephony regional services MZONE is an MDS block that stores zone code data and analyzes subscriber-related regional services data. 11 MTVZONE - Mobile Telephony Visiting ZONE code MTVZONE is an MDS block that is used to store, retrieve, write and delete zone codes and associated data for a mobile subscriber.

Assignment of an MSRN

16. Before roaming number allocation, MRNAP fetches the subscribers LA (Location Area) pointer with combined signal RMMDATA1/ACK. It then determines if the subscriber is idle or busy with combined signal pair READCMSTATUS/ACK. Note in this example, it is assumed the subscriber is idle. If the subscriber is busy, then MRNAP reads the CGI (Cell Global Identity) in order to determine the subscribers LA. 17. MRNAP requests a roaming number from block MRNR12 with signal REQMSRN3, which includes the IMSI, LA and other parameters. MRNR then attempts to convert the LA into a LATA (Local Access Transport Area) with combined signal pair LOCTOLATA/ACK to block MBSSD13. MRNR assigns an MSRN (Mobile Station Roaming Number) record based on the MSRN allocation method defined (MT exchange property MSRNHOMETHOD) and whether or not CCSC7TCPHLRMRNAPMTVMABCMUABCMRNR17aREQMSNR317cREQMSRNRMBSSD 17bLOCTOLATA / ACK16aRMMDATA1 / ACK 16bREADCMSTATUS / ACK 18aSTOREHLRDATA4 / ACK18bSTOREHLRDATA5 / ACK19ALLOWDISC / ACK 12 MRNR Mobile Telephony Roaming Number Routing MRNR is an MDS block that holds the roaming number series and provides roaming numbers for

routing of terminating calls from GMSC Server and handover numbers for routing handover calls from anchor-MSC. In case of an incoming call from the GMSC the MSRN is passed to subsystem MSS. In case of a handover call the seizure is forwarded to the subsystem MMS. 13 MBSSD - Mobile telephone BSS Data MBSSD is part of MMS and administers a database of traffic data for cells (local and outer), BSCs, RNCs, LATAs and LAs. It also converts CGIs and LAs to pointers and vice versa, as well as other conversions such as cells to LAs. MBSSD also stores LNs (Location Numbers), ERNs (Emergency Routing Numbers) and E911M (Enhanced 911 Mechanism) data. the LATA is known. MT exchange property MSRNHOMETHOD determines whether the allocation of numbers for roaming and handover are from the same or from different pool of numbers. The IMSI is stored within the MSRN record and the MSRN number is sent to MRNAP in return signal REQMSRNR. The relationship between the MSRN and the IMSI is a time supervised relationship that lasts until the call is delivered to the VMSC or time out. The length of the timer is also an MT exchange property, MSRNTCNTIME. 18. MRNAP transfers data to MRNR which was received from the HLR in the MAP-PRN message to be stored for future use. This data is stored in the MSRN record because it is call specific data that will be used when the call is delivered to the VMSC. MRNAP uses combined signal pair STORHLRDATA4/ACK to store the GSM/PLMN BC and combined signal pair STORHLRDATA5/ACK to store the NCR (Network Call Reference) number, the OR Not Supported in GMSC indication, the Supported Camel Phase in interrogating node and the GMSC address. Note that other signals with data would also be sent if other parameters were received in the MAP-PRN message. NCR (Network Call Reference) The NCR number, referred to as the CRN (Call Reference Number) parameter in the specification, provides a mechanism for the post-processing system to link together different call data records produced for a call or, when multi party supplementary service invokes several related calls within a node. As an option, call data records produced in different nodes for the same call can contain the same NCR, if the signalling transfers the NCR between different nodes. 19. MRNAP is ready to reply to the HLR but first disconnects itself from the MTV record. MRNAP sends combined signal pair ALLOWDISC/ACK to MTV in order to remove the prevent disconnection indication in MTV which it set at step 12 above.

MAP-PRN-Ack Message Sent

At this point, MRNAP needs to build the MAP-PRN-Ack message and send it back towards the HLR in which it will include the MSRN. CCSHLRMRNR20aC7DIPORTREQ20bC7DIPORTREQACC21aC7RESULTREQ21bC7RESUL TREQACC22aC7ENDREQ 22bC7ENDREQEXEC23aDISCMABC23bDISCMUABC23cDISCMUABCR23dDISCMABCRM AP Provide Roaming Number Ack TCAP -End & Result & DialogueResp. SCCP UDT (Connectionless) MABCMABCMUABCMUABCC7TCPC7TCPMRNAPMRNAP 20. MRNAP then asks that an ACN (Application Context Name) be sent in the dialogue portion of the TCAP message with signal C7DIPORTREQ. C7TCP replies with C7DIPORTREQACC providing a DB (Dynamic Buffer) address where MRNAP can store the ACN (Application Context Name). By returning to the HLR the same ACN that was received, the VMSC indicates to the HLR that the dialogue (e.g. MAP version) has been accepted. Note the TCCSE uses its own DBs (Dynamic Buffers) in which it builds or receives messages. It then asks the TC-users (e.g. MRNAP) to read or write information directly into or from the DB, thus saving PLEX signalling. 21. MRNAP then requests that a component portion be included in the TCAP message with signal C7RESULTREQ. As the signal name implies, it is a request for an RR (Return Result) component type message. C7TCP prepares the component portion and provides MRNAP with the DB address of where to store the MAP-PRN-Ack message in signal C7RESULTREQACC. MRNAP then stores the MOPCODE of the MAP-PRN-Ack message and the only parameter for the message, the MSRN.

22. MRNAP then orders the sending of the TCAP message with signal C7ENDREQ. This signal specifies that the transaction portion have an end message type, which is always the case for the last message of a structured TCAP interaction. C7TCP confirms the sending of the message to the SCCP layer with signal C7ENDREQEXEC. At this point the C7TCP individual returns to idle. 23. MRNAP releases its link to MABC with signal pair DISCMABC/R. Upon receiving this release indication, MABC sends a nested signal pair DISCMUABC/R to MUABC. The MABC, MUABC and MRNAP individuals all return to their respective idle lists.

The signalling part of the call delivery process in the VMSC is now complete. All individuals in the VMSC that participated in the first part of the processes have returned to idle with the exception of the MSRN individual within block MRNR. Obviously, the VLR record also remains in the VMSC in the same state it was prior to the call delivery. MAP-PRN-Ack (Provide Roaming Number Acknowledgement) Parameters The MAP-PRN-Ack message (3GPP TS 29.002 Rel. 5) contains few parameters. Only the parameters that are relevant to this example are presented below. MSRN - is the Mobile Station Roaming Number, a number that is used to route the call from the GMSC to the VMSC and also used to identify the called subscriber within the VMSC. The MSRN is a conditional parameter. 6.3.3 Signalling Flow on A-interface for a Speech Call To an MS The signalling flow presented below shows the most common messages on the A-interface for a normal speech call to an MS. However, there are others messages that can optionally be sent during a call setup but are not shown below. Note that some of the signalling sequences can occur in parallel and thus some messages may enter or exit the MSC before or after the suggested flow. Also note that messages that are optional are shown with a dotted line, while information flow on the speech path is shown with dashed lines. Figure 6 A. Upon reception of an IAM type message, the MSC/VLR uses the MSRN to identify the called subscriber by finding its VLR. The MSC then sends the BSSMAP-Paging Request (IMSI, TMSI, Cell Identity List) message to each BSS within the paging scope. Each BSS sends the page out on the air interface via a CCCH (Common Control CHannel) in the hope that the destined MS will hear it. B. When the MS hears the page, it responds to the BSS, which sent it the page request. The BSS assigns a DCCH (Dedicated Control CHannel) to the MS. The MS then sends the RR Paging Response (IMSI or TMSI) message over the air interface to the BSS. MSCBSSMSD. DTAP AUTHENTICATION RESPONSESCCP Data Form 1(DT1) MOBILE TERMINATION SIGNALLING FLOW

..A-Interface....Air interface .. E. BSSMAP CIPHER MODE COMPLETESCCP Data Form 1(DT1) D. DTAP AUTHENTICATION RESPONSEChannelD. DTAP AUTHENTICATION REQUESTChannelE. CIPHERING MODE COMPLETEChannelE. CIPHERING MODE COMMANDChannelB. BSSMAP PAGING REQUESTSCCP Unit Data (UDT) B. BSSMAP-CL3I : RR-PAGING RESPONSESCCP Connection Request(CR) C. SCCP Connection Confirm (CC) D. DTAP AUTHENTICATION REQUESTSCCP Data Form 1(DT1) E. BSSMAP CIPHER MODE COMMANDSCCP Data Form 1(DT1) B. PAGING REQUESTChannelB. CHANNEL REQUESTChannelB. IMMEDIATE ASSIGNMENTChannelB. SABM (PAGING RESPONSE) ChannelB. UA (PAGE RESPONSE) ChannelF. DTAP -TMSI REALLOCATION COMPLETESCCP Data Form 1(DT1) F. DTAP -TMSI REALLOCATION COMMANDSCCP Data Form 1(DT1) F. DTAP -TMSI REALLOCATION COMPLETEChannelF. DTAP -TMSI REALLOCATION COMMANDChannelA. IAMISUP or OIP The BSS encapsulates the RR Paging Response message within a BSSMAPCL3I (Complete Layer 3 Information) message and sends this message within an SCCP-CR (Connection Request) message. C. The MSC confirms the SCCP connection request to the BSS with an SCCPCC (Connection Confirm) message to the BSS. D. If authentication is active in the MSC and it is applicable to the call scenario, then the MSC sends the DTAP-Authentication Request to the MS. The MS responds with a DTAP-Authentication Response (SRES) message. If the SRES (Signed RESponse) matches the one received from the HLR/AUC, then the authentication is considered successful and the call proceeds. E. If the ciphering feature is active in the MSC and it is applicable to the call scenario, then the MSC sends the BSSMAP-Cipher Mode Command message to the BSS. The BSS then establishes ciphering with the MS via air interface messaging and then returns the BSSMAP-Cipher Mode Complete message to the MSC. F. If TMSI allocation is active in the MSC and a new TMSI needs to be assigned to the MS, then the MSC sends the DTAP-TMSI Reallocation Command (TMSI, new LAI) message to the MS. The MS confirms the acceptance of the TMSI with a DTAP-TMSI Reallocation Complete message.

Figure 7 G. The MSC sends the call set up details in the DTAP-Setup (BC) message. This message contains all the information required by the MS to process the call. H. The MS responds to the DTAP-Setup message with a DTAP-Call Confirmed (BC) message. This message is sent by the called MS to confirm the incoming

call request. I. The MSC proceeds with the assignment of a traffic channel by sending the BSSMAP-Assignment Request (CIC) message to the BSS. This message contains the CIC (Circuit Identity Code) in order to identify the trunk device to be used on the A-interface. Once the BSS sets up appropriate traffic channel on the air interface and seizes the required trunk resources on the A-interface, it sends the BSSMAP-Assignment Complete message to the MSC. J. After channel assignment, the called MS is ready for speech and starts alerting. Thus the MS sends a DTAP-Alerting message to the MSC informing it that it is ringing. Since the B-MS is available and ringing, the MSC/VLR sends an ACM type message to its incoming side. This ACM message works its way back through the call chain informing previous nodes that the B-subscriber is ringing. K. When the called MS answers the call, it sends a DTAP-Connect message. The MSC/VLR sends an ANM type message to its incoming side. This ANM message works its way back through the call chain informing previous nodes that the B-subscriber has answered the call. The MSC acknowledges the reception of the DTAP-Connect message with the DTAP-Connect Acknowledge message. MSCBSSMSJ. DTAP ALERTINGSCCP Data Form 1(DT1) MOBILE TERMINATION SIGNALLING FLOWI. BSSMAP ASSIGNMENT COMPLETESCCP Data Form 1(DT1) I. BSSMAP ASSIGNMENT REQUESTSCCP Data Form 1(DT1) H. DTAP CALL CONFIRMEDSCCP Data Form 1(DT1) K. DTAP CONNECTSCCP Data Form 1(DT1) K. DTAP CONNECT ACKNOWLEDGETraffic ChannelL. SPEECHsymmetrical speech pathG. DTAP SETUPChannelG. DTAP SETUPSCCP Data Form 1 (DT1) H. DTAP CALL CONFIRMEDChannelI. ASSIGNMENT COMPLETEChannelI. ASSIGNMENT COMMANDChannelJ. DTAP ALERTINGTraffic ChannelK. DTAP CONNECTTraffic ChannelK. DTAP CONNECT ACKNOWLEDGESCCP Data Form 1 (DT1) J. ACMISUP or OIPK. ANMISUP or OIP ..A-Interface....Air interface .. L. At this point the speech path in the user plane is available and thus the Asubscriber and B-MS are in full two-way conversation.

6.3.4 Steps for the call set up in the VMSC

The call set up part of the call delivery process in the VMSC begins when the TRAM (TRansit AM) performs B-digit analysis and it results in an MTE (Mobile TErmination). For an MTE, TRAM identifies the outgoing EP (End Point) as being

block MOIPHI14. Therefore, the TRAM initiates the establishment of an APC (AM Protocol Carrier) session to MOIPHI. The main steps in the process are numbered in all the figures and correspond to the written explanations. Note that most but not all of the signals involved in the process are mentioned in the diagrams and explanations. Also note that the signal sequence is preserved as best as possible. However, there are cases where for simplicity and clarity purposes, the signals are not presented in the exact order. MOIPHIAPCRMPTRACOTRAM24cAPCCONNRESP24bAPCCONNIND24dAPCCONNCONF TRAM analyses detain IAM, determines outgoing EP and seize an APC link to outgoing side24aAPCCONNREQ1OIPIAM25aAPCDATACBREQ25bAPCDATACBINDMTBMRNR26M INCCONNECTOIPIAM28aPRNLADATA28bPRNDATAINFO28cPRNDATAEND1MTBCO27I NITIATEMTC / ACK27aSEIZEMTB1 / ACKMRNR27cMINCCONNECTR 6.3.4.1 OIP-IAM Received and Initiation of Call Path Figure 8 24. Once the TRAM has identified the outgoing EP (End Point) as being MOIPHI, it asks the APCSE (Am Protocol Carrier Service) within the RMP (Resource Module Platform) to open a session on the static APC link between itself and MOIPHI. TRAM knows the EPID (EP IDentity) of MOIPHI because a static APC link between them was previously established with command ARLII. Block TRACO15 within the TRAM initiates this process by sending signal 14 MOIPHI Mobile telephony OIP Handler Incoming side MOIPHI is an MSS block that provides an interface towards user blocks in 1/APT and allows communication via the OIP (Open Intra Node Protocol) to the Transit Application Module (TRAM) in case of an incoming call. 15 TRACO TRansit Am COordinator APCCONNREQ1 specifying the EPID to the RMP. Block APC16 within the RMP receives this signal and assigns a session ID that it sends to the terminating user, MOIPHI, with signal APCCONNIND. If MOIPHI accepts the session, it assigns an individual and returns signal APCCONNRESP to APC. APC then returns signal APCCONNCONF, which includes the session ID, to TRACO confirming the session establishment. 25. After seizing its own SSV (Switching Switch View) and joining it to the SV of

its incoming EP and then possibly seizing a charging view, the TRAM forwards the OIP-IAM message to its outgoing EP via the APC session with signal APCDATACBREQ. MOIPHI receives the OIP-IAM with signal APCDATACBIND. 26. Since the MOIPHI block can be used as the TRAM interface for several mobile routes as well as for a mobile terminating call, MOIPHI reads the mobile pointer (MRNR pointer for MSRN series) in the OIP-IAM CB4k (Communication Buffer - 4Kbytes). If the mobile pointer exists, as is the case in this example, then it is a mobile terminating call. Otherwise MOIPHI would have read the outgoing global route parameter within the OIP-IAM CB4k to determine the outgoing route (see the GMSC lesson for such an example). MOIPHI then reads the last two digits of the called party number (i.e. MSRN) in the OIP-IAM CB4k, in order to determine which MSRN within the MSRN series is to be addressed. MOIPHI sends this information in signal MINCCONNECT to MRNR to find the previously assigned MSRN record. 27. MRNR uses the mobile pointer and the last two digits of the MSRN received in signal MINCONNECT to derive the MSRN pointer within its block. Once the MSRN record is found, MRNR seizes an MTB17 individual with combined signal pair SEIZEMTB1/ACK. This signal contains the terminating MSs IMSI that was stored in the MSRN record at step 17. Nested within this signal pair, MTB seizes the companion MTBCO18 individual with combined signal pair INITIATEMTC/ACK. MTB and MTBCO share the same file size hence the same pointer. Although MOIPHI seized MRNR as its user at step 26, it is MTBCO that confirms the seizure as an MOIPHI user with signal MINCONNECTR. 28. MRNR then passes the rest of the call related information that was received in the MAP-PRN message (stored at step 18) to MTB with signals PRNLATADATA (LATA), PRNDATAINFO (NCR and GSMC address) and PRNDATAEND1 (GSM/PLMN BC). At this point, the MSRN individual within MRNR drops off to idle and is ready to be used in another call delivery. TRACO is a TRAM block that passes OIP messages between the incoming and outgoing sides as well as the subscribing blocks within the TRAM. 16 APC AM Protocol Carrier APC is an RMP block that deals with the implementation of the APCSE (AM Protocol Carrier Service), which is used for communication between AM's in the same physical node. It consists of both a traffic and an administrative part. 17 MTB Mobile telephony, Traffic coordinator, B-subscriber MTB is an MSS block that coordinates and controls the terminating call on the CC level. It is the master block of a global file size alteration that also includes blocks MTBCC, MTBSS and MTBCO. 18 MTBCO Mobile telephony, Traffic coordinator, B-subscriber, COntroller

MTBCO is an MSS block the coordinates and controls the OIP message distribution and is the interface to call charging and monitoring. The MSRN within block MRNR is only used temporarily to deliver the call from the GMSC to the VMSC. Once the call enters the VMSC, the subscriber is identified in the VMSC with the IMSI stored within the MSRN record. The MSRN (i.e. MRNR) individual is then released and MTB is its associated blocks are asked to coordinate the remainder of the call set up. Figure 9 29. MTBCO then receives the OIP-IAM message in signal MRECFWDMSG from MOIPHI. MTBCO first distributes the OIP-IAM message to MTB with signal MMSG. Over the next few steps, MTB will get most of the information for this terminating call set up from this OIP-IAM message, which is contained within the CB4k. 30. MTB then seizes an MTBSS19 individual with signal SEIZEMTBSS3, which contains the IMSI that was stored in the MSRN record. MTBSS shares the same file size and thus the same pointer as MTB and MTBCO. MTBSS then uses the IMSI to identify the VLR record with combined signal pair IDENTIFYMS/ACK to block MSNAN. MSNAN performs mobile digit analysis on the IMSI in order to find the MTV individual assigned to the subscriber. If the VLR record is not found, the call fails and is subject to EOS (End-Of-Selection) code 2288. Note the VLR should always be found since it was found earlier at the MAP signalling phase in order to assign an MSRN. MOIPHIMTB29bMMSGMTBCO29aMRECFWDMSGMTBSSMSNAN30aSEIZEMTBSS330bI DENTIFYMS / ACK31PREVENTDISC / ACKMTVMNSAN33IMSITOANRES2 / ACK34SEIZEMTBSS2RMTVS32bFETCHSSALL / ACK32eFETCHSSALL1 / ACK32hFETCHSSALL1/ ACK32a/cREADMTVDA1 / ACK 32d/fREADMTVDA3 / ACK32g/iREADMTVDA5 / ACK35REQAOCSTATUS / ACK 19 MTBSS - Mobile Telephony traffic coordinator, B-subscriber, Subscriber Services MTBSS is an MSS (Mobile Switching Subsystem) block that handles the invocation of supplementary services for the B-subscriber in the MSC/VLR server. 31. MTBSS uses combined signal pair PREVENTDISC/ACK to remove MTV from the suitable list and thus ensure the MTV will not be disconnected during this process. An MTV may be disconnected and used by another MS when not enough MTV records exist within the VLR, a process known as recycling. 32. MTBSS reads subscriber data and classes that it will need to verify during the terminating call. It sends combined signal pairs READMTVDA1/ACK,

READMTVDA3/ACK and READMTVDA5/ACK to MTV, which in turn sends nested combined signal pairs FETCHSSALL/ACK, FETCHSSALL1/ACK and again FETCHSSALL1/ACK to MTVS. There following is some of the data and features that MTBSS is interested in: MSISDN, B-TCL, CLIP, CLIR, COLR, PICs, EMLPP, ST, AOC (Advice of Charge) information and call barring information. 33. MTBSS then asks MNSAN20 with combined signal pair IMSITOANRES2/ACK to perform IMSI series analysis. MNSAN is asked to determine if the IMSI series is subject to any of the following analysis results: OBA (Origin for B-number Analysis), NATMS (NATional MS), OWNMS, PLMN and STALL (Subscription Type ALLowed). This data is then stored in MTBSS and used by MTBSS as well as passed on to other blocks later in the process. OBA - used for analysis of B-digits within the TRAM. NATMS - determines whether the subscriber is considered as a national or international subscriber within this PLMN. OWNMS - determines whether the subscriber belongs to the HPLMN (Home PLMN) or not. As an example, it is used to determine whether the subscriber can make originating calls without dialling the numbering plan area code. PLMN - indicates which language must be used for the announcement messages sent to the subscriber. STALL - indicates whether the ST (Subscription Type, STYPE) stored in the VLR can be used. The ST is a value that associates a mobile subscriber to a group with certain characteristics. All mobile subscribers with the same ST have the same result in route, end-of-selection, charging and accounting analysis. The ST is stored in the HLR profile and sent to the VLR as an Ericsson private parameter. 34. MTBSS confirms successful seizure to MTB with signal SEIZEMTBSS2R as a response to signal SEIZEMTBSS3 at step 30 above 35. MTB fetches the AOC (Advice Of Charging) status information from MTBSS with REQAOCSTATUS/ACK. MTB stores this information for possible later use. For more information on this feature see FS Advice of Charge in MSC/VLR Server. 20 MNSAN - Mobile telephone Number Series ANalysis MNSAN is an MDS block that contains functions for analysis of IMSI number series and the administration of the table of analysis results and data associated with those number series. The primary use for analysis is to translate an IMSI number series to give data for traffic handling. 6.3.4.2 Analysis of BC

Figure 10 36. If CAMEL (Customized Applications for Mobile network Enhanced Logic) phase 3 is supported (DBS parameter GSM1APTF:CAMELPH3SUPP) in the MSC, MTB asks MTBSS to fetch CAMEL data with signal FETCHCAMELDATA. MTBSS then asks block MVIPH21 with signal REQVLRDATA to load CAMEL data from the VLR directly into CB4k containing the OIP-IAM message. Note that the type of information requested is not included within signal REQVLRDATA but rather within the OIP section of the CB4k. MTBSS requests all relevant CAMEL data. MVIPH uses combined signal pair PREVENTDISC/ACK to remove MTV from the suitable list and thus ensure the MTV will not be disconnected during this process. It then asks MTV to provide the MTVIN22 pointer for O-CSI data with combined signal pair FETCHRECPTR/ACK. It then asks MTV to provide the MTVIN pointer for D-CSI and VT-CSI data, with two more FETCHRECPTR/ACK MOIPHIMTBMTBCOMTBSSMTVMABCMUABC39aFORWARDPLMNBC39bFORWARDIS DNBC 38bSEIZEMUABC / ACK 38a/cSEIZEMABC/ ACK39cFORWARDPLMNBC39dFORWARDISDNBC 36aFETCHCAMELDATA36cPREVENTDISC / ACK36dFETCHRECPTR / ACK36eFETCHRECPTR / ACK36fFETCHRECPTR / ACK36gALLOWDISC / ACK 36bREQVLRDATA36hREQVLRDATAR37aFETCHTA / ACK37bFETCHCAMELDATAR40aFWDMISCDATA140bFWDMISCDATA1MVIPHMVIPH 21 MVIPH Mobile telephony VLR data read Interface Protocol Handler MVIPH is an MDS block that acts as an interface between a database block and the user who requests to transfer VLR data using the communication buffer service. 22 MTVIN Mobile Telephony Visiting subscriber Intelligent Network data MTVIN is an MDS block that is used to store, retrieve, and delete mobile subscriber data related to CAMEL (Customized Applications for Mobile Network Enhanced Logic) and MISI (Mobility management Intelligent network Subscription Information). CAMEL includes O-CSI (Originating CAMEL Subscription Information), SS-CSI (Supplementary Service CSI), MO-SMS-CSI (Mobile Originating Short Message Subsystem CSI), D-CSI (Dialled Services CSI), VT-CSI (VMSC Terminating CSI), M-CSI (Mobility Management CSI) and MT-SMS-CSI (Mobile Terminating Short Message Subsystem CSI) data. combined signal pairs. Since the MS in this example has no such data, its MTV record has no MTVIN record linked for O-CSI, D-CSI or VT-CSI data. Therefore, MVIPH sends combined signal pair ALLOWDISC/ACK to MTV in order to remove the prevent disconnection indication in MTV. MVIPH returns a successful result to MTBSS with signal REQVLRDATAR. Even though the requested data was not

found, the result is successful because CAMEL data is optional. 37. Before responding to MTB on the result of the CAMEL data fetch process, MTBSS fetches the TA (Transport Area) from MTB with combined signal FETCHTA/ACK and stores it the OIP-IAM CB4k. MTBSS only fetches the TA if the global equal access feature is supported in the MSC (DBS parameter GSMMSCF:GEAFEATURE). See FS Global Equal Access in MSC/VLR server and GMSC server for more details on this feature. MTBSS then indicates to MTB that the CAMEL was successfully read with signal FETCHCAMELDATAR. This is the return signal to FETCHCAMELDATA in the previous step. In this example, no CAMEL data exists for the subscriber. For certain CAMEL data combination, the call would have to be route to the SSFAM (Service Switching Function Application Module) in order to contact the relevant IN nodes. 38. The MTB individual seizes an MABC individual as a side link with combined signal pair SEIZEMABC/ACK. MABC in turns uses nested combined signal pair SEIZEMUABC/ACK to seize its corresponding MUABC individual. Note the MABC and MUABC individuals share the same pointer, hence the same file size. 39. MTB forwards the GSM/PLMN BC data received from MRNR at step 28 to MABC and then onwards to MUABC with signal FORWARDPLMNBC. Furthermore, since the OIP-IAM CB4k contains an ISDN BC, MTB forwards it to MABC and then onwards to MUABC with signal FORWARDISDNBC. 40. MTB then forwards some miscellaneous data such as TMR and WSIG to MABC in signal FWDMISCDATA1 that is also forwarded to MUABC. This data is required for analysis of the BC.

Figure 11 41. MTB then asks MABC to perform analysis of BC for this terminating call with signal ABCMTSETUP1. MOIPHIMTBMTBCOMTBSSMABCMUABCMTVSMTVMTECA42MPRETSA1 / ACK43MBCOMPANA1 / ACK44b/fFETCHSUBSCR/ ACK44c/eSUBSCRANA/ ACK44dCHKSUBSCRBSG / ACK44a/gFETCHSUBSCR/ ACK41ABCMTSETUP144hABCMTSETUPR Analysis of bearer capabilities Analysis of bearer capabilities is partly the negotiation of the BC (Bearer Capabilities) between the MSC/VLR and the MS. During this process the MSC/VLR determines the final values of certain PLMN bearer capability parameters taking into account the MSs capabilities and preferences (e.g. classmark) and the MSCs capabilities. The analysis of bearer capabilities also involves the determination of the BASC (BAsic Service Code, either a teleservice

or bearer service) that is checked against the subscribed BASCs. 42. MABC then uses the previously received BC to generate a BASC (BAsic Service Code, either a teleservice or bearer service), which in this case turns out to be teleservice telephony. MABC then asks MTECA to pre-analyze telecommunication services based on the BASC with combined signal pair MPRETSA1/ACK. MTECA determines whether the telecommunication service requested by the MS is available in the system. If available, MTECA returns a set of parameters (TCL, WSIG, TBP, etc,) to be used during the call. 43. MABC goes back to MTECA to determine if the WSIG (Wanted SIGnalling) and TMR (Transmission Medium Requirements) between the originating and terminating ends are compatible. The combined signal pair used for compatibility analysis is MBCOMPANA1/ACK. 44. MABC then proceeds to fetch the MSs subscribed BASC list. This is accomplished by using combined signal pair FETCHSUBSCR to MTBSS, via MTB. MTBSS then sends nested combined signal pair SUBSCRANA/ACK to MTV. MTV in turns sends another nested combined signal pair, CHKSUBSCRBSG/ACK, to MTVS. MTVS returns a list of bearer services and teleservices that the MS is subscribed to. MABC performs a subscription check to determine if the MS is subscribed to the BASC required for this call. MABC

returns the final result of analysis of bearer capabilities in signal ABCMTSETUPR to MTB. Figure 12 45. MTB then repeats the analysis of bearer capabilities for UMTS with signal UABCMTSETUP1 to MUABC via MABC. MUABC also generates a BASC (BAsic Service Code) and asks MTECA to pre-analyze telecommunication services based on the BASC with combined signal pair UMPRETSA/ACK. 46. MUABC goes back to MTECA to determine if the WSIG (Wanted SIGnalling) and TMR (Transmission Medium Requirements) between the originating and terminating ends are compatible. The combined signal pair used for compatibility analysis is UMBCOMPANA/ACK. 47. MUABC asks MABC to provide the MSs subscribed BASC list that it fetched in step 44 with combined signal pair SUBSCRDATA/ACK. MABC again fetches the BASC using combined signal pair FETCHSUBSCR to MTBSS, via MTB. MTBSS then sends nested combined signal pair SUBSCRANA/ACK to MTV. MTV in turns sends another nested combined signal pair, CHKSUBSCRBSG/ACK, to MTVS. MTVS returns a list of bearer services and teleservices that the MS is subscribed to. 48. MUABC performs a subscription check to determine if the MS is subscribed to the BASC required for this call on UMTS. The analysis succeeds since the MS is allowed to access UMTS for this call and thus MUABC returns signal UABCMTSETUP1R to MTB via MABC. 49. MTB asks MTBSS to fetch subscriber service data related to a specific

BASC, in this case telephony, with signal GETBGDATA. MTBSS uses combined signal pair FETCHSSBSG/ACK to MTV, which in turn uses combined signal pair FETCHSTBSG/ACK to MTVS. MTBSS returns information such as CUG validity, B-TCL and whether call forwarding may occur or not in signal GETBGDATAR. MOIPHIMTBMTBCOMTBSSMABCMUABCMTVSMTVMTECA47c/gFETCHSUBSCR/ACK 47d/fSUBSCRANA/ACK 47eCHKSUBSCRBSG / ACK47b/hFETCHSUBSCR/ ACK45aUABCMTSETUP148bUABCMTSETUP1R45bUABCMTSETUP148aUABCMTSETUP 1R45cUMPRETSA / ACK46UMBCOMPANA / ACK47a/iSUBSCRDATA/ ACK49aGETBGDATA49eGETBGDATAR49b/dFETCHSSBSG/ ACK49cFETCHSTBSG / ACK 6.3.4.3 Seizure of Connection Service, Charging and CC layer Figure 13 50. MTB orders the seizure of an MCSE23 individual with signal SEIZEMCSE1. The MCSE individual proceeds to seize two SSVs (Switching Switch View) via block COMAIN24 in the RMP (Resource Module Platform). Refer to Connection Service (CSE) service specification document for details on this process. The first SSV has a two-way connection and is joined to the SSV seized by the TRAM, while the second SSV is joined to the first and has speech broken in both directions. The identity of the TRAM SSV and its logical channel is obtained by MTB from the OIP-IAM and passed on to MCSE in signal SEIZEMCSE1. 51. After seizing its SSVs, the MCSE individual proceeds to seize its corresponding MCIWF25 individual with signal INITIATEMCIWF. MCSE and MOIPHIMTBMTBCOMTBSSMABCMUABCMCSEMCIWF51aINITIATEMCIWF51bINITIAT EMCIWFRSeize 2SwitchingSwitch ViewsCOMAINRMP50SEIZEMCSE152SEIZEMCSE1RMTTEC54a/eMSTARTMTTEC/ ACK54b/dSTARTMTTEC/ ACK54cSEIZEMTTEC / ACKAPCRMPTRACOTRAM55MMSGR54fSTARTTIMERS53bGET2NDANR / ACK53aCLIPINFO53cCLIPINFOR 23 MCSE - Mobile telephony Connection SErvice MCSE is an MSS (Mobile Switching Subsystem) block that is responsible for the seizure and release of switch views needed for basic call handling in MSS. Block MCSE is responsible for the setting of through-connection state, for the generation of call in progress tone, ringing control tone and announcements at call disconnection. 24 COMAIN - Mobile telephony A-interface Line Terminal

COMAIN is an RMP block that is the main block in the CSE (Connection SErvice) and handles all user orders from the AM-users except those dealing with Message Senders, Digit Receivers, Digit Senders and Monitoring Digit Receivers. COMAIN owns the SVs and channels and coordinates all user orders on the SV chain. 25 MCIWF - Mobile telephony Control of InterWorking Functions MCIWF is an MSS (Mobile Switching Subsystem) block that controls interworking functions for data calls of GSM and UMTS access, as well as alternate fax and speech calls for GSM access. MCIWF MCIWF share the same pointer hence the same file size. MCIWF initializes its variables and confirms seizure to MCSE with signal INITIATEMCIWFR. MCIWF is seized in case an interface to the DTS-R (Data Transmission Subsystem in the RMP) is needed during this call. An IWF will not be needed in this example. 52. MCSE confirms seizure to MTB with signal SEIZEMCSE1R as a reply to signal SEIZEMCSE1 at step 50 above. 53. MTB asks MTBSS to determine how to handle the CLIP (Calling Line Identification Presentation) feature for this call with signal CLIPINFO. MTBSS then requests MTB to provide additional CLIP information such as a second calling party number, if it exists, with combined signal pair GET2NDANR/ACK. MTBSS then returns the results in signal CLIPINFOR indicating whether or not to present the CLIP and which calling party number to use. For more information on the CLIP feature, refer to FS Calling Line Identification Supplementary Services in MSC/VLR. 54. MTB then verifies if any sort of timing is required for this call for features such as CIP (Call In Progress tone) delay time, ACM delay time and MGW (media gateway) selection time. Timing is performed by block MTTEC26, which is seized as a side link to MOIPHI. In this particular example CIP timing is required; therefore, MTB ask MTBCO to seize timing resources with combined signal pair MSTARTMTTEC/ACK. MTBCO in turn sends nested combined signal pair STARTMTTEC/ACK to MOIPHI, which then seizes an MTTEC individual as a side link with nested combined signal pair SEIZEMTTEC/ACK. MTB then orders the start of the timers with signal STARTTIMERS directly to MTTEC. 55. MTB returns control of the CB4k and the OIP-IAM message within it to MTBCO with signal MMSGR. MTBCO had handed over control to MTB at step 29 above and will return control back to MTB later in the call. MTBCO now needs to take care of charging requirements for this call. communicates with RMP using the APSI service 'Data Transmission Interworking Unit Device Service' 26 MTTEC - Mobile Telephony Timer Expiry Control

MTTEC is an MSS block that controls the ACM, CIP, and the MGW delay timer in the MSC/VLR for mobile terminating, call forwarding, and CAMEL Phase 3 rerouting calls. The timers are started by the MOIPHI user. In case of call forwarding the block will be relinked to a new user. Figure 14 56. MTBCO initiates the seizure of a charging view via MCEDHC27 with signal SEIZECHGCCC1. MCEDHC seizes an individual and orders to the seizure of a context adapted charging view to block CHVIEW28 in the RMP. MCEDHC also subscribes locally to public charging data, in particular the analysis result. Public charging data is data that can be stored in a charging view by any user and is accessible to all users. This makes it possible for users to exchange some charging data between them. MCEDHC confirms seizure of a charging view and establishes a link with MTBCO with signal SEIZECHGCCCR. 57. MTBCO sends the CB4k pointer to MCEDHC with signal MSGREPORT, so that MCEDHC can read the necessary charging data directly from the OIP-IAM. MCEDHC then asks MTBCO to specify exactly which parameters within the OIPIAM it would like to include as charging data with combined signal pair MOIPHIMTBMTBCOMTBSSMABCMUABCMTTECAPCRMPTRACOTRAMMCEDHC57aM SGREPORT57dMSGREPORT1RTRAN57cTRAGLROUTENO / ACK 56aSEIZECHGCCC156bSEIZECHGCCCRCHVIEWRMPStore publiccharging data Seize a fullChargingview in RMPMTBCCMCCMHMCCPH60a/eSEIZEMTBCC/ ACK58MMSG61MMSGRMEPPA59a/cSENDEMLPPINF/ ACK59bGETGEMLPPWPS1 / ACK 60b/dSEIZEMMH/ ACK60cACTIVEPPH / ACK57bSENDOUTCCC/ACK 27 MCEDHC Mobile telephony Call and Event Data Handler for Charging MCEDHC is an MSS block that receives the charging data from the MSS traffic blocks and controls the charging analysis of events. MCEDHC filters charging data using the information received from CHS. 28 CHVIEW Charging VIEW handling and call logging CHVIEW is a CHSS (CHarging Service Subsystem, part of CHARM (CHArging Resource Module) within the RMP) block that offers to the users the possibility to store charging or traffic related data for processes, controlled by the user (e.g. a call or a service). A view can be used for each process to which charging or traffic related data needs to be stored. To a view, several logs can be connected,

for the collection of data. With the data, provided by the user, CHVIEW will determine if an output has to be initiated. When an output is initiated, the collected data in CHVIEW can be fetched by the output blocks. SENDOUTCCC/ACK. One of the parameters MCEDHC is asked to read is the incoming global route number, which TRAN29 translates into a global route name with combined signal pair TRAGLROUTENO/ACK. Once all the data is read into variables, MCEDHC returns signal MSGREPORT1R to MTBCO. This signal includes a NCR (Network Call Reference), charging view ID and other fields. MTBCO adds the NCR to the OIP-IAM. 58. MTBCO proceeds by sending the OIP-IAM to the next user on the distribution list, which in this example happens to be MTB again. Once again since MMSG is sent to MTB with the CB4k pointer. 59. MTB asks block MEPPA30 via MTBSS to determine the granted EMLPP (Enhanced Multi-Level Precedence and Pre-Emption) for this call. MTB initiates this check by sending combined signal pair SENDEMLPPINF1/ACK to MTBSS with an EMLPP if available. If an EMLPP parameter was received in the OIPIAM, MTB uses it or a mapping of it; otherwise a default value is assigned. Since the WPS (Wireless Priority Service, variant of EMLPP feature) is active in this example (DBS parameter GSM1APTF:WPSF), MTBSS sends nested combined signal pair GETGEMLPPWPS1/ACK to MEPPA to determine the granted EMLPP. Otherwise, MTBSS would have sent combined signal GETGEMLPPINF/ACK. The granted EMLPP will be used later at channel assignment. The purpose of EMLPP and WPS features is to allocate a priority to a call so that upon congestion the BSC can pre-empt radio resources or buffer radio resource requests based on this allocated priority. For more information on the EMLPP and WPS features, refer to FSs Enhance Multi-Level Precedence and PreEmption Service in the MSC/VLR and Wireless Priority Service in GMSC, TSC, MSC/VLR (GSM). 60. MTB now attempts to connect the CM (Connection Management) layer of the call path. MTB orders the seizure of an MTBCC31 individual with combined forward signal SEIZEMTBCC. MTBCC shares the same file size and thus the same pointer as MTB and MTBSS. The MTBCC individual then orders the seizure of an MCCMH32 individual with combined signal pair SEIZEMMH/ACK. 29 TRAN TRANslation functions

TRAN is an OMS (Operation and Maintenance Subsystem) block that contains functions for loading and translating parameters. It also contains the command EXRNC for the changing of route data. 30 MEPPA Mobile telephony Enhanced multi-level Precedence and Pre-emption service Administration MEPPA is an MDS block that provides the granted eMLPP priority level for the mobile originating, mobile terminating and emergency calls, provides the PVI (Pre-emption Vulnerability Indicator), PCI (Pre-emption Capability Indicator), QAI (Queueing Allowed Indicator) and Priority based on the granted eMLPP priority level and handles the commands to change and print eMLPP data. 31 MTBCC - Mobile telephony traffic coordinator, B-subscriber Call Control MTBCC is an MSS (Mobile Switching Subsystem) block that contains traffic handling functions needed for handling of mobile-terminated calls. It also comprises the DTAP message handling function in cooperation with MCCMH and MCPPH. 32 MCCMH - Mobile telephony Call Control Message Handler MCCMH is an MSS block that contains functions for encoding and decoding DTAP messages related to CC (Call Control) and call-related supplementary service procedures. Within this combined signal pair, the MCCMH individual activates its corresponding MCPPH33 individual with combined signal pair ACTIVEPPH/ACK. Note the MCCMH and MCPPH individuals share the same pointer, hence the same file size. MTBCC acknowledges seizure with combined forward signal SEIZEMTBCCACK. 61. MTB again returns control of the CB4k and the OIP-IAM message within it to MTBCO with signal MMSGR. MTBCO had handed over control of the message to MTB at step 58 above. 6.3.4.4 Paging Preparation and Paging Message Sent Figure 15 62. MTB sends the NCR and the GMSC address in signal SENDCAMELDATA to MTBSS, which it may need if this call need to be transferred via optimal routing, see description below. MTB also sends the transfer treatment indicators to MTBSS in signal SENDTREATINDIC, which it may need to determine if this call requires a transfer.

MTBMABCMUABCMCSEMCIWFMTBSSMCEDHCMTVMZONE63aPREPPAGING163bRM MDATA1 / ACK65aZCFRRCHK65bFETCHZCDATA/ACK65cZCFRRCHKR66READYFORPAGMTBCC MCCMHMCCPHMOIPHIMTBCO62aSENDCAMELDATA62bSENDTREATINDICMZONE64 MRECFWDMSGR If the call needs to be transferred later on and the optimal routing feature is active and permitted in the GMSC, then the VMSC may ask the GMSC to perform the call forwarding. Such a request is done with a MAP-RCH (Resume Call Handling) message and would contain the NCR (Network Call Reference) number as a 33 MCPPH - Mobile telephony Cross Phase Protocol Handler MCPPH is an MSS block that encodes and decodes the facility information elements in a DTAP message. In other words, it assists block MCCMH in handling the SS (Supplementary Services) protocol defined towards the MS for control of call related supplementary services. means to identify the call to be forwarded. The GMSC address is used to identify the GMSC node. For more information on this feature see function description Optimal Routing at Late Call Forwarding in GMSC Server. 63. MTB asks MTBSS to check whether it is possible to page the MS with signal PREPPAGING1. MTBSS reads the subscriber state and roaming restriction information from MTV with the combined signal pair RMMDATA1/ACK. The assumption here is that the MS is still attached. If the roaming restriction information indicates that the subscriber is restricted due to roaming being an unsupported feature, a disconnection order or a call forwarding indication (CFNRC, Call Forwarding Not Reachable) is sent to MTB. This feature restricts the MSC service area to the MS when the MSC does not support certain senstive services (for example, Advice of Charge or Regional Subscription). The roaming restriction indication is received from the HLR. For more information on this feature, refer to FS Roaming Restriction Due to Unsupported Feature in MSC/VLR. As in all other cases in this example, the check is successful and allows the call set up to proceed. 64. After receiving signal MMSGR from MTB (step 61), MTBCO determines that there are no more blocks to distribute the message to. Therefore MTBCO confirms the reception of the OIP-IAM message to MOIPHI with signal MRECFWDMSGR. At which point, MOIPHI will no longer buffer any forward messages and sends to MTB any that may have been received. No messages are buffered in this example. MRECFWDMSGR is the return signal to MRECFWDMSG from step 29 above. 65. If any of the regional services (local subscription, regional subscription and subscription with tariff areas) are supported in the MSC, MTBSS orders MZONE to check roaming restrictions due to regional services with signal ZCFRRCHK. Note this is the same check as in step 15. MZONE dedicates an individual to this task. This individual then fetches the zone code set from the MTV with combined

signal pair FETCHZCDATA/ACK. The VLR zone code data is stored in block MTVZONE; however in this example, since the MTV individual has no link to MTVZONE, it knows there is no zone code data and indicates this to MTBSS with signal ZCFRRCHKR. As a result, the process successfully proceeds. See FSs Local Subscription in MSC/VLR Server, Regional Subscription in MSC/VLR Server, Subscription with Tariff Areas in MSC/VLR Server and Regional Services in HLR for more details on the regional services feature. 66. MTBSS indicates to MTB with signal READYFORPAG that it may proceed with paging. This is a reply to signal PREPAGING1 at step 63.

Figure 16 67. Before initiating paging, MTB starts the not reachable timer to supervise the time between paging and a successful traffic channel assignment. The timer duration is determined by DBS parameter GSM1APTC:TIMNREAM. If LATAs are used, then MTB initiates paging to block MPAG34 with signal LATAPAGEREQ2; otherwise, signal PAGEREQ5 is used. In this example, MPAG receives signal LATAPAGEREQ2. 68. MPAG seizes an individual and immediately busy marks the MTV record for paging with combined signal pair BUSYMARKMSUB/ACK. It is here that MTV stores the MPAG pointer. When the MS responds to the paging, the IMSI can be used to identify the MTV pointer, which will then contain the identity of MPAG individual and thus link the paging response process to the paging request process. If the backward combined signal BUSYMARKMSUBACK indicates that the subscriber is already busy at the CM level or for previous paging, then the paging attempt fails. 69. MPAG reads the current LA (Location Area) from MTV with combined signal pair RMMDATA1/ACK. It then asks block MBSSD to translate the LA into the present LATA with combined signal pair LOCTOLATA/ACK. If the LATA received in signal LATAPAGEREQ, which is the LATA used to assign the MSRN, matches MTBCOMTBMABCMCSEMCIWFMCEDHCMTBCCMTVMTBSS72bTRANSFERTA / ACKMCCMHMPAG67LATAPAGEREQ268BUSYMARKMSUB / ACK 69aRMMDATA1 / ACK 70aRMMDATA1 / ACK 71CHECKGPRS / ACK 72aLATAPAGEREQRMBSSD69bLOCTOLATA / ACK70bLAPTOLAI / ACK 34 MPAG - Mobile telephony PAGing MPAG is an MMS block that receives requests for paging, fetches the data related to paging in one LA or LATA or global paging, and seizes blocks MUPAG and/or MBPAG according to the required type of paging (UMTS/GSM). If paging is executed via SGSN, MPAG sends the page request message to MGPRO for packing.

the present LATA, the call proceeds. Otherwise, the call attempts fails due tLATA mismatch. Note this LATA check c parameter GSMMMSC:CTRESTLATA. 70. MPAG reads the current LA (Location Area) again from MTV with combined signal pair RMMDATA1/ACK. If the LA is present, MPAG decides to perform LApaging and thus asks block MBSSD to translate the LA pointer into an LAI ( Identity) with combined signal pair LAPTOLAI/ACK. The LAI is required to communicate the identity of the LA to the BSC. Note that it is at this step that MPAG checks to see if the TMSI is used, in which case it supply it. The TMSI feature is not active in this example. 71. MPAG also checks if the MS is GPRS attached with combined signal pair CHECKGPRS/ACK to MTV. The reason for this check is that if the MS were GPRS attached as well as IMSI attached and the MSC supports the Gs interfacto the SGSN (Serving Gprs Service Node), then the paging w GPRS. MPAG would seize block MGPRO for this purpose. 72. MPAG confirms that it accepts the page request with signal LATAPAGREQR to MTB. This is the reply signal to LATAPAGEREQ2 from step 67. MTB transfthe LATA information received in this signal to MTBCC with combined signal TRANSFERTA/ACK. MTBCC s 35 MGPRO - Mobile Gs-interface PROcedures MGPRO is an MMS block that contains the logic of all the BSSAP+ procedures, which are handled via the Gs-interface towards SGSN (Serving GPRS Support Node) in the MSC/VLR. Figure 17 73. MPAG seizes an MBPAG36 individual with hurry signal SEIZEMBPAG. MBPAG confirms seizure with hurry signal MBPAGSEIZED. 74. MPAG orders MBPAG to initiate a GSM LA page providing the LA and IMSI in signal GSMPAGE. MBPAG then asks MBSSD to provide a list of BSCs that the LA spans with signal pair BSCLIST/R. 75. MBPAG orders the sending of a BSSMAP-Paging message to a particular BSC with signal PAGEPACKREQ to block MRRM37. Note that if an LA spans more than one BSC, then this message is sent once for each BSC. MRRM initiates the message packing by sending to MRRMH38 the various information elements required in the BSSMAP-Paging message. MRRM supplies MRRMH with the necessary parameters using a series of combined signal pairs: the IMSI with RRIMSIOUT/ACK and the Cell Identifier List (LA in this case) with RRCEIDLSTOUT/ACK.

MTBMABCMTBCCMTBSSMCCMHMPAGMBPAGMBSSD74aGSMPAGE74bBSCLIST74cB SCLISTRMRRMMSCCLMRRMH75bRRIMISOUT / ACK75cRRCEIDLSTOUT / ACK76aSENDBSSMAPCLCCSSCBMBSCSCRDBSSMAP Paging SCCP UDT (Connectionless) SCRD75aPAGEPACKREQ78bGSMPAGER76bBSSAPOCLMREQ77bG7BUFFREQR 77aG7BUFFREQ 77cG7UDTREQI / R78aBSSAPOCLMRESULT77dG7UDTREQE / R73aSEIZEMBPAG73bMBPAGSEIZED 36 MBPAG - Mobile telephony GSM PAGing MBPAG is an MMS block that is responsible for paging via A-interface. Both Lata and satellite paging are performed by MBPAG only. Depending on the information provided by MAPG in the signal GSMPAGE, MBPAG performes local, global, lata or satellite paging 37 MRRM - Mobile Telephony Radio Resources Management MRRM is an MMS (Mobile Mobility and radio Subsystem) block that handles and coordinates the RR function level within the MSC. MRRM supervises the establishment and release of signalling connections between a MSC and a BSC and handles and distributes the messages to and from the A-interface. 38 MRRMH - Mobile telephony Radio Resources Message Handler of BSSMAP messages MRRMH is an MMS block, whose task is to pack and unpack BSSMAP type messages. 76. Once all these information elements are forwarded for packing, MRRM orders MRRMH to send the connectionless SCCP message with direct signal SENDBSSMAPCL. MRRMH sends this BSSMAP message to MSCCL39 with signal BSSAPOCLMREQ. 77. MSCCL then seizes an SCCP dynamic buffer with signal pair G7BUFFREQ/R to block SCBM40. MSCCL loads the message within the buffer and then orders block SCRD41 to route the message to the appropriate BSC with the following two signal pairs: G7UDTREQI/R and G7UDTREQE/R. 78. MSCCL confirms the message sending to MBPAG with signal BSSAPOCLMRESULT. If MBPAG needs to send the BSSMAP-Paging message to more than one BSC, it returns to step 75 above for the next BSC. This process repeats itself until all BSCs are paged. This example assumes that the LA being paged only spans one BSC, hence no repetition. SCRD and other CCS blocks ensure that the BSSMAP-Paging message is sent to the BSC over an SCCP UDT (Unit Data) message. Once all BSCs are paged, MBPAG returns an indication to MPAG that the paging has been ordered with signal GSMPAGER. Upon receiving signal GSMPAGER, MPAG starts the appropriate paging timer. MPAG contains various DBS parameters that determine the paging timer duration. The parameter used depends on whether it is the first or second page

and whether is LA or global or LATA paging. Note if the first page times out in MPAG, then MPAG may attempt a second page by repeating the paging process starting with step 74 above. Whether or not a second page is attempted and what type of paging is performed on the second attempt depends on the first page type and a few other DBS parameters defined within block MPAG. Paging Parameters The Paging message (3GPP TS 48.008 Rel. 5) contains 2 mandatory and several optional parameters of which only the Chosen Channel is described below: IMSI - is the International Mobile Station Identity, a number that uniquely identifies a subscriber within the PLMN network. IMSI is a mandatory parameter. TMSI - is the Temporary Mobile Station Identity, a number that uniquely identifies a subscriber within the MSC/VLR area. Its use enhances security 39 MSCCL - Mobile telephony SCCP ConnectionLess signalling MSCCL is an MMS block that handles connectionless SCCP messages. MSCCL also handles a translation table that translates the SPC (Signalling Point Code) and NI (Network Indicator, always 2 (national) for ANSI) into a BSC pointer and vice versa. 40 SCBM - SCCP Buffer Manager SCBM is a CCS (Common Channel Signalling) block that administers a pool of 512 octet buffers for SS7 message processing. 41 SCRD SCCP Routing Destination SCRD is a CCS block that routes SCCP messages to destinations throughout the network. It contains functions for validation of message formats, determination of message destinations, determination of destination availability, message routing to MTP, message routing to local subsystems, message return or discard on error, and provisioning for message screening. (fraud and privacy) and since it is shorter than the IMSI, it reduces load on

the paging channels. This element is omitted in the case where the IMSI is used instead of the TMSI as a paging address at the radio interface Cell Identifier List - is a mandatory parameter that uniquely identifies all the cells in which paging is to be performed. The parameter can contain a list of individual cells or a list of LAs or ask that all cells within a BSS be paged. 6.3.4.5 Paging Response Message Received

MTBCCMCCMHMPAGMBPAGBSCCCSSCCOCMSCCOMSCCL79cOPCTOBSCP179dOPCT OBSCPRMRRMMRRMH80bRNICOMRHSZCB 81aRRCEIDIN / ACK81bRRLAY3IFIN / ACK80cRCVBSSMAPCO1RR -PAGING RESPONSEBSSMAP -CL3I (Comp Layer 3 Info) SCCP -CR (Connection Request) 79aSCCONNINDI / ACK79bSCCONNINDEExisting TerminatingMobile Call Path80aRNICOMRRSZCB81cRRCHOSECHIN / ACK81dRRAPDUIN / ACKMRRMASGMRRMHO82aSEIZEASG / ACK82bSEIZEMRRMHO / ACK82cSTOREHOPID/ ACK Figure 18 79. Assuming the MS hears the page and successfully answers with an RRPage Response on the air interface, the BSC will send a BSSMAP-CL3I (Complete Layer 3 Information) message on the A-interface to the MSC. The contents of this message as well as the originating BSC point code is provided by block SCCOC42 to block MSCCO43 with combined signal pair SCCONNINDI/ACK and direct signal SCCONNINDE. Note that the BSSMAP-CL3I message is encapsulated by an SCCP-CR (Connection Request) message initiating an SCCP connection dialogue and hence the involvement of blocks SCCOC and 42 SCCOC - SCCP Connection Oriented Control SCCOC is a CCS (Common Channel signalling Subsystem) block, which handles SCCP connections. It contains functions for setup, control and release of temporary signalling connections 43 MSCCO - Mobile telephony SCCP Connection Oriented signalling MSCCO is an MMS (Mobile Mobility and radio Subsystem) block and acts as SCCOCs counterpart for signalling over the A-interface. MSCCO transfers connection-oriented messages between the MSC and BSC. MSCCO. An MSCCO individual is seized and the whole BSSMAP-CL3I message content is stored within the individual. MSCCO then asks MSCCL to translate the BSC point code into a BSC pointer via signal pair

OPCTOBSCP1/OPCTOBSCPR. 80. The BSSMAP-CL3I message encapsulates the RR-Paging Response message. Both messages will be analyzed and unpacked at the RR layer. MSCCO allocates a CB4k (Communication Buffer - 4 Kbytes) in which it stores the BSSMAP-CL3I message. Block MRRM44 receives the message from MSCCO in signal RNICOMRRSZCB, which contains the CB4k pointer and the discrimination parameter (BSSMAP or DTAP). An MRRM individual is seized and since this message has a BSSMAP component, it is forwarded to MRRMH with signal RNICOMRHSZCB for unpacking. Since this message is connection oriented at the SCCP level, an MRRMH individual is seized and will be used for all received and sent BSSMAP messages on this SCCP connection. MRRMH transfers the content of the CB4k to its own internal buffers and then analyzes the message by first determining the message type and then checking for any formatting errors. It reports its result as well a list of received optional parameters to MRRM with hurry signal RCVBSSMAPCO1, which in this example includes the BSSMAP message type of CL3I, Complete Layer 3 Information. 81. Since the message is successfully analyzed by MRRMH, MRRM asks MRRMH to unpack the contents of the message, in other words, get the BSSMAP-CL3I message parameters. With combined signal pair RRCEIDIN/ACK MRRM gets the CGI (Cell Global Identity). MRRMH uses mandatory parameter CI (Cell Identifier) to build the CGI. MRRM also fetches the Layer 3 Information mandatory parameter, with combined signal pair RRLAY3IFIN/ACK, the optional Chosen Channel parameter with combined signal pair RRCHOSECHIN/ACK and the APDU parameter with combined signal pair RRAPDUIN/ACK. CGI - Cell Global Identifier The CGI is composed of the MCC+MNC+LAC+CellID. MCC, Mobile Country Code, 3 digits, same as in IMSI MNC, Mobile Network Code, 2 or 3 digits, identifies PLMN within a country, same as in IMSI LAC, Location Area Code, 2 octets, fixed length, uniquely identifies an LA within a PLMN CellID, Cell Identity, 2 octets, uniquely identifies a cell within an LA or within a BSS; the coding of the CellID is up to each administration. CL3I Parameters The CL3I message (3GPP TS 48.008 Rel. 5) contains 2 mandatory and several optional parameters of which only the Chosen Channel is described below: 44 MRRM - Mobile Telephony Radio Resources Management

MRRM is an MMS (Mobile Mobility and radio Subsystem) block that handles and coordinates the RR function level within the MSC. MRRM supervises the establishment and release of signalling connections between a MSC and a BSC and handles and distributes the messages to and from the A-interface. CI - The CI (Cell Identifier) is a mandatory parameter within the BSSMAPCL3I message. The technical specifications gives several options on coding the CI within the CL3I message. The CI can be the whole CGI or just CellID or other in between options. Layer 3 Information - is a mandatory parameter within the CL3I message, see note below. Chosen Channel - is an optional parameter that contains a description of the channel allocated to the MS on the air interface. APDU - Application Protocol Data Unit is an optional parameter that is defined as a general container for passing information transparently between BSSs or between BSS and SMLC (Serving Mobile Location Center) via the MSC. In this example, contains location information that may be used later in the process, such as during a handover. The Layer 3 Information component - DTAP within BSSMAP The Layer 3 Information component within a BSSMAP-CL3I message is a parameter that encapsulates the first layer 3 interface message sent by the MS to the BSC for a system request (usually a DTAP message but an RR layer message in this case). The reason a DTAP message is encapsulated within a BSSMAP message, is so that a DTAP message can be sent at the same time as an SCCP-CR. Remember that a DTAP message is used for MS to MSC communication and thus by its very nature requires a previously established SCCP connection. The BSSMAP-CL3I message allows a DTAP message to be sent along with an SCCP-CR thus saving signalling load on the A-interface by not requiring an independent SCCP-CR and SCCP-CC (Connection Confirm) message exchange prior to the DTAP message. 82. MRRM then proceeds to seize two side link blocks. It first seizes an MRRMASG45 individual with combined signal pair SEIZEASG/ACK and then an MRRMHO46 individual with combined signal pair SEIZEMRRMHO/ACK. Note that both MRRMASG and MRRMHO share the same size alteration event as MRRM and thus the same pointer. Nevertheless, MRRM sends the MRRMHO pointer to MRRMASG with combined signal pair STOREHOPID/ACK. MRRM also provides the MRRMH block reference and pointer to both MRRMASG and MRRMHO.

45 MRRMASG - Mobile Telephony Radio Resources Management ASsiGnment MRRMASG is an MMS block that contains protocol handling functions corresponding to radio resource and BSSMAP procedures related to assignment. 46 MRRMHO - Mobile Telephony Radio Resources Management Handover MRRMHO is an MMS block that contains protocol handling functions corresponding to radio resource and BSSMAP procedures related to handover. This page is intentionally left blank. Figure 19 83. Since the protocol discriminator of the Layer 3 Information component indicates it is a RR (Radio Resource) layer message. MRRM asks MRRMH to also analyze the contents of this message with hurry signal RNICOMINDCB. This signal contains the same CB4k pointer allocate by MSCCO at step 80 but now only contains the Layer 3 Information parameter. MRRMH transfers the content of the CB4k to its own internal buffers and then analyzes the message by first determining the message type and then checking for any formatting errors. It reports its result as well a list of received optional parameters to MRRM with hurry signal RCVBSSMAPCO1, which includes the message type of RR-Paging Response. 84. Since the Paging Response message is successfully analyzed, MRRM starts fetching from MRRMH the different parameters included in the message with a series of combined signal pairs: the Ciphering Key Sequence Number with RRKEYSEQNRIN/ACK, the MS Classmark 2 Information with RRMOBCLAS2IN/ACK and the Mobile Identity, IMSI, with RRMOBILEIDIN/ACK. CCSBSCSCCOCMSCCOMRRMMRRMH84aRRKEYSEQNRIN / ACK83aRNICOMINDCB 84bRRMOBCLASS2IN / ACK83bRCVBSSMAPCO184cRRMOBILEIDIN / ACKMMM85RRLAYLINKED86aPAGERESPMMSZ86bMMLAYLINKED87aRRLAYCONRE SPSCCP CC (Connection Confirm) 87bSCCONNRESP87cSCCONNRESPACKExisting TerminatingMobile Call PathMEC88aSEIZEMEC 88bMECSEIZEDMMMCSMBSSD89aPAGERESPCSSZ1 89bCSLINKED 90aLORECOREQ91aLAITOLAP191bLAITOLAP1R90bLORECOREQMRRMASGMRRMHO Paging Response Parameters The Paging Response message is defined in (3GPP TS 44.018 Rel. 5 Mobile

radio interface layer 3 specification, RR control protocol) and contains 3 mandatory parameters which are described below: Ciphering Key Sequence Number - In a GSM authentication challenge, the purpose of the Ciphering Key Sequence Number information element is to make it possible for the network to identify the Kc (ciphering key) that is stored in the mobile station without invoking the authentication procedure. Mobile Station Classmark 2 - This parameter indicates some general mobile station characteristics. This affects the manner in which the network handles

the operation of the mobile station. For multiband mobile, this parameter includes the frequency band in use. Mobile Identity - Since the RR Paging Response message is the first connection oriented message in the mobile terminated call establishment process, the mobile needs to identify itself with either the IMSI or TMSI. From this point onwards, all other messages on the same SCCP connection will refer to the same MS. 85. Since the first message, the BSSMAP-CL3I message, is successfully analyzed by MRRMH, MRRM completes the downlink with MSCCO by sending signal RRLAYLINKED. The reason this signal appears at this point is because all the signals in the previous two steps are either hurry or combined signals. 86. MRRM then forwards all the data from the two messages that were unpacked to the MM layer with signal PAGERESPMMSZ to block MMM47. An MMM individual is seized which then completes the downlink with the MRRM individual by sending signal MMLAYLINKED1. Note that if the Paging Response message is received from UMTS rather than GSM, then blocks MUSCCO and MUAMCO rather than MSCCO and MRRM would represent the RR layer in the call path. However the signal to MMM would be the same, signal PAGERESPMMSZ. 87. On reception of MMLAYLINKED, MRRM orders MSCCO to confirm the connection at the SCCP layer with hurry signal RRLAYCONRESP. Then with combined signal pair SCCONNRESP/ACK to block SCCOC, MSCCO asks CCS to send an SCCP-CC (Connection Confirm) message to the BSC thus establishing an SCCP connection across the A-interface. 88. In parallel with step 87, MMM seizes a MEC48 individual in case an IMEI equipment check is required later during this process. The MEC individual is seized with signal pair SEIZEMEC/MECSEIZED.

Mobile Terminated Call Establishment, MMM and MMMCS Block MMM uses block MMMCS49 as a side link to help out with this call scenario. MMMCS along with MMM interface with MSS (Mobile telephone Switching Subsystem) during the mobile terminated call establishment process. 47 MMM - Mobile telephony Mobility Management MMM is an MMS block responsible for the establishment, maintenance and release of the MM internal AXE links between CM and RR layers. MMM procedures are grouped into MM connection management procedures, specific MM layer procedures management and MM common procedures. 48 MEC Mobile telephony Equipment Control MEC is an MMS block that when given the MSs IMEI (International Mobile Equipment Identity) performs the equipment identity check by communicating via signalling with the EIR (Equipment Identity Register) node. 49 MMMCS - Mobile telephony Mobility Management Connection Setup MMMCS is an MMS block that handles connection setup and updates link between MMM and blocks in CM-Layer after function access confirmation is over. MMMCS is involved in speech calls, SMSs and call independent supplementary services to and from the MS. It is also involved in the location service procedure. 89. MMMCS receives the Paging Response message data from MMM with signal PAGERESPCSSZ1. An MMMCS individual is seized which then completes the link with MMM by sending signal CSLINKED. Signal PAGERESPCSSZ1 contains all the Paging Response parameters as well as the LAI. 90. MMMCS then sends signal LORECOREQ to MRRM via MMM for the sending of a location reporting control message. However since the location reporting control feature only applies to UMTS and this example has a GSM access, the signal is not acted upon by MRRM. This location reporting procedure is used to report where the MS is currently located, or to report when the MS moves into or out of a given service area. This procedure relates to location services and other services in UMTS. 91. MMMCS asks block MBSSD to translate the LAI (LA Identity) into an LA pointer with signal pair LAITOLAP1/R. 6.3.4.6 Paging Response Process Finds Paging Request Process

Figure 20 92. The MMMCS individual orders the seizure of an MVLRP50 individual with combined signal pair SEIZEMVLRP/ACK. MTVMMMMECMMMCSMTBMABCMTBCCMTBSSMCCMHMPAGMBPAGMVLRPMSNA N92SEIZEMVLRP / ACK94IDENTIFYMS / ACK93ACCESSREQUEST295PREVENTDISC / ACK97bMTVTOMPAGP / ACK97cPAGEINDIC1 / ACKMUABCMCCPHMBRIA99MBSCRECIMSI196RMMDATA1 / ACK98a/dACCONFDATA2 / ACK 97aACCONFDATA198e/ ACK98cPREVENTDISC / ACK98bUPDATEMSDATA / ACK 50 MVLRP - Mobile telephony VLR Procedures MVLRP is an MMS block that contains functions for performing VLR tasks such as analysis of the mobile subscriber identity, and informing the VLR of radio contact with the MS. MVLRP supports fetching of authentication data and IMSI from a previous cooperating VLR during location updating and is also responsible for initiating authentication procedures. 93. MMMCS asks MVLRP to initiate the access confirmation for the mobile terminated call with signal ACCESSREQUEST2, which also carries the necessary information. The MVLRP individual will inter-work with MMMCS, MSS blocks and MDS (Mobile Data Subsystem) blocks to perform the access confirmation. 94. MVLRP then uses the IMSI received in the Paging Response message to identify the VLR record with combined signal pair IDENTIFYMS/ACK to block MSNAN. MSNAN performs mobile digit analysis on the IMSI in order to find the MTV individual assigned to the subscriber. If the VLR record is not found, an 'IMSI unknown in VLR' reject cause is returned to the MS. Not the case in the example. Note if the MS provides a TMSI as a mobile identity in the Paging Response, then MVLRP will attempt to translate the TMSI into an MTV record by using block MTMSIAN51. If the TMSI cannot be identified, MVLRP will order the MS to send the IMSI with the DTAP-Identity Request message on the A-interface and ultimately the air interface. 95. MVLRP uses combined signal pair PREVENTDISC/ACK to remove MTV from the suitable list and thus ensure the MTV will not be disconnected during this process. An MTV may be disconnected and used by another MS when not enough MTV records exist within the VLR, a process known as recycling. 96. MVLRP then reads the radio confirmation flag in the MTV with combined

signal pair RMMDATA1/ACK. The radio confirmation flag indicates whether the location information was previously confirmed in the HLR. This flag is returned to MMMCS later in the process. If the flag is false, then MMMCS may initiate an update location to the HLR, more on this after step 130. The radio confirmation flag in this example is true. 97. MVLRP then asks MMM via MMMCS to busy mark the VLR. MVLRP accomplishes this by using combined signal pair ACCONFDATA1/ACK to MMMCS. Before forwarding the request to MMM, MMMCS fetches the MPAG pointer that was stored in MTV during the paging process (step 68) with combined signal pair MTVPTOMPAGP/ACK. MMMCS then informs MPAG of the paging response with combined signal pair PAGEINDIC1/ACK. In the backward combined signal, MPAG provides the access type, which in this case is mobile terminating call but could also be mobile terminating SMS or SS. Note this is where the paging response process and its associated individuals are bridged with the paging request process and its associated individuals. 98. MMMCS then forwards the busy mark order received in the previous step with nested combined signal ACCONFDATA2/ACK to MMM. This signal contains an order to busy mark the VLR as well as: the MTV pointer, the access type and the IMSI. Upon receiving the order, MMM sends a series of nested combined signal pairs to MTV. MMM sends the classmark 2 information received in the Paging Response message to MTV with combined signal pair UPDATEMSDATA/ACK. MMM also uses PREVENTDISC/ACK to ensure the 51 MTMSIAN - Mobile Telephony TMSI ANalysis MTMSIAN is an MDS block that handles handles reservation, allocation, release, and analysis of the Temporary Mobile Subscriber Identity (TMSI). MTV will not be disconnected during this process. Although the order in signal ACCONFDATA2 is to busy mark the MTV record, MMM skips this step for now since the MTV is still busy marked for paging. The MTV will be marked busy for CM level later at step 126. 99. At the previous step, MMM also sends buffered signal BSCRECIMSI1 to block MBRIA52 to verify if BSC Recording function is active for this MS during the mobile terminating call access type. In this example, the function is off and thus the signal is not acted upon by block MBRIA. However, if the function did apply to this process, MBRIA would order MRRM via MMM to send the BSSMAP- Trace Invocation message to the BSC in order to start the recording. See FS BSC Recording Initiation in MSC/VLR Server and command series MGBR for more details on this function. 6.3.4.7 Security Related Functions

Figure 21 100. MVLRP now proceeds with authentication. It first seizes an MAUTH53 individual with combined signal pair SEIZEAUTH/ACK. MMMMECMMMCSMVLRPMTVMRRMMRRMHMAUTH100SEIZEAUTH / ACK 101AUTHENTICATE104AUTHENTICATE1R107aAUTHENTICATE1102bREQACTKEYS / ACK102a/dRACTKEYS/ ACK103a/cUPDATEKEYS/ ACK106aTRACEINFOREQ106bTRACEINFOREQR107cSENDCIPH1 107bSENDCIPH1 108bSENDCIPHU / ACK 108a/cSENDCIPHU/ ACK MTRIPMNSAN 102cIMSITOANRES2 / ACK103bREQUPDKEYS / ACK105bINITCOMID 105aINITCOMID 52 MBRIA - Mobile telephony BSC Recording Initiation Administration MBRIA is an MMS block that initiates BSC recording in the case of an MSC-ordered recording. It also handles the commands for the administration of BSC recording initiation 53 MAUTH - Mobile telephony AUTHentication MAUTH is an MMS block that upon request performs security related functions such as ciphering, TMSI (re)allocation and authentication. MAUTH also fetches authentication vectors (triplets or quintuplets) from the HLR. The authentication process is split into two parts: 1) security related function up to but not including ciphering and then 2) the remaining security related functions. The MSC may send the BSSMAP-Common Id message in between these two parts. Furthermore, if the BSS Trace Invocation feature (DBS parameter GSM1APTC:MSCNF624) applies to the MS within this call scenario, then it is performed in between these two authentication steps. See FS BSS Trace Invocation In MSC/VLR and command series MGST_ for more details on this function. Note this function is similar to the BSC Recording function present at step 99 above. 101. MVLRP initiates the first authentication part, up to but not including ciphering, with signal AUTHENTICATE1 to MAUTH. Since the selective authentication feature is active (DBS parameter GSMMMSC:SELAUTH) in this example, authentication is not performed (but ciphering must be performed) and the only step in this first part is the fetching of the active keys, both the ciphering and integrity keys. 102. A few conditions are required for selective authentication to apply. Thus MAUTH uses forward combined signal RACTKEYS to fetch the active keys (ciphering and integrity keys) via MTV. MTV in turn uses nested combined signal pair REQACTKEYS/ACK to read this data from MTRIP54. MTV then sends combined signal pair IMSITOANRES2/ACK to MNSAN to determine if the

subscriber belong to the home PLMN (OWNMS). This IMSI series analysis against the OWNMS analysis result is required since selective authentication is only performed for MS within their home PLMN. If the MS does not belong to the home PLMN, then MTV indicates zero for the number of cipherings allowed without authentication; otherwise, it returns the number fetched from MTRIP. MTV returns this information along with the active keys and the CKSN to MAUTH with backward combined signal RACTKEYSACK. Note that for simplicity purposes the side links to MTV, such as MTRIP, are only shown in the figures when information from these side links is accessed. 103. MAUTH then checks that the number of cipherings allowed without authentication is greater than zero and that the CKSN received from the MS in the Paging Response message matches the one in the VLR from the previous step. In this example, the number of cipherings allowed without authentication is indeed greater than zero and the CKSNs match and thus selective authentication is allowed to proceed. Thus MAUTH sends combined signal pair UPDATEKEYS/ACK to MTV to decrease by one the counter for the number of cipherings allowed without authentication. MTV in turn sends nest combined signal pair REQUPKEYS/ACK to MTRIP to update this information. Note that the initial number of successive subscriber accesses allowed to be performed without authentication for GSM security is determined by DBS parameter GSMMMSC:SELAUTHCIPNR in block MAUTH. 54 MTRIP - Mobile telephony TRIPlet store and authentication data handler MTRIP is an MDS block that stores authentication vectors (triplets or quintuplets) for mobile subscribers in the MSC/VLR. The authentication vectors are used for authentication and ciphering during traffic handling. 104. MAUTH then returns AUTHENTICATE1R to MVLRP to indicate the first part of authentication is completed. This is the response to signal AUTHENTICATE1 in step 101 above. Note if MTRIP did not have any active keys or if the CKSNs did not match, then MAUTH would need to perform authentication with the MS. MAUTH would have sent the DTAP-Authentication Request message to the MS and then would have waited for the DTAP-Authentication Response message. In order to perform authentication, a new authentication vector would have been required. If a new authentication vector were not available in the VLR, then MAUTH would have fetched it from the HLR/AUC via the MAP-Send Authentication Info operation. Refer to the Registration lesson for such details on the authentication process.

105. MVLRP sends the INITCOMID message to MRRM via MMM. For DTM (Dual Transfer Mode) cases, MRRM may send the BSSMAP-Common Id message in order to inform the BSC of the IMSI associated with this SCCP connection. According to the specifications, if the MS, the BSS and the MSC support DTM and as soon as the IMSI is available at the MSC, the MSC shall send the BSSMAP-Common Id message to the BSS. See specification 3GPP TS 48.008 Rel. 5 for more details. There is no need to send the BSSMAPCommon Id message in this example. 106. MVLRP then verifies if the BSS Trace Invocation feature applies to this subscriber with signal pair TRACEINFOREQ/R to MTV. The subscriber in this example is not being traced. However, if the function did apply to this subscriber, MVLRP would order MRRM via MMM to send the BSSMAP-MSC Invoke Trace message to the BSC in order to start the tracing. 107. MVLRP proceeds with the second part of the security procedures again with signal AUTHENTICATE1 to MAUTH. Since ciphering is active in the MSC and the Ciphering Key Sequence Number received in the RR-Paging Response matches the one fetched in MTRIP at step 102 above, MAUTH orders the sending of the BSSMAP-Cipher Mode Command message with signal SENDCIPH1 to MMM. MMM transits this signal to MRRM. This signal contains GSM Kcs (ciphering keys) and also indicates whether or not to fetch the IMEI. . Note the IMEI can be fetched via the BSSMAP-Cipher Mode Command or via the DTAP-Identity Request. The IMEI fetching method is determined via an MT exchange property, IMEIFETCHCIPH. In this example, the indication in MVLRP is not to check nor fetch the IMEI and hence there is no need to fetch the IMEI from the MS. The IMEI fetch indication is actually stored in block MEC as a local parameter (IMEIFETCH) and is read by MVLRP from MEC at restart. The IMEI check indication is determined by a DBS parameter in block MEC, GSMMMSF:IMEICHECK. 108. Since the Cipher Mode Command is a BSSMAP type message, MRRM will ask MRRMH to encode the message. However, since the MS in this example is also UMTS capable, MRRM first reads the UMTS ciphering and integrity keys from MAUTH with signal SENDCIPHU/ACK via MMM. MRRM may need this information later on if the MS switches to UMTS. MAUTH obtained these keys earlier at step 102.

Figure 22 109. MRRM initiates the building of the BSSMAP-Cipher Mode Command message by sending to MRRMH the Layer 3 Header optional information element with combined signal pair RRLAY3HDOUT/ACK. MRRM also sends the

mandatory Encryption Information element with combined signal pair RRENCRYPOUT/ACK. In a previous step, the MRRMH individual unpacked a received BSSMAP message, in this step it will pack a BSSMAP message that is to be sent to the BSC. Once all the information elements are forwarded for packing, MRRM orders MRRMH to send the connection oriented BSSMAP message to SCCP with direct signal SENDBSSMAPCO. CCSBSCSCCOCMSCCOMRRMMRRMHMMM110bRNOCOMREQCB110cSCDATAREQCB MECMMMCS109bRRENCRYPOUT / ACK 110aRNOCOMREQCB109aRRLAY3HDOUT / ACK 109cSENDBSSMAPCO 110dSCDATAREQCBACKBSSMAP Cipher Mode CommandSCCP DT1 (Data Form 1) MRRMASGMRRMHO Cipher Mode Command Parameters The Cipher Mode Command message (3GPP TS 48.008 Rel. 5) contains 1 mandatory and 1 optional parameter: Encryption Information - This element is a mandatory parameter that contains the user data encryption information used to control any encryption equipment at the BSS, i.e. Kc and permitted algorithms. Layer 3 Header Information - An optional parameter, that provides information the BSS needs over the air interface; however, it no longer serves any useful purpose unless the BSS requires it for backward compatibility. 110. MRRMH allocates a CB4k and writes the Cipher Mode Command message into it. MRRMH then sends the message to MRRM with signal RNOCOMREQCB, MRRM forwards it downlink to MSCCO as a hurry signal. MSCCO forwards this message to SCCOC with combined signal pair SCDATAREQCB/ACK. SCCOC along with other CCS blocks then ensure that the Cipher Mode Command message is sent to the BSC over the SCCP connection. SCCOC also releases the CB4k allocated by MRRMH above.

Figure 23 111. When the BSC receives the Cipher Mode Command message, it selects an appropriate algorithm, taking into account the MS ciphering capabilities. Once ciphering is successfully established with the MS, the BSC responds with a BSSMAP-Cipher Mode Complete message on the A-interface to the MSC. This message is connection oriented, so its contents are provided by SCCOC in a newly allocated CB4k to MSCCO with direct signal SCDATAINDCB. Note that at this point the MMS subsystem does not yet know the message type. The

message is then forwarded to MRRM with signal RNICOMINDCB. This signal contains the discrimination parameter, which indicates it is a BSSMAP type message. Therefore, MRRM forwards the message to MRRMH, also with RNICOMINDCB but as a hurry signal, for analysis and unpacking. MRRMH transfers the content of the CB4k to its own internal buffers and then analyzes the message by first determining the message type and then checking for any formatting errors. MRRMH releases the CB4k and then reports its result as well a list of received optional parameters to MRRM with hurry signal RCVBSSMAPCO1, which in this example includes the BSSMAP message type of Cipher Mode Complete. 112. There are no mandatory parameters in the Cipher Mode Complete message and one optional parameter was received in this example. MRRM reads the Chosen Encryption Algorithm parameter with combined signal pair RRCHOALGIN/ACK to MRRMH. This information is forwarded to MAUTH in the next step. CCSBSCSCCOCMSCCOMRRMMRRMHMMMMECMMMCS111cRNICOMINDCBBSSMAP Cipher Mode CompleteSCCP DT1 (Data Form 1) 111aSCDATAINDCB111bRNICOMINDCB111dRCVBSSMAPCO1MRRMASGMRRMHO112 RRCHOALGIN / ACK Cipher Mode Complete Parameters The Cipher Mode Complete message (3GPP TS 48.008 Rel. 5) contains no mandatory parameters and a few optional parameters, some of which are included below. Chosen Encryption Algorithm - This optional element indicates the encryption algorithm being used by the BSS. This page is intentionally left blank. Figure 24 113. MRRM then informs MAUTH, via MMM, with signal SENDCIPH1R that the ciphering was successfully completed. SENDCIPH1R is a reply signal to SENDCIPH1 at step 107 above. MMMMECMMMCSMVLRPMTV118ACCESSREQUEST2RMRRMMRRMHMAUTH114eAU THENTICATE1R115bRELEASEAUTHR113aSENDCIPH1R 114bDISCAUTH 113bSENDCIPH1R 114aDISCAUTH

114cDISCAUTHR114dDISCAUTHR115aRELEASEAUTH117aRADIOCONTACT / ACK117bUPDATEMSLOC1 / ACK120bGETACCESS / ACKMAUTH120a/cGETACCESS / ACK 116aBUSYMARKMSUB / ACK116bRUNUSED116dRUNUSEDRMTRIP116cREQUNUSED/ACK119READMWF / ACK 121bGETLOCDATA / ACK121a/cGETLOCDATA/ ACK116eIDLEMARKMSUB / ACK MAUTH then verifies if a new TMSI needs to be allocated. Since the TMSI allocation feature if inactive in this example, MAUTH proceeds; otherwise, it would have reserved a TMSI in block MTMSIAN and then ordered the sending of the DTAP-TMSI Reallocation Command to the MS and waited for the DTAPTMSI Reallocation Complete. TMSI allocation is determined by DBS parameter GSMMMSC:TMSIPAR, which is stored in block MAUTH. 114. Since MAUTH has finished with the security related functions, it first releases the ciphering procedure in MRRM by sending signal DISCAUTH to MRRM via MMM. MRRM replies via MMM with signal DISCAUTHR. MAUTH then returns signal AUTHENTICATE1R with a successful indication to MVLRP. AUTHENTICATE1R is a reply signal to AUTHENTICATE1 at step 107 above. 115. At this point, all security related functions are complete. As a result, MVLRP releases the MAUTH individual with signal pair RELEASEAUTH/R. 116. Before returning to idle MAUTH verifies whether or not a new set of triplets needs to be fetched from the HLR/AUC. MAUTH first busy marks the MTV record for fetching of triplets with combined signal pair BUSYMARKMSUB/ACK. It then asks MTV for the number of unused triplets present in the VLR with signal RUNUSED. MTV fetches this information from MTRIP with combined signal pair REQUNUSED/ACK and returns it to MAUTH with signal RUNUSEDR. MAUTH then checks if the number of unused triplets is

greater than the allowed threshold (DBS parameter GSM1APTC:AVTHRESHOLD). If it were not greater, then MAUTH would initiate the fetching of authentication vectors. In this example, the fetching of new triplets is not required and thus MAUTH idle marks the MTV record for fetching of triplets with combined signal pair IDLEMARKMSUB/ACK and goes to idle itself. For more information on authentication, selective authentication, ciphering, TMSI allocation and other security features refer to FS (Function Specification) Mobile Subscriber Related Security Functions in MSC/VLR. 117. Since the security functions were successfully completed, MVLRP tells MTV that a successful radio contact has been established by the MS with combined signal pair RADIOCONTACT/ACK. MTV ensures the subscriber state is set to attached and clears the implicit detach and deregistration timers. MVLRP also updates the LA pointer in MTV with combined signal

UPDATEMSLOC1/ACK. 118. At this point MVLRP has validated the access and thus confirms this fact to MMMCS with signal ACCESSREQUEST2R. Note that this signal is a response to signal ACCESSREQUEST2 at step 93. 119. MMMCS then reads the message waiting flag in MTV with combined signal pair READMWF/ACK. If the flag indicates that there is an outstanding message, then MMMCS orders the sending of the MAP-Ready for SM (or MAPNote MS Present, MAP V1) message, via block MSMPAP55. This message would be sent later in the process, after step 127, in order to inform the HLR that the MS is again reachable. Not the case in this example since there was no outstanding message. 120. MMMCS fetches the access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via the MMM individual. The access type is required to determine which type of location information to fetch in the next step (CGI or SAI). 121. Since the access type in this example is GSM, MMMCS fetches the location information from MRRM via MMM with combined signal pair GETLOCDATA/ACK. The CGI and TA (Timing Advance) values provided by MRRM are then used as input to the spatial trigger event. MMMCS reports the mobile terminating traffic spatial trigger event to MSTEH56 with signal STEENCOUNTER. This signal initiates another independent thread within this process. MSTEH will need to determine if it needs to act upon this event, see step 129 below. 55 MSMPAP - Mobile telephony Short Message MS Present Application Part MSMPAP is an SHS (SHort message Subsystem) block that controls the Mobile Application Part (MAP) dialogue related to the VLR procedure "handling of ready for short message" towards the HLR. 56 MSTEH - Mobile telephony Spatial Trigger Event Handler MSTEH is an LSS (location Services Subsystem) block that handles IMSI-based and subscriberbased spatial triggers event data necessary for the support of spatial triggers feature. It is responsible for the sending of triggering location information to the GMLC (Gateway Mobile Location Center). 6.3.4.8 Joining of Call Paths and Verification of Features Figure 25 122. Now that the MS has been validated, MMMCS confirms the page response to MPAG with forward combined signal PAGECONF. MPAG then idle

marks the MTV record for paging with combined signal pair IDLEMARKMSUB/ACK. This undoes the busy marking of step 68. MPAG also stops the paging timer it started at step 78 above. 123. MPAG translates the LAI received in PAGECONF to a LATA pointer with signal LOCTOLATA/ACK to block MBSSD. MPAG performs the call delivery LATA mismatch check since the DBS parameter GSMMMSC:CTRESTLATA is set and the call delivery LATA pointer is known. Note this is the same parameter use at step 69. Since the LATA used to assign the MSRN is the same as the LATA in which the call is set up, MPAG returns backward combined signal PAGECONFACK to MMMCS with a successful indication. This signal also contains the MTB block reference and pointer, which MMMCS will soon use to bridge the paging request and paging response call paths. 124. MMMCS then fetches the CGI from MRRM with combined signal pair GETCGI1/ACK that transits via MMM. The CGI is required for the regional services check that MMMCS initiates as this point but whose signals only appear at step 130 due to the nature of buffered signals. 125. At this point MMMCS has completed its connection set up task and begins linking out of the call path chain as well bridging the two ends of the call paths together. It asks block MTBCC, via MTB to set its down link to MMM with combined signal pair SETDOWNLINK2/ACK, which MTB forwards as combined MMMMECMMMCSMTBMABCMTBCCMTBSSMCCMHMPAGMBPAGMVLRPMBSSDMT VMUABCMCCPHMRRM124bGETCGI / ACK 123aLOCTOLATA / ACK122bIDLEMARKMSUB / ACK 125dFWDSCREENING/ ACK 126bBUSYMARKMSUB / ACK122aPAGECONF123b/ ACK 124a/cGETCGI/ ACK125a/gSETDOWNLINK2/ ACK 125b/fMDOWNLINK/ACK125c/eFWDSCREENING / ACK 126a/cCHANGEUPLNK1 / ACK127CHKUENOTIFY / ACK signal pair MDOWNLINK/ACK. These signals contain MS Classmark 2 information (in particular SS screening indicator), which MTBCC forwards to MCPPH, via MCCMH, with combined signal pair FWDSREENING/ACK. 126. MMMCS then asks MMM to change its uplink to MTBCC with combined signal pair CHANGEUPLNK1/ACK. This prompts MMM to busy mark the MTV record for CM (Connection Management) level with combined signal pair BUSYMARKMSUB/ACK. At this point MMMCS is no longer in the call path chain. 127. MMMCS also checks if there exists a deferred MT-LR (Mobile Terminating Location Request) with combined signal pair CHKUENOTIFY/ACK to MTV. If there were a deferred MT-LR request, MMMCS would have to inform the appropriate location services block that the UE (User Equipment, i.e. MS) is now available.

Note that if the radio confirmation flag at step 96 indicates that the location information was not previously confirmed in the HLR, then MMMCS would initiate a location update to the HLR, in parallel with the mobile termination process. This is accomplished by sending signal INITPARALOCUPD to MMM which would first busy mark the MTV record for location updating and then seize an MMMLR57 to coordinate this parallel location updating process. This is not the case in this example. Note that if the regional services result allows the sending of the MAP-Ready for SM (or MAP-Note MS Present, MAP V1) message, which may have been required by the message waiting flag check at step 119 above, it would be sent at this point in the process. This message informs the HLR that the MS is again reachable so that, for example, an outstanding SMS message can be delivered. 57 MMMLR - Mobile telephony Mobility Management Location Registration MMMLR is an MMS block that contains functions for updating the location registration of an MS to the VLR. Figure 26 MMMMECMABCMTBCCMPAGMVLRPMTVMUABCMRRM128bSTARTCM131aSTARTIM EICHK1131bSTARTIMEICHK1R131cIMEICHECKED128aSTARTCM131dIMEIACCESINFO 13eIMEICLASSINFOMBPAGMBSSD132aPAGEDISC131fIMEIACCESINFO131gIMEICLASS INFO133cPAGEDISCR133bGSMPAGERELR133aGSMPAGEREL132bLAITOLAP1 / RMBPAGMTBMPAGMMMCSMZONE129bPREVENTDISC / ACK129cRDIMSIMSISDN / ACK 129dREADSTE129eREADSTER129fALLOWDISC / ACK129gIMSITOANRES3 / ACKMNSAN129aSTEENCOUNTER 130bFETCHZCDATA / ACK130cZCFCHECKR130aZCFCHECKMSTEHMSTEHMZONE Note that at this point, MMMCS sends several signals that initiate several parallel processes; therefore, the signal order over the next 6 steps is not maintained in order to facilitate the understanding of the various processes. 128. MMMCS then hands over control of the call processing to the CM layer by sending hurry signal STARTCM to MTBCC. MTBCC transits the same signal as a buffered signal to MTB. 129. At step 121 above another independent process was triggered when a spatial trigger event indication (Mobile Terminating Traffic) was sent to MSTEH with signal STEENCOUNTER. MSTEH seizes an individual and then determines if it needs to act upon this event. MSTEH uses combined signal pair

PREVENTDISC/ACK to remove MTV from the suitable list and thus ensure the MTV will not be disconnected during this process. MSTEH fetches both the IMSI and MSISDN from MTV with combined signal pair RDIMSIMSISDN/ACK to ensure valid subscriber number information is available. MSTEH also reads the spatial trigger event information from MTV with signal READSTE/R. In this example, MTV has no side link to an MTVLCS58 individual and thus immediately responds with signal READSTER with an unsuccessful indication. Since there are no stored subscriber based spatial triggers, MSTEH sends combined signal 58 MTVLCS - Mobile Telephony Visiting subscriber LoCation Services MTVLCS is an MDS block that stores the LCS (LoCation Services) subscriber related information in order to support GSM location services according to the standard. This block stores all the LCS information such as privacy exception list, MO-LR (Mobile Originating Location Request) list of LCS originating classes that the MS is permitted to request, GMLC (Gateway Mobile Location Center) list from which a MT-LR (Mobile Terminating Location Request) is allowed. pair ALLOWDISC/ACK to MTV. MSTEH looks for IMSI based STPROF (Spatial Triggers PROFiles) with combined signal pair IMSITOANRES3/ACK to MNSAN. Since there are no IMSI based spatial triggers in this example, MSTEH need not contact the GMLC (Gateway Mobile Location Center) node, thus MSTEH returns to idle. For more information of spatial triggers refer to FS Spatial Triggers in MSC/VLR Server. 130. After step 124 above, if any of the regional services (local subscription, regional subscription and subscription with tariff areas) are supported in the MSC, MMMCS orders MZONE to perform a subscription area check with signal ZCFCHECK. MZONE dedicates an individual to this task. This individual then fetches the zone code set from the MTV with combined signal pair FETCHZCDATA/ACK. The VLR zone code data is stored in block MTVZONE; however in this example, since the MTV individual has no link to MTVZONE, it knows there is no zone code data and indicates this to MMMCS with signal ZCFCHECKR. As a result, the process proceeds successfully. See FSs Local Subscription in MSC/VLR Server, Regional Subscription in MSC/VLR Server, Subscription with Tariff Areas in MSC/VLR Server and Regional Services in HLR for more details on the regional services feature. 131. Upon reception of signal CHANGEUPLINK at step 126, MMM asks MEC to perform the IMEI check with signal STARTIMEICHK1. Note that although the exchange settings are such that the IMEI was never received in this call scenario (see after step 107), the signal is nevertheless sent to MEC. Because no IMEI is available, MEC immediately returns the STARTIMEICHK1R signal with the default call through connection information to MMM. This signal informs MMM

that it can proceed with call set up and through connection. In other words, there is no need to wait for the IMEI check to complete. MMM forwards this information to the CM level with signal IMEIACCESSINFO1 to MTBCC which is passed on to MTB. MEC also returns the default IMEI check result with signal IMEICHECKED to MMM. This signal indicates that the IMEI check was successful although none was performed; MMM forwards this indication to MTB via MTBCC with signal IMEICLASSINFO. 132. At the reception of signal STARTCM at step 128, MTB orders the release of the MPAG individual with signal PAGEDISC. MPAG asks block MBSSD to translate the LAI (LA Identity) into an LA pointer an with signal pair LAITOLAP1/R. MPAG needs the LA pointer in which the page was answered in order to step the appropriate paging counters. 133. MPAG order the release of the MBPAG individual with signal GSMPAGEREL. MBPAG responds with signal GSMPAGERELR and returns to its idle list. MPAG then in turn responds to MTB with signal PAGEDISCR and returns to its idle list.

Figure 27 134. The MVLRP individual is no longer required, so MMMCS orders its release with signal RELEASEMVLRP. MVLRP sends combined signal pair ALLOWDISC/ACK to MTV in order to undo the prevent disconnection indication from step 95. MVLRP replies to MMMCS with signal RELEASEMVLRPR and returns to idle state. At this point, the MMMCS individual sends itself a CONTINUEB signal in order to receive any buffered signals that may have been sent to it before returning itself to the idle list. 135. MTB fetches the CGI from MRRM with combined signal pair GETCGI1/ACK that transits via MTBCC and MMM. Since the cell is local, i.e. no inter-MSC handover, MTB asks MBSSD to return the corresponding LN (Location Number) information with signal pair READCELLLN/R. The LN information will be used for the regional services check in the next step. 136. If any of the regional services (local subscription, regional subscription and subscription with tariff areas) are supported in the MSC, MTB orders MZONE, via MTBSS, to perform a subscription area check. Note this is the same check as in step 130 except that this time the MS location is identified with an LN rather than a CGI. MTB sends signal REGSERVCHK to MTBSS, which in turns sends signal ZCFCHECK to MZONE. MZONE dedicates an individual to this task. This individual then fetches the zone code set from the MTV with combined signal pair FETCHZCDATA/ACK. The VLR zone code data is stored in block MTVZONE; however in this example, since the MTV individual has no link to MTVZONE, it knows there is no zone code data and indicates this to MTBSS with signal ZCFCHECKR. MTBSS forwards the result to MTB with signal REGSERVCHKR. As a result, the process proceeds successfully.

MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMZONE136bZCFCHE CK136dZCFCHECKRMBSSD136aREGSERVCHK136eREGSERVCHKRMTBSS136cFETCHZ CDATA / ACK135cGETCGI / ACK135fREADCELLLN / R138dBSCPTOGLRTE / ACK135a/eGETCGI/ ACK135b/dGETCGI/ ACK138a/gGETCHARGDATA/ ACK138b/fGETCHARGDATA / ACK138c/eGETCHARGDATA/ ACKMVLRP134aRELEASEMVLRP 134cRELEASEMVLRPR MVLRPMMMCSMMMCS134dCONTINUEB134bALLOWDISC / ACK137aREPMONIEVENT137bREPMONIEVENTRto and fromMTBCOMZONE 137. MTB reports the fact that a downlink connection has been established to MTBCO with signal REPMONIEVENT. The signal contains the OIP-IAM CB4k pointer. MTBCO needs this information in case that monitoring of the subscriber is active. Since this is not the case, MTBCO immediately returns signal REPMONIEVENTR with a successful indication and control of the CB4k so that MTB can proceed. 138. MTB reads the global route number from MRRM via MTBCC and MMM with combined forward signal GETCHARGDATA. Before replying, MRRM asks block MBSSD to convert the BSC pointer into a global route number with combined signal pair BSCPTOGLRTE/ACK. MRRM then responds with the global route number in combined backward signal GETCHARGDATAACK. The global route number is required as charging data later on the process, step 196.

6.3.4.9 Setup Message Sent and Call Confirmed Message Received Figure 28 139. MTB orders the sending of the DTAP-Setup (Mobile Terminated) message with signal MSENDSETUP3 to MTBCC. MTBCC then fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM. Since the access is still GSM and the analysis of bearer capabilities for GSM succeeded, MTBCC proceeds with call setup. 140. Since the access is still GSM, MTBCC fetches the GSM/PLMN BC from MABC (for UMTS BC is fetched from MUABC) via MTB with forward combined signal pair MTFETCHBC. Before returning the BC, MABC attempts to read the classmark 3 information, in particular the MSs multislot capability, from MRRM via the downlink with combined signal pair GETCLMARK3/ACK. In this example, since MRRM did not previously receive the classmark 3 information (BSSMAPClassmark Update), it returns nothing and thus it is assumed the MS has no multislot capability. The BC is an optional parameter within the DTAP-Setup (Mobile Terminated) message. MABC returns the GSM/PLMN BC in backward combined signal MTFETCHBCACK. 141. MTBCC then attempts to fetch the HLC and LLC from MABC via MTB with combined signal pairs FETCHGSMLLC/ACK and FETCHGSMHLC/ACK.

Both HLC and LLC are optional parameters within the DTAP-Setup (Mobile Terminated) message. Neither one exists in this example. 142. MTBCC then requests CLIP (Calling Line Identification Presentation) service information from MTB with combined signal MTFETCHCLIP/ACK. MTBCC uses this information to determine if the Cause of no CLI parameter is to be included in the DTAP-Setup (Mobile Terminated) message. This parameter is MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMTBSS139aMSENDSE TUP3141bFETCHGSMLLC / ACK 141eFETCHGSMHLC / ACK142MTFETCHCLIP / ACKMTBCOMCSEMCEDHC144aSENDRNMSG1143aBEARER1CAP1144bRNOCOMREQC B144cRNOCOMREQCB144dRNOCOMREQCB143cCALLINGNUMREQ139b/dGETACCESS / ACK 139cGETACCESS / ACK 140b/jMTFETCHBC/ ACK 140c/iGETCLMARK3/ACK140d/hGETCLMARK3/ACK140a/kMTFETCHBC/ ACK 140e/gGETCLMARK3 / ACK140fGETCLMARK3 / ACK141a/cFETCHGSMLLC/ ACK141d/fFETCHGSMHLC/ ACK143bLOADDATACCMH / ACK included if the terminating subscriber has the CLIP feature but the CLI cannot be presented and if DBS parameter GSMMSSF:CAUSEOFNOCLIM allows this parameter to be sent. Since the CLIP information is available in this example, the Cause of no CLI parameter is not sent. 143. MTBCC sends the BC received at step 140 to MCCMH to be packed in the message with signal BEARERCAP1REQ1. MTBCC also asks block MTB to load data directly into MCCMH with combined signal LOADDATACCMH/ACK. MTB sends the CLIP information received at step 53, Calling Party BCD Number parameter, with signal CALLINGNUMREQ. Setup (Mobile Terminated) Parameters The Setup (Mobile Terminated) message (3GPP TS 24.008 Rel. 5) contains no mandatory and several optional parameters. Only the parameters that MTBCC or MTB send or attempt to fetch are presented below. Bearer Capability 1 and 2 - is an optional parameter whose purpose is to describe a bearer service. The reason this parameter appears twice is because an MS can indicate capability for an alternative call mode. The bearer capability 1 information element may be omitted in the case where the mobile subscriber is allocated only one directory number for all services BC Repeat Indicator - is a conditional parameter whose purpose is to indicate how the associated repeated information elements shall be interpreted. It is included if both Bearer Capability parameters are included within the Setup (Mobile Terminated) message. Low/High Layer Compatibility 1 - each is an optional parameter that is

included when the calling MS wants to pass low/high layer compatibility information to the called user. The purpose of the low/high layer compatibility information is to provide a means to an addressed entity, i.e. called user, to perform compatibility checking. Facility - an optional parameter that is included for functional operation of supplementary services. The parameter is an array of octets whose interpretation is defined in specification 3GPP TS 24.080 Rel. 5 "Mobile radio layer 3 supplementary services specification, Formats and coding". Calling Party Number - is an optional parameter which is used to identify the calling party, i.e. CLIP feature. Calling Party Subaddress - an optional parameter whose purpose is to identify a subaddress associated with the origin of a call. Called Party Subaddress - an optional parameter whose purpose is to identify the subaddress of the called party of a call. Cause of no CLI - an optional parameter whose purpose is to provide the MS the detailed reason why the calling party BCD number is not provided. 144. MTBCC sends signal SENDRNMSG1 to order MCCMH to pack the DTAP-Setup (Mobile Terminated) and send it to the MS via the SCCP connection on the A-interface. MCCMH allocates a CB4k and writes the Setup message into it. MCCMH sends the message to MTBCC with signal RNOCOMREQCB. MTBCC, MMM and MRRM forward this signal downlink to MSCCO as a hurry signal. MSCCO forwards this message to SCCOC with combined signal pair SCDATAREQCB/ACK. SCCOC along with other CCS blocks then ensure that

the Setup message is sent to the BSC over the SCCP connection. SCCOC also releases the CB4k allocated by MCCMH above. Figure 29 CCSBSCSCCOCMSCCOMRRMMRRMHMMMMECMTVDTAP Setup (Mobile Terminated Call Establishment) SCCP DT1 (Data Form 1) 145aSCDATAINDCB145bRNICOMINDCB144dRNOCOMREQCB144eRNOCOMREQCB144f SCDATAREQCB / ACKDTAP Call Confirmed SCCP DT1 (Data Form 1) 145cRNICOMINDCB145dRNICOMINDCBMRRMASGMRRMHO At this point, the CM level waits for the DTAP-Call Confirmed message to arrive from the MS. 145. The Call Confirmed message is connection oriented, so its contents are provided by SCCOC in a newly allocated CB4k to MSCCO with direct signal SCDATAINDCB. Note that at this point the MMS subsystem does not yet know

the message type. The message is then forwarded to MRRM with signal RNICOMINDCB. This signal contains the discrimination parameter, which indicates it is a DTAP type message. Since it is not a BSSMAP type message, MRRM forwards the message uplink to MMM, also with RNICOMINDCB but as a hurry signal. MMM reads the protocol discriminator, which indicates it is a CC (Call Control) type message hence belonging to the CM level. Therefore, MMM forwards the message uplink to MTBCC also with RNICOMINDCB as a hurry signal. MTBCC immediately forwards this same signal as a hurry signal to MCCMH for unpacking. MCCMH transfers the content of the CB4k to its own internal buffers and releases the CB4k. It then analyzes the message for any errors or missing mandatory information elements and reports that the message is approved with signal RECEIVERNMSG1.

This page is intentionally left blank. Figure 30 146. MTBCC begins to read the parameters within the DTAP-Call Confirmed message. MTBCC requests the parameters one at a time, always with combined forward signal FETCHIE to MCCMH. The requested parameter is determined by a data word within this signal. The combined backward signal returned by MCCMH depends on the parameter requested. The 6 requested parameters along with their combined backward signal name are the following: Stream Identifier STREAMIDIND, BC Repeat Indicator REPEATIND, Bearer Capability 1 BEARCAP1IND2, Bearer Capability 2 BEARCAP2IND2, Supported Codec List SUPPCODECIND and Cause CAUSEIND. Since all the necessary parameters have been read, MTBCC releases the buffered message in MCCMH with signal CLEARBUFF1. Note that only the Bearer Capability 1 is received in this example. MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMTBSS147aFORWAR DPLMNBC148aABCMTCCONF1151aABCMTCCONF1RMCSE145fRECEIVERNMSG1145dR NICOMINDB145eRNICOMINDCB146a/c/FETCHIE(5 times) 146bSTREAMIDIND146fBEARCAP1IND2146dREPEATIND146hBEARCAP2IND2146jSUPP CODECIND146mCLEARBUFF1147bFORWARDPLMNBC148bABCMTCCONF1147cFRWAR DPLMNBC151bABCMTCCONF1R152aUABCMTCCONF154cUABCMTCCONFR152bUABC MTCCONF 154bUABCMTCCONFR 152cUABCMTCCONF 154aUABCMTCCONFR MRRMHMTECA155bGETACCESS / ACK 156b/dGETACCESS / ACK156cGETACCESS / ACK156a/eGETACCESS/ACK 155a/cGETACCESS / ACK

146lCAUSEIND149MMAINTSA1/ACK150MBCOMPANA1/ ACK152dUMMAINTSA1/ACK153UMBCOMPANA/ACKMTBCOMCEDHC Note that unlike the RR and MM layer message handlers, MCCMH does not provide a list of received optional parameters at unpacking and thus MTBCC must attempt to fetch all parameter it may be interested in. Call Confirmed Parameters The Call Confirmed message (3GPP TS 24.008 Rel. 5) contains no mandatory and several optional parameters. Only the parameters that MTBCC attempts to read are presented below. Stream Identifier - an optional parameter whose purpose is to associate a particular call with a Radio Access Bearer (RAB) when an MS supports multicall. Bearer Capability 1 and 2 - is a mandatory parameter whose purpose is to describe a bearer service. The Bearer Capability information element is used

for compatibility checking. The reason this parameter appears twice is because an MS can indicate capability for an alternative call mode. Refer specifications to see in which scenarios BC1 must be included Repeat Indicator - is a conditional parameter whose purpose is to indicate how the associated repeated information elements shall be interpreted. It is included if both Bearer Capability parameters are included within the Call Confirmed message. Supported Codec List - is a conditional parameter whose purpose is to provide the network with information about the speech codecs supported by the MS. Cause - The purpose of the cause information element is to describe the reason for generating certain messages, to provide diagnostic information in the event of procedural errors and to indicate the location of the cause originator. 147. When MTBCC receive the Bearer Capability 1 parameter above, it forwards this parameter to MTB with signal FORWARDPLMNBC. MTB forwards this signal to MABC which forwards it onwards to MUABC. Both the MABC and MUABC individuals store the MSs bearer capabilities so that they can be used later at analysis of bearer capabilities. 148. MTBCC orders the negotiation of the GSM/PLMN BCs with signal ABCMTCCONF1 to MABC via MTB. At this point MABC checks for compatibility between the BC received from the network and the one received in the the Call Confirmed message from the MS. 149. MABC then uses the BC to generate a BASC (BAsic Service Code,

either a teleservice or bearer service), which in this case turns out to be teleservice telephony. MABC then asks MTECA to analyze telecommunication services based on the BASC with combined signal pair MMAINTSA1/ACK. MTECA determines whether the telecommunication service requested by the MS is available in the system. If available, MTECA returns a set of parameters (TCL, WSIG, TBP, TPI, etc,) to be used during the call. 150. MABC goes back to MTECA to determine if the WSIG (Wanted SIGnalling) and TMR (Transmission Medium Requirements) between the originating and terminating ends are compatible. The combined signal pair used for compatibility analysis is MBCOMPANA1/ACK. 151. MABC then performs a subscription check to determine if the MS is subscribed to the BASC required for this call. MABC previously fetched the MSs subscribed BASC list at step 44 above. MABC returns the final result of analysis of bearer capabilities (after the Call Confirmed message) in signal ABCMTCCONF1R to MTBCC via MTB. 152. MTBCC then repeats the analysis of bearer capabilities (after the Call Confirmed message) for UMTS with signal UABCMTCCONF to MUABC via MTB and MABC. MUABC also generates a BASC (BAsic Service Code) and asks MTECA to analyze telecommunication services based on the BASC with combined signal pair UMMAINTSA1/ACK. 153. MUABC goes back to MTECA to determine if the WSIG (Wanted SIGnalling) and TMR (Transmission Medium Requirements) between the

originating and terminating ends are compatible. The combined signal pair used for compatibility analysis is UMBCOMPANA/ACK. 154. MUABC performs a subscription check to determine if the MS is subscribed to the BASC required for this call on UMTS. MUABC previously fetched the MSs subscribed BASC list at step 47 above. MUABC returns the final result of analysis of bearer capabilities (after the Call Confirmed message) in signal UABCMTCCONFR to MTBCC via MABC and MTB. 155. MTBCC then fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM. Since the access is still GSM and the analysis of bearer capabilities for GSM succeeded, MTBCC proceeds with call setup. 6.3.4.10 Channel Assignment Figure 31 156. When MTB transits signal UABCMTCCONFR at step 152 above, it also fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM and MTBCC. MTB needs this data to fetch the appropriate subscriber service data related to the BASC, the GSM BASC in this case. This is done by sending signal GETNEWBGDATA to MTBSS. MTBSS sends combined signal pair FETCHSSBSG/ACK to MTV, which sends

nested combined signal pair FETCHSTBSG/ACK to MTVS. Among the data returned to MTB with signal GETNEWBGDATAR is: no reply timer, CUG information and an indication of whether call forwarding may occur. Note some of this data was already fetched at step 49 above but is fetched again in case the access type changed. MMMMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMTBSSMCSE156fGETNEW BGDATA160aASSIGNMENT1MTVS156hFETCHSTBSG / ACK156jGETNEWBGDATAR158aFETCHTCHDAT3/ACK158cFETCHRABDATA2 / ACK 159GETSSVDATA / ACK160bASSIGNMENT1MRRMHCOMAINRMPSeize 2SwitchingSwitch Views156g/iFETCHSSBSG/ ACK 158b/dFETCHRABDATA2 / ACK MTBCO157aREPMONIEVENT157bREPMONIEVENTRMRRMHOMRRMASG161bASSIGN MENT1 161aASSIGNMENT1MCEDHC 157. MTB reports the fact that MS data for this mobile terminating call is now available to MTBCO with signal REPMONIEVENT. MTBCO needs this information in case that monitoring of the subscriber is active. Since this is not the case, MTBCO immediately returns signal REPMONIEVENTR with a successful indication so that MTB can proceed. 158. MTB begins preparing the sending of the BSSMAP-Assignment Request message. Since the RR layer packs this message and lots of data needs to be transferred downlink via the call path, MTB seizes a CB128 to facilitate the transfer of this information. MTB then reads traffic channel data for traffic channel assignment from MABC with combined signal pair FETCHTCHDAT3/ACK. Having previously determined during analysis of BCs that this is a simple speech call, MABC sets certain traffic channel data values for speech and returns other data such as allowed speech coder version information. MTB fetches the UMTS assignment data from MUABC via MABC with combined signal pair FETCHRABDATA2/ACK. MTB stores whatever valid data it receives in the CB128. 159. MTB then fetches the SSV (Switching Switch View) data from MCSE with combined signal pair GETSSVDATA/ACK. MTB is interested in the downlink logical channel of the SSV seized at step 50, so that it can pass this information downlink so that other SSVs can join to it. 160. MTB then orders the sending of the BSSMAP-Assignment Request message with signal ASSIGNMENT1 to block MTBCC, which transits the signal downlink to MMM. Among the data in this signal is the CB128 pointer, granted eMLPP, and the downlink MSS SSV logical channel acquired in the previous step. 161. Before transiting the ASSIGNMENT1 signal, the MMM individual seizes two SSVs via block COMAIN in the RMP (Resource Module Platform). Refer to

Connection Service (CSE) service specification document for details on this process. Both SSVs are seized as two-way connections. The first SSV seized is joined to the downlink logical channel of the MSS SSV seized by MCSE, while the second SSV seized by MMM is joined to the first. MMM seizes two SSVs to facilitate the insertion of other SVs without disturbing the uplink or downlink SVs. For example, in case of speech monitoring, the RES subsystem seizes two MSVs (Monitoring Switch Views) and links them in between MMMs two SSVs. MMM then transits signal ASSIGNMENT1 to MRRM which forwards it onwards to MRRMASG.

Figure 32 162. Upon receiving signal ASSIGNMENT1, MRRMASG uses the CB128 pointer provided in the signal to read the traffic channel data stored by MTB in this CB128. MRRMASG then asks MEPPA with combined signal GETASSIGNINF/ACK to provide the priority information corresponding to granted EMLPP priority level. MRRMASG then asks MBSSD to translate the BSC pointer to the corresponding incoming and outgoing route numbers with combined signal pair BSCPTORTE/ACK. Note that MBSSD provides both local and remote route pointers and MALT references to MRRMASG. MRRMASG then select either local or remote values depending of the MGW type selected (combined or remote). MRRMASG forwards these route pointers to MRRM with combined signal pair STOREBSCROUTEP/ACK. MRRMASG then asks MBSSD to provide certain BSC characteristics with combined signal pair BSCTOBSCDATA/ACK. This signal is sent twice. 163. MRRMASG then requests a terrestrial line to the BSC, i.e. a MALT (Mobile telephone A-Line Terminal) device. MRRMASG sends signal SEIZEALT2 to block MALTM59, ordering the seizure of a MALT device on the appropriate route. MRRMASG determined the route to the BSC at step 162. MALTM then selects an idle device on this route. MSCCOMRRMMRRMHMMMCOMAINRMPMRRMASGSCCOCCCSBSCMTBCCMCCMHM CCPHMALTM163SEIZEALT2165aALTSEIZED3 164a/eASKSVDATA/ R165bFREESVDATA 164cASKSVDATA / RMEPPAMBSSD162dBSCTOBSCDATA / ACK162bBSCPTORTE / ACK 162eBSCTOBSCDATA / ACK161bASSIGNMENT1162cSTOREBSCROUTEP / ACK 165cFREESVDATA 165dFREESVDATA MRRMHO162aGETASSIGNINF / ACK Seize anAccessSwitch View164b/dASKSVDATA/ R 59 MALT - Mobile telephony A-interface Line Terminal MALT is an MMS block that owns A-interface lines, handles the selection and the release of devices,

performs actions such as blocking, deblocking and reset of the devices according to the reception of messages from the BSS. The block can send BSSAP messages to acknowledge or initiate actions. There are several variations of the MALT block whose software is the same but whose associated hardware varies: MALTM, MALNA51, MALT4, etc. 164. At this point, MALTM needs to seize an ASV (Access Switch View) via block COMAIN in the RMP and also needs to connect this switch view to the neighbouring uplink SSV. Therefore, MALTM asks MMM for the identity of the neighbouring SSV and its downlink logical channel with signal pair ASKSVDATA via MRRMASG and MRRM. Once this information is received in return signal ASKSVDATAR, MALTM orders the seizure of an ASV with a two-way connection and asks for it to be joined to the SSV supplied by MMM. When seizing an ASV, MALTM must also provide details of the physical access point (e.g. MUP, Multiple Position). 165. If the ASV is successfully seized, MALTM returns ALTSEIZED3 to MRRMASG as a response to SEIZEALT2 at step 163 and thus establishing a link to the MRRMASG individual. Furthermore, MALTM also sends signal FREESVDATA to MMM via MRRMASG and MRRM. This signal allows MMM to answer any buffered ASKSVDATA request that may have come in after the one from MALTM at step 164. The reason for buffering subsequent requests for SV data is to prevent a situation where more than one SV manipulation is ongoing at the same time, which would cause corruption in the linking of SVs.

Figure 33 166. Since MRRMASG is about to send the BSSMAP-Assignment Request message which will require a change of channel on the air interface and thus a small interruption of the connection to the MS, it asks the uplink to temporarily stop sending any DTAP messages with signal STOPDTAPMSG. Upon receiving this signal, both MMM and MTBCC flag this stop DTAP message indication. Before replying MTBCC sends itself a CONTINUEB signal to allow the message handler (MCCMH) to get rid of any buffered signals. Signal STOPDTAPMSGR is returned to MRRMASG as an acknowledgement. MRRMASG also asks MRRM to suspend any ongoing location services during the channel assignment with combined signal pairs SUSPENDLCS/ACK and SUSPENDLCSR9/ACK. 167. MRRMASG initiates the building of the BSSMAP-Assignment Request message by sending to MRRMH the Channel Type mandatory information element with combined signal pair RRCHTYPOUT1/ACK. In this example, a full rate or half rate speech channel with full rate preferred is requested. The Layer 3 Header and Priority optional information elements are sent with combined signal pairs RRLAY3HDOUT/ACK and RRPRIORITOUT/ACK. Since a MALT device is used for this call, the CIC (Circuit Identity Code) information element is required and sent with combined signal pair RRCICOUT/ACK. MRRMASG sends the

Downlink DTX Flag parameter with combined signal pair RRDTXFLAGOUT/ACK. Once all the information elements are forwarded for packing, MRRMASG orders MRRMH to send the connection oriented BSSMAP message to SCCP with direct signal SENDBSSMAPCO. MSCCOMRRMHMMM168bRNOCOMREQCB166bSTOPDTAPMSG MRRMASGSCCOCCCSBSCDTAP Assignment Request SCCP DT1 (Data Form 1) MTBCCMCCMHMCCPH166fSTOPDTAPMSGR166cSTOPDTAPMSG 166eSTOPDTAPMSGR168cSCDATAREQCB / ACK 167bRRLAY3HDOUT / ACK 167cRRPRIORITOUT / ACK167dRRCICOUT / ACK 167eRRDTXFLAGOUT / ACK 168aRNOCOMREQCBMALTMMEC166gSTOPDTAPMSGR166hSUSPENDLCS / ACK166iSUSPENDLCSR9 / ACK 166dCONTINUEB167aRRCHTYPOUT1 / ACK 167fSENDBSSMAPCOMRRM166aSTOPDTAPMSG Note that MRRMASG sends signals directly to MRRMH and not via MRRM. This is because MRRMASG has a direct link to MRRMH that was established at step 82 above. This link is not explicitly shown in the figures for simplicity purposes. Assignment Request Parameters The Assignment Request message (3GPP TS 48.008 Rel. 5) contains 1 mandatory and several optional parameters, some of which are included below: Channel Type - This element is a mandatory parameter that contains all of the information that the BSS requires to determine the required radio resource. Layer 3 Header Information - An optional parameter, that provides information the BSS needs over the air interface; however, it no longer serves any useful purpose unless the BSS requires it for backward compatibility. Priority - Indicates the priority level of the request and whether pre-emption and queuing are allowed CIC - A previously agreed upon number between the MSC and BSC at commissioning, which uniquely defines the terrestrial channel over which the call will pass. Downlink DTX Flag - indicates whether the DTX (Discontinuous Transmission) function in the BSS is to be disabled on a particular radio channel.

168. MRRMH allocates a CB4k and writes the Assignment Request message into it. MRRMH then sends the message to MRRM with signal RNOCOMREQCB, MRRM forwards it downlink to MSCCO as a hurry signal. MSCCO forwards this message to SCCOC with combined signal pair SCDATAREQCB/ACK. SCCOC along with other CCS blocks then ensure that the Assignment Request message is sent to the BSC over the SCCP connection. SCCOC also releases the CB4k allocated by MRRMH above.

Figure 34 169. When the BSC receives the Assignment Request message, it selects the appropriate radio resources and ensures the MS is available on this new traffic channel. The BSC also ensures that the terrestrial (trunk) resources on the Ainterface are set up. The BSC responds with a BSSMAP- Assignment Complete message on the A-interface to the MSC. This message is connection oriented, so its contents are provided by SCCOC in a newly allocated CB4k to MSCCO with direct signal SCDATAINDCB. Note that at this point the MMS subsystem does not yet know the message type. The message is then forwarded to MRRM with signal RNICOMINDCB. This signal contains the discrimination parameter, which indicates it is a BSSMAP type message. Therefore, MRRM forwards the message to MRRMH, also with RNICOMINDCB but as a hurry signal, for analysis and unpacking. MRRMH transfers the content of the CB4k to its own internal buffers and then analyzes the message by first determining the message type and then checking for any formatting errors. MRRMH releases the CB4k and then reports its result as well a list of received optional parameters to MRRM with hurry signal RCVBSSMAPCO1, which in this example includes the BSSMAP message type of Assignment Complete. 170. MRRM forwards the message analysis results to MRRMASG with signal ASSIGNCOMPLR. Since the message was successfully analyzed by MRRMH, MRRMASG asks MRRMH to unpack the contents of the message. There are no mandatory parameters in the Assignment Complete message and only two optional parameters were received in this example. MRRMASG reads the Chosen Channel and Chosen Speech Version parameters with combined signal pairs RRCHOSECHIN/ACK and RRSPEECHVIN/ACK. MRRMASG also asks MBSSD to provide certain BSC characteristics (BCIC, circuit pool function) with combined signal pair BSCTOBSCDATA/ACK. MSCCOMRRMHMMMMECSCCOCCCSBSCDTAP Assignment Complete SCCP DT1 (Data Form 1) MTBCCMCCMHMCCPH169aSCDATAINDCB 169cRNICOMINDCBMBSSD172cASSIGNCOMPL6173cSTARTDTAPMSG172dASSIGNCOM PL6MRRMASGMALTM173eASGPROCEEDLCS170bRRCHOSECHIN / ACK

170cBSCTOBSCDATA / ACK171aCGITOORG171bCGITOORGR173dCLEARRRMH173aSTARTDTAPMSGAS169dRC VBSSMAPCO1170dRRSPEECHVIN / ACK MRRM169bRNICOMINDCB173bSTARTDTAPMSG 172bASSIGNCOMPL6 170aASSIGNCOMPLR172aASSIGNCOMPL6 171. MRRMASG then sends the CGI to MBSSD and asks it to determine the CO (Charging Origin) associated to the cell with signal pair CGITOORG/R. This information is forwarded to the uplink via the CB128 in the next step. Assignment Complete Parameters The Assignment Complete message (3GPP TS 48.008 Rel. 5) contains no mandatory and several optional parameters, some of which are included below: Chosen Channel - is an optional parameter that contains a description of the channel allocated to the MS on the air interface. Chosen Speech Version - indicates the speech version being used by the BSS. Always included when the speech coder version choice was done by the BSS. 172. MRRMASG informs the uplink, via MRRM, of the Assignment Complete message with signal ASSIGNCOMPL6. MRRM forwards the signal to MTB via MMM and MTBCC. This is the successful response to signal ASSIGNMENT1 from step 160 above. MRRMASG transfers the Assignment Complete message data to the uplink within the same CB128 that was used in the ASSIGNMENT1 signal to the downlink. 173. MRRMASG also sends signal STARTDTAPMSGAS to the MRRM so that DTAP messages can once again be sent if required, now that the MS is connected on a new traffic channel. MRRM in turn sends signal STARTDTAPMSG to the uplink to undo the DTAP buffering that was initiated at step 166 above. At the same time MRRM also asks MRRMH to clear the message from its buffer with signal CLEARRRMH. MRRMASG also sends signal ASGPROCEEDLCS so that MRRM may resume any ongoing location services. This signal is the counterpart to signal SUSPENDLSC at step 166 above.

Figure 35 174. When MTB receives signal ASSIGNCOMPL6, it forwards traffic channel information to MABC with forward combined signal FWDCHANNINF1. MABC returns charging information regarding assigned radio characteristics and IWF (Interworking Function) parameters in backward combined signal

FWDCHANNINF1ACK. At this point MTB releases the CB128 whose pointer was contained within signal ASSIGNCOMPL6. MTB also stops the not reachable timer that it started at step 67. 175. MTB reads the time at which the channel assignment was completed with combined signal pair TIME/ACK to block JOB60. MTB then reports a charging event to MTBCO with signal REPCHGCCC. This signal instructs MTBCO to provision charging analysis input data. 176. MTBCO begins by using destination dependent analysis, which is performed by block IA61 within the TRAM, to determine the CC (Charging Case) for the airtime charging. However, communication with this service is inter-AM MTBMABCMTBCCMCCMHMUABCMCCPHMCLMTHMTBCOMCSEMCEDHC172dASSIG NCOMPL6174FWDCHANNINF1 / ACKCLMTRMPMTBSS178bREADMMSISDN / ACK180bREADMMSISDN / ACKCHVIEWRMPStore publiccharging data 184READYFORALERTMOIPHI176bSEIZEMCLMTHR176aSEIZEMCLMTH179aCLMANAF UNC1179bCLMANAFUNCR180dCLMANUMANA180eCLMANUMANAR177a/cGETACCES S/ACK181a/cGETACCESS/ACK177bGETACCESS / ACK to MRRM181bGETACCESS / ACK to MRRM178a/cMREADMMSISDN/ ACK180a/cMREADMMSISDN/ ACK175bREPCHGCCC 182CHGANALDATA / ACK183bREPCHGCCCR183aDISCMCLMTH / RMCIWFJOB175aTIME / ACK TRAMIAIAIAIAMCLMTH 60 JOB JOB monitor JOB is an APZ block that is a part of the operative system kernel and the subsystem CPS (Central Processor Subsystem). The block handles the system calendar, time zones, supervision of program execution, processor load measurements, the administration of the time queues and the jobtable and a number of service functions related to these functions 61 IA Interface to Analysis functions IA is a TCS block within the TRAM that is used as an interface to A-number, B-number, routing and barring analysis. A user subscribes to analysis results of interest and IA then sends these results to the user. The user can also restrict the way IA is allowed to handle certain events during the analysis. and thus is done via the RMP, in particular block CLMT62. Therefore, MTBCO seizes block MCLMTH63 that will facilitate the connectionless interface with the RMP. An MCLMTH is seized with signal pair SEIZEMCLMTH/R. 177. MTBCO also fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM, MTBCC and MTB. MTBCO needs this data so that it may use the appropriate TMR (Transmission Medium Requirement) for analysis at step 179 below.

178. The analysis to determine the CC is performed on the MSISDN digits; therefore, MTBCO requests the MSISDN from MTB with combined signal pair MREADMMSISDN/ACK, which MTB reads from MTBSS with nested combined signal pair READMMSISDN/ACK. 179. MTBCO then sends signal CLMANAFUNC1 to MCLMTH, which includes the MSISDN, the BO (B-number Origin, defined on MTB route) as well as few other parameters. This signal indicates that MTBCO is interested in any CC that is encountered during analysis. Once B-number analysis is completed, the result is returned in signal CLMANAFUNCR with an indication that a CC was encountered. MTBCO stores this CC, which it will use later at charging analysis. 180. MTB then reads the MSISDN again with the same signal pair as in step 178 above, but this time for A-number analysis so that an ACO (A-Charging Origin) can be determined. This done with signal CLMANUMANA to MCLMTH, which includes the MSISDN. Once A-number analysis is completed, the result is returned in signal CLMANUMANAR with a possible ACO. 181. MTBCO once again fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM, MTBCC and MTB. MTBCO needs this data so that it may provide the appropriate parameters as input data for charging analysis in the next step. 182. MTBCO then provides the necessary charging analysis input data, such as CC and ACO, to MCEDHC with combined forward signal CHGANALDATA. MCEDHC stores this data and returns combined backward signal CHGANALDATAACK. At this point, MCEDHC writes some of this data as public charging data in CHVIEW. Public charging data is data that can be stored in a charging view by any user and is accessible to all users. This makes it possible for users to exchange some charging data between them. 183. MTBCO no longer requires the connectionless interface to TRAM since all analyses are complete. Therefore the MCLMTH individual is disconnected by means of signal pair DISCMCLMTH/R. MTBCO also returns a successful indication to MTB with signal REPCHGCCCR, indicating that charging analysis was successful. 62 CLMT ConnectionLess Message Transfer service CLMT is an RMP block that provides a connectionless message transfer service in APSI. This service allow a user in an AM to transfer messages towards a specified user. The messages are of connection less type, i.e. no logical connection (on session level) has to be established between the two users exchanging messages. 63 MCLMTH Mobile telephony ConnectionLess Message Transfer Handler MCLMTH is an MSS block that provides an interface block between users in 1/APT and TRAM for

several analysis functions in TRAM which use the connectionless message transfer service of RMP as bearer. 184. MTB then informs MTBCC with signal READYFORALERT that it is waiting for the DTAP-Alerting message before it can proceed with the call establishment. 6.3.4.11 Alerting Message Received, OIP-ACM Sent Figure 36 185. The DTAP-Alerting message is connection oriented, so its contents are provided by SCCOC in a newly allocated CB4k to MSCCO with direct signal SCDATAINDCB. Note that at this point the MMS subsystem does not yet know the message type. The message is then forwarded to MRRM with signal RNICOMINDCB. This signal contains the discrimination parameter, which indicates it is a DTAP type message. Since it is not a BSSMAP type message, MRRM forwards the message uplink to MMM, also with RNICOMINDCB but as a hurry signal. MMM reads the protocol discriminator, which indicates it is a CC (Call Control) type message hence belonging to the CM level. Therefore, MMM forwards the message uplink to MTBCC also with RNICOMINDCB as a hurry signal. MTBCC immediately forwards this same signal as a hurry signal to MCCMH for unpacking. MCCMH transfers the content of the CB4k to its own internal buffers and releases the CB4k. It then analyzes the message for any errors or missing mandatory information elements and reports that the message is approved with signal RECEIVERNMSG1. 186. The only parameter that MTBCC attempts to read within the DTAPAlerting message is the Facility parameter. MTBCC asks MCPPH, via MCCMH, to fetch the Facility information element with combined forward signal FETCHFACIE. Since no Facility parameter was received in the Alerting message, MCPPH responds with combined backward signal NOMORECOMP. If MSCCOMRRMMRRMHMMMMEC185bRNICOMINDCBSCCOCCCSBSCDTAP Alerting SCCP DT1 (Data Form 1) MTBCCMCCMHMCCPH185aSCDATAINDCB 185eRNICOMINDCB185cRNICOMINDCB185dRNICOMINDCB185fRECEIVERNMSG1186b FETCHFACIE / ACK 186a/cFETCHFACIE/ ACK 186dCLEARBUFF1 MRRMASGMALTMMRRMHO the Facility parameter had been received, then MCCMH would have forwarded it to MCPPH for validation analysis at step 185 above. Since all the necessary parameters have been read, MTBCC releases the buffered message in MCCMH

with signal CLEARBUFF1. Alerting (MS to Network) Parameters The Alerting message (3GPP TS 24.008 Rel. 5) contains no mandatory and several optional parameters. Only the parameters that MTBCC attempts to read are presented below. Facility - an optional parameter that is included for functional operation of supplementary services. The parameter is an array of octets whose interpretation is defined in specification 3GPP TS 24.080 Rel. 5 "Mobile radio layer 3 supplementary services specification, Formats and coding".

Figure 37 187. As a parallel process to the call set up, MTBCC checks if the network initiated TAI (Tariff Area Indication) is active in the MSC. This information is available in block MTBSS (DBS parameter GSMMSSF:MSCNF1157) and is accessed with combined signal pair CHCKSSINVOKE/ACK via MTB. Since the feature is active within the MSC, MTBCC reads the regional service data and IMSI that will be used for the TAI. The data is read from MTB with combined signal pair FETCHTAIDATA/ACK. MTBCC then asks block MUATAI64 with signal TAINWINDICATE to check if a network initiated TAI is required for this call. In this example, MUATAI determines that no indication is required, so this parallel process ends here. The purpose of this function is to provide the mobile subscriber with an indication about the relevant tariff area. For more information on this feature see FS Indication of Tariff Area to Mobile Subscriber in MSC/VLR server. 188. MTBCC informs MTB about the reception of the DTAP-Alerting message with signal MBSUBFREE. This signal prompts MTB to generate an ACM (Address Complete Message) backwards in the call path and inform its side links of the ACM. MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMCSEMTBCOMTBSS MCEDHC188MBSUBFREE MRRMHCharginganalysisMUATAI190SENDCALLEVENT187bCHCKSSINVOKE / ACK 191fMSTARTINBANDCOMAINRMPStartringing tone187dFETCHTAIDATA / ACK CHVIEWRMP195dGETACCESS / ACK191cGETACCESS / ACK187a/cCHCKSSINVOKE / ACK191a/eGETACCESS / ACK191b/dGETACCESS / ACK 195c/eGETACCESS/ ACK 195b/fGETACCESS/ ACK187eTAINWINDICATE193aMSGREPORT193bMSGREPORT1R194CHGANALRES / ACK

MTTEC189STOPTIMERS192MMSGBUF195a/gGETACCESS/ACK Since MTB initiates two parallel processes, the signal order in the next two steps is not maintained. 64 MUATAI Mobile telephony Ussd Application Tariff Area Indicator MUATAI is an MSS block that handles a request for TAI (Tariff Area Indication) received from MTACC/MTBCC during call setup and a request received from the USSD platform. It determines the appropriate TAI and asks the USSD platform to send the appropriate USSD text string to the MS. 189. MTB orders MTTEC to stop the timers that were started at step 54 above with signal MSTOPTTIMERS. These timers did not get a chance to time out since the call is promptly delivered to the B-subscriber. 190. MTB informs MCSE of the ACM event by sending signal SENDCALLEVENT. The signal is not acted upon by MCSE since the speech path in this example will only be established with the ANM event. MCSE uses the DBS parameter GSMMSSC:TCONTYPE to determine when to set up a two-way speech path, at the ACM or ANM event. 191. MTB also fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM and MTBCC. MTB needs this data to determine the appropriate TPI (Tone Protection Information) for this access type, GSM or UMTS. The TPI determines if tone sending is allowed for this call. The TPI for GSM access was determined as part of the analysis of bearer capabilities for GSM at step 149 above. Since tone sending is allowed, MTB orders MCSE to start the ringing tone towards the A-subscriber with signal MSTARTINBAND. This prompts MCSE to order a ringing tone via the uplink channel of the second SSV that it previously seized at step 50. 192. MTB then seizes a CB4k (Communication Buffer) and begins building the OIP-ACM message within it. The OIP-ACM message will be sent to TRAM (TRansit AM) later in the process. For now MTB passes to the message onwards to MTBCO for distribution with signal MMSGBUF. 193. MTBCO first distributes the CB4k pointer of the OIP-ACM message to MCEDHC with signal MSGREPORT, so that MCEDHC can read the necessary charging data from the OIP-ACM. MCEDHC stores and then reads public charging data to and from the charging view. MCEDHC initiates the charging analysis on the CC (Charging Case) it stored at step 182, by storing the analysis indicator as public data in the charging view. The result of the charging analysis is communicated to MCEDHC also via the public charging data analysis result. Note that MCEDHC subscribed to this public data at step 56 above. Once MCEDHC finishes with this process, MCEDHC returns signal MSGREPORT1R to MTBCO. 194. MTBCO reads the charging analysis result, the TC (Tariff Class) and CP (Charged party), from MCEDHC with combined signal pair CHGANALRES/ACK. This information was a result of the charging analysis in the previous step.

195. MTBCO again fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM, MTBCC and MTB. This time MTBCO needs this data to send the appropriate charging data to MCEDHC at step 197 below.

Figure 38 MOIPHIAPCRMPTRACOTRAM202bAPCDATACBINDOIPACMMTBMAPTCMABCMUAB CMTBCCMCCMHMCCPHMTBSSTRANMCSEMTBCO196c/eMREADMMSISDN/ACKMCE DHCCHVIEWRMP197aSENDCCCDATA(12 times) 197bSENDCCCDATAEND 202aAPCDATACBREQ197cSENDCCCDATAENDR198aMMSG198bMMSGR196dREADMM SISDN / ACK199REQAOCDATA / R201aMSENDBWDMSGMTTEC201bMBWDMSG / ACK200READYFORCONNECT203aREPORTTONEANNC203bREPORTTONEANNC 196aNODENOREQ/ ACK196bTRAGLROUTENO/ ACK Since MTB and MTBCO initiate several parallel processes, the signal order in the next five steps is not maintained. 196. MTBCO collects charging data from its side links with the following combined signal pairs. It fetches the international MSC/VLR number (own calling address, command MGCA_) with NODENOREQ/ACK to MAPTC. MTBCO then asks block TRAN to translate the outgoing global route number, acquired at step 138, into a global route name with TRAGLROUTENO/ACK. MTBCO requests the MSISDN from MTB with combined signal pair MREADMMSISDN/ACK, which MTB reads from MTBSS with nested combined signal pair READMMSISDN/ACK. This data will be sent to MCEDHC in the next step. 197. MTBCO then proceeds to send this recently collected data as well as other data to MCEDHC with a series of SENDCCCDATA signals. In this example, the signal was sent 14 times with data such as the MSC/VLR number, BASC, IMSI, MSISDN, time of seizure, CGI, RF power class, AOC, global route name and more. Once finished sending information, MTB sends signal SENDCCCDATAEND and MCEDHC replies with signal SENDCCCDATAENDR. 198. MTBCO then distributes the OIP-ACM message back to MTB with signal MMSG. MTB immediately returns control of the message to MTBCO for further distribution with signal MMSGR before performing a few actions. 199. The previous step prompts MTB to request the AOC information with signal REQAOCDATA. In this example, MTBSS responds with REQAOCDATAR indication AOC is not active. If AOC were active, then MTBSS would interact with

several blocks to determine the various elements of AOC. For more information on this feature see FS Advice of Charge in MSC/VLR Server.

200. MTB also sends the READYFORCONNECT signal to MTBCC informing it that it is now ready to receive the connect indication. Since the Connect message has not yet been received, MTBCC notes this fact and exits. 201. After receiving signal MMSGR from MTB (step 198), MTBCO determines that there are no more blocks to distribute the message to. Therefore MTBCO sends the OIP-ACM message to MOIPHI with signal MSENDBWDMSG. MOIPHI informs its side link MTTEC of the OIP-ACM message with forward combined signal MBWDMSG. MTTEC decides whether or not to buffer the message based on whether or not it is waiting for a continuity check message. In this example, MTTEC indicates that the OIP-ACM message can be sent to MOIPHI in backward combined signal MBWDMSGACK. 202. MOIPHI sends the OIP-ACM message via the APC session with signal APCDATACBREQ specifying the message type, CB4k and session ID. APC simply transits this data to the TRACO individual within the TRAM with signal APCDATACBIND. The TRAM analyzes the OIP-ACM and if successful propagates it backwards through the call chain. The OIP-ACM and any equivalent message in other protocols, such as an ISUP ACM, inform the incoming call chain that the Bsubscriber was successfully identified and that ringing has started, thus through connection is required. 203. At step 191 above, MTB initiated the start of the ringing tone. Once the tone is started, MCSE replies back to MTB with signal REPORTTONEANNC, which MTB transits to MTBCO. MTBCO only acts on this signal when the subscriber is being monitored. The reason this signal is returned much later is because it involves communicating with hardware, thus implying an independent processor. In this example, signal REPORTTONEANNC entered MTB at this point but it is important to note that it could have entered sooner or later depending on the nature of the hardware interaction. 6.3.4.12 Connect Message Received, OIP-ANM Sent Figure 39 204. The DTAP-Connect message is connection oriented, so its contents are provided by SCCOC in a newly allocated CB4k to MSCCO with direct signal SCDATAINDCB. The message is then forwarded to MRRM with signal RNICOMINDCB. This signal contains the discrimination parameter, which indicates it is a DTAP type message. Since it is not a BSSMAP type message, MRRM forwards the message uplink to MMM, also with RNICOMINDCB but as a

hurry signal. MMM reads the protocol discriminator, which indicates it is a CC (Call Control) type message hence belonging to the CM level. Therefore, MMM forwards the message uplink to MTBCC also with RNICOMINDCB as a hurry signal. MTBCC immediately forward this same signal as a hurry signal to MCCMH for unpacking. MCCMH transfers the content of the CB4k to its own internal buffers and releases the CB4k. It then analyzes the message for any errors or missing mandatory information elements and reports that the message is approved with signal RECEIVERNMSG1. 205. MTBCC attempts to read two optional parameters within the DTAPConnect message even though no parameters were received in this example. It first requests the Connected Subaddress with combined signal FETCHIE/CONSUBADIND1. MTBCC asks MCPPH, via MCCMH, to fetch the Facility information element with combined forward signal FETCHFACIE. Since no Facility parameter was received in the Connect message, MCPPH responds with combined backward signal NOMORECOMP. If the Facility parameter had been received, then MCCMH would have forwarded it to MCPPH for validation analysis at step 204 above. Since all the necessary parameters have been read, MTBCC releases the buffered message in MCCMH with signal CLEARBUFF1. MSCCOMRRMMRRMHMMMMEC204bRNICOMINDCBSCCOCCCSBSCDTAP Connect SCCP DT1 (Data Form 1) MTBCCMCCMHMCCPH204aSCDATAINDCB204eRNICOMINDCB206MBANSWER204cRN ICOMINDCB204dRNICOMINDCB204fRECEIVERNMSG1205cFETCHFACIE / ACK 205aFETCHIE / CONSUBADIND1205eCLEARBUFF1205b/dFETCHFACIE/ ACK MRRMASGMALTMMRRMHO Connect (MS to Network) Parameters The Connect message (3GPP TS 24.008 Rel. 5) is sent by the called mobile station to the network to indicate call acceptance by the called user. The Connect message contains no mandatory and several optional parameters. Only the parameters that MTBCC attempts to read are presented below. Connected Subaddress - an optional parameter whose purpose is to identify a subaddress associated with the connected party of a call. Facility - an optional parameter that is included for functional operation of supplementary services. The parameter is an array of octets whose interpretation is defined in specification 3GPP TS 24.080 Rel. 5 "Mobile radio layer 3 supplementary services specification, Formats and coding". 206. MTBCC informs MTB of the connect/B-answer indication with signal MBANSWER. Now that that the call has been answered, MTB finally releases the OIP-IAM CB4k, received at step 29. MTB holds on to the OIP-IAM CB4k since

it is required in case of call forwarding. Now that the call is answered, the possibility of call forwarding is no longer an option.

Figure 40 MMMMECMTBMABCMTBCCMCCMHMUABCMCCPHMRRMMCSEMTBCOMTBSS206M BANSWER211SENDCALLEVENTMRRMH210MSTOPINBANDCOMAINRMPStopringing tone207cGETACCESS / ACKbothwayconnection207a/eGETACCESS / ACK207b/dGETACCESS / ACKMCEDHCLog allchargingdataCHVIEWRMP212aMSGREPORT212bMSGREPORT1R213aMMSG213bMMSG R209MMSGBUF208READMMSISDN / ACK Since MTB initiates several parallel processes, the signal order in the next five steps is not maintained. MTB seizes a CB4k (Communication Buffer) and begins building the OIP-ANM message within it. The OIP-ANM message will be sent to TRAM (TRansit AM) later in the process. 207. Once again MTB fetches the current access type (GSM or UMTS) from MRRM with combined signal pair GETACCESS/ACK via MMM and MTBCC. This time MTB needs this data to determine the appropriate propagation delay parameter in the OIP-ANM message. The propagation delay is different between GSM and UMTS. 208. MTB requests the MSISDN from MTBSS with combined signal pair READMMSISDN/ACK. The MSISDN is included in the OIP-ANM message to support the SDLDC (Supervision and Disconnection of Long Duration Call) feature. See FS Time Supervision and Disconnection of Long Duration Call for information on this feature. 209. MTB has finished building the OIP-ANM message and thus passes it to MTBCO for distribution with signal MMSGBUF. 210. Since the call was answered, MTB orders MCSE to stop the ringing tone towards the A-subscriber with signal MSTOPINBAND. MCSE then orders a stop to the ringing tone via the RMP through the same SSV used to start the ringing tone at step 191.

211. MTB then informs MCSE of the B-answer reception by sending signal SENDCALLEVENT with the event data set to ANM (ANswer Message). At this point, MCSE changes the second SSV it seized at step 50 to a two-way speech connection. The speech path is established at the ANM event and not at the ACM event because of DBS parameter TCONTYPE, see step 190 for more details.

212. MTBCO first distributes the CB4k pointer of the OIP-ANM message to MCEDHC with signal MSGREPORT, so that MCEDHC can read the necessary charging data from it. This prompts MCEDHC to log all the data it has collected thus far into the charging view. Once MCEDHC finishes with this process, MCEDHC returns signal MSGREPORT1R to MTBCO. 213. MTBCO then distributes the OIP-ANM message back to MTB with signal MMSG. MTB immediately returns control of the message to MTBCO for further distribution with signal MMSGR before performing a few actions.

Figure 41 MOIPHIAPCRMPTRACOTRAM218cAPCDATACBINDOIPANM218bAPCDATACBREQMT BMCSEMABCMUABCMTBCCMCCMHMCCPH214aSENDCALLEVENTMTBSS218aMSEN DBWDMSGCEDHC216MCONNECTMSMCIWF214bSENDCALLEVENT215aALTEVENT1M TBCO217aCCSUPERVISIONMTV217bALLOWDISC / ACKMTTEC Once again since MTB initiates several parallel processes, the signal order in the next few steps is not maintained. 214. The previous step prompts MTB to inform MCIWF via MCSE of the call supervision event also with signal SENDCALLEVENT. MCIWF ignores this signal since no IWF is seized for this call. 215. MTB also sends signal ALTEVENT1 to the downlink in order to inform the MALT device that the call has been answered. Upon receiving this signal the MALTM individual marks the B-answer for seizure supervision purposes and increments B-answer route counters. 216. MTB orders the sending of the DTAP-Connect Acknowledge message with signal MCONNECTMS to MTBCC. 217. MTB informs MTBSS with signal CCSUPERVISION that the CC-layer has reached call supervision state. MTBSS sends combined signal pair ALLOWDISC/ACK to MTV in order to remove the prevent disconnection indication in MTV which it set at step 31 above. 218. After receiving signal MMSGR from MTB (step 213), MTBCO determines that there are no more blocks to distribute the message to. Therefore MTBCO sends the OIP-ANM message to MOIPHI with signal MSENDBWDMSG. MOIPHI sends the OIP-ANM message via the APC session with signal APCDATACBREQ specifying the message type, CB4k and session ID. APC simply transits this data to the TRACO individual within the TRAM with signal APCDATACBIND. The TRAM analyzes the OIP-ANM and if successful propagates it backwards through the call chain. The OIP-ANM and any equivalent message in other

protocols, such as an ISUP ANM, inform the incoming call chain that the Bsubscriber answered the call. Figure 42 219. MTBCC sends signal SENDRNMSG1 to order MCCMH to pack the DTAP-Connect Acknowledge message and send it to the MS via the SCCP connection on the A-interface. MCCMH allocates a CB4k and writes the DTAPConnect Acknowledge message into it. MCCMH sends the message to MTBCC with signal RNOCOMREQCB. MTBCC, MMM and MRRM forward this signal downlink to MSCCO as a hurry signal. MSCCO forwards this message to SCCOC with combined signal pair SCDATAREQCB/ACK. SCCOC along with other CCS blocks then ensure that the Connect Acknowledge message is sent to the BSC over the SCCP connection. SCCOC also releases the CB4k allocated by MCCMH above MSCCOMRRMMRRMHMMMMECSCCOCCCSBSCDTAP Connect AcknowledgeSCCP DT1 (Data Form 1) MTBCCMCCMHMCCPH219fSCDATAREQCB / ACK 215bALTEVENT1215cALTEVENT1215dALTEVENT1 219aSENDRNMSG1219bRNOCOMREQCB 219cRNOCOMREQCB219dRNOCOMREQCB219eRNOCOMREQCB216MCONNECTMSMR RMASGMALTM215eALTEVENT1MRRMHO Connect Acknowledge (Network to MS) The Connect Acknowledge message (3GPP TS 24.008 Rel. 5) is sent by the network to the called mobile station to indicate that the mobile station has been awarded the call. The Connect Acknowledge message contains no parameters. 6.3.4.13 Mobile Terminated Call Path MRRMMSCCOSCCOCMRRMHCCSBSCMMMMTBCCMCCMHMCPPHMTVMECMCSEMC IWFMALTMMRRMASGMRRMHOMTBMABCMUABCMTBSSMobileTerminatedCall PathMTBCOMCEDHCMOIPHIAPCRMPMTTEC