Generating policy and charging control rules

Abstract

A NE configured to receive a user request in natural language specifying a desired network treatment for a particular application, cause the user request to be processed using a language processing model, extract policy parameters including at least a QoS level, wherein the policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network's policy framework, obtain, in response to a first request received from the language processing model, traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application, send the traffic flow descriptors to the language processing model and receive therefrom a PCC rule based on the extracted one or more policy parameters and the traffic flow descriptors, and initiate installation, in response to a second request received from the language processing model, the rule into the core network's policy framework.

Description

GENERATING POLICY AND CHARGING CONTROL RULESTECHNICAL FIELD

[0001] The present disclosure relates to wireless communications, and more specifically to generating Policy and Charging Control (PCC) rules.BACKGROUND

[0002] A wireless communications system may include one or multiple network communication devices, such as network equipment (NE), supporting wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology. The wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like)). Additionally, the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).SUMMARY

[0003] An article “a” before an element is unrestricted and understood to refer to “at least one” of those elements or “one or more” of those elements. The terms “a,” “at least one,” “one or more,” and “at least one of one or more” may be interchangeable. As used herein, including in the claims, “or” as used in a list of items (e.g., a list of items prefaced by a phrase such as “at least one of’ or “one or more of’ or “one or both of’) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Also, as used herein, the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be basedAttorney Docket No. PC934517WOon both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.

[0004] A NE for wireless communication is described. The NE may be capable of, operable to, or configured to perform one or more operations as described herein. For example, the NE may be capable of, operable to, or configured to receive a user request in natural language specifying a desired network treatment for a particular application, cause the user request to be processed using a language processing model, to extract one or more policy parameters including at least a Quality- of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network, receive a first request from the language processing model for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application, obtain, in response to the first request received from the language processing model, the traffic flow descriptors, send the traffic flow descriptors to the language processing model, receive a second request from the language processing model including a PCC rule, the PCC rule based on the extracted one or more policy parameters and the traffic flow descriptors, and initiate installation of the PCC rule into the core network, in response to receipt of the second request.

[0005] A processor (e.g., a standalone processor chipset, or a component of a first device) for wireless communication is described. The processor may be capable of, operable to, or configured to perform one or more operations as described herein. For example, the processor may be capable of, operable to, or configured to receive a user request in natural language specifying a desired network treatment for a particular application, cause the user request to be processed using a language processing model, to extract one or more policy parameters including at least a Quality- of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network, receive a first request from the language processing model, for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application, obtain, in response to the first request received from the language processing model, the traffic flow descriptors, send the traffic flow descriptors to the language processing model, receive a second request from the language processing model including a PCC rule, the PCC rule based on theAttorney Docket No. PC934517WOextracted one or more policy parameters and the traffic flow descriptors, and initiate installation of the PCC rule into the core network, in response to receipt of the second request.

[0006] A method performed or performable by a NE for wireless communication is described. The method may include receiving a user request in natural language specifying a desired network treatment for a particular application, causing the user request to be processed using a language processing model, to extract one or more policy parameters including at least a Quality-of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network’s policy framework, receiving a first request from the language processing model for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application, obtaining, in response to the first request received from the language processing model, the traffic flow descriptors, sending the traffic flow descriptors to the language processing model, receiving a second request from the language processing model including a PCC rule, the PCC rule based on the extracted one or more policy parameters and the traffic flow descriptors, and initiating installation, in response to the second request received from the language processing model, the PCC rule into the core network’s policy framework.

[0007] In some implementations of the NE, the processor, and the method described herein, the PCC rule includes at least a service data flow component and a QoS policy component.

[0008] In some implementations of the NE, the processor, and the method described herein, the PCC rule includes a QoS policy component comprising a 5G QoS Indicator, 5QI, value, an Allocation and Retention Priority, ARP, with priority level and preemption parameters, and a service data flow component comprising the traffic flow descriptors for uplink and / or downlink directions, such that the PCC rule is parseable by a 5G core Policy Control function.

[0009] In some implementations of the NE, the processor, and the method described herein the service data flow component is derived based on the traffic flow descriptors and includes one or more of IP addresses, IP packet prefixes, protocol identifiers, port numbers, and other packet identifiers.

[0010] In some implementations of the NE, the processor, and the method described herein may further be capable of, operable to, or configured to process the user request using a local LLM installed at the NE or using a remote LLM accessed via an Application Programming Interface, API.Attorney Docket No. PC934517WO

[0011] In some implementations of the NE, the processor, and the method described herein may further be capable of, operable to, or configured to obtain the traffic flow descriptors using a first tool installed at the NE and initiate installation of the PCC rule into a core network’s policy framework using a second tool installed at the NE.

[0012] In some implementations of the NE, the processor, and the method described herein, the first tool maintains a library of applications and matching traffic flow descriptors for each application, and the processor is configured to cause the NE to match the identification of the particular application to an entry in the library and fetch the corresponding traffic flow descriptors.

[0013] In some implementations of the NE, the processor, and the method described herein may further be capable of, operable to, or configured to initiate installation of the PCC rule into a core network’s policy framework by invoking a RESTful API exposed by the core network, and to receive a confirmation indicating that the policy has been applied.

[0014] In some implementations of the NE, the processor, and the method described herein may further be capable of, operable to, or configured to utilise a third tool to query the core network’s policy framework to retrieve subscription data including one or more stored PCC rules and verify their contents.

[0015] In some implementations of the NE, the processor, and the method described herein may further be capable of, operable to, or configured to provide feedback or a summary of the installed subscription data to the user and to log the outcome for audit purposes, based upon the retrieved subscription data.

[0016] In some implementations of the NE, the processor, and the method described herein may further be capable of, operable to, or configured to compare the user request or the PCC rule against existing policies to identify overlaps or contradictions and, if a potential conflict is detected, to obtain a merged PCC rule and / or alert the user.

[0017] A system for wireless communication is described. The system may comprise the NE described above, and a network bridge module configured to receive the PCC rule from the NE and to install or update the PCC rule in the core network’s policy framework.

[0018] In some implementations of the system, the network bridge module is adapted for a 5G core network and writes the PCC rule into a 5G core network’s subscription database directly or via a Unified Data Repository, UDR, such that the PCC rule is stored under a specified subscriberAttorney Docket No. PC934517WOor network slice profile and is immediately enforceable by core network functions for any matching traffic.BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure in accordance with aspects of the present disclosure.

[0020] Figure 2 illustrates an exemplary architecture.

[0021] Figure 3 illustrates an operation workflow for the architecture of Figure 2.

[0022] Figure 4 illustrates an exemplary user intent and processing of that intent to generate a PCC rule.

[0023] Figure 5 illustrates an exemplary PCC rule.

[0024] Figure 6 illustrates an example of a NE 1100 in accordance with aspects of the present disclosure.

[0025] Figure 7 is a flowchart illustrating a method 1200 performed by a NE in accordance with aspects of the present disclosure.DETAILED DESCRIPTION

[0026] The 3rd Generation Partnership Project (3GPP) refers to a collaborative initiative among multiple standards organizations that develop protocols for mobile telecommunications technologies. These technologies include, but are not limited to, radio access, core network functionality, and service capabilities, collectively providing a comprehensive system framework for mobile telecommunications.

[0027] 3GPP has developed 5G networks that require sophisticated Policy and Charging Control (PCC) rules to manage traffic flows, quality of service (QoS), and charging for different applications and users. Creating and managing these rules is largely a manual process handled by skilled engineers through web consoles or configuration files. This manual PCC rule creation process may be time-consuming and error prone. Furthermore, as networks evolve, the complexity of maintaining rule sets for each slice, user, and service becomes challenging. There is a need to move beyond manual configuration of network policies towards more automated, intent-drivenAttorney Docket No. PC934517WOapproaches. For example, specifying priority and desired QoS for applications via high-level intents may significantly reduce operational effort compared to editing low-level rule definitions.

[0028] Attempts at intent-based networking in telecom networks have been limited so far. Some systems allow high-level network configuration through structured intents or templates, but they often require the operator to learn a special syntax or only handle broad tasks like slice provisioning. Early research on natural language processing (NLP) powered intent management for 5G (e.g., private networks) introduced intent engines for slice setup and service deployment.

[0029] Known prior art approaches include:• The use of LLMs to interpret user intents and generate network configurations. This provides for validating low-level configurations, without PCC rule enforcement.• The use of Al to interpret natural language policies and generate structured network rules. This approach primarily applies to content delivery networks (CDN), not 5G / 6G core networks.• Convert intent-driven statements into device-specific policies. This approach does not directly construct PCC rules for subscriber traffic control.• The use of machine learning to refine PCRF rule creation. This approach lacks realtime natural language interpretation for intent-based policies.

[0030] However, these solutions typically do not integrate deeply with real-time PCC rule enforcement for individual traffic flows, nor do they harness the full capability of modern large language models (LLMs) for free-form natural language understanding. In short, current Al-based intent systems lack fine-grained control and seamless integration with the 5G core’s policy framework.

[0031] A solution presented here lies at the intersection of mobile core network management and artificial intelligence, enabling natural language interpretation for PCC rule creation in 5G networks. More particularly, the solution addresses the above challenges by leveraging an advanced large language model (LLM) to translate a user's natural-language request into concrete PCC rules in a 5G core. The solution aims to empower network operators and application developers to specify desired QoS policies in natural language (e.g., “Give streaming video high priority for enterprise users, with at least 5 Mbps guaranteed”) and have the system automatically create, deploy, and activate the appropriate PCC rules. This may reduce the complexity and delay in deploying policy changes. The solution may use an LLM for per-subscriber, application-specificAttorney Docket No. PC934517WOpolicy generation, directly tying the outcome into a working 5G core network, enabling intent- driven policy control at the network slice and user level.

[0032] By way of example, the solution may be implemented using the Open5GS (an open source 5G core implementation) as the underlying 5G core network. Of course other implementations are possible.

[0033] Aspects of the present disclosure are described in the context of a wireless communications system.

[0034] Figure 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure. The wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106. The wireless communications system 100 may support various radio access technologies. In some implementations, the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE-Advanced (LTE-A) network. In some other implementations, the wireless communications system 100 may be a NR network, such as a 5G network, a 5G- Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network. In other implementations, the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20. The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.

[0035] The one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100. One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a nextgeneration NodeB (gNB), or other suitable terminology. An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection. For example, an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.

[0036] An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area. For example, an NE 102Attorney Docket No. PC934517WOand a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies. In some implementations, an NE 102 may be moveable, for example, a satellite associated with a nonterrestrial network (NTN). In some implementations, different geographic coverage areas 112 associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.

[0037] The one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100. A UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology. In some implementations, the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples. Additionally, or alternatively, the UE 104 may be referred to as an Internet-of-Things (loT) device, an Internet-of- Everything (loE) device, or machine-type communication (MTC) device, among other examples.

[0038] A UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link. For example, a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link. In some implementations, such as vehicle-to-vehicle (V2V) deployments, vehicle-to-everything (V2X) deployments, or cellular-V2X deployments, the communication link 114 may be referred to as a sidelink. For example, a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.

[0039] An NE 102 may support communications with the CN 106, or with another NE 102, or both. For example, an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, N2, or network interface). In some implementations, the NE 102 may communicate with each other directly. In some other implementations, the NE 102 may communicate with each other or indirectly (e.g., via the CN 106. In some implementations, one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC). An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).

[0040] The CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions. The CN 106 may be an evolvedAttorney Docket No. PC934517WOpacket core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management functions (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P- GW), or a user plane function (UPF)). In some implementations, the control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.

[0041] The CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, N2, or another network interface). The packet data network may include an application server. In some implementations, one or more UEs 104 may communicate with the application server. A UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102. The CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session). The PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).

[0042] In the wireless communications system 100, the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications). In some implementations, the NEs 102 and the UEs 104 may support different resource structures. For example, the NEs 102 and the UEs 104 may support different frame structures. In some implementations, such as in 4G, the NEs 102 and the UEs 104 may support a single frame structure. In some other implementations, such as in 5G and among other suitable radio access technologies, the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures). The NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.

[0043] One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix. A first numerology (e.g., / r=0) may be associated with a first subcarrier spacing (e.g., 15 kHz) and a normal cyclic prefix. In some implementations, the first numerology (e.g., / r=0) associated with the first subcarrier spacing (e.g., 15 kHz) may utilize one slot per subframe. A second numerology (e.g.,Attorney Docket No. PC934517WO / r=l) may be associated with a second subcarrier spacing (e.g., 30 kHz) and a normal cyclic prefix. A third numerology (e.g., / r=2) may be associated with a third subcarrier spacing (e.g., 60 kHz) and a normal cyclic prefix or an extended cyclic prefix. A fourth numerology (e.g., / r=3) may be associated with a fourth subcarrier spacing (e.g., 120 kHz) and a normal cyclic prefix. A fifth numerology (e.g., / r=4) may be associated with a fifth subcarrier spacing (e.g., 240 kHz) and a normal cyclic prefix.

[0044] A time interval of a resource (e.g., a communication resource) may be organized according to frames (also referred to as radio frames). Each frame may have a duration, for example, a 10 millisecond (ms) duration. In some implementations, each frame may include multiple subframes. For example, each frame may include 10 subframes, and each subframe may have a duration, for example, a lms duration. In some implementations, each frame may have the same duration. In some implementations, each subframe of a frame may have the same duration.

[0045] Additionally or alternatively, a time interval of a resource (e.g., a communication resource) may be organized according to slots. For example, a subframe may include a number (e.g., quantity) of slots. The number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100. For instance, the first, second, third, fourth, and fifth numerologies (i.e., / r=0, jU=l, f =2, jU=3, / r=4) associated with respective subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, 120 kHz, and 240 kHz may utilize a single slot per subframe, two slots per subframe, four slots per subframe, eight slots per subframe, and 16 slots per subframe, respectively. Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols). In some implementations, the number (e.g., quantity) of slots for a subframe may depend on a numerology. For a normal cyclic prefix, a slot may include 14 symbols. For an extended cyclic prefix (e.g., applicable for 60 kHz subcarrier spacing), a slot may include 12 symbols. The relationship between the number of symbols per slot, the number of slots per subframe, and the number of slots per frame for a normal cyclic prefix and an extended cyclic prefix may depend on a numerology. It should be understood that reference to a first numerology (e.g., / r=0) associated with a first subcarrier spacing (e.g., 15 kHz) may be used interchangeably between subframes and slots.

[0046] In the wireless communications system 100, an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc. By way of example, the wireless communications system 100 may support one or multipleAttorney Docket No. PC934517WOoperating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz). In some implementations, the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands. In some implementations, FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data). In some implementations, FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.

[0047] FR1 may be associated with one or multiple numerologies (e.g., at least three numerologies). For example, FR1 may be associated with a first numerology (e.g., / r=0), which includes 15 kHz subcarrier spacing; a second numerology (e.g., / r=l), which includes 30 kHz subcarrier spacing; and a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing. FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies). For example, FR2 may be associated with a third numerology (e.g., / r=2), which includes 60 kHz subcarrier spacing; and a fourth numerology (e.g., / r=3), which includes 120 kHz subcarrier spacing.

[0048] The solution presented here involves an Al-driven agent system that translates naturallanguage user intents into PCC rules and installs them in a mobile core network (CN). [A “natural language” may be defined as a language that has developed naturally in use, as contrasted with an artificial language or computer code.] These PCC rules are enforced by the mobile network and result in, for example, the application of specific QoS treatment(s) for specific traffic flows.

[0049] Figure 2 illustrates an exemplary architecture 200. This architecture is modular, consisting of an Agent 202 and several interconnected components. The user 204 (e.g., a network operator, vertical application, etc.) interacts with the system via a “Northbound Interface” 206 which communicates, through a Representational State Transfer (REST) API, with the Agent 202. This Northbound Interface 206 may be a web-based dashboard, a chatbot, CLI, or any application that allows the user (e.g., a network operator or administrator) to input an intent such as a sentence or command.

[0050] A language processing model component, for a example a Large Language Model (LLM) 208, is integrated to handle natural language processing although, in other examples, the LLM model may be an external component, e.g., located in the cloud, accessible via an API. TheAttorney Docket No. PC934517WOLLM model may be pre-trained and / or fine-tuned to create PCC rules based on natural-language user intents. The LLM model retrieves user intents from the Agent and requests the Agent to invoke supported tools to execute tasks and provide task results back to the LLM model.

[0051] In addition to the LLM component, the Agent 202 also interfaces with three tools: a Flow Descriptor Lookup (Tooll) 210, PCC Rule Installation (Tool2) 212, and PCC Rule Viewer (Tool3) 214. The Agent 202 and these tools may communicate over known and well-defined internal APIs or function calls. The Agent 202 operates as a bridge between the LLM model 208 and these specialized tools: the Agent 202 receives instructions from the LLM model to call functions available using specialized tools and provides the results from these functions to the LLM model.

[0052] Considering the specialized tools in more detail, these provide the following functions:Flow Descriptor Lookup Tool - a module that provides traffic descriptors (e.g., IP addresses, port numbers, domain names) for known applications or services. Given an application name or service description from the user intent, this tool returns the corresponding flow descriptor, which identifies the traffic of the application name of service, e.g., using IP address ranges, protocol types and port ranges.PCC Rule Installation Tool - a module that handles the installation of the generated rules in an underlying 5G network. It provides a function which the LLM can call (via the Agent) to validate and install a complete PCC rule in the underlying 5G network. This tool interacts with a bridge 218 - see below - in the 5G network that undertakes the installation of the rule in the 5G core network’s subscription database.PCC Rule Viewer Tool - a module that can retrieve and display currently installed PCC rules. It provides a function which the LLM can call (via the Agent) to retrieve installed PCC rules (or general subscription information) from the underlying 5G network. This tool interacts also with the bridge 218 in the 5G network that undertakes the retrieval of the rule from the 5G core network’s subscription database.

[0053] Via a “Southbound Interface” 216, the Agent 202 uses the bridge 218 (via Tool2 or Tool3) to interact with the 5G CN 220. The bridge 218 exposes REST endpoints (or a similar interface) that the Agent calls to install, update or view PCC rules. The bridge 218 in turn translates the Agent’s request into the appropriate format for the CN’s subscription database 222. The bridge 218 may write the PCC rules to the subscription database 222 directly or via the UDR (Unified Data Repository) 224 by using some standard UDR API. In the latter case, the UDR may informAttorney Docket No. PC934517WOthe CN’s Policy Control Function (PCF) about the subscription changes and the new PCC rule can become active for the target subscriber or service.

[0054] The modular design presented here allows each component to be upgraded or replaced independently. For example, the LLM model 208 may be swapped for a more advanced model without affecting the rest of the system, or the bridge 218 may be modified to support a different vendor’s core (since it communicates via a REST API, the bridge be adapted to another database schema or another interface).

[0055] Figure 3 illustrates an operation workflow from the point in time when a user provides an intent to the point where a network policy is applied, with entities involved in the workflow being identified using the reference numerals of Figure 2. The following steps are identified in Figure 3.

[0056] la. A user (such as a network engineer or administrator) inputs a high-level policy intent via a user interface. This intent may be in the form of a natural language sentence or command phrased in natural language. For example: “Give Best Effort service and low retention priority to CAM Application ABC..” In this example, the user is requesting that a certain application (“CAM Application ABC” where “CAM Application” indicates a Connected Automated Mobility application) be treated with a best-effort QoS and a low allocation / retention priority.

[0057] The user interface encapsulates this intent (along with any relevant metadata, such as which network slice the intent applies to, data network name (DNN), or subscriber it pertains to) and sends the encapsulated intent (“intent string”) to the (Al) Agent 202 through a REST API call (step lb below). This is typically an HTTP POST request to an endpoint (e.g., / api / vl / intents) exposed by the Agent 202, carrying a JSON payload such as { "intent": "Give Best Effort service and low retention to CAM Application ABC", "target": '^subscriber id, slice id, dnn>" }. The Agent receives and starts processing the incoming intent string.

[0058] lb. The Agent 202 passes the intent string to the LLM model 208. This can be done by constructing a prompt may include some context or instructions for the LLM model. For example, the Agent may prepend a system message to the LLM model such as: “You are an expert in mobile network policy. The user intent is: 'Give Best Effort service and low retention to CAM Application ABC. Construct the required PCC rule and identify the application flows..”Attorney Docket No. PC934517WO

[0059] 2. The LLM model 208 determines that it needs to know the details for “CAMApplication ABC”. It therefore asks the Agent 202 to invoke Tooll 210: Flow Descriptor Lookup with parameters that identify the application (e.g., the application identity or name).

[0060] 3. The Agent 202 invokes Tooll e.g., by calling a function in Tooll such as requestFlowDescriptor("CAM Application ABC"). This tool has a record of known applications / services and their respective traffic flow descriptors. In the present example, suppose that “CAM Application ABC” is a known Internet of Things (loT) or Vehicle-to-Every thing (V2X) application and that there is a server in the network for this application that communicates at a specific IP address or within a certain IP range and using a certain protocol and port. Tooll returns, for example, that Application ABC corresponds to destination IP address 193.14.11.10, protocol = TCP, and destination port = 27890. It might also specify whether the traffic is uplink, downlink or both. For the purpose of this example, it is assumed traffic can be bidirectional, so descriptors for both directions will be required.

[0061] The Agent 202 calls the function in Tooll 210 (step 3a) as requested by the LLM model 208, receives the response from this function (step 3b) and forwards it to the LLM model (step 3c).

[0062] 4. The LLM model 208 now creates a new PCC rule based on the received user intent and the flow description for CAM Application ABC. The rule is structured according to the standard PCC rule format as defined in 3 GPP TS 29.212. Elements of the rule may include:

[0063] A unique Rule ID or name (e.g., "RuleCAM ABC BE" to indicate it is for CAM ABC with Best Effort).

[0064] Service Data Flow (SDF) descriptors: These are essentially the traffic flow filters that specify the uplink and downlink traffic of CAM Application ABC. In the present example, the model creates two flow descriptions - one for uplink (UE-to-network) and one for downlink (network-to-UE). Each flow description may be a string in IP filter format (for example, "permit in tcp from 10.0.0.0 / 8 to 193.14.11.10 27890" for uplink, and the inverse for downlink. Here, “193.14.11.10” represents the application server IP address and “10.0.0.0 / 8” the IP address range of UEs. The exact syntax follows the format used in PCC rules (which often resembles firewall rules).

[0065] QoS parameters: The LLM model assigns specific QoS parameters to the PCC rules. These QoS parameters will be used by the 5G network to handle the traffic described in the Service Data Flow descriptors, i.e., the traffic of CAM Application ABC. The QoS parameters include aAttorney Docket No. PC934517WO5QI value and the ARP (Allocation and Retention Priority). ARP consists of three subfields: priority level (an integer, where 1 is highest priority and 15 is lowest), a pre-emption capability flag, and a pre-emption vulnerability flag. “Low retention” in intent implies this traffic can be dropped if needed (so it should be vulnerable to pre-emption by others and not pre-empt others). For example, the LLM model might set priorityLevel = 14 (or 15, to indicate very low priority), preemptioncapability = false (meaning this flow cannot preempt any other flows), and preemptionvulnerability = true (meaning any higher priority flow can preempt this flow).

[0066] Optionally, other PCC rule fields: If needed, the rule could include a Charging Key or Rating Group (if specific charging is required) or a monitoring key if usage monitoring is to be tied to this flow. In the present example, since the user’s intent did not refer to charging or data caps, the Agent 202 might use default values for these or omit them. In addition, the PCC rule may also contain Activation / Deactivation information, which determines when the PCC rule should be activated and / or deactivated in the 5G network.

[0067] 5. After creating the PCC rule, the LLM model 208 determines that it needs to call another tool (Tool2 212) to install the created PCC rule in the underlying 5G network. Hence, it instructs the Agent 202 to invoke Tool2 (step 5a), e.g., by calling a function in Tool2 like installPccRule(created PCC rule). The Agent 202 calls the function in Tool2 (step 5b) as requested by the LLM model.

[0068] 6. Validation and Conflict Check: Before installing the PCC rule, the system may check if a similar rule already exists (e.g., via Tool3 214 or internal tracking). In this case, if a rule for “CAM Application ABC” is already present, the Agent may choose to update the rule or avoid duplication. Additionally, a rule validation takes place to ensure that the PCC rule created by the LLM model 208 has the correct structure and complies with the correct JSON schema.

[0069] 7. After the rule validation and conflict check, Tool2 212 initiates the installation of thePCC rule in the underlying 5G network by sending a Subscription Update Request to the bridge component 218 within the CN. This is typically another REST call (step 7a), for example: POST / api / vl / installRule with the rule data in JSON format. The request includes necessary context such as subscriber identity, slice, and the Data Network Name (DNN) this rule applies to. The payload contains the PCC rule structure created in step 4. The bridge 218 receives this API call and then interfaces with the CN’s subscription database 222. This interaction involves the exchange (stepAttorney Docket No. PC934517WO7b) of one or more database commands that result in updating the subscription data of one or more subscribers with the new PCC rule.

[0070] In the case of Open5GS, the bridge 218 connects to the database of UDR 224 where subscriber information and policies are stored. [Open5GS uses a MongoDB database for the UDR.] The bridge 218 either directly performs a database insertion / update (as shown in Figure 3) or calls a UDR service API (Open5GS provides RESTful endpoints for subscription data management). In the latter case, the database is updated indirectly by the UDR.

[0071] Once the subscription database update is completed, the 5G core’s PCF function can be notified to fetch the new subscription data and update the rules of active Packet Data Unit (PDU) sessions, effectively enforcing the new PCC rule immediately.

[0072] In step 7c, the bridge 218 responds to Tool2 with a Result parameter that indicates whether the PCC rule has been successfully installed and with a Count parameter that indicates the number of subscribers or sessions which the PCC rule was installed in. It may include the rule ID or a copy of the installed PCC rule as confirmation.

[0073] In an example implementation, the bridge 218 responds with an HTTP response message that contains the following information. The "rule" parameter contains the JSON representation of the PCC rule that was added to the database.{"result" : "PCC_rule_added", "count" : 1 , "rule" : {"_id" : "67f29a6a863401763906c909","q os" : {"arp" : {"priority _level" : 15, "pre_emption_capability" : O,"pre_emption_vulnerabilit y": l}, "mbr": {"downlink": {"unit":l}, "uplink": {"umt":l }},"gbr": {"downlink": {"umt": ltion":l," description": "permit out udp from any 1-65535 to 7.7.7.7"}]}}The "rule" parameter contains the JSON representation of the PCC rule that was added to the database.

[0074] 8. The Tool2 returns a response to the Agent 202 (response to request in step 5b) including the Result and Count received from the bridge (step 8a). In turn, the Agent forwards the response from Tool2 to the UUM model (step 8b), which requested the invocation of Tool2 in step 5a.

[0075] 9. Based on the received Result and Count, the UUM model constructs a response to the user intent received in step lb (step 9a) and sends the response to the Agent (step 9b). Finally, the Agent sends the response to the user that provided the user intent (step 9c). Typically, the responseAttorney Docket No. PC934517WOmight indicate success or failure, and details of the action. In the present example, the Agent might return a message such as: “Intent applied: A newPCC rule 'RuleCAM ABC BE' has been installed for CAM Application ABC with 5QI=9 and ARP priority level 15.”. This confirms to the user that the best-effort, low-priority policy for the application is now active. If the system provides a user- friendly user interface, UI, it could also present the rule in a readable format or as a summary: e.g., “Traffic to IP 198.51.100.0 / 24 is now set to Best Effort (5QI 9) with low priority”.

[0076] As an optional step, after the installation of the PCC rule, the Agent 202 may use the PCC Rule Viewer (Tool3 214) to retrieve and confirm the newly installed rule. For example, it could call the function in Tool3, which would send a GET / api / vl / rules / <rule_id> to the bridge 218 to query the database 222. The bridge fetches the rule directly from the subscription database, or indirectly via the UDR, and returns it to the Agent. The Agent compares the installed PCC rule with what was intended. This step ensures that the rule stored in the 5G network is exactly as generated.

[0077] The process completes at this point. The 5G network will enforce the PCC rule and the user’s intent has been fulfilled in an entirely automation manner. The Agent can await receipt of a further intent.

[0078] Throughout the above described workflow, if any step fails (for example if the LLM output is unclear, or the flow lookup finds no data, or installation to the 5G core fails), the Agent 202 may handle the error, possibly returning a descriptive error to the user (e.g., “Unknown application” or “Failed to install policy, see admin logs”): no changes are made to the network unless all steps are deemed to have been performed successfully.

[0079] In order to further illustrate the proposed solution, a more specific example of a user intent, and the resulting PCC rule that is generated, will now be described with reference to Figure 4. The following steps are identified in Figure 4.

[0080] 1. Receive User Intent: “Give Best Effort service and low retention to CAM ApplicationABC. ”

[0081] This intent implies two main components regarding the desired network treatment:• QoS level: ‘ ‘Best Effort service” - in 5G network terms, this corresponds to a default bearer quality, which is typically represented by 5QI = 9 (a non-guaranteed bit rate, general purpose QoS identifier). “Best Effort” means no dedicated bandwidth guarantee, just a standard scheduling weight.Attorney Docket No. PC934517WO• Priority level: “Low retention” - interpreted as wishing this traffic to have low priority in resource allocation and retention. In 3GPP QoS, this is governed by ARP (Allocation and Retention Priority). “Low priority” means that, if the network is congested, this flow is one of the first that could be throttled or dropped. Technically, ARP is defined with a Priority Level value (range 1 to 15, where 1 is highest priority). So “low priority” corresponds to a high numeric value, such as 14 or 15. Additionally, ARP includes pre-emption settings: to truly be low priority, it should allow others to preempt it and it should not preempt any others. The following are set as Pre-emption Capability = “Disabled” (cannot take resources from others) and Pre-emption Vulnerability = “Enabled” (others can take its resources). Combined, these settings yield a low-retention priority profile.

[0082] 2. Getting the flow descriptor: The intent identifies “CAM Application ABC”. This is assumed to be a known application in the network’s context, e.g., a specific enterprise application or a standardized application. The Flow Descriptor Lookup (Tooll) might find, for example, that CAM Application ABC ’s traffic is identified by IP address 193.14.11.10 and TCP port 27890. Typically, this is the IP address, protocol and port used by the server for that application in the data network.

[0083] 3. Create PCC rule using LLM model: Using the retrieved flow descriptor for CAMApplication ABC and the received user intent, the LLM model now has all information needed to create an appropriate PCC rule that will enable the 5G network to enforce a desired level of QoS on the traffic of this application. The LLM model knows the structure of a PCC rule from 3 GPP TS 29.212 and creates a JSON representation of a PCC rule. This may have the structure shown in Figure 5.

[0084] This rule is identified by "RuleCAM ABC BEl". It has a “flow” element that contains two flow descriptions describing the uplink and downlink traffic that matches the PCC rule:• The uplink traffic matches all data packets from any UE address to IP address 193.14.11.10 and TCP port 27890.• The downlink traffic matches all data packets from IP address 193.14.11.10 and TCP port 27890 to any UE address.The rule has also a “qos” element that specifies the QoS treatment for the traffic that matches the “flow” element of the rule. In this particular example, the “qos” indicates that the traffic should beAttorney Docket No. PC934517WOhandled with 5QI=9, with ARP priority 15 (lowest priority), pre emption capability 0 (cannot preempt other traffic flows in case of congestion), and pre emption vulnerability 1 (can be preempted by other traffic flows in case of congestion). The Maximum Bit Rate (mbr) and the Guaranteed Bit Rate (gbr) parameters are left with their default values, since there is no need to guarantee uplink or downlink bitrates.

[0085] From the user’s perspective, there is no requirement for knowledge about 5QI values or traffic flow descriptors - the system acted upon the intent “best effort, low retention for app ABC”, and handled all translation.

[0086] The user may check (via the PCC Rule Viewer or the interface) that a rule was added. For example, the interface might show a summary such as: “CAM Application ABC traffic -> 5QI 9, ARP level 15, installed.”. This traceability is important for trust in an Al-driven system, ensuring that the user can verify that the outcome aligns with the request.

[0087] 4. Provide created PCC rule to Tool2: The JSON representation of the created PCC rule is provided to Tool2, which confirms that the rule does not conflict with another existing rule and confirms that its structure matches with the proper JSON schema.

[0088] 5. Store PCC rule in subscription data: Tool2 requests that the bridge store (install) thePCC rule in the subscription database of the 5G network. For example, it requests the PCC rule to be stored in all subscription documents that match Slice = SST-1 and DNN = “internet”. In this case, the PCC rule will be enforced when any UE attempts to communicate with the server of CAM Application ABC via a PDU session on slice SST-1 and DNN “internet”.

[0089] 6. Create response: After the PCC rule is stored in the subscription database, a suitable response is provided to the user to indicate that the rule was successfully stored and, once stored in the database, the 5G core network’s PCF will be notified and will associate this rule with a subscriber’s session. If the subscriber’s device is currently connected, the PCF triggers the SMF to create a dedicated QoS flow (or modify an existing one) matching these filters. This could result in establishing a new bearer / QoS flow with the desired 5QI. If the device is not currently active, the rule will take effect when it next establishes a session or matches the criteria (some rules can even be dormant until traffic matches, depending on implementation of dynamic PCC).

[0090] Figure 6 illustrates an example of a NE 600 in accordance with aspects of the present disclosure. The NE 600 may include a processor 602, a memory 604, a controller 606, and a transceiver 608. The processor 602, the memory 604, the controller 606, or the transceiver 608, orAttorney Docket No. PC934517WOvarious combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.

[0091] The processor 602, the memory 604, the controller 606, or the transceiver 608, or various combinations or components thereof may be implemented in hardware (e.g., circuitry). The hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.

[0092] The processor 602 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 602 may be configured to operate the memory 604. In some other implementations, the memory 604 may be integrated into the processor 602. The processor 602 may be configured to execute computer-readable instructions stored in the memory 604 to cause the NE 600 to perform various functions of the present disclosure.

[0093] The memory 604 may include volatile or non-volatile memory. The memory 604 may store computer-readable, computer-executable code including instructions when executed by the processor 602 cause the NE 600 to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such the memory 604 or another type of memory. Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.

[0094] In some implementations, the processor 602 and the memory 604 coupled with the processor 602 may be configured to cause the NE 600 to perform one or more of the functions described herein (e.g., executing, by the processor 602, instructions stored in the memory 604). For example, the processor 602 may support wireless communication at the NE 600 in accordance with examples as disclosed herein. The NE 600, referred to as a first NE, may be configured to support a means receive a user request in natural language specifying a desired network treatment for a particular application, cause the user request to be processed using a language processingAttorney Docket No. PC934517WOmodel, to extract one or more policy parameters including at least a Quality-of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network, receive a first request from the language processing model for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application, obtain, in response to the first request received from the language processing model, the traffic flow descriptors, send the traffic flow descriptors to the language processing model, receive a second request from the language processing model including a PCC rule, the PCC rule based on the extracted one or more policy parameters and the traffic flow descriptors, and initiate installation of the PCC rule into the core network, in response to receipt of the second request.

[0095] The controller 606 may manage input and output signals for the NE 600. The controller 606 may also manage peripherals not integrated into the NE 600. In some implementations, the controller 606 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems. In some implementations, the controller 606 may be implemented as part of the processor 602.

[0096] In some implementations, the NE 600 may include at least one transceiver 608. In some other implementations, the NE 600 may have more than one transceiver 608. The transceiver 608 may represent a wireless transceiver. The transceiver 608 may include one or more receiver chains 610, one or more transmitter chains 612, or a combination thereof.

[0097] A receiver chain 610 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium. For example, the receiver chain 610 may include one or more antennas for receive the signal over the air or wireless medium. The receiver chain 610 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal. The receiver chain 610 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal. The receiver chain 610 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.

[0098] A transmitter chain 612 may be configured to generate and transmit signals (e.g., control information, data, packets). The transmitter chain 612 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium. The at least one modulator may be configured to support one or more techniques such as amplitudeAttorney Docket No. PC934517WOmodulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM). The transmitter chain 612 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium. The transmitter chain 612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.

[0099] Figure 7 illustrates a flowchart of a method in accordance with aspects of the present disclosure. The operations of the method may be implemented by a NE as described herein. In some implementations, the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.

[0100] At 702, the method may include receiving a user request in natural language specifying a desired network treatment for a particular application. In some implementations, aspects of the operations of 702 may be performed by a NE as described with reference to Figure 6.

[0101] At 704, the method may include causing the user request to be processed using a language processing model, to extract one or more policy parameters including at least a Quality- of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network’s policy framework. In some implementations, aspects of the operations of 704 may be performed by a NE as described with reference to Figure 6.

[0102] At 706, the method may include receiving a first request from the language processing model for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application. In some implementations, aspects of the operations of 706 may be performed by a NE as described with reference to Figure 6.

[0103] At 708, the method may include obtaining, in response to the first request received from the language processing model, the traffic flow descriptors. In some implementations, aspects of the operations of 708 may be performed by a NE as described with reference to Figure 6.

[0104] At 710, the method may include sending the traffic flow descriptors to the language processing model. In some implementations, aspects of the operations of 710 may be performed by a NE as described with reference to Figure 6.

[0105] At 712, the method may include receiving a second request from the language processing model including a PCC rule, the PCC rule based on the extracted one or more policy parametersAttorney Docket No. PC934517WOand the traffic flow descriptors. In some implementations, aspects of the operations of 712 may be performed by a NE as described with reference to Figure 6.

[0106] At 714, the method may include initiating installation, in response to the second request received from the language processing model, the PCC rule into the core network’s policy framework. In some implementations, aspects of the operations of 714 may be performed by a NE as described with reference to Figure 6.

[0107] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0108] It should be noted that the method described herein describes a possible implementation, and that the operations and the steps may be rearranged or otherwise modified and that other implementations are possible.

[0109] The description herein is provided to enable a person having ordinary skill in the art to make or use the disclosure. Various modifications to the disclosure will be apparent to a person having ordinary skill in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not limited to the examples and designs described herein but is to be accorded the broadest scope consistent with the principles and novel features disclosed herein.Attorney Docket No. PC934517WO

Claims

24CLAIMS1. A network equipment, NE, for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the NE to: receive a user request in natural language specifying a desired network treatment for a particular application; cause the user request to be processed using a language processing model, to extract one or more policy parameters including at least a Quality-of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network; receive a first request from the language processing model for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application; obtain, in response to the first request received from the language processing model, the traffic flow descriptors; send the traffic flow descriptors to the language processing model; receive a second request from the language processing model including a PCC rule, the PCC rule based on the extracted one or more policy parameters and the traffic flow descriptors; and initiate installation of the PCC rule into the core network, in response to receipt of the second request.

2. The network equipment of claim 1, wherein the PCC rule includes at least a service data flow component and a QoS policy component.

3. The network equipment of claim 2, wherein the PCC rule includes a QoS policy component comprising a 5G QoS Indicator, 5QI, value, an Allocation and Retention Priority, ARP, with priority level and preemption parameters, and a service data flow component comprising the traffic flow descriptors for uplink and / or downlink directions, such that the PCC rule is parseable by a 5G core Policy Control function.Attorney Docket No. PC934517WO4. The network equipment of claim 2 or 3, wherein the service data flow component is derived based on the traffic flow descriptors and includes one or more of IP addresses, IP packet prefixes, protocol identifiers, port numbers, and other packet identifiers.

5. The network equipment of any preceding claim, wherein the processor is configured to cause the NE to process the user request using a local language processing model installed at the NE or using a remote language processing model accessed via an Application Programming Interface, API.

6. The network equipment of any preceding claim, wherein the processor is configured to cause the NE to obtain the traffic flow descriptors using a first tool installed at the NE and initiate installation of the PCC rule into a core network’s policy framework using a second tool installed at the NE.

7. The network equipment of claim 6, wherein the first tool maintains a library of applications and matching traffic flow descriptors for each application, and the processor is configured to cause the NE to match the identification of the particular application to an entry in the library and fetch the corresponding traffic flow descriptors.

8. The network equipment of any preceding claim, wherein the processor is configured to cause the NE to initiate installation of the PCC rule into a core network’s policy framework by invoking a RESTful API exposed by the core network, and to receive a confirmation indicating that the policy has been applied.

9. The network equipment of any preceding claim, wherein the processor is configured to cause the NE to utilise a third tool to query the core network’s policy framework to retrieve subscription data including one or more stored PCC rules and verify their contents.Attorney Docket No. PC934517WO10. The network equipment of claim 9, wherein the processor is configured to cause the NE to provide feedback or a summary of the installed subscription data to the user and to log the outcome for audit purposes, based upon the retrieved subscription data.

11. The network equipment of any preceding claims, wherein the processor is configured to cause the NE to compare the user request or the PCC rule against existing policies to identify overlaps or contradictions and, if a potential conflict is detected, to obtain a merged PCC rule and / or alert the user.

12. A system comprising the network equipment of any preceding claim, the system further comprising a network bridge module configured to receive the PCC rule from the NE and to install or update the PCC rule in the core network’s policy framework.

13. The system of claim 12, wherein the network bridge module is adapted for a 5G core network and writes the PCC rule into a 5G core network’s subscription database directly or via a Unified Data Repository, UDR, such that the PCC rule is stored under a specified subscriber or network slice profile and is immediately enforceable by core network functions for any matching traffic.

14. A method performed by a network equipment, the method comprising: receiving a user request in natural language specifying a desired network treatment for a particular application; causing the user request to be processed using a language processing model, to extract one or more policy parameters including at least a Quality-of-Service, QoS, level, wherein the one or more policy parameters are extracted by mapping the desired network treatment to QoS levels supported by a core network’s policy framework; receiving a first request from the language processing model, for traffic flow descriptors for the particular application, wherein the traffic flow descriptors comprise network identifiers for the particular application; obtaining, in response to the first request received from the language processing model, the traffic flow descriptors; sending the traffic flow descriptors to the language processing model;Attorney Docket No. PC934517WO27 receiving a second request from the language processing model including a PCC rule, the PCC rule based on the extracted one or more policy parameters and the traffic flow descriptors; and initiating installation, in response to the second request received from the language processing model, the PCC rule into the core network’s policy framework.

15. The method of claim 14, wherein the PCC rule includes at least a service data flow component and a QoS policy component.

16. The method of claim 15, wherein the PCC rule includes a QoS policy component comprising a 5G QoS Indicator, 5QI, value, an Allocation and Retention Priority, ARP, with priority level and preemption parameters, and a service data flow component comprising the traffic flow descriptors for uplink and / or downlink directions, such that the PCC rule is parseable by a 5G core Policy Control function.

17. The method of claim 15 or 16, wherein the service data flow component is derived based on the traffic flow descriptors and includes one or more of IP addresses, IP packet prefixes, protocol identifiers, port numbers, and other packet identifiers.

18. The method of any of claims 14 to 17 and comprising processing the user request using one of a local language processing model or a language processing model accessible via an Application Programming Interface, API.

19. The method of any of claims 14 to 18 and comprising obtaining the traffic flow descriptors using a first tool installed at the NE and initiating installation of the PCC rule into a core network’s policy framework using a second tool installed at the NE.

20. the method of claim 19, wherein the first tool maintains a library of applications and matching traffic flow descriptors for each application, the method comprising matching the identification of the particular application to an entry in the library and fetching the corresponding traffic flow descriptors.Attorney Docket No. PC934517WO

Images