Interesting Video
Sunday, 18 October 2009
Saturday, 17 October 2009
Vodafone Access Gateway (VAG) femtocell setup
I blogged about ALU and Vodafone Femto earlier. Here is an Interesting Video showing unboxing, setting up and using the Femtocell.
Thursday, 15 October 2009
On Relay Technology in LTE-Advanced and WiMAX standards
I blogged earlier about Relay technology that is part of LTE-Advanced. In the IEEE Communications Magazine, this month there is a complete article on Relay technology. Here is a brief summary from that paper with my own understanding (and words).
We have mentioned about IMT-Advanced and LTE-Advanced before. International Mobile Telecommunications-Advanced is going to be the first 4G technology and as i discussed earlier, there are two main technologies vying for the 4G crown. I am sure both are as good and both will succeed. From 3GPP point of view, the standards will be part of Release-10 and should be ready end 2010 or beginning 2011. The understanding is that IMT-Advanced systems will support peak data rates of 100 Mb/s in high mobility environment (up to 350 km/h) and 1 Gb/s in stationary and pedestrian environments (up to 10 km/h). The transmission bandwidth of IMT-Advanced systems will be scalable and can change from 20 to 100 MHz, with downlink and uplink spectrum efficiencies in the ranges of [1.1, 15 b/s/Hz] and [0.7, 6.75 b/s/Hz], respectively. There will be a minimum requirement on voice over IP (VoIP) capacities in high- and low-mobility environments of around 30 and 50 active users/sector/MHz. The latency for control and user planes should be less than 100 ms and 10 ms, respectively, in unloaded conditions.
As I mentioned last week, the 3GPP candidate for IMT-Advanced is LTE-Advanced. On the IEEE front, 802.16j group published the relay-based multihop techniques for WiMAX and IEEE 802.16m has been submitted for the IMT-Advanced approval last week. The normal 802.16 WiMAX standard has been approved as 3G standard by the ITU.
So what exactly are Relays. Relay transmission can be seen as a kind of collaborative communications, in which a relay station (RS) helps to forward user information from neighboring user equipment (UE)/mobile station (MS) to a local eNode-B (eNB)/base station (BS). In doing this, an RS can effectively extend the signal and service coverage of an eNB and enhance the overall throughput performance of a wireless communication system. The performance of relay transmissions is greatly affected by the collaborative strategy, which includes the selection of relay types and relay partners (i.e., to decide when, how, and with whom to collaborate).
There are two different terminology used for Relay's. First is Type-I and Type-II and other is non-transparency and transparency. Specifically, a Type-I (or non-transparency) RS can help a remote UE unit, which is located far away from an eNB (or a BS), to access the eNB. So a Type-I RS needs to transmit the common reference signal and the control information for the eNB, and its main objective is to extend signal and service coverage. Type-I RSs mainly perform IP packet forwarding in the network layer (layer 3) and can make some contributions to the overall system capacity by enabling communication services and data transmissions for remote UE units. On the other hand, a Type-II (or transparency) RS can help a local UE unit, which is located within the coverage of an eNB (or a BS) and has a direct communication link with the eNB, to improve its service quality and link capacity. So a Type-II RS does not transmit the common reference signal or the control information, and its main objective is to increase the overall system capacity by achieving multipath diversity and transmission gains for local UE units.
Different relay transmission schemes have been proposed to establish two-hop communication between an eNB and a UE unit through an RS. Amplify and Forward — An RS receives the signal from the eNB (or UE) at the first phase. It amplifies this received signal and forwards it to the UE (or eNB) at the second phase. This Amplify and Forward (AF) scheme is very simple and has very short delay, but it also amplifies noise. Selective Decode and Forward — An RS decodes (channel decoding) the received signal from the eNB (UE) at the first phase. If the decoded data is correct using cyclic redundancy check (CRC), the RS will perform channel coding and forward the new signal to the UE (eNB) at the second phase. This DCF scheme can effectively avoid error propagation through the RS, but the processing delay is quite long. Demodulation and Forward — An RS demodulates the received signal from the eNB (UE) and makes a hard decision at the first phase (without decoding the received signal). It modulates and forwards the new signal to the UE (eNB) at the second phase. This Demodulation and Forward (DMF) scheme has the advantages of simple operation and low processing delay, but it cannot avoid error propagation due to the hard decisions made at the symbol level in phase one.
We have mentioned about IMT-Advanced and LTE-Advanced before. International Mobile Telecommunications-Advanced is going to be the first 4G technology and as i discussed earlier, there are two main technologies vying for the 4G crown. I am sure both are as good and both will succeed. From 3GPP point of view, the standards will be part of Release-10 and should be ready end 2010 or beginning 2011. The understanding is that IMT-Advanced systems will support peak data rates of 100 Mb/s in high mobility environment (up to 350 km/h) and 1 Gb/s in stationary and pedestrian environments (up to 10 km/h). The transmission bandwidth of IMT-Advanced systems will be scalable and can change from 20 to 100 MHz, with downlink and uplink spectrum efficiencies in the ranges of [1.1, 15 b/s/Hz] and [0.7, 6.75 b/s/Hz], respectively. There will be a minimum requirement on voice over IP (VoIP) capacities in high- and low-mobility environments of around 30 and 50 active users/sector/MHz. The latency for control and user planes should be less than 100 ms and 10 ms, respectively, in unloaded conditions.
As I mentioned last week, the 3GPP candidate for IMT-Advanced is LTE-Advanced. On the IEEE front, 802.16j group published the relay-based multihop techniques for WiMAX and IEEE 802.16m has been submitted for the IMT-Advanced approval last week. The normal 802.16 WiMAX standard has been approved as 3G standard by the ITU.
So what exactly are Relays. Relay transmission can be seen as a kind of collaborative communications, in which a relay station (RS) helps to forward user information from neighboring user equipment (UE)/mobile station (MS) to a local eNode-B (eNB)/base station (BS). In doing this, an RS can effectively extend the signal and service coverage of an eNB and enhance the overall throughput performance of a wireless communication system. The performance of relay transmissions is greatly affected by the collaborative strategy, which includes the selection of relay types and relay partners (i.e., to decide when, how, and with whom to collaborate).
There are two different terminology used for Relay's. First is Type-I and Type-II and other is non-transparency and transparency. Specifically, a Type-I (or non-transparency) RS can help a remote UE unit, which is located far away from an eNB (or a BS), to access the eNB. So a Type-I RS needs to transmit the common reference signal and the control information for the eNB, and its main objective is to extend signal and service coverage. Type-I RSs mainly perform IP packet forwarding in the network layer (layer 3) and can make some contributions to the overall system capacity by enabling communication services and data transmissions for remote UE units. On the other hand, a Type-II (or transparency) RS can help a local UE unit, which is located within the coverage of an eNB (or a BS) and has a direct communication link with the eNB, to improve its service quality and link capacity. So a Type-II RS does not transmit the common reference signal or the control information, and its main objective is to increase the overall system capacity by achieving multipath diversity and transmission gains for local UE units.
Different relay transmission schemes have been proposed to establish two-hop communication between an eNB and a UE unit through an RS. Amplify and Forward — An RS receives the signal from the eNB (or UE) at the first phase. It amplifies this received signal and forwards it to the UE (or eNB) at the second phase. This Amplify and Forward (AF) scheme is very simple and has very short delay, but it also amplifies noise. Selective Decode and Forward — An RS decodes (channel decoding) the received signal from the eNB (UE) at the first phase. If the decoded data is correct using cyclic redundancy check (CRC), the RS will perform channel coding and forward the new signal to the UE (eNB) at the second phase. This DCF scheme can effectively avoid error propagation through the RS, but the processing delay is quite long. Demodulation and Forward — An RS demodulates the received signal from the eNB (UE) and makes a hard decision at the first phase (without decoding the received signal). It modulates and forwards the new signal to the UE (eNB) at the second phase. This Demodulation and Forward (DMF) scheme has the advantages of simple operation and low processing delay, but it cannot avoid error propagation due to the hard decisions made at the symbol level in phase one.
Relay starts becoming interesting because according to the 3GPP LTE-Advanced and IEEE 802.16j, an RS can act as the BS for legacy UE units and should have its own physical cell identifier. It should be able to transmit its own synchronization channels, reference symbols and downlink control information. So an RS shall have the full functions of an eNB/BS (except for traffic backhauling), including the capabilities of knowing the radio bearer of received data packets and performing traffic aggregation to reduce signaling overhead. There should be no difference between the cell controlled by an RS and that controlled by a normal eNB.
There are much more details and simulation results in the IEEE article. For those interested, can always get hold of the article and dig deeper.
More information also available in the following:
Monday, 12 October 2009
Sunday, 11 October 2009
Google's strategy for winning in a nutshell
Interesting analysis by Zigurd Mednieks on his blog 4thscreen. Though not directly linked to mobiles, I am sure a similar approach is being taken for mobiles.Google wants to enable Google applications to run as well as possible as many places as possible. Here is how:
Google applications: Web applications run in browsers, on all kinds of systems. No need to be installed or updated, and hard to block. Anyone with IE, Firefox, Safari, Opera, or, of course, Chrome has access to all the latest applications.
Gears: Web applications run in a sandbox and don't have much access to your system. Gears enables more access. Applications are still in a sandbox, but the Gears-enabled sandbox is bigger, and can persist. This frees Web applications from having to be connected all the time.
GWT: The Google Web Toolkit (GWT) is a radical abstraction of of the browser runtime environment. GWT applications are written in Java and compiled to JavaScript. The GWT library provides fixes for incompatibilities between browsers, as well as a rich UI library.
Chrome: Google's browser. Chrome provides the ideal browser runtime environment for Google applications. Fast JavaScript execution. Separate processes for each Web page.
Chrome Frame: Chrome Frame puts the Chrome browser inside Internet Explorer. This shows the lengths Google will go to in order to give Google applications the best possible runtime environment is as many situations as possible.
Android: Android is a Linux-based OS for mobile handsets and other devices. Android has exploded in popularity among handset manufacturers. This is Google's first win in computing platforms, and Google influences the software “stack” all the way down to the hardware. Android has a Webkit-derived browser.
Chrome OS: Chrome OS is meant for things larger than handsets. Chrome will be Google's attempt to bring a Linux-based OS and Web-based applications to netbooks and PCs.
Google's strategy is comprehensive: Control the software all the way down to the hardware where possible, and, if that isn't possible, be compatible, and maximize capabilities, on every possible platform.
Google's strategy is also technologically coherent: Java, Linux, Webkit, SQLite, Eclipse, and other common components are reused across multiple Google products and platforms. You can expect Google to contribute to and influence the development of these key ingredients. You can also see some design philosophy in common across Google products. For example, Android runs Java applications in multiple tasks, and Chrome runs Web pages/apps in multiple tasks to make these systems resilient to apps that crash.
While Google's applications, like Gmail, are proprietary, Android, Chrome, Gears, GWT and many other components of Google's strategy are open source software, many with permissive licensing that would not preclude competitors from using them. Open source builds confidence in Google's partners and in software developers using Google platforms.
Google's strategy has formed recently and moved quickly. It can be hard to perceive the impact. As fast as Google is implementing this strategy, you can expect a similarly fast emergence of an application ecosystem around Google's strategy. This will be one of the most significant developments in software in the coming years.
Meanwhile google has recently added search options to mobiles. You can now search only forums and you can search for posts that were posted within last week. Very powerful feature but shame so many PC users dont even know hot to use them.
Another very interesting feature that has been added is that when you search using desktop, you will be able to see that in your search history in mobiles as well. Google now synchs between your desktop and mobile as long as you have iPhone, Android or Palm phone.
I wonder how will Google surprise us next.
Friday, 9 October 2009
IMT-Advanced Proposals to be discussed next week
Depending on which camp you belong to, you would have read atleast one press release.The 3GPP Partners, which unite more than 370 leading mobile technology companies, made a formal submission to the ITU yesterday, proposing that LTE Release 10 & beyond (LTE-Advanced) be evaluated as a candidate for IMT-Advanced. Complete press release here.
The IEEE today announced that it has submitted a candidate radio interface technology for IMT-Advanced standardization in the Radiocommunication Sector of the International Telecommunication Union (ITU-R).
The proposal is based on IEEE standards project 802.16m™, the “Advanced Air Interface” specification under development by the IEEE 802.16™ Working Group on Broadband Wireless Access. The proposal documents that it meets ITU-R’s challenging and stringent requirements in all four IMT-Advanced “environments”: Indoor, Microcellular, Urban, and High Speed. The proposal will be presented at the 3rd Workshop on IMT-Advanced in Dresden on 15 October in conjunction with a meeting of ITU-R Working Party 5D. Complete press release here.
The workshop next week will see lots of announcements, discussions and debates about both these technologies. More details on workshop here. My 3G4G page on LTE-Advanced here.
I am sure there is a place for both these technologies and hopefully both of them will succeed :)
Thursday, 8 October 2009
TD-SCDMA Politics!
I posted sometime back about China Mobile standards ready to battle the 3G standards. I read this interesting piece in The IET Magazine:
The wait is over for millions of Chinese mobile phone users. Following several years of delays, the government has finally issued the licences that were necessary for the introduction of third-generation cellular services in the country.
As ordered by the Ministry of Industry and Information Technology, each of the nation’s three main operators will have to build and operate a network based on one of the three different standards that were vying for a share of the world’s largest cellular market.
China Mobile (by far the dominant carrier with over 460 million subscribers) will operate on TD-SCDMA, the 3G technology that was developed entirely in the People’s Republic by the Chinese Academy of Telecommunications Technology in collaboration with Datang and Siemens. China Telecom will run on W-CDMA, while China Unicom gets CDMA2000.
Considering how immature TD-SCDMA technology still is - and how discouraging its build-up trials have proved - China Mobile seems to have landed the worst possible deal.
Then again, that was the whole idea of this so-called reorganisation of the country’s telecoms industry. Let the incumbent cellco work on the many problems that will have to be ironed out before TD-SCDMA can be considered a credible 3G alternative, and that should give the two smaller operators enough time to catch up by taking advantage of proven technologies and an established pool of equipment suppliers.
The Chinese government wants a more balanced, more competitive telecoms market, and this should help do the trick. But the move is also likely to have some strange consequences in the relationship between mobile operators and phone makers.
China Mobile faces two different handset-related challenges when it comes to 3G. The first one is qualitative: existing TD-SCDMA phones are technically inferior to those that subscribers have been using in the rest of the world for well over eight years now. The second is quantitative: only 40 or so TD-SCDMA models exist, while China Mobile says it will need several hundred.
So the company is resorting to some unprecedented behaviour for a cellular operator. At the last Mobile World Congress in Barcelona, Wang Jianzhou, the chairman of China Mobile, met with a group of handset vendors (including Nokia, LG, Samsung, Sony Ericsson and some of the Chinese manufacturers) and offered to pay them part of the R&D costs of developing better TD-SCDMA products.
Handset makers have rarely witnessed such generous attitudes from an operator. Even rarer is the fact that the offer is coming from what is now the world’s largest operator. Add to that the unfavourable financial conditions most of these OEMs are enduring and you could safely assume they’ll go and see what they can do to help China Mobile.
Wednesday, 7 October 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:
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
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.
Monday, 5 October 2009
Industry's first LTE Comformance test submitted for approval
Anite has submitted the first LTE test case 8.1.2.1 based on the conformance test specification 36.523-1. The test case was debugged using the LG Electronics LE03 UE.
This is in a way good news as the industry is moving forward at an amazing speed. The Release-8 of LTE was finalised in reality in March 09 (or Dec. 08 for some specs).
Anite has partnered with Agilent for the conformance testing and this release of TC's is a good way forward towards proving industry leadership. Looking at the latest test cases that have been submitted, it seems another couple of tests 7.1.1.1 and 8.1.1.1 have been submitted as well.
People who are interested in technical details can look at the logs submitted and get the details of the messages that I have specified in the message flow earlier here.
====== Edited after post =====
Here is their press release which seems to have come after my blog :)
Anite, a global leader in testing technology for the wireless industry, and LG Electronics (LG), a global leader and technology innovator in mobile communications, today announced the successful verification of the industry’s first LTE protocol conformance test cases. Anite and LG Electronics have made the results from their groundbreaking work available to the members of the 3GPP standards body, so that the entire mobile industry may benefit from this milestone achievement.
Conformance testing is fundamental in leading-edge technologies, such as LTE, because it ensures that new handsets and data cards deliver both the applications and services anticipated by the end user and the ability to work seamlessly with existing users and networks. LG uses Anite’s LTE solution – which provides a suite of development tools for UE designers – to develop their devices in advance of LTE networks being available, ensuring these meet the industry’s rigorous certification requirements during the earliest stages of their development cycle.
The new tests build upon Anite’s comprehensive portfolio for all leading 3GPP protocol technologies from GSM through EDGE and WCDMA to the latest HSPA+ standards. Anite’s unique blend of software-only host and target test solutions for 2G, 3G and LTE technologies allows developers to adopt a total end-to-end test philosophy for all of their wireless testing needs, reducing both their time and cost to market.
"LTE device certification is essential in ensuring that next generation LTE wireless devices meet customer expectations. Working with LG is speeding the availability of the first LTE test cases to LTE developers, enabling the wireless industry to deploy the technology successfully and more quickly," said Paul Beaver, 3GPP Director, Anite. “Our customers can be confident that investing in Anite’s products will meet their conformance testing needs, maximising their test system utilisation and return on investment.”
Subscribe to:
Posts (Atom)
