Patent Description:
The following abbreviations are herewith defined, at least some of which are referred to within the following description: Third Generation Partnership Project ("<NUM> GPP"), Fifth Generation Core Network ("5CG"), Fifth Generation System ("5GS"), Fifth Generation QoS Identifiers ("5QI"), Fifth Generation QoS Class Identifier ("5Qis"), Authentication, Authorization and Accounting ("AAA"), Access and Mobility Management Function ("AMF"), Access Stratum ("AS"), Positive-Acknowledgment ("ACK"), Application Function ("AF"), Application Programming Interface ("API"), Automated Guided Vehicle ("AGV"), Base Station ("BS"), Category of Requirements ("CoR"), Centralized Network Channel State Information ("CSI"), Configuration ("CNC"), Control Element ("CE"), Cooperating merging ("CM"), Cooperative Overtaking ("CO"), Cooperating Transition of Control ("CToC"), Core Network ("CN"), Downlink ("DL"), Discontinuous Transmission ("DTX"), Evolved Node-B ("eNB"), Evolved Packet Core ("EPC"), Evolved Packet System ("EPS"), Evolved UMTS Terrestrial Radio Access ("E-UTRA"), Evolved UMTS Terrestrial Radio Access Network ("E-UTRAN"), European Telecommunications Standards Institute ("ETSI"), Factory of the Future ("FF"), FF Application Client ("FFAC"), FF Application Enabler Client ("FFAE-C"), FF Application Enabler Server ("FFAE-S"), General Packet Radio Service ("GPRS"), Generic Public Service Identifier ("GPSI"), Global System for Mobile Communications ("GSM"), Hybrid Automatic Repeat Request ("HARQ"), Home Subscriber Server ("HSS"), Information Element ("IE"), Internet-of-Things ("IoT"), International Electrotechnical Commission ("IEC"), International Mobile Equipment Identity ("IMEI"), Key Performance Indicator ("KPI"), Level of Automation ("LoA"), Long Term Evolution ("LTE"), Mobility Management ("MM"), Mobility Management Entity ("MME"), Negative-Acknowledgment ("NACK") or ("NAK"), New Generation (<NUM>) Node-B ("gNB"), New Generation Radio Access Network ("NG-RAN", a RAN used for 5GS networks), New Radio ("NR", a <NUM> radio access technology; also referred to as "<NUM> NR"), Non-Access Stratum ("NAS"), Network Resource 'x' ("NRx"), Network Slice Selection Assistance Information ("NSSAI"), Packet Data Unit ("PDU", used in connection with 'PDU Session'), Packet Error Rate ("PER"), PC5 5QI ("PQI"), Permanent Equipment Identifier ("PEI"), Per-Stream Filtering and Policing ("PSFP"), Policy Control Function ("PCF"), Policy and Charging Control ("PCC"), Proximity Service ("ProSe"), Public Land Mobile Network ("PLMN"), Quality of Service ("QoS"), Quality of Experience ("QoE"), Radio Access Network ("RAN"), Radio Link Management ("RLM"), Radio Resource Management ("RRM"), Receive ("Rx"), Road Side Unit ("RSU"), Round Trip Time ("RTT"), Service Enabler Architecture Layer ("SEAL"), Session Management ("SM"), Session Management Function ("SMF"), Service Provider ("SP"), Single Network Slice Selection Assistance Information ("S-NSSAI"), Transport Block ("TB"), Time Sensitive Communications ("TSC"), TSC Assistance Information ("TAI"), Time Sensitive Networking ("TSN"), TSN Application Server ("TSN AS"), Device-Side TSN Translator ("DS-TT"), Network-Side TSN Translator ("NW-TT"), Tracking Area ("TA"), Transmit ("Tx"), Vehicle-to-Everything ("V2X"), Vehicle-to-Infrastructure ("V21"), Vehicle-to-Vehicle ("V2V"), Vehicle-to-Relay ("V2R"), V2X Application Enabler ("VAE"), Unified Data Management ("UDM"), User Data Repository ("UDR"), User Entity/Equipment (Mobile Terminal) ("UE"), Uplink ("UL"), User Plane ("UP"), User Plane Function ("UPF"), Universal Mobile Telecommunications System ("UMTS"), UMTS Terrestrial Radio Access ("UTRA"), UMTS Terrestrial Radio Access Network ("UTRAN"), User Service Description ("USD"), and Worldwide Interoperability for Microwave Access ("WiMAX"). As used herein, "HARQ-ACK" may represent collectively the Positive Acknowledge ("ACK") and the Negative Acknowledge ("NACK") and Discontinuous Transmission ("DTX"). ACK means that a TB is correctly received while NACK (or NAK) means a TB is erroneously received. DTX means that no TB was detected.

IEEE TSN is a set of standards to define mechanisms for the time-sensitive (i.e., deterministic) transmission of data over Ethernet networks. The <NUM> System is extended to support Time sensitive communication as defined in IEEE P802.

<NPL>" and describes application architecture aspects to support Factories of the Future in <NUM> network, and corresponding architectural solutions.

Claim <NUM> defines a method performed by an application enabling server, claim <NUM> defines an application enabling server, claim <NUM> defines a method performed by a user equipment apparatus, and claim <NUM> defines a user equipment apparatus. In the following, any method and/or apparatus referred to as embodiments but nevertheless do not fall within the scope of the appended claims are to be understood as examples helpful in understanding the invention.

Disclosed are procedures for policy modification in a TSN system. One method of a server, e.g., for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more UEs, includes receiving a trigger event, the trigger event indicating a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. The method includes determining a first policy parameter for at least one UE and requesting a policy modification from a TSN system, said request including the first policy parameter. Here, the first policy parameter comprising at least one of: a first service parameter, a first QoS parameter and a first port management parameter. The method includes receiving a second policy parameter based on the first policy parameter from the TSN system and transmitting the second policy parameter to at least one network entity and/or the at least one UE.

One method of a UE, e.g., for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more UEs in an operation phase, includes detecting a trigger event, the trigger event indicating a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. The method includes reporting the trigger event to an application enabler server and receiving a policy parameter based on the first policy parameter from the TSN system, the policy parameter comprising at least one of: a first service parameter, a first QoS parameter and a first port management parameter. The method includes updating a TSN policy based on the received policy parameter.

Code for carrying out operations for embodiments may be any number of lines and may be written in any combination of one or more programming languages including an object-oriented programming language such as Python, Ruby, Java, Smalltalk, C++, or the like, and conventional procedural programming languages, such as the "C" programming language, or the like, and/or machine languages such as assembly languages.

As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof" includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C or a combination of A, B and C.

The code may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart diagrams and/or block diagrams.

Generally, the present disclosure describes systems, methods, and apparatus for supporting the monitoring of application TSN QoS parameters and negotiating a change of an application parameter related to the TSN service operation and/or performance (in particular a change of a user equipment QoS parameter, a radio parameter, a user equipment context) to be mapped to an updated traffic policy and/or network policy and/or QoS policy by an external (i.e., 3rd-party) application, such as an application enabler server and client, e.g., for Factory-of-the Future. Negotiating a change of wireless radio and/or user equipment QoS/context parameter to be mapped to an updated policy may take the form of <NUM>) adaptation of service requirements (e.g., survival time), <NUM>) adaptation of network requirements (e.g., TSN QoS) or <NUM>) adaptation of port management policies (DS-TT, NW-TT policies).

The high-level problem to be solved by this disclosure is how to dynamically translate and negotiate the change of one or more application parameters related to the TSN service operation and/or performance, to network QoS and traffic policies to ensure meeting the TSC requirements, subject to changes at the wireless network conditions and/or UE context.

Time-Sensitive Networking (TSN) is a key functionality of industrial networks in factories of the future. Such industrial networks are usually ethernet-based IEEE <NUM>-based networks. <NUM> could provide advantages for cyber-physical control applications with respect to flexibility and mobility due to their radio access network with low latency, high availability, high reliability, and time synchronization capabilities over wireless links. On the other hand, IEEE-<NUM>-based TSN networks provide advantages with wired connectivity for cyber-physical control applications, especially for demanding real-time control applications and periodic-deterministic communication, also with very high availability requirements. <NUM> together with IEEE <NUM>-based TSN networks, can provide a holistic solution for use cases in factories of the future. Thus, an integration of <NUM> networks and IEEE <NUM>-based TSN networks may be necessary.

TSN was developed to enable deterministic communication on standard Ethernet. Deterministic communication is important to multiple industries (for example, aerospace, automotive, manufacturing, transportation, and utilities). "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. TSN was developed to provide a way to make sure information can travel from point A to point B in a fixed and predictable amount of time. Being predictable enables increased efficiency.

When integrating <NUM> networks and IEEE <NUM>-based TSN networks, one key challenge is how to translate the TSN traffic policies to application QoS parameters (as identified in 3GPP TS <NUM>); and subsequently application QoS parameters to network QoS parameters (e.g., 5QIs) to meet the overall objective of guaranteeing meeting the tight deterministic Time Sensitive Communications ("TSC") service Key Performance Indicators ("KPIs"). More specifically in TS <NUM> the following procedure is supported for periodic deterministic traffic:.

At step <NUM>, the TSN traffic pattern policies are set by the TSN system, using Per-Stream Filtering and Policing (PSFP) policies. PSFP is used to filter frames at the ingress port that do not meet the configured policies. Different types of policies may apply as in IEEE <NUM>. 1Q, such as: A) Time-based policing: This allows detection of incoming frames during periods when the stream gate is in the closed state; B) Rate-based policing: This is supported by the flow meter instances; and C) Burst-based policing. This is supported by the flow meter instances, indicating the length of supported burst (back-to back sending of streams).

At step <NUM>, the TSN AF is responsible for obtaining PSFP parameters and use them to calculate traffic pattern parameters (such as burst arrival time with reference to the ingress port, periodicity, and flow direction).

At the step <NUM>, the TSN AF is also responsible of forwarding these parameters in TSN QoS container to the SMF (via PCF). At the step <NUM>, the SMF will bind PCC rules with a TSN QoS Container, e.g., as described in clause <NUM>. <NUM> of TS <NUM>. At the step <NUM>, the SMF derives TSCAI on a per QoS Flow basis and send it to the RAN.

For some parameters defined in 3GPP TS <NUM>, e.g., survival time, the mapping of application QoS to network QoS parameters (steps <NUM> and <NUM> above) is not straightforward. Also, how the TSN AF selects the mapping of traffic to QoS at 5GS is left to implementation. Furthermore, there are use cases (e.g., mobile robots), where due to the mobility requirement, some negotiation of the parameters may be needed between the TSN system and the 5GS so as to prevent service discontinuity.

The proper integration of <NUM> networks and TSN networks can also require the acquisition and configuration of service requirements that may not be yet in the scope of the current <NUM> QoS framework. In particular:.

Survival time (e.g., as specified in 3GPP TS <NUM>) which reflects an application's resilience to consecutive transmission failures of the application data. The survival time which is seen as an application QoS attribute (i.e., service performance requirement, as specified in TS <NUM>), should be taken into account when the TSN system provides/adapts the service requirements to the 5GC or the UE, since this may have impact on the network QoS configuration. The survival time indicates to the communication service the time available to recover from failure. This parameter is thus tightly related to maintainability.

Transfer interval target value (for periodic deterministic traffic): time difference between two consecutive transfers of application data from an application via the service interface to 3GPP system. This definition is based on subclause <NUM>. <NUM> in IEC <NUM>-<NUM>.

TSC service area: geographic region where a 3GPP communication service is accessible. For some services can be in Length x Width x Height format.

UE speed and/or mobility: UEs may be stationary or mobile (e.g., mobile robots). The UE speed requirements are shown in TS <NUM>. The speed requirement may be adjustable (up to a maximum threshold) and it may affect the network QoS parameter setting.

The rationale behind investigating this topic is the fact that when integrating with 5GS, due to the nature of the wireless part of the 5GS (RAN, wireless BH), some impact on the fulfilment of the deterministic communication requirements (due to the fluctuations of performance of the wireless access) may be seen; hence the wireless access could be seen as the bottleneck when using 5GS as a bridge.

However, the <NUM> System specific procedures in 5GC and RAN, wireless communication links, etc. remain hidden from the TSN network, and 5GS is seen as TSN Bridge. At the same time, the service communication parameters are closely coupled with the TSN service performance and need to be taken into account when configuring the QoS parameters.

To this end, the dynamic interaction between the 5GS operator and TSN system, for guaranteeing, by negotiating, the TSC service KPI (or application QoS parameters), subject to network/radio conditions changes, is needed to be discussed as part of the application layer on top of 5GS, to allow the translation of 5GS bridge parameters to TSN policies, while hiding the 5GS topology to TSN system.

The problem to be solved is how to enable the TSN system to dynamically interact with one or more underlying networks / 5GS bridges for negotiating the change of one or more application parameters related to the TSN service operation and/or performance and their mapping to network QoS and traffic policy parameters.

IEEE TSN is a set of standards to define mechanisms for the time-sensitive (i.e., deterministic) transmission of data over Ethernet networks. The <NUM> System is extended to support Time sensitive communication as defined in IEEE P802.1Qcc.

3GPP TS <NUM> describes <NUM> System features that support Time Sensitive Communications (TSC) and allow the <NUM> System to be integrated transparently as a bridge in an IEEE TSN network. The <NUM> System is integrated with the external network as a TSN bridge. This "logical" TSN bridge includes TSN Translator functionality for interoperation between TSN System and <NUM> System both for user plane and control plane. 5GS TSN translator functionality consists of Device-side TSN translator (DS-TT) and Network-side TSN translator (NW-TT).

<NUM> System specific procedures in 5GC and RAN, wireless communication links, etc. remain hidden from the TSN network. To achieve such transparency to the TSN network and the 5GS to appear as any other TSN Bridge, the 5GS provides TSN ingress and egress ports via DS-TT and NW-TT. DS-TT optionally supports link layer connectivity discovery and reporting as defined in IEEE <NUM>. 1AB for discovery of Ethernet devices attached to DS-TT. NW-TT supports link layer connectivity discovery and reporting as defined in IEEE <NUM>. 1AB for discovery of Ethernet devices attached to NW-TT.

5GS supports both periodic and aperiodic deterministic traffic. For periodic traffic, a periodic deterministic QoS feature (TS <NUM>, clause <NUM>. 1a) allows the 5GS to support periodic deterministic communication where the traffic characteristics are known a-priori, and a schedule for transmission from the UE to a downstream node, or from the UPF to an upstream node is provided via external protocols outside the scope of 3GPP (e.g., IEEE TSN).

The features include the following: A) Providing TSC Assistance Information (TSCAI) that describe TSC flow traffic patterns at the 5GS egress interfaces; and B) Support for hold-and-forward buffering or stop-and-buffering mechanism in the TSN Translator on the UE side and UPF side to de-jitter flows that have traversed the <NUM> System. A "TSC flow," as used herein, describes the time-critical communication between end devices. Each flow has strict time requirements that the networking devices honor. Each TSN flow is uniquely identified by the network devices.

Application architecture aspects to support Factories of the Future in <NUM> network, and corresponding architectural solutions are specified in 3GPP TR <NUM>. The study includes identifying architecture requirements that are necessary to ensure efficient use and deployment of application layer support for Factories of the Future in <NUM> network. As part of this study, one identified Key Issue is the one related to TSN Supporting (KI #<NUM>) which investigates the issue on how to enable the translation of TSN application QoS requirements (e.g., survival time) to network QoS parameters, and what would be the impact on 5GS for QoS enforcement.

To this end, a novel functionality is disclosed at a middleware layer (can be seen as application enabling function on top of the communication part) for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more user equipment.

In various embodiments, the middleware layer supports the adaptation of service requirements for the TSC and/or the port management parameters for the 5GS bridge and the determination of policies, in order to cope with the QoS/radio related dynamic changes (e.g., congestion, QoS downgrade).

In various embodiments, the middleware layer supports the negotiation of the determined policies between a middleware functionality and the TSN system, without involving the 5GS (which is seen as a bridge).

In various embodiments, the middleware layer supports the interactions with the application enabler client at the Device side for monitoring TSC QoS and/or service-related parameters and configuring the application of the device with new policies to be dynamically applied.

<FIG> depicts a wireless communication system <NUM> for policy modification in a TSN system, according to embodiments of the disclosure. In one embodiment, the wireless communication system <NUM> includes at least one remote unit <NUM>, a radio access network ("RAN") <NUM>, and a mobile core network <NUM>. The RAN <NUM> and the mobile core network <NUM> form a mobile communication network. The RAN <NUM> may be composed of a base unit <NUM> with which the remote unit <NUM> communicates using wireless communication links <NUM>. Even though a specific number of remote units <NUM>, base units <NUM>, wireless communication links <NUM>, RANs <NUM>, and mobile core networks <NUM> are depicted in <FIG>, one of skill in the art will recognize that any number of remote units <NUM>, base units <NUM>, wireless communication links <NUM>, RANs <NUM>, and mobile core networks <NUM> may be included in the wireless communication system <NUM>.

In one implementation, the RAN <NUM> is compliant with the <NUM> system specified in the 3GPP specifications. In another implementation, the RAN <NUM> is compliant with the LTE system specified in the 3GPP specifications. More generally, however, the wireless communication system <NUM> may implement some other open or proprietary communication network, for example WiMAX, among other networks.

In one embodiment, the remote units <NUM> may include computing devices, such as desktop computers, laptop computers, personal digital assistants ("PDAs"), tablet computers, smart phones, smart televisions (e.g., televisions connected to the Internet), smart appliances (e.g., appliances connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), vehicle on-board computers, network devices (e.g., routers, switches, modems), or the like. Moreover, the remote units <NUM> may be referred to as the UEs, subscriber units, mobiles, mobile stations, users, terminals, mobile terminals, fixed terminals, subscriber stations, user terminals, wireless transmit/receive unit ("WTRU"), a device, or by other terminology used in the art.

The remote units <NUM> may communicate directly with one or more of the base units <NUM> in the RAN <NUM> via uplink ("UL") and downlink ("DL") communication signals. Furthermore, the UL and DL communication signals may be carried over the wireless communication links <NUM>. Here, the RAN <NUM> is an intermediate network that provides the remote units <NUM> with access to the mobile core network <NUM>.

In some embodiments, the remote units <NUM> communicate with a communication host (e.g., application server) via a network connection with the mobile core network <NUM>. For example, an application <NUM> (e.g., web browser, media client, telephone/VoIP application) in a remote unit <NUM> may trigger the remote unit <NUM> to establish a PDU session (or other data connection) with the mobile core network <NUM> via the RAN <NUM>. The mobile core network <NUM> then relays traffic between the remote unit <NUM> and the application server using the PDU session. Note that the remote unit <NUM> may establish one or more PDU sessions (or other data connections) with the mobile core network <NUM>. As such, the remote unit <NUM> may concurrently have multiple active PDU session with may be for the same or different packet data networks. In various embodiments, the remote unit <NUM> establishes a PDU session with a TSN application server in the service provider domain <NUM> for TSC service.

The base units <NUM> may be distributed over a geographic region. In certain embodiments, a base unit <NUM> may also be referred to as an access terminal, an access point, a base, a base station, a Node-B, an eNB, a gNB, a Home Node-B, a relay node, or by any other terminology used in the art. The base units <NUM> are generally part of a radio access network ("RAN"), such as the RAN <NUM>, that may include one or more controllers communicably coupled to one or more corresponding base units <NUM>. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The base units <NUM> connect to the mobile core network <NUM> via the RAN <NUM>.

The base units <NUM> may serve a number of remote units <NUM> within a serving area, for example, a cell or a cell sector, via a wireless communication link <NUM>. The base units <NUM> may communicate directly with one or more of the remote units <NUM> via communication signals. Generally, the base units <NUM> transmit DL communication signals to serve the remote units <NUM> in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the wireless communication links <NUM>. The wireless communication links <NUM> may be any suitable carrier in licensed or unlicensed radio spectrum. The wireless communication links <NUM> facilitate communication between one or more of the remote units <NUM> and/or one or more of the base units <NUM>.

In one embodiment, the mobile core network <NUM> is a <NUM> core ("5GC") or the evolved packet core ("EPC"), which may be coupled to a packet data network <NUM>, like the Internet and private data networks, among other data networks. A remote unit <NUM> may have a subscription or other account with the mobile core network <NUM>. Each mobile core network <NUM> belongs to a single public land mobile network ("PLMN").

The mobile core network <NUM> includes several network functions ("NFs"). As depicted, the mobile core network <NUM> includes multiple user plane functions ("UPFs") <NUM>. The mobile core network <NUM> also includes multiple control plane functions including, but not limited to, an Access and Mobility Management Function ("AMF") <NUM> that serves the RAN <NUM>, a Session Management Function ("SMF") <NUM>, a Policy Control Function ("PCF") <NUM>, and a Unified Data Management function ("UDM") <NUM>. In certain embodiments, the mobile core network <NUM> may also include an Authentication Server Function ("AUSF"), a Network Repository Function ("NRF") (used by the various NFs to discover and communicate with each other over APIs), or other NFs defined for the 5GC.

In various embodiments, the mobile core network <NUM> supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network <NUM> optimized for a certain traffic type or communication service. A network slice instance may be identified by a S-NSSAI, while a set of network slices for which the remote unit <NUM> is authorized to use is identified by NSSAI. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF <NUM> and UPF <NUM>. In some embodiments, the different network slices may share some common network functions, such as the AMF <NUM>. The different network slices are not shown in <FIG> for ease of illustration, but their support is assumed.

Although specific numbers and types of network functions are depicted in <FIG>, one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network <NUM>. Moreover, where the mobile core network <NUM> is an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, and the like. In certain embodiments, the mobile core network <NUM> may include a AAA server.

The service provider domain <NUM> includes network-side functions of the TSN system <NUM>. In some embodiments, the TSN AS <NUM> is application specific server which may reside at the TSN System <NUM>. In certain embodiments, the TSN AS <NUM> may be a FF application specific server that interacts with the FF Application Client ("FFAC") <NUM>.

As depicted, the wireless communication system <NUM> may include an FF Application Enabler Server ("FFAE-S") <NUM>, a TSN AF <NUM>, and a NW-TT <NUM>. In some embodiments, the FFAE-S <NUM> includes the TSN AF <NUM>. In other embodiments, the TSN AF may be part of the mobile core network <NUM>. The TSN AF <NUM> refers to the AF which interacts with the <NUM> core and may interact with e.g., the PCF <NUM> and/or NEF <NUM>.

In some embodiments, the TSN AF <NUM> is part of the mobile core network <NUM>. In other embodiments, the TSN AF <NUM> may be part of service provider domain <NUM>. Similarly, the NW-TT <NUM> may be a part of the mobile core network <NUM> or a part of the service provider domain. The NW-TT <NUM> provides the user plane interactions between UPF <NUM> and the TSN system <NUM>, whereas the TSN AF <NUM> handles the control plane interactions between control plane of the mobile core network <NUM> and the TSN system <NUM>.

While <FIG> depicts components of a <NUM> RAN and a <NUM> core network, the described embodiments for policy modification in a TSN system apply to other types of communication networks and RATs, including IEEE <NUM> variants, GSM, GPRS, UMTS, LTE variants, CDMA <NUM>, Bluetooth, ZigBee, Sigfoxx, and the like. For example, in an LTE variant involving an EPC, the AMF <NUM> may be mapped to an MME, the SMF mapped to a control plane portion of a PGW and/or to an MME, the UPF map to an SGW and a user plane portion of the PGW, the UDM/UDR maps to an HSS, etc..

TSN device <NUM> includes a remote unit <NUM>, an FF Application Client ("FFAC") <NUM>, a Device-Side TSN Translator ("DS-TT") <NUM>, and an FF Application Enabler Client ("FFAE-C") <NUM>. The TSN device <NUM> uses the RAN <NUM> and mobile core network <NUM> to connect to the network elements of the TSN system <NUM>.

In various embodiments, the FFAC <NUM> interacts with a FF application specific server (e.g., the TSN AS <NUM>) for TSN service operation. The DS-TT <NUM> has a network-side counterpart, the NW-TT <NUM>, and provides TSN Translator functionality at the TSN device <NUM> for interoperation between TSN System <NUM> and <NUM> System (i.e., RAN <NUM> and mobile core network <NUM>) for the user plane.

The FF Application Enabler Client ("FFAE-C") <NUM> is at a FF middleware layer (i.e., an application-enabling function), which monitors the application TSN QoS parameters and negotiates the service and/or QoS requirements (and/or port management policies) for adapting the TSN service operation. The FFAE-C <NUM> interacts with a FFAE-S <NUM>. In certain embodiments, the FFAE-C(s) <NUM> and FFAE-S <NUM> form a distributed TSN middleware.

In the following descriptions, the term gNB is used for the base station but it is replaceable by any other radio access node, e.g., BS, eNB, gNB, AP, NR, etc. Further the operations are described mainly in the context of <NUM> NR. However, the proposed solutions/methods are also equally applicable to other mobile communication systems supporting FF bridging.

<FIG> depicts a network architecture <NUM> for policy modification in a TSN system, according embodiments of the disclosure. The network architecture <NUM> includes a TSN system <NUM> including a TSN device <NUM>, at least one PLMN <NUM>, a NW-TT <NUM>, a FFAE-S <NUM> and TSN AF <NUM>. Note here that the TSN device <NUM> includes a FFAE-C <NUM>, a DS-TT <NUM> and a 3GPP UE <NUM>. Additionally, the 3GPP UE <NUM> allows the TSN device <NUM> to communicate with a TSN/FF application-specific server via a first 5GS bridge <NUM> and/or a second 5GC bridge <NUM> supported by the PLMN(s) <NUM>. Note that the TSN AF <NUM> may be part of the 5GS bridge too (e.g., the TSN AF <NUM> handles the control plane interactions with <NUM> Core in PLMN(s) <NUM>).

Disclosed herein is a mechanism for (e.g., the FFAE server <NUM> and FFAE client <NUM>) for monitoring the application TSN QoS parameters and negotiating a change of application QoS requirements to be mapped to an updated traffic policy and/or network policy, which may take the form of <NUM>) adaptation of service requirements (e.g., survival time), <NUM>) adaptation of network requirements (e.g., TSN QoS) or <NUM>) adaptation of port management policies (DS-TT policies, NW-TT policies). The solution comprises the following high level steps:.

At step <NUM>, the TSN/FF application-specific server (or another external functionality from the TSN system <NUM>, e.g., CNC) sends to the FFAE-S <NUM> a request for managing the TSN QoS for one or more applications (see messaging <NUM>). For TSN, the CNC acts as a proxy for the Network (the TSN Bridges and their interconnections) and the control applications that require deterministic communication. The CNC defines the schedule on which all TSN frames are transmitted.

The FFAE-S <NUM> is defined as a middleware server which may reside at the service providers domain or the network operator domain; and includes TSN AF functionality <NUM> as well as server-client support functionalities. TSN system <NUM> distributes the TSN QoS requirements, PSFP policies and TSN scheduling parameters to FFAE-S <NUM>, as part of the request.

At step <NUM>, in response of the receiving the request, the FFAE-S <NUM> configures one or more FFAE-Cs <NUM> (using also pre-configured traffic mapping tables by OAM), to monitor application or network related TSN QoS attributes and report trigger events based on their unfulfillment (see messaging <NUM>). This trigger may also be related to the degradation of the radio conditions. The FFAE-C <NUM> in response of receiving the configuration, may send a response/ACK to the FFAE-S <NUM> and starts monitoring the radio conditions (by interacting with the AS layers of the UE).

At step <NUM>, the TSN device <NUM> experiences a trigger event. The FFAE-C <NUM> captures a change at the radio access conditions and/or UE context (e.g., mobility/velocity) and reports to the FFAE-S <NUM> a trigger event based on the changes, e.g., the change of application or network QoS for the session (see messaging <NUM>).

At step <NUM>, the FFAE-S <NUM> in response of receiving the trigger event, translates the change of network/application QoS conditions to an updated proposed TSN policy, to ensure meeting the stringent KPIs (see block <NUM>). This proposed updated policy is one or more of the following: <NUM>) Update of TSN service attributes (survival time, mobility, TSC service area, automation level); <NUM>) Update of TSN QoS attributes (e.g., requirement for new 5QI for the session); <NUM>) Update of port management policies (for NW-TT <NUM> and/or DS-TT <NUM>), e.g., including also a) Change the relationship between a port on UE/DS-TT side and a PDU Session, and b) Change of hold and buffer parameters to allow the dynamic de-jittering for a session.

At step <NUM>, the FFAE-S <NUM> negotiates the proposed updated policies with the TSN System <NUM> and/or the CNC, by sending a request to the TSN system <NUM> (i.e., TSN AS or CNC), to adjust the service/QoS/port management requirements (see messaging <NUM>).

At steps <NUM>, the FFAE-S in response of receiving a confirmation of the TSN system (acknowledgement or an alternative for policy update), it applies the new policies accordingly. Depending on the new policy, this is communicated to one or more of the following: (A) transmit the new service requirements to the FFAE-C <NUM> and 5GS (see messaging <NUM> and <NUM>), (B) transmit the new QoS policies to 5GS (e.g., PLMN <NUM>; see messaging <NUM>), (C) transmit to the NW-TT <NUM> the updated policies, and in particular, to transfer standardized and deployment-specific port management information (acting as TSN AF <NUM>; see messaging <NUM>), and (D) transmit to the DS-TT <NUM> (via the FFAE-C <NUM>) the updated policies, and in particular, to transfer standardized and deployment-specific port management information between the FFAE-S <NUM> and the FFAE-C <NUM> to reach DS-TT <NUM> (see messaging <NUM>).

The benefit of applying the policies related to service requirements are to allow the fast adaptation of application behavior (e.g., mobility, survival time) to ensure meeting the TSC flow requirements, whereas preventing the adaption of the network QoS parameters.

As particular example of application-to-network QoS negotiation, the survival time which is set per TSN service can be provided. This metric may be adjusted to avoid service discontinuity (if packets are not received after X ms, session is suspended; however, this may be due to some temporary link degradation). If the FFAE-C <NUM> monitors some congestion at radio side and alerts the FFAE-S <NUM>, then the FFAE-S <NUM> may request the adjustment of survival time in a given area. In another example, the mobility of the UEs/TSN Devices <NUM> may be reduced to allow for meeting the KPIs (e.g., in case of moving towards a congested area).

The benefit of applying the policies related to QoS requirements adaption are to ensure undisrupted service by dynamically negotiating the change of service offering for a TSC flow with the TSN system <NUM>.

As a particular example, the FFAE-S <NUM> may request to adapt the TSN QoS profile so as to continue providing the service with more relaxed QoS attributes. The FFAE-S <NUM> provides the requested adaption to CNC and CNC may trigger the application requirements adaptation which result to QoS profile change (via TSCAI).

The benefit of applying port management policies corresponding to the user-plane and/or 5GS bridge adaptations are that the FFAE-S <NUM> may re-configure the NW-TT/DS-TT rules, e.g., to change the stop-and-buffer mechanisms to ensure meeting the deterministic communication requirements for the corresponding application. This may result - after negotiation - to change of the 5GS bridge <NUM>, <NUM> if the current bridge cannot support the delay requirements.

One particular example for policy adaptation is that when high jitter is monitored, the parameters for hold-and-forward buffering (also referred to as stop-and-forward buffering) may be adapted (adapt the time for holding the traffic) to ensure meeting the jitter target for the user-plane traffic.

As a further example for policy adaptation corresponding to both port management policies and service requirements, when high jitter is monitored for an ongoing session, the hold-and-forward buffering parameters may be adapted to de-jitter the TSC flows. However, this will have impact on the survival time, because the delayed reception of the traffic (due to holding the incoming packets at the NW-TT <NUM>) may lead to session termination at the device side (due to reaching the maximum survival time). In this case, the FFAE-S <NUM> negotiates with the TSN system (e.g., TSN AS and/or CNC <NUM>) the adaption of the survival time, in combination with the hold-and-forward buffering parameters. After negotiating, the FFAE-S <NUM> provides the new survival time to the FFAE-C <NUM>, and the new hold-and-forward buffering parameters to the NW-TT <NUM>.

<FIG> depicts a procedure <NUM> for negotiating the service and/or QoS requirements, according to embodiments of the disclosure. The procedure <NUM> involves a vertical UE <NUM>, a PLMN domain <NUM>, and a service provider domain <NUM>. Here, the vertical UE <NUM> includes a FFAC <NUM>, a FFAE client ("FFAE-C") <NUM>, a DS-TT <NUM>, and an 3GPP UE <NUM>. The PLMN domain <NUM> includes a PCF and/or SMF (depicted as combined element "PCF/SMF" <NUM>). The PLMN domain <NUM> also includes a NW-TT <NUM>. The service provider domain <NUM> includes a FFAE server ("FFAE-S") <NUM> and TSN application server and/or CNC (depicted as combined element "TSN AS / CNC" <NUM>).

The procedure <NUM> for negotiating the service requirements and/or QoS requirements between the FFAE-S and the TSN system for adapting the TSN service operation due to an access related event (radio related or UE context related change). As a precondition, the procedure <NUM> assumes that the UE <NUM> is registered to 5GS (e.g., part of PLMN domain <NUM>).

At Step <NUM>, the TSN system (e.g., TSN application specific server <NUM>) sends to the FFAE-S <NUM> a request for managing the TSN QoS for one or more applications. The FFAE-S <NUM> is defined as a middleware server which may reside at the service providers domain <NUM> or the network operator domain (e.g., PLMN domain <NUM>). The FFAE-S <NUM> may include TSN AF functionality as well as server-client support functionalities.

This request for managing the TSN QoS for one or more applications may include one or more of the following parameters: Application ID; service profile(s) and ID(s); service requirements (survival time, mobility, service coverage area); TSN QoS-related parameters; traffic classes and their priorities per port; TSC Burst Size of TSN streams; 5GS bridge delays per port pair and traffic class (independentDelayMax, independentDelayMin, dependentDelayMax, dependentDelayMin); propagation delay per port; UE-DS-TT residence time; PSFP policies; enforcement flag (whether the FFAE-S has the permission to enforce or just recommend a change); maximum number of UEs to be active simultaneously; UE IDs (GPSI, external ID, group ID); and area of validity (cell IDs, TA ID) and time of validity.

Note that the FFAE-S <NUM> may also have pre-configured mapping tables from OAM (e.g., as specified in TS <NUM>).

At Step <NUM>, the FFAE-S <NUM> interacts with the FFAE-C <NUM> to request the monitoring of radio status and/or UE context status (see messaging <NUM>). This can be in the form of a Request - Response (one-time event or periodically) or by Subscribing-Notify when an event is triggered. The FFAE-S <NUM> may also configure the TSN QoS event reporting at the Subscribe and/or Request message.

In some embodiments, the request/subscription may include one or more of the following parameters: A) Application ID; B) Service profiles and service IDs; C) UE IDs; D) TSN QoS related parameters; E) TSN QoS report configuration (time, format, parameters Mandatory and Optional); and F) area and time of validity.

At Step <NUM>, a trigger event is captured at the FFAE-C <NUM> (see block <NUM>) by either the application layer of the UE <NUM> (e.g., QoE measurements, throughput degradation, packet drops,. ) or by the lower layers of the UE <NUM> (based on radio measurements like CSI, RRM, RLM measurements). Also, the application (i.e., FFAC <NUM>) may provide UE-related context change (e.g., change of mobility or velocity) which will be input for the trigger.

A trigger event report message is sent from FFAE-C <NUM> to FFAE-S <NUM> (see messaging <NUM>). In various embodiments, the trigger event report includes one or more of the following parameters: UE QoE/QoS downgrade indication; UE QoS/QoE sustainability analytics; High resource load indication and/or Congestion indication; High access delay indication; Low Resource availability indication; QoS fluctuations indication; Radio Link failures indication; Channel Loss over a X%; PER over Y%; UE mobility and/or velocity change indication; RRM/RLM measurements; Indication for reaching maximum survival time; and Indication for reaching service area edge.

At Step <NUM>, the FFAE-S <NUM> upon receiving the report, processes the report and determines a proposed TSN policy update for the applications running that service (or a sub-set of them) (see block <NUM>). The different policy types include change of service requirements and change of QoS/QoE requirements.

Examples of change of service requirements include (but are not limited to): A) Increase survival time if indication for reaching survival time was acquired or if temporary coverage gap occurs (but without affecting the service operation); B) Require the change of mobility or inter-UE distance (for this UE and the surrounding) to ensure meeting the KPIs, in cases when the congestion and/or resource unavailability at target area where the UE moves, may lead to performance downgrade; C) Increase the service area to extend TSN service coverage to ensure meeting the TSC requirements; D) Decrease the service area to minimize the effect of interference by other UEs using the same resources; and E) Request the change of automation level for the TSC service (e.g., from fully automated AGVs to cloud navigated AGVs).

Examples of change of QoS/QoE requirements include (but are not limited to): A) Change of application QoS and/or QoE requirements (e.g., throughput, RTT, reliability, communication service availability, jitter, a quality of experience score, a buffering parameter, a stalling event, a stalling ratio, a mean opinion score); and B) Change of TSN QoS profile for the service (e.g., 5QI change, alternative 5QI priority change,.

At Step 4a, the FFAE-S <NUM> sends the proposed TSN policy update to TSN AS <NUM> and/or TSN System (see messaging <NUM>). The Update Policy Request message includes at least one of the following parameters: A) Application ID, Service ID, UE ID, and Bridge ID; B) Cause of adaptation (mobility change, QoS and/or QoE degradation, QoS and/or QoE upgrade, RAN performance downgrade/upgrade,. ); C) Proposed Policy Update ID; D) Proposed Policy Update type (change service req, change of QoS requirements); E) Proposed Policy Update parameters (change survival time, change mobility, change service area, change automation level, change of application QoS and/or QoE request, change of QoS profile); and F) Time validity and Area of validity for the proposed update.

At Step 4b, the FFAE-S <NUM> receives a response from the TSN AS <NUM> and/or TSN System, indicating a positive or negative acknowledgement or proposing an alternative TSN policy update (see messaging <NUM>). The Update Policy Response message includes at least one of the following parameters: A) Result (Yes, No, Negotiate); B) Alternative Policy Update ID; C) Alternative Policy Update parameters (change survival time, change mobility, change service area, change automation level, change of application QoS/QoE request, change of QoS profile); and D) Time validity and area of validity for the negotiated update. Note that the FFAE-S <NUM> may also send an ACK as response for the negotiated policy update.

At Step 5a1, the FFAE-S <NUM> sends a service requirements update request message to the involved FFAE clients <NUM> (see messaging <NUM>). This message includes the agreed policy update ID, type and parameters (proposed or alternative), as well as the time and area validity.

At Step 5a2, the FFAE-C <NUM> based on the update type interacts with FFAC <NUM> and/or TSN system to apply the requested changes (see block <NUM>).

If the change is about survival time increase, the FFAE-C <NUM> sends to FFAC <NUM> the new extended survival time (new value or delta value).

If the change is about mobility and/or velocity change, the FFAE-C <NUM> sends to FFAC <NUM> a request for changing the mobility and/or velocity of the device. This may be also relayed to other surrounding FFAE clients <NUM> which are involved in this action.

If the change is about service area increase/decrease, the FFAC <NUM> get informed on the new coverage, and also the FFAE-C <NUM> notifies the AS layer of the UE <NUM> for adapting radio parameters accordingly, e.g., power control.

At Step 5a3, the FFAE-S <NUM> receives a response as acknowledgement for the update request message, upon the application of the updated policies (see messaging <NUM>).

At Step 5b1, the FFAE-S <NUM> after receiving the response, acting as TSN AF, it sends an Updated TSN QoS container to SMF via PCF (via N5 or Nnef, see messaging <NUM>). This message includes the updated QoS requirements to be applied to the PDU session. At Step 5b2, the SMF updates the PCC rules and the TSCAI which is then sent to RAN (see block <NUM>).

<FIG> depicts a procedure <NUM> for negotiating changes of port management policies, according to embodiments of the disclosure. The procedure <NUM> involves the vertical UE <NUM>, the PLMN domain <NUM>, and the service provider domain <NUM>, described above with reference to <FIG>. As a precondition, the procedure <NUM> assumes that the UE <NUM> is registered to 5GS (e.g., part of PLMN domain <NUM>).

The procedure <NUM> begins with Steps <NUM>-<NUM> described above with reference to <FIG> (refer to messaging <NUM>, block <NUM>, messaging <NUM>, block <NUM> and messaging <NUM>).

Continuing at Step <NUM>, the FFAE-S <NUM> upon receiving the report, processes the report and determines a proposed TSN policy update for the applications running that service (or a sub-set of them) (see block <NUM>). The target is to negotiate the 5GS bridge parameters for the end-to-end TSC stream, based on the QoS/radio monitoring. The change of NW-TT <NUM> port management policies may include one or more of the following:.

Hold-and-forward parameters (in case of high expected jitter to request the adaptation hold-and-forward time). This may include a change of parameters AdminBaseTime, AdminControlList at Port management information, e.g., described in TS <NUM>, clause <NUM>.

The change of DS-TT <NUM> port management policies may include one or more of the following:.

At Step 4a, the FFAE-S <NUM> sends the proposed TSN policy update to TSN AS <NUM> and/or TSN System (see messaging <NUM>). The Update Policy Request message includes at least one of the following parameters:.

At Step 4b, the FFAE-S <NUM> receives a response from the TSN AS <NUM> and/or TSN System, indicating a positive or negative acknowledgement or proposing an alternative TSN policy update (see messaging <NUM>). The Update Policy Response message includes at least one of the following parameters:.

For updates to DS-TT <NUM> policies, the FFAE-S <NUM> and FFAE-C <NUM> perform Steps 5a. For updates to NW-TT <NUM> policies, the FFAE-S <NUM> and PLMN domain <NUM> perform Steps 5b.

At Step 5a1, the FFAE-S <NUM> sends to the FFAE-C <NUM> a DS-TT port management update policy request (see messaging <NUM>), which includes the negotiated port management policies (can be seen as port management policy container which is send over FFAE layer). These parameters may include one or more of the following:.

At Step 5a3, the FFAE-C <NUM> sends a response to the FFAE-S <NUM> indicating a positive or negative acknowledgement.

At Step 5b1, the FFAE-S <NUM> (acting as TSN AF) sends to NW-TT <NUM> a port management update policy request (see messaging <NUM>), which includes the negotiated port management policies (can be seen as port management policy container which is send over FFAE layer). These parameters may include one or more of the following:.

At Step 5b3, the NW-TT <NUM> sends a response to the FFAE-S <NUM> indicating a positive or negative acknowledgement (see messaging <NUM>).

<FIG> depicts a procedure <NUM> for using SEAL service for TSC QoS monitoring, according to embodiments of the disclosure. The procedure <NUM> involves a SEAL server and/or NRx (depicted as combined element "SEAL/NRx" <NUM>), a FFAE-S <NUM>, and TSN System and/or TSN AS (depicted as combined element "TSN System/TSN AS" <NUM>). The SEAL server is an entity which provides on-demand (subscription or request) services for all vertical enablers (e.g., FFAE-S <NUM>). In certain embodiments, the SEAL server performs as described in 3GPP TS <NUM>. A SEAL Network Resource Management service enabler specifies APIs to request reservation, modification, and release of network resources, including QoS resources.

One functionality of the SEAL/NRx <NUM> is the monitoring of QoS for TSC flows. In particular, the FFAE-S323 may subscribe to receive QoS monitoring reports from the SEAL server (e.g., NRx) <NUM> by making use of the NEF QoS monitoring capabilities. In this embodiment, the monitoring of QoS related to TSC flows is not provided by FFAE-C / device side; but this is provided by a SEAL/NRx server <NUM>.

As a pre-condition, the UE is registered to 5GS and a TSC session is ongoing. At Step <NUM>, TSN system (or TSN application specific server) sends to the FFAE-S <NUM> a request for managing the TSN QoS for one or more applications (see messaging <NUM>). The FFAE-S <NUM> is defined as a middleware server which may reside at the service providers domain or the network operator domain; and includes TSN AF functionality as well as server-client support functionalities. This request includes one or more of the following parameters:.

Note that the FFAE-S <NUM> may also have pre-configured mapping tables from OAM (as specified in TS <NUM>) (see block <NUM>).

At Step <NUM>, the FFAE-S <NUM> subscribes to receives QoS monitoring events from SEAL server / NRx <NUM> (see block <NUM>). This subscription may include configuration of reporting which includes:.

At Step <NUM>, a trigger event is captured at the SEAL/NRx <NUM> which can be acquired by the SEAL client of the UE (e.g., QoE measurements, throughput degradation, packet drops, etc.) (see messaging <NUM>). The trigger event report message is sent from the SEAL/NRx server <NUM> to the FFAE-S <NUM> and includes one or more of the following parameters:.

At Step <NUM>, the FFAE-S <NUM> upon receiving the report, processes the report and determines a proposed TSN policy update for the applications running that service (or a sub-set of them) (see block <NUM>). The target is to negotiate the service, QoS or port management information with the TSN system <NUM> (parameters are similar to Steps <NUM> of Embodiments #<NUM> and #<NUM>).

At Step 4a, the FFAE-S <NUM> sends the proposed TSN policy update to TSN AS / TSN System <NUM> (see messaging <NUM>). The Update Policy Request message includes at least one of the following parameters:.

At Step 4b, the FFAE-S <NUM> receives a response from the TSN AS / TSN System <NUM>, indicating a positive or negative acknowledgement or proposing an alternative TSN policy update (see messaging <NUM>). The Update Policy Response message includes at least one of the following parameters:.

Note that the FFAE-S <NUM> may also send an ACK as response for the negotiated policy update.

At Step <NUM>, the SEAL/NRx <NUM>, a FFAE-S <NUM>, and TSN System / TSN AS <NUM> perform policy updating (see block <NUM>). If the policies require service/QoS adaptation, the transmission of the update policies to FFAE-C, DS-TT, NW-TT is similar to Step <NUM> of the <FIG> (the first solution). If the policies alter port management parameters policies require service/QoS adaptation, the transmission of the update policies to FFAE-C, DS-TT, NW-TT is similar to Step <NUM> of the <FIG> (the second solution).

<FIG> depicts a user equipment apparatus <NUM> that may be used for policy modification in a TSN system, according to embodiments of the disclosure. In various embodiments, the user equipment apparatus <NUM> is used to implement one or more of the solutions described above. The user equipment apparatus <NUM> may be implemented in a TSN device, such as the TSN device <NUM> containing the remote unit <NUM> and FFAE-C <NUM>, and/or the vertical UE <NUM> containing FFAE-C <NUM> and UE <NUM>, described above. Furthermore, the user equipment apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, and a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus <NUM> may not include any input device <NUM> and/or output device <NUM>. In various embodiments, the user equipment apparatus <NUM> may include one or more of: the processor <NUM>, the memory <NUM>, and the transceiver <NUM>, and may not include the input device <NUM> and/or the output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with one or more remote units <NUM>. Additionally, the transceiver <NUM> may support at least one network interface <NUM>. In some embodiments, the transceiver <NUM> supports a first interface (e.g., Uu interface) for communicating with one or more base units in a RAN, a second interface (e.g., N1 interface) for communicating with a AMF, and a third interface for communicating with a TSN system.

For example, the processor <NUM> may be a microcontroller, a microprocessor, a central processing unit ("CPU"), a graphics processing unit ("GPU"), an auxiliary processing unit, a FPGA, or similar programmable controller.

The user equipment apparatus <NUM> supports one or more application interfaces <NUM>. Each application interface <NUM> supports communication among application instances running on the user equipment apparatus <NUM> and/or supports communication with an external application instance, e.g., running on a network device or a UE. In some embodiments, the application interface(s) <NUM> include a set of functions and procedures that allow for applications running on the user equipment apparatus <NUM> to access data and features of other applications, services or operating systems. As described in further detail below, a FFAE client running on the user equipment apparatus <NUM> may use an application interface <NUM> to communicate with a FFAE server. As another example, a TSN application running on the user equipment apparatus <NUM> may use an application interface <NUM> to communicate with a TSN application server.

In various embodiments, the processor <NUM> controls the user equipment apparatus <NUM> to implement the above described UE and/or FFAE-C behaviors. In some embodiments, the processor <NUM> detects a trigger event. Here, the trigger event may indicate a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. Via the transceiver <NUM> and/or application interface <NUM>, the processor <NUM> reports the trigger event to an application enabler server (i.e., the FFAE-S) and receives a policy parameter based on the first policy parameter from the TSN system. Here, the policy parameter includes at least one of: a first service parameter, a first QoS parameter and a first port management parameter. The processor <NUM> updates a TSN policy based on the received policy parameter.

In some embodiments, the policy parameter is received in an update request. In such embodiments, the processor <NUM> further transmits (i.e., via transceiver <NUM>) an update response to the application enabler server.

In some embodiments, the processor <NUM> receives (i.e., via transceiver <NUM> and/or application interface <NUM>) a request for monitoring reporting from the application enabler server. In such embodiments, the trigger event is reported in response to the request for monitoring reporting. In certain embodiments, the request for monitoring reporting includes a subscription request for a Subscribe/Notify communication model. In other embodiments, the request for monitoring reporting includes a subscription request for a Request/Response communication model.

In various embodiments, the request for monitoring reporting includes at least one of the following parameters: an Application ID, at least one service profile and service ID, at least one UE ID, at least one TSN QoS related parameter, a TSN QoS report configuration, a set of area of validity and time of validity parameters.

In some embodiments, the memory <NUM> stores data related to policy modification in a TSN system. For example, the memory <NUM> may store TSN policies, service requirements, QoS requirements, QoE requirements, port management policies, and the like. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system or other controller algorithms operating on the remote unit <NUM>.

The transceiver <NUM> operates under the control of the processor <NUM> to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor <NUM> may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages.

In various embodiments, the transceiver <NUM> is configured to communicate with 3GPP access network(s) and/or the non-3GPP access network(s). In some embodiments, the transceiver <NUM> implements modem functionality for the 3GPP access network(s) and/or the non-3GPP access network(s). In one embodiment, the transceiver <NUM> implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

In one embodiment, the transceiver <NUM> includes a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

The transceiver <NUM> may include one or more transmitters <NUM> and one or more receivers <NUM>. Although a specific number of transmitters <NUM> and receivers <NUM> are illustrated, the user equipment apparatus <NUM> may have any suitable number of transmitters <NUM> and receivers <NUM>. Further, the transmitter(s) <NUM> and the receiver(s) <NUM> may be any suitable type of transmitters and receivers. In certain embodiments, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share transceiver hardware and/or circuitry. For example, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like.

In various embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an application-specific integrated circuit ("ASIC"), or other type of hardware component. In certain embodiments, one or more transmitters <NUM> and/or one or more receivers <NUM> may be implemented and/or integrated into a multi-chip module. In some embodiments, other components such as the network interface <NUM> or other hardware components/circuits may be integrated with any number of transmitters <NUM> and/or receivers <NUM> into a single chip. In such embodiment, the transmitters <NUM> and receivers <NUM> may be logically configured as a transceiver <NUM> that uses one more common control signals or as modular transmitters <NUM> and receivers <NUM> implemented in the same hardware chip or in a multi-chip module. In certain embodiments, the transceiver <NUM> may implement a 3GPP modem (e.g., for communicating via NR or LTE access networks) and a non-3GPP modem (e.g., for communicating via Wi-Fi or other non-3GPP access networks).

<FIG> depicts one embodiment of a network equipment apparatus <NUM> that may be used for policy modification in a TSN system, according to embodiments of the disclosure. In some embodiments, the network equipment apparatus <NUM> may be one embodiment of a FFAE server, such as the FFAE-S <NUM>, and/or the FFAE <NUM>. Furthermore, network equipment apparatus <NUM> may include a processor <NUM>, a memory <NUM>, an input device <NUM>, an output device <NUM>, a transceiver <NUM>. In some embodiments, the input device <NUM> and the output device <NUM> are combined into a single device, such as a touch screen. In certain embodiments, the network equipment apparatus <NUM> does not include any input device <NUM> and/or output device <NUM>.

As depicted, the transceiver <NUM> includes at least one transmitter <NUM> and at least one receiver <NUM>. Here, the transceiver <NUM> communicates with one or more remote units <NUM>. Additionally, the transceiver <NUM> may support at least one network interface <NUM>, such as the N1, N2, and N3 interfaces. In some embodiments, the transceiver <NUM> supports a first interface for communicating with one or more network functions in a mobile core network (e.g., a 5GC and/or EPC), a second interface for communicating with a TSN system, and a third interface for communicating with a remote unit (e.g., UE).

The network equipment apparatus <NUM> supports one or more application interfaces <NUM>. Each application interface <NUM> supports communication among application instances running on the user equipment apparatus <NUM> and/or supports communication with an external application instance, e.g., running on a network device or a UE. In some embodiments, the application interface(s) <NUM> include a set of functions and procedures that allow for applications running on the network equipment apparatus <NUM> to access data and features of other applications, services or operating systems. As described in further detail below, a FFAE client running on the network equipment apparatus <NUM> may use an application interface <NUM> to communicate with a FFAE server. As another example, a TSN application running on the network equipment apparatus <NUM> may use an application interface <NUM> to communicate with a TSN application server.

In various embodiments, the processor <NUM> controls the network equipment apparatus <NUM> to perform the above described FFAE-S behaviors. Via an application interface <NUM>, the processor <NUM> may receive a trigger event. Here, the trigger event indicates a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. Responsive to the trigger event, the processor <NUM> determines a first policy parameter for at least one UE. Here, the first policy parameter includes at least one of: a first service parameter, a first QoS parameter and a first port management parameter.

Via the network interface <NUM> and/or application interface <NUM>, the processor <NUM> requests a policy modification from a TSN system, said request including the first policy parameter, and receives a second policy parameter based on the first policy parameter from the TSN system. Via the network interface <NUM> and/or application interface <NUM>, the processor <NUM> transmits the second policy parameter to at least one network entity and/or the at least one UE.

In some embodiments, the processor <NUM> sends a request for monitoring reporting from the at least one UE. In certain embodiments, the request for monitoring reporting comprises a subscription request for a Subscribe/Notify communication model. In other embodiments, the request for monitoring reporting includes a subscription request for a Request/Response communication model. In various embodiments, the request for monitoring reporting includes at least one of the following parameters: an Application ID, at least one service profile and service ID, at least one UE ID, at least one TSN QoS related parameter, a TSN QoS report configuration, a set of area of validity and time of validity parameters.

In some embodiments, the trigger event is one of the following: a downgrade indication for UE QoS, a downgrade indication for UE QoE, UE QoS sustainability analytics, UE QoE sustainability analytics, a high resource load indication, a congestion indication, a high access-delay indication, a low resource availability indication, a QoS fluctuation indication, a radio link failure indication, a channel loss over a threshold amount, a packet error rate over a threshold amount, a UE mobility indication, a UE velocity change indication, RRM measurements, RLM measurements, an indication for reaching maximum survival time, and an indication for reaching service area edge.

In some embodiments, the first policy parameter is a service parameter or a first QoS parameter, wherein the first policy parameter comprises one or more of the following actions: an increased survival time, a decreased survival time, a change of UE mobility distance, a change of inter-UE distance, an increase of a TSC service area, a decrease of the TSC service area, an adaption to an automation level for a TSC flow, an adaption to an application QoS requirement, an adaption to a network QoS requirement, an adaption to a network QoS profile, and an adaption to a QoE target.

In some embodiments, the first policy parameter is port management parameter, wherein the first policy parameter comprises one or more of the following actions: an adaption to a Hold-and-Forward parameter (in particular change of AdminBaseTime, AdminControlList), an adaption to a Per Stream Flow Policy (e.g., change bandwidth profile), an adaption to a Queuing policy parameter (change weights, priorities), and a 5GS bridge switch.

In some embodiments, the second updated policy parameter is different from the first parameter. In certain embodiments, the second policy parameter comprises one or more of the following actions: an increased survival time, a decreased survival time, a change of UE mobility distance, a change of inter-UE distance, an increase to a TSC service area, a decrease the TSC service area, an adaption to an automation level for the TSC flow, an adaption to an application QoS requirement, an adaption to a network QoS requirement, an adaption to a network QoS profile, an adaption to a QoE target, an adaption to a Hold-and-Forward parameters (in particular change of AdminBaseTime, AdminControlList), an adaption to a Per Stream Flow Policies (e.g., change bandwidth profile), an adaption to a Queuing policy parameters (change weights, priorities), and a 5GS bridge switch.

In some embodiments, the determination of the second policy parameter is determined by a TSN system or an external application. In certain embodiments, the at least one network entity to which the second policy parameter is transmitted comprises a NW-TT and/or a core network function. In certain embodiments, the second policy parameter is transmitted to a DS-TT and/or one or more applications of the at least one UE. In some embodiments, the trigger event is received from at least one of a SEAL server and a network resource management server.

In some embodiments, the memory <NUM> stores data relating to policy modification in a TSN system, for example storing TSN policies, service requirements, QoS requirements, QoE requirements, port management policies, and the like. In certain embodiments, the memory <NUM> also stores program code and related data, such as an operating system ("OS") or other controller algorithms operating on the network equipment apparatus <NUM> and one or more software applications.

The output device <NUM>, in one embodiment, may include any known electronically controllable display or display device. The output device <NUM> may be designed to output visual, audible, and/or haptic signals. In some embodiments, the output device <NUM> includes an electronic display capable of outputting visual data to a user. As another, non-limiting, example, the output device <NUM> may include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like.

In other embodiments, all or portions of the output device <NUM> may be located near the input device <NUM>.

As discussed above, the transceiver <NUM> may communicate with one or more remote units and/or with one or more network functions that provide access to one or more PLMNs. The transceiver <NUM> may also communicate with one or more network functions (e.g., in the mobile core network <NUM>). The transceiver <NUM> operates under the control of the processor <NUM> to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor <NUM> may selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages.

The transceiver <NUM> may include one or more transmitters <NUM> and one or more receivers <NUM>. In certain embodiments, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share transceiver hardware and/or circuitry. For example, the one or more transmitters <NUM> and/or the one or more receivers <NUM> may share antenna(s), antenna tuner(s), amplifier(s), filter(s), oscillator(s), mixer(s), modulator/demodulator(s), power supply, and the like. In one embodiment, the transceiver <NUM> implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

<FIG> depicts one embodiment of a method <NUM> for policy modification in a TSN system, according to embodiments of the disclosure. In various embodiments, the method <NUM> is performed by a FFAE server, such as the FFAE-S <NUM>, the FFAE <NUM>, and/or user equipment apparatus <NUM>, described above. In some embodiments, the method <NUM> is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> begins and receives <NUM> a trigger event, the trigger event indicating a change to a wireless radio parameter, a UE QoS parameter, and/or UE context information. The method <NUM> includes determining <NUM> a first policy parameter for at least one UE. Here, the first policy parameter includes a first service parameter, a first QoS parameter, and/or a first port management parameter. The method <NUM> includes requesting <NUM> a policy modification from a TSN system, said request including the first policy parameter. The method <NUM> includes receiving <NUM> a second policy parameter based on the first policy parameter from the TSN system. The method <NUM> includes transmitting <NUM> the second policy parameter to at least one network entity and/or the at least one UE. The method <NUM> ends.

<FIG> depicts one embodiment of a method <NUM> for policy modification in a TSN system, according to embodiments of the disclosure. In various embodiments, the method <NUM> is performed by a FFAE client device, such as the FFAE-C <NUM> in the TSN device <NUM>, the FFAE-C <NUM> in the vertical UE <NUM>, and/or the user equipment apparatus <NUM>, described above. In some embodiments, the method <NUM> is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

The method <NUM> begins and detects <NUM> a trigger event, the trigger event indicating a change to a wireless radio parameter, a UE QoS parameter, and/or UE context information. The method <NUM> includes reporting <NUM> the trigger event to an application enabler server. The method <NUM> includes receiving <NUM> a policy parameter based on the first policy parameter from the TSN system, the policy parameter includes a first service parameter, a first QoS parameter and/or a first port management parameter. The method <NUM> includes updating <NUM> a TSN policy based on the received policy parameter. The method <NUM> ends.

Disclosed herein is a first apparatus for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more UEs, according to embodiments of the disclosure. The first apparatus may be implemented by a FFAE server, such as the FFAE-S <NUM>, the FFAE <NUM>, and/or user equipment apparatus <NUM>. The first apparatus includes a processor and an application interface that receives a trigger event, the trigger event indicating a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. The processor determines a first policy parameter for at least one UE. Here, the first policy parameter includes at least one of: a first service parameter, a first QoS parameter and a first port management parameter. Via the application interface, the processor requests a policy modification from a TSN system, said request including the first policy parameter, receives a second policy parameter based on the first policy parameter from the TSN system, and transmits the second policy parameter to at least one network entity and/or the at least one UE.

In some embodiments, the processor sends a request for monitoring reporting from the at least one UE. In certain embodiments, the request for monitoring reporting comprises a subscription request for a Subscribe/Notify communication model. In other embodiments, the request for monitoring reporting includes a subscription request for a Request/Response communication model. In various embodiments, the request for monitoring reporting includes at least one of the following parameters: an Application ID, at least one service profile and service ID, at least one UE ID, at least one TSN QoS related parameter, a TSN QoS report configuration, a set of area of validity and time of validity parameters.

Disclosed herein is a first method for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more UEs, according to embodiments of the disclosure. The first method may be performed by a FFAE server, such as the FFAE-S <NUM>, the FFAE <NUM>, and/or user equipment apparatus <NUM>. The first method includes receiving a trigger event. Here, the trigger event indicating a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. The first method determining a first policy parameter for at least one UE. Here, the first policy parameter includes at least one of: a first service parameter, a first QoS parameter and a first port management parameter. The first method requesting a policy modification from a TSN system, said request including the first policy parameter, receiving a second policy parameter based on the first policy parameter from the TSN system, and transmitting the second policy parameter to at least one network entity and/or the at least one UE.

In some embodiments, the first method includes requesting monitoring reporting from the at least one UE. In certain embodiments, the request for monitoring reporting includes a subscription request for a Subscribe/Notify communication model. In other embodiments, the request for monitoring reporting includes a subscription request for a Request/Response communication model. In various embodiments, the request for monitoring reporting includes at least one of the following parameters: an Application ID, at least one service profile and service ID, at least one UE ID, at least one TSN QoS related parameter, a TSN QoS report configuration, a set of area of validity and time of validity parameters.

Disclosed herein is a second apparatus for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more UEs, according to embodiments of the disclosure. The second apparatus may be implemented by a FFAE client device, such as the FFAE-C <NUM> in the TSN device <NUM>, the FFAE-C <NUM> in the vertical UE <NUM>, and/or the user equipment apparatus <NUM>, described above. The second apparatus includes a processor that detects a trigger event, the trigger event indicating a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. The second apparatus includes a transceiver that reports the trigger event to an application enabler server (i.e., the FFAE-S) and receives a policy parameter based on the first policy parameter from the TSN system. Here, the policy parameter includes at least one of: a first service parameter, a first QoS parameter and a first port management parameter. The processor updates a TSN policy based on the received policy parameter.

In some embodiments, the policy parameter is received in an update request. In such embodiments, the processor further transmits an update response to the application enabler server.

In some embodiments, the transceiver receives a request for monitoring reporting from the application enabler server, wherein the trigger event is reported in response to the request for monitoring reporting. In certain embodiments, the request for monitoring reporting includes a subscription request for a Subscribe/Notify communication model. In other embodiments, the request for monitoring reporting includes a subscription request for a Request/Response communication model. In various embodiments, the request for monitoring reporting includes at least one of the following parameters: an Application ID, at least one service profile and service ID, at least one UE ID, at least one TSN QoS related parameter, a TSN QoS report configuration, a set of area of validity and time of validity parameters.

Disclosed herein is a second method for negotiating the TSN QoS, service and bridge parameters for one or more TSC flows of one or more UEs, according to embodiments of the disclosure. The second method may be implemented by a FFAE client device, such as the FFAE-C <NUM> in the TSN device <NUM>, the FFAE-C <NUM> in the vertical UE <NUM>, and/or the user equipment apparatus <NUM>, described above. The second method includes detecting a trigger event. Here, the trigger event indicates a change to at least one of: a wireless radio parameter, a UE QoS parameter, and UE context information. The second method includes reporting the trigger event to an application enabler server (i.e., the FFAE-S) and receiving a policy parameter based on the first policy parameter from the TSN system. Here, the policy parameter includes at least one of: a first service parameter, a first QoS parameter and a first port management parameter. The second method includes updating a TSN policy based on the received policy parameter.

In some embodiments, the policy parameter is received in an update request. In such embodiments, the second method includes transmitting an update response to the application enabler server.

In some embodiments, the second method includes receiving a request for monitoring reporting from the application enabler server, wherein the trigger event is reported in response to the request for monitoring reporting. In certain embodiments, the request for monitoring reporting comprises a subscription request for a Subscribe/Notify communication model. In other embodiments, the request for monitoring reporting comprises a subscription request for a Request/Response communication model. In various embodiments, the request for monitoring reporting includes at least one of the following parameters: an Application ID, at least one service profile and service ID, at least one UE ID, at least one TSN QoS related parameter, a TSN QoS report configuration, a set of area of validity and time of validity parameters.

Claim 1:
A method (<NUM>) performed by an Application Enabling Server, AES, the method (<NUM>) comprising:
receiving (<NUM>) a trigger event from a User Equipment, UE, wherein the trigger event indicates a change to at least one of: a wireless radio parameter, a UE Quality of Service, QoS, parameter, or UE context information, and wherein the UE context information relates to a mobility or a velocity of the UE;
determining (<NUM>) a first policy parameter for at least one UE based on the trigger event, wherein the first policy parameter comprises at least one of: a first service parameter, a first QoS parameter, or a first port management parameter;
requesting (<NUM>) a policy modification from a Time-Sensitive Networking, TSN, system, wherein the request for the policy modification includes the first policy parameter;
receiving (<NUM>) a second policy parameter based on the first policy parameter from the TSN system; and
transmitting (<NUM>) the second policy parameter to at least one network entity or the at least one UE, or both.