QOS measurement

Abstract

Embodiments herein relate to QoS measurement. Some embodiments propose a method (700) performed by a first network function (212) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) server. In one embodiment, the method may include a step (S701) of sending a subscription message to a Vertical Application Layer (VAL) User Equipment (UE) (201) to request a report of transmission quality measurements for VAL UE (201) traffic, the VAL UE (201) including a first functional component (222) implementing a SEAL DD client. In one embodiment, the method may further include a step (S703) of receiving a notification message from the VAL UE (201) to provide a report of multiple measurement results of the transmission quality measurements. Embodiments herein may enable a SEAL DD client to support data transmission quality measurement requirements and a SEAL DD client configured to initiate a data transmission quality measurement procedure.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to PCT Application Serial No. PCT / CN2023 / 076771, filed February 17, 2023, entitled "QOS MEASUREMENT FOR MULTIPLE UES," and PCT Application Serial No. PCT / CN2023 / 087439, filed April 11, 2023, entitled "QOS MEASUREMENT," the contents of which are incorporated herein by reference in their entireties.

[0002] FIELD Embodiments herein generally relate to the field of communications, and more particularly, embodiments herein relate to quality of service (QoS) measurements. [Background technology]

[0003] The Service Enablement Architecture Layer for Verticals (SEAL) has been introduced since 3GPP Release 16 to support vertical applications (e.g., Vehicle-to-Everything (V2X) communication applications). 3GPP TS 23.434 specifies application plane and signaling plane entities for application enablement services (e.g., group management, configuration management, location management, identity / key management, and network resource management), which are reusable across vertical applications. SEAL also specifies northbound application programming interfaces (APIs) for its individual services to enable flexible integration with vertical applications.

[0004] Figure 1 is a schematic block diagram illustrating a general in-network functional model 100 of SEAL. As shown in Figure 1, in the Vertical Application Layer (VAL), a VAL Client 121 can communicate with a VAL Server 111 via a VAL-UU reference point. The VAL-UU can support both unicast and multicast delivery modes.

[0005] The SEAL functional entities on the user equipment (UE) 101 and the server are partitioned into a SEAL client 122 and a SEAL server 112, respectively. SEAL may have a common set of services (e.g., group management, location management) and reference points. SEAL provides its services to VALs.

[0006] The SEAL client 122 can communicate with the SEAL server 112 via the SEAL-UU reference point. The SEAL-UU can support both unicast and multicast delivery modes. The SEAL client 122 can provide service realization layer support functions to the VAL client 121 via the SEAL-C reference point. The VAL server 111 can communicate with the SEAL server 112 via the SEAL-S reference point. The SEAL server 112 can communicate with the underlying 3GPP network system 102 using the respective 3GPP network interface defined by the 3GPP network system 102.

[0007] Data Delivery (DD) One of the capabilities SEAL provides is Data Delivery (DD).

[0008] FIG. 2 is a schematic block diagram illustrating SEAL's in-network functional model for DD (Data Delivery), which is the SEAL Data Delivery Service Architecture 200.

[0009] For uplink (UL) traffic, the VAL client 121 can send VAL application data traffic to the SEALDD client 222 via SEALDD-C for SEALDD service. After data plane packet processing by the SEALDD client 222, the VAL application data traffic can be converted to SEALDD data traffic and forwarded to the SEALDD server 212 via SEALDD-UU. The SEALDD server 212 can restore the VAL application data traffic and send it to the VAL server 111 via SEALDD-S. The VAL application traffic data can be included in SEALDD flow data, and the VAL application traffic can be identified by a SEALDD flow id.

[0010] For downlink (DL) traffic, the VAL server 111 can send VAL application data traffic to the SEALDD server 212 via SEALDD-S for SEALDD service. After data plane packet processing by the SEALDD server 212, the VAL application data traffic can be converted to SEALDD data traffic and forwarded to the SEALDD client 222 via SEALDD-UU. The SEALDD client 222 can restore the VAL application data traffic and send it to the VAL client 121 via SEALDD-C. The VAL application traffic data can be included in SEALDD flow data, and the VAL application traffic can be identified by a SEALDD flow id.

[0011] Optionally, a VAL deployment may choose to route application signaling and application data traffic for some or all of the functions that the VAL provides using SEALDD services, and Figure 3 shows an architecture for achieving this. In this case, the VAL client 121 and VAL server 111 may choose not to maintain application connections themselves, but to forward all application traffic for those functions over SEALDD connections.

[0012] It should be noted that the functionality of SEALDD may be provided as an API to the VAL layer, leaving it up to the VAL layer to decide which traffic (e.g., application signaling, application data) should be forwarded.

[0013] FIG. 3 is a schematic block diagram illustrating an example architecture for SEAL application traffic forwarding.

[0014] The SEALDD client 222 can cooperate with the SEALDD server 212 to establish an application layer data transmission path. Through this path, the SEALDD server 212 and the SEALDD client 222 can provide data transmission service functions such as data plane packet processing (e.g., packet duplication, removal, or transmission coordination), data forwarding, data caching, and background data forwarding to support the VAL server 111 and the VAL client 121.

[0015] The data transmission service functionality provided by the SEALDD client 222 and SEALDD server 212 can be enhanced by performing data transmission quality measurements. Currently, the SEALDD data transmission quality measurement procedures are incomplete. For example, the SEALDD client does not support receiving the respective measurement configuration and reporting procedures. The SEALDD client also does not support receiving corrective actions instructed by the SEALDD server. Summary of the Invention

[0016] SUMMARY OF THE INVENTION The embodiments herein propose a method, a network function, a UE, a computer-readable medium, and a computer program product for improving QoS measurements.

[0017] In some embodiments, a method is proposed that is performed by a first network function implementing a SEALDD server. In one embodiment, the method can include sending a subscription message to a VALUE to request a report of transmission quality measurements for VALUE traffic. The VALUE can include a first functional component implementing a SEALDD client. In one embodiment, the method can further include receiving a notification message from the VALUE to provide a report of a plurality of measurement results of the transmission quality measurements.

[0018] In one embodiment, the subscription message may include a first parameter indicating at least one VAL application traffic to be measured. In one embodiment, the subscription message may include a second parameter indicating measurement requirement information. In one embodiment, the subscription message may include a third parameter indicating one or more measurement conditions for the transmission quality measurement.

[0019] In one embodiment, the one or more measurement conditions may include one or more spatial conditions and / or one or more temporal conditions. In one embodiment, if the one or more conditions are not met, the first functional component implementing the SEALDD client may stop or suspend the transmission quality measurements.

[0020] In one embodiment, the measurement requirement information may include a fourth parameter indicating measurements related to any one or a combination of delay, bit rate, or packet loss rate. In one embodiment, the measurement requirement information may include a fifth parameter indicating whether reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a sixth parameter indicating a reporting period if reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a seventh parameter indicating a measurement period window for the transmission quality measurement. In one embodiment, the measurement requirement information may include an eighth parameter indicating a measurement expiration time for the transmission quality measurement. In one embodiment, the measurement requirement information may include a ninth parameter indicating a reporting criterion for reporting measurement results of the transmission quality measurement. In one embodiment, the measurement requirement information may include a tenth parameter indicating a service quality guarantee policy associated with the SEALDD flow.

[0021] In one embodiment, the reporting criteria may include reporting the measurement if the delay or bit rate is higher or lower than a value. In one embodiment, the reporting criteria may include a unique identifier for each criterion of the predefined plurality of criteria.

[0022] In one embodiment, the service level policy may include an eleventh parameter indicating an event that triggers a service level action. In one embodiment, the service level policy may include a twelfth parameter indicating a service level action to be performed when the event occurs.

[0023] In one embodiment, the event may include reaching a measurement threshold.

[0024] In one embodiment, the notification message may include a thirteenth parameter indicating a list of transmission quality measurement reports generated for the transmission quality measurement.

[0025] In one embodiment, the transmission quality measurement report list may further include a fourteenth parameter indicating a measurement related to any one or a combination of delay, bit rate, or packet loss rate based on the fourth parameter. In one embodiment, the transmission quality measurement report list may further include a fifteenth parameter indicating an average measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a sixteenth parameter indicating a minimum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a seventeenth parameter indicating a maximum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include an eighteenth parameter indicating a standard deviation of the measurement values ​​of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a nineteenth parameter indicating a k-percentile measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a twentieth parameter indicating a measurement period of the plurality of measurement results based on the seventh parameter. In one embodiment, the transmission quality measurement report list may further include a twenty-first parameter indicating a timestamp of the plurality of measurement results.

[0026] In one embodiment, the method may include receiving a response message from the VALUE in response to the subscription message.

[0027] In one embodiment, the response message may include a 22nd parameter indicating whether the subscription was successful or unsuccessful. In one embodiment, the response message may include a 23rd parameter indicating an expiration date for the subscription if the 22nd parameter indicates a successful subscription.

[0028] In one embodiment, the subscription message may be a transmission quality measurement subscription request. In one embodiment, the notification message may be a transmission quality measurement notification. In one embodiment, the response message may be a transmission quality measurement subscription response.

[0029] In some embodiments, a method is proposed that is performed by a VALUE that includes a first functional component that implements a SEALDD client. In one embodiment, the method can include receiving a subscription message from a network function that implements a SEALDD server or a second functional component that implements a VALUE client in the VALUE to request reporting of transmission quality measurements of VALUE traffic. In one embodiment, the method can further include sending a notification message to provide reporting of a plurality of measurement results of the transmission quality measurements.

[0030] In one embodiment, the subscription message may include a first parameter indicating at least one VAL application traffic to be measured. In one embodiment, the subscription message may include a second parameter indicating measurement requirement information. In one embodiment, the subscription message may include a third parameter indicating one or more measurement conditions for the transmission quality measurement.

[0031] In one embodiment, the one or more measurement conditions may include one or more spatial conditions and / or one or more temporal conditions. In one embodiment, if the one or more conditions are not met, the first functional component implementing the SEALDD client may stop or suspend the transmission quality measurements.

[0032] In one embodiment, the measurement requirement information may include a fourth parameter indicating measurements related to any one or a combination of delay, bit rate, or packet loss rate. In one embodiment, the measurement requirement information may include a fifth parameter indicating whether reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a sixth parameter indicating a reporting period if reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a seventh parameter indicating a measurement period window for the transmission quality measurement. In one embodiment, the measurement requirement information may include an eighth parameter indicating a measurement expiration time for the transmission quality measurement. In one embodiment, the measurement requirement information may include a ninth parameter indicating a reporting criterion for reporting measurement results of the transmission quality measurement. In one embodiment, the measurement requirement information may include a tenth parameter indicating a service quality guarantee policy associated with the SEALDD flow.

[0033] In one embodiment, the reporting criteria may include reporting the measurement if the delay or bit rate is higher or lower than a value. In one embodiment, the reporting criteria may include a unique identifier for each criterion of the predefined plurality of criteria.

[0034] In one embodiment, the service level policy may include an eleventh parameter indicating an event that triggers a service level action. In one embodiment, the service level policy may include a twelfth parameter indicating a service level action to be performed when the event occurs.

[0035] In one embodiment, the event may include reaching a measurement threshold.

[0036] In one embodiment, the method may further include determining to start a measurement process. In one embodiment, the method may further include initiating an uplink packet delay measurement. In one embodiment, the method may further include obtaining a plurality of measurements.

[0037] In one embodiment, the notification message may include a thirteenth parameter indicating a list of transmission quality measurement reports generated for the transmission quality measurement.

[0038] In one embodiment, the transmission quality measurement report list may further include a fourteenth parameter indicating a measurement related to any one or a combination of delay, bit rate, or packet loss rate based on the fourth parameter. In one embodiment, the transmission quality measurement report list may further include a fifteenth parameter indicating an average measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a sixteenth parameter indicating a minimum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a seventeenth parameter indicating a maximum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include an eighteenth parameter indicating a standard deviation of the measurement values ​​of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a nineteenth parameter indicating a k-percentile measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a twentieth parameter indicating a measurement period of the plurality of measurement results based on the seventh parameter. In one embodiment, the transmission quality measurement report list may further include a twenty-first parameter indicating a timestamp of the plurality of measurement results.

[0039] In one embodiment, the method may include sending a response message in response to the subscription message.

[0040] In one embodiment, the response message may include a 22nd parameter indicating whether the subscription was successful or unsuccessful. In one embodiment, the response message may include a 23rd parameter indicating an expiration date for the subscription if the 22nd parameter indicates a successful subscription.

[0041] In one embodiment, the subscription message may be a transmission quality measurement subscription request. In one embodiment, the notification message may be a transmission quality measurement notification sent to a network function implementing a SEALDD server or a second functional component implementing a VAL client. In one embodiment, the response message may be a transmission quality measurement subscription response sent to a network function implementing a SEALDD server or a second functional component implementing a VAL client.

[0042] In some embodiments, a method is proposed that is executed by a VALUE, the method including a first functional component implementing a SEALDD client and a second functional component implementing a VALUE client. In one embodiment, the method can include sending a subscription message from the second functional component to the first functional component to request reporting of transmission quality measurements for VALUE traffic. In one embodiment, the method can further include sending a notification message from the first functional component to the second functional component to provide reporting of multiple measurement results of the transmission quality measurements.

[0043] In one embodiment, the method may further include determining to start a measurement process. In one embodiment, the method may further include initiating an uplink packet delay measurement. In one embodiment, the method may further include obtaining a plurality of measurements.

[0044] In some embodiments, a method is proposed, which is performed by a first network function implementing a SEALDD server. In one embodiment, the method can include initiating a data transmission quality measurement process for a transmission path. In one embodiment, the method can further include transmitting a first request message to a VALUE to request a transmission quality assurance operation based on the measured data transmission quality. The VALUE can include a first functional component implementing a SEALDD client.

[0045] In one embodiment, the first request message may include a 24th parameter indicating at least one VAL application traffic measured. In one embodiment, the first request message may include a 25th parameter indicating a transmission quality assurance operation.

[0046] In one embodiment, the transmission quality assurance operation may further include establishing a redundant transmission path. In one embodiment, the transmission quality assurance operation may further include re-establishing the transmission path. In one embodiment, the transmission quality assurance operation may further include switching to a backup transmission path.

[0047] In one embodiment, the first request message may be an application trigger message. In one embodiment, the 25th parameter may indicate a trigger for redundant connection setup, connection re-establishment, or connection switching for transmitting a SEALDD packet.

[0048] In one embodiment, the method may further include receiving a transmission quality assurance response message from the VALUE. In one embodiment, the transmission quality assurance response message may include a 26th parameter indicating whether the request is successful or unsuccessful.

[0049] In one embodiment, the method may further include sending a second request message to VAL UE to request the use of a single transmission path.

[0050] In one embodiment, a transmission path may be formed between a second functional component implementing a VAL client of the UE and a second network function implementing a VAL server via a first functional component implementing a SEALDD client and a first network function implementing a SEALDD server.

[0051] In some embodiments, a method is proposed that is performed by a VALUE that includes a first functional component that implements a SEALDD client. In one embodiment, the method includes determining to perform a transmission quality assurance operation. In one embodiment, the transmission quality assurance operation is performed in response to a first request message for requesting the transmission quality assurance operation from a first network function that implements a SEALDD server. In one embodiment, the transmission quality assurance operation is based on a measured data transmission quality of a data transmission quality measurement process for the transmission path.

[0052] In one embodiment, the first request message may include a 24th parameter indicating at least one VAL application traffic measured. In one embodiment, the first request message may include a 25th parameter indicating a transmission quality assurance operation.

[0053] In one embodiment, the transmission quality assurance operation may further include establishing a redundant transmission path. In one embodiment, the transmission quality assurance operation may further include re-establishing the transmission path. In one embodiment, the transmission quality assurance operation may further include switching to a backup transmission path.

[0054] In one embodiment, performing the transmission quality assurance operation may further include establishing an additional transmission path for redundancy. In one embodiment, performing the transmission quality assurance operation may further include establishing two new transmission paths and releasing the existing transmission path for redundancy. In one embodiment, performing the transmission quality assurance operation may further include releasing the existing transmission path and establishing a new transmission path. In one embodiment, performing the transmission quality assurance operation may further include switching to a backup transmission path and disabling the existing transmission path.

[0055] In one embodiment, the first request message may be an application trigger message. In one embodiment, the 25th parameter may indicate a trigger for redundant connection setup, connection re-establishment, or connection switching for transmitting a SEALDD packet.

[0056] In one embodiment, the method can further include sending a transmission quality assurance response message to the first network function implementing the SEALDD server. In one embodiment, the transmission quality assurance message can include a 26th parameter indicating whether the first request was successful or unsuccessful.

[0057] In one embodiment, the method may further include determining to use a single transmission path. In one embodiment, the determination to use the single transmission path is made in response to a second request message from a first network function implementing a SEALDD server requesting to use the single transmission path. In one embodiment, the determination to use the single transmission path is made based on measured data transmission quality of a separate data transmission quality measurement process of the transmission path.

[0058] In one embodiment, the method may further include releasing at least one transmission path and returning to a single SEALDD connection mode.

[0059] In one embodiment, a transmission path may be formed between a second functional component implementing a VAL client of the UE and a second network function implementing a VAL server via a first functional component implementing a SEALDD client and a first network function implementing a SEALDD server.

[0060] In some embodiments, a network function is proposed, comprising at least one processor and a non-transitory computer-readable medium coupled to the at least one processor. In one embodiment, the non-transitory computer-readable medium can store instructions executable by the at least one processor, whereby the at least one processor can be configured to perform the above-described method associated with the above-described network function. In one embodiment, the network function can be configured as the above-described first network function or the second network function.

[0061] In some embodiments, a UE is proposed, comprising at least one processor and a non-transitory computer-readable medium coupled to the at least one processor. In one embodiment, the non-transitory computer-readable medium can store instructions executable by the at least one processor, whereby the at least one processor can be configured to perform the above-mentioned method associated with the above-mentioned UE or functional components thereof.

[0062] In some embodiments, a computer readable medium is proposed that stores computer readable code that, when executed on a device, causes the device to perform any of the above methods.

[0063] In some embodiments, a computer program product is proposed that stores computer readable code that, when executed on a device, causes the device to perform any of the above methods.

[0064] Embodiments herein may enable SEALDD clients to be configured with data transmission quality measurement requirements and support how the SEALDD client initiates a data transmission quality measurement procedure. Embodiments herein may further enable SEALDD servers to support instructing SEALDD clients on how to mitigate data transmission quality issues. [Brief explanation of the drawings]

[0065] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the present disclosure and, together with the description, serve to further explain the principles of the present disclosure and to enable those skilled in the art to make and practice the embodiments disclosed herein. In the drawings, like reference numbers indicate identical or functionally similar elements. [Figure 1] Figure 1 is a schematic block diagram illustrating the general in-network functional model of SEAL. [Figure 2]FIG. 2 is a schematic block diagram showing the network functional model of SEAL for DD. [Figure 3] FIG. 3 is a schematic block diagram illustrating an exemplary architecture for SEAL application traffic forwarding. [Figure 4] FIG. 4 is a schematic signaling chart illustrating messages in an example SEALDD-enabled data transmission quality measurement procedure, according to embodiments herein. [Figure 5A] FIG. 5A is a schematic signaling chart illustrating messages in another exemplary SEALDD-enabled data transmission quality measurement procedure, according to embodiments herein. [Figure 5B] FIG. 5B is a schematic signaling chart illustrating messages in yet another exemplary SEALDD-enabled data transmission quality measurement procedure, according to embodiments herein. [Figure 6A] FIG. 6A is a schematic signaling chart illustrating messages in an exemplary SEALDD-enabled data transmission quality assurance procedure, according to embodiments herein. [Figure 6B] FIG. 6B is a schematic signaling chart illustrating messages in another exemplary SEALDD-enabled data transmission quality assurance procedure, according to embodiments herein. [Figure 7] FIG. 7 is a schematic flowchart illustrating an exemplary method in a first network function, according to an embodiment herein. [Figure 8] FIG. 8 is a schematic flowchart illustrating an exemplary method in a UE, according to an embodiment herein. [Figure 9] FIG. 9 is a schematic flowchart illustrating another exemplary method in a UE, according to embodiments herein. [Figure 10] FIG. 10 is a schematic flowchart illustrating another exemplary method in a first network function, according to embodiments herein. [Figure 11]FIG. 11 is a schematic flowchart illustrating yet another exemplary method in a UE, according to embodiments herein. [Figure 12] FIG. 12 is a schematic block diagram illustrating an exemplary first network function according to embodiments herein. [Figure 13] FIG. 13 is a schematic block diagram illustrating an exemplary UE, according to embodiments herein. [Figure 14] FIG. 14 is a schematic block diagram illustrating an exemplary computer-implemented apparatus, according to embodiments herein. [Figure 15] FIG. 15 is a schematic signaling chart illustrating messages in an exemplary SEALDD-enabled data transmission quality measurement procedure according to embodiments herein. [Figure 16] FIG. 16 is a schematic signaling chart illustrating messages in an exemplary SEALDD-enabled data transmission quality assurance procedure, according to an embodiment herein. DETAILED DESCRIPTION OF THE INVENTION

[0066] Embodiments herein are described in detail below with reference to the accompanying drawings illustrating embodiments. However, these embodiments herein may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Elements of the drawings are not necessarily to scale relative to each other.

[0067] Reference to "one embodiment" or "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Thus, the appearances of the phrase "in an embodiment" appearing in various places throughout this specification do not necessarily all refer to the same embodiment.

[0068] As used herein, the term "A, B, or C" means "A" or "B" or "C," the term "A, B, and C" as used herein means "A" and "B" and "C," and the term "A, B, and / or C" as used herein means "A," "B," "C," "A and B," "A and C," "B and C."

[0069] Currently, the SEALDD data transmission quality measurement procedures are incomplete. For example, the SEALDD client does not support receiving the respective measurement configuration and reporting procedures. The SEALDD client also does not support receiving corrective actions instructed by the SEALDD server.

[0070] In view of the above drawbacks, this embodiment proposes a solution to improve QoS measurement in the SEALDD layer to support SEALDD client initiated data transmission quality measurement.In addition, the case where the SEALDD server initiates data transmission quality measurement is also enhanced to alleviate data transmission quality problems.

[0071] This embodiment may be implemented in an architecture for SEAL data delivery services, as shown in FIGS.

[0072] In one embodiment, the architecture 200 can be configured for an OTT scenario. The OTT connection may be transparent, in the sense that the communication devices through which the OTT connection pass are unaware of the routing of uplink and downlink communications. For example, the base station may not, and need not, be informed of the previous path of incoming downlink communications, including data originating from the VAL server 111 or SEALDD server 212, to be forwarded (e.g., handed over) to the connected UE 201. Similarly, the base station does not need to be aware of the future routing of outgoing uplink communications from the UE 201 toward the VAL server 111 or SEALDD server 212.

[0073] It should also be understood that the network functions may be implemented as network elements on dedicated hardware, as software instances running on dedicated hardware, or as virtualized functions instantiated on a suitable platform, for example on a cloud infrastructure.

[0074] As used herein, a UE 101 or 201 refers to a device capable of, configured, arranged, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE 101 or 201 include, but are not limited to, a smartphone, a mobile phone, a cellular phone, a voice-over-IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless camera, a game console or device, a music storage device, a playback device, a wearable device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop embedded equipment (LEE), a laptop mounted equipment (LME), a smart device, wireless customer premises equipment (CPE), a wireless device mounted on or embedded / integrated in a vehicle, etc. Other examples include any UE defined by the 3rd Generation Partnership Project (3GPP), including a Narrowband Internet of Things (NB-IoT) UE, a Machine Type Communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0075] The UE 101 or 201 may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), or vehicle-to-everything communications (V2X). In other examples, the UE 101 or 201 may not necessarily assume a user in the sense of a human user who owns and / or operates an associated device. Instead, the UE 101 or 201 may represent a device intended for sale to or operation by a human user, but not associated with or initially associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE 101 or 201 may represent a device not intended for sale to or operation by an end user, but associated with or operated for the benefit of a user (e.g., a smart electricity meter).

[0076] It should be noted that while a 3GPP network system 102 is used herein as an example, embodiments herein may also be applicable to non-3GPP networks. In that sense, the network system 102 may be configured to operate according to predefined rules or procedures, such as a particular standard, including, but not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G), a wireless local area network (WLAN) standard such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (Wi-Fi), and / or any other suitable wireless communications standard, such as Worldwide Interoperability for Microwave Access (WiMAX), Bluetooth, Z-Wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any low power wide area network (LPWAN) standard such as LoRa and Sigfox.

[0077] 4 is a schematic signaling chart illustrating messages in an exemplary SEALDD-enabled data transmission quality measurement procedure according to embodiments herein. The SEALDD client 222 and SEALDD server 212 may be enhanced by performing data transmission quality measurements.

[0078] Before performing the data transmission quality measurement procedure, the SEALDD server 212 and the SEALDD client 222 may be synchronized to a time source provided by 5GS as specified in 3GPP TS 23.501, and the VAL server 111 may discover and select the SEALDD server 212 through a Common API Framework (CAPIF) function.

[0079] In one embodiment, the signaling chart of FIG. 4 may include the following messages or steps:

[0080] Step 1. An ongoing normal data transmission connection may be established in accordance with section 9.2.2.2 of 3GPP TS 23.433.

[0081] Step 2. The VAL server 111 can send a SEALDD transmission quality measurement subscription request to the SEALDD server 212. The request can include an identifier of the application traffic (e.g., VAL service ID, VAL server ID), requirements for transmission quality measurement (e.g., delay, bit rate, packet loss rate), and UEs to be measured (a single UE, a group of UEs, or all UEs), and can also include reporting frequency, spatial conditions, and time conditions.

[0082] In one example, a group of VAL UEs or VAL UE groups may include multiple VAL UEs 201 that share the same VAL service and / or are located in the same geographic area.

[0083] Table 1 below shows the information flow from the VAL server 111 to the SEALDD server 212 for subscribing to the data transmission measurement service.

[0084] Table 1: SEALDD Transmission Quality Measurement Subscription Requests [Table 1]

[0085] As shown in Table 1, the information element "VALUE group ID", which is a group identifier (ID) of a group of VALUEs, or the information element "ALL VALUES indication", which is an indication indicating all VALUEs, can be provided in the subscription request to request reporting of transmission quality measurements for one or more VALUEs.

[0086] Additionally, the information element "report frequency" may be provided in the subscription request to indicate whether the reporting should be periodic. If the reporting is set to periodic, the information element "report period" may be provided in the subscription request to indicate the reporting period.

[0087] Additionally, an information element "report granularity" may be provided in the subscription request to indicate whether a report should be provided per UE or aggregated across multiple UEs. The report granularity may indicate whether the requested report is for a specific VALUE, an individual VALUE of multiple VALUEs, a group of VALUEs, or all VALUEs.

[0088] Additionally, the information element "measurement conditions" may be provided in the subscription request to indicate one or more spatial and / or temporal conditions for the measurement. If one or more conditions are not met, the SEALDD server 212 may stop or suspend the transmission quality measurement.

[0089] In one example, the VAL server 111 can send a measurement request to the SEALDD server 212 with a geographical area or scheduled route (spatial condition) and / or a start-stop time with any time period (temporal condition).

[0090] For example, it is assumed that measurements are taken daily from 9:00 AM to 6:00 PM for VALUE201, which is located in a park or campus.

[0091] In another example, measurements are assumed to be performed on VAL UE201 (e.g., a group of V2X UEs) with a planned route (from city A to city B via highways A2 and A3) from 9:00 AM to 11:00 AM on Tuesdays and from 1:00 PM to 5:00 PM on Thursdays until September 2025.

[0092] Step 3. Upon receiving the request, the SEALDD server 212 may perform an authorization check. If the authorization check is successful, the SEALDD server 212 may send a response to the VAL server 111 with the subscription ID and expiration date.

[0093] Table 2 below shows the information flow from the SEALDD server 212 to the VAL server 111 for responding to a transmission quality measurement subscription request.

[0094] Table 2: SEALDD Transmission Quality Measurement Subscription Response [Table 2]

[0095] Step 4. The SEALDD server 212 can start downlink (DL) packet delay measurement based on the request from the VAL server 111 in step 2. When the SEALDD server 212 sends a DL monitoring packet, the SEALDD server 212 can encapsulate the DL monitoring packet (i.e., a DL SEALDD packet having a SEALDD DL monitoring header and VAL traffic as a payload, or a dummy DL SEALDD packet generated for data transmission quality monitoring) with local time T1. The SEALDD server 212 can consider spatial and / or temporal conditions when starting / resumeing transmission quality measurement. If the conditions are not met, the SEALDD server 212 can stop / suspend transmission quality measurement.

[0096] Step 5. The SEALDD client 222 can receive the DL monitoring packet and record the local time T2. Note that no dummy packets are sent to the VAL client 222.

[0097] Step 6. Similarly, the SEALDD client 222 can encapsulate an uplink (UL) monitoring packet (i.e., a UL SEALDD packet having a SEALDD UL monitoring header and VAL traffic as payload, or a dummy UL SEALDD packet generated for data transmission quality monitoring) using the local time T2 when the SEALDD client 222 receives the DL monitoring packet and the local time T3 when the SEALDD client 222 sends out the UL monitoring packet.

[0098] Step 7. The SEALDD server 212 can record the local time T4 when the SEALDD server 212 receives the UL monitoring packet and can calculate the packet delay using T1, T2, T3, and T4. The SEALDD server 212 can also calculate the bit rate and packet loss rate over a period of time on a particular SEALDD connection by recording the status of SEALDD packets carrying VAL traffic or dummy SEALDD packets generated for transmission quality measurement reporting.

[0099] Step 8. The SEALDD server 212 can report data transmission quality measurements (eg, packet delay, bit rate, packet error rate) to the VAL server 111 via notification messages.

[0100] In step 2, once a group of VALUEs or all VALUE indications are received, steps 4 through 7 may be repeated for the VALUEs in the group or for all VALUEs. The SEALDD server 212 may identify SEALDD connections corresponding to the desired VALUEs 201 to trigger measurements, and depending on the reporting requirements for multiple VALUEs 201, the SEALDD server 212 may calculate the necessary reports for the VAL server 111. For example, the SEALDD server 212 may aggregate one or more transmission quality measurement results to form an aggregated transmission quality measurement result (such as an average measurement, a minimum measurement, and / or a maximum measurement).

[0101] Table 3 below shows the information flow from the SEALDD server 212 to the VAL server 111 for notifying a transmission quality measurement report.

[0102] Table 3: SEALDD Transmission Quality Measurement Notification [Table 3]

[0103] When the measurement target is for a group of UEs or all UEs, the report may be per UE or aggregated (e.g., average measurement, maximum measurement) for the group or all UEs depending on the reporting requirements. As shown in Table 3, the information element "VAL UE ID(s)" may be provided in the notification to indicate whether the transmission quality measurement and / or report is per UE or aggregated for multiple UEs.

[0104] If the information element "reporting granularity" in the subscription request is set to a specific VALUE or to an individual VALUE of multiple VALUEs, the transmission quality measurements for one or more VALUEs may be transmission quality measurements for the specific VALUE or the individual VALUE.

[0105] If the information element "reporting granularity" in the subscription request is set to multiple UEs, the transmission quality measurements for one or more VALUEs may be an aggregation of the transmission quality measurements for a group of VALUEs or for all VALUEs.

[0106] In one example, for a vehicle in a fleet, an average measurement of the vehicle's transmission quality may be used for reselection of the SEALDD server 212. As shown in Table 3, the information element "average measurement" may be provided in the notification to indicate the average measurement of multiple transmission quality measurements for a group of VALUEs or all VALUEs.

[0107] 4, embodiments herein can support multiple VALUEs in a SEALDD data transmission quality measurement subscription and support different forms of reporting (e.g., average values) for multiple VALUEs. As a result, QoS measurement at the SEALDD layer can be improved to support multiple VALUEs in one subscription, which would otherwise require the VAL server to send many subscription requests (one per UE data flow).

[0108] 5A is a schematic signaling chart illustrating messages in another exemplary SEALDD-enabled data transmission quality measurement procedure according to embodiments herein. In one embodiment, FIG. 5A illustrates VAL data transmission quality measurements reported by SEALDD client 222. SEALDD client 222 can receive the transmission quality measurement request, decide to initiate VAL data transmission monitoring, and generate a measurement report.

[0109] In one embodiment, the signaling chart of FIG. 5A may include the following messages or steps:

[0110] Step 1. An ongoing normal data transmission connection is established according to section 9.2.2.2 of 3GPP TS 23.433. In one embodiment, transmission quality measurements can be triggered by the VAL server 111 as described in steps 2 to 5.

[0111] Step 2. The VAL Server 111 can send a SEALDD transmission quality measurement subscription request to the SEALDD Server 212. The request includes an identifier of the application traffic (e.g., VAL Service ID, VAL Server ID), transmission quality measurement requirements (e.g., delay, jitter, bit rate), and UEs to be measured (e.g., a single UE, a group of UEs, or all UEs), and can also include reporting criteria, reporting frequency, spatial conditions, and temporal conditions.

[0112] In one embodiment, spatial and / or temporal conditions may be used by the SEALDD client 222 to apply when and where measurements are performed. For example, for a group of VALUEs with a planned route (from city A to city B via highways A2 and A3), it is assumed that measurements will be taken on Tuesdays from 9:00 AM to 11:00 AM and on Thursdays from 1:00 PM to 5:00 PM.

[0113] Step 3. Upon receiving the request, the SEALDD server 212 may perform an authorization check. If the authorization check is successful, the SEALDD server 212 may respond to the VAL server 111.

[0114] Step 4. The SEALDD server 212 may send a SEALDD transmission quality measurement subscription request to the SEALDD client 222.

[0115] Table 4 below shows the information flow from the SEALDD server 212 to the SEALDD client 222 for a data transmission measurement subscription.

[0116] Table 4: Transmission Quality Measurement Subscription Requests [Table 4]

[0117] In one embodiment, the SEALDD flow IDs in Table 4 may be used by the SEALDD client 222 and the SEALDD server 212 to identify different VAL application traffic for the same SEALDD client 222. The SEALDD flow ID may be the same as the application traffic's identifier or may be the same as a new, simplified ID assigned by SEALDD. VAL application traffic data may be included in the SEALDD flow data, and the VAL application traffic may be identified by the SEALDD flow ID.

[0118] Step 5. The SEALDD client 222 can respond to the SEALDD server.

[0119] Table 5 below shows the information flow from the SEALDD client 222 to the SEALDD server 212 for responding to a transmission quality measurement subscription request.

[0120] Table 5: Transmission Quality Measurement Subscription Response [Table 5]

[0121] Based on the received service level policy, including thresholds and actions, the SEALDD client 222 can take corrective action as described in the embodiment shown in Figure 6A and / or Figure 6B.

[0122] Step 6. After the SEALDD client 222 decides to start the measurement process, when a UL packet arrives, the SEALDD client 222 can start the UL packet delay measurement.

[0123] The SEALDD client 222 can encapsulate the UL monitoring packet (i.e., a UL SEALDD packet having a SEALDD UL monitoring header and VAL traffic as a payload for VAL data transmission quality monitoring) at local time T1 when the SEALDD client 222 sends out the UL monitoring packet.

[0124] The SEALDD client 222 can consider spatial and / or temporal conditions when starting / resuming transmission quality measurements. If the conditions are not met, the SEALDD client 222 can stop / suspend transmission quality measurements.

[0125] Step 7. The SEALDD server 212 can receive the UL monitoring packet and record the local time T2.

[0126] Step 8. Similarly, the SEALDD server 212 can encapsulate the DL monitoring packet (i.e., a DL SEALDD packet having a SEALDD DL monitoring header and VAL traffic as payload, or a dummy UL SEALDD packet generated for data transmission quality monitoring in the absence of DL VAL traffic) with the local time T2 recorded in step 7 and the local time T3 when the SEALDD server 212 sends out the DL monitoring packet.

[0127] In one embodiment, the timing at which the SEALDD server 212 sends a dummy UL packet as a monitoring response to the SEALDD client 222 may depend on the SEALDD server implementation.

[0128] Step 9. The SEALDD client 222 can record the local time T4 when the SEALDD client 222 receives the DL monitor packet and can calculate the delay using T1, T2, T3, and T4.

[0129] The SEALDD client 222 may also calculate the bit rate and jitter over a period of time on a particular SEALDD connection by recording the status of SEALDD monitor packets.

[0130] The SEALDD client 222 may also evaluate the reporting criteria (if any) in the SEALDD transmission quality measurement subscription request to generate a transmission quality measurement report.

[0131] Steps 10-11. The SEALDD client 222 can report data transmission quality measurements (eg, delay, jitter, bit rate) to the VAL server 111 via the SEALDD server 212.

[0132] Table 6 below shows the information flow from SEALDD client 222 to SEALDD server 212 for notifying a transmission quality measurement report.

[0133] Table 6: Transmission quality measurement notification [Table 6]

[0134] In one embodiment, if a VAL Group ID or list of VAL UE IDs or all VAL UE indication is received in step 2, steps 4 through 10 above may be repeated for the VAL UEs in the group / list or for all VAL UEs. If a VAL Group ID is received, the SEALDD server 212 may map the VAL UE Group ID to a list of VAL UE IDs. The SEALDD server 212 may identify the SEALDD connections corresponding to the desired VAL UEs to trigger measurements, and depending on the reporting requirements for multiple UEs, the SEALDD server 212 may collect and aggregate the necessary reports for the VAL server 111.

[0135] 5B is a schematic signaling chart illustrating messages in yet another exemplary SEALDD-enabled data transmission quality measurement procedure according to embodiments herein. In one embodiment, FIG. 5B illustrates VAL data transmission quality measurements reported by SEALDD client 222. SEALDD client 222 can receive the transmission quality measurement request, decide to initiate VAL data transmission monitoring, and generate a measurement report.

[0136] In one embodiment, the signaling chart of FIG. 5B may include the following messages or steps:

[0137] Step 1. An ongoing normal data transmission connection is established according to section 9.2.2.2 of 3GPP TS 23.433. In one embodiment, transmission quality measurements may be triggered by the VAL client 121 as described in step 2.

[0138] Step 2. The VAL client 121 can initiate a SEALDD transmission quality measurement procedure to the SEALDD client 222 to collect measurement report information. The VAL client 121 can use messages similar to steps 4 and 5 above in Figure 5A or parameters similar to Tables 4 and 5 above to initiate the SEALDD transmission quality measurement procedure.

[0139] Step 3. After the SEALDD client 222 decides to start the measurement process, when a UL packet arrives, the SEALDD client 222 can start the UL packet delay measurement.

[0140] The SEALDD client 222 can encapsulate the UL monitoring packet (i.e., a UL SEALDD packet having a SEALDD UL monitoring header and VAL traffic as a payload for VAL data transmission quality monitoring) at local time T1 when the SEALDD client 222 sends out the UL monitoring packet.

[0141] The SEALDD client 222 can consider spatial and / or temporal conditions when starting / resuming transmission quality measurements. If the conditions are not met, the SEALDD client 222 can stop / suspend transmission quality measurements.

[0142] Step 4. The SEALDD server 212 can receive the UL monitoring packet and record the local time T2.

[0143] Step 5. Similarly, the SEALDD server 212 can encapsulate the DL monitoring packet (i.e., a DL SEALDD packet having a SEALDD DL monitoring header and VAL traffic as payload, or a dummy UL SEALDD packet generated for data transmission quality monitoring in the absence of DL VAL traffic for DL ​​packet delay monitoring) with the local time T2 recorded in step 4 and the local time T3 when the SEALDD server 212 sends out the DL monitoring packet.

[0144] In one embodiment, the timing at which the SEALDD server 212 sends a dummy UL packet as a monitoring response to the SEALDD client 222 may depend on the SEALDD server implementation.

[0145] Step 6. The SEALDD client 222 can record the local time T4 when the SEALDD client 222 receives the DL monitor packet and can calculate the delay using T1, T2, T3, and T4.

[0146] The SEALDD client 222 may also calculate the bit rate and jitter over a period of time on a particular SEALDD connection by recording the status of SEALDD monitor packets.

[0147] The SEALDD client 222 may also evaluate the reporting criteria (if any) in the SEALDD transmission quality measurement subscription request to generate a transmission quality measurement report.

[0148] Step 7. The SEALDD client 222 can report the data transmission quality measurement results to the VAL client 121. The SEALDD client 222 can use a message similar to step 10 above in FIG. 5A or parameters similar to those in Table 6 above to report the data transmission quality measurement results.

[0149] Embodiments herein may enable support for SEALDD clients with configured data transmission quality measurement requirements and for SEALDD clients to initiate data transmission quality measurement procedures.

[0150] 6A is a schematic signaling chart illustrating messages in an exemplary SEALDD-enabled data transmission quality assurance procedure, according to an embodiment of the present specification. In one embodiment, FIG. 6A illustrates a procedure for using redundant transmission as an operation to meet connection reliability requirements specified by a SEALDD service policy.

[0151] In one embodiment, SEALDD service policies, including data transmission quality guarantees, may be available to SEALDD server 212, SEALDD client 222, and / or VAL client 121. The policies may be used to configure measurements and determine SEALDD layer actions necessary to meet service policy requirements.

[0152] In one embodiment, the SEALDD client 222 may have the authority to request redundant transmission services on behalf of the VAL client 121 .

[0153] In one embodiment, the signaling chart of FIG. 6A may include the following messages or steps:

[0154] Step 1. The VAL client 121 and the VAL server 111 can establish a SEALDD connection via the SEALDD client 222 and the SEALDD server 212 to transmit application data.

[0155] As part of the connection establishment, the SEALDD service policy is shared so that it is available to both the SEALDD client 222 and the SEALDD server 212. The SEALDD server 212 may use the data transmission quality requirements of this policy in combination with other local policies pre-configured on the SEALDD server 212. The SEALDD service policy may be configured locally on the SEALDD server 212 or may be provided by the VAL server 111 and accepted / approved by the SEALDD server 212.

[0156] The SEALDD client 222 may determine whether to initiate data transmission quality measurements (as shown in Figures 5A and 5B). As a result, SEALDD measurements (e.g., packet loss rate, delay) may be configured in the SEALDD client 222 as described in Figures 5A and 5B and initiated accordingly. The SEALDD client 222 may then receive the measurement reports.

[0157] Step 2. Based on the measurement report and the SEALDD service policy, the SEALDD client 222 can decide to perform an action such that the data transmission quality requirements of the policy are met.

[0158] In one embodiment, the transmission quality assurance operation may include at least one of establishing a redundant transmission path, re-establishing a transmission path, and switching to a backup transmission path.

[0159] Step 3. The SEALDD client 222 can initiate the establishment of a redundant transmission service.

[0160] Step 4. The SEALDD client 222 may request the use of a redundant transmission service from the SEALDD server 212. As part of this step, the UE 201, including the VAL client 121 and the SEALDD client 222, may terminate the initial PDU session and establish a redundant PDU session.

[0161] In one embodiment, the SEALDD client 222 can request at least one of establishing an additional transmission path for redundancy, establishing two new transmission paths for redundancy and releasing an existing transmission path, releasing an existing transmission path and establishing a new transmission path, and switching to a backup transmission path and disabling the existing transmission path.

[0162] Step 5. The SEALDD client 222 can update the SEALDD connection with the redundant transmission information, i.e., UE address and port for the redundant PDU session, SEALDD flow identifier, and application traffic descriptor. The SEALDD client 222 can also configure parameters to enable any necessary SEALDD measurements for the new SEALDD flow.

[0163] Step 6. The SEALDD server 212 can subscribe to receive notifications from the 3GPP network system (e.g., a 5G network) 102 for user plane measurements (e.g., network delay requirements specified in 3GPP TS 28.541), network analysis (specified in 3GPP TS 28.104), etc.

[0164] Step 7. The SEALDD client 222 and SEALDD server 212 can handle data deduplication and elimination of application traffic on redundant SEALDD flows, and the necessary measurements can be collected by the SEALDD client 222.

[0165] When the SEALDD measurement results indicate that the SEALDD data transmission is performing well according to the policy guarantee threshold, if the measurement was initiated by the SEALDD client 222, the SEALDD client 222 can release one transmission path and return to a single SEALDD connection mode.

[0166] 6B is a schematic signaling chart illustrating messages in another exemplary SEALDD-enabled data transmission quality assurance procedure according to embodiments herein. In one embodiment, FIG. 6B illustrates a procedure for using redundant transmission as an operation to meet connection reliability requirements defined by a SEALDD service policy.

[0167] In one embodiment, SEALDD service policies, including data transmission quality guarantees, may be available to SEALDD server 212, SEALDD client 222, and / or VAL client 121. The policies may be used to configure measurements and determine SEALDD layer actions necessary to meet service policy requirements.

[0168] In one embodiment, the SEALDD client 222 may have the authority to request redundant transmission services on behalf of the VAL client 121 .

[0169] In one embodiment, the signaling chart of FIG. 6B may include the following messages or steps:

[0170] Step 1. The VAL client 121 and the VAL server 111 can establish a SEALDD connection via the SEALDD client 222 and the SEALDD server 212 to transmit application data.

[0171] As part of the connection establishment, the SEALDD service policy is shared so that it is available to both the SEALDD client 222 and the SEALDD server 212. The SEALDD server 212 may use the data transmission quality requirements of this policy in combination with other local policies pre-configured on the SEALDD server 212. The SEALDD service policy may be configured locally on the SEALDD server 212 or may be provided by the VAL server 111 and accepted / approved by the SEALDD server 212.

[0172] The SEALDD server 212 can determine whether to initiate data transmission quality measurements (as shown in FIG. 4). As a result, SEALDD measurements (e.g., packet loss rate, delay) can be configured in the SEALDD server 212 as described in FIG. 4 and initiated accordingly. The SEALDD server 212 can then receive the measurement reports.

[0173] Step 2. Based on the measurement report and the SEALDD service policy, the SEALDD server 212 can decide to perform an action such that the data transmission quality requirements of the policy are met.

[0174] In one embodiment, the transmission quality assurance operation may include at least one of establishing a redundant transmission path, re-establishing a transmission path, and switching to a backup transmission path.

[0175] Step 3. The SEALDD server 212 can trigger the establishment of a redundant transmission service by sending a transmission quality assurance request to the SEALDD client 222 requesting the establishment of a redundant transmission path.

[0176] In one embodiment, the request may be sent to SEALDD client 222 via an application trigger (as defined in section 4.13.2 of 3GPP TS 23.502) with a payload indicating the trigger of a redundant connection setup for SEALDD packet transmission. In another embodiment, the payload may indicate the trigger of a connection re-establishment or connection switch.

[0177] Table 7 below shows the information flow from the SEALDD server 212 to the SEALDD client 222 for requesting data transmission quality assurance.

[0178] Table 7: Transmission quality assurance requirements [Table 7]

[0179] The SEALDD client 222 can respond to a transmission quality assurance request, signaling the outcome of the request as either successful or unsuccessful.

[0180] Table 8 below shows the information flow from the SEALDD client 222 to the SEALDD server 212 for responding to a transmission quality assurance request.

[0181] Table 8: Transmission quality assurance responses [Table 8]

[0182] Step 4. The SEALDD client 222 may request the use of a redundant transmission service from the SEALDD server 212. As part of this step, the UE 201, including the VAL client 121 and the SEALDD client 222, may terminate the initial PDU session and establish a redundant PDU session.

[0183] In one embodiment, the SEALDD client 222 can request at least one of establishing an additional transmission path for redundancy, establishing two new transmission paths for redundancy and releasing an existing transmission path, releasing an existing transmission path and establishing a new transmission path, and switching to a backup transmission path and disabling the existing transmission path.

[0184] Step 5. The SEALDD client 222 can update the SEALDD connection with the redundant transmission information, i.e., UE address and port for the redundant PDU session, SEALDD flow identifier, and application traffic descriptor. The SEALDD server 212 can also configure parameters to enable any necessary SEALDD measurements for the new SEALDD flow.

[0185] Step 6. The SEALDD server 212 can subscribe to receive notifications from the 3GPP network system (e.g., a 5G network) 102 for user plane measurements (e.g., network delay requirements specified in 3GPP TS 28.541), network analysis (specified in 3GPP TS 28.104), etc.

[0186] Step 7. The SEALDD client 222 and SEALDD server 212 can handle data deduplication and elimination of application traffic on redundant SEALDD flows, and the necessary measurements can be collected by the SEALDD server 212.

[0187] When the SEALDD measurement results indicate that the SEALDD data transmission is performing well according to the policy guarantee threshold, the SEALDD server 212 can send a request to the SEALDD client 222 requesting to use a single transmission, and the SEALDD client 222 may then release one transmission path and return to a single SEALDD connection mode.

[0188] Embodiments herein may enable support for SEALDD servers to instruct SEALDD clients on how to mitigate data transmission quality issues.

[0189] 7 is a schematic flowchart illustrating an exemplary method 700 in a first network function, according to an embodiment herein. In one embodiment, the flowchart of FIG. 7 may be implemented in the SEALDD server 212 of FIGS. 1-6B, 15, and 16.

[0190] Method 700 may begin at step S701, in which a first network function (e.g., SEALDD server 212) may send a subscription message to a VALUE to request reporting of transmission quality measurements for VALUE traffic. The VALUE may include a first functional component implementing a SEALDD client. In one embodiment, the subscription message may be a transmission quality measurement subscription request.

[0191] In one embodiment, the subscription message may include a first parameter indicating at least one VAL application traffic to be measured. In one embodiment, the subscription message may include a second parameter indicating measurement requirement information. In one embodiment, the subscription message may include a third parameter indicating one or more measurement conditions for the transmission quality measurement.

[0192] In one embodiment, the one or more measurement conditions may include one or more spatial conditions and / or one or more temporal conditions. In one embodiment, if the one or more conditions are not met, the first functional component implementing the SEALDD client may stop or suspend the transmission quality measurements.

[0193] In one embodiment, the measurement requirement information may include a fourth parameter indicating measurements related to any one or a combination of delay, bit rate, or packet loss rate. In one embodiment, the measurement requirement information may include a fifth parameter indicating whether reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a sixth parameter indicating a reporting period if reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a seventh parameter indicating a measurement period window for the transmission quality measurement. In one embodiment, the measurement requirement information may include an eighth parameter indicating a measurement expiration time for the transmission quality measurement. In one embodiment, the measurement requirement information may include a ninth parameter indicating a reporting criterion for reporting measurement results of the transmission quality measurement. In one embodiment, the measurement requirement information may include a tenth parameter indicating a service quality guarantee policy associated with the SEALDD flow.

[0194] In one embodiment, the reporting criteria may include reporting the measurement if the delay or bit rate is higher or lower than a value. In one embodiment, the reporting criteria may include a unique identifier for each criterion of the predefined plurality of criteria.

[0195] In one embodiment, the service level policy may include an eleventh parameter indicating an event that triggers a service level action. In one embodiment, the service level policy may include a twelfth parameter indicating a service level action to be performed when the event occurs.

[0196] In one embodiment, the event may include reaching a measurement threshold.

[0197] The method 700 may then proceed to step S702, where the first network function (e.g., SEALDD server 212) may receive a response message from the VALUE in response to the subscription message. In one embodiment, the response message may be a transmission quality measurement subscription response.

[0198] In one embodiment, the response message may include a 22nd parameter indicating whether the subscription was successful or unsuccessful. In one embodiment, the response message may include a 23rd parameter indicating an expiration date for the subscription if the 22nd parameter indicates a successful subscription.

[0199] The method 700 may then proceed to step S703, where the first network function (e.g., SEALDD server 212) may receive a notification message from the VALUE to provide a report of the plurality of measurement results of the transmission quality measurement. In one embodiment, the notification message may be a transmission quality measurement notification.

[0200] In one embodiment, the notification message may include a thirteenth parameter indicating a list of transmission quality measurement reports generated for the transmission quality measurement.

[0201] In one embodiment, the transmission quality measurement report list may further include a fourteenth parameter indicating a measurement related to any one or a combination of delay, bit rate, or packet loss rate based on the fourth parameter. In one embodiment, the transmission quality measurement report list may further include a fifteenth parameter indicating an average measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a sixteenth parameter indicating a minimum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a seventeenth parameter indicating a maximum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include an eighteenth parameter indicating a standard deviation of the measurement values ​​of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a nineteenth parameter indicating a k-percentile measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a twentieth parameter indicating a measurement period of the plurality of measurement results based on the seventh parameter. In one embodiment, the transmission quality measurement report list may further include a twenty-first parameter indicating a timestamp of the plurality of measurement results.

[0202] The above steps are merely examples, and the first network function may perform any of the associated operations described with respect to FIGS. 1-6B, 15, and 16.

[0203] 8 is a schematic flowchart illustrating an example method 800 in a UE, according to an embodiment herein. In one embodiment, the flowchart of FIG. 8 may be implemented in a UE 201 including the SEALDD client 222 of FIGS. 1-6B, 15, and 16.

[0204] The method 800 may begin at step S801, in which the UE 201 (including the SEALDD client 222) may receive a subscription message to request reporting of transmission quality measurements for VAL UE traffic. In one embodiment, the subscription message may be a transmission quality measurement subscription request received from a network function implementing a SEALDD server or a second functional component implementing a VAL client.

[0205] In one embodiment, the subscription message may include a first parameter indicating at least one VAL application traffic to be measured. In one embodiment, the subscription message may include a second parameter indicating measurement requirement information. In one embodiment, the subscription message may include a third parameter indicating one or more measurement conditions for the transmission quality measurement.

[0206] In one embodiment, the one or more measurement conditions may include one or more spatial conditions and / or one or more temporal conditions. In one embodiment, if the one or more conditions are not met, the first functional component implementing the SEALDD client may stop or suspend the transmission quality measurements.

[0207] In one embodiment, the measurement requirement information may include a fourth parameter indicating measurements related to any one or a combination of delay, bit rate, or packet loss rate. In one embodiment, the measurement requirement information may include a fifth parameter indicating whether reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a sixth parameter indicating a reporting period if reporting is set to periodic reporting. In one embodiment, the measurement requirement information may include a seventh parameter indicating a measurement period window for the transmission quality measurement. In one embodiment, the measurement requirement information may include an eighth parameter indicating a measurement expiration time for the transmission quality measurement. In one embodiment, the measurement requirement information may include a ninth parameter indicating a reporting criterion for reporting measurement results of the transmission quality measurement. In one embodiment, the measurement requirement information may include a tenth parameter indicating a service quality guarantee policy associated with the SEALDD flow.

[0208] In one embodiment, the reporting criteria may include reporting the measurement if the delay or bit rate is higher or lower than a value. In one embodiment, the reporting criteria may include a unique identifier for each criterion of the predefined plurality of criteria.

[0209] In one embodiment, the service level policy may include an eleventh parameter indicating an event that triggers a service level action. In one embodiment, the service level policy may include a twelfth parameter indicating a service level action to be performed when the event occurs.

[0210] In one embodiment, the event may include reaching a measurement threshold.

[0211] The method 800 may then proceed to step S802, where the UE 201 (including the SEALDD client 222) may send a response message in response to the subscription message. In one embodiment, the response message may be a transmission quality measurement subscription response sent to a network function implementing a SEALDD server or a second functional component implementing a VAL client.

[0212] In one embodiment, the response message may include a 22nd parameter indicating whether the subscription was successful or unsuccessful. In one embodiment, the response message may include a 23rd parameter indicating an expiration date for the subscription if the 22nd parameter indicates a successful subscription.

[0213] The method 800 may then proceed to step S803, where the UE 201 (including the SEALDD client 222) may perform transmission quality measurements.

[0214] In one embodiment, the UE 201 (including the SEALDD client 222) can decide to start a measurement process. In one embodiment, the UE 201 (including the SEALDD client 222) can start an uplink packet delay measurement. In one embodiment, the UE 201 (including the SEALDD client 222) can obtain multiple measurement results.

[0215] The method 800 may then proceed to step S804, in which the UE 201 (including the SEALDD client 222) may send a notification message to provide a report of multiple measurement results of the transmission quality measurements.

[0216] In one embodiment, the notification message may be a transmission quality measurement notification sent to a network function implementing a SEALDD server or a second functional component implementing a VAL client.

[0217] In one embodiment, the transmission quality measurement report list may further include a fourteenth parameter indicating a measurement related to any one or a combination of delay, bit rate, or packet loss rate based on the fourth parameter. In one embodiment, the transmission quality measurement report list may further include a fifteenth parameter indicating an average measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a sixteenth parameter indicating a minimum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a seventeenth parameter indicating a maximum measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include an eighteenth parameter indicating a standard deviation of the measurement values ​​of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a nineteenth parameter indicating a k-percentile measurement value of the plurality of measurement results. In one embodiment, the transmission quality measurement report list may further include a twentieth parameter indicating a measurement period of the plurality of measurement results based on the seventh parameter. In one embodiment, the transmission quality measurement report list may further include a twenty-first parameter indicating a timestamp of the plurality of measurement results.

[0218] The above steps are merely examples, and the UE may perform any associated operations described with respect to FIGS. 1-6B, 15, and 16.

[0219] 9 is a schematic flowchart illustrating another exemplary method 900 in a UE, according to an embodiment herein. In one embodiment, the flowchart of FIG. 9 may be implemented in a UE 201 including the SEALDD client 222 and the VAL client 121 of FIGS. 1-6B, 15, and 16.

[0220] The method 900 may begin at step S901, in which the UE 201 (including the SEALDD client 222 and the VAL client 121) may perform a transmission quality measurement subscription request. In one embodiment, the method may include transmitting a subscription message from the second functional component to the first functional component to request reporting of transmission quality measurements for VAL UE traffic. The UE 201 may use messages or parameters similar to those described in FIGS. 5A, 5B, 7, and 8 for the request.

[0221] The method 900 may then proceed to step S902, where the UE 201 (including the SEALDD client 222 and the VAL client 121) may perform transmission quality measurement notification. In one embodiment, the method may further include sending a notification message from the first functional component to the second functional component to provide a report of multiple measurement results of the transmission quality measurements. The UE 201 may use a message or parameters similar to those described in FIGS. 5A, 5B, 7, and 8 for notification.

[0222] The above steps are merely examples, and the UE may perform any associated operations described with respect to FIGS. 1-6B, 15, and 16.

[0223] 10 is a schematic flowchart illustrating another exemplary method 1000 in a first network function, according to embodiments herein. In one embodiment, the flowchart of FIG. 10 may be implemented in the SEALDD server 212 of FIGS. 1-6B, 15, and 16.

[0224] Method 1000 may start at step S1001, in which a first network function (such as SEALDD server 212) may initiate a data transmission quality measurement process for a transmission path. For example, the first network function (such as SEALDD server 212) may initiate a data transmission quality measurement process as shown in FIG.

[0225] In one embodiment, a transmission path may be formed between a second functional component implementing a VAL client of the UE and a second network function implementing a VAL server via a first functional component implementing a SEALDD client and a first network function implementing a SEALDD server.

[0226] The method 1000 may then proceed to step S1002, in which a first network function (e.g., the SEALDD server 212) may send a first request message to a VALUE to request a transmission quality assurance operation based on the measured data transmission quality. The VALUE may include a first functional component that implements a SEALDD client.

[0227] In one embodiment, the first request message may include a 24th parameter indicating at least one VAL application traffic measured. In one embodiment, the first request message may include a 25th parameter indicating a transmission quality assurance operation.

[0228] In one embodiment, the transmission quality assurance operation may further include establishing a redundant transmission path. In one embodiment, the transmission quality assurance operation may further include re-establishing the transmission path. In one embodiment, the transmission quality assurance operation may further include switching to a backup transmission path.

[0229] In one embodiment, the first request message may be an application trigger message. In one embodiment, the 25th parameter may indicate a trigger for redundant connection setup, connection re-establishment, or connection switching for transmitting a SEALDD packet.

[0230] Method 1000 may then proceed to step S1003, where the first network function (e.g., SEALDD server 212) may receive a transmission quality assurance response message from VALUE. In one embodiment, the transmission quality assurance response message may include a 26th parameter indicating whether the request was successful or unsuccessful.

[0231] Method 1000 may then proceed to step S1004, in which the first network function (e.g., SEALDD server 212) may send a second request message to VALUE to request the use of a single transmission path.

[0232] The above steps are merely examples, and the first network function may perform any of the associated operations described with respect to FIGS. 1-6B, 15, and 16.

[0233] 11 is a schematic flowchart illustrating yet another exemplary method 1100 in a UE, according to an embodiment herein. In one embodiment, the flowchart of FIG. 11 may be implemented in a UE 201 including the SEALDD client 222 of FIGS. 1-6B, 15, and 16.

[0234] Method 1100 may begin with optional step S1101, in which UE 201 (including SEALDD client 222) may receive a first request message to request transmission quality assurance operation from a first network function implementing a SEALDD server.

[0235] In one embodiment, the first request message may include a 24th parameter indicating at least one VAL application traffic measured. In one embodiment, the first request message may include a 25th parameter indicating a transmission quality assurance operation.

[0236] In one embodiment, the first request message may be an application trigger message. In one embodiment, the 25th parameter may indicate a trigger for redundant connection setup, connection re-establishment, or connection switching for transmitting a SEALDD packet.

[0237] In one embodiment, a transmission path may be formed between a second functional component implementing a VAL client of the UE and a second network function implementing a VAL server via a first functional component implementing a SEALDD client and a first network function implementing a SEALDD server.

[0238] The method 1100 may then proceed to optional step S1102, in which the UE 201 (including the SEALDD client 222) may perform a data transmission quality measurement process for the transmission path. For example, the UE 201 (including the SEALDD client 222) may initiate a data transmission quality measurement process as shown in FIG. 5A or 5B.

[0239] The method 1100 may then proceed to step S1103, in which the UE 201 (including the SEALDD client 222) may send a transmission quality assurance response message to the first network function implementing the SEALDD server. In one embodiment, the transmission quality assurance message may include a 26th parameter indicating whether the first request was successful or unsuccessful.

[0240] The method 1100 may then proceed to step S1104, where the UE 201 (including the SEALDD client 222) may decide to perform a transmission quality assurance operation.

[0241] In one embodiment, the transmission quality assurance operation is in response to receiving a first request message (as shown in step S1101) for requesting a transmission quality assurance operation from a first network function implementing a SEALDD server.

[0242] In one embodiment, the transmission quality assurance operation is based on the measured data transmission quality of the transmission path in a data transmission quality measurement process (as shown in step S1102).

[0243] In one embodiment, the transmission quality assurance operation may further include establishing a redundant transmission path. In one embodiment, the transmission quality assurance operation may further include re-establishing the transmission path. In one embodiment, the transmission quality assurance operation may further include switching to a backup transmission path.

[0244] In one embodiment, performing the transmission quality assurance operation may further include establishing an additional transmission path for redundancy. In one embodiment, performing the transmission quality assurance operation may further include establishing two new transmission paths and releasing the existing transmission path for redundancy. In one embodiment, performing the transmission quality assurance operation may further include releasing the existing transmission path and establishing a new transmission path. In one embodiment, performing the transmission quality assurance operation may further include switching to a backup transmission path and disabling the existing transmission path.

[0245] The method 1100 may then proceed to step S1105, where the UE 201 (including the SEALDD client 222) may decide to use a single transmission path. In one embodiment, the decision to use a single transmission path is made in response to a second request message from a first network function implementing a SEALDD server, requesting to use a single transmission path. In one embodiment, the decision to use a single transmission path is made based on the measured data transmission quality of another data transmission quality measurement process of the transmission path.

[0246] In one embodiment, the method may further include releasing at least one transmission path and returning to a single SEALDD connection mode.

[0247] The above steps are merely examples, and the UE may perform any associated operations described with respect to FIGS. 1-6B, 15, and 16.

[0248] 12 is a schematic block diagram illustrating an exemplary first network function 1200 according to embodiments herein. In one embodiment, the exemplary first network function 1200 of FIG. 12 may be implemented as the SEALDD server 212 of FIGS. 1-6B, 15, and 16.

[0249] In one embodiment, the first network function 1200 may include at least one processor 1201 and a non-transitory computer-readable medium 1202 coupled to the at least one processor 1201. The non-transitory computer-readable medium 1202 may store instructions executable by the at least one processor 1201, whereby the at least one processor 1201 is configured to perform steps in the exemplary methods 700 and 1000 as shown in the schematic flowcharts of Figures 7 and 10, the details of which are omitted herein.

[0250] It should be noted that first network function 1200 may be implemented as hardware, software, firmware, and any combination thereof. For example, first network function 1200 may include multiple units, circuits, modules, etc., each of which may be used to perform one or more steps of example methods 700 and 1000, or one or more steps illustrated in Figures 1-6B, 15, and 16 associated with a first network function (e.g., SEALDD server 212).

[0251] 13 is a schematic block diagram illustrating an example UE 201 according to an embodiment of the present disclosure. In one embodiment, the example UE 201 of FIG. 13 may be implemented as including the SEALDD client 222 and the VAL client 121 of FIGS. 1-6B, 15, and 16.

[0252] In one embodiment, the UE 201 may include at least one processor 1301 and a non-transitory computer-readable medium 1302 coupled to the at least one processor 1301. The non-transitory computer-readable medium 1302 may store instructions executable by the at least one processor 1301, whereby the at least one processor 1301 is configured to perform steps in the exemplary methods 800, 900, 1100 as shown in the schematic flowcharts of Figures 8, 9, 11, details of which are omitted herein.

[0253] It should be noted that the UE 201 may be implemented as hardware, software, firmware, and any combination thereof. For example, the UE 201 may include multiple units, circuits, modules, etc., each of which may be used to perform one or more steps of the exemplary methods 800, 900, 1100, or one or more steps illustrated in Figures 1-6B, 15, and 16 associated with the UE 201 (including the SEALDD client 222 and the VAL client 121).

[0254] 14 is a schematic block diagram illustrating an example computer-implemented apparatus 1400 according to embodiments herein. In one embodiment, the apparatus 1400 may be configured as the apparatus described above, such as the UE 101 or a functional component thereof (such as the VAL client 121 and / or the SEAL client 122), the UE 201 or a functional component thereof (such as the VAL client 121 and / or the SEALDD client 222), a first network function (such as the VAL server 111), or a second network function (such as the SEALDD server 212).

[0255] In one embodiment, the device 1400 may include, but is not limited to, at least one processor, such as a central processing unit (CPU) 1401, a computer-readable medium 1402, and a memory 1403. The memory 1403 may include volatile (e.g., random access memory, RAM) and / or non-volatile memory (e.g., a hard disk or flash memory). In one embodiment, the computer-readable medium 1402 may be configured to store computer programs and / or instructions that, when executed by the processor 1401, cause the processor 1401 to perform any of the methods described above.

[0256] In one embodiment, computer readable medium 1402 (e.g., a non-transitory computer readable medium) may be stored on memory 1403. In another embodiment, the computer program may be stored in a remote location, such as in computer program product 1404 (which may be embodied as a computer readable medium), and may be accessible by processor 1401, for example, via carrier medium 1405.

[0257] The computer readable medium 1402 and / or the computer program product 1404 may be distributed and / or stored on a removable computer readable medium, such as a diskette, a CD (compact disc), a DVD (digital video disc), flash or similar removable memory medium (e.g., CompactFlash, SD (Secure Digital), Memory Stick, Mini SD card, MMC multimedia card, SmartMedia), HD-DVD (High Definition DVD) or Blu-ray DVD, USB (Universal Serial Bus) based removable memory medium, magnetic tape medium, optical storage medium, magneto-optical medium, bubble memory, or may be distributed as a signal transmitted over a network (e.g., Ethernet, ATM, ISDN, PSTN, X.25, the Internet, a local area network (LAN), or similar network capable of transmitting data packets to infrastructure nodes).

[0258] Furthermore, the current The following amendments are proposed to amend 3GPP TS 23.433v1.2.0:

[0259] Title: Complete Transmission Quality Measurement introduction: This pCR modifies and complements the SEALDD data transmission quality measurement procedure.

[0260] Reason for change: The SEALDD data transmission quality measurement procedure is incomplete.

[0261] Currently, section 9.7.2.3, step 1, states that SEALDD measurement information is configured at the SEALDD client. This configuration is not yet supported.

[0262] 1. The VAL client and server establish a SEALDD connection for transmitting application data. As part of the connection establishment, the SEALDD service policy from Precondition 1 is shared for use by both the SEALDD client and the SEALDD server. The SEALDD server may use the data transmission quality requirements of this policy in combination with other local policies pre-configured on the SEALDD server. As a result, SEALDD measurements (packet loss rate, delay, etc.) are configured on the SEALDD client as described in Section 9.7.2.1, and the SEALDD client receives measurement reports.

[0263] The process proposed in this paper is that the SEALDD client or server initiates data transmission quality measurement.

[0264] Proposed changes: ***First Change*** (Proposed changes include the following new section to be added to 3GPP TS 23.433): 9.7.2.x Data Transmission Quality Measurements Reported by SEALDD Clients Figure 9.7.2.x-1 (see Figure 15) shows the SEALDD-enabled data transmission quality measurement procedure for VAL traffic. The SEALDD client receives the transmission quality measurement requirement, decides to start VAL data transmission monitoring, and generates a measurement report.

[0265] Figure 9.7.2.x-1 (See Figure 15) VAL Data Transmission Quality Measurements Reported by SEALDD Client 1. An ongoing normal data transmission connection is established in accordance with Section 9.2.2.2.

[0266] The transmission quality measurement can be initiated by the VAL server or the VAL client, which is described in steps 2 to 5 and step 6, respectively.

[0267] 2. The VAL server sends a SEALDD transmission quality measurement subscription request to the SEALDD server. The request includes an application traffic identifier (e.g., VAL service ID, VAL server ID), transmission quality measurement requirements (e.g., delay, jitter, bit rate), and target UEs (e.g., a single UE, a group of UEs, or all UEs), and may also include reporting criteria, reporting frequency, spatial conditions, and temporal conditions.

[0268] Note: Spatial and / or temporal conditions can be used by the SEALDD client to apply when and where measurements are performed. For example, for a group of VALUEs with a planned route (from city A to city B via highways A2 and A3), measurements are assumed to be taken on Tuesdays from 9:00 AM to 11:00 AM and on Thursdays from 1:00 PM to 5:00 PM.

[0269] 3. Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, the SEALDD server responds to the VAL server.

[0270] 4-5. The SEALDD server sends a SEALDD transmission quality measurement subscription request to the SEALDD client, and the SEALDD client responds to the SEALDD server. Based on the received service quality policy, including thresholds and actions, the SEALDD client can take corrective action as described in Section 9.7.2.3.

[0271] 6. The VAL client initiates the SEALDD transmission quality measurement procedure to the SEALDD client to collect measurement report information.

[0272] 7. After the SEALDD client decides to start the measurement process, when a UL packet arrives, the SEALDD client starts UL packet delay measurement. When the SEALDD client sends out a UL monitoring packet, it encapsulates the UL monitoring packet (i.e., a UL SEALDD packet with a SEALDD UL monitoring header and VAL traffic as the payload for VAL data transmission quality monitoring) at local time T1. The SEALDD client considers spatial and / or temporal conditions when starting / resumes transmission quality measurement. If the conditions are not met, the SEALDD client stops / suspends transmission quality measurement.

[0273] 8. The SEALDD server receives the UL monitoring packet and records the local time T2.

[0274] 9. Similarly, the SEALDD server encapsulates the DL monitoring packet (i.e., a DL SEALDD packet having a SEALDD DL monitoring header and VAL traffic as a payload, or a dummy UL SEALDD packet generated for data transmission quality monitoring when there is no DL VAL traffic for DL ​​packet delay monitoring) with the local time T2 recorded in step 8 and the local time T3 when the SEALDD server sends the DL monitoring packet.

[0275] Note: The timing at which the SEALDD server sends a dummy UL packet as a monitoring response to the SEALDD client depends on the implementation of the SEALDD server.

[0276] 10. The SEALDD client records the local time T4 when the SEALDD client receives the DL monitor packet and uses T1, T2, T3, and T4 to calculate the delay. The SEALDD client can also calculate the bit rate and jitter over a period of time on a particular SEALDD connection by recording the status of the SEALDD monitor packet. The SEALDD client also evaluates the reporting criteria, if present, in the SEALDD Transmission Quality Measurement Subscription Request to generate a Transmission Quality Measurement Report.

[0277] Depending on which entity initiates the data transmission quality measurement, steps 11 and 12 correspond to steps 2 to 5, and step 13 corresponds to step 6.

[0278] 11-12. The SEALDD client reports data transmission quality measurement results (e.g., delay, jitter, bit rate) to the VAL server via the SEALDD server.

[0279] 13. The SEALDD client reports the data transmission quality measurement results to the VAL client.

[0280] In step 2, if a VAL Group ID or a list of VAL UE IDs or all VAL UE indications are received, steps 4 to 11 are repeated for the VAL UEs in the group / list or for all VAL UEs. If a VAL Group ID is received, the SEALDD server maps the VAL UE Group ID to a list of VAL UE IDs. The SEALDD server identifies the SEALDD connection corresponding to the desired VAL UE to initiate measurements. Depending on the reporting requirements for multiple UEs, the SEALDD server also collects and aggregates the necessary reports for the VAL Server.

[0281] 9.7.3.x1 Transmission Quality Measurement Subscription Request Table 9.7.3.x1-1 shows the information flow from SEALDD Server to SEALDD Client for Data Transmission Measurement Subscription.

[0282] Table 9.7.3.x1-1: Transmission Quality Measurement Subscription Request [Table 9]

[0283] Transmission Quality Measurement Subscription Response Table 9.7.3.x2-1 shows the information flow from a SEALDD client to a SEALDD server to respond to a transmission quality measurement subscription request.

[0284] Table 9.7.3.x2-1: Transmission Quality Measurement Subscription Response [Table 10]

[0285] 9.7.3.x3 Transmission quality measurement notification Table 9.7.3.3-1 shows the information flow for transmission quality measurement report notification from the SEALDD client to the SEALDD server.

[0286] Table 9.7.3.3-1: Transmission quality measurement notification [Table 11]

[0287] ***Second Change*** (Proposed changes include replacing current section 9.7.2.3) 9.7.2.3 SEALDD-compliant data transmission quality assurance through redundant transmission Figure 9.7.2.3-1 (see Figure 16) shows the procedure for using redundant transmission as an operation to meet the connection reliability requirements specified by the SEALDD service policy.

[0288] Prerequisites: 1. SEALDD service policies, including data transmission quality guarantees, are available to SEALDD servers, SEALDD clients, and / or VAL clients. The policies can be used to configure measurements and determine the SEALDD layer actions necessary to meet service policy requirements.

[0289] 2. SEALDD clients have the authority to request redundant transmission services on behalf of VAL clients.

[0290] Figure 9.7.2.3-1 (See Figure 16) SEALDD data transmission quality assurance by redundant transmission 1. The VAL client and server establish a SEALDD connection for transmitting application data. As part of the connection establishment, the SEALDD service policy from Prerequisite 1 is shared for use by both the SEALDD client and the SEALDD server. The SEALDD server may use the data transmission quality requirements of this policy in combination with other local policies preconfigured on the SEALDD server. The SEALDD service policy may be configured locally on the SEALDD server or may be provided by the VAL server and accepted / acknowledged by the SEALDD server. The SEALDD server decides whether data transmission quality measurements should be initiated independently or by the SEALDD client. As a result, SEALDD measurements (packet loss rate, delay, etc.) are configured on the SEALDD client as described in Section 9.7.2.x or on the SEALDD server as described in Section 9.7.2.1 and initiated accordingly. Then, either the SEALDD server or the client receives the measurement reports.

[0291] 2. Based on the measurement report and the SEALDD service policy, either the SEALDD client or server, depending on the entity that initiated the measurement, decides to perform an action so that the data transmission quality requirements of the policy are met.

[0292] 3. Specifically, if the measurement is initiated by a SEALDD client, the SEALDD client triggers the establishment of a redundant transmission service. If the measurement is initiated by a SEALDD server, the SEALDD server triggers the establishment of a redundant transmission service by sending a transmission quality assurance request to the SEALDD client requesting the establishment of a redundant transmission path.

[0293] Note: The request can be sent to the SEALDD client via an application trigger (specified in section 4.13.2 of 3GPP TS 23.502 [6]) with a payload indicating the initiation of the redundant connection setup for sending SEALDD packets.

[0294] 4. The SEALDD client requests the use of the redundant transmission service from the SEALDD server using steps 6 to 9 of the procedure in section 9.3.2.1. As part of this step, the UE may terminate the initial PDU session and establish a redundant PDU session.

[0295] 5. The SEALDD client updates the SEALDD connection with the redundant transmission information, i.e., UE address and port for the redundant PDU session, SEALDD flow identifier, and application traffic descriptor. The SEALDD client or server also configures parameters to enable any required SEALDD measurements for the new SEALDD flow.

[0296] 6. The SEALDD server can subscribe to receive notifications from the 5G network about user plane measurements (e.g., network delay requirements as specified in 3GPP TS 28.541

[12] ), network analytics (such as those specified in 3GPP TS 28.104

[11] ).

[0297] 7. SEALDD clients and servers handle data deduplication and elimination of application traffic on redundant SEALDD flows, and the necessary measurements are collected by the SEALDD client or server.

[0298] If the SEALDD measurement results indicate that the SEALDD data transmission has good performance according to the policy guarantee threshold, and if the measurement was initiated by the SEALDD client, the SEALDD client can release one transmission path and return to single SEALDD connection mode; if not, the SEALDD server can send a request to the SEALDD client requesting to use a single transmission, and the SEALDD client will release one transmission path and return to single SEALDD connection mode.

[0299] *** Third Change *** (Proposed changes include the following new section to be added to 3GPP TS 23.433): 9.7.3.x4 Transmission quality assurance requirements Table 9.7.3.x4-1 shows the information flow for data transmission quality assurance requests from the SEALDD server to the SEALDD client.

[0300] Table 9.7.3.x4-1: Transmission quality assurance requirements [Table 12]

[0301] 9.7.3.x5 Transmission Quality Assurance Response Table 9.7.3.x5-1 shows the information flow for the transmission quality assurance request response from the SEALDD client to the SEALDD server.

[0302] Table 9.7.3.x5-1: Transmission Quality Assurance Response [Table 13] ***END OF CHANGE***

[0303] Exemplary embodiments are described herein with reference to block diagrams and / or flowchart illustrations of computer-implemented methods, apparatus (systems and / or devices), and / or non-transitory computer program products. It should be understood that a block of the block diagrams and / or flowchart illustrations, or combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by computer program instructions executed by one or more computer circuits. These computer program instructions can be provided to processor circuits of general-purpose computer circuits, special-purpose computer circuits, and / or other programmable data processing circuits to produce machine-readable instructions that, when executed via the processor of the computer and / or other programmable data processing apparatus, transform and control transistors, values ​​stored in memory locations, and other hardware components within such circuits to implement the function(s) / operations specified in the block diagram and / or flowchart block(s), thereby producing means (functions) and / or structure for implementing the function(s) / operations specified in the block diagram and / or flowchart block(s).

[0304] These computer program instructions may also be stored on a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored on the computer-readable medium generate an article of manufacture that includes instructions that implement the functions / acts specified in the block diagram and / or flowchart block or blocks. Thus, embodiments of the inventive concepts may be embodied in hardware and / or software (including firmware, resident software, microcode, etc.) running on a processor, such as a digital signal processor, which may collectively be referred to as a "circuit," "module," or variations thereof.

[0305] It should also be noted that in some alternative implementations, the functions / acts noted in the blocks may occur in a different order than that noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or may be executed in the reverse order, depending on the functions / acts involved in the blocks. Furthermore, the functionality of a given block in the flowcharts and / or block diagrams may be separated into multiple blocks, and / or the functionality of two or more blocks in the flowcharts and / or block diagrams may be at least partially integrated. Finally, other blocks may be added / inserted between the illustrated blocks, and / or blocks / acts may be omitted without departing from the scope of the inventive concept. Furthermore, while some of the figures include arrows on communication paths to indicate a primary direction of communication, it should be understood that communication may occur in a direction opposite to that of the illustrated arrows.

[0306] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the inventive concept. All such variations and modifications are intended to be included within the scope of the inventive concept. Accordingly, the subject matter disclosed above should be considered illustrative and not limiting, and the accompanying example embodiments are intended to encompass all such modifications, improvements, and other embodiments that fall within the spirit and scope of the inventive concept. Therefore, to the maximum extent permitted by law, the scope of the inventive concept should be determined by the broadest permissible interpretation of this disclosure, including the following example embodiments and their equivalents, and is not intended to be limited or constrained by the foregoing detailed description.

[0307] Abbreviation 3GPP 3rd Generation Partnership Project API Application Programming Interface DD Data Delivery DL Downlink OTT Over The Top QoS Quality of Service SEAL Service Enablement Architecture Layer for Verticals SEALDD SEAL Data Delivery UE User Equipment UP Uplink V2X vehicle to everything VAL Vertical Application Layer.

Claims

1. 1. A method (700) performed by a first network function (212) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) server, comprising: - sending a subscription message to a vertical application layer (VAL) user equipment (UE) (201) (S701) to request a report of transmission quality measurements for said VAL UE (201) traffic, said VAL UE (201) including a first functional component (222) implementing a SEALDD client; receiving (S703) from said VAL UE (201) a notification message for providing said report of a plurality of measurement results of said transmission quality measurements; A method (700) comprising:

2. The subscription message: a first parameter indicative of at least one VAL application traffic to be measured; a second parameter indicating measurement requirement information; 10. The method of claim 1, comprising:

3. The subscription message further comprises: a third parameter indicating one or more measurement conditions for the transmission quality measurement; The method (700) of claim 2, comprising:

4. the one or more measurement conditions include one or more spatial conditions and / or one or more temporal conditions; and / or If the one or more conditions are not met, the first functional component (222) implementing the SEALDD client stops or suspends the transmission quality measurements.

4. The method (700) of claim 3.

5. The measurement requirement information includes: a fourth parameter indicating a measurement related to any one or a combination of delay, bit rate, or packet loss rate; The method (700) of any one of claims 2 to 4, comprising:

6. The measurement requirement information includes: a fifth parameter indicating whether the reporting is set to periodic reporting; a sixth parameter indicating a reporting period if the reporting is set to periodic reporting; a seventh parameter indicating a measurement period window for the transmission quality measurement; an eighth parameter indicating a measurement expiration time for the transmission quality measurement; a ninth parameter indicating a reporting standard for reporting measurement results of the transmission quality measurement; a tenth parameter indicating a level of service policy associated with the SEALDD flow; The method (700) of claim 5, further comprising at least one of:

7. The reporting criteria include reporting the measurement result if the delay or bit rate is higher or lower than a value; and / or the reporting criteria include a unique identifier for each criterion of a predefined plurality of criteria; 7. The method (700) of claim 6.

8. The service level agreement policy: an eleventh parameter indicating an event that triggers quality assurance action; a twelfth parameter indicating the quality assurance action to be performed when the event occurs; The method (700) of claim 6 or 7, comprising:

9. 9. The method (700) of claim 8, wherein the event comprises reaching a measurement threshold.

10. The notification message includes: a thirteenth parameter indicating a list of transmission quality measurement reports generated for the transmission quality measurement; The method (700) of any one of claims 1 to 9, comprising:

11. The transmission quality measurement report list further comprises: a fourteenth parameter indicating a measurement value for any one or a combination of delay, bit rate, or packet loss rate based on the fourth parameter; 11. The method (700) of claim 10, comprising:

12. The transmission quality measurement report list includes: a fifteenth parameter indicating an average measurement value of the plurality of measurement results; a sixteenth parameter indicating the minimum measurement value of the plurality of measurements; a seventeenth parameter indicating a maximum measurement value of the plurality of measurement results; an eighteenth parameter indicating the standard deviation of the measurement values ​​of the plurality of measurement results; a nineteenth parameter indicative of a k-percentile measurement of the plurality of measurements; a twentieth parameter indicating a measurement period for the plurality of measurement results based on the seventh parameter; a 21st parameter indicating a timestamp of the plurality of measurements; 12. The method (700) of claim 11, further comprising at least one of:

13. receiving (S702) from the VAL UE (201) a response message in response to the subscription message, receiving a response message (S702), the response message including a 22nd parameter indicating whether the subscription was successful or unsuccessful; The method (700) of any one of claims 1 to 12, further comprising:

14. 14. The method (700) of claim 13, wherein the response message further comprises a 23rd parameter indicating an expiration date for the subscription if the 22nd parameter indicates success of the subscription.

15. The subscription message is a transmission quality measurement subscription request, the notification message is a transmission quality measurement notification; and / or the response message is a transmission quality measurement subscription response; The method (700) of any one of claims 1 to 14.

16. 1. A method (800) performed by a Vertical Application Layer (VAL) User Equipment (UE) (201) including a first functional component (222) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) client, comprising: - receiving a subscription message (S801) from a network function (212) implementing a SEAL DD server or a second functional component (121) in the VAL UE (201) implementing a VAL client, for requesting a report of transmission quality measurements for the VAL UE (201) traffic; sending a notification message (S804) to provide a report of a plurality of measurement results of said transmission quality measurements; A method (800) comprising:

17. The subscription message: a first parameter indicative of at least one VAL application traffic to be measured; a second parameter indicating measurement requirement information; 17. The method (800) of claim 16, comprising:

18. The subscription message: a third parameter indicating one or more measurement conditions for the transmission quality measurement; 20. The method (800) of claim 17, further comprising:

19. the one or more measurement conditions include one or more spatial conditions and / or one or more temporal conditions; and / or If the one or more conditions are not met, the first functional component (222) implementing the SEALDD client stops or suspends the transmission quality measurements.

20. The method (800) of claim 18.

20. The measurement requirement information includes: a fourth parameter indicating a measurement related to any one or a combination of delay, bit rate, or packet loss rate; The method (800) of any one of claims 17 to 19, comprising:

21. The measurement requirement information includes: a fifth parameter indicating whether the reporting is set to periodic reporting; a sixth parameter indicating a reporting period if the reporting is set to periodic reporting; a seventh parameter indicating a measurement period window for the transmission quality measurement; an eighth parameter indicating a measurement expiration time for the transmission quality measurement; a ninth parameter indicating a reporting standard for reporting measurement results of the transmission quality measurement; a tenth parameter indicating a service level policy associated with the SEALDD flow; 21. The method (800) of claim 20, further comprising at least one of:

22. the reporting criteria include reporting the measurement if the delay or bit rate is higher or lower than a value; and / or the reporting criteria including a unique identifier for each criterion of a predefined plurality of criteria; 22. The method (800) of claim 21.

23. The service level agreement policy: an eleventh parameter indicating an event that triggers quality assurance action; a twelfth parameter indicating a quality assurance action to be taken when the event occurs; 23. The method (800) of claim 21 or 22, comprising:

24. 24. The method (800) of claim 23, wherein the event comprises reaching a measurement threshold.

25. - deciding to start the measurement process (S803); - initiating said uplink packet delay measurement; - obtaining said plurality of measurements; 25. The method (800) of claim 24, further comprising:

26. The notification message includes: a thirteenth parameter indicating a list of transmission quality measurement reports generated for the transmission quality measurement; The method (800) of any one of claims 16 to 25, comprising:

27. The transmission quality measurement report list includes: a fourteenth parameter indicating a measurement value for any one or a combination of delay, bit rate, or packet loss rate based on the fourth parameter; 27. The method (800) of claim 26, further comprising:

28. The transmission quality measurement report list includes: a fifteenth parameter indicating an average measurement value of the plurality of measurement results; a sixteenth parameter indicating the minimum measurement value of the plurality of measurements; a seventeenth parameter indicating a maximum measurement value of the plurality of measurement results; an eighteenth parameter indicating the standard deviation of the measurement values ​​of the plurality of measurement results; a nineteenth parameter indicative of a k-percentile measurement of the plurality of measurements; a twentieth parameter indicating a measurement period for the plurality of measurement results based on the seventh parameter; a 21st parameter indicating a timestamp of the plurality of measurements; 28. The method (800) of claim 27, further comprising at least one of:

29. sending a response message in response to said subscription message, sending a response message, the response message including a 22nd parameter indicating whether the subscription was successful or unsuccessful; The method (800) of any one of claims 16 to 28, further comprising:

30. 30. The method (800) of claim 29, wherein the response message further includes a 23rd parameter indicating an expiration date for the subscription if the 22nd parameter indicates success of the subscription.

31. The subscription message is a transmission quality measurement subscription request, said notification message being a transmission quality measurement notification sent to said network function implementing said SEALDD server (212) or said second functional component implementing said VAL client (121); and / or the response message is a transmission quality measurement subscription response sent to the network function (212) implementing the SEALDD server or the second functional component (121) implementing the VAL client; The method (800) of any one of claims 16 to 30.

32. 1. A method (900) performed by a Vertical Application Layer (VAL) User Equipment (UE) (201) including a first functional component (222) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) client and a second functional component (121) implementing a VAL client, comprising: - sending a subscription message from the second functional component (121) to the first functional component (222) to request a report of transmission quality measurements for the VAL UE (201) traffic (S901); sending (902) a notification message from said first functional component (222) to said second functional component (121) providing a report of a plurality of measurement results of said transmission quality measurements; A method (900).

33. - determining the start of said measurement process; - initiating said uplink packet delay measurement; - obtaining said plurality of measurements; 33. The method (900) of claim 32, further comprising:

34. 1. A method (1000) performed by a first network function (212) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) server, comprising: Initiating a data transmission quality measurement process of a transmission path (S1001); - sending (S1002) a first request message to a Vertical Application Layer (VAL) User Equipment (UE) (201) for requesting a transmission quality assurance operation based on the measured data transmission quality, wherein the VAL UE (201) includes a first functional component (222) implementing a SEALDD client; A method (1000).

35. The first request message includes: a 24th parameter indicative of the measured at least one VAL application traffic; and a 25th parameter indicating the transmission quality assurance operation; 35. The method (1000) of claim 34, comprising:

36. The transmission quality assurance operation includes: establishing a redundant transmission path; - re-establishing said transmission path; - switching to a backup transmission path; 36. The method (1000) of claim 34 or 35, comprising at least one of:

37. the first request message is an application trigger message; and / or The 25th parameter indicates a trigger for redundant connection setup, connection re-establishment, or connection switching for SEALDD packet transmission; 37. The method (1000) of claim 36.

38. receiving a transmission quality assurance response message from said VAL UE (201), receiving the transmission quality assurance response message, the transmission quality assurance response message including a 26th parameter indicating whether the request was successful or failed; The method (1000) of any one of claims 34 to 37, further comprising:

39. - sending a second request message to the VAL UE (201) to request the use of a single transmission path (S1004); The method (1000) of any one of claims 34 to 38, further comprising:

40. The method (1000) according to any one of claims 34 to 39, wherein the transmission path is formed between a second functional component (121) implementing a VAL client of the UE (201) and a second network function (111) implementing a VAL server via the first functional component (222) implementing the SEALDD client and the first network function (212) implementing the SEALDD server.

41. 1. A method (1100) performed by a Vertical Application Layer (VAL) User Equipment (UE) (201) including a first functional component (222) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) client, comprising: Deciding to perform a transmission quality assurance operation (S1104), In response to receiving (S1102) a first request message for requesting a transmission quality assurance operation from a first network function (222) implementing a SEALDD server; or Based on the data transmission quality measured in the data transmission quality measurement process (S1101) of the transmission path, - deciding to perform a transmission quality assurance operation (S1104); The method (1100) includes:

42. The first request message includes: a 24th parameter indicative of the measured at least one VAL application traffic; and a 25th parameter indicating the transmission quality assurance operation; 42. The method (1100) of claim 41, comprising:

43. The transmission quality assurance operation includes: - establishing redundant transmission paths; - re-establishing said transmission path; - switching to a backup transmission path; 43. The method (1100) of claim 41 or 42, comprising at least one of:

44. performing the transmission quality assurance operation - Establishing additional transmission paths for redundancy; - Establishment of two new transmission paths and freeing up the existing transmission path for redundancy; - Releasing existing transmission paths and establishing new ones; - Switching to a backup transmission path and disabling the existing transmission path; 44. The method (1100) of claim 43, further comprising performing at least one of:

45. the first request message is an application trigger message; and / or The 25th parameter indicates a trigger for redundant connection setup, connection re-establishment, or connection switching for SEALDD packet transmission; 44. The method (1100) of claim 43.

46. sending (S1103) a transmission quality assurance response message to a first network function (212) implementing a SEALDD server, the transmission quality assurance message includes a 26th parameter indicating whether the first request is successful or unsuccessful. Sending a transmission quality assurance response message (S1103); The method (1100) of any one of claims 41 to 45, further comprising:

47. - determining to use a single transmission path (S1105), in response to a second request message from the first network function implementing the SEALDD server to request the use of a single transmission path; or based on the measured data transmission quality of another data transmission quality measurement process of the transmission path; - deciding to use a single transmission path (S1105); The method (1100) of any one of claims 41 to 46, further comprising:

48. - Release at least one transmission path and return to a single SEALDD connection mode.

48. The method (1100) of claim 47, further comprising:

49. The method according to any one of claims 41 to 48, wherein the transmission path is formed between a second functional component (121) implementing a VAL client of the UE (201) and a second network function (111) implementing a VAL server via the first functional component (222) implementing the SEALDD client and the first network function (212) implementing the SEALDD server.

50. a first network function (1200, 212) implementing a Service Realization Architecture Layer (SEAL) Data Delivery (DD) server, at least one processor (1201); a non-transitory computer-readable medium (1202) coupled to the at least one processor (1201), the non-transitory computer-readable medium (1202) comprising instructions executable by the at least one processor (1201), whereby the at least one processor (1201) is configured to perform a method (700, 1000) according to any one of claims 1 to 15 and 34 to 40; a first network function (1200, 212) including:

51. A Vertical Application Layer (VAL) User Equipment (UE) (201), comprising: at least one processor (1301); at least one non-transitory computer-readable medium (1302) coupled to said at least one processor (1301), said non-transitory computer-readable medium (1302) comprising instructions executable by said at least one processor (1301), whereby said at least one processor (1301) is configured to perform a method (800, 900, 1100) according to any one of claims 16 to 31, 32 to 33 and 41 to 49; A Vertical Application Layer (VAL) User Equipment (UE) (201) including:

52. A computer readable medium (1202, 1302, 1402) comprising computer readable code that, when executed on an apparatus (201, 212, 1200, 1400), causes the apparatus (201, 212, 1200, 1400) to perform a method (700, 800, 900, 1000, 1100) according to any one of claims 1 to 49.

53. A computer program product (1404) comprising computer readable code that, when executed on an apparatus (201, 212, 1200, 1400), causes said apparatus (201, 212, 1200, 1400) to perform a method (700, 800, 900, 1000, 1100) according to any one of claims 1 to 49.

Images