ETHERNET-BASED FIELDBUS PACKET EXCHANGE WITHIN A MOBILE WIRELESS COMMUNICATION NETWORK

Apparatuses, methods, and systems are disclosed for ethernet-based fieldbus packet exchange within a mobile wireless communication network. One apparatus (700) includes a transceiver (725) in communication with a first node in an ethernet-based fieldbus system and a plurality of user equipment (“UE”) devices via a mobile wireless communication network. The apparatus includes a processor (705) that determines configuration information that comprises a mapping defining which datagrams of a packet each of the plurality of UE devices within the mobile wireless communication network receives and a sequence in which each UE device receives the datagrams. The processor (705) further receives a packet comprising a plurality of datagrams. The processor (705) further determines which datagrams of the plurality of datagrams are for each UE device according to the configuration information and sends to each UE device, in order of the sequence defined by the configuration information, a packet comprising the datagrams.

FIELD

The subject matter disclosed herein relates generally to wireless communications and more particularly relates to ethernet-based fieldbus packet exchange within a mobile wireless communication network.

BACKGROUND

In certain wireless communication systems, a mobile wireless communication network can be used to facilitate datagram transmissions for an ethernet-based fieldbus packet exchange within a mobile wireless communication network.

BRIEF SUMMARY

Disclosed are procedures for ethernet-based fieldbus packet exchange within a mobile wireless communication network. Said procedures may be implemented by apparatus, systems, methods, and/or computer program products.

One method of a network function in a mobile communication network includes a configuration delivery management entity for an ethernet-based fieldbus packet exchange within a mobile wireless communication network that receives configuration information from control node, where the configuration information includes information about the topology of the ethernet-based fieldbus packet exchange devices and the ethernet-based fieldbus packet exchange datagrams required by each device.

One method of a network function in a mobile communication network includes a translation function that receives configuration information from the configuration delivery management entity and determines based on the configuration information the order of the device to forwards an ethernet packet received from the control node and which datagrams each device receives.

DETAILED DESCRIPTION

Generally, the present disclosure describes systems, methods, and apparatus for ethernet-based fieldbus packet exchange within a mobile wireless communication network. In certain embodiments, the methods may be performed using computer code embedded on a computer-readable medium. In certain embodiments, an apparatus or system may include a computer-readable medium containing computer-readable code which, when executed by a processor, causes the apparatus or system to perform at least a portion of the below described solutions.

Regarding time sensitive networks (“TSN”), a 3GPP system supports TSNs in the following ways:i. The mobile wireless communication network, e.g., a 5G system (“5GS”) is integrated with the external network as a TSN bridge.ii. TSN translators such as network-side TSN translators (“NW-TT”) and device-side TSN translators (“DS-TT”) achieve time synchronization between the external TSN clocks and internal 5GS clock.iii. An application function (“AF”) provides quality of service (“QoS”)/synchronization requirements to the 3GPP system that the session management function (“SMF”) in the 5G core converts into TSC assistance information. The TSC assistance information describes traffic characteristics (e.g., burst arrival time) that is used by the radio access network (“RAN”) to schedule the TSN traffic.

The current procedure is useful to external TSN networks that require the 5GS to be incorporated as a TSN bridge supporting mainly time synchronization protocols defined by IEEE (e.g., synchronization methods based on IEEE 802.1Q).

However, there are external TSN systems in which having the 5GS system as a bridge is not optimal to the TSN operation. One example is to support industrial Ethernet protocols like Ethernet for control automation technology (“EtherCAT”), PROFINET, SERCOS, and/or the like, relying on summation frame and/or ring topology for networking with and without TSN. Although EtherCAT is taken as an example herein for simplicity and consistency, the embodiments described herein are equally applicable to other Industrial Ethernet schemes such as PROFINET, SERCOS, and/or the like, as well as schemes using ring topology to distribute Ethernet data to nodes wirelessly.

For example, EtherCAT networking allows transmission of data to multiple recipients within one Ethernet frame. Each Ethernet frame may contain multiple EtherCAT datagrams, where each datagram corresponds to a single or a group of device(s). A network implementing EtherCAT network consists of an EtherCAT master and multiple EtherCAT slave devices, which may be connected in a ring topology.

An EtherCAT master sends Ethernet frames containing one or more EtherCAT datagrams. The Ethernet frame (containing EtherCAT datagrams) is sent to each slave device in the network. Each slave device processes one or more datagrams contained in the Ethernet packet according to configuration information. Each EtherCAT datagram includes a header that comprises information on what type of instruction the master requires the slave device(s) to execute. The information may include an operation, such as read, write, or read/write, and a device address, which may address a single or a group of slave devices. Once the Ethernet packet reaches the last slave device the Ethernet packet is sent back to the EtherCAT master.

In a 5G system, EtherCAT networks can be supported using an EtherCAT master that is located either at the network side (e.g., EtherCAT network or other ethernet-based fieldbus system) or the UE side of the 5G core, and EtherCAT slave devices that are located at the UE side. In a conventional deployment option, an EtherCAT master that is located at the network side sends EtherCAT datagrams within Ethernet frames in the downlink direction that is received by slave UE devices on the radio side. As each Ethernet frame must be processed by every slave UE device due to the ring topology implementation, the Ethernet frame must pass through every UE in the 5G system. This creates additional latency in the 5G system as the same Ethernet frame is sent between each UE via both uplink and downlink.

In addition, another issue with conventional deployments is how each UE supporting EtherCAT slave functionality is configured to send the Ethernet frame to the next UE in the topology (e.g., in wireline environments each slave UE is physically connected to each other).

Thus, this disclosure addresses the following:i. Configuring network topology using a 5G system for sending and receiving packets for ethernet-based fieldbus packet exchange within a mobile wireless communication network; andii. Reducing latency by defining a method where the 3GPP system is aware of which UEs require one or more EtherCAT datagrams contained in the Ethernet frame.

FIG.1depicts a wireless communication system100for ethernet-based fieldbus packet exchange within a mobile wireless communication network, according to embodiments of the disclosure. In one embodiment, the wireless communication system100includes at least one remote unit105, a Fifth-Generation Radio Access Network (“5G-RAN”)115, and a mobile core network140. The 5G-RAN115and the mobile core network140form a mobile communication network. The 5G-RAN115may be composed of a 3GPP access network120containing at least one cellular base unit121and/or a non-3GPP access network130containing at least one access point131. The remote unit105communicates with the 3GPP access network120using 3GPP communication links123and/or communicates with the non-3GPP access network130using non-3GPP communication links133. Even though a specific number of remote units105, 3GPP access networks120, cellular base units121, 3GPP communication links123, non-3GPP access networks130, access points131, non-3GPP communication links133, and mobile core networks140are depicted inFIG.1, one of skill in the art will recognize that any number of remote units105, 3GPP access networks120, cellular base units121, 3GPP communication links123, non-3GPP access networks130, access points131, non-3GPP communication links133, and mobile core networks140may be included in the wireless communication system100.

In one implementation, the RAN120is compliant with the 5G system specified in the Third Generation Partnership Project (“3GPP”) specifications. For example, the RAN120may be a NG-RAN, implementing NR RAT and/or LTE RAT. In another example, the RAN120may include non-3GPP RAT (e.g., Wi-Fi® or Institute of Electrical and Electronics Engineers (“IEEE”) 802.11-family compliant WLAN). In another implementation, the RAN120is compliant with the LTE system specified in the 3GPP specifications. More generally, however, the wireless communication system100may implement some other open or proprietary communication network, for example Worldwide Interoperability for Microwave Access (“WiMAX”) or IEEE 802.16-family standards, among other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

The remote units105may communicate directly with one or more of the cellular base units121in the 3GPP access network120via uplink (“UL”) and downlink (“DL”) communication signals. Furthermore, the UL and DL communication signals may be carried over the 3GPP communication links123. Similarly, the remote units105may communicate with one or more access points131in the non-3GPP access network(s)130via UL and DL communication signals carried over the non-3GPP communication links133. Here, the access networks120and130are intermediate networks that provide the remote units105with access to the mobile core network140.

In some embodiments, the remote units105communicate with a remote host (e.g., in the data network150or in the data network160) via a network connection with the mobile core network140. For example, an application107(e.g., web browser, media client, telephone and/or Voice-over-Internet-Protocol (“VoIP”) application) in a remote unit105may trigger the remote unit105to establish a protocol data unit (“PDU”) session (or other data connection) with the mobile core network140via the 5G-RAN115(i.e., via the 3GPP access network120and/or non-3GPP network130). The mobile core network140then relays traffic between the remote unit105and the remote host using the PDU session. The PDU session represents a logical connection between the remote unit105and a User Plane Function (“UPF”)141.

In order to establish the PDU session (or PDN connection), the remote unit105must be registered with the mobile core network140(also referred to as “attached to the mobile core network” in the context of a Fourth Generation (“4G”) system). Note that the remote unit105may establish one or more PDU sessions (or other data connections) with the mobile core network140. As such, the remote unit105may have at least one PDU session for communicating with the packet data network150. Additionally—or alternatively—the remote unit105may have at least one PDU session for communicating with the packet data network160. The remote unit105may establish additional PDU sessions for communicating with other data networks and/or other communication peers.

In the context of a 5G system (“5GS”), the term “PDU Session” refers to a data connection that provides end-to-end (“E2E”) user plane (“UP”) connectivity between the remote unit105and a specific Data Network (“DN”) through the UPF131. A PDU Session supports one or more Quality of Service (“QoS”) Flows. In certain embodiments, there may be a one-to-one mapping between a QoS Flow and a QoS profile, such that all packets belonging to a specific QoS Flow have the same 5G QOS Identifier (“5QI”).

In the context of a 4G/LTE system, such as the Evolved Packet System (“EPS”), a Packet Data Network (“PDN”) connection (also referred to as EPS session) provides E2E UP connectivity between the remote unit and a PDN. The PDN connectivity procedure establishes an EPS Bearer, i.e., a tunnel between the remote unit105and a Packet Gateway (“PGW”, not shown) in the mobile core network130. In certain embodiments, there is a one-to-one mapping between an EPS Bearer and a QoS profile, such that all packets belonging to a specific EPS Bearer have the same QoS Class Identifier (“QCI”).

As described in greater detail below, the remote unit105may use a first data connection (e.g., PDU Session) established with the first mobile core network130to establish a second data connection (e.g., part of a second PDU session) with the second mobile core network140. When establishing a data connection (e.g., PDU session) with the second mobile core network140, the remote unit105uses the first data connection to register with the second mobile core network140.

The cellular base units121may be distributed over a geographic region. In certain embodiments, a cellular base unit121may also be referred to as an access terminal, a base, a base station, a Node-B (“NB”), an Evolved Node B (abbreviated as eNodeB or “eNB,” also known as Evolved Universal Terrestrial Radio Access Network (“E-UTRAN”) Node B), a 5G/NR Node B (“gNB”), a Home Node-B, a Home Node-B, a relay node, a device, or by any other terminology used in the art. The cellular base units121are generally part of a radio access network (“RAN”), such as the 3GPP access network120, that may include one or more controllers communicably coupled to one or more corresponding cellular base units121. These and other elements of radio access network are not illustrated but are well known generally by those having ordinary skill in the art. The cellular base units121connect to the mobile core network140via the 3GPP access network120.

The cellular base units121may serve a number of remote units105within a serving area, for example, a cell or a cell sector, via a 3GPP wireless communication link123. The cellular base units121may communicate directly with one or more of the remote units105via communication signals. Generally, the cellular base units121transmit DL communication signals to serve the remote units105in the time, frequency, and/or spatial domain. Furthermore, the DL communication signals may be carried over the 3GPP communication links123. The 3GPP communication links123may be any suitable carrier in licensed or unlicensed radio spectrum. The 3GPP communication links123facilitate communication between one or more of the remote units105and/or one or more of the cellular base units121. Note that during NR operation on unlicensed spectrum (referred to as “NR-U”), the base unit121and the remote unit105communicate over unlicensed (i.e., shared) radio spectrum.

The non-3GPP access networks130may be distributed over a geographic region. Each non-3GPP access network130may serve a number of remote units105with a serving area. An access point131in a non-3GPP access network130may communicate directly with one or more remote units105by receiving UL communication signals and transmitting DL communication signals to serve the remote units105in the time, frequency, and/or spatial domain. Both DL and UL communication signals are carried over the non-3GPP communication links133. The 3GPP communication links123and non-3GPP communication links133may employ different frequencies and/or different communication protocols. In various embodiments, an access point131may communicate using unlicensed radio spectrum. The mobile core network140may provide services to a remote unit105via the non-3GPP access networks130, as described in greater detail herein.

In some embodiments, a non-3GPP access network130connects to the mobile core network140via an interworking entity135. The interworking entity135provides an interworking between the non-3GPP access network130and the mobile core network140. The interworking entity135supports connectivity via the “N2” and “N3” interfaces. As depicted, both the 3GPP access network120and the interworking entity135communicate with the AMF143using a “N2” interface. The 3GPP access network120and interworking entity135also communicate with the UPF141using a “N3” interface. While depicted as outside the mobile core network140, in other embodiments the interworking entity135may be a part of the core network. While depicted as outside the non-3GPP RAN130, in other embodiments the interworking entity135may be a part of the non-3GPP RAN130.

In certain embodiments, a non-3GPP access network130may be controlled by an operator of the mobile core network140and may have direct access to the mobile core network140. Such a non-3GPP AN deployment is referred to as a “trusted non-3GPP access network.” A non-3GPP access network130is considered as “trusted” when it is operated by the 3GPP operator, or a trusted partner, and supports certain security features, such as strong air-interface encryption. In contrast, a non-3GPP AN deployment that is not controlled by an operator (or trusted partner) of the mobile core network140, does not have direct access to the mobile core network140, or does not support the certain security features is referred to as a “non-trusted” non-3GPP access network. An interworking entity135deployed in a trusted non-3GPP access network130may be referred to herein as a Trusted Network Gateway Function (“TNGF”). An interworking entity135deployed in a non-trusted non-3GPP access network130may be referred to herein as a non-3GPP interworking function (“N3IWF”). While depicted as a part of the non-3GPP access network130, in some embodiments the N3IWF may be a part of the mobile core network140or may be located in the data network150.

In one embodiment, the mobile core network140is a 5G core (“5GC”) or the evolved packet core (“EPC”), which may be coupled to a data network150, like the Internet and private data networks, among other data networks. A remote unit105may have a subscription or other account with the mobile core network140. Each mobile core network140belongs to a single public land mobile network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

The mobile core network140includes several network functions (“NFs”). As depicted, the mobile core network140includes at least one user plane function (“UPF”)141. The mobile core network140also includes multiple control plane functions including, but not limited to, an Access and Mobility Management Function (“AMF”)143that serves the 5G-RAN115, a Session Management Function (“SMF”)145, a Policy Control Function (“PCF”)146, an Authentication Server Function (“AUSF”)147, a Unified Data Management (“UDM”) and Unified Data Repository function (“UDR”).

The UPF(s)141is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU session for interconnecting Data Network (“DN”), in the 5G architecture. The AMF143is responsible for termination of NAS signaling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The SMF145is responsible for session management (i.e., session establishment, modification, release), remote unit (i.e., UE) IP address allocation & management, DL data notification, and traffic steering configuration for UPF for proper traffic routing.

The PCF146is responsible for unified policy framework, providing policy rules to CP functions, access subscription information for policy decisions in UDR. The AUSF147acts as an authentication server.

The UDM is responsible for generation of Authentication and Key Agreement (“AKA”) credentials, user identification handling, access authorization, subscription management. The UDR is a repository of subscriber information and can be used to service a number of network functions. For example, the UDR may store subscription data, policy-related data, subscriber-related data that is permitted to be exposed to third party applications, and the like. In some embodiments, the UDM is co-located with the UDR, depicted as combined entity “UDM/UDR”149.

In various embodiments, the mobile core network140may also include an Network Exposure Function (“NEF”) (which is responsible for making network data and resources easily accessible to customers and network partners, e.g., via one or more APIs), a Network Repository Function (“NRF”) (which provides NF service registration and discovery, enabling NFs to identify appropriate services in one another and communicate with each other over Application Programming Interfaces (“APIs”)), or other NFs defined for the 5GC. In certain embodiments, the mobile core network140may include an authentication, authorization, and accounting (“AAA”) server.

In various embodiments, the mobile core network140supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Here, a “network slice” refers to a portion of the mobile core network140optimized for a certain traffic type or communication service. A network instance may be identified by a S-NSSAI, while a set of network slices for which the remote unit105is authorized to use is identified by NSSAI. In certain embodiments, the various network slices may include separate instances of network functions, such as the SMF and UPF141. In some embodiments, the different network slices may share some common network functions, such as the AMF143. The different network slices are not shown inFIG.1for ease of illustration, but their support is assumed.

Although specific numbers and types of network functions are depicted inFIG.1, one of skill in the art will recognize that any number and type of network functions may be included in the mobile core network140. Moreover, where the mobile core network140comprises an EPC, the depicted network functions may be replaced with appropriate EPC entities, such as an MME, S-GW, P-GW, HSS, and the like.

WhileFIG.1depicts components of a 5G RAN and a 5G core network, the described embodiments for using a pseudonym for access authentication over non-3GPP access apply to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfoxx, and the like. For example, in an 4G/LTE variant involving an EPC, the AMF143may be mapped to an MME, the SMF mapped to a control plane portion of a PGW and/or to an MME, the UPF141may be mapped to an SGW and a user plane portion of the PGW, the UDM/UDR149may be mapped to an HSS, etc.

As depicted, a remote unit105(e.g., a UE) may connect to the mobile core network (e.g., to a 5G mobile communication network) via two types of accesses: (1) via 3GPP access network120and (2) via a non-3GPP access network130. The first type of access (e.g., 3GPP access network120) uses a 3GPP-defined type of wireless communication (e.g., NG-RAN) and the second type of access (e.g., non-3GPP access network130) uses a non-3GPP-defined type of wireless communication (e.g., WLAN). The 5G-RAN115refers to any type of 5G access network that can provide access to the mobile core network140, including the 3GPP access network120and the non-3GPP access network130.

In the depicted embodiment, an ethernet-based fieldbus data network170may be connected to the mobile network140. As used herein, an ethernet-based fieldbus data network170may include an industrial computer network that is used for (real-time) distributed control of UEs, such as remote unit105, robots, and/or other machines, using Ethernet data packets. The ethernet-based fieldbus data network170may include a configuration management node, such as an EtherCAT Delivery Configuration Management node, application function, server, and/or the like and a control node172such as an EtherCAT master control node.

In various embodiments, the configuration management node171and/or the control node172is connected to the mobile network140via a network-side (or UPF141side) TSN translator (“NW-TT”)151or a network exposure function (“NEF”)153or a device-side TSN translator (“DS-TT”)152(located within the RAN115and/or on a UE device105), which are used to configure and manage packet signaling, transmission, reception, sequencing, order, and/or the like of Ethernet packets (e.g., EtherCAT packets) from the control node172to various UEs, such as remote unit105.

FIG.2depicts a network architecture200for ethernet-based fieldbus packet exchange within a mobile wireless communication network. The depicted network architecture200and elements are described with respect to EtherCAT but would be equally applicable to other industrial ethernet protocols and standards.

In one embodiment, the network architecture200includes an EtherCAT network202that includes an EtherCAT Delivery Configuration Management entity (“EDCM”)204, which may be similar to the configuration management node171inFIG.1, and an EtherCAT master node206, which may be similar to the control node172inFIG.1. Both the EDCM204and the master node206may be connected to an EtherCAT translator function (“ECATTF”)208acting as or located within a NW-TT or other function interfacing with the UPF.

In further embodiments, the network architecture200includes a 5G core210(similar to the mobile network140depicted inFIG.1), a RAN115, and plurality of UEs, one acting as an EtherCAT master212and other UE slave devices214a-214b(collectively214), which may each include a DS-TT. As shown in the depicted network architecture200, an EtherCAT master206may be located on the network side and may send Ethernet packets that are received via N6 by a UPF. In other embodiments, an EtherCAT master212may be a UE sending Ethernet packets in the uplink over Uu. In one embodiment, the EDCM240may connect to the 5G core210, e.g., the mobile network140, via a NEF153.

In one embodiment, the EDCM204is an entity, node, server, application function, or the like of the EtherCAT network202. The EDCM204may be configured to provide configuration of both physical and logical EtherCAT topology (e.g., how each slave UE device214is configured to send Ethernet packets to the next UE214in the logical ring topology, for example; however, physical topology can be line, star, ring, or the like) to each slave UE device214. The EDCM204may further be configured to provide the number of slave UE devices214with corresponding addressing and placement of each slave UE device214in the logical ring topology. The ring topology configuration may either be provided to the ECATTF208(described below) or to each UE slave device214. In the former case, the ECATTF208determines the next UE slave device214in the topology configuration that required an ethernet packet. In the latter case, the UE slave device214determines the next UE slave device214to send an ethernet packet.

In certain embodiments, the EtherCAT master node206,212provides a cycle time of an EtherCAT frame. If there are more than one EtherCAT frame transmitted by the EtherCAT master node206,212, then the cycle time of each EtherCAT frame is provided. Further, the EtherCAT master node206,212provides an expected traffic arrival/transmission to/from each slave UE device214from one or more EtherCAT frames.

The EDCM204, in one embodiment, is configured to provide an EtherCAT datagrams configuration where the 3GPP system (e.g., the ECATTF208) receives information on which UE slave devices214require specific EtherCAT datagrams included in an Ethernet frame (e.g., a telegram) received from the EtherCAT master206,212. In certain embodiments, the EDCM provides configuration information for non-real-time traffic, e.g., packets that contain no EtherCAT datagrams (e.g., packets may include configuration information from the EtherCAT master206,212). The configuration information may include QoS configuration information.

In one embodiment, the EDCM204is configured to provide TSC assistance information (e.g., the EDCM204acting as an AF) where the TSC assistance information includes information for each slave UE device214according to datagrams required by each slave UE device214. TSC assistance information is described in 3GPP TS 23.501.

The TSC assistance information may also include a survival time configuration. The survival time configuration can provide information regarding whether a survival time is applicable for each slave UE device214or for all slave UE devices214/EtherCAT frame. As an example, survival time consists of consecutive error packets that can be tolerated by an application which can be failure to decode consecutive transport blocks at the physical layer. In one implementation, a survival timer is maintained per slave UE device214at the RAN115and in another implementation, a survival timer is maintained per EtherCAT frame or a combination of both in the third example. A survival timer for each slave could be started/stopped/expired based on the decoding status of a transport block, where the survival timer is started when a packet decoding fails, and it stops when at least one packet is received successfully, and the timer expires when the consecutive packet failure reaches the beyond a tolerable limit.

In another exemplary implementation a survival timer is started upon the detection of a transmission failure, e.g., based on hybrid automatic repeat request (“HARQ”) feedback received from a receiving device, e.g., EtherCAT master node206,212. In one example, the survival timer is started when a packet transmission fails, and it stops when at least one consecutive packet is successfully transmitted. The survival timer may expire when the consecutive packet transmission failure reaches the beyond a tolerable limit. When the survival timer is maintained for a EtherCAT frame, it is started/stopped/expired based on a decoding status of one or more slave UE device(s)214receiving the EtherCAT frame. As an example, when there is dependency between slave1and slave2in the ring topology, failure to decode a packet by slave1also has an impact on slave2, hence a common survival timer is sufficed. In another implementation, a common survival timer could be defined for a subset of slaves when there is a dependency.

The EDCM204also receives from the EtherCAT master206,212configuration information describing the configuration to use based on the communication time (e.g., the time between the EtherCAT master206,212sending the frame, propagation delay in the 5G core210, and receiving the frame). In one embodiment the communication time is the EtherCAT cycle time. In certain embodiments communication time is expected traffic arrival/transmission to/from each slave UE node214from one or more EtherCAT frames. In one embodiment, configuration information enables the EtherCAT datagram parsing at the ECATTF208if the communication time exceeds a specific communication time threshold.

The ECATTF208, in one embodiment, is configured to determine, based on the received configuration information, to which slave UE devices214to send one or more EtherCAT datagrams received from an EtherCAT master206,212. In further embodiments, the ECATTF208may be located within an NW-TT, DS-TT, or a new function that can interface with the UPF or slave UE devices214.

FIG.3illustrates a general procedure300for ethernet-based fieldbus packet exchange within a mobile wireless communication network, according to embodiments of the disclosure. The depicted network architecture200and elements are described with respect to EtherCAT but would be equally applicable to other industrial ethernet protocols and standards. In one embodiment, many of the elements illustrated inFIG.3are similar to the elements illustrated and described above with reference toFIG.2.

In one embodiment, the ECATTF208receives configuration information302from the EDCM204(not shown) describing what EtherCAT datagrams each target device (slave UE devices214) requires. In one embodiment, the configuration information302may be also pre-configured at the ECATTF208. The configuration information302may include the order that slave UE devices214are to receive Ethernet packets comprising certain EtherCAT datagrams and also which EtherCAT datagrams each slave UE device214is to receive (either the original EtherCAT datagrams sent from the EtherCAT master206or EtherCAT datagrams that have been modified by a previous slave UE device214in the ring topology).

In one embodiment, when the ECATTF208receives an Ethernet packet from an EtherCAT master206containing one or more datagrams, the ECATTF208determines the first slave UE device214in the EtherCAT ring topology to receive the Ethernet packet based on the configuration information302.

In one embodiment, the ECATTF208determines, based on the configuration information302, which EtherCAT datagrams from the plurality of EtherCAT datagrams are to be sent to which slave UE devices214. The ECATTF208, in one embodiment, constructs an Ethernet packet with the datagrams and sends the Ethernet packet to the slave UE devices214. In one embodiment, the ECATTF208repeats the above procedures for the next slave UE device214in the ring topology, according to the configuration information302. In certain embodiments, if the EtherCAT master206sends non-real-time information (e.g., packets containing no EtherCAT datagrams), the ECATTF208sends the packet to the slave UE devices214according to a configuration received from the EDCM204.

FIG.4depicts a signaling flow diagram for a procedure400for ethernet-based fieldbus packet exchange within a mobile wireless communication network. The depicted procedure400and elements are described with respect to EtherCAT but would be equally applicable to other industrial ethernet protocols and standards. In one embodiment, many of the elements illustrated inFIG.4are similar to the elements illustrated and described above with reference toFIGS.2and3. In one embodiment, the procedure400involves at least two slave UE devices404,408(e.g., EtherCAT slave devices) and corresponding EDCM clients402,404. The procedure400, in some embodiments, also involves an ECATTF208, an EDCM server204, a service enabler architecture layer (“SEAL”) server410, and an EtherCAT master206within an EtherCAT system, e.g., an EtherCAT network202.

In certain embodiments, the EDCM server204can be seen as a middleware application entity, which may reside at the EtherCAT network202or at the mobile network operator (“MNO”) domain. The EDCM client402,406, in various embodiments, is the middleware's client counterpart at the slave UE device404,408side and interacts with the EDCM server204to receive datagram mapping configuration. In one embodiment, the role of the EDCM server204is to configure the datagram mapping (e.g., slave UE device order and datagram assignment) per EtherCAT slave UE device404,408, as well as the identity management of EtherCAT entities for communicating over the 5GS.

The EDCM server204, in some embodiments, may be deployed as one or more of the following: an AF (as defined in 23.501), a SEAL server functionality (as specified in 3GPP TS23.434), a vertical-specific enabler server functionality (as specified in 3GPP TR 23.745), an Edge Enabler Server/Edge Configuration Server functionality (as defined in 3GPP TS 23.558), a MEC platform capability, and/or the like. In one embodiment, the EDCM client402,406may be deployed as one or more of the following: a SEAL client functionality (as specified in 3GPP TS23.434), a vertical-specific enabler client functionality (as specified in 3GPP TR 23.745), an Edge Enabler Client/Application Client functionality (as defined in 3GPP TS 23.558), and/or the like.

In one embodiment, the EtherCAT master206(or, more generally, an application specific server) in an EtherCAT system sends a request to the EDCM server204(see messaging420) to manage EtherCAT delivery over the 5GS. This request may include the type of management required, the time validity, and geographical area for which the request applies. The type of management depends on the needs of the EtherCAT system/master and can include providing the datagram mapping to slave device configuration; supporting the identity management of the slave UE devices404,408in relation to 3GPP system; configuring application QoS parameters per session (corresponding to a slave UE device404,408or a group of slave UE devices404,408); and configuring the topology, and in particular the order/sequence of transmissions from each slave device e.g., to ensure minimizing the per session and end-to-end key performance indicators (“KPIs”).

The EtherCAT master206, in one embodiment, may send the configuration information when the EtherCAT master206determines that the communication time exceeds a specific time threshold. Alternatively, in various embodiments, the EtherCAT master206includes the requested EtherCAT configuration information per communication time. In this alternative, the EDCM server204calculates the communication time based on information received from the NW-TT and DS-TT. In one embodiment communication time is the time sensitive network (“TSN”) residence time calculated between NW-TT and DS-TT as described in 3GPP TS 23.501.

In one embodiment, the EDCM server204sends (see messaging422) a response to the request as result (e.g., either a positive or negative acknowledgment). In further embodiments, the EtherCAT master206sends (see messaging424) additional configuration information to the EDCM server204. The configuration information may include the datagram mapping configuration from the EtherCAT system such as the slave UE device address, which may be the node address, e.g., a Configured Station Address/Alias for each slave UE device404,408or a physical address, and the mapping of the slave UE device address to a list of logical addresses, which identifies the permissions of each slave UE device404,408over the datagrams.

Such mapping of logical to physical addresses can be derived by a fieldbus memory management unit (“FMMU”), which is configured by the EtherCAT master206and is available in all slave UE devices404,408. Also, the source MAC address, e.g., for EtherCAT frames, and IP address of the slave UE devices404,408can be included, e.g., in case that EtherCAT datagrams are encapsulated in UDP/IP frames. The EtherCAT master206may send topological information that is necessary to the EDCM server204for deriving the order of transmissions as well as the port management policies (e.g., at the DS-TT/NW-TT).

In one embodiment, the EDCM server sends204(see messaging426) a request to a SEAL Identity Management (“IM”) server410for determining the slave UE device identifiers corresponding to the application session (e.g., an EtherCAT command consisting of one or more EtherCAT frames can be seen as the end-to-end session).

In one embodiment, the SEAL server410retrieves and/or generates the vertical application later (“VAL”) UE group identities to be used in relation with the 3GPP system and sends (see messaging428) the identifies to the EDCM server204. Such identities may include VAL UE IDs, 3GPP UE IDs (e.g., generic public subscription identifiers (“GPSIs”, permanent equipment identifiers (“PEIs”), international mobile equipment identities (“IMEIs”), and/or VAL Group IDs (external group identifiers)). It is noted that the EDCM server204is shown as a separate logical entity; however, in certain implementations, the EDCM server204may be deployed together with the SEAL server410or the EDCM capability may be shared among other servers such as a configuration management (“CM”) server, an identify management (“IM”) server, and/or the like.

In a further embodiment, the EDCM server204retrieves or generates the VAL UE identities and/or VAL group identities to be used in relation with the 3GPP system. In such an embodiment, the EDCM server204retrieves and/or generates the VAL UE identities based on a pre-configuration of the mapping between the VAL application and the corresponding VAL UEs.

In one embodiment, the EDCM server204determines (see block430) a configuration of the EtherCAT delivery based on the type in Step 1a. Such configuration can include a mapping of the datagrams to slave UE devices404,408based on a mapping of a logical address to a slave UE device ID (e.g., based on the generated and/or the configured station address).

In further embodiments, the configuration information can include the order or sequence of transmitting datagrams to the slave UE devices404,408, including application traffic triggering rules (e.g., when each slave UE device404,408is triggered to send Ethernet packets to the next UE in the ring topology, based on the determined sequence). The sequence can be either in a form of a list or timetable indicating an order of slave UE devices404,408(e.g., based on their device IDs, logical addresses, or the like) to trigger the following transmission. This can be either enforced by the NW-TT/UPF (e.g., ECATFF functionality) or at the device side (by the application of the slave UE devices404,408, as triggered by EDCM layer).

In some embodiments, the configuration information can include a determination of the QoS requirements such as latency, reliability, jitter, and/or the like per QoS flow, which may be included within the application session (e.g., different communication links per slave UR device404,408may have different QoS requirements, depending on the datagram mapping). In particular, the QoS requirements may be derived end-to-end, e.g., when the EtherCAT master206receives the datagrams after being transmitted throughout the ring topology, it knows the experienced QoS, but it does not monitor the QoS for the constituent links. The EDCM server204may provide the QoS requirements per involved link (e.g., EtherCAT master206to slave UE device1408, slave UE device1408to slave UE device2404, and slave UE device2404to EtherCAT master206), so as to support the network to map the different protocol data unit (“PDU”) sessions (e.g., per slave) to different QoS flows.

In one embodiment, the EDCM server204sends (see messaging432) the determined configuration information/parameters to the ECATFF208(e.g., based on step 1e). Such parameters can be related to the datagram mapping (e.g., this can be in the format of <list of logical addresses, station address, generated Device IDs>), the application traffic triggering policies (e.g., the order of the slave UE devices404,408so as to allow the ECATTF208to coordinate the end-to-end transmissions), the application QoS requirements per slave UE device session, NW-TT port management policies, and/or the like.

In one embodiment, the EDCM server204sends (see messaging434) the configuration parameters to the EDCM clients402,406of slave UE devices404,408, together with the application traffic triggering policies from one slave UE device408to another slave UE device404, and optionally the QoS parameters for the slave UE device session. EDCM clients402,406may interact with the lower layers at the slave UE devices to check the logical-to-physical address mapping (e.g., via FMMU), as well as the logical addresses-to-device ID mapping to receive or determine the correct datagrams for each slave UE device404,408and forward traffic to other slave UE devices404,408. The EDCM clients402,406may also interact with an EtherCAT application specific client to provide the application QoS requirements and traffic triggering policies.

FIGS.5A and5Bdepict a signaling flow diagram for a procedure500for ethernet-based fieldbus packet exchange within a mobile wireless communication network. The depicted procedure500and elements are described with respect to EtherCAT but would be equally applicable to other industrial ethernet protocols and standards. In one embodiment, many of the elements illustrated inFIG.4are similar to the elements illustrated and described above with reference toFIGS.2-4. In one embodiment, the procedure500involves at least two slave UE devices404,408(e.g., EtherCAT slave devices) and corresponding EDCM clients402,404. The procedure500, in some embodiments, also involves a RAN115, an SMF145, a UPF141, an ECATTF208, an EDCM server204, a SEAL) server410, and an EtherCAT master206within an EtherCAT system, e.g., an EtherCAT network202.

In one embodiment, the ECATTF208and slave UE devices404,408receive configuration information from the EDCM204entity/server (which may be acting as an AF). The configuration information may include information on the EtherCAT datagrams required by each slave UE device404,408, and ring topology configuration. Alternatively, each slave UE device404,408and the ECATTF208may be pre-configured with this information.

In one embodiment, the EDCM204sends the configuration when the EDCM204determines that the communication time exceeds a predefined, calculated, or otherwise determined threshold time. In an alternative embodiment, the EtherCAT master206sends the configuration information to the EDCM204when the EtherCAT master206determines that the communication time exceeds a threshold time.

In one embodiment, the EDCM204determines (see block504) time sensitive communication (“TSC”) assistance information required for each slave UE device404,408based on the datagrams, time synchronization, and QOS requirements.

In certain embodiments, the EDCM204provides (see messaging506) the TSC assistance information to the SMF145, e.g., as described in 3GPP TS 23.502. In further embodiments, the SMF145provides (see messaging508) the TSC assistance information to the RAN115for each QoS flow for each slave UE device404,408.

In one embodiment, the EtherCAT master206constructs an Ethernet packet containing one or more EtherCAT datagrams for EtherCAT slave UE devices404,408and sends (see messaging510) the packet via a user plane to the 3GPP network, e.g., to the ECATTF208.

In one embodiment, the Ethernet packet is received at the ECATTF208. The ECATTF determines (see block512) the first slave UE device404,408that receives the Ethernet packet based on configuration information received in step 1 or based on the target device address in the ethernet frame.

In one embodiment, the ECATTF208determines (see block514) what EtherCAT datagrams from the ethernet packet received in step 2 are assigned or intended for a target slave UE device404,408based on configuration information received in step 1. In the depicted procedure flow500, for example, the ECATTF208may determine from the configuration information that EtherCAT datagram1should be transmitted to slave UE device1408.

In one embodiment, the ECATTF208constructs an Ethernet packet containing the required datagrams (e.g., datagram1) and sends (see messaging516) it to slave UE device1408. The Ethernet packet may be sent via a PDU session via a QoS flow with specific QoS rules. The UPF may be configured for routing the Ethernet packet via a specific QoS flow. Datagrams that are not needed by slave UE device1408may be buffered at the ECATTF208. The Ethernet packet is transmitted by the gNB to the slave UE devices404,408according the TSC assistance information received from the SMF145(which may have been provided to the SMF145by the EDCM204). In one embodiment, the RAN115transmits (see messaging518) the Ethernet packet via Uu to slave UE device1408considering TSC assistance information provided by the SMF145.

In further embodiments, referring toFIG.5B, salve UE device1408processes (see block520) the EtherCAT datagrams according to the received configuration information. Slave UE device1408may add additional information within the EtherCAT datagrams and may determine the next, subsequent, following, or the like slave UE device, e.g., slave UE device2404, within the topology to receive the next Ethernet pack of datagrams.

In one embodiment, slave UE device1408constructs an ethernet packet and includes all datagrams processed in step 6 (existing or modified) and sends (see messaging522) the Ethernet packet to the RAN115, e.g., directly to the second EtherCAT slave UE device404(in the topology) or sends (see messaging524) the Ethernet packet to the ECATTF208based on the configuration information received in step 1.

In one embodiment, the Ethernet packet is received by the ECATTF. The ECATTF208determines (see block526) the second slave UE device404that requires the Ethernet packet and also determines the EtherCAT datagrams required by the second device, based on the configuration information. The ECATTF208may determine the next slave UE device404based on the topology configuration received from the EDCM204or based on the destination address in the Ethernet packet sent by the previous slave UE device408. In the depicted procedure flow500, for example, slave UE device2404may require information included in datagram2.

In one embodiment, steps 6-10 are repeated for slave UE device2404, and other slave UE devices within the topology (see block528). In some embodiments, if there are no more slave UE devices404,408in the topology, the ECATTF208constructs (see messaging530) an Ethernet packet containing all the datagrams, either originally sent or modified, and sends (see messaging532) the Ethernet packet to the EtherCAT master206. In certain embodiments, the ECATTF208provides all EtherCAT datagrams that were included by the EtherCAT master206in step 2, which may have been modified by the slave UE devices404,408within the topology.

FIG.6depicts a user equipment apparatus600that may be used for ethernet-based fieldbus packet exchange within a mobile wireless communication network, according to embodiments of the disclosure. In various embodiments, the user equipment apparatus600is used to implement one or more of the solutions described above. The user equipment apparatus600may be one embodiment of the remote unit105and/or the UE205, described above. Furthermore, the user equipment apparatus600may include a processor605, a memory610, an input device615, an output device620, and a transceiver625.

In some embodiments, the input device615and the output device620are combined into a single device, such as a touchscreen. In certain embodiments, the user equipment apparatus600may not include any input device615and/or output device620. In various embodiments, the user equipment apparatus600may include one or more of: the processor605, the memory610, and the transceiver625, and may not include the input device615and/or the output device620.

As depicted, the transceiver625includes at least one transmitter630and at least one receiver635. In some embodiments, the transceiver625communicates with one or more cells (or wireless coverage areas) supported by one or more base units121. In various embodiments, the transceiver625is operable on unlicensed spectrum. Moreover, the transceiver625may include multiple UE panel supporting one or more beams. Additionally, the transceiver625may support at least one network interface640and/or application interface645. The application interface(s)645may support one or more APIs. The network interface(s)640may support 3GPP reference points, such as Uu, N1, PC5, etc. Other network interfaces640may be supported, as understood by one of ordinary skill in the art.

The processor605, in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor605may be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor605executes instructions stored in the memory610to perform the methods and routines described herein. The processor605is communicatively coupled to the memory610, the input device615, the output device620, and the transceiver625. In certain embodiments, the processor605may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio functions.

In various embodiments, the processor605controls the user equipment apparatus600to implement the above described UE behaviors such as processing commands, instructions, data, and/or the like contained within the datagrams in the Ethernet packets that are received from the control entity.

The memory610, in one embodiment, is a computer readable storage medium. In some embodiments, the memory610includes volatile computer storage media. For example, the memory610may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). In some embodiments, the memory610includes non-volatile computer storage media. For example, the memory610may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory610includes both volatile and non-volatile computer storage media.

In some embodiments, the memory610stores data related to ethernet-based fieldbus packet exchange within a mobile wireless communication network. For example, the memory610may store various parameters, resource assignments, policies, and the like as it relates to processing the Ethernet datagrams, as described above. In certain embodiments, the memory610also stores program code and related data, such as an operating system or other controller algorithms operating on the user equipment apparatus600.

The input device615, in one embodiment, may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device615may be integrated with the output device620, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, the input device615includes a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. In some embodiments, the input device615includes two or more different devices, such as a keyboard and a touch panel.

In certain embodiments, the output device620includes one or more speakers for producing sound. For example, the output device620may produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device620includes one or more haptic devices for producing vibrations, motion, or other haptic feedback. In some embodiments, all, or portions of the output device620may be integrated with the input device615. For example, the input device615and output device620may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device620may be located near the input device615.

The transceiver625communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver625operates under the control of the processor605to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor605may selectively activate the transceiver625(or portions thereof) at particular times in order to send and receive messages.

The transceiver625includes at least transmitter630and at least one receiver635. One or more transmitters630may be used to provide UL communication signals to a base unit121, such as the UL transmissions described herein. Similarly, one or more receivers635may be used to receive DL communication signals from the base unit121, as described herein. Although only one transmitter630and one receiver635are illustrated, the user equipment apparatus600may have any suitable number of transmitters630and receivers635. Further, the transmitter(s)630and the receiver(s)635may be any suitable type of transmitters and receivers. In one embodiment, the transceiver625includes a first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and a second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum.

In certain embodiments, the first transmitter/receiver pair used to communicate with a mobile communication network over licensed radio spectrum and the second transmitter/receiver pair used to communicate with a mobile communication network over unlicensed radio spectrum may be combined into a single transceiver unit, for example a single chip performing functions for use with both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter/receiver pair and the second transmitter/receiver pair may share one or more hardware components. For example, certain transceivers625, transmitters630, and receivers635may be implemented as physically separate components that access a shared hardware resource and/or software resource, such as for example, the network interface640.

In various embodiments, one or more transmitters630and/or one or more receivers635may be implemented and/or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other type of hardware component. In certain embodiments, one or more transmitters630and/or one or more receivers635may be implemented and/or integrated into a multi-chip module. In some embodiments, other components such as the network interface640or other hardware components/circuits may be integrated with any number of transmitters630and/or receivers635into a single chip. In such embodiment, the transmitters630and receivers635may be logically configured as a transceiver625that uses one more common control signals or as modular transmitters630and receivers635implemented in the same hardware chip or in a multi-chip module.

FIG.7depicts a network apparatus700that may be used for ethernet-based fieldbus packet exchange within a mobile wireless communication network, according to embodiments of the disclosure. In one embodiment, network apparatus700may be one implementation of a RAN node, such as the base unit121, the RAN node210, or gNB, described above, a configuration management node (e.g., an EDCM), a control node (e.g., an EtherCAT master node), a translation node (e.g., an ECATTF), and/or the like. Furthermore, the base network apparatus700may include a processor705, a memory710, an input device715, an output device720, and a transceiver725.

In some embodiments, the input device715and the output device720are combined into a single device, such as a touchscreen. In certain embodiments, the network apparatus700may not include any input device715and/or output device720. In various embodiments, the network apparatus700may include one or more of: the processor705, the memory710, and the transceiver725, and may not include the input device715and/or the output device720.

As depicted, the transceiver725includes at least one transmitter730and at least one receiver735. Here, the transceiver725communicates with one or more remote units105. Additionally, the transceiver725may support at least one network interface740and/or application interface745. The application interface(s)745may support one or more APIs. The network interface(s)740may support 3GPP reference points, such as Uu, N1, N2 and N3. Other network interfaces740may be supported, as understood by one of ordinary skill in the art.

The processor705, in one embodiment, may include any known controller capable of executing computer-readable instructions and/or capable of performing logical operations. For example, the processor705may be a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or similar programmable controller. In some embodiments, the processor705executes instructions stored in the memory710to perform the methods and routines described herein. The processor705is communicatively coupled to the memory710, the input device715, the output device720, and the transceiver725. In certain embodiments, the processor705may include an application processor (also known as “main processor”) which manages application-domain and operating system (“OS”) functions and a baseband processor (also known as “baseband radio processor”) which manages radio function.

In various embodiments, the network apparatus700is a configuration node for ethernet-based fieldbus packet exchange, a translation function for ethernet-based fieldbus packet exchange, and/or a control node for ethernet-based fieldbus packet exchange, as described above. In such embodiments, the processor705may determine configuration information that comprises a mapping defining which datagrams of a packet each of a plurality of user equipment (“UE”) devices within a mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the processor705may receive a packet comprising a plurality of datagrams from a first node in an ethernet-based fieldbus system. In one embodiment, the processor705may determine which datagrams of the plurality of datagrams are for each UE device according to the configuration information. In one embodiment, the processor705may send to each UE device within the mobile wireless communication network, in order of the sequence defined by the configuration information, a packet comprising the datagrams for the UE device.

In one embodiment, the processor705may receive the configuration information from a configuration entity of the ethernet-based fieldbus system. In one embodiment, the processor705may determine, based on the configuration information, whether a datagram that is sent to a UE device comprises an originally-received datagram or a datagram that is modified by a previous UE in the sequence. In one embodiment, the processor705may determine time sensitive communications assistance information for each UE device based on the datagrams for each UE device and a quality of service.

In one embodiment, the processor705may construct and send, via the transceiver725, a packet comprising datagrams to a first node in response to the sequence being complete. In one embodiment, the processor705may construct the packet comprising the datagrams for the UE device by modifying a packet frame header to provide information for the UE device on how to read each datagram. In one embodiment, the processor705may construct the packet comprising the datagrams for the UE device by inserting the datagrams in a frame of the packet in a same position as structured by the received packet comprising the plurality of datagrams.

In one embodiment, the processor705receives, via the transceiver725, a request to manage configuration of the ethernet-based fieldbus system session, the request based on a communication time threshold for a packet to be transmitted and received by the control entity.

In one embodiment, the processor705determines a configuration for the ethernet-based fieldbus system session that satisfies the communication time threshold. The configuration comprising a mapping describing which datagrams each of a plurality of user equipment (“UE”) devices within the mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the processor705transmits, via the transceiver725, the determined configuration to the ethernet-based fieldbus system translator function within the mobile wireless communication network for implementation of the configuration for the ethernet-based fieldbus system session.

In one embodiment, the processor705receives, via the transceiver725, configuration information from the control entity comprising a configuration for the mapping. The mapping configuration comprising at least one of a physical address for each UE device, a mapping of the physical address to a logical address for each UE device, a media access control address for each UE device, an internet protocol address for each UE device, topological information, and port management policies.

In one embodiment, the processor705determines time sensitive communications assistance information for each UE device based on the datagrams for each UE and a quality of service.

The memory710, in one embodiment, is a computer readable storage medium. In some embodiments, the memory710includes volatile computer storage media. For example, the memory710may include a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and/or static RAM (“SRAM”). In some embodiments, the memory710includes non-volatile computer storage media. For example, the memory710may include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory710includes both volatile and non-volatile computer storage media.

In some embodiments, the memory710stores data related to ethernet-based fieldbus packet exchange within a mobile wireless communication network. For example, the memory710may store parameters, configurations, resource assignments, policies, and the like, as described above. In certain embodiments, the memory710also stores program code and related data, such as an operating system or other controller algorithms operating on the network apparatus700.

The input device715, in one embodiment, may include any known computer input device including a touch panel, a button, a keyboard, a stylus, a microphone, or the like. In some embodiments, the input device715may be integrated with the output device720, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, the input device715includes a touchscreen such that text may be input using a virtual keyboard displayed on the touchscreen and/or by handwriting on the touchscreen. In some embodiments, the input device715includes two or more different devices, such as a keyboard and a touch panel.

In certain embodiments, the output device720includes one or more speakers for producing sound. For example, the output device720may produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device720includes one or more haptic devices for producing vibrations, motion, or other haptic feedback. In some embodiments, all, or portions of the output device720may be integrated with the input device715. For example, the input device715and output device720may form a touchscreen or similar touch-sensitive display. In other embodiments, the output device720may be located near the input device715.

The transceiver725includes at least transmitter730and at least one receiver735. One or more transmitters730may be used to communicate with the UE, as described herein. Similarly, one or more receivers735may be used to communicate with network functions in the NPN, PLMN and/or RAN, as described herein. Although only one transmitter730and one receiver735are illustrated, the network apparatus700may have any suitable number of transmitters730and receivers735. Further, the transmitter(s)730and the receiver(s)735may be any suitable type of transmitters and receivers.

FIG.8is a flowchart diagram of a method800for ethernet-based fieldbus packet exchange within a mobile wireless communication network. The method800may be performed by a network apparatus700as described herein. In some embodiments, the method800may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the method800includes determining805configuration information that comprises a mapping defining which datagrams of a packet each of a plurality of user equipment (“UE”) devices within a mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the method800includes receiving810a packet comprising a plurality of datagrams from a first node in an ethernet-based fieldbus system. In one embodiment, the method800includes determining815which datagrams of the plurality of datagrams are for each UE device according to the configuration information. In one embodiment, the method800includes sending820to each UE device within the mobile wireless communication network, in order of the sequence defined by the configuration information, a packet comprising the datagrams for the UE device. The method800ends.

FIG.9is a flowchart diagram of a method900for ethernet-based fieldbus packet exchange within a mobile wireless communication network. The method900may be performed by a network apparatus700as described herein. In some embodiments, the method900may be performed by a processor executing program code, for example, a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

In one embodiment, the method900includes receiving905a request to manage configuration of an ethernet-based fieldbus system session, the request based on a communication time threshold for a packet to be transmitted and received by a control entity.

In one embodiment, the method900includes determining910a configuration for the ethernet-based fieldbus system session that satisfies the communication time threshold. The configuration may include a mapping describing which datagrams each of a plurality of user equipment (“UE”) devices within a mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the method900includes transmitting915the determined configuration to an ethernet-based fieldbus system translator function within the mobile wireless communication network for implementation of the configuration for the ethernet-based fieldbus system session. The method900ends.

In one embodiment, a first apparatus is disclosed for ethernet-based fieldbus packet exchange within a mobile wireless communication network that includes a transceiver that is in communication with a first node in an ethernet-based fieldbus system and is in communication with a plurality of user equipment (“UE”) devices via a mobile wireless communication network. In one embodiment, the first apparatus includes a processor that determines configuration information that comprises a mapping defining which datagrams of a packet each of the plurality of UE devices within the mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the processor further receives, via a transceiver, from the first node in the ethernet-based fieldbus system, a packet comprising a plurality of datagrams. In one embodiment, the processor further determines which datagrams of the plurality of datagrams are for each UE device according to the configuration information. In one embodiment, the processor further sends, via the transceiver, to each UE device within the mobile wireless communication network, in order of the sequence defined by the configuration information, a packet comprising the datagrams for the UE device.

In one embodiment, the processor further receives the configuration information from a configuration entity of the ethernet-based fieldbus system. In one embodiment, the configuration information is received from the configuration entity of the ethernet-based fieldbus system in response to a communication time satisfying a threshold communication time.

In one embodiment, each of the UE devices is configured with the configuration information from a configuration entity of the ethernet-based fieldbus system. In one embodiment, the processor further determines, based on the configuration information, whether a datagram that is sent to a UE device comprises an originally-received datagram or a datagram that is modified by a previous UE in the sequence.

In one embodiment, the processor further determines time sensitive communications assistance information for each UE device based on the datagrams for each UE device and a quality of service. In one embodiment, the processor further constructs and sends, via the transceiver, a packet comprising datagrams to a master first node in response to the sequence being complete.

In one embodiment, the processor further constructs the packet comprising the datagrams for the UE device by modifying a packet frame header to provide information for the UE device on how to read each datagram. In one embodiment, the processor further constructs the packet comprising the datagrams for the UE device by inserting the datagrams in a frame of the packet in a same position as structured by the received packet comprising the plurality of datagrams.

In one embodiment, the datagrams are formatted according to an industrial network protocol for the ethernet-based fieldbus system. In one embodiment, the datagrams are formatted according to an ethernet for control automation technology (“EtherCAT”) industrial network protocol.

In one embodiment, a first method is disclosed for ethernet-based fieldbus packet exchange within a mobile wireless communication network that includes determining configuration information that comprises a mapping defining which datagrams of a packet each of a plurality of user equipment (“UE”) devices within a mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the method includes receiving a packet comprising a plurality of datagrams from a first node in an ethernet-based fieldbus system. In one embodiment, the method includes determining which datagrams of the plurality of datagrams are for each UE device according to the configuration information. In one embodiment, the method includes sending to each UE device within the mobile wireless communication network, in order of the sequence defined by the configuration information, a packet comprising the datagrams for the UE device.

In one embodiment, the method includes receiving the configuration information from a configuration entity of the ethernet-based fieldbus system. In one embodiment, the configuration information is received from the configuration entity of the ethernet-based fieldbus system in response to a communication time satisfying a threshold communication time.

In one embodiment, each of the UE devices is configured with the configuration information from a configuration entity of the ethernet-based fieldbus system. In one embodiment, the method includes determining, based on the configuration information, whether a datagram that is sent to a UE device comprises an originally-received datagram or a datagram that is modified by a previous UE in the sequence.

In one embodiment, the method includes determining time sensitive communications assistance information for each UE device based on the datagrams for each UE device and a quality of service. In one embodiment, the method includes constructing and sending a packet comprising datagrams to a master first node in response to the sequence being complete.

In one embodiment, the method includes constructing the packet comprising the datagrams for the UE device by modifying a packet frame header to provide information for the UE device on how to read each datagram. In one embodiment, the method includes constructing the packet comprising the datagrams for the UE device by inserting the datagrams in a frame of the packet in a same position as structured by the received packet comprising the plurality of datagrams.

In one embodiment, the datagrams are formatted according to an industrial network protocol for the ethernet-based fieldbus system. In one embodiment, the datagrams are formatted according to an ethernet for control automation technology (“EtherCAT”) industrial network protocol.

A second apparatus is disclosed for ethernet-based fieldbus packet exchange within a mobile wireless communication network. In one embodiment, the apparatus includes a transceiver that is in communication with a control entity of an ethernet-based fieldbus system and is in communication with an ethernet-based fieldbus system translator function within a mobile wireless communication network.

In one embodiment, the apparatus includes a processor that receives, via the transceiver, a request to manage configuration of the ethernet-based fieldbus system session, the request based on a communication time threshold for a packet to be transmitted and received by the control entity. In one embodiment, the processor further determines a configuration for the ethernet-based fieldbus system session that satisfies the communication time threshold. The configuration includes a mapping describing which datagrams each of a plurality of user equipment (“UE”) devices within the mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the processor transmits, via the transceiver, the determined configuration to the ethernet-based fieldbus system translator function within the mobile wireless communication network for implementation of the configuration for the ethernet-based fieldbus system session.

In one embodiment, the request further comprises at least one of a type of management, a time validity, and a geographical area for which the request applies. In one embodiment, the type of management comprises at least one of providing the datagram mapping to UE configuration, supporting identity management of the UE devices in relation to the mobile wireless communication network, configuring application quality of service parameters, and configuring a topology including the sequence of transmissions from each UE device.

In one embodiment, the processor further receives, via the transceiver, configuration information from the control entity comprising a configuration for the mapping. The mapping configuration includes at least one of a physical address for each UE device, a mapping of the physical address to a logical address for each UE device, a media access control address for each UE device, an internet protocol address for each UE device, topological information, and port management policies.

In one embodiment, the configuration further comprises quality of service requirements per quality of service flow for at least one of an end-to-end quality of service flow and a quality of service flow for each connection between UE devices involved in the sequence. In one embodiment, the configuration further comprises a mapping of a session identity for the ethernet-based fieldbus system to one or more UE device identities in relation to the mobile wireless communication network.

In one embodiment, the sequence in which each UE device receives the datagrams comprises at least one application traffic triggering policy that defines when each UE device is triggered to send packets to a next device in the sequence. In one embodiment, the processor further determines time sensitive communications assistance information for each UE device based on the datagrams for each UE and a quality of service. In one embodiment, the time sensitive communications assistance information comprises a survival time configuration that determines whether a survival timer is applicable to a UE device.

A second method is disclosed for ethernet-based fieldbus packet exchange within a mobile wireless communication network. In one embodiment, the method includes receiving a request to manage configuration of the ethernet-based fieldbus system session, the request based on a communication time threshold for a packet to be transmitted and received by the control entity. In one embodiment, the method includes determining a configuration for the ethernet-based fieldbus system session that satisfies the communication time threshold. The configuration includes a mapping describing which datagrams each of a plurality of user equipment (“UE”) devices within the mobile wireless communication network receives and a sequence in which each UE device receives the datagrams.

In one embodiment, the method includes transmitting the determined configuration to the ethernet-based fieldbus system translator function within the mobile wireless communication network for implementation of the configuration for the ethernet-based fieldbus system session.

In one embodiment, the request further comprises at least one of a type of management, a time validity, and a geographical area for which the request applies. In one embodiment, the type of management comprises at least one of providing the datagram mapping to UE configuration, supporting identity management of the UE devices in relation to the mobile wireless communication network, configuring application quality of service parameters, and configuring a topology including the sequence of transmissions from each UE device.

In one embodiment, the method includes receiving configuration information from the control entity comprising a configuration for the mapping. The mapping configuration includes at least one of a physical address for each UE device, a mapping of the physical address to a logical address for each UE device, a media access control address for each UE device, an internet protocol address for each UE device, topological information, and port management policies.

In one embodiment, the configuration further comprises quality of service requirements per quality of service flow for at least one of an end-to-end quality of service flow and a quality of service flow for each connection between UE devices involved in the sequence. In one embodiment, the configuration further comprises a mapping of a session identity for the ethernet-based fieldbus system to one or more UE device identities in relation to the mobile wireless communication network.

In one embodiment, the sequence in which each UE device receives the datagrams comprises at least one application traffic triggering policy that defines when each UE device is triggered to send packets to a next device in the sequence. In one embodiment, the method includes determining time sensitive communications assistance information for each UE device based on the datagrams for each UE and a quality of service. In one embodiment, the time sensitive communications assistance information comprises a survival time configuration that determines whether a survival timer is applicable to a UE device.