WO2021136636A1 - Grouping qos flow for user equipment to user equipment communications - Google Patents

Grouping qos flow for user equipment to user equipment communications Download PDF

Info

Publication number
WO2021136636A1
WO2021136636A1 PCT/EP2020/085242 EP2020085242W WO2021136636A1 WO 2021136636 A1 WO2021136636 A1 WO 2021136636A1 EP 2020085242 W EP2020085242 W EP 2020085242W WO 2021136636 A1 WO2021136636 A1 WO 2021136636A1
Authority
WO
WIPO (PCT)
Prior art keywords
flow
user equipment
flows
qos
communications
Prior art date
Application number
PCT/EP2020/085242
Other languages
French (fr)
Inventor
Pilar ANDRÉS MALDONADO
Troels Emil Kolding
Peter Rost
Devaki Chandramouli
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of WO2021136636A1 publication Critical patent/WO2021136636A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0252Traffic management, e.g. flow control or congestion control per individual bearer or channel
    • H04W28/0263Traffic management, e.g. flow control or congestion control per individual bearer or channel involving mapping traffic to individual bearers or channels, e.g. traffic flow template [TFT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0268Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]

Definitions

  • Time sensitive networks may be used to support a variety of applications including applications such as ultra-reliable low-latency communications (URLLC), industrial verticals, and/or the like.
  • applications such as ultra-reliable low-latency communications (URLLC), industrial verticals, and/or the like.
  • URLLC ultra-reliable low-latency communications
  • industrial verticals and other mission critical applications there may be some requirements that are relatively unique, such as certain requirements for low latency, deterministic data transmission, and high reliability, when compared to other 5G cellular services.
  • an apparatus configured to at least group two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment.
  • the apparatus may be further caused to at least detect that the first flow and the second flow can be grouped based on at least the two flows carrying data from between the first user equipment and the second user equipment via the cellular network.
  • the apparatus may be further caused to at least detect that the first flow and the second flow can be grouped based on at least one or more packet filters of the first flow and/or the second flow.
  • the one or more packet filters may include one or more of the following: a source MAC address, a destination MAC address, a source IP address, and a destination IP address.
  • the grouping may include merging the first flow and the second flow into a single flow, wherein the merging includes modifying one or more session parameters associated with the first flow and/or the second flow to enable the single flow.
  • the grouping may include linking the first flow and the second flow as a group, wherein the linking is indicated by an identifier.
  • the grouped first and second flows may share a packet forwarding control protocol session.
  • the apparatus may be caused to receive a request for communications between the first user equipment and the second user equipment.
  • the grouping may be triggered by the received request.
  • the apparatus may be further caused to at least configure the first flow and the second flow based on at least one or more end-to-end quality of service requirements.
  • FIGs. 1 A depicts an example of UE to UE communications, in accordance with some example embodiments
  • FIG. IB depicts an example of a process for grouping QoS flows of UE-UE communications, in accordance with some example embodiments.
  • FIG. 1C depicts an example of grouping based on group-level flow definitions, in accordance with some example embodiments.
  • FIG. ID depicts an example of grouping based on merging flow definitions, in accordance with some example embodiments.
  • FIG. 2 A depicts an example of a portion of a time sensitive network, in accordance example embodiments.
  • FIG. 2B depicts an example of a 3 GPP bridge for a time sensitive network, in accordance with some example embodiments;
  • FIG. 3 depicts an example of a shared session, in accordance with some example embodiments.
  • FIG. 4 depicts an example of a process flow for UE-UE communications based on grouped QoS flows session, in accordance with some example embodiments
  • FIG. 5 depicts an example of a network node, in accordance with some example embodiments.
  • FIG. 6 depicts an example of an apparatus, in accordance with some example embodiments.
  • Some Time Sensitive Communications (TSC) use cases may involve communications between machines, such as between user equipment (UE) located in the 5G network.
  • UE user equipment
  • 3GPP TS 22.104 a few application areas, such as within factories and the like, may be optimized for UE to UE (UE-UE) communications to provide improved service, end-to-end latency, maintainability, and flexibility.
  • control communications between UEs may provide optimized TSC between individual components (or functions) of a larger machine (e.g., the components of the larger machine may operate via UE-UE communications in a TSC manner).
  • the UE-UE communications may be used to coordinate individual machines (which include UEs) when performing a task.
  • These machines may be synchronized and exchange real-time (or near real-time) information. Moreover, these machines may not have a fixed configuration (e.g., as control nodes their configuration may vary as the status of the corresponding machine changes).
  • the UE-UE communications disclosed herein refers to communications, such as TSC or other traffic types having demands for low latency and/or high reliability, via the cellular network, rather than device-to-device (D2D) communications directly between the UEs.
  • D2D device-to-device
  • the TSC may be used in other environments, such as in the audio industry, the video industry, and the like.
  • the flows may transmit audio and/or video to a limited geographic area (e.g., a live concert) and/or wider areas (e.g., a concert broadcasting).
  • a limited geographic area e.g., a live concert
  • wider areas e.g., a concert broadcasting
  • the radio conditions at each of the UEs may differ significantly. And, these conditions at each UE may be dynamic in the sense that the conditions may change from time to time. For example, the UEs may be mobile or may encounter different obstructions and the like (e.g., different structures such as walls or obstacles within a factory may cause radio or RF obstructions). As such, the radio conditions for the two UEs may be not be the same, such as asymmetric.
  • a cellular network such as 5G as shown at FIG.
  • the cellular network may consider the quality of service (QoS) requirements, and may then establish two independent, new QoS flows between each of the UEs 102A-B and a corresponding user plane function (UPF) 115 via a base station such as a 5G gNB type base station 110A.
  • QoS quality of service
  • UPF user plane function
  • FIG. 1 A depicts the UE-UE communications link including the first leg 105 and the second leg 107 via a single base station 110 A, the UE-UE communications link may be via two base stations as well as.
  • the UE-UE communications link includes a first leg 105 including communication links 105A-B and a second leg 107 including communication links 107A-B.
  • the first leg 105 may include a radio link 105 A (which may include an uplink (and/or a downlink) via data radio bearer(s), DRBs) from the UE 102A and gNB 110A and a tunnel, such as a GTP-U tunnel 105B (GPRS tunneling protocol -user plane tunnel(s)) between the gNB 110A and UPF 115.
  • a radio link 105 A which may include an uplink (and/or a downlink) via data radio bearer(s), DRBs
  • a tunnel such as a GTP-U tunnel 105B (GPRS tunneling protocol -user plane tunnel(s)) between the gNB 110A and UPF 115.
  • GTP-U tunnel 105B GPRS tunneling protocol -user plane tunnel(s)
  • the second leg 107 may include a radio link 107 A (which may include a downlink (and/or an uplink) via DRBs) from the UE 102B and gNB 110A and a tunnel, such as a GTP-U tunnel 107B between the gNB 110A and UPF 115.
  • a radio link 107 A (which may include a downlink (and/or an uplink) via DRBs) from the UE 102B and gNB 110A and a tunnel, such as a GTP-U tunnel 107B between the gNB 110A and UPF 115.
  • the cellular network may configure both QoS flows (for both legs 105 and 107) to satisfy a maximum delay of 2 milliseconds (ms) for each leg 105 and 107 as there is no current mechanism in the cellular network to jointly consider the radio conditions of both UEs 102A-B to support this maximum delay requirement or other QoS parameters.
  • the cellular network needs a way to link these two legs for UE-UE communications, so that if the radio conditions does change at, for example, UE 102A and first leg 105, the network can jointly consider the change and perhaps make adjustments to UE 102B and the second leg 107.
  • the cellular network may, in accordance with some example embodiments, modify the session for UE 102B so that the latency is 1 millisecond.
  • UE-UE communications via the cellular system or network, such as the 5G system, such that when the data is forwarded through the 5G system the QoS flows are grouped for the user-plane traffic of the UE-UE communications between, for example, UE 102 A and UE 102B.
  • knowledge of the UE-UE communications may be used to optimize QoS in such a way that the QoS parameters are chosen and established for the whole UE-UE communication link (or whole path including legs 105 and 107) from UE 102 A and UE 102B, and not just for each of the independent QoS flows.
  • the QoS parameters may be configured at the time the QoS flow is established (or reconfigured upon mobility or other event of one or both the UE(s)) for the entire UE-UE communications link between the EEs 102A-B, for example. This may allow the QoS flow to be optimized irrespective of whether the delay estimated for both the EEs 102A-B is symmetric or asymmetric.
  • Symmetric delay implies that the delay incurred over the air and backhaul is the same for both the EEs 102A-B.
  • asymmetric delay implies that the delay incurred over and air and backhaul are different for both the EEs 102A-B.
  • the 5G core network may detect that the requested QoS flows are dedicated to the EE-EE communications between EE 102A-B. This detection may be based on the packet filters within the QoS rules requested. For example, the detection of the first flow and the second flow may be based on the packet filters of the first and second flows.
  • the packet filter for an IP PDU session may include one or more of the following: the source IP address(or IPv6 prefix), the destination IP address (or IPv6 prefix), the source port number, the destination port number, protocol ID of the protocol above IP/Next header type, type of service/ traffic class and mask, flow label, security parameter index, and packet filter direction.
  • the packet filter for an Ethernet PDU session may include one or more of the following: the source MAC address, the destination MAC address, customer- VLAN tag and/or service- VLAN tag VID fields as defined in IEEE 802. IQ, customer- VLAN tag (C-TAG) and/or service- VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE 802. IQ, IP packet filter set, and packet filter direction.
  • the contents of the packet filters may be used to determine source UE and destination UE based on source and destination IP addresses included in the packet filters, source and destination MAC addresses included in the packet filters, protocol IDs, and the like.
  • the UE-UE communications may apply for a subset of the QoS flows within a PDU session, or may apply to all the QoS flows within the PDU session (in which case, the PDU session is a special case of the PDU session for the UE-UE communications).
  • the 5G core network may use the knowledge of the end point UEs 102A-B, the TSC traffic characteristics, and the QoS requirements for the entire UE-UE communications path (e.g., legs 105-107 between EE 102A-B) to establish a grouped QoS flow for the two EEs in EE-EE communications, in accordance with some example embodiments.
  • a trigger for grouping QoS flows for the EE-EE communications may be a node, such as a core network node, receiving forwarding information (e.g., EE 102A-B as end points that want to communicate) from another network node (e.g., new information available at the session management function (SMF) or policy control function (PCF) from the AF).
  • EE uplink
  • PCF policy control function
  • a trigger for grouping QoS flows for EE-EE communication may be a node, such as a core network node, receiving a request or indication that is indicative of a UE requesting a new QoS flow for EE-EE communications.
  • FIG. IB depicts an example of a process for grouping QoS flows of EE-EE communications, in accordance with some example embodiments.
  • each EE such as EE 102A and EE 102B, may request a flow, such as a QoS flow via a message, such as a PDU session establishment (or modification) procedure.
  • the requested QoS flow may have a certain configuration (or identifier) to identify that the QoS flow is for the EE-EE communications type of traffic.
  • the destination address e.g., of the destination EE 102B
  • the QoS rule (or filter) of the QoS flow may indicate that the QoS flow is for the EE-EE communications traffic type between UE 102A and UE 102B.
  • a node such as a 5G core network node, may configure a QoS flow for each of the EEs in EE-EE communications.
  • the node may configure, for EE 102 A, a first QoS flow for the first leg 105 and may configure, for the UE 102B, a second QoS flow for the second leg 107.
  • a node such as a 5G core network node, may detect that both QoS flows can be grouped because the QoS flows are for UE-UE communications between UE 102 A and UE 102B.
  • the node may detect that first QoS flow over leg 105 and the second QoS flow (over the second leg 107) may be grouped since both the first and second QoS flows depend on one another for UE-UE communications between UE 102 A and UE 102B.
  • the SMF may determine (e.g., by correlating) the requests, so the detection that the QoS flows can be grouped may be done based on the combination of information within the QoS rules (or filters) requested for each UE (e.g., traffic source/destination) or based on information received from the AF (e.g. the configuration of a virtual network group).
  • the QoS rules or filters
  • a node such as a 5G core network node, may group the QoS flows and reconfigure the user plane based on the end-to-end QoS requirements for the UE-UE communications. For example, the first QoS flow via leg 105 may be grouped with the second QoS flow via leg 107. This grouping enables the node to coordinate the grouped QoS flows management for the UE-UE communications link type of traffic.
  • the QoS flow grouping is further described below with respect to FIGs. 1C and ID.
  • the first QoS flow and the second QoS flow carry user-plane traffic end-to-end between UEs 102A-B, which are in UE-UE communications (which may be TSC type traffic or other types of low delay and/or high reliability traffic).
  • UE-UE communications which may be TSC type traffic or other types of low delay and/or high reliability traffic.
  • a changed of the conditions affecting the first QoS flow or the first UE 102 A may be considered jointly with the second QoS flow or the second UE 102B.
  • the network may modify the configuration of the second QoS flow to provide a 1 ms delay in order to maintain a 4 ms packet delay budget, for example.
  • the grouping of the QoS flows such as the QoS flows being carried over leg 105 and 107, for UE-UE communications enables establishment, modification, and/or release based on the conditions, such as connectivity conditions at both UEs 102A-B, jointly.
  • the cellular network may, in accordance with some example embodiments, modify the session for UE 102B so that the latency is 1 millisecond.
  • FIG. 1C depicts UE 102A (labeled UE1) and UE 102B (labeled UE2) in UE-UE communications via a core network node, such as the UPF 115 based on grouped flows, in accordance with some example embodiments.
  • the UE 102 A and UE 102C (labeled UE3) are also in UE-UE communications via the UPF 115.
  • the two QoS flows 172 A and 172B are grouped as they provide the flows for the UE- UE communications between UE 102A and UE 102B.
  • the two QoS flows 174A and 174B are grouped as they provide the flows for the UE-UE communications between UE 102B and UE 102C.
  • the QoS flow definitions and their policies may be extended so that a new, so-called “overlay” QoS flow may be defined to enable the grouped flows.
  • the overlay QoS flow is an additional layer considered within the core network, such as the SMF, PCF, and/or other node, that groups at least two QoS flows.
  • the core network nodes such as the SMF, PCF, and the like, detect the flow grouping and configure QoS parameters or policy based on the end-end requirements of the UE-UE communications and based on the connectivity conditions at each of the UEs in UE-UE communications.
  • the group-level QoS flows are treated jointly with respect to QoS parameters and policy rather than independently.
  • the group-level QoS flows are flagged with an indication, such as an identifier for the QoS flows making up the group-level.
  • the indication such as the identifier of the group-level QoS flow, may be used among network nodes, such as the SMF, PCF, and the like, to indicate that certain QoS flows belong to the same group-level QoS flow.
  • the QoS flows joined in the same group are dependent on one another, so the reconfiguration in one leg of the user plane (e.g., QoS flow 172A between UE 102A and UPF) may impact the other leg (e.g., QoS flow 172B between UE 102B and UPF).
  • a reconfiguration in one leg of the user plane e.g., QoS flow 174A between UE1 102A and UPF
  • QoS flow 174B between UE 102C and UPF 115.
  • each leg may be configured in an asymmetric manner.
  • the configuration of one leg of the user plane may be different from the other leg (e.g., QoS flow 172B between UE 102B and UPF).
  • the asymmetric configuration enables QoS flow 172A to be configured to have a 1 millisecond delay while QoS flow 172B to have a 2 millisecond delay.
  • FIG. ID depicts UE 102A and UE 102B in UE-UE communications via a core network node, such as the UPF 115, based on merged flows, in accordance with some example embodiments.
  • the a network node such as a 5G core network node, may reconfigure the user- plane configuration to join both the QoS flows in a merged flow in which the configuration is shared between both UEs (e.g., the QoS requirements, charging, etc.) considering the end-to-end QoS requirements for UE-UE communications.
  • the QoS flows for each leg are replaced by a single, merged QoS flow, which is end-to-end between the UEs.
  • the merged QoS flow is treated as a single QoS flow (e.g., between UE 102A and UE 102B), rather than as two QoS flows (one between UE 102 A and the UPF and another between UE 102B and the UPF).
  • the UE 102 A views the QoS flows 182A- B as a single QoS flow, but the core network may view the QoS flows 182A-B as a shared QoS flow between two UEs 102A-B.
  • the merged flows may have symmetric configurations (e.g., the same or similar QoS parameters or policies).
  • Both grouping QoS flows techniques at FIG. 1C and ID may, from a UE perspective, may be in accordance with, for example, 3GPP TS 23.501.
  • a network node such as a 5G core network node, may obtain end-to-end QoS requirements for the UE-UE communications.
  • the node may obtain these end-to-end QoS requirements from the AF, UEs, or other nodes.
  • the UEs 102A-B (or an AF) may provide to the network node network including the 5G core network the end-to-end QoS requirements for the UE-UE communications.
  • the QoS requirements requested may be in the form of QoS related information elements but for the specific UE-UE communication, QoS flows end-to-end.
  • the grouping of QoS flows may be triggered by an event, such as receiving information, such as an indication or other information from an AF, UE, or other node.
  • the UE-UE communications may be identified in a proactive (e.g., before QoS flows are established) or a reactive manner (e.g., after the QoS flows are established).
  • the UE-UE communications between UE 102A and UE 102B may be identified in a proactive manner.
  • the UE-UE communication link may be identified based on the information received from the AF and/or UE. This information may include a specific configuration of the requested QoS flows (e.g., a packet filter included in the QoS rule) or the information received from the AF (e.g., 5G virtual network configuration and end-to-end QoS requirements).
  • the UE-UE communication link may be identified based on the exchanged user plane packets between the UEs 102A-B.
  • the exchanged user plane packets between the UEs 102A-B may enable a network node such as a 5G core network node to recognize the source and destination end points as two UEs 102A-B or based on address resolution protocol requests.
  • the reactive identification may not be used to do frequent QoS parameters updates on the fly as the QoS flows should be configured in advance, but it may be used to update the TSC assistance information configuration of the QoS flows.
  • the QoS flow configuration may vary based on whether the QoS flows are grouped (as described above with respect to FIG. 1C) or merged (as described above with respect to FIG. ID).
  • the procedures to configure both QoS flows may be extended to take into account the group-level flows and how these flows are treated at core network nodes, such as a session management function (SMF), policy control function (PCF) when configuring both, group-level QoS flows.
  • a new type of identifier may be used to point to, or indicate, the group-level QoS flow.
  • the identifier may indicate that the two QoS flows (e.g., the first QoS flow from the UE 102 A to the UPF and the second QoS flow from UE 102B to the UPF) are grouped for purposes UE-UE communications, so a change to one UE or QoS flow affects the other UE and QoS flow as well.
  • This identifier may only be needed at the SMF and PCF as the nodes, which may be responsible for configuring and/or managing the group-level QoS flow.
  • the QoS flow procedures may be extended to take into account having a shared QoS flow between two UEs.
  • the QoS flow procedures may be extended to take into account having a shared QoS flow between two UEs.
  • PDU protocol data unit
  • core network procedures it may vary based on whether the QoS flows are group-level (as described above with respect to FIG. 1C) or merged (as described above with respect to FIG. ID). With the group-level QoS flow of FIG.
  • this may enable the use of a Packet Forwarding Control Protocol (PFCP) session (established at the N4 interface between UPF and SMF) to the control of the user-plane (e.g. in terms of charging, forwarding, policies, QoS enforcement, etc.) when establishing the QoS flows.
  • PFCP Packet Forwarding Control Protocol
  • a shared PFCP session between both UEs may be provided to handle the group-level QoS flow. With the merged QoS flow of FIG. ID for example, this may also require a shared PFCP session between the two UEs involved in the UE-UE communications.
  • the merged QoS flows or group-level QoS flows may be applied in both UE- UE TSC communication based a Time Sensitive Networks (TSN) black box architecture (e.g., a 5G system as a TSN Bridge as shown at 205D at FIG. 2B) or a TSC service without the TSN Bridge.
  • TSN Time Sensitive Networks
  • the UE-UE communications technology disclosed herein Before providing additional description regarding the UE-UE communications technology disclosed herein. The following provides a description related to TSC communications, although the UE-UE communications technology disclosed herein may be used in systems, apparatus, and processes not related to TSC as well. Furthermore, although some of the examples refer to 5G, the UE-UE communications technology disclosed herein may be used with other types of systems and networks as well.
  • 3GPP wireless technologies may be applied in addition to wired time sensitive networking (TSN) to provide additional flexibility with respect to mobility and to provide scalability with respect to the quantity of sensors, actuators, and/or the like which can be supported.
  • TSN wired time sensitive networking
  • a TSN or other source of deterministic traffic may couple to a user equipment and use the 3 GPP wireless network as a bridge to enable the traffic to traverse the 3GPP network to another device or network, such as another TSN network.
  • deterministic traffic refers to predictable, such as periodic traffic, an example of which is TSN traffic, which may be in accordance with IEEE 802.1 series standards, for example.
  • FIG. 2 A depicts an example of a TSN network 200 configured in a fully centralized configuration model, although other configuration models may be implemented as well.
  • the network 200 may include a centralized user configuration (CUC) function 202, a centralized network controller (CNC) 204 function, one or more TSN bridges 205A-C, and one or more end stations 207A-F.
  • CRC centralized user configuration
  • CNC centralized network controller
  • the CUC 202 may be configured in accordance with the one or more of the IEEE 802.1 series of TSN standards.
  • the CUC may control the configuration of end stations 207A-F and/or applications at the end stations.
  • the CUC may interface with the CNC 204 to make requests to the CNC for deterministic, TSN communications (e.g., TSN flows) with specific requirements for those flows between end stations.
  • TSN flow may represent a time sensitive, deterministic stream of traffic between end stations. These TSN flows may have low delay and/or strict timing requirements for time sensitive networks.
  • a TSN flow (also referred to as a TSN stream) between end stations may, as noted, be used in an industrial control application (e.g., robot, factory machines, etc.) requiring low delay and/or strict, deterministic timing between the end stations.
  • the TSN flow may also have requirements for ultra-low reliability.
  • the CNC 204 may provide a proxy for the TSN bridges 205A-C and the corresponding interconnections, and provide a proxy for control applications that require deterministic communication.
  • the CNC may define the schedules, such as gate schedules, on which all TSN traffic is transmitted (or received) between the end stations including any intervening devices such as the TSN bridges 205A-C.
  • the schedules may define periodic transmission and/or reception.
  • the TSN bridges 205 A-C may be implemented as Ethernet switches, for example.
  • the TSN bridges are configured to transmit and/or receive TSN flows in accordance with a schedule, such as the gate schedule that gates traffic for transmission or reception.
  • the TSN flow may be in the form of Ethernet frames transmitted and/or received on the schedule to meet the low delay and/or deterministic requirements of the TSN flow.
  • the talker end station 207A may transmit traffic based on the schedule (see, e.g., IEEE 802.1Qbv) to a bridge 105 A, which may also receive and/or transmit traffic to another device based on a schedule.
  • the end stations 207A-F may be a source and/or a destination of a TSN flow.
  • the end stations may include an application, such as an industrial application or other application requiring low delay and/or other time sensitive requirement for a deterministic traffic flow.
  • the end stations may also be referred to as talkers and listeners.
  • Talker end stations refer to an end station that at a given instance is “talking,” such as transmitting in accordance with TSN, while the listener end stations refer to an end station that at a given instance is “listening.”
  • each of the end stations may include circuitry to transmit (e.g., in the case of a “talker”) and/or receive (e.g., in the case of a “listener”) using for example, Time Sensitive Network (TSN) circuitry that enables communications over a TSN network in accordance with the IEEE suite of 802.1 series of standards.
  • TSN Time Sensitive Network
  • FIG. 2B depicts an example of a TSN bridge 205D, in accordance with some example embodiments.
  • the TSN bridge 205D is also referred to herein as a 3GPP bridge 205D (or 5G system (5GS) bridge) as the 3GPP bridge 205D is implemented as part of the cellular wireless system, such as the 5G system or other type of cellular or wireless system.
  • 5GS 5G system
  • each of the UEs 102A and 102B may comprise, or be comprised in, UE 264 to enable the TSC.
  • FIG. 1 A-B each of the UEs 102A and 102B may comprise, or be comprised in, UE 264 to enable the TSC.
  • the TSN system 288 A may comprise the end station 207 A, which may access the 3 GPP bridge 205D via for example a wired connection to a user equipment (UE) 264 and a device side (DS) TSN translator (TT) 262.
  • the user equipment 264 may establish a connection with a user plane function (UPF) 282 (which also includes a network side (NW) TT) via a radio access network (RAN) 270, such as a 5G gNB or other type of base station.
  • the UPF 282 including the NW-TT 282 may provide a TSN compatible user plane data flow to TSN system 288B, which may comprise an end station, such as end station 207D for example.
  • the UE 264 and/or RAN 270 may be configured with a schedule such as a gate schedule (which may be in accordance with IEEE 802. IQbv).
  • the gate schedule defines when traffic, such as burst, can be transmitted (or received) over the link in order to satisfy the low-latency and/or deterministic needs of TSN.
  • the gate schedule may define the periodicity of the transmission and/or reception of a given device.
  • the links e.g., uplinks and/or downlinks
  • the links via the RAN represent the wireless part of the end-to-end connection between the TSN system 288A and another device or network, such as the TSN system 288B.
  • the DS-TT 262 and NW-TT 283 may translate TSN user plane data between the TSN system and the 3GPP system (e.g., via an ingress port 266A at the UE and an egress port 266B at the UPF 282.
  • FIG. 2B depicts the NW-TT 283 at the UPF 282, the NW- TT may be located at other nodes as well.
  • One or more nodes of the 3GPP bridge 205D may interface with the CUC 202 and/or CNC 204 to obtain information regarding the end station requirements for the TSN flow connection(s).
  • the AF 250 may interface to the TSN’s CUC 202 and/or CNC 204 to obtain information regarding the TSN flows between TSN systems 288A-B (e.g., end stations).
  • the 3GPP bridge 205D may include one or more radio access networks 270 (e.g., a radio access network served by a base station, gNB, eNB, and/or other nodes including core network nodes) to enable wireless connectivity for an end-to-end TSN flow between the TSN systems.
  • radio access networks 270 e.g., a radio access network served by a base station, gNB, eNB, and/or other nodes including core network nodes
  • one or more of the bridges 205 A-C may be implemented using the 3GPP bridge 205D of FIG. IB to provide TSN support over the 5G wireless system. From the perspective of the end stations 207A and D for example, the 5G system’s 3GPP bridge 205D appears like a more traditional wired TSN bridge.
  • FIG. 2B also depicts other network elements including an Access and Mobility Management Function (AMF) 272, a User Data Management (UDM) function 274, a Session Management Function (SMF) 276, a Policy Control Function (PCF) 280, a Network Exposure Function (NEF) 278, and an Application Function (AF) 250.
  • AMF Access and Mobility Management Function
  • UDM User Data Management
  • SMF Session Management Function
  • PCF Policy Control Function
  • NEF Network Exposure Function
  • AF Application Function
  • the TSN system 288B may include a corresponding UE and/or DS-TT to mirror the UE 264 and DS-TT.
  • UE 102A may comprise, or be comprised in, UE 264, while UE 102B may be similarly implemented.
  • both UEs may be configured such that they are being served by at least one of RAN 270.
  • the UEs 102 A-B may be configured as described with respect to UE 264.
  • the integration may only support a TSN fully centralized model as noted above.
  • the CUC 202 may be primarily responsible for the end stations’ configuration and application requirements management, while the CNC 204 may configure the TSN bridges using a relatively complete view of the physical topology of the network and the capabilities of each TSN bridge.
  • the 5G system may, as noted, provide one or more 3 GPP bridges of the TSN network. The granularity of each 3GPP bridge is at a per user plane function (UPF) level.
  • UPF user plane function
  • All protocol data unit (PDU) sessions (which connect to the same TSN network via a specific UPF) may be grouped into a single, logical 3GPP bridge, such as 3GPP bridge 205D.
  • PDU protocol data unit
  • the cellular system such as the 5G core network (or nodes therein), may be configured to identify the UE-UE communications based on specific configuration parameters for the QoS flows (e.g., a specific requested packet filter set within the QoS rule representative of UE-UE communications).
  • These QoS flows for UE-UE communications may comprise a subset or all the flows contained in a PDU session.
  • the specific configuration parameters may be obtained at the 5G core network node from at least two sources.
  • the AF may be a source.
  • the current set of information received for the configuration of a 5G virtual network group may be reused by adding QoS requirements needed for the UE-UE communications.
  • the UE may also be a source.
  • the parameters to configure the QoS flow for UE- UE communications may be made available to the UE in variety of ways. For example, the parameters to configure the QoS flow may be pre-configured in the UE.
  • the parameters to configure the QoS flow may be provided by an application server.
  • the parameters to configure the QoS flow may be provided by the PCF to the UE as UE Route Selection Policy (URSP) rules.
  • the parameters to configure the QoS flow may be provided by the SMF to the UE during the registration procedure or a generic UE configuration update procedure.
  • URSP UE Route Selection Policy
  • the derivation of UE-UE communications may occur at a network node, such as the SMF or the PCF.
  • the QoS flow configuration of both UEs may change to establish a group-level QoS flow (as described with respect to FIG. 1C, for example) or a merged QoS flow (as described with respect to FIG. ID, for example) considering the end-to-end QoS requirements.
  • the remaining entities in the network e.g., UE, gNB, AMF, and the like
  • the SMF or PCF may receive the configuration and set up the user-plane connectivity per 3GPP TS 23.501, but the UPF behavior may be different if the PFCP session is shared between two UEs.
  • the UPF may report user plane management information to the SMF associated with two UEs or avoid the use of the 5G virtual network internal interface for local switching when forwarding UE-UE traffic.
  • defining a merging QoS flow may include additional changes when configuring the shared QoS flow. This is due in part to both UEs having to share the PDU session and the QoS flow configuration parameters being used by the shared, merged QoS flow, so that the connectivity is compatible.
  • Table 1 summarizes some parameters that may be common between the two UEs and some parameters, which may be specific for a given UE, when a merged QoS flow is configured.
  • Table 1 PDU session parameters common and specific per UE when using merged QoS flow.
  • the UEs in UE-UE communications may share a PFCP session.
  • This shared PFCP session may be defined at the group QoS flow level (e.g., group-level QoS flow) or a merged QoS flow may have an individual PFCP session to control the packet processing at the UPF.
  • the shared PFCP session may be shared between the two UEs involved in the UE-UE communications.
  • PFCP is described, other control-plane protocols for controlling user-plane packet processing and forwarding may be used as well to handle packet detection rules, forwarding action rules, buffering action rules, QoS enforcement rules, and/or usage reporting rules.
  • FIG. 3 shows how the PFCP session may be defined for a group-level QoS flow.
  • each UE 102A-B has a PFCP session for its PDU session.
  • the PFCP session is shared between two UEs, such as UE 102A-B, and the granularity is smaller to enable control of the group-level QoS flow. Therefore, the shared PFCP session at 399 is based on two UEs in this configuration (e.g., the PDI definition or the user-plane reporting is associated with two UEs, avoiding thus the need of the two-step forwarding in 5G virtual network (via 5G virtual network internal interface at the UPF)).
  • the configuration of the shared PFCP session 399 may allow different, smaller granularities when processing the uplink (UL) and downlink (DL) flows at the UPF as the shared PFCP session can have 2 or 4 packet data detection rules (PDR for matching data packets to certain processing rules) and forwarding action rules (FARs, how packets matching PDRs should be handled including a trigger for first packet notification) to treat UL and DL traffic from both UEs 102A-B.
  • PDR packet data detection rules
  • FARs forwarding action rules
  • the shared PFCP session 399 may enable extending what the UPF considers as UL traffic and DL traffic for the usage reporting rules (URR) and QoS enforcement rules (QER) reporting in both UEs.
  • URR usage reporting rules
  • QER QoS enforcement rules
  • the UL and DL traffic may be differentiated based on source.
  • a merged QoS Flow may consider UL traffic as the traffic generated at UE 102 A and DL traffic as the traffic generated at UE 102B.
  • the same QoS flow is shared between two UEs.
  • the shared PFCP session enables sharing the management of the user-plane traffic (PDR, FAR, etc).
  • FIG. 3 is an example for group-level alternative, but for merged QoS flow the shared PFCP session 399 would be the same or similar (e.g., PDR for UL and DL traffic and then the associated FAR, QER, etc that should apply for both UEs).
  • FIG. 4 depicts an example process for grouping of QoS flows as a group-level flow as noted above with respect to FIG. 1C.
  • a network node such as a network exposure function (NEF) 444, may receive from the AF 250 a request indicating UE-UE communications between UEs 102A-B (e.g., for TSC).
  • NEF network exposure function
  • the need for UE-UE communications is identified based on the request received at 404, for example.
  • one or more network nodes such as the NEF, PCF, and/or SMF, may determine whether the UE-UE communications is a service authorized for UEs 102A-B.
  • the PCF may decide to update UE 102 A and UE 102B with QoS policies that enable the UE-UE communications.
  • the PCF may deliver UE route selection policies (URSP) to UE 102 A and UE 102B using a UE configuration update procedure for transparent UE policy delivery.
  • URSP UE route selection policies
  • the UE 102A may initiate a PDF session establishment based on the received URSP.
  • the UE 102B may initiate a PDF session establishment based on the received URSP.
  • the SMF may correlate both QoS flows for UE-UE communications between UE 102A and UE 102B.
  • the SMF may group the both QoS flows using a group-level flow definition or a merge of the QoS flows.
  • the SMF may also reconfigure the user-plane (u- plane) based on the group-level flow definition. For example, the SMF establishes a shared PFCP session with the UPF to manage the group-level flow or the merged QoS Flow, the SMF reconfigures the access-specific QoS parameters for UEl and UE2 at the UPF/gNB. [073] In the FIG.
  • the AF 250 may send the information regarding the UE- UE communication requirements (identity of linked UEs and QoS requirements) to a core network node.
  • the PCF 280 may generate URSP rules and delivers the URSP rules together with the QoS requirements to the UEs using the UE configuration update procedure for transparent UE policy delivery as described in 3GPP TS 23.502.
  • the UEs may check they do not have a PDU session with the parameters received and both UEs trigger the establishment of a new PDU session and a QoS flow based on the URSP.
  • the SMF may correlate, at 416, both QoS flows and may decide to group at 416 the QoS flows. Grouping both QoS flows at 416 may be based on a group-level QoS flow as a pipeline for both QoS flows or merging both QoS Flows into one. Depending on the option selected, the SMF may configure the UPF.
  • the SMF may configure the UPF may reconfigure the user-plane (with, e.g., the establishment of a shared PFCP session and the reconfiguration UE 102 A and UE 102B QoS flow level parameters) if needed at the remaining nodes, such as the UEs, gNB, PCF, and/or the like.
  • the UEs 102A-B may directly request the establishment of a new QoS flow for UE-UE communications based on the information pre- configured or received by the network.
  • the UEs may initiate the establishment of the QoS flows needed for the UE-UE communications and the SMF may correlate, at 416, the QoS flows to identify possible grouping of QoS Flows.
  • FIG. 5 depicts a block diagram of a network node 800, in accordance with some example embodiments.
  • the network node 500 may be configured to provide one or more network side functions, such as a base station (e.g., RAN 270), AMF 272, PCF 280, AF 250, CNC 204, CUC 202, and/or other network nodes.
  • the network node 500 may include a network interface 502, a processor 520, and a memory 504, in accordance with some example embodiments.
  • the network interface 502 may include wired and/or wireless transceivers to enable access other nodes including base stations, devices 252-280, the Internet, and/or other nodes.
  • the memory 504 may comprise volatile and/or non-volatile memory including program code, which when executed by at least one processor 520 provides, among other things, the processes disclosed herein with respect to the network node.
  • FIG. 6 illustrates a block diagram of an apparatus 10, in accordance with some example embodiments.
  • the apparatus 10 may represent a user equipment, such as the user equipment 102A-C.
  • the apparatus 10 may include at least one antenna 12 in communication with a transmitter 14 and a receiver 16. Alternatively transmit and receive antennas may be separate.
  • the apparatus 10 may also include a processor 20 configured to provide signals to and receive signals from the transmitter and receiver, respectively, and to control the functioning of the apparatus.
  • Processor 20 may be configured to control the functioning of the transmitter and receiver by effecting control signaling via electrical leads to the transmitter and receiver.
  • processor 20 may be configured to control other elements of apparatus 10 by effecting control signaling via electrical leads connecting processor 20 to the other elements, such as a display or a memory.
  • the processor 20 may, for example, be embodied in a variety of ways including circuitry, at least one processing core, one or more microprocessors with accompanying digital signal processor(s), one or more processor(s) without an accompanying digital signal processor, one or more coprocessors, one or more multi-core processors, one or more controllers, processing circuitry, one or more computers, various other processing elements including integrated circuits (for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and/or the like), or some combination thereof. Accordingly, although illustrated in FIG. 6 as a single processor, in some example embodiments the processor 20 may comprise a plurality of processors or processing cores.
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • the apparatus 10 may be capable of operating with one or more air interface standards, communication protocols, modulation types, access types, and/or the like.
  • Signals sent and received by the processor 20 may include signaling information in accordance with an air interface standard of an applicable cellular system, and/or any number of different wireline or wireless networking techniques, comprising but not limited to Wi-Fi, wireless local access network (WLAN) techniques, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, 802.16, 802.3, ADSL, DOCSIS, and/or the like.
  • these signals may include speech data, user generated data, user requested data, and/or the like.
  • the apparatus 10 and/or a cellular modem therein may be capable of operating in accordance with various first generation (1G) communication protocols, second generation (2G or 2.5G) communication protocols, third-generation (3G) communication protocols, fourth-generation (4G) communication protocols, fifth-generation (5G) communication protocols, Internet Protocol Multimedia Subsystem (IMS) communication protocols (for example, session initiation protocol (SIP) and/or the like.
  • the apparatus 10 may be capable of operating in accordance with 2G wireless communication protocols IS-136, Time Division Multiple Access TDMA, Global System for Mobile communications, GSM, IS-95, Code Division Multiple Access, CDMA, and/or the like.
  • the apparatus 10 may be capable of operating in accordance with 2.5G wireless communication protocols General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), and/or the like. Further, for example, the apparatus 10 may be capable of operating in accordance with 3G wireless communication protocols, such as Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), and/or the like. The apparatus 10 may be additionally capable of operating in accordance with 3.9G wireless communication protocols, such as Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and/or the like. Additionally, for example, the apparatus 10 may be capable of operating in accordance with 4G wireless communication protocols, such as LTE Advanced, 5G, and/or the like as well as similar wireless communication protocols that may be subsequently developed.
  • GPRS General Packet Radio Service
  • EDGE Enhanced Data GSM Environment
  • the processor 20 may include circuitry for implementing audio/video and logic functions of apparatus 10.
  • the processor 20 may comprise a digital signal processor device, a microprocessor device, an analog-to-digital converter, a digital-to-analog converter, and/or the like. Control and signal processing functions of the apparatus 10 may be allocated between these devices according to their respective capabilities.
  • the processor 20 may additionally comprise an internal voice coder (VC) 20a, an internal data modem (DM) 20b, and/or the like.
  • the processor 20 may include functionality to operate one or more software programs, which may be stored in memory. In general, processor 20 and stored software instructions may be configured to cause apparatus 10 to perform actions.
  • processor 20 may be capable of operating a connectivity program, such as a web browser.
  • the connectivity program may allow the apparatus 10 to transmit and receive web content, such as location-based content, according to a protocol, such as wireless application protocol, WAP, hypertext transfer protocol, HTTP, and/or the like.
  • Apparatus 10 may also comprise a user interface including, for example, an earphone or speaker 24, a ringer 22, a microphone 26, a display 28, a user input interface, and/or the like, which may be operationally coupled to the processor 20.
  • the display 28 may, as noted above, include a touch sensitive display, where a user may touch and/or gesture to make selections, enter values, and/or the like.
  • the processor 20 may also include user interface circuitry configured to control at least some functions of one or more elements of the user interface, such as the speaker 24, the ringer 22, the microphone 26, the display 28, and/or the like.
  • the processor 20 and/or user interface circuitry comprising the processor 20 may be configured to control one or more functions of one or more elements of the user interface through computer program instructions, for example, software and/or firmware, stored on a memory accessible to the processor 20, for example, volatile memory 40, non-volatile memory 42, and/or the like.
  • the apparatus 10 may include a battery for powering various circuits related to the mobile terminal, for example, a circuit to provide mechanical vibration as a detectable output.
  • the user input interface may comprise devices allowing the apparatus 20 to receive data, such as a keypad 30 (which can be a virtual keyboard presented on display 28 or an externally coupled keyboard) and/or other input devices.
  • apparatus 10 may also include one or more mechanisms for sharing and/or obtaining data.
  • the apparatus 10 may include a short-range radio frequency (RF) transceiver and/or interrogator 64, so data may be shared with and/or obtained from electronic devices in accordance with RF techniques.
  • RF radio frequency
  • the apparatus 10 may include other short-range transceivers, such as an infrared (IR) transceiver 66, a BluetoothTM (BT) transceiver 68 operating using BluetoothTM wireless technology, a wireless universal serial bus (USB) transceiver 70, a BluetoothTM Low Energy transceiver, a ZigBee transceiver, an ANT transceiver, a cellular device-to-device transceiver, a wireless local area link transceiver, and/or any other short-range radio technology.
  • Apparatus 10 and, in particular, the short-range transceiver may be capable of transmitting data to and/or receiving data from electronic devices within the proximity of the apparatus, such as within 10 meters, for example.
  • the apparatus 10 including the Wi-Fi or wireless local area networking modem may also be capable of transmitting and/or receiving data from electronic devices according to various wireless networking techniques, including 6LoWpan, Wi-Fi, Wi-Fi low power, WLAN techniques such as IEEE 802.11 techniques, IEEE 802.15 techniques, IEEE 802.16 techniques, and/or the like.
  • various wireless networking techniques including 6LoWpan, Wi-Fi, Wi-Fi low power, WLAN techniques such as IEEE 802.11 techniques, IEEE 802.15 techniques, IEEE 802.16 techniques, and/or the like.
  • the apparatus 10 may comprise memory, such as a subscriber identity module (SIM) 38, a removable user identity module (R-UIM), an eUICC, an UICC, and/or the like, which may store information elements related to a mobile subscriber.
  • SIM subscriber identity module
  • R-UIM removable user identity module
  • eUICC embedded user identity module
  • UICC universal integrated circuit card
  • the apparatus 10 may include volatile memory 40 and/or non-volatile memory 42.
  • volatile memory 40 may include Random Access Memory (RAM) including dynamic and/or static RAM, on-chip or off-chip cache memory, and/or the like.
  • RAM Random Access Memory
  • Non-volatile memory 42 which may be embedded and/or removable, may include, for example, read-only memory, flash memory, magnetic storage devices, for example, hard disks, floppy disk drives, magnetic tape, optical disc drives and/or media, non-volatile random access memory (NVRAM), and/or the like. Like volatile memory 40, non-volatile memory 42 may include a cache area for temporary storage of data. At least part of the volatile and/or non-volatile memory may be embedded in processor 20.
  • the memories may store one or more software programs, instructions, pieces of information, data, and/or the like which may be used by the apparatus for performing operations disclosed herein. Alternatively or additionally, the apparatus may be configured to cause the operations disclosed herein with respect to the base stations/WLAN access points and network nodes including the UEs.
  • the memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying apparatus 10.
  • the memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying apparatus 10.
  • the processor 20 may be configured using computer code stored at memory 40 and/or 42 to the provide operations disclosed herein with respect to the UE.
  • Some of the embodiments disclosed herein may be implemented in software, hardware, application logic, or a combination of software, hardware, and application logic.
  • the software, application logic, and/or hardware may reside on memory 40, the control apparatus 20, or electronic components, for example.
  • the application logic, software or an instruction set is maintained on any one of various conventional computer- readable media.
  • a “computer-readable medium” may be any non-transitory media that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or data processor circuitry, with examples depicted at FIG. 6, computer-readable medium may comprise a non-transitory computer-readable storage medium that may be any media that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.
  • the base stations and user equipment (or one or more components therein) and/or the processes described herein can be implemented using one or more of the following: a processor executing program code, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an embedded processor, a field programmable gate array (FPGA), and/or combinations thereof.
  • ASIC application-specific integrated circuit
  • DSP digital signal processor
  • FPGA field programmable gate array
  • These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
  • These computer programs also known as programs, software, software applications, applications, components, program code, or code
  • computer-readable medium refers to any computer program product, machine-readable medium, computer-readable storage medium, apparatus and/or device (for example, magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions.
  • PLDs Programmable Logic Devices
  • systems are also described herein that may include a processor and a memory coupled to the processor.
  • the memory may include one or more programs that cause the processor to perform one or more of the operations described herein.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

In some example embodiment, there may be provided an apparatus configured to at least group two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment. Related system, methods, and articles of manufacture are also disclosed.

Description

GROUPING QOS FLOW FOR USER EQUIPMENT TO USER EQUIPMENT
COMMUNICATIONS
[001] The subject matter described herein relates to wireless technology.
Background
[002] Time sensitive networks (TSN) may be used to support a variety of applications including applications such as ultra-reliable low-latency communications (URLLC), industrial verticals, and/or the like. In the case of industrial verticals and other mission critical applications, there may be some requirements that are relatively unique, such as certain requirements for low latency, deterministic data transmission, and high reliability, when compared to other 5G cellular services.
Summary
[003] In some example embodiment, there may be provided an apparatus configured to at least group two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment.
[004] In some variations, one or more of the features disclosed herein including the following features can optionally be included in any feasible combination. The apparatus may be further caused to at least detect that the first flow and the second flow can be grouped based on at least the two flows carrying data from between the first user equipment and the second user equipment via the cellular network. The apparatus may be further caused to at least detect that the first flow and the second flow can be grouped based on at least one or more packet filters of the first flow and/or the second flow. The one or more packet filters may include one or more of the following: a source MAC address, a destination MAC address, a source IP address, and a destination IP address. The grouping may include merging the first flow and the second flow into a single flow, wherein the merging includes modifying one or more session parameters associated with the first flow and/or the second flow to enable the single flow. The grouping may include linking the first flow and the second flow as a group, wherein the linking is indicated by an identifier. The grouped first and second flows may share a packet forwarding control protocol session. The apparatus may be caused to receive a request for communications between the first user equipment and the second user equipment. The grouping may be triggered by the received request. The apparatus may be further caused to at least configure the first flow and the second flow based on at least one or more end-to-end quality of service requirements.
[005] The above-noted aspects and features may be implemented in systems, apparatus, methods, and/or articles depending on the desired configuration. The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
Description of Drawings
[006] In the drawings,
[007] FIGs. 1 A depicts an example of UE to UE communications, in accordance with some example embodiments;
[008] FIG. IB depicts an example of a process for grouping QoS flows of UE-UE communications, in accordance with some example embodiments.
[009] FIG. 1C depicts an example of grouping based on group-level flow definitions, in accordance with some example embodiments.
[010] FIG. ID depicts an example of grouping based on merging flow definitions, in accordance with some example embodiments.
[011] FIG. 2 A depicts an example of a portion of a time sensitive network, in accordance example embodiments. [012] FIG. 2B depicts an example of a 3 GPP bridge for a time sensitive network, in accordance with some example embodiments;
[013] FIG. 3 depicts an example of a shared session, in accordance with some example embodiments;
[014] FIG. 4 depicts an example of a process flow for UE-UE communications based on grouped QoS flows session, in accordance with some example embodiments;
[015] FIG. 5 depicts an example of a network node, in accordance with some example embodiments; and
[016] FIG. 6 depicts an example of an apparatus, in accordance with some example embodiments.
[017] Like labels are used to refer to same or similar items in the drawings.
Detailed Description
[018] Some Time Sensitive Communications (TSC) use cases may involve communications between machines, such as between user equipment (UE) located in the 5G network. In 3GPP TS 22.104, a few application areas, such as within factories and the like, may be optimized for UE to UE (UE-UE) communications to provide improved service, end-to-end latency, maintainability, and flexibility. For example, control communications between UEs may provide optimized TSC between individual components (or functions) of a larger machine (e.g., the components of the larger machine may operate via UE-UE communications in a TSC manner). Similarly, the UE-UE communications may be used to coordinate individual machines (which include UEs) when performing a task. These machines (which include UEs) may be synchronized and exchange real-time (or near real-time) information. Moreover, these machines may not have a fixed configuration (e.g., as control nodes their configuration may vary as the status of the corresponding machine changes). The UE-UE communications disclosed herein refers to communications, such as TSC or other traffic types having demands for low latency and/or high reliability, via the cellular network, rather than device-to-device (D2D) communications directly between the UEs.
[019] Although the previous example refers to TSC within a factory, the TSC may be used in other environments, such as in the audio industry, the video industry, and the like.
Within these use case examples, the flows, such as the deterministic flows found in TSC, may transmit audio and/or video to a limited geographic area (e.g., a live concert) and/or wider areas (e.g., a concert broadcasting).
[020] Although two UEs may be connected to the same cellular network and may camp in the same geographical area, the radio conditions at each of the UEs may differ significantly. And, these conditions at each UE may be dynamic in the sense that the conditions may change from time to time. For example, the UEs may be mobile or may encounter different obstructions and the like (e.g., different structures such as walls or obstacles within a factory may cause radio or RF obstructions). As such, the radio conditions for the two UEs may be not be the same, such as asymmetric. When establishing a data communication link between these two UEs in a cellular network such as 5G as shown at FIG. 1 A, the cellular network may consider the quality of service (QoS) requirements, and may then establish two independent, new QoS flows between each of the UEs 102A-B and a corresponding user plane function (UPF) 115 via a base station such as a 5G gNB type base station 110A. Although FIG. 1 A depicts the UE-UE communications link including the first leg 105 and the second leg 107 via a single base station 110 A, the UE-UE communications link may be via two base stations as well as.
[021] In the example of FIG. 1 A, the UE-UE communications link includes a first leg 105 including communication links 105A-B and a second leg 107 including communication links 107A-B. For example, the first leg 105 may include a radio link 105 A (which may include an uplink (and/or a downlink) via data radio bearer(s), DRBs) from the UE 102A and gNB 110A and a tunnel, such as a GTP-U tunnel 105B (GPRS tunneling protocol -user plane tunnel(s)) between the gNB 110A and UPF 115. And, the second leg 107 may include a radio link 107 A (which may include a downlink (and/or an uplink) via DRBs) from the UE 102B and gNB 110A and a tunnel, such as a GTP-U tunnel 107B between the gNB 110A and UPF 115.
[022] If the end-to-end latency requirement is 4 milliseconds for example, the cellular network may configure both QoS flows (for both legs 105 and 107) to satisfy a maximum delay of 2 milliseconds (ms) for each leg 105 and 107 as there is no current mechanism in the cellular network to jointly consider the radio conditions of both UEs 102A-B to support this maximum delay requirement or other QoS parameters. As such, if the radio condition at UE 102 A changes drastically, the cellular network needs a way to link these two legs for UE-UE communications, so that if the radio conditions does change at, for example, UE 102A and first leg 105, the network can jointly consider the change and perhaps make adjustments to UE 102B and the second leg 107. To illustrate further, if the radio conditions at UE 102A change for the worse so that latency on the first leg increases to 3 milliseconds, the cellular network may, in accordance with some example embodiments, modify the session for UE 102B so that the latency is 1 millisecond. Although some of the examples refer to delay as the QoS parameter being configured for UE-UE communications, other parameters may be configured as well.
[023] In some example embodiments, there may be provided UE-UE communications via the cellular system or network, such as the 5G system, such that when the data is forwarded through the 5G system the QoS flows are grouped for the user-plane traffic of the UE-UE communications between, for example, UE 102 A and UE 102B.
[024] For example, knowledge of the UE-UE communications may be used to optimize QoS in such a way that the QoS parameters are chosen and established for the whole UE-UE communication link (or whole path including legs 105 and 107) from UE 102 A and UE 102B, and not just for each of the independent QoS flows. In other words, the QoS parameters may be configured at the time the QoS flow is established (or reconfigured upon mobility or other event of one or both the UE(s)) for the entire UE-UE communications link between the EEs 102A-B, for example. This may allow the QoS flow to be optimized irrespective of whether the delay estimated for both the EEs 102A-B is symmetric or asymmetric. Symmetric delay implies that the delay incurred over the air and backhaul is the same for both the EEs 102A-B. By contrast, the asymmetric delay implies that the delay incurred over and air and backhaul are different for both the EEs 102A-B.
[025] The 5G core network may detect that the requested QoS flows are dedicated to the EE-EE communications between EE 102A-B. This detection may be based on the packet filters within the QoS rules requested. For example, the detection of the first flow and the second flow may be based on the packet filters of the first and second flows. For example, the packet filter for an IP PDU session may include one or more of the following: the source IP address(or IPv6 prefix), the destination IP address (or IPv6 prefix), the source port number, the destination port number, protocol ID of the protocol above IP/Next header type, type of service/ traffic class and mask, flow label, security parameter index, and packet filter direction. And the packet filter for an Ethernet PDU session may include one or more of the following: the source MAC address, the destination MAC address, customer- VLAN tag and/or service- VLAN tag VID fields as defined in IEEE 802. IQ, customer- VLAN tag (C-TAG) and/or service- VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE 802. IQ, IP packet filter set, and packet filter direction. As such, the contents of the packet filters may be used to determine source UE and destination UE based on source and destination IP addresses included in the packet filters, source and destination MAC addresses included in the packet filters, protocol IDs, and the like.
[026] The UE-UE communications may apply for a subset of the QoS flows within a PDU session, or may apply to all the QoS flows within the PDU session (in which case, the PDU session is a special case of the PDU session for the UE-UE communications). The 5G core network may use the knowledge of the end point UEs 102A-B, the TSC traffic characteristics, and the QoS requirements for the entire UE-UE communications path (e.g., legs 105-107 between EE 102A-B) to establish a grouped QoS flow for the two EEs in EE-EE communications, in accordance with some example embodiments.
[027] In some example embodiments, there may be provided different forwarding treatments that uplink (EE) user data packets can have in one or more QoS flows based on the QoS rules to handle different EE-EE links within the same PDU session for the EE-EE communications. For example, a trigger for grouping QoS flows for the EE-EE communications may be a node, such as a core network node, receiving forwarding information (e.g., EE 102A-B as end points that want to communicate) from another network node (e.g., new information available at the session management function (SMF) or policy control function (PCF) from the AF). Alternatively, or additionally, a trigger for grouping QoS flows for EE-EE communication may be a node, such as a core network node, receiving a request or indication that is indicative of a UE requesting a new QoS flow for EE-EE communications.
[028] FIG. IB depicts an example of a process for grouping QoS flows of EE-EE communications, in accordance with some example embodiments.
[029] At 160A-B, each EE, such as EE 102A and EE 102B, may request a flow, such as a QoS flow via a message, such as a PDU session establishment (or modification) procedure. The requested QoS flow may have a certain configuration (or identifier) to identify that the QoS flow is for the EE-EE communications type of traffic. In the case of EE 102A for example, the destination address (e.g., of the destination EE 102B) may be included in the QoS rule (or filter) of the QoS flow to indicate that the QoS flow is for the EE-EE communications traffic type between UE 102A and UE 102B.
[030] At 162A-B, a node, such as a 5G core network node, may configure a QoS flow for each of the EEs in EE-EE communications. For example, the node may configure, for EE 102 A, a first QoS flow for the first leg 105 and may configure, for the UE 102B, a second QoS flow for the second leg 107.
[031] At 164, a node, such as a 5G core network node, may detect that both QoS flows can be grouped because the QoS flows are for UE-UE communications between UE 102 A and UE 102B. For example, the node may detect that first QoS flow over leg 105 and the second QoS flow (over the second leg 107) may be grouped since both the first and second QoS flows depend on one another for UE-UE communications between UE 102 A and UE 102B. For example, the SMF may determine (e.g., by correlating) the requests, so the detection that the QoS flows can be grouped may be done based on the combination of information within the QoS rules (or filters) requested for each UE (e.g., traffic source/destination) or based on information received from the AF (e.g. the configuration of a virtual network group).
[032] At 166, a node, such as a 5G core network node, may group the QoS flows and reconfigure the user plane based on the end-to-end QoS requirements for the UE-UE communications. For example, the first QoS flow via leg 105 may be grouped with the second QoS flow via leg 107. This grouping enables the node to coordinate the grouped QoS flows management for the UE-UE communications link type of traffic. The QoS flow grouping is further described below with respect to FIGs. 1C and ID. In this example, the first QoS flow and the second QoS flow carry user-plane traffic end-to-end between UEs 102A-B, which are in UE-UE communications (which may be TSC type traffic or other types of low delay and/or high reliability traffic). As such, a changed of the conditions affecting the first QoS flow or the first UE 102 A may be considered jointly with the second QoS flow or the second UE 102B. As noted in the above-noted example, if the radio conditions at UE 102 A deteriorate so that the first QoS flow can only support a 3 ms delay requirement, the network may modify the configuration of the second QoS flow to provide a 1 ms delay in order to maintain a 4 ms packet delay budget, for example. [033] The grouping of the QoS flows, such as the QoS flows being carried over leg 105 and 107, for UE-UE communications enables establishment, modification, and/or release based on the conditions, such as connectivity conditions at both UEs 102A-B, jointly. As such, if the radio conditions at UE 102 A change for the worse so that latency on the first leg 105 increases to 3 milliseconds, the cellular network may, in accordance with some example embodiments, modify the session for UE 102B so that the latency is 1 millisecond.
[034] FIG. 1C depicts UE 102A (labeled UE1) and UE 102B (labeled UE2) in UE-UE communications via a core network node, such as the UPF 115 based on grouped flows, in accordance with some example embodiments. In the example of FIG. 1C, the UE 102 A and UE 102C (labeled UE3) are also in UE-UE communications via the UPF 115.
[035] In the example of FIG. 1C, there is a group-level QoS flow definition. For example, the two QoS flows 172 A and 172B are grouped as they provide the flows for the UE- UE communications between UE 102A and UE 102B. Likewise, the two QoS flows 174A and 174B are grouped as they provide the flows for the UE-UE communications between UE 102B and UE 102C.
[036] The QoS flow definitions and their policies (see, e.g., 3GPP TS 23.501 and 23.503) may be extended so that a new, so-called “overlay” QoS flow may be defined to enable the grouped flows.
[037] In the case of the group-level grouping of flows, the overlay QoS flow is an additional layer considered within the core network, such as the SMF, PCF, and/or other node, that groups at least two QoS flows. When two QoS flows are grouped as a group-level, the core network nodes, such as the SMF, PCF, and the like, detect the flow grouping and configure QoS parameters or policy based on the end-end requirements of the UE-UE communications and based on the connectivity conditions at each of the UEs in UE-UE communications. In other words, the group-level QoS flows are treated jointly with respect to QoS parameters and policy rather than independently. In some example embodiments, the group-level QoS flows are flagged with an indication, such as an identifier for the QoS flows making up the group-level. For example, the indication, such as the identifier of the group-level QoS flow, may be used among network nodes, such as the SMF, PCF, and the like, to indicate that certain QoS flows belong to the same group-level QoS flow.
[038] From the 5G core network perspective, the QoS flows joined in the same group, such as QoS flow 172 A and 172B, are dependent on one another, so the reconfiguration in one leg of the user plane (e.g., QoS flow 172A between UE 102A and UPF) may impact the other leg (e.g., QoS flow 172B between UE 102B and UPF). Likewise, a reconfiguration in one leg of the user plane (e.g., QoS flow 174A between UE1 102A and UPF) may impact the other leg (e.g., QoS flow 174B between UE 102C and UPF 115). As the two flows are linked, each leg may be configured in an asymmetric manner. For example, the configuration of one leg of the user plane (e.g., QoS flow 172A between UE 102A and UPF 115) may be different from the other leg (e.g., QoS flow 172B between UE 102B and UPF). With a packet delay budget between UE 102A and UE 102B of 3 milliseconds for example, the asymmetric configuration enables QoS flow 172A to be configured to have a 1 millisecond delay while QoS flow 172B to have a 2 millisecond delay.
[039] FIG. ID depicts UE 102A and UE 102B in UE-UE communications via a core network node, such as the UPF 115, based on merged flows, in accordance with some example embodiments. In the case of a merged QoS flow definition, when both QoS flows are established, the a network node, such as a 5G core network node, may reconfigure the user- plane configuration to join both the QoS flows in a merged flow in which the configuration is shared between both UEs (e.g., the QoS requirements, charging, etc.) considering the end-to-end QoS requirements for UE-UE communications. In the case of the merge, the QoS flows for each leg are replaced by a single, merged QoS flow, which is end-to-end between the UEs. As such, the merged QoS flow is treated as a single QoS flow (e.g., between UE 102A and UE 102B), rather than as two QoS flows (one between UE 102 A and the UPF and another between UE 102B and the UPF). In the case of a merged flow, the UE 102 A views the QoS flows 182A- B as a single QoS flow, but the core network may view the QoS flows 182A-B as a shared QoS flow between two UEs 102A-B. As the flows are merged into a single flow, the merged flows may have symmetric configurations (e.g., the same or similar QoS parameters or policies).
[040] Both grouping QoS flows techniques at FIG. 1C and ID may, from a UE perspective, may be in accordance with, for example, 3GPP TS 23.501. A network node, such as a 5G core network node, may obtain end-to-end QoS requirements for the UE-UE communications. The node may obtain these end-to-end QoS requirements from the AF, UEs, or other nodes. For example, the UEs 102A-B (or an AF) may provide to the network node network including the 5G core network the end-to-end QoS requirements for the UE-UE communications. The QoS requirements requested may be in the form of QoS related information elements but for the specific UE-UE communication, QoS flows end-to-end.
[041] In some example embodiments, the grouping of QoS flows may be triggered by an event, such as receiving information, such as an indication or other information from an AF, UE, or other node.
[042] In some example embodiments, the UE-UE communications may be identified in a proactive (e.g., before QoS flows are established) or a reactive manner (e.g., after the QoS flows are established). For example, the UE-UE communications between UE 102A and UE 102B may be identified in a proactive manner. To illustrate further, the UE-UE communication link may be identified based on the information received from the AF and/or UE. This information may include a specific configuration of the requested QoS flows (e.g., a packet filter included in the QoS rule) or the information received from the AF (e.g., 5G virtual network configuration and end-to-end QoS requirements). [043] In the case of reactive, the UE-UE communication link may be identified based on the exchanged user plane packets between the UEs 102A-B. For example, the exchanged user plane packets between the UEs 102A-B may enable a network node such as a 5G core network node to recognize the source and destination end points as two UEs 102A-B or based on address resolution protocol requests. The reactive identification may not be used to do frequent QoS parameters updates on the fly as the QoS flows should be configured in advance, but it may be used to update the TSC assistance information configuration of the QoS flows.
[044] The QoS flow configuration may vary based on whether the QoS flows are grouped (as described above with respect to FIG. 1C) or merged (as described above with respect to FIG. ID).
[045] With the group-level QoS flow of FIG. 1C for example, the procedures to configure both QoS flows may be extended to take into account the group-level flows and how these flows are treated at core network nodes, such as a session management function (SMF), policy control function (PCF) when configuring both, group-level QoS flows. In some example embodiments, a new type of identifier may be used to point to, or indicate, the group-level QoS flow. For example, the identifier may indicate that the two QoS flows (e.g., the first QoS flow from the UE 102 A to the UPF and the second QoS flow from UE 102B to the UPF) are grouped for purposes UE-UE communications, so a change to one UE or QoS flow affects the other UE and QoS flow as well. This identifier may only be needed at the SMF and PCF as the nodes, which may be responsible for configuring and/or managing the group-level QoS flow.
[046] With the merged QoS flow of FIG. ID for example, the QoS flow procedures may be extended to take into account having a shared QoS flow between two UEs. As two UEs are sharing a QoS flow, there may be some QoS parameters that will be specific to a UE while other QoS parameters may be common to both UEs in a given session (e.g., the protocol data unit (PDU) session) and the QoS flows. [047] With respect to core network procedures, it may vary based on whether the QoS flows are group-level (as described above with respect to FIG. 1C) or merged (as described above with respect to FIG. ID). With the group-level QoS flow of FIG. 1C for example, this may enable the use of a Packet Forwarding Control Protocol (PFCP) session (established at the N4 interface between UPF and SMF) to the control of the user-plane (e.g. in terms of charging, forwarding, policies, QoS enforcement, etc.) when establishing the QoS flows. Additionally, a shared PFCP session between both UEs may be provided to handle the group-level QoS flow. With the merged QoS flow of FIG. ID for example, this may also require a shared PFCP session between the two UEs involved in the UE-UE communications.
[048] The merged QoS flows or group-level QoS flows may be applied in both UE- UE TSC communication based a Time Sensitive Networks (TSN) black box architecture (e.g., a 5G system as a TSN Bridge as shown at 205D at FIG. 2B) or a TSC service without the TSN Bridge.
[049] Before providing additional description regarding the UE-UE communications technology disclosed herein. The following provides a description related to TSC communications, although the UE-UE communications technology disclosed herein may be used in systems, apparatus, and processes not related to TSC as well. Furthermore, although some of the examples refer to 5G, the UE-UE communications technology disclosed herein may be used with other types of systems and networks as well.
[050] In some systems such as industrial networks including industrial internet of things (IIoT) or Industry 4.0 networks, 3GPP wireless technologies may be applied in addition to wired time sensitive networking (TSN) to provide additional flexibility with respect to mobility and to provide scalability with respect to the quantity of sensors, actuators, and/or the like which can be supported. For example, a TSN or other source of deterministic traffic may couple to a user equipment and use the 3 GPP wireless network as a bridge to enable the traffic to traverse the 3GPP network to another device or network, such as another TSN network. As used herein, deterministic traffic refers to predictable, such as periodic traffic, an example of which is TSN traffic, which may be in accordance with IEEE 802.1 series standards, for example.
[051] FIG. 2 A depicts an example of a TSN network 200 configured in a fully centralized configuration model, although other configuration models may be implemented as well. In the TSN network example of FIG. 2A, the network 200 may include a centralized user configuration (CUC) function 202, a centralized network controller (CNC) 204 function, one or more TSN bridges 205A-C, and one or more end stations 207A-F.
[052] The CUC 202 may be configured in accordance with the one or more of the IEEE 802.1 series of TSN standards. The CUC may control the configuration of end stations 207A-F and/or applications at the end stations. For example, the CUC may interface with the CNC 204 to make requests to the CNC for deterministic, TSN communications (e.g., TSN flows) with specific requirements for those flows between end stations. The TSN flow may represent a time sensitive, deterministic stream of traffic between end stations. These TSN flows may have low delay and/or strict timing requirements for time sensitive networks. For example, a TSN flow (also referred to as a TSN stream) between end stations may, as noted, be used in an industrial control application (e.g., robot, factory machines, etc.) requiring low delay and/or strict, deterministic timing between the end stations. The TSN flow may also have requirements for ultra-low reliability.
[053] The CNC 204 may provide a proxy for the TSN bridges 205A-C and the corresponding interconnections, and provide a proxy for control applications that require deterministic communication. The CNC may define the schedules, such as gate schedules, on which all TSN traffic is transmitted (or received) between the end stations including any intervening devices such as the TSN bridges 205A-C. For example, the schedules may define periodic transmission and/or reception.
[054] The TSN bridges 205 A-C may be implemented as Ethernet switches, for example. The TSN bridges are configured to transmit and/or receive TSN flows in accordance with a schedule, such as the gate schedule that gates traffic for transmission or reception. The TSN flow may be in the form of Ethernet frames transmitted and/or received on the schedule to meet the low delay and/or deterministic requirements of the TSN flow. For example, the talker end station 207A may transmit traffic based on the schedule (see, e.g., IEEE 802.1Qbv) to a bridge 105 A, which may also receive and/or transmit traffic to another device based on a schedule.
[055] The end stations 207A-F may be a source and/or a destination of a TSN flow. The end stations may include an application, such as an industrial application or other application requiring low delay and/or other time sensitive requirement for a deterministic traffic flow. The end stations may also be referred to as talkers and listeners. Talker end stations refer to an end station that at a given instance is “talking,” such as transmitting in accordance with TSN, while the listener end stations refer to an end station that at a given instance is “listening.” For example, each of the end stations may include circuitry to transmit (e.g., in the case of a “talker”) and/or receive (e.g., in the case of a “listener”) using for example, Time Sensitive Network (TSN) circuitry that enables communications over a TSN network in accordance with the IEEE suite of 802.1 series of standards.
[056] FIG. 2B depicts an example of a TSN bridge 205D, in accordance with some example embodiments. The TSN bridge 205D is also referred to herein as a 3GPP bridge 205D (or 5G system (5GS) bridge) as the 3GPP bridge 205D is implemented as part of the cellular wireless system, such as the 5G system or other type of cellular or wireless system. Referring also to FIGs. 1 A-B, each of the UEs 102A and 102B may comprise, or be comprised in, UE 264 to enable the TSC. In the example of FIG. 2B, the TSN system 288 A may comprise the end station 207 A, which may access the 3 GPP bridge 205D via for example a wired connection to a user equipment (UE) 264 and a device side (DS) TSN translator (TT) 262. The user equipment 264 may establish a connection with a user plane function (UPF) 282 (which also includes a network side (NW) TT) via a radio access network (RAN) 270, such as a 5G gNB or other type of base station. The UPF 282 including the NW-TT 282 may provide a TSN compatible user plane data flow to TSN system 288B, which may comprise an end station, such as end station 207D for example.
[057] Moreover, the UE 264 and/or RAN 270 may be configured with a schedule such as a gate schedule (which may be in accordance with IEEE 802. IQbv). The gate schedule defines when traffic, such as burst, can be transmitted (or received) over the link in order to satisfy the low-latency and/or deterministic needs of TSN. The gate schedule may define the periodicity of the transmission and/or reception of a given device. The links (e.g., uplinks and/or downlinks) via the RAN represent the wireless part of the end-to-end connection between the TSN system 288A and another device or network, such as the TSN system 288B.
[058] The DS-TT 262 and NW-TT 283 may translate TSN user plane data between the TSN system and the 3GPP system (e.g., via an ingress port 266A at the UE and an egress port 266B at the UPF 282. Although FIG. 2B depicts the NW-TT 283 at the UPF 282, the NW- TT may be located at other nodes as well.
[059] One or more nodes of the 3GPP bridge 205D may interface with the CUC 202 and/or CNC 204 to obtain information regarding the end station requirements for the TSN flow connection(s). For example, the AF 250 may interface to the TSN’s CUC 202 and/or CNC 204 to obtain information regarding the TSN flows between TSN systems 288A-B (e.g., end stations). The 3GPP bridge 205D may include one or more radio access networks 270 (e.g., a radio access network served by a base station, gNB, eNB, and/or other nodes including core network nodes) to enable wireless connectivity for an end-to-end TSN flow between the TSN systems. Referring again to FIG. 2A, one or more of the bridges 205 A-C may be implemented using the 3GPP bridge 205D of FIG. IB to provide TSN support over the 5G wireless system. From the perspective of the end stations 207A and D for example, the 5G system’s 3GPP bridge 205D appears like a more traditional wired TSN bridge.
[060] FIG. 2B also depicts other network elements including an Access and Mobility Management Function (AMF) 272, a User Data Management (UDM) function 274, a Session Management Function (SMF) 276, a Policy Control Function (PCF) 280, a Network Exposure Function (NEF) 278, and an Application Function (AF) 250. In some implementations, the TSN system 288B may include a corresponding UE and/or DS-TT to mirror the UE 264 and DS-TT. Referring also to FIGs. 1 A-B, UE 102A may comprise, or be comprised in, UE 264, while UE 102B may be similarly implemented. In the case of UE-UE communications for example where the QoS flows in each of the legs of the user plane are coordinated as being dependent, both UEs may be configured such that they are being served by at least one of RAN 270. In other words, the UEs 102 A-B may be configured as described with respect to UE 264.
[061] With respect to the integration of 5G and TSN, the integration may only support a TSN fully centralized model as noted above. In this centralized model, the CUC 202 may be primarily responsible for the end stations’ configuration and application requirements management, while the CNC 204 may configure the TSN bridges using a relatively complete view of the physical topology of the network and the capabilities of each TSN bridge. The 5G system may, as noted, provide one or more 3 GPP bridges of the TSN network. The granularity of each 3GPP bridge is at a per user plane function (UPF) level. As such, all protocol data unit (PDU) sessions (which connect to the same TSN network via a specific UPF) may be grouped into a single, logical 3GPP bridge, such as 3GPP bridge 205D. [062] Disclosed herein are two ways to group flows, such as QoS flows, using a group-level QoS flow definition or a merged QoS flow definition. The cellular system, such as the 5G core network (or nodes therein), may be configured to identify the UE-UE communications based on specific configuration parameters for the QoS flows (e.g., a specific requested packet filter set within the QoS rule representative of UE-UE communications).
These QoS flows for UE-UE communications may comprise a subset or all the flows contained in a PDU session. And, the specific configuration parameters may be obtained at the 5G core network node from at least two sources. For example, the AF may be a source. In the case of the AF, the current set of information received for the configuration of a 5G virtual network group may be reused by adding QoS requirements needed for the UE-UE communications. The UE may also be a source. In the case of a UE, the parameters to configure the QoS flow for UE- UE communications may be made available to the UE in variety of ways. For example, the parameters to configure the QoS flow may be pre-configured in the UE. Alternatively, or additionally, the parameters to configure the QoS flow may be provided by an application server. Alternatively, or additionally, the parameters to configure the QoS flow may be provided by the PCF to the UE as UE Route Selection Policy (URSP) rules. Alternatively, or additionally, the parameters to configure the QoS flow may be provided by the SMF to the UE during the registration procedure or a generic UE configuration update procedure.
[063] The derivation of UE-UE communications may occur at a network node, such as the SMF or the PCF. The QoS flow configuration of both UEs may change to establish a group-level QoS flow (as described with respect to FIG. 1C, for example) or a merged QoS flow (as described with respect to FIG. ID, for example) considering the end-to-end QoS requirements. The remaining entities in the network (e.g., UE, gNB, AMF, and the like) may not be impacted if the SMF and/or PCF handle the grouping of the QoS flows. The SMF or PCF may receive the configuration and set up the user-plane connectivity per 3GPP TS 23.501, but the UPF behavior may be different if the PFCP session is shared between two UEs. For example, the UPF may report user plane management information to the SMF associated with two UEs or avoid the use of the 5G virtual network internal interface for local switching when forwarding UE-UE traffic.
[064] For the merged QoS flow definition, defining a merging QoS flow (which is shared between two UEs) may include additional changes when configuring the shared QoS flow. This is due in part to both UEs having to share the PDU session and the QoS flow configuration parameters being used by the shared, merged QoS flow, so that the connectivity is compatible. Table 1 summarizes some parameters that may be common between the two UEs and some parameters, which may be specific for a given UE, when a merged QoS flow is configured.
[065] Table 1 : PDU session parameters common and specific per UE when using merged QoS flow.
Figure imgf000021_0001
[066] As noted, the UEs in UE-UE communications may share a PFCP session. This shared PFCP session may be defined at the group QoS flow level (e.g., group-level QoS flow) or a merged QoS flow may have an individual PFCP session to control the packet processing at the UPF. As such, the shared PFCP session may be shared between the two UEs involved in the UE-UE communications. Although PFCP is described, other control-plane protocols for controlling user-plane packet processing and forwarding may be used as well to handle packet detection rules, forwarding action rules, buffering action rules, QoS enforcement rules, and/or usage reporting rules.
[067] FIG. 3 shows how the PFCP session may be defined for a group-level QoS flow. At 360A-B, each UE 102A-B has a PFCP session for its PDU session. At 399, the PFCP session is shared between two UEs, such as UE 102A-B, and the granularity is smaller to enable control of the group-level QoS flow. Therefore, the shared PFCP session at 399 is based on two UEs in this configuration (e.g., the PDI definition or the user-plane reporting is associated with two UEs, avoiding thus the need of the two-step forwarding in 5G virtual network (via 5G virtual network internal interface at the UPF)).
[068] To illustrate further, the configuration of the shared PFCP session 399 may allow different, smaller granularities when processing the uplink (UL) and downlink (DL) flows at the UPF as the shared PFCP session can have 2 or 4 packet data detection rules (PDR for matching data packets to certain processing rules) and forwarding action rules (FARs, how packets matching PDRs should be handled including a trigger for first packet notification) to treat UL and DL traffic from both UEs 102A-B.
[069] In the case of the merged QoS flow, the shared PFCP session 399 may enable extending what the UPF considers as UL traffic and DL traffic for the usage reporting rules (URR) and QoS enforcement rules (QER) reporting in both UEs. Based on the source UE, the UL and DL traffic may be differentiated based on source. For UE 102 A to UE 102B link for example, a merged QoS Flow may consider UL traffic as the traffic generated at UE 102 A and DL traffic as the traffic generated at UE 102B. In the case of merged flows, the same QoS flow is shared between two UEs. As such, the shared PFCP session enables sharing the management of the user-plane traffic (PDR, FAR, etc). FIG. 3 is an example for group-level alternative, but for merged QoS flow the shared PFCP session 399 would be the same or similar (e.g., PDR for UL and DL traffic and then the associated FAR, QER, etc that should apply for both UEs).
[070] FIG. 4 depicts an example process for grouping of QoS flows as a group-level flow as noted above with respect to FIG. 1C.
[071] At 402, the UE 102A and UE 102B may already be registered with the cellular network. At 404, a network node, such as a network exposure function (NEF) 444, may receive from the AF 250 a request indicating UE-UE communications between UEs 102A-B (e.g., for TSC). At 406, the need for UE-UE communications is identified based on the request received at 404, for example. At 406, one or more network nodes, such as the NEF, PCF, and/or SMF, may determine whether the UE-UE communications is a service authorized for UEs 102A-B. At 408, the PCF may decide to update UE 102 A and UE 102B with QoS policies that enable the UE-UE communications. At 410, the PCF may deliver UE route selection policies (URSP) to UE 102 A and UE 102B using a UE configuration update procedure for transparent UE policy delivery. At 412, the UE 102A may initiate a PDF session establishment based on the received URSP. At 414, the UE 102B may initiate a PDF session establishment based on the received URSP.
[072] At 416, the SMF may correlate both QoS flows for UE-UE communications between UE 102A and UE 102B. The SMF may group the both QoS flows using a group-level flow definition or a merge of the QoS flows. The SMF may also reconfigure the user-plane (u- plane) based on the group-level flow definition. For example, the SMF establishes a shared PFCP session with the UPF to manage the group-level flow or the merged QoS Flow, the SMF reconfigures the access-specific QoS parameters for UEl and UE2 at the UPF/gNB. [073] In the FIG. 4 example, the AF 250 may send the information regarding the UE- UE communication requirements (identity of linked UEs and QoS requirements) to a core network node. Based on the AF request, the PCF 280 may generate URSP rules and delivers the URSP rules together with the QoS requirements to the UEs using the UE configuration update procedure for transparent UE policy delivery as described in 3GPP TS 23.502. Upon reception of the core network information (e.g., the URSP or other information) at the UEs, the UEs may check they do not have a PDU session with the parameters received and both UEs trigger the establishment of a new PDU session and a QoS flow based on the URSP. When the UEs request specific QoS flows to communicate between each other, the SMF may correlate, at 416, both QoS flows and may decide to group at 416 the QoS flows. Grouping both QoS flows at 416 may be based on a group-level QoS flow as a pipeline for both QoS flows or merging both QoS Flows into one. Depending on the option selected, the SMF may configure the UPF. And, the SMF may configure the UPF may reconfigure the user-plane (with, e.g., the establishment of a shared PFCP session and the reconfiguration UE 102 A and UE 102B QoS flow level parameters) if needed at the remaining nodes, such as the UEs, gNB, PCF, and/or the like.
[074] Alternatively, or additionally, the UEs 102A-B may directly request the establishment of a new QoS flow for UE-UE communications based on the information pre- configured or received by the network. When this is the case, the UEs may initiate the establishment of the QoS flows needed for the UE-UE communications and the SMF may correlate, at 416, the QoS flows to identify possible grouping of QoS Flows.
[075] FIG. 5 depicts a block diagram of a network node 800, in accordance with some example embodiments. The network node 500 may be configured to provide one or more network side functions, such as a base station (e.g., RAN 270), AMF 272, PCF 280, AF 250, CNC 204, CUC 202, and/or other network nodes. [076] The network node 500 may include a network interface 502, a processor 520, and a memory 504, in accordance with some example embodiments. The network interface 502 may include wired and/or wireless transceivers to enable access other nodes including base stations, devices 252-280, the Internet, and/or other nodes. The memory 504 may comprise volatile and/or non-volatile memory including program code, which when executed by at least one processor 520 provides, among other things, the processes disclosed herein with respect to the network node.
[077] FIG. 6 illustrates a block diagram of an apparatus 10, in accordance with some example embodiments.
[078] The apparatus 10 may represent a user equipment, such as the user equipment 102A-C.
[079] The apparatus 10 may include at least one antenna 12 in communication with a transmitter 14 and a receiver 16. Alternatively transmit and receive antennas may be separate. The apparatus 10 may also include a processor 20 configured to provide signals to and receive signals from the transmitter and receiver, respectively, and to control the functioning of the apparatus. Processor 20 may be configured to control the functioning of the transmitter and receiver by effecting control signaling via electrical leads to the transmitter and receiver. Likewise, processor 20 may be configured to control other elements of apparatus 10 by effecting control signaling via electrical leads connecting processor 20 to the other elements, such as a display or a memory. The processor 20 may, for example, be embodied in a variety of ways including circuitry, at least one processing core, one or more microprocessors with accompanying digital signal processor(s), one or more processor(s) without an accompanying digital signal processor, one or more coprocessors, one or more multi-core processors, one or more controllers, processing circuitry, one or more computers, various other processing elements including integrated circuits (for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and/or the like), or some combination thereof. Accordingly, although illustrated in FIG. 6 as a single processor, in some example embodiments the processor 20 may comprise a plurality of processors or processing cores.
[080] The apparatus 10 may be capable of operating with one or more air interface standards, communication protocols, modulation types, access types, and/or the like. Signals sent and received by the processor 20 may include signaling information in accordance with an air interface standard of an applicable cellular system, and/or any number of different wireline or wireless networking techniques, comprising but not limited to Wi-Fi, wireless local access network (WLAN) techniques, such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, 802.16, 802.3, ADSL, DOCSIS, and/or the like. In addition, these signals may include speech data, user generated data, user requested data, and/or the like.
[081] For example, the apparatus 10 and/or a cellular modem therein may be capable of operating in accordance with various first generation (1G) communication protocols, second generation (2G or 2.5G) communication protocols, third-generation (3G) communication protocols, fourth-generation (4G) communication protocols, fifth-generation (5G) communication protocols, Internet Protocol Multimedia Subsystem (IMS) communication protocols (for example, session initiation protocol (SIP) and/or the like. For example, the apparatus 10 may be capable of operating in accordance with 2G wireless communication protocols IS-136, Time Division Multiple Access TDMA, Global System for Mobile communications, GSM, IS-95, Code Division Multiple Access, CDMA, and/or the like. In addition, for example, the apparatus 10 may be capable of operating in accordance with 2.5G wireless communication protocols General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), and/or the like. Further, for example, the apparatus 10 may be capable of operating in accordance with 3G wireless communication protocols, such as Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), and/or the like. The apparatus 10 may be additionally capable of operating in accordance with 3.9G wireless communication protocols, such as Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and/or the like. Additionally, for example, the apparatus 10 may be capable of operating in accordance with 4G wireless communication protocols, such as LTE Advanced, 5G, and/or the like as well as similar wireless communication protocols that may be subsequently developed.
[082] It is understood that the processor 20 may include circuitry for implementing audio/video and logic functions of apparatus 10. For example, the processor 20 may comprise a digital signal processor device, a microprocessor device, an analog-to-digital converter, a digital-to-analog converter, and/or the like. Control and signal processing functions of the apparatus 10 may be allocated between these devices according to their respective capabilities. The processor 20 may additionally comprise an internal voice coder (VC) 20a, an internal data modem (DM) 20b, and/or the like. Further, the processor 20 may include functionality to operate one or more software programs, which may be stored in memory. In general, processor 20 and stored software instructions may be configured to cause apparatus 10 to perform actions. For example, processor 20 may be capable of operating a connectivity program, such as a web browser. The connectivity program may allow the apparatus 10 to transmit and receive web content, such as location-based content, according to a protocol, such as wireless application protocol, WAP, hypertext transfer protocol, HTTP, and/or the like.
[083] Apparatus 10 may also comprise a user interface including, for example, an earphone or speaker 24, a ringer 22, a microphone 26, a display 28, a user input interface, and/or the like, which may be operationally coupled to the processor 20. The display 28 may, as noted above, include a touch sensitive display, where a user may touch and/or gesture to make selections, enter values, and/or the like. The processor 20 may also include user interface circuitry configured to control at least some functions of one or more elements of the user interface, such as the speaker 24, the ringer 22, the microphone 26, the display 28, and/or the like. The processor 20 and/or user interface circuitry comprising the processor 20 may be configured to control one or more functions of one or more elements of the user interface through computer program instructions, for example, software and/or firmware, stored on a memory accessible to the processor 20, for example, volatile memory 40, non-volatile memory 42, and/or the like. The apparatus 10 may include a battery for powering various circuits related to the mobile terminal, for example, a circuit to provide mechanical vibration as a detectable output. The user input interface may comprise devices allowing the apparatus 20 to receive data, such as a keypad 30 (which can be a virtual keyboard presented on display 28 or an externally coupled keyboard) and/or other input devices.
[084] As shown in FIG. 6, apparatus 10 may also include one or more mechanisms for sharing and/or obtaining data. For example, the apparatus 10 may include a short-range radio frequency (RF) transceiver and/or interrogator 64, so data may be shared with and/or obtained from electronic devices in accordance with RF techniques. The apparatus 10 may include other short-range transceivers, such as an infrared (IR) transceiver 66, a BluetoothTM (BT) transceiver 68 operating using BluetoothTM wireless technology, a wireless universal serial bus (USB) transceiver 70, a BluetoothTM Low Energy transceiver, a ZigBee transceiver, an ANT transceiver, a cellular device-to-device transceiver, a wireless local area link transceiver, and/or any other short-range radio technology. Apparatus 10 and, in particular, the short-range transceiver may be capable of transmitting data to and/or receiving data from electronic devices within the proximity of the apparatus, such as within 10 meters, for example. The apparatus 10 including the Wi-Fi or wireless local area networking modem may also be capable of transmitting and/or receiving data from electronic devices according to various wireless networking techniques, including 6LoWpan, Wi-Fi, Wi-Fi low power, WLAN techniques such as IEEE 802.11 techniques, IEEE 802.15 techniques, IEEE 802.16 techniques, and/or the like.
[085] The apparatus 10 may comprise memory, such as a subscriber identity module (SIM) 38, a removable user identity module (R-UIM), an eUICC, an UICC, and/or the like, which may store information elements related to a mobile subscriber. In addition to the SIM, the apparatus 10 may include other removable and/or fixed memory. The apparatus 10 may include volatile memory 40 and/or non-volatile memory 42. For example, volatile memory 40 may include Random Access Memory (RAM) including dynamic and/or static RAM, on-chip or off-chip cache memory, and/or the like. Non-volatile memory 42, which may be embedded and/or removable, may include, for example, read-only memory, flash memory, magnetic storage devices, for example, hard disks, floppy disk drives, magnetic tape, optical disc drives and/or media, non-volatile random access memory (NVRAM), and/or the like. Like volatile memory 40, non-volatile memory 42 may include a cache area for temporary storage of data. At least part of the volatile and/or non-volatile memory may be embedded in processor 20. The memories may store one or more software programs, instructions, pieces of information, data, and/or the like which may be used by the apparatus for performing operations disclosed herein. Alternatively or additionally, the apparatus may be configured to cause the operations disclosed herein with respect to the base stations/WLAN access points and network nodes including the UEs.
[086] The memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying apparatus 10. The memories may comprise an identifier, such as an international mobile equipment identification (IMEI) code, capable of uniquely identifying apparatus 10. In the example embodiment, the processor 20 may be configured using computer code stored at memory 40 and/or 42 to the provide operations disclosed herein with respect to the UE. [087] Some of the embodiments disclosed herein may be implemented in software, hardware, application logic, or a combination of software, hardware, and application logic. The software, application logic, and/or hardware may reside on memory 40, the control apparatus 20, or electronic components, for example. In some example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer- readable media. In the context of this document, a “computer-readable medium” may be any non-transitory media that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or data processor circuitry, with examples depicted at FIG. 6, computer-readable medium may comprise a non-transitory computer-readable storage medium that may be any media that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.
[088] Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein may be better resource utilization of UE-UE communications links.
[089] The subject matter described herein may be embodied in systems, apparatus, methods, and/or articles depending on the desired configuration. For example, the base stations and user equipment (or one or more components therein) and/or the processes described herein can be implemented using one or more of the following: a processor executing program code, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), an embedded processor, a field programmable gate array (FPGA), and/or combinations thereof. These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device. These computer programs (also known as programs, software, software applications, applications, components, program code, or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object- oriented programming language, and/or in assembly/machine language. As used herein, the term “computer-readable medium” refers to any computer program product, machine-readable medium, computer-readable storage medium, apparatus and/or device (for example, magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions. Similarly, systems are also described herein that may include a processor and a memory coupled to the processor. The memory may include one or more programs that cause the processor to perform one or more of the operations described herein.
[090] Although a few variations have been described in detail above, other modifications or additions are possible. In particular, further features and/or variations may be provided in addition to those set forth herein. Moreover, the implementations described above may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed above. Other embodiments may be within the scope of the following claims.
[091] If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined. Although various aspects of some of the embodiments are set out in the independent claims, other aspects of some of the embodiments comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims. It is also noted herein that while the above describes example embodiments, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications that may be made without departing from the scope of some of the embodiments as defined in the appended claims. Other embodiments may be within the scope of the following claims. The term “based on” includes “based on at least.” The use of the phase “such as” means “such as for example” unless otherwise indicated.

Claims

WHAT 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 to at least: group two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment.
2. The apparatus of claim 1, wherein the apparatus is further caused to at least detect that the first flow and the second flow can be grouped based on at least the two flows carrying data from between the first user equipment and the second user equipment via the cellular network.
3. The apparatus of claim 1, wherein the apparatus is further caused to at least detect that the first flow and the second flow can be grouped based on at least one or more packet filters of the first flow and/or the second flow.
4. The apparatus of claim 3, wherein the one or more packet filters include one or more of the following: a source MAC address, a destination MAC address, a source IP address, and a destination IP address.
5. The apparatus of any of claims 1-4, wherein the grouping comprises merging the first flow and the second flow into a single flow, wherein the merging includes modifying one or more session parameters associated with the first flow and/or the second flow to enable the single flow.
6. The apparatus of any of claims 1-5, wherein the grouping comprises linking the first flow and the second flow as a group, wherein the linking is indicated by an identifier.
7. The apparatus of any of claims 1-6, wherein the grouped first and second flows share a packet forwarding control protocol session.
8. The apparatus of any of claims 1-7, wherein the apparatus is further caused to receive a request for communications between the first user equipment and the second user equipment.
9. The apparatus of claim 8, wherein the grouping is triggered by the received request.
10. The apparatus of any of claims 1-9, wherein the apparatus is further caused to at least configure the first flow and the second flow based on at least one or more end-to-end quality of service requirements.
11. A method comprising: grouping two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment.
12. The method of claim 11, further comprising detecting that the first flow and the second flow can be grouped based on at least the two flows carrying data from between the first user equipment and the second user equipment via the cellular network.
13. The method of claim 11, further comprising detecting that the first flow and the second flow can be grouped based on at least one or more packet filters of the first flow and/or the second flow.
14. The method of claim 13, wherein the one or more packet filters include one or more of the following: a source MAC address, a destination MAC address, a source IP address, and a destination IP address.
15. The method of any of claims 11-14, wherein the grouping comprises merging the first flow and the second flow into a single flow, wherein the merging includes modifying one or more session parameters associated with the first flow and/or the second flow to enable the single flow.
16. The method of any of claims 11-15, wherein the grouping comprises linking the first flow and the second flow as a group, wherein the linking is indicated by an identifier.
17. The method of any of claims 11-16, wherein the grouped first and second flows share a packet forwarding control protocol session.
18. The method of any of claims 11-17, further comprising receiving a request for communications between the first user equipment and the second user equipment.
19. The method of claim 18, wherein the grouping is triggered by the received request.
20. The method of any of claims 11-19, further comprising configuring the first flow and the second flow based on at least one or more end-to-end quality of service requirements.
21. An apparatus comprising: means for grouping two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment.
22. The apparatus of claim 21 further comprising means for performing any of the functions in any of claims 12-19.
23. A non-transitory computer-readable storage medium including program code which when executed causes operations comprising: grouping two flows including a first flow and a second flow, the two flows carrying data from a first user equipment via a cellular network to a second user equipment.
PCT/EP2020/085242 2020-01-03 2020-12-09 Grouping qos flow for user equipment to user equipment communications WO2021136636A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202062956961P 2020-01-03 2020-01-03
US62/956,961 2020-01-03

Publications (1)

Publication Number Publication Date
WO2021136636A1 true WO2021136636A1 (en) 2021-07-08

Family

ID=73835568

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/085242 WO2021136636A1 (en) 2020-01-03 2020-12-09 Grouping qos flow for user equipment to user equipment communications

Country Status (1)

Country Link
WO (1) WO2021136636A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023009043A1 (en) * 2021-07-27 2023-02-02 Telefonaktiebolaget Lm Ericsson (Publ) Network node and method therein for optimized use of 5g system bridge ports
WO2023088155A1 (en) * 2021-11-19 2023-05-25 华为技术有限公司 Quality-of-service (qos) management method and apparatus
WO2023098618A1 (en) * 2021-11-30 2023-06-08 中国电信股份有限公司 Quality of service (qos) control method and apparatus for virtual network (vn) group, and related device
WO2023193571A1 (en) * 2022-04-06 2023-10-12 华为技术有限公司 Communication method and communication apparatus
WO2024061007A1 (en) * 2022-09-21 2024-03-28 中国电信股份有限公司 Virtual network group topology management method, nef entity, communication system, and storage medium
WO2024066939A1 (en) * 2022-09-29 2024-04-04 中国电信股份有限公司 Multicast communication method for virtual network group, communication system, and related device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018201822A1 (en) * 2017-05-04 2018-11-08 中国移动通信有限公司研究院 Data transmission configuration and data transmission method, apparatus, and computer storage medium
WO2019158219A1 (en) * 2018-02-19 2019-08-22 Huawei Technologies Duesseldorf Gmbh Ran device and core network device for network slicing

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018201822A1 (en) * 2017-05-04 2018-11-08 中国移动通信有限公司研究院 Data transmission configuration and data transmission method, apparatus, and computer storage medium
WO2019158219A1 (en) * 2018-02-19 2019-08-22 Huawei Technologies Duesseldorf Gmbh Ran device and core network device for network slicing

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023009043A1 (en) * 2021-07-27 2023-02-02 Telefonaktiebolaget Lm Ericsson (Publ) Network node and method therein for optimized use of 5g system bridge ports
WO2023088155A1 (en) * 2021-11-19 2023-05-25 华为技术有限公司 Quality-of-service (qos) management method and apparatus
WO2023098618A1 (en) * 2021-11-30 2023-06-08 中国电信股份有限公司 Quality of service (qos) control method and apparatus for virtual network (vn) group, and related device
WO2023193571A1 (en) * 2022-04-06 2023-10-12 华为技术有限公司 Communication method and communication apparatus
WO2024061007A1 (en) * 2022-09-21 2024-03-28 中国电信股份有限公司 Virtual network group topology management method, nef entity, communication system, and storage medium
WO2024066939A1 (en) * 2022-09-29 2024-04-04 中国电信股份有限公司 Multicast communication method for virtual network group, communication system, and related device

Similar Documents

Publication Publication Date Title
JP7040556B2 (en) Method, session management function node, user plane function node, and session management parameter maintenance user equipment and its computer readable recording medium.
WO2021136636A1 (en) Grouping qos flow for user equipment to user equipment communications
US11197168B2 (en) Systems and methods to augment the capacities and capabilities of cellular networks through an unmanned aerial vehicle network overlay
CN110583095B (en) Default service quality rule management method and user equipment
US9578593B2 (en) System and method for coordinated remote control of network radio nodes and core network elements
US11956157B2 (en) Activation of PDU session and QOS flows in 3GPP-based ethernet bridges
US20210400524A1 (en) Method to support 5g time sensitive communications
JP7344990B2 (en) TSN and 5GS QoS Mapping - User Plane Based Method
CN112889254A (en) Method and system for processing data packet by using strategy
US20220263743A1 (en) Selective packet duplication or alternative packet transmission based on survival time
US20220078662A1 (en) TSN-CELLULAR COMMUNICATION SYSTEM QoS MAPPING AND RAN OPTIMIZATION BASED ON TSN TRAFFIC PATTERN RELATED INFORMATION
KR102469973B1 (en) Communication method and device
CN112636884B (en) Message transmission method and device
WO2021069552A1 (en) Identifying time sensitive network streams within a 3gpp qos flow
KR20170133793A (en) Method and system of signaling procedure for mobile communication core network
CN116916402A (en) Mechanism for coordinating seamless service continuity to edge application servers at relocation
Detti Functional architecture
Do et al. SDN-based mobile packet core for multicast and broadcast services
US20230038925A1 (en) Qos flow configuration for user equipment to user equipment communications
US20240056955A1 (en) Techniques for non-integrated traffic aggregation, steering, and switching for a protocol data unit session
CN116134955A (en) Autonomously activating features at a wireless communication device to satisfy a lifetime of an application consuming communication services
CN111373834B (en) Client device, access network device, method and computer program for establishing a data radio bearer
WO2024037256A1 (en) Service flow routing method and apparatus
WO2022222666A1 (en) Communication method and apparatus
US20220159758A1 (en) Apparatuses and Methods for Data Duplication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20824489

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20824489

Country of ref document: EP

Kind code of ref document: A1