MTAS Priority Services Management Guide
MTAS

Contents

1Introduction
1.1Prerequisites

2
Overview
2.1Subfunctions
2.2Interaction with Other Services

3
Priority Services Configuration
3.1Priority Services Administrative State Configuration
3.2Priority Call Termination on Low Credit Configuration
3.3GETS Priority Services Configuration

4
Performance Management

5
Fault Management

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:

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) Session Initiation Protocol (SIP) extension, in the initial INVITE of the session. According to the GETS scheme, five different priority levels are used above normal.

The GETS Priority Service is enhancement over Priority Services, where MTAS identifies the GETS Priority Service Call type based on the Request URI in the initial INVITE request and reports the GETS-specific charging information. Eligibility for the GETS Priority Service is granted by another node, Call Session Control Function (CSCF), SBG, or the GETS Application Server (GETS-AS). GETS-AS is the third-party Application Server.

2.1   Subfunctions

This section describes the following subfunctions:

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 the "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 the 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.

Table 1    H.248 Priority Attribute Value Mapping

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 an element of the IMS-Information group AVP, with a priority value mapped from the preserved priority data for the session, see Table 2.

Table 2    Session Priority Attribute Value Mapping

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

Diameter messages through Ro and Rf interface to charging systems also contain a Supplementary Service Information Attribute Value Pair(AVP) as an element of the Ericsson-Service-Information for the GETS Priority Service call, see Table 3.

Table 3    Supplementary Service Information Attribute Value Mapping

GETS Priority Service Call Type

Supplementary-Service-Identity

Supplementary-Service-Action

GETS-FC

GETS_FC_PRIORITY_SERVICE (5000)

Use of Service

GETS-AN

GETS_AN_PRIORITY_SERVICE (5001)

Use of Service

GETS-NT

GETS_NT_PRIORITY_SERVICE (5002)

Use of Service

GETS-FC+GETS-AN

GETS_FC_GETS_AN_PRIORITY_SERVICE (5003

Use of Service

GETS-FC+GETS-NT

GETS_FC_GETS_NT_PRIORITY_SERVICE (5004)

Use of Service

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. The 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 because of charging link failures.

Depending on the configuration, it is possible to disable that the established resource prioritized calls are terminated because of 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 is 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 high load conditions, the Home Subscriber Server (HSS) can handle it accordingly. Then, the MTAS also sends a 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 because of the 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.1.5   GETS Priority Service Call Identification

The MTAS identifies the call type as the GETS Priority Service call type in the following type and the process accordingly:

2.1.6   Configure GETS Priority Service

Configure GETS Priority Service function is utilized by the operator to configure the GETS Priority Service at the node level.

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:

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.

Figure 1   Priority Call MO Structure

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.

3.3   GETS Priority Services Configuration

The GETS Priority Services feature configuration is controlled by the MtasPriorityCallGetsService Managed Object (MO). An overview of the Priority Call GETS Service MO structure is shown in Figure 2.

Figure 2   GETS Priority Call MO Structure

3.3.1   GETS Priority Service Administrative State

Unlock the mtasPriorityCallGetsServiceAdministrativeState attribute in the MtasPriorityCallGetsService MO by setting it to 1 (Unlocked). If the mtasPriorityCallGetsServiceAdministrativeState attribute is set to 0 (Locked), GETS Priority Service is not activated. MTAS does not identify the GETS Priority Service call type and does not support the GETS Priority Service specific charging functionality.

GETS Priority Service is enhancement over existing priority service, see Section 3.1 Priority Services Administrative State Configuration, which is a prerequisite for the GETS Priority Service activation.

As a prerequisite, the administrative state of the SSC service and the Number Normalization service must be enabled.

3.3.2   GETS Priority Service

GETS Priority Service is configured for different call types as follows:

3.3.2.1   GETS-FC Priority Service Configuration

mtasSscPriorityCallComSyntInv:

MTAS can be configured to identify GETS-FC Priority Service call by setting mtasSscPriorityCallComSyntInv to a specific feature code prefix. The prefix defines the command syntax to parse the SSC code dialed by the user for the GETS FC Priority Service Invocation.

For more information about the command syntax configuration, refer to MTAS Supplementary Service Codes Management Guide.

Different command syntaxes can be configured by the operator, for example:

3.3.2.2   GETS-AN Priority Service Configuration

mtasPriorityCallGetsServiceAnNumbers:

MTAS can be configured to identify a GETS-AN Priority Service call by setting the mtasPriorityCallGetsServiceAnNumbers attribute to GETS-AN numbers and by configuring the GETS-AN number as OSN\NSN Number in the MtasNumNorm MOC. OSN/NSN configuration is required to deter the Number Normalization service from normalizing the number in the R-URI.

For more information about the OSN/NSN number configuration, refer to MTAS Number Normalization Management Guide.

For example:

3.3.2.3   GETS-NT Priority Service Configuration

mtasPriorityCallGetsServiceNtNumbers:

MTAS can be configured to identify GETS-NT Priority Service call by setting the mtasPriorityCallGetsServiceNtNumbers attribute to GETS-NT numbers and by configuring the GETS-NT number as OSN\NSN Number in MtasNumNorm MOC. Do not set any substitution rule in the MtasNumNorm for the dialed number.

For example:

3.3.2.4   GETS-FC + GETS-AN Priority Service Configuration

The configuration required is a combination of configurations for GETS-FC and GETS-AN call. For more details, see Section 3.3.2.1 GETS-FC Priority Service Configuration and Section 3.3.2.2 GETS-AN Priority Service Configuration.

3.3.2.5   GETS-FC + GETS-NT Priority Service Configuration

The configuration required is a combination of configurations for GETS-FC and GETS-NT call. For more details, see Section 3.3.2.1 GETS-FC Priority Service Configuration and Section 3.3.2.2 GETS-AN Priority Service Configuration.

3.3.2.6   Configuration for Charging Method Suppression in GETS Priority Service

In GETS Priority Service, for different Priority Service Calls Type (GETS-FC, GETS-AN, GETS-FC-AN, GETS-FC-NT, GETS-TERM, and so on), an operator can configure which charging method (online or offline, or both) needs to be suppressed at the originating side and the terminating side.

mtasChargingProfileSupressOrigChargingInGetsFC:

MTAS can be configured to suppress charging method for specific GETS-FC Priority Service call type by setting the mtasChargingProfileSupressOrigChargingInGetsFC attribute to the following values:

Example: if the mtasChargingProfileSupressOrigChargingInGetsFC default value is 0, it means no suppression of charging methods. All defined charging methods in the charging profile are applicable for GETS-FC Priority Service call type.

mtasChargingProfileSupressOrigChargingInGetsNT:

MTAS can be configured to suppress charging method for specific GETS-NT Priority Service call type by setting mtasChargingProfileSupressOrigChargingInGetsNT attribute to the following values:

Example: if the mtasChargingProfileSupressOrigChargingInGetsNT default value is 0, it means no suppression of charging methods. All defined charging methods in the charging profile are applicable for GETS-NT Priority Service call type.

For GETS-FC+GETS-AN\NT Priority Service call,

mtasChargingProfileSupressOrigChargingInGetsFC is applicable.

mtasChargingProfileSupressOrigChargingInGetsAN:

MTAS can be configured to suppress charging method for specific GETS-AN Priority Service call type by setting the mtasChargingProfileSupressOrigChargingInGetsAN attribute to the following values:

Example: if mtasChargingProfileSupressOrigChargingInGetsAN default value is 0, it means no suppression of charging methods. All defined charging methods in the charging profile are applicable for GETS-AN Priority Service call type.

3.3.2.7   Call Diversion Configuration

MTAS can be provisioned with forward to DN number as GETS Numbers. MTAS can be configured to identify the provisioned forward to DN number as GETS-FC, GETS-AN/NT, GETS-FC+ GETS-AN/NT Priority Service call by setting the mtasSscPriorityCallComSyntInv, mtasPriorityCallGetsServiceAnNumbers, and mtasPriorityCallGetsServiceNtNumbers attributes.

For more information on how to configure forward to DN number, refer to MTAS CAI3G Interface.

For example:

3.3.2.8   Miscellaneous Configuration Scenarios of Priority Service

There are multiple scenarios where calls are to be rejected or accepted as per the configuration.

3.3.2.8.1   Combination of GETS-FC + SSC Prefix +ND in Originating MTAS

When GETS-FC prefix (for example *272) is followed by another SSC Prefix and ND, the MTAS SSC service executes GETS-FC functionality first, mark the call as GETS-FC, and execute second SSC prefix-specific functionality.

Example: sip:*272*314506274387;phone-context=+1@bt.co.uk;user=phone;

1st SSC prefix (GETS-FC) = *272

2nd SCC prefix = *31

Number Dialed (ND) = 4506274387

3.3.2.8.2   Combination of SSC Prefix + GETS-FC + ND in Originating MTAS

When another valid SSC Prefix is followed by GETS-FC Prefix (for example*272) and ND, MTAS SSC service executes the SSC prefix-specific functionality first and then rejects the call by 403 SIP response, if the valid RPH Header is present in the INVITE request.

Example: sip:*31*2724506274387;phone-context=+1@bt.co.uk;user=phone;

1st SSC prefix = *31

2nd SCC prefix (GETS-FC) = *272

Number Dialed (ND) = 4506274387

If the valid RPH Header is not present in the INVITE request and another valid SSC Prefix is followed by GETS-FC Prefix (*272) and ND, MTAS SSC service executes the SSC prefix-specific functionality first. GETS call handling is done as per CM attribute mtasPriorityCallGetsServiceNoRPH value configured.

There are two values possible for mtasPriorityCallGetsServiceNoRPH:

3.3.2.8.3   Valid RPH Header but an Unidentified GETS Priority Service Call Type

When an INVITE request comes with valid RPH header values but MTAS did not find request URI belongs to any GETS Priority Service Call type then call handling is done as per CM mtasPriorityCallGetsServiceWithUnknwonGETSCallType value configured.

There are two values possible for this:

3.3.2.8.4   No RPH Header but an Identified GETS Priority Service Call Type

When an INVITE request comes without RPH header values or with an invalid RPH header value but MTAS found request URI belongs to any GETS PriorityService Call type then call handling is done as per CM mtasPriorityCallGetsServiceWithNoRPH value configured.

There are two values possible for this:

3.3.2.9   Configuration for GETS Session Response Matching

The following CM attributes define the SIP responses used to step the GETS Priority Service OK and NOK session counters:

mtasPriorityCallGetsServiceOkResponses

MTAS can be configured to increment the GETS Priority Service OK performance counter by setting successful SIP response values in the mtasPriorityCallGetsServiceOkResponses attribute.

Apart from 2xx response values, successful response values can include 1xx (except 100) or non-2xx response values, or both, indicating that GETS Priority Service call reached the remote end.

CM attribute mtasPriorityCallGetsServiceOkResponses is a list of strings, where each string consists of 1–2 parts separated by colons, see Example 1. The first part must contain the Status-Code of the response for GETS Priority Service session. The second part is optional and can contain the Reason-Phrase from the Status-Line, or the Reason header value present in the SIP response.

Example 1   mtasPriorityCallGetsServiceOkResponses String

1.	200
2.	487:RequestTerminated
3.	480:SIP;cause=480;text="XYZ"
where Reason header in 480 SIP response is like Reason: SIP;cause=480;text="XYZ"

During a GETS Priority Service Call establishment, the GETS Priority Service OK performance counter is incremented only once for a matched successful response, and the GETS Priority Service OK or GETS Priority Service NOK performance counter is not incremented in advance for the call. The text comparison/match is case-insensitive. The Reason-header/Reason-phrase part must be trimmed for leading and trailing whitespace.

In response matching, preference is given to detailed configuration matching, such as StatusCode:Reason-Phrase/ReasonHeader (if configured), over simple configuration matching such as StatusCode. If the detailed configuration is not matched, it can result in the GETS Priority Service OK counter not being incremented.

If there is a GETS Priority Service call type other than GETS-FC, the first 18X response is not considered for performance measurement because it is sent by a GETS-Application Server.

The mtasPriorityCallGetsServiceNOkResponses list is considered for GETS Service NOK performance counter increment, if the final response values match not found in mtasPriorityCallGetsServiceOkResponses list and GETS Priority Service OK or NOK performance counter has not been incremented previously for the call.

mtasPriorityCallGetsServiceNOkResponses

MTAS can be configured to increment GETS Priority Service NOK performance counter by setting unsuccessful SIP response values in the mtasPriorityCallGetsServiceNOkResponses attribute.

The CM attribute mtasPriorityCallGetsServiceNOkResponses is a list of strings, where each string consists of 1–2 parts separated by colons, see Example 2. The first part must contain the Status-Code of the response for the GETS Priority Service session. The second part is optional and can contain the Reason-Phrase from the Status-Line, or the Reason header value present in the SIP response.

Example 2   mtasPriorityCallGetsServiceNOkResponses String

1.	603
2.	500:Internal Error
3.	480:SIP;cause=480;text="XYZ"

where Reason header in 480 SIP response is like
Reason: SIP;cause=480;text="XYZ"

During a GETS Priority Service Call establishment, the GETS Priority Service NOK performance counter is incremented only once for a matched unsuccessful response, and the GETS Priority Service OK or GETS Priority Service NOK performance counter is not incremented in advance for the call. The text comparison/match is case-insensitive. The Reason-header/Reason-phrase part must be trimmed for leading and trailing whitespace.

In response matching, preference is given to detailed configuration matching, such as StatusCode:Reason-Phrase/ReasonHeader (if configured), over simple configuration matching such as StatusCode. If the detailed configuration is not matched, it can result in the GETS Priority Service NOK counter not being incremented.

3.3.2.10   Configuration for Operator Network Identification

The MtasPriorityCallGetsServiceOk/ MtasPriorityCallGetsServiceNOk counters are keyed on the terminating network type as follows:

In GETS Priority Service, the mtasPriorityCallGetsServiceNetIdentifer CM attribute is defined to identify the correct key value for the GETS Priority Service OK and NOK session counters performance measurement.

mtasPriorityCallGetsServiceNetIdentifer

MTAS can be configured to identify the operator network by setting the network identifier attribute mtasPriorityCallGetsServiceNetIdentifer, for example mtasPriorityCallGetsServiceNetIdentifer = "ims.com".

The P-Charging-Vector (PCV) Header present in GETS Priority service session request and response is used to identify operator network. The PCV header parameters orig-ioi and term-ioi values are compared with the values configured in the mtasPriorityCallGetsServiceNetIdentifer attribute.

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.



Copyright

© Ericsson AB 2016, 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    MTAS Priority Services Management Guide         MTAS