Method and apparatus for performing a performance measurement function protocol procedure using an evolved packet data gateway in mobile communications
By maintaining consistency in packet counts between user equipment and network nodes, the problem of inconsistent packet counts in ePDG scenarios in mobile communications is solved, achieving accuracy and robustness in packet loss rate measurement.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- MEDIATEK INC
- Filing Date
- 2024-11-06
- Publication Date
- 2026-06-05
AI Technical Summary
In mobile communications, when user equipment and network equipment use ePDG for PMFP procedures, there are issues related to the accuracy of packet counting, especially in untrusted non-3GPP access networks. Existing technologies cannot ensure the consistency of packet counting between the user equipment and network sides.
By maintaining a consistent packet counting granularity between user equipment and network nodes, packet loss rate is ensured to be counted across the entire PDN connection during PLR measurement. This is achieved using PMFP procedures on ePDG and cellular links, with PMFP request and report messages used for packet loss rate measurement.
It achieves accuracy and consistency in packet counting in ePDG scenarios, ensures robust operation of PLR measurement process, and improves the accuracy of performance measurement function protocols in mobile communication.
Smart Images

Figure CN122162430A_ABST
Abstract
Description
[0001] Cross-referencing This application is part of a non-provisional application claiming priority to U.S. Patent Application No. 63 / 596,333, filed November 6, 2023, the contents of which are incorporated herein by reference in their entirety. Technical Field
[0002] This invention generally relates to mobile communications, and more specifically, to the process by which user equipment (UE) and network equipment in mobile communications perform a performance measurement function protocol (PMFP) using an enhanced packet data gateway (ePDG). Background Technology
[0003] Unless otherwise stated, the methods described in this section are not considered prior art in the claims, nor are they considered prior art by virtue of their inclusion in this section.
[0004] Access Service Setup, Handover, and Offloading (ATSSS) is a feature in the 3GPP standard that enables service setup across multiple access points, including 3GPP access points (e.g., 5G cellular networks) and non-3GPP access points (e.g., WiFi networks). User equipment (UEs) with ATSSS capability can establish Packet Data Network (PDN) connections over untrusted non-3GPP access networks as user plane resources for Multiple Access Protocol Data Unit (MA PDU) sessions. Simultaneously, MA PDU sessions can selectively establish user plane resources on 3GPP access networks. An interface called Enhanced Packet Data Gateway (ePDG) is used between the 5G core network and untrusted non-3GPP access networks to provide access control, data forwarding, security, mobility management, and Quality of Service (QoS) management functions. In 3GPP Release 18, two scenarios are provided for ePDG. In one scenario, only an IPsec Security Association (SA) is established between the UE and the ePDG, which is used to transmit the default bearer and all dedicated bearers established between the ePDG and the Packet Data Network Gateway (PDN-GW) via S2b. In the second scenario, the UE and ePDG support establishing a separate IPsec child security association (child SA) for each dedicated S2b bearer to transmit services on the dedicated bearer, while the primary IPsec security association is used to transmit services on the default bearer. Since the PDN-GW cannot know the specific scenario adopted by the ePDG, some PMFP procedures related to packet counting may not execute correctly on the UE and network sides. Therefore, appropriate solutions are needed to address these issues. Summary of the Invention
[0005] The following overview is illustrative only and is not intended to be limiting in any way. That is, it is provided to introduce the concept, key points, benefits, and advantages of the novel and non-obvious techniques described in this invention. Selected implementations are further described in the detailed description below. Therefore, the following overview is not intended to identify essential features of the claimed subject matter, nor is it intended to define the scope of the claimed subject matter.
[0006] One objective of this invention is to propose a solution or method for addressing problems related to the PMFP process of user equipment and network equipment utilizing ePDG in mobile communications.
[0007] In one aspect, a method may involve a device establishing a packet data network connection. The method may also involve the device sending a PMFP request message related to a PMFP procedure to a network node. The method may further involve the device counting uplink packets transmitted over the entire PDN connection. The method may further involve the device receiving a PMFP report message from the network node. The PMFP report message may include the number of received UL packets counted by the network node.
[0008] In one aspect, an apparatus may include a transceiver that wirelessly communicates with a network node during operation. The apparatus may also include a processor communicatively coupled to the transceiver. During operation, the processor may perform operations including establishing a PDN connection via the transceiver. The processor may also perform operations including sending a PMFP request message related to a PMFP process to the network node via the transceiver. The processor may further perform operations including counting UL packets transmitted throughout the PDN connection. The processor may further perform operations including receiving a PMFP report message from the network node via the transceiver. The PMFP report message may include the number of UL packets received, counted by the network node.
[0009] In another aspect, one method may involve a network node sending a PMFP request message related to the PMFP procedure to the UE. The method may also involve the network node counting DL packets transmitted over the entire PDN connection. The method may further involve the network node receiving a PMFP report message from the UE. The PMFP report message may include the number of DL packets received, counted by the UE.
[0010] It is worth noting that while the descriptions provided herein can be used in the context of certain radio access technologies, networks, and network topologies, such as LTE, LTE Advanced, LTE Advanced Pro, 5G, NR, IoT, NB-IoT, IIoT, B5G, and 6G, the proposed concepts, schemes, and any variations / derivatives thereof can be implemented in, used in, and by other types of radio access technologies, networks, and network topologies. Therefore, the scope of the invention is not limited to the examples described herein. Attached Figure Description
[0011] The accompanying drawings contain information for a further understanding of the invention and are incorporated into and constitute a part of the invention. These drawings illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. It is worth noting that the drawings are not necessarily drawn to scale, as some components may be shown out of proportion to their actual size in order to clearly illustrate the concepts of the invention.
[0012] Figure 1 This is an example scenario of a communication environment in which various solutions and schemes of the present invention can be implemented.
[0013] Figure 2A This is an example scenario where each PDN connection corresponds to a single IPSec SA according to an embodiment of the present invention.
[0014] Figure 2B This is an example scenario where each S2b bearer corresponds to a single IPSec SA according to an embodiment of the present invention.
[0015] Figure 3 This is an example communication system according to an embodiment of the present invention.
[0016] Figure 4 This is an example process according to an embodiment of the present invention.
[0017] Figure 5 This is another example process according to an embodiment of the present invention. Detailed Implementation
[0018] This invention discloses detailed embodiments and implementations of the claimed subject matter. However, it should be understood that the inventive embodiments and implementations are merely illustrative of the claimed subject matter, which can be implemented in various forms. Moreover, the invention can be implemented in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided to make the specification of this invention comprehensive and complete, and to fully convey the scope of the invention to those skilled in the art. In the following description, details of known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.
[0019] Overview The embodiments of this invention relate to various techniques, methods, schemes, and / or solutions regarding the PMFP process when using ePDG in mobile communications, ensuring consistency in packet counting granularity between the user equipment and the network side. According to this invention, multiple possible solutions can be implemented individually or in combination. That is, although these possible solutions are described separately below, two or more possible solutions can be implemented in some combination.
[0020] Figure 1 This is an example scenario of a communication environment where various solutions and schemes according to embodiments of the present invention can be implemented. In scenario 100, the ATSSS function can be supported by UE 110 and User Plane Function (UPF) 120. The ATSSS function implements a Multiple Access Protocol Data Unit (MA PDU) connectivity service, which can exchange PDUs between UE 110 and data network 130 by simultaneously using 3GPP access network 140 and non-3GPP access network 150. The MA PDU connectivity service is implemented by establishing an MA PDU session. That is, the PDU session can have user plane resources on both 3GPP access network 140 and non-3GPP access network 150. In one embodiment, 3GPP access network 140 may include one or more base stations (e.g., gNB / eNB) providing radio access to UE 110 through various 3GPP Radio Access Technologies (RATs), including but not limited to 6G, 5G, 4G, and 3G / 2G, while non-3GPP access network 150 may include access points (APs) providing radio access to UE 110 through non-3GPP RATs (such as WiFi). For non-3GPP access, the enhanced packet data gateway (ePDG) acts as a key intermediary in cellular networks (e.g., LTE / 5G networks) to ensure secure and seamless connectivity between the cellular core network and the non-3GPP access network 150.
[0021] In scenario 100, the PMFP procedure can be performed between Performance Measurement Function (PMF) 115 in UE 110 and PMF 125 in UPF 120 to measure the performance between PMFs 115 and 125. The PMFP procedure can be performed on ePDG links and / or cellular links (e.g., 3GPP NR links, Packet Data Network (PDN) links). For example, when a PDN connection is established as a user plane resource for a multi-access data session (i.e., an MA PDU session) via an untrusted non-3GPP access network (e.g., non-3GPP access network 150), the packet loss rate (PLR) measurement procedure in the PMFP process can be initiated by PMFs 115 and 125. In one embodiment, the PLR measurement can be performed across the entire PDN connection. Specifically, two scenarios are provided for untrusted non-3GPP access using ePDG, but UPF 120 and PGW-U are unaware of which scenario the ePDG uses. Furthermore, because UE 110 cannot identify the bearer or IPsec SA used for the PMFP procedure, UE 110 cannot count packets sent / received on a specific IPsec SA / bearer. To ensure accurate execution of the PMFP procedure related to packet counting, a consistent packet counting granularity is required between UE 110 and UPF 120. For example, during PLR measurement, UE 110 and UPF 120 can count packets sent / received across the entire PDN connection. That is, UE 110 and UPF 120 can count all packets sent / received on all SWu instances / all IPsec SAs / all S2b bearers. Additionally, UE 110 and UPF 120 can send PMFP messages through the default bearer of the PDN connection. In one embodiment, UE 110 and UPF 120 can perform PMFP procedures other than the PLR measurement procedure on the default S2b bearer or default IPsec SA of the PDN connection. For example, when using an ePDG link, for round-trip time (RTT) measurement procedures, PMFP messages are sent only through the default bearer of the PDN connection (e.g., the IPsec channel of the default bearer and the IPsec channel of the default S2b bearer of the PDN connection).
[0022] Figure 2AThis is an example scenario where each PDN connection corresponds to a single IPSec SA according to an embodiment of the present invention. In scenario 200a, only one IPsec SA is established between UE 210a and ePDG 220a, which is used to transmit services of the default bearer and all dedicated bearers established between ePDG 220a and UPF230 / related PDN gateway via S2b. In one embodiment, after UE 210a establishes a PDN connection as a user plane resource for a multi-access data session through an untrusted non-3GPP access network, UE 210a can send a PMFP PLR count request message related to the PLR measurement process to UPF 230a. For example, the PMFP PLR count request message sent by UE 210a and other PMFP messages related to the PLR measurement process can be sent through the IPsec channel of the default bearer context of the PDN connection.
[0023] After sending the PMFP PLR count request message, UE 210a begins counting the uplink (UL) packets transmitted over the entire PDN connection. The entire PDN connection can include all IPsec channels of the PDN connection. For example, assuming that the number of UL packets 211a transmitted through IPsec channel 240 is 100 and the number of UL packets 213a transmitted through IPsec channel 240 is 50, then UE 210a will obtain a count result of 150 (i.e., 100 + 50).
[0024] On the other hand, upon receiving the PMFP PLR count request message from UE 210a, UPF 230a begins counting the UL packets received on all bearers of the PDN connection and returns a PMFP PLR report response message containing the count results to UE 210a. For example, UL packet 211a sent via IPsec channel 240 is filtered by UL packet filter 221 in ePDG 220a and transmitted to UPF 230a via S2b bearer 251. Similarly, UL packet 213a sent via IPsec channel 240 is filtered by UL packet filter 221 and transmitted to UPF 230a via S2b bearer 253. Assuming the number of received UL packets 231a corresponding to UL packet 211a is 95 and the number of received UL packets 233a corresponding to UL packet 213a is 50, the count result to be included in the PMFP PLR report response message is 145 (i.e., 95 + 50). Then, UE 210a can calculate the UL packet loss rate based on the local count results (i.e., 150) and the number reported by UPF 230a (i.e., 145).
[0025] UPF 230a can also initiate the PLR measurement process by sending a PMFP PLR count request message to UE 210a. For example, the PMFP PLR count request message from UPF 230a, along with other PMFP messages related to the PLR measurement process, can be sent via the default bearer of the PDN connection. After sending the PMFP PLR count request message, UPF 230a begins counting downlink (DL) packets sent across the entire PDN connection. In this embodiment, the entire PDN connection may include all bearers of that PDN connection (e.g., S2b bearers 251 and 253). For example, assuming the number of DL packets 235a sent via S2b bearer 251 is 200 and the number of DL packets 237a sent via S2b bearer 253 is 300, then the local count result obtained by UPF 230a is 500 (i.e., 200 + 300).
[0026] Upon receiving the PMFP PLR count request message, UE 210a begins counting the DL packets received through all IPsec channels connected via the PDN and returns the count results to UPF 230a in a PMFP PLR report response message. For example, DL packet 235a is filtered by DL packet filter 239 and transmitted to ePDG 220a via S2b bearer 251, and DL packet 237a is filtered by DL packet filter 239 and transmitted to ePDG 220a via S2b bearer 253. Assuming that the number of received DL packets 215a corresponding to DL packet 235a is 200 and the number of received DL packets 217a corresponding to DL packet 237a is 280, then the count result to be included in the PMFP PLR report response message is 480 (i.e., 200 + 280). Therefore, UPF230a can calculate the DL packet loss rate based on the local count result (i.e., 500) and the number reported by UE 210a (i.e., 480).
[0027] In one embodiment, counting of UL or DL packets transmitted over the entire PDN connection is performed only when the PDN connection corresponds to a single IPsec SA (e.g., scenario 200a). In another embodiment, counting of UL or DL packets transmitted over the entire PDN connection may also be performed when the PDN connection corresponds to multiple IPsec SAs.
[0028] Figure 2BThis is an example scenario where each S2b bearer corresponds to a single IPSec SA according to an embodiment of the present invention. In scenario 200b, UE 210b and ePDG 220b support establishing a separate IPsec subSA for each dedicated S2b bearer for transmitting services of the dedicated bearer, and the primary (default) IPsec SA is used to transmit services of the default bearer. UE 210b can establish a PDN connection through an untrusted non-3GPP access network as a user plane resource for a multi-access data session and send a PMFP PLR count request message related to the PLR measurement process to UPF 230b. In this embodiment, the PMFP PLR count request message from UE 210b and other PMFP messages related to the PLR measurement process can be sent through the IPsec channel of the default bearer context of the PDN connection.
[0029] After sending the PMFP PLR count request message, UE 210b begins counting the UL packets transmitted through the entire PDN connection. In scenario 200b, the entire PDN connection may include all IPsec channels of that PDN connection, such as IPsec channels 261 and 263 associated with SWu instance 260. For example, assuming that the number of UL packets 211b transmitted through IPsec channel 261 is 200 and the number of UL packets 213b transmitted through IPsec channel 263 is 100, then the count result obtained by UE 210b is 300 (i.e., 200 + 100).
[0030] Upon receiving the PMFP PLR count request message, UPF 230b begins counting all UL packets received via the PDN connection and returns the count results to UE 210b in a PMFP PLR report response message. For example, UL packet 211b is filtered by UL packet filter 219, sent via IPsec channel 261, and transmitted to UPF 230b via S2b bearer 251. UL packet 213b is filtered by UL packet filter 219, sent via IPsec channel 263, and transmitted to UPF 230b via S2b bearer 253. Assuming the number of received UL packets 231b corresponding to UL packet 211b is 200, and the number of received UL packets 233b corresponding to UL packet 213b is 95, the count result to be included in the PMFP PLR report response message is 295 (i.e., 200 + 95). Then, UE 210b can calculate the UL packet loss rate based on the local count results (i.e., 300) and the number reported by UPF 230b (i.e., 295).
[0031] On the other hand, UPF 230b can also initiate the PLR measurement process by sending a PMFP PLR count request message to UE 210b. For example, the PMFP PLR count request message can be sent through the default bearer of the PDN connection. After sending the PMFP PLR count request message, UPF 230b begins counting the DL packets sent through the entire PDN connection. In scenario 200b, the entire PDN connection can include all bearers of that PDN connection (e.g., S2b bearers 251 and 253). Assuming that the number of DL packets 235b sent through S2b bearer 251 is 300 and the number of DL packets 237b sent through S2b bearer 253 is 100, then the local count result obtained by UPF 230b is 400 (i.e., 300 + 100).
[0032] Upon receiving the PMFP PLR count request message, UE 210b begins counting the DL packets received through all IPsec channels connected via the PDN and returns the count results to UPF 230b in a PMFP PLR report response message. For example, DL packet 235b is filtered by DL packet filter 239 and transmitted to ePDG 220b via S2b bearer 251, while DL packet 237b is filtered by DL packet filter 239 and transmitted to ePDG 220b via S2b bearer 253. Assuming the number of received DL packets 215b corresponding to DL packet 235b is 250 and the number of received DL packets 217b corresponding to DL packet 237b is 100, the count result to be included in the PMFP PLR report response message is 350 (i.e., 250 + 100). Therefore, the UPF230b can calculate the DL packet loss rate based on the local count results (i.e., 400) and the number reported by the UE 210b (i.e., 350).
[0033] By ensuring consistency in packet counting granularity between the UE side and the network side, robust operation of PMFP procedures (e.g., PLR measurement procedures) when using ePDG can be achieved.
[0034] Example Implementation Figure 3 This is an example communication system 300 according to an embodiment of the present invention, which includes at least one example communication device 310 and one example network device 320. The communication device 310 and the network device 320 can perform various functions to implement the schemes, techniques, processes and methods described herein, relating to the PMFP process when using ePDG in mobile communications, including the above-described scenarios / schemes and processes 400 and 500 described below.
[0035] Communication device 310 may be part of an electronic device, which may be a user equipment (UE), such as a portable or mobile device, wearable device, wireless communication device, or computing device. For example, communication device 310 may be implemented in a smartphone, smartwatch, personal digital assistant, digital camera, or computing device (such as a tablet, laptop, or notebook computer). Communication device 310 may also be part of a machine-type device, which may be an Internet of Things (IoT), Narrowband Internet of Things (NB-IoT), or Industrial Internet of Things (IIoT) device, such as a non-movable or fixed device, home device, wired communication device, or computing device. For example, communication device 310 may be implemented in a smart thermostat, smart refrigerator, smart door lock, wireless speaker, or home control center. Alternatively, communication device 310 may be implemented in the form of one or more integrated circuit (IC) chips, such as, but not limited to, one or more single-core processors, one or more multi-core processors, one or more Reduced Instruction Set Computing (RISC) processors, or one or more Complex Instruction Set Computing (CISC) processors. Communication device 310 may include... Figure 3 The at least partial package shown is, for example, processor 312. Communication device 310 may also include one or more other components unrelated to the proposed solution (e.g., internal power supply, display device, and / or user interface device); however, for the sake of brevity, these components of communication device 310 are not listed here. Figure 3 This is shown in the text and not described in the following text.
[0036] Network device 320 may be a network entity supporting one or more network functions (NFs). These network functions include, but are not limited to, Access and Mobility Management Function (AMF), Session Management Function (SMF), Unified Data Management (UDM), and User Plane Function (UPF). Alternatively, network device 320 may be a base station and / or a UPF. Network device 320 may include... Figure 3 The at least partial packet shown is, for example, processor 322. Processor 322 may also include a protocol stack and a set of control function modules and circuitry. Network device 320 may also include one or more other components unrelated to the proposed solution (e.g., internal power supply, display device, and / or user interface device); however, for the sake of brevity, these components of network device 320 are not listed in the above description. Figure 3 This is shown in the text and not described in the following text.
[0037] In one aspect, each of processors 312 and 322 may be implemented as one or more single-core processors, one or more multi-core processors, or one or more Complex Instruction Set Computing (CISC) processors. That is, although the singular term "processor" is used herein to refer to processors 312 and 322, each of processors 312 and 322 may include multiple processors in some implementations and a single processor in others, according to different implementations of the invention. In another aspect, each of processors 312 and 322 may be implemented in hardware (and optionally firmware) and includes electronic components, such as, but not limited to, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors, and / or one or more variable capacitors, which are configured and arranged to achieve a particular purpose according to different implementations of the invention. In other words, in at least some implementations, each of processors 312 and 322 is a dedicated machine specifically designed, arranged, and configured to perform specific tasks of embodiments of the invention in a device (e.g., represented by communication device 310) and a network (e.g., represented by network device 320).
[0038] In some implementations, the communication device 310 may also include a transceiver 316 coupled to the processor 312, which is capable of wireless data transmission and reception. In some implementations, the communication device 310 may also include a memory 314 coupled to the processor 312, which can access and store data therein.
[0039] In some implementations, network device 320 may also include memory 324 coupled to processor 322, which can access and store data therein. Accordingly, communication device 310 and network device 320 may communicate wirelessly via transceiver 316 and transceiver 326, respectively.
[0040] For illustrative purposes and without limitation, the capabilities of communication device 310 and network device 320 are described below in conjunction with processes 400 and 500. In these processes, communication device 310 is implemented as or is implemented as a communication device or user equipment, and network device 320 is implemented as or is implemented as a network node of a communication network.
[0041] Explanatory process Figure 4This is an example process 400 according to an embodiment of the present invention. Process 400 may be part or all of the example implementation of the above-described scenario / scheme involving PMFP process using ePDG in mobile communication. Process 400 may represent one aspect of the functional implementation of communication device 310. Process 400 may include one or more operations, actions, or functions, as shown in one or more blocks 410, 420, 430, and 440 of process 400. Although shown in the form of independent blocks, the individual blocks of process 400 may be divided into more blocks, merged into fewer blocks, or omitted as required for implementation. Furthermore, the blocks of process 400 may be arranged according to Figure 4 The process can be executed in the order shown, or in a different order. Process 400 can be implemented by communication device 310 or any suitable user equipment (e.g., UE 110, 210a, or 210b) or machine-type device. For illustrative purposes only and without limitation, process 400 is described below with communication device 310 as the UE. Process 400 may begin at block 410.
[0042] In block 410, process 400 may involve the processor 312 of communication device 310 establishing a PDN connection via transceiver 316. Process 400 can then proceed from block 410 to block 420.
[0043] In block 420, process 400 may involve processor 312 sending a PMFP request message related to the PMFP process to a network node (e.g., UPF120, 230a, or 230b, or network device 320) via transceiver 316. Process 400 can proceed from block 420 to block 430.
[0044] In block 430, process 400 may involve processor 312 counting uplink UL packets transmitted throughout the PDN connection. Process 400 can proceed from block 430 to block 440.
[0045] In block 440, process 400 may involve processor 312 receiving PMFP report messages from a network node via transceiver 316. The received PMFP report messages may include the number of UL packets received, counted by the network node.
[0046] In some implementations, PDN connections are established as user plane resources for multi-access data sessions through untrusted non-3GPP access networks.
[0047] In some implementations, the entire PDN connection can include all IPsec channels of the PDN connection.
[0048] In some implementations, the number of received UL packets can be counted across all bearers of the PDN connection.
[0049] In some implementations, at least one bearer of a PDN connection may include an S2b bearer.
[0050] In some implementations, the PMFP procedure can be performed on at least one of the ePDG link and the cellular link.
[0051] In some implementations, PMFP request messages can be sent through the IPsec channel of the default bearer context of the PDN connection.
[0052] In some implementations, the count of UL packets sent over the entire PDN connection is performed only when the PDN connection corresponds to a single IPSec SA.
[0053] In some implementations, the PMFP procedure may include a PLR measurement procedure, the PMFP request message may include a PMFP PLR count request message, and the PMFP report message may include a PMFP PLR report response message.
[0054] Figure 5 This is another example process 500 according to an embodiment of the present invention. Process 500 may be part or all of the example implementation of the above-described scenario / scheme involving PMFP procedures using ePDG in mobile communications. Process 500 may represent one aspect of the functional implementation of network device 320 or any suitable network node (e.g., UPF 120, 230a, or 230b). Process 500 may include one or more operations, actions, or functions, as shown in one or more blocks 510, 520, and 530 of process 500. Although shown in the form of independent blocks, the individual blocks of process 500 may be divided into more blocks, merged into fewer blocks, or omitted as needed for the desired implementation. Furthermore, the blocks of process 500 may be arranged according to... Figure 5 The processes can be executed in the order shown, or in a different order. Process 500 can begin at block 510.
[0055] In block 510, process 500 may involve the processor 322 of network device 320 sending a PMFP request message related to the PMFP process to a UE (e.g., UE 110, 210a, or 210b, or communication device 310) via transceiver 326. Process 500 may continue from block 510 to block 520.
[0056] In block 520, process 500 may involve processor 322 counting DL packets sent throughout the PDN connection. Process 500 can continue from block 520 to block 530.
[0057] In block 530, process 500 may involve processor 322 receiving a PMFP report message from the UE via transceiver 326. The PMFP report message may include the number of DL packets received, counted by the UE.
[0058] In some implementations, PDN connections are established as user plane resources for multi-access data sessions through untrusted non-3GPP access networks.
[0059] In some implementations, the entire PDN connection may include all bearers of that PDN connection.
[0060] In some implementations, the number of received DL packets can be counted across all IPsec channels of the PDN connection.
[0061] In some implementations, PMFP request messages can be sent through the default bearer of the PDN connection.
[0062] Additional Notes The subject matter described in this invention sometimes illustrates different components included within or coupled to other components. However, it should be understood that these depicted architectures are merely examples, and many other architectures implementing the same functionality can actually be implemented. Conceptually, any arrangement of components implementing the same functionality is effectively “associated” to enable the desired functionality. Therefore, regardless of architecture or intermediate components, any two components combined in this invention to achieve a particular function can be considered “associated” to each other to enable the desired functionality. Similarly, any two such associated components can also be considered “operationally coupled” to each other to achieve the desired functionality, and any two components that can be so associated can also be considered “operationally coupled” to each other to achieve the desired functionality. Specific examples of operationally coupled components include, but are not limited to, physically mating and / or physically interacting components and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.
[0063] Furthermore, regarding any plural and / or singular terms used substantially in this invention, those skilled in the art can convert them from plural to singular and / or from singular to plural as appropriate for the content and / or application. For clarity, various singular / plural substitutions may be explicitly stated in this invention.
[0064] Furthermore, those skilled in the art will understand that, generally, the terms used in this invention, and especially in the appended claims (e.g., the body of the appended claims), are generally meant as “open-ended” terms. For example, the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “at least having,” the term “comprising” should be interpreted as “including but not limited to,” and so on. Those skilled in the art will also understand that if a specific number of claims is intentionally listed, this intention will be explicitly listed in the claims, and the absence of such a listing will not indicate this intention. For example, to aid understanding, the appended claims may include the use of the introductory phrases “at least one” and “one or more.” However, the use of such phrases should not be construed as implying that the introduction of the indefinite article “a” or “an” limits any particular claim that includes such an introductory claim to only one embodiment of such a listing, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an,” for example, “a and / or one” should be interpreted as meaning “at least one” or “one or more,” the same applies to the use of definite articles used to introduce claims. Furthermore, even when a specific number of the introduced claims are explicitly listed, those skilled in the art will recognize that such a listing should be interpreted as meaning at least the number listed. For example, in the absence of other modifiers, the basic listing of "two listings" means at least two listings or two or more listings. Additionally, when using conventions such as "at least one of A, B, and C," it generally means, in the sense that those skilled in the art will understand, that a system having at least one of A, B, and C will include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together. When using conventions such as "at least one of A, B, or C," it generally means, in the sense that those skilled in the art will understand, that a system having at least one of A, B, or C will include, but is not limited to, systems having A alone, having B alone, having C alone, having A and B together, having A and C together, having B and C together, and / or having A, B, and C together. Those skilled in the art will also understand that any transitional words and / or phrases in the specification, claims, or drawings that actually indicate two or more options should be understood to include the possibility of including one, any, or both of these items. For example, the phrase "A or B" will be understood to include the possibility of including "A" or "B" or "A and B".
[0065] As can be seen from the foregoing, it is understood that various embodiments of the present invention have been described for illustrative purposes, and various modifications can be made without departing from the scope and spirit of the invention. Therefore, the various embodiments disclosed in this invention are not intended to be limiting, and the true scope and spirit are determined by the appended claims.
Claims
1. A method comprising: The device's processor establishes a packet data network (PDN) connection; The processor sends PMFP request messages related to the Performance Measurement Function Protocol (PMFP) procedure to the network nodes; The processor counts the uplink UL packets transmitted throughout the entire PDN connection; and The processor receives a PMFP report message from the network node, wherein the PMFP report message includes the number of UL packets received, counted by the network node.
2. The method as described in claim 1, characterized in that, This PDN connection serves as a user plane resource for multiple access data sessions and is established through an untrusted non-3GPP access network.
3. The method as described in claim 1, characterized in that, The entire PDN connection includes all Internet Protocol Security (IPsec) channels within the PDN connection.
4. The method as described in claim 1, characterized in that, The number of UL packets received is counted across all bearers of this PDN connection.
5. The method as described in claim 4, characterized in that, At least one bearer of the PDN connection includes an S2b bearer.
6. The method as described in claim 1, characterized in that, The PMFP request message is sent through the IPsec channel of the default bearer context of the PDN connection.
7. The method as described in claim 1, characterized in that, The counting of UL packets sent over the entire PDN connection is performed only if the PDN connection corresponds to a single IPSec security association (SA).
8. The method as described in claim 1, characterized in that, The PMFP process includes a packet loss rate (PLR) measurement process, the PMFP request message includes a PMFP PLR count request message, and the PMFP report message includes a PMFP PLR report response message.
9. An apparatus comprising: A transceiver that enables wireless communication during operation; as well as A processor, communicatively coupled to the transceiver, performs the following operations during operation: Establish a PDN connection using this transceiver; This transceiver sends PMFP request messages related to the PMFP process to network nodes. Count the UL packets sent through the entire PDN connection; and The transceiver receives PMFP report messages from the network node, wherein the PMFP report message includes the number of UL packets received, counted by the network node.
10. The device as claimed in claim 9, characterized in that, The entire PDN connection includes all IPsec channels of the PDN connection.
11. The device as claimed in claim 9, characterized in that, The number of UL packets received is counted across all bearers of this PDN connection.
12. The device as claimed in claim 11, characterized in that, At least one bearer of the PDN connection includes an S2b bearer.
13. The device as claimed in claim 9, characterized in that, The PMFP request message is sent through the IPsec channel of the default bearer context of the PDN connection.
14. The device as claimed in claim 9, characterized in that, The counting of UL packets sent over the entire PDN connection is performed only when the PDN connection corresponds to a single IPSec SA.
15. The device as claimed in claim 9, characterized in that, The PMFP process includes a PLR measurement process, the PMFP request message includes a PMFP PLR count request message, and the PMFP report message includes a PMFP PLR report response message.
16. A method comprising: The processor of the network node sends a PMFP request message related to the PMFP procedure to the user equipment (UE); The processor counts the downlink DL packets sent through the entire PDN connection; and The processor receives a PMFP report message from the UE, wherein the PMFP report message includes the number of DL packets received, counted by the UE.
17. The method as described in claim 16, characterized in that, This PDN connection serves as a user plane resource for multiple access data sessions and is established through an untrusted non-3GPP access network.
18. The method as described in claim 16, characterized in that, The entire PDN connection includes all bearers of the PDN connection.
19. The method as described in claim 16, characterized in that, The number of received DL packets is counted across all IPsec channels of this PDN connection.
20. The method as described in claim 16, characterized in that, The PMFP request message is sent through the default bearer of the PDN connection.