ETSI GS INS 002 V1.1.1 (2010-09)

Identity and Access Management for Networks and Services Distributed Access Control for Telecommunications Use Cases and Requirements

DGS/INS-002

General Information

• Status: Published
• Publication Date: 02-Sep-2010
• Technical Committee: INS - Identity and access management for Networks and Services
• Current Stage: 12 - Completion
• Due Date: 08-Sep-2010
• Completion Date: 03-Sep-2010

Standards Content (Sample)

Group Specification
Identity and Access Management for Networks and Services
Distributed Access Control for Telecommunications
Use Cases and Requirements
2 ETSI GS INS 002 V1.1.1 (2010-09)

Reference
DGS/INS-002
Keywords
access, control, ID, management, network,
service
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS INS 002 V1.1.1 (2010-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 7
4 Current Landscape . . 8
4.1 General Access Control Frameworks . 8
4.1.1 IETF Geopriv Working Group Policies Frameworks . 8
4.1.2 eXtensible Access Control Markup Language . 9
4.1.3 Enterprise Privacy Authorization Language (EPAL). 10
4.2 Access Control in Telecommunications . 11
4.2.1 3GPP Policy Control and Charging (PCC) . 11
4.2.1.1 Application Function (AF) . 12
4.2.1.2 Subscription Profile Repository (SPR). 12
4.2.1.3 Policy Control and Charging Rule Function (PCRF) . 12
4.2.1.4 Policy and Charging Enforcement Function (PCEF) . 12
4.2.2 ETSI TISPAN Resource and Admission Control Sub-systems (RACS) . 13
4.2.2.1 Application Function (AF) . 14
4.2.2.2 Service Policy Decision Function (SPDF) . 14
4.2.2.3 Generic Resource and Admission Control Function (x-RACF) . 14
4.2.2.4 Border Gateway Function (BGF) . 14
4.2.2.5 Resource Control Enforcement Function (RCEF) . 14
4.2.3 ITU-T Resource and Admission Control Functions (RACF) . 15
4.2.3.1 Service Control Function (SCF) . 15
4.2.3.2 Policy Decision Function Entity (PD-FE) . 15
4.2.3.3 Network Attachment Control Functions (NACF) . 15
4.2.3.4 Transport Resource Control Functional Entity (TRC-FE) . 15
4.2.3.5 Policy Enforcement Functional Entity (PE-FE) . 16
5 Use Cases . 16
5.1 UC1: Software as a Service . 16
5.1.1 Description . 16
5.1.2 Actors . 16
5.1.2.1 Actors specific Issues . 17
5.1.2.2 Actors specific benefits . 17
5.1.3 Pre-Conditions . 17
5.1.4 Post-Condition . 18
5.1.5 Normal Flow . 18
5.2 UC2: Enterprise Environment . 19
5.2.1 Description . 19
5.2.2 Actors . 19
5.2.2.1 Actors specific Issues . 19
5.2.2.2 Actors specific Benefits . 19
5.2.3 Pre-Conditions . 20
5.2.4 Post-Conditions . 20
5.2.5 Normal Flow . 20
5.3 UC3: Roaming Network Access . 21
5.3.1 Description . 21
5.3.2 Actors . 21
5.3.2.1 Actors Specific Issues . 21
5.3.2.2 Actor Specific Benefits . 22
ETSI
4 ETSI GS INS 002 V1.1.1 (2010-09)
5.3.3 Pre-conditions . 22
5.3.4 Post-conditions . 22
5.3.5 Example Flow . 23
5.4 Summary Table of Use Cases. 23
6 Requirements . 24
6.1 General Access Control Framework Requirements . 24
6.1.1 Policy Management . 24
6.1.2 Decision . 25
6.1.3 Enforcement . 26
6.2 Distributed Access Control Requirements . 26
6.2.1 Policy Management . 27
6.2.2 Decision . 27
6.2.3 Enforcement . 27
6.3 Telecommunications Requirements . 28
6.4 Access Control and Identity Management Requirements. 29
6.5 Summary Table of Requirements and Map to Use Cases . 30
7 Conclusion . 32
Annex A (informative): Bibliography . 33
History . 34

ETSI
5 ETSI GS INS 002 V1.1.1 (2010-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Identity and access
management for Networks and Services (INS).
Introduction
Service and network providers need to restrict access to their functions in order to efficiently charge, protect critical
systems and offer personalization. While historically this has been the case for many years, a new type of access control
surrounding the user and its data becomes paramount in this day and age. Users are targeted by many different services,
not all of them friendly, and require mechanisms to protect their data and information. In addition, the more social
services are available, the more information about them is available and the harder it is to ensure that users' sensitive
data would not be easily subject to theft and misuse.
In the present document we analyse not only the requirements for access control related to identity management but also
bring this question one step further in considering that providers need to cooperate in order to enforce all the policies
related to that user's data. This cooperation can be achieved either by exchanging data about the user or the context of
the request, sharing policies or, in the case we will evaluate in this document, sharing the decision.
In the first part of the present document a summary of some of the activities around access control languages and
mechanisms can be found. The second part of the document presents those use cases which we consider present new
questions which are not yet addressed by other standardization activities. Finally, the third part of the document
introduces a set of requirements extracted from the use cases.
ETSI
6 ETSI GS INS 002 V1.1.1 (2010-09)
1 Scope
The present document will provide requirements on the use and application of distributed policy management, decision
and enforcement in a hybrid environment (operator and services domains).
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, and J. Rosenberg: "A Document
Format for Expressing Privacy Preferences for Location Information", Nov 2003 Feb 2006,
IETF draft (draft-ietf-geopriv-policy-08.txt).
NOTE: See http://tools.ietf.org/wg/geopriv/.
[i.2] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, and J. Rosenberg: "Common Policy:
A Document Format for Expressing Privacy Preferences", Feb 2004 Aug 2006,
IETF draft (draft-ietf-geopriv-common-policy-11.txt).
NOTE: See http://tools.ietf.org/wg/geopriv/.
[i.3] H. Tschofenig, H. Schulzrinne, A. Newton, J. Peterson, A Mankin, The IETF Geopriv and
presence architecture focusing on location privacy, Position paper at W3C Workshop on
Languages for Privacy Policy Negotiation and Semantics-Driven Enforcement, Ispra, Italy, 2006.
[i.4] IETF RFC 4745: "Common Policy: A Document Format for Expressing Privacy Preferences".
NOTE: See http://www.rfc-editor.org/rfc/rfc4745.txt.
[i.5] T. Moses, eXtensible Access Control Markup Language (XACML) Version 2.0 OASIS Standard,
Entrust Inc., 1 Feb 2005.
NOTE: See http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.
[i.6] IETF RFC 2753: "A Framework for Policy-based Admission Control".
NOTE: See http://www.ietf.org/rfc/rfc2753.txt.
[i.7] ISO/IEC 10181-3 (1966): "Information technology - Open Systems Interconnection -- Security
frameworks for open systems: Access control framework".
ETSI
7 ETSI GS INS 002 V1.1.1 (2010-09)
[i.8] Moses, T., ed., OASIS Privacy policy profile of XACML v2.0, OASIS Standard 1 Feb 2005.
NOTE: See http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-privacy_profile-spec-os.pdf.
[i.9] T.Moses et al.,"XACML Profile for Web Services", OASIS TC Working Draft,
September 29th, 2003.
NOTE: See www.oasis-open.org/committees/download.php/3661/draft-xacml-wspl-04.pdf.
[i.10] Anderson, A., ed., Core and hierarchical role based access control (RBAC) profile of XACML
v2.0; OASIS Standard, February 1, 2005.
NOTE: See http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf.
[i.11] Erik Rissanen et al., "XACML 3.0 administrative policy", working draft 07, 3 November 2008.
NOTE: See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml.
[i.12] IBM, Enterprise Privacy Authorization Language (EPAL), Version 1.2, 2003.
NOTE: See http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/.
[i.13] A. H. Anderson. A comparison of two 5, New York, NY, USA, 2006. ACM Press.
[i.14] IETF RFC 3261: "SIP: Session Initiation Protocol".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
AF Application Function
BGF Border Gateway Function
BGS Border Gateway Services
BTF Basic Transport Functions
CPN Customer Premises Network
EPAL Enterprise Privacy Authorization Language
FMC Fixed and Mobile Converged
GBR Guaranteed Bit Rate
GGSN Gateway GPRS Service Node
GPRS General Package Radio Service
IdM Identity Management
IdP Identity Provider
IP Internet Protocol
ITU-T International Telecommunication Union
MBR Maximum Bit Rate
NACF Network Attachment Control Functions
NAPT Network Address and Port Translation
NASS Network Attachment Sub-System
NAT Network Address Translation
NO Network Operator
OASIS Organization for the Advancement of Structured Information Standards
OCS On-line Charging System
PAP Policy Administration Point
PCC Policy Control and Charging
PCEF Policy and Charging Enforcement Function
PCRF Policy Control and Charging Rule Function
PD-FE Policy Decision Function Entity
PDG Packet Data Gateway
PDN Packet Data Network
PDP Policy Decision Point
PE-FE Policy Enforcement Functional Entity
ETSI
8 ETSI GS INS 002 V1.1.1 (2010-09)
PEP Policy Enforcement Point
PIP Policy Information Point
QoS Quality of Service
RACF Resource and Admission Control Functions
RACS Resource and Admission Control Subsystem
RBAC Role Based Access Control
RCEF Resource Control Enforcement Function
SaaS Software as a Service
SBP Service-Based Policy control
SCF Service Control Function
SDO Standards Development Organization
SDP Service Delivery Platform
SIP Session Initiation Protocol
SLA Service Level Agreement
SPDF Service Policy Decision Function
SPR Subscription Profile Repository
TRC-FE Transport Resource Control Functional Entity
UE User Equipment
WiFi Wireless Fidelity
WLAN Wireless LAN
WS Web Service
XACML eXtensible Access Control Markup Language
XML eXtended Mark up Language
4 Current Landscape
The need for Identity Management has surpassed the enterprise and web provider's world. Today, the need for Identity
Management is present whenever the user needs to login or the provider needs information about the user. Information,
authentication and authorization should be consistent and act as the glue between the different applications the user
interacts with.
Access Control is one important aspect in the user's control of his/her identity. In a Distributed Identity Management
Platform the user should be able to deal with various services, specify the preferences regarding the information
revealed, coordinate between different hierarchical entities of an Identity Management Platform.
Access policies have the tendency to grow more complex over time. A policy may also depend on (generic) privacy
policies which must be enforced by organizations due to legal regulations. Enterprises have complex policies
instantiated by different divisions. In case of SaaS, two major reasons come into play: on the one hand these services
could be composed from various elements, thus access to the service as a whole depends on access privileges from all
those providers. On the other hand, the SaaS domain can be outside of the enterprise domain. Both these reasons imply
that a monolithic policy definition is impractical. The key point of Distributed Access Control is to introduce an
abstraction or modularization which splits the policies into building blocks. Through these building blocks, specific
aspects (e.g. generic data privacy) could be specified. As each policy can have its own notion of subject, resources and
action, an important aspect is the mapping of these definitions between different sets of policies.
4.1 General Access Control Frameworks
4.1.1 IETF Geopriv Working Group Policies Frameworks
The IETF Geographic Location/Privacy (Geopriv) working group has defined a protocol that carries Geopriv location
objects (i.e. presence and location information). In term of privacy protection, the working group has published two
frameworks for authorization policies controlling access to application-specific data, especially location and presence
information; Common-Policy- [i.1] and Geopriv-Policy-Framework [i.2].
Whereas the Common-Policy, defines the basic rule structure using conditions, actions, transformations and provides a
resolution mechanism that considers the fact that authorization policies might be used and evaluated in a distributed
fashion, the Geopriv-Policy specifies several extensions of Common-Policy (i.e. with location-specific authorization
policies with respect to conditions among others, or with presence authorization rules to perform authorization decisions
for a presence based system) (see [i.3]).
ETSI
9 ETSI GS INS 002 V1.1.1 (2010-09)
In February 2007, the efforts of the Geopriv working group were standardized as RFC 4745 [i.4]. RFC 4745 [i.4]
combines location- and presence-specific authorization aspects and uses XML to specify the language in which the
privacy policy rules are to be represented.
The main purpose of the proposed policy framework is to protect the access on location and presence information.
A policy consists of several rules. Each of these rules again consists of three parts: conditions, actions and
transformations. A rule set defines conditions for data access and potential transformations/actions that should take
place with the data. Conditions specify who is allowed to access the data when and under which conditions;
e.g. whether the requested location information can be sent to the receiver or not. The transformation part of a rule
describes optional changes (i.e. reduction of the location information's precision) of the requested location information
before sending it to a requestor.
As identity, information serves any communication identifier, e.g. SIP address, mail addresses, etc. Validity restrictions
can limit the applicability of a rule to a specific time period. Finally, it is possible to restrict the access by so called
spheres, e.g. 'home', 'work', of the data owner. How this information is gathered is up to application specific realization.
The modification of rules is controlled by so called metapolicies, which describe who is allowed to insert, update or
delete a particular rule.
The RFC 4745 [i.4] common policy framework is designed to fulfil the needs of mobile application with requirement of
being efficient and can be extended to other application domains.
4.1.2 eXtensible Access Control Markup Language
The eXtensible Access Control Markup Language (XACML) [i.5] is a widely adopted standard language for expressing
both privacy and security policies in a machine-readable format (i.e. XML), developed and ratified by OASIS.
Basically, XACML provides the syntax for a policy language and the semantics for processing those policies. It has, in
accordance with RFC 2753 [i.6] and ISO 10181-3 [i.7], an abstract data-flow model and language model.
XACML policy language model, has three key components; rules that are the most elementary unit of a policy, they
contain much complex logic aiming to make XACML expressive and fit to handle different policy requirements; policy
that are combination of rules including a target, some obligations and an a rule-combining algorithm-identifier; and
policy-set composed of a set of policies and several obligations (see [i.5]).

Figure 1: XACML Architecture
ETSI
10 ETSI GS INS 002 V1.1.1 (2010-09)
The XACML data-flow model shown in Figure 1 includes request and response formats to query policies, as well as
semantics for determining validity of policies to the requests. Both request and response formats are seen as interface
between two other abstract components: Policy Decision Point (PDP) and Policy Enforcement Point (PEP). All access
requests for a protected data go through the PEP. The incoming access request together with other information (e.g. a
description of which action is to be performed on the protected data) are condensed by the PEP and send to the PDP as
request for an authorization decision. PDP then chooses the relevant policies to the decision request, along with any
additional information (e.g. obligations; actions PEP must tackle along with enforcing the authorization decision) in
some cases, evaluates the policies, and returns an authorization decision to the PEP. The resulted authorization decision
is either "allow access", "deny access", or "no policies apply to this access request". Based on the resulted authorization
decision, the PEP either grants or denies access to the requested data. Sometimes, neither "allow access" nor "deny
access" is result from the policies evaluation. An error is returned instead if the policies could not be evaluated or
retrieved.
The XACML 2.0 Standard defines several profiles, in order to tackle environments or technologies specifically
demands and requirements e.g. management of attributes in web services or expressing policies that use role based
access control. Another profile considers policy specification to archive privacy protection [i.8] or adopt parts of the
RBAC standard to XACML [i.10].
The Privacy policy profile of XACML was defined in the version 2 of the XACML Standard in order to aid
interoperability in the specification of privacy policies. It defines standard XACML Attribute identifiers for expressing
the purpose for which data is collected and the purpose for which data is being accessed. It also defines a standard rule
for requiring that the purpose for which data is collected must be consistent with the purpose for which data is being
accessed.
Another extension is the Web Services Profile of XACML (WS-XACML) [i.9]) that defines one Web Services Policy
Assertion targeting privacy concerns: The XACMLPrivacyAssertion. The XACMLPrivacyAssertion supports policy
agreement, privacy/confidentiality requirements for PII, specific resources or parts of XML documents, data retention
limits. Moreover, it fits into WSPolicy and can use P3P inside. XACMLPrivacyAssertion may be used to define privacy
and confidentiality requirements like "You must not release my personal information to any 3rd party", or "You may
keep my information less than 60 days."
A new XACML version, v3.0, is in preparation and will add generic attribute categories for administrative policy
(i.e. who is allowed to write policies about what) and delegation, extend and integrate current XACML assertion types
(e.g. the XACMLPrivacyAssertion) (see [i.11]).
4.1.3 Enterprise Privacy Authorization Language (EPAL)
The Enterprise Privacy Authorization Language (EPAL) is a formal language to express fine-grained enterprise privacy
policies, ratified by the W3C consortium [i.12]. At its core, EPAL focus on the primary privacy authorization while
abstracting data models and user-authentication from all deployment details.
In EPAL, privacy policy is defined as lists of hierarchical sorted data-, user-categories, and purposes and sets of privacy
related actions, obligations, and conditions. The user-categories define entities (users/groups) that use collected data
(e.g. travel expense department or tax auditor) while the data-categories set different categories of collected data that are
handled in different ways from a privacy perspective (e.g. medical-record vs. contact-data). Purposes and actions define
the service for which data is used (e.g. processing a travel expense reimbursement or auditing purposes), and how this
data is used (e.g. disclose vs. read) respectively. Finally, obligations and conditions set restrictions in regard of actions
(e.g. delete after 30 days or get consent) or context evaluation (e.g. "the user-category must be an adult" or "the
user-category must be the primary care physician of the data-subject").
Enterprise privacy languages, EPAL particularly, are mostly used for company internal purposes and they are more
fine-grained than the web privacy policy languages (i.e. XACML).
However, EPAL was not designed to be an all-round solution. For example, the manipulation of EPAL by data subjects
in order to set their preferences (e.g. providing information that enables the creation of user-preferences forms based on
the information given in an EPAL policy). In addition, Anderson [i.13] has shown that EPAL provides a subset of the
functionality that can be provided by XACML.
ETSI
11 ETSI GS INS 002 V1.1.1 (2010-09)
4.2 Access Control in Telecommunications
Policy-based resource control provides the network with the intelligence required to manage transport network
resources and adapt transparently to the different needs of running services and applications in aspects such as Quality
of Service (QoS), authentication, authorization, accounting and charging. Policy-based resource control functions
ensure that intended QoS is actually supported at the transport plane. This functionality is considered crucial for
telecom operators in order to deliver 4-play services (voice, data, video and mobility) over Fixed and Mobile Converged
(FMC) networks in a sustainable way. As such, different Standards Development Organizations (SDOs) have specified
policy-based resource management functionalities.
In the field of standardization related to access control in telecommunications, the Telecommunication Standardization
Sector of the International Telecommunication Union (ITU-T) has published the Resource and Admission Control
Functions (RACF) specification, intended for general networks. The European Telecommunications Standards Institute
(ETSI) has defined the Resource and Admission Control Subsystem (RACS), which targets fixed and mobile converged
space, while the Third Generation Partnership Project (3GPP) has developed the Policy Control and Charging (PCC)
Framework, specifically aimed for the mobile network environment that not only touches upon admission and resource
management but also addresses charging. Although there are some differences between the various SDO's architectures
(nomenclature, functional elements, research scope, and so on), the core concept remains the same, which is the clear
separation between control and transport, between functionality and access technologies. In Figure 2 a small overview
of all functional elements associated with access/resource control in the various mentioned SDO's network architectures
is presented.
Figure 2: Policy-related architecture elements in ITU-T/3GPP/ETSI NGNs
With regards to QoS, all the three leading standardization organizations mentioned centralize their activity on control
mechanisms for QoS guarantee, but do not address specific QoS technologies. They do have a unifying theme in their
architectures, which is to implement resource and admission control function between service control and access/bearer
layer in order to exercise control over resources of access/bearer nodes. The main aim is to shield specific technologies
and topologies of the access/bearer layer from the service control layer. After receiving a service relevant QoS
requirement from service control layer, resource control function combines it with the admission control strategies and
network topologies, converts the service relevant QoS requirement into the IP QoS requirement, and then sends those
requirements to related access nodes, bearer nodes and service gateway nodes. These nodes will then implement
requested QoS in accordance with the messages received from the resource control elements.
4.2.1 3GPP Policy Control and Charging (PCC)
The policy control and charging (PCC) architecture allows operators to perform service based QoS policy and flow
based charging control. PPC works on a service data flow level, and, as the name implies, provides the functions for
policy and charging control as well as event reporting for service data flows. Its functionality encompasses two main
functions:
• Flow Based Charging: including charging control and online credit control.
• Policy control including gating control and QoS control, among others.
ETSI
12 ETSI GS INS 002 V1.1.1 (2010-09)
Service flows are described by an aggregate set of packet flows characterized by identical source and destination IP
address and port numbers. The PCC binds transport and service information in such a way that charging and policy are
tied together to target heterogeneous transport networks. In the following paragraphs, a small description of each
functional element and their role in 3GPP's PCC architecture is presented.
4.2.1.1 Application Function (AF)
The AF offers applications that require dynamic policy and/or charging control over the IP access network user plane
behaviour. The AF communicates with the PCRF to transfer dynamic session information, required for PCRF decisions
as well as to receive network specific information and notifications about bearer level events. One example of an AF is
the P-CSCF in IMS. The PCRF may reject the service information request sent by the AF, and also inform it of service
information that it would accept. In that case, the AF rejects the service establishment towards the UE and if possible
the AF forwards the service information to the UE that the PCRF would accept. An AF may able to contact multiple
PCRFs, choosing the appropriate one based on either the users' IP address and/or a UE (User Equipment) identity that it
already is aware of.
4.2.1.2 Subscription Profile Repository (SPR)
The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies
and network bearer level PCC rules by the PCRF. The SPR may be combined with or distributed across other databases
in the operator's network, but those functional elements and their requirements for the SPR are not addressed.
4.2.1.3 Policy Control and Charging Rule Function (PCRF)
The PCRF is responsible for policy control decisions, flow based charging control, and monitoring capabilities (in
regards to user plane traffic). It provides network control regarding the service data flow detection, gating, QoS and
flow based charging (except credit management) towards the PCEF. Before accepting service information from the AF,
the PCRF applies the security procedures, as required by the operator and crosschecks the service information provided
by the AF to see if it is consistent with operator defined policy rules. It is also responsible for determining how a certain
service data flow shall be treated in the PCEF, and ensure that the PCEF user plane traffic mapping and treatment is in
accordance with the user's subscription profile.
The service information provided by the AF shall be used to derive the QoS for the service. As mentioned previously,
the PCRF may reject the request received from the AF when the service information is not consistent with either the
related subscription information or the operator defined policy rules and as a result the PCRF shall indicate that this in
the response to the AF, along with the service information that can be accepted by the PCRF (e.g. the acceptable
bandwidth).
To calculate the proper QoS authorization (QoS class identifier, bitrates), the PCRF uses the service information
received from the AF (e.g. SDP information or other available application information, for both session based and
non-session based services) and/or the subscription information received from the SPR.
4.2.1.4 Policy and Charging Enforcement Function (PCEF)
This functional entity is located at the Gateway (e.g. GGSN in the GPRS case, and PDG in the WLAN case). It provides
service data flow detection, user plane traffic handling, triggering control plane session management (where possible),
QoS handling, and service data flow measurement as well as online and offline charging interactions.
A PCEF ensures that an IP packet, which is discarded as a result from policy enforcement or flow based charging, is
neither reported for offline charging nor cause credit consumption for online charging. The PCEF is enforces the policy
control as indicated by the PCRF in two different ways:
• Gate enforcement: The PCEF only allows a service data flow to pass through it if and only if the
corresponding gate.
ETSI
13 ETSI GS INS 002 V1.1.1 (2010-09)
• QoS enforcement: The PCEF is able to convert a QoS class identifier value to specific access network QoS
attribute values and vice-versa. It is also in charge of PCC rule QoS enforcement, in which it enforces an
authorized QoS of a service data flow according to active PCC rules. Finally, the PCEF controls the QoS that
is provided to a combined set of service data flows. The policy enforcement function ensures that the resources
which can be used by an authorized set of service data flows are within the "authorized resources". The
authorized QoS provides an upper bound on the resources that can be reserved (GBR) or allocated (MBR) for
the access network bearer.
Enforcement of charging control policies is another function within the PCEF realm. For a service data flow (defined by
an active PCC rule) that is subject to charging control, the PCEF will allow the service data flow to pass through the
PCEF if and only if there is a corresponding active PCC rule with and, for online charging, the OCS has authorized
credit for the charging key. The PCEF may let a service data flow pass through the PCEF during the course of the credit
re-authorization procedure.
In short, for any service data flow (defined by an active PCC rule) that is subject to both Policy Control and Charging
Control, the PCEF will only allow it to pass through if and only if the right conditions from both policy control and
charging control happen, meaning that the corresponding gate is open and, in case of online charging, the OCS has
authorized credit for its charging key.
A PCEF may be served by one or more PCRF nodes. The PCEF shall contact the appropriate PCRF based on the packet
data network (PDN) connected to, together with, a UE identity information (if available, and which may be dependent
on the access network used).
4.2.2 ETSI TISPAN Resource and Admission Control Sub-systems
(RACS)
ETSI TISPAN architectural element related to access control can be surmised by 3 sub-systems: the Network
Attachment Sub-System (NASS), the Resource Admission Control Sub-System (RACS) and the Transporting
Processing Functions.
The Network Attachment Sub-System (NASS) provides registration at access level and initialization of User
Equipment (UE) for accessing to the TISPAN NGN services. The NASS provides network level identification and
authentication (based on user profile), manages the IP address space of the Access Network and authenticates access
sessions. The NASS also announces the contact point of the TISPAN NGN Service/Applications Subsystems to the UE.
Network attachment through NASS is based on implicit or explicit user identity and authentication credentials stored in
the NASS.
The Resource Admission Control Sub-System (RACS) is responsible for elements such as policy control, resource
reservation and admission control. In addition, it also supports core Border Gateway Services (BGS) including Network
Address Translator (NAT) mechanisms. The RACS provides policy based transport control services to applications,
allowing for the request and reservation of transport resources from access and core transport networks within its
coverage. By hiding the interaction between applications and transport resources, RACS ensures that applications do
not need to be aware of the underlying transport networks. As the network system responsible for policy based transport
control, RACS is able to perform admission control in order to evaluate those requests in the context of predefined
policy rules provisioned by the network operator. It may then perform resource reservation provided the request passes
the policy tests and appropriate resources are available in the transport network. In this way, RACS offers the operators
the means to perform admission control, which may be followed by the installation of bearer service policy rules. In
terms o
...