Contents
1 Introduction
This document describes how to configure the Priority Services feature in the MTAS.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the Operation and Maintenance (O&M) area, in general.
1.1.1 Licenses
To enable the Priority Services feature, the Priority Call license must be installed.
For more information about the Priority Call license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
- An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
The Priority Services feature enables MTAS to operate as part of an IP Multimedia Subsystem (IMS) network, which uses the Government Emergency Telecommunications Service (GETS) priority scheme to ensure liable rescue communications in a disaster scenario.
The GETS scheme is defined in IMS Core Network Government Industry Requirements for National Security/Emergency Preparedness NGN Priority Services, Issue 2.0, January 2013.
Priority Services is a network feature that ensures priority handling of communication throughout nodes. Eligibility for priority is granted by other node, Serving Call Session Control Function (S-CSCF), or Session Border Gateway (SBG).
MTAS gives priority treatment and provides exemption from certain restriction policies for incoming communication sessions that have been initiated with priority. This is determined, based on presence of a valid Resource-Priority header (RPH) SIP extension, in the initial INVITE of the session. According to the GETS scheme, five different priority levels are used above normal.
2.1 Subfunctions
This section describes the following subfunctions:
- Priority session identification
- Resource priority treatment
- Propagate priority information
- Provide exemption
2.1.1 Priority Session Identification
Resource-prioritized sessions are identified by recognition and analysis of the RPH in a received initial INVITE. Level of priority is determined, and resource priority data are preserved with the session.
Priority Session Identification is specified according to RFC 4412 (February 2006) Communications Resource Priority for the Session Initiation Protocol (SIP) and IMS Core Network Government Industry Requirements for National Security/Emergency Preparedness NGN Priority Services, Issue 2.0, January 2013.
MTAS processes the RPHs if the "ETS.x" namespace is present, where value of x can be either 0 or 1. This value is not used beyond validation.
Five different levels of priority are determined based on "WPS.y" namespace of the RPH, where y ranges from 0 (highest) to 4 (lowest).
2.1.2 Resource Priority Treatment
Session initiations with higher priority level are treated with higher priority.
Request priority treatment means that the load regulation mechanism does not reject higher priority requests, unless the load is so high that all normal and lower priority requests have been rejected.
Once a session is established, no in-session requests are rejected by the load regulation. This behavior is not depending on priority.
2.1.3 Propagate Priority Information
RPHs are forwarded to other SIP entities through IP Multimedia Service Control (ISC) and Ma interfaces. The priority value, that is preserved from the initial INVITE, is mapped to Mr, Mp, Ro, and Rf interfaces, and to Sh-Pull messages of the Sh interface.
2.1.3.1 Priority Indication on H.248 Interface to MRFP
In H.248 messages to the Media Resource Function Processor (MRFP), the Priority context attribute contains the value mapped from the preserved priority data of the session, see Table 1.
|
RPH WPS Attribute |
H.248 Priority Attribute |
|---|---|
|
WPS.0 |
15 |
|
WPS.1 |
14 |
|
WPS.2 |
13 |
|
WPS.3 |
12 |
|
WPS.4 |
11 |
2.1.3.2 Resource Priority Level Indication on Mr Interface
SIP messages on Mr interface to MRFC contain an RPH that is based on the preserved resource priority data of the session.
2.1.3.3 Priority Indication on Ro and Rf Interfaces To Charging System
Diameter messages through Ro and Rf interface to Charging Systems contain a Session-Priority Attribute Value Pair (AVP), as element of the IMS-Information group AVP, with a priority value mapped from the preserved priority data for the session, see Table 2.
|
RPH WPS Attribute |
Session-Priority AVP |
|---|---|
|
WPS.0 |
Priority-0 |
|
WPS.1 |
Priority-1 |
|
WPS.2 |
Priority-2 |
|
WPS.3 |
Priority-3 |
|
WPS.4 |
Priority-4 |
2.1.3.4 Priority Indication in Sh-Pull Messages on Sh Interface to HSS
All Sh-Pull messages in a priority session contain a Session-Priority AVP with a priority value mapped from the preserved priority data for the session. Same mapping, as described in Section 2.1.3.3 Priority Indication on Ro and Rf Interfaces To Charging System, is applied.
2.1.4 Provide Exemption
The Priority Services feature provides exemption from several policies that would block non-prioritized sessions.
2.1.4.1 Exemptions from Charging Failure Handling
For priority sessions, the Charging Failure Handling configuration is overridden, so that the calls are not terminated owing to charging link failures.
Depending on a configuration, it can be disabled that the established resource prioritized calls are terminated owing to credit consumption.
For Charging Failure Handling configuration, refer to MTAS Charging Management Guide.
2.1.4.2 Exemptions from Subscription Failures on Sh Interface
When a user has to be registered upon a prioritized initial INVITE, user data is requested with the priority (see Section 2.1.3.4 Priority Indication in Sh-Pull Messages on Sh Interface to HSS), so that, in the high load conditions, the Home Subscriber Server (HSS) can handle it accordingly. Then, the MTAS also sends an Sh-Subs-Notif message, to subscribe to possible changes in user data. Since this request cannot indicate priority, the HSS can fail to process it owing to same high load.
For non-prioritized calls, this failure prevents the call from being established. For priority calls, the MTAS continues establishing the session without subscription for user data changes.
2.2 Interaction with Other Services
This section describes how services interact with the Priority Services feature.
MTAS services update or set SIP dialog priorities, as follows:
- Ad-hoc Conference
Ad-hoc conference participant SIP dialogs inherit resource priority settings of the INVITE that created the conference focus.
When an existing session is moved to the ad-hoc conference, its priority is updated with the priority of the conference. If the moved session had priority but the conference has not, then priority is removed from it.
- Communication Completion
The completion call has the same priority as original. However, the signalling that prepares the completion call has no priority.
- Communication Diversion
When a call is diverted by Communication Diversion (CDIV), resource priority of the caller is preserved for the diverted calls.
- Three Party Call
Priority of the user who initiated the Three Party Service (3PTY) call is preserved as priority of the 3PTY focus. This priority is valid on all SIP dialogs of the focus.
After resuming to two party sessions, the priorities of the original calls are not restored.
- Explicit Communication Transfer
Priority of user who started Explicit Communication Transfer (ECT) service (Transferee) is valid on all SIP dialogs of the ECT session on the Transferee AS.
- Flexible Communication Distribution
Priority of the caller is used for the distributed requests.
- Session Transfer to Own Device
Priority of caller is used in transfer requests to all devices.
- Call Return
Priority of user who initiates the callback is in effect in the callback call.
- Scheduled Conference
The priority of all dial-in users is valid on their respective SIP dialogs. Dial-out legs have no priority.
- Communication Completion
The completion call has same priority as original. However, the signalling that prepares the completion call has no priority.
3 Priority Services Configuration
The Priority Services feature configuration is controlled by the MtasPriorityCall Managed Object (MO). An overview of the Priority Call MO structure is shown in Figure 1.
For configurable MOs and attributes related to the Priority Call configuration, refer to Managed Object Model (MOM).
3.1 Priority Services Administrative State Configuration
The Priority Services feature is enabled by setting the mtasPriorityCallResourcePriorityAdministrativeState attribute in the MtasPriorityCall MO to 1 (Unlocked). If the mtasPriorityCallResourcePriorityAdministrativeState attribute is set to 0 (Locked), Resource-Priority headers pass through the MTAS with no effect.
3.2 Priority Call Termination on Low Credit Configuration
MTAS can be configured not to terminate priority calls running out of credit in the Online Charging scenario by setting mtasPriorityCallTerminateOnLowCredit to 0 (Disabled). If mtasPriorityCallTerminateOnLowCredit is set to 1 (Enabled), the priority calls terminate on low credit similarly as non-prioritized calls.
4 Performance Management
For a description of measurements related to the Priority Services feature, refer to Managed Object Model (MOM).
5 Fault Management
For a list of alarms related to the Priority Call service, refer to MTAS Alarm List.