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.

Circuit Switched Fallback (CSFB): A Quick Primer

I have explained CSFB with basic signalling here and there is a very interesting Ericsson whitepaper explaining all Voice issues in LTE here.

The following CSFB details have been taken from NTT Docomo Technical Journal:

The basic concept of CS Fallback is shown in Figure 1. Given a mobile terminal camping on LTE, a mobile terminating voice call arrives at the terminal from the existing CS domain via EPC. On receiving a paging message, the mobile terminal recognises that the network is calling the mobile terminal for CS-based voice and therefore switches to 3G. The response confirming the acceptance of a call request is then sent from the mobile terminal to the 3G-CS system, and from that point on, all call control for the voice service is performed on the 3G side.

The CS Fallback consists of a function to notify a mobile terminal of a call request from the CS domain and combined mobility management functions between CS domain and EPC for that

purpose. The network architecture of CS Fallback is shown in Figure 2.

One of the remarkable characteristics of the EPC supporting CS Fallback is that it connects the Mobile Switching Center (MSC) and Visited Location Register (VLR) in the 3G CS domain

with the Mobility Management Entity (MME), which provides EPC mobility management functionality. The interface connecting MSC/VLR and MME is called an SGs reference point. This

interface is based on the concept of the Gs reference point that exchanges signalling with MSC, which connects to the Serving General Packet Radio Service Support Node (SGSN), a 3G

packet switch. The SGs provides nearly all the functions provided by the existing Gs.

The CS Fallback function uses this SGs reference point to transfer the mobile terminating call requests from the CS domain to LTE. It also provides combined mobility management

between the 3G CS domain and the EPC to enable this transfer to take place.

Combined Mobility Management between CS Domain and EPC Network:

A mobile communications network must always know where a mobile terminal is located to deliver mobile terminating service requests to the mobile user on the mobile terminating side. The procedure for determining terminal location is called “mobility management". As a basic function of mobile communications, 3G and LTE each provide a mobility management function.

To complete a call using the CS Fallback function, the CS domain needs to know which LTE location registration area the mobile terminal is currently camping on. To this end, the MME must correlate mobility management control of the CS domain with that of EPC and inform MSC/VLR that the mobile terminal is present in an LTE location registration area.

The 3G core network already incorporates a function for linking mobility management of the CS domain with that of the Packet Switched (PS) domain providing packet-switching functions. As described above, the CS domain and PS domain functions are provided via separate switches. Thus, if combined mobility management can be used, the mobility management procedure for the terminal only needs to be performed once, which has the effect of reducing signal traffic in the network. This concept of combined mobility management is appropriated by the CS Fallback function. Specifically, MSC/VLR uses the same logic for receiving a location registration request from SGSN as that for receiving a location registration request from MME. This achieves a more efficient combined mobility management between the CS domain and EPC while reducing the development impact on MSC.

As described above, a mobile terminal using LTE cannot use 3G at the same time. This implies that the MME, which contains the LTE location registration area (Tracking Area (TA)), is unable to identify which MSC/VLR it should send the mobility management messages to from the TA alone. To solve this problem, the mapping of TAs and 3G Location Areas (LA) within MME has been adopted. The concept behind TA/LA mapping is shown in Figure 3. Here, MME stores a database that manages the correspondence between physically overlapping TAs and LAs. This information is used to determine which MSC/VLR to target for location registration.

The combined TA/LA update procedure for CS fallback is shown in detail in Figure 4. First, the mobile terminal sends to the MME a Tracking Area Update (TAU) request message indicating a combined TAU and the current TA in which the mobile terminal is currently present (Fig. 4 (1)). The MME then performs a location update procedure towards Home Subscriber Server (HSS), which is a database used for managing subscriber profiles (Fig. 4 (2)). Next, the MME uses the TA/LA correspondence database to identify the corresponding LA and the MSC/VLR that is managing that area, and uses the SGs reference point to send a Location Area Update (LAU) request message to the MSC/VLR together with the LA so identified (Fig. 4 (3)). The MSC/VLR that receives the LAU request message stores the correspondence between the ID of the MME originating the request and an ID such as the International Mobile Subscriber Identity (IMSI) that identifies the subscriber (Fig. 4 (4)). This enables the MSC/VLR to know which MME the mobile terminal is currently connected to and that the mobile terminal is camping on LTE. Following this, the MSC/VLR performs a location registration procedure with the HSS (Fig. 4 (5)). Finally, the MSC/VLR informs the MME of temporary user identity (Temporary Mobile Subscriber Identity (TMSI)), which is used at the time of a mobile terminating call in the CS domain, and indicates that location registration has been completed. The MME then informs the mobile terminal of the TMSI and of the LA that the mobile terminal has been registered with thereby completing combined location registration (Fig. 4 (6) (7)).

CS Fallback Call Control Procedures - Mobile Originating Call:

To originate a voice call using the CS Fallback function, a mobile terminal in the LTE location registration area must first switch (fall back) to 3G. The mobile-originating voice call procedure is shown in Figure 5. To originate a call, the mobile terminal begins by sending a CS fallback service request message to the MME (Fig. 5 (1)). Since a packet-communications transmission path (bearer) must always exist in EPC for the purpose of providing an always-on connection, the bearer also has to be handed over to 3G. To accomplish this, the MME issues a handover command to the mobile terminal in LTE and initiates a handover procedure (Fig. 5 (2)). The mobile terminal changes its radio from LTE to 3G during this procedure (Fig. 5 (3)). On completion of handover, the mobile terminal issues an originating request for voice service to the MSC/VLR. A voice-call connection is then established using an existing calloriginating procedure on 3G and the CS Fallback procedure is completed (Fig. 5(4)).

CS Fallback Call Control Procedures - Mobile Terminating Call:

The mobile terminating voice call procedure using CS Fallback is shown in Figure 6. When the MSC/VLR receives a message indicating the occurrence of a mobile terminating call (Fig. 6 (1)), the MSC/VLR identifies the corresponding MME from the call information received (Fig. 6 (2)). Then, the MSC/VLR sends a paging message (Fig. 6 (3)) towards the MME. Next, the MME sends a paging message to the mobile terminal in LTE (Fig. 6 (4)). This paging message includes an indication that the call is a CS service, and on identifying the call as such, the mobile terminal sends a CS fallback service request signal to the MME (Fig. 6 (5)). Following this, a handover procedure to 3G as described above takes place (Fig. 6 (6), (7)). The mobile terminal that is now switched to 3G sends a paging response message to the MSC/VLR at which it is registered (Fig. 6 (8)). Finally, an existing mobile terminating call procedure on 3G is executed and the CS Fallback procedure is completed (Fig. 6 (9)).

Quick primer on Push-to-talk (PTT)

Push to Talk (PTT)

View more documents from Zahid Ghadialy.

MBMS in LTE Release-9

From NTT Docomo Technical Journal:

MBMS is a bearer service for broadcast/multicast transmission of data, to transmit the same information to all interested UEs in an area over a common bearer. Note that MBMS has been supported in UTRA since Release 6.

LTE Release 9 supports basic MBMS functionality not requiring complex control. One of the main features is support for MBMS Single Frequency Network (MBSFN) transmission. With MBSFN transmission eNBs in the MBSFN area transmit the same signal simultaneously using the same time-frequency resource. The UE receives the combined signals as a single, strong signal, improving coverage and signal quality without much additional complexity in the UE. By applying MBSFN transmission, a 3GPP study concluded that to provide 95% coverage with a packet error rate of 1%, a spectral efficiency of 3 bit/s/Hz or greater can be achieved.

The logical architecture for MBMS in LTE is shown in Figure 4. The MBMS gateway (GW) distributes data received from the Broadcast Multicast Service Center (BMSC) to the relevant eNBs by IP multicast. The Multi-Cell Multicast Coordination Entity (MCE) specifies the radio resources to be used by eNBs comprising the MBSFN and ensures that the content is synchronized. To support MBMS, logical channels, namely Multicast Traffic Channel (MTCH) and Multicast Control Channel (MCCH), and a transport channel, namely Multicast Channel (MCH), are defined (Figure 5).

Relation between 3GPP Release-8 and Release-9

Five quick videos from Mobile World Congress 2011 - 3

More on HTC Freestyle and Brew OS here.

More on Live translating service here.

Ps: I know there are 6 videos ;)

Five quick videos from Mobile World Congress 2011 - 2

Facebook onto a SIM using Class 2 SMS

I am sure you have already heard of Gemalto's (worlds largest SIM manufacturer and supplier) Facebook on the SIM announcement. The advantage of this approach is that 100% of the existing phones will be able to support facebook (if the operator supports the application on the SIM). This is a big step0 forward. The press release says:

Gemalto’s software development team has embedded the software application into the SIM. This ensures the Facebook application is compatible with 100% of SIM-compliant mobile phones.

The innovative solution provides mobile subscribers with simple and convenient access to core Facebook features such as friend requests, status updates, wall posts or messages. It also offers unique functions: people can sign up for this service and log in directly from the SIM application. Interactive Facebook messages pop-up on the phone’s screen so people can always share up-to-the-minute posts and events. One can also automatically search their SIM phonebook for other friends and send them requests.

Facebook for SIM is extremely easy to use and is available to everyone. No data contract or application download is needed, because the software is embedded in the SIM and it uses SMS technology. As a result, it works for prepaid as well as for pay-monthly customers. Following an initial limited free trial period, Facebook for SIM then operates on a subscription model via an unlimited pass for a given period of time.

“Facebook for SIM enables operators to leverage two of their main assets: the SMS to communicate with the web application and the SIM for application distribution to the masses,” added Philippe Vallée, Executive Vice President, Gemalto. “Over 200 million people already use Facebook on handsets and those are twice as active as non-mobile users . By providing anytime, anywhere availability to the social network, Gemalto delivers on the growing demand for mobile connectivity all over the world.”

An article on the Register had more details:

The SIM-based client isn't as pretty as its smartphone contemporaries – don't expect picture streams or sliding interfaces – but it was developed with the help of Facebook, and provides text-menu-based interaction with Facebook – including status updates, pokes and friend requests – to any GSM-compatible handset through the magic of the GSM SIM Toolkit and Class 2 SMS messages.

The SIM Toolkit is part of the GSM standard and thus supported on just about every GSM handset, from the dumbest PAYG talker to the latest iGear. It allows the SIM to present menu options to the user, collect responses, and pop up alerts when new data arrives, which is all that's necessary for a basic Facebook client.

Modern handsets also allow the SIM to make TCP/IP data connections, but Gemalto is eschewing that for Class 2 SMS to ensure compatibility with the most basic handsets, and networks.

Class 2 SMS messages are delivered direct to the SIM without the user being involved, so can update friends' status messages and deliver a poke or two. The application running on the SIM then prods the handset into alerting the user.

That user's own updates are sent over SMS too, following a status change or wall posting client pastes that into an SMS, which is sent silently on its way.

How, or if, the network operator charges for all those messages flying about isn't clear. Gemalto won't name operators yet but claims to be talking to one operator who reckons that Facebook is eating half its bandwidth, and another who's already working on SIM distribution strategies.

Not that a new SIM is necessarily required – SIMs are field upgradable, though few operators deploy them with sufficient empty space for an application like this and issuing replacement SIMs is probably easier from a marketing point of view.

You can also find some of these details here.

As I have been working on SMS for the last few weeks, I decided to dig a bit deep into what these Class 2 SMS are.

Classes identify the message's importance as well as the location where it should be stored. There are 4 message classes.

Class 0: Indicates that this message is to be displayed on the MS immediately and a message delivery report is to be sent back to the SC. The message does not have to be saved in the MS or on the SIM card (unless selected to do so by the mobile user).

Class 1: Indicates that this message is to be stored in the MS memory or the SIM card (depending on memory availability).

Class 2: This message class is Phase 2 specific and carries SIM card data. The SIM card data must be successfully transferred prior to sending acknowledgement to the SC. An error message will be sent to the SC if this transmission is not possible.

Class 3: Indicates that this message will be forwarded from the receiving entity to an external device. The delivery acknowledgement will be sent to the SC regardless of whether or not the message was forwarded to the external device.

You can also read this for more details on SMS message contents

Five quick videos from Mobile World Congress 2011

Follow the latest action in Mobile World Congress at Twitter here.

Non-Voice Emergency Services (NOVES)

Its been a while we talked about SMS for Emergency purposes and eCall. A new study item in 3GPP has looked at non-voice alternatives for Emergency purposes.

Picture Source: Dailymail

The following is from the recent 4G Americas report entitled: 4G Mobile Broadband Evolution: 3GPP Release-10 and Beyond:

Non-verbal communications such as text messaging and instant messaging via wireless devices has been very successful and continues to expand. Many of the consumers assume that they can utilize these types of non-verbal communications as mechanisms to communicate with emergency services whenever emergency assistance is required. Such mechanisms currently do not exist. The Emergency Services community has a desire to have multimedia emergency services supported with the same general characteristics as emergency voice calls.

Currently, service requirements for emergency calls (with or without the IP Multimedia Core Network) are limited to voice media. The Non-Voice Emergency Services (NOVES) is intended to be an end-to-end citizen to authority communications. NOVES could support the following examples of non-verbal communications to an emergency services network:

1. Text messages from citizen to emergency services

2. Session-based and session-less instant messaging type sessions with emergency services

3. Multimedia (e.g., pictures, video clips) transfer to emergency services either during or after other communications with emergency services.

4. Real-time video session with emergency services

In addition, to support the general public, this capability would facilitate emergency communications to emergency services by individuals with special needs (e.g., hearing impaired citizens).

The objectives of this study include the following questions for NOVES with media other than or in addition to voice:

1. What are the requirements for NOVES?

2. What are the security, reliability, and priority handling requirements for NOVES?

3. How is the appropriate recipient emergency services system (e.g., PSAP) determined?

4. What are the implications due to roaming?

5. Are there any implications to hand over between access networks?

6. Are there any implications due to the subscriber crossing a PSAP boundary during NOVES communications (e.g., subsequent text messages should go to the same PSAP)?

7. Do multiple communication streams (e.g., voice, text, video emergency services) need to be associated together?

8. What types of “call-back” capabilities are required?

9. What are the load impacts of NOVES in the case of a large scale emergency event or malicious use?

NOVES will be applicable to GPRS (GERAN, UTRAN) and to EPS (GERAN, UTRAN, E-UTRAN and non-3GPP). The content may be transmitted between the subscribers and the emergency services which might bring new security issues. Therefore, the security impacts need to be studied.

You can spend your weekend reading the 3GPP Study Item TR 22.871: Study on Non-Voice Emergency Services (Release 11).

A word of caution, the name NOVES may be changed in future as Emergency agencies in Europe have an objection to the name. See here and here.

Smarter Cars of the Future

We all know that cars are getting smarter. Back in Oct., Google unveiled the cars that can drive by themselves. I am sure they will make our life much better and we will be able to catch on the sleep at early morning commute.

Then there were quite a few futuristic cars at the CES 2011 last month. One such video is embedded below.

The following is a summary from the an IEEE article:

Cars have been getting smarter for years, studded with suites of sensors and supporting electronics aimed at keeping them from crashing. But entertainment and convenience have rapidly caught up to safety as the impetus for new in-car electronics development. Because automakers typically spend three years developing and producing new cars—and new gadget candy to go with them—they’ve found themselves constantly playing catch-up with consumer electronics and consumer expectations. So car companies have teamed up with the makers of smartphone software platforms to integrate a spectacular array of apps designed for handsets with cars’ digital dashboards, center consoles, and speaker systems.

Take for instance Ford’s new Focus all-electric vehicle, which made a big splash at the 2011 International Consumer Electronics Show in Las Vegas last month. It features a software application called MyFord Mobile.

The app, which runs on Ford’s proprietary Sync platform and is compatible with the BlackBerry, iPhone, and Android devices, links the car with the driver’s smartphone and home computer. The software lets the driver listen to a smartphone’s music library and lets passengers watch movies or TV shows. It delivers information such as when electricity prices are at their lowest (to allow for the cheapest battery recharging) and where the nearest charging stations are. And it allows a smartphone to function as a remote control, by means of a connection to cloud-based servers. This remote communication lets the handset keep tabs on the car’s location and the batteries’ state of charge. It will also let the driver start the Focus EV from indoors on a blustery January morning, then step into a car whose seats and steering wheel are already warm. The MyFord Mobile app lets the driver remotely start the car, turn on the heater or air conditioner, or unlock the doors from anywhere in the world (including beneath the bedcovers).

And because the system differentiates one driver’s key from another’s, it presents information on the reconfigurable 4-inch screens on either side of the speedometer in the current driver’s preferred color and style. The state of charge, for example, could be shown as a percentage of the full charge, as an estimate of the remaining miles before recharging, or as a simple bar that gets shorter as the batteries’ energy is consumed. This differentiation also works for utility and entertainment options; it automatically queues up driver A’s list of radio station presets, favorite mobile apps, and preferred display options for the 8-inch center console touch screen. Because MyFord Mobile links the Focus to the driver’s handset, it can also access his or her contact list for hands-free calling and read out e-mails and texts through the car’s speakers.

Ford is trying to position itself as a technological leader in the automotive industry with MyFord Mobile and Sync AppLink Voice Control, which puts the driver in control of all the Sync system’s capabilities via voice commands, but it has stiff competition from the likes of Mercedes-Benz, Continental, and Toyota. Launched by Mercedes-Benz in November 2009, the Mbrace system, designed and engineered by Hughes Telematics of Atlanta, was the first telematics service on the market to give smartphones the power to remotely lock, unlock, or locate a car. It didn’t signal a revolution in the way the average driver interacts with his or her vehicle because when the German luxury vehicle maker offers a new technology or set of features, there is usually a multiyear wait for them to trickle down to cars whose sticker prices aren’t stratospheric.

The second generation of Mbrace debuted last September. It introduced Mercedes-Benz Concierge, which not only opens the car to information from the outside but also makes some car-based information and entertainment options portable. The Mbrace Mobile Application 2.0 gives iPhone and Blackberry users single-phone-number access to recommendations for nearby entertainment and restaurant options, directions, traffic updates, and more, whether the person is in the car or not. The concierge then sends destination information to the smartphone or directly to the in-vehicle navigation system. With the Mbrace system’s latest wrinkle, the Drive2Friend service, the driver can dictate a friend’s mobile number and the app sends a text message reporting that the driver is trying to find the person. The friend has the option of allowing his or her location to be sent back to the car via cellular triangulation.

While Ford was showing off its wares at CES, Continental was also there showcasing the Android-based AutoLinQ system, which lets the driver connect to the car in three ways.

AutoLinQ’s Mobile View lets you to send text messages to your car; the smart vehicle can text you back with information such as its location. In this demo [Flash video], a smartphone user is shown making a remote inquiry about the status of his car. Mobile View reports that the sunroof is open and offers the option to close it or ignore the warning. When he taps Close on the handset’s touch screen, the sunroof’s glass panel glides shut. This type of call-and-response vehicle update also tells whether doors are closed and locked and whether the headlights or interior lights are on. Mobile View doesn’t wait for a query to alert the driver when the alarm is triggered, the battery is depleted, the air bag has been activated, or the internal temperature of the car is too high or low. And like MyFord Mobile, it turns the smartphone into a remote control for locking and unlocking the doors, starting the engine, flashing the lights, and more.

AutoLinQ’s Home View lets you download apps and configure vehicle settings from your home computer. Clickable tabs at the bottom of the Home View screen let the car owner move through screens showing a wealth of data on the car’s status, driver preferences, navigation information, and applications that can be downloaded or fine-tuned. The status menu tells whether the ignition is on and displays the fuel and motor oil levels, the pressure for each of the four tires, and much, much more.

Car View, in AutoLinQ, is for updating features from the driver’s seat. Car View provides the same information as Home View but lets the driver use the center console touch screen to download apps on the fly that provide better control of the car and the ability to remotely manipulate electronic devices back home. An app that sends an alert when a game or match in the driver’s favorite sport is about to appear on television also gives the option to activate a digital video recorder at home, pull up a Web site featuring periodic updates about the game, or listen to play-by-play on the radio.

Continental is also designing unique apps that will enhance vehicle performance. For instance, the Filling Assistant will detect underinflated tires and notify the driver. When the driver goes to inflate the tires, the Filling Assistant will report pressure information to the driver’s smartphone and honk the car’s horn or flash its lights to indicate when a tire has enough air.

Not to be left out, Toyota, the world’s leading automaker, debuted the QNX-based Entune at CES 2011. Entune is an upgradable suite of entertainment, navigation, and information functions. "Consumers have grown accustomed to having the world at their fingertips through their mobile phones," says Jon Bucci, vice president of Toyota’s advanced technology department, who notes that putting them in the car is a natural evolution.

After downloading the Toyota Entune app to a handset and syncing it with the Toyota vehicle, the driver can begin accessing content and services, including Bing for Web navigation and OpenTable, which can make reservations at any one of 15 000 restaurants, with directions sent seamlessly to the navigation system and information appearing on the center console. Entune also lets a driver get customizable real-time traffic updates, sports, weather, stocks, and information on prices at local fueling stations. The system doesn’t forget music, which has almost always been a part of the driving experience. Entune includes Iheartradio, which delivers roughly 750 local radio stations at the touch of a button.

The tide of apps extending handset capabilities to cars will only continue to rise. ABI Research, in Oyster Bay, N.Y., reports that the number of users of automotive apps will increase from 1.4 million in 2010 to more than 28 million by 2015. And according to Global Industry Analysts, the vehicle telematics market is expected to reach US $11.2 billion by 2015.

You can read the complete article here.

In other news, Robots in future will have their own Internet and content like Wikipedia, etc. Does anyone else remember 'The Terminator'?