WO2023110052A1

WO2023110052A1 - Frer support using 5g system bridges

Info

Publication number: WO2023110052A1
Application number: PCT/EP2021/085419
Authority: WO
Inventors: Rakash SIVASIVA GANESAN; Peter Rost; Borislava GAJIC; Christian MANNWEILER
Original assignee: Nokia Solutions And Networks Gmbh & Co. Kg
Priority date: 2021-12-13
Filing date: 2021-12-13
Publication date: 2023-06-22

Abstract

According to an aspect, there is provided an apparatus for performing the following. The apparatus obtains frame replication and elimination for reliability configuration information and extracts sequence recovery function information therefrom. The apparatus detects, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host. In response to the detecting, the apparatus causes a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

Description

FRER SUPPORT USING 5G SYSTEM BRIDGES

TECHNICAL FIELD

Various example embodiments relate to wireless communications.

BACKGROUND

Frame Replication and Elimination for Reliability (FRER) is a scheme for reducing the probability of packet loss due to equipment failures when transferring time-sensitive networking (TSN) streams via a bridged network. This increased reliability is achieved by transmitting multiple copies of the packets belonging to a TSN stream through independent paths in the network. In industrial networks, it would be beneficial if multiple 5G system (5GS) bridges could be deployed and that FRER could be performed across these bridges to enhance end-to- end (E2E) reliability.

BRIEF DESCRIPTION

According to an aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims. The scope of protection sought for various embodiments is set out by the independent claims.

The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments.

BRIEF DESCRIPTION OF DRAWINGS

In the following, example embodiments will be described in greater detail with reference to the attached drawings, in which

Figure 1 illustrates an exemplified wireless communication system;

Figure 2 illustrates an example of a FRER deployment in a bridged network;

Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C and 4D illustrate exemplary systems according to embodiments;

Figures 5A, 5B, 6, 7, 8A, 8B, 9 and 10 illustrate exemplary processes according to embodiments; and

Figures 11 and 12 illustrate apparatuses according to embodiments. DETAILED DESCRIPTION OF SOME EMBODIMENTS

In the following, different exemplifying embodiments will be described using, as an example of an access architecture to which the embodiments may be applied, a radio access architecture based on long term evolution advanced (LTE Advanced, LTE-A) or new radio (NR, 5G), without restricting the embodiments to such an architecture, however. The embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN or E-UTRAN), long term evolution (LTE, the same as E-UTRA), wireless local area network (WLAN or WiFi), worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra- wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet Protocol multimedia subsystems (IMS) or any combination thereof.

The expression “communicatively connected” as used in the following may have the meaning of connected so as to enable communication (i.e., transmission and/or reception of signals) between the connected elements. Elements which are communicatively connected may be connected, for example, via one or more wired communication links, one or more wireless communication links, one or more wired communication networks and/or one or more wireless communication networks. The expression “communicatively connected” does not necessarily imply that the associated elements are electrically connected (i.e., connected via a conducting path) and/or physically connected.

Figure 1 depicts examples of simplified system architectures only showing some elements and functional entities, all being logical units, whose implementation may differ from what is shown. The connections shown in Figure 1 are logical connections; the actual physical connections may be different. It is apparent to a person skilled in the art that the system typically comprises also other functions and structures than those shown in Figure 1.

The embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties.

The example of Figure 1 shows a part of an exemplifying radio access network. Figure 1 shows devices 100 and 102. The devices 100 and 102 may, for example, be user devices. The devices 100 and 102 are configured to be in a wireless connection on one or more communication channels with a node 104. The node 104 is further connected to a core network 110. In one example, the node 104 may be an access node such as (e/g)NodeB providing or serving devices in a cell. In one example, the node 104 may be a non-3GPP access node. The physical link from a device to a (e/g) NodeB is called uplink or reverse link and the physical link from the (e/g) NodeB to the device is called downlink or forward link. It should be appreciated that (e/g)NodeBs or their functionalities may be implemented by using any node, host, server or access point etc. entity suitable for such a usage.

A communications system typically comprises more than one (e/g) NodeB in which case the (e/g)NodeBs may also be configured to communicate with one another over links, wired or wireless, designed for the purpose. These links may be used for signalling purposes. The (e/g)NodeB is a computing device configured to control the radio resources of communication system it is coupled to. The NodeB may also be referred to as a base station, an access point or any other type of interfacing device including a relay station capable of operating in a wireless environment. The (e/g)NodeB includes or is coupled to transceivers. From the transceivers of the (e/g) NodeB, a connection is provided to an antenna unit that establishes bi-directional radio links to devices. The antenna unit may comprise a plurality of antennas or antenna elements. The (e/g)NodeB is further connected to the core network 110 (CN or next generation core NGC). Depending on the system, the counterpart on the CN side can be a serving gateway (S-GW, routing and forwarding user data packets), packet data network gateway (P-GW), for providing connectivity of devices (UEs) to external packet data networks, or mobile management entity (MME), etc.

The device (also called user device, UE, user equipment, user terminal, terminal device, etc.) illustrates one type of an apparatus to which resources on the air interface are allocated and assigned, and thus any feature described herein with a device may be implemented with a corresponding apparatus, such as a relay node. An example of such a relay node is a layer 3 relay (self-backhauling relay) towards the base station.

The device typically refers to a device ( e.g. a portable or non-portable computing device) that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (mobile phone), smartphone, personal digital assistant (PDA), handset, device using a wireless modem (alarm or measurement device, etc.), laptop and/or touch screen computer, tablet, game console, notebook, and multimedia device. It should be appreciated that a device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A device may also be a device having capability to operate in Internet of Things (loT) network which is a scenario in which objects are provided with the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction, e.g., to be used in smart power grids and connected vehicles. The device may also utilise cloud. In some applications, a device may comprise a user portable device with radio parts (such as a watch, earphones or eyeglasses) and the computation is carried out in the cloud. The device (or in some embodiments a layer 3 relay node) is configured to perform one or more of user equipment functionalities. The device may also be called a subscriber unit, mobile station, remote terminal, access terminal, user terminal or user equipment (UE) just to mention but a few names or apparatuses.

Various techniques described herein may also be applied to a cyberphysical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the implementation and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers, etc.) embedded in physical objects at different locations. Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals.

Additionally, although the apparatuses have been depicted as single entities, different units, processors and/or memory units (not all shown in Figure 1) may be implemented.

5G enables using multiple input - multiple output (M1M0) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and employing a variety of radio technologies depending on service needs, use cases and/or spectrum available. 5G mobile communications supports a wide range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications (such as (massive) machine-type communications (mMTC), including vehicular safety, different sensors and real-time control. 5G is expected to have multiple radio interfaces, namely below 6GHz, cmWave and mmWave, and also being integrable with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words, 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-Rl operability (inter-radio interface operability, such as below 6GHz - cmWave, below 6GHz - cmWave - mmWave] . One of the concepts considered to be used in 5G networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.

The current architecture in LTE networks is fully distributed in the radio and fully centralized in the core network. The low latency applications and services in 5G require to bring the content close to the radio which leads to local break out and multi-access edge computing (MEC). 5G enables analytics and knowledge generation to occur at the source of the data. This approach requires leveraging resources that may not be continuously connected to a network such as laptops, smartphones, tablets and sensors. MEC provides a distributed computing environment for application and service hosting. It also has the ability to store and process content in close proximity to cellular subscribers for faster response time. Edge computing covers a wide range of technologies such as wireless sensor networks, mobile data acquisition, mobile signature analysis, cooperative distributed peer- to-peer ad hoc networking and processing also classifiable as local cloud/fog computing and grid/mesh computing, dew computing, mobile edge computing, cloudlet, distributed data storage and retrieval, autonomic self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (massive connectivity and/or latency critical), critical communications (autonomous vehicles, traffic safety, real-time analytics, time-critical control, healthcare applications).

The communication system is also able to communicate with other networks, such as a public switched telephone network or the Internet 112, or utilize services provided by them. The communication network may also be able to support the usage of cloud services, for example at least part of core network operations may be carried out as a cloud service (this is depicted in Figure 1 by “cloud” 114). The communication system may also comprise a central control entity, or a like, providing facilities for networks of different operators to cooperate for example in spectrum sharing.

The technology of Edge cloud may be brought into a radio access network (RAN) by utilizing network function virtualization (NVF) and software defined networking (SDN). Using the technology of edge cloud may mean access node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head or base station comprising radio parts. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. Application of cloudRAN architecture enables RAN real time functions being carried out at the RAN side (in a distributed unit, DU 104) and non-real time functions being carried out in a centralized manner (in a centralized unit, CU 108).

It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Big Data and all-lP, which may change the way networks are being constructed and managed. 5G (or new radio, NR) networks are being designed to support multiple hierarchies, where MEC servers can be placed between the core and the base station or nodeB (gNB). It should be appreciated that MEC can be applied in 4G networks as well.

5G may also utilize satellite communication to enhance or complement the coverage of 5G service, for example by providing backhauling. Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (loT) devices or for passengers on board of vehicles, or ensuring service availability for critical communications, and future railway/maritime/aeronautical communications. Satellite communication may utilise geostationary earth orbit (GEO) satellite systems, but also low earth orbit (LEO) satellite systems, in particular mega-constellations (systems in which hundreds of (nano)satellites are deployed). Each satellite 106 in the mega-constellation may cover several satellite- enabled network entities that create on-ground cells. The on-ground cells may be created through an on-ground relay node 104 or by a gNB located on-ground or in a satellite.

It is obvious for a person skilled in the art that the depicted system is only an example of a part of a radio access system and in practice, the system may comprise a plurality of (e/g)NodeBs, the device may have an access to a plurality of radio cells and the system may comprise also other apparatuses, such as physical layer relay nodes or other network elements, etc. At least one of the (e/g)NodeBs or may be a Home(e/g)nodeB. Additionally, in a geographical area of a radio communication system a plurality of different kinds of radio cells as well as a plurality of radio cells may be provided. Radio cells may be macro cells (or umbrella cells) which are large cells, usually having a diameter of up to tens of kilometers, or smaller cells such as micro-, femto- or picocells. The (e/g)NodeBs of Figure 1 may provide any kind of these cells. A cellular radio system may be implemented as a multilayer network including several kinds of cells. Typically, in multilayer networks, one access node provides one kind of a cell or cells, and thus a plurality of (e/g)NodeBs are required to provide such a network structure.

For fulfilling the need for improving the deployment and performance of communication systems, the concept of “plug-and-play” (e/g)NodeBs has been introduced. Typically, a network which is able to use “plug-and-play” (e/g)Node Bs, includes, in addition to Home (e/g)NodeBs (H(e/g)nodeBs), a home node B gateway, or HNB-GW (not shown in Figure 1). A HNB Gateway (HNB-GW), which is typically installed within an operator’s network may aggregate traffic from a large number of HNBs back to a core network.

The one of the main target scenarios of the embodiments to be discussed below may be considered the tactile industrial network, also known as Industrial loT (11 oT) or Industry 4.0 networks. Here, 3GPP technologies are applied in addition to wired time sensitive networking (TSN) to provide flexibility (in terms of mobility) and scalability (in terms of number of sensors or actuators). The embodiments focus on enabling 5G-system (5GS) TSN bridge, e.g., as specified in the standard TS 23.501 to support the Frame Replication and Elimination for Reliability (FRER), e.g., as defined in IEEE 802.1CB-2017.

To facilitate the following discussion of embodiments which relate to the use of FRER mechanism in a (TSN) bridged network, the basic functionalities of FRER are discussed in the following in connection with Figure 2.

Figure 2 illustrates an example of a FRER deployment 200 in a bridged network. The embodiments to be discussed in the following may be implemented in such an FRER deployment 200. Specifically, Figure 2 illustrates a bridged network comprising first and second (TSN) end stations 202, 211 and two parallel sets of connected (TSN) bridges 206-208 & 209-210 connecting said firstand second (TSN) end stations 201, 211 via two different paths. In general, the entities 202, 211 could, alternatively, be bridges though, in the following discussion, they are called end stations for simplicity. Additionally, Figure 2 shows a centralized network controller 203. The CNC is a functional element of a TSN deployment which provides configuration data to TSN bridges in response to receiving TSN flow requests from a CUC (Centralized User Configuration). Though not shown in Figure 2, the TSN deployment may comprise also said CUC. According to a general definition, the CUC is a logical function which is configured to receive requests for TSN flow establishment from TSN endpoints (i.e., from TSN listener and/or talker end devices) and, in turn, to pass configuration data related to the TSN flow to the CNC for instantiation.

In context of FRER, a (TSN) stream also referred to as (TSN) compound stream is composed of one or more (TSN) member streams linked together. FRER mechanism enables transforming (through replication and change of header information) a compound stream into one or more linked member streams. It replicates the packets of the stream, transforming the copies into the multiple member streams, and then re-joins those member streams at one or more other points, eliminates the replicates, and delivers the reconstituted stream from those points. Hence, a compound stream is a stream composed of one or more member streams. Note that each of the member streams are a stream on its own with its own packet header, e.g., destination address and quality of service (QoS) requirements.

Figure 2 shows a simple example of this end-to-end (E2E) FRER mechanism. Initially, a compound stream 201 originating from a TSN talker end device (not shown in Figure 2) is provided. The TSN talker end device may be equally simply a TSN talker or even just a talker. The individual blocks of the compound stream 201 illustrate frames of the compound stream 201. The first end station 202 receiving said compound stream 201 is configured by the centralized network controller 203 to implement a stream splitting function, that is, to perform sequence numbering and replication of packets. Accordingly, the first end station 202 splits the (TSN) compound stream 201 is split into a first (TSN) member stream 204 and a second member (TSN) stream 205.

The first and second member streams 204, 205 take different path through the bridged network. The first member stream 204 is transmitted via the (TSN) bridges 206-208 to the second end station 211 while the second member stream is transmitted via the (TSN) bridges 209, 210 to the second end station.

The second end station 211 is configured by the centralized network controller 203 to implement the sequence recovery function. In other words, the second end station 211 serves to eliminate frame replicates (i.e., reverse the frame replication performed in the first end station 202) to form a (compound) stream 212. The stream 212 correspond to the stream 201. The stream 212 may be further transmitted to a TSN listener end device (not shown in Figure 2). Alternatively, the element 211 may comprise the TSN listener end device. The TSN listener end device may be equally simply a TSN listener or even just a listener. By providing two independent paths through the bridged network for two copies of the same stream, the probability of packet loss due to equipment failures is reduced (i.e., reliability is increased).

In the following, the key components and concepts of FRER are described in more detail.

Five functions may be considered to form the central functionality of the FRER mechanism. Said five functions comprise sequencing function, stream splitting function, individual recovery function, sequence encode/decode function, and stream identification function, where the five functions have been listed in the order of how high they are placed in the protocol stack (the sequencing function and the stream identification function corresponding to the highest and lowest layers in the protocol stack, respectively).

Said five functions may be described as follows:

Sequencing function: The sequencing function has two components:

• The sequence generation function operates on packets passed down the protocol stack towards the physical layer and generates a value for a sequence number. The sequence number may be equally called a sequence_number subparameter, at least in some embodiments.

• The sequence recovery function operates on packets of a merged set of member streams passed up the stack towards the higher layer functions and uses the sequence_number subparameter to decide which packets to pass and which to discard. In other words, it operates on a merged set of member streams originally marked with the sequence number. It examines the sequence numbers of the received packets passed up to it (from compound streams) and discards packets whose sequence_number subparameter indicates that it is a duplicate of a packet received previously. Latent error detection function is part of sequence recovery function. This function detects if packets of one of the multiple FRER paths are missing and reports an error when a certain number of packets are missing.

Stream splitting function: The stream splitting function replicates each frame passed down to it and assigns each replicate a different stream handle (or a different stream_handle subparameter). Individual recovery function: This function examines the sequence numbers of received packets passed up to it (belonging to member streams), and discards packets whose sequence number indicates that it is a duplicate of a packet received previously. By applying the Individual recovery function to member streams, whether before or without the application of the Sequence recovery function to compound streams, errored streams can be discovered early, and pollution of the merged stream avoided. Unlike the sequence recovery function, which is modelled as being instantiated on a specific port, a single instantiation of an Individual recovery function can be applied to any number of ports.

Sequence Encode/Decode function: This function inserts the sequence number into the packet and extracts it from the packet, respectively. If the stream identification function also encodes and decodes the sequence number for a given stream on a particular port and direction, then no sequence encode/decode sublayer is needed.

Stream identification function: This function examines the stream handle of packets received from the lower layer (passed down from the upper layers, respectively) to determine whether the packet belongs to a known or unknown stream and treat it accordingly.

The main benefit of using FRER in a TSN network is that certain target reliability and availability (avoiding single point of failure) may be achieved in an E2E connection. However, reliability and availability of a TSN bridge is typically pre-defined. A 5GS is modelled as a TSN bridge and thus it needs to satisfy the requirements similar to that of a TSN bridge. It should be noted that the aim of the FRER mechanism is not to increase the reliability or availability of the TSN bridge as such, i.e., the FRER mechanism does not enable transmitting redundant streams through a bridge to increase the reliability offered by the bridge. However, the 5GS should guarantee a pre-defined reliability and availability to the TSN network (i.e., to the management system or the CNC). This requirement applies regardless of whether or not the FRER mechanism is used in the E2E network.

A 5GS may be deployed at different places in an E2E TSN network. Based on the location, it may take different roles. In a first role, one of the member streams is transmitted through the 5GS TSN bridge so that the FRER mechanism is effectively transparent to the 5G TSN bridge. Note, e.g., IEEE 802.1CB only configures the first and the last FRER bridge/end station. For the intermediate bridges, FRER is transparent. In the second and third roles, the CNC provides the FRER configuration information to the 5GS to duplicate and merge the member streams, respectively. The IR NC320862 addresses the scenario where 5GS is the first/last bridge (corresponding to the second and third roles) of a FRER path. In the embodiments, the focus is placed on the firstrole 1, where FRER is transparent to the 5GS TSN bridge.

The embodiments to be discussed below provide a mechanism for implementing redundancy enhancement in an industrial network comprising multiple 5GS TSN bridges across which FRER may be performed. The embodiments may pertain specifically to a scenario where two 5GS TSN bridges are configured to carry different member streams of a compound stream and further said two 5GS TSN bridges are realized by a single 5GS deployment (i.e., the two logical 5GS bridges are realized by the same underlying 5GS).

Figures 3A, 3B, 3C and 3D illustrate four alternative systems according to embodiments. Any of said systems 300, 320, 340, 360 may form a part of the communication system of Figure 1. While not explicitly shown in Figures 3A, 3B, 3C and 3D, any of the hosts 300, 320, 340, 360 may be communicatively connected to a CNC of the TSN deployment, e.g., as depicted in Figure 2.

Referring to Figure 3A, the system 300 comprises a (device-side) host 301 connected via first and second 5GS TSN bridges 308, 309 to a TSN bridged network (formed of elements 308 to 313). The host 301 may be equally called a host system. Similar to Figure 2, a TSN talker (T) end device 313 of the TSN bridged network is connected via two different paths of the TSN bridged network (defined by bridges 308, 310, 312 and bridges 309, 311, respectively) to two TSN listener end devices 302, 303 (LI & L2) comprised in the host 301. Thus, the host 301 (or specifically the TSN listener end devices 302, 303) is capable of receiving two independent member streams of a compound stream from the TSN talker end device 313.

The number of bridges in the two paths through the TSN bridged network (namely, three and two in Figure 3A) are merely exemplary. In general, each of the two paths may comprise one of the 5GS TSN bridges 308, 309 and zero or more further TSN bridges.

Each of the first and second 5GS TSN bridges 308, 309 may comprise one of first and second device-side TSN translators (DS-TTs) 305, 306, a terminal device 307, one or more access and/or relay nodes serving said terminal device 307, a user plane function (UPF) of a core network communicatively connected to said one or more access and/or relay nodes and a network-side TSN translator (NW-TT) communicatively connected to the UPF. In order to avoid single point of failure, the 5GS TSN bridges need to be configured to use different resources of the underlying 5GS for the two member streams. Different resources may relate here specifically to different physical resources such as different access nodes. The embodiments provide a mechanism for ensuring this operation.

The host 301 comprises the terminal device 307, the first and second device-side TSN translators (DS-TTs) 305, 306, an FRER-capable (device-side) bridge 304 and said two TSN listener end devices 302, 303. The host 301 may be equally called an end station or a TSN end station.

The terminal device 307 (equally called a first terminal device) is connected via first and second 5GS TSN bridges 308, 309 to the TSN bridged network (or specifically at least to said two different paths within the TSN bridged network). The connection to the first and second 5GS TSN bridges 308, 309 may be provided via first and third (communication) interfaces of the terminal device. Moreover, the terminal device 307 is communicatively connected to the FRER capable bridge 304 via the first and second DS-TTs 305, 306. The terminal device 307 may be configured to forward the first and second member streams (corresponding, e.g., to the upper and lower paths through the TSN bridged network as depicted in Figure 3A) to the first and second DS-TTs 305, 306, respectively.

As the name implies, the first and second DS-TTs 305, 306 serve to translate, at the terminal device -side, the TSN member streams for the 5G system so as to enable interoperation between the two systems. The first and second DS- TTs 305, 306 may be comprised in the terminal device 307 or be external to the terminal device 307 but communicatively connected to it via second and fourth (communication) interfaces of the terminal device. The first and second DS-TTs 305, 306 are communicatively connected via the FRER-capable bridge to the first and second listener end devices 302, 303, respectively. More generally, the FRER capable bridge 304 may connect the first and second DS-TTs 306, 306 to a local fixed-line network comprising said first and second listener end devices 302, 303. Said first and second listener end devices 302, 303 may serve as gateways to the local fixed-line network.

The host 301 may comprise at least one host (computing) device 315 communicatively connected at least to the terminal device 307 and the FRER-capable bridge 304 (connections not shown in Figure 3A). Said at least one host device 315 (equally called a host control device or a host controller) may further be communicatively connected to a centralized network controller (CNC) of the TSN bridged network, as depicted in Figure 2. Said at least one host device 315 may serve as a (centralized) controller of the host 301 and may, in that role, monitor and/or control the operation of the other elements of the host 301 or at least some of them (i.e., of the TSN listener end devices 302, 303, the FRER-capable bridge 304, the DS-TTs 305, 306, and/or the terminal device 307). Said at least one host device 315 may be configured to receive configuration information pertaining to the host 301 from the CNC.

The host 301 (or specifically said at least one host device) may maintain, in a memory, information on the (E2E) FRER configuration. Said E2E FRER configuration may have been obtained through either o E2E FRER bridge configuration specified in IEEE 802.1CB and using simple management protocol (SNMP)/management information base (M1B) or RESTCONF/NESTCONF yet another next generation (YANG) models, or o application specific interfaces such as Profinet or object linking and embedding for process control unified architecture (OPC UA).

Said FRER configuration information may be used for identifying protocol data unit (PDU) session (or equally QoS flows) transporting redundant TSN member streams as configured by FRER, as will be discussed in more detail below.

The systems 320, 340, 360 of Figures 3B, 3C and 3D correspond, for the most part, to the system 300 of Figure 3A as discussed above. Namely, elements 321 to 326 and 329 to 335 of Figure 3B may correspond fully to elements 301 to 306, 308 to 313 and 315 of Figure 3A, respectively. Further, elements 341 to 353 and 355 of Figure 3C may correspond fully to elements 301 to 306, 308 to 313 and 315 of Figure 3A, respectively. Also, elements 361 to 366 and 369 to 375 of Figure 3D may correspond fully to elements 301 to 306, 308 to 313 and 315 of Figure 3A, respectively. However, it should be noted that the at least one host computing device 335, 375 of Figures 3B and 3C may be communicatively connected to both of the two terminal devices 327, 328, 367, 368 (i.e., not only to a single terminal device as in the case of Figure 3A). In the following, only the differences of systems 320, 340, 360 of Figures 3B, 3C and 3D relative to the system 300 of Figure 3A are discussed for brevity.

The system 320 of Figure 3B differs from the system of Figure 3A in that the host 301 comprises first and second terminal devices 327, 328 communicatively connected to or comprising, respectively, the first and second DS-TTs 325, 326. Said first and second terminal devices 327, 328 are further communicatively connected, respectively, via first and second 5GS TSN bridges 329, 330. The connection of the first and second terminal devices 327, 328 to the first and second 5GS TSN bridges 329, 330 may be provided via first (communication) interfaces of the first and second terminal device 327, 328. If the first and second DS-TTs 325, 326 do not form a part of the first and second terminal devices 327, 328, the connection of the firstand second terminal devices 327, 328 to the firstand second DS-TTs 325, 326 may be provided via second (communication) interfaces of the first and second terminal device 327, 328.

The system 340 of Figure 3C differs from the system of Figure 3A in that the first and second TSN listener end devices 342, 343 (LI & L2) do not form a part of the host 341 (i.e., they are external to the host 341). Nevertheless, the first and second TSN listener end devices 342, 343 are communicatively connected to the host 341. The first and second TSN listener end devices 342, 343 may be remote devices (with the host 341 being a local device). In this case, the host 341 may specifically correspond to customer premises equipment (CPE). Customer premises equipment (CPE) may, according to a general definition of the term, comprise telecommunications and information technology equipment kept at a physical location of a customer rather than in premises of the service provider.

The system 360 of Figure 3D corresponds to a system exhibiting both of the differences relative to the system of Figure 3A discussed in connection with Figures 3B and 3C. Namely, the host 361 comprises first and second terminal devices 367, 368 communicatively connected to or comprising, respectively, the first and second DS-TTs 365, 366 and communicatively connected, respectively, via first and second 5GS TSN bridges 369, 370, and the first and second TSN listener end devices 362, 363 do not form a part of the host 361 (i.e., they are external to the host 361). The definitions provided in connection with Figures 3B and 3C may apply also here.

While, in Figures 3A, 3B, 3C and 3D, the host 301, 321, 341, 361 comprised or was (directly) connected to TSN listener end devices 302, 303, 322, 323, 342, 343, 362, 363, in other embodiments, the host 301, 321, 341, 361 may comprise or be (communicatively) connected to, alternatively or additionally, TSN talker end devices for transmission to a TSN listener device comprised in a TSN bridged network. Figures 4A, 4B, 4C and 4D illustrate four such alternative systems 400, 420, 440, 460 according to embodiments. As described for systems of Figures 3A, 3B, 3C and 3D, any of said systems 300, 320, 340, 360 may form a part of the communication system of Figure 1. While not explicitly shown in Figures 4A, 4B, 4C and 4D, any of the hosts 400, 420, 440, 460 may be communicatively connected to a CNC of the TSN deployment, e.g., as depicted in Figure 2. Referring to Figures 4A and 4B, each of the hosts 401, 421 of the systems 400, 420 comprises first and second TSN talker end devices 402, 403, 422, 423 (T1 & T2) communicatively connected, respectively, via the FRER-capable bridges 404, 424 to the first and second DS-TTs 405, 406, 425, 426. Said first and second TSN talker end devices 402, 403, 422, 423 may be provided, in addition or alternatively to first and second TSN listener end devices, similar to as described in connection with Figures 3A and 3B. Said firstand second talker end devices 402, 403, 422, 423 may be connected to a local fixed-line network. Similar to as described for above embodiments, the host 401, 421 may comprise at least one host (computing) device 415, 435 communicatively connected at least to the terminal device 407 or the firstand second terminal devices 427, 428 and the FRER-capable bridge 404, 424 (connections not shown in Figures 4A & 4B). Said at least one host device 415, 435 may correspond to the at least one host device as described in connection with Figures 3A, 3B, 3C and 3D though obviously in this case, said at least one host device 415, 435 may be configured to monitor and/or control the first and second TSN talker end devices 402, 403, 422, 423 (instead of or in addition to first and second TSN listener end devices).

Further referring to Figures 4A and 4B, the system 400, 420 comprises, in general, the (device-side) host 401, 421 connected via first and second 5GS TSN bridges 408, 409, 428, 429 to a TSN bridged network (formed of elements 408 to 413 & 428 to 433). A TSN listener (L) end device 413, 433 of the TSN bridged network is connected via two different paths of the TSN bridged network (defined by bridges 408, 410, 412 and 409, 411 in Figure 4A or bridges 429, 431, 433 and 430, 432 in Figure 4B, respectively) to two TSN talker end devices 402, 403, 422, 423 (T1 & T2) comprised in the host 401, 421. Thus, the host 401, 421 (or specifically the firstand second TSN talker end devices 402, 403, 422, 423) is capable of transmitting two independent member streams of a compound stream to the TSN listener end device 413, 433.

Referring to Figures 4C and 4D, the systems 440, 460 may correspond, respectively, to the systems 400, 420 of Figures 4A and 4B, apart from the fact that in the systems 440, 460 the first and second TSN talker end devices 442, 443, 462, 463 do not form a part of the host 441, 461 (i.e., they are external to the host 341). Nevertheless, the first and second TSN talker end devices 442, 443, 462, 463 are communicatively connected to the host 441, 461. In that sense, the systems 440, 460 of Figures 4C and 4D are similar to (or analogous with) the systems 340, 360 of Figures 3C and 3D. The first and second TSN talker end devices 442, 443, 462, 463 may be remote devices (with the host 441, 461 being a local device). In this case, the host 441, 461 may specifically correspond to customer premises equipment (CPE).

Apart from the differences described above relating to the different information propagation direction, the discussion provided for Figures 3A, 3B, 3C and 3D applies, mutatis mutandis, for Figures 4A, 4B, 4C and 4D. At least the elements 404 to 412, 424 to 433, 444 to 452, 464 to 473 of Figures 4A, 4B, 4C and 4D may correspond to elements 304 to 312, 324 to 333, 344 to 352, 364 to 373 of Figures 3A, 3B, 3C and 3D, respectively.

One potential use case for the systems discussed in connection with Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C and 4D is Automated Guided Vehicles (AGVs) which are connected through wireless communication with a central AGV sched- uler/orchestrator. The end-station (the host 301, 321, 341, 361 in Figures 3A, 3B, 3C and 3D or the host 401, 421, 441, 461 in Figures 4A, 4B, 4C and 4D) would connect through 5GS with a central AGV scheduler/orchestrator and using local fixed-line communication within the AGV, e.g., with servo-control of wheels. Another potential use case is semi-static robots and machines in end-to-end discrete automation, where the end-to-end automation line may be changed frequently. In this case, the individual machines need to communicate with each other via 5GS while the local communication within the machine is using fixed-line connectivity. Other examples include remote crane control, process automation (e.g., valve control), smart energy infrastructure (e.g., local distribution stations). In all of these use cases, there is a strong interest in highly reliable and possibly redundant communication towards the end-station via 5GS. In addition, the end-station would also merge the individual redundant TSN streams.

Figures 5A and 5B illustrate processes according to embodiments for determining that two TSN streams to be received or transmitted over two 5GS bridges, respectively, are redundant copies of the same E2E TSN streams (i.e., are member streams) and communicating this information to a terminal device. Specifically, Figures 5A and 5B illustrate signaling between a CNC of a TSN deployment, a terminal device, a host (computing) device and a FRER-capable bridge (providing a connection to a local fixed-line network). Figure 5A corresponds to a case where the host is configured to receive data traffic while Figure 5B corresponds to a case where the host is configured to transmit data traffic. The FRER- capable bridge, the host device and the terminal device of Figure 5A may correspond to elements 304, 315, 307 of Figure 3A or elements 344, 355, 347 of Figure 3C, respectively while the FRER-capable bridge, the host device and the terminal device of Figure 5B may correspond to elements 404, 415, 407 of Figure 4A or elements 444, 455, 447 of Figure 4C, respectively. Thus, the procedures of Figure 5A and 5B may be applicable specifically for hosts comprising a (single) terminal device connected to two DS-TTs and two 5GS systems. Also, the FRER-capable bridge, the host (computing) device and the terminal device may form parts of the same host or host system. Also, the terminal device is assumed to be capable of receiving TSN streams via first and second 5GS bridges and of forwarding them via first and second DS-TTs to the FRER-capable bridge. The terminal device of Figures 5A and/or 5B may be either of terminal devices 100, 102 of Figure 1.

Referring to Figure 5A, it may be initially assumed, at least in some embodiments, that the terminal device has been configured with user equipment route selection policy rules (URSP). Thus, the terminal device may maintain, in at least one memory of the terminal device, one or more pre-defined URSP rules. The one or more pre-defined URSP rules may comprise at least one or more traffic descriptors comprising at least one or more data network names (DNNs) and one or more route selection descriptors comprising at least the one or more DNNs and associated single-network slice selection assistance information (S-NSSA1). The combination of a DNN and a S-NSSA1 may be used as an indication that redundant PDU sessions need to be set up. The one or more route selection descriptors may further comprise one or more RSNs and/or one or more PDU session pair identifiers (corresponding to the DNN/S-NSSA1 combinations). One PDU session pair identifier per a pair of redundant PDU sessions may be defined. The host device may be assumed to be configured in a corresponding manner, that is, the data traffic that needs to be sent over redundant PDU sessions needs to be sent with different DNNs from the host device. It may further be assumed that the initial configuration of 5GS bridges to which the terminal device is connected (as shown in Figure 3A or 3C) has been carried out. The configuration is discussed in more detail in connection with Figure 9.

The process of Figure 5A is initiated by the CNC transmitting, in message 501, (E2E) FRER configuration information for the host to the host device. The FRER configuration information may comprise at least sequence recovery function (SRF) information for determining whether received data packets are replicated data packets (i.e., a part of a member stream). Upon receiving the FRER configuration information in block 502, the host device forwards, in message 503, to the FRER configuration information to the FRER-capable bridge. The FRER configuration information is received, in block 504, by the FRER-capable bridge. The FRER configuration may subsequently be stored by the FRER-capable bridge and/or the host device to respective at least one memory.

The host device extracts, in block 505, SRF information from the FRER configuration information. Based on the SRF information, the host device is able to determine which TSN streams are member streams (i.e., duplicated streams) that are recoverable at the FRER-capable bridge. The SRF information may define at least first and second TSN streams which are member streams of a particular compound stream.

The host device detects, in block 506, based on the SRF information that first and second member streams of a compound stream, recoverable at the FRER- capable bridge, are to be received in the host (i.e., in the terminal device). The first and second member streams correspond redundant copies of the same end-to-end TSN stream sent by a given TSN talker end device. In general, the host device may be configured to monitor the operation of the terminal device, the first and second DS-TTs and/or the FRER-capable bridge.

In response to the detecting in block 506, the host device causes, in block 507, the terminal device of the host to establish first and second (redundant) PDU sessions for receiving, respectively, the first and second member streams. In other words, two independent paths for receiving the same data traffic are established.

The causing of the terminal device to establish first and second redundant PDU sessions in block 507 may comprise transmitting a message for establishing said first and second redundant protocol data unit sessions to the terminal device. Before said transmission, the host device may assign first and second DNNs for duplicated data traffic associated with the first and second member streams (respectively). The first and second DNNs may have different values or the same value. The host device may include said first and second DNNs in the message transmitted to the terminal device. In other words, the message may comprise (or consist of) first and/or second DNNs assigned by the host device for the first and / or second member streams for enabling the terminal device to establish said first and/or second PDU sessions. While block 507 is depicted as being carried out by the host device and the terminal device, the establishing of the first and second PDU sessions may also comprise configuring the FRER-capable bridge to merge the received member streams. In some embodiments, said message may correspond to “dummy traffic” for initiating the establishment of the redundant PDU session.

Referring to Figure 5B, the initial assumptions discussed in connection with Figure 5A may apply equally here, at least in connection with some embodiments. Moreover, the initial steps of the procedure of Figure 5B may correspond to the initial steps of Figure 5A. Namely, the CNC initially transmits, in message 511, (E2E) FRER configuration information for the host to the host device. The FRER configuration information may comprise, here, at least sequence splitting function (SSF) information for determining whether data packets to be transmitted by the host are to be duplicated or split before transmission (i.e., whether they form a part of a member stream of a compound stream). Upon receiving the FRER configuration information in block 512, the host device forwards, in message 513, to the FRER configuration information to the FRER-capable bridge. The FRER configuration information is received, in block 514, by the FRER-capable bridge. The FRER configuration may subsequently be stored by the FRER-capable bridge and/or the host device to respective at least one memory.

The host device extracts, in block 515, SSF information from the FRER configuration information. Based on the SSF information, the host device is able to determine which TSN streams are member streams (i.e., duplicated streams) of a compound stream(s) that are created (or generated or split) at the FRER-capable bridge. The SSF information may define at least first and second TSN streams which are member streams of a particular compound stream.

The host device detects, in block 516, based on the SSF information that first and second member streams of a compound stream, created at the FRER-capable bridge, are to be transmitted by the host (i.e., by the terminal device). The first and second member streams correspond to redundant copies of the same end- to-end TSN stream transmitted by first and second TSN talker end devices comprised or communicatively connected to the host. In general, the host device may be configured to monitor the operation of the terminal device, the first and second DS-TTs and/or the FRER-capable bridge.

In response to the detecting in block 516, the host device causes, in block 517, the terminal device of the host to establish first and second (redundant) PDU sessions for transmitting, respectively, the first and second member streams. In other words, two independent paths for transmitting the same data traffic are established. Referring to either of Figures 5A and 5B, the establishing of the first and second protocol data unit sessions for reception or transmission of first and second member streams in block 507 or block 517 may comprise establishing one or more new protocol data unit sessions and/or modifying one or more existing protocol data unit sessions.

While Figures 5A and 5B are defined (primarily) for hosts comprising a single terminal device as shown in Figures 3A, 3C, 4A and 4D, corresponding processes may be defined also for the hosts comprising two terminal devices as shown in Figures 3B, 3D, 4B and 4D, as will be discussed in connection with Figures 8A and 8B. In such embodiments, in response to the detecting in block 506 or 516, the host device causes, in block 507 or 517, first and second terminal devices of the host to establish, respectively, first and second (redundant) PDU sessions for transmitting, respectively, the first and second member streams. Thus, in such embodiments, the data transmission or reception is carried out independently using the first and second terminal devices. In other aspects, the discussion provided in connection with Figures 5A and 5B may apply, mutatis mutandis, also for these embodiments.

In some embodiments, the one or more route selection descriptors may further comprise first and second RSNs and/or a (corresponding) PDU session pair identifier.

Figure 6 illustrates another process according to embodiments for determining that two TSN streams to be transmitted over two 5GS bridges, respectively, are redundant copies of the same E2E TSN streams (i.e., are member streams) and communicating this information to a terminal device. Specifically, Figure 6 illustrates signaling between a CNC of a TSN deployment, a terminal device, a host (computing) device and a FRER-capable bridge (providing a connection to a local fixed-line network). The FRER-capable bridge, the host device and the terminal device of Figure 6 may correspond to elements 404, 415, 407 of Figure 4A or elements 444, 455, 447 of Figure 4C. Thus, the procedure of Figure 6 may be applicable specifically for hosts comprising a terminal device connected to two DS-TTs and two 5GS systems. Also, the FRER-capable bridge, the host (computing) device and the terminal device may form parts of the same host or host system. Also, the terminal device is assumed to be capable of receiving and/or transmitting TSN streams via first and second 5GS bridges and of forwarding and/or receiving them via first and second DS-TTs to the FRER-capable bridge. The terminal device of Figure 6 may be either of terminal devices 100, 102 of Figure 1.

The procedure of Figure 6 corresponds, to some extent, to the procedure of Figure 5B though two key differences exist, as will be discussed below. Any of the initial assumption described in connection with Figure 5A or 5B apply equally here.

The first difference between the procedure of Figure 6 and the procedure of Figure 5B lies in the initial steps for triggering the procedure. Namely, in Figure 6, the procedure is initiated by the CNC transmitting, in message 601, FRER configuration information (directly) to the FRER-capable bridge. The FRER-capa- ble bridge receives said FRER configuration information in block 602. The FRER- capable bridge stores also said FRER configuration information to at least one memory.

In order to have knowledge of the FRER configuration information, the host device retrieves, in message 603, the FRER configuration information (or a part thereof) from the FRER-capable bridge (i.e., from said at least one memory to which it was stored). The host device may retrieve at least SSF information for determining whether data packets to be transmitted are replicated data packets comprised in said FRER configuration information. The retrieving may comprise requesting, by the host device, the FRER configuration information or a part thereof from the FRER-capable bridge, transmitting, by the FRER-capable bridge, upon reception of the request in the FRER-capable bridge, the requested information to the host device and receiving the requested information in the host device.

The alternative method for obtaining the FRER configuration information as discussed in connection with elements 601 to 603 may be employed with any of the processes discussed previously in connection with Figures 5A and 5B. In the case of the process of Figure 5A, at least the SRF information (not the SSF information) may be retrieved from the FRER-capable bridge (in message 603).

The latter part of the procedure of Figure 6 describes a more detailed exemplary implementation of the elements 515 to 517 of Figure 5B. This more detailed implementation may be equally combined with the method for obtaining the FRER configuration information as discussed in connection with elements 501 to 504 of Figure 5A or elements 511 to 514 of Figure 5B. First, the host device extracts, in block 604, SSF information from the FRER configuration information, similar to as described in previous embodiments. However, if only the SSF information is retrieved in messages 603 (as opposed to the FRER configuration information as a whole), block 604 may be omitted.

Also similar to the previous embodiments, the host device detects, in block 605, based on the SSF information that first and second member streams of a compound stream, created at the FRER-capable bridge, are to be transmitted by the host (i.e., by the terminal device).

The host device causes, in block 606, the FRER-capable bridge to duplicate data traffic associated with the first and second member streams. The causing of the duplication of the data traffic by the FRER-capable bridge may comprise, e.g., transmitting at least one message (or request) for duplicating said data traffic associated with the first and second member streams from the host device to the FRER-capable bridge and, upon receiving said at least one message in the FRER- capable bridge, duplicating the data traffic by the FRER-capable bridge.

Then, the host device assigns, in block 607, first and second DNNs respectively to two duplicates of the data traffic. The first and second DNNs may have different values or the same value.

The host device and the FRER-capable bridge transmit, in messages 608, the two duplicates of the data traffic and the first and second DNNs to the terminal device. The two duplicates of the data traffic and the associated first and second DNNs are received, in block 609, by the terminal device.

As described above, the terminal maintains, in at least one memory, one or more pre-defined URSP rules, where the one or more pre-defined URSP rules comprise one or more traffic descriptors comprising one or more DNNs and one or more route selection descriptors comprising the one or more DNNs and associated S-NSSA1. This information may be used by the terminal device for deriving S- NSSAls for the two duplicates of the data traffic. Namely, in response to the first DNN matching a DNN comprised in a traffic descriptor of the one or more traffic descriptors, the terminal device selects, in block 610, a first route selection descriptor defining said first data network name and a first S-NSSA1 for enabling establishing a first PDU session with redundancy. Similarly, in response to the second DNN matching a DNN comprised in a traffic descriptor of the one or more traffic descriptors, the terminal device selects, in block 610, a second route selection descriptor defining said second DNN and a second S-NSSA1 for enabling establishing a second PDU session with redundancy. Specifically, based on the DNN/S-NSSA1 information, the terminal device is capable of employing a reliability enhancement mechanism (e.g., as defined in TS 23.501) for guaranteeing two independent E2E paths through the 5GS without a single point of failure. An example of this procedure is discussed in connection with Figure 7.

The operation of the terminal device described above in connection with blocks 609, 610 may be equally applicable to the scenario discussed in connection with Figure 5A where the host device transmits a message comprising first and second DNNs to the terminal device for enabling the terminal device to establish first and second redundant PDU sessions for receiving first and second member streams.

Figure 7 illustrates a process according to embodiments for using the duplicated data traffic and DNNs communicated to the terminal device and S- NSSAls determined by the terminal device for guaranteeing two independent E2E paths through the 5GS without single point of failure. Correspondingly, the procedure of Figure 7 may be carried out, for example, following the completion of the procedure of Figure 6 or the completion of the corresponding procedure for reception of member streams (as opposed to transmission). Figure 7 illustrates signaling between a terminal device, an access node and a session management function (SMF) of a core network. The communication between the terminal device and the SMF may be provided, in general, via one or more access and/or relay nodes (comprising the illustrated access node) and optionally one or more core network nodes. The terminal device of Figure 7 may correspond to element 407 of Figure 4A or element 447 of Figure 4C. The terminal device of Figure 7 may be either of terminal devices 100, 102 of Figure 1 and the SMF and the AF may be comprised in the core network 110 of Figure 1.

Referring to Figure 7, it may be initially assumed that the terminal device has received two copies of the data traffic pertaining to first and second member stream of a compound stream to be transmitted and associated with first and second DNNs and has derived, based on the one or more pre-defined URSP rules and the first and second DNNs, the corresponding first and second S-NSSAls, as described above.

The terminal device requests, in message 701, establishing of a first PDU session for the first DNN and the first S-NSSA1 from the SMF. Moreover, the terminal device requests, also in message 701, establishing of a second PDU session for the second DNN and the second S-NSSA1 from the SMF. The requesting may comprise transmitting, from the terminal device to the SMF, at least one request for establishing the first and second PDU sessions, where said at least one request comprises the first DNN, the first S-NSSA1, the second DNN and the second S-NSSA1. The requesting of the establishing of the first and/or second PDU session in message 701 may be triggered in response to no existing PDU session matching the first DNN and the first S-NSSA1 and/or the second DNN and the second S-NSSA1.

In response to receiving the request message 701 in block 702, the SMF determines, in block 702, whether the first and second PDU sessions are to be handled redundantly. This determining is based on the first DNN and S-NSSA1 and the second DNN and S-NSSA1 as well as further on policy provided for the first and second PDU sessions by the policy control function (PCF), user subscription configuration and/or local policy configuration maintained in at least one memory of the SMF (assuming dynamic policy and charging control is not used for the PDU session).

If the first PDU session is to be handled redundantly, the SMF determines, in block 703, a first redundancy sequence number (RSN) for the first PDU session based on the first DNN and the first S-NSSA1. Similarly, if the second PDU session is to be handled redundantly, the SMF determines, in block 703, a second RSN for the second PDU session based on the second DNN and the second S-NSSA1. In general, a RSN differentiates PDU sessions that are handled redundantly and indicates redundant user plane requirements for the PDU sessions in (NG-)RAN.

In some alternative embodiments, if the first and second PDU sessions are to be handled redundantly, the SMF determines, in block 703, a PDU session pair identifier based on the first DNN, the first S-NSSA1, the second DNN and the second S-NSSA1 (and local configuration), instead of or in addition to the first and second RSNs.

The SMF transmits, in message 704, the first and second RSNs and/or the PDU session pair identifier to a RAN or specifically an access node serving the terminal device (not shown in Figure 7). The access node receives, in block 705, from the SMF, the first and second RSNs and / or the PDU session pair identifier. The first and second RSNs and/or the PDU session pair identifier indicate to the access node that the first and second PDU session are to be handled redundantly. More specifically, the first and second RSNs and/or the PDU session pair identifier indicate that orthogonal user plane resources in the RAN are needed for the first and second PDU sessions carrying the redundant streams (e.g., different access nodes may be employed for the first and second PDU sessions). Based on the first and second RSNs and/or the PDU session pair identifier and RAN configuration, the RAN (i.e., at least the access node) may set up, in block 706, a dual connectivity involving at least said terminal device in order to ensure the redundant paths for the first and second PDU sessions. According to a general definition, dual connectivity involves two radio network nodes providing radio resources to a given terminal device (with active radio bearers), while a single N2 termination point exists for the terminal device between an access and mobility management function (AMF) and the RAN.

In some embodiments, the SMF may further consider the first and second RSNs and/or the PDU session pair identifier for selecting and configuring user plane functions (UPFs).

Figures 8A and 8B illustrates a process according to embodiments for determining that two TSN streams to be transmitted over two 5GS bridges, respectively, are redundant copies of the same E2E TSN streams (i.e., are member streams) and communicating this information to first and second terminal devices. Specifically, Figures 8A and 8B illustrates signaling between a CNC of a TSN deployment, first and second terminal devices, a host (computing) device and a FRER- capable bridge (providing a connection to a local fixed-line network). The FRER- capable bridge, the host device and the first and second terminal devices of Figure 8A may correspond to elements 324, 335, 327, 328 of Figure 3B or elements 364, 375, 367, 368 of Figure 3D, respectively, while the FRER-capable bridge, the host device and the first and second terminal devices of Figure 8B may correspond to elements 424, 435, 427, 428 of Figure 4B or elements 464, 475, 467, 468 of Figure 4D, respectively. Thus, the FRER-capable bridge, the host (computing) device and the first and second terminal device may form parts of the same host or host system. Also, the first and second terminal devices are assumed to be capable of receiving and/or transmitting TSN streams via first and second 5GS bridges and of forwarding and/or receiving them via first and second DS-TTs to the FRER-capable bridge, respectively. Each of the first and second terminal devices of Figure 8A and/or 8B may be either of terminal devices 100, 102 of Figure 1.

Referring to either of Figures 8A or 8B, it may be initially assumed that both the first and second terminal devices has been configured with URSP rules. Thus, the first terminal device may maintain, in at least one memory of the first terminal device, one or more first pre-defined URSP rules, and the second terminal device may maintain, in at least one memory of the second terminal device, one or more second pre-defined URSP rules. The one or more first pre-defined URSP rules and the one or more second pre-defined URSP rules may optionally be defined to be the same. The one or more first pre-defined URSP rules and/or the one or more second pre-defined URSP rules may (each) comprise at least one or more traffic descriptors comprising one or more data network names (DNNs) and one or more route selection descriptors comprising the one or more DNNs and associated single-network slice selection assistance information (S-NSSA1). The combination of a DNN and a S-NSSA1 may be used as an indication that redundant PDU sessions need to be set up. The one or more route selection descriptors may further comprise one or more RSNs and/or one or more PDU session pairs (corresponding to the DNN/S- NSSA1 combination pairs). The host device may be assumed to be configured in a corresponding manner, that is, the data traffic that needs to be sent over redundant PDU sessions needs to be sent with different DNNs from the host device. It may further be assumed that the initial configuration of 5GS bridges to which, respectively, the first and second terminal devices are connected (as shown in Figure 3B or 3D) has been carried out. The configuration is discussed in more detail in connection with Figure 8.

The initial actions relating to either of the procedures of Figures 8A and 8B may correspond to actions which were previously described in connection with Figure 5A/5B or 6. Namely, actions pertaining to elements 501 to 504 of Figure 5A or equally elements 511 to 514 of Figure 5B or to elements 601 to 603 of Figure 6 may be carried out in block 801 of Figure 8A and/or block 811 of Figure 8B.

The following steps are also very similar to the ones discussed in connection with Figure 5A or 5B.

Referring specifically to Figure 8A, the host device extracts, in block 802, SRF information from the FRER configuration information. Based on the SRF information, the host device is able to determine which TSN streams are member streams (i.e., duplicated streams) of a compound stream that are recoverable at the FRER-capable bridge. The SRF information may define here at least first and second TSN streams which are member streams of a compound stream.

The host device detects, in block 803, based on the SRF information, that said first and second member streams of a compound stream, recoverable at the FRER-capable bridge, are to be received by the host.

In response to the detecting in block 803, the host device causes, in block 804, the first terminal device of the host and the second terminal device of the host, respectively, to establish first and second redundant PDU sessions for receiving, respectively, the first and second member streams. The causing of the establishing of the first and second PDU sessions in block 804 may comprise transmitting a first message (or a first request) for establishing the first redundant protocol data unit session to the first terminal device and a second message (or a second request) for establishing the second redundant protocol data unit session to the second terminal device. Before said transmission, the host device may assign first and second first and second DNNs for duplicated data traffic associated with the first and second member streams (respectively). The first and second DNNs may have different values or the same value. The host device may include said first and second DNNs, respectively, in the first and second messages transmitted to the terminal device. In other words, the first message may comprise (or consist of) a first DNN assigned (by the host device) for the first member stream for enabling the first terminal device to establish said first PDU session. Correspondingly, the second message may comprise (or consist of) a second DNN assigned (by the host device) for the second member stream for enabling the second terminal device to establish said second PDU session. While block 804 is depicted as being carried out by the host device and the first and second terminal devices, the establishing of the first and second PDU sessions may also comprise configuring the FRER-capable bridge to merge the received member streams.

The two duplicates of the data traffic and the associated first and second DNNs may be subsequently received by the first and second terminal devices, respectively. The first and second terminal devices may be configured to perform the following (not shown in Figure 8A). In response to the first DNN matching a DNN comprised in a traffic descriptor of the one or more traffic descriptors, the first terminal device selects a first route selection descriptor defining said first data network name and a first S-NSSA1 for enabling establishing a first PDU session with redundancy. Similarly, in response to the second DNN matching a DNN comprised in a traffic descriptor of the one or more traffic descriptors, the second terminal device selects a second route selection descriptor defining said second DNN and a second S-NSSA1 for enabling establishing a second PDU session with redundancy. Specifically, based on the DNN/S-NSSA1 information, the first and second terminal devices are capable of employing a reliability enhancement mechanism (e.g., as defined in TS 23.501) for guaranteeing two independent E2E paths through the 5GS without a single point of failure. An example of this procedure is discussed in connection with Figure 9.

Referring specifically to Figure 8B, the host device extracts, in block 812, SSF information from the FRER configuration information. Based on the SSF information, the host device is able to determine which TSN streams are member streams (i.e., duplicated streams) of a compound stream created at the FRER-capa- ble bridge and to be transmitted by the host. The SSF information may define here at least first and second TSN streams which are member streams of a compound stream.

The host device detects, in block 813, based on the SSF information, that first and second member streams of a compound stream, created at the FRER-ca- pable bridge, are to be transmitted by the host.

In response to the detecting in block 813, the host device causes, in block 814, the first terminal device of the host and the second terminal device of the host, respectively, to establish first and second redundant PDU sessions for transmitting, respectively, the first and second member streams. The causing of the establishing of the first and second PDU sessions in block 814 may comprise carrying out a process similar to the one described in connection with elements 606 to 610 of Figure 6 though, in this case, the host device and the FRER-capable bridge obviously communicates with both the first and second terminal devices.

Specially, the block 814 may comprise the following steps (analogous with the steps described in connection with elements 606 to 610 of Figure 6). The host device causes duplication of data traffic associated with the first and second member streams by the FRER-capable bridge and assigns first and second DNNs respectively to two duplicates of the data traffic. The FRER-capable bridge transmits the two duplicates of the data traffic to the first and second terminal devices, respectively, while the host device transmits the first and second DNNs, respectively, to the first and second terminal devices.

The two duplicates of the data traffic and the associated first and second DNNs may be subsequently received by the first and second terminal devices, respectively. The first and second terminal devices may be configured to perform, based on the first and second DNNs, the steps described above in connection with Figure 8A for enabling establishing first and second PDU sessions with redundancy (not shown in Figure 8B). Thus, in response to the first DNN matching a DNN comprised in a traffic descriptor of the one or more traffic descriptors, the first terminal device selects a first route selection descriptor defining said first data network name and a first S-NSSA1 for enabling establishing a first PDU session with redundancy. Similarly, in response to the second DNN matching a DNN comprised in a traffic descriptor of the one or more traffic descriptors, the second terminal device selects a second route selection descriptor defining said second DNN and a second S-NSSAI for enabling establishing a second PDU session with redundancy. Specifically, based on the DNN /S-NSSAI information, the first and second terminal devices are capable of employing a reliability enhancement mechanism (e.g., as defined in TS 23.501) for guaranteeing two independent E2E paths through the 5GS without a single point of failure.

Figure 9 illustrates a process according to embodiments for using the duplicated data traffic and DNNs communicated to the first and second terminal devices and S-NSSAls determined by the first and second terminal devices for guaranteeing two independent E2E paths through the 5GS without single point of failure. Correspondingly, the procedure of Figure 9 may be carried out following the completion of the procedure of Figure 8A or 8B. Figure 9 illustrates signaling between first and second terminal devices, an access node and a session management function (SMF) of a core network. The communication between the first and second terminal devices and the SMF may, in general, be provided via one or more access and/or relay nodes (comprising the illustrated access node) and optionally one or more core network nodes. The first and/or second terminal devices of Figure 9 may correspond to elements 327, 328 of Figure 3B, elements 367, 368 of Figure 3D, elements 427, 428 of Figure 4B or elements 467, 468 of Figure 4D, respectively. The first and/or second terminal devices of Figure 9 may be either of terminal devices 100, 102 of Figure 1 and the SMF may be comprised in the core network 110 of Figure 1.

The procedure of Figure 9 is analogous with the procedure of Figure 7 with the difference that the functions of the terminal device relating to the first and second PDU sessions in Figure 7 are performed, in Figure 9, separately by the first and second terminal devices. Any of the definitions provided in connection with Figure 7 apply, mutatis mutandis, for the procedure of Figure 9.

Referring to Figure 9, it may be initially assumed that the first terminal device has received a first copy of the data traffic pertaining to a first member stream of a compound stream and associated with a first DNN and has derived, based on the one or more first pre-defined URSP rules and the first DNN, the corresponding first S-NSSAI, as described above. Similarly, it is assumed that the second terminal device has received a second copy of the data traffic pertaining to a second member stream of a compound stream and associated with a second DNN and has derived, based on one or more second pre-defined URSP rules and the second DNN, the corresponding second S-NSSAI The first terminal device requests, in message 901, establishing of a first PDU session for the first DNN and the first S-NSSA1 from the SMF. Moreover, the second terminal device requests, in message 902, establishing of a second PDU session for the second DNN and the second S-NSSA1 from the SMF. The requesting in message 901 may comprise transmitting, from the first terminal device to the SMF, at least one first request for establishing the first PDU session, where said at least one first request comprises the first DNN and the first S-NSSA1. The requesting in message 902 may comprise transmitting, from the second terminal device to the SMF, at least one second request for establishing the second PDU session, where said at least one second request comprises the second DNN and the second S- NSSA1. The requesting of the establishing of the first and/or second PDU session in message 901 and/or 902 may be triggered in response to no existing PDU session matching the first DNN and the first S-NSSA1 and/or the second DNN and the second S-NSSA1, respectively.

In response to receiving the first and second request messages 901, 902 in block 903, the SMF determines, in block 904, whether the first and second PDU sessions are to be handled redundantly. This determining is based on the first DNN, the first S-NSSA1, the second DNN and the second S-NSSA1 as well as further on policy provided for the first and second PDU sessions by the policy control function (PCF), user subscription configuration and/or local policy configuration maintained in at least one memory of the SMF.

If the first PDU session is to be handled redundantly, the SMF determines, in block 904, a first RSN for the first PDU session based on the first DNN and the first S-NSSA1. Similarly, if the second PDU session is to be handled redundantly, the SMF determines, in block 904, a second RSN for the second PDU session based on the second DNN and the second S-NSSA1. Alternatively, the SMF may determine a single PDU session pair identifier for the first and second PDU sessions based on the first and second DNNs and the first and second S-NSSAls (and local configuration.

The SMF transmits, in message 905, the first RSN or the PDU session pair identifier and the second RSN or the PDU session pair identifier to the RAN (or specifically to the access node). The access node receives, in block 906, from the SMF, the first and second RSNs or the PDU session pair identifier. The first and second RSNs or the PDU session pair identifier indicate to the access node that the first and second PDU session are to be handled redundantly. More specifically, the first and second RSNs or the PDU session pair identifier indicate(s) that orthogonal user plane resources in the RAN are needed for the first and second PDU sessions carrying the redundant streams (e.g., different access nodes may be employed for the first and second PDU sessions). Based on the first and second RSNs or the PDU session pair identifier and RAN configuration, the RAN (i.e., at least the access node) may set up, in block 907, a dual connectivity in order to ensure the redundant paths for the first and second PDU sessions.

Figure 10 illustrates a procedure for initial configuration of a system according to embodiments. Said configuration may precede any of the processes discussed in connection with preceding Figures. Specifically, Figure 10 illustrates signaling between a host device, a terminal device, a SMF, an application function (AF), a CNC of a TSN deployment and a CUC of the TSN deployment. The host device and the terminal device of Figure 10 may correspond to elements 315, 307 of Figure 3A, elements 415, 407 of Figure 4A, elements 355, 347 of Figure 3C or elements 455, 447 of Figure 4C, respectively. Thus, the host (computing) device and terminal device may form parts of the same host or host system. Also, the terminal device is assumed to be capable of receiving and/or transmitting TSN streams via first and second 5GS bridges and of forwarding and/or receiving them via first and second DS-TTs to a FRER-capable bridge, respectively, as discussed in connection with above embodiments. The terminal device of Figure 10 may be either of terminal devices 100, 102 of Figure 1 and the SMF and the AF may be comprised in the core network 110 of Figure 1.

Referring to Figure 10, the host device may configure, in block 1001, the terminal device to employ one or more pre-defined URSP rules. Corresponding configuration may be implemented, in block 1001, also for the host device itself and/or, if the host comprises multiple terminal devices, for another terminal device of the host (not shown in Figure 10). As described above, the one or more predefined URSP rules define the way in which duplicated traffic received from the host device (and which will be further on associated to the redundant PDU sessions) is handled at the terminal device.

Said one or more pre-defined URSP rules may be defined as described in connection with above embodiments. To summarize, the incoming traffic needs to be differentiated by two distinct traffic descriptors. Such traffic descriptors need to have different DNNs so that the two redundant PDU Sessions are matched to the route selection descriptors of distinct URSP rules. The route selection descriptor will contain also the distinct S-NSSA1 value, which in combination with DNN will serve as indication that redundant PDU sessions need to be set up. The host device needs to be configured accordingly, i.e., the traffic that needs to be sent over redundant PDU sessions needs to be sent with different DNNs from the host device.

It is assumed in Figure 10 that the terminal device and associated first and second DS-TTs are set up as part of first and second 5GS bridges, respectively. Each 5GS bridge has an associated AF (communicatively connected to the CNC) and a UPF. This initial setting up comprises setting up, in message 1002, PDU Sessions (and QoS flows) and DS-TT ports.

The AF transmits, in message 1003, information on the 5GS bridge capabilities for the first and second 5GS bridges to the CNC.

To set up a TSN bridged network, the TSN talker and listener end devices provide application requirements to the CUC (not shown in Figure 10). The CUC, in turn, transmits, in message 1005, network requirements of the TSN bridged network to the CNC.

Upon receiving the network requirements in block 1006, the CNC determines, in block 1006, the configurations of individual bridges of the TSN bridged network (comprising the first and second 5GS bridges and one or more further bridges). The FRER configuration information is determined in this step. The configurations of the first and second 5GS bridges are then transmitted, in message 1007, 1008, to the AF. Upon receiving the configurations in block 1009, the AF causes configuring, in block 1009, the firstand second 5GS bridges according to the received configurations. The CNC may further cause configuration of the one or more other bridges of the TSN bridged network (not shown in Figure 10).

While the procedure of Figure 10 was discussed above in reference to the system of Figures 3A, 3C, 4A and 4C (i.e., the systems where the host comprises a single terminal device), the illustrated procedure may be applied, mutatis mutandis, also the systems of Figures 3B, 3D, 4B and 4D (i.e., the systems where the host comprises a first and second terminal device). The only changes needed for the procedure of Figure 10 when it is applied to said alternative systems according to embodiments is that the URSP pre-configuration in block 1001 is carried out for both the first and second terminal devices and subsequently both the first and second terminal devices carry out PDU session establishment (i.e., actions relating to message 1002). While above embodiments used specifically data network names (DNNs) as redundancy identifiers, other redundancy identifiers may be used in other embodiments for the same purpose as the DNNs were used above. Thus, the first DNN, the second DNN and/or the one or more DNNs as used in the above embodiments may be replaced, in more general embodiments, with a first redundancy identifier, a second redundancy identifier and one or more redundancy identifiers, respectively. Correspondingly, the one or more (first and/or second) pre-defined URSP rules as used in embodiments may (each) comprise at least one or more traffic descriptors comprising one or more redundancy identifiers and one or more route selection descriptors comprising the one or more redundancy identifiers and associated single-network slice selection assistance information (S-NSSA1). Similar to as described for the first and second DNNs, the first and second redundancy identifiers may have the same value or different values.

The blocks, related functions, and information exchanges described above by means of Figures 5A, 5B, 6, 7, 8A, 8B, and 9 are in no absolute chronological order, and some of them may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between them or within them, and other information may be sent and/or received, and/or other mapping rules applied. Some of the blocks or part of the blocks or one or more pieces of information can also be left out or replaced by a corresponding block or part of the block or one or more pieces of information.

Figure 11 provides an apparatus 1101 according to some embodiments. Figure 11 may illustrate a terminal device or a part thereof (e.g., a computing device comprised in the terminal device) configured to carry out at least the functions described above in connection with the terminal device (and/or the first and/or second terminal devices). The apparatus 1101 may correspond to any of the terminal devices 100, 102 of Figure 1, the terminal device 307 of Figure 3A, the first and/or second terminal devices 327, 328 of Figure 3B, the terminal device 347 of Figure 3C, the first and/or second terminal devices 367, 368 of Figure 3D, the terminal device 407 of Figure 4A, the first and/or second terminal devices 427, 428 of Figure 4B, the terminal device 447 of Figure 4C and/or the first and/or second terminal devices 467, 468 of Figure 4D.

The apparatus 1101 may comprise one or more communication control circuitry 1120, such as at least one processor, and at least one memory 1130, including one or more algorithms 1131, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause, respectively, the apparatus to carry out any one of the exemplified functionalities of the terminal device (and/or the first and/or second terminal devices) as described above.

Referring to Figure 11, the communication control circuitry 1120 of the apparatus 1101 comprises at least redundancy handling circuitry 1121. The redundancy handling circuitry 1121 may be configured to carry out at least some of the functionalities of the terminal device (and/or the first and/or second terminal device) described above by means of any of Figures 5A, 5B, 6, 7, 8A, 8B and 9 using one or more individual circuitries.

The at least one memory 1130 may comprise at least one database 1132 which may comprise, for example, at least one or more pre-defined URSP rules. Said at least one database 1132 may further comprise, for example, one or more DNN /S- NSSA1 pairs (or, more generally, one or more redundancy identifier/S-NSSAl) for one or more PDU sessions, one or more RSNs and/or one or more PDU session pair identifiers. Each memory 1130 may comprise software and at last one database. The memory 1130 may also comprise other databases which may not be related to the functionalities of the apparatus according to any of presented embodiments. The at least one memory 1130 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

Referring to Figure 11, the apparatus 1101 may further comprise different interfaces 1110 such as one or more communication interfaces (TX/RX) comprising hardware and/or software for realizing communication connectivity over one or more communications network according to one or more communication protocols. Specifically, the one or more communication interfaces 1110 may provide the apparatus with communication capabilities to communicate in one or more mobile network and enable communication with one or more access nodes, one or more terminal devices (possibly via said plurality of access nodes) and/or one or more other network nodes or elements. The one or more communication interfaces 1110 may enable communication with the host device of the host of which the apparatus 1101 forms a part. Moreover, the one or more communication interfaces 1110 may enable via one or more DS-TTs (which may be further connected to a FRER-capable bridge) and/or one or more 5GS (TSN) bridges. The one or more communication interfaces 1110 may comprise standard well-known components such as an amplifier, filter, frequency-converter, analog- to-digital converts, (de) modulator, and encoder/decoder circuitries, controlled by the corresponding controlling units, and one or more antennas.

Figure 12 provides an apparatus 1201 according to some embodiments. The apparatus 1201 may be a host (computing) device comprised in a host. The apparatus 1201 may be configured to carry out at least the functions described above in connection the host device. The apparatus 1201 may correspond to any of the host devices 315, 335, 355, 375, 415, 435, 455, 475 of Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C and 4D.

The apparatus 1201 may comprise one or more communication control circuitry 1220, such as at least one processor, and at least one memory 1230, including one or more algorithms 1231, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause, respectively, the apparatus to carry out any one of the exemplified functionalities of the host device described above.

Referring to Figure 12, the communication control circuitry 1220 of the apparatus 1201 comprises at least redundancy handling control circuitry 1221. The redundancy handling control circuitry 1221 may be configured to configure terminal devices (and possible the FRER-capable bridge of the host) to handle TSN member streams in a redundant manner according to embodiments and, to this end, to carry out at least some of the functionalities described above by means of any of Figures 5A, 5B, 6, 8A, 8B and 10 using one or more individual circuitries.

The at least one memory 1230 may comprise at least one database 1232 which may comprise, for example, FRER configuration information and/or SRF information and/or SSF information. Each memory 1230 may comprise software and at last one database. The at least one memory 1230 may also comprise other databases which may not be related to the functionalities of the apparatus according to any of presented embodiments. The at least one memory 1230 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

Referring to Figure 12, the apparatus may further comprise different interfaces 1210 such as one or more communication interfaces (TX/RX) comprising hardware and/or software for realizing communication connectivity over one or more communications network according to one or more communication protocols. Specifically, the one or more communication interfaces 1210 may provide the apparatus 1201 with communication capabilities to enable communication at least with one or more terminal devices, one or more FRER-capable bridges (of the host), one or more CNCs, one or more access nodes and/or one or more core network nodes.

The one or more communication interfaces 1210 may comprise standard well-known component(s) such as an amplifier, filter, frequency-converter, an- alog-to-digital converts, (de)modulator, and encoder/decoder circuitries, controlled by the corresponding controlling units, and/or one or more antennas.

As used in this application, the term ‘circuitry’ may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software (and/or firmware), such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software /firm ware and (ii) any portions of hardware processor(s) with software, including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus, such as a terminal device or an access node, to perform various functions, and (c) hardware circuit(s) and processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g. firmware) for operation, but the software may not be present when it is not needed for operation. This definition of ‘circuitry’ applies to all uses of this term in this application, including any claims. As a further example, as used in this application, the term ‘circuitry’ also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term ‘circuitry’ also covers, for example and if applicable to the particular claim element, a baseband integrated circuit for an access node or a terminal device or other computing or network device.

In embodiments, the at least one processor, the memory, and the computer program code form (processing) means for or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C, 4D, 5A, 5B, 6, 7, 8A, 8B, and 9 or operations thereof.

In an embodiment, at least some of the processes described in connection with of Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C, 4D, 5A, 5B, 6, 7, 8A, 8B, and 9 may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C, 4D, 5A, 5B, 6, 7, 8A, 8B, and 9 or operations thereof.

According to an aspect, there is provided an apparatus (e.g., a host (computing) device or a part thereof) comprising means for performing: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

According to an aspect, there is provided an apparatus (e.g., a host (computing) device or a part thereof) comprising means for performing: obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams.

The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatuses) of embodiments may be implemented within one or more applicationspecific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chipset (procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and/or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art.

Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with Figures 3A, 3B, 3C, 3D, 4A, 4B, 4C, 4D, 5A, 5B, 6, 7, 8A, 8B, and 9 may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program maybe provided as a computer readable medium comprising program instructions stored thereon or as a non-transitory computer readable medium comprising program instructions stored thereon. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

A computer program stored in a computer-readable storage medium, the program comprising software code for performing the steps of: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

A computer readable storage medium having a computer program embodied therewith, wherein the computer program executable by a processor to cause the processor to perform a method: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method comprising: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

A computer program stored in a computer-readable storage medium, the program comprising software code for performing the steps of: obtaining frame replication and elimination for reliability configuration information for a host; obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams

A computer readable storage medium having a computer program embodied therewith, wherein the computer program executable by a processor to cause the processor to perform a method: obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams

A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when loaded into an apparatus, execute a method comprising: obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams

Even though the invention has been described above with reference to examples according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

43 CLAIMS

1. An apparatus comprising: at least one processor, and at least one memory for storing instructions to be executed by the at least one processor, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to perform: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

2. The apparatus of claim 1, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to cause the establishing of the first and second redundant protocol data unit sessions by performing the following: transmitting a message for establishing said first and second redundant protocol data unit sessions to the first terminal device; or transmitting a first message for establishing the first redundant protocol data unit session to the first terminal device and a second message for establishing the second redundant protocol data unit session to the second terminal device.

3. The apparatus of claim 2, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform the establishing of the first and second protocol data unit sessions by performing the following: 44 assigning first and second redundancy identifiers for duplicated data traffic associated with the first and second member streams; and including the first and second redundancy identifiers in the message; or including the first redundancy identifier in the first message and the second redundancy identifier in the second message.

4. An apparatus comprising: at least one processor, and at least one memory for storing instructions to be executed by the at least one processor, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to perform: obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams.

5. The apparatus of claim 4, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to cause the establishing of the first and second protocol data unit sessions by performing the following: causing the frame replication and elimination for reliability -capable bridge to duplicate data traffic associated with the first and second member streams; 45 assigning first and second redundancy identifiers respectively to two duplicates of the data traffic; and causing transmitting the first and second redundancy identifiers to the first terminal device or, respectively, to the first and second terminal devices.

6. The apparatus according to any preceding claim, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform the obtaining of the frame replication and elimination for reliability configuration information by receiving the frame replication and elimination for reliability configuration information from a centralized network controller of a time-sensitive networking bridged network.

7. The apparatus according to claim 6, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform: in response to the receiving of the frame replication and elimination for reliability configuration information, forwarding the frame replication and elimination for reliability configuration information to the frame replication and elimination for reliability -capable bridge.

8. The apparatus according to any preceding claim, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform the obtaining of the frame replication and elimination for reliability configuration information by retrieving the frame replication and elimination for reliability configuration information from the frame replication and elimination for reliability -capable bridge of the host.

9. The apparatus according to claim 3 or 5, wherein the first and second redundancy identifiers are first and second data network names.

10. The apparatus according to any of claims 3, 5 and 9, wherein the first and second redundancy identifiers have the same value.

11. The apparatus according to any preceding claim, wherein the establishment of the first and second protocol data unit sessions comprises establishing one or more new protocol data unit sessions and/or modifying one or more existing protocol data unit sessions.

12. The apparatus according to any preceding claim, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform, before the obtaining: causing configuring at least the apparatus and the first terminal device with one or more user equipment route selection policy rules, wherein the one or more user equipment route selection policy rules comprise one or more traffic descriptors comprising one or more redundancy identifiers and one or more route selection descriptors comprising the one or more redundancy identifiers and associated single-network slice selection assistance information, the one or more redundancy identifiers comprising at least the first and second redundancy identifiers.

13. The apparatus according to claim 12, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform, before the obtaining: causing configuring the second terminal device with said one or more user equipment route selection policy rules.

14. The apparatus according to any preceding claim, wherein the apparatus is a host device for the host or a part of said host device, the host comprising the frame replication and elimination for reliability -capable bridge, the first terminal device, a first device-side time-sensitive networking translator connected or comprised in the first terminal device, the second terminal device, a second device-side time-sensitive networking translator connected or comprised in the second terminal device or the host comprising the frame replication and elimination for reliability -capable bridge, the first terminal device, the first device-side time-sensitive networking translator connected or comprised in the first terminal device and a second device-side time-sensitive networking translator connected or comprised in the first terminal device.

15. The apparatus according to claim 14, wherein the host is customer premises equipment or a fully integrated host comprising one or more time-sensitive networking end devices.

16. A host comprising: a first terminal device for connecting to first and second 5G-system time-sensitive networking bridges; first and second device-side time-sensitive networking translators communicatively connected or comprised in the first terminal device; a frame replication and elimination for reliability -capable bridge communicatively connected to the first terminal device via the first and second de- vice-side time-sensitive networking translators; and a host device being or comprising an apparatus according to any of claims 1 to 15 communicatively connected at least to the first terminal device and the frame replication and elimination for reliability -capable bridge, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform the causing of the first terminal device of the host to establish the first and second redundant protocol data unit sessions.

17. A host comprising: a first terminal device for connecting to a first 5G-system time-sensitive networking bridge; a second terminal device for connecting to a second 5G-system timesensitive networking bridge; a first device-side time-sensitive networking translator communicatively connected to or comprised in the first terminal device; a second device-side time-sensitive networking translators communicatively connected to or comprised in the second terminal device; a frame replication and elimination for reliability -capable bridge communicatively connected to the first and second terminal devices via the first and second device-side time-sensitive networking translators; and a host device being or comprising an apparatus according to any of claims 1 to 15 communicatively connected at least to the first and second terminal devices and the frame replication and elimination for reliability -capable bridge, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus to perform the causing of the 48 first and second terminal devices of the host to establish the first and second redundant protocol data unit sessions.

18. The host of claim 16 or 17, further comprising: one or more time-sensitive networking listener end devices communicatively connected to the frame replication and elimination for reliability -capable bridge; and/or one or more time-sensitive networking talker end devices communicatively connected to the frame replication and elimination for reliability -capable bridge.

19. The host according to any of claims 16 to 18, wherein the first terminal device comprises at least one memory for storing instructions to be executed by the at least one processor, wherein the at least one memory and the instructions are configured to, with the at least one processor, cause the first terminal device at least to perform: maintaining, in said at least one memory, one or more pre-defined user equipment route selection policy rules, wherein the one or more pre-defined user equipment route selection policy rules comprise one or more traffic descriptors comprising one or more redundancy identifiers and one or more route selection descriptors comprising the one or more redundancy identifiers and associated single-network slice selection assistance information; receiving, from the host device of the host, a first redundancy identifier associated with a first member stream of a compound stream to be transmitted or received; and in response to the first redundancy identifier matching a redundancy identifier comprised in a traffic descriptor of the one or more traffic descriptors, selecting a route selection descriptor defining said first redundancy identifier and first single-network slice selection assistance information for enabling establishing a first protocol data unit session with redundancy.

20. A method comprising: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; 49 detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

21. A method comprising: obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams.

22. A computer program product, embodied on a non-transitory computer readable medium, comprising program instructions, that when run is adapted to perform: obtaining frame replication and elimination for reliability configuration information for a host; extracting sequence recovery function information from the frame replication and elimination for reliability configuration information; detecting, based on the sequence recovery function information, that first and second member streams of a compound stream, recoverable at a frame 50 replication and elimination for reliability -capable bridge of the host, are to be received in the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for receiving, respectively, the first and second member streams.

23. A computer program product, embodied on a non-transitory computer readable medium, comprising program instructions, that when run is adapted to perform: obtaining frame replication and elimination for reliability configuration information for a host comprising a frame replication and elimination for reliability -capable bridge, first and second device-side time-sensitive networking translators and a first terminal device or the first terminal device and a second terminal device; extracting stream splitting function information from the frame replication and elimination for reliability configuration information; detecting, based on the stream splitting function information, that first and second member streams of a compound stream, created at a frame replication and elimination for reliability -capable bridge of the host, are to be transmitted by the host; and in response to the detecting, causing a first terminal device of the host or the first terminal device and a second terminal device of the host, respectively, to establish first and second redundant protocol data unit sessions for transmitting, respectively, the first and second member streams.