Jumat, 08 Juli 2011

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.

Call failure caused by equipment problems

Call failure caused by equipment problems
Strictly speaking, equipment problems should be solved before network optimization, but actually a lot of equipment problems are found in optimization.
Typical phenomena
The problems are sudden: the previous network works normally, and the problems happen suddenly.
The problems are universal: after DT test, it can be found that the problems happen in large area.
Analyzing:
Inquire if there is hardware changing recently, like boards replacing or transmission changing and so on; Inquire if there is software changing recently, like the software version updating or parameters adjustment;


If there are software and hardware adjustment, check the adjustment and consider resuming these adjustments, observe if the problem will happen;


If there is no adjustment recently, start single cell checking and judge if there is problem in hardware;
Single cell checking can find the obvious equipment problem, but some secluded problems are hard to find. At this time, boards resetting and replacement can be used to locate the problem.


Solution:
Because the reason is equipment problem, so the solution can not be called as “optimization”, it is just like troubleshooting.
In troubleshooting, TRX, CHM, CCM, and antenna feeder system are the key points we should care for.
Note:
The operation for software and hardware should be very cautious. For commercial network, the operation should be carried out by operator’s engineers after operator’s permission;
All the operation for equipment should be after midnight, if there is problem in operation, everything should be resumed in time.

Call failure caused by poor coverage


Typical case:
MS Rx power is about -100dBm or less;
MS Tx power tends to 23dBm;
The strongest pilot Ec/Io is <-15dB;
After MS sends origination message, it is hard to access successfully, finally it is shown: call failure;
Analyzing:
MS call failure caused by poor coverage is normal phenomenon. In the edge of coverage, MS receive power is very low and usually Rx power is about -100dBm or less, the strongest pilot Ec/Io is -15dB or less; MS Tx power will tend to the maximum 23 dBm.


When MS starts origination in the edge of coverage, the signal transmission between BTS and MS can not be received correctly for the bad air link and the call will be failed.
In addition, even if MS starts origination in good coverage area, it will take some time to access for MS. When MS moves fast to outside or cell (cars or railway stations), MS may have reached outside of the coverage before access completion, this will lead to call failure.


Note:
In CDMA protocol MS maximum Tx power is 23dBm (0.2W). But MS is produced by different manufactures; the real maximum Tx power may exceed 23 dBm in practice.

Optimization solution:
The ultimate way for this kind of problem is add new BTS or repeater in blind coverage area or poor coverage area.
If adding new BTS is not possible, other methods also can be used to improve coverage, like increase antenna height, select large gain antenna, and adjust antenna azimuth and down tilt. But these methods can not solve problems ultimately, and it should be very careful when change these parameters.

Call failure caused by wireless link fading

Call failure caused by wireless link fading
Typical case:
In the beginning of origination, MS forward and reverse signal are normal, but finally the call is failed;
In this period MS received signal fades greatly ( MS is in the corner of street or goes into subway).


Analyzing:
When MS is in the corner of the street or goes into subway, the radio environment will change greatly and signal fade very fast. Usually both forward and reverse link will fade at the same time. If MS starts access at this time, it is very possible to meet access failure for signal losing.
Note:
For the signal losing, MS and BTS sides will transmit again. If the fading time is short, access procedure can be continued; but if the fading time is too long, the retransmitted signal may be lost and the access will be failed.


Solution:
Optimize network topology structure and decrease the area where signal fades greatly.

Call failure caused by forward and reverse imbalance


Typical case:
MS received power and strongest pilot Ec/Io maintain in good state, such as Rx Power>-100dBm, Ec/Io>-15dB;
After MS origination, reverse Tx power is increasing continuously, until 23dBm, but access is failed;
After access failure, MS will stay in previous pilot;
When MS is nearer to BTS, MS call can be successful. Observe Tx_Adj, it is a positive value. (Note: only when MS acquires F-TCH and reverse closed-loop power control starts working, Tx_Adj value will be efficient)


Analyzing:
In the above case, MS Rx power and pilot Ec/Io are all good, and this means the forward link is good. But in MS origination procedure MS is increasing transmitting power until maximum, and this means the reverse link is bad.

That is forward and reverse imbalance. Tx_Adj>0 also means forward is better than reverse.
Because forward is better than reverse, so in the edge of coverage BTS can not receive the signal from MS correctly and call is failed.


Optimization method:
Find the rootstock of imbalance:
Judge if the cell power configuration is too high:
Judge if the pilot gain is too high:
Judge if there is reverse interference;

Call failure caused by resource limitation

Call failure caused by resource limitation
Typical case:

Observe MS received signals in DT test, MS receives BTS ACK message after access, but does not receive channel assignment message, and finally call is failed; In this period MS Rx power is in normal state, there is no large fading;
The above call failure does not often happen, usually in busy hour. The call is normal and seldom meets above problem when traffic is low.

Analyzing:
According to call procedure principle, when BTS receives access request from MS, firstly BTS will send ACK message and then apply for resource, if resource is available, BTS will send channel assignment message to MS.
According to above case description, MS has received BTS ACK message but not received channel assignment messaged.
There are two possible reasons:
1. BTS has sent channel assignment message, but MS does not receive;
2. BTS does not send channel assignment message for resource limitation.


For the first reason, commonly forward link large fading will lead MS can not receive channel assignment message. According to DT test information, if MS received power is normal in call procedure and there is no large fading, this kind of reason can be excluded.


For the second reason, according to DT test, it is very possible. This kind of call failure does not often happen, usually in busy hour. The normal reason is that system resource is not enough in busy hour, so BTS rejects access and does not send channel assignment message.

Note:
There is another reason for the above call failure that is illegal MS. If MS is illegal, it will send power-up registration message after power up. Because it is illegal, registration in MSC will be failed. When this MS starts origination call, MSC will reject to assign resource and MS will not receive channel assignment message; Another good way for above problem is starting signal tracing for the MS in OMC;

The reasons for resource limitation are a lot of kinds.

They are: CE resource limitation, vocoder resource limitation, trunk circuit limitation, forward power resource limitation and so on.


Optimization methods:
Find which kind of resource is not enough and adjust network parameters and topology structure or network expanding.
If the limitation is physical resource limitation, like CE, vocoders, trunk circuit, consider expanding related the resource; If forward power resource is imitated, consider the following methods:
Wireless parameters optimization, check OMC wireless parameters configuration and all the forward power control parameters;
Adjust network topology structure (including feed parameters and cell power), let free cell share the traffic of busy cell;
If the busy cell has repeater, change the repeater to BTS, or change free BTS to be the master BTS of the repeater’
Split cells and increase BTS; Update to dual carriers;

Rabu, 06 Juli 2011

Call failure caused by too narrow MS search window

Call failure caused by too narrow MS search window
Typical case:

In call procedure, MS Rx power is normal, Tx power is normal also;
In call procedure, pilot Ec/Io is too low and can not maintain the requirement for demodulation, finally call is failed;
Use PN Scanner to test pilot, the pilot Ec/Io of PN in active set is normal.


Analyzing:
MS Rx power and Tx power are all normal, use PN Scanner to test pilot: the pilot Ec/Io of the PN in active set is normal, but MS received Ec/Io is too low. This indicates MS can not distinguish some useful multipath signal. Usually it is caused by too narrow search window of MS.
If MS search window is too low, MS can not find strong multipath signal. This will lead the useful signal dropping outside the search window;the Ec/Io will be too low; the unuseful signal dropping outside the search window will become strong interference. If MS can not demodulate forward signal, the call will be failed finally.


Note:
The above case is about MS search window problem. Also, for reverse signal BTS has search window: they are access channel search window and traffic channel search window, if they are too low, the reverse multipath signal will drop outside and call will be failed.


Optimization method:
Check OMC wireless parameters and adjust the search windows.

My Headlines