The present specification relates to inter-cell proactive co-ordination in telecommunication systems, for example based on latency data.

Background

Devices within a cell of a mobile communication system may have different latency budgets. Similarly, devices of neighbouring cells may have different latency budgets. There remains a need for allocating resources in such communication systems.

Summary

In a first aspect, this specification describes an apparatus comprising means for performing: generating a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; sending selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); receiving second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and generating a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data. In this way, the multi-cell outage time database may store time to outage data for a plurality of devices served by the plurality of cells of the mobile communication system. The multi cell outage time database may, for example, be a modified version of the local outage time database (including some or all of the other updates from other cells). In some example embodiments, the means are further configured to perform: sorting the multi-cell outage time database in order of time left to outage data (e.g. in ascending order). Sorting the multi-cell outage time database in this way may enable the determination of a cell latency priority amongst a plurality of cells of the mobile communication system. In some example embodiments the means are further configured to perform: identifying the cell serving the device having the shortest time left to outage as a highest priority cell amongst the first cell and the other cell(s). The said means may be further configured to perform providing inter-cell co-ordination based on the identified highest priority cell. Byway of example, providing inter-cell co ordination may comprise: determining whether the first cell is lightly loaded; and in the event that the first cell is not the highest priority cell and is lighted loaded, sending an offloading proposal to the identified highest priority cell proposing offloading of one or more latency-critical devices from the highest priority cell to the first cell. The means maybe further configured to perform: initiating the offload of said one or more latency- critical device on receipt of an acceptance of said offloading proposal from the identified highest priority cell. As noted above, the said means may be further configured to perform providing inter cell co-ordination (e.g. based on the identified highest priority cell). By way of example, providing inter-cell co-ordination may comprise: determining whether the first cell is highly loaded; and in the event that the first cell is not the highest priority cell and is highly loaded, sending muting proposal to the identified highest priority cell. The means may be further configured to perform: initiating muting of said first cell on receipt of an acceptance of said muting proposal from the highest priority cell.

In some example embodiments, providing inter-cell co-ordination comprises: receiving, at the first cell (e.g. the highest priority cell), an offload proposal or a muting proposal from one or more of said one or more other cells of the mobile communication system; and responding to said request in accordance with a protocol.

In some example embodiments, the means are further configured to perform: determining the selected parts of the local outage time database to send to the one or more other cells of the mobile communication network (e.g. by determining local outage time database entries with times left to outage below a threshold).

Sending said selected parts of the local outage time database to said one or more other cells of the mobile communication network may comprise sending an update message via an Xn interface of the communication system. In some example embodiments, the means are further configured to perform: identifying cells of the one or more other cells of the mobile communication system as aggressor cells in the event that signal power at the first cell from said other cell compared with signal power received at the first cell from a server node is above a threshold.

The local outage time database for the first cell may store one or more of: a cell identifier for the first cell; an identifier for each of the plurality of devices served by the first cell; time left to outage data for each of said devices (e.g. per radio bearer per device); a link direction for each of the devices; and cell identifier for any identified aggressor cells.

Each entry of the multi-cell outage time database may comprise: a cell identifier; a device identifier; a time left to outage for the respective device; and a link direction for each of the devices.

The said means may comprise: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured, with the at least one processor, to cause the performance of the apparatus.

In a second aspect, this specification describes a method comprising: generating a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; sending selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); receiving second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and generating a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data. The method may comprise: sorting the multi-cell outage time database in order of time left to outage data (e.g. in ascending order). The method may comprise: identifying the cell serving the device having the shortest time left to outage as a highest priority cell amongst the first cell and the other cell(s). The method may comprise providing inter-cell co-ordination based on the identified highest priority cell. By way of example, providing inter-cell co-ordination may comprise: determining whether the first cell is lightly loaded; and in the event that the first cell is not the highest priority cell and is lighted loaded, sending an offloading proposal to the identified highest priority cell proposing offloading of one or more latency-critical devices from the highest priority cell to the first cell. The method may comprise: initiating the offload of said one or more latency-critical device on receipt of an acceptance of said offloading proposal from the identified highest priority cell.

Alternatively, or in addition, providing inter-cell co-ordination may comprise: determining whether the first cell is highly loaded; and in the event that the first cell is not the highest priority cell and is highly loaded, sending muting proposal to the identified highest priority cell. The method may comprise: initiating muting of said first cell on receipt of an acceptance of said muting proposal from the highest priority cell. In some example embodiments, providing inter-cell co-ordination comprises: receiving, at the first cell (e.g. the highest priority cell), an offload proposal or a muting proposal from one or more of said one or more other cells of the mobile communication system; and responding to said request in accordance with a protocol. The method may comprise: determining the selected parts of the local outage time database to send to the one or more other cells of the mobile communication network (e.g. by determining local outage time database entries with times left to outage below a threshold). Sending said selected parts of the local outage time database to said one or more other cells of the mobile communication network may comprise sending an update message via an Xn interface of the communication system.

The method may comprise: identifying cells of the one or more other cells of the mobile communication system as aggressor cells in the event that signal power at the first cell from said other cell compared with signal power received at the first cell from a server node is above a threshold.

In a third aspect, this specification describes an apparatus configured to perform any method as described with reference to the second aspect.

In a fourth aspect, this specification describes computer-readable instructions which, when executed by computing apparatus, cause the computing apparatus to perform any method as described with reference to the second aspect.

In a fifth aspect, this specification describes a computer program comprising instructions for causing an apparatus to perform at least the following: generating a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; sending selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); receiving second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and generating a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data. In a sixth aspect, this specification describes a computer-readable medium (such as a non-transitory computer-readable medium) comprising program instructions stored thereon for performing at least the following: generating a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; sending selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); receiving second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and generating a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data.

In a seventh aspect, this specification describes an apparatus comprising: at least one processor; and at least one memory including computer program code which, when executed by the at least one processor, causes the apparatus to: generate a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; send selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); receive second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and generate a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data.

In an eighth aspect, this specification describes an apparatus comprising: a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; an output for providing selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); an input for receiving second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and a control module for generating a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data.

In a ninth aspect, this specification describes an apparatus comprising: means for generating a local outage time database for a first cell of a mobile communication system, wherein the local outage time database stores first latency data for each of a plurality of devices served by the first cell, wherein each first latency data comprises time left to outage data for the respective device; means for sending selected parts of the local outage time database to one or more other cells of the mobile communication network (e.g. comprising adjacent or neighbouring cells of the mobile communication network); means for receiving second latency data from at least one of the one or more other cells of the mobile communication system, wherein said second latency data includes time left to outage data for one or more devices served by said other cells; and means for generating a multi-cell outage time database including some or all of the shared selected parts of the local outage time database and some or all of the received second latency data.

Brief description of the drawings

Example embodiments will now be described, by way of example only, with reference to the following schematic drawings, in which: FIG. 1 is a block diagram of a system in accordance with an example embodiment;

FIG. 2 is a table in accordance with an example embodiment;

FIGS. 3 and 4 are block diagrams of systems in accordance with example embodiments; FIG. 5 is a flowchart showing an algorithm in accordance with an example embodiment; FIG. 6 is a table in accordance with an example embodiment;

FIG. 7 is a message sequence in accordance with an example embodiment;

FIG. 8 is a flowchart showing an algorithm in accordance with an example embodiment;

FIG. 9 is a message sequence in accordance with an example embodiment; FIG. 10 is a flowchart showing an algorithm in accordance with an example embodiment;

FIGS. 11 and 12 are message sequence in accordance with example embodiments;

FIG. 13 is a block diagram of components of a system in accordance with an example embodiment; and FIGS. 14A and 14B show tangible media, respectively a removable non-volatile memory unit and a Compact Disc (CD) storing computer-readable code which when run by a computer perform operations according to example embodiments.

Detailed description The scope of protection sought for various embodiments of the invention is set out by the independent claims. The embodiments and features, if any, described in the specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention. In the description and drawings, like reference numerals refer to like elements throughout.

FIG. l is a block diagram of a system, indicated generally by the reference numeral 10, in accordance with an example embodiment. The system 10 comprises a plurality of devices (a first device 12, a second device 13, a third device 14 and a fourth device 15 are shown in FIG. 1) in communication with a base station 16. The system 10 forms part of a mobile communication system. Although user devices are shown in FIG. 1, the devices 12 to 15 may take many forms, such as industrial equipment (e.g. robots, machineiy etc.) or the like.

In an example embodiment, each of the plurality of devices 12 to 15 has a latency budget. A latency budget may be defined as the maximum supported time duration from the moment a packet arrives at the transmitter until it has been successfully received by the intended receiver. In the event that a device-specific latency budget is violated, due to, e.g., successive packet drops because of, e.g., inter-cell interference, dynamic-TDD cross link interference, over-loading, etc., the device may exhibit an outage. For example, in the event that a latency budget of a robotic arm is violated, that robotic arm may shutdown. FIG. 2 is a table, indicated generally by the reference numeral 20, in accordance with an example embodiment. The example table 20 shows part of a local outage time database (OTD) for the system 10 (which system may be referred to as a first cell).

The table 20 stores: · A cell identifier (Cell ID) for the relevant cell. The cell identifier is a global unique cell ID of the current serving cell.

• A device identifier (UE ID) for each of the plurality of devices served by the first cell (e.g. the first to fourth devices 12 to 15 described above).

• Time left to outage data for each of said devices (e.g. per radio bearer per device). The time left to outage data is a value in milliseconds to indicate how much time is left before a running radio bearer of an active device enters an outage if its uplink (UL) or downlink (DL) packets are not successfully processed within the relevant time deadline. This time may be captured on the packet data convergence protocol (PDCP) layer level. A simple decreasing timer may be used at the cell side to determine the time left to outage data, which timer is initialized by the value of ‘maximum latency budget’ of each flow. The timer can then be activated when an active radio bearer flow becomes available for transmission. Per each transmission time interval (TTI) duration, such timers may be locally updated in the sense that each is either reset, in case the corresponding packets of the flow have been successfully received or is left to continue decreasing if corresponding packets are still pending, e.g., inflicting either packet drops or several HARQ re-transmissions.

• A link direction for each of the devices, e.g. whether the intended link direction is uplink (UL) or downlink (DL).

• A cell identifier (Cell ID) for any identified aggressor cells. This entry includes the reported cell IDs of the downlink aggressor cells reported by the active devices in the downlink direction. In an example embodiment, a serving cell of a mobile communication system first configures its active devices with inter-cell interference measurements. Through the higher RRC signalling, a cell may configure its devices to identify the downlink interference aggressor cells by measuring the reference signal receive power (RSRP) of the neighbouring cells. Accordingly, devices report serving cells with the primary cell ID (PCI) IDs of the neighbouring cells with a comparable RSRP coverage as: the cells which satisfy RSRP _serving - RSRP _neighbor < P, where P is a predefined RSRP threshold signalled through the physical downlink control channel (PDCCH). Example embodiments of the principles described herein include neighbouring cells within an industrial or factory setting, associated with a tight radio latency budge per connected devices. Example applications include:

• Both frequency division duplexing (FDD) and dynamic time division duplexing (TDD) modes. · Ultra-reliable low latency communication (URLLC) deployments with sporadic packet arrivals and dynamic user scheduling.

• Time sensitive communication (TSC) deployments with deterministic packet arrivals and semi-persistent scheduling. FIG. 3 is a block diagram of a system, indicated generally by the reference numeral 30, in accordance with an example embodiment.

The system 30 comprises a first cell 31 and a second cell 32, both of which are in communication with a core network 33. The first cell 31 includes a communication node 35 (such as a base station), a first device 36 and a second device 37. The second cell 32 includes a communication node 38 (such as a base station), a third device 39 and a fourth device 40. The first to fourth devices of the system 30 each have a latency budget. For example, as shown in the system 30, the first device 36 has a first latency budget 41, the second device 37 has a second latency budget 42, the third device 39 has a third latency budget 43, and the fourth device 40 has a fourth latency budget 44. FIG. 4 is a block diagram of a system, indicated generally by the reference numeral 50, in accordance with an example embodiment. The system 50 is a mobile communication system comprising a first cell 51, a second cell 52 and a third cell 53. Each of the cells 51 to 53 maybe similar to the cells 31 and 32 described above. Local outage time databases (OTDs) maybe generated for each of the cells 51 to 53 and at least some data of said OTD may be transferred between cells (as indicated by the arrows in FIG. 4).

As described below, exchanging outage time database (OTD) data between adjacent cells enables those cells to work together to seek to achieve device-specific latency- aware co-ordinated transmissions. For example, at an arbitrary time, devices with low dynamically-calculated latency allowance before an outage may be prioritized in order to improve the overall outage performance of the system 50.

FIG. 5 is a flowchart showing an algorithm, indicated generally by the reference numeral 60, in accordance with an example embodiment.

The algorithm 60 starts at operation 62, wherein a local outage time database (OTD) is generated for a first cell of a mobile communication system (such as one of the cells 31 and 33 of the system 30 or one of the cells 51 to 53 of the system 50). As described above, the local outage time database stores a latency budget for each of a plurality of devices served by the first cell, wherein each latency budget comprises time left to outage data for the respective device. At operation 64, some or all of the latency data for the first cell are shared with one or more other cells. For example, latency data generated for the first cell 51 described above may be shared with the second and third cells 52 and 53 of the system 50. Sharing latency data may include sending selected parts of the local outage time database to one or more other cells of the mobile communication network. These cells maybe adjacent or neighbouring cells of the relevant mobile communication network. The operation 64 may be implemented by generating a local outage time database (OTD) such as the OTD 20 described above and sending some or all of that OTD to the other cells.

By way of example, each cell may share latency data for all entries in the relevant local OTD where the time-left-to-outage is below a predefined latency threshold. The sharing of latency data in the operation 64 may be different for uplink and downlink transmissions.

For downlink transmissions, in the event that there are device-reported downlink (DL) aggressor cells, the cells may exchange these corresponding entries as part of an OTD update message (e.g. an information object). The OTD update message may be sent (e.g. over the Xn-interface) only with those DL aggressor adjacent cells. The OTD update message may include the following data: Cell ID, UE ID, time-left-to-outage per DRB per UE, and link direction per DRB per UE. In the event that there are no reported DL aggressor cells for the respective devices, the cells may skip these entries from the inter-cell exchange, since neither coordinated ICIC nor traffic offloading is applicable in this case.

For uplink transmissions, the cell may these corresponding entries as an OTD update message (e.g. over the Xn-interface) with all tier-i adjacent cells. As noted above, the OTD update message may include: Cell ID, UE ID, time-left-to-outage per DRB per UE, and link direction per DRB per UE.

At operation 66, latency data are received (at the first cell) from at least one of the one or more other cells of the mobile communication system, wherein said latency data includes time left to outage data for one or more devices served by said other cells. For example, the first cell 51 may receive latency data (e.g. in the form of an OTD or a portion of an OTD) from the second cell 52 and/or the third cell 53 of the system 50,

At operation 68, a multi-cell outage time database is generated at the first cell (such as the cell 51). The multi-cell OTD may a modified version of the local OTD generated at the first cell. For example, the local OTD may be modified to include updates from other cells (i.e. some or all of the latency data received in the operation 66) in order to generate the multi-cell OTD. In the context of the system 50, the first cell 51 may generate a multi-cell OTD by modifying a local OTD generated at the first cell using latency data obtained from other cells in the system 50. Similarly, the second and third cells 52 and 53 may each generate a multi-cell OTD by modifying a local OTD generated at the respective cell using latency data obtained from other cells in the system 50.

FIG. 6 is a table, indicated generally by the reference numeral 70, in accordance with an example embodiment. The table 70 shows an extract of an example multi-cell outage time database (OTD). The table 70 stores:

• A cell identifier (Cell ID) for the relevant cell. The cell identifier is a global unique cell ID of the current serving cell. In the example table 70, the first entry relates to data from a first cell and the second entry relates to data from a third cell.

• A device identifier (UE ID). · Time left to outage data for the respective device.

• A link direction for the respective device.

Thus, the table 70 includes similar entries to the table 20 described above. In the particular example table 70, the aggressor cell IDs are not reported (although they could be in some example embodiments). One reason for omitting aggressor cell IDs is that a first cell receiving an OTD update from an adjacent cell may understand that the first cell is acting as an aggressor for that adjacent cell.

FIG. 7 is a message sequence, indicated generally by the reference numeral 80, in accordance with an example embodiment. The messages sequence 80 shows messages transferred between a Cell 1 (such as the first cell 51 described above), Cell 2 (such as the second cell 52 described above) and Cell 3 (such as the third cell 53 described above). At operation 82, each of the cells builds an individual outage time database (OTD). The operation 82 includes a number of steps.

Each of the cells first configures its active devices with inter-cell interference measurements.

Through the higher RRC signalling, each cell configures its devices to identify the downlink interference aggressor cells by measuring the RSRP of the neighbouring cells. Accordingly, devices report serving cells with the PCI IDs of the neighbouring cells with a comparable RSRP coverage as: the cells which satisfy RSRP _serving - RSRP _neighbor < P, where P is a predefined RSRP threshold signaled through the PDCCH.

Accordingly, the maximum outage latency budget of each active device may be identified from the core entities handling the QoS PDCP flows. Based on the information generated as discussed above, a local OTD can be generated at each cell (thereby implementing operation 62 of the algorithm 60). As discussed above, each locally generated OTD includes data such as: cell ID; UE ID; time-left-to- outage (ms) per DRB per UE; link direction per DRB per UE; and DL aggressor cell ID per UE.

At operation 84, load information is exchange between the cells as part of Xn-interface specifications. In this way, each cell becomes aware of the load level of its surrounding cells. At operation 86, the first cell determines that a connected device of the hrst cell is approaching an outage condition. This condition can be detected on the basis of the time to outage data of the locally generated OTD.

In response to the detection is operation 86, an OTD update (information object) is sent to the second cell using message 88a and is also sent to the third cell using message 88b. For the downlink direction, in the event that there are devices reporting DL aggressor cells, the OTD update maybe shared only with those DL aggressor adjacent cells. In the event that there are no reported DL aggressor cells for the respective device, an OTD update message may be omitted, since neither coordinated ICIC nor traffic offloading is applicable in this case.

For the uplink direction, the first cell sends the OTD update message to all tier-i adjacent cells, as discussed above.

FIG. 8 is a flowchart showing an algorithm, indicated generally by the reference numeral 90, in accordance with an example embodiment.

The algorithm 90 assumes that a multi-cell OTD has been obtained or generated. For example, a multi-cell OTD may be generated using the algorithm 60 described above.

The algorithm 90 starts at operation 92, where the obtained or generated multi-cell outage time database (OTD) is sorted in order of said time left to outage data. For example, the multi-cell OTD may be sorted in ascending order of time left to outage. The sorting may enable a cell latency priority to be determined amongst a plurality of cells of a mobile communication system.

At operation 94, the highest priority cell is identified. For example, the operation 94 may identify the cell serving the device having the shortest time left to outage as a highest priority cell amongst the various cells of the communication system (such as the cells 31 and 32 or the cells 51 to 53 described above).

At operation 96, inter-cell co-ordination is provided based on the highest priority cell identified in operation 94. A number of example options for inter-cell co-ordination are described in detail below.

It should be noted that assuming efficient link adaptation and user scheduling are in place, violating the PDCP, i.e., DRB, flow-specific latency bounds can often be attributed to either overloaded capacity or strong cross-cell interference. Hence, inter- cell proactive coordination by means of traffic offloading or interference coordination are attractive options. The example embodiments herein describe device-specific latency aware embodiments (rather than an average-cell latency aware that might lead to device-specific outage events).

FIG. 9 is a message sequence, indicated generally by the reference numeral 100, in accordance with an example embodiment. The message sequence 100 is an example implementation of the algorithm 90 described above, for example using the system 50 described above, including the first cell 51, second cell 52 and third cell 53.

At operation 101, a first cell Cell 1 (e.g the first cell) 51 sorts a multi-cell OTD generated or obtained by the first cell. Similarly, at operation 102, the second cell Cell 2 (e.g. the second cell 52) sorts a multi-cell OTD generated or obtained by the second cell and at operation 103, the third cell Cell 3 (e.g. the third cell 53) sorts a multi-cell OTD generated or obtained by the third cell. Thus, the operations 101 to 103 implement the operation 92 of the algorithm 90 described above.

At operation 105, the second cell identifies the first cell as the highest priority cell (thereby implementing one instance of the operation 94 of the algorithm 90 described above). Similarly, at operation 106, the third cell identifies the first cell as the highest priority cell (thereby implementing another instance of the operation 94 of the algorithm 90 described above).

In response to identifying that the first cell has the highest priority, the second cell exchanges messages 108 with the first cell and the third cell exchanges messages 109 with the first cell. The messages 108 and 109 (examples of which are discussed further below) are example implementations of the operation 96 described above.

The operation 96 (and the messages 108 and 109) may take many different forms.

FIG. 10 is a flowchart showing an algorithm, indicated generally by the reference numeral 110, in accordance with an example embodiment. The algorithm 110 is an example implementation of the operation 96.

The algorithm 110 is implemented at a cell of a communication system, such as the system 50 described above, that has a plurality of cells, including a first cell that has determined (in an instance of the operation 94 described above) that it is not the highest priority cell. At operation 112, the first cell determines that protective inter-cell co-ordination is required. At operation 114, it is determined whether the first cell is lightly loaded. If so (such that the first cell in not the highest priority cell and is lightly loaded), the algorithm moves to operation 116; otherwise, the algorithm moves to operation 118.

At operation 116, an offloading proposal is sent (from the first cell) to the identified highest priority cell proposing offloading of one or more latency-critical devices from the highest priority cell to the first cell. The algorithm 110 then terminates at operation 122. As discussed in detail below, an offload of one or more latency-critical devices to the first cell may be implemented on receipt of an acceptance of said offload proposal from the identified highest priority cell.

At operation 118, it is determined whether the first cell his highly loaded. If so (such that the first cell in not the highest priority cell and is highly loaded), the algorithm moves to operation 120; otherwise the algorithm terminates at operation 122. At operation 120, a muting proposal is sent (from the first cell) to the identified highest priority cell proposing muting of the first cell. The algorithm 110 then terminates at operation 122. As discussed in detail below, muting of the first cell may be implemented on receipt of an acceptance of said muting proposal from the identified highest priority cell.

It should be noted that in the algorithm 110 (and in the message sequences described in detailed below), the muting and offloading proposals are triggered by a cell offering proactive inter-cell assistance (rather than a cell requesting such assistance). Since a cell offering assistance is aware of its own conditions, it can offer inter-cell co- ordination (such as muting or offloading proposals) that it can accept. If such an offer is accepted, it may be possible to implement the offer immediately, without any further message exchanges. In contrast, some example systems in which a cell requests assistance (such as muting or offloading assistance) may require a further one or more additional rounds of inter-cell signalling in order to determine the parameters of the assistance to be given. In embodiments with tight latency budgets, having reducing the number of rounds of inter-cell signalling can be advantageous. FIG. li is a message sequence, indicated generally by the reference numeral 130, in accordance with an example embodiment. The message sequence 130 shows messages transferred between a Cell 1 (such as the first cell 51 described above), Cell 2 (such as the second cell 52 described above) and Cell 3 (such as the third cell 53 described above).

At operation 82, each of the cells builds an individual/local outage time database (OTD). The operation 82 includes a number of steps, as discussed further above.

At operation 84, load information is exchange between the cells as part of Xn-interface specifications. In this way, each cell becomes aware of the load level of its surrounding cells. At operation 132a, it is determined that Cell 1 is highly loaded. Similarly, at operation 132b it is determined that the Cell 2 is highly loaded and at operation 132c it is determined that the Cell 3 is highly loaded.

At operation 134a, it is determined that an uplink device at Cell 1 is approaching an outage condition (i.e. a time to outage of the uplink device is below a threshold level).

In response to the determination at operation 134a, an OTD update message 136a is sent from Cell 1 to Cell 2 and an OTD update message 136b is sent from Cell 1 to Cell 3. As discussed above, the OTD update messages 136a and 136b enable multi-cell OTDs to be generated at Cell 2 and Cell 3.

Similarly, at operation 134b, it is determined that an uplink device at Cell 3 is approaching an outage condition (i.e. a time to outage of the uplink device is below a threshold level). In response to the determination at operation 134b, an OTD update message 138a is sent from Cell 3 to Cell 1 and an OTD update message 138b is sent from Cell 3 to Cell 2. As discussed above, the OTD update messages 138a and 138b enable multi-cell OTDs to be generated at Cell 1 and Cell 2.

At this stage, multi-cell OTDs are generated at each cell and those multi-cell OTDs may be locally sorted. This enables the relative priorities of the cells to be determined (such that the cell with the lowest time to outage remaining can be identified). At operation 140a, it is determined (at Cell 1) that Cell 1 has the highest priority and that Cell 3 has the second highest priority. Similar determinations are made in operation 140b (at Cell 2) and operation 140c (at Cell 3). At Cell 3, a determination is made that Cell 3 is highly loaded, but is not the highest priority cell. As a result, a muting proposal 142 is sent from Cell 3 to the highest priority cell (Cell 1 in this example). The muting proposal 142 proposes to Cell 1 that Cell 3 be muted in order to provide proactive inter-cell co-ordination. Similarly, at Cell 2, a determination is made that Cell 2 is highly loaded, but is not the highest priority cell. As a result, a muting proposal 143 is sent from Cell 2 to the highest priority cell (Cell 1). The muting proposal 143 proposes to Cell 1 that Cell 3 be muted in order to provide proactive inter-cell co-ordination. Thus, both of the lower priority cells (i.e. the cells with a larger time-1 eft-to-outage) proactively propose an inter-cell interference co-ordination (ICIC) assistance to the highest priority cell (Cell 1) through exchanging muting proposal messages.

Cell 1 sends a first recommended muting message 144 to Cell 3 and a second recommending muting message 145 to Cell 2. The recommended muting messages 144 and 145 provide proposed muting configurations.

The first recommended muting message 144 is accepted by Cell 3 and an accept message 146 sent to Cell 1. Similarly, the second recommended muting message 145 is accepted by Cell 2 and an accept message 147 sent to Cell 1.

At operations 148a and 148b the respective muting proposals are implemented at Cell 2 and Cell 3 respectively such that inter-cell interference free uplink transmission 150 can occur at Cell 1. The operations 148a, 148b and 150 collectively form inter-cell co- ordination (thereby implementing operation 96 of the algorithm 90 described above).

FIG. 12 is a message sequence, indicated generally by the reference numeral 160, in accordance with an example embodiment. The message sequence 160 shows messages transferred between a Cell 1 (such as the first cell 51 described above), Cell 2 (such as the second cell 52 described above) and Cell 3 (such as the third cell 53 described above). At operation 82, each of the cells builds an individual/local outage time database (OTD). The operation 82 includes a number of steps, as discussed further above. At operation 84, load information is exchange between the cells as part of Xn-interface specifications. In this way, each cell becomes aware of the load level of its surrounding cells.

At operation 162a, it is determined that Cell 1 is highly loaded. Similarly, at operation 162b it is determined that the Cell 3 is highly loaded. However, at operation 163 it is determined that Cell 2 is lightly loaded.

At operation 164, it is determined that a connected downlink device at Cell 1 is approaching an outage condition (i.e. a time to outage of the downlink device is below a threshold level). In response to the determination at operation 164, an OTD update message 166a is sent from Cell 1 to Cell 2 and an OTD update message 166b is sent from Cell 1 to Cell 3. As discussed above, the OTD update messages 166a and 166b enable multi-cell OTDs to be generated at Cell 2 and Cell 3. At this stage, multi-cell OTDs are generated at each cell and those multi-cell OTDs may be locally sorted. This enables the relative priorities of the cells to be determined (such that the cell with the lowest time to outage remaining can be identified).

At operation 168a, it is determined (at Cell 1) that Cell 1 has the highest priority. Similar determinations are made in operation 168b (at Cell 2) and operation 168c (at Cell 3).

At Cell 2 a determination is made that Cell 2 is lightly loaded and is not the highest priority cell. As a result, an offloading proposal 170 is sent from Cell 2 to the highest priority cell (Cell 1 in this example). The offloading proposal 170 recommends a downlink offloading assistance to Cell 1.

At Cell 3, a determination is made that Cell 3 is highly loaded, but is not the highest priority cell. As a result, a muting proposal 172 is sent from Cell 3 to the highest priority cell (Cell 1 in this example). The muting proposal 142 proposes to Cell 1 that Cell 3 be muted in order to provide proactive inter-cell co-ordination. Thus, both of the lower priority cells (i.e. the cells with a larger time-1 eft-to-outage) proactively propose an inter-cell interference co-ordination (ICIC) assistance to the highest priority cell (Cell 1); however, the nature of the co-ordination assistance offered is different.

Cell l accepts the proposal to offload the latency-degraded device to Cell 2 (and therefore sends an accept message 174 to Cell 2). Accordingly, Cell 1 rejects the assistance offered by Cell 3 (and therefore sends a reject message 175 to Cell 3). On receipt of the reject message 175, Cell 3 discards the muting proposal and so the proposed muting is not implemented.

In operations 176 and 178 the offload proposal is implemented by Cell 1 and Cell 2. The operations 176 and 178 collectively form inter-cell co-ordination (thereby implementing operation 96 of the algorithm 90 described above).

The message sequence 130 and 160 therefore describe example protocols of generating offloading and muting proposals and also described example protocols for responding to offloading and muting proposals.

Based on the updated multi-cell OTD at each cell, cells proactively coordinate to seek to ensure fast and interference-controlled conditions for cells with the most critical flows.

A destination cell updates its own OTD with the OTD entries received from neighbouring source cells. Then, a destination cell identifies the most critical source cells with the lowest time to outage entries. Accordingly, a destination cell becomes aware of the actual latency performance of its own connected devices as well as the critical surrounding source cells. Thus, depending on its load and interference conditions, a cell can proactively send either an offloading proposal or a muting proposal to critical, i.e., highest priority, source cells over the Xn-interface.

The offloading proposal indicates the destination cell recommends offloading the critical devices with the urgent DRB flows from source to destination cell. The muting proposal may indicate the destination cell recommends certain UL/DL resource muting in order to facilitate an interference-free transmission of the critical DRB payload in the source cell. Furthermore, if a destination cell cannot mute certain resources or accept traffic offloading from source cell(s), it does not send either the offloading proposal or the muting proposal and it shall be excluded from coordination.

At the source cell, after receiving the offloading proposal and/or muting proposals from the neighbouring cells, cross-cell conflicts may occur. Thus, in order to resolve potential conflicts, a source cell sends back either “accept”, “reject”, “recommended offload” or “recommended muting” messages, as follows:

• ACCEPT : a source cell accepts the corresponding proposal from a destination cell (without any changes to that proposal).

• REJECT : a source cell rejects the corresponding proposal from a destination cell without further action, i.e., no further coordination is needed between source cell and this destination cell.

• RECOMMENDED OFFLOAD: a source cell sends back the respective destination cell with a recommended offloading configuration in response to the offloading proposal. This maybe useful in cases when the state of the latency-degraded device has quickly changed (payload transmitted/further retransmitted) before sending a new OTD update from source to destination cell.

• RECOMMENDED MUTING: a source cell sends back the respective destination cell with a recommended muting configuration in response to the muting proposal. This maybe used to resolve potential conflicts. For example, two destination cells may offer muting proposals for a neighbouring critical source cell, with various proposed timing and frequency resources to be muted. Thus, a source cell may recommend a common muting configuration for all destination cells and accordingly schedule the latency-degraded device(s) with interference-free conditions over the agreed resources. It should be noted that in the message sequences 130 and 160, the various muting and offloading proposals are triggered from the cell that are offering muting or offloading support to another cell (e.g. from a destination cell to a source cell), thereby offering proactive inter-cell assistance. This is different to a mechanism in which a cell that needs support requests that support from other cells in the vicinity (e.g. by sending requests from a source cell to a destination cell). In system in which a source cell (needing support) sends requests to one or more destination cells, each destination cell may accept or reject a request and hence, another round of coordination/signalling may be needed to agree on specific inter-cell coordination. In embodiments having critically tight latency budgets, it maybe an advantage to implement a system without such additional rounds of inter-cell signalling.

For completeness, FIG. 13 is a schematic diagram of components of one or more of the example embodiments described previously, which hereafter are referred to generically as a processing system 300. The processing system 300 may, for example, be the apparatus referred to in the claims below.

The processing system 300 may comprise one or more of: a processor 302, a memory 304 closely coupled to the processor and comprised of a RAM 314 and a ROM 312, a user input 310 (such as a touch screen input, hardware keys and/or a voice input mechanism) and a display 318 (at least some of those components may be omitted in some example embodiments). The processing system 300 may comprise one or more network/apparatus interfaces 308 for connection to a network/apparatus, e.g. a modem which may be wired or wireless. The interface 308 may also operate as a connection to other apparatus such as device/apparatus which is not network side apparatus. Thus, direct connection between devices/apparatus without network participation is possible.

The processor 302 is connected to each of the other components in order to control operation thereof.

The memory 304 may comprise a non-volatile memory, such as a hard disk drive (HDD) or a solid state drive (SSD). The ROM 312 of the memory 304 stores, amongst other things, an operating system 315 and may store software applications 316. The RAM 314 of the memory 304 is used by the processor 302 for the temporary storage of data. The operating system 315 may contain code which, when executed by the processor implements aspects of the algorithms 60, 90 and 110 or the message sequences 80, 100, 130 and 160 described above. Note that in the case of small device/apparatus the memory can be most suitable for small size usage i.e. not always a hard disk drive (HDD) or a solid state drive (SSD) is used. The memory 304 may include computer program code, such that the at least one memory 304 and the computer program maybe configured, with the at least one processor 302, may cause the performance of the apparatus.

The processor 302 may take any suitable form. For instance, it may be a microcontroller, a plurality of microcontrollers, a processor, or a plurality of processors.

The processing system 300 maybe a standalone computer, a server, a console, or a network thereof. The processing system 300 and needed structural parts may be all inside device/apparatus such as IoT device/apparatus i.e. embedded to very small size.

In some example embodiments, the processing system 300 may also be associated with external software applications. These maybe applications stored on a remote server device/apparatus and may run partly or exclusively on the remote server device/apparatus. These applications maybe termed cloud-hosted applications. The processing system 300 may be in communication with the remote server device/apparatus in order to utilize the software application stored there.

FIGS. 14A and 14B show tangible media, respectively a removable memory unit 365 and a compact disc (CD) 368, storing computer-readable code which when run by a computer may perform methods according to example embodiments described above. The removable memory unit 365 maybe a memory stick, e.g. a USB memory stick, having internal memory 366 storing the computer-readable code. The internal memory 366 may be accessed by a computer system via a connector 367. The CD 368 may be a CD-ROM or a DVD or similar. Other forms of tangible storage media may be used.

Tangible media can be any device/apparatus capable of storing data/information which data/information can be exchanged between devices/apparatus/network.

Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/ or hardware may reside on memory, or any computer media. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a “memory” or “computer-readable medium” may be any non-transitory media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

Reference to, where relevant, “computer-readable medium”, “computer program product”, “tangibly embodied computer program” etc., or a “processor” or “processing circuitry” etc. should be understood to encompass not only computers having differing architectures such as single/multi-processor architectures and sequencers/parallel architectures, but also specialised circuits such as field programmable gate arrays FPGA, application specify circuits ASIC, signal processing devices/apparatus and other devices/apparatus. References to computer program, instructions, code etc. should be understood to express software for a programmable processor firmware such as the programmable content of a hardware device/apparatus as instructions for a processor or configured or configuration settings for a fixed function device/apparatus, gate array, programmable logic device/apparatus, etc.

If desired, the different functions discussed herein may be performed in a different order and/ or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined. Similarly, it will also be appreciated that the flow diagrams and message sequences of FIGS. 5 and 7 to 12 are examples only and that various operations depicted therein may be omitted, reordered and / or combined.

It will be appreciated that the above described example embodiments are purely illustrative and are not limiting on the scope of the invention. Other variations and modifications will be apparent to persons skilled in the art upon reading the present specification.

Moreover, the disclosure of the present application should be understood to include any novel features or any novel combination of features either explicitly or implicitly disclosed herein or any generalization thereof and during the prosecution of the present application or of any application derived therefrom, new claims may be formulated to cover any such features and/ or combination of such features.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described example embodiments and/ or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

It is also noted herein that while the above describes various examples, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.