Method, controller and computer program for scheduling data transmissions in radio access network

Abstract

A method, controller and computer program for scheduling data transmissions in a radio access network. A method of scheduling data transmissions in a radio access network is provided. The radio access network comprises a scheduler configured to orchestrate transmission of data between one or more base stations and a plurality of user equipments (UEs) according to a set of instructions. The method includes receiving real-time network usage data. The method further includes dynamically modifying the instruction set based on the network usage data. The method further includes implementing the modified set of instructions such that the scheduler is configured to orchestrate transmission of data between the one or more base stations and the plurality of UEs according to the modified set of instructions.

Description

TECHNICAL FIELD

[0001] The present invention relates to scheduling in a radio access network. In particular, the present invention relates to modification of L1 scheduling based on network usage data and / or conditions.

[0002] Glossary

[0003] RAN - Radio Access Network

[0004] MNO - Mobile Network Operator

[0005] GPU - Graphics Processing Unit

[0006] O-RAN - Open RAN Alliance

[0007] O-DU - Open Distributed Unit

[0008] O-CU - Open Central Unit

[0009] O-RU - Open Radio Unit

[0010] PHY - Physical Layer (L1)

[0011] MAC - Medium Access Control (L2)

[0012] RLC - Radio Link Control (L2)

[0013] PDCP - Packet Data Convergence Protocol (L3)

[0014] RRC - Radio Resource Control (L3)

[0015] SDAP - Service Data Adaptation Protocol

[0016] OS - Operating System

[0017] API - Application Programming Interface

[0018] SMO - Service Management and Orchestration

[0019] DMS - Deployment Management Service

[0020] NF - Network Function

[0021] IMS - Infrastructure Management Service

[0022] QoS - Quality of Service

[0023] PDCCH - Physical Downlink Control Channel

[0024] DCI - Downlink Control Information

[0025] PDSCH - Physical Data Shared Channel

[0026] ARQ - Automatic Repeat reQuest

[0027] HARQ - Hybrid ARQ PUSCH - Physical Uplink Shared Channel SLIV - Start and Length Indicator Value ARP - Allocation and Retention Priority RQA - Reflective QoS Attribute near RT RIC - Near-Real-Time RAN Intelligent Controller ISAC - Integrated Sensing and Communication RF - Radio Frequency RIS - Reconfigurable Intelligent Surface CUDA - Compute Unified Device Architecture AI - Artificial Intelligence ML - Machine Learning CPU - Central Processing Unit CU - Centralized Unit DU - Distributed Unit MNO - Mobile Network Operator RRH - Remote Radio Head APU - Antenna Processing Unit CF-mMIMO - Cell-Free Massive Multiple-Input Multiple-Output RIC - Radio Interface Controller or RAN Intelligent Controller SI - Scheduler Instruction CaaS - Containers as a Service SW - Software HW - Hardware COTS - Commercial Off-The-Shelf UE - User Equipment BS - Base Station ABS - Advanced Base Station BTS - Base Transceiver Station BSS - Basic Service Set ESS - Extended Service Set AP - Access Point

[0028] NB - Node B (Radio Base Station Receiver)

[0029] eNB - Evolved Node B

[0030] gNB - Next Generation Node B

[0031] TRP - Transmission and Reception Point

[0032] PS - Processing Server

[0033] TE - Terminal Equipment

[0034] MS - Mobile Station

[0035] MT - Mobile Terminal

[0036] UT - User Terminal

[0037] SS - Subscriber Station

[0038] PDA - Personal Digital Assistant

[0039] CDMA - Code Division Multiple Access

[0040] FDMA - Frequency Division Multiple Access

[0041] TDMA - Time Division Multiple Access

[0042] OFDMA - Orthogonal Frequency Division Multiple Access

[0043] SC-FDMA - Single-Carrier Frequency Division Multiple Access

[0044] MC-FDMA - Multi-Carrier Frequency Division Multiple Access

[0045] UTRA - Universal Terrestrial Radio Access

[0046] GSM - Global System for Mobile Communications (2G)

[0047] GSMA - GSM Association

[0048] GPRS - General Packet Radio Service

[0049] EDGE - Enhanced Data rates for GSM Evolution

[0050] IEEE - Institute of Electrical and Electronics Engineers

[0051] E-UTRA - Evolved UTRA

[0052] UMTS - Universal Mobile Telecommunications System (3G)

[0053] E-UMTS - Evolved UMTS

[0054] 3GPP - 3rd Generation Partnership Project

[0055] DL - Downlink

[0056] UL - Uplink

[0057] LTE - Long Term Evolution (4G)

[0058] LTE-A - LTE Advanced

[0059] NR - New Radio (5G)

[0060] FDD - Frequency Division Duplex

[0061] TDD - Time Division Duplex

[0062] CRS - Cell-specific Reference Signal

[0063] CSI-RS - Channel State Information Reference Signal

[0064] FPGA - Field Programmable Gate Array

[0065] ASIC - Application-Specific Integrated Circuit

[0066] DSP - Digital Signal Processor

[0067] CD-ROM - Compact Disc Read Only Memory

[0068] DVD-ROM - Digital Versatile Disc Read Only Memory

[0069] ROM - read only memory

[0070] RAM - random access memory

[0071] EEPROM - electrically erasable programmable read only memory

[0072] EPROM - erasable programmable read only memory BACKGROUND

[0073] Scheduling in a radio access network is the process of allocating radio resources for transmission of data. In most prior art use cases, scheduling is decided by the network. UEs connected via the network have to comply with the scheduling set by the network. Developments in radio access network technology have introduced methods for feeding data back to the network that can be used to improve scheduling.

[0074] Open RAN is a technical architecture concept targeting the decoupling of hardware and software components of a radio access network (RAN). It is a RAN that includes open, interoperable interfaces and virtualization. In prior art (non-open) RANs, hardware and software components are typically proprietary. Non-open RAN equipment is typically obtained from a single vendor to ensure seamless functionality, security, and efficiency. In contrast, open RAN introduces open standards for both hardware and software, thereby enabling interoperability between various network elements. For mobile network operators (MNOs), open RAN is strategically important as it promotes vendor diversity, allowing the integration of new vendors and enhancing supply chain flexibility. It also brings energy efficiency gains by enabling targeted improvements in specific areas of the RAN. Furthermore, open RAN promotes innovation and competition by providing a more dynamic and efficient network environment. In addition, it offers opportunities for collaboration with specialist vendors and promotes resource optimization by allowing software upgrades without the need for hardware replacement. Open RAN is important in MNOs’ long-term network innovation strategy, providing energy efficiency, supply chain diversity, flexibility enhancement, and promoting innovation and competition.

[0075] Figure 1 Figures illustrate some of the elements of an example open RAN system 100, which is implemented as a cloud computing platform (O-Cloud). The system 100 can be described with reference to different hardware and software layers of the platform.

[0076] At the O-Cloud node tier 110, the system includes one or more physical infrastructure nodes 120A, 120N that satisfy O-RAN requirements. Each physical infrastructure node 120A includes compute 121, networking 122, GPU 123, and storage 124 components, as well as acceleration technologies 125 for RAN operations such as forward error correction and other compute-intensive operations that are offloaded to specialized hardware. Each physical infrastructure node 120A, 120N is configured to host related O-RAN network functions 150, 160 implemented at the open RAN application tier 140. The network functions 150, 160 implemented at the open RAN application tier 140 can include O-CU 160, O-DU 150, and O-RU.

[0077] O-CU, O-DU, and O-RU network function deployments include functional elements for processing different protocols in the RAN protocol stack. The O-DU 150 includes:

[0078] • a high PHY component 151 for performing scrambling, modulation, layer mapping, precoding, resource element mapping, and I / Q compression elements of the PHY layer;

[0079] • a MAC component 152; and

[0080] • an RLC component 153.

[0081] The O-CU includes:

[0082] • a PDCP component 161; and

[0083] • an RRC / SDAP component 162.

[0084] The O-DU 150 can further include an open RAN fronthaul interface for connecting the O-DU to one or more O-RUs.

[0085] At the O-Cloud hypervisor or container / OS tier 130, there is a collection of cloud functions to enable the open RAN applications 150, 160 to run on one or more O-Cloud hardware nodes 120A. The cloud functions can include supporting software components such as operating systems, containers (self-contained executable software packages), container orchestration platforms such as Kubernetes, container runtimes, and the like. The cloud functions can also include corresponding management and orchestration functions.

[0086] O-Cloud serves as a fundamental component for facilitating cloud computing capabilities in the context of RAN network functions. It includes both hardware elements and software elements. In particular, its software exposes an open API, thereby facilitating interoperability and flexibility across various vendor solutions. With a decoupled architecture, O-Cloud allows hardware to be procured from different vendors, thereby facilitating neutrality and flexibility in hardware selection. It supports service management and orchestration (SMO), thereby enabling home decisions and selecting deployment management services (DMS) for network function (NF) deployment. DMS handles workload placement, lifecycle management, and resource allocation within an O-Cloud node cluster, while an infrastructure management service (IMS) ensures availability, reliability, and performance of the infrastructure. In addition, O-Cloud provides automation capabilities, thereby improving efficiency and reducing human intervention, ultimately supporting efficient resource utilization and scalability of RAN network functions in a cloud-native environment.

[0087] Layer 1 (LI) scheduling in hardware platforms of open RAN systems is typically completely static and fixed. In standard scheduling, a fixed frame slot is provided during which queued tasks must be completed. Any uncompleted tasks must be discarded or postponed until the next available frame slot.

[0088] Existing methods bind scheduling tasks completely within the execution parameters of frame slots, without regard to available resources and performance capabilities of the platform. This provides a limited performance response that cannot adapt to rapidly changing demands of the environment. In some cases, this can result in disruption of operations due to system crashes, or can limit the performance of the system due to underutilized available resources. This can also limit on-demand services of ULLRC applications, such as gaming, facial recognition (e.g., at airports), surgical operations, and the like. Services can be limited to a limited time period, especially for 6G speed and latency requirements.

[0089] Furthermore, static and fixed LI scheduling parameters are currently set manually by engineers to ensure that tasks fit within frame slots and do not cause buffer overflows or other issues. There is currently no available method to determine parameters to customize scheduling for a particular chipset, environment, and traffic patterns. Current LI scheduling prior art only provides static LI scheduling similar to a black box. SUMMARY

[0090] A method for data transmission in a radio access network is provided. The radio access network includes a scheduler configured to orchestrate the transmission of data between one or more base stations and multiple user equipment (UEs) according to a set of instructions. The method includes receiving real-time network usage data and / or network status data. The method further includes dynamically modifying the instruction set based on the network usage data. The method further includes implementing the modified instruction set such that the scheduler is configured to orchestrate the transmission of data between one or more base stations and multiple UEs according to the modified instruction set, wherein the instruction set includes one or more parameters relating to constraints on target hardware.

[0091] The aforementioned problems are addressed by providing a continuously updated schedule, updated in near real-time. This allows scheduling parameters to be available at fixed locations, and continuous changes to these parameters enable dynamic scheduling. Environmental changes (such as traffic density, mobility direction, and aggregation speed) will cause dynamic changes in the schedule to adapt to the changing environment. The target hardware refers to the hardware used in data transmission between one or more base stations and multiple user equipment (UEs).

[0092] The scheduler can be configured to allocate physical layer (L1) resources.

[0093] The scheduler can be configured to coordinate data transmission on both the downlink and uplink.

[0094] A scheduler can be provided in the MAC layer (L2).

[0095] The method of data transmission can be either a method of scheduling data transmission or a method of controlling data transmission.

[0096] Existing methods involve scheduling resources based on channel quality measurements between each UE and the base station, the data buffer status of each UE (downstream and upstream), the QoS requirements of each UE, and the like. However, the basic scheduling parameters (which apply to all UEs) are typically static and fixed. These parameters are not adjusted in response to changing network demands or changing radio conditions.

[0097] In contrast, the proposed method provides the network with the ability to dynamically (during runtime) modify the schedule. Schedule modifications can be based on multiple factors, including changes in the environment, utilization of radio resources, radio conditions, and the like.

[0098] L1 components are among the most power-intensive components in the radio access network. Therefore, improving L1 scheduling can significantly improve RAN efficiency.

[0099] In 5G, Pre-6G, 6G, and higher, there is (or is predicted) an increasing demand for large amounts of processing and radio resources available (with low latency) within short timeframes. Current scheduling methods always provide a static amount of resources. The proposed method is able to respond quickly to requests for increased capacity and thus better serve the changing needs of subscribers.

[0100] In some examples, the scheduler can switch between static scheduling methods (according to existing technology) and dynamic scheduling (according to the proposed method).

[0101] Network usage data may include data indicating the status of one or more radio channels, such as radio channel conditions (noise, interference, attenuation, etc.).

[0102] Network usage data can include network demand information, such as the number of subscribers, traffic density, and the like.

[0103] Network usage data can also include forecast data that indicates future demand on the network. For example, demand forecasts could be based on the number of people identified by surveillance cameras in a specific area (or facing a specific area).

[0104] The data transmitted between one or more base stations and multiple UEs can be user data (i.e., application data).

[0105] In the context of this disclosure relating to “real-time” network usage data, this could be low-latency data that can take effect immediately in a closed-loop feedback system.

[0106] Modifying the instruction set can include defining a time period during which the scheduler modifies the instruction set.

[0107] The method may further include reverting to the previous schedule (i.e., before the modification) after the time period has elapsed.

[0108] Modifying the instruction set may further include defining a time window, during which a period of time during which the scheduler implements the modification of the instruction set is a part of the time window.

[0109] The window for defining time may include setting a start flag and a stop flag. Alternatively, the window for defining time may include setting a start flag and the number of frame slots.

[0110] The time window can be defined by xApp on the near-RT RIC, which can determine the required timing window based on network usage data. For example, if the default scheduling is designed for 5 people passing through a given area every 20 seconds (e.g., passport control), sensing 20 people in the given area can be addressed by increasing capacity by 4 times over the 20-second period. If more people are subsequently detected (e.g., because a flight has just arrived), xApp on the RIC can determine that more capacity is needed and increase capacity by 5 or 6 times over a longer period (e.g., 5 minutes).

[0111] When setting up a window for a modified instruction, the controller (e.g., RIC) can check for conflicts to ensure that the modified schedule does not cause the app to conflict on a time slot.

[0112] The method may further include preparing the modified instruction set for implementation during an initial time period after the start flag and before the time period during which the scheduler implements the modified instruction set.

[0113] The initial time slot can be used to fine-tune the default operation schedule until a new schedule is implemented. For example, it can be used to schedule idle time slots that will be used by the modified schedule.

[0114] Similarly, after the current time period has passed and during the final time period before the stop flag, the scheduler can prepare to implement the next schedule (e.g., the original default schedule or a newly modified schedule).

[0115] During the initial time period and / or when the scheduling of the modified instructions takes effect, tasks for other UEs (which do not require enhanced capacity) can be compressed to fill smaller time slots. This frees up frame time slots for tasks of UEs that require enhanced capacity.

[0116] During the initial time period and / or when the modified instructions take effect, tasks can follow different time sequences based on network data usage to meet network needs.

[0117] The instruction set may include one or more parameters (e.g., multiple parameters), including one or more of the following:

[0118] Subcarrier offset;

[0119] Subcarrier spacing;

[0120] Symbol duration;

[0121] Time slot format;

[0122] Time-domain allocation k0 for downlink data transmission;

[0123] Ack / Nack timing information k1;

[0124] Time-domain allocation k2 is used for uplink data transmission;

[0125] Start and length indicator values ​​SLIV;

[0126] The minimum time duration N1 required from decoding the physical downlink control channel PDCCH to receiving the physical data sharing channel PDSCH;

[0127] The minimum time duration N2 required from decoding the physical downlink control channel PDCCH to transmitting the physical uplink shared channel PUSCH;

[0128] Waiting time;

[0129] Response time;

[0130] Turnover time;

[0131] Buffer size;

[0132] Block size;

[0133] 5G Quality of Service (QoS) identifier;

[0134] Assign and retain priority ARPs;

[0135] Reflecting QoS attribute RQA;

[0136] One or more scheduling weights;

[0137] One or more admission thresholds; and

[0138] One or more queue management thresholds.

[0139] Downlink control information (DCI) can be carried via the physical downlink control channel (PDCCH).

[0140] Downlink data can be transmitted via the Physical Data Sharing Channel (PDSCH). Uplink data can be transmitted via the Physical Uplink Sharing Channel (PUSCH).

[0141] The time domain allocation (k0) used for downlink data transmission can be the number of time slots between PDCCH / DCI and PDSCH.

[0142] The Ack / Nack timing information (k1) can be the number of time slots between PDSCH and HARQ Ack / Nack transmissions.

[0143] The time domain allocation (k0) used for uplink data transmission can be the number of time slots between the PDCCH / DCI and the uplink data transmission.

[0144] The Start and Length Indicator Value (SLIV) can include the start symbol and the length of the symbol for scheduling in a specific time slot used for PDSCH and / or PUSCH.

[0145] One or more parameters related to constraints on the target hardware may include:

[0146] 5G constraints;

[0147] Subcarrier offset;

[0148] Subcarrier spacing;

[0149] Symbol duration;

[0150] Time slot format;

[0151] Time-domain allocation k0 for downlink data transmission;

[0152] Ack / Nack timing information k1;

[0153] Time-domain allocation k2 is used for uplink data transmission;

[0154] Start and length indicator values ​​SLIV;

[0155] The minimum time duration N1 required from decoding the physical downlink control channel PDCCH to receiving the physical data sharing channel PDSCH;

[0156] The minimum time duration N2 required from decoding the physical downlink control channel PDCCH to transmitting the physical uplink shared channel PUSCH;

[0157] Buffer size; and

[0158] Block size.

[0159] The method may further include storing the updated instruction set in the scheduler's persistent storage location.

[0160] The persistent storage location can be a file stored at a fixed file location on the scheduler.

[0161] A RAN can be an open RAN that includes one or more network function deployments.

[0162] One or more network function deployments may include an Open Distributed Unit (O-DU).

[0163] O-DU may include a scheduler.

[0164] The open RAN may further include a controller configured to perform the steps of receiving real-time network usage data and dynamically modifying the instruction set based on the network usage data.

[0165] The controller can be a near real-time RAN intelligent controller, i.e., a near-RT RIC.

[0166] The RAN Intelligent Controller (RIC) can be a software-defined component of an Open Radio Access Network (Open RAN) that is responsible for controlling and tuning RAN functions.

[0167] RIC can facilitate third-party applications for automating and tuning RAN operations.

[0168] RIC can be configured to enable personalized services, network slicing, traffic redirection, beamforming, and indoor location tracking capabilities.

[0169] RICs can include near-real-time RICs (near-RTRICs) and non-real-time RICs (non-RT RICs).

[0170] A non-RT RIC can be an element of the SMO framework. A non-RT RIC can host one or more applications called rApps. In some examples, a non-RT RIC can be used to implement control over RAN elements and their resources with a response time of 1 second or longer.

[0171] Non-RT RICs can use network data, performance metrics, and subscriber data as input to their AI models. Non-RT RICs can then leverage these AI models for network tuning and policy guidance.

[0172] Near-RT RICs can reside within telecom edge clouds or regional clouds. Near-RT RICs can be responsible for intelligent edge control of RAN nodes and resources. Near-RT RICs can host one or more applications called xApps. Near-RT RICs can provide policy feedback to non-RTRICs. In some examples, near-RTRICs can be used to control RAN elements and their resources with a response time of 1 second or less. Preferably, near-RT RICs can be used to control RAN elements and their resources with a response time of approximately 10 milliseconds.

[0173] Network usage data can indicate changes in the environment, including one or more of the following:

[0174] Number of subscribers

[0175] Flow density,

[0176] The direction of subscriber mobility

[0177] Maximum subscriber mobility

[0178] Minimum subscriber mobility

[0179] The speed of gathering

[0180] Interference measurement

[0181] Signal strength,

[0182] Downlink latency

[0183] Uplink latency, and

[0184] Power saving mode.

[0185] In this document, "traffic" can refer to data exchanged via an access network. "Traffic density" can refer to the data rate of network traffic.

[0186] User mobility can include the geographical movement of individual UEs and / or the overall geographical movement of groups of UEs.

[0187] The speed of aggregation can include the geographical dispersion (or convergence) of subscribers.

[0188] The method according to any of the preceding claims, wherein the network usage data includes data from the Integrated Sensing and Communication (ISAC) platform.

[0189] The ISAC platform can include multiple environmental sensors. The ISAC platform can be configured to facilitate communication via one or more of the following: beamforming using MIMO arrays; AI model creation and training; and modulation scheme adaptation.

[0190] The proposed approach enables networks to respond quickly to changing needs of their subscribers. Examples include smart factories, health monitoring, intelligent traffic monitoring, intruder detection, privacy protection, and / or target localization.

[0191] The sensing and communication aspects of the ISAC platform can each include common elements, such as:

[0192] Beamforming; and

[0193] Phased antenna array.

[0194] The ISAC platform can further include channel estimation, symbol detection, and object detection capabilities, which are provided by common hardware.

[0195] The ISAC platform may include sensors for monitoring wireless networks, as well as other inputs (such as cameras, which can be used to identify and count people) for measuring relevant parameters that indirectly affect the network.

[0196] Network usage data can indicate changes in radio frequency (RF) coverage. The method can further include adjusting one or more reconfigurable smart surfaces (RIS) based on network usage data to improve coverage.

[0197] One or more reconfigurable smart surfaces may comprise planar surfaces composed of unit cells. The characteristics of the unit cells can be dynamically controlled to tune incident wireless signals through reflection, refraction, focusing, collimation, modulation, and / or absorption.

[0198] RIS can be used both indoors and outdoors. RIS can be used indoors in offices, airports, and shopping malls. RIS can be used outdoors in street installations such as lampposts and billboards.

[0199] One or more RIS can be used to automatically sense UE movement and dynamically update coverage (e.g., by determining which cells need to be changed to enhance coverage).

[0200] Advantageously, using RIS can improve network coverage and reduce energy consumption.

[0201] Adjusting one or more RIS can be further based on one or more RF coverage models.

[0202] The RF model reconfiguration AI engine can be used to control one or more RIS based on one or more RF coverage models and network usage data.

[0203] The data and instructions used to control one or more RISs can be provided by the SMO. Additionally or alternatively, the data and instructions used to control one or more RISs can be provided by the network controller (e.g., RIC, such as an xApp running on a near real-time RIC or an rApp running on a non-real-time RIC).

[0204] Network usage data may include scheduling data (e.g., operator or customer data) that indicates planned or predicted changes in data capacity demand.

[0205] In one example, network data usage may include requests for temporarily increased data capacity (e.g., gaming, drone photography, medical instruments).

[0206] One or more base stations can be associated with a single cell, and multiple UEs can connect to a single cell.

[0207] One or more base stations can be associated with multiple different cells, and multiple UEs can each connect to a cell selected from multiple different cells.

[0208] In multi-cell scenarios, L1 scheduling can be implemented by CUDA-accelerated RAN (such as those provided by NVIDIA (RTM)).

[0209] Dynamically modifying the instruction set based on network usage data can include modifying the instruction set based on a model of one or more physical hardware components on which a scheduler is implemented.

[0210] Physical hardware components can be one or more physical infrastructure nodes in a cloud platform.

[0211] Physical hardware components can include chipset architectures.

[0212] A controller is also provided that can be configured to execute any of the methods described above.

[0213] A computer program including instructions is also provided, which, when executed on a processor, cause the processor to perform any of the methods described above.

[0214] A method for scheduling data transmission in a radio access network is also provided. The radio access network includes a scheduler configured to orchestrate the transmission of data between one or more base stations and multiple user equipment (UEs) according to a set of instructions. The method includes simulating the instruction set using a model of one or more physical hardware components on which the scheduler is implemented and network usage conditions; and the method further includes obtaining one or more predicted performance metrics. The method further includes modifying the instruction set based on the one or more predicted performance metrics. The method further includes implementing the modified instruction set such that the scheduler is configured to orchestrate the transmission of data between one or more base stations and multiple UEs according to the modified instruction set.

[0215] Compared to existing techniques where engineers manually manage L1 scheduling parameters, the proposed method involves automatically determining L1 scheduling parameters by training a model for the chipset. This model dynamically builds upon specific environment and traffic patterns to create specific L1 schedules based on short-term and long-term requirements. Current L1 scheduling techniques only provide static, black-box-like L1 scheduling and cannot be externally trained by AI / ML for deployment. In contrast, the proposed method leverages AI and ML algorithms to provide improved L1 scheduling based on specific chipset, environment, and traffic patterns. The AI ​​and ML algorithms can be trained on a dataset including network usage data. The dataset can be created using raw real-world data, managed real-world data, synthetic data, or some combination of these options. Data can be created using simulations of telecommunications networks. The output of the AI ​​and ML algorithms can include a set of instructions comprising one or more parameters related to constraints on the target hardware. Alternatively, the output of the AI ​​and ML algorithms can include values ​​for one or more parameters related to constraints on the target hardware. One or more parameters can then be included in the instruction set. Therefore, the AI ​​and ML algorithms can be used to create instruction sets based on data including network usage. The performance of AI and ML algorithms can be evaluated by simulating instruction sets created using the algorithm and modeling one or more physical hardware components on which a scheduler is implemented, along with network usage data matched against corresponding network usage conditions. The model can be refined based on the performance evaluation. AI and ML algorithms can be hosted on a Service Management Orchestrator (SMO) platform. AI and ML algorithms can include one or more of the following types of models / algorithms:

[0216] Deep reasoning;

[0217] Logistic regression

[0218] Neural networks

[0219] Recurrent Neural Networks (RNNs)

[0220] Long Short-Term Memory (LSTM)

[0221] Convolutional Neural Network (CNN)

[0222] k-means

[0223] Support Vector Machine

[0224] k-nearest neighbor,

[0225] Random Forest

[0226] Decision trees, and

[0227] XGBoost (Extreme Gradient Boosting)

[0228] This problem is solved by using hardware models (digital twins) to allow RICs or SMOs to generate dynamically trained schedules based on network usage data (such as inputs from traffic performance and long-term traffic patterns, such as weekdays, end of the month, banking, and public holidays) to create schedules trained for specific locations (e.g., shopping malls, airports, industrial areas, schools, universities, highways, stadiums, etc.) over a period of time.

[0229] Digital twins can also leverage scheduling data (e.g., airport flight scheduling, football match scheduling, and the like) to refine multiple different instruction sets and generate dynamic performance patterns that meet the network's needs.

[0230] When a flight arrives, facial recognition may need to be performed on passengers (e.g., at passport control). This may require transmitting a large amount of data over the access network, and therefore may necessitate temporarily increasing the capacity of the UE performing the facial recognition.

[0231] Digital twins can send updated schedules (including one or more instruction sets) to an L1 scheduling framework and can implement new instruction sets during marked time periods (e.g., defined by start and end times).

[0232] Digital twins can be continuously updated based on feedback from the network. RIC / SMO can use the updated model to continuously refine one or more instruction sets and replace instructions sent to the scheduler. Therefore, L1 scheduling parameters can be updated based on network usage to provide improved power-performance tradeoffs and increase subscriber satisfaction.

[0233] The scheduler can be configured to allocate physical layer (L1) resources.

[0234] The scheduler can be configured to coordinate data transmission on both the downlink and uplink.

[0235] A scheduler can be provided in the MAC layer (L2).

[0236] Existing methods involve scheduling resources based on channel quality measurements between each UE and the base station, the data buffer state of each UE (downstream and upstream), the QoS requirements of each UE, and so on. However, the basic scheduling parameters (which apply to all UEs) are typically static and fixed.

[0237] In contrast, the proposed method provides the network with the ability to modify scheduling based on a specific environment by using models of hardware and environment to simulate scheduling.

[0238] Network usage status can include the status of one or more radio channels, such as radio channel conditions (noise, interference, attenuation, etc.).

[0239] Network usage data can include network demand information, such as the number of subscribers, traffic density, and the like.

[0240] The data transmitted between one or more base stations and multiple UEs can be user data (i.e., application data).

[0241] This model can be an AI model. Training data can be used to train the model.

[0242] Using models to simulate instruction sets can include using models to simulate multiple different candidate instruction sets, obtaining one or more corresponding performance metrics for each candidate, and selecting modified instruction sets from multiple candidates based on performance metrics.

[0243] Using models to simulate an instruction set can include estimating the time taken for each of a number of instructions to be executed by one or more physical hardware elements.

[0244] A description of the physical hardware can be copied into the model. This model can then be used to simulate the time spent executing specific instructions. For example, the model can be used to simulate the time spent moving data from memory.

[0245] Actual hardware measurements can be performed and used to train the model.

[0246] One or more physical hardware components may include one or more of the following:

[0247] Chipset;

[0248] CPU;

[0249] GPU;

[0250] Computer memory;

[0251] Data storage device;

[0252] Networking components; and

[0253] Acceleration element.

[0254] Physical hardware components can be one or more physical infrastructure nodes in a cloud platform.

[0255] Network usage status includes environmental conditions, including one or more of the following:

[0256] Number of subscribers

[0257] Flow density,

[0258] The direction of user mobility

[0259] The speed of gathering

[0260] Interference measurement, and

[0261] Signal strength.

[0262] The method may further include using network usage data and / or physical hardware performance data (e.g., data indicating the time taken for each of a plurality of instructions to be executed by one or more physical hardware elements) to train the model.

[0263] Network usage data may include one or more of the following:

[0264] Network data received from network functions, controllers, and / or management platforms (e.g., non-RT RIC or SMO);

[0265] Sensing data (e.g., from ISAC); and

[0266] RF coverage data (e.g., from an RF coverage model).

[0267] Network usage can correspond to points in time within a recurring schedule. The instruction set for implementing modifications can include a set of instructions that modify according to a schedule, such that the modification occurs at the time corresponding to a point in time within the recurring schedule.

[0268] In other words, the network conditions during scheduling can be consistent with the network conditions used to train the model (i.e., the model for which the instruction set is simulated and modified).

[0269] Network demand can vary based on recurring patterns. For example, in a shopping mall, it might be quieter in the morning and may require less capacity. During lunchtime, the capacity in the food court can be increased. When school ends, the children's area may be busier, and the capacity there can be increased. Scheduling can be adapted based on weekdays / weekends, public holidays, school holidays, and the like.

[0270] Network usage can be used to train a model tailored to the network's needs. This model can then be used to simulate modified instructions to refine them (e.g., to provide optimal output for efficiency, throughput, etc., based on performance metrics). The modified instructions can then be fed to a dynamic L1 scheduler based on the trained sequence.

[0271] The method may further include receiving real-time network usage data. The modified instruction set may include selecting the modified instruction set based on the real-time network usage data.

[0272] This method may further include dynamically adjusting the instruction set based on network usage data.

[0273] The instruction set may include multiple parameters, which include one or more of the following: subcarrier spacing; and symbol duration.

[0274] The method may further include storing the updated instruction set in the scheduler's persistent storage location.

[0275] The persistent storage location can be a file stored at a fixed file location on the scheduler ("fixed location file").

[0276] RAN can be an open RAN.

[0277] Open RAN can include one or more network function deployments.

[0278] One or more network function deployments may include an Open Distributed Unit (O-DU).

[0279] O-DU may include a scheduler.

[0280] An open RAN may include a controller configured to perform steps that modify the instruction set.

[0281] The controller can be a non-real-time RAN intelligent controller, i.e., a non-RT RIC.

[0282] One or more base stations can be associated with a single cell, and multiple UEs can connect to a single cell.

[0283] One or more base stations can be associated with multiple different cells, and multiple UEs can each connect to a cell selected from multiple different cells.

[0284] A controller is also provided that can be configured to execute any of the methods described above.

[0285] A computer program including instructions is also provided, which, when executed on a processor, cause the processor to perform any of the methods described above. Attached Figure Description

[0286] The invention is described with reference to the following accompanying drawings, which illustrate non-limiting examples.

[0287] Figure 1 The illustration shows an example cloud platform.

[0288] Figure 2 The diagram illustrates a system based on a specific example.

[0289] Figure 3 The diagram illustrates a timing diagram based on a specific example.

[0290] Figure 4 The diagram illustrates a system based on another specific example.

[0291] Figure 5 The diagram illustrates a system based on another specific example.

[0292] Figure 6 The diagram illustrates a system based on another specific example.

[0293] Figure 7 The illustration shows a schematic diagram illustrating the data flow in a system based on a specific example. Detailed Implementation

[0294] The proposed method is described below with reference to open RAN systems. The proposed method is particularly suitable for open RAN systems because open RAN provides mechanisms for feeding environmental data and network usage back to the RAN to modify scheduling. However, the proposed method can be implemented in non-open networks, provided that network usage data and / or network usage conditions are available to the network.

[0295] Prior to Open RAN, mobile networks were built by a small number of vendors with tightly coupled hardware and software. Interoperability between equipment from different vendors was limited, and this arrangement resulted in limited flexibility and innovation. The goal of Open RAN is to improve upon this traditional model by decoupling hardware and software components. This enables greater flexibility, innovation, and cost-effectiveness in building and operating mobile networks.

[0296] As mentioned above, Open RAN systems decouple the hardware and software in a RAN network and allow for the separate configuration of hardware and software components. To this end, the Open RAN Alliance has provided new standards for the interaction between the hardware and software components of Open RAN systems (the term "O-RAN" generally refers to the standards specified by the Open RAN Alliance).

[0297] The following benefits can be achieved by moving from a non-open RAN to an open RAN:

[0298] break down;

[0299] Decouple HW from SW;

[0300] Open ecosystem;

[0301] Open interfaces; and

[0302] Intelligent management.

[0303] Open RAN enables interoperability of hardware and software components from different vendors. By doing so, Open RAN also provides resilience to MNOs by promoting vendor diversity in the network. If a component from a particular vendor stops functioning correctly or needs to be permanently or temporarily removed (e.g., due to security or performance requirements), it can be replaced by a component from another vendor without causing significant disruption to the network.

[0304] Open RAN also offers potential energy efficiency improvements, such as through flexible hardware configuration to meet network requirements.

[0305] Open RAN enables functional block decomposition, where baseband processing functions are separated into distinct blocks, allowing for contributions and innovation from various vendors. For interoperability, solutions from different vendors should work together. Therefore, the goal of Open RAN is to facilitate interoperability between hardware and software components across different vendors. Decomposing RAN functions into software-based components that can be hosted on different processor architectures introduces interoperability challenges when managing and orchestrating these functions.

[0306] A cloud platform (sometimes referred to as "O-Cloud") serves as a fundamental component of an open RAN system. A cloud platform comprises both hardware and software components. The hardware components of a cloud platform include physical infrastructure nodes deployed in one or more node clusters. These provide the hardware resources required to support the deployment of network functions (e.g., O-RU, O-DU, and O-CU), which are implemented in software applications running on the cloud platform hardware.

[0307] The proposed method in this disclosure provides dynamic real-time or near-real-time L1 scheduling based on environmental changes.

[0308] In the first embodiment, on-demand scheduling is facilitated to enhance the performance of the HW platform during a specified time period.

[0309] In the second embodiment, a trained AI model (referred to as a digital twin) based on hardware and environment is used to plan scheduling in advance to enhance the performance of the HW platform.

[0310] Figure 2 A schematic diagram of a system according to a specific example of the first embodiment is illustrated. The following description... Figure 2 The functional components are shown in the diagram.

[0311] DU and CU (e.g., which can be 4G / 5G / 6G) are implemented as network function applications running on the underlying hardware of the O-Cloud platform.

[0312] SMO is responsible for allocating hardware resources to network functions.

[0313] The DU and CU network functions communicate with one or more remote radio heads (RRHs), antenna processing units (APUs), and cell-free massive MIMO (CF-mMIMO) to transmit data with UEs connected via the radio access network.

[0314] Network usage data is provided in one or more of the following forms: network statistics (e.g., from RIC and / or SMO); ISAC sensing data; and RF coverage data from RF coverage models.

[0315] The radio interface controller (also known as the "RAN Intelligent Controller"; RIC) communicates with the hardware platform to control and tune RAN functions. The RIC can be a near-RT RIC and can reside in a telecom edge cloud or regional cloud.

[0316] A dynamic L1 scheduler generator (which may be a component of the RIC) communicates with the hardware platform and includes a task scheduling file for implementing modified schedules. The modified schedules can allocate more radio resources to one or more UEs connected via the RAN based on network usage data. The modified schedules can be implemented within a limited time period before reverting to the previous schedule.

[0317] Figure 3 The illustration shows a timing diagram according to a specific example of the first embodiment. The timing method includes the following steps:

[0318] Step 1: Set a timing flag for the next specified number of frame slots or a specified time period with start and stop times.

[0319] Step 2: The modified scheduler instruction set (SI-a) is sent to the L1 scheduler file.

[0320] Step 3: The L1 task scheduler uses a new scheduler instruction set (SI-a) within a specified number of frame slots or a specified time period.

[0321] Step 4: Turn off the timer flag setting.

[0322] Step 5: Restore to the default L1 task scheduler instruction set or set a new timing flag for the new scheduler instruction set (SI-b).

[0323] Figure 4 The illustration shows a schematic diagram of a system according to a first embodiment and another specific example.

[0324] 6G cellless architecture can include DU and CU network functions running on the underlying hardware of the O-Cloud platform.

[0325] The 6G cellless architecture communicates with one or more remote radio heads (RRHs), antenna processing units (APUs), and cellless massive multiple-input multiple-output (CF-mMIMO) devices to transmit data with UEs connected via a radio access network.

[0326] The radio interface controller (also known as the "RAN Intelligent Controller"; RIC) communicates with the hardware platform to control and tune RAN functions. The RIC can be a near-RT RIC and can reside within a telecom edge cloud or regional cloud.

[0327] The network uses data from a sensing platform (e.g., an ISAC platform) to provide to the RIC.

[0328] RICs can be used to control one or more reconfigurable smart surfaces (RIS). One or more RICs can also be configured to provide network usage data to the RICs.

[0329] RF coverage data from the RF coverage model is provided to the RIS and sensing platform. The RIS and sensing platform can also feed the data back to the RF coverage model to refine the model.

[0330] A dynamic L1 scheduler generator (which may be a component of the RIC) communicates with the hardware platform and includes a task scheduling file for implementing a modified scheduler instruction set (which may also be referred to as a "schedule" or "schedule of instructions"). The dynamic L1 scheduler generator also communicates with the RIS and sensing platform to receive network usage data. The modified schedule can allocate more radio resources to one or more UEs connected via the RAN based on the network usage data. The modified schedule can be implemented within a limited time period before reverting to the previous schedule. The modified instruction set can be implemented via the L1 scheduler's chipset hardware (and may utilize a dynamic scheduling AI engine).

[0331] It can record changes in the environment in real time or near real time, such as the number of subscribers, traffic density, direction of user movement, interference, and signal strength.

[0332] The recorded input can be fed into a dynamic L1 scheduler generator. The performance parameters required by subscribers in the region within a specified time period can be used to create new L1 schedules for on-demand services. New L1 scheduler parameters can be updated in near real-time in a fixed location file of the current scheduler.

[0333] An updated scheduler instruction set can be marked as ready to be executed within a predetermined window (e.g., from a specified time to a specified time). Optimized L1 scheduler instruction sets can be created for specified time periods based on environmental requirements (e.g., based on network usage data interpretation).

[0334] It can collect and correlate feedback from the environment with HW platform performance KPIs. Rapid changes can be continuously fed into the dynamic L1 scheduler generator.

[0335] Additionally, network operators may request (e.g., via RIC app) a new set of scheduler instructions for new subscriber applications within another specified time period.

[0336] Figure 5 The illustration shows a schematic diagram of a system according to another specific example based on the second embodiment.

[0337] DU and CU (e.g., which can be 4G / 5G / 6G) are implemented as network function applications running on the underlying hardware of the O-Cloud platform.

[0338] SMO is responsible for allocating hardware resources to network functions.

[0339] The DU and CU network functions communicate with one or more remote radio heads (RRHs), antenna processing units (APUs), and cell-free massive MIMO (CF-mMIMO) to transmit data with UEs connected via the radio access network.

[0340] Network usage is provided in one or more of the following forms: network statistics (e.g., from RIC and / or SMO); ISAC sensing data; and RF coverage data from RF coverage models.

[0341] The radio interface controller (also known as the "RAN Intelligent Controller"; RIC) communicates with the hardware platform to control and tune RAN functions. The RIC can be a near-RT RIC and can reside within a telecom edge cloud or regional cloud.

[0342] A digital twin is used to model an L1 scheduler instruction set using one or more physical hardware components on which a scheduler is implemented. Network usage (network statistics (e.g., from RIC and / or SMO); ISAC sensing data; and RF coverage data from an RF coverage model) is provided to the digital twin to obtain one or more predicted performance metrics.

[0343] The predicted performance metrics can be provided to the RIC. These predicted performance metrics can then be used to modify the instruction set to generate an improved one.

[0344] A dynamic L1 scheduler generator (which may be a component of RIC and / or SMO) communicates with the hardware platform and includes a task scheduling file for implementing one or more modified scheduler instruction sets. Based on simulation results and / or network usage, each modified scheduler instruction set can allocate more radio resources to one or more UEs connected via the RAN.

[0345] Figure 6 The illustration shows a schematic diagram of a system according to another specific example based on the second embodiment.

[0346] Digital twins create digital models of hardware (e.g., chipsets).

[0347] Non-real-time RICs and SMOs provide data to digital twins, such as network usage and hardware details.

[0348] The performance parameters required by subscribers in this region within a specified time period are used to create a new L1 scheduler instruction set for on-demand services trained by AI in a digital twin. An optimized L1 schedule is created for the specified time period based on environmental requirements.

[0349] The new L1 scheduling parameters are sent to the current scheduler's fixed location file. The updated schedule is marked as ready to execute from the specified time to the specified time.

[0350] Feedback from the environment and performance KPIs of the HW platform can be collected and correlated. Changes can be continuously fed back into the dynamic L1 scheduler generator to improve one or more scheduler instruction sets. These improvements can be simulated using digital twins and implemented in the future (i.e., on a non-real-time basis).

[0351] Mobile network operators may request (e.g., via RIC app) a new set of scheduler instructions for new subscriber applications at another specified time period.

[0352] Figure 7 The illustration shows a schematic diagram illustrating the data flow in a system according to a specific example of the first and second embodiments.

[0353] In the first embodiment, network usage data is provided to the near-RT RIC for dynamically modifying the instruction set. The network usage data is provided in one or more of the following forms: network statistics (e.g., from the RIC and / or SMO); ISAC sensing data; and RF coverage data from the RF coverage model.

[0354] Network usage data can include airport flight scheduling takeoff and landing data.

[0355] A modified L1 scheduler instruction set can be provided to the scheduler, which can be part of a CaaS (Container as a Service) platform. Start / stop timing flags can also be provided to the scheduler.

[0356] The example method according to the first embodiment may include the steps described below.

[0357] Step 1: Receive network usage data, such as sensor data, RF changes, or operator or enterprise customer databases (e.g., airport flight scheduling takeoff / landing data). Network usage data is received by the near-RT RIC. Network usage data may include requests for or indications of a temporary increase in capacity. For example, a large amount of computation may be required in the next 12 minutes due to a flight arrival / customs arrival. In another example, the duration of the high computational demand may only be a few seconds (e.g., gaming, video capture by a drone) or a few milliseconds (e.g., as requested by a robot in industry or an ambulance / health device in the home).

[0358] Step 2: Based on network usage data (which may also include data from network elements including RIC and / or SMO, as well as sensing data from ISAC and RF coverage models), determine the modified L1 scheduler instruction set for the specified request.

[0359] Step 3: The timing flag is set with a specified start / stop time (with an instantaneous response request).

[0360] Step 4: Receive feedback from the modified scheduler for further RIC strategy adaptation. Closed-loop control of chipset performance is implemented using the RIC / SMO / ISAC / RF model.

[0361] In the second embodiment, network usage data is provided to a model (digital twin) of one or more physical hardware elements on which a scheduler is implemented to simulate one or more instruction sets. The network usage data is provided in one or more of the following forms: network statistics (e.g., from RIC and / or SMO); ISAC sensing data; and RF coverage data from an RF coverage model.

[0362] One or more modified instruction sets can be generated based on simulation (e.g., different instructions for different time periods).

[0363] A modified L1 scheduler instruction set can be provided to the scheduler, which can be part of a CaaS (Container as a Service) platform. Start / stop timing flags can also be provided to the scheduler for each modified instruction set.

[0364] The example method according to the second embodiment may include the steps described below.

[0365] Step 1: Replicate the chipset architecture model in the digital twin, especially the time spent on each type of basic instruction / execution.

[0366] Step 2: The AI / Gen AI trains the digital twin using data from the network (e.g., from RIC and / or SMO), sensing (ISAC), and RF coverage models (collectively referred to as network usage). A modified L1 scheduler instruction set is determined for the specified subscriber area (shopping mall, industrial area, highway, city center).

[0367] Step 3: The timing flag is determined by the digital twin or by a request from the RIC policy (e.g., morning / evening peak hours, weekends, bank holidays, etc.). The start / stop time using the digital twin can involve longer time frames rather than instantaneous response time (unlike the first embodiment).

[0368] Step 4: Feedback from the modified scheduling implementation is sent to the hardware model and also used for further RIC strategy adaptation. Therefore, closed-loop control of chipset performance is implemented using the RIC / SMO / ISAC / RF model.

[0369] Step 5: A hardware model (digital twin) is used to modify the instruction set and is refined based on further network usage data collected during the implementation of the modified instruction set. Different modified instruction sets can be created and implemented based on repeated scheduling to account for macro-network changes and better serve UEs connected via the access network.

[0370] Although specific embodiments have been described above, those skilled in the art will understand that various modifications and variations are possible. For example, while this disclosure has been described with respect to existing network architectures, it will be understood that changes to the architecture (and / or terminology) are possible, but this disclosure may still apply in such cases. Furthermore, combinations of any particular features shown with reference to one or more embodiments are provided, even if such combinations are not explicitly detailed herein.

[0371] For example, in the case of servers in this application, for redundancy, this can actually be a pair of servers (a primary server and a failover server).

[0372] In the context of this application involving "network entities," those skilled in the art will understand that a network entity can actually be provided by multiple geographically distributed servers.

[0373] The open radio access network described above can be used as a cellular network to provide services to one or more user equipment (UEs). Examples of UEs include various fixed and mobile devices that transmit and receive user data and / or various control information from base stations. UEs can be referred to as terminal equipment (TE), mobile station (MS), mobile terminal (MT), user terminal (UT), subscriber station (SS), radio equipment, personal digital assistant (PDA), wireless modem, handheld device, etc.

[0374] While the examples described above pertain to specific radio access networks (e.g., 4G and 5G radio access networks), these methods, technologies, apparatuses, and systems can be applied to a wide variety of radio multiple access systems. Examples of multiple access systems include CDMA, FDMA, TDMA, OFDMA, SC-FDMA, and MC-FDMA. CDMA can be implemented using radio technologies such as UTRA or CDMA2000. TDMA can be implemented using radio technologies such as GSM, GPRS, or EDGE. OFDMA can be implemented using radio technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA. UTRA is part of UMTS. 3GPP LTE is part of E-UMTS using E-UTRA. 3GPP LTE uses OFDMA in the downlink and SC-FDMA in the UL. LTE-A is an evolution of 3GPP LTE. 3GPP NR uses OFDMA for both downlink and uplink and can operate in both FDD and TDD modes. For ease of description, it is assumed that the present invention applies to 3GPP NR. However, the technical features of the present invention are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP NR system, aspects of the present invention that are not specific to 3GPP NR are applicable to other mobile communication systems. Furthermore, the technical features of the present invention can be applied to future iterations of multiple access systems defined in the 3GPP standard, such as (but not limited to) 6G.

[0375] The examples described can be executed on any suitable data processing device, such as a personal computer, laptop computer, mobile phone, server, virtual machine, and the like. For purposes of discussion, the above description of the systems and methods has been simplified and is intended to provide specific examples to illustrate the invention. As those skilled in the art will understand, different types of systems and methods can be used. It will be understood that the boundaries between logic blocks are merely illustrative, and alternative embodiments may combine logic blocks or elements, or may impose alternative decompositions of functionality on various logic blocks or elements.

[0376] It will be understood that the above-described functions can be implemented as hardware and / or software as one or more corresponding modules. For example, the functions mentioned above can be implemented as one or more software components executed by the system's processor. Alternatively, the functions mentioned above can be implemented as hardware, such as on one or more FPGAs, and / or one or more ASICs, and / or one or more DSPs, and / or other hardware arrangements. The method steps implemented in the flowcharts included herein or as described above can each be implemented by their respective corresponding modules. Furthermore, multiple method steps implemented in the flowcharts included herein or as described above can be implemented together by a single module.

[0377] Any of the methods described herein can be implemented as computer software or a "computer program". A computer program can be configured to control a network entity (e.g., a server or group of servers) to perform any of the methods disclosed herein. Network entities (e.g., servers or groups of servers) within a cellular network may also be provided, configured to operate according to some of the methods disclosed herein. For example, a network entity may include a processor and at least one communication interface, particularly including one or both of a transmitter and a receiver.

[0378] It also provides storage media and transmission media for carrying computer programs. A computer program may include one or more instructions or code that, when executed by a computer, cause the described methods to be performed. A computer program may be a sequence of instructions designed to execute on a computer system and may include subroutines, functions, procedures, modules, object methods, object implementations, executable applications, applets, service applets, source code, object code, shared libraries, dynamic link libraries, and / or other sequences of instructions designed to execute on a computer system. Storage media may be disks (such as hard disk drives or floppy disks), optical disks (such as CD-ROMs, DVD-ROMs, or Blu-ray discs), or memory (such as ROM, RAM, EPROM, EEPROM, flash memory, or portable / removable memory devices). Transmission media may be communication signals, data broadcasts, communication links between two or more computers, etc.

[0379] Unless otherwise stated, each feature disclosed in this specification can be used to replace alternative features for the same, equivalent, or similar purposes. Therefore, unless otherwise stated, each disclosed feature is merely one example from a range of general equivalent or similar features.

[0380] Wherein used herein, including in the claims, unless the context otherwise indicates, the singular form of a term herein shall be construed as including the plural form, and vice versa. For example, unless the context otherwise indicates, singular references herein, including in the claims, such as “a” or “an” (such as a UE, network entity, server, or cell) mean “one or more” (e.g., one or more UEs, one or more network entities, one or more servers, or one or more cells). Throughout the specification and claims of this disclosure, the words “comprise,” “including,” “having,” and “comprising,” as well as variations of these words, such as “comprising” and “comprises,” or similar, mean “comprising” and are not intended to (and do not) exclude other components.

[0381] The use of any and all examples or exemplary language (“e.g.,” “such as,” “e.g.,” and similar language) provided herein is intended only to better illustrate the invention and does not indicate any limitation on the scope of the invention, unless otherwise stated. No language in the specification should be construed as indicating that any unclaimed element is necessary for carrying out the invention.

[0382] Any steps described in this specification may be performed in any order or simultaneously unless otherwise stated or required by the context. Furthermore, the fact that a step is described as being performed after another step does not preclude the performance of intermediate steps.

[0383] All aspects and / or features disclosed herein can be combined in any combination, except for at least some mutually exclusive combinations of such features and / or steps. As described herein, specific combinations of aspects may exist that offer further benefits, such as determining a set of compensation parameters and applying that set to a measurement. In particular, preferred features of the invention apply to all aspects of the invention and can be used in any combination. Similarly, features described in non-essential combinations may be used separately (not in combination).

[0384] A method is also provided for manufacturing and / or operating any of the devices disclosed herein. This method may include the steps of providing each of the disclosed features and / or configuring or using the respective feature for its stated functionality.

Claims

1. A method for data transmission in a radio access network, wherein, A radio access network includes a scheduler configured to orchestrate the transmission of data between one or more base stations and multiple user equipment (UEs) according to a set of instructions, the method comprising: Receive real-time network usage data; The instruction set is dynamically modified based on network usage data; and The modified instruction set is implemented such that the scheduler is configured to orchestrate the transmission of data between one or more base stations and multiple UEs according to the modified instruction set, wherein the instruction set includes one or more parameters relating to constraints on the target hardware.

2. The method according to claim 1, wherein, Modifying the instruction set includes defining a time period during which the scheduler implements modifications to the instruction set.

3. The method according to claim 1 or claim 2, wherein, The instruction set includes multiple parameters, which include one or more of the following: Subcarrier offset; Subcarrier spacing; Symbol duration; Time slot format; Time-domain allocation k0 for downlink data transmission; Ack / Nack timing information k1; Time-domain allocation k2 is used for uplink data transmission; Start and length indicator values ​​SLIV; The minimum time duration N1 required from decoding the physical downlink control channel PDCCH to receiving the physical data sharing channel PDSCH; The minimum time duration N2 required from decoding the physical downlink control channel PDCCH to transmitting the physical uplink shared channel PUSCH; Waiting time; Response time; Turnover time; Buffer size; Block size; 5G Quality of Service (QoS) identifier; Assign and retain priority ARPs; Reflecting QoS attribute RQA; One or more scheduling weights; One or more admission thresholds; as well as One or more queue management thresholds.

4. The method according to any of the preceding claims, wherein the RAN is an open RAN, comprising: One or more network function deployments include an Open Distributed Unit (O-DU), wherein the O-DU includes a scheduler; as well as The controller is configured to perform the steps of receiving real-time network usage data and dynamically modifying the instruction set based on the network usage data.

5. The method according to claim 4, wherein, The controller is a near real-time RAN intelligent controller, also known as a near-RT RIC.

6. The method according to any of the preceding claims, wherein, The network uses data to indicate changes in the environment, including one or more of the following: Number of subscribers Flow density, The direction of subscriber mobility Maximum subscriber mobility Minimum subscriber mobility The speed of aggregation Interference measurement Signal strength, Downlink latency Uplink latency, and Power saving mode.

7. The method according to any of the preceding claims, wherein, Network usage data includes data from the Integrated Sensing and Communication (ISAC) platform.

8. The method according to any of the preceding claims, wherein, Network usage data indicates changes in radio frequency (RF) coverage, wherein the method further includes adjusting one or more reconfigurable smart surfaces (RIS) based on the network usage data to improve coverage.

9. The method according to claim 8, wherein, Adjust one or more RIS models based on one or more RF coverage models.

10. The method according to any of the preceding claims, wherein, Network usage data includes scheduling data that indicates planned or predicted changes in data capacity demand.

11. The method according to any of the preceding claims, wherein, Network usage data includes requests for temporarily increased data capacity.

12. The method according to any of the preceding claims, wherein: One or more base stations are associated with a single cell, and multiple UEs are connected to the single cell; or One or more base stations are associated with multiple different cells, and multiple UEs are each connected to a cell selected from the multiple different cells.

13. The method according to any of the preceding claims, wherein, Dynamically modifying the instruction set based on network usage data includes modifying the instruction set based on a model of one or more physical hardware components on which the scheduler is implemented.

14. A controller configured to perform the method of any one of claims 1 to 13.

15. A computer program comprising instructions that, when executed on a processor, cause the processor to perform the method according to any one of claims 1 to 13.

Images