Archive | PCRF RSS feed for this section

PCRF experience: from functional testing to performance monsters or how did we climb the testing hill

4 Nov

Our team is developing PCRF (Policy and Charging Rules Function) product that is a significant component in operator network. We have a successful installation in Yota production network and so two important characteristics that we thoroughly care about from version to version are performance and stability under high load. To reach this goal we passed a long and interesting way from unit testing to functional regression testing and various performance testing in the end. And so here we would like to tell you some of our PCRF testing “secrets”. Below we will tell you about three main steps in PCRF testing (excluding unit testing that is zero and obvious one) that we follow during each version’s stabilisation.

1. Regression testing
We hold on to the Continuous Integration methodology and have Jenkins installed with all builds done there and unit tests and regressions tasks started from it after each build automatically. At present we have:

Component Smoke tests Regression tests
PCRF 270 972
DDF 149 600

Smoke tests are the selection from Regression part. This small set is intended for initial evaluation of the new version and thus includes the main functionality tests with the exception of the negative tests and all non-default and non-trivial configurations. One can also mention that we have independent set for PCRF and DDF (that is Data Distribution Function node – a centralized storage used by all other local PCRFs). The reports in Jenkins are presented in the following way (click to look closer):

Our QA department prepares functional tests using Robot Framework and their own library written on Python as a back-end. To make the testers life easier when working with the Diameter (that is a binary protocol) in Python we have implemented C shared library that supports all Diameter applications known to PCRF and is built together with it so any change in Diameter protocol library is delivered to QA team immediately. It is called and it makes the translation from XML format to Diameter binary message and back. So test can work with the Python object that can be converted to Diameter binary data and back through the XML step.
Regression tests recreate full PCRF environment emulating PCEF (Policy and Charging Enforcement Function) equipment, various DPIs (Deep Packet Inspection), AF (Application Function), provisioning from BSS (Business Support System) and O&M console operations. Example of one of our test cases together with the Robot Framework test implementation can be found here.

QA team also calculates test coverage. That is 64% for now. But this includes many Diameter messages that are present in library but not used in PCRF application and also some debugging utilities that are compiled together with PCRF and all of this is not covered with tests for now. The unit-test coverage is much better and is shown on the picture:

Rem: On Free PCRF image meanwhile one can start Seagull functional tests by the following commands set:
cd /opt/pcrf_test/simple

2. Seagull performance tests
To measure the performance on first-row scenarios we started from the Seagull instrument, that is a free, GPL multi-protocol traffic generator test tool, very popular for many cases, including Diameter testing (compatible with the RFC 3588) . And the significant benefit is that Seagull is optimized for the performance scenarios. And if some new Diameter application is needed this becomes a matter of editing an XML file.
Seagull scenarios that we’ve passed through are the following:
– one PCEF GxCCR-I/GxCCA-I -> (GxRAR/GxRAA) * n times -> GxCCR-T/GxCCA-T
– one PCEF GxCCR-I/GxCCA-I -> GxCCR-U/GxCCA-U  with usage monitoring enabled-> GxCCR-T/GxCCA-T

Interesting report done with the help of Seagull instrument for the previous 3.5.2 PCRF version can be found here.

Next let us show some numbers from 3.6.0 version that was released recently:
– 1 000 000 subscribers (IMSIs)
– 50 unique services in PCRF dictionary
– 50 unique policies in PCRF dictionary
– 2 services for each subscriber
– 2 attributes for each service
– servers used: HP ProLiant DL360 G5: Intel Xeon E5420 2500 MHz x 2, 8 Gb RAM
– Lua script runs for policy selection for each subscriber and analyzes subscriber profile, subscriber services, service attributes
– performance run – 11000 TPS
– errors happening during performance testing – 0, no errors.

3. Self-implemented bench tool
Seagull is perfect for simple scenarios (especially when only one outer node is communicating with PCRF), but several more complicated cases also exist and need to be measured in respect of performance. They are:
– PCEF and DPI both establish sessions to PCRF for one subscriber.
– PCEF, DPI and AF (Application Function) establish sessions to PCRF for one subscriber.
– Usage monitoring performance cases with PCEF and DPI sessions established.
– Session validation scenario based on GxRAR sent from PCRF to PCEF and DPI sessions established.
– Session re-validation scenario based on GxCCR-U with revalidation event trigger sent from PCEF and DPI to PCRF.
In all above the order of the messages is not strictly determined. And despite going through the different connections messages are strictly relative to each other in terms of order and data.
When failed to make all of these complicated scenarios with branching logic and mutable messages order on Seagull we’ve decided to implement our own benching solution. This was quite easy since we’ve implemented a Diameter library, transport library and all statistics stuff as an independent components that have high re-use factor. Scenarios were implemented in C/C++ and are based on finite automaton with some non-deterministic parts included to handle mutable message order.
All tests below were done on the following configuration:
– 1 000 000 subscribers (IMSIs)
– 100 unique services in PCRF dictionary, 50 for one PCEF dialect and 50 for other one
– 100 unique policies in PCRF dictionary, 50 for one PCEF dialect and 50 for other one
– 2 services for each subscriber at a time
– 2 attributes for each service
– 250 000 subscribers have 1-3 usage accumulators assigned
– servers used: usual hosts with 4 Intel core processor i7 2.93GHz, 8 Gb RAM
– Lua script runs for policy selection for each subscriber and analyzes PCEF dialect, subscriber profile, subscriber services, service attributes, subscriber accumulator
Scenarios and results summary:

Scenario name Scenario description TPS (messages handled per sec) Simultaneous sessions count Max CPU % on between all PCRF processes
double_procera PCEF and DPI (Procera) both establish sessions to PCRF for one subscriber, usage monitoring is switched on. 9000 500 000 80-85%
double_procera with revalidation The same as double_procera scenario but with revalidation GxCCR messages included. 8500 500 000 80%
rx_simple PCEF, DPI and AF (Application Function) establish sessions to PCRF for one subscriber. 11000 500 000 90-95%

It should be mentioned here that there are no errors of any kind during these scenarios running. And any of these load-scenario can operate for the unlimited amount of time on PCRF cluster without any degradation.


PCRF experience: dynamic script-based policy decision maker or what do we need LUA for

11 Oct

Our team in Yota is involved in development of PCRF, useful and important component of the operator network. Policy and Charging Rules Function (PCRF) is an advanced policy management solution enabling the operator to dynamically control network elements and apply real-time policies based on services, subscriber info and usage context. One of it’s key features we are really proud of is a flexible script-based policy decision maker. And here we would like to share our experience about this magical component.

Let’s take our thoughts away from PCRF, operators and clients for a while. Think about a high-performance and high-reliable system with some storage inside with a functionality like:

  • store & backup the information
  • reply HTTP requests as soon as possible
  • configure replies in a very flexible way so that it can be changed on fly

From our past experience and research and from the common practices the simple architecture that serves well for such kind of tasks is: storage (db commonly or some other standalone storage implementation) + nginx + script to configure the replies. And all that is left is just to select the proper scripting language. Because we have a C/C++ application the first we talked about was Lua. If to think more accurately you can find out that it’s really a very convenient solution. What does Lua language mean for most of the developers?

  • it’s simple and light-weighted – so easy to build into your application
  • it’s a skeleton – build as many your own Lua or C functions as you wish, use them in a script
  • it’s easy (both – scripts readability and expandability) for those who are not programmers from top to bottom, for example the maintenance team that you want to allow to tune up the logic on a production system in real-time
  • it’s really quick for high-performance application

And now let us come back to PCRF and show how we used it and what we’ve reached. PCRF stores all the subscriber’s information in the Subscription Profile Repository (SPR) stored in Data Base.  Also it aggregates all the user session’s information and also stores it in DB. There are lots of systems that would like to use this information and to make some decisions based on it.

1. The first and the major use case for PCRF is of course PCEF for which we should make a real-time policy selection for user based on services, subscriber info, usage context, location, operator special conditions and etc. So there should be a way to configure PCRF diameter handlers logic.

2. Other systems also may use the information stored in PCRF SPR – end-user network devices clients, operator notification services, contact centers, web services, mobile applications and so on. For example, a very popular use case is to provide a policy for turbo button service which will show if this turbo button is available for the user at the moment. This solution should be made very quickly and depends on user profile, location, network resources availability and many other parameters that can be found in PCRF data storage.

All this client-systems may use there own heuristics and logic that filter the stored information and give the specific output. There is no way of course for hard-coding or standardization for this output. It should be changed easily on fly from inside logic to output format for each application separately and independently.

That’s why the described scheme was used. We have nginx server and a Lua-based scripting functionality. And we provide the outer system with the library of Lua functions (more than one hundred) that has access to all data stored in PCRF so that outer system can just load a Lua-script into the PCRF and run it.

If talking about the performance let us just show the numbers that will speak for themselves.

1. First case is used primary for PCEF purposes as we talked before. The diameter messages handlers in PCRF just call the loaded Lua script by name. The script itself can be managed by the maintenance team easily and loaded on fly to the PCRF server. The performance was measured for the script that accesses the Data Base and makes the policy decision based on this info. And so here we have 50 000 calls/sec.

The interesting key point here is that of course maintenance team wants to test the scripts they made. So we’ve created a validation tool with the db-read-only mode that can calculate all the data and provide the resulted policy. Also there is a possibility in our PCRF to load a new Lua script for the limited users percent (for example 10%) and check how it solves the task on this amount of subscribers while others will be served by the previously loaded and tested script. If it goes ok just call commit and use the new script for full 100%.

2. For all other systems we called it Generic Request API (GRAPI) method. The idea is so simple – just load your own Lua script with main function and call HTTP request (smth. like and you’ll get the reply from PCRF. This is our way for the turbo button implementation and many other similar systems.

Apache benchmark started for 100000 requests with concurrency 100 and HTTP keep alive feature gave us more than 30 000 requests/sec on quite a complicated script with multiple Data Base searches inside, detailed logging and logic branching.


Policy Control Use Case – Resource Allocation

2 Jul

The Policy Control and Charging (PCC) Rules Function (PCRF) is a centralized policy decision point that deploys business policy rules to allocate network resources and manages flow-based charges for subscribers and services.  Gx is the policy interface between the PCRF and the Policy and Charging Enforcement Function (PCEF), providing control over policy and flow-based charges for subscribers.

The Gx interface includes support for:

  • Service provisioning, activation, and deactivation;
  • Threshold triggers for service statistics processing;
  • Accounting;
  • Subscriber session  maintenance (activation, updating and termination);
  • Event notifications.

One important part of provisioning PCC rules is ascertaining that the requested resources associated with a PCC rule are successfully allocated.  The PCRF can request this verification from the PCEF with a CCA or RAR message that includes the Event-Trigger AVP with the value SUCCESSFUL_RESOURCE_ALLOCATION. The PCRF installs the rules that require resource allocation confirmation by including the Resource-Allocation-Notification AVP with the value ENABLE_NOTIFICATION within the corresponding Charging-Rule-Install AVP.

Developing Solutions’ dsTest supports this behavior of Policy Control by allowing a service to be configured with the ‘Resource_Allocation_Notification’ element.  See the dsTest schemafor more information.

Reference: TS 29.212

Refer to the message flow below:

Message Exchange 1 (CCR-I/CCA-I): Initial Request and Answer

Initial Request and Answer

The PCEF establishes a Gx Session with the PCRF with a Credit-Control-Request Initialization (CCR-I) message.  The PCRF responds to the PCEF with a Credit-Control-Answer (CCA-I) in which the PCRF requests that the PCEF confirm that the resources associated with a PCC rule are successfully allocated.  This request by the PCRF is accomplished by the inclusion of an Event-Trigger AVP with the value of SUCCESSFUL_RESOURCE_ALLOCATION.


Message Exchange 2(AAR/AAA): Rx session established.

Gx Re-Authorization

The Call Session Control Function (CSCF) establishes a Rx Session with the PCRF with a Authorize/Authenticate-Request (AAR) message.  The PCRF responds to the CSCF with an AA-Answer (AAA).

Message Exchange 3 (RAR/RAA): Gx Re-Authorization

The establishment of a Rx session triggers a Gx Re-Authorization Request from the PCRF to the PCEF.

Using the Charging-Rule-Install AVP, the PCRF reauthorizes the installed PCC rules at the PCEF.  The PCRF indicates which rules require notification by including the Resource-Allocation-Notification AVP with a value of ENABLE_NOTIFICATION.

Message Exchange 4 (CCR-U/CCA-U): Gx Update

Gx Update

The RAR/RAA exchange triggers a Gx CCR Update (CCR-U) from the PCEF to the PCRF, based upon the initial CCR-I/CCA-I exchange with the Event-Trigger AVP with the value of SUCCESSFUL_RESOURCE_ALLOCATION from the PCRF (Message Exchange 1).  The PCEF includes the Charging-Rule-Report AVP in the CCR-U which contains the Charging-Rule-Name AVP for each of the rules installed.

Message Exchange 5/6/7 (STR/STA)/(RAR/RAA)/(CCR-T/CCA-T): Sessions are Terminated

The Rx session is terminated, resulting in a Gx reauthorization request/answer, and then the Gx session is terminated.


 About dsTest

dsTest originates, receives, and processes signaling traffic into and from the core network.  Multiple emulated nodes can be coordinated to simulate the UE traffic for complex signaling interactions such as VoLTE.  Unlike some test tools, dsTest provides stateful, standards-based applications that react appropriately to both expected and unexpected events without the need for scripting, simplifying the process of performance testing the signaling core.  dsTest provides multiple advanced testing features, such as SmartEventsDiameter Dictionary validation, and SmartAVP™ customized messages

dsTest surpasses all other tools with its capacity, its performance, and the ease with which you can customize the scenarios and messages to achieve your testing goals.


HP Launches Intelligent Wi-Fi Solution – Integrates Offload, Analytics and Policy Management

27 Jun

HP announced a “.. new solution designed to help mobile network operators (MNOs) improve overall service quality and customer experience by leveraging WiFi technologies .. HP is providing a wide set of modules that can be used independently or together to enable WiFi services such as WiFi Offload .. HP’s Intelligent WiFi solutions are available worldwide with pricing based on solution size and architecture”.  

HP Intelligent WiFi Offload solutions rely on many HP sub-domains and define a wide framework
divided into five layers:

  • Access point control provides a complete range of networking products for offloading, including a large portfolio of hotspots scaling
  • Gateway and switching link WiFi traffic with the data network, tunneling data to ensure security, and providing protection against attacks and identity theft
  • Authentication and routing methods identify the user who wants to connect on WiFi and includes HSS core network elements and the deep packet inspection (DPI) function to collect user information for further business analysis
  • Data logical layer stores subscriber data and applies analytics and business intelligence [here]
  • Policies and rules dictate hotspot network selection, policy control rule function (PCRF – here), real time charging (RTC) rules, and where business analytics reside.


LTE QoS Concepts & Architecture

22 Jan

LTE QoS Concept


  1. What is LTE QoS?
  2. QoS Tags
  3. Bearer
  4. QoS Management
  5. PCRF

ExploreGate – Free Video Tutorials


Cellular Wi-Fi Integration—A comprehensive analysis—Part II

4 Aug

In Part I we looked at the origins of Wi-Fi and efforts to integrate cellular mobile technology.

Beginnings: GSM Association’s WLAN Interworking Task Force

Taking note of the standardization of Wi-Fi by IEEE and the increasing uptake of Wi-Fi technology by the market, mobile operators and vendors in GSMA undertook the step of studying the potential integration of Wi-Fi as an alternate radio access method to the core network and services of mobile operators. A task force was created, called the “WLAN Interworking Task Force” which studied the topic between 2002 and 2004. The group investigated various use cases and defined six different levels of interworking between the Wi-Fi and cellular networks.

The simplest interworking scenario was what may be termed as “loose interworking” and consisted of common authentication, access control and billing. Such a combined network would allow a cellular operator to offer Wi-Fi access services to their subscribers, authenticate them using standard cellular methods (i.e. based on SIM cards in the cell phones), verify the service level subscriptions and bill them as needed. The main technical contribution here was the recommendation to use the EAP-SIM protocol over the Wi-Fi networks to authenticate cellular subscribers with SIM-based Wi-Fi enabled handsets.

Progressively tighter levels of interworking were defined in terms of increasingly seamless and integrated access to cellular networks and services. For example, in the loose interworking scenario, the subscriber can access the cellular operator’s core network and service network, but some services may not be accessible over the Wi-Fi radio. This limitation is removed in the second level of interworking. The second level of interworking allows “Service Continuity”, meaning that all the services that a subscriber has subscribed to must be accessible by the subscriber via the Wi-Fi network. This would include voice-mail, texting, mobile TV, and any other services offered by the cellular operator.

A limitation of the second level of interworking is that while all services may be accessed via the Wi-Fi network, an ongoing session that a user has established over the cellular radio may not, due to user mobility, seamlessly handover to a Wi-Fi network. In other words, the ongoing cellular radio session would be torn down and a new Wi-Fi session would have to be established. This would seriously impact the quality of the user experience. This limitation is removed in the third level of tighter interworking, which calls for so-called “session continuity”. This would make the experience of a user moving between Wi-Fi Networks and Cellular Networks as seamless as if he or she were still connected to the cellular network.

Shown below is a figure from GSMA PRD (Permanent Reference Document) SE.27, illustrating various integration scenarios, as understood at the time.


GSMA’s WLAN Task Force completed the study in a comprehensive manner and identified the need for standardization within 3GPP. This resulted in the development of a number of standards, based essentially on the loose integration of Wi-Fi networks with the 3GPP core network and can be viewed as an evolution of integration scenario #3 in the above figure. The detailed integration solutions depend upon whether the core network is a UMTS Core network or Enhanced Packet Core (EPC) network. The former set of standards is referred to as IWLAN (Integrated/Interworked WLAN) standards and the latter as EPC standards.

Integrated Wireless LAN (IWLAN) Standards

The IWLAN standardization work commenced with an initial feasibility study, which included some of the findings of the GSMA’s WLAN Task Force. It resulted in a 3GPP Technical Report, TR 23.234, latest version of which is v10.0.0, produced in 2011. The report essentially identifies a number of interworking scenarios, numbered 1 through 6 as follows:

Scenario 1 – Common Billing and Customer Care

Scenario 2 – 3GPP system based Access Control and Charging

Scenario 3: Access to 3GPP system PS based services

Scenario 4: Service Continuity

Scenario 5: Seamless services

Scenario 6: Access to 3GPP CS Services

The last scenario has not been pursued in standardization, but the others led to a number of 3GPP specifications, listed below:

TS 23.234: Scenarios 1 and 2: Common Billing, Access Control and Charging and Access to PS Services.

TS 23.327: Scenarios 4 and 5: Service Continuity and Seamless Services – Single Radio Case and Mobility

TS 23.261: Scenarios 4 and 5: Service Continuity and Seamless Services – Dual Radio Case and Flow Mobility

TS 23.234 provides a solution for Interworking Scenarios 1 and 2. The figure below is a simplified version of a figure from 23.234, wherein the 3GPP AAA server performs the necessary user authentication and authorization for both WLAN access and 3GPP services. Two different types of IP-Access Services are provided to the user, namely “3GPP IP access” and “Direct IP access”. The former refers to access to 3GPP packet data services, such as MMS, mobile video, etc. as well as internet services, whereas the latter refers to direct access to internet or intranets.


One of the main goals of the IWLAN solutions was to achieve authentication without manual user intervention, such as entering a username-password, as is common is many Wi-Fi networks. This is made possible by developing authentication protocols based on the use of SIM cards, which are already provisioned in the 3GPP handsets. In addition to providing authentication in a manner transparent to the user, SIM based authentication methods are also familiar to 3GPP operators and provide the same level of security as 3GPP devices.

Since the SIM based authentication is now done via WLAN networks, which are essentially IP Networks, the basic 3GPP authentication protocols are modified and are known as EAP-SIM, EAP-AKA and EAP-AKA’ protocols, which were standardized by the IETF. IP Networks also use certificate-based authentication methods, which are also standardized as EAP-TLS and EAP-TTLS protocols for WLAN based authentication. 

Regarding IP access services, the 3GPP-IP-access is provided by two functional entities called WAG and PDG. As the name indicates, the PDG is a gateway to a specific Packet Data Network, such as the Internet or an operator service network. Clearly, the 3GPP network may support multiple PDNs and hence multiple PDGs, for different types of services. The WAG implements a typical gateway function on the user side, by connecting the user to one of the possibly several PDGs. It also acts as a firewall and implements operator policies, which are downloaded from the 3GPP AAA servers.

Finally, WAG performs charging related functions, as set by the operator, and communicates with the 3GPP charging systems, of which there are two types, namely offline (for post-paid customers) and online (for pre-paid customers and for checking spending limits). 

While the solutions presented in TS 23.234 allow WLAN UEs to access 3GPP core networks and services, the radio connection cannot be dynamically switched between Wi-Fi and 3GPP access networks. These solutions are standardized in TS 23.327, which describes mobility between Interworking WLAN Networks and 3GPP networks.


The mobility function is essentially based on an IP-level mobility management protocol called DSMIPv6, which is standardized by IETF. This protocol is implemented in an entity called HA (Home Agent) in the core network of the home 3GPP network and in a peer entity called DSMIPv6 client in the UE. The UE has a single IP address (for the purposes of mobility management), which is called Home Address (HoA) and a Care-of-Address (CoA) which changes as the UE attachment is changed between IWLAN and 3GPP radio interfaces. Changes in CoA address are synchronized between the UE and the HA by exchanging the so-called “Binding Updates” messages. These are sent over the logical interface H1 shown in the above figure. It is supported over the chain of physical interfaces Uu/Um, Iu_ps/Gb, Gn and H3 when connected over the 3GPP access network and over Ww, Wn, Wp and H3 when connected over the WLAN Access Network.


DSMIPv6 mobility protocols allow handover from 3GPP access to WLAN access or vice versa. However, in the current version of the standards, only the UE can initiate such a handover procedure. This is based partly on the rationale that the UE has a better knowledge of the WLAN radio networks. However, there are some initiatives in the 3GPP standards organization currently that are seeking to standardize network-initiated handovers as well, since the network has a more comprehensive knowledge of the network congestion state. Although the HA function is shown as a separate function in the above figure, it is often collocated with the GGSN.

Enhanced Packet Core (EPC) Standards

The above solutions have two basic limitations. The first limitation is that the HA is not connected to policy and QoS management entities in the core network, such as PCRF. This prevents advanced policy and QoS based management of the IWLAN-3GPP mobility. These limitations are removed in the case of integration of WLAN into EPC core networks, which is described in the next section.

The second limitation is that the above solutions restrict the UE to have only a single radio connection at any given time, namely either to the WLAN or 3GPP radio interface. Modern smart phones allow simultaneous connectivity to both radio interfaces, which raises the possibility of managing 3GPP and WLAN interworking at an individual IP-Flow level. That is, it should be possible to support certain IP-Flows on the 3GPP radio interface and certain others on the WLAN radio interface, based on criteria such as QoS requirements, user subscription, type of user equipment, etc. Furthermore, it could also enable dynamic switching of individual IP-Flows from one radio interface to another.  The figures below illustrate the situation.


The EPC standards for 3GPP and Non-3GPP interworking introduce a new class of non-3GPP access networks, namely Trusted Non-3GPP Networks, with the word “trust” referring to trust by the operator (and not necessarily by the user). Accordingly, Trusted Wi-Fi Networks imply that the Trusted Wi-Fi access points are deployed and managed by the Operator, so that UE can connect to the Wi-Fi Network directly using the radio interface without requiring any additional security measures.

In contrast, un-trusted Wi-Fi Networks do not have any trust relationship to the operators, so that the operators require that the UE establish a secure tunnel (i.e. IPSec tunnel) to a trusted node in the operator core network. Typically, such a node is a PDG in UMTS core networks (as in IWLAN architectures) and ePDG in EPC core networks.  Shown below are two simplified architectures of an EPC core network with 3GPP as well as Trusted and Un-Trusted non-3GPP Access. Other architectures are also possible and are documented comprehensively in TS 23.401 and TS 23.402.


 Note that here the PGW includes a HA functionality and that PCRF is connected to various gateway functions, each of which has a PCRF or its functional equivalent to enforce the operator policies.

Shown also is the ANDSF functionality, which is a critical one for Cellular-Wi-Fi interworking from an operator policy point of view. Currently, most smartphones choose and camp on to Wi-Fi networks based on explicit user preferences or preconfigured preferences, already stored in the UE. It was clear that if operators were to offer Wi-Fi access as an integral part of the access offerings, they needed to be able to install operator policies on the UE and also be able to change them dynamically, as the conditions may change. To achieve this, the framework of ANDSF was standardized. It essentially consists of an ANDSF server in the operator network, which stores the operator policies regarding discovery and selection of Wi-Fi access. For example, it contains discovery information of Wi-Fi hotspots based on the location of a UE. Regarding selection of Wi-Fi Hotspots, the policies may specify that certain Wi-Fi hotspots are preferred at certain locations and/or certain times of day, or for certain types of applications, such as mobile video etc. These operator policies can be transferred to the UE via the S14 interface using communication procedures based on device management procedures, originally developed by the OMA organization.

Interworking between 3GPP and non-3GPP networks essentially consists of mobility of IP-Flows between the 3GPP and non-3GPP networks. A number of cases of such mobility can be distinguished depending on the following aspects: (1) mobility is on a per IP-Flow basis or per all IP-Flows associated with a PDN connection; (2) mobility is Seamless or Non-Seamless, with Seamlessness defined as preservation of the IP-address of the UE during the mobility process. Different combinations of these two fundamental aspects result in a number of scenarios, such as Wi-Fi offload, referring to mobility of IP-Flow(s) from 3GPP to Wi-Fi networks, and handovers, referring to mobility of all IP-Flows associated with a PDN connection etc.

The 3GPP standard TS 23.401 describes Seamless and Non-Seamless Handover solutions between 3GPP and Non-3GPP access networks, wherein GTP is used as the protocol for the Handover over the interfaces S2a, S2b and S5. Similarly, TS 23.402 documents similar solutions for the cases where PMIP and DSMIP are used for mobility.

Finally, TS 23.261 describes the solutions for Seamless IP-Flow Mobility using DSMIP protocols. As mentioned below, this allows for selective assignment of different IP-Flows to different access networks and includes Seamless Wi-Fi Offload as a special case.

In all cases listed above, the mobility is triggered by the UE and not by the network. Efforts are also being made to standardize network-triggered mobility procedures, since the network is often more knowledgeable about the overall network usage and congestion state than the UE.

This concludes a review of past efforts towards cellular/Wi-Fi integration. However, with the advent of new device types and applications, the desire for increased integration is more salient now than ever before. In Part III of this series, we’ll be looking at current and future efforts, and how they are setting the stage for the heterogeneous networks of the future.

Source: – Prabhakar Chitrapu, Alex Reznik, Juan Carlos Zuniga- 07.23.2012 July 23, 2012

%d bloggers like this: