01_FN42431EN80GLA0_PCS5000_General

PCS-5000 Introduction and Features

FN42431EN80GLA0

© Nokia Solutions and Networks 2015.

1

Contents

1 General 3

1.1 Motivation for Policy based Resource Control 4

1.2 Standards organizations 8

1.3 PCRF 10

1.4 PCS 5000 Architecture 13

1.5 PCS-5000 Operation, Administration and Maintenance: WEB GUI 17

1.6 PCS-5000 Operation, Administration and Maintenance: PCM 18

1.7 PCRF Features and Functions 19

2 Basic Features 21

2.1 Network element features 23

2.2 Gx applications support 26

3 Extended Features 31

3.1 Special Features 33

3.2 VoLTE Support 62



FN42431EN80GLA0


2


FN42431EN80GLA0


3

1 General


FN42431EN80GLA0


4

1.1 Motivation for Policy based Resource Control

Problems in current network

In a single network variety of services and applications are present.

Additionally, there is variety of users: business and private users. Business

subscribers pay more and expect to have good Quality of Service.

If policy control is not introduced, all users have same rights, same quality. Low

priority traffic slows down high priority traffic.

Problems appear especially when traffic is crowded. Nobody can get priority;

nobody really gets a good service. Regulators request to provide more rights to some priority users (police, government, business customers…).

Solution:

Install Policy Server to control access to the network resources based on policy rules, subscription data and available resources.

Benefits of PCS

Introducing centralized policy control functionality in the network will make it

possible for operator to limit access to the network to guarantee service availability

especially for disaster events. Unlimited access could interfere with service quality, or even be interrupted.

But beside technical aspects there are also commercials ones, which cause an

operator to require policy control. There are a lot of business models, which are based on individual agreements with the user, when and how to use a service.


FN42431EN80GLA0


5

Motivation for Policy Based Resource Control

Problems in current network• Variety of services and applications in a single network

• Variety of users (business and private users)

• Low priority traffic slows down high priority traffic

• Regulators request: priority call during network overload

Solution:Policy Server to control access to the network resources based on:

policy rules, subscription data and available resources

Benefits of Policy Based Resource Control• technical aspects

• commercials aspects

Fig. 1


FN42431EN80GLA0


6

What is a Policy?

Policies are simple rules that trigger certain kinds of behavior in any kind of system, from a network to an organization.

If a system can be controlled through policies it can easily be modified to meet the

requirements of the day

Main Policy categories:

Subscriber based policies (based on subscriber profile )

Service based policies

Time based policy

Device based policy

Volume based policy


FN42431EN80GLA0


7

Policy

What is a Policy

Policies are simple rules that trigger certain kinds of behavior in any

kind of system, from a network to an organization.

If a system can be controlled through policies it can easily be modified

to meet the requirements of the day

Main categories for policy decisions:

• Subscriber based policies (based on subscriber profile )

• Service based policies

• Time based policy

• Device based policy

• Volume based policy

Fig. 2


FN42431EN80GLA0


8

1.2 Standards organizations

From the very beginning, the Nokia Solutions and Networks PCS development strategy was based on the information contained in the documents of the

standardization bodies. These include:

Third Generation Partnership Project (3GPP)

Internet Engineering Task Force (IETF)

European Telecommunication Standards Institute - Telecoms and Internet-

converged Services and Protocols for Advanced Networks (ETSI TISPAN)

Cable Television Laboratories Incorporated (CableLabs)

In the release 8 only PCS for Mobile Network, according to 3GPP, is released. It is called PCRF (Policy and Charging Rule Function).


FN42431EN80GLA0


9

Fixed

Mobile

Telecommunications and

Internet converged Services

and Protocols

for Advanced Networking

European

Telecommunications

Standards Institute

Cable Television Laboratories 3rd Generation Partnership Project

Cable

Fig. 3

TIP For previous PCS version 6.3, following PCS variants were released:

SPDF

I-SPDF

PCRF

CPCS (common scenario for SPDF and PCRF)


FN42431EN80GLA0


10

1.3 PCRF

From 3GPP R7 on, combined PDF (Policy Decision Function) and CRF (Charging Rule Function) is called PCRF (Policy and Charging Rule Function).

With Policy Decision, network resources are controlled. For each mobile access and

each secondary PDP (packet data protocol) context/bearer, the PCRF should authorize and control the resource usage. The PCRF acts as the policy decision point and the GGSN as the corresponding policy enforcement point.

The PCRF also supports flow based charging, except credit management.

Implemented Interfaces:

Gx Interface

The Gx reference point is located between the PCRF and the PCEF (GGSN or PDN-

GW). The Gx reference point is used for provisioning and removal of Policy and Charging Control (PCC) rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used

for charging control, policy control or both by applying relevant AVPs.

Gx interface is based on Diameter protocol. It is defined in 3GPP TS 29.212.The

PCRF acts as a Diameter server and the PCEF acts as the Diameter client.

Rx Interface

The Rx reference point is used to exchange application level session information between the Policy and Charging Rules Function (PCRF) and the Application

Function (AF). This information is part of the input used by the PCRF for the Policy and Charging Control (PCC).

PCRF acts as a Diameter server and the AF acts as the Diameter client.

Rx is defined in 3GPP TS 29.214.

Gy Interface

The Gy reference point resides between the OCS and the PCEF. The Gy reference

point allows online credit control for service data flow based charging.

Sp Interface

The Sp reference point lies between the SPR and the PCRF.

The Sp reference point allows the PCRF to request subscription information related

to the subscriber from the SPR. These data can be based on subscriber ID (e.g. IMSI or MSISDN). Sp reference point allows the SPR to notify the PCRF when the subscription information has been changed.

The details associated with the Sp reference point are not specified by 3GPP.


FN42431EN80GLA0


11

Policy Control 3GPP Reference Architecture

PCEF

Rx

Sp

Gy

Gz

Gx

SPR

OCS

UE

OFCS

AF

PCRF

AF: Application Function

PCEF: Policy Enforcement Function

PCRF: Policy and Charging

Rule Function

SPR: Subscription Profile Repository

OCS: Online Charging System

OFCS: Offline Charging System

UE: User Equipment

Access

Transport

Netvork

Gy

PULL (CCR)

PUSH (RAR)

PULL (CCR)

Fig. 4


FN42431EN80GLA0


12

Push and Pull mode

PCRF should send via Gx interface point PCC rules to be applied at the PCEF.

The PCRF can use two modes of operation: push or pull.

PULL mode (solicited provision)

Provisioning is asked (solicited) by the PCEF. The Gateway pulls the PCC rules from the PCRF. In response to a request for PCC rules being made by the PCEF (CCR) the PCRF should provision PCC rules in the CCA.

PUSH mode (unsolicited provision)

Provisioning is not asked by the PCEF. The PCRF does not contact the GW on request. Instead, it can be in response to information provided from AF via the Rx

reference point, or in response to a trigger (internal, within the PCRF or external). To provision PCC rules without a request from the PCEF, the PCRF includes these PCC rules in an RAR message. No CCR/CCA messages are triggered by

this RAR message.

PCC rules may be based on one or more of the following:

Information obtained from the AF via the Rx reference point, e.g. the session,

media and subscriber related information.

Information obtained from the PCEF via the Gx reference point, e.g. IP-CAN

bearer attributes, request type, location information.

Information obtained from the SPR via the Sp/Sh reference point, e.g. subscriber

and service related data.


FN42431EN80GLA0


13

1.4 PCS 5000 Architecture

From PCS-5000 v8.0 distributed farm architecture is supported. Server Farm is a variable number of nodes, depending on performance and availability requirements.

Number of Nodes in one Farm MUST be even number.

In the PCS Farm Architecture one additional unit is added: Access Gateway or F5 IP

Load Balancer. The Load Balancer encapsulates the server farm topology for external systems (e.g. Packet Gateway). In this way, Server Farm extension (adding

nodes) can be done transparently for external systems.

Load Balancer distributes IP traffic based on load status of nodes of the farm. Layer 4

load balancing (TCP/IP connection) is used.

Configuration of Load Balancer is active – standby.

PCS Farm Architecture

1/2

Fig. 5


FN42431EN80GLA0


14

1.4.1 TSP and DAF based architecture

TSP based PCS architecture

Ending with version 6.3, PCS was offered as a cluster on Sparc or ATCA Platform.

Software architecture was based on Telco Service Platform (TSP7000). TSP7000 is middleware from Nokia Solutions and Networks, designed for telecommunication market. It is carrier-grade platform and comprises of components that enable high

availability of the overall system. TSP7000 includes functions like application supervision, database management, context and counter management, real-time database management system.

TSP7000 integrates several third-party commercial products, which include among

others, Oracle / SOLID Data Base. Apache web server (Web), Sun Java virtual machine and Volume Manager.

CAF (Common Application Framework) is present as platform component and application component.

As operating system Solaris 10 for Sun Netra or Red Hat Linux 6 for ATCA is used.

DAF based PCS architecture

In version 8, software architecture is based on DAF (Distributed Architecture

Framework). Only ATCA hardware is supported. DAF is high available middleware. Like TSP7000, it is designed for the telecommunication market with its carrier-grade requirements. DAF comprises of components that enable the high availability of the

overall system and avoid any lower layer failures affecting applications. DAF also includes the real-time database management system. It offers applications a single image view (hides the farm architecture). DAF provides failure security and

redundancy between nodes of the farm, as well as fault tolerance at the process level.

Functionally, DAF includes application supervision, database management, context management, and counter management.

DAF integrates several third-party commercial products, which include among others the Oracle database, the Apache WebServer (Web), and the Sun Java virtual

machine.

As operating system Red Hat Linux 5/6 is used.

The PCS-5000 software is integrated with the platform via an application

programming interface (API) offered by the DAF.

NOTE

DAF - Distributed Architecture Framework is also called as Common Application Framework (CAF).


FN42431EN80GLA0


15

TSP based PCS Architecture

Sparc/ATCASparc/ATCA

PCS Appl

CAF

SunCluster

TSP

Solaris/RHEL

PCS Appl

CAF

SunCluster

TSP

SolarisRHEL

IP SwitchesIP Switches

• 2 node Sparc (T5220, T5240) or x86-ATCA

• Oralce DB on shared disks or Solid DB (in-memory, local disks)

• OS: Solaris or RHEL

• Clusterware (Sun Cluster, Prime Cluster), Cluster File System, tightly coupled HA system

• Active/Standby, local equal load distribution

• TSP functions (high availability , Node, Context, Counter, Database Management, Tracing, Alarming, application supervision)

Fig. 6


FN42431EN80GLA0


16

DAF based PCS architecture

• N node Farm , x86-ATCA, no shared disks, loosely coupled

• OS: RHEL

• HA ensured by multiple nodes and several platform functions

• DAF functions: high availability, failure security and redundancy between nodes, single image view, Application supervision, Database, Context and Counter management.

• Load Balancer : F5 IP Load Balancer or s Access Gateways (A/S): single system view,, easy farm extension, securityLayer 4 load balancing , based on load status of the nodes of the farm.

…

ATCA

PCS Appl

DAF

RHEL

ATCA

PCS Appl

DAF

RHEL

ATCA

PCS Appl

DAF

RHEL

IP Load Balancer 1IP Load Balancer 2

Access Gateway

ATCA

PCS Appl

DAF

RHEL

Fig. 7


FN42431EN80GLA0


17

1.5 PCS-5000 Operation, Administration and Maintenance: WEB GUI

Web GUI is also called DAF WEB GUI or @vantage GUI. It provides following

Management functions:

Trace Management

Configuration Data Management (CDM)

Farm Management

Local User Management (LUMAF)

Process Management (part of Trace or System Management)

Alarm Management (part of System Management)

Web GUI

Fig. 8


FN42431EN80GLA0


18

1.6 PCS-5000 Operation, Administration and Maintenance: PCM

Policy and Configuration Management (PCM) provides following Management

functions:

Configuration Management

Policy Management

PCM – Policy and Configuration Management

Fig. 9


FN42431EN80GLA0


19

1.7 PCRF Features and Functions

PCRF provides wide range of features.

Basic Features:

Network element features High availability

Overload protection Session Context Release

Gx applications support

Provisioning of PCC rules QoS control Gate Control

Provisioning of charging related information Charging Correlation Provisioning of event triggers

Usage Monitoring

Extended Features

Special Features

Fair Usage Policy

Subscriber Profile Repository Rapid policy suite Bill shock prevention.

Billing cycle reset. Round off volume accumulation Subscriber notification

Generic Plug-in Interface Multiple IP-CAN session

VoLTE and Rx applications support Emergency call

Multimedia priority Service (MPS) SIP Forking


FN42431EN80GLA0


20


FN42431EN80GLA0


21

2 Basic Features


FN42431EN80GLA0


22

Basic Features:

Network element features

High availability Overload protection Session Context Release

Gx applications support

Provisioning of PCC rules QoS control

Gate Control Provisioning of charging related information Charging Correlation

Provisioning of event triggers Usage Monitoring


FN42431EN80GLA0


23

2.1 Network element features

2.1.1 High Availability

High Availability refers to configuration that provides maximum network availability by having redundant or backup devices, links or switches between the host and the rest

of the world. The goal is to provide the maximum availability of network connectivity (i.e., the network always works), even though other configuration could provide higher throughput.

High availability is realized through:

HW redundancy

PCS nodes:

even number of nodes, minimum 4. Each node backs up the other. All nodes are active.

@com

2 nodes, Active / Standby

HUB 2 nodes, Active / Standby

Load Balancer

2 elements, Active / Standby.

SW organization

PCS-5000 is designed as a multi-process system. Process organization in one Farm Node and in one Node is already explained in Chapter 2 (Interfaces and Processes).

You will find there the mode of operation of processes in the PCS Farm in case of normal operation and in case of failure.

.


FN42431EN80GLA0


24

2.1.2 Overload

PCS Overload Control controls the load of the system. The purpose is to protect the system from performance degradation and outages due to resource exhaustion or

over-utilization. This requires resource management and supervision in order to keep sufficient resources available for the highest prioritized tasks. When it is necessary, number of requests received on the external interfaces will be temporarily reduced.

Operator is informed via OAM about Overload Level.

Load levels

Load Level can be

Normal

Above Normal

High

Critical

Very Critical.

Data important for overload (e.g. number of messages per interface, CPU load,

memory load) operator have to specify in PCM: PCS_ServiceConfigParams.xml. When measured data is greater than specified data, overload is recognized.

Message Rate:

100% - 120% - Above Normal load

120% - 125% - High load

125% - 130% - Critical load

130% - 135% - Very Critical load

CPU:

85% - Normal load

89% - Above Normal load

93% - High load

97% - Critical load

100 % - Very Critical load

To enable Overload Control, the operator must set the "Do-Overload-Control" to

"true" in the "PCS_ServiceConfigParams" (Core).


FN42431EN80GLA0


25

Load levels

Load level Load Factor

Up to 100% - Normal load

100% - 120% - Above Normal load

120% - 125% - High load

125% - 130% - Critical load

130% - 135% - Very Critical load

Message Rate

85% - Normal load

89% - Above Normal load

93% - High load

97% - Critical load

100 % - Very Critical load

CPU

Normal load 4

Above Normal load 5

High load 6

Critical load 7

Very Critical load >=8

Fig. 10


FN42431EN80GLA0


26

2.2 Gx applications support

2.2.1 Provisioning of PCC rules

PCC Rule provides parameters for policy control and charging control. It can be:

Predefined in PCEF:

This type of the rule has been provisioned directly into the PCEF by the operator. PCRF can activate or deactivate them at any time.

Dynamically provisioned by the PCRF

PCRF can install, modify and removed them at any time.

PCRF can activate/deactivate/remove/modify PCC Rules. Reference to this PCC Rule is defined with

Charging Definition AVP

Charging-Rule-Name AVP

Charging-Rule-Base-Name AVP

Which action is required is defined by:

Charging-Rule-Install AVP

Charging-Rule-Remove AVP

Charging-Rule-Name is used to: - Activate/deactivate a PCC rule that is predefined at the PCEF. Required action is

indicated by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP.

Charging-Rule-Base-Name: It is used in case of group of PCC rules, in the same way like "Charging-Rule-Name" AVP.

Charging-Rule-Definition AVP: It is used to install a new PCRF defined PCC rule, or to modify an already installed

PCRF defined PCC rule.


FN42431EN80GLA0


27

2.2.2 QoS control

QoS-Information AVP can be sent from the PCEF to the PCRF or from the PCRF to the PCEF.

When QoS-Information AVP is sent from the PCEF to the PCRF, it indicates the requested QoS information associated with resources requested by the UE, an IP CAN bearer or the subscribed QoS information at APN level.

When this AVP is sent from the PCRF to the PCEF, it indicates the authorized QoS for IP-CAN bearer, for an APN or for service flow (when is included in the PCC rule).

2.2.3 Gate Control

Gate function describes status of gate (open or closed) enabling or disabling

forwarding of service flow packets. A gate is described within a PCC rule. If the PCC rule contains Flow-Description AVP(s) applicable for uplink IP flows, it describes a gate for the corresponding uplink IP flows. If the PCC rule contains Flow-Description

AVP(s) applicable for downlink IP flows, it describes a gate for the corresponding downlink IP flows. The Flow Status AVP of the PCC rule describes if the possible uplink and possible downlink gate is opened or closed.

If the gate is closed all packets of the related IP flows shall be dropped. If the gate is

opened the packets of the related IP flows are allowed to be forwarded.

PCRF derives the required state of a gate (open or closed) from the service

information of the AF session to which the IP packet flow belongs. The AF does this by sending the AA-Request message containing the Media-Component-Description

AVP(s). Inside this AVP is Flow-Status AVP, for the flows to be enabled or disabled.

The Flow-Description and Flow-Status AVP are components of Charging-Rule-

Definition AVP, sent from the PCRF to the PREF:


FN42431EN80GLA0


28

2.2.4 Provisioning of charging related information

Provisioning of Default Charging Method.

Default charging method is defined with.

Online AVP

Offline AVP

Default Charging method can be provided by:

PRCF

Online AVP or Offline AVP can be embedded within the CCA command to the

PCEF.

PCEF

Online AVP and/or Offline AVP can be embedded within the CCR command to the

PCRF.

The default charging method provided by the PCRF shall take precedence over any

pre-configured default charging method at the PCEF.

Provisioning of Charging Address:

PCRF can provide OFCS and/or OCS addresses within a Charging-Information AVP to the PCEF defining the offline and online charging system addresses

respectively. These overwrite any predefined addresses at the PCEF.

2.2.5 Charging Correlation

For the purpose of charging correlation between AF and PCEF, applicable charging

identifiers shall be passed, if such identifiers are available. Passing corresponding AVP's is done through PCRF. Charging identifier which are exchanges are:

Access-Network-Charging-Identifier-Gx (generated by PCEF)

AF-Charging-Identifier (generated by AF)


FN42431EN80GLA0


29

2.2.6 Provisioning of event triggers

Event triggers are used to determine which event causes the GGSN to re-request

PCC rules. The PCRF provides one or more event triggers within one or more Event-Trigger AVP to the GGSN. GGSN should inform PCRF about new event only if this event was requested from PCRF.

The PCRF provides applicable event triggers in the CCA or RAR commands using

Event-Trigger AVP's.

The PCRF removes all previously provided event triggers by providing the Event-

Trigger AVP set to the value NO_EVENT_TRIGGERS. When an Event-Trigger AVP is provided with this value, no other Event-Trigger AVP is provided in the CCA or

RAR command. Upon reception of an Event-Trigger AVP with this value, the GGSN does not inform PCRF of any event.

In case of IMS, the PCRF forwards indications of loss/recovery/release of the bearer from a GGSN to an AF. PCRF performs this function only if requested to by the AF.

2.2.7 Usage Monitoring

3GPP Release 9 (TS 29.212, R.9) has defined procedures to support usage

monitoring and reporting to PCRF on the Gx interface. With this, Volume Based FUP via Gx interface is possible.

New AVP's are added for CCR and CCA message:

Usage-Monitoring-Information::= < AVP Header: 1067 > [ Monitoring-Key ]

[ Granted-Service-Unit ] [ Used-Service-Unit ] [ Usage-Monitoring-Level ]

[ Usage-Monitoring-Report ] [ Usage-Monitoring-Support ] *[ AVP ]

Granted-Service-Unit ::= < AVP Header: 431 > [Tariff-Time-Change ] [CC-Time ]

[CC-Total-Octets ] [CC-Input-Octets ] [CC-Output-Octets ]

[CC-Service-Specific-Units ]


FN42431EN80GLA0


30


FN42431EN80GLA0


31

3 Extended Features


FN42431EN80GLA0


32

Extended Features:

Special Features

Fair Usage Policy Subscriber Profile Repository Rapid policy suite

Bill shock prevention. Round off volume accumulation Subscriber notification

Generic Plug-in Interface Multiple IP-CAN session

VoLTE and Rx applications support

Emergency call Multimedia priority Service (MPS) SIP Forking


FN42431EN80GLA0


33

3.1 Special Features

3.1.1 Fair Usage Policy

Operators are looking for a solution which allows them to identify and regulate subscriber resource usage. This makes it possible for them to offer that the best

quality of service is available to the maximum number of users.

Function in the PCS (PCRF) which performs regulation of resources on subscriber

usage, based on subscriber data and information from PCEF is called Fair Usage Policy (FUP) Engine.

FUP takes care of fair distribution of resources, making that users consume what

they have subscribed for.

Subscriber Data are written in Subscriber Profile, placed in Subscriber Profile

Repository (SPR).

As a result of policy evaluation, SMS, with help of SMS Center (SMSC), can be sent to the affected subscriber.


FN42431EN80GLA0


34

3.1.2 Implementation of FUP Engines in PCS

Fair Usage Policies can be implemented in different ways, based on the interface between the PCS and the PCEF:

Gx FUP Engine based on Diameter protocol

Gy FUP Engine based on Diameter protocol

This type of FUP engine is also called Diameter Credit-Control Application (DCCA)

Radius FUP Engine based on Radius protocol

This type of interface is used due to the fact that many PCEF's do not support Diameter but Radius. Radius accounting is specified in RFC 2866

All types can use Subscriber Profile Repository (SPR) for subscriber data. The PCS pulls the subscriber data from SPR using e.g. MS-ISDN key received from the

PCEF. Then the PCS verifies data received from the SPR, applies the policies applicable for each subscriber, and sends the appropriate response to the PCEF.

SPR can be external or internal Data Base. External Data Base is used for

commercial purpose, internal for trial only.

There are two possible solutions for External Data Base:

SPR with Sh interface (e.g. Home Subscriber Server cluster, HSSc)

SPR with Sp interface and LDAP (lightweight directory access protocol).

Example: One Network Directory Server (One-NDS)

In trial version internal Data Base is used as SPR.

TIP Gy and Radius Interface are supported only on request.


FN42431EN80GLA0


35

Example: Gx FUP Engine based on Diameter protocol: Volume Based Policy

This type of FUP is possible when PCS and PCEF support Diameter Protocol over Gx according to 3GPP Release 9 (TS 29.212 R9).

Message flow for Volume Based Policy:

1. The GW receives an Establish IP-CAN from Client

2. The GW sends a CCR to the PCS.

3. The PCS stores this information.

4. If the PCS sends a request to the SPR: Profile Request.

5. The SPR replies with Profile Response.

6. Policy Rule Engine analyzes access rules and PCS selects PCC Rule(s) to be

installed.

7. The PCC Rules are provisioned by the PCS to the GW using Diameter CCA.

8. The GW installs the received PCC Rules and

9. sends to user that IP CAN session is established

10. After some time GW can send to the PCS CCR-U (update).

11. , 12., 13., 14.: these steps are like steps: 3, 4, 5,and 6.


FN42431EN80GLA0


36

1 © Nokia Siemens

Netw orks

Gx FUP Engine: Volume based policy

GGSN/PDN-GW PCS SPR

3. Store Information

8. Install PCC

Policy enforcement

1. Establish IP CAN

Session Request

2. CCR-I

4. Profile Request

5. Profile Response

7. CCA-I

6. PCC Rules Decision

10. CCR-U

14. CCA-U

UE

9. Establish IP CAN

Session Request

11. Profile Request

12. Profile Response

13. PCC Rules Decision

.

.

.

.

.

.

Fig. 11


FN42431EN80GLA0


37

3.1.3 Subscriber Profile Repository (SPR)

Subscriber data are getting more and more attention from customers who are looking at deploying Policy Control in their networks. Subscriber Data are written in

Subscriber Profile, placed in Subscriber Profile Repository (SPR).

The 3GPP specifications for release 7 and LTE specifies the Sp as an interface to an

external subscriber profile repository called as SPR. However, the 3GPP has not specified any protocol for the Sp interface. The 3GPP also defines Sh interface to access the data from the HSS.

PCS-5000 can support two different types of Data Base:

Internal Data Base, for trial only

External Data Base, for commercial purpose.

Solutions for External Data Base:

The SPR with Sh interface, based on Diameter protocol.

It can be Home Subscriber Server Cluster (HSSc) or any other data base.

The SPR with Sp interface, based on LDAP protocol.

Example: One network directory server (One-NDS), as part of the Home Subscriber server Distributed (HSSd).

Multiple SPR with both Sh and Sp interface.

SPR as plug-in


FN42431EN80GLA0


38

Operator should specify if SPR is used or not via PCM in following way:

xml file: PCS_ServiceConfigParams.

Parameter: SPR-Interface.

value of this parameter for any type of external data base: MULTIPLE_SPR

General rule for any kind of SPR is: The PCS pulls the subscriber data from SPR using the key received from the PCEF.

Then the PCS verifies data received from the SPR, applies the policies applicable for each subscriber, and sends the appropriate response to the PCEF.

Subscriber Profile Repository

PCS provides onbord SPR

Onbord SPR

Integrate via LDAP & SOAP I/F with

the One-NDSdirectly

One-NDSas SPR

Integrate via Sh (Diameter) I/F to fetch subscriber profile from HSS

HSScas SPR

PCS also supports Multiple-SPR (Dual) repositories in parallel

SOAP

LDAP

Sp Sh

Diameter

Any kind of Data Base which support Sh I/F

Sh interfacefor SPR

Sh

Diameter

Plig-in SPR

Dat Baase with user-specific I/F

Fig. 12


FN42431EN80GLA0


39

For every new Attribute, the operator must define which Data Base it belongs to:

LDAP-Interface

Sh-Interface

Local-DB-Interface

Plug-in Interface

Update of the SPR is completely configurable by the operator. The operator can indicate:

when the Attribute is updated

which Attributes to update

what Attribute value is to be used

which Attribute should be reset at the end of a Billing Cycle

Fig. 13


FN42431EN80GLA0


40

3.1.4 Policy evaluation with/without SPR

Policy control can also be done in the absence of subscriber profile repository (SPR)

data. PCS does the policy evaluation based only on AVPs.

SPR search info

PCS-5000 allows the operator to selectively apply this feature for the desired

Subscriber Id or Ids. The subscriber Id or Ids, for which the policy evaluation must happen by checking the SPR data, must be specified. It is done in PCS_HostSpecificConfigParams.xml.

Following filters are possible:

Best match:

The prefix of the Subscriber Id is specified. PCS checks the SPR data for all the

requests which Subscriber Ids start with the mentioned prefix.

Exact match:

Particular Subscriber Id, for which the SPR data must be checked before policy evaluation, is specified.

Range:

The range of Subscriber Ids, for which SPR data must be checked before policy evaluation, is specified. .

The operator can apply only one filter rule at a time.

When PCS receives a subscriber request, it first checks if the Subscriber Id of the

calling subscriber matches with the specified subscriber Id (through best match, exact match or range ). If yes, then it checks for SPR data and then does the policy evaluation. If not it does a policy evaluation without fetching the SPR data.

If the operator does not specify any range, then by default PCS-5000 checks for the

SPR data.


FN42431EN80GLA0


41

3.1.5 Sh Interface to SPR

The Sh interface, between the PCS and SPR is based on Diameter protocol. It allows

a Diameter server and a Diameter client to download and update user data. Sh interface is specified in 3GPP TS 29.329.

Supported data handling procedures:

Download of data from the SPR to the PCS

Update of data in the SPR

Subscribe to notifications from SPR

Receive notifications from SPR

User data handling Messages:

1) Data read - Sh-Pull This procedure is invoked by the PCS to read transparent and/or non-transparent

data for a specified user from the SPR. It is mapped to the commands: User-Data-Request/Answer (UDR/UDA) in the Diameter protocol.

2) Data update - Sh-Update This procedure is invoked by the PCS to update the transparent (repository) data

stored at the SPR. It is mapped to the commands: Profile-Update-Request/Answer (PUR/PUA) in the Diameter protocol.

3) Subscription to notifications - Sh-Subs-Notif This procedure is invoked by the PCS to subscribe to notifications when

transparent and/or non-transparent data for a specified user is updated. It is mapped to the commands Subscribe Notifications Request/Answer (SNR/SNA)

4) Notifications - Sh-Notif

This procedure is invoked by the SPR in order to notify changes in the user data. It is mapped to the commands: Push-Notification-Request/Answer (PNR/PNA) in the Diameter protocol.


FN42431EN80GLA0


42

Call flow in case of SPR with Sh Interface

1. PCEF sends a CCR to PCS for service access or update request. In the CCR

PCEF sends subscriber-Id information. PCS uses the subscriber-Id to access SPR repository.

2. The PCS sends User Data Request (UDR) message on Sh interface asking for subscriber related information from SPR.

3. SPR responds with a User Data Acceptance (UDA) message with subscriber

details.

4. PCS does a policy evaluation using the CCR information and subscriber data

received from SPR.

5. According to policy evaluation, PCS responds to PCEF with a CCA.

6. If the policy results into any repository update like updating accumulated volume, PCS sends Profile Update Request (PUR) message to SPR.

7. SPR updates the subscriber data and replies with Profile Update Response

(PUA).

8. If there are any updates done on the repository data through provision gateway

(PGW),

9. SPR sends Push Notification Request (PNR) message to PCS informing changes.

10. PCS updates the cache and replies with a Push-Notification-Answer (PNA).

11. PCS does a policy evaluation and then

12. sends a Diameter RAR (Re-Auth-Request) to request that the GW installs,

modifies or removes PCC Rules and updates the policy decision.

13. The GW sends RAA (Re-Auth-Answer) to acknowledge the RAR


FN42431EN80GLA0


43

Call flow in case of SPR with Sh Interface PCS SPRGGSN/PDN-GW PGW

2. UDR (User Data Request)

3. UDA (User Data Answer)

1. CCR

5. CCA

6. PUR (Profile Update Request)

7. PUA (Profile Update Answer)

9. PNR (Push Notification Request)

10. PNA (Push Notification Answer)

8. Data update

12. RAR

13. RAA

4. Policy evaluation


Fig. 14


FN42431EN80GLA0


44

3.1.6 One-NDS

One NDS is developed as part of HSSd (Home Subscriber Server distributed). The

HSSd is innovative separated and distributed database architecture. It is based on the concept of separating and distributing application logic and application data. The HSS application logic is implemented in a suitable number of HSSd front ends (HSS-

FE) and application data in One-NDS.

PCS can access data from one NDS via Sp interface using standard LDAP protocol

(Lightweight Directory Access Protocol). LDAP protocol is specified in RFC 4511 specification.

In order to track the notifications (trigger) from the one-NDS, Simple Object Access

Protocol (SOAP) will be used. Triggers are generated by One-NDS towards PCS-5000 in case of Add /Delete /Modify of data in One-NDS from Provision Gateway (PGW).

Data stored in One-NDS is segregated into the following two categories:

Subscriber related data

Subscriber information is NOT locally stored in PCS-5000. In case of subscriber information change/deletion, DB trigger can internally trigger some policy enforcement.

Example: pcsPricingPlan, pcsServiceId, pcsUsedUplinkQuota, pcsUsedDownlinkQuota….

Non-subscriber related data (NSR)

Non-subscriber data is locally stored (cached) in PCS-5000. When PCS comes up, it requests for all NSR data, and caches it. In case of NSR data change, SOAP trigger for NSR data change is received and the changed data is cached in PCS.

Non subscriber data which are use by the PCS are: 1. Qos, Search key: Qos name 2. Device, Search key: Tac

3. Services, Search Key: Service Id

NOTE

Simple Object Access Protocol (SOAP) is a protocol specification for exchanging

structured information in computer networks. It relies on Extensible Markup Language (XML) as its message format, and usually relies on other Application Layer

protocols (HTTP) for message negotiation and transmission.

http://en.wikipedia.org/wiki/Protocol_%28computing%29

http://en.wikipedia.org/wiki/Computer_network

http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/Application_Layer

http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol


FN42431EN80GLA0


45

One-NDS

Read/Write access:

LDAP Protocol

Trigger:

SOAP

PCS

One

NDS

NOT locally stored in PCS-5000

Example:

pcsPricingPlan,

pcsServiceId,

pcsUsedUplinkQuota

Search Key: IMSI/MSISDN

Non Subscriber Related Data

Locally stored in PCS-5000

Qos, Search key: Qos name

Device, Search key: Tac

Services, Search Key: Service Id

Subscriber Related Data

Fig. 15

Provisioning

Application: HSS

Logic Logic Logic

Common Data Storage (subscriber repository)

Application: HSL Application: PCS

ONE-NDS

HSSd

Front-End:

LDAP

Fig. 16


FN42431EN80GLA0


46

One-NDS to PCS initialization call flow

After activation of a project, PCS sends a request to the One-NDS for NSR data, to initialize its local Data Base.

PCS handles NSR data change triggers. If NSR data changes, e.g. some parameter

of some Service changes, it is cached in the PCS, but it has no effect on existing sessions, and the new values are reflected only from next session onwards.


FN42431EN80GLA0


47

One-NDS initialization call flow

Activate Project

PCM

GUI PCS

NSR data Request

NSR data Response

One

NDS

Updates local

cache

SOAP/XML Notify

SOAP/XML Notify-Ack

PGW

Data update

Fig. 17


FN42431EN80GLA0


48

Call flow in case of SPR with Sp Interface

For every new session, a request is sent to OneNDS to get the latest data.

PCS handles NSR data change triggers.

Notification handling for subscriber related data change has not been implemented, but the design is ready and will be taken up in future releases.

1. PCEF sends a CCR to PCS for service access or update request. In the CCR

PCEF sends subscriber-Id information. PCS uses the subscriber-Id to access One-NDS repository.

2. The PCS sends LDAP profile Read Request message asking for subscriber related information from One-NDS.

3. One-NDS responds with a LDAP profile Read Response message with the

subscriber details.

4. PCS does a policy evaluation using the CCR information and subscriber data

received from One-NDS,

5. According to policy evaluation, PCS responds to PCEF with a CCA.

6. If the policy results into any repository update like updating accumulated volume, PCS sends a LDAP profile update request to One-NDS.

7. One-NDS updates the subscriber data and replies with LDAP profile update

response.

8. If there is any update done on the repository data through provision gateway

(PGW),

9. One NDS sends SOAP/XML notification message.

10. PCS replies with a SOAP/XML notification acknowledge message.

11. PCS sends LDAP profile Read Request message to One-NDS asking for subscriber related information.

12. One-NDS responds with an LDAP profile Read Response message.

13. PCS does a policy evaluation,

14. If result of policy evaluation is changing Qos or Charging rules info, PCS sends

an RAR to PCEF indicating the change.

15. PCEF replies with an RAA.


FN42431EN80GLA0


49

One-NDS to PCS end-to-end call flow

PCSOne

NDSPCEF PGW

2. LDAP Read Req

3. LDAP Read Rsp

1. CCR

5. CCA

6. LDAP Update Request

7. LDAP Update Response

8. Data update


9. SOAP/XML Notify

10. SOAP/XML Notify-Ack

11. LDAP Read Req

12. LDAP Read Rsp


14. RAR

15. RAA

Fig. 18


FN42431EN80GLA0


50

3.1.7 Round off volume accumulation

PCS allows the operator to round volume usage, according to the near highest preset

volume.

Possible values are:

BYTES

KBYTES

MBYTES

GBYTES

TBYTES


FN42431EN80GLA0


51

3.1.8 Rapid Policy Suite

With Rapid Policy Suite, policies based on the service provider needs, can be

created dynamically, at run time. An operator can predefine new attributes and then use them in a new policy, which is based on its requirement. Attributes and policies are created through the PCM GUI.

PCS software needs not be modified for any new Attribute!

Attributes can be from SPR or from Diameter Interface, Gx or Gy:

Diameter Interface (Gx or Gy)

Before the introduction of RPS, only a small set of AVP's (Attribute Value Pair) were supported for policy evaluation. With RPS, PCS provides the option to the

operator to dynamically introduce any AVP.

SPR - database parameter.

Any data base parameter, from internal or external Data Base.

RPS - Rapid Policy Suite

GGSN/

DPI

PCRF

SPR

Diameter Interface (Gx,Gy)

Any Data Base parameter

can be used as parameter

in any policy

SPR

Any AVP on Diameter

Interface can be used as

parameter in any policy

Fig. 19


FN42431EN80GLA0


52

3.1.9 Notification Interface to SMS Center

As a result of policy evaluation, optionally a notification SMS can be sent to the

affected subscriber. In that case, Notification IF should be established between PCS and SMS Center.

SMS notification is a built-in feature of PCS. This feature provides a short message peer-to-peer (SMPP) interface towards SMS center (SMSC) to send SMS notifications to the subscriber. Notification to SMS Center is via SMPP (Short

Message Peer-to-Peer) protocol. PCS supports SMPPv3.4

PCS can be connected to only one SMS Center.

PCS provides, in addition, more options for subscriber notification. It is "Generic

notification plug-in", explained later.


FN42431EN80GLA0


53

Fig. 20


FN42431EN80GLA0


54

3.1.10 SMPP messages

Using the SMPP protocol, the PCS plays the role of ‘External Short Message Entity’

(ESME) and may initiate an application layer connection with an SMSC over a TCP/IP network connection and then may send (receive) short messages to (from) the SMSC respectively.

PCS connects to only one SMSC server in order to send a SMS Notification.

SMPP messages supported by PCS

bind_transmitter

bind_transmitter_resp

submit_sm

submit_sm_resp

unbind

unbind_resp

enquire_link

enquire_link_resp

With a bind request, PCS is registered in SMSC like an instance of an ESME. Thus, the Bind operation may be viewed as a form of SMSC login request to authenticate

the PCS wishing to establish a connection.

When the PCS has requested to bind as an "ESME Transmitter", by issuing a

bind_transmitter, and has received a response from the SMSC authorizing its bind request, then the PCS may send short messages to an SMSC for onward delivery to

a Mobile Station.

submit_sm is used by the PCS to submit a short message to the SMSC for onward

transmission to a specified Mobile Station.

PCS5000 periodically triggers enquire_link message to the SMSC after it is bound successfully with the SMSC. This message is sent in order to check the application

layer connectivity between PCS and the SMSC.


FN42431EN80GLA0


55

SMPP messages

PCS SMSC

bind_transmitter

bind_transmitter_resp

submit_sm

submit_sm_resp

unbind

unbind_resp

trigger

session establishment

submit message

session termination

Fig. 21


FN42431EN80GLA0


56

3.1.11 Generic Plug-in Interface

NSN has received a number of customer requirements where the handing of a use

case is needed in customer specific way.

In order to satisfy these kinds of requirements and to avoid changing of the code,

PCS provides the plug-in manager, and the plug-in framework.

Proprietary, Customer Specific adaptations are handled at the Plug-in. Plug-in is responsible for interface with external system. Interface with PCS core is realized

over Plug-in Manager.

Plug-in should be developed by the customer in Java.

Currently PCS provides support for integrating with the following plug-ins:

SPR plug-in

PCS supports connecting to various external profile repositories that use different

interfaces to connect to PCS. So, PCS provides the SPR plug-in that is customizable whenever there is a new type of external profile repository.

SPR Trigger plug-in

NSR Plugin

NSR Trigger Plugin

EDR (External Data Base Reporting plug-in)

This plug-in allow s the operator to select the required data to be reported when a policy is evaluated and use it for various purposes. Reporting plug-in allows: External third party DB Update On Policy Action Statistics Collection Logging


FN42431EN80GLA0


57

PCS

Core

LogicPolicy Rule

Engine

XX Diameter

Dispatcher

LDAP

Dispatcher

Ia Dispatcher

SOAP / XML

Dispatcher

Gx Dispatcher Rx Dispatcher…

PCS

Core

LogicPCS Core

Logic

Plu

gin

Ma

na

ge

r

GenericPluginProcess

PCS-5000

Plugin

Plugin

New process

C++ Entity

Java Entity

External

Systems

Fig. 22


FN42431EN80GLA0


58

3.1.12 Subscriber Notification plug-in

The Subscriber notification Interface of PCS provides mechanism for the operator to

send notifications to the subscriber using various interfaces. These interfaces are supported as part of Notification plug-in. The plug-in can be independently developed and integrated with PCS-5000 without resulting in any PCS software change.

Subscriber notification plug-in is an external module/library (java based) that can be included as part of PCS to achieve support for multiple notification interfaces.

Notification plug-in is called additionally Customer specific interface (CSI) adapter.

CSI adapter supports following types of notification interfaces:

SMTP

Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail (e-mail) transmission across IP network.

MM7

MM7 is used to send MMS (Multimedia Messaging Service). MMS is a standard way to send messages that include multimedia content to and from mobile phones (e.g. pictures, text pages and ring tones). It is a vendor-independent protocol,

specified by 3GPP and based on the concept of web services. The protocol uses HTTP for communication and utilizes SOAP/MIME/XML message format.

PAP

Push Access Protocol (PAP) is a protocol defined in WAP-247 of the Wireless Application Protocol suite. PAP is used to send content from Push Initiators to Push Proxy Gateways for subsequent delivery to narrow band devices (e.g.

cellular phones). Example messages include news, stock quotes, weather, traffic reports, and notification of events such as email arrival.

Initiation

The initialization function is called by PCS-5000 during the start up. The PCS Core then triggers the configured notification interfaces to be initialized.

http://en.wikipedia.org/wiki/Internet_standard

http://en.wikipedia.org/wiki/E-mail

http://en.wikipedia.org/wiki/Multimedia

http://en.wikipedia.org/wiki/Mobile_phone

http://en.wikipedia.org/wiki/Ringtone

http://en.wikipedia.org/wiki/Wireless_Application_Protocol

http://en.wikipedia.org/wiki/Wireless_Application_Protocol


FN42431EN80GLA0


59

Subscriber Notification plug in

PCS Core

email Server

MMS Server

Push ProxyGateway

SMTP- Simple Mail Transfer Protocol

MMS - Multimedia Messaging Service

PAP - Push Access Protocol

CSI - customer specific interface

NotificationPlug-in (CSI Scope)

SMTP stack

MM7 stack

PAP stack

CSI Scope

PCS Scope

PCSNotificationAdapter

Fig. 23


FN42431EN80GLA0


60

3.1.13 Billing cycle reset

Billing cycle reset functionality ensures that a subscriber's usage for a particular

service is measured over a given period. Once this cycle is over, the recorded usage is reset to zero. This is possible for both prepaid and postpaid subscribers.

PCS resets the billing cycle only upon receiving a CCR.

Operator can set or reset the billing cycle.

PCS supports the following types of resets:

Monthly reset

The reset of usage records happens on a fixed date of every month, according to the number defined by operator. Example:

BillingStartDate = 2010-01-10 BillingResetType=date BillingPeriod=10

Then, on the 10th of every month usage records are reset.

Duration based reset

The reset of usage records happens after the specified number of days from the BillingStartDate.

Example: BillingStartDate = 2010.01.10, BillingResetType=duration and BillingPeriod = 10. The next reset will take effect in 10 days = 2010.01.20. The reset after 20th Jan

2010 will take effect on 2010.01.30 and so on.

Hourly reset

The reset of usage records happens after the specified number of hours from the BillingStartDate. Example:

BillingStartDate = 2010-01-10-03:00:00 BillingResetType=hours BillingPeriod=10

Minute based reset

The reset of usage records happens after a specified number of minutes from the BillingStartDate.

BillingStartDate = 2010-01-10-03:00:00 BillingResetType=minutes BillingPeriod=10

Format supported :

For date and duration : YYYY-MM-DD

For hours and minutes: YYYY-MM-DD-HH:MM:SS


FN42431EN80GLA0


61

3.1.14 Multiple IP-CAN sessions

IP-CAN (IP Connectivity Access Network) session is the association between a UE

and IP Network. The association is identified by a UE IP address together with UE identity information, if available. An IP-CAN session incorporates one or more IP-

CAN bearers. Support for multiple IP-CAN bearers per IP-CAN session is IP-CAN specific.

An IP-CAN session exists as long as the UE IP address is established and announced to the IP network.

UE can have multiple IP-CAN session, multiple associations with same PCEF or

Multiple PCEF's.

IP-CAN sessions across different

gateways (GGSN can interact with the same or different PCS’s)

IP-CAN sessions for different services

IP-CAN sessions for different APN’s

IP-CAN bearers

IP-CAN session

Fig. 24


FN42431EN80GLA0


62

3.2 VoLTE Support

3.2.1 VoLTE and Rx applications support

Feature Description

PCS-5000 fulfils the pivotal functionality of providing Quality of Service parameters in combination with the P-CSCF in response to call setup requests for data services

engaging a dedicated bearer on LTE and also for IMS-based voice over LTE services. The realization of this is through the Gx/Rx interfaces.

QoS authorization in PCRF and selection of QoS parameters (e.g. QCI, ARP,

GBR, MBR, APN-AMBR)

QoS Authorization based on seamless mapping from bandwidth options from Rx

interface (received from P-CSCF from SDP to Media-Component-Description) or based on operator-defined policies

Operator defined policies could be based on Rx attributes such as media type, Gx

attributes such as RAT type and/or subscriber profile attributes such as subscription type

Dynamic creation/removal of PCC rules in PCRF and provisioning to P-GW

Default bearer QoS control

PCC rule enforcement in P-GW which may cause creation/removal of dedicated

bearers with specific QoS values

Main steps of QoS control of IMS services in LTE access

The figure shows a simple illustration of main NE interactions for establishment of a service.

As the UE is attached, default bearer is always established. The UE contacts the

Application server (P-CSCF in this case) which in turn contacts PCRF over Rx reference point along with Service information. PCRF would install the PCC rules as required, which may result in creation of dedicated bearer.


FN42431EN80GLA0


63

Dedicated bearer – GBR, VoIP QCI=1Dedicated bearer – GBR, VoIP QCI=1

MME

S-GW P-GWeNB

PCRF

1. Voice session setup in progress, mapping of SDP to Service Information

4. PCC rules installed and bearer created

P-CSCF IMS

2. Session information delivered to PCRF for QoS authorization

3. PCRF creates PCC rules and pushes PCC rules to P-GW.

RTP

5. Bearer Management in eNodeB and MME

Fig. 25


FN42431EN80GLA0


64

Call flow - Voice call establishment

A simplified view of call establishment from PCRF point of view is shown here.

Steps:

Gx session initiation results in establishment of default bearer

Default bearer QoS and APN AMBR may be controlled from PCRF via policy

control and PCRF may provide this in CCA

PCRF may optionally use SPR attributes for policy control. For this purpose, it will

issue profile read request and get response with Subscriber Profile.

When UE initiates a call, based on SIP signalling netween UE and P-CSCF, P-

CSCF will send AAR to PCRF containing service informaiton based on SDP information

PCRF does policy control based on Rx, Gx and SPR parameters based on operator policies

PCRF sends AAA towards CSCF

PCRF issues RAR towards P-GW containing Dynamic rules

Dedicated bearer for signalling may be established depending on the model used

Dedicated bearers for media may be established based on the policies or seamless mapping based on Rx parameters

There may be more than one AAR-AAA exchanges resulting in

establishment/modification/termination of bearers

When user terminates the call, STR will be issued by AF which will result in PCRF

removing the rules (resulting in removal of relevant dedicated bearers)


FN42431EN80GLA0


65

Optional

AF PCRF SPR

Rx AAR (MCDs)

Rx AAA

Profile Req

Profile Resp

2. Profile Req

3. Profile Resp

GW

GxCCR-I

GxCCA-I (optional default bearer QoS, APN AMBR)

GxRAR (Dynamic Rules for dedicated bearers)

GxRAA

GxCCR-T

GxCCA-T

GxSession Establishment

GxSession Termination

Profile Req

Profile Resp

Rx STR

Rx STAGxRAR (Rule removal to Terminate the bearers)

GxRAA

Profile Req

Profile Resp

Policy evaluation

Policy evaluation

Policy evaluation

Policy evaluation

Session Binding

Rx call

initiation

Rx call termination

Fig. 26


FN42431EN80GLA0


66

3.2.2 Emergency call

To establish Emergency call some operators uses fall back to circuit switching

network. But some "green field operators" are relaying on 4G network and use VoLTE. According to government regulation, PCS support IMS emergency sessions based to 3GPP standards (TS 22.101). Calls to Police, Ambulance, Fire Brigade,

Marine Guard, Mountain Rescue etc are treated as emergency calls. Operator shall specify preferred emergency call numbers according to numbering plan, (e.g. 991 or 110, 111…).

Emergency call is treated differently than normal call. Following cases is supported:

UE is subject of service restrictions. For example, UE is in the cell in a forbidden

PLMN or in a forbidden LA.

UE is without a SIM card.

Emergency call should be established even in case of high load. Due to their high

priority, emergency session should get certain fixed QoS. Based on the operator requirement, the session may be given higher priority (ARP)

PCS recognizes emergency call according to:

AVP on Gx Interface: Called station Id (Emergency APN).

Example: emergency.lte.mnc099.mcc234.lte emergency.lte.mnc099.mcc234.gprs

AVP on Rx Interface: Service URN

Example: sos.fire, sos.ambulance. This AVP is normally not changed from country to country, from operator to

operator

Both AVP's are defined in the PCS, via PCM.


FN42431EN80GLA0


67

1 © Nokia Siemens Networks

Emergency Session

Gx

PCS

5000

PCEF

Rx

AF

Rx Attributes: Service-URN

Example:

sos.fire, sos.ambulance

Gx Attributes:Called station Id AVP: Emergency

APN

Example:

emergency.lte.mnc099.mcc234.lte

emergency.lte.mnc099.mcc234.gprs

SPR

PCS applies QoS/ARP for

Emergency calls

1

3GPP : TS 22.101

Fig. 27


FN42431EN80GLA0


68

Call flow for Emergency Call

1. UE sends request for the session to GW (PCEF).

2. GW sends CCR to PCS. PCS compares APN - AVP from message with configured emergency APNs. If matched, PCS marks the session as emergency call.

SPR query is not performed.

3. In CCA is sent preconfigured QoS through Policy (default bearer).

5. According to SIP Invite, PCEF recognize Emergency call and sends

6. AAR with Emergency Service URN to the PCS.

PCS verifies UE IP associated with EC on Gx. PCS makes authorization and policy decisions configured by operator for

Emergency Call.

8. PCS sends RAR to modify Emergency Bearer.

9. GW confirms with RAA.

Messages that follow are like in normal VoLTE call flow.


FN42431EN80GLA0


69


Call Flow

1. Create Session Req

2. CCR-I

3. CCA-I

4. Create Session Resp

5. Sip Invite/Registration

6. AAR

7. AAA

8. RAR

9. RAA

10. 183

UE PCSGW AF

. . . . . . . . . . .

Fig. 28


FN42431EN80GLA0


70

3.2.3 Multimedia priority Service (MPS)

Priority Call

Priority call is generated by priority user. Priority user should be authorized by

operator. It is normally members of Government, Policy or Army. Multimedia Priority Service (MPS) allows priority users to obtain radio and network resources with priority. When invoked, the user of such service should be given preferential

treatment. For this purpose, PCS supports IMS MPS services as per 3GPP standards (3GPP TS 24.229). MPS session is normally given higher priority.

Priority call should never fail, apart from network (over)load condition.

To support MPS, PCS will need:

Extension Package

Policy

MPS can be:

SPR based:

priority user is defined with SPR attribute: MPS Id

Rx based:

1. MPS-Identifier AVP, in in AA-Request. 2. Reservation-Priority, in AA-Request (session level) or in Media-Component-Description AVP to assign (priority is assign to the IP flow).

.


FN42431EN80GLA0


71


SPR based Priority

CCR-I

Read Subscriber Record

MPS Id, Res Priority

SPR Attr : MPS Id

Attr Datatype = String

Attr Value == NGN GETS

CCA-I [Default-EPS-Bearer-QoS ]

PCEF PCSSPR

Policy evaluation

QCI/ARP decided by Policy

AF

Fig. 29

SPR based Priority call: session modification

PCEF PCSSPR

1

RAR [Default-EPS-Bearer-QoS ]

Read Subscriber Record

MPS Id, Res Priority

SPR Attr : MPS Id



QCI/ARP decided by Policy

RAA

Normal Default estb.

SOAP Trigger [MPS id modified]

AF

Fig. 30


FN42431EN80GLA0


72

Rx based: priority

P-CSCF can receive an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field. In both cases appropriate priority value in

SIP signaling is included. If the P-CSCF then recognizes the need for priority then shall include:

MPS-Identifier AVP,

which contains the national variant for MPS service name indicating MPS session. If the PCRF receives the MPS-Identifier AVP indicating an MPS session, the PCRF may take specific actions on the corresponding IP-CAN to ensure that the

MPS session is prioritized.

Reservation-Priority AVP:

This AVP can be present in AA-Reqest or in Media-Component-Description AVP.

Reservation-Priority in AA-Request provides the relative priority for a session while the Reservation-Priority at the media-component-description provides the relative priority for an IP flow within a session.

If the priority value is unknown, then is populates with default value. In the PCS V8, this AVP is still not supported.

.


FN42431EN80GLA0


73

Rx based Priority call

PCEF PCSSPR AF

RAR [Default-EPS-Bearer-QoS ]

AAR-Initial [MPS Id]

Interface Attr : Rx MPS Id



RAA

AAA

RAR [Dynamic Rules – QoS based on Priority]

RAA

Default Bearer Upgrade

and Dedicated Bearer

creation can be done in a

single RAR

Fig. 31

Rx Priority call – termination

STR

STA

RAR to terminate Dedicated Bearer

Check if Priority user

RAR [ Default-EPS-Bearer-QoS Downgrade]

If [Not Priority user]

PCEF PCSSPR AF

Fig. 32


FN42431EN80GLA0


74

3.2.4 SIP Forking

In VoLTE scenario there are cases, where a given request to a destination is

simultaneously forked to multiple end-points. In such a case, it gives the called user a flexibility to answer the call from a desired endpoint.

Forking also can happen for personalized ringtone or network announcements. For

this purpose, PCS supports SIP-Forking as per 3GPP TS 23.228. The related UE procedures are described in 3GPP TS 24.229.

Example:

SIP requests is routed to a specific Public User Identity: [email protected]

This call is proxied to multiple registered contact addresses:

[email protected] [A mobile phone client]

[email protected] [A laptop client]

+49-89-12345678 [A land-line client]

P-CSCF becomes aware of the forking only when a subsequent provisional response arrives for a new early dialogue. Then the P-CSCF shall use an AA request within the existing Diameter session containing the SIP-Forking-Indication AVP with value

SEVERAL_DIALOGUES When receiving an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, the PCRF shall identify the existing authorization

information for that AF session.. The PCRF shall authorize the maximum bandwidth required by any of the dialogues, but not the sum of the bandwidths required by all dialogues. Thus, the QoS

authorized for a media component is equal to the highest QoS requested for that media component by any of the forked responses.

SIP-Forking-Indication AVP

The SIP-Forking-Indication AVP (AVP code 523) is of type Enumerated, and describes if several SIP dialogues are related to one Diameter session. Possible values are:

SINGLE_DIALOGUE (0)

This value is used to indicate that the Diameter session relates to a single SIP dialogue. This is the default value applicable if the AVP is omitted.

SEVERAL_DIALOGUES (1) This value is used to indicate that the Diameter session relates to several SIP

dialogues

mailto:[email protected]




FN42431EN80GLA0


75

SIP Forking

SIP

Forking

Indicator

Single Dialogue

Handle as Normal call

Several Dialogues

-

• Check the Bandwidth against which it was previously allocated

• Assign whichever is greater

if previous one was greater, no need to change

If this one is greater, this one needs to be assigned

• Similar check for flow status(enabled if previously enabled)

3GPP TS 23.228

Fig. 33

Forking call Flow

AAR

AAARAR

RAA

IP-Can Session Established

AAR

AAARAR

RAA

Session Id 1

SIP Forking Ind

MCD

MCD-Number 1

Media-Type Audio

Codec-data 50330 RTP

Max DL 10K

Max UL 20K

MSCD

Flow-Number 1

Flow-usage 0 (RTP)

Flow-status Enabled

Charging Rule Install

Rule Rame 30

Flow Status ENABLED

QoS Info

Max DL 10K

Max UL 20K

QCI 4

ARP 1Session Id 1

SIP Forking IndSeveral-Dialogues

MCD

MCD-Number 1

Media-Type Audio

Codec-data 50330 RTP

Max DL 20K

Max UL 10K

MSCD

Flow-Number=1 1

Flow-usage 0 (RTP)

Flow-status Disabled

Charging Rule Install

Rule Rame 30

Flow Status ENABLED

QoS Info

Max DL 20K

Max UL 20K

QCI 4

ARP 1

PCRF applies higher QoS from whichever existing flow or

new flow with SIP-Forking indication, and install it to PGW.

PCEF PCSSPR AF

Fig. 34


FN42431EN80GLA0


76

Documents

01_FN42431EN80GLA0_PCS5000_General