The invention relates generally to handovers.
It is known that handovers are needed in mobile communications when a user equipment (UE) traverses from one cell to another. It takes time and resources to determine whether a handover to a certain cell is allowable and/or beneficial to the UE.
The invention is defined by the independent claims. Some embodiments of the invention are defined in the dependent claims.
One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which
The following embodiments are exemplary. Although the specification may refer to “an”, “one”, or “some” embodiment(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment(s), or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.
Embodiments described may be implemented in a radio system, such as in at least one of the following: Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication System (UMTS, 3G) based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), Long Term Evolution (LTE), LTE-Advanced, and/or 5G system.
The embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties. Another example of a suitable communications system is the 5G concept. 5G is likely to use multiple input-multiple output (MIMO) techniques (including MIMO antennas), many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words, 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as below 6 GHz-cmWave, below 6 GHz-cmWave-mmWave).
In the case of multiple access nodes in the communication network, the access nodes may be connected to each other with an interface. LTE specifications call such an interface as X2 interface. Other communication methods between the access nodes may also be possible. The access node may be further connected via another interface, called S1, to a core network 130 of the cellular communication system. The LTE specifications specify the core network as an evolved packet core (EPC), and the core network may comprise e.g. a mobility management entity (MME) and a gateway node. The MME may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and also handle signalling connections between the terminal devices and the core network 130. The gateway node may handle data routing in the core network 130 and to/from the terminal devices.
The network architecture as depicted in
It should be appreciated that future networks may utilize network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into “building blocks” or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications this may mean node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of functionalities between core network operations and base station operations may differ from that of the LTE or even be non-existent.
Therefore, a new RAN architecture, depicted in
As show in
While the following description is mainly written in the context of the cloud RAN architecture of
Let us consider handovers. The terms handover or handoff refers to the process of transferring an ongoing call or data session from one channel connected to the core network to another channel. Often this requires changing the serving cell from a source cell to a target cell due to mobility of the UE 150 (possible mobility options requiring handover to another cell are depicted with dotted lines in
When dividing the baseband functionality into the two parts as described above and inserting a latency tolerant interface C2 between them, many of the radio protocols are impacted, and care has to be taken to ensure optimal radio performance and preserving the benefit of the multi-layer Cloud RAN architecture. Therefore, in some embodiments, downlink user-plane buffer handling and total preparation and execution time for synchronous handovers are considered. Tight buffer handling is of higher importance in the multi-layer Cloud RAN than in the traditional Distributed RAN architecture as the handover control element (radio resource control, which may be situated in the cloud 140) may see a latency towards the distributed processing element (e.g. realtime physical and medium access control, MAC, procedure) sitting at the RF site 105, 115, 125. Latencies between the two can be significant, e.g. 10 ms round-trip-time (RTT) which impacts significantly the performance of e.g. synchronous handovers.
The concept of synchronous handovers means a handover without random access (RA). This is also known as synchronous RA-less handover. One of the principles is that the involved source and target cell agrees on the time instant of the handover, and informs the UE in advance of that. Until the time of the handover, the UE continues to listen to the source cell (and receives data when scheduled). At the time of the handover, the UE immediately starts to listen to the target cell—and receives data when scheduled. From a physical (PHY) and/or MAC perspective, this implies that the data interruption time during the handover process is limited to in principle only a fraction of a transmission time interval (TTI). However, in a multi-layer Cloud RAN procedure, effective buffer management and flow switching between the source and target cell needs to be supported that takes into account the network latencies of the new architecture.
To better understand this latency aspects, consider
In an embodiment of
It is assumed in the following that the received measurement report indicates that the UE 150 is better off being handed over to another cell (e.g. the cell 102 or to cell 122). The Cloud 140 then in step 308 initiates a handover preparation phase by making a (positive) handover decision and by contacting both the source 112 and the target cell (let us assume that the target cell is the cell 102). In particular the nodes 105 and 115 may be contacted. The nodes 105, 115, as described earlier may comprise distributed baseband elements hosting realtime physical and MAC layer functionalities of the cells 102, 112, respectively. In more details, the cloud 140 in step 310 and 312 causes a handover command to be sent to the UE 150 via the C2 interface (step 310) and via the RRC link between the node 115 and UE 150 (step 312). The command may also include an indication of the time ‘T’, denoting the agreed time of the synchronous handover (T), impacted by communication latencies over the C2 interface connecting the source/target cells with the cloud 140. The command may also comprise uplink allocation for the UE 150. The uplink allocation is for the UE 150 and is valid for transmission to the target cell at the time of the handover (i.e. at the time point T). Consequently, in step 314 the UE 150 makes RRC processing regarding the HO command.
Step 316 may comprise the cloud 140 notifying the target cell 102 about the handover and the time T. The cloud 140 in step 318 performs data forwarding towards the target cell 102, so that the node 105 of the target cell 102 may buffer the downlink data in step 322 until the time point T has been reached. Meanwhile, in step 320, the source cell 112 keeps on transmitting data to the UE 150, since the handover will not be executed until the time T has elapsed/is reached. Time T may be a delay that needs to be waited between the handover command and the time when the UE 150 is finally handed over to the target cell 102, or it may be an absolute time point when the UE 150 is handed over to the target cell 102.
Up till the time T of the handover, the UE 150 continues to receive scheduled data from the source cell's node 115. At the time T of the synchronous handover, the node 115 stops data transmission to the UE 150 in step 324. Thereafter, the UE 150 immediately starts to listen to the target cell 102. The UE 150 makes reconfiguration to the new cell 102 at point 326 and the reconfiguration complete indication is transmitted via the target cell 102 to the cloud 140 in steps 330 and 332. The target cell 102 may also perform TTI alignment for the UE 150, although not shown for simplicity. Since the target cell 102 has already buffered the DL data to the UE 150, the target cell 102 can in step 334 start data transmission to the UE 150.
As can be seen from above, one of the envisaged problems in the illustrated scenario relates to latencies in-built into the system when implementing the synchronous handover directly onto the new architecture. The latency between receiving a measurement report at the source cell until the source cell can communicate the handover command to the UE is long as it includes involving the cloud that only communicates to the source cell via the C2 interface that can have long latencies. One possible solution might be to distribute the handover decision to the access nodes but that might remove the benefit of the C-RAN architecture in terms of reducing the handover preparation time compared to traditional distributed architecture (because the processing of handover decision and admission control can be in C-RAN done in parallel by the same physical entity).
In view of the above mentioned problems, there is proposed a solution that not only maintains the core benefits of the multi-layer cloud RAN (i.e. C-RAN) architecture in terms of synchronous handover but may further improve the performance significantly.
In step 400, the method comprises the source node 115 maintaining a list of candidate target cells for a handover. The candidate target cells (or simply candidate cells or target cells) may comprise e.g. all the neighbouring cells to the source cell 112. The list may be a table, database, matrix, or in whatever form comprising information per cell. The list comprises for each candidate target cell an indication of whether a handover to the candidate target cell is allowed or not. The list may be called an early admission matrix, for example.
Upon receiving a handover request from a UE 150 (locating in the source cell 112) to a candidate target cell for which a handover is determined as allowable in the list, the node 115 may in step 402 trigger the handover to the candidate target cell without negotiating regarding the request with a network element associated with the candidate target cell. The handover that is determined as allowable in the list may be called an early admission control handover, since the admission can be controlled/performed in an early stage, i.e. without discussion whether the request should be allowed or not—the source cell can make the decision by itself immediately after receiving the request. In an embodiment the handover is a synchronous handover. In an embodiment, triggering the handover in step 402 comprises sending a handover command to the UE 150 and sending a handover indication/notification to the network element associated with the candidate target cell.
The network element associated with the candidate target cell may be e.g. the central network element (i.e. the cloud 140 of
An example of the list is shown in Table 1 below. The use of the proposed table reduces latencies and may be called an early admission control scheme that enables any source cell to work autonomously in relation to synchronous handovers and bypass latency components (e.g. the C2 interface) of the traditional synchronous handover procedure.
Owing to the proposal, the source cell's network node is able to do the admission control without consulting the cloud first. The source cell is allowed to do so, because the cloud has given it a permission to do so. If the proposal is translated into the typical D-RAN solution of
Each source cell under the cloud's control may be provided with a table/list/matrix (where the source cell itself is listed as a source cell) and all the tables are maintained, controlled, and distributed by the cloud 140. The table may include other parameters, e.g. quality of service (QoS) constrained early admission parameters, physical layer parameters of the target cell needed for the source cell to build and possibly include in the handover command, but for simplicity these have been left out from Table 1.
Let us take a closer look at the table through an example. In this example it is assumed that the UE 150 sends a measurement report that it would like to initiate a handover to target cell with ID 44****22. Upon receiving this request, the source cell with ID 44****96 may immediately respond positively to the request and start the handover preparation with the UE 150. This is because the list, called as Early Admission Matrix, has a “Yes” in the allowed column, e.g. the cloud 140 knows the availability and load of the requested target cell with ID 44****22 (from monitoring it and updating the Early Admission Matrix table when needed). For other cells, early admission may not be tolerated, as example early handover preparation towards a target cell with ID 43****44 is not allowed in the given example.
As shown, the list may be specific to a given source cell. This aids in keeping the size of the cell feasible to be transmitted over the C2 interface since only information relevant to the specific source cell 112 is transmitted, instead of transmitting a large list indicating all source cells.
In an embodiment, the list further comprises, at least for each candidate target cell to which a handover is determined as allowable (and possibly to all listed target cells), a target cell-specific timing information indicating when a handover to the candidate target cell takes place after being triggered. Referring to
In an embodiment, triggering the handover in step 402 further comprises indicating the corresponding timing information T to the UE 150. E.g. if the UE 150 requests handover to the cell with ID 44****22, the triggering may comprise the source cell element indicating a value of 15 ms to the UE as the parameter T. Then the UE 150 knows that after 15 ms, the UE 15 can switch to receive data from the target cell. As described above, in an alternative embodiment, the time T may be given as an absolute time point. This may provide increased reliability, since the time it takes for the UE 150 to correctly receive the HO command may vary, depending on whether e.g. a retransmission is required or not.
In an embodiment, the timing information for a given candidate target cell is based on communication latency between the source cell and the corresponding candidate target cell. As said, there may be a cloud 140 in-between, when the network architecture is according to
In an embodiment, the allowability of a handover to a given candidate target cell is based on at least one of the following: load of the candidate target cell, success rate of previous handovers to the candidate target cell.
Regarding the load, the cloud 140 may be aware of those due to load based measurements received from all connected cells (periodic, or event triggered). E.g. if one cell has too high load to blindly receive incoming traffic without “normal” admission control, it may indicate so to the cloud/source cell and the Early Admission Matrix would then include/update all rows with that cell as the target cell to “Not Allowed”. On the other hand, if the load in the cell is feasible (under certain load threshold, for example), then the cloud 140 may determine that the early handover admission to that cell as the target cell may be allowed.
Regarding the success rate, each conducted early admission event may be monitored in terms of success rates, to ensure that the table provides for a robust network. E.g. some handover pairs may be too unstable for Early Admission handovers due to instable channel conditions, in which case the list would indicate that handover relating to such a handover pair is not allowed.
It may be noted that the criteria for allowing the early admission handover to the cell comprise aspects related to the time-varying conditions of the target cell in question, and thus the handover allowability status of a given cell may vary in time, e.g. as the traffic condition of the cell varies. In an embodiment, the allowability of a cell is not dependent on the type of the cell, e.g. on the CSG status.
In an embodiment, the list may be generated as a result of a negotiation with at least one network element associated with the candidate target cells prior to the UE 150 requests a handover. E.g. the negotiation may be among many eNBs of neighbouring cells in a distributed RAN of
Alternatively, in an embodiment, the list may be received from the cloud 140, as shown with reference numeral 410. This allows the cloud 140 to control the Early Admission control behaviour of its source cells by means of distributing the semi-static Early Admission table/list/matrix. When the list comes from the cloud 140, the cloud 140 may generate the list based on knowledge and measurements of cells under the control of the cloud 140 and then distribute to each cell a relevant list where the receiving cell is marked as a source cell, and relevant neighbouring cells are marked as candidate target cells.
In an embodiment, the list is valid for each user equipment in the source cell. Therefore, the source need not maintain a list for each specific UE separately, which may vary due to CSG restrictions per UE, for example. However, it is proposed that the UE already knows its restrictions and does not propose a handover to a cell which is blacklisted for the UE. In other words, the UE has a certain measurement configuration from which the measurement report of steps 302 and 304 is formed, but the UE does not include the blacklisted cells to the measurement report. Alternatively, the source cell knows which cells are blacklisted for each UE, so that the source cell does not allow an early handover to any blacklisted cell.
In an embodiment, the source element 110/115 may receive update information for the list in step 414 from the network element associated with a given candidate target cell. The update may be regarding the early admission handover allowability of the given candidate target cell and/or regarding the timing information of the given candidate target cell. It is also possible to update any other data content of the list. This allows for performance optimization of the network, e.g. optimizing the setting for the handover time (T) based on knowledge of source and target cell conditions. There may be e.g. an outer loop procedure managed by the cloud 140. As the cloud 140 have the “helicopter view” and knows the different cell sites configuration, capabilities, load conditions, etc., it has all the knowledge to determine when new early admission tables (with updated information) should be pushed to the source cell sites.
Updates of the Early Admission Matrix/list/table may be triggered by predetermined events. E.g. the update may be based on e.g. predetermined changes in a load condition of the cell, predetermined changes in latency conditions, predetermined changes in success rates of previous handovers, or due to establishing a new handover pair (e.g. when a UE requests handover to a target cell not yet in list, the list can be updated with a new pair). Therefore, in one an embodiment, the source node 110/115 may detect that a handover request is to a target cell not included in the list. Consequently the source node may send a message to the cloud (or in general to the network element/node associated with the new target cell), the message including a request for adding the new target cell to the list and responding with an update. The source node may know the network element associated with the new target cell based on the ID of the target cell, for example. As a consequence of any of the updates received by the source cell, the source cell may update the list accordingly, as shown with reference numeral 400 in
Further referring to
From the point of view of the cloud 140 (in case of C-RAN) or the target cell's network element 100/120 (in case of D-RAN), the method as shown in
In case of the cloud 140 providing the information, the allowability information may be given for each target cell (from the point of view of the source cell in question) that is under the control of the cloud 140. The timing information may be given to all target cells or only to those that are determined as allowable to keep the required space of the list smaller. On the other hand, providing the delay information to the source node for all target cells may be beneficial because if the previously not-allowed target cell becomes allowed, then the source node already knows the delay value (in case of update is needed, the cloud 140 may provide such). In case of D-RAN, the base station of the target cell providing the information only provides information related to that target cell, since it may not be aware of the allowability and delay (i.e. T) status of any other target cell.
In an embodiment, the information for the list is provided prior to any UE requesting a handover from the source cell. In an embodiment, the list is provided or generated as part of the initial cell configuration setup, or at any time after the cell is switched on (activated). This way the benefits of the proposal with respect to reducing latencies for synchronous handovers can be taken into full advantage.
To understand the improvement to the handover procedure that follows from using proposed approach, let us take a look at a flow diagram in
In more details, in step 600 of
The source node 115 further notifies the handover to the cloud 140 in step 604 along with indication of the target cell in question. The cloud 140 then notifies in step 606 the target node 105 of the relevant target cell that a handover of this specific UE 150 will take place after the earlier agreed delay T (or at the time T, in case of absolute time instant for the handover instead of delay). The timing information T may be indicated to the target cell 102 in step 606. In an embodiment, the timing information is already known by the target node 105 in which case the timing information T need not be indicated to the target cell at this point. The target node 105 may know the timing T based on its own measurements of channel and traffic conditions of the cell 102, or based on information received from the cloud 140. For simplicity,
The rest of the procedure runs as described in
In an embodiment, if the early admission handover to the most suitable target cell is not allowed, the source node 115 may determine whether the early admission handover is allowable to another target cell for which the early admission handover is allowable. Then the source node 115 may decide, instead of following the process of
Also it may be worth noting that the
When looking at
According to simulations, the handover preparation is improved compared to the prior art implementation for various values for C2 RTT latency. It can be seen from the simulations that the proposed scheme significantly improves the handover preparation performance versus both the D-RAN and the C-RAN implementations. Performance improvements are 30-60% depending on interface delays and assumption related to RRC processing time for the UE 150. Naturally exchanging all the relevant information between the cell sites and the cloud in order to push and maintain/update the HO tables does present some complexity. But, it should be noted that this complexity, means that the usual signalling between the source and target cells may be avoided, and also the proposed invention offer latency reductions.
In further embodiment, the interface (C2 in case of C-RAN or X2 interface in case of D-RAN) may be extended to allow for the exchange of Early Admission Matrix/table/list in robust manner as well as for exchanging measurements needed to maintain the tables.
Network Element behaviour may be optimized as well. E.g. there may be certain rules that prevent a given source cell to behave autonomously. One example may be that if the Early Admission Matrix/table/list has not been updated during a certain predetermined time period, the list may be considered as expired and the early admission may not be allowed based on that list. In other words, the list may have an expiration time, which may be renewed or updated when the table is updated. As another and/or additional option, the list may be valid only when certain predefined acknowledgements are respected. For example, the reception of the list from the cloud may require that acknowledgements are sent from the source to the cloud, and possibly also from the cloud to the source, to make sure that any fraudulent behaviour is avoided/reduced.
As explained before, the proposal may be implemented in the distributed RAN architecture to achieve similar benefit but without assumption of cloud RAN. E.g. each source cell would by itself maintain its own Early Admission Matrix by exchanging information with its target cells. E.g. such information would be exchanged across X2 interface. Also behavioural rules for the individual eNBs, if required, may be communicated. In D-RAN it may be that more measurements are need to be exchanged to keep local handover tables up to date. E.g. load measurements may be exchanged regularly between cells. In the cloud RAN architecture, the cloud 140 may already monitor all of its connected cells (including monitoring load by watching user plane traffic going through the cell) and the implementation in C-RAN requires less signalling. Anyway, the benefit of the proposal would still apply to the Distributed RAN case, since the two way communication over the X2 interface between the source and target cell regarding whether or not to allow the handover request may be avoided in cases where early admission handover is allowed for the requested target cell.
It should be noted that the proposal is different from closed subscriber group (CSG) related solutions, where e.g. CSG list indicates which cells a given UE should (or shouldn't) include in a measurements report. However, if the cell is included in the report (because it belongs to the CSG list or because is not included in any blacklist), the network still has to apply the traditional handover decision algorithms and admission control, resulting in latencies which are avoided or at least reduced in the current proposal. Therefore, the current proposed list of Table 1 may be seen as a supplement to this CSG or any other type of “cell filtering”, as it affects to those cells that are already in the allowed list. Additionally, the table includes information about the cells that support the early admission mechanism. So, it provides more information than an allowed/blocked cell. It also provides information about what type of handover mechanism (early admission control of
An embodiment, as shown in
In an embodiment, the apparatus 700 may be or be comprised in a base station (also called a base transceiver station, a Node B, a radio network controller, or an evolved Node B, for example). In an embodiment the apparatus is or is comprised in the eNB 110 of the source cell 112.
In an embodiment, the apparatus 700 is comprised in a remote radio head operatively coupled (e.g. via wired or wireless interface) to a control unit, e.g. the central element 140. In an embodiment the apparatus 700 is or is comprised in the access node 115 of the source cell 112.
The apparatus 700 may further comprise communication interface (TRX) 706 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to access the radio access network and communicate with UEs, for example. The TRX may comprise wireless and/or wired communication capabilities.
The control circuitry 710 may comprise a management circuitry 712 for managing and/or updating/receiving the early admission list according to any of the embodiments. A handover control circuitry 714 may then control the handover admission at least partly based on the list according to any of the embodiments.
An embodiment, as shown in
In an embodiment, the apparatus 800 may be or be comprised in a base station (also called a base transceiver station, a Node B, a radio network controller, or an evolved Node B, for example). In an embodiment the apparatus is or is comprised in the eNB 100/120 of the target cell 102/122.
In an embodiment, the apparatus 800 is comprised in a control unit (e.g. the cloud 140) operatively coupled to a remote radio head. In an embodiment the apparatus 800 is or is comprised in the cloud 140.
The apparatus 800 may further comprise communication interface (TRX) 806 comprising hardware and/or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to access the radio access network and communicate with UEs, for example. The TRX may comprise wireless and/or wired communication capabilities.
The control circuitry 810 may comprise a generation circuitry 812 for at least partly creating and updating the early admission list according to any of the embodiments. A provision circuitry 814 may then provide information for the list to the source cell(s), according to any of the embodiments
The apparatuses 700, 800 may also comprise user interfaces comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. Each user interface may be used to control the respective apparatus by the user.
In an embodiment, an apparatus carrying out at least some of the embodiments described comprises at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to carry out the functionalities according to any one of the embodiments described. According to an aspect, when the at least one processor executes the computer program code, the computer program code causes the apparatus to carry out the functionalities according to any one of the embodiments described. According to another embodiment, the apparatus carrying out at least some of the embodiments comprises the at least one processor and at least one memory including a computer program code, wherein the at least one processor and the computer program code perform at least some of the functionalities according to any one of the embodiments described. Accordingly, the at least one processor, the memory, and the computer program code may form processing means for carrying out at least some of the embodiments described. According to yet another embodiment, the apparatus carrying out at least some of the embodiments comprises a circuitry including at least one processor and at least one memory including computer program code. When activated, the circuitry causes the apparatus to perform the at least some of the functionalities according to any one of the embodiments described.
As used in this application, the term ‘circuitry’ refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of circuits and soft-ware (and/or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s)/software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term in this application. As a further example, as used in this application, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and/or firmware. The term ‘circuitry’ would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.
In an embodiment, at least some of the processes described may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiplecore processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry.
The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set (e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.
Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments described may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.
In the following some embodiments are disclosed.
One embodiment includes maintaining, by a network element of a source cell, a list of candidate target cells for a handover, the list comprising for each candidate target cell an indication of whether a handover to the candidate target cell is allowed or not; and upon receiving a handover request from a user equipment to a candidate target cell for which a handover is determined as allowable, triggering the handover to the candidate target cell without negotiating regarding the request with a network element associated with the candidate target cell. In one embodiment, triggering the handover comprises sending a handover command to the user equipment and sending a handover indication to the network element associated with the candidate target cell. In one embodiment, the list further comprises, for each candidate target cell to which a handover is determined as allowable, a target cell-specific timing information indicating when a handover to the candidate target cell takes place after being triggered, and the triggering further comprises indicating the corresponding timing information to the user equipment. In one embodiment the timing information for a given candidate target cell is based on communication latency between the source cell and the corresponding candidate target cell. One embodiment includes upon receiving a handover request from a user terminal to a candidate target cell that is determined as not-allowable, triggering a negotiation with the network element associated with the candidate target cell regarding accepting or not accepting the handover request. In one embodiment, the list is a result of a negotiation with at least one network element associated with the candidate target cells prior to the user equipment requesting a handover. In one embodiment, the allowability of the handover to a given candidate target cell is based on at least one of the following: load of the candidate target cell, success rate of previous handovers to the candidate target cell. One embodiment includes receiving update information for the list from the network element associated with a given candidate target cell; and updating the list accordingly. One embodiment includes detecting that a handover request from the user equipment is to a target cell not included in the list; and sending a message to a network element associated with the target cell, the message including a request for adding the target cell to the list and responding with an updated list. In one embodiment, the network element associated with the candidate target cell is a central network element controlling a plurality of cells including the source cell and the candidate target cell, and the communication between the source cell and the candidate target cell is via the central network element.
One embodiment includes providing, to a network element of a source cell by a network element associated with at least one candidate target cell of a handover, information for a list of candidate target cells, the list comprising for each candidate target cell an indication of whether a handover request to the candidate target cell can be allowed or not without the network element of a source cell negotiating regarding the request with the network element associated with the candidate target cell. One embodiment includes additionally providing, for each candidate target cell to which a handover is determined as allowable, a target cell-specific timing information indicating when a handover to the candidate target cell takes place after being triggered. In one embodiment the network element associated with at least one candidate target cell is a central network element controlling a plurality of cells including the source cell and the at least one candidate target cell, wherein communication between the source cell and the at least one candidate target cell is via the central network element. In one embodiment, the list is provided prior to a user equipment requesting a handover from the source cell.
In one embodiment there is provided an apparatus, comprising at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause a network element of a source cell to perform operations comprising: maintaining a list of candidate target cells for a handover, the list comprising for each candidate target cell an indication of whether a handover to the candidate target cell is allowed or not; and upon receiving a handover request from a user equipment to a candidate target cell for which a handover is determined as allowable, triggering the handover to the candidate target cell without negotiating regarding the request with a network element associated with the candidate target cell. In one embodiment, triggering the handover comprises sending a handover command to the user equipment and sending a handover indication to the network element associated with the candidate target cell. In one embodiment, the list further comprises, for each candidate target cell to which a handover is determined as allowable, a target cell-specific timing information indicating when a handover to the candidate target cell takes place after being triggered, and the triggering further comprises indicating the corresponding timing information to the user equipment. In one embodiment the timing information for a given candidate target cell is based on communication latency between the source cell and the corresponding candidate target cell. In one embodiment the at least one memory and the computer program code are configured, with the at least one processor, to cause the network element of the source cell further to perform operations comprising: upon receiving a handover request from a user terminal to a candidate target cell that is determined as not-allowable, triggering a negotiation with the network element associated with the candidate target cell regarding accepting or not accepting the handover request. In one embodiment, the list is a result of a negotiation with at least one network element associated with the candidate target cells prior to the user equipment requesting a handover. In one embodiment, the allowability of the handover to a given candidate target cell is based on at least one of the following: load of the candidate target cell, success rate of previous handovers to the candidate target cell. In one embodiment, the at least one memory and the computer program code are configured, with the at least one processor, to cause the network element of the source cell further to perform operations comprising: receiving update information for the list from the network element associated with a given candidate target cell; and updating the list accordingly. In one embodiment, the at least one memory and the computer program code are configured, with the at least one processor, to cause the network element of the source cell further to perform operations comprising: detecting that a handover request from the user equipment is to a target cell not included in the list; and sending a message to a network element associated with the target cell, the message including a request for adding the target cell to the list and responding with an updated list. In one embodiment, the network element associated with the candidate target cell is a central network element controlling a plurality of cells including the source cell and the candidate target cell, and the communication between the source cell and the candidate target cell is via the central network element.
In one embodiment there is provided an apparatus comprising: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform operations comprising: providing, to a network element of a source cell, information for a list of candidate target cells, the list comprising for each candidate target cell an indication of whether a handover request to the candidate target cell can be allowed or not without the network element of a source cell negotiating regarding the request with the apparatus. In one embodiment, the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus further to perform operations comprising: additionally providing, for each candidate target cell to which a handover is determined as allowable, a target cell-specific timing information indicating when a handover to the candidate target cell takes place after being triggered. In one embodiment, the apparatus is or is comprised in a central network element controlling a plurality of cells including the source cell and the at least one candidate target cell, wherein communication between the source cell and the at least one candidate target cell is via the central network element. In one embodiment, the list is provided prior to a user equipment requesting a handover from the source cell.
In one embodiment, there is provided an apparatus, comprising means for performing the method according to any of appended claims. In one embodiment, the apparatus comprises at least one processor; and at least one memory comprising computer program code, and wherein the at least one memory and the computer program code are configured, with the at least one processor to cause the apparatus to provide said means.
In one embodiment there is provided an apparatus, comprising processing means configured to cause the apparatus to perform the method according to any of appended claims.
In one embodiment there is provided a computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute the method according to any of appended claims.
In one embodiment there is provided a computer program product comprising program instructions which, when loaded into an apparatus, execute the method according to any of appended claims.
Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/FI2016/050741 | 10/21/2016 | WO | 00 |