132
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

Gsm Call Path Course

Embed Size (px)

DESCRIPTION

Uploaded from Google Docs

Citation preview

Page 1: Gsm Call Path Course

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

Page 2: Gsm Call Path Course

● CALL DELIVERY, VMSC

● Definition of VMSC

The VMSC (Visited Mobile Switching Center) is the MSC within a mobile calldelivery scenario where an MS (Mobile Station) receives a call, i.e. where theterminating mobile call path is set up.

The VMSC is the MSC where the MS last registered and is pointed to by thesubscriber location within the HLR at call delivery.

The VMSC is also known as the MSC/VLR; hence these two terms will be usedinterchangeably 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 anOIP-IAM (Initial Address Message) message and the B- number analysisassociated to this message leads to the seizure of a GRI (Gmsc RoamingInterrogation) route. The OIP-IAM is sent to TRAM by its incoming side, whichcan be an ISUP trunk, an originating mobile or any device/subsystem that caninitiate a call process. In the case of a trunk, the call (most probably) originated inanother 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 NumberMAPE.Send Routing Information Ack.MAPF.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)

Page 3: Gsm Call Path Course

ISUP (or OIP or other protocol)MAPB.Send Routing InformationMAPD.Provide Roaming Num Ack

potential incoming side to the TRAM, as well as any previous node involved inthis call.B. Using the MSISDN (dialled digits), the GMSC contacts the HLR forinformation about the subscriber being called in order to determine how to routethe call. The GMSC sends a MAP-SRI (Send Routing Information) message tothe HLR for this purpose. The assumption in this example is that the MS is in idlestate and ‘IMSI attached’ to a VMSC (MSC/VLR) and thus the location in theHLR is set.C. Upon reception of the MAP-SRI message, the HLR uses the MSISDN withinthe message to find the subscriber profile within its database. The HLR profilecontains all the relevant subscriber data. After a list of checks to determine ifcertain features that need to be triggered prior to call delivery are applicable, theHLR sends a MAP-PRN (Provide Roaming Number) to the VMSC pointed to bythe location data within the subscriber profile.D. Upon receiving the MAP-PRN message, the VMSC (MSC/VLR) assigns anMSRN (Mobile Station Roaming Number) to this call. The MSRN temporarilyrepresents the called subscriber within the VMSC and thus will allow the call tobe routed from the GMSC to the VMSC. Note that the GMSC and VMSC parts ofa call delivery scenario can be located within the same node. The VMSC returnsthe 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-Ackmessage.F. The GMSC then seizes a new TRAM on its outgoing side and sends it anOIP-IAM with the MSRN as the dialled digits. Analysis of this OIP-IAM within theTRAM should lead to either an outgoing trunk route or to a mobile termination ifthe GMSC and VMSC are within the same MSC. Note the OUT in figure 1 aboverepresents the TRAM and any potential outgoing side to the TRAM, as well asany transit node that may exists between the GMSC and VMSC for this call. Ifthe 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 subsequentsignalling, 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, anACM (Address Complete Message) type message is expected to make its wayback through the call chain. Eventually the GMSC receives an ACM typemessage.H. Upon receiving the ACM type message, the GMSC stores certain data foundwithin 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 thecall chain. Eventually the GMSC receives an ANM type message.

Page 4: Gsm Call Path Course

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 toan idle MS.

● Assumptions

While there could be several reasons for a terminating call process to fail in theVMSC, this example assumes that all goes well. Some of these failure reasonsare mentioned at the appropriate points in the process, but the details are nevershown for it is assumed that the process proceeds successfully.

There are several features and services that can be triggered during a calldelivery process. Some of the trigger points for these features and services arementioned at the appropriate points in the process but most details are notshown for it is assumed the most features or services are not applicable to thiscall scenario.

In the example below, it is assumed that the MS (Mobile Station) already has aVLR record in the VMSC at the time of the call delivery. This is obviously themost common scenario for a terminating call and implies the mobile haspreviously 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. Thisprocess takes place in an ANSI signalling environment. In other signallingenvironments (ITU, MPT, TTC, etc.) the TCCSE interface would be a littledifferent.

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 theVMSC.

● Steps for the MAP signalling phase in the VMSC

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

Page 5: Gsm Call Path Course

Capabilities application part SErvice) initiates a session with the appropriate TC-user for the MAP-PRN message.

The main steps in the process are numbered in all the figures and correspond tothe written explanations. Note that most but not all of the signals involved in theprocess 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 notpresented 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 sessionwith a TC-user, which it identifies (via the SSN (SubSystem Number) asMAPTC1. Block C7TCP2 sends G7BEGININD to MAPTC requesting the seizureof 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 andcalling 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 TCAPmessage.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 calledaddress for the return message (i.e. HLR address) so that both addresses havethe same nature in the return message. This is accomplished with combinedsignal pair G7CHANGEADDR/ACK.

MAPTCCCSC7TCPHLRMRNAP1G7BEGININD2G7CHANGEADDR / ACK3C7DPINFCBREQ / ACK4C7DIALCBINDR6aMDIALSEIZREQ6eMDIALGRANTED5C7INVOKECBINDMSNANMTV7bMINVOKECBINDMAP –Provide Roaming NumberTCAP –Begin & Invoke & Dial.Req.SCCP –UDT (Connectionless)MABCMUABC7aC7CHTCUREF / ACK8C7OPCBINDR9aFORWARDPLMNBC9bFORWARDPLMNBCMTECA10cMPRNTSA / ACK10bABCPRN11aIDENTIFYSUB12bIDENTIFYSUBR11bIDENTIFYMS / ACK12aPREVENTDISC / ACK6b/dSEIZEMABC / ACK6cSEIZEMUABC / ACKMAPTC10aCONTINUEB1 MAPTC - Mobile telephony Application Part incoming Transaction Coordinator

Page 6: Gsm Call Path Course

MAPTC is an MDS block that contains functions for the following: setup of incoming dialogues forMobile Application Part (MAP) operations, management of the international and national own callingaddresses for MAP in the MSC/VLR, initiation of policing for MAP operations received in theMSC/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. Ittakes all the decisions that are related to the TC protocol. It handles the complete interface to boththe TC-user and the SCCP layer.

3 MAPTC asks C7TCP to send information from the dialogue portion of theTCAP message with forward combined signal C7DPINFCBREQ. MAPTC isinterested in the ACN (Application Context Name). C7TCP provides the CB512(Communication Buffer - 512bytes) pointer within which the ACN is located withbackward combined signal C7DPINFCBREQACK. MAPTC reads the ACN, whichlater will be used at step 5 to determine the signalling user in the VMSC for thismessage.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 areturn signal to G7BEGININD at step 1 above. The C7DIALCBINDR signalreturns control of the CB512 back to C7TCP and also informs TCCSE that the TC-user (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 dialogueportion of a TCAP message.5. MAPTC then receives the component portion of the message in signalC7INVOKECBIND. As the signal name implies, it is an “invoke” component typemessage. This signal provides the CB512 pointer (same as in previous step) ofwhere the message is stored. MAPTC first reads the MOPCODE (MobileOPeration CODE, number specifying MAP message type) and then uses thisMOPCODE and the ACN acquired at step 3 to determine the VMSC signallinguser for this message, MRNAP3.6. MAPTC orders the seizure on an internal dialogue (i.e. a link) to MRNAP withsignal MDIALSEIZREQ. The MRNAP block seizes one of its own individuals andthen immediately seizes an MABC4 individual as a side link with combined signalpair SEIZEMABC/ACK. MABC in turns uses nested combined signal pairSEIZEMUABC/ACK to seize its corresponding MUABC5 individual. Note theMABC and MUABC individuals share the same pointer, hence the same file size.MRNAP responds to MAPTC with its pointer in signal MDIALGRANTED. Onceagain the term dialogue here is not to be confused with the dialogue portion of aTCAP message.

Page 7: Gsm Call Path Course

MAPTC has identified and seized the appropriate signalling user block for thismessage. From this point onwards MAPTC is no longer required. MAPTC will linkout, thus making MRNAP the TC-user.

7. MAPTC asks the TCCSE to change link to MRNAP with combined signal pairC7CHTCUREF/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/VLRis called.

4 MABC - Mobile telephony Analysis of Bearer Capabilities (GSM)

MABC is an MSS (Mobile Switching Subsystem) block that is responsible for the PLMN BearerCapability and Basic Service Code handling in the MSC/VLR. MABC includes the radio channelparameter 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 capabilityhandling and basic service code handling in the MSC/VLR server for UMTS calls.

TC-user. MAPTC forwards the CB512 pointer that contains the component portionof the TCAP message to MRNAP with signal MINVOKECBIND. After sendingthis signal, MAPTC drops off to idle.8. MRNAP locally stores all the parameters found within the CB512. MRNAPthen acknowledges signal C7INVOKECBIND with signal C7OPCBINDR directlyto C7TCP, indicating that the complete TCAP message and its associated CB512can now be released.9. MRNAP validates the parameters received to ensure that they are in thecorrect format. This process can be lengthy and thus may require phase divisionwith CONTINUEB signals. In this example the GSM/PLMN BC (BearerCapability) parameter is received, which MRNAP sends to MABC and thenonwards 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

Page 8: Gsm Call Path Course

Capabilities) between the MSC/VLR and the MS. During this process theMSC/VLR determines the final values of certain PLMN bearer capabilityparameters taking into account the MS’s capabilities and preferences (e.g.classmark) and the MSCs capabilities. The analysis of bearer capabilities alsoinvolves the determination of the BASC (BAsic Service Code, either a teleserviceor bearer service) that is checked against the subscribed BASCs.

10. After sending itself the final CONTINUEB signal, MRNAP initiates the earlyanalysis of the bearer capabilities received in the MAP-PRN message by sendingsignal 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 caseturns out to be teleservice ‘telephony’. MABC then asks MTECA6 to analyzetelecommunication services based on the BASC with combined signal pairMPRNTSA/ACK. MTECA determines whether the telecommunication servicerequested by the MS is available in the system.11. MABC orders the identification of the subscriber with signal IDENTIFYSUB toMRNAP. MRNAP then uses the mandatory parameter IMSI received in the MAP-PRN message to identify the VLR record with combined signal pairIDENTIFYMS/ACK to block MSNAN7. MSNAN performs mobile digit analysis onthe 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 andmulti-slot services, stores the TSA related data and performs compatibility check for mobileterminating 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 internaladdress 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 MTV’sfunctions 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 subscribersfrom the VLR and marking the state of the subscriber to detach/attach.

Page 9: Gsm Call Path Course

If the VLR is not found, then a new VLR is seized and the subscriber profile isfetched from the HLR before proceeding.

12. MRNAP uses combined signal pair PREVENTDISC/ACK to remove MTVfrom the suitable list and thus ensure the MTV will not be disconnected duringthis process. An MTV may be disconnected and used by another MS when notenough MTV records exist within the VLR, a process known as recycling.MRNAP replies to MABC with signal IDENTIFYSUBR containing the MTVpointer.

MAP-PRN (Provide Roaming Number) Parameters

The MAP-PRN message (3GPP TS 29.002 Rel. 5) contains several mandatoryand many conditional parameters. Only the parameters that are mentioned in thisexample are presented below.

• IMSI - is the International Mobile Station Identity, a number that uniquelyidentifies a subscriber within the PLMN network. IMSI is a mandatoryparameter.• VMSC Number - this mandatory parameter is the ISDN number assigned tothe MSC currently serving the MS. The MSC number is stored in the HLR asprovided at location updating. The Ericsson MSC/VLR ignores thisparameter.• MSISDN - it is the Mobile Subscriber ISDN number assigned to the calledsubscriber.• LMSI - the Local MS Identity parameter refers to a local identity allocated bythe MSC/VLR to a given subscriber for internal management of data in theMSC/VLR. The Ericsson MSC/VLR does not use this parameter and thus theLMSI will never exist for a MS roaming within an Ericsson MSC/VLR.• GSM Bearer Capability - this optional parameter whose purpose is todescribe a bearer service. The GSM Bearer Capability information element isused for compatibility checking.• Call Reference Number - this parameter refers to a call reference numberallocated by a call control MSC, described after step 18 below as the NCRnumber. This parameter is obtained from the GMSC in the MAP-SRImessage.• GMSC Address - this conditional parameter refers to the E.164 address of aGMSC.• OR Not Supported in GMSC - this optional parameter indicates that theGMSC does not support the OR (Optimal Routing) functionality.• Supported Camel Phase in interrogating node - this optional IE lists thesupported CAMEL phases in the GMSC. This parameter is obtained from theGMSC in the MAP-SRI message.• Calling Party Number and Category - the sending of this private parameter in

Page 10: Gsm Call Path Course

the protocol extension area is an Ericsson proprietary service; see FSs

(Function Specifications) “Protocol Specification for Sending of Calling PartyNumber and Category in GMSC” and “Sending of Calling Party Number andCategory to HLR at Mobile Terminating Call in GMSC” for more details.

13. MABC proceeds with the analysis of the bearer capabilities by doing asubscription check. MABC fetches the MS’s subscribed BASC list. This isaccomplished 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 andteleservices that the MS is subscribed to. MABC performs a subscription checkto determine if the MS is subscribed to the BASC required for this call. MABCreturns the final result of analysis of bearer capabilities in signal ABCPRNR toMRNAP. This is the return signal to ABCPRN at step 10.

CCSC7TCPHLRMRNAPMTVMABCMUABC13fABCPRNRMTVS15aZCFRRCHK15bFETCHZCDATA / ACK15cZCFRRCHKR13cCHKSUBSCRBSG/ ACK13b/dSUBSCRANA/ ACK14bFETCHSSALL/ ACK14a/cREADMTVDA1 / ACK13a/eFETCHSUBSCR/ ACKMZONEMZONENote that for simplicity purposes the side links to MTV, such as MTVS, are onlyshown in the figures when information from these side links is accessed.

14. MRNAP reads more subscriber data from MTV with combined signal pairREADMTVDA1/ACK in order to check if the MS is attached or detached. Ifdetached, 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 thevisiting 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 fetchessome of required data from MTVS with nested combined signal pairFETCHSSALLACK. MRNAP stores the MSISDN and the various roamingrestriction features information received in READMTVDA1ACK.

Page 11: Gsm Call Path Course

15. If the MS is attached and has no roaming restrictions and if any of theregional services (local subscription, regional subscription and subscription withtariff areas) are supported in the MSC, MRNAP orders MZONE10 to checkroaming restrictions due to regional services with signal ZCFRRCHK. MZONEdedicates an individual to this task. This individual then fetches the zone code setfrom the MTV with combined signal pair FETCHZCDATA/ACK. The VLR zonecode data is stored in block MTVZONE11; however in this example, since theMTV individual has no link to MTVZONE, it knows there is no zone code dataand indicates this to MRNAP with signal ZCFRRCHKR. As a result, the processsuccessfully proceeds. See FSs (Function Specifications) “Local Subscription inMSC/VLR Server”, “Regional Subscription in MSC/VLR Server”, “Subscriptionwith Tariff Areas in MSC/VLR Server” and “Regional Services in HLR” for moredetails 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 regionalservices data.

11 MTVZONE - Mobile Telephony Visiting ZONE code

MTVZONE is an MDS block that is used to store, retrieve, write and delete zone codes andassociated data for a mobile subscriber.

● Assignment of an MSRN

16. Before roaming number allocation, MRNAP fetches the subscriber’s LA(Location Area) pointer with combined signal RMMDATA1/ACK. It thendetermines if the subscriber is idle or busy with combined signal pairREADCMSTATUS/ACK. Note in this example, it is assumed the subscriber isidle. If the subscriber is busy, then MRNAP reads the CGI (Cell Global Identity) inorder to determine the subscriber’s LA.17. MRNAP requests a roaming number from block MRNR12 with signalREQMSRN3, which includes the IMSI, LA and other parameters. MRNR thenattempts to convert the LA into a LATA (Local Access Transport Area) withcombined signal pair LOCTOLATA/ACK to block MBSSD13. MRNR assigns anMSRN (Mobile Station Roaming Number) record based on the MSRN allocationmethod defined (MT exchange property MSRNHOMETHOD) and whether or not

CCSC7TCPHLRMRNAPMTVMABCMUABCMRNR17aREQMSNR317cREQMSRNRMBSSD17bLOCTOLATA / ACK16aRMMDATA1 / ACK16bREADCMSTATUS / ACK18aSTOREHLRDATA4 / ACK18bSTOREHLRDATA5 / ACK19ALLOWDISC / ACK

Page 12: Gsm Call Path Course

12 MRNR – Mobile Telephony Roaming Number Routing

MRNR is an MDS block that holds the roaming number series and provides roaming numbers forrouting of terminating calls from GMSC Server and handover numbers for routing handover calls fromanchor-MSC. In case of an incoming call from the GMSC the MSRN is passed to subsystem MSS. Incase 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 otherconversions such as cells to LAs. MBSSD also stores LNs (Location Numbers), ERNs (EmergencyRouting Numbers) and E911M (Enhanced 911 Mechanism) data.

the LATA is known. MT exchange property MSRNHOMETHOD determineswhether the allocation of numbers for roaming and handover are from the sameor from different pool of numbers. The IMSI is stored within the MSRN record andthe MSRN number is sent to MRNAP in return signal REQMSRNR. Therelationship between the MSRN and the IMSI is a time supervised relationshipthat lasts until the call is delivered to the VMSC or time out. The length of thetimer is also an MT exchange property, MSRNTCNTIME.18. MRNAP transfers data to MRNR which was received from the HLR in theMAP-PRN message to be stored for future use. This data is stored in the MSRNrecord because it is call specific data that will be used when the call is deliveredto the VMSC. MRNAP uses combined signal pair STORHLRDATA4/ACK to storethe GSM/PLMN BC and combined signal pair STORHLRDATA5/ACK to store theNCR (Network Call Reference) number, the OR Not Supported in GMSCindication, the Supported Camel Phase in interrogating node and the GMSCaddress. Note that other signals with data would also be sent if other parameterswere received in the MAP-PRN message.

NCR (Network Call Reference)

The NCR number, referred to as the CRN (Call Reference Number) parameter inthe specification, provides a mechanism for the post-processing system to linktogether different call data records produced for a call or, when multi partysupplementary service invokes several related calls within a node. As an option,call data records produced in different nodes for the same call can contain thesame NCR, if the signalling transfers the NCR between different nodes.

Page 13: Gsm Call Path Course

19. MRNAP is ready to reply to the HLR but first disconnects itself from the MTVrecord. MRNAP sends combined signal pair ALLOWDISC/ACK to MTV in orderto remove the prevent disconnection indication in MTV which it set at step 12above.

● MAP-PRN-Ack Message Sent

At this point, MRNAP needs to build the MAP-PRN-Ack message and send itback towards the HLR in which it will include the MSRN.

CCSHLRMRNR20aC7DIPORTREQ20bC7DIPORTREQACC21aC7RESULTREQ21bC7RESULTREQACC22aC7ENDREQ22bC7ENDREQEXEC23aDISCMABC23bDISCMUABC23cDISCMUABCR23dDISCMABCRMAP –Provide Roaming Number AckTCAP -End & Result & DialogueResp.SCCP –UDT (Connectionless)MABCMABCMUABCMUABCC7TCPC7TCPMRNAPMRNAP20. MRNAP then asks that an ACN (Application Context Name) be sent in thedialogue portion of the TCAP message with signal C7DIPORTREQ. C7TCPreplies with C7DIPORTREQACC providing a DB (Dynamic Buffer) addresswhere MRNAP can store the ACN (Application Context Name). By returning tothe HLR the same ACN that was received, the VMSC indicates to the HLR thatthe dialogue (e.g. MAP version) has been accepted.

Note the TCCSE uses its own DBs (Dynamic Buffers) in which it builds orreceives messages. It then asks the TC-users (e.g. MRNAP) to read or writeinformation directly into or from the DB, thus saving PLEX signalling.

21. MRNAP then requests that a component portion be included in the TCAPmessage with signal C7RESULTREQ. As the signal name implies, it is a requestfor an “RR (Return Result)” component type message. C7TCP prepares thecomponent portion and provides MRNAP with the DB address of where to storethe MAP-PRN-Ack message in signal C7RESULTREQACC. MRNAP then storesthe MOPCODE of the MAP-PRN-Ack message and the only parameter for themessage, the MSRN.

22. MRNAP then orders the sending of the TCAP message with signalC7ENDREQ. This signal specifies that the transaction portion have an “end”message type, which is always the case for the last message of a structuredTCAP interaction. C7TCP confirms the sending of the message to the SCCP

Page 14: Gsm Call Path Course

layer with signal C7ENDREQEXEC. At this point the C7TCP individual returns toidle.23. MRNAP releases its link to MABC with signal pair DISCMABC/R. Uponreceiving this release indication, MABC sends a nested signal pairDISCMUABC/R to MUABC. The MABC, MUABC and MRNAP individuals allreturn to their respective idle lists.

The signalling part of the call delivery process in the VMSC is now complete. Allindividuals in the VMSC that participated in the first part of the processes havereturned 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 wasprior 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 routethe call from the GMSC to the VMSC and also used to identify the calledsubscriber 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 theA-interface for a normal speech call to an MS. However, there are othersmessages that can optionally be sent during a call setup but are not shownbelow.

Note that some of the signalling sequences can occur in parallel and thus somemessages 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, whileinformation flow on the speech path is shown with dashed lines.

Figure 6A. Upon reception of an IAM type message, the MSC/VLR uses the MSRN toidentify the called subscriber by finding its VLR. The MSC then sends theBSSMAP-Paging Request (IMSI, TMSI, Cell Identity List) message to each BSSwithin the paging scope. Each BSS sends the page out on the air interface via aCCCH (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 pagerequest. The BSS assigns a DCCH (Dedicated Control CHannel) to the MS. The

Page 15: Gsm Call Path Course

MS then sends the RR –Paging Response (IMSI or TMSI) message over the airinterface 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 BSSMAP-CL3I (Complete Layer 3 Information) message and sends this message within anSCCP-CR (Connection Request) message.

C. The MSC confirms the SCCP connection request to the BSS with an SCCP-CC (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 MSresponds with a DTAP-Authentication Response (SRES) message. If the SRES(Signed RESponse) matches the one received from the HLR/AUC, then theauthentication is considered successful and the call proceeds.E. If the ciphering feature is active in the MSC and it is applicable to the callscenario, then the MSC sends the BSSMAP-Cipher Mode Command message tothe BSS. The BSS then establishes ciphering with the MS via air interfacemessaging and then returns the BSSMAP-Cipher Mode Complete message tothe MSC.F. If TMSI allocation is active in the MSC and a new TMSI needs to be assignedto 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 witha DTAP-TMSI Reallocation Complete message.

Page 16: Gsm Call Path Course

Figure 7G. 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 incomingcall request.I. The MSC proceeds with the assignment of a traffic channel by sending theBSSMAP-Assignment Request (CIC) message to the BSS. This messagecontains the CIC (Circuit Identity Code) in order to identify the trunk device to beused on the A-interface. Once the BSS sets up appropriate traffic channel on theair interface and seizes the required trunk resources on the A-interface, it sendsthe BSSMAP-Assignment Complete message to the MSC.J. After channel assignment, the called MS is ready for speech and startsalerting. Thus the MS sends a DTAP-Alerting message to the MSC informing itthat it is ringing. Since the B-MS is available and ringing, the MSC/VLR sends anACM type message to its incoming side. This ACM message works its way backthrough 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 ANMmessage works its way back through the call chain informing previous nodes thatthe B-subscriber has answered the call. The MSC acknowledges the reception ofthe 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 A-subscriber and B-MS are in full two-way conversation.

6.3.4 Steps for the call set up in the VMSC

Page 17: Gsm Call Path Course

The call set up part of the call delivery process in the VMSC begins when theTRAM (TRansit AM) performs B-digit analysis and it results in an MTE (MobileTErmination). For an MTE, TRAM identifies the outgoing EP (End Point) as beingblock MOIPHI14. Therefore, the TRAM initiates the establishment of an APC (AMProtocol Carrier) session to MOIPHI.

The main steps in the process are numbered in all the figures and correspond tothe written explanations. Note that most but not all of the signals involved in theprocess 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 notpresented in the exact order.

MOIPHIAPCRMPTRACOTRAM24cAPCCONNRESP24bAPCCONNIND24dAPCCONNCONFTRAM analyses detain IAM, determines outgoing EP andseize an APC link to outgoing side24aAPCCONNREQ1OIPIAM25aAPCDATACBREQ25bAPCDATACBINDMTBMRNR26MINCCONNECTOIPIAM28aPRNLADATA28bPRNDATAINFO28cPRNDATAEND1MTBCO27INITIATEMTC / ACK27aSEIZEMTB1 / ACKMRNR27cMINCCONNECTR6.3.4.1 OIP-IAM Received and Initiation of Call Path

Figure 824. Once the TRAM has identified the outgoing EP (End Point) as being MOIPHI,it asks the APCSE (Am Protocol Carrier Service) within the RMP (ResourceModule Platform) to open a session on the static APC link between itself andMOIPHI. TRAM knows the EPID (EP IDentity) of MOIPHI because a static APClink between them was previously established with command ARLII. BlockTRACO15 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 allowscommunication via the OIP (Open Intra Node Protocol) to the Transit Application Module (TRAM) incase of an incoming call.

15 TRACO – TRansit Am COordinator

Page 18: Gsm Call Path Course

APCCONNREQ1 specifying the EPID to the RMP. Block APC16 within the RMPreceives this signal and assigns a session ID that it sends to the terminatinguser, MOIPHI, with signal APCCONNIND. If MOIPHI accepts the session, itassigns an individual and returns signal APCCONNRESP to APC. APC thenreturns signal APCCONNCONF, which includes the session ID, to TRACOconfirming the session establishment.25. After seizing its own SSV (Switching Switch View) and joining it to the SV ofits incoming EP and then possibly seizing a charging view, the TRAM forwardsthe OIP-IAM message to its outgoing EP via the APC session with signalAPCDATACBREQ. MOIPHI receives the OIP-IAM with signal APCDATACBIND.26. Since the MOIPHI block can be used as the TRAM interface for severalmobile routes as well as for a mobile terminating call, MOIPHI reads the mobilepointer (MRNR pointer for MSRN series) in the OIP-IAM CB4k (CommunicationBuffer - 4Kbytes). If the mobile pointer exists, as is the case in this example, thenit is a mobile terminating call. Otherwise MOIPHI would have read the outgoingglobal 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 twodigits of the called party number (i.e. MSRN) in the OIP-IAM CB4k, in order todetermine which MSRN within the MSRN series is to be addressed. MOIPHIsends this information in signal MINCCONNECT to MRNR to find the previouslyassigned MSRN record.27. MRNR uses the mobile pointer and the last two digits of the MSRN receivedin signal MINCONNECT to derive the MSRN pointer within its block. Once theMSRN record is found, MRNR seizes an MTB17 individual with combined signalpair SEIZEMTB1/ACK. This signal contains the terminating MS’s IMSI that wasstored in the MSRN record at step 17. Nested within this signal pair, MTB seizesthe companion MTBCO18 individual with combined signal pairINITIATEMTC/ACK. MTB and MTBCO share the same file size hence the samepointer. Although MOIPHI seized MRNR as its user at step 26, it is MTBCO thatconfirms the seizure as an MOIPHI user with signal MINCONNECTR.28. MRNR then passes the rest of the call related information that was receivedin the MAP-PRN message (stored at step 18) to MTB with signalsPRNLATADATA (LATA), PRNDATAINFO (NCR and GSMC address) andPRNDATAEND1 (GSM/PLMN BC). At this point, the MSRN individual withinMRNR 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 aswell 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 CarrierService), which is used for communication between AM's in the same physical node. It consists ofboth a traffic and an administrative part.

Page 19: Gsm Call Path Course

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 themaster 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 theinterface to call charging and monitoring.

The MSRN within block MRNR is only used temporarily to deliver the call fromthe GMSC to the VMSC. Once the call enters the VMSC, the subscriber isidentified 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 areasked to coordinate the remainder of the call set up.

Figure 929. MTBCO then receives the OIP-IAM message in signal MRECFWDMSG fromMOIPHI. MTBCO first distributes the OIP-IAM message to MTB with signalMMSG. Over the next few steps, MTB will get most of the information for thisterminating call set up from this OIP-IAM message, which is contained within theCB4k.30. MTB then seizes an MTBSS19 individual with signal SEIZEMTBSS3, whichcontains the IMSI that was stored in the MSRN record. MTBSS shares the samefile size and thus the same pointer as MTB and MTBCO. MTBSS then uses theIMSI to identify the VLR record with combined signal pair IDENTIFYMS/ACK toblock MSNAN. MSNAN performs mobile digit analysis on the IMSI in order to findthe MTV individual assigned to the subscriber. If the VLR record is not found, thecall fails and is subject to EOS (End-Of-Selection) code 2288. Note the VLRshould always be found since it was found earlier at the MAP signalling phase inorder to assign an MSRN.

MOIPHIMTB29bMMSGMTBCO29aMRECFWDMSGMTBSSMSNAN30aSEIZEMTBSS330bIDENTIFYMS / ACK31PREVENTDISC / ACKMTVMNSAN33IMSITOANRES2 / ACK34SEIZEMTBSS2RMTVS32bFETCHSSALL / ACK32eFETCHSSALL1 / ACK32hFETCHSSALL1/ ACK32a/cREADMTVDA1 / ACK32d/fREADMTVDA3 / ACK32g/iREADMTVDA5 / ACK35REQAOCSTATUS / ACK19 MTBSS - Mobile Telephony traffic coordinator, B-subscriber, Subscriber Services

MTBSS is an MSS (Mobile Switching Subsystem) block that handles the invocation of supplementaryservices for the B-subscriber in the MSC/VLR server.

Page 20: Gsm Call Path Course

31. MTBSS uses combined signal pair PREVENTDISC/ACK to remove MTVfrom the suitable list and thus ensure the MTV will not be disconnected duringthis process. An MTV may be disconnected and used by another MS when notenough MTV records exist within the VLR, a process known as recycling.32. MTBSS reads subscriber data and classes that it will need to verify duringthe terminating call. It sends combined signal pairs READMTVDA1/ACK,READMTVDA3/ACK and READMTVDA5/ACK to MTV, which in turn sendsnested combined signal pairs FETCHSSALL/ACK, FETCHSSALL1/ACK andagain FETCHSSALL1/ACK to MTVS. There following is some of the data andfeatures 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/ACKto perform IMSI series analysis. MNSAN is asked to determine if the IMSI seriesis subject to any of the following analysis results: OBA (Origin for B-numberAnalysis), NATMS (NATional MS), OWNMS, PLMN and STALL (SubscriptionType ALLowed). This data is then stored in MTBSS and used by MTBSS as wellas 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 orinternational subscriber within this PLMN.• OWNMS - determines whether the subscriber belongs to the HPLMN (HomePLMN) or not. As an example, it is used to determine whether the subscribercan make originating calls without dialling the numbering plan area code.• PLMN - indicates which language must be used for the announcementmessages sent to the subscriber.• STALL - indicates whether the ST (Subscription Type, STYPE) stored in theVLR can be used. The ST is a value that associates a mobile subscriber to agroup with certain characteristics. All mobile subscribers with the same SThave the same result in route, end-of-selection, charging and accountinganalysis. The ST is stored in the HLR profile and sent to the VLR as anEricsson private parameter.

34. MTBSS confirms successful seizure to MTB with signal SEIZEMTBSS2R asa response to signal SEIZEMTBSS3 at step 30 above35. MTB fetches the AOC (Advice Of Charging) status information from MTBSSwith REQAOCSTATUS/ACK. MTB stores this information for possible later use.For more information on this feature see FS “Advice of Charge in MSC/VLRServer”.

20 MNSAN - Mobile telephone Number Series ANalysis

Page 21: Gsm Call Path Course

MNSAN is an MDS block that contains functions for analysis of IMSI number series and theadministration of the table of analysis results and data associated with those number series. Theprimary use for analysis is to translate an IMSI number series to give data for traffic handling.

6.3.4.2 Analysis of BC

Figure 1036. If CAMEL (Customized Applications for Mobile network Enhanced Logic)phase 3 is supported (DBS parameter GSM1APTF:CAMELPH3SUPP) in theMSC, MTB asks MTBSS to fetch CAMEL data with signal FETCHCAMELDATA.MTBSS then asks block MVIPH21 with signal REQVLRDATA to load CAMELdata from the VLR directly into CB4k containing the OIP-IAM message. Note thatthe type of information requested is not included within signal REQVLRDATA butrather within the OIP’ section of the CB4k. MTBSS requests all relevant CAMELdata. MVIPH uses combined signal pair PREVENTDISC/ACK to remove MTVfrom the suitable list and thus ensure the MTV will not be disconnected duringthis process. It then asks MTV to provide the MTVIN22 pointer for O-CSI data withcombined signal pair FETCHRECPTR/ACK. It then asks MTV to provide theMTVIN pointer for D-CSI and VT-CSI data, with two more FETCHRECPTR/ACK

MOIPHIMTBMTBCOMTBSSMTVMABCMUABC39aFORWARDPLMNBC39bFORWARDISDNBC38bSEIZEMUABC / ACK38a/cSEIZEMABC/ ACK39cFORWARDPLMNBC39dFORWARDISDNBC36aFETCHCAMELDATA36cPREVENTDISC / ACK36dFETCHRECPTR / ACK36eFETCHRECPTR / ACK36fFETCHRECPTR / ACK36gALLOWDISC / ACK36bREQVLRDATA36hREQVLRDATAR37aFETCHTA / ACK37bFETCHCAMELDATAR40aFWDMISCDATA140bFWDMISCDATA1MVIPHMVIPH21 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 whorequests 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 toCAMEL (Customized Applications for Mobile Network Enhanced Logic) and MISI (Mobilitymanagement Intelligent network Subscription Information). CAMEL includes O-CSI (Originating

Page 22: Gsm Call Path Course

CAMEL Subscription Information), SS-CSI (Supplementary Service CSI), MO-SMS-CSI (MobileOriginating Short Message Subsystem CSI), D-CSI (Dialled Services CSI), VT-CSI (VMSCTerminating CSI), M-CSI (Mobility Management CSI) and MT-SMS-CSI (Mobile Terminating ShortMessage Subsystem CSI) data.

combined signal pairs. Since the MS in this example has no such data, its MTVrecord 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 removethe prevent disconnection indication in MTV. MVIPH returns a successful resultto MTBSS with signal REQVLRDATAR. Even though the requested data was notfound, 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 signalFETCHTA/ACK and stores it the OIP-IAM CB4k. MTBSS only fetches the TA ifthe global equal access feature is supported in the MSC (DBS parameterGSMMSCF:GEAFEATURE). See FS “Global Equal Access in MSC/VLR serverand GMSC server” for more details on this feature. MTBSS then indicates toMTB 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 CAMELdata combination, the call would have to be route to the SSFAM (ServiceSwitching Function Application Module) in order to contact the relevant IN nodes.

38. The MTB individual seizes an MABC individual as a side link with combinedsignal pair SEIZEMABC/ACK. MABC in turns uses nested combined signal pairSEIZEMUABC/ACK to seize its corresponding MUABC individual. Note theMABC 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 toMABC and then onwards to MUABC with signal FORWARDPLMNBC.Furthermore, since the OIP-IAM CB4k contains an ISDN BC, MTB forwards it toMABC and then onwards to MUABC with signal FORWARDISDNBC.40. MTB then forwards some miscellaneous data such as TMR and WSIG toMABC in signal FWDMISCDATA1 that is also forwarded to MUABC. This data isrequired for analysis of the BC.

Figure 1141. MTB then asks MABC to perform analysis of BC for this terminating call withsignal ABCMTSETUP1.

Page 23: Gsm Call Path Course

MOIPHIMTBMTBCOMTBSSMABCMUABCMTVSMTVMTECA42MPRETSA1 / ACK43MBCOMPANA1 / ACK44b/fFETCHSUBSCR/ ACK44c/eSUBSCRANA/ ACK44dCHKSUBSCRBSG / ACK44a/gFETCHSUBSCR/ ACK41ABCMTSETUP144hABCMTSETUPRAnalysis of bearer capabilities

Analysis of bearer capabilities is partly the negotiation of the BC (BearerCapabilities) between the MSC/VLR and the MS. During this process theMSC/VLR determines the final values of certain PLMN bearer capabilityparameters taking into account the MS’s capabilities and preferences (e.g.classmark) and the MSCs capabilities. The analysis of bearer capabilities alsoinvolves the determination of the BASC (BAsic Service Code, either a teleserviceor bearer service) that is checked against the subscribed BASCs.

42. MABC then uses the previously received BC to generate a BASC (BAsicService Code, either a teleservice or bearer service), which in this case turns outto be teleservice ‘telephony’. MABC then asks MTECA to pre-analyzetelecommunication services based on the BASC with combined signal pairMPRETSA1/ACK. MTECA determines whether the telecommunication servicerequested by the MS is available in the system. If available, MTECA returns a setof 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 andterminating ends are compatible. The combined signal pair used for compatibilityanalysis is MBCOMPANA1/ACK.44. MABC then proceeds to fetch the MS’s subscribed BASC list. This isaccomplished by using combined signal pair FETCHSUBSCR to MTBSS, viaMTB. MTBSS then sends nested combined signal pair SUBSCRANA/ACK toMTV. MTV in turns sends another nested combined signal pair,CHKSUBSCRBSG/ACK, to MTVS. MTVS returns a list of bearer services andteleservices that the MS is subscribed to. MABC performs a subscription checkto 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 ABCMTSETUPRto MTB.Figure 1245. MTB then repeats the analysis of bearer capabilities for UMTS with signalUABCMTSETUP1 to MUABC via MABC. MUABC also generates a BASC (BAsicService Code) and asks MTECA to pre-analyze telecommunication servicesbased 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 andterminating ends are compatible. The combined signal pair used for compatibility

Page 24: Gsm Call Path Course

analysis is UMBCOMPANA/ACK.47. MUABC asks MABC to provide the MS’s subscribed BASC list that it fetchedin step 44 with combined signal pair SUBSCRDATA/ACK. MABC again fetchesthe 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 andteleservices that the MS is subscribed to.48. MUABC performs a subscription check to determine if the MS is subscribedto the BASC required for this call on UMTS. The analysis succeeds since the MSis allowed to access UMTS for this call and thus MUABC returns signalUABCMTSETUP1R to MTB via MABC.49. MTB asks MTBSS to fetch subscriber service data related to a specificBASC, in this case ‘telephony’, with signal GETBGDATA. MTBSS usescombined signal pair FETCHSSBSG/ACK to MTV, which in turn uses combinedsignal pair FETCHSTBSG/ACK to MTVS. MTBSS returns information such asCUG validity, B-TCL and whether call forwarding may occur or not in signalGETBGDATAR.

MOIPHIMTBMTBCOMTBSSMABCMUABCMTVSMTVMTECA47c/gFETCHSUBSCR/ACK 47d/fSUBSCRANA/ACK47eCHKSUBSCRBSG / ACK47b/hFETCHSUBSCR/ ACK45aUABCMTSETUP148bUABCMTSETUP1R45bUABCMTSETUP148aUABCMTSETUP1R45cUMPRETSA / ACK46UMBCOMPANA / ACK47a/iSUBSCRDATA/ ACK49aGETBGDATA49eGETBGDATAR49b/dFETCHSSBSG/ ACK49cFETCHSTBSG / ACK

6.3.4.3 Seizure of Connection Service, Charging and CC layer

Figure 1350. MTB orders the seizure of an MCSE23 individual with signal SEIZEMCSE1.The MCSE individual proceeds to seize two SSVs (Switching Switch View) viablock COMAIN24 in the RMP (Resource Module Platform). Refer to “ConnectionService (CSE)” service specification document for details on this process. Thefirst SSV has a two-way connection and is joined to the SSV seized by theTRAM, while the second SSV is joined to the first and has speech broken in bothdirections. The identity of the TRAM SSV and its logical channel is obtained byMTB from the OIP-IAM and passed on to MCSE in signal SEIZEMCSE1.51. After seizing its SSVs, the MCSE individual proceeds to seize itscorresponding MCIWF25 individual with signal INITIATEMCIWF. MCSE and

MOIPHIMTBMTBCOMTBSSMABCMUABCMCSEMCIWF51aINITIATEMCIWF51bINITIATEMCIWFRSeize 2SwitchingSwitch

Page 25: Gsm Call Path Course

ViewsCOMAINRMP50SEIZEMCSE152SEIZEMCSE1RMTTEC54a/eMSTARTMTTEC/ ACK54b/dSTARTMTTEC/ ACK54cSEIZEMTTEC / ACKAPCRMPTRACOTRAM55MMSGR54fSTARTTIMERS53bGET2NDANR / ACK53aCLIPINFO53cCLIPINFOR23 MCSE - Mobile telephony Connection SErvice

MCSE is an MSS (Mobile Switching Subsystem) block that is responsible for the seizure and releaseof switch views needed for basic call handling in MSS. Block MCSE is responsible for the setting ofthrough-connection state, for the generation of call in progress tone, ringing control tone andannouncements 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 alluser orders from the AM-users except those dealing with Message Senders, Digit Receivers, DigitSenders and Monitoring Digit Receivers. COMAIN owns the SVs and channels and coordinates alluser 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 datacalls 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 itsvariables and confirms seizure to MCSE with signal INITIATEMCIWFR. MCIWFis seized in case an interface to the DTS-R (Data Transmission Subsystem in theRMP) 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 tosignal SEIZEMCSE1 at step 50 above.53. MTB asks MTBSS to determine how to handle the CLIP (Calling LineIdentification Presentation) feature for this call with signal CLIPINFO. MTBSSthen requests MTB to provide additional CLIP information such as a secondcalling party number, if it exists, with combined signal pair GET2NDANR/ACK.MTBSS then returns the results in signal CLIPINFOR indicating whether or not topresent the CLIP and which calling party number to use. For more information onthe CLIP feature, refer to FS “Calling Line Identification Supplementary Servicesin MSC/VLR”.54. MTB then verifies if any sort of timing is required for this call for features such

Page 26: Gsm Call Path Course

as CIP (Call In Progress tone) delay time, ACM delay time and MGW (mediagateway) selection time. Timing is performed by block MTTEC26, which is seizedas a side link to MOIPHI. In this particular example CIP timing is required;therefore, MTB ask MTBCO to seize timing resources with combined signal pairMSTARTMTTEC/ACK. MTBCO in turn sends nested combined signal pairSTARTMTTEC/ACK to MOIPHI, which then seizes an MTTEC individual as aside link with nested combined signal pair SEIZEMTTEC/ACK. MTB then ordersthe start of the timers with signal STARTTIMERS directly to MTTEC.55. MTB returns control of the CB4k and the OIP-IAM message within it toMTBCO with signal MMSGR. MTBCO had handed over control to MTB at step29 above and will return control back to MTB later in the call. MTBCO now needsto take care of charging requirements for this call.

communicates with RMP using the APSI service 'Data Transmission Interworking Unit DeviceService'

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 formobile terminating, call forwarding, and CAMEL Phase 3 rerouting calls. The timers are started by theMOIPHI user. In case of call forwarding the block will be relinked to a new user.

Figure 1456. MTBCO initiates the seizure of a charging view via MCEDHC27 with signalSEIZECHGCCC1. MCEDHC seizes an individual and orders to the seizure of acontext adapted charging view to block CHVIEW28 in the RMP. MCEDHC alsosubscribes locally to public charging data, in particular the ‘analysis result’. Publiccharging data is data that can be stored in a charging view by any user and isaccessible to all users. This makes it possible for users to exchange somecharging data between them. MCEDHC confirms seizure of a charging view andestablishes a link with MTBCO with signal SEIZECHGCCCR.57. MTBCO sends the CB4k pointer to MCEDHC with signal MSGREPORT, sothat MCEDHC can read the necessary charging data directly from the OIP-IAM.MCEDHC then asks MTBCO to specify exactly which parameters within the OIP-IAM it would like to include as charging data with combined signal pair

MOIPHIMTBMTBCOMTBSSMABCMUABCMTTECAPCRMPTRACOTRAMMCEDHC57aMSGREPORT57dMSGREPORT1RTRAN57cTRAGLROUTENO / ACK56aSEIZECHGCCC156bSEIZECHGCCCRCHVIEWRMPStore publiccharging data

Page 27: Gsm Call Path Course

Seize a fullChargingview in RMPMTBCCMCCMHMCCPH60a/eSEIZEMTBCC/ ACK58MMSG61MMSGRMEPPA59a/cSENDEMLPPINF/ ACK59bGETGEMLPPWPS1 / ACK60b/dSEIZEMMH/ ACK60cACTIVEPPH / ACK57bSENDOUTCCC/ACK27 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 controlsthe charging analysis of events. MCEDHC filters charging data using the information received fromCHS.

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 forprocesses, controlled by the user (e.g. a call or a service). A view can be used for each process towhich 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 hasto be initiated. When an output is initiated, the collected data in CHVIEW can be fetched by the outputblocks.

SENDOUTCCC/ACK. One of the parameters MCEDHC is asked to read is theincoming global route number, which TRAN29 translates into a global route namewith combined signal pair TRAGLROUTENO/ACK. Once all the data is read intovariables, MCEDHC returns signal MSGREPORT1R to MTBCO. This signalincludes 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 thedistribution list, which in this example happens to be MTB again. Once againsince 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 initiatesthis check by sending combined signal pair SENDEMLPPINF1/ACK to MTBSSwith an EMLPP if available. If an EMLPP parameter was received in the OIP-IAM, MTB uses it or a mapping of it; otherwise a default value is assigned. Sincethe WPS (Wireless Priority Service, variant of EMLPP feature) is active in thisexample (DBS parameter GSM1APTF:WPSF), MTBSS sends nested combinedsignal pair GETGEMLPPWPS1/ACK to MEPPA to determine the grantedEMLPP. Otherwise, MTBSS would have sent combined signal

Page 28: Gsm Call Path Course

GETGEMLPPINF/ACK. The granted EMLPP will be used later at channelassignment.

The purpose of EMLPP and WPS features is to allocate a priority to a call so thatupon congestion the BSC can pre-empt radio resources or buffer radio resourcerequests based on this allocated priority. For more information on the EMLPPand WPS features, refer to FSs “Enhance Multi-Level Precedence and Pre-Emption 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 thecall path. MTB orders the seizure of an MTBCC31 individual with combinedforward signal SEIZEMTBCC. MTBCC shares the same file size and thus thesame pointer as MTB and MTBSS. The MTBCC individual then orders theseizure 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 loadingand 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 serviceAdministration

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 thegranted 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 functionsneeded for handling of mobile-terminated calls. It also comprises the DTAP message handlingfunction 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 relatedto CC (Call Control) and call-related supplementary service procedures.

Page 29: Gsm Call Path Course

Within this combined signal pair, the MCCMH individual activates itscorresponding MCPPH33 individual with combined signal pair ACTIVEPPH/ACK.Note the MCCMH and MCPPH individuals share the same pointer, hence thesame file size. MTBCC acknowledges seizure with combined forward signalSEIZEMTBCCACK.61. MTB again returns control of the CB4k and the OIP-IAM message within it toMTBCO with signal MMSGR. MTBCO had handed over control of the messageto MTB at step 58 above.6.3.4.4 Paging Preparation and Paging Message Sent

Figure 1562. MTB sends the NCR and the GMSC address in signal SENDCAMELDATA toMTBSS, which it may need if this call need to be transferred via optimal routing,see description below. MTB also sends the transfer treatment indicators toMTBSS in signal SENDTREATINDIC, which it may need to determine if this callrequires a transfer.

MTBMABCMUABCMCSEMCIWFMTBSSMCEDHCMTVMZONE63aPREPPAGING163bRMMDATA1 / ACK65aZCFRRCHK65bFETCHZCDATA/ACK65cZCFRRCHKR66READYFORPAGMTBCCMCCMHMCCPHMOIPHIMTBCO62aSENDCAMELDATA62bSENDTREATINDICMZONE64MRECFWDMSGRIf the call needs to be transferred later on and the optimal routing feature is activeand permitted in the GMSC, then the VMSC may ask the GMSC to perform thecall 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 DTAPmessage. 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 identifythe 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 signalPREPPAGING1. MTBSS reads the subscriber state and roaming restrictioninformation from MTV with the combined signal pair RMMDATA1/ACK. Theassumption here is that the MS is still attached. If the roaming restrictioninformation indicates that the subscriber is restricted due to roaming being an

Page 30: Gsm Call Path Course

unsupported feature, a disconnection order or a call forwarding indication(CFNRC, Call Forwarding Not Reachable) is sent to MTB. This feature restrictsthe MSC service area to the MS when the MSC does not support certain senstiveservices (for example, Advice of Charge or Regional Subscription). The roamingrestriction indication is received from the HLR. For more information on thisfeature, refer to FS “Roaming Restriction Due to Unsupported Feature inMSC/VLR”. As in all other cases in this example, the check is successful andallows the call set up to proceed.64. After receiving signal MMSGR from MTB (step 61), MTBCO determines thatthere are no more blocks to distribute the message to. Therefore MTBCOconfirms the reception of the OIP-IAM message to MOIPHI with signalMRECFWDMSGR. At which point, MOIPHI will no longer buffer any forwardmessages and sends to MTB any that may have been received. No messagesare buffered in this example. MRECFWDMSGR is the return signal toMRECFWDMSG from step 29 above.65. If any of the regional services (local subscription, regional subscription andsubscription with tariff areas) are supported in the MSC, MTBSS orders MZONEto 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 thistask. This individual then fetches the zone code set from the MTV with combinedsignal pair FETCHZCDATA/ACK. The VLR zone code data is stored in blockMTVZONE; however in this example, since the MTV individual has no link toMTVZONE, it knows there is no zone code data and indicates this to MTBSSwith signal ZCFRRCHKR. As a result, the process successfully proceeds. SeeFSs “Local Subscription in MSC/VLR Server”, “Regional Subscription inMSC/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 proceedwith paging. This is a reply to signal PREPAGING1 at step 63.

Figure 1667. Before initiating paging, MTB starts the not reachable timer to supervise thetime between paging and a successful traffic channel assignment. The timerduration is determined by DBS parameter GSM1APTC:TIMNREAM. If LATAs areused, then MTB initiates paging to block MPAG34 with signal LATAPAGEREQ2;otherwise, signal PAGEREQ5 is used. In this example, MPAG receives signalLATAPAGEREQ2.68. MPAG seizes an individual and immediately busy marks the MTV record for‘paging’ with combined signal pair BUSYMARKMSUB/ACK. It is here that MTVstores the MPAG pointer. When the MS responds to the paging, the IMSI can beused to identify the MTV pointer, which will then contain the identity of MPAGindividual and thus link the paging response process to the paging requestprocess. If the backward combined signal BUSYMARKMSUBACK indicates thatthe subscriber is already busy at the ‘CM level’ or for previous ‘paging’, then the

Page 31: Gsm Call Path Course

paging attempt fails.69. MPAG reads the current LA (Location Area) from MTV with combined signalpair RMMDATA1/ACK. It then asks block MBSSD to translate the LA into thepresent LATA with combined signal pair LOCTOLATA/ACK. If the LATA receivedin signal LATAPAGEREQ, which is the LATA used to assign the MSRN, matches

MTBCOMTBMABCMCSEMCIWFMCEDHCMTBCCMTVMTBSS72bTRANSFERTA / ACKMCCMHMPAG67LATAPAGEREQ268BUSYMARKMSUB / ACK69aRMMDATA1 / ACK70aRMMDATA1 / ACK71CHECKGPRS / ACK72aLATAPAGEREQRMBSSD69bLOCTOLATA / ACK70bLAPTOLAI / ACK34 MPAG - Mobile telephony PAGing

MPAG is an MMS block that receives requests for paging, fetches the data related to paging in oneLA or LATA or global paging, and seizes blocks MUPAG and/or MBPAG according to the requiredtype of paging (UMTS/GSM). If paging is executed via SGSN, MPAG sends the page requestmessage to MGPRO for packing.

the present LATA, the call proceeds. Otherwise, the call attempts fails due tLATA mismatch. Note this LATA check cparameter GSMMMSC:CTRESTLATA.70. MPAG reads the current LA (Location Area) again from MTV with combinedsignal 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 tocommunicate the identity of the LA to the BSC. Note that it is at this step thatMPAG checks to see if the TMSI is used, in which case itsupply it. The TMSI feature is not active in this example.71. MPAG also checks if the MS is GPRS attached with combined signal pairCHECKGPRS/ACK to MTV. The reason for this check is that if the MS wereGPRS attached as well as IMSI attached and the MSC supports the Gs interfacto the SGSN (Serving Gprs Service Node), then the paging wGPRS. MPAG would seize block MGPRO for this purpose.72. MPAG confirms that it accepts the page request with signal LATAPAGREQRto MTB. This is the reply signal to LATAPAGEREQ2 from step 67. MTB transfthe LATA information received in this signal to MTBCC with combined signalTRANSFERTA/ACK. MTBCC s

35 MGPRO - Mobile Gs-interface PROcedures

Page 32: Gsm Call Path Course

MGPRO is an MMS block that contains the logic of all the BSSAP+ procedures, which are handledvia the Gs-interface towards SGSN (Serving GPRS Support Node) in the MSC/VLR.

Figure 1773. 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 IMSIin signal GSMPAGE. MBPAG then asks MBSSD to provide a list of BSCs thatthe LA spans with signal pair BSCLIST/R.75. MBPAG orders the sending of a BSSMAP-Paging message to a particularBSC with signal PAGEPACKREQ to block MRRM37. Note that if an LA spansmore than one BSC, then this message is sent once for each BSC. MRRMinitiates the message packing by sending to MRRMH38 the various informationelements required in the BSSMAP-Paging message. MRRM supplies MRRMHwith the necessary parameters using a series of combined signal pairs: the IMSIwith RRIMSIOUT/ACK and the Cell Identifier List (LA in this case) withRRCEIDLSTOUT/ACK.

MTBMABCMTBCCMTBSSMCCMHMPAGMBPAGMBSSD74aGSMPAGE74bBSCLIST74cBSCLISTRMRRMMSCCLMRRMH75bRRIMISOUT / ACK75cRRCEIDLSTOUT / ACK76aSENDBSSMAPCLCCSSCBMBSCSCRDBSSMAP –PagingSCCP –UDT (Connectionless)SCRD75aPAGEPACKREQ78bGSMPAGER76bBSSAPOCLMREQ77bG7BUFFREQR77aG7BUFFREQ 77cG7UDTREQI / R78aBSSAPOCLMRESULT77dG7UDTREQE / R73aSEIZEMBPAG73bMBPAGSEIZED36 MBPAG - Mobile telephony GSM PAGing

MBPAG is an MMS block that is responsible for paging via A-interface. Both Lata and satellite pagingare performed by MBPAG only. Depending on the information provided by MAPG in the signalGSMPAGE, 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 RRfunction level within the MSC. MRRM supervises the establishment and release of signallingconnections between a MSC and a BSC and handles and distributes the messages to and from theA-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.

Page 33: Gsm Call Path Course

76. Once all these information elements are forwarded for packing, MRRMorders MRRMH to send the connectionless SCCP message with direct signalSENDBSSMAPCL. MRRMH sends this BSSMAP message to MSCCL39 withsignal BSSAPOCLMREQ.77. MSCCL then seizes an SCCP dynamic buffer with signal pairG7BUFFREQ/R to block SCBM40. MSCCL loads the message within the bufferand then orders block SCRD41 to route the message to the appropriate BSC withthe following two signal pairs: G7UDTREQI/R and G7UDTREQE/R.78. MSCCL confirms the message sending to MBPAG with signalBSSAPOCLMRESULT. If MBPAG needs to send the BSSMAP-Paging messageto more than one BSC, it returns to step 75 above for the next BSC. This processrepeats itself until all BSCs are paged. This example assumes that the LA beingpaged only spans one BSC, hence no repetition. SCRD and other CCS blocksensure that the BSSMAP-Paging message is sent to the BSC over an SCCPUDT (Unit Data) message. Once all BSCs are paged, MBPAG returns anindication 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 timerduration. The parameter used depends on whether it is the first or second pageand whether is LA or global or LATA paging.

Note if the first page times out in MPAG, then MPAG may attempt a second pageby repeating the paging process starting with step 74 above. Whether or not asecond page is attempted and what type of paging is performed on the secondattempt depends on the first page type and a few other DBS parameters definedwithin block MPAG.

Paging Parameters

The Paging message (3GPP TS 48.008 Rel. 5) contains 2 mandatory andseveral optional parameters of which only the Chosen Channel is describedbelow:

• IMSI - is the International Mobile Station Identity, a number that uniquelyidentifies a subscriber within the PLMN network. IMSI is a mandatoryparameter.• TMSI - is the Temporary Mobile Station Identity, a number that uniquelyidentifies 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

Page 34: Gsm Call Path Course

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 forSS7 message processing.

41 SCRD – SCCP Routing Destination

SCRD is a CCS block that routes SCCP messages to destinations throughout the network. It containsfunctions for validation of message formats, determination of message destinations, determination ofdestination availability, message routing to MTP, message routing to local subsystems, messagereturn or discard on error, and provisioning for message screening.

(fraud and privacy) and since it is shorter than the IMSI, it reduces load onthe paging channels. This element is omitted in the case where the IMSI isused instead of the TMSI as a paging address at the radio interface• Cell Identifier List - is a mandatory parameter that uniquely identifies all thecells in which paging is to be performed. The parameter can contain a list ofindividual cells or a list of LAs or ask that all cells within a BSS be paged.6.3.4.5 Paging Response Message Received

MTBCCMCCMHMPAGMBPAGBSCCCSSCCOCMSCCOMSCCL79cOPCTOBSCP179dOPCTOBSCPRMRRMMRRMH80bRNICOMRHSZCB 81aRRCEIDIN / ACK81bRRLAY3IFIN / ACK80cRCVBSSMAPCO1RR -PAGING RESPONSEBSSMAP -CL3I (Comp Layer 3 Info)SCCP -CR (Connection Request)79aSCCONNINDI / ACK79bSCCONNINDEExisting TerminatingMobile Call Path80aRNICOMRRSZCB81cRRCHOSECHIN / ACK81dRRAPDUIN / ACKMRRMASGMRRMHO82aSEIZEASG / ACK82bSEIZEMRRMHO / ACK82cSTOREHOPID/ ACKFigure 1879. Assuming the MS hears the page and successfully answers with an RR-Page Response on the air interface, the BSC will send a BSSMAP-CL3I(Complete Layer 3 Information) message on the A-interface to the MSC. Thecontents of this message as well as the originating BSC point code is provided byblock SCCOC42 to block MSCCO43 with combined signal pair SCCONNINDI/ACKand direct signal SCCONNINDE. Note that the BSSMAP-CL3I message is

Page 35: Gsm Call Path Course

encapsulated by an SCCP-CR (Connection Request) message initiating anSCCP 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 SCCOC’s counterpartfor signalling over the A-interface. MSCCO transfers connection-oriented messages between theMSC and BSC.

MSCCO. An MSCCO individual is seized and the whole BSSMAP-CL3I messagecontent is stored within the individual. MSCCO then asks MSCCL to translate theBSC point code into a BSC pointer via signal pairOPCTOBSCP1/OPCTOBSCPR.80. The BSSMAP-CL3I message encapsulates the RR-Paging Responsemessage. Both messages will be analyzed and unpacked at the RR layer.MSCCO allocates a CB4k (Communication Buffer - 4 Kbytes) in which it storesthe BSSMAP-CL3I message. Block MRRM44 receives the message fromMSCCO in signal RNICOMRRSZCB, which contains the CB4k pointer and thediscrimination parameter (BSSMAP or DTAP). An MRRM individual is seized andsince this message has a BSSMAP component, it is forwarded to MRRMH withsignal RNICOMRHSZCB for unpacking. Since this message is connectionoriented at the SCCP level, an MRRMH individual is seized and will be used forall received and sent BSSMAP messages on this SCCP connection. MRRMHtransfers the content of the CB4k to its own internal buffers and then analyzes themessage by first determining the message type and then checking for anyformatting errors. It reports its result as well a list of received optional parametersto MRRM with hurry signal RCVBSSMAPCO1, which in this example includesthe BSSMAP message type of CL3I, Complete Layer 3 Information.81. Since the message is successfully analyzed by MRRMH, MRRM asksMRRMH to unpack the contents of the message, in other words, get theBSSMAP-CL3I message parameters. With combined signal pair RRCEIDIN/ACKMRRM gets the CGI (Cell Global Identity). MRRMH uses mandatory parameterCI (Cell Identifier) to build the CGI. MRRM also fetches the Layer 3 Informationmandatory parameter, with combined signal pair RRLAY3IFIN/ACK, the optionalChosen Channel parameter with combined signal pair RRCHOSECHIN/ACK andthe APDU parameter with combined signal pair RRAPDUIN/ACK.

Page 36: Gsm Call Path Course

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 LAwithin a PLMN• CellID, Cell Identity, 2 octets, uniquely identifies a cell within an LA or withina 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 severaloptional 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 RRfunction level within the MSC. MRRM supervises the establishment and release of signallingconnections between a MSC and a BSC and handles and distributes the messages to and from theA-interface.

• CI - The CI (Cell Identifier) is a mandatory parameter within the BSSMAP-CL3I message. The technical specifications gives several options on codingthe CI within the CL3I message. The CI can be the whole CGI or just CellIDor 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 thechannel allocated to the MS on the air interface.• APDU - Application Protocol Data Unit is an optional parameter that isdefined as a general container for passing information transparently betweenBSSs or between BSS and SMLC (Serving Mobile Location Center) via theMSC. In this example, contains location information that may be used later inthe 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

Page 37: Gsm Call Path Course

parameter that encapsulates the first layer 3 interface message sent by the MSto the BSC for a system request (usually a DTAP message but an RR layermessage in this case). The reason a DTAP message is encapsulated within aBSSMAP message, is so that a DTAP message can be sent at the same time asan SCCP-CR. Remember that a DTAP message is used for MS to MSCcommunication and thus by its very nature requires a previously establishedSCCP connection. The BSSMAP-CL3I message allows a DTAP message to besent along with an SCCP-CR thus saving signalling load on the A-interface bynot 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 anMRRMASG45 individual with combined signal pair SEIZEASG/ACK and then anMRRMHO46 individual with combined signal pair SEIZEMRRMHO/ACK. Notethat both MRRMASG and MRRMHO share the same size alteration event asMRRM and thus the same pointer. Nevertheless, MRRM sends the MRRMHOpointer to MRRMASG with combined signal pair STOREHOPID/ACK. MRRMalso provides the MRRMH block reference and pointer to both MRRMASG andMRRMHO.

45 MRRMASG - Mobile Telephony Radio Resources Management ASsiGnment

MRRMASG is an MMS block that contains protocol handling functions corresponding to radioresource 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 resourceand BSSMAP procedures related to handover.

This page is intentionally left blank.

Figure 1983. Since the protocol discriminator of the Layer 3 Information componentindicates it is a RR (Radio Resource) layer message. MRRM asks MRRMH toalso analyze the contents of this message with hurry signal RNICOMINDCB. Thissignal contains the same CB4k pointer allocate by MSCCO at step 80 but nowonly contains the Layer 3 Information parameter. MRRMH transfers the contentof the CB4k to its own internal buffers and then analyzes the message by firstdetermining the message type and then checking for any formatting errors. Itreports its result as well a list of received optional parameters to MRRM withhurry signal RCVBSSMAPCO1, which includes the message type of RR-Paging

Page 38: Gsm Call Path Course

Response.84. Since the Paging Response message is successfully analyzed, MRRM startsfetching from MRRMH the different parameters included in the message with aseries of combined signal pairs: the Ciphering Key Sequence Number withRRKEYSEQNRIN/ACK, the MS Classmark 2 Information withRRMOBCLAS2IN/ACK and the Mobile Identity, IMSI, with RRMOBILEIDIN/ACK.

CCSBSCSCCOCMSCCOMRRMMRRMH84aRRKEYSEQNRIN / ACK83aRNICOMINDCB84bRRMOBCLASS2IN / ACK83bRCVBSSMAPCO184cRRMOBILEIDIN / ACKMMM85RRLAYLINKED86aPAGERESPMMSZ86bMMLAYLINKED87aRRLAYCONRESPSCCP –CC (Connection Confirm)87bSCCONNRESP87cSCCONNRESPACKExistingTerminatingMobileCall PathMEC88aSEIZEMEC88bMECSEIZEDMMMCSMBSSD89aPAGERESPCSSZ189bCSLINKED90aLORECOREQ91aLAITOLAP191bLAITOLAP1R90bLORECOREQMRRMASGMRRMHOPaging Response Parameters

The Paging Response message is defined in (3GPP TS 44.018 Rel. 5 “Mobileradio interface layer 3 specification, RR control protocol”) and contains 3mandatory parameters which are described below:

• Ciphering Key Sequence Number - In a GSM authentication challenge, thepurpose of the Ciphering Key Sequence Number information element is tomake it possible for the network to identify the Kc (ciphering key) that isstored in the mobile station without invoking the authentication procedure.• Mobile Station Classmark 2 - This parameter indicates some general mobilestation characteristics. This affects the manner in which the network handles

the operation of the mobile station. For multiband mobile, this parameterincludes the frequency band in use.• Mobile Identity - Since the RR Paging Response message is the firstconnection oriented message in the mobile terminated call establishmentprocess, the mobile needs to identify itself with either the IMSI or TMSI. Fromthis point onwards, all other messages on the same SCCP connection willrefer to the same MS.

85. Since the first message, the BSSMAP-CL3I message, is successfullyanalyzed by MRRMH, MRRM completes the downlink with MSCCO by sendingsignal RRLAYLINKED. The reason this signal appears at this point is because allthe signals in the previous two steps are either hurry or combined signals.

Page 39: Gsm Call Path Course

86. MRRM then forwards all the data from the two messages that wereunpacked to the MM layer with signal PAGERESPMMSZ to block MMM47. AnMMM individual is seized which then completes the downlink with the MRRMindividual by sending signal MMLAYLINKED1.

Note that if the Paging Response message is received from UMTS rather thanGSM, then blocks MUSCCO and MUAMCO rather than MSCCO and MRRMwould represent the RR layer in the call path. However the signal to MMM wouldbe the same, signal PAGERESPMMSZ.

87. On reception of MMLAYLINKED, MRRM orders MSCCO to confirm theconnection at the SCCP layer with hurry signal RRLAYCONRESP. Then withcombined signal pair SCCONNRESP/ACK to block SCCOC, MSCCO asks CCSto send an SCCP-CC (Connection Confirm) message to the BSC thusestablishing an SCCP connection across the A-interface.88. In parallel with step 87, MMM seizes a MEC48 individual in case an IMEIequipment check is required later during this process. The MEC individual isseized 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 callscenario. MMMCS along with MMM interface with MSS (Mobile telephoneSwitching 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 MMinternal AXE links between CM and RR layers. MMM procedures are grouped into MM connectionmanagement 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 MS’s IMEI (International Mobile Equipment Identity)performs the equipment identity check by communicating via signalling with the EIR (EquipmentIdentity Register) node.

49 MMMCS - Mobile telephony Mobility Management Connection Setup

Page 40: Gsm Call Path Course

MMMCS is an MMS block that handles connection setup and updates link between MMM and blocksin CM-Layer after function access confirmation is over. MMMCS is involved in speech calls, SMSsand call independent supplementary services to and from the MS. It is also involved in the locationservice procedure.

89. MMMCS receives the Paging Response message data from MMM withsignal PAGERESPCSSZ1. An MMMCS individual is seized which thencompletes the link with MMM by sending signal CSLINKED. SignalPAGERESPCSSZ1 contains all the Paging Response parameters as well as theLAI.90. MMMCS then sends signal LORECOREQ to MRRM via MMM for thesending of a location reporting control message. However since the locationreporting control feature only applies to UMTS and this example has a GSMaccess, the signal is not acted upon by MRRM. This location reporting procedureis used to report where the MS is currently located, or to report when the MSmoves into or out of a given service area. This procedure relates to locationservices and other services in UMTS.91. MMMCS asks block MBSSD to translate the LAI (LA Identity) into an LApointer with signal pair LAITOLAP1/R.6.3.4.6 Paging Response Process Finds Paging Request Process

Figure 2092. The MMMCS individual orders the seizure of an MVLRP50 individual withcombined signal pair SEIZEMVLRP/ACK.

MTVMMMMECMMMCSMTBMABCMTBCCMTBSSMCCMHMPAGMBPAGMVLRPMSNAN92SEIZEMVLRP / ACK94IDENTIFYMS / ACK93ACCESSREQUEST295PREVENTDISC / ACK97bMTVTOMPAGP / ACK97cPAGEINDIC1 / ACKMUABCMCCPHMBRIA99MBSCRECIMSI196RMMDATA1 / ACK98a/dACCONFDATA2/ ACK97aACCONFDATA198e/ ACK98cPREVENTDISC / ACK98bUPDATEMSDATA / ACK50 MVLRP - Mobile telephony VLR Procedures

MVLRP is an MMS block that contains functions for performing VLR tasks such as analysis of themobile subscriber identity, and informing the VLR of radio contact with the MS. MVLRP supportsfetching of authentication data and IMSI from a previous cooperating VLR during location updating

Page 41: Gsm Call Path Course

and is also responsible for initiating authentication procedures.

93. MMMCS asks MVLRP to initiate the access confirmation for the mobileterminated call with signal ACCESSREQUEST2, which also carries thenecessary information. The MVLRP individual will inter-work with MMMCS, MSSblocks and MDS (Mobile Data Subsystem) blocks to perform the accessconfirmation.94. MVLRP then uses the IMSI received in the Paging Response message toidentify the VLR record with combined signal pair IDENTIFYMS/ACK to blockMSNAN. MSNAN performs mobile digit analysis on the IMSI in order to find theMTV 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 theexample.

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 blockMTMSIAN51. If the TMSI cannot be identified, MVLRP will order the MS to sendthe IMSI with the DTAP-Identity Request message on the A-interface andultimately the air interface.

95. MVLRP uses combined signal pair PREVENTDISC/ACK to remove MTVfrom the suitable list and thus ensure the MTV will not be disconnected duringthis process. An MTV may be disconnected and used by another MS when notenough MTV records exist within the VLR, a process known as recycling.96. MVLRP then reads the radio confirmation flag in the MTV with combinedsignal pair RMMDATA1/ACK. The radio confirmation flag indicates whether thelocation information was previously confirmed in the HLR. This flag is returned toMMMCS later in the process. If the flag is false, then MMMCS may initiate anupdate location to the HLR, more on this after step 130. The radio confirmationflag in this example is true.97. MVLRP then asks MMM via MMMCS to busy mark the VLR. MVLRPaccomplishes this by using combined signal pair ACCONFDATA1/ACK toMMMCS. Before forwarding the request to MMM, MMMCS fetches the MPAGpointer that was stored in MTV during the paging process (step 68) withcombined signal pair MTVPTOMPAGP/ACK. MMMCS then informs MPAG of thepaging response with combined signal pair PAGEINDIC1/ACK. In the backwardcombined signal, MPAG provides the access type, which in this case is “mobileterminating call” but could also be “mobile terminating SMS or SS”. Note this iswhere the paging response process and its associated individuals are bridgedwith the paging request process and its associated individuals.98. MMMCS then forwards the busy mark order received in the previous stepwith nested combined signal ACCONFDATA2/ACK to MMM. This signal containsan order to busy mark the VLR as well as: the MTV pointer, the access type andthe IMSI. Upon receiving the order, MMM sends a series of nested combined

Page 42: Gsm Call Path Course

signal pairs to MTV. MMM sends the classmark 2 information received in thePaging Response message to MTV with combined signal pairUPDATEMSDATA/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 theTemporary Mobile Subscriber Identity (TMSI).

MTV will not be disconnected during this process. Although the order in signalACCONFDATA2 is to busy mark the MTV record, MMM skips this step for nowsince 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 toblock MBRIA52 to verify if BSC Recording function is active for this MS during themobile terminating call access type. In this example, the function is off and thusthe signal is not acted upon by block MBRIA. However, if the function did apply tothis process, MBRIA would order MRRM via MMM to send the BSSMAP- TraceInvocation message to the BSC in order to start the recording. See FS “BSCRecording Initiation in MSC/VLR Server” and command series MGBR for moredetails on this function.6.3.4.7 Security Related Functions

Figure 21100. MVLRP now proceeds with authentication. It first seizes an MAUTH53individual with combined signal pair SEIZEAUTH/ACK.

MMMMECMMMCSMVLRPMTVMRRMMRRMHMAUTH100SEIZEAUTH / ACK101AUTHENTICATE104AUTHENTICATE1R107aAUTHENTICATE1102bREQACTKEYS / ACK102a/dRACTKEYS/ ACK103a/cUPDATEKEYS/ ACK106aTRACEINFOREQ106bTRACEINFOREQR107cSENDCIPH1 107bSENDCIPH1108bSENDCIPHU / ACK 108a/cSENDCIPHU/ ACKMTRIPMNSAN102cIMSITOANRES2 / ACK103bREQUPDKEYS / ACK105bINITCOMID 105aINITCOMID52 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 alsohandles the commands for the administration of BSC recording initiation

53 MAUTH - Mobile telephony AUTHentication

Page 43: Gsm Call Path Course

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 orquintuplets) from the HLR.

The authentication process is split into two parts: 1) security related function upto but not including ciphering and then 2) the remaining security relatedfunctions. The MSC may send the BSSMAP-Common Id message in betweenthese two parts. Furthermore, if the BSS Trace Invocation feature (DBSparameter GSM1APTC:MSCNF624) applies to the MS within this call scenario,then it is performed in between these two authentication steps. See FS “BSSTrace Invocation In MSC/VLR” and command series MGST_ for more details onthis function. Note this function is similar to the BSC Recording function presentat step 99 above.

101. MVLRP initiates the first authentication part, up to but not includingciphering, with signal AUTHENTICATE1 to MAUTH. Since the selectiveauthentication feature is active (DBS parameter GSMMMSC:SELAUTH) in thisexample, authentication is not performed (but ciphering must be performed) andthe only step in this first part is the fetching of the active keys, both the cipheringand integrity keys.102. A few conditions are required for selective authentication to apply. ThusMAUTH uses forward combined signal RACTKEYS to fetch the active keys(ciphering and integrity keys) via MTV. MTV in turn uses nested combined signalpair REQACTKEYS/ACK to read this data from MTRIP54. MTV then sendscombined signal pair IMSITOANRES2/ACK to MNSAN to determine if thesubscriber belong to the home PLMN (OWNMS). This IMSI series analysisagainst the OWNMS analysis result is required since selective authentication isonly performed for MS within their home PLMN. If the MS does not belong to thehome PLMN, then MTV indicates zero for the number of cipherings allowedwithout authentication; otherwise, it returns the number fetched from MTRIP.MTV returns this information along with the active keys and the CKSN to MAUTHwith backward combined signal RACTKEYSACK.

Note that for simplicity purposes the side links to MTV, such as MTRIP, are onlyshown in the figures when information from these side links is accessed.

103. MAUTH then checks that the number of cipherings allowed withoutauthentication is greater than zero and that the CKSN received from the MS inthe Paging Response message matches the one in the VLR from the previousstep. In this example, the number of cipherings allowed without authentication isindeed greater than zero and the CKSNs match and thus selective authenticationis allowed to proceed. Thus MAUTH sends combined signal pair

Page 44: Gsm Call Path Course

UPDATEKEYS/ACK to MTV to decrease by one the counter for the number ofcipherings allowed without authentication. MTV in turn sends nest combinedsignal pair REQUPKEYS/ACK to MTRIP to update this information. Note that theinitial number of successive subscriber accesses allowed to be performedwithout authentication for GSM security is determined by DBS parameterGSMMMSC: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 mobilesubscribers in the MSC/VLR. The authentication vectors are used for authentication and cipheringduring traffic handling.

104. MAUTH then returns AUTHENTICATE1R to MVLRP to indicate the firstpart of authentication is completed. This is the response to signalAUTHENTICATE1 in step 101 above.

Note if MTRIP did not have any active keys or if the CKSNs did not match, thenMAUTH would need to perform authentication with the MS. MAUTH would havesent the DTAP-Authentication Request message to the MS and then would havewaited for the DTAP-Authentication Response message. In order to performauthentication, a new authentication vector would have been required. If a newauthentication vector were not available in the VLR, then MAUTH would havefetched 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 Idmessage in order to inform the BSC of the IMSI associated with this SCCPconnection. According to the specifications, “if the MS, the BSS and the MSCsupport DTM and as soon as the IMSI is available at the MSC, the MSC shallsend the BSSMAP-Common Id message to the BSS”. See specification 3GPPTS 48.008 Rel. 5 for more details. There is no need to send the BSSMAP-Common Id message in this example.106. MVLRP then verifies if the BSS Trace Invocation feature applies to thissubscriber with signal pair TRACEINFOREQ/R to MTV. The subscriber in thisexample 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 Tracemessage to the BSC in order to start the tracing.107. MVLRP proceeds with the second part of the security procedures againwith signal AUTHENTICATE1 to MAUTH. Since ciphering is active in the MSCand the Ciphering Key Sequence Number received in the RR-Paging Response

Page 45: Gsm Call Path Course

matches the one fetched in MTRIP at step 102 above, MAUTH orders thesending of the BSSMAP-Cipher Mode Command message with signalSENDCIPH1 to MMM. MMM transits this signal to MRRM. This signal containsGSM 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 theDTAP-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 norfetch the IMEI and hence there is no need to fetch the IMEI from the MS. TheIMEI fetch indication is actually stored in block MEC as a local parameter(IMEIFETCH) and is read by MVLRP from MEC at restart. The IMEI checkindication is determined by a DBS parameter in block MEC,GSMMMSF:IMEICHECK.

108. Since the Cipher Mode Command is a BSSMAP type message, MRRMwill ask MRRMH to encode the message. However, since the MS in this exampleis also UMTS capable, MRRM first reads the UMTS ciphering and integrity keysfrom MAUTH with signal SENDCIPHU/ACK via MMM. MRRM may need thisinformation later on if the MS switches to UMTS. MAUTH obtained these keysearlier at step 102.

Figure 22109. MRRM initiates the building of the BSSMAP-Cipher Mode Commandmessage by sending to MRRMH the Layer 3 Header optional informationelement with combined signal pair RRLAY3HDOUT/ACK. MRRM also sends themandatory Encryption Information element with combined signal pairRRENCRYPOUT/ACK. In a previous step, the MRRMH individual unpacked areceived BSSMAP message, in this step it will pack a BSSMAP message that isto be sent to the BSC. Once all the information elements are forwarded forpacking, MRRM orders MRRMH to send the connection oriented BSSMAPmessage to SCCP with direct signal SENDBSSMAPCO.

CCSBSCSCCOCMSCCOMRRMMRRMHMMM110bRNOCOMREQCB110cSCDATAREQCBMECMMMCS109bRRENCRYPOUT / ACK110aRNOCOMREQCB109aRRLAY3HDOUT / ACK109cSENDBSSMAPCO110dSCDATAREQCBACKBSSMAP –Cipher Mode CommandSCCP –DT1 (Data Form 1)MRRMASGMRRMHOCipher Mode Command Parameters

Page 46: Gsm Call Path Course

The Cipher Mode Command message (3GPP TS 48.008 Rel. 5) contains 1mandatory and 1 optional parameter:

• Encryption Information - This element is a mandatory parameter thatcontains the user data encryption information used to control any encryptionequipment at the BSS, i.e. Kc and permitted algorithms.• Layer 3 Header Information - An optional parameter, that providesinformation the BSS needs over the air interface; however, it no longerserves any useful purpose unless the BSS requires it for backwardcompatibility.

110. MRRMH allocates a CB4k and writes the Cipher Mode Commandmessage into it. MRRMH then sends the message to MRRM with signalRNOCOMREQCB, MRRM forwards it downlink to MSCCO as a hurry signal.MSCCO forwards this message to SCCOC with combined signal pairSCDATAREQCB/ACK. SCCOC along with other CCS blocks then ensure thatthe Cipher Mode Command message is sent to the BSC over the SCCPconnection. SCCOC also releases the CB4k allocated by MRRMH above.

Figure 23111. When the BSC receives the Cipher Mode Command message, it selectsan appropriate algorithm, taking into account the MS ciphering capabilities. Onceciphering is successfully established with the MS, the BSC responds with aBSSMAP-Cipher Mode Complete message on the A-interface to the MSC. Thismessage is connection oriented, so its contents are provided by SCCOC in anewly allocated CB4k to MSCCO with direct signal SCDATAINDCB. Note that atthis point the MMS subsystem does not yet know the message type. Themessage is then forwarded to MRRM with signal RNICOMINDCB. This signalcontains the discrimination parameter, which indicates it is a BSSMAP typemessage. Therefore, MRRM forwards the message to MRRMH, also withRNICOMINDCB but as a hurry signal, for analysis and unpacking. MRRMHtransfers the content of the CB4k to its own internal buffers and then analyzes themessage by first determining the message type and then checking for anyformatting errors. MRRMH releases the CB4k and then reports its result as well alist of received optional parameters to MRRM with hurry signalRCVBSSMAPCO1, which in this example includes the BSSMAP message typeof Cipher Mode Complete.112. There are no mandatory parameters in the Cipher Mode Completemessage and one optional parameter was received in this example. MRRMreads the Chosen Encryption Algorithm parameter with combined signal pairRRCHOALGIN/ACK to MRRMH. This information is forwarded to MAUTH in thenext step.

Page 47: Gsm Call Path Course

CCSBSCSCCOCMSCCOMRRMMRRMHMMMMECMMMCS111cRNICOMINDCBBSSMAP –Cipher Mode CompleteSCCP –DT1 (Data Form 1)111aSCDATAINDCB111bRNICOMINDCB111dRCVBSSMAPCO1MRRMASGMRRMHO112RRCHOALGIN / ACKCipher Mode Complete Parameters

The Cipher Mode Complete message (3GPP TS 48.008 Rel. 5) contains nomandatory parameters and a few optional parameters, some of which areincluded below.

Chosen Encryption Algorithm - This optional element indicates the encryptionalgorithm being used by the BSS.

This page is intentionally left blank.

Figure 24113. MRRM then informs MAUTH, via MMM, with signal SENDCIPH1R thatthe ciphering was successfully completed. SENDCIPH1R is a reply signal toSENDCIPH1 at step 107 above.

MMMMECMMMCSMVLRPMTV118ACCESSREQUEST2RMRRMMRRMHMAUTH114eAUTHENTICATE1R115bRELEASEAUTHR113aSENDCIPH1R114bDISCAUTH113bSENDCIPH1R114aDISCAUTH114cDISCAUTHR114dDISCAUTHR115aRELEASEAUTH117aRADIOCONTACT / ACK117bUPDATEMSLOC1 / ACK120bGETACCESS / ACKMAUTH120a/cGETACCESS / ACK116aBUSYMARKMSUB / ACK116bRUNUSED116dRUNUSEDRMTRIP116cREQUNUSED/ACK119READMWF / ACK121bGETLOCDATA / ACK121a/cGETLOCDATA/ ACK116eIDLEMARKMSUB / ACKMAUTH then verifies if a new TMSI needs to be allocated. Since the TMSIallocation feature if inactive in this example, MAUTH proceeds; otherwise, itwould have reserved a TMSI in block MTMSIAN and then ordered the sending ofthe DTAP-TMSI Reallocation Command to the MS and waited for the DTAP-TMSI Reallocation Complete. TMSI allocation is determined by DBS parameterGSMMMSC:TMSIPAR, which is stored in block MAUTH.

114. Since MAUTH has finished with the security related functions, it firstreleases the ciphering procedure in MRRM by sending signal DISCAUTH toMRRM via MMM. MRRM replies via MMM with signal DISCAUTHR. MAUTH

Page 48: Gsm Call Path Course

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 oftriplets needs to be fetched from the HLR/AUC. MAUTH first busy marks theMTV record for ‘fetching of triplets’ with combined signal pairBUSYMARKMSUB/ACK. It then asks MTV for the number of unused tripletspresent in the VLR with signal RUNUSED. MTV fetches this information fromMTRIP with combined signal pair REQUNUSED/ACK and returns it to MAUTHwith signal RUNUSEDR. MAUTH then checks if the number of unused triplets is

greater than the allowed threshold (DBS parameterGSM1APTC:AVTHRESHOLD). If it were not greater, then MAUTH would initiatethe fetching of authentication vectors. In this example, the fetching of new tripletsis not required and thus MAUTH idle marks the MTV record for ‘fetching oftriplets’ with combined signal pair IDLEMARKMSUB/ACK and goes to idle itself.

For more information on authentication, selective authentication, ciphering, TMSIallocation and other security features refer to FS (Function Specification) “MobileSubscriber Related Security Functions in MSC/VLR”.

117. Since the security functions were successfully completed, MVLRP tellsMTV that a successful radio contact has been established by the MS withcombined signal pair RADIOCONTACT/ACK. MTV ensures the subscriber stateis set to attached and clears the implicit detach and deregistration timers.MVLRP also updates the LA pointer in MTV with combined signalUPDATEMSLOC1/ACK.118. At this point MVLRP has validated the access and thus confirms this factto MMMCS with signal ACCESSREQUEST2R. Note that this signal is aresponse to signal ACCESSREQUEST2 at step 93.119. MMMCS then reads the message waiting flag in MTV with combinedsignal pair READMWF/ACK. If the flag indicates that there is an outstandingmessage, then MMMCS orders the sending of the MAP-Ready for SM (or MAP-Note MS Present, MAP V1) message, via block MSMPAP55. This message wouldbe sent later in the process, after step 127, in order to inform the HLR that theMS is again reachable. Not the case in this example since there was nooutstanding message.120. MMMCS fetches the access type (GSM or UMTS) from MRRM withcombined signal pair GETACCESS/ACK via the MMM individual. The accesstype is required to determine which type of location information to fetch in thenext step (CGI or SAI).121. Since the access type in this example is GSM, MMMCS fetches the

Page 49: Gsm Call Path Course

location information from MRRM via MMM with combined signal pairGETLOCDATA/ACK. The CGI and TA (Timing Advance) values provided byMRRM are then used as input to the spatial trigger event. MMMCS reports themobile terminating traffic spatial trigger event to MSTEH56 with signalSTEENCOUNTER. This signal initiates another independent thread within thisprocess. MSTEH will need to determine if it needs to act upon this event, seestep 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 subscriber-based spatial triggers event data necessary for the support of spatial triggers feature. It is responsiblefor 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 25122. Now that the MS has been validated, MMMCS confirms the pageresponse to MPAG with forward combined signal PAGECONF. MPAG then idlemarks the MTV record for ‘paging’ with combined signal pairIDLEMARKMSUB/ACK. This undoes the busy marking of step 68. MPAG alsostops the paging timer it started at step 78 above.123. MPAG translates the LAI received in PAGECONF to a LATA pointer withsignal LOCTOLATA/ACK to block MBSSD. MPAG performs the call deliveryLATA mismatch check since the DBS parameter GSMMMSC:CTRESTLATA isset and the call delivery LATA pointer is known. Note this is the same parameteruse at step 69. Since the LATA used to assign the MSRN is the same as theLATA in which the call is set up, MPAG returns backward combined signalPAGECONFACK to MMMCS with a successful indication. This signal alsocontains the MTB block reference and pointer, which MMMCS will soon use tobridge the paging request and paging response call paths.124. MMMCS then fetches the CGI from MRRM with combined signal pairGETCGI1/ACK that transits via MMM. The CGI is required for the regionalservices check that MMMCS initiates as this point but whose signals only appear

Page 50: Gsm Call Path Course

at step 130 due to the nature of buffered signals.125. At this point MMMCS has completed its connection set up task andbegins linking out of the call path chain as well bridging the two ends of the callpaths together. It asks block MTBCC, via MTB to set its down link to MMM withcombined signal pair SETDOWNLINK2/ACK, which MTB forwards as combined

MMMMECMMMCSMTBMABCMTBCCMTBSSMCCMHMPAGMBPAGMVLRPMBSSDMTVMUABCMCCPHMRRM124bGETCGI / ACK123aLOCTOLATA / ACK122bIDLEMARKMSUB/ ACK125dFWDSCREENING/ ACK126bBUSYMARKMSUB/ ACK122aPAGECONF123b/ ACK124a/cGETCGI/ ACK125a/gSETDOWNLINK2/ ACK125b/fMDOWNLINK/ACK125c/eFWDSCREENING/ ACK126a/cCHANGEUPLNK1 / ACK127CHKUENOTIFY / ACK

signal pair MDOWNLINK/ACK. These signals contain MS Classmark 2information (in particular SS screening indicator), which MTBCC forwards toMCPPH, via MCCMH, with combined signal pair FWDSREENING/ACK.126. MMMCS then asks MMM to change its uplink to MTBCC with combinedsignal pair CHANGEUPLNK1/ACK. This prompts MMM to busy mark the MTVrecord for ‘CM (Connection Management) level’ with combined signal pairBUSYMARKMSUB/ACK. At this point MMMCS is no longer in the call path chain.127. MMMCS also checks if there exists a deferred MT-LR (MobileTerminating Location Request) with combined signal pair CHKUENOTIFY/ACKto MTV. If there were a deferred MT-LR request, MMMCS would have to informthe appropriate location services block that the UE (User Equipment, i.e. MS) isnow available.

Note that if the radio confirmation flag at step 96 indicates that the locationinformation was not previously confirmed in the HLR, then MMMCS would initiatea location update to the HLR, in parallel with the mobile termination process. Thisis accomplished by sending signal INITPARALOCUPD to MMM which would firstbusy mark the MTV record for location updating and then seize an MMMLR57 tocoordinate this parallel location updating process. This is not the case in thisexample.

Note that if the regional services result allows the sending of the MAP-Ready forSM (or MAP-Note MS Present, MAP V1) message, which may have beenrequired by the message waiting flag check at step 119 above, it would be sentat this point in the process. This message informs the HLR that the MS is againreachable so that, for example, an outstanding SMS message can be delivered.

Page 51: Gsm Call Path Course

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 theVLR.

Figure 26

MMMMECMABCMTBCCMPAGMVLRPMTVMUABCMRRM128bSTARTCM131aSTARTIMEICHK1131bSTARTIMEICHK1R131cIMEICHECKED128aSTARTCM131dIMEIACCESINFO13eIMEICLASSINFOMBPAGMBSSD132aPAGEDISC131fIMEIACCESINFO131gIMEICLASSINFO133cPAGEDISCR133bGSMPAGERELR133aGSMPAGEREL132bLAITOLAP1 / RMBPAGMTBMPAGMMMCSMZONE129bPREVENTDISC / ACK129cRDIMSIMSISDN / ACK129dREADSTE129eREADSTER129fALLOWDISC / ACK129gIMSITOANRES3 / ACKMNSAN129aSTEENCOUNTER130bFETCHZCDATA / ACK130cZCFCHECKR130aZCFCHECKMSTEHMSTEHMZONENote that at this point, MMMCS sends several signals that initiate several parallelprocesses; therefore, the signal order over the next 6 steps is not maintained inorder to facilitate the understanding of the various processes.

128. MMMCS then hands over control of the call processing to the CM layerby sending hurry signal STARTCM to MTBCC. MTBCC transits the same signalas a buffered signal to MTB.129. At step 121 above another independent process was triggered when aspatial trigger event indication (Mobile Terminating Traffic) was sent to MSTEHwith signal STEENCOUNTER. MSTEH seizes an individual and then determinesif it needs to act upon this event. MSTEH uses combined signal pairPREVENTDISC/ACK to remove MTV from the suitable list and thus ensure theMTV will not be disconnected during this process. MSTEH fetches both the IMSIand MSISDN from MTV with combined signal pair RDIMSIMSISDN/ACK toensure valid subscriber number information is available. MSTEH also reads thespatial trigger event information from MTV with signal READSTE/R. In thisexample, MTV has no side link to an MTVLCS58 individual and thus immediatelyresponds with signal READSTER with an unsuccessful indication. Since thereare 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 inorder to support GSM location services according to the standard. This block stores all the LCS

Page 52: Gsm Call Path Course

information such as privacy exception list, MO-LR (Mobile Originating Location Request) list of LCSoriginating classes that the MS is permitted to request, GMLC (Gateway Mobile Location Center) listfrom which a MT-LR (Mobile Terminating Location Request) is allowed.

pair ALLOWDISC/ACK to MTV. MSTEH looks for IMSI based STPROF (SpatialTriggers PROFiles) with combined signal pair IMSITOANRES3/ACK to MNSAN.Since there are no IMSI based spatial triggers in this example, MSTEH need notcontact the GMLC (Gateway Mobile Location Center) node, thus MSTEH returnsto idle. For more information of spatial triggers refer to FS “Spatial Triggers inMSC/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 theMSC, MMMCS orders MZONE to perform a subscription area check with signalZCFCHECK. MZONE dedicates an individual to this task. This individual thenfetches the zone code set from the MTV with combined signal pairFETCHZCDATA/ACK. The VLR zone code data is stored in block MTVZONE;however in this example, since the MTV individual has no link to MTVZONE, itknows there is no zone code data and indicates this to MMMCS with signalZCFCHECKR. As a result, the process proceeds successfully. See FSs “LocalSubscription in MSC/VLR Server”, “Regional Subscription in MSC/VLR Server”,“Subscription with Tariff Areas in MSC/VLR Server” and “Regional Services inHLR” for more details on the regional services feature.131. Upon reception of signal CHANGEUPLINK at step 126, MMM asks MECto perform the IMEI check with signal STARTIMEICHK1. Note that although theexchange 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 isavailable, MEC immediately returns the STARTIMEICHK1R signal with thedefault call through connection information to MMM. This signal informs MMMthat it can proceed with call set up and through connection. In other words, thereis no need to wait for the IMEI check to complete. MMM forwards this informationto the CM level with signal IMEIACCESSINFO1 to MTBCC which is passed on toMTB. MEC also returns the default IMEI check result with signal IMEICHECKEDto MMM. This signal indicates that the IMEI check was successful although nonewas performed; MMM forwards this indication to MTB via MTBCC with signalIMEICLASSINFO.132. At the reception of signal STARTCM at step 128, MTB orders the releaseof the MPAG individual with signal PAGEDISC. MPAG asks block MBSSD totranslate the LAI (LA Identity) into an LA pointer an with signal pairLAITOLAP1/R. MPAG needs the LA pointer in which the page was answered inorder to step the appropriate paging counters.133. MPAG order the release of the MBPAG individual with signalGSMPAGEREL. MBPAG responds with signal GSMPAGERELR and returns toits idle list. MPAG then in turn responds to MTB with signal PAGEDISCR and

Page 53: Gsm Call Path Course

returns to its idle list.

Figure 27134. The MVLRP individual is no longer required, so MMMCS orders itsrelease with signal RELEASEMVLRP. MVLRP sends combined signal pairALLOWDISC/ACK to MTV in order to undo the prevent disconnection indicationfrom step 95. MVLRP replies to MMMCS with signal RELEASEMVLRPR andreturns to idle state. At this point, the MMMCS individual sends itself aCONTINUEB signal in order to receive any buffered signals that may have beensent to it before returning itself to the idle list.135. MTB fetches the CGI from MRRM with combined signal pairGETCGI1/ACK that transits via MTBCC and MMM. Since the cell is local, i.e. nointer-MSC handover, MTB asks MBSSD to return the corresponding LN(Location Number) information with signal pair READCELLLN/R. The LNinformation will be used for the regional services check in the next step.136. If any of the regional services (local subscription, regional subscriptionand subscription with tariff areas) are supported in the MSC, MTB ordersMZONE, via MTBSS, to perform a subscription area check. Note this is the samecheck as in step 130 except that this time the MS location is identified with an LNrather than a CGI. MTB sends signal REGSERVCHK to MTBSS, which in turnssends signal ZCFCHECK to MZONE. MZONE dedicates an individual to thistask. This individual then fetches the zone code set from the MTV with combinedsignal pair FETCHZCDATA/ACK. The VLR zone code data is stored in blockMTVZONE; however in this example, since the MTV individual has no link toMTVZONE, it knows there is no zone code data and indicates this to MTBSSwith signal ZCFCHECKR. MTBSS forwards the result to MTB with signalREGSERVCHKR. As a result, the process proceeds successfully.

MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMZONE136bZCFCHECK136dZCFCHECKRMBSSD136aREGSERVCHK136eREGSERVCHKRMTBSS136cFETCHZCDATA / ACK135cGETCGI / ACK135fREADCELLLN / R138dBSCPTOGLRTE / ACK135a/eGETCGI/ ACK135b/dGETCGI/ ACK138a/gGETCHARGDATA/ ACK138b/fGETCHARGDATA / ACK138c/eGETCHARGDATA/ ACKMVLRP134aRELEASEMVLRP134cRELEASEMVLRPRMVLRPMMMCSMMMCS134dCONTINUEB134bALLOWDISC / ACK137aREPMONIEVENT137bREPMONIEVENTRto and fromMTBCOMZONE

137. MTB reports the fact that a downlink connection has been established toMTBCO with signal REPMONIEVENT. The signal contains the OIP-IAM CB4kpointer. MTBCO needs this information in case that monitoring of the subscriberis active. Since this is not the case, MTBCO immediately returns signalREPMONIEVENTR with a successful indication and control of the CB4k so that

Page 54: Gsm Call Path Course

MTB can proceed.138. MTB reads the global route number from MRRM via MTBCC and MMMwith combined forward signal GETCHARGDATA. Before replying, MRRM asksblock MBSSD to convert the BSC pointer into a global route number withcombined signal pair BSCPTOGLRTE/ACK. MRRM then responds with theglobal route number in combined backward signal GETCHARGDATAACK. Theglobal 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 28139. MTB orders the sending of the DTAP-Setup (Mobile Terminated)message with signal MSENDSETUP3 to MTBCC. MTBCC then fetches thecurrent access type (GSM or UMTS) from MRRM with combined signal pairGETACCESS/ACK via MMM. Since the access is still GSM and the analysis ofbearer capabilities for GSM succeeded, MTBCC proceeds with call setup.140. Since the access is still GSM, MTBCC fetches the GSM/PLMN BC fromMABC (for UMTS BC is fetched from MUABC) via MTB with forward combinedsignal pair MTFETCHBC. Before returning the BC, MABC attempts to read theclassmark 3 information, in particular the MS’s multislot capability, from MRRMvia the downlink with combined signal pair GETCLMARK3/ACK. In this example,since MRRM did not previously receive the classmark 3 information (BSSMAP-Classmark Update), it returns nothing and thus it is assumed the MS has nomultislot capability. The BC is an optional parameter within the DTAP-Setup(Mobile Terminated) message. MABC returns the GSM/PLMN BC in backwardcombined signal MTFETCHBCACK.141. MTBCC then attempts to fetch the HLC and LLC from MABC via MTBwith combined signal pairs FETCHGSMLLC/ACK and FETCHGSMHLC/ACK.Both HLC and LLC are optional parameters within the DTAP-Setup (MobileTerminated) 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 tobe included in the DTAP-Setup (Mobile Terminated) message. This parameter is

MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMTBSS139aMSENDSETUP3141bFETCHGSMLLC / ACK141eFETCHGSMHLC / ACK142MTFETCHCLIP / ACKMTBCOMCSEMCEDHC144aSENDRNMSG1143aBEARER1CAP1144bRNOCOMREQCB144cRNOCOMREQCB144dRNOCOMREQCB143cCALLINGNUMREQ139b/dGETACCESS / ACK 139cGETACCESS / ACK140b/jMTFETCHBC/ ACK

Page 55: Gsm Call Path Course

140c/iGETCLMARK3/ACK140d/hGETCLMARK3/ACK140a/kMTFETCHBC/ ACK140e/gGETCLMARK3 / ACK140fGETCLMARK3 / ACK141a/cFETCHGSMLLC/ ACK141d/fFETCHGSMHLC/ ACK143bLOADDATACCMH / ACK

included if the terminating subscriber has the CLIP feature but the CLI cannot bepresented and if DBS parameter GSMMSSF:CAUSEOFNOCLIM allows thisparameter to be sent. Since the CLIP information is available in this example, theCause of no CLI parameter is not sent.143. MTBCC sends the BC received at step 140 to MCCMH to be packed inthe message with signal BEARERCAP1REQ1. MTBCC also asks block MTB toload data directly into MCCMH with combined signal LOADDATACCMH/ACK.MTB sends the CLIP information received at step 53, Calling Party BCD Numberparameter, with signal CALLINGNUMREQ.

Setup (Mobile Terminated) Parameters

The Setup (Mobile Terminated) message (3GPP TS 24.008 Rel. 5) contains nomandatory and several optional parameters. Only the parameters that MTBCC orMTB send or attempt to fetch are presented below.

• Bearer Capability 1 and 2 - is an optional parameter whose purpose is todescribe a bearer service. The reason this parameter appears twice isbecause an MS can indicate capability for an alternative call mode. Thebearer capability 1 information element may be omitted in the case where themobile subscriber is allocated only one directory number for all services• BC Repeat Indicator - is a conditional parameter whose purpose is toindicate how the associated repeated information elements shall beinterpreted. It is included if both Bearer Capability parameters are includedwithin the Setup (Mobile Terminated) message.• Low/High Layer Compatibility 1 - each is an optional parameter that isincluded when the calling MS wants to pass low/high layer compatibilityinformation to the called user. The purpose of the low/high layer compatibilityinformation is to provide a means to an addressed entity, i.e. called user, toperform compatibility checking.• Facility - an optional parameter that is included for functional operation ofsupplementary services. The parameter is an array of octets whoseinterpretation is defined in specification 3GPP TS 24.080 Rel. 5 "Mobile radiolayer 3 supplementary services specification, Formats and coding".• Calling Party Number - is an optional parameter which is used to identify thecalling party, i.e. CLIP feature.• Calling Party Subaddress - an optional parameter whose purpose is toidentify a subaddress associated with the origin of a call.• Called Party Subaddress - an optional parameter whose purpose is toidentify the subaddress of the called party of a call.• Cause of no CLI - an optional parameter whose purpose is to provide the MS

Page 56: Gsm Call Path Course

the detailed reason why the calling party BCD number is not provided.

144. MTBCC sends signal SENDRNMSG1 to order MCCMH to pack theDTAP-Setup (Mobile Terminated) and send it to the MS via the SCCP connectionon the A-interface. MCCMH allocates a CB4k and writes the Setup message intoit. MCCMH sends the message to MTBCC with signal RNOCOMREQCB.MTBCC, MMM and MRRM forward this signal downlink to MSCCO as a hurrysignal. MSCCO forwards this message to SCCOC with combined signal pairSCDATAREQCB/ACK. SCCOC along with other CCS blocks then ensure that

the Setup message is sent to the BSC over the SCCP connection. SCCOC alsoreleases the CB4k allocated by MCCMH above.Figure 29

CCSBSCSCCOCMSCCOMRRMMRRMHMMMMECMTVDTAP –Setup (Mobile Terminated Call Establishment)SCCP –DT1 (Data Form 1)145aSCDATAINDCB145bRNICOMINDCB144dRNOCOMREQCB144eRNOCOMREQCB144fSCDATAREQCB / ACKDTAP –Call ConfirmedSCCP –DT1 (Data Form 1)145cRNICOMINDCB145dRNICOMINDCBMRRMASGMRRMHOAt this point, the CM level waits for the DTAP-Call Confirmed message to arrivefrom the MS.

145. The Call Confirmed message is connection oriented, so its contents areprovided by SCCOC in a newly allocated CB4k to MSCCO with direct signalSCDATAINDCB. Note that at this point the MMS subsystem does not yet knowthe message type. The message is then forwarded to MRRM with signalRNICOMINDCB. This signal contains the discrimination parameter, whichindicates 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 ahurry signal. MMM reads the protocol discriminator, which indicates it is a CC(Call Control) type message hence belonging to the CM level. Therefore, MMMforwards the message uplink to MTBCC also with RNICOMINDCB as a hurrysignal. MTBCC immediately forwards this same signal as a hurry signal toMCCMH for unpacking. MCCMH transfers the content of the CB4k to its owninternal buffers and releases the CB4k. It then analyzes the message for anyerrors or missing mandatory information elements and reports that the messageis approved with signal RECEIVERNMSG1.

Page 57: Gsm Call Path Course

This page is intentionally left blank.

Figure 30146. MTBCC begins to read the parameters within the DTAP-Call Confirmedmessage. MTBCC requests the parameters one at a time, always with combinedforward signal FETCHIE to MCCMH. The requested parameter is determined bya data word within this signal. The combined backward signal returned byMCCMH depends on the parameter requested. The 6 requested parametersalong with their combined backward signal name are the following: StreamIdentifier STREAMIDIND, BC Repeat Indicator REPEATIND, Bearer Capability 1BEARCAP1IND2, Bearer Capability 2 BEARCAP2IND2, Supported Codec ListSUPPCODECIND and Cause CAUSEIND. Since all the necessary parametershave been read, MTBCC releases the buffered message in MCCMH with signalCLEARBUFF1. Note that only the Bearer Capability 1 is received in this example.

MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMTBSS147aFORWARDPLMNBC148aABCMTCCONF1151aABCMTCCONF1RMCSE145fRECEIVERNMSG1145dRNICOMINDB145eRNICOMINDCB146a/c/…FETCHIE(5 times)146bSTREAMIDIND146fBEARCAP1IND2146dREPEATIND146hBEARCAP2IND2146jSUPPCODECIND146mCLEARBUFF1147bFORWARDPLMNBC148bABCMTCCONF1147cFRWARDPLMNBC151bABCMTCCONF1R152aUABCMTCCONF154cUABCMTCCONFR152bUABCMTCCONF154bUABCMTCCONFR152cUABCMTCCONF154aUABCMTCCONFRMRRMHMTECA155bGETACCESS / ACK156b/dGETACCESS / ACK156cGETACCESS / ACK156a/eGETACCESS/ACK155a/cGETACCESS / ACK146lCAUSEIND149MMAINTSA1/ACK150MBCOMPANA1/ ACK152dUMMAINTSA1/ACK153UMBCOMPANA/ACKMTBCOMCEDHCNote that unlike the RR and MM layer message handlers, MCCMH does notprovide a list of received optional parameters at unpacking and thus MTBCCmust 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 mandatoryand several optional parameters. Only the parameters that MTBCC attempts toread are presented below.

• Stream Identifier - an optional parameter whose purpose is to associate aparticular call with a Radio Access Bearer (RAB) when an MS supportsmulticall.• Bearer Capability 1 and 2 - is a mandatory parameter whose purpose is to

Page 58: Gsm Call Path Course

describe a bearer service. The Bearer Capability information element is used

for compatibility checking. The reason this parameter appears twice isbecause an MS can indicate capability for an alternative call mode. Referspecifications to see in which scenarios BC1 must be included• Repeat Indicator - is a conditional parameter whose purpose is to indicatehow the associated repeated information elements shall be interpreted. It isincluded if both Bearer Capability parameters are included within the CallConfirmed message.• Supported Codec List - is a conditional parameter whose purpose is toprovide the network with information about the speech codecs supported bythe MS.• Cause - The purpose of the cause information element is to describe thereason for generating certain messages, to provide diagnostic information inthe event of procedural errors and to indicate the location of the causeoriginator.

147. When MTBCC receive the Bearer Capability 1 parameter above, itforwards this parameter to MTB with signal FORWARDPLMNBC. MTB forwardsthis signal to MABC which forwards it onwards to MUABC. Both the MABC andMUABC individuals store the MS’s bearer capabilities so that they can be usedlater at analysis of bearer capabilities.148. MTBCC orders the negotiation of the GSM/PLMN BCs with signalABCMTCCONF1 to MABC via MTB. At this point MABC checks for compatibilitybetween the BC received from the network and the one received in the the CallConfirmed 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 beteleservice ‘telephony’. MABC then asks MTECA to analyze telecommunicationservices based on the BASC with combined signal pair MMAINTSA1/ACK.MTECA determines whether the telecommunication service requested by the MSis 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 (WantedSIGnalling) and TMR (Transmission Medium Requirements) between theoriginating and terminating ends are compatible. The combined signal pair usedfor compatibility analysis is MBCOMPANA1/ACK.151. MABC then performs a subscription check to determine if the MS issubscribed to the BASC required for this call. MABC previously fetched the MS’ssubscribed BASC list at step 44 above. MABC returns the final result of analysisof bearer capabilities (after the Call Confirmed message) in signalABCMTCCONF1R to MTBCC via MTB.152. MTBCC then repeats the analysis of bearer capabilities (after the Call

Page 59: Gsm Call Path Course

Confirmed message) for UMTS with signal UABCMTCCONF to MUABC via MTBand MABC. MUABC also generates a BASC (BAsic Service Code) and asksMTECA to analyze telecommunication services based on the BASC withcombined signal pair UMMAINTSA1/ACK.153. MUABC goes back to MTECA to determine if the WSIG (WantedSIGnalling) and TMR (Transmission Medium Requirements) between the

originating and terminating ends are compatible. The combined signal pair usedfor compatibility analysis is UMBCOMPANA/ACK.154. MUABC performs a subscription check to determine if the MS issubscribed to the BASC required for this call on UMTS. MUABC previouslyfetched the MS’s subscribed BASC list at step 47 above. MUABC returns thefinal result of analysis of bearer capabilities (after the Call Confirmed message) insignal UABCMTCCONFR to MTBCC via MABC and MTB.155. MTBCC then fetches the current access type (GSM or UMTS) fromMRRM with combined signal pair GETACCESS/ACK via MMM. Since the accessis still GSM and the analysis of bearer capabilities for GSM succeeded, MTBCCproceeds with call setup.6.3.4.10 Channel Assignment

Figure 31156. When MTB transits signal UABCMTCCONFR at step 152 above, it alsofetches the current access type (GSM or UMTS) from MRRM with combinedsignal pair GETACCESS/ACK via MMM and MTBCC. MTB needs this data tofetch the appropriate subscriber service data related to the BASC, the GSMBASC in this case. This is done by sending signal GETNEWBGDATA to MTBSS.MTBSS sends combined signal pair FETCHSSBSG/ACK to MTV, which sendsnested combined signal pair FETCHSTBSG/ACK to MTVS. Among the datareturned to MTB with signal GETNEWBGDATAR is: no reply timer, CUGinformation and an indication of whether call forwarding may occur. Note some ofthis data was already fetched at step 49 above but is fetched again in case theaccess type changed.

MMMMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMTBSSMCSE156fGETNEWBGDATA160aASSIGNMENT1MTVS156hFETCHSTBSG / ACK156jGETNEWBGDATAR158aFETCHTCHDAT3/ACK158cFETCHRABDATA2/ ACK159GETSSVDATA / ACK160bASSIGNMENT1MRRMHCOMAINRMPSeize 2SwitchingSwitch Views156g/iFETCHSSBSG/ ACK158b/dFETCHRABDATA2/ ACK

Page 60: Gsm Call Path Course

MTBCO157aREPMONIEVENT157bREPMONIEVENTRMRRMHOMRRMASG161bASSIGNMENT1161aASSIGNMENT1MCEDHC

157. MTB reports the fact that MS data for this mobile terminating call is nowavailable to MTBCO with signal REPMONIEVENT. MTBCO needs thisinformation in case that monitoring of the subscriber is active. Since this is notthe case, MTBCO immediately returns signal REPMONIEVENTR with asuccessful indication so that MTB can proceed.158. MTB begins preparing the sending of the BSSMAP-Assignment Requestmessage. Since the RR layer packs this message and lots of data needs to betransferred downlink via the call path, MTB seizes a CB128 to facilitate the transferof this information. MTB then reads traffic channel data for traffic channelassignment from MABC with combined signal pair FETCHTCHDAT3/ACK.Having previously determined during analysis of BCs that this is a simple speechcall, MABC sets certain traffic channel data values for speech and returns otherdata such as allowed speech coder version information. MTB fetches the UMTSassignment data from MUABC via MABC with combined signal pairFETCHRABDATA2/ACK. MTB stores whatever valid data it receives in theCB128.159. MTB then fetches the SSV (Switching Switch View) data from MCSEwith combined signal pair GETSSVDATA/ACK. MTB is interested in the downlinklogical channel of the SSV seized at step 50, so that it can pass this informationdownlink so that other SSVs can join to it.160. MTB then orders the sending of the BSSMAP-Assignment Requestmessage with signal ASSIGNMENT1 to block MTBCC, which transits the signaldownlink to MMM. Among the data in this signal is the CB128 pointer, grantedeMLPP, and the downlink MSS SSV logical channel acquired in the previousstep.161. Before transiting the ASSIGNMENT1 signal, the MMM individual seizestwo SSVs via block COMAIN in the RMP (Resource Module Platform). Refer to“Connection Service (CSE)” service specification document for details on thisprocess. Both SSVs are seized as two-way connections. The first SSV seized isjoined to the downlink logical channel of the MSS SSV seized by MCSE, whilethe second SSV seized by MMM is joined to the first. MMM seizes two SSVs tofacilitate the insertion of other SVs without disturbing the uplink or downlink SVs.For example, in case of speech monitoring, the RES subsystem seizes twoMSVs (Monitoring Switch Views) and links them in between MMM’s two SSVs.MMM then transits signal ASSIGNMENT1 to MRRM which forwards it onwards toMRRMASG.

Figure 32162. Upon receiving signal ASSIGNMENT1, MRRMASG uses the CB128pointer provided in the signal to read the traffic channel data stored by MTB in

Page 61: Gsm Call Path Course

this CB128. MRRMASG then asks MEPPA with combined signalGETASSIGNINF/ACK to provide the priority information corresponding togranted EMLPP priority level. MRRMASG then asks MBSSD to translate theBSC pointer to the corresponding incoming and outgoing route numbers withcombined signal pair BSCPTORTE/ACK. Note that MBSSD provides both localand remote route pointers and MALT references to MRRMASG. MRRMASG thenselect either local or remote values depending of the MGW type selected(combined or remote). MRRMASG forwards these route pointers to MRRM withcombined signal pair STOREBSCROUTEP/ACK. MRRMASG then asks MBSSDto provide certain BSC characteristics with combined signal pairBSCTOBSCDATA/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 SEIZEALT2to block MALTM59, ordering the seizure of a MALT device on the appropriateroute. MRRMASG determined the route to the BSC at step 162. MALTM thenselects an idle device on this route.

MSCCOMRRMMRRMHMMMCOMAINRMPMRRMASGSCCOCCCSBSCMTBCCMCCMHMCCPHMALTM163SEIZEALT2165aALTSEIZED3164a/eASKSVDATA/ R165bFREESVDATA164cASKSVDATA / RMEPPAMBSSD162dBSCTOBSCDATA / ACK162bBSCPTORTE / ACK162eBSCTOBSCDATA / ACK161bASSIGNMENT1162cSTOREBSCROUTEP / ACK165cFREESVDATA165dFREESVDATAMRRMHO162aGETASSIGNINF / ACKSeize anAccessSwitch View164b/dASKSVDATA/ R59 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 ofmessages 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 associatedhardware varies: MALTM, MALNA51, MALT4, etc.

164. At this point, MALTM needs to seize an ASV (Access Switch View) viablock COMAIN in the RMP and also needs to connect this switch view to theneighbouring uplink SSV. Therefore, MALTM asks MMM for the identity of theneighbouring SSV and its downlink logical channel with signal pair ASKSVDATAvia MRRMASG and MRRM. Once this information is received in return signal

Page 62: Gsm Call Path Course

ASKSVDATAR, MALTM orders the seizure of an ASV with a two-way connectionand 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 toMRRMASG as a response to SEIZEALT2 at step 163 and thus establishing a linkto the MRRMASG individual. Furthermore, MALTM also sends signalFREESVDATA to MMM via MRRMASG and MRRM. This signal allows MMM toanswer any buffered ASKSVDATA request that may have come in after the onefrom MALTM at step 164. The reason for buffering subsequent requests for SVdata is to prevent a situation where more than one SV manipulation is ongoing atthe same time, which would cause corruption in the linking of SVs.

Figure 33166. Since MRRMASG is about to send the BSSMAP-Assignment Requestmessage which will require a change of channel on the air interface and thus asmall interruption of the connection to the MS, it asks the uplink to temporarilystop sending any DTAP messages with signal STOPDTAPMSG. Upon receivingthis signal, both MMM and MTBCC flag this stop DTAP message indication.Before replying MTBCC sends itself a CONTINUEB signal to allow the messagehandler (MCCMH) to get rid of any buffered signals. Signal STOPDTAPMSGR isreturned to MRRMASG as an acknowledgement. MRRMASG also asks MRRMto suspend any ongoing location services during the channel assignment withcombined signal pairs SUSPENDLCS/ACK and SUSPENDLCSR9/ACK.167. MRRMASG initiates the building of the BSSMAP-Assignment Requestmessage by sending to MRRMH the Channel Type mandatory informationelement with combined signal pair RRCHTYPOUT1/ACK. In this example, a fullrate or half rate speech channel with full rate preferred is requested. The Layer 3Header and Priority optional information elements are sent with combined signalpairs RRLAY3HDOUT/ACK and RRPRIORITOUT/ACK. Since a MALT device isused for this call, the CIC (Circuit Identity Code) information element is requiredand sent with combined signal pair RRCICOUT/ACK. MRRMASG sends theDownlink DTX Flag parameter with combined signal pair RRDTXFLAGOUT/ACK.Once all the information elements are forwarded for packing, MRRMASG ordersMRRMH to send the connection oriented BSSMAP message to SCCP with directsignal SENDBSSMAPCO.

MSCCOMRRMHMMM168bRNOCOMREQCB166bSTOPDTAPMSGMRRMASGSCCOCCCSBSCDTAP –Assignment RequestSCCP –DT1 (Data Form 1)MTBCCMCCMHMCCPH166fSTOPDTAPMSGR166cSTOPDTAPMSG166eSTOPDTAPMSGR168cSCDATAREQCB/ ACK

Page 63: Gsm Call Path Course

167bRRLAY3HDOUT / ACK167cRRPRIORITOUT / ACK167dRRCICOUT / ACK167eRRDTXFLAGOUT / ACK168aRNOCOMREQCBMALTMMEC166gSTOPDTAPMSGR166hSUSPENDLCS / ACK166iSUSPENDLCSR9 / ACK166dCONTINUEB167aRRCHTYPOUT1 / ACK167fSENDBSSMAPCOMRRM166aSTOPDTAPMSGNote that MRRMASG sends signals directly to MRRMH and not via MRRM. Thisis because MRRMASG has a direct link to MRRMH that was established at step82 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 1mandatory and several optional parameters, some of which are included below:

• Channel Type - This element is a mandatory parameter that contains all ofthe information that the BSS requires to determine the required radioresource.• Layer 3 Header Information - An optional parameter, that providesinformation the BSS needs over the air interface; however, it no longerserves any useful purpose unless the BSS requires it for backwardcompatibility.• Priority - Indicates the priority level of the request and whether pre-emptionand queuing are allowed• CIC - A previously agreed upon number between the MSC and BSC atcommissioning, which uniquely defines the terrestrial channel over which thecall will pass.• Downlink DTX Flag - indicates whether the DTX (DiscontinuousTransmission) function in the BSS is to be disabled on a particular radiochannel.

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

Figure 34169. When the BSC receives the Assignment Request message, it selects the

Page 64: Gsm Call Path Course

appropriate radio resources and ensures the MS is available on this new trafficchannel. The BSC also ensures that the terrestrial (trunk) resources on the A-interface are set up. The BSC responds with a BSSMAP- Assignment Completemessage on the A-interface to the MSC. This message is connection oriented, soits contents are provided by SCCOC in a newly allocated CB4k to MSCCO withdirect signal SCDATAINDCB. Note that at this point the MMS subsystem doesnot yet know the message type. The message is then forwarded to MRRM withsignal RNICOMINDCB. This signal contains the discrimination parameter, whichindicates it is a BSSMAP type message. Therefore, MRRM forwards themessage to MRRMH, also with RNICOMINDCB but as a hurry signal, foranalysis and unpacking. MRRMH transfers the content of the CB4k to its owninternal buffers and then analyzes the message by first determining the messagetype and then checking for any formatting errors. MRRMH releases the CB4k andthen reports its result as well a list of received optional parameters to MRRM withhurry signal RCVBSSMAPCO1, which in this example includes the BSSMAPmessage type of Assignment Complete.170. MRRM forwards the message analysis results to MRRMASG with signalASSIGNCOMPLR. Since the message was successfully analyzed by MRRMH,MRRMASG asks MRRMH to unpack the contents of the message. There are nomandatory parameters in the Assignment Complete message and only twooptional parameters were received in this example. MRRMASG reads theChosen Channel and Chosen Speech Version parameters with combined signalpairs RRCHOSECHIN/ACK and RRSPEECHVIN/ACK. MRRMASG also asksMBSSD to provide certain BSC characteristics (BCIC, circuit pool function) withcombined signal pair BSCTOBSCDATA/ACK.

MSCCOMRRMHMMMMECSCCOCCCSBSCDTAP –Assignment CompleteSCCP –DT1 (Data Form 1)MTBCCMCCMHMCCPH169aSCDATAINDCB169cRNICOMINDCBMBSSD172cASSIGNCOMPL6173cSTARTDTAPMSG172dASSIGNCOMPL6MRRMASGMALTM173eASGPROCEEDLCS170bRRCHOSECHIN / ACK170cBSCTOBSCDATA / ACK171aCGITOORG171bCGITOORGR173dCLEARRRMH173aSTARTDTAPMSGAS169dRCVBSSMAPCO1170dRRSPEECHVIN / ACKMRRM169bRNICOMINDCB173bSTARTDTAPMSG172bASSIGNCOMPL6170aASSIGNCOMPLR172aASSIGNCOMPL6

171. MRRMASG then sends the CGI to MBSSD and asks it to determine theCO (Charging Origin) associated to the cell with signal pair CGITOORG/R. Thisinformation is forwarded to the uplink via the CB128 in the next step.

Assignment Complete Parameters

Page 65: Gsm Call Path Course

The Assignment Complete message (3GPP TS 48.008 Rel. 5) contains nomandatory and several optional parameters, some of which are included below:

• Chosen Channel - is an optional parameter that contains a description of thechannel allocated to the MS on the air interface.• Chosen Speech Version - indicates the speech version being used by theBSS. Always included when the speech coder version choice was done bythe BSS.

172. MRRMASG informs the uplink, via MRRM, of the Assignment Completemessage with signal ASSIGNCOMPL6. MRRM forwards the signal to MTB viaMMM and MTBCC. This is the successful response to signal ASSIGNMENT1from step 160 above. MRRMASG transfers the Assignment Complete messagedata to the uplink within the same CB128 that was used in the ASSIGNMENT1signal to the downlink.173. MRRMASG also sends signal STARTDTAPMSGAS to the MRRM sothat DTAP messages can once again be sent if required, now that the MS isconnected on a new traffic channel. MRRM in turn sends signalSTARTDTAPMSG to the uplink to undo the DTAP buffering that was initiated atstep 166 above. At the same time MRRM also asks MRRMH to clear themessage from its buffer with signal CLEARRRMH. MRRMASG also sends signalASGPROCEEDLCS so that MRRM may resume any ongoing location services.This signal is the counterpart to signal SUSPENDLSC at step 166 above.

Figure 35174. When MTB receives signal ASSIGNCOMPL6, it forwards traffic channelinformation to MABC with forward combined signal FWDCHANNINF1. MABCreturns charging information regarding assigned radio characteristics and IWF(Interworking Function) parameters in backward combined signalFWDCHANNINF1ACK. At this point MTB releases the CB128 whose pointer wascontained within signal ASSIGNCOMPL6. MTB also stops the not reachabletimer that it started at step 67.175. MTB reads the time at which the channel assignment was completedwith combined signal pair TIME/ACK to block JOB60. MTB then reports acharging event to MTBCO with signal REPCHGCCC. This signal instructsMTBCO to provision charging analysis input data.176. MTBCO begins by using destination dependent analysis, which isperformed by block IA61 within the TRAM, to determine the CC (Charging Case)for the airtime charging. However, communication with this service is inter-AM

Page 66: Gsm Call Path Course

MTBMABCMTBCCMCCMHMUABCMCCPHMCLMTHMTBCOMCSEMCEDHC172dASSIGNCOMPL6174FWDCHANNINF1 / ACKCLMTRMPMTBSS178bREADMMSISDN / ACK180bREADMMSISDN / ACKCHVIEWRMPStore publiccharging data184READYFORALERTMOIPHI176bSEIZEMCLMTHR176aSEIZEMCLMTH179aCLMANAFUNC1179bCLMANAFUNCR180dCLMANUMANA180eCLMANUMANAR177a/cGETACCESS/ACK181a/cGETACCESS/ACK177bGETACCESS / ACK to MRRM181bGETACCESS / ACK to MRRM178a/cMREADMMSISDN/ ACK180a/cMREADMMSISDN/ ACK175bREPCHGCCC182CHGANALDATA / ACK183bREPCHGCCCR183aDISCMCLMTH / RMCIWFJOB175aTIME / ACKTRAMIAIAIAIAMCLMTH60 JOB – JOB monitor

JOB is an APZ block that is a part of the operative system kernel and the subsystem CPS (CentralProcessor Subsystem). The block handles the system calendar, time zones, supervision of programexecution, processor load measurements, the administration of the time queues and the jobtable anda 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 andbarring analysis. A user subscribes to analysis results of interest and IA then sends these results tothe 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, MTBCOseizes block MCLMTH63 that will facilitate the connectionless interface with theRMP. An MCLMTH is seized with signal pair SEIZEMCLMTH/R.177. MTBCO also fetches the current access type (GSM or UMTS) fromMRRM with combined signal pair GETACCESS/ACK via MMM, MTBCC andMTB. 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 pairMREADMMSISDN/ACK, which MTB reads from MTBSS with nested combinedsignal pair READMMSISDN/ACK.179. MTBCO then sends signal CLMANAFUNC1 to MCLMTH, which includesthe MSISDN, the BO (B-number Origin, defined on MTB route) as well as fewother parameters. This signal indicates that MTBCO is interested in any CC thatis encountered during analysis. Once B-number analysis is completed, the result

Page 67: Gsm Call Path Course

is returned in signal CLMANAFUNCR with an indication that a CC wasencountered. 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 step178 above, but this time for A-number analysis so that an ACO (A-ChargingOrigin) can be determined. This done with signal CLMANUMANA to MCLMTH,which includes the MSISDN. Once A-number analysis is completed, the result isreturned 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, MTBCCand MTB. MTBCO needs this data so that it may provide the appropriateparameters as input data for charging analysis in the next step.182. MTBCO then provides the necessary charging analysis input data, suchas CC and ACO, to MCEDHC with combined forward signal CHGANALDATA.MCEDHC stores this data and returns combined backward signalCHGANALDATAACK. At this point, MCEDHC writes some of this data as publiccharging data in CHVIEW. Public charging data is data that can be stored in acharging view by any user and is accessible to all users. This makes it possiblefor users to exchange some charging data between them.183. MTBCO no longer requires the connectionless interface to TRAM sinceall analyses are complete. Therefore the MCLMTH individual is disconnected bymeans of signal pair DISCMCLMTH/R. MTBCO also returns a successfulindication to MTB with signal REPCHGCCCR, indicating that charging analysiswas successful.

62 CLMT – ConnectionLess Message Transfer service

CLMT is an RMP block that provides a connectionless message transfer service in APSI. This serviceallow a user in an AM to transfer messages towards a specified user. The messages are ofconnection less type, i.e. no logical connection (on session level) has to be established between thetwo 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 forseveral analysis functions in TRAM which use the connectionless message transfer service of RMPas bearer.

184. MTB then informs MTBCC with signal READYFORALERT that it iswaiting for the DTAP-Alerting message before it can proceed with the callestablishment.

Page 68: Gsm Call Path Course

6.3.4.11 Alerting Message Received, OIP-ACM Sent

Figure 36185. The DTAP-Alerting message is connection oriented, so its contents areprovided by SCCOC in a newly allocated CB4k to MSCCO with direct signalSCDATAINDCB. Note that at this point the MMS subsystem does not yet knowthe message type. The message is then forwarded to MRRM with signalRNICOMINDCB. This signal contains the discrimination parameter, whichindicates 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 ahurry signal. MMM reads the protocol discriminator, which indicates it is a CC(Call Control) type message hence belonging to the CM level. Therefore, MMMforwards the message uplink to MTBCC also with RNICOMINDCB as a hurrysignal. MTBCC immediately forwards this same signal as a hurry signal toMCCMH for unpacking. MCCMH transfers the content of the CB4k to its owninternal buffers and releases the CB4k. It then analyzes the message for anyerrors or missing mandatory information elements and reports that the messageis approved with signal RECEIVERNMSG1.186. The only parameter that MTBCC attempts to read within the DTAP-Alerting message is the Facility parameter. MTBCC asks MCPPH, via MCCMH,to fetch the Facility information element with combined forward signalFETCHFACIE. Since no Facility parameter was received in the Alertingmessage, MCPPH responds with combined backward signal NOMORECOMP. If

MSCCOMRRMMRRMHMMMMEC185bRNICOMINDCBSCCOCCCSBSCDTAP –AlertingSCCP –DT1 (Data Form 1)MTBCCMCCMHMCCPH185aSCDATAINDCB185eRNICOMINDCB185cRNICOMINDCB185dRNICOMINDCB185fRECEIVERNMSG1186bFETCHFACIE / ACK186a/cFETCHFACIE/ ACK186dCLEARBUFF1MRRMASGMALTMMRRMHO

the Facility parameter had been received, then MCCMH would have forwarded itto MCPPH for validation analysis at step 185 above. Since all the necessaryparameters have been read, MTBCC releases the buffered message in MCCMHwith signal CLEARBUFF1.

Alerting (MS to Network) Parameters

The Alerting message (3GPP TS 24.008 Rel. 5) contains no mandatory andseveral optional parameters. Only the parameters that MTBCC attempts to readare presented below.

Page 69: Gsm Call Path Course

• Facility - an optional parameter that is included for functional operation ofsupplementary services. The parameter is an array of octets whoseinterpretation is defined in specification 3GPP TS 24.080 Rel. 5 "Mobile radiolayer 3 supplementary services specification, Formats and coding".

Figure 37187. As a parallel process to the call set up, MTBCC checks if the networkinitiated TAI (Tariff Area Indication) is active in the MSC. This information isavailable in block MTBSS (DBS parameter GSMMSSF:MSCNF1157) and isaccessed with combined signal pair CHCKSSINVOKE/ACK via MTB. Since thefeature is active within the MSC, MTBCC reads the regional service data andIMSI that will be used for the TAI. The data is read from MTB with combinedsignal pair FETCHTAIDATA/ACK. MTBCC then asks block MUATAI64 with signalTAINWINDICATE to check if a network initiated TAI is required for this call. Inthis example, MUATAI determines that no indication is required, so this parallelprocess ends here. The purpose of this function is to provide the mobilesubscriber with an indication about the relevant tariff area. For more informationon this feature see FS “Indication of Tariff Area to Mobile Subscriber in MSC/VLRserver”.188. MTBCC informs MTB about the reception of the DTAP-Alerting messagewith signal MBSUBFREE. This signal prompts MTB to generate an ACM(Address Complete Message) backwards in the call path and inform its side linksof the ACM.

MMMMECMTBMABCMTBCCMCCMHMTVMUABCMCCPHMRRMMCSEMTBCOMTBSSMCEDHC188MBSUBFREEMRRMHCharginganalysisMUATAI190SENDCALLEVENT187bCHCKSSINVOKE / ACK191fMSTARTINBANDCOMAINRMPStartringing tone187dFETCHTAIDATA / ACKCHVIEWRMP195dGETACCESS / ACK191cGETACCESS / ACK187a/cCHCKSSINVOKE / ACK191a/eGETACCESS / ACK191b/dGETACCESS / ACK195c/eGETACCESS/ ACK195b/fGETACCESS/ ACK187eTAINWINDICATE193aMSGREPORT193bMSGREPORT1R194CHGANALRES/ ACKMTTEC189STOPTIMERS192MMSGBUF195a/gGETACCESS/ACKSince MTB initiates two parallel processes, the signal order in the next two stepsis 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

Page 70: Gsm Call Path Course

MTACC/MTBCC during call setup and a request received from the USSD platform. It determines theappropriate 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 abovewith signal MSTOPTTIMERS. These timers did not get a chance to time outsince the call is promptly delivered to the B-subscriber.190. MTB informs MCSE of the ACM event by sending signalSENDCALLEVENT. The signal is not acted upon by MCSE since the speechpath in this example will only be established with the ANM event. MCSE uses theDBS parameter GSMMSSC:TCONTYPE to determine when to set up a two-wayspeech path, at the ACM or ANM event.191. MTB also fetches the current access type (GSM or UMTS) from MRRMwith combined signal pair GETACCESS/ACK via MMM and MTBCC. MTB needsthis data to determine the appropriate TPI (Tone Protection Information) for thisaccess type, GSM or UMTS. The TPI determines if tone sending is allowed forthis call. The TPI for GSM access was determined as part of the analysis ofbearer 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 signalMSTARTINBAND. This prompts MCSE to order a ringing tone via the uplinkchannel of the second SSV that it previously seized at step 50.192. MTB then seizes a CB4k (Communication Buffer) and begins building theOIP-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 onwardsto MTBCO for distribution with signal MMSGBUF.193. MTBCO first distributes the CB4k pointer of the OIP-ACM message toMCEDHC with signal MSGREPORT, so that MCEDHC can read the necessarycharging data from the OIP-ACM. MCEDHC stores and then reads publiccharging data to and from the charging view. MCEDHC initiates the charginganalysis on the CC (Charging Case) it stored at step 182, by storing the ‘analysisindicator’ as public data in the charging view. The result of the charging analysisis communicated to MCEDHC also via the public charging data ‘analysis result’.Note that MCEDHC subscribed to this public data at step 56 above. OnceMCEDHC finishes with this process, MCEDHC returns signal MSGREPORT1Rto 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) fromMRRM with combined signal pair GETACCESS/ACK via MMM, MTBCC andMTB. This time MTBCO needs this data to send the appropriate charging data toMCEDHC at step 197 below.

Page 71: Gsm Call Path Course

Figure 38

MOIPHIAPCRMPTRACOTRAM202bAPCDATACBINDOIPACMMTBMAPTCMABCMUABCMTBCCMCCMHMCCPHMTBSSTRANMCSEMTBCO196c/eMREADMMSISDN/ACKMCEDHCCHVIEWRMP197aSENDCCCDATA(12 times)197bSENDCCCDATAEND 202aAPCDATACBREQ197cSENDCCCDATAENDR198aMMSG198bMMSGR196dREADMMSISDN / ACK199REQAOCDATA / R201aMSENDBWDMSGMTTEC201bMBWDMSG / ACK200READYFORCONNECT203aREPORTTONEANNC203bREPORTTONEANNC196aNODENOREQ/ ACK196bTRAGLROUTENO/ ACKSince MTB and MTBCO initiate several parallel processes, the signal order in thenext five steps is not maintained.

196. MTBCO collects charging data from its side links with the followingcombined signal pairs. It fetches the international MSC/VLR number (own callingaddress, command MGCA_) with NODENOREQ/ACK to MAPTC. MTBCO thenasks block TRAN to translate the outgoing global route number, acquired at step138, into a global route name with TRAGLROUTENO/ACK. MTBCO requests theMSISDN from MTB with combined signal pair MREADMMSISDN/ACK, whichMTB reads from MTBSS with nested combined signal pairREADMMSISDN/ACK. This data will be sent to MCEDHC in the next step.197. MTBCO then proceeds to send this recently collected data as well asother data to MCEDHC with a series of SENDCCCDATA signals. In thisexample, 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 routename and more. Once finished sending information, MTB sends signalSENDCCCDATAEND and MCEDHC replies with signal SENDCCCDATAENDR.198. MTBCO then distributes the OIP-ACM message back to MTB with signalMMSG. MTB immediately returns control of the message to MTBCO for furtherdistribution with signal MMSGR before performing a few actions.199. The previous step prompts MTB to request the AOC information withsignal REQAOCDATA. In this example, MTBSS responds with REQAOCDATARindication AOC is not active. If AOC were active, then MTBSS would interact with

several blocks to determine the various elements of AOC. For more informationon this feature see FS “Advice of Charge in MSC/VLR Server”.200. MTB also sends the READYFORCONNECT signal to MTBCC informingit that it is now ready to receive the connect indication. Since the Connectmessage has not yet been received, MTBCC notes this fact and exits.201. After receiving signal MMSGR from MTB (step 198), MTBCO determinesthat there are no more blocks to distribute the message to. Therefore MTBCOsends the OIP-ACM message to MOIPHI with signal MSENDBWDMSG. MOIPHI

Page 72: Gsm Call Path Course

informs its side link MTTEC of the OIP-ACM message with forward combinedsignal MBWDMSG. MTTEC decides whether or not to buffer the message basedon 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 inbackward combined signal MBWDMSGACK.202. MOIPHI sends the OIP-ACM message via the APC session with signalAPCDATACBREQ specifying the message type, CB4k and session ID. APCsimply transits this data to the TRACO individual within the TRAM with signalAPCDATACBIND.

The TRAM analyzes the OIP-ACM and if successful propagates it backwardsthrough the call chain. The OIP-ACM and any equivalent message in otherprotocols, such as an ISUP ACM, inform the incoming call chain that the B-subscriber was successfully identified and that ringing has started, thus throughconnection is required.

203. At step 191 above, MTB initiated the start of the ringing tone. Once thetone is started, MCSE replies back to MTB with signal REPORTTONEANNC,which MTB transits to MTBCO. MTBCO only acts on this signal when thesubscriber is being monitored.

The reason this signal is returned much later is because it involvescommunicating with hardware, thus implying an independent processor. In thisexample, signal REPORTTONEANNC entered MTB at this point but it isimportant to note that it could have entered sooner or later depending on thenature of the hardware interaction.

6.3.4.12 Connect Message Received, OIP-ANM Sent

Figure 39204. The DTAP-Connect message is connection oriented, so its contents areprovided by SCCOC in a newly allocated CB4k to MSCCO with direct signalSCDATAINDCB. The message is then forwarded to MRRM with signalRNICOMINDCB. This signal contains the discrimination parameter, whichindicates 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 ahurry signal. MMM reads the protocol discriminator, which indicates it is a CC(Call Control) type message hence belonging to the CM level. Therefore, MMMforwards the message uplink to MTBCC also with RNICOMINDCB as a hurrysignal. MTBCC immediately forward this same signal as a hurry signal toMCCMH for unpacking. MCCMH transfers the content of the CB4k to its owninternal buffers and releases the CB4k. It then analyzes the message for any

Page 73: Gsm Call Path Course

errors or missing mandatory information elements and reports that the messageis approved with signal RECEIVERNMSG1.205. MTBCC attempts to read two optional parameters within the DTAP-Connect message even though no parameters were received in this example. Itfirst requests the Connected Subaddress with combined signalFETCHIE/CONSUBADIND1. MTBCC asks MCPPH, via MCCMH, to fetch theFacility information element with combined forward signal FETCHFACIE. Sinceno Facility parameter was received in the Connect message, MCPPH respondswith combined backward signal NOMORECOMP. If the Facility parameter hadbeen received, then MCCMH would have forwarded it to MCPPH for validationanalysis at step 204 above. Since all the necessary parameters have been read,MTBCC releases the buffered message in MCCMH with signal CLEARBUFF1.

MSCCOMRRMMRRMHMMMMEC204bRNICOMINDCBSCCOCCCSBSCDTAP –ConnectSCCP –DT1 (Data Form 1)MTBCCMCCMHMCCPH204aSCDATAINDCB204eRNICOMINDCB206MBANSWER204cRNICOMINDCB204dRNICOMINDCB204fRECEIVERNMSG1205cFETCHFACIE / ACK205aFETCHIE /CONSUBADIND1205eCLEARBUFF1205b/dFETCHFACIE/ ACKMRRMASGMALTMMRRMHO

Connect (MS to Network) Parameters

The Connect message (3GPP TS 24.008 Rel. 5) is sent by the called mobilestation to the network to indicate call acceptance by the called user. The Connectmessage contains no mandatory and several optional parameters. Only theparameters that MTBCC attempts to read are presented below.

• Connected Subaddress - an optional parameter whose purpose is to identifya subaddress associated with the connected party of a call.• Facility - an optional parameter that is included for functional operation ofsupplementary services. The parameter is an array of octets whoseinterpretation is defined in specification 3GPP TS 24.080 Rel. 5 "Mobile radiolayer 3 supplementary services specification, Formats and coding".

206. MTBCC informs MTB of the connect/B-answer indication with signalMBANSWER. Now that that the call has been answered, MTB finally releasesthe OIP-IAM CB4k, received at step 29. MTB holds on to the OIP-IAM CB4k sinceit is required in case of call forwarding. Now that the call is answered, thepossibility of call forwarding is no longer an option.

Figure 40

Page 74: Gsm Call Path Course

MMMMECMTBMABCMTBCCMCCMHMUABCMCCPHMRRMMCSEMTBCOMTBSS206MBANSWER211SENDCALLEVENTMRRMH210MSTOPINBANDCOMAINRMPStopringing tone207cGETACCESS / ACKbothwayconnection207a/eGETACCESS / ACK207b/dGETACCESS / ACKMCEDHCLog allchargingdataCHVIEWRMP212aMSGREPORT212bMSGREPORT1R213aMMSG213bMMSGR209MMSGBUF208READMMSISDN / ACKSince MTB initiates several parallel processes, the signal order in the next fivesteps is not maintained.

MTB seizes a CB4k (Communication Buffer) and begins building the OIP-ANMmessage 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) fromMRRM with combined signal pair GETACCESS/ACK via MMM and MTBCC. Thistime MTB needs this data to determine the appropriate propagation delayparameter in the OIP-ANM message. The propagation delay is different betweenGSM and UMTS.208. MTB requests the MSISDN from MTBSS with combined signal pairREADMMSISDN/ACK. The MSISDN is included in the OIP-ANM message tosupport the SDLDC (Supervision and Disconnection of Long Duration Call)feature. See FS “Time Supervision and Disconnection of Long Duration Call” forinformation on this feature.209. MTB has finished building the OIP-ANM message and thus passes it toMTBCO for distribution with signal MMSGBUF.210. Since the call was answered, MTB orders MCSE to stop the ringing tonetowards the A-subscriber with signal MSTOPINBAND. MCSE then orders a stopto the ringing tone via the RMP through the same SSV used to start the ringingtone at step 191.

211. MTB then informs MCSE of the B-answer reception by sending signalSENDCALLEVENT with the event data set to ANM (ANswer Message). At thispoint, MCSE changes the second SSV it seized at step 50 to a two-way speechconnection. The speech path is established at the ANM event and not at theACM event because of DBS parameter TCONTYPE, see step 190 for moredetails.212. MTBCO first distributes the CB4k pointer of the OIP-ANM message toMCEDHC with signal MSGREPORT, so that MCEDHC can read the necessarycharging data from it. This prompts MCEDHC to log all the data it has collectedthus 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

Page 75: Gsm Call Path Course

MMSG. MTB immediately returns control of the message to MTBCO for furtherdistribution with signal MMSGR before performing a few actions.

Figure 41

MOIPHIAPCRMPTRACOTRAM218cAPCDATACBINDOIPANM218bAPCDATACBREQMTBMCSEMABCMUABCMTBCCMCCMHMCCPH214aSENDCALLEVENTMTBSS218aMSENDBWDMSGCEDHC216MCONNECTMSMCIWF214bSENDCALLEVENT215aALTEVENT1MTBCO217aCCSUPERVISIONMTV217bALLOWDISC / ACKMTTECOnce again since MTB initiates several parallel processes, the signal order in thenext few steps is not maintained.

214. The previous step prompts MTB to inform MCIWF via MCSE of the callsupervision event also with signal SENDCALLEVENT. MCIWF ignores this signalsince no IWF is seized for this call.215. MTB also sends signal ALTEVENT1 to the downlink in order to informthe MALT device that the call has been answered. Upon receiving this signal theMALTM individual marks the B-answer for seizure supervision purposes andincrements B-answer route counters.216. MTB orders the sending of the DTAP-Connect Acknowledge messagewith signal MCONNECTMS to MTBCC.217. MTB informs MTBSS with signal CCSUPERVISION that the CC-layerhas reached call supervision state. MTBSS sends combined signal pairALLOWDISC/ACK to MTV in order to remove the prevent disconnectionindication in MTV which it set at step 31 above.218. After receiving signal MMSGR from MTB (step 213), MTBCO determinesthat there are no more blocks to distribute the message to. Therefore MTBCOsends the OIP-ANM message to MOIPHI with signal MSENDBWDMSG. MOIPHIsends the OIP-ANM message via the APC session with signal APCDATACBREQspecifying the message type, CB4k and session ID. APC simply transits this datato the TRACO individual within the TRAM with signal APCDATACBIND.

The TRAM analyzes the OIP-ANM and if successful propagates it backwardsthrough 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 B-subscriber answered the call.

Figure 42219. MTBCC sends signal SENDRNMSG1 to order MCCMH to pack theDTAP-Connect Acknowledge message and send it to the MS via the SCCP

Page 76: Gsm Call Path Course

connection on the A-interface. MCCMH allocates a CB4k and writes the DTAP-Connect Acknowledge message into it. MCCMH sends the message to MTBCCwith signal RNOCOMREQCB. MTBCC, MMM and MRRM forward this signaldownlink to MSCCO as a hurry signal. MSCCO forwards this message toSCCOC with combined signal pair SCDATAREQCB/ACK. SCCOC along withother CCS blocks then ensure that the Connect Acknowledge message is sent tothe BSC over the SCCP connection. SCCOC also releases the CB4k allocated byMCCMH above

MSCCOMRRMMRRMHMMMMECSCCOCCCSBSCDTAP –Connect AcknowledgeSCCP –DT1 (Data Form 1)MTBCCMCCMHMCCPH219fSCDATAREQCB/ ACK215bALTEVENT1215cALTEVENT1215dALTEVENT1219aSENDRNMSG1219bRNOCOMREQCB219cRNOCOMREQCB219dRNOCOMREQCB219eRNOCOMREQCB216MCONNECTMSMRRMASGMALTM215eALTEVENT1MRRMHOConnect Acknowledge (Network to MS)

The Connect Acknowledge message (3GPP TS 24.008 Rel. 5) is sent by thenetwork to the called mobile station to indicate that the mobile station has beenawarded the call. The Connect Acknowledge message contains no parameters.

6.3.4.13 Mobile Terminated Call Path

MRRMMSCCOSCCOCMRRMHCCSBSCMMMMTBCCMCCMHMCPPHMTVMECMCSEMCIWFMALTMMRRMASGMRRMHOMTBMABCMUABCMTBSSMobileTerminatedCall PathMTBCOMCEDHCMOIPHIAPCRMPMTTEC