TSN and 5GS QoS Mapping - User Plane-Based Approach

Abstract

Disclosed herein are systems and methods for quality of service (QoS) mapping in a cellular communication system operating as a time-sensitive networking (TSN) bridge. In one embodiment, a method of operating a session management function (SMF) in a cellular communication system operating as a bridge for a TSN system includes: obtaining a QoS mapping table that maps TSN service classes to QoS flows within the cellular communication system; and distributing at least a portion of the QoS mapping table to a user plane function (UPF) or a TSN translator (TT) on the UPF side. In this manner, QoS mapping is provided. Also disclosed are corresponding embodiments of the SMF and a network node implementing the SMF. Also disclosed are embodiments of a method of operating an application function (AF), and corresponding embodiments of the AF and a network node implementing the AF.

Description

[0001] Related applications

[0002] This application claims the benefit of PCT patent application serial number PCT / CN2019 / 089766, filed on June 3, 2019, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates to a cellular communication system, and in particular, to a cellular communication system operating as a bridge in a Time Sensitive Network (TSN). Background Art

[0004] The manufacturing industry is undergoing a digital transformation towards the "Fourth Industrial Revolution" (Industry 4.0) towards smart manufacturing. Flexible connectivity infrastructure is a key enabler for manufacturing to interconnect machines, products, and all kinds of other devices in a flexible, secure, and consistent manner.

[0005] As an alternative or supplement to wired connection solutions, the 3rd Generation Partnership Project (3GPP) fifth generation (5G) system should support the new requirements and challenges from these vertical fields. 3GPP has a study on automation communication in vertical fields (Technical Report (TR) 22.804), in which many use cases from vertical fields are analyzed. Industrial automation applications (e.g., motion control) have extremely stringent service requirements in terms of high availability, ultra-reliability, low latency, low jitter, and determinism, such as end-to-end latency of 1-10 milliseconds (ms) and packet delay variation of 1-100 microseconds (μs). Summary of the Invention

[0006] Disclosed herein are systems and methods for quality of service (QoS) mapping in a cellular communication system operating as a bridge for a time-sensitive networking (TSN) system. In one embodiment, a method of operating a session management function (SMF) in a cellular communication system operating as a bridge for a TSN system includes: obtaining a QoS mapping table that maps TSN service classes to QoS flows within the cellular communication system; and distributing at least a portion of the QoS mapping table to a user plane function (UPF) or a TSN translator (TT) on the UPF side. In this manner, QoS mapping between TSN service classes of the TSN system and QoS flows of the cellular communication system is provided.

[0007] In one embodiment, at least a portion of the QoS mapping table includes available TSN traffic classes associated with a bridge identifier (ID) and a port ID.

[0008] In one embodiment, different QoS mapping tables are used for different UPFs.

[0009] In one embodiment, the QoS mapping table is pre-configured. In one embodiment, the QoS mapping table is pre-configured during a capability reporting phase in which the cellular communication system reports its capabilities related to operating as a bridge for a TSN system.

[0010] In one embodiment, the QoS flows include one or more pre-established QoS flows. In one embodiment, the QoS flows include one or more QoS flows pre-established during a capability reporting phase in which the cellular communication system reports its capabilities related to operating as a bridge for the TSN system. In one embodiment, the QoS flows include one or more QoS flows pre-established based on one or more pre-configured QoS profiles when establishing one or more protocol data unit (PDU) sessions to the TSN system.

[0011] Also disclosed are embodiments of corresponding SMFs. In one embodiment, an SMF of a cellular communication system operating as a bridge for a TSN system is adapted to: obtain a QoS mapping table that maps TSN service classes to QoS flows within the cellular communication system; and distribute at least a portion of the QoS mapping table to a UPF or a TT on the UPF side.

[0012] Also disclosed are corresponding embodiments of a network node implementing an SMF. In one embodiment, a network node implementing an SMF for a cellular communication system operating as a bridge for a TSN system includes a network interface and processing circuitry associated with the network interface, wherein the processing circuitry is configured to cause the network node to: obtain a QoS mapping table that maps TSN service classes to QoS flows within the cellular communication system; and distribute at least a portion of the QoS mapping table to a UPF or a TT on the UPF side.

[0013] Also disclosed are embodiments of methods of operating an application function (AF). In one embodiment, a method of operating an AF in a cellular communication system operating as a bridge for a TSN system includes: receiving one or more TSN QoS requirements and one or more TSN scheduling parameters from a controller associated with the TSN system during a configuration phase of the bridge; and notifying one or more network nodes in the cellular communication system of which QoS flows among a plurality of pre-configured QoS flows are being used by the TSN system.

[0014] In one embodiment, the method further comprises: distributing one or more TSN parameters to relevant network nodes in the cellular communication system during a configuration phase of the network bridge. In one embodiment, the one or more TSN parameters include Qbv scheduling and time-sensitive communication assistance information.

[0015] In one embodiment, the method further includes providing the response to a controller associated with the TSN system.

[0016] Embodiments of corresponding AFs are also disclosed. In one embodiment, an AF of a cellular communication system operating as a bridge for a TSN system is adapted to: receive one or more TSN QoS requirements and one or more TSN scheduling parameters from a controller associated with the TSN system during a configuration phase of the bridge; and notify one or more network nodes in the cellular communication system of which QoS flows among a plurality of pre-configured QoS flows are being used by the TSN system.

[0017] Also disclosed are corresponding embodiments of network nodes implementing AF. In one embodiment, a network node implementing AF for a cellular communication system operating as a bridge for a TSN system includes a network interface and processing circuitry associated with the network interface, wherein the processing circuitry is configured to cause the network node to: receive one or more TSN QoS requirements and one or more TSN scheduling parameters from a controller associated with the TSN system during a configuration phase of the bridge; and notify one or more network nodes in the cellular communication system of which QoS flows among a plurality of pre-configured QoS flows are being used by the TSN system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings incorporated in and forming a part of this specification illustrate several aspects of the disclosure and together with the description serve to explain the principles of the disclosure.

[0019] Figure 1 An example of a cellular communication system according to some embodiments of the present disclosure is shown;

[0020] Figure 2 and Figure 3 An example fifth generation (5G) system (5GS) architecture is shown;

[0021] Figure 4 An example of a system in which a 5GS operates as a bridge in a time-sensitive network (TSN) and in which embodiments of the present disclosure may be implemented is shown;

[0022] Figure 5 The present invention illustrates the process of user equipment (UE) onboarding and reporting virtual bridge capabilities to a centralized network configuration (CNC) according to some embodiments of the present disclosure.

[0023] Figure 6 The process of configuring a virtual network bridge and transmitting services using a CNC according to some embodiments of the present disclosure is shown;

[0024] Figure 7 is a schematic block diagram of a network node according to some embodiments of the present disclosure;

[0025] Figure 8 is a diagram showing some embodiments of the present disclosure Figure 7 A schematic block diagram of an embodiment of a virtualization of a network node;

[0026] Figure 9 According to some other embodiments of the present disclosure Figure 7 A schematic block diagram of a network node;

[0027] Figure 10 is a schematic block diagram of a UE according to some embodiments of the present disclosure;

[0028] Figure 11 According to some other embodiments of the present disclosure Figure 10 A schematic block diagram of a UE; and

[0029] Figure 12 A process of distributing a portion of a table from a session management function (SMF) to a user plane function (UPF) or a TSN translator (TT) on the UPF side according to some embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0030] The embodiments set forth below represent information that enables those skilled in the art to practice these embodiments and illustrates the best mode for practicing these embodiments. When reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure and will recognize the applications of these concepts that are not specifically set forth herein. It should be understood that these concepts and applications fall within the scope of the present disclosure.

[0031] Radio node: As used herein, a "radio node" is a radio access node or a wireless device.

[0032] Radio access node: As used herein, a "radio access node" or "radio network node" is any node in a radio access network (RAN) of a cellular communication network that operates to transmit and / or receive signals wirelessly. Some examples of radio access nodes include, but are not limited to, base stations (e.g., a 3rd Generation Partnership Project (3GPP) fifth generation (5G) New Radio (NR) base station (gNB) in a 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, etc.), and relay nodes.

[0033] Core network node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of core network nodes include, for example, a mobility management entity (MME), a packet data network gateway (P-GW), a service capability exposure function (SCEF), a home subscriber server (HSS), etc. Some other examples of core network nodes include nodes that implement an access and mobility management 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), etc.

[0034] Wireless Device: As used herein, a "wireless device" is any type of device that accesses a cellular communication network (i.e., is served by a cellular communication network) by wirelessly sending and / or receiving signals to a radio access node. Some examples of wireless devices include, but are not limited to, user equipment (UE) and machine type communication (MTC) devices in 3GPP networks.

[0035] Network node: As used herein, a "network node" is any node that is part of the RAN or core network of a cellular communication network / system.

[0036] Note that the description given herein focuses on 3GPP cellular communication systems and therefore 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems.

[0037] Note that in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beam may be used instead of cell, and therefore, it is important to note that the concepts described herein apply equally to cells and beams.

[0038] For Time Sensitive Networking (TSN)-5G integration, 3GPP Technical Report (TR) 23.734 reached a model in which the 5G system is modeled as a virtual bridge (or several bridges). 3GPP TR 23.734 Solution #18 describes the Quality of Service (QoS) negotiation between 3GPP and TSN networks. The control plane-based QoS negotiation consists of two phases:

[0039] 1. Phase 1: Bridge Capability Reporting Phase. TSN capability reporting of 5G System (5GS) TSN bridges (also known as the bridge loading phase) (Section 6.18.1.2.1 of [1]).

[0040] 2. Phase 2: Bridge configuration phase. Solution #30 [1] proposes a process for “TSN-related QoS configuration of 5G virtual bridges”, which can be an alternative to Solution #18 “TSN-aware QoS profile generation” (Section 6.18.1.2.2 of [1]).

[0041] U.S. Provisional Patent Application Serial No. 62 / 805,727, entitled “5G System Support for Virtual TSN Bridge Management, QoS Mapping and TSN Qbv Scheduling” (herein referred to as the “’727 Application”), describes several options for addressing the two phases of control-plane-based QoS negotiation. Specifically, the ’727 Application describes:

[0042] In one option, the QoS flow is pre-configured during the 5G bridge capability reporting phase. In this case, a QoS flow with a specific 5G QoS indicator (5QI) is established even if no TSN traffic passes through the QoS flow.

[0043] In another option, QoS flows are not pre-configured during the 5G Bridge Capability Reporting phase. Instead, only the visibility of the QoS flows is reported. QoS flow establishment is then completed during the Phase 2 Bridge Configuration phase.

[0044] The '727 application introduces three options for mapping TSN QoS parameters to 5G QoS profiles. These options are based on the "control plane-based QoS negotiation" approach. The proposed solution of the '727 application has some problems. Specifically, these problems are:

[0045] 1. The control plane-based QoS mapping method relies on the IEEE 802.1Qcc centralized model, such as Centralized Network Configuration (CNC) and / or Centralized User Configuration (CUC). Therefore, it cannot be applied to TSN networks without CNC / CUC.

[0046] 2. The '727 application proposes several methods for mapping TSN QoS parameters to 5G QoS profiles during the bridge configuration phase. The QoS mapping methods assume that no QoS flows with corresponding QoS profiles for TSN services are pre-established during the bridge capability reporting phase. That is, the 5GS only reports the available QoS profiles to the TSN network during the bridge capability reporting phase.

[0047] a. The delay caused by the signaling process of QoS flow establishment during the bridge configuration phase can be a problem. In 5GS, the signaling process of establishing a new QoS flow for a specific TSN service class is complex and may include paging, service request, policy control, protocol data unit (PDU) session modification, etc.

[0048] The delay caused by the signaling process may exceed the performance requirements of TSN applications.

[0049] b. Communication service availability is considered a critical service performance requirement for applications with deterministic traffic. For TSN applications, latency, lifetime, and system reliability are also key factors in availability. When message transmission time exceeds the maximum transmission delay, the system is considered unavailable for TSN applications. It is possible that a QoS profile is available during the bridge capability reporting phase but not during the bridge configuration phase. Therefore, during the bridge configuration phase, a QoS flow verification step is required in the QoS mapping method proposed in the '727 application.

[0050] This document proposes embodiments of a solution that addresses several issues by providing a new procedure for establishing a static TSN connection between a UE-side TSN converter (UE / TT) (i.e., the TT converter is integrated into the UE or as a separate unit communicatively coupled to the UE) and a UPF-side TSN converter (UPF / TT) (i.e., the TT converter is integrated into the UPF or as a separate unit communicatively coupled to the UE) with 5GS as a bridge (the model currently adopted in [1]).

[0051] Disclosed herein are systems and methods for establishing a static TSN connection between a user equipment (UE)-side TSN translator (UE / TT) and a user plane function (UPF)-side TSN translator (UPF / TT) of a cellular communication system (e.g., a fifth generation (5G) system (5GS)) operating as a bridge in a time-sensitive network (TSN).

[0052] Embodiments of methods for operating a session management function (SMF) and corresponding SMF embodiments are disclosed. In some embodiments, a method for operating an SMF in a cellular communication system (e.g., 5GS) operating as a bridge for a TSN includes: communicating with one or more other network entities for a protocol data unit (PDU) session establishment process, establishing an always-on PDU session to the TSN in the PDU session establishment process; pre-establishing one or more quality of service (QoS) flows in the always-on PDU session; and distributing one or more packet detection rules (PDRs) to a UPF associated with the PDU session and / or distributing one or more QoS rules to a UE associated with the PDU session, so that a service class of the TSN is bound to a QoS flow in the cellular communication system.

[0053] With the solution disclosed in this article, the 5GS truly acts as a bridge because the port-to-port connections are fixed and pre-established. The CNC does not need to trigger the establishment of QoS flows within existing PDU sessions. Nor does it need to configure a mapping table between TSN service classes and QoS flows. Because static connections are pre-established at the user plane level, the complex signaling process on the 5GS control plane and the latency caused by signaling overhead are avoided.

[0054] The solution disclosed in this article can improve the performance and capabilities of 5G virtual TSN bridges in the following aspects:

[0055] 1. Embodiments of the solution disclosed herein can provide a user-plane-based QoS mapping mechanism for TSN-5G QoS mapping, where the QoS mapping table is pre-configured in the user-plane node. However, this is not limited to situations where the QoS mapping table can be exchanged between the control-plane node and the user-plane node.

[0056] 2. The embodiments of the solution disclosed in this article can be applied to TSN networks with or without CNC. They can be used for control plane-based QoS mapping (i.e., negotiation between 5GS and TSN) and user plane-based QoS mapping.

[0057] 3. Embodiments of the solution disclosed herein provide the option of using pre-established QoS flows during the bridge capability reporting (bridge loading) phase. Several potential benefits are:

[0058] a. Since the 5G QoS flow has been established during the bridge capability reporting phase, the delay caused by the signaling process of QoS flow establishment during the bridge configuration phase is reduced;

[0059] b. Ensure service availability through QoS flow establishment and uninterrupted PDU sessions; and

[0060] c. Via pre-established QoS flows and pre-configured mapping tables to TSN service classes, the process of new TSN service initiation in a 5G virtual bridge is potentially simplified (e.g., the QoS flow verification step during the 5G bridge configuration phase can be omitted).

[0061] Before describing the embodiments of the present disclosure in more detail, it is helpful to briefly describe 5GS. In this regard, Figure 1 An example of a cellular communication system 100 in which embodiments of the present disclosure may be implemented is shown. In the embodiments described herein, the cellular communication system 100 is a 5GS including an NR RAN (also referred to as a next generation (NG) RAN). In this example, the RAN includes base stations 102-1 and 102-2 (referred to as gNBs in 5GS) that control respective (macro) cells 104-1 and 104-2. Base stations 102-1 and 102-2 are generally referred to herein as base stations 102 and individually as base stations 102. Similarly, (macro) cells 104-1 and 104-2 are generally referred to herein as (macro) cells 104 and individually as (macro) cells 104. The RAN may also include a plurality of low-power nodes 106-1 to 106-4 that control respective small cells 108-1 to 108-4. The low-power nodes 106-1 to 106-4 may be small base stations (e.g., pico or femto base stations) or remote radio heads (RRHs), among others. It is worth noting that, although not shown, one or more of the small cells 108-1 to 108-4 may alternatively be provided by the base station 102. The low power nodes 106-1 to 106-4 are generally referred to herein as low power nodes 106 and individually as low power nodes 106. Similarly, the small cells 108-1 to 108-4 are generally referred to herein as small cells 108 and individually as small cells 108. The cellular communication system 100 also includes a core network 110, which is referred to as a 5G core (5GC) in 5GS. The base station 102 (and optionally, the low power node 106) is connected to the core network 110.

[0062] Base station 102 and low power node 106 provide service to wireless devices 112-1 through 112-5 in respective cells 104 and 108. Wireless devices 112-1 through 112-5 are generally referred to herein collectively and individually as wireless devices 112. Wireless devices 112 are also sometimes referred to herein as UEs.

[0063] Figure 2 A wireless communication system is shown represented as a 5G network architecture consisting of core NFs, where the interaction between any two NFs is represented by point-to-point reference points / interfaces. Figure 2 can be considered as Figure 1 A specific embodiment of the system 100 is provided.

[0064] From the access side, Figure 2 The 5G network architecture shown includes multiple UEs 112 connected to a radio access network (RAN) or access network (AN) and an AMF 200. Typically, the R(AN) includes a base station 102, such as an eNB or gNB. From the core network side, Figure 2 The 5G core NF shown includes a network slice selection function (NSSF) 202, an AUSF 204, a UDM 206, an AMF 200, an SMF 208, a PCF 210, an application function (AF) 212, and a user plane function (UPF) 214.

[0065] The reference points of the 5G network architecture represent detailed call flows used in developing standardization specifications. The N1 reference point is defined as carrying signaling between the UE 112 and the AMF 200. The reference points for connecting the AN and the AMF 200 and the AN and the UPF 214 are defined as N2 and N3, respectively. Reference point N11 exists between the AMF 200 and the SMF 208. N4 is used by the SMF 208 and the UPF 214 so that the UPF 214 can be configured using control signals generated by the SMF 208 and the UPF 214 can report its status to the SMF 208. N9 is a reference point for connecting different UPFs 214, while N14 is a reference point for connecting different AMFs 200. N15 and N7 are defined because the PCF 210 applies policies to the AMF 200 and SMF 208, respectively. N12 is required by the AMF 200 to authenticate the UE 112. Since AMF 200 and SMF 208 require the subscription data of the UE, N8 and N10 are defined.

[0066] The 5G core network is designed to separate the user plane and the control plane. The user plane carries user services, while the control plane carries signaling in the network. Figure 2 In this architecture, UPF 214 is located in the user plane, while all other NFs (i.e., AMF 200, SMF 208, PCF 210, AF 212, NSSF 202, AUSF 204, and UDM 206) are located in the control plane. Separating the user and control planes ensures that resources for each plane are scaled independently. It also allows UPF 214 to be deployed in a distributed manner, separate from the control plane functions. In this architecture, UPF 214 can be deployed very close to UE 112 to reduce the round-trip time (RTT) between UE 112 and the data network for some applications that require low latency.

[0067] The core 5G network architecture consists of modular functions. For example, AMF 200 and SMF 208 are independent functions in the control plane. Separating AMF 200 and SMF 208 allows for independent evolution and scaling. Other control plane functions like PCF 210 and AUSF 204 can be Figure 2 The modular functional design enables the 5G core network to flexibly support various services.

[0068] Each NF interacts directly with another NF. Intermediary functions can be used to route messages from one NF to another. In the control plane, the set of interactions between two NFs is defined as a service, allowing for reuse. This service supports modularity. The user plane supports interactions such as forwarding operations between different UPFs 214.

[0069] Figure 3 Shows the use of service-based interfaces between NFs in the control plane instead of Figure 2 The 5G network architecture uses point-to-point reference points / interfaces in the 5G network architecture. However, the above reference Figure 2 The described NF corresponds to Figure 3 The services provided by NF to other authorized NFs can be exposed to authorized NFs through service-based interfaces. Figure 3 In the NF, the service-based interface is indicated by the letter "N" followed by the name of the NF, for example, Namf represents the service-based interface of AMF 200, and Nsmf represents the service-based interface of SMF 208, etc. Figure 3 The Network Exposure Function (NEF) 300 and NRF 302 in the above Figure 2 However, it should be clear that Figure 2 All NFs depicted in Figure 3 NEF and NRF interact, although not in Figure 2 Clear instructions in.

[0070] Figure 2 and Figure 3Some attributes of the NFs shown in FIG can be described as follows. The AMF 200 provides UE-based authentication, authorization, mobility management, and other functions. Even UEs 112 using multiple access technologies are essentially connected to a single AMF 200, as the AMF 200 is access technology-agnostic. The SMF 208 is responsible for session management and allocates IP addresses to UEs 112. It also selects and controls the UPF 214 for data transmission. If a UE 112 has multiple sessions, a different SMF 208 can be assigned to each session to manage them individually and potentially provide different functionality for each session. The AF 212 provides information about packet flows to the PCF 210, which is responsible for policy control, to support QoS. Based on this information, the PCF 210 determines policies regarding mobility and session management to ensure proper operation of the AMF 200 and SMF 208. The AUSF 204 supports authentication functions for UEs 112 and the like and, therefore, stores authentication data for UEs 112 and the like, while the UDM 206 stores subscription data for UEs 112. The Data Network (DN) (not part of the 5G core network) provides internet access or operator services, etc.

[0071] NFs can be implemented as network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on a suitable platform (e.g., cloud infrastructure).

[0072] The embodiments of the present disclosure are more particularly related to 5GS being presented as a TSN bridge for integration with TSN. In this regard, as a Change Request (CR) S2-1906754 to 3GPP Technical Specification (TS) 23.501 Figure 4 .4.8.2-1 Reproduction Figure 4 An example of an architecture is shown where the 5GS behaves as a TSN bridge. Figure 4 As shown in the figure, 5GS is represented as a virtual (or logical) TSN bridge 400. Figure 4 As shown and described above, the 5GS includes a UE 112, an (R)AN including one or more RAN nodes (shown as reference numeral 102 in this example, which corresponds to the base station 102), and multiple core network nodes (also referred to herein as core network functions). As shown, the core network nodes include AMF 200, UDM, SMF, PCF, NEF, and UPF. In addition, in this example, there is also a TSN AF 402, Figure 4 The TSN converter (TT) on the UE side (also referred to herein as UE-side TT or UE / TT) represented as DS-TT 404 in FIG. Figure 44. FIGURE 214 illustrates a UPF-side TSN TT (also referred to herein as a UPF-side TT or UPF / TT) represented as NW-TT 406 in FIGURE 214. In this example, DS-TT 404 is shown as being external to UE 112 and NW-TT 406 is shown as being internal to the UPF. However, in other embodiments, DS-TT 404 may alternatively be implemented within UE 112 and / or NW-TT 406 may alternatively be implemented outside of UPF 214.

[0073] According to an embodiment of the present disclosure, the 5GS is configured to be equivalent to a TSN bridge 400 whose port-to-port connections are fixed and pre-established. The following aspects are considered to maintain static TSN connections in the 5GS:

[0074] I. Uninterrupted PDU Session

[0075] II. QoS Flow Pre-configuration

[0076] III. Pre-configured TSN-5G Q in the User Plane o S-mapping table

[0077] IV.TSN Service Transmission

[0078] V. Example Implementations

[0079] I. Uninterrupted PDU Session

[0080] Deactivation of the user plane (UP) connection of an existing PDU session results in deactivation of the corresponding data radio bearers and N3 tunnels. In order to maintain a static connection with the TSN and avoid delays caused by the signaling procedures enabled by the UP connection, deactivation of the UP connection should be avoided.

[0081] A PDU session connected to a TSN can be established as an uninterrupted PDU session. In this case, the SMF 208 should not deactivate the UP connection of the PDU session due to inactivity.

[0082] II. QoS flow pre-configuration (pre-establishment)

[0083] The QoS flow is pre-configured (or pre-established) during the 5G bridge capability reporting phase (also known as the bridge loading phase). In this case, a QoS flow with a specific 5QI is established even if no TSN traffic passes through the QoS flow.

[0084] The QoS information may be pre-configured in the SMF 208 or the UE 112.

[0085] Pre-configuration in SMF 208: When UE 112 establishes a PDU session to a specified TSN, SMF 208 establishes the required QoS flow for UE 112 based on the pre-configured QoS profile. For more details, see clause 4.3.2 of [3].

[0086] Pre-configuration in UE 112: If the QoS requirements for TSN are pre-configured in UE 112, then after a successful PDU session establishment, UE 112 initiates a PDU session modification procedure that includes TSN-related QoS rules for the QoS processing request. Then, the corresponding QoS flow for the TSN service can be established.

[0087] III. Pre-configuration of TSN-5G QoS Mapping Table in User Plane

[0088] Pre-configured based on SMF 208:

[0089] If a QoS flow is pre-configured in the SMF 208, the SMF 208 maintains a mapping table of TSN traffic classes and binds the traffic class to the QoS flow. The SMF 208 assigns a QoS Flow Identifier (QFI) to the new QoS flow and derives its QoS profile, uplink and downlink packet detection rules (PDRs), and QoS rules. For more details, see Section 5.7 of [2].

[0090] • Uplink and downlink PDRs are provided by the SMF 208 to the UPF 214. The UPF 214 maps UP traffic (eg, different traffic classes) to QoS flows based on the PDRs.

[0091] • QoS rules are provided by the SMF 208 to the UE 112 over the N1 reference point via the AMF 200. The UE 112 performs association of uplink traffic with QoS flows based on the QoS rules.

[0092] The QoS profile is provided to the AN 102 by the SMF 208 via the AMF 200 over the N2 reference point or is pre-configured in the AN 102.

[0093] In case of using IEEE 802.1Qcc CNC, a portion of the table (e.g., available TSN service classes associated with bridge identifiers (IDs) and port IDs) is reported to the AF 402 during the capability reporting phase. In this case, the CNC is aware of the available TSN service classes.

[0094] In case CNC is not available (e.g. IEEE 802.1Qcc fully distributed model), 5GS will collect information on the required parameters to be available to the TSN network (similar concept to the bridge capability reporting phase in the CNC case). A portion of the table (e.g. available TSN service classes associated with bridge ID and port ID) may be distributed from the SMF 208 to the UPF 214 or the TT (TSN translator) on the UPF side (i.e. NW-TT 406). This is done in Figure 12 Specifically, Figure 12 As shown, the SMF 208 obtains the QoS mapping table (step 1200). The SMF 208 may obtain the QoS mapping table in any manner described herein. The SMF 208 then distributes at least a portion of the QoS mapping table to the UPF 214 or the NW-TT 406 (step 1202). As described herein, in some embodiments, the QoS mapping table is pre-configured. Also as described herein, in some embodiments, the QoS flow includes a pre-established QoS flow.

[0095] Variation 1: The SMF 208 may have different “pre-configured” mapping tables for different UPFs. This may depend on other aspects, such as how the 5G bridge is modeled.

[0096] Variation 2: The mapping table may be pre-configured (stored) directly in the UPF 214 .

[0097] Based on UE pre-configuration:

[0098] If QoS rules are pre-configured in UE 112, UE 112 maintains a mapping table between TSN service classes and QoS requests. UE 112 requests specific QoS treatment for the selected service class. The PDU Session Modification Request includes a packet filter describing the service class. The request for specific QoS is sent to SMF 208 via AMF 200 over the N1 reference point.

[0099] The SMF 208 assigns a QFI for the new QoS flow and derives its QoS profile, uplink and downlink PDRs, and QoS rules based on the UE QoS request. The QoS rules are delivered to the UE 112 via a response to the AMF 200. The SMF 208 updates the uplink PDR for the new QoS flow for the UPF 214.

[0100] IV.TSN Service Processing

[0101] a. Case 1 with CNC (e.g., applies to both fully centralized models and centralized network / distributed user models)

[0102] Based on the flow requirements from the end stations in TSN, the CNC calculates the transmission schedule and network path. The CNC distributes the TSN QoS requirements and TSN scheduling parameters (specific to the current node) to the 5G virtual bridge via the TSN AF402.

[0103] For the 5G virtual bridge 400 with static TSN connections, the relevant QoS flows have been established, and the TSN AF 402 may not need to trigger a PDU session modification procedure for establishing the QoS flows.

[0104] In a system using time-aware scheduling to meet QoS requirements (IEEE 802.1Qbv[5]), and when managed objects on the 5G virtual bridge 400 are modified for traffic scheduling (e.g., changes to the gate control list), information is delivered to the DS-TT 404 and the NW-TT 406.

[0105] If the CNC indicates that it can support the end station's QoS requirements, the CUC configures the talker and listener for the streaming (this process is outside the scope of 3GPP), and the communication begins.

[0106] Figure 5 The process of UE loading and reporting virtual bridge capability to CNC according to some embodiments of the present disclosure is shown. Figure 5 Steps of the process shown:

[0107] ·Step 500a: Establish a PDU session to the TSN based on UE request or via network trigger. The PDU session connected to the TSN can be established as an uninterrupted PDU session. As used herein, an "uninterrupted" PDU session is as defined in 3GPP TS 23.502 V16.0.2 Section 5.6.13, which describes: "An uninterrupted PDU session is a PDU session for which user plane resources must be enabled during each transition from CM idle mode to CM connected state." As described above, if the 5GS QoS profile (i.e., the 5GS QoS profile related to TSN) and the corresponding TSN traffic class are pre-configured (mapping table) in the SMF 208, the SMF 208 establishes the required QoS flow in the PDU session and binds the traffic class to the QoS flow via distributing the PDR in the UPF 214 and distributing the QoS rules in the UE 112. Note that distributing the PDR to the UPF 214 and distributing the QoS rules to the UE 112 are part of the PDU session establishment process.

[0108] o Variation 1: Pre-establishment of QoS flows is based on a pre-configured mapping table at the SMF 208 or PCF 210.

[0109] Variation 2: QoS flows are pre-established based on available 5G resources. The SMF 208 or PCF 210 maintains a mapping table for all QoS flows. Based on the established QoS flows, the SMF 208 or PCF 210 selects a portion of the mapping table and reports it to the AF 402 (in the case of a CNC). In the absence of a CNC, the SMF 208 or UPF 214 can select a portion of the mapping table for use by the TSN network.

[0110] Step 500b (optional): As described above, if the 5GS QoS profile and the corresponding TSN traffic class are pre-configured in the UE 112, then after successfully establishing the PDU session, the UE 112 initiates a PDU session modification procedure, which includes TSN-related QoS rules for handling the TSN traffic class. In other words, using the PDU session modification procedure, the UE 112 provides information about the QoS profile and the corresponding traffic class to the network (e.g., to the SMF 208). This information may include the QoS requirements for TSN. Then, based on the information obtained from the UE 112, the SMF 208 establishes all required QoS flows and binds the traffic class to the QoS flow (mapping table) via the distribution of the PDR in the UPF 214 and the distribution of the QoS rules in the UE 112. Note that the distribution of the PDR to the UPF 214 and the distribution of the QoS rules to the UE 112 are part of the PDU session modification procedure.

[0111] Step 502: Based on the request from the SMF 208, the TTs in the UE side and the UPF side (ie, the DS-TT 404 and the NW-TT 406) collect network topology, propagation delay, and TSN related information, and provide the information to the SMF 208.

[0112] • Step 504: Based on the SMF event notification, report the TSN bridge management information (bridge ID, port ID) and supported QoS parameters for TSN to the TSN AF 402 (directly or via the NEF 300).

[0113] • Step 506 (optional): TSN AF 402 may notify the CNC to read the capability report, for example, when a bridge capability change / update event occurs.

[0114] Step 508: The CNC reads the capability report from the 5GS virtual bridge.

[0115] Note that steps 502 through 508 are identical to the corresponding steps performed in the '727 application.

[0116] Figure 6The process of using CNC to configure virtual bridge and transmit services according to some embodiments of the present disclosure is shown below. Figure 6 Steps of the process:

[0117] Step 600: Based on the flow requirements from the TSN end stations, the CNC calculates the transmission schedule and network path. The CNC distributes the TSN QoS requirements and TSN scheduling parameters (specific to the current node) to the 5G virtual bridge via the TSN AF.

[0118] Step 602: Since the QoS flows have already been pre-established and reported to the CNC for use by the TSN, the bridge configuration does not require the establishment of 5G QoS flows; however, there may be an optional function.

[0119] o Step 602a (optional): The TSN AF may verify the capabilities of the bridge to check whether it is still able to satisfy the request from the CNC and whether the relevant resources are available.

[0120] Step 602b (optional): Similarly, if QoS flows are pre-established, the TSN network (e.g., CNC) can select only some of the QoS flows. AF can then inform the 5GS which QoS flows are actually in use, and the 5GS can then perform further resource optimization, such as using other resources for redundancy.

[0121] o Step 602c: The AF may take actions other than QoS mapping, such as delivering other TSN parameters (Qbv scheduling, time-sensitive communication assistance information) to the relevant 5G nodes.

[0122] Step 604 (optional): TSN AF responds to CNC.

[0123] Step 606: If the CNC indicates that it can support the QoS requirements of the end station, the CUC configures the talker and listener for the streaming (this process is outside the scope of 3GPP) and the new TSN streaming service can be transported in the 5G virtual bridge.

[0124] b. Case 2 - No CNC (e.g., applied to a fully distributed model)

[0125] In the case where CNC is not available (e.g., IEEE 802.1Qcc fully distributed model), 5GS will collect information on the required parameters to be available to the TSN network (similar concept to the bridge capability reporting phase in the case of CNC). A portion of the table (e.g., available TSN service classes associated with bridge IDs and port IDs) can be distributed from the SMF to the UPF or TT (TSN Translator) on the UPF side.

[0126] Corresponding traffic filters (PDRs) and QoS rules are pre-configured to bind the QoS flows with the traffic class / priority of the incoming traffic at the UPF (downlink traffic) and UE (uplink traffic), respectively.

[0127] V. Example Implementations

[0128] An example implementation of at least some aspects of the present disclosure will now be described. In 23.501, Section 5.29.1, the following operations are specified:

[0129]

[0130] The bridge information reported to the CNC includes the 802.1Qcc bridge latency attributes of the 5GS ports to be used for the path through the 5GS. Since these ports correspond to the UE and UPF, the UE must register and establish a PDU session for selecting one or more UPFs for it. Once the UE and UPF are known, the 5GS can report the bridge information to the TSN network, and the CNC can calculate the port configuration using 802.1Qbv (as specified in 5.29.2 of 23.501).

[0131] There are two options for supporting 5GS QoS.

[0132] 1. Pre-configured / static QoS: The 5GS QoS for the TSC flow is pre-configured or set at PDU session establishment, before receiving path configuration information from the CNC. In this case, TCSAI and other flow-specific characteristics are unknown, no TSC flow-specific QoS is applied in 5GS, and the default QoS parameters for TSC 5QI must be used. AF-triggered PDU session modification due to receiving the 802.1Qbv gate parameter table is not required.

[0133] 2. Dynamic QoS: After the CNC determines the e2e path and provides the 802.1Qbv gate parameter table for the egress port, the QoS of the TSC flow is modified via the PDU session. Optionally, other information indicating the QoS requirements of the TSC flow is provided to the AF (e.g., information sent directly from the CUC to the AF). In order to modify the PDU session after receiving configuration information from the TSN network, a binding must be established between the PDU session and the bridge configuration information provided by 802.1Qbv. In this way, when the configuration information is received from the CNC, the PDU session to be modified is known.

[0134] 802.1Qbv provides a gate parameter table for 5GS bridge egress ports. For each traffic class on a port, the gate control list specifies the transmission gate state of "open" or "closed" according to time (independent of the TSN flow ingress port). In addition, although the CNC calculates all TSN flows that accommodate all UE / PDU sessions on the egress port, the bridge only receives per-port, per-traffic class information. 802.1Qbv does not provide flow level and ingress port information to the bridge. Therefore, the possible identifiers from the CNC that can be used to identify the PDU session are the egress port bridge ID and the port ID. It is assumed here that traffic classes will be mapped to QoS flows, as has been suggested in several related contributions.

[0135] There are two cases to consider:

[0136] Downlink flow at UE egress port: When a PDU session is established, it can be uniquely bound to the port ID assigned to the UE. When the CNC provides 802.1Qbv configuration information for the UE port, it can trigger a PDU session modification based on the binding.

[0137] Note that the gate state of the service class carrying the TSN flow will reflect the on / off requirements of that flow over time. The 5GS QoS flows mapped to the service class carrying the TSN traffic can be modified accordingly.

[0138] Uplink flows at UPF egress ports: Several bridge configuration options have been considered in S2-190172 and subsequent revisions.

[0139] o If the 5GS Bridge is configured as a "5G Bridge per PDU Session" (Option 4, where each UE / PDU Session is a logical bridge), then upon PDU Session establishment, the PDU Session may be uniquely bound to the Bridge ID. When the CNC provides 802.1Qbv configuration information for that Bridge ID, PDU Session modification may be triggered based on this binding.

[0140] o If the 5GS Bridge is configured as a "5G Bridge per UE" (Option 3, where each UE / PDU Session is a logical bridge), then at PDU Session establishment, the PDU Session can be uniquely bound to the Bridge ID and UPF Port ID. When the CNC provides 802.1Qbv configuration information for that UPF Port ID and Bridge ID, a PDU Session modification can be triggered based on this binding.

[0141] As in the case of downlink flows, the gate state for the traffic class carrying TSN flows will reflect the on / off requirements of that flow over time. The 5GS QoS flows mapped to the traffic class carrying TSN traffic can be modified accordingly.

[0142] For other 5GS bridge configurations, such as a monolithic 5GS bridge or logical bridges on a per-UPF basis (one 5GS bridge per UPF), either:

[0143] 1. When a PDU session is established, the PDU session must be bound to a unique UPF port ID, which is then provided to the CNC for path calculation. While the physical UPF port does not change, the UPF port ID provided to the CNC must be unique for the PDU session. The applicability of this option may depend on the CNC capabilities; or

[0144] 2. Because the PDU session cannot be determined based on the 802.1Qbv port configuration information, option 1 above will be applied.

[0145] In order to accommodate the various scenarios described above for uplink and downlink TSN flows, it is recommended that the PDU session be bound to a unique UE port ID, UPF port ID, and bridge ID when the PDU session is established. The SMF assigns an ID (e.g., a unique UPF port ID for the PDU session or a public UPF port ID for the UPF physical port) based on the 5GS bridge configuration and the operator's desired QoS type (pre-configured / static or dynamic). This approach provides the flexibility to support future bridge configuration methods (e.g., 802.1Qci) that provide per-flow visibility.

[0146] With the foregoing in mind, one example implementation of some aspects of the embodiments of the present disclosure may be represented as a Change Request (CR) to 23.501 V16.0.2 as follows:

[0147]

[0148]

[0149] VI. Additional Aspects

[0150] Figure 7is a schematic block diagram of a network node 700 according to some embodiments of the present disclosure. Network node 700 may be, for example, a base station 102 or 106 (e.g., a gNB) or a network node implementing a core network entity (e.g., a UPF, a UPF-side TT separate from the UPF, a TSN AF, an SMF, a PCF, or some other core network entity). As shown, network node 700 includes a control system 702, which includes one or more processors 704 (e.g., a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc.), a memory 706, and a network interface 708. The one or more processors 704 are also referred to herein as processing circuitry. Furthermore, if network node 700 is a radio access node, network node 700 includes one or more radio units 710, each of which includes one or more transmitters 712 and one or more receivers 714 coupled to one or more antennas 716. Radio unit 710 may be referred to as, or part of, a radio interface circuit. In some embodiments, the radio unit 710 is external to the control system 702 and is connected to the control system 702 via, for example, a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit 710 and (possibly) the antenna 716 are integrated with the control system 702. The one or more processors 704 operate to provide one or more functions of the network node 700 as described herein (e.g., as described herein, for example, with respect to Figure 5 and Figure 6 One or more functions of the gNB, UPF, UPF-side TT, TSN AF, AMF, SMF, PCF, NEF, etc.). In some embodiments, these functions are implemented in software stored in the memory 706 and executed by one or more processors 704.

[0151] Figure 8is a schematic block diagram illustrating a virtualized embodiment of a network node 700 according to some embodiments of the present disclosure. As used herein, a "virtualized" network node is an embodiment of a network node 700 in which at least a portion of the functionality of the network node 700 is implemented as a virtual component (e.g., via a virtual machine executing on a physical processing node in the network). As shown, in this example, the network node 700 includes one or more processing nodes 800 coupled to a network 802 via a network interface 708 or included as part of the network 802. Each processing node 800 includes one or more processors 804 (e.g., a CPU, ASIC, FPGA, etc.), a memory 806, and a network interface 808. If the network node 700 is a radio access node, the network node 702 also includes a radio unit 710, and optionally includes a control system 702 and / or one or more radio units 710. Note that if the radio access node includes a radio unit 710 but does not include a control system 702, the radio unit 710 includes a network interface that communicatively couples the radio unit 710 to the network 802.

[0152] In this example, the functionality 810 of the network node 700 described herein (e.g., as described herein, for example, with respect to Figure 5 and Figure 6 One or more functions of the gNB, UPF, UPF-side TT, TSN AF, AMF, SMF, PCF, NEF, etc.) are implemented at one or more processing nodes 800 or distributed in any desired manner between the control system 702 and one or more processing nodes 800. In some specific embodiments, some or all of the functions 810 of the radio access node 700 described herein (e.g., as described herein, for example, with respect to Figure 5 and Figure 6 One or more functions of the gNB, UPF, UPF side TT, TSN AF, AMF, SMF, PCF, NEF, etc. are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment hosted by the processing node 800.

[0153] In some embodiments, a computer program comprising instructions is provided that, when executed by at least one processor, causes the at least one processor to perform the functions of a network node 700 or a node (e.g., processing node 800) that implements one or more functions 810 of the network node 700 in a virtual environment according to any embodiment described herein. In some embodiments, a carrier comprising the 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 a memory).

[0154] Figure 9is a schematic block diagram of a network node 700 according to some other embodiments of the present disclosure. The network node 700 includes one or more modules 900, each of which is implemented in software. The modules 900 provide the functionality of the network node 700 described herein. This discussion also applies to Figure 8 800 , where module 900 may be implemented at one of processing nodes 800 or distributed across multiple processing nodes 800 and / or across processing nodes 800 and control system 702 .

[0155] Figure 10 10 is a schematic block diagram of a UE 1000 according to some embodiments of the present disclosure. As shown, the UE 1000 includes one or more processors 1002 (e.g., CPU, ASIC, FPGA, etc.), a memory 1004, and one or more transceivers 1006, each transceiver 1006 including one or more transmitters 1008 and one or more receivers 1010 coupled to one or more antennas 1012. The transceiver 1006 includes a radio front-end circuit connected to the antenna 1012, which is configured to condition the signal transmitted between the antenna 1012 and the processor 1002, as will be understood by a person of ordinary skill in the art. The processor 1002 is also referred to herein as a processing circuit. The transceiver 1006 is also referred to herein as a radio circuit. In some embodiments, the functions of the above-mentioned UE 1000 (and / or UE-side TT) may be implemented in whole or in part in software, for example, stored in the memory 1004 and executed by the processor 1002. Note that the UE 1000 may include Figure 10 Additional components not shown in the figure, such as one or more user interface components (e.g., input / output interfaces including a display, buttons, a touch screen, a microphone, a speaker, etc. and / or any other components for allowing information to be input to and / or allowing information to be output from the UE 1000), a power source (e.g., a battery and associated power circuitry), etc.

[0156] In some embodiments, a computer program comprising instructions is provided that, when executed by at least one processor, causes the at least one processor to perform the functionality of the UE 1000 according to any of the embodiments described herein. In some embodiments, a carrier comprising the 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 a memory).

[0157] Figure 11 1 is a schematic block diagram of a UE 1000 according to some other embodiments of the present disclosure. The UE 1000 includes one or more modules 1100, each of which is implemented in software. The modules 1100 provide the functions of the UE 1000 described herein.

[0158] Any appropriate steps, methods, features, functions or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of such functional units. These functional units may be implemented via processing circuits (which may include one or more microprocessors or microcontrollers) and other digital hardware (which may include digital signal processors (DSPs), dedicated digital logic, etc.). The processing circuit may be configured to execute program code stored in a memory, which may include one or more types of memory, such as read-only memory (ROM), random access memory (RAM), cache memory, flash memory device, optical storage device, etc. The program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for executing one or more technologies described herein. In some embodiments, the processing circuit may be used to cause the corresponding functional units to perform the corresponding functions according to one or more embodiments of the present disclosure.

[0159] Although the processes in the figures may illustrate a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc.).

[0160] Some example embodiments of the present disclosure are as follows.

[0161] Embodiment 1: A method of operating a session management function (SMF) in a cellular communication system (e.g., a fifth generation 5G system 5GS) operating as a bridge of a time-sensitive network (TSN), the method comprising one or more of the following actions:

[0162] Communicating (500a) with one or more other network entities to perform a protocol data unit (PDU) session establishment procedure in which an uninterrupted PDU session to the TSN is established;

[0163] pre-establishing (500a or 500b) one or more Quality of Service (QoS) flows in the uninterrupted PDU session; and

[0164] Distributing (500a or 500b) one or more packet detection rules (PDRs) to a user plane function (UPF) associated with the uninterrupted PDU session and / or distributing (500a or 500b) one or more QoS rules to a user equipment (UE) associated with the uninterrupted PDU session, such that the service class of the TSN is bound to the qoS flow in the cellular communication system.

[0165] Embodiment 2: The method of embodiment 1, wherein the user plane UP connection of the uninterrupted PDU session is not deactivated due to inactivity.

[0166] Embodiment 3: The method according to embodiment 1 or 2, wherein establishing one or more QoS flows comprises establishing one or more QoS flows based on pre-configured information.

[0167] Embodiment 4: The method according to any one of embodiments 1 to 3, wherein the one or more PDRs distributed to the UPF are based on pre-configured information and / or the one or more QoS rules distributed to the UE are based on pre-configured information.

[0168] Embodiment 5: The method according to embodiment 3 or 4, wherein the pre-configured information is pre-configured in the SMF.

[0169] Embodiment 6: The method according to embodiment 3 or 4, wherein the pre-configured information is pre-configured in the UE, and the method further comprises: after the PDU session establishment process, receiving (500b) the pre-configured information during the PDU session modification process.

[0170] Embodiment 7: The method according to any one of embodiments 3 to 6, wherein the pre-configured information includes one or more pre-configured QoS profiles and corresponding service categories (ie, a mapping table).

[0171] Embodiment 8: The method according to any one of embodiments 1 to 7 further comprises sending (504) a bridge capability report to a controller of the TSN.

[0172] Embodiment 9: A session management function SMF, adapted to perform the method according to any one of embodiments 1 to 8.

[0173] At least some of the following abbreviations may be used in this disclosure. If there is a discrepancy between abbreviations, the above usage shall take precedence. If listed multiple times below, the first listing shall take precedence over any subsequent listings.

[0174] μs microseconds

[0175] 3GPP Third Generation Partnership Project

[0176] 5G fifth generation

[0177] 5GC fifth generation core

[0178] 5GS fifth generation system

[0179] 5QI Fifth Generation Service Quality Indicator

[0180] AF application function

[0181] AMF access and mobility management function

[0182] AN Access Network

[0183] ASIC Application-Specific Integrated Circuit

[0184] AUSF authentication server function

[0185] CNC centralized network configuration

[0186] CPU Central Processing Unit

[0187] CR Change Request

[0188] CUC Central User Configuration

[0189] DN Data Network

[0190] DSP digital signal processor

[0191] eNB Enhanced or evolved Node B

[0192] FPGA Field Programmable Gate Array

[0193] gNB New Radio Base Station

[0194] HSS Home Subscriber Server

[0195] ID identifier

[0196] IP Internet Protocol

[0197] LTE Long Term Evolution

[0198] MME Mobility Management Entity

[0199] ms milliseconds

[0200] MTC Machine Type Communication

[0201] NEF network exposure function

[0202] NF Network Function

[0203] NG Next Generation

[0204] NR New Radio

[0205] NRF Network Function Repository function

[0206] NSSF network slice selection function

[0207] PCF policy control function

[0208] PDR group detection rules

[0209] PDU Protocol Data Unit

[0210] P-GW Packet Data Network Gateway

[0211] QFI Quality of Service Flow Identifier

[0212] QoS Quality of Service

[0213] RAM Random Access Memory

[0214] RAN Radio Access Network

[0215] ROM Read Only Memory

[0216] RRH Remote Radio Head

[0217] RTT round trip time

[0218] SCEF service capability exposure function

[0219] SMF session management capabilities

[0220] TR Technical Report

[0221] TS Technical Specifications

[0222] TSN Time-Sensitive Network

[0223] TT Time Sensitive Network Converter

[0224] UDM unified data management

[0225] UE User Equipment

[0226] UP user plane

[0227] UPF User Plane Function

[0228] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure, and all such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

[0229] References

[0230] 1.3GPP TR 23.734: "Study on enhancement of 5G System (5GS) for vertical and Local Area Network (LAN) services";

[0231] 2.3GPP TS 23.501:“System Architecture for the 5G System;Stage 2”.

[0232] 3.3GPP TS 23.502:“Procedures of the 5G System;Stage 2”;

[0233] 4.3GPP TR 23.734:“Study on enhancement of 5G System(5GS)for verticaland Local Area Network(LAN)services”;

[0234] 5.IEEE P802.1Qcc / D1.6:”Draft Standard for Local and metropolitan areanetworks-Bridges and Bridged Networks-Amendment:Stream Reservation Protocol(SRP)Enhancements and Performance Improvements”;

[0235] 6.IEEE P802.1Qbv / D3.1:“Draft Standard for Local and Metropolitan AreaNetworks-Bridges and Bridged Networks-Amendment:Enhancements for ScheduledTraffic”。

Claims

1. A method of operating a session management function (SMF) (208) in a cellular communication system, the cellular communication system operating as a bridge (400) of a time-sensitive networking (TSN) system, the method comprising: Obtaining (1200) a QoS mapping table that maps TSN service classes to quality of service (QoS) flows within the cellular communication system, wherein the QoS mapping table is pre-configured within the cellular communication system; as well as At least a portion of the QoS mapping table is distributed (1202) to a user plane function UPF (214) of the cellular communication system or a TSN converter TT (406) on the UPF side.

2. The method according to claim 1, wherein At least a portion of the QoS mapping table includes available TSN service classes associated with a bridge identifier ID and a port ID.

3. The method according to claim 1 or 2, wherein: Different QoS mapping tables are used for different UPFs.

4. The method according to claim 1 or 2, wherein: The QoS mapping table is pre-configured during a capability reporting phase in which the cellular communication system reports its capabilities related to operating as a bridge for the TSN system.

5. The method according to claim 1 or 2, wherein: The QoS flow includes one or more pre-established QoS flows.

6. The method according to claim 1 or 2, wherein: The QoS flows include one or more QoS flows pre-established during a capability reporting phase in which the cellular communication system reports its capabilities related to operating as a bridge for the TSN system.

7. The method according to claim 1 or 2, wherein: The QoS flows include one or more QoS flows pre-established based on one or more pre-configured QoS profiles when establishing one or more protocol data unit (PDU) sessions to the TSN system.

8. A network node (700) implementing a session management function (SMF) (208) of a cellular communication system operating as a bridge (400) of a time-sensitive networking (TSN) system, the network node (700) comprising: Network interface (708; 808); as well as A processing circuit (704; 804) associated with the network interface (708; 808), the processing circuit (704; 804) being configured to cause the network node (700): Obtaining (1200) a QoS mapping table that maps TSN service classes to quality of service (QoS) flows within the cellular communication system, wherein the QoS mapping table is pre-configured within the cellular communication system; as well as At least a portion of the QoS mapping table is distributed (1202) to a user plane function UPF (214) of the cellular communication system or a TSN converter TT (406) on the UPF side.

9. The network node (700) according to claim 8, wherein At least a portion of the QoS mapping table includes available TSN service classes associated with a bridge identifier ID and a port ID.

10. The network node (700) according to claim 8 or 9, wherein Different QoS mapping tables are used for different UPFs.

11. The network node (700) according to claim 8 or 9, wherein The QoS mapping table is pre-configured during a capability reporting phase in which the cellular communication system reports its capabilities related to operating as a bridge for the TSN system.

12. The network node (700) according to claim 8 or 9, wherein The QoS flow includes one or more pre-established QoS flows.

13. The network node (700) according to claim 8 or 9, wherein The QoS flows include one or more QoS flows pre-established during a capability reporting phase in which the cellular communication system reports its capabilities related to operating as a bridge for the TSN system.

14. The network node (700) according to claim 8 or 9, wherein The QoS flows include one or more QoS flows pre-established based on one or more pre-configured QoS profiles when establishing one or more protocol data unit (PDU) sessions to the TSN system.

15. A method of operating an application function AF (402) in a cellular communication system, the cellular communication system operating as a bridge (400) of a time sensitive networking (TSN) system, the method comprising: During the configuration phase of the bridge (400): receiving ( 600 ) one or more TSN quality of service (QoS) requirements and one or more TSN scheduling parameters from a controller associated with the TSN system; One or more network nodes in the cellular communication system are notified (602b) of which QoS flows of a plurality of QoS flows are being used by the TSN system, wherein the plurality of QoS flows are pre-established based on a pre-configured QoS mapping table, the QoS mapping table mapping TSN service classes to QoS flows within the cellular communication system and stored at a session management function (SMF) (208) or a policy control function (PCF) (210) in the cellular communication system.

16. The method according to claim 15, further comprising: During the configuration phase of the bridge (400): One or more TSN parameters are distributed (602c) to relevant network nodes in the cellular communication system.

17. The method according to claim 16, wherein The one or more TSN parameters include Qbv scheduling and time-sensitive communication assistance information.

18. The method according to any one of claims 15 to 17, further comprising: A response is provided (604) to the controller associated with the TSN system.

19. A network node (700) implementing an application function AF (402) of a cellular communication system operating as a bridge (400) of a time-sensitive networking (TSN) system, the network node (700) comprising: Network interface (708; 808); as well as Processing circuitry (704; 804) associated with the network interface (708; 808), the processing circuitry (704; 804) being configured to cause the network node (700): during a configuration phase of the network bridge (400): receiving ( 600 ) one or more TSN quality of service (QoS) requirements and one or more TSN scheduling parameters from a controller associated with the TSN system; One or more network nodes in the cellular communication system are notified (602b) of which QoS flows of a plurality of QoS flows are being used by the TSN system, wherein the plurality of QoS flows are pre-established based on a pre-configured QoS mapping table, the QoS mapping table mapping TSN service classes to QoS flows within the cellular communication system and stored at a session management function (SMF) (208) or a policy control function (PCF) (210) in the cellular communication system.

20. The network node (700) according to claim 19, wherein the processing circuit (704; 804) is further configured to cause the network node (700): during a configuration phase of the network bridge (400): One or more TSN parameters are distributed (602c) to relevant network nodes in the cellular communication system.

21. The network node (700) according to claim 20, wherein The one or more TSN parameters include Qbv scheduling and time-sensitive communication assistance information.

22. The network node (700) according to any one of claims 19 to 21, wherein the processing circuit (704; 804) is further configured to cause the network node (700) to: provide (604) a response to the controller associated with the TSN system.

Images