ETWS detailed in LTE and UMTS

Its been couple of years since the introductory post on 3GPP Earthquake and Tsunami Warning service (ETWS). The following is more detailed post on ETWS from the NTT Docomo technical journal.

3GPP Release 8 accepted the standard technical specification for warning message distribution platform such as Area Mail, which adopts pioneering technology for faster distribution, in order to fulfil the requirements concerning the distribution of emergency information e.g. earthquakes, tsunamis and so on in LTE/EPC. The standard specifies the delivery of emergency information in two levels. The Primary Notification contains the minimum, most urgently required information such as “An earthquake occurred”; the Secondary Notification includes supplementary information not contained in the Primary Notification, such as seismic intensity, epicentre, and so on. This separation allows implementation of excellent information distribution platforms that can achieve the theoretically fastest speed of the warning distribution.

The purpose of the ETWS is to broadcast emergency information such as earthquake warnings provided by a local or national governments to many mobile terminals as quickly as possible by making use of the characteristic of the widespread mobile communication networks.

The ETWS, in the same way as Area Mail, detects the initial slight tremor of an earthquake, the Primary Wave (P wave - The first tremor of an earthquake to arrive at a location), and sends a warning message that an earthquake is about to happen to the mobile terminals in the affected area. ETWS can deliver the first notification to mobile terminals in the shortest theoretical time possible in a mobile communication system (about four seconds after receiving the emergency information from the local or national government), which is specified as a requirement by 3GPP.

The biggest difference between Area Mail and the ETWS is the disaster notification method (Figure 1). Earthquake warnings in Area Mail have a fixed-length message configuration that notifies of an earthquake. ETWS, on the other hand, achieves distribution of the highest priority information in the shortest time by separating out the minimum information that is needed with the most urgency, such as “Earthquake about to happen,” for the fastest possible distribution as a Primary Notification; other supplementary information (seismic intensity, epicentre, etc.) is then distributed in a Secondary Notification. This distinction thus implements a flexible information distribution platform that prioritizes information distribution according to urgency.

The Primary Notification contains only simple patterned disaster information, such as “Earthquake.” When a mobile terminal receives a Primary Notification, it produces a pre-set alert sound and displays pre-determined text on the screen according to the message content to notify users of the danger. The types of disaster that a Primary Notification can inform about are specified as “Earthquake,” “Tsunami,” “Tsunami + Earthquake,” “Test” and “Other,” regardless of the type of radio access.

The Secondary Notification contains the same kind of message as does the existing Area Mail service, which is, for example, textual information distributed from the network to the mobile terminal to inform of the epicentre, seismic intensity and other such information. That message also contains, in addition to text, a Message Identifier and Serial Number that identifies the type of disaster.

A major feature of the ETWS is compatibility with international roaming. Through standardization, mobile terminals that can receive ETWS can receive local emergency information when in other countries if the local network provides the ETWS service. These services are provided in a manner that is common to all types of radio access (3G, LTE, etc.).

Network Architecture

The ETWS platform is designed based on the Cell Broadcast Service (CBS). The ETWS network architecture is shown in Figure 2. Fig. 2 also shows the architecture for 3G network to highlight the features differences between LTE and 3G.

In the ETWS architecture for 3G, a Cell Broadcast Centre (CBC), which is the information distribution server, is directly connected to the 3G Radio Network Controller (RNC). The CBC is also connected to the Cell Broadcast Entity (CBE), which distributes information from the Meteorological Agency and other such sources.

In an LTE radio access network, however, the eNodeB (eNB) is directly connected to the core network, and eNB does not have a centralized radio control function as the one provided by the RNC of 3G. Accordingly, if the same network configuration as used for 3G were to be adopted, the number of eNB connected to the CBC would increase and add to the load on the CBC. To overcome that issue, ETWS for LTE adopts a hierarchical architecture in which the CBC is connected to a Mobility Management Entity (MME).

The MME, which acts as a concentrator node, is connected to a number of eNBs. This architecture gives advantages to the network, such as reducing the load in the CBC and reducing the processing time, and, thus preventing delay in distribution.

Message Distribution Area

In the 3G ETWS and Area Mail systems, the distribution area can be specified only in cell units, which creates the issue of huge distribution area database in CBC. In LTE ETWS, however, the distribution area is specified in three different granularities (Figure 3). This allows the operator to perform area planning according to the characteristic of the warning/emergency occasions, e.g. notice of an earthquake with a certain magnitude needs to be distributed in a certain width of area, thus allowing efficient and more flexible broadcast of the warning message.

1) Cell Level Distribution Area: The CBC designates the cell-level distribution areas by sending a list of cell IDs. The emergency information is broadcasted only to the designated cells. Although this area designation has the advantage of being able to pinpoint broadcast distribution to particular areas, it necessitates a large processing load in the network node (CBC, MME and eNB) especially when the list is long.

2) TA Level Distribution Area: In this case, the distribution area is designated as a list of Tracking Area Identities (TAIs). TAI is an identifier of a Tracking Area (TA), which is an LTE mobility management area. The warning message broadcast goes out to all of the cells in the TAIs. This area designation has the advantage of less processing load when the warning message has to be broadcast to relatively wide areas.

3) EA Level Distribution Area: The Emergency Area (EA) can be freely defined by the operator. An EA ID can be assigned to each cell, and the warning message can be broadcasted to the relevant EA only. The EA can be larger than a cell and is independent of the TA. EA is a unit of mobility management. EA thus allows flexible design for optimization of the distribution area for the affected area according to the type of disaster.

Message Distribution

The method of distributing emergency information to LTE radio networks is shown in Figure 4. When the CBC receives a request for emergency information distribution from CBE, it creates the text to be sent to the terminals and specifies the distribution area from the information in the request message (Fig. 4 (1) (2)).

Next, the CBC sends a Write-Replace Warning Request message to the MME of the specified area. This message contains information such as disaster type, warning message text, message distribution area, Primary Notification information, etc. (Fig. 4 (3)). When the MME receives this message, it sends a response message to the CBC to notify that the message was correctly received. The CBC then notifies the CBE that the distribution request was received and the processing has begun (Fig. 4 (4) (5)). At the same time, the MME checks the distribution area information in the received message (Fig. 4 (6)) and, if a TAI list is included, it sends the Write-Replace Warning Request message only to the eNB that belong to the TAI in the list (Fig. 4 (7)). If the TAI list is not included, the message is sent to all of the eNB to which the MME is connected.

When the eNB receives the Write-Replace Warning Request message from the MME, it determines the message distribution area based on the information included in the Write-Replace Warning Request message (Fig. 4 (8)) and starts the broadcast (Fig. 4 (9) (10)). The following describes how the eNB processes each of the specified information elements.

1) Disaster Type Information (Message Identifier/Serial Number): If an on-going broadcast of a warning message exists, this information is used by the eNB to decide whether it shall discard the newly received message or overwrite the ongoing warning message broadcast with the newly received one. Specifically, if the received request message has the same type as the message currently being broadcasted, the received request message is discarded. If the type is different from the message currently being broadcast, the received request message shall overwrite the ongoing broadcast message and the new warning message is immediately broadcasted.

2) Message Distribution Area (Warning Area List): When a list of cells has been specified as the distribution area, the eNB scans the list for cells that it serves and starts warning message broadcast to those cells. If the message distribution area is a list of TAIs, the eNB scans the list for TAIs that it serves and starts the broadcast to the cells included in those TAIs. In the same way, if the distribution area is specified as an EA (or list of EAs), the eNB scans the EA ID list for EA IDs that it serves and starts the broadcast to the cells included in the EA ID.

If the received Write-Replace Warning Request message does not contain distribution area information, the eNB broadcasts the warning message to all of the cells it serves.

3) Primary Notification Information: If Primary Notification information indication exists, that information is mapped to a radio channel that is defined for the broadcast of Primary Notification.

4) Message Text: The eNB determines whether or not there is message text and thus whether or not a Secondary Notification needs to be broadcasted. If message text exists, that text is mapped to a radio channel that is defined for the broadcast of Secondary Notification. The Secondary Notification is broadcast according to the transmission intervals and number of transmissions specified by the CBC. Upon the completion of a broadcast, the eNB returns the result to the MME (Fig. 4 (11)).

Radio Function Specifications

Overview : In the previous Area Mail service, only mobile terminals in the standby state (RRC_IDLE) could receive emergency information, but in ETWS, emergency information can be received also by mobile terminals in the connected state (RRC_CONNECTED), and hence the information can be delivered to a broader range of users. In LTE, when delivering emergency information to mobile terminals, the eNB sends a bit in the paging message to notify that emergency information is to be sent (ETWS indication), and sends the emergency information itself as system information broadcast. In 3G, on the other hand, the emergency information is sent through the paging message and CBS messages.

Message Distribution method for LTE: When the eNB begins transmission of the emergency information, a paging message in which the ETWS indication is set is sent to the mobile terminal. ETWS-compatible terminals, whether in standby or connected, try to receive a paging message at least once per default paging cycle, whose value is specified by the system information broadcast and can be set to 320 ms, 640 ms, 1.28 s or 2.56 s according to the 3GPP specifications. If a paging message that contains an ETWS indication is received, the terminal begins receiving the system information broadcast that contains the emergency information. The paging message that has the ETWS indication set is sent out repeatedly at every paging opportunity, thus increasing the reception probability at the mobile terminal.

The ETWS message itself is sent as system information broadcast. Specifically, the Primary Notification is sent as the Warning Type in System Information Block Type 10 (SIB10) and the Secondary Notification is sent as a Warning Message in SIB11. By repeated sending of SIB10 and SIB11 (at an interval that can be set to 80 ms, 160 ms, 320 ms, 640 ms, 1.28 s, 2.56 s, or 5.12 s according to the 3GPP specifications), the probability of the information being received at the residing mobile terminal can be increased. In addition, the SIB10 and SIB11 scheduling information is included in SIB1 issued at 80-ms intervals, so mobile terminals that receive the ETWS indication try to receive SIB10 and SIB11 after first having received the SIB1. By checking the disaster type information (Message Identifier and Serial Number) contained in SIB10 and SIB11, the mobile terminal can prevent the receiving of multiple messages that contain the same emergency information.

3G Message Distribution Method: For faster information delivery and increased range of target uers in 3G also, the CBS message distribution control used in Area Mail was enhanced. An overview of the 3G radio system is shown in Figure 5.

In the Area Mail system, a Common Traffic Channel (CTCH) logical channel is set up in the radio link, and emergency information distribution is implemented by sending CBS messages over that channel. To inform the mobile terminals that the CTCH logical channel has been set up, the RNC orders the base station (BTS) to set the CTCH Indicator information element in the system information broadcast to TRUE, and transmits the paging message indicating a change in the system information broadcast to the mobile terminals. When the mobile terminal receives the CTCH Indicator, it begins monitoring the CTCH logical channel and can receive CBS messages.

In ETWS, by including the Warning Type in the paging message indicating a change in the system information broadcast, processing for a pop-up display and alert sound processing (Primary Notification) at the mobile terminals according to the Warning Type can be executed in parallel to the processing at the mobile terminals to start receiving the CBS messages. This enhancement allows users whose terminals are in the connected state (RRC_CONNECTED) to also receive emergency information. In the previous system, it was not possible for these users to receive emergency information. Also including disaster type information (Message Identifier and Serial Number) in this paging message makes it possible to prevent receiving multiple messages containing the same emergency information at the mobile terminal.

More detailed information (Secondary Notification) is provided in CBS messages in the same way as in the conventional Area Mail system, thus achieving an architecture that is common to ETWS users and Area Mail users.

Presentations on Femtocell Applications and Services from MWC2011

These three interesting presentations embedded below from Mobile World Congress 2011 are available to download from Femto Forum website here.

Femtocell Based Applications and Services

View more presentations from Zahid Ghadialy

Next generation remote management: bridging devices and applications

View more presentations from Zahid Ghadialy

Services and Femtocell Adoption

View more presentations from Zahid Ghadialy

Augmented Reality: Future Killer App?

Augmented Reality can be understood very easily with the two videos embedded below:

It may look cool and one may wonder how this can be useful practically, here is another video showing how this can be used:

So in future you may have quite a few people who can only look at you through the [phone rather than directly :)

The following is an extract from The Guardian article titled, "What is mobile augmented reality for?":

Mobile augmented reality is a relatively young technology, but it has already attracted a great deal of hype and scepticism in equal measure.

Overlaying digital information onto the real world, viewed through a cameraphone, is technically impressive, but the business models and usage patterns are still evolving.

That's a polite way of saying mobile AR is cool, but nobody really knows what it's for, or how it will make money. One of the more interesting conference sessions at this year's Mobile World Congress aimed to answer the key question: what is it for?

Tourism has been an early focus. Just this week, travel site TripAdvisor added an augmented reality feature to its iPad app (pictured above), while Lonely Planet has also used AR elements in several of its travel apps.

"You are most information-starved when you are in a completely new environment," said Jeremy Kreitler, vice-president of mobile at Lonely Planet. "Those are probably the environments where augmented reality will flourish the most."

The Layar chief executive, Raimo Van der Klein, pointed to the popularity of Twitter layers in his company's app, which allow people to see local tweets superimposed on their camera view of the world around them.

"In the future, it will be the physical world that will trigger usage," he said. "Your dynamic and changing context, as you interact with different media, products, packaging and people, and you would like to make sense of what you encounter."

Technology firm Qualcomm recently held an augmented reality contest for mobile developers, announcing three winners this week at Mobile World Congress. All three were games.

Qualcomm's vice-president of ventures, Nagraj Kashyap, took the view that games are often a good proving ground for new technologies in their early stages, with AR no different.

"It's just something that appeals to a wide cross-section of users," he said. "But to have augmented reality become mass, we need to move out of just the gaming context."

Qualcomm sees much potential in marketing, particularly when AR is used to add an interactive layer to print advertisements. Kashyap also thought educational and instructional AR content will be popular in the future. "Imagine pointing your phone at a newly bought washing machine and getting instructions for it on your phone."

However, Philipp Schloter, chief executive of developer Abukai, said that looking for individual killer apps is the wrong way to approach augmented reality.

"This is really more of an enabler that sits across many different areas," he said. He was backed up by Peter Meier, founder of Metaio, the company which makes the Junaio AR browser app. "I always see augmented reality as a new user interface technology, and less as something for which there's the killer app out there," said Meier.

"For me, this is about accessing and understanding information more easily, and enjoying information that is somehow related to the real world ... I don't think there's a killer app. This is more like the next touchscreen for mobile phones – more like the next user interface revolution."

David Marimon, who heads up mobile augmented reality and visual search for operator group Telefonica, suggested that new uses for AR will be found as different kinds of developers start to work with it, including visual and interaction designers.

He also said that Telefonica is keen to help developers find new uses for AR by providing them with technology and APIs to tap into the operator's customer data.

"We know where mobile phones are thanks to GPS and other sensors, which is a very intuitive starting point to get the context of the user," he said. "We are also working on visual recognition to acquire that context: we need to know what the user is looking at, for which we can use the camera."

In the recently concluded Mobile World Congress, there was a panel that discussed the options on Augmented Reality or AR as its better known. The slides are embedded below but only the initial slides provide some value.

Augmented Reality Panel - Mobile World Congress 2011

View more presentations from Zahid Ghadialy

I have heard of some and can can think of some more simple applications that can actually be very useful. Maybe some of them are already being developed.

1. reviews of Pubs/Clubs - If you planning to go to some Pub/club in an area you can just look at the places through your lens and immediately see the number of stars received in reviews.

2. Virtual tour guide - One of the apps Lonely Planet are working on is developing virtual tour guides that can tell you all the information about a place once in your mobile camera

3. In some countries where For Sale sign could not be put while selling houses, you can go in an area and look at the houses though your camera and it will tell you which house is for sale, which estate agent and what is the price

4. Some manufacturers have suggested that simple procedures required with gadgets like changing the toner or a printer can be done using AR apps.

5. Games is certainly and area that is going to be a major user of AR for effects and to get people excited

6. Dating apps could use AR to tell about the places where singles hangout in the real time.

7. Educational purpose.

8. CV's for Jobs - Personally, I think QR code can do the job in this case

9. AR could be used as your personal shopping assistant in the supermarket helping you do your shopping in the least amount of time - assuming you know all the things that need to be bought in advance

And many more uses of AR can be thought of and debated.

Finally, there is also a recent presentation titled "Augmented Research" embedded below:

Augmented Research

View more presentations from Face

Dilbert humour on Engineering budgets

Source: dilbert.com

Mobile Services Beyond Handsets

Interesting presentation by Ted Matsumoto from Softbank, Japan in Mobile World Congress 2011.

Mobile Services go beyond handsets

View more presentations from Zahid Ghadialy

LTE to 3G Handover Procedure and Signalling

It may be worthwhile brushing up the LTE/SAE Interfaces and Architecture before proceeding.

1) Overview of Handover Operation

With EPC, continuous communication is possible, even while the terminal switches from one type of radio access system to another.

Specifically, in order to achieve the internal network path switching required to change radio access systems, the S-GW provides a mobility management anchor function for handover between 3GPP radio access systems, and the P-GW provides the function for handover between 3GPP and non-3GPP radio access systems. In this way, the IP address does not change when the terminal switches radio access systems, and communications can continue after handover.

In handover between the 3GPP radio access systems, LTE and 3G, handover preparation is done before changing systems, including tasks such as securing resources on the target radio access system, through cooperation between the radio access systems (Figure 3 (a)(A)). Then, when the actual switch occurs, only the network path needs to be switched, reducing handover processing time (Fig.3 (a)(B)). Also, loss of data packets that arrive at the pre-switch access point during handover can be avoided using a data forwarding function (Fig.3 (b)).

In this way, through interaction between radio access systems, fast handover without packet loss is possible, even between radio access systems such as LTE and 3G which cannot be used simultaneously.

2) Handover Preparation Procedure (Fig.3 (a)(A))

The handover preparation procedure for switching radio access from LTE to 3G is shown in Figure 4.

Step (1):The terminal sends a radio quality report containing the handover candidate base-stations and other information to the eNodeB. The eNodeB decides whether handover shall be performed based on the information in the report, identifies the base station and RNC to switch to, and begins handover preparation.

Steps (2) to (3): The eNodeB sends a handover required to the MME, sending the RNC identifier and transmission control information for the target radio access system. The MME identifies the SGSN connected to the target RNC based on the received RNC identifier and sends the communication control and other information it received from the eNodeB to the SGSN in a forward relocation request signal. The information required to configure the communications path between the S-GW and SGSN, which is used for data transmission after the MME has completed the handover, is sent at the same time.

Steps (4) to (5): The SGSN forwards the relocation request to the RNC, notifying it of the communications control information transmitted from the eNodeB. The RNC performs the required radio configuration processing based on the received information and sends a relocation response to the SGSN. Note that through this process, a 3G radio access bearer is prepared between the SGSN and RNC.

Step (6): The SGSN sends a forward relocation response to the MME in order to notify it that relocation procedure has completed. This signal also includes data issued by the SSGN and required to configure a communications path from the S-GW to the SGSN, to be used for data forwarding.

Steps (7) to (8): The MME sends a create indirect data forwarding tunnel request to the S-GW, informing it of the information issued by the SSGN that it just received. From the information that the S-GW receives, it establishes a communications path from the S-GW to the SGSN for data forwarding and sends a create indirect data forwarding tunnel response to the MME.

Through this handover preparation, target 3G radio-access resources are readied, the radio access bearer between the SGSN and RNC is configured, and the data forwarding path from the

S-GW to the SGSN configuration is completed.

3) Handover Procedure for Radio Access System Switching (Fig. 3(a)(B)):

The handover process after switching radio access system is shown in Figure 5.

Steps (1) to (2): When the handover preparation described in Fig.4 is completed, the MME sends a handover command to the eNodeB. When it receives this signal, the eNodeB sends a handover from LTE command for the terminal to switch radio systems. Note that when the eNodeB receives the handover command from the MME, it begins forwarding data packets received from the S-GW. Thereafter, packets for the terminal that arrive at the S-GW are forwarded to the terminal by the path: S-GW, eNodeB, S-GW, SGSN, RNC.

Steps (3) to (6): The terminal switches to 3G and when the radio link configuration is completed, notification that it has connected to the 3G radio access system is sent over each of the links through to the MME: from terminal to RNC, from RNC to SGSN, and from SGSN to MME. This way, the MME can perform Step (10) described below to release the eNodeB resources after a set period of time has elapsed.

Step (7): The MME sends a forward relocation complete acknowledgement to the SGSN. A set period of time after receiving this signal, the SGSN releases the resources related to data forwarding.

Step (8): The SGSN sends a modify bearer request to the S-GW to change from the communications path before the handover, between the S-GW and eNodeB, to one between the S-GW and SGSN. This signal contains information elements required to configure the path from S-GW to SGSN, including those issued by the SGSN. When the S-GW receives this signal, it configures a communications path from the S-GW to the SGSN. In this way, the communications path becomes: S-GW, SGSN, RNC, terminal; and data transmission to the target 3G radio access system begins.

Note that after this point, data forwarding is no longer needed, so the S-GW sends a packet to the eNodeB with an “End Marker” attached, and when the eNodeB receives this packet, it releases its resources related to data forwarding.

Steps (9) to (10): The S-GW sends a modify bearer response to the SGSN, indicating that handover procedure has completed. The MME also releases eNodeB resources that are no longer needed.

Through this handover procedure, data is forwarded during the handover, the switch of radio access bearer is completed, and the communications path from the P-GW to the terminal is updated.

In the examples above, we described the handover procedure between 3GPP radio access systems in which the S-GW did not change, but handovers with S-GW relocation are also possible. In these cases, the P-GW provides the anchor function for path switching, as with switches to non-3GPP access systems.

TERMS

Anchor function: A function which switches the communications path according to the area where the terminal is located, and forwards packets for the terminal to that area.

Relocation: Switching communications equipment such as area switches during communication.

UMTS-LTE in 3.5GHz

There are two new bands: 3.4-3.6 GHz and 3.6-3.8 GHz decided for Broadband Wireless Access, which are already widely available for licensing in Europe. These bands have earlier been allocated to the Fixed Service on a primary basis in Region 1. Furthermore, the 3.4-3.6 GHz band was allocated to the mobile service on a primary basis and identified for IMT at WRC 07.

These bands constitute a substantial amount of spectrum that will be available in many countries in the short term. In Europe (Region 1) both bands can be used so block sizes could be large for any duplex arrangement.

The UMTS-LTE 3500 MHz Technical Report (3GPP TR 37.801) is already available as a study of current plans in the frequency bands 3.4-3.6 GHz and 3.6-3.8 GHz for UMTS and LTE systems. Specification work is due for first publication in March 2011 (TSG#51), with a series of specifications updated or being created.

The technical report is embedded below:

3GPP TR 37.801: UMTS-LTE 3500 MHz Work Item Technical Report

View more documents from Zahid Ghadialy

Rich Communication Suite (RCS)

I have heard quite a bit about Rich Communication Suite (RCS) recently. It was supposed to start become popular by 2011 but Infonetics puts it as a little too late to become mass market anytime soon in a recent report. The new report forecasts that there would be around 6.8 million RCS subscribers worldwide by end of 2012.

Dean Bubley from Disruptive Wireless released a report some months back saying that RCS is a bit too late and inflexible and the built-in assumptions have problems which wont make it a mass market technology.

Anyway, I decided to explore the technology a bit to understand it better. Before we start digging into this, the following Youtube Video gives a good overview of what RCS is supposed to be:

The following article gives a good summary of RCS as of now:

The GSMA is welcoming a new version of Rich Communication Suite (RCS) that will enable mobile phone customers to use instant messaging (IM), live video sharing and file transfer across any device on any network operator. Deutsche Telekom, Orange, Telecom Italia, Telefonica and Vodafone intend to commercially launch RCS across several European markets from late 2011, and additional operators are expected to launch later in 2012.

Once adopted, Rich Communication Suite – e* (RCS-e) will enable customers to use these enhanced communication services across mobile networks in a simpler and more intuitive way. It is based on a specification put forward by Bharti, Deutsche Telekom, Orange, Orascom Telecom, SK Telecom, Telecom Italia, Telefonica, Telenor and Vodafone which aims to lower the hurdle and speed up the market introduction and adoption of these services.

With RCS-e, customers will be able to use IM, share live video and share files such as photos simultaneously during calls, regardless of the network or device used. RCS-e will enable users to communicate in a very natural way, much like with GSM voice and text today, and will also offer the simplicity and security customers expect from mobile operator services.

As customers open their address book, they will be able to see which communication services are available to them. They can then choose their preferred communications option. For example, a customer would see if their contact is in an area with 3G coverage and is able to receive video.

The participating operators will work with handset suppliers to ensure the service is integrated into the address books of devices, so that customers will not have to download any additional software or technically configure their handsets in order to benefit from the enhanced experience.

“Mobile operators are committed to giving their customers greater choice in the way they communicate with one and other,” said Rob Conway, CEO and Member of the Board of the GSMA. “We welcome the pragmatic approach taken by these operators to accelerate the commercialisation of RCS and simplify the experience for mobile customers and we will work to adopt this specification within the RCS initiative.”

The RCS specification is designed to be interoperable between all operators and devices, giving customers greater choice in how they communicate. The new RCS-e is the result of extensive trials and is a subset of the current RCS 2.0 standard with enhancements. It is focused on extending the principles of voice and SMS calls to deliver an advanced set of interoperable data-centric communications services.

* RCS-e is a new enhanced version of the RCS specification which is based on the use across networks of IP Multimedia Subsystem (IMS) technology, an architectural framework for delivering Internet Protocol (IP) multimedia services.

The following presentation provides a bit more detail

Rich Communication Suite (RCS)

View more presentations from Zahid Ghadialy

Eduardo Martin's blog provides some more insight into the RCS Releases:

RCS has 3 releases, each upgrades the previous one. I will focus on SIP Presence only, but RCS touches more than SIP Presence, it also works other services such as IM.

RCS Release 1 evolves around the concept of the Enhanced Address Book (EAB), an evolution of the usual address book. In short the address book is decorated with enriched information, coming from different services. This plays nicely with today's wishes for cloud stored information, unified social networks status updates, contact content such as portrait icons. I'm not going into technical details, but I for sure am someone who is aware of the design issues around SIP Presence, its hard time scaling due to huge traffic, the dozens of ugly workarounds to make it work, and RCS is a nice step forward into the right direction, there are simple decisions that deeply simplify the network design, making it more like "old" presence networks, which simply work. One remark, it takes quite an effort to define this endorsing IMS and OMA, 27 pages of functional description, plus 39 of technical realization, it should be a lesson for everyone in these standard bodies when defining more extensions or new versions.

The RCS Release 2 effort focuses on enabling access to rich communication services from a wider range of devices. In short it tells that the user has multiple devices, for instance a mobile phone and a PC, possibly concurring for services, and adapts Release 1 for that. It also introduces the Network Address Book, which is just the realization that the EAB needs to be in the network and sync the multiple user devices.

The RCS Release 3 mostly consolidates Release 2 features, and adds some minor enhancements, such as preparing the network for different usages of it, for instance users with devices, which are not connected to mobile network, instead only have broadband connections. In my humble opinion a very important and positive decision, it's about time to consider these scenarios and find out new opportunities. It is weird to say this, but the fact that the industry finally acknowledges that content sharing between two users may happen off the voice/video session is a victory, welcome to the world not session centric.

The RCS specs are available here.

More than 50 Billion Connected Devices

I blogged about the 50 Billion connected devices as predicted by Ericsson last year. With the promised 'Internet of things' and 'connected world' we may see 50 billion devices not too far in the near future. Here is a recent whitepaper from Ericsson on this topic.

Vision 2020 - 50 Billion Connected Devices - Ericsson from Ericsson France

Attach Sequence for LTE Radio

I have in past posted a complete Attach Sequence on the 3G4G website for LTE Radio Signaling but included the signalling on a few nodes. Recently I came across a signalling example in NTT Docomo technical journal which was less detailed but at a higher level and detailed signalling on these other nodes. It may be worthwhile brushing up the LTE Architecture diagram before diving into this.

With EPC, when a terminal connects to the LTE radio access system it is automatically connected to the PDN and this connected state is maintained continuously. In other words, as the terminal is registered on the network (attached) through the LTE radio access system, a communications path to the PDN (IP connectivity) is established.

The PDN to which a connection is established can be preconfigured on a per-subscriber basis, or the terminal can specify it during the attach procedure. This PDN is called the default PDN. With the always-on connection function, the radio link of the connection only is released after a set amount of time has elapsed without the terminal performing any communication, and the IP connectivity between the terminal and the network is maintained. By doing this, only the radio link needs to be reconfigured when the terminal begins actual communication, allowing the connection-delay time to be reduced. Also, the IP address obtained when the terminal attaches can be used until it detaches, so it is always possible to receive packets using that IP address.

The information flow for the terminal attaching to the network up until the connection to the PDN is established is shown in Figure 2 below.

Steps (1) to (3): When the terminal establishes a radio control link for sending and receiving control signals with the eNodeB, it sends an attach request to the MME. The terminal and MME perform the required security procedures, including authentication, encryption and integrity.

Steps (4) to (5): The MME sends an update location request message to the Home Subscriber Server (HSS), and the HSS records that the terminal is connected under the MME.

Step (6): To begin establishing a transmission path to the default PDN, the MME sends a create session request to the S-GW.

Steps (7) to (8): When the S-GW receives the create session request from the MME, it requests proxy binding update to the P-GW. The P-GW allocates an IP address to the terminal and notifies the S-GW of this information in a proxy binding acknowledgement message. This process establishes a continuous core-network communications path between the P-GW and the S-GW for the allocated IP address.

Step (9): The S-GW prepares a radio access bearer from itself to the eNodeB, and sends a create session response signal to the MME. The create session response signal contains information required to configure the radio access bearer from the eNodeB to the S-GW, including information elements issued by the S-GW and the IP address allocated to the terminal.

Steps (10) to (11) and (13): The MME sends the information in the create session response signal to the eNodeB in an initial context setup request signal. Note that this signaling also contains other notifications such as the attach accept, which is the response to the attach request. When the terminal receives the attach accept in Step (11), it sends an attach complete response to the MME, notifying that processing has completed.

Step (12): The eNodeB establishes the radio data link and sends the attach accept to the terminal. It also configures the radio access bearer from the eNodeB to the S-GW and sends an initial context setup response to the MME. The initial context setup response contains information elements issued by the eNodeB required to establish the radio access bearer from the S-GW to the eNodeB.

Steps (14) to (15): The MME sends the information in the initial context setup response to the S-GW in a modify bearer request signal. The S-GW completes configuration of the previously prepared radio bearer from the S-GW to the eNodeB and sends a modify bearer response to the MME.

Through these steps, a communications path from the terminal to the P-GW is established, enabling communication with the default PDN.

If the terminal performs no communication for a set period of time, the always-on connection function described above releases the radio control link, the LTE radio data link, and the LTE radio access bearer, while maintaining the core network communications path.

After the terminal has established a connection to the default PDN, it is possible to initiate another connection to a different PDN. In this way it is possible to manage PDNs according to service.

For example the IMS PDN, which provides voice services by packet network, could be used as the default PDN, and a different PDN could be used for internet access.

To establish a connection to a PDN other than the default PDN, the procedure is the same as the attach procedure shown in Fig.2, excluding Steps (4) and (5).

TERMS:

Attach: Procedure to register a terminal on the network when, for example, its power is switched on.

Detach: Procedure to remove registration of a terminal from the network when, for example, its power is switched off.

Integrity: Whether the transmitted data is complete and has not been falsified. Here we refer to pre-processing required to ensure integrity of the data.

Bearer: A logical transmission path established, as between the S-GW and eNodeB.

Context setup: Configuration of information required for the communications path and communications management.