eMPS: Enhanced Multimedia Priority Service in Release-10 and beyond

The response to emergency situations (e.g., floods, hurricanes, earthquakes, terrorist attacks) depends on the communication capabilities of public networks. In most cases, emergency responders use private radio systems to aid in the logistics of providing critically needed restoration services. However, certain government and emergency management officials and other authorised users have to rely on public network services when the communication capability of the serving network may be impaired, for example due to congestion or partial network infrastructure outages, perhaps due to a direct or indirect result of the emergency situation.

Multimedia Priority Service, supported by the 3GPP system set of services and features, is one element creating the ability to deliver calls or complete sessions of a high priority nature from mobile to mobile networks, mobile to fixed networks, and fixed to mobile networks.

Requirements for the Multimedia Priority Service (MPS) have been specified in TS 22.153 for the 3GPP Release-9

The intention of MPS is to enable National Security/Emergency Preparedness (NS/EP) users (herein called Service Users) to make priority calls/sessions using the public networks during network congestion conditions. Service Users are the government-authorized personnel, emergency management officials and/or other authorized users. Effective disaster response and management rely on the Service User’s ability to communicate during congestion conditions. Service Users are expected to receive priority treatment, in support of mission critical multimedia communications.

LTE/EPC Release 9 supports IMS-based voice call origination by a Service User and voice call termination to a Service User with priority. However, mechanisms for completing a call with priority do not exist for call delivery to a regular user for a priority call originated by a Service User. MPS enhancements are needed to support priority treatment for Release 10 and beyond for call termination and for the support of packet data and multimedia services.

MPS will provide broadband IP-based multimedia services (IMS-based and non-IMS-based) over wireless networks in support of voice, video, and data services. Network support for MPS will require end-to-end priority treatment in call/session origination/termination including the Non Access Stratum (NAS) and Access Stratum (AS) signaling establishment procedures at originating/terminating network side as well as resource allocation in the core and radio networks for bearers. The MPS will also require end-to-end priority treatment in case of roaming if supported by the visiting network and if the roaming user is authorized to receive priority service.

MPS requirement is already achieved in the 3G circuit-switched network. Therefore, if the network supports CS Fallback, it is necessary to provide at least the same capability as 3G circuit switched-network in order not to degrade the level of voice service. In CS Fallback, UE initiates the fallback procedures over the LTE as specified in TS 23.272 when UE decides to use the CS voice service for mobile originating and mobile terminating calls. To achieve priority handling of CS Fallback, NAS and AS signaling establishment procedures, common for both IP-based multimedia services and CS Fallback, shall be treated in a prioritized way.

In Release-10, for LTE/EPC, the following mechanisms will be specified.

• Mechanisms to allocate resources for signaling and media with priority based on subscribed priority or based on priority indicated by service signaling.
• For a terminating IMS session over LTE, a mechanism for the network to detect priority of the session and treat it with priority.

In Release-10, for CS Fallback, the following mechanism will be specified:

• A mechanism to properly handle the priority terminating voice call and enable the target UE to establish the AS and NAS connection to fall-back to the GERAN/UTRAN/1xRTT.

For more information, see:

3GPP TR 23.854: Enhancements for Multimedia Priority Service (Release 10)

3GPP TS 22.153: Multimedia priority service (Release 10)

10 business models that rocked 2010

Very interesting read!

10 business models that rocked 2010 - by @nickdemey (boardofinnovation.com)

View more presentations from Board of Innovation (BOI).

3GPP Tutorials via 'The SpecTools'

Some of you may have noticed that the new and revamped 3GPP website have recently started offering 3GPP specs and features tutorials via The SpecTools. There is quite a lot of useful information and most of it is premium but a lot is free as well.

So the new starters or those wishing to refresh their knowledge feel free to check this out:

http://www.thespectool.com/3gpp/index.php

Heterogeneous LTE Networks and Inter-Cell Interference Coordination

An interesting paper that is more of a background to my earlier post here is available from Nomor Research and is embedded below.

Heterogeneous LTE Networks and Inter-Cell Interference Coordination

View more documents from Zahid Ghadialy.

This paper is available to download from here.

RAN mechanisms to avoid CN overload due to MTC

Machine-to-Machine (M2M) is the future and Machine-type communications (MTC) will be very important once we have billions of connected devices. I have talked in the past about the 50 Billion connected devices by 2050 and the Internet of Things.

One of the challenges of today's networks is to handle this additional signalling traffic due to MTC. One of the very important topics being discussed in 3GPP RAN meetings is 'RAN mechanisms to avoid CN overload due to MTC'. Even though it has not been finalised, its interesting to see the direction in which things are moving.

The above figure from R2-106188 shows that an extended wait time could be added in the RRC Connection Reject/Release message in case if the eNodeB is overloaded. The device can reattempt the connection once the wait time has expired.

In R2-110462, another approach is shown where Core Network (CN) is overloaded. Here a NAS Request message is sent with delay tolerant indicator a.k.a. low priority indicator. If the CN is overloaded then it can reject the request with a backoff timer. Another approach would be to send this info to the eNodeB that can do a RRC Connection Reject when new connection request is received.

All Documents from 3GPP RAN2 #72-bis are available here. Search for NIMTC for M2M related and overload related docs.

More Dilbert Humour on Cloud Computing

When I posted a Dilbert cartoon on the weekend, I expected lots of people to click on 'Not Useful' box at the bottom of the post. Honestly I got more response than I expected. Now with Cloud being talked about everywhere, I thought it would be worthwhile sticking some more old Dilbert Cloud crackers.

To combine fun with work, there are some links as well pointing to some recent Cloud based articles. Enjoy!

Ericsson CTO: cloud computing + mobile connectivity = mind-blowing innovation

Look up, it's the future: Learning to love 'the cloud'

CES2011: NEC dual-screen Android Cloud Communicator LT-W hands-on

How the Wikimedia Foundation is Using OpenStack to Build a Cloud Infrastructure

Security researcher uses Amazon cloud to hack WPA-PSK passwords

Data security must improve for the cloud to succeed

Efficiency drive will grow government outsourcing and cloud usage, says Ovum

Introducing Windows Azure

Source of Cartoons: http://dilbert.com/

SI on Signalling and procedure for interference avoidance for in-device coexistence

In order to allow users to access various networks and services ubiquitously, an increasing number of UEs are equipped with multiple radio transceivers. For example, a UE may be equipped with LTE, WiFi, and Bluetooth transceivers, and GNSS receivers. One resulting challenge lies in trying to avoid coexistence interference between those collocated radio transceivers. Figure 4-1 below shows an example of coexistence interference.

3GPP initiated a Study Item (SI) in Release-10 timeframe to investigate the effects of the interference due to multiple radios and signalling. This study is detailed in 3GPP TR 36.816 (see link at the end).

Due to extreme proximity of multiple radio transceivers within the same UE, the transmit power of one transmitter may be much higher than the received power level of another receiver. By means of filter technologies and sufficient frequency separation, the transmit signal may not result in significant interference. But for some coexistence scenarios, e.g. different radio technologies within the same UE operating on adjacent frequencies, current state-of-the-art filter technology might not provide sufficient rejection. Therefore, solving the interference problem by single generic RF design may not always be possible and alternative methods needs to be considered. An illustration of such kind of problem is shown in Figure 4-2 above.

The following scenarios were studied:

- LTE coexisting with WiFi

- LTE coexisting with Bluetooth

- LTE Coexisting with GNSS

Based on the analysis in SI, some examples of the problematic coexistence scenarios that need to be further studied are as follows:

- Case 1: LTE Band 40 radio Tx causing interference to ISM radio Rx;

- Case 2: ISM radio Tx causing interference to LTE Band 40 radio Rx;

- Case 3: LTE Band 7 radio Tx causing interference to ISM radio Rx;

- Case 4: LTE Band 7/13/14 radio Tx causing interference to GNSS radio Rx.

In order to facilitate the study, it is also important to identify the usage scenarios that need to be considered. This is because different usage scenarios will lead to different assumption on behaviours of LTE and other technologies radio, which in turn impact on the potential solutions. The following scenarios will be considered:

1a) LTE + BT earphone (VoIP service)

1b) LTE + BT earphone (Multimedia service)

2) LTE + WiFi portable router

3) LTE + WiFi offload

4) LTE + GNSS Receiver

The SI also proposes some ways of reducing the interference and is work in progress at the moment.

Reference: 3GPP TR 36.816 : Study on signalling and procedure for interference avoidance for in-device coexistence; (Release 10).

Dilbert Humour: Cloud Computing

Source: Dilbert

If you like these then please click 'Very Useful' or 'More like this' so that I know people find these useful.

For similar things follow the label: Mobile Humour.

LTE-Advanced (Rel-10) UE Categories

I blogged about the 1200Mbps of DL with LTE Advanced earlier and quite a few people asked me about the bandwidth, etc. I found another UE categories table in Agilent lterature on LTE-Advanced here.

The existing UE categories 1-5 for Release 8 and Release 9 are shown in Table 4. In order to accommodate LTE-Advanced capabilities, three new UE categories 6-8 have been defined.

Note that category 8 exceeds the requirements of IMT-Advanced by a considerable

margin.

Given the many possible combinations of layers and carrier aggregation, many configurations could be used to meet the data rates in Table 4. Tables 5 and 6 define the most probable cases for which performance requirements will be developed.

Refresher: LTE MAC Layer Protocol

This is following the RLC refresher post here. You can also view logs from real tests on a real LTE UE here.

3GPP LTE-MAC

View more presentations from praveenkmr78.