Support of data transfer measurement action assurance for data delivery services

Abstract

Methods for SEALDD data transmission measurements and data delivery services are described herein. A SEALDD client may receive a first request for a data delivery service from an application, the first request including information for configuring a data transfer measurement (DTM) or action assurance for the data delivery service. The SEALDD client may send a second request to the SEALDD server, the second request including a configuration for enabling at least one of a data transfer measurement or an action guarantee. The SEALDD client may receive a first response to the second request, the first response including a DTM configuration for configuring the SEALDD client to collect data transfer information, and the SEALDD client may send a second response to the application, the second response including information received in the first response. The SEALDD client may collect data transfer measurements during application of data traffic, may receive a DTM report of the configured measurements, and may send the DTM report of the configured measurements.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 371,270, filed on August 12, 2022, the entire contents of which are incorporated herein by reference. Background Art

[0003] In order for the vertical industry service enabling architecture layer (SEAL) data delivery (SEALDD) layer to provide data delivery services to meet the requirements of vertical applications, both the SEALDD client and the SEALDD server may need to know the performance characteristics of the underlying network. However, existing network performance measurements do not consider the entire path between the SEALDD client and the SEALDD server. In addition, there is no exposure of data transmission measurements from the SEALDD layer to the vertical application layer (VAL) to assist the VAL application in selecting the necessary data delivery services in the network (including the service enabling layer) to ensure the VAL functional objectives. Therefore, an improved SEALDD process is needed. Summary of the invention

[0004] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description in a simplified form. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additionally, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure.

[0005] Methods for SEALDD servers and clients are described herein. The methods described herein may be applied to data transmission measurement and data delivery services. In an exemplary method, a SEALDD client may receive a first request for a data delivery service from an application. The first request may include information for configuring data transmission measurement (DTM) and / or action assurance for the data delivery service. The SEALDD client may send a second request to the SEALDD server. The second request may include a configuration for enabling at least one of data transmission measurement or action assurance. The SEALDD client may receive a first response to the second request. The response may include a DTM configuration for configuring the SEALDD client to collect data transmission information. The SEALDD client may send a second response to the application. The response includes the information received in the first response. The SEALDD client may collect data transmission measurements during application data services. The SEALDD client may receive DTM reports of configured measurements at configured intervals. The SEALDD client may send DTM reports of configured measurements at configured intervals. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In order to promote a more robust understanding of the present application, reference is now made to the drawings, in which like elements are referenced with like reference numerals. These drawings should not be construed as limiting the present application, and are intended to be illustrative only.

[0007] Figure 1 is a system diagram of an exemplary machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system in which one or more disclosed embodiments may be implemented;

[0008] Figure 2 is available in Figure 1 A system diagram of an exemplary architecture used within an M2M / IoT / WoT communication system;

[0009] Figure 3 is available in Figure 1 and 2 A system diagram of an exemplary communication network node (such as an M2M / IoT / WoT device, gateway or server) used within the communication system illustrated in FIG.

[0010] Figure 4 It can be reflected Figure 1 and 2 A block diagram of an exemplary computing system of a node of a communication system of;

[0011] Figure 5 An exemplary SEALDD architecture is shown;

[0012] Figure 6 An exemplary SEALDD application service delivery is shown;

[0013] Figure 7 illustrates an exemplary SEALDD server discovery and selection for data traffic delivery;

[0014] Figure 8 An exemplary non-roaming 5G system architecture is shown;

[0015] Fig. 9 An exemplary data transmission measurement SEALDD server discovery process is shown;

[0016] Fig.10 An exemplary SEALDD data transmission measurement enable is shown;

[0017] Fig.11 An exemplary general SEALDD data transmission measurement process is shown;

[0018] Fig.12 An exemplary SEALDD data transmission measurement exposure is shown;

[0019] Fig.13An exemplary SEALDD action guarantee using user plane modification is shown;

[0020] Fig.14 shows an exemplary SEALDD action guarantee using redundant transmission;

[0021] Fig.15 illustrates an exemplary SEALDD action guarantee using a SEALDD data store or cache;

[0022] Fig.16 shows an exemplary SEALDD action guarantee using a SEALDD forwarding agent;

[0023] Fig.17 illustrates an exemplary autonomous SEALDD action assurance initiated by a SEALDD server; and

[0024] Fig.18 An exemplary GUI is shown. DETAILED DESCRIPTION

[0025] Methods and apparatus for SEALDD server and client communications are described herein. For example, the methods described herein may be applied to data transmission measurement and data delivery services.

[0026] The following definitions and abbreviations are described here:

[0027]

[0028]

[0029] Action Assurance: An action that a SEALDD server performs to ensure that a SEALDD connection is providing a level of data delivery service that meets the QoS requirements of the application traffic.

[0030] Data Transfer Measurements: Data transfer measurements represent end-to-end measurements obtained at the SEALDD layer between a SEALDD client and a SEALDD server.

[0031] Figure 1 is a diagram of an exemplary machine-to-machine (M2M), Internet of Things (IoT), or Web of Things (WoT) communication system 10 in which one or more disclosed embodiments may be implemented. In general, M2M technology provides building blocks for IoT / WoT, and any M2M device, M2M gateway, M2M server, or M2M service platform may be a component or node of IoT / WoT and IoT / WoT service layer, etc. Figure 5-18 Any client, proxy or server device illustrated in any of the figures in the may comprise a node of a communication system such as Figure 5-18 Nodes shown in the figure.

[0032] The service layer can be a functional layer within a network service architecture. The service layer is usually located above the application protocol layer (such as HTTP, CoAP or MQTT) and provides value-added services to client applications. The service layer also provides an interface to the core network at the lower resource layer (such as, for example, the control layer and the transport / access layer). The service layer supports a variety of (service) capabilities or functions, including service definition, service runtime enablement, policy management, access control and service clustering. Recently, several industrial standard bodies (e.g., oneM2M) have been developing the M2M service layer to address the challenges associated with combining M2M-type devices and applications in deployments such as the Internet / Web, cellular, enterprise and home networks. The M2M service layer can provide applications and / or various devices with access to a batch or set of the above-mentioned capabilities or functions supported by the service layer, which can be referred to as CSE or SCL. Some examples include, but are not limited to, security, charging, data management, device management, discovery, provisioning and connectivity management that can be commonly used by various applications. These capabilities or functions can be used for such various applications using the message format, resource structure and resource representation API defined by the M2M service layer. CSE or SCL is a functional entity that can be implemented by hardware and / or software and provides (service) capabilities or functions exposed to various applications and / or devices (i.e., functional interfaces between such functional entities) so that they can use such capabilities or functions.

[0033] like Figure 1 As shown in , the M2M / IoT / WoT communication system 10 includes a communication network 12. The communication network 12 may be a fixed network (e.g., Ethernet, optical fiber, ISDN, PLC, etc.) or a wireless network (e.g., WLAN, cellular network, etc.) or a network of heterogeneous networks. For example, the communication network 12 may include a variety of access networks that provide content (such as voice, data, video, messaging, broadcasting, etc.) to multiple users. For example, the communication network 12 may adopt one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), etc. In addition, the communication network 12 may include other networks, such as, for example, a core network, the Internet, a sensor network, an industrial control network, a personal area network, a fused personal network, a satellite network, a home network, or an enterprise network.

[0034] like Figure 1As shown in , the M2M / IoT / WoT communication system 10 may include an infrastructure domain and a field domain. The infrastructure domain refers to the network side of the end-to-end M2M deployment, and the field domain refers to the regional network usually behind the M2M gateway. Both the field domain and the infrastructure domain may include various different nodes of the network (e.g., servers, gateways, devices, etc.). For example, the field domain may include an M2M gateway 14 and a device 18. It will be understood that any number of M2M gateway devices 14 and M2M devices 18 may be included in the M2M / IoT / WoT communication system 10 as desired. Each of the M2M gateway devices 14 and the M2M devices 18 is configured to send and receive signals via the communication network 12 or a direct radio link using a communication circuit system. The M2M gateway 14 allows wireless M2M devices (e.g., cellular and non-cellular) and fixed network M2M devices (e.g., PLC) to communicate through an operator network (such as, the communication network 12) or a direct radio link. For example, the M2M devices 18 may collect data and send data to the M2M applications 20 or other M2M devices 18 via the communication network 12 or a direct radio link. The M2M devices 18 may also receive data from the M2M applications 20 or the M2M devices 18. In addition, as described below, data and signals may be sent to and received from the M2M applications 20 via the M2M service layer 22. The M2M devices 18 and the gateway 14 may communicate via various networks including, for example, cellular, WLAN, WPAN (e.g., Zigbee, 6LoWPAN, Bluetooth), direct radio links, and wired. Exemplary M2M devices include, but are not limited to, tablet computers, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart sockets.

[0035] Reference Figure 2 , the M2M service layer 22 in the illustrated field provides services for the M2M application 20, the M2M gateway 14 and the M2M device 18, and the communication network 12. It will be understood that the M2M service layer 22 can communicate with any number of M2M applications, M2M gateways 14, M2M devices 18, and communication networks 12 as needed. The M2M service layer 22 can be implemented by one or more nodes of the network, which may include servers, computers, devices, etc. The M2M service layer 22 provides service capabilities applied to the M2M devices 18, the M2M gateway 14, and the M2M application 20. The functions of the M2M service layer 22 can be implemented in various ways, such as being implemented as a web server, implemented in a cellular core network, implemented in the cloud, etc.

[0036] Similar to the illustrated M2M service layer 22, there is an M2M service layer 22' in the infrastructure domain. The M2M service layer 22' provides services for the M2M applications 20' and the underlying communication network 12 in the infrastructure domain. The M2M service layer 22' also provides services for the M2M gateways 14 and the M2M devices 18 in the field domain. It will be understood that the M2M service layer 22' can communicate with any number of M2M applications, M2M gateways, and M2M devices. The M2M service layer 22' can interact with service layers of different service providers. The M2M service layer 22' can be implemented by one or more nodes of the network, which may include servers, computers, devices, virtual machines (e.g., cloud computing / storage farms, etc.), etc.

[0037] Also refer to Figure 2 , the M2M service layers 22 and 22' provide a set of core service delivery capabilities that can be utilized by different applications and vertical industries. These service capabilities enable M2M applications 20 and 20' to interact with devices and perform functions such as data collection, data analysis, device management, security, billing, service / device discovery, etc. Basically, these service capabilities free applications from the burden of implementing these functions, thereby simplifying application development and reducing the cost and time to market. The service layers 22 and 22' also enable M2M applications 20 and 20' to communicate over various networks (such as, network 12) in conjunction with the services provided by the service layers 22 and 22'.

[0038] The M2M applications 20 and 20' may include applications in various industries, such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and monitoring. As described above, the M2M service layer running across devices, gateways, servers, and other nodes of the system supports various functions, such as, for example, data collection, device management, security, billing, location tracking / geofencing, device / service discovery, and legacy system integration, and provides these functions as services to the M2M applications 20 and 20'.

[0039] Typically, a service layer (such as Figure 2The service layer 22 and 22' illustrated in the figure defines a software middleware layer that supports value-added service capabilities through a set of application programming interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. The service layer of ETSI M2M is called the service capability layer (SCL). The SCL can be implemented in various different nodes of the ETSI M2M architecture. For example, an instance of the service layer can be implemented in an M2M device (where it is called a device SCL (DSCL)), a gateway (where it is called a gateway SCL (GSCL)) and / or a network node (where it is called a network SCL (NSCL)). The oneM2M service layer supports a set of public service functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more specific types of CSFs is called a public service entity (CSE), which can be hosted on different types of network nodes (e.g., infrastructure nodes, intermediate nodes, application-specific nodes). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine type communication (MTC). In this architecture, the service layer and the service capabilities it provides are implemented as part of a service capability server (SCS). Whether embodied in the DSCL, GSCL or NSCL of the ETSI M2M architecture, in the service capability server (SCS) of the 3GPP MTC architecture, in the CSF or CSE of the oneM2M architecture, or in some other node of the network, an instance of the service layer can be implemented as a logical entity (e.g., software, computer executable instructions, etc.) executed on one or more independent nodes (including servers, computers and other computing devices or nodes) in the network, or as part of one or more existing nodes. As an example, an instance of the service layer or its components can be implemented as a component of a network having the following description: Figure 3 or Figure 4 The form of software running on a network node (e.g., server, computer, gateway, device, etc.) of the general architecture illustrated in FIG.

[0040] Additionally, the methods and functions described herein may be implemented as part of an M2M network that uses a service-oriented architecture (SOA) and / or a resource-oriented architecture (ROA) to access services.

[0041] Figure 3 are nodes of the network (such as Figure 5-18 , a block diagram of an exemplary hardware / software architecture of a node (one of the clients, servers or agents illustrated in FIG. 1 ), which node may be used as an M2M server, gateway, device or other node in an M2M network, such as Figure 5-18 The nodes shown in the figure. Figure 3As shown in FIG. 1 , node 30 may include a processor 32, non-removable memory 44, removable memory 46, speaker / microphone 38, keypad 40, display, touch pad and / or indicator 42, power supply 48, global positioning system (GPS) chipset 50, and other peripherals 52. Node 30 may also include communication circuitry such as transceiver 34 and transmit / receive element 36. It will be understood that node 30 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. This node may be a node that implements the methods described herein, for example, the methods described with reference to Figure 5-18 or Figure 5-18 The data structure, the method described in Tables 1-9, or the method in the claims are related.

[0042] The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. In general, the processor 32 may execute computer executable instructions stored in the node's memory (e.g., memory 44 and / or memory 46) to perform various required node functions. For example, the processor 32 may perform signal decoding, data processing, power control, input / output processing, and / or any other function that enables the node 30 to operate in a wireless or wired environment. The processor 32 may run application layer programs (e.g., browsers) and / or radio access layer (RAN) programs and / or other communication programs. The processor 32 may also perform security operations such as, for example, authentication, security key negotiation, and / or cryptographic operations at the access layer and / or application layer.

[0043] like Figure 3 As shown in FIG. 1 , processor 32 is coupled to its communication circuitry (e.g., transceiver 34 and transmit / receive element 36). Through the execution of computer-executable instructions, processor 32 may control the communication circuitry so that node 30 communicates with other nodes via the network to which it is connected. In particular, processor 32 may control the communication circuitry so as to perform the methods described herein, for example, with Figure 5-18 The method or method in the claims. Figure 3 The processor 32 and the transceiver 34 are depicted as separate components, but it will be appreciated that the processor 32 and the transceiver 34 may be integrated together in an electronic package or chip.

[0044] The send / receive element 36 may be configured to send signals to other nodes, or receive signals from other nodes, including M2M servers, gateways, devices, etc. For example, in an embodiment, the send / receive element 36 may be an antenna configured to send and / or receive RF signals. The send / receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, etc. In an embodiment, for example, the send / receive element 36 may be a transmitter / detector configured to send and / or receive IR, UV or visible light signals. In another embodiment, the send / receive element 36 may be configured to send and receive both RF and optical signals. It will be appreciated that the send / receive element 36 may be configured to send and / or receive any combination of wireless or wired signals.

[0045] In addition, although the transmission / reception element 36 is Figure 3 Although described as a single element in FIG. 3 , the node 30 may include any number of transmit / receive elements 36. More specifically, the node 30 may employ MIMO technology. Therefore, in an embodiment, the node 30 may include two or more transmit / receive elements 36 (e.g., multiple antennas) for transmitting and receiving wireless signals.

[0046] The transceiver 34 may be configured to modulate signals to be transmitted by the transmit / receive element 36 and to demodulate signals received by the transmit / receive element 36. As described above, the node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the node 30 to communicate via multiple RATs, such as, for example, UTRA and IEEE 802.11.

[0047] The processor 32 can access information from any type of suitable memory (such as, non-removable memory 44 and / or removable memory 46), and store data in any type of suitable memory. For example, the processor 32 can store the session context in its memory, as described above. The non-removable memory 44 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a user identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 32 can access information from a memory that is not physically located on the node 30 (such as, located on a server or a home computer), and store data in the memory. The processor 32 can be configured to control the lighting pattern, image, or color on the display or indicator 42.

[0048] Processor 32 may receive power from power source 48 and may be configured to distribute and / or control power to other components in node 30. Power source 48 may be any suitable device for powering node 30. For example, power source 48 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0049] Processor 32 may also be coupled to a GPS chipset 50 that is configured to provide location information (eg, longitude and latitude) regarding the current location of node 30. It will be appreciated that node 30 may acquire location information by any suitable location determination method while remaining consistent with an embodiment.

[0050] The processor 32 may further be coupled to other peripherals 52, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass (e-compass), a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnect interface, a vibration device, a television transceiver, a hands-free headset, modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0051] Node 30 may be embodied in other devices or apparatuses, such as sensors, consumer electronic devices, wearable devices (such as smart watches or smart clothing), medical or electronic health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes). Node 30 may be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces (such as, for example, an interconnect interface that may include one of peripheral devices 52).

[0052] Figure 4 is a block diagram of an exemplary computing system 90, which may also be used to implement one or more nodes of a network, such as Figure 5-18 The client, server or agent shown in FIG. 1 may be used as an M2M server, gateway, device or other node in an M2M network, such as Figure 5-18 Nodes shown in the figure.

[0053] The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions that may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor, such as a central processing unit (CPU) 91, to cause the computing system 90 to operate. In many known workstations, servers, and personal computers, the central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may include multiple processors. The coprocessor 81 is an optional processor that is different from the main CPU 91 and performs additional functions or assists the CPU 91. The CPU 91 and / or the coprocessor 81 may receive, generate, and process data related to the disclosed system and method for E2E M2M service layer sessions, such as receiving session credentials or authenticating based on session credentials.

[0054] In operation, the CPU 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computer's primary data transfer path, the system bus 80. Such a system bus connects components in the computing system 90 and defines the medium for data exchange. The system bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0055] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function when executing instructions, which converts a virtual address into a physical address. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; it cannot access memory within the virtual address space of another process unless memory sharing between processes has been set.

[0056] Additionally, computing system 90 may include a peripheral device controller 83 responsible for transmitting instructions from CPU 91 to peripheral devices such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0057] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0058] Additionally, computing system 90 may include communications circuitry (such as, for example, network adapter 97) that may be used to connect computing system 90 to an external communications network (such as, for example, a network adapter 97). Figure 1-4 network 12) to enable computing system 90 to communicate with other nodes of the network.

[0059] The SEAL Data Delivery (SEALDD) architecture is described here. 3GPP has defined a vertical industry service enabling architecture layer (SEAL) to provide a horizontal layer in which public services are made available to the vertical application layer. The public services provided by SEAL include, but are not limited to, location management, group management, configuration management, identity management, key management, and network resource management. Vertical application layer (VAL) clients can access SEAL services, which can transmit application services to VAL servers via the SEAL layer. In Release 18, 3GPP has decided to enhance the SEAL layer to support efficient data distribution, delivery, and caching toward the application layer. 3GPP TR 23.700-34 captures the work done in the SEALDD study to enhance the SEAL layer with data delivery services.

[0060] Figure 5 A proposed SEALDD architecture 500 is shown. Such an architecture 500 may be found in 3GPP TR 23.700-34. In the architecture 500, at the SEAL layer 501, a SEALDD client 510 and a SEALDD server 512 may provide data delivery services for application traffic delivery from a VAL layer 502 via a SEALDD-UU interface 513. In addition, the SEALDD server 512 may have access to exposure information available from the 3GPP network via the N33 / N5 514 and N6 515 interfaces, and may have the ability to communicate with other SEALDD servers via a SEALDD-E interface 516. The SEALDD server 512 may access performance statistics from a network data analysis function (NWDAF) via a network exposure function (NEF) via an N33 interface 514, may configure network parameters to a policy control function (PCF) via an N5 interface 514, and may obtain data traffic measurements from a user plane function (UPF) via an N6 interface 516.

[0061] Figure 6 An example of a SEALDD architecture is shown that provides a vertical application end-to-end data delivery service 600. It can be found in 3GPP TR 23.700-34 Figure 6 . VAL client 610 on user equipment (UE) 601 may request SEALDD service from SEALDD client 611 via SEALDD-C interface 620. SEALDD client 611 may route application traffic to SEALDD server 612 via SEALDD-UU interface 621, which may span multiple network nodes. Upon receiving SEALDD data traffic 630, SEALDD server 612 may forward application data traffic 631 to corresponding VAL server 613.

[0062] Figure 7 The proposed solution for SEALDD server discovery and selection for data service delivery 700 is shown. This example is from 3GPP TR 23.700-34. By sending a SEALDD service subscription request 710 and receiving a SEALDD service subscription response 711, a VAL server 704 can subscribe to a SEALDD service from a SEALDD server 703. Through application layer signaling, SEALDD server information 712 can be provided to a VAL client 701. When requesting a SEALDD service 713, the VAL client 701 can provide the SEALDD server information to the SEALDD client 702, and the SEALDD client 701 can use the information to establish a SEALDD connection 714 with the SEALDD server 703. The SEAL client 701 can send a SEALDD service consumption response to the VAL client 701.

[0063] Figure 8 The 3GPP 5G non-roaming system architecture is shown in accordance with reference point representation 800. This example is from 3GPP TR23.501. The UE can communicate with the 5G network to establish control plane signaling and enable the UE to use services from the 5G network. In addition, the UE can also establish a user plane session to communicate with other UEs or application servers in the data network (DN). The user plane includes a path from the UE to the radio access network (RAN) node, through the user plane function (UPF) and to the DN, where application servers and other UEs can be reached. For the path between the UE and the RAN node and for the path between the UE and the UPF, network performance measurements can be obtained.

[0064] Traditionally, network performance is measured between two endpoints, and it can be used to specify the quality of service of the network between the endpoints. The main aspects of network performance measurement may include, but are not limited to, data rate, delay, and data loss. The data rate can be measured as network throughput, which represents the actual data rate that can be delivered by the network between the two endpoints over a specific time period. Delay can be expressed as the round-trip time of a data packet, and can also be expressed as the jitter experienced by the receiver, which has the form of the variance of the packet delay between different packets. Data loss can also be referred to as network error, which can be characterized by the packet loss rate measured by the receiver, and can be characterized by the retransmission rate measured by the sender. The aforementioned measurement can rely on the network connection between the two endpoints. Therefore, connection availability can also be regarded as a measurement related to network performance measurement. Finally, the performance measurement can then be used as an input for the calculation of the quality of service (QoS) provided by the network or the quality of experience (QoE) of the user's experience.

[0065] In order for the SEALDD layer to provide data delivery services to meet the requirements of vertical applications, both the SEALDD client and the SEALDD server may need to know the performance characteristics of the underlying network. 3GPP TR 23.700-34 has identified key issues to add support for data transmission quality measurement and assurance to the SEALDD layer. Currently, the SEALDD server may already have access to performance measurements from the 5G network, but the measurement only indicates the performance within the 5G network (e.g., the business between the UE and the UPF) and does not extend to the end-to-end performance between the SEALDD client and the SEALDD server. Therefore, the network performance measurement does not take into account the entire path between the SEALDD client and the SEALDD server.

[0066] The overall end-to-end data delivery path between the VAL client and the VAL server is shown in Figure 6 As described above. When data originates from a VAL client and terminates at a VAL server (or vice versa), the true quality of the data delivery service for the application business can be measured in an end-to-end manner. Therefore, data transmission measurements obtained for an end-to-end path can be reflected in the user experience. In this scenario, the SEALDD server can be co-located with the VAL server or deployed close enough to the VAL server to minimize network latency.

[0067] Currently, there may not be exposure of data transmission measurements from the SEALDD layer to the VAL layer to assist the VAL application in selecting the necessary data delivery services in the network (including the service enabling layer) to ensure the VAL functional objectives. If more than one SEALDD server is available, the VAL application may not be able to determine whether the SEALDD server can provide the expected service or service level required by the VAL application. This may cause unexpected interruptions to the application business and reduce the user's quality of experience.

[0068] Finally, the SEALDD layer may be able to address network congestion issues by performing actions to ensure that the SEALDD connection is providing a level of data delivery service that meets the QoS requirements of the application traffic. Data transmission measurements may be used by the SEALDD client and SEALDD server to monitor the quality of the SEALDD connection, and if the measurements indicate a possible network congestion issue, the SEALDD client and / or server may perform actions to modify user plane resources in the 5G network or use redundant transport or other SEALDD capabilities to attempt to improve the quality of the SEALDD connection.

[0069] The SEALDD layer can provide data delivery services to vertical applications, which can directly affect the user experience. Therefore, the ability to obtain end-to-end data transmission measurements at the SEALDD layer can assist SEALDD clients and servers in better providing data delivery services. Data transmission measurements can provide insight into network congestion and allow SEALDD servers to perform actions to ensure that the QoS requirements of the data delivery service are maintained. The SEALDD layer can also expose data transmission measurements to vertical applications to enhance the overall SEALDD data delivery service.

[0070] Embodiments related to the following aspects are described here:

[0071] A method for causing a SEALDD client to:

[0072] receiving a first request for a data delivery service from an application, the first request may include information for configuring a data transfer measurement (DTM) and / or an action guarantee for the data delivery service;

[0073] sending a second request to the SEALDD server, the second request comprising a configuration for enabling at least one of data transmission measurement or action assurance;

[0074] receiving a first response to the second request, the response including a DTM configuration for configuring the SEALDD client to collect data transmission information;

[0075] sending a second response to the application, the response including the information received in the first response;

[0076] collecting data transmission measurements during application data services;

[0077] Receive DTM reports of configured measurements at periodic intervals; and

[0078] Sends DTM reports of configured measurements at periodic intervals.

[0079] A method for causing a SEALDD server to:

[0080] Receive configuration of Data Transfer Measurement (DTM) and Action Assurance;

[0081] Send DTM reports and include configured data transmission measurements;

[0082] receiving a request to perform an action guarantee; and

[0083] The requested action is performed, the action ensuring including one or more of modifying a user plane, establishing redundant transport, using a data store, a data cache, or a forwarding proxy capability.

[0084] A method for causing a SEALDD client to:

[0085] sending a request to the edge-enabled client with a list of data transfer measurements supported by the SEALDD client; and

[0086] A response is received from the edge-enabled client, the response having a list of SEALDD servers including a list of data transfer measurements supported by each SEALDD server using the DTM configuration and a list of action guarantees that can be performed by each SEALDD server.

[0087] A process that can realize data transmission measurement in SEALDD layer to enhance and optimize data delivery service is described here. SEALDD server discovery process can be enhanced to enable SEALDD client to discover SEALDD server that supports data transmission measurement. Alternatively, SEALDD client can be supplied with information about SEALDD server. Various data transmission measurements that are applicable to SEALDD layer can be described to show end-to-end interaction. Data transmission measurement can be combined with action guarantee performed in SEALDD layer in response to network congestion, and can realize the optimization of application business transmission. Action guarantee can use other SEALDD services that may be available, such as using redundant transmission, SEALDD data storage or cache and SEALDD server forwarding agent.

[0088] The SEALDD server discovery enhancement for data transmission measurement is described here. Obtaining data transmission measurement requires support from both the SEALDD client and the SEALDD server. Before enabling such measurement, the SEALDD client may first discover a SEALDD server that supports data transmission measurement. There are various ways for the SEALDD client to discover the SEALDD server, and each way is described below. It should be noted that the VAL server or another SEALDD server may also discover the data transmission measurement capability of the SEALDD server.

[0089] 3GPP TR 23.700-34 describes a SEALDD server discovery and selection process, such as Figure 7 As shown in Figure 7 In the embodiment of the present invention, the VAL server subscribes to the SEALDD server and provides the SEALDD server information to the SEALDD client via application layer signaling. During this process, the VAL server may have obtained the capabilities of the SEALDD server. One such capability may be the support of the SEALDD server for data transmission measurement and action guarantee, as further outlined in the present disclosure. The VAL server may forward the support of the SEALDD server for data transmission measurement and action guarantee to the SEALDD client, and the SEALDD client may use this information to enable the collection of the expected data transmission measurement and request action guarantee as needed.

[0090] In another embodiment, in the edge data network, the SEALDD server can be discovered by the SEALDD client as part of the edge application server (EAS) discovery process. The EAS discovery process is described in 3GPP TS23.558. The SEALDD server used as EAS first registers with the edge enabling server (EES), indicating support for data transmission measurement and action assurance. Then, the edge enabling client (EEC) on the UE can use the EAS discovery process to discover the SEALDD server, and the capabilities of the SEALDD server can be obtained, at which time the information can be made available to the SEALDD client.

[0091] Fig. 9 An example of an enhancement of the SEALDD server discovery process 900 is shown, in which a SEALDD client can discover a SEALDD server that supports data transfer measurement and action assurance.

[0092] In step 911, the SEALDD server 901 may function as an EAS and may provide an EAS profile with a data transmission measurement identifier in an EAS registration request. The EAS profile may also include a list of data transmission measurements supported by the SEALDD server 901 and possible configurations of the data transmission measurements. In addition, the SEALDD server 901 may also include the action guarantees it supports.

[0093] At step 912, the edge enabling server (EES) 902 may perform an authorization check to verify whether the EAS is authorized to register with the EES. If the EAS is authorized, the EES 902 may store the EAS profile and return a response to the SEALDD server 901. The response may include the status of the request and the expiration time of the registration. It should be noted that the EES 902 may receive registration requests with its EAS profile from multiple EASs (e.g., SEALDD servers).

[0094] At step 913, SEALDD client 904 may send a discovery request to edge enabling client (EEC) 903. The request may include a list of data transmission measurements supported by the SEALDD client to enable EEC 903 to discover SEALDD servers matching the provided data transmission measurements.

[0095] At step 914 , EEC 903 may send an EAS discovery request to EES 902 , which may include a discovery filter that may include data transmission measurements provided by SEALDD client 904 .

[0096] In step 915, EES 902 may check whether EEC 903 is authorized to discover EAS. If authorized, EES 902 may search for EAS that support the data transmission measurement provided in the discovery filter. EES 902 may return a list of EAS that support the requested data transmission measurement and information from the corresponding EAS profile. For each EAS, EES 902 may include a list of DTM identifiers, data transmission measurements and applicable configurations (if it is available), and a list of action guarantees.

[0097] In step 916 , the EEC 903 may return the list of EASs and related information received from the EES 902 to the SEALDD client 904 .

[0098] In this example, the discovery of a SEALDD server that supports data transfer measurements by a SEALDD client depends on information about the capabilities of the SEALDD server. This information may include various information describing what types of performance measurements are supported and a list of available measurement configurations and action guarantees.

[0099] Here, SEALDD end-to-end data transmission measurement is described. After the discovery of the DTM support of the SEALDD server, the SEALDD client can request to enable data transmission measurement during the establishment or update of the SEALDD connection with the SEALDD server. This can be referred to as SEALDD DTM enabling here. The SEALDD client can also include a list of data transmission measurements that it supports in the request so that the SEALDD server can configure the DTM measurement collection and report from the SEALDD client in the connection response. DTM collection can be integrated with application data transmission to provide the responsiveness measurement provided by the SEALDD connection. The responsiveness measurement can indicate the quality of the underlying network between the SEALDD client and the SEALDD server. It should be noted that SEALDD DTM enabling can also occur between two SEALDD servers to exchange DTM capabilities. In this scenario, DTM enabling can be integrated as a part of SEALDD server discovery, or configured by operator strategy, server administrator or OAM management node.

[0100] Fig.10 An exemplary process 1000 for SEALDD data transmission measurement (DTM) enabling is shown. In step 1021, the SEALDD client 1011 of UE 1001 may be configured with SEALDD server contact information and associated SEALDD capabilities, including whether the SEALDD server supports data transmission measurement. This configuration may be provided as part of SEALDD server discovery, user or service provider configuration through application layer services, etc. For SEALDD services that may require authorization, such as the use of redundant transmission services, the SEALDD client 1011 may be notified that it is authorized to use such services. The SEALDD client 1011 may be configured with information indicating one or more SEALDD servers.

[0101] In step 1022, the VAL client 1010 of the UE 1001 may request the SEALDD data delivery service and may provide information about applications with expected QoS requirements. The request may include an application identifier, expected QoS, whether data transmission measurement is enabled and what data transmission measurement is enabled, data transmission measurement configuration information, and a list of one or more action guarantees with corresponding triggering events. Action guarantees are described in more detail in the action guarantee process. The data delivery service request may include the use of other SEALDD services, such as redundant transmission, SEALDD data storage or caching, and the use of a SEALDD server forwarding agent.

[0102] At step 1023, SEALDD client 1011 may determine which SEALDD server best provides SEALDD data delivery services based on information provided by VAL client 1010. SEALDD client 1011 may also select a SEALDD server that supports data transfer measurement to monitor and manage SEALDD connections to provide the desired services to the VAL client.

[0103] In step 1024, the SEALDD client 1011 can establish a SEALDD connection with the selected SEALDD server 1003, and can provide information to configure and enable data transmission measurement of the SEALDD connection. Examples of information that can be provided for data transmission measurement are listed in Table 1. The SEALDD client 1011 can specify the data transmission measurement it supports, and configure one or more measurements to be reported by the SEALDD server 1003. The SEALDD client 1011 can also specify whether to enable the measurement schedule of the SEALDD connection, in which the SEALDD server 1003 autonomously measures and provides the DTM report to the SEALDD client 1011. For each measurement, the SEALDD client 1011 can specify the identifier of the measurement, the type of measurement to be reported, the measurement and reporting time period schedule, and the expiration time of the measurement. Alternatively, the SEALDD client 1011 can also use the explicit mode to explicitly initiate a measurement request, and initiate the payload size of the measurement request as required. Some measurements may need to send multiple requests and / or the total number of requests to obtain more meaningful measurements. For these measurements, burst size and total packet information element can be configured. In addition, various identifiers can be kept so that context is provided for measurement configuration. The example of this identifier can be the identifier of DTM configuration identifier, SEALDD connection identifier, application identifier and application type. SEALDD client 1011 also can request the use of other SEALDD services, such as redundant transmission, SEALDD data storage or high-speed cache and SEALDD server 1003 forwarding agents. The configuration of SEALDD service is shown in Table 9, and will be described in more detail in the action guarantee process.

[0104] Table 1 - Data transmission measurement configuration information

[0105]

[0106] The configuration information shown in Table 1 can be exposed to VAL applications, SEALDD clients and servers, and other network nodes (such as, analysis clients and servers) to provide access and configuration to supported data transmission measurements. The data transmission measurements can then provide information about the quality or responsiveness of the SEALDD connection. The VAL application can use the measurements to determine the appropriate SEALDD service for a particular application, and the analysis server can use the measurements to generate statistics and predictions of SEALDD communications in a particular area and / or during a particular time period.

[0107] In step 1025, SEALDD server 1003 can return the situation of setting up request for SEALDD connection, and can include DTM configuration information of SEALDD client 1011.DTM configuration can configure SEALDD client 1011 to collect data transmission information, and also includes the update of DTM configuration of SEALDD server 1003.If any identifier in the identifier listed in Table 1 does not exist in step 1024, then SEALDD server 1003 can also return the identifier.Separated DTM identifier can be provided-an identifier for SEALDD server configuration and another identifier for SEALDD client configuration.The DTM configuration of SEALDD server can determine what measurement the SEALDD server can collect and can report, and the DTM configuration of SEALDD client can determine what measurement the SEALDD client can collect and can report.If SEALDD client has requested to use other SEALDD services, then SEALDD server can also return the action guarantee configuration information as shown in Table 9 in response message. For example, if SEALDD data storage or caching capabilities are configured, the SEALDD server may return a storage URI, a maximum storage size, and an expiration time after which the stored data will be removed.

[0108] In step 1026, the SEALDD client 1011 may return a response to the VAL client 1010 and include data transmission measurement exposure information that the VAL client 1010 can use to monitor the SEALDD connection. The data transmission measurement exposure information may include the measurement configuration shown in Table 1. The VAL client 1010 may use the exposure information to subscribe to receive data transmission measurements from the SEALDD layer.

[0109] In step 1027, the SEALDD server 1003 may subscribe to receive notifications from the 5G network or OAM management node 1002 to obtain network measurements and / or analysis. For example, the SEALDD server 1003 may subscribe to obtain user plane measurements from a session management function (SMF) or from a user plane function (UPF). The SEALDD server 1003 may also subscribe to obtain analysis statistics or predictions from a network data analysis function (NWDAF) or other network functions in the 5G system. If authorized and appropriate, the SEALDD server 1003 may also subscribe to obtain RAN level measurements and performance measurements from the OAM management node. These measurements can be used by the SEALDD server 1003 to assist in determining where network congestion may be when the SEALDD data delivery service does not provide appropriate QoS.

[0110] At step 1028, application data traffic may be sent over the SEALDD data delivery connection, and if configured, the SEALDD client 1011 and SEALDD server 1003 may collect and process the data to report data transfer measurements.

[0111] In step 1029, according to the configured measurement report interval, the SEALDD client 1011 and the SEALDD server 1003 may submit a DTM report containing enabled data transmission measurements and other information, as shown in Table 2. For each configured measurement, the DTM report may contain a measurement identifier, a source of measurement, a measurement time period, and one or more types of requested measurements. The DTM report may also contain a report identifier, a SEALDD connection identifier, an application identifier, a timestamp of the report, and a connection quality metric for the SEALDD connection. Connection quality metrics may be generated from various sources that may have been obtained by the SEALDD server 1003 and / or the client (including information obtained from an analysis function, from a 5G network, or from an OAM management node 1002).

[0112] To provide additional benefit to other network nodes, a subscription / notification mechanism may be used for DTM reports.An analysis server or other SEALDD server may subscribe to receive notifications of DTM reports containing certain measurement identifiers and measurement types.

[0113] Table 2 - Data transmission measurement report information

[0114]

[0115] Fig.11 An exemplary SEALDD data transfer measurement process 1100 is shown. After the DTM enablement process is completed, a SEALDD client 1101 or a SEALDD server 1102 may initiate data transfer measurement collection. Fig.111 shows a general process in which a SEALDD client may initiate a data transmission measurement with a SEALDD server 1102. The measurement request may include data transmission measurement configuration information as shown in Table 1 to identify which measurements are requested and the configuration used to obtain the measurements. Fig.11 It is shown that the SEALDD client 1101 initiates the measurement request, but the SEALDD server may also initiate the same request to the SEALDD client.

[0116] At step 1110, whenever data transmission measurements are needed, SEALDD client 1101 may send a request to SEALDD server 1102 to trigger the initiation of DTM collection. The request may include measurement configuration information as shown in Table 1 to identify which measurements are being requested.

[0117] At step 1111, the request from step 1110 may trigger the initiation of a measurement timer for time-based measurements such as round-trip time and packet loss rate. After sending the request at step 1110, a timer may be started in SEALDD client 1101 (step 1111a), and upon receiving the request from step 1110, a timer may be started in SEALDD server 1102 (step 1111b). Data collection of the requested measurements may be initiated.

[0118] In step 1112, the SEALDD server 1102 may return a measurement response to the SEALDD client 1101 to confirm the initiation of the collection of the requested measurement. The response may include any updates to the measurement configuration provided by step 1110 that the SEALDD server 1102 has modified. If the measurement is for connection availability, the response may indicate that the SEALDD connection is valid, and available data transfer measurements may be provided to indicate the quality of the SEALDD connection. For measurements that can be obtained using a single request / response message pair (such as round-trip time), the SEALDD server 1102 may provide the measurement in the response.

[0119] In step 1113-1115, step 1110-1112 can be repeated. In one embodiment, step 1113-1115 can represent the end of the measurement time period, and SEALDD server 1102 can return DTM report to SEALDD client 1101 in step 1115. The example of DTM report is shown in Table 2. If the measurement collection is to be continued, the measurement request in step 1113 can trigger the stop and restart of the measurement timer in steps 1114a and 1114b. In another embodiment, step 1113-1115 can represent the end of the measurement collection, and the measurement timer is stopped in steps 1114a and 1114b. In two embodiments, SEALDD server 1102 can return DTM report to SEALDD client 1101 in step 1115. When autonomous data transmission measurement is configured, the SEALDD client 1101 and the SEALDD server 1102 may automatically stop and restart the measurement timer in steps 1114a and 1115b, respectively, based on the schedule information element shown in Table 1. As a result, it may not be necessary for the SEALDD client 1101 to send a request in step 1113. Then, the SEALDD server 1102 may send a DTM report to the SEALDD client 1101 at each configured reporting interval until the DTM collection expires.

[0120] At step 1116, for certain measurements (such as throughput and jitter), the SEALDD client 1101 may send a burst of measurement requests to the SEALDD server 1102. The measurement requests may include a certain size payload to enable the SEALDD server 1102 to collect and determine the appropriate measurements. Typically, the payload is zero-filled for the specified size; however, if the measurement request is integrated with the application data transfer, the payload may be actual application data. For jitter measurements, an identifier may be included to identify the requests belonging to the burst to enable the SEALDD server 1102 to measure the jitter associated with the requests in the burst.

[0121] At steps 1117a and 1117b, for each configured measurement, SEALDD client 1101 and SEALDD server 1102 may start one or more measurement timers (similar to steps 1111a and 1111b). One timer may be associated with each request in a burst.

[0122] In step 1118, the SEALDD server 1102 may return a response for each request received in step 1116 (similar to step 1112, but applied to a burst of responses).

[0123] In steps 1119-1121, the timer associated with each burst request for each configured measurement may be stopped and restarted (similar to steps 1113-1115, but applied to each request in the burst, steps 1116-1118 may be repeated as steps 1119-1121). Autonomous DTM collection may be configured in which timers are automatically stopped and restarted and periodic DTM reports are sent to the SEALDD client.

[0124] Fig.11 The measurement request / response is shown as explicit signaling between SEALDD client 1101 and SEALDD server 1102, which uses the established SEALDD connection, the transport protocol, and the PDU session of the application service between the VAL client and the VAL server. In order to improve efficiency, the measurement request / response can be integrated with the application service between the SEALDD client 1101 and the SEALDD server 1102. It should be noted that this is possible due to the measurement of the SEALDD layer from which the application data is available. For other network performance measurements, since the application data may not be available, explicit measurement request / response may be required.

[0125] Fig.11 Also shown are two methods for requesting measurements: individual requests and burst requests. For some measurements, such as connection availability and RTT, individual requests may be sufficient to obtain necessary measurements. However, for other measurements, such as throughput and jitter, burst requests may be required to obtain more meaningful measurements. In addition, in an autonomous manner, measurement requests may be scheduled, and in an autonomous manner, measurement time periods, reporting time periods, and measurement expiration times may be configured. For measurement scheduling, the SEALDD client 1101 or server 1102 manages the start, stop, and restart of internal timers during the associated measurement time periods.

[0126] In the following measurement descriptions, for each measurement, an exemplary configuration is provided. This configuration can be exposed to the VAL application so that the VAL application accesses and requests data transmission measurements from the SEALDD layer. The VAL application can query the SEALDD client or server for available data transmission measurements and associated configurations. The VAL application can then explicitly request the expected measurement configuration, or the VAL application can simply request to enable the measurement and let the SEALDD layer manage the measurement configuration.

[0127] Fig.12 An exemplary process 1200 is shown in which a VAL client / server 1201 may query a SEALDD client / server 1202 , respectively, for data transfer measurements available to a VAL application.

[0128] At step 1210 , the VAL client / server 1201 may send a request to the SEALDD client / server 1202 for available data transfer measurements and associated configurations.

[0129] At step 1211, the SEALDD client / server 1202 processes the query request. The SEALDD client may search within the internally stored EAS profiles to locate an EAS (e.g., SEALDD server) that supports data transmission measurements and their associated configurations. The SEALDD server may compile all supported data transmission measurements and associated configurations.

[0130] In step 1212, the SEALDD client / server 1202 may return a response having a list of data transmission measurements and associated configurations. The configuration may include a range for configuring each measurement parameter. The response from the SEALDD client may include available measurements and associated configurations for one or more SEALDD servers, which may indicate that the available measurements are supported by both the SEALDD client and the SEALDD server.

[0131] After the VAL client / server 1201 has discovered available data transmission measurements at the SEALDD layer, the VAL client / server 1201 may subscribe to receive notifications of measurements of the SEALDD connection. The subscription request may include a VAL client / server 1201 identifier, a SEALDD connection identifier, one or more data transmission measurement identifiers, and conditions for receiving notifications. The conditions may be based on a periodic timer or a measurement threshold, where a notification is sent if the measurement exceeds a threshold or drops below a threshold. The VAL client / server 1201 may also specify an expiration time for receiving notifications.

[0132] The connection availability measurement can be simply a request / response mechanism between the SEALDD client and the SEALDD server, and vice versa. The measurement can be implemented as a periodic heartbeat or echo request to ensure that the SEALDD connection is still valid. Table 3 shows an example of a configuration of a connection availability measurement with an associated measurement identifier. If the measurement request contains a request measurement information element, the receiver is expected to return any available data transmission measurement. If no measurement is available, the response can indicate nothing or zero. Connection availability can also be scheduled using periodic measurement time periods and expiration times. When scheduled, it can be represented as a heartbeat notification sent from the receiver to the requester to indicate that the connection is valid.

[0133] Table 3 - Connection availability configuration

[0134] Information Elements Parameter Description Measurement ID Connection availability Schedule Configure a schedule for reporting the availability of connections Expiration time Configuration of data transmission measurement expiration Request measurement Specifies the list of current measurements to provide in the response

[0135] Throughput measurement enables a SEALDD client or SEALDD server to determine the data rate of a SEALDD connection during a period of time. Throughput measurement can be used to evaluate the bandwidth usage of a SEALDD connection and can help assist in analyzing and / or predicting potential network congestion. Throughput measurement can be configured with a throughput measurement identifier as shown in Table 4. The requester can indicate the type of measurement value included in the DTM report and the direction of the measurement. Throughput can also be scheduled by providing a measurement period, a reporting period, and an expiration time. When scheduled, the receiver automatically starts, stops, and restarts the internal timer and measures the data rate of the bytes recorded during each measurement period. Then, in the appropriate reporting period, the receiver sends a DTM report with the requested measurement type. Explicit mode can provide the requester with the ability to control the measurement at the receiver to start measurement collection (e.g., initialize throughput counters), continue measurement collection, report and continue measurement collection, report and reset measurement collection, and report and stop measurement collection. If the measurement request is an explicit request, the payload size can be included to specify how many bytes of data are sent. In addition, the burst size can also be included to specify how many requests are sent in a burst.

[0136] Table 4 - Throughput measurement configuration

[0137]

[0138] Round trip time measurement enables a SEALDD client or SEALDD server to measure the round trip delay of a SEALDD message between a SEALDD client and a SEALDD server. RTT delay can be measured using a single request / response message pair, or delay can be measured over a measurement period, where the delay can be averaged or post-processed to provide a measure of network latency. Similar to throughput measurement, RTT delay measurement can be configured to operate in autonomous or explicit mode. For autonomous mode, the requester can provide a measurement period, a reporting interval, and an expiration time for the measurement. As needed, a burst size can be specified to provide multiple RTT delay measurements. Similar to throughput measurement, the same explicit mode can be specified: start measurement, continue measurement, report and continue measurement, report and reset measurement, and report and stop measurement. The type of measurement reported can include current value (e.g., last value or moving average), minimum value, maximum value, average value, normalized value, etc.

[0139] Table 5 - Round Trip Time Measurement Configuration

[0140]

[0141] Jitter measurements can be used to represent the variance of delays between different packets passed within a SEALDD connection. In this case, the receiver may receive packets with various delays and out of order compared to when the packets were sent. As a result, an easy way to configure jitter measurements is to send bursts of requests with the same burst identifier and different packet numbers, and have the receiver calculate the jitter based on the arrival time of the packets. Therefore, the burst size information element can play an important role in the configuration of jitter measurements. Similarly, the configuration of the measurement type can also provide additional information about the jitter measurement. Similar to other measurements, jitter measurements can also be configured to operate in autonomous or explicit mode.

[0142] Table 6 - Jitter measurement configuration

[0143]

[0144] The packet loss rate measurement can be measured by the receiver of the SEALDD service and can be used to indicate the ratio of packet loss relative to a known total number of packets. For this measurement, the configuration of the total number of packets may be important because the packet loss rate can be calculated as the ratio of received packets to the total number of packets. The sender can provide all packets at the beginning of each measurement period, and the receiver can record the number of packets received during the period and use all sent packets to calculate the packet loss rate percentage. Similar to other measurements, the packet loss rate measurement can be configured to provide different types of measurement values, and can also be configured to operate in autonomous or explicit operation mode.

[0145] Table 7 - Packet loss rate measurement configuration

[0146]

[0147] The retransmission rate can be measured by the sender of the SEALDD service and can be used to indicate the ratio of retransmissions relative to the total number of packets or during the measurement period. If an acknowledgment is not received within a certain time, the sender may decide to retransmit the packet, or the packet may be requested by the receiver. The retransmission rate can then be calculated as the number of retransmitted packets relative to the total number of packets. Similar to other measurements, the retransmission rate measurement can be configured to provide different types of measurement values, and can also be configured to operate in an autonomous or explicit mode of operation.

[0148] Table 8 - Resend rate measurement configuration

[0149]

[0150] The SEALDD action guarantee of the data delivery service is described here. The VAL client can use SEALDD data transmission measurement to assist in determining which VAL servers to send application data to. After VAL server selection and during the SEALDD data delivery service, there may be interference or congestion in the network that reduces the performance of the data delivery service so that it significantly affects the user experience. In response, the SEALDD layer may be able to provide "action guarantees" to address such network congestion, interference and / or errors.

[0151] "Action guarantee" can represent the ability of SEALDD layer to perform other actions to improve data delivery service without the intervention of VAL application. Some examples of SEALDD layer executable actions include requesting to modify the user plane resources in the network of SEALDD connection, adding redundant transmission of specific application business, using SEALDD data storage or cache capability, using SEALDD server forwarding agent and even triggering the autonomous action guarantee of SEALDD server. Table 9 shows an example of action guarantee configuration that SEALDD client, VAL client or VAL server can request from SEALDD server. Action guarantee configuration can be provided as a part of SEALDD connection establishment or DTM measurement enable request. Alternatively, action guarantee configuration can be used as the update of SEALDD connection separately. In one embodiment, as a part of SEALDD data delivery request, VAL client can provide the information of action guarantee configuration to SEALDD client, and in another embodiment, after receiving application business from SEALDD server, VAL server can provide action guarantee configuration to SEALDD server. In the third embodiment, in response to the enabling of data transmission measurement, SEALDD client or server can specify action guarantee. Action guarantee configuration can also be based on local or pre-supplied strategy.

[0152] Table 9-Action guarantee configuration information

[0153]

[0154]

[0155] The action guarantee configuration may include a SEALDD connection identifier to which the action guarantee applies, a DTM configuration identifier for specifying a data transmission measurement applied to the action guarantee, and / or an application identifier associated with the action guarantee. The SEALDD client may explicitly trigger the action guarantee, or allow the SEALDD server to autonomously trigger the action guarantee based on certain events. In explicit mode, the SEALDD client may specify an action guarantee to be performed by the SEALDD server. In autonomous mode, the SEALDD client may provide an event or rule that may trigger an action guarantee. An event or rule may specify a limit on the data transmission measurement that may trigger an action guarantee. For example, a rule may be that if the throughput drops to 90% below a certain throughput level (e.g., 5Mbps), the use of redundant transmission is triggered. Another example may be that a SEALDD server forwarding agent is used if the connection is unavailable or is experiencing severe degradation. A third example may be that if measurements obtained from a 5G network indicate network congestion in a specific UPF serving a SEALDD connection, the user plane resources of the SEALDD connection are modified. For events that trigger action guarantees, other examples may also be conceivable.

[0156] Configuration can also be used for the use of SEALDD data storage or caching capabilities or SEALDD server forwarding agents. The use of SEALDD data storage or caching capabilities can be triggered to provide an alternative path for SEALDD data delivery services to a SEALDD server that can temporarily store application data. It should be noted that the SEALDD capabilities of data storage and caching can be collectively referred to as temporary data storage below, but the features can be functionally different. The application business can then be requested by the original SEALDD server to be forwarded to the VAL server. Similarly, the use of the SEALDD server forwarding agent can allow the SEALDD data delivery business to be rerouted to the original SEALDD server through the agent before the application business is forwarded to the VAL server. In both cases, the action guarantees that an alternative route is provided for the SEALDD data delivery business.

[0157] In addition to using the application layer proxy for store and forward functions, the SEALDD server can also be enabled to utilize core network functions, such as device triggering or changing (if authorized) core network downlink buffering and delay parameters. The SEALDD server can also be enabled to autonomously decide to select an alternative delivery mechanism, such as SMS, to utilize the core network store and forward functions.

[0158] It should be noted that for certain data delivery services, some of the aforementioned actions may require the SEALDD client (and therefore, the UE) to be authorized. For example, the use of redundant transmissions may require additional authorization for the UE. The use of SEALDD data storage or cache may also require authorization. In the following process, it can be assumed that: for the described actions to ensure that the SEALDD client is authorized.

[0159] Fig.13 An exemplary process 1300 for requesting modification of certain user plane resources of a PDU session carrying a data delivery service is shown. In this example, a SEALDD client 1311 of a UE 1301 requests a SEALDD server 1303 to modify certain user plane resources of a PDU session carrying a data delivery service. The SEALDD client 1311 has established a SEALDD data delivery service and enables SEALDD data transmission measurement collection. After some time, the SEALDD client 1311 may receive a DTM report from the SEALDD server 1303, and the DTM report may indicate that the application service is experiencing a delay longer than the usual delay or is transmitted at a low data rate. In response, the SEALDD client 1311 may request the SEALDD server 1303 to perform an action guarantee, such as requesting modification of the user plane of a PDU session carrying a data delivery service.

[0160] At step 1320, the SEALDD client 1311 and the SEALDD server 1303 may negotiate or configure to use data transmission measurement for the data delivery service between the VAL client 1310 of the UE 1301 and the VAL server 1304. This step may be performed as follows: Fig.10 The SEALDD data transfer measurement enabling process described in .

[0161] In step 1321, according to the configured reporting interval, a DTM report may be generated and transmitted between the SEALDD client 1311 and the SEALDD server 1303. The report may indicate that there is a network congestion or error that causes the data delivery service to not provide the appropriate service guarantee required by the VAL application 1304. This step may be repeated during multiple reporting time periods to provide the SEALDD client 1311 and the SEALDD server 1303 with a historical sampling of the data transmission quality during the life of the data delivery service of the VAL application. The DTM report may contain information as listed in Table 2. The SEALDD client 1311 and the SEALDD server 1303 may send individual reports of the measurements collected by each of them for reporting.

[0162] In step 1322, SEALDD client 1311 may determine that end-to-end data transmission measurements indicate that it cannot meet the data delivery requirements of the application service, for example due to network congestion. As a result, SEALDD client 1311 may decide to perform action guarantees so that the data delivery service can be improved to meet the application service requirements.

[0163] In step 1323, the SEALDD client 1311 may decide to request the SEALDD server 1303 to perform user plane management to improve the data delivery service. The SEALDD client 1311 may send a SEALDD connection update request to the SEALDD server 1303 and may include a SEALDD connection identifier, modified DTM configuration information, and action guarantee configuration as shown in Table 9. The request may also include other information as shown in Table 1 to update the DTM configuration of the SEALDD data delivery connection.

[0164] In step 1324, the SEALDD server 1303 may perform an action guarantee based on the request, wherein a user plane modification is performed in the 5G network. The SEALDD server 1303 may request the 5GC 1302 to perform UPF selection (reselection) or update the user plane delay requirements. Other examples of user plane modifications may be the use of an uplink classifier UPF or a branch point UPF and the use of a local area data network (LADN) if the UE is within a certain LADN service area. The SEALDD server 1303 may also communicate with an OAM management node 1302 in the network to request a user plane modification associated with a PDU session for a data delivery service. This step may be associated with the impact of an application function (AF) on the service routing process, wherein the SEALDD server 1303 acts as an AF. The SEALDD server 1303 may also send measurement subscriptions to the 5GC and other network functions, such as Fig.10 as described in step 1027 of FIG.

[0165] At step 1325, the SEALDD server 1303 may respond to the SEALDD client 1311 with the status of the user plane modification request and any DTM configuration information that was changed or updated. The SEALDD server 1303 may also provide the SEALDD client 1311 with updates of the DTM configuration.

[0166] At step 1326, application data traffic may be sent within the SEALDD data delivery connection, and both the SEALDD client 1311 and the SEALDD server 1303 may collect and process data for data transmission measurements. As a result of the user plane modification, the SEALDD connection may use different underlying user plane resources than were originally used for application traffic prior to step 5.

[0167] In step 1327, according to the configured measurement reporting interval, the SEALDD client 1311 and the SEALDD server 1303 may submit a DTM report containing enabled data transmission measurements and other information, as shown in Table 2. The DTM report may be compared with the DTM report obtained in step 2 to evaluate whether the user plane modification successfully improved the data delivery service. The SEALDD client 1311 and the SEALDD server 1303 may send individual reports of the measurements collected by each of them for reporting.

[0168] Another action guarantee that can be requested by SEALDD client 1311 or performed by SEALDD server 1303 is the use of redundant transport. SEALDD redundant transport allows the use of two different user plane paths to route application traffic to ensure reliable data delivery of application traffic from VAL client to VAL server. The use of redundant transport can be used to address lower throughput caused by network congestion, increased RTT delay and / or jitter, and higher packet loss or retransmission rates.

[0169] Fig.14 An exemplary process 1400 for requesting to use redundant transmission due to a DTM report showing network congestion for a SEALDD connection is shown. In this example, a SEALDD client 1411 of a UE 1401 requests to use redundant transmission due to a DTM report showing network congestion for a SEALDD connection.

[0170] Steps 1420-1422 can be performed with Fig.13 Steps 1320-1322 are the same.

[0171] In step 1423, the SEALDD client 1411 may decide to use redundant transmission to improve the data delivery service, and may request that redundant transmission be used for the SEALDD connection. If authorized to use redundant transmission, the SEALDD server 1403 may perform an AF-affected URSP process with the 5G network, and the UE may need to establish a redundant PDU session with the 5G network. If the UE is not authorized to use redundant transmission, the SEALDD client 1411 may establish a second PDU session and process future application data services as if redundant transmission was used. In this scenario, the SEALDD layer may manually manage redundant transmission. Alternatively, the UE may request authorization to use redundant transmission from the SEALDD server 1403 or from the 5G network.

[0172] In step 1424, SEALDD client 1411 can send SEALDD connection update request to SEALDD server 1403, and this request has information about redundant PDU session, for example UE IP address and port number of redundant PDU session or the information that is used to manually manage redundant transmission at SEALDD layer.This request can also include SEALDD connection identifier and DTM configuration information for new transmission.This request can indicate that the action guarantee that will be taken because the DTM report received before shows that there may be network congestion and / or error experienced by data delivery service.Action guarantee configuration can be as shown in table 9.This request can also include other information as shown in table 1 to update the DTM configuration of original transmission.For example, SEALDD client 1411 can configure different measurement and report intervals.

[0173] At step 1425, SEALDD server 1403 may respond to SEALDD client 1411 with the status of the SEALDD connection update request and any DTM configuration information changed or updated for the original transfer. SEALDD server 1403 may also include DTM configuration for SEALDD client 1411 to collect and report requested data transfer measurements for the new transfer.

[0174] In step 1426, the SEALDD server 1403 may subscribe to receive notifications to obtain network measurements and / or analysis of redundant or new PDU sessions. The SEALDD server 1403 may also send measurement subscriptions to the 5GC 1402 and other network functions, such as Fig.10 as described in step 7.

[0175] In step 1427, the SEALDD client 1411 and the SEALDD server 1403 manage redundant application traffic and discard any duplication before sending data to the VAL layer. In the case where the SEALDD layer manually manages redundant transmissions, additional mapping information may be maintained by both the SEALDD client 1411 and the SEALDD server 1403. At the same time, both the SEALDD client 1411 and the SEALDD server 1403 may collect and process data for configured data transmission measurements.

[0176] At step 1428, SEALDD client 1411 and SEALDD server 1403 may submit DTM reports, which contain enabled data transmission measurements and other information, as shown in Table 2, according to the configured measurement reporting interval. The DTM reports may be compared with the DTM reports obtained in step 1421 to evaluate whether redundant transmissions are successful in improving data delivery services.

[0177] The SEALDD layer provides certain capabilities to enhance data delivery services, and one such capability is the ability to use the SEALDD server 1403 for data storage or high-speed caching. It should be noted that, as previously described, the SEALDD capabilities of data storage and high-speed caching can be collectively referred to as temporary data storage, but the characteristics can be different. The SEALDD temporary data storage can be used as an action guarantee, wherein application data can be rerouted to the SEALDD server 1403 with temporary data storage capabilities. The original SEALDD server 1403 responsible for the application business can then retrieve the application data from the SEALDD server 1403 with temporary data storage capabilities to forward to the VAL server 1404. This action guarantee can be used when the SEALDD connection with the original SEALDD server 1403 is unavailable or is experiencing severe degradation.

[0178] Fig.15 An exemplary process 1500 for requesting an alternative path for application data is shown. In this example, a SEALDD client 1511 of a UE 1501 requests that an alternative path for application data be provided to a VAL server 1505 using a SEALDD server 1503, 1504 with temporary data storage capabilities.

[0179] Similar to Fig.13 Steps 1320-1322, steps 1520-1522 may be executed.

[0180] At step 1523, the SEALDD client 1511 may determine the ability to use the temporary data storage feature of the SEALDD layer and may establish or modify a PDU session for establishing a SEALDD connection to a SEALDD server 1504 that supports the temporary data storage capability. Fig.10 In step 1021 , as part of the DTM enabling process, the SEALDD client 1511 may have been provisioned with a SEALDD server that supports temporary data storage.

[0181] At step 1524, the SEALDD client 1511 may establish a new SEALDD connection with the SEALDD server 1504 and may provide a SEALDD connection identifier and DTM configuration information as shown in Table 1 to enable collection and processing of data transfer measurements. The SEALDD client 1511 may also provide an action guarantee configuration (such as a temporary data storage URI) as shown in Table 9 to enable the SEALDD server 1504 to retrieve application data from the SEALDD server 1503. The SEALDD client 1511 may have received the URI from the SEALDD server 1503 during the original SEALDD connection establishment.

[0182] At step 1525, the SEALDD server 1504 may respond to the SEALDD client 1511 with the status of the SEALDD connection request, a resource location identifier (such as a URI) where to access the temporary data store from the SEALDD server 1504, and any DTM configuration information changed or updated by the SEALDD server 1504. The SEALDD server 1504 may also include the DTM configuration of the SEALDD client 1511 to collect and report data transfer measurements for the request of the new SEALDD connection.

[0183] In step 1526, SEALDD client 1511 may perform a SEALDD connection update with SEALDD server 1503 and may provide an action guarantee configuration to configure SEALDD server 1503 to act as a data retrieval server. The request may also include a SEALDD connection identifier, a URI provided by SEALDD server 1504 in step 6, and other action guarantee configurations. The URI may allow SEALDD server 1503 to retrieve application data stored in SEALDD server 1504.

[0184] In step 1527, SEALDD server 1503 may subscribe to receive notifications of application data from SEALDD server 1504 using the URI received in step 7. Likewise, SEALDD server 1504 may subscribe to receive notifications of application data from SEALDD server 1503 using the URI received in step 5.

[0185] In step 1528, SEALDD server 1503 and SEALDD server 1504 may subscribe to receive notifications of network measurements and / or analysis from the 5G network and / or from OAM management node 1502, such as Fig.10 as described in step 1027 of FIG.

[0186] At step 1529, application data traffic may be sent within the SEALDD data delivery connection, and both the SEALDD client 1511 and the SEALDD server 1504 may collect and process data for data transmission measurements. For the case of uplink application data, the VAL client 1510 of the UE 1501 provides the SEALDD client 1511 with application data, and the SEALDD client 1511 transmits the data to the SEALDD server 1504 via the SEALDD connection. The SEALDD server 1504 then notifies the SEALDD server 1503 of the application data, and the SEALDD server 1503 sends the application data to the VAL server 1505. For the case of downlink application data, the VAL server 1505 provides the SEALDD server 1503 with application data, and the SEALDD server 1503 notifies the SEALDD server 1504 of the application data. The SEALDD server 1504 then transmits the application data to the SEALDD client 1511 via the SEALDD connection, and the SEALDD client 1511 provides the data to the VAL client.

[0187] At step 1530, the SEALDD client 1511 and SEALDD server 1504 may submit DTM reports, which contain enabled data transmission measurements and other information, as shown in Table 2, according to the configured measurement reporting interval. The DTM reports may be compared with the DTM reports obtained in step 2 to evaluate whether the SEALDD temporary data storage is successfully improving the data delivery service.

[0188] Similar to the action guarantee using a SEALDD server with temporary data storage capability, the SEALDD client 1511 can also request to use a SEALDD server that supports forwarding proxy functionality. In this scenario, the SEALDD server forwarding proxy receives application data from the SEALDD client 1511 and forwards the SEALDD service to the original SEALDD server, which then forwards the application data to the VAL server.

[0189] Fig.16 An exemplary process 1600 for action assurance involving a SEALDD forwarding proxy server is shown. Fig.13 Steps 1320-1322, steps 1620-1622 may be executed.

[0190] At step 1623, the SEALDD client 1611 may decide to establish a new SEALDD connection to the SEALDD proxy to forward the SEALDD traffic to the SEALDD server 1603, and may establish or modify a PDU session for establishing a SEALDD connection to the SEALDD server 1604. Fig.10 In step 1021 of , as part of the DTM enablement process, the SEALDD client 1611 of the UE 1601 may have been provisioned with a SEALDD server that supports SEALDD proxy capabilities.

[0191] In step 1624, SEALDD client 1611 may establish a new SEALDD connection with SEALDD server 1604, and may provide an action assurance configuration as shown in Table 9 and DTM configuration information as shown in Table 1 to enable the collection and processing of data transmission measurements. SEALDD client 1611 may provide a SEALDD connection identifier, contact information of SEALDD server 1603, and enable forwarding proxy functionality. This configuration may notify SEALDD server 1604 to forward all SEALDD traffic associated with the SEALDD connection identifier to SEALDD server 1603.

[0192] At step 1625, SEALDD server 1604 may respond to SEALDD client 1611 with the status of the SEALDD connection request and any DTM configuration information changed or updated by SEALDD server 1604. SEALDD server 1604 may also include DTM configuration for SEALDD client 1611 to collect and report data transfer measurements for requests for new SEALDD connections.

[0193] In step 1626, SEALDD client 1611 performs a SEALDD connection update with SEALDD server 1603, and SEALDD proxy mode may be configured to pass in and provide contact information of SEALDD server 1604. This configuration may inform SEALDD server 1603 to receive all SEALDD services associated with SEALDD flows from SEALDD server 1604, and forward application data to VAL server 1605.

[0194] In step 1627, SEALDD server 1603 and SEALDD server 1604 may subscribe to receive notifications of network measurements and / or analysis from the 5G network and / or from OAM management node 1602, such as Fig.10 as described in step 1027 of FIG.

[0195] At step 1628, application data may be provided by the VAL client 1610 of the UE 1601 to the SEALDD client 1611. The SEALDD client 1611 transmits the application data to the SEALDD server 1604, and due to the configuration that the SEALDD server 1604 is a forward proxy, the SEALDD server 1604 may forward the application data to the SEALDD server 1603. The SEALDD server 1603 may then route the application data to the VAL server 1605. Conversely, the application data from the VAL server 1605 is sent to the SEALDD server 1603, which forwards the data to the SEALDD server 1604. The data is then sent to the SEALDD client 1611, which forwards the data to the VAL client 1610. If configured, both the SEALDD client 1611 and the SEALDD server 1604 may collect and process data for data transmission measurements.

[0196] At step 1629, according to the configured measurement reporting interval, SEALDD client 1611 and SEALDD server 1604 may submit DTM reports containing enabled data transmission measurements and other information, as shown in Table 2. The DTM reports may be compared with the DTM reports obtained at step 1621 to evaluate whether the SEALDD forwarding agent is successfully improving the data delivery service.

[0197] Since the DTM report shows that network congestion or interference affects the SEALDD data delivery service, the aforementioned action guarantee process has been initiated entirely by the SEALDD client 1611. The SEALDD client 1611 may proactively configure the SEALDD server to perform such action guarantees when measuring or receiving measurements or information about network congestion or interference. The SEALDD server may not only be able to collect and measure end-to-end data transmission measurements, but it may also be able to receive network performance measurements from the 5G network or obtain analytical statistics or predictions from analytical functions. Due to this capability, the SEALDD server may then be able to perform the configured action guarantees, and may even be able to autonomously determine the best action guarantees to be performed to improve the SEALDD connection quality.

[0198] Fig.17 An exemplary process 1700 is shown in which a SEALDD server is configured to perform autonomous action guarantees. Due to network congestion, an action guarantee may be triggered, and the SEALDD server 1703 may be configured with an action guarantee to be performed or configured to autonomously determine which action guarantees to perform.

[0199] At step 1720, the SEALDD client and SEALDD server 1703 may negotiate or configure to use data transmission measurement for data delivery services between the VAL client 1710 of the UE 1701 and the VAL server 1705. This step may be performed as follows: Fig.10 In addition, the SEALDD client 1711 of the UE 1701 may also configure the SEALDD server 1703 to autonomously perform the action assurance process based on one or more events that may indicate network congestion. Alternatively, the SEALDD server 1703 may be configured by a local or pre-provisioned policy to autonomously perform action assurance. The policy may contain rules that trigger autonomous action assurance.

[0200] At step 1721, the SEALDD server 1703 evaluates the data transmission measurements it has obtained against the rules configured for autonomous mode. The SEALDD server 1703 may determine that an action guarantee needs to be performed when the measurement triggers a rule indicating that network congestion or some other network error may occur. Alternatively, the SEALDD server 1703 may also determine that an action guarantee is needed in response to network performance measurements received from the 5G network or statistics or predictions provided by the analysis function indicating possible network congestion that may affect the SEALDD connection.

[0201] In step 1722, if an explicit action guarantee is specified, the SEALDD server 1703 may perform the configured action guarantee. If the action guarantee is specified to be determined autonomously by the SEALDD server, the SEALDD server 1703 may evaluate data transmission measurements to determine which action guarantees will be performed. The SEALDD server 1703 may also use other measurements and / or analysis obtained from the 5G network to make action guarantee decisions. In addition, the SEALDD server 1703 may also use application level analysis available at SEAL or other application enabling layers. The SEALDD server 1703 may initiate an action guarantee with the 5G network, the SEALDD client 1711, or another SEALDD server. For example, the SEALDD server 1703 may modify the user plane resources of the PDU session carrying the data delivery service. Other actions may include the SEALDD server 1703 notifying the SEALDD client 1711 to use redundant transmission, the SEALDD server 1703 may use the SEALDD temporary data storage feature, or the SEALDD server 1703 may reroute the application data service through the SEALDD forwarding proxy server.

[0202] In step 1723a, if the action ensures the use of redundant transmission, the SEALDD client 1711 may establish a redundant PDU session with the 5G network in step 1723a and perform a SEALDD connection update in step 1723b as described above.

[0203] In step 1724a, if the action guarantees to use another SEALDD connection, a new PDU session can be established or an existing PDU session can be modified. Then, the SEALDD client 1711 can perform a SEALDD connection establishment with the SEALDD server in step 1724b. The SEALDD server 1703 may have supplied the identifier and IP address and port number of the SEALDD server to be connected with the SEALDD client 1711 in step 1722. The SEALDD connection update may need to be performed in step 1724c to notify the SEALDD server 1703 of a temporary data storage URI or a SEALDD server forwarding agent address. In step 1724d, SEALDD context information transfer may occur between the SEALDD server 1703 and the SEALDD server 1704.

[0204] In step 1725, if a new SEALDD connection is established or an existing SEALDD connection is modified, the SEALDD server 1703 and the SEALDD server 1704 may subscribe to receive notifications of network measurements and / or analysis from the 5G network and / or from the OAM management node 1702, such as Fig.10 as described in step 7.

[0205] At step 1726, application data provided by the VAL layer is transmitted within the SEALDD connection, and data transmission measurements are collected and processed by the SEALDD client 1711 and the SEALDD server according to the configuration.

[0206] At step 1727, according to the configured measurement reporting interval, the SEALDD server and / or SEALDD client 1711 may submit a DTM report containing enabled data transmission measurements and other information, as shown in Table 2. Depending on the number of SEALDD connections, there may be one or more DTM reports exchanged.

[0207] At step 1728, if the action warrants the use of another SEALDD connection, the SEALDD client 1711 may delete the original SEALDD connection with the SEALDD server 1703. Alternatively, the initial SEALDD connection may be deleted autonomously after a certain time, or upon request of the new SEALDD server after the SEALDD context has been transferred.

[0208] Fig.18 An exemplary graphical user interface (GUI) 1800 is shown in which a user of a UE may provide an action assurance configuration. The GUI may present the information captured in Table 9 to present to the user to configure the action assurance. The main GUI may show various identifiers of the action assurance configuration and the different action assurance configurations available to the user. Within each configuration option, another GUI may provide the user with a more fine-grained configuration. For example, selecting an autonomous action assurance configuration may present the user with the ability to configure different events that may trigger a specific action assurance. The user may also be able to enable or disable autonomous action assurance as needed. For action assurance that may require other SEALDD capabilities, there may be additional configuration options accessible to the user in the main GUI.

[0209] In describing the preferred embodiments of the subject matter of the present disclosure, as shown in the figures, specific terms are employed for clarity. However, the claimed subject matter is not intended to be limited to the specific terms so selected, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

[0210] In describing the preferred embodiments of the subject matter of the present disclosure, as shown in the figures, specific terms are employed for clarity. However, the claimed subject matter is not intended to be limited to the specific terms so selected, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.

Claims

1. A device comprising a processor, a memory and a communication circuit system, the device being connected to a network via its communication circuit system, the device further comprising computer executable instructions stored in the memory of the device, the computer executable instructions when executed by the processor of the device causing the device to: receiving, by a Vertical Industry Service Enablement Architecture Layer (SEAL) Data Delivery (SEALDD) client of the device, a request to perform one or more data transmission measurements; performing, by the SEALDD client, the one or more data transmission measurements; sending, by the SEALDD client to the SEALDD server, first information indicating one or more data transmission measurements performed by the SEALDD client; and Second information of one or more data transmission measurements performed by the SEALDD server is received from the SEALDD server.

2. The apparatus of claim 1, wherein the request is received from a SEALDD server.

3. The apparatus of claim 1 , wherein the one or more data transmission measurements include at least one of: Application identifier, measurement identifier, Measurement type, a schedule for performing said one or more data transmission measurements, or Reporting schedule.

4. The apparatus of claim 1, wherein the first information indicates at least one of the following: delay, bit rate, jitter, or packet loss rate.

5. The apparatus of claim 1, wherein the second information indicates at least one of the following: delay, bit rate, jitter, or packet loss rate.

6. The device of claim 1, wherein the computer executable instructions, when executed by a processor of the device, further cause the device to: An action assurance configuration is received, the action assurance configuration indicating one or more events that trigger performance of one or more actions.

7. The device of claim 6, wherein the computer executable instructions, when executed by a processor of the device, further cause the device to: Based on the first information or the second information, and based on the action guarantee configuration, an action is performed.

8. The apparatus of claim 7, wherein the action comprises sending a request to use redundant transport for a SEALDD connection.

9. A method comprising: Receiving, by a Vertical Industry Service Enablement Architecture Layer (SEAL) Data Delivery (SEALDD) client, a request to perform one or more data transfer measurements; performing, by the SEALDD client, the one or more data transmission measurements; sending, by the SEALDD client to the SEALDD server, first information indicating one or more data transmission measurements performed by the SEALDD client; and Second information of one or more data transmission measurements performed by the SEALDD server is received from the SEALDD server.

10. The method of claim 9, wherein the request is received from a SEALDD server.

11. The method of claim 9, wherein the one or more data transmission measurements include at least one of the following: Application identifier, measurement identifier, Measurement type, a schedule for performing said one or more data transmission measurements, or Reporting schedule.

12. The method of claim 9, wherein the first information indicates at least one of the following: delay, bit rate, jitter, or packet loss rate.

13. The method of claim 9, wherein the second information indicates at least one of the following: delay, bit rate, jitter, or packet loss rate.

14. The method of claim 9, wherein the computer executable instructions, when executed by a processor of the device, further cause the device to: An action assurance configuration is received, the action assurance configuration indicating one or more events that trigger performance of one or more actions.

15. The method of claim 14, wherein the computer executable instructions, when executed by a processor of the device, further cause the device to: Based on the first information or the second information, and based on the action assurance configuration, an action is performed, wherein the action includes sending a request to use redundant transport for the SEALDD connection.

Images