Method and apparatus for service processing

Abstract

Embodiments of the present disclosure provide method and apparatus for service processing. A method performed by a first application functional entity may comprise obtaining second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. The second protocol description information comprises uplink protocol description information and / or downlink protocol description information. The method may comprise sending the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device.

Description

METHOD AND APPARATUS FOR SERVICE PROCESSINGTECHNICAL FIELDThe non-limiting and exemplary embodiments of the present disclosure generally relate to the technical field of communications, and specifically to methods and apparatuses for service processing.BACKGROUNDThis section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.In communication networks such as fifth generation system (5GS) as defined by 3rd Generation Partnership Project (3GPP) , various services may be required to be supported. For example, multi-modal services may be required to be supported in Service Enablement Architecture Layer for Verticals (SEAL) .Since 3GPP Release 16, SEAL has been introduced to support vertical applications (e.g. vehicle-to-everything (V2X) applications) . 3GPP Technical Specification (TS) 23.434 V19.0.0, the disclosure of which is incorporated by reference herein in its entirety, specifies application plane and signaling plane entities for application-enabling services (e.g. group management, configuration management, location management, identity / key management, network resource management) that can be reused across vertical applications. SEAL also specifies the northbound Application Programming Interfaces (APIs) for its individual services to enable flexible integration with vertical applications.Multi-modal services may comprise several data flows (named as multi-modal flows) that related to each other and may come from different sources. Each data flow (single-modal data) may be seen as one type of data (for example audio, video, positioning, haptic data) associated with the same communication service. Data flows that comprise a multi-modal service may come from a single user equipment (UE) , either via a single device or via multiple devices connected to the single UE that can access the 5GS, or from multiple UEs.SUMMARYThis summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.In the latest 3GPP Release 19 study for Extended Reality (XR) (e.g. 3GPP TR 23.700-23 v0.1.0 clause 4.2) , “KI for E2E Multi-Modal Communication Flows” , S6-234107, 3GPP TSG-SA WG6 Meeting #58, mentions further gaps in ensuring XR traffic transmission quality. The open issue list says the following aspects:Whether and how to support the end to end (E2E) multi-modal communication flows between application clients and application servers within the application enablement layer?Whether and how to support the interaction between the application enablement layer and fifth generation (5G) core network (CN) to manage E2E multi-modal communication flows between application clients and application servers?Whether and how Service Enabler Architecture Layer for verticals Data Deliver (SEALDD) may be enhanced to assist in managing E2E multi-modal communication flows between application clients and application servers involved in the same application service (e.g., support for multi-modal aware SEALDD flow management and policies) ?SEALDD was specified since 3GPP Release-18, the user plane protocol stack over 5GS is depicted in FIG. 2b. The application content including SEALDD layer information and Vertical Application Layer (VAL) payload are transferred between the SEALDD client in the UE and the SEALDD server in the data network.Protocol data unit (PDU) layer corresponds to the PDU carried between the UE and the data network (DN) over the PDU Session. E. g. User Datagram Protocol (UDP)  / Internet Protocol (IP) , transmission control protocol (TCP)  / IP, Quick UDP Internet Connections (QUIC)  / UDP / IP.For downlink (DL) data, without using SEALDD, after application function (AF) informs the network such as 5G core network (5GC) about the protocol description via Setting up required quality of service (QoS) procedure, user plane function (UPF) can mark PDU set information in General Packet Radio Service (GPRS) Tunneling Protocol (GTP) based on received protocol extension, e.g., Real Time Protocol (RTP) . Then during access network (AN) congestion, 5G-radio access network (RAN) and / or UPF will perform specific packet handling (e.g. drop, re-transmit) for PDU in a PDU set and also for PDU sets in the same Service Data Flow (SDF) based on PDU set information in GTP.When SEALDD is used, a user plane (e.g. UPF or the access network protocol layer entity of the terminal device) knows nothing about the existence of SEALDD. So that packet inspection and classification cannot be performed properly by the user plane. The user plane cannot mark PDU set information.To overcome or mitigate at least one of above mentioned issues or other issues, the embodiments of the present disclosure propose a solution for service processing.In a first aspect of the disclosure, there is provided a method performed by a first application functional entity. The method may comprise obtaining second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. The method may comprise sending the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a second aspect of the disclosure, there is provided a method performed by a network exposure node. The method may comprise receiving, from a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. The method may comprise sending the second protocol description information to a policy control node. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a third aspect of the disclosure, there is provided a method performed by a policy control node. The method may comprise receiving, from a first application functional entity or a network exposure node, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol. The method may comprise sending the second protocol description information to a session management node. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a fourth aspect of the disclosure, there is provided a method performed by a session management node. The method may comprise receiving, from a policy control node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. The method may comprise sending the second protocol description information to a user plane function and / or an access network protocol layer entity of a terminal device. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a fifth aspect of the disclosure, there is provided a method performed by an access network protocol layer entity of a terminal device. The method may comprise receiving, from a session management node or a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. The method may comprise receiving the packeted data traffic including the PDU set information transmitted using the tunneling protocol. The method may comprise processing the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a sixth aspect of the disclosure, there is provided a method performed by a user plane function. The method may comprise receiving, from a session management node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. The method may comprise receiving the packeted data traffic including the PDU set information transmitted using the tunneling protocol. The method may comprise processing the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a seventh aspect of the disclosure, there is provided a first application functional entity. The first application functional entity may comprise a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said first application functional entity is operative to obtain second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. Said first application functional entity is operative to send the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an eighth aspect of the disclosure, there is provided a network exposure node. The network exposure node comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said network exposure node is operative to receive from a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. Said network exposure node is operative to send the second protocol description information to a policy control node. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a ninth aspect of the disclosure, there is provided a policy control node. The policy control node comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said policy control node is operative to receive, from a first application functional entity or a network exposure node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. Said policy control node is operative to send the second protocol description information to a session management node. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a tenth aspect of the disclosure, there is provided a session management node. The session management node comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said session management node is operative to receive, from a policy control node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. Said session management node is operative to send the second protocol description information to a user plane function and / or an access network protocol layer entity of a terminal device. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an eleventh aspect of the disclosure, there is provided an access network protocol layer entity of a terminal device. The access network protocol layer entity comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said access network protocol layer entity is operative to receive, from a session management node or a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. Said access network protocol layer entity is operative to receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol. Said access network protocol layer entity is operative to process the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a twelfth aspect of the disclosure, there is provided a user plane function. The user plane function comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said user plane function is operative to receive, from a session management node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol. Said user plane function is operative to receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol. Said user plane function is operative to process the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information. The second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In a thirteenth aspect of the disclosure, there is provided a computer program product comprising instructions which when executed by at least one processor, cause the at least one processor to perform the methods according to any one of the first to sixth aspects.In a fourteenth aspect of the disclosure, there is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to perform the methods according to any one of the first to sixth aspects.Embodiments herein may provide many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, it may reduce complexity for the second application functional entity such as VAL client and VAL server. For example, the second application functional entity can only transfer media raw data such as H. 264 to the first application functional entity such as SEALDD server or SEALDD client and the first application functional entity will handle the rest such as packetization, PDU set marking, or RTCP and RTSP data control. In some embodiments herein, it may enable the first application functional entity such as SEALDD server to derive PDU set related assistance information when interacting with 3GPP core network. In some embodiments herein, it may enable the first application functional entity such as SEALDD server or SEALDD client to handle packetization, PDU set marking (e.g. in RTP extension) , and RTCP and RTSP control, to offload the second application functional entity such as VAL client and VAL server. In some embodiments herein, it may solve the issue: when SEALDD application layer is used, how to inform, a user plane function and / or an access network protocol layer entity of a terminal device, information indicating that the tunneling protocol is used in transmission of the packeted data traffic and tunneling protocol information. In some embodiments herein, it may enable the user plane function and / or the access network protocol layer entity of the terminal device to handle the data of the tunneling protocol correctly. In some embodiments herein, it can protect the stream content e.g. if VAL service provider and SEALDD service provider are not from the same organization. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.For any aspect of the disclosure, in the prior art such as 3GPP TS 23.433 V19.0.0, the protocol description information does not comprise tunneling protocol description information. When the tunneling protocol is used, a user plane function and / or the access network protocol layer entity know nothing about the existence of the tunneling protocol. So that the user plane function and / or the access network protocol layer entity can not correctly identify the packeted data traffic and proceed with identifying the PDU set information. In this embodiment, it may inform the user plane function and / or the access network protocol layer entity via the third application functional entity, the network exposure node, or the policy control node, the second protocol description information, which may enable the user plane function and / or the access network protocol layer entity to correctly identify the packeted data traffic and proceed with identifying the PDU set information.The information indicating that the tunneling protocol is used in transmission of the packeted data traffic may enable the user plane function and / or the access network protocol layer entity of the terminal device to know that the tunneling protocol is used in transmission of the packeted data traffic and then it can correctly identify the packeted data traffic and proceed with identifying the PDU set information.The header length of the tunneling protocol may enable the user plane function and / or the access network protocol layer entity of the terminal device to know the location of the packeted data traffic and then it can correctly identify the packeted data traffic and proceed with identifying the PDU set information.The offset of payload of the tunneling protocol and the offset position information in a header of the tunneling protocol may enable the user plane function and / or the access network protocol layer entity of the terminal device to know the location of the packeted data traffic and then it can correctly identify the packeted data traffic and proceed with identifying the PDU set information.The location of the PDU set information may enable the user plane function and / or the access network protocol layer entity of the terminal device to know the location of the PDU set information and then it can correctly identify the PDU set information.In an embodiment, the first application functional entity may be a SEALDD server, it may send the second protocol description information to at least one of a SEALDD client, the network exposure node, or the policy control node to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device. The third application functional entity is the SEALDD client.In this embodiment, it may inform a user plane function and / or an access network protocol layer entity of a terminal device, information indicating that the tunneling protocol is used in transmission of the packeted data traffic and tunneling protocol information, which may enable the user plane function and / or the access network protocol layer entity of the terminal device to correctly identify the packeted data traffic and proceed with identifying the PDU set information.In an embodiment, the first application functional entity may be a SEALDD client, it may send the second protocol description information to at least one of a SEALDD server, the network exposure node or the policy control node, to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device. The third application functional entity is the SEALDD server.In this embodiment, it may inform a user plane function and / or an access network protocol layer entity of a terminal device, information indicating that the tunneling protocol is used in transmission of the packeted data traffic and tunneling protocol information, which may enable the user plane function and / or the access network protocol layer entity of the terminal device to correctly identify the packeted data traffic and proceed with identifying the PDU set information.In an embodiment, the first application functional entity may be a SEALDD client, it may send the second protocol description information to an access network protocol layer entity of a terminal device.In this embodiment, it may inform an access network protocol layer entity of a terminal device, information indicating that the tunneling protocol is used in transmission of the packeted data traffic and tunneling protocol information, which may enable the access network protocol layer entity of the terminal device to correctly identify the packeted data traffic and proceed with identifying the PDU set information.In an embodiment, the first application functional entity may receive from a second application functional entity, a first message comprising first protocol description information for transmission of data traffic using a transport protocol.In the prior art such as 3GPP TS 23.433 V19.0.0, the protocol description information is not transmitted between VAL client and SEALDD client and between VAL server and SEALDD server. Therefore the prior art such as 3GPP TS 23.433 V19.0.0 cannot support the E2E multi-modal communication flows between application clients and application servers within the application enablement layer. Since the protocol description information can be transmitted between VAL client and SEALDD client and between VAL server and SEALDD server, this embodiment can support the E2E multi-modal communication flows between application clients and application servers within the application enablement layer.In an embodiment, the first protocol description information comprises information indicating PDU set marking.In the prior art such as 3GPP TS 23.433 V19.0.0, the information indicating PDU set marking is not transmitted between VAL client and SEALDD client and between VAL server and SEALDD server. Therefore the prior art such as 3GPP TS 23.433 V19.0.0 cannot support PDU set marking in SEALDD server and SEALDD client. Since the PDU set marking can be transmitted between VAL client and SEALDD client and between VAL server and SEALDD server, this embodiment can support the PDU set marking in SEALDD server and SEALDD client.In an embodiment, the first application functional entity may receive the data traffic from the second application functional entity. The method further comprises performing packetization for the data traffic. And it may perform PDU set marking to include PDU set information in the packeted data traffic according to the information indicating PDU set marking.In this embodiment, the packetization may be performed by SEALDD client and SEALDD server, which may reduce complexity for VAL client and VAL server. For example, the VAL client and VAL server can only transfer media raw data such as H. 264 to SEALDD server or SEALDD client and the SEALDD server or SEALDD client will handle the rest such as packetization, PDU set marking, or Real-Time Transport Control Protocol (RTCP) and Real Time Streaming Protocol (RTSP) data control, which can offload VAL client and VAL server.In an embodiment, the first application functional entity may derive at least one PDU set QoS parameter from an identifier of a service and / or an identifier of an application functional entity providing the service.In this embodiment, it may enable the first application functional entity such as SEALDD server to derive the PDU set QoS parameter when interacting with 3GPP core network.In an embodiment, the data traffic may be encrypted by the second application functional entity and cannot be decrypted by the first application functional entity.In this embodiment, it can protect the stream content e.g. if VAL service provider and SEALDD service provider are not from the same organization.BRIEF DESCRIPTION OF THE DRAWINGSThe above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which like reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:FIG. 1a schematically shows generic on-network functional model of SEAL;FIG. 1b schematically shows architecture for SEAL for DD Service;FIG. 2a schematically shows architecture for application traffic transfer;FIG. 2b schematically shows an example of user plane protocol stack over 5GS according to an embodiment of the present disclosure;FIG. 2c schematically shows an example of packetization in SEALDD according to an embodiment of the present disclosure;FIG. 2d schematically shows a high level architecture in a 5G network according to an embodiment of the present disclosure;FIG. 3a, 3b, 3c, 3d, 3e, 3f, 3g, 3h, 3i, 3j, 4a, 4b, 4c, 4d, 4e, 4f, 4g, 4h, 4i, 4j, 4k, 4l, 4m, 4n and 4o show flowcharts of methods according to embodiments of the present disclosure;FIG. 5 shows a flowchart of a procedure for establishing regular SEALDD data transmission connection;FIG. 6a shows a flowchart of Policy enforced by SEALDD server for connectivity;FIG. 6b shows a flowchart of the procedure for redundant transmission establishment;FIG. 6c shows a flowchart of the procedure for client initiated redundant transmission establishment for data transfer per application layer transaction;FIG. 6d shows a flowchart of Policy enforced by SEALDD server for redundant connectivity; andFIG. 7 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure.DETAILED DESCRIPTIONThe embodiments of the present 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 persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.As used herein, the term “network” refers to a network following any suitable communication standards 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 Address (TDMA) , Frequency Division Multiple Access (FDMA) , Orthogonal Frequency-Division Multiple Access (OFDMA) , Single carrier frequency division multiple access (SC-FDMA) and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA) , etc. UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM) . An OFDMA network may implement a radio technology 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 network, wireless sensor network, etc. In the following description, the terms “network” and “system” can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the communication protocols as defined by a standard organization such as 3GPP. For example, the communication protocols may comprise the first generation (1G) , 2G, 3G, 4G, 4.5G, 5G, 6G communication protocols, and / or any other protocols either currently known or to be developed in the future.The term “network device” or “network node” or “network function” refers to any suitable function which can be implemented in a network entity (physical or virtual) of a communication network. For example, the network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. For example, the 5G system (5GS) may comprise a plurality of NFs such as Access and Mobility Management Function (AMF) , and other NFs as shown in FIG. 2d, which will be described later. In other embodiments, the network function may comprise different types of NFs for example depending on a specific network.Virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to a provider edge node and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components (e.g., via one or more applications, components, functions, virtual machines or containers executing on one or more physical processing nodes in one or more networks) .In some embodiments, some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines implemented in one or more virtual environments hosted by one or more of hardware nodes. Further, in embodiments in which the virtual node is not a radio access node or does not require radio connectivity (e.g., a core network node) , then the provider edge node or PE may be entirely virtualized.The functions may be implemented by one or more applications (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc. ) operative to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein. Applications are run in virtualization environment which provides hardware comprising processing circuitry and memory. Memory contains instructions executable by processing circuitry whereby application is operative to provide one or more of the features, benefits, and / or functions disclosed herein.Virtualization environment, comprises general-purpose or special-purpose network hardware devices comprising a set of one or more processors or processing circuitry, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs) , or any other type of processing circuitry including digital or analog hardware components or special purpose processors. Each hardware device may comprise memory which may be non-persistent memory for temporarily storing instructions or software executed by processing circuitry. Each hardware device may comprise one or more network interface controllers (NICs) , also known as network interface cards, which include physical network interface. Each hardware device may also include non-transitory, persistent, machine-readable storage media -having stored therein software and / or instructions executable by processing circuitry. Software may include any type of software including software for instantiating one or more virtualization layers (also referred to as hypervisors) , software to execute virtual machines as well as software allowing it to execute functions, features and / or benefits described in relation with some embodiments described herein.Virtual machines, comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer or hypervisor. Different embodiments of the instance of virtual appliance may be implemented on one or more of virtual machines, and the implementations may be made in different ways.During operation, processing circuitry executes software to instantiate the hypervisor or virtualization layer, which may sometimes be referred to as a virtual machine monitor (VMM) . Virtualization layer may present a virtual operating platform that appears like networking hardware to virtual machine.The term “terminal device” refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE) , or other suitable devices. The UE may be, for example, a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and a playback appliance, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA) , a portable computer, a desktop computer, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE) , a laptop-mounted equipment (LME) , a USB dongle, a smart device, a wireless customer-premises equipment (CPE) and the like. In the following description, the terms “terminal device” , “terminal” , “user equipment” and “UE” may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP (3rd Generation Partnership Project) , such as 3GPP LTE standard or NR standard. As used herein, a “user equipment” or “UE” may not necessarily have a “user” in the sense of a human user who owns and / or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and / or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another terminal device and / or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.References in the specification to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed terms.As used herein unless expressly stated to the contrary, the phrase “at least one of A and B” or “at least one of A or B” should be understood to mean any of the following “only A, only B, or both A and B. ” The phrase “A and / or B” should be understood to mean any of the following “only A, only B, or both A and B” .As used herein unless expressly stated to the contrary, the phrase “a plurality of” followed by a conjunctive list of enumerated items (e.g., “A and B” , “A, B, and C” ) is intended to mean “multiple items, with each item selected from the list consisting of” the enumerated items. For example, “a plurality of A and B” is intended to mean any of the following: more than one A; more than one B; or at least one A and at least one B.The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and / or “including” , when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar / same meanings may also be used.In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.System architecture and protocol stack descriptionAlthough the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a communication system complied with the exemplary system architecture illustrated in FIGs. 1a, 1b, 2a, 2c and 2d. For simplicity, the system architecture of FIGs. 1a, 1b, 2a, 2c and 2d only depict some exemplary elements. In practice, a communication system may further include any additional elements suitable to support communication between terminal devices or between a wireless device and another communication device, such as a landline telephone, a 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 the terminal devices’ access to and / or use of the services provided by, or via, the communication system.FIG. 1a schematically shows generic on-network functional model of SEAL, which is same as Figure 6.2-1 of 3GPP TS 23.434 V19.0.0.Clause 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, the entities within the application plane of the VAL system may comprise VAL client, VAL server, SEAL client, SEAL server and VAL user database, which are examples of “application functional entities” in the present disclosure.The VAL client provides the client side functionalities corresponding to the vertical applications (e.g. V2X client) . The VAL client supports interactions with the SEAL client (s) .The VAL server provides the server side functionalities corresponding to the vertical applications (e.g. V2X application servers) . The VAL server acts as API invoker of Common API Framework for northbound APIs (CAPIF) as specified in 3GPP TS 23.222 V19.0.0.The SEAL client provides the client side functionalities corresponding to the specific SEAL service. The SEAL client (s) supports interactions with the VAL client (s) . The SEAL client also supports interactions with the corresponding SEAL client between the two UEs.The SEAL server provides the server side functionalities corresponding to the specific SEAL service. The SEAL server supports interactions with the VAL server (s) . The SEAL server may act as CAPIF's API exposing function as specified in 3GPP TS 23.222 V19.0.0. The SEAL server may also support interactions with the corresponding SEAL server in distributed SEAL deployments.The reference points for the generic functional model for SEAL are described in the clause 6.5 of 3GPP TS 23.434 V19.0.0.FIG. 1b schematically shows architecture for SEAL for Data Delivery (SEALDD) Service, which is same as Figure 7.2-3 of 3GPP TS 23.433 V19.0.0.The functional entities for SEALDD service are described in the clause 7.3 of 3GPP TS 23.433 V19.0.0.The SEAL data delivery server functional entity acts as the application server for the data delivery enablement. The SEAL data delivery client functional entity acts as the application client for the data delivery enablement.The reference points for the functional model for SEALDD are described in the clause 7.4 of 3GPP TS 23.433 V19.0.0 as below.SEALDD-UU is a reference point between SEALDD client and SEALDD server used to transfer data content and exchange information for SEALDD service provisioning, control, reporting etc.SEALDD-C is a reference point between SEALDD client and VAL client to enable northbound client side API exposed by SEALDD client to VAL client for data delivery and SEALDD service provisioning, control, reporting etc.SEALDD-S is a reference point between SEALDD server and VAL server to enable northbound server side API exposed by SEALDD server to VAL server for data delivery and SEALDD service provisioning, control, reporting etc.SEALDD-E is a reference point enables interactions between two SEALDD servers to transfer data content and exchange information for SEALDD service provisioning, control, reporting etc.N6 is a reference point enables interactions between SEALDD server and fifth generation core network (5GC) to transfer SEALDD traffic packets.N33 / N5 is a reference point enables interactions between SEALDD server and 5GC to send control plane requirements or receive control plane notification for optimized data transmission.For uplink (UL) traffic, VAL client sends application data traffic to SEALDD client for SEALDD service over SEALDD-C. After data plane packet processing by SEALDD client, the application data traffic is converted to SEALDD data traffic and transferred to SEALDD server over SEALDD-UU. The SEALDD server restores the application data traffic and sends it to VAL server over SEALDD-S. For downlink (DL) traffic, VAL server sends application data traffic to SEALDD server for SEALDD service over SEALDD-S. After data plane packet processing by SEALDD server, the application data traffic is converted to SEALDD data traffic and transferred to SEALDD client over SEALDD-UU. The SEALDD client restores the application data traffic and sends it to VAL client over SEALDD-C. Optionally, VAL deployments may choose to route application signaling traffic and application data traffic for some or all functions it offers using SEALDD service and FIG. 1b illustrates the architecture for achieving this. In this case the VAL client and VAL server may choose not to maintain application connection by themselves and transfer all the application traffic over SEALDD connections for those functions.SEALDD capabilities are provided as APIs to the VAL Layer, it is up to VAL layer to decide which traffic to be transferred (e.g. application signaling, application data) .Currently SEALDD lacks the capability to perform E2E measurement and / or synchronization of traffic flows spanning across different SEALDD flows which are used to service different VAL clients and servers. Without this capability, additional complexity and burden will be placed on VAL clients and VAL servers to manage E2E multi-modal communication flows themselves in an over-the-top manner. This can be challenging for real world deployments since applications may be deployed in a distributed manner requiring VAL clients to be hosted on different UEs. Likewise, different VAL servers may be used to service different VAL traffic flows.FIG. 2a schematically shows architecture for application traffic transfer, which is same as Figure 7.2-4 of 3GPP TS 23.433 V19.0.0.The SEAL Data Delivery client interacts with the SEAL data delivery server to establish application layer data transport path.Through this path, the SEALDD server and client provides data transport service capabilities such as data plane packet processing (e.g. packet duplication, elimination or transport coordination) , data forwarding, data caching, background data transfer, etc. to support the VAL server and client.SEALDD connection can be established by either SEALDD client or SEALDD server, as described in clause 9.2 and clause 9.3 of 3GPP TS 23.433 V19.0.0.3GPP TS 23.433 V19.0.0 also specifies some transmission quality assurance methods (e.g., using redundant transmission) , see clause 9.9 of 3GPP TS 23.433 V19.0.0.FIG. 2b schematically shows an example of user plane protocol stack over 5GS according to an embodiment of the present disclosure.The Application content including SEALDD layer information and VAL payload may be transferred between the SEALDD client in the UE and the SEALDD server in the data network.Protocol data unit (PDU) layer corresponds to the PDU carried between the UE and the DN over the PDU Session. The protocol may comprise at least one of UDP / IP, TCP / IP, QUIC / UDP / IP.For downlink (DL) data, PDU Session Anchor (PSA) UPF can mark PDU set information in General Packet Radio Service (GPRS) Tunneling Protocol (GTP) based on received protocol extension, e.g., RTP. Then during access network (AN) congestion, 5G-RAN and / or UPF will perform specific packet handling (e.g. drop, re-transmit) for PDUs in a set and also for PDU sets in the same SDF based on PDU set information in GTP.For UL data, UE lower layer can mark PDU set information in AN-protocol based on received protocol extension, e.g., RTP. Then during access network congestion, 5G-RAN will perform packet handling for PDUs in a set and also for PDU sets in the same Service Data Flow (SDF) based on PDU set information in AN-protocol.The PDU set marking operation may be performed in any other suitable node or function such as a VAL client or a VAL server or SEALDD client or SEALDD server e.g. when the data traffic is to be carried in a tunneling protocol.One example for PDU set information is the “PDU Set Information” defined in 3GPP TS23.501 V18.4.0. The PDU set information may be comprised in any suitable location (such as header or header extension) of packet or data of a protocol (such as transmission protocol) .A PDU Set may comprise one or more PDUs carrying an application layer payload such as a video frame or video slice. PDU Set based Handling is described in clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0. PDU Set Identification is described in clause 5.37.5.2 of 3GPP TS 23.501 V18.4.0. One example for PDU set marking is the “RTP Header Extensions for PDU Set Marking” as defined in clause 4.4.2 of 3GPP TS 26.522 V0.2.0.FIG. 2c schematically shows an example of packetization in SEALDD according to an embodiment of the present disclosure.H. 264 raw data may be [NALU] [NALU] … [NALU] . NALU denotes Network Abstraction Layer (NAL) unit.After SEALDD packetization using RTP (Internet Engineering Task Force (IETF) Request For Comments (RFC) 6184, RFC 7798) , NAL units can be segmented (if size is too large for line transmission) or aggregated (for small NAL units) by SEALDD. SEALDD may also update NALU header.Between the SEALDD client and SEALDD server, the SEALDD payload transferred via SEALDD / UDP / IP includes RTP / RTCP / RTSP data.FIG. 2d schematically shows a high level architecture in a 5G network according to an embodiment of the present disclosure. For example, the fifth generation network may be 5G system (5GS) . The architecture of FIG. 2d may be similar to Figure 4.2.3-1 of 3GPP TS 23.501 V18.4.0, the disclosure of which is incorporated by reference herein in its entirety. The system architecture of FIG. 2d may comprise a plurality of 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 Exposure Function (NEF) , User plane Function (UPF) and Network Repository Function (NRF) , (radio) access network ( (R) AN) , service communication proxy (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.In accordance with an exemplary embodiment, the UE can establish a signaling connection with the AMF over the reference point N1, as illustrated in FIG. 2d. This signaling connection may enable NAS (Non-access stratum) signaling exchange between the UE and the core network, comprising a signaling connection between the UE and the (R) AN and the N2 connection for this UE between the (R) AN and the AMF. The (R) AN can communicate with the UPF over the reference point N3. The UE can establish a protocol data unit (PDU) session to the DN (data network, e.g. an operator network or Internet) through the UPF over the reference point N6.As further illustrated in FIG. 2d, the exemplary system architecture also contains the service-based interfaces such as Nnrf, Nnef, Nausf, Nudm, Npcf, Namf, Nnsacf, Neasdf, Nnssf, Nnwdaf and Nsmf exhibited by NFs such as the NRF, the NEF, the AUSF, the UDM, the PCF, the AMF, the NSACF, the EASDF, the NSSF, the NWDAF and the SMF. In addition, FIG. 2d also shows some reference points such as N1, N2, N3, N4, N6 and N9, which can support the interactions between NF services in the NFs. For example, these reference points may be realized through corresponding NF service-based interfaces and by specifying some NF service consumers and providers as well as their interactions in order to perform a particular system procedure.Various NFs shown in FIG. 2d may be responsible for functions such as session management, mobility management, authentication, security, etc. The AUSF, AMF, DN, NEF, NRF, NSSF, PCF, SMF, UDM, UPF, AF, UE, (R) AN, SCP, NSACF, NSSAAF, EASDF may include the functionality for example as defined in clause 6.2 of 3GPP TS 23.501 V18.4.0.Protocol DescriptionProtocol Description is described in clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0 as bellow.-Protocol Description: Indicates the transport protocol used by the service data flow (e.g. RTP, SRTP) and information, e.g. the following:-RTP

[0185] or SRTP

[0186] ;-RTP or SRTP with RTP Header Extensions, including:-RTP Header Extensions for PDU Set Marking as defined in TS 26.522

[0179] ;-Other RTP Header Extensions as defined RFC 8285

[0189] ;-RTP or SRTP without RTP Header Extensions, but together with RTP Payload Format (e.g. H. 264

[0187] or H. 265

[0188] ) ;-RTP or SRTP with RTP Header Extensions for PDU Set Marking as defined in TS 26.522

[0179] , and together with RTP Payload Format (e.g. H. 264

[0187] or H. 265

[0188] ) ;-RTP or SRTP with other RTP Header Extensions following RFC 8285

[0189] , and together with RTP Payload Format (e.g. H. 264

[0187] or H. 265

[0188] ) .AF provided PDU Set QoS Parameters and Protocol Description may be used in determining the PCC Rule by the PCF as defined in clause 6.1.3.27.4 of TS 23.503

[0045] and the Protocol Description may be used for identifying the PDU Set information by the PSA UPF.For the downlink direction, the PSA UPF identifies PDUs that belong to PDU Sets and marks them accordingly as described in clause 5.37.5.2 of 3GPP TS 23.501 V18.4.0.The SMF instructs PSA UPF to perform PDU Set marking and may provide the PSA UPF the Protocol Description used by the service data flow. The Protocol Description may be received in the PCC rule, based on information provided by the AF or by PCF local policies as described in clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0.Protocol Description (as described in clause 5.37.5 of TS 23.501 V18.4.0) can be included in the AF request in Setting up an AF session with required QoS procedure as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0.Protocol Description (as described in clause 5.37.5 of TS 23.501 V18.4.0) can be included in the Npcf_PolicyAuthorization_Create service operation as described in clause 5.2.5.3.2 of 3GPP TS 23.502 V18.4.0.Protocol Description (as described in clause 5.37.5 of TS 23.501 V18.4.0) can be included in the Nnef_AFsessionWithQoS_Create service operation as described in clause 5.2.6.9.2 of 3GPP TS 23.502 V18.4.0.Methods according to embodiments of the present disclosureFIG. 3a, 3b, 3c, 3d, 3e, 3f, 3g, 3h, 3i and 3j show flowcharts of methods according to embodiments of the present disclosure, which may be performed by an apparatus implemented in or at or as a first application functional entity or communicatively coupled to the first application functional entity. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the methods as well as means or modules or circuits for accomplishing other processes in conjunction with other components.FIG. 3a shows a flowchart of a method according to an embodiment of the present disclosure.At block 302, the first application functional entity may receive from a second application functional entity a first message comprising first protocol description information for transmission of data traffic using a transport protocol.In an embodiment, the first protocol description information may comprise uplink protocol description information and / or downlink protocol description information.The first application functional entity may communicate with any suitable network. For example, the first application functional entity may communicate with the underlying 3GPP network systems using the respective 3GPP interfaces specified by the 3GPP network system. In an embodiment, the first application functional entity may communicate with a fifth generation system (5GS) or a sixth generation system (6GS) as defined by 3GPP.The first application functional entity may be any suitable application functional device or application functional node. For example, the first application functional entity can act as the application server for the data delivery enablement or the application client for the data delivery enablement.In an embodiment, the first application functional entity may be a SEALDD server or a SEALDD client.The second application functional entity may be any suitable application functional device or application functional node. For example, the second application functional entity may can provide the client side functionalities corresponding to the vertical applications (e.g. V2X client) or the server side functionalities corresponding to the vertical applications (e.g. V2X application servers) . The second application functional entity can act as the application server for the data delivery enablement or the application client for the data delivery enablement.In an embodiment, the second application functional entity may be a VAL server or a VAL client or a SEALDD client or a SEALDD server.In an embodiment, the first application functional entity may be a SEALDD server and the second application functional entity may be a VAL server. For example, the SEALDD server may receive the first protocol description information from the VAL server via SEALDD-S.In an embodiment, the first application functional entity may be a SEALDD server and the second application functional entity may be a SEALDD client. For example, the SEALDD client may receive the first protocol description information from the VAL client via SEALDD-C, and then it may send the first protocol description information to the SEALDD server via SEALDD-UU.In an embodiment, the first application functional entity may be a SEALDD client and the second application functional entity may be a VAL client. For example, the SEALDD client may receive the first protocol description information from the VAL client via SEALDD-C.In an embodiment, the first application functional entity may be a SEALDD client and the second application functional entity may be a SEALDD server. For example, the SEALDD server may receive the first protocol description information from the VAL server via SEALDD-S, and then it may send the first protocol description information to the SEALDD client via SEALDD-UU.The data traffic may be data traffic of any suitable service. In an embodiment, the data traffic may be for a multi-modal service. In other embodiment, the data traffic may be for any other suitable service. For example, the data traffic may comprise data traffic of a multi-modal service such as XR. The data traffic may comprise the application data traffic between a SEALDD client and a VAL client or between a SEALDD server and a VAL server. The data traffic between the SEALDD server and the SEALDD client may be called as SEALDD data traffic. In other words, the application data traffic may be converted to SEALDD data traffic and transferred to SEALDD client over SEALDD-UU.For example, XR use cases may comprise multiple types of flows, e.g. video / audio, haptics, sensor data, which are multi-modal communication flows, and these flows are for the multi-modal service XR. These flows may span one or more application servers and clients and may require synchronization and coordination with one another.Many XR use cases may require E2E multi-modal communication flows between application clients and application servers. Using information provided by application clients and servers (e.g., policies) , the application enablement layer, in coordination with the 5GC, can support functionality to assist in managing E2E multi-modal communication flows between application clients and application servers. XR multi-modal traffic flows may need to be synchronized with respect to one another in an E2E manner such that a high quality of experience is provided to the users.The first message may be a new message or an existing message. In an embodiment, the first message may comprise at least one of one or more SEALDD enabled regular transmission requests, one or more SEALDD connection status subscription requests, one or more SEALDD service requests, one or more SEALDD regular transmission connection establishment requests, one or more SEALDD regular transmission connection establishment responses, one or more SEALDD URLLC transmission connection establishment requests, or one or more SEALDD URLLC transmission connection establishment responses for example as described in 3GPP TS 23.433 V19.0.0.The first protocol description information may comprise any suitable information. For example, the first protocol description information may comprise information which can be used to determine PDU Set QoS parameters. The first protocol description information may comprise information indicating whether the first application functional entity needs to perform packetization. The first protocol description information may comprise information indicating PDU set marking. The first protocol description information may comprise header extension information for PDU set marking. The first protocol description information may comprise payload type and format.A PDU set may comprise one or more PDUs carrying an application layer payload such as, e.g. a video frame or video slice. The PDU Set based QoS handling by the network node such as next generation (NG) RAN may be determined by PDU Set QoS Parameters in the QoS profile of the QoS Flow (specified in clause 5.7.7 of 3GPP TS 23.501 V18.4.0) and PDU Set information provided by the PDU Session Anchor (PSA) UPF via N3 / N9 interface as described in clause 5.37.5.2 of 3GPP TS 23.501 V18.4.0. The PDU Set based QoS Handling can be applied for Guaranteed Bit Rate (GBR) and non-GBR QoS Flows.In an embodiment, the first protocol description information may comprise information indicating PDU set marking.In an embodiment, the first protocol description information may comprise format parameters used by a service data flow.In an embodiment, the information indicating PDU Set marking may comprise header extension with PDU Set.For example, the first protocol description information may indicate at least one of transport protocol (e.g. RTP, SRTP) , transport protocol header extensions (e.g. RTP Header Extension for PDU Set Marking 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) used by the service data flow.For example, the first protocol description information may comprise the protocol description of VAL traffic. It may include at least one of 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) .In an embodiment, header extension information may be only applicable when payload indicates RTP.In an embodiment, the first protocol description information may comprise at least one information of the Protocol Description as described in clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0.In an embodiment, the first protocol description information may comprise information about the packetization for the data traffic, e.g. the transport protocol used by the data traffic, transport protocol payload format, etc.The first protocol description information may be obtained by the first application functional entity in various ways.For example, if the second application functional entity is an entity (such as VAL client or VAL server) generating the data traffic, it may generate the first protocol description information by itself and send it to the first application functional entity.For example, the first application functional entity such as SEALDD client may receive the first protocol description information from VAL client. For example, the VAL client may generate the first protocol description information and then send it to the SEALDD client. Alternatively, the VAL client may receive the first protocol description information from the VAL server and then send it to the SEALDD client.For example, the first application functional entity such as SEALDD client may receive the first protocol description information from SEALDD server. For example, the VAL server may generate the first protocol description information or receive it from VAL client, and then send it to the SEALDD server. The SEALDD server may send it to the SEALDD client.For example, the first application functional entity such as SEALDD server may receive the first protocol description information from SEALDD client. For example, the VAL client may generate the first protocol description information or receive it from VAL server, and then send it to the SEALDD client. The SEALDD client may send it to the SEALDD server.For example, the first application functional entity such as SEALDD server may receive the first protocol description information from VAL server. For example, the VAL server may generate the first protocol description information and send it to the SEALDD server. Alternatively the VAL server may receive the first protocol description information from the VAL client and then send it to the SEALDD server.For example, the first application functional entity such as VAL client may receive the first protocol description information from the VAL server. For example, the VAL server may generate the first protocol description information and send it to the VAL client.For example, the first application functional entity such as VAL server may receive the first protocol description information from the VAL client. For example, the VAL client may generate the first protocol description information and send it to the VAL server.In an embodiment, the first protocol description information may comprise protocol description information for uplink and / or downlink. As used herein, the uplink may refer to the link from an application functional client to an application functional server. The downlink may refer to the link from an application functional server to an application functional client.FIG. 3b shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 312, the first application functional entity may receive the data traffic from the second application functional entity.For example, the first application functional entity such as SEALLDD client may receive the data traffic from the second application functional entity such as VAL client. The first application functional entity such as SEALLDD server may receive the data traffic from the second application functional entity such as VAL server.At block 314, the first application functional entity may perform the packetization for the data traffic.As a first example, the first application functional entity may receive the packetization indication from the second application functional entity, and then it may perform the packetization for the data traffic according to the packetization indication. As a second example, the first application functional entity may be configured to perform the packetization for the data traffic e.g. by an operator, then it may perform the packetization of the traffic according to the configuration. As a third example, the first application functional entity may detect that the data traffic is not packeted, then it may perform the packetization of the traffic e.g. according to the first protocol description information or configuration information.For example, the data traffic may be H. 264 raw data: [NALU] [NALU] … [NALU] . After SEALDD packetization using RTP (RFC 6184, RFC 7798) , NAL units can be segmented (if size is too large for line transmission) or aggregated (for small NAL units) by SEALDD. SEALDD may also update NALU header. Between the SEALDD client and SEALDD server, the SEALDD payload transferred via SEALDD / UDP / IP may include RTP / RTCP / RTSP data. It is note that H. 264 and RTP are for the purpose of describing particular embodiments only and are not intended to be limiting of example embodiments. Any other suitable format of raw data and / or any other suitable protocol are also possible.At block 316, the first application functional entity may perform PDU set marking to include PDU set information in the packeted data traffic according to the information indicating PDU set marking.The PDU Set Information may be included in any suitable location of the packeted data traffic. In an embodiment, the PDU Set Information may be included in a header extension in the packeted data traffic. One example for PDU set information is the “PDU Set Information” defined in 3GPP TS23.501 V18.4.0. One example for the header extension is the “RTP Header Extensions for PDU Set Marking” as defined in clause 4.4.2 of 3GPP TS 26.522 V0.2.0.For example, the first application functional entity may insert PDU Set Information related to packets belonging to a PDU Set into a header of the packet, e.g. a transport protocol header extension. For example, when the transport protocol is RTP, it may use RTP Header Extension for PDU Set Marking as defined in 3GPP TS 26.522 V0.2.0, the disclosure of which is incorporated by reference herein in its entirety.For example, the PDU set information may comprise any suitable information. For example, it may at least one of:-PDU Set Sequence Number.-Indication of End PDU of the PDU Set.-PDU Sequence Number within a PDU Set.-PDU Set Size in bytes.-PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.For example, if the packetization indication indicates that SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD client for downlink application traffic. Similarly, the SEALDD client performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD server for uplink application traffic. The SEALDD server and client also perform PDU Set marking (e.g. in RTP extension as defined in 3GPP TS 26.522 V0.2.0) , and if needed, stream session and transport management (e.g. RTCP, RTSP) .In an embodiment, the data traffic may be encrypted by the second application functional entity and cannot be decrypted by the first application functional entity. For example, in SEALDD performed packetization mode, to protect the stream content (e.g. if VAL service provider and SEALDD service provider are not from the same organization) , payload encryption (e.g., NAL compliant encryption for H. 264) can be implemented by VAL.FIG. 3c shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 322, the first application functional entity may receive, from the second application functional entity, a packetization indication indicating whether the first application functional entity needs to perform packetization for the data traffic.The packetization indication may be comprised in any suitable message such as new message or existing message. In an embodiment, the packetization indication may be comprised in the first message. In an embodiment, the packetization indication may be comprised in the first protocol description information.The packetization indication may be an explicit indication or an implicit infication. The packetization indication may explicitly indicate which communication function to perform the packetization or whether the first application functional entity needs to perform the packetization. For the case that an implicit indication indicates the first application functional entity or the second application functional entity needs to perform packetization, one exemplary embodiment is as such: when the packetization indication is absent in the first message, it may indicate that the first application functional entity needs to perform packetization; when an opposite indication exists explicitly in the first message, it may indicate that the second application functional entity needs to perform the packetization.In an embodiment, which communication function performs the packetization may be predefined or preconfigured. For example, the packetization performed by the first application functional entity may be predefined or preconfigured.For example, two modes can be enabled. Downlink (DL) data is used as example. The processing for uplink data may be similar.Mode 1. The VAL server sends streaming data in a transport format (e.g. RTP packet) as payload to SEALDD server and performs PDU Set marking (e.g. in RTP extension) , then SEALDD server transfers the payload via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to SEALDD client.Mode 2. VAL server sends encoded video and audio (e.g. H. 264 and Advanced Audio Coding (AAC) ) to SEALDD server, then SEALDD server performs packetization and sends packetized data in a transport (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to SEALDD client. The SEALDD server also performs PDU Set marking (e.g. in RTP extension) , RTCP and RTSP control (if needed) . In this mode, it simplifies operation in VAL, e.g., VAL application server doesn’t need to know how to set RTP extension for optimized traffic handling in 5GS.In an embodiment, when the packetization indication indicates that the first application functional entity needs to perform packetization for the data traffic, the first application functional entity needs to perform packetization for the data traffic. When the packetization indication indicates that the first application functional entity does not need to perform the packetization for the data traffic, the first application functional entity does not perform the packetization for the data traffic.FIG. 3d shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 332, the first application functional entity may receive packeted data traffic including PDU set information from the second application functional entity.In an embodiment, the second application functional entity performs the packetization for the data traffic. For example, the second application functional entity may be configured to perform the packetization for the data traffic e.g. by an operator or a local policy. For example, the second application functional entity may perform packetization for the data traffic and perform PDU set marking to include PDU set information in the packeted data traffic.In an embodiment, the PDU set information may be included in a header extension in the packeted data traffic. One example for PDU set information is the “PDU Set Information” defined in 3GPP TS23.501 V18.4.0. One example for the header extension is the “RTP Header Extensions for PDU Set Marking” as defined in clause 4.4.2 of 3GPP TS 26.522 V0.2.0.FIG. 3e shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 342, the first application functional entity may derive at least one PDU Set QoS parameter from an identifier of a service and / or an identifier of an application functional entity providing the service.In this embodiment, the first application functional entity may be SEALDD server, SEALDD client, VAL server or VAL client.The service may be any service (such as multi-modal service) provided by an application functional entity. For example, the service may be a service provided by VAL server or VAL client. The identifier of the service may be VAL identifier (ID) .The application functional entity providing the service may be any suitable application functional entity such as VAL server or VAL client. The identifier of the application functional entity providing the service may be VAL server ID or VAL client ID.The first application functional entity may obtain the identifier of the service and / or the identifier of the application functional entity providing the service in various ways. For example, the second application functional entity may send the identifier of the service and / or the identifier of the application functional entity providing the service to the first application functional entity in any suitable message.In an embodiment, the first message may comprise the identifier of the service and / or the identifier of the application functional entity.The first application functional entity may derive the at least one PDU Set quality of QoS parameter from the identifier of the service and / or then identifier of the application functional entity providing the service in various ways.In an embodiment, the first application functional entity may be configured with a mapping table between the identifier of the service (or the identifier of the application functional entity providing the service, or the identifier of the service and the identifier of the application functional entity providing the service) and the at least one PDU Set quality of QoS parameter, and the first application functional entity may derive the at least one PDU set QoS parameter by querying the mapping table.In an embodiment, the first application functional entity may derive or determine the at least one PDU Set QoS Parameter further based on a local configuration or a local policy.In an embodiment, when the first application functional entity is a SEALDD server, it can derive the PDU Set QoS parameters from VAL service ID and / or VAL server ID.In an embodiment, when the first application functional entity is a SEALDD client, it can derive the PDU Set QoS parameters from VAL service ID and / or VAL client ID.In an embodiment, for multi-modal service, the first application functional entity may derive the at least one PDU Set QoS parameter from the identifier of the multi-modal service and / or the identifier of the application functional entity providing the multi-modal service. The first application functional entity may know whether the service is a multi-modal service e.g. based on the first protocol description information or the information indicating PDU set marking.The PDU Set QoS Parameter may comprise any suitable QoS parameter. For example, it may comprise at least one of PDU Set Delay Budget (PSDB) , PDU Set Error Rate (PSER) , or PDU Set Integrated Handling Information (PSIHI) as described in 3GPP TS 23.501 V18.4.0. The PDU Set QoS Parameter may comprise PDU Set QoS Parameter for UL and / or DL direction.At block 344, the first application functional entity may send, to a network exposure node or a policy control node, the at least one PDU set QoS parameter, using a procedure of setting up an application function session with required QoS.In an embodiment, the first application functional entity may send the at least one PDU set QoS parameter to the network exposure node and the network exposure node may send it to the policy control node directly or via Time Sensitive Communication and Time Synchronization Function (TSCTSF) as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 or clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0, the disclosure of which is incorporated by reference herein in its entirety.The network exposure node may be any suitable network device or network node or network function or network entity which can implement exposure function. For example, the network exposure node may provide means to securely expose the services, events and capabilities provided by network interfaces. In an embodiment, the network exposure node may comprise a network exposure function (NEF) . In an embodiment, the network exposure node may comprise the network exposure node which may be defined in 6GS of 3GPP.The policy control node may be any suitable network device or network node or network function or network entity which can implement policy control function. In an embodiment, the policy control node may comprise a PCF. In an embodiment, the network exposure node may comprise the policy control function which may be defined in 6GS of 3GPP.The procedure of setting up an application function session with required QoS may be any suitable procedure which can set up an application function session with required QoS. In an embodiment, the procedure may be Setting up an AF session with required QoS procedure as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 or AF session with required QoS update procedure as described in clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0.In an embodiment, after the policy control node receives the at least one PDU set QoS parameter, the policy control node may perform the operations as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 or 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.For example, the at least one PDU set QoS parameter may be used in determining policy and charging control (PCC) Rules by the policy control node such as PCF. The policy control node may send the PCC Rules to SMF. When the SMF receives a PCC rule containing one or more PDU Set QoS Parameters (e.g. PSER, PSDB and PSIHI) , the SMF may add these PDU Set QoS parameters to the QoS Profile of the QoS Flow. The SMF may send the QoS Profile of the QoS Flow to AMF. AMF may send the QoS Profile of the QoS Flow to NG-RAN. The NG-RAN may perform the PDU Set based QoS handling as described in clause 5.37.5 of 3GPP TS 23.501 V18.4.0.FIG. 3f shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 352, the first application functional entity may obtain second protocol description information for transmission of the packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.The tunneling protocol may be any suitable tunneling protocol and the present disclosure has no limit on it. For example, the tunneling protocol may comprise at least one of Generic Routing Encapsulation (GRE) , open virtual private network (OpenVPN) , Virtual Extensible Local Area Network (VXLAN) , Layer 2 Tunneling Protocol (L2TP ) , Generic Network Virtualization Encapsulation (Geneve) , etc.In an embodiment, the tunneling protocol may be any suitable tunneling protocol which can be used in SEALDD-UU or SEALDD connection.In an embodiment, the second protocol description information may comprise any suitable information which can enable a user plane function and / or an access network protocol layer entity of a terminal device to identify a PDU that belongs to a PDU Set.In an embodiment, the second protocol description information may comprise the Protocol Description as described in clause 5.37.5.1 of 3GPP TS 23.501 V18.4.0 and information related to the tunneling protocol.In an embodiment, the second protocol description information may comprises at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol. The header length of the tunneling protocol and the offset of payload of the tunneling protocol can be used to locate the PDU set information.The first application functional entity may obtain the second protocol description information in various ways such as determining it by itself or receiving it from another entity.In an embodiment, when the first application functional entity is a SEALDD server, it may determine the second protocol description information by itself. For example, the SEALDD server may transmit the packeted data traffic according to the tunneling protocol and determine the second protocol description information.In an embodiment, when the first application functional entity is a SEALDD client, the SEALDD client may determine the second protocol description information by itself. For example, the SEALDD client may transmit the packeted data traffic according to the tunneling protocol and determine the second protocol description information.In an embodiment, when the first application functional entity is a SEALDD client, the SEALDD client may receive the second protocol description information from a SEALDD server directly or via a VAL server and a VAL client. For example, the SEALDD server may determine the second protocol description information. The SEALDD server may send it to the SEALDD client directly via SEALDD-UU. Alternatively, the SEALDD server may it to the VAL server via SEALDD-S. The VAL server may send it to the VAL client via VAL-UU. The VAL client may it to the SEALDD client via SEALDD-C.In an embodiment, when the first application functional entity is a SEALDD server, the first application functional entity may receive the second protocol description information from a SEALDD client directly or via a VAL client and a VAL server. For example, the SEALDD client may determine the second protocol description information. The SEALDD client may send it to the SEALDD server directly via SEALDD-UU. Alternatively, the SEALDD client may it to the VAL client via SEALDD-C. The VAL client may send it to the VAL server via VAL-UU. The VAL server may it to the SEALDD server via SEALDD-S.In an embodiment, when the first application functional entity is a VAL client, the first application functional entity may determine the second protocol description information. For example, the VAL client may know that it will use a tunnel protocol (e.g. SEALDD) to transmit the packeted data traffic including PDU set information and may determine the second protocol description information.In an embodiment, when the first application functional entity is a VAL server, the first application functional entity may determine the second protocol description information. For example, the VAL server may know that it will use a tunnel protocol (e.g. SEALDD) to transmit the packeted data traffic including PDU set information and may determine the second protocol description information.In an embodiment, the second protocol description information may comprise protocol description information for uplink and / or downlink.At block 354, the first application functional entity may send the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device, e.g. to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device.The third application functional entity may communicate with any suitable network. For example, the third application functional entity may communicate with the underlying 3GPP network systems using the respective 3GPP interfaces specified by the 3GPP network system. In an embodiment, the third application functional entity may communicate with a 5GS or a 6GS as defined by 3GPP.The third application functional entity may be any suitable application functional device or application functional node. For example, the third application functional entity can act as the application server for the data delivery enablement or the application client for the data delivery enablement.In an embodiment, the third application functional entity may be a SEALDD server or a SEALDD client. For example, when the first application functional entity is SEALDD client, the third application functional entity may be SEALDD server. When the first application functional entity is SEALDD server, the third application functional entity may be SEALDD client.The network exposure node may be any suitable network device or network node or network function or network entity which can implement exposure function. For example, the network exposure node may be NEF or the network exposure node which may be defined in 6GS of 3GPP.The policy control node may be any suitable network device or network node or network function or network entity which can implement policy control function. In an embodiment, the policy control node may comprise a PCF. In an embodiment, the policy control node may comprise the policy control function which may be defined in 6GS of 3GPP.FIG. 3g shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 362, when the first application functional entity is a SEALDD server, the first application functional entity may send the second protocol description information to at least one of a SEALDD client, a network exposure node, or a policy control node to enable the second protocol description information is to be sent to a user plane function and / or an access network protocol layer entity of a terminal device. In this embodiment, the third application functional entity may be the SEALDD client.For example, the SEALDD server may send the second protocol description information to the SEALDD client via SEALDD-UU. Alternatively, the SEALDD server may send the second protocol description information to the VAL server via SEALDD-S. The VAL server may send it to the VAL client via VAL-UU. The VAL client may send it to the SEALDD client via SEALDD-C. The SEALDD client may send the second protocol description information to the access network protocol layer entity of the terminal device.For example, the SEALDD server as an AF may send the second protocol description information to the network exposure node or the policy control node in various ways as described in various 3GPP specifications such as 3GPP TS 23.502 V18.4.0. For example, the SEALDD server may send the second protocol description information to the network exposure node or the policy control node using Setting up an AF session with required QoS procedure as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 or AF session with required QoS update procedure as described in clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0. For example, the SEALDD server may send the second protocol description information to the policy control node using PCF initiated SM Policy Association Modification as described in clause 4.16.5.2 of 3GPP TS 23.502 V18.4.0. The policy control node may send the second protocol description information to SMF. The SMF may send the second protocol description information to the access network protocol layer entity of the terminal device and / or the user plane function.In an embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent together in a same message. In another embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent in different messages.FIG. 3h shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 372, when the first application functional entity is a SEALDD client, the first application functional entity may send the second protocol description information to at least one of a SEALDD server, a network exposure node or a policy control node, to enable the second protocol description information is to be sent to a user plane function and / or an access network protocol layer entity of a terminal device. In this embodiment, the third application functional entity may be the SEALDD server.For example, the SEALDD client may send the second protocol description information to the SEALDD server via SEALDD-UU. Alternatively, the SEALDD client may send the second protocol description information to the VAL client via SEALDD-C, The VAL client may send it to the VAL server via VAL-UU. The VAL server may send it to the SEALDD server via SEALDD-S. The SEALDD server as an AF may send the second protocol description information to the network exposure node or the policy control node in various ways as described in various 3GPP specifications such as 3GPP TS 23.502 V18.4.0. The policy control node may send the second protocol description information to SMF. The SMF may send the second protocol description information to the access network protocol layer entity of the terminal device and / or the user plane function.The SEALDD client as an AF may send the second protocol description information to the network exposure node or the policy control node in various ways as described in various 3GPP specifications such as 3GPP TS 23.502 V18.4.0. For example, the SEALDD client may send the second protocol description information to the network exposure node or the policy control node using Setting up an AF session with required QoS procedure as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 or AF session with required QoS update procedure as described in clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0. For example, the SEALDD client may send the second protocol description information to the policy control node using PCF initiated SM Policy Association Modification as described in clause 4.16.5.2 of 3GPP TS 23.502 V18.4.0. The policy control node may send the second protocol description information to SMF. The SMF may send the second protocol description information to the access network protocol layer entity of the terminal device and / or the user plane function.In an embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent together in a same message. In another embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent in different messages.FIG. 3i shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 382, when the first application functional entity is a SEALDD client, the first application functional entity may send the second protocol description information to an access network protocol layer entity of a terminal device. For example, the SEALDD client may be located in the terminal device and may send the second protocol description information to an access network protocol layer of the terminal device.FIG. 3j shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 392, when the first application functional entity is a VAL client or a VAL server, the first application functional entity may send the second protocol description information to the network exposure node or the policy control node, to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device.The VAL client or VAL server as an AF may send the second protocol description information to the network exposure node or the policy control node in various ways as described in various 3GPP specifications such as 3GPP TS 23.502 V18.4.0. For example, the VAL client or VAL server may send the second protocol description information to the network exposure node or the policy control node using Setting up an AF session with required QoS procedure as described in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 or AF session with required QoS update procedure as described in clause 4.15.6.6a of 3GPP TS 23.502 V18.4.0. For example, the VAL client or VAL server may send the second protocol description information to the policy control node using PCF initiated SM Policy Association Modification as described in clause 4.16.5.2 of 3GPP TS 23.502 V18.4.0. The policy control node may send the second protocol description information to SMF. The SMF may send the second protocol description information to the access network protocol layer entity of the terminal device and / or the user plane function.In an embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent together in a same message. In another embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent in different messages.The second protocol description information may be used for identifying PDUs that belong to PDU Sets. For the downlink direction, the PSA UPF identifies PDUs that belong to PDU Sets 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 that belong to PDU Sets and marks them accordingly. For example, the PSA UPF may insert PDU Set Information related to packets belonging to a PDU Set into General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) header. The PSA UPF may forward PDU Set related information of each PDU to the NG-RAN over GTP-U, as described in clause 5.37.5 of 3GPP TS 23.501 V18.1.0. The terminal device may perform the similar operations. The PDU Set based QoS handling by the NG-RAN is determined by PDU Set QoS Parameters in the QoS profile of the QoS Flow and PDU Set information provided by the PSA UPF via N3 / N9 interface or the terminal device. The PDU Set based QoS Handling can be applied for GBR and non-GBR QoS Flows.FIG. 4a, 4b, 4c, 4d, 4e and 4f show flowcharts of methods according to embodiments of the present disclosure, which may be performed by an apparatus implemented in or at or as a second application functional entity or communicatively coupled to the second application functional entity. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the methods as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.FIG. 4a shows a flowchart of a method according to another embodiment of the present disclosure.At block 402, the second application functional entity may send, to a first application functional entity, a first message comprising first protocol description information for transmission of data traffic using a transport protocol.In an embodiment, the first protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an embodiment, the data traffic may be for a multi-modal service.In an embodiment, the first protocol description information may comprise information indicating protocol data unit (PDU) set marking.In an embodiment, the first application functional entity may be a SEALDD server and the second application functional entity may be a VAL server.In an embodiment, the first application functional entity may be a SEALDD client and the second application functional entity may be a VAL client.In an embodiment, the first application functional entity may be a SEALDD server and the second application functional entity may be a SEALDD client.In an embodiment, the first application functional entity may be a SEALDD client and the second application functional entity may be a SEALDD server.In an embodiment, the first message may comprise at least one of one or more SEALDD enabled regular transmission requests, one or more SEALDD connection status subscription requests, one or more SEALDD service requests, one or more SEALDD regular transmission connection establishment requests, one or more SEALDD regular transmission connection establishment responses, one or more SEALDD URLLC transmission connection establishment requests, or one or more SEALDD URLLC transmission connection establishment responses.In an embodiment, the first protocol description information may comprise at least one of information indicating protocol data unit (PDU) set marking, payload type and format, or transport protocol indication.In an embodiment, the information indicating PDU Set marking may comprise header extension with PDU Set.In an embodiment, the first application functional entity may be a SEALDD server and the second application functional entity may be a VAL server.In an embodiment, the first application functional entity may be a SEALDD client and the second application functional entity may be a VAL client.In an embodiment, the first application functional entity may be a SEALDD server and the second application functional entity may be a SEALDD client.In an embodiment, the first application functional entity may be a SEALDD client and the second application functional entity may be a SEALDD server.In an embodiment, the traffic may comprise traffic of a multi-modal service.In an embodiment, the first message may comprise at least one of a SEALDD enabled regular transmission request, or a SEALDD connection status subscription request.FIG. 4b shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 412, the second application functional entity may send the traffic to the first application functional entity. For example, the first application functional entity may perform packetization for the data traffic.In an embodiment, the data traffic is encrypted by the second application functional entity and cannot be decrypted by the first application functional entity.FIG. 4c shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 422, the second application functional entity may send, to the first application functional entity, a packetization indication indicating whether the first application functional entity needs to perform packetization for the data traffic.FIG. 4d shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 432, the second application functional entity may perform packetization for the data traffic. Block 432 is similar to block 314.At block 434, the second application functional entity may perform PDU set marking to include PDU set information in the packeted data traffic according to the information indicating PDU set marking. Block 434 is similar to block 316.At block 436, the second application functional entity may send the packeted data traffic including PDU set information to the first application functional entity.In an embodiment, the PDU set information may be included in a header extension in the packeted data traffic.FIG. 4e shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 442, when the second application functional entity is a SEALDD server, the second application functional entity may receive, from a SEALDD client, second protocol description information for transmission of the packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.At block 444, the second application functional entity may send the second protocol description information to at least one of a network exposure node or a policy control node to enable the second protocol description information is to be sent to a user plane function and / or an access network protocol layer entity of a terminal device.FIG. 4f shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 452, when the second application functional entity is a SEALDD client, the second application functional entity may receive, from a SEALDD server, second protocol description information for transmission of the packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.At block 454, the second application functional entity may send the second protocol description information to at least one of a network exposure node or a policy control node to enable the second protocol description information is to be sent to a user plane function and / or an access network protocol layer entity of a terminal device.In an embodiment, the second protocol description information may comprise at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol.FIG. 4g and 4h show flowcharts of methods according to embodiments of the present disclosure, which may be performed by an apparatus implemented in or at or as a network exposure node or communicatively coupled to the network exposure node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the methods as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.FIG. 4g shows a flowchart of a method according to another embodiment of the present disclosure.At block 462, the network exposure node may receive, from a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the first application functional entity may comprise a SEALDD server or a SEALDD client or a VAL server or a VAL client.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an embodiment, the second protocol description information may comprise at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol.For example, the first application functional entity may send the second protocol description information to the network exposure node at blocks 354, 362, 372 and 392, and then the network exposure node may receive, from the first application functional entity, the second protocol description information. For example, the second protocol description information may be comprised in Nnef_AFsessionWithQoS service as described in clause 5.2.6.9 of 3GPP TS 23.502 V18.4.0.At block 464, the network exposure node may send the second protocol description information to a policy control node.For example, the network exposure node may send the second protocol description information to the policy control node e.g., in Npcf_PolicyAuthorization Service as described in clause 5.2.5.3 of 3GPP TS 23.502 V18.4.0.FIG. 4h shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 472, the network exposure node may receive, from the first application functional entity, at least one PDU set QoS parameter.For example, the first application functional entity may send the at least one PDU set QoS parameter to the network exposure node at block 344, and then the network exposure node may receive, from the first application functional entity, the at least one PDU set QoS parameter. For example, the at least one PDU set QoS parameter may be comprised in Nnef_AFsessionWithQoS service as described in clause 5.2.6.9 of 3GPP TS 23.502 V18.4.0.At block 474, the network exposure node may send the at least one PDU set QoS parameter to the policy control node.For example, the network exposure node may send the at least one PDU set QoS parameter to the policy control node e.g., inNpcf_PolicyAuthorization Service as described in clause 5.2.5.3 of 3GPP TS 23.502 V18.4.0.In an embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent together in a same message. In another embodiment, the second protocol description information and the at least one PDU set QoS parameter may be sent in different messages.FIG. 4i and 4j show flowcharts of methods according to embodiments of the present disclosure, which may be performed by an apparatus implemented in or at or as a policy control node or communicatively coupled to the policy control node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the methods as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.FIG. 4i shows a flowchart of a method according to another embodiment of the present disclosure.At block 482, the policy control node may receive, from a first application functional entity or a network exposure node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the first application functional entity may comprise a SEALDD server or a SEALDD client or a VAL server or a VAL client.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an embodiment, the second protocol description information may comprise at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol.For example, the network exposure node may send the second protocol description information to the policy control node at block 464, and then the policy control node may receive, from the network exposure node, the second protocol description information. For example, the second protocol description information may be comprised in Npcf_PolicyAuthorization Service as described in clause 5.2.5.3 of 3GPP TS 23.502 V18.4.0.For example, the first application functional entity may send the second protocol description information to the policy control node at blocks 354, 362, 372 and 392, and then the policy control node may receive, from the first application functional entity, the second protocol description information. For example, the second protocol description information may be comprised in Npcf_PolicyAuthorization Service as described in clause 5.2.5.3 of 3GPP TS 23.502 V18.4.0.At block 484, the policy control node may send the second protocol description information to a session management node.The session management node may be any suitable network device or network node or network function or network entity which can implement session management function. In an embodiment, the session management node may comprise an SMF. In an embodiment, the session management node may comprise the session management function which may be defined in 6GS of 3GPP.The second protocol description information can be comprised in any suitable message which can be sent from the policy control node to the session management node. For example the second protocol description information can be sent from the policy control node to the session management node in Npcf_SMPolicyControl_UpdateNotify service operation as described in clause 5.2.5.4 of 3GPP TS 23.502 V18.4.0.FIG. 4j shows a flowchart of a method according to another embodiment of the present disclosure. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 492, the policy control node may receive, from the first application functional entity or the network exposure node, at least one PDU set QoS parameter.For example, the first application functional entity may send the at least one PDU set QoS parameter to the policy control node at block 344, and then the policy control node may receive, from the first application functional entity, the at least one PDU set QoS parameter.For example, the network exposure node may send the at least one PDU set QoS parameter to the policy control node at block 474, and then the policy control node may receive, from the network exposure node, the at least one PDU set QoS parameter.In an embodiment, the second protocol description information and the at least one PDU set QoS parameter may be received together in a same message. In another embodiment, the second protocol description information and the at least one PDU set QoS parameter may be received in different messages.At block 494, the policy control node may determine a PCC rule based on the at least one PDU set QoS parameter and the second protocol description information.For example, the at least one PDU set QoS parameter and the second protocol description information may be used in determining the PCC Rule by the PCF e.g. as defined in clause 6.1.3.27.4 of 3GPP TS 23.503 V18.4.0.FIG. 4k shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a session management node or communicatively coupled to the session management node. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 4900 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 4902, the session management node may receive, from a policy control node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an embodiment, the second protocol description information may comprise at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol.For example, the policy control node may send the second protocol description information to the session management node at block 384, and then the session management node may receive, from the policy control node, the second protocol description information.At block 4904, the session management node may send the second protocol description information to a user plane function and / or an access network protocol layer entity of a terminal device.The second protocol description information may be comprised in any suitable message which can be sent from the session management node such as SMF to the user plane function such as UPF or the access network protocol layer entity e.g. as described in various 3GPP specifications such as 3GPP TS 23.502 V18.4.0.FIG. 4l shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as an access network protocol layer entity of a terminal device or communicatively coupled to the access network protocol layer entity of a terminal device. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 4910 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 4912, the access network protocol layer entity may receive, from a session management node or a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the first application functional entity comprises a SEALDD client.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an embodiment, the second protocol description information may comprise at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol.For example, the session management node may send the second protocol description information to the access network protocol layer entity at block 4904, and then the access network protocol layer entity may receive, from the session management node, the second protocol description information.For example, the first application functional entity may send the second protocol description information to the access network protocol layer entity at block 382, and then the access network protocol layer entity may receive, from the first application functional entity, the second protocol description information.At block 4914, the access network protocol layer entity may receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol.For example, the access network protocol layer entity may receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol from a SEALDD client.At block 4916, the access network protocol layer entity may process the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information.For example, the second protocol description information may enable the access network protocol layer entity of the terminal device to know that the tunneling protocol is used in transmission of the packeted data traffic and then it can correctly identify the packeted data traffic and proceed with identifying the PDU set information based on the second protocol description information. Then the access network protocol layer may mark the PDU set information accordingly in the access network protocol layer data.FIG. 4m shows a flowchart of a method according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a user plane function or communicatively coupled to the user plane function. As such, the apparatus may provide means or modules or circuits for accomplishing various parts of the method 4920 as well as means or modules or circuits for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, the description thereof is omitted here for brevity.At block 4922, the user plane function may receive, from a session management node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol.In an embodiment, the second protocol description information may comprise uplink protocol description information and / or downlink protocol description information.In an embodiment, the second protocol description information may comprise at least one of information indicating that the tunneling protocol is used in transmission of the packeted data traffic, a header length of the tunneling protocol, an offset of payload of the tunneling protocol, a location of the PDU set information, or offset position information in a header of the tunneling protocol.For example, the session management node may send the second protocol description information to the user plane function at block 4904, and then the user plane function may receive, from the session management node, the second protocol description information.At block 4924, the user plane function may receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol.For example, the user plane function may receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol from a SEALDD server.At block 4926, the user plane function entity may process the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information.For example, the second protocol description information may enable the user plane function to know that the tunneling protocol is used in transmission of the packeted data traffic and then it can correctly identify the packeted data traffic and proceed with identifying the PDU set information based on the second protocol description information. Then the user plane function may mark the PDU set information accordingly in the GTP.FIG. 4n shows a flowchart of Setting up an AF session with required QoS procedure according to another embodiment of the present disclosure, which is same as Figure 4.15.6.6-1 of 3GPP TS 23.502 V18.4.0.The procedure of FIG. 4n is same as steps 1 to 8 in clause 4.15.6.6 of 3GPP TS 23.502 V18.4.0 with differences that:The SEALDD client or SEALDD server or VAL server or VAL client may act as AF.In step 1. The Nnef_AFsessionWithQoS_Create request may comprise the second protocol description information.In step 3. The Npcf_PolicyAuthorization_Create request may comprise the second protocol description information.In steps 3a and 3b. If TSCTSF is involved, it transparently relay the received second protocol description information from NEF / AF to PCF.The network node such as AF, NEF and PCF may operate according to embodiments of the present disclosure.FIG. 4o shows a flowchart of PCF initiated SM Policy Association Modification according to another embodiment of the present disclosure, which is same as Figure 4.16.5.2-1 of 3GPP TS 23.502 V18.4.0.The procedure of FIG. 4o is same as steps 1a to 5 in clause 4.16.5.2 of 3GPP TS 23.502 V18.4.0 with differences that:The SEALDD client or SEALDD server or VAL server or VAL client may act as AF.In step 1a. The application / service information may comprise the second protocol description information.If TSCTSF is involved, it transparently relay the received second protocol description information from NEF / AF to PCF.In step 4. The Npcf_SMPolicyControl_UpdateNotify request may comprise the second protocol description information.In N4 interface, SMF may send the second protocol description information for DL data to UPF in Packet Detection Rule (PDR) . See clause 5.8.5.3 of 3GPP TS 23.501 for PDR definition.SMF may send the second protocol description information for UL data to the access network protocol layer entity of the terminal device.The network node such as AF, SMF and PCF may operate according to embodiments of the present disclosure.According to various embodiments, the proposed solution describes how application enablement layer can facilitate application multi-modal service over-the-top to reduce complexity for VAL, considering the network capability and application adaptation&optimization.According to various embodiments, the solution proposes to specify the following aspects in facilitating application multi-modal service (e.g. for XR traffic) :Enabling SEALDD server to derive PDU set related assistance information when interacting with 3GPP core network; andEnabling SEALDD layer to handle packetization, PDU set marking (e.g. in RTP extension) , and RTCP and RTSP control, to offload VAL client and VAL server.In an embodiment, the Protocol Description described in 3GPP TS 23.501 V18.4.0 may be extended with SEALDD information, for example, the underlined part may be added in the Protocol Description:-Protocol Description: Indicates the transport protocol used by the service data flow (e.g. RTP, SRTP) and information, e.g. the following:-RTP

[0185] or SRTP

[0186] ;-RTP or SRTP with RTP Header Extensions, including:-RTP Header Extensions for PDU Set Marking as defined in TS 26.522

[0179] ;-Other RTP Header Extensions as defined RFC 8285

[0189] ;-RTP or SRTP without RTP Header Extensions, but together with RTP Payload Format (e.g. H. 264

[0187] or H. 265

[0188] ) ;-RTP or SRTP with RTP Header Extensions for PDU Set Marking as defined in TS 26.522

[0179] , and together with RTP Payload Format (e.g. H. 264

[0187] or H. 265

[0188] ) ;-RTP or SRTP with other RTP Header Extensions following RFC 8285

[0189] , and together with RTP Payload Format (e.g. H. 264

[0187] or H. 265

[0188] ) ;-SEALDD usage indication (e.g. whether SEALDD is used in the service data flow) (if SEALDD is used) SEALDD header length or payload (e.g. RTP or SRTP) offset and the offset info position in SEALDD header.NOTE: in one protocol realization, by knowing the SEALDD header length, UPF or UE lower layer (e.g. access network protocol layer) can skip SEALDD header assuming the octet / byte after header is start octet / byte of payload. In another protocol realization, by knowing the SEALDD payload offset and the offset information position in SEALDD header, the UPF or UE layer can identify start octet / byte of SEALDD payload.As described in clauses 5.37.5.1 and 5.37.5.2 of 3GPP TS 23.501 V18.4.0, PSA UPF can identify the PDU Set Information using the Protocol Description for DL data received from AF. With SEALDD information, the PSA UPF can correctly identify SEALDD payload (e.g. RTP or SRTP) and proceed with identifying the PDU Set information for the DL data (e.g. identifies PDUs that belong to a PDU Set) .PCF impact: AF provided PDU Set QoS Parameters and Protocol Description (UL and / or DL) may be used in determining the PCC Rule by the PCF as defined in clause 6.1.3.27.4 of 3GPP TS 23.503 V18.4.0.For the UL protocol description handling, one of the two options can be used:Option 1: For UL data, application client (e.g. SEALDD client) in the UE may send SEALDD info as described above in UL protocol description to UE lower layer so that the UE lower layer can mark PDU set information in AN-protocol based on received protocol extension, e.g., RTP extension. Then during AN congestion, 5G-RAN will perform packet handling for PDUs in a set and also for PDU sets in the same SDF based on PDU set information in AN-protocol.Option 2: AF sends UL protocol description to NEF / PCF, and then PCF sends it to SMF. SMF further sends the UL protocol description to the UE lower layer (e.g. via NAS message) .NOTE: for AF invoking NEF / PCF service to provide protocol description including SEALDD information, alternatively, UE application client can invoke NEF / PCF service based on CAPIF (quote: “The API invoker may be either an application on a server or an application on a UE. ” from clause 6.3.2 of TS 23.222 v. 19.0.0) .Embodiments herein may provide many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, it may reduce complexity for the second application functional entity such as VAL client and VAL server. For example, the second application functional entity can only transfer media raw data such as H. 264 to the first application functional entity such as SEALDD server or SEALDD client and the first application functional entity will handle the rest such as packetization, PDU set marking, or RTCP and RTSP control. In some embodiments herein, it may enable the first application functional entity such as SEALDD server to derive PDU set related assistance information when interacting with 3GPP core network. In some embodiments herein, it may enable the first application functional entity such as SEALDD server or SEALDD client to handle packetization, PDU set marking (e.g. in RTP extension) , and RTCP and RTSP control, to offload the second application functional entity such as VAL client and VAL server. In some embodiments herein, it may solve the issue: when SEALDD application layer is used, how to inform, a user plane function and / or an access network protocol layer entity of a terminal device, information indicating that the tunneling protocol is used in transmission of the packeted data traffic and tunneling protocol information. In some embodiments herein, it may enable the user plane function and / or the access network protocol layer entity of the terminal device to handle the data of the tunneling protocol correctly. In some embodiments herein, it can protect the stream content e.g. if VAL service provider and SEALDD service provider are not from the same organization. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.Apparatuses according to embodiments of the present disclosureFIG. 7 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure. For example, the first application functional entity, the second application functional entity, the network exposure node, the session management node, the access network protocol layer entity, or the user plane function described above may be implemented as or through the apparatus 700.The apparatus 700 comprises at least one processor 721, such as a digital processor (DP) , and at least one memory (MEM) 722 coupled to the processor 721. The apparatus 700 may further comprise a transmitter TX and 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 apparatus 700 to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor 721 and the at least one MEM 722 may form processing means 725 adapted to implement various embodiments of the present disclosure.Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor 721, software, firmware, hardware or in a combination thereof.The MEM 722 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories, as non-limiting examples.The processor 721 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.In an embodiment where the apparatus is implemented as or at the first application functional entity, the memory 722 contains instructions executable by the processor 721, whereby the first application functional entity operates according to any of the methods performed by the first application functional entity as described above.In an embodiment where the apparatus is implemented as or at the second application functional entity, the memory 722 contains instructions executable by the processor 721, whereby the second application functional entity operates according to any of the methods performed by the second application functional entity as described above.In an embodiment where the apparatus is implemented as or at the network exposure node, the memory 722 contains instructions executable by the processor 721, whereby the network exposure node operates according to any of the methods performed by the network exposure node as described above.In an embodiment where the apparatus is implemented as or at the policy control node, the memory 722 contains instructions executable by the processor 721, whereby the policy control node operates according to any of the methods performed by the policy control node as described above.In an embodiment where the apparatus is implemented as or at the session management node, the memory 722 contains instructions executable by the processor 721, whereby the session management node operates according to any of the methods performed by the session management node as described above.In an embodiment where the apparatus is implemented as or at the access network protocol layer entity, the memory 722 contains instructions executable by the processor 721, whereby the access network protocol layer entity operates according to any of the methods performed by the access network protocol layer entity as described above.In an embodiment where the apparatus is implemented as or at the user plane function, the memory 722 contains instructions executable by the processor 721, whereby the user plane function operates according to any of the methods performed by the user plane function as described above.Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain 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 the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.The term unit or module may have conventional meaning in the field of electronics, electrical devices and / or electronic devices and may include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods as described above.According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods as described above.In addition, the present disclosure may also provide a carrier containing the computer program as mentioned above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. The computer readable storage medium can be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory) , a ROM (read only memory) , Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function, or means that may be configured to perform two or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses) , firmware (one or more apparatuses) , software (one or more modules) , or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatuses. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The above described embodiments are given for describing rather than limiting the disclosure, and it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the disclosure as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the disclosure and the appended claims. The protection scope of the disclosure is defined by the accompanying claims.In an embodiment, 3GPP TS23.433 V19.0.0 may be changed as following.9.2.2.2 SEALDD enabled regular data transmission connection establishment procedureFIG. 5 shows a flowchart of a procedure for establishing regular SEALDD data transmission connection.Pre-condition:-The VAL server can discover and select the SEALDD server by CAPIF functions. The steps of FIG. 5 is as following.1. The VAL server decides to use SEALDD service for application traffic transfer and allocates address / port as SEALDD-S Data transmission connection information for receiving the data packets from SEALDD server. The VAL server sends Sdd_RegularTransmission request to the SEALDD server discovered by CAPIF. The service request includes UE ID / address, VAL server ID, VAL service ID, SEALDD-S Data transmission connection information of the VAL server side, and optionally, the protocol description, the QoS information for the application traffic, e.g. QoS requirements.2. Upon receiving the request, the SEALDD server performs an authorization check. If authorization is successful, SEALDD server allocates address / port of the SEALDD server to receive the packets from the VAL server for application data transfer as SEALDD-S data transmission connection information of the SEALDD server side. The SEALDD server allocates a specific address or port used for SEALDD traffic transfer with the specific UE for the VAL server and responds with a SEALDD service response (including SEALDD-S data transmission connection information of the SEALDD server side) . The VAL server and SEALDD server can use SEALDD-S data transmission connection information to establish the data transmission connection between VAL server and SEALDD server for application data transfer.The SEALDD server may send the AF request to provide the required QoS information to 5GC via N33 / N5, as defined in clause 5.2.6.9 and in clause 5.2.5.3 of 3GPP TS 23.502 [6] . The AF request includes the application traffic descriptor containing the address or ports allocated by SEALDD server, and the QoS information for application traffic. The QoS information may be determined by SEALDD server according to VAL service ID for different service type of application traffic if the QoS information is not provided by VAL server. The SEALDD server relies on the northbound Policy Authorization Service API exposed 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 N5 reference point, or the northbound AF Session with QoS Service APIs and / or the PFD Management northbound APIs exposed by the NEF as specified in 3GPP TS 23.502 [6] and 3GPP TS 23.503 [7] , if the SEALDD server is connected to the PCF via NEF. SEALDD may also rely upon the EES Session with QoS API as specified in 3GPP TS 23.558

[0010] and / or the NRM QoS functionality as described in 3GPP TS 23.434 [4] . For application multi-modal service, the SEALDD server derives PDU Set related assistance information based on VAL service ID and / or VAL server ID for interacting with NEF / PCF.Editor's note: For SEALDD layer, it is a tunnel (e.g. SEALDD / UDP / IP) wrapping the multi-modal service data (e.g. RTP packet) from VAL server / client. How SEALDD server can indicate a tunnel protocol description to 5GC in Session with QoS API needs coordination with SA2.NOTE 1: The SEALDD-S data transmission connection information of the SEALDD server side is optional to respond to the VAL server, if the SEALDD server uses the downlink pull mode to obtain the data / content from the address provided by the VAL server in step 1, and uses the uplink push mode to send the data / content to the address provided by VAL server.3. Data transmission session information is provisioned to the VAL client by the VAL server via application signalling.NOTE 2: The application signalling may be transmitted via direct application layer connection or via the SEALDD layer.4. The VAL client sends a SEALDD service request to SEALDD client. The VAL client receives a SEALDD service response to the SEALDD client. The response indicates that whether the SEALDD service request is successful or not.5. The VAL / SEALDD client discover and select the proper SEALDD server for the VAL application, as described in clause 9.4.3. After this step, the VAL server is discovered and selected along with the associated SEALDD server, the SEALDD client can get the SEALDD server's address.6. The SEALDD client allocates a SEALDD flow ID mapping to the identifiers of the application traffic. The SEALDD client sends Sdd_RegularTransmissionConnection_Establish request to SEALDD server with the SEALDD client ID, the SEALDD flow ID, the SEALDD traffic descriptor of the SEALDD client side (the address / port of the SEALDD client for receiving the downlink SEALDD traffic) , VAL server ID, VAL service ID. The request message also contains the selected VAL server endpoint information and UEID. The SEALDD server retrieves the location information of the VAL UE or SEALDD client from SEAL LM services defined in 3GPP TS 23.434 [4] clause 9.3.12 and verifies with the Geofence policy configured by the VAL server to allow or restrict the data connection establishment. If the location information is allowed as per the configured geofence policy then the SEALDD server allows the data connection establishment, otherwise SEALDD server returns a failed result e.g. performs connection reject.NOTE 3: The SEALDD server can use or update the association between SEALDD-UU connection and SEALDD-S connection that associated with UE ID, VAL service ID, VAL server endpoint, which is used to correlate the SEALDD traffic and the VAL application traffic.NOTE 4: The SEALDD flow ID is used by the SEALDD client and SEALDD server to identify different VAL application traffic of the same SEALDD client. The SEALDD flow ID may be same with the identifiers of the application traffic or new simplified IDs allocated by SEALDD.7. The SEALDD server responds to the SEALDD client with the SEALDD traffic descriptor of SEALDD server side (e.g. address / port allocated in step 2, transport layer protocol) mapping to the application traffic. The SEALDD server may send the protocol description received from the VAL server to the SEALDD client in the SEALDD regular transmission connection establishment response.8. If the connection between VAL server and SEALDD server is not established in step 2, the SEALDD server establishes connection with VAL server for the VAL client to transmit application traffic mapping to the SEALDD traffic according to the SEALDD-S information negotiated in step 1-2.9. The SEALDD client uses the SEALDD traffic descriptor of SEALDD server side for SEALDD connection establishment.After this step, the SEALDD client and SEALDD server both get the whole SEALDD traffic descriptor (including the UE's address / port and SEALDD server's address / port for the SEALDD traffic transmission) .After the negotiation and establishment of the connections, the SEALDD client gets the mapping information between application traffic and SEALDD flow ID. The SEALDD server gets the mapping information between the SEALDD flow ID and the SEALDD-S connection. Upon receiving application traffic from VAL client, the SEALDD maps it to SEALDD traffic with SEALDD traffic descriptors as negotiated with SEALDD server in step 6 and step 7. The SEALDD traffic is sent to the SEALDD server. The SEALDD server maps the SEALDD traffic to the application traffic according to the stored SEALDD traffic descriptor, SEALDD client ID and SEALDD flow ID. The SEALDD server sends the recovered application traffic to the address provided by VAL server in step 1, via the connection established in step 2 or 8 according to the mapping information. The downlink application traffic sent from VAL server to VAL client is processed similarly. If packetization indication indicates that SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD client for downlink application traffic. Similarly, the SEALDD client performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD server for uplink application traffic. The SEALDD server and client also perform PDU Set marking (e.g. in RTP extension as defined in 3GPP TS 26.522 [TS26522] ) , and if needed, stream session and transport management (e.g. RTCP, RTSP) .NOTE 5: In SEALDD performed packetilization mode, to protect the stream content (e.g. if VAL service provider and SEALDD service provider are not from the same organization) , payload encryption (e.g., NAL compliant encryption for H. 264) can be implemented by VAL.The SEALDD server receives any UE location change notification using SEAL LM services defined in 3GPP TS 23.434 [4] clause 9.3.12, then the SEALDD server performs the data delivery in alignment with the geofence policy. If the UE is in the forbidden location or not allowed for the given VAL service to send / receive data as per the Geofence policy, then the SEALDD server performs action like releases the connection and informs the VAL server that UE is not reachable because in a forbidden location using connection event status procedure. If UE enters the allowed location area then the SEALDD server initiates the connection establishment using the procedure defined in clause 9.2.2.3.9.2.2.3 SEALDD enabled regular data transmission connection establishment based on policyThe SEALDD servers has Data Delivery (DD) policy being provisioned. Before the application communication between VAL client and VAL server starts, the DD policy is enforced by the SEALDD server to establish the SEALDD connection.Pre-conditions:1. The SEALDD server has DD policies available.FIG. 6a shows a flowchart of policy enforced by SEALDD server for connectivity.1. The VAL server subscribes to SEALDD event exposure for connection status using the procedure defined in clause 9.2.2.6.2. When the time for data transmission is about to start, the SEALDD server enforces the policy to trigger regular data transmission connection establishment. If spatial condition for UE is provided, the SEALDD server also ensures the UE’s location requirement is satisfied when establishing regular data transmission connection (e.g. by using NEF service for monitoring UE location or SEAL location service for UE entering area of interest) .3. If there is a special routing requirement for SEALDD user plane traffic (e.g. running on a specific slice and DNN) , the SEALDD server interacts with 3GPP CN to provision service specific parameters with NEF as described in 3GPP TS 23.502 [6] , clause 4.15.6.10 and clause 4.15.6.7.If there are QoS requirements in the DD policy, the SEALDD server also applies QoS to ensure the quality for SEALDD traffic by utilizing NEF / PCF / NRM / EES service for QoS adjustment. Specifically, the SEALDD server relies on the northbound Policy Authorization Service API exposed 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 N5 reference point, or the northbound AF Session with QoS Service API and / or the PFD Management northbound APIs exposed by the NEF as specified in 3GPP TS 23.502 [6] and 3GPP TS 23.503 [7] , if the SEALDD server is connected to the PCF via NEF. SEALDD may also rely upon the EES Session with QoS API as specified in 3GPP TS 23.558

[0010] and / or the NRM QoS functionality as described in 3GPP TS 23.434 [4] . For application multi-modal service, the SEALDD server derives PDU Set related assistance information based on VAL service ID and / or VAL server ID for interacting with NEF / PCF.Editor's note: For SEALDD layer, it is a tunnel (e.g. SEALDD / UDP / IP) wrapping the multi-modal service data (e.g. RTP packet) from VAL server / client. How SEALDD server can indicate a tunnel protocol description to 5GC in session with QoS API needs coordination with SA2.If the DD policy specifies failure detection report, the SEALDD server may subscribe to CN analytics (e.g. DN performance analytics) from NEF / NWDAF and further notify data delivery status of application traffic to VAL client (via SEALDD client) and VAL server based on analytics result.4. The SEALDD server allocates an IP address and port for sending and receiving packet over SEAL-S reference point, then SEALDD server sends SEALDD connection establishment notification to the VAL server with VAL service ID, the IP address and port.5-6. The SEALDD server allocates an IP address and port for sending and receiving packet over SEAL-Uu reference point, then SEALDD server sends regular data transmission connection establishment request to the SEALDD client with SEALDD flow ID, VAL service ID, the IP address and port. The SEALDD server may send the protocol description received from the VAL server to the SEALDD client in the SEALDD regular transmission connection establishment request. The request is responded by the SEALDD client. UE IP address (and port) may be included by the SEALDD client in the response or sent in a separate update message by SEALDD client if a different UE IP address is to be used in SEALDD connection user plane.NOTE 1: Step 4 and step 5 can be done in parallel.NOTE 2: Step 5 can be sent via PDU session (if exist) or via application triggering (if no PDU session exists) .7. The SEALDD client further notifies the VAL client about the SEALDD connection being established.Upon receiving application traffic from VAL client (not shown in the figure) , the SEALDD client sends it to SEALDD server in SEALDD traffic. The SEALDD server identifies application traffic based on the VAL service ID and further sends the application traffic to VAL server. The downlink application traffic sent from VAL server to VAL client is processed similarly. If packetization indication indicates that SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD client for downlink application traffic. Similarly, the SEALDD client performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD server for uplink application traffic. The SEALDD server and client also perform PDU Set marking (e.g. in RTP extension as defined in 3GPP TS 26.522 [TS26522] ) , and if needed, stream session and transport management (e.g. RTCP, RTSP) .NOTE 3: In SEALDD performed packetilization mode, to protect the stream content (e.g. if VAL service provider and SEALDD service provider are not from the same organization) , payload encryption (e.g., NAL compliant encryption for H. 264) can be implemented by VAL.9.3.2.1 E2E redundant transmission path establishment procedure FIG. 6b shows a flowchart of the procedure for redundant transmission establishment. This procedure can be triggered by a VAL server for data transfer per application layer transaction.Pre-conditions:1. The VAL server has discovered and selected the SEALDD server by CAPIF functions as specified in clause 9.4.2.2. The VAL server has established application connection with the VAL client and can get the VAL client’s UE ID or UE address via the application connection.The steps of FIG. 6b is as following.1. The VAL server decides to use SEALDD service to help ensuring data transmission quality for application traffic transfer and send a Sdd_URLLCTransmission request to the SEALDD server discovered by CAPIF. The request includes UE ID / address, VAL server ID, VAL service ID, SEALDD-S Data transmission connection information of the VAL server side, and optionally, the protocol description, the QoS information for the application traffic, e.g. QoS requirements. The VAL server ID and VAL service ID can be used to identify the VAL application traffic.2. Upon receiving the request, the SEALDD server decides to establish redundant transmission path. The SEALDD server allocates two different addresses or ports for the two redundant transmission paths and sends an AF request to 5GS to create or update URSP rules as described in clause 4.15.6.10 of 3GPP TS 23.502 [6] for the UE (s) going to use the redundant transmission service. The AF request includes Identifiers of the UE (s) and application traffic descriptor containing the addresses or ports allocated by SEALDD server. The SEALDD server may send the AF request to provide the required QoS information to 5GC via N33 / N5, as defined in clause 5.2.6.9 and in clause 5.2.5.3 of 3GPP TS 23.502 [6] . For application multi-modal service, the SEALDD server derives PDU Set related assistance information for the two redundant transmission paths based on VAL service ID and / or VAL server ID for interacting with NEF / PCF.Editor's note: For SEALDD layer, it is a tunnel (e.g. SEALDD / UDP / IP) wrapping the multi-modal service data (e.g. RTP packet) from VAL server / client. How SEALDD server can indicate a tunnel protocol description to 5GC in Session with QoS API needs coordination with SA2.3. If the processing of the request was successful, SEALDD server allocates address / port of the SEALDD server to receive the packets from the VAL server for application data transfer as SEALDD-S data transmission connection information of the SEALDD server side. The SEALDD server responds with a SEALDD service response (including SEALDD-S data transmission connection information of the SEALDD server side) and indicates to the VAL server that redundant transmission service should be activated. The VAL server and SEALDD server can use SEALDD-S data transmission connection information to establish the data transmission connection between VAL server and SEALDD server for application data transfer.4. If the redundant transmission requirement is not preconfigured or notified to the VAL client, the VAL server may notify the VAL client (s) which is going to use the redundant transmission service through application layer message.NOTE 1: The application signalling may be transmitted via direct application layer connection or via the SEALDD layer.NOTE 2: The VAL client can be preconfigured that the VAL service should always be transmitted via redundant transmission. Or this application layer notification may be notified to the UE in another period before the VAL application traffic is really transmitted.5. The VAL client sends a SEALDD service request to use E2E redundant transmission for the application traffic.6. The SEALDD client discovers and selects the proper SEALDD server for the VAL application as specified in clause 9.4.3. After this step, the SEALDD client can get the SEALDD server's address.7. The SEALDD client allocates a SEALDD flow ID mapping to the application traffic. The SEALDD client sends Sdd_URLLCTransmissionConnection_Establish request to SEALDD server. The request includes the SEALDD client ID, SEALDD flow ID, VAL server ID, VAL service ID for SEALDD server to identify the specific application traffic.8. Upon receiving the request, the SEALDD server sends SEALDD traffic descriptor for redundant transmission of the SEALDD server side (i.e. the addresses or ports for the redundant transmission paths allocated in step 2 and the transport protocol used for the SEALDD traffic) to SEALDD client. The SEALDD server may send the protocol description received from the VAL server to the SEALDD client in the SEALDD URLLC transmission connection establishment response.9. The UE uses the SEALDD traffic descriptor of the SEALDD server and the created or updated URSP rules to trigger two redundant PDU Sessions establishment procedure via 5GS as specified in clause 5.33.2.1 of 3GPP TS 23.501 [5] .10. [Optional] The SEALDD client sends Sdd_URLLCTransmissionConnection_Update request to SEALDD server. The request includes the SEALDD client ID, the SEALDD flow ID, the SEALDD traffic descriptors for redundant transmission of the SEALDD client side (i.e. UE addresses and ports of the two redundant PDU Sessions) . The two redundant SEALDD traffic use the same SEALDD flow ID for identification.11. [Optional] The SEALDD server sends a response to SEALDD client. After this step, the SEALDD client and SEALDD server both get the whole SEALDD traffic descriptors (including the UE's addresses / ports and SEALDD server's addresses / ports for the SEALDD traffic transmission) . The SEALDD client and SEALDD server store the mapping between the application traffic and SEALDD traffic.12. [Optional] If the connection between VAL server and SEALDD server is not established in step 3, the SEALDD server establishes connection with VAL server for the VAL client to transmit application traffic mapping to the redundant SEALDD traffic according to the SEALDD-S information negotiated in step 1-3NOTE 3: Step 10 and Step 11 are optional. If the redundant PDU sessions are already established before step 7, the IP addresses of the UE may be notified to the SEALDD server in step 7. In other cases, after the establishment of the two redundant PDU sessions, the SEALDD client may communicate with SEALDD server through the redundant PDU sessions to let the SEALDD server know the UE's address (es) of the redundant PDU session to fulfil the traffic mapping or the SEALDD client and SEALDD server may use other mapping mechanisms, it is up to the transport protocol used by SEALDD client and SEALDD server for the SEALDD traffic.13. The SEALDD client responds with a SEALDD service response.After the negotiation and establishment of the connections, the SEALDD client gets the mapping information between the application traffic and SEALDD flow ID. The SEALDD server gets the mapping information between the SEALDD flow ID and the SEALDD-S connection. Upon receiving application traffic from VAL client, the SEALDD client duplicates the application packets and maps them into two SEALDD traffic flows with SEALDD traffic descriptors as negotiated with SEALDD server in step 8 and step 10. The two SEALDD traffic is sent through two redundant PDU sessions to the SEALDD server. The SEALDD server maps the two SEALDD traffic to the same application traffic according to the stored SEALDD traffic descriptors, SEALDD client ID and SEALDD flow ID. After packet elimination and reordering the SEALDD server sends the aggregated application traffic to VAL server via the connection established in step 3 according to the mapping information. The downlink application traffic sent from VAL server to VAL client is processed similarly. If packetization indication indicates that SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD client for downlink application traffic. Similarly, the SEALDD client performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD server for uplink application traffic. The SEALDD server and client also perform PDU Set marking (e.g. in RTP extension as defined in 3GPP TS 26.522 [TS26522] ) , and if needed, stream session and transport management (e.g. RTCP, RTSP) .NOTE 4: In SEALDD performed packetilization mode, to protect the stream content (e.g. if VAL service provider and SEALDD service provider are not from the same organization) , payload encryption (e.g., NAL compliant encryption for H. 264) can be implemented by VAL.9.3.2.2 Client initiated E2E redundant transmission path establishment procedureFIG. 6c shows a flowchart of the procedure for client initiated redundant transmission establishment for data transfer per application layer transaction.Pre-conditions:1. The SEALDD client is authorized to request redundant transmission services on behalf of the VAL client when the VAL client initiates redundant transmission service.The steps of FIG. 6c is as following.1. A VAL client determines to use SEALDD service to ensure that the data transmission quality for the application traffic is met and makes a service request to the SEALDD client.2. Upon receiving the request, the SEALDD client decides to establish redundant transmission path according to the QoS requirements. The SEALDD client discovers and selects the proper SEALDD server for the VAL application as specified in clause 9.4.3.3. The SEALDD client sends a request to the SEALDD server to configure redundant transport for the application traffic. The SEALDD client allocates a SEALDD flow ID mapping to the application traffic. The SEALDD client sends Sdd_URLLCTransmissionConnection_Establish request to SEALDD server. The request includes the SEALDD client ID, the SEALDD flow ID, the application ID, the UE ID / address, the VAL server ID / address, the QoS requirements, the UE location, and a request for redundant transport. The SEALDD client may send the protocol description received from the VAL client to the SEALDD server in the SEALDD URLLC transmission connection establishment request.4. The SEALDD server allocates IP addresses and ports for the redundant transport paths and initiates the application guidance for URSP determiniation procedure with the 5G network 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 application traffic descriptor containing the addresses or ports allocated by SEALDD server. The UE receives the new or updated URSP rules from the 5G core network. For application multi-modal service, the SEALDD server derives PDU Set related assistance information for the two redundant transmission paths based on VAL service ID and / or VAL server ID for interacting with NEF / PCF.5. The SEALDD server responds to the SEALDD client providing the configuration status. The response includes the IP addresses and ports for the redundant transmission paths allocated in step 4. The SEALDD client and SEALDD server store the mapping between the application traffic and SEALDD traffic.6. The UE establishes redundant PDU sessions with the 5G network using the new or updated URSP rules as specified in clause 5.33.2.1 of 3GPP TS 23.501 [5] .7. [Optional] The SEALDD client sends Sdd_URLLCTransmissionConnection_Update request to SEALDD server. The request includes the SEALDD client ID, the SEALDD flow ID, the application traffic descriptors for redundant transmission of the SEALDD client side (i.e. UE addresses and ports of the two redundant PDU Sessions) . The two redundant SEALDD traffic use the same SEALDD flow ID for identification.8. [Optional] The SEALDD server establishes connection with VAL server for the VAL client to transmit application traffic mapping to the redundant SEALDD traffic. The SEALDD server sends a response to the SEALDD client. After this step, the SEALDD client and SEALDD server both get the application traffic descriptors (including the UE's addresses / ports and SEALDD server's addresses / ports for the SEALDD traffic transmission) . The SEALDD client and SEALDD server store the mapping between the application traffic and SEALDD traffic.9. The SEALDD client responds with a SEALDD service response.NOTE 1: Details of the VAL client service request in step 1 and the corresponding response in step 9 are out of scope of the current specification.The VAL client sends application traffic to the SEALDD client, which duplicates the application data on the redundant PDU sessions. The SEALDD server receives the redundant traffic and reassembles the data to send to the VAL server. Similarly, the SEALDD server duplicates downlink traffic from the VAL server and sends the data to the SEALDD client on the redundant PDU sessions. The SEALDD client eliminates the redundant data and reassembles data to send to the VAL client. If packetization indication indicates that SEALDD layer needs to perform packetization, the SEALDD server performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD client for downlink application traffic. Similarly, the SEALDD client performs packetization and sends streaming data (e.g. RTP packet) via SEALDD-UU user plane (e.g. SEALDD / UDP / IP) to the SEALDD server for uplink application traffic. The SEALDD server and client also perform PDU Set marking (e.g. in RTP extension as defined in 3GPP TS 26.522 [TS26522] ) , and if needed, stream session and transport management (e.g. RTCP, RTSP) .NOTE 2: In SEALDD performed packetilization mode, to protect the stream content (e.g. if VAL service provider and SEALDD service provider are not from the same organization) , payload encryption (e.g., NAL compliant encryption for H. 264) can be implemented by VAL.9.3.2.3 SEALDD enabled URLLC transmission connection establishment based on policyThe SEALDD servers has Data Delivery (DD) policy being provisioned. The DD policy includes reliable transmission service for the associated VAL traffic. Before the application communication between VAL client and VAL server starts, the DD policy is enforced by the SEALDD server to establish the SEALDD connection.Pre-conditions:1. The SEALDD server has DD policies available.FIG. 6d shows a flowchart of policy enforced by SEALDD server for redundant connectivity.The procedure is same as step 1 to 7 in clause 9.2.2.3 with differences that:-in step 2, the SEALDD server enforces the policy to trigger URLLC transmission connection establishment.-in step 5 and 6, the SEALDD server allocates dual IP address and port for sending and receiving packet over SEALDD-UU reference point, then SEALDD server sends URLLC transmission connection establishment request to the SEALDD client with SEALDD flow ID, VAL service ID, the dual IP address and port. The SEALDD server may send the protocol description received from the VAL server to the SEALDD client in the SEALDD URLLC transmission connection establishment request. The request is responded by the SEALDD client. Dual UE IP address (and port) may be included by the SEALDD client in the response or sent in a separate update message by SEALDD client if a different UE IP address is to be used in SEALDD connection user plane.9.2.3.1 SEALDD enabled regular transmission requestTable 9.2.3.1-1 describes the information flow from the VAL server to the SEALDD server for requesting the regular application transmission service.Table 9.2.3.1-1: SEALDD enabled Regular transmission request9.2.3.7 SEALDD connection status subscription requestTable 9.2.3.7-1 describes the information flow from the VAL server to SEALDD server to subscribe to SEALDD connection status information.Table 9.2.3.7-1: SEALDD connection status subscription request9.2.3.3 SEALDD regular transmission connection establishment requestTable 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 for requesting the regular SEALDD connection establishment.Table 9.2.3.3-1: SEALDD regular transmission connection establishment request9.2.3.4 SEALDD regular transmission connection establishment responseTable 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 for responding to the regular SEALDD connection establishment.Table 9.2.3.4-1: SEALDD regular transmission connection establishment response9.3.3.3 SEALDD URLLC transmission connection establishment requestTable 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 for requesting the URLLC transmission connection establishment.Table 9.3.3.3-1: SEALDD URLLC transmission connection establishment request9.3.3.4 SEALDD URLLC transmission connection establishment responseTable 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 for responding to the URLLC transmission connection establishment.Table 9.3.3.4-1: SEALDD URLLC transmission connection establishment response

Claims

1.A method (350) performed by a first application functional entity, comprising:obtaining (352) second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsending (354) the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device.2.The method according to claim 1, wherein the obtaining the second protocol description information comprises at least one of:when the first application functional entity is a Service Enabler Architecture Layer for verticals Data Deliver (SEALDD) server, determining the second protocol description information by itself,when the first application functional entity is a SEALDD client, determining the second protocol description information by itself,when the first application functional entity is a SEALDD client, receiving the second protocol description information from a SEALDD server directly or via a Vertical Application Layer (VAL) server and a VAL client, orwhen the first application functional entity is a SEALDD server, receiving the second protocol description information from a SEALDD client directly or via a VAL client and a VAL server.3.The method according to claim 1 or 2, wherein the second protocol description information comprises at least one of:information indicating that the tunneling protocol is used in transmission of the packeted data traffic,a header length of the tunneling protocol,an offset of payload of the tunneling protocol,a location of the PDU set information, oroffset position information in a header of the tunneling protocol.4.The method according to any of claims 1-3, wherein the sending the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device comprises:when the first application functional entity is a SEALDD server, sending (362) the second protocol description information to at least one of a SEALDD client, the network exposure node, or the policy control node to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device, wherein the third application functional entity is the SEALDD client.5.The method according to any of claims 1-4, wherein the sending the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device comprises:when the first application functional entity is a SEALDD client, sending (372) the second protocol description information to at least one of a SEALDD server, the network exposure node or the policy control node, to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device, wherein the third application functional entity is the SEALDD server.6.The method according to any of claims 1-5, wherein the sending the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device comprises:when the first application functional entity is a SEALDD client, sending (382) the second protocol description information to the access network protocol layer entity of the terminal device.7.The method according to any of claims 1-6, further comprising:receiving (302) , from a second application functional entity, a first message comprising first protocol description information for transmission using a transport protocol to transmit data traffic,wherein the first protocol description information comprises uplink protocol description information and / or downlink protocol description information,wherein the data traffic is for a multi-modal service.8.The method according to claim 7, wherein the first protocol description information comprises:information indicating protocol data unit (PDU) set marking.9.The method according to claim 8, further comprising:receiving (312) the data traffic from the second application functional entity;performing (314) packetization for the data traffic; andperforming (316) PDU set marking to include PDU set information in the packeted data traffic according to the information indicating PDU set marking.10.The method according to claim 9, further comprising:receiving (322) , from the second application functional entity, a packetization indication indicating whether the first application functional entity needs to perform packetization for the data traffic,wherein performing packetization for the data traffic further comprises: performing packetization for the data traffic when the packetization indication indicates that the first application functional entity needs to perform packetization for the data traffic.11.The method according to claim 10, wherein the packetization indication is comprised in the first protocol description information.12.The method according to claim 8, further comprising:receiving (332) the packeted data traffic including PDU set information from the second application functional entity.13.The method according to any of claims 9-11, wherein the PDU set information is included in a header extension in the packeted data traffic.14.The method according to any of claims 9-13, further comprising:deriving (342) at least one PDU set quality of service (QoS) parameter from an identifier of a service and / or an identifier of an application functional entity providing the service; andsending (344) , to a network exposure node or a policy control node, the at least one PDU set QoS parameter, using a procedure of setting up an application function session with required QoS.15.The method according to any of claims 9-14, wherein the data traffic is encrypted by the second application functional entity and cannot be decrypted by the first application functional entity.16.The method according to any of claims 9-15, whereinthe 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, orthe first application functional entity is a SEALDD server and the second application functional entity is a SEALDD client, orthe first application functional entity is a SEALDD client and the second application functional entity is a SEALDD server.17.The method according to any of claims 9-16, wherein the first message comprises at least one of:one or more SEALDD enabled regular transmission requests,one or more SEALDD connection status subscription requests,one or more SEALDD service requests,one or more SEALDD regular transmission connection establishment requests,one or more SEALDD regular transmission connection establishment responses,one or more SEALDD Ultra Reliable Low Latency Communication (URLLC) transmission connection establishment requests, orone or more SEALDD URLLC transmission connection establishment responses.18.The method according to claim 1, wherein the obtaining the second protocol description information comprises at least one of:when the first application functional entity is a VAL client, determining the second protocol description information, orwhen the first application functional entity is a VAL server, determining the second protocol description information.19.The method according to claim 1 or 18, wherein the sending the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device comprises:when the first application functional entity is a VAL client or a VAL server, sending (392) the second protocol description information to the network exposure node or the policy control node, to enable the second protocol description information is to be sent to a user plane function and / or the access network protocol layer entity of the terminal device.20.A method (460) performed by a network exposure node, comprising:receiving (462) , from a first application functional entity, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsending (464) the second protocol description information to a policy control node.21.The method according to claim 20, further comprising:receiving (472) , from the first application functional entity, at least one PDU set quality of service (QoS) parameter; andsending (474) the at least one PDU set QoS parameter to the policy control node.22.The method according to claim 20 or 21, wherein the second protocol description information comprises at least one of:information indicating that the tunneling protocol is used in transmission of the packeted data traffic,a header length of the tunneling protocol,an offset of payload of the tunneling protocol,a location of the PDU set information, oroffset position information in a header of the tunneling protocol.23.The method according to any of claims 20-22, wherein the first application functional entity comprises a SEALDD server or a SEALDD client or a VAL server or a VAL client.24.A method (480) performed by a policy control node, comprising:receiving (482) , from a first application functional entity or a network exposure node, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsending (484) the second protocol description information to a session management node.25.The method according to claim 24, further comprising:receiving (492) , from the first application functional entity or the network exposure node, at least one PDU set quality of service (QoS) parameter; anddetermining (494) a policy and charging control (PCC) rule based on the at least one PDU set QoS parameter and the second protocol description information.26.The method according to claim 24 or 25, wherein the second protocol description information comprises at least one of:information indicating that the tunneling protocol is used in transmission of the packeted data traffic,a header length of the tunneling protocol,an offset of payload of the tunneling protocol,a location of the PDU set information, oroffset position information in a header of the tunneling protocol.27.The method according to any of claims 24-26, wherein the first application functional entity comprises a SEALDD server or a SEALDD client or a VAL server or a VAL client.28.A method (4900) performed by a session management node, comprising:receiving (4902) , from a policy control node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsending (4904) the second protocol description information to a user plane function and / or an access network protocol layer entity of a terminal device.29.The method according to claim 28, wherein the second protocol description information comprises at least one of:information indicating that the tunneling protocol is used in transmission of the packeted data traffic,a header length of the tunneling protocol,an offset of payload of the tunneling protocol,a location of the PDU set information, oroffset position information in a header of the tunneling protocol.30.A method (4910) performed by an access network protocol layer entity of a terminal device, comprising:receiving (4912) , from a session management node or a first application functional entity, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information;receiving (4914) the packeted data traffic including the PDU set information transmitted using the tunneling protocol; andprocessing (4916) the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information.31.The method according to claim 30, wherein the second protocol description information comprises at least one of:information indicating that the tunneling protocol is used in transmission of the packeted data traffic,a header length of the tunneling protocol,an offset of payload of the tunneling protocol,a location of the PDU set information, oroffset position information in a header of the tunneling protocol.32.The method according to any of claims 30-31, wherein the first application functional entity comprises a SEALDD client.33.A method (4920) performed by a user plane function, comprising:receiving (4922) , from a session management node, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information;receiving (4924) the packeted data traffic including the PDU set information transmitted using the tunneling protocol; andprocessing (4926) the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information.34.The method according to claim 33, wherein the second protocol description information comprises at least one of:information indicating that the tunneling protocol is used in transmission of the packeted data traffic,a header length of the tunneling protocol,an offset of payload of the tunneling protocol,a location of the PDU set information, oroffset position information in a header of the tunneling protocol.35.A first application functional entity (700) , comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said first application functional entity (700) is operative to:obtain second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsend the second protocol description information to at least one of a third application functional entity, a network exposure node, a policy control node, an access network protocol layer entity of a terminal device.36.The first application functional entity according to claim 35, wherein the first application functional entity is further operative to perform the method of any one of claims 2 to 19.37.A network exposure node (700) , comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said network exposure node (700) is operative to:receive from a first application functional entity, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsend the second protocol description information to a policy control node.38.The network exposure node according to claim 37, wherein the network exposure node is further operative to perform the method of any one of claims 21 to 23.39.A policy control node (700) , comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said policy control node (700) is operative to:receive, from a first application functional entity or a network exposure node, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsend the second protocol description information to a session management node.40.The policy control node according to claim 39, wherein the policy control node is further operative to perform the method of any one of claims 25 to 27.41.A session management node (700) , comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said session management node (700) is operative to:receive, from a policy control node, second protocol description information for transmission of packeted data traffic including PDU set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information; andsend the second protocol description information to a user plane function and / or an access network protocol layer entity of a terminal device.42.The session management node according to claim 41, wherein the session management node is further operative to perform the method of claim 29.43.An access network protocol layer entity (700) of a terminal device, comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said access network protocol layer entity (700) is operative to:receive, from a session management node or a first application functional entity, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information;receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol; andprocess the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information.44.The access network protocol layer entity according to claim 43, wherein the access network protocol layer entity is further operative to perform the method of any one of claims 31 to 32.45.A user plane function (700) , comprising:a processor (721) ; anda memory (722) coupled to the processor (721) , said memory (722) containing instructions executable by said processor (721) , whereby said user plane function (700) is operative to:receive, from a session management node, second protocol description information for transmission of packeted data traffic including protocol data unit (PDU) set information using a tunneling protocol, wherein the second protocol description information comprises uplink protocol description information and / or downlink protocol description information;receive the packeted data traffic including the PDU set information transmitted using the tunneling protocol; andprocess the packeted data traffic including the PDU set information transmitted using the tunneling protocol based on the second protocol description information.46.The user plane function according to claim 45, wherein the user plane function is further operative to perform the method of claim 34.47.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 34.48.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 34.

Images