Delegate traffic management system and method

Abstract

According to an implementation, a communication device transmits a TMM message over a traffic management and monitoring TMM transport channel. The TMM transmission channel is a transmission channel based on a user plane, the transmission channel based on the user plane uses a TMM quality of service (QoS) flow, and the TMM QoS flow is different from a user data QoS flow used for user data transmission. Or a data radio bearer DRB between the UE and the base station and a general packet radio service tunneling protocol user GTP-U protocol between the base station and the UPF network entity are used. Or, the transmission channel is a transmission channel based on a control plane, and the transmission channel based on the control plane uses a non-access stratum (NAS) signaling between the UE and a session management function (SMF) network entity and a packet forwarding control protocol (PFCP) between the SMF network entity and the UPF network entity.

Description

Cross-references to applications related to delegated traffic management systems and methods

[0001] This patent application claims priority to U.S. Provisional Application No. 63 / 587,844, filed October 4, 2023, entitled “System and Methods for Delegated Traffic Management,” and U.S. Provisional Application No. 63 / 674,075, filed July 22, 2024, entitled “System and Methods for Delegated Traffic Management,” both of which are hereby incorporated herein by reference as if reproduced in their entirety. Technical Field

[0002] The present invention relates to a system and method for delegated traffic management, and in a particular embodiment, to a system and method for use of transport containers in delegated traffic management. Background Technology

[0003] In various scenarios, the slow start phase in traffic management can be impacted by increased end-to-end (E2E) queues (increased latency) and potential packet loss. This technical issue is particularly challenging for traffic requiring low latency and high throughput that triggers Internet Protocol (IP) layer handovers (e.g., user mobility). With the highly distributed deployment of user plane functions (UPFs) in networks and increased user mobility, handovers can become more frequent, leading to additional latency, jitter, and packet loss.

[0004] The embodiments of the present invention provide technical improvements and advantages to address these technical problems. Summary of the Invention

[0005] The technical advantages are achieved through the implementation of the methods, apparatus and system described in this invention.

[0006] Depending on the implementation, the communication equipment uses a traffic management and monitoring (TMM) transport container to transmit transport management messages for flow regulation reports (FRR) based on extensions to the 3GPP control plane channels or 3GPP user plane channels. The user plane function (UPF) network entity provides the user equipment (UE) with bandwidth or other flow conditions between the UPF network entity and the UE.

[0007] Depending on the implementation, the communication device can be a UPF network entity or a UE.

[0008] Depending on some implementations, transport management messages may include commands to UPF network entities for end-to-end (E2E) Internet Protocol (IP) flows belonging to a Protocol Data Unit (PDU) session of a UE.

[0009] Depending on the implementation, the session management function (SMF) network entity can authorize flow conditioning request messages for FRR based on the policy or ownership of the E2E IP flow belonging to the PDU session of the UE.

[0010] Depending on the implementation, the SMF network entity may delegate the authorization of flow conditioning request messages for FRR to the UPF network entity based on the policy or ownership of the E2E IP flow belonging to the PDU session of the UE.

[0011] Depending on the implementation, the transport management message used for FRR can indicate changes to the bandwidth constraints of an E2E IP flow.

[0012] Depending on the implementation, the communication device can be a UE (User Equipment). Applications within the UE may be eligible to request changes to flow conditioning attributes. When an application starts, it can initiate the establishment of a Flow Conditioning Attribute (FRR) within the UE to request changes to flow conditioning attributes from the network device properties.

[0013] Depending on the implementation, applications in the UE can determine whether they are eligible to request changes in flow conditioning attributes from the network device based on the UE route selection policy (URSP).

[0014] According to some implementation methods, the UE can determine the application corresponding to the transmission management message used for FRR based on IP flow information, which includes the quintuple of the E2P IP flow.

[0015] Depending on the implementation, the communication device can be a UPF network entity. The UPF network entity can configure FRR, which instructs the UPF network entity's control procedures to change E2E stream shaping or scheduling attributes. The UPF network entity can send or receive transport management messages for FRR.

[0016] Depending on the implementation, the TMM transport container can use non-access stratum (NAS) message extensions between the UE and the SMF network entity, and packet forwarding control protocol (PFCP) extensions between the SMF network entity and the UPF network entity.

[0017] Depending on the implementation, the TMM transport container can be located in one of the following: (i) a dedicated quality of service (QoS) stream, (ii) a service data adaptation protocol (SDAP) control channel, or (iii) a packet data convergence protocol (PDCP) control protocol data unit (PDU).

[0018] Depending on the implementation, the TMM transport container can be carried in a dedicated QoS stream that is separate from the user data QoS stream.

[0019] Depending on the implementation, dedicated QoS streams and user data QoS streams can be mapped to a single data radio bearer (DRB).

[0020] Depending on the implementation, dedicated QoS streams and user data QoS streams can be mapped to separate data radio bearers (DRBs).

[0021] Depending on the implementation, the TMM transport container can be carried within an SDAP control PDU. The SDAP control PDU may include a control PDU type field indicating that the SDAP control PDU is an SDAP TMM transport control PDU.

[0022] Depending on the implementation, the TMM transport container can be carried in a PDCP control PDU. The PDCP control PDU may include a PDU type field indicating that the PDCP control PDU is a TMM transport control PDU. Alternatively, the PDCP control PDU may be a generic message transport control PDU, including a message type field indicating the message type carried in the message payload field.

[0023] Depending on the implementation, bandwidth or other flow conditions can be carried in the TMM transport container. The UPF network entity can provide the TMM transport container to the UE, such that the UPF network entity provides the TMM transport container directly to the UE without any other network entity relaying the TMM transport container, or the UPF network entity provides the TMM transport container to the UE through a second network entity without the second network entity modifying the TMM transport container.

[0024] Depending on some implementation methods, the second network entity can be an SMF network entity.

[0025] Depending on the implementation method, extensions to the 3GPP control plane channels or 3GPP user plane can be implemented at a layer lower than the IP layer.

[0026] Depending on the implementation, the communication device uses a transport container for carrying IP streams and traffic management information to communicate between the UE and the UPF network entity. The transport container uses Non-Access Stratum (NAS) message extension between the UE and the SMF network entity, and PFCP extension between the SMF network entity and the UPF network entity.

[0027] Depending on the implementation, the communication device can be a UPF network entity or a UE.

[0028] Depending on the implementation, the communication device uses a transport container for carrying IP streams and traffic management information to communicate between the UE and the UPF network entity. The transport container is located in one of the following: (i) a dedicated QoS stream, (ii) an SDAP control channel, or (iii) a PDCP control PDU.

[0029] Depending on the implementation, the communication device can be a UPF network entity or a UE.

[0030] Examples of advantages of implementing the present invention include improved traffic management, including reduced latency, potential packet loss, and other technical issues associated with slowly increasing the rate to avoid exceeding available capacity. Attached Figure Description

[0031] To provide a more complete understanding of the invention and its advantages, the following description is made in conjunction with the accompanying drawings, in which: Figure 1 is an example representation of NAS and RRC signaling from UE to 5GS; Figure 2 is an example representation of a general model of a UE and UPF supporting TMM and FRR according to some implementations; Figure 3 is an example representation of a protocol stack for TMM transmission via NAS and PFCP according to some implementations; Figures 4A and 4B show example representations of NAS-TMM with FRR flowcharts according to some implementations; Figure 5 is an example representation of a QoS flow-based TMM / FRR flowchart according to some implementations; Figure 6A is an example representation of an existing format of SDAP end-mark control PDU; Figure 6B is an example representation of an existing format of UL SDAP data PDU and a new format of DL SDAP data PDU; Figure 6C is a new UL and DL according to some implementations. Figure 7 shows an example representation of the format of an SDAP control PDU, based on some implementations, for carrying a TMM payload via the Uu interface; Figures 8A and 8B show example representations of the SDAP control PDU / TMM and GTP-U extension flowcharts based on some implementations; Figure 9A shows an example representation of the format of a UL and DL PDCP TMM transmission control PDU based on some implementations; Figure 9B shows the format of a UL and DL PDCP TMM transmission control PDU based on some implementations. Figure 10 is an example representation of the format of the PDCP General Message Transmission Control PDU, according to some implementations; Figures 11A and 11B show example representations of the PDCP control PDU / TMM and GTP-U extension flowcharts according to some implementations; Figure 12A shows a flowchart of a method performed by a communication device according to some implementations; Figure 12B shows a flowchart of a method performed by a communication device according to some implementations; Figure 12C shows a flowchart of a method performed by a communication device according to some implementations; Figure 13 shows an example communication system according to some implementations; Figure 14 shows an example communication system according to some implementations; Figures 15A and 15B show example devices that can implement the methods and teachings according to the present invention according to some implementations; and Figure 16 is a block diagram of a computing system that can be used to implement the devices and methods disclosed herein.

[0032] Unless otherwise indicated, corresponding numbers and symbols in different diagrams generally refer to corresponding parts. The diagrams are drawn to clearly illustrate relevant aspects of the embodiments and are not necessarily drawn to scale. Detailed Implementation

[0033] Internet transmission uses end-to-end (E2E) congestion control (CC) to limit the transmission rate of a flow to the bandwidth-delay product (BDP). This process is achieved by gradually increasing the rate ("slow start phase") and adding capacity, while not exceeding available capacity to avoid packet loss. During the slow start phase, there may be increased E2E queuing (e.g., increased latency) and potential packet loss. This is particularly problematic for traffic that requires low latency and high throughput and triggers IP layer handovers (e.g., user mobility). With the highly distributed deployment of UPFs in networks and increased user mobility, handovers may become more frequent, leading to additional latency, jitter, and packet loss.

[0034] Current processes are considering how to avoid an overly conservative start-up phase. For example, https: / / datatracker.ietf.org / doc / draft-ietf-tsvwg-careful-resume / proposes an ineffective jump to a reasonable high level of capacity and a fallback if necessary. However, the process needs to estimate the available capacity of the flow after switching to a new bottleneck link (e.g., a wireless link). Users / hosts can use configured values, but these will be insufficient if bandwidth values ​​are dynamic, such as in 5th generation (5G) wireless networks. The available bandwidth for a flow is dynamic due to the nature of the wireless link, the number of users on the link, and network attachment (e.g., PDU sessions) / flow policies.

[0035] The dynamic bandwidth value of the stream can be provided through application layer transmission, but this requires a proxy connection and encryption (and key management) between the host / UE and the router / UPF. One technical approach is to extend the existing 3GPP Layer 2 signaling framework to support this exchange between the UPF and the UE. This invention describes this technical approach.

[0036] The following provides a high-level overview of control signaling between user equipment (UE) and RAN / 5GC.

[0037] Figure 1 is an example representation of non-access stratum (NAS) and radio resource control (RRC) signaling from the UE to the 5G system (5GS). NAS signaling messages are transmitted between the UE 102 and the 5G core (5GC) (e.g., access and mobility management function (AMF) 104, session management function (SMF) 106) via the N1 / N11 interface for NAS mobility management (NAS-MM) and NAS session management (NAS-SM). AMF 104 uses the N2 interface to send parameters used by gNB 108 for the UE. UE 102 and gNB 108 use RRC signaling to manage the radio resources of UE 102.

[0038] The signaling radio bearer (SRB) is used to transmit signaling messages between UE 102 and gNB 108 via the Uu interface. All signaling is processed centrally, with SMF 106 (used for session management) transmitting policy and other control messages to UPF 110 via the N4 interface through the packet forwarding control protocol (PFCP). However, there is no signaling context or mechanism for directly transmitting information between UE 102 and UPF 110. The requirements for network coordination signaling define this technical issue and related requirements in detail.

[0039] The Protocol Data Unit (PDU) session established between UE 102 and 5GS can be used to carry one or more E2E flows. Each E2E flow is identified by an IP 5-tuple and has an IP source address that 5GS has assigned to the UE / PDU session. Based on the policy rules assigned to the E2E flows in the PDU session, one or more Quality of Service (QoS) flows can be associated with each other. The 5G user plane (e.g., UPF 110, gNB 108) shapes and schedules packets in these E2E flows according to the policy. This shaping process estimates flow behavior to maximize overall network utilization. As a result, different E2E flows in the PDU session are not always served at nominal rates (e.g., guaranteed bit rate (GBR), maximum flow bit rate (MFBR)) or even proportionally between E2E flows within the PDU session.

[0040] This paper provides a technical solution for transmitting signaling messages for managing one or more QoS flows between a UE and a UPF using a direct transport channel. Various implementations of the solution are described, including adding new functional entities to the UE and UPF, and various signaling flows and protocols involving the UE, UPF, and various other network nodes such as gNB, AMF, and SMF.

[0041] Figure 2 illustrates a general model of the various functional entities in the UE and UPF and the signaling flow between them to support transport management and monitoring (TMM) and flow regulation rules / reports (FRR).

[0042] UPF configuration can include packet detection rules (PDRs) applied to packets in E2E flows (identified by IP 5-tuples, DiffServ codepoints (DSCPs), etc.). Rules in TS 29.244 include Forwarding Action Rules (FAR), Multiple Access Rules (MAR), QoS Enforcement Rules (QER), Buffer Action Rules (BAR), and Usage Reporting Rules (URR). However, current rules do not provide UE bandwidth (BW) information for calculating the secure congestion window (cwnd). Therefore, in various embodiments, a Flow Regulation Report (FRR) mechanism is introduced to provide bandwidth information from the UPF to the UE, which can be used by the UE (e.g., after handover) to accelerate slow start in the new cell serving the UE. FRR entities are configured in both the UE and the UPF for generating (by the UPF) or processing (by the UE) FRR information. TMM entities are also configured in both the UE and UPF to handle signaling messages carrying FRR information. The TMM transport channel can also be used to transmit other types of higher-layer information (e.g., PDU set information of extended reality (XR) packets) between the UE and UPF. In this invention, the TMM transport channel and the TMM transport container are interchangeable.

[0043] The mechanisms described in this invention can be used in applications highly sensitive to bandwidth changes, such as video streaming, or any application requiring high bandwidth and low latency. Therefore, these applications can be FRR-aware. FRR-aware applications can react to shaping used in the network; however, these mechanisms do not affect or change how network shaping itself works. These methods are used to report information for use by applications that may need it and to subscribe to that information. The network layer in the UE uses the information reported in the FRR (i.e., the current bandwidth) for “rate information” of the stream to feed back to the server (which regulates the downlink stream rate). Alternatively, applications at the UE (e.g., adaptive bit rate (ABR) streams) can use this information to determine the rate and then request the server to send at a rate matching the available bandwidth.

[0044] Among the various implementation methods, the process that supports TMM and FRR includes the following operations: Operation 201: Exchange and negotiate TMM and / or FRR capability information during the registration process.

[0045] During registration, the UE indicates to the network its ability to support TMM and FRR, and negotiates with the network for support of TMM (for example, the network can select an AMF that supports TMM to provide services to the UE based on this indication, and the selected AMF can also prepare to select an SMF that supports TMM to provide services for PDU sessions that have not yet been requested by the UE). Since UPF is not involved in operation 201, more details of operation 201 will be described later in Figures 4, 5, 8 and 11.

[0046] Operation 202: Configure TMM and / or FRR support during PDU session establishment (including establishing a transport channel for TMM).

[0047] During PDU session establishment, the application in the UE uses extended socket options to trigger an FRR support request to be sent to the network (e.g., the request is included in the PDU session establishment request message). The network configuration indicates the UE route selection policy (URSP) information for this eligibility (e.g., the route descriptor, in addition to DNN / NSSAI / 3GPP_access, also indicates FRR eligibility). The SMF authorizes or instructs the UPF to authorize FRR for the PDU session (e.g., an E2E flow with a PDU session IP address). Authorization rules restrict FRR requests from the UE to only request a subset of the E2E flows of the PDU session (e.g., all flows of the PDU session (IP address), or 5-tuple / PDU session flows to a specific destination). The rules for the destination in the 5-tuple of the PDU session E2E flow can be based on pre-configured information about the destination server IP address or Server Name Indication (SNI). Subsequently, support for TMM and FRR is initialized in the UE and UPF (including configuring their respective TMM entities and FRR entities), and a TMM transport channel is established between them.

[0048] Operation 203: Application subscription FRR.

[0049] The application (App) in the UE requests the FRR for the E2E flow identified by the IP 5-tuple by subscribing to or setting a callback for a report on the FRR, which triggers the next operation.

[0050] Operation 204: Configure FRR in the network.

[0051] The FRR entity in the UE initiates an FRR request to be sent to the UPF. The FRR request is encapsulated in a TMM message and sent to the UPF via the established TMM transport. The UPF establishes the FRR and initializes the control procedures (including shaping) to report changes in the specified E2E flow. When the FRR is established (either during the initial PDU establishment / modification or after handover), an FRR report is sent to the UE containing information indicating the current bandwidth (BW) of the E2E flow, as shown in step 6 below.

[0052] Operation 205: Transmit PDU / data.

[0053] Operation 206: When the UPF control procedure initiates processing of changes to an E2E flow with an FRR (e.g., due to a policy change or other dynamic control involving multiple flow shaping), it notifies the FRR entity of the change. The UPF receives information representing the resources and capacity available in the gNB. This can be achieved through operations and management (OAM) or policy control function (PCF) / policy for each E2E flow. The FRR entity assembles bandwidth (or other) information, the IP 5-tuple of the E2E flow, etc., into an FRR and provides this FRR to the TMM entity.

[0054] The TMM entity encapsulates the FRR in a TMM message and sends the TMM message to the TMM entity in the UE via the TMM transport channel.

[0055] Operation 207: The IP 5-tuple in the FRR is used by the UE to look up the binding relationship between the received FRR and the associated E2E flow / application. Information in the FRR (such as bandwidth, etc.) is published (based on previous subscriptions) or called back to the application / network service interface (e.g., socket options published by the service agent in the UE).

[0056] The present invention extends and adds the following aspects: 1. A transmission channel for traffic management and monitoring (TMM).

[0057] 2. Flow Regulation Report (FRR). FRR messages between the UE and UPF, as well as FRR (rules) in the UPF, are triggered when the flow regulation direction of an E2E flow with the corresponding rule changes.

[0058] 3. NAS-SM extension, used to transmit TMM messages between the UE and SMF, as part of a CP-based embodiment of TMM transmission; N4 / PFCP message, used to transmit TMM messages between the SMF and UPF, as another part of a CP-based embodiment of TMM transmission. This CP-based TMM transmission mechanism for transmitting FRR messages or other user plane higher-layer control messages between the UE and UPF via the NAS and N4 interfaces is described in detail below.

[0059] 4. The following describes in detail the UP-based TMM transport mechanism for transmitting FRR messages or other user plane (UP) higher-layer control messages between the UE and UPF via a dedicated QoS stream.

[0060] 5. The following describes in detail another UP-based TMM transmission mechanism for transmitting FRR or other user plane higher-layer control messages between the UE and UPF using the in-band signaling mechanism of the General Packet Radio Service Tunneling Protocol (GTP User, GTP-U) protocol (via the N3 interface) and the in-band signaling mechanism of the Service Data Adaptation Protocol (SDAP) (via the Uu interface).

[0061] 6. The following describes in detail another UP-based TMM transmission mechanism for transmitting FRR or other UP higher-layer control messages between the UE and UPF using the in-band signaling mechanism of the GTP-U protocol (via the N3 interface) and the in-band signaling mechanism of the Packet Data Convergence Protocol (PDCP) (via the Uu interface).

[0062] In this invention, "flow" can refer to an E2E flow (which has, for example, an IP 5-tuple) or a 3GPP QoS flow. When "flow" is not qualified, it refers to an E2E flow. The following sections describe the transport channel and flow conditioning in detail.

[0063] This section describes the TMM transport mechanism for transmitting FRR or other signaling messages between the UE and UPF. Four exemplary implementations of the transport mechanism are described, all using the same association (i.e., the TMM context between the UE and UPF). This is understood as delegated control because the SMF, which can act as a controller, is explicitly capable of establishing delegated control messages between the UE and UPF.

[0064] Figure 3 illustrates the protocol stack for a CP-based TMM transport channel using extended NAS and PFCP signaling messages, according to several implementations. The TMM protocol provides end-to-end transport services between the UE and UPF for FRR or other signaling messages. In this CP-based implementation, the TMM protocol uses transport services provided by the NAS protocol and its underlying N4 / PFCP. More specifically, TMM messages are encapsulated in new container fields within specific NAS-SM messages (such as PDU session establishment request / response messages, PDU session modification request / response messages, etc.) to be carried between UE 302 and SMF 304, and in another new container field within specific N4 / PFCP messages between SMF 304 and UPF 306. SMF 304 can verify that UE 302 has access rights (or other policy permissions) for actions in the FRR control message. During initialization, SMF 304 also authorizes UPF 306 to support FRR for the PDU session. These relate to the scope of one or more E2E flows (i.e., whether the UE / PDU session is granted an IP address in the requested 5-tuple) or other subscriptions or policies that determine whether the UE / PDU session is allowed to request FRR control. SMF 394 forwards FRR messages sent via the TMM channel to UFP 306 via PFCP (e.g., PFCP session request / response). In addition to FRR messages, TMM messages can also be used to carry other signaling messages between UE 302 and UFP 306 (e.g., PDU set information indicating XR service flows).

[0065] Direct delegated control between UE 302 and UPF 306 can be achieved by using NAS transmission and TMM transmission with a new container (e.g., TMM container) combined with PFCP-based TMM transmission on the N4 interface.

[0066] Figures 4A and 4B illustrate the operational sequence for establishing TMM transfers on NAS and PFCP, depending on the implementation method.

[0067] In operation 401, UE 422 registers with AMF 426 as described in Section 4.2.2 of TS 23.502 (Section 5.5 of TS 24.501, GMM Procedure). UE 422 indicates that it can support TMM (and FRR), and AMF 426 confirms TMM support.

[0068] In operation 402, at sub-operation 402a, UE 422 initiates PDU session establishment using the procedure described in Section 4.3 of TS 23.502 (Section 6 of TS 24.501, 5GSM Procedure), and AMF 426 selects SMF 428 that supports TMM. PDU session establishment includes requesting TMM / FRR support from SMF 428.

[0069] At sub-operation 402b, SMF 428 selects UPF 430, which supports TMM / FRR, to service the PDU session. SMF sends a PFCP Session Establishment Request (SE-Request), initializes the FRR of the PDU session, and delegates the authorization of the FRRs of the E2E flows belonging to the PDU session to UPF 430. UPF 430 sends a PFCP Session Establishment Response (SE-Response) with its supported FRRs.

[0070] In one example, the FRR report includes bandwidth (BW).

[0071] At sub-operation 402c, SMF 428 confirms FRR capability and support, and configures URSP rules indicating FRR eligibility in UE 422 via (R)AN (e.g., gNB) 424 (see operation 202 in Figure 2).

[0072] In operation 403, the application in UE 422 is started.

[0073] If the application is FRR-aware (e.g., a video stream with ABR), the application requests FRR support from the underlying operating system (OS) services.

[0074] If the application relies on the OS network for congestion control (or user-space services, such as in Quick UDP Internet Connections (QuIC)), the application uses socket extensions to request FRR.

[0075] In operation 404, at sub-operation 404a, the application of the FRR request in the previous step causes the 3GPP module to establish FRR. UE 422 sends a PDU session modification request with TMM (e.g., an FRR subscription message and an FRR configuration including the IP flow (five-tuple) and the requested FRR report (i.e., bandwidth change).

[0076] At sub-operation 404b, SMF 428 verifies the FRR request to ensure that UE 422 has the ability to request IP flows.

[0077] At sub-operation 404c, SMF 428 sends an N4 / PFCP report request to UPF 430 to configure FRR rules and report.

[0078] At sub-operation 404d, the UPF 430 initializes the control program to report bandwidth changes to the FRR module.

[0079] At sub-operation 404e, UPF 430 sends an N4 / PFCP report response to SMF 428 to confirm the FRR configuration.

[0080] At sub-operation 404f, SMF 428 sends a PDU session modification command with TMM / FRR acknowledgment to UE 422. UE 422 responds to SMF 428 with a PDU session modification complete message.

[0081] In operation 405, the application of UE 422 sends data packets to a remote end (e.g., an application server, a data network (DN)).

[0082] In operation 406, when there is an FRR change, the sequence of messages 406a / 406b / 406c can be repeated.

[0083] At suboperation 406a, the UPF 430 control program modifies the stream shaping characteristics due to policy changes or other utilization changes. The UPF 430 control program notifies the UPF 430's FRR module of the new information (i.e., the new bandwidth).

[0084] At sub-operation 406b, UPF 430 sends a PFCP report response containing new FRR information and an FRR notification with new FRR information to SMF 428.

[0085] At sub-operation 406c, SMF 428 associates the PFCP report message with the UE / PDU session and triggers a PDU session modification command containing a TMM:FRR message via the IP flow (five-tuple) and new bandwidth information.

[0086] In Operation 407, the 3GPP modules and OS services in UE 422 notify the application / network services of the new bandwidth. When the application in UE 422 receives the notification, it is responsible for controlling the rate based on the new information. If the application in UE 422 relies on the network services of UE 422 for congestion and rate control, these services incorporate the new bandwidth into the feedback information to manage the transmission rate.

[0087] In operation 408, when the application in UE 422 terminates, release socket extensions or other FRR support.

[0088] In operation 409, the release of FRR support in operation 408 causes the following sub-operations.

[0089] At sub-operation 409a, UE 422 sends a PDU session modification request with a TMM:FRR unsubscribe message.

[0090] At suboperation 409b, SMF 428 verifies that the FRR request to unsubscribe is allowed.

[0091] At sub-operation 409c, SMF 428 sends an NF / PFCP report request with FRR unsubscribe to UPF 430.

[0092] At sub-operation 409d, UPF 430 removes the FRR rules and configurations associated with the flow.

[0093] At sub-operation 409e, UPF 430 sends an N4 / PFCP report response to SMF 428 to confirm the removal of FRR.

[0094] At sub-operation 409f, SMF 428 sends a PDU session modification command to confirm the removal of FRR. UE 422 responds to SMF 428 with a PDU session modification complete message.

[0095] Implementation of User Plane-Based TMM Transport Channel Using Dedicated QoS Streams In this implementation, TMM transport uses a separate QoS stream, which can be referred to as the TMM QoS stream. The TMM QoS stream is distinct from the one or more user data QoS streams it helps manage. On the Uu interface, the data radio bearer (DRB) configured for the TMM QoS stream can be the same as or different from the DRB configured for the associated one or more user data QoS streams.

[0096] Figure 5 illustrates the operational sequence for establishing a TMM channel and FRR using QoS flows, depending on the implementation method.

[0097] In Operation 501, UE 522 registers with AMF 526 as described in Section 4.2.2 of TS 23.502 (Section 5.5 of TS 24.501, GMM Procedure). UE 522 indicates that it can support TMM (and FRR), and AMF 526 confirms TMM support.

[0098] In operation 502, at sub-operation 502a, UE 522 initiates PDU session establishment using the procedure described in Section 4.3 of TS 23.502 (Section 6 of TS 24.501 5GSM Procedure), and AMF 526 selects SMF 528 that supports TMM.

[0099] At sub-operation 502b, SMF 528 selects UPF 530, which supports TMM / FRR, to service the PDU session and sends an N4 / PFCP Session Establishment Request (SE-Req) to establish a PDU session with a separate QoS flow for the TMM QoS flow and one or more associated user data QoS flows. SMF 528 also delegates the FRR authorization rules to UPF 430, which enables UPF 430 to accept / reject FRR requests from the UE.

[0100] The UPF 430 responds with an N4 / PFCP Session Establishment Response (SE-Resp), which contains the QoS flow identifier (ID) of the TMM QoS flow and one or more QoS flow identifiers (QFIs) of the associated user data QoS flow, as well as the GTP tunnel endpoint identifier (TEID) and other parameters of the PDU session.

[0101] At sub-operation 502c, SMF 528 sends a PDU session establishment accept message to UE 522, including information about individual QoS flows.

[0102] At sub-operation 502d, SMF 528 provides the gNB with information (e.g., QoS templates) on the TMM QoS stream and one or more user data QoS streams, and requests the gNB 524 to establish radio resources to meet their QoS requirements.

[0103] At sub-operation 502e, gNB 524 configures one or more DRBs to serve the QoS flows requested by SMF 528 via RRC reconfiguration procedure, and provides QFI-to-DRB mapping rules to UE 522. In one example, gNB 524 configures a single DRB to map to both the TMM QoS flow and the associated user data QoS flow simultaneously. In this example, gNB 524 also configures the SDAP entity to add an SDAP header to all SDAP data PDUs, such that the QFI field in the SDAP header allows the receiver to distinguish which received SDAP SDUs belong to the TMM QoS flow and which belong to the user data QoS flow, so that the receiving SDAP entity can forward the received SDAP SDUs accordingly. In another example, gNB 524 configures a unique DRB for each of the TMM QoS flow and the associated one or more user data QoS flows. In this example, the gNB 524 configures the SDAP entity not to add the SDAP header to any SDAP data PDU in the PDU session because the one-to-one mapping relationship and the configured QFI to DRB mapping rules have enabled the receiver to distinguish which received SDAP SDUs belong to the TMM QoS flow and which belong to the user data QoS flow based on which DRB the SDAP SDU was received through.

[0104] In operation 503, the application in UE 522 is started.

[0105] At sub-operation 503a, if the application in UE 522 is FRR-aware (e.g., a video stream with ABR), the application requests FRR support from the underlying OS service.

[0106] At suboperation 503b, if an application in UE 522 relies on the OS network functions of UE 522 for congestion control (or a service above the kernel, such as in QUIC), the application in UE 522 requests FRR using socket extensions.

[0107] In operation 504, at sub-operation 504a, the FRR request made by the application of UE 522 in the previous operation 503 causes the FRR entity in the UE to initiate an FRR subscription message, and the TMM entity in UE 522 encapsulates the FRR request in a first TMM message. The 3GPP module in UE 522 sends the TMM request to UPF 530 through the TMM QoS flow.

[0108] UPF 530 verifies the FRR subscription request to ensure that UE 522 has the ability to request the IP flow.

[0109] At sub-operation 504b, UPF 530 initializes the control procedure (see Figure 2) to report bandwidth changes to the FRR entity, which generates an FRR to be sent back to the FRR entity in UE 522.

[0110] At sub-operation 504c, the FRR confirmation message is encapsulated in a second TMM message, and the second TMM message is sent to UE 522 via the TMM QOS stream.

[0111] In Operation 505, the application of UE 522 sends data packets to a remote end (e.g., an application server, DN).

[0112] In operation 506, at sub-operation 506a, the control program of UPF 530 modifies the shaping characteristics of the flow due to policy changes or other utilization changes. The control program in UPF 530 notifies the FRR entity in UPF 530 of the new information (i.e., the new bandwidth).

[0113] At sub-operation 506b, the FRR entity in UPF 530 triggers a TMM notification message using an IP flow (e.g., a 5-tuple) and new bandwidth information from another FRR notification message. A TMM response message with FRR information (in the FRR notification message) is then sent to UE 522 via a TMM QoS flow.

[0114] In Operation 507, the 3GPP modules and OS services in UE 522 notify the applications / network services in UE 522 of the new bandwidth. When the application in UE 522 receives the notification, it is responsible for controlling the rate based on the new information. If the application in UE 522 relies on the network services of UE 522 for congestion and rate control, these services incorporate the new bandwidth into the feedback information to manage the transmission rate.

[0115] In operation 508, when the application in UE 522 terminates, release socket extensions or other FRR support.

[0116] In operation 509, the release of FRR support in operation 508 causes the following sub-operations.

[0117] At sub-operation 509a, UE 522 sends a PDU session modification request with a TMM:FRR unsubscribe message.

[0118] At suboperation 509b, SMF 528 verifies that the FRR request to unsubscribe is allowed.

[0119] At sub-operation 509c, SMF 528 sends an NF / PFCP report request with FRR unsubscribe to UPF 530.

[0120] At sub-operation 509d, UPF 530 removes the FRR rules and configurations associated with the flow.

[0121] At sub-operation 509e, UPF 530 sends an N4 / PFCP report response to SMF 528 to confirm the removal of FRR.

[0122] At sub-operation 509f, SMF 528 sends a PDU session modification command to confirm the removal of FRR. UE 522 responds to SMF 528 with a PDU session modification complete message.

[0123] Another example implementation of a user plane-based TMM transport channel using SDAP control PDUs. In this implementation, TMM transport uses an SDAP control PDU to carry TMM messages via the Uu interface (i.e., between the UE and gNB), and uses a new GTP-U extension to carry TMM messages via the N3 interface (i.e., between the gNB and UPF). The SDAP control PDU can be referred to as the SDAP TMM transport control PDU. The GTP-U extension may be new, but is similar to an already defined extension for carrying PDU set information for XR video packets via the N3 interface.

[0124] In this implementation, the SDAP entity adds an SDAP header to each SDAP PDU, allowing the Data / Control (D / C) field within this header to distinguish between SDAP control PDUs and SDAP data PDUs. Currently, the D / C field marks control PDUs and UL SDAP data PDUs on the UL SDAP end, with formats shown in Figures 6A and 6B, respectively. A value of "0" in D / C field 602 indicates that the SDAP PDU is an SDAP control PDU, and a value of "1" in D / C field 604 indicates that the SDAP PDU is an SDAP data PDU.

[0125] To introduce the SDAP TMM transmission control PDU, a new format for the SDAP control PDU was introduced, as shown in Figure 6C. The bits between the D / C field and the QFI field can be defined as the control PDU type (T) field 606. A value of "1" in the T field 606 indicates that the SDAP control PDU is an SDAP TMM transmission control PDU for both UL and DL. A value of "0" in the T field 606 is reserved for DL ​​and indicates for UL that the SDAP control PDU is an SDAP end-marking control PDU, making it backward compatible with the existing format of SDAP end-marking control PDUs on UL, because, as shown in Figure 6A, the R (referring to "reserved") field 603 in the existing format of the SDAP end-marking control PDU is set to the value "0". When the T field is set to "1", the TMM payload field 608 is present in the SDAP control PDU; otherwise, the TMM payload field is not present.

[0126] The existing format of DL SDAP data PDUs is incompatible with the new DL SDAP control PDUs because all bits in the existing DL SDAP data PDU header are used to indicate information related to reflective QoS mapping; therefore, there is no D / C field in the header to distinguish between SDAP data PDUs and SDAP control PDUs. To support TMM transmission in DL, DL SDAP data PDUs also use the format shown in Figure 6B. Therefore, in this implementation, a QoS stream cannot simultaneously support TMM and reflective QoS mapping.

[0127] Figure 7 illustrates a functional view of an enhanced transmitting SDAP entity 702 (shown on the left) and a receiving SDAP entity 704 (shown on the right) for supporting the transmission of TMM messages via Uu (e.g., between a UE and a gNB) or PC5 (e.g., between two UEs) interface 706, according to some implementations. In the transmitting SDAP entity 702, the TMM payload (e.g., retrieved by the gNB (also known as an NG-RAN node) in the GTP-U extended header of a GTP-U packet received from the UPF (for DL) or provided by a higher-level entity in the UE (for UL)) can be encapsulated in an SDAP control PDU (e.g., an SDAP TMM transmission control PDU as described above) and transmitted to the receiving SDAP entity 704 in the UE (for DL) or gNB (for UL). In receiving SDAP entity 704, the TMM payload in the SDAP control PDU is retrieved for DL ​​and forwarded to the TMM entity in the UE for further processing, or forwarded for UL to the GTP-U entity in the gNB for further transmission to the UPF via a GTP-U extended header having a TEID established during the PDU session / TMM channel establishment (see Figures 8A and 8B below).

[0128] Figures 8A and 8B illustrate the operational sequence for establishing TMM transport on TMM RB and TMM GTP-U extensions, depending on the implementation method.

[0129] In operation 801, UE 822 registers with AMF 826 as described in Section 4.2.2 of TS 23.502 (Section 5.5 of TS 24.501, GMM Procedure). UE 822 requests support for TMM, and AMF 826 confirms TMM support.

[0130] In operation 802, at sub-operation 802a, UE 822 initiates PDU session establishment using the procedure described in Section 4.3 of TS 23.502 (Section 6 of TS 24.501 5GSM procedure), and AMF 826 selects SMF 828 that supports TMM.

[0131] At sub-operation 802b, SMF 828 selects UPF 830, which can support QoS-based TMM, and sends an N4 / PFCP request to establish QoS flows for user data transmission and TMM channels.

[0132] The UPF 830 responds with a QoS stream for user data transmission and confirms the TMM channel along with the GTP TEID.

[0133] At sub-operation 802c, SMF 826 sends a PDU session establishment accept message to UE 822, the PDU session establishment accept message having FFR support including an indication of which QFI is used for TMM.

[0134] At sub-operation 802d, SMF 826 requests (R)AN 824 to establish an SDAP control PDU for the TMM channel in the GTP-U extension, the SDAP control PDU having a TEID and an indication of which QFI is for TMM.

[0135] At sub-operation 802e, an RRC reconfiguration process is executed, including SDAP configuration that supports TMM.

[0136] In operation 803, the application in the UE is started.

[0137] If the application is FRR-aware (e.g., a video stream with ABR), the application requests FRR support from the underlying OS service.

[0138] If the application relies on the OS network for congestion control (or services above the kernel, such as in QuIC), the application uses socket extensions to request FRR.

[0139] An application's request for FRR can trigger the initiation of FRR establishment in the 3GPP module of UE 822.

[0140] In operation 804, at sub-operations 804a / 804e, UE 822 sends a user plane TMM request with FRR configuration via (R)AN 824, which includes IP flow (five-tuple) and requested FRR report (i.e., bandwidth change), and sends an SDAP control PDU to (R)AN 824, where it is mapped to GTP-U extension / TEID for transmission to UPF 830.

[0141] At sub-operation 804c, UPF 830 configures FRR rules.

[0142] At suboperation 804b / 804d, UPF 830 verifies the FRR request to ensure that UE 822 is allowed to request the IP flow.

[0143] The UPF 830 initialization control procedure (see Figure 2) reports bandwidth changes to the FRR module in the UPF 830. The UPF 830 responds by indicating that an FRR has been established for the flow.

[0144] In Operation 805, the application of UE 822 sends data packets to a remote end (e.g., an application server, DN).

[0145] In operation 806, at sub-operation 806a, the control program of UPF 830 modifies the shaping characteristics of the flow due to policy changes or other utilization changes. The control program in UPF 830 notifies the FRR module in UPF 830 of the new information (i.e., new bandwidth), thereby triggering a user plane TMM message with FRR information.

[0146] At suboperation 806b, the FRR module in UPF 830 triggers the sending of a user plane TMM notification message with IP flow (five-tuple) and new bandwidth information in the FRR to gNB 824 using a GTP-U extension with TMM / FRR. The TMM notification message is inserted into the SDAP control PDU at gNB 824 for transmission to UE 822.

[0147] In Operation 807, the 3GPP modules and OS services in UE 822 notify the applications / network services in UE 822 of the new bandwidth. When the application receives the notification, it is responsible for controlling the rate based on the new information. If the application relies on the network services of UE 822 for congestion and rate control, these services incorporate the new bandwidth into the feedback information to manage the transmission rate.

[0148] In operation 808, when the application in UE 822 terminates, release socket extensions or other FRR support.

[0149] In operation 809, the release of FRR support in operation 808 causes the following sub-operations.

[0150] At sub-operation 809a, UE 822 sends a PDU session modification request with a TMM:FRR unsubscribe message.

[0151] At suboperation 809b, SMF 828 verifies that the FRR request for unsubscribing is allowed.

[0152] At sub-operation 809c, SMF 828 sends an NF / PFCP report request with FRR unsubscribe to UPF 830.

[0153] At sub-operation 809d, UPF 830 removes the FRR rules and configurations associated with the flow.

[0154] At sub-operation 809e, UPF 830 sends an N4 / PFCP report response to SMF 828 to confirm the removal of FRR.

[0155] At sub-operation 809f, SMF 828 sends a PDU session modification command to confirm the removal of FRR. UE 822 responds to SMF 828 with a PDU session modification complete message.

[0156] Another example implementation of a user plane-based TMM transport channel using a PDCP control PDU is provided. In this first example implementation, a new type of PDCP control PDU (e.g., called a TMM transport control PDU) with the format shown in Figure 9A is introduced, where the D / C field 902 is set to the value "0" to indicate that the PDCP PDU is a PDCP control PDU. When the D / C field 902 is set to "0", the PDU type field 904 indicates the type of control PDU, as shown in Table 1 below. When the PDU type field 904 is set to the value "101", the PDCP control PDU is a PDCP TMM transport control PDU, and the TMM payload field 906 carries TMM messages.

[0157] Table 1. PDU type field values ​​(for the first embodiment)

[0158] In an alternative example implementation, the newly introduced type of PDCP control PDU can be referred to as a general message transmission control PDU, which has the format shown in Figure 9B and the PDU type field 908 defined in Table 2 below. The remaining 4 bits of the first octet are used as the message type field 910 to indicate the type of message carried in the message payload field 912 of the PDCP control PDU. For example, when the message payload field 912 carries a TMM request message, the message type field 910 can be set to "0000"; when the message payload field 912 carries a TMM response message, the message type field 910 can be set to "0001"; and when the message payload field 912 carries a TMM notification message, the message type field 910 can be set to "0010", while other values ​​can be reserved or used for other purposes. For example, when the message payload field 912 carries a TMM message, the message type field 910 can be set to the value "0000". When the message payload field 912 carries PDU set information for XR traffic, the message type field 910 can be set to the value "0001". When the message payload field 912 carries an artificial intelligence / machine learning (AI / ML) control message, the message type field 910 can be set to the value "0010". Other values ​​can be reserved or used to achieve other purposes. In this implementation, the receiving PDCP entity uses the message type value in the header to route the retrieved message payload to the corresponding higher-level entity, such as the TMM entity, XR entity, AI / ML entity, etc.

[0159] Table 2. PDU type field values ​​(for the second embodiment)

[0160] Figure 10 illustrates a functional view of an enhanced transmitting PDCP entity 1002 (shown on the left) and receiving PDCP entity 1004 (shown on the right) for supporting the transmission of TMM messages via a Uu interface (e.g., between the UE and gNB), according to some implementations. In the transmitting PDCP entity 1002, the TMM payload (e.g., retrieved by the gNB in ​​the GTP-U extended header of a GTP-U packet received from the UPF (for DL) or provided by a higher-level entity in the UE (for UL)) is encapsulated in a new PDCP control PDU (e.g., a PDCP TMM transmission control PDU as described above) and transmitted to the receiving PDCP entity 1004 in the UE (for DL) or gNB (for UL). In receiving PDCP entity 1004, the PDCP controls the TMM payload in the PDU to be retrieved for DL ​​and forwarded to the TMM entity in the UE for further processing, or to be forwarded for UL to the GTP-U entity in the gNB for further transmission to the UPF via a GTP-U extended header having a TEID established during the PDU session / TMM channel establishment (see Figures 11A and 11B described below).

[0161] Figures 11A and 11B illustrate the operational sequence for establishing TMM transports on TMM resource blocks (RBs) and TMM GTP-U extensions, depending on the implementation.

[0162] In operation 1101, UE 1122 registers with AMF 1126 as described in Section 4.2.2 of TS 23.502 (Section 5.5 of TS 24.501, GMM Procedure). UE 1122 requests support for TMM, and AMF 1126 confirms TMM support.

[0163] In operation 1102, at sub-operation 1102a, UE 1122 initiates PDU session establishment using the procedure described in Section 4.3 of TS 23.502 (Section 6 of TS 24.501 5GSM procedure), and AMF 1126 selects SMF 1128 that supports TMM.

[0164] At sub-operation 1102b, the SMF selects a UPF 1130 that can support QoS-based TMM and sends an N4 / PFCP request to establish a QoS flow for user data transmission and the TMM channel.

[0165] The UPF 1130 responds with a QoS stream for user data transmission and acknowledges the TMM channel along with the GTP TEID.

[0166] At sub-operation 1102c, SMF 1128 sends a PDU session establishment accept message to UE 1122, the PDU session establishment accept message having FFR support including an indication of which QFI is used for TMM.

[0167] At sub-operation 1102d, SMF 1128 requests (R)AN 1124 to establish an SDAP control PDU for the TMM channel in the GTP-U extension, the SDAP control PDU having a TEID and an indication of which QFI is for TMM.

[0168] At sub-operation 1102e, an RRC reconfiguration process is executed, including SDAP configuration that supports TMM.

[0169] In operation 1103, the application in UE 1102 is started.

[0170] If the application in UE 1102 is FRR-aware (e.g., a video stream with ABR), the application requests FRR support from the underlying OS service in UE 1102.

[0171] If an application in UE 1102 relies on the OS network in UE 1102 for congestion control (or services above the kernel, such as in QuIC), the application uses socket extensions to request FRR.

[0172] The application's request for FRR triggers the initiation of FRR establishment in the 3GPP module of UE 1122.

[0173] In operation 1104, at sub-operations 1104a / 1104e, UE 1122 sends a user plane TMM request with FRR configuration via (R)AN 1124, which includes IP flow (five-tuple) and requested FRR report (e.g., bandwidth change), and sends a PDCP control PDU to (R)AN 1124, where it is mapped to GTP-U extension / TEID for transmission to UPF 1130.

[0174] At sub-operation 1104c, UPF 1130 configures the FRR rule.

[0175] At sub-operation 1104b / 1104d, UPF 1130 verifies the FRR request to ensure that UE 1122 is allowed to request the IP flow.

[0176] The UPF 1130 initialization control procedure (see Figure 2) reports bandwidth changes to the FRR module in the UPF 1130.

[0177] UPF 1130 responded by indicating that an FRR was established for the flow.

[0178] In operation 1105, the application of UE 1122 sends data packets to a remote end (e.g., application server, DN).

[0179] In operation 1106, at sub-operation 1106a, the control program of UPF 1130 modifies the shaping characteristics of the flow due to policy changes or other utilization changes. The control program notifies the FRR module in UFP 1130 of the new information (i.e., new bandwidth), thereby triggering a user plane TMM message with FRR information.

[0180] At sub-operation 1106b, the FRR module in UPF 1130 triggers the sending of a user plane TMM notification message with IP flow (five-tuple) and new bandwidth information in FRR to gNB 1124 using the GTP-U extension with TMM / FRR.

[0181] At sub-operation 1106c, the TMM notification message is inserted into the PDCP control PDU at gNB 1124 so that it can be transmitted to UE 1122.

[0182] In Operation 1107, the 3GPP modules and OS services in UE 1122 notify the applications / network services in UE 1122 of the new bandwidth. When the application receives the notification, it is responsible for controlling the rate based on the new information. If the applications in UE 1122 rely on the network services of UE 1122 for congestion and rate control, these services incorporate the new bandwidth into the feedback information to manage the transmission rate.

[0183] In operation 1108, when the application in UE 1122 terminates, release socket extensions or other FRR support.

[0184] In operation 1109, the release of FRR support in operation 1108 causes the following sub-operations.

[0185] At sub-operation 1109a, UE 1122 sends a PDU session modification request with a TMM:FRR unsubscribe message.

[0186] At sub-operation 1109b, SMF 1128 verifies that the FRR request to unsubscribe is allowed.

[0187] At sub-operation 1109c, SMF 1128 sends an NF / PFCP report request with FRR unsubscribe to UPF 1130.

[0188] At sub-operation 1109d, UPF 1130 removes the FRR rules and configurations associated with the flow.

[0189] At sub-operation 1109e, UPF 1130 sends an N4 / PFCP report response to SMF 1128 to confirm the removal of FRR.

[0190] At sub-operation 1109f, SMF 1128 sends a PDU session modification command to confirm the removal of FRR. UE 1122 responds to SMF 1128 with a PDU session modification complete message.

[0191] Figure 12A illustrates a flowchart of a method 1200 executed by a communication device according to some implementations. The communication device may include computer-readable code or instructions executable on one or more processors of the communication device. In consideration of the present invention, the coding of software for performing or executing method 1200 is entirely within the scope of those skilled in the art. Method 1200 may include more or fewer operations than those shown and described, and may be performed or executed in different orders. The computer-readable code or instructions of the software executable by one or more processors may be stored on a non-transitory computer-readable medium such as the memory of the communication device. In some implementations, method 1200 may be executed by one or more units or modules of the communication device (e.g., integrated circuits), such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0192] At operation 1202 of method 1200, the communication equipment uses a traffic management and monitoring (TMM) transport container to transmit transport management messages for flow regulation reports (FRR) based on extensions to the third generation partnership project (3GPP) control plane channels or 3GPP user plane channels. The user plane function (UPF) network entity provides the user equipment (UE) with bandwidth or other flow conditions between the UPF network entity and the UE.

[0193] Depending on the implementation, the communication device can be either a UPF network entity or a UE.

[0194] Depending on some implementations, transport management messages may include commands to UPF network entities for end-to-end (E2E) Internet Protocol (IP) flows belonging to a Protocol Data Unit (PDU) session of a UE.

[0195] Depending on the implementation, the session management function (SMF) network entity can authorize flow conditioning request messages for FRR based on the policy or ownership of the E2E IP flow belonging to the PDU session of the UE.

[0196] Depending on the implementation, the SMF network entity may delegate the authorization of flow conditioning request messages for FRR to the UPF network entity based on the policy or ownership of the E2E IP flow belonging to the PDU session of the UE.

[0197] Depending on the implementation, the transport management message used for FRR can indicate changes to the bandwidth constraints of an E2E IP flow.

[0198] Depending on the implementation, the communication device can be a UE (User Equipment). Applications within the UE may be eligible to request changes to flow conditioning attributes. When an application starts, it can initiate the establishment of a Flow Conditioning Attribute (FRR) within the UE to request changes to flow conditioning attributes from the network device properties.

[0199] Depending on the implementation, applications in the UE can determine whether they are eligible to request changes in flow conditioning attributes from the network device based on the UE route selection policy (URSP).

[0200] According to some implementation methods, the UE can determine the application corresponding to the transmission management message used for FRR based on IP flow information, which includes the quintuple of the E2P IP flow.

[0201] Depending on the implementation, the communication device can be a UPF network entity. The UPF network entity can configure FRR, which instructs the UPF network entity's control procedures to change E2E stream shaping or scheduling attributes. The UPF network entity can send or receive transport management messages for FRR.

[0202] Depending on the implementation, the TMM transport container can use non-access stratum (NAS) message extensions between the UE and the SMF network entity, and packet forwarding control protocol (PFCP) extensions between the SMF network entity and the UPF network entity.

[0203] Depending on the implementation, the TMM transport container can be located in one of the following: (i) a dedicated quality of service (QoS) stream, (ii) a service data adaptation protocol (SDAP) control channel, or (iii) a packet data convergence protocol (PDCP) control protocol data unit (PDU).

[0204] Depending on the implementation, the TMM transport container can be carried in a dedicated QoS stream that is separate from the user data QoS stream.

[0205] Depending on the implementation, dedicated QoS streams and user data QoS streams can be mapped to a single data radio bearer (DRB).

[0206] Depending on the implementation, dedicated QoS streams and user data QoS streams can be mapped to separate data radio bearers (DRBs).

[0207] Depending on the implementation, the TMM transport container can be carried within an SDAP control PDU. The SDAP control PDU may include a control PDU type field indicating that the SDAP control PDU is an SDAP TMM transport control PDU.

[0208] Depending on the implementation, the TMM transport container can be carried in a PDCP control PDU. The PDCP control PDU may include a PDU type field indicating that the PDCP control PDU is a TMM transport control PDU. Alternatively, the PDCP control PDU may be a generic message transport control PDU, including a message type field indicating the message type carried in the message payload field.

[0209] Depending on the implementation, bandwidth or other flow conditions can be carried in the TMM transport container. The UPF network entity can provide the TMM transport container to the UE, such that the UPF network entity provides the TMM transport container directly to the UE without any other network entity relaying the TMM transport container, or the UPF network entity provides the TMM transport container to the UE through a second network entity without the second network entity modifying the TMM transport container.

[0210] Depending on some implementation methods, the second network entity can be an SMF network entity.

[0211] Depending on the implementation method, extensions to the 3GPP control plane channels or 3GPP user plane can be implemented at a layer lower than the IP layer.

[0212] Figure 12B illustrates a flowchart of method 1210 executed by a communication device according to some implementations. The communication device may include computer-readable code or instructions executable on one or more processors of the communication device. In consideration of the present invention, the coding of software for performing or executing method 1210 is entirely within the scope of those skilled in the art. Method 1210 may include more or fewer operations than those shown and described, and may be performed or executed in different orders. The computer-readable code or instructions of the software executable by one or more processors may be stored on a non-transitory computer-readable medium such as the memory of the communication device. In some implementations, method 1210 may be executed by one or more units or modules (e.g., integrated circuits) of the communication device, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0213] At operation 1212 of method 1210, the communication device uses a transport container for carrying Internet Protocol (IP) streams and traffic management information to communicate between user equipment (UE) and user plane function (UPF) network entities. The transport container uses non-access stratum (NAS) message extensions between the UE and the session management function (SMF) network entity, and uses packet forwarding control protocol (PFCP) extensions between the SMF and UPF network entities.

[0214] Depending on the implementation, the communication device can be either a UPF network entity or a UE.

[0215] Figure 12C illustrates a flowchart of method 1220 performed by a communication device according to some implementations. The communication device may include computer-readable code or instructions executable on one or more processors of the communication device. In consideration of the present invention, the coding of software for performing or executing method 1220 is entirely within the scope of those skilled in the art. Method 1220 may include more or fewer operations than those shown and described, and may be performed or executed in different orders. The computer-readable code or instructions of the software executable by one or more processors may be stored on a non-transitory computer-readable medium such as the memory of the communication device. In some implementations, method 1220 may be executed by one or more units or modules of the communication device (e.g., integrated circuits), such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0216] At operation 1222 of method 1220, the communication equipment uses a transport container for carrying Internet Protocol (IP) streams and traffic management information to communicate between user equipment (UE) and user plane function (UPF) network entities. The transport container is located in one of the following: (i) a dedicated quality of service (QoS) stream, (ii) a service data adaptation protocol (SDAP) control channel, or (iii) a packet data convergence protocol (PDCP) control protocol data unit (PDU).

[0217] Depending on the implementation, the communication device can be either a UPF network entity or a UE.

[0218] The following references are incorporated herein by reference.

[0219] - 3GPP TS 23.501: System Architecture of 5G System (5GS) https: / / www.3gpp.org / ftp / Specs / archive / 23_series / 23.501 / 23501-i22.zip - 3GPP TS 23.502: Flowchart of 5G System (5GS) https: / / www.3gpp.org / ftp / Specs / archive / 23_series / 23.502 / 23502-i20.zip - 3GPP SP-231198: Research on XRM Phase 2 Architecture Enhancements - 3GPP TS 29.281: General Packet Radio System (GPRS) Tunneling Protocol User Plane (GTPv1-U) https: / / www.3gpp.org / ftp / Specs / archive / 29_series / 29.281 / 29281-h40.zip - 3GPP TS 24.501: Non-access stratum protocol for 5G System (5GS), Phase 3 https: / / www.3gpp.org / ftp / Specs / archive / 24_series / 24.501 / 24501-i40.zip - 3GPP TS 38.413 NG-RAN; NG Application Protocol (NGAP) https: / / www.3gpp.org / ftp / Specs / archive / 38_series / 38.413 / 38413-i10.zip - SA2 Rel-19 23Q4 Moderated Discussion – Traffic Management / Monitoring – Version 0.0.1 https: / / nwm-trial.etsi.org / # / documents / 8671 - IETF Draft, “Network Collaboration Signaling Requirements”, https: / / datatracker.ietf.org / doc / draft-kwbdgrr-tsvwg-net-collab-rqmts / Figure 13 illustrates an example communication system 1300. Communication system 1300 includes an access node 1310 that serves user equipment (UE), such as UE 1320, with coverage area 1301. In a first operating mode, communication to and from the UE passes through access node 1310 with coverage area 1301. Access node 1310 connects to backhaul network 1315 for internet access, operation, and management, etc.In the second operating mode, communication to and from the UE does not pass through access node 1310; however, access node 1310 typically allocates resources for UE communication when certain conditions are met. Communication between a pair of UEs 1320 can use a sidelink connection (shown as two separate unidirectional connections 1325). In Figure 13, sidelink communication occurs between two UEs operating within coverage area 1301. However, sidelink communication can also typically occur when both UEs 1320 are outside coverage area 1301; both UEs 1320 are within coverage area 1301; or one UE 1320 is within coverage area 1301 and the other UE 1320 is outside coverage area 1301. Communication between the UE and the access node pair is conducted via a unidirectional communication link, where the communication link between the UE and the access node is called uplink 1330, and the communication link between the access node and the UE is called downlink 1335.

[0220] Access nodes are also commonly referred to as base stations (NodeB), evolved NodeBs (eNB), next-generation (NG) NodeBs (gNB), master eNBs (MeNB), secondary eNBs (SeNB), master gNBs (MgNB), secondary gNBs (SgNB), network controllers, control nodes, base stations, access points, transmission points (TP), transmission-reception points (TRP), cells, carriers, macro cells, femtocells, picocells, etc., while UEs are also commonly referred to as mobile stations, handsets, terminals, users, subscribers, sites, etc. Access nodes can provide wireless access according to one or more wireless communication protocols, such as 3GPP Long Term Evolution (LTE), LTE Advanced (LTE-A), 5G, 5G LTE, 5G NR, Sixth Generation (6G), High Speed ​​Packet Access (HSPA), and IEEE 802.11 series standards, such as 802.11a / b / g / n / ac / ad / ax / ay / be, etc. While it is understood that a communication system could employ multiple access nodes capable of communicating with several UEs, for simplicity, only one access node and two UEs are shown.

[0221] Figure 14 illustrates an example communication system 1400. Typically, system 1400 enables multiple wireless or wired users to send and receive data and other content. System 1400 may implement one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), or non-orthogonal multiple access (NOMA).

[0222] In this example, the communication system 1400 includes electronic devices (EDs) 1410a to 1410c, radio access networks (RANs) 1420a and 1420b, a core network 1430, a public switched telephone network (PSTN) 1440, the Internet 1450, and other networks 1460. Although Figure 14 shows a number of these components or elements, the system 1400 may include any number of these components or elements.

[0223] EDs 1410a to 1410c are used for operation or communication within system 1400. For example, EDs 1410a to 1410c are used for transmitting or receiving via wireless or wired communication channels. Each ED 1410a to 1410c represents any suitable end-user equipment and may include (or be referred to as) devices such as: user equipment (UE), wireless transmit or receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, personal digital assistant (PDA), smartphone, laptop computer, computer, touchpad, wireless sensor, or consumer electronics device.

[0224] Here, RAN 1420a includes base station 1470a, and RAN 1420b includes base station 1470b. Each base station 1470a and 1470b is used to radio interfacing with one or more of ED 1410a to 1410c to enable access to the core network 1430, PSTN 1440, Internet 1450, or other networks 1460. For example, base stations 1470a and 1470b may include (or may be) one or more of several well-known devices, such as a base transceiver station (BTS), Node-B (NodeB), evolved NodeB (eNB), Next Generation (NG) NodeB (gNB), gNB centralized unit (gNB-CU), gNB distributed unit (gNB-DU), Home NodeB, Home eNodeB, site controller, access point (AP), or wireless router. ED 1410a to 1410c are used for interfacing and communicating with the Internet 1450 and can access the core network 1430, PSTN 1440 or other networks 1460.

[0225] In the embodiment shown in Figure 14, base station 1470a forms part of RAN 1420a, which may include other base stations, components, or devices. Similarly, base station 1470b forms part of RAN 1420b, which may include other base stations, components, or devices. Each base station 1470a and 1470b is used to transmit or receive radio signals within a specific geographical area (sometimes referred to as a "cell"). In some embodiments, multiple-input multiple-output (MIMO) technology may be employed, which equips each cell with multiple transceivers.

[0226] Base stations 1470a and 1470b communicate with one or more of ED 1410a to 1410c via one or more air interfaces 1490 using a wireless communication link. Air interface 1490 can use any suitable wireless access technology.

[0227] It is conceivable that system 1400 can use multi-channel access capabilities, including the schemes described above. In specific embodiments, the base station and ED implement 5G New Radio (NR), LTE, LTE-A, or LTE-B. Of course, other multiple access schemes and radio protocols can also be utilized.

[0228] RANs 1420a and 1420b communicate with core network 1430 to provide voice, data, application, Voice over Internet Protocol (VoIP), or other services to EDs 1410a through 1410c. It should be understood that RANs 1420a and 1420b or core network 1430 can communicate directly or indirectly with one or more other RANs (not shown). Core network 1430 can also serve as a gateway access for other networks (e.g., PSTN 1440, Internet 1450, and other networks 1460). Furthermore, some or all of EDs 1410a through 1410c can communicate with different wireless networks via different wireless links using different wireless technologies or protocols. EDs can communicate with service providers or switches (not shown) and with Internet 1450 via wired communication channels, rather than wirelessly (or as a supplement to wireless communication).

[0229] Although Figure 14 shows an example of a communication system, various modifications can be made to Figure 14. For example, in any suitable configuration, the communication system 1400 can include any number of EDs, base stations, networks, or other components.

[0230] Figures 15A and 15B illustrate example devices that can implement the methods and teachings according to the present invention. Specifically, Figure 15A shows example ED 1510, and Figure 15B shows example base station 1570. These components can be used in system 1400 or any other suitable system.

[0231] As shown in Figure 15A, ED 1510 includes at least one processing unit 1500. The processing unit 1500 implements various processing operations of ED 1510. For example, the processing unit 1500 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables ED 1510 to operate in system 1400. The processing unit 1500 also supports the methods and teachings described in detail above. Each processing unit 1500 includes any suitable processing or computing device for performing one or more operations. For example, each processing unit 1500 may include a microprocessor, microcontroller, digital signal processor, field-programmable gate array, or application-specific integrated circuit.

[0232] ED 1510 also includes at least one transceiver 1502. Transceiver 1502 is used to modulate data or other content for transmission by at least one antenna or network interface controller (NIC) 1504. Transceiver 1502 is also used to demodulate data or other content received by at least one antenna 1504. Each transceiver 1502 includes any suitable structure for generating signals for wireless or wired transmission or for processing signals received wirelessly or wiredly. Each antenna 1504 includes any suitable structure for transmitting or receiving wireless or wired signals. One or more transceivers 1502 and one or more antennas 1504 may be used in ED 1510. Although transceiver 1502 is shown as a single functional unit, it can also be implemented using at least one transmitter and at least one separate receiver.

[0233] ED 1510 also includes one or more input / output devices 1506 or interfaces (such as a wired interface to the Internet 1450). Input / output devices 1506 facilitate interaction with users or other devices on the network (network communication). Each input / output device 1506 includes any suitable structure for providing or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touchscreen, including network interface communication.

[0234] In addition, ED 1510 includes at least one memory 1508. Memory 1508 stores instructions and data used, generated, or collected by ED 1510. For example, memory 1508 may store software or firmware instructions executed by one or more processing units 1500, as well as data for reducing or eliminating interference in incoming signals. Each memory 1508 includes any suitable one or more volatile or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, and secure digital (SD) card, etc.

[0235] As shown in Figure 15B, base station 1570 includes at least one processing unit 1550, at least one transceiver 1552 (which includes transmitter and receiver functions), one or more antennas 1556, at least one memory 1558, and one or more input / output devices or interfaces 1566. A scheduler, as understood by those skilled in the art, is coupled to processing unit 1550. The scheduler may be included within base station 1570 or may operate separately from base station 1570. Processing unit 1550 implements various processing operations of base station 1570, such as signal encoding, data processing, power control, input / output processing, or any other functions. Processing unit 1550 may also support the methods and instructions detailed above. Each processing unit 1550 includes any suitable processing or computing device for performing one or more operations. For example, each processing unit 1550 may include a microprocessor, microcontroller, digital signal processor, field-programmable gate array, or application-specific integrated circuit.

[0236] Each transceiver 1552 includes any suitable structure for generating signals for wireless or wired transmission with one or more EDs or other devices. Each transceiver 1552 also includes any suitable structure for processing signals received wirelessly or wiredly from one or more EDs or other devices. Although the transmitter and receiver are shown combined as transceiver 1552, they can be separate components. Each antenna 1556 includes any suitable structure for transmitting or receiving wireless or wired signals. Although a shared antenna 1556 is shown herein coupled to transceiver 1552, one or more antennas 1556 can be coupled to one or more transceivers 1552, thus supporting separate antennas 1556 coupled to the transmitter and receiver (when the transmitter and receiver are configured as separate components). Each memory 1558 includes any suitable one or more volatile or non-volatile storage and retrieval devices. Each input / output device 1566 facilitates interaction with users or other devices in the network (network communication). Each input / output device 1566 includes any suitable structure for providing information to or receiving / providing information from users, including network interface communication.

[0237] Figure 16 is a block diagram of a computing system 1600 that can be used to implement the devices and methods disclosed herein. For example, the computing system can be any entity in a UE, access network (AN), mobility management (MM), session management (SM), user plane gateway (UPGW), or access stratum (AS). A particular device may utilize all or only a subset of the components shown, and the level of integration may vary from device to device. Furthermore, the device may include multiple instances of components, such as multiple processing units, multiple processors, multiple memories, multiple transmitters, multiple receivers, etc. The computing system 1600 includes a processing unit 1602. The processing unit includes a central processing unit (CPU) 1614, memory 1608, and may also include a mass storage device 1604 connected to a bus 1620, a video adapter 1610, and an I / O interface 1612.

[0238] Bus 1620 can be one or more of several bus architectures of any type, including a memory bus or memory controller, a peripheral bus, or a video bus. CPU 1614 can include any type of electronic data processor. Memory 1608 can include any type of non-transitory system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or combinations thereof. In an embodiment, memory 1608 may include ROM for use at boot time and DRAM for storing programs and data for use during program execution.

[0239] Mass storage 1604 may include any type of non-transitory storage device for storing data, programs, and other information, and making such data, programs, and other information accessible via bus 1620. Mass storage 1604 may include one or more of a solid-state drive, hard disk drive, disk drive, or optical disk drive.

[0240] Video adapter 1610 and I / O interface 1612 provide interfaces for coupling external input and output devices to processing unit 1602. Examples of input and output devices, as shown, include a display 1618 coupled to video adapter 1610 and a mouse, keyboard, or printer 1616 coupled to I / O interface 1612. Other devices may be coupled to processing unit 1602, and more or fewer interface cards may be used. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to interface external devices.

[0241] The processing unit 1602 also includes one or more network interfaces 1606, which may include wired links such as Ethernet cables or wireless links for accessing nodes or different networks. The network interface 1606 enables the processing unit 1602 to communicate with remote units via a network. For example, the network interface 1606 may provide wireless communication via one or more transmitter / transmit antennas and one or more receiver / receive antennas. In embodiments, the processing unit 1602 is coupled to a local area network 1622 or a wide area network for data processing and communication with remote devices (such as other processing units, the Internet, or remote storage facilities).

[0242] It should be understood that one or more steps of the methods in the embodiments provided herein can be performed by corresponding units or modules. For example, a signal can be sent by a sending unit or sending module. A signal can be received by a receiving unit or receiving module. A signal can be processed by a processing unit or processing module. Other steps can be performed by: an execution unit or module, a generation unit or module, an acquisition unit or module, a setting unit or module, an adjustment unit or module, an addition unit or module, a reduction unit or module, a determination unit or module, a modification unit or module, a reduction unit or module, a deletion unit or module, or a selection unit or module. The corresponding units / modules can be hardware, software, or a combination thereof. For example, one or more of these units or modules can be integrated circuits, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0243] While this specification has been described in detail, it should be understood that various changes, substitutions, and modifications can be made without departing from the spirit and scope of the invention as defined by the appended claims. Furthermore, the scope of the invention is not intended to be limited to the specific embodiments described herein, as those skilled in the art will readily recognize from the invention that existing or later-developed processes, machines, articles of manufacture, material components, elements, methods, or steps can perform substantially the same functions or achieve substantially the same results as the corresponding embodiments described herein. Therefore, the appended claims are intended to include such processes, machines, articles of manufacture, material components, elements, methods, or steps within their scope.

Claims

1. A method, characterized in that, include: The communication equipment is configured with a TMM transport channel for traffic management and monitoring TMM message transmission between the User Equipment (UE) and the User Plane Function (UPF) network entity. The communication equipment transmits TMM messages through the TMM transport channel, wherein the TMM transport channel is a user plane-based transport channel that uses a TMM Quality of Service (QoS) flow, which is different from the user data QoS flow used for user data transmission, or the user plane-based transport channel uses a Data Radio Bearer (DRB) between the UE and the base station and a General Packet Radio Service Tunneling Protocol (GTP) user GTP-U protocol between the base station and the UPF network entity.

2. The method according to claim 1, characterized in that, The TMM transmission channel is a user plane-based transmission channel using the DRB and the GTP-U protocol, and the communication device is one of the UPF network entity, the UE, or the base station.

3. The method according to claim 1 or 2, characterized in that, The TMM message is encapsulated in a GTP-U extended header, which has a GTP tunnel endpoint identifier (TEID) corresponding to the TMM transport channel used for TMM message transmission.

4. The method according to any one of claims 1 to 3, characterized in that, The TMM message is encapsulated in a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU). The PDCP control PDU includes a PDU type field, which indicates the type of PDU transmitted by the TMM.

5. The method according to any one of claims 1 to 4, characterized in that, The TMM message is encapsulated in a Service Data Adaptation Protocol (SDAP) control PDU, which includes a header having a field indicating that the SDAP control PDU belongs to the TMM transport channel.

6. The method according to claim 1, characterized in that, The TMM transport channel is the user plane-based transport channel using the TMM QoS flow, and the communication device is the UPF network entity or the UE.

7. The method according to any one of claims 1 to 6, characterized in that, The TMM message includes a transmission management message used for Flow Regulation Report (FRR).

8. The method according to claim 7, characterized in that, The method further includes: the UE's ability to interact with the core network to support the TMM and the FRR.

9. The method according to claim 7 or 8, characterized in that, The method further includes: the UPF network entity configuring the FRR, the FRR instructing the control program of the UPF network entity to change the end-to-end E2E flow shaping or scheduling attributes; the UPF network entity sending or receiving the TMM message for the FRR.

10. The method according to any one of claims 7 to 9, characterized in that, The transmission management message used for the FRR indicates a change in bandwidth constraints for the bandwidth or E2E Internet Protocol IP flow between the UE and the UPF network entity.

11. The method according to any one of claims 7 to 10, characterized in that, Also includes: The UE determines the application corresponding to the transmission management message used for the FRR based on the IP flow information, which includes a quintuple of E2E IP flows.

12. A method, characterized in that, include: The communication equipment is configured with a TMM channel for traffic management and monitoring of TMM transmission between the User Equipment (UE) and the User Plane Function (UPF) network entity; the communication equipment transmits TMM messages through a transmission channel, wherein the transmission channel is a control plane-based transmission channel, and the control plane-based transmission channel uses non-access stratum (NAS) signaling between the UE and the Session Management Function (SMF) network entity and the Packet Forwarding Control Protocol (PFCP) between the SMF network entity and the UPF network entity.

13. The method according to claim 12, characterized in that, The communication device is one of the UPF network entity, the UE, or the SMF network entity.

14. The method according to claim 12 or 13, characterized in that, The TMM message includes a transmission management message used for Flow Regulation Report (FRR).

15. The method according to claim 14, characterized in that, The method further includes: the UE's ability to interact with the core network to support the TMM and the FRR.

16. The method according to claim 14 or 15, characterized in that, The method further includes: the UPF network entity configuring the FRR, the FRR instructing the control program of the UPF network entity to change the end-to-end E2E flow shaping or scheduling attributes; the UPF network entity sending or receiving the TMM message for the FRR.

17. The method according to any one of claims 14 to 16, characterized in that, The SMF network entity authorizes the flow conditioning request message for the FRR based on the policy or ownership of the E2E Internet Protocol IP flow belonging to the PDU session of the UE.

18. A communication device, characterized in that, include: At least one processor; a non-transitory computer-readable storage medium storing a program comprising instructions that, when executed by the at least one processor, cause the communication device to perform the method according to any one of claims 1 to 11.

19. A communication device, characterized in that, include: At least one processor; a non-transitory computer-readable storage medium storing a program comprising instructions that, when executed by the at least one processor, cause the communication device to perform the method according to any one of claims 12 to 17.

20. A non-transitory computer-readable medium, characterized in that, It stores instructions that, when executed by the device, cause the device to perform the method according to any one of claims 1 to 11.

21. A non-transitory computer-readable medium, characterized in that, It stores instructions that, when executed by the device, cause the device to perform the method according to any one of claims 12 to 17.

Images