Patent Description:
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. <CIT> discloses estimating the reliability and/or latency of a transmission in communication systems. One method may include identifying at least one user equipment requiring dual connectivity or multi connectivity support. The method may then include configuring, by an anchor network node, at least one secondary network node to serve as a duplication set for the at least one user equipment. The duplication set may include one or more secondary network nodes that are capable of transmission of a duplicated packet to at least one user equipment. The method may also include receiving, from the at least one secondary network node, estimates of supported latency and reliability for the at least one user equipment. The configuring may include selecting the duplication set that minimizes a probability of outage and minimizes latency of the transmission of the duplicated packet to at least one user equipment. "<NPL>, discloses a Study on enhancement of Ultra-Reliable Low-Latency Communication support in the <NUM> Core network.

In a first aspect, this specification describes an apparatus as claimed in claim <NUM>. 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. 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 means may be 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.

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).

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.

Example embodiments will now be described, by way of example only, with reference to the following schematic drawings, in which:.

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.

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

In an example embodiment, each of the plurality of devices <NUM> to <NUM> 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> is a table, indicated generally by the reference numeral <NUM>, in accordance with an example embodiment. The example table <NUM> shows part of a local outage time database (OTD) for the system <NUM> (which system may be referred to as a first cell).

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:.

<FIG> is a block diagram of a system, indicated generally by the reference numeral <NUM>, in accordance with an example embodiment.

The system <NUM> comprises a first cell <NUM> and a second cell <NUM>, both of which are in communication with a core network <NUM>. The first cell <NUM> includes a communication node <NUM> (such as a base station), a first device <NUM> and a second device <NUM>. The second cell <NUM> includes a communication node <NUM> (such as a base station), a third device <NUM> and a fourth device <NUM>.

The first to fourth devices of the system <NUM> each have a latency budget. For example, as shown in the system <NUM>, the first device <NUM> has a first latency budget <NUM>, the second device <NUM> has a second latency budget <NUM>, the third device <NUM> has a third latency budget <NUM>, and the fourth device <NUM> has a fourth latency budget <NUM>.

<FIG> is a block diagram of a system, indicated generally by the reference numeral <NUM>, in accordance with an example embodiment. The system <NUM> is a mobile communication system comprising a first cell <NUM>, a second cell <NUM> and a third cell <NUM>. Each of the cells <NUM> to <NUM> may be similar to the cells <NUM> and <NUM> described above. Local outage time databases (OTDs) may be generated for each of the cells <NUM> to <NUM> and at least some data of said OTD may be transferred between cells (as indicated by the arrows in <FIG>).

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 <NUM>.

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

The algorithm <NUM> starts at operation <NUM>, wherein a local outage time database (OTD) is generated for a first cell of a mobile communication system (such as one of the cells <NUM> and <NUM> of the system <NUM> or one of the cells <NUM> to <NUM> of the system <NUM>). 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 <NUM>, 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 <NUM> described above may be shared with the second and third cells <NUM> and <NUM> of the system <NUM>. 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 <NUM> may be implemented by generating a local outage time database (OTD) such as the OTD <NUM> 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 <NUM> 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-<NUM> 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 <NUM>, 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 <NUM> may receive latency data (e.g. in the form of an OTD or a portion of an OTD) from the second cell <NUM> and/or the third cell <NUM> of the system <NUM>,.

At operation <NUM>, a multi-cell outage time database is generated at the first cell (such as the cell <NUM>). 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 <NUM>) in order to generate the multi-cell OTD.

In the context of the system <NUM>, the first cell <NUM> 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 <NUM>. Similarly, the second and third cells <NUM> and <NUM> 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 <NUM>.

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

Thus, the table <NUM> includes similar entries to the table <NUM> described above. In the particular example table <NUM>, 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> is a message sequence, indicated generally by the reference numeral <NUM>, in accordance with an example embodiment. The messages sequence <NUM> shows messages transferred between a Cell <NUM> (such as the first cell <NUM> described above), Cell <NUM> (such as the second cell <NUM> described above) and Cell <NUM> (such as the third cell <NUM> described above).

At operation <NUM>, each of the cells builds an individual outage time database (OTD). The operation <NUM> 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 RSRPserving - RSRPneighbor < 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 <NUM> of the algorithm <NUM>). 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 <NUM>, 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 <NUM>, the first cell determines that a connected device of the first 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 <NUM>, 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 may be 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-<NUM> adjacent cells, as discussed above.

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

The algorithm <NUM> starts at operation <NUM>, 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 <NUM>, the highest priority cell is identified. For example, the operation <NUM> 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 <NUM> and <NUM> or the cells <NUM> to <NUM> described above).

At operation <NUM>, inter-cell co-ordination is provided based on the highest priority cell identified in operation <NUM>. 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> is a message sequence, indicated generally by the reference numeral <NUM>, in accordance with an example embodiment. The message sequence <NUM> is an example implementation of the algorithm <NUM> described above, for example using the system <NUM> described above, including the first cell <NUM>, second cell <NUM> and third cell <NUM>.

At operation <NUM>, a first cell Cell <NUM> (e. g the first cell) <NUM> sorts a multi-cell OTD generated or obtained by the first cell. Similarly, at operation <NUM>, the second cell Cell <NUM> (e.g. the second cell <NUM>) sorts a multi-cell OTD generated or obtained by the second cell and at operation <NUM>, the third cell Cell <NUM> (e.g. the third cell <NUM>) sorts a multi-cell OTD generated or obtained by the third cell. Thus, the operations <NUM> to <NUM> implement the operation <NUM> of the algorithm <NUM> described above.

At operation <NUM>, the second cell identifies the first cell as the highest priority cell (thereby implementing one instance of the operation <NUM> of the algorithm <NUM> described above). Similarly, at operation <NUM>, the third cell identifies the first cell as the highest priority cell (thereby implementing another instance of the operation <NUM> of the algorithm <NUM> described above).

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

The operation <NUM> (and the messages <NUM> and <NUM>) may take many different forms.

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

The algorithm <NUM> is implemented at a cell of a communication system, such as the system <NUM> described above, that has a plurality of cells, including a first cell that has determined (in an instance of the operation <NUM> described above) that it is not the highest priority cell.

At operation <NUM>, the first cell determines that protective inter-cell co-ordination is required.

At operation <NUM>, 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 <NUM>; otherwise, the algorithm moves to operation <NUM>.

At operation <NUM>, 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 <NUM> then terminates at operation <NUM>. 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 <NUM>, 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 <NUM>; otherwise the algorithm terminates at operation <NUM>.

At operation <NUM>, a muting proposal is sent (from the first cell) to the identified highest priority cell proposing muting of the first cell. The algorithm <NUM> then terminates at operation <NUM>. 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 <NUM> (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> is a message sequence, indicated generally by the reference numeral <NUM>, in accordance with an example embodiment. The message sequence <NUM> shows messages transferred between a Cell <NUM> (such as the first cell <NUM> described above), Cell <NUM> (such as the second cell <NUM> described above) and Cell <NUM> (such as the third cell <NUM> described above).

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

At operation 132a, it is determined that Cell <NUM> is highly loaded. Similarly, at operation 132b it is determined that the Cell <NUM> is highly loaded and at operation 132c it is determined that the Cell <NUM> is highly loaded.

At operation 134a, it is determined that an uplink device at Cell <NUM> 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 <NUM> to Cell <NUM> and an OTD update message 136b is sent from Cell <NUM> to Cell <NUM>. As discussed above, the OTD update messages 136a and 136b enable multi-cell OTDs to be generated at Cell <NUM> and Cell <NUM>.

Similarly, at operation 134b, it is determined that an uplink device at Cell <NUM> 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 <NUM> to Cell <NUM> and an OTD update message 138b is sent from Cell <NUM> to Cell <NUM>. As discussed above, the OTD update messages 138a and 138b enable multi-cell OTDs to be generated at Cell <NUM> and Cell <NUM>.

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 <NUM>) that Cell <NUM> has the highest priority and that Cell <NUM> has the second highest priority. Similar determinations are made in operation 140b (at Cell <NUM>) and operation 140c (at Cell <NUM>).

At Cell <NUM>, a determination is made that Cell <NUM> is highly loaded, but is not the highest priority cell. As a result, a muting proposal <NUM> is sent from Cell <NUM> to the highest priority cell (Cell <NUM> in this example). The muting proposal <NUM> proposes to Cell <NUM> that Cell <NUM> be muted in order to provide proactive inter-cell co-ordination.

Similarly, at Cell <NUM>, a determination is made that Cell <NUM> is highly loaded, but is not the highest priority cell. As a result, a muting proposal <NUM> is sent from Cell <NUM> to the highest priority cell (Cell <NUM>). The muting proposal <NUM> proposes to Cell <NUM> that Cell <NUM> 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-left-to-outage) proactively propose an inter-cell interference co-ordination (ICIC) assistance to the highest priority cell (Cell <NUM>) through exchanging muting proposal messages.

Cell <NUM> sends a first recommended muting message <NUM> to Cell <NUM> and a second recommending muting message <NUM> to Cell <NUM>. The recommended muting messages <NUM> and <NUM> provide proposed muting configurations.

The first recommended muting message <NUM> is accepted by Cell <NUM> and an accept message <NUM> sent to Cell <NUM>. Similarly, the second recommended muting message <NUM> is accepted by Cell <NUM> and an accept message <NUM> sent to Cell <NUM>.

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

At operation 162a, it is determined that Cell <NUM> is highly loaded. Similarly, at operation 162b it is determined that the Cell <NUM> is highly loaded. However, at operation <NUM> it is determined that Cell <NUM> is lightly loaded.

At operation <NUM>, it is determined that a connected downlink device at Cell <NUM> 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 <NUM>, an OTD update message 166a is sent from Cell <NUM> to Cell <NUM> and an OTD update message 166b is sent from Cell <NUM> to Cell <NUM>. As discussed above, the OTD update messages 166a and 166b enable multi-cell OTDs to be generated at Cell <NUM> and Cell <NUM>.

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

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

Thus, both of the lower priority cells (i.e. the cells with a larger time-left-to-outage) proactively propose an inter-cell interference co-ordination (ICIC) assistance to the highest priority cell (Cell <NUM>); however, the nature of the co-ordination assistance offered is different.

Cell <NUM> accepts the proposal to offload the latency-degraded device to Cell <NUM> (and therefore sends an accept message <NUM> to Cell <NUM>). Accordingly, Cell <NUM> rejects the assistance offered by Cell <NUM> (and therefore sends a reject message <NUM> to Cell <NUM>).

On receipt of the reject message <NUM>, Cell <NUM> discards the muting proposal and so the proposed muting is not implemented.

In operations <NUM> and <NUM> the offload proposal is implemented by Cell <NUM> and Cell <NUM>. The operations <NUM> and <NUM> collectively form inter-cell co-ordination (thereby implementing operation <NUM> of the algorithm <NUM> described above).

The message sequence <NUM> and <NUM> 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:.

It should be noted that in the message sequences <NUM> and <NUM>, 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 may be an advantage to implement a system without such additional rounds of inter-cell signalling.

For completeness, <FIG> 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 <NUM>. The processing system <NUM> may, for example, be the apparatus referred to in the claims below.

The processing system <NUM> may comprise one or more of: a processor <NUM>, a memory <NUM> closely coupled to the processor and comprised of a RAM <NUM> and a ROM <NUM>, a user input <NUM> (such as a touch screen input, hardware keys and/or a voice input mechanism) and a display <NUM> (at least some of those components may be omitted in some example embodiments). The processing system <NUM> may comprise one or more network/apparatus interfaces <NUM> for connection to a network/apparatus, e.g. a modem which may be wired or wireless. The interface <NUM> 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 memory <NUM> may comprise a non-volatile memory, such as a hard disk drive (HDD) or a solid state drive (SSD). The ROM <NUM> of the memory <NUM> stores, amongst other things, an operating system <NUM> and may store software applications <NUM>. The RAM <NUM> of the memory <NUM> is used by the processor <NUM> for the temporary storage of data. The operating system <NUM> may contain code which, when executed by the processor implements aspects of the algorithms <NUM>, <NUM> and <NUM> or the message sequences <NUM>, <NUM>, <NUM> and <NUM> 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 <NUM> may include computer program code, such that the at least one memory <NUM> and the computer program may be configured, with the at least one processor <NUM>, may cause the performance of the apparatus.

The processor <NUM> 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 <NUM> may be a standalone computer, a server, a console, or a network thereof. The processing system <NUM> 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 <NUM> may also be associated with external software applications. These may be applications stored on a remote server device/apparatus and may run partly or exclusively on the remote server device/apparatus. These applications may be termed cloud-hosted applications. The processing system <NUM> may be in communication with the remote server device/apparatus in order to utilize the software application stored there.

<FIG> show tangible media, respectively a removable memory unit <NUM> and a compact disc (CD) <NUM>, storing computer-readable code which when run by a computer may perform methods according to example embodiments described above. The removable memory unit <NUM> may be a memory stick, e.g. a USB memory stick, having internal memory <NUM> storing the computer-readable code. The internal memory <NUM> may be accessed by a computer system via a connector <NUM>. The CD <NUM> 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.

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..

Similarly, it will also be appreciated that the flow diagrams and message sequences of <FIG> and <FIG> to <FIG> 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.

Claim 1:
An apparatus comprising means for performing:
Generating (<NUM>) a local outage time database (<NUM>) for a first cell (<NUM>) of a mobile communication system (<NUM>), 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 (<NUM>) selected parts of the local outage time database to one or more other cells of the mobile communication network;
receiving (<NUM>) 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 (<NUM>) 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.