Monday 15 November 2010

HTML5 for Mobile Devices

I had been recently talking to some developers about the programming and App development on mobiles and quite a few people are of the opinion that HTML5 may help the mobile Apps go to the next level.

The biggest problem HTML5 is supposed to solve is write once run anywhere applicatons. Most of the programs will have the same look and feel if they are run on a PC or mobile and between different devices.

Ofcourse not everything is perfect. There are yet many API's that need to be implemented in for HTML5 like the 3D and Mic API's, etc. Another problem is that a lot of phones are not yet supporting HTML5 and some of them that are supporting, not supporting it completely. This will have to be solved asap.

The following is a recent presentation from Ericsson on HTML5 that gives a good idea on why it is a good idea.
Another interesting place to look for some HTML5 stuff is Patrick Chanezon's html5 Bookmarks

Thursday 11 November 2010

UEInformationRequest/UEInformationResponse - New RRC messages in Release-9

As is obvious from the title, The UE information procedure is used by E-UTRAN to request the UE to report information [1].

There are two different scenarios for the Network to send the UEInformationRequest message to the UE. One is to find out the number of RACH preambles it needed for the random access procedure and the other is to get the measurement information when a Radio Link Failure (RLF) occurred.

[2] also provides the following detail:

The network may poll for the UE report after a successful random access procedure (UEInformationRequest) and the UE responds with the number of preambles sent by MAC for the last successfully completed random access procedure and whether contention is detected by MAC for at least one of the transmitted preambles for the last successfully completed random access procedure (UEInformationResponse).

Source:

[1] 3GPP TS 36.331 V9.3.0: Radio Resource Control (RRC); Protocol specification - Section 5.6.5

[2] 3GPP TR 36.902 V9.2.0: Self-configuring and self-optimizing network (SON) use cases and solutions

Wednesday 10 November 2010

Proximity Indication - New RRC Uplink Message in Rel-9

The inbound handover from a Macro eNB to an HeNB (a.k.a. Femtocell) is not supported in Release 8. Before making a handover decision to a HeNB, the Macro eNB needs to acquire UE measurement information related to the so-called target CSG cell. Nevertheless, UEs cannot continuously make measurements and read the system information of lots of CSG cells in cases of large scale HeNB deployments.

In order to allow the UE to make those measurements efficiently, a newly defined proximity report can be configured within the RRC Reconfiguration message. This proximity report will allow the UE to send a so-called “proximity indication” to the source eNB in the uplink whenever it is entering or leaving the proximity of one or more cells with CSG IDs that the UEs has in its CSG Whitelist.

A UE that is able to determine that it is near its CSG cell can thus inform the network to take the necessary actions for handover preparation. The detection of proximity is based on an autonomous search function.

The source eNB, upon receiving the proximity indication, might ask the UE to perform measurements of the CSG cell, to read the System Information (SI) or, in case it already has all required information, it might already start the handover procedure. PCI (Physical Cell Identification) confusion is resolved in Release 9. The eNB will ask the UE to report the global cell identity. As usual the UE reporting is using the RRC measurement procedures. The ovell procedure is illustrated in Figure below.

In summary five basic steps can be identified:
1. Proximity configuration/reporting
2. HO measurement configuration/reporting
3. Resolution of PCI confusion by requesting and reporting System Information
4. Access Control in the network
5. HO execution

Since the CSG search can be very slow there are no strict requirements on the inbound handover performance, which can range from one to several 10’s of seconds.

Since the proximity information is based on UE signaling, the network might be receiving a lot of proximity indications, increasing the network load. Therefore, it was agreed to limit proximity indications a UE can send within a certain time frame. A timer, called the prohibit proximity timer, was introduced.

Source:

Monday 8 November 2010

Single Radio Voice Call Continuity (SR‐VCC)

From a 3GPP presentation by Hannu Hietalahti

1. SR-VCC use case
1a. IMS call initiated in LTE can continue in CS domain after moving outside of LTE coverage area
1b. SR-VCC is invoked if no other VoIP capable PS system (e.g., HSPA/eHRPD) is available for VoIP PS-PS HO (Handovers)
1c. Only HO of a single voice bearer from PS to CS is specified
1d. Requires overlapping with 1xRTT/GSM/WCDMA coverage

2. SR-VCC allows a voice calls are anchored in IMS
2a. One-way HO from PS to CS systems (LTE to GSM/UMTS or LTE to 1xRTT)
2b. No simultaneous operation of different radio transceivers needed

3. Rel-9 SR-VCC improvements
3a. IMS support of mid call services (e.g., HOLD, MPTY)
3b. SR-VCC support for emergency calls

4. Video calls, reverse direction from CS call to IMS and optimisations are being studied in Rel-10

Saturday 6 November 2010

LTE CS Fallback Procedure

From a 3GPP presentation by Hannu Hietalahti:

1. CS FallBack from EPS to CS domain
2. CSFB reuses voice and other CS-domain services provided by legacy CS infrastructure
3. EPS redirects the UE to CS Domain for CS services
3a. SMS can be delivered to the UE without redirecting to CS Domain
3b. After CS service the UE returns to LTE, depending on coverage and policy
4. User can decide, based on CLI, whether to accept CSFB request
5. Application of CSFB:
5a. CS capable device camping on LTE cell can establish/receive CS services
5b. Reuse of existing CS infrastructure for voice service until IMS VoIP is deployed
5c. Provide voice roaming support with LTE
5d. Support E911 using existing CS infrastructure
5e. Rel-9 IMS provides full emergency call support
5f. Requires overlapping CS domain coverage

Note: CSFB applies between LTE and GSM, WCDMA and 1xRTT


Thursday 4 November 2010

Emergency Calls in LTE/SAE Release-9


From a 3GPP presentation by Hannu Hietalahti:

Emergency calls in LTE

Regulatory requirement of emergency calls is supported in Rel-9 for LTE:
1. Detection of emergency numbers in UE
2. Indication and prioritisation of emergency calls
3. Location services, both for routing and user location data for PSAP (Public Safety Answering Point)
4. Callback is possible, but processed as normal call without exceptions

UE matches digits dialledby the user with list of known emergency numbers
1. Emergency number list in the UE is common for CS and PS domain use
2. Default 112 and 911, USIM pre-configuration, downloaded in MM procedure
3. In case of match, the UE shall initiate the call as an emergency call

In IMS emergency calls the UE translates dialled number into emergency service URN
1. Service URN with a top-level service type of "sos" as specified in RFC5031
2. Additionally, sub-service type can be added to indicate emergency category if information on the type of emergency service is known (fire, ambulance, police,…)

P-CSCF (Proxy - Call Session Control Function) must also be prepared to detect emergency call if the UE is not aware of local emergency call
1. This is backup for those cases when the (roaming) UE does not have full information of all local emergency call numbers and initiates a normal call
2. From EPC perspective, it will be a normal PDN connection

Benefit of location information
1. P-CSCF discovers the regionally correct PSAP to take the emergency call
2. PSAP gets information on the precise user location


Related Posts:

Wednesday 3 November 2010

'Wi-Fi Direct': New Standard and competition to Femtocells and Bluetooth


Last month when I blogged about WiFi as 4G, i got mixed reactions. Some suggesting that WiFi is just a filler till Femtocells become prevalent and others suggested that in future all devices would with 3G/HSPA/LTE/4G enabled so there may be no need for WiFi.

Well, yesterday I read about the new Wi-Fi Direct (formerly known as 'Wi-Fi Peer-to-Peer') standard that is supposed to make WiFi devices easier to operate with other WiFi devices. I havent explored the security options but I am sure they are well thought out.

Before we go further, you may want to check out the WiFi Direct official video below:



There is an interesting piece in PC World that compares Bluetooth 4.0 with Wi-Fi Direct. I am sure soon both these camps would be listing the merit of their standards and dissing the other one. According to the Register, Bluetooth never really took off in the US. They think Wi-Fi has bigger clout and this would translate to WiFi Direct success.

WiFi Alliance has a recently revised FAQ on Wi-Fi Direct here. Very interesting read. A Media presentation is embedded below and can be downloaded from Slideshare here.

The devices have already started undergoing certification and commercial devices should be available by the end of this year.

Finally, while there is a lot of debate going on about WiFi v/s Femtocells and I respect everyone's views and arguments on this debate, I think Wi-Fi direct may give a kicking to the Femtocell manufacturers where it hurts the most.

One of the strong arguments in the favour of Femtocell is the seamless roaming. With Wi-Fi direct you may be able to seamlessly connect to various Wi-Fi devices and Access points. This certainly counts big time in their favour.

Certainly the gate is still wide open for some Femtocell based killer apps which would turn the tide in their favour but for now I am looking forward to some Wi-Fi direct devices.