WO2023079340A1

WO2023079340A1 - Method, apparatus, and computer program product for local bridging using a multiport device

Info

Publication number: WO2023079340A1
Application number: PCT/IB2021/060237
Authority: WO
Inventors: Markus Sakari ISOMÄKI; Markus STAUFER
Original assignee: Nokia Technologies Oy
Priority date: 2021-11-04
Filing date: 2021-11-04
Publication date: 2023-05-11

Abstract

Method, apparatuses, and computer program products provide means for configuring a multiport device as part of a 5GS bridge to forward traffic between local ports without involvement of the User Plane Function of the 5G System. An example method includes: receiving notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receiving initial configuration and capabilities from a Device-Side Time Sensitive Network Translator (DS-TT) using a Port Management Information Container (PMIC); calculating a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; determining combinations of ingress and egress ports that can be bridged locally; generating a forwarding-rule-list for the ingress port of the DS-TT; providing configuration information to the DS-TT including the forwarding-rule-list; and causing the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list.

Description

METHOD, APPARATUS, AND COMPUTER PROGRAM PRODUCT FOR LOCAL BRIDGING USING A MULTIPORT DEVICE

TECHNOLOGICAL FIELD

[0001] An example embodiment relates generally to local bridging using a multiport device, and more particularly, to a method, apparatus, and computer program product for configuring a multiport device as part of a bridge, such as a fifth generation (5G) system (5GS) bridge to forward traffic between local ports without involvement of the User Plane Function.

BACKGROUND

[0002] Next generation or fifth generation (5G) technology was designed to provide high capacity mobile multimedia with high data rates and is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks. The 3^rd Generation Partnership Project has standardized various aspects of 5G technology and hardware components thereof. A 5GS Bridge is an abstraction of an Ethernet Bridge distributed across 5G user equipment devices and network functions. The 5G user plane function and the 5G user equipment devices provide ports for the bridge, while the protocol data unit sessions between the user equipment devices and the user plane function carry traffic between the bridge ports and the 5GS control plane controls the bridge setup and internal connectivity. Various 5G hardware devices including routers/bridges contain more than one Ethernet port. Based on 3GPP standard releases 16 and 17, it is possible that such a device joins the 5GS bridge such that the each port becomes a port of the 5GS bridge. The only way to configure scheduled Time Sensitive Networking (TSN) or other streams forwarded based on static rules between ports in the same device involves passing traffic via the user plane function with substantial port-to-port latency.

BRIEF SUMMARY

[0003] Various embodiments generally relate to local bridging using a multiport device, and more particularly, to a method, apparatus, and computer program product for configuring a multiport device as part of a bridge, such as a 5GS bridge, to forward traffic between local ports without involvement of the User Plane Function. Certain embodiments provided herein include an apparatus including: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to: receive notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receive initial configuration and capabilities from a Device- Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); determine combinations of ingress and egress ports able to be bridged locally; calculate a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT ; expose bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receive forwarding and scheduling rules from the TSN CNC; generate a forwarding-rule-list for the ingress port of the DS-TT; provide configuration information to the DS-TT including the forwarding-rule-list; and cause the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list. The apparatus of an example embodiment is further caused to modify static filtering entries received from the TSN CNC and provided for the NW-TT in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry. [0004] According to certain embodiments, the initial configuration and capabilities from the DS- TT includes a local-bridging-port-list, which includes a list of egress ports to which traffic from the port of the DS-TT acting as an ingress port can be locally forwarded. The initial configuration and capabilities from the DS-TT include, in some embodiments, per-traffic class delays to each local jegress port. Causing the apparatus of certain embodiments to calculate the port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT includes causing the apparatus to: calculate the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability. The forwarding-rule-list includes a destination port Media Access Control (MAC) addresses identifying each locally bridgeable port. The forwarding-rule-list of some embodiments further includes a stream identifier including a destination MAC address and Virtual Local Area Network (VLAN) identifier. The apparatus of some embodiments is further caused to translate the destination port MAC addresses into local identifiers.

[0005] An example embodiment provided herein includes an apparatus embodied by a User Equipment (UE) including: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: receive information including local bridging capabilities and delays from a bridging device; establish a Protocol Data Unit (PDU) session to join a 5GS bridge; send information including local bridging capabilities and delays to the 5GS bridge’s Time Sensitive Networking Application Function (TSN AF); receive configuration information including a forwarding-rule-list from the 5GS Bridge’s TSN AF; receive configuration information including a forwarding-rule-list; configure the bridging device based on the configuration information; and conduct Ethernet traffic related to the PDU session via the bridging device. The forwarding-rule-list of certain embodiments includes destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

[0006] According to an example embodiment, causing the apparatus to conduct the Ethernet traffic related to the PDU session via the bridging device includes causing the apparatus to: conduct a network communication session via the bridging device using local bridging from an ingress port to an egress port, where the ingress port and the egress port are two locally bridgeable ports. The apparatus of certain embodiments is further caused to provide port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability. According to certain embodiments, causing the apparatus to conduct the Ethernet traffic related to the PDU session via the bridging device further includes causing the apparatus to: conduct a network communication session via the bridging device using local bridging from an ingress port to the apparatus, where the ingress port and the egress port are two ports not locally bridgeable, and causing the apparatus to send the egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port. Causing the apparatus to conduct the Ethernet traffic related to the PDU session via the bridging device further includes, in some embodiments, causing the apparatus to: conduct a network communication session via the bridging device using local bridging from the apparatus to the egress port, where the ingress port is not a local port of the bridging, and ingress packets are received by the apparatus via the PDU session.

[0007] Causing the apparatus to receive configuration information including a forwarding-rule- list includes, in certain embodiments, causing the apparatus to: receive configuration information including a forwarding-rule-list in response to the apparatus providing port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability. [0008] An example embodiment provided herein includes a method including receiving notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receiving initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); determining combinations of ingress and egress ports able to be bridged locally; calculating a port-to- port per-class delay matrix using the initial configuration and capabilities from the DS-TT ; exposing bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receive forwarding and scheduling rules from the TSN CNC; generating a forwarding-rule-list for the ingress port of the DS-TT ; providing configuration information to the DS-TT including the forwarding-rule-list; and causing the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list. The method of an example embodiment further includes modifying static filtering entries received from the TSN CNC and provided for the NW-TT in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry.

[0009] According to certain embodiments, the initial configuration and capabilities from the DS- TT includes a local-bridging-port-list, which includes a list of egress ports to which traffic from the port of the DS-TT acting as an ingress port is locally forwarded. The initial configuration and capabilities from the DS-TT include, in some embodiments, per-traffic class delays to each local egress port. Calculating the port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT includes, in some embodiments, calculating the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability. The forwarding-rule-list includes a destination port Media Access Control (MAC) addresses identifying each locally bridgeable port. The forwarding-rule-list of some embodiments further includes a stream identifier including a destination MAC address and Virtual Local Area Network (VLAN) identifier. The method of some embodiments further includes translating the destination port MAC addresses into local identifiers.

[0010] An example embodiment provided herein includes a method including: receiving information including local bridging capabilities and delays from a bridging device; establishing a Protocol Data Unit (PDU) session to join a 5GS bridge; sending information including local bridging capabilities and delays to the 5GS bridge’s Time Sensitive Networking Application Function (TSN AF); receiving configuration information including a forwarding-rule-list from the 5GS Bridge’s TSN AF; receiving configuration information including a forwarding-rule-list; configuring the bridging device based on the configuration information; and conducting Ethernet traffic related to the PDU session via the bridging device. The forwarding-rule-list of certain embodiments includes destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

[0011] According to an example embodiment, conducting the Ethernet traffic related to the PDU session via the bridging device includes conducting a network communication session via the bridging device using local bridging from an ingress port to an egress port, where the ingress port and the egress port are two locally bridgeable ports. The method of certain embodiments further includes providing port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability. According to certain embodiments, conducting the Ethernet traffic related to the PDU session via the bridging device further includes conducting a network communication session via the bridging device using local bridging from an ingress port to a user equipment (UE), where the ingress port and the egress port are two ports not locally bridgeable, and causing the UE to send the egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port. Conducting the Ethernet traffic related to the PDU session via the bridging device further includes, in some embodiments, conducting a network communication session via the bridging device using local bridging from the apparatus to the egress port, where the ingress port is not a local port of the bridging, and ingress packets are received by the apparatus via the PDU session.

[0012] According to some embodiments, receiving configuration information including a forwarding-rule-list includes receiving configuration information including a forwarding-rule-list in response to the apparatus providing port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability.

[0013] An example embodiment provided herein includes a computer program product including at least one non-transitory computer-readable storage medium having computer executable program code instructions stored therein, the computer executable program code instructions including program code instructions to: receive notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receive initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); determine combinations of ingress and egress ports able to be bridged locally; calculate a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; expose bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receive forwarding and scheduling rules from the TSN CNC; generate a forwarding-rule- list for the ingress port of the DS-TT; provide configuration information to the DS-TT including the forwarding-rule-list; and cause the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list. The computer program product of an example embodiment further comprises program code instructions to modify static filtering entries received from the TSN CNC and provided for the NW-TT in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry.

[0014] According to certain embodiments, the initial configuration and capabilities from the DS- TT includes a local-bridging-port-list, which includes a list of egress ports to which traffic from the port of the DS-TT acting as an ingress port can be locally forwarded. The initial configuration and capabilities from the DS-TT include, in some embodiments, per-traffic class delays to each local egress port. The program code instructions of certain embodiments to calculate the port-to-port per- class delay matrix using the initial configuration and capabilities from the DS-TT include program code instructions to: calculate the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability. The forwarding-rule-list includes a destination port Media Access Control (MAC) addresses identifying each locally bridgeable port. The forwarding-rule-list of some embodiments further includes a stream identifier including a destination MAC address and Virtual Local Area Network (VLAN) identifier. The computer program product of some embodiments further includes program code instructions to translate the destination port MAC addresses into local identifiers.

[0015] An example embodiment provided herein includes a computer program product including at least one non-transitory computer readable storage medium having computer executable program code instructions stored therein, the computer executable program code instructions including program code instructions configured, upon execution, to: receive information including local bridging capabilities and delays from a bridging device; establish a Protocol Data Unit (PDU) session to join a 5GS bridge; send information including local bridging capabilities and delays to the 5GS bridge’s Time Sensitive Networking Application Function (TSN AF); receive configuration information including a forwarding-rule-list from the 5GS Bridge’s TSN AF; receive configuration information including a forwarding-rule-list; configure the bridging device based on the configuration information; and conduct Ethernet traffic related to the PDU session via the bridging device. The forwarding-rule-list of certain embodiments includes destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device. [0016] According to an example embodiment, the program code instructions to conduct the Ethernet traffic related to the PDU session via the bridging device include program code instructions to: conduct a network communication session via the bridging device using local bridging from an ingress port to an egress port, where the ingress port and the egress port are two locally bridgeable ports. The computer program product of certain embodiments further includes program code instructions to provide port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability. According to certain embodiments, the program code instructions to conduct the Ethernet traffic related to the PDU session via the bridging device further include program code instructions to: conduct a network communication session via the bridging device using local bridging from an ingress port to a User Equipment (UE), where the ingress port and the egress port are two ports not locally bridgeable, and causing the UE to send the egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port. The program code instructions to conduct the Ethernet traffic related to the PDU session via the bridging device further includes, in some embodiments, program code instructions to: conduct a network communication session via the bridging device using local bridging from the apparatus to the egress port, where the ingress port is not a local port of the bridging, and ingress packets are received by the UE via the PDU session.

[0017] The program code instructions to receive configuration information including a forwarding-rule-list includes, in certain embodiments, program code instructions to: receive configuration information including a forwarding-rule-list in response to the UE providing port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability.

[0018] An example embodiment provided herein includes an apparatus including: means for receiving notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; means for receiving initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); means for determining combinations of ingress and egress ports able to be bridged locally; means for calculating a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; means for exposing bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receiving forwarding and scheduling rules from the TSN CNC; means for generating a forwarding-rule-list for the ingress port of the DS-TT ; means for providing configuration information to the DS-TT including the forwarding-rule-list; and means for causing the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list. The apparatus of an example embodiment further includes means for modifying static filtering entries received from the TSN CNC and provided for the NW-TT in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry. [0019] According to certain embodiments, the initial configuration and capabilities from the DS- TT includes a local-bridging-port-list, which includes a list of egress ports to which traffic from the port of the DS-TT acting as an ingress port is locally forwarded. The initial configuration and capabilities from the DS-TT include, in some embodiments, per-traffic class delays to each local egress port. The means for calculating the port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT include, in some embodiments, means for calculating the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability. The forwarding-rule-list includes a destination port Media Access Control (MAC) addresses identifying each locally bridgeable port. The forwarding-rule-list of some embodiments further includes a stream identifier including a destination MAC address and Virtual Local Area Network (VLAN) identifier. The apparatus of some embodiments further includes means for translating the destination port MAC addresses into local identifiers.

[0020] An example embodiment provided herein includes an apparatus including: means for receiving information including local bridging capabilities and delays from a bridging device; means for establishing a Protocol Data Unit (PDU) session to join a 5GS bridge; means for sending information including local bridging capabilities and delays to the 5GS bridge’s Time Sensitive Networking Application Function (TSN AF); means for receiving configuration information including a forwarding-rule-list from the 5GS Bridge’s TSN AF; means for receiving configuration information including a forwarding-rule-list; means for configuring the bridging device based on the configuration information; and means for conducting Ethernet traffic related to the PDU session via the bridging device. The forwarding-rule-list of certain embodiments includes destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

[0021] According to an example embodiment, the means for conducting the Ethernet traffic related to the PDU session via the bridging device includes means for conducting a network communication session via the bridging device using local bridging from an ingress port to an egress port, where the ingress port and the egress port are two locally bridgeable ports. The apparatus of certain embodiments further includes means for providing port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability. According to certain embodiments, the means for conducting the Ethernet traffic related to the PDU session via the bridging device further includes means for conducting a network communication session via the bridging device using local bridging from an ingress port to a user equipment (UE), where the ingress port and the egress port are two ports not locally bridgeable, and causing the UE to send the egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port. The means for conducting the Ethernet traffic related to the PDU session via the bridging device further includes, in some embodiments, means for conducting a network communication session via the bridging device using local bridging from the apparatus to the egress port, where the ingress port is not a local port of the bridging, and ingress packets are received by the apparatus via the PDU session. [0022] According to some embodiments, the means for receiving configuration information including a forwarding-rule-list includes means for receiving configuration information including a forwarding-rule-list in response to the apparatus providing port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability.

[0023] The above summary is provided merely for purposes of summarizing some example embodiments to provide a basic understanding of some aspects of the disclosure. Accordingly, it will be appreciated that the above-described embodiments are merely examples and should not be construed to narrow the scope or spirit of the disclosure in any way. It will be appreciated that the scope encompasses many potential embodiments in addition to those here summarized, some of which will be further described below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Having thus described certain example embodiments of the present disclosure in general terms above, non-limiting and non-exhaustive embodiments of the subject disclosure will now be described with reference to the accompanying drawings, which are not necessarily drawn to scale. The components illustrated in the accompanying drawings may or may not be present in certain embodiments described herein. Some embodiments may include fewer (or more) components than those shown in the drawings.

[0025] Figure 1 illustrates an overview of an example mobile network (e.g., 5GS), in accordance with various embodiments of the present disclosure;

[0026] Figure 2 provides a block diagram of an example apparatus that can employ local bridging using a multiport device, in accordance with various embodiments of the present disclosure; [0027] Figure 3 illustrates a multiport device for a 5G System functioning as a bridge according to an example embodiment of the present disclosure;

[0028] Figure 4 illustrates a multiport device depicting local bridging and traffic passing through the User Plane Function (UPF) according to an example embodiment of the present disclosure;

[0029] Figure 5 illustrates an example embodiment of the architecture used to conduct local bridging using a multiport device according to an example embodiment of the present disclosure;

[0030] Figure 6 illustrates a message sequence of using a multiport device for local bridging in a 5G system according to an example embodiment of the present disclosure;

[0031] Figure 7 is a flowchart of an example embodiment of a method configuring a multiport device as part of a 5GS bridge to forward traffic between local ports without involvement of the User Plane Function of the 5G System according to an example embodiment of the present disclosure; and [0032] Figure 8 is a flowchart of an example embodiment of operations of a User Equipment (UE) and Device Side TSN Translator (DS-TT) when operating within a multiport device with port- to-port local bridging according to an example embodiment of the present disclosure.

DETAILED DESCRIPTION

[0033] Some embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, various embodiments of the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals refer to like elements throughout. As used herein, the terms “data,” “content,” “information,” “electronic information,” “signal,” “command,” and similar terms may be used interchangeably to refer to data capable of being captured, transmitted, received, and/or stored in accordance with various embodiments of the present disclosure. Thus, use of any such terms should not be taken to limit the spirit and scope of embodiments of the present disclosure. Further, where a first computing device is described herein to receive data from a second computing device, it will be appreciated that the data may be received directly from the second computing device or may be received indirectly via one or more intermediary computing devices, such as, for example, one or more servers, relays, routers, network access points, base stations, hosts, repeaters, and/or the like, sometimes referred to herein as a “network.” Similarly, where a first computing device is described herein as sending data to a second computing device, it will be appreciated that the data may be sent or transmitted directly to the second computing device or may be sent or transmitted indirectly via one or more intermediary computing devices, such as, for example, one or more servers, remote servers, cloud-based servers (e.g., cloud utilities), relays, routers, network access points, base stations, hosts, repeaters, and/or the like.

[0034] The term “comprising” means including but not limited to and should be interpreted in the manner it is typically used in the patent context. Use of broader terms such as comprises, includes, and having should be understood to provide support for narrower terms such as consisting of, consisting essentially of, and comprised substantially of. Furthermore, to the extent that the terms “includes” and “including,” and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising.” [0035] The phrases “in one embodiment,” “according to one embodiment,” “in some embodiments,” “in various embodiments”, and the like generally refer to the fact that the particular feature, structure, or characteristic following the phrase may be included in at least one embodiment of the present disclosure, but not necessarily all embodiments of the present disclosure. Thus, the particular feature, structure, or characteristic may be included in more than one embodiment of the present disclosure such that these phrases do not necessarily refer to the same embodiment. [0036] As used herein, the terms “example,” “exemplary,” and the like are used to mean “serving as an example, instance, or illustration.” Any implementation, aspect, or design described herein as “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other implementations, aspects, or designs. Rather, use of the terms “example,” “exemplary,” and the like are intended to present concepts in a concrete fashion.

[0037] If the specification states a component or feature “may,” “can,” “could,” “should,” “would,” “preferably,” “possibly,” “typically,” “optionally,” “for example,” “often,” or “might” (or other such language) be included or have a characteristic, that particular component or feature is not required to be included or to have the characteristic. Such component or feature may be optionally included in some embodiments, or it may be excluded.

[0038] As used herein, the term “computer-readable medium” refers to non-transitory storage hardware, non-transitory storage device or non-transitory computer system memory that may be accessed by a controller, a microcontroller, a computational system or a module of a computational system to encode thereon computer-executable instructions or software programs. A non-transitory “computer-readable medium” may be accessed by a computational system or a module of a computational system to retrieve and/or execute the computer-executable instructions or software programs encoded on the medium. Examples of non-transitory computer-readable media may include, but are not limited to, one or more types of hardware memory, non-transitory tangible media (for example, one or more magnetic storage disks, one or more optical disks, one or more USB flash drives), computer system memory or random-access memory (such as, DRAM, SRAM, EDO RAM), and the like.

[0039] Additionally, as used herein, the term ‘circuitry’ refers to (a) hardware-only circuit implementations (e.g., implementations in analog circuitry and/or digital circuitry); (b) combinations of circuits and computer program product(s) comprising software and/or firmware instructions stored on one or more computer readable memories that work together to cause an apparatus to perform one or more functions described herein; and (c) circuits, such as, for example, a microprocessor(s) or a portion of a microprocessor(s), that require software or firmware for operation even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term herein, including in any claims. As a further example, as used herein, the term ‘circuitry’ also includes an implementation comprising one or more processors and/or portion(s) thereof and accompanying software and/or firmware. As another example, the term ‘circuitry’ as used herein also includes, for example, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, other network device (such as a core network apparatus), field programmable gate array, and/or other computing device.

[0040] Wireless communication networks employ a variety of technologies and use various standards throughout the world. There are generally agreed upon standards that promote some degree of unity between networks, with some of those standards being defined by 3GPP (3^rd Generation Partnership Project), such as the Third Generation (3G), a Fourth Generation (4G), and/or a next generation (e.g., Fifth Generation, or 5G) network. 5G is the fifth generation of the technology standard for broadband cellular networks. These standards provide an architecture through which user equipment (UE) can communicate with networks and other UE devices.

[0041] Within 5G networks, the 3GPP has standardized the concept of a “5GS Bridge”, which is an abstraction of IEEE (Institute of Electrical and Electronics Engineers) 802 Ethernet Bridge distributed across the 5G UEs and Network Functions. The 5G User Plane Function (UPF) and the 5G UEs provide the ports for the bridge, while the PDU (Protocol Data Unit) sessions between the UEs and the UPF carry the traffic between the bridge ports and the 5GS Control Plane controls the bridge setup and internal connectivity. On the user/data plane the external behavior of the 5GS Bridge is identical to an “ordinary” Ethernet bridge with respect to the Ethernet features it supports, such that the 5GS Bridge can be treated similarly to any other Ethernet bridge in an Ethernet network.

[0042] A special feature of the 3GPP 5GS Bridge is that it can support some of the features relevant for IEEE Time Sensitive Networking (TSN) and also supports the TSN centralized configuration model where a TSN Central Network Controller (CNC) manages these features in the bridge. The management interface to the CNC, which is based on IEEE and IETF (Internet Engineering Task Force) standards, using SNMP (Simple Network Management Protocol) and MIBs (Management Information Bases) or NETCONF/RESTCONF protocol and YANG (Yet Another Next Generation) data models, is exposed by a specialized TSN Application Function (TSN AF). The TSN AF communicates with the 5GS Control Plane (via PCF (Point Coordination Function)) to collect information about the 5GS Bridge towards the CNC and to configure the 5GS Bridge based on the configuration received from the CNC.

[0043] Among the most important TSN features of the 5GS bridge is the support for the IEEE 802.1Qbv Time Aware Shaper traffic scheduling in the bridge egress ports. Qbv allows configuring dedicated “timeslots” cyclically for specific Ethernet traffic classes in the egress port. The CNC can schedule these cyclic slots and cyclic stream transmission times such that the streams do not collide with each other in time at any egress port. For this, the CNC needs to learn specific information about each bridge, especially the class-specific internal delays between each bridge port.

[0044] Qbv and the egress port scheduling overall in the 5GS Bridge are implemented by special TSN/TSC Translators. On the UE side, these are called Device Side TSN Translators (DS-TT), while on the UPF side they are called Network Side TSN Translators (NW-TT). The TT functions are logically separate from the UE and UPF, respectively, though in practice, UE and DS-TT would reside within the same physical device. The TSN AF communicates with the DS-TTs via the 5GS Control Plane using Port Management Information Containers (PMIC). PMICs allow the TSN AF to read/receive DS-TT’ s capabilities and current configuration, and also write/update its configuration. This configuration includes, for instance, the Qbv parameters. [0045] For TSN/Qbv scheduled streams, the forwarding (or bridging) of frames with specific VLAN identifier and destination MAC addresses to specific egress ports in a bridge is configured by the CNC using IEEE defined static filtering entries. In a 5GS Bridge, the TSN AF configures the static filtering entries received from the CNC to the NW-TT. This works as long as all streams in a bridge pass through the UPF/NW-TT.

[0046] The 5GS Bridge operation is defined mainly in 3GPP TS’s 23.501, 23.502, and 23.503. The PMIC operations between DS-TT and TNS-AF are defined in detail in TS 24.539, while the exact port management parameters related, for instance, to Qbv, are defined in the IEEE 802. IQ specification. The 5GS Bridge is operable in example embodiments over a mobile network.

[0047] Referring now to Figure 1, an example mobile network 100 is illustrated. Mobile network 100 (also referred to as a cellular network) is a type of network where at least the last link is wireless, and provides voice and/or data services to a plurality of devices. Mobile network 100 may be a Third Generation (3G), a Fourth Generation (4G), and/or a next generation (e.g., Fifth Generation, or 5G) network.

[0048] Mobile network 100 is illustrated as providing communication services to UEs 110. UEs 110 may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, Internet of Things (loT) services, and/or other services. A UE 110 may be an end user device such as a mobile phone (e.g., smartphone), a tablet or PDA, a computer with a mobile broadband adapter, and/or the like.

[0049] Mobile network 100 includes one or more radio access networks (RAN 120) that communicate with UEs 110 over a radio interface. RAN 120 of one example embodiment may support Evolved-UMTS terrestrial Radio Access network (E-UTRAN) access, Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new Radio Access Technologies (RAT), and/or the like. As an example, RAN 120 may comprise an E-UTRAN or Next Generation RAN (NG- RAN) that includes one or more base stations 124 that are dispersed over a geographic area. A base station 124 may comprise an entity that uses radio communication technology to communicate with a UE on the licensed spectrum, and interface the UE with a core network 130. Base stations 124 in an E-UTRAN may be referred to as Evolved-NodeBs (eNodeB). Base stations 124 in a NG-RAN may be referred to as gNodeBs (NR base stations) and/or ng-eNodeBs (LTE base stations supporting a 5G Core Network). As another example, RAN 120 may comprise a WLAN that includes one or more Wireless Access Points (WAP). A WLAN is a network in which a UE is able to connect to a Local Area Network (LAN) through a wireless (radio) connection. A WAP is a node that uses radio communication technology to communicate with a UE over the unlicensed spectrum and provides the UE access to a core network. One example of a WAP is a Wi-Fi access point that operates on the 2.4 GHz or 5 GHz radio bands. The term “base station” then may refer to an eNodeB, a gNodeB, an ng- eNodeB, a WAP, and/or the like. [0050] UEs 110 are able to attach to a cell of a RAN 120 to access a core network 130. RAN 120 therefore represents the radio interface between UEs 110 and core network 130. Core network 130 is the central part of mobile network 100 that provides various services to customers who are connected by RAN 120. One example of core network 130 is the Evolved Packet Core (EPC) network as described by the 3GPP for LTE. Another example of core network 130 is a 5G Core (5GC) network as described by the 3GPP. Core network 130 includes network elements 132, which may comprise servers, devices, apparatuses, or equipment (including hardware) that provide services for UEs 110. Network elements 132, in an EPC network, may comprise a Mobility Management Entity (MME), a Service Gateway (S-GW), a Packet Data Network Gateway (P-GW), and/or the like. Network elements 132, in a 5G network, may comprise an Access and Mobility Management Function (AMF), a Session Management Function (SMF), a User Plane Function (UPF), a Policy Control Function (PCF), a Unified Data Management (UDM), and/or the like.

[0051] Referring now to Figure 2, an example apparatus 300 is provided. The apparatus 300 may be an embodiment of a UE 110 and/or may be embodied by or otherwise associated with a UE 110, in some instances. Alternatively, the apparatus 300 may be an embodiment of a network element 132 or may be embodied by or otherwise associated with a network element 132, such as a PCF 260. In any regard, the apparatus 300 is configured to indicate and/or evaluate the applicability of routing parameters, such as URSP parameters. In an example embodiment, apparatus 300 is embodied by a network element 132, such as a PCF 260, and generates network applicability indications for parameters in a policy rule data object. The apparatus 300 may then cause transmission of the policy rule data object including the network applicability indications to a UE 110, and the UE 110 may subsequently use the policy rule data object and evaluate the network applicability indications for the parameters of the policy rule data object in communicating via a network. In another example embodiment, apparatus 300 is embodied by a UE 110 and receives a policy rule data object comprising network applicability indications associated with parameters. The apparatus 300 (e.g., UE 110) evaluates the network applicability indications to determine whether to ignore or consider various parameters and/or rule descriptors when communicating via a network.

[0052] The apparatus 300 may include processor 302, memory 304, and network interface 306. The apparatus 300 may be configured to execute the operations described herein. Although these components are described with respect to the performance of various functions, it should be understood that the particular implementations necessarily include the use of particular hardware. It should also be understood that certain of these components may include similar or common hardware. For example, two sets of circuitries may both leverage use of the same processor, network interface, storage medium, or the like to perform their associated functions, such that duplicate hardware is not required for each set of circuitries.

[0053] In some embodiments, the processor 302 (and/or co-processor or any other processing circuitry assisting or otherwise associated with the processor) may be in communication with the memory 304 via a bus for passing information among components of the apparatus. The memory 304 is non-transitory and may include, for example, one or more volatile and/or non-volatile memories. In other words, for example, the memory 304 may be an electronic storage device (e.g., a computer- readable storage medium). The memory 304 may be configured to store information, data, content, applications, instructions, or the like for enabling the apparatus to carry out various functions in accordance with an example embodiment disclosed herein.

[0054] The processor 302 may be embodied in a number of different ways and may, for example, include one or more processing devices configured to perform independently. In some non-limiting embodiments, the processor 302 may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelining, and/or multithreading. The use of the term “processor” may be understood to include a single core processor, a multi-core processor, multiple processors internal to the apparatus, and/or remote or “cloud” processors.

[0055] In some embodiments, the processor 302 may be configured to execute instructions stored in the memory 304 and/or circuitry otherwise accessible to the processor 302. In some embodiments, the processor 302 may be configured to execute hard-coded functionalities. As such, whether configured by hardware or software methods, or by a combination thereof, the processor 302 may represent an entity (e.g., physically embodied in circuitry) capable of performing operations according to an embodiment disclosed herein while configured accordingly. Alternatively, as another example, when the processor 302 is embodied as an executor of software instructions, the instructions may specifically configure the processor 302 to perform the algorithms and/or operations described herein when the instructions are executed.

[0056] In some embodiments, the apparatus 300 may include input/output circuitry that may, in turn, be in communication with processor 302 to provide output to a user and/or other entity and, in some embodiments, to receive an indication of an input. The input/output circuitry may comprise a user interface and may include a display, and may comprise a web user interface, a mobile application, a query-initiating computing device, a kiosk, or the like. In some embodiments, the input/output circuitry may also include a keyboard, a mouse, a joystick, a touch screen, touch areas, soft keys, a microphone, a speaker, or other input/output mechanisms. The processor and/or user interface circuitry comprising the processor may be configured to control one or more functions of one or more user interface elements through computer program instructions (e.g., software and/or firmware) stored on a memory accessible to the processor (e.g., memory 304, and/or the like).

[0057] The network interface 306 may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data from/to a network and/or any other device, circuitry, or module in communication with the apparatus 300. In this regard, the network interface 306 may include, for example, a network interface for enabling communications with a wired or wireless communication network. For example, the network interface 306 may include one or more network interface cards, antennae, buses, switches, routers, modems, and supporting hardware and/or software, or any other device suitable for enabling communications via a network. Additionally, or alternatively, the network interface 306 may include the circuitry for interacting with the antenna/antennae to cause transmission of signals via the antenna/antennae or to handle receipt of signals received via the antenna/antennae. [0058] It is also noted that all or some of the information discussed herein can be based on data that is received, generated and/or maintained by one or more components of apparatus 300. In some embodiments, one or more external systems (such as a remote cloud computing and/or data storage system) may also be leveraged to provide at least some of the functionality discussed herein.

[0059] Figure 3 illustrates an example embodiment of a 5GS bridge for use with a network as described herein. The 3GPP Release 16 defines the 5GS Ethernet Bridge with TSN capabilities. The Bridge is a distributed entity with ports located at the UPF on the network side (port 310 of Figure 3) as well as UE device ports 320 for 5G devices connected to the UPF. The bridge can switch packets between ports via the UPF. For TSN purposes, it is able to guarantee a deterministic bridging delay between any two ports. The 5GS Bridge can be deployed in Ethernet topology as any ordinary “single box” bridge.

[0060] The 5GS Bridge provides a centralized management interface to management systems such as TSN controller (CNC). The management interface is provided by a special function TSN AF. The TSN AF itself manages the individual bridge ports and switching between them. The TSN AF configures TSN scheduling at a port by exchanging Port Management Information Containers (PMICs) with port specific DS-TTs over 5G control plane. The DS-TTs and PMICs are per port and per PDU session. The port-specific configuration and state (e.g., traffic schedules for TSN streams at the port) with the bridge management interface is used, for example, by TSN CNC to see bridge and port capabilities and schedule TSN streams.

[0061] According to certain embodiments described herein, a UE device joins a specific 5GS Bridge by establishing a PDU session to the UPF identified by a specific DNN (Data Network Name). The DS-TT provides a unique MAC address for the port and UPF allocates a unique port number for it. The DS-TT provides the port’s capabilities to TSN AF using PMIC. The TSN AF uses port capabilities and other information to provide port-to-port delays to TSN CNC, such that CNC can schedule streams from one port to another through the bridge. Based on 3GPP TS’s 23.502, if the UE indicated support of transferring PMIC, the SMF informs PCF that a 5GS Port and Bridge information is available. SMF also includes the port number of the DS-TT port, MAC address of the DS-TT Ethernet port for Ethernet PDU Session type, UE IP address for IP PDU Session type, 5GS Bridge ID, PMIC, and UE-DS-TT Residence Time (if available) as provided by the UE. To support IEEE TSN, the TSN AF calculates the bridge delay for each port pair (e.g., composed of DS-TT Ethernet port and NW-TT Ethernet port) using the UE-DS-TT Residence Time for all NW-TT Ethernet ports serving the 5GS Bridge indicated by the 5GS Bridge ID. Further, the TSN AF determines the 5GS bridge delay for port pair composed of two DS-TT ports connecting the same 5GS Bridge as a sum of bridge delays related to PDU Sessions of the two DS-TT ports.

[0062] Most 5G router/bridge devices include more than one Ethernet port. According to 3GPP Releases 16 and 17 it is possible that such a device joints the 5GS Bridge such that each one of its ports becomes a port in a 5GS Bridge. This requires each port to have a dedicated DS-TT and each DS-TT/port to use a dedicated PDU session to join and exchange traffic within the 5GS Bridge. If the device supports internal bridging between its ports (as many devices with multiple ports would), this type of device internal bridging cannot be supported for TSN scheduled streams or Qbv, as there is no way for the TSN AF to know about this capability, nor the port-to-port delays that it would need to report to the CNC. Further, it is not possible to configure static filtering entries to apply for the internal bridging as the static filtering entries can only be configured at the UPF/NW-TT.

[0063] With the 3GPP R16 and R17 standards, the only way to configure scheduled or other static rule-based streams between ports in the same device would be by passing the traffic via the UPF. This would mean the port-to-port delays would be on the order of milliseconds (traffic going over the 5G radio link in both uplink and downlink directions) rather than tens of microsections which would be possible for the bridging within a device itself. Figure 4 illustrates this effect with the local bridging 330 occurring within the multiport device 335, whereas passing the traffic 340 via UPF 345 involves more processing port-to-port delays in reaching the UPF 345. The multiport device 335 can, in some embodiments, be represented as an independent bridge from the 5GS Bridge. Even for such an embodiment, the device would have to implement some type of interface between the 5GS Bridge port /DS-TT and bridge port of the independent bridge logically connected to the 5GS Bridge.

[0064] Figure 5 illustrates an example embodiment of the architecture to resolve the aforementioned deficiencies of the 3GPP R16 and R17 standards. As shown, there is one PDU session per port and DS-TT. The DS-TT data model and PMIC are extended to include bridging delays between the local ports and forwarding rules for the local ports. No changes to the SMF or UPF logic are required with respect to the DS-TTs and PDU sessions.

[0065] The apparatus of example embodiments is based on the 3GPP 5GS Bridge architecture defined in R16 including a CNC 355, TSN AF 365, a 5GS, and an industrial device. The industrial device includes a UE 375 and one or several DS-TTs 385 including one Ethernet port 395 per DS-TT. Each DS-TT is served by a dedicated PDU session and using a dedicated PMIC as shown in Figure 5. Certain embodiments improve upon the 3GPP R16 and R17 standards as detailed herein.

[0066] According to an embodiment described herein, beyond the 3GPP architecture, a multiport device is included as part of a 5GS Bridge that is characterized by the internal bridging capabilities with its ability to forward traffic between local ports without involvement of the UPF of the 5G system. The port receiving traffic (5G-UE-3 in Figure 5, along arrow 350) is the ingress port, with the port sending the traffic (5G-UE-2) is the egress port. Some embodiments include new information elements extending the existing DS-TT data model that are used to model and configure local bridging of TSN streams. Separate instances of the disclosed information elements exist for each DS-

TT.

[0067] An example embodiment includes a “local-bridging-port-list” information element that includes a list of egress ports to which internal bridging from the DS-TT’s port is supported. The egress port is identified by its MAC address. For each egress port, the list includes the internal bridging delay per Ethernet traffic class between the ingress port (e.g., the port of the DS-TT owning this instance of the local-bridging-port-list) and this egress port, and a flag indicating if local bridging between these ports is enabled or not. In principle, the same information can be provided from egress port perspective (e.g., providing per egress port a list of ingress ports from which internal bridging to the particular egress port is supported), with bridging delays. In either case collecting the information across all ports or DS-TTs a full port-to-port internal bridging delay matrix is obtained from the device.

[0068] Certain embodiments further include a “forwarding-rule-list” information element that includes a list of traffic forwarding rules that apply to incoming traffic received via the ingress port (e.g., the port of the DS-TT owning the instance of this forwarding-rule-list”). The rules are used to control local bridging (e.g., to steer traffic identified by the list entry directly to a set of local egress ports only if needed to the UPF). These forwarding rules of certain embodiments can be modeled for instance based on IEEE static filtering entries that contain destination MAC address and VLAN ID for frame identification, and have a set of egress ports to which the identified frame should be forwarded (minus its ingress port).

[0069] According to an example embodiment described herein, the data model of the existing PMIC which is used by the TSN AF to interact with the DS-TT (read and update data, get notified about changes in the data) is extended to contain the claimed new information elements. In this way, the TSN AF can: read the local-bridging-port-list and read/write the attributes in the list indicating whether local bridging to a specific port is enabled or disabled, and read/write the forwarding-rule- list.

[0070] Certain embodiments provide a method for creation of the local-bridging-port-list where each DS-TT initially populates its instance of the local-bridging-port-list by interacting with the device internal bridging fabric. The internal bridging fabric includes, in some embodiments, a dedicated piece of hardware, but further exhibits a management interface for discovery of capabilities and reading and writing of configurations.

[0071] An example embodiment employs the TSN AF for calculation of a port-to-port delay matrix using the local-bridging-port-list. The TSN AF reads/receives, via PMIC, the initial content of the port and delay list from all the DS-TTs of the device. Based on the lists, the TSN AF can identify between which ports the 5GS Bridge device-side bridging is possible (in each direction) and the classspecific port-to-port delays (in each direction). The TSN AF uses these values in the port-to-port delay matrix it exposes to the TSN CNC instead of the values based on the port-to-port traffic traversing the UPF as per 3GPP R17.

[0072] Certain embodiments further employ the TSN AF for calculation of the forwarding-rule- list for DS-TT. After receiving configuration information (including, but not limited to Qbv, Per Stream Filtering Policy PSFP) from the CNC related to the scheduled streams (calculated by the CNC using the port-to-port delay matrix based on the local-bridging-port-lists), the TSN AF creates the forwarding-rule-lists for DS-TT acting as ingress ports for a stream. The forwarding-rule-list contains information for identification of the stream (e.g., Destination MAC address, VLAN ID), the set of locally bridged egress ports, and in case the stream needs to be forwarded to a non-local port, a flag indicating that the stream should be forwarded to the UPF using the PDU session.

[0073] The TSN AF as described herein calculates static filtering entries for the UPF. When configurating static filtering entries for a specific stream at the UPF/NW-TT, the TSN AF removes from the entry any egress ports that can be bridged locally and therefore are covered by the forwarding-rule-lists given to the DS-TT.

[0074] If a DS-TT receives any information related to the configuration of the local bridging fabric, the DS-TT configures the bridging fabric accordingly using the management interface of the bridging fabric. Such information is typically provided to the DS-TT by the TSN AF in the form of the forwarding-rule-list included in the PMIC. With this information derived from the forwarding- rule-list configured in the local bridging fabric, the device will forward frames of incoming streams locally from the ingress ports to the correct local egress ports and only if needed to the UPF. Since the forwarding happens based on forwarding rules created by the CNC based on the local bridging times reported to the CNC in the local-bridging-port-list, the forwarding schedules match the actual delays intended by the CNC for these streams. The Qbv and PSFP configurations are not affected but follow the logic already set in 3GPP R16. This solution presumes that the TSN AF is able to determine the ingress port of each scheduled stream.

[0075] Figure 6 illustrates the message sequence of an example embodiment described herein. A device with multiple ports and DS-TTs is initialized. The DS-TT related to a specific port communicates with the device’s internal bridging fabric 410 and learns which other internal ports are available for local bridging and the per-traffic class delays to each of them as shown at (1). The DS- TT/UE 420 updates it’s state accordingly. The DS-TT ’s ports identify themselves to the bridging fabric using the MAC addresses they will use for identifying the DS-TT’ s ports towards the 5GS Bridge (at 5G Core 430). The DS-TT/UE 420 joins the 5GS Bridge, with the UE establishing a PDU session for each DS-TT as shown at (2). The TSN AF 440 is informed of a new PDU session and port being added to the 5GS Bridge as shown at (3).

[0076] Each DS-TT from DS-TT/UE 420 sends its initial configuration and capabilities to the TSN AF using a PMIC as shown at (4). This PMIC includes the new information element, local- bridging-port-list. This information element includes a list of all egress ports to which traffic can be forwarded locally if the port of the DS-TT is used as the ingress port. For each egress port, the list includes per traffic class delays. For example, a local-bridging-port-list can include two entries like this:

(Port=”MAC-A”: (per class traffic delay information as per IEEE TSN standards), local- bridging=”Enabled”)

(Port=”MAC-B”: (per class traffic delay information as per IEEE TSN standards), local- bridging=”Enabled”)

The TSN AF calculates its port-to-port class delay matrix as shown at (5) using the DS-TT reported local bridging delays for ingress, egress port pairs for which the DS-TT has indicated local bridging capability. These delays override the normal UE-to-UE port delays as calculated per 3GPP R17. [0077] Bridge and port capabilities, and topology and link delay information, is reported to the TSN CNC 450 as shown at (6) including now the local bridging based delays for the relevant (ingress/egress) port pairs. The CNC knows requirements and characteristics of the scheduled streams and using the information provided by the bridges, calculates the schedules for each stream, the Qbv, and the PSFP parameters and static filtering entries for the bridge now using the local bridging delays for the 5GS Bridge for streams that are set from one local port to another. The resulting configuration is sent to the TSN AF 440 of the 5GS Bridge as shown at (7).

[0078] The TSN AF 440 determines which static filtering entries received from the CNC are relevant for specific ingress ports/DS-TTs for local bridging. This is done by determining the ingress port and all egress ports for the stream using any methods TSN AF has for this. If any combination of ingress and egress port can be bridged locally, the TSNAF creates the forwarding-rule-list intended for the ingress port’s DS-TT containing the following information as shown at (8): (A) Stream identification - Destination MAC and VLAN ID from the static filtering entry. (B) Destination ports - each of the stream’s egress port in the static filtering entry which is locally bridgeable from the stream’ s ingress port. If the stream exhibits at least one egress port which is not bridged locally, a special destination ID indicating forwarding to the UPF is added to the forwarding rule list. (C) Forwarding-rule-list: Stream ID = ([Destination MAC], [VLAN ID]), Destination Ports = (MAC-A, MAC-B, 5G-UPF). “MAC-A” and “MAC-B” are the MAC addresses identifying two locally bridgeable ports. “5G-UPF” indicates that the stream should also be forwarded uplink via the PDU session to the UPF. TSN AF uses DS-TT/port MAC addresses instead of port numbers since port numbers of the 5GS Bridge are not necessarily known within the device/DS-TT, as only MAC addresses are.

[0079] The TSN AF requests Quality of Service (QoS) for the DS-TT related PDU sessions as shown at (9) and configures the NW-TT. The NW-TT static filtering entries provided to the 5G Core in this operation are those prepared in (8) above. Streams which can be bridged entirely locally do not require any capacity in the 5GS PDU sessions. For those streams, operation (9) may be omitted. The TSN AF 440 sends configuration information to DS-TT 420 including the forwarding-rule-list of operation (8). The DS-TT interacts with the internal bridging fabric 410 to configure bridging according to the forwarding-rule-list from the TSN AF. Destination port MAC addresses may need to be translated to local identifiers according to some embodiments.

[0080] Figure 7 illustrates a flowchart of an example embodiment of a method configuring a multiport device as part of a 5GS bridge to forward traffic between local ports without involvement of the User Plane Function of the 5G System. A notification is received at 510 of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge. The notification may be received, for example, by a Time-Sensitive Networking (TSN) Application Function (AF), and may be provided, for example, by 5G Core. An apparatus of example embodiments includes means for receiving the notification, such as by network interface 306 and processor 302 of Figure 2. An initial configuration and capabilities is received at 520 from a Device-Side Time Sensitive Network Translator (DS-TT) using a Port Management Information Container (PMIC). Embodiments described herein further provide means for receiving the configuration and capabilities, such as that the network interface 306 and/or processor 302. This is also received, in certain embodiments, by the TSN AF. Combinations of ingress ports and egress ports that can be bridged locally are determined at 530. Embodiments provide means for making such a determination, such as using processor 302 and memory 304, for example. These combinations can be determined by the TSN AF, such as using a processor such as processor 302 of Figure 2, for example. A port-to-port per-class delay matrix is calculated at 540 using the initial configuration and capabilities from the DS-TT. Embodiments provide means, such as processor 302 and memory 204 for calculating the matrix based on the initial configurations and capabilities that are received by receiving means. Bridge information is exposed to a TSN CNC at 550 and forwarding and scheduling rules are received from the CNC. Embodiments provided herein include means, such as network interface 306 and processor 302 for exposing and receiving information as described in 550. A forwarding-rule-list is generated at 560 for the ingress port of the DS-TT. This list is generated, in some embodiments, by the TSN AF, such as using processor 302 and memory 304 as means for generating the forwarding-rule-list. The configuration information is provided to the DS-TT including the forwarding rule list at 570. Embodiments include means for providing the configuration information, such as, through network interface 306 when embodying the TSN AF. The DS-TT is caused to configure internal bridging of a multiport device according to the forwarding rule list provided at 580. Embodiments provide means, such as processor 302 and network interface 306 to provide instructions for configuring internal bridging of a multiport device as described herein. Optionally, static filtering entries received from the CNC are modified and provided for the NW-TT in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry. This filtering may be performed by means such as processor 302, for example. The multiport device may be embodied by the multiport device 335 of Figures 4 or 5, for example. [0081] Figure 8 illustrates a flowchart of an example embodiment of operations of a User Equipment and Device Side TSN Translator (DS-TT) when operating within a multiport device with port-to-port local bridging. As shown, information including local bridging capabilities and delays are received at the DS-TT from a bridging device at 610. Embodiments provide means, such as processor 302 for receiving such information and providing the information. A Protocol Data Unit (PDU) session is established at 620 by the UE to let the port related to the DS-TT to join a 5G bridge. The PDU session is established, in some embodiments, by means such as processor 302 and network interface 306, for example. This session may be established, for example, by the UE using processor 302 via network interface 306 when the components of Figure 2 are embodying a UE device. Information including local bridging capabilities and delays are sent to a TSN AF of the 5GS bridge at 630. This may be performed by means, such as processor 302 and network interface 306, for example. Configuration information including a forwarding-rule-list is received at 640, such as by network interface 306. Embodiments provide means, such as the network interface 306 and processor 302 for receiving the configuration information described herein. The bridging device is configured based on the configuration information at 650. This may be accomplished, for example, by the UE device communicating the configuration information to the bridging device, such as by means including network interface 306 and processor 302. The ethernet traffic related to a PDU session is conducted via the bridging device at 660, such as via a multiport device 335 shown in Figures 4 and 5.

[0082] Figures 7 and 8 illustrate flowcharts depicting operations according to an example embodiments of the present disclosure. It will be understood that each block of the flowchart and combination of blocks in the flowchart may be implemented by various means, such as hardware, firmware, processor, circuitry, and/or other communication devices associated with execution of software including one or more computer program instructions. For example, one or more of the procedures or operations described above may be embodied by computer program instructions. In this regard, the computer program instructions which embody the procedures or operations described above may be stored by a memory 304 of an apparatus (e.g., apparatus 300, UE 110) employing an embodiment of the present invention and executed by a processor 302. As will be appreciated, any such computer program instructions may be loaded onto a computer or other programmable apparatus (for example, hardware) to produce a machine, such that the resulting computer or other programmable apparatus implements the functions specified in the flowchart blocks. These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture the execution of which implements the function specified in the flowchart blocks. The computer program instructions may also be loaded onto a computer or other programmable apparatus to cause a series of operations to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide operations for implementing the functions specified in the flowchart blocks.

[0083] Accordingly, blocks of the flowchart support combinations of means for performing the specified functions and combinations of operations for performing the specified functions for performing the specified functions. It will also be understood that one or more blocks of the flowchart, and combinations of blocks in the flowchart, can be implemented by special purpose hardware-based computer systems which perform the specified functions, or combinations of special purpose hardware and computer instructions.

[0084] Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims.

[0085] Moreover, although the foregoing descriptions and the associated drawings describe example embodiments in the context of certain example combinations of elements and/or functions, it should be appreciated that different combinations of elements and/or functions may be provided by alternative embodiments without departing from the scope of the appended claims. In this regard, for example, different combinations of elements and/or functions than those explicitly described above are also contemplated as may be set forth in some of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

23 THAT WHICH IS CLAIMED:

1. An apparatus comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: receive notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receive initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); determine combinations of ingress and egress ports that are able to be bridged locally; calculate a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; expose bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receive forwarding and scheduling rules from the TSN CNC; generate a forwarding-rule-list for an ingress port of the DS-TT ; provide configuration information to the DS-TT including the forwarding-rule-list; and cause the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list.

2. The apparatus of claim 1, wherein the apparatus is further caused to: modify static filtering entries received from the TSN CNC and provided for a Network-Side TSN Translator (NW-TT) in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry.

3. The apparatus of claim 1, wherein the initial configuration and capabilities from the DS-TT comprises a local-bridging-port-list, wherein the local-bridging-port-list comprises a list of egress ports to which it is possible to forward traffic locally when the port of the DS-TT is used as the ingress port.

4. The apparatus of claim 3, wherein the initial configuration and capabilities from the DS-TT include per-traffic class delay information for each egress port.

5. The apparatus of claim 4, wherein causing the apparatus to calculate the port-to-port per class delay matrix using the initial configuration and capabilities from the DS-TT comprises causing the apparatus to: calculate the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability.

6. The apparatus of any of claims 1 through 5, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port.

7. The apparatus of claim 6, wherein the forwarding-rule-list further comprises a stream identifier comprising a destination port MAC address and Virtual Local Area Network (VLAN) identifier.

8. The apparatus of claim 7, wherein the apparatus is further caused to translate the destination port MAC addresses into local identifiers.

9. An apparatus comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to: receive information comprising local bridging capabilities and delays from a bridging device; establish a Protocol Data Unit (PDU) session to join a 5GS Bridge; send information including local bridging capabilities and delays to a Time Sensitive Networking Application Function (TSN AF) of the 5GS bridge; receive configuration information including a forwarding-rule-list; configure the bridging device based on the configuration information; and conduct Ethernet traffic related to the PDU session via the bridging device.

10. The apparatus of claim 9, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

11. The apparatus of claim 10, wherein causing the apparatus to conduct the Ethernet traffic related to the PDU session via the bridging device comprises causing the apparatus to: conduct a network communication session via the bridging device using local bridging from an ingress port to an egress port, wherein the ingress port and the egress port are two locally bridgeable ports.

12. The apparatus of claim 10, wherein causing the apparatus to conduct the Ethernet traffic related to the PDU session via the bridging device further comprises causing the apparatus to: conduct a network communication session via the bridging device using local bridging from an ingress port to the apparatus, wherein the ingress port and egress port are two ports not locally bridgeable, and cause the apparatus to send egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port.

13. The apparatus of claim 10, wherein causing the apparatus to conduct the Ethernet traffic related to the PDU session via the bridging device further comprises causing the apparatus to: conduct a network communication session via the bridging device using local bridging from the apparatus to an egress port, wherein an ingress port is not a local port of the bridging device, and ingress packets are received by the apparatus via the PDU session.

14. The apparatus of any of claims 8 through 13, wherein the apparatus is further caused to: provide port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability.

15. The apparatus of claim 14, wherein causing the apparatus to receive configuration information including a forwarding-rule-list comprises causing the apparatus to: receive configuration information including the forwarding-rule-list in response to the apparatus being caused to provide port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability.

16. A method comprising : receiving notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receiving initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); determining combinations of ingress and egress ports that are able to be bridged locally; calculating a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; exposing bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receiving forwarding and scheduling rules from the TSN CNC; 26 generating a forwarding-rule-list for an ingress port of the DS-TT ; providing configuration information to the DS-TT including the forwarding-rule-list; and causing the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list.

17. The method of claim 16, further comprising: modifying static filtering entries received from the TSN CNC and provided for a Network- Side TSN Translator (NW-TT) in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry.

18. The method of claim 16, wherein the initial configuration and capabilities from the DS-TT comprise a local-bridging-port-list, wherein the local-bridging-port-list comprises a list of egress ports to which it is possible to forward traffic locally when the port of the DS-TT is used as the ingress port.

19. The method of claim 18, wherein the initial configuration and capabilities from the DS-TT include per-traffic class delay information for each egress port.

20. The method of claim 19, wherein calculating the port-to-port per class delay matrix using the initial configuration and capabilities from the DS-TT comprises: calculating the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability.

21. The method of any of claims 16 through 20, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port.

22. The method of claim 21, wherein the forwarding-rule-list further comprises a stream identifier comprising a destination port MAC address and Virtual Local Area Network (VLAN) identifier.

23. The method of claim 22, further comprising translating the destination port MAC addresses into local identifiers.

24. A method comprising: receiving information comprising local bridging capabilities and delays from a bridging device; establishing a Protocol Data Unit (PDU) session to join a 5GS Bridge; 27 sending information including local bridging capabilities and delays to a Time Sensitive Networking Application Function (TSN AF) of the 5GS bridge; receiving configuration information including a forwarding-rule-list; configuring the bridging device based on the configuration information; and conducting Ethernet traffic related to the PDU session via the bridging device.

25. The method of claim 24, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

26. The method of claim 25, wherein conducting the Ethernet traffic related to the PDU session via the bridging device comprises: conducting a network communication session via the bridging device using local bridging from an ingress port to an egress port, wherein the ingress port and the egress port are two locally bridgeable ports.

27. The method of claim 25, wherein conducting the Ethernet traffic related to the PDU session via the bridging device further comprises: conducting a network communication session via the bridging device using local bridging from an ingress port to a User Equipment (UE), wherein the ingress port and egress port are two ports not locally bridgeable, and cause the UE to send egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port.

28. The method of claim 25, wherein conducting the Ethernet traffic related to the PDU session via the bridging device further comprises: conducting a network communication session via the bridging device using local bridging from the apparatus to an egress port, wherein an ingress port is not a local port of the bridging device, and ingress packets are received by the apparatus via the PDU session.

29. The method of any of claims 24 through 28, further comprising: providing port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability.

30. The method of claim 29, wherein receiving configuration information including a forwarding- rule-list comprises: receiving configuration information including the forwarding-rule-list in response to the apparatus being caused to provide port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability. 28

31. A computer program product comprising at least one non-transitory computer readable storage medium having computer executable program code instructions stored therein, the computer executable program code instructions comprising program code instructions configured, upon execution, to: receive notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; receive initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); determine combinations of ingress and egress ports that are able to be bridged locally; calculate a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; expose bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receive forwarding and scheduling rules from the TSN CNC; generate a forwarding-rule-list for an ingress port of the DS-TT ; provide configuration information to the DS-TT including the forwarding-rule-list; and cause the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list.

32. The computer program product of claim 31, further comprising program code instructions to: modify static filtering entries received from the TSN CNC and provided for a Network-Side

TSN Translator (NW-TT) in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry.

33. The computer program product of claim 31, wherein the initial configuration and capabilities from the DS-TT comprise a local-bridging-port-list, wherein the local-bridging-port-list comprises a list of egress ports to which it is possible to forward traffic locally when the port of the DS-TT is used as the ingress port.

34. The computer program product of claim 33, wherein the initial configuration and capabilities from the DS-TT include per-traffic class delay information for each egress port.

35. The computer program product of claim 34, wherein the program code instructions to calculate the port-to-port per class delay matrix using the initial configuration and capabilities from the DS-TT comprises program code instructions to: 29 calculate the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability.

36. The computer program product of any of claims 31 through 35, wherein the forwarding-rule- list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port.

37. The computer program product of claim 36, wherein the forwarding-rule-list further comprises a stream identifier comprising a destination port MAC address and Virtual Local Area Network (VLAN) identifier.

38. The computer program product of claim 37, further comprising program code instructions to translate the destination port MAC addresses into local identifiers.

39. A computer program product comprising at least one non-transitory computer readable storage medium having computer executable program code instructions stored therein, the computer executable program code instructions comprising program code instructions configured, upon execution, to: receive information comprising local bridging capabilities and delays from a bridging device; establish a Protocol Data Unit (PDU) session to join a 5GS Bridge; send information including local bridging capabilities and delays to a Time Sensitive Networking Application Function (TSN AF) of the 5GS bridge; receive configuration information including a forwarding-rule-list; configure the bridging device based on the configuration information; and conduct Ethernet traffic related to the PDU session via the bridging device.

40. The computer program product of claim 39, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

41. The computer program product of claim 40, wherein the program code instructions to conduct the Ethernet traffic related to the PDU session via the bridging device comprise program code instructions to: conduct a network communication session via the bridging device using local bridging from an ingress port to an egress port, wherein the ingress port and the egress port are two locally bridgeable ports. 30

42. The computer program product of claim 40, wherein the program code instructions to conduct the Ethernet traffic related to the PDU session via the bridging device further comprise program code instructions to: conduct a network communication session via the bridging device using local bridging from an ingress port to a User Equipment (UE), wherein the ingress port and egress port are two ports not locally bridgeable, and cause the UE to send egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port.

43. The computer program product of claim 40, wherein the program code instructions to conduct the Ethernet traffic related to the PDU session via the bridging device further comprise program code instructions to: conduct a network communication session via the bridging device using local bridging from a User Equipment (UE) to an egress port, wherein an ingress port is not a local port of the bridging device, and ingress packets are received by the UE via the PDU session.

44. The computer program product of any of claims 39 through 43, further comprising program code instructions to: provide port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability.

45. The computer program product of claim 44, wherein the program code instructions to receive configuration information including a forwarding-rule-list comprise program code instructions to: receive configuration information including the forwarding-rule-list in response to a User Equipment (UE) being caused to provide port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability.

46. An apparatus comprising: means for receiving notification of a new Protocol Data Unit (PDU) session and port of a multiport device being added to a bridge; means for receiving initial configuration and capabilities from a Device-Side Time Sensitive Networking Translator (DS-TT) using a Port Management Information Container (PMIC); means for determining combinations of ingress and egress ports that are able to be bridged locally; means for calculating a port-to-port per-class delay matrix using the initial configuration and capabilities from the DS-TT; 31 means for exposing bridge information to a Time Sensitive Networking Central Network Controller (TSN CNC) and receiving forwarding and scheduling rules from the TSN CNC; means for generating a forwarding-rule-list for an ingress port of the DS-TT; means for providing configuration information to the DS-TT including the forwarding-rule- list; and means for causing the DS-TT to configure internal bridging of a multiport device according to the forwarding-rule-list.

47. The apparatus of claim 46, further comprising: means for modifying static filtering entries received from the TSN CNC and provided for a Network-Side TSN Translator (NW-TT) in such a way that egress ports for which frames are already sent via local bridging are excluded from each entry.

48. The apparatus of claim 46, wherein the initial configuration and capabilities from the DS-TT comprise a local-bridging-port-list, wherein the local-bridging-port-list comprises a list of egress ports to which it is possible to forward traffic locally when the port of the DS-TT is used as the ingress port.

49. The apparatus of claim 48, wherein the initial configuration and capabilities from the DS-TT include per-traffic class delay information for each egress port.

50. The apparatus of claim 49, wherein the means for calculating the port-to-port per class delay matrix using the initial configuration and capabilities from the DS-TT comprise: means for calculating the port-to-port per-class delay matrix using DS-TT reported local bridging delays for port pairs of ingress ports and egress ports for which the DS-TT has indicated local bridging capability.

51. The apparatus of any of claims 46 through 50, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port.

52. The apparatus of claim 51, wherein the forwarding-rule-list further comprises a stream identifier comprising a destination port MAC address and Virtual Local Area Network (VLAN) identifier.

53. The apparatus of claim 52, wherein the apparatus further comprises means for translating the destination port MAC addresses into local identifiers. 32

54. An apparatus comprising: means for receiving information comprising local bridging capabilities and delays from a bridging device; means for establishing a Protocol Data Unit (PDU) session to join a 5GS Bridge; means for sending information including local bridging capabilities and delays to a Time Sensitive Networking Application Function (TSN AF) of the 5GS bridge; means for receiving configuration information including a forwarding-rule-list; means for configuring the bridging device based on the configuration information; and means for conducting Ethernet traffic related to the PDU session via the bridging device.

55. The apparatus of claim 54, wherein the forwarding-rule-list comprises destination port Media Access Control (MAC) addresses identifying each locally bridgeable port of the bridging device.

56. The apparatus of claim 55, wherein the means for conducting the Ethernet traffic related to the PDU session via the bridging device comprise: means for conducting a network communication session via the bridging device using local bridging from an ingress port to an egress port, wherein the ingress port and the egress port are two locally bridgeable ports.

57. The apparatus of claim 55, wherein the means for conducting the Ethernet traffic related to the PDU session via the bridging device further comprise: means for conducting a network communication session via the bridging device using local bridging from an ingress port to the apparatus, wherein the ingress port and egress port are two ports not locally bridgeable, and cause the apparatus to send egress packets to the User Plane Function (UPF) using the PDU session associated with the ingress port.

58. The apparatus of claim 55, wherein the means for conducting the Ethernet traffic related to the PDU session via the bridging device further comprise: means for conducting a network communication session via the bridging device using local bridging from the apparatus to an egress port, wherein an ingress port is not a local port of the bridging device, and ingress packets are received by the apparatus via the PDU session.

59. The apparatus of any of claims 54 through 58, further comprising: means for providing port capabilities including a list of locally bridgeable ports with per-class delay information and forwarding rules capability. 33

60. The apparatus of claim 59, wherein the means for receiving configuration information including a forwarding-rule-list comprise: means for receiving configuration information including the forwarding-rule-list in response to the apparatus being caused to provide port capabilities including the list of locally bridgeable ports with per-class delay information and forwarding rules capability.