7 Functional requirements of network entities
23.0183GPPBasic call handlingRelease 17Technical realizationTS
The text in this clause is a supplement to the definition in the SDL diagrams; it does not duplicate the information in the SDL diagrams.
The entities described in this clause interwork with other entities over four different types of interface:
– The Iu interface, used to interwork between the MSC and the UTRAN or the UMTS UE;
– The A interface, used to interwork between the MSC and the GSM BSS or the GSM MS;
– The C, D & F interfaces, used to interwork between the MSC & HLR (C), VLR & HLR (D) and MSC & EIR (F);
– Telephony signalling interfaces, used to interwork between an MSC and another exchange.
The protocols used over the Iu interface are RANAP, which is specified in 3GPP TS 25.413 [27], for interworking with the UTRAN and DTAP, which is specified in 3GPP TS 24.008 [26], for interworking with the MS.
The protocols used over the A interface are BSSMAP, which is specified in 3GPP TS 48.008 [2], for interworking with the BSS and DTAP, which is specified in 3GPP TS 24.008 [26], for interworking with the MS.
The protocol used over the C, D & F interfaces is MAP, which is specified in 3GPP TS 29.002 [29].
For the purposes of the present document, the protocol used over telephony signalling interfaces is ISUP, which is specified in ITU‑T Recommendations Q.761[33], Q.762 [34], Q.763 [35] and Q.764 [36]; other telephony signalling systems may be used instead.
The present document shows the call handling application processes interworking with a protocol handler for each of the protocols listed above. Each protocol defines supervision timers. If a supervision timer expires before a distant entity responds to a signal, the handling is as defined in the appropriate protocol specification. In general, the protocol handler reports timer expiry to the application as an error condition or negative response. Where a timer is shown in the present document, therefore, it is an application timer rather than a protocol timer. Interworking with the protocol handlers uses functional signal names which do not necessarily have a one-to-one correspondence with the names of messages used in the protocols.
An MSC which receives an IAM from an originating exchange may react in three different ways:
– It acts as a transit exchange, i.e. it relays the IAM to a destination exchange determined by analysis of the called party address, and thereafter relays other telephony signalling between the originating and destination exchange until the connection is released. This behaviour is not specific to UMTS or GSM;
– It acts as a terminating exchange, i.e. it attempts to connect the call to an MS currently registered in the service area of the MSC;
– It acts as a GMSC, i.e. it interrogates an HLR for information to route the call. If the HLR returns routeing information, the MSC uses the routeing information from the HLR to construct an IAM, which it sends to a destination exchange determined by analysis of the routeing information from the HLR.
Annex A describes the method which the MSC uses to decide how to process the IAM.
The SDL diagrams in this clause show the handling for a number of optional features and services. If the handling consists only of a call to a procedure specific to the feature or service, the procedure call is omitted if the entity does not support an optional feature or service. If the handling consists of more than a call to a procedure specific to the feature or service, the text associated with each SDL diagram specifies the handling which applies if the entity does not support an optional feature or service. For simplicity of description, it is assumed that support for Operator Determined Barring and the Call Forwarding and Call Barring supplementary services is mandatory.