SYSTEMS AND METHODS FOR SUPPORTING NETWORK SLICE SERVICES USING TRANSPORT DEVICES

A system comprises one or more devices. The devices are configured to: receive a context associated with a flow of packets between a User Equipment device (UE) and a network slice in a wireless network; obtain one or more policy rules; apply the policy rules to the context and a model of a transport device to generate or update a map that assigns one or more contexts to queues within the transport device; and send the map to the transport device. The transport device is configured to: adjust parameters of the queues based on the map; shape traffic from each of the queues; schedule packets from the queues; and forward the scheduled packets.

BACKGROUND INFORMATION

General Packet Radio Service (GPRS) is a radio communication standard for mobile devices. When a mobile device establishes a connection with a base station, the mobile device creates a logical tunnel between the mobile device and the base station in accordance with a GPRS tunneling protocol (GTP)—a tunneling protocol based on the GPRS. The logical tunnel is referred to as a GTP tunnel.

A GTP tunnel may include a GTP-User Plane (GTP-U) tunnel. The GTP-U tunnel carries encapsulated protocol data units (PDUs) between the endpoints. The header of a PDU of a GTP-U tunnel may include information that characterizes the GTP-U tunnel and the PDU, such as a Tunnel Endpoint Identifier (TEID) that indicates to which tunnel the PDU belongs.

DETAILED DESCRIPTION

A User Equipment device (UE) and a cellular network may conduct a protocol data unit (PDU) session between them over a GTP-U tunnel (or simply a GTP-U). The GTP-U may be characterized by a context for the PDU session. Transport domain components (e.g., components associated with data transport between a Central Unit-User Plane (CU-CP) and a Distributed Unit (DU), gNB, etc.), however, do not typically expose the context at the transport domain level. In the absence of such information at the transport domain level, it is difficult to achieve a fine-grained control over transport resources to enforce network slice-based Service Level Agreements (SLAs).

Network components exchange various identifiers (IDs), such as a network slice-ID, a Fifth Generation Quality of Service ID (5QI), a User Equipment ID or UE device ID (UE-ID), and a Data Radio Bearer ID (DRB-ID) during creation of a GTP-U tunnel, as part of bearer setup procedures in the mid-haul network. These identifiers may represent traffic per network slice, per QoS, per flow, per UE, and/or per DRB, and may provide a context for the session. The context is herein referred to as a GTP-U tunnel context (also referred to as a GTP-U context, a PDU session context, a PDU context, or simply as a context). By having an access network (e.g., a radio access network (RAN)) expose GTP-U tunnel contexts, it is possible to leverage the GTP-U contexts for 5G network slice deployments, to ensure adherence to 5G network slice-based SLAs at the transport level.

The systems and methods described herein relate to supporting network slice services using transport devices. More particularly, a transport system may comprise at least one transport controller and one or more transport devices (also simply referred to as transport devices). A transport controller receives GTP tunnel contexts from a radio access network and uses the contexts to generate, for each transport device, a corresponding map of the contexts to queues within the transport device. The transport controller sends the generated map to each transport device. Each transport device uses the map to achieve a fine-grained control over its traffic shaping and packet scheduling to effectively meet SLAs for each service flow to/from network slices.

FIG.1illustrates an overview of an exemplary transport system, according to an implementation. As shown, an environment100includes a cellular network200and a UE202(e.g., a smart phone). Cellular network200may include network slices212(e.g., a logical network) and a transport system214. Network200, UE202, network slices212, and transport system214are described in greater detail below with reference toFIGS.2-11. InFIG.1, when or after UE202establishes a communication path102to a particular network slice212to receive a service, transport system214obtains a context from part of102. Transport system214uses the context to achieve a fine-grained control over various flows to/from UE202from/to the network slice212.

FIG.2illustrates network200in which transport system214ofFIG.1may be implemented. As shown, network200may include a UE202, an access network204, a core network206, and a data network208. UE202may include a wireless computational, communication device. Examples of UE202include: a smart phone; a tablet device; a wearable computer device (e.g., a smart watch); a global positioning system (GPS) device; a laptop computer; a media playing device; a portable gaming system; an autonomous vehicle navigation system; a sensor, such as a pressure sensor; and an Internet-of-Things (IoT) device. In some implementations, UE202may correspond to a wireless Machine-Type-Communication (MTC) device that communicates with other devices over a machine-to-machine (M2M) interface, such as LTE-M or Category M1 (CAT-M1) devices and Narrow Band (NB)-IoT devices.

Access network204may allow UE202to access core network206. To do so, access network204may establish and maintain, with participation from UE202, an over-the-air channel with UE202; and maintain backhaul channels with core network206. Access network204may relay information through these channels, from UE202to core network206and vice versa. Access network204may include a Long-term Evolution (LTE) radio network and/or a Fifth Generation (5G) radio network or other advanced radio network. These networks may include many central units (CUs), distributed units (DUs), radio units (RUs), and wireless stations, one of which is illustrated inFIG.2as access station210for establishing and maintaining over-the-air channel with UE202. Access station210may include a 4G, 5G, or another type of base station (e.g., eNB, gNB, etc.) that comprise one or more radio frequency (RF) transceivers. In some implementations, access station210may be part of an evolved Universal Mobile Telecommunications Service (UMTS) Terrestrial Network (eUTRAN).

Core network206may manage communication sessions of subscribers connecting to core network206via access network204. For example, core network206may establish an Internet Protocol (IP) connection between UEs202and data network208. In some implementations, core network206may include a 5G core network. In other implementations, core network206may include a 4G core network (e.g., an evolved packet core (EPC) network) or another type of core network.

The components of core network206may be implemented as dedicated hardware components or as virtualized functions implemented on top of a common shared physical infrastructure using Software Defined Networking (SDN). For example, an SDN controller may implement one or more of the components of core network206using an adapter implementing a Virtual Network Function (VNF) virtual machine, a container, an event driven server-less architecture interface, and/or another type of SDN component. The common shared physical infrastructure may be implemented using one or more devices1100described below with reference toFIG.11in a cloud computing center associated with core network206. Exemplary components of core network206are described below with reference toFIG.4.

As shown, core network206may include one or more network slices212. Depending on the implementation, network slices212may be implemented within other networks, such as access network204and/or data network208. Access network204, core network206, and data network208may include multiple instances of network slices212. Each network slice212may be instantiated as a result of “network slicing,” which involves a form of virtual network architecture that enables multiple logical networks to be implemented on top of a shared physical network infrastructure using the SDN and/or network function virtualization (NFV). Each logical network, referred to as a “network slice,” may encompass an end-to-end virtual network with dedicated storage and/or computational resources that include access network components, clouds, transport, Central Processing Unit (CPU) cycles, memory, etc. Furthermore, each network slice212may be configured to meet a different set of requirements and may be associated with a particular Quality of Service (QoS) class, a type of service, 5QI, and/or a particular group of enterprise customers associated with communication devices.

Each network slice212may be associated with an identifier, herein referred to as a Single Network Slice Selection Assistance Information (S-NSSAI) and/or a network slice instance ID. Each UE202that is configured to access a particular network slice may be associated with corresponding subscription data, stored in core network206for example, that includes the S-NSSAI corresponding to the network slice.

Data network208may include one or more networks connected to core network206. In some implementations, a particular data network208may be associated with a data network name (DNN) in 5G, and/or an Access Point Name (APN) in 4G, and a UE202may request a connection to data network208using a DNN or APN. Data network208may include, and/or be connected to and enable communication with, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), an autonomous system (AS) on the Internet, an optical network, a cable television network, a satellite network, another wireless network (e.g., a Code Division Multiple Access (CDMA) network, a general packet radio service (GPRS) network, and/or an LTE network), an ad hoc network, a telephone network (e.g., the Public Switched Telephone Network (PSTN) or a cellular network), an intranet, or a combination of networks. Data network208may include an application server (also simply referred to as application). An application may provide services for a program or an application running on UE202and may establish communication session with UE202via core network206.

Although not shown inFIG.2, network200may include a transport network to bridge access network204and core network206. Such a transport network may include a transport system214and one or more components of access network204and/or core network206. As indicated above, transport system214may support network slice services. Transport system214may receive tunnel contexts from access network204and/or core network206and use the contexts to generate, for each transport device, a corresponding map of the contexts to queues within the transport device. Each transport device may use the map to achieve a fine-grained control over traffic shaping and packet scheduling to effectively meet SLAs for each service or flow to/from network slices212.

Depending on the implementation, network200may include additional networks and components than those illustrated inFIG.2. For clarity, however,FIG.2does not show all components that may be included in environment200(e.g., routers, bridges, wireless access point, additional UE devices, switches, etc.).

FIG.3depicts exemplary components of transport system214according to an implementation. As shown, transport system214may include an analyzer302, a transport controller304, a policy designer306, and transport devices308-1through308-N(collectively referred to as transport devices308and generically as transport device308). Depending on the implementation, transport system214may include additional, fewer, different or a different arrangement of devices than those shown inFIG.3.

Network components300may include components of access network204and/or core network206. These components may provide control plane signals (CPS)310(including Key Performance Indicators (KPIs)), and contexts312-2to analyzer302and transport controller304. CPS310may include signals from which analyzer302can obtain the context and a TEID; and contexts310-2may include 4-tuples (i.e., UE-ID, 5QI, a network slice ID, and a DRB-ID). The KPIs may include parameters that pertain to one or more sessions, DRBs, UEs, etc., such as a delay, jitter, throughput, etc. Network components300may provide CPS310, contexts310-2and the KPIs either in response to requests from analyzer302and transport controller304or as part of its notification services.

Analyzer302may receive CPS310from network components300and extract, from CPS310, GTP-U tunnel contexts and packet information (e.g., TEID, UE-ID, source IP address, destination IP address, port numbers, etc.). Analyzer302may forward the extracted GTP-U contexts to a tunnel context database in transport controller304, via database services exposed by a database manager (e.g., insert, delete, and update services).

Transport controller304may receive contexts312-1from analyzer302, contexts312-2from network components300, and/or policies314from policy designer306. Transport controller304may use contexts312, policies314, and/or KPIs (not shown) to generate, for each transport device308, a corresponding map and instructions. Given a transport device, the map designates or assigns contexts to queues within the transport device308. The instructions may specify parameters for traffic shaping and scheduling, as well as other parameters associated with processing packets. As shown, transport controller304may send the map and the instructions to transport devices308as part of Transport Control Signals (TCS)316-1through316-M (collectively referred to as TCSs316and generically as TCS316). Transport controller304may receive transport device signals (TDS)318-1through318-M from transport devices308. TDS318may include values of monitored parameters and responses to queries from transport controller304. Transport controller304may use information that TDS318provides in updating device models, as explained below with reference toFIG.5.

Policy designer306may receive user inputs for designing traffic flow policies (e.g., rules on how to treat traffic flows that are part of a DRB) for different flow types. The user input may specify properties and/or requirements per UE, per slice, and per 5QI, for example, when not combined as a DRB. Based on user input and/or other parameters (e.g., parameters from NWDAF416), policy designer306may generate the traffic flow policies314and send traffic flow policies314to transport controller304(e.g., distribute policies to a policy database in transport controller304) in accordance with user instructions. The generated traffic flow policies314may include: flow policies that specify or refer to Committed Information Rate (CIR), Excess Information Rate (EIR), weights for flows and/or network slices212; Weighted Random Early Detection (WRED) policies (e.g., policies for setting queueing thresholds for PDUs with different properties); DRB policies that refer to uplink (UL) and/or downlink (DL) properties; etc.

Transport devices308may include devices within transport domains. A transport domain may extend, for example, from an edge of access network204to an edge of core network206(e.g., a mid-haul network). Transport device308may be implemented as a router, a switch, a gateway, or another device within the transport domain. Transport device308may receive TCS316, which includes a map and configuration instructions, from transport controller304; use the map to assign each context to a queue within the device308and use the instructions to configure traffic shaping, PDU scheduling, and/or other PDU processing.

Each transport device308may monitor different parameters, such as flow throughput, delay, jitter, number of packets dropped per queue, average queue-size, etc., and provide the monitored values of the parameters to transport controller304.

FIG.4illustrates exemplary network components300, in access network204and core network206, that may provide CPS310to analyzer302and contexts312to transport controller304, according to an implementation. As shown, network components300may include core network components, such as an Access and Mobility Management Function (AMF)402, a Session Management Function (SMF)404, a user Plane Function (UPF)406, a Policy Control Function (PCF)408, a Unified Data Management (UDM)410, a Unified Data Repository (UDR)412, a Network Slice Selection Function (NSSF)414, and a Network Data Analytics Function (NWDAF)416, as well as access network components, such as an access station210. Each of components402-416and210may include network device1100or be implemented on one or more network devices1100. Depending on the implementation, network components300may include additional, fewer, and/or different 5G core network components and/or access network components than those illustrated inFIG.4.

AMF402may perform registration management, connection management, reachability management, mobility management, lawful intercepts, Short Message Service (SMS) transport between UE202and a Short Message Service Function (SMSF), session management messages transport between UE202and SMF404, access authentication and authorization, location services management, functionality to support non-Third Generation Partnership Program (3GPP) access networks, and/or other types of management processes. When AMF402receives UE-related requests from access station210(a request to establish a session). AMF402may obtain a number of parameters, such as UE-ID, 5QI, etc. AMF402may be configured to provide such parameters to analyzer302, for example.

SMF404may perform session establishment, session modification, and/or session release, perform Internet Protocol (IP) address allocation and management, perform Dynamic Host Configuration Protocol (DHCP) functions, perform selection and control of UPF406, configure traffic steering at UPF406to guide the traffic to the correct destinations, terminate interfaces toward PCF408, perform lawful intercepts, charge data collection, support charging interfaces, control and coordinate of charging data collection, terminate session management parts of Non-Access Stratum (NAS) messages, perform downlink data notification, manage roaming functionality, and/or perform other types of control plane processes for managing user plane data. When SMF404receives requests from a gNB or a CU-CP to establish a session, for example, SMF404may obtain one or more of a 4-tuple context. SMF404may be configured to provide the obtained values to analyzer302and/or transport controller304as a context. In some implementations, SMF404may provide network slice-related information (e.g., traffic congestion) to transport controller304, to aid transport controller304in generating maps for transport devices308.

UPF406may maintain an anchor point for intra/inter-RAT mobility, maintain an external PDU point of interconnect to a particular data network (e.g., data network208), perform packet routing and forwarding, perform the user plane part of policy rule enforcement, perform packet inspection, perform lawful intercept, perform traffic usage reporting, perform Quality of Service (QoS) handling in the user plane, perform uplink traffic verification, perform transport level packet marking, perform downlink packet buffering, forward an “end marker” to a RAN node (e.g., gNB), and/or perform other types of user plane processes. During exchange of signals between SMF404and UPF406, UPF406may obtain components of a 4-tuple context. UPF406may be configured to provide one or more of the 4-tuple context to either analyzer302and/or to transport controller304.

PCF408may support policies to control network behavior, provide policy rules to control plane functions (e.g., to SMF404), access subscription information relevant to policy decisions, perform policy decisions, and/or perform other types of processes associated with policy enforcement.

UDM410may maintain subscription information for UEs202, manage subscriptions, generate authentication credentials, handle user identification, perform access authorization based on subscription data, perform network function registration management, maintain service and/or session continuity by maintaining assignment of SMF404for ongoing sessions, support SMS delivery, support lawful intercept functionality, and/or perform other processes associated with managing user data. UDR412may store information that UDM410manages. When analyzer302obtains one or more components of a 4-tuple context, and if there are UE-related information that analyzer304and/or transport controller304needs, analyzer302and/or transport controller304may query UDM410/UDR412(e.g., a particular form of UE-ID (e.g., Subscription Permanent Identifier (SUPI)).

NSSF414may select a set of network slice instances to serve a particular UE202, determine network slice selection assistance information (NSSAI) or a Single-NSSAI (S-NSSA), identify a particular AMF to serve a particular AMD102, and/or perform other types of processing associated with network slice selection or management. Analyzer302and/or transport controller304may, if necessary, query NSSF414to verify network slice information for a particular UE202.

NWDAF416may collect analytics information associated with radio access network120and/or core network206. For example, NWDAF416may collect accessibility Key Performance Indicators (KPIs) (e.g., a Radio Resource Control (RRC) connection setup success rate, a Radio Access Bearer (RAB) success rate, etc.), retainability KPIs (e.g., a call drop rate, etc.), mobility KPIs (e.g., a handover success rate, etc.), service integrity KPIs (e.g., downlink average throughput, downlink maximum throughput, uplink average throughput, uplink maximum throughput, etc.), utilization KPIs (e.g., resource block utilization rate, average processor load, etc.), availability KPIs (e.g., radio network unavailability rate, etc.), traffic KPIs (e.g., downlink traffic volume, uplink traffic volume, average number of users, maximum number of users, a number of voice bearers, a number of video bearers, etc.), response time KPIs (e.g., latency, packet arrival time, etc.), and/or other types of wireless network KPIs.

NWDAF416may be configured to provide one or more of the KPIs to transport controller304for generating maps and/or instructions for configuring transport devices308. In some implementations, NWDAF416may provide some KPIs to policy designer306, to aid in designing flow policies.

Access station210may provide one or more components of a 4-tuple context to analyzer302and/or transport controller304. As used herein, the term “access station” may refer not only to a base station (e.g., gNB) but also to a CU-CP, a CU-UP, and/or a DU.

FIG.5shows exemplary components of transport controller304according to an implementation. As shown, transport controller304may include a database (DB) manager500, a tunnel context DB502, a transport device manager504, a configuration generator506, a policy engine508, and a policy DB510. Depending on the implementation, transport controller304may include additional, fewer, different, or a different arrangement of components than those shown inFIG.5.

DB manager500may expose services to insert, delete, and/or update database entries for each database that may be included in transport controller304(e.g., DB502,512,514,516,518, or520or other databases not shown inFIG.5). For example, DB manager500may receive designs (e.g., from Open Network Automation Platform (ONAP) Service Design Center (SDC)). DB manager500may provide notification services to database subscribers (e.g., configuration generator506). For example, if configuration generator506is subscribed to the notification service for DB502, DB manager500may notify configuration generator506when a new database record is inserted into DB502or an old record in DB502is updated.

Tunnel context DB502may include contexts from network components300and/or analyzer302. Configuration generator506may access tunnel context DB502via DB manager500. In some implementations, when a tunnel context in tunnel context DB502changes, DB manager500may notify configuration generator506.

Transport device manager504may configure transport devices308. More specifically, transport device manager504may use a device model (received from configuration generator506) to generate instructions for transport devices308and send the model and/or the instructions as part of a transport control signals (TCS)316. When generating instructions, transport device manager504may take into account physical device settings, parameters, and configurations that are stored in a device configuration DB512. In some implementations, transport device manager504may use per-device-type plugins that handles each device type. Device-type plugins may be retrieved from device configuration DB512.

Configuration generator506may generate maps for configuring transport devices308and forward the maps to transport device manager504. Each map may indicate how logical flows are assigned to particular ingress queues of a transport device308, as well as parameter values for traffic shaping and policing at a particular transport device308.

Configuration generator506may generate a map when configuration generator506is notified of or detects a new logical flow. In response to a notification, configuration generator506assigns a new logical flow ID to the new flow. Configuration generator506may store information pertaining to the flow in a logical low DB514.

As indicated above, configuration generator506may include a device DB516. Device DB516may include parameters of an abstracted device model of a transport device308. For example, device DB516may include two models corresponding to two types of transport devices from different vendors, each with a different number of ports. A device model may be complete when configuration generator506generates a map for the device model and stores the map with other information in device DB516.

To generate a map, configuration generator506may apply design policy rules and flow policy rules (e.g., a policy for a traffic flow) to information in a device model. By applying the policies, configuration generator506may generate a map that completes the device model, where the map assigns a flow to an ingress port of a particular transport device308, as well as contexts to queues in transport device308. Configuration generator506may forward each completed device model (e.g., model specific parameter values and the map for the device308) to transport device manager504.

Because some information in device DB516may depend on the operating parameters of each transport device308, configuration generator506may update device models in device DB516based on device parameter values received from transport devices308, as transport device signals (TDSs)318. TDSs318may comprise monitored parameter values at each transport device308(e.g., device load, throughput, processor utilization, memory used, etc.). Configuration generator506may store the parameter values as part of device models in device DB516. In a different implementation, transport device manager504may receive TDSs318and use the information in TDSs318to update device configuration DB512.

Policy engine508may store design rules in design rules DB518in policy DB510and provide or push these rules to configuration generator506. The design rules in design rules DB518may specify how to determine properties of traffic flows. Design rules may specify, for example, how to combine each of UE properties, slice properties, and 5QI properties to obtain priorities of the flows. More specifically, for example, a rule may specify how to determine the final priority of a flow in accordance with the rule that defines the priority as the product of a 5QI and a network slice priority. In another example, a design rule may specify how to determine an excess information rate (EIR) for a flow as the minimum of UE maximum throughput and the 5QI EIR.

Policy engine518may store flow policies in flow properties DB520in policy DB510and provide or push these rules to configuration generator506. The flow policy rules in flow properties dB520may specify how to modify flow properties. For example, a rule may specify promoting a best effort flow type (identified by a 5QI) within a DRB as a guaranteed bit rate (GBR) flow (e.g. a video stream or a video flow) but not promoting the flow as a delay critical GBR (DC GBR) (e.g., a control loop flow).

FIG.6illustrates a table600that summarizes how transport system214maps flows to DRBs. In the example ofFIG.6, transport system214manages 7 unique flows with 5QIs (see column1of table600). Each flow, which may be associated with a particular 5QI, has a maximum commit bit rate and a minimum latency budget per hop. As further shown, these flows are mapped to DRBs. For example, assume that GRB flow3,4, and6have the maximum commit rate of 20 Mbps (from 5QI of 4 in table600). The flows would be assigned to the DRB with the DRB-ID of 3.

FIG.7illustrates how transport system214might handles individual packets according to an implementation ofFIG.6. Each packet (e.g., 1, 2 and 3) may map to a unique 5QI (e.g., 3, 4, and 6). Assume that the packets arrive over a dedicated GTP tunnels702-1.702-2, and702-3. The flows of the GTP-U tunnels702are aggregated into a DRB700due to similar QoS flow properties. In this implementation, other flows are assigned to other DRBs in accordance with table600.

FIG.8Ashows an example mapping800between different network services and 5QIs, according to an implementation. Mapping800may occur during operation of transport system214. As shown, each network service (e.g., an enhanced mobile broadband (eMBB) gold service, an eMBB silver service, a Push-to-Talk (PTT) service, and a high-definition video (HD VIDEO) service) may be associated with a particular network slice with a particular priority. Each network slice may support multiple 5QIs.

FIG.8Bshows an example mapping (table)850between a combination of a UE and a network slice and a DRB, according to an implementation. Mapping850may occur as a result of operating transport system214. As shown, the first column in table850shows a combination of UE and network slice. A particular UE may request one or more network slices and this is reflected in column1. Columns2,3, and4show a 5QI, a priority for the 5QI and a slice priority, respectively, for each of the UE/slice combinations in column1. Column5indicates which DRB carries the packets for the network slices of column1.

FIG.9depicts exemplary components of transport device308and exemplary processing that is performed at the transport device308. As shown, transport device308may include an ingress pipeline902, a discard stage904, a programmable switch906, and an egress pipeline908. Depending on the implementation, transport device308may include fewer, additional, different, or a different arrangement of components than those depicted inFIG.9.

Ingress pipeline902may receive packets through one or more ingress ports910and pre-process packets in preparation for packet discarding, traffic shaping, and scheduling. For example, as part of the pre-processing, ingress pipeline902may classify916packets based on the flow identifiers of the packets and meter918the packets. Metering918the packets may include, for example, not only counting the packets of a flow, but also obtaining the number of bytes carried by the packets, the number of packets and bytes in reference to a TEID, a UE-ID. And/or a 5QI for the flow, etc. After metering918the packets, ingress pipeline902may color920the packets. Coloring920may include determining the priorities at which the packets were before they were received at the transport device308. After coloring920the packets, ingress pipeline902may forward the packets to discard stage904.

Discard stage904may select and discard packets that are received from ingress pipeline902. Discard stage904may discard packets based on a packet priority/color, a 5QI, a TEID, a UE-ID, and/or another packet characteristic. Discard stage904may forward packets that have not been discarded to programmable switch906.

Programmable switch906may sort and distribute the packets into different queues924-1though924-M, where each queue924is assigned to one or more context values and where each context value comprises a combination of a UE-ID, a 5QI, a network slice ID, and a DRB (i.e., a 4-tuple). The packets from each queue924may be provided to a traffic shaper926(e.g., one of traffic shapers926-1through926-M). Traffic shaper926may slow or speed certain packets based on packet characteristics (e.g., a 5QI, a packet priority, etc.). Traffic shapers926may then pass the packets to a scheduler928. Scheduler928may schedule the packets for transmission/forwarding. Programmable switch906may convey the scheduled packets to egress pipeline908.

Egress pipeline908may apply access control lists (ACL)930to each of the packets from programmable switch906. ACL930may include a list of access controls (criteria) to filter packets. By applying ACL930, egress pipeline908may restrict or limit the flow of traffic, restrict the access by users and devices to a network slice or a network, and/or prevent the traffic from leaving a network. Example applying ACL930may prevent packets with a particular source IP address. a particular destination IP address. etc. from being forwarded to another network device. After applying ACL930. egress pipeline908may forward932each of the packets to a particular port932for transmission to a node in the network.

Transport device308may receive, from transport device manager904, TCS316that includes a map (or a device model) and configuration instructions. The device model and configuration instructions may specify parameter values for ingress pipeline902, discard stage904, programmable switch906, and egress pipeline908. The configuration instructions may specify, for example: packet types into which packets may be classified916, metering918requirements (e.g., what parameter to measure, such as the number of packets or bytes received by transport device308for a particular TEID, UE-ID, etc.), coloring920configuration (e.g., a priority to which each packet is to be assigned based on its context), discarding922requirements, a map (or device model) that indicates which queue924is to be assigned to which 4-tuple contexts, traffic shaper926parameters (e.g., delays for different packets), scheduling928parameters (e.g., an order of precedence for scheduling packets from queues924), and criteria for ACL930(e.g., banned destination IP addresses or source IP addresses). Upon receipt of TCS316, transport device308may configure its ingress pipeline902, discard stage904, programmable switch906, and/or egress pipeline908in accordance with the map and configuration instructions in TCS916.

FIG.10is a flow diagram of an exemplary process1000that is associated with transport system214. Process1000may be performed by network components300and/or components of transport system214. As shown, process1000may include receiving transport device information (block1002). The device information may be provided by a network device, a network operator, an administrator, etc. When transport controller304in system214receives the information, transport controller304may store the information as a device model in device DB516of configuration generator506and/or as parameters in device configuration DB512in transport device manager504.

Process1000may further include receiving and storing policy rules from policy designer306(block1004). For example, a network administrator may use policy designer306to design policy rules and have policy designer306forward the designed policy rules to policy DB510. If the policy rules pertain to modifying flow properties, the rules may be stored in flow properties DB520. If the rules specify using different components of a context (i.e., the elements of a 4-tuple) to arrive at a priority for the flow, the rules may be stored in design rules DB518.

Process1000may further include receiving and storing a flow context (block1006). For example, network components300(e.g., gNB) may send a 4-tuple as a context to transport controller304in transport system214. Database manager500may receive the context and store the context in tunnel context DB502.

When tunnel context DB502stores a new flow context, DB manager500may notify configuration generator506in transport controller304with new flow information. When configuration generator805receives the flow information (block1008), configuration generator506may assign a new flow ID to the flow and store the flow ID with the flow information in flow DB514. Furthermore, configuration generator506may query policy engine508to retrieve policy rules applicable to the flow, from design rules DB518and flow properties DB520(block1008). Policy engine510may retrieve and provide the requested rules to configuration generator506.

Process1000may further include configuration generator506applying the policy rules provided by policy engine508and the flow information (received from tunnel context DB502(block1010). By applying the rules, configuration generator506may generate a map that assigns queue of transport devices308to contexts (block1012). Context generator506may combine the map with the device information to complete a device model (block1012). Configuration generator506may send the completed device model to transport device manager504(block1014).

When transport device manager504receives the device model, transport device manager504may generate a set of instructions and/or configuration parameters for one or more target transport devices308. Transport device manager504may send the model/map and the generated configuration instructions/settings to the transport devices (block1018), as TCS316. When transport devices308receive the maps and/or the instructions, each transport device308may configure its internal components, such as ingress pipeline902, discard stage904, programmable switch906, and egress pipeline908(block1018), as described above with reference toFIG.9.

The transport devices308may process packets of the new flow in accordance with their new configurations. During their operation, transport devices308may provide TDSs318to transport controller304(e.g., have configuration generator506update its device DB416) (block1020).

FIG.11depicts exemplary components of an exemplary network device1100. Network device1100may correspond to or be included in any of the devices and/or components illustrated inFIGS.1-5and9(e.g., UE202, access network204, core network206, data network208, access station210, transport system214, NFs402-416, components in transport device308, etc.). In some implementations, network devices1100may be part of a hardware network layer on top of which other network layers and NFs may be implemented.

As shown, network device1100may include a processor1102, memory/storage1104, input component1106, output component1108, network interface1110, and communication path1112. In different implementations, network device1100may include additional, fewer, different, or different arrangement of components than the ones illustrated inFIG.12. For example, network device1100may include line cards, switch fabrics, modems, etc.

Processor1102may include a processor, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), programmable logic device, chipset, application specific instruction-set processor (ASIP), system-on-chip (SoC), central processing unit (CPU) (e.g., one or multiple cores), microcontrollers, and/or other processing logic (e.g., embedded devices) capable of controlling network device1100and/or executing programs/instructions.

Memory/storage1104may include static memory, such as read only memory (ROM), and/or dynamic memory, such as random access memory (RAM), or onboard cache, for storing data and machine-readable instructions (e.g., programs, scripts, etc.).

Memory/storage1104may also include a CD ROM, CD read/write (R/W) disk, optical disk, magnetic disk, solid state disk, holographic versatile disk (HVD), digital versatile disk (DVD), and/or flash memory, as well as other types of storage device (e.g., Micro-Electromechanical system (MEMS)-based storage medium) for storing data and/or machine-readable instructions (e.g., a program, script, etc.). Memory/storage1104may be external to and/or removable from network device1100. Memory/storage1104may include, for example, a Universal Serial Bus (USB) memory stick, a dongle, a hard disk, off-line storage, a Blu-Ray® disk (BD), etc. Memory/storage1104may also include devices that can function both as a RAM-like component or persistent storage, such as Intel® Optane memories.

Depending on the context, the term “memory,” “storage,” “storage device,” “storage unit,” and/or “medium” may be used interchangeably. For example, a “computer-readable storage device” or “computer-readable medium” may refer to both a memory and/or storage device.

Input component1106and output component1108may provide input and output from/to a user to/from network device1100. Input/output components1106and1108may include a display screen, a keyboard, a mouse, a speaker, a microphone, a camera, a DVD reader, USB lines, and/or other types of components for obtaining, from physical events or phenomena, to and/or from signals that pertain to network device1100.

Network interface1110may include a transceiver (e.g., a transmitter and a receiver) for network device1110to communicate with other devices and/or systems. For example, via network interface1110, network device1100may communicate over a network, such as the Internet, an intranet, cellular, a terrestrial wireless network (e.g., a WLAN, WIFI, WIMAX, etc.), a satellite-based network, optical network, etc. Network interface1110may include a modem, an Ethernet interface to a LAN, and/or an interface/connection for connecting network device1100to other devices (e.g., a Bluetooth interface).

Communication path or bus1112may provide an interface through which components of network device1100can communicate with one another.

Network device1100may perform the operations described herein in response to processor1102executing software instructions stored in a non-transient computer-readable medium, such as memory/storage1104. The software instructions may be read into memory/storage1104from another computer-readable medium or from another device via network interface1110. The software instructions stored in memory/storage1104, when executed by processor1102, may cause processor1102to perform one or more of the processes that are described herein.

In the above, while series of messages, signals, and acts have been described withFIGS.9and10, the order of the messages, signals, and acts may be modified in other implementations. In addition, non-dependent messages, signals, and acts may represent messages, signals, and acts can be sent, received, and/or performed in parallel and in different orders.

Further, certain portions of the implementations have been described as “logic” that performs one or more functions. This logic may include hardware, such as a processor, a microprocessor, an application specific integrated circuit, or a field programmable gate array, software, or a combination of hardware and software.

No element, block, or instruction used in the present application should be construed as critical or essential to the implementations described herein unless explicitly described as such. Also, as used herein, the articles “a,” “an,” and “the” are intended to include one or more items. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.