Pages

Join our LinkedIn group

Showing posts with label Handovers. Show all posts
Showing posts with label Handovers. Show all posts

Wednesday, 21 May 2014

Connected and Autonomous Car Revolution

Last week we had the Automotive and Transport SIG event in Cambridge Wireless. There is already some good writeup on that event here and here. In this post my interest in looking at the technologies discussed.

R&S (who were the sponsors) gave their introduction presentation quite well highlighting the need and approaches for the connected car. He also introduced the IEEE 802.11p to the group.

As per Wikipedia, "IEEE 802.11p is an approved amendment to the IEEE 802.11 standard to add wireless access in vehicular environments (WAVE), a vehicular communication system. It defines enhancements to 802.11 (the basis of products marketed as Wi-Fi) required to support Intelligent Transportation Systems (ITS) applications. This includes data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz). IEEE 1609 is a higher layer standard based on the IEEE 802.11p."

Back in December, Dr. Paul Martin did an equally useful presentation in the Mobile Broadband SIG and his presentation is equally relevant here as he introduced the different terms live V2X, V2i, V2V, V2P, etc. I have embedded his presentation below:



Roger Lanctot from Strategy Analytics, gave us some interesting facts and figures. Being based in the US, he was able to give us the view of both US as well as Europe. According to him, “LTE is the greatest source of change in value proposition and user experience for the customer and car maker. Bluetooth, Wi-Fi, NFC and satellite connectivity are all playing a role, but LTE deployment is the biggest wave sweeping the connected car, creating opportunities for new technologies and applications.” His officially released presentation is embedded below (which is much smaller than his presentation on that day.



There were also interesting presentations that I have not embedded but other may find useful. One was from Mike Short, VP of Telefonica and the other was from Dr. Ireri Ibarra of MIRA.


The final presentation by Martin Green of Visteon highlighted some interesting discussions regarding handovers that may be required when the vehicle (and the passengers inside) is moving between different access networks. I for one believe that this will not be an issue as there may be ways to work the priorities of access networks out. Anyway, his presentation included some useful nuggets and its embedded below:


Monday, 4 November 2013

Key challenges with automatic Wi-Fi / Cellular handover

Recently in a conference I mentioned that the 3GPP standards are working on standards that will allow automatic and seamless handovers between Cellular and Wi-Fi. At the same time operators may want to have a control where they can automatically switch on a users Wi-Fi radio (if switched off) and offload to Wi-Fi whenever possible. It upset quite a few people who were reasoning against the problems this could cause and the issues that need to be solved.

I have been meaning to list the possible issues which could be present in this scenario of automatically handing over between Wi-Fi and cellular, luckily I found that they have been listed very well in the recent 4G Americas whitepaper. The whitepaper is embedded below but here are the issues I had been wanting to discuss:

In particular, many of the challenges facing Wi-Fi/Cellular integration have to do with realizing a complete intelligent network selection solution that allows operators to steer traffic in a manner that maximizes user experience and addresses some of the challenges at the boundaries between RATs (2G, 3G, LTE and Wi-Fi).
Figure 1 (see above) below illustrates four of the key challenges at the Wi-Fi/Cellular boundary.
1) Premature Wi-Fi Selection: As devices with Wi-Fi enabled move into Wi-Fi coverage, they reselect to Wi-Fi without comparative evaluation of existing cellular and incoming Wi-Fi capabilities. This can result in degradation of end user experience due to premature reselection to Wi-Fi. Real time throughput based traffic steering can be used to mitigate this.
2) Unhealthy choices: In a mixed wireless network of LTE, HSPA and Wi-Fi, reselection may occur to a strong Wi-Fi network, which is under heavy load. The resulting ‘unhealthy’ choice results in a degradation of end user experience as performance on the cell edge of a lightly loaded cellular network may be superior to performance close to a heavily loaded Wi-Fi AP. Real time load based traffic steering can be used to mitigate this.
3) Lower capabilities: In some cases, reselection to a strong Wi-Fi AP may result in reduced performance (e.g. if the Wi-Fi AP is served by lower bandwidth in the backhaul than the cellular base station presently serving the device). Evaluation of criteria beyond wireless capabilities prior to access selection can be used to mitigate this.
4) Ping-Pong: This is an example of reduced end user experience due to ping-ponging between Wi-Fi and cellular accesses. This could be a result of premature Wi-Fi selection and mobility in a cellular environment with signal strengths very similar in both access types. Hysteresis concepts used in access selection similar to cellular IRAT, applied between Wi-Fi and cellular accesses can be used to mitigate this.
Here is the paper:



Monday, 9 January 2012

Overview of LTE Handovers


From the NTT Docomo Technical journal:


The LTE handover is broadly divided into a backward handover (PS handover) and forward handover. In the former, the network performs cell switching and notifies the mobile terminal of the destination cell, and in the latter, the mobile terminal performs autonomous switching to pick up the destination cell.


To control packet loss due to a momentary cutoff at the time of radio switching, PS handover supports a data forwarding process that transfers undelivered data from the switching-source eNodeB to the switching-destination eNodeB and a reordering process that corrects sequencing mistakes between forwarded data and new data.


The forward handover can be classified into Release with Redirection triggered by a cutoff signal from the network and Non Access Stratum (NAS) Recovery in which the mobile terminal autonomously performs a NAS recovery, either of which is accompanied by data loss due to a momentary cutoff. From a different perspective, handover can be classified in the following two ways according to whether it is accompanied by Radio Access Technology (RAT) or frequency switching or by eNodeB or EPC switching (Figure 7).


1) Intra-RAT handover: This is a handover that occurs within the LTE system in which node transition occurs between sectors within an eNodeB, between eNodeBs within an EPC switch, or between EPC switches. 


A handover between eNodeBs within an EPC switch may be an X2 or S1 handover. In an X2 handover, signal processing is performed by the X2 logical interface between eNodeBs, while in an S1 handover, signal processing is performed by the S1 logical interface between an eNodeB and the EPC switch. There is a tradeoff between the cost of maintaining an X2 link and the cost incurred by an S1 handover, and operations are configured accordingly.


Handover can also be classified by whether the center frequency is the same before and after handover, that is, whether the handover occurs within the same frequency or between frequencies.


2) Inter-RAT handover: This is a handover that occurs between RATs either as a transition from LTE to 3G or from 3G to LTE.

A detailed post on LTE to 3G Inter-RAT handover is available here.

Friday, 18 November 2011

Interoperability between LTE FDD/TDD network

In countries where FDD and TDD are both in use, it would be interesting to see Dual-mode LTE terminals that would support both TDD and FDD and it should be possible to do a reselection as well has handovers from one mode to another.

It should be noted that the Structure of TDD and FDD frames are different as shown above.

If you are wondering why we need both FDD and TDD modes in the same geographical location, its because of Spectrum being available as well as with TDD allows possibility of different UL/DL data rates which generally means more efficient use of spectrum.

Wednesday, 9 November 2011

Redirection, Reselection, Handovers and other Inter-RAT combinations in LTE


Another one from Qualcomm's 4G World presentation. You can see the number of scenarios that would have to be taken into account for; this was one of the reasons I believed SVLTE may be a good choice.

Related posts:


Wednesday, 27 July 2011

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)

Friday, 22 July 2011

Mobility Robustness Optimization to avoid Handover failures

The following is from 4G Americas Whitepaper on SON:

Mobility Robustness Optimization (MRO) encompasses the automated optimization of parameters affecting active mode and idle mode handovers to ensure good end-user quality and performance, while considering possible competing interactions with other SON features such as, automatic neighbor relation and load balancing.

There is also some potential for interaction with Cell Outage Compensation and Energy Savings as these could also potentially adjust the handover boundaries in a way that conflicts with MRO. While the goal of MRO is the same regardless of radio technology namely, the optimization of end-user performance and system capacity, the specific algorithms and parameters vary with technology.

The objective of MRO is to dynamically improve the network performance of HO (Handovers) in order to provide improved end-user experience as well as increased network capacity. This is done by automatically adapting cell parameters to adjust handover boundaries based on feedback of performance indicators. Typically, the objective is to eliminate Radio Link Failures and reduce unnecessary handovers. Automation of MRO minimizes human intervention in the network management and optimization tasks.

The scope of mobility robustness optimization as described here assumes a well-designed network with overlapping RF coverage of neighboring sites. The optimization of handover parameters by system operators typically involves either focused drive-testing, detailed system log collection and postprocessing, or a combination of these manual and intensive tasks. Incorrect HO parameter settings can negatively affect user experience and waste network resources by causing HO ping-pongs, HO failures and Radio Link Failures (RLF). While HO failures that do not lead to RLFs are often recoverable and invisible to the user, RLFs caused by incorrect HO parameter settings have a combined impact on user experience and network resources. Therefore, the main objective of mobility robustness optimization should be the reduction of the number of HO-related radio link failures. Additionally, sub-optimal configuration of HO parameters may lead to degradation of service performance, even if it does not result in RLFs. One example is the incorrect setting of HO hysteresis, which may results in ping-pongs or excessively delayed handovers to a target cell. Therefore, the secondary objective of MRO is the reduction of the inefficient use of network resources due to unnecessary or missed handovers.

Most problems associated with HO failures or sub-optimal system performance can ultimately be categorized, as either too-early or too-late triggering of the handover, provided that the required fundamental network RF coverage exists. Thus, poor HO-related performance can generally be categorized by the following events:

* Intra-RAT late HO triggering
* Intra-RAT early HO triggering
* Intra-RAT HO to an incorrect cell
* Inter-RAT too late HO
* Inter RAT unnecessary HO

Up to Release 9, a UE is required to send RLF report only in case of successful RRC re-establishment after a connection failure. Release 10 allows support for RLF reports to be sent even when the RRC reestablishment does not succeed. The UE is required to report additional information to assist the eNB in determining if the problem is coverage related (no strong neighbors) or handover problems (too early, too late or wrong cell). Furthermore, Release 10 allows for precise detection of too early / wrong cell HO.

Monday, 14 March 2011

LTE Physical Layer Measurements of RSRP and RSRQ

One of the things on my mind for long time was to find a bit more about RSRP and RSRQ.

The following is from Agilent Whitepaper:

The UE and the eNB are required to make physical layer measurements of the radio characteristics. The measurement definitions are specified in 3GPP TS 36.214. Measurements are reported to the higher layers and are used for a variety of purposes including intra- and inter-frequency handover, inter-radio access technology (inter-RAT) handover, timing measurements, and other purposes in support of RRM.

Reference signal receive power (RSRP):

RSRP is the most basic of the UE physical layer measurements and is the linear average (in watts) of the downlink reference signals (RS) across the channel bandwidth. Since the RS exist only for one symbol at a time, the measurement is made only on those resource elements (RE) that contain cell-specific RS. It is not mandated for the UE to measure every RS symbol on the relevant subcarriers. Instead, accuracy requirements have to be met. There are requirements for both absolute and relative RSRP. The absolute requirements range from ±6 to ±11 dB depending on the noise level and environmental conditions. Measuring the difference in RSRP between two cells on the same frequency (intra-frequency measurement) is a more accurate operation for which the requirements vary from ±2 to ±3 dB. The requirements widen again to ±6 dB when the cells are on different frequencies (inter-frequency measurement).

Knowledge of absolute RSRP provides the UE with essential information about the strength of cells from which path loss can be calculated and used in the algorithms for determining the optimum power settings for operating the network. Reference signal receive power is used both in idle and connected states. The relative RSRP is used as a parameter in multi-cell scenarios.

Reference signal receive quality (RSRQ):

Although RSRP is an important measure, on its own it gives no indication of signal quality. RSRQ provides this measure and is defined as the ratio of RSRP to the E-UTRA carrier received signal strength indicator (RSSI). The RSSI parameter represents the entire received power including the wanted power from the serving cell as well as all cochannel power and other sources of noise. Measuring RSRQ becomes particularly important near the cell edge when decisions need to be made, regardless of absolute RSRP, to perform a handover to the next cell. Reference signal receive quality is used only during connected states. Intra- and inter-frequency absolute RSRQ accuracy varies from ±2.5 to ±4 dB, which is similar to the interfrequency relative RSRQ accuracy of ±3 to ±4 dB.

The following is from R&S white paper:


The RSRP is comparable to the CPICH RSCP measurement in WCDMA. This measurement of the signal strength of an LTE cell helps to rank between the different cells as input for handover and cell reselection decisions. The RSRP is the average of the power of all resource elements which carry cell-specific reference signals over the entire bandwidth. It can therefore only be measured in the OFDM symbols carrying reference symbols.

The RSRQ measurement provides additional information when RSRP is not sufficient to make a reliable handover or cell reselection decision. RSRQ is the ratio between the RSRP and the Received Signal Strength Indicator (RSSI), and depending on the measurement bandwidth, means the number of resource blocks. RSSI is the total received wideband power including all interference and thermal noise. As RSRQ combines signal strength as well as interference level, this measurement value provides additional help for mobility decisions.

Assume that only reference signals are transmitted in a resource block, and that data and noise and interference are not considered. In this case RSRQ is equal to -3 dB. If reference signals and subcarriers carrying data are equally powered, the ratio corresponds to 1/12 or -10.79 dB. At this point it is now important to prove that the UE is capable of detecting and decoding the downlink signal under bad channel conditions, including a high noise floor and different propagation conditions that can be simulated by using different fading profiles.

I will be adding some conformance test logs at the 3G4G website for Measurement and Cell Selection/Re-selection that will give some more information about this.

In case you can provide a much simpler explanation or reference please feel free to add in the comment.

Thursday, 3 March 2011

LTE to 3G Handover Procedure and Signalling

It may be worthwhile brushing up the LTE/SAE Interfaces and Architecture before proceeding.

1) Overview of Handover Operation

With EPC, continuous communication is possible, even while the terminal switches from one type of radio access system to another.

Specifically, in order to achieve the internal network path switching required to change radio access systems, the S-GW provides a mobility management anchor function for handover between 3GPP radio access systems, and the P-GW provides the function for handover between 3GPP and non-3GPP radio access systems. In this way, the IP address does not change when the terminal switches radio access systems, and communications can continue after handover.



In handover between the 3GPP radio access systems, LTE and 3G, handover preparation is done before changing systems, including tasks such as securing resources on the target radio access system, through cooperation between the radio access systems (Figure 3 (a)(A)). Then, when the actual switch occurs, only the network path needs to be switched, reducing handover processing time (Fig.3 (a)(B)). Also, loss of data packets that arrive at the pre-switch access point during handover can be avoided using a data forwarding function (Fig.3 (b)).

In this way, through interaction between radio access systems, fast handover without packet loss is possible, even between radio access systems such as LTE and 3G which cannot be used simultaneously.

2) Handover Preparation Procedure (Fig.3 (a)(A))

The handover preparation procedure for switching radio access from LTE to 3G is shown in Figure 4.


Step (1):The terminal sends a radio quality report containing the handover candidate base-stations and other information to the eNodeB. The eNodeB decides whether handover shall be performed based on the information in the report, identifies the base station and RNC to switch to, and begins handover preparation.

Steps (2) to (3): The eNodeB sends a handover required to the MME, sending the RNC identifier and transmission control information for the target radio access system. The MME identifies the SGSN connected to the target RNC based on the received RNC identifier and sends the communication control and other information it received from the eNodeB to the SGSN in a forward relocation request signal. The information required to configure the communications path between the S-GW and SGSN, which is used for data transmission after the MME has completed the handover, is sent at the same time.

Steps (4) to (5): The SGSN forwards the relocation request to the RNC, notifying it of the communications control information transmitted from the eNodeB. The RNC performs the required radio configuration processing based on the received information and sends a relocation response to the SGSN. Note that through this process, a 3G radio access bearer is prepared between the SGSN and RNC.

Step (6): The SGSN sends a forward relocation response to the MME in order to notify it that relocation procedure has completed. This signal also includes data issued by the SSGN and required to configure a communications path from the S-GW to the SGSN, to be used for data forwarding.

Steps (7) to (8): The MME sends a create indirect data forwarding tunnel request to the S-GW, informing it of the information issued by the SSGN that it just received. From the information that the S-GW receives, it establishes a communications path from the S-GW to the SGSN for data forwarding and sends a create indirect data forwarding tunnel response to the MME.

Through this handover preparation, target 3G radio-access resources are readied, the radio access bearer between the SGSN and RNC is configured, and the data forwarding path from the
S-GW to the SGSN configuration is completed.


3) Handover Procedure for Radio Access System Switching (Fig. 3(a)(B)):

The handover process after switching radio access system is shown in Figure 5.



Steps (1) to (2): When the handover preparation described in Fig.4 is completed, the MME sends a handover command to the eNodeB. When it receives this signal, the eNodeB sends a handover from LTE command for the terminal to switch radio systems. Note that when the eNodeB receives the handover command from the MME, it begins forwarding data packets received from the S-GW. Thereafter, packets for the terminal that arrive at the S-GW are forwarded to the terminal by the path: S-GW, eNodeB, S-GW, SGSN, RNC.

Steps (3) to (6): The terminal switches to 3G and when the radio link configuration is completed, notification that it has connected to the 3G radio access system is sent over each of the links through to the MME: from terminal to RNC, from RNC to SGSN, and from SGSN to MME. This way, the MME can perform Step (10) described below to release the eNodeB resources after a set period of time has elapsed.

Step (7): The MME sends a forward relocation complete acknowledgement to the SGSN. A set period of time after receiving this signal, the SGSN releases the resources related to data forwarding.

Step (8): The SGSN sends a modify bearer request to the S-GW to change from the communications path before the handover, between the S-GW and eNodeB, to one between the S-GW and SGSN. This signal contains information elements required to configure the path from S-GW to SGSN, including those issued by the SGSN. When the S-GW receives this signal, it configures a communications path from the S-GW to the SGSN. In this way, the communications path becomes: S-GW, SGSN, RNC, terminal; and data transmission to the target 3G radio access system begins.

Note that after this point, data forwarding is no longer needed, so the S-GW sends a packet to the eNodeB with an “End Marker” attached, and when the eNodeB receives this packet, it releases its resources related to data forwarding.

Steps (9) to (10): The S-GW sends a modify bearer response to the SGSN, indicating that handover procedure has completed. The MME also releases eNodeB resources that are no longer needed.

Through this handover procedure, data is forwarded during the handover, the switch of radio access bearer is completed, and the communications path from the P-GW to the terminal is updated.

In the examples above, we described the handover procedure between 3GPP radio access systems in which the S-GW did not change, but handovers with S-GW relocation are also possible. In these cases, the P-GW provides the anchor function for path switching, as with switches to non-3GPP access systems.

TERMS

Anchor function: A function which switches the communications path according to the area where the terminal is located, and forwards packets for the terminal to that area.

Relocation: Switching communications equipment such as area switches during communication.


Wednesday, 10 November 2010

Proximity Indication - New RRC Uplink Message in Rel-9

The inbound handover from a Macro eNB to an HeNB (a.k.a. Femtocell) is not supported in Release 8. Before making a handover decision to a HeNB, the Macro eNB needs to acquire UE measurement information related to the so-called target CSG cell. Nevertheless, UEs cannot continuously make measurements and read the system information of lots of CSG cells in cases of large scale HeNB deployments.

In order to allow the UE to make those measurements efficiently, a newly defined proximity report can be configured within the RRC Reconfiguration message. This proximity report will allow the UE to send a so-called “proximity indication” to the source eNB in the uplink whenever it is entering or leaving the proximity of one or more cells with CSG IDs that the UEs has in its CSG Whitelist.

A UE that is able to determine that it is near its CSG cell can thus inform the network to take the necessary actions for handover preparation. The detection of proximity is based on an autonomous search function.

The source eNB, upon receiving the proximity indication, might ask the UE to perform measurements of the CSG cell, to read the System Information (SI) or, in case it already has all required information, it might already start the handover procedure. PCI (Physical Cell Identification) confusion is resolved in Release 9. The eNB will ask the UE to report the global cell identity. As usual the UE reporting is using the RRC measurement procedures. The ovell procedure is illustrated in Figure below.

In summary five basic steps can be identified:
1. Proximity configuration/reporting
2. HO measurement configuration/reporting
3. Resolution of PCI confusion by requesting and reporting System Information
4. Access Control in the network
5. HO execution

Since the CSG search can be very slow there are no strict requirements on the inbound handover performance, which can range from one to several 10’s of seconds.

Since the proximity information is based on UE signaling, the network might be receiving a lot of proximity indications, increasing the network load. Therefore, it was agreed to limit proximity indications a UE can send within a certain time frame. A timer, called the prohibit proximity timer, was introduced.

Source:

Monday, 8 November 2010

Single Radio Voice Call Continuity (SR‐VCC)

From a 3GPP presentation by Hannu Hietalahti

1. SR-VCC use case
1a. IMS call initiated in LTE can continue in CS domain after moving outside of LTE coverage area
1b. SR-VCC is invoked if no other VoIP capable PS system (e.g., HSPA/eHRPD) is available for VoIP PS-PS HO (Handovers)
1c. Only HO of a single voice bearer from PS to CS is specified
1d. Requires overlapping with 1xRTT/GSM/WCDMA coverage

2. SR-VCC allows a voice calls are anchored in IMS
2a. One-way HO from PS to CS systems (LTE to GSM/UMTS or LTE to 1xRTT)
2b. No simultaneous operation of different radio transceivers needed

3. Rel-9 SR-VCC improvements
3a. IMS support of mid call services (e.g., HOLD, MPTY)
3b. SR-VCC support for emergency calls

4. Video calls, reverse direction from CS call to IMS and optimisations are being studied in Rel-10

Monday, 27 September 2010

HeNBs (Femtocells) and eNBs Handovers

An excerpt from presentation by Dr. Doug Pulley, picoChip. The presentation is available to download from here.

Friday, 23 July 2010

Shunning mobiles in favour of Landlines


I guess its time to clean the cobwebs off the landlines. I was reading David Chambers analysis on Homezone tarrifs and it reminded me of the time when I would get big bundle of voice minutes to call using my mobile from home. In those days the voice quality seemed better, signal strength indicator was high and there were hardly any dropped calls.

Nowadays, the signal strength seems to have gone worse whether I am in the office or at home, the voice on the calls keeps breaking, there are too many dropped calls.

To give you an idea of what's going wrong; My phone kept stationary at the table has 4 bars strength of 3G/HSPA, it suddenly becomes 1 bar after 2-3 minutes then hands me over to what the phone says GPRS then the phone says EDGE. If the phone says EDGE then my calls drop within 2 minutes. If my phone says GPRS then I am worried that if it hands over to 3G then my call will drop. If the phone says 3G then unless there are 3 bars, the voice breaks.

Last week I used my landline phone after maybe a year or so and that reminded me how good the voice quality is. In theory the voice quality using mobile phone should be as good as the landline but in practice that may not be true. Of course the wideband AMR can offer much better HD voice but I need reliable voice more than HD voice.

So for the time being, I am going to be sticking with the landlines as far as possible due to reliable and clear communications and wait for the mobiles/networks to catch up.

Friday, 26 March 2010

E-UTRAN Mobility Drivers and Limitations

Many years back, when things used to be simple, I wrote a tutorial about Handovers in UMTS. It would be very difficult to write a similarly simple tutorial for LTE. Things are a bit complicated because there are many different conditions in which handovers can take place.

It was also easier to visualise the Intra-frequency and Inter-frequency handovers in UMTS and you can probably do the same to some extent in LTE but with things getting more complicated and carrier aggregation, classifying handovers in these categories may be difficult.

3GPP TS 36.300 has an informative Annex E which details the scenarios in which handovers and cell change can/will take place.

It is best to go and see Annex E in detail. Here is a bit of summary from there:

Intra-frequency mobility: intra-frequency mobility is the most fundamental, indispensable, and frequent scenario. With the frequency reuse being one in E-UTRAN, applying any driver other than the “best radio condition” to intra-frequency mobility control incur increased interference and hence degraded performance.

Inter-frequency mobility: as in UTRAN, an operator may have multiple carriers/bands for E-UTRAN working in parallel. The use of these frequency layers may be diverse. For example, some of these frequency layers may utilise the same eNB sites and antenna locations (i.e., co-located configuration), whereas some may be used to form a hierarchical cell structure (HCS), or even be used for private networks. Some frequency layers may provide MBMS services, while some may not. Moreover, E-UTRAN carriers/bands may be extended in the future to increase capacity.

Inter-RAT mobility: the aspects that need to be considered for inter-RAT are similar to those for inter-frequency. For mobility solutions to be complete with the inter-RAT drivers, relevant updates would be necessary on the legacy (UTRAN/GERAN) specifications. This will add to the limitations, which are evidently more effective in inter-RAT.


The drivers for mobility control are:

Best radio condition: The primary purpose of cell reselection, regardless of intra-frequency, inter-frequency, or inter-RAT, is to ensure that the UE camps on/connects to the best cell in terms of radio condition, e.g., path loss, received reference symbol power, or received reference symbol Es/I0. The UE should support measurements to suffice this aspect.

Camp load balancing: This is to distribute idle state UEs among the available bands/carriers/RATs, such that upon activation, the traffic loading of the bands/carriers/RATs would be balanced. At least the path loss difference between different bands should be compensated to avoid UEs concentrating to a certain frequency layer.

Traffic load balancing: This is to balance the loading of active state UEs, using redirection for example. In E-UTRAN, traffic load balancing is essential because of the shared channel nature. That is, the user throughput decreases as the number of active UEs in the cell increases, and the loading directly impacts on the user perception.

UE capability: As E-UTRAN bands/carriers may be extended in the future, UEs having different band capabilities may coexist within a network. It is also likely that roaming UEs have different band capabilities. Overlaying different RATs adds to this variety.

Hierarchical cell structures: As in UTRAN, hierarchical cell structures (HCS) may be utilised in E-UTRAN to cover for example, indoors and hot spots efficiently. It is possible that E-UTRAN is initially deployed only at hot spots, in which case this driver becomes essential for inter-RAT, not just for inter-frequency. Another use case would be to deploy a large umbrella cell to cover a vast area without having to deploy a number of regular cells, while providing capacity by the regular cells on another frequency.

Network sharing: At the edge of a shared portion of a network, it will be necessary to direct UEs belonging to different PLMNs to different target cells.

Private networks/home cells: Cells that are part of a sub-network should prioritise the camping on that sub-network. UEs that do not belong to private sub-networks should not attempt to camp or access them.

Subscription based mobility control: This mobility driver aims to limit the inter-RAT mobility for certain UEs, e.g., based on subscription or other operator policies.

Service based mobility control: An operator may have different policies in allocating frequencies to certain services. For example, the operator may concentrate VoIP UEs to a certain frequency layer or RAT (e.g., UTRAN or GERAN), if evaluations prove this effective. UEs requiring higher data rates may better be served on a frequency layer or RAT (e.g., E-UTRAN) having a larger bandwidth. The operator may also want to accommodate premium services on a certain frequency layer or RAT, that has better coverage or larger bandwidth.

MBMS: For Release-9, no new mobility procedures compared to Release-8 are included specifically for MBMS. In future releases the following should be considered. As MBMS services may be provided only in certain frequency layers, it may be beneficial/necessary to control inter-frequency/RAT mobility depending on whether the UE receives a particular MBMS service or not. For MBMS scenarios only, UE based service dependent cell reselection might be considered acceptable. This aspect also depends on the UE capability for simultaneous reception of MBMS and unicast.


While the issues mentioned above drive E-UTRAN towards “aggressive” mobility control, the limiting factors also have to be considered:

UE battery saving: The mobility solution should not consume excessive UE battery, e.g., due to measurements, measurement reporting, broadcast signalling reception, or TA update signalling.
Network signalling/processing load: The mobility solution should not cause excessive network signalling/processing load. This includes over-the-air signalling, S1/X2 signalling, and processing load at network nodes. Unnecessary handovers and cell reselections should be avoided, and PCH and broadcast signalling, as well as dedicated signallings, should be limited.

U-plane interruption and data loss: U-plane interruption and data loss caused by the mobility solution should be limited.

OAM complexity: The mobility solution should not demand excessive efforts in operating/maintaining a network. For example, when a new eNB is added or an existing eNB fails, the mobility solution should not incur excessive efforts to set up or modify the parameters.

More details available in Annex E of 3GPP TS 36.300

Monday, 1 March 2010

GSM-UMTS Network migration towards LTE


Another interesting white-paper from 3G Americas. The following from their press release:

A 3rd Generation Partnership Project (3GPP) specification, LTE will serve to unify the fixed and mobile broadband worlds and will open the door to new converged multimedia services. As an all-IP-based technology, LTE will drive a major network transformation as the traditional circuit-based applications and services migrate to an all-IP environment, though introducing LTE will require support and coordination between a complex ecosystem of application servers, devices/terminals and interaction with existing technologies. The report discusses functionality and steps GSM-UMTS network operators may use to effectively evolve their networks to LTE and identifies potential challenges and solutions for enabling the interaction of LTE with GSM, GPRS and UMTS networks.

“This white paper reveals solutions that facilitate a smooth migration for network operators as they deploy LTE,” stated Chris Pearson, president of 3G Americas. “3GPP has clearly defined the technology standards in Release 9 and Release 10, and this paper explores the implementation of these standards on 3GPP networks.”



A reported
130 operators around the world have written LTE into their technology roadmaps. In December 2009, TeliaSonera launched the world’s first LTE networks in Norway and Sweden and an estimated 17 operators are expected to follow in its footsteps in 2010.

“LTE is receiving widespread support and powerful endorsements from industry leaders around the world, but it is important to keep in mind that the evolution to LTE will require a multi-year effort,” Pearson said. “LTE must efficiently and seamlessly coexist with existing wireless technologies during its rise to becoming the leading next-generation wireless technology.”

Operators planning LTE deployments must consider the implications of utilizing LTE in an ecosystem comprising 2G, 3G and future “4G” wireless technologies. Therefore, operators planning an LTE deployment will need to offer multi-technology devices with networks that allow mobility and service continuity between GSM, EDGE, HSPA and LTE.


Tuesday, 19 June 2007

Voice call continuity (VCC)




Voice call continuity requires maintaining a voice call when a mobile terminal moves from one cell to another for second generation Global System for Mobile Communications (GSM) digital cellular communications systems. Operational for many years, this technique enables a conversation to continue when the Circuit-Switched (CS) call reroutes to use a new basestation as the mobile moves from one coverage area to another. The parties will perceive no break whatsoever.

Today, the scenario is rather more complicated, with calls being handed over not only from 2G to 2G cells and from 3G to 3G cells, but also between 2G GSM and 3G Universal Mobile Telecommunications System (UMTS) cells. This is relatively easy from an administrative point of view, given that generally the same cellular network is involved throughout.

Earlier work carried out within the 3rd Generation Partnership Project (3GPP) envisaged telephony using packet-switched connections – Voice over Internet Protocol (VoIP) – using either the 3GPP-defined IP Multimedia Subsystem (IMS) on the 3G Universal Terrestrial Access Network (UTRAN), or Wireless Local Area Network (WLAN) radio access technology based on IEEE 802.11, and other standards. This was covered by the WLAN interworking work items.

However, until now, handover between CS and IMS (packet-switched) calls was not addressed. 3GPP is now investigating the problem of handing over a voice (or potentially video or other multimedia conversational service) call between the cellular network and a WLAN, possibly operated by a completely different service provider. Again, for conversational service, the hand-over has to be seamless, with no break in service perceived by either party to the call. Until recently, such handover had only been considered for services that are not real-time, such as file-transfer, where short breaks during the handover process are acceptable and probably go unnoticed by the user.

The approach taken by 3GPP is to have the WLAN operator use the information registered by the home operator for the mobile terminal subscriber in this sequence:

1. Validate the eligibility of the handover to happen at all
2. Manage charging for the call that is effectively transferred from one network operator to another

It is generally, though not necessarily, the case that WLAN hotspots are also well covered by cellular service. Thus, such handover may take place when cellular coverage is reduced to an unacceptable level, yet an adequate WLAN hotspot service is available. The handover is more likely to occur when spare bandwidth exists on the WLAN but where excess demand for cellular channels exists.

The goal is to maintain the conversational service call, thus optimizing the service to the users, which in turn will maximize the revenue accruing to the operator(s). 3GPP embarked on the technical activity required to enable this service by approving a work item on Voice Call Continuity (VCC) in the June 2005 meeting of its Technical Specification Group System Aspects and Architecture (TSG SA). In order to be accepted onto the 3GPP work plan, any work item needs to have the support of at least four supporting member companies, and no sustained opposition. The VCC work item has no fewer than 16 supporters, and its progress
can be tracked on the 3GPP website, www.3gpp.org. It is intended that this work be achieved in the Release 7 time frame.



3GPP TR 23.806: Voice Call Continuity between CS and IMS Study (Release 7)
3GPP TS 23.206: Voice Call Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2 (Release 7)
3GPP TS 24.206: Voice Call Continuity between the Circuit-Switched (CS) domain and the IP Multimedia Core Network (CN) (IMS) subsystem; Stage 3 (Release 7)
3GPP TS 24.216: Communication Continuity Management Object (MO) (Release 7)

http://www.compactpci-systems.com/columns/spec_corner/pdfs/2006,04.pdf
http://www.huawei.com/publications/viewRelated.do?id=1146&cid=1802
http://news.tmcnet.com/news/it/2006/06/02/1667856.htm
http://www.tmcnet.com/usubmit/-an-introduction-voice-call-continuity-vcc-/2007/05/02/2577864.htm
http://www.tmcnet.com/wifirevolution/articles/5861-voice-call-continuity-solution-dual-mode-wi-ficdma.htm