Technical Field

[0001] The present disclosure relates to Radio Access Network (RAN) control, and in particular to Symbol Based methods for improving time critical communication (TCC) services.

Background

[0002] Time critical communication (TCC) services are characterized by requiring packet data delivery within a specified bounded latency and with a specific bounded reliability. Depending on the application requirements, the bounded latency may range from tens of milliseconds to 1 millisecond, and the bounded reliability may range from 99 percent to 99.999 percent. The Third Generation Partnership Project (3GPP) have specified a large number of functions related to TCC services in their technical standard releases for the 5G New Radio (NR) (e.g. release 15 and later) under a work item called Ultra-Reliable Low Latency Communication (URLLC). The terms TCC and URLLC may be used synonymously. The reliability and bounded latency requirements of TCC are typically much tougher than for enhanced mobile broadband (eMBB) type of traffic where throughput usually is the most important performance indicator. As industry is also pushing RAN solutions to have improved energy efficiency and more cost effective solutions, all the requirements have lead the RAN design (e.g. in the Baseband Processing Unit (BPU) and Radio) towards a tight collaboration model and down to symbol level of granularity to suite different needs at a given time.

[0003] To date, there are known features and functions to improve the communication reliability and bounded latency at the slot, mini slot and link level (involving UE). Today’s RAN level solution to deliver data is focused on eMBB type of traffic, and it is not optimized for TCC services with corresponding reliability and latency requirements. For example, the radio control loop can introduce radio link impairments in the form of transient data errors or “glitches”, which typically have a duration of one or a few symbols. Common sources of these glitches include Digital pre-distortion (DPD) restart and automatic gain control (AGC) state changes within the radio control loops. Typically, glitches are treated as a localized behavior in the radio, and any needed recovery process is only visible to, and handled by, the radio itself. The related performance impact may not be visible to higher layers, or it is tolerated. It is generally not treated at the RAN level.

[0004] Current development of the RAN network is mainly focused on maximizing the throughput at the bit level, whereas for TCC services the reliability and latency are also important.

[0005] At symbol level (e.g. OFDM), radio related performance is not always the same. For example, immediately after a Time Division Duplex (TDD) Downlink (DL) slot is turned on, the first few symbols error vector magnitude (EVM) performance is in general worse than the subsequent DL symbols. Another example is the so-called Micro sleep feature (also known as Symbol Based Power Saving (SBPS)) which causes the power amplifier to switch ON and OFF, leading to a negative performance impact. There is currently no differentiation to handle these glitches at the symbol level.

[0006] At the RAN level, in downlink, the current link adaptation approach is based on channel state information (CSI) feedback measured in and reported by the UE to the gNB, to determine the channel quality and to change the MCS scheme et.al. for data delivery. Link adaptation based on CSI feedback can be considered to be a “slow” control loop, because it involves a round-trip (i.e. from the gNB to the UE and then back to the gNB) delay that is typically longer than the (e.g. 1 ms) latency tolerance that is needed for some TCC services. Similarly, downlink data transmission scheduling based on HARQ feedback from the UE can also be considered as a “slow” control loop, because it also involves a round-trip delay that is typically longer than the (e.g.

1 ms) latency tolerance that is needed for some TCC services. Radio component based signal distortion should be more predictable than over-the-air channel fading and interference, but both sources of signal distortion are commonly treated together by CSI for baseband without differentiation.

[0007] Improved support for TCC services remains highly desirable.

[0008] An aspect of the present disclosure provides a method in a wireless node of a wireless network. The wireless node includes a radio unit (RU) coupled to at least one baseband processing unit (BPU). The method comprises: detecting, by the RU, impairments affecting performance of a radio link supported by the radio transceiver; sending, by the RU, information regarding the detected impairments to the at least one BPU; and allocating, by a scheduler of the at least one BPU, radio resources for time critical communication (TCC) services based at least in part on the detected impairments.

[0009] In some embodiments, detecting impairments affecting performance of the radio link comprises detecting any one of more of:

• a radio channel impairment;

• a reset of digital predistorsion (DPD);

• a change of state of automatic gain control (AGC); and

• a transmission delay.

[0010] In some embodiments, the information indicative of impairments affecting performance of the radio link comprises an identification of radio resources affected by the detected impairment.

[0011] In some embodiments, allocating radio resources comprises scheduling data for TCC services to radio resources that are least affected by the detected impairments.

[0012] In some embodiments, in a 3GPP network, scheduling data for TCC services comprises scheduling a transport block to resource elements that are least affected by the detected impairments.

[0013] In some embodiments, in a transmit mode, the method further comprises: predicting, by a first BPU, that a transport block currently being transmitted is likely to fail decoding and cyclic redundancy check (CRC) by a user equipment (UE); and retransmitting, by the first BPU, the transport block to the UE before receiving a NACK result from the UE.

[0014] In some embodiments, the BPU terminates transmission of the transport block to the UE prior to retransmitting the transport block:

[0015] In some embodiments, in a receive mode, the method further comprises:

• predicting, by a first BPU, that a transport block currently being received by the wireless node is likely to fail decoding and cyclic redundancy check (CRC);

• sending, via the RU, a NACK result or a re-transmission request pertaining to the transport block; and

• discarding a received portion of the transport block, without decoding or CRC.

[0016] A further aspect of the present disclosure provides a method in a baseband processing unit (BPU) of a wireless network node including a radio unit (RU) connected to at least one BPU. The method comprises:

• receiving, from the RU, information indicative of impairments affecting performance of a radio link supported by the RU;

• controlling allocation of radio resources for time critical communication (TCC) services through the RU, based at least in part on the received information.

[0017] In some embodiments, the information indicative of impairments affecting performance of a radio link comprises information indicative of any one of more of:

• a radio channel impairment;

• a reset of digital predistorsion (DPD);

• a change of state of automatic gain control (AGC); and

• a transmission delay. [0018] In some embodiments, the information indicative of impairments affecting performance of the radio link comprises an identification of radio resources affected by the detected impairment

[0019] In some embodiments, allocating radio resources comprises scheduling data for TCC services to radio resources that are least affected by the detected impairments.

[0020] In some embodiments, in a 3GPP network, scheduling data for TCC services comprises scheduling a corresponding transport block to resource elements that are least affected by the detected impairments.

[0021] In some embodiments, in a transmit mode of the wireless node, the method further comprises:

• predicting, by the BPU, that a transport block currently being transmitted is likely to fail decoding and cyclic redundancy check (CRC) by a user equipment (UE); and

• retransmitting, by the BPU, the transport block to the UE before receiving a NACK result from the UE.

[0022] In some embodiments, the BPU terminates transmission of the transport block to the UE prior to retransmitting the transport block:

[0023] In some embodiments, in a receive mode, the method further comprises:

• predicting, by the BPU, that a transport block currently being received by the wireless node will fail decoding and cyclic redundancy check (CRC);

• sending, via the RU, a NACK result pertaining to the transport block; and

• discarding a received portion of the transport block, without decoding or CRC.

[0024] A further aspect of the present disclosure provides a method in a radio unit (RU) of a wireless network node including the RU connected to at least one baseband processing unit (BPU). The method comprises: detecting impairments affecting performance of a radio link supported by the RU; and

• sending, to the at least one BPU, information indicative of the detected impairments.

[0025] In some embodiments, detecting impairments affecting performance of a radio link comprises detecting any one of more of:

• a radio channel impairment;

• a reset of digital predistorsion (DPD);

• a change of state of automatic gain control (AGC); and

• a transmission delay.

[0026] In some embodiments, the information indicative of impairments affecting performance of the radio link comprises an identification of radio resources affected by the detected impairment.

[0027] A further aspect of the present disclosure provides a radio node of a wireless network. The radio transceiver comprises: a radio unit (RU) configured to detect impairments affecting performance of a radio link supported by the radio transceiver; and at least one baseband processing unit (BPU) configured to allocate radio resources for time critical communication (TCC) services based at least in part on the detected impairments.

[0028] A further aspect of the present disclosure provides a node of a wireless network. The node comprises: at least one processor; and a memory storing program instructions configured to control the at least one processor to perform steps of:

• receiving, from a radio unit (RU), information indicative of impairments affecting performance of a radio link supported by the RU;

• controlling allocation of radio resources for time critical communication (TCC) services through the RU, based at least in part on the received information. [0029] In some embodiments, the node is one of: a baseband processing unit of the wireless network; and a virtual BPU function of an Open RAN Distributed Unit.

[0030] A further aspect of the present disclosure provides a radio unit (RU) of a wireless network node including the RU and at least one baseband processing unit (BPU). The RU comprises: at least one processor; and a memory storing program instructions configured to control the at least one processor to perform steps of:

• detecting impairments affecting performance of a radio link supported by the RU; and

• sending, to the at least one BPU, information indicative of the detected impairments.

[0031] Embodiments of a base station, communication system, and a method in a communication system are also disclosed.

Brief Description of the Drawings

[0032] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain principles of the disclosure.

[0033] FIG. 1 is a block diagram schematically illustrating a representative network in which embodiments of the present disclosure may be deployed;

[0034] FIGs. 2A and 2B are block diagrams schematically illustrating examples of a computing device usable in embodiments of the present disclosure;

[0035] FIG. 3 is a block diagram schematically illustrating an architecture of a representative network element virtualization usable in embodiments of the present disclosure;

[0036] FIG. 4 is a block diagram schematically illustrating elements of a system in which methods according to embodiments of the present disclosure may be implemented;

[0037] FIG. 5 is a flow chart showing a method for static TCC friendly capability radio reporting in accordance with the present disclosure; [0038] FIGs. 6A and 6B are flow charts showing dynamic TCC friendly capability radio reporting in accordance with the present disclosure;

[0039] FIGs. 7A and 7B are flow charts respectively showing methods for static and dynamic TCC service notification in accordance with the present disclosure;

[0040] FIGs. 8A and 8B are block diagrams schematically illustrating elements of a system in which methods of retransmission prediction according to respective embodiments of the present disclosure may be implemented;

[0041] FIGs. 9A and 9B are block diagrams schematically illustrating elements of another system in which methods of retransmission prediction according to respective embodiments of the present disclosure may be implemented;

[0042] FIG. 10 is a block diagram schematically illustrating cloud-based operations in accordance with embodiments of the present disclosure.

Detailed Description

[0043] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0044] At least some of the following abbreviations and terms may be used in this disclosure.

• 2D Two Dimensional

• 3GPP Third Generation Partnership Project

• 5G Fifth Generation

• AAS Antenna Array System

• AGC Automatic Gain Control

• AoA Angle of Arrival

• AoD Angle of Departure

• ASIC Application Specific Integrated Circuit BB Baseband

BF Beamforming

BLER Block Error Rate

BPU Baseband Processing Unit

BW Beamwidth

C-loT Critical loT

CPU Central Processing Unit

CSI Channel State Information dB Decibel

DCI Downlink Control Information

DFT Discrete Fourier Transform

DL Down Link

DPD Digital Pre-Distortion

DSP Digital Signal Processor eMBB enhanced Mobile Broadband eNB Enhanced or Evolved Node B

FIR Finite Impulse Response

FPGA Field Programmable Gate Array gNB New Radio Base Station

ICC Information Carrying Capacity

HR Infinite Impulse Response loT Internet of Things

LTE Long Term Evolution

MIMO Multiple Input Multiple Output

MME Mobility Management Entity

MMSE Minimum Mean Square Error

MTC Machine Type Communication

NR New Radio

O-RAN Open RAN

OTT Over-the-Top

PBCH Physical Broadcast Channel

PDCCH Physical Downlink Control Channel PDSCH Physical Downlink Shared Channel

P-GW Packet Data Network Gateway

QoS Quality of Service

RAM Random Access Memory

RAN Radio Access Network

RIC RAN Intelligence Controller

ROM Read Only Memory

RRC Radio Resource Control

RRH Remote Radio Head

RT Real Time

RU Radio Unit

SBPS Symbol Based Power Saving

SCEF Service Capability Exposure Function

SINR Signal to Interference plus Noise Ratio

TBS Transmission Block Size

TCC Time Critical Communication

UE User Equipment

UL Up Link

ULA Uniform Linear Array

URA Uniform Rectangular Array

SMO service management and orchestration

URLLC Ultra Reliable Low Latency Communication

[0045] Radio Node: As used herein, a “radio node” is either a radio access node or a wireless device.

[0046] Radio Access Node: As used herein, a “radio access node” or “radio network node” is any node in a radio access network of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

[0047] Core Network Node: As used herein, a “core network node” is any type of node in a core network. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), or the like.

[0048] Wireless Device: As used herein, a “wireless device” is any type of device that has access to (i.e. , is served by) a cellular communications network by wirelessly transmitting (and/or receiving) signals to (and/or from) a radio access node. Some examples of a wireless device include, but are not limited to, a User Equipment device (UE) in a 3GPP network and a Machine Type Communication (MTC) device.

[0049] Network Node: As used herein, a “network node” is any node that is either part of the radio access network or the core network of a cellular communications network/system.

[0050] Cell: As used herein, a “cell” is a combination of radio resources (such as, for example, antenna port allocation, time and frequency) that a wireless device may use to exchange radio signals with a radio access node, which may be referred to as a host node or a serving node of the cell. However, it is important to note that beams may be used instead of cells, particularly with respect to 5G NR. As such, it should be appreciated that the techniques described herein are equally applicable to both cells and beams.

[0051] Note that references in this disclosure to various technical standards (such as 3GPP TS 38.211 V15.1.0 (2018-03) and 3GPP TS 38.214 V15.1.0 (2018-03), for example) should be understood to refer to the specific version(s) of such standard(s) that is(were) current at the time the present application was filed, and may also refer to applicable counterparts and successors of such versions.

[0052] The description herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system. [0053] FIG. 1 illustrates one example of a cellular communications network 100 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications network 100 is a Public Land Mobility Network (PLMN) conforming to one or more of the LTE, 3G, 4G and 5G NR standards, or their successors. In the illustrated example, the cellular communications network 100 includes a Radio Access Network (RAN) 102 comprising base stations 104-1 and 104-2 controlling radio communications with wireless devices 106-1 , 106-2, 106-3, 106-4,106-5 within corresponding macro cells 108-1 and 108-2. Each macro cell 108 may be defined by any suitable combination of geography, frequency, Radio Access Technology (RAT) and modulation scheme.

[0054] Base stations 104 can be any type of network access device capable of establishing radio connection(s) with one or more wireless devices 106 within a respective coverage area of the base station 104 or low power node 112, and further configured to forward subscriber traffic between the core network 114 and the one or more wireless devices 106. An important feature of a base station 104 is that it is configured with both a radio interface configured to send and receive radio signals to and from a wireless device 106, and a network interface configured to exchange electronic and/or optical signals with the core network 114. Examples of base stations 104 and low power nodes 112 include: Evolved Node B (eNB) systems (known, for example, in the 3GPP standards): WiFi access points (known, for example from IEEE 802.11 standards) or the like. In some contexts, a base station 104 may be referred to as an access point (AP) regardless of the Radio Access Technology (RAT) that it supports.

[0055] The illustrated RAN 102 also includes small cells 110-1 through 1 10-4, within which radio communication can be controlled by corresponding low power nodes 112-1 through 112-4. As with the macro cells 108, each small cell may be defined by any suitable combination of geography, frequency, Radio Access Technology (RAT) and modulation scheme. As with the base stations 104, a low power node 112 can be any type of network access device capable of establishing radio connection(s) with one or more wireless devices 106 within a respective coverage area of the low power node 112, and further configured to forward subscriber traffic between the core network 114 and the one or more wireless devices 106. An important feature of a low power node 112 is that it is configured with both a radio interface configured to send and receive radio signals to and from a wireless device 106, and a network interface configured to exchange electronic and/or optical signals with the core network 114. In some embodiments, a low power node 112 may be connected to the core network 114 by a direct connection, such as an optical cable. In other embodiments, a low power node 112 may be connected to the core network 114 by an indirect connection, such as via a radio or optical fiber link to a base station 104. Examples of low power nodes 1 12 include: Remote Radio Heads (RRHs) connected to a base station or a network router (not shown): WiFi access points or the like. In some contexts, a low power node 112 may be referred to as an access point (AP) regardless of the specific Radio Access Technology (RAT) that it supports.

[0056] Notably, while not illustrated, a particular small cell 110 may alternatively be controlled by a base station 104, for example using a beam-forming technique. In such cases, the particular small cell 110 will not be associated with a respective low power node 112 per se. Rather, the particular small cell 110 will be associated with a respective set of parameters implemented in the base station 104. In this disclosure, the term “cell” is used to refer to a defined combination of parameters (such as geography, frequency, Radio Access Technology (RAT), modulation scheme, identifiers and the like) that can be used by a wireless device 106 to access communication services of the network 100. The term “cell” does not imply any particular parameter values, or any particular physical configuration of devices needed to enable a wireless device 106 to access those communication services.

[0057] Wireless devices 106 can be any type of device capable of sending and receiving radio signals to and from a base station 104 and/or low power node 112. Examples of wireless device 106 include cellular phones, Personal Data Assistants (PDAs), mobile computers, Internet of Things (loT) devices, autonomous vehicle controllers, and the like. In some contexts, a wireless device 106 may be referred to as a User Equipment (UE) or a mobile device.

[0058] In some embodiments, the macro cells 108-1 and 108-2 may overlap each other, and may also overlap one or more small cells 110. For example, a particular macro cell 108-1 may be one macro cell 108 among a plurality of macro cells covering a common geographical region and having a common RAT and modulation scheme, but using respective different frequencies and/or AP identifiers. In such cases, a wireless device 106 located within a region covered by two or more overlapping cells 108, 112 may send and receive radio signals to and from each of the corresponding base stations 104 and/or low power nodes 112.

[0059] In the illustrated example, the RAN 102 is connected to a Core Network (CN) 114, which may also be referred to as Evolved Core Network (ECN) or Evolved Packet Core (EPC). The CN 114 includes (or, equivalently, is connected to) one or more servers 116 configured to provide networking services such as, for example, Network Functions (NFs) described in 3GPP TS 23.501 V15.2.0 (2018-06) “System Architecture for the 5G System” and its successors. The CN 114 also includes one or more gateway (GW) nodes 118 configured to connect the CN 114 to a packet data network (DN) 120 such as, for example, the internet. A gateway node 118 may be referred to as a packet gateway (PGW) and/or a serving gateway (SGW). The DN 120 may provide communications services to support end-to-end communications between wireless devices 106 and one or more application servers (ASs) 122 configured to exchange data packet flows with the wireless devices 106 via the CN 114 and RAN 102. In some contexts, an application server (AS) 122 may also be referred to as a host server.

[0060] In some contexts, an end-to-end signal path between an AS 122 and one or more wireless devices 106 may be referred to as an Over-The-Top (OTT) connection. Similarly, a communication service that employs signal transmission between an AS 122 and one or more wireless devices 106 may be referred to as an OTT service.

[0061] It should be appreciated that the separation between the CN 114 and the DN 120 can be purely logical, in order to simplify understanding of their respective roles. In particular, the CN 114 is primarily focused on providing wireless device access services and supporting wireless device mobility. On the other hand, the DN 120 is primarily focused on providing end-to-end communications, particularly across network domains. However, it will be appreciated that both the CN 114 and the DN 120 can be implemented on common physical network infrastructure, if desired.

[0062] FIGs. 2A and 2B are block diagrams schematically illustrating a communications system 200 including a computing device 202 usable in embodiments of the present disclosure. In various embodiments, any or all of the base stations 104 or 112, wireless devices 106, core network servers 1 16 or gateways 118 and data network servers 122 may be implemented using systems and principles in accordance with the computing device 202. It may also be appreciated that any or all of the elements of the network 100 may be virtualized using techniques known in the art or developed in the future, in which case the functions of any or all the base stations 104 or 112, core network servers 116 or gateways 118, and/or any or all network functions may be implemented by suitable software executing within a computing device 202 or within a data center (non shown) composed of multiple computing devices 202.

[0063] In the example of FIG. 2A, the communications system 200 generally includes computing device 202 connected to one or more networks 210 and one or more radio units 212. The computing device 202 includes processing circuitry such as one or more processors 204, a memory 206, one or more network interfaces 208. The processors 204 may be provided as any suitable combination of Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or the like. Similarly, the memory 206 may be provided as any suitable combination of Random Access Memory (RAM), Read Only Memory (ROM) and mass storage technologies such as magnetic or optical disc storage or the like. The network interfaces 208 enable signaling between the computing device 200 and the networks 210, such as the Core Network 114, the data network 120, or a private domain network such as a data center (not shown).

[0064] Each radio unit 212 typically includes at least one transmitter (Tx) 214 and at least one receiver (Rx) 216 coupled to one or more antennas 218. In the example of FIG. 2A, the radio unit(s) 212 is(are) shown as being external to the computing device 202 and connected to the computing device 202 via a suitable physical connection (such as a copper cable or an optical cable). In the example of FIG. 2B, the radio unit(s) 212 is(are) shown as being connected to computing device 202 via a network 210 and a network interface 208. In still other embodiments, the radio unit(s) 212 and optionally also the antenna(s) 218 may be integrated together with the computing device 202.

[0065] The one or more processors 204 operate to provide functions of the computing device 202. Typically, these function(s) are implemented as software applications (APPs) 220 or modules that are stored in the memory 206, for example, and executed by the one or more processors 204. In some embodiments, one or more software applications or modules 220 may execute within a secure run-time environment (RTE) 222 maintained by an operating system (not shown) of the computing device 202.

[0066] It may be appreciated that specific embodiments may exclude one or more of the elements illustrated in FIGs. 2A and 2B. For example, a computing device 202 configured to implement a wireless device 106 may incorporate processing circuitry including one or more processors 204, a memory 206, and one or more radio units 212, but may exclude a network interface 208. Conversely, a computing device 202 configured to implement a server 1 16 or 122 may include processing circuitry including one or more processors 204, a memory 206, and one or more network interfaces 208, but may exclude radio units 212. A computing device 202 configured to implement a base station 104 or 112, on the other hand, will normally include processing circuitry including one or more processors 204, a memory 206, and both radio units 212 and network interfaces 208.

[0067] FIG. 3 is a block diagram schematically illustrating an example architecture for network element virtualization usable in embodiments of the present disclosure. It is contemplated that the network elements may be physically implemented using one or more computers, data storage devices and routers (any or all of which may be constructed in accordance with the system 200 described above with reference to FIG. 2) interconnected together and executing suitable software to perform its intended functions. Those of ordinary skill will recognize that there are many suitable combinations of hardware and software that may be used for this purpose, which are either known in the art or may be developed in the future. For this reason, a figure showing physical hardware components and connections is not included herein.

[0068] As maybe seen in FIG. 3, the illustrated architecture 300 generally comprises hosting infrastructure 302, a virtualization layer 304 and an Application Platform Services layer 306. The hosting infrastructure 302 comprises physical hardware resources provided by the infrastructure on which the architecture 300 is being implemented. These physical hardware resources may include any or all of the processors 204, memory 206, network interfaces 208 and radio units 212 described above with reference to FIG. 2, and may also include traffic forwarding and routing hardware 308. The virtualization layer 304 presents an abstraction of the hardware resources 302 to the Application Platform Services layer 306. The specific details of this abstraction will depend on the requirements of the applications 220 being hosted by the Application Platform Services layer 306. Thus, for example, an APP 220 that provides traffic forwarding functions (for example as part of a User Plane Function) may be presented with an abstraction of the hardware resources 306 (e.g. processor(s) 204, memory 206 and traffic forwarding hardware 308) that simplifies the implementation of traffic forwarding policies. Similarly, an application that provides data storage functions may be presented with an abstraction of the hardware resources 306 (e.g. processor(s) 204 and memory 206) that facilitates the storage and retrieval of data (for example using Lightweight Directory Access Protocol - LDAP).

[0069] The application platform 306 provides the capabilities for hosting applications. In some embodiments, the application platform 306 supports a flexible and efficient multi-tenancy run-time and hosting environment for applications 220 by providing Infrastructure as a Service (laaS) facilities. In operation, the application platform 306 may provide a security and resource “sandbox” for each application 220 being hosted by the platform 306. Each “sandbox” may be implemented as a Virtual Machine (VM) image 310 that may include an appropriate operating system and controlled access to (virtualized) hardware resources 302. Alternatively, each “sandbox” may be implemented as a container 311 that may include appropriate virtual memory and controlled access to host operating system and (virtualized) hardware resources 302. The application platform 306 may also provide a set of middleware application services and infrastructure services to the applications 220 hosted on the application platform 306, as will be described in greater detail below.

[0070] Applications 220 from vendors, service providers, and third-parties may be deployed and executed within a respective Virtual Machine 310. Communication between applications 220 and services of the application platform 306 may conveniently be designed according to the principles of Service-Oriented Architecture (SOA) known in the art.

[0071] Communication services 312 may allow applications 220 to communicate with the application platform 306 (through pre-defined Application Programming Interfaces (APIs) for example) and with each other (for example through a servicespecific API).

[0072] A Service registry 314 may provide visibility of the services available on the computing device 200. In addition, the service registry 314 may present service availability (e.g. status of the service) together with the related interfaces and versions. This may be used by applications 220 to discover and locate the end-points for the services they require, and to publish their own service end-point for other applications to use.

[0073] Network Information Services (NIS) 316 may provide applications 220 with low-level network information pertaining to a network service instance or one or more PDU sessions, for example. For example, the information provided by NIS 316 may be used by an application 220 to calculate and present relevant data (such as: cell-ID, location of the subscriber, cell load and throughput guidance) to session, access and policy control functions, any or all of which may themselves be implemented by applications 220 executing in respective VMs 310 or containers 311.

[0074] A Traffic Off-Load Function (TOF) service 318 may prioritize traffic, and route selected, policy-based, data streams to and from applications 220.

[0075] TCC represents the Use Case family where it requires high service reliability and bounded (typically on the order of 1 ms) latency. Such requirements must be supported at the network level (i.e. end to end (e2e) including RAN and CORE). However, at the RAN level, where it involves live RF and Over-the-Air (OTA) transmission, signal qualities are highly dependent on environmental variables (such as carrier configurations, interference and temperature, among others). Traditional channel estimation is based on UE and BPU loop and signal feedback, which is typically too slow for TCC support.

[0076] This disclosure provides methods to enable the RAN system to take fast/proactive actions to fulfill the needed reliability and bounded latency to support TCC services.

[0077] FIG. 4 is a block diagram schematically illustrating elements of an example system in which methods according to embodiments of the present disclosure may be implemented. In the example of FIG. 4 a baseband processing unit (BPU, 400), which may for example be implemented as a computing device 202 and/or one or more APPs 220 implementing, for example, a virtual BPU function in a cloud computing system, includes a baseband central processing unit (CPU_B, 402) a baseband scheduler 412, a baseband Operations and Maintenance block (OAM_B, 406) and a baseband layer 1 (L1_B, 408). Correspondingly, the radio unit (RU, 212), which may for example be implemented as a computing device 202 and/or one or more APPs 220, includes a radio central processing unit (CPU_R, 410), a radio Operations and Maintenance block (OAM_R, 412) and a radio layer 1 (L1_R, 414). The BPU 400 interacts with the RU 212 to implement the functions of a radio access node, such as a gNB in a 5G/NR network, for example. Thus, for example, the OAM_B 406 may interact with the OAM_R 412 to implement a distributed OAM functionality of the gNB, while the L1_B 408 interacts with the L1_R 414 to implement a distributed layer 1 functionality of the gNB. These interactions may be implement by way of control layer signaling between the BPU 400 ad the RU 212. Thus the present disclosure provides a “fast” control path between the RU 212 and scheduler 404, such that when the RU 212 detects a problem (such as a data glitch) which will impact an on-going TOO service, the scheduler 404 can be notified (via control signaling from the RU 212 and take appropriate action with minimum delay. Such mechanism enables the Scheduler 404 to react faster than the traditional link adaptation and data scheduling methods, which rely on slow UE CSI and HARQ feedback transmissions.

[0078] In the example of FIG. 4, only one PBU 400 is illustrated for clarity of description. However, it will be appreciated that in alternative embodiments, the RU 212 may be connected to, and interact with, more than one BPU 400 to implement methods in accordance with the present disclosure.

[0079] Also, the Scheduler 404 may inform the RU 212 of TCC service requirements to allow the RU 212 to provide the best resources (such as Symbols or resource elements (REs)) to facilitate such service.

[0080] The above capabilities enable Scheduler 404 and/or RU 212 to prioritize for the TCC services even with the price of sacrificing other services and capabilities at the given time (e.g. eMBB data and Energy efficiency measurements). Note that references herein to a RU 212 also refer to an Open-RAN RU (O-RU). 7/ C-loT Capability exchange between Scheduler 404 and RU 212

[0081] TCC capability exchange can happen at radio start up time with its built-in knowledge. As well, such TCC service support capability can also be further crystalized based on run-time radio performance environment assessments using certain TCC capability testing methods. On top, when there are any radio state change and control loop triggered actions which may impair TCC service, such capability change is also communicated to Scheduler 404 via fast path to guard the TCC service QoS.

General solution types:

2/ Early link quality predication and retransmission prediction in RU 212 and BPU 400 to improve the TCC service robustness.

[0082] Such capability can be enabled via the fast path established between the RU 212 and BPU 400. Re-transmission/Transmission prediction can be done in the gNB. In this solution the Scheduler 404 is provided with information known in the RU 212 about fault/glitch errors that are predicted either in the near future or during an ongoing air interface transmission/reception. This is done by gathering such information in a report that can be sent to the Scheduler 404. The Scheduler 404 would then combine this with other link adaptation algorithms (such as those known in the art, for example) to make more optimized scheduling decisions.

[0083] In receive mode (RX) the RU 212 monitors the signal strength and internal radio impairments, for each symbol, to identify possible problems with the signal. Results from the measurements are sent to the BPU 400. The probability of a later retransmission is calculated by Retransmission prediction 812 function and the result is sent to the Scheduler 404 to enable early retransmission requests. If the prediction is that the transmission will fail, then scheduler 404 can do a retransmission request a head of time compared with the result from the decode and CRC checks This retransmission request is then sent earlier than it would if waiting for the decode and CRC checks, but it is based on retransmission prediction, hence it may be not needed, and the transmission is redundant. If the first transmission succeeds then the second transmission is ignored, but if the retransmission prediction is correct the data is used in the decoding and latency is improved. [0084] In transmit mode (TX) the RU 212 monitors internal radio impairments for each symbol. Any identified problem is signaled to BPU 400 for planning of new transmission before the ACK/NACK is received. In other words, the system does not need to wait for HARQ ACK/NACK feedback from UE.

[0085] Scheduler 404 can do additional early checks for retransmission prediction and decide, based on the allowed latency (such as the packet delay budget “PDB”), whether or not a retransmission shall be requested and whether or not a new transmission will be planned or done.

[0086] If a glitch causing symbol distortion is predicted and informed to Scheduler 404, the Scheduler 404 can respond to avoid scheduling TCC data on the symbols (and/or resource elements) that are affected by the predicted glitch. Consequently, a more robust information data rate can be obtained and retransmission can be avoided. If an optimal (i.e. low distortion) symbol is predicted and informed to Scheduler 404, the Scheduler 404 can prioritize the predicted optimal symbol to schedule TCC data.

In some embodiments, traffic flows can be scheduled to use predicted optimal symbol(s) while other symbols are slept to improve for energy efficiency.

[0087] If multiple consecutive predictions fail for a specific time point, redundancy may be increased by utilizing more available frequency spectrum that is available for the UE location.

3/ TCC on-site near real-time capability assessment.

[0088] Such assessment can include the Scheduler 404, RU 212 and UE with the site configuration, and/or just utilizing the existing infrastructure in radio to periodically assess the radio channel quality for TCC services. The assessments may, for example, include one or more spectrum quality metrics and information regarding changes of TCC capability over time.

[0089] The methods described in this disclosure enable fast communication between the RU 212 and Scheduler 404 for both UL and DL reception and transmission. This may improve the latency and the reliability aspects for TCC services based on the existing BPU 400 and RU 212 communication mechanisms. [0090] As well such method will allow RAN to serve different types of services/traffics at a given time but provide the finer tuning capability to support TCC as a new service type.

[0091] As noted above, this disclosure mainly covers three areas. These are described in greater detail below.

1. Radio URLLC capability exchanqe with BPU

[0092] Radio TCC capability can be exchanged with BPU when radio is brought into service. In some embodiments, the TCC capability may be indicated with a granularity of a radio spectrum block and/or a symbol.

[0093] This disclosure introduces the concept of TCC friendly capabilities, which may, for example, represent radio resources that can support reliability and/or latency requirements of a given TCC service. Such capabilities are communicated between BPU 400 and RU 212 when the radio RU 212 is put into service. There are different types of TCC friendly capabilities, for example static and run-time.

[0094] There are two ways to facilitate a TCC friendly service window in which TCC services can be supported One option is by enforcing such window, for example by scheduling non-TCC traffic to time and frequency resources outside the TCC friendly service window or by preventing DPD restart and/or AGC state change events for a defined period of time corresponding to the window. Alternatively, RU 212 and BPU 400 may monitor radio links and wait for a period of time in which radio link conditions are suitable for TCC service transmissions. Depending on the types of TCC friendly capability exchange at radio start up time, and during service time, at RAN level, the BPU 400 and RU 212 are more equipped to make more agile decisions (for example for rerouting and/or rescheduling traffic, retransmitting packets, postponing service interruption recovery actions) to improve TCC QoS.

[0095] One aspect in this disclosure proposes methods to enable a “fast” control path at RAN level for TCC friendly capability exchange between RU 212 and BPU 400. a/ Static TCC friendly capability radio reports to BPU(s) upon power up.

[0096] Static TCC friendly capabilities can for example, relate to any one or more of: frequency blocks of the radio band (e.g. indicating a filter roll-off edge that should be avoided for TCC services); symbols in the time domain that are likely to be affected when a PA is activated (can be tied with a number of symbols when PA is ON or with a number of symbols starting with the first UL Sub-frame with the TDD switch patten); general recommended configured carrier power levels and some specific spots not suitable for TCC support (for example, in Multi-band FDD case, certain carrier combinations and location of carrier config are more prone to PIM attack relative to other cases).

[0097] Static TCC friendly capability exchange may not require a fast path. For example, for CAM level when the RU is powered up, it can broadcast to the registered client (e.g. one or more BPUs) information regarding its TCC friendly capabilities using conventional signaling methods. The Static TCC friendly capability exchange may also include whether the RU has the capability to support fast path communication for TCC services.

[0098] FIG. 5 is a flow chart showing a method for static TCC friendly capability radio reporting in accordance with the present disclosure. The illustrated method comprises the following steps:

[0099] Step 500: During the start-up (or re-boot) procedure of the RU 212, the RU 212 gathers static capability parameters from database entries (e.g. whether it supports the fast path channel, TCC friendly spectrum block, symbol location per Subframe and recommended power per RF Branch if TCC is serviced). Once the OAM connection (i.e. control plane signaling between OAM_R 412 and OAM_B 406) between the RU 212 and the BPU 400 is established, this connection may be used to signal the static capability parameters to the BPU 400.

[0100] Step 502: Upon receipt of the static capability parameters from the RU 212, OAM_B 406 may process the received parameters to derive RU capability indicators that are passed to the scheduler 404 for use in subsequently scheduling TCC traffic on the RAN network to optimize channels for TCC services.

[0101] Step 504: The CPU_B 402 may also process the received parameters (and or the RU capability indicators derived by the OAM_B 406) to perform any or more of:

Decisions including but not limited to NR carrier configuration for TCC service optimization; PRB level knowledge (such as, for example, identification of high reliability PRBs) that can be handed down to the scheduler 404 for use in scheduling TCC traffic. b/ Dynamic TCC friendly capability radio reports to BPU(s)

[0102] Dynamic TCC friendly capability is obtained by a TCC focused test process which may be conducted when radio is deployed on site and/or subsequently (for example in accordance with a predetermined schedule). The test process may focus on optimized spectrum blocks, for example. Preferably, TCC focused tests will collect data to detect patterns (for example relative to time) of traffic load, interference levels and other environmental variable(s) to provide a run-time TCC friendly capability evaluation and report to BPU 400. The run-time TCC friendly capability report(s) can also be provided to all registered BPUs to improve TCC QoS.

[0103] However, when the RU 212 is put into service, all of its control loops will be operating (e.g. DL Digital Predistortion and UL Automatic gain control), and certain actions will cause data glitches due to hardware nature and/or in terms of hardware protection need. Indications of these state changes will need to be communicated between the RU 212 and BPU 400 using the “fast” path to facilitate real-time TCC service optimization. In some embodiments, the fast path is provided by a User Plane (UP) communication channel established between RU 212 and BPU 400.

[0104] FIGs. 6A and 6B are flow charts showing dynamic TCC friendly capability radio reporting in accordance with the present disclosure. The example method of FIG. 6A comprises the following steps:

[0105] Step 600: During in-service operation of the RU 212, the L1_R 414 control loops (e.g. Digital Predistortion and Automatic gain control for example) are in operation. When a state change or glitch is detected or predicted, the CPU_R may operate to postpone any actions of the RU 212 which may impact TCC services, and inform BPU 400 using fast path signaling, for example between the L1_R 414 and the L1_B 408. For example, a change in the power supplied to a power amplifier, for example when entering or exiting a “sleep mode”, can produce a data glitch. Such a power level change may be deferred while information of the predicted data glitch is sent to the RU 212. In some embodiments, information regarding glitches and/or state changes in the L1_R 414 may be signaled directly to the L1_B 408. In other embodiments, information of at least some state changes (for example predicted state changes) may be signaled between the OAM_R 412 and the OAM_B 406.

[0106] Step 602: Upon receipt of the fast path signaling from the RU 212, L1_B 408 and/or OAM_B 406 may notify the scheduler 404.

[0107] Step 604: Based on the information received from the L1_B 408 and/or OAM_B 406, the scheduler can take appropriate action to preserve TCC QoS. For example, TCC traffic can be redirected to a radio channel that is not affected by the predicted glitch, or TCC traffic may be repeated to improve reliability.

[0108] The example method of FIG. 6B comprises the following steps:

[0109] Step 606: During in-service operation of the RU 212, the OAM_R 412 and/or the CPU_R 410 may execute a test cycle to determine TCC capability parameters. These capability parameters may be signaled to the BPU 400 via the connection between the OAM_R 412 and OAM_B 406.

[0110] Step 608: Upon receipt of the static capability parameters from the RU 212, OAM_B 406 may process the received parameters to derive updated RU capability indicators that are passed to the scheduler 404 for use in subsequently scheduling TCC traffic. For example, this may include determining suitable freq, blocks and/or symbols within per sub-frame in time domain, optimal Tx power levels, UL interference levels and recommended window for best TCC service at the site.

[0111] Step 610: The CPU_B 402 may also process the received updated parameters (and or the updated RU capability indicators derived by the OAM_B 406) to perform any or more of:

• Influence TCC service enabled NR carrier config;

• Influence Scheduler 404 for better TCC service. c/ TCC service notification from Scheduler 404 to radio

[0112] TCC service notification can be in a static fashion and/or dynamic fashion. In more details, at gNB start up time (radio and BPUs are connected and start TCC friendly capability exchange using OAM layer signaling), the NR carriers which BPU intends to use for TCC service can be tagged when carrier is configured/activated.

[0113] Also, at run time, within the cadence at the slot level, the TCC related symbols can be labelled and informed to radio. Such real-time capability will enable the real-time better handling of the TCC data at the radio level. For example, radio can postpone certain actions which may impact the TCC service at a given time.

Alternatively, the RU can guard the TCC service with reduced performance for other types of traffic, if needed (e.g. to optimize SNR of the TCC services while reducing SNR of other services).

[0114] FIGs. 7A and 7B are flow charts respectively showing methods for static and dynamic TCC service notification in accordance with the present disclosure.

[0115] The example method of FIG. 7A comprises the following steps:

[0116] Step 700: During carrier configuration, the BPU 400 shall inform radio with the configured NR carriers on which TCC services will be provided, via signaling between the OAM_B 406 and the OAM_R 412.

[0117] Step 702: Upon receiving the configured carrier information from the BPU 400, the RU 212 can use dedicated physical channels to provide the TCC service on the configured carriers.

[0118] Step 704: Scheduler 404 configures/prep the most TCC friendly Physical path for the best QoS.

[0119] The example method of FIG. 7B comprises the following steps:

[0120] Step 706: Scheduler 404 marks TCC traffic and interacts with L1_B 408 to perform the DL signal marking to enable appropriate identification and handling of the TTC traffic by other layers.

[0121] Step 708: Upon identifying marked TCC traffic, L1_R 414 can protect the data stream traversing the radio channel, for example by avoiding over clipping, power backoff and/or any zero insertions. [0122] Step 710: The RU 212 digital front end (DFE) operates to avoid any service interruption when TCC services are served - e.g avoid zero insertion and other local recover actions.

2. Radio re-transmission prediction

[0123] Referring to FIG. 8A, in receive (RX) mode the RU 212 radio RX chain 800 receives uplink transport blocks from a UE (not shown) and passes the received transport block to the BPU 400 for channel decoding and Cyclic Redundancy Check (CRC) 802. In normal operation, the CRC 802 generates a CRC result 804 that is passed to the Scheduler 404, which in turn produces an ACK/NACK result 806 that is transmitted back to the UE in Downlink Control Information/Physical Downlink Control Channel (DCI/PDCCH) via the radio transmit (TX) chain 808.

[0124] In some embodiments of the present disclosure, the RU 212 monitors (at 810) the radio link quality detected by the radio RX chain 800 and reports the results to a retransmission prediction block 812. For example, the radio link quality detected by the radio RX chain 800 may be based on signal strength measurements i.e. , weak signal or too strong signal (blocker) or other impairments introduced by RU 212 i.e., calibration functions or fast temperature changes or similar. The BPU 400 may also supply internal quality measures 814 to the retransmission prediction block 812. For example, the internal quality measures 804 may be derived from historical CRC results 804 generated from previously received transmission blocks.

[0125] Based on the radio link quality reports from the RU 212 and internal quality measures 814, the retransmission prediction block 812 generates a retransmission prediction result indicative of a likelihood that the current transmission block (that is, the transmission block currently being received) will fail the decoding and CRC 802

[0126] When CRC failure is predicted, the scheduler 404 can preemptively send a NACK 806 to request retransmission of the transport block, before the affected received transport block is decoded and the cyclic redundancy check result is calculated. As a result, the retransmission can be requested before the transport block has been completely received by the radio RX chain 800. In some embodiments, the BPU 400 can cause the current transport block (that is predicted to fail decoding and/or CRC) to be discarded without performing the decoding and CRC steps, thereby minimizing both the delay and resources needed to receive and process a corrupted transport block.

[0127] Retransmission prediction can also be combined with known information in the RU 212 that some upcoming (i.e. not yet received) symbols will become degraded. For example, where the transmission duration is a full slot (i.e. 14 symbols) and already after X symbols (X<14) it can be predicted that the first X symbols have so poor quality and/or that the upcoming 14-X symbols will likely have poor quality (or the combination of these) with a high probability would lead to a decoding error. If this happens this could immediately be reported to the Scheduler 404 that then based on this information decides to provide the UE with a new UL grant at the next possible PDCCH occasion. The re-transmission prediction result could either be a simple binary yes/no but also a more elaborate measure like a probability value that could be used to make different decisions based on different thresholds.

[0128] For example, if a value of 99.99% is estimated the Scheduler 404 could even take a decision to stop the ongoing channel decoding and issue a NACK to request re-transmission. Another example could be if the re-transmission prediction result is reported after every symbol (during a transmission duration of e.g. one slot) with a probability value the Scheduler 404 may wait and monitor/evaluate the results until a certain threshold is reached before a first decision is made (e.g. to issue a NACK to request re-transmission if the resource situation allows and there is DL PDCCH transmission opportunity available) and then at a later time (i.e. some symbols later) makes a second decision (e.g. to stop decoding processing if the probability became very high or reverting the first decision if probability became low and it is still time to stop the re-transmission request to be sent to the UE).

[0129] FIG. 8B illustrates an alternative RX mode operation. In the example of FIG. 8B, the RU 212 radio RX chain 800 receives Physical Uplink Shared Channel (PUSCH) from a UE (not shown) and passes the received PUSCH to the BPU 400 for channel decoding and Cyclic Redundancy Check (CRC) 802. In normal operation, the CRC 802 generates a CRC result 804 that is passed to the Scheduler 404, which in turn produces an ACK/NACK result 806 that is transmitted back to the UE in Downlink Control Information/Physical Downlink Control Channel (DCI/PDCCH) via the radio transmit (TX) chain 808. [0130] In some embodiments of the present disclosure, the RU 212 monitors (at 810) the radio link quality detected by the radio RX chain 800 and reports the results to a retransmission prediction block 812. For example, the radio link quality detected by the radio RX chain 800 may be based on signal strength measurements i.e. , weak signal or too strong signal (blocker) or other impairments introduced by RU 212 i.e., calibration functions or fast temperature changes or similar. The BPU 400 may also supply internal quality measures 814 to the retransmission prediction block 812. For example, the internal quality measures 804 may be derived from historical CRC results 804 generated from previously received transmission blocks.

[0131] Based on the radio link quality reports from the RU 212 and internal quality measures 814, the retransmission prediction block 812 generates a retransmission prediction result indicative of a likelihood that the current transmission block (that is, the transmission block currently being received) will fail the decoding and CRC 802.

[0132] When CRC failure is predicted to be likely (for example, when the retransmission prediction result is equal to or greater than a predetermined threshold), a (re)transmission selection block 816 can preemptively trigger a NACK 806 to request retransmission of the transport block, before the affected received transport block is decoded and the cyclic redundancy check result is calculated. As a result, the retransmission can be requested before the transport block has been completely received by the radio RX chain 800. In some embodiments, the BPU 400 can cause the current transport block (that is predicted to fail decoding and/or CRC) to be terminated or discarded without performing the decoding and CRC steps, thereby minimizing both the delay and resources needed to receive and process a corrupted transport block.

[0133] Retransmission prediction can also be combined with known information in the RU 212 that some upcoming (i.e. not yet received) symbols will become degraded. For example, where the transmission duration is a full slot (i.e. 14 symbols) and already after X symbols (X<14) it can be predicted that the first X symbols have so poor quality and/or that the upcoming 14-X symbols will likely have poor quality (or the combination of these) with a high probability would lead to a decoding error. If this happens this could immediately be reported to the Scheduler 404 that then based on this information decides to provide the UE with a new UL grant at the next possible PDCCH occasion. The re-transmission prediction result could either be a simple binary yes/no but also a more elaborate measure like a probability value that could be used to make different decisions based on different thresholds.

[0134] For example, if a value of 99.99% is estimated the (re)transmission selection block 816 could even take a decision to stop the ongoing channel decoding and issue a NACK to request re-transmission. Another example could be if the retransmission prediction result is reported after every symbol (during a transmission duration of e.g. one slot) with a probability value the (re)transmission selection block 816 may wait and monitor/evaluate the results until a certain threshold is reached before a first decision is made (e.g. to issue a NACK to request re-transmission if the resource situation allows and there is PDCCH transmission opportunity available) and then at a later time (i.e. some symbols later) makes a second decision (e.g. to stop decoding processing if the probability became very high or reverting the first decision if probability became low and it is still time to stop the re-transmission request to be sent to the UE).

[0135] Referring to FIG. 9A, in transmit mode (TX) the RU 212 monitors (at 810) radio internal disturbances (e.g. glitches generated in the radio Tx chain 808) and reports detected disturbances to the retransmission prediction block 812. The BPU 400 may add baseband quality measures 900 to the retransmission prediction block 812. Baseband quality measures 900 may, for example, include channel quality information derived from previous HARQ feedback and/or CQI information reported by UEs. The re-transmission prediction block 812 informs the Scheduler 404 about the retransmission prediction result. In case a re-transmission is predicted, then a pro-active re-transmission can be issued before the HARQ feedback is received from the UE. In some embodiments, the feedback may include NACK or DTX on the control channel (i.e. PUCCH or PUSCH in 3GPP based systems like LTE and NR).

[0136] FIG. 9B illustrates an alternative TX mode operation. In the example of FIG. 9B the RU 212 monitors (at 810) radio internal disturbances (e.g. glitches generated in the radio Tx chain 808) and reports detected disturbances to the retransmission prediction block 812. The BPU 400 may add baseband quality measures 900 to the retransmission prediction block 812. Baseband quality measures 900 may, for example, include channel quality information derived from previous HARQ feedback and/or CQI information reported by UEs. The re-transmission prediction block 812 informs the (re)transmission selection block 816 about the retransmission prediction result. In case a re-transmission is predicted, then a pro-active re-transmission can be issued before the HARQ feedback is received from the UE. In some embodiments, the HARQ feedback may include a NACK result or a DTX on the control channel (i.e. PUCCH or PUSCH in 3GPP based systems like LTE and NR).

[0137] Similar mechanisms as described above for the Receive mode applies also here. This could lower the latency of the data transmission in the system as the HARQ feedback is usually sent much later. As an example, assume an NR TDD system using the 8+2/DDDDDDDSUU pattern (or 4+2+4/DDDSUUDDDD) with 30kHz sub-carrier spacing (these are the two most used TDD deployments in FR1 frequency bands that also have LTE deployed). If a DL transmission takes place in the first slot (or just after the last UL slot) then the HARQ feedback would not be received until 8 slots later and the re-transmission could be sent earliest 10 slots after the first transmission. Thus, this is 5 ms later so if a re-transmission could be predicted with a high probability already during the slot of the first transmission and a pro-active HARQ re-transmission could transmitted already in the first or second slot after the after the first transmission a latency gain of 4- 5 ms could be achieved (if the first transmission failed to be decoded by the peer device).

[0138] FDD and TDD may have differences, but the concept is similar for both FDD and TDD. The scheduler 404 needs to handle the requests depending on the mode.

[0139] If the Scheduler 404 gets information about possible upcoming disturbances in the RU 212 prior to starting the transmission, then additional redundancy can be added already for the initial transmission if processing time allows prior to:

• start of the first symbol of the data transmission (in the transmit mode) or

• start of the first symbol of the control message (grant) transmission (in the receive mode)

[0140] The actual placement of the re-transmission prediction block 812 can be placed in either the BPU 400 or in the RU 212.

[0141] Radio TCC capability report (including data glitch reporting using fast path) and BPU 400 reaction to provide better TCC services. The capability report shall report potential faults/glitch errors for both RX and TX chain. The report could be either periodically or event based, sending from radio to baseband. When the error report is received before the actual scheduling performed, potentially it can be taken into account in the scheduling decision. For example, in reception of a report about transmission antenna branch failure, which will occur at a potential MIMO transmission, scheduling can change the decision from two layer to one layer transmission; if an antenna branch failure occurs for a scheduling decision of transmission multiplexing, potentially scheduling can select the MCS corresponding to half of the transmission power. When the error report is received after the scheduling decision is made, early retransmission can be scheduled before the actual HARQ decoding feedback is received.

Cloud and O-RAN Implementation

[0142] Cloud based RAN (Including Open RAN) implementation and the intelligent automation platform service management and orchestration (SMO) on top of it results in a wide range of flexible deployment options, including network slicing.

[0143] Time Critical Communication (TCC) is an application which requires support from RAN network with management and automation capabilities which are challenging for a legacy purpose-built network. SMO, together with customized application(s) for network automation, enables the optimization of RAN deployment for TCC with bounded latency and reliability. TCC with bounded latency and reliability may also be referred to as Critical loT (C-loT) and/or URLLC described above and in the 3GPP standards.

[0144] In particular, information collected over time from cell/radio site (e.g. occasional RF component malfunctioning) can be fed to an Artificial Intelligence/Machine Learning (AI/ML) capable near-Real Time (near-RT) RAN Intelligent controller (RIC) and/or SMO application for optimizing the network configuration such that network slicing for C-loT service is deployed accordingly.

[0145] RU service interruption collection and handling - There are several ways which radio fault information can be collected, analyzed and used to optimize the overall performance including reliability and latency. [0146] Method 1 : RU (including O-RU) service interruption info is collected at Open RAN Distributed Unit (O-DU). This enables the fastest reaction from the scheduler (which is part of BPU 400 in O-DU). The limitation is service interruption information from only a few radios can be collected and the decision is more localized. This method refers to RU service interruption information path a in FIG. 10.

[0147] Method 2: RU service interruption info is collected and cascaded through DU(3GPP defined Distributed Unit which contains O-DU and O-RU) to CU(3GPP defined Centralized Unit) and to near-RT RIC(Near Real-Time RAN Intelligence controller). The main benefit of collecting RU service interruption information in this proposed way is to collect RU service interruption information from a larger scale (e.g. larger number of radios). On the other hand, AI/ML capability in near-RT RIC can handle RU service interruption information collected over larger scale and time to optimize Radio Resource Management (RRM) decision. Comparing with Method 1 , the reaction from near-RT RIC is at a slower pace but at larger scale. This is beneficial for the scenarios that RAN need to be optimized (for a static RAN) or steered (for dynamic RAN) towards certain specific performance requirements, e.g. more or less C-loT devices need to be served. This method refers to RU service interruption information path and y in FIG. 10.

[0148] Method 3: Similar to Method 2, RU service interruption info is collected at near-RT RIC through E2-like interface. This method refers to RU service interruption information path 8 in FIG. 10. Such way can speed up the information propagation.

[0149] Method 4: Similar to method 2, RU service Interruption info is collected at SMO/non-RT RIC through 01 -like interface. This method refers to RU service interruption information path e in FIG. 10.

[0150] Other than providing a fast path to enable quicker/more robust C-loT service. These proposed methods can be used to cascade the C-loT service interruptions at different levels(CUZDU) and pass to the next level in the RAN network hierarchy for further AI/ML analysis.

[0151] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is representative, and that alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.

[0152] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.