Managing resource usage in radio access network

Abstract

According to an aspect, a computer-implemented method of managing resource usage in a radio access network (RAN) of a communication network is provided. One or more user equipments (UEs) communicate using the RAN. The method comprises: receiving (701) a traffic profile for traffic of the one or more UEs, the traffic profile being received from the UE and / or a server connected to the communication network via application layer communication, the traffic profile relating to requirements for one or more Quality of Service (QoS) flows of the one or more UEs; monitoring (703) performance of one or more cells in the RAN; determining (705) a change in connectivity of the one or more UEs to the RAN and / or a change in one or more QoS flows based on the monitored performance and the received traffic profile; and sending (707) a control signal to the RAN to validate the determined change.

Description

Technical Field

[0001] The present disclosure relates to managing resource usage in a Radio Access Network (RAN) of a communication network. Background Art

[0002] An ecosystem of industrial (non-3GPP) alliances and standardization organizations has been established, specifying industrial applications such as automation, logistics, and processing, and defining the associated protocols and parameters. One such organization is the OPC Foundation. These industrial applications communicate according to these specifications. For the industrial automation ecosystem, communication via 3GPP New Radio (NR) is just one of many supporting technologies, comparable to wired Ethernet, WiFi, Bluetooth, or WirelessHeart. Therefore, 3GPP is just another communication system that Industrial Internet of Things (IIoT) applications (apps) can choose to use within the enterprise IT domain. In this regard, 3GPP systems should interoperate with IIoT apps at the interface level, both for the user plane and for signaling required Quality of Service (QoS) parameters.

[0003] In the current solution, IIoT apps do not signal any QoS parameters to the 3GPP system, but instead apply static subscription-based QoS parameters. This allows for traffic differentiation between different user equipment (UEs), but it does not allow for differentiation between the criticality of different IIoT apps using different UEs or different QoS flows within a UE.

[0004] In current industry deployments, it's impossible for the 3GPP Radio Access Network (RAN) to obtain (or receive) detailed information about the needs of IIoT applications. Currently, core network functions (NFs) make assumptions about application requirements, for example based on subscription attributes or through business analysis, and map these assumptions to 3GPP-defined fifth-generation (5G) QoS index (5QI) parameter sets. These assumptions are then used by the RAN to establish, modify, and monitor QoS flows. This means that much of the detailed and valuable information that would be useful for optimizing RAN resource scheduling is not available to RAN nodes.

[0005] Figure 1The figure shows nodes / units present in an existing 3GPP system that can be used by an IIoT application. A user equipment (UE) 102 can run or execute an IIoT application 104. UE 102 is connected to a RAN 105 of a 3GPP network via a distributed unit (DU) 106. DU 106 is connected to a centralized unit (CU) 108, and CU 108 is connected to one or more network function (NFs) 110 in a core network (CN). Core NFs 110 are connected to an enterprise IT domain 112, which runs or executes an IIoT application 114. As described above, core NFs 110 make assumptions about the application's requirements, for example based on subscription attributes or through business analysis, and map these assumptions to 5QI parameter sets. Core NFs 110 then apply the subscription-based QoS profile to IIoT application 114. Summary of the Invention

[0006] Currently, scarce radio access network (RAN) resources (spectrum) are shared among all UEs based on 5QI values ​​and some priority values ​​provided by the core network (CN) to the RAN. However, when resource usage is extremely high, service for all UEs may decline because the RAN nodes are unaware of application criticality and priority. In such situations (i.e., where time-critical and / or mission-critical services may fail), resources must be provided to UEs carrying traffic only when the UE is actually performing a time-critical and / or mission-critical service.

[0007] At the same time, a device (UE) can serve multiple use cases via several QoS flows. The RAN is unaware of the criticality of a device's QoS flows and cannot optimally utilize or schedule radio resources. Furthermore, the core network lacks this detailed information and cannot provide it to the RAN. As a result, resources are either wasted due to unnecessary resource reservations, or too few resources are allocated to high-priority QoS flows, and these flows fail to meet application expectations.

[0008] The technology described herein provides for a UE, server (or other type of computer) connected to a network, or an industrial application (IIoT APP) running on a UE or server / computer to send its service profile (in the industrial definition) to a RAN resource management node, optionally in addition to the optional 5QI value selected during QoS flow setup. Thus, the service profile is sent to the RAN resource management node via application layer communication.

[0009] Based on the received (industrial) traffic profile, the RAN resource management node can manage the radio resources in an optimized or more optimized way.The application / UE / server can dynamically update the profile and request the service characteristics it really needs at a given time.

[0010] The RAN resource management node can instruct or command the RAN to prioritize radio resources among one or more UEs under its control. For example, the UE can be moved to a cell with more radio resources (e.g., a mmWave cell), specific QoS flows of one or more UEs can be moved to another cell, QoS flows can be downgraded and the corresponding applications can be informed, one or more new QoS flows can be added, or a low-priority QoS flow of a UE or the UE itself can be released to free up resources for high-priority flows / UEs.

[0011] With the techniques described herein, RAN resource management nodes in 5G / sixth generation (6G) networks can (better) decide which QoS flows and UEs should be prioritized in situations where radio resources are scarce and / or congested.

[0012] The UE / server / IIoT app can send its native service profile to the RAN resource management node, so that the available level of detail about services (e.g., services generated / used by the application ("application services")) has a higher granularity compared to 5QI. The UE / server / IIoT app can also dynamically modify the profile, thereby enabling the RAN resource management node to provide dynamic and optimized radio resource utilization.

[0013] According to a first aspect, a computer-implemented method for managing resource usage in a RAN of a communications network is provided. One or more UEs communicate using the RAN. The method comprises receiving, via application layer communication, a service profile for services of the one or more UEs from the UEs and / or a server connected to the communications network. The service profile relates to requirements for one or more QoS flows of the one or more UEs. The method further comprises monitoring performance of one or more cells in the RAN; determining, based on the monitored performance and the received service profile, a change in connectivity of the one or more UEs to the RAN and / or a change in one or more QoS flows; and sending a control signal to the RAN to effect the determined change.

[0014] According to a second aspect, there is provided a computer program product comprising a computer-readable medium having computer-readable code embodied therein, the computer-readable code being configured to, when executed by a suitable computer or processor, cause the computer or processor to perform a method according to the first aspect or any embodiment thereof.

[0015] According to a third aspect, a RAN resource management node configured to manage resource usage in a RAN of a communications network is provided. One or more UEs communicate using the RAN. The RAN resource management node is configured to receive, via application layer communication, a service profile for services of the one or more UEs from the UEs and / or a server connected to the communications network. The service profile relates to requirements for one or more QoS flows of the one or more UEs. The RAN resource management node is further configured to monitor performance of one or more cells in the RAN; determine, based on the monitored performance and the received service profile, a change in connectivity between the one or more UEs and the RAN and / or a change in one or more QoS flows; and send a control signal to the RAN to effect the determined change.

[0016] According to a fourth aspect, a RAN resource management node for managing resource usage in a RAN of a communication network is provided, comprising a processor and a memory. One or more UEs communicate using the RAN. The memory contains instructions that can be executed by the processor, whereby the RAN resource management node is operable to receive a service profile for a service of one or more UEs from the UE and / or a server connected to the communication network via application layer communication. The service profile relates to requirements for one or more QoS flows of the one or more UEs. The RAN resource management node is further operable to: monitor the performance of one or more cells in the RAN; determine changes to the connectivity of one or more UEs to the RAN and / or changes to one or more QoS flows based on the monitored performance and the received service profile; and send a control signal to the RAN to effect the determined changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which:

[0018] Figure 1 Shows nodes / units existing in the existing 3GPP system that can be used by IIoT applications;

[0019] Figure 2 shows the implementation of the technology described herein in a 3GPP system;

[0020] Figure 3 is a signaling diagram illustrating signaling in the system when receiving or updating a service profile;

[0021] Figure 4 is a flow chart illustrating a method of operating a RAN resource management node when receiving or updating a service profile;

[0022] Figure 5 is a signalling diagram illustrating signalling in the system when receiving new performance data for a cell;

[0023] Figure 6 is a flow chart illustrating a method of operating a RAN resource management node when receiving new performance data for a cell;

[0024] Figure 7 is a flow chart illustrating a method of managing resource usage in a RAN according to the techniques described herein;

[0025] Figure 8 is a block diagram of a RAN resource management node according to some embodiments; and

[0026] Figure 9 is a block diagram illustrating a virtualization environment in which functionality implemented by some embodiments may be virtualized. DETAILED DESCRIPTION

[0027] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided as examples to convey the scope of the subject matter to those skilled in the art.

[0028] As described above, a RAN resource management node is provided that receives a service profile for one or more UEs via application layer communications. Based on the service profile and the performance of one or more cells in the network, the RAN resource management node can manage radio resources in an optimized or more optimized manner. While the RAN resource management node is described with reference to an Industrial IoT scenario using a non-public / private network, it will be understood that the RAN resource management node can be used in a public network (e.g., a Public Land Mobile Network (PLMN)), a slice of a public network, a terrestrial network, or a non-terrestrial network. Furthermore, the use of the RAN resource management node is not limited to the Industrial IoT scenario, and those skilled in the art will recognize other application scenarios in which the RAN resource management node can be used.

[0029] Figure 2 An exemplary implementation of a RAN resource management node in a 3GPP system (and in particular, a 5G NR system) is shown. Figure 2 3GPP system architecture and Figure 1 The 3GPP system architecture shown is similar and Figure 1 and Figure 2 The same components / nodes / entities in the 3GPP network are given the same reference numerals. Thus, one or more UEs 202 can run or execute IIoT APP 204. UE 202 is connected to RAN 105 of a 3GPP network, wherein RAN 105 includes one or more DUs 106 connected to one or more CUs 108. CU 108 is connected to one or more NFs 110 in the CN.

[0030] existFigure 2 In the illustrated embodiment, an enterprise IT domain 212 (collectively referred to as "server 212") is connected to the core NF 110, and the server 212 may also run or execute an IIoT application 214. The server 212 is external to the core NF 110 and may be external to the communication network itself. In this illustrated embodiment, a UE 202 may communicate with the server 212, or more specifically, an IIoT application 204 running on the UE 202 may communicate with the IIoT application 214 running on the server 212. Therefore, communication between the UE 202 and the server 214 occurs via the RAN 105 and the associated core NF 110.

[0031] exist Figure 2 In an alternative embodiment to the illustrated embodiment, the enterprise IT domain / server 212 running or executing the IIoT APP 214 may be provided with wireless communication means to enable the server 212 to access the RAN 105 and communicate via the RAN 105. In this case, the server 212 is actually another UE 202. In this embodiment, the UEs 202 can communicate with each other and / or with the server 212 (or more specifically, the IIoT application 204 running on the RAN 105 can communicate with the IIoT application 204 running on another UE 202 or the IIoT application 214 running on the server 212). Therefore, communications between the UEs 202 and / or between other UEs 202 and the server 214 are via the RAN 105 and the associated core NF 110.

[0032] exist Figure 2 In another alternative embodiment to the illustrated embodiment, there is no enterprise IT domain / server 212 running or executing the IIoT APP 214. In this embodiment, the UEs 202 can communicate with each other (or more specifically, the IIoT application 204 running on the UE 202 can communicate with the IIoT application 204 running on another UE 202). Therefore, the communication between the UEs 202 is via the RAN 105 and the relevant core NF 110.

[0033] exist Figure 2 , a RAN resource management node 220 is shown that is capable of interacting with the UE 202 and / or the server 212 (if present) and the RAN 105 (i.e., the DU 106 and / or the CU 108 in this embodiment). The RAN resource management node 220 is used to manage resource usage in the RAN 105 based on a traffic profile received from the UE 202 and / or the server 212.

[0034] The traffic profile may relate to traffic or traffic requirements between the UE 202 and the server 212. Additionally or alternatively, the traffic profile may relate to traffic or traffic requirements between different UEs 202, and in particular, traffic sent between the UEs 202 via the RAN 105.

[0035] While the IIoT applications 204 and / or 214 are described herein as being responsible for managing and sending traffic profiles to the RAN resource management node 220, it will be understood that the UE 202 and / or server 212 themselves may be configured (e.g., in terms of hardware, firmware, software, or underlying operating system) to manage and send traffic profiles to the RAN resource management node 220, and that a separate or distinct IIoT application is not required.

[0036] Although Figure 2 The following description of the operation of the RAN resource management node 220 relates to a RAN 105 including one or more CUs 108 and one or more DUs 106, but it will be understood that the RAN resource management node 220 may be used with a RAN 105 that does not employ a distributed RAN architecture, and in those embodiments, the RAN resource management node 220 may communicate with base stations (e.g., eNBs and / or gNBs) rather than the DUs 106 and CUs 108. In other embodiments, the RAN resource management node 220 may be capable of communicating with elements in a distributed RAN architecture as well as conventional (non-distributed) base stations.

[0037] As used herein, UE 202 includes or refers to a device capable of, configured to, arranged to, and / or operable to wirelessly communicate with a node in the RAN 105, other UEs 202, and / or with a server 212 via the RAN 105 and the CN 110. Examples of wireless devices / UEs include, but are not limited to, smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, portable computers, portable embedded devices (LEEs), portable-mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), in-vehicle or vehicle embedded / integrated wireless devices, etc. Other examples include any UE identified by 3GPP, including narrowband Internet of Things (NB-IoT) UEs, machine type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0038] The wireless device / UE 202 may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE 202 may not necessarily have a "user" in the sense of a human user who owns and / or operates the associated device. Instead, the UE 202 may represent a device that is intended for sale to or operated by a human user but may not, or may not initially, be associated with a specific human user (e.g., a smart sprinkler controller or smart sensor used to monitor machinery in a factory). Alternatively, the UE 202 may represent a device that is not intended for sale to or operated by an end user but may be associated with or operated for the benefit of a user (e.g., a smart electricity meter).

[0039] When UE 202 is in the form of an IoT device, the UE may be a device used in one or more application areas including, but not limited to, urban wearable technology, expanded industrial applications, and healthcare. Non-limiting examples of such IoT devices include devices that are or are embedded in connected refrigerators or freezers, TVs, connected lighting, electric meters, robotic vacuum cleaners, voice-activated smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electronic door locks, connected doorbells, heat pump-like air conditioning systems, autonomous vehicles, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smart watches, fitness trackers, head-mounted displays for augmented reality (AR) or VR, wearable devices for tactile or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical equipment (such as heart rate monitors or teleoperated surgical robots). In addition to other components typically found in a UE 202 that enable the UE 202 to communicate with the RAN 105 , a UE in the form of an IoT device may also include circuitry and / or software depending on the intended application of the IoT device.

[0040] As another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or a network node. In this case, the UE may be an M2M device, which in the 3GPP context may be referred to as an MTC device. As a specific example, a UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle (e.g., a car, bus, truck, ship, or airplane) or other device capable of monitoring and / or reporting its operational status or other functions associated with its operation.

[0041] The RAN 105 (and specifically, the base stations and / or DUs 106 within the RAN 105) facilitate direct or indirect connectivity for the UE 202 via one or more wireless connections. As used herein, a base station or DU refers to a device capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or devices in a telecommunications network. Examples of base stations include, but are not limited to, access points (APs), Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs).

[0042] The server 212 may be owned or under the control of an entity other than the operator or provider of the RAN 105 and / or the core NF 110. The server 212 may host various applications to provide one or more services, including the IIoT application 214. The server 212 may be located at a location remote from the RAN 105 and / or the core NF 110. Alternatively, the server 212 may be in the same location or premises as the RAN 105 and / or the core NF 110, for example in an IIoT implementation where the RAN 105 and the core NF 110 are part of a non-public / private network provided for an industrial environment.

[0043] Return to Figure 2 , a new entity, namely, RAN resource management node 220 (also referred to as RAN resource manager (RAN-RM) 220), receives an (IIoT) service profile from one or more of the Industrial IoT applications 204, 214. As described above, the IIoT application can reside on the UE 202, for example as an embedded software (SW) entity, or the IIoT application can reside on a server 212 in the enterprise IT domain. In either case, communication with the RAN-RM 220 is non-real-time and can use any communication path established in the application layer. For example, if the service profile resides on the UE 202, the communication path can be a default protocol data unit (PDU) session, or if the service profile resides on the server 212, the communication path can be an Internet Protocol (IP) connection.

[0044] The functions / operations performed by the RAN-RM 220 may include any of the following:

[0045] 1) Store and analyze service profiles of one or more (or all) UEs 202. Unsupported profile attribute values ​​may be rejected for IIoT APPs 204, 214 providing service profiles.

[0046] 2) Performance data may be collected, for example, periodically from one or more (or all) cells in the communication network and / or from one or more (or all) DUs 106. This performance data may be analyzed, and, for example, the RAN-RM 220 may calculate a parameter representing the cell load, referred to herein as the weighted cell load (WCL). The RAN-RM 220 may also receive events or information regarding the establishment, modification, and / or release of QoS flows from the CU 108.

[0047] 3) When a new or modified traffic profile is received, and / or when a new WCL is calculated, the RAN-RM 220 triggers and evaluates the resource analysis algorithm. The algorithm determines:

[0048] a. whether a specific QoS flow (respectively, a data radio bearer (DRB)) needs to be moved to another cell; or

[0049] b. Whether the UE needs to move to a different cell, or

[0050] c. Whether a low priority QoS flow or a low priority UE must be disconnected. In this case, the RAN-RM 220 may inform the relevant IIoT APP 204, 214 or node (UE 202 or server 212) of the disconnection.

[0051] As described above, the IIoT APP 204 / 214 sends a service profile to the RAN-RM 220 via application layer communication. The service profile relates to the requirements of one or more QoS flows of the UE 202. The service profile can be sent by the UE via Figure 2 The application layer service profile interface 250 in the example embodiment of the present invention is provided, and / or provided from the server 212 via the application layer service profile interface 252.

[0052] The RAN-RM 220 also has an interface 254 for receiving performance (PM) data from the RAN 105 (e.g., from the DU 106 and the CU 108). The RAN-RM 220 also has an interface 256 with the RAN 105 (e.g., with the DU 106 and / or the CU 108) that enables the RAN-RM 220 to send commands or instructions to the RAN 105 to move, modify, add, or release QoS flows or UEs.

[0053] The core NF 110 has a QoS monitoring interface 258 with the RAN 105 (eg, the CU 108) for receiving information about the QoS of existing QoS flows in the network.

[0054] In some embodiments, the traffic profile may be non-deterministic. In alternative embodiments, the traffic profile may be deterministic. Both types of traffic profiles may include an indication of the criticality of the application of the associated QoS flow, which the RAN-RM 220 uses to determine the importance and / or priority of a particular QoS flow compared to other QoS flows.

[0055] The traffic profile may include additional or other types of information related to the QoS flow and / or the UE 202 .

[0056] Specifically, the non-deterministic service profile may include an indication of any one of the following items:

[0057] a) the criticality of the QoS flow or the service of a specific UE (e.g. in terms of high, medium, low);

[0058] b) average data throughput (kbit / s) for uplink (UL) and / or downlink (DL); and

[0059] c) Peak data throughput in UL and DL (kbit / s).

[0060] A deterministic traffic profile may relate to UL, DL, or both, and may include an indication of any of the following:

[0061] a) the criticality of the QoS flow or the service of a specific UE (e.g. in terms of high, medium, low);

[0062] b) the periodicity type (e.g., periodic, aperiodic) of the traffic of a QoS flow or a specific UE;

[0063] c) the transmission interval of a QoS flow or a service for a specific UE (e.g., periodic (ms), aperiodic (ms));

[0064] d) Inactive periods of traffic for a QoS flow or for a specific UE (e.g., time stop, time start);

[0065] e) Jitter tolerance (ms) for QoS flows and / or specific UEs;

[0066] f) packet loss tolerance for a QoS flow and / or a specific UE (e.g., the acceptable number of consecutive packet losses); and

[0067] g) Typical packet data size (bytes).

[0068] Figure 3 It shows that when receiving or updating the service configuration file Figure 2 Specifically, Figure 3 Signaling between the DU 106, CU 108, RAN-RM 220, Core NF 110 and IIoT applications 204 / 214 is shown.

[0069] Initially, the IIoT application 204 / 214 (i.e., in the UE 202 or the server 212) sends a request 302 to the RAN-RM 220 requesting or indicating the existence of a new service profile for an existing or new QoS flow, or a change in the service profile for an existing QoS flow. The request 302 includes the new or changed service profile. Figure 3 As shown, the message 302 may be a message: “Request: Service Profile Change.” A new service profile or an updated service profile for an existing QoS flow may include new or modified attribute values.

[0070] Upon receiving a new or modified service profile, the RAN-RM 220 is triggered to execute the RAN management algorithm (as shown in step 304 "Trigger 1"). Figure 4 Let’s describe the algorithm in detail.

[0071] The algorithm can result in a decision by the RAN-RM 220 to move, modify or release QoS flows, add new QoS flows, or move or release one or more UEs 202. To make the decision of the algorithm effective, the RAN-RM 220 sends instructions or commands 306 to the CU 108 to instruct the CU 108 to add, move, modify or release QoS flows or entire UEs. The instructions or commands 306 to the CU 108 can be in any suitable format. One example of a suitable format is found in “O-RAN.WG2.A1TD-R003-v05.00”. In this Open Radio Access Network (O-RAN) architecture example, the instructions or commands 306 can be a http put / get interface with a JavaScript Object Notation (JSON) object. A JSON object for steering traffic per UE is provided below:

[0072]

[0073] After sending the instructions or commands 306 to the CU 108, the CU 108 subsequently requests the relevant DUs 106 to perform the changes. The DUs 106 acknowledge to the CU 108 that the changes have been made. The request / acknowledgement signaling between the DUs 106 and the CU 108 is shown by signals 308 in Figure 3 The CU 108 acknowledges that the commands 306 have been completed by sending an acknowledgement 310 to the RAN-RM 220.

[0074] The RAN-RM 220 can then send a reply 312 to the IIoT application 204 / 214 acknowledging that the traffic profile changes have been made effective. This reply 312 can be a new message: “Response: Traffic Profile Changes”. This reply 312 can inform the IIoT application 204 / 214 whether the requested new or changed traffic profile was met or denied, or whether an alternative traffic profile was applied. In the latter case, the IIoT application 204 / 214 can accept the alternative profile, or it can request that the alternative traffic profile be applied.

[0075] Depending on the changes to the QoS flows that were made effective by the CU 108, the CU 108 can send a notification 314 to the core NF 110 indicating that QoS changes have been made to specific QoS flows.

[0076] Figure 4 is a flowchart illustrating a method of operating a Radio Access Network Resource Management node (RAN-RM) 220 when receiving or updating traffic profiles. The method is Figure 3 The method is an implementation of step 304 in

[0077] In step 402, a new / modified traffic profile is received from the IIoT application 204 / 214. The new / modified traffic profile relates to a new or existing QoS flow.

[0078] In step 404, RAN-RM 220 calculates a parameter called weighted cell load (WCL) of the primary cell (PCell) from measurements of cells in the network and compares the WCL to a threshold representing a target WCL value for the PCell.

[0079] The WCL is a parameter calculated based on the resources requested by the QoS flow's traffic profile and the current utilization of the dimensional resources. The WCL can be determined separately for uplink (UL) and downlink (DL) traffic directions for each cell. The WCL value can be recalculated each time an event notification is received from the CU 108 or DU 106. This event can be the availability of new performance data (also known as "performance management data" or "PM data") for the cell. Alternatively, the event can be the acceptance of a new UE connection or the establishment, modification, or release of a QoS flow in the corresponding cell of the network.

[0080] WCL can be calculated as follows. The input parameters for WCL calculation are:

[0081] • Business profile: Profile type (deterministic or non-deterministic) and attributes;

[0082] • Configuration data for each cell: configuredCellThroughput (UL / DL);

[0083] •Performance data received for each cell: measuredCellThroughput (UL / DL).

[0084] The weighting factor w is calculated using the following formula:

[0085]

[0086] And the weighted cell load is calculated using the following formula:

[0087]

[0088] as well as

[0089]

[0090] At step 404, if the calculated WCL is below the threshold, the method proceeds to step 406, where no specific action is required and a QoS flow may be set or modified in the PCell according to the received service profile. The method then proceeds to step 424, described later.

[0091] If the PCell's WCL is above the threshold, the method proceeds to step 408, where the algorithm checks whether there are other possibilities that could satisfy the requested service profile change. Specifically, it checks whether the secondary cell (SCell) is available for carrier aggregation (CA) and whether spectrum is available in the SCell for the requested QoS flow. In step 408, the UE capabilities and load level (WCL) of any eligible SCell are checked. If the WCL in the SCell is below the threshold, the method proceeds to step 410, where the SCell is utilized to perform the QoS flow setup / change.

[0092] In the event that it is determined in step 408 that no suitable SCell is available (i.e., the WCL is above the threshold), the method proceeds to step 412 and all QoS flow assignments for all UEs may then be scanned or evaluated to determine (step 414) whether there are any QoS flows that have a lower priority than the QoS flow to be established or modified according to the received service profile.

[0093] If no QoS flow with a lower priority is found, the method proceeds to step 416 where the traffic profile received in step 402 is rejected and the RAN-RM 220 notifies the IIoT application 204 / 214 accordingly.

[0094] If a UE with a lower priority QoS flow is found in step 414, then it is determined whether the identified UE has a common SCell with the UE involved in the new / modified service profile in step 418. If not, the method proceeds to step 420, where the service profile received in step 402 is rejected and the RAN-RM 220 notifies the IIoT application 204 / 214 accordingly.

[0095] If the identified UE does have a common SCell with the UE involved in the new / modified service profile, then the QoS flow for the UE is released in step 420 (e.g., by sending a suitable command or instruction to the CU 108 via the RAN-RM 220). The method then proceeds to step 410, where the RAN-RM 220 sets or changes the QoS flow using the identified SCell (e.g., by sending a suitable command or instruction to the CU 108).

[0096] Then, in step 424 , the RAN-RM 220 informs the IIoT application 204 / 214 (eg, via signal 312 ) of the release of the QoS flow and the establishment or modification of the higher priority QoS flow to which the traffic profile received in step 402 relates.

[0097] Finally, in step 426, the WCL may be recalculated based on measurements of the cell's performance after the QoS flows were reconfigured.

[0098] Figure 5 is a signaling diagram illustrating the signaling in the system when receiving new performance (PM) data of a cell. Specifically, Figure 5 The signaling between DU 106, CU 108, RAN-RM 220, Core NF 110 and IIoT applications 204 / 214 is shown, similar to Figure 3 .

[0099] Initially, an event occurs in one or both of the DU 106 and CU 108. Specifically, new performance data / measurements are available for one or more cells in the network. The DU 106 and / or CU 108 forwards the PM data to the RAN-RM 220 via signals 502 and 504, respectively.

[0100] Upon receiving new PM data, RAN-RM 220 is triggered to execute the RAN management algorithm (as shown in step 506 "Trigger 2"). Figure 6 Let’s describe the algorithm in detail.

[0101] In addition to or as an alternative to the events represented by signals 502 and 504, QoS monitoring / measurement may be performed in the core NF 110 and the QoS measurement data may be sent to the RAN-RM 220 via signal 508. The RAN-RM 220 may analyze the QoS data (step 510) and determine that a RAN management algorithm should be initiated (as shown in step 512 "Trigger 2"). This algorithm is similar to the one described below with reference to Figure 6 The algorithm described in detail is the same.

[0102] The algorithm may result in the RAN-RM 220 making a decision to move, modify, or release a QoS flow, add a new QoS flow, or move or release one or more UEs 202. To effect the algorithm's decision, the RAN-RM 220 sends an instruction or command 514 to the CU 108 instructing the CU 108 to add, move, modify, or release a QoS flow or an entire UE. The CU 108 then requests the relevant DU 106 to perform the change. The DU 106 confirms to the CU 108 that the change has been made. The request / confirmation signaling between the DU 106 and the CU 108 is carried out in Figure 55. The CU 108 confirms that the command 306 has been completed by sending an acknowledgment 518 to the RAN-RM 220.

[0103] The RAN-RM 220 may then send a reply 520 to the IIoT application 204 / 214 confirming that the service profile change has taken effect. This reply 520 may be a new message: "Response: Service Profile Change." This reply 520 may inform the IIoT application 204 / 214 whether the requested new or changed service profile is satisfied or rejected, or whether an alternative service profile is applied. In the latter case, the IIoT application 204 / 214 may accept the alternative profile, or it may request that the alternative service profile be applied.

[0104] Depending on the changes to the QoS flows effected by the CU 108, the CU 108 may send a notification 522 to the core NF 110 indicating that a QoS change has been made to the particular QoS flow.

[0105] Figure 6 is a flow chart illustrating a method of operating a RAN resource management node when receiving new performance data for a cell. The method is Figure 5 Implementation of step 506 or 512 and including aspects of signals 514 and 520.

[0106] In step 602 , new / modified PM data is received from the DU 106 / CU 108 .

[0107] In step 604, the RAN-RM 220 calculates the WCL of the cell based on the PM data. The new WCL value is used to evaluate the current QoS flow allocation in the network.

[0108] In step 606, the calculated WCL for the QoS flow is compared to a threshold representing a target WCL value.

[0109] If no QoS flow WCL value is above the threshold, no further action is required.

[0110] However, if any QoS flow WCL is above the threshold, a priority decision is prepared by scanning and sorting all QoS flows above the threshold (i.e., in all cells exceeding the threshold) according to the priority attribute. Specifically, at step 608, the QoS flows in the cells with WCL exceeding the threshold are sorted into a list according to the priority of the QoS flows.

[0111] Then, in step 610, for the first QoS flow in the list (i.e., the QoS flow with the highest priority), a determination is made as to whether there is an alternative cell for the QoS flow, where the WCL of the cell is below the threshold. If such a cell (i.e., a cell with a smaller load) is available, the method proceeds to step 612, where a handover of the QoS flow to the cell is initiated (e.g., by sending an appropriate command or instruction 514 to the CU 108 via the RAN-RM 220).

[0112] Next, at step 614, the QoS flow with the highest priority in the sorted list is removed from the sorted list. At step 616, a determination is made as to whether the list is empty (i.e., whether all QoS flows have been evaluated). If the list is empty, the method ends at step 618.

[0113] If the list is not empty, the method returns to step 610 and operates on the remaining highest priority QoS flows in the sorted list.

[0114] If, at step 610, no candidate cell exists with a WCL below the threshold, the method proceeds to step 620, where a determination is made as to whether any active QoS flows with a lower priority exist in the candidate cell. If no lower priority QoS flows are found in step 620, then, at step 622, a determination is made to release the QoS flow being evaluated (e.g., by sending an appropriate command or instruction 514 to the CU 108 via the RAN-RM 220). The RAN-RM 220 may also notify the IIoT application 204 / 214 (e.g., via signal 520) of the release of the QoS flow. The method proceeds to step 614, where the evaluated QoS flow is removed from the sorted list.

[0115] However, if a lower priority QoS flow is found at step 620, then in step 624, a determination is made to release the lower priority QoS flow (e.g., by sending an appropriate command or instruction 514 to the CU 108 via the RAN-RM 220). The RAN-RM 220 may also inform the IIoT application 204 / 214 of the release of the QoS flow (e.g., via signal 520). The method proceeds to step 614, where the evaluated QoS flow is removed from the sorted list.

[0116] Figure 7 is a flow chart illustrating a method for managing resource usage in a RAN according to the techniques described herein. The method may be performed by the RAN resource management node 220, for example, in response to executing suitably formulated computer-readable code. The computer-readable code may be embodied or stored on a computer-readable medium (e.g., a memory chip, optical disk, or other storage medium). The computer-readable medium may be part of a computer program product.

[0117] In step 701, a service profile for a service of one or more UEs 202 is received. One or more UEs 202 are currently communicating using RAN 105 (e.g., the UEs are in connected or idle mode), or will be communicating using RAN 105. The service profile may be received from the UEs 202 via application layer communication 250. In this case, the application layer communication 250 may be via a PDU session. Additionally or alternatively, the service profile may be received from a server 212 connected to a communication network via application layer communication 252. In this case, the application layer communication 252 may be via an IP connection.

[0118] A traffic profile relates to the requirements of one or more QoS flows for one or more UEs 202. A traffic profile may relate to uplink traffic (i.e., from a UE 202 to a server 212), downlink traffic (i.e., from a server 212 to a UE 202), or both. A traffic profile need not relate to all established QoS flows and / or all UEs 202 connected to the RAN 105, and instead may relate to a subset of established QoS flows and / or a subset of UEs connected to the RAN 105. In some embodiments, a traffic profile may relate to a single QoS flow, or to a single UE 202 or a single type of UE 202 (e.g., a UE associated with a security camera, a UE associated with a machine sensor, etc.).

[0119] In some embodiments, a service profile indicates the importance and / or priority of services in one or more QoS flows and / or services of one or more UEs. The importance and / or priority may be indicated by a value or level (e.g., "high," "low," etc.). The importance and / or priority may be indicated relative to the importance and / or priority of services of other QoS flows and / or services of other UEs.

[0120] A service profile may indicate any of the types of information described above.

[0121] In some embodiments, the service profile received in step 701 is an update to a previously received service profile.

[0122] In step 703, the performance of one or more cells in the RAN 105 is monitored. In some embodiments (particularly where the method is implemented by the RAN-RM 220), step 703 may include receiving performance monitoring data from the RAN 105. The performance of the cell may be monitored in terms of the cell's data throughput.

[0123] In step 705, a change in connectivity of one or more UEs 202 to the RAN 105 and / or a change in one or more QoS flows is determined based on the monitored performance and the received traffic profile. In step 705, the change can be determined to comply or satisfy the traffic profile received in step 701.

[0124] The change determined in step 705 can be any of the following: moving a QoS flow to a different cell in the RAN 105; modifying a QoS flow; releasing a QoS flow; adding a QoS flow; moving a UE 202 to a different cell in the RAN 105; releasing a UE 202 connected to the RAN 105; and releasing or disconnecting a QoS flow or a UE 202 having a lower priority than the QoS or the UE 202 associated with the received traffic profile.

[0125] In some embodiments, the change can be determined by: calculating a load metric (e.g., a WCL) for the first cell from the measurements indicative of performance of the first cell; comparing the calculated load metric to a target load metric for the first cell; and determining whether the received traffic profile can be satisfied in the first cell based on the comparison. In some embodiments, step 705 can be performed in the manner as shown in FIG. 7A and / or as described above. Figure 4 and / or Figure 6

[0126] In a particular embodiment of step 705 (where the first cell is a PCell), if the comparison indicates that the received traffic profile cannot be satisfied in the PCell, step 705 can further include determining whether the received traffic profile can be satisfied in an SCell. If the traffic profile can be satisfied in the SCell, step 705 can include determining that the QoS flow and / or the UE 202 should be moved to the SCell.

[0127] In another particular embodiment of step 705, if the comparison indicates that the received traffic profile cannot be satisfied in the first cell, it is determined whether one or more QoS flows and / or UEs 202 connected to the first cell have a lower priority than traffic according to the received traffic profile. If there is one or more QoS flows or UEs 202 connected to the first cell having a lower priority, step 705 can decide to move these lower priority QoS flows and / or UEs 202 out of the cell, modify or release these lower priority QoS flows and / or UEs 202.

[0128] ​In step 707, a control signal is sent to the RAN 105 to effect the determined change. The control signal may be sent to any of the CU 108, one or more DUs 106, and one or more base stations.

[0129] In some embodiments, the method may further include notifying the UE 202 and / or the server 212 of the change in connectivity of the UE 202 with the RAN 105 and / or the change in the QoS flow.

[0130] In some embodiments, the communication network is a public communication network (eg, a PLMN), a slice in a communication network, a private network, a non-public network (NPN), a terrestrial network, or a non-terrestrial network.

[0131] In some embodiments, UE 202 and / or server 212 are used to execute industrial applications, such as IIoT applications. In this case, UE 202 can be regarded as an IoT UE.

[0132] Figure 8 is a simplified block diagram of a RAN resource management node 800 according to some embodiments, which may be used to implement one or more techniques described herein.

[0133] The RAN resource management node 800 includes processing circuitry (or logic) 801. It will be appreciated that the RAN resource management node 800 may include one or more virtual machines running different software and / or processes. Thus, the RAN resource management node 800 may include, be implemented in, or be implemented as one or more servers, switches, and / or storage devices, and / or may include cloud computing infrastructure running software and / or processes.

[0134] The processing circuit 801 controls the operation of the RAN resource management node 800 to implement relevant portions of the methods described herein. The processing circuit 801 may include one or more processors, processing units, multi-core processors, or modules configured or programmed to control the discovery management function 800 in the manner described herein. In a specific implementation, the processing circuit 801 may include multiple software and / or hardware modules, each of which is configured to perform or be used to perform a single step or multiple steps of the methods described herein with respect to the RAN resource management node 800.

[0135] The RAN resource management node 800 also includes a communication interface 802. The communication interface 802 is used to implement communications with other network nodes, computers, servers, and the like. For example, the communication interface 802 may be configured to send and / or receive requests, responses, information, data, signals, and the like to and from other nodes (including the UE 202, the server 212, and / or the RAN 105). The communication interface 802 may utilize any suitable communication technology.

[0136] The processing circuit 801 may be configured to control the communication interface 802 to send and / or receive requests, responses, information, data, signals, etc. to other nodes, etc., according to the methods described herein.

[0137] The RAN resource management node 800 may include a memory 803. In some embodiments, the memory 803 may be configured to store program code that can be executed by the processing circuit 801 to perform the methods described herein with respect to the RAN resource management node 800. Alternatively or additionally, the memory 803 may be configured to store any requests, responses, information, data, signals, etc. described herein. The processing circuit 801 may be configured to control the memory 803 to store such information therein.

[0138] Figure 9 is a block diagram illustrating a virtualization environment 900 in which functionality implemented by some embodiments may be virtualized. For example, the RAN resource management node 220 / 800 described herein may be implemented in the virtualization environment 900.

[0139] In this context, virtualization means creating a virtual version of an apparatus or device, which can include virtualizing hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to any of the devices described herein or their components, and involves an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functionality described herein can be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 900 hosted by one or more of the hardware nodes (e.g., hardware computing devices operating as the RAN resource management node 220). Alternatively, the RAN resource management node 220 can be fully virtualized.

[0140] Application 902 (which may alternatively be referred to as a software instance, a virtual appliance, a network function, a virtual node, a virtual network function, etc.) runs in virtualized environment 900 to implement some features, functions, and / or benefits of some embodiments disclosed herein.

[0141] Hardware 904 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein (e.g., network interfaces, input / output interfaces, etc.). The software may be executed by the processing circuitry to instantiate one or more virtualization layers 906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 908a and 908b (one or more of which may be generally referred to as VMs 908), and / or perform any of the functions, features, and / or benefits described in connection with some embodiments described herein. Virtualization layer 906 may present a virtual operating platform that appears to VMs 908 as networked hardware.

[0142] Virtual machines 908 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and can be run by corresponding virtualization layers 906. Different embodiments of instances of virtual devices 902 can be implemented on one or more of VMs 908, and the implementation can be done in different ways. In some contexts, hardware virtualization is referred to as network function virtualization (NFV). NFV can be used to unify numerous network device types onto industry-standard high-capacity server hardware, physical switches, and physical storage that can be located in data centers and customer premises equipment.

[0143] In the context of NFV, VMs 908 can be software implementations of physical machines that run programs as if they were executed on a physical, non-virtualized machine. Each VM 908 and the portion of hardware 904 that executes it (which can be hardware dedicated to that VM and / or hardware shared by that VM and other VMs in the VM stack) form a separate virtual network element. Still in the context of NFV, a virtual network function (VNF) is responsible for handling specific network functions running in one or more VMs 908 on hardware 904 and corresponds to an application 902.

[0144] Hardware 904 can be implemented in a standalone network node with general or specialized components. Hardware 904 can implement some functionality through virtualization. Alternatively, hardware 904 can be part of a larger hardware cluster (e.g., in a data center or CPE), where many hardware nodes work together and are managed by management and coordination 910, which oversees, among other things, the lifecycle management of applications 902. In some embodiments, hardware 904 is coupled to one or more radio units, each comprising one or more transmitters and one or more receivers, which can be coupled to one or more antennas. The radio units can communicate directly with other hardware nodes via one or more suitable network interfaces and can be used in conjunction with virtual components to provide a virtual node with radio capabilities, such as a radio access node or base station. In some embodiments, a control system 912 can be used to provide some signaling, which can alternatively be used for communication between hardware nodes and radio units.

[0145] While the computing devices described herein (e.g., RAN resource management node 220 / 800) may include a combination of the hardware components shown, other embodiments may include computing devices with different combinations of components. It should be understood that such computing devices may include any suitable combination of hardware and / or software necessary to perform the tasks, features, functions, and methods disclosed herein. The determinations, calculations, acquisitions, or similar operations described herein may be performed by processing circuitry that may process information by, for example, converting the acquired information into other information, comparing the acquired information or the converted information with information stored in the network node, and / or performing one or more operations based on the acquired information or the converted information and making determinations based on the results of such processing. Furthermore, while components may be depicted as a single block within a larger block or nested within multiple blocks, in reality, a computing device may include multiple distinct physical components that make up the single illustrated component, and functionality may be divided between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or functionality of a component may be divided between the processing circuitry and the communication interface. In another example, non-computationally intensive functionality of any such component may be implemented in software or firmware, while computationally intensive functionality may be implemented in hardware.

[0146] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit that executes instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuit, for example, in a hardwired manner, without executing instructions stored on a separate or discrete device-readable storage medium. In any of these specific embodiments, the processing circuit may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to the processing circuit or to other components of the computing device, but are enjoyed by the computing device as a whole and / or by the end user and the wireless network as a whole.

[0147] The foregoing merely illustrates the principles of the present disclosure. In light of the teachings herein, various modifications and variations of the described embodiments will be readily apparent to those skilled in the art. Therefore, it should be understood that those skilled in the art will be able to devise numerous systems, arrangements, and processes that, although not explicitly shown or described herein, embody the principles of the present disclosure and are therefore within the scope of the present disclosure. As will be appreciated by those skilled in the art, the various exemplary embodiments may be used together or interchangeably.

Claims

1. A computer-implemented method for managing resource usage in a radio access network (RAN) of a communication network, wherein: One or more user equipments (UEs) communicate using the RAN, and the method includes: Receiving (701) a traffic profile for a traffic of one or more UEs, wherein the traffic profile is received from the UE and / or a server connected to the communication network via application layer communication, wherein the traffic profile relates to requirements of one or more quality of service (QoS) flows of the one or more UEs; monitoring (703) performance of one or more cells in the RAN; determining (705) a change in connectivity of one or more UEs to the RAN and / or a change in one or more QoS based on the monitored performance and the received traffic profile; and A control signal is sent (707) to the RAN to effect the determined change.

2. The method according to claim 1, wherein The received traffic profile relates to one or both of uplink traffic and downlink traffic.

3. The method according to claim 1 or 2, wherein: The received traffic profile indicates the importance and / or priority of traffic in one or more QoS flows and / or traffic of one or more UEs.

4. The method according to any one of claims 1 to 3, wherein The received traffic profile indicates the importance and / or priority of traffic in one or more QoS flows and / or traffic of one or more UEs relative to the importance and / or priority of traffic in one or more other QoS flows and / or traffic of one or more other UEs.

5. The method according to any one of claims 1 to 4, wherein The traffic profile relates to a subset of established QoS flows and / or a subset of UEs connected to the RAN.

6. The method according to any one of claims 1 to 5, wherein The service profile indicates one or more of the following: criticality of the QoS flow and / or the services of the one or more UEs; an average data throughput of the QoS flow and / or services of the one or more UEs on uplink and / or downlink; a peak data throughput of the QoS flow and / or the service of the one or more UEs on uplink and / or downlink; a periodicity type of the QoS flow and / or the traffic of the one or more UEs; a transmission interval of the QoS flow and / or services of the one or more UEs; an inactive period of the QoS flow and / or the traffic of the one or more UEs; jitter tolerance of the QoS flow and / or the services of the one or more UEs; packet loss tolerance of the QoS flow and / or the services of the one or more UEs; as well as Typical packet data size of the QoS flow and / or traffic of the one or more UEs.

7. The method according to any one of claims 1 to 6, wherein The service profile is received from one or more UEs via a protocol data unit (PDU) session.

8. The method according to any one of claims 1 to 6, wherein The service configuration file is received from the server via an Internet Protocol (IP) connection.

9. The method according to any one of claims 1 to 8, wherein The received service profile is an update to a previously received service profile.

10. The method according to any one of claims 1 to 9, wherein Monitoring (703) the performance of the cell includes monitoring a data throughput of the cell.

11. The method according to any one of claims 1 to 10, wherein The method further comprises: The one or more UEs and / or the server are informed of the determined change in connectivity of the one or more UEs with the RAN and / or the change in one or more QoS flows.

12. The method according to any one of claims 1 to 11, wherein The control signal is sent to any one of: a centralized unit CU in the RAN; one or more distributed units DU in the RAN; or one or more base stations in the RAN.

13. The method according to any one of claims 1 to 12, wherein A change in connectivity of one or more UEs and / or a change in one or more QoS flows is determined to conform to or satisfy the received traffic profile.

14. The method according to any one of claims 1 to 13, wherein The determined changes include any one or more of: moving a QoS flow to a different cell in the RAN; modifying a QoS flow; releasing a QoS flow; Add QoS flow; moving the UE to a different cell in the RAN; releasing the UE connected to the RAN; and releasing or disconnecting QoS flows or UEs having a lower priority than the QoS or UEs associated with the received service profile.

15. The method according to any one of claims 1 to 14, wherein The steps to determine (705) the changes include: calculating a load metric for the first cell based on a measurement representing performance of the first cell; comparing the calculated load metric with a target load metric for the first cell; and Based on the comparison, it is determined whether the received service profile can be satisfied in the first cell.

16. The method according to claim 15, wherein The first cell is a primary cell (PCell), and if it is determined based on the comparison that the received service profile cannot be satisfied in the PCell, it is determined whether the received service profile can be satisfied in a secondary cell (SCell).

17. The method according to claim 15, wherein: If it is determined that the received service profile cannot be satisfied in the first cell: determining whether one or more QoS flows and / or UEs connected to the first cell have a lower priority than traffic according to the received traffic profile; as well as Determine to move, modify, or release one or more QoS flows or UEs having a lower priority connected to the first cell.

18. The method according to any one of claims 1 to 17, wherein The communication network is any one of the following networks: a public communication network, a slice in a communication network, a private network, a non-public network, a terrestrial network and a non-terrestrial network.

19. The method according to any one of claims 1 to 18, wherein The one or more UEs and / or the server are configured to execute an industrial application.

20. A computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured to, when executed by a suitable computer or processor, cause the computer or processor to perform the method according to any one of claims 1 to 19.

21. A RAN resource management node (220) for managing resource usage in a radio access network RAN ​​(105) of a communication network, wherein: One or more user equipments (UE) (202) communicate using the RAN (105), and the RAN resource management node (220) is configured to: receiving a traffic profile for traffic of one or more UEs (202), wherein the traffic profile is received from the UEs (202) and / or a server (212) connected to the communication network via application layer communication, wherein the traffic profile relates to requirements of one or more quality of service (QoS) flows of the one or more UEs (202); monitoring performance of one or more cells in the RAN (105); determining a change in connectivity of one or more UEs (202) to the RAN (105) and / or a change in one or more QoS based on the monitored performance and the received traffic profile; and A control signal is sent to the RAN (105) to effect the determined change.

22. The RAN resource management node (220) according to claim 21, wherein The received traffic profile relates to one or both of uplink traffic and downlink traffic.

23. The RAN resource management node (220) according to claim 21 or 22, wherein: The received traffic profile indicates the importance and / or priority of traffic in one or more QoS flows and / or traffic of one or more UEs (202).

24. The RAN resource management node (220) according to any one of claims 21 to 23, wherein: The received traffic profile indicates the importance and / or priority of traffic in one or more QoS flows and / or traffic of one or more UEs (202) relative to the importance and / or priority of traffic in one or more other QoS flows and / or traffic of one or more other UEs (202).

25. The RAN resource management node (220) according to any one of claims 21 to 24, wherein: The traffic profile relates to a subset of established QoS flows and / or a subset of the UEs (202) connected to the RAN (105).

26. The RAN resource management node (220) according to any one of claims 21 to 25, wherein: The service profile indicates one or more of the following: criticality of the QoS flow and / or traffic of the one or more UEs (202); Average data throughput of the QoS flow and / or traffic of the one or more UEs (202) on uplink and / or downlink; Peak data throughput of the QoS flow and / or traffic of the one or more UEs (202) on uplink and / or downlink; a periodicity type of traffic of the QoS flow and / or the one or more UEs (202); a transmission interval of the QoS flow and / or traffic of the one or more UEs (202); Inactive periods of traffic of the QoS flow and / or the one or more UEs (202); jitter tolerance of the QoS flow and / or traffic of the one or more UEs (202); packet loss tolerance of the QoS flow and / or traffic of the one or more UEs (202); as well as Typical packet data sizes of the QoS flows and / or traffic of the one or more UEs (202).

27. The RAN resource management node (220) according to any one of claims 21 to 26, wherein: The service profile is received from one or more UEs (202) via a protocol data unit (PDU) session.

28. The RAN resource management node (220) according to any one of claims 21 to 26, wherein: The service profile is received from the server (212) via an Internet Protocol (IP) connection.

29. The RAN resource management node (220) according to any one of claims 21 to 28, wherein: The received service profile is an update to a previously received service profile.

30. The RAN resource management node (220) according to any one of claims 21 to 29, wherein: The performance of the cell is the data throughput of the cell.

31. The RAN resource management node (220) according to any one of claims 21 to 30, wherein: The RAN resource management node (220) is further configured to: The one or more UEs (202) and / or the server (212) are informed of the determined change in connectivity of the one or more UEs (202) to the RAN (105) and / or the change in one or more QoS flows.

32. The RAN resource management node (220) according to any one of claims 21 to 31, wherein: The control signal is sent to any one of: a centralized unit CU (108) in the RAN (105); one or more distributed units DU (106) in the RAN (105); or one or more base stations in the RAN (105).

33. The RAN resource management node (220) according to any one of claims 21 to 32, wherein: A change in connectivity of one or more UEs (202) and / or a change in one or more QoS flows is determined to conform to or satisfy the received traffic profile.

34. The RAN resource management node (220) according to any one of claims 21 to 33, wherein: The determined changes include any one or more of: moving a QoS flow to a different cell in the RAN (105); modifying a QoS flow; releasing a QoS flow; adding a QoS flow; moving a UE (202) to a different cell in the RAN (105); releasing a UE (202) connected to the RAN (105); and releasing or disconnecting a QoS flow or UE (202) having a lower priority than the QoS or UE (202) associated with the received traffic profile.

35. The RAN resource management node (220) according to any one of claims 21 to 34, wherein: The RAN resource management node (220) is configured to determine the change by: calculating a load metric for the first cell based on a measurement representing performance of the first cell; comparing the calculated load metric with a target load metric for the first cell; as well as Based on the comparison, it is determined whether the received service profile can be satisfied in the first cell.

36. The RAN resource management node (220) according to claim 35, wherein The first cell is a primary cell (PCell), and if it is determined based on the comparison that the received service profile cannot be satisfied in the PCell, the RAN resource management node (220) is further configured to determine whether the received service profile can be satisfied in a secondary cell (SCell).

37. The RAN resource management node (220) according to claim 35, wherein If it is determined that the received service profile cannot be satisfied in the first cell, the RAN resource management node (220) is further configured to: determining whether one or more QoS flows and / or UEs (202) connected to the first cell have a lower priority than the traffic according to the received traffic profile; as well as Determining to move, modify, or release one or more QoS flows or UEs connected to the first cell with a lower priority (202).

38. The RAN resource management node (220) according to any one of claims 21 to 37, wherein The communication network is any one of the following networks: a public communication network, a slice in a communication network, a private network, a non-public network, a terrestrial network and a non-terrestrial network.

39. The RAN resource management node (220) according to any one of claims 21 to 38, wherein The one or more UEs (202) and / or the server (212) are used to execute an industrial application.

40. A RAN resource management node for managing resource usage in a Radio Access Network (RAN) of a communication network, wherein: One or more user equipments (UEs) communicate using the RAN, and the RAN resource management node comprises a processor and a memory, wherein the memory contains instructions, and the instructions are executable by the processor, whereby the RAN resource management node is operable to: receiving a service profile for a service of one or more UEs, wherein the service profile is received from the UE and / or a server connected to the communication network via application layer communication, wherein the service profile relates to requirements of one or more quality of service (QoS) flows of the one or more UEs; monitoring performance of one or more cells in the RAN; determining a change in connectivity of one or more UEs to the RAN and / or a change in one or more QoS based on the monitored performance and the received traffic profile; and A control signal is sent to the RAN to effect the determined change.

41. The RAN resource management node according to claim 40, wherein: The received traffic profile relates to one or both of uplink traffic and downlink traffic.

42. The RAN resource management node according to claim 40 or 41, wherein: The received traffic profile indicates the importance and / or priority of traffic in one or more QoS flows and / or traffic of one or more UEs.

43. The RAN resource management node according to any one of claims 40 to 42, wherein: The received traffic profile indicates the importance and / or priority of traffic in one or more QoS flows and / or traffic of one or more UEs relative to the importance and / or priority of traffic in one or more other QoS flows and / or traffic of one or more other UEs.

44. The RAN resource management node according to any one of claims 40 to 43, wherein: The traffic profile relates to a subset of established QoS flows and / or a subset of the UEs connected to the RAN.

45. The RAN resource management node according to any one of claims 40 to 44, wherein: The service profile indicates one or more of the following: criticality of the QoS flow and / or the services of the one or more UEs; an average data throughput of the QoS flow and / or services of the one or more UEs on uplink and / or downlink; a peak data throughput of the QoS flow and / or the service of the one or more UEs on uplink and / or downlink; a periodicity type of the QoS flow and / or the traffic of the one or more UEs; a transmission interval of the QoS flow and / or services of the one or more UEs; an inactive period of the QoS flow and / or the traffic of the one or more UEs; jitter tolerance of the QoS flow and / or the services of the one or more UEs; packet loss tolerance of the QoS flow and / or the services of the one or more UEs; as well as Typical packet data size of the QoS flow and / or traffic of the one or more UEs.

46. ​​The RAN resource management node according to any one of claims 40 to 45, wherein: The service profile is received from one or more UEs via a protocol data unit (PDU) session.

47. The RAN resource management node according to any one of claims 40 to 45, wherein: The service configuration file is received from the server via an Internet Protocol (IP) connection.

48. The RAN resource management node according to any one of claims 40 to 47, wherein: The received service profile is an update to a previously received service profile.

49. The RAN resource management node according to any one of claims 40 to 48, wherein: The performance of the cell is the data throughput of the cell.

50. The RAN resource management node according to any one of claims 40 to 49, wherein: The RAN resource management node is further operable to: The one or more UEs and / or the server are informed of the determined change in connectivity of the one or more UEs with the RAN and / or the change in one or more QoS flows.

51. The RAN resource management node according to any one of claims 40 to 50, wherein: The control signal is sent to any one of: a centralized unit CU in the RAN; one or more distributed units DU in the RAN; or one or more base stations in the RAN.

52. The RAN resource management node according to any one of claims 40 to 51, wherein: A change in connectivity of one or more UEs and / or a change in one or more QoS flows is determined to conform to or satisfy the received traffic profile.

53. The RAN resource management node according to any one of claims 40 to 52, wherein: The determined changes include any one or more of: moving a QoS flow to a different cell in the RAN; modifying a QoS flow; releasing a QoS flow; Add QoS flow; moving the UE to a different cell in the RAN; releasing the UE connected to the RAN; and releasing or disconnecting QoS flows or UEs having a lower priority than the QoS or UEs associated with the received service profile.

54. The RAN resource management node according to any one of claims 40 to 53, wherein: The RAN resource management node is operable to determine the change by: calculating a load metric for the first cell based on a measurement representing performance of the first cell; comparing the calculated load metric with a target load metric for the first cell; as well as Based on the comparison, it is determined whether the received service profile can be satisfied in the first cell.

55. The RAN resource management node according to claim 54, wherein: The first cell is a primary cell (PCell), and if the received service profile cannot be satisfied in the PCell based on the comparison, the RAN resource management node is further operable to determine whether the received service profile can be satisfied in a secondary cell (SCell).

56. The RAN resource management node according to claim 54, wherein: If it is determined that the received service profile cannot be satisfied in the first cell, the RAN resource management node is further operable to: determining whether one or more QoS flows and / or UEs connected to the first cell have a lower priority than traffic according to the received traffic profile; as well as Determine to move, modify, or release one or more QoS flows or UEs having a lower priority connected to the first cell.

57. The RAN resource management node according to any one of claims 40 to 56, wherein: The communication network is any one of the following networks: a public communication network, a slice in a communication network, a private network, a non-public network, a terrestrial network and a non-terrestrial network.

58. The RAN resource management node according to any one of claims 40 to 57, wherein: The one or more UEs and / or the server are configured to execute an industrial application.

Images