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

Abstract

The present disclosure relates to a method, a controller and a 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 includes a scheduler configured to orchestrate data communications between one or more base stations and a plurality of user equipments (UEs) according to an instruction set. The method includes receiving real-time network usage data. The method also includes dynamically modifying the instruction set based on the network usage data. The method also includes implementing the modified set of instructions such that the scheduler is configured to orchestrate data communications between the one or more base stations and the plurality of UEs according to the modified set of instructions.

Description

Technical Field

[0001] This invention relates to scheduling in radio access networks. In particular, this invention relates to modifying L1 scheduling based on network usage data and / or conditions.

[0002] Vocabulary

[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 – Media 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 Functions

[0021] IMS – Infrastructure Management Services

[0022] QoS – Quality of Service

[0023] PDCCH—Physical Downlink Control Channel

[0024] DCI – Downlink Control Information

[0025] PDSCH—Physical Data Sharing Channel

[0026] ARQ – Automatic Repeat Request; HARQ – Hybrid ARQ; PUSCH – Physical Uplink Shared Channel; SLIV – Start and Length Indicator Values; ARP – Assign and Reserve Priority; RQA – Reflective QoS Attributes; Near-Real-Time RAN Intelligent Controller; TRIC – Near-Real-Time RAN Intelligent Controller; Non-Real-Time RAN Intelligent Controller; ISAC – Integrated Sensing and Communication; RF – Radio Frequency; RIS – Reconfigurable Smart Surface; CUDA – Computational 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 Header; APU – Antenna Processing Unit; CF-mMIMO – Cellless Massive Multiple-Input Multiple-Output; RIC – Radio Interface Controller or RAN Intelligent Controller; SI – Scheduler Command; CaaS – Container 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 N B – Node B (Radio Base Station Receiver) eNB – Evolved Node BgNB – Next Generation Node BTRP – Transmit and Receive Point PS – Processing Server TE – Terminal Equipment MS – Mobile Station MT – Mobile Terminal UT – User Terminal SS – Subscriber Station PDA – Personal Digital Assistant CDMA – Code Division Multiple Access FDMA – Frequency Division Multiple Access TDMA – Time Division Multiple Access OFDMA – Orthogonal Frequency Division Multiple Access SC-FDMA – Single Carrier Frequency Division Multiple Access MC-FDMA – Multi-Carrier Frequency Division Multiple Access UTRA – Universal Terrestrial Radio Access GSM – Global System for Mobile Communications (2G) GSMA – GSM Association GPRS – Universal Packet Radio Service EDGE – Enhanced Data Rate Evolution of GSM E-UTRA – Institute of Electrical and Electronics Engineers Electronic UTRA – Evolved UTRA UMTS – Universal Mobile Telecommunications System (3G) E-UMTS – Evolved UMTS

[0027] 3GPP – 3rd Generation Partnership Project (DL) – Downlink (UL) – Uplink (LTE) – Long Term Evolution (4G)

[0028] LTE-A – LTE Advanced

[0029] NR – New Radio (5G)

[0030] FDD - Frequency Division Duplex

[0031] TDD - Time Division Duplex

[0032] CRS—Cell-Specific Reference Signal

[0033] CSI-RS—Channel State Information Reference Signal

[0034] FPGA - Field Programmable Gate Array

[0035] ASIC — Application-Specific Integrated Circuit

[0036] DSP—Digital Signal Processor

[0037] CD-ROM—Optical Disc Read-Only Memory

[0038] DVD-ROM—Digital Multifunction Optical Disc Read-Only Memory

[0039] ROM - Read-Only Memory

[0040] RAM—Random Access Memory

[0041] EEPROM—Electrically Erasable Programmable Read-Only Memory

[0042] EPROM—Erasable Programmable Read-Only Memory Background Technology

[0043] Scheduling in radio access networks is the process of allocating radio resources for data transmission. In most existing technology use cases, scheduling is determined by the network. UEs connected via the network must adhere to a scheduling table set by the network. Advances in radio access network technology have introduced methods for feeding data back to the network, which can be used to improve scheduling.

[0044] Open RAN is a technical architecture concept for decoupling the hardware and software components of a radio access network (RAN). It is a type of RAN that includes open, interoperable interfaces and virtualization. In existing (non-open) RAN technologies, both hardware and software components are typically proprietary. Non-open RAN equipment is generally sourced from a single vendor to ensure seamless functionality, security, and efficiency. In contrast, Open RAN introduces open standards for both hardware and software, enabling interoperability between various network elements. Open RAN is strategically important for mobile network operators (MNOs) because it promotes vendor diversity, allowing for the integration of new suppliers and enhanced supply chain resilience. It also delivers energy efficiency gains by enabling targeted improvements in specific areas of the RAN. Furthermore, Open RAN fosters innovation and competition by providing a more dynamic and efficient network environment. Additionally, it offers opportunities to collaborate with specialized vendors and facilitates resource optimization by allowing software upgrades without replacing hardware. Open RAN is crucial in MNOs' long-term network innovation strategies, providing energy efficiency, supply chain diversification, enhanced resilience, and fostering innovation and competition.

[0045] Figure 1 The illustration shows some components of an example open RAN system 100, which is implemented as a cloud computing platform (O-Cloud). The different hardware and software layers of the platform can be referenced to describe system 100.

[0046] At the O-Cloud node layer 110, the system includes one or more physical infrastructure nodes 120A, 120N that meet O-RAN requirements. Each physical infrastructure node 120A includes a computing component 121, a networking component 122, a GPU component 123, and a storage component 124, as well as acceleration technologies 125 for RAN operations such as forward error correction and other compute-intensive operations offloaded to dedicated hardware. Each physical infrastructure node 120A, 120N is configured to host relevant O-RAN network functions 150, 160 implemented at the Open RAN application layer 140. The network functions 150, 160 implemented at the Open RAN application layer 140 may include O-CU 160, O-DU 150, and O-RU.

[0047] The O-CU, O-DU, and O-RU network function deployment includes functional elements for handling different protocols in the RAN protocol stack. The O-DU 150 includes:

[0048] ●High PHY component 151 is used to perform scrambling, modulation, layer mapping, precoding, resource element mapping and I / Q compression elements of the PHY layer;

[0049] ●MAC component 152; and

[0050] ·RLC component 153.

[0051] O-CU includes:

[0052] ·PDCP component 161; and

[0053] ·RRC / SDAP component 162.

[0054] The O-DU 150 may further include an open RAN fronthaul interface to connect the O-DU to one or more O-RUs.

[0055] In the O-Cloud hypervisor or container / OS layer 130, there exists a collection of cloud functions to enable open RAN applications 150, 160 to run on one or more O-Cloud hardware nodes 120A. Cloud functions may include supporting software components such as operating systems, containers (standalone executable packages), container orchestration platforms (such as Kubernetes), and container runtime environments. Cloud functions may also include corresponding management and orchestration capabilities.

[0056] O-Cloud serves as a fundamental component enabling cloud computing capabilities within the context of RAN network functions. It comprises both hardware and software components. Specifically, its software exposes open APIs, facilitating interoperability and flexibility across various vendor solutions. Through its decoupled architecture, O-Cloud allows for hardware procurement from different vendors, enhancing hardware selection neutrality and flexibility. It supports Service Management and Orchestration (SMO), implements relocation decisions, and selects Deployment Management Service (DMS) for Network Function (NF) deployments. DMS handles workload placement, lifecycle management, and resource allocation within the O-Cloud node cluster, while Infrastructure Management Service (IMS) ensures infrastructure availability, reliability, and performance. Furthermore, O-Cloud provides automation capabilities, enhancing efficiency and reducing manual intervention, ultimately supporting efficient resource utilization and scalability of RAN network functions in cloud-native environments.

[0057] Layer 1 (L1) scheduling in the hardware platform of an open RAN system is typically completely static and fixed. In standard scheduling, a fixed number of frame slots are provided, during which queued tasks must be completed. Any uncompleted tasks must be discarded or deferred until the next available frame slot.

[0058] Existing methods constrain scheduling tasks entirely to the execution parameters of frame slots, without considering available resources and platform performance capabilities. This provides limited performance response and cannot adapt to rapidly changing environmental needs. In some cases, this can lead to operational failures due to system crashes or limit system performance due to underutilization of available resources. It can also limit on-demand services for ULRC applications, such as gaming, facial recognition (e.g., at airports), and surgery. Services may be throttled for limited time periods, especially for 6G speeds and latency requirements.

[0059] Furthermore, static and fixed L1 scheduling parameters are currently set manually by engineers to ensure that tasks are matched to frame slots and to prevent buffer overflows or other issues. There is currently no available method to determine parameters to customize the scheduling table for a specific chipset, environment, and traffic pattern. Current L1 scheduling technologies only provide a static L1 scheduling table, which is essentially a black box. Summary of the Invention

[0060] A method for scheduling data transmission in a radio access network is provided. The radio access network includes a scheduler configured to orchestrate data communications between one or more base stations and multiple user equipments (UEs) according to an instruction set. The method includes receiving real-time network usage data. The method also 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 data communications between one or more base stations and multiple UEs according to the modified instruction set.

[0061] The problem described above is solved by providing a continuously updated schedule table, updated in near real-time. The parameters of the schedule table are available at fixed locations, and continuous changes to these parameters allow the schedule table to be dynamic. Changes in the environment, such as traffic density, movement direction, and aggregation speed, will cause the schedule to dynamically adapt to the changing environment.

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

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

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

[0065] 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), and the QoS requirements of each UE. However, the basic scheduling parameters (which are applied to all UEs) are typically static and fixed. These parameters do not adjust in response to changes in network needs or radio conditions.

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

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

[0068] In 5G, pre-6G, 6G and above, there is an increasing (or anticipated) demand for high-volume processing and availability of radio resources (with low latency) within short timeframes. Current scheduling methods always provide a static amount of resources. The proposed method can respond quickly to requests for increased capacity and thus better serve changing subscriber needs.

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

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

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

[0072] Network usage data can also include forecast data indicating future demand for 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).

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

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

[0075] Modifying the instruction set can include defining a time period during which the scheduler implements the modified instruction set.

[0076] The method may also include restoring the previous schedule (i.e., the schedule before the modification) after the time period has elapsed.

[0077] Modifying the instruction set may also include defining a time window, where a period of time is a part of the time window during which the scheduler implements the modified instruction set.

[0078] Defining a time window may include setting a start marker and a stop marker. Alternatively, defining a time window may include setting a start marker and several frame slots.

[0079] The time window can be defined by an xApp on the near-RT RIC, which can determine the required timing window based on network usage data. For example, if the default schedule is designed for 5 people to pass through a given area every 20 seconds (e.g., passport security), 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), the xApp on the RIC can determine that more capacity is required and increase capacity by 5 or 6 times over a longer period (e.g., 5 minutes).

[0080] When setting windows for modified instructions, the controller (e.g., RIC) can check for conflicts to ensure that the modified schedule does not cause conflicts in the application within the time slot.

[0081] The method may also include preparing for the implementation of the modified instruction set during an initial period after the start mark and before the period during which the scheduler implements the modified instruction set.

[0082] The initial time period can be used to fine-tune the default operation scheduler until a new scheduler is implemented. For example, it can be used to schedule time slots to be released, which will then be used by the modified scheduler.

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

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

[0085] During the initial time period and / or when the modified instruction scheduler takes effect, tasks may follow different timing sequences to meet network demands based on network usage data.

[0086] This instruction set may include multiple parameters, which may include one or more of the following:

[0087] Subcarrier offset;

[0088] Subcarrier spacing;

[0089] Symbol duration;

[0090] Time slot format;

[0091] Time-domain allocation (k0) for downlink data transmission;

[0092] Ack / Nack timing information (k1);

[0093] Time-domain allocation (k2) for uplink data transmission;

[0094] Start and length indicator values ​​(SLIV);

[0095] The minimum duration (N1) required from decoding the Physical Downlink Control Channel (PDCCH) to receiving the Physical Data Sharing Channel (PDSCH);

[0096] The minimum duration (N2) required from decoding the Physical Downlink Control Channel (PDCCH) to transmitting the Physical Uplink Shared Channel (PUSCH);

[0097] Waiting time;

[0098] Response time;

[0099] Turnover time;

[0100] Buffer size;

[0101] Chunking size;

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

[0103] Assign and retain priority (ARP);

[0104] Reflective QoS Attributes (RQA);

[0105] One or more scheduling weights;

[0106] One or more admission thresholds; and

[0107] One or more queue management thresholds.

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

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

[0110] The time domain allocation (k0) for downlink data transmission can be several time slots between PDCCH / DCI and PDSCH.

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

[0112] The time domain allocation (k0) for uplink data transmission can be several time slots between PDCCH / DCI and uplink data transmission.

[0113] The Start and Length Indicator (SLIV) value can include the start symbol and the length of the symbol scheduled in a specific time slot of the PDSCH and / or PUSCH.

[0114] Multiple parameters can involve constraints on the target hardware (such as 5G constraints).

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

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

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

[0118] One or more network function deployments may include Open Distributed Units (O-DUs).

[0119] O-DU may include a scheduler.

[0120] Open RAN may also include a controller configured to perform the following steps: receive real-time network usage data and dynamically modify the instruction set based on the network usage data.

[0121] The controller can be a near real-time RAN intelligent controller (near RT RIC).

[0122] 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.

[0123] RIC can facilitate the automation of third-party applications and the tuning of RAN operations.

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

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

[0126] A non-RT RIC can be a component 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 components and their resources with a response time of 1 second or longer.

[0127] 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.

[0128] 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-RT RICs 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.

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

[0130] Number of subscribers

[0131] traffic density,

[0132] The direction of subscriber mobility

[0133] Maximum subscriber mobility

[0134] Minimum subscriber mobility

[0135] The speed of gathering

[0136] Interference measurement

[0137] Signal strength,

[0138] Downlink latency

[0139] Uplink latency, and

[0140] Power saving mode.

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

[0142] User mobility can include the geographic movement of individual UEs and / or the total geographic movement of groups of UEs.

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

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

[0145] 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.

[0146] The proposed method enables networks to respond quickly to changes in their subscribers' needs. Examples include smart factories, health monitoring, intelligent traffic monitoring, intrusion detection, privacy protection, and / or target localization.

[0147] The sensing and communication aspects of the ISAC platform can each include general-purpose components, such as:

[0148] Beamforming; and

[0149] Phased antenna array.

[0150] The ISAC platform may also include channel estimation, symbol detection, and target detection capabilities, which are provided by general-purpose hardware.

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

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

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

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

[0155] 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 increase coverage).

[0156] The effective use of RIS can improve network coverage and reduce energy consumption.

[0157] Adjusting one or more RIS can also be based on one or more RF coverage models.

[0158] 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.

[0159] 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 xApp running on a near real-time RIC or rApp running on a non-real-time RIC).

[0160] Network usage data may include schedule data (e.g., operator or customer data) that indicates planned or predicted changes in data capacity requirements.

[0161] Network usage data may include requests for temporarily increased data capacity (e.g., gaming, drone photography, medical instruments).

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

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

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

[0165] 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.

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

[0167] Physical hardware components can include chipset architectures.

[0168] It also provides controllers that can be configured to execute any of the methods described above.

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

[0170] A method for scheduling data transmission in a radio access network is also provided. The radio access network includes a scheduler configured to orchestrate data communication between one or more base stations and multiple user equipments (UEs) according to an instruction set. The method includes simulating the instruction set using a model of one or more physical hardware elements on which the scheduler is implemented and network usage conditions; and the method further includes obtaining one or more predicted performance metrics. The method also 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 data communication between one or more base stations and multiple UEs according to the modified instruction set.

[0171] Compared to existing techniques where engineers manually manipulate L1 scheduling parameters, the proposed method involves automatically determining L1 scheduling parameters by training a model on a chipset. This model is dynamically built using 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 schedules and cannot be externally trained by AI / ML for deployment. In contrast, the proposed method leverages AI and ML algorithms to provide improved L1 schedules based on specific chipsets, environments, and traffic patterns.

[0172] This problem is solved by using a hardware model (digital twin) to allow RICs or SMOs to generate dynamic, trained schedules based on network usage conditions (such as inputs from traffic performance and long-term traffic patterns (e.g., weekdays, end of the month, banking, and public holidays)). These schedules are then used to create schedules for specific locations (e.g., shopping malls, airports, factories, schools, universities, highways, stadiums, etc.) that have been trained over a period of time.

[0173] Digital twins can also leverage scheduling data (e.g., airport flight schedules, football match schedules, etc.) to improve multiple different instruction sets and generate dynamic performance patterns that serve the needs of the network.

[0174] When a flight arrives, facial recognition may need to be performed on passengers (e.g., at passport control). This may require transmitting large amounts of data over the access network and may therefore require a temporary increase in the capacity used by the UE to perform facial recognition.

[0175] The digital twin can send an updated schedule table (including one or more instruction sets) to the L1 scheduling framework, and the new instruction sets can be implemented during a marked time period (e.g., a time period defined using start and end times).

[0176] Digital twins can be continuously updated based on feedback from the network. The RIC / SMO can use the updated model to continuously improve one or more instruction sets, replacing the instructions sent to the scheduler. Therefore, L1 scheduling parameters can be updated based on network usage to provide an improved power-to-performance tradeoff, thereby improving subscriber satisfaction.

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

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

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

[0180] 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), and the QoS requirements of each UE. However, the basic scheduling parameters (which are applied to all UEs) are typically static and fixed.

[0181] In contrast, the proposed method simulates the scheduling table by using models of hardware and environment, providing the network with the ability to modify the scheduling table based on specific environments.

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

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

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

[0185] This model can be an AI model. It can be trained using training data.

[0186] Using the model to simulate an instruction set may include using the model to simulate multiple different candidate instruction sets, obtaining one or more corresponding performance metrics for each candidate instruction set, and selecting a modified instruction set from the multiple candidate instruction sets based on the performance metrics.

[0187] Using a model to simulate an instruction set can include estimating the time taken for each of a number of instructions implemented by one or more physical hardware components.

[0188] A description of the physical hardware can be copied into the model. This model can then be used to simulate the time it takes to execute a specific instruction. For example, the model can be used to simulate how long it takes to move data from memory.

[0189] It allows for actual hardware measurements, which can then be used to train the model.

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

[0191] Chipset;

[0192] CPU;

[0193] GPU;

[0194] Computer memory;

[0195] Data storage device;

[0196] Networking components; and

[0197] Acceleration element.

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

[0199] Network usage conditions include environmental conditions, which include one or more of the following:

[0200] Number of subscribers

[0201] traffic density,

[0202] The direction of user mobility

[0203] The speed of gathering

[0204] Interference measurement, and

[0205] Signal strength.

[0206] The method may also include training the model using network usage data and / or physical hardware performance data (e.g., data indicating the time spent on each of a plurality of instructions implemented by one or more physical hardware elements).

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

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

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

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

[0211] Network usage conditions can correspond to time points in the repetitive scheduling table. Implementing a modified instruction set can include implementing the modified instruction set according to a schedule, such that the modified instruction set is implemented at the time corresponding to the time point in the repetitive scheduling table.

[0212] In other words, the network conditions for implementing the schedule table at that time can be aligned with the network conditions used to train the model (i.e., the model that simulates the modified instruction set against its own data).

[0213] Network needs can vary based on recurring patterns. For example, in a shopping mall, it might be quieter in the morning and require less capacity. During lunchtime, the food court's capacity might increase. When school ends, the children's area might become busier, and its capacity might increase. Schedules can be adapted based on weekdays / weekends, public holidays, school holidays, etc.

[0214] Network usage conditions can be used to train the model according to the network's needs. This model can then be used to simulate modified instructions to improve upon them (e.g., to provide optimal output based on performance metrics such as efficiency and throughput). Modified instructions can be provided to a dynamic L1 scheduler based on the trained sequence.

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

[0216] The method may also include dynamically adjusting the instruction set based on network usage data.

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

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

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

[0220] RAN can be an open RAN.

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

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

[0223] O-DU may include a scheduler.

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

[0225] The controller can be a non-real-time RAN intelligent controller (non-RT RIC).

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

[0227] 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.

[0228] It also provides a controller that can be configured to execute any of the methods described above.

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

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

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

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

[0233] Figure 3 The illustration shows a timing diagram based on a specific example.

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

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

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

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

[0238] 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 a mechanism for feeding environmental data and network usage back to the RAN for modifying the scheduling table. However, if network usage data and / or network usage conditions are available to the network, the proposed method can be implemented in non-open RAN networks.

[0239] Prior to Open RAN, mobile networks were built by a few vendors, with hardware and software tightly coupled. Interoperability between equipment from different vendors was limited, and this arrangement resulted in limited flexibility and innovation. Open RAN aims 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.

[0240] As described above, Open RAN systems decouple the hardware and software in a RAN network, allowing hardware and software components to be provided separately. To achieve this, the Open RAN Alliance has provided new standards for the interaction between the hardware and software components of an Open RAN system (the term "O-RAN" generally refers to the standards specified by the Open RAN Alliance).

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

[0242] De-aggregation;

[0243] Decouple HW from SW;

[0244] Open ecosystem;

[0245] Open interfaces; and

[0246] Intelligent management.

[0247] Open RAN enables interoperability of hardware and software components from different vendors. In doing so, Open RAN also provides resilience to MNOs by promoting vendor diversity within 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 network disruption.

[0248] Open RAN also offers potential energy efficiency improvements, for example, by flexibly providing hardware to meet network requirements.

[0249] Open RAN implements function block decoupling, where baseband processing functions are separated into different blocks, allowing for contributions and innovation from various vendors. For interoperability to be achieved, 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 and aggregating RAN functions into software-based components that can be hosted on different processor architectures introduces interoperability challenges while managing and orchestrating these functions.

[0250] 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 (e.g., O-RUs, O-DUs, and O-CUs) required to support network function deployments, which are implemented in software applications running on the cloud platform hardware.

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

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

[0253] In the second embodiment, trained AI models of the hardware and environment (referred to as digital twins) are used for advance planning and scheduling to enhance the performance of the hardware platform.

[0254] Figure 2 The illustration shows a schematic diagram of a system according to a specific example of the first embodiment. Figure 2 The functional elements illustrated in the figure are described below.

[0255] 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.

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

[0257] 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.

[0258] Network usage data may be 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.

[0259] 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.

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

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

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

[0263] Step 2: Send the modified scheduler instruction set (SI-a) to the L1 scheduler file.

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

[0265] Step 4: The timer is set to off.

[0266] 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).

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

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

[0269] 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.

[0270] 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.

[0271] Network usage data is provided to the RIC from a sensing platform (e.g., an ISAC platform).

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

[0273] 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 improve it.

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

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

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

[0277] 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). Based on environmental requirements (such as those interpreted from network usage data), an optimized L1 scheduler instruction set can be created for a specified time period.

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

[0279] Additionally, network operators may request new scheduler instruction sets for new subscriber applications (e.g., via RIC applications) within another specified time period.

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

[0281] 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.

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

[0283] 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.

[0284] Network usage conditions are 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 the RF coverage model.

[0285] 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.

[0286] Digital twins are used to model the L1 scheduler instruction set using one or more physical hardware components on which the scheduler is implemented. Network usage conditions (network statistics (e.g., from RIC and / or SMO); ISAC sense data; and RF coverage data from the RF coverage model) are fed to the digital twin to obtain one or more predicted performance metrics.

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

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

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

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

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

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

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

[0294] 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).

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

[0296] Figure 7 The illustration shows a schematic diagram of data flow in a system according to a specific example, based on the first embodiment and the second embodiment.

[0297] In a 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 an RF coverage model.

[0298] Network usage data can include airport flight schedules for takeoffs and landings.

[0299] 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 timers can also be provided to the scheduler.

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

[0301] Step 1: Receive network usage data, such as sensor data, RF changes, or operator or enterprise customer databases (e.g., airport flight schedule takeoff / landing data). Network usage data is received by the near-RT RIC. Network usage data may include requests for or indications of a need for temporary capacity increases. For example, high computation may be required within the next 12 minutes of a flight arriving at immigration / customs. In another example, the duration of the high computation requirement may be only a few seconds (e.g., gaming, drone video capture) or a few milliseconds (e.g., as requested by robots in industry or ambulances / home health equipment).

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

[0303] Step 3: The timing marker is set with a specified start / stop time (with instant response request).

[0304] Step 4: Receive feedback from the modified scheduling table to further adapt to the RIC strategy. Closed-loop control of chipset performance is implemented using the RIC / SMO / ISAC / RF model.

[0305] In a second embodiment, network usage data is provided to a model of one or more physical hardware elements on which a scheduler (digital twin) 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.

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

[0307] 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 timers can also be provided to the scheduler for each modified instruction set.

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

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

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

[0311] Step 3: The timing marker is determined by the digital twin or a request from the RIC policy (e.g., morning / evening peak hours, weekends, bank holidays, etc.). This start / stop time using the digital twin may involve longer time frames and is not an instantaneous response time (compared to the first embodiment).

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

[0313] Step 5: A hardware model (digital twin) is used to modify the instruction set and improve it based on additional network usage data collected during the implementation of the modified instruction set. Different modified instruction sets can be created and implemented based on repeating schedules to account for macro network changes and better serve UEs connected via the access network.

[0314] 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, and 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.

[0315] For example, regarding redundancy, in the case of the server mentioned in this application, this could actually be a pair of servers (a primary server and a failover server).

[0316] When the term "network entity" is used in this application, those skilled in the art will understand that a network entity can actually be provided by multiple geographically distributed servers.

[0317] 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 types of 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.

[0318] While the examples above are described with reference 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 DL and SC-FDMA in UL. LTE-A is an evolution of 3GPP LTE. 3GPP NR employs 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 is applied 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 the 3GPP NR system, aspects of the present invention that are not specific to 3GPP NR are also 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).

[0319] Examples can be implemented on any suitable data processing device such as a personal computer, laptop, mobile phone, server, virtual machine, etc. For the 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 appreciate, 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.

[0320] It will be understood that the functions mentioned above 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 for execution 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. Each method step implemented in the flowcharts included herein or in the method steps described above can be implemented by a corresponding module. Furthermore, multiple method steps implemented in the flowcharts included herein or described above can be implemented together by a single module.

[0321] Any method described herein can be implemented as computer software or a "computer program". The computer program can be configured to control a network entity (e.g., a server or group of servers) to perform any method according to this disclosure. 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 one or both of a transmitter and a receiver.

[0322] It also provides storage 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, programs, modules, object methods, object implementations, executable applications, applets, service programs, 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 broadcasting, communication links between two or more computers, etc.

[0323] Unless otherwise stated, each feature disclosed in this specification may be replaced by an alternative feature serving the same, equivalent, or similar purpose. Therefore, unless otherwise stated, each disclosed feature is merely one example of an equivalent or similar feature in a general series.

[0324] As used herein (including in the claims), unless the context otherwise indicates, the singular form of a term is to be construed as including the plural form, and vice versa. For example, unless the context otherwise indicates, singular references (such as “a” or “an” (such as a UE, network entity, server, or cell)) herein (including in the claims) 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 “comprising,” “including,” “having,” and “containing,” as well as variations of these words (e.g., “comprising” and “containing” or similar), mean “comprising” and are not intended to (and will not) exclude other components.

[0325] The use of any and all example or exemplary language (“e.g.,” “such as,” “for example,” and similar language) provided herein is intended merely 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 essential to the practice of the invention.

[0326] 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 an intermediary step.

[0327] All aspects and / or features disclosed in this specification can be combined in any combination, except for combinations in which at least some of such features and / or steps are mutually exclusive. As described herein, there may be specific combinations of further beneficial aspects, such as determining a set of compensation parameters and applying the set of compensation parameters to the 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 alone (not in combination).

[0328] Methods for manufacturing and / or operating any device disclosed herein are also provided. These methods may include steps of providing each disclosed feature and / or configuring or using the respective feature for its claimed functionality.

Claims

1. A method for scheduling data transmission in a radio access network, wherein the radio access network includes a scheduler configured to orchestrate data communication between one or more base stations and multiple user equipments (UEs) according to a set of instructions, the method comprising: The instruction set is simulated using models of one or more physical hardware components on which the scheduler is implemented and network usage conditions to obtain one or more predicted performance metrics; Modify the instruction set based on one or more predicted performance metrics; and A modified instruction set is implemented such that the scheduler is configured to orchestrate data communication between the one or more base stations and the plurality of UEs according to the modified instruction set.

2. The method of claim 1, wherein simulating the instruction set includes simulating a plurality of different candidate instruction sets using the model, obtaining one or more corresponding performance metrics for each candidate instruction set, and selecting a modified instruction set from the plurality of candidate instruction sets based on the performance metrics.

3. The method of claim 1 or claim 2, wherein simulating the instruction set using the model includes estimating the time taken for each of a plurality of instructions to be implemented by the one or more physical hardware elements.

4. The method according to any one of the preceding claims, wherein the one or more physical hardware elements comprise one or more of the following: Chipset; CPU; GPU; Computer memory; Data storage device; Networking components; and Acceleration element.

5. The method according to any one of the preceding claims, wherein the network usage conditions include environmental conditions, the environmental conditions including one or more of the following: Number of subscribers traffic density, The direction of user mobility The speed of gathering Interference measurement, and Signal strength.

6. The method according to any one of the preceding claims further includes using network usage data and / or physical hardware performance data to train the model.

7. The method of claim 6, wherein the network usage data includes one or more of the following: Network data received from network functions, controllers, and / or management platforms; Sensing data; and RF coverage data.

8. The method according to any one of the preceding claims, wherein the network usage conditions correspond to time points in the repeat schedule table, wherein implementing the modified instruction set includes implementing the modified instruction set according to a schedule such that the modified instruction set is implemented at the time corresponding to the time point in the repeat schedule table.

9. The method according to any one of the preceding claims, further comprising: Receive real-time network usage data. Implementing the modified instruction set includes selecting the modified instruction set based on the real-time network usage data.

10. The method of claim 9, further comprising dynamically adjusting the instruction set based on the network usage data.

11. The method according to any one of the preceding claims, wherein the instruction set comprises a plurality of parameters, the plurality of parameters comprising one or more of the following: Subcarrier spacing; Symbol duration.

12. The method according to any one of the preceding claims, wherein the RAN is an open RAN, the open RAN comprising: One or more network function deployments include an Open Distributed Unit (O-DU), wherein the O-DU includes the scheduler; as well as A controller configured to perform steps of simulating the instruction set and modifying the instruction set.

13. The method of claim 12, wherein the controller is a non-real-time RAN intelligent controller (non-RTRIC).

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

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

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

Images