Priority Service Support in the Core Network

Priority Service Support in the Core Network

Damir Buric, Lovre Hribar, Alen Bulic

Ericsson Nikola Tesla, d.d.

Poljicka 39, Split, Croatia

Phone: +38521434937 Fax: +38521434834 E-mail:

Abstract:Certain system conditions (e.g. emergency situations, network overload) result in congested networks with blocking call attempts and thus an inability to handle emergency service calls. Under these situations, it should be possible to priorities certain calls and provide greater support to national, regional and international emergency organizations. United States (US) regulators defined the Wireless Priority Service (WPS) intended for National Security and Emergency Preparedness (NS/EP) leaders and key personnel in the US. Layered architecture was not taken into account. Standardization activities for Priority Service that should cover the layered architecture within 3GPP and ITU-T has started. Point of congestion that the layered architecture introduces will be stated in this paper.

I. INTRODUCTION

As defined in the Ref.[1], Priority Service allows qualified and authorizedusers to obtain priority access to the next available radio (voice or data traffic) channels on a priority basis before other PLMN users during situations when PLMN congestion is blocking call attempts. In addition, Priority Service supports priority call progression and call completion to support an “end-to-end” priority call.

Priority Service is intended to be used by qualified and authorized users, i.e., emergency service personnel, only during times of emergency situations and network congestion. Access to Priority Service is limited to key personnel and those with leadership responsibilities and is not intended for use by all emergency service personnel. This is to ensure that non-emergency service personnel cannot “take over” the network and deny the other non-emergency service subscribers a reasonably level of service.

An Industry Requirement document, Ref.[2] was developed under the auspices of the National Communications System (NCS) in the United States and in co-operation with companies from the telecommunication industry in order to standardize the Wireless Priority Service (WPS) for GSM systems. The first phase called WPS-IOC (Initial Operating Capabilities) and the second phase called WPS-FOC (Full Operating Capabilities). WPS is intended to facilitate emergency response and recovery operations in response to natural and man-made disasters and events, such as floods, earthquakes, hurricanes, and terrorist attacks. WPS is also intended to support both national and international emergency communications. It will provide National Security and Emergency Preparedness (NS/EP) leaders and key personnel in the United States priority treatment when using telecommunication networks. It will be implemented in GSM-based systems and in the PSTN; i.e. NS/EP calls will be given end-to-end priority treatment, across all call paths, mobile-mobile, mobile-fixed, and fixed-mobile. The regulatory requirements for WPS-IOC and WPS-FOC do not take the layered architecture into account.

However, it can be foreseen that the layered architecture must be supported in a longer time perspective for the following reasons:

• There could come additional requirements on WPS-FOC from the US regulatory organisation to support also the layered architecture;

• The installed based of layered architecture reaches a critical level where lack of support for WPS becomes apparent;

• Standardization activities within 3GPP and ITU-T has started for WPS services and they will cover the layered architecture. As a result from this, operators might demand WPS with support for 3G and layered architecture also outside of the US. At the moment only a frame has been discussed and there is no indication as to in which direction the solutions will go.

II. WIRELESS PRIORITY SERVICE IN MONOLITHIC ARCHITECTURE

WPS is invoked on a per call basis using WPS dialling procedures, i.e., WPS calls are originated by dialling *272+Destination Number. WPS is a subscription service. Subscriptions are only granted on recommendation of an authorising agency (in the U.S.A. that will be the NCS). WPS does not pre-empt established calls in progress; rather, WPS, provides priority access to network resources for WPS subscribers. WPS makes, within the network, use of the access priority levels provided by the enhanced Multi-Level Precedence and Pre-emption (eMLPP) feature. Invoking WPS calls on a per call basis by dialling the prefix (i.e., *272) avoids the need for eMLPP compatible User Equipment. Besides WPS calls there are another kind of priority calls, so called Government Emergency Telecommunication Service (GETS) calls. For a GETS call no prefix is used. A GETS call is invoked by dialling dedicated numbers e.g. 710-NCS-GETS (710-627-4387). In total five different numbers can be used to identify a GETS call. Compared to a WPS call no priority levels are used for a GETS call.

WPS and GETS calls are both priority calls or so called NS/EP calls. Priority handling for such calls is only applicable during call setup. Procedures proposed in Ref.[2] include two general categories of functions:

• Capabilities used to mark calls that require special WPS processing (e.g., including an NS/EP call indication and the Service User’s priority level) and to pass this special marking to subsequent nodes along the call path (in order to enable subsequent WPS processing); and

• Capabilities used to increase the probability of WPS call completion as the call progresses from the originating node, through any transit nodes, and on to the terminating node.

WPS requirements are based on the functions defined by the HPC Network Capability requirements, Ref.[3]. The HPC Network Capability requirements specify the setting of the Calling Party’s Category (CPC) parameter and MTP priority values in the Initial Address Message (IAM) (i.e., the CPC parameter value set to “NS/EP call” and IAM MTP priority set to “1”). The HPC Network Capability provides for treatment triggered by the CPC parameter set to “NS/EP call” or based on the recognition of a pre-defined dialed digit pattern. The HPC Capability includes the marking of specified calls and the execution of additional network treatment to increase the probability of call completion. These treatments include the following:

• Exemption from certain restrictive network management controls.

• Trunk queuing.

The HPC Network Capability relies on the deployment of SS7 switching system capabilities, including the ability to:

• Set the CPC parameter within the IAM to identify the call as an NS/EP call based on the dialled digits.

• Pass the CPC parameter through the telecommunications network.

• Pass the SS7 MTP priority of “1” for the SS7 IAM to increase the probability of delivery of the SS7 IAM to the next exchange in case of congestion in the signaling network.

• Recognize the NS/EP call indication in the CPC in the IAM.

Beyond the HPC capabilities several additional capabilities would increase the probability of WPS call completion. These additional procedures are applied to a WPS call as it progresses through the originating and any transit networks, and on to the terminating network.

• Provide a higher MTP message priority for all MAP messages that are required to successfully set up a WPS call. These procedures increase the probability of the corresponding messages being successfully transferred to their destination in the case of congestion in the signaling network.

• Set the (optional) ISUP Precedence parameterwithin the IAM to indicate the specific priority of the WPS call as assigned in the originating Service Provider’s network. The Precedence parameter is used in conjunction with the MLPP service. This parameter will be used for WPS, without invoking the pre-emption capabilities of MLPP.

• Pass the Precedence parameter through the telecommunications network.

• Recognize the Precedence parameter in the IAM in order to afford special WPS treatment at the terminating node (for calls that are destined for a wireless user). The priority of the WPS call is considered in allocating terminating radio traffic channel resources if no radio traffic channel is available.

Several possible points of congestion where WPS calls may experience blocking in their end-to-end call path will need to be overcome. Some of these congestion points are identified in Fig. 1. While these are not the only congestion points within the various call paths, they are the most likely and will significantly impact the call flow before other blocking points are expected to begin to have an impact.

The following items in Fig. 1 are addressed:

1. (ISUP/CAS) connections between nodes or towards other networks: congestion and priority handling
2. TCAP interfaces between GMSC, HLR, MSC/VLR, EIR, and LNP-DB: priority handling for TCAP dialogues
3. No radio channel available at radio interface
4. MSC/VLR:

• network management controls
• interactions with supplementary services
• shortage of system resources, which could be: too few software individuals, not enough hardware devices, or lack of Mobile Station Roaming Numbers

1. GMSC:

• network management controls
• interactions with supplementary services
• shortage of system resources; e.g. too few software individuals

1. TSC:

• network management controls
• shortage of system resources; e.g. too few software individuals

Fig. 1. Congestion or blocking points in Monolithic Network Architecture

1. Interface between gsmSSF and gsmSCF
2. BSC - MSC trunk congestion.
3. Congestion in SS7 signalling network: STP not part of the MSC/VLR, GMSC, or TSC therefore not in the scope of the report. The STP will send the received MTP priority level transparently to the next node. The MTP congestion function can be used in the STP in the same way as in an MSC (see chapter TCAP signalling).
4. Gs interface.

III. WIRELESS PRIORITY SERVICE IN LAYERED ARCHITECTURE

Layered architecture was not taken into account in Ref.[2]. When introducing layered architecture with ATM or IP backbone networks, the WPS user will expect the same handling as in the non-layered architecture: the probability of completion should not worsen. In order to ensure this, longer delays are accepted during the call establishment to allow e.g. waiting for a requested resource to become available.

NS/EP calls should be prioritized whenever possible over any other type of calls, including emergency calls.

In a layered architecture there are additional points of congestion that don’t exist in a non-layered network.

Fig. 2 shows those additional points of congestion that the layered architecture and WCDMA introduce.

The following points of congestion have been identified:

1.There could be congestion on the Mc link between MSC server and MGW with the result that messages to control the bearer signalling do not reach the other node or are delayed.

Priority handling: MTP3b/M3UA priority could be applied to GCP messages related to a WPS call.

2. There could be processor load congestion in the MGW with the result that the MGW is not able to execute GCP commands.

Fig. 2. Layered Architecture Specific Congestion or Blocking Points in WCDMA/GSM CS Core Network

Priority handling: the MGW could reserve some processor capacity only for NS/EP calls, that is, if the processor load reaches a certain level, the MGW should reject all MSC server attempts of establishing new calls, except for NS/EP calls. Alternatively, the NS/EP calls could share some reserved processor capacity with emergency calls.

The MSC could use the MGW congestion information, which is a reflection of the processor load in the MGW, to avoid selecting congested MGWs and, in case no other MGW is available, only allow NS/EP calls to attempt the congested MGW.

Another advantage is that MSC could attempt different MGWs and/or repeated times each MGW if an attempt meets congestion in the MGW.

3.There could be congestion in the bearer handling resources in the MGW, that is, in software or hardware resources in the MGW.

Priority handling: The MGW could reserve some extra software and hardware resources for the NS/EP usage only (these resources are dynamic). Alternatively, NS/EP calls could use the existing resource reservation mechanism for emergency calls.

The MSC could repeat the attempt several times to request the resources if it meets congestion. It may as well repeat the attempts on different MGWs.

The MGW could queue the request until the needed resources are available.

4.There could be congestion on the Nc interface which would cause call control messages (e.g. IAM, ACM) to be delayed or discarded. There are two different possible protocols on the Nc interface: ISUP and BICC. (IPBCP is tunnelled in BICC and not regarded as a separate protocol)

Priority handling: M3UA/MTP3b priorities should be applied to BICC messages related to a WPS call on the same way as it is proposed in WPS FOC for ISUP messages that use the MTP priority .

5.There could be congestion in the Nb interface, that is, in the bearer connectivity resources. This is a network-type-of congestion as opposed to e.g. the bearer handling resources, which is an internal node congestion.

Priority handling: Q.AAL2 priority should be applied to bearer control messages related to a WPS call. Q.AAL2 priority requires CS3.

MTP3b priority should be applied to Q.AAL2 messages related to a WPS call.

IP admission control could be by-passed for WPS calls.

For ATM, the MGW should queue the MSC server request until bandwidth (BA & BIR) is available.

For ATM, the MSC should attempt different MGWs and/or repeated times each MGW if an attempt meets congestion in the MGW.

6. There could be congestion on the external TDM trunks

Remote trunk queuing: The MSC should perform trunk queuing in a similar way as it is proposed in Ref.[1] for local ISUP in the non-layered architecture.

7. For WCDMA only: There could be congestion in the Iu interface.

RAB assignment requests should be queued if no air resources are available, in a similar way as it is proposed in Ref.[1] for the A-interface.

IV. HIGH LEVEL REQUIREMENTS FOR PRIORITY SERVICE IN 3GPP

Standardization activities for Priority Service that should cover the layered architecture has started. At this stage, the Ref. [1] performs a Gap Analysis to assess the ability of existing 3GPP specifications to meet the high-level Priority Service requirements.

1.Priority Call Origination

A call shall receive priority treatment (priority access to voice or traffic channels) on the originating side, when the call is setup by a Service User using the priority service dialling procedure.

2.Priority Call Termination

A call shall receive priority treatment (priority access to voice or traffic channels) on the terminating side, when the call is setup by a Service User using the priority service dialling procedure.

3.Priority Progression

The user should receive priority call treatment/progression through the mobile network(s). A priority call should be given higher priority over normal calls in the originating mobile network, to interconnected networks supporting priority (including the PSTN) and in the terminating network. Vendor specific functionality is needed to set priorities for each leg. This may not be supported in all interfaces or some nodes on path may not have needed functionality.

4.Priority Radio Resource Queuing

When a Priority Service call encounters a “no radio available” condition in the call path involving an access or egress air-interface, or both, and, at call origination, and upon recognition of the Priority Service dialing pattern, the Priority Service call is queued in the cell serving the calling party and processed for the next available radio channel in that cell in accordance with the caller’s priority level and call initiation time. At call termination upon recognition of a priority call indication in an incoming call, the Priority Service call is queued in the cell serving the called party and processed for the next available radio channel in that cell in accordance with the call’s priority level and arrival time.

5.Priority Level

The subscriber should be assigned one of n priority levels. Priority levels are defined as 1, 2, 3,…,n , with 1 being the highest priority level and n being the lowest priority level.

6.Invocation on Demand

Priority Service is invoked only when requested and an idle voice or traffic channel required for an origination request is not available.

7.Applicability to Telecommunications Services Priority Service shall be applicable to voice and data telecommunications services that require a voice or traffic channel assignment.

8.Authorization

A subscriber invoking Priority Service on call origination is authorized based on the caller’s subscription. It should also be possible for an additional second level of authentication (e.g., by the use of PIN) to identify that the user is authorized to make a priority call. In this case, authorization of the subscriber may be realized..

9.Priority Service service code.

Priority Service is manually requested by adding on the Priority Service service code to the origination request.

10.Roaming

Priority Service shall be supported during roaming when the roaming network supports Priority Service.

11.Handover

Priority Service shall be supported during handover.

12.Priority Service charging data record

The system should record the following Priority Service charging data information, in addition to non-Priority Service CDR information: Priority Service invocation attempts,

Call legs (origination and/or termination) on which Priority Service was used to gain access to the radio channel.

Recording of appropriate Priority Service information.

13.Priority Trunk Queuing

Priority Service shall be able to support queuing of Priority Service calls for trunk resources.

14.Coexistence with eMLPP

As a service provider option, it shall be possible to offer Priority Service and eMLPP within the same network, but not to the same user.

This standardization work in 3GPP is in the begining and there are no final conclusion on requirements for Priority Service.

V. PRIORITY SERVICE SUPPORT BY ITU-T STANDARDS

The main principle of Priority Service defined by ITU-T, Ref.[4], is valid for ISUP. It is agreed and there are activities within the ITU-T to include the I.255.4 Priority Service with 5 levels of priority into the BICC protocol that exists in the Layered Network, Ref.[5]. Fig.3 shows an example of congestion in the Bearer Network.