5 Overload and compatibility overview

29.0023GPPMobile Application Part (MAP) specificationRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Overload control

There is a requirement for an overload/congestion control for all entities of the Public Land Mobile Network and the underlying Signalling System No. 7.

5.1.1 Overload control for MSC (outside MAP)

For the entity MSC the following two procedures (outside MAP) may be applied to control the processor load:

– ISDN
CCITT Recommendation Q.764 (Automatic Congestion Control), applicable to reduce the mobile terminating traffic;

– BSSAP
3GPP TS 48.008 [49] (A-interface Flow Control), applicable to reduce the mobile originating traffic.

5.1.2 Overload control for MAP entities

For all MAP entities, especially the HLR, the following overload control method is applied.

If overload of a MAP entity is detected requests for certain MAP operations (see tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4) may be ignored by the responder. The decision as to which MAP Operations may be ignored is made by the MAP service provider and is based upon the priority of the application context.

Since most of the affected MAP operations are supervised in the originating entity by TC timers (medium) an additional delay effect is achieved for the incoming traffic.

If overload levels are applicable in the Location Registers the MAP operations should be discarded taking into account the priority of their application context (see table 5.1/1 for HLR, table 5.1/2 for MSC/VLR, table 5.1/3 for the SGSN and table 5.1/4 for the SMLC; the lowest priority is discarded first).

The ranking of priorities given in the tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4 is not normative. The tables can only be seen as a proposal that might be changed due to network operator/implementation matters.

Table 5.1/1: Priorities of Application Contexts for HLR as Responder

Responder = HLR Initiating Entity
Priority high
Mobility Management
networkLocUp VLR
(updateLocation),
(restoreData/v2),
(sendParameters/v1)
gprsLocationUpdate SGSN
(updateGPRSLocation/v3),
infoRetrieval VLR/SGSN
(sendAuthenticationInfo/v2/v3),
(sendParameters/v1)
istAlerting MSC
(istAlert/v3) msPurging VLR
(purgeMS/v2/v3)
msPurging SGSN
(purgeMS/v3)
Short Message Service
shortMsgGateway GMSC
(sendRoutingInfoforSM),
(reportSM-DeliveryStatus)
mwdMngt VLR/SGSN
(readyForSM/v2/v3),
(noteSubscriberPresent/v1)
Mobile Terminating Traffic
locInfoRetrieval GMSC
(sendRoutingInfo)
anyTimeEnquiry gsmSCF
(anyTimeInterrogation/v3)
reporting VLR
(statusReport)
Location Services
locationSvcGateway GMLC
(sendRoutingInfoforLCS/v3)
Subscriber Controlled Inputs (Supplementary Services)
networkFunctionalSs VLR
(registerSS),
(eraseSS),
(activateSS),
(deactivateSS),
(interrogateSS),
(registerPassword),
(processUnstructuredSS-Data/v1),
(beginSubscriberActivity/v1)
callCompletion VLR
(registerCCEntry),
(eraseCCEntry)
networkUnstructuredSs VLR
(processUnstructuredSS-Request/v2)
imsiRetrieval VLR
(sendIMSI/v2)
gprsLocationInfoRetrieval GGSN/SGSN
(sendRoutingInfoForGprs/v3/v4)
failureReport GGSN/SGSN
(failureReport/v3)
authenticationFailureReport VLR/SGSN
(authenticationFailureReport/v3)

Priority low

NOTE: The application context name is the last component but one of the object identifier.
Operation names are given in brackets for information with "/vn" appended to vn only operations.

Table 5.1/3: Priorities of Application Contexts for SGSN as Responder

Responder = SGSN Initiating Entity
Priority high
Mobility and Location Register Management
locationCancel HLR
(cancelLocation v3)
reset HLR
(reset)
subscriberDataMngt HLR
(insertSubscriberData v3),
(deleteSubscriberData v3)
tracing HLR
(activateTraceMode),
(deactivateTraceMode)

Short Message Service
shortMsgMT-Relay MSC
(MT-ForwardSM v3),
(forwardSM v1/v2)

Location Services

locationSvcEnquiry GMLC
(provideSubscriberLocation v3)

Network-Requested PDP context activation
gprsNotify HLR
(noteMsPresentForGprs v3),

(Subscriber Location & State retrieval)
subscriberInfoEnquiry HLR
(provideSubscriberInformation/v3)

Priority low

NOTE: The application context name is the last component but one of the object identifier.
Operation names are given in brackets for information with "/vn" appended to vn.

Table 5.1/2: Priorities of Application Contexts for MSC/VLR as Responder

Responder = MSC/VLR Initiating Entity
Priority high
Handover
handoverControl MSC
(prepareHandover/v2/v3),
(performHandover/v1)

Group call and Broadcast call
groupCallControl MSC
(prepareGroupCall/v3)
groupCallInfoRetrieval MSC
(sendGroupCallInfo/v3)

Mobility and Location Register Management
locationCancel HLR
(cancelLocation)
reset HLR
(reset)
immediateTermination HLR
(istCommand/v3)

interVlrInfoRetrieval VLR
(sendIdentification/v2/v3),
(sendParameters/v1)
subscriberDataMngt HLR
(insertSubscriberData),
(deleteSubscriberData)
tracing HLR
(activateTraceMode),
(deactivateTraceMode)

Short Message Service
shortMsgMO-Relay MSC/SGSN
(MO-ForwardSM v3),
(forwardSM v1/v2)
shortMsgMT-Relay MSC
(MT-ForwardSM v3),
(forwardSM v1/v2)
shortMsgAlert HLR
(alertServiceCentre/v2),
(alertServiceCentreWithoutResult/v1)

Mobile Terminating Traffic
resourceMngt GMSC
(releaseResources)
roamingNbEnquiry HLR
(provideRoamingNumber)
callControlTransfer MSC
(resumeCallHandling)
subscriberInfoEnquiry HLR
(provideSubscriberInformation/v3)
reporting HLR
(remoteUserFree),
(SetReportingState)

Location Services
locationSvcEnquiry GMLC
(provideSubscriberLocation/v3)

Network-Initiated USSD
networkUnstructuredSs HLR
(unstructuredSS-Request/v2),
(unstructuredSS-Notify/v2)
Priority low

NOTE: The application context name is the last component but one of the object identifier.
Operation names are given in brackets for information with "/vn" appended to vn only operations.

5.1.3 Congestion control for Signalling System No. 7

The requirements of SS7 Congestion control have to be taken into account as far as possible.

Means that could be applied to achieve the required traffic reductions are described in clauses 5.1.1 and 5.1.2.

5.2 Compatibility

5.2.1 General

The present document of the Mobile Application Part is designed in such a way that an implementation which conforms to it can also conform to the Mobile Application Part operational version 1 specifications, except on the MSC-VLR interface.

A version negotiation mechanism based on the use of an application-context-name is used to negotiate the protocol version used between two entities for supporting a MAP-user signalling procedure.

When starting a signalling procedure, the MAP-user supplies an application-context-name to the MAP-provider. This name refers to the set of application layer communication capabilities required for this dialogue. This refers to the required TC facilities (e.g. version 1 or 2) and the list of operation packages (i.e. set of operations) from which operations can be invoked during the dialogue.

A version one application-context-name may only be transferred to the peer user in a MAP-U-ABORT to an entity of version two or higher (i.e. to trigger a dialogue which involves only communication capabilities defined for MAP operational version 1).

If the proposed application-context-name can be supported by the responding entity the dialogue continues on this basis otherwise the dialogue is refused and the initiating user needs to start a new dialogue, which involves another application-context-name which requires less communication capabilities but provides similar functionality (if possible).

When a signalling procedure can be supported by several application contexts that differ by their version number, the MAP-User needs to select a name. It can either select the name that corresponds to the highest version it supports or follow a more specific strategy so that the number of protocol fallbacks due to version compatibility problems is minimised.

5.2.2 Strategy for selecting the Application Context (AC) version

A method should be used to minimise the number of protocol fall-backs which would occur sometimes if the highest supported AC-Name were always the one selected by GSM entities when initiating a dialogue. The following method is an example that can be used mainly at transitory phase stage when the network is one of mixed phase entities.

5.2.2.1 Proposed method

A table (table 1) may be set up by administrative action to define the highest application context (AC) version supported by each destination; a destination may be another node within the same or a different PLMN, or another PLMN considered as a single entity. The destination may be defined by an E.164 number or an E.214 number derived from an IMSI or in North America (World Zone 1) by an E.164 number or an IMSI (E.212 number). The table also includes the date when each destination is expected to be able to handle at least one AC of the latest version of the MAP protocol. When this date is reached, the application context supported by the node is marked as "unknown", which will trigger the use of table 2.

A second table (table 2) contains an entry for each destination that has an entry in table 1. For a given entity, the entry in table 2 may be a single application context version or a vector of different versions applying to different application contexts for that entity. Table 2 is managed as described in clause 5.2.2.2.

The data for each destination will go through the following states:

a) the version shown in table 1 is "version n-1", where ‘n’ is the highest version existing in this specification; table 2 is not used;

b) the version shown in table 1 is "unknown"; table 2 is used, and maintained as described in clause 5.2.2.2;

c) when the PLMN operator declares that an entity (single node or entire PLMN) has been upgraded to support all the MAP version n ACs defined for the relevant interface, the version shown in table 1 is set to "version n" by administrative action; table 2 is no longer used, and the storage space may be recovered.

5.2.2.2 Managing the version look-up table

WHEN it receives a MAP-OPEN ind the MAP-User determines the originating entity number either using the originating address parameter or the originating reference parameter or retrieving it from the subscriber data using the IMSI or the MSISDN.

IF the entity number is known:

THEN

It updates (if required) the associated list of highest supported ACs.

ELSE

It creates an entry for this entity and includes the received AC-name in the list of highest supported ACs.

WHEN starting a procedure, the originating MAP-user looks up its version control table.

IF the destination address is known and not timed-out.

THEN

It retrieves the appropriate AC-name and uses it

IF the dialogue is accepted by the peer

THEN

It does not modify the version control table

ELSE (this should never occur)

It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer).

It replaces the old AC-name by the new one in the list of associated highest AC supported.

ELSE

It uses the AC-name that corresponds to the highest version it supports.

IF the dialogue is accepted by the peer.

THEN

It adds the destination node in its version control table and includes the AC-Name in the list of associated highest AC supported.

ELSE

It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer).

IF the destination node was not known

THEN

It adds the destination node in its version control table and includes the new AC-Name in the list of associated highest AC supported.

ELSE

It replaces the old AC-name by the new one in the list of highest supported AC and reset the timer.

5.2.2.3 Optimising the method

A table look-up may be avoided in some cases if both the HLR and the VLR or both the HLR and the SGSN store for each subscriber the version of the AC-name used at location updating. Then:

– for procedures which make use of the same application-context, the same AC-name (thus the same version) can be selected (without any table look-up) when the procedure is triggered;

– for procedures which make use of a different application-context but which includes one of the packages used by the location updating AC, the same version can be selected (without any table look-up) when the procedure is triggered;

for HLR:

– Subscriber data modification (stand alone);

for VLR:

– Data Restoration.