PICOCELLS, FEMTOCELLS ANDHOME ENODEBS
`
`S79
`
`wtswldaarea.
`i
`i
`!
`i
`E-Glocalareai
`
`i
`i
`I
`I
`!
`!
`E
`5
`i
`i
`:
`!
`!
`-
`i
`i
`20MHz. 5'-
`:
`i
`i
`! §—'H
`f—H—d !
`:
`.
`.
`-
`g
`27horne i
`: L27homei
`:
`l'
`l-35local.
`i
`:
`i43wlde
`:
`—r—i—-
`
`ISallclasses
`IP—f
`I
`
`A
`E
`'9,
`g
`E
`3
`m
`
`
`
` 1
`
`Frequency (MHz)
`
`12500
`
`Figure 24.8: Blocking requirements.
`
`EPA and EVA propagation models8 with a maximum Doppler frequency no larger than 70 Hz.
`In these cases the performance requirements are the same as for the Vifrde Area eNodeB
`class. In addition for the Home class, new requirements are defined for the decoding of
`Hybrid Automatic Repeat reQest ACKnowledgements (HARQ-ACKs) and channel quality
`information feedback.
`
`24.4.4 Time Synchronization for TDD Operation
`
`Time synchronization in TDD systems is an important consideration for the avoidance of
`interference between uplink and downlink transmissions on neighbouring eNodaBs (see
`Section 23.3). For the HeNBs this is particularly important in view of the potential inter-
`ference scenarios and unplanned deployment. Therefore a mandatory accuracy requirement
`is specified for HeNBs, even though, in cormnon with all eNodeBs, no specific method
`is mandated. The ditference in radio frame start timing, measured at the transmit antenna
`connectors, between the HeNB and any other HeNB or eNodeB which has overlapping
`coverage [12] is required to be less than 3 us, except in cases where timing is obtained by
`monitoring another eNodeB which is more than 500 m away. In this case the requirement is
`relaxed in line with the additional one~way propagation delay beyond 500 m.
`The requirement is designed to ensure that the combination of synchronization error,
`propagation delay to a victim, and multipath delay spread remains less than the smallest
`Cyclic Prefix (CP) length, taking into account that multipath delay spreads tend to be small in
`femtocells; if this condition is satisfied. interference at the uplink/downlink switching points
`within the TDD radio frame will be avoided.
`
`aExtended Pedestrian A and Extended Vehicular A — see Chapter 20.
`
`Samsung Ex. 1010
`1181 of 1365
`
`IPR2022-00464
`Apple EX1014 Page 645
`
`

`

`LTE – THE UMTS LONG TERM EVOLUTION
`
`580
`24.5 Summary
`LTE Release 9 saw the introduction of new classes of base stations: Home eNodeBs or
`femtocells to cover homes and apartments, usually on a closed subscriber group basis, and
`pico eNodeBs to cover hotzones and other local areas.
`While the basic architectural principles remain the same as for LTE macro eNodeBs, some
`new features were introduced specifically to handle the challenges posed by small cells –
`most notably the introduction of the Home eNodeB Gateway to address the needs of very
`large densities of femtocells, and, in Release 10, direct X2-interface handover between Home
`eNodeBs.
`Heterogeneous deployments of small cells and macrocells bring new problems in terms of
`interference; some potential interference management schemes are described in this Chapter.
`Finally, in the last part of the chapter, some of the RF challenges and requirements are
`discussed for both pico and Home eNodeBs.
`
`References9
`[1] Request
`for Comments 4960 The Internet Engineering Task Force (IETF), Network
`Working Group, ‘Stream Control Transmission Protocol’, www.ietf.org.
`[2] 3GPP Technical Specification 23.003, ‘Numbering, addressing and identification (Release 9)’,
`www.3gpp.org.
`[3] 3GPP Technical Report 36.921, ‘FDD Home eNodeB (HeNB) RF requirements analysis
`(Release 9)’, www.3gpp.org.
`[4] Qualcomm, ‘R4-091906: Frequency reuse results with full buffer’, 3GPP TSG RAN WG4,
`meeting 51, San Francisco, USA, May 2009.
`[5] CMCC, ‘R4-092872: Downlink interference coordination between HeNBs’, 3GPP TSG RAN
`WG4, meeting 52, Shenzhen, China, August 2009.
`[6] 3GPP Technical Specification 36.104, ‘Evolved Universal Terrestrial Radio Access (E-UTRA);
`Base Station (BS) Radio Transmission and Reception (Release 9)’, www.3gpp.org.
`[7] CATT, ‘R4-094074: Home eNode B Maximum output power’, 3GPP TSG RAN WG4, meeting
`52bis, Miyazaki, Japan, October 2009.
`[8] CATT, ‘R4-092852: Proposal of maximum output power for Pico eNB’, 3GPP TSG RAN WG4,
`meeting 52, Shenzhen, China, August 2009.
`[9] Huawei, ‘R4-092810: LTE Pico NodeB maximum output power’, 3GPP TSG RAN WG4, meeting
`52, Shenzhen, China, August 2009.
`[10] 3GPP Technical Specification 25.104, ‘Base Station (BS) Radio Transmission and Reception’,
`www.3gpp.org.
`[11] CMCC, ‘R4-091789: Analysis of absolute ACLR1 requirements for LTE TDD HeNB’, 3GPP
`TSG RAN WG4, meeting 51, San Francisco, USA, May 2009.
`[12] 3GPP Technical Report 36.922, ‘TDD Home eNodeB (HeNB) RF requirements analysis (Release
`9)’, www.3gpp.org.
`[13] CATT and Huawei, ‘R4-092809: TP on frequency error for Pico eNodeB’, 3GPP TSG RAN WG4,
`meeting 52, Shenzhen, China, August 2009.
`
`9All web sites confirmed 1st March 2011.
`
`IPR2022-00464
`Apple EX1014 Page 646
`
`

`

`25
`
`Self-Optimizing Networks
`
`Philippe Godin
`
`25.1 Introduction
`
`The provision of Self-Optimizing Network (SON) functions is one of the key differentiators
`of LTE compared to previous generations of cellular systems such as UMTS and GSM. Self-
`optimization of the network is a tool to derive the best performance in a cost-effective manner,
`especially in changing radio environments. It allows the network operator to automate key
`aspects of the network configuration processes, and thus reduces the need for centralized
`planning and human intervention. For these reasons, this feature has been given a high
`priority and was a cornerstone around which the LTE radio, S1 and X2 procedures were
`designed. This makes SON functionality particularly efficient in the LTE system. The
`involvement of the User Equipment (UE) in the SON functionality of LTE is another key
`contributor to its success.
`This chapter starts with an explanation of the Automatic Neighbour Relation (ANR)
`Function, the functionality for self-configuration of the eNodeB and MME1 and the automatic
`Physical Cell Identity (PCI) configuration as natively implemented within the basic S1 and
`X2 interface procedures.2 These three SON functions, which were included in Release 8, are
`of particular relevance for the initial deployment of an LTE network.
`The chapter then explores other SON functions developed in Release 9 which are designed
`to optimize deployed LTE networks, such as the Mobility Load Balancing (MBL), Mobility
`Robustness Optimization (MRO) and Random Access CHannel (RACH) optimization
`functions. The chapter also includes the latest Release 10 SON enhancements which further
`optimize advanced LTE networks. Finally, as SON is a continuously evolving area, the
`
`1Mobility Management Entity.
`2For details about the S1 interface see Section 2.5 and [1]; for X2 see Section 2.6 and [2].
`
`LTE – The UMTS Long Term Evolution: From Theory to Practice, Second Edition.
`Stefania Sesia, Issam Toufik and Matthew Baker.
`© 2011 John Wiley & Sons, Ltd. Published 2011 by John Wiley & Sons, Ltd.
`
`IPR2022-00464
`Apple EX1014 Page 647
`
`

`

`582
`
`LTE — THE UMTS LONG TERM EVOLUTION
`
`chapter concludes with examples of other new SON functions which are envisioned to
`complement the SON family in the near future.
`Further details of the specified SON techniques can be found in [3,4].
`
`25.2 Automatic Neighbour Relation Function (ANRF)
`
`The ANR Function (ANRF) is an example of a SON function which exploits both the design
`of the LTE radio interface and the UE to enable the network to optimize itself. The purpose of
`the ANRF is to relieve the network operator from the burden of manually managing relations
`between neighbouring cells.
`
`25.2.1
`
`Intra-LTE ANRF
`
`The ANRF relies on the cells broadcasting their globally unique identity, termed the E-
`UTRAN Cell Global Identifier (ECGl). The ECG] is composed of 3 bytes canying the Public
`Land Mobile Network (PLMN) ID and 28 bits to identify the cell within that PLMN. The
`function involves User Equipments (UEs), when requested by their serving eNodeB, reading
`and reporting the ECG] broadcast by a neighbouring cell that has been detected previously
`by that UE or another UE.
`When an eNodeB receives from a UE a Physical Cell Identity (PCI) of a neighbour cell
`as part of a normal measurement report, and the eNodeB does not recognize the PCI, the
`eNodeB can instruct the UE to execute a new dedicated reporting procedure which uses the
`newly discovered PCI as a parameter. Through this procedure, the UE reads and reports to
`the requesting eNodeB some system information of the detected neighbouring cell, including
`the ECGI. the Tracking Area Code (TAC) and all available PLMN IDs. An example of this
`procedure is illustrated in Figure 25.1.
`
`Cell A
`Phy cm=3
`Global ClD=17
`
`m
`Phy CID=5
`Global ClD=19
`
`2) Report Global CID
`Requestflarget Phy
`cro=5)
`
`3) Rep“.
`Global cm=19
`
`2b) Read BOCHO
`
`1) Reponlphy c10=5.
`strong signal)
`
`Figure 25.1: The intra-LTE ANR Function. Reproduced by permission of © 3GPP.
`
`By means of the ANRF, each eNodeB can thus automatically populate a Neighbour
`Relation Table (NRT) for each cell it controls, containing all the Neighbour cell Relations
`(NRs) of the cell. An existing NR is defined as a unidirectional cell-to-cell relation from one
`
`Samsung Ex. 1010
`1184 of 1365
`
`IPR2022-00464
`Apple EX1014 Page 648
`
`

`

`SELF-OPTIMIZING NETWORKS
`
`583
`
`source cell controlled by the eNodeB to a target cell for which the eNodeB controlling the
`source cell:
`• knows the ECGI and PCI;
`• has an entry in the NRT for the source cell that identifies the target cell;
`• has the attributes (detailed in the following subsection) in this NRT entry defined either
`by Operation and Maintenance (O&M) or set to default values.
`
`25.2.2 Automatic Neighbour Relation Table
`From the discussion above, it can be seen that the ANRF is a cell-related function managed
`by the eNodeB. In the NRT, each NR can have a number of attributes, including:
`• No Remove flag: The eNodeB shall not remove the NR from the NRT if this flag is set.
`This is typically used if the NR is certain, for example because it has been configured
`by O&M.
`• No Handover flag: The NR shall not be used by the eNodeB for handover purposes if
`this flag is checked. This may, for example, be used if handovers are not useful from
`the source cell to the target cell, but the NR is nevertheless useful for the purpose of
`exchanging interference information.
`• No X2 flag: The NR shall not use an X2 interface to initiate procedures towards the
`eNodeB that controls the target cell. This may, for example, be due to the source and
`target cell belonging to different PLMNs.
`The ANRF incorporates three main functions for the management of NRs in the NRT, as
`shown in Figure 25.2:
`• The ‘NRT management function’ which manages the table, including modifying NR
`attributes;
`• The ‘neighbour detection function’ which finds new neighbour cells and adds them to
`the NRT;
`• The ‘neighbour removal function’ which removes outdated NRs, for example after
`expiry of a timer.
`The ANRF also allows the NRTs to be managed by O&M. O&M functionality can add
`or delete NRs or change the attributes of an NR. Conversely, O&M is also informed about
`changes in an NRT.
`
`25.2.3 Inter-RAT or Inter-Frequency ANRF
`The ANRF also exists between LTE and other Radio Access Technologies (RATs) or towards
`other frequencies. For inter-RAT and inter-frequency ANR, each cell is assigned an inter-
`frequency search list containing all frequencies that should be searched. The target RATs for
`inter-RAT ANRF are UTRAN3, GERAN4 and CDMA2000. The inter-RAT/inter-frequency
`ANR function can be divided into five steps:
`3UMTS Terrestrial Radio Access Network.
`4GSM EDGE Radio Access Network.
`
`IPR2022-00464
`Apple EX1014 Page 649
`
`

`

`584
`
`L'IE— THE UMTS LONG TERM EVOLU'HON
`
`Neighbor Relation Table
`
`Neighbour Relation
`
`Figure 25.2: The ANR function and the ANR table. Reproduced by permission of © SGPP.
`
`. In connected state, the eNodeB instructs a UE to search for neighbour cells in the target
`RATS/frequencies (it may need to schedule appropriate idle periods for this).
`
`The UE reports the PC15 of the detected cells in the target RATS/frequencies (note that
`each RAT has its own specific format of PG).
`
`w
`
`. The eNodeB instructs the UE, using the newly discovered PC] as a parameter, to read
`the key RAT—specific cell identification parameters from the broadcast channel of the
`cell (e.g. the CGI and Routing Area Code (RAC) for GERAN; CGI. Local Area Code
`(LAC) and RAC for UTRAN; CGI for CDMA2000).
`
`The UE reports these key RAT.specific cell identification parameters to the eNodeB of
`the serving cell.
`
`.
`
`the eNodeB updates its inter-RAT/inter-frequency NRT. The eNodeB can then make
`use of the NR, for example when triggering subsequent handovers.
`
`25.3 Self-Configuration of eNodeB and MME
`
`Self-configuration of the eNodeB/MME is a SON function which is implemented in the basic
`8] and X2 interface procedures [1. 2].
`
`Samsung Ex. 1010
`1186 of 1365
`
`IPR2022-00464
`Apple EX1014 Page 650
`
`

`

`585
`
`SELF-OPTIMIZING NETWORKS
`25.3.1 Self-Configuration of eNodeB/MME over S1
`With the native support of the S1-flex function in LTE (see Section 2.5), an eNodeB must
`set up an S1 interface towards each MME of the pool area to which it belongs. The list of
`MME nodes of the pool area together with an initial corresponding remote Internet Protocol
`(IP) address can be directly configured in the eNodeB at deployment (although other means
`may also be used). Once the eNodeB has initiated a Stream Control Transmission Protocol
`(SCTP, see Section 2.5.1.1) association with each MME of the pool area using that IP address,
`they can exchange, via the ‘S1 Setup procedure’ (see Section 2.5), some application-level
`configuration data which is essential for the system operation. This automatic configuration
`process thus saves some manual configuration effort for the network operator, together with
`the associated risk of human error.
`Examples of such application-level configuration data exchanged between the eNodeB
`and the MMEs include Tracking Area (TA) identities,5 lists of PLMNs of different operators
`who may be sharing the network so that all the PLMN IDs can be broadcast over the air for
`their respective UEs, and Closed Subscriber Group (CSG) IDs to allow auto-configuration
`of the Home eNodeB (HeNB) gateway when it connects to thousands of HeNBs.6 Once all
`the data to be broadcast over the radio interface have been configured within each and every
`eNodeB, they are sent automatically to all the relevant MME nodes of the pool area via the
`S1 Setup procedure.7
`The eNodeB can later update the configuration data it had previously sent to the MME
`by sending an ‘eNB CONFIGURATION UPDATE’ message. In this case it only sends the
`updated configuration data, and the data that is not included is interpreted by the MME as
`being unchanged. Conversely, the MME can also send updates of its data to the eNodeBs
`by means of an ‘MME CONFIGURATION UPDATE’. The updated configuration data is
`assumed to be stored in both the eNodeB and the MME for the duration of the SCTP
`association or until any further update occurs.
`
`25.3.2 Self-Configuration of IP address and X2 interface
`Similarly to the S1 interface, self-configuration of IP addresses and of the X2 interface
`is implemented in the basic X2 and S1 interface procedures. The X2 interface may be
`established between one eNodeB and one of its neighbour eNodeBs when they need to
`exchange load, interference or handover related information (see Section 2.6). The automatic
`initialization of the X2 interface consists of three steps:
`
`1. The eNodeB identifies a suitable neighbour;
`
`2. The eNodeB retrieves a suitable IP address for this neighbour if not already available
`and sets up an SCTP association with it;
`
`3. The two eNodeBs exchange configuration data.
`
`5TAs correspond to the zones in which UEs are paged, and their mapping to eNodeBs must remain consistent
`between the E-UTRAN and the Evolved Packet Core (EPC).
`6This enables the paging optimization feature in the HeNB gateway. Further details can be found in Chapter 24.
`7Note that in case of CSG, the S1 Setup messages are exchanged via the Home eNodeB gateway to the MME
`(see Section 24.2).
`
`IPR2022-00464
`Apple EX1014 Page 651
`
`

`

`586
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`The first step can be achieved either by configuration or by using the ANRF described in
`Section 25.2. If the ANRF is used, this step basically consists of the eNodeB being made
`aware of the ECGI and Tracking Area Identity (TAI) of the detected neighbour.
`For the second step, the eNodeB needs to know the IP address of the neighbour in order to
`set up an SCTP association. This IP address may again be either configured or retrieved
`via the network (the latter being used if the ANRF is used during the first step). Auto-
`configuration of the IP address is achieved by the requesting eNodeB sending over the S1
`interface a dedicated ‘eNB CONFIGURATION TRANSFER’ message that includes both
`routing information (such as the ECGI of the detected target cell) and the nature of the
`information that is requested – in this case an IP address for the purpose of X2 initiation.
`The requesting eNodeB also includes its own ECGI to be used for routing back the answer.
`If the receiving eNodeB agrees, it returns one or more IP addresses which can be used
`for the establishment of an X2 interface. When this procedure is complete, the requesting
`eNodeB can set up the SCTP association with its neighbour by sending an SCTP INIT
`message. In Release 10, in order to protect the eNodeBs from malicious SCTP INIT
`requests from unauthorized parties, this auto-configuration process has been enhanced to
`enable the use of an Access Control List (ACL)8 of authorized source IP addresses in the
`receiving eNodeB. For this purpose, the ‘eNB CONFIGURATION TRANSFER’ message
`has been enhanced with the possibility for the requesting eNodeB to include one or several
`IP addresses that the receiving eNodeB can store in its ACL. Thus, whenever a further
`SCTP INIT message is received to set up an X2 interface, the receiving eNodeB can first
`check that the source IP address corresponds to one notified earlier. The protocol also
`allows the requesting eNodeB to provide IP addresses for an IPSec9 transport endpoint for
`scenarios where IPSec is expected to be used (e.g. routing via a security gateway). Finally,
`the requesting eNodeB can also include the IP addresses that it intends to use for the data-
`forwarding GPRS Tunnelling Protocol (GTP) tunnels that it will later establish. This would
`also allow for checking of the user plane traffic at the receiving eNodeB. The reciprocal
`behaviour is also supported: the receiving eNodeB may similarly provide in the ‘eNB
`CONFIGURATION TRANSFER’ message to the requesting eNodeB all the IP addresses
`it intends to use for its control plane SCTP endpoint, user plane GTP endpoints and/or IPSec
`endpoint.
`Once an SCTP association exists between these two neighbour eNodeBs, the third step can
`be started, i.e. exchanging configuration data. This consists of application-level data similar
`to the data exchanged during the self-configuration of the S1 interface (see Section 25.3.1).
`In this case, the ‘X2 Setup’ procedure is used for the exchange. For example, an eNodeB can
`report, via the ‘X2 SETUP REQUEST’ message to a neighbour eNodeB, information about
`each cell it manages, such as the cell’s PCI, frequency band, TAI and/or associated PLMNs.
`More detailed radio parameters can also be included, such as the cyclic prefix length (see
`Section 5.4.1), the transmission bandwidth or the uplink-downlink subframe configuration
`(see Section 6.2) for Time Division Duplex (TDD) cells.
`An eNodeB can also exchange the list of pool areas to which it belongs with a neighbour
`eNodeB. The neighbour eNodeB can thus automatically learn if it shares a pool area in
`common and therefore whether it will need to use the S1 or the X2 handover procedure
`
`8A receiving network node where ACL functionality is applied may only accept connections from other peer
`network nodes once the source addresses of the sending network node are known in the receiving node.
`9IP Security – a collection of protocols and algorithms for IP security, including key management.
`
`IPR2022-00464
`Apple EX1014 Page 652
`
`

`

`SELF-OPTIMIZING NETWORKS
`
`587
`
`to transfer UEs. Indeed, if the eNodeBs do not share a pool area in common, the MME
`associated with the UE must be relocated on handover and the S1 handover has to be used
`(see Sections 2.5.6 and 2.6.3 respectively).
`
`25.4 Automatic Configuration of Physical Cell Identity
`
`The application-level configuration data exchanged during the X2 setup procedure is also
`the core of another SON feature: automatic self-configuration and self-optimization of the
`Physical Cell Identities (PCIs). This helps the eNodeBs to select PCIs that avoid collisions
`and hence cell confusion. Cell confusion arises when two neighbouring cells broadcast
`the same PCI so that a UE cannot discriminate between the two cells when it reports
`measurements. As a consequence the serving eNodeB of that UE cannot determine which one
`of these two cells should be the handover target for the UE. Increased inter-cell interference
`may also arise. The possibility for cell confusion stems from the fact that only about five
`hundred PCI values are available. PCI collision can be avoided by careful configuration on
`the part of the network operator, i.e. by selecting the PCIs allocated to each cell so that
`they are unique within clusters of adjacent neighbouring cells; however, this is a laborious
`operation, and moreover there remains an ongoing risk of further PCI collisions due to the
`start up of new eNodeBs as the network is densified.
`The SON solution to this problem relies on the exchange of PCI values between neighbour
`eNodeBs during the X2 Setup procedure. In both the ‘X2 SETUP REQUEST’ and the ‘X2
`SETUP RESPONSE’ messages, an eNodeB can include the list of PCI values used not only
`by its own cells but also by the ‘direct neighbours’ of its own cells. A direct neighbour of a cell
`is defined as any cell controlled by an eNodeB that is a neighbour of the eNodeB controlling
`the first cell (even if that cell has not yet been reported by any UE). This exchange of direct
`neighbour PCI values over the X2 interface enables an eNodeB to become quickly aware
`of the set of PCI values that are being used in the cluster to which it belongs. In particular
`the eNodeB can easily identify any collision in this cluster and can decide to change the
`PCI of one of its cells if needed; if it does so, it can signal the change to its neighbours in
`an ‘eNB CONFIGURATION UPDATE’ message. However, the exact PCI change algorithm
`supported by eNodeBs is not standardized and remains up to vendor implementations. An
`example of self configuration of PCIs is illustrated in Figure 25.3.
`Via O&M, the network operator can use a variety of degrees of self-configuration at start
`up of the network: the operator could assign no PCI values and let each eNodeB select PCIs
`fully autonomously, or alternatively a range of possible PCI values can be assigned in order
`to assist the convergence of the self-configuration algorithms.
`
`25.5 Mobility Load Balancing Optimization
`
`Release 9 incorporates SON load balancing functionality, the objective of which is to coun-
`teract local traffic load imbalance between neighbouring cells with the aim of improving the
`overall system capacity and reducing congestion. The feature functions by first detecting any
`traffic imbalance and then applying solutions such as adjusting the cell reselection/handover
`parameters (such as handover thresholds). These parameters can be autonomously changed
`
`IPR2022-00464
`Apple EX1014 Page 653
`
`

`

`588
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`eNB B
`
`Cell_B1
`Ph_ID1
`
`Cell_B2
`Ph_ID 2
`
`Cell_C1
`t_Ph ID a
`
`UE_b
`
`UE_a
`
`Cell_A2
`Ph_ID 4
`
`Cell_C2
`t_Ph ID b
`
`eNB C
`(new)
`
`Cell_A1
`Ph_ID 3
`
`eNB A
`
`Figure 25.3: Illustration of PCI allocation. Reproduced by permission of © 3GPP.
`
`and directly communicated between neighbouring cells by means of the X2 Parameter
`Negotiation procedure as explained in Section 25.5.2.
`
`25.5.1 Intra-LTE Load Exchange
`In order to detect an imbalance, it is first necessary to exchange load information between
`neighbouring eNodeBs over X2 for comparison. A client-server mechanism is used for this
`purpose: a requesting eNodeB (client) sends a ‘RESOURCE STATUS REQUEST’ message
`to request a load report from some of its neighbours. The ‘RESOURCE STATUS REQUEST’
`message can simultaneously request multiple types of load report and may also be directed
`at multiple cells of the receiving eNodeB (server). The neighbours that receive the request
`report the requested load information over the X2 interface via the ‘RESOURCE STATUS
`RESPONSE/UPDATE’ message. The reporting of the load is periodic with period indicated
`in the ‘RESOURCE STATUS REQUEST’ message.
`The reported information can indicate any of four different types of cell load information:
`
`• Current usage of Physical Resource Blocks (PRBs), possibly partitioned into real-time
`and non-real-time traffic;
`• Current hardware load;
`• Current S1 transport load;
`• Available composite load.
`
`The first three measurements represent a global view of the current load situation in
`the node that reports them. The ‘available composite load’ indicator represents the amount
`of overall resources that the reporting node is ready to accept. ‘Composite’ means that
`the reporting node takes into account multiple internal resource criteria via a proprietary
`evaluation to build up its report. The ‘available’ characteristic is interesting as an estimate
`
`IPR2022-00464
`Apple EX1014 Page 654
`
`

`

`SELF-OPTIMIZING NETWORKS
`
`589
`
`of the amount of non-GBR10 traffic that can be handed over into the cells controlled by the
`eNodeB. For example, in a case when one UE was using all PRBs, the ‘current usage of
`PRBs’ would typically indicate that all PRBs were fully utilized whereas those PRBs would
`in fact still be available to be shared by the traffic of a second UE. Two formats may be used
`by the operator for the ‘available composite load’ indicator:
`
`• A simple percentage of the total E-UTRAN resources available (i.e. of the total cell
`uplink or downlink bandwidth known from the X2 Setup procedure);
`
`• A percentage weighted according to a cell capacity class value.11
`
`25.5.2 Intra-LTE Handover Parameter Optimization
`
`As a result of the exchange of load information and detection of local load imbalance,
`eNodeBs may take immediate action such as deciding to handover some UEs to cells which
`are less loaded. However, longer-term actions can also be taken to combat the imbalance more
`efficiently. For example when an imbalance is detected between two specific cells it may be
`desirable to shift the handover trigger threshold by, for example, 0.5 dB. By so doing, UEs
`served by an overloaded cell may find that a less-loaded neighbour cell becomes a relatively
`attractive handover target, thus allowing some UEs from the overloaded cell to be served
`reliably by the less-loaded cell. In order to avoid a ping-pong effect, it is often desirable that
`the lightly loaded cell shift its corresponding threshold by a similar amount as the overloaded
`cell but in the opposite direction. For this to happen, the lightly loaded cell must be made
`aware of the change applied by the overloaded cell, or alternatively the overloaded cell could
`first request the less-loaded cell to change its handover threshold and wait for a positive
`response before initiating the change.
`This is the object of the ‘Handover Parameter Negotiation’ procedure. If the two cells
`in question belong to the same eNodeB, this negotiation happens within the eNodeB node
`itself via a proprietary algorithm; otherwise, the negotiation procedure is conducted over X2
`interface via the ‘Mobility Settings Change’ procedure. This procedure enables one eNodeB
`to send a ‘MOBILITY CHANGE REQUEST’ message to another, to indicate the handover
`trigger parameter shift that the first eNodeB sees as necessary for one of the cells controlled
`by the receiving eNodeB. The same message can optionally indicate if the first eNodeB has
`already performed any configuration change of this parameter for one of its own cells. If the
`second eNodeB accepts the proposed handover trigger parameter modification and is able
`to complete it, then it replies with a ‘MOBILITY CHANGE ACKNOWLEDGE’ message;
`otherwise it responds with a ‘MOBILITY CHANGE FAILURE’ message which can include
`an ‘allowed parameter modification range’ if the reason for the failure was that the change
`proposed by the first eNodeB was outside the possible range.
`
`10Guaranteed Bit-Rate – see Section 2.4.
`11The cell capacity class value is a parameter between 0 and 100 configured by the operator to classify one
`particular cell capacity with respect to the other cells available in its network. The use of this parameter is mandatory
`when the ‘available composite load’ indicator is exchanged inter-RAT, e.g. towards UMTS.
`
`IPR2022-00464
`Apple EX1014 Page 655
`
`

`

`590
`25.5.3
`
`LTE – THE UMTS LONG TERM EVOLUTION
`Inter-RAT Load Exchange
`
`In order to perform load information exchange with neighbour cells of a RAT other than
`LTE, an eNodeB can trigger a ‘Cell Load Reporting Request/Response’ procedure towards
`a neighbouring Radio Network Controller (RNC) (for WCDMA), Base Station Controller
`(BSC) (for GSM) or evolved High Speed Packet Access (HSPA) NodeB (for HSPA).
`This new inter-RAT procedure was purposely designed to be independent of the handover
`procedure in order that it can be triggered at any time by a requesting eNodeB even in the
`absence of any mobility event. The procedure is implemented as a generic ‘SON Transfer’
`container carried on top of the RAN Information Management (RIM) protocol.12 The new
`inter-RAT cell load reporting procedure allows an eNodeB to evaluate the load situation
`of GSM or UMTS/HSPA neighbour cells before triggering any load-related action such as
`handing traffic over to those neighbours or switching off a carrier. The new procedure may be
`used in all directions, i.e. from any LTE/UMTS/GSM source node to any LTE/UMTS/GSM
`target node of another RAT.
`
`25.5.4 Enhanced Inter-RAT Load Exchange
`
`One limitation of the Release 9 inter-RAT load exchange procedure described in Section 25.5.3
`is that the RIM messaging which carries it passes through the core network nodes, which may
`become overloaded if load exchange occurs too frequently. On the other hand, variations
`in the radio conditions mean that it is important for the RAN nodes to have up-to-date
`load values from their peers in order to assess the load situation across different RATs. In
`order to solve these two opposing requirements, the inter-RAT load exchange procedure was
`enhanced in Release 10 by the introduction of two new types of reporting:
`
`Event-triggered reporting enables a source RAN node to request a target RAN node
`to report only when a pre-defined cell load-level threshold is crossed in the target node.
`The source node signals the granularity with which it wishes to receive indications of load
`variation: for example, if it requests a granularity of five levels, the target RAN node will
`divide the cell-load scale by five, evenly distributed on a linear scale below the overload
`threshold and will report the target cell load each time the load changes from one reporting
`level to another or enters or exits the overload state. Other parameters (such as hysteresis and
`averaging factors) can be configured by O&M at the target nodes.
`
`Multiple-cell reporting enables a source RAN node to request the a target RAN node to
`report the load of multiple cells within a single report. For example, in the case of UMTS, an
`eNodeB will only need to send one request to the RNC instead of individual requests for all
`the cells controlled by the RNC.
`
`12RIM is a well known protocol dedicated to information exchange between two RAN nodes of different RATs.
`An example is given in Section 25.6.7.
`
`IPR2022-00464
`Apple EX1014 Page 656
`
`

`

`591
`
`SELF-OPTIMIZING NETWORKS
`25.6 Mobility Robustness Optimization
`The Mobility Robustness Optimization (MRO) SON feature aims at detecting and preventing
`connection failures that occur as a result of mobility. These failures are of four types:
`• Too-late handover, leading to a connection failure in the serving cell;
`• Coverage hole, leading to a connection failure in the serving cell;
`• Too-early handover, leading to a connection failure in the target cell;
`• Handover to an inappropriate cell, leading to a connection failure in the wrong target
`cell.
`
`Connection failure cases generally correspond to Radio Link Failures (RLFs), including
`handover failure. These scenarios and their respective SON solutions are described in more
`detail below.
`
`25.6.1 Too-Late Handover
`When a h