Showing posts with label Release 9. Show all posts
Showing posts with label Release 9. Show all posts

Monday, May 31, 2010

LTE Femtocell Enhancements for Release-9

LTE Release 9 provides further functionality to support more efficiently HeNBs operation and to provide a better user experience. The key functionality added the Radio Access Network for HeNBs in Release 9 are:

• A novel Hybrid Cell concept
• Management of out-of-date CSG info
• Inbound Mobility (including proximity reports)
• Access Control
• Operation, Administration and Maintenance for HeNB
• Operator controlled CSG list
• RF Requirements for TDD and FDD HeNBs

Nomor Research have recently released a paper that covers all these issues and much more. Titled "LTE Home Node Bs and its enhancements in Release 9", its available to download here.

Friday, March 26, 2010

E-UTRAN Mobility Drivers and Limitations

Many years back, when things used to be simple, I wrote a tutorial about Handovers in UMTS. It would be very difficult to write a similarly simple tutorial for LTE. Things are a bit complicated because there are many different conditions in which handovers can take place.

It was also easier to visualise the Intra-frequency and Inter-frequency handovers in UMTS and you can probably do the same to some extent in LTE but with things getting more complicated and carrier aggregation, classifying handovers in these categories may be difficult.

3GPP TS 36.300 has an informative Annex E which details the scenarios in which handovers and cell change can/will take place.

It is best to go and see Annex E in detail. Here is a bit of summary from there:

Intra-frequency mobility: intra-frequency mobility is the most fundamental, indispensable, and frequent scenario. With the frequency reuse being one in E-UTRAN, applying any driver other than the “best radio condition” to intra-frequency mobility control incur increased interference and hence degraded performance.

Inter-frequency mobility: as in UTRAN, an operator may have multiple carriers/bands for E-UTRAN working in parallel. The use of these frequency layers may be diverse. For example, some of these frequency layers may utilise the same eNB sites and antenna locations (i.e., co-located configuration), whereas some may be used to form a hierarchical cell structure (HCS), or even be used for private networks. Some frequency layers may provide MBMS services, while some may not. Moreover, E-UTRAN carriers/bands may be extended in the future to increase capacity.

Inter-RAT mobility: the aspects that need to be considered for inter-RAT are similar to those for inter-frequency. For mobility solutions to be complete with the inter-RAT drivers, relevant updates would be necessary on the legacy (UTRAN/GERAN) specifications. This will add to the limitations, which are evidently more effective in inter-RAT.


The drivers for mobility control are:

Best radio condition: The primary purpose of cell reselection, regardless of intra-frequency, inter-frequency, or inter-RAT, is to ensure that the UE camps on/connects to the best cell in terms of radio condition, e.g., path loss, received reference symbol power, or received reference symbol Es/I0. The UE should support measurements to suffice this aspect.

Camp load balancing: This is to distribute idle state UEs among the available bands/carriers/RATs, such that upon activation, the traffic loading of the bands/carriers/RATs would be balanced. At least the path loss difference between different bands should be compensated to avoid UEs concentrating to a certain frequency layer.

Traffic load balancing: This is to balance the loading of active state UEs, using redirection for example. In E-UTRAN, traffic load balancing is essential because of the shared channel nature. That is, the user throughput decreases as the number of active UEs in the cell increases, and the loading directly impacts on the user perception.

UE capability: As E-UTRAN bands/carriers may be extended in the future, UEs having different band capabilities may coexist within a network. It is also likely that roaming UEs have different band capabilities. Overlaying different RATs adds to this variety.

Hierarchical cell structures: As in UTRAN, hierarchical cell structures (HCS) may be utilised in E-UTRAN to cover for example, indoors and hot spots efficiently. It is possible that E-UTRAN is initially deployed only at hot spots, in which case this driver becomes essential for inter-RAT, not just for inter-frequency. Another use case would be to deploy a large umbrella cell to cover a vast area without having to deploy a number of regular cells, while providing capacity by the regular cells on another frequency.

Network sharing: At the edge of a shared portion of a network, it will be necessary to direct UEs belonging to different PLMNs to different target cells.

Private networks/home cells: Cells that are part of a sub-network should prioritise the camping on that sub-network. UEs that do not belong to private sub-networks should not attempt to camp or access them.

Subscription based mobility control: This mobility driver aims to limit the inter-RAT mobility for certain UEs, e.g., based on subscription or other operator policies.

Service based mobility control: An operator may have different policies in allocating frequencies to certain services. For example, the operator may concentrate VoIP UEs to a certain frequency layer or RAT (e.g., UTRAN or GERAN), if evaluations prove this effective. UEs requiring higher data rates may better be served on a frequency layer or RAT (e.g., E-UTRAN) having a larger bandwidth. The operator may also want to accommodate premium services on a certain frequency layer or RAT, that has better coverage or larger bandwidth.

MBMS: For Release-9, no new mobility procedures compared to Release-8 are included specifically for MBMS. In future releases the following should be considered. As MBMS services may be provided only in certain frequency layers, it may be beneficial/necessary to control inter-frequency/RAT mobility depending on whether the UE receives a particular MBMS service or not. For MBMS scenarios only, UE based service dependent cell reselection might be considered acceptable. This aspect also depends on the UE capability for simultaneous reception of MBMS and unicast.


While the issues mentioned above drive E-UTRAN towards “aggressive” mobility control, the limiting factors also have to be considered:

UE battery saving: The mobility solution should not consume excessive UE battery, e.g., due to measurements, measurement reporting, broadcast signalling reception, or TA update signalling.
Network signalling/processing load: The mobility solution should not cause excessive network signalling/processing load. This includes over-the-air signalling, S1/X2 signalling, and processing load at network nodes. Unnecessary handovers and cell reselections should be avoided, and PCH and broadcast signalling, as well as dedicated signallings, should be limited.

U-plane interruption and data loss: U-plane interruption and data loss caused by the mobility solution should be limited.

OAM complexity: The mobility solution should not demand excessive efforts in operating/maintaining a network. For example, when a new eNB is added or an existing eNB fails, the mobility solution should not incur excessive efforts to set up or modify the parameters.

More details available in Annex E of 3GPP TS 36.300

Tuesday, March 2, 2010

Commercial Mobile Alert System (CMAS) in Release-9

I have blogged about Public Warning System and covered CMAS as part of that earlier.

The following is an extract from 3G Americas white paper, "3GPP Mobile Broadband Innovation Path to 4G: Release 9, Release 10 and Beyond: HSPA+, SAE/LTE and LTE-Advanced,":

In response to the Warning, Alert, and Response Network (WARN) Act passed by Congress in 2006, the Federal Communications Commission (FCC) established the Commercial Mobile Alert Service (CMAS) to allow wireless service providers who choose to participate, to send emergency alerts as text messages to their users who have CMAS capable handsets.

The FCC established a Commercial Mobile Service Alert Advisory Committee (CMSAAC) for the development of a set of recommendations for the support of CMAS. The CMSAAC recommendations were included as the CMAS Architecture and Requirements document in the FCC Notice of Proposed Rule Making (NPRM) which was issued in December 2007. In 2008, the FCC issued three separate Report and Order documents detailing rules (47 Code of Federal Regulations [CFR] Part 10) for CMAS. The FCC CMAS First Report and Order specifies the rules and architecture for CMAS. The FCC CMAS Second Report and Order establishes CMAS testing requirements and describes the optional capability for Noncommercial Educational (NCE) and public broadcast television stations distribute geo-targeted CMAS alerts. The FCC CMAS Third Report and Order defined the CMAS timeline, subscriber notification requirements for CMSPs, procedures for CMSP participation elections and the rules for subscriber opt-out. The FCC also issued a CMAS Reconsideration and Erratum document.

The CMAS network will allow the
Federal Emergency Management Agency (FEMA), to accept and aggregate alerts from the President of the United States, the National Weather Service (NWS), and state and local emergency operations centers, and then send the alerts over a secure interface to participating commercial mobile service providers (CMSPs). These participating CMSPs will then distribute the alerts to their users. between the issuance of the second and third Report & Order documents.

As defined in the FCC CMAS Third Report and Order, CMSPs that voluntarily choose to participate in CMAS must begin an 18 month period of development, testing and deployment of the CMAS no later than 10 months from the date that the Government Interface Design specifications available. On December 7, 2009, the CMAS timeline of the FCC CMAS Third Report and Order was initiated
with the announcement by FEMA and the FCC that the Joint ATIS/TIA CMAS Federal Alert GW to CMSP GW Interface Specification (J-STD-101) has been adopted as the Government Interface Design specification referenced in the FCC CMAS Third Report and Order.

Participating CMSPs must be able to target alerts to individual counties and ensure that alerts reach customers roaming outside a provider’s service area. Participating CMSPs must also transmit alerts with a dedicated vibration cadence and audio attention signal. Emergency alerts will not interrupt calls in progress. CMAS supports only English text-based alert messages with a maximum displayable message size of 90 English characters.


For purposes of CMAS, emergency alerts will be classified in one of three categories:

1. Presidential Alerts. Any alert message issued by the President for local, regional, or national emergencies and are the highest priority CMAS alert

2. Imminent Threat Alerts. Notification of emergency conditions, such as hurricanes or tornadoes, where there is an imminent threat to life or property and some immediate responsive action should be taken

3. Child Abduction Emergency/AMBER Alerts. Alerts related to missing or endangered children due to an abduction or runaway situation

The subscribers of participating CMSPs may opt out of receiving Imminent Threat and Child Abduction/AMBER alerts, but cannot opt out from Presidential Alerts.

The following figure shows the CMAS Reference Architecture as defined in the FCC CMAS First Report and Order:


Reference Point C is the secure interface between the Federal Alert GW and the Commercial Mobile Service Provider (CMSP) GW. The Reference Point C interface supports delivery of new, updated or canceled wireless alert messages, and supports periodic testing of the interface. This interface is defined in the
J-STD-101, the Joint ATIS/TIA CMAS Federal Alert GW to CMSP GW Interface Specification.

Federal Government entity (i.e. FEMA) responsible for the administration of the Federal Alert GW. FEMA will perform the function of aggregating all state, local, and federal alerts and will provide one logical interface to each CMSP who elects to support CMAS alerts.

For GSM and UMTS systems, wireless alert messages that are received by CMSP GWs will be transmitted to targeted coverage areas using GSM-UMTS Cell Broadcast Service (CBS). The CMAS functionality does not require modifications to the 3GPP-defined Cell Broadcast Service.

The ATIS WTSC-G3GSN Subcommittee is developing the CMAS via GSM-UMTS Cell Broadcast Service Specification. The purpose of this standard is to describe the use of the GSM-UMTS Cell Broadcast Service for the broadcast of CMAS messages. The standard includes the mapping of CMAS application level messages to the Cell Broadcast Service message structure.

The ATIS WTSC-G3GSN Subcommittee is developing the Cell Broadcast Entity (CBE) to Cell Broadcast Center (CBC) Interface Specification. The purpose of this standard is to define a standard XML based interface to the Cell Broadcast Center (CBC). The CMSP Alert GW will utilize this interface to provide the CMAS Alert message information to the CBC for broadcast via CBS.

The ATIS WTSC-G3GSN Subcommittee has developed the Implementation Guidelines and Best Practices for GSM/UMTS Cell Broadcast Service Specification and this specification was approved in October 2009. The purpose of this specification is to describe implementation guidelines and best practices related to GSM/UMTS Cell Broadcast Service regardless of the application using CBS. This specification is not intended to describe an end-to-end Cell Broadcast architecture, but includes clarifications to the existing 3GPP CBS standards as well as “best practices” for implementation of the 3GPP standards. CMAS is an example of an application that uses CBS.

J-STD-100, Joint ATIS/TIA CMAS Mobile Device Behavior Specification, defines the common set of requirements for GSM, UMTS, and CDMA based mobile devices behavior whenever a CMAS alert message is received and processed. A common set of requirements will allow for a consistent user experience regardless of the associated wireless technology of the mobile device. Additionally, this common set of requirements will allow the various local, state, and Federal level government agencies to develop subscriber CMAS educational information that is independent of the wireless technology.

CMAS VIA LTE/EPS

In order to comply with FCC requirements for CMAS, CMSPs have a need for standards development to support CMAS over LTE/EPS as it relates to the network-user interface generally described as the “E-Interface” in the CMAS Reference Architecture. The intent of ATIS WTSC-G3GSN is to build upon LTE text broadcast capabilities currently being specified by 3GPP for the Public Warning System (PWS).

3GPP STANDARDS

3GPP TS 22.268. Public Warning System (PWS) Requirements, covers the core requirements for the PWS and covers additional subsystem requirements for the Earthquake and Tsunami Warning System (ETWS) and for CMAS. TS 22.268 specifies general requirements for the broadcast of Warning Notifications to broadcast to a Notification Area that is based on the geographical information as specified by the Warning Notification Provider. This specification also defines specific CMAS requirements based on the three Reports & Orders issued to date by the FCC.

3GPP TS 23.401. GPRS enhancements for E-UTRAN access, specifies the Warning System Architecture for 3GPP accesses and the reference point between the Cell Broadcast Center (CBC) and Mobility Management Entity (MME) for warning message delivery and control functions. This TS identifies the MME functions for warning message transfer (including selection of appropriate eNodeB), and provides Stage 2 information flows for warning message delivery and warning message cancel. The architecture and warning message delivery and control functions support CMAS.

3GPP TS 29.168. Cell Broadcast Center interfaces with the EPC – Stage 3, specifies the procedures and application protocol between the Cell Broadcast center and the MME for Warning Message Transmission, including the messages, information elements and procedures needed to support CMAS.

3GPP TS 36.300. E-UTRA and E-UTRAN – Overall description – Stage 2, specifies the signaling procedures for the transfer of warning messages from the MME to the eNodeB. The signaling procedures support CMAS operations.

3GPP TS 36.331. E-UTRA Radio Resource Control (RRC) – Protocol specification, specifies the radio resource control protocol for UE-to-E-UTRAN radio interface and describes CMAS notification and warning message transfer.

3GPP TS 36.413. E-UTRAN – S1 Application Protocol (S1AP), specifies the E-UTRAN radio network layer signaling protocol between the MME and eNodeB, and describes the warning message transfer needed for CMAS.

3GPP participants are working to complete these specifications and other UE procedures for supporting PWS and CMAS.

ATIS WTSC-G3GSN will develop a Standard for a CMAS via LTE Broadcast Capability Specification. This Standard will map the CMAS application level messages to the LTE warning message transfer protocol (i.e. for CMAS).

This ATIS WTSC-G3GSN effort has an anticipated completion date of December 31, 2010. This takes into account the time needed for completion of the ongoing 3GPP standards development on warning message broadcast for LTE.

ATIS WTSC G3GSN and TIA TR45.8 Subcommittees in conjunction with FEMA will also be jointly developing a testing certification specification for the Reference Point C interface between the Federal Alert GW and the CMSP GW based upon the requirements defined in J-STD-101. This specification has an anticipated completion date of December 31, 2010.

Monday, February 15, 2010

Self Organizing Networks and Enhancements

I have blogged about SON earlier here and here. The following is an update from the 3G Americas Whitepaper on Mobile Broadband:

SON concepts are included in the LTE (E-UTRAN) standards starting from the first release of the technology (Rel-8) and expand in scope with subsequent releases. A key goal of 3GPP standardization is the support of SON features in multi-vendor network environments. 3GPP has defined a set of LTE SON use cases and associated SON functions. The standardized SON features effectively track the expected LTE network evolution stages as a function of time. With the first commercial networks expected to launch in 2010, the initial focus of Rel-8 has been functionality associated with initial equipment installation and integration.

The scope of the first release of SON (Rel-8) includes the following 3GPP functions, covering different aspects of the eNodeB self-configuration use case:
• Automatic Inventory
• Automatic Software Download
• Automatic Neighbor Relations
• Automatic PCI Assignment

The next release of SON, as standardized in Rel-9, will provide SON functionality addressing more maturing networks. It includes the following additional use cases:
• Coverage & Capacity Optimization
• Mobility optimization
• RACH optimization
• Load balancing optimization

Other SON-related aspects that are being discussed in the framework of Rel-9 include improvement on the telecom management system to increase energy savings, a new OAM interface to control home eNodeBs, UE reporting functionality to minimize the amount of drive tests, studies on self testing and self-healing functions and minimization of drive testing. It should be clarified that SON-related functionality will continue to expand through the subsequent releases of the LTE standard.

The SON specifications have been built over the existing 3GPP network management architecture, reusing much functionality that existed prior to Rel-8. These management interfaces are being defined in a generic manner to leave room for innovation on different vendor implementations. More information on the SON capabilities in 3GPP can be found in 3G Americas’ December 2009 white paper, The Benefits of SON in LTE.

SON technologies have been introduced in Rel-8/Rel-9 to help decrease the CAPEX and OPEX of the system. LTE-Advanced further enhances the SON with the following features:
  • Coverage and Capacity Optimization. Coverage and Capacity Optimization techniques are currently under study in 3GPP and will provide continuous coverage and optimal capacity of the network. The performance of the network can be obtained via key measurement data and adjustments can then be made to improve the network performance. For instance, call drop rates will give an initial indication of the areas within the network that have insufficient coverage and traffic counters can be used to identify capacity problems. Based on these measurements, the network can optimize the performance by trading off capacity and coverage.
  • Mobility Robustness Optimization. Mobility Robustness Optimization aims at reducing the number of hand over related radio link failures by optimally setting the hand over parameters. A secondary objective is to avoid the ping-pong effect or prolonged connection to a non-optimal cell.
  • Mobility Load Balancing. Related to Mobility Robustness is Mobility Load Balancing, which aims to optimize the cell reselection and handover parameters to deal with unequal traffic loads. The goal of the study is to achieve this while minimizing the number of handovers and redirections needed to achieve the load balancing.
  • RACH Optimization. To improve the access to the system, RACH Optimization has been proposed to optimize the system parameters based upon monitoring the network conditions, such as RACH load and the uplink interference. The goal is to minimize the access delays for all the UEs in the system and the RACH load.

In addition to the enhanced SON technologies described above, minimization of manual drive testing functionality is also currently under examination in 3GPP to enhance and minimize the effort for optimization of the LTE-Advance network. The main goal is to automate the collection of UE measurement data. In so doing, it will minimize the need for operators to rely on manual drive tests to optimize the network. In general, a UE that is experiencing issues, such as lack of coverage, traffic that is unevenly distributed or low user throughput, will automatically feed back measurement data to the network which may be used by the network as a foundation for network optimization.

SON related 3GPP references can be found on Martin Sauter's blog here.

Friday, February 12, 2010

A quick Introduction to M2M Communications

Machine-to-Machine (M2M) communications is a healthy sector that' s expanding rapidly and generating significant revenues for mobile network operators (MNOs). Devices outnumber subscribers by an order of magnitude, but the term doesn' t do justice to the concept and the market it represents.

The following is from 3G Americas report on 3GPP standards and their evolution to 4G:

By leveraging connectivity, Machine-to-Machine (M2M) communication would enable machines to communicate directly with one another. In so doing, M2M communication has the potential to radically change the world around us and the way that we interact with machines.

In Rel-10, 3GPP is in the process of establishing requirements for 3GPP network system improvements that support Machine-Type Communications (MTC). The objective of this study is to identify 3GPP network enhancements required to support a large number of MTC devices in the network and to provide necessary network enablers for MTC communication service. Specifically, transport services for MTC as provided by the 3GPP system and the related optimizations are being considered as well as aspects needed to ensure that MTC devices and/or MTC servers and/or MTC applications do not cause network congestion or system overload. It is also important to enable network operators to offer MTC services at a low cost level, to match the expectations of mass market machine-type services and applications.

The 3GPP study on M2M communications has shown potential for M2M services beyond the current "premium M2M market segment." The example of applications for mass M2M services include machine type communications in smart power grid, smart metering, consumer products, health care, and so forth. The current mobile networks are optimally designed for Human-to-Human communications, but are less optimal for M2M applications.


A study item on M2M communications (3GPP TR 22.868) was completed in 2007; however, no subsequent normative specification has been published. For Rel-10 and beyond, 3GPP intends to take the results on network improvements from the study item forward into a specification phase and address the architectural impacts and security aspects to support MTC scenarios and applications. As such, 3GPP has defined a work item on Network Improvements for Machine-Type Communication (NIMTC). The following goals and objectives are described in the work item:

The goal of this work item is to:
• Provide network operators with lower operational costs when offering machine-type communication services
• Reduce the impact and effort of handling large machine-type communication groups
• Optimize network operations to minimize impact on device battery power usage
• Stimulate new machine-type communication applications by enabling operators to offer services tailored to machine-type communication requirements

The objectives of this work item include:
• Identify and specify general requirements for machine-type communications
• Identify service aspects where network improvements (compared to the current H2H oriented services) are needed to cater for the specific nature of machine-type communications
• Specify machine-type communication requirements for these service aspects where network improvements are needed for machine-type communication
• Address system architecture impacts to support machine-type communication scenarios and applications

A RAN study item to investigate the air interface enhancements for the benefit of M2M communication has also been recently approved. The study will be initiated in early 2010.

Further Reading:

Wednesday, February 10, 2010

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:

Sunday, February 7, 2010

3G Americas Publishes New Report on Technology choices for Mobile Broadband

3G Americas, a wireless industry trade association representing the GSM family of technologies including LTE, announced that it has published its highly anticipated resource report on 3rd Generation Partnership Project (3GPP) standards and their evolution to IMT-Advanced, or 4G. The white paper, 3GPP Mobile Broadband Innovation Path to 4G: Release 9, Release 10 and Beyond: HSPA+, SAE/LTE and LTE-Advanced, provides in-depth examination of 3GPP technology standards from a technical, business and applications standpoint.

“The 3GPP technology standards deliver mobile connectivity to more than 4 billion users worldwide today and have been developed to continue evolving to higher levels of performance with mobile broadband innovation,” said Chris Pearson, president of 3G Americas. “GSM operators can choose to evolve their networks in ways that best suit their assets and business environments with benefits that offer flexibility, scalability and economic advantages, whether they choose HSPA+ or LTE.”



UMTS-HSPA is the world’s leading 3G technology and is the preferred choice for the majority of wireless operators and subscribers today and into the future. The global demand for wireless data services continues to drive the rapid growth of HSPA technology with 303 commercial HSPA networks and over 454 million UMTS-HSPA subscriptions reported at the end of 2009 by Informa Telecoms & Media. Informa has further projected that by year-end 2012, worldwide subscriptions to UMTS-HSPA will reach nearly 1.4 billion; by year-end 2013, global UMTS-HSPA subscriptions are expected to exceed 2 billion, rising to 2.8 billion by the end of 2014. GSM-UMTS-HSPA subscriptions provide the foundation for future evolutions to 3GPP Release 9, Release 10 and beyond with HSPA+, LTE and LTE-Advanced.

“Wireless data consumption is increasing faster now than ever before,” said Adrian Scrase, 3GPP Head of Mobile Competence Center. “Smartphone usage is experiencing higher volumes and the superior user experience offered by such devices is resulting in quickly rising demand and escalating use of wireless data applications. This is consequently driving the need for continued innovations that are supported by the efficient and successful 3GPP technology path.”


3GPP Mobile Broadband Innovation Path to 4G: Release 9, Release 10 and Beyond: HSPA+, SAE/LTE and LTE-Advanced, is a comprehensive resource intended to assist members of the wireless industry as well as interested members of the general public in understanding details of the work in 3GPP on Release 9 and Release 10. In addition, the report further describes the features of Release 8 that were closed in March 2009.

Release 9, which is targeted for completion by March 2010, will provide increased feature functionality and performance enhancements to both HSPA and LTE. The report reviews additional multi-carrier and MIMO options for HSPA and features and enhancements to support emergency services, location services and broadcast services for LTE. Other Release 9 enhancements include those to support Home NodeB/eNodeB (i.e. femtocells), Self-Organizing/Self-Optimizing Networks (SON) and the evolution of the IP Multimedia Subsystem (IMS) architecture.

LTE will serve to unify the fixed and mobile broadband worlds. As an all IP-based technology, LTE will allow expansion of the Internet experience on mobile devices and deliver multimedia content to the screen of choice. The vast majority of leading operators, device and infrastructure manufacturers support LTE as the mobile broadband technology of the future and, according to Informa Telecoms & Media, 130 global operators have announced trials or intentions to evolve their networks to LTE. Two commercial networks have already been launched in Norway and Sweden by TeliaSonera in 2009 and as many as 20 will be launched in 2010.

“All roads lead to LTE – for GSM, CDMA, newly licensed and potentially even WiMAX mobile operators,” Pearson added. “The appeal of the 3GPP technology roadmap is no longer suited for only GSM operators.”

While work for Release 9 is nearing completion, significant progress has already been made in 3GPP on work for Release 10, which includes LTE-Advanced. In fact, 3GPP already submitted a proposal in October 2009 based on LTE-Advanced for the IMT-Advanced evaluation and certification process led by the International Telecommunication Union (ITU). The ITU has defined requirements that will officially define and certify technologies as IMT-Advanced, or 4G, and is expected to evaluate submitted proposals by standards organizations for potential certification in the 2010 timeframe; certified 4G/IMT-Advanced technology specifications are projected to be published by early 2011.

As part of Release 10, some of the key LTE-Advanced technology enhancements include carrier aggregation, multi-antenna enhancements and relays. Assuming LTE-Advanced is certified to be IMT-Advanced compliant, 3GPP targets completion of the Release 10 specification by year-end 2010.

“The white paper by 3G Americas provides an excellent overview of the work by 3GPP in determining the standards on the path to 4G,” Scrase said.

The popular white paper, 3GPP Mobile Broadband Innovation Path to 4G: Release 9, Release 10 and Beyond: HSPA+, SAE/LTE and LTE-Advanced, was written collaboratively by members of 3G Americas and is available for free download here.

Friday, January 29, 2010

HSPA+ rollout updates, Jan 2010

It has been predicted that the growth of HSPA+ broadband across Europe is set to soar with the total number of subscribers set to nearly double across Europe in 2011.

A new report has predicted that by 2011 the growth of HSPA+ broadband across key European markets will soar, and could almost double compared to 2009. The number of subscribers is set to soar from twenty two million in 2009 to around forty three million in 2011. The report was released by CCS Insight.

According to the report HSPA+ broadband will be a major factor in seeing growth of one hundred percent in the to five major European markets. The report goes on to state that the European mobile broadband market will enjoy seeing both subscriber and revenue numbers double by 2011. Revenues are set to increase from around six billion Euros in 2009 to around eleven billion Euros in 2011.

Michael O’Hara, chief marketing officer at the GSMA, said: “It is clear from this report that with the right network investment, European mobile network operators will see significant growth in mobile broadband adoption in the next two years. HSPA technology will drive this rapid uptake across Europe as mobile operators and their customers continue to benefit from its expanding, vibrant and competitive ecosystem.”


HSPA+ was generally the most efficient way of upgrading use of bandwidth already in use and was likely to dominate in the short term at least, with an estimated 1.4 billion subscribers worldwide by 2013, around ten times the estimated take-up of LTE.

HSPA+ release 7, which became available last year, uses MIMO technology like that in 11n Wifi to help take the peak downlink throughput to 28Mbps, with 11Mbps on the uplink. Release 8, for which chipsets will become available this year, aggregates two carrier signals to bring peak data rates to 42Mbps on the downlink.

Release 9 will put two MIMO streams on each of two 5MHz carriers, aggregated to produce a 10MHz data pipe delivering 84Mbps on the downlink; the uplink uses simple aggregation to 23Mbps. A projected Release 10 would bring the peak downlink speed to 168Mbps, though this would require 20MHz carriers only available in the 2.5GHz and 2.6GHz bands.

Novatel Wireless, a developer of wireless data cards and other devices, said that it has added support for dual-carrier HSPA+ networks. The firm said it is using Qualcomm's MDM8220 chipset for the support, and will launch commercial devices in the second half of 2010 based on the chipset. Novatel said the new support will add more advanced data capability and other features to its offerings. Dual Carrier HSPA+ networks are expected to provide higher throughput to wireless data devices, and also helps address better service for cell phone users.

The new modem can receive data at up to 42M bps (bits per second) in compatible 3G networks. To increase the theoretical maximum download speed of the modem from 21M bps to 42M bps, Novatel uses two carrier frequencies instead of the usual one, a technique called dual-carrier. But it will only deliver the higher speed on networks that also support the technique.

Users can expect peak speeds at up to 30M bps, according to Hans Beijner, marketing manager for radio products at Ericsson.Leif-Olof Wallin, research vice president at Gartner, is a more pessimistic, saying increased traffic on the networks could negatively impact speeds. "I think it will be difficult to get above 20M bps," he said.

Sixty-six operators have said they plan to use HSPA Evolution, and so far 37 networks have been commercially launched, according to statistics from the Global Mobile Suppliers Association (GSA).

However, the version of HSPA Evolution that supports 42M bps is still very much in its infancy. Last week, mobile operator 3 Scandinavia announced plans to launch services when modems become available. In December, representatives from Vodafone and the Australian operator Telstra visited Ericsson to Stockholm to view a demonstration, but neither operator has so far announced plans to launch commercial services.

Ericsson and 3 Scandinavia have unveiled plans to roll-out a worlds-first 84Mbps HSPA+ wireless network. The initial rollout will cover Denmark and four Swedish cities. HSPA+ networks that currently operate in Canada, for example, offer speeds of up to 21Mbps depending on conditions. In the United States, T-Mobile recently announced a similar planned network.

Real-world tests of the 21Mbps networks show the services achieving around 7Mbps speed. If a similar performance could be applied to the new Ericsson/3 network, it could result in speeds of roughly 28Mbps at realistic distances and network load.

and 3 will also deploy 900MHz 3G networks in Sweden in a bid to boost coverage in remote areas, as existing higher frequency networks have left some users with poor performance.
The high-speed services will hit Denmark and areas of Sweden this winter if all goes to plan.

China Unicom is putting the finishing touch on the tests on its HSPA+ networks in Guangzhou, Shenzhen, and Zhuhai, which were kicked off in October 2009 by partnering with its three major suppliers Huawei Technologies, ZTE, and Ericsson.

HSPA+ is the next generation technology for China Unicom's WCDMA 3G service. HSPA+, also known as Evolved High-Speed Packet Access, is a wireless broadband standard defined in 3GPP release 7. The HSPA+ network claims with a transmission speed of 21Mbps, 1.5 times faster than its current 3G network.

The outdoor average speed of the networks built up by Ericsson and Huawei reach up to 16.5Mbps and 18.5Mbps on the downlink, 50% higher than that of the existing HSPA network. That means you can download a song within two or three seconds.

Cell C, South Africa, has signed a US$378m deal with the Chinese telecom equipment provider ZTE Corporation. Cell C would ever lead the industry as far as network infrastructure is concerned but it is a fact that Cell C will be the first South African operator to roll out HSPA+ technologies incorporating download speeds of up to 21Mbit/s – three times faster than anything currently available.

According to Cell C an important factor in the decision to appoint ZTE is its ability to offer 4G services using Cell C’s 900MHz frequency band which offers wider and deeper coverage than existing 2100 MHz networks, enabling cost effective deployment to rural as well as metropolitan areas.

Tuesday, January 12, 2010

Takehiro Nakamura on LTE Radio Aspects


In summary:

Release 8 - Minor change requests to it based on March 2009 freeze;
Release 9 - an enhanced version of Release 8 and additional features;
Release 10 (LTE-Advanced) - proposed as an IMT-Advanced and is expected to be approved by December 2010; major differences between LTE and LTE-Advanced


Tuesday, December 15, 2009

3G Americas Publishes New Report on LTE SON Self-Optimizing / Self-Organizing Networks

I have blogged about SON networks before. Now has published an educational report titled, The Benefits of SON in LTE, to increase understanding of the improvements in network management that have been developed through 3GPP standards – Release 8, Release 9 and beyond.

Self-Optimizing and Self-Organizing Networks, called SON, can significantly improve network management performance, helping operators and their customers. The 3GPP standards organization is standardizing self-optimizing and self-organizing capabilities for LTE. LTE SON will leverage network intelligence, automation and network management features in order to automate the configuration and optimization of wireless networks, thereby increasing efficiency as well as improving network performance and flexibility.

“The time is right for SON as wireless carriers’ networks have increasing mobile broadband demand and a high level of complexity,” said Chris Pearson, President of 3G Americas. “The good news is that smartphones, netbooks and emerging classes of mobile devices are driving significant growth of wireless data usage. However, operators will need to continue to significantly improve network management capabilities to efficiently meet the demands of this new mobile broadband world.”

The Benefits of SON in LTE describes the motivation behind SON and provides an overview of key SON features contained in Releases 8 and 9 that will serve as a solution for network operators. Motivations for operators to deploy SON include:

  • Wireless service providers must now support a growing number of higher-bandwidth data applications and services on their networks
  • Operators must drive down the delivery cost per bit
  • Radio access network complexity will increase through additions of small cells such as femtocells, picocells as well as WiFi access points to increase and improve coverage and capacity

These and other trends portend ever-increasing demands upon service providers in the areas of network performance and operations.

Initial solutions are offered in the 3GPP Release 8 specifications, which were completed in March 2009, and include SON features such as automatic inventory, software download, neighbor relations and PCI assignment that would be built over 3GPP network management architecture. LTE SON features begin with 3GPP Release 8 and evolve with the expected LTE network evolution stages. In 3GPP Release 9, other SON features are addressed, such as the optimization of coverage and capacity, mobility, RACH, load balancing and support of SON features in multi-vendor network environments.

Other organizations such as the Next Generation Mobile Networks (NGMN) have contributed significantly to the development and standardization of SON at 3GPP.


“Self-optimizing networks are a key part in the future-proofing of network reliability and operational efficiency,” said Dr. Peter Meissner, Operating Officer of the NGMN Alliance. “NGMN established a set of initial requirements and since then has worked with its partners to define the remaining requirements and to drive forward the early adoption in the standardization.”

You can find this whitepaper and many other whitepapers on LTE at the 3G4G Library here.


Tuesday, November 10, 2009

eMBMS: Naughty after 11pm ;)


I have blogged about MBMS in past about how it didn't take off even though it was a promising technology. Now you may probably be aware that eMBMS is part of Release-9. I heard some interest in this feature.

The expectation is that the demand for data drops off later in the night after around 10pm. The operators may start some channels say after 11pm because the network will have lots of spare capacity that could be used for television channels. You could have late night movies, sports channels and adult channels.

An advantage of going eMBMS way would mean that even if you are roaming, you can have pay per view kind of approach as long as the other network is Release-9 compliant.

Interesting idea, not sure if it will take off.

Tuesday, October 6, 2009

Femtocells Standardization in 3GPP

Femtocells have been around since 2007. Before Femtocells, the smallest possible cell was the picocell that was designed to serve a small area, generally a office or a conference room. With Femtocells came the idea of having really small cells that can be used in houses and they were designed to serve just one home. Ofcourse in my past blogs you would have noticed me mentioning about Super Femtos and Femto++ that can cater for more users in a small confined space, typically a small office or a meeting room but as far as the most common definition is concerned they are designed for small confined spaces and are intended to serve less than 10 users simultaneously.

This blog post is based on IEEE paper on "Standardization of Femtocells in 3GPP" that appeared in IEEE Communications Magazine, September 2009 issue. This is not a copy paste article but is based on my understanding of Femtos and the research based on the IEEE paper. This post only focusses on 3GPP based femtocells, i.e., Femtocells that use UMTS HSDPA/HSPA based technology and an introduction to OFDM based LTE femtocells.

The reason attention is being paid to the Femtocells is because as I have blogged in the past, there are some interesting studies that suggest that majority of the calls and data browsing on mobiles originate in the home and the higher the frequency being used, the less its ability to penetrate walls. As a result to take advantage of the latest high speed technologies like HSDPA/HSUPA, it makes sense to have a small cell sitting in the home giving ability to the mobiles to have high speed error free transmission. In addition to this if some of the users that are experiencing poor signal quality are handed over to these femtocells, the overall data rate of the macro cell will increase thereby providing better experience to other users.

Each technology brings its own set of problems and femocells are no exception. There are three important problems that needs to be answered. They are as follows:

Radio interference mitigation and management: Since femtocells would be deployed in adhoc manner by the users and for the cost to be kept down they should require no additional work from the operators point of view, they can create interference with other femtocells and in the worst possible scenario, with the macro cell. It may not be possible initially to configure everything correctly but once operational, it should be possible to adjust the parameters like power, scrambling codes, UARFCN dynamically to minimise the interference.

Regulatory aspects: Since the mobiles work in licensed spectrum bands, it is required that they follow the regulatory laws and operate in a partcular area in a band it is licensed. This is not a problem in Europe where the operators are given bands for the whole country but in places like USA and India where there are physical boundaries within the country for the allocation of spectrum for a particular operator. This brings us to the next important point.

Location detection: This is important from the regulatory aspect to verify that a Femtocell can use a particular band over an area and also useful for emergency case where location information is essential. It is important to make sure that the user does not move the device after initial setup and hence the detection should be made everytime the femto is started and also at regular intervals.

3GPP FEMTOCELLS STANDARDIZATION

Since the femtocells have been available for quite a while now, most of them do not comply to standards and they are proprietary solutions. This means that they are not interoperable and can only work with one particular operator. To combat this and to create economy of scale, it became necessary to standardise femtocells. Standardized interfaces from the core network to femtocell devices can potentially allow system operators to deploy femtocell devices from multiple vendors in a mix-and-match manner. Such interfaces can also allow femtocell devices to connect to gateways made by multiple vendors in the system operator’s core network (e.g., home NodeB gateway [HNB-GW] devices).

In 2008, Femto Forum was formed and it started discussion on the architecture. From 15 different proposals, consensus was reached in May over the Iuh interface as shown below.

There are two main standard development organizations (SDOs) shaping the standard for UMTS-related (UTRAN) femto technology: 3GPP and The Broadband Forum (BBF).
More about 3GPP here. BBF (http://www.broadbandforum.org) was called the DSL Forum until last year. As an SDO to meet the needs of fixed broadband technologies, it has created specifications mainly for DSL-related technologies. It consists of multiple Working Groups. The Broadband Home WG in particular is responsible for the specification of CPE device remote management. The specification is called CPE wide area network (WAN) Management Protocol (CWMP), which is commonly known by its document number, TR-069.

There are several other important organisations for femto technology. The two popular ones are the Femto Forum (www.femtoforum.org) and Next Generation Mobile Network (NGMN).

3GPP has different terminology for Femtocells and components related to that. They are as follows:

Generic term: Femtocell
3GPP Term: home NodeB (HNB)
Definition: The consumer premises equipment (CPE) device that functions as the small-scale nodeB by interfacing to the handset over the standard air interface (Uu) and connecting to the mobile network over the Iuh interface.

Generic term: FAP Gateway (FAP-GW) or Concentrator
3GPP Term: home NodeB gateway (HNB-GW)
Definition: The network element that directly terminates the Iuh interface with the HNB and the existing IuCS and IuPS interface with the CN. It effectively aggregates a large number of HNBs (i.e., Iuh interface) and presents it as a single IuCS/PS interface to the CN.

Generic term: Auto-Configuration Server (ACS)
3GPP Term: home NodeB management system (HMS)
Definition: The network element that terminates TR-069 with the HNB to handle the remote management of a large number of HNBs.

In addition, there is a security gateway (SeGW) that establishes IPsec tunnel to HNB. This ensures that all the Iuh traffic is securely protected from the devices in home to the HNB-GW.
The HNB-GW acts as a concentrator to aggregate a large number of HNBs which are logically represented as a single IuCS/IuPS interface to the CN. In other words, from the CN’s perspective, it appears as if it is connected to a single large radio network controller (RNC). This satisfies a key requirement from 3GPP system operators and many vendors that the femtocell system architecture not require any changes to existing CN systems.

The radio interface between HNB and UE is the standard RRC based air interface but has been modified to incude HNB specific changes like the closed subscriber group (CSG) related information.

Two new protocols were defined to address HNB-specific differences from the existing Iu interface protocol to 3GPP UMTS base stations (chiefly, RANAP at the application layer).

HNB Application Protocol (HNBAP): An application layer protocol that provides HNB-specific control features unique to HNB/femtocell deployment (e.g., registration of the HNB device with the HNBGW).

RANAP User Adaptation (RUA): Provides a lightweight adaptation function to allow RANAP messages and signaling information to be transported directly over Stream Control Transport Protocol (SCTP) rather than Iu, which uses a heavier and more complex protocol stack that is less well suited to femtocells operating over untrusted networks from home users (e.g., transported over DSL or cable modem connections).


Figure above is representation of the protocol stack diagram being used in TS 25.467.

Security for femtocell networks consists of two major parts: femtocell (HNB) device authentication, and encryption/ciphering of bearer and control information across the untrusted Internet connection between the HNB and the HNB-GW (e.g., non-secure commercial Internet service). The 3GPP UMTS femtocell architecture provides solutions to both of these problems. 3GPP was not able to complete the standardization of security aspects in UMTS Release 8; however, the basic aspects of the architecture were agreed on, and were partially driven by broad industry support for a consensus security architecture facilitated in discussions within the Femto Forum. All security specifications will be completed in UMTS Release 9 (targeted for Dec. 2009).

FEMTOCELL MANAGEMENT

Management of femtocells is a very big topic and very important one for the reasons discussed above.

The BBF has created CWMP, also referred to as TR-069. TR-069 defines a generic framework to establish connection between the CPE and the automatic configuration server (ACS) to provide configuration of the CPE. The messages are defined in Simple Object Access Protocol (SOAP) methods based on XML encoding, transported over HTTP/TCP. It is flexible and extensive enough to incorporate various types of CPE devices using various technologies. In fact, although TR-069 was originally created to manage the DSL gateway device, it has been adopted by many other types of devices and technologies.

The fundamental functionalities TR-069 provides are as follows:
• Auto-configuration of the CPE and dynamic service provisioning
• Software/firmware management and upgrade
• Status and performance monitoring
• Diagnostics

The auto-configuration parameters are defined in a data model. Multiple data model specifications exist in the BBF in order to meet the needs of various CPE device types. In fact, the TR-069 data model is a family of documents that has grown over the years in order to meet the needs of supporting new types of CPE devices that emerge in the market. In this respect, femtocell is no exception. However, the two most common and generic data models are:
TR-098: “Internet Gateway Device Data Model for TR-069”
TR-106: “Data Model Template for TR-069-Enabled Devices”

HAND-IN AND FEMTO-TO-FEMTO HANDOVERS

The 3GPP specifications focused on handovers in only one direction initially — from femtocell devices to the macrocellular system (sometimes called handout). A conscious decision was made to exclude handover from the macrocellular system to the femtocell devices (sometimes called macro to femtocell hand-in). This decision was driven by two factors:
• There are a number of technical challenges in supporting hand-in with unmodified mobile devices and core network components.
• The system operator requirements clearly indicate that supporting handout is much more important to end users.
Nonetheless, there is still a strong desire to develop open, interoperable ways to support handin in an efficient and reliable manner, and the second phase of standards in 3GPP is anticipated to support such a capability.

NEXT-G EFFORTS

3GPP Release 8 defines the over-the-air radio signaling that is necessary to support LTE femtocells. However, there are a number of RAN transport and core network architecture, interface, and security aspects that will be addressed as part off 3GPP’s Release 9 work efforts. While it is preliminary as of the publication of this article, it seems highly likely that all necessary RAN transport and core network work efforts for LTE femtocells will be completed in 3GPP Release 9 (targeted for completion by the end of 2009).

3GPP STANDARDS ON FEMTOCELLS

[1] 3GPP TS 25.331: RRC
[2] 3GPP TS 25.367: Mobility Procedures for Home NodeB (HNB); Overall Description; Sage 2
[3] 3GPP TS 25.467: UTRAN Architecture for 3G Home NodeB; Stage 2
[4] 3GPP TS 25.469: UTRAN Iuh Interface Home NodeB (HNB) Application Part (HNBAP) Signaling
[5] 3GPP TS 25.468: UTRAN Iuh Interface RANAP User Adaption (RUA) Signaling
[6] 3GPP TR 3.020: Home (e)NodeB; Network Aspects -(http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/R3_internal_TRs/R3.020_Home_eNodeB/)
[7] 3GPP TS 25.104: Base Station (BS) Radio Transmission and Reception (FDD)
[8] 3GPP TS 25.141: Base Station (BS) Conformance Testing (FDD)
[9] 3GPP TR 25.967: FDD Home NodeB RF Requirements
[10] 3GPP TS 22.011: Service Accessibility
[11] 3GPP TS 22.220: Service Requirements for Home NodeB (HNB) and Home eNodeB (HeNB)
[12] 3GPP TR 23.830: Architecture Aspects of Home NodeB and Home eNodeB
[13] 3GPP TR 23.832: IMS Aspects of Architecture for Home NodeB; Stage 2
[14] 3GPP TS 36.300: E-UTRA and E-UTRAN; Overall Description; Stage 2
[15] 3GPP TR 33.820: Security of H(e)NB 3GPP TR 32.821: Telecommunication Management; Study of Self-Organizing Networks (SON) Related OAM Interfaces for Home NodeB
[16] 3GPP TS 32.581: Telecommunications Management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and Requirements for Type 1 Interface HNB to HNB Management System (HMS)
[17] 3GPP TS 32.582: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Information Model for Type 1 Interface HNB to HNB Management System (HMS)
[18] 3GPP TS 32.583: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HNB to HNB Management System (HMS)
[19] 3GPP TS 32.584: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); XML Definitions for Type 1 Interface HNB to HNB Management System (HMS)
I would strongly recommend reading [3] and [6] for anyone who wants to gain better understanding of how Femtocells work.

Thursday, August 6, 2009

Multi-Standards Radio Base Station (MSR-BS) in 3GPP Release 9

I wrote about Future Mobile Terminals earlier which will probably be Multiservice, Multinetwork and Multimode. A similar approach would be needed for the network side. 3GPP is working on Release-9 feature of Multi-Standard Radio (MSR-BS). The 3GPP Spec 37.900 is not yet available but a draft should be available soon.

Research and Markets have already released a report arguing about the benefits of MSR-BS. Last year Ericsson released the RBS 6000 series products that has MSR support. Huawei and Nokia Siemens Networks are also working on similar products under different guises. Martin has blogged about this topic as well earlier in case you want to refer to.

According to Research and Markets report the terms used for this technology is Multi-Standard Radio Base Station (MSR-BTS/MSR-BS), Multi-Mode Radio Base Station (MMR-BTS/MMR-BS) and Multi-Radio Access Technology (Multi-RAT). The name in standards usually is MSR-BS.

So what is MSR-BS? The 3GPP definition is: Base Station characterized by the ability of its receiver and transmitter to process two or more carriers in common active RF components simultaneously in a declared RF bandwidth, where at least one carrier is of a different RAT than the other carrier(s).

In very simple terms, a single Base Station will be able to simultaneously transmit different radio access technologies from a single unit. So a unit may be for example transmitting GSM, WCDMA 2100 and LTE 2600 simultaneously.

The number of technologies supported by a BTS will be an implementation choice. With technology maturing it wont be surprising to have upto 4-5 different technologies in a MSR-BS in the next five years.

The advantage the mobile operator will have will not only be monetary but there will be possibility of space saving. But as the old english proverb says, they will be "putting their eggs in a single basket". If one unit stops working then the coverage in the area goes down. There may not be an option to fallback on different technology.

The way this MSR-BS are implemented will be definitely based on Software Defined Radios (SDR). The advantage with SDR will be that in different parts there is a slight frequency variation for different technologies like GSM-850 is specific to USA whereas the rest of the world uses GSM-900. These small variations will easily be customisable with these MSR-BS and optimisations wont be too far off.

Different Band Categories have been defined for different scenarios. For example Band Category 1 involves deplyment where GSM wont be present. Only LTE and WCDMA is present there. Band Category 2 involves frequency bands where GSM, EDGE, WCDMA and LTE may be present. Band Category 3 is designed with TDD and TD-SCDMA in mind.

More information as and when available

Wednesday, July 22, 2009

On Self Organising Network Concept in Rel-8 and Rel-9

Self-Organising Networks popularly known as SON are feature of 3GPP Release 8 and Release 9. SON has been around for quite some time now and is not a new concept. Its not an evolutionary technology, rather a revolutionary technology. The first time I heard of SON was in relation to Femtocells. Remember, a Femtocell has to start in an unfamiliar environment, learn about its surrounding and then adapt to the environment.

Other terms often used to mean SON is 'Plug-n-play' or 'PnP', 'Zero Touch', 'Auto Configured', 'Self Managed...', etc. SON is a very useful feature that will allow for the automation of several tasks lowering the OPEX costs. Examples include plug and play or a cell in between existing ones, neighbour recognition and (re-)configuration, optimizations, etc. Properly implemented, it could kill off drive-testing.

In simplest of terms, SON can be explained with the basic diagram above. A new cell created in an existing environment possibly due to too many existing resources being in use or too many users in an area during a particular time (football match for example) and this cell has to look at the surrounding and adjust its conditions. The other existing cells also have to adjust tehmselves with the change in surroundings.

According to recent analysis in NEC Whitepaper on SON (available here), about 17 % of wireless operator’s CAPEX is spent on engineering and installation services. SON’s self-configuring functions are expected to eliminate many on-site operations for the basic settings and subsequent updating of network equipments, and thus reduce CAPEX.

It is also known that about 24 % of a typical wireless operator’s revenue goes to network OPEX, which are the cost of network operation and maintenance, training and support, power, transmission, and site rental. SON’s self-optimizing functions will reduce a workload for site survey and analysis of network performances, and thus reduce OPEX. Moreover, SON’s energy-saving functions reduce the costs of power consumed by the equipment.

Self-optimizing and self-healing architectures improve user perceived qualities by mitigating quality degradations that result from inaccuracies of the planning or equipment faults as early as possible and by optimizing the network parameters under interference and overload conditions.
Nomor research has got an excellent paper on SON with regards to LTE. The full paper is available here. Here is an extract from that paper.

The main functionality of SON includes: self-configuration, self-optimization and self-healing.

Self-configuration process is defined as the process where newly deployed nodes (eNBs) are configured by automatic installation procedures to get the necessary basic configuration for system operation

Self-optimization process is defined as the process where UE & eNB measurements and performance measurements are used to autotune the network

Self-healing function aims at automatic detection and localization of most of the failures and applies self-healing mechanisms to solve several failure classes, such as reducing the output power in case of temperature failure or automatic fallback to previous software version.

A Self-configuration Subsystem will be created in OAM to be responsible for the selfconfiguration of eNB. For self-optimisation functions, they can be located in OAM or eNB or both of them. So according to the location of optimisation algorithms, SON can be divided into three classes: Centralised SON, Distributed SON and Hybrid SON.


The paper also lists the Use cases and the problems ands solutions for the use cases.

NEC whitepaper on SON is quite recent and it lists the recent standards status:

3GPP has introduced SON items in its standardization path as required features for LTE deployments. Rel. 8 includes the first specifications on requirements, integration with operators’ processes, and identification of main use cases. Rel. 9 is expected to define advanced features, which will introduce self-healing and self-optimization capabilities into LTE. The SON related specifications are driven from the SA5 Working Group (WG) – mainly for architectural aspects– and the RAN3 WG – especially for the optimization of radio functions. Also, Rel. 8 defined the grounding documents for SON: “SON Concepts and Requirements” in TS 32.500, and two main use cases– “Self-Establishment of eNodeB” and “Automatic Neighbor Relation” – in TS 32.501, 32.502 and 32.511.