FAQ_Cvbs training result_ PCRF_V1.0_OCF_IN SWAP_0027009700 (1).docx
Document Details
Uploaded by ImpeccableSimile4266
Tags
Full Transcript
OCF\_IN SWAP PROJECT: PCRF V8.1 part 1 Ver 1.0 Report OCF\_IN SWAP PROJECT: PCRF V8.1 part 1\_Introduction, architecture, policying and configuration **Report Version: V1.0** []{#_Toc411586489.anchor}Revision History +---------+---------+---------+---------+---------+---------+---------+ | Ver...
OCF\_IN SWAP PROJECT: PCRF V8.1 part 1 Ver 1.0 Report OCF\_IN SWAP PROJECT: PCRF V8.1 part 1\_Introduction, architecture, policying and configuration **Report Version: V1.0** []{#_Toc411586489.anchor}Revision History +---------+---------+---------+---------+---------+---------+---------+ | Version | Drafted | Drafter | Reviewe | Mentor | Date | Locatio | | No | By | Email | d | Email | | n | | | (Name) | ID | By | ID | | on | | | | | :Mentor | | | IKNOW | | | | | Name | | | | +=========+=========+=========+=========+=========+=========+=========+ | 1.0 | Djomatc | Djomatc | Chen | chen.ku | 27-12-2 | | | | houa | houa.tc | kui | i8\@zte | 017 | | | | | hamaga\ | | soft.co | | | | | Idriss | @ztesof | | m | | | | | | t.com | | | | | +---------+---------+---------+---------+---------+---------+---------+ []{#_Toc503518622.anchor}Contents [[Revision History] 4](#_Toc411586489) [[Contents] 5](#_Toc503518622) [[Figures] 8](#_Toc283915664) [[TOPICS COVERED:] 9](#_Toc503518624) [[Document sommary] 10](#_Toc503518625) [ [Introduction to PCRF] 11](#introduction-to-pcrf) [[1.1] [OCS description] 11](#ocs-description) [[1.2] [PCRF description] 11](#pcrf-description) [ [PCRF Logical Network Architecture] 13](#pcrf-logical-network-architecture) [[2.1] [3GPP PCC Architecture] 13](#gpp-pcc-architecture) [[2.1.1] [Overview] 13](#overview) [[2.1.2] [Interface description] 14](#interface-description) [[2.2] [Network Topology of our project] 14](#network-topology-of-our-project) [[2.2.1] [Network Architecture] 14](#network-architecture) [[2.2.2] [Physical Connectivity] 15](#physical-connectivity) [ [PCRF Software Architecture] 18](#pcrf-software-architecture) [[3.1] [Data layer] 18](#data-layer) [[3.2] [Business Process Layer] 19](#business-process-layer) [[3.2.1] [PDE (Policy Decision Engine):] 20](#pde-policy-decision-engine) [[3.2.2] [SPR Proxy:] 20](#spr-proxy) [[3.3] [Communication Layer] 20](#communication-layer) [[3.4] [Business Configuration] 21](#business-configuration) [[3.5] [Infrastructure] 21](#infrastructure) [ [PCRF Function Modules] 22](#pcrf-function-modules) [[4.1] [PHUB function module] 23](#phub-function-module) [[4.2] [UIP function module] 23](#uip-function-module) [[4.3] [PDE function module] 24](#pde-function-module) [[4.4] [SPR Data Management] 24](#spr-data-management) [[4.5] [Statistic Analysis] 25](#statistic-analysis) [[4.6] [System Surveillance] 25](#system-surveillance) [ [PCRF Hardware Architecture] 26](#pcrf-hardware-architecture) [[5.1] [Overview] 26](#overview-1) [[5.2] [Policy Server] 27](#policy-server) [[5.3] [Data Base Server] 27](#data-base-server) [[5.4] [PHUB Server] 27](#phub-server) [[5.5] [UIP Server] 27](#uip-server) [[5.6] [OAM Server] 28](#oam-server) [ [Services features and call flow] 29](#services-features-and-call-flow) [[6.1] [Policy Decision Function] 29](#policy-decision-function) [[6.2] [QoS Control Function] 29](#qos-control-function) [[6.3] [Access Control Function] 29](#access-control-function) [[6.3.1] [Gating Control] 29](#gating-control) [[6.3.2] [URL Control] 30](#url-control) [[6.4] [Alerting and Redirection] 30](#alerting-and-redirection) [[6.5] [Sy/Sp Call Flow] 30](#sysp-call-flow) []{#_Toc283915664.anchor}Figures [[Figure 1:3GPP PCC Architecture] 13](#_Toc503518666) [[Figure 2: PCRF Network side architecture --connection with othes network elements] 15](#_Toc503518667) [[Figure 3: OCS and PCRF Co-Localized Physical Connectivity] 16](#_Toc503518668) [[Figure 4: PCRF Software Architecture] 18](#_Toc503518669) [[Figure 5: PCRF Data Layer] 19](#_Toc503518670) [[Figure 6:PCRF Business Process Layer] 19](#_Toc503518671) [[Figure 7: SPR Communication Layer] 21](#_Toc503518672) [[Figure 8: PCRF Function Modules] 22](#_Toc503518673) [[Figure 9: PHUB function] 23](#_Toc503518674) [[Figure 10: UIP function module] 24](#_Toc503518675) [[Figure 11: PCRF Hardware Architecture] 26](#_Toc503518676) []{#_Toc503518624.anchor}TOPICS COVERED: Following main topics will be covered through this document Introduction to PCRF ----------------------------------- PCRF Logical Network Architecture PCRF Software Architecture PCRF Function Module PCRF Hardware Architecture Services Features and call flow []{#_Toc503518625.anchor}Document sommary This document will guide you through all the technical steps related to the topics mentioned above. It contains both theoretical and technical knowledge of the above services. It contains screen shots, specific step by step flow of execution. Introduction to PCRF ==================== OCS description --------------- ZTE OCS product is a flexible and powerful Online Charging System. It can support charging by event, page, duration and volume. In PCC structure, the OCS performs online charging function for subscribers by interacting with PCEF. PCRF description ---------------- ZTE PCRF (Policy and Charging Rules Function) product is the cobitre network element developed for DATA Service. ZTE PCRF product strictly follows international standards for PCC structure including 3GPP. The PCRF is a functional element that encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF (Policy and Charging Enforcement Function). The PCRF take responsibility for Rule Management and Policy Decision for Prepaid and Postpaid Subscribers. By Deploying PCRF, Service Operators can flexibly provide various data services with various bandwidths and admission control for meeting marketing needs. The PCRF does network policy control based on the operator configured policies, and provides PCC (Policy and Charging Control) control rules to the PCEF. The PCRF can make policy decision based on subscriber Profile and service information that the subscriber is using. Date time and data usage accumulation can be factors to decide policy. PCRF deployed with co-localized architecture, rating and charging of data service are managed by OCS. ZSmart Policy Manager supports both predefined and dynamic rules: - Rules are configured at PCEF; multiple static rules could be bound as rules group. ZSmart Policy Manager can activate/deactivate predefined rules or rules group. - Rules are configured at ZSmart Policy manager, delivered to PCEF when needed. When external triggering condition alters, such as time stamp or roaming status, ZSmart Policy manager delivers new dynamic policy rules or activates new static policy rules if needed. PCRF Logical Network Architecture ================================= 3GPP PCC Architecture --------------------- ### Overview PCC is short for Policy and Charging Control defined in 3GPP R7 PCC is the architecture described by 3GPP R7 to solve the network resource control issue based on the existing network systems. ![](media/image3.png) []{#_Toc503518666.anchor}Figure 1:3GPP PCC Architecture - **BBERF:** Bearer Binding and Event Reporting Function - **PCRF:** the Policy and Charging Rules Function - **AF:** Application Function - **OCS:** Online Charging System - **OFCS:** Offline Charging System - **SPR:** Subscription Profile Repository ### Interface description +-------------+-------------+-------------+-------------+-------------+ | \# | Node A | Node B | Description | interface | +=============+=============+=============+=============+=============+ | 1 | PCRF | PCEF | PCEF sends | Gx | | | | | policy | | | | | | request DCC | | | | | | to PCRF, | | | | | | PCRF sends | | | | | | policy | | | | | | response | | | | | | DCC to | | | | | | PCEF. | | +-------------+-------------+-------------+-------------+-------------+ | 2 | OCS | PCEF | PCEF sends | Gy | | | | | charging | | | | | | request DCC | | | | | | to PCRF, | | | | | | PCRF sends | | | | | | policy | | | | | | response | | | | | | DCC to | | | | | | PCEF. | | +-------------+-------------+-------------+-------------+-------------+ | 3 | PCEF | GGSN/AAA | GGSN/AAA | Gi | | | | | sends | | | | | | radius | | | | | | accounting | | | | | | message to | | | | | | PCEF. | | +-------------+-------------+-------------+-------------+-------------+ | 4 | PCRF | SPR | SPR is | Sp | | | | | deployed | | | | | | together | | | | | | with OCS, | | | | | | PCRF gets | | | | | | subscriber | | | | | | information | | | | | | from SPR. | | +-------------+-------------+-------------+-------------+-------------+ | 5 | PCEF | ASN-GW | ASN-GW | Gi | | | | | sends | | | | | | radius | | | | | | accounting | | | | | | message to | | | | | | PCEF. | | +-------------+-------------+-------------+-------------+-------------+ | 6 | CRM | UIP | CRM send | SOAP | | | | | subscriptio | | | | | | n | | | | | | to ZTE | | +-------------+-------------+-------------+-------------+-------------+ | 7 | PCRF | OCS | Request of | Sy | | | | | policy | | | | | | counter | | | | | | status | | | | | | reporting | | | | | | from PCRF | | | | | | to OCS. | | | | | | | | | | | | Notificatio | | | | | | n | | | | | | of policy | | | | | | counter | | | | | | status | | | | | | change from | | | | | | OCS to | | | | | | PCRF. | | | | | | | | | | | | Cancellatio | | | | | | n | | | | | | of policy | | | | | | counter | | | | | | status | | | | | | reporting | | | | | | from PCRF | | | | | | to OCS. | | +-------------+-------------+-------------+-------------+-------------+ Network Topology of our project ------------------------------- ### Network Architecture The figure above present the network architecture regarding PCRF side in our IN Swap projet. []{#_Toc503518667.anchor}Figure 2: PCRF Network side architecture --connection with othes network elements ### Physical Connectivity We note that a PCRF test bed is include in our project. []{#_Toc503518668.anchor}Figure 3: OCS and PCRF Co-Localized Physical Connectivity OLC is the online collection server of OCS. It is the interface server between OCS and the external network elements. When the external NE sends message to OCS, OLC will first receive and transfer the message into DCC protocol, then sends it to the related OCS according to the distribution strategy. After the OCS finish the message process, OLC will receive the sent back message from OCS, and transfer the message protocol again and distribute it to each NE interface. UIP means Unified Interface Platform, it is also the interface server and communication application. Normally, it supports SOAP, MML, HTTP, SMPP protocols. ZMC (ZSmart Monitoring & Control ZMC) server is a part of ZSmart product, which is positioned as Element Management System (EMS). ZMC includes system monitoring, operation & maintenance and other functions as management entry of ZSmart business system and efficient assistant of maintenance engineer, which ensures system maintainability and reliability. PHUB parses the interaction protocols and provides multiple access methods as a bridge between ZSmart Policy Manager and other policy related network elements (such as PCEF, BBEF, AF, SPR and etc.) In the new co-localized solution, storage and SAN switch is also shared with Policy servers. To have better stability and fault tolerance, clusters are setup for each pair of servers to offer higher availability. PCRF Software Architecture ========================== []{#_Toc503518669.anchor}Figure 4: PCRF Software Architecture Data layer ---------- Manage the data, including classification, organizing, coding, storing, searching, maintenance (this content configuration management, system monitoring, statistic & analysis). There are three types of data stored in the database: - Session data (**session MDB** :ODBC) : information about the online subscriber, such as accumulation information, policy in use, start and expire time of the policy and session context - Static data (**PCC Rule SHM** : Pcache): information about the bundle and policy, such as behavior recognition, policy definition and bundle definition - Subscription data (**ZSPR** : ODBC) : information about subscriber and service subscription, such as subscriber profile and service subscriber []{#_Toc503518670.anchor}Figure 5: PCRF Data Layer Business Process Layer ---------------------- Include common and customized business process packages. There are two core modules: PDE and SPR Proxy. ![](media/image8.png) []{#_Toc503518671.anchor}Figure 6:PCRF Business Process Layer ### PDE (Policy Decision Engine): Policy Decision Engine is the core function module of ZSmart Policy Manager, PDE receives and decodes the message which is delivered by PHUB, then estimates subscriber behavior according to the policy engine, creates session, decides policy and finally outputs the proper policy. It contains the following sub-modules: - **Flow Engine** -- It drives the entire service process. - **Session Management** -- It manages lifecycle of each session and handles the recycle of exception session. - **Policy Decision** -- It matches the corresponded policy according to subscriber profile and subscriber event. - **Encoding/ Decoding** -- It performs encoding/decoding of DCC protocol. - **Advice of Policy** -- It generates the message when subscriber has to be informed by the policy server. Message will be sent through UIP. - **Behavior Analysis** -- It analyzes the subscriber behavior that is reported by PCEF and mapping it to predefined event. ### SPR Proxy: It performs the Sy/Sp messages processing Communication Layer ------------------- It is a bridge between ZSmart Policy Manager and other external systems. It parses the interaction protocols and provides multiple access methods to external policy related network elements. It also provides a SOA-based public interface platform which supports multiple protocols for the system easily extend applications related with external systems. This contains the PHUB and the UIP. []{#_Toc503518672.anchor}Figure 7: SPR Communication Layer Business Configuration ---------------------- Business configuration module enables functions such as adding, modification, deleting and refreshing of data, it provides independent configuration management operation interface to each type of data. It contains the following sub-modules: - Policy Management: It provides policy event, policy plan and other policy rule related configuration, maintenance and inquiry interface. - ZSPR Management: It provides interface of subscription information configuration, display and communication with PCRF. - Base Data Management: It provides configuration and maintenance of system-level parameters (including log, shared memory, types of event-trigger and etc.). Infrastructure -------------- It is the front-end supporting platform of ZSmart Policy Manager. It implements basic functions for the system normal running, such as alarming, statistic, monitoring and configuration. PCRF Function Modules ===================== The figure billow present a datailled overvieiw of all PRCF modules function we present above: ![模块图](media/image10.jpeg) []{#_Toc503518673.anchor}Figure 8: PCRF Function Modules Bellow we will presents some functions like: - - - - - - PHUB function module -------------------- - Parse the interaction protocols - Provide multiple access methods as a bridge between PCRF and other policy related network elements (such as PCEF, BBEF, AF, SPR and etc.) []{#_Toc503518674.anchor}Figure 9: PHUB function UIP function module ------------------- - UIP is a SOA-based public interface platform - Protocols can be easily plugged via adapter. - The notification message of policy changing will be sent through UIP when policy changes. []{#_Toc503518675.anchor}Figure 10: UIP function module PDE function module ------------------- The PDE is the core function module of PCRF. It is responsible of: - Flow control - Session management - Policy decision - Encoding and decoding DCC messages - Advice of policy - Behavior analysis SPR Data Management ------------------- The SPR Data Management manages the: - External SPR Access Proxy - ZSPR Data Management Statistic Analysis ------------------ For this function, we have: - Service statistic - Alarm statistic - Performance statistic System Surveillance ------------------- The main function of system surveillance module is: - Topology management - KPI collection - Service Track & Test - Log Management - Alarm Processing - Surveillance Console PCRF Hardware Architecture ========================== Overview -------- The figure bellow present an exemple of PCRF hardware architecture. []{#_Toc503518676.anchor}Figure 11: PCRF Hardware Architecture In this architecture we have some severals servers like: - Policy Server - Data Base Server - PHUB Server - UIP Server - OAM Server - iNMS Server - Backup Server (Optional) - Testbed Server (Optional) - Report Server (Optional) Policy Server ------------- The main function of policy server is to create, control and dispatch policies in real-time. - The PDE and SPR management module are deployed on the policy server. - The policy server uses UNIX dual-server (which works in hot-standby mode). Data Base Server ---------------- - Store policy information and subscriber information. - The database server uses UNIX platform (which works in hot-standby mode). - Oracle database software PHUB Server ----------- - PHUB runs the client-side application of real-time policy protocol. - UNIX or Linux platform - Dual-server which works in the hot-standby mode UIP Server ---------- - UIP provides connection with external systems through common protocols such as MML, WEB Services, SMPP and etc. - Dual-server (PC Server + Linux) OAM Server ---------- - Management and operation to services and system - Modules would be deployed on OAM server: - Business configuration module - Statistic analysis module - System surveillance module Services features and call flow =============================== Policy Decision Function ------------------------ PCRF supports very flexible policy plans for operators. The PCRF can provide **user-level policy** **control** and **service-level policy control**. For user-level policy control, PCRF can provide different bandwidths for different level subscriber such as Gold user, Silver user and Bronze user. And PCRF also supports different QoS at different time, day, month or year. When Subscriber has already used enough data usage which has reached a threshold in a month, the PCRF can increase or decrease bandwidth for him/her. For service-level policy control, PCRF can provide different bandwidths to different services for a single user. For example, PCRF can allocate 1Mbps to HTTP browsing, 512kbps to FTP, 215Kbps to P2P for a user. The combination of user-level and service-level policy control is also supported by PCRF. In short, the PCRF can support very powerful and flexible policy plans to completely meet operators' needs. QoS Control Function -------------------- QoS is Quality of Service. For now, QoS is like bandwidth. Different QoS means different bandwidth. PCRF sends the QoS information within PCC Rules for a specific user to PCEF, PCEF activates the PCC Rules and performs corresponding policy enforcement for the user. In order to control the user's bandwidth, PCEF will use **DPI** to execute service awareness for inspecting the user's data packet flow that belongs to what kind of service. If this data packet matches the service data flow filter that is defined in a specific PCC Rule, PCEF will apply the bandwidth control that is defined in this PCC Rule. Access Control Function ----------------------- ### Gating Control Gating Control is like a gate that can be opened for somebody and closed for others. With this function, some user can only use some particular services or protocols. For this user, if he/she uses any other service or protocol, corresponding data packets will be blocked or discarded. ### URL Co**n**trol Permit or not permit the data flow according to specific source/target IP address/port and protocol. This rule is for all users as default rule, and cannot be subscribe by single user. For example, the websites in the black list cannot be accessed by all users. Alerting and Redirection ------------------------ The PCRF has inner component called UIP that connects to SMSC, so PCRF support alerting function to inform user that some event is happening. For example, when a user reaches the predefined package volume's 80%, PCRF can alert the user by SMS. The redirection function is that PCRF can redirect a user to some pre-configured web page when the user is using data service and some condition happens. For example, when user is rejected by admission control, in this case, the user may be redirected to a pre-configured URL based on user profile. Also, when reaching the usage cap of the Package, PCRF can redirect the user to the 'Re-Subscribe page' based on user profile. Sy/Sp Call Flow --------------- Sy interface contains three pairs of message: SLR/SLA, SNR/SNA and STR/ STA. Message Type Message Name -------------- -------------------------------------- SLA Spending Limit Answer SLR Spending Limit Request SNA Spending-Status Notification Answer SNR Spending-Status Notification Request STA Session Termination Answer STR Session Termination Request The Online Charging System (OCS), for the purpose of policy decisions based on the subscriber\'s spending, maintains the policy counter statuses applicable for a subscriber such as accumulation and balance information. If PCRF requires policy control, will send request to OCS (SLR/SLA), i.e. when the request is sent for the first time for the Subscriber, the PCRF shall set the SL-Request-Type AVP to the value INITIAL\_REQUEST (0). For subsequent requests for the same Subscriber, the PCRF shall set the SL-Request-Type AVP to INTERMEDIATE\_REQUEST (1). For each policy counter that the PCRF requires the current status and notifications of future status changes, the PCRF shall indicate the concerned policy counter identifiers in the request. Alternatively, the policy counter identifiers may be omitted if the PCRF requires the current status and notifications of future status changes of all available policy counters. OCS shall report the policy counter status values for the subscriber when requested to the PCRF When a policy counter status changes, report the change to the PCRF (SNR/SNA). When PCRF session is finished, PCRF will report the status to OCS to clear the Sy session (STR/STA).