Method and apparatus for service processing

Abstract

Embodiments of the present disclosure provide methods and apparatuses for service handling. A method performed by a first application function entity can comprise receiving, from a second application function entity, a first message comprising first protocol description information for transmitting a data service using a transport protocol. The first protocol description information comprises uplink protocol description information and / or downlink protocol description information. The data service can be for a multi-modal service. The first protocol description information can comprise information indicating a protocol data unit, PDU, set marker.

Description

Technical Field

[0001] The non-limiting and exemplary embodiments of this disclosure generally relate to the field of communication technology, and more particularly to methods and apparatus for service processing. Background Technology

[0002] This section introduces several aspects that can help in a better understanding of this disclosure. Therefore, the statements in this section should be read in this light and should not be construed as an admission of what is in or not in the prior art.

[0003] In communication networks such as fifth-generation systems (5GS) as defined by the 3rd Generation Partnership Project (3GPP), support for various services may be required. For example, support for multimodal services may be required in the Service Enablement Architecture Layer (SEAL) for vertical industries.

[0004] Since 3GPP Release 16, SEAL has been introduced to support vertical applications, such as Vehicle-to-Everything (V2X) applications. 3GPP Technical Specification (TS) 23.434 V19.0.0 (the entire contents of which are incorporated herein by reference) specifies the application plane and signaling plane entities for application enabling services (such as group management, configuration management, location management, identity / key management, and network resource management) that can be reused across vertical applications. SEAL also specifies northbound application programming interfaces (APIs) for its various services to enable flexible integration with vertical applications.

[0005] Multimodal services can include several data streams (called multimodal streams) that are interconnected and may originate from different sources. Each data stream (monomodal data) can be considered as a type of data (e.g., audio, video, location, haptic data) associated with the same communication service. Data streams that include multimodal services can originate from a single user equipment (UE) (a single device or multiple devices connected via a single UE that can access 5GS), or from multiple UEs. Summary of the Invention

[0006] The present invention is provided in a simplified form to introduce a chosen concept, which is further described in the following detailed description. This summary is neither intended to identify key or essential features of the claimed subject matter nor to limit the scope of the claimed subject matter.

[0007] In the latest 3GPP Release 19 Extended Reality (XR) study (e.g., 3GPP TR 23.700-23 v0.1.0, Clause 4.2), S6-234107 "KI for E2E Multimodal Communication Streams," from the 58th meeting of 3GPP TSG-SA WG6, mentions further gaps in ensuring the quality of XR service transmission. The published list of issues identifies the following aspects:

[0008] Does it support end-to-end (E2E) multimodal communication between application clients and application servers within the application enablement layer?

[0009] Does it support the interaction between the application enablement layer and the fifth-generation (5G) core network (CN) to manage E2E multimodal communication flows between application clients and application servers?

[0010] Is it possible and how can we enhance the business enablement architecture layer data delivery (SEALDD) for vertical industries to assist in managing E2E multimodal communication flows between application clients and application servers involved in the same application service (e.g., supporting multimodal-aware SEALDD flow management and policies)?

[0011] Since 3GPP version 18, SEALDD has been specified. Figure 2b The document describes the user plane protocol stack on 5GS. Application content, including SEALDD layer information and Vertical Application Layer (VAL) payloads, is transmitted between the SEALDD client in the UE and the SEALDD server in the data network.

[0012] The Protocol Data Unit (PDU) layer corresponds to the PDUs carried between the UE and the data network (DN) through a PDU session. Examples include User Datagram Protocol (UDP) / Internet Protocol (IP), Transmission Control Protocol (TCP) / IP, and Fast UDP Internet Connection (QUIC) / UDP / IP.

[0013] For downlink (DL) data, without using SEALDD, after the Application Function (AF) notifies the network, such as the 5G Core Network (5GC), of the required Quality of Service (QoS) protocol description via a process for establishing the AF, the User Plane Function (UPF) can mark PDU set information in the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) based on the received protocol extensions (e.g., Real-time Protocol (RTP)). Then, during access network (AN) congestion, the 5G Radio Access Network (RAN) and / or the UPF will perform specific packet processing (e.g., drop, retransmission) on the PDUs in the PDU set and also on the PDU sets in the same Service Data Stream (SDF) based on the PDU set information in the GTP.

[0014] When SEALDD is used, the user plane (such as the UPF or the access network protocol layer entity of the terminal device) is unaware of the existence of SEALDD. Therefore, the user plane cannot correctly perform packet inspection and classification. The user plane cannot tag PDU set information.

[0015] To overcome or mitigate at least one of the above-mentioned or other problems, embodiments of this disclosure propose a solution for service processing.

[0016] In a first aspect of this disclosure, a method performed by a first application function entity is provided. The method may include receiving a first message from a second application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information may include uplink protocol description information and / or downlink protocol description information. The data service may be used for multimodal services. The first protocol description information may include information indicating PDU set markings.

[0017] In a second aspect of this disclosure, a method performed by a second application function entity is provided. The method may include sending a first message to a first application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information may include uplink protocol description information and / or downlink protocol description information. The data service may be used for multimodal services. The first protocol description information may include information indicating PDU set markings.

[0018] In a third aspect of this disclosure, a first application function entity is provided. The first application function entity may include a processor and a memory coupled to the processor. The memory contains instructions executable by the processor. The first application function entity is operable to receive a first message from a second application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information may include uplink protocol description information and / or downlink protocol description information. The data service may be used for multimodal services. The first protocol description information may include information indicating PDU set markings.

[0019] In a fourth aspect of this disclosure, a second application function entity is provided. The second application function entity includes a processor and a memory coupled to the processor. The memory contains instructions executable by the processor. The second application function entity is operable to send a first message to a first application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information may include uplink protocol description information and / or downlink protocol description information. The data service may be used for multimodal services. The first protocol description information may include information indicating PDU set markings.

[0020] In a fifth aspect of this disclosure, a computer program product including instructions is provided, which, when executed by at least one processor, cause the at least one processor to perform a method according to either the first or second aspect.

[0021] In a sixth aspect of this disclosure, a computer-readable storage medium is provided that stores instructions which, when executed by at least one processor, cause the at least one processor to perform a method according to either the first or second aspect.

[0022] The embodiments described herein can provide numerous advantages, and the following is a non-exhaustive list of examples of these advantages. In some embodiments described herein, it can reduce the complexity of second application function entities such as VAL clients and VAL servers. For example, the second application function entity can only transmit raw media data, such as H.264, to a first application function entity such as a SEALDD server or SEALDD client, and the first application function entity will handle the rest, such as packetization, PDU set marking, or RTCP and RTSP data control. In some embodiments described herein, it can enable a first application function entity such as a SEALDD server to derive auxiliary information related to PDU sets when interacting with the 3GPP core network. In some embodiments described herein, it can enable a first application function entity (e.g., a SEALDD server or SEALDD client) to handle packetization, PDU set marking (e.g., in RTP extensions), and RTCP and RTSP control, thereby reducing the load on the second application function entity (e.g., a VAL client and VAL server). In some embodiments herein, it can address the following problem: how to notify the access network protocol layer entities of user plane functions and / or terminal devices when using the SEALDD application layer: information indicating the use of tunneling protocols and tunneling protocol information in the transmission of packetized data services. In some embodiments herein, it can ensure that the access network protocol layer entities of user plane functions and / or terminal devices can correctly process tunneling protocol data. In some embodiments herein, it can protect streaming content, for example, if the VAL service provider and the SEALDD service provider are not from the same organization. The embodiments herein are not limited to the features and advantages described above. Additional features and advantages will be recognized by those skilled in the art upon reading the following detailed description.

[0023] For any aspect of this disclosure, in prior art such as 3GPP TS 23.433 V19.0.0, protocol description information is not transmitted between VAL clients and SEALDD clients, or between VAL servers and SEALDD servers. Therefore, prior art such as 3GPP TS 23.433 V19.0.0 cannot support E2E multimodal communication flows between application clients and application servers within the application enablement layer. Since protocol description information can be transmitted between VAL clients and SEALDD clients, and between VAL servers and SEALDD servers, this embodiment can support E2E multimodal communication flows between application clients and application servers within the application enablement layer.

[0024] For any aspect of this disclosure, in the prior art such as 3GPP TS 23.433 V19.0.0, the information indicating the PDU set tag is not transmitted between the VAL client and the SEALDD client, or between the VAL server and the SEALDD server. Therefore, the prior art such as 3GPP TS 23.433 V19.0.0 cannot support PDU set tagging in the SEALDD server and the SEALDD client. Since the PDU set tag can be transmitted between the VAL client and the SEALDD client, and between the VAL server and the SEALDD server, this embodiment can support PDU set tagging in the SEALDD server and the SEALDD client.

[0025] In one embodiment, the method further includes receiving data traffic from a second application function entity. The method further includes performing packetization on the data traffic. The method further includes performing PDU set marking based on information indicating PDU set marking, to include PDU set information in the packetized data traffic.

[0026] In this embodiment, packetization can be performed by both the SEALDD client and the SEALDD server, which reduces the complexity for both the VAL client and the VAL server. For example, the VAL client and VAL server can transmit only the raw media data, such as H.264, to the SEALDD server or SEALDD client, while the SEALDD server or SEALDD client handles the rest, such as packetization, PDU set tagging, or Real-time Transmission Control Protocol (RTCP) and Real-time Streaming Protocol (RTSP) data control, which reduces the load on the VAL client and VAL server.

[0027] In an embodiment, the method further includes deriving at least one PDU set QoS parameter from the identifier of the service and / or the identifier of the application functional entity providing the service.

[0028] In this embodiment, it enables the first application function entity (e.g., the SEALDD server) to export PDU set QoS parameters when interacting with the 3GPP core network.

[0029] In an embodiment, the second protocol description information includes at least one of the following: information indicating the use of the tunneling protocol in the transmission of the packetized data service, the header length of the tunneling protocol, the offset of the payload of the tunneling protocol, the location of the PDU set information, or offset position information in the header of the tunneling protocol.

[0030] In this embodiment, the information indicating the use of a tunneling protocol in the transmission of the packetized data service can enable the access network protocol layer entity of the client plane function and / or terminal device to know that a tunneling protocol is used in the transmission of the packetized data service, and then it can correctly identify the packetized data service and continue to identify PDU set information.

[0031] In this embodiment, the header length of the tunneling protocol can be used by the client-side functions and / or the access network protocol layer entity of the terminal device to know the location of the packetized data service, and then it can correctly identify the packetized data service and continue to identify the PDU set information.

[0032] In this embodiment, the offset of the tunneling protocol payload and the offset position information in the tunneling protocol header can be used by the access network protocol layer entity of the client plane function and / or terminal device to know the location of the packetized data service, and then it can correctly identify the packetized data service and continue to identify PDU set information.

[0033] In this embodiment, the location of the PDU set information can be known by the client-side functions and / or the access network protocol layer entity of the terminal device, and then it can correctly identify the PDU set information.

[0034] In one embodiment, the method further includes sending the second protocol description information to at least one of a SEALDD client, a network open node, or a policy control node when the first application function entity is a SEALDD server.

[0035] In this embodiment, it can notify the access network protocol layer entity of the user plane function and / or terminal device of information and tunnel protocol information indicating the use of tunneling protocol in the transmission of the packetized data service. This enables the access network protocol layer entity of the user plane function and / or terminal device to correctly identify the packetized data service and continue to identify PDU set information.

[0036] In one embodiment, the method further includes sending the second protocol description information to at least one of a SEALDD server, a network open node, or a policy control node when the first application functional entity is a SEALDD client.

[0037] In this embodiment, it can notify the access network protocol layer entity of the user plane function and / or terminal device of information and tunnel protocol information indicating the use of tunneling protocol in the transmission of the packetized data service. This enables the access network protocol layer entity of the user plane function and / or terminal device to correctly identify the packetized data service and continue to identify PDU set information.

[0038] In one embodiment, the method further includes sending the second protocol description information to the access network protocol layer entity of the terminal device when the first application function entity is a SEALDD client.

[0039] In this embodiment, it can notify the access network protocol layer entity of the terminal device to indicate the use of tunneling protocol information and tunneling protocol information in the transmission of the packetized data service. This enables the access network protocol layer entity of the terminal device to correctly identify the packetized data service and continue to identify PDU set information.

[0040] In this embodiment, the data service is encrypted by the second application function entity and cannot be decrypted by the first application function entity.

[0041] In this embodiment, for example, if the VAL service provider and the SEALDD service provider are not from the same organization, it can protect the streaming content. Attached Figure Description

[0042] From the following detailed description with reference to the accompanying drawings, by way of example, the above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, in which similar reference numerals or letters are used to refer to similar or equivalent elements. The drawings are shown to facilitate a better understanding of embodiments of the present disclosure and are not necessarily drawn to scale, wherein:

[0043] Figure 1a The general intranet functional model of SEAL is illustrated schematically;

[0044] Figure 1b The architecture used for the SEALDD service is illustrated schematically.

[0045] Figure 2a The architecture used for application service transmission is illustrated schematically;

[0046] Figure 2b An example of a user plane protocol stack on a 5GS according to an embodiment of this disclosure is illustrated schematically;

[0047] Figure 2c An example of grouping in SEALDD according to an embodiment of this disclosure is illustrated schematically;

[0048] Figure 2d The high-level architecture in a 5G network according to an embodiment of the present disclosure is illustrated schematically;

[0049] Figure 3a , 3b3c, 3d, 3e, 3f, 3g, 3h, 3i, 4a, 4b, 4c, 4d, 4e and 4f illustrate flowcharts of a method according to an embodiment of the present disclosure;

[0050] Figure 5 A flowchart is shown illustrating the process for establishing a regular SEALDD data transmission connection;

[0051] Figure 6a A flowchart illustrating the connectivity policies implemented by the SEALDD server is shown.

[0052] Figure 6b A flowchart is shown for the process of establishing redundant transmission;

[0053] Figure 6c A flowchart is shown for the process of establishing redundant transports initiated by the client, which is used for data transfer in each application layer transaction;

[0054] Figure 6d A flowchart illustrating the strategy for redundant connectivity implemented by the SEALDD server is shown; and

[0055] Figure 7 This is a block diagram illustrating an apparatus suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0056] Embodiments of this disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled in the art to better understand and thus implement this disclosure, and not to suggest any limitation on the scope of this disclosure. References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable with this disclosure should be included in or in any single embodiment of this disclosure. Rather, references to features and advantages should be understood as meaning that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this disclosure. Furthermore, in one or more embodiments, the features, advantages, and characteristics described in this disclosure may be combined in any suitable manner. Those skilled in the art will recognize that this disclosure can be practiced without one or more particular features or advantages in a particular embodiment. In other instances, additional features and advantages may be recognized in some embodiments, and these additional features and advantages may not be present in all embodiments of this disclosure.

[0057] As used herein, the term "network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), LTE Advanced, Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), and other wireless networks. CDMA networks can implement radio technologies such as Universal Terrestrial Radio Access (UTRA). UTRA includes other variants of WCDMA and CDMA. TDMA networks can implement radio technologies such as Global System for Mobile Communications (GSM). OFDMA networks can implement radio technologies such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, Ad-hoc networks, wireless sensor networks, etc. In the following description, the terms "network" and "system" are used interchangeably. Furthermore, communication between two devices in a network can be performed according to any suitable communication protocol, including but not limited to those defined by standards organizations such as 3GPP. For example, communication protocols may include first-generation (1G), 2G, 3G, 4G, 4.5G, 5G, 6G communication protocols and / or any other currently known or future-developed protocols.

[0058] The terms "network device," "network node," or "network function" refer to any suitable function that can be implemented in a (physical or virtual) network entity within a communication network. For example, a network function can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, such as cloud infrastructure. For instance, a 5G system (5GS) can include multiple NFs, such as Access and Mobility Management Functions (AMFs), and others described later. Figure 2d Other NFs are shown. In other embodiments, network functions may include different types of NFs, for example, depending on the specific network.

[0059] Virtualization means creating virtual versions of devices or equipment, which may include virtualized hardware platforms, storage devices, and network resources. As used herein, virtualization can be applied to provider edge nodes and relates to an implementation in which at least a portion of functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines, or containers executed on one or more physical processing nodes in one or more networks).

[0060] In some embodiments, some or all of the functionality described herein may be implemented as virtual components executed by one or more virtual machines, which are implemented in one or more virtual environments hosted by one or more hardware nodes. Furthermore, in embodiments where the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node), the provider edge node or PE may be fully virtualized.

[0061] This functionality can be implemented by one or more applications (which may alternatively be referred to as software instances, virtual devices, network functions, virtual nodes, virtual network functions, etc.) operable to implement some of the features, functions, and / or benefits of some embodiments disclosed herein. The application runs in a virtualized environment that provides hardware including processing circuitry and memory. The memory contains instructions executable by the processing circuitry, thereby enabling the application to operate to provide one or more of the features, benefits, and / or functions disclosed herein.

[0062] The virtualization environment includes general-purpose or special-purpose network hardware devices, which include a collection of one or more processors or processing circuits. These can be commercial off-the-shelf (COTS) processors, application-specific integrated circuits (ASICs), or any other type of processing circuitry, including digital or analog hardware components or dedicated processors. Each hardware device may include memory, which can be non-persistent memory used for temporarily storing instructions or software executed by the processing circuitry. Each hardware device may include one or more network interface controllers (NICs), also known as network interface cards, which include physical network interfaces. Each hardware device may also include non-transient, persistent, machine-readable storage media—containing software and / or instructions executable by the processing circuitry stored therein. The software can include any type of software, including software for instantiating one or more virtualization layers (also known as hypervisors), software for executing virtual machines, and software that allows them to perform the functions, features, and / or benefits described in relation to some of the embodiments described herein.

[0063] Virtual machines include virtual processing, virtual memory, virtual networks or interfaces, and virtual storage, and can be run by a corresponding virtualization layer or hypervisor. Different embodiments of virtual device instances can be implemented on one or more virtual machines, and can be implemented in different ways.

[0064] During operation, the processing circuitry executes software to instantiate the hypervisor, or virtualization layer, sometimes referred to as the virtual machine monitor (VMM). The virtualization layer presents a virtual operating platform to the virtual machines that appears as network hardware.

[0065] The term "terminal device" refers to any terminal device that can access a communication network and receive services from it. By way of example and not limitation, a terminal device refers to a mobile terminal, user equipment (UE), or other suitable device. A UE can be, for example, a subscriber station (SS), a portable subscriber station, a mobile station (MS), or an access terminal (AT). Terminal devices can include, but are not limited to, portable computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablet computers, wearable devices, personal digital assistants (PDAs), portable computers, desktop computers, wearable terminal devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEE), laptop installed devices (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), etc. In the following description, the terms "terminal device," "terminal," "user equipment," and "UE" are used interchangeably. As an example, a terminal device may represent a UE configured to communicate according to one or more communication standards published by 3GPP (3rd Generation Partnership Project), such as 3GPP's LTE or NR standards. As used herein, a "User Equipment" or "UE" may not necessarily have a "user" in relation to a human user who owns and / or operates the associated device. In some embodiments, a terminal device may be configured to send and / or receive information without direct human interaction. For example, when triggered by an internal or external event, or in response to a request from a communication network, a terminal device may be designed to send information to the network according to a predetermined schedule. Alternatively, a UE may represent a device intended for sale to a human user or operated by a human user but which may not initially be associated with a particular human user.

[0066] As another example, in the Internet of Things (IoT) scenario, a terminal device can represent a machine or other device that performs monitoring and / or measurement, and transmits the results of such monitoring and / or measurement to another terminal device and / or network device. In this case, the terminal device can be a machine-to-machine (M2M) device, which in the 3GPP context can be referred to as a machine-type communication (MTC) device. As a specific example, a terminal device can be a UE that implements the 3GPP Narrowband Internet of Things (NB-IoT) standard. Specific examples of such machines or devices are sensors, metering devices (e.g., electricity meters), industrial machinery, or household or personal appliances such as refrigerators, televisions, personal wearable devices (e.g., watches), etc. In other scenarios, a terminal device can represent a vehicle or other device capable of monitoring and / or reporting its operating status or other functions related to its operation.

[0067] References to "an embodiment," "embodiment," "exemplary embodiment," etc., in the specification indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes that particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is claimed that, whether explicitly described or not, its influence on that feature, structure, or characteristic in conjunction with other embodiments is within the knowledge of those skilled in the art.

[0068] It should be understood that while the terms “first” and “second” may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed terms.

[0069] As used herein, unless otherwise expressly stated to the contrary, the phrase “at least one of A and B” or “at least one of A or B” shall be understood to mean any one of the following: “A only, B only, or both A and B”. The phrase “A and / or B” shall be understood to mean any one of the following: “A only, B only, or both A and B”.

[0070] As used herein, unless otherwise expressly stated to the contrary, the phrase “multiple” followed by a conjunctive list of enumerated items (e.g., “A and B”, “A, B and C”) is intended to mean “multiple items”, each of which is selected from the list of enumerated items. For example, “multiple A and B” means any of the following: more than one A; more than one B; or at least one A and at least one B.

[0071] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” as used herein are also intended to include the plural forms. It will be further understood that, when used herein, the terms “comprising,” “including,” “having,” “owning,” “containing,” and / or “covering” specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.

[0072] Note that the terms used in this article are for ease of description and to distinguish between nodes, devices, or networks, etc. As technology evolves, other terms with similar / identical meanings may also be used.

[0073] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0074] System architecture and protocol stack description

[0075] Although the subjects described herein can be implemented in any suitable type of system using any suitable components, the embodiments disclosed herein are related to conforming to... Figure 1a , 1b The communication system described uses the exemplary system architectures shown in 2a, 2c, and 2d. For simplicity, Figure 1a , 1b The system architectures in 2a, 2c, and 2d only depict some exemplary elements. In practice, a communication system may further include any additional elements suitable for supporting communication between terminal devices or between a wireless device and another communication device (such as a landline telephone, service provider, or any other network node or terminal device). The communication system may provide communication and various types of services to one or more terminal devices to facilitate their access to and / or use of services provided by or via the communication system.

[0076] Figure 1a The general intranet functional model of SEAL is schematically shown, which is the same as Figure 6.2-1 of 3GPP TS 23.434 V19.0.0.

[0077] Section 6.4.2 of 3GPP TS 23.434 V19.0.0 describes the application plane. Entities within the application plane of a VAL system provide application control and media-specific functions to support one or more VAL services. For example, entities within the application plane of a VAL system may include VAL clients, VAL servers, SEAL clients, SEAL servers, and VAL user databases, which are examples of "application function entities" in this disclosure.

[0078] The VAL client provides client-side functionality corresponding to vertical applications (such as V2X clients). The VAL client supports interaction with one or more SEAL clients.

[0079] The VAL server provides server-side functionality corresponding to vertical applications (such as V2X application servers). The VAL server acts as an API caller for the Common API Framework (CAPIF) for northbound APIs as specified in 3GPP TS 23.222 V19.0.0.

[0080] The SEAL client provides client-side functionality corresponding to a specific SEAL service. One or more SEAL clients support interaction with one or more VAL clients. The SEAL client also supports interaction between two UEs and their respective SEAL clients.

[0081] The SEAL server provides server-side functionality corresponding to a specific SEAL service. The SEAL server supports interaction with one or more VAL servers. The SEAL server can act as an API open function for CAPIF as specified in 3GPP TS 23.222 V19.0.0. The SEAL server can also support interaction with corresponding SEAL servers in a distributed SEAL deployment.

[0082] The reference point for the general functional model for SEAL is described in Clause 6.5 of 3GPP TS 23.434 V19.0.0.

[0083] Figure 1b The diagram schematically illustrates the architecture for SEAL Data Delivery (SEALDD) service, which is consistent with 3GPP TS23.433 V19.0.0. Figure 7 .2-3 are the same.

[0084] The functional entities used for SEALDD services are described in Clause 7.3 of 3GPP TS 23.433 V19.0.0.

[0085] The SEAL data transfer server functional entity acts as the application server for enabling data transfer. The SEAL data transfer client functional entity acts as the application client for enabling data transfer.

[0086] The reference point for the functional model used in SEALDD is described in Clause 7.4 of 3GPP TS 23.433 V19.0.0 as follows.

[0087] SEALDD-UU is a reference point between the SEALDD client and the SEALDD server. This reference point is used to transfer data content and exchange information for SEALDD service configuration, control, reporting, etc.

[0088] SEALDD-C is a reference point between the SEALDD client and the VAL client. This reference point enables the SEALDD client to expose its northbound client-side API to the VAL client for data transfer, as well as SEALDD service configuration, control, reporting, and other functions.

[0089] SEALDD-S is a reference point between the SEALDD server and the VAL server. This reference point enables the SEALDD server to expose northbound server-side APIs to the VAL server for data transfer, as well as SEALDD service configuration, control, reporting, etc.

[0090] SEALDD-E is a reference point that enables interaction between two SEALDD servers to transfer data content and exchange information for SEALDD service configuration, control, reporting, etc.

[0091] N6 is a reference point that enables interaction between the SEALDD server and the fifth-generation core network (5GC) to transmit SEALDD service packets.

[0092] N33 / N5 are reference points that enable interaction between the SEALDD server and 5GC to send control plane requests or receive control plane notifications for optimized data transfer.

[0093] For uplink (UL) services, the VAL client sends application data to the SEALDD client via SEALDD-C for SEALDD service. After data plane packet processing by the SEALDD client, the application data is converted into SEALDD data and transmitted to the SEALDD server via SEALDD-UU. The SEALDD server recovers the application data and sends it to the VAL server via SEALDD-S. For downlink (DL) services, the VAL server sends application data to the SEALDD server via SEALDD-S for SEALDD service. After data plane packet processing by the SEALDD server, the application data is converted into SEALDD data and transmitted to the SEALDD client via SEALDD-UU. The SEALDD client recovers the application data and sends it to the VAL client via SEALDD-C. Optionally, the VAL deployment can use the SEALDD service to route application signaling and application data services for some or all of its provided functions, and Figure 1b shows the architecture for implementing this approach. In this scenario, VAL clients and VAL servers can choose not to maintain application connections themselves and instead transmit all application services for those functions via the SEALDD connection.

[0094] The SEALDD capability is provided as an API to the VAL layer, which then decides which services (such as application signaling and application data) to transmit.

[0095] Currently, SEALDD lacks the capability to perform E2E measurement and / or synchronization of service flows across different SEALDD flows used to serve different VAL clients and servers. Without this capability, additional complexity and burden are placed on VAL clients and VAL servers to manage E2E multimodal communication flows over-the-top. This can be challenging for real-world deployments, as applications may be deployed in a distributed manner, requiring VAL clients to be hosted on different UEs. Similarly, different VAL servers may be used to serve different VAL service flows.

[0096] Figure 2a The diagram schematically illustrates the architecture used for application service transport, which is consistent with 3GPP TS 23.433 V19.0.0. Figure 7 .2-4 are the same.

[0097] The SEAL data transfer client interacts with the SEAL data transfer server to establish an application layer data transfer path.

[0098] Through this path, SEALDD servers and clients provide data transfer services such as data plane packet processing (e.g., packet replication, deduplication, or transport coordination), data forwarding, data caching, and background data transfer to support VAL servers and clients.

[0099] SEALDD connections can be established by a SEALDD client or a SEALDD server, as described in Clauses 9.2 and 9.3 of 3GPP TS 23.433V19.0.0.

[0100] 3GPP TS 23.433 V19.0.0 also specifies some methods for ensuring transmission quality (e.g., using redundant transmission), see Section 9.9 of 3GPP TS 23.433 V19.0.0.

[0101] Figure 2b An example of a user plane protocol stack on a 5GS according to an embodiment of this disclosure is illustrated schematically.

[0102] Application content, including SEALDD layer information and VAL payload, can be transmitted between the SEALDD client in the UE and the SEALDD server in the data network.

[0103] The Protocol Data Unit (PDU) layer corresponds to the PDU carried between the UE and DN via a PDU session. This protocol may include at least one of UDP / IP, TCP / IP, and QUIC / UDP / IP.

[0104] For downlink (DL) data, the PDU Session Anchor (PSA) UPF can tag PDU set information in the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) based on the received protocol extension (e.g., RTP). Then, during access network (AN) congestion, the 5G-RAN and / or UPF will perform specific packet processing (e.g., drop, retransmission) on the PDUs in the set, as well as on the PDU sets in the same SDF, based on the PDU set information in the GTP.

[0105] For UL data, the UE lower layer can mark PDU set information in the AN protocol based on the received protocol extension (e.g., RTP). Then, during access network congestion, the 5G-RAN will perform packet processing on the PDUs in the set and also on the PDU groups in the same Service Data Stream (SDF) based on the PDU set information in the AN protocol.

[0106] PDU set marking operations can be performed in any other suitable node or function (such as VAL client, VAL server, SEALDD client, or SEALDD server), for example when data traffic will be carried in a tunneling protocol.

[0107] An example of PDU set information is the “PDU set information” defined in 3GPP TS23.501 V18.4.0. PDU set information can be included in any appropriate location (such as the header or header extension) of packets or data in a protocol (such as a transport protocol).

[0108] A PDU set may include one or more PDUs carrying application layer payloads, such as video frames or video slices. Processing based on PDU sets is described in Clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0. Clause 5.37.5.2 of 3GPP TS 23.501 V18.4.0 describes PDU set identification. An example of PDU set marking is “RTP Header Extension for PDU Set Marking” as defined in Clause 4.4.2 of 3GPP TS 26.522 V0.2.0.

[0109] Figure 2c An example of grouping in SEALDD according to an embodiment of this disclosure is illustrated schematically.

[0110] H.264 raw data can be [NALU][NALU]…[NALU]. NALU represents a Network Abstraction Layer (NAL) unit.

[0111] After using RTP (Internet Engineering Task Force (IETF) Draft Comments (RFC) 6184, RFC 7798) for SEALDD packetization, NAL units can be segmented by SEALDD (if the size is too large for line transmission) or aggregated (for small NAL units). SEALDD can also update the NALU header.

[0112] The SEALDD payload transmitted between the SEALDD client and the SEALDD server via SEALDD / UDP / IP includes RTP / RTCP / RTSP data.

[0113] Figure 2d The high-level architecture in a 5G network according to embodiments of this disclosure is illustrated schematically. For example, the fifth-generation network may be a 5G system (5GS). Figure 2d The architecture can be similar to Figure 4.2.3-1 of 3GPP TS 23.501 V18.4.0, the entire contents of which are disclosed herein are incorporated by reference. Figure 2d The system architecture can include multiple network functions (NFs), such as Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Service Function (AUSF), Unified Data Management (UDM), Policy Control Function (PCF), Application Function (AF), Network Open Function (NEF), User Plane Function (UPF), and Network Repository Function (NRF), (Radio) Access Network ((R)AN), Service Communication Agent (SCP), Network Slice Selection Function (NSSF), Network Slice Specific Authentication and Authorization Function (NSSAAF), Edge Application Server Discovery Function (EASDF), NSACF (Network Slice Admission Control Function), NWDAF, etc.

[0114] According to an exemplary embodiment, the UE can establish a signaling connection with the AMF through reference point N1, such as... Figure 2d As shown in the diagram. This signaling connection enables NAS (Non-Access Stratum) signaling exchange between the UE and the core network, including the signaling connection between the UE and the (R)AN, and the N2 connection for the UE between the (R)AN and the AMF. The (R)AN can communicate with the UPF via reference point N3. The UE can establish a Protocol Data Unit (PDU) session with the DN (Data Network, e.g., Operator Network or Internet) via reference point N6 through the UPF.

[0115] like Figure 2dThe exemplary system architecture further illustrated also includes service-based interfaces presented by NFs (such as NRF, NEF, AUSF, UDM, PCF, AMF, NSACF, EASDF, NSSF, NWDAF, and SMF), such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf, Nnsacf, Neasdf, Nnssf, Nnwdaf, and Nsmf. Furthermore, Figure 2d Reference points, such as N1, N2, N3, N4, N6, and N9, are also shown, which can support interaction between NF services in an NF. For example, these reference points can be implemented through corresponding NF service-based interfaces, and by specifying some NF service consumers and providers and their interactions to execute specific system procedures.

[0116] Figure 2d The various NFs shown can be responsible for functions such as session management, mobility management, authentication, and security. AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R)AN, SCP, NSACF, NSSAAF, and EASDF can include, for example, the functions defined in Clause 6.2 of 3GPP TS 23.501 V18.4.0.

[0117] Protocol Description

[0118] The protocol is described in Clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0 as follows.

[0119] - Protocol Description: Indicates the transport protocol and information used by the service data stream (e.g., RTP, SRTP), such as the following:

[0120] -RTP

[185] or SRTP

[186] ;

[0121] - RTP or SRTP with RTP header extensions, including:

[0122] - RTP header extensions for PDU set tagging as defined in TS 26.522

[179] ;

[0123] - Other RTP header extensions as defined in RFC 8285

[189] ;

[0124] - RTP or SRTP without RTP header extension but with RTP payload format (e.g., H.264

[187] or H.265

[188] );

[0125] - RTP or SRTP with an RTP header extension for PDU set marking as defined in TS 26.522

[179] and having an RTP payload format (e.g., H.264

[187] or H.265

[188] );

[0126] - An RTP or SRTP with additional RTP header extensions conforming to RFC 8285

[189] and having an RTP payload format such as H.264

[187] or H.265

[188] .

[0127] The QoS parameters and protocol descriptions of the PDU set provided by the AF can be used by the PCF to determine the PCC rules, as defined in Clause 6.1.3.27.4 of TS 23.503

[45] , and the protocol descriptions can be used by the PSA UPF to identify the PDU set information.

[0128] For the downlink direction, the PSA UPF identifies PDUs belonging to the PDU set and labels them accordingly, as described in Clause 5.37.5.2 of 3GPP TS23.501 V18.4.0.

[0129] The SMF instructs the PSA UPF to perform PDU set marking and may provide the PSA UPF with the protocol description used for service data flows. The protocol description may be received in the PCC rule and is based on information provided by the AF or by the PCF local policy, as described in Clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0.

[0130] The protocol description (as described in Clause 5.37.5 of TS 23.501 V18.4.0) may be included in the AF request during the process of establishing an AF session with the required QoS, as described in Clause 4.15.6.6 of 3GPP TS23.502 V18.4.0.

[0131] The protocol description (as described in Clause 5.37.5 of TS 23.501 V18.4.0) may be included in the Npcf_PolicyAuthorization_Create service operation as described in Clause 5.2.5.3.2 of 3GPP TS23.502 V18.4.0.

[0132] The protocol description (as described in Clause 5.37.5 of TS 23.501 V18.4.0) may be included in the Nnef_AFsessionWithQoS_Create service operation as described in Clause 5.2.6.9.2 of 3GPP TS23.502 V18.4.0.

[0133] Method according to embodiments of this disclosure

[0134] Figure 3a , 3b Images 3c, 3d, 3e, 3f, 3g, 3h, and 3i illustrate flowcharts of a method according to embodiments of the present disclosure. This method can be performed by means in a first application functional entity, by means at the first application functional entity, by means implemented as the first application functional entity, or by means communicatively coupled to the first application functional entity. Therefore, the apparatus can provide components, modules, or circuits for implementing various parts of the method, as well as component modules or circuits for combining with other components to implement other processes.

[0135] Figure 3a A flowchart of a method according to an embodiment of this disclosure is shown.

[0136] In box 302, the first application function entity can receive a first message from the second application function entity, the first message including first protocol description information for transmitting data services using a transport protocol.

[0137] In an embodiment, the first protocol description information may include uplink protocol description information and / or downlink protocol description information.

[0138] The first application function entity can communicate with any suitable network. For example, the first application function entity can communicate with the underlying 3GPP network system using the appropriate 3GPP interface specified by the 3GPP network system. In an embodiment, the first application function entity can communicate with systems such as the fifth generation (5GS) or the sixth generation (6GS) as defined by 3GPP.

[0139] The first application function entity can be any suitable application function device or application function node. For example, the first application function entity can act as an application server for enabling data transmission or an application client for enabling data transmission.

[0140] In this embodiment, the first application function entity may be a SEALDD server or a SEALDD client.

[0141] The second application function entity can be any suitable application function device or application function node. For example, the second application function entity can provide client-side functions (e.g., V2X client) or server-side functions (e.g., V2X application server) corresponding to a vertical application. The second application function entity can act as an application server for enabling data transmission or an application client for enabling data transmission.

[0142] In an embodiment, the second application function entity may be a VAL server, a VAL client, a SEALDD client, or a SEALDD server.

[0143] In this embodiment, the first application function entity may be a SEALDD server, and the second application function entity may be a VAL server. For example, the SEALDD server may receive first protocol description information from the VAL server via SEALDD-S.

[0144] In this embodiment, the first application function entity can be a SEALDD server, and the second application function entity can be a SEALDD client. For example, the SEALDD client can receive first protocol description information from the VAL client via SEALDD-C, and then it can send the first protocol description message to the SEALDD server via SEALDD-UU.

[0145] In this embodiment, the first application function entity may be a SEALDD client, and the second application function entity may be a VAL client. For example, the SEALDD client may receive first protocol description information from the VAL client via SEALDD-C.

[0146] In this embodiment, the first application function entity can be a SEALDD client, and the second application function entity can be a SEALDD server. For example, the SEALDD server can receive first protocol description information from the VAL server via SEALDD-S, and then it can send the first protocol description message to the SEALDD client via SEALDD-UU.

[0147] Data services can be data services for any suitable service. In this embodiment, data services can be used for multimodal services. In other embodiments, data services can be used for any other suitable service. For example, data services can include data services for multimodal services such as XR. Data services can include application data services between SEALDD clients and VAL clients or between SEALDD servers and VAL servers. Data services between SEALDD servers and SEALDD clients can be referred to as SEALDD data services. In other words, application data services can be converted into SEALDD data services and transmitted to the SEALDD client via SEALDD-UU.

[0148] For example, XR use cases can include multiple types of streams, such as video / audio, haptic, and sensor data. These streams are multimodal communication streams, and they are used to provide multimodal XR services. These streams can span one or more application servers and clients, and may require synchronization and coordination with each other.

[0149] Many XR use cases may require end-to-end (E2E) multimodal communication flows between application clients and application servers. Using information provided by the application clients and servers (such as policies), the application enablement layer, in coordination with 5GC, can support functionalities to help manage these E2E multimodal communication flows. XR multimodal service flows may need to be synchronized with each other in an E2E manner to provide users with a high quality of experience.

[0150] The first message can be a new message or an existing message. In an embodiment, the first message may include at least one of the following: one or more SEALDD enabled regular transport requests, one or more SEALDD connection state subscription requests, one or more SEALDD service requests, one or more SEALDD regular transport connection establishment requests, one or more SEALDD regular transport connection establishment responses, one or more SEALDD URLLC transport connection establishment requests, or one or more SEALDD URLLC transport connection establishment responses, such as those described in 3GPP TS 23.433 V19.0.0.

[0151] The first protocol description information may include any suitable information. For example, the first protocol description information may include information that can be used to determine the QoS parameters of the PDU set. The first protocol description information may include information indicating whether the first application function entity needs to perform packetization. The first protocol description information may include information indicating PDU set labeling. The first protocol description information may include header extension information for PDU set labeling. The first protocol description information may include payload type and format.

[0152] A PDU set may include one or more PDUs carrying application-layer payloads, such as video frames or video slices. PDU set-based QoS processing performed by network nodes such as Next Generation (NG) RANs can be determined by the PDU set QoS parameters in the QoS profile of the QoS flow (as specified in Clause 5.7.7 of 3GPP TS 23.501 V18.4.0) and the PDU set information provided by the PDU Session Anchor (PSA) UPF via the N3 / N9 interface (as described in Clause 5.37.5.2 of 3GPP TS 23.501 V18.4.0). PDU set-based QoS processing can be applied to both Guaranteed Bit Rate (GBR) and non-GBR QoS flows.

[0153] In an embodiment, the first protocol description information may include information indicating the PDU set tag.

[0154] In an embodiment, the first protocol description information may include format parameters used by the service data stream.

[0155] In an embodiment, the information indicating the PDU set tag may include a header extension with a PDU set.

[0156] For example, the first protocol description information may indicate at least one of the following used by the service data stream: transport protocol (e.g., RTP, SRTP), transport protocol header extension (e.g., RTP header extension for PDU set labeling as defined in 3GPP TS 26.522 V0.2.0), payload type and format (e.g., H.264, H.265), and format parameters (e.g., H.264 profile level and packetization mode).

[0157] For example, the first protocol description information may include a protocol description of the VAL service. It may include at least one of the following: header extension information (e.g., RTP extension with PDU set), packetization indication, payload type and format (e.g., H.264 / RTP, H.265 / RTP, H.264, H.265).

[0158] In this embodiment, the header extension information may only be applicable when the payload indicates the RTP.

[0159] In an embodiment, the first protocol description information may include at least one piece of information describing the protocol as described in Clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0.

[0160] In an embodiment, the first protocol description information may include information about packetization for data services, such as the transport protocol used by the data service, the transport protocol payload format, etc.

[0161] The first protocol description information can be obtained by the first application function entity in various ways.

[0162] For example, if the second application function entity is an entity that generates data services (such as a VAL client or VAL server), it can generate the first protocol description information itself and send it to the first application function entity.

[0163] For example, a first application function entity, such as a SEALDD client, can receive first protocol description information from a VAL client. For instance, the VAL client can generate the first protocol description information and then send it to the SEALDD client. Alternatively, the VAL client can receive the first protocol description information from a VAL server and then send it to the SEALDD client.

[0164] For example, a first application function entity, such as a SEALDD client, can receive first protocol description information from the SEALDD server. For instance, a VAL server can generate the first protocol description information or receive it from a VAL client and then send it to the SEALDD server. The SEALDD server can then send it to the SEALDD client.

[0165] For example, a first application function entity, such as a SEALDD server, can receive first protocol description information from a SEALDD client. For instance, a VAL client can generate the first protocol description information or receive it from a VAL server and then send it to a SEALDD client. The SEALDD client can then send it to the SEALDD server.

[0166] For example, a first application function entity, such as a SEALDD server, can receive first protocol description information from a VAL server. For instance, the VAL server can generate the first protocol description information and send it to the SEALDD server. Alternatively, the VAL server can receive the first protocol description information from a VAL client and then send it to the SEALDD server.

[0167] For example, a first application function entity, such as a VAL client, can receive first protocol description information from a VAL server. Alternatively, the VAL server can generate the first protocol description information and send it to the VAL client.

[0168] For example, a first application function entity, such as a VAL server, can receive first protocol description information from a VAL client. For instance, a VAL client can generate the first protocol description information and send it to the VAL server.

[0169] In this embodiment, the first protocol description information may include protocol description information for the uplink and / or downlink. As used herein, an uplink may refer to a link from the application function client to the application function server. A downlink may refer to a link from the application function server to the application function client.

[0170] Figure 3b A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0171] In box 312, the first application function entity can receive data services from the second application function entity.

[0172] For example, a first application function entity, such as a SEALDD client, can receive data services from a second application function entity, such as a VAL client. Similarly, a first application function entity, such as a SEALDD server, can receive data services from a second application function entity, such as a VAL server.

[0173] In box 314, the first application function entity can perform grouping of data services.

[0174] As a first example, a first application function entity can receive a grouping instruction from a second application function entity, and then it can perform grouping of data services according to the grouping instruction. As a second example, the first application function entity can be configured by the operator, for example, to perform grouping of data services, and then it can perform grouping of services according to that configuration. As a third example, the first application function entity can detect that a data service has not been grouped, and then it can perform grouping of the service, for example, according to first protocol description information or configuration information.

[0175] For example, data services can be H.264 raw data: [NALU][NALU]…[NALU]. After SEALDD packetization using RTP (RFC6184, RFC 7798), NAL units can be segmented by SEALDD (if the size is too large for line transmission) or aggregated (for small NAL units). SEALDD can also update the NALU header. The SEALDD payload transmitted between the SEALDD client and SEALDD server via SEALDD / UDP / IP can include RTP / RTCP / RTSP data. Note that H.264 and RTP are used only to describe particular embodiments and are not intended to limit the exemplary embodiments. Any other suitable format and / or any other suitable protocol for the raw data is also possible.

[0176] In box 316, the first application function entity can perform PDU set marking based on the information indicating PDU set marking, so as to include PDU set information in the packetized data service.

[0177] PDU set information can be included in any suitable location within a packetized data service. In an embodiment, PDU set information can be included in the header extension of the packetized data service. An example of PDU set information is “PDU set information” as defined in 3GPP TS23.501 V18.4.0. An example of header extension is “RTP header extension for PDU set labeling” as defined in Clause 4.4.2 of 3GPP TS26.522 V0.2.0.

[0178] For example, a first application function entity can insert PDU set information associated with a packet belonging to a PDU set into the header of that packet, such as a transport protocol header extension. For example, when the transport protocol is RTP, it can use an RTP header extension for PDU set marking as defined in 3GPP TS26.522 V0.2.0 (the entire contents of which are incorporated herein by reference).

[0179] For example, PDU set information can include any suitable information. For instance, it can include at least one of the following:

[0180] -PDU set serial number.

[0181] - Indication of the end of the PDU set.

[0182] - The PDU sequence number within the PDU set.

[0183] - PDU set size (bytes).

[0184] - PDU set importance, which identifies the relative importance of a PDU set within a QoS flow compared to other PDU sets.

[0185] For example, if a packetization instruction specifies that the SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g., RTP packets) to the SEALDD client via the SEALDD-UU user plane (e.g., SEALDD / UDP / IP) for downlink application services. Similarly, the SEALDD client performs packetization and sends streaming data (e.g., RTP packets) to the SEALDD server via the SEALDD-UU user plane (e.g., SEALDD / UDP / IP) for uplink application services. The SEALDD server and client also perform PDU set marking (e.g., in RTP extensions as defined in 3GPP TS 26.522 V0.2.0) and, if necessary, perform streaming session and transport management (e.g., RTCP, RTSP).

[0186] In this embodiment, data services can be encrypted by a second application function entity and cannot be decrypted by a first application function entity. For example, in the packetized mode of SEALDD execution, to protect the stream content (e.g., if the VAL service provider and the SEALDD service provider are not from the same organization), VAL can implement payload encryption (e.g., NAL-compatible encryption for H.264).

[0187] Figure 3c A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0188] In box 322, the first application function entity can receive a grouping instruction from the second application function entity, which indicates whether the first application function entity needs to perform grouping on data services.

[0189] The grouping indication can be included in any suitable message, such as a new message or an existing message. In one embodiment, the grouping indication can be included in a first message. In another embodiment, the grouping indication can be included in first protocol description information.

[0190] A packetization instruction can be explicit or implicit. A packetization instruction can explicitly indicate which communication function should perform packetization, or whether a first application function entity needs to perform packetization. For cases where an implicit instruction indicates that either the first or second application function entity needs to perform packetization, an exemplary embodiment is as follows: when no packetization instruction exists in the first message, it can indicate that the first application function entity needs to perform packetization; when an explicit instruction to the contrary exists in the first message, it can indicate that the second application function entity needs to perform packetization.

[0191] In an embodiment, which communication function performs packetization can be predetermined or pre-configured. For example, the packetization performed by a first application function entity can be predetermined or pre-configured.

[0192] For example, two modes can be enabled. Downlink (DL) data is used as an example. Processing for uplink data can be similar.

[0193] Mode 1. The VAL server sends streaming data as a payload in a transport format (e.g., RTP packets) to the SEALDD server and performs PDU set marking (e.g., in RTP extensions). The SEALDD server then transmits the payload to the SEALDD client via the SEALDD-UU user plane (e.g., SEALDD / UDP / IP).

[0194] Mode 2. The VAL server sends encoded video and audio (e.g., H.264 and Advanced Audio Coding (AAC)) to the SEALDD server, which then performs packetization and sends the packetized data, placed in the transport (e.g., RTP packets), to the SEALDD client via the SEALDD-UU user plane (e.g., SEALDD / UDP / IP). The SEALDD server also performs PDU set marking (e.g., in RTP extensions), RTCP, and RTSP control (if needed). In this mode, it simplifies operations within the VAL; for example, the VAL application server does not need to know how to configure RTP extensions for optimized business processing in 5GS.

[0195] In this embodiment, when a grouping instruction indicates that the first application function entity needs to perform grouping on the data service, the first application function entity needs to perform grouping on the data service. When a grouping instruction indicates that the first application function entity does not need to perform grouping on the data service, the first application function entity does not perform grouping on the data service.

[0196] Figure 3d A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0197] In box 332, the first application function entity can receive packetized data services containing PDU set information from the second application function entity.

[0198] In this embodiment, the second application function entity performs packetization on the data service. For example, the second application function entity may be configured, for instance, by the operator or local policy, to perform packetization on the data service. For example, the second application function entity may perform packetization on the data service and perform PDU set marking to include PDU set information in the packetized data service.

[0199] In embodiments, PDU set information may be included in the header extension of packetized data services. An example of PDU set information is “PDU set information” as defined in 3GPP TS23.501 V18.4.0. An example of header extension is “RTP header extension for PDU set labeling” as defined in Clause 4.4.2 of 3GPP TS 26.522 V0.2.0.

[0200] Figure 3e A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0201] In box 342, the first application function entity may derive at least one set of PDU QoS parameters from the identifier of the service and / or the identifier of the application function entity providing the service.

[0202] The service can be any service provided by an application functional entity (e.g., a multimodal service). For example, the service could be provided by a VAL server or a VAL client. The service identifier can be a VAL identifier (ID).

[0203] The application entity providing this service can be any suitable application entity, such as a VAL server or a VAL client. The identifier of the application entity providing this service can be a VAL server ID or a VAL client ID.

[0204] The first application function entity can obtain the identifier of the service and / or the identifier of the application function entity providing the service in various ways. For example, the second application function entity can send the identifier of the service and / or the identifier of the application function entity providing the service to the first application function entity in any appropriate message.

[0205] In an embodiment, the first message may include the identifier of the service and / or the identifier of the application functional entity.

[0206] The first application function entity may derive at least one set of PDU QoS parameters from the identifier of the service and / or the identifier of the application function entity providing the service in various ways.

[0207] In an embodiment, the first application function entity may be configured with a mapping table between the service identifier (or the identifier of the application function entity providing the service, or the service identifier and the identifier of the service function entity providing the service) and at least one PDU set QoS parameter, and the first application function entity may derive at least one PDU set QoS parameter by querying the mapping table.

[0208] In an embodiment, the first application function entity may derive or determine at least one PDU set QoS parameter based on local configuration or local policy.

[0209] In an embodiment, when the first application function entity is a SEALDD server, it can derive PDU set QoS parameters from the VAL service ID and / or VAL server ID.

[0210] In an embodiment, when the first application function entity is a SEALDD client, it can derive PDU set QoS parameters from the VAL service ID and / or VAL client ID.

[0211] In an embodiment, for a multimodal service, a first application function entity can derive at least one PDU set QoS parameter from the identifier of the multimodal service and / or the identifier of the application function entity providing the multimodal service. The first application function entity can determine whether the service is a multimodal service, for example, based on first protocol description information or information indicating PDU set markings.

[0212] PDU set QoS parameters can include any suitable QoS parameters. For example, it can include at least one of the following: PDU set delay budget (PSDB), PDU set error rate (PSER), or PDU set integrated processing information (PSIHI) as described in 3GPP TS 23.501 V18.4.0. PDU set QoS parameters can include PDU set QoS parameters for UL and / or DL ​​directions.

[0213] In box 344, the first application function entity may use the process of establishing an application function session with the required QoS to send at least one set of PDU QoS parameters to the network open node or policy control node.

[0214] In an embodiment, the first application function entity may send at least one set of QoS parameters of PDUs to the network open node, and the network open node may send them directly or via Time-Sensitive Communication and Time Synchronization Function (TSCTSF) to the policy control node, as described in Clause 4.15.6.6 or Clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0, the entire contents of which are hereby incorporated by reference.

[0215] A network open node can be any suitable network device, network node, network function, or network entity capable of implementing open functionality. For example, a network open node can provide means for securely opening services, events, and capabilities offered by a network interface. In embodiments, a network open node may include a network open function (NEF). In embodiments, a network open node may include a network open node that can be defined in 3GPP's 6GS.

[0216] A policy control node can be any suitable network device, network node, network function, or network entity capable of implementing policy control functions. In some embodiments, a policy control node may include a PCF. In some embodiments, a network open node may include policy control functions that can be defined in 3GPP's 6GS.

[0217] The process of establishing an Application Function Session (AF) with the required QoS can be any suitable process capable of establishing an AF session with the required QoS. In an embodiment, this process can be the process of establishing an AF session with the required QoS, as described in Clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0, or the update process of an AF session with the required QoS, as described in Clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0.

[0218] In an embodiment, after the policy control node receives at least one set of PDU QoS parameters, the policy control node may perform the operations described in Clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0, Clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0, or Clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0.

[0219] For example, at least one PDU set QoS parameter can be used by a policy control node (e.g., PCF) to determine policy and charging control (PCC) rules. The policy control node can send PCC rules to the SMF. When the SMF receives a PCC rule containing one or more PDU set QoS parameters (e.g., PSER, PSDB, and PSIHI), the SMF can add these PDU set QoS parameters to the QoS profile of the QoS flow. The SMF can send the QoS profile of the QoS flow to the AMF. The AMF can send the QoS profile of the QoS flow to the NG-RAN. The NG-RAN can perform PDU set-based QoS processing as described in Clause 5.37.5 of 3GPP TS 23.501 V18.4.0.

[0220] Figure 3f A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0221] In box 352, the first application function entity can obtain second protocol description information for transmitting packetized data services containing PDU set information using a tunneling protocol.

[0222] In an embodiment, the second protocol description information may include uplink protocol description information and / or downlink protocol description information.

[0223] The tunneling protocol can be any suitable tunneling protocol, and this disclosure does not limit it. For example, the tunneling protocol may include at least one of the following: Generic Routing Encapsulation (GRE), Open Virtual Private Network (OpenVPN), Virtual Extensible Local Area Network (VXLAN), Layer 2 Tunneling Protocol (L2TP), Geneve Network Virtualization Encapsulation, etc.

[0224] In this embodiment, the tunneling protocol can be any suitable tunneling protocol that can be used for SEALDD-UU or SEALDD connections.

[0225] In an embodiment, the second protocol description information may include any suitable information that can be used by the client-side functions and / or the access network protocol layer entities of the terminal device to identify PDUs belonging to the PDU set.

[0226] In an embodiment, the second protocol description information may include a protocol description and information related to the tunneling protocol as described in Clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0.

[0227] In an embodiment, the second protocol description information may include at least one of the following: information indicating the use of a tunneling protocol in the transmission of packetized data services, the tunneling protocol header length, the tunneling protocol payload offset, the location of PDU set information, or offset position information in the tunneling protocol header. The tunneling protocol header length and the tunneling protocol payload offset can be used to locate the PDU set information.

[0228] The first application function entity can obtain the second protocol description information in various ways, such as determining it itself or receiving it from another entity.

[0229] In this embodiment, when the first application function entity is a SEALDD server, it can determine the second protocol description information itself. For example, the SEALDD server can transmit packetized data services according to a tunneling protocol and determine the second protocol description information.

[0230] In this embodiment, when the first application function entity is a SEALDD client, the SEALDD client can determine the second protocol description information itself. For example, the SEALDD client can transmit packetized data services according to a tunneling protocol and determine the second protocol description information.

[0231] In this embodiment, when the first application functional entity is a SEALDD client, the SEALDD client can receive the second protocol description information directly from the SEALDD server or via the VAL server and the VAL client. For example, the SEALDD server can determine the second protocol description information. The SEALDD server can send it directly to the SEALDD client via SEALDD-UU. Alternatively, the SEALDD server can send it to the VAL server via SEALDD-S. The VAL server can send it to the VAL client via VAL-UU. The VAL client can send it to the SEALDD client via SEALDD-C.

[0232] In this embodiment, when the first application function entity is a SEALDD server, the first application function entity can receive the second protocol description information directly from the SEALDD client or via the VAL client and VAL server. For example, the SEALDD client can determine the second protocol description information. The SEALDD client can send it directly to the SEALDD server via SEALDD-UU. Alternatively, the SEALDD client can send it to the VAL client via SEALDD-C. The VAL client can send it to the VAL server via VAL-UU. The VAL server can send it to the SEALDD server via SEALDD-S.

[0233] In an embodiment, the second protocol description information may include protocol description information for the uplink and / or downlink.

[0234] Figure 3g A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0235] In box 362, when the first application function entity is a SEALDD server, the first application function entity may send the second protocol description information to at least one of the following: a SEALDD client, a network open node, or a policy control node, for example, to enable the second protocol description information to be sent to the access network protocol layer entity of the user plane function and / or the terminal device.

[0236] For example, the SEALDD server can send the second protocol description information to the SEALDD client via SEALDD-UU. Alternatively, the SEALDD server can send the second protocol description information to the VAL server via SEALDD-S. The VAL server can then send it to the VAL client via VAL-UU. The VAL client can then send it to the SEALDD client via SEALDD-C. The SEALDD client can then send the second protocol description information to the access network protocol layer entity of the terminal device.

[0237] For example, a SEALDD server acting as an AF can send second protocol description information to a network open node or policy control node in various ways (such as those described in various 3GPP specifications, such as 3GPP TS23.502 V18.4.0). For instance, the SEALDD server can use the procedure for establishing an AF session with the required QoS as described in Clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0, or the procedure for updating an AF session with the required QoS as described in Clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0, to send the second protocol description information to the network open node or policy control node. For instance, the SEALDD server can use a PCF-initiated SM policy association modification as described in Clause 4.16.5.2 of 3GPP TS 23.502 V18.4.0 to send the second protocol description information to the policy control node. The policy control node can then send the second protocol description information to the SMF. SMF can send second protocol description information to the access network protocol layer entities and / or user plane functions of the terminal device.

[0238] In one embodiment, the second protocol description information and at least one PDU set QoS parameter can be sent together in the same message. In another embodiment, the second protocol description information and at least one PDU set QoS parameter can be sent in different messages.

[0239] Figure 3h A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0240] In box 372, when the first application function entity is a SEALDD client, the first application function entity may send second protocol description information to at least one of the following: a SEALDD server, a network open node, or a policy control node, for example, to enable the second protocol description information to be sent to the access network protocol layer entity of the user plane function and / or the terminal device.

[0241] For example, a SEALDD client can send the second protocol description information to a SEALDD server via SEALDD-UU. Alternatively, the SEALDD client can send the second protocol description information to a VAL client via SEALDD-C, and the VAL client can send it to a VAL server via VAL-UU. The VAL server can then send it to the SEALDD server via SEALDD-S. The SEALDD server, acting as an AF (Agent Front-End), can send the second protocol description information to a network open node or policy control node in various ways (such as those described in various 3GPP specifications, e.g., 3GPP TS 23.502 V18.4.0). The policy control node can send the second protocol description information to the SMF (Service Front-End). The SMF can send the second protocol description information to the access network protocol layer entities and / or user plane functions of the terminal equipment.

[0242] As an AF (Agency Default Server) client, the SEALDD client can send second protocol description information to the network opening node or policy control node in various ways, such as those described in various 3GPP specifications (e.g., 3GPP TS 23.502 V18.4.0). For example, the SEALDD client can use the procedure for establishing an AF session with the desired QoS as described in Clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0, or the procedure for updating an AF session with the desired QoS as described in Clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0, to send second protocol description information to the network opening node or policy control node. For example, the SEALDD client can use the PCF-initiated SM policy association modification as described in Clause 4.16.5.2 of 3GPP TS 23.502 V18.4.0 to send second protocol description information to the policy control node. The policy control node can then send the second protocol description information to the SMF. SMF can send second protocol description information to the access network protocol layer entities and / or user plane functions of the terminal device.

[0243] In one embodiment, the second protocol description information and at least one PDU set QoS parameter can be sent together in the same message. In another embodiment, the second protocol description information and at least one PDU set QoS parameter can be sent in different messages.

[0244] Figure 3i A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0245] In box 382, ​​when the first application function entity is a SEALDD client, the first application function entity can send the second protocol description information to the access network protocol layer entity of the terminal device. For example, the SEALDD client can be located in the terminal device and can send the second protocol description information to the access network protocol layer of the terminal device.

[0246] The second protocol description information can be used to identify PDUs belonging to a PDU set. For the downlink direction, the PSA UPF identifies PDUs belonging to the PDU set and marks them accordingly, as described in Clause 5.37.5.2 of 3GPP TS 23.501 V18.4.0. For the uplink direction, the terminal device identifies PDUs belonging to the PDU set and marks them accordingly. For example, the PSA UPF can insert PDU set information associated with packets belonging to the PDU set into the User Plane General Packet Radio Service (GPRS) Tunneling Protocol (GTP-U) header. The PSA UPF can forward the PDU set-related information for each PDU to the NG-RAN via GTP-U, as described in Clause 5.37.5 of 3GPP TS 23.501 V18.1.0. Terminal devices can perform similar operations. NG-RAN performs PDU-based QoS processing, which is determined by the PDU set QoS parameters in the QoS profile of the QoS flow and the PDU set information provided by the PSA UPF via the N3 / N9 interface or by the terminal equipment. PDU-based QoS processing can be applied to both GBR and non-GBR QoS flows.

[0247] Figure 4a , 4b Images 4c, 4d, 4e, and 4f illustrate flowcharts of a method according to embodiments of the present disclosure. This method can be performed by means of a device in a second application functional entity, or by means of a device located at the second application functional entity, or by means of a device implemented as a second application functional entity, or by means of a device communicatively coupled to the second application functional entity. Therefore, the device can provide components, modules, or circuits for implementing various parts of the method, as well as component modules or circuits for combining with other components to implement other processes. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0248] Figure 4a A flowchart of a method according to another embodiment of this disclosure is shown.

[0249] In box 402, the second application function entity can send a first message to the first application function entity, the first message including first protocol description information for transmitting data services using a transport protocol.

[0250] In an embodiment, the first protocol description information may include uplink protocol description information and / or downlink protocol description information.

[0251] In this embodiment, data services can be used for multimodal services.

[0252] In an embodiment, the first protocol description information may include information indicating the labeling of a protocol data unit (PDU) set.

[0253] In this embodiment, the first application function entity may be a SEALDD server, and the second application function entity may be a VAL server.

[0254] In this embodiment, the first application function entity may be a SEALDD client, and the second application function entity may be a VAL client.

[0255] In this embodiment, the first application function entity may be a SEALDD server, and the second application function entity may be a SEALDD client.

[0256] In this embodiment, the first application function entity may be a SEALDD client, and the second application function entity may be a SEALDD server.

[0257] In an embodiment, the first message may include at least one of the following: one or more SEALDD enabled regular transport requests, one or more SEALDD connection state subscription requests, one or more SEALDD service requests, one or more SEALDD regular transport connection establishment requests, one or more SEALDD regular transport connection establishment responses, one or more SEALDD URLLC transport connection establishment requests, or one or more SEALDD URLLC transport connection establishment responses.

[0258] In an embodiment, the first protocol description information may include at least one of the following: information indicating the protocol data unit (PDU) set marker, payload type and format, or transport protocol indication.

[0259] In an embodiment, the information indicating the PDU set tag may include a header extension with a PDU set.

[0260] In this embodiment, the first application function entity may be a SEALDD server, and the second application function entity may be a VAL server.

[0261] In this embodiment, the first application function entity may be a SEALDD client, and the second application function entity may be a VAL client.

[0262] In this embodiment, the first application function entity may be a SEALDD server, and the second application function entity may be a SEALDD client.

[0263] In this embodiment, the first application function entity may be a SEALDD client, and the second application function entity may be a SEALDD server.

[0264] In this embodiment, the service may include a multimodal service.

[0265] In an embodiment, the first message may include at least one of a regular transport request for SEALDD enablement or a SEALDD connection state subscription request.

[0266] Figure 4b A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0267] In box 412, the second application function entity can send services to the first application function entity. For example, the first application function entity can perform packetization on data services.

[0268] In this embodiment, the data service is encrypted by the second application function entity and cannot be decrypted by the first application function entity.

[0269] Figure 4c A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0270] In box 422, the second application function entity can send a grouping instruction to the first application function entity, which indicates whether the first application function entity needs to perform grouping on data services.

[0271] Figure 4d A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0272] In box 432, the second application function entity can perform grouping of data services. Box 432 is similar to box 314.

[0273] In box 434, the second application function entity can perform PDU set marking based on the information indicating PDU set marking, so as to include PDU set information in the packetized data service. Box 434 is similar to box 316.

[0274] In box 436, the second application function entity can send packetized data services containing PDU set information to the first application function entity.

[0275] In this embodiment, PDU set information may be included in the header extension of the packetized data service.

[0276] Figure 4e A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0277] In box 442, when the second application function entity is a SEALDD server, the second application function entity can receive second protocol description information from the SEALDD client for transmitting packetized data services containing PDU set information using a tunneling protocol.

[0278] In an embodiment, the second protocol description information may include uplink protocol description information and / or downlink protocol description information.

[0279] In box 444, the second application function entity may send second protocol description information to at least one of the network open node or policy control node, for example, to enable the second protocol description information to be sent to the access network protocol layer entity of the user plane function and / or terminal device.

[0280] Figure 4f A flowchart of a method according to another embodiment of this disclosure is shown. For the sake of brevity, descriptions of some parts already described in the above embodiments are omitted here.

[0281] In box 452, when the second application function entity is a SEALDD client, the second application function entity can receive second protocol description information from the SEALDD server for transmitting packetized data services containing PDU set information using the tunneling protocol.

[0282] In an embodiment, the second protocol description information may include uplink protocol description information and / or downlink protocol description information.

[0283] In box 454, the second application function entity may send second protocol description information to at least one of the network open node or policy control node, for example, to enable the second protocol description information to be sent to the access network protocol layer entity of the user plane function and / or terminal device.

[0284] In an embodiment, the second protocol description information may include at least one of the following: information indicating the use of a tunneling protocol in the transmission of packetized data services, the header length of the tunneling protocol, the offset of the payload of the tunneling protocol, the location of the PDU set information, or offset position information in the header of the tunneling protocol.

[0285] According to the various embodiments, the proposed solutions describe how the application enablement layer can facilitate application multimodal service over-the-top, thereby reducing the complexity of the VAL, while taking into account network capabilities and application adaptation and optimization.

[0286] According to various embodiments, this solution proposes to specify the following aspects in facilitating the application of multimodal services (e.g., for XR services):

[0287] This enables the SEALDD server to export auxiliary information related to the PDU set when interacting with the 3GPP core network; and

[0288] Enable the SEALDD layer to handle packetization, PDU set marking (e.g. in RTP extensions), and RTCP and RTSP control to reduce the load on VAL clients and VAL servers.

[0289] In this embodiment, the protocol description described in 3GPP TS 23.501 V18.4.0 can be expanded with SEALDD information; for example, underlined portions can be added to the protocol description.

[0290] - Protocol Description: Indicates the transport protocol and information used by the service data stream (e.g., RTP, SRTP), such as the following:

[0291] -RTP

[185] or SRTP

[186] ;

[0292] - RTP or SRTP with RTP header extensions, including:

[0293] - RTP header extensions for PDU set tagging as defined in TS 26.522

[179] ;

[0294] - Other RTP header extensions as defined in RFC 8285

[189] ;

[0295] - RTP or SRTP without RTP header extension but with RTP payload format (e.g., H.264

[187] or H.265

[188] );

[0296] - RTP or SRTP with an RTP header extension for PDU set marking as defined in TS 26.522

[179] and having an RTP payload format (e.g., H.264

[187] or H.265

[188] );

[0297] - An RTP or SRTP with additional RTP header extensions conforming to RFC 8285

[189] and having an RTP payload format such as H.264

[187] or H.265

[188] .

[0298] -SEALDD usage instructions (e.g., whether SEALDD is used for service data flow) (if SEALDD is used) SEALDD Head length or payload (e.g., RTP or SRTP) offset and offset information location in the SEALDD header.

[0299] Note: In one protocol implementation, by knowing the length of the SEALDD header, the UPF or UE lower layer (e.g., the access network protocol layer) can skip the SEALDD header, assuming that the eight bytes / bytes following the header are the first eight bytes / bytes of the payload. In another protocol implementation, by knowing the SEALDD payload offset and the position of the offset information in the SEALDD header, the UPF or UE layer can identify the first eight bytes / bytes of the SEALDD payload.

[0300] As described in Clauses 5.37.5.1 and 5.37.5.2 of 3GPP TS 23.501 V18.4.0, the PSA UPF can use the protocol description for DL ​​data received from the AF to identify PDU set information. Using the SEALDD information, the PSA UPF can correctly identify the SEALDD payload (e.g., RTP or SRTP) and continue to identify the PDU set information for DL ​​data (e.g., identifying PDUs belonging to the PDU set).

[0301] PCF Impact: The QoS parameters and protocol descriptions (UL and / or DL) of the PDU set provided by AF can be used by PCF to determine PCC rules, as defined in Clause 6.1.3.27.4 of 3GPP TS 23.503 V18.4.0.

[0302] For UL protocol description processing, one of two options can be used:

[0303] Option 1: For UL data, the application client in the UE (e.g., a SEALDD client) can send the SEALDD information as described above to the UE lower layer in the UL protocol description, so that the UE lower layer can mark the PDU set information in the AN protocol based on the received protocol extension (e.g., RTP extension). Then, during AN congestion, the 5G-RAN will perform packet processing on the PDUs in the set based on the PDU set information in the AN protocol, as well as on the PDU set in the same SDF.

[0304] Option 2: The AF sends the UL protocol description to the NEF / PCF, which then sends it to the SMF. The SMF further sends the UL protocol description to the UE lower layer (e.g., via NAS messages).

[0305] Note: For the AF calling NEF / PCF services to provide a protocol description including SEALDD information, alternatively, the UE application client can call NEF / PCF services based on CAPIF (quoted from TS 23.222 v.19.0.0, Clause 6.3.2: "API callers can be applications on the server or applications on the UE.").

[0306] The embodiments described herein can provide numerous advantages, and the following is a non-exhaustive list of examples of these advantages. In some embodiments described herein, it can reduce the complexity of second application function entities such as VAL clients and VAL servers. For example, the second application function entity can only transmit raw media data, such as H.264, to a first application function entity such as a SEALDD server or SEALDD client, and the first application function entity will handle the rest, such as packetization, PDU set marking, or RTCP and RTSP control. In some embodiments described herein, it can enable a first application function entity such as a SEALDD server to derive auxiliary information related to PDU sets when interacting with the 3GPP core network. In some embodiments described herein, it can enable a first application function entity (e.g., a SEALDD server or SEALDD client) to handle packetization, PDU set marking (e.g., in RTP extensions), and RTCP and RTSP control, thereby reducing the load on the second application function entity (e.g., a VAL client and VAL server). In some embodiments herein, it can address the following problem: how to notify the access network protocol layer entities of user plane functions and / or terminal devices when using the SEALDD application layer: information indicating the use of tunneling protocols and tunneling protocol information in the transmission of packetized data services. In some embodiments herein, it can ensure that the access network protocol layer entities of user plane functions and / or terminal devices can correctly process tunneling protocol data. In some embodiments herein, it can protect streaming content, for example, if the VAL service provider and the SEALDD service provider are not from the same organization. The embodiments herein are not limited to the features and advantages described above. Additional features and advantages will be recognized by those skilled in the art upon reading the following detailed description.

[0307] Apparatus according to embodiments of the present disclosure

[0308] Figure 7 This is a block diagram illustrating an apparatus suitable for implementing some embodiments of the present disclosure. For example, the first or second application function entity described above can be implemented as or through the apparatus 700.

[0309] The device 700 includes at least one processor 721, such as a digital processor (DP), and at least one memory (MEM) 722 coupled to the processor 721. The device 700 may also include a transmitter TX and a receiver RX 723 coupled to the processor 721. The MEM 722 stores a program (PROG) 724. The PROG 724 may include instructions that, when executed on the associated processor 721, enable the device 700 to operate according to embodiments of the present disclosure. A combination of at least one processor 721 and at least one MEM 722 can form a processing device 725 suitable for implementing various embodiments of the present disclosure.

[0310] The various embodiments of this disclosure can be implemented by a computer program, software, firmware, hardware, or a combination thereof that can be executed by one or more processors 721.

[0311] The MEM 722 can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based storage devices, magnetic storage devices and systems, optical storage devices and systems, fixed memory and removable memory, as non-limiting examples.

[0312] The processor 721 may be of any type suitable for the local technical environment and may include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture, as non-limiting examples.

[0313] In embodiments where the device is implemented as a first application functional entity or implemented at a first application functional entity, the memory 722 contains instructions executable by the processor 721, thereby allowing the first application functional entity to operate according to any method performed by the first application functional entity as described above.

[0314] In embodiments where the device is implemented as a second application functional entity or implemented at a second application functional entity, the memory 722 contains instructions executable by the processor 721, thereby allowing the second application functional entity to operate according to any method performed by the second application functional entity as described above.

[0315] Using functional units, the first or second application functional entity may not require a fixed processor or memory; arbitrary computing and storage resources can be deployed from the first or second application functional entity within the communication system. The introduction of virtualization and network computing technologies can improve the efficiency of network resource utilization and network flexibility.

[0316] While the computing devices described herein (e.g., UE, network node, host) may include the hardware component combinations shown, other embodiments may include computing devices with different component combinations. It will be understood that these computing devices may include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determination, computation, acquisition, or similar operations described herein may be performed by processing circuitry that processes information by, for example, converting acquired information into other information, comparing the acquired or converted information with information stored in a network node, and / or performing one or more operations based on the acquired or converted information, and making determinations based on the results of said processing. Furthermore, although components are depicted as single boxes located within larger boxes or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functionality may be partitioned between individual components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of a component may be partitioned between processing circuitry and the communication interface. In another example, non-computationally intensive functionality of any such component may be implemented in software or firmware, while computationally intensive functionality may be implemented in hardware.

[0317] In some embodiments, some or all of the functionality described herein may be provided by processing circuitry that executes instructions stored in memory, which in some embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry without executing instructions stored, for example, on a separate or discrete device-readable storage medium in a hard-wired manner. In any of these particular embodiments, the processing circuitry may be configured to perform the described functionality regardless of whether instructions stored on a non-transitory computer-readable storage medium are executed. The benefits provided by such functionality are not limited to processing circuitry alone or to other components of a computing device, but can generally be enjoyed by the entire computing device and / or end users and wireless networks.

[0318] The term unit or module may have the conventional meaning in the field of electronic, electrical and / or electronic equipment, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logic solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, outputs and / or display functions, and the like, as described herein.

[0319] According to one aspect of this disclosure, a computer program product is provided, which is tangibly stored on a computer-readable storage medium and includes instructions that, when executed on at least one processor, cause the at least one processor to perform any of the methods described above.

[0320] According to one aspect of this disclosure, a computer-readable storage medium is provided that stores instructions, when executed on at least one processor, causing the at least one processor to perform any of the methods described above.

[0321] Furthermore, this disclosure may also provide a carrier containing the aforementioned computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium. The computer-readable storage medium may be, for example, an optical disc or an electronic storage device, such as RAM (random access memory), ROM (read-only memory), flash memory, magnetic tape, CD-ROM, DVD, Blu-ray disc, etc.

[0322] The techniques described herein can be implemented in various ways, such that the means for implementing one or more functions of the corresponding apparatus described in the embodiments includes not only prior art components, but also components for implementing one or more functions of the corresponding apparatus described in the embodiments, and may include separate components for each individual function, or components that can be configured to perform two or more functions. For example, these techniques can be implemented in hardware (one or more apparatuses), firmware (one or more apparatuses), software (one or more modules), or a combination thereof. For firmware or software, implementation can be accomplished by modules (e.g., processes, functions, etc.) that perform the functions described herein.

[0323] Exemplary embodiments of the present document have been described above with reference to block diagrams and flowcharts of methods and apparatus. It will be understood that each block of the block diagrams and flowcharts, as well as combinations of blocks in the block diagrams and flowcharts, can be implemented by various components including computer program instructions. These computer program instructions can be loaded onto a general-purpose computer, a special-purpose computer, or other programmable data processing equipment to produce a machine, such that the instructions, which execute on the computer or other programmable data processing equipment, create components for implementing the functions specified in the flowchart blocks or blocks.

[0324] Furthermore, although the operations are depicted in a specific order, this should not be construed as requiring that these operations be performed in the specific order shown or sequentially, or requiring that all illustrated operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features described in the context of a single embodiment may also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0325] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any implementation or the scope that may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular implementation. Some features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually in multiple embodiments or in any suitable sub-combination. Furthermore, while the features described above may be described as functioning in certain combinations, and even initially claimed in this way, in certain circumstances one or more features from the claimed combination may be removed from the combination, and the claimed combination may be for sub-combinations or variations thereof.

[0326] It will be apparent to those skilled in the art that the inventive concept can be implemented in various ways with advancements in technology. The above embodiments are given for description purposes only and not for limitation of this disclosure, and it should be understood that modifications and variations can be made without departing from the spirit and scope of this disclosure, as will be readily apparent to those skilled in the art. Such modifications and variations are considered to be within the scope of this disclosure and the appended claims. The scope of protection of this disclosure is defined by the appended claims.

[0327] In this embodiment, 3GPP TS23.433 V19.0.0 can be modified as follows.

[0328]

[0329] Further discussion (if needed):

[0330] Since version 18, SEALDD has been specified in 3GPP. Figure 2b The document describes the user plane protocol stack on 5GS. Application content, including SEALDD layer information and VAL payload, is transmitted between the SEALDD client in the UE and the SEALDD server in the data network.

[0331] The PDU layer corresponds to the PDU carried between the UE and DN through a PDU session. Examples include UDP / IP, TCP / IP, and QUIC / UDP / IP.

[0332] For DL ​​data, the PSA UPF can tag PDU set information in the GTP based on the received protocol extensions (e.g., RTP extensions). Then, during AN congestion, the 5G-RAN and / or UPF will perform specific packet processing (e.g., drop, retransmission) on the PDUs in the set and also on the PDU set in the same SDF based on the PDU set information in the GTP.

[0333] For UL data, the UE lower layer can mark PDU set information in the AN protocol based on the received protocol extensions (such as RTP extensions). Then, during AN congestion, the 5G-RAN will perform packet processing on the PDUs in the set and also on the PDU sets in the same SDF according to the PDU set information in the AN protocol.

[0334] Grouping in SEALDD Figure 2c Described as:

[0335] H.264 raw data: [NALU][NALU]…[NALU]

[0336] After SEALDD packetization using RTP (RFC 6184, RFC 7798), NAL units can be segmented by SEALDD (if the size is too large for line transmission) or aggregated (for small NAL units). SEALDD also updates the NALU header.

[0337] The SEALDD payload transmitted between the SEALDD client and the SEALDD server via SEALDD / UDP / IP includes RTP / RTCP / RTSP data.

[0338] The proposed changes are:

[0339] References

[0340] The following document contains terms, which, through reference in this document, constitute the terms of this document.

[0341] References are either specific (identified by publication date, edition number, version number, etc.) or non-specific.

[0342] - For certain references, subsequent revisions are not applicable.

[0343] - For non-specific references, the latest version applies. When citing 3GPP documents (including GSM documents), a non-specific reference implicitly refers to the latest version of that document within the same version as this document.

[0344] [1] 3GPP TR 21.905: “Glossary for 3GPP specifications”.

[0345] [2]-

[15] omitted

[0346] [TS26522]3GPP TS 26.522: "5G Real-Time Media Transport Protocol Configuration".

[0347] 9.2.2.2 SEALDD Enabled Regular Data Transmission Connection Establishment Process

[0348] Figure 5 A flowchart is shown for the process of establishing a regular SEALDD data transmission connection.

[0349] Prerequisites:

[0350] -VAL servers can discover and select SEALDD servers using the CAPIF function.

[0351] Figure 5 The steps are as follows.

[0352] 1. The VAL server decides to use the SEALDD service for application service transmission and allocates an address / port as SEALDD-S data transmission connection information for receiving data packets from the SEALDD server. The VAL server sends an Sdd_RegularTransmission request to the SEALDD server discovered by CAPIF. This service request includes the UE ID / address, VAL server ID, VAL service ID, SEALDD-S data transmission connection information on the VAL server side, and optionally, Protocol Description QoS information used for application services, such as QoS requirements.

[0353] 2. Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, the SEALDD server assigns its own address / port as the SEALDD-S data transmission connection information on the SEALDD service side. This address / port is used to receive packets from the VAL server for application data transmission. The SEALDD server assigns a specific address or port to the VAL server, which is used for SEALDD service transmission with a specific UE and responds with a SEALDD service response (including the SEALDD-S data transmission connection information on the SEALDD server side). The VAL server and SEALDD server can use the SEALDD-S data transmission connection information to establish a data transmission connection between themselves for application data transmission.

[0354] The SEALDD server can send an AF request to the 5GC via N33 / N5 to provide the required QoS information, as described in Clauses 5.2.6.9 and 5.2.5.3 of 3GPP TS 23.502[6]. The AF request includes an application service descriptor containing the address or port assigned by the SEALDD server and QoS information for the application service. If the QoS information is not provided by the VAL server, the SEALDD server can determine the QoS information based on the VAL service ID for the different service types used for the application service. If the SEALDD server is connected to the PCF via the N5 reference point, the SEALDD server relies on the Northbound Policy Authorization Service API opened by the PCF as specified in 3GPP TS 23.502 [6] and 3GPP TS 23.503 [7]; if the SEALDD server is connected to the PCF via the NEF, the SEALDD server relies on the Northbound AF Session API with QoS services and / or PFD Management Northbound API opened by the NEF as specified in 3GPP TS 23.502 [6] and 3GPP TS 23.503 [7]. SEALDD may also rely on the EES Session API with QoS as specified in 3GPP TS 23.558

[10] and / or the NRM QoS features described in 3GPP TS 23.434 [4]. For multimodal services applications The SEALDD server derives auxiliary information related to the PDU set based on the VAL service ID and / or VAL server ID for use with NEF / PCF Interaction .

[0355] Editor's Note: For the SEALDD layer, it is a tunnel (e.g., SEALDD / UDP / IP) that wraps the packet from the VAL service. Multimodal service data (e.g., RTP packets) for both server and client. How can the SEALDD server provide session APIs with QoS? The description of the tunneling protocol for the 5GC indicates that it needs to be coordinated with SA2.

[0356] Note 1: If the SEALDD server obtains data / content from the address provided by the VAL server using downlink pull mode in step 1, and sends the data / content to the address provided by the VAL server using uplink push mode, then the SEALDD-S data transmission connection information on the SEALDD server side is optional when responding to the VAL server.

[0357] 3. The VAL server provides data transmission session information to the VAL client via application signaling.

[0358] Note 2: Application signaling can be sent via a direct application layer connection or via the SEALDD layer.

[0359] 4. The VAL client sends a SEALDD service request to the SEALDD client. The VAL client receives a SEALDD service response from the SEALDD client. This response indicates whether the SEALDD service request was successful.

[0360] 5. The VAL / SEALDD client discovers and selects a suitable SEALDD server for the VAL application, as described in Section 9.4.3. After this step, the VAL server is discovered and selected along with the associated SEALDD server, and the SEALDD client obtains the address of the SEALDD service.

[0361] 6. The SEALDD client assigns a SEALDD flow ID mapped to the identifier of the application service. The SEALDD client sends an Sdd_RegularTransmissionConnection_Establish request to the SEALDD server, which has the SEALDD client ID, SEALDD flow ID, SEALDD service descriptor on the SEALDD client side (the address / port of the SEALDD client used to receive downlink SEALDD services), VAL server ID, and VAL service ID. The request message also includes the selected VAL server endpoint information and UEID. The SEALDD server retrieves the location information of the VAL UE or SEALDD client from the SEAL LM service defined in Clause 9.3.12 of 3GPP TS 23.434[4] and verifies it using the geofencing policy configured by the VAL server to allow or restrict the establishment of the data connection. If the location information is allowed according to the configured geofencing policy, the SEALDD server allows the establishment of the data connection; otherwise, the SEALDD server returns a failure result, such as performing a connection rejection.

[0362] Note 3: The SEALDD server can use or update the association between the SEALDD-UU connection and the SEALDD-S connection. This association is associated with the UE ID, VAL service ID, and VAL server endpoint. This association is used to associate SEALDD services and VAL application services.

[0363] Note 4: SEALDD clients and SEALDD servers use SEALDD Stream IDs to identify different VAL applications within the same SEALDD client. The SEALDD Stream ID can be the same as the application identifier or a new, simplified ID assigned by SEALDD.

[0364] 7. The SEALDD server responds to the SEALDD client with a SEALDD service descriptor mapped to the application service's SEALDD service side (e.g., the address / port and transport layer protocol allocated in step 2). SEALDD servers can be used in SEALDD normally. The protocol description received from the VAL server is sent to the SEALDD client in the connection establishment response. .

[0365] 8. If a connection is not established between the VAL server and the SEALDD server in step 2, the SEALDD server establishes a connection with the VAL server based on the SEALDD-S information negotiated in steps 1-2, so that the VAL client can send application services mapped to the SEALDD service.

[0366] 9. The SEALDD client uses the SEALDD service descriptor on the SEALDD server side for SEALDD connection establishment.

[0367] After this step, both the SEALDD client and the SEALDD server will obtain the entire SEALDD service descriptor (including the address / port of the UE used for SEALDD service transmission and the address / port of the SEALDD server).

[0368] After negotiation and connection establishment, the SEALDD client obtains the mapping information between the application service and the SEALDD flow ID. The SEALDD server obtains the mapping data between the SEALDD flow ID and the SEALDD-S connection. After receiving the application service from the VAL client, SEALDD maps it to a SEALDD service with the SEALDD service descriptor negotiated with the SEALDD server in steps 6 and 7. The SEALDD service is sent to the SEALDD server. The SEALDD server maps the SEALDD service to the application service based on the stored SEALDD service descriptor, SEALDD client ID, and SEALDD flow ID. Based on the mapping information, the SEALDD server sends the recovered application service to the address provided by the VAL server in step 1 via the connection established in step 2 or 8. Downlink application services sent from the VAL server to the VAL client are processed similarly. If the grouping instruction specifies that the SEALDD layer needs to perform grouping, the SEALDD server performs the grouping and transmits it via... The SEALDD-UU user plane (e.g., SEALDD / UDP / IP) sends streaming data (e.g., RTP packets) to the SEALDD client. Used for downlink application services. Similarly, the SEALDD client performs packetization and transmits data via the SEALDD-UU user plane (e.g., SEALDD (UDP / IP) sends streaming data (such as RTP packets) to the SEALDD server for uplink application services. The SEALDD server and client also perform PDU set marking (e.g., as defined in 3GPP TS 26.522 [TS26522]). In RTP extensions), and if necessary, perform stream session and transport management (e.g., RTCP, RTSP).

[0369] Note 5: In the grouping mode executed by SEALDD, in order to protect the stream content (e.g., if the VAL service provider...) (VAL is not from the same organization as the SEALDD service provider), VAL can enable payload encryption (e.g., for H.264). NAL-compatible encryption).

[0370] The SEALDD server receives any UE location change notifications using the SEAL LM service defined in Clause 9.3.12 of 3GPP TS 23.434[4], and then performs data transmission in accordance with the geofencing policy. If the UE is in a prohibited location or is not allowed to send / receive data according to the geofencing policy, the SEALDD server performs actions such as releasing the connection and notifies the VAL server using the connection event state procedure that the UE is unreachable because it is in a prohibited location. If the UE enters an allowed location area, the SEALDD server initiates connection establishment using the procedure defined in Clause 9.2.2.3.

[0371] 9.2.2.3 Establishment of Regular Data Transmission Connections Enabled by Policy-Based SEALDD

[0372] The SEALDD server has a data transfer (DD) policy being configured. Before application communication between the VAL client and the VAL server begins, the SEALDD server enforces the DD policy to establish a SEALDD connection.

[0373] Prerequisites:

[0374] 1. The SEALDD server has available DD policies.

[0375] Figure 6a A flowchart illustrating the policies implemented by the SEALDD server regarding connectivity is shown.

[0376] 1. The VAL server uses the procedure defined in Section 9.2.2.6 to subscribe to the SEALDD event open for connection state.

[0377] 2. When the time for data transmission is about to begin, the SEALDD server implements a policy to trigger the establishment of a regular data transmission connection. If spatial conditions for the UE are provided, the SEALDD server also ensures that the UE's location requirements are met when establishing a regular data transmission connection (e.g., by monitoring the UE's location using the NEF service, or by detecting UEs entering the area of ​​interest using the SEAL location service).

[0378] 3. If the SEALDD user plane service has specific routing requirements (e.g., running on a specific slice and DNN), the SEALDD server interacts with the 3GPP CN to provide NEF with service-specific parameters as described in Clauses 4.15.6.10 and 4.15.6.7 of 3GPP TS 23.502[6].

[0379] If there are QoS requirements in the DD policy, the SEALDD server will also apply QoS to ensure the quality of the SEALDD service by utilizing NEF / PCF / NRM / EES services for QoS adjustment. Specifically, if the SEALDD server is connected to the PCF via the N5 reference point, the SEALDD server relies on the northbound policy authorization service API opened by the PCF as specified in 3GPP TS 23.502[6] and 3GPP TS 23.503[7], or if the SEALDD service is connected to the PCF via the NEF, the SEALDD service relies on the northbound QoS-enabled AF session service API and / or PFD management northbound API opened by the NEF as specified in 3GPP TS 23.502[6] and 3GPP TS 23.503[7]. SEALDD may also rely on EES Session API with QoS as specified in 3GPP TS 23.558

[10] and / or NRM QoS features as described in 3GPP TS 23.434[4]. For Using multimodal services, the SEALDD server derives auxiliary information related to the PDU set based on the VAL service ID and / or VAL server ID. Information for interaction with NEF / PCF .

[0380] Editor's Note: For the SEALDD layer, it is a tunnel (e.g., SEALDD / UDP / IP) that wraps the packet from the VAL service. Multimodal service data (e.g., RTP packets) for both server and client. How does the SEALDD server provide this data in a QoS-enabled session API? 5GC indicates that the tunneling protocol description needs to be coordinated with SA2.

[0381] If the DD policy specifies fault detection reports, the SEALDD server can subscribe to CN analysis (such as DN performance analysis) from NEF / NWDAF, and based on the analysis results, further notify the VAL client (via the SEALDD client) and the VAL server of the data transmission status of the application service.

[0382] 4. The SEALDD server assigns an IP address and port for sending and receiving packets through the SEAL-S reference point. Then, the SEALDD server sends a SEALDD connection establishment notification to the VAL server, which includes the VAL service ID, IP address, and port.

[0383] 5-6. The SEALDD server assigns an IP address and port for sending and receiving packets through the SEAL-Uu reference point. Then, the SEALDD server sends a regular data transmission connection establishment request to the SEALDD client with the SEALDD stream ID, VAL service ID, IP address, and port. The SEALDD server can retrieve data from the regular SEALDD transport connection establishment request during the SEALDD regular transport connection establishment request. The protocol description received by the VAL server is sent to the SEALDD client.The SEALDD client responds to the request. If a different UE IP address will be used in the SEALDD connection user plane, the SEALDD client can include the UE IP address (and port) in the response, or the SEALDD client can send the UE IP address (and port) in a separate update message.

[0384] Note 1: Steps 4 and 5 can be executed in parallel.

[0385] Note 2: Step 5 can be sent via a PDU session (if one exists) or via application trigger (if no PDU session exists).

[0386] 7. The SEALDD client further notifies the VAL client of the SEALDD connection that is being established.

[0387] After receiving application traffic from the VAL client (not shown in the diagram), the SEALDD client sends it to the SEALDD server within the SEALDD traffic. The SEALDD server identifies the application traffic based on the VAL service ID and further forwards it to the VAL server. Downlink application traffic sent from the VAL server to the VAL client is processed similarly. like If the grouping instruction specifies that the SEALDD layer needs to perform grouping, then the SEALDD server performs grouping and transmits it via SEALDD- UU user plane (e.g., SEALDD / UDP / IP) sends streaming data (e.g., RTP packets) to SEALDD clients for downlink use. Link application services. Similarly, the SEALDD client performs packetization and transmits data via the SEALDD-UU user plane (e.g., SEALDD / ). UDP / IP sends streaming data (e.g., RTP packets) to the SEALDD server for uplink application services. SEALDD The server and client also perform PDU set marking (e.g., as defined in 3GPP TS 26.522 [TS26522] for RTP extensions). (in the middle), and if necessary, perform stream session and transport management (e.g., RTCP, RTSP).

[0388] Note 3: In the grouped mode executed by SEALDD, in order to protect the stream content (e.g., if the VAL service provider...) (VAL is not from the same organization as the SEALDD service provider), VAL can enable payload encryption (e.g., for H.264). NAL-compatible encryption).

[0389] 9.3.2.1 E2E Redundant Transmission Path Establishment Process

[0390] Figure 6b A flowchart illustrating the process for establishing redundant transmissions is shown. This process can be triggered by the VAL server for data transmission during each application-layer transaction.

[0391] Prerequisites:

[0392] 1. The VAL server has discovered and selected the SEALDD server through the CAPIF function as specified in Section 9.4.2.

[0393] 2. The VAL server has established an application connection with the VAL client and can obtain the VAL client's UE ID or UE address through this application connection.

[0394] Figure 6b The steps are as follows.

[0395] 1. The VAL server decides to use the SEALDD service to help ensure the data transmission quality of application services and sends an Sdd_URLLCTransmission request to the SEALDD server discovered by CAPIF. This request includes the UE ID / address, VAL server ID, VAL service ID, SEALDD-S data transmission connection information on the VAL server side, and optionally, Agreement Description Narrative QoS information used for application services, such as QoS requirements. VAL server ID and VAL service ID can be used to identify VAL application services.

[0396] 2. Upon receiving the request, the SEALDD server decides to establish redundant transmission paths. The SEALDD server assigns two different addresses or ports to the two redundant transmission paths and sends an AF request to the 5GS to create or update URSP rules for one or more UEs that will use the redundant transmission service, as described in Clause 4.15.6.10 of 3GPP TS 23.502 [6]. The AF request includes the identifier of one or more UEs and an application service descriptor containing the address or port assigned by the SEALDD server. The SEALDD server may send the AF request to the 5GC via N33 / N5 to provide the required QoS information, as described in Clauses 5.2.6.9 and 5.2.5.3 of 3GPP TS 23.502 [6]. For applications Multimodal service, SEALDD server derives two redundant transmission paths based on VAL service ID and / or VAL server ID. The PDU set contains auxiliary information for interaction with NEF / PCF. .

[0397] Editor's Note: For the SEALDD layer, it is a tunnel (e.g., SEALDD / UDP / IP) that wraps the packet from the VAL service. Multimodal service data (e.g., RTP packets) for both server and client. How can the SEALDD server provide session APIs with QoS? The 5GC-directed tunneling protocol description requires coordination with SA2. .

[0398] 3. If the request is successfully processed, the SEALDD server assigns its address / port as the SEALDD-S data transfer connection information on the SEALDD server side. This address / port is used to receive packets from the VAL server for application data transfer. The SEALDD server responds with a SEALDD service response (including the SEALDD-S data transfer connection information on the SEALDD server side) and instructs the VAL server that redundant transfer services should be activated. The VAL server and SEALDD server can use the SEALDD-S data transfer connection information to establish a data transfer connection between themselves for application data transfer.

[0399] 4. If the redundant transport requirement is not pre-configured or notified to the VAL client, the VAL server can notify one or more VAL clients that will use the redundant transport service via application layer messages.

[0400] Note 1: Application signaling can be sent via direct application layer connection or via SEALDD layer.

[0401] Note 2: The VAL client can be pre-configured: VAL services should always be transmitted via redundant transmission. Alternatively, this application layer notification can be sent to the UE at a different time before the VAL application service is actually sent.

[0402] 5. The VAL client sends a SEALDD service request to use E2E redundant transmission for application services.

[0403] 6. The SEALDD client, in accordance with Section 9.4.3, discovers and selects a suitable SEALDD server for the VAL application. After this step, the SEALDD client obtains the address of the SEALDD server.

[0404] 7. The SEALDD client assigns a SEALDD flow ID mapped to the application service. The SEALDD client sends an Sdd_URLLCTransmissionConnection_Establish request to the SEALDD server. This request includes the SEALDD client ID, SEALDD flow ID, VAL server ID, and VAL service ID, which the SEALDD server uses to identify the specific application service.

[0405] 8. Upon receiving the request, the SEALDD server sends the SEALDD service descriptor for redundant transmission (i.e., the address or port allocated in step 2 for the redundant transmission path and the transmission protocol for the SEALDD service) to the SEALDD client. The SEALDD server can retrieve VAL from the SEALDD URLLC transport connection establishment response. The server sends the received protocol description to the SEALDD client. .

[0406] 9. The UE uses the SEALDD service descriptor of the SEALDD server and the created or updated URSP rules to trigger two redundant PDU session establishment processes via 5GS, as specified in Clause 5.33.2.1 of 3GPP TS 23.501[5].

[0407] 10. [Optional] The SEALDD client sends an Sdd_URLLCTransmissionConnection_Update request to the SEALDD server. This request includes the SEALDD client ID, the SEALDD stream ID, and the SEALDD service descriptor on the SEALDD client side for redundant transmission (i.e., the UE address and port of the two redundant PDU sessions). The two redundant SEALDD services use the same SEALDD stream ID for identification.

[0408] 11. [Optional] The SEALDD server sends a response to the SEALDD client. After this step, both the SEALDD client and the SEALDD server obtain the complete SEALDD service descriptor (including the address / port of the UE used for SEALDD service transmission and the address / port of the SEALDD server). The SEALDD client and the SEALDD server store the mapping between application services and SEALDD services.

[0409] 12. [Optional] If the connection between the VAL server and the SEALDD server is not established in step 3, the SEALDD server establishes a connection with the VAL server so that the VAL client can send application services mapped to the redundant SEALDD service according to the SEALDD-S information negotiated in steps 1-3.

[0410] Note 3: Steps 10 and 11 are optional. If a redundant PDU session has been established before step 7, the UE's IP address can be notified to the SEALDD server in step 7. In other cases, after establishing two redundant PDU sessions, the SEALDD client can communicate with the SEALDD server through the redundant PDU sessions to inform the SEALDD server of one or more addresses of the UE in the redundant PDU sessions, thereby completing the service mapping. Alternatively, the SEALDD client and SEALDD server can use other mapping mechanisms, depending on the transport protocol used by the SEALDD client and SEALDD server for SEALDD services.

[0411] 13. The SEALDD client responds with the SEALDD service response.

[0412] After connection negotiation and establishment, the SEALDD client obtains the mapping information between the application service and the SEALDD flow ID. The SEALDD server obtains the mapping data between the SEALDD flow ID and the SEALDD-S connection. After receiving the application service from the VAL client, the SEALDD client replicates the application packet and maps it to two SEALDD service flows with SEALDD service descriptors, which are negotiated with the SEALDD server as in steps 8 and 10. The two SEALDD services are sent to the SEALDD server through two redundant PDU sessions. The SEALDD server maps the two SEALDD services to the same application service based on the stored SEALDD service descriptors, SEALDD client ID, and SEALDD flow ID. After packet deduplication and reordering, the SEALDD server sends the aggregated application service to the VAL server via the connection established in step 3 based on the mapping information. Downlink application services sent from the VAL server to the VAL client are processed similarly. If the grouping instruction specifies that the SEALDD layer needs to perform grouping, then the SEALDD server performs the grouping and... Streaming data (e.g., RTP packets) is sent from the SEALDD-UU user plane (e.g., SEALDD / UDP / IP) to the SEALDD client. This is used for downlink application services. Similarly, the SEALDD client performs packetization and transmits data via the SEALDD-UU user plane (e.g., ...). For example, SEALDD / UDP / IP sends streaming data (such as RTP packets) to the SEALDD server for uplink applications. The SEALDD server and client also perform PDU set marking (e.g., as defined in 3GPP TS 26.522 [TS26522]). In the RTP extension), and if necessary, perform stream session and transport management (e.g., RTCP, RTSP).

[0413] Note 4: In the grouping mode executed by SEALDD, in order to protect the stream content (e.g., if the VAL service provider...) (VAL is not from the same organization as the SEALDD service provider), VAL can enable payload encryption (e.g., for H.264). NAL-compatible encryption).

[0414] 9.3.2.2 Client-initiated E2E redundant transmission path establishment process

[0415] Figure 6c A flowchart is shown for the process of establishing redundant transports initiated by the client, which is used for data transmission for each application layer transaction.

[0416] Prerequisites:

[0417] 1. When a VAL client initiates a redundant transport service, the SEALDD client is authorized to request the redundant transport service on behalf of the VAL client.

[0418] Figure 6c The steps are as follows.

[0419] 1. The VAL client determines to use the SEALDD service to ensure the data transmission quality required for application services and sends a service request to the SEALDD client.

[0420] 2. Upon receiving the request, the SEALDD client determines whether to establish a redundant transmission path based on QoS requirements. The SEALDD client discovers and selects a suitable SEALDD server for the VAL application, as specified in Section 9.4.3.

[0421] 3. The SEALDD client sends a request to the SEALDD server to configure redundant transmission for the application service. The SEALDD client assigns a SEALDD flow ID mapped to the application service. The SEALDD client sends an Sdd_URLLCTransmissionConnection_Establish request to the SEALDD server. This request includes the SEALDD client ID, SEALDD flow ID, application ID, UE ID / address, VAL server ID / address, QoS requirements, UE location, and a request for redundant transmission. The SEALDD client can receive the protocol description from the VAL client in the SEALDD URLLC transport connection establishment request. Send to SEALDD server .

[0422] 4. The SEALDD server allocates IP addresses and ports for redundant transmission paths and initiates a process to the 5G network for application guidance for URSP determination to create or update URSP rules for the UE, as described in Clause 4.15.6.10 of 3GPP TS 23.502[6]. The request includes the UE ID and an application service descriptor containing the address or port allocated by the SEALDD server. The UE receives new or updated URSP rules from the 5G core network. For applications of multimodal The service, SEALDD server, derives a PDU set for two redundant transport paths based on the VAL service ID and / or VAL server ID. Related auxiliary information for interaction with NEF / PCF .

[0423] 5. The SEALDD server responds to the SEALDD client, providing the configuration status. The response includes the IP address and port assigned in step 4 for redundant transmission paths. The SEALDD client and SEALDD server store the mapping between application services and SEALDD services.

[0424] 6. The UE establishes redundant PDU sessions with the 5G network using new or updated URSP rules, as specified in Clause 5.33.2.1 of 3GPP TS 23.503[5].

[0425] 7. [Optional] The SEALDD client sends an Sdd_URLLCTransmissionConnection_Update request to the SEALDD server. This request includes the SEALDD client ID, the SEALDD stream ID, and the application service descriptor for redundant transmission on the SEALDD client side (i.e., the UE address and port of the two redundant PDU sessions). The two redundant SEALDD services use the same SEALDD stream ID for identification.

[0426] 8. [Optional] The SEALDD server establishes a connection with the VAL server for the VAL client to send application services mapped to redundant SEALDD services. The SEALDD server sends a response to the SEALDD client. After this step, both the SEALDD client and the SEALDD server obtain application service descriptors (including the address / port of the UE used for SEALDD service transmission and the address / port of the SEALDD server). The SEALDD client and the SEALDD server store the mapping between application services and SEALDD services.

[0427] 9. SEALDD customers respond with SEALDD service responses.

[0428] Note 1: Details of the VAL client service request in step 1 and the corresponding response in step 9 are not within the scope of the current specification.

[0429] The VAL client sends application traffic to the SEALDD client, which replicates the application data on a redundant PDU session. The SEALDD server receives the redundant traffic and reassembles the data before sending it to the VAL server. Similarly, the SEALDD server replicates downlink traffic from the VAL server and sends the data to the SEALDD client on a redundant PDU session. The SEALDD client removes the redundant data and reassembles it before sending it to the VAL client. If grouping instruction If it is specified that the SEALDD layer needs to perform packetization, then the SEALDD server performs packetization and transmits it through the SEALDD-UU user plane (e.g., ...). For example, SEALDD / UDP / IP sends streaming data (such as RTP packets) to SEALDD clients for downlink applications. Similarly, the SEALDD client performs packetization and sends packets via the SEALDD-UU user plane (e.g., SEALDD / UDP / IP) to... The SEALDD server sends streaming data (such as RTP packets) for uplink application services. The SEALDD server and the client... The client also performs PDU set marking (e.g., as in the RTP extensions defined in 3GPP TS 26.522 [TS26522]), and as... If necessary, perform stream session and transport management (e.g., RTCP, RTSP).

[0430] Note 2: In the grouping mode executed by SEALDD, in order to protect the stream content (e.g., if the VAL service provider...) (VAL is not from the same organization as the SEALDD service provider), VAL can enable payload encryption (e.g., for H.264). NAL-compatible encryption).

[0431] 9.3.2.3 Policy-based SEALDD-enabled URLLC transport connection establishment

[0432] The SEALDD server has a data delivery (DD) policy being configured. The DD policy includes reliable transport services for associated VAL services. Before application communication between the VAL client and the VAL server begins, the SEALDD server implements the DD policy to establish a SEALDD connection.

[0433] Prerequisites:

[0434] 1. The SEALDD server has available DD policies.

[0435] Figure 6dA flowchart is shown of the strategy for redundant connectivity implemented by the SEALDD server.

[0436] This process is the same as steps 1 to 7 in Section 9.2.2.3, except that:

[0437] - In step 2, the SEALDD server implements a policy to trigger the establishment of a URLLC transport connection.

[0438] - In steps 5 and 6, the SEALDD server allocates dual IP addresses and ports for sending and receiving packets through the SEALDD-UU reference point. Then, the SEALDD server sends a URLLC transport connection establishment request to the SEALDD client, which has the SEALDD stream ID, VAL service ID, dual IP addresses and ports. The SEALDD server can transmit links via SEALDD URLLC. The protocol description received from the VAL server is sent to the SEALDD client in the establishment request. The request is responded to by the SEALDD client. If different UE IP addresses will be used in the SEALDD connection user plane, the SEALDD client can include both UE IP addresses (and ports) in the response, or the SEALDD client can send both UE IP addresses (and ports) in a separate update message.

[0439] 9.2.3.1 Regular transport requests enabled by SEALDD

[0440] Table 9.2.3.1-1 describes the information flow from the VAL server to the SEALDD server for requesting regular application transport services.

[0441] Table 9.2.3.1-1: Regular transport requests enabled by SEALDD

[0442]

[0443] 9.2.3.7 SEALDD Connection State Subscription Request

[0444] Table 9.2.3.7-1 describes the information flow from the VAL server to the SEALDD server for subscribing to SEALDD connection state information.

[0445] Table 9.2.3.7-1: SEALDD Connection State Subscription Request

[0446]

[0447] 9.2.3.3 SEALDD Regular Transport Connection Establishment Request

[0448] Table 9.2.3.3-1 describes the information flow from the SEALDD client to the SEALDD server or from the SEALDD server to the SEALDD client, used to request the establishment of a regular SEALDD connection.

[0449] Table 9.2.3.3-1: SEALDD Regular Transport Connection Establishment Request

[0450]

[0451] 9.2.3.4 SEALDD Regular Transport Connection Establishment Response

[0452] Table 9.2.3.4-1 describes the information flow from the SEALDD server to the SEALDD client or from the SEALDD client to the SEALDD server, used to respond to the establishment of a regular SEALDD connection.

[0453] Table 9.2.3.4-1: SEALDD Regular Transport Connection Establishment Response

[0454]

[0455] 9.3.3.3 SEALDD URLLC Transport Connection Establishment Request

[0456] Table 9.3.3.3-1 describes the information flow from the SEALDD client to the SEALDD server or from the SEALDD server to the SEALDD client, used to request the establishment of a URLLC transport connection.

[0457] Table 9.3.3.3-1: SEALDD URLLC Transport Connection Establishment Request

[0458]

[0459] 9.3.3.4 SEALDD URLLC Transport Connection Establishment Response

[0460] Table 9.3.3.4-1 describes the information flow from the SEALDD server to the SEALDD client or from the SEALDD client to the SEALDD server, used to respond to the establishment of a URLLC transport connection.

[0461] Table 9.3.3.4-1: SEALDD URLLC Transport Connection Establishment Response

[0462]

Claims

1. A method (300) executed by a first application function entity, comprising: Receive (302) a first message from the second application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information includes uplink protocol description information and / or downlink protocol description information. The data service mentioned above is used for multimodal services. The first protocol description information includes information indicating the label of the Protocol Data Unit (PDU) set.

2. The method according to claim 1, further comprising: Receive the data service (312) from the second application function entity; Perform (314) packetization on the data service; as well as Based on the information indicating the PDU set marking, perform (316) PDU set marking to include the PDU set information in the packetized data service.

3. The method according to claim 2, further comprising: The first application function entity receives (322) a packetization instruction from the second application function entity, the packetization instruction indicating whether the first application function entity needs to perform packetization on the data service. The process of grouping the data service further includes: when the grouping instruction indicates that the first application function entity needs to group the data service, the data service is grouped.

4. The method according to claim 3, wherein, The grouping indication is included in the first protocol description information.

5. The method according to any one of claims 2-4, wherein, The PDU set information is included in the header extension of the grouped data service.

6. The method according to any one of claims 2-5, further comprising: Derive (342) at least one PDU set of Quality of Service (QoS) parameters from the identifier of the service and / or the identifier of the application functional entity providing the service; as well as Using the process of establishing an application function session with the required QoS, send (344) the at least one set of PDU QoS parameters to the network open node or policy control node.

7. The method according to any one of claims 2-6, further comprising: Obtain (352) second protocol description information for transmitting the packetized data service containing PDU set information using a tunneling protocol. The second protocol description information includes uplink protocol description information and / or downlink protocol description information.

8. The method according to claim 7, wherein, Obtaining the second protocol description information includes at least one of the following: When the first application function entity is a SEALDD server, the second protocol description information is determined automatically. When the first application function entity is a SEALDD client, it automatically determines the second protocol description information. When the first application function entity is a SEALDD client, it receives the second protocol description information directly or via the vertical application layer VAL server and VAL client from the SEALDD server, or When the first application function entity is a SEALDD server, the second protocol description information is received directly from the SEALDD client or via the VAL client and the VAL server.

9. The method according to claim 7 or 8, wherein, The second protocol description information includes at least one of the following: Information indicating the use of the tunneling protocol in the transmission of the packetized data service. The header length of the tunneling protocol, The offset of the tunneling protocol's payload. The location of the PDU set information, or The offset position information in the header of the tunneling protocol.

10. The method according to any one of claims 7-9, further comprising: When the first application function entity is a business enablement architecture layer data transmission SEALDD server for vertical industries, the second protocol description information (362) is sent to at least one of the SEALDD client, network open node, or policy control node.

11. The method according to any one of claims 7-9, further comprising: When the first application function entity is a SEALDD client, the second protocol description information (372) is sent to at least one of the SEALDD server, network open node, or policy control node.

12. The method according to any one of claims 7-9, further comprising: When the first application function entity is a SEALDD client, the second protocol description information (382) is sent to the access network protocol layer entity of the terminal device.

13. The method according to any one of claims 1-12, wherein, The data service is encrypted by the second application function entity and cannot be decrypted by the first application function entity.

14. The method according to any one of claims 1-13, wherein The first application functional entity is a SEALDD server, and the second application functional entity is a vertical application layer VAL server. The first application functional entity is a SEALDD client, and the second application functional entity is a VAL client, or The first application function entity is a SEALDD server, and the second application function entity is a SEALDD client, or The first application function entity is a SEALDD client, and the second application function entity is a SEALDD server.

15. The method according to any one of claims 1-14, wherein, The first message includes at least one of the following: One or more regular transport requests enabled by SEALDD. One or more SEALDD connection state subscription requests, One or more SEALDD service requests, One or more SEALDD regular transport connection establishment requests, One or more SEALDD regular transport connection establishment responses, One or more SEALDD Ultra-Reliable Low-Latency Communication (URLLC) transport connection establishment requests, or One or more SEALDD URLLC transport connection establishment responses.

16. A method (400) performed by a second application function entity, comprising: Send a (402) first message to the first application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information includes uplink protocol description information and / or downlink protocol description information. The data service mentioned above is used for multimodal services. The first protocol description information includes information indicating the labeling of the Protocol Data Unit (PDU) set.

17. The method of claim 16, further comprising: Send the data service (412) to the first application function entity.

18. The method of claim 17, further comprising: Send a (422) grouping instruction to the first application function entity, the grouping instruction indicating whether the first application function entity needs to perform grouping on the data service.

19. The method according to claim 18, wherein, The grouping indication is included in the first protocol description information.

20. The method of claim 16, further comprising: When the second application function entity is a SEALDD server, it receives (442) second protocol description information from the SEALDD client for transmitting packetized data services including PDU set information using a tunneling protocol, wherein the second protocol description information includes uplink protocol description information and / or downlink protocol description information; and Send (444) the second protocol description information to at least one of the network open nodes or policy control nodes.

21. The method of claim 16, further comprising: When the second application function entity is a SEALDD client, it receives (452) second protocol description information from the SEALDD server for transmitting packetized data services including PDU set information using a tunneling protocol, wherein the second protocol description information includes uplink protocol description information and / or downlink protocol description information; and Send (454) the second protocol description information to at least one of the network open nodes or policy control nodes.

22. The method according to claim 20 or 21, wherein, The second protocol description information includes at least one of the following: Information indicating the use of the tunneling protocol in the transmission of the packetized data service. The header length of the tunneling protocol, The offset of the tunneling protocol's payload. The location of the PDU set information, or The offset position information in the header of the tunneling protocol.

23. The method according to any one of claims 16-22, wherein, The data service is encrypted by the second application function entity and cannot be decrypted by the first application function entity.

24. The method according to any one of claims 16-23, wherein The first application functional entity is a SEALDD server, and the second application functional entity is a vertical application layer VAL server. The first application functional entity is a SEALDD client, and the second application functional entity is a VAL client, or The first application function entity is a SEALDD server, and the second application function entity is a SEALDD client, or The first application function entity is a SEALDD client, and the second application function entity is a SEALDD server.

25. The method according to any one of claims 16-24, wherein, The first message includes at least one of the following: One or more regular transport requests enabled by SEALDD. One or more SEALDD connection state subscription requests, One or more SEALDD service requests, One or more SEALDD regular transport connection establishment requests, One or more SEALDD regular transport connection establishment responses, One or more SEALDD Ultra-Reliable Low-Latency Communication (URLLC) transport connection establishment requests, or One or more SEALDD URLLC transport connection establishment responses.

26. A first application function entity (700), comprising: Processor (721); and A memory (722) coupled to the processor (721) contains instructions executable by the processor (721), thereby enabling the first application function entity (700) to: A first message is received from the second application function entity. The first message includes first protocol description information for transmitting data services using a transport protocol. The first protocol description information includes uplink protocol description information and / or downlink protocol description information. The data service mentioned above is used for multimodal services. The first protocol description information includes information indicating the label of the Protocol Data Unit (PDU) set.

27. The first application function entity according to claim 26, wherein, The first application functional entity is further operable to perform the method of any one of claims 2 to 15.

28. A second application function entity (700), comprising: Processor (721); and A memory (722) coupled to the processor (721) contains instructions executable by the processor (721), thereby enabling the second application function entity (700) to: A first message is sent to the first application function entity, the first message including first protocol description information for transmitting data services using a transport protocol. The first protocol description information includes uplink protocol description information and / or downlink protocol description information. The data service mentioned above is used for multimodal services. The first protocol description information includes information indicating the labeling of the Protocol Data Unit (PDU) set.

29. The second application functional entity according to claim 28, wherein, The second application functional entity is further operable to perform the method of any one of claims 17 to 25.

30. A computer-readable storage medium storing instructions, which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 25.

31. A computer program product comprising instructions, which, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 25.

Images