WO2023042044A1 - Signalisation de commande entre des entités de réseau 3gpp et un réseau de transport - Google Patents

Signalisation de commande entre des entités de réseau 3gpp et un réseau de transport Download PDF

Info

Publication number
WO2023042044A1
WO2023042044A1 PCT/IB2022/058477 IB2022058477W WO2023042044A1 WO 2023042044 A1 WO2023042044 A1 WO 2023042044A1 IB 2022058477 W IB2022058477 W IB 2022058477W WO 2023042044 A1 WO2023042044 A1 WO 2023042044A1
Authority
WO
WIPO (PCT)
Prior art keywords
qos flow
network
qos
delay
flow
Prior art date
Application number
PCT/IB2022/058477
Other languages
English (en)
Inventor
György Miklós
Balázs VARGA
János FARKAS
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2023042044A1 publication Critical patent/WO2023042044A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2491—Mapping quality of service [QoS] requirements between different networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0252—Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H04W28/0263—Traffic management, e.g. flow control or congestion control per individual bearer or channel involving mapping traffic to individual bearers or channels, e.g. traffic flow template [TFT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]

Definitions

  • the present disclosure is directed to systems and methods for control signaling between Third Generation Partnership Project (3GPP) network entities and a transport network.
  • 3GPP Third Generation Partnership Project
  • the Fifth Generation (5G) of mobile technology is positioned to provide much wider range of services than the existing Third Generation (3G) I Fourth Generation (4G) technologies. It is expected to enable a fully connected society, in which a rich set of Use Cases-some of them are still not yet conceptualized-will be supported from the Enhanced Mobile Broadband (eMBB) through media distribution, Massive Machine Type of Communication (M-MTC) to the Mission Critical Services (Critical Machine Type of Communication - C-MTC).
  • eMBB Enhanced Mobile Broadband
  • M-MTC Massive Machine Type of Communication
  • C-MTC Mission Critical Services
  • the C-MTC Use Case group covers a large set of applications, but most of them can be characterized by low latency and high reliability.
  • the Time-Sensitive Networking (TSN) Task Group of Institute of Electrical and Electronics Engineers (IEEE) 802.1 provides a standardized solution for satisfying low latency and high reliability requirements in fixed Ethernet networks.
  • the Third Generation Partnership Project (3GPP) has defined an integration mechanism into TSN networks, so that 3GPP networks can also act as virtual bridges (also referred to herein as 5GS bridges), which emulates the operation of a real TSN switch.
  • the TSN network is an example of a delay-sensitive networking system.
  • the 3GPP work focuses on a fully centralized network model scenario where a Centralized Network Controller (CNC) provides the configuration for the TSN bridges.
  • CNC Centralized Network Controller
  • the TSN Application Function AF
  • DS-TT Device Side TSN Translator
  • NW-TT Network Side TSN Translator
  • FIG. 1 reproduces Figure 4.4.8.2-1 in Section 4.4.8.2 of 3GPP Technical Specification (TS) 23.501 V17.1.1.
  • the 5GS bridge provides a delay between its logical ports; this information is provided from the TSN AF to the CNC (section 5.27.5 of 3GPP TS 23.501 V17.1.1).
  • the delay e.g., between the User Equipment (UE) and the User Plane Function (UPF) is configured based on pre-configuration in the TSN AF.
  • the TSN AF also considers the UE-DS-TT residence time within the terminal device that is reported to the TSN AF.
  • UE User Equipment
  • UPF User Plane Function
  • the pre-configuration is based on the network operator's expected maximum delay that may be provided within the TSN system considering the delay in a Radio Access Network (RAN), and in a Centralized Network (CN) including the delay spent within the transport network between RAN and the UPF.
  • RAN Radio Access Network
  • CN Centralized Network
  • the transport network that provides connectivity between the RAN and the CN is considered logically separate from the 3GPP entities, and there is no explicit signaling between the two domains.
  • the transport network can be realized and deployed separately from the 3GPP entities. It is up to the deployment to decide which technology to use in the transport network which can ensure the required delays within the network. For example, it may be possible to apply a TSN network also in the transport domain, or a DetNet network in the transport domain to make sure that the delay targets are met.
  • TSN network also in the transport domain
  • DetNet network in the transport domain to make sure that the delay targets are met.
  • a Third Generation Partnership Project (3GPP) network connected with a Time-Sensitive Networking (TSN) system includes a transport network, a Session Management Function (SMF), and a transport controller performs a method comprising, at the SMF, receiving information about a delay-sensitive stream, configuring filtering rules for tunneling endpoints (i) in a User Plane Function (UPF) and (ii) in a Radio Access Network (RAN) or a User Equipment (UE) that map traffic for the delay-sensitive stream to a Quality-of- Service (QoS) flow, and providing information about the QoS flow to the transport controller.
  • 3GPP Third Generation Partnership Project
  • SMF Session Management Function
  • a transport controller performs a method comprising, at the SMF, receiving information about a delay-sensitive stream, configuring filtering rules for tunneling endpoints (i) in a User Plane Function (UPF) and (ii) in a Radio Access Network (RAN) or a User Equipment (UE) that
  • the information about the QoS flow may comprise one or more delay requirements.
  • the method further comprises, at the transport controller, receiving the information about the QoS flow from the SMF and configuring a user plane of the transport network that connects the UPF and the RAN, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • the TSN or similar functions in the transport network are fully used.
  • the delay guarantees may be met in the domain of the transport network. More traffics with delay guarantees may be supported in the transport network.
  • the 3GPP network's overall delay budget may be reduced.
  • configuring the user plane of the transport network that connects the UPF and the RAN a per QoS flow basis, to meet one or more QoS requirements for the QoS flow comprises configuring the user plane of the transport network such that a particular tunnel to which the QoS flow is mapped meets the one or more QoS requirements for the QoS flow.
  • the particular tunnel is associated to a particular tunneling encapsulation header.
  • the particular tunneling encapsulation header comprises a Virtual Local Area Network (VLAN) tag or Generic Routing Encapsulation (GRE) tunnel identifier that identifies the QoS flow.
  • VLAN Virtual Local Area Network
  • GRE Generic Routing Encapsulation
  • the one or more QoS requirements for the QoS flow comprise delay requirements.
  • the information about the QoS flow further comprises any of an identification of the QoS flow or a Differentiated Services Code Point (DSCP). [0013] In one embodiment, the information about the QoS flow further comprises a QoS flow identifier identifying the QoS flow.
  • DSCP Differentiated Services Code Point
  • the SMF or the transport controller configures a safety delay margin to the QoS flow transmitted or received by the UE before the UE moves from an original location to a target location.
  • a method performed by a SMF comprises receiving information about a delay-sensitive stream, configuring filtering rules for tunneling endpoints (i) in a UPF and (ii) in a RAN or a UE that map traffic for the delay-sensitive stream to a QoS flow, providing information about the QoS flow to the transport controller. The information about the QoS flow comprising one or more delay requirements.
  • the information about the QoS flow further comprises any of an identification of the QoS flow or a DSCP.
  • the information about the QoS flow further comprises a QoS flow identifier identifying the QoS flow.
  • the method further comprises configuring a safety delay margin to the QoS flow transmitted or received by the UE before the UE moves from an original location to a target location.
  • the method further comprises indicating, to the RAN, to eliminate uncertainty in a burst arrival time at an RAN egress point in the uplink.
  • the method further comprises sending a preferred delay requirement in addition to actual delay requirement to the transport controller.
  • the method further comprises sending an alternative delay requirement in addition to actual delay requirement to the transport controller.
  • the method further comprises signaling, to the transport controller, to establish a QoS aware delivery of a packet through a transport network in a downlink direction.
  • the method further comprises requesting, to the transport controller, transport network redundancy for a traffic flow.
  • a SMF is adapted to receive information about a delaysensitive stream, configure filtering rules for tunneling endpoints (i) in a UPF and (ii) in a RAN or a UE that map traffic for the delay-sensitive stream to a QoS flow, and provide information about the QoS flow to the transport controller.
  • the information about the QoS flow comprises one or more delay requirements.
  • a SMF comprises processing circuitry to cause the SMF to receive information about a delay-sensitive stream, configure filtering rules for tunneling endpoints (i) in a UPF and (ii) in a RAN or a UE that map traffic for the delay-sensitive stream to a QoS flow, and provide information about the QoS flow to the transport controller.
  • the information about the QoS flow comprises one or more delay requirements.
  • a method performed by a transport controller of a transport network comprises receiving information about the QoS flow from the SMF.
  • the information comprising one or more delay requirements.
  • the method further comprises configuring a user plane of the transport network that connects the UPF and the RAN, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • the step of configuring the user plane of the transport network that connects the UPF and the RAN, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow comprises configuring the user plane of the transport network such that a particular tunnel to which the QoS flow is mapped meets the one or more QoS requirements for the QoS flow.
  • the particular tunnel is associated to a particular tunneling encapsulation header.
  • the particular tunneling encapsulation header comprises a VLAN tag or GRE tunnel identifier that identifies the QoS flow.
  • the one or more QoS requirements for the QoS flow comprise delay requirements.
  • the method further comprises configuring a safety delay margin to the QoS flow transmitted or received by the UE before the UE moves from an original location to a target location.
  • the method further comprises receiving an indication of burst arrival time, the indication being an interval about expected earliest and latest arrival time of a data burst.
  • the method further comprises configuring a user plane node in a transport network at an ingress point for compensating for uncertainty in a burst arrival time.
  • a transport controller of a transport network is adapted to receive information about the QoS flow from the SMF and to configure a user plane of the transport network that connects the UPF and the RAN, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • the information comprises one or more delay requirements.
  • a transport controller of a transport network comprises processing circuitry to cause the transport controller to receive the information about the QoS flow from the SMF and to configure a user plane of the transport network that connects the UPF and the RAN, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • the information comprises one or more delay requirements.
  • a method performed by a first network node comprises receiving a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow, which is a QoS flow to which a delay-sensitive stream is mapped, and receiving traffic for the particular QoS flow.
  • the method further comprises encapsulating the traffic with the particular tunneling encapsulation header to provided encapsulated traffic, and transmitting the encapsulated traffic to a second network node via a transport network.
  • the particular tunneling encapsulation header comprises a particular VLAN tag or GRE tunnel identifier that identifies the particular QoS flow.
  • the first network node is an RAN
  • the second network node is a UPF
  • the first network node is a UPF
  • the second network node is an RAN.
  • a first network node is adapted to receive a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow, which is a QoS flow to which a delay-sensitive stream is mapped, and receive traffic for the particular QoS flow.
  • the first network node is further adapted to encapsulate the traffic with the particular tunneling encapsulation header to provided encapsulate traffic, and transmit the encapsulated traffic to a second network node via a transport network.
  • a first network node comprises processing circuitry that, in order to provide functionality of the first node, is configured to cause the first network node to receive a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow, which is a QoS flow to which a delay-sensitive stream is mapped, and receive traffic for the particular QoS flow.
  • the processing circuitry is further configured to cause the first network node to encapsulate the traffic with the particular tunneling encapsulation header to provided encapsulate traffic, and transmit the encapsulated traffic to a second network node via a transport network.
  • a first network node comprises receiving encapsulated traffic that is encapsulated with a particular tunneling encapsulation header that is mapped to a particular QoS flow, which is a QoS flow to which a delay-sensitive stream is mapped, and removing the particular tunneling encapsulation header from the encapsulated traffic to provide resulting traffic for the particular QoS flow.
  • the particular tunneling encapsulation header comprises a particular VLAN tag or GRE tunnel identifier that identifies the particular QoS flow.
  • the first network node is a RAN.
  • the first network node is an UPF.
  • a first network node is adapted to receive encapsulated traffic that is encapsulated with a particular tunneling encapsulation header that is mapped to a particular QoS flow, which is a QoS flow to which a delay-sensitive stream is mapped, and remove the particular tunneling encapsulation header from the encapsulated traffic to provide resulting traffic for the particular QoS flow.
  • a first network node comprises processing circuitry that, in order to provide functionality of the first network node, is configured to cause the first network node to receive encapsulated traffic that is encapsulated with a particular tunneling encapsulation header that is mapped to a particular QoS flow, which is a QoS flow to which a delay-sensitive stream is mapped, and remove the particular tunneling encapsulation header from the encapsulated traffic to provide resulting traffic for the particular QoS flow.
  • Figure 2 illustrates one example of a cellular communications system 200 in which embodiments of the present disclosure may be implemented.
  • Figure 3 illustrates a wireless communication system represented as a Fifth Generation (5G) network architecture composed of core Network Functions (NFs).
  • Figure 4 illustrates a 5G network architecture using service-based interfaces between the NFs.
  • 5G Fifth Generation
  • NFs core Network Functions
  • Figure 5 illustrates an example of the overall system and the steps in accordance with embodiments of the present disclosure.
  • Figure 6 illustrates a flow chart of one embodiment of the present disclosure.
  • Figure 7 illustrates delay components in the 3GPP network.
  • Figure 8A illustrates a method of steps performed by an ingress node to the transport network.
  • Figure 8B illustrates a method of steps performed by an egress node to the transport network.
  • Figure 9 is a schematic block diagram of a network node according to some embodiments of the present disclosure.
  • Figure 10 a schematic block diagram that illustrates a virtualized embodiment of the network node according to some embodiments of the present disclosure.
  • Figure 11 is a schematic block diagram of the network node according to some other embodiments of the present disclosure.
  • Radio Node As used herein, a "radio node” is either a radio access node or a wireless communication device.
  • Radio Access Node As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals.
  • RAN Radio Access Network
  • a radio access node examples include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
  • a base station e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B
  • Core Network Node is any type of node in a core network or any node that implements a core network function.
  • Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like.
  • MME Mobility Management Entity
  • P-GW Packet Data Network Gateway
  • SCEF Service Capability Exposure Function
  • HSS Home Subscriber Server
  • a core network node examples include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
  • AMF Access and Mobility Function
  • UPF User Plane Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • PCF Policy Control Function
  • UDM Unified Data Management
  • Communication Device is any type of device that has access to an access network.
  • Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC).
  • the communication device may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
  • Wireless Communication Device One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network).
  • a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device.
  • UE User Equipment
  • MTC Machine Type Communication
  • LoT Internet of Things
  • Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC.
  • the wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.
  • Network Node As used herein, a "network node” is any node that is either part of the RAN or the core network of a cellular communications network/system. [0072] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.
  • the transport network needs to ensure that delay requirements for the end-to-end delay sensitive flows are met without getting explicit information about the flows themselves. Without the explicit information about the flows, the transport network may not provide low delay bounds. Also, it may be possible that the transport network may have to serve less traffic that meets the delay bounds. The transport network may not provide feedback about whether or not a specific flow can be served and what should be the proper delay bound that the transport network can satisfy.
  • the Session Management Function provides signals including the stream's identification, traffic characteristic, and Quality of Service (QoS) requirement (such as delay requirement) to a controller responsible for the transport network domain's configuration (hereinafter "transport controller").
  • QoS Quality of Service
  • transport controller responsible for the transport network domain's configuration
  • the transport controller responds with a message that indicates whether or not it could satisfy the QoS requirements (such as delay guarantee) for the flow.
  • the present disclosure is directed to systems and methods in a 3GPP network function (e.g., the SMF) that receives information about traffic flows (or delay-sensitive streams) requiring QoS guarantees.
  • the network function Based on the information about traffic flows, the network function indicates (a) the stream identification of the traffic flow (also including the General Packet Radio Service Tunneling Protocol (GTP) header information when applicable), (b) the traffic characteristics, and (c) QoS requirements (when applicable) to the transport controller that is responsible for ensuring QoS enabled packet delivery in the transport network.
  • GTP General Packet Radio Service Tunneling Protocol
  • FIG. 2 illustrates one example of a cellular communications system 200 in which embodiments of the present disclosure may be implemented.
  • the cellular communications system 200 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC).
  • the RAN includes base stations 202-1 and 202-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 204-1 and 204-2.
  • the base stations 202-1 and 202-2 are generally referred to herein collectively as base stations 202 and individually as base station 202.
  • the (macro) cells 204-1 and 204-2 are generally referred to herein collectively as (macro) cells 204 and individually as (macro) cell 204.
  • the RAN may also include a number of low power nodes 206-1 through 206-4 controlling corresponding small cells 208-1 through 208-4.
  • the low power nodes 206-1 through 206-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like.
  • RRHs Remote Radio Heads
  • one or more of the small cells 208-1 through 208-4 may alternatively be provided by the base stations 202.
  • the low power nodes 206-1 through 206-4 are generally referred to herein collectively as low power nodes 206 and individually as low power node 206.
  • the small cells 208-1 through 208-4 are generally referred to herein collectively as small cells 208 and individually as small cell 208.
  • the cellular communications system 200 also includes a core network 210, which in the 5GS is referred to as the 5GC.
  • the base stations 202 (and optionally the low power nodes 206) are connected to the core network 210.
  • the base stations 202 and the low power nodes 206 provide service to wireless communication devices 212-1 through 212-5 in the corresponding cells 204 and 208.
  • the wireless communication devices 212-1 through 212-5 are generally referred to herein collectively as wireless communication devices 212 and individually as wireless communication device 212.
  • the wireless communication devices 212 are oftentimes UEs, but the present disclosure is not limited thereto.
  • Figure 3 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface.
  • Figure 3 can be viewed as one particular implementation of the system 200 of Figure 2.
  • the 5G network architecture shown in Figure 3 comprises a plurality of UEs 212 connected to either a RAN 202 or an Access Network (AN) as well as an AMF 300.
  • the RAN 202 comprises base stations, e.g., such as eNBs or gNBs or similar.
  • the 5GC NFs shown in Figure 3 include a NSSF 302, an AUSF 304, a UDM 306, the AMF 300, a SMF 308, a PCF 310, and an Application Function (AF) 312.
  • NSSF 302 Seen from the core network side, the 5GC NFs shown in Figure 3 include a NSSF 302, an AUSF 304, a UDM 306, the AMF 300, a SMF 308, a PCF 310, and an Application Function (AF) 312.
  • AF Application Function
  • the N1 reference point is defined to carry signaling between the UE 212 and AMF 300.
  • the reference points for connecting between the AN 202 and AMF 300 and between the AN 202 and UPF 314 are defined as N2 and N3, respectively.
  • N4 is used by the SMF 308 and UPF 314 so that the UPF 314 can be set using the control signal generated by the SMF 308, and the UPF 314 can report its state to the SMF 308.
  • N9 is the reference point for the connection between different UPFs 314, and N14 is the reference point connecting between different AMFs 300, respectively.
  • N15 and N7 are defined since the PCF 310 applies policy to the AMF 300 and SMF 308, respectively.
  • N12 is required for the AMF 300 to perform authentication of the UE 212.
  • N8 and N10 are defined because the subscription data of the UE 212 is required for the AMF 300 and SMF 308.
  • the 5GC network aims at separating User Plane (UP) and Control Plane (CP).
  • the UP carries user traffic while the CP carries signaling in the network.
  • the UPF 314 is in the UP and all other NFs, i.e., the AMF 300, SMF 308, PCF 310, AF 312, NSSF 302, AUSF 304, and UDM 306, are in the CP.
  • Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.
  • RTT Round Trip Time
  • the core 5G network architecture is composed of modularized functions.
  • the AMF 300 and SMF 308 are independent functions in the CP. Separated AMF 300 and SMF 308 allow independent evolution and scaling.
  • Other CP functions like the PCF 310 and AUSF 304 can be separated as shown in Figure 3.
  • Modularized function design enables the 5GC network to support various services flexibly.
  • Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF.
  • a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity.
  • the UP supports interactions such as forwarding operations between different UPFs.
  • Figure 4 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of Figure 3.
  • the NFs described above with reference to Figure 3 correspond to the NFs shown in Figure 4.
  • the service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface.
  • the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g., Namf for the service based interface of the AMF 300 and Nsmf for the service based interface of the SMF 308, etc.
  • the AMF 300 provides UE-based authentication, authorization, mobility management, etc.
  • a UE 212 even using multiple access technologies is basically connected to a single AMF 300 because the AMF 300 is independent of the access technologies.
  • the SMF 308 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 314 for data transfer. If a UE 212 has multiple sessions, different SMFs 308 may be allocated to each session to manage them individually and possibly provide different functionalities per session.
  • the AF 312 provides information on the packet flow to the PCF 310 responsible for policy control in order to support QoS.
  • the PCF 310 determines policies about mobility and session management to make the AMF 300 and SMF 308 operate properly.
  • the AUSF 304 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 306 stores subscription data of the UE 212.
  • the Data Network (DN) not part of the 5GC network, provides Internet access or operator services and similar.
  • An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.
  • FIG. 5 is an example illustration the overall system and the steps in accordance with embodiments of the present disclosure.
  • a 3GPP network 500 includes a transport network 502, which is located between the RAN 202 and the UPF 314.
  • the 3GPP network 500 is also called as a "5GS bridge” or a "TSN bridge” throughout the present application.
  • a TSN network 504 (a data network) is connected to a Centralized Network Controller (CNC) 506.
  • the TSN network 504 is an example of delay-sensitive networking systems.
  • the TSN network 504 may be replaced with any other delay-sensitive networking systems.
  • the CNC 506 is connected to a TSN Application Function (AF) 508 and provides configurations for the 3GPP network 500.
  • AF TSN Application Function
  • the TSN AF 508 provides the signaling interface between the CNC 506 and the functions of the 3GPP network 500 such as the PCF 310.
  • a Device Side TSN Translator (DS-TT) port 510 corresponds to logical ports of the 3GPP network 500 on the device side
  • a Network Side TSN Translator (NW-TT) port 512 corresponds to logical ports of the 3GPP network 500 on the network side.
  • a transport controller 513 is positioned between the SMF 308 and the transport network 502. The transport controller 513 is responsible for ensuring QoS enabled packet delivery in the transport network.
  • the functions of the 3GPP network 500 are configured to perform the following steps.
  • Figure 5 may illustrate some of the following steps, as described below.
  • Step 1 The SMF 308 receives information about the TSN stream, which is an example of the delay-sensitive stream (hereinafter "TSN stream info").
  • TSN stream info an example of the delay-sensitive stream
  • the CNC 506 provides the TSN stream info that has QoS guarantees (specifically, delay guarantees) to the TSN AF 508, which maps the TSN stream info to 3GPP parameters.
  • the TSN AF 508 forwards the TSN stream info to the PCF 310, which, in turn, forwards the TSN stream info to the SMF 308.
  • the steps 514A, 514B, and 514C correspond to the above-described step 1.
  • the signaling may also involve the Time Sensitive communication Time Synchronization function (TSCTSF) function defined in release 17.
  • TSCTSF Time Sensitive communication Time Synchronization function
  • the TSN stream info may be replaced with non-TSN flows such as DetNet flows, or other traffic flows with delay guarantees.
  • the TSN stream info forwarded to the SMF 308 includes (a) the identification of the traffic flow (which can be in the flow of a set of filters on the packet header), (b) information about the traffic characteristics of the traffic flow (such as periodicity, direction (uplink/downlink), burst arrival time, maximum burst size, or other information), and (c) information about the QoS requirement such as the delay.
  • the QoS requirement can be based on the 5G QoS Identifier (5QI) that is determined by the PCF 310 and can be determined by a pre-configured mapping table that sets, e.g., the maximum delay that must be achieved in the transport network 502. [0093] Step 2.
  • the SMF 308 configures certain filtering rules for the tunneling endpoints in the UPF 314 and in the RAN 202 or in the UE 212. For this, a mapping is established based on the traffic filtering rules to the appropriate QoS flow which is identified by a QoS Flow Identifier (QFI). It is possible that a new QoS flow is established in this step.
  • QFI QoS Flow Identifier
  • the QoS flow may already exist and be extended for the new traffic.
  • GTP tunneling is used between the UPF and the RAN node.
  • the UPF 314 and the RAN 202 provides additional information (e.g., a Differentiated Services Code Point (DSCP) to be used for the traffic flow) to the SMF 318 in this step.
  • the SMF 318 may provide the DSCP value to be used for the traffic flow based on the configuration.
  • the transport network 502 may use additional tunneling encapsulation for the traffic flow, and if so, the UPF 314 or RAN 202 may provide information about the flow identifier used for such tunneling encapsulation (e.g., TSN stream id, or DetNet flow id). Note that such tunneling encapsulation may also be configured and managed by the transport controller 513.
  • Step 3 The SMF 308 provides information about the traffic flow to the transport controller 513 that is responsible for the delay guarantees in the transport network 502. (The transport controller 513 is different from the CNC 506 that is responsible for the TSN network 504 (data network). In Figure 5, the step 516 corresponds to this step.
  • the information about the traffic flow may indicate a new traffic flow, or the modification of an existing traffic flow.
  • the information about the traffic flow may include (i) an identification of the traffic flow, (ii) information about the traffic characteristics, (iii) the QoS requirements of the flow, and (iv) the ingress and egress points.
  • the identification of the traffic flow may include: the destination tunnel endpoint identifier (GTP endpoint IP address and Tunnel Endpoint ID (TEID)); the source tunnel endpoint identifier (GTP endpoint IP address and TEID), even though, in most practical cases, the destination tunnel endpoint is used; the QFI and additional filtering information that the SMF has received to identify the flow.
  • the SMF 308 may also send additional traffic flow information, such as the DSCP may be determined based on a pre-configured mapping table from the 5QI.
  • the information about traffic characteristics may include the flow periodicity, the burst arrival time of the flow, the direction (uplink/downlink) and the maximum burst size, and possibly other parameters as received by the SMF 308.
  • the SMF 308 determines these parameters from the information that it received in step 1.
  • the SMF 308 may perform a mapping on the received values, e.g., as described in section 5.27.2.4 of 3GPP TS 23.501.
  • QoS requirements such as maximum delay, may be (a) based on a priori configuration at the SMF 308 for a specific 5QI, (b) derived from the Ethernet priority, or (c) based on the value that is explicitly provided from the CNC 506 via the TSN AF 508 and the PCF 310.
  • the ingress and the egress points may be identified using the IP address (and, optionally, also the TEID) of the source and destination of the GTP tunnel.
  • the source and destination respectively correspond to the RAN 202 and the UPF 314, depending on the direction of the flow.
  • Step 4 Based on the information about the traffic flow that the transport controller 513 has received from the SMF 308, the transport controller 513 configures the user plane of the transport network 502 so that the QoS requirements are met.
  • the transport network 502 may use TSN, DetNet or other technologies. It may be possible for the transport controller 513 to configure a tunneling encapsulation for the traffic flow in this step.
  • Step 5 The transport controller 513 provides feedback to the SMF 308 on whether or not the configuration of the user plane was successful or not.
  • the SMF 308 may provide feedback to the PCF 310 and further to the TSN AF 508 and the CNC 506 on whether or not the requested QoS could be satisfied, which may also include information specifically about whether the requested QoS could be satisfied in the transport network 502.
  • the GTP tunneling source IP address and port are used as identifiers of the traffic flow.
  • This option requires a new GTP tunnel to be established for each traffic flow and assigns a different port number at the source side. If this is done, then the GTP source port would be sent from the UPF 314 or the RAN 202 to the SMF 308.
  • This option may be used as a vendor specific option. The advantage of this option is that with the source tunnel IP address and port as the identifier, the transport controller 513 can configure the nodes to check for those identifiers.
  • GTP tunnel destination IP address and TEID are used as identifiers of the traffic flow. This option also requires a new GTP tunnel to be established for each traffic flow. This option may be used as a vendor specific option.
  • GTP tunnel destination IP address, TEID, and QFI are used as identifiers of the traffic flow. This is aligned with the current specification, i.e., may use a single GTP tunnel per PDU Session, and based on QFI marking in the GTP header per QoS flow. Note, however, that the TEID and the QFI are encoded into the GTP header, while some transport technologies cannot interpret that header information for flow identification, which could be a disadvantage in some deployments. However, the parsing of the GTP header could be added as a vendor implementation to the user plane nodes if not explicitly supported by the transport technology specification.
  • a payload header within the GTP tunnel (and optionally, the GTP header information which may include destination IP address, TEID and QFI) is used as an identifier of the traffic flow. This is aligned with the current specification. Note that transport technologies may not be able to interpret payload headers within the GTP tunnel. However, the parsing of the payload header could be added as a vendor implementation to the user plane nodes if not explicitly supported by the transport technology specification.
  • tunneling encapsulation is used to identify the traffic flow. This option may be combined with any of the above options.
  • the tunneling encapsulation header is added for the flow at the ingress and removes it at the egress (i.e., at the RAN 202 and the UPF 314, which may serve the ingress and egress roles depending on the flow direction).
  • VLAN Virtual Local Area Network
  • Ethernet Virtual Local Area Network
  • GRE Generic Routing Encapsulation
  • IP Generic Routing Encapsulation
  • This additional tunneling encapsulation may be configured by the transport controller 513 based on the information that it receives from the SMF 308 in the step 4.
  • this tunneling encapsulation may be set up already in the step 2 by the UPF 314 and the RAN 202 themselves, and information about this tunneling encapsulation (i.e., the flow identifier) is conveyed to the transport controller 513 in the steps 2 and 3.
  • the mapping of the traffic stream to the tunneling encapsulation, using filtering criteria, needs to be configured for this option, which can be coordinated by the transport controller 513.
  • Figure 6 illustrates a flow chart of one embodiment implemented by the above-described steps 1-5. That is, the above-described steps 1 to 5 correspond to the following steps 600, 602, 604, 606, 608, respectively.
  • the SMF 308 receives an information about a TSN stream, which is an example of a delay-sensitive stream.
  • the SMF 308 configures filtering rules for tunneling endpoints in the UPF 314 and in the RAN 202 or in the UE 212 that map traffic for the TSN stream to a QoS flow.
  • the SMF 308 provides information about the QoS flow to the transport controller 513.
  • the information about the QoS flow may comprise one or more delay requirements and, optionally, a QoS flow identifier that identifies the QoS flow.
  • the transport controller 513 receives the information about the QoS flow from the SMF 308.
  • the transport controller 513 configures a user plane of the transport network 502 that connects the UPF 314 and the RAN 202, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • FIG. 7 illustrates delay components in the 3GPP network 500. As illustrated, these delay components include the Access Network (AN) Packet Delay Budget (PDB) and the Core Network (CN) PDB. The embodiments implemented by the above steps 1-6 may reduce the delay components, such as the CN PDB shown in Figure 7.
  • AN Access Network
  • PDB Packet Delay Budget
  • CN Core Network
  • FIG. 8A illustrates one embodiment of a method performed by the ingress node to the transport network 502 (e.g., the RAN 202 for UL or the UPF 314 for the DL).
  • the method comprises receiving a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow, which is a QoS flow to which a TSN stream, which is a delay-sensitive stream, is mapped.
  • the method further comprises receiving a traffic for the particular QoS flow.
  • the method further comprises encapsulating the traffic with the particular tunneling encapsulation header to provided encapsulated traffic.
  • the method further comprises transmitting the encapsulated traffic to a second network node via a transport network.
  • Figure 8B illustrates one embodiment of a method performed by the egress node to the transport network 502 (e.g., the UPF 314 for UL or the RAN 202 for the DL).
  • the method performed by the egress node comprises receiving encapsulated traffic that is encapsulated with a particular tunneling encapsulation header that is mapped to a particular QoS flow, which is a QoS flow to which a TSN stream, which is an example of a delay-sensitive stream, is mapped.
  • the method further comprises removing the particular tunneling encapsulation header from the encapsulated traffic to provide resulting traffic for the particular QoS flow.
  • the particular tunneling encapsulation header comprises a particular VLAN tag or GRE tunnel identifier that identifies the particular QoS flow.
  • the first network node is the RAN 202
  • the second network node is the UPF 314 or vice versa.
  • the burst arrival time in the uplink for the transport network ingress may be determined based on the burst arrival time at the UE 212, plus the expected time in the device as reported (the "UE-DS-TT residence time” as shown in Figure 7), and the expected time spent in the RAN 202 (the "AN PDB” as shown in Figure 7), which may be determined based on a configuration of the 3GPP network 500.
  • the actual time spent in the RAN 202 may be variable, which results in uncertainty regarding when the packet arrives to the transport network 502. Due to this uncertainty, there can be several options to consider.
  • the uncertainty may be indicated to the transport controller 513, so that the RAN 202 or the 3GPP network 500 can set the configuration based on the uncertainty in the burst arrival time.
  • the burst arrival time may be indicated as an interval, indicating the expected earliest and latest arrival time of the data burst.
  • the length of the uncertainty may be pre-configured in the SMF 308 on a per 5QI basis, based on which the SMF 308 could signal the length of the uncertainty to the transport controller 513.
  • the transport controller 513 may be pre-configured with the knowledge that the uplink burst arrival time is uncertain. The transport controller 513 may expect that the uplink packet may arrive earlier than the indicated burst arrival time.
  • the transport controller 513 may configure a user plane node in the transport network 502 at the ingress point for compensating for the uncertainty in the burst arrival time. That user plane node would buffer the packet until the time corresponding to the deadline in the burst arrival time. In this way, the uncertainty in the uplink burst arrival time may be compensated and avoided in the subsequent user plane nodes in the transport network 502.
  • the SMF 308 may indicate to the RAN 202 to eliminate the uncertainty at an RAN egress point in the uplink.
  • the SMF 308 may indicate the expected burst arrival time in the uplink into the transport network, which can be determined based on the burst arrival time at the DS-TT, plus the UE-DS-TT residence time, plus the expected residence time in RAN 202 (a pre-configured value corresponding to the given 5QI).
  • This information may be indicated e.g., in the Time-Sensitive Communication Assistance Information (TSCAI) assistance information that is already signaled to the RAN 202 (that currently includes the burst arrival time in the UE for uplink, now the addition would be the expected burst arrival time at the ingress of the transport network, which is the egress of the RAN 202).
  • TSCAI Time-Sensitive Communication Assistance Information
  • the RAN 202 would buffer the uplink packet until the expected burst arrival time to the transport network is reached.
  • the SMF 308 may also send additional information besides the actual delay requirement in the transport network 502. For example, the SMF 308 may send a preferred delay requirement to the transport controller 513, which is a lower value; but the SMF 308 may also send an alternative delay requirement, which is a higher value, in case that the lower, more stringent value cannot be met. In this way, the SMF 308 may minimize the system delay, but the SMF 308 may maintain the delivery of the traffic flow even if the low delay cannot be satisfied. It could also be possible to have more than two delay requirements together with their preference order, and the transport controller 513 attempts to satisfy the lowest possible delay.
  • the SMF 308 may also handle flexible delay requirements even if the transport controller 513 does not explicitly support such a feature.
  • the SMF 308 may try with the lowest delay requirement first to check if that can be satisfied; in case it cannot be satisfied and the transport controller 513 returns an error, the SMF 308 may try with the next, higher delay value.
  • the SMF 308 may be pre-configured with the preferred delay requirement values, where the pre-configuration may be done on a per 5QI basis. Alternatively, the preferred delay requirements (in precedence order) may also be provided explicitly from an application function to the PCF 310 and to the SMF 308.
  • the SMF 308 may also indicate to the transport controller 513 that the delay requirement is not flexible, so that the transport controller 513 should configure the transport network 502 in such a way that the delay should be exactly the same as the delay requirement parameter. That means that the transport controller 513 should configure additional buffering in the transport network 502 in case the packet would arrive earlier than the delay requirement.
  • This may be useful, e.g., in the downlink, where the exact delay through the transport network 502 ensures that the packet arrives at the RAN 202 as indicated to the RAN 202 by the SMF 308 in the TSCAI container Burst Arrival Time (BAT) value.
  • BAT Burst Arrival Time
  • the TSCAI container includes the BAT also in the downlink direction for the RAN 202, indicating the time when the packet arrives at the RAN 202 at the latest. In the downlink direction, this is currently calculated based on the BAT at the UPF 314, plus the CN PDB, where the CN PDB is a pre-configured maximum time while the packet reaches the RAN 202 from the UPF 314 (the pre-configuration can be on a per priority or per 5QI basis). Since the CN PDB is a pre-configured value, it may be an upper bound meaning that the downlink packet may arrive to the RAN 202 earlier than the BAT indicates.
  • a flag e.g., called "exact BAT value
  • the transport controller 513 may also provide feedback about the expected delay that the transport network 513 could provide for future traffic flows between a UPF endpoint and a RAN endpoint. Such an expected value could be calculated based on the knowledge of the transport network resource situation that the transport controller is aware of.
  • the SMF 308 may also perform a calculation on its own. Based on the history of the delay guarantees that could be provided between a UPF endpoint and a RAN endpoint, the SMF 308 could calculate an upper bound, possibly adding a safety margin as well, so that this delay can be expected to be provided for future flows.
  • the SMF may indicate the possible expected delay to the PCF 310 and the TSN AF 508.
  • the total delay bound in the 3GPP network 500 could be calculated between the concerned DS-TT port 510 and NW-TT port 512 (also considering the device residence time UE-DS-TT, as reported to the TSN AF 508).
  • the TSN AF 508 may report the updated value of the 5GS bridge delay to the CNC 506. The updated value of the 5GS bridge delay can help the CNC 506 to better schedule the flows and the flows can achieve a lower delay considering the actual transport network delay performance.
  • Mobility handling When the UE 212 moves from one RAN 202 to another (handover), the corresponding deterministic flows require a new reservation for deterministic service over the new GTP tunnel at the target RAN.
  • the SMF 308 requests the new reservations when the handover takes place, and when the handover is successfully completed, the SMF 308 initiates the release of the reservations at the old location.
  • the SMF 308 or the RAN 202 may also request reservations for the forwarding tunnel from the source to the target RAN nodes when such forwarding is applied.
  • the transport controller 513 cannot ensure the same delay requirement at the target location as what was possible at the source location, resulting in the increase of the delay through the 3GPP network 500.
  • the increase of the delay may be reported to the CNC 506, which may decide whether to keep the flow with the increased delay or not. Such a reporting is possible by reporting a change in the delay attributed; in the future it can be possible add explicit support for such reporting to the CNC 506.
  • the SMF 308 may have additional parameters to control the system behavior during mobility.
  • a maximal delay may be set for the transport network delay at the target location. This may be pre-configured in the 3GPP network 500 (in the SMF 308 or the PCF 310 or the TSN AF 508, and be provided to the SMF 308), or the maximal delay may be explicitly indicated by the CNC 506, which is further indicated to the 3GPP network 500 (i.e., the TSN AF 508 may indicate the maximal delay during mobility), which is communicated to the SMF 308 or the transport controller 513. Based on such a maximal delay parameter, the SMF 308 or the transport controller 513 may terminate the reservation and/or release the traffic flow when the maximal delay is exceeded during mobility.
  • the transport controller may include additional buffering to compensate for the lower delay, and the delay within the 3GPP network 500 does not change. It may be indicated to the SMF 308 and to the transport controller using a flag whether to insert additional delay to keep the delay unchanged during mobility. This indication may be based on a similar indication that originates from the CNC 506 or the TSN AF 508 or the PCF 310.
  • the TSN system 504 may also be prepared for the mobility by adding a safety delay margin at the original location, even before mobility takes place.
  • the safety delay margin (that applies to traffic flows of UEs located at the original location) is configured in the SMF 308 or in the transport controller 513.
  • the safety delay margin may be varied based on a particular criterion, such as the user's subscription, i.e., done only for the users where mobility is expected, and the value of the safety margin may also be different depending on the user.
  • the TSN system 504 may make sure that the transport network delay does not change even during subsequent mobility events (up to a limit). This may be useful in case that the delay in the transport network 502 is higher at the target location, or when the traffic forwarding from the source to the target RAN requires extra delay.
  • the TSN system 504 may indicate, to the SMF 308 or to the transport controller 513:
  • the SMF 308 may report (possibly via intermediate entities) to the UE 212 or to the application server when the delay guarantee cannot be met due to mobility; it is also possible for the SMF 308 to report in advance the value of the safety margin and/or the area where mobility is expected to be supported.
  • the transport network 502. may signal to the SMF 308, which in turn can signal to the transport controller 513 to reserve the requested resources.
  • Delay requirements in case of redundant GTP tunnels in the transport network [0137] As specified in Section 5.33.2.2 of 3GPP TS 23.501, there may be multiple GTP tunnels between the RAN 202 and the UPF 314 for redundancy. In that case, the delay requirements must be ensured for both of GTP tunnels. In such a scenario, the SMF 308 requests reservations for both of GTP tunnels when signaling to the transport controller 513.
  • transport network redundancy for the traffic flows when the SMF 308 signals to the transport controller 513.
  • the request for transport network redundancy may be done explicitly, or alternatively implicitly by indicating the requested parameters, such as maximum packet loss or network node/link availability, and the transport controller 513 may determine whether or not redundancy mechanisms are needed to satisfy the requested characteristics.
  • the use of transport network redundancy mechanism is described in Section 5.33.2.3 of 3GPP TS 23.501.
  • FRER Frame Replication and Elimination for Reliability
  • Transport network redundancy may be used in addition to the delay requirements, or redundancy may be used without delay requirements in the transport network.
  • the SMF 308 has knowledge about whether or not redundancy should be required for a given traffic flow, and if redundancy mechanism is required in the transport network, it indicates this to the transport controller 513 which is responsible for configuring the redundant traffic flows in the transport network 502.
  • FIG. 9 is a schematic block diagram of a network node 900 according to some embodiments of the present disclosure.
  • the network node 900 may be, for example, a network node that implements all or part of the functionality of the TSN AF 508, or other network node that enables the aforementioned functionality with respect to obtain per TSN stream information from the CNC 506, as described herein.
  • the network node 900 may be, for example, a network node that implements all or part of the functionality of the CNC 506 that enables the aforementioned functionality with respect to send per TSN stream information from to the TSN AF 508 of the 5GS bridge 500, as described herein.
  • the network node 900 includes one or more processors 904 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 906, and a network interface 908.
  • the one or more processors 904 are also referred to herein as processing circuitry.
  • the one or more processors 904 operate to provide one or more functions of the network node 900 as described herein (e.g., one or more functions of the TSN AF 508 (or other NF) in the 5GS bridge 500 as described herein, or one or more functions of the CNC 506 as described herein, e.g., with respect to Figure 5).
  • the function(s) is implemented in software that is stored, e.g., in the memory 906 and executed by the one or more processors 904.
  • FIG 10 is a schematic block diagram that illustrates a virtualized embodiment of the network node 900 according to some embodiments of the present disclosure.
  • a "virtualized" network node is an implementation of the network node 900 in which at least a portion of the functionality of the network node 900 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).
  • the network node 900 includes one or more processing nodes 1000 coupled to or included as part of a networks) 1002.
  • Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908.
  • functions 1010 of the network node 900 described herein are implemented at the one or more processing nodes 1000 or distributed across the one or more processing nodes 1000 in any desired manner.
  • some, or all of the functions 1010 of the network node 900 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1000.
  • a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of network node 900 or a node (e.g., a processing node 1000) implementing one or more of the functions 1010 of the network node 900 in a virtual environment according to any of the embodiments described herein (e.g., one or more functions of the TSN AF 508 (or other NF) in the 5GS bridge 500 as described herein, or one or more functions of the CNC 506 as described herein, e.g., with respect to Figure 5) is provided.
  • a carrier comprising the aforementioned computer program product is provided.
  • the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non- transitory computer readable medium such as memory).
  • FIG 11 is a schematic block diagram of the network node 900 according to some other embodiments of the present disclosure.
  • the network node 900 includes one or more modules 1100, each of which is implemented in software.
  • the module(s) 1000 provide the functionality of the network node 900 described herein (e.g., one or more functions of the TSN AF 508 (or other NF) in the 5GS bridge 500 as described herein, or one or more functions of the CNC 506 as described herein, e.g., with respect to Figure 5).
  • This discussion is equally applicable to the processing node 900 of Figure 9 where the modules 1100 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900.
  • any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
  • Each virtual apparatus may comprise a number of these functional units.
  • These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like.
  • the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
  • Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.
  • the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
  • a method performed by a Third Generation Partnership Project (3GPP) network 500 connected with a Time-Sensitive Networking (TSN) system 504 is proposed.
  • the 3GPP network 500 includes a transport network 502, a Session Management Function (SMF) 308, and a transport controller 513.
  • the method comprises one or more of the following.
  • the method comprises receiving information about a delay-sensitive stream; configuring filtering rules for tunneling endpoints (i) in a UPF 314 and (ii) in a RAN 202 or a UE 212 that map traffic for the delay-sensitive stream to a Qua I ity-of- Service, QoS, flow; and providing information about the QoS flow to the transport controller 513.
  • the information about the QoS flow comprises one or more delay requirements and, optionally, a QoS flow identifier identifying the QoS flow.
  • the method comprises receiving the information about the QoS flow from the SMF 308; and configuring a user plane of the transport network 502 that connects the UPF 314 and the RAN 202, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • the step of configuring the user plane of the transport network 502 that connects the UPF 314 and the RAN 202, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow comprises configuring the user plane of the transport network 502 such that a particular tunnel to which the QoS flow is mapped meets the one or more QoS requirements for the QoS flow.
  • the one or more QoS requirements for the QoS flow comprise delay requirements.
  • the information about the QoS flow further comprises any of an identification of the QoS flow or a Differentiated Services Code Point (DSCP).
  • DSCP Differentiated Services Code Point
  • the particular tunnel is associated to a particular tunneling encapsulation header.
  • the particular tunneling encapsulation header comprises a VLAN tag or GRE tunnel identifier that identifies the QoS flow.
  • the SMF 308 or the transport controller 513 configures a safety delay margin to the QoS flow transmitted or received by the UE 212 before the UE 212 moves from an original location to a target location.
  • a 3GPP network 500 is connected with a TSN system 504.
  • the 3GPP network 500 includes a transport network 502, a SMF 308, and a transport controller 513.
  • the 3GPP network 500 is adapted to (a) receive, at the SMF 308, information about a delay-sensitive stream, (b) configure, at the SMF 308, filtering rules for tunneling endpoints (i) in a UPF 314 and (ii) in a RAN 202 or a UE 212 that map traffic for the delay-sensitive stream to a Quality-of-Service, QoS, flow; (c) provide, at the SMF 308, information about the QoS flow to the transport controller 513.
  • the information about the QoS flow comprises one or more delay requirements and, optionally, a QoS flow identifier identifying the QoS flow; (d) receive, at the transport controller 513, the information about the QoS flow from the SMF 308; and (e) configure, at the transport controller 513, a user plane of the transport network 502 that connects the UPF 314 and the RAN 202, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • a 3GPP network 500 is connected with a TSN system 504.
  • the 3GPP network 500 includes a transport network 502, a SMF 308, a transport controller 513, and processing circuitry 2304.
  • the processing circuitry 2304 in order to provide functionality of the 3GPP network 500, is configured to cause the 3GPP network 500 to (a) receive, at the SMF 308, information about a delay-sensitive stream, (b) configure, at the SMF 308, filtering rules for tunneling endpoints (i) in a UPF 314 and (ii) in a RAN 202 or a UE 212 that map traffic for the delay-sensitive stream to a Quality-of- Service, QoS, flow; (c) provide, at the SMF 308, information about the QoS flow to the transport controller 513.
  • the information about the QoS flow comprises one or more delay requirements and, optionally, a QoS flow identifier identifying the QoS flow; (d) receive, at the transport controller 513, the information about the QoS flow from the SMF 308; and (e) configure, at the transport controller 513, a user plane of the transport network 502 that connects the UPF 314 and the RAN 202, on a per QoS flow basis, to meet one or more QoS requirements for the QoS flow.
  • a method performed by a first network node 900 comprises (a) receiving a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow that is a QoS flow to which a delay-sensitive stream is mapped; (b) receiving traffic for the particular QoS flow; (c) encapsulating the traffic with the particular tunneling encapsulation header to provided encapsulated traffic; and (d) transmitting the encapsulated traffic to a second network node 900 via a transport network.
  • the particular tunneling encapsulation header comprises a particular VLAN tag or GRE tunnel identifier that identifies the particular QoS flow.
  • the first network node 900 is a RAN 202 and the second network node 900 is a UPF 314.
  • the first network node 900 is a UPF 314 and the second network node 900 is a RAN 202.
  • a first network node 900 is adapted to (a) receive a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow that is a QoS flow to which a delay-sensitive stream is mapped; (b) receive traffic for the particular QoS flow; (c) encapsulate the traffic with the particular tunneling encapsulation header to provided encapsulated traffic; and (d) transmit the encapsulated traffic to a second network node 900 via a transport network.
  • a first network node 900 comprises processing circuitry 2304 that, in order to provide functionality of the first node, is configured to cause the first network node 900 to (a) receive a configuration that indicates information for a particular tunneling encapsulation header to be used for a particular QoS flow that is a QoS flow to which a delay-sensitive stream is mapped; (b) receive traffic for the particular QoS flow; (c) encapsulate the traffic with the particular tunneling encapsulation header to provided encapsulated traffic; and (d) transmit the encapsulated traffic to a second network node 900 via a transport network.
  • a method performed by a first network node 900 comprises receiving encapsulated traffic that is encapsulated with a particular tunneling encapsulation header that is mapped to a particular QoS flow that is a QoS flow to which a delay-sensitive stream is mapped; and removing the particular tunneling encapsulation header from the encapsulated traffic to provide resulting traffic for the particular QoS flow.
  • the particular tunneling encapsulation header comprises a particular VLAN tag or GRE tunnel identifier that identifies the particular QoS flow.
  • the first network node 900 is a RAN 202 and the second network node 900 is a UPF 314.
  • the first network node 900 is a UPF 314 and the second network node 900 is a RAN 202.

Abstract

Sont divulgués dans la présente invention des systèmes et des procédés de signalisation de commande entre des entités de réseau de projet de partenariat de troisième génération (3GPP) et un réseau de transport. Dans certains modes de réalisation, un procédé mis en œuvre par un premier nœud de réseau consiste à recevoir une configuration qui indique des informations pour un en-tête d'encapsulation de tunnellisation particulier à utiliser pour un flux de qualité de service particulier (QoS). Le flux QoS particulier est un flux QoS avec lequel un flux sensible au retard est mis en correspondance. Le procédé consiste en outre à recevoir un trafic correspondant au flux QoS particulier, à encapsuler le trafic avec l'en-tête d'encapsulation de tunnellisation particulier pour fournir un trafic encapsulé, et à transmettre le trafic encapsulé à un second nœud de réseau par l'intermédiaire d'un réseau de transport.
PCT/IB2022/058477 2021-09-14 2022-09-08 Signalisation de commande entre des entités de réseau 3gpp et un réseau de transport WO2023042044A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163243936P 2021-09-14 2021-09-14
US63/243,936 2021-09-14

Publications (1)

Publication Number Publication Date
WO2023042044A1 true WO2023042044A1 (fr) 2023-03-23

Family

ID=83689418

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2022/058477 WO2023042044A1 (fr) 2021-09-14 2022-09-08 Signalisation de commande entre des entités de réseau 3gpp et un réseau de transport

Country Status (1)

Country Link
WO (1) WO2023042044A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020148616A1 (fr) * 2019-01-15 2020-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Mappage qos de système de communication tsn-cellulaire et optimisation ran sur la base d'informations relatives à un motif de trafic tsn
US20210160768A1 (en) * 2019-11-26 2021-05-27 Netsia, Inc. APPARATUS AND METHOD FOR QoS AWARE GTP-U TRANSPORT IN MOBILE NETWORKS

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020148616A1 (fr) * 2019-01-15 2020-07-23 Telefonaktiebolaget Lm Ericsson (Publ) Mappage qos de système de communication tsn-cellulaire et optimisation ran sur la base d'informations relatives à un motif de trafic tsn
US20210160768A1 (en) * 2019-11-26 2021-05-27 Netsia, Inc. APPARATUS AND METHOD FOR QoS AWARE GTP-U TRANSPORT IN MOBILE NETWORKS

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System Architecture for the 5G System; Stage 2 (Release 16)", 23 September 2019 (2019-09-23), XP051839499, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_sa/WG2_Arch/Latest_SA2_Specs/DRAFT_INTERIM/Archive/23501-g20_Postponed_23.501%20CR1592_NOT_23501_CR1345r2_CRs_Implemented.zip 23501-g20_Postponed_23.501 CR1592_NOT_23501_CR1345r2_CRs_Implemented.doc> *
3GPP TECHNICAL SPECIFICATION (TS) 23.501
3GPP TS 23.501
ERICSSON: "RAN enhancements based on new QoS related parameters", vol. RAN WG2, no. Electronic meeting;, 1 April 2021 (2021-04-01), XP051992072, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_113bis-e/Docs/R2-2103429.zip> *

Similar Documents

Publication Publication Date Title
KR102523413B1 (ko) 시간 민감성 네트워킹을 위한 제어 평면 기반 구성
US11825337B2 (en) 5G system support for virtual TSN bridge management, QoS mapping and TSN Qbv scheduling
US20220046513A1 (en) Device Configuration for Time Sensitive Network Bridge
US20220182896A1 (en) Identification of Time Sensitive Network Bridge
CN112514422A (zh) 支持组通信的系统与方法
US20220256393A1 (en) TSN AND 5GS QoS MAPPING - A USER PLANE BASED METHOD
EP3782401B1 (fr) Dispositif client, noeud de commande de reseau et upf pour la transmission et la reception de flux de paquets de donnees en multiconnectivite
US20240098572A1 (en) Systems and methods for user plane handling
WO2020148616A1 (fr) Mappage qos de système de communication tsn-cellulaire et optimisation ran sur la base d&#39;informations relatives à un motif de trafic tsn
CN115316039A (zh) 用于边缘计算的会话管理
US20230019215A1 (en) TSC-5G QoS MAPPING WITH CONSIDERATION OF ASSISTANCE TRAFFIC INFORMATION AND PCC RULES FOR TSC TRAFFIC MAPPING AND 5G QoS FLOWS BINDING
KR20210024160A (ko) 통신 방법 및 장치
CN115426677A (zh) 一种用户面信息上报方法及装置
US9271255B1 (en) Providing wireless network communication among a plurality of wireless devices
JP7192896B2 (ja) 通信システム
CN115462174A (zh) 用于处理卸载的会话管理
CN110138685B (zh) 一种通信方法及装置
US11265838B2 (en) User equipment, control device, and communication control method
WO2023212175A2 (fr) Réseaux déterministes
WO2023042044A1 (fr) Signalisation de commande entre des entités de réseau 3gpp et un réseau de transport
CN116097751A (zh) 利用smf重新选择来重新锚定
EP4342152A1 (fr) Transmission d&#39;un message de réponse pour une communication sensible au temps
US20230239174A1 (en) Packet detection rules derived from ethernet forwarding information
CN117528561A (zh) 通信方法及装置
CN115842578A (zh) 一种通信方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22786836

Country of ref document: EP

Kind code of ref document: A1