Updated LTE Architecture with LCS and MBMS entities

Here is an attempt to update the LTE Architecture with MBMS and Location Services (LCS) entities included

You can also refer to the following old posts:

• Simplifying LTE/SAE Interfaces
• 3GPP Official 'MBMS support in E-UTRAN' - Mar 2011
• MBMS in LTE Release-9

3GPP LTE Evolved Packet System & Application to Femtos

3GPP LTE Evolved Packet System & Application to Femtos

View more presentations from Zahid Ghadialy

A video of the actual presentation is embedded below. Its quite long (94 minutes)



The presentation is available to download in PDF format from here.

Evolution towards ALL-IP Single RAN (SRAN)

Presented by Matthias Sauder and Dr. Volker Sebastian, VodafoneD2 GmbH in the 2nd FOKUS FUSECO Forum 2011, Berlin 17-18 Nov. 2011

More on Policy and Charging in LTE

Continuing on the Policy and Charging in LTE from the previous post here.

Presented by Erik P. Neitzel, DMTS, Technology Development Group, U.S. Cellular in the LTE North America 2011 conference

Introduction of HSS in the LTE

Click on the pic to enlarge

Interesting slides from E-Plus Mobilfunk GmbH & Co. KG presented in FUSECO Forum 17th-18th November 2011, Berlin.

LTE Policy Control and Charging

What is coming next after LTE and IMT-Advanced

Interesting presentation from NSN

What is coming next after LTE and IMT-Advanced

View more presentations from Zahid Ghadialy

Other related posts:

• Next Mobile Network (NMN)
• 4G Mobile Broadband Evolution: 3GPP Release-10 and Beyond

ETSI INT IMS/EPC Interoperability Standardisation: Motivation, Roadmap & First Results

INT = IMS Network Testing. ETSI INT website here. More details below the presentation:

ETSI INT IMS/EPC INTEROPERABILITY STANDARDISATION

View more presentations from Zahid Ghadialy

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’s Technical Committee INT: IMS Network Testing


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.

Donor eNB (DeNB) and Relay Node (RN)

Extracted from 3GPP 36.300:

The eNB hosts the following functions:

- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);

- IP header compression and encryption of user data stream;

- Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;

- Routing of User Plane data towards Serving Gateway;

- Scheduling and transmission of paging messages (originated from the MME);

- Scheduling and transmission of broadcast information (originated from the MME or O&M);

- Measurement and measurement reporting configuration for mobility and scheduling;

- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);

- CSG handling;

- Transport level packet marking in the uplink.

The DeNB hosts the following functions in addition to the eNB functions:

- S1/X2 proxy functionality for supporting RNs;

- S11 termination and S-GW/P-GW functionality for supporting RNs.

E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface. The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also applies to RNs unless explicitly specified. RNs do not support NNSF. In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2, RRC, and NAS functionality, in order to wirelessly connect to the DeNB.

The architecture for supporting RNs is shown in Figure 4.7.2-1. The RN terminates the S1, X2 and Un interfaces. The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and S GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for X2) and an S-GW (for S1-U) to the RN.

For more details see - 3GPP TS 36.300 : Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)

Detailed presentation on Femtocell Security from Black Hat 2011

Femtocells: a Poisonous Needle in the Operator's Hay Stack

View more presentations from Zahid Ghadialy

Presentation available to download from here.

Detailed write-up on: Exploiting the Ubiquisys/SFR femtocell webserver here.

My earlier blogpost 'Femto Hacking in UMTS and LTE' here.

Femto Hacking in UMTS and LTE

Couple of weeks back, The Hacker’s Choice (THC) made available some documents about how the Vodafone's (UK) Femtocell (a.k.a. SureSignal) is unsecure and can be hacked. Everyone seemed to jump on this bandwagon with some news articles even sounding like the whole Vodafone network has been hacked and hackers may be sending messages and making calls via your phone number.

In the end it came to light that the problem was fixed over a year back when Vodafone was made aware of this problem. THC is still arguing that there is an architecture fault and the Femto can be compromised.

As a result I decided to think about what could happen if the Femtocell is hacked.

Lets take case of UMTS Femtocell. A simple network architecture with femtocell (oficially known as Home NodeB) is as follows:

As you can see, the signalling over the air interface is encrypted and integrity protected. If a hacker is able to get into the Femto and able to listen to all the packets using some tool like WireShark, he would be able to get hold of the Ciphering and Integrity Keys as they come in cleartext in the RANAP Security Mode Command message.

It wouldnt be difficult to have a device that can listen to the conversations once provided with this keys. In fact if the hacker is able to listen to the messages, there is no reason he cannot stick his own messages at the right interval (when a voice call is ongoing) to send SMS and would appear that the message actually went from the phone number. Note that this message would be inserted in the Home NodeB and would be a NAS message. The end user would generally never find out that a message has been sent on behalf of his phone.

One thing that should be remembered though is that the phone would have to be in the range of the Femtocell and connected successfully to the network (via the Femto). One question someone may have is that can I not reverse engineer the key so that I can clone the SIM card. Fortunately for us, this is not easily possible. There are multiple levels of protection and generally it would be difficult to get the algorithms for generating the key. Also it should be noted that the authentication algorithms are confidential and only the operators know the algorithm.

Now lets look at the LTE Femtocell (a.k.a. Home eNodeB) as shown below:

One of the differences you may notice is that the signalling from Femto to the Core Network over S1 is encrypted and Integrity Protected. In case of the LTE Femto, there are multiple keys and only the required key (Kenb) is provided to the Femto. See the key hierarchy below:

Source: RedYoda

This would sound like an ideal protection from the end user perspective but some of the problems still remain. If the hacker can get hold of the Kenb which is sent in cleartext over the S1 interface via Initial Context Setup Request message then he could easily use it to listen to the packets. Since there is no voice support as of yet in LTE, it would only be the packets that the hacker can listen to.

As you may notice, there is now an Integrity and Ciphering on the S1 interface for the UE messages, the hacker cannot get hold of the Kasme or the master keys K, CK and IK. This means that he cannot insert rouge messages that would for example send unsolicited SMS on behalf of the user as he would be able to do in case of UMTS.

There is a small caveat though. There are multiple Ciphering and Integrity algorithms defined in the standard. No ciphering is defined as eea0 algorithm. In Release-8 of LTE, there was no possibility to have Integrity switched off as there was no eia0 algorithm defined. In Release-9 though, the new eia0 has been defined which means that the network can set the Integrity to NULL. I am sure that the network would not want to do so as it makes absolutely no sense but the hacker can force it to do so.

When the Network requests the UE to send the capability information, the hacker can force it to say that it only supports eia0 and eea0 which would mean that the integrity and ciphering in the call would be off. To be honest, this is quite a difficult thing to do in real time and also the network would not accept a UE that does not support other Integrity and Ciphering algorithms.

3GPP has already forseen these kind of threats that could be affecting the networks in the future when they roll out the Femtocells. As a result they have produced 3GPP TR 33.820 that lists all the possible threats and the best practices that can help to minimise the chances of the network being compromised. If that document is too big and technical, you can go though this presentation as it summarises some of the problems.

Feel free to comment or correct any mistakes that you think I have made.

Network Mode of Operation (NMO)

Picture Source: Tektronix

The Network Mode of Operation (NMO) is also sometimes referred to as Network Operation Mode (NOM). The Network Modes have different values and interpretation in UTRAN and GERAN

In both the cases the Operation modes is decided based on the Gs interface between the CS CN (core network) a.k.a. MSC and the PS CN a.k.a. SGSN

In UTRAN:

Network Operation Mode I (NMO-I) is used when the Gs interface is present. In this case during the registration a Combined Attach (includes GPRS Attach & IMSI Attach procedures) procedure can be performed. A GMM Attach Request message with the attach type set to Combined Attach is used. Upon completion of this procedure, MM Status is IMSI Attached and GMM State is Attached.

In Network Operation Mode II (NMO-II) the GS Interface is not present. So the GMM attach procedure and the IMSI Attach (via Location Update) has to be performed seperately. This causes additional signalling.

Basic air interface signalling in case of NMO2 is shown here.

In GERAN:

Network operation mode 1. A network which has the Gs interface implemented is referred to as being in network operation mode 1. CS and PS paging is coordinated in this mode of operation on either the GPRS or the GSM paging channel. If the mobile device has been assigned a data traffic channel then CS paging will take place over this data channel rather than the paging channel (CS or PS).

Network operation mode 2. The Gs interface is not present and there is no GPRS paging channel present. In this case, paging for CS and PS devices will be transferred over the standard GSM common control channel (CCCH) paging channel. Even if the mobile device has been assigned a packet data channel, CS paging will continue to take place over the CCCH paging channel and thus monitoring of this channel is still required.

Network operation mode 3. The Gs interface is not present. CS paging will be transferred over the CCCH paging channel. PS paging will be transferred over the packet CCCH (PCCCH) paging channel, if it exists in the cell. In this case the mobile device needs to monitor both the paging channels.

The GERAN part above is extract from the book Convergence Technologies for 3G Networks.

From Martin Sauter's Blog:

The Gs interface, has a number of subtle but important advantages:

During an ongoing GPRS / EDGE data transfer (TBF established), mobiles can't detect incoming voice calls and SMS messages as they are focused on receiving packets and thus can not observe the paging channel. In NMO-1, the circuit switched part of the network forwards the paging message to the packet switched side of the network which then forwards the paging message between the user data blocks while a data transfer is ongoing. Mobiles can thus receive the paging message despite the ongoing data transfer, interrupt the session and accept the voice call or SMS.

Location/Routing area updates when moving to a cell in a different location/routing area are performed much faster as the mobile only communicates with the packet switched part of the network. The packet switched network (the SGSN) then forwards the location update to the circuit switched part of the network (to the MSC) which spares the mobile from doing it itself. This is especially important for ongoing data transfers as these are interrupted for a shorter period of time.

Cell reselections from UMTS to GPRS can be executed much faster due to the same effect as described in the previous bullet. Whithout NOM-1 an Inter RAT (Radio Access Technology) cell reselection with Location and Routing Area update requires around 10 to 12 seconds. With NOM-1 the time is reduced to around 5 to 6 seconds. An important difference as this reduces the chance to miss an incoming call during the change of the radio network. Also, ongoing data transfers are interrupted for a shorter time,an additional benefit that should not be underestimated.

Couple of presentations on GNSS and LCS

I came across couple of presentations from International Conference on Localization and GNSS, held in Tampere, Finland, June 29-30, 2011

This first presentation by Lauri Wirola of Nokia gives good summary of standardized positioning technologies in use today. It also lists the difference between control plane and user plane positioning. The 3GPP based positioning from Rel 5 to Rel 8 has been listed. Overall a very interesting presentation.

Location Standards driving the mass market LCS adoption

View more presentations from Zahid Ghadialy

The second presentation by Ignacio Fernández Hernández of the European Commission, gives an overview of the EU satnav programmes (Galileo, EGNOS) and current R&D status; Present some numbers and findings of the overall GNSS R&D panorama in EU and abroad; Present some trends and challenges in location technologies for the following years. Another interesting presentation I think.

GNSS Programmes and R&D landscape in the EU

View more presentations from Zahid Ghadialy

Roaming with the IP eXchange (IPX)

From Wikipedia:

Traditionally, voice traffic interconnection between different operators has utilized the international SS7/TDM networks. However, lately the all-IP paradigm with VoIP is being rapidly introduced by different operators in various forms, such as IMS. In order to minimize the number of conversions between packet-switched voice and circuit-switched voice there is a clear need to deploy an IP based NNI (Network-to-Network Interface) and therefore an IP based interconnection network.

It is also evident that a large number of IP based services (such as Presence or IM) simply cannot be interconnected using a SS7/TDM network, further increasing the need for evolution into an IP based interconnection network.

Since the year 2000 GSM operators have been using GRX (GPRS Roaming Exchange) network for routing the IP based commercial roaming traffic between visited and home operators. Mainly 2.5G and 3G data roaming has been using GRX. GRX is a private IP network (separated from internet) consisting of multiple different GRX carriers that are connected to each other via peering points. However, GRX is limited only to GSM operator community and not all GRX's are capable of meeting the demands of real-time services.

Even though the GRX environment is not entirely suitable as a common IP network for interconnection and roaming, it offers a good starting point for the development of IPX. IPX development has been done in various GSM Association projects and working groups since 2004.

The following presentation is from LTE World Summit:

The IP Interconnect in VoLTE - Market & Technical requirements

View more presentations from Zahid Ghadialy

NTT DoCoMo: Core Network Evolution and Voice Strategy

Core network evolution and voice strategy

View more presentations from Zahid Ghadialy.

Presentation by Seizo ONOE, Senior Vice President and Managing Director of R&D Strategy Department NTT DOCOMO, INC. in LTE World Summit 2010 on the 18th May 2010

IPv6 transition in cellular networks gaining momentum

IPv6 is good and we all know that. I has been talked for years but practically it hasnt found much success. Verizon made some noise last year but I am not sure of the conclusion.

Just to recap, IPv4 was introduced back in 1982 and IPv6 work started since 1995. IPV4 uses 32 bit (4 bytes) addresses while IPV6 uses 128 bit (16 bytes) addresses. Theoretically we would now have 2^96 times more addresses than in case of IPv4.

Most of network infrastructure manufacturers have their equipment ready for IPv6 as some of the handset manufacturers. The main driver being that someday soon IPv4 addresses would be exhausted (Internet Assigned Numbers Authority will run out of IPv4 addresses in September of 2011, based on current projections) and their equipment would be ready to provide IPv6 addresses without any problems.

Recently, IETF-3GPP Workshop on IPv6 in cellular networks was held in San Francisco, USA on 1 - 2 March, 2010. There are lots of interesting presentations available here for people who want to dig a bit deeper. The concluding report that summarises the presentations and discussions are available here. Here is a brief summary from one of the reports (with links at the end):

Summary

• Scenarios for IPv6 migration were discussed based on 3GPP Technical Report 23.975
• The discussion focused on validating the scenarios
• General IPv6 transition and deployment guidelines were outlined based on input from IETF
• Solutions for migration and v4-v6 co-existence were presented
  
• Solutions included existing RFCs and working group items but also proposals in Internet Drafts
• Gap analysis wrt transition scenarios was discussed

Conclusions on scenarios

• Scenarios 1 and 3 based on dual-stack and IPv6-only deployments were generally recognized as valid
• See docs IPW100013, IPW100028
• Scenario 2 was also recognized as valid, addressing two separate problems related to insufficient RFC1918 space and subscriber identification
• See doc IPW100027
• Scenario 4 did not receive wide support from the workshop, largely because it was felt that it addressed a problem already solved by other scenarios
• Variants of some of these scenarios were brought up during the discussions, conclusions were not reached on these
• These may need further discussion

Conclusions on solutions

• It was recognized that necessary support in the network and devices is already available to “switch on” IPv6 in 3GPP networks
• Some networks reported running dual stack
• Some networks reported running IPv6-only now
• Solutions enhancing existing mechanisms for dual stack deployments and new solutions for IPv6-only deployments drew wide support
• Gateway-initiated Dual Stack Lite
• Stateful IPv4/IPv6 translation

Next steps: 3GPP

• IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
• Note that the workshop itself does not have the mandate to make formal decisions
• 3GPP is expected to identify possible normative specification impacts, if any, of the preferred solutions
• A need was identified to provide more operational guidelines about IPv6 deployment to 3GPP operators
• The best location for these guidelines is FFS (e.g. 3GPP TR 23.975, GSMA, etc)

Next steps: IETF

• IETF and 3GPP are expected to focus further work based on the conclusions of the workshop
• Note that the workshop itself does not have the mandate to make formal decisions
• IETF is encouraged to continue working on stateless and stateful IPv4/IPv6 translation mechanisms
• These mechanisms are being worked on in IETF BEHAVE group
• IETF is also encouraged to consider new solutions that are not yet working group items
• Gateway Initiated DS Lite
• Per-interface NAT44 bindings addressing IPv4 address shortage
• Note that the workshop has not set any timelines

Further reading:

• 3GPP TR 23.975: IPv6 Migration Guidelines, Release 10 (http://www.3gpp.org/ftp/Specs/archive/23_series/23.975/)
• 'IETF-3GPP Workshop on IPv6 in cellular networks' Workshop Presentations (http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/)
• 'IETF-3GPP Workshop on IPv6 in cellular networks' Workshop Summary Report(http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Report/)
• 3G Americas Report on 'Transitioning to IPv6' (http://3gamericas.org/documents/2008_IPv6_transition_3GA_Mar2008.pdf)
• Is IPv6 Finally on the Verge? - Light Reading (http://www.lightreading.com/document.asp?doc_id=189143)
• Jari Arkko's Publications (http://www.arkko.com/publications.html)

Evolution of 3G Networks: The Concept, Architecture and Realisation of Mobile Networks beyond UMTS

This book has a title that can be a bit misleading but the main focus is on LTE network. One of the main problems that I generally notice is the lack of understanding of the bigger picture from the network point of view. This book can help fill that gap. The book starts with Mobile Network Evolution in General and moves to explain the evolved 3GPP network.

The different layers and interfaces have been explained quite well and the concepts have been well illustrated with the diagrams. A lot of books have diagrams that are verbatim copy of the standards of illustrated in a complicated way, these have been avoided in this book. To illustrate my point lets look at this image below that shows example arrangement of bearers with multiple PDN connectivity.

Later on the signalling for different scenarios have been explained in a rather nice way. For example of we look at PDN connectivity again, its rather simply explained.

There are many examples of signalling and once they are complete, there is a chapter looking at different protocols like GTP, PMIP, DIAMATER, SCTP, etc.

The book is a bit pricey though but worth the investment if your focus is on the signalling side of things and if you are required to understand the concepts quite well. You can also have a look at the book n google books as embedded below:

UICC and USIM in 3GPP Release 8 and Release 9

In good old days of GSM, SIM was physical card with GSM "application" (GSM 11.11)

In the brave new world of 3G+, UICC is the physical card with basic logical functionality (based on 3GPP TS 31.101) and USIM is 3G application on a UICC (3GPP TS 31.102). The UICC can contain multiple applications like the SIM (for GSM), USIM and ISIM (for IMS). There is an interesting Telenor presentation on current and future of UICC which may be worth the read. See references below.

UICC was originally known as "UMTS IC card". The incorporation of the ETSI UMTS activities into the more global perspective of 3GPP required a change of this name. As a result this was changed to "Universal Integrated Circuit Card". Similarly USIM (UMTS Subscriber Identity Module) changed to Universal Subscriber Identity Module.

The following is from the 3G Americas Whitepaper on Mobile Broadband:

UICC (3GPP TS 31.101) remains the trusted operator anchor in the user domain for LTE/SAE, leading to evolved applications and security on the UICC. With the completion of Rel-8 features, the UICC now plays significant roles within the network.

Some of the Rel-8 achievements from standards (ETSI, 3GPP) are in the following areas:

USIM (TS 31.102)
With Rel-8, all USIM features have been updated to support LTE and new features to better support non-3GPP access systems, mobility management, and emergency situations have been adopted.

The USIM is mandatory for the authentication and secure access to EPC even for non-3GPP access systems. 3GPP has approved some important features in the USIM to enable efficient network selection mechanisms. With the addition of CDMA2000 and HRPD access technologies into the PLMN, the USIM PLMN lists now enable roaming selection among CDMA, UMTS, and LTE access systems.

Taking advantage of its high security, USIM now stores mobility management parameters for SAE/LTE. Critical information like location information or EPS security context is to be stored in USIM rather than the device.

USIM in LTE networks is not just a matter of digital security but also physical safety. The USIM now stores the ICE (In Case of Emergency) user information, which is now standardized. This feature allows first responders (police, firefighters, and emergency medical staff) to retrieve medical information such as blood type, allergies, and emergency contacts, even if the subscriber lies unconscious.

3GPP has also approved the storage of the eCall parameters in USIM. When activated, the eCall system establishes a voice connection with the emergency services and sends critical data including time, location, and vehicle identification, to speed up response times by emergency services. ECalls can be generated manually by vehicle occupants or automatically by in-vehicle sensors.

TOOLKIT FEATURES IMPROVEMENT (TS 31.111)
New toolkit features have been added in Rel-8 for the support of NFC, M2M, OMA-DS, DM and to enhance coverage information.

The contactless interface has now been completely integrated with the UICC to enable NFC use cases where UICC applications proactively trigger contactless interfaces.

Toolkit features have been updated for terminals with limited capabilities (e.g. datacard or M2M wireless modules). These features will be notably beneficial in the M2M market where terminals often lack a screen or a keyboard.

UICC applications will now be able to trigger OMA-DM and DS sessions to enable easier device support and data synchronization operations, as well as interact in DVB networks.

Toolkit features have been enriched to help operators in their network deployments, particularly with LTE. A toolkit event has been added to inform a UICC application of a network rejection, such as a registration attempt failure. This feature will provide important information to operators about network coverage. Additionally, a UICC proactive command now allows the reporting of the signal strength measurement from an LTE base station.

CONTACT MANAGER
Rel-8 defined a multimedia phone book (3GPP TS 31.220) for the USIM based on OMA-DS and its corresponding JavaCard API (3GPP TS 31.221).

REMOTE MANAGEMENT EVOLUTION (TS 31.115 AND TS 31.116)
With IP sessions becoming prominent, an additional capability to multiplex the remote application and file management over a single CAT_TP link in a BIP session has been completed. Remote sessions to update the UICC now benefit from additional flexibility and security with the latest addition of the AES algorithm rather than a simple DES algorithm.

CONFIDENTIAL APPLICATION MANAGEMENT IN UICC FOR THIRD PARTIES
The security model in the UICC has been improved to allow the hosting of confidential (e.g. third party) applications. This enhancement was necessary to support new business models arising in the marketplace, with third party MVNOs, M-Payment and Mobile TV applications. These new features notably enable UICC memory rental, remote secure management of this memory and its content by the third party vendor, and support new business models supported by the Trusted Service Manager concept.

SECURE CHANNEL BETWEEN THE UICC AND TERMINAL
A secure channel solution has been specified that enables a trusted and secure communication between the UICC and the terminal. The secure channel is also available between two applications residing respectively on the UICC and on the terminal. The secure channel is applicable to both ISO and USB interfaces.

RELEASE 9 ENHANCEMENTS: UICC: ENABLING M2M AND FEMTOCELLS
The role of femtocell USIM is increasing in provisioning information for Home eNodeB, the 3GPP name for femtocell. USIMs inside handsets provide a simple and automatic access to femtocells based on operator and user-controlled Closed Subscriber Group list.

Work is ongoing in 3GPP for the discovery of surrounding femtocells using toolkit commands. Contrarily to macro base stations deployed by network operators, a femtocell location is out of the control of the operator since a subscriber can purchase a Home eNodeB and plug it anywhere at any time. A solution based on USIM toolkit feature will allow the operator to identify the femtocells serving a given subscriber. Operators will be able to adapt their services based on the femtocells available.

The upcoming releases will develop and capitalize on the IP layer for UICC remote application management (RAM) over HTTP or HTTPS. The network can also send a push message to UICC to initiate a communication using TCP protocol.

Additional guidance is also expected from the future releases with regards to the M2M dedicated form factor for the UICC that is currently under discussion to accommodate environments with temperature or mechanical constraints surpassing those currently specified by the 3GPP standard.

Some work is also expected to complete the picture of a full IP UICC integrated in IP-enabled terminal with the migration of services over EEM/USB and the capability for the UICC to register on multicast based services (such as mobile TV).

Further Reading:

• Business perspective and Mobile service offer through Future SIM - Telenor (http://www.ux.uis.no/atc08/workshop/Larsen.pdf)
• The role of the UICC in Long Term Evolution all IP networks - Gemalto (http://www.gemalto.com/telecom/download/lte_gemalto_whitepaper.pdf)
• Technical White Paper: Smart Card in IMS - 3G Americas (http://www.3gamericas.org/documents/GEM_WP_IMS.pdf)
• 3GPP TS 31.101: UICC-terminal interface; Physical and logical characteristics (http://www.3gpp.org/ftp/Specs/archive/31_series/31.101/)
• 3GPP TS 31.102: Universal Subscriber Identity Module (USIM) application (http://www.3gpp.org/ftp/Specs/archive/31_series/31.102/)
• 3GPP TS 31.111: Universal Subscriber Identity Module (USIM) Application Toolkit (USAT) (http://www.3gpp.org/ftp/Specs/archive/31_series/31.111/)
• 3GPP TS 31.115: Secured packet structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications (http://www.3gpp.org/ftp/Specs/archive/31_series/31.115/)
• 3GPP TS 31.116: Remote APDU Structure for (U)SIM Toolkit applications (http://www.3gpp.org/ftp/Specs/archive/31_series/31.116/)
• 3GPP TS 31.220: Characteristics of the Contact Manager for 3GPP UICC applications (http://www.3gpp.org/ftp/Specs/archive/31_series/31.220/)
• 3GPP TS 31.221: Contact Manager Application Programming Interface (API); Contact Manager API for Java Card™ (http://www.3gpp.org/ftp/Specs/archive/31_series/31.221/)

Simplifying LTE/SAE Interfaces

Here is simplified diagram of LTE Interfaces from my upcoming training on LTE/SAE. Hope you find it useful.

India gets ready for 3G

So here comes 3G in India. It’s been long coming as the data needs were increasing rapidly in almost all the Indian states. With the existing cellular infrastructure not capable of holding huge traffic particular for data, arrival of 3G was imminent.

The Indian Department of Telecoms (DoT) has published its official timetable for the award of its 3G licences across the country as well as a breakdown of how the relevant spectrum will be allocated across the telecoms circles.

As expected, the state-owned operators BSNL and MTNL each have been reserved one block of 2x5MHz in each circle, with the exception of Rajasthan (State in North West India) which will have no 3G spectrum at all. The number of blocks of spectrum in the private auction differs depending on the circle (see the spectrum table, below).

The auction for the 15-year licences is planned for Jan. 15, 2009. In the majority of 3G service areas there is 25 MHz of paired frequency bandwidth available which relates to four blocks of 2x5 MHz spectrum available for auction in addition to the block reserved for the state-owned operators, Bharat Sanchar Nigam (BSNL) and Mahanagar Telephone Nigam (MTNL). Spectrum is rather limited in many other areas, including the major metro circle of Delhi where only two 2x5MHz blocks will be available to private operators.

All of the 3G spectrum will be in the 2.1 GHz band and in the 2.3 GHz and 2.5 GHz frequency bands, a separate auction for Broadband Wireless Access (WiMAX). In both these auctions, which will take place two days after the 3G auction, bidders are restricted to just one block of spectrum per service area.

The table below shows the proposed spectrum layout.

Service Area (Indian Cities or States)	Paired frequency bandwidth to be allotted	Paired frequency bandwidth to be allotted
Delhi	160	15
Mumbai	160	25
Kolkata	80	25
Maharashtra	160	25
Gujrat	160	15
Andhra Pradesh	160	25
Karnataka	160	25
Tamil Nadu	80	25
Kerela	80	25
Punjab	80	25
Haryana	80	25
Uttar Pradesh(e)	80	25
Uttar Pradesh (w)	80	10
Rajasthan	0	20
Madhya Pradesh	80	25
Bengal	80	25
Himachal Prades	30	25
Bihar	30	25
Orrisa	30	25
Assam	30	25
North East	30	5
Jammu And Kashmir	30	25