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) 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 other node, Call Session Control Function (CSCF) or the Session Border Gateway (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 "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.

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 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 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. 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 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 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.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 will not be 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, administrative state of SSC service and the Number Normalization service is to be enabled.

3.3.2   GETS Priority Service

Configuration of GETS Priority Service for different Call type is 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 specific feature code prefix which 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.

For example, different command syntaxes can be configured by the operator:

3.3.2.2   GETS-AN Priority Service Configuration

mtasPriorityCallGetsServiceAnNumbers:

MTAS can be configured to identify GETS-AN Priority Service call by setting mtasPriorityCallGetsServiceAnNumbers attribute to GETS-AN numbers and by configuring GETS-AN number as OSN\NSN Number in the MtasNumNorm MOC. OSN/NSN configuration is required in order 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 mtasPriorityCallGetsServiceNtNumbers attribute to GETS-NT numbers and by configuring 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 values

Example: if 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 values

Example: if 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 mtasChargingProfileSupressOrigChargingInGetsAN attribute to the 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 the mtasPriorityCallGetsServiceNtNumbers

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 will execute GETS-FC functionality first, mark the call as GETS-FC and then 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 will execute the SSC prefix specific functionality first and then reject 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 will execute the SSC prefix specific functionality first. GETS call handling will be done as per CM attribute mtasPriorityCallGetsServiceNoRPH value configured.

There are two value 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 will be done as per CM mtasPriorityCallGetsServiceWithUnknwonGETSCallType value configured.

There are two value 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 will be done as per CM mtasPriorityCallGetsServiceWithNoRPH value configured.

There are two value possible for this:

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