Wednesday, 4 May 2011

New Security Algorithms in Release-11


I did mention in my earlier blog post about the new algorithm for 3GPP LTE-A Security. The good news is that this would be out hopefully in time for the Release-11.

The following from 3GPP Docs:


The current 3GPP specifications for LTE/SAE security support a flexible algorithm negotiation mechanism. There could be sixteen algorithms at most to support LTE/SAE confidentiality and integrity protection. In current phase, 3GPP defines that there are two algorithms used in EPS security, i.e. SNOW 3G and AES. The remaining values have been reserved for future use. So it is technically feasible for supporting new algorithm for LTE/SAE ciphering and integrity protection.

Different nations will have different policies for algorithm usage of communication system. The current defined EPS algorithm may not be used in some nations according to strict policies which depend on nation’s security laws. Meanwhile, operators shall implement their networks depending on national communication policies. To introduce a new algorithm for EPS security will give operators more alternatives to decide in order to obey national requirements.


Picture: Zu Chongzi
Picture Source: Wikipedia


Some work has been done to adapt LTE security to national requirements about cryptography of LTE/SAE system, i.e. designing a new algorithm of EPS security, which is named ZUC (i.e. Zu Chongzhi, a famous Chinese scientist name in history). Certainly the new algorithm should be fundamentally different from SNOW 3G and AES, so that an attack on one algorithm is very unlikely to translate into an attack on the other.

The objective of this work item is to standardise a new algorithm in EPS. This will include the following tasks:
To develop new algorithms for confidentiality and integrity protection for E-UTRAN
To enable operators to quickly start to support the new algorithm
Not to introduce any obstacle for R8 roaming UE

The following issues should at least be handled in the WI:
Agree requirement specification with ETSI SAGE for development of new algorithms
Delivery of algorithm specification, test data and design and evaluation reports

The algorithm is provided for 3GPP usage on royalty-free basis.

The algorithm shall undergo a sequential three-stage evaluation process involving first ETSI SAGE, then selected teams of cryptanalysts from academia and finally the general public.


The documents related to the EEA3 and EIA3 algorithm could be downloaded from here.

If you are new to LTE Security, the following can be used as starting point: http://www.3g4g.co.uk/Lte/LTE_Security_WP_0907_Agilent.pdf

Friday, 29 April 2011

Service Layer Optimization element to Improve Utilisation of Network Capacity


The following is an extract from 4G Americas whitepaper, "Optimizing the Mobile Application Ecosystem":


Applications have diverse requirements on the mobile network in terms of throughput, relative use of uplink vs. downlink, latency and variability of usage over time. While the underlying IP based Layer 3 infrastructure attempts to meet the needs of all the applications, significant network capacity is lost to inefficient use of the available resources. This inefficiency stems primarily from the non-deterministic nature of the aggregate requirements on the network from the numerous applications and their traffic flows live at any time.

This reduction in network utilization can be mitigated by incorporating application awareness into network traffic management through use of Application or Service Layer optimization technologies. A Service Layer optimization solution would incorporate awareness of:

1) device capabilities such as screen size and resolution;
2) user characteristics such as billing rates and user location;
3) network capabilities such as historic and instantaneous performance and;
4) application characteristics such as the use of specific video codecs and protocols by an application such as Video on Demand (VOD) to ensure better management of network resources.

Examples of Service Layer optimization technologies include:
* Real-time transcoding of video traffic to avoid downlink network congestion and ensure better Quality of Experience (QoE) through avoidance of buffering
* Shaping of self-adapting traffic such as Adaptive Streaming traffic through packet delay to avoid downlink network congestion
* Shaping of error-compensating flows such as video conferencing through use of packet drops to avoid uplink network congestion
* Shaping of large flows such as file uploads on the uplink through packet delays to conserve responsiveness of interactive applications such as web browsing
* Explicit caching of frequently accessed content such as video files on in-network CDNs to minimize traffic to backbone
* Implicit caching of frequently accessed content such as images in web content on in-network caches to improve web page retrieval speeds

Service Layer optimization technologies may be incorporated in the data path in many locations:
1) the origin server;
2) the UE device;
3) as a cloud-hosted offering through which devices and/or applications and/or networks route traffic or;
4) as a network element embedded in a service provider’s network.

Further, in a service provider’s network the optimization function may be deployed in either the core network and/or edge aggregation locations. When Service Layer optimization entities in the network are deployed at both core and edge locations, they may operate in conjunction with each other to form a hierarchy with adequate level of processing to match the traffic volume and topology. Such a hierarchy of network entities is especially effective in the case of caching.

The 3GPP standard network architecture defines a number of elements such as QoS levels that are understood and implemented in the network infrastructure. However, much of this network capability is not known or packaged for use in the Service Layer by application developers. One approach to resolving this discrepancy may be to publish standard Service Layer APIs that enable application developers to request network resources with specific capabilities and also to get real-time feedback on the capabilities of network resources that are in use by the applications. Such APIs may be exposed by the network to the cloud or may be exposed to application clients resident on mobile devices through device application platforms and SDKs. The network APIs being defined by the Wholesale Application Community are an example of the recognition of the need for such Service Layer visibility into network capabilities. Future versions of the WAC standards will likely incorporate and expose network Quality of Service (QoS) capabilities.



Pic Source: Aria Networks


Why does Optimization matter? A good answer to this question is provided in Telecoms.com article as follows:

For many people, says Constantine Polychronopoulos, founder and chief technology officer of mobile internet infrastructure specialist Bytemobile, the definition of optimisation as it relates to mobile networks is too narrow; restricted to compressing data or to the tweaking of the radio access network in a bid to improve throughput. While these are key elements of optimisation, he says, the term ought to be interpreted far more broadly. “The best way for us to think of optimisation,” he says, “is as a set of synergistic technologies that come together to address everything that has to do with improving network and spectrum utilisation and user experience. If you stretch the argument, it includes pretty much every thing that matters. This holistic, end-to-end approach to optimisation is the hallmark of Bytemobile’s solutions. Point products tend to be costly and difficult or impossible to evolve and maintain.”

And optimisation matters, he says, because the boom in mobile data traffic experienced in some of the world’s most advanced mobile markets represents a serious threat to carrier performance and customer satisfaction. US operator and pioneer iPhone partner AT&T is a case in point, Polychronopoulos says.

“If you look at what’s been said by Ralph de la Vega (president and CEO of AT&T Mobility) and John Donovan (the firm’s CTO), they have seen a 5,000- per cent increase in data traffic over the past two years. The data points from other operators are similar,” he continues. “They see an exponential growth of data traffic with the introduction of smartphones, in particular the iPhone.”

Operators may have received what they’d been wishing for but the scale of the uptake has taken them by surprise, Polychronopoulos says. The type of usage consumers are exhibiting can be problematic as well. Bytemobile is seeing a great deal of video-based usage, which can often be a greater drain on network resource than web browsing. Given the increasing popularity of embedding video content within web pages, the problem is becoming exacerbated.

Dr. Polychronopoulos is keen to point out that there are optimisation opportunities across different layers of the OSI stack—Bytemobile offers solutions that will have an impact on layers three (the IP layer) through seven (the application layer). But he stresses that some of the most effective returns from optimisation technologies come from addressing the application layer, where the bulk of the data is to be found.

“An IP packet can be up to 1,500 bytes long,” he says. “So at layer three, while you can balance packet by packet, there is only so much you can do to optimise 1,500 bytes. At the top layer, the application can be multiple megabytes or gigabytes if you’re watching video. And when you’re dealing with those file sizes in the application layer, there is a whole lot more you can do to reduce the amount of data or apply innovative delivery algorithms to make the content more efficient,” he says.

By optimising content such as video, Polychronopoulos says, significant gains can be made in spectral and backhaul network utilisation. A range of options are open to operators, he says, with some techniques focused on optimising the transport protocol, and others designed to reduce the size of the content.

“With video, we can resize the frame, we can reduce the number of frames, we can reduce the resolution of the frame or apply a combination of the above in a way that does not affect the video quality but greatly improves network efficiencies,” he says. “So if you go to a site like YouTube and browse a video, you might download something like 100MB of data. But if you were to go through a platform like ours, you may download only 50MB when the network is congested and still experience not only the same video quality, but also fluid video playback without constant re-buffering stalls.”

It is possible, he explains, to run these solutions in a dynamic way such that data reduction engages only when the network is congested. If a user seeks to access high-volume data like video during the network’s quiet time, the reduction technologies are not applied. But when things are busier, they kick in automatically and gradually. This could have an application in tiered pricing strategies. Operators are looking at such options in a bid to better balance the cost of provisioning mobile data services with the limited revenue stream that they currently generate because of the flat rate tariffs that were used to stimulate the market in the first place. Being able to dynamically alter data reduction and therefore speed of delivery depending on network load could be a useful tool to operators looking to charge premium prices for higher quality of service, Polychronopoulos says.

If it is possible to reduce video traf- fic in such a way that data loads are halved but the end user experience does not suffer proportionally, the question arises as to why operators would not simply reduce everything, whether the network was busy or not. Polychronopoulos argues that in quiet times there are no savings to be made by reducing the size of content being transported.

“The operator has already provisioned the network one way or another,” he says, “so there is a certain amount of bandwidth and a certain amount of backhaul capacity. When the network is not congested, the transport cost is already sunk. When it becomes congested, though, you get dropped calls and buffering and stalled videos and the user experience suffers. That’s where optimisation shines. Alternatively, media optimisation can be factored in during toplevel network provisioning when the savings in CAPEX can be extremely compelling.”

While LTE is held up by some within the industry as the panacea to growing demand for more mobile broadband service, Polychronopoulos is unconvinced. If anything, he says, the arrival of the fourth generation will serve only to exacerbate the situation.

“LTE is going to make this problem far more pronounced, for a number of reasons,” he says. “As soon as you offer improved wireless broadband, you open the door to new applications and services. People are always able to come up with new ways of inundating any resource, including bandwidth. We’re going to see more data-driven applications on mobile than we see on the typical desktop, because the mobile device is always with you.” And while LTE promises greater spectral efficiency than its 3G forebears, Polychronopoulos says, the fact that spectrum remains a finite resource will prove ever more problematic as services evolve.

“We’re reaching the limits of spectral efficiency,” he says. “Shannon’s Law defines the limit as six bits per Hertz, and while we may be moving to higher-bandwidth wireless broadband, spectrum remains finite. To offer 160Mbps, you have to allocate twice the amount of spectrum than in 3G, and it’s a very scarce and very expensive resource.”

Operators have been wrong to focus exclusively on standards-based solutions to network optimisation issues, Polychronopoulos says. In restricting themselves to 3GPP-based solutions, he argues that they have missed what he describes as “the internet component of wireless data.” Internet powerhouses like Google, Yahoo and Microsoft (which he dubs ‘the GYM consortium’) have established a model that he says is a great threat to the mobile operator community in that it establishes a direct consumer relationship and disregards the “pipe” (wireless broadband connection) used to maintain that relationship.

“The operators have to accelerate the way they define their models around wireless data so that they’re not only faster than the GYM consortium in terms of enabling popular applications, but smarter and more efficient as well,” he says. Dr. Polychronopoulos then makes a popular case for the carriers’ success: “The operators have information about the subscriber that no other entity in the internet environment can have; for example, they know everything the subscriber has done over the lifetime of their subscription and the location of each event. They don’t have to let this data outside of their networks, so they are very well positioned to win the race for the mobile internet.”


Wednesday, 27 April 2011

Possible Release-12 features

Not sure if everyone checked the presentation from yesterday, it has a slide that lists possible Rel-12 features that I have listed below:


Release 12 content not yet defined, but Study Items (SI) in Release 11 indicate where specification work is likely

•Study on IMS based Peer-to-Peer Content Distribution Services

•Study on IMS based Peer-to-Peer Content Distribution Services (Stage 2)

•Study on IMS Network-Independent Public User Identities

•Study on Integration of Single Sign-On (SSO) frameworks with 3GPP networks

•Study on Coordinated Multi-Point operation for LTE

•Study on UE Application Layer Data Throughput Performance

•Study on Uplink MIMO

•Study on Non Voice Emergency Services

•Study on UICC/USIM enhancements

•Study on Alternatives to E.164 for Machine-Type Communications

•Study on enhancements for Machine-Type Communications (MTC)

•Study on Support for 3GPP Voice Interworking with Enterprise IP-PBX

•Study on Security aspects of Integration of Single Sign-On (SSO) frameworks with 3GPP networks

•Study on Core Network Overload solutions

•Study on Continuity of Data Sessions to Local Networks

•Study on Non-MTC Mobile Data Applications impacts

•Study on System Enhancements for Energy Efficiency

•Study on Solutions for GSM/EDGE BTS Energy Saving

•Study on HSDPA Multipoint Transmission

•Study on Inclusion of RF Pattern Matching as a positioning method in the E-UTRAN

Release 11 completion date set for September 2012, Release-12 work will start after that.


Monday, 25 April 2011

Advanced Telephony Services for LTE

With LTE World Summit just round the corner, I was going through the last year's presentations and realised that we didn't talk of this one before.

The concept for the advanced telephony services has been around since the early days of IMS and this was one of the ways IMS was sold. Unfortunately IMS didn't take off as planned and only now with the standardisation of VoLTE, there is a possibility of the advanced services becoming a reality.

The following presentation summarises some of these advanced telephony services concepts.

Sunday, 24 April 2011

ANDSF: Access Network Discovery and Selection Function

The following is a recent news from Mobile Europe:

WeFi has launched a product that is intended to enable mobile operators to route traffic over the mobile macro network or a WiFi hotspot without the consumer having to manage their own settings.

The product, from WeFi, enables operators to set network management policies using a 3GPP-defined function for the Evolved Packet Core called ANDSF – Access Network Discovery and Selection Function. WeFi said that its WeANDSF is the first standards-compliant product on the market, although it said that as the standards are not yet fully finalised, the product is more accurately described as a pre-standards compliant product.

ANDSF, specified in 3GPP standards 23.402 and 24.312, is intended to allow mobile operators to set network management policies and priorities, and to control where, when and under what circumstances a subscriber’s device connects to which wireless network, be it cellular or Wi-Fi.

Operators may choose to route traffic according to application type to reduce network load, or to provide the best available customer experience. Although operators are increasingly looking at using WiFi for offload in congested areas, one problem for them is that once traffic is routed over WiFi control is lost over any traffic policies they have set for that user. ANDSF keeps a link to the operator's core network, allowing the operator visibility of traffic even when it is routed over WiFi.

WeFi said that the product is already in trials with several mobile operators. As handset manufacturers are yet to include the device element of ANDSF, WeFi is also providing a device client, although it sees that role diminishing as handset vendors deliver ANDSF-compliant handsets, “when these become available in the market by 2012”.

The following presentation is by Fraunhofer Fokus on ANDSF:

For more details see:

3GPP TS 23.402: Architecture enhancements for non-3GPP accesses

3GPP TS 24.312: Access Network Discovery and Selection Function (ANDSF) Management Object (MO)

Tuesday, 19 April 2011

Unstructured Supplementary Service Data (USSD) simulation service in IMS (USSI)

I hope we all know USSD. If not then hopefully my old blog post will help remind you of USSD. Apparently USSD is as popular as it was nearly a decade back since it is supported by 100% of the phones. As a result 3GPP have made sure that a USSD like service is available in LTE/SAE since USSD was designed for a CS domain and in SAE we have only the PS domain.


Picture Source: Aayush Weblog

The following is from the 3GPP document:

Today mobile initiated unstructured SS data in MMI mode are widely used to interact with proprietary home-network provided services, e.g. to activate or deactivate certain features or to interrogate some parameter settings.

The user dials a certain feature code, e.g. in the format “*# ”, this code is forwarded to the home network and answered with a text string providing the requested information. Unlike common SMS the string is displayed immediately and not stored on the UE.

A typical use case is the interrogation of the account balance in a prepaid service. The prepaid user e.g. dials "*101#", the message is forwarded to the HPLMN and further to the IN system where the account balance is checked and finally the current value is transferred to the user in a short answer string, e.g. "Balance: € 35,40". Another use case is controlling the active UE for incoming calls and messages in case of a hunting service / multi SIM service.

From a network perspective the functionality is as follows:
1. The user sends the request
2. USSD is sent as MAP message to the HPLMN
3. USSD is forwarded to a Service Node (SN) [non-standardized functionality]
4. USSD is answered
5. answer
6. answer

The mentioned functionality is not available in the EPS. So e.g. a business customer who is subscribed to a certain multi SIM service will use his UEs via CS and EPS/IMS. Dependent on the access he would have to use different mechanisms for controlling the active UE.

This problem can be avoided when introducing completely new services. Then mechanisms can be used that are available via all access networks, e.g. web interfaces via GPRS or EPS. However we are talking about existing services with a broad customer base that is accustomed to use USSD codes as they are fast and simple to use.

As USSD is widely used in CS domain, operators would benefit from re-using the already deployed servers also when the user accesses services that make use of USSD over IMS.

It is therefore desirable to create in 3GPP a service which provides the same capabilities for the user, like the well known "GSM Mobile User Initiated USSD" feature.

For the user, it is important that the user experience is transparent (I.e. the look and feel of the service is independent of the transport mechanism used to convey the USSD payload to the network).


Possible solutions

There are several possibilities to solve this issue. One would be to re-introduce USSD in EPS. This is not the intention as it creates too much overhead. The idea is to specify a light weight solution which provides the same look and feel for the user but uses existing network mechanisms, i.e. only to simulate the USSD service.

One variant could be that the UE when being attached via the EPS to the IMS encapsulates the USSD codes in IP messages and forwards them to the network. This could happen either via the Ut interface as XCAP data using http or in a SIP message.

It should be noted that there are also user initiated MMI mode USSDs for VPLMN use. The differentiation, if USSD are intended for HPLMN or VPLMN use, is done via the range of the feature code. If USSD for VPLMN use were to be supported / simulated this may prevent certain solutions (e.g. using the Ut) and have some architectural impact (considering all possible roaming scenarios for the IMS).

Proposal

To specify an easy solution having no architectural impact. Only the simulation of mobile initiated USSD – MMI mode for HPLMN use should be supported. The functionality should be available for Multimedia Telephony, i.e. it can be implemented with the MMTel UE client and USSD messages are sent to and answered by the MMTel AS.


Though there isn't much details on this feature available, Ayush's weblog has some more details on this feature here.

Monday, 18 April 2011

Multimedia Telephony (MMTel) in 3GPP Rel-7

Came across MMTel multiple times in the last few months so decided to dig a bit more in detail.

The following from wikipedia:

The 3GPP/NGN IMS Multimedia Telephony Service (MMTel) is a global standard based on the IP Multimedia Subsystem (IMS), offering converged, fixed and mobile real-time multimedia communication using the media capabilities such as voice, real-time video, text, file transfer and sharing of pictures, audio and video clips. With MMTel, users have the capability to add and drop media during a session. You can start with chat, add voice (for instance Mobile VoIP), add another caller, add video, share media and transfer files, and drop any of these without losing or having to end the session.

The MMTel standard is a joint project between the 3GPP and ETSI/TISPAN standardization bodies. The MMTel standard is today the only global standard that defines an evolved telephony service that enables real-time multimedia communication with the characteristics of a telephony service over both fixed broadband, fixed narrowband and mobile access types. MMTel also provides a standardized Network-to-Network Interface (NNI). This allow operators to interconnect their networks which in turn enables users belonging to different operators to communicate with each other, using the full set of media capabilities and supplementary services defined within the MMTel service definition.

One of the main differences with the MMTel standard is that, in contrast of legacy circuit switched telephony services, IP transport is used over the mobile access. This means that the mobile access technologies that are in main focus for MMTel are access types such as High Speed Packet Access (HSPA), 3GPP Long Term Evolution (LTE) and EDGE Evolution that all are developed with efficient IP transport in mind.

MMTel allows a single SIP session to control virtually all MMTel supplementary services and MMTel media. All available media components can easily be accessed or activated within the session. Employing a single session for all media parts means that no additional sessions need to be set up to activate video, to add new users, or to start transferring a file. Even though it is possible to manage single-session user scenarios with several sessions – for instance, using a circuit-switched voice service that is complemented with a packet-switched video session, a messaging service or both – there are some concrete benefits to MMTel’s single-session approach. A single SIP session in an all-IP environment benefits conferencing; in particular, lip synchronization, which is quite complex when the voice part is carried over a circuit-switched service and the video part is carried over a packet-switched service. In fixed-mobile convergence scenarios, the single-session approach enables all media parts of the multimedia communication solution to interoperate.

An interesting presentation on MMTel is embedded below.

If you are still hungry for more on this topic then Ericsson's old presentation on MMTel is available on Slideshare here.

Thursday, 14 April 2011

Smart Grids (again)


I blogged about smart grids just the other day but they seem to be the 'in thing' and keep popping up everywhere.

The very interesting picture above is from The Guardian article here, that promises that consumers will be able to cut down on their bills by taking advantage of smart meters.

Meanwhile European Commission is making Smart Grids a high priority. The following is from one of their communique:

The European Commission presented its Communication on smart grids. It sets policy directions to drive forward the deployment of future European electricity networks. Bringing together latest progress in Information and Communication technologies and network development will allow electricity current to flow exactly where and when it is needed at the cheapest cost. Smart grids will give in particular to consumers the ability to follow their actual electricity consumption in real time : smart meters will give consumers strong incentives to save energy and money. Estimates show that smart electricity grids should reduce CO2 emissions in the EU by 9% and the annual household energy consumption by 10%. They also help to ensure secure functioning of the electricity system and are a key enabler of both the internal energy market and integration of vast amounts of renewable.

You can read the complete press summary here. A new report entitled 'Smart Grids: from innovation to deployment' is available to download from here. The European Commission Smart Grids taskforce webpage is here.


The following is from IEEE Spectrum :

On 17 March, game designers at the Institute for the Future, in collaboration with us at IEEE Spectrum, ran a 24-hour forecasting game called Smart Grid 2025. Weenlisted the help of listeners like you and game players around the world to brainstorm solutions to the problems the smart grid will face. That way, by 2025—when all our homes have smart meters and utilities are linking up wind farms and solar plants to national grids—it'll be running as smoothly as it possibly can.

Steven Cherry's guest is Jake Dunagan, the game's project leader at the Institute for the Future in Palo Alto, Calif. He was on this show in early March in advance of the Smart Grid 2025 game to talk about how it would work, and now he's back to tell how it went.

This interview was recorded 4 April 2011. (Listen below)



Background on Smart Grids from the same IEEE article: One of the hottest topics in engineering is the smart grid—the idea of adding computer intelligence to a nation's basic electrical grid. The goal is to transport and use energy more efficiently in the grid itself—and also in your home. By adding intelligence to our electrical meters, fuse boxes, even our home appliances, each of us can use electricity more wisely and consume less of it.

But it's still early days for smart grid deployment. In fact, today, the smart grid still raises more questions than it answers—questions like, who will profit from the smart grid? How do we keep the smart grid from knowing too much about our personal lives? Is the smart grid dangerously hackable? Will the smart grid force you to do your laundry at night? Will the smart grid make us healthier? What kind of appliances are needed to accommodate the smart grid?

Feel free to add your thoughts in the comments.

Wednesday, 13 April 2011

User Data Convergence (UDC) in Release 9 and its evolution

The below is mish-mash from the specs (see refrences at the end)

With the increase of service entities and the resulting user data types, User Data Convergence (UDC) is required to ensure the consistency of storage and data models.

UDC:
simplifies the overall network topology and interfaces
overcomes the data capacity bottleneck of a single entry point
avoids data duplication and inconsistency
reduces CAPEX and OPEX.

UDC simplifies creation of new services and facilitates service development and deployment though a common set of user data.

UDC promotes service and network convergence to support the increasing number of new services including Internet services and UE applications. A new facility User Data Repository (UDR) is considered for UDC.

In UDC, all the user data is stored in a single UDR allowing access from core and service network entities.

To achieve high performance, reliability, security and scalability, the UDR entity may consist of a network of different components distributed geographically, and exposes capabilities via open interfaces in multiple access entry points.


In the current 3GPP system, user data are scattered in several domains (e.g. CS, PS, IMS) and different network entities (e.g. HLR, HSS, Application Servers). With the increase of user data entities and the resulting data types, it is more difficult for integrated services to access necessary user information from plural entities.

The scenario mentioned herein is kind of called “User Data Silo”, which is the major paradigm of user data deployment for the time being, as illustrated by Fig.1. below


With the user data silos, user data are independently accessed, stored and managed independently. That brings many challenges to network deployment and evolution. Different user data access interfaces impose complexity on network topology as well as on application development, especially for booming Internet services and incoming IP-based UE applications; separated user data increases management workload. Moreover, new networks and services such as IMS are expected, so that the introduction of their user data only makes things worse, not to mention network and service convergence even if those user data have a lot in common and are correlated to each other. Separation also undermines the value of user data mining.
User data convergence is required to ensure the consistency of storage and data models. User data convergence will simplify overall network topology and interfaces, overcome the data capacity bottleneck of a single entry point, avoid data duplication and inconsistency and reduce CAPEX and OPEX. Also it will simplify the creation of new services and facilitate service development and deployment though a common set of user data. Finally it will promote service and network convergence to support the increasing number of new services including Internet services and UE applications. In this regard, a new facility User Data Repository (UDR) should be considered for user data convergence.

As illustrated by Fig. 2 above, User Data Convergence, as opposed to User Data Silo, is simply to move the user data from where it belonged, to a facility here called User Data Repository (UDR) where it can be accessed, stored and managed in a common way. Despite of the diversity of user data structures for different services, user data can be decomposed and reformed by a common data model framework (e.g. tree-like data model, rational data model) provided by UDR. In that case, user data categorized by services can be regrouped and identified by user ID, leaving no data redundancy. Also, convergence in data model will unify the user data access interface and its protocol, which will promote new service application development. Thereby, the capability of user data convergence can be open to creation of data-less applications.


There are plenty of data distributed in the 3GPP system which is used to perform the services, for instance, the configuration data of a network entity, the session data of a multimedia call, the IP address of a terminal, etc. With respect to user data, it refers to all kinds of the information related to users who make use of the services provided by the 3GPP system.

In 3GPP system, user data is spread widely through the different entities (e.g. HLR, HSS, VLR, Application servers) and also the type of user data is various. It is of paramount importance to categorize the user data before going through the convergence of user data.

The UDC shall support multiple application user data simultaneously, e.g. HSS and others.
Any application can retrieve data from the UDC and store data in it. The applications shall be responsible of updating the UDC with the dynamic changes of the user profile due to traffic reasons (e.g. user status, user location…) or as a consequence of subscriber procedures.

User Subscription Data: Before a user can enjoy a service, he may need to subscribe the service first. The subscription data relates to the necessary information the mobile system ought to know to perform the service. User identities (e.g. MSISDN, IMSI, IMPU, IMPI), service data (e.g. service profile in IMS) , and transparent data (data stored by Application Servers for service execution) are the examples of the subscription data. This kind of user data has a lifetime as long as the user is permitted to use the service and may be modified during the lifetime. User may be accessed and configured via various means, e.g. customer service, web interface, UE Presence service. The subscription data is composed of different types such as authentication data, configuration data, etc. Different type of data may require different levels of security.

User content Data: Some applications may have to store content defined by the user and that here may be quite large (e.g. Photos, videos) User content data can reach very high volume (e.g. Hundreds of Mbytes and more), and the size required to store them may largely vary over time. They generally do not require the real time constraints as user profile data may require. Storage of user data content is not typically subject of UDR. Storage of user data content is not typically subject of UDR. UDC on user content data can be achieved by converging them with links or references, such as URLs, to other entity.

User Behaviour Data: Such data concerns the usage of services by a user as services are consumed. Generally there are event data records that can be generated on various events in the usage of services by a user and that can be used not only for charging or billing purposes but e.g. for user profiling regarding user behaviour and habits, and that can be valuable for marketing purposes. The amount of such data is also quite different from other categories, they present a cumulative effect as such data can be continuously generated by the network implying a need for corresponding storage. Usage data may require real time aspects about their collection (e.g. for on line charging), they are also often characterized by a high amount of back office processing (e.g. Billing, user profiling). Processing of user behaviour data such as for CRM, billing, data mining is not typically subject of UDR. Those might be processed with lower priority or by external systems whereby UDR supports mass data transfer.

User Status Data: This kind of user data contains call-related or session-related dynamic data (e.g. MSRN, P-TMSI), which are typically stored in VLR or SGSN. These dynamic data are only used by their owner transitorily and proprietarily, and hardly shared by other services in the short term.

Figure 4.1-1 below presents the reference UDC architecture. UDC is the logical representation of the layered architecture that separates the user data from the application logic, so that user data is stored in a logically unique repository allowing access from entities handling an application logic, hereby named Application Front Ends.

In the architecture, the User Data Repository (UDR) is a functional entity that acts as a single logical repository of user data and is unique from Application Front End’s perspective. Entities which do not store user data and that need to access user data stored in the UDR are collectively known as application front ends.

NOTE: Depending on the different network deployment, there may be more than one UDC in an operator’s network.

Application Front Ends (FE) connect to the UDR through the reference point named Ud to access user data.

Figure 4.1-2 shows how the UDC reference architecture is related to the overall network architecture by comparing a Non-UDC Network with an UDC Network. In the non-UDC Network, the figure shows NEs with their own database storing persistent user data and a NE accessing an external database; in both cases, when UDC architecture is applied, the persistent user data are moved to the UDR and concerned NEs are becoming Application-FEs (NE-FEs) according to the UDC architecture. This figure also shows that network interfaces between NEs are not impacted .A Network Element (NE), which in its original form represents application logic with persistent data storage, when the UDC architecture is applied, may become a NE Front End, since the related persistent data storage is moved to the UDR.

3GPP TS 23.335 gives more details and information flows for User Data Convergence

Further evolution of UDC is being studied part of 3GPP TR 23.845. The TR tries to address the assumption of multiple UDRs in a PLMN, to identify consequences and the possible impacts on existing UDC specifications. From a practical point of view, even if the aim is to have one single logical repository, a certain number of considerations may drive to have more than one UDR in a PLMN.

For very large networks with a very large amount of users, although an UDR may be implemented in a distributed architecture and multiple database servers with geographical distribution and geographical redundancy, an operator may consider to deploy several UDRs between which it will distribute the users.

More details in the technical report.


References:

3GPP TR 22.985: Service requirement for the User Data Convergence (UDC) (Release 9)

3GPP TS 23.335: User Data Convergence (UDC); Technical realization and information flows; Stage 2 (Release 10)

3GPP TS 29.335: User Data Convergence (UDC); User Data Repository Access Protocol over the Ud interface; Stage 3 (Release 10)

3GPP TS 32.182: User Data Convergence (UDC); Common Baseline Information Model (CBIM) (Release 10)

3GPP TR 32.901: Study on User Data Convergence (UDC) information model handling and provisioning: Example Use Cases (Release 11)

3GPP TR 29.935: Study on UDC Data Model.

3GPP TR 23.845: Study on User Data Convergence (UDC) evolution (Release 10)