
Cập nhật tình hình thị trường bất động sản, địa ốc hiện nay tại Việt Nam. Tìm hiểu về bất động sản, thị trường nhà đất, bất động sản Việt Nam.Cnlax.com
Monday, May 31, 2010
LTE Femtocell Enhancements for Release-9

Friday, March 26, 2010
E-UTRAN Mobility Drivers and Limitations
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
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

- 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.
Friday, February 12, 2010
A quick Introduction to M2M Communications

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:
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.
- 3GPP TR 22.868: Study on Facilitating Machine to Machine Communication in 3GPP Systems; (http://www.3gpp.org/ftp/Specs/archive/22_series/22.868/)
- 3GPP TR 33.812: Feasibility Study on the Security Aspects of Remote Provisioning and Change of Subscription for M2M Equipment; (http://www.3gpp.org/ftp/Specs/archive/33_series/33.812/)
- 3GPP's initial thoughts on Machine to Machine communication (http://docbox.etsi.org/workshop/2008/2008_06_M2MWORKSHOP/3GPPs_SWETINA_M2MWORKSHOP.pdf)
- M2M Activities in ETSI (http://www.pole-scs.org/index.php?m=6&l=en&x=file.download&h=0&fileid=57063)
- ETSI Workshop on M2M STANDARDIZATION 4th and 5th of June 2008: Agenda (http://docbox.etsi.org/Workshop/2008/2008_06_M2MWORKSHOP/00M2Magenda_FINALVERSION.pdf)
- ETSI Workshop on M2M STANDARDIZATION 4th and 5th of June 2008: Presentations (http://docbox.etsi.org//Workshop/2008/2008_06_M2MWORKSHOP/)
- M2M: the Internet of 50 billion devices, Jan 2010, Win-Win (http://www.huawei.com/publications/view.do?id=6083&cid=11392&pid=10664)
- 5 Myths about M2M (http://www.slideshare.net/blueslice/5-myths-about-m2m-presentation)
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:
- 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/)
Sunday, February 7, 2010
3G Americas Publishes New Report on Technology choices for Mobile Broadband


Friday, January 29, 2010
HSPA+ rollout updates, Jan 2010

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.”
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.
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.
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.
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
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

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 ;)

Tuesday, October 6, 2009
Femtocells Standardization in 3GPP
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.

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).
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:
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:
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:
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
Thursday, August 6, 2009
Multi-Standards Radio Base Station (MSR-BS) in 3GPP Release 9

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.
Wednesday, July 22, 2009
On Self Organising Network Concept in Rel-8 and Rel-9
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.

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.
The paper also lists the Use cases and the problems ands solutions for the use cases.
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.