Patent ID: 12231983

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.1is a block diagram of a system, indicated generally by the reference numeral10, in accordance with an example embodiment. The system10comprises a plurality of devices (a first device12, a second device13, a third device14and a fourth device15are shown inFIG.1) in communication with a base station16. The system10forms part of a mobile communication system. Although user devices are shown inFIG.1, the devices12to15may take many forms, such as industrial equipment (e.g. robots, machinery etc.) or the like.

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

The table20stores: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 devices12to15described 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 RSRPserving−RSRPneighbor<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.3is a block diagram of a system, indicated generally by the reference numeral30, in accordance with an example embodiment.

The system30comprises a first cell31and a second cell32, both of which are in communication with a core network33. The first cell31includes a communication node35(such as a base station), a first device36and a second device37. The second cell32includes a communication node38(such as a base station), a third device39and a fourth device40.

The first to fourth devices of the system30each have a latency budget. For example, as shown in the system30, the first device36has a first latency budget41, the second device37has a second latency budget42, the third device39has a third latency budget43, and the fourth device40has a fourth latency budget44.

FIG.4is a block diagram of a system, indicated generally by the reference numeral50, in accordance with an example embodiment. The system50is a mobile communication system comprising a first cell51, a second cell52and a third cell53. Each of the cells51to53may be similar to the cells31and32described above. Local outage time databases (OTDs) may be generated for each of the cells51to53and at least some data of said OTD may be transferred between cells (as indicated by the arrows inFIG.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 system50.

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

The algorithm60starts at operation62, wherein a local outage time database (OTD) is generated for a first cell of a mobile communication system (such as one of the cells31and33of the system30or one of the cells51to53of the system50). 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 operation64, 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 cell51described above may be shared with the second and third cells52and53of the system50. 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 may be adjacent or neighbouring cells of the relevant mobile communication network. The operation64may be implemented by generating a local outage time database (OTD) such as the OTD20described 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 operation64may 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-1 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 operation66, 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 cell51may receive latency data (e.g. in the form of an OTD or a portion of an OTD) from the second cell52and/or the third cell53of the system50,

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

In the context of the system50, the first cell51may generate a multi-cell OTD by modifying a local OTD generated at the first cell using latency data obtained from other cells in the system50. Similarly, the second and third cells52and53may 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 system50.

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

The table70stores: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 table70, 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 table70includes similar entries to the table20described above. In the particular example table70, 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.7is a message sequence, indicated generally by the reference numeral80, in accordance with an example embodiment. The messages sequence80shows messages transferred between a Cell 1 (such as the first cell51described above), Cell 2 (such as the second cell52described above) and Cell 3 (such as the third cell53described above).

At operation82, each of the cells builds an individual outage time database (OTD). The operation82includes 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 operation62of the algorithm60). 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 operation84, 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 operation86, 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 operation86, an OTD update (information object) is sent to the second cell using message88aand is also sent to the third cell using message88b.

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-1 adjacent cells, as discussed above.

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

The algorithm90assumes that a multi-cell OTD has been obtained or generated. For example, a multi-cell OTD may be generated using the algorithm60described above.

The algorithm90starts at operation92, 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 operation94, the highest priority cell is identified. For example, the operation94may 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 cells31and32or the cells51to53described above).

At operation96, inter-cell co-ordination is provided based on the highest priority cell identified in operation94. 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.9is a message sequence, indicated generally by the reference numeral100, in accordance with an example embodiment. The message sequence100is an example implementation of the algorithm90described above, for example using the system50described above, including the first cell51, second cell52and third cell53.

At operation101, a first cell Cell 1 (e.g the first cell)51sorts a multi-cell OTD generated or obtained by the first cell. Similarly, at operation102, the second cell Cell 2 (e.g. the second cell52) sorts a multi-cell OTD generated or obtained by the second cell and at operation103, the third cell Cell 3 (e.g. the third cell53) sorts a multi-cell OTD generated or obtained by the third cell. Thus, the operations101to103implement the operation92of the algorithm90described above.

At operation105, the second cell identifies the first cell as the highest priority cell (thereby implementing one instance of the operation94of the algorithm90described above). Similarly, at operation106, the third cell identifies the first cell as the highest priority cell (thereby implementing another instance of the operation94of the algorithm90described above).

In response to identifying that the first cell has the highest priority, the second cell exchanges messages108with the first cell and the third cell exchanges messages109with the first cell. The messages108and109(examples of which are discussed further below) are example implementations of the operation96described above.

The operation96(and the messages108and109) may take many different forms.

FIG.10is a flowchart showing an algorithm, indicated generally by the reference numeral110, in accordance with an example embodiment. The algorithm110is an example implementation of the operation96.

The algorithm110is implemented at a cell of a communication system, such as the system50described above, that has a plurality of cells, including a first cell that has determined (in an instance of the operation94described above) that it is not the highest priority cell.

At operation112, the first cell determines that protective inter-cell co-ordination is required.

At operation114, 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 operation116; otherwise, the algorithm moves to operation118.

At operation116, 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 algorithm110then terminates at operation122. 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 operation118, 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 operation120; otherwise the algorithm terminates at operation122.

At operation120, a muting proposal is sent (from the first cell) to the identified highest priority cell proposing muting of the first cell. The algorithm110then terminates at operation122. 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 algorithm110(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.11is a message sequence, indicated generally by the reference numeral130, in accordance with an example embodiment. The message sequence130shows messages transferred between a Cell 1 (such as the first cell51described above), Cell 2 (such as the second cell52described above) and Cell 3 (such as the third cell53described above).

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

At operation84, 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 operation132a, it is determined that Cell 1 is highly loaded. Similarly, at operation132bit is determined that the Cell 2 is highly loaded and at operation132cit is determined that the Cell 3 is highly loaded.

At operation134a, 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 operation134a, an OTD update message136ais sent from Cell 1 to Cell 2 and an OTD update message136bis sent from Cell 1 to Cell 3. As discussed above, the OTD update messages136aand136benable multi-cell OTDs to be generated at Cell 2 and Cell 3.

Similarly, at operation134b, 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 operation134b, an OTD update message138ais sent from Cell 3 to Cell 1 and an OTD update message138bis sent from Cell 3 to Cell 2. As discussed above, the OTD update messages138aand138benable 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 operation140a, 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 operation140b(at Cell 2) and operation140c(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 proposal142is sent from Cell 3 to the highest priority cell (Cell 1 in this example). The muting proposal142proposes 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 proposal143is sent from Cell 2 to the highest priority cell (Cell 1). The muting proposal143proposes 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-left-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 message144to Cell 3 and a second recommending muting message145to Cell 2. The recommended muting messages144and145provide proposed muting configurations.

The first recommended muting message144is accepted by Cell 3 and an accept message146sent to Cell 1. Similarly, the second recommended muting message145is accepted by Cell 2 and an accept message147sent to Cell 1.

At operations148aand148bthe respective muting proposals are implemented at Cell 2 and Cell 3 respectively such that inter-cell interference free uplink transmission150can occur at Cell 1. The operations148a,148band150collectively form inter-cell co-ordination (thereby implementing operation96of the algorithm90described above).

FIG.12is a message sequence, indicated generally by the reference numeral160, in accordance with an example embodiment. The message sequence160shows messages transferred between a Cell 1 (such as the first cell51described above), Cell 2 (such as the second cell52described above) and Cell 3 (such as the third cell53described above).

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

At operation84, 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 operation162a, it is determined that Cell 1 is highly loaded. Similarly, at operation162bit is determined that the Cell 3 is highly loaded. However, at operation163it is determined that Cell 2 is lightly loaded.

At operation164, 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 operation164, an OTD update message166ais sent from Cell 1 to Cell 2 and an OTD update message166bis sent from Cell 1 to Cell 3. As discussed above, the OTD update messages166aand166benable 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 operation168a, it is determined (at Cell 1) that Cell 1 has the highest priority. Similar determinations are made in operation168b(at Cell 2) and operation168c(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 proposal170is sent from Cell 2 to the highest priority cell (Cell 1 in this example). The offloading proposal170recommends 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 proposal172is sent from Cell 3 to the highest priority cell (Cell 1 in this example). The muting proposal142proposes 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-left-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 1 accepts the proposal to offload the latency-degraded device to Cell 2 (and therefore sends an accept message174to Cell 2). Accordingly, Cell 1 rejects the assistance offered by Cell 3 (and therefore sends a reject message175to Cell 3).

On receipt of the reject message175, Cell 3 discards the muting proposal and so the proposed muting is not implemented.

In operations176and178the offload proposal is implemented by Cell 1 and Cell 2. The operations176and178collectively form inter-cell co-ordination (thereby implementing operation96of the algorithm90described above).

The message sequence130and160therefore 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 may be 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 may be 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 sequences130and160, 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.13is a schematic diagram of components of one or more of the example embodiments described previously, which hereafter are referred to generically as a processing system300. The processing system300may, for example, be the apparatus referred to in the claims below.

The processing system300may comprise one or more of: a processor302, a memory304closely coupled to the processor and comprised of a RAM314and a ROM312, a user input310(such as a touch screen input, hardware keys and/or a voice input mechanism) and a display318(at least some of those components may be omitted in some example embodiments). The processing system300may comprise one or more network/apparatus interfaces308for connection to a network/apparatus, e.g. a modem which may be wired or wireless. The interface308may 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 processor302is connected to each of the other components in order to control operation thereof.

The memory304may comprise a non-volatile memory, such as a hard disk drive (HDD) or a solid state drive (SSD). The ROM312of the memory304stores, amongst other things, an operating system315and may store software applications316. The RAM314of the memory304is used by the processor302for the temporary storage of data. The operating system315may contain code which, when executed by the processor implements aspects of the algorithms60,90and110or the message sequences80,100,130and160described 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 memory304may include computer program code, such that the at least one memory304and the computer program may be configured, with the at least one processor302, may cause the performance of the apparatus.

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

The processing system300may be a standalone computer, a server, a console, or a network thereof. The processing system300and 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 system300may 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 system300may be in communication with the remote server device/apparatus in order to utilize the software application stored there.

FIGS.14A and14Bshow tangible media, respectively a removable memory unit365and 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 unit365may be a memory stick, e.g. a USB memory stick, having internal memory366storing the computer-readable code. The internal memory366may be accessed by a computer system via a connector367. The CD368may 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 ofFIGS.5and7to12are 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.