eMBMS Physical layer aspects from T&M point of view

Based on the success of the recent posts on eMBMS, here and here, this final post on this topic is a look at physical layer perspective from Test and Measurement point of view. Slides kindly provided by R&S

eMBMS: Broadcast and Multicast in LTE from Zahid Ghadialy

A video of this is also available on Youtube, embedded below:

CSFB Performance

Here is another presentation from Qualcomm from the '4G World'.

CSFB Performance from Zahid Ghadialy

With regards to SI Tunneling mentioned in the presentation, I found the following in another Qualcomm whitepapers:


With Release 9 Enhanced Release with Redirection—SI Tunneling, the device follows 3GPP release 9, where SIB information can be tunneled from the target Radio Access Network (RAN) via the core network to the source RAN and be included in the redirection message sent to the device. This can avoid reading any SIBs on the target cell. 

The predominant solutions deployed today are based on Release 8 Release with Redirection — SIB Skipping, in order to achieve good call setup times, good reliability, and simplify deployments. It is anticipated that Release 9 Enhanced Release with Redirection will be deployed in the near future. At this time, there is not as much push for handover-based CSFB since both Release 8 Release with Redirection—SIB Skipping and Release 9 Enhanced Release with Redirection—SI Tunneling have largely addressed any call setup time issues that may have existed with the Basic Release with Redirection solution.

I have blogged on this topic before, here.

More on Dual Radio here and SVLTE here.

3GPP Standards Self Organizing Networks

The following is a presentation by 3GPP on Self-Organising Networks in the SON Conference 2012:

3GPP Standards Self Organizing Networks from Zahid Ghadialy

A basic tutorial on SON is available also on 3GPP website here.

A detailed list of 3GPP work items on SON is available to view and download from here.

HSPA+ Evolution: Standards and Data Rates

From the 4G Americas white paper.

Updated LTE Architecture with LCS and MBMS entities

Here is an attempt to update the LTE Architecture with MBMS and Location Services (LCS) entities included

You can also refer to the following old posts:

• Simplifying LTE/SAE Interfaces
• 3GPP Official 'MBMS support in E-UTRAN' - Mar 2011
• MBMS in LTE Release-9

3GPP System Building on Releases

Evolution of 3GPP Security

Reducing CSFB Timing with RRC R9 Optimisations

While in the initial testing CSFB timing used to be between 6-8 seconds, most Rel-8 phones can complete the CSFB procedure between 4-4.5 seconds. Unfortunately this is still a lot in terms of signalling. To reduce this in Rel-9 there is a simple optimisation that has been done.

In the RRC Connection Release message, there is a possibility to add UTRAN/GERAN System Information messages. In the picture above, I have only shown UTRA System Information but a similar picture can be drawn for GERAN.

Once all the Mandatory SIB's are sent to the UE then it can immediately camp on without the need to read any other additional system info. This will reduce the CSFB time between 1-2 seconds.

The lesser the CSFB time, the better the Quality of end user experience

New 4G Americas whitepaper on HSPA evolution in 3GPP standards

Some forecasts put HSPA at over 3.5 billion subscribers by the end of 2016. Operators with HSPA and LTE infrastructure and users with HSPA and LTE multi-mode devices will be commonplace. There are 412 commercial deployments of HSPA in 157 countries, including 165 HSPA+ networks. Thus, with the continued deployment of LTE throughout the world, and the existing ubiquitous coverage of HSPA in the world, HSPA+ will continue to be enhanced through the 3GPP standards process to provide a seamless solution for operators as they upgrade their networks. While LTE, with 33 commercial deployments to date and over 250 commitments worldwide, will be the mobile broadband next generation technology of choice for HSPA, EV-DO, WiMAX and new wireless operators, HSPA will continue to be a pivotal technology in providing mobile broadband to subscribers.

The white paper explains that as 3GPP specifications evolve, their advanced features help to further the capabilities of today’s modern mobile broadband networks. With each release there have been improvements such as better cell edge performance, increased system efficiencies, higher peak data rates and an overall improved end-user experience. 3GPP feature evolution from Rel-7 to Rel-10 has pushed possible HSPA peak data rates from 14 Mbps to 168 Mbps. Continued enhancements in 3GPP Rel-11 will again double this capability to a possible peak data rate of 336 Mbps:

• Rel-7: 64QAM or 2X2 MIMO => 21 or 28 Mbps
• Rel-8: DC + 64QAM or 2X2 MIMO + 64QAM => 42 Mbps
• Rel-9: DC + 2X2 MIMO + 64QAM => 84 Mbps
• Rel-10: 4C + 2X2 MIMO + 64QAM => 168 Mbps
• Rel-11: (8C or 4X4 MIMO) + 64QAM => 336 Mbps

“If operators are able to gain new additional harmonized spectrum from governments, they will no doubt deploy LTE, However, it is clear that HSPA+ technology is still exceptionally strong and will continue to provide operators with the capability to meet the exploding data usage demands of their customers in existing spectrum holdings,” Pearson said.

The paper is embedded as follows:

The Evolution of HSPA

View more documents from All About 4G

This paper and other similar papers are available to download from the 3G4G website here.

Self-Evolving Networks (SEN): Next step of SON

In a post last year, I listed the 3GPP features planned for the Self-Organising networks. Self-optimisation has been a part of the SON. It is becoming more of a common practice to refer to SON as Self-Optimising networks. A recent 4G Americas whitepaper was titled "Benefits of self-optimizing networks in LTE".

The next phase in the evolution of the Self-Configuring, Self-organizing and Self-optimizing network are the Self-Evolving Networks (aka. SEN) that will combine the Organizing and Optimizing features with the Self-testing and Self-Healing features. Self-testing and Self-healing have been recommended as subtasks of SON in the NGMN white paper. Self-testing and self-healing means that a system detects itself problems and mitigates or solves them avoiding user impact and significantly reducing maintenance costs.

We may still be a long way away from achieving this SEN as there are quite a few items being still standardised in 3GPP. Some of the standardised items have not yet been fully implemented and tested as well. Some of this new features that will help are listed as follows:

Automatic Radio Network Configuration Data Preparation (Rel-9)

When radio Network Elements (e.g. cells and/or eNBs) are inserted into an operational radio network, some network configuration parameters cannot be set before-hand because they have interdependencies with the configuration of operational NEs. "Dynamic Radio Network Configuration Data Preparation" comprises the generation and distribution of such interdependent parameters to the newly inserted network element and optionally already operational NEs.

This functionality allows fully automatic establishment of an eNB into a network. Otherwise an operator needs to set these configurations manually. Without this functionality self-configuration cannot be considered not fully as "self".

SON Self-healing management (Rel-10)

The target of Self-Healing (SH) is to recover from or mitigate errors in the network with a minimum of manual intervention from the operator.

Self-healing functionality will monitor and analyse relevant data like fault management data, alarms, notifications, and self-test results etc. and will automatically trigger or perform corrective actions on the affected network element(s) when necessary. This will significantly reduce manual interventions and replace them with automatically triggered re-s, re-configurations, or software reloads/upgrades thereby helping to reduce operating expense.

LTE Self Optimizing Networks (SON) enhancements (Rel-10)

This WI continues work started in Rel-9. Some cases that were considered in the initial phases of SON development are listed in the TR 36.902. From this list, almost all use cases are already specified. Capacity and Coverage Optimization (CCO) was already nominally part of the Rel-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 Optimization (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 optimizations. The upcoming LTE-A brings about also new challenges that can be addressed by SON. However, since not all features are clearly defined yet, it is difficult to work on SON algorithms for them. It is therefore proposed to assign lower priority to the features specific for LTE-A.

UTRAN Self-Organizing Networks (SON) management (Rel-11)

For LTE, SON (Self-Organizing Networks) concept and many features have been discussed and standardised.

The SON target is to maintain network quality and performance with minimum manual intervention from the operator. Introducing SON functions into the UTRAN legacy is also very important for operators to minimize OPEX.

Automatic Neighbour Relation (ANR) function, specified in the LTE context, automates the discovery of neighbour relations. ANR can help the operators to avoid the burden of manual neighbour cell relations management.

Self-optimization functionalities will monitor and analyze performance measurements, notifications, and self-test results and will automatically trigger re-configuration actions on the affected network node(s) when necessary.

This will significantly reduce manual interventions and replace them with automatically triggered re-optimizations or re-configurations thereby helping to reduce operating expenses.

Minimization of Drive Tests (MDT) for E-UTRAN and UTRAN is an important topic in 3GPP Rel-10.

With the help of standardized UTRAN MDT solutions, Capacity and Coverage Optimization (CCO) for UTRAN should also be considered in UTRAN SON activities.

Study on IMS Evolution (Rel-11)

IMS network service availability largely relies on the reliability of network entity. If some critical network elements (e.g. S-CSCF, HSS) go out of service, service availability will be severely impacted. Moreover network elements are not fully utilized because network load is not usually well distributed, e.g. some nodes are often overloaded due to sudden traffic explosion, while others are under loaded to some extent. Though there’re some element level approaches to solve these problems, such as the ongoing work in CT4, the system level solution should be studied, for example, the method to distribute load between network elements in different regions especially when some disaster happens, such as earthquake.

The network expansion requires a great deal of manual configurations, and the network maintenance and upgrade are usually time-consuming and also costly for operators. Introducing self-organization features will improve the network intelligence and reduce the efforts of manual configuration. For example, upon discovering the entry point of the network, new nodes can join the network and auto-configure themselves without manual intervention. And if any node fails, other nodes will take over the traffic through the failed node timely and automatically.

The above mentioned features are just few ways in which we will achieve a truly zero-operational 4G network.

MRO: Handover failures signalling

Continuing on the Self-organising Network (SON) feature of Mobility Robust Optimisation, Handover failures.

Click on image to enlarge

One of the discussions I had with a colleague is how would the signalling happen in case of Handover failures I mentioned earlier.

After the handover failure, when the connection is successfully established again either as a normal Setup or Re-Establishment or RRC Reconfiguration then a new optional field is available:

rlf-InfoAvailable-r10 ENUMERATED {true} OPTIONAL,

This is used to indicate to the network that the UE has some information relating to the RL Failure that occurred.

The network will then use the UE Information Request I blogged about earlier to ask for this information. The UE will send the information back in the response.

It should be noted that this UEInformationRequest and Response messages were introduced part of Release-9 but there has been since some updates in Release-10. The Response message now looks as follows:

RLF-Report-r9 ::= SEQUENCE {

measResultLastServCell-r9 SEQUENCE {

rsrpResult-r9 RSRP-Range,

rsrqResult-r9 RSRQ-Range OPTIONAL

},

measResultNeighCells-r9 SEQUENCE {

measResultListEUTRA-r9 MeasResultList2EUTRA-r9 OPTIONAL,

measResultListUTRA-r9 MeasResultList2UTRA-r9 OPTIONAL,

measResultListGERAN-r9 MeasResultListGERAN OPTIONAL,

measResultsCDMA2000-r9 MeasResultList2CDMA2000-r9 OPTIONAL

} OPTIONAL,

...,

[[ locationInfo-r10 LocationInfo-r10 OPTIONAL,

failedPCellId-r10 CHOICE {

cellGlobalId-r10 CellGlobalIdEUTRA,

pci-arfcn-r10 SEQUENCE {

physCellId-r10 PhysCellId,

carrierFreq-r10 ARFCN-ValueEUTRA

}

} OPTIONAL,

reestablishmentCellId-r10 CellGlobalIdEUTRA OPTIONAL,

timeConnFailure-r10 INTEGER (0..1023) OPTIONAL,

connectionFailureType-r10 ENUMERATED {rlf, hof} OPTIONAL,

previousPCellId-r10 CellGlobalIdEUTRA OPTIONAL

]]

}

Everything after the extension marker ellipses (...) is added in release 10. More information in Release-10 RRC specs (36.331)

Advanced IP Interconnection of Services (IPXS) in 3GPP Rel-11

The following is edited from the 3GPP documents:

IP is being introduced in both fixed and mobile networks as a more cost-effective alternative to circuit switched technology in the legacy PSTN/PLMN, as well as the underpinning transport for delivering IMS based multi-media services.

In order to ensure carrier grade end to end performance, appropriate interconnect solutions are required to support communications between users connected to different networks. There are currently a number of initiatives underway outside 3GPP addressing IP Interconnection of services scenarios and commercial models to achieve this; for example, the GSM Association has developed the IPX (IP Packet Exchange). Also, ETSI has recently defined requirements and use case scenarios for IP Interconnection of services. These initiatives require the use of appropriate technical solutions and corresponding technical standards, some of which are already available and others which will require development in 3GPP.

Moreover, new models of interconnection may emerge in the market where Network Operators expose network capabilities to 3rd party Application Providers including user plane connectivity for the media related to the service.

The main objective of IPXS is thus:

To specify the technical requirements for carrier grade inter-operator IP Interconnection of Services for the support of Multimedia services provided by IMS and for legacy voice PTSN/PLMN services transported over IP infrastructure (e.g. VoIP).

These technical requirements should cover the new interconnect models developed by GSMA (i.e. the IPX interconnect model) and take into account interconnect models between national operators (including transit functionality) and peering based business trunking.

Any new requirements identified should not overlap with requirements already defined by other bodies (e.g. GSMA, ETSI TISPAN). Specifically the work will cover:

• Service level aspects for direct IP inter-connection between Operators, service level aspects for national transit IP interconnect and service level aspects for next generation corporate network IP interconnect (peer-to-peer business trunking).

• Service layer aspects for interconnection of voice services (e.g. toll-free, premium rate and emergency calls).

• Service level aspects for IP Interconnection (service control and user plane aspects) between Operators and 3rd party Application Providers.

To ensure that requirements are identified for the Stage 2 & 3 work to identify relevant existing specifications, initiate enhancements and the development of the new specifications as necessary.

The following is a related presentation on Release-8 II-NNI with an introduction to Rel-9 and Rel-10 features.

II-NNI in the 3GPP standard

View more presentations from Zahid Ghadialy

The 3GPP references can be seen from the presentation above.

European Commission conducted a study on this topic back in 2008 and produced a lengthy report on this. Since the report is 187 pages long, you can also read the executive summary to learn about the direction in technical, economic and public policy.

User Data Convergence (UDC) in Release 9 and its evolution

The below is mish-mash from the specs (see refrences at the end)

With the increase of service entities and the resulting user data types, User Data Convergence (UDC) is required to ensure the consistency of storage and data models.

UDC:

• simplifies the overall network topology and interfaces

• overcomes the data capacity bottleneck of a single entry point

• avoids data duplication and inconsistency

• reduces CAPEX and OPEX.

UDC simplifies creation of new services and facilitates service development and deployment though a common set of user data.

UDC promotes service and network convergence to support the increasing number of new services including Internet services and UE applications. A new facility User Data Repository (UDR) is considered for UDC.

In UDC, all the user data is stored in a single UDR allowing access from core and service network entities.

To achieve high performance, reliability, security and scalability, the UDR entity may consist of a network of different components distributed geographically, and exposes capabilities via open interfaces in multiple access entry points.

In the current 3GPP system, user data are scattered in several domains (e.g. CS, PS, IMS) and different network entities (e.g. HLR, HSS, Application Servers). With the increase of user data entities and the resulting data types, it is more difficult for integrated services to access necessary user information from plural entities.

The scenario mentioned herein is kind of called “User Data Silo”, which is the major paradigm of user data deployment for the time being, as illustrated by Fig.1. below

With the user data silos, user data are independently accessed, stored and managed independently. That brings many challenges to network deployment and evolution. Different user data access interfaces impose complexity on network topology as well as on application development, especially for booming Internet services and incoming IP-based UE applications; separated user data increases management workload. Moreover, new networks and services such as IMS are expected, so that the introduction of their user data only makes things worse, not to mention network and service convergence even if those user data have a lot in common and are correlated to each other. Separation also undermines the value of user data mining.

User data convergence is required to ensure the consistency of storage and data models. User data convergence will simplify overall network topology and interfaces, overcome the data capacity bottleneck of a single entry point, avoid data duplication and inconsistency and reduce CAPEX and OPEX. Also it will simplify the creation of new services and facilitate service development and deployment though a common set of user data. Finally it will promote service and network convergence to support the increasing number of new services including Internet services and UE applications. In this regard, a new facility User Data Repository (UDR) should be considered for user data convergence.

As illustrated by Fig. 2 above, User Data Convergence, as opposed to User Data Silo, is simply to move the user data from where it belonged, to a facility here called User Data Repository (UDR) where it can be accessed, stored and managed in a common way. Despite of the diversity of user data structures for different services, user data can be decomposed and reformed by a common data model framework (e.g. tree-like data model, rational data model) provided by UDR. In that case, user data categorized by services can be regrouped and identified by user ID, leaving no data redundancy. Also, convergence in data model will unify the user data access interface and its protocol, which will promote new service application development. Thereby, the capability of user data convergence can be open to creation of data-less applications.

There are plenty of data distributed in the 3GPP system which is used to perform the services, for instance, the configuration data of a network entity, the session data of a multimedia call, the IP address of a terminal, etc. With respect to user data, it refers to all kinds of the information related to users who make use of the services provided by the 3GPP system.

In 3GPP system, user data is spread widely through the different entities (e.g. HLR, HSS, VLR, Application servers) and also the type of user data is various. It is of paramount importance to categorize the user data before going through the convergence of user data.

The UDC shall support multiple application user data simultaneously, e.g. HSS and others.

Any application can retrieve data from the UDC and store data in it. The applications shall be responsible of updating the UDC with the dynamic changes of the user profile due to traffic reasons (e.g. user status, user location…) or as a consequence of subscriber procedures.

User Subscription Data: Before a user can enjoy a service, he may need to subscribe the service first. The subscription data relates to the necessary information the mobile system ought to know to perform the service. User identities (e.g. MSISDN, IMSI, IMPU, IMPI), service data (e.g. service profile in IMS) , and transparent data (data stored by Application Servers for service execution) are the examples of the subscription data. This kind of user data has a lifetime as long as the user is permitted to use the service and may be modified during the lifetime. User may be accessed and configured via various means, e.g. customer service, web interface, UE Presence service. The subscription data is composed of different types such as authentication data, configuration data, etc. Different type of data may require different levels of security.

User content Data: Some applications may have to store content defined by the user and that here may be quite large (e.g. Photos, videos) User content data can reach very high volume (e.g. Hundreds of Mbytes and more), and the size required to store them may largely vary over time. They generally do not require the real time constraints as user profile data may require. Storage of user data content is not typically subject of UDR. Storage of user data content is not typically subject of UDR. UDC on user content data can be achieved by converging them with links or references, such as URLs, to other entity.

User Behaviour Data: Such data concerns the usage of services by a user as services are consumed. Generally there are event data records that can be generated on various events in the usage of services by a user and that can be used not only for charging or billing purposes but e.g. for user profiling regarding user behaviour and habits, and that can be valuable for marketing purposes. The amount of such data is also quite different from other categories, they present a cumulative effect as such data can be continuously generated by the network implying a need for corresponding storage. Usage data may require real time aspects about their collection (e.g. for on line charging), they are also often characterized by a high amount of back office processing (e.g. Billing, user profiling). Processing of user behaviour data such as for CRM, billing, data mining is not typically subject of UDR. Those might be processed with lower priority or by external systems whereby UDR supports mass data transfer.

User Status Data: This kind of user data contains call-related or session-related dynamic data (e.g. MSRN, P-TMSI), which are typically stored in VLR or SGSN. These dynamic data are only used by their owner transitorily and proprietarily, and hardly shared by other services in the short term.

Figure 4.1-1 below presents the reference UDC architecture. UDC is the logical representation of the layered architecture that separates the user data from the application logic, so that user data is stored in a logically unique repository allowing access from entities handling an application logic, hereby named Application Front Ends.

In the architecture, the User Data Repository (UDR) is a functional entity that acts as a single logical repository of user data and is unique from Application Front End’s perspective. Entities which do not store user data and that need to access user data stored in the UDR are collectively known as application front ends.

NOTE: Depending on the different network deployment, there may be more than one UDC in an operator’s network.

Application Front Ends (FE) connect to the UDR through the reference point named Ud to access user data.

Figure 4.1-2 shows how the UDC reference architecture is related to the overall network architecture by comparing a Non-UDC Network with an UDC Network. In the non-UDC Network, the figure shows NEs with their own database storing persistent user data and a NE accessing an external database; in both cases, when UDC architecture is applied, the persistent user data are moved to the UDR and concerned NEs are becoming Application-FEs (NE-FEs) according to the UDC architecture. This figure also shows that network interfaces between NEs are not impacted .A Network Element (NE), which in its original form represents application logic with persistent data storage, when the UDC architecture is applied, may become a NE Front End, since the related persistent data storage is moved to the UDR.

3GPP TS 23.335 gives more details and information flows for User Data Convergence

Further evolution of UDC is being studied part of 3GPP TR 23.845. The TR tries to address the assumption of multiple UDRs in a PLMN, to identify consequences and the possible impacts on existing UDC specifications. From a practical point of view, even if the aim is to have one single logical repository, a certain number of considerations may drive to have more than one UDR in a PLMN.

For very large networks with a very large amount of users, although an UDR may be implemented in a distributed architecture and multiple database servers with geographical distribution and geographical redundancy, an operator may consider to deploy several UDRs between which it will distribute the users.

More details in the technical report.

References:

3GPP TR 22.985: Service requirement for the User Data Convergence (UDC) (Release 9)

3GPP TS 23.335: User Data Convergence (UDC); Technical realization and information flows; Stage 2 (Release 10)

3GPP TS 29.335: User Data Convergence (UDC); User Data Repository Access Protocol over the Ud interface; Stage 3 (Release 10)

3GPP TS 32.182: User Data Convergence (UDC); Common Baseline Information Model (CBIM) (Release 10)

3GPP TR 32.901: Study on User Data Convergence (UDC) information model handling and provisioning: Example Use Cases (Release 11)

3GPP TR 29.935: Study on UDC Data Model.

3GPP TR 23.845: Study on User Data Convergence (UDC) evolution (Release 10)

3GPP Official 'MBMS support in E-UTRAN' - Mar 2011

Last month I blogged about the MBMS feature in Rel-9. The 3GPP official presentation on MBMS is now available. Embedded below:

MBMS support in E-UTRAN - March 2011

View more presentations from Zahid Ghadialy

Presentation can be downloaded from Slideshare.

This presentation was a part of Joint one hour session of 3GPP RAN and 3GPP CT on March 16th 2011, 11.00 am – 12.00 p.m. More on this coming soon.

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

VoLTE: Semi-Persistent Scheduling (SPS) and TTI Bundling

The following is from the recently released 4G Americas paper '4G Mobile Broadband Evolution: 3GPP Release-10 and beyond:

With the support of emergency and location services in Rel-9, interest in Voice over LTE (VoLTE) has increased. This is because the Rel-9 enhancements to support e911 were the last step to enable VoLTE (at least in countries that mandate e911) since the Rel-8 specifications already included the key LTE features required to support good coverage, high capacity/quality VoLTE. There are two main features in Rel-8 that focus on the coverage, capacity and quality of VoLTE: Semi-Persistent Scheduling (SPS) and TTI Bundling.

SPS is a feature that significantly reduces control channel overhead for applications that require persistent radio resource allocations such as VoIP. In LTE, both the DL and UL are fully scheduled since the DL and UL traffic channels are dynamically shared channels. This means that the physical DL control channel (PDCCH) must provide access grant information to indicate which users should decode the physical DL shared channel (PDSCH) in each subframe and which users are allowed to transmit on the physical UL shared channel (PUSCH) in each subframe. Without SPS, every DL or UL physical resource block (PRB) allocation must be granted via an access grant message on the PDCCH. This is sufficient for most bursty best effort types of applications which generally have large packet sizes and thus typically only a few users must be scheduled each subframe. However, for applications that require persistent allocations of small packets (i.e. VoIP), the access grant control channel overhead can be greatly reduced with SPS.

SPS therefore introduces a persistent PRB allocation that a user should expect on the DL or can transmit on the UL. There are many different ways in which SPS can setup persistent allocations, and Figure below shows one way appropriate for VoLTE. Note that speech codecs typically generate a speech packet every 20 ms. In LTE, the HARQ interlace time is 8 ms which means retransmissions of PRBs that have failed to be decoded can occur every 8 ms. Figure below shows an example where a maximum of five total transmissions (initial transmission plus four retransmissions) is assumed for each 20 ms speech packet with two parallel HARQ processes. This figure clearly shows that every 20 ms a new “first transmission” of a new speech packet is sent. This example does require an additional 20 ms of buffering in the receiver to allow for four retransmissions, but this is generally viewed as a good tradeoff to maximize capacity/coverage (compared to only sending a maximum of two retransmissions).

The example in Figure above can be applied to both the DL and UL and note that as long as there are speech packets arriving (i.e. a talk spurt) at the transmitter, the SPS PRBs would be dedicated to the user. Once speech packets stop arriving (i.e. silence period), these PRB resources can be re-assigned to other users. When the user begins talking again, a new SPS set of PRBs would be assigned for the duration of the new talkspurt. Note that dynamic scheduling of best effort data can occur on top of SPS, but the SPS allocations would take precedent over any scheduling conflicts.

TTI bundling is another feature in Rel-8 that optimizes the UL coverage for VoLTE. LTE defined 1 ms subframes as the Transmission Time Interval (TTI) which means scheduling occurs every 1 ms. Small TTIs are good for reducing round trip latency, but do introduce challenges for UL VoIP coverage. This is because on the UL, the maximum coverage is realized when a user sends a single PRB spanning 180 kHz of tones. By using a single 180 kHz wide PRB on the UL, the user transmit power/Hz is maximized. This is critical on the UL since the user transmit power is limited, so maximizing the power/Hz improves coverage. The issue is that since the HARQ interlace time is 8 ms, the subframe utilization is very low (1/8). In other words, 7/8 of the time the user is not transmitting. Therefore, users in poor coverage areas could be transmitting more power when a concept termed TTI bundling (explained in the next paragraph) is deployed.

While it’s true that one fix to the problem is to just initiate several parallel HARQ processes to fill in more of the 7/8 idle time, this approach adds significant IP overhead since each HARQ process requires its own IP header. Therefore, TTI bundling was introduced in Rel-8 which combined four subframes spanning 4 ms. This allowed for a single IP header over a bundled 4 ms TTI that greatly improved the subframe utilization (from 1/8 to 1/2) and thus the coverage (by more than 3 dB).

Martin Sauter puts it in a simpler way in his blog as follows: The purpose of TTI Bundling is to improve cell edge coverage and in-house reception for voice. When the base station detects that the mobile can't increase it's transmission power and reception is getting worse it can instruct the device to activate TTI bundling and send the same packet but with different error detection and correction bits in 2, 3 or even 4 consecutive transmit time intervals. The advantage over sending the packet in a single TTI and then detecting that it wasn't received correctly which in turn would lead to one or more retransmissions is that it saves a lot of signaling overhead. Latency is also reduced as no waiting time is required between the retransmissions. In case the bundle is not received correctly, it is repeated in the same way as an ordinary transmission of a packet. Holma and Toskala anticipate a 4dB cell edge gain for VoIP with this feature which is quite a lot. For details how the feature is implemented have a look at 3GPP TS 36.321.

A whitepaper explaining the concepts of TTI Bundling is available on Slideshare here.

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)

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.

eICIC: Enhanced inter-cell interference coordination in 3GPP Release-10

Inter-cell interference coordination (ICIC) was introduced in Release-8/9 of the 3GPP LTE standards. The basic idea of ICIC is keeping the inter-cell interferences under control by radio resource management (RRM) methods. ICIC is inherently a multi-cell RRM function that needs to take into account information (e.g. the resource usage status and traffic load situation) from multiple cells.

Broadly speaking, the main target of any ICIC strategy is to determine the resources (bandwidth and power) available at each cell at any time. Then (and typically), an autonomous scheduler assigns those resources to users. Thus, from the Radio Resource Control perspective, there are two kind of decisions: (a) which resources will be allocated to each cell? and, (b) which resources will be allocated to each user?. Clearly, the temporality of such decisions is quite different. Whereas resources to users allocation is in the order of milliseconds, the allocation of resources to cells take much longer periods of time or can be fixed.

Static ICIC schemes are attractive for operators since the complexity of their deployment is very low and there is not need for new extra signaling out of the standard. Static ICIC mostly relies on the fractional reuse concept. This means that users are categorized according to their Signal-to-Noise-plus-Interference Ratio (SINR), that means basically according to their inter-cell interference, and different reuse factors are applied to them, being higher at regions with more interference, mostly outer regions of the cells. The total system bandwidth is divided into sub-bands which are used by the scheduler accordingly.

A simple way to explain ICIC is based on picture above. The users are divided into two categories, one is Cell Center User (CCU), and the other one is Cell Edge User (CEU). CCUs are the users distributed in the gray region of above figure, and CEUs are the users distributed in the above red, green and blue areas. CCU can use all the frequencypoints to communicate with the base station, while CEU must use corresponding specified frequency points to ensure orthogonality between different cells.

CEUs can be assigned a higher transmissionpower for the frequency reuse factor is greater than 1. The frequency points are not overlapped at the edges so the adjacent cell interference is small. CCU’s frequency reuse factor is 1; for the path loss is small and transmission power is low. Therefore the interference to the adjacent cells is not high either.

Dominant interference condition has been shown when Non-CSG/CSG users are in close proximity of Femto, in this case, Rel8/9 ICIC techniques are not fully effective in mitigating control channel interference, and hence, Enhanced interference management is needed At least the following issues should be addressed by any proposed solutions:

o Radio link monitoring (RLM)

o Radio Resource Management (including detection of PSS/SSS and PBCH)

o Interference from CRS

oo To PCFICH/PHICH/PDCCH

oo To PDSCH

o CSI measurement

o Interference from PDCCH masked with P-RNTI and SI-RNTI (for SIB-1 only) and associated PCFICH

As a result, from Release-10 onwards eICIC work was started. In Rel-10, two eICIC or Enhanced inter-cell interference coordination (also incorrectly referred to as Enhanced Inter-Cell Interference Cancellation) were being actively discussed. They are Time domain eICIC and autonomous HeNB power setting. More advanced ideas are being thought of beyong Rel-10 including Interference management techniques on carrier resolution ( optimally exploiting available Networks frequency assets (carriers in same or different bands) , combination with Carrier Aggregation; interference management schemes proposed both during LTE-Advanced Study Item phase, and during Rel-10 HetNet eICIC work.

From an earlier presentation in SON Conference:

eICIC:

- Effectively extends ICIC to DL control - time domain

- Requires synchronization at least between macro eNB and low power eNBs in its footprint

- No negative impact on legacy Rel 8 Use

Range Extension(RE)

- Refers to UE ability to connect and stay connected to a cell with low SINR

- Achieved with advanced UE receivers - DL interference cancellation (IC)

RE + eICIC technique:

– Eliminates coverage holes created by closed HeNBs

– Improves load balancing potential for macro network with low power eNBs and leads to significant network throughput increase

–Enables more UEs can be served by low power eNBs, which can lead to substantially higher network throughput

More details on eICIC is available in 3GPP CR's and TR's listed below:

• R1-105081: Summary of the description of candidate eICIC solutions, 3GPP TSG-WG1 #62, Madrid, Spain, August 23rd – 27th, 2010.
• R1-104942: Views on eICIC Schemes for Rel-10, 3GPP TSG RAN WG1 Meeting #62, Madrid, Spain, 23-27 August, 2010.
• R1-104238: eICIC Chairman’s note, 3GPP TSG RAN WG1 Meeting #61bis, Dresden, Germany, 28th June – 2nd July 2010.
• R1-103822: Enhanced ICIC considerations for HetNet scenarios, 3GPP TSG RAN WG1 #61bis Meeting, Dresden, Germany, June 28 – July 2, 2010.

You can also check out NTT Docomo's presentation on LTE Enhancements and Future Radio Access here.