Seal data transfer management

Abstract

Systems and methods relating to management of vertical industry oriented service enabled architecture layer (SEAL) data transfer via cellular communication systems are disclosed. In one embodiment, a method performed by a system for SEAL data transfer via a telecommunications system includes determining, at a vertical application layer (VAL) server of a regulatory domain, a policy for data transfer from a client in a first business participant domain to a VAL server in a second business participant domain, where the VAL server is configured to receive data from the client in the first business participant domain, and the VAL server is configured to receive data from the client in the second business participant domain. The data transfer is communication via SEAL data transfer over the telecommunications system. The method further includes, at the VAL server of the regulatory domain, providing the policy to a SEAL data transfer server in the regulatory domain for enforcement of the policy, including establishing a data transfer connection between a first business participant domain (SEAL DD client) and a second business participant domain (VAL server).

Description

[0001] Related Applications

[0002] This application claims the benefit of international patent application serial number PCT / CN2022 / 123680 filed on October 3, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to data delivery management according to the Service Enablement Architecture Layer (SEAL) standard for vertical industries. Background Art

[0004] Vertical applications place high demands on the openness of 5G capabilities and resources of the fifth generation 5G system (5GS). Ericsson leads all telecom vendors in the openness of device connection management capabilities. In the industrial context, the openness of device connection management is being studied in depth (for example, see 5G-ACIA, "Exposure of 5G Capabilities for Connected Industries and Automation Applications", 2021). Ericsson has been contributing work on the opening of device connection management capabilities to the 3rd Generation Partnership Project (3GPP) Service Enabler Architecture Layer for Verticals (SEAL) standard (see 3GPP, "TS 23.434; Technical Specification Group Services and System Aspects; Service Enabler Architecture Layer for Verticals (SEAL); Functional architecture and information flows; Release 18)", 2022, and 3GPP "TS 29.549; Technical Specification Group Core Network and Terminals; Service Enabler Architecture Layer for Verticals (SEAL); Application Programming Interface (API) specification; Stage 3 (Release 17)". 3(Release17))”, 2022). Summary of the invention

[0005] Systems and methods are disclosed that relate to management of vertical industry-oriented service enabling architecture layer (SEAL) data transfer via a cellular communication system. In one embodiment, a method performed by a system for SEAL data transfer via a cellular communication system includes: determining, at a vertical application layer (VAL) server of a regulatory domain of the system, a policy for data transfer from a client (e.g., a SEAL DD client) in a first business participant domain of the system to a VAL server in a second business participant domain of the system, wherein the data transfer is via a SEAL data transfer communication. The method also includes: providing, at the VAL server of the regulatory domain, the policy to a SEAL data transfer server in the regulatory domain of the system for implementation of the policy. The method also includes: receiving, at the SEAL data transfer server, the policy from the VAL server of the regulatory domain of the system for implementation of the policy for data transfer from the VAL client in the first business participant domain of the system to the VAL server in the second business participant domain of the system, wherein the data transfer is via a SEAL data transfer communication over a cellular communication system. The method also includes, at the SEAL data transfer server, implementing the policy for data transfer between the first business participant domain and the second business participant domain, such as triggering a data transfer (DD) communication channel between the first business participant domain and the second business participant domain to transfer data. In this way, a data owner (e.g., a first business participant) can share data with a data user (e.g., a second business participant) in a secure manner.

[0006] Embodiments of a VAL server in a regulatory domain and a method of operating the same are also disclosed.

[0007] Embodiments of a SEAL data transfer server and method of operating the same in a supervisory domain are also disclosed.

[0008] In one embodiment, a method performed by a system for SEAL data transfer via a cellular communication system comprises: at a VAL server of a regulatory domain of the system, sending a request to a SEAL data transfer server in the regulatory domain of the system, the request comprising a policy for connection establishment for data transfer from a VAL client in a first business participant domain of the system to a VAL server in a second business participant domain of the system. The method further comprises: at the SEAL data transfer server of the regulatory domain of the system, receiving from the VAL server of the regulatory domain of the system the request comprising the policy for connection establishment for data transfer from the VAL client in the first business participant domain of the system to the VAL server in the second business participant domain; authorizing the request; and storing the policy for implementation.

[0009] In one embodiment, the policy is pre-configured in the regulatory domain.

[0010] In one embodiment, the method also includes: at the SEAL data transfer server in the regulatory domain of the system: determining that the policy for connection establishment for data transfer is to be implemented; and according to the policy: sending a data transfer connection establishment notification to the SEAL data transfer client in the first business participant domain of the system that communicates with the VAL client in the first business participant domain of the system via a cellular communication system for establishing a first connection for data transfer; sending a data transfer connection establishment notification to the VAL server in the second business participant domain for establishing a second connection for data transfer; and enabling data transfer between the VAL client and the VAL server via the SEAL data transfer client on the first connection and the second connection.

[0011] In one embodiment, the method further comprises: determining, at the VAL server in the regulatory domain, that the policy for data transfer is to be updated, and sending an update request to the SEAL data transfer server in the regulatory domain of the system, the update request comprising the updated policy for connection establishment for data transfer from the VAL client in the first business participant domain of the system to the VAL server in the second business participant domain of the system. The method further comprises: receiving, at the SEAL data transfer server in the regulatory domain, the update request comprising the updated policy; authorizing the update request; and storing the updated policy for implementation.

[0012] In one embodiment, the method also includes: at the SEAL data transfer server of the regulatory domain, determining to delete the second connection with the VAL server in the second business participant domain and the first connection with the SEAL data transfer client in the first business participant domain; notifying the VAL server in the second business participant domain that the second connection is to be deleted; and notifying the SEAL data transfer client that the first connection is to be deleted.

[0013] In one embodiment, a method performed by a SEAL data transfer server of a regulatory domain of a system for providing SEAL data transfer via a cellular communication system comprises: receiving a request from a VAL server of the regulatory domain of the system, the request comprising a policy for connection establishment for data transfer from a VAL client in a first business participant domain of the system to the VAL server in a second business participant domain of the system. The method further comprises: authorizing the request; and storing the policy for implementation.

[0014] In one embodiment, the policy is pre-configured in the regulatory domain.

[0015] In one embodiment, the method also includes: determining that the policy for establishing a connection for data transfer is to be implemented; and according to the policy: sending a data transfer connection establishment notification to a SEAL data transfer client in the first business participant domain of the system that communicates with the VAL client in the first business participant domain of the system via a cellular communication system for establishing a first connection for data transfer; sending a data transfer connection establishment notification to the VAL server in the second business participant domain for establishing a second connection for data transfer; and enabling data transfer between the VAL client and the VAL server via the SEAL data transfer client on the first connection and the second connection.

[0016] In one embodiment, the method further includes: receiving an update request from the VAL server in the regulatory domain of the system, the update request including an updated policy for establishing a connection for data transmission from the VAL client in the first business participant domain of the system to the VAL server in the second business participant domain of the system; authorizing the update request; and storing the updated policy for implementation.

[0017] In one embodiment, the method further includes: determining to delete the second connection with the VAL server in the second business participant domain and the first connection with the SEAL data transfer client in the first business participant domain; notifying the VAL server in the second business participant domain that the second connection is to be deleted; and notifying the SEAL data transfer client that the first connection is to be deleted.

[0018] Corresponding embodiments of a SEAL data transfer server are also disclosed. In one embodiment, a SEAL data transfer server of a regulatory domain of a system for providing SEAL data transfer via a cellular communication system is adapted to: receive a request from a VAL server of the regulatory domain of the system, the request including a policy for connection establishment for data transfer from a VAL client in a first business participant domain of the system to the VAL server in a second business participant domain of the system. The SEAL data transfer server is further adapted to: authorize the request; and store the policy for implementation.

[0019] A corresponding embodiment of a server computer for implementing a SEAL data transfer server is also disclosed. In one embodiment, a server computer for implementing a SEAL data transfer server for a regulatory domain of a system for providing SEAL data transfer via a cellular communication system includes: a network interface; and processing circuitry associated with the network interface. The processing circuitry is configured to cause the server computer to perform the following operations to operate as the SEAL data transfer server: receive a request from a VAL server of the regulatory domain of the system, the request including a policy for connection establishment for data transfer from a VAL client in a first business participant domain of the system to the VAL server in a second business participant domain of the system; authorize the request; and store the policy for implementation. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0021] Figure 1 An example of data transmission between business participants according to an embodiment of the present disclosure is shown;

[0022] Figure 2 A network functional model for data distribution management on the SEAL layer according to an embodiment of the present disclosure is shown;

[0023] Figure 3 shows a data delivery (DD) policy creation process according to some embodiments of the present disclosure;

[0024] Figure 4 shows DD policy enforcement and DD communication establishment according to one embodiment of the present disclosure;

[0025] Figure 5 shows DD policy enforcement and DD communication establishment according to another embodiment of the present disclosure;

[0026] Figure 6 The DD policy information query process according to one embodiment of the present disclosure is shown;

[0027] Figure 7 shows a DD policy information query process according to another embodiment of the present disclosure;

[0028] Figure 8 The DD communication information query process according to one embodiment of the present disclosure is shown;

[0029] Fig. 9 shows a DD communication information query process according to another embodiment of the present disclosure;

[0030] Fig.10 shows a DD policy update process according to an embodiment of the present disclosure;

[0031] Fig.11 shows a DD communication update process according to another embodiment of the present disclosure;

[0032] Fig.12 shows a DD policy deletion process according to an embodiment of the present disclosure;

[0033] Fig.13 A DD communication deletion notification process according to an embodiment of the present disclosure is shown;

[0034] Fig.14 shows a DD communication deletion process according to an embodiment of the present disclosure;

[0035] Fig.15 shows a DD policy deletion process according to another embodiment of the present disclosure;

[0036] Fig.16 and 17 is a schematic block diagram of a server computer according to some embodiments of the present disclosure; and

[0037] Fig.18 is a schematic block diagram of a user equipment device (UE) according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0038] The embodiments described below represent information that enables those skilled in the art to practice the embodiments, and illustrate the best mode for practicing these embodiments. After reading the following description with reference to the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure, and will recognize the applications of these concepts not specifically mentioned herein. It should be understood that these concepts and applications fall within the scope of the present disclosure.

[0039] 5G API: A fifth generation (5G) application programming interface (API) is an application programming interface that exposes 5G network capabilities to users, especially to business participants and regulators in the preferred use cases described herein. The 5G API acts as an intermediary between the 5G network and the users. It allows users to directly manage and monitor the connectivity or quality of the network without the involvement of the mobile network operator's staff. Therefore, it provides simplicity to the users as the users can simply send requests on their own to make changes in the 5G network, add their devices to the network or create new device groups, etc. The 5G API can then forward these requests to the relevant 5G core network functions to perform the necessary actions requested by the user.

[0040] Application: An application is an application from a business participant. It can be located on any computing engine (for example, cloud or edge cloud).

[0041] Business Participant: A business participant is a participant who is authorized to use the 5G API to, for example, request communication policy creation, establish communication links, etc. This participant can be from any vertical sector, including robotics companies, software development companies, railway companies, and power distribution companies.

[0042] Data Orchestrator: A data orchestrator is a software entity that has mechanisms to collect data from many data sources, sort the data, and retransmit the data within a specific time period. It is responsible for orchestrating when to enable communication between business participants and how long to allow data to be transmitted.

[0043] Regulator: A regulator is a business entity that is authorized to enable the communication between different business actors. It can do this manually or program the data orchestrator to enable / disable the communication itself.

[0044] Vertical devices: Vertical devices are physical assets of business participants that are connected to 5G user equipment (UE). The device can collect or generate data on-site to be sent to applications via the 5G network.

[0045] Existing technologies present specific challenges. In particular, real-time data streams from field devices and data processed by applications or stored in databases are used by data owners for analysis and other purposes. This data can be provided to other business participants from the same or different vertical sectors. Other business participants will analyze the data and provide value-added services to the data owner. Sharing data with other business participants is beneficial to both the service provider and the data owner. However, currently data cannot be shared between business participants or can only be shared in a very limited way.

[0046] Today, data owners cannot share data with other business actors in a convenient way while keeping their critical infrastructure secure. Furthermore, access cannot be provided within predefined time windows. In practice, it is often the case that data only needs to be provided within specific time intervals, for example, when no critical infrastructure operations are being performed.

[0047] One of the existing solutions to these problems is to exchange data via a virtual private network (VPN). However, setting up and configuring a VPN solution requires information technology (IT) expertise that the data owner and other business participants usually do not have. For example, VPNs need to be configured, login details and keys need to be shared between the data owner and other business participants, and firewalls need to be set up correctly. In addition, the wired communications currently used are a less flexible and cost-effective alternative compared to wireless communications, etc. Therefore, sharing data with other business participants is a complex task.

[0048] Disclosed herein are systems and methods for addressing the above and / or other challenges. Embodiments of the proposed solution enable data owners to share their data with other business participants (i.e., data users) in a convenient manner. Data users can be participants from the same vertical as the data owner or participants from different verticals. In addition, there will be a third participant, referred to herein as a regulator. The regulator manages secure data sharing between data owners and data users.

[0049] In one embodiment, the data owner has the right to define the time and frequency of sharing their data with the data user. The data owner allows the regulator to take responsibility for managing the data sharing between itself and the data user, as long as it is suitable for the data owner. The regulator can define the time window within which the data owner will provide data to the data user according to the preferences of the data owner. The data owner and the data user communicate with each other in a secure manner using standard communication security procedures typical of mobile networks.

[0050] In one embodiment, the solution is implemented in a wireless network (e.g., a 3GPP network, such as a 5G network). Data owners, data users, and regulators interact with the wireless network through an extended wireless network API (e.g., an extended 5G API).

[0051] In one embodiment, the distribution of data between different business participants is defined by regulators and business participants. The data distribution is defined based on the settings of communication endpoints, the time when communication will be allowed, and the setting of other communication characteristics (e.g., the quality of the communication link). In existing mobile networks, these capabilities are handled by mobile network operators; however, in embodiments of the present disclosure, these capabilities are provided to users through new APIs (e.g., new or expanded 5G APIs). Users (e.g., regulators and business participants) are able to set up communications between devices and applications belonging to business participants in the manner described herein.

[0052] While not limited to or by any particular advantage, the embodiments described herein may provide many advantages over the prior art. Embodiments of the present disclosure enable data owners to share data with data users (i.e., another business participant from the same or a different vertical sector) in a secure manner. Through data analysis, data users will be able to provide new services that improve the operations of the data owner's organization. Data owners and data users do not need to have IT expertise to complete this task. New APIs (e.g., new or expanded 5G APIs) will provide simple communication management for regulators and business participants.

[0053] Embodiments of the proposed solution enable the exchange of selected data between business participants in a flexible and secure manner provided and managed by a trusted supervisor. Data owners will share their data with data users at any time through the trusted supervisor without endangering critical infrastructure resources. In addition, data sharing can be further optimized by automating the operation with orchestration tools.

[0054] Various aspects of the embodiments of the present disclosure will now be described in the following subsections. However, it should be noted that the various aspects may be used alone or together in any suitable combination.

[0055] 1. Data transmission management requirements

[0056] This section specifies general requirements for data delivery management services according to embodiments of the present disclosure. These requirements relate to users of the service, such as business participants and regulators.

[0057] 1.1 Requirements for Business Participants

[0058] According to an embodiment of the present disclosure, the data delivery management service described herein satisfies any one or more of the following service requirements related to business participants, or preferably satisfies all service requirements:

[0059] [SR-6.1.1-a] In emergency situations, business participants are able to delete established communications involving their data or applications. After successfully deleting the communication, the regulator will delete the associated policy.

[0060] [SR-6.1.1-b] Business actors can query policy details for all policies defined for their devices or applications.

[0061] [SR-6.1.1-c] A service participant may be able to query the communication performance (e.g., current latency, packet loss, throughput, etc.) of all established connections for its device or application.

[0062] 1.2 Regulator Requirements

[0063] According to an embodiment of the present disclosure, the data delivery management service described herein satisfies any one or more of the following service requirements related to the regulator, or preferably satisfies all service requirements:

[0064] [SR-6.1.2-a] Supervisors will be able to create, update, and delete data transfer policies. Communications will be established or deleted as defined in the policies. In some cases, real-time communications will be updated without deleting and re-establishing the communications link.

[0065] [SR-6.1.2-b] In case of emergency, the supervisor has the ability to delete any established communication. Upon successful deletion of the communication, the associated policy will be deleted.

[0066] [SR-6.1.2-c] The regulator requests a data transfer from a business participant and forwards the data to another business participant.

[0067] [SR-6.1.2-d] Only regulators are allowed to establish communications between business participants.

[0068] [SR-6.1.2-e] Supervisors can query policy details for all policies.

[0069] [SR-6.1.2-f] The supervisor can query the communication performance of all established connections (e.g., current latency, packet loss,

[0070] throughput, etc.).

[0071] 2Business relationships for data transfer management

[0072] Figure 1An example of a data transfer scenario is shown, in which data is sent from one business participant to another business participant. In the scenario shown, participant A's device (referred to herein as the "participant A device") provides data to participant B's application (referred to herein as the "participant B application"). The regulator establishes communication based on predefined policies (e.g., policies defined by a previous agreement between the business participants). The regulator forwards the data from business participant A to business participant B (e.g., from the participant A device to the participant B application). Note that the business participant B application can send data to the business participant A device, but this is not reflected in the Figure 1 middle.

[0073] 3 Functional model for data transfer management

[0074] The functional model for the data transfer management service is organized into functional entities to describe a functional architecture that relates to support for data transfer management for vertical applications. It should be noted that these functional entities can be implemented in a suitable physical architecture. For example, each functional entity can be implemented on a corresponding device or network node (e.g., via execution of corresponding software executed by a processor of the corresponding device or network node).

[0075] Figure 2 The network functional model for data delivery management services with corresponding functional entities and reference points is shown. The figure follows the main approach used in the 3GPP SEAL standard (see 3GPP TS23.434). The Service Enablement Architecture Layer (SEAL) allows 5G capabilities to be used for applications from the same or different vertical sectors. The SEAL architecture also considers 5G capabilities to support mission-critical applications.

[0076] Figure 2 An example of a use case is shown, where data is transferred from a business actor A device to an application belonging to business actor B. However, data can also be transferred from a business actor B application to a business actor A device, but this scenario is not reflected in Figure 2 middle.

[0077] The SEAL Data Delivery (SEALDD) server creates connections with devices and applications by interacting with the 3GPP system (Network Exposure Function - NEF) via the N33 interface. In addition, the SEALDD server can send notifications to devices and applications, but this is optional. The regulator can request Data Delivery (DD) policy creation and deletion. After the policy is created, application communication via SEALDD is established. During application communication, the DD policy is enforced by the SEALDD server (regulator).

[0078] More specifically, if Figure 2As shown, the system 200 represented by the architecture includes the following components:

[0079] In the domain 202 of business participant A (i.e., “Participant A domain 202”):

[0080] o A device shown as a user equipment (UE), denoted herein as VAL-UE 204, comprising:

[0081] ■ VAL client 206, and

[0082] ■ SEALDD client 208, and

[0083] ○VAL server, denoted herein as VAL-A server 210.

[0084] In the domain 212 of the regulator (ie, "regulatory domain 212"):

[0085] o The supervisor's VAL server 214, referred to as "VAL-R server 214", and

[0086] ○SEALDD server 216.

[0087] In business participant B's domain 218 (ie, "Participant B domain 218"):

[0088] o VAL server 220, denoted herein as "VAL-B server 220".

[0089] · 3GPP network system 222 (also generally referred to as a telecommunication system) (eg, a 5G network also referred to herein as a 5G system).

[0090] 3.1 Functional Entity Description

[0091] 3.1.1 SEALDD Client

[0092] The SEALDD client (i.e., SEALDD client 208) is a functional entity that provides client-side functions corresponding to the data transfer management service and belongs to a business participant. The SEALDD client is deployed on the devices and servers of the business participant. The SEALDD client interacts with the SEALDD server (i.e., SEALDD server 216). The SEALDD client also supports interaction with the corresponding SEALDD client between two UEs. In an example embodiment, the SEALDD client is implemented as software stored and executed by a processor of a corresponding device (e.g., VAL-UE 204), which belongs to a corresponding business participant (e.g., Figure 2business participant A in the example of ) or otherwise with a corresponding business participant (e.g., Figure 2 In the example, business participant A) is associated.

[0093] 3.1.2 SEALDD Server

[0094] The SEALDD server (i.e., SEALDD server 216) is a functional entity that provides server-side functions corresponding to data transmission management services and belongs to the supervisor. This entity is deployed on the supervisor's server. The function of the SEALDD server is to implement the policy defined by the VAL server. In an example embodiment, the SEALDD server is implemented as software stored and executed by a processor of a corresponding server computer owned by the supervisor or otherwise associated with the supervisor.

[0095] 3.1.3VAL Client

[0096] The VAL client (i.e., VAL client 206) is a functional entity that provides client-side functionality corresponding to a business participant or regulator application. The VAL client participates in the definition of policies together with the VAL clients and servers of the regulator and business participants. In an example embodiment, the VAL client is implemented, for example, by a corresponding business participant (e.g., Figure 2 ) owned by or otherwise associated with a corresponding business participant (e.g., Figure 2 Software stored and executed by a processor of a corresponding device (e.g., VAL-UE) associated with a business participant A in the example.

[0097] 3.1.4VAL-A Server

[0098] The VAL-A server (i.e., VAL-A server 210) is a functional entity that provides server-side functions corresponding to business participant applications (in this example, corresponding to participant A). The VAL-A server participates in the definition of policies together with the regulator and business participant's VAL clients and servers. In an example embodiment, the VAL-A server is implemented, for example, by the corresponding business participant (e.g., Figure 2 ) owned by or otherwise associated with a corresponding business participant (e.g., Figure 2 In the example of business participant A), the processor of the corresponding server computer associated with the business participant A stores and executes the software.

[0099] 3.1.4VAL-B Server

[0100] The VAL-B server (i.e., VAL-B server 220) is a functional entity that provides server-side functions corresponding to business participant applications (in this example, corresponding to participant B). The VAL-B server participates in the definition of policies together with the regulator and business participant's VAL clients and servers. In an example embodiment, the VAL-B server is implemented, for example, by the corresponding business participant (e.g., Figure 2 ) owned by or otherwise associated with a corresponding business participant (e.g., Figure 2 In the example of business participant B), the software is stored and executed by a processor of a corresponding server computer associated with the business participant.

[0101] 3.1.5 VAL-R Server

[0102] The VAL-R server (i.e., VAL-R server 214) is a functional entity that provides server-side functions corresponding to the regulator application. The VAL-R server participates in the definition of policies together with the VAL clients and servers of the business participants. In an example embodiment, the VAL-R server is implemented as software stored and executed by a processor of a corresponding server computer owned by or otherwise associated with the regulator.

[0103] 3.2 Reference point description

[0104] The reference points of the functional model for data transfer management are described in the following subclauses.

[0105] 3.2.1N33

[0106] Reference point N33 supports interaction between the SEALDD server 216 and the network open function (NEF) in the 3GPP network system 222 and is specified in 3GPP "TS23.501, Technical Specification Group Services and SystemAspects, System Architecture for the 5G System(5GS), Stage 2.Release 17, 2022". The SEALDD server 216 interacts with the NEF via N33 to obtain quality of service (QoS) information from the 3GPP network system 222 and request to establish DD communication. N33 is used for network-based network slice remapping mechanism.

[0107] 3.2.2N6

[0108] The N6 interface provides a connection between a user plane function (UPF) in the 3GPP network system 222 and a data network (eg, the Internet).

[0109] 3.2.3SEALDD-C

[0110] The SEALDD-C reference point supports the use of the service participant UE (i.e., Figure 2 2 and 3. In the example of FIG. 2 , interactions between the VAL client 206 within the VAL-UE 204 and the SEALDD client 208 related to data transfer management functions.

[0111] 3.2.4SEALDD-S

[0112] The SEALDD-S reference point supports communication between business participants and regulator VAL servers (i.e. Figure 2 The VAL-R server 214 in the example of Figure 2 216) between the SEALDD server 216 in the example of FIG. 217 and the data transfer management function. It should be noted that the SEALDD is located on one side and the VAL server is located on the other side.

[0113] 3.2.5 SEALDD-UU

[0114] The SEALDD-UU reference point supports the use of the SEALDD client side (i.e. Figure 2 The SEALDD client 208 in the example of FIG. 200 and the data transfer management (SEALDD) server (ie, Figure 2 The reference point utilizes the Uu reference point as described in 3GPP TS 23.501.

[0115] 4. Processes and information flows for new services

[0116] 4.1 Overview

[0117] Assumptions for the new service process:

[0118] - In this document, the communication between VAL servers is not shown.

[0119] - A SEALDD client is authorized and authenticated by a SEALDD server belonging to a different business actor (ie, a different VAL system).

[0120] - The user authentication and authorization process is described in 3GPP TS 33.434 clause 5.4.

[0121] - Business participant B (VAL-B server) can trigger the same processes as business participant A, but these processes are not shown here.

[0122] - Devices belonging to business participant A will be able to send data to applications deployed on servers belonging to business participant B.

[0123] -The supervisor only forwards the data received from one participant to another. It does not store the data.

[0124] -Devices and apps that exchange data are not subject to the regulator.

[0125] - The VAL-R server has a data delivery (DD) policy available. The policy can be based on offline or online negotiation with the VAL-A client side administrator and the VAL-B server side administrator.

[0126] The following procedures are described in the following subsections:

[0127] -Data Delivery (DD) strategy creation

[0128] -Data Transfer (DD) communication establishment

[0129] -Data Delivery (DD) policy information query

[0130] ○Requests from business participants

[0131] ○Request from the Supervisor

[0132] -Data transfer (DD) communication information query

[0133] ○Requests from business participants

[0134] ○Request from the Supervisor

[0135] -Data Delivery (DD) strategy update

[0136] -Data Delivery (DD) communication updates

[0137] -Data Delivery (DD) Policy Deletion

[0138] -Data Transfer (DD) communication deletion

[0139] ○Requests from business participants

[0140] ○Request from the Supervisor

[0141] It should be noted that the description herein focuses on embodiments related to data transmission from a device to an application. A similar process is also effective for data transmission from an application to a device.

[0142] 4.2 Data Delivery (DD) Strategy Creation

[0143] 4.2.1 Overview

[0144] Business participants and regulators can request Data Delivery (DD) policy creation.

[0145] A business participant requests a policy creation from the regulator for a communication with another business participant, which provides information about the participant's users / UEs and the communication time schedule. The regulator checks whether it is allowed to fulfill the request, such as checking contracts, service level agreements (SLAs), communication schedules, etc., and requests approval from other business participants. Finally, the regulator creates a new policy and notifies the business participant of the new policy creation.

[0146] The regulator creates a policy with information about the participant users / UEs that will participate in the communication and the communication time schedule, and notifies the business participants of the new policy creation. The regulator can request approval from the business participants to establish a new policy.

[0147] Figure 3 An embodiment of DD policy creation according to one embodiment is shown. The supervisor creates a policy with information about the participant users / UEs that will participate in the communication and the communication time schedule, and notifies the participants of the new policy creation.

[0148] exist Figure 3 In step 1, the VAL-R server 214 performs a policy check and determines that a policy is to be created (step 1). In other words, the VAL-R server 214 checks whether the same policy has been created before creating the policy. The VAL-R server 214 sends a DD policy creation request to the SEALDD server 216 (step 2). The request includes the policy (e.g., data transmission start and stop time, data transmission quality of service (QoS), sender identity (ID) (VAL user ID or UE ID) and receiver ID (VAL server ID), UE's spatial conditions) and the VAL service ID.

[0149] After receiving the request, SEALDD server 216 authorizes the request and creates a policy. Then, SEALDD server 216 responds to VAL-R server 214 (step 3).

[0150] It should be noted that the SEALDD server 216 will store the policy and use it during subsequent communication establishment and implementation.

[0151] It should be noted that the policy ID can be created by the SEALDD server 216 or the VAL-R server 214 .

[0152] After step 2, the VAL-R server 214 may notify the VAL-A client-side administrator and the VAL-B server-side administrator. Such communication may be performed via the VAL-UU reference point.

[0153] 4.3 Data Transfer (DD) Communication Establishment

[0154] The regulator requests the 3GPP system to establish DD communication between service participants based on the defined policy, and notifies the service participants of the new DD communication establishment. Figure 4 The process of establishing DD communication is shown.

[0155] Prerequisites:

[0156] During the policy creation or update process, the SEALDD server 216 has received and stored the policy from the VAL-R server 214 . Figure 4 The steps of the process are as follows:

[0157] -Step 1: When the data transmission time is about to start, the SEALDD server 216 implements a policy to trigger the DD connection establishment. If the UE's spatial conditions are provided, the SEALDD server 216 also ensures that the UE's location requirements are met when establishing the DD connection (for example, by using NEF services to monitor UE location or using SEAL location services to monitor UEs entering the area of ​​interest).

[0158] - Step 2: If there are special routing requirements for SEALDD user plane traffic (e.g., running on a specific slice and data network name - DNN), the SEALDD server 216 interacts with the 3GPP Core Network (CN) to provide service specific parameters through the NEF as described in 3GPP TS23.502 Sections 4.15.6.10 and 4.15.6.7.

[0159] - Step 3: The SEALDD server 216 creates a relationship between the policy and the communication ID.

[0160] - Step 4-5: SEALDD server 216 allocates an Internet Protocol (IP) address and port for sending and receiving packets through the SEALDD-S reference point, and then SEALDD server 216 sends a DD connection establishment notification containing the VAL service ID, IP address and port to VAL-B server 220. The VAL-B server confirms the notification.

[0161] - Step 6-7: SEALDD server 216 allocates an IP address and port for sending and receiving packets via SEALDD-UU reference point, then SEALDD server 216 sends a DD connection establishment notification including VAL service ID, IP address and port to SEALDD client 208. SEALDD client 208 acknowledges the notification.

[0162] The SEALDD client 208 also notifies the VAL-A client 206 that a DD connection is being established.

[0163] After receiving the application service from VAL-A client 206, SEALDD client 208 sends the application service in a SEALDD service to SEALDD server 216. SEALDD server 216 identifies the application service based on the VAL service ID and further sends the application service to VAL-B server 220.

[0164] Figure 5 The process of establishing a DD connection according to one embodiment is shown.

[0165] Prerequisites:

[0166] - The SEALDD server 216 (supervisor) has the DD policy received from the VAL server 214 (supervisor).

[0167] - VAL server 220 (provider B) and SEALDD client 208 have subscribed to the SEALDD server 216

[0168] (Regulator) Receive notification.

[0169] Figure 5 The steps of the process are as follows:

[0170] - Step 1: When the data transmission time is about to start, the SEALDD server 216 (supervisor) implements a policy to trigger the DD connection establishment. If the UE's spatial conditions are provided, the SEALDD server 216 (supervisor) also ensures that the UE's location requirements are met when the DD connection is established (for example, by using NEF services to monitor UE location or using SEAL location services to monitor UEs entering the area of ​​interest).

[0171] - Step 2: If there are special routing requirements for SEALDD user plane traffic (e.g., running on specific slices and DNNs), the SEALDD server (regulator) interacts with the 3GPP CN to provide service specific parameters through the NEF as described in 3GPP TS23.502 clauses 4.15.6.10 and 4.15.6.7.

[0172] - Step 3-4: SEALDD server 216 allocates an IP address and port for sending and receiving packets through the SEAL-S reference point, and then SEALDD server 216 sends a DD connection establishment notification to VAL server 220 (provider B), which contains the VAL service ID, IP address and port. VAL server 220 (provider B) confirms the notification.

[0173] - Steps 5-6: The SEALDD server 216 allocates an IP address and port for sending and receiving packets over the SEAL Uu reference point, and then the SEALDD server 216 sends a DD connection establishment notification containing the VAL service ID, IP address and port to the SEALDD client 208. The SEALDD client 208 confirms the notification. If a different UE IP address is to be used in the DD connection user plane, the UE IP address (and port) can be included by the SEALDD client 208 in the notification confirmation, or sent by the SEALDD client 208 in a separate update message.

[0174] - Note that steps 3 and 5 can be completed in parallel.

[0175] - Step 7: The SEALDD client 208 also informs the VAL client 206 (Provider A) that the DD connection is being established.

[0176] -After receiving the application service from the VAL client 206 (not shown in the figure), the SEALDD client 208 sends the application service to the SEALDD server 216 (supervisor) in the SEALDD service. The SEALDD server 216 (supervisor) identifies the application service based on the VAL service ID and further sends the application service to the VAL server 220 (provider B). The downlink application service sent from the VAL server 220 to the VAL client 206 is similarly processed.

[0177] 4.4 Data Delivery (DD) Policy Information Query

[0178] 4.4.1 Overview

[0179] Business participants or regulators can query DD policy information.

[0180] The service participant requests information from the regulator regarding the DD policy involving the participant's users / UEs.

[0181] The regulator requests information about the DD policies involving the participant users / UEs.

[0182] 4.4.2 Requests from Business Participants

[0183] Figure 6 The process for querying DD policy information triggered by a business participant is shown.

[0184] Prerequisites:

[0185] -Business participants want to check whether the policy is applied correctly. After that, business participants can take follow-up actions,

[0186] For example, requesting a policy update, or deleting or creating a new policy, or implementing a communication deletion.

[0187] Figure 6 The steps of the process are as follows:

[0188] - Step 1: VAL-B server 220 sends a policy information request to SEALDD server 216. VAL-B server 220 can request specific policy information by query type (such as data transfer time window). During policy creation, the policy ID specified in the request has been received in advance from VAL-R server 214.

[0189] - It should be noted that the policy information request can also be sent by the VAL-A server 210.

[0190] - Step 2: The SEALDD server 216 provides the requested policy information via a Policy Information Response message.

[0191] It should be noted that although Figure 6 The example embodiment shows the request in step 1 coming from VAL-B server 220 , but the request may also come from VAL-A server 210 .

[0192] 4.4.3 Requests from regulators

[0193] Figure 7 A process for querying DD policy information triggered by a supervisor is shown.

[0194] Prerequisites:

[0195] - The supervisor wishes to check whether the policy has been applied correctly. Afterwards, the supervisor can take follow-up actions, for example, request a policy update, or delete or create a new policy, or implement a communication deletion.

[0196] Figure 7 The steps of the process are as follows:

[0197] - Step 1: The VAL-R server 214 sends a policy information request to the SEALDD server 216. The VAL-R server 214 may request specific policy information by query type (eg, data transfer time window).

[0198] - Step 2: The SEALDD server 216 provides the requested policy information via a Policy Information Response message.

[0199] 4.5 Data Transfer (DD) Communication Information Query

[0200] 4.5.1 Overview

[0201] Business participants and regulators can query DD communication information.

[0202] A service participant requests information from the supervisor about established communications involving the participant's users / UEs.

[0203] The supervisor requests information about established communications involving participant users / UEs.

[0204] 4.5.2 Requests from Business Participants

[0205] Figure 8 The process for querying DD communication information triggered by a service participant is shown.

[0206] Prerequisites:

[0207] -Business actors want to monitor communication performance, such as latency or reliability, and compliance with agreed-upon service level agreements (SLAs).

[0208] Figure 8 The steps of the process are as follows:

[0209] - Step 1: VAL-B server 220 sends a communication information request to SEALDD server 216. VAL-B server 220 may request specific communication information by query type (e.g., data on communication delay performance). During communication establishment, the communication ID specified in the request has been received in advance from SEALDD server 216.

[0210] -It should be noted that the communication information request can also be sent by the VAL-A server 210.

[0211] - Step 2: The SEALDD server 216 provides the requested communication information via a communication information response message.

[0212] 4.5.3 Requests from regulators

[0213] Fig. 9 A process for querying DD communication information triggered by a supervisor is shown.

[0214] Prerequisites:

[0215] - Regulators want to monitor communication performance, such as latency or reliability, and compliance with agreed SLAs.

[0216] Fig. 9 The steps of the process are as follows:

[0217] - Step 1: VAL-R server 214 sends a communication information query request to SEALDD server 216. VAL-R server 214 can request specific communication information by query type (such as data on communication delay performance). During the establishment of communication, the communication ID specified in the request has been received in advance from SEALDD server 216.

[0218] - Step 2: The SEALDD server 216 provides the requested communication information via a communication information response message.

[0219] 4.6 Data Delivery (DD) Strategy Update

[0220] 4.6.1 Overview The regulator updates the policy and notifies business participants of the policy updates.

[0221] Prerequisites:

[0222] - The regulator and participants have agreed on policy updates either in an offline manner or through communication between VAL servers. This is outside the scope of this study.

[0223] Fig.10 The steps of the DD policy update process are as follows:

[0224] - Step 1: VAL-R server 214 sends a DD policy update request to SEALDD server 216. The policy update request conveys policy information (e.g., data transfer duration and time, QoS, sender and receiver of data, etc.) and the operation to be performed (policy information to be added, deleted or modified).

[0225] - Step 2: After receiving the request, the SEALDD server 216 authorizes the request and creates a policy. Then, the SEALDD server 216 responds to the VAL-R server 214.

[0226] - Note that the policy ID can be created by the SEALDD server 216 or the VAL server 214 in the supervisor.

[0227] - After step 2, the VAL-R server 214 may notify the VAL-A client-side administrator and the VAL-B server-side administrator; however, such communication is outside the scope of the present disclosure.

[0228] 4.7 Data Delivery (DD) Communication Updates In certain situations (eg, QoS adjustments), the supervisor updates real-time communications.

[0229] Prerequisites:

[0230] -The SEALDD server pre-receives and stores policy updates during the policy update process.

[0231] Fig.11 The steps of the DD communication update process are as follows:

[0232] - Step 1: SEALDD server 216 implements communication establishment based on the updated policy that SEALDD server 216 has previously received and stored during the policy update process. During the policy update process, SEALDD server 216 has received the policy ID. SEALDD server 216 looks up the corresponding communication ID.

[0233] - Step 2: SEALDD server 216 and 3GPP system 222 apply QoS for data transmission (eg by utilizing NEF / PCF services for QoS adjustment). This is an existing 3GPP system function. QoS adjustment is an example of real-time communication.

[0234] - Step 3-4: SEALDD server 216 sends a DD connection establishment notification including VAL service ID, IP address and port to VAL-B server 220. VAL-B server 200 confirms the notification.

[0235] - Step 5-6: SEALDD server 216 sends DD connection establishment notification including VAL service ID, IP address and port to SEALDD client 208. SEALDD client 208 confirms the notification. SEALDD client 208 also notifies VAL-A client 206 of DD connection update.

[0236] 4.8 Data Delivery (DD) Policy Deletion

[0237] 4.8.1 Overview

[0238] The regulator requests the policy to be deleted and notifies the participants of the policy deletion.

[0239] Prerequisites:

[0240] - Policy deletion has been agreed upon between the regulator and the participants. This policy deletion agreement can be implemented in an offline manner or through communication between VAL servers. This is outside the scope of this article.

[0241] Fig.12 A procedure for deleting a DD policy is shown. Fig.12 The steps of the process are as follows:

[0242] - Step 1: The VAL-R server 214 sends a DD policy deletion request to the SEALDD server 216. The request includes the policy ID to be deleted.

[0243] - Step 2: After receiving the request, the SEALDD server 216 authorizes the request and deletes the policy indicated by the policy ID. Then, the SEALDD server 216 responds to the VAL-R server 214.

[0244] - After step 2, the VAL-R server 214 may notify the VAL-A client-side administrator and the VAL-B server-side administrator. Such communication is outside the scope of the present disclosure.

[0245] - The SEALDD server 216 will implement the communication deletion as described in the DD communication deletion procedure.

[0246] 4.9 Data Transfer (DD) Communication Deletion

[0247] 4.9.1 Overview

[0248] The Supervisor requests the DD communication deletion and notifies the Participant of the DD communication deletion.

[0249] Requests by regulators or participants for deletion of communications in emergency situations.

[0250] 4.9.2 Standard Request

[0251] Fig.13 The standard procedure for deleting DD communications is shown.

[0252] Prerequisites:

[0253] - One of the following conditions has been met: (i) SEALDD server 216 has received the policy deletion request, (ii)

[0254] The data transmission stop time is reached, or (iii) the UE is leaving the area of ​​interest (if the spatial condition of the UE is provided in the policy).

[0255] Fig.13 The steps of the process are as follows:

[0256] - Step 1: The SEALDD server 216 triggers the communication deletion. The SEALDD server 216 associates the received policy ID with the communication ID.

[0257] - Step 2: If the SEALDD connection is established, the SEALDD server 216 deletes the connection (ie, deletes the DD connection context).

[0258] - Step 3: If special routing requirements for SEALDD user plane services are provided to the 3GPP CN, ​​the SEALDD server 216 interacts with the 3GPP CN to delete service specific parameters such as 3GPP TS

[0259] 23.502, Section 4.15.6.7.

[0260] - Step 4: The SEALDD server 216 deletes the relationship between the policy and the communication ID.

[0261] - Step 5-6: SEALDD server 216 notifies the DD connection deletion to VAL-B server 220. VAL-B server 220 acknowledges the notification.

[0262] - Steps 7-8: SEALDD server 216 notifies SEALDD client 208 of the DD connection deletion. SEALDD client 208 acknowledges the notification. SEALDD client 208 also notifies VAL-A client 206 that the DD connection is being deleted.

[0263] 4.9.3 Emergency Request

[0264] Fig.14 Describes the emergency deletion process in situations where a business participant or regulator has identified that data transfer must be stopped urgently. Fig.15 Describes the standard policy removal process.

[0265] Fig.14 A procedure for deleting DD communications in an emergency situation is shown.

[0266] Prerequisites:

[0267] - A business participant or regulator has identified that data transfer must be urgently stopped. In the figure, business participant A has identified the need to stop data transfer of a device.

[0268] Fig.14 The steps of the process are as follows:

[0269] - Step 1: The VAL-A client 206 requests a communication deletion. The VAL-A client 206 sends a deletion request to the SEALDD client 208 and further to the SEALDD server 216.

[0270] - Step 2: If the SEALDD connection is established, the SEALDD server 216 deletes the connection (ie, deletes the DD connection context).

[0271] - Step 3: If special routing requirements for SEALDD user plane services are provided to the 3GPP CN, ​​the SEALDD server 216 interacts with the 3GPP CN to delete service specific parameters through the NEF, as described in 3GPP TS 23.502 No.

[0272] As described in Article 4.15.6.7.

[0273] - Step 4: The SEALDD server 216 deletes the relationship between the policy and the communication ID.

[0274] - Step 5: The SEALDD server 216 sends a communication deletion response to the VAL-A client 206 via the SEALDD client 208 .

[0275] - Step 6-7: SEALDD server 216 notifies the DD connection deletion to VAL-B server 220. VAL-B server 220 acknowledges the notification.

[0276] - Step 8: The SEALDD server 216 provides the policy ID to the VAL-R server 214.

[0277] - It should be noted that the VAL-R server 214 will implement policy deletion later.

[0278] Fig.15 A standard procedure for deleting DD communications according to another embodiment is shown.

[0279] Prerequisites:

[0280] - The VAL server 220 (Provider B) and the SEALDD client 208 have subscribed to receive notifications from the SEALDD server 216 (Supervisor).

[0281] Fig.15 The steps of the process are as follows:

[0282] - Step 1: The VAL server 214 (supervisor) sends a DD policy deletion request to the SEALDD server 216 (supervisor). The request includes the policy ID to be deleted.

[0283] - Step 2: After receiving the request, the SEALDD server 216 (supervisor) authorizes the request and deletes the policy indicated by the policy ID. The SEALDD server 216 (supervisor) then responds to the VAL server 214 (supervisor).

[0284] - Step 3: If a SEALDD connection is established, the SEALDD server 216 decides to delete the connection.

[0285] - Step 4-5: SEALDD server 216 (supervisor) notifies VAL server 220 (provider B) of DD connection deletion. VAL server 220 (provider B) confirms the notification. Application services are stopped on both sides.

[0286] Step 6-7: SEALDD server 216 (supervisor) notifies SEALDD client 208 of DD connection deletion. SEALDD client 208 confirms the notification. Application services are stopped on both sides.

[0287] - Note that steps 4 and 6 can be completed in parallel.

[0288] - Step 8: SEALDD client 208 also informs VAL client 206 (provider A) that the DD connection is being deleted. Application traffic stops on both sides.

[0289] - Step 9: If special routing requirements for SEALDD user plane traffic are provided to the 3GPP CN, ​​the SEALDD server 216 (regulator) interacts with the 3GPP CN to delete service specific parameters via the NEF, as described in 3GPP TS 23.502 clause 4.15.6.7.

[0290] - Step 10: The SEALDD server 216 deletes the DD connection (ie, deletes the DD connection context).

[0291] Data delivery policy enforcement

[0292] Except as Figure 4 or Figure 5 In addition to the DD connection establishment triggered by the DD policy described in, during data transfer, the SEALDD server 216 (supervisor) also implements the following policies:

[0293] - When the data transmission stop time is reached or the UE is leaving the area of ​​interest (if the spatial condition of the UE is provided in the policy)

[0294] , delete the SEALDD connection. Fig.15 Steps 3 to 10 are the same.

[0295] - if a failure detection request is provided in the DD policy, then notify the application service of the data delivery status; and / or

[0296] - Apply QoS for data transmission (e.g. by utilizing NEF / PCF / NRM services for QoS adjustment).

[0297] 6More Details

[0298] Fig.161900 is a schematic block diagram of a server computer 1900 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. For example, server computer 1900 can implement the functions of a VAL server or a SEALDD server according to any embodiment described herein. As shown in the figure, server computer 1900 includes one or more processors 1904 (e.g., a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), a memory 1906, and a network interface 1908. One or more processors 1904 are also referred to as processing circuits in this article. One or more processors 1904 are used to provide one or more functions of a VAL server or a SEALDD server as described herein. In some embodiments, the functions of a VAL server or a SEALDD server are implemented in software, which is stored in, for example, a memory 1906 and executed by one or more processors 1904.

[0299] Fig.17 1 is a schematic block diagram illustrating a virtualized embodiment of a server computer 1900 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. In addition, other types of network nodes may have similar virtualized architectures. Similarly, optional features are represented by dashed boxes.

[0300] As used herein, a "virtualized" server computer is an implementation of a server computer 1900 in which at least a portion of the server computer 1900 functionality is implemented as a virtual component (e.g., via a virtual machine executing on a physical processing node in a network). As shown, in this example, the server computer 1900 includes one or more processing nodes 2000 coupled to a network 2002 or included as part of the network 2002. Each processing node 2000 includes one or more processors 2004 (e.g., CPU, ASIC, FPGA, etc.), a memory 2006, and a network interface 2008. In this example, the functionality 2010 of the server computer 1900 described herein (e.g., the functionality of a VAL server or a SEALDD server) is implemented at one or more processing nodes 2000, or distributed between two or more processing nodes 2000 in any desired manner. In some specific embodiments, some or all of the functionality 2010 of the server computer 1900 described herein is implemented as a virtual component executed by one or more virtual machines implemented in a virtual environment hosted by the processing node 2000.

[0301] In some embodiments, a computer program comprising instructions is provided, which, when executed by at least one processor, causes at least one processor of a server computer or a virtual server computer to perform the functions of a VAL server or a SEALDD server according to any embodiment described herein. In some embodiments, a carrier comprising the above-mentioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transient computer-readable medium such as a memory).

[0302] Fig.18 2100 is a schematic block diagram of a UE 2100 according to some embodiments of the present disclosure. UE 2100 may be, for example, the above-mentioned VAL-UE. As shown in the figure, UE 2100 includes one or more processors 2102 (e.g., CPU, ASIC, FPGA, etc.), a memory 2104, and one or more transceivers 2106, each transceiver 2106 including one or more transmitters 2108 and one or more receivers 2110 coupled to one or more antennas 2112. Transceiver 2106 includes a radio front-end circuit connected to antenna 2112, which is configured to adjust the signal transmitted between antenna 2112 and processor 2102, as will be understood by those of ordinary skill in the art. Processor 2102 is also referred to herein as a processing circuit. Transceiver 2106 is also referred to herein as a radio circuit. In some embodiments, the functions of the above-mentioned UE 2100 (e.g., the functions of VAL-UE, etc.) may be implemented in whole or in part in software, which is, for example, stored in memory 2104 and executed by processor 2102. It should be noted that UE2100 may include other components not shown in Figure 21, such as one or more user interface components (for example, input / output interfaces including displays, buttons, touch screens, microphones, speakers, etc. and / or any other components for allowing information to be input to UE 2100 and / or allowing information to be output from UE 2100), power sources (for example, batteries and associated power circuits), etc.

[0303] In some embodiments, a computer program comprising instructions is provided, which, when executed by at least one processor, causes the at least one processor to perform the functions of the UE 2100 according to any embodiment described herein. In some embodiments, a carrier containing the above-mentioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium (e.g., a non-transitory computer-readable medium such as a memory).

[0304] Any suitable steps, methods, features, functions or benefits disclosed herein can be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include multiple such functional units. These functional units can be implemented via a processing circuit, which may include one or more microprocessors or microcontrollers, and other digital hardware, which may include a digital signal processor (DSP), dedicated digital logic, etc. The processing circuit may be configured to execute program codes stored in a memory, which may include one or more types of memory, such as a read-only memory (ROM), a random access memory (RAM), a cache memory, a flash memory device, an optical storage device, etc. The program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols, and instructions for executing one or more technologies described herein. In some implementations, the processing circuit is used to cause the corresponding functional unit to perform the corresponding functions according to one or more embodiments of the present disclosure.

[0305] Although the processes in the figures may show a particular order of operations performed by a particular embodiment of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform operations in a different order, combine particular operations, overlap particular operations, etc.).

[0306] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

[0307] The following are only a few examples and do not limit the claims.

[0308] Embodiment 1: A method executed by a system for transmitting SEAL data via a cellular communication system for a vertical industry oriented service enabling architecture layer, the method comprising:

[0309] At the vertical application layer VAL server of the regulatory domain of the system:

[0310] ° Determining a policy for data transfer between a client (SEAL DD client) in a first business participant domain of the system and a VAL server in a second business participant domain of the system; and

[0311] ° Provide the policy to the SEAL data delivery server in the regulatory domain of the system;

[0312] At the SEAL data transfer server for the system's supervisory domain:

[0313] ° Receive the policy from a VAL server of the system's regulatory domain; and

[0314] ° Implementing the policy for data transfer between the first service participant domain and the second service participant domain.

[0315] Embodiment 2: The method according to embodiment 1, wherein implementing the policy further comprises: at a SEAL data transfer server of the supervision domain:

[0316] determining that a data transfer DD communication / connection between a client in the first service participant domain and a VAL server in the second service participant domain should be established,

[0317] A DD connection / communication is established with a client in a first service participant domain and a DD connection / communication is established with a VAL server in a second service participant domain via a telecommunication system (eg, a 3GPP system).

Claims

1. A method performed by a system (200) for vertical industry-oriented service enabling architecture layer (SEAL) data transmission via a cellular communication system (222), the method comprising: At a vertical application layer VAL server (214) of a regulatory domain of the system (200): ° sending ( FIG. 3 , step 2) a request to a SEAL data transfer server (216) in the regulatory domain of the system (200), the request comprising a policy for connection establishment for data transfer from a VAL client (206) in a first business participant domain of the system (200) to a VAL server (220) in a second business participant domain of the system (200); At the SEAL data transfer server (216) of the regulatory domain of the system (200): ° receiving ( FIG. 3 , step 2) from the VAL server (214) of the regulatory domain of the system (200) the request including the policy for connection establishment for data transfer from the VAL client (206) in the first business participant domain of the system (200) to the VAL server (220) in the second business participant domain; ° authorize (Figure 3, step 2) the request; and °Storing (Figure 3, step 2) the strategy for implementation.

2. The method according to claim 1, wherein: The policy is pre-configured in the regulatory domain.

3. The method according to claim 1 or 2, further comprising: At the SEAL data transfer server (216) in the regulatory domain of the system (200): determining ( FIG. 4 , step 1 ) that the policy for connection establishment for data transfer is to be implemented; and According to the strategy: ° Sending ( FIG. 4 , step 6) a data transfer connection establishment notification to a SEAL data transfer client (208) in the first service participant domain of the system (200) communicating with the VAL client (206) in the first service participant domain of the system (200) via a cellular communication system (222) for establishing a first connection for data transfer; ° Sending (FIG. 4, step 4) a data transmission connection establishment notification to the VAL server (220) in the second service participant domain, so as to establish a second connection for data transmission; and ° Enabling data transfer between the VAL client (206) and the VAL server (220) via the SEAL data transfer client (208) over the first connection and the second connection.

4. The method according to any one of claims 1 to 3, further comprising: At the VAL server (214) in the regulatory domain: ° determining ( FIG. 10 , step 1) that the strategy for data transfer is to be updated, ° sending ( FIG. 10 , step 2) an update request to the SEAL data transfer server (216) in the regulatory domain of the system (200), the update request including an updated policy for connection establishment for data transfer from the VAL client (206) in the first business participant domain of the system (200) to the VAL server (220) in the second business participant domain of the system (200); At the SEAL data transfer server (216) in the regulatory domain: ° receiving ( FIG. 10 , step 2) said update request including said updated policy; ° Authorize ( FIG. 10 , step 2) the update request; as well as °Store ( FIG. 10 , step 2) the updated strategy for future implementation.

5. The method according to any one of claims 1 to 4, further comprising: At the SEAL data transfer server (216) of the regulatory domain: Determine (FIG. 15, step 3) to delete the second connection with the VAL server (220) in the second business participant domain and the first connection with the SEAL data transfer client (208) in the first business participant domain; Notifying (FIG. 15, step 4) the VAL server (220) in the second service participant domain that the second connection is to be deleted; as well as The SEAL data transfer client (208) is notified that the first connection is to be deleted.

6. A method performed by a SEAL data delivery server (216) of a regulatory domain of a system (200) for providing a service enabling architecture layer (SEAL) data delivery for vertical industries via a cellular communication system (222), the method comprising: receiving ( FIG. 3 , step 2) a request from a vertical application layer VAL server ( 214 ) of the regulatory domain of the system ( 200 ), the request comprising a policy for connection establishment for data transfer from a VAL client ( 206 ) in a first business participant domain of the system ( 200 ) to the VAL server ( 220 ) in a second business participant domain of the system ( 200 ); authorizing ( FIG. 3 , step 2) the request; and The strategy is stored (FIG. 3, step 2) for implementation.

7. The method according to claim 6, wherein: The policy is pre-configured in the regulatory domain.

8. The method according to claim 6 or 7, further comprising: Determining ( FIG. 4 , step 1 ) that the strategy for connection establishment for data transfer is to be implemented; as well as According to the strategy: ° Sending ( FIG. 4 , step 6) a data transfer connection establishment notification to a SEAL data transfer client (208) in the first service participant domain of the system (200) communicating with the VAL client (206) in the first service participant domain of the system (200) via a cellular communication system (222) for establishing a first connection for data transfer; ° Sending (FIG. 4, step 4) a data transmission connection establishment notification to the VAL server (220) in the second service participant domain, so as to establish a second connection for data transmission; and ° Enabling data transfer between the VAL client (206) and the VAL server (220) via the SEAL data transfer client (208) over the first connection and the second connection.

9. The method according to any one of claims 6 to 8, further comprising: receiving ( FIG. 10 , step 2) an update request from the VAL server (214) in the regulatory domain of the system (200), the update request comprising an updated policy for connection establishment for data transfer from the VAL client (206) in the first business participant domain of the system (200) to the VAL server (220) in the second business participant domain of the system (200); Authorizing ( FIG. 10 , step 2) the update request; as well as The updated policy is stored ( FIG. 10 , step 2 ) for later implementation.

10. The method according to any one of claims 6 to 9, further comprising: Determine (FIG. 15, step 3) to delete the second connection with the VAL server (220) in the second business participant domain and the first connection with the SEAL data transfer client (208) in the first business participant domain; Notifying (FIG. 15, step 4) the VAL server (220) in the second service participant domain that the second connection is to be deleted; as well as The SEAL data transfer client (208) is notified that the first connection is to be deleted.

11. A SEAL data delivery server (216) of a regulatory domain of a system (200) for providing a service enabling architecture layer SEAL data delivery for vertical industries via a cellular communication system (222), wherein the SEAL data delivery server (216) is adapted to: receiving ( FIG. 3 , step 2) a request from a vertical application layer VAL server ( 214 ) of the regulatory domain of the system ( 200 ), the request comprising a policy for connection establishment for data transfer from a VAL client ( 206 ) in a first business participant domain of the system ( 200 ) to the VAL server ( 220 ) in a second business participant domain of the system ( 200 ); authorizing ( FIG. 3 , step 2) the request; and The strategy is stored (FIG. 3, step 2) for implementation.

12. The SEAL data transfer server (216) of claim 11, wherein: The policy is pre-configured in the regulatory domain.

13. The SEAL data transmission server (216) according to claim 11 or 12, wherein: The SEAL data transfer server (216) is also adapted to: determining ( FIG. 4 , step 1 ) that the policy for connection establishment for data transfer is to be implemented; and According to the strategy: ° Sending ( FIG. 4 , step 6) a data transfer connection establishment notification to a SEAL data transfer client (208) in the first service participant domain of the system (200) communicating with the VAL client (206) in the first service participant domain of the system (200) via a cellular communication system (222) for establishing a first connection for data transfer; ° Sending (FIG. 4, step 4) a data transmission connection establishment notification to the VAL server (220) in the second service participant domain, so as to establish a second connection for data transmission; and ° Enabling data transfer between the VAL client (206) and the VAL server (220) via the SEAL data transfer client (208) over the first connection and the second connection.

14. The SEAL data transfer server (216) according to any one of claims 11 to 13, further adapted to: receiving ( FIG. 10 , step 2) an update request from the VAL server (214) in the regulatory domain of the system (200), the update request comprising an updated policy for connection establishment for data transfer from the VAL client (206) in the first business participant domain of the system (200) to the VAL server (220) in the second business participant domain of the system (200); Authorizing ( FIG. 10 , step 2) the update request; as well as The updated policy is stored ( FIG. 10 , step 2 ) for later implementation.

15. The SEAL data transfer server (216) according to any one of claims 11 to 14, further adapted to: Determine (FIG. 15, step 3) to delete the second connection with the VAL server (220) in the second business participant domain and the first connection with the SEAL data transfer client (208) in the first business participant domain; Notifying (FIG. 15, step 4) the VAL server (220) in the second service participant domain that the second connection is to be deleted; as well as The SEAL data transfer client (208) is notified that the first connection is to be deleted.

16. A server computer (1900) for implementing a SEAL data delivery server (216) of a regulatory domain of a system (200) for providing a service enabling architecture layer (SEAL) data delivery for vertical industries via a cellular communication system (222), the server computer (1900) comprising: Network Interface (1908); as well as A processing circuit (1904) associated with the network interface (1908), the processing circuit (1904) being configured to cause the server computer (1900) to perform the following operations to operate as the SEAL data delivery server (216): receiving ( FIG. 3 , step 2) a request from a vertical application layer VAL server ( 214 ) of the regulatory domain of the system ( 200 ), the request comprising a policy for connection establishment for data transfer from a VAL client ( 206 ) in a first business participant domain of the system ( 200 ) to the VAL server ( 220 ) in a second business participant domain of the system ( 200 ); authorizing ( FIG. 3 , step 2) the request; and The strategy is stored (FIG. 3, step 2) for implementation.

17. The server computer (1900) according to claim 16, wherein: The policy is pre-configured in the regulatory domain.

18. The server computer (1900) according to claim 16 or 17, wherein: The processing circuit (1904) is further configured to cause the server computer (1900) to perform the following operations to operate as the SEAL data delivery server (216): determining ( FIG. 4 , step 1 ) that the policy for connection establishment for data transfer is to be implemented; and According to the strategy: ° Sending ( FIG. 4 , step 6) a data transfer connection establishment notification to a SEAL data transfer client (208) in the first service participant domain of the system (200) communicating with the VAL client (206) in the first service participant domain of the system (200) via a cellular communication system (222) for establishing a first connection for data transfer; ° Sending (FIG. 4, step 4) a data transmission connection establishment notification to the VAL server (220) in the second service participant domain, so as to establish a second connection for data transmission; and ° Enabling data transfer between the VAL client (206) and the VAL server (220) via the SEAL data transfer client (208) over the first connection and the second connection.

19. The server computer (1900) according to any one of claims 16 to 18, wherein: The processing circuit (1904) is further configured to cause the server computer (1900) to perform the following operations to operate as the SEAL data delivery server (216): receiving ( FIG. 10 , step 2) an update request from the VAL server (214) in the regulatory domain of the system (200), the update request comprising an updated policy for connection establishment for data transfer from the VAL client (206) in the first business participant domain of the system (200) to the VAL server (220) in the second business participant domain of the system (200); Authorizing ( FIG. 10 , step 2) the update request; as well as The updated policy is stored ( FIG. 10 , step 2 ) for later implementation.

20. The server computer (1900) according to any one of claims 16 to 19, wherein: The processing circuit (1904) is further configured to cause the server computer (1900) to perform the following operations to operate as the SEAL data delivery server (216): Determine (FIG. 15, step 3) to delete the second connection with the VAL server (220) in the second business participant domain and the first connection with the SEAL data transfer client (208) in the first business participant domain; Notifying (FIG. 15, step 4) the VAL server (220) in the second service participant domain that the second connection is to be deleted; as well as The SEAL data transfer client (208) is notified that the first connection is to be deleted.

21. A computer program comprising instructions which, when executed on at least one processor, cause the processor to perform the method according to any one of claims 6 to 10.

22. A carrier comprising a computer program according to claim 21, wherein: The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

23. A non-transitory computer readable medium comprising instructions executable by a processing circuit of a server computer, whereby the server computer, in order to operate as a SEAL data delivery server (216) of a regulatory domain of a system (200) for providing a vertical industry oriented service enabling architecture layer (SEAL) data delivery via a cellular communication system (222), is operable to: receiving ( FIG. 3 , step 2) a request from a vertical application layer VAL server ( 214 ) of the regulatory domain of the system ( 200 ), the request comprising a policy for connection establishment for data transfer from a VAL client ( 206 ) in a first business participant domain of the system ( 200 ) to the VAL server ( 220 ) in a second business participant domain of the system ( 200 ); authorizing ( FIG. 3 , step 2) the request; and The strategy is stored (FIG. 3, step 2) for implementation.

Images