Advancements in Congestion control technology for M2M

NTT Docomo recently published a new article (embedded below) on congestion control approaches for M2M. In their own words:

Since 3GPP Release 10 (Rel. 10) in 2010, there has been active study of technical specifications to develop M2M communications further, and NTT DOCOMO has been contributing proactively to creating these technical specifications. In this article, we describe two of the most significant functions standardized between 3GPP Rel. 10 and Rel. 11: the M2M Core network communications infrastructure, which enables M2M service operators to introduce solutions more easily, and congestion handling technologies, which improve reliability on networks accommodating a large number of terminals.

Complete article as follows:

Core Network Infrastructure and Congestion Control Technology for M2M Communications from Zahid Ghadialy

Other related posts:

• Rise of the "Thing"
• Access Class Barring in LTE using System Information Block Type 2
• Extended Access Barring (EAB) in Release 11 to avoid MTC overload
• RAN mechanisms to avoid CN overload due to MTC
• Service Specific Access Control (SSAC) in 3GPP Release 9

SIPTO Evolution

Couple of years back I did a post on SIPTO (Selected IP Traffic Offload) and related technologies coming as part of Rel-10. I also put up a comparison for SIPTO, LIPA and IFOM here. Having left it for couple of years, I found that there have been some enhancements to the architecture from the basic one described here.

I have embedded the NEC paper below for someone wanting to investigate further the different options shown in the picture above. I think that even though the operator may offload certain type of traffic locally, they would still consider that data as part of the bundle and would like to charge for it. At the same time there would be a requirement on the operator for lawful interception, so not sure how this will be managed for different architectures. Anyway, feel free to leave comments if you have any additional info.

NEC: Mobile Traffic Offload from Zahid Ghadialy

ANDSF: Evolution and Roaming with Hotspot 2.0

Access Network Discovery and Selection Function (ANDSF) is still evolving and with the introduction of Hotspot 2.0 (HS 2), there is a good possibility to provide seamless roaming from Cellular to Wi-Fi, Wi-Fi to Wi-Fi and Wi-Fi to Cellular.

There is a good paper (not very recent) by Alcatel-Lucent and BT that explains these roaming scenarios and other ANDSF policies related information very well. Its embedded below:

Push to talk (PTT) via eMBMS

I was talking about push to share back in 2007 here. Now, in a recent presentation (embedded below) from ALU, eMBMS has been suggested as a a solution for PTT like services in case of Public safety case. Not sure if or when we will see this but I hope that its sooner rather than later. Anyway, the presentation is embedded below. Feel free to add your comments:

eMBMS for Public Safety from Zahid Ghadialy

Cell Range Expansion (CRE)

The intention of the Pico Cells is to offload traffic from the Macro cells to increase the system capacity. As a result, when Macro cell becomes overloaded, it would make sense to offload the MUE’s in the vicinity of the Pico cell to it. This can/should be done even if the UE is receiving a better signal from the Macro cell. The expansion of the range of the Pico cell is termed as CRE or Cell Range expansion.

To make sure that the UE does not fail in the handover process, the Time domain ICIC should be used and Macro cell should use ABS. The UE’s can be configured to do measurements on the Pico when the Macro is using ABS. The MUE now reports the Measurement reports to the Macro and are handed over to the Pico to act as PUE.

LTE-A: Downlink Transmission Mode 9 (TM-9)

When LTE was introduced in Release-8 it had 7 transmission modes that were increased to 8 in Release-9. Earlier, I posted an R&S whitepaper on the different Transmission modes (10K+ views already) that listed transmission modes till TM 8. In Release-10 (LTE-A) 3GPP Introduced a new transmission mode, TM 9. TM9 is designed to help reduce interference between base stations to maximise signal stability and boost performance. The new TM-9 enables the enhancement of network capabilities and performance with minimum addition of overhead. TM9 is designed to combine the advantages of high spectrum efficiency (using higher order MIMO) and cell-edge data rates, coverage and interference management (using beamforming). Flexible and dynamic switching between single-user MIMO (SU-MIMO) and an enhanced version of multi-user MIMO (MU-MIMO) is also provided.

A new Downlink Control Information (DCI) format - known as format 2C - is used for TM9 data scheduling. Two new reference signals are defined in TM9: Channel State Information Reference Signal (CSI-RS) and Demodulation Reference Signal (DMRS). The first is used from the UE to calculate and report the CSI feedback (CQI/PMI/RI), while the latter is an evolution - providing support for more layers - of the UE specific reference signal that is already used for beamforming in Rel-9, and is used for signal demodulation. TM-9 is particularly smart as it can detect when a mobile device is being used and send a different type of signal that is optimal for a mobile device (variable DM-RS – demodulation reference signals). This maximises the efficient use of the base station and guarantee’s a decent data rate for users.

Early results in SK Telecom press release are positive with a claimed 10-15% increase in data rates in locations where there was known inter-cell interference.

I also looked into couple of books and here is one explanation from An Introduction to LTE by Chris Cox.

To use eight layer spatial multiplexing, the base station starts by configuring the mobile into a new transmission mode, mode 9. This supports both single user and multiple user MIMO, so the base station can quickly switch between the two techniques without the need to change transmission mode.

The base station schedules the mobile using a new DCI format, 2C. In the scheduling command, it specifies the number of layers that it will use for the data transmission, between one and eight. It does not have to specify the precoding matrix, because that is transparent to the mobile. The base station then transmits the PDSCH on antenna ports 7 to 7 + n, where n is the number of layers that the mobile is using. The maximum number of codewords is two, the same as in Release 8.

The mobile still has to feed back a precoding matrix indicator, which signals the discrepancy between the precoding that the base station is transparently providing and the precoding that the mobile would ideally like to use. Instead of using the PMI, however, the mobile feeds back two indices, i1 and i2. Both of these can vary from 0 to 15, which provides more finely-grained feedback than the PMI did and in turn improves the performance of the multiple user MIMO technique. The base station can then use these indices to reconstruct the requested precoding matrix.

Embedded below is an extract from Google books for Lte-Advanced Air Interface Technology By Xincheng Zhang, Xiaojin Zhou

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.

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.

3GPP Enhancements for Machine Type Communications Overview from Zahid Ghadialy

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.

Machine Type Communications (MTC): Architecture, Features, Standards in 3GPP Rel-10

The following 14 MTC Features have been identified during the 3GPP Release-10 timelines:

• Low Mobility
• Time Controlled
• Time Tolerant
• Packet Switched (PS) Only
• Small Data Transmissions
• Mobile Originated Only
• Infrequent Mobile Terminated
• MTC Monitoring
• Priority Alarm Message (PAM)
• Secure Connection
• Location Specific Trigger
• Network Provided Destination for Uplink Data
• Infrequent Transmission
• Group Based MTC Features

In Rel 10, 3GPP will focus on the general functionality required to support these features:

• Overload control (Radio Network Congestion use case, Signalling Network Congestion use case and Core Network Congestion use case)
• Addressing
• Identifiers
• Subscription control
• Security

The following specifications are associated with the MTC work

Spec   - Specifications associated with or affected by MTC work
22.011 - Service accessibility
22.368 - Service requirements for Machine-Type Communications (MTC); Stage 1
23.008 - Organization of subscriber data
23.012 - Location management procedures
23.060 - General Packet Radio Service (GPRS); Service description; Stage 2
23.122 - Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode
23.203 - Policy and charging control architecture
23.401 - General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access
23.402 - Architecture enhancements for non-3GPP accesses
23.888 - System improvements for Machine-Type Communications (MTC)
24.008 - Mobile radio interface Layer 3 specification; Core network protocols; Stage 3
24.301 - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3
24.368 - Non-Access Stratum (NAS) configuration Management Object (MO)
25.331 - Radio Resource Control (RRC); Protocol specification
29.002 - Mobile Application Part (MAP) specification
29.018 - General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification
29.060 - General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface
29.118 - Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification
29.274 - 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
29.275 - Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling protocols; Stage 3
29.282 - Mobile IPv6 vendor specific option format and usage within 3GPP
31.102 - Characteristics of the Universal Subscriber Identity Module (USIM) application
33.868 - Security aspects of Machine-Type Communications
36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification
37.868 - RAN Improvements for Machine-type Communications
43.868 - GERAN Improvements for Machine-type Communications
44.018 - Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol
44.060 - General Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control / Medium Access Control (RLC/MAC) protocol
45.002 - Multiplexing and multiple access on the radio path

Here are couple of presentations I have extracted the above information from:

• 3GPP Enhancements for Machine Type Communications Overview
• Understanding how 3GPP Standards Updates affect LTE Roll-Out

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.
 

3GPP based 'Sponsored Data Connectivity'

One of the features being investigated and added is the Sponsored Data Connectivity feature in the Evolved Packet System. This feature has lots of backers as this is deemed to be a new source of revenue for the operators.

In Release-10 one of the items for this is titled 'Policy Enhancements for Sponsored Connectivity and Coherent Access to Policy related Databases (PEST)'

The justification for PEST is as follows:


With the emerging of innovative IP services, the transactional data usage is becoming more and more prevalent on the mobile. For example, the user downloads a purchased ebook from an online store; the user purchases and downloads a game from an operator store; the user views free trailer clip from an online library to determine whether to buy the entire movie or not. In many cases, the Sponsor (e.g., Application service provider) pays for the user’s data usage in order to allow the user to access the Application Service Provider’s services. This enables additional revenue opportunities for both the Application service providers and the operators.


In particular, such dynamic data usage provided by the Sponsor allows the operator to increase revenues from the users with limited data plans. The user may have limited data plans allowing only a nominal data volume per month and the Sponsor may dynamically sponsor additional volume for the user to allow access to the services offered by the Application service providers.


The PCC framework can be enhanced to enable such use cases, in particular, it allows the operator to provide service control based on such sponsored services. For example, it allows a dynamic IP flow to be excluded from the user’s data plan since a Sponsor might sponsor the data usage for the identified IP flows. For example, the user may use the limited data plan to browse an online store for interested books; but once a book is purchased, the data usage for downloading the book can be granted for free. In addition, the IP flow may also be granted certain level of QoS (e.g. video streaming).

TR 23.813 studied the feasibility of these scenarios of sponsored connectivity in the key issue 1 and converged into a set of extensions to the PCC procedures which will allow the operator to provide sponsored connectivity to sponsor entities.


In addition to Key Issue 1, SA2 also studied the feasibility of Key issue 2 - Coherent access to Policy related databases within TR 23.813. It enables UDR (User Data Repository) in the PCC architecture as an optional functional entity where PCC related subscriber data can be stored and retrieved by the PCRF through the Ud interface. This deployment scenario does not require SPR and allows the PCRF access to the PCC related subscriber data stored in the UDR.

In Release-12 PEST is linked to another new feature titled, 'Interworking between Mobile Operators using the Evolved Packet System and Data Application Providers (MOSAP)'

The Justification of this is as follows:

Mobile operators have to deal with increasing flexibility of data services delivery on different devices. 


The data services could be hosted by the mobile operators in their data centers within 3GPP domain or could be hosted by 3rd party data application providers that could be outside of the mobile operator domain. 


Current practices involve individual mobile operators negotiating agreements with data application providers resulting in proprietary additional functionalities in 3GPP networks which results in  non-standard 3GPP interfaces. With the advent of new models of services delivery like cloud computing and Application Stores, it is important that the mobile operator minimises upgrades to the network  and associated backend integration. 


Also the mobile operator has the opportunity to explore various charging models in this interworking scenario with data service providers. 


Sample services/capabilities that mobile operators can provide to data application providers are customised billing/charging, promotional services, group addressing capabilities, identity services, statistics, etc.


This WI proposes to enable the mobile operator to use enhanced functionalities and interfaces to meet the needs of the rapidly changing industry models. The WI is expected to develop requirements and architectural frameworks for authentication, authorization, policy, charging, mobility and session continuity aspects for various interworking scenarios.


The existing schemes for authentication/authorization and charging need to be studied and updated/enhanced, when deemed necessary, by liaising with other 3GPP Working Groups/SDOs/fora in charge of them.


This WI was de-prioritised in Rel-11. The Rel-12 work will take into consideration the new TS 23.682 developed in Rel-11 (Architecture Enhancements to facilitate communications with Packet Data Networks and Applications).

What are you your thoughts on sponsored data connectivity?

xoxoxoxoxoxo  Added on 08/07/2012 - 14.00 xoxoxoxoxoxo



I had a quick discussion with Dean Bubley on twitter and here is what he thinks:

Key question is what use cases & how the biz model / sponsor interaction works. 1-800 model is a #UselessCase for example. I think tollfree/1-800 apps is a nice idea, but totally unworkable when you drill into the practicalities. There are a few corner-cases & niche exceptions (eg govt-supplied apps) but proposed case for general apps / content is a chimera. 

More details on what Dean Bubley means is on his blog post here.

The comment at the end is very interesting, summarising the hurdles that exist in providing 'Toll-free data'.

My belief is that since the operators are running out of the options in generating new revenues, they may make a compromise and find a middle ground for making the 'Sponsored-data' to work

HSPA+ Evolution: Standards and Data Rates

From the 4G Americas white paper.

Enhanced Uplink SC-FDMA: PUSCH+PUCCH Simultaneous Transmission

3GPP System Building on Releases

Evolution of 3GPP Security

Radio relay technologies in LTE-Advanced

The following is from NTT Docomo Technical journal: 

Three types of radio relay technologies and their respective advantages and disadvantages are shown in Figure 1. 

A layer 1 relay consists of relay technology called a booster or repeater. This is an Amplifier and Forward (AF) type of relay  technology by which Radio Frequency (RF) signals received on the downlink from the base station are amplified and transmitted to the mobile station. In a similar manner, RF signals received on the uplink from the mobile station are amplified and transmitted to the base station. The equipment functions of a layer 1 relay are relatively simple, which makes for low-cost implementation and short processing delays associated with relaying. With these  features, the layer 1 relay has already found widespread use in 2G and 3G mobile communication systems. It is being deployed with the aim of improving coverage in mountainous regions, sparsely populated areas and urban areas as well as in indoor environments.


The RF performance specifications for repeaters have already been specified in LTE, and deployment of these repeaters for the same purpose is expected. The layer 1 relay, however, amplifies intercell interference and noise together with desired signal components thereby deteriorating the received Signal to Interference plus Noise power Ratio (SINR) and reducing the throughput enhancement gain.


The layer 2 relay, meanwhile, is a Decode and Forward (DF) type of relay technology by which RF signals received on the downlink from the base station are demodulated and decoded and then encoded and modulated again before being sent on to the mobile station. This demodulation and decoding processing performed at the radio relay station overcomes the drawback in layer 1 relays of deteriorated received SINR caused by amplification of intercell interference and noise. A better throughput-enhancement effect can therefore be expected compared with the layer 1 relay. At the same time, the layer 2 relay causes a delay associated with modulation/demodulation and encoding/decoding processing. In this type of relay, moreover, radio functions other than modulation/demodulation and encoding/decoding (such as mobility control, retransmission control by Automatic Repeat request (ARQ), and user-data concatenation/segmentation/reassembly) are performed between the base station and mobile station transparently with respect to the radio relay, which means that new radio-control functions for supporting this relay technology are needed. 

The layer 3 relay also performs demodulation and decoding of RF signals received on the downlink from the base station, but then goes on to perform processing (such as ciphering and user-data concatenation/segmentation/reassembly) for retransmitting user data on a radio interface and finally performs encoding/modulation and transmission to the mobile station. Similar to the layer 2 relay, the layer 3 relay can improve throughput by eliminating inter-cell interference and noise, and additionally, by incorporating the same functions as a base station, it can have small impact on the standard specifications for radio relay technology and on implementation. Its drawback, however, is the delay caused by user-data processing in addition to the delay caused by modulation/demodulation and encoding/decoding processing.


In 3GPP, it has been agreed to standardize specifications for layer 3 relay technology in LTE Rel. 10 because of the above features of improved received SINR due to noise elimination, ease of coordinating standard specifications, and ease of implementing the technology. Standardization of this technology is now moving forward.


Layer 3 radio relay technology is shown in Figure 2. In addition to performing user-data regeneration processing and modulation/demodulation and encoding/ decoding processing as described above, the layer 3 relay station also features a unique Physical Cell ID (PCI) on the physical layer different than that of the base station. In this way, a mobile station can recognize that a cell provided by a relay station differs from a cell provided by a base station.


In addition, as physical layer control signals such as Channel Quality Indicator (CQI) and Hybrid ARQ (HARQ) can terminate at a relay station, a relay station is recognized as a base station from the viewpoint of a mobile station. It is therefore possible for a mobile station having only LTE functions (for example, a mobile station conforming to LTE Rel. 8 specifications) to connect to a relay station. Here, the wireless backhaul link (Un) between the base station and relay station and the radio access link (Uu) between the relay station and mobile station may operate on different frequencies or on the same frequency. In the latter case, if transmit and receive processing are performed simultaneously at the relay station, transmit signals will cause interference with the relay station’s receiver by coupling as long as sufficient isolation is not provided between the transmit and receive circuits. Thus, when operating on the same frequency, the wireless backhaul-link and radio-access-link radio resources should be subjected to Time Division Multiplexing (TDM) so that transmission and reception in the relay station are not performed simultaneously.

Scenarios in which the introduction of relay technology is potentially useful have been discussed in 3GPP. Deployment scenarios are shown in Table 1. Extending the coverage area to mountainous and sparsely populated regions (rural area and wireless backhaul scenarios) is an important scenario to operators. It is expected that relay technology can be used to economically extend coverage to such areas as opposed to deploying fixed-line backhaul links. Relay technology should also be effective for providing temporary coverage when earthquakes or other disasters strike or when major events are being held (emergency or temporary coverage scenario), i.e., for situations in which the deployment of dedicated fixed-line backhaul links is difficult. In addition, while pico base stations and femtocells can be used for urban hot spot, dead spot, and indoor hot spot scenarios, the installation of utility poles, laying of cables inside buildings, etc. can be difficult in some countries and regions, which means that the application of relay technology can also be effective for urban scenarios. Finally, the group mobility scenario in which relay stations are installed on vehicles like trains and buses to reduce the volume of control signals from moving mobile stations is also being proposed.


In 3GPP, it has been agreed to standardize the relay technology deployed for coverage extension in LTE Rel. 10. These specifications will, in particular, support one-hop relay technology in which the position of the relay station is fixed and the radio access link between the base station and mobile station is relayed by one relay station.



References
[1] 3GPP TS36.912 V9.1.0: “Feasibility study for Further Advancement for E-UTRA (LTE-Advanced),” 2010.
[2] 3GPP TS36.323 V9.0.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification,” 2009
[3] 3GPP TS36.322 V9.1.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification,” 2010.
[4] 3GPP TS36.321 V9.2.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification,” 2010.
[5] 3GPP TS36.331 V9.2.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification,” 2010.
[6] 3GPP TS36.413 V9.2.1: “Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP),” 2010.
[7] 3GPP TR36.806 V9.0.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Relay architectures for E-UTRA (LTEAdvanced),” 2010.
[8] IETF RFC4960: “Stream Control Transmission Protocol,” 2007.
[9] 3GPP TS29.281 V9.2.0: “General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U),” 2010.

IMS Release 10 Tutorial

IMS Release 10 Tutorial

View more documents from Zahid Ghadialy

Available to download from here.

Heterogeneous network deployments in LTE: The soft-cell approach

Heterogeneous network deployments in LTE

View more documents from Zahid Ghadialy

Available to download from here.

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.

RRC Signalling in Rel-10 for MDT

Last year I wrote about Minimization of Drive Testing (MDT) and mentioned about the possibility of enhancements. Now looking at the new RRC specs I can see a new message LoggedMeasurementsConfiguration has been added,

When the UE is in RRC_CONNECTED mode, this message can be sent and the UE be informed about the measurements to be performed. The message contents are as follows:

LoggedMeasurementConfiguration-r10 ::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

loggedMeasurementConfiguration-r10 LoggedMeasurementConfiguration-r10-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

LoggedMeasurementConfiguration-r10-IEs ::= SEQUENCE {

traceReference-r10 TraceReference-r10,

traceRecordingSessionRef-r10 OCTET STRING (SIZE (2)),

tce-Id-r10 OCTET STRING (SIZE (1)),

absoluteTimeInfo-r10 AbsoluteTimeInfo-r10,

areaConfiguration-r10 AreaConfiguration-r10 OPTIONAL, -- Need OR

loggingDuration-r10 LoggingDuration-r10,

loggingInterval-r10 LoggingInterval-r10,

nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP

}

Once the UE has done the measurements, it can inform the network in one of the following messages, RRCConnectionSetupComplete, RRCConnectionReestablishmentComplete, RRCConnectionReconfigurationComplete and UEInformationResponse that it has the required information available. This is done by including the following new Enum:

logMeasAvailable-r10 ENUMERATED {true} OPTIONAL,

Finally, the network can request the logged Measurements information in the UE Information Request Message. The new fields for that are:


UEInformationRequest-v1020-IEs ::= SEQUENCE {
logMeasReportReq-r10 ENUMERATED {true} OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}

The UE would send the following information in the response message:

LogMeasInfo-r10 ::= SEQUENCE {
locationInfo-r10 LocationInfo-r10 OPTIONAL,
relativeTimeStamp-r10 INTEGER (0..7200),
servCellIdentity-r10 CellGlobalIdEUTRA,
measResultServCell-r10 SEQUENCE {
rsrpResult-r10 RSRP-Range,
rsrqResult-r10 RSRQ-Range
},
measResultNeighCells-r10 SEQUENCE {
measResultListEUTRA-r10 MeasResultList2EUTRA-r9 OPTIONAL,
measResultListUTRA-r10 MeasResultList2UTRA-r9 OPTIONAL,
measResultListGERAN-r10 MeasResultList2GERAN-r10 OPTIONAL,
measResultListCDMA2000-r10 MeasResultList2CDMA2000-r9 OPTIONAL
} OPTIONAL,
...
}


MeasResultList2GERAN-r10 ::= SEQUENCE (SIZE (1..maxCellListGERAN)) OF MeasResultListGERAN


LocationInfo-r10 ::= SEQUENCE {
locationCoordinates-r10 CHOICE {
ellipsoid-Point-r10 OCTET STRING,
ellipsoidPointWithAltitude-r10 OCTET STRING,
...
},
horizontalVelocity-r10 OCTET STRING OPTIONAL,
gnss-TOD-msec-r10 OCTET STRING OPTIONAL,
...
}