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-00648
`Apple EX1023 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-00648
`Apple EX1023 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-00648
`Apple EX1023 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-00648
`Apple EX1023 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-00648
`Apple EX1023 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-00648
`Apple EX1023 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-00648
`Apple EX1023 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 handover is executed too late, a connection failure may occur in the source cell
`and the UE may try to re-establish the radio link in a different cell controlled by a different
`eNodeB, as illustrated in Figure 25.4. In order to enable eNodeB of the source cell to improve
`the situation, an ‘RLF INDICATION’ message can be used to report the event from the
`eNodeB under which the UE re-establishes the connection to the original source eNodeB.
`The message includes the PCI of the cell in which the connection failed, the CGI of the cell
`where the radio link was re-established and the identity (C-RNTI13) that the UE had in the cell
`where the connection failed. The message may also include the short MAC-I bits14 to allow
`verification of UE identity at the source eNodeB: the source eNodeB can recalculate these
`bits using the security configuration of the source cell. This mechanism makes it possible
`to eliminate false RLF detections that could happen due to PCI collision, for example. If
`a PCI collision occurs, an eNodeB would typically send the ‘RLF INDICATION’ message
`to multiple neighbour eNodeBs which all control cells with the same PCI, but the use of
`the short MAC-I bits enables only the source cell in which the RLF had really occurred to
`concern itself about the too-late handover.
`
`25.6.2 Coverage Hole Detection
`Receiving the ‘RLF INDICATION’ message at a source eNodeB might be caused either
`by a connection failure due to a too-late handover from the source to the target cell or
`by a coverage hole at the edge of the source cell. In order to improve the operation of
`the ‘too-late handover’ counter in the source eNodeB, it is useful to discriminate between
`these two scenarios. Hence, after completing the re-establishment procedure in the eNodeB
`where the connection is re-established, the UE may indicate to this eNodeB whether it can
`report the last cell measurements it has performed before the connection failed. If this is
`possible, this eNodeB may retrieve an ‘R9 UE RLF Report’ measurement and add it into the
`‘RLF INDICATION’ message sent to the source eNodeB. By evaluating the measurements
`
`13Cell-Radio Network Temporary Identifier.
`14The 16 least-significant bits of the Message Authentication Code for Integrity (MAC-I, see Section 4.2.3).
`
`IPR2022-00648
`Apple EX1023 Page 657
`
`

`

`592
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`Target Cell
`
`Source Cell
`
`Time
`
`Connection failure in target cell
`
`UE attempts to re-establish in original cell
`
`Sgna Strength
`
`Figure 25.4: Example of signal strength fluctuation in the source and target cells during
`handover.
`
`contained in this report, the source eNodeB should be able to determine if the connection
`failure was actually due to a coverage hole or not.
`
`25.6.3 Too-Early Handover
`When a handover is executed too early, the UE may experience a connection failure in the
`target cell due to fluctuations of the radio signal in cell B as illustrated in Figure 25.4, and
`will try to re-establish the radio link in the original source cell. Since the source eNodeB
`would have deleted all contexts related to that UE when the handover was completed, the
`re-establishment in the source cell would result in the source eNodeB sending an ‘RLF
`INDICATION’ message to the target eNodeB, exactly as if a too-late handover had taken
`place in the opposite direction. However, the target eNodeB can still discriminate the too-
`early handover from a too-late handover in the other direction if it had previously started a
`timer Tearly on the incoming handover of the UE and notices that the ‘RLF INDICATION’
`message is received from the same source cell and for the same UE before Tearly expires. The
`implementation of the SON remedy for too-early handover therefore requires both a new
`timer to be run in the target eNodeB and a new message, ‘HANDOVER REPORT’, to be
`sent from the target eNodeB B to the source eNodeB in response to the ‘RLF INDICATION’
`message, to signal to the source eNodeB that the source cell had a too-early handover problem
`towards the target cell rather than a ‘too-late’ handover problem.
`These examples also show that implementations of SON remedies for too-late and too-
`early handover are best implemented in conjunction with each other as a comprehensive
`solution in order to avoid wrong MRO verdicts.
`
`25.6.4 Handover to an Inappropriate Cell
`Handover to an inappropriate cell shares some similarities with the too-early handover
`described above. Consider an example where a UE moves from a cell A of eNodeB A to
`
`IPR2022-00648
`Apple EX1023 Page 658
`
`

`

`SELF-OPIIMIZING NETWORKS
`
`593
`
`a cell B of eNodeB B, but traverses a small overlap area in which a cell C of eNodeB C
`presents the strongest signal. This scenario is illustrated in Figure 25.5.
`
`
`
`Figure 25.5: Handover to an inappropriate cell.
`
`In this scenario, eNodeB A may be tempted to trigger the handover to cell C, but if the
`period for which cell C is the strongest is too short this could result in the UE experiencing
`a connection failure in cell C and re-cstablishing the radio link in the real suitable target cell
`B. However, the problem can again easily be reported to the originating eNodeB A: When
`the UE re-establishes the radio link in cell B, eNodeB B will send an ‘RLF INDICATION’
`
`message to eNodeB C for that UE before the timer Tm, expires in cell C, indicating
`the originating cell A. Then eNodeB C can send a ‘HANDOVER REPORT’ message to
`eNodeB A to inform it about the inappropriate handover to cell C. eNodeB A can then
`take appropriate conective action if it receives multiple similar reports. The ‘HANDOVER
`REPORT" message can also be sent from eNodeB C to eNodeB A over the X2 interface, even
`when both cells B and C belong to the same eNodeB and the ‘RLF INDICATION’ was thus
`internal to that eNodeB.
`
`It can be noticed that the same ‘HANDOVER REPORT" message is used to report the
`two MRO verdicts of too-early handover and handover to inappropriate cells, an information
`element ‘type of handover problem’ is used within the message to discriminate between these
`two cases.
`
`25.6.5 MRO Verdict Improvement
`
`As mentioned above, discrimination between a ‘too-late handover’ and a ‘coverage hole’
`MRO verdict requires that the eNodeB where the UE re—establishes the connection after
`
`Samsung Ex. 1010
`1195 of 1365
`
`IPR2022-00648
`Apple EX1023 Page 659
`
`

`

`594
`
`LTE – THE UMTS LONG TERM EVOLUTION
`
`the connection failure wait for the completion of the re-establishment and retrieve some
`measurements from the UE (the ‘R9 UE RLF Report’) before it can send the ‘RLF
`INDICATION’ message. As a result, this message may arrive late and hence confuse the
`MRO verdict between too-late, too-early and wrong cell handover. In order to remove this
`dependency on the timing of the network delivery of the ‘RLF INDICATION’ message, the
`‘R9 UE RLF Report’ was extended in Release 10 to include the ‘Time elapsed since the last
`handover initialization until connection failure’. Since this timer runs in the UE, its value is
`independent of network delivery conditions and therefore more accurate. When receiving the
`‘RLF INDICATION’ message, the source eNodeB will compare this new timer (instead of
`the Release 9 timer Tearly described above) to an internal threshold and thus obtain a more
`accurate verdict between the three MRO types (too-late, too-early and wrong cell).
`
`25.6.6 Handover to an Unprepared Cell
`Release 10 further extends the scope of MRO to cover the case where, after a connection
`failure, the UE is in idle mode when it re-connects to the network, either because the RLF
`took too long or simply because the UE first tried to re-establish the connection on a target
`cell that was unprepared and hence the re-establishment failed. In such scenarios, a network
`context cannot be relied upon, and therefore the Release 9 MRO detection scheme cannot be
`used. Therefore Release 10 includes an equivalent context-less MRO solution:
`
`1. A Release 10 UE starts a log when connection failure occurs, containing the following
`items:
`
`• The information contained in the Release 9 UE RLF report;
`• The new timer defined for the MRO verdict improvement (see Section 25.6.5),
`which measures the time elapsed since the last handover initialization until the
`connection failure;
`• The identity of the last cell that served the UE;
`• The identity of the cell which received the first (unsuccessful) re-establishment
`attempt;
`• The identity of the cell that served the UE at the last handover initialization.
`
`2. The UE starts this log at connection failure detection and delivers it when it re-connects
`to the network from idle mode over the newly established Radio Resource Control
`(RRC) connection. By analysing the UE’s log, the network can obtain all the elements
`to make a verdict between too-late handover, too-early handover, wrong-cell handover
`or coverage hole, despite the fact that the UE had transitioned through idle mode.
`
`25.6.7 Unnecessary Inter-RAT Handovers
`MRO was also extended in Release 10 to cover inter-RAT scenarios. The unnecessary inter-
`RAT handover scenario addresses the case where a UE is handed over from LTE to another
`RAT (e.g. UMTS or GSM) despite the fact the quality of the LTE coverage was actually good
`enough and would have allowed the UE to remain on LTE. This can be seen as a too-early
`handover to another RAT with no connection failure; it may affect the user experience if the
`
`IPR2022-00648
`Apple EX1023 Page 660
`
`

`

`SELF-OPTIMIZING NETWORKS
`
`595
`
`other RAT offers lower performance and the UE cannot easily reconnect to LTE; it may also
`lead to a non-optimal use of network resources. It is typically due to the handover threshold
`for the LTE serving cell being set too high.
`Such unnecessary inter-RAT handovers are detected by the target RAN node when
`triggered by the source eNodeB. The source eNodeB first requests the target RAN node
`during the inter-RAT Handover Preparation procedure to instruct the UE to continue
`measuring the LTE cells. It also provides the duration for which these measurements should
`continue and a minimum reference quality above which the target RAN node is allowed to
`report. It may also provide a list of selected LTE frequencies, for example to minimize the
`impact of compressed mode while in UMTS. Then, whenever the target RAN node receives a
`UE measurement above this threshold for one LTE cell for a sufficient period of time, it marks
`this LTE cell as to be reported. The reporting phase is performed by the target RAN node:
`when the measurement duration ends, the target RAN node sends a report (using a generic
`SON transfer container on top of the RIM protocol) to the originating LTE cell containing
`the results of the measurements – i.e. the list of LTE cells whose quality the UE measured to
`be above the configured threshold. Upon reception of the report, the originating eNodeB can
`take further corrective action, such as deciding if and how its parameters (e.g. the threshold
`to trigger inter-RAT handover) should be adjusted.
`
`25.6.8 Potential Remedies for Identified Mobility Problems
`Whenever the mechanisms described above are used in a network to detect such connection
`failure scenarios between cells, the source eNodeB may take some appropriate actions to
`combat them. For instance, in the case of repeated too-late or too-early handovers, one
`possible action could be to change the threshold at which the handovers are triggered. The
`source eNodeB can then use the same ‘Mobility Settings Change’ procedure as for MBL
`scenarios to inform the neighbour eNodeB of the change of threshold it has performed.
`In this case the ‘MOBILITY CHANGE REQUEST’ message is sent with a cause value
`‘hando