Systems and Methods for Time-to-Live Delivery in 5GC

Abstract

The fifth-generation core network (5GC) provides 5G radio access network (RAN) services to a user equipment (UE) in a time-sensitive communication (TSC) network (TSN). This includes: receiving, from the UE, a protocol data unit (PDU) session establishment request that includes an industrial Internet of Things (IIoT) vertical or application type; identifying a TSN application function (AF) associated with the IIoT vertical or application type; determining quality of service (QoS) parameters for communication between the UE and the 5G RAN based on the identified TSN AF, the QoS parameters including a time-to-live for the IIoT vertical or application type; and establishing a PDU session with the UE when the QoS parameters including the time-to-live are satisfied.

Description

Background Art

[0001] Time-Sensitive Networking (TSN) is a technology for deterministic real-time communication. Time synchronization and schedule sharing among components achieve maximum latency of traffic through various network components. Some vertical domains, including, for example, factories and other industrial domains, include Cyber-Physical Systems (CPS) with control applications having strict deterministic requirements. 5G New Radio (NR) has been designed for Industrial Internet of Things (IIoT) communication, and the convergence of 5G and TSN can provide both flexibility and low latency for industrial environments.

[0002] Communication service availability is an important service performance requirement for cyber-physical 5G-TSN systems. The communication service availability requirement is a combination of the latency, lifetime, and reliability requirements of 5G systems. Lifetime is the time during which an application using the communication service can continue to operate without expected messages. The lifetimes of various applications are standardized in 3GPP TS 22.104 5.2 and can depend on the time sensitivity of the application.

[0003] When a cyber-physical TSN application does not receive an expected message after the lifetime of the application expires, the system is considered unavailable for that application. In other words, when the transmission time of the expected message, i.e., the actual latency, is greater than the sum of the maximum end-to-end latency and the lifetime, the system is considered unavailable. Therefore, it is important for the 5G system to know the lifetime of the TSN application to which it will provide services. Summary of the Invention

[0004] In some exemplary embodiments, a method performed by a 5th Generation Core Network (5GC) that provides 5G Radio Access Network (RAN) services to a User Equipment (UE) in a Time-Sensitive Communication (TSC) Network (TSN). The method includes: receiving, from the UE, a Protocol Data Unit (PDU) session establishment request that includes an Industrial Internet of Things (IIoT) vertical or application type; identifying a TSN Application Function (AF) associated with the IIoT vertical or application type; determining Quality of Service (QoS) parameters for communication between the UE and the 5G RAN based on the identified TSN AF, the QoS parameters including the lifetime of the IIoT vertical or application type; and establishing a PDU session with the UE when the QoS parameters including the lifetime are satisfied.

[0005] In other exemplary embodiments, a system is provided that has one or more network components configured to provide a fifth generation core network (5GC) that provides 5G radio access network (RAN) services to a user equipment (UE) in a time sensitive communication (TSC) network (TSN). The one or more network components are configured to: receive a protocol data unit (PDU) session establishment request from the UE, the PDU session establishment request including an industrial Internet of Things (IIoT) vertical or application type; identify a TSN application function (AF) associated with the IIoT vertical or application type; determine quality of service (QoS) parameters for communication between the UE and the 5G RAN based on the identified TSN AF, the QoS parameters including a time to live for the IIoT vertical or application type; and establish a PDU session with the UE when the QoS parameters including the time to live are satisfied.

[0006] In yet other exemplary embodiments, one or more non-transitory computer-readable storage media are provided. The non-transitory computer-readable storage media include a set of instructions that, when executed, cause one or more processors to perform operations. The operations include: receiving a protocol data unit (PDU) session establishment request from a user equipment (UE) in a time sensitive communication (TSC) network (TSN), the PDU session establishment request including an industrial Internet of Things (IIoT) vertical or application type; identifying a TSN application function (AF) associated with the IIoT vertical or application type; determining quality of service (QoS) parameters for communication between the UE and a 5G radio access network (RAN) based on the identified TSN AF, the QoS parameters including a time to live for the IIoT vertical or application type; and establishing a PDU session with the UE when the QoS parameters including the time to live are satisfied. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 A network arrangement is shown in accordance with various exemplary embodiments.

[0008] Figure 2 An exemplary UE is shown in accordance with various exemplary embodiments.

[0009] Figure 3 A signaling diagram is shown in which a time sensitive network (TSN) application function (AF) provides its capabilities to a 5GC in accordance with various exemplary embodiments.

[0010] FIG. 4a shows a first exemplary signaling diagram for providing time sensitive communication (TSC) support information to a policy control function (PCF) in accordance with various exemplary embodiments.

[0011] Figure 4b shows a second exemplary signaling diagram for providing TSC support information to a PCF according to various exemplary embodiments.

[0012] Figure 5 An exemplary signaling diagram is shown in which a PCF obtains a TSN AF address according to various exemplary embodiments.

[0013] Figure 6 A signaling diagram is shown in which a 5G core network (5GC) discovers the lifetime of a UE in a TSN network and establishes a PDU session with the UE according to various exemplary embodiments.

[0014] Figure 7 A method for determining a scaling path for the lifetime of a TSN UE is shown.

[0015] Figure 8 An AF service is shown that can be used to provide AF capabilities from an AF to a network exposure function (NEF) or a network function (NF) repository function (NRF) according to various exemplary embodiments.

[0016] Figure 9 A NEF service is shown that can be used to provide AF capabilities from a NEF to a PCF according to various exemplary embodiments. Detailed Description

[0017] The exemplary embodiments can be further understood with reference to the following description and the related drawings, in which like elements are provided with the same reference numerals. The exemplary embodiments describe a method for obtaining the lifetime of a user equipment (UE) in an industrial Internet of Things (IIoT) vertical or application and including the lifetime in quality of service (QoS) requirements. The method can be performed in a core network (CN) of a 5G NR network, such as a 5GC, and includes: identifying an application function (AF) of a TSN vertical / application that the UE is using, and retrieving the lifetime from the AF. When establishing a PDU session between the UE and the 5GC, the lifetime is then transmitted to the UE via various network components. Each of these operations will be described in more detail below.

[0018] Figure 1FIG. 100 shows a network arrangement 100 according to various exemplary embodiments. The network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, a tablet computer, a smart phone, a phablet, an embedded device, a wearable device, a Cat-M device, a Cat-M1 device, an MTC device, an eMTC device, other types of Internet of Things (IoT) devices, etc. An actual network arrangement may include any number of UEs used by any number of users. Therefore, the example of a single UE 110 is provided for illustrative purposes only. In an embodiment of the present invention, the UE 110 may be an IIoT UE in an industrial plant system configured for low-latency TSN communication.

[0019] The UE 110 may be configured to communicate directly with one or more networks. In an example of the network arrangement 100, the UE 110 may wirelessly communicate with a 5G New Radio (NR) Radio Access Network (5G NR RAN) 120 and a Wireless Local Area Network (WLAN) 122. However, the UE 110 may also communicate with other types of networks (such as an LTE RAN, a legacy RAN, etc.). The UE 110 may also communicate with a network via a wired connection. Therefore, the UE 110 may include a 5G NR chipset for communicating with the 5G NR RAN 120 and an ISM chipset for communicating with the WLAN 122.

[0020] The 5G NR RAN 120 may be part of a cellular network deployable by a network operator (such as Verizon, AT&T, Sprint, T-Mobile, etc.). The 5G NR RAN 120 may include, for example, cells or base stations (Node B, eNodeB, HeNB, eNBS, gNB, gNodeB, macro cell base stations, micro cell base stations, small cell base stations, femto cell base stations, etc.) configured to send and receive communication traffic from UEs equipped with appropriate cellular chipsets. The WLAN 122 may include any type of wireless local area network (WiFi, hotspot, IEEE 802.11x network, etc.).

[0021] The UE 110 can be connected to the 5G NR RAN 120 via a next-generation Node B (gNB) 120A. Those skilled in the art will understand that any relevant process can be executed for the UE 110 to connect to the 5G NR RAN 120. For example, as described above, the 5G NR RAN 120 can be associated with a specific network operator where the UE 110 and / or its user has protocol and credential information (e.g., stored on the SIM card). When detecting the presence of the 5G NR RAN 120, the UE 110 can transmit the corresponding credential information to be associated with the 5G NR RAN 120. More specifically, the UE 110 can be associated with a specific cell (e.g., the gNB 120A of the 5G NR RAN 120). As described above, the use of the 5G NR RAN 120 is for illustrative purposes, and any type of network can be used. For example, the UE 110 can also be connected to an LTE-RAN (not shown) or a legacy RAN (not shown).

[0022] In addition to the networks 120 and 122, the network arrangement 100 further includes a cellular core network (CN) 130, i.e., the 5GC. The cellular core network 130 can be regarded as an interconnected collection of components that manage the operations and traffic of the cellular network. In the embodiments of the present invention, the components of the CN 130 include an Access and Mobility Management Function (AMF) 132, a Session Management Function (SMF) 134, a Network Exposure Function (NEF) 136, a Network Function (NF) Repository Function (NRF) 138, a Policy Control Function (PCF) 140, a User Plane Function (UPF) 142, and an Application Function (AF) 144. However, the actual cellular core network may include various additional components that perform any of a variety of different functions.

[0023] The AMF 132 performs operations related to mobility management, such as but not limited to paging, non-access stratum (NAS) management, and registration process management between the UE 110 and the cellular core network 130. The AMF 132 can provide transmission for session management (SM) messages between the UE 110 and the SMF 134 and act as a transparent proxy for routing SM messages. The reference to a single AMF 132 is only for illustrative purposes, and the actual network arrangement may include any appropriate number of AMFs.

[0024] The SMF 134 performs operations related to session management (SM) (e.g., session establishment, modification, and release, including tunnel maintenance between the UPF 142 and the gNB 120A). SM may refer to the management of PDU sessions, and a PDU session or "session" may refer to a PDU connectivity service that provides or enables PDU exchange between the UE 110 and a data network. A PDU session may be established upon UE request, modified upon UE and 5GC request, and released upon UE and 5GC request.

[0025] The NEF 136 performs operations related to securely exposing the services and capabilities provided by 3GPP network functions to third parties, internal exposure / re - exposure, application functions (e.g., AF 144), edge computing or fog computing systems, etc. The NEF 136 may also receive information from other network functions (NFs) based on the exposed capabilities of those other NFs. This information may be stored at the NEF 136 as structured data, or stored at a data storage NF using a standardized interface. The stored information may then be re - exposed by the NEF 136 to other NFs and AFs, and / or used for other purposes such as analytics.

[0026] The NRF 138 performs operations related to the discovery function: receiving NF discovery requests from NF instances, and providing information on the discovered NF instances to NF instances. The NRF 138 also maintains information on available NF instances and the services they support.

[0027] The PCF 140 performs operations related to providing policy rules to control plane functions for enforcement, and may also support a unified policy framework for governing network behavior.

[0028] The UPF 142 performs operations related to mobility within and between RATs: interconnecting external PDU sessions to data networks, and supporting multi - homed PDU sessions. The UPF 142 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, legally intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), perform transport - level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.

[0029] The AF 144 performs operations related to traffic routing, accessing the NEF 136, and interacting with the policy framework for policy control. The AF may be specific to a particular application for which the 5G NR network provides services. For example, a TSN AF may include information configured for UEs in the TSN network, such as UEs performing assembly line tasks in an industrial environment.

[0030] The network arrangement 100 also includes the Internet 170, an IP Multimedia Subsystem (IMS) 150, and a network service backbone 160. The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 170 to provide multimedia services to the UE 110. The network service backbone 160 communicates directly or indirectly with the Internet 170 and the cellular core network 130. The network service backbone 160 can generally be described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a set of services that can be used to extend the functionality for the UE 110 to communicate with various networks.

[0031] Figure 2 An exemplary UE 110 is shown in accordance with various exemplary embodiments. The UE 110 will be described with reference to Figure 1 the network arrangement 100. The UE 110 can represent any electronic device and can include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 can include, for example, an audio input device, an audio output device, a battery providing a limited power source, a data acquisition device, a port for electrically connecting the UE 110 to other electronic devices, a sensor for detecting the condition of the UE 110, etc.

[0032] The processor 205 can be configured to execute multiple engines of the UE 110. For example, the engines can include a PDU session establishment engine 235 for establishing a PDU session with the 5GC. The PDU session establishment engine 235 can perform operations including transmitting the IIoT vertical / application type of the UE to the SMF, where the SMF uses the IIoT vertical / application identifier to retrieve the lifetime of the IIoT vertical / application via various CN components, which will be described in detail below.

[0033] The above engines, as application programs (e.g., programs) executed by the processor 205, are merely exemplary. The functions associated with the engines can also be represented as separate integrated components of the UE 110, or can be modular components coupled to the UE 110, e.g., integrated circuits with or without firmware. For example, an integrated circuit can include an input circuit for receiving signals and a processing circuit for processing the signals and other information. The engines can also be embodied as one application program or separate multiple application programs. Additionally, in some UEs, the functionality described for the processor 205 is shared between two or more processors such as a baseband processor and an application processor. The exemplary embodiments can be implemented in any of these or other configurations of the UE.

[0034] The memory 210 can be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 can be a hardware component configured to display data to the user, while the I / O device 220 can be a hardware component that enables the user to make inputs. The display device 215 and the I / O device 220 can be separate components or can be integrated together (such as a touch screen). The transceiver 225 can be a hardware component configured to establish connections with the LTE-RAN 120, 5G NR-RAN 122, legacy RAN 124, and WLAN 126. Thus, the transceiver 225 can operate on various different frequencies or channels (e.g., a set of contiguous frequencies).

[0035] As described above, an IIoT UE in a TSN network, such as a robot in an assembly line at a factory, can be configured with a 5G NR connection and receive services from a 5G NR RAN. When the IIoT UE requests a PDU session, e.g., transmits a PDU session establishment request, the 5GC 130 should know which application function (AF) 144, e.g., the TSN AF, to request the corresponding QoS from. To obtain this information, the 5GC 130 should be provided with the capabilities of the AF 144, e.g., which vertical or application the AF 144 serves.

[0036] Those skilled in the art will understand that the 5GC 130 can have multiple AFs 144 (as well as other described functions, e.g., SMF 134, NEF 136, NRF 138, PCF 140, UPF 142), and the operations described herein for each of these functions can be performed by one or more of these functions. Thus, the use of reference numerals (e.g., AF 144) can refer to a specific AF (e.g., the TSN AF for an application executed by the UE 110) or an AF in general. This also applies to the other functions of the 5GC 130 described herein.

[0037] In short, to enable the 5GC 130 to obtain the TSN AF 144 capabilities, the NEF 136 can be configured to request the AF 144 capabilities. The AF 144 can register its services with the NEF 136 / NRF 138, and the NEF 136 / NRF 138 can maintain a repository of AF IDs and the IIoT verticals or applications served by the AF 144. When the PCF 140 requests QoS parameters for a TSN PDU session, the NEF 136 can provide details of the corresponding TSN AF 144.

[0038] The following exemplary embodiments include various signaling diagrams that include messages exchanged between various components and / or functions. These messages may be provided with message names and / or Information Element (IE) names. It should be understood that these names are merely exemplary, and in different embodiments, messages and / or IEs that provide the same information may have different names. Those skilled in the art will understand the various functions and / or information provided in each message and may apply them to other embodiments.

[0039] Figure 3 A signaling diagram 300 is shown in which a Time-Sensitive Networking (TSN) Application Function (AF) 144 provides its capabilities to a 5GC 130 according to various exemplary embodiments. At 305, the NEF 136 / NRF 138 signals a Time-Sensitive Communication (TSC) support request to the AF 144 on the Naf interface using, for example, the Naf_TSC_Support_Request IE. The NEF 136 may use this service to query the TSC support and / or capabilities of the AF 144.

[0040] At 310, the AF 144 signals a TSC support response to the NEF 136 / NRF 138 on the Naf interface using, for example, the Naf_TSC_Support_Response. The AF 144 may use this service to provide the TSC support and / or capabilities of the AF 144 to the NEF 136 / NRF 138. When the AF 144 is a TSN AF 144, the support details may include the IIoT vertical type (e.g., future factory) and IIoT application type (e.g., robot) that it supports.

[0041] At 315, the PCF 140 signals a TSC support request to the NEF 136 / NRF 138 on the Nnef interface using, for example, the Nnef_TSC_AFSupport_Request. The PCF 140 may use this service to request TSN AF 144 information for IIoT vertical and / or application types. Although signal 315 is shown in Figure 3 as occurring after the NEF / NRF query, signal 315 may be sent before the NEF / NRF query.

[0042] At 320, the NEF 136 / NRF 138 signals a TSC support notification to the PCF 140 on the Nnef interface using, for example, the Nnef_TSC_AFSupport_Notify. The NEF 136 may use this service to notify the PCF 140 about the TSN AF 144s connected to the 5GC 130 via the NEF 136 and the IIoT support provided by each TSN AF 144.

[0043] Thus, via Figure 3 signaling, the NEF 136 / NRF 138 obtains information related to the capabilities of a specific TSN AF 144. The NEF 136 / NRF 138 can obtain this information for multiple AFs 144 and maintain a repository of AF IDs and the IIoT verticals / applications served by the AFs. Thus, when the PCF 140 requests QoS parameters for a TSC PDU session, the NEF 136 / NRF 138 can provide details of the corresponding AF 144, which will be described in further detail below with respect to Figure 6 method 600.

[0044] Figure 8 An AF service 800 is shown that can be used to provide AF capabilities from an AF 144 to the NEF 136 or NRF 138 according to various exemplary embodiments. The Naf_TSC_Support_Request service and the Naf_TSC_Support_Response service can be used to send TSN AF capabilities between the AF 144 and the NEF 136 / NRF 138.

[0045] When there is any change in the TSN AF capabilities, the AF 144 can use the Naf_TSC_Update service to update the NEF136 / NRF 138. Examples can include support for a new IioT application type. The Naf_TSC_Subscribe service and the Naf_TSC_Notify service can be used to allow the consumer NEF 136 and NRF 138 to subscribe to the capabilities of the AF 144 and be notified whenever there is a change in the capabilities.

[0046] Figure 9 A NEF service 900 is shown that can be used to provide AF capabilities from the NEF 136 to the PCF 140 according to various exemplary embodiments. The PCF 140 can use the Nnef_TSC_AFSupport_Request service and the Nnef_TSC_AFSupport_Response service to retrieve the TSN AF addresses that support IIoT applications. In the event of any change in the TSN AF addresses, the AF 144 can use the Nnef_TSC_AFSupport_Notify service to notify the PCF 140.

[0047] Figures 4a and 4b depict various ways in which the AF 144 obtains the lifetime information, which is provided to the PCF 140. Figure 4a shows a first exemplary signaling diagram 400 for providing TSC support information to the PCF 140 according to various exemplary embodiments. In this exemplary embodiment, it can be considered that the TSN AF 144 may be preloaded with the lifetime of the TSC vertical / application. For example, the 3GPP TS 22.104 standard includes various information of the TSC vertical / application (e.g., lifetime). The information of the vertical / information supported by the TSN AF 144 can be preloaded into the TSN AF 144.

[0048] In this case, as shown at 405, the PCF 140 may include a request for the IIoT vertical and / or application type in the policy authorization notification on the Npcf interface, and the policy authorization notification is, for example, transmitted to the TSN AF via the NEF / NRF in the Npcf_PolicyAuthorisation_Notify service including the 5GS bridge information and the port management information container. At 410, the AF 144 may include the lifetime along with other QoS parameters and transmit the lifetime as part of the TSN AF QoS container included in the policy authorization response on the Npcf interface, and the policy authorization response is, for example, also the Npcf_PolicyAuthorisation_Notify_Response service including the MAC address of the DS-TT port.

[0049] In other exemplary embodiments, the TSN AF 144 may request the lifetime from the TSN. For example, the TSN AF 144 may request the centralized network configuration (CNC) of the TSN to provide the lifetime as part of the QoS requirement. Figure 4b shows a second exemplary signaling diagram 450 for providing TSC support information to the PCF 140 according to various exemplary embodiments. The signaling includes a request 455 signaled by the PCF 140 to the TSN AF 144. The request 455 is similar to the above request 405. After receiving the request 455, at 460, the TSN AF 144 requests the CNC of the TSN to provide the lifetime as part of the QoS requirement. After receiving the lifetime and other QoS requirements from the CNC, the AF 144 transmits a response 465. Similarly, the response 465 is similar to the above response 410.

[0050] Figure 5FIG. 500 is an exemplary signaling diagram showing a PCF 140 obtaining a TSN AF 144 address according to various exemplary embodiments. The PCF 140 may obtain information to understand the TSN AF 144 address from which it requests QoS capability information including a time-to-live. In some exemplary embodiments, the PCF 140 may receive the address of a particular TSN AF 144 from the NEF 136 / NRF 138.

[0051] At 505, the PCF 140 transmits a TSC AF support request including the IIoT vertical / application in the 5GS bridge information. The 5GS bridge information is described in more detail below with respect to the signaling diagram of Figure 6 . Either the NEF 136 or the NRF 138 may store the TSN AF 144 information. The NEF 136 or the NRF 138 may store the TSN AF 144 information in, for example, a mapping table that stores the correlation between various TSN AFs 144 and the corresponding IIoT vertical / applications. The process for determining the TSN AF 144 information is described in further detail below with respect to the method 700 of Figure 7 . When using the NEF 136, the PCF 140 may use the Nnef_TSC_AFSupport_Request service on the Nnef interface to request the TSN AF 144 address of the IIoT vertical / application. When using the NRF 138, the PCF 140 may use the Nnrf_TSC_AFSUpport_Request service on the Nnrf interface to request the TSN AF 144 address of the IIoT vertical / application.

[0052] At 510, the NEF 136 / NRF 138 transmits a TSC AF support response that includes the AF 144 address of the TSN AF 144 connected to the 5GC 130 via the NEF 136 / NRF 138 and the IIoT support provided by each TSN AF 144. When using the NEF 136, the NEF 136 may use the Nnef_TSC_AFSUpport_Response service on the Nnef interface to provide the TSN AF 144 address to the PCF 140. When using the NRF 138, the NRF 138 may use the Nnrf_TSC_AFSUpport_Response service on the Nnrf interface to provide the TSN AF 144 address to the PCF 140.

[0053] In some exemplary embodiments, the NRF 138 may store the capability information, but the PCF 140 may request the capability information from the NEF 136. In this case, the NEF 136 may first retrieve the AF 144 address from the NRF 138 and then provide the AF 144 address to the PCF 140.

[0054] Figure 6 A signaling diagram 600 is shown for the 5GC 130 to discover the lifetime of the UE 110 in the TSN network and establish a PDU session with the UE 110 according to various exemplary embodiments. At 605, the UE+DS-TT 110 (Device Side TSN Converter) initiates a PDU session establishment request with the SMF 134 of the 5GC 130 via the AMF 132. The UE 110 may include multiple IEs in the request message, including the UE DS-TT stay time, DS-TT MAC address, port management capabilities, and IIoT vertical / application type. The UE 110 may send multiple IIoT vertical / application types in the same PDU request or may create separate PDU sessions for each IIoT application type.

[0055] At 610, the SMF 134 selects a suitable UPF 142 for the TSC session based on the parameters included in the PDU session establishment request and transmits an N4 establishment request to the UPF+NW-TT 142 (Network Side TSN Converter). At 615, the UPF+NW-TT142 allocates port numbers and transmits an N4 establishment response to the SMF 134. The response includes multiple IEs, including the port number of the DS-TT, the port number of the NW-TT, and the bridge ID.

[0056] At 620, the SMF 134 encapsulates the IEs received at 605 and 615 into "5GS bridge information" and transmits the bridge information to the PCF 140 in a request for policy and charging control (PCC) rules for setting the QoS of the session. For example, the SMF134 may use the Npcf_SMPolicyControl_Update_Request service including the 5GS bridge information and the port management information container.

[0057] At 625, the PCF 140 requests the NEF 136 / NRF 138 to provide the address of the TSN AF144 applicable to the IIoT vertical / application type. At 630, the NEF 136 / NRF 138 provides the TSN AF 144 capability information to the PCF 140. Message transmissions 625 and 635 are described in detail above with respect to Figure 5 Message transmissions 625 and 635 are described in detail above with respect to

[0058] In 635, the PCF 140 contacts the TSN AF 144 identified in 630 and requests the QoS parameters of the TSC session. For example, the PCF 140 may use the Npcf_PolicyAuthorisation_Notify service including the 5GS bridge information and the port management information container. As described above, the 5GS bridge information includes the IIoT vertical + application type, and the port management information container includes the port capabilities of the DS-TT and NW-TT.

[0059] In 640, the TSN AF 144 provides the QoS parameters of the requested TSC session as part of the TSN AF QoS container. For example, the TSN AF 144 may use the Npcf_PolicyAuthorisation_Notify service including the MAC address of the DS-TT port and the TSN AF QoS container. The container includes the time to live along with other QoS parameters. The process by which the TSN AF 144 obtains the QoS parameters and the time to live will be described in further detail below with respect to Figure 4A the signaling 400 and Figure 4B the signaling 450.

[0060] In 645, the PCF 140 creates a PCC rule and transmits the PCC rule to the SMF 134. For example, the PCF 140 may use the Npcf_SMPolicyControl_Update_Response service including the PCC rule. The PCC rule includes the time to live, the MAC address of the DS-TT port, and the QoS provided at the SDF level with 5QI. In 650, the SMF 134 provides the QoS information to the AMF 132. For example, the SMF 134 may use the Namf_Communication_N1N2MessageTransfer service including the QoS information. The QoS information includes the PDU session ID, the CN tunnel information, the QoS profile (5QI, QFI, time to live), and the SMF-originated CN auxiliary RAN parameter tuning.

[0061] In 655, the AMF 132 forwards the QoS information received in 650 to the 5G RAN 120 (e.g., gNB 120A) to set up the N3 tunnel. For example, the AMF 132 may use a PDU session resource setup request that includes parameters such as a PDU session ID, CN tunnel information, a QoS profile with a QFI (including time-to-live), a NAS PDU, and UL NG-U UP TNL information. In 660, the 5G RAN 120 transmits a PDU session resource setup response to the AMF. In 665, the AMF 132 transmits a PDU session establishment accept message to the UE 110. This message includes a QoS flow with a 5QI value and time-to-live information.

[0062] Figure 7 A method 700 for determining a scaling approach for the time-to-live of a TSN UE is shown. In 705, the 5GC 130 retrieves the specified time-to-live. Various ways in which the 5GC 130 obtains the time-to-live have been described above. In one example, the time-to-live may be 50 ms.

[0063] In 710, the 5G-RAN 120 notifies the SMF 134 via the AMF 132 whether it can or cannot meet the QoS parameters (including the time-to-live). If the 5G-RAN 120 can meet the QoS parameters, the method proceeds to 715. Otherwise, the 5GC 130 is considered unavailable and the method ends.

[0064] In 715, the SMF 134 iteratively shortens the time-to-live by a factor x. For example, the factor x may be 20%. Thus, if the specified time-to-live is 50 ms, the time-to-live will be shortened to 40 ms. The SMF 134 may continue to reduce the time-to-live by the factor x until the 5G RAN 120 can no longer meet the parameter. In 720, when the 5G RAN 120 finally cannot meet the reduced time-to-live parameter, the SMF 134 may return and continuously use the previously satisfied time-to-live parameter, e.g., the lowest time-to-live value that is known to have been satisfied by the 5G RAN 120. Thus, in this way, the 5GC 130 can iteratively set the time-to-live for a specific vertical / application performed by the UE 110.

[0065] When the 5G RAN 120 fails to meet the time-to-live parameter, the 5G RAN 120 can determine the actions to be performed. For example, the UE 110 can notify the 5G RAN 120 of the time-to-live status via an ACK message. The UE 110 can send an acknowledgment (ACK) to the gNB 120A for each DL packet received from the gNB 120A, for example. The UE 110 can include an IE related to the time-to-live in the ACK message. For example, the ACK message can include both the ACK and the time-to-live "OK" or not OK ("NOK") IE. When the gNB 120A receives the NOK along with the ACK, the gNB 120A will understand that the UE 110 has not received any commands within the time-to-live window and that the IIoT application cannot continue without any new commands. Then, the gNB 120A can notify the SMF 134 that the QoS of the TSC session cannot be guaranteed. Then, the SMF 134 can instruct the gNB 120A to perform various operations regarding the PDU session. For example, the SMF 134 can instruct the gNB 120A to release the RRC connection and the N3 tunnel in order to reconstruct the session with an updated QoS.

[0066] Those skilled in the art will understand that the above-described exemplary embodiments can be implemented in any suitable software configuration or hardware configuration or a combination thereof. An exemplary hardware platform for implementing the exemplary embodiments can include, for example, an Intel x86-based platform with a compatible operating system, Windows OS, Mac platform, and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. In other examples, the exemplary embodiments of the above methods can be embodied as a program including lines of code stored on a non-transitory computer-readable storage medium, which can be executed on a processor or a microprocessor when compiled.

[0067] Although this patent application describes various combinations of various embodiments each having different features, those skilled in the art will understand that any feature of one embodiment can be combined with the features of other embodiments in any manner not negated by the disclosure or features that are not functionally or logically inconsistent with the operation of the devices or the functions of the embodiments disclosed in the present invention.

[0068] It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of the authorized use should be clearly explained to the user.

[0069] It will be apparent to those skilled in the art that various modifications can be made to the present disclosure without departing from the spirit or scope thereof. Accordingly, the present disclosure is intended to cover modifications and variations of the present disclosure provided they are within the scope of the appended claims and their equivalents.

Claims

1. A method for time-to-live delivery, comprising: At a fifth generation core network 5GC that provides 5G radio access network RAN services to a user equipment UE in a time-sensitive communication TSC network TSN: Receiving a protocol data unit PDU session establishment request from the UE; Identifying a TSN application function AF for the PDU session; Determining quality of service QoS parameters for communication between the UE and the 5G RAN based on the identified TSN AF, the QoS parameters including a time-to-live provided by the TSN AF in a message container; And Establishing a PDU session with the UE when the QoS parameters including the time-to-live are satisfied.

2. The method according to claim 1, further comprising: Signaling a first TSC support request for an application type served by the TSN AF from one of a network exposure function NEF or a network function NF repository function NRF to the TSN AF; And Signaling a TSC support response including the application type from the TSN AF to the one of the NEF or the NRF.

3. The method according to claim 2, further comprising: Signaling a second TSC support request from a policy control function PCF to the one of the NEF or the NRF; And Signaling a second TSC support response from the one of the NEF or the NRF to the PCF.

4. The method according to claim 1, further comprising: Maintaining, by one of a network exposure function NEF or a network function NF repository function NRF, an AF identifier ID and a repository for each application type.

5. The method according to claim 4, further comprising: Signaling a TSC support request for identification of a TSN AF address from a policy control function PCF to the one of the NEF or the NRF; And Signaling a TSN AF identification from the one of the NEF or the NRF to the PCF.

6. The method according to claim 1, wherein the TSN AF is pre-loaded with the time-to-live.

7. The method according to claim 1, further comprising: Requesting a centralized network configuration CNC of the TSN to provide the time-to-live in the QoS parameters; And Receiving the time-to-live from the CNC.

8. The method according to claim 1, further comprising: Receiving the time-to-live of a TSN UE; Receiving an indication from the 5G RAN whether the 5G RAN satisfies the time-to-live.

9. The method according to claim 8, further comprising: When the 5G RAN satisfies the time-to-live, iteratively shortening the time-to-live by a factor until the 5G RAN cannot satisfy the time-to-live; And When the 5G RAN cannot satisfy the time-to-live, using the previous time-to-live that the 5G RAN could satisfy as the time-to-live.

10. The method according to claim 9, wherein the factor is 20%.

11. The method according to claim 9, wherein the UE notifies whether the 5G RAN meets the time-to-live by including OK or NOK in the ACK transmitted when receiving a downlink packet from the gNB.

12. A system for time-to-live delivery, the system comprising: One or more network components configured to provide a fifth generation core network 5GC, the 5GC providing 5G radio access network RAN services to a user equipment UE in a time-sensitive communication TSC network TSN, the one or more network components being configured to: Receive a protocol data unit PDU session establishment request from the UE; Identify a TSN application function AF for the PDU session; Determine quality of service QoS parameters for communication between the UE and the 5G RAN based on the identified TSN AF, the QoS parameters including a time-to-live provided by the TSN AF in a message container; And Establish a PDU session with the UE when the QoS parameters including the time-to-live are met.

13. The system according to claim 12, wherein the one or more network components are further configured to: Signal a first TSC support request for the application type served by the TSN AF from one of a network exposure function NEF or a network function NF repository function NRF to the TSN AF; Signal a TSC support response including the application type from the TSN AF to one of the NEF or the NRF; Signal a second TSC support request for the application type from a policy control function PCF to one of the NEF or the NRF; And Signal a second TSC support response including the application type from one of the NEF or the NRF to the PCF.

14. The system according to claim 12, wherein the one or more network components are further configured to: Maintain an AF identifier ID and a repository for each application type by one of a network exposure function NEF or a network function NF repository function NRF; Signal a TSC support request for identification of a TSN AF address related to an application type from a policy control function PCF to one of the NEF or the NRF; And Signal a TSN AF identification from the NEF or the NRF to the PCF.

15. The system according to claim 12, wherein the time-to-live of the TSN AF is one of the following: (i) pre-loaded for the application type, or (ii) received from a centralized network configuration CNC of the TSN.

16. The system according to claim 12, wherein the one or more network components are further configured to: Receive the time-to-live of the TSN UE; Receive an indication from the 5G RAN whether the 5G RAN meets the time-to-live. When the 5G RAN meets the survival time, iteratively shorten the survival time by a factor until the 5G RAN can no longer meet the survival time; and When the 5G RAN cannot meet the survival time, use the previous survival time that the 5G RAN could meet as the survival time.

17. One or more non-transitory computer-readable storage media including an instruction set, the instruction set when executed causing one or more processors to perform operations, the operations including: Receiving a protocol data unit (PDU) session establishment request from a user equipment (UE) in a time-sensitive communication (TSC) network (TSN); Identifying a TSN application function (AF) for the PDU session; Determining quality of service (QoS) parameters for communication between the UE and a 5G radio access network (RAN) based on the identified TSN AF, the QoS parameters including a survival time provided by the TSN AF in a message container; And Establishing a PDU session with the UE when the QoS parameters including the survival time are met.

18. The computer-readable storage medium according to claim 17, wherein the operations further include: Signaling a first TSC support request for an application type served by the TSN AF from one of a network exposure function (NEF) or a network function (NF) repository function (NRF) to the TSN AF; Signaling a TSC support response including the application type from the TSN AF to the one of the NEF or the NRF; Signaling a second TSC support request for the application type from a policy control function (PCF) to the one of the NEF or the NRF; And Signaling a second TSC support response from the one of the NEF or the NRF to the PCF.

19. The computer-readable storage medium according to claim 17, wherein the operations further include: Maintaining an AF identifier (ID) and a repository for each application type by one of a network exposure function (NEF) or a network function (NF) repository function (NRF); Signaling a TSC support request for identification of a TSN AF address from a policy control function (PCF) to the one of the NEF or the NRF; And Signaling a TSN AF identification from the one of the NEF or the NRF to the PCF.

20. The computer-readable storage medium according to claim 17, wherein the survival time of the TSN AF is one of the following: (i) pre-loaded for the application type, or (ii) received from a centralized network configuration (CNC) of the TSN.

Images