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
No comments:
Post a Comment