Commercial Mobile Alert System (CMAS) in Release-9

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

CMAS VIA LTE/EPS

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

3GPP STANDARDS

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

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

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

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

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

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

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

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

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

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

Practical innovation, Radical innovation and Incremental innovation at the Mobile World Congress

From a post by Ajit Jaokar in Forum Oxford:

There has been a lot of coverage of mobile world congress. I have said before that the event was a success and also that we, as an industry are adding value when there is so much economic chaos around us. GSMA also validates this trend by their statistics and attendee numbers GSMA Releases Congress Visitor Stats

If there was an underlying theme for the event, then I think it was 'practical innovation' i.e. innovation designed to solve problems. This is a more interesting trend which I genuinely like. However, there is also space for radical innovation and also incremental innovation. Hence, I will discuss innovation in these themes below. By 'incremental innovation', I mean changes that take a few years to manifest but are significant. Most changes in the devices, networks and infrastructure will be in this space. The challenge for incremental innovation is: Customers may be overtaken by more nimble/sometimes imperfect. And then, there is radical innovation which may be a game changer

I will provide a series of links to announcements that caught my eye in the show (and afterwards). But first, a note of caution: Let's not forget what happened to Palm AFTER the MWC. Last year, Palm was an 'innovator' with much talk of its 'comeback'. Today, there is an overall doom and gloom around Palm. . Palm's products may be good .. But does it matter when the industry is moving so fast and customers have so much choice? Will developers continue to support a waning platform? Today, we see excellent new devices from Samsung, Microsoft, HTC and others which were not present a year ago. All this means that the rate of change has increased. This is a matter for optimism but also caution as the woes of Palm demonstrate.

Firstly, before we discuss further, some of the big announcements. Again, I provide links so that I don't duplicate much of what we have seen before.

Major announcements

Carriers Connect to Rival Apple's App Store

Moblin + Maemo + Linux Foundation = MeeGo

VOIP and Skype. See the white paper written by me and Chetan on the tipping point for VOIP

Wholesale Applications Community

Vodafone calls for tiered mobile-bandwidth pricing

Windows Phone 7 Series

Also see my talk as well: Is Twittter the glue for the Internet of things?

Practical innovation

Orange Healthcare joins the mHealth Alliance to develop mobilehealth solutions in west africa

Telefónica Internacional selects NEC as strategic partner to promote Cloud Computing solutions in Latin America

GSMA Announces Winners of the 15th Annual Global Mobile Awards

RIM to offer free BlackBerry Enterprise Server

mHealth potential: More questions than answers

Radical innovation

Access SIM-Based Services Just by Tapping or Shaking the Mobile Phone

An Accelerometer 1,000x More Sensitive Than the iPhone's

Elsemobile

Growvc launches with an innovative model for mobile startups

Incremental innovation which could be pointers to bigger trends

DEVICES

Huawei and Acer add high-end phones to Android mix

Microsoft to let you install apps on memory card sticks

Huawei unveils first HSPA+ Android phone

Samsung Wave review

Adobe joins LiMo Foundation, adds Flash support to LiMo platform

10 things the iPhone can learn from Mobile World Congress

Qualcomm's Dual-Core 1.5GHz Snapdragon: Smartphones Are About to Go Hyperspeed

The best phones, stunts, and demos of Mobile World Congress

Motorola milestone

LG Licenses Push Email from Good

Layar Looks to Create the App Store of Mobile Augmented Reality

Nokia chief: we want to be all things to all consumers again

The Android Who Cried Wolf

Vodafone To Sell Sub-$15 Phone in Developing Countries

RIM shows off the new WebKit-powered BlackBerry browser

Gallery: Biggest Smartphone News From Barcelona

LG: No plans for a proprietary OS

The Puma phone
Samsung's Wave Is Bada-Full

Samsung's About to Own More of the TV Market Than Any Company in 60 Years

NETWORKS

Alcatel-Lucent beefs up carrier apps strategy

Movial Selected as LG-Nortel Partner to Provide Rich Multimedia Communications Application and Touch Screen Optimized Mobile Browser

Gemalto Innovation: Gemalto Launches "Device Service Link" to Facilitate Access to Mobile Broadband

OneAPI Gains Momentum as GSMA Announces Commercial Pilot with Leading Mobile Operators in Canada

LTE-Advanced specs to be published in 2011

Huawei show first triple-mode LTE modem

GSMA Outlines Progress with RCS Initiative

40 Companies Back GSMA's Voice Over LTE Fix

OneAPI Standardizes Carrier Billing APIs Across Networks

GSM-UMTS Network migration towards LTE

Another interesting white-paper from 3G Americas. The following from their press release:

A 3rd Generation Partnership Project (3GPP) specification, LTE will serve to unify the fixed and mobile broadband worlds and will open the door to new converged multimedia services. As an all-IP-based technology, LTE will drive a major network transformation as the traditional circuit-based applications and services migrate to an all-IP environment, though introducing LTE will require support and coordination between a complex ecosystem of application servers, devices/terminals and interaction with existing technologies. The report discusses functionality and steps GSM-UMTS network operators may use to effectively evolve their networks to LTE and identifies potential challenges and solutions for enabling the interaction of LTE with GSM, GPRS and UMTS networks.

“This white paper reveals solutions that facilitate a smooth migration for network operators as they deploy LTE,” stated Chris Pearson, president of 3G Americas. “3GPP has clearly defined the technology standards in Release 9 and Release 10, and this paper explores the implementation of these standards on 3GPP networks.”

A reported 130 operators around the world have written LTE into their technology roadmaps. In December 2009, TeliaSonera launched the world’s first LTE networks in Norway and Sweden and an estimated 17 operators are expected to follow in its footsteps in 2010.

“LTE is receiving widespread support and powerful endorsements from industry leaders around the world, but it is important to keep in mind that the evolution to LTE will require a multi-year effort,” Pearson said. “LTE must efficiently and seamlessly coexist with existing wireless technologies during its rise to becoming the leading next-generation wireless technology.”

Operators planning LTE deployments must consider the implications of utilizing LTE in an ecosystem comprising 2G, 3G and future “4G” wireless technologies. Therefore, operators planning an LTE deployment will need to offer multi-technology devices with networks that allow mobility and service continuity between GSM, EDGE, HSPA and LTE.

BBC and Ubiquisys stream multiple videos over a femtocell at MWC 2010

Impressive. I suppose they are four simultaneous PS dedicated calls as all other approaches (Like Mobile TV Broadcast technology and MBMS) would not be applicable for Femtocells (atleast for now).

Femtocells for LTE

Picture Source: Continuous Computing

Going back to my old posts here and here, I mentioned that one of the ideas being floated is that to roll out LTE technology initially in Femtocells as that will give the device manufacturers and the operators an idea and a feel about the technology. All the gremlins can be ironed out before mass market take up.

As you may have heard (or know) that in UK, Vodafone rolled out Femtocells which have now been branded as 'Sure Signal' and the device now costs less than half the initial price. The falling prices is because of the fall in the Bill Of Materials (BOM) as well as operator getting more confidence and subsidising the femto's a bit more. Of course this fall in prices means increase in uptake and that is what is being expected by the industry.

At the same time, some small players are getting more interested in the small cells for LTE. The following is from an article in The Register:

Meanwhile, the femto players are looking ahead to LTE, where there are many indications from operators that tiny cells will play a big part in the strategy. The devices will be used from day one by some carriers - to offload data from the macrocell or to provide indoor coverage in high frequencies like 2.6GHz. They could also add capacity to deployments in low frequencies like 700MHz and even be used as a starting point for greenfield providers, which could then add macro networks later, explained Simon Saunders, chair of the Femto Forum.

Continuous Computing has been eyeing the femto market for several years from its heartlands in protocol stacks, core networking and traffic shaping. At MWC, it worked with picoChip and Cavium Networks to show the first complete LTE femtocell reference design. Available immediately, this includes the LTE modem, RF and packet processors, protocol software, intelligent router functionality and a complete Evolved Packet Core (EPC) simulator.

"The demand for LTE femtocells is unquestionable. We are already seeing operators asking for small cell access points to start testing in the second half of this year. Femtocells represent the key to avoiding the difficulties surrounding the first 3G deployments where roll-outs cost too much, took too long and did not meet user expectations," said Mike Dagenais, CEO of Continuous.

Ps: Also read the post on Metro Femtocells here.

Eye movement controlled earphones from NTT DoCoMo

Projector Phones are the future

Couple of interesting Videos from Mobile World Congress

Codec's for LTE

Sometime back I mentioned about Orange launching AMR-WB codec which would result in 'hi-fi quality' voice (even though its being referred to as HD voice by some). Since then, there has been not much progress on this HD-voice issue. CODEC stands for “COder-DECoder,” but is also known as an enCOder-DECoder and COmpression-DECompression system when used in video systems. Codec's are important as they compress the voice/video data/packets so less bandwidth is required for the data to be transmitted. At the same time it has to be borne in mind that the capacity to withstand errors decrease with higher compression ratio and as a result it may be necessary to change the codecs during the voice/video call. This calls for flexibility as in case of AMR (Adaptive Multi Rate) Codecs. The following is from Martin Sauter's book "Beyond 3G – Bringing Networks, Terminals and the Web Together": Voice codecs on higher layers have been designed to cope with packet loss to a certain extent since there is not usually time to wait for a repetition of the data. This is why data from circuit-switched connections is not repeated when it is not received correctly but simply ignored. For IP sessions, doing the same is difficult, since a single session usually carries both real-time services such as voice calls and best-effort services such as Web browsing simultaneously. In UMTS evolution networks, mechanisms such as ‘Secondary PDP contexts’ can be used to separate the real-time data traffic from background or signaling traffic into different streams on the air interface while keeping a single IP address on the mobile device. UMTS uses the same codecs as GSM. On the air interface users are separated by spreading codes and the resulting data rate is 30–60 kbit/s depending on the spreading factor. Unlike GSM, where timeslots are used for voice calls, voice capacity in UMTS depends less on the raw data rate but more on the amount of transmit power required for each voice call. Users close to the base station require less transmission power in downlink compared with more distant users. To calculate the number of voice calls per UMTS base station, an assumption has to be made about the distribution of users in the area covered by a cell and their reception conditions. In practice, a UMTS base station can carry 60–80 voice calls per sector. A typical three-sector UMTS base station can thus carry around 240 voice calls. As in the GSM example, a UMTS cell also carries data traffic, which reduces the number of simultaneous voice calls. 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,": Real-time flows (voice/video) based on rate adaptive codecs can dynamically switch between different codec rates. Codec rate adaptation allows an operator to trade off voice/video quality on one side and network capacity (e.g. in terms of the number of accepted VoIP calls), and/or radio coverage on the other side. Operators have requested a standardized solution to control the codec rate adaptation for VoIP over LTE, and a solution has been agreed upon and specified in the 3GPP Rel-9 specifications, which is provided in this paper. CODEC RATE ADAPTATION BASED ON ECN Given previous discussion in 3GPP (3GPP S4-070314) it was clear that dropping IP packets was not an acceptable means for the network to trigger a codec rate reduction. Instead an explicit feedback mechanism had to be agreed on by which the network (e.g. the eNodeB) could trigger a codec rate reduction. The mechanism agreed on for 3GPP Rel-9 is the IP-based Explicit Congestion Notification (ECN) specified in an IETF RFC. ECN is a 2 bit field in the end-to-end IP header. It is used as a “congestion pre-warning scheme” by which the network can warn the end points of incipient congestion so that the sending endpoint can decrease its sending rate before the network is forced to drop packets or excessive delay of media occurs. Any ECN-based scheme requires two parts: network behavior and endpoint behavior. The first part had already been fully specified in an IETF RFC106 and merely had to be adopted into the corresponding specifications (3GPP TS 23.401 and 3GPP TS 36.300). The network behavior is completely service and codec agnostic. That is, it works for both IMS and non-IMS based services and for any voice/video codec with rate-adaptation capabilities. The main work in 3GPP focused on the second part: the endpoint behavior. For 3GPP Rel-9, the endpoint behavior has been specified for the Multimedia Telephony Service for IMS (MTSI - 3GPP TS 26.114). It is based on a generic (i.e. non-service specific) behavior for RTP/UDP based endpoints, which is being standardized in the IETF. Furthermore, it was agreed that no explicit feedback was needed from the network to trigger a codec rate increase. Instead, the Rel-9 solution is based on probing from the endpoints – more precisely the Initial Codec Mode (ICM) scheme that had already been specified in 3GPP Rel-7 (3GPP S4-070314). After the SIP session has been established, the sending side always starts out with a low codec rate. After an initial measurement period and RTCP receiver reports indicating a “good channel,” the sending side will attempt to increase the codec rate. The same procedure is executed after a codec rate reduction. Figure 6.8 depicts how codec rate reduction works in Rel-9:

• Step 0. The SIP session is negotiated with the full set of codec rates and independent of network level congestion. The use of ECN has to be negotiated separately for each media stream (e.g. VoIP).
• Steps 1 and 2. After ECN has been successfully negotiated for a media stream the sender must mark each IP packet as ECN-Capable Transport (ECT). Two different values, 10 and 01, have been defined in an IETF RFC106 to indicate ECT. However, for MTSI only 10 shall be used.
• Step 3. To free up capacity and allow more VoIP calls and/or to improve VoIP coverage, the eNodeB sets the ECN field to Congestion Experienced (CE) in an IP packet that belongs to an IP flow marked as ECT. Note that the ECN-CE codepoint in an IP packet indicates congestion in the direction in which the IP packets are being sent.
• Steps 4 and 5. In response to an ECN-CE the receiving MTSI client issues an RTCP message to trigger a codec rate reduction.

Note that ECN operates in both directions (uplink and downlink) entirely independent and without any interactions. It is very well possible to trigger codec rate adaptation in one direction without triggering it in the other direction. ONGOING WORK IN 3GPP A new work item called, Enabling Encoder Selection and Rate Adaptation for UTRAN and E-UTRAN, has been created for 3GPP Rel-10. Part of this work item is to extend the scope of the codec rate adaptation solution agreed in Rel-9 to also apply to HSPA and non-voice RTP-based media streams. Further Reading:

• 3GPP S4-070314, Rate-Adaptive Real-time Media, Reply Liaison from SA4 to RAN2, 2007 (http://www.3gpp.org/ftp/TSG_SA/WG4_CODEC/TSGS4_43/Docs/S4-070314.zip)
• IETF RFC 3168 (09/2001), The Addition of Explicit Congestion Notification (ECN) to IP. (http://tools.ietf.org/html/rfc3168)
• 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (http://www.3gpp.org/ftp/Specs/archive/23_series/23.401/)
• 3GPP TS 36.300: Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (http://www.3gpp.org/ftp/Specs/archive/36_series/36.300/)
• 3GPP TS 26.114: IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handling and interaction (http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/)
• Westerlund, M., et al., Explicit Congestion Notification (ECN) for RTP over UDP, draft-westerlund-avt-ecn-for-rtp-02, work in progress (ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-westerlund-avt-ecn-for-rtp-02.txt)
• 3GPP TR 23.860: Enabling Coder Selection and Rate Adaptation for UTRAN and E-UTRAN for Load Adaptive Applications; Stage 2 (http://www.3gpp.org/ftp/Specs/archive/23_series/23.860/)
• 3GPP TS 26.071: Mandatory speech CODEC speech processing functions; AMR speech CODEC; General description(http://www.3gpp.org/ftp/Specs/archive/26_series/26.071/)
• 3GPP TS 26.171: Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; General description (http://www.3gpp.org/ftp/Specs/archive/26_series/26.171/)

Femtocells update from Mobile World Congress 2010

From The Register:

Among a host of announcements, the leading silicon supplier for this segment, picoChip, was working hard to maintain its headstart as Qualcomm and others gear up to enter the market. It announced no fewer than six new customers, many coming from the Taiwanese ecosystem that is so vital to the mass adoption and price competitiveness of any emerging consumer product.

The new customers are Alpha Networks, Argela, Askey, C&S Micro, Contela and Zyxel, all of which will use the UK firm's PC302 picoXcell system-on-chip for HSPA(+). This is designed to reduce cost and time to market for vendors, and now has over 20 adopters, including Vodafone's femto supplier Alcatel-Lucent, and AT&T's, Cisco/ip.access.

Meanwhile, the femto players are looking ahead to LTE, where there are many indications from operators that tiny cells will play a big part in the strategy. The devices will be used from day one by some carriers - to offload data from the macrocell or to provide indoor coverage in high frequencies like 2.6GHz. They could also add capacity to deployments in low frequencies like 700MHz and even be used as a starting point for greenfield providers, which could then add macro networks later, explained Simon Saunders, chair of the Femto Forum.

Continuous Computing has been eyeing the femto market for several years from its heartlands in protocol stacks, core networking and traffic shaping. At MWC, it worked with picoChip and Cavium Networks to show the first complete LTE femtocell reference design. Available immediately, this includes the LTE modem, RF and packet processors, protocol software, intelligent router functionality and a complete Evolved Packet Core (EPC) simulator.

"The demand for LTE femtocells is unquestionable. We are already seeing operators asking for small cell access points to start testing in the second half of this year. Femtocells represent the key to avoiding the difficulties surrounding the first 3G deployments where roll-outs cost too much, took too long and did not meet user expectations," said Mike Dagenais, CEO of Continuous.

The reference design used a picoChip modem, mezzanine RF card and PHY software; Cavium's Octeon Plus multicore processor; and Continuous' Trillium LTE Layer 2/3 protocols, eNodeB reference application and EPC emulator.

From The Independent:

Call it network congestion, capacity crunch or data overload - the complaints aired at the Mobile World Congress in Barcelona this week were all about cellphone network operators trying to find ways of profitably handling an explosion in mobile data traffic.

Management of the data traffic has become a priority for the telecoms industry as mobile internet usage is booming but data revenues for the phone companies grow slowly at best.

Research firm Informa forecasts a 50 per cent rise in mobile data traffic in 2010 on the back of the increasing popularity of devices such as the Apple iPhone and netbooks, but only a 13 percent rise in data revenues.

This has put added pressure on the phone companies to find ways of using fixed line networks including the internet to take some of the strain off the airwaves.

"Offloading is crucial for us," France Telecom -owned Orange's global head of mobile Olaf Swantee told Reuters ahead of the conference.

"In many countries where we have a fixed network we try to offload directly," he said.

The problem is that offloading data from wireless network to local hotspots still costs money, and operators are searching left and right for solutions that will not raise their overall capital spending, industry executives said.

"To address the smartphone challenge they are investing again," said Rajeev Suri, chief executive of joint venture equipment maker Nokia Siemens, who added that it was uncertain whether this spending was additional to or instead of other investment plans.

More certain was Bruce Brda, head of rival Motorola's networks business. "Carriers have been very consistent - they do not increase capex," he told Reuters.

Nevertheless Motorola saw better than expected demand late last year for equipment as some operators strengthened their existing networks to cope with surging data traffic, Brda said.

"In early 2010 I am seeing the same trend. The indication is there is incremental spending."

Equipment vendors such as Ericsson, Nokia Siemens and Alcatel-Lucent were also demonstrating new technology LTE equipment in Barcelona, as a route toward handling the data rush.

Operators are expected to spend billions of euros converting their networks to the Long Term Evolution standard, which will enable fast mobile broadband access for services such as watching movies on mobile phones, although some critics say LTE would prove a stopgap solution if data traffic goes on growing.

"LTE will buy a carrier two to three years of relief, but then it runs out," Brda said.

And analysts say telecom operators' sales in mature markets are not growing fast enough to justify major investments, which may mean an increase in demand instead for other technologies such as Wi-Fi or femtocells.

Femtocells are localized phone network base stations sited in homes and offices where signal strength might otherwise be weak, taking users onto the phone company's network via their own broadband internet connections.

"The biggest problem is that everybody is expecting these huge amounts of data but nobody is willing to pay much extra for it," said Stephen Rayment, chief technology officer of Belair Networks, which provides Wi-Fi services.

"Operators started offering 'all you can eat' data and now that's coming back to bite them," he said.

Speaking at Mobile World Congress Professor Simon Saunders, chairman of the femtoforum - the official non-profit standards' body proclaimed "2010 is the breakthrough year for femtocell".

From a UK perspective he was able to confirm the backing of industry regular Ofcom while T-Mobile, Telefonica/O2, Vodafone and Orange have all signed up as members so far. Furthermore, deployment of femtocell solutions to compete with Sure Signal is now ready and in their hands.

"The technology is there and it is now a matter of timing for the operators," he told me. "I cannot give specific dates, but all UK operators should be looking at a 2010 roll-out."

So far 55 network operators are femtocell forum members around the world, and operator commitments have jumped 50 per in the last three months alone. On top of this 3GPP has formalised femtocell standards, and the body's next generation ('Release 9') will bring support for LTE and enhancements for UMTS. The WiMax Forum is also on board as is the FCC in the US while China and Japan have confirmed their support.

Alcatel-Lucent recently announced the availability of a “small cell” (femtocell) designed to address the needs of enterprise customers. And last month Vodafone renamed its femtocell device to Sure Signal, as well as dramatically reducing its cost from £160 down to £50.

Informa said that the Vodafone relaunch of its femtocell offering is “realising considerable success in the UK, spearheading the entrance of femtocell services in the European market.”

“Vodafone rebranded the femtocell service to make the proposition clearer to end users while differentiating from their competition by eliminating indoor coverage deadspots,” it added.

According to Informa there are currently 12 service commitments, including nine commercial launches and several ongoing trials, while completed trials are now progressing into deployment plans for several mobile operators. This contrasts with eight femtocell service commitments and six commercial launches in November 2009.

During the last three months it cited French mobile operator SFR, Portuguese operator OPTIMUS and Chinese operator China Unicom, all of which have commercially launched femtocell services. Meanwhile it says that both Japan’s KDDI and France’s free have also committed to the technology.

Pictures Source: Trusted Reviews

Samsung Mobiles launched at MWC 2010