IMB and TDtv (and DVB-H)

Its long time since I blogged about TDtv. Its been quite a while since I heard about TDtv. Apparently its been superseded by IMB, aka. Integrated Mobile Broadcast.

IMB is used to stream live video and store popular content on the device for later consumption. This results in a significant offloading of data intensive traffic from existing 3G unicast networks and an improved customer experience. The multimedia client features an intuitive electronic program guide, channel grid and embedded video player for live TV viewing and video recording. All IMB applications can be quickly and cost-effectively adapted to support all major mobile operating systems and different mobile device types, including smartphones, tablets and e-readers.

IMB was defined in the 3GPP release 8 standards, and was recently endorsed by the GSMA as their preferred method for the efficient delivery of broadcast services. In June 2010, O2, Orange and Vodafone – three of the five major UK mobile operators – announced that they have teamed up for a three-month trial that will explore IMB wireless technology within a tranche of 3G TDD spectrum.

This spectrum already forms part of the 3G licenses held by many European mobile operators, but has remained largely unused because of a lack of appropriate technology. Currently, 3G TDD spectrum is available to over 150 operators across 60 countries, covering more than half a billion subscribers. IMB enables spectrally efficient delivery of broadcast services in the TDD spectrum based on techniques that are aligned with existing FDD WCDMA standards. This enables a smooth handover between IMB and existing 3G networks.

Issues that previously limited uptake of IMB, or IPWireless' tdTV system, have now all been addressed. Namely, the standard now allows for smooth handover between IMB and unicast delivery; has the potential to be integrated onto a single W-CDMA chip rather than requiring a separate chip; and has resolved interference issues with FDD W-CDMA, at least for spectrum in the 1900MHz to 1910MHz range.

IP Wireless already had a trial at Orange and T-Mobile in the UK (which have just agreed to merge), but in that pilot each 5MHz segment only gave rise to 14 TV channels per operator. The new standard could support 40 separate TV channels if two operators shared their TDD spectrum.

The GSMA announced its support and is backed up with additional support from both IPWireless and Ericsson as well as operators Orange, Softbank and Telstra.

There have been recently quite a few bad news for DVB-H and on top of that IP Wireless has announced that Samsung is going to be releasing phones with IMB support so it may be that we will see IMB sometime next year.

The GSMA paper that details IMB service scenarios and System requirements is embedded below:

Integrated Mobile Broadcast (IMB) Service Scenarios and System Requirements

View more documents from Zahid Ghadialy.

Fast Dormancy in Release-8

Nokia Siemens Networks has collaborated with Qualcomm to carry out the industry’s first successful interoperability test of the new 3GPP standardized Release 8 Fast Dormancy feature. Unlike proprietary approaches to fast dormancy, the new standard allows operators to take full advantage of smart network features such as Cell_PCH without worrying that individual handset settings will ignore network controls.

The test was conducted at Nokia Siemens Networks’ Smart Lab in Dallas using Nokia Siemens Networks’ Flexi Multiradio Base Station and Radio Network Controller and Qualcomm’s QSC7230TM smartphone optimized chipset. The test showed how smartphones can act dynamically, exploiting Cell_PCH on Nokia Siemens Networks’ smart networks or adjusting to Fast Dormancy on other vendors’ traditional networks.

In fact the operators have been getting upset quite for some time because of smartphone hacks that save the UE battery life but cause network signalling congestion. See here.

To explain the problem, lets look at the actual signalling that occurs when the UE is not transmitting anything. Most probably it gets put into CELL_PCH or URA_PCH state. Then when keep alive messages need to be sent then the state is transitioned to CELL_FACH and once done its sent back to CELL_PCH. Now the transitioning back from CELL_FACH (or CELL_DCH) to CELL_PCH can take quite some time, depending on the operator parameters and this wastes the UE battery life.

To get round this problem, the UE manufacturers put a hack in the phone and what they do is that if there no data to transmit for a small amount of time, the UE sends RRC Signalling Connection Release Indication (SCRI) message. This message is supposed to be used in case when something is gone wrong in the UE and the UE wants the network to tear the connection down by sending RRC Connection Release message. Anyway, the network is forced to Release the connection.

If there is another requirement to send another keep alive message (they are needed for lots of apps like Skype, IM's, etc.) the RRC connection would have to be established all over again and this can cause lots of unnecessary signalling for the network causing congestion at peak times.

To speed up the transitioning to CELL_PCH state in Release-8 when the UE sends SCRI message, its supposed to include the cause value as "UE Requested PS Data session end". Once the network receives this cause it should immediately move the UE to CELL_PCH state.

This is a win win situation for both the network and the UE vendors as long as a lot of UE's implement this. The good thing is that even a pre-Rel8 UE can implement this and if the network supports this feature it would work.

GSMA has created a best practices document for this feature which is embedded below.

Fast dormancy from Dono Miguel

Further Reading:

• UMTS State Switching and Fast Dormancy Evolution - Martin Sauter
• RP-090941 - System impact of poor proprietary Fast Dormancy implementations
• RP-090942 - Clarification on Enhanced SCRI approach for fast dormancy
• RP-090960 - Configuration of Fast Dormancy
• R2-096882 - Changes to Release-8 Fast Dormanc

LTE Self Optimizing Networks (SON) enhancements for Release-10

Capacity and Coverage Optimisation (CCO) was already nominally part of the Release-9 WI, but could not be completed due to amount of work related to other use cases.

Energy Savings are a very important topic, especially for operators, as solutions derived for this use case can significantly limit their expenses. According to TR 36.902 this solution should concern switching off cells or whole base stations. This may require additional standardised methods, once there is need identified for.

Basic functionality of Mobility Load Balancing (MLB) and Mobility Robustness Optimisation (MRO), also listed in TR 36.902, were defined in Rel.9. However, successful roll-out of the LTE network requires analysing possible enhancements to the Rel.9 solutions for MLB and MRO. In particular, enhancements that address inter-RAT scenarios and inter-RAT information exchange must be considered. These enhancements should be addressed in Rel.10.

There may also be other use cases for LTE for which SON functionality would bring optimisations.

Although, it is of primary interest to provide coverage to users during a roll-out, it is equally important to enhance the capacity of the network during operation. As such, both coverage and capacity are considered in the use case and supported by the SON function. The CCO SON function should be configured through appropriate objectives and targets in order to meet the operator’s requirement on coverage and capacity, and the prioritization between them.

The following use cases and scenarios are planned for Release-10:

Coverage and Capacity Optimisation (CCO)

The use case is to enable detection of following problems:

• Priority 1: coverage problems, e.g. coverage holes

• Priority 2: capacity problems

Mobility Robustness Optimisation (MRO) enhancements

The use case is to enable detection and to provide tools for possible correction of following problems:

• Connection failures in inter-RAT environment:

o Priority 1: at HOs from LTE to UMTS/GSM

o Priority 2: at HOs from UMTS/GSM to LTE

• Obtaining UE measurements in case of unsuccessful re-establishment after connection

failure

• Ping-pongs in idle mode (inter-RAT and intra-LTE environment)

• Ping-pongs in active mode (inter-RAT)

• HO to wrong cell (in intra-LTE environment) that does not cause connection failure (e.g. short stay problem)

Mobility Load Balancing (MLB) enhancements

The use case is to fulfil following objectives:

• Improving reliability of MLB in intra-LTE scenarios

• Improving functionality of the MLB in inter-RAT scenarios (the transport method agreed for R9 should be used for R10).

For more info see 3GPP TS 32.521: Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP); Requirements; Release-10

There is also a Self-Organising Networks Conference that I am attending next month and I plan to give SON lots of coverage before and after the event.

If you havent read the 3G Americas whitepaper on SON, it is definitely worth a read. I have embedded it below.

Benefits of SON in LTE

View more documents from All About 4G

TETRA Evolution

Couple of Interesting presentation on TETRA Evolution.

Network Improvements for Machine Type Communications (NIMTC)

I have blogged about M2M before here.

The Release 10 work item Network Improvements for Machine Type Communications – Stage 1 for NIMTC specified a number of requirements to make the network more suitable for machine type communications. Additional aspects need to be studied before proceeding with their potential inclusion in the normative work.

In the course of the Release 10 work item, it was decided to leave out MTC Device to MTC Device communications from Release 10. This because it was felt it was not possible to do it justice within the Release 10 time frame. Nevertheless, MTC Device to MTC Device communications are expected to become of major importance, especially with consumer devices communicating directly to each other. Therefore, this work item aims to study the network improvements requirements of MTC Device to MTC Device scenarios. A particular aspect of MTC Device to MTC Device scenarios is the identification and functionality needed to set up a connection towards a MTC Device. The IMS domain may provide a solution for this required functionality. In this case the impacts and requirements of MTC on IMS needs to be studied.

Additionally MTC Devices often act as a gateway for a capillary network of other MTC Devices or non-3GPP devices. These gateway MTC Devices may have specific requirements on the mobile network, which have not yet been taken into account in the Release 10 NIMTC work item. Study is needed to determine to what extent improvements are needed and can be specified by 3GPP for MTC Devices that act as a gateway for 'capillary networks' of other devices. Also alignment with what is specified by ETSI TC M2M on this aspect is needed.

Further optimisations may be possible for (groups of) MTC Devices that are co-located. An example of this could be a car with a number of different MTC Devices that always move along together. Optimisations for these kind of scenarios have been suggested, but have not yet been taken into account in the Release 10 NIMTC. Study is needed to determine to what extent network improvements can be specified for co-located MTC Devices.

Because of the different characteristics of Machine-Type Communications, the optimal network for MTC may not be the same as the optimal network for human to human communications. Optimisations of network selections and steering of roaming may be needed. Study is needed to determine to what extent improvements are needed on network selection and steering of roaming for MTC.

Many MTC applications use some kind of location tracking. E.g. the existing LCS framework could be used to provide location information for these kinds of MTC applications. Study is needed to determine to what extent improvements are needed for MTC location tracking.

MTC brings a new concept of a MTC User and MTC Server. So far little attention has been given to service requirements on the communication between the network and the MTC User/MTC Server. Also alignment with what is specified by ETSI TC M2M on that aspect is needed. Study is needed on what kind of service requirements are needed and can be specified by 3GPP.

The Objective of Study on enhancements for Machine-Type Communications item is to study additional requirements, use cases and functionality beyond that specified by the Release 10 NIMTC work item on the following aspects:

• network improvements for MTC Device to MTC Device communications via one or more PLMNs. Note: direct-mode communication between devices is out of scope.

• possible improvements for MTC Devices that act as a gateway for 'capillary networks' of other devices. Note: capillary networks themselves are out of scope of 3GPP.

• network improvements for groups of MTC Devices that are co-located with other MTC Devices

• improvements on network selection mechanisms and steering of roaming for MTC devices

• possible enhancements to IMS to support MTC

• possible improvements for location tracking of MTC Devices

• service requirements on communications between PLMN and the MTC User/MTC Server (e.g. how the MTC User can set event to be monitored with MTC Monitoring);

• possible service requirements to optimize MTC Devices

• possible New MTC Features to further improve the network for MTC

The results of the study will be recorded in a Technical Report. Work ongoing in external standard organization shall be considered (e.g. ETSI M2M, CCSA TC 10).

The European Telecommunications Standards Institute (ETSI) now has a Technical Committee exclusively focused on M2M; the Chinese Communications Standards Association (CCSA) is currently exploring the definition of M2M standards for China and the Geneva-headquartered International Telecommunications Union (ITU) is working on “mobile wireless access systems providing telecommunications for a large number of ubiquitous sensors and/or actuators scattered over wide areas in the land mobile service,” which are at the center of the M2M ecosystem.

Closer to us, the US Telecommunications Industry Association (TIA) has also launched a new engineering committee centered on Smart Device Communications (TIA TR-50). Incidentally, at Global Standards Collaboration 15 (GSC-15), which will be held on August 30- September 2, 2010 in Beijing and hosted by CCSA, the world’s leading telecommunications and radio standards organizations will meet to promote innovation and collaboration on a broad spectrum of standards topics among which M2M has been identified as a “High Interest Subject.”

Related subject on 3GPP here.

M2M workshop is happening in ETSI next week. More details here.

Definitions:

MTC Device: A MTC Device is a UE equipped for Machine Type Communication, which communicates through a PLMN with MTC Server(s) and/or other MTC Device(s).

Local-Access Device: A Local-Access Device is a device in MTC Capillary Network, which has no 3GPP mobile communication capability.

MTC Capillary Network: An MTC Capillary Network is a network of devices that provides local connectivity between devices within its coverage and MTC Gateway Device.

MTC Gateway Device: An MTC Gateway Device is an MTC device equipped for Machine Type Communication, which acts as a gateway for a group of co-located MTC Devices or to connect MTC Devices and/or Local-Access Devices in an MTC Capillary Network to communicate through a PLMN with MTC Server(s), and/or other MTC Device(s).

Further Interesting Reading:

The M2M Switch - turning the wireless business model upside down

MARKET FOR M2M APPLICATIONS EXPLODES

Embedded Mobile M2M Modem Market on Track to More Than Triple in 2010

Recap of Handover procedures in LTE

Interoperability in LTE

View more documents from All About 4G

Is WiFi the real 4G?

Thought provoking presentation...

Wi-Fi is the new 4G

View more presentations from Brough Turner

LTE Video Tutorials on 3g4g

I have added some Video Tutorials on the 3G4G website here. Please scroll to the Video Tutorials section at the bottom of the page.

Alternatively check out Free 2G, 3G, 4G & 5G Training Videos here.

Ultrawideband (UWB) based In-building Location Systems

Continuing on yesterdays theme of Location determination. I have heard in couple of presentations that in future based on multiple RF radios that we will carry, we could be uniquely identified on the planet even though there may not be a single device identifying us uniquely.

A similar project as above but for computers is the Panopticlick project which can be found here.

UBISENSE: UWB Based In-building Location Systems

View more presentations from Zahid Ghadialy.

Locating Wireless Devices Where GPS May Not Be Available

Some of you may have read my earlier posts on stealing spectrum via Femtocells and using Femtocells abroad illegally. This presentation tries to answer one such problem on how do you find the location where GPS cannot be used. This could also be used in case of Cognitive Radios. See my old blog entry here.

OFCOM Locating Wireless Devices where GPS may not be available

View more presentations from Zahid Ghadialy.