Patent Description:
TSN operation is the IEEE <NUM>. 1Q-defined technology for ensuring information delivery between two points in a fixed and predictable amount of time. TSN technology is an Ethernet standard, not an Internet Protocol (IP) standard. Because TSN technology is focused on time, one of the requirements for the networking devices implementing TSN technology, e.g., bridges and end devices, is to share a uniform sense of time, and Precision Time Protocol (PTP) is used to maintain a uniform sense of time. The forwarding decisions made by the TSN bridges (also referred to as Ethernet switches) use the Ethernet header contents, not the IP address. Because the payloads of the Ethernet frames can be anything (and are not limited to IP), TSN technology can be used in any environment, e.g., used to carry an industrial application payload.

When mobile and/or wireless networks are used for TSN, User Plane Function (UPF) becomes an important entity through which the TSN data has to be transmitted. 3rd Generation Partnership Project (3GPP) has proposed an architecture (<NPL>)) which enables the <NUM> core network to be used for such services.

<FIG> shows a TSN in which portions of <NUM> network <NUM> are shown as bridges (i.e., virtual TSN bridge <NUM>1010a for a protocol data unit (PDU) session <NUM>, and virtual TSN bridge <NUM>1010b for a PDU session <NUM>), controlling the factory automated system <NUM> and factory controller <NUM> for the ethernet traffic. The TSN shown in <FIG> further includes the following: policy control function (PCF) <NUM>; application function (AF) <NUM>, which acts as a TSN translator (TT) in this example; Access and Mobility Management Function (AMF) <NUM>; session management function (SMF) <NUM>; user equipment <NUM> (UE <NUM>) 1007a (acting as a TT); UE2 1007b (acting as a TT); gNB <NUM>1011a; gNB <NUM>1011b; user plane function <NUM> (UPF <NUM>) 1008a (acting as a TT); UPF <NUM>1008b (acting as a TT); TSN bridge <NUM>1009a; and TSN bridge <NUM>1009b. PCF <NUM>, AF <NUM>, AMF <NUM> and SMF <NUM> are control plane (CP) elements; the elements shown below the CP elements in <FIG> are user plane (UP) elements. The TSN shown in <FIG> is unsynchronized, i.e., the factory automated system <NUM> and the bridges (e.g., 1009a, 1009b, 1010a, 1010b) follow different time drifts. The 3GPP has defined procedures (e.g., <NPL>); <NPL>)) for making the time synchronized between the bridges and time-sensitive devices and/or networks connected via TT.

<FIG> shows the CP and UP interworking in the <NUM> network <NUM>, e.g., using interfaces N1, N2, N4, N5, N7 and N11. The TSN shown in <FIG> is unsynchronized. The TSN controller <NUM> connects to the AF <NUM> to inform about the time details and time drifts required to support the communication. The AF <NUM>, using the PCF <NUM>, interfaces with the SMF <NUM> to installs rules at the UPF <NUM> with the time-related information, so that the UP can be synchronized with the TSN.

<FIG> shows the call flow for SMF <NUM> provisioning the relevant rules at the UPF <NUM> for clock synchronization and TT-port creation, e.g., as per 3GPP protocols defined in <NPL>) and <NPL>). In block <NUM>, packet forwarding control protocol (PFCP) association setup request is sent from SMF <NUM> to UPF <NUM>, which Setup Request includes clock drift control information, e.g., time domain number (precision time protocol (PTP) domain number), and time offset threshold. In block <NUM>, PFCP association setup response is sent from UPF <NUM> to SMF <NUM>. In block <NUM>, PFCP session creation request is sent from SMF <NUM> to UPF <NUM>, which creation request includes "create bridge" information for time sensitive connection (TSC). In block <NUM>, PFCP session creation response is sent from UPF <NUM> to SMF <NUM>, which creation response includes created bridge information for TSC, e.g., device-side TSN translator (DS-TT) port number; network-side TSN translator (NW-TT) port number; and bridge ID.

The 3GPP has also defined TSN port management procedures, e.g., the CP can ask for the TSN port information, using the PFCP modification procedures. <FIG> shows one such call flow, e.g., SMF <NUM> doing the port management for the TSN bridge, based on 3GPP specification (<NPL>)). In block <NUM>, PFCP session modification request is sent from SMF <NUM> to UPF <NUM>, which modification request includes port management information (request for the TSN port information) for TSC. In block <NUM>, PFCP session modification response is sent from UPF <NUM> to SMF <NUM>, which modification response includes port management information (requested TSN port information) for TSC and port management information container for TSC.

The ethernet connections in a TSN may fluctuate (i.e., the connection goes down and subsequently comes back up) at certain times between the UPF (TT) and the TSN Controller, in which cases the UP connection between the UPF (TT) and TSN will be subjected to a reconnection attempt involving a reset of the UP connection. In the above scenario involving a reset of the UP connection, there are times when the data traffic stops flowing in the UP (e.g., during a reset and/or during down time), but there is no audit mechanism at the UPF that can notify the CP about the data traffic stoppage. In addition, the UPF (TT) may trigger high availability (HA) procedures involving implementation of a failover, i.e., automatically switch to a backup system component in case of a failure of a primary system component. <FIG> shows one such example in which the connection is switched from UPF <NUM>5008a (TT) to UPF <NUM>5008b (backup TT). The TSN shown in <FIG> is synchronized.

In both of the above situations (data traffic stoppage associated with a reset of the UP connection, and failover), miscalculation of "survival time" occurs. As defined in <NPL>), "survival time" refers to the time period that a communication service may continue without meeting an application's requirement before the communication service is deemed to be in an unavailable state. In other words, the communication service is considered unavailable to the application when an expected message is not received by the application after application's survival time expires.

Document 3GPP: "<NPL>, defines the Stage <NUM> procedures and Network Function services for the <NUM> system architecture which is described in the TS <NUM> and for the policy and charging control framework which is described in TS <NUM>. however, the above mentioned issues are not solved.

Accordingly, there is a need for a method for ensuring correct calculation of survival time, e.g., in scenarios involving a failover and/or data traffic stoppage due to reset of UP connection.

The present invention relates to a method for time sensitive network (TSN) operation according to claim <NUM>.

The following aspects summarize the present disclosure and are not necessarily part of the claimed invention. According to an example according to the present disclosure, a method for time sensitive network (TSN) operation includes: in the case of data traffic stoppage in a communication channel of TSN due to at least one of down time of a user plane (UP) connection and a reset of the UP connection, performing the following: generating, by a user plane function (UPF), an audit report about the at least one of the down time and the reset; sending, by the UPF, the audit report to a first element in control plane (CP), without waiting for communication from the CP; and determining, by one of the first element or a second element in the CP, survival time of the communication channel. The audit report is sent along with a report type indicating the down time of the UP connection due to connection fluctuation or a switch-over of the UP connection from a primary UPF to a back-up UPF.

According to an example according to the present disclosure, the audit report is sent along with a report type indicating one of i) down time of the UP connection due to connection fluctuation, or ii) down time of the UP connection due to a switch-over of the UP connection from a primary user plane function (UPF) to a back-up UPF.

According to an example according to the present disclosure, in the case the down time of the UP connection is due to the switch-over of the UP connection from the primary user plane function (UPF) to the back-up UPF, the audit report is sent by the back-up UPF.

According to an example according to the present disclosure, in the case the report type indicates down time of the UP connection due to connection fluctuation, the audit report includes at least one of the following information: operation status, IP address: display name; interface name; virtual routing and forwards (VRF); virtual local area network (VLAN); physical address; protocol type; start time for TSN session; previous down time; and duration of down time.

According to an example according to the present disclosure, in the case the report type indicates down time of the UP connection due to the switch-over of the UP connection from the primary user plane function (UPF) to the back-up UPF, the audit report includes at least one of the following information: operation status, IP address: display name; interface name; virtual routing and forwards (VRF); virtual local area network (VLAN); old physical address; new physical address; protocol type; start time for TSN session; previous down time; and duration of down time.

In an example embodiment of a method according to the present disclosure, in the event of experiencing data traffic stoppage in TSN due to down time and/or a reset of the UP connection, the UP generates and sends an audit report to the CP (e.g., SMF <NUM> in the CP), without waiting for any communication from the CP, as shown in <FIG>. In block <NUM> in <FIG>, UPF <NUM> sends to SMF <NUM> a "PFCP Session Report Request" message including i) Report Type = TSN, and ii) an Audit Report having specified contents. The contents of an Audit Report can include the following fields:.

As an example, the following could be included in the Audit Report:.

Next, as shown in block <NUM> in <FIG>, SMF <NUM> sends to PCF <NUM> an update, NPCF Session Management Policy Control Update (Npcf_SMPolicyControl_Update), which message includes i) Report Type = TSN Bridge Information (TSNBridgeInfo), and ii) the Audit Report received from UPF <NUM>. In block <NUM>, PCF <NUM> sends to AF <NUM> a Network Application Function (NAF) Event Exposure message including: i) Events Subscription = TSN, and ii) the Audit Report received from SMF <NUM>. In block <NUM>, AF <NUM> sends to TSN controller <NUM> a Hypertext Transfer Protocol Secure (HTTPS) POST request message including i) Report Type = TSN, and ii) the Audit Report received from PCF <NUM>. The survival time can be computed at SMF <NUM> or AF <NUM>.

In the event of a switch-over of the connection from UPF (TT) to the UPF (Backup TT), the ethernet ports (DS-TT and NW-TT) created at the UPF(TT) are also switched, which results in a temporary pause of the connection with the TSN System. Because the CP is unaware of the connection reset, resulting loss of synchronization occurs among the TSN devices. In order to overcome this problem, in an example embodiment of a method according to the present disclosure, in the event of a switch-over, the UP notifies the CP about the HA action (i.e., the switch-over of the connection), so that the AF (working as TT) can inform the TSN controller about the time gaps. In block <NUM> in <FIG>, UPF <NUM> (which corresponds to UPF <NUM> serving as the back-up TT shown in <FIG>) sends to SMF <NUM> a "PFCP Session Report Request" including i) Report Type = HA, and ii) an Audit Report having specified contents. The contents of an Audit Report can include the following fields:.

Next, as shown in block <NUM> in <FIG>, SMF <NUM> sends to PCF <NUM> an update, NPCF Session Management Policy Control Update (Npcf_SMPolicyControl_Update), which message includes i) Report Type = TSN Bridge Information HA (TSNBridgeInfoHA), and ii) the Audit Report received from UPF <NUM>. In block <NUM>, PCF <NUM> sends to AF <NUM> a Network Application Function (NAF) Event Exposure message including: i) Events Subscription = TSNHA, and ii) the Audit Report received from SMF <NUM>. In block <NUM>, AF <NUM> sends to TSN controller <NUM> a Hypertext Transfer Protocol Secure (HTTPS) POST request message including i) Report Type = HA, and ii) the Audit Report received from PCF <NUM>. The survival time can be computed at SMF <NUM> or AF <NUM>.

The example embodiments of the method according to the present disclosure provide the advantage of enabling the CP to be informed of TSN data traffic stoppage, e.g., due to down time and/or a reset of the UP connection. By having the UP notify the SMF in the CP about TSN data-traffic-stoppage events, the network operator is able to obtain the correct timings during which the UP was unable to handle the data traffic on the communication channel, i.e., the path between the Device-Side TSN Translator (DS-TT), e.g., UE, and Network-Side TSN Translator (NW-TT), e.g., UPF. The notification from the UP enables correct computing of the survival time of the communication channel.

Although the example method according to the present disclosure has been described in the context of <NUM> network, the method according to the present disclosure is not limited to <NUM>, e.g., the method can be applied to <NUM> network.

Claim 1:
A method for time sensitive network, TSN, operation, comprising:
in the case of data traffic stoppage in a communication channel of TSN due to at least one of down time of a user plane, UP, connection and a reset of the UP connection, performing the following:
generating, by a user plane function, UPF, an audit report about the at least one of the down time and the reset;
sending, by the UPF, the audit report to a first element (<NUM>) in control plane, CP, without waiting for any communication from the CP,
characterized in that:
the first element (<NUM>) in the CP is a session management function, SMF;
a second element (<NUM>) in the CP is an application function, AF;
the method further comprising the steps of:
sending the audit report along with a report type indicating one of i) down time of the UP connection due to connection fluctuation, or ii) down time of the UP connection due to a switch-over of the UP connection from a primary user plane function, UPF, (<NUM>) to a back-up UPF; and
determining, by one of the first element or the second element (<NUM>) in the CP whether the down time of the UP connection exceeds a survival time of the communication channel,
wherein:
in the case the down time of the UP connection is due to the switch-over of the UP connection from the primary user plane function, UPF, to the back-up UPF, the audit report is sent by the back-up UPF;
in the case the report type indicates down time of the UP connection due to connection fluctuation, the audit report includes at least one of the following information: operation status, IP address: display name; interface name; virtual routing and forwards, VRF; virtual local area network, VLAN; physical address; protocol type; start time for TSN session; previous down time; and duration of down time;
in the case the report type indicates down time of the UP connection due to the switch-over of the UP connection from the primary user plane function, UPF, to the back-up UPF, the audit report includes at least one of the following information: operation status, IP address: display name; interface name; virtual routing and forwards, VRF; virtual local area network, VLAN; old physical address; new physical address; protocol type; start time for TSN session; previous down time; and duration of down time.