Patent ID: 12231920

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating a first example network system, in accordance with one or more techniques of this disclosure. In the example illustrated inFIG.1, network system100includes the centralized user configuration (CUC)102, a central network controller (CNC)104, a service orchestrator110including a network slice unit114, a radio access network (RAN) domain122, a transport network domain132, and a core network domain142. The RAN domain122includes a RAN domain orchestrator124and one or more RAN elements126. The transport network domain132includes a transport network domain orchestrator134, an embedded CNC136, and forwarding path element(s)138. Core network domain142includes a core network domain orchestrator144, and one or more core network elements146. A service management and orchestration (SMO) unit150includes service orchestrator110, RAN domain orchestrator124, transport network domain orchestrator134, and core network domain orchestrator144.

Time sensitive networking (TSN) may refer to one or more network standards that define communication of packets over a network, such as network system100ofFIG.1. When a network implements TSN, one or more devices connected to the network may be synchronized such that each device of the one or more devices knows a current network time, and the one or more devices work in synchrony to transmit information over the network in a more time-efficient manner as compared with networks that do not implement TSN. For example, a central time source may distribute one or more time synchronization instructions to endpoint devices. Once the endpoint devices receive time synchronization instructions, it may be possible for endpoint devices to communicate over the network according to one or more TSN protocols. In some examples, the network may use the precision time protocol (PTP), the generic PTP (gPTP), or another protocol in order to time synchronize one or more devices one or more devices within the network.

Additionally, or alternatively, one or more TSN protocols may perform traffic shaping in order to solve packet agglomerations more efficiently as compared with networks that do not implement TSN. Packet agglomerations occur when network traffic overwhelms one or more nodes (e.g., switches and/or routers) in the network. Packets may have priority levels so that the network can prioritize some packets over others when packet agglomerations occur. For example, a packet may be assigned one of eight different priority levels. High priority levels may indicate high priority network traffic and low priority levels may indicate low priority network traffic.

In some examples, CUC102is configured to communicate with CNC104. In some examples, CUC102is configured to communicate with CNC104using representational state transfer application programming interfaces (REST APIs). CUC102is configured to output one or more instructions to CNC104in order to control CNC104to configure aspects of network system100. In some examples, CUC102may be configured to output a request to CNC104to determine a network topology of network system100. CNC104may use link layer discovery protocol (LLDP) and a seed device in order to discover each device of the physical topology of network system100and how they are connected, including end devices. After CNC104determines the network topology, CUC102may issue a request for the CNC104to return the discovered topology. The network topology may, in some cases, include a topology of the one or more RAN elements126, the one or more forwarding path elements (FPEs)138, and the core network elements146. Additionally, or alternatively, the network topology may include a topology of end station152, end station154, first UE device162, second UE device164, TSN bridge170, FPEs138, or any combination thereof. In some examples, CUC102may output one or more instructions to synchronize a time of one or more devices within network system100. In some examples, CUC102may generate requests to create one or more flows based on the determined network topology. In some examples, the one or more flows may represent frame retransmission elimination for reliability (FRER) flows.

In some examples, CUC102may identify one or more network resources corresponding to one or more endpoints (e.g., end station152and end station154). For example, CUC102may determine latency requirements for communication between end station152and end station154(e.g., end station154must receive network traffic from end station152within 500 microseconds (μs) from the start of transmission). Additionally, or alternatively, CUC102may determine a maximum size of a packet to be sent between end station152and end station154. CUC102may determine one or more other dependencies (e.g., whether there is a sequence order to the TSN flows). CUC102may send the one or more network resources to CNC104using an application programming interface (API).

CUC102may send one or more requests to create the one or more flows to CNC104. In some examples, the one or more requests may indicate the end station152and the end station154as endpoints. In some examples, CUC102may communicate with the end station152and/or the end station154in order to configure the end station152and/or the end station154in order to support the one or more requested flows between the end station152and the end station154.

In some examples, CUC102may determine that CNC104has identified the topology of the physical network, and that CNC104has received all TSN flow requests. CUC102may send a request for CNC104to compute a schedule for the one or more TSN flows. CNC104may send, to CUC102, a message indicating a success or a failure of computing the schedule. CNC104may be able to determine the schedule once CNC104discovers the physical topology. In some examples, CUC102may request that CNC104return the computed schedule. The computed schedule may, in some examples, include details for each device included in the one or more TSN flows. The details may include information that end devices (e.g., end station152and end station154) and TSN bridges (e.g., TSN bridge170) use to communicate according to the one or more TSN flows. In some examples, the details included in the computed schedule may include one or more unique identifiers for each TSN flow, a start and end of transmit window at each hop, a start and end of receive window at each hop, and an end-to-end latency.

In response to determining that the computed schedule is satisfactory, CUC102may send a request for CNC104to distribute the computed schedule to TSN bridge170. CUC102may program end station152and end station154in order to support the one or more requested TSN flows.

CNC104may, in some cases, receive one or more requests from CUC102. CNC104may, in some examples, be able to communicate with CUC102, service orchestrator110, one or more user equipment (UE) devices (e.g., first UE device162and second UE device164), and one or more TSN bridges (e.g., TSN bridge170). In some examples, the CNC includes a proxy for the network (e.g., one or more TSN bridges, one or more UE devices, and/or one or more end stations). CNC104may control one or more TSN bridges (e.g., TSN bridge170) in the network system100. CNC104may represent a software application running on customer premises (as opposed to cloud). In some examples, CNC104may determine routes and scheduling for TSN flows through TSN bridge107. In some examples, CNC104may configure TSN bridge170for operation.

In some examples, CNC104communicates with CUC102to retrieve one or more communications requirements for one or more requested flows between end station152and end station154. CNC104may collect the one or more requests received from CUC102and the communications requirements received from CUC102. Based on the one or more requests and the communications requirements, CNC104may compute one or more TSN flows between end station152and end station154, CNC104may schedule end-to-end transmission for each TSN flow, and transfer the computed schedule to TSN bridge170. To compute the schedule, CNC104may provide a unique identifier for each TSN flow. This unique identifier may be used by TSN bridges to differentiate one TSN flow from another. The unique identifier may include the destination media access control (MAC) address, virtual local area network identification (VLAN ID), and a class of service (CoS) value. With these three items, the TSN bridges may identify the TSN flow and transmit the flow based on the correct schedule.

CNC104may generate TSN configuration data. In some examples, the TSN configuration data represents information for configuring one or more TSN flows between a pair of endpoints (e.g., between end station152and end station154. The TSN configuration data may be used to implement the computed schedule. A TSN flow may be configured to carry network traffic (e.g., packets) across a network according to one or more TSN protocols. For example, the TSN configuration data may include information for configuring a first TSN flow between end station152and end station154via first UE device162and TSN bridge170. Additionally, or alternatively, the TSN configuration data may include information for configuring a second TSN flow between end station152and end station154via second UE device164and TSN bridge170.

CUC102provides an interface for use by end station152and end station154to provision communication services. In some aspects, CUC102can present a user interface that presents user interface elements (e.g., screens, menus, maps, etc.) as part of a workflow for provisioning a communication service. In some aspects, the user interface and workflow can be an “end-to-end” workflow such that when the workflow is completed, there is enough information available to provisioning portal to create service order that can be used by service orchestrator110for provisioning a desired communication service.

End station152and end station154(collectively, “end stations152,154”) can be or include computing devices that execute a TSN application. Each of end stations152,154, can represent an industrial robot, controller, or other industrial apparatus, a network device such an Ethernet switch or router, a sensor, a conveyor, a motion controller, or other device implementing or requiring time-sensitive networking. End stations152,154may alternatively be referred to as endpoint devices, endpoints, or end devices of one or more TSN flows. For example, one or more TSN flows may exist between end station152and end station154. In some examples, each TSN flow of the one or more TSN flows may correspond to one or more network slices. For example, network slice163connects end station152with end station154via first UE device162and TSN bridge170, and network slice165connects end station152with end station154vie second UE device164and TSN bridge170.

In some examples, TSN bridge170may represent a network device (e.g., an ethernet switch). TSN bridge170may be configured to transmitting and/or receiving frames of a TSN flow (e.g., TSN flows corresponding to network slice163and network slice165) according to a schedule.

CUC102can be communicatively coupled to end station152, and CNC104can be communicatively coupled to service orchestrator110. In the example illustrated inFIG.1, CUC102is executed in a computing environment, which may be provided by a cloud service provider. However, CUC102may be executed in other environments. Service orchestrator110may be a component of a server or other computing device in a data center, such as a data center of a mobile network operator. In addition, some operations attributed herein to CUC102, CNC104, or service orchestrator110may in various examples be performed by CUC102, CNC104, or service orchestrator110.

In some aspects, communication services that may be provisioned using service orchestrator110include network slices. In 5G network environments, network slicing facilitates creations of multiple virtualized and independent logical networks that are multiplexed over the same physical network infrastructure. A network slice can be logically isolated from other network slices and can be customized to meet service level expectations of an application that may be established by a service level agreement (SLA). In the example illustrated inFIG.1, service orchestrator110can create and allocate network slices on the network system100.

Service orchestrator110may receive the TSN configuration data from CNC104. Service orchestrator110may include a network slice unit114that is configured to process the TSN configuration data and control the network system100to implement one or more TSN flows. In some examples, network slice unit114may convert the TSN configuration data into one or more network slice intents. Network slice unit114may translate the TSN configuration data in order to identify one or more endpoints. In some examples, network slice unit114may be referred to as a “TSN to Slice Translator.” Network slice unit114may create a network slice intent corresponding to one or more TSN flows specified in the TSN configuration data. For example, network slice unit114may create a first network slice intent for a first network slice163between first UE device162and TSN bridge170, and network slice unit114may create a second network slice intent for a second network slice165between second UE device164and TSN bridge170. First network slice163may correspond to a first one or more TSN flows indicated by the TSN configuration data. Second network slice165may correspond to a second one or more TSN flows indicated by the TSN configuration data. Alternatively, network slice unit114may reuse an existing network slice for the TSN flows for any of UE devices162and164. For example, service orchestrator110may pre-provision network slices in the mobile network domains in anticipation of transporting TSN flows.

The mobile network ofFIG.1is a multi-domain network including RAN domain122, transport network domain132, and core network domain142. Service orchestrator110may output one or more instructions to RAN domain orchestrator124, transport network orchestrator134for transport network domain, and/or core network orchestrator144for core network domain142in order to implement each network slice intent of the one or more network slice intents generated based on the TSN configuration information. Service orchestrator110may leverage the RAN domain orchestrator124, transport network domain132, and/or core network domain142in order to create the first network slice163between first UE device162and TSN bridge170and the second network slice165between second UE device164and TSN bridge170. For example, RAN domain orchestrator124may execute a RAN network slice subnet management function (RAN NSSMF), transport network domain orchestrator134may execute a transport network NSSMF (TN NSSMF), and core network domain orchestrator144may execute a core network NSSMF (CORE NSSMF). Service orchestrator110may leverage the RAN NSSMF and the CORE NSSMF in order to create a TSN slice subnet management function corresponding to each network slice intent of the one or more network slice intents.

RAN domain122may include RAN domain orchestrator124and one or more RAN elements126. In some examples, RAN domain orchestrator124may configure the one or more RAN elements126in order to connect one or more UE devices to the transport network domain132and the core network domain142. RAN elements126may include one or more wireless towers and/or antennas that are configured to communicate wirelessly with UE devices. In some examples, one or more RAN elements126includes radio units (RUs) located at various cellular network sites (“cell sites”), along with distributed units (DUs) and centralized units (CUs). Each RU consists of an LO PHY and a RF transmitter. The LO PHY component may be implemented using specialized hardware for high-performance packet processing.

RUs can connect to DUs via a fronthaul network. The fronthaul network connects LO PHY and HI PHY and is used by RUs and DUs to implement the F2 interface of 5G. DUs manage the packet transmission of radio by the RUs. In some cases, such packet transmission conforms to the Common Packet Radio Interface (CPRI) and/or to the enhanced CPRI (eCPRI) standard, or to IEEE 1914.3. DUs may implement the Radio Link Control (RLC), Media Access Control (MAC), and the HI PHY layer. DUs are at least partially controlled by CUs.

DUs can connect to CUs via a mid-haul network, which may be used by DUs and CUs to implement the F1 interface of 5G. CUs may implement the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) layers. CUs connect to core105via a backhaul network. The midhaul and backhaul networks may each be wide area networks (WANs).

In some examples, the one or more RAN elements126may include a gNodeB base station. In some examples, the gNodeB base station includes a CU and a DU. In some examples, the CU may support multiple DUs in order to implement multiple gNodeB base stations. Further, one or more radio hardware units (RUs) may be supported by a single DU.

Any DU may or may not be located at the cell site that includes the RU(s) supported by the DU. A DU may be located at a cell site, while other DUs may be located at a local data center and collectively support multiple RUs. Network system100may have radio access networks within the RAN domain122that include many thousands of cell sites and gNodeBs. RAN domain122may connect to core network domain142via transport network domain132. Core network domain142may comprise a 5G core network.

Transport network domain132may provide connectivity between RAN domain122and core network domain142. Additionally, or alternatively, transport network domain132may provide connectivity between disaggregated RAN network functions (e.g., a midhaul connection between DU and CU.142. Transport network domain132may include transport network domain orchestrator134, embedded CNC136, and one or more FPEs138. In some examples, the transport network domain132may include one or more network devices (e.g., routers and/or switches) that represent the one or more FPEs138. One or more of FPEs138may be TSN bridges. The transport network domain orchestrator134and/or embedded CNC136may configure the FPEs138in order to connect the RAN domain122and the core network domain142, and connect disaggregated RAN network functions. For example, the FPEs138may receive network traffic from the one or more RAN elements126and forward the network traffic to the one or more core network elements146. In some examples, it may be beneficial for the transport network domain orchestrator134and/or embedded CNC136to configure the one or more FPEs in order to support one or more network slices.

Core network domain142may include core network domain orchestrator144and one or more core network elements146. In some aspects, resources associated with service to w tenant may be provided by, or managed by, functions of core network domain142and/or components of RAN domain122. In some aspects, core network domain142implements various discrete control plane and user plane functions for network system100. In some aspects, the core network domain orchestrator144of core network domain142includes 5G control plane functions such as Access Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), User Data Management (UDM), Network Repository Function (NRF), Authentication Server Function (AUSF), and Network Slice Selection Function (NSSF). AMF may provide access mobility management services. SMF may provide session management services. PCF may provide policy control services. Unified Data Management (UDM) function may manage network user data. AUSF may provide authentication services. Network Repository Function (NRF) may provide a repository that can be used to register and discover services in a network operator's network. Network Slice Selection Function (NSSF) may be used to select an instance of an available network slice for use by a UE device (e.g., first UE device162and/or second UE device164). The one or more core network elements146may include User Plane Functions (UPFs). UPFs may provide packet routing, forwarding and other network data processing functions (e.g., Quality of Service, packet inspection, traffic optimization etc.).

In some examples, service orchestrator110may be configured to receive, from CNC104, TSN configuration data. The TSN configuration data may indicate end station152and end station154as endpoints. In some examples, the TSN configuration data may indicate one or more requested TSN flows between end station152and end station154. In some examples, service orchestrator110may determine one or more TSN flows based on the TSN configuration data. For example, a first TSN flow may connect end station152and end station154via first UE device162and TSN bridge170, and a second TSN flow may connect end station152and end station154via second UE device164and TSN bridge170. Network slice unit114may translate the TSN configuration data in order to generate one or more network slice intents. For example, network slice unit114may generate a first network slice intent corresponding to the requested TSN flow between the first UE device162and TSN bridge170, and network slice unit114may generate a second network slice intent corresponding to the requested TSN flow between the second UE device164and TSN bridge170. Although described with respect to two separate slices163and165and two separate UE devices162and164, the techniques of this disclosure are applicable to provisioning a single network slice to which a single UE may map TSN flows.

In some examples, to generate the first network slice intent and the second network slice intent, network slice unit114may add some information to the network slice intents that is not present in the TSN configuration data. For example, although the TSN configuration data may indicate end stations152,154as endpoints of the requested TSN flows, the TSN configuration data received from CNC104might not include some information for configuring one or more elements of the RAN domain122, the transport network domain132, and/or the core network domain142in order to support the flows. When network slice unit114converts TSN configuration data into the first network slice intent and the second network slice intent, network slice unit114may generate the network slice intent to include information for leveraging RAN domain orchestrator124, transport network domain orchestrator134, and/or core network domain orchestrator144in order to configure these elements.

Based on the first network slice intent and the second network slice intent, service orchestrator110may leverage RAN domain orchestrator124, transport network domain orchestrator134, and/or core network domain orchestrator144in order to create a first network slice163corresponding to a first network slice intent and a second network slice165corresponding to a second network slice intent. For example, service orchestrator110may leverage a RAN NSSMF executing on the RAN domain orchestrator124and a CORE NSSMF executing on the core network domain orchestrator144in order to create a first TSN slice subnet management function corresponding to the first network slice intent and a second TSN slice subnet management function corresponding to the second network slice intent. Based on the first TSN slice subnet management function and the second TSN slice subnet management function, the RAN domain orchestrator124, the transport network domain orchestrator134, and the core network domain orchestrator144may manage the first network slice163and the second network slice165.

In some examples, service orchestrator110is configured to leverage a TN NSSMF executing on the transport network domain orchestrator134in order to connect the first network slice163and the second network slice165across the one or more FPEs138. For example, first network slice163and second network slice165may each be configured to handle an amount of network bandwidth. Service orchestrator110may leverage the TN NSSMF in order to configure the one or more FPEs138so that both of the first network slice163and the second network slice165support a full amount of allocated network bandwidth. In some examples, the one or more FPEs138may be located on network devices within one or more data centers of the transport network domain132. The TN NSSMF may, in some examples, use a network slice controller in order to connect the first network slice163and the second network slice165across the one or more FPEs138. For example, the network slice controller may configure the one or more FPEs138in order to support a latency, a jitter, an allocated amount of bandwidth, and a quality of service (QoS) associated with each of the first network slice163and the second network slice165.

In some examples, embedded CNC136is configured to activate one or more TSN bridges within the transport network domain132on order to connect the first network slice163and the second network slice165across the one or more FPEs138. In some examples, the one or more TSN bridges may span the one or more FPEs138. Any of the FPEs138may include or represent a TSN bridge.

In some examples, when service orchestrator110leverages the RAN domain orchestrator124, the transport network domain orchestrator134, and/or the core network domain orchestrator144to create the first network slice163and the second network slice165, service orchestrator110creates first slice identification data corresponding to the first network slice163and second slice identification data corresponding to the second network slice165. Service orchestrator110may add the first slice identification data and the second slice identification data to a network slice selection assistance information (NSSAI) list. In some examples, the first slice identification data includes a first TSN slice identification corresponding to the first network slice163and the second slice identification data includes a second TSN slice identification corresponding to the second network slice165. In some examples, the first slice identification data including the first TSN slice identification represents first single network slice selection assistance information (S-NSSAI) and the second slice identification data including the second TSN slice identification represents second S-NSSAI. Once the first network slice163and the second network slice165are created, first UE device162may communicate with TSN bridge170over the first network slice and second UE device164may communicate with TSN bridge170over the second network slice. In some examples, a device in possession of the first S-NSSAI may send packets over the first network slice163and a device in possession of the second S-NSSAI may send packets over the second network slice165.

Service orchestrator110may output network slice identification data. For example, service orchestrator110may output first network slice identification data (e.g., a first S-NSSAI) to first UE device162and service orchestrator110may output second network slice identification data (e.g., a second S-NSSAI) to a second UE device164. In some examples, service orchestrator110may output one or both of the first network slice identification data and the second network slice identification data to the CNC104. CNC104may receive the first network slice identification data and the second network slice identification data and forward the first network slice identification data and the second network slice identification data to the CUC102. The CUC102may receive the first network slice identification data and the second network slice identification data and forward the first network slice identification data and the second network slice identification data to the end station152. The end station152may send the first network slice identification data to the first UE device162. Additionally, or alternatively, the end station152may send the second network slice identification data to the second UE device164.

In some examples, first UE device162may receive the first network slice identification data (e.g., a first S-NSSAI) and second UE device164may receive the second network slice identification data (e.g., a second S-NSSAI). While in possession of the first network slice identification data, first UE device162may be configured to communicate with TSN bridge170via the one or more RAN elements126, the one or more FPEs138, and the one or more core network elements146according to the first network slice163. While in possession of the second network slice identification data, second UE device164may be configured to communicate with TSN bridge170via the one or more RAN elements126, the one or more FPEs138, and the one or more core network elements146according to the second network slice165.

In some examples, service orchestrator110may output, to RAN domain orchestrator124an instruction to configure one or more RAN elements126in order to support the set of network slices. In response to the instruction, the RAN domain orchestrator124is configured to configure the one or more RAN elements126in order to support each network slice of the set of network slices. In some examples, service orchestrator110may output, the core network domain orchestrator144, an instruction to configure one or more core network elements146in order to support the set of network slices. In response to receiving the instruction, the core network domain orchestrator144is configured to configure the one or more core network elements146in order to support each network slice of the set of network slices.

FIG.2is a block diagram illustrating a second example network system200, in accordance with one or more techniques of this disclosure. In the example illustrated inFIG.2, network system200includes CUC202, CNC204, a service orchestrator210including a network slice unit214, a radio access network (RAN) domain222, a transport network domain232, and a core network domain242. The RAN domain222includes a RAN domain orchestrator224and one or more RAN elements226. The transport network domain232includes a transport network domain orchestrator234, an embedded CNC236, and forwarding path element(s)238. Core network domain242includes a core network domain orchestrator244, and one or more core network elements246. A service management and orchestration (SMO) unit250includes service orchestrator210, RAN domain orchestrator224, transport network domain orchestrator234, and core network domain orchestrator244. Network system200includes end station152, end station154, first UE device162, second UE device164, and TSN bridge170.

In some examples, network system200ofFIG.2may be substantially the same as network system100ofFIG.1, except that service orchestrator210ofFIG.2outputs network slice identification data directly to first UE device262and second UE device264, whereas service orchestrator110outputs network slice identification data to first UE device162and second UE device164via CUC102, CNC104, and end station154. For example, service orchestrator210may output first network slice identification data (e.g., a first S-NSSAI) to first UE device262and service orchestrator210may output second network slice identification data (e.g., a second S-NSSAI) to second UE device264. Service orchestrator210may output the first network slice information data directly to first UE device262. In some examples, service orchestrator210may output second network slice information dataset directly to second UE device264. First UE device262includes a slice ID unit267, and second UE device264includes a slice ID unit269.

In some examples, first UE device262may receive the first network slice identification data and second UE device264may receive the second network slice identification data. While in possession of the first network slice identification data, first UE device262may be configured to communicate with TSN bridge270via the one or more RAN elements226, the one or more FPEs238, and the one or more core network elements246according to the first network slice263. While in possession of the second network slice identification data, second UE device264may be configured to communicate with TSN bridge270via the one or more RAN elements226, the one or more FPEs238, and the one or more core network elements246according to the second network slice265.

FIG.3is a block diagram illustrating further details of one example of a computing device300, in accordance with one or more techniques of this disclosure.FIG.3may illustrate a particular example of a server or other computing device300that includes processing circuitry302for executing any one or more of CUC102,202, CNC104,204, and SMO unit150,250, or any other system, application, node software, or module described herein. Other examples of computing device300may be used in other instances. Although shown inFIG.3as a stand-alone computing device300for purposes of example, a computing device may be any component or system that includes one or more processors or other suitable computing environment for executing software instructions and, for example, need not necessarily include one or more elements shown inFIG.3(e.g., communication circuitry306; and in some examples components such as memory308may not be co-located or in the same chassis as other components). As shown in the specific example ofFIG.3, computing device300includes processing circuitry302, one or more input devices304, communication circuitry306, one or more output device(s)312, memory308, and user interface (UI) device(s)310. Computing device300, in one example, further includes one or more applications322and operating system316that are executable by computing device300. Each of components302,304,306,308,310, and312are coupled (physically, communicatively, and/or operatively) for inter-component communications. In some examples, communication channels314may include a system bus, a network connection, an inter-process communication data structure, a message bus, or any other method for communicating data. As one example, components302,304,306,308,310, and312may be coupled by one or more communication channels314.

Processing circuitry302, in one example, are configured to implement functionality and/or process instructions for execution within computing device300. For example, processing circuitry302may be processing circuitry capable of processing instructions stored in memory308. Examples of processing circuitry302may include, any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

Memory308may be configured to store information within computing device300during operation. Memory308, in some examples, is described as a computer-readable storage medium. In some examples, memory308is a temporary memory, meaning that a primary purpose of memory308is not long-term storage. Memory308, in some examples, is described as a volatile memory, meaning that memory308does not maintain stored contents when the computer is turned off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, memory308is used to store program instructions for execution by processing circuitry302. Memory308, in one example, is used by software or applications running on computing device300to temporarily store information during program execution.

Memory308, in some examples, also include one or more computer-readable storage media. Memory308may be configured to store larger amounts of information than volatile memory. Memory308may further be configured for long-term storage of information. In some examples, memory308include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Computing device300, in some examples, also includes communication circuitry306. Computing device300, in one example, utilizes communication circuitry306to communicate with external devices via one or more networks, such as one or more wired/wireless/mobile networks. Communication circuitry306may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. In some examples, computing device300uses communication circuitry306to communicate with an external device.

Computing device300, in one example, also includes one or more user interface devices310. User interface devices310, in some examples, are configured to receive input from a user through tactile, audio, or video feedback. Examples of user interface devices(s)310include a presence-sensitive display, a mouse, a keyboard, a voice responsive system, video camera, microphone, or any other type of device for detecting a command from a user. In some examples, a presence-sensitive display includes a touch-sensitive screen.

One or more output devices312may also be included in computing device300. Output device312, in some examples, is configured to provide output to a user using tactile, audio, or video stimuli. Output device312, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines. Additional examples of output device312include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user.

Computing device300may include operating system316. Operating system316, in some examples, controls the operation of components of computing device300. For example, operating system316, in one example, facilitates the communication of one or more applications322with processing circuitry302, communication circuitry306, memory308, input device304, user interface devices310, and output device312.

Application(s)322may also include program instructions and/or data that are executable by computing device300. Example applications322executable by computing device300may include application and/or other software to implement capabilities described above. For example, applications322can include applications associated with CUC102,202, CNC104,204, and SMO unit150,250.

FIG.4is a block diagram illustrating an example UE device400, in accordance with one or more techniques of this disclosure. Example UE device400shown inFIG.4may be an example of any of UE devices162,164,262,264ofFIGS.1-2. UE device400may include any type of wireless and/or wired client device, and the disclosure is not limited in this respect. For example, UE device400may include a mobile device such as a smart phone, tablet or laptop computer, a personal digital assistant (PDA), a wireless terminal, a smart watch, a smart ring, or any other type of mobile or wearable device. UE device400may also include any type of IoT client device such as a printer, a security sensor or device, an environmental sensor, or any other connected device configured to communicate over one or more wireless and/or wired networks.

UE device400includes a wired interface430, wireless interfaces420A-420C, processing circuitry406, memory412, and a user interface410. The various elements are coupled together via a bus414over which the various elements may exchange data and information. Wired interface430includes a receiver432and a transmitter434. Wired interface430may be used, if desired, to couple UE device400to a network. UE devices are not required to have a wired interface. Some example UE devices may include wireless interfaces without a wired interface. First, second and third wireless interfaces420A,420B, and420C include receivers422A,422B, and422C, respectively, each including a receive antenna via which UE device400may receive wireless signals from wireless communications devices, such as RAN elements126ofFIG.1, RAN elements226ofFIG.2, or other devices configured for wireless communication. First, second, and third wireless interfaces420A,420B, and420C further include transmitters424A,424B, and424C, respectively, each including transmit antennas via which UE device400may transmit wireless signals to wireless communications devices, RAN elements126ofFIG.1, RAN elements226ofFIG.2, other UE devices and/or other devices configured for wireless communication. In some examples, first wireless interface420A may include a Wi-Fi 802.11 interface (e.g., 2.4 GHz and/or 5 GHz) and second wireless interface420B may include a Bluetooth interface and/or a Bluetooth Low Energy interface. Third wireless interface420C may include, for example, a cellular interface through which UE device400may connect to a cellular network.

Processing circuitry406executes software instructions, such as those used to define a software or computer program, stored to a computer-readable storage medium (such as memory412), such as non-transitory computer-readable mediums including a storage device (e.g., a disk drive, or an optical drive) or a memory (such as Flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause the processing circuitry406to perform the techniques described herein.

Memory412includes one or more devices configured to store programming modules and/or data associated with operation of user400. For example, memory412may include a computer-readable storage medium, such as non-transitory computer-readable mediums including a storage device (e.g., a disk drive, or an optical drive) or a memory (such as Flash memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause the processing circuitry406to perform the techniques described herein.

In this example, memory412includes an operating system440, applications442, a communications module444, and configuration settings450. Communications module444includes program code that, when executed by processing circuitry406, enables UE device400to communicate using any of wired interface(s)430, wireless interfaces420A-420B and/or cellular interface450C. Configuration settings450include any device settings for UE device400settings for each of wireless interface(s)420A-420B and/or cellular interface420C.

FIG.5is a flow diagram illustrating an example operation for configuring a set of network slices and outputting network slice identification data, in accordance with one or more techniques of this disclosure. For convenience,FIG.5is described with respect to network system100ofFIG.1and network system200ofFIG.2. However, the techniques ofFIG.5may be performed by different components of network system100ofFIG.1and network system200ofFIG.2or by additional or alternative devices.

Service orchestrator110is configured to receive, from CNC104, TSN configuration data for a TSN flow between two end station devices (502). In some examples, the two end station devices may include end station152and end station154. In some examples, service orchestrator110may configure the TSN flow without information indicating end station152and end station154as end station devices. Service orchestrator110may generate, based on the TSN configuration data, an intent to create a network slice in the mobile network to transport packets for the TSN flow (504). For example, network slice unit114of service orchestrator110may translate the TSN configuration data in order to identify end station152and end station154. In some examples, the intent to create the network slice includes indications of end station152and end station154and one or more instructions for provisioning the network to implement the network slice.

Service orchestrator110may provision the network with the network slice based on the intent, where the network slice is associated with slice identification data (506). In some examples, a radio access network (RAN) orchestrator124is configured to manage one or more RAN elements126, a transport network orchestrator134is configured to manage one or more forwarding path elements (FPEs)138, and a core network orchestrator144is configured to manage one or more core network elements146. In some examples, to provision the network with the network slice based on the intent, the service orchestrator110is configured to leverage the RAN orchestrator124, the transport network orchestrator134, and the core network orchestrator144in order to configure the one or more RAN elements126, the one or more FPEs128, and the one or more core network elements146in order to support the network slice.

Service orchestrator110may output the slice identification data to cause a UE device attached to the mobile network to map packets for the TSN flow, received from one of the two end station devices, to the network slice (508). For example, service orchestrator110may output the slice identification data to first UE device162. In another example, service orchestrator110may output the slice identification data to second UE device164. When in possession of the slice identification data, first UE device162is configured to communicate with TSN bridge170via the network slice. When in possession of the slice identification data, second UE device164is configured to communicate with TSN bridge170via the network slice. A UE device may map a TSN flow to a network slice identified by slice identification data using a ruleset that maps properties of packets for the TSN flow to the slice identification data, which causes the UE to use the identified slice for such packets. When a UE attached to a RAN, the slice identification data for a TSN slice may be included in a list of allowed slices. As described above, another system will inform the UE which slice is to be used for TSN flows.

FIG.6is a flow diagram illustrating a first example operation for sending network slice identification data to a set of UE devices, in accordance with one or more techniques of this disclosure. For convenience,FIG.6is described with respect to network system100ofFIG.1. However, the techniques ofFIG.6may be performed by different components of network system100ofFIG.1or by additional or alternative devices.

CUC102is configured to output, to CNC104, a setup request (602). In some examples, the setup request may represent a frame replication and elimination for reliability (FRER) setup request. In some examples, the setup request may indicate one or more endpoints for requested flows. CNC104may generate a request to create a TSN flow based on the setup request. CNC104may output the request to create the TSN flow to service orchestrator110(604). In some examples, the request to create the TSN flow represents a request to create an ultra-reliable low latency (URLLC) TSN slice between a specified pair of endpoints.

In some examples, service orchestrator110receives the request to create the TSN flow and translates the request. Service orchestrator110may output one or more instructions to configure a network slice based on the intent (606). The network slice may be associated with slice identification data. In some examples, service orchestrator110may output the instructions to RAN domain orchestrator124, transport network domain orchestrator134, core network domain orchestrator144, or any combination thereof. Based on the instructions, orchestrators124,134,144may configure one or more elements in order to support the network slice.

Service orchestrator110is configured to output slice identification data to CNC104(608). In some examples, the slice identification data may include an S-NSSAI. CNC104may forward the slice identification data to CUC102. CUC102may forward the slice identification data to end station152. End station152may forward the slice identification data to a UE device (e.g., first UE device162or second UE device164) (614).

FIG.7is a flow diagram illustrating a second example operation for sending network slice identification data to a set of UE devices, in accordance with one or more techniques of this disclosure. For convenience,FIG.7is described with respect to network system200ofFIG.2. However, the techniques ofFIG.7may be performed by different components of network system200ofFIG.2or by additional or alternative devices.

CUC102is configured to output, to CNC104, a setup request (702). In some examples, the setup request may represent a FRER setup request. In some examples, the setup request may indicate one or more endpoints for requested flows. CNC104may generate a request to create a TSN flow based on the setup request. CNC104may output the request to create the TSN flow to service orchestrator110(704). In some examples, the request to create the TSN flow represents a request to create a URLLC TSN slice between a specified pair of endpoints.

In some examples, service orchestrator110receives the request to create the TSN flow and translates the request. Service orchestrator110may output one or more instructions to configure a network slice based on the intent (706). The network slice may be associated with slice identification data. In some examples, service orchestrator110may output the instructions to RAN domain orchestrator124, transport network domain orchestrator134, core network domain orchestrator144, or any combination thereof. Based on the instructions, orchestrators124,134,144may configure one or more elements in order to support the network slice. Service orchestrator110is configured to output slice identification data directly to a UE device (e.g., first UE device262and/or second UE device264(708).

The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more programmable processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. The term “processor” or “processing circuitry” may generally refer to any of the foregoing logic circuitry, alone or in combination with other logic circuitry, or any other equivalent circuitry. A control unit comprising hardware may also perform one or more of the techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components or integrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. The term “computer-readable storage media” refers to physical storage media, and not signals, carrier waves, or other transient media.