One of the features being investigated and added is the Sponsored Data Connectivity feature in the Evolved Packet System. This feature has lots of backers as this is deemed to be a new source of revenue for the operators.
In Release-10 one of the items for this is titled 'Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Databases (PEST)'
The justification for PEST is as follows:
With the emerging of innovative IP services, the transactional data usage is becoming more and more prevalent on the mobile. For example, the user downloads a purchased ebook from an online store; the user purchases and downloads a game from an operator store; the user views free trailer clip from an online library to determine whether to buy the entire movie or not. In many cases, the Sponsor (e.g., Application service provider) pays for the user’s data usage in order to allow the user to access the Application Service Provider’s services. This enables additional revenue opportunities for both the Application service providers and the operators.
In particular, such dynamic data usage provided by the Sponsor allows the operator to increase revenues from the users with limited data plans. The user may have limited data plans allowing only a nominal data volume per month and the Sponsor may dynamically sponsor additional volume for the user to allow access to the services offered by the Application service providers.
The PCC framework can be enhanced to enable such use cases, in particular, it allows the operator to provide service control based on such sponsored services. For example, it allows a dynamic IP flow to be excluded from the user’s data plan since a Sponsor might sponsor the data usage for the identified IP flows. For example, the user may use the limited data plan to browse an online store for interested books; but once a book is purchased, the data usage for downloading the book can be granted for free. In addition, the IP flow may also be granted certain level of QoS (e.g. video streaming).
TR 23.813 studied the feasibility of these scenarios of sponsored connectivity in the key issue 1 and converged into a set of extensions to the PCC procedures which will allow the operator to provide sponsored connectivity to sponsor entities.
In addition to Key Issue 1, SA2 also studied the feasibility of Key issue 2 - Coherent access to Policy related databases within TR 23.813. It enables UDR (User Data Repository) in the PCC architecture as an optional functional entity where PCC related subscriber data can be stored and retrieved by the PCRF through the Ud interface. This deployment scenario does not require SPR and allows the PCRF access to the PCC related subscriber data stored in the UDR.
In Release-12 PEST is linked to another new feature titled, 'Interworking between Mobile Operators using the Evolved Packet System and Data Application Providers (MOSAP)'
The Justification of this is as follows:
Mobile operators have to deal with increasing flexibility of data services delivery on different devices.
The data services could be hosted by the mobile operators in their data centers within 3GPP domain or could be hosted by 3rd party data application providers that could be outside of the mobile operator domain.
Current practices involve individual mobile operators negotiating agreements with data application providers resulting in proprietary additional functionalities in 3GPP networks which results in non-standard 3GPP interfaces. With the advent of new models of services delivery like cloud computing and Application Stores, it is important that the mobile operator minimises upgrades to the network and associated backend integration.
Also the mobile operator has the opportunity to explore various charging models in this interworking scenario with data service providers.
Sample services/capabilities that mobile operators can provide to data application providers are customised billing/charging, promotional services, group addressing capabilities, identity services, statistics, etc.
This WI proposes to enable the mobile operator to use enhanced functionalities and interfaces to meet the needs of the rapidly changing industry models. The WI is expected to develop requirements and architectural frameworks for authentication, authorization, policy, charging, mobility and session continuity aspects for various interworking scenarios.
The existing schemes for authentication/authorization and charging need to be studied and updated/enhanced, when deemed necessary, by liaising with other 3GPP Working Groups/SDOs/fora in charge of them.
This WI was de-prioritised in Rel-11. The Rel-12 work will take into consideration the new TS 23.682 developed in Rel-11 (Architecture Enhancements to facilitate communications with Packet Data Networks and Applications).
What are you your thoughts on sponsored data connectivity?
xoxoxoxoxoxo Added on 08/07/2012 - 14.00 xoxoxoxoxoxo
I had a quick discussion with Dean Bubley on twitter and here is what he thinks:
Key question is what use cases & how the biz model / sponsor interaction works. 1-800 model is a #UselessCase for example. I think tollfree/1-800 apps is a nice idea, but totally unworkable when you drill into the practicalities. There are a few corner-cases & niche exceptions (eg govt-supplied apps) but proposed case for general apps / content is a chimera.
More details on what Dean Bubley means is on his blog post here.
The comment at the end is very interesting, summarising the hurdles that exist in providing 'Toll-free data'.
My belief is that since the operators are running out of the options in generating new revenues, they may make a compromise and find a middle ground for making the 'Sponsored-data' to work
The problem is divided into two parts, the Access network part where the Air Interface is the bottleneck and the core network part which can easily be swamped by the overwhelming amount of Signalling due to more intelligent billing system and always on devices with background applications generating much more amount of traffic as would have on an older system. Lets look at them in turn.
Core Network Signalling Storm:
As I reported earlier, Diameter has been highlighted as a way of salvation for the operators with dozens of use cases but due to its immaturity has caused outages and have given it a bad name. As Connected Planet mentions, "According to one signaling expert, launching the iPhone’s browser, for example, instantly sets off about fifteen individual network signaling requests. Beyond that, 4G network software elements supporting increasingly sophisticated mobile service scenarios “talk” to each other at rates that traditional TDM/SS7-based networks never had to deal with." Hopefully a stable implementation of Diameter protocol will help not only solve the signalling storm but will help generate new models for charging and revenue generation.
A presentation by Ed Gubbins of Current Analysis, comparing the big vendors of Diameter Signalling is available here.
Access Network Signalling Storm:
My thinking is that the Core Network Signalling problem will become an issue some years down the road whereas the Access Network Signalling problem will be seen sooner rather than later. In fact for 3G/HSPA the problem is becoming more visible as the market has matured and more and more users are moving towards using smartphones, Since LTE rollouts are in its infancy (in most markets) the problem is still some way away.
One of the reasons for Signalling storm is the incorrect APN name. I reported earlier about Telefonica's approach to solve this problem by using 'Parking APN', see here.
Also embedded below are couple of presentations from the Signalling Focus day that talk about the problem from Access Network point of view
This was presented by Giulio Maggiore, Telecom Italia, ETSI TC INT Chairman in the 2nd FOKUS FUSECO Forum 2011, Berlin 17-18 Nov. 2011
From the ETSI leaflet (note that this is quite old information but still on the ETSI website here):
IMS interoperability is a key issue for boosting IMS (IP Multimedia Subsystem) roll-out and more specifically network interconnection between operators. Only through thorough testing in practical scenarios can operators ensure operational excellence in a multi-vendor and multi-provider environment.
IMS comprises a set of specifications designed to enable network operators to implement IP-based networks that can carry services for both fixed and mobile customers simultaneously.
IMS was developed originally in the mobile world (specifically in the specifications created by the 3rd Generation Partnership Project, 3GPP), and was adopted for fixed networks by ETSI’s TISPAN Technical Committee (Telecoms & Internet Converged Services & Protocols for Advanced Networks).
However this promise of advanced communications over the next generation network will only be delivered if those same networks can interconnect.
ETSI is bridging the existing gap between 3GPP IMS Core Network standards and the initial industry IMS implementations through the organization of IMS interoperability events in connection with ETSI’s Centre for Testing & Interoperability (CTI) and Plugtests™ interoperability testing service.
Our Technical Committee for IMS Network Testing (TC INT) is actively establishing close contact with a number of industry fora and organizations dealing with IMS interoperability, including 3GPP, GSMA, MSF (Multi Service Forum), IMS Forum and the ITU-T. TC INT develops IMS test specification according to conformance, network integration and interoperability testing methodologies. Other ongoing work includes development of tests for Supplementary Services based on regulatory requirements and IMS tests with legacy networks (e.g. SIP-I).
ETSI has already held two IMS interoperability events. The first examined interconnection aspects of 3GPP IMS Release 6, including such issues as basic call on the Mw interface. The second event had a wider scope that included the testing of 3GPP IMS Release 7 interworking, roaming, border control, and integration of application servers executing selected Multimedia Telephony supplementary services.
Future ETSI activities and events will go even deeper towards bridging 3GPP IMS standards and industry implementations. These will include the organization of further IMS interoperability events designed to boost the roll-out and take-off of IMS services and operators’ network interconnections.
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.
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
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).
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).
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.
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.
•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.
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)
With EPC, continuous communication is possible, even while the terminal switches from one type of radio access system to another.
Specifically, in order to achieve the internal network path switching required to change radio access systems, the S-GW provides a mobility management anchor function for handover between 3GPP radio access systems, and the P-GW provides the function for handover between 3GPP and non-3GPP radio access systems. In this way, the IP address does not change when the terminal switches radio access systems, and communications can continue after handover.
In handover between the 3GPP radio access systems, LTE and 3G, handover preparation is done before changing systems, including tasks such as securing resources on the target radio access system, through cooperation between the radio access systems (Figure 3 (a)(A)). Then, when the actual switch occurs, only the network path needs to be switched, reducing handover processing time (Fig.3 (a)(B)). Also, loss of data packets that arrive at the pre-switch access point during handover can be avoided using a data forwarding function (Fig.3 (b)).
In this way, through interaction between radio access systems, fast handover without packet loss is possible, even between radio access systems such as LTE and 3G which cannot be used simultaneously.
2) Handover Preparation Procedure (Fig.3 (a)(A))
The handover preparation procedure for switching radio access from LTE to 3G is shown in Figure 4.
Step (1):The terminal sends a radio quality report containing the handover candidate base-stations and other information to the eNodeB. The eNodeB decides whether handover shall be performed based on the information in the report, identifies the base station and RNC to switch to, and begins handover preparation.
Steps (2) to (3): The eNodeB sends a handover required to the MME, sending the RNC identifier and transmission control information for the target radio access system. The MME identifies the SGSN connected to the target RNC based on the received RNC identifier and sends the communication control and other information it received from the eNodeB to the SGSN in a forward relocation request signal. The information required to configure the communications path between the S-GW and SGSN, which is used for data transmission after the MME has completed the handover, is sent at the same time.
Steps (4) to (5): The SGSN forwards the relocation request to the RNC, notifying it of the communications control information transmitted from the eNodeB. The RNC performs the required radio configuration processing based on the received information and sends a relocation response to the SGSN. Note that through this process, a 3G radio access bearer is prepared between the SGSN and RNC.
Step (6): The SGSN sends a forward relocation response to the MME in order to notify it that relocation procedure has completed. This signal also includes data issued by the SSGN and required to configure a communications path from the S-GW to the SGSN, to be used for data forwarding.
Steps (7) to (8): The MME sends a create indirect data forwarding tunnel request to the S-GW, informing it of the information issued by the SSGN that it just received. From the information that the S-GW receives, it establishes a communications path from the S-GW to the SGSN for data forwarding and sends a create indirect data forwarding tunnel response to the MME.
Through this handover preparation, target 3G radio-access resources are readied, the radio access bearer between the SGSN and RNC is configured, and the data forwarding path from the
S-GW to the SGSN configuration is completed.
3) Handover Procedure for Radio Access System Switching (Fig. 3(a)(B)):
The handover process after switching radio access system is shown in Figure 5.
Steps (1) to (2): When the handover preparation described in Fig.4 is completed, the MME sends a handover command to the eNodeB. When it receives this signal, the eNodeB sends a handover from LTE command for the terminal to switch radio systems. Note that when the eNodeB receives the handover command from the MME, it begins forwarding data packets received from the S-GW. Thereafter, packets for the terminal that arrive at the S-GW are forwarded to the terminal by the path: S-GW, eNodeB, S-GW, SGSN, RNC.
Steps (3) to (6): The terminal switches to 3G and when the radio link configuration is completed, notification that it has connected to the 3G radio access system is sent over each of the links through to the MME: from terminal to RNC, from RNC to SGSN, and from SGSN to MME. This way, the MME can perform Step (10) described below to release the eNodeB resources after a set period of time has elapsed.
Step (7): The MME sends a forward relocation complete acknowledgement to the SGSN. A set period of time after receiving this signal, the SGSN releases the resources related to data forwarding.
Step (8): The SGSN sends a modify bearer request to the S-GW to change from the communications path before the handover, between the S-GW and eNodeB, to one between the S-GW and SGSN. This signal contains information elements required to configure the path from S-GW to SGSN, including those issued by the SGSN. When the S-GW receives this signal, it configures a communications path from the S-GW to the SGSN. In this way, the communications path becomes: S-GW, SGSN, RNC, terminal; and data transmission to the target 3G radio access system begins.
Note that after this point, data forwarding is no longer needed, so the S-GW sends a packet to the eNodeB with an “End Marker” attached, and when the eNodeB receives this packet, it releases its resources related to data forwarding.
Steps (9) to (10): The S-GW sends a modify bearer response to the SGSN, indicating that handover procedure has completed. The MME also releases eNodeB resources that are no longer needed.
Through this handover procedure, data is forwarded during the handover, the switch of radio access bearer is completed, and the communications path from the P-GW to the terminal is updated.
In the examples above, we described the handover procedure between 3GPP radio access systems in which the S-GW did not change, but handovers with S-GW relocation are also possible. In these cases, the P-GW provides the anchor function for path switching, as with switches to non-3GPP access systems.
Anchor function: A function which switches the communications path according to the area where the terminal is located, and forwards packets for the terminal to that area.
Relocation: Switching communications equipment such as area switches during communication.
I have in past posted a complete Attach Sequence on the 3G4G website for LTE Radio Signaling but included the signalling on a few nodes. Recently I came across a signalling example in NTT Docomo technical journal which was less detailed but at a higher level and detailed signalling on these other nodes. It may be worthwhile brushing up the LTE Architecture diagram before diving into this.
With EPC, when a terminal connects to the LTE radio access system it is automatically connected to the PDN and this connected state is maintained continuously. In other words, as the terminal is registered on the network (attached) through the LTE radio access system, a communications path to the PDN (IP connectivity) is established.
The PDN to which a connection is established can be preconfigured on a per-subscriber basis, or the terminal can specify it during the attach procedure. This PDN is called the default PDN. With the always-on connection function, the radio link of the connection only is released after a set amount of time has elapsed without the terminal performing any communication, and the IP connectivity between the terminal and the network is maintained. By doing this, only the radio link needs to be reconfigured when the terminal begins actual communication, allowing the connection-delay time to be reduced. Also, the IP address obtained when the terminal attaches can be used until it detaches, so it is always possible to receive packets using that IP address.
The information flow for the terminal attaching to the network up until the connection to the PDN is established is shown in Figure 2 below.
Steps (1) to (3): When the terminal establishes a radio control link for sending and receiving control signals with the eNodeB, it sends an attach request to the MME. The terminal and MME perform the required security procedures, including authentication, encryption and integrity.
Steps (4) to (5): The MME sends an update location request message to the Home Subscriber Server (HSS), and the HSS records that the terminal is connected under the MME.
Step (6): To begin establishing a transmission path to the default PDN, the MME sends a create session request to the S-GW.
Steps (7) to (8): When the S-GW receives the create session request from the MME, it requests proxy binding update to the P-GW. The P-GW allocates an IP address to the terminal and notifies the S-GW of this information in a proxy binding acknowledgement message. This process establishes a continuous core-network communications path between the P-GW and the S-GW for the allocated IP address.
Step (9): The S-GW prepares a radio access bearer from itself to the eNodeB, and sends a create session response signal to the MME. The create session response signal contains information required to configure the radio access bearer from the eNodeB to the S-GW, including information elements issued by the S-GW and the IP address allocated to the terminal.
Steps (10) to (11) and (13): The MME sends the information in the create session response signal to the eNodeB in an initial context setup request signal. Note that this signaling also contains other notifications such as the attach accept, which is the response to the attach request. When the terminal receives the attach accept in Step (11), it sends an attach complete response to the MME, notifying that processing has completed.
Step (12): The eNodeB establishes the radio data link and sends the attach accept to the terminal. It also configures the radio access bearer from the eNodeB to the S-GW and sends an initial context setup response to the MME. The initial context setup response contains information elements issued by the eNodeB required to establish the radio access bearer from the S-GW to the eNodeB.
Steps (14) to (15): The MME sends the information in the initial context setup response to the S-GW in a modify bearer request signal. The S-GW completes configuration of the previously prepared radio bearer from the S-GW to the eNodeB and sends a modify bearer response to the MME.
Through these steps, a communications path from the terminal to the P-GW is established, enabling communication with the default PDN.
If the terminal performs no communication for a set period of time, the always-on connection function described above releases the radio control link, the LTE radio data link, and the LTE radio access bearer, while maintaining the core network communications path.
After the terminal has established a connection to the default PDN, it is possible to initiate another connection to a different PDN. In this way it is possible to manage PDNs according to service.
For example the IMS PDN, which provides voice services by packet network, could be used as the default PDN, and a different PDN could be used for internet access.
To establish a connection to a PDN other than the default PDN, the procedure is the same as the attach procedure shown in Fig.2, excluding Steps (4) and (5).
Attach: Procedure to register a terminal on the network when, for example, its power is switched on.
Detach: Procedure to remove registration of a terminal from the network when, for example, its power is switched off.
Integrity: Whether the transmitted data is complete and has not been falsified. Here we refer to pre-processing required to ensure integrity of the data.
Bearer: A logical transmission path established, as between the S-GW and eNodeB.
Context setup: Configuration of information required for the communications path and communications management.
This white paper provides a summary of the MultiService Forum’s (MSF) Global LTE Interoperability event which took place from March 15-30, 2010.
The LTE Interoperability Event is designed to test standards compliance of Evolved Packet Core network scenarios of interest to major Service Providers, and to gauge vendor support for this technology. Building on the success of previous Global MSF Interoperability (GMI) events, the LTE Interoperability event provided the first global “real network” multi-vendor trial of the Evolved Packet Core infrastructure.
Incorporating the Evolved Packet Core defined within the Third Generation Partnership Project (3GPP) Release 8 (R8) standards, the MSF architecture introduced new access tiles to support LTE access and non-3GPP (specifically eHRPD) access to EPC. The IMS core network provided the application layer for which services may be deployed, and the binding of Quality of Service utilizing the Policy and Charging Control (PCC) for the bearer.
The event demonstrated that most of the defined LTE/EPC interfaces were mature and interoperable; however limited backwards compatibility between different implementations of 3GPP Release 8 specifications did create some issues. The fact that 3GPP does not require backward compatibility is a known limitation, but it is important to understand that this is limiting interoperability with commercially available equipment. Service providers will need to factor this into vendor selection.
Highlights of the event included:-
Sessions were successfully established via LTE access to EPC, with creation of default and dedicated bearers with appropriate Quality of Service applied.
An end-to-end IMS Voice over LTE session was also successfully demonstrated,
Access to the EPC via a simulated eHRPD access was successfully tested.
Handover between LTE and eHRPD,
Roaming was successfully tested.
Though the essential standards are reasonably mature, the implementation of early versions of the standards within several of the available implementations of network nodes highlights the problems that can arise due to non-backwards compatibility between 3GPP releases. It is also clear that early implementations have focused initially on development of LTE access to EPC and that support for legacy access (2G/3G) to EPC is somewhat behind. Events such as the MSF LTE Interoperability event highlight these issues and prove the validity of the MSF approach to achieving multi-vendor interoperability.