EP4144059A1

EP4144059A1 - Mechanism for stream reservation control in communication network for time sensitive networking system

Info

Publication number: EP4144059A1
Application number: EP20724037.5A
Authority: EP
Inventors: Borislava GAJIC; Christian MANNWEILER; Peter Rost; Rakash Sivasivaganesan
Original assignee: Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2020-04-30
Filing date: 2020-04-30
Publication date: 2023-03-08
Also published as: WO2021219227A1

Abstract

An apparatus for use by a network element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, to process the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, to provide data based on the extracted relevant information to a core network control element or function of the communication network.

Description

MECHANISM FOR STREAM RESERVATION CONTROL IN COMMUNICATION NETWORK FOR TIME SENSITIVE NETWORKING SYSTEM

DESCRIPTION

BACKGROUND

Field

Examples of embodiments relate to apparatuses, methods, systems, computer programs, computer program products and (non-transitory) computer-readable media usable for integrating a communication network, such as a wireless communication network based on 3GPP standards, in a time sensitive networking (TSN) or Ethernet based system, and in particular to apparatuses, methods, systems, computer programs, computer program products and (non-transitory) computer-readable media usable for employing a wireless communication network part in a TSN system or Ethernet based system using a distributed configuration.

Background Art

The following description of background art may include insights, discoveries, understandings or disclosures, or associations, together with disclosures not known to the relevant prior art, to at least some examples of embodiments of the present disclosure but provided by the disclosure. Some of such contributions of the disclosure may be specifically pointed out below, whereas other of such contributions of the disclosure will be apparent from the related context.

The following meanings for the abbreviations used in this specification apply:

3GPP 3^rd Generation Partnership Project

4G fourth generation

5G fifth generation

5GS 5G system

AF application function

AMF access and mobility function AN access network

BS base station

CN core network

CP control plane

CPU central processing unit

DN data network

DS device side eNB evolved node B

ETSI European Telecommunications Standards Institute gNB next generation node B

ID identifier, identification

IEEE Institute of Electrical and Electronics Engineers loT Internet of things

LRP link-local reservation protocol

LTE Long Term Evolution

LTE-A LTE Advanced

MAC media access control

MMRP multiple MAC registration protocol

MRP multiple registration protocol

MSRP multiple SRP

MVRP multiple VLAN registration protocol

NEF network exposure function

NF network function

NG new generation

NW network, network side

PDU packet data unit

QoS quality of service

RAN radio access network

RAT radio access technology

RRP resource reservation protocol

SMF session and mobility management function

SRP stream reservation protocol

TSN time sensitive networking

TT TSN translator

UDM unified data management UE user equipment

UMTS universal mobile telecommunication system

UP user plane

UPF user plane function

URSP UE route selection policy

VLAN virtual local area network

SUMMARY

According to an example of an embodiment, there is provided, for example, an apparatus for use by a network element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, to process the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, to provide data based on the extracted relevant information to a core network control element or function of the communication network.

Furthermore, according to an example of an embodiment, there is provided, for example, a method for use in a network element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the method comprising receiving a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, processing the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, providing data based on the extracted relevant information to a core network control element or function of the communication network.

According to further refinements, these examples may include one or more of the following features:

- the declaration message related to the stream reservation procedure between the at least one talker party and at least one listener party may be received from a source located outside the bridge element of the communication system or from a translator element or function of the bridge element of the communication system;

- in the processing of the declaration message, as the type of the declaration message, one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message may be identified, wherein the kind of relevant information being extracted from the declaration message may depend on the identified type of the declaration message;

- in the processing of the declaration message, there may be extracted from the declaration message as the relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream.

- when providing data based on the extracted relevant information to the core network control element or function of the communication network, the extracted relevant information may be forwarded;

- in the processing of the declaration message, on the basis of the relevant information extracted from the declaration message, a further processing related to at least one of updating and handling the declaration message for forwarding it to a target may be conducted, and, when providing data based on the extracted relevant information to the core network control element or function of the communication network, a result of the further processing may be forwarded;

- as the further processing, at least one of determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target may be conducted;

- in response to the provision of data based on the extracted relevant information, from the core network control element or function of the communication network, response information indicating updating and handling of the declaration message for forwarding it to a target may be received, and the response information may be processed, wherein the response information may indicate at least one of a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified, an indication how parameters of the declaration message to be forwarded to the target are to be modified, a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and an identification of a port to be used for forwarding the declaration message to the target;

- an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the declaration message being received may be requested;

- an updated declaration message based on the processing result of the declaration message being received may be forwarded to a target of the declaration message;

- the communication network may form a bridge element for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function of the communication network may represent one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system, wherein a network-side translator element or function may be connected to or part of a core network element or function of the wireless communication network and a device-side translator element or function may be connected to or part of the device forming a mobile terminal element or function or a user equipment element or function, and wherein the apparatus (or method) may be connected to or part of at least one of the network-side translator element or function and the device-side translator element or function;

- the communication network may be based on a 3GPP standard.

In addition, according to an example of an embodiment, there is provided, for example, an apparatus for use by a core network control element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, to process the received data for updating and handling of the declaration message for forwarding it to a target, and to forward a result of the processing to a network element or function of the communication network for forwarding an updated declaration message to the target.

Furthermore, according to an example of an embodiment, there is provided, for example, a method for use in a core network control element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the method comprising receiving data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, processing the received data for updating and handling of the declaration message for forwarding it to a target, and forwarding a result of the processing to a network element or function of the communication network for forwarding an updated declaration message to the target. According to further refinements, these examples may include one or more of the following features:

- the data may be received from a translator element or function of the bridge element of the communication system;

- a type of the declaration message may be one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message, wherein the relevant information being the basis of the data being received may depend on the type of the declaration message;

- the relevant information may be required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, and may comprise at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream;

- the data being received and processed may include the extracted relevant information;

- in the processing of the received data, on the basis of the relevant information extracted from the declaration message, a further processing related to at least one of updating and handling the declaration message for forwarding it to the target may be conducted, wherein the further processing may comprise at least one of determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target;

- as the result of the processing, a result of the further processing may be forwarded to the network element or function of the communication network for forwarding an updated declaration message to the target; - the data being received and processed may include at least one of a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified, an indication how parameters of the declaration message to be forwarded to the target are to be modified, a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and an identification of a port to be used for forwarding the declaration message to the target, wherein in the processing of the received data, the contents of the data may be checked and is may be determined whether the contents of the data can be acknowledged or have to be modified;

- as the result of the processing, one of an acknowledgement of the contents of the data or an indication of a modification of the contents of the data may be forwarded to the network element or function of the communication network for forwarding an updated declaration message to the target;

- an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the data based on relevant information extracted from the declaration message may be requested;

- the communication network may form a bridge element for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function of the communication network may represent one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system, wherein a network-side translator element or function may be connected to or part of a core network element or function of the wireless communication network and a device-side translator element or function may be connected to or part of the device forming a mobile terminal element or function or a user equipment element or function, and wherein the apparatus (method) may be connected to or part of at least one of a core network control element or function of the communication network;

- the communication network may be based on a 3GPP standard.

In addition, according to embodiments, there is provided, for example, a computer program product for a computer, including software code portions for performing the steps of the above defined methods, when said product is run on the computer. The computer program product may include a computer-readable medium on which said software code portions are stored. Furthermore, the computer program product may be directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present disclosure are described below, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 shows a diagram illustrating an example of a deployment of a wireless communication network in a TSN system architecture;

Fig. 2 shows a signaling diagram illustrating a procedure related to propagation of a declaration message according to some examples of embodiments;

Fig. 3 shows a signaling diagram illustrating a further procedure related to propagation of a declaration message according to some examples of embodiments;

Fig. 4 shows a signaling diagram illustrating a further procedure related to propagation of a declaration message according to some examples of embodiments;

Fig. 5 shows a flow chart of a processing conducted in a network element or function acting as a TSN translator according to some examples of embodiments;

Fig. 6 shows a flow chart of a processing conducted in a network element or function acting as a core network element or function according to some examples of embodiments;

Fig. 7 shows a diagram of a network element or function representing a TSN translator according to some examples of embodiments; and

Fig. 8 shows a diagram of a network element or function representing a core network element or function according to some examples of embodiments. DESCRIPTION OF EMBODIMENTS

In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3^rd generation (3G) like the Universal Mobile Telecommunications System (UMTS), fourth generation (4G) communication networks or enhanced communication networks based e.g. on Long Term Evolution (LTE) or Long Term Evolution-Advanced (LTE-A), fifth generation (5G) communication networks, cellular 2^nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolution (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), Bluetooth or Worldwide Interoperability for Microwave Access (WiMAX), took place all over the world. Various organizations, such as the European Telecommunications Standards Institute (ETSI), the 3^rd Generation Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3^rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers), the WiMAX Forum and the like are working on standards or specifications for telecommunication network and access environments.

Basically, for properly establishing and handling a communication between two or more end points (e.g. communication stations or elements, such as terminal devices, user equipments (UEs), or other communication network elements, a database, a server, host etc.), one or more network elements or functions (e.g. virtualized network functions), such as communication network control elements or functions, for example access network elements like access points, radio base stations, relay stations, eNBs, gNBs etc., and core network elements or functions, for example control nodes, support nodes, service nodes, gateways, user plane functions, access and mobility functions etc., may be involved, which may belong to one communication network system or different communication network systems. New communication systems, such as the 5G System (5GS), are developed in order to support new business models such as those for loT and enterprise managed networks. Services such as unmanned aerial vehicle control, augmented reality, and factory automation are intended to be provided. Network flexibility enhancements support self- contained enterprise networks, installed and maintained by network operators while being managed by the enterprise. Enhanced connection modes and evolved security facilitate support of massive loT, expected to include tens of millions of UEs sending and receiving data over the 5G network.

As indicated above, one use case is factory automation which is also referred to as vertical industries (i.e. Industry 4.0). Vertical industries are related to e.g. discrete automation, process automation, and intelligent transport systems in industrial factories or the like. Design principles concern several aspects, such as, for example, interconnection, i.e. the ability of machines, devices, sensors, and people to connect and communicate with each other via loT, information transparency, i.e. the provision of operators with useful information needed to make appropriate decisions from all points in the manufacturing process, technical assistance, i.e. the ability of assistance systems to support humans by aggregating and visualizing information comprehensively for making informed decisions and solving urgent problems on short notice, and the ability of cyber physical systems to physically support humans by conducting a range of tasks, and decentralized decisions, i.e. the ability of cyber physical systems to make decisions on their own and to perform their tasks as autonomously as possible.

Cyber-physical systems are to be understood as systems that include engineered, interacting networks of physical and computational components. Cyber-physical control applications are to be understood as applications that control physical processes. Cyber physical control applications in automation follow certain activity patterns, which are open-loop control, closed-loop control, sequence control, and batch control

Communication services supporting cyber-physical control applications need to be ultra reliable, dependable with a high communication service availability, and often require low or (in some cases) very low end-to-end latency. Communication in automation in vertical domains follows certain communication patterns. One example for such a communication pattern is a periodic deterministic communication. As described above, communication systems employed in applications like vertical industries have to fulfill certain requirements, such as high communication service availability and low end-to-end latency. In order to provide such capabilities, mechanisms for Time Sensitive Networking (TSN) as defined by IEEE are integrated with 5GS. TSN is currently standardized as the mechanism for communication within industrial networks. A set of IEEE 802.1 protocols (IEEE 802.1AS-Rev, 802.1CB, 802.1Qcc, 802.1Qch, 802.1Qci, 802.1Qcj, 802.1 CM, 802.1Qcp, 802.1Qcr, 802.1AB) is applied to achieve deterministic data transmission.

That is, TSN (or Time Sensitive Communication (TSC)) refer to a communication service that supports deterministic communication and/or isochronous communication with high reliability and availability. It is about providing packet transport with bounds on latency, loss, packet delay variation (jitter), and reliability, where end systems and relay/transmit nodes can be strictly synchronized.

Currently, in industries, TSN is used as a mechanism to provide end to end connectivity with deterministic capacity and delay. The talkers (e.g., sensors, controllers) and listeners (e.g. controllers, actuators) are connected through bridges using fixed connection lines, such as cables.

TSN proposes three configuration models, i.e. fully centralized, distributed and hybrid (distributed user centralized network). In the centralized approach, TSN has a centralized entity, named CNC (Centralized Network Controller or Centralized Network Configuration ), which collects the requirements of end to end communication between the Talker End Stations and Listener End Stations and performs scheduling centrally. Bridges learn the connection information for their immediate network peer in each physical port using link layer related data, such as, for example, using the link layer discovery protocol (LLDP). The CNC calculates schedules, paths etc. in order to fulfil the stream QoS requirements, and it provides the schedule to each bridge using respective bridge managed objects.

On the other hand, in the distributed TSN approach, bridges conduct self-management, i.e. control by a centralized entity is not provided. It is to be noted that the bridges are time-aware in a TSN network. There may be one or more bridges between a talker end station and a respective listener end station. In the following, some examples are based on the assumption that two bridges are provided between talker and listener, but other examples and configurations are also applicable, e.g. where only one bridge or three or more bridges are involved. Each talker end station may talk to one or more listener end stations, and each listener end station may listen to one or more talker end stations. A listener end station of one communication may be a talker end station of another communication.

In a main target scenario, the tactile industrial network, also known as Industrial loT (NoT) or Industry 4.0 networks, 3GPP technologies are applied in addition to wired time sensitive networking (TSN) in industrial environments to provide flexibility (in terms of mobility) and scalability (in terms of number of sensors or actuators).

The introduction of wireless devices provides more flexibility, cost effectiveness and scalability in the system, but requires for example a wireless network as defined by 3GPP to provide predictable QoS for the communication. TSN and 3GPP networks are developed and standardized as two disjoint domains which are managed independently.

For implementing the 5GS part into TSN, an approach can be used in which the 5GS appears as a TSN bridge. Basically, 5GS overall adopts a QoS framework where applications request QoS properties that the 5GS then meets using 5G QoS framework. When the 5GS appears as a TSN bridge, the 5G system receives TSN related reservation requests using the known 5G QoS framework. The 5G system then uses 5G internal signaling to satisfy the TSN reservation request.

For example, there are three TSN configuration models, i.e. a so called fully centralized model, a distributed model and distributed user centralized network model, which can be supported e.g. by 5GS.

End of 2018, 3GPP has finalized studies on 5GS Enhanced support of vertical and LAN Services (SA2 TR 23.734) which selects the option for integration of 3GPP and TSN called bridge model (black box) as a baseline for 3GPP normative work. During year 2019, the 3GPP has conducted the normative work for Release 16 regarding the 5GS support of TSN, where the fully centralized configuration model and scheduled traffic (time-aware scheduling) of TSN has been considered, and the 5GS support for this model has been described in TS 23.501.

Furthermore, the 5GS support of TSN fully distributed configuration model has been discussed and included in requirements specification (TS 22.104). Additionally, discussion for introducing the fully distributed model is made. However, due to resource constraints in 3GPP, the introduction of fully distributed model is not yet completed.

For a distributed configuration model, SRP (Stream Reservation Protocol) is utilized in TSN. The IEEE has specified the SRP (see IEEE 802.1Q-2018: Clause 35) and Multiple Stream Registration Protocol (MSRP) (see IEEE 802.1Q-2018: Clause 35.1).

SRP utilizes three signalling protocols, i.e. MMRP, MVRP and MSRP, in order to establish stream reservations across a bridged network. While MMRP and MVRP are mainly used to control the propagation of end station declarations, MSRP is a signalling protocol that enables the reservation of network resources that will guarantee the transmission and reception of data streams across a network with the requested QoS.

SRP implements admission control and defines the concept of streams at L2. Also provided is a mechanism for end-to-end management of the streams' resources, to guarantee QoS. Listeners indicate what streams are to be received, Talkers announce the streams that can be supplied by a bridged entity. From these primitives the resources are allocated and configured in both the end nodes of the data stream and the transit nodes along the data streams' path. An end-to-end signaling mechanism to detect the success/failure of the effort is also provided.

SRP is used for a distributed configuration model, as described above. It is to be noted that MMRP and MVRP are either optionally used or can be circumvented by using a network management tool and pre-configuration of network entities. Thus, the MSRP represents a fundamental part of the SRP and realization of the fully distributed model.

It is to be noted that also other standards are to be considered. For example, currently, IEEE specifies two amendments to the IEEE 802.1Q standard. These include IEEE 802.1CS (Link-Local Reservation Protocol) and IEEE 802.1Qdd (Resource Reservation Protocol). The link-local registration protocol may replace the Multiple Registration Protocol (MRP) and allow for the exchange of larger databases. MSRP is an application running over MRP. For industrial networks utilizing the fully distributed model, MRP may be replaced by the Resource Reservation Protocol as specified in IEEE 802.1Qdd, which is an application running over LRP. However, the Resource Reservation Protocol (RRP) may extend the MSRP.

Using MSRP, the stream source end station (Talkers) indicates stream requirements before transmitting the actual stream data. Such requirements are indicated to the network by using so called “Talker Advertise” declarations (also referred to hereinafter as talker declaration). In this declaration, a worst-case latency indicator is provided. The Talker Advertise declaration is propagated by bridges on the path towards potential Listeners as long as the stream requirements can be met by individual bridges. During the propagation of Talker advertise declarations, the accumulated latency is updated at each hop/bridge. In such way, Listeners can have the information about the worst-case latency. The Listener can use this information to decide if the latency is too large for acceptable reception of the stream.

For example, the accumulated latency grows by the portTcMaxLatency value for the bridge, which represents the worst-case latency that the bridge could add to the total packet latency. The portTcMaxLatency. per hop is equal to the sum of the following: a) (equal or higher priority traffic) the time required to empty the queue in which frames of that priority are placed, if that queue and all higher priority queues are full; b) (lower priority traffic) the time required to transfer one lower priority frame of maximum size that could have just started transmitting as the current priority frame was queued up; c) (internal processing) the worst-case time required by the Bridge to transfer a received frame from the input port to the output queue; d) (wire propagation time) the time required for the first bit of the frame to propagate from the output port to the receiving device; e) (media access delay) the time required to wait for the media to become available for transmission.

Listeners receiving Talker Advertise declarations and willing to receive the stream data send back a specific message, i.e. a “Listener Ready” declaration (also referred to hereinafter as listener declaration) to the Talker. During the propagation of this message the bridges reserve the resources needed to deliver the stream data. When the Talker receives a Listener Ready declaration, it starts transmitting the stream.

It is to be noted that there are also defined additional attributes in SRP messages which provide an optional mechanism to Talkers and Listeners to define their requirements towards the network, i.e. UserToNetworkRequirements attribute. Such an attribute can be used to express the requirements on maximum latency that the T alker and/or Listener require for a particular stream. The maximum latency specified by a Talker applies for all Listeners of that stream, whereas the maximum latency specified by Listener applies solely to that Listener. The Bridges can compare the max latency requirements with an indication of the latency being accumulated so far on the transmission path (i.e. from the end station via other hops/bridges), which is also referred to as the AccumulatedLatency indicated in the declaration message. Such comparison is done separately for Listener and Talker. In the case that AccumulatedLatency exceeds the maximum latency of the Talker, the bridge changes the Talker Advertise to a failure message also referred to as “Talker Failed” declaration (for example, a failure code 21 (max latency exceeded) can be provided). It is to be noted that a similar comparison is done for Listeners.

When integrating a wireless communication network, such as a 3GPP based network, into a TSN network structure, the wireless communication network shall be transparently integrated with a TSN network. In other words, the TSN networks assumes the wireless network part as being just one further bridge, which means that the 3GPP network is modeled as a TSN bridge (further also referred to as ‘3GPP bridge’ or 5GS Bridge). The TSN network can interact with this bridge in a manner as defined e.g. in IEEE 802.1Q specifications. Thus, the 3GPP network provides wireless connectivity service to the TSN network in a transparent way.

However, as indicated above, for the 5GS integration with TSN in a fully distributed configuration model it is necessary that the 5GS bridge is adapted for self-management. This comprises the support for SRP, reservation of bandwidth required for streams, updating the messages sent by Talker and Listener, etc. For example, as described above, when using SRP, the end station behaving as a Talker sends “Talker Advertise” declaration in order to inform about the stream(s) it can provide. Bridges, including the 5GS Bridge, have to propagate such a message through the network and update the field that indicates the accumulated latency. The Listener interested in receiving the stream with given characteristics (including the accumulated latency) will send back the declaration message towards the Talker.

However, in addition to adding the communication network caused delay to MSRP messages while being transmitted by the bridge (e.g. a 5GS bridge), also signalling procedures within the communication network such as a 5GS have to be established in order to realize this. In other words, the internal procedures and signalling between communication network for supporting a TSN fully distributed configuration model have to be provided. In particular, the following needs to be defined:

- Which entity (e.g. a translator element or function, such as a UE/DS-TT, UPF/NW- TT, or core network element or function, such as a SMF, PCF) participates in the MSRP message processing, and which information relevant for communication network, e.g. a 5GS, needs to be extracted from MSRP messages, i.e. which information from MSRP relates to requirements towards 5GS bridge

- To which entities the extracted information needs to be communicated and how

- Which actions/procedures (and by which entities) are to be performed within 5GS in order to fulfil the requirements related to the stream.

In the following, different exemplifying embodiments will be described using, as an example of a communication network to which examples of embodiments may be applied, a communication network architecture based on 3GPP standards for a communication network, such as a 5G/NR, without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communication networks where mobile communication principles are integrated with TSN communications, e.g. Wi-Fi, worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad-hoc networks (MANETs), wired access, etc.. Furthermore, without loss of generality, the description of some examples of embodiments is related to a mobile communication network, but principles of the disclosure can be extended and applied to any other type of communication network, such as a wired communication network. The following examples and embodiments are to be understood only as illustrative examples. Although the specification may refer to “an”, “one”, or “some” example(s) or embodiment(s) in several locations, this does not necessarily mean that each such reference is related to the same example(s) or embodiment(s), or that the feature only applies to a single example or embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, terms like “comprising” and “including” should be understood as not limiting the described embodiments to consist of only those features that have been mentioned; such examples and embodiments may also contain features, structures, units, modules etc. that have not been specifically mentioned.

A basic system architecture of a (tele)communication network including a mobile communication system where some examples of embodiments are applicable may include an architecture of one or more communication networks including wireless access network subsystem(s) and core network(s). Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station (BS), an access point (AP), a NodeB (NB), an eNB or a gNB, a distributed or a centralized unit, which controls a respective coverage area or cell(s) and with which one or more communication stations such as communication elements, user devices or terminal devices, like a UE, or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a station, an element, a function or an application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels via one or more communication beams for transmitting several types of data in a plurality of access domains. Furthermore, core network elements or network functions, such as gateway network elements/functions, mobility management entities, a mobile switching center, servers, databases and the like may be included.

The general functions and interconnections of the described elements and functions, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for a communication to or from an element, function or application, like a communication endpoint, a communication network control element, such as a server, a gateway, a radio network controller, and other elements of the same or other communication networks besides those described in detail herein below.

A communication network architecture as being considered in examples of embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet. The communication network may also be able to support the usage of cloud services for virtual network elements or functions thereof, wherein it is to be noted that the virtual network part of the telecommunication network can also be provided by non-cloud resources, e.g. an internal network or the like. It should be appreciated that network elements of an access system, of a core network etc., and/or respective functionalities may be implemented by using any node, host, server, access node or entity etc. being suitable for such a usage. Generally, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

Furthermore, a network element, such as communication elements, like a UE, a terminal device, control elements or functions, such as access network elements, like a base station (BS), an gNB, a radio network controller, a core network control element or function, such as a gateway element, or other network elements or functions, as described herein, and any other elements, functions or applications may be implemented by software, e.g. by a computer program product for a computer, and/or by hardware. For executing their respective processing, correspondingly used devices, nodes, functions or network elements may include several means, modules, units, components, etc. (not shown) which are required for control, processing and/or communication/signaling functionality. Such means, modules, units and components may include, for example, one or more processors or processor units including one or more processing portions for executing instructions and/or programs and/or for processing data, storage or memory units or means for storing instructions, programs and/or data, for serving as a work area of the processor or processing portion and the like (e.g. ROM, RAM, EEPROM, and the like), input or interface means for inputting data and instructions by software (e.g. floppy disc, CD-ROM, EEPROM, and the like), a user interface for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like), other interface or means for establishing links and/or connections under the control of the processor unit or portion (e.g. wired and wireless interface means, radio interface means including e.g. an antenna unit or the like, means for forming a radio communication part etc.) and the like, wherein respective means forming an interface, such as a radio communication part, can be also located on a remote site (e.g. a radio head or a radio station etc.). It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.

It should be appreciated that according to some examples, a so-called “liquid” or flexible network concept may be employed where the operations and functionalities of a network element, a network function, or of another entity of the network, may be performed in different entities or functions, such as in a node, host or server, in a flexible manner. In other words, a “division of labor” between involved network elements, functions or entities may vary case by case.

According to some examples of embodiments, measures for integrating a wireless communication system based, for example, on 3GPP standard, into a TSN or other Ethernet based system are described, wherein the TSN or other Ethernet based system uses in particular a distributed configuration as described above.

In order to support TSN, 3GPP has introduced a so-called translator function on device and network side (also referred to as DS-TT and NW-TT, respectively) which perform protocol translation and adaptation. By using MSRP, reservation of network resources that will guarantee the transmission and reception of data streams across a network with the requested QoS can be achieved. The current IEEE specification IEEE 802.1Q on MSRP provides a solid foundation in order to begin the work in 3GPP regarding the 5GS support of TSN distributed configuration model.

Fig. 1 shows a diagram illustrating an example of a system architecture for integrating a communication network part forming a TSN bridge into a TSN environment. Basically, according to Fig. 1 , a TSN system A and a TSN system C represent potential parties of a communication via a TSN based communication, i.e. by means of a time sensitive communication link. The TSN system may comprise one or more bridges, wherein Fig. 1 shows one TSN bridge B, wherein the TSN bridge B includes a wireless communication network part using a wireless communication services based on 3GPP technologies, such as a 5GS based network. For linking the TSN bridge B (formed by the wireless communication network) to the other parts A and B of the TSN system, such as an end station or another bridge, TSN translators (DS-TT 100) and NW-TT 90 are introduced as a functionality to integrate the wireless communication network into the TSN network domain in a transparent manner. In other words, to the TSN network, the wireless communication service of the wireless communication network acts like any other TSN bridge, while the TSN network acts as e.g. a data network to the wireless communication network.

It is to be noted that the network-side TSN translator (NW-TT) and the device-side TSN translator (DS-TT), which are responsible for translation between TSN and 3GPP domains, can also be seen as representing a respective translator element or function and a translator client element or function.

The TSN bridge part B, which is the 5GS part being linked to the TSN systems A and C as a TSN bridge, comprises several network elements or functions which can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. a cloud infrastructure. Specifically, as shown in Fig. 1, in the 5GS, protocols and reference points are defined for network functions (NF) and reference points connecting NFs.

As shown in Fig. 1, a communication element such as a UE 10 is connected to a RAN or access network (AN) 20 and to an access and mobility function (AMF) 50. The UE 10 is also connected to the DS-TT element 100 which forms together with the UE 10 the device side bridge towards the TSN system C, for example. The UE 10 represents either an ingress point (UL communication direction) or an egress point (DL communication direction) for the TSN based communication. The RAN 20 represents a base station (BS or NB) using a NR RAT and/or an evolved LTE base station, while AN 20 is a general base station including e.g. non-3GPP access, e.g., Wi-Fi.

The core network architecture shown in Fig. 2 applied for a 5GS network comprises various NFs. As shown in Fig. 1 , the CN NFs comprises the AMF 50, a session management function (SMF) 40, a policy control function (PCF) 60, a network exposure function, a user data management (UDM) 80, and one or more user plane function(s) (UPF) 30.

The AMF 50 provides UE-based authentication, authorization, mobility management, etc. A UE (e.g. UE 10) even using multiple access technologies is basically connected to a single AMF because the AMF 50 is independent of the access technologies.

The SMF 40 sets up and manages sessions according to network policy. The SMF 40 is responsible, for example, for session management and allocates IP addresses to UEs. Furthermore, it selects and controls the UPF 30 for data transfer.

It is to be noted that it is also possible that in case the UE 10 has e.g. multiple sessions (communication connections), different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session.

The UPF 30 can be deployed in various configurations and locations, according to the service type. Functions of the UPF 30 are e.g. QoS handling for user plane, packet routing and forwarding, packet inspection and policy rule enforcement, traffic accounting and reporting.

The PCF 60 provides a policy framework incorporating network slicing, roaming and mobility management, similar to a policy and charging rules function in a 4G network.

The UDM 80 stores and provides subscription data of the UE 10, similar to an home subscriber server (HSS) in 4G networks, and also network slice specific information.

The NEF 70 is used for exposing network capabilities and events to an AF. Furthermore, NW-TT 90 (provided in connection with the UPF 30) and a TSN application function (AF) 95 are provided which act as TSN translator functions to and from the TSN system A (AF 90 for control plane (CP) signaling, NW-TT 95 for user plane (UP) signaling). Basically, the NW-TT 90 and AF 95 provide information on the packet flow to the PCF 60 in order to support QoS. Based on the information, the PCF 60 determines policies about mobility and session management to make the AMF 50 and the SMF 40 operate properly.

In the configuration according to Fig. 1, the NW-TT 90 and the TSN AF 95 form the network side bridge towards the TSN system A. Thus, the NW-TT 90 and the TSN AF 95 represent either an ingress point (DL communication direction) or an egress point (UL communication direction) for the TSN based communication.

As shown in Fig. 1 , the NFs are connected by means of so-called reference points (N1 to N33). This representation of reference points N1 to N33 is used for illustrating how data flows are developed. For example, N1 is defined to carry signaling between the UE 10 and the AMF 50. The reference point for connecting between the RAN/AN 20 and the AMF 50 is defined as N2, and the reference point between RAN/AN 20 and the UPF 30 is defined as N3. A reference point N 11 is defined between the AMF 50 and the SMF 40 so that SMF 40 is controllable by the AMF 50. Reference point N4 is used by the SMF 40 and the UPF 30 so that the UPF 30 can be set using the control signal generated by the SMF 40, and the UPF 30 can report its state to the SMF 40. Reference point N9 is the reference point for the connection between different UPFs. Reference point N7 is defined for connecting the PCF 60 to the SMF 40, so that the PCF 60 can apply policy to the SMF40. Reference points N8 and N10 are defined because the subscription data of the UE 10 is required for the AMF 50 and the SMF 40, respectively. Reference point N5 is defined for connecting between the TSN AF 95 and the PCF 60. Reference point N33 is for connecting between the NEF 70 and the AF 95.

For the transparent usage of the wireless connection service and to hide specific behavior of the 3GPP network to the TSN network and vice versa, the TT (DS-TT, NW- TT) functions are used which work as a respective intermediator between both domains, i.e. they understand the TSN protocol and maps the TSN network messages into control and user plane messages of the 3GPP network to trigger corresponding actions in the 3GPP network, e.g. to trigger the establishment of a wireless connection with guaranteed QoS, and vice versa. Furthermore, the TT functions take care of services like the enforcement of priority classes for the traffic, frame translation, gate schedules etc. which are typically offered by the bridges in the wired network to guarantee deterministic communication.

It is to be noted that the TSN systems A and C may be, for example, a sensor, controller, actuator or any other industrial device. Furthermore, the UE 10, which is shown in Fig. 1 as a separate entity, may be integrated in an end station or may be plugged into an end station.

As indicated above, in a configuration as shown in Fig. 1, DS-TT 100 and NW-TT 90, 95 work as a respective intermediator between both domains, i.e. , the TT functions understands the TSN protocol and the 3GPP protocols and maps the TSN commands and messages into corresponding actions and messages in a 3GPP network providing 5G and vice versa.

According to some examples, two key types of information messages are differentiated by the TSN Translator:

1) The network configuration related messages of the TSN network will be denoted in the following by the term control plane (CP) in order to be consistent with the naming convention of mobile network terminology. The CP messages, e.g. LLDP messages are converted into the corresponding control plane messages and procedures in a 3GPP network. The control plane messages and procedures are used to establish for example a packet data unit (PDU) session or a service flow (QoS flow) and to provide for example required QoS parameters for the service flow within the PDU session. The TT function has an interface to respective 3GPP functional entities of the core network (CN), e.g. PCF of a 5G network, which interacts directly or indirectly with further 3GPP CN functional entities like SMF and AMF. The TT function acts from the 3GPP network point of view e.g. as an application function (AF). In addition, the TT function derives information to act as a TSN bridge in the TSN network. A typical example is the LLDP required at a TSN bridge to be interoperable with the TSN network.

Alternatively, or additionally, other options may be used to interact between 3GPP CN and TT function. For example, according to examples of embodiments, the TT function provides an interface to the NEF when authentication and authorization features are needed.

2) For the transmission of data between the TSN systems A and C, the TT function has an interface to the UPF and a connection to the TSN system, which is denoted in the following by the term user plane (UP), again to align with the terminology applied in 3GPP networks. The UP of the TT function may act as a data network to the 3GPP network. On the other side, for an adjacent TSN system (e.g. a bridge or a TSN End Station), it looks like a TSN bridge. With respect to the user plane functionality, according to some examples of embodiments, the TT function offers among others the following functions: a. Removes the header information from frames or packets received at UPF and create the corresponding TSN frame or packet b. Maps the frames or packets received in a particular PDU session to the packets to be transmitted from the corresponding egress port c. Depending on the QoS flow of the given PDU session, place the frame or packet in the corresponding priority queue of a specific port d. Based on a gate control list, it shall transmit the frames or packets from one of the different queues through the egress port. The gate control list specifies at which time interval a frame or packet from a specified priority queue can be transmitted at a particular egress port. e. If the frame or packet arrives delayed such that the gate control for this frame or packet in the current interval is already closed, then this frame or packet shall be dropped and not transmitted. f. Shall introduce guard band between the transmission intervals g. Shall pre-empt the Ethernet frames or packets, which started its transmission in the previous time interval, in order to make the port be available for the frames or packets scheduled to be transmitted at the current time interval

Similar translation shall be performed when the TSN frames or packets arrive at the TT ingress ports. The priority queues shall be implemented at the translator or the translator client or both. The UP part of the TT function is realized either as: a. UPF with extended TSN functionality: In this case, both UPF and TSN T ranslator UP are within a single box and intermediation between the UPF protocol and the TSN protocol is performed internally or b. UPF and TSN translator UP act as two separate entities: In this case, interface between them may be a proprietary interface or the N6 interface as defined by 3GPP is extended to support the TSN capabilities

The following functions are provided by the TT function (DS-TT 100 and NW-TT 90) together with the 3GPP network to achieve transparent integration in the TSN network:

1. The DS-TT 100 and NW-TT 90 are enabled to initiate PDU sessions and QoS flows with a set of pre-defined QoS parameter, e.g. 5G QoS indicator (5QI), in the 3GPP network, which are used to exchange information between DS-TT 100 and NW-TT 90. The PDU sessions and respective QoS flows are used to transport information between the DS-TT 100 and NW-TT 90, and between the TSN systems A and C, for example.

2. The UE 10 connected to the DS-TT 100 establishes the wireless connection to the 3GPP CN domain, based on standardized 3GPP authentication and authorization procedures. The DS-TT 100, which is connected to the UE 10 may provide additional credentials allowing to check if the UE 10 and DS-TT 100 together are authorized to establish a wireless connection. Optionally, the DS-TT 100 provides further credentials of the connected TSN system C that is added to the credentials.

3. The 3GPP network allows to establish additional PDU sessions and QoS flows for existing and/or the new PDU sessions with a set of pre-defined QoS parameter (e.g. 5QI), which is controlled by the PCF, optionally considering information provided by the TT functions (DS-TT 100 and NW-TT 90) on required minimum or average throughput, traffic pattern (e.g. cyclic data), maximum or average allowed packet loss, maximum or average latency, and jitter. As an example, a typical PDU session would define a maximum delay (10ms) and further information, which needs to be guaranteed with high probability (99.999%) and minimum guaranteed bit rate (less than 1Mbps). The information may be derived from information provided by the TSN network. 4. The DS-TT 100 and NW-TT 90 support the Link Layer Discovery Protocol (LLDP) and participates in a network discovery procedure. The PDU session and the QoS flow represent the connection between the UE 10 and the UPF. This information is mapped toTSN bridge managed object’s (BMO) parameters, which may then be reported by the TT function.

5. The TT functions (DS-TT 100 and NW-TT 90) have at least one of the following functions:

[1] Mapping of control plane information from the TSN network and the TSN end stations to 3GPP control plane information;

[2] Mapping of control plane information from the TSN network and the TSN end stations to information exchanged between DS-TT 100 and NW-TT 90;

[3] Mapping of control plane information from the 3GPP network to information exchanged between DS-TT 100 and NW-TT 90, and TSN network and the TSN end stations;

[4] Handling of TSN user plane, including scheduled gating at the egress port;

[5] Handling of Time Synchronization in the TSN network;

[6] Access control for TSN end station.

6. The 3GPP network may provide multiple PDU sessions for the UE 10 connected to the TT function (DS-TT 100) to realize at least one wireless connection in the 3GPP network. Each PDU session may contain multiple QoS flows with a defined set of QoS parameters for each. The DS-TT 100 and NW-TT 90 maps each QoS session and its QoS parameters to TSN Bridge managed object’s (BMO) parameters.

As described above, according to some examples of embodiments, for integrating the wireless communication system (in the following, a 3GPP and specifically a 5G based network is assumed) a TSN (or Ethernet based) system including a distributed configuration as described above, it is necessary to support SRP in the 5GS bridge shown e.g. in Fig. 1, in order to enable the propagation of Talker/Listener declarations within the 5G network as well as the adequate resource management within 5GS. That is, according to examples of embodiments, measures are provided which allow to control the propagation of messages, such as Talker and Listener declarations as well as actual stream data transmission through the 5GS Bridge so as to enable the establishment of required TSN streams between Talker(s) and Listener(s) while minimizing the amount of resources used within 5GS. For this purpose, for example, PDU sessions and QoS flows suitable for the propagation of Talker and Listener declarations are established, wherein corresponding ports within the 5GS bridge are (pre-)configured in a way to allow forwarding of declarations with selected destination addresses, and to enable back-propagation of declarations from Listener(s). Moreover, failure indications such as “Talker Failed” or “Listener Failed” messages, e.g. in case an accumulated latency exceeds defined thresholds, are processed.

Furthermore, a value for latency that is to be added to the AccumulatedLatency field in the Talker Advertise declaration message to be propagated towards the Listener is estimated. In this connection, the possibility of the 5GS to set up different QoS flows with different QoS characteristics including guaranteed latency as well as the fact that the resulting accumulated latency is one of the deciding factors for the final stream setup between Talker and Listener(s) are considered.

The DS-TT 100 and NW-TT 90 allow to conduct a control enabling the transmission of a data stream between the Talker(s) and the Listener(s) wherein self-management of the 5GS Bridge according to the TSN distributed configuration model is possible.

In the example shown in Fig. 1, the DS-TT 100 and NW-TT 90 enable the support of SRP and the distributed TSN configuration model by a 5GS acting as a TSN Bridge (“5GS Bridge”). It is to be noted that also other parts of the communication network can be used for accommodating corresponding function, at least in part, such as a core network element or function, the UE or the like.

Basically, according to examples of embodiments, the following functionalities 1 to 4 are comprised within the DS-TT 100 and NW-TT 90:

1. Bridge resource management and ports configurations. By means of this, it is possible to use a minimal amount of resources of the wireless communication network for propagation of e.g. SRP declarations through the 5GS Bridge. In detail, this comprises a control of the distribution of declaration messages (e.g. Talker Advertise declarations) in such a way that they are only forwarded on a selected set of egress ports. By means of this, it is prevented that Talker Advertise or Listener Ready declarations are propagated on all ports of 5GS bridge. That is, the 5GS Bridge is configured by the DS-TT 100 and NW-TT 90 to allow the propagation of e.g. Talker and Listener declarations on ingress/egress port pair(s) which are needed to transmit frames or packets between identified Talker(s) and Listener(s).

Furthermore, the connectivity within the 5GS bridge is enabled such that the propagation of SRP declarations between Talkers and Listeners can be done at corresponding (ingress, egress) port pairs. This implies, for example, an establishment or modification of at least one PDU session per UE (UE 10) to which the Talker(s) (and/or Listener(s)) is/are connected (it is to be noted that the PDU session models the port at the UE and the port at the corresponding UPF). Corresponding PDU sessions are to be used for propagation of SRP declarations between Listeners and Talkers connected to the respective ports (at UEs and UPF) of the 5GS bridge. Alternatively, an existing PDU session/QoS flow can be re-used, if already established, for a pair of TSN Translator functions on the network and UE side. It is to be noted that the PDU sessions used for transmission of SRP messages can simultaneously be used for transmission of other information, e.g. LLDP information, non-TSN user traffic, etc.

2. Calculation/estimation of suitable capabilities of 5GS Bridge to be declared during the SRP declaration propagation and included in the declaration messages (in other words a value representing the latency caused by the 5GS bridge which is to be added to the AccumulatedLatency field of the Talker declaration message, for example).

3. Setup or modification of PDU sessions/QoS flows with adequate QoS characteristics once the resources are actually required. For example, in some use cases, only when an acknowledgement from the Listener (i.e. a Listener Ready declaration, for example) to receive the Talker’s stream is propagated backward, the corresponding resources in the 5GS bridge are prepared. By means of this, resource pre-reservations are avoided.

4. Modification of existing PDU sessions/QoS flows (or alternatively setup of a different PDU session/QoS flow) within the 5GS Bridge on demand. For example, when stream transmissions with more demanding QoS requirements are detected, this allows for dynamically updating the Talker declaration messages to support such stream transmissions.

That is, a functionality is provided which enables, for example, the 5GS to handle SRP protocol used in distributed TSN configuration model in a way which optimizes the resource usage of 3GPP network while providing the performance required to support the TSN streams within 3GPP network. That is, self-management of 5GS Bridge according to the TSN distributed configuration model is enabled, considering TSN stream requirements as well as supporting procedures defined by the SRP, comprising handling of SRP procedures during the Talker declaration propagation, Listener declaration propagation as well as supporting the TSN stream transmission.

In the following, examples of embodiments are described in which a mechanism for stream reservation control in the communication network part (i.e. , for example, in the 5GS bridge B shown in Fig. 1) is described.

According to some examples of embodiments, it is defined which entity in 5GS is used to process incoming SRP messages (in the described example, in particular MSRP messages, as described above), such as UPF/NW-TT 90 and DS-TT 100.

Moreover, according to some examples of embodiments, it is defined which information needs to be extracted from a MSRP messages, i.e. which information is of relevance for the 5GS processing (for example, a difference between MaxLatency and Accumulated Latency parameter values from MSRP messages, priority or VLAN information, etc.).

Furthermore, according to some examples of embodiments, it is defined to which 5GS network functions such extracted information needs to be signalled (e.g. from UPF to SMF and PCF).

In addition, according to some examples of embodiments, it is defined how the extracted information is used, i.e. what procedures are performed within 5GS in order to fulfil the MSRP requirements at the 5GS bridge (for example, the PCF may trigger PDU session modification procedure in order to establish a QoS flow for extracted priority information/traffic class and the delay that 5GS bridge needs to support).

It is to be noted that in the following examples of embodiments, four relevant cases of MSRP handling at the 5GS are assumed for which the corresponding procedures at 5GS are identified. The four cases are as follows:

1. The Talker declaration is received at UE side of the 5GS bridge, i.e. by DS-TT 100.

2. The Listener declaration is received at UE side of the 5GS bridge, i.e. by DS-TT 100.

3. The Talker declaration is received at network side of the 5GS bridge, i.e. by UPF/NW- TT 90.

4. The Listener declaration is received at network side of the 5GS bridge, i.e. by UPF/NW-TT 90.

Depending on the cases 1 to 4 indicated above, the UPF/NW-TT 90 or DS-TT 100 is configured to perform at least one of the following actions:

1. Forward the received MSRP message towards the other side of the 5GS bridge (i.e. if DS-TT 100 receives the message it forwards it to UPF/NW-TT 90, and vice versa) for further processing

2. Extract, from MSRP messages, relevant information for the 5GS processing, modify the MSRP message accordingly (e.g. modify the type of message or the message parameters) and forward it to the other side of the 5GS bridge (i.e. if DS-TT 100 received the message it forwards it to UPF/NW-TT 90, and vice versa).

The relevant information for 5GS according to the IEEE standards [e.g. IEEE 802.1Q, IEEE802.1Qcc] comprises, for example, one or more of the following: a) Talker’s or Listener’s latency requirements for the stream transmission (UserToNetworkRequirements.MaxLatency), b) the latency that the stream would experience on the path to the 5GS Bridge (Accu m u I ated Laten cy) , c) Data Frame Priority, d) Rank, e) MaxFrameSize, f) StreamID (containing, for example, MAC address of the stream’s source and unique ID) etc.

3. Request establishment or modification of a suitable PDU session (i.e. such that the PDU session can fulfil QoS requirements of the stream) based on the information extracted and MSRP message modifications from 2. and the type of MSRP message received and/or forwarded. According to examples of embodiments, the following options can be applied: a) UE initiated PDU session establishment by UE/DS-TT 100 (as described in TS 23.502) either already after the reception of Talker Advertise message or only after the corresponding Listener Ready message is received. The required QoS characteristics of such PDU session/QoS flow are determined based on UE subscription information, policies at PCF and the extracted information from MSRP messages. b) Network triggered PDU session establishment or modification. In such case the TSN AF 95 triggers the UE/DS-TT 90 to establish/modify the PDU session (as described in TS 23.502 Section 4.13.2) based on the information extracted from MSRP messages signalled from UPF/NW-TT 90 via SMF 40 and PCF 60 or via NEF 70. The according QoS characteristics of such PDU session/QoS flow are determined based on UE subscription information, policies at PCF and the extracted information from MSRP messages.

For example, according to some examples of embodiments, considering the relevant information a) to f) as indicated above, according PDU session QoS characteristics can be derived. According to some examples, a mapping table can be configured which contains possible (or at least the set of likely) MSRP parameter combinations and maps each combination to a standardized 5QI value (e.g. according to TS 23.501, 5.7.4). As an illustrative example, the following mapping can be considered for individual 5GS QoS parameters, wherein also other mapping examples are possible:

I) information a) and b) indicated above can be used to derive “packet delay budget” (PDB) of the QoS flow;

II) information c) and d) indicated above can be used to derive “ARP (allocation and retention priority) level” and “Packet Error Rate” of the QoS flow; III) information e) can be used to derive “Maximum Data Burst Volume” of the QoS flow;

IV) information f), together with information c) and d), can be used to derive “RQA (Reflective QoS Attribute)” and also “ARP level”.

According to further examples of embodiments, the above described four main relevant cases 1 to 4 of MSRP handling at 5GS, for which the corresponding procedures at 5GS are identified, can be further broken down into sub-cases depending on the type of Talker and Listener declaration received.

For example, the following Talker declarations are defined by MSRP:

- Talker advertise (an advertisement for a stream that has not encountered any constraints along the network path)

- T alker failed (an advertisement of the stream that is not available to the listener due to constraints along the path)

Furthermore, the following Listener declarations are defined by MSRP:

- Listener ready (sufficient bandwidth and resources along the network path, one or more Listeners requesting the stream),

- Listener ready failed (at least one among the requesting listeners has sufficient bandwidth, but other may not have it); in this case an “earlier” bridge on the path received both ‘Listener Ready’ and ‘Listener Failed’ message for the same stream (from different Listeners) and it merged it to ‘Listener ready failed’ message.

- Listener asking failed (none of listeners is able to receive the stream due to bandwidth or resource allocation problems)

It is to be noted that the following examples of embodiments are applicable, basically, to each of the identified cases and sub-cases. For the sake of simplicity, 5GS procedures and involved entities for selected subsets of the identified cases are described in further detail; however, it is evident that corresponding procedures are also applicable for those subsets and other cases being not specified in detail.

Fig. 2 shows a signaling diagram illustrating a 5GS procedure related to propagation of a declaration message according to some examples of embodiments. Specifically, Fig. 2 is related to the above indicated case where a Talker Advertise declaration message is received by the DS-TT 100 from a Talker End Station on U E-side (from or via TSN system C, for example another bridge or the end station).

In S10, the TSN device (e.g., a Talker End Station in TSN system C or connected via TSN system C) sends an MSRP message (here: Talker Advertise message) to the UE- side DS-TT 100.

In S20, the UE/DS-TT 100 forwards the received Talker Advertise message to the UPF/NW-TT 90 using an already established (e.g. default) PDU session for transmission of MSRP messages (user plane forwarding). It is to be noted that it is assumed in the present example that such a default PDU session is established beforehand and is used for transmission of data between DT-TT 100 and NW-TT 90, such as management information in a transparent container (e.g. as defined in 3GPP TS 23.501).

In S30, the UPF/NW-TT 90 performs a processing of the MSRP message received in S20. For example, the processing includes identifying the message type (Talker Advertise in this case, indicating that there is an end station willing to transmit the stream with specified characteristics). Furthermore, the processing includes extracting 5GS relevant information from the MSRP message; for example, such relevant information comprises Talker’s latency requirements for the stream transmission (UserToNetworkRequirements.MaxLatency), the latency that the stream would experience on the path to the 5GS Bridge B (AccumulatedLatency), Data Frame Priority, Rank, MaxFrameSize, StreamID (containing e.g. a MAC address of the stream’s source and a unique ID). Corresponding information are indicated e.g. in IEEE 802.1Q, IEEE 802.1Qcc.

It is to be noted that as an alternative in the processing in S30, the NW-TT 90 derives also information relevant for updating the MSRP message, such as an amount of latency that needs to be added to the current value of the MSRP message’s AccumulatedLatency field (this addition represents the latency added by the 5GS bridge B).

In S40, the NW-TT 90 signals the extracted information to SMF 40 (which then can forward this extracted information to PCF 60 and the TSN AF 95, for example). In case the alternative processing in S30 is conducted (i.e. NW-TT derives information relevant for updating the MSRP message), the signaling in S40 comprises this this information towards the SMF 40 (and to the further control plane network functions indicated above).

In S50, the SMF 40 as an example of a core network element or function conducts a processing related to the propagation of the MSRP message in the 5GS bridge. In detail, according to one example, the SMF 40 derives, based on the extracted MSRP information received from the UPF 30 (i.e. the NW-TT 90), and based on UE subscription data at UDM and (operator) policies at the PCF, the information relevant for updating the MSRP message, such as amount of latency that needs to be added to the value of the MSRP message AccummulatedLatency field.

It is to be noted that with regard to the (operator) policies, the PCF may indicate (e.g. based on 3GPP TS 23.501 and TS 23.502) during the UE registration procedure, to the AMF the operator policies to be used at PDU Session Establishment. The SMF is responsible of checking whether the UE requests are compliant with the user subscription. For this purpose, it retrieves and requests to receive update notifications on SMF level subscription data from the UDM 80. Such data may indicate, for example, the allowed PDU Session Types and the default PDU Session Type, the allowed SSC (session and service continuity) modes and the default SSC mode, and QoS information, such as the subscribed Session-AMBR (aggregate maximum bit rate), default 5QI and default ARP.

Furthermore, according to an alternative processing, when the UPF/NW-TT already provides a proposal for the MSRP update (alternative indicated in connection with S30), the SMF 40 conducts a check of this proposal and either acknowledges it or determines an alternative setting (which is determined in accordance with the above described process in S50, for example)..

In S60, based on the extracted MSRP information received from the UPF/NW-TT and UE subscription data at UDM 80 and (operator) policies at PCF 60, the SMF 50 derives the according QoS characteristics of a PDU session/QoS flow that can fulfil the QoS as reported in the updated MSRP message (and therefore also the stream requirements).

It is to be noted that the processing of S50 and S60 does not impose a strict order of those operations. The operations performed in S50 and S60 are closely related to each other, so that it is necessary to consider a certain harmony therebetween; that is, parameters of updated MSRP messages need to be in line with the parameters of according QoS characteristics for PDU session/QoS flow.

In S70, the derived information of S50 is signaled to UPF 30 / NW-TT 90, which can use it to update the MSRP message. Alternatively, if the UPF 60 had already provided a proposal for the MSRP update (see alternatives in S30 and S50), the SMF 40, based on the check conducted by it, either acknowledges the proposal or provides an alternative.

In S80, the UPF/NW-TT, after updating the MSRP message according to information received in S70 (e.g. in view of adding a latency factor etc.), forwards the updated MSRP message (here the updated Talker Advertise message to the TSN device in DN (i.e. to TSN system A).

In S90, the SMF 40 signals the information derived in S60 to the TSN AF 95 (via PCF 60).

In S100, the TSN AF 95 executes on the basis of the information received in S90 (i.e. as derived by the SMF in S60) the according PDU session establishment/modification. The PDU session establishment/modification can either be UE initiated or network triggered. As a prerequisite, corresponding URSP rules at the UE may be updated by the PCF 60, as well as session management policies at the PCF 60 and subscription data at the UDM 80. In Fig. 2, an example is illustrated where the TSN AF 95 performs a network triggered PDU session establishment/modification based on the received information from S90. As indicated above, also a UE initiated PDU session establishment/modification can be executed in S100.

It is to be noted that S100 can be configured as being optional. Specifically, according to the MSRP procedures, the actual resource reservation is done only after a corresponding Listener Ready declaration is received by the TSN bridge (here 5GS bridge B). Therefore, S100 can be configured to be performed only after the corresponding Listener Ready message is received by the 5GS Bridge.

According to further examples of embodiments, the above described procedures related to the propagation of a declaration message according to Fig. 2 can be modified. For example, the processing of the MSRP message, which is executed in the above described example in S30 at the NW-TT 90, can already conducted at the DS-TT 100, e.g. before sending information to the NW-TT 90 in S20. That is, the information provided to the NW-TT 90 in S20 can then contain the updated MSRP message (e.g. by adding guaranteed latency to AccumulatedLatency).

Then, the NW-TT 90 (UPF), in case it has received already an updated MSRP message, it has only to forward this updated MSRP message without further processing it or performing additional operations.

Furthermore, it is to be noted that there are different options how to process the MSRP messages. For example, in case a higher processing power (i.e. a higher “intelligence”) is placed in one of the NW-TT or DS-TT elements or functions, this TT function is used for the MSRP message processing. In current scenarios, usually, the NW-TT 90 is provided with a higher “intelligence” and therefore also used for control.

According to further examples of embodiments, the NW-TT 90 can receive from the DS- TT 100 extracted 5G relevant information. In this case, the NW-TT 90 forward this information towards the core network entities (corresponding to S40).

Furthermore, instead of using the SMF 40 as a core network element or function for performing the processing in S50 and S60, also another core network element of function can be used, such as the PCF 60. That is, processing according to S40, S50, S60 and S90, for example, are to be linked with PCF 60 or another suitable core network element or functions.

Fig. 3 shows another signaling diagram illustrating a 5GS procedure related to propagation of a declaration message according to some examples of embodiments. Specifically, Fig. 3 is related to the above indicated case where a Listener Ready type of declaration message is received by the DS-TT 100 from a Listener End Station on UE- side (from or via TSN system C, for example another bridge or the end station). ln S310, the TSN device (e.g., a Listener End Station in TSN system C or connected via TSN system C) sends an MSRP message (here: Listener Ready message) to the UE- side DS-TT 100.

In S320, the UE/DS-TT 100 forwards the received Listener Ready message to the UPF/NW-TT 90 using an already established (e.g. default) PDU session for transmission of MSRP messages (user plane forwarding). It is to be noted that it is assumed in the present example that such a default PDU session is established beforehand and is used for transmission of data between DT-TT 100 and NW-TT 90, such as management information in a transparent container (e.g. as defined in 3GPP TS 23.501).

In S330, the UPF/NW-TT 90 performs a processing of the MSRP message received in S320. For example, the processing includes identifying the message type (Listener Ready in this case, indicating that there is sufficient bandwidth and resources along the network path, one or more Listeners requesting the stream). Furthermore, the processing includes extracting 5GS relevant information from the MSRP message; for example, such relevant information comprises Listener’s latency requirements for the stream transmission (UserToNetworkRequirements.MaxLatency), and StreamID (containing e.g. a MAC address of the stream’s source and a unique ID). Corresponding information are indicated e.g. in IEEE 802.1Q, IEEE 802.1Qcc.

It is to be noted that as an alternative in the processing in S330, the NW-TT 90 performs, from the extracted information, also a further processing, such as performing mapping between Listener Ready with a corresponding Talker Advertise (based on StreamID), identifying the port at which the Listener Ready declaration shall be forwarded, i.e. based on the information on the port that registered the Talker Advertise with the given StreamID, wherein corresponding processing is conducted e.g. only in case a corresponding check results in that UserToNetworkRequirements.MaxLatency can be fulfilled by the advertised stream.

In S340, the NW-TT 90 signals the extracted information to SMF 40 (which then can forward this extracted information to PCF 60 and the TSN AF 95, for example). In case the alternative processing in S330 is conducted (i.e. NW-TT derives information like the port information etc.) the signaling in S340 comprises this information towards the SMF 40 (and to the further control plane network functions indicated above, i.e. PCF, TSN AF etc.).

In S350, the SMF 40 as an example of a core network element or function conducts a processing for deriving information relevant for further handling and/or updating the MSRP message, such as performing the mapping between Listener Ready with the corresponding Talker Advertise (based on StreamID), identifying the port at which the Listener Ready declaration shall be forwarded i.e. only on the port that registered the Talker Advertise with the given StreamID, wherein corresponding processing is conducted e.g. only in case a corresponding check results in that UserToNetworkRequirements.MaxLatency can be fulfilled by the advertised stream

Furthermore, according to an alternative processing, when the UPF/NW-TT already performs this processing and provides corresponding information to the SMF (in S340), the SMF 40 conducts a check of this proposal and either acknowledges it or determines an alternative setting (which is determined in accordance with the above described process in S350, for example).

In S360, based on the derived information (e.g. received from the UPF/NW-TT) and UE subscription data at UDM 80 and (operator) policies at PCF 60, the SMF 50 derives the according QoS characteristics of a PDU session/QoS flow that fulfills the requested stream requirements.

In S370, the derived information of S350 is signaled to UPF 30 / NW-TT 90. Alternatively, if the UPF 60 had already provided a proposal (see alternatives in S330 and S350), the SMF 40, based on the check conducted by it, either acknowledges the proposal or provides an alternative.

In S380, the UPF/NW-TT sends the Listener Ready message according to instructions received in S370.

In S390, the SMF 40 signals the information derived in S360 to the TSN AF 95 (via PCF 60). ln S400, the TSN AF 95 executes on the basis of the information received in S390 (i.e. as derived by the SMF in S360) the according PDU session establishment/modification either as UE initiated or network triggered. As a prerequisite, corresponding URSP rules at the UE may be updated by the PCF 60, as well as session management policies at the PCF 60 and subscription data at the UDM 80. In Fig. 3, an example is illustrated where the TSN AF 95 performs a network triggered PDU session establishment/modification based on the received information from S90. As indicated above, also a UE initiated PDU session establishment/modification can be executed in S100.

It is to be noted that S100 can be configured as being optional. In case the PDU session establishment/modification has been already performed after the initial Talker Advertise is received (e.g. from a Talker in the DN, see also processing described in connection with Fig. 2) and the PDU session does not need to be further modified based on information received in S390 (i.e. as derived by the SMF in S360), S400 can be omitted.

As a further example of embodiments, a case can be considered where the Talker and the Listener are both on the same side, e.g. on the UE/DS-TT side of 5GS Bridge B (for example, two different UEs). This case represents a UE-to-UE communication case. In such a UE-to-UE communication case, two PDU sessions are required in order to transfer the data between Talker and Listener. Therefore, in addition to already established/modified PDU session (“uplink” session) after the Talker Advertise is received at UE/DS-TT side, once the corresponding Listener Ready is received at UE/DS-TT side, a further PDU session (“downlink” session) is established/modified in order to ensure connectivity between Talker and Listener both residing at the same side (e.g. the UE/DS-TT side) of the 5GS Bridge.

According to further examples of embodiments, the above described procedures related to the propagation of a declaration message according to Fig. 3 can be modified.

For example, the processing of the MSRP message, which is executed in the above described example in S330 at the NW-TT 90, can already conducted at the DS-TT 100, e.g. before sending information to the NW-TT 90 in S320. For example, the identification of message type, extraction of relevant information, mapping to corresponding Talker Advertise, identification of the port to which Listener Ready is derived by the DS-TT 100 and forwarded to the NW-TT 90. Based on this information, according UE triggered PDU session establishment/modification can be triggered.

Then, the NW-TT 90 (UPF), in case it has received already the processing results for the MSRP message, it has only to forward this information without further processing it or performing additional operations.

According to further examples of embodiments, the NW-TT 90 can receive from the DS- TT 100 extracted 5G relevant information. In this case, the NW-TT 90 forward this information towards the core network entities (corresponding to S340).

Furthermore, instead of using the SMF 40 as a core network element or function for performing the processing in S350 and S360, also another core network element of function can be used, such as the PCF 60. That is, processing according to S340, S350, S360 and S390, for example, are to be linked with PCF 60 or another suitable core network element or functions.

Fig. 4 shows a signaling diagram illustrating a 5GS procedure related to propagation of a declaration message according to some examples of embodiments. Specifically, Fig. 4 is related to above indicated case where a Talker Advertise declaration message is received by the NW-TT 90 from a Talker End Station on NW-side (from or via TSN system A, for example another bridge or the end station).

In S410, the TSN device (e.g., a Talker End Station in TSN system A or connected via TSN system A) sends an MSRP message (here: Talker Advertise message) to the NW- side NW-TT 90.

In S420, the UPF/NW-TT 90 performs a processing of the MSRP message received in S410. For example, the processing includes identifying the message type (Talker Advertise in this case, indicating that there is an end station willing to transmit the stream with specified characteristics). Furthermore, the processing includes extracting 5GS relevant information from the MSRP message; for example, such relevant information comprises Talker’s latency requirements for the stream transmission (UserToNetworkRequirements.MaxLatency), the latency that the stream would experience on the path to the 5GS Bridge B (AccumulatedLatency), Data Frame Priority, Rank, MaxFrameSize, StreamID (containing e.g. a MAC address of the stream’s source and a unique ID). Corresponding information are indicated e.g. in IEEE 802.1Q, IEEE 802.1Qcc.

It is to be noted that as an alternative in the processing in S420, the NW-TT 90 derives also information relevant for updating the MSRP message, such as an amount of latency that needs to be added to the current value of the MSRP message’s Accumulated Latency field (this addition represents the latency added by the 5GS bridge B).

In S430, the NW-TT 90 signals the extracted information to SMF 40 (which then can forward this extracted information to PCF 60 and the TSN AF 95, for example). In case the alternative processing in S320 is conducted (i.e. NW-TT derives information relevant for updating the MSRP message), the signaling in S430 comprises this this information towards the SMF 40 (and to the further control plane network functions indicated above).

In S440, the SMF 40 as an example of a core network element or function conducts a processing related to the propagation of the MSRP message in the 5GS bridge. In detail, according to one example, the SMF 40 derives, based on the extracted MSRP information received from the UPF 30 (i.e. the NW-TT 90), and based on UE subscription data at UDM and (operator) policies at the PCF, the information relevant for updating the MSRP message, such as amount of latency that needs to be added to the value of the MSRP message AccummulatedLatency field.

Furthermore, according to an alternative processing, when the UPF/NW-TT already provides a proposal for the MSRP update (alternative indicated in connection with S420), the SMF 40 conducts a check of this proposal and either acknowledges it or determines an alternative setting (which is determined in accordance with the above described process in S440, for example).

In S450, based on the extracted MSRP information received from the UPF/NW-TT and UE subscription data at UDM 80 and (operator) policies at PCF 60, the SMF 50 derives the according QoS characteristics of a PDU session/QoS flow that can fulfil the QoS as reported in the updated MSRP message (and therefore also the stream requirements). It is to be noted that the processing of S440 and S450 does not impose a strict order of those operations. The operations performed in S50 and S60 are closely related to each other, so that it is necessary to consider a certain harmony therebetween; that is, parameters of updated MSRP messages need to be in line with the parameters of according QoS characteristics for PDU session/QoS flow.

In S460, the derived information of S440 is signaled to UPF 30 / NW-TT 90, which can use it to update the MSRP message. Alternatively, if the UPF 60 had already provided a proposal for the MSRP update (see alternatives in S420 and S440), the SMF 40, based on the check conducted by it, either acknowledges the proposal or provides an alternative.

In S470, the UPF/NW-TT 90, after updating the MSRP message according to information received, forwards the updated Talker Advertise message to the UE/DS-TT 1000 using an already established (e.g. default) PDU session for transmission of MSRP messages (user plane forwarding). It is to be noted that it is assumed in the present example that such a default PDU session is established beforehand and is used for transmission of data between DT-TT 100 and NW-TT 90, such as management information in a transparent container (e.g. as defined in 3GPP TS 23.501).

In S480, the DS-TT 100 forwards the MSRP message to the connected TSN system A (i.e. , for example to a Listener End Station).

In S490, the SMF 40 signals the information derived in S450 to the TSN AF 95 (via PCF 60).

In S500, the TSN AF 95 executes on the basis of the information received in S490 (i.e. as derived by the SMF in S450) the according PDU session establishment/modification. The PDU session establishment/modification can either be UE initiated or network triggered. As a prerequisite, corresponding URSP rules at the UE may be updated by the PCF 60, as well as session management policies at the PCF 60 and subscription data at the UDM 80. In Fig. 4, an example is illustrated where the TSN AF 95 performs a network triggered PDU session establishment/modification based on the received information from S490. As indicated above, also a UE initiated PDU session establishment/modification can be executed in S500. It is to be noted that S500 can be configured as being optional. Specifically, according to the MSRP procedures, the actual resource reservation is done only after a corresponding Listener Ready declaration is received by the TSN bridge (here 5GS bridge B). Therefore, S500 can be configured to be performed only after the corresponding Listener Ready message is received by the 5GS Bridge.

According to further examples of embodiments, the above described procedures related to the propagation of a declaration message according to Fig. 4 can be modified.

For example, instead of using the SMF 40 as a core network element or function for performing the processing in S440 and S450, also another core network element of function can be used, such as the PCF 60. That is, processing according to S430, S440, S450 and S460, for example, are to be linked with PCF 60 or another suitable core network element or functions.

Fig. 5 shows a flow chart of a processing executed by a network element or function acting as a TT element or function. The TT element or function is used for a control processing according to examples of embodiments, as described above, so as to enable transmission of a data stream between at least one talker party and at least one listener party, According to examples of embodiments, the TT element or function to which the processing described in connection with Fig. 5 is applied is located in bridge element, is formed, for example, for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function represents one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system. The TT element or function is e.g. a network-side TT element or function and is connected to or part of a core network element or function of the wireless communication network, or the TT element or function is e.g. a device-side translator element or function connected to or part of the device forming a mobile terminal element or function or a user equipment element or function.

As also indicated above, the communication network is based on a 3GPP standard. However, also other communication standards can be used, according to other examples of embodiments. ln S510, a declaration message related to a stream reservation procedure (e.g. MSRP) between the at least one talker party and at least one listener party via the communication network forming the bridge element of a communication system (such as a TSN system) is received.

For example, according to examples of embodiments, receive the declaration message related to the stream reservation procedure between the at least one talker party and at least one listener party is received from a source located outside the bridge element of the communication system. This is represented, for example, in the example discussed in connection with Fig. 4. According to another example, the declaration message is received from a translator element or function of the bridge element of the communication system. This is represented, for example, in the examples discussed in connection with Figs. 2 and 3.

In S520, the declaration message is processed. The processing includes, for example, at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party,

According to some examples of embodiments, in the processing of the declaration message, one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message is identified as the type of the declaration message, It is to be noted that the kind of relevant information being extracted from the declaration message depends on the identified type of the declaration message (that is, there are different parameters required by the communication network for dealing with the corresponding declaration message; for example, a processing for a listener ready declaration message requires other (less) data than a processing of a talker advertise declaration message).

According to some examples of embodiments, in the processing of the declaration message, as the relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, different types of data are extracted. For example, at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream is extracted.

Furthermore, according to some examples of embodiments, in the processing of the declaration message, on the basis of the relevant information extracted from the declaration message, a further processing can be conducted which is related to at least one of updating and handling the declaration message for forwarding it to a target. For example, as the further processing, at least one of determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target is executed. This corresponds to the alternative processing described in Fig. 2 to 4, for example.

In S530, data based on the extracted relevant information are provided to a core network control element or function of the communication network. For example, when providing data based on the extracted relevant information to the core network control element or function of the communication network, the extracted relevant information are forwarded.

Alternatively, when the further processing is conducted, as indicated above, a result of the further processing is provided.

According to further examples of embodiments, in response to the provision of data based on the extracted relevant information (i.e. the data provided in S530), response information indicating updating and handling of the declaration message for forwarding it to a target is received from the core network control element or function of the communication network. The response information is processed accordingly, For example, the response information indicates at least one of: a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified (for example, when the latency can be fulfilled by the side from where the declaration message was received, but not fulfilled by the bridge element, then a type of the declaration message is to be changed, e.g. from a listener ready declaration to a listener ready failed declaration), an indication how parameters of the declaration message to be forwarded to the target are to be modified (for example, a new accumulated latency value), a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received (e.g. a listener ready declaration message and a previous talker advertise declaration massage to which the listener ready is the response), and an identification of a port to be used for forwarding the declaration message to the target (according to the port being used for receiving the talker advertise declaration message, for example).

According to some further examples of embodiments, an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the declaration message being received is requested. For example, the TT element or function can request such a measure at the TSN AF, as indicated above.

Furthermore, according to some examples of embodiments, an updated declaration message based on the processing result of the declaration message being received is forwarded to a target of the declaration message (as described, for example, in S80 of Fig. 2).

Fig. 6 shows a flow chart of a processing executed by a core network control element or function, such as an SMF or PCF as described in the examples of Figs. 2 to 4. The core network control element function is used for a control processing according to examples of embodiments, as described above, so as to enable transmission of a data stream between at least one talker party and at least one listener party, According to examples of embodiments, the core network control element or function to which the processing described in connection with Fig. 6 is applied is located in an SMF or PCF of a communication network forming a bridge element, for example, for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function represents one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system. TT elements or functions are provided in the communication network, such as e.g. a network-side TT element or function connected to or part of the core network element or function and a device-side TT element or function connected to or part of the device forming a mobile terminal element or function or a user equipment element or function.

As also indicated above, the communication network is based on a 3GPP standard. However, also other communication standards can be used, according to other examples of embodiments.

In S610, data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via the communication network forming the bridge element of the (TSN) communication system are received. The relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party,

According to some examples of embodiments, the data are received from a translator element or function of the bridge element of the communication system (which has extracted the relevant information and derived from this extracted relevant information the data, as described above).

According to examples of embodiments, a type of the declaration message is one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message. As also indicated above, the relevant information being the basis for the received data depends on the type of the declaration message (that is, there are different parameters required by the communication network for dealing with the corresponding declaration message; for example, a processing for a listener ready declaration message requires other (less) data than a processing of a talker advertise declaration message).

According to example of embodiments, the relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party comprises at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream.

In S620, the received data are processed for updating and handling of the declaration message for forwarding it to a target.

As also described in connection with Figs. 2 to 4, the data being received and processed include the extracted relevant information. Then, in the processing of the received data, on the basis of the relevant information extracted from the declaration message, a further processing is conducted which is related to at least one of updating and handling the declaration message for forwarding it to the target, wherein the further processing comprises at least one of determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target. That is, a processing can be conducted in the core network control element or function which is equivalent to a corresponding further processing in the TT element or function as described in connection with Fig. 5.

On the other hand, when the further processing is not conducted in the core network control element or function but in the TT element or function, the data being received and processed include at least one of the determination result whether a required latency amount can be fulfilled by the bridge element, the indication whether a type of the declaration message to be forwarded to the target is to be modified, the indication how parameters of the declaration message to be forwarded to the target are to be modified, the determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, the result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and the identification of a port to be used for forwarding the declaration message to the target. In this case, in the processing of the received data, the contents of the data are checked and it is determined whether the contents of the data can be acknowledged or have to be modified.

In S630, a result of the processing in S620 is forwarded to a network element or function of the communication network for forwarding an updated declaration message to the target.

For example, as the result of the processing, a result of the further processing executed in the core network control element or function is forwarded to the network element or function of the communication network for forwarding an updated declaration message to the target. Alternatively, as the result of the processing, one of an acknowledgement of the contents of the data or an indication of a modification of the contents of the data is forwarded to the network element or function of the communication network for forwarding an updated declaration message to the target (as described e.g. in connection with S70 of Fig. 2)

According to further examples of embodiment, an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the data based on relevant information extracted from the declaration message is requested (as described e.g. in connection with S90 of Fig. 2).

Fig. 7 shows a diagram of a network element or function acting as a TSN translator element or function, such as DS-TT 100 or NW-TT 90 according to some examples of embodiments, as described in connection with Figs. 1 to 4, which is configured to conduct a control processing for enabling transmission of a data stream between a talker and a listener party according to examples of embodiments of the disclosure. It is to be noted that the network element or function, like the DS-TT or NW-TT, may include further elements or functions besides those described herein below. Furthermore, even though reference is made to a network element or function, the element or function may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The network element or function 90 shown in Fig. 7 may include a processing circuitry, a processing function, a control unit or a processor 901 , such as a CPU or the like, which is suitable for executing instructions given by programs or the like related to the control procedure. The processor 901 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference sign 902 and 903 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 901. The I/O units 902 may be used for communicating with a TSN system or element, such as end stations or bridges, as described in connection with Fig. 1, for example. The I/O units 903 may be used for communicating with network elements or functions of the communication network e.g. the 3GPP network, as described in connection with Figs. 1 to 4. The I/O units 902 and 903 may be combined units including communication equipment towards several entities, or may include a distributed structure with a plurality of different interfaces for different entities. Reference sign 904 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 901 and/or as a working storage of the processor or processing function 901. It is to be noted that the memory 904 may be implemented by using one or more memory portions of the same or different type of memory.

The processor or processing function 901 is configured to execute processing related to the above described control processing. In particular, the processor or processing circuitry or function 901 includes one or more of the following sub-portions. Sub-portion 9011 is a processing portion which is usable as a portion for receiving a declaration message. The portion 9011 may be configured to perform processing according to S510 of Fig. 5. Furthermore, the processor or processing circuitry or function 901 may include a sub-portion 9012 usable as a portion for processing the declaration message. The portion 9012 may be configured to perform a processing according to S520 of Fig. 5. In addition, the processor or processing circuitry or function 901 may include a sub-portion 9013 usable as a portion for forwarding data. The portion 9013 may be configured to perform a processing according to S530 of Fig. 5.

Fig. 8 shows a diagram of a network element or function acting as a core network control element or function, such as SMF 40 or PCF 60 according to some examples of embodiments, as described in connection with Figs. 1 to 4, which is configured to conduct a control processing for enabling transmission of a data stream between a talker and a listener party according to examples of embodiments of the disclosure. It is to be noted that the network element or function, like the SMF or PCF, may include further elements or functions besides those described herein below. Furthermore, even though reference is made to a network element or function, the element or function may be also another device or function having a similar task, such as a chipset, a chip, a module, an application etc., which can also be part of a network element or attached as a separate element to a network element, or the like. It should be understood that each block and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.

The network element or function 40 shown in Fig. 8 may include a processing circuitry, a processing function, a control unit or a processor 401 , such as a CPU or the like, which is suitable for executing instructions given by programs or the like related to the control procedure. The processor 401 may include one or more processing portions or functions dedicated to specific processing as described below, or the processing may be run in a single processor or processing function. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors, processing functions or processing portions, such as in one physical processor like a CPU or in one or more physical or virtual entities, for example. Reference sign 402 and 403 denote input/output (I/O) units or functions (interfaces) connected to the processor or processing function 401. The I/O units 402 may be used for communicating with a TSN translator element or function, such as DS-TT or NW-TT (via the corresponding network element like UPF 30, as shown in Fig. 1, for example), as described in connection with Fig. 1, for example. The I/O units 403 may be used for communicating with network elements or functions of the communication network e.g. the 3GPP network, as described in connection with Figs. 1 to 4. The I/O units 402 and 403 may be combined units including communication equipment towards several entities, or may include a distributed structure with a plurality of different interfaces for different entities. Reference sign 404 denotes a memory usable, for example, for storing data and programs to be executed by the processor or processing function 401 and/or as a working storage of the processor or processing function 401. It is to be noted that the memory 404 may be implemented by using one or more memory portions of the same or different type of memory.

The processor or processing function 401 is configured to execute processing related to the above described control processing. In particular, the processor or processing circuitry or function 401 includes one or more of the following sub-portions. Sub-portion 4011 is a processing portion which is usable as a portion for receiving data. The portion 4011 may be configured to perform processing according to S610 of Fig. 6. Furthermore, the processor or processing circuitry or function 401 may include a sub-portion 4012 usable as a portion for processing the data. The portion 4012 may be configured to perform a processing according to S620 of Fig. 6. In addition, the processor or processing circuitry or function 401 may include a sub-portion 4013 usable as a portion for forwarding a result. The portion 4013 may be configured to perform a processing according to S630 of Fig. 6.

It is to be noted that examples of embodiments of the disclosure are applicable to various different network configurations. In other words, the examples shown in the above described figures, which are used as a basis for the above discussed examples, are only illustrative and do not limit the present disclosure in any way. That is, additional further existing and proposed new functionalities available in a corresponding operating environment may be used in connection with examples of embodiments of the disclosure based on the principles defined.

Furthermore, it is to be noted that while the above described examples are related to the usage of the mechanisms usable for declaration message transmission in connection with a TSN network or system, it is possible to implement corresponding features also in connection with procedures used for other networks related to Ethernet or the like.

According to a further example of embodiments, there is provided, for example, an apparatus for use by a network element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising means configured to receive a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, means configured to process the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, and means configured to provide data based on the extracted relevant information to a core network control element or function of the communication network.

Furthermore, according to some other examples of embodiments, the above defined apparatus may further comprise means for conducting at least one of the processing defined in the above described methods, for example a method according to that described in connection with Fig 5.

According to a further example of embodiments, there is provided, for example, an apparatus for use by a core network control element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising means configured to receive data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, means configured to process the received data for updating and handling of the declaration message for forwarding it to a target, and means configured to forward a result of the processing to a network element or function of the communication network for forwarding an updated declaration message to the target.

Furthermore, according to some other examples of embodiments, the above defined apparatus may further comprise means for conducting at least one of the processing defined in the above described methods, for example a method according to that described in connection with Fig. 6.

According to a further example of embodiments, there is provided, for example, a non- transitory computer readable medium comprising program instructions for causing an apparatus to perform, when conducting a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, at least: to receive a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, to process the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, and to provide data based on the extracted relevant information to a core network control element or function of the communication network.

According to a further example of embodiments, there is provided, for example, a non- transitory computer readable medium comprising program instructions for causing an apparatus to perform, when conducting a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising at least to receive data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, to process the received data for updating and handling of the declaration message for forwarding it to a target, and to forward a result of the processing to a network element or function of the communication network for forwarding an updated declaration message to the target. It is to be noted that, while examples of embodiments described above, refer to a configuration using MSRP, also other configuration examples can apply corresponding measures. For example, as described above, LRP may be used instead of MRP and allow for the exchange of larger databases. MSRP is an application running over MRP. For industrial networks utilizing the fully distributed model, MRP may be replaced by the RRP, which is an application running over LRP. RRP may extend the MSRP. Thus, the principles described above and defined in methods and apparatus as defined in the claims below may be equally applicable to RRP, LRP, or other protocol types being applicable.

It should be appreciated that

- an access technology via which traffic is transferred to and from an entity in the communication network may be any suitable present or future technology, such as WLAN (Wireless Local Access Network), WiMAX (Worldwide Interoperability for Microwave Access), LTE, LTE-A, 5G, Bluetooth, Infrared, and the like may be used; additionally, embodiments may also apply wired technologies, e.g. IP based access technologies like cable networks or fixed lines.

- embodiments suitable to be implemented as software code or portions of it and being run using a processor or processing function are software code independent and can be specified using any known or future developed programming language, such as a high- level programming language, such as objective-C, C, C++, C#, Java, Python, Javascript, other scripting languages etc., or a low-level programming language, such as a machine language, or an assembler.

- implementation of embodiments is hardware independent and may be implemented using any known or future developed hardware technology or any hybrids of these, such as a microprocessor or CPU (Central Processing Unit), MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), and/or TTL (T ransistor-T ransistor Logic).

- embodiments may be implemented as individual devices, apparatuses, units, means or functions, or in a distributed fashion, for example, one or more processors or processing functions may be used or shared in the processing, or one or more processing sections or processing portions may be used and shared in the processing, wherein one physical processor or more than one physical processor may be used for implementing one or more processing portions dedicated to specific processing as described,

- an apparatus may be implemented by a semiconductor chip, a chipset, or a (hardware) module including such chip or chipset; - embodiments may also be implemented as any combination of hardware and software, such as ASIC (Application Specific 1C (Integrated Circuit)) components, FPGA (Field- programmable Gate Arrays) or CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components.

- embodiments may also be implemented as computer program products, including a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to execute a process as described in embodiments, wherein the computer usable medium may be a non-transitory medium.

Although the present disclosure has been described herein before with reference to particular embodiments thereof, the present disclosure is not limited thereto and various modifications can be made thereto.

Claims

1. An apparatus for use by a network element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, to process the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, to provide data based on the extracted relevant information to a core network control element or function of the communication network.

2. The apparatus according to claim 1, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to receive the declaration message related to the stream reservation procedure between the at least one talker party and at least one listener party from a source located outside the bridge element of the communication system or from a translator element or function of the bridge element of the communication system.

3. The apparatus according to any of claims 1 and 2, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: in the processing of the declaration message, to identify, as the type of the declaration message, one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message, wherein the kind of relevant information being extracted from the declaration message depends on the identified type of the declaration message.

4. The apparatus according to any of claims 1 to 3, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: in the processing of the declaration message, to extract, from the declaration message as the relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream.

5. The apparatus according to any of claims 1 to 4, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to forward, when providing data based on the extracted relevant information to the core network control element or function of the communication network, the extracted relevant information.

6. The apparatus according to any of claims 1 to 4, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: in the processing of the declaration message, to conduct, on the basis of the relevant information extracted from the declaration message, a further processing related to at least one of updating and handling the declaration message for forwarding it to a target, and to forward, when providing data based on the extracted relevant information to the core network control element or function of the communication network, a result of the further processing.

7. The apparatus according to claim 6, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to conduct, as the further processing, at least one of: determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target.

8. The apparatus according to any of claims 1 to 7, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to receive, in response to the provision of data based on the extracted relevant information, from the core network control element or function of the communication network, response information indicating updating and handling of the declaration message for forwarding it to a target, and to process the response information, wherein the response information indicates at least one of: a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified, an indication how parameters of the declaration message to be forwarded to the target are to be modified, a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and an identification of a port to be used for forwarding the declaration message to the target.

9. The apparatus according to any of claims 1 to 8, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to request an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the declaration message being received.

10. The apparatus according to any of claims 1 to 9, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to forward an updated declaration message based on the processing result of the declaration message being received to a target of the declaration message.

11. The apparatus according to any of claims 1 to 10, wherein the communication network forms a bridge element for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function of the communication network represents one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system, wherein a network-side translator element or function is connected to or part of a core network element or function of the wireless communication network and a device-side translator element or function is connected to or part of the device forming a mobile terminal element or function or a user equipment element or function, and wherein the apparatus is connected to or part of at least one of the network-side translator element or function and the device-side translator element or function.

12. The apparatus according to any of claims 1 to 11 , wherein the communication network is based on a 3GPP standard.

13. An apparatus for use by a core network control element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, to process the received data for updating and handling of the declaration message for forwarding it to a target, and to forward a result of the processing to a network element or function of the communication network for forwarding an updated declaration message to the target.

14. The apparatus according to claim 13, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to receive the data from a translator element or function of the bridge element of the communication system.

15. The apparatus according to any of claims 13 and 14, wherein a type of the declaration message is one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message, wherein the relevant information being the basis of the data being received depends on the type of the declaration message.

16. The apparatus according to any of claims 13 to 15, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, and comprises at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream.

17. The apparatus according to any of claims 13 to 16, wherein the data being received and processed include the extracted relevant information.

18. The apparatus according to claim 17, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: in the processing of the received data, to conduct, on the basis of the relevant information extracted from the declaration message, a further processing related to at least one of updating and handling the declaration message for forwarding it to the target, wherein the further processing comprises at least one of: determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target.

19. The apparatus according to claim 18, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to forward, as the result of the processing, a result of the further processing to the network element or function of the communication network for forwarding an updated declaration message to the target

20. The apparatus according to any of claims 13 to 16, wherein the data being received and processed include at least one of a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified, an indication how parameters of the declaration message to be forwarded to the target are to be modified, a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and an identification of a port to be used for forwarding the declaration message to the target, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: in the processing of the received data, to check the contents of the data and to determine whether the contents of the data can be acknowledged or have to be modified.

21. The apparatus according to claim 20, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to forward, as the result of the processing, one of an acknowledgement of the contents of the data or an indication of a modification of the contents of the data to the network element or function of the communication network for forwarding an updated declaration message to the target.

22. The apparatus according to any of claims 13 to 21, wherein the at least one memory and the instructions are further configured to, with the at least one processing circuitry, cause the apparatus at least: to request an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the data based on relevant information extracted from the declaration message.

23. The apparatus according to any of claims 13 to 22, wherein the communication network forms a bridge element for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function of the communication network represents one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system, wherein a network-side translator element or function is connected to or part of a core network element or function of the wireless communication network and a device-side translator element or function is connected to or part of the device forming a mobile terminal element or function or a user equipment element or function, and wherein the apparatus is connected to or part of at least one of a core network control element or function of the communication network.

24. The apparatus according to any of claims 13 to 23, wherein the communication network is based on a 3GPP standard.

25. A method for use in a network element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the method comprising receiving a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, processing the declaration message, the processing includes at least an identification of the type of the declaration message and an extraction, from the declaration message, of relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, providing data based on the extracted relevant information to a core network control element or function of the communication network.

26. The method according to claim 25, further comprising receiving the declaration message related to the stream reservation procedure between the at least one talker party and at least one listener party from a source located outside the bridge element of the communication system or from a translator element or function of the bridge element of the communication system.

27. The method according to any of claims 24 and 25, further comprising

Identifying, in the processing of the declaration message, as the type of the declaration message, one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message, wherein the kind of relevant information being extracted from the declaration message depends on the identified type of the declaration message.

28. The method according to any of claims 24 to 27, further comprising extracting, in the processing of the declaration message, from the declaration message as the relevant information required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream.

29. The method according to any of claims 25 to 28, further comprising forwarding, when providing data based on the extracted relevant information to the core network control element or function of the communication network, the extracted relevant information.

30. The method according to any of claims 25 to 28, further comprising conducting, in the processing of the declaration message, on the basis of the relevant information extracted from the declaration message, a further processing related to at least one of updating and handling the declaration message for forwarding it to a target, and to forward, when providing data based on the extracted relevant information to the core network control element or function of the communication network, a result of the further processing.

31. The method according to claim 30, further comprising conducting, as the further processing, at least one of: determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target.

32. The method according to any of claims 25 to 31, further comprising receiving, in response to the provision of data based on the extracted relevant information, from the core network control element or function of the communication network, response information indicating updating and handling of the declaration message for forwarding it to a target, and processing the response information, wherein the response information indicates at least one of: a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified, an indication how parameters of the declaration message to be forwarded to the target are to be modified, a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and an identification of a port to be used for forwarding the declaration message to the target.

33. The method according to any of claims 25 to 32, further comprising requesting an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the declaration message being received.

34. The method according to any of claims 25 to 33, further comprising forwarding an updated declaration message based on the processing result of the declaration message being received to a target of the declaration message.

35. The method according to any of claims 25 to 34, wherein the communication network forms a bridge element for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function of the communication network represents one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system, wherein a network-side translator element or function is connected to or part of a core network element or function of the wireless communication network and a device-side translator element or function is connected to or part of the device forming a mobile terminal element or function or a user equipment element or function, and wherein the method is conducted at or in at least one of the network-side translator element or function and the device-side translator element or function.

36. The method according to any of claims 25 to 35, wherein the communication network is based on a 3GPP standard.

37. A method for use in a core network control element or function configured to conduct a control processing for enabling transmission of a data stream between at least one talker party and at least one listener party, the method comprising receiving data based on relevant information extracted from a declaration message related to a stream reservation procedure between the at least one talker party and at least one listener party via a communication network forming a bridge element of a communication system, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, processing the received data for updating and handling of the declaration message for forwarding it to a target, and forwarding a result of the processing to a network element or function of the communication network for forwarding an updated declaration message to the target.

38. The method according to claim 37, further comprising receiving the data from a translator element or function of the bridge element of the communication system.

39. The method according to any of claims 37 and 38, wherein a type of the declaration message is one of a talker advertise declaration message, a talker failed declaration message, a listener ready declaration message, a listener ready failed declaration message, and a listener failed declaration message, wherein the relevant information being the basis of the data being received depends on the type of the declaration message.

40. The method according to any of claims 37 to 39, wherein the relevant information is required by the communication network for providing resources required for the stream between the at least one talker party and at least one listener party, and comprises at least one of a latency requirement of the talker or listener for a stream transmission, an amount of latency which the stream experiences on the way to the bridge element of the communication system, a data frame priority for the stream transmission, a rank of the stream transmission, a maximum frame size for the stream transmission, and an identification of the stream.

41. The method according to any of claims 37 to 40, wherein the data being received and processed include the extracted relevant information.

42. The method according to claim 41, further comprising conducting, in the processing of the received data, on the basis of the relevant information extracted from the declaration message, a further processing related to at least one of updating and handling the declaration message for forwarding it to the target, wherein the further processing comprises at least one of: determining whether a required latency amount can be fulfilled by the bridge element, modifying a type of the declaration message to be forwarded to the target, modifying parameters of the declaration message to be forwarded to the target, determining an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and identifying a port to be used for forwarding the declaration message to the target.

43. The method according to claim 42, further comprising forwarding, as the result of the processing, a result of the further processing to the network element or function of the communication network for forwarding an updated declaration message to the target.

44. The method according to any of claims 37 to 43, wherein the data being received and processed include at least one of a determination result whether a required latency amount can be fulfilled by the bridge element, an indication whether a type of the declaration message to be forwarded to the target is to be modified, an indication how parameters of the declaration message to be forwarded to the target are to be modified, a determination result of an amount of latency resulting from the bridge element and to be added to a latency value indicated in the declaration message being received, a result of a mapping between the declaration message being received and a former declaration message being received earlier and related to the declaration message being received, and an identification of a port to be used for forwarding the declaration message to the target, wherein the method further comprises in the processing of the received data, checking the contents of the data and determining whether the contents of the data can be acknowledged or have to be modified.

45. The method according to claim 44, further comprising forwarding, as the result of the processing, one of an acknowledgement of the contents of the data or an indication of a modification of the contents of the data to the network element or function of the communication network for forwarding an updated declaration message to the target.

46. The method according to any of claims 37 to 45, further comprising requesting an establishment or modification of a packet data unit session according to requirements of the stream determined from the processing of the data based on relevant information extracted from the declaration message.

47. The method according to any of claims 37 to 46, wherein the communication network forms a bridge element for a time sensitive networking system or Ethernet based networking system, wherein a device forming a mobile terminal element or function or a user equipment element or function of the communication network represents one end point of the bridge element being connectable with at least one end station or another bridge element of the time sensitive networking system or Ethernet based networking system, wherein a network-side translator element or function is connected to or part of a core network element or function of the wireless communication network and a device-side translator element or function is connected to or part of the device forming a mobile terminal element or function or a user equipment element or function, and wherein the method is conducted in at least one of a core network control element or function of the communication network.

48. The method according to any of claims 37 to 47, wherein the communication network is based on a 3GPP standard.

49. A computer program product for a computer, including software code portions for performing the steps of any of claims 25 to 36 or any of claims 37 to 48 when said product is run on the computer.

50. The computer program product according to claim 49, wherein the computer program product includes a computer-readable medium on which said software code portions are stored, and/or the computer program product is directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.