Patent Application
20230284083
Certain examples of the present disclosure provide methods, apparatus and/or systems for flow control. For example, certain examples of the present disclosure provide methods, apparatus and/or systems for DownLink (DL) hop-by-hop flow control within 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) and NR-based relay networks.
To meet the demand for wireless data traffic having increased since deployment of 4G communication systems, efforts have been made to develop an improved 5G or pre-5G communication system. Therefore, the 5G or pre-5G communication system is also called a ‘Beyond 4G Network’ or a ‘Post LTE System’. The 5G communication system is considered to be implemented in higher frequency (mmWave) bands, e.g., 60 GHz bands, so as to accomplish higher data rates. To decrease propagation loss of the radio waves and increase the transmission distance, the beamforming, massive multiple-input multiple-output (MIMO), Full Dimensional MIMO (FD-MIMO), array antenna, an analog beam forming, large scale antenna techniques are discussed in 5G communication systems. In addition, in 5G communication systems, development for system network improvement is under way based on advanced small cells, cloud Radio Access Networks (RANs), ultra-dense networks, device-to-device (D2D) communication, wireless backhaul, moving network, cooperative communication, Coordinated Multi-Points (CoMP), reception-end interference cancellation and the like. In the 5G system, Hybrid FSK and QAM Modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), non-orthogonal multiple access (NOMA), and sparse code multiple access (SCMA) as an advanced access technology have been developed.
The Internet, which is a human centered connectivity network where humans generate and consume information, is now evolving to the Internet of Things (IoT) where distributed entities, such as things, exchange and process information without human intervention. The Internet of Everything (IoE), which is a combination of the IoT technology and the Big Data processing technology through connection with a cloud server, has emerged. As technology elements, such as “sensing technology”, “wired/wireless communication and network infrastructure”, “service interface technology”, and “Security technology” have been demanded for IoT implementation, a sensor network, a Machine-to-Machine (M2M) communication, Machine Type Communication (MTC), and so forth have been recently researched. Such an IoT environment may provide intelligent Internet technology services that create a new value to human life by collecting and analyzing data generated among connected things. IoT may be applied to a variety of fields including smart home, smart building, smart city, smart car or connected cars, smart grid, health care, smart appliances and advanced medical services through convergence and combination between existing Information Technology (IT) and various industrial applications.
In line with this, various attempts have been made to apply 5G communication systems to IoT networks. For example, technologies such as a sensor network, Machine Type Communication (MTC), and Machine-to-Machine (M2M) communication may be implemented by beamforming, MIMO, and array antennas. Application of a cloud Radio Access Network (RAN) as the above-described Big Data processing technology may also be considered to be as an example of convergence between the 5G technology and the IoT technology.
In 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR), Integrated Access and Backhaul (IAB) is a technique for providing wireless backhaul as an alternative to a fibre backhaul network. An IAB network comprises IAB nodes, at which wireless resources are shared between wireless backhaul and access links. Due to the use of the mmWave spectrum, and consequentially the limited coverage area of an IAB node, the backhaul network is typically implemented as a multi-hop network with backhaul traffic traversing multiple IAB nodes.
Flow control is needed in Integrated Access and Backhaul (IAB) networks to prevent congestion occurring. There are two main types of flow control in relay networks: end-to-end and hop-by-hop.
On the UpLink (UL), resource allocation serves as a form of flow control (the parent node has full control over UL transmissions of its child nodes). For the DownLink (DL), end-to-end flow control mechanisms are already in place. Hop-by-hop DL flow control for IAB is currently being developed in 3GPP. However, several open issues need to be finalized in order to design a working IAB system.
Therefore, what is needed is a technique for flow control, and in particular a technique for DL hop-by-hop flow control within 3GPP 5G NR and NR-based relay networks.
The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present invention.
It is an aim of certain examples of the present disclosure to address, solve and/or mitigate, at least partly, at least one of the problems and/or disadvantages associated with the related art, for example at least one of the problems and/or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.
According to one embodiment of the disclosure, a method for flow control in a network, the network including a first node, a second node and a third node, performed by the second node, wherein the second node is a child node of the first node and the third node is a child node of the second node, the method comprising: transmitting, to the first node, flow control feedback information, wherein the flow control feedback information comprises at least one of information on a status of the third node or information on a status of a link between the second node and the third node.
According to another embodiment of the disclosure, a second node for flow control in a network, the network including a first node, the second node and a third node, wherein the second node is a child node of the first node and the third node is a child node of the second node, the second node comprising: a transceiver; and at least one processor configured to: control the transceiver to transmit, to the first node, flow control feedback information, wherein the flow control feedback information comprises at least one of information on a status of the third node or information on a status of a link between the second node and the third node.
Embodiments or examples disclosed in the description and/or figures falling outside the scope of the claims are to be understood as examples useful for understanding the present invention.
Other aspects, advantages, and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.
According to an embodiments of present disclosure apparatus and/or systems for DownLink (DL) hop-by-hop flow control in a NR wireless network is provided.
The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present invention, as defined by the claims. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made.
The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.
Detailed descriptions of techniques, structures, constructions, functions or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.
The terms and words used herein are not limited to the bibliographical or standard meanings, but, are merely used to enable a clear and consistent understanding of the examples disclosed herein.
Throughout the description and claims, the words “comprise”, “contain” and “include”, and variations thereof, for example “comprising”, “containing” and “including”, means “including but not limited to”, and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, functions, characteristics, and the like.
Throughout the description and claims, the singular form, for example “a”, “an” and “the”, encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.
Throughout the description and claims, language in the general form of “X for Y” (where Y is some action, process, function, activity or step and X is some means for carrying out that action, process, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.
Features, elements, components, integers, steps, processes, functions, characteristics, and the like, described in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim disclosed herein unless incompatible therewith.
Certain examples of the present disclosure provide methods, apparatus and/or systems for flow control. The following examples are applicable to, and use terminology associated with, 3GPP 5G. For example, certain examples of the present disclosure provide methods, apparatus and/or systems for DL hop-by-hop flow control within 3GPP 5G NR and NR-based relay networks. However, the skilled person will appreciate that the techniques disclosed herein are not limited to these examples or to 3GPP 5G, and may be applied in any suitable system or standard, for example one or more existing and/or future generation wireless communication systems or standards. The skilled person will appreciate that the techniques disclosed herein may be applied in any existing or future releases of 3GPP 5G NR or any other relevant standard.
For example, the functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function, operation or purpose within the network. For example, the functionality of an IAB node in the examples below may be applied to any other suitable type of entity performing functions of a network node.
The skilled person will appreciate that certain examples of the present disclosure may not be directly related to standardization but rather proprietary implementation of some of the Integrated Access and Backhaul (IAB) functions.
The skilled person will appreciate that the present invention is not limited to the specific examples disclosed herein. For example:
Certain examples of the present disclosure may be provided in the form of an apparatus/device/network entity configured to perform one or more defined network functions and/or a method therefor. Such an apparatus/device/network entity may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and/or method steps for implementing the techniques described herein. For example, an operation/function of X may be performed by a module configured to perform X (or an X-module). Certain examples of the present disclosure may be provided in the form of a system (e.g. a network) comprising one or more such apparatuses/devices/network entities, and/or a method therefor. For example, in the following examples, a network may include one or more IAB nodes.
It will be appreciated that examples of the present disclosure may be realized in the form of hardware, software or a combination of hardware and software. Certain examples of the present disclosure may provide a computer program comprising instructions or code which, when executed, implement a method, system and/or apparatus in accordance with any aspect, claim, example and/or embodiment disclosed herein. Certain embodiments of the present disclosure provide a machine-readable storage storing such a program.
To satisfy extremely high data rate requirements, the 3GPP 5G NR standard utilises communication frequencies in a relatively high range, from 30 GHz to 300 GHz, corresponding to wavelengths in the millimetre (mm) range (mmWave communication). Such mmWave communication provides a large available bandwidth and high transmission speeds. However, problems with mmWave communication include severe signal path loss and low penetration, resulting in a relatively short transmission range. This in turn requires a greater density of base stations deployment.
Due to the relatively high cost and other difficulties associated with deployment of fibre transport network links, wireless backhauling can be used as an alternative. Integrated Access and Backhaul (IAB), in which a part of the radio resources is used for backhauling, is currently being standardized for 3GPP Rel-16.
According to 3GPP TR 38.874 (e.g. V16.0.0, 2018 December), the backhaul architecture is expected to support multi-hop backhauling in which backhaul traffic is wirelessly relayed by network nodes via one or more hops using mmWave communication. Multi-hop backhauling provides more range extension than single hop. This is especially beneficial for above-6 GHz frequencies due to their limited range. Multi-hop backhauling further enables backhauling around obstacles, e.g. buildings in urban environment for in-clutter deployments.
Also according to TR 38.874, IAB strives to reuse existing functions and interfaces defined for access. In particular, Mobile-Termination (MT), gNB-DU, gNB-CU, UPF, AMF and SMF as well as the corresponding interfaces NR Uu (between MT and gNB), F1, NG, X2 and N4 are used as baseline for the IAB architectures.
The Mobile-Termination (MT) function has been defined as a component of the Mobile Equipment, and is referred to as a function residing on an IAB-node that terminates the radio interface layers of the backhaul Uu interface toward the IAB-donor or other IAB-nodes.
In the present disclosure, the following abbreviations and definitions may be used.
An IAB-node (100, 110) may be defined as a RAN node that supports wireless access to UEs (130, 131, 132) and wirelessly backhauls the access traffic. An IAB-donor (120) may be defined as a RAN node which provides UE's interface to core network and wireless backhauling functionality to IAB-nodes (100, 110).
The architecture of
In the architecture of
The IAB-donor (120) also holds a DU to support UEs (130, 131, 132) and MTs of downstream IAB-nodes (100, 110). The IAB-donor (120) holds a CU for the DUs of all IAB-nodes (100, 110) and for its own DU. It is assumed that the DUs on an IAB-node (100, 110) are served by only one IAB-donor (120). This IAB-donor (120) may change through topology adaptation. Each DU on an IAB-node (100, 110) connects to the CU in the IAB-donor (120) using a modified form of F1, which is referred to as F1*. F1*-U runs over RLC channels on the wireless backhaul between the MT on the serving IAB-node and the DU on the IAB-donor (120). An adaptation layer is added—named Backhaul Adaptation Layer, or BAP, in the ongoing normative phase—which performs bearer mapping and routing. It replaces the IP functionality of the standard F1-stack. F1*-U may carry a GTP-U header for the end-to-end association between CU and DU.
The Uu interface represents the interface between the UE (130, 131, 132) and the DU in an IAB node (100, 110). The F1* interface represents the interface between the IAB DU and an upstream CU.
In the architecture of
In NR Rel-16 IAB, Hop-by-Hop (HbH) flow control feedback is limited to single-hop, and includes available or desired buffer size (in absolute terms, rather than relative terms e.g. percentage). Additionally, the flow control feedback can only be reported for a subset of bearers with the same routing ID (basically bearers heading to the same final destination), or for the entire channel (total buffer status of a channel of the link). Moreover, reporting based on polling and threshold-based reporting are both introduced.
In certain examples of the present disclosure a first node may receive flow control feedback from a second node that is a child node of the first node. The flow control information may comprise first information relating to a status of the second node (e.g. buffer status) and/or a status of the link between the first node and the second node (e.g. congestion status). The first node may receive such information from one or more, or all, of its child nodes. For example, in
When there is a third node that is a child node of the second node, the flow control feedback received by the first node may also include second information relating to a status of the third node (e.g. buffer status) and/or a status of the link between the second node and the third node (e.g. congestion status). The first node may receive such information relating to one or more, or all, of the child nodes of its own child nodes. For example, in
In certain examples, the flow control feedback information received by the first node may include information relating to the status of nodes and/or links further downstream. For example, in
Various aspects of examples of the present disclosure include the content of the flow control feedback, the circumstances and criteria according to which the flow control feedback is provided or reported, and the action that a node may take in response to receiving the flow control feedback.
Various examples of these aspects are described below. However, the skilled person will appreciate that the present disclosure is not limited to these specific examples. The flow control feedback may comprise any suitable type of information for enabling flow control. The flow control feedback may be provided or reported in response to any suitable set of one or more criteria. A node may take any suitable action(s) in response to receiving the flow control feedback, or may determine not to take any action.
In the following examples, flow control feedback from a child node to a parent node may contain information on the status of the links of the child node to one or more of its own child nodes. This could include:
In certain examples, one or more existing control PDUs could be used for reporting the enhanced content according to the examples above. For instance, one of the reserved ‘R’ bits could be used to indicate that the control PDU carries an estimated change in occupancy of own buffers (rather than actual occupancy). Another reserved ‘R’ bit could be used to indicate that what is being reported is buffer status of child nodes of the child node. Additional fields could be added to the control PDU to carry, for instance, desired data rate for a node in question or its child nodes, a number of hops to the node to which the report refers, etc., according to above examples.
In certain examples of the present disclosure, the reporting may be done based on different groupings, for example one or more of the following:
The value of the grouping variable may also be included in the report. For instance, the node may report joint buffer status in one of its child nodes for all the data in that child node with a specified routing ID, together with the routing ID in question. The receiving node (parent of the reporting node) may then get an estimate of how congested the route towards that specific destination (given by the specified routing ID) is.
In cases where there is no universal node identifier, and the parent node can only see the routing ID and the next hop node(s) for that specific routing ID, and (as per examples of the present disclosure) the report from further down the chain on the occupancy of buffers for data with that same routing ID, the parent node can still estimate how congested that route ID is further down the line. It can then start sending data for that same destination via a different path (i.e. different routing ID, which is a unique combination of path ID and destination address, but use the same destination address, over a different path).
The reports may also be shared with the CU, which may then modify the routing tables (as opposed to this being done locally as in the example just described).
In another example, if grouping is done by radio bearers (e.g. per bearer ID) then the receiving node would know if a specific bearer is getting congested e.g. two hops down the line. There may be no congestion in the first hop (on the link to the reporting node), but reports from a reporting node on link/buffer status from nodes further down the chain could indicate that there is in fact congestion at later hops. Therefore, the node receiving the reports may infer that there is no point in continuing to send the data for the same bearer via the same next hop. This information may also be shared with the CU, which may then reconfigure routing tables.
In certain examples of the present disclosure, one or more of the following techniques may be applied:
In certain examples of the present disclosure, a triggering condition(s) for (self-) reporting, by a node, of the flow control feedback may include one or more of the following:
In certain examples, the triggering condition(s) can be set by the Donor-CU, or by the parent node. In certain examples, the triggering conditions may be predefined, for example based on node type (e.g. local vs. wideband node), number of its child nodes, etc.
In certain examples, reporting may be periodic, for example as configured by the parent node (e.g. by using a specific BAP layer Control Element, or CE), or by the CU (e.g. by reconfiguring the node via OAM or RRC).
In certain examples, reporting may be based on polling, for example by the parent node (e.g. triggered by reception of a specific BAP layer Control Element, or CE) or by the CU (e.g. change of node configuration via OAM or RRC). In certain examples, the triggering condition(s) for polling of the flow control feedback may include one or more of the following:
In certain examples, a node receiving information according to the examples disclosed herein (e.g. IAB-DU of the parent node) may do one or more of the following in response:
In a first step 401, a report is received (e.g. by a first node), for example in response to polling (e.g. by the first node) or self-reporting by a second node (e.g. a child node of the first node). For example, the first node receives an enhance report from the second node.
In a second step 402, it is determined (e.g. by the first node) based on the received report whether there is any indication that the transmission rate to a child node should be modified. For example, the first node determines whether there is any indication that the transmission rate to a child node should be modified, based on the received enhance report. If it is determined that the transmission rate should be modified then the method proceeds to a third step 403, otherwise the third step is skipped and the method proceeds directly to a fourth step 404. For example, if it is determined that the transmission rate should not be modified then the method proceeds to the fourth step 404.
In the third step 403, the transmission rate (for example overall or per bearer/routing ID, etc.) is lowered. For example, the transmission rate may be controlled to be lowered per bearer or per routing ID.
In the fourth step 404, it is determined (e.g. by the first node) based on the received report whether there is any indication that load balancing is needed/beneficial. For example, the first node determines whether there is any indication that load balancing is needed/beneficial based on the received enhanced report. If it is determined that load balancing is needed/beneficial then the method proceeds to a fifth step 405, otherwise the fifth step is skipped and the method ends or proceeds back to the first step 401.
In the fifth step 405, load balancing is performed (e.g. by the first node). For example, the first node performs the load balancing.
In certain examples of the present disclosure, the flow control feedback may include a time stamp (indication of validity of information therein). In certain examples, when polling, the network/parent node IAB-DU may include a request indicating how recent the data needs to be. The child node may then provide the information which it already has, or poll its child nodes for more up-to-date information.
For load balancing (local), a node can either be restricted to use of the routing alternatives as pre-determined by the CU, or it can make local decisions.
In a first step 501, flow control feedback is received (e.g. by a first node), for example in response to polling (e.g. by the first node) or self-reporting by a second node (e.g. a child node of the first node). For example, the first node receives an enhance report from the second node.
In a second step 502, it is determined (e.g. by the first node or another network entity) whether or not a node (e.g. the first node) is restricted by CU to preconfigured alternatives.
If the node is not restricted, then in a third step 503 the route is decided (e.g. by the first node or another network entity) using received information and internal KPIs (e.g. fairness, efficiency, latency).
On the other hand, if the node is restricted, then in a fourth step 504 it is determined (e.g. by the first node or another network entity) whether or not CU has configured priority among alternative routes.
If CU has not configured priority, then in a fifth step 505 any of the alternative routes (random, or based on implementation) may be chosen (e.g. by the first node or another network entity).
On the other hand, if CU has configured priority, then in a sixth step 506 it is determined (e.g. by the first node or another network entity) whether or not at least one of the alternative RLF is free.
If at least one of the alternative RLF is not free, then in a seventh step 507 packets are dropped (e.g. by the first node). For example, the first node drops the packets.
On the other hand, if at least one of the alternative RLF is free, then in an eighth step 508, the priority list is followed (e.g. by the first node). For example, the first node follows the priority list.
For load balancing (e.g. centralized), certain examples of the present disclosure may feed-back information on flow control to CU.
The entity 600 comprises a processor (or controller) 601, a transmitter 603 and a receiver 605. The receiver 605 is configured for receiving one or more messages from one or more other network entities. The transmitter 603 is configured for transmitting one or more messages to one or more other network entities. The transmitter 603 and the receiver 605 may be referred to as a transceiver or a communicator or a communication unit according to various embodiments.
The processor 601 is configured for performing operations as described above. In the disclosure, the processor 601 may be defined as a circuit, an application-specific integrated circuit, or a controller.
Certain examples of the present disclosure provide a method for flow control in a network including a first node, a second node and a third node, wherein the second node is a child node of the first node and the third node is a child node of the second node, the method comprising: receiving, by the first node from the second node, flow control feedback information, wherein the flow control feedback information comprises information on a status of the third node and/or a status of a link between the second node and the third node.
In certain examples, the flow control feedback information may comprise information indicating one or more of: the status of the link and an ID of the link; the status of a buffer (e.g. IAB-DU buffer) of the third node; a combined/average status of the link; a combined/average status of a buffer (e.g. IAB-DU buffer) of the third node; and a status report relating to a child node of the third node.
In certain examples, the information indicating the status of the link may comprise one or more values indicating one or more of: “not congested”, “congested”, “some congestion”, and a degree of congestion.
In certain examples, the information indicating the status of the buffer may comprise one or more values indicating one or more of: “full”, “not full”, used buffer space, remaining buffer space, and recommended transmission rate.
In certain examples, the status report may include one or more of: a link status, a buffer status, combined/average link status, combined/average buffer status, a distance from the reporting node, node ID, and node address.
In certain examples, the flow control feedback information may be grouped according to one or more of the following: per routing ID; per bearer ID; per destination IP address; per destination BAP address; per specific link ID; per channel on a specific link; and per destination Donor-DU.
In certain examples, the method may further comprise grouping radio bearers into radio bearer groups (e.g. based on QoS requirements and/or type of bearer).
In certain examples, the flow control feedback information may comprise information only for a sub-set of radio bearers and/or a sub-set of radio bearer groups.
In certain examples, the flow control feedback information may comprise information only for a sub-set of backhaul links.
In certain examples, the second node transmits the flow control feedback information to the first node based on one or more triggering conditions.
In certain examples, the one or more triggering conditions may include one or more of the following: a buffer level of the second node or a buffer level of the third node has exceeded a certain threshold; the third node has reported a preferred transmission rate below a certain threshold; a packet error rate has fallen below a certain threshold on one or more egress links of the third node; one or more egress links of the third node has suffered a radio link failure or is predicted to suffered a radio link failure based on feedback information from child nodes of the third node; expiration of a time stamp; and the difference between ingress and egress throughputs of the third node exceeds a certain threshold.
In certain examples, the one or more triggering conditions may be configured for bearers carrying a specific service and/or bearers having a certain priority.
In certain examples, the second node may transmit the flow control feedback information periodically (e.g. configured by the first node or by a CU).
In certain examples, the second node may transmit the flow control feedback information in response to polling (e.g. by the first node or by a CU).
In certain examples, the polling may be done based on one or more triggering conditions, including one or more of the following: reconfiguration of a routing table; an increase in a transmission rate from the first node; a packet error rate, or a similar rate at any protocol layer, falls below a certain threshold on one or more links; a topology change in a wider network; and a change in a number of child nodes of the first node and/or UEs attaching to the first node.
In certain examples, the method may further comprise performing, by the first node, based on the received flow control feedback information, one or more of: lowering a transmission rate to the second node; and performing load balancing.
In certain examples, the transmission rate may comprises one or more of: an overall sending rate; a sending rate per bearer; a sending rate per destination; and a sending rate per routing ID.
In certain examples, the load balancing may comprise one or more of: re-routing traffic; and dropping certain packets.
In certain examples, a packet may be dropped based on a determination that the packet will not be useful and/or will not be used once it reaches its destination (e.g. based on an estimated delay of the packet to reach its destination).
Certain examples of the present disclosure provide a method for flow control in a network including a first node, a second node and a third node, wherein the second node is a child node of the first node and the third node is a child node of the second node, the method comprising: transmitting, by the second node to the first node, flow control feedback information, wherein the flow control feedback information comprises information on a status of the third node and/or a status of a link between the second node and the third node.
Certain examples of the present disclosure provide a first node for flow control in a network including the first node, a second node and a third node, wherein the second node is a child node of the first node and the third node is a child node of the second node, wherein the first node is configured to receive, from the second node, flow control feedback information, wherein the flow control feedback information comprises information on a status of the third node and/or a status of a link between the second node and the third node.
Certain examples of the present disclosure provide a second node for flow control in a network including a first node, the second node and a third node, wherein the second node is a child node of the first node and the third node is a child node of the second node, wherein the second node is configured to transmit, to the first node, flow control feedback information, wherein the flow control feedback information comprises information on a status of the third node and/or a status of a link between the second node and the third node.
Certain examples of the present disclosure provide a network comprising a first node and a second node according to the above examples.
Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out any method disclosed herein. Certain examples of the present disclosure provide a computer-readable data carrier having stored thereon such a computer program.
While the invention has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the invention, as defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2012202.4 | Aug 2020 | GB | national |
This application is a 371 of International Application No. PCT/KR2021/010318 filed on Aug. 5, 2021, which claims priority to United Kingdom Patent Application No. 2012202.4 filed on Aug. 5, 2020, the disclosures of which are herein incorporated by reference in their entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/KR2021/010318 | 8/5/2021 | WO |
