Showing posts with label Release 11. Show all posts
Showing posts with label Release 11. Show all posts

Monday 11 February 2013

Revisiting Coordinated Multi-point (CoMP) Technology

Looks like I re-visit CoMP every Q1 of the year. Couple of years back, I had posted a primer on CoMP here and last year I had a slide on schemes and deployments here. With Release-11 out of the door and  Release-12 getting in full swing in the standards, its time to re-visit this topic in a bit more detail. There are couple of presentations, one completely devoted to this topic and one that has a section on it. Both of them can be downloaded from slideshare.


Monday 5 November 2012

3GPP Standards Self Organizing Networks

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



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.

Tuesday 16 October 2012

Extended Access Barring (EAB) in Release 11 to avoid MTC overload

M2M is going to be big. With the promise of 50 Billion devices by 2020, the networks are already worried about the overloading due to signalling by millions of devices occurring at any given time. To counter this, they have been working on avoiding overloading of the network for quite some time as blogged about here.

The feature to avoid this overload is known as Extended Access Barring (EAB). For E-UTRAN, in Rel-10, a partial solution was implemented and a much better solution has been implemented in Rel-11. For GERAN a solution was implemented in Rel-10. The following presentation gives a high level overview of EAB for E-UTRAN and GERAN.



In Rel-11, a new System Information Block (SIB 14) has been added that is used specifically for EAB. Whereas in Rel-10, the UE would still send the RRCConnectionRequest, in Rel-11, the UE does not even need to do that, thereby congesting the Random Access messages.

The following is from RRC 36.331 (2012-09)
***

–                SystemInformationBlockType14

The IE SystemInformationBlockType14 contains the EAB parameters.
SystemInformationBlockType14 information element
-- ASN1START

SystemInformationBlockType14-r11 ::= SEQUENCE {
    eab-Param-r11                        CHOICE {
       eab-Common-r11                       EAB-Config-r11,
       eab-PerPLMN-List-r11                 SEQUENCE (SIZE (1..6)) OF EAB-ConfigPLMN-r11
    }                                                  OPTIONAL, -- Need OR
    lateNonCriticalExtension             OCTET STRING          OPTIONAL, -- Need OP
    ...
}

EAB-ConfigPLMN-r11 ::=               SEQUENCE {
    eab-Config-r11                   EAB-Config-r11            OPTIONAL -- Need OR
}

EAB-Config-r11 ::=               SEQUENCE {
    eab-Category-r11                 ENUMERATED {a, b, c, spare},
    eab-BarringBitmap-r11            BIT STRING (SIZE (10))
}

-- ASN1STOP

SystemInformationBlockType14 field descriptions
eab-BarringBitmap
Extended access class barring for AC 0-9. The first/ leftmost bit is for AC 0, the second bit is for AC 1, and so on.
eab-Category
Indicates the category of UEs for which EAB applies. Value a corresponds to all UEs, value b corresponds to the UEs that are neither in their HPLMN nor in a PLMN that is equivalent to it, and value c corresponds to the UEs that are neither in the PLMN listed as most preferred PLMN of the country where the UEs are roaming in the operator-defined PLMN selector list on the USIM, nor in their HPLMN nor in a PLMN that is equivalent to their HPLMN, see TS 22.011 [10].
eab-Common
The EAB parameters applicable for all PLMN(s).
eab-PerPLMN-List
The EAB parameters per PLMN, listed in the same order as the PLMN(s) occur in plmn-IdentityList in SystemInformationBlockType1.

***

Here is my attempt to explain the difference in overload control mechanism in Rel-8, Rel-10 and Rel-11. Please note that not actual message names are used.





As usual, happy to receive feedback, comments, suggestions, etc.

Tuesday 11 September 2012

New Carrier-Aggregation Proposed Bands

Carrier Aggregation (CA) the promised feature of LTE-A that will make it compatible to IMT-A is not fully exploited in Rel-10. There are only 2 bands supported for CA in Rel-10 and the same for Rel-11. The following are the bands for Rel-10

And the following for Rel-11

Unfortunately these are not enough for all the operators launching LTE/LTE-A. As a result there is currently a study on lots of other bands ongoing within 3GPP. Here is my understanding of the bands that would be needed and the region where they would be needed. Interested in knowing if there are other operators/regions where other bands need to be included.
 

Sunday 26 February 2012

RAN priorities during beyond Release 11 - Video from 3GPP


RAN priorities during beyond Release 11 from 3GPPlive on Vimeo.
An interview with Takehiro Nakamura, 3GPP RAN Chairman, filmed December 2011.

-RAN priorities during early Release 11 work
-Workshop on Rel-12 and beyond, to Identify key requirements
-How does LTE-Advanced change things ?

Related links:



Friday 16 December 2011

Release 12 study item on Continuity of Data Sessions to Local Networks (CSN)

LIPA was defined as part of Release-10 that I have already blogged about. Imagine the situation where a user started accessing local network while camped on the Home eNode B (aka Femtocell) but then moved to the macro network but still wants to continue using the local network. Release 12 defines this feature and is called Continuity of Data Sessions to Local Networks (CSN). This study item was originally part of Release 11 but has now been moved to Rel-12.



From SP-100885:


Justification
Basic functionality for Local IP Access (LIPA) has been specified in Rel-10.
LIPA signifies the capability of a UE to obtain access to a local residential/enterprise IP network (subsequently called a local network) that is connected to one or more H(e)NBs.
The current study item investigates extending LIPA functionality to allow access to the local network when a UE is under coverage of the macro network and provide related mobility support.

LIPA allows a UE to work with devices in the local network – e.g. printers, video cameras, or a local web-server. If the local network offers services that enable exchange of digital content (e.g. UPnP) LIPA allows the UE to discover supporting devices and to be discovered.
Examples for services that become available by LIPA are:
·         The pictures stored in a UE’s digital camera may be uploaded to a local networked storage device or printed out at a local printer.
·         A portable audio player in the UE may fetch new content from a media centre available on the local network.
·         A UE may receive video streams from local surveillance cameras in the home.
·         A local web-server in a company’s intranet may be accessed by the UE.
·         Support of VPN.
LIPA does not require the local network to be connected to the Internet but achieves IP connectivity with the UE through one or more H(e)NBs of the mobile operator.
In Release 10  3GPP has only specified the support of LIPA when the UE accesses the local network via H(e)NB.
On the other hand an operator may, e.g. as a chargeable user service, wish to provide access to the local network also to a UE that is under coverage of the macro network. Access to the local network when a UE is under coverage of the macro network should be enabled in Rel-11.

In Rel-10 it had been required for a UE to be able to maintain IP connectivity to the local network when moving between H(e)NBs within the same local network.
However, access to the local network may be lost as a UE moves out of H(e)NB coverage into the macro network, even if other services (e.g. telephony, data services, SIPTO) survive a handover to the macro network and are continued. This may result in an unsatisfactory user experience.
The current study item will allow continuation of data sessions to the local network when the UE moves between H(e)NB and the macro network.

Therefore, in Rel-11, the 3GPP system requires additional functionality to allow
·         A UE to access the local network from the macro network
·         A UE to maintain continuity of data sessions to the local network when moving between a H(e)NB and the macro network

Objective:              to propose requirements and study feasibility for the following scenarios:
Provide a capability to the mobile operator to allow or restrict
­        Access to an enterprise/residential IP network when a UE is under coverage of the macro network, assuming that the IP address of the local IP network (e.g. residential/enterprise gateway) is available to the UE.
­        Continuity of data session(s) to an enterprise/residential IP network when a UE moves between a H(e)NB in an enterprise/residential environment and the macro network.
The support of Continuity of Data Sessions to Local Networks should be an operator option that may or may not be provided by individual PLMNs.

Service Aspects
The user should be able to decline access to the local network from the macro network. The user should also be able to decline continuity of data sessions to local networks when moving between H(e)NB and the macro network (e.g. in the case when data sessions to local networks is charged differently if accessed from macro coverage or via the H(e)NB).
A difference in QoS may be noticeable by the user when the local network is accessed from the macro network or via the H(e)NB.

Monday 21 November 2011

HSDPA multiflow data transmission

From RP-111375:

HSPA based mobile internet offerings are becoming very popular and data usage is increasing rapidly. As a result, HSPA has begun to be deployed on more than one transmit antenna and/or on more than one carrier. As an example, the single cell downlink MIMO (MIMO-Physical layer) feature was introduced in Release 7. This feature allowed a NodeB to transmit two transport blocks to a single UE from the same cell on a pair of transmit antennas thus improving data rates at high geometries and providing a beamforming advantage to the UE in low geometry conditions. Subsequently, in Release-8 and Release-9, the dual cell HSDPA (DC-HSDPA) and dual band DC-HSDPA features were introduced. Both these features allow the NodeB to serve one or more users by simultaneous operation of HSDPA on two different carrier frequencies in two geographically overlapping cells, thus improving the user experience across the entire cell coverage area.

When a UE falls into the softer or soft handover coverage region of two cells on the same carrier frequency, the link from the serving HS-DSCH cell is capacity or coverage limited and the non-serving cell in its active set has available resources, it would be beneficial to schedule packets to this UE also from the non-serving cell and thereby improve this particular user’s experience.


One family of such schemes parses the incoming data for the user into multiple (restricted to two cells in the study) data streams or flows, each of which is transmitted from a different cell [8] Concurrent transmission of data from the two cells may either be permitted or the UE may be restricted to receiving data from only one cell during a given TTI. The former type of scheme is designated an aggregation scheme while the latter is termed a switching scheme. The aggregation scheme can be seen as subsuming the switching scheme at the network when scheduling to the user is restricted to the cell with better channel quality.

Figure 14 illustrates the basic multi-flow concept with both cells operating on the same carrier frequency F1.




3GPP studied different multipoint transmission options for HSDPA and documented the findings and performance gains in TR25.872 providing feasibility and performance justification for the specification work.

For more details also see:
http://www.3gpp.org/ftp/Specs/html-info/FeatureOrStudyItemFile-530034.htm
See also old blog post on Multipoint HSDPA/HSPA here.

Wednesday 26 October 2011

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:

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

Wednesday 14 September 2011

Inter-technology Carrier Aggregation

Another one from the 4G Americas whitepaper of Mobile Broadband explosion:

Carrier aggregation will play an important role in providing operators maximum flexibility for using all of their available spectrum. By combining spectrum blocks, LTE-Advanced will be able to deliver much higher throughputs than otherwise possible. Asymmetric aggregation (i.e., different amounts of spectrum used on the downlink versus the uplink) provides further flexibility and addresses the fact that currently there is greater demand on downlink traffic than uplink traffic. Specific types of aggregation include:

  • Intra-band on adjacent channels.
  • Intra-band on non-adjacent channels.
  • Inter-band (e.g., 700 MHz, 1.9 GHz).
  • Inter-technology (e.g., LTE on one channel, HSPA+ on another). This is currently a study item for Release 11. While theoretically promising, a considerable number of technical issues will have to be addressed.

Tuesday 13 September 2011

CELL_FACH to LTE Mobility

At the moment, transition from RRC states from UMTS to LTE can happen from CELL_DCH to E-UTRA_RRC_CONNECTED state via Handover or from UTRA_IDLE to E-UTRA_RRC_IDLE via Cell Reselection. There is a study ongoing to transition from CELL_FACH to LTE. The state has not been specified but my guess is that it would probably be E-UTRA_RRC_CONNECTED. The following is the reasoning based on RP-111208:

It is our understanding that some of the Cell_FACH enhancement proposals for Release 11 are targeted to make it more attractive to keep UEs longer in the Cell_FACH state than is expected with pre-Rel-11 devices. This expectation that the UEs may stay longer in the Cell_FACH state is in turn motivating the mobility from Cell_FACH state to LTE proposal.

For instance, as the network can already today release the Cell_FACH UE’s RRC Connection with redirection, network may want to redirect UE to the correct RAT and frequency based on the UE measurement. Specifically if the network strategy is to keep the UEs long time in Cell_FACH state, it would make sense to provide the network the tools to manage the UEs’ mobility in that state. In addition, the needs for mobility to LTE are somewhat different from mobility to e.g. GERAN, as the former would be typically priority based while the latter would happen for coverage reasons. Thus, if introduced, the network controlled mobility from UMTS Cell_FACH would be specifically interesting for the UMTS to LTE case.


Will update once I have more info.

Sunday 4 September 2011

HSPA+ Advanced - Enhancements beyond R10

Looks like Qualcomm is becoming my favourite company as the last few blog posts have been based on their documents and presentations. This one is a continuation of the last post on Multipoint HSPA.

Related post: HSPA evolution – beyond 3GPP Release 10 - Ericsson

Friday 2 September 2011

Multipoint HSDPA / HSPA

The following is from 3GPP TR 25.872 - Technical Specification Group Radio Access Network; HSDPA Multipoint Transmission:

HSPA based mobile internet offerings are becoming very popular and data usage is increasing rapidly. Consequently, HSPA has begun to be deployed on more than one transmit antenna or more than one carrier. As an example, the single cell downlink MIMO (MIMO-Physical layer) feature was introduced in Release 7. This feature allowed a NodeB to transmit two transport blocks to a single UE from the same cell on a pair of transmit antennas thus improving data rates at high geometries and providing a beamforming advantage to the UE in low geometry conditions. Subsequently, in Release-8 and Release-9, the dual cell HSDPA (DC-HSDPA) and dual band DC-HSDPA features were introduced. Both these features allow the NodeB to serve one or more users by simultaneous operation of HSDPA on two different carrier frequencies in two geographically overlapping cells, thus improving the user experience across the entire cell coverage area. In Release 10 these concepts were extended so that simultaneous transmissions to a single UE could occur from four cells (4C-HSDPA).

When a UE falls into the softer or soft handover coverage region of two cells on the same carrier frequency, it would be beneficial for the non-serving cell to be able to schedule packets to this UE and thereby improving this particular user’s experience, especially when the non-serving cell is partially loaded. MultiPoint HSDPA allows two cells to transmit packets to the same UE, providing improved user experience and system load balancing. MultiPoint HSDPA can operate on one or two frequencies.

Click to enlarge

There is also an interesting Qualcomm Whitepaper on related topic that is available to view and download here. The following is from that whitepaper:

The simplest form of Multipoint HSPA, Single Frequency Dual Cell HSPA (SFDC-HSPA), can be seen as an extension to the existing DC-HSPA feature. While DC-HSPA allows scheduling of two independent transport blocks to the mobile device (UE) from one sector on two frequency carriers, SFDC-HSPA allows scheduling of two independent transport blocks to the UE from two different sectors on the same carrier. In other words, it allows for a primary and a secondary serving cell to simultaneously send different data to the UE. Therefore, the major difference between SFDC-HSPA and DC-HSPA operation is that the secondary transport block is scheduled to the UE from a different sector on the same frequency as the primary transport block. The UE also needs to have receive diversity (type 3i) to suppress interference from the other cell as it will receive data on the same frequecny from multiple serving cells.Figure 1 llustrates the high-level concept of SFDC-HSPA.

In the case where the two sectors involved in Multipoint HSPA transmission belong to the same NodeB (Intra-NodeB mode), as illustrated in Figure 2, there is only one transmission queue maintained at the NodeB and the RNC. The queue management and RLC layer operation is essentially the same as for DC-HSPA.

In the case where the two sectors belong to different NodeBs (Inter-NodeB mode), as illustrated in Figure 2, there is a separate transmission queue at each NodeB. RLC layer enhancements are needed at the RNC along with enhanced flow control on the Iub interface between RNC and NodeB in order to support Multipoint HSPA operation across NodeBs. These enhancements are discussed in more detail in Section 4. In both modes, combined feedback information (CQI and HARQ-ACK/ NAK) needs to be sent on the uplink for both data streams received from the serving cells. On the uplink, the UE sends CQIs seen on all sectors using the legacy channel structure, with timing aligned to the primary serving cell.

When two carriers are available in the network, there is an additional degree of freedom in the frequency domain. Dual Frequency Dual Cell HSPA (DFDC-HSPA) allows exploiting both frequency and spatial domains by scheduling two independent transport blocks to the UE from two different sectors on two different frequency carriers. For a DC-HSPA capable UE, this is equivalent to having independent serving cells on the two frequency carriers. In Figure 3, UE1 is in DC-HSPA mode, whereas UE2 is in DFDC-HSPA mode.

Dual Frequency Four-Cell HSPA (DF4C-HSPA) can be seen as a natural extension of DFDC-HSPA, suitable for networks with UEs having four receiver chains. DF4C-HSPA allows use of the four receiver chains by scheduling four independent transport blocks to the UE from two different sectors on two different frequency carriers. DF4C-HSPA is illustrated in Figure 4.

Like SFDC-HSPA; DFDC-HSPA and DF4C-HSPA can also be intra-NodeB or inter-NodeB, resulting in an impact on transmission queue management, Iub flow control and the RLC layer.

Advantages of Multipoint transmission:
* Cell Edge Performance Improvement
* Load balancing across sectors and frequency carriers
* Leveraging RRU and distributed NodeB technology

Multipoint HSPA improves the performance of cell edge users and helps balance the load disparity across neighboring cells. It leverages advanced receiver technology already available in mobile devices compatible with Release 8 and beyond to achieve this. The system impact of Multipoint HSPA on the network side is primarily limited to software upgrades affecting the upper layers (RLC and RRC).