Communication method, device and system for task session

Abstract

The invention provides a communication method, device and system for a task session. The method comprises: receiving a packet; the present invention relates to a method and a device for transmitting a general packet radio service (GPRS) packet generated on the basis of a packet and a general packet radio service (GPRS) user plane tunneling protocol (GTP) protocol, in which the GTP-U packet includes information on a task session for providing a task service to a task customer, the task service being a service for both packet data unit (PDU) connection and data processing, and a method for transmitting a GTP-U packet generated on the basis of the packet and the GTP-U protocol, in which the GTP-U packet includes information on a task session for providing a task service to the task customer.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 541,522, filed September 29, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to the field of communication technology, and more particularly to a communication method, apparatus and system for task sessions. Background Technology

[0004] Many emerging trends will drive the consideration and design of 6G / future wireless networks: new network infrastructure capabilities, such as widely deployed cloud-native / friendly infrastructure; emerging (relatively) mature technologies, such as large-scale AI models, data privacy, and blockchain, which have made significant progress and have had a major impact on society and human life; new applications and services, such as AI services, data (sensing) services, and digital world services, which are widely used in the industrial / commercial sectors and by individual customers; and the increasingly significant trend of globalization / openness / collaboration, meaning that more open and collaborative operating models are becoming common practice in many fields.

[0005] However, for next-generation networks (such as sixth generation (6G) or higher), or (for example, traditional networks in the 6G era such as fifth generation (5G), fourth generation (4G), third generation (3G), or second generation (2G)) networks, 6G networks are expected to support not only connectivity but also data processing.

[0006] The purpose of providing background information is to disclose information that the applicant believes may be relevant to this application. It is neither necessary to acknowledge nor should it be construed as any of the aforementioned information constituting prior art relative to this application. Summary of the Invention

[0007] In a first aspect, this disclosure provides a communication method, including...

[0008] Receive packets;

[0009] Send GTP-U packets generated based on the aforementioned packets and the General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) protocol, wherein the GTP-U packets include information about a mission session used to provide mission services to mission clients, the mission services being services that simultaneously support packet data unit (PDU) connectivity and data processing.

[0010] In this way, task services can be supported by information about the task session included in the GTP-U packet.

[0011] In a second aspect, this disclosure provides a communication method, comprising:

[0012] Receive General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) packets, wherein the GTP-U packets are packets based on the GTP-U protocol, and the GTP-U packets include information about a task session, the task session being used to provide task services to task clients, the task services being services that are used for both packet data unit (PDU) connectivity and data processing;

[0013] Based on the information about the task session, determine the task session to which the GTP-U packet belongs.

[0014] In this way, the network entity receiving the GTP-U packet can identify the task session to which the GTP-U packet belongs by using information about the task session.

[0015] In one possible implementation of the first or second aspect, the task session includes one or more data sessions, each data session including an association terminating at a computing block (CB) entity, the CB entity executing at least one CB of a task, the task including one or more CBs, each CB corresponding to a computational step that implements the task service.

[0016] In one possible implementation of the first or second aspect, the data processing includes the at least one CB that performs the task.

[0017] In one possible implementation of the first or second aspect, the CB entity is deployed in one of the following: a device, a radio access network (RAN), a core network (CN), and a data network (DN).

[0018] In one possible implementation of the first or second aspect, the computational steps for implementing the task service include one or more of the following: artificial intelligence (AI) training, AI inference, data preprocessing, data privacy protection, data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, data aggregation, data segmentation, useless data filtering, data formatting, data adaptation, data feature engineering, data compression, data embedding, data representation learning, or data feature extraction.

[0019] In one possible implementation of the first or second aspect, the task session further includes one or more gateway (GW) sessions, each GW session including an association between two GW entities, each GW entity being used to support communication between CB entities.

[0020] In one possible implementation of the first or second aspect, the information about the task session is included in the packet header of the GTP-U packet or the payload of the GTP-U packet.

[0021] In one possible implementation of the first or second aspect, the GTP-U packets are transmitted via a GTP-U tunnel dedicated to data sessions.

[0022] In other words, the granularity of a GTP-U tunnel can be a data session.

[0023] In one possible implementation of the first or second aspect, the information regarding the task session includes a quality of service (QoS) flow identifier (QFI) and / or a computing block ID (CBID), wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session, and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

[0024] In one possible implementation of the first or second aspect, the information about the task session is included in the packet header of the GTP-U packet, the packet header including a GTP-U extension header, and the QFI and / or the CBID included in the GTP-U extension header.

[0025] In one possible implementation of the first aspect or the second aspect, the GTP-U extension header is a first type of GTP-U extension header, which is a data session container.

[0026] In this way, a new type of extension header (i.e., data session container) is defined at the granularity of data session; since the GTP-U tunnel is dedicated to the data session of the task session, the network entity that receives the GTP-U packet including the data session container from the tunnel can quickly and accurately determine the data session to which the GTP-U packet belongs.

[0027] In one possible implementation of the first or second aspect, the information regarding the task session includes a first field, which is indicated by the first type of GTP-U extension header.

[0028] In one possible implementation of the first aspect or the second aspect, the value of the first field is 1000 1000.

[0029] In one possible implementation of the first or second aspect, the first field indicates that the GTP-U tunnel is dedicated to the data session by indicating the first type of GTP-U extension header.

[0030] In one possible implementation of the first or second aspect, the GTP-U extension header is a second type of GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the second type of GTP-U extension header is used for a data session.

[0031] In this way, existing containers (such as PDU session containers) can be reused to distinguish the data session to which the received GTP-U packets belong.

[0032] In one possible implementation of the first or second aspect, the indication is included in the second type of GTP-U extension header, or

[0033] The information about the task session includes a second field, and the indication is included in the second field.

[0034] In one possible implementation of the first or second aspect, the indication is 2 bits, the value of which indicates that the second type of GTP-U extension header is used for a PDU session or a data session.

[0035] In one possible implementation of the first or second aspect, the information about the task session includes a second field, and the indication is indicated by a range of values ​​for the second field.

[0036] In one possible implementation of the first or second aspect, the GTP-U packets are transmitted via a GTP-U tunnel dedicated to inter-GW sessions.

[0037] In other words, the granularity of GTP-U tunnels can be inter-GW sessions.

[0038] In one possible implementation of the first or second aspect, the information regarding the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the inter-GW session, and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

[0039] In one possible implementation of the first or second aspect, the information about the task session is included in the packet header of the GTP-U packet, the packet header including a GTP-U extension header, and the QFI and / or the CBID included in the GTP-U extension header.

[0040] In one possible implementation of the first aspect or the second aspect, the GTP-U extension header is a first type of GTP-U extension header, which is a GW inter-session container.

[0041] In this way, a new type of extension header (i.e., inter-GW session container) is defined at the granularity of inter-GW sessions; since GTP-U tunnels are dedicated to inter-GW sessions of task sessions, network entities that receive GTP-U packets containing inter-GW session containers from the tunnel can quickly and accurately determine the inter-GW session to which the GTP-U packet belongs.

[0042] In one possible implementation of the first or second aspect, the information regarding the task session includes a first field, which is indicated by the first type of GTP-U extension header.

[0043] In one possible implementation of the first aspect or the second aspect, the value of the first field is 1000 1001.

[0044] In one possible implementation of the first aspect or the second aspect, the first field indicates that the GTP-U tunnel is dedicated to the inter-GW session by indicating the first type of GTP-U extension header.

[0045] In one possible implementation of the first or second aspect, the GTP-U extension header is a second type of GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the second type of GTP-U extension header is used for inter-GW sessions.

[0046] In this way, existing containers (such as PDU session containers) can be reused to distinguish the inter-GW session to which the received GTP-U packets belong.

[0047] In one possible implementation of the first or second aspect, the indication is included in the second type of GTP-U extension header, or

[0048] The information about the task session includes a second field, and the indication is included in the second field.

[0049] In one possible implementation of the first or second aspect, the indication is 2 bits, the value of which indicates that the second type of GTP-U extension header is used for PDU sessions or GW-to-GW sessions.

[0050] In one possible implementation of the first or second aspect, the information about the task session includes a second field, and the indication is indicated by a range of values ​​for the second field.

[0051] In one possible implementation of the first or second aspect, the GTP-U packets are transmitted via a GTP-U tunnel dedicated to the task session and shared by one or more data sessions and / or one or more inter-GW sessions of the task session.

[0052] In other words, the granularity of GTP-U tunnels can be at the task session level.

[0053] In one possible implementation of the first or second aspect, the information about the task session includes one or both of a data session ID and auxiliary information, wherein the data session ID is used to identify a data session included in the one or more data sessions, and the auxiliary information is used to assist in distinguishing the data session or distinguishing CB.

[0054] In one possible implementation of the first or second aspect, the information regarding the task session further includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session; and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

[0055] In one possible implementation of the first or second aspect, the information about the task session includes one or both of the following: an inter-GW session ID and auxiliary information, wherein the inter-GW session ID is used to identify an inter-GW session and the auxiliary information is used to assist in distinguishing between inter-GW sessions or between CBs.

[0056] In one possible implementation of the first or second aspect, the information regarding the task session further includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the inter-GW session; and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

[0057] In one possible implementation of the first or second aspect, the information about the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows in the task session; and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

[0058] In one possible implementation of the first or second aspect, the information about the task session is included in the packet header of the GTP-U packet, the packet header including a GTP-U extension header, which includes one or more of the following: the data session ID, the inter-GW session ID, the auxiliary information, the QFI, or the CBID.

[0059] In one possible implementation of the first aspect or the second aspect, the GTP-U extension header is a first type of GTP-U extension header, which is a task session container.

[0060] In this way, a new type of extension header (i.e., task session container) is defined at the granularity of task session. Since the GTP-U tunnel is dedicated to task sessions, the network entity that receives a packet containing a task session container from the tunnel can determine the task session to which the GTP-U packet belongs based on the information about the task session included in the task session container (such as data session ID, inter-GW session ID, and auxiliary information), and further determine the data session (or inter-GW session) to which the GTP-U packet belongs.

[0061] In one possible implementation of the first or second aspect, the information regarding the task session includes a first field, which is indicated by the first type of GTP-U extension header.

[0062] In one possible implementation of the first aspect or the second aspect, the value of the first field is 1000 1010.

[0063] In one possible implementation of the first or second aspect, the first field indicates that the GTP-U tunnel is dedicated to the task session by indicating the first type of GTP-U extension header.

[0064] In this way, existing containers (such as PDU session containers) can be reused to distinguish task sessions and further distinguish the data sessions (or inter-GW sessions) of the task sessions to which the received GTP-U packets belong.

[0065] In one possible implementation of the first or second aspect, the GTP-U extension header is a second type of GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the second type of GTP-U extension header is used for a task session.

[0066] In one possible implementation of the first or second aspect, the indication is included in the second type of GTP-U extension header, or

[0067] The information about the task session includes a second field, and the indication is included in the second field.

[0068] In one possible implementation of the first or second aspect, the indication is 2 bits, the value of which indicates that the second type of GTP-U extension header is used for a PDU session or a task session.

[0069] In one possible implementation of the first or second aspect, the information about the task session includes a second field, and the indication is indicated by a range of values ​​for the second field.

[0070] In one possible implementation of the first or second aspect, the GTP-U packets are transmitted via a GTP-U tunnel dedicated to the CB entity and shared by one or more task sessions of the CB entity, the one or more task sessions including the task session.

[0071] In other words, the granularity of a GTP-U tunnel can be a CB entity.

[0072] In one possible implementation of the first aspect or the second aspect, the information about the task session includes one or more of the following: task session ID, data session ID, or auxiliary information; the task session ID is used to identify a first task session, the data session ID is used to identify a data session included in the first task session, and the auxiliary information is used to assist in distinguishing the data session or distinguishing CB.

[0073] In one possible implementation of the first or second aspect, the information regarding the task session further includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session; and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

[0074] In one possible implementation of the first or second aspect, the information in the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows of the one or more task sessions of the CB entity, and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

[0075] In one possible implementation of the first or second aspect, the information about the task session is included in the packet header of the GTP-U packet, the packet header including a GTP-U extension header, which includes one or more of the following: the task session ID, the data session ID, the auxiliary information, the QFI, or the CBID.

[0076] In one possible implementation of the first or second aspect, the GTP-U extension header is a first type of GTP-U extension header, which is a CB entity container.

[0077] In this way, a new type of extension header (i.e., CB entity container) is defined for the granularity of CB entity; the network entity that receives a GTP-U packet including a CB entity container from the tunnel can determine the data session of the task session to which the packet belongs based on the information about the task session (such as task session ID, data session ID and auxiliary information) included in the CB entity container.

[0078] In one possible implementation of the first or second aspect, the information regarding the task session includes a first field, which is indicated by the first type of GTP-U extension header.

[0079] In one possible implementation of the first aspect or the second aspect, the value of the first field is 1000 1011.

[0080] In one possible implementation of the first or second aspect, the first field indicates that the GTP-U tunnel is dedicated to the CB entity by indicating the first type of GTP-U extension header.

[0081] In one possible implementation of the first or second aspect, the GTP-U extension header is a second type of GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the second type of GTP-U extension header is used for a CB entity.

[0082] In this way, existing containers (such as PDU session containers) can be reused to distinguish task sessions and further distinguish the data sessions of the task sessions to which the received GTP-U packets belong.

[0083] In one possible implementation of the first or second aspect, the indication is included in the second type of GTP-U extension header, or

[0084] The information about the task session includes a second field, and the indication is included in the second field.

[0085] In one possible implementation of the first or second aspect, the indication is 2 bits, the value of which indicates that the second type of GTP-U extension header is used for a PDU session or CB entity.

[0086] In one possible implementation of the first or second aspect, the information about the task session includes a second field, and the indication is indicated by a range of values ​​for the second field.

[0087] In one possible implementation of the first or second aspect, the GTP-U packets are transmitted via a GTP-U tunnel dedicated to the GW entity and shared by one or more task sessions of the GW entity, the one or more task sessions including the task session.

[0088] In other words, the granularity of a GTP-U tunnel can be a GW entity.

[0089] In one possible implementation of the first aspect or the second aspect, the information about the task session includes one or more of the following: task session ID, data session ID, or first auxiliary information, or includes one or more of the following: task session ID, inter-GW session ID, or second auxiliary information;

[0090] The task session ID is used to identify the first task session, the data session ID is used to identify the data session included in the first task session, and the first auxiliary information is used to assist in distinguishing the data session or distinguishing CB; or

[0091] The task session ID is used to identify the first task session, the inter-GW session ID is used to identify the inter-GW session included in the first task session, and the second auxiliary information is used to assist in distinguishing the inter-GW session or distinguishing the CB.

[0092] In one possible implementation of the first or second aspect, the information regarding the task session further includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session or the inter-GW session; and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

[0093] In one possible implementation of the first or second aspect, the information about the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows of the one or more task sessions of the GW entity, and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

[0094] In one possible implementation of the first or second aspect, the information about the task session is included in the packet header of the GTP-U packet, the packet header including a GTP-U extension header, which includes one or more of the following: the task session ID, the data session ID, the inter-GW session ID, the first auxiliary information, the second auxiliary information, the QFI, or the CBID.

[0095] In one possible implementation of the first aspect or the second aspect, the GTP-U extension header is a first type of GTP-U extension header, and the first type of GTP-U extension header is a GW entity container.

[0096] In this way, a new type of extension header (i.e., GW entity container) is defined at the granularity of GW entity; the network entity that receives a GTP-U packet containing a GW entity container from the tunnel can determine the data session (or inter-GW session) of the task session to which the GTP-U packet belongs based on the information about the task session included in the GW entity container (such as task session ID, data session ID, inter-GW session ID and auxiliary information).

[0097] In one possible implementation of the first or second aspect, the information regarding the task session includes a first field, which is indicated by the first type of GTP-U extension header.

[0098] In one possible implementation of the first aspect or the second aspect, the value of the first field is 1000 1100.

[0099] In one possible implementation of the first or second aspect, the first field indicates that the GTP-U tunnel is dedicated to the GW entity by indicating the first type of GTP-U extension header.

[0100] In one possible implementation of the first or second aspect, the GTP-U extension header is a second type of GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the second type of GTP-U extension header is used for a GW entity.

[0101] In this way, existing containers (such as PDU session containers) can be reused to distinguish task sessions and further distinguish the data sessions (or inter-GW sessions) of the task sessions to which the received GTP-U packets belong.

[0102] In one possible implementation of the first or second aspect, the indication is included in the second type of GTP-U extension header, or

[0103] The information about the task session includes a second field, and the indication is included in the second field.

[0104] In one possible implementation of the first or second aspect, the indication is 2 bits, the value of which indicates that the second type of GTP-U extension header is used for a PDU session or GW entity.

[0105] In one possible implementation of the first or second aspect, the information about the task session includes a second field, and the indication is indicated by a range of values ​​for the second field.

[0106] In one possible implementation of the first or second aspect, the second field is a tunnel endpoint identifier (TEID).

[0107] In one possible implementation of the first aspect or the second aspect, the auxiliary information, the first auxiliary information or the second auxiliary information includes one or more of the following: an operation ID that identifies a data processing operation, a CBID that identifies a CB, a step ID that identifies a process step, or a task client ID that identifies a task session client.

[0108] In one possible implementation of the first aspect or the second aspect, the second type of GTP-U extension header includes one or more of the following: PDU session container, radio access network (RAN) container, new radio (NR) RAN container, or Xw RAN container.

[0109] In one possible implementation of the first or second aspect, the task service is simplified to a service that supports only PDU connections.

[0110] In one possible implementation of the first or second aspect, the task session is simplified to a PDU session used for the PDU connection.

[0111] In one possible implementation of the first or second aspect, there is no CB entity participating in the task session, or all CB entities participating in the task session are pseudo-CB entities.

[0112] In one possible implementation of the first aspect or the second aspect, there is no data session belonging to the task session, or all data sessions belonging to the task session are pseudo-data sessions.

[0113] In a third aspect, this disclosure provides a communication device, comprising:

[0114] The receiving module is used to receive packets;

[0115] The transmitting module is used to transmit GTP-U packets generated based on the packets and the General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U). The GTP-U packets include information about a task session, which is used to provide task services to task clients. The task services are services that are used for both packet data unit (PDU) connection and data processing.

[0116] In a fourth aspect, this disclosure provides a communication device, comprising:

[0117] The receiving module is used to receive General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U) packets, wherein the GTP-U packets are packets based on the GTP-U protocol, and the GTP-U packets include information about a task session, the task session being used to provide task services to task clients, the task services being services that are used for both packet data unit (PDU) connection and data processing;

[0118] The determination module is used to determine the task session to which the GTP-U packet belongs based on the information about the task session.

[0119] In a fifth aspect, this disclosure provides an apparatus including processing circuitry for performing the method in the first aspect or the second aspect or any possible implementation thereof.

[0120] In a sixth aspect, this disclosure provides a chip including an input / output (I / O) interface and a processor, wherein the processor is configured to call and run a computer program stored in a memory to cause a device on which the chip is mounted to perform the methods of the first aspect or the second aspect or any possible implementation thereof.

[0121] In a seventh aspect, this disclosure provides an apparatus comprising:

[0122] One or more processors, wherein

[0123] The one or more processors are configured to execute instructions stored in memory, and when the instructions are executed by the one or more processors, to perform the method of the first aspect or any possible implementation thereof.

[0124] In an eighth aspect, this disclosure provides an apparatus comprising:

[0125] One or more processors, wherein

[0126] The one or more processors are configured to execute instructions stored in memory, and when the instructions are executed by the one or more processors, to perform the method of the second aspect or any possible implementation thereof.

[0127] In a ninth aspect, this disclosure provides a communication system including the apparatus of the seventh aspect and the apparatus of the eighth aspect.

[0128] In a tenth aspect, this disclosure provides a non-transitory computer-readable medium carrying program code that, when executed by a processor, performs the method described in the first aspect or the second aspect or any possible implementation thereof.

[0129] In an eleventh aspect, this disclosure provides a computer program product comprising program code for performing the method in the first aspect or the second aspect or any possible implementation thereof. Attached Figure Description

[0130] The accompanying drawings are provided to further understand the present disclosure and form part of the specification. They are used to explain the present disclosure and the following specific exemplary embodiments, but should not be construed as limiting the present disclosure.

[0131] Figure 1 This is a simplified schematic diagram of a communication system according to one or more embodiments of the present disclosure.

[0132] Figure 2 This is a schematic diagram of an exemplary communication system according to one or more embodiments of the present disclosure.

[0133] Figure 3 This is a schematic diagram of the basic component structure of a communication system according to one or more embodiments of the present disclosure.

[0134] Figure 4 A block diagram of a device in a communication system according to one or more embodiments of the present disclosure is shown.

[0135] Figure 5 A block diagram illustrating the conceptual structure of a 6G system according to one or more embodiments of the present disclosure is shown.

[0136] Figure 6 This is a schematic diagram of a 5G PDU session according to one or more embodiments of the present disclosure.

[0137] Figure 7 This is a schematic diagram of the structure of a GTP-U packet header according to one or more embodiments of the present disclosure.

[0138] Figure 8 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure.

[0139] Figure 9 This is a schematic diagram of the format of a GTP-U extension header according to one or more embodiments of the present disclosure.

[0140] Figure 10 This is a schematic diagram of the format of downlink (DL) PDU session information according to one or more embodiments of this disclosure.

[0141] Figure 11 This is a schematic diagram of the format of uplink (UL) PDU session information according to one or more embodiments of this disclosure.

[0142] Figure 12 This is a schematic diagram of a task service provided by a 6G network according to one or more embodiments of the present disclosure.

[0143] Figure 13 This is a schematic diagram of a task session for a task service according to one or more embodiments of the present disclosure.

[0144] Figure 14 This is a schematic diagram illustrating the configuration of tunnels for data (inter-GW) sessions according to one or more embodiments of this disclosure.

[0145] Figure 15 This is a schematic diagram of configuring tunnels per task session according to one or more embodiments of the present disclosure.

[0146] Figure 16 This is a schematic diagram of configuring tunnels by network entity according to one or more embodiments of the present disclosure.

[0147] Figure 17 This is a schematic flowchart of a communication method according to one or more embodiments of the present disclosure.

[0148] Figure 18 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure.

[0149] Figure 19 This is a schematic diagram illustrating the evolution format of downlink (DL) PDU session information according to one or more embodiments of this disclosure.

[0150] Figure 20 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure.

[0151] Figure 21 This is a schematic diagram of the format of DL task session information according to one or more embodiments of the present disclosure.

[0152] Figure 22 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure.

[0153] Figure 23 This is a schematic diagram illustrating the format of DL CB entity information according to one or more embodiments of this disclosure.

[0154] Figure 24 This is a schematic diagram illustrating the format of DL GW entity information according to one or more embodiments of this disclosure.

[0155] Figure 25 This is a schematic diagram of the structure of a communication device according to one or more embodiments of the present disclosure. Detailed Implementation

[0156] In the following description, reference is made to the accompanying drawings, which form a part of this disclosure, which illustrate by way of description specific aspects of the present disclosure or aspects in which the present disclosure may be used. It should be understood that the present disclosure may be used in other aspects and may include structural or logical variations not shown in the drawings. Therefore, the following detailed description should not be construed in a limiting sense, and the scope of this disclosure is defined by the appended claims.

[0157] To aid in understanding this disclosure, examples of wireless communication systems and devices are described below.

[0158] Exemplary communication systems and devices

[0159] Figure 1 This is a simplified schematic diagram of a communication system according to one or more embodiments of the present disclosure. Reference Figure 1 , Figure 1As a non-limiting illustrative example, a simplified schematic diagram of a communication system is provided. Communication system 100 includes a radio access network 120. Radio access network 120 may be a next-generation (such as sixth-generation, 6G, or later) radio access network, or a traditional (such as 5G, 4G, 3G, or 2G) radio access network. One or more electronic devices (EDs) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generally referred to as 110) may be interconnected with each other or connected to one or more network nodes (170a, 170b, generally referred to as 170) in radio access network 120. Core network 130 may be part of the communication system and may depend on or be independent of the radio access technology used in communication system 100. Communication system 100 also includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0160] Figure 2 This is a schematic diagram of an exemplary communication system according to one or more embodiments of the present disclosure. Figure 2 An exemplary communication system 100 is illustrated. Generally, the communication system 100 enables multiple wireless or wired components to transmit data and other content. The purpose of the communication system 100 may be to provide content such as voice, data, video, and / or text via broadcast, multicast, unicast, etc. The communication system 100 can operate by sharing resources (such as carrier spectrum bandwidth) among its constituent components. The communication system 100 may include terrestrial communication systems and / or non-terrestrial communication systems. The communication system 100 can provide a wide range of communication services and applications (such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery, and mobility). The communication system 100 can provide high availability and robustness through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can form a multi-layered heterogeneous network. Compared to traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0161] Terrestrial communication systems and non-terrestrial communication systems can be considered subsystems of a communication system. Figure 2In the example shown, communication system 100 includes electronic devices (EDs) 110a, 110b, 110c, and 110d (generally referred to as ED 110), radio access networks (RANs) 120a and 120b, a non-terrestrial communication network 120c, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. RANs 120a and 120b include corresponding base stations (BSs) 170a and 170b, which are generally referred to as terrestrial transmit and receive points (T-TRPs) 170a and 170b. The non-terrestrial communication network 120c includes access nodes 172, which are generally referred to as non-terrestrial transmit and receive points (NT-TRPs) 172.

[0162] Alternatively or additionally, any ED 110 can be used to connect, access, or communicate with any T-TRP 170a, 170b, and NT-TRP 172, the Internet 150, the core network 130, the PSTN 140, other networks 160, or any combination thereof. In some examples, ED 110a can communicate uplink and / or downlink with T-TRP 170a via terrestrial air interface 190a. In some examples, ED 110a, 110b, 110c, and 110d can also communicate directly with each other via one or more sidelink air interfaces 190b. In some examples, ED 110d can communicate uplink and / or downlink with NT-TRP 172 via non-terrestrial air interface 190c.

[0163] Air interfaces 190a and 190b can use similar communication technologies, such as any suitable wireless access technology. For example, communication system 100 can implement one or more channel access methods in air interfaces 190a and 190b, such as code division multiple access (CDMA), space division multiple access (SDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA, also known as discrete Fourier transform spread OFDMA (DFT-s-OFDMA)). Air interfaces 190a and 190b can utilize other high-dimensional signal spaces, which may include combinations of orthogonal and / or non-orthogonal dimensions.

[0164] The non-terrestrial air interface 190c enables communication between the ED 110d and one or more NT-TRP 172s via a wireless link or a simple link. In some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of ED 110s and one or more NT-TRP 172s for multicast transmission.

[0165] RANs 120a and 120b communicate with the core network 130 to provide various services, such as voice, data, and other services, to EDs 110a, 110b, and 110c. RANs 120a and 120b and / or the core network 130 can communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by the core network 130, and may or may not use the same radio access technology as RANs 120a, RAN 120b, or both. The core network 130 can also serve as a gateway access between (i) RANs 120a and 120b or EDs 110a, 110b, and 110c, or both, and (ii) other networks (such as PSTN 140, Internet 150, and other networks 160). Additionally, some or all of the EDs in EDs 110a, 110b, and 110c may include the ability to communicate with different wireless networks via different radio links using different radio technologies and / or protocols. ED 110a, 110b, and 110c can communicate with a service provider or exchange (not shown) via a wired communication channel and with the Internet 150, but not wirelessly (or also wirelessly). PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include a computer network and / or subnet (intranet) and incorporate protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). ED 110a, 110b, and 110c may be multimode devices capable of operating under various wireless access technologies and include multiple transceivers required to support such technologies.

[0166] Basic component structure

[0167] Figure 3 This is a schematic diagram of the basic component structure of a communication system according to one or more embodiments of the present disclosure. Figure 3Another example of the ED 110 and base stations 170a, 170b, and / or 170c is shown. The ED 110 is used to connect people, objects, machines, etc. The ED 110 can be widely used in various scenarios, including: for example, cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communications (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), metaverse, digital twin, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, and so on.

[0168] Each ED 110 represents any suitable end-user equipment for wireless operation and may include (or be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smart book, vehicle, car, truck, bus, train, or IoT device, wearable device (such as watch, glasses, head-mounted device, etc.), industrial equipment, or devices that include or incorporate the above-mentioned equipment (such as communication modules, modems, or chips), etc. Next-generation ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs, referred to below as T-TRP 170. Furthermore, as Figure 3As shown, NT-TRP is referred to as NT-TRP 172 below. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically started (i.e., established, activated, or enabled), shut down (i.e., released, deactivated, or disabled), and / or configured in response to one or more of connectivity availability and connectivity necessity.

[0169] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown in the figure to avoid clutter. One, some, or all of the antennas 204 may also be panels. The transmitter 201 and receiver 203 may be integrated, for example, integrated as a transceiver. The transceiver is used to modulate data or other content for transmission through at least one antenna 204 or a network interface controller (NIC). The transceiver may also be used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0170] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or collected by ED 110. For example, memory 208 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by one or more processing units (such as processor 210). Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, and on-processor cache, etc.

[0171] ED 110 may also include one or more input / output devices (not shown) or interfaces (such as those connected to...). Figure 1(Wired interface of Internet 150 in the network). Input / output devices or interfaces support interaction with other devices or users in the network. Each input / output device or interface includes any suitable structure for providing or receiving information from the user and / or for network interface communication. Suitable structures include speakers, microphones, keypads, keyboards, displays, touchscreens, etc.

[0172] ED 110 includes a processor 210 for performing the following operations: operations related to preparing uplink transmissions for NT-TRP 172 and / or T-TRP 170; operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170; and operations related to processing sidelink transmissions to and from other ED 110. Processing operations related to preparing uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to an embodiment, the downlink transmission may be received by receiver 203 using receive beamforming, and processor 210 may extract signaling from the downlink transmission (e.g., by detecting and / or decoding signaling). An example of signaling may be a reference signal transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, processor 210 performs transmit beamforming and / or receive beamforming based on beam direction indications (such as beam angle information (BAI)) received from T-TRP 170. In some embodiments, processor 210 may perform operations related to network access (such as initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some embodiments, processor 210 may perform channel estimation, for example, using reference signals received from NT-TRP 172 and / or T-TRP 170.

[0173] Processor 210 may be part of transmitter 201 and / or receiver 203, but is not shown in the figures. Memory 208 may be part of processor 210, but is not shown in the figures.

[0174] The processing components in processor 210, transmitter 201, and receiver 203 can be implemented by the same or different processors, which execute instructions stored in memory (such as memory 208). Alternatively, some or all of the processing components in processor 210, transmitter 201, and receiver 203 can be implemented using dedicated circuits such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or hardware accelerators such as graphics processing units (GPUs) or artificial intelligence (AI) accelerators.

[0175] In some implementations, the T-TRP 170 can have other names, such as base station, base transceiver station (BTS), wireless base station, network node, network device, network-side device, transmit / receive node, NodeB, evolved NodeB (eNodeB or eNB), home eNodeB, next-generation NodeB (gNB), transmission point (TP), site controller, access point (AP), wireless router, relay station, ground node, ground network device, ground base station, base band unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), location node, etc. The T-TRP 170 can be a macro BS, pico BS, relay node, or donor node, or a combination thereof. T-TRP 170 can refer to the aforementioned equipment or to a component within the aforementioned equipment (such as a communication module, modem, or chip).

[0176] In some embodiments, the various parts of T-TRP 170 may be distributed. For example, some modules in T-TRP 170 may be located remotely from the device housing the antenna 256 of T-TRP 170 and may be coupled to the device housing the antenna 256 via a communication link (not shown) sometimes referred to as a fronthaul (such as a common public radio interface (CPRI)). Therefore, in some embodiments, the term T-TRP 170 may also refer to network-side modules that perform processing operations such as determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding, which are not necessarily part of the device housing the antenna 256 of T-TRP 170. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 170 may actually be multiple T-TRPs that operate together to serve ED 110, such as through the use of cooperative multicast.

[0177] T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid clutter. One, some, or all of the antennas 256 may also be panels. The transmitter 252 and receiver 254 may be integrated as a transceiver. T-TRP 170 also includes a processor 260 for performing operations related to: preparing transmissions for downlink transmission to ED 110; processing uplink transmissions received from ED 110; preparing transmissions for backhaul transmission to NT-TRP 172; and processing transmissions received from NT-TRP 172 via backhaul. Processing operations related to preparing transmissions for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to receiving uplink or backlink transmissions may include receiving beamforming, demodulating received symbols, and decoding received symbols. Processor 260 may also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 260 also generates beam direction indications, such as BAI, which may be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the deployment location of NT-TRP 172, etc. In some embodiments, processor 260 may generate signaling to configure one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172, etc. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" as used herein may also refer to control signaling. Signaling can be transmitted in physical layer control channels such as the physical downlink control channel (PDCCH). In this case, the signaling can be called dynamic signaling. Signaling transmitted in the downlink physical layer control channel is called downlink control information (DCI). Signaling transmitted in the uplink physical layer control channel is called uplink control information (UCI). Signaling transmitted in the sidelink physical layer control channel is called sidelink control information (SCI).Signaling can be included in higher-layer (e.g., above the physical layer) packets that are transmitted on physical layer data channels such as the Physical Downlink Shared Channel (PDSCH). In this case, the signaling can be called higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling can also refer to Radio Resource Control (RRC) protocol signaling or Media Access Control – Control Element (MAC-CE) signaling.

[0178] Scheduler 253 may be coupled to processor 260. Scheduler 253 may be included within T-TRP 170 or may operate separately from T-TRP 170. Scheduler 253 may schedule uplink, downlink, lateral link, and / or backlink transmissions, including issuing scheduling authorizations and / or configuring schedule-free (e.g., “configuration authorizations”) resources. T-TRP 170 also includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or collected by T-TRP 170. For example, memory 258 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by processor 260.

[0179] Processor 260 may be part of transmitter 252 and / or receiver 254, but is not shown in the figures. Additionally, processor 260 may implement scheduler 253, but is not shown in the figures. Memory 258 may be part of processor 260, but is not shown in the figures.

[0180] The processing components in processor 260, scheduler 253, transmitter 252, and receiver 254 can be implemented by the same or different processors, which execute instructions stored in memory (such as memory 258). Alternatively, some or all of the processing components in processor 260, scheduler 253, transmitter 252, and receiver 254 can be implemented using dedicated circuitry such as a programmable FPGA, hardware accelerator (such as a GPU or AI accelerator), or ASIC.

[0181] Although the NT-TRP 172 is only illustrated as a drone, it can be implemented in any suitable non-terrestrial form. It should be noted that the NT-TRP 172 can be omitted in some scenarios. Furthermore, in some implementations, the NT-TRP 172 may have other names, such as satellite and high-altitude platform, including international mobile communication base stations and unmanned aerial vehicles. Additionally, in some implementations, the NT-TRP 172 may have other names, such as non-terrestrial node, non-terrestrial network device, or non-terrestrial base station. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure to avoid clutter. One, some, or all of the antennas can also be panels. The transmitter 272 and receiver 274 can be integrated into a transceiver. NT-TRP 172 also includes a processor 276 for performing operations related to: preparing to transmit downlink transmissions to ED 110; processing uplink transmissions received from ED 110; preparing to transmit backhaul transmissions to T-TRP 170; and processing transmissions received from T-TRP 170 via backhaul. Processing operations related to preparing to transmit downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling to configure one or more parameters of ED 110, etc. In some embodiments, the NT-TRP 172 implements physical layer processing but not higher-layer functions, such as those in the medium access control (MAC) or radio link control (RLC) layers. Since this is merely an example, the NT-TRP 172 typically implements higher-layer functions in addition to physical layer processing.

[0182] The NT-TRP 172 also includes a memory 278 for storing information and data. A processor 276 may be part of the transmitter 272 and / or the receiver 274, but is not shown in the figure. The memory 278 may be part of the processor 276, but is not shown in the figure.

[0183] The processing components in processor 276, transmitter 272, and receiver 274 can be implemented by the same or different processors, which execute instructions stored in memory (such as memory 278). Alternatively, some or all of the processing components in processor 276, transmitter 272, and receiver 274 can be implemented using dedicated circuitry such as a programmable FPGA, hardware accelerator (such as a GPU or AI accelerator), or ASIC. In some embodiments, NT-TRP 172 can actually be multiple NT-TRPs operating together to serve ED110, such as through cooperative multicast.

[0184] T-TRP 170, NT-TRP 172 and / or ED 110 may include other components, but for clarity these components are omitted.

[0185] Basic module structure

[0186] Figure 4 A block diagram of a device in a communication system according to one or more embodiments of the present disclosure is shown, such as Figure 4 As shown, one or more steps of the exemplary methods provided herein can be performed by the corresponding unit or module. Figure 4 The diagram illustrates units or modules within a device (such as ED 110, T-TRP 170, or NT-TRP 172). For example, signals may be transmitted by a transmitting unit or transmitting module. Signals may be received by a receiving unit or receiving module. Signals may be processed by a processing unit or processing module. Other steps may be performed by an artificial intelligence (AI) module or a machine learning (ML) module, which may be selected or omitted depending on actual needs. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more of these units or modules may be circuits, such as integrated circuits. Examples of integrated circuits include programmable FPGAs, GPUs, or ASICs. For example, one or more of these units or modules may be logic, such as logical functions executed by circuits, a portion of an integrated circuit, or software instructions executed by a processor. It should be understood that if these modules are implemented using software executed by a processor, etc., then these modules may be retrieved by the processor, in whole or in part, individually or collectively, for processing, in one or more instances, and these modules themselves may include instructions for further deployment and instantiation. It should be noted that, Figure 4The modules shown are merely illustrative and should not be construed as limiting the embodiments of this disclosure. The device may include more or fewer modules, and this is not a limitation. For example, the transmitting and receiving modules can be replaced by a single transceiver module. Furthermore, depending on actual needs, the ML module may or may not be included in the device.

[0187] Further details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0188] The schemes described in this disclosure can be applied to next-generation networks (such as sixth-generation (6G) or higher) or traditional networks (such as 5G, 4G, 3G or 2G).

[0189] The proposed 6G system architecture aims to support 6G anything-as-a-service (XaaS) services by employing technologies such as network function virtualization and network slicing. The 6G system architecture utilizes a service-based interaction mechanism between 6G services.

[0190] This 6G system adopts a service-based architecture and the XaaS concept. The XaaS services in the 6G system are divided into three layers. Figure 5 A block diagram illustrating the conceptual structure of a 6G system according to one or more embodiments of the present disclosure is shown.

[0191] The infrastructure layer includes the infrastructure that supports 6G services. This includes wireless network (RAN, CN) infrastructure, cloud / data center infrastructure, satellite networks, storage / database infrastructure, and sensor networks. This infrastructure can be provided by a single provider or multiple providers.

[0192] Various types of infrastructure can have their own control and management functions, represented as control and management (C / M) functions, used for infrastructure management. Each of these types of infrastructure is a type of Infrastructure as a Service.

[0193] The Control and Management (C / M) layer includes control and management services for the 6G system. These services are developed and deployed using slicing technology and leveraging resources provided by the infrastructure layer. The 6G services in the Control and Management (C / M) layer include:

[0194] Resource Management (RM) as a Service: Provides lifecycle management for various slices and the ability to allocate over-the-air resources to wireless devices.

[0195] - Mission Management (MM) as a Service: Provides the ability to programmatically configure XaaS services in the service layer to provide mission services.

[0196] - Confederation Network (CONET) as a Service: Provides the ability for multiple partners to jointly deliver 6G services. This capability is provided through alliance formation, mutual authentication and authorization among partners, and protocol negotiation to record and trace selected operations performed by partners, ensuring the trustworthiness of the 6G system operating environment.

[0197] Service Provisioning Management (SPM) as a Service provides the ability to control and manage a customer's access to 6G services and provision services upon request. This capability can be provided through unified mutual authentication, authorization and policies, key management, QoS guarantees, and billing between any pair of XaaS service providers and customers. These customers include not only end customers in the physical world but also digital representatives in the digital world.

[0198] - Connectivity Management (CM) as a service: Utilizes 5G connectivity management capabilities, but extends to include the digital world.

[0199] - Protocol as a Service: Provides the ability to design customized protocol stacks for specific interfaces. These protocol stacks can be predefined for selection on demand, or designed on demand.

[0200] - Cybersecurity as a Service: Provides infrastructure owners with the ability to detect potential security risks to their infrastructure.

[0201] 6G tasks are defined as services provided by 6G systems to customers. A task can be a type of service provided by a single 6G XaaS service, or it can be a type of service that requires the participation of multiple XaaS services.

[0202] XaaS services in the C / M layer support both the control and management of the 6G system itself and provide support to vertical industries upon request. For example, RM services can provide air resource management for the RAN and also provide services to vertical industries to enable them to allocate air resources to their end customers. XaaS in the C / M layer can be deployed using slicing technology.

[0203] The service layer includes 6G services provided to customers. In the conceptual architecture of a 6G system:

[0204] AI services can be represented as NET4AI as a Service. Artificial intelligence services provide AI capabilities to support a wide range of AI applications.

[0205] Data collection, data cleansing, data analysis, and data delivery services are referred to as DAM as a service. This service provides the ability to manage the lifecycle of statistical data, including data acquisition, de-identification, analysis, and delivery of information statistics from any type of sensor, device, and network function.

[0206] Data storage and sharing services can be represented as NET4Data as a Service, which provides the ability to reliably store and share data under the control of the data owner and in accordance with the regulations of an authority regarding specific data controls.

[0207] Providing services for the digital world can be represented as NET4DW as a Service. Digital world services provide the ability to build, control, and manage the digital world. The digital world is defined as the digital realization of the physical world.

[0208] - 6G blockchain services can be represented as NET4BC as a service. 6G connectivity services are represented as NET4Con as a service. These services provide the capability to support 6G blockchain services.

[0209] - Enhanced connectivity services (such as network for connectivity (NET4CON)) are services. These services provide the ability to exchange messages and data between supporting new 6G services.

[0210] All XaaS services in this layer utilize resources provided within the infrastructure and are developed and deployed using network function virtualization and slicing technologies. The capabilities of each 6G service are provided by its control and management functions, as well as service-specific data processing capabilities.

[0211] In addition to supporting 6G XaaS services in the service layer, the 6G system also leverages the 5G system to provide vertical services. The difference between 6G XaaS services and other vertical industries is that vertical industries are purely customers who need other XaaS services to support their operation, while each XaaS service provides its own capabilities to 6G customers.

[0212] Any pair of XaaS services in a 6G system can also be customer and provider to each other. For example, the infrastructure owner provides its resources to XaaS services in the service layer and the C / M layer; the RM service may need the capabilities provided by NET4AI, DAM, and NET4DW when managing resources for vertical slices; and the operation of the CONET service and the NET4Data service may need the capabilities provided by NET4BC.

[0213] The core concepts of 6G systems include:

[0214] - Define the basic XaaS service by decoupling various integrated services from the basic XaaS service. The basic XaaS service provides unique capabilities to support specific types of services, such as NET4AI service, NET4DW service, DAM service, NET4Data service, blockchain service, task management service, etc.

[0215] - Allows multiple partners to jointly operate the 6G system.

[0216] - Define the data plane of the 6G system, including the data plane processing functions of XaaS services. Programming the interconnection of these functions through task management services enables support for various customized customer services.

[0217] - By classifying basic control and management services and combining these services into basic XaaS services in the Control and Management (C / M) layer, the 6G system architecture is simplified.

[0218] - Define the C / M plane of the 6G system, which includes C / M functions in XaaS services and may include 5G CPs (such as AMF) depending on the implementation scheme.

[0219] - Define a Basic Architecture Structure (BAS), which is a unified infrastructure with a minimal number of interfaces and is independent of infrastructure type.

[0220] - Use the BAS concept to simplify the standardization, development and deployment of 6G systems, while supporting various infrastructure deployment scenarios.

[0221] -By leveraging the capabilities, capacity, and demands of the infrastructure network, BAS or subsets can be applied to the infrastructure to adapt to various deployment scenarios.

[0222] -Utilize the concept of service-based interface (SBI) and apply SBI interaction on both the 6G C / M plane and the 6G data plane.

[0223] -Simplify the SBI interface by introducing a trusted GW in the data plane and C / M plane of the 6G system.

[0224] - By introducing CONET capabilities, NET4BC capabilities, and anonymous service activation capabilities provided by the Trusted Gateway on the C / M plane and data plane of the 6G system, the trustworthiness of the 6G system is improved from the perspective of its operation.

[0225] - Enhance trustworthiness from the perspective of end-customer privacy protection by providing unified mutual authentication, IDM and data purification through SPM service, DAM service and 6G blockchain service.

[0226] - Simplify roaming management of wireless devices in the physical and digital worlds through unified authentication that includes all participating partners and customers.

[0227] - By introducing the BAS concept, multiple architectural solutions can be defined without investing a lot of effort, supporting multiple development paths from 5G systems to 6G systems.

[0228] - By leveraging the advantages of SBA and its additional features, backward compatibility is supported. 5G users can access 5G services through 6G systems.

[0229] - Thanks to the anonymous service provisioning concept implemented in the trusted GW introduced in the 6G C / M plane and 6G data plane, future expansion can be supported by adding new XaaS services, while minimizing the impact on standardization and deployment.

[0230] Many emerging trends will drive the considerations and design of 6G / future wireless networks:

[0231] - New network infrastructure capabilities, such as widely deployed cloud-native / friendly infrastructure.

[0232] Emerging (relatively) mature technologies, such as large-scale AI models, data privacy protection, and blockchain, have made significant progress and have had a major impact on society and human life.

[0233] - New applications and services, such as AI services, data (sensing) services, digital world services, etc., are widely used in the industrial / commercial sector and by individual customers.

[0234] - The trends of globalization, openness, and collaboration are becoming increasingly prominent, meaning that more open and collaborative operating models are becoming common practices in many fields.

[0235] New expectations and more stringent requirements for future networks are driving a rethinking and development of next-generation wireless networks. These requirements include:

[0236] Privacy and trustworthiness, etc.

[0237] -Simplify and standardize.

[0238] - Rapid deployment.

[0239] -etc.

[0240] All of the above factors have driven the research on 6G network architecture.

[0241] The proposed (X-centric) 6G network architecture is based on SBA (XaaS service) and has cloud-native characteristics.

[0242] Requirements for 6G system network architecture design:

[0243] - The proposed 6G network architecture needs to support new 6G services that can be developed / deployed by third parties.

[0244] - The proposed 6G network architecture needs to build a more open ecosystem that is open to third parties with technical capabilities.

[0245] The proposed 6G network architecture requires more reliable trust management.

[0246] In related technologies, PDU connectivity services are provided by 5G networks. PDU connectivity service is a service that facilitates PDU exchange between user equipment (UE) and data network (DN). The 5G network provides PDU connectivity services to the UE through one or more PDU sessions. Figure 6 This is a schematic diagram of a 5G PDU session according to one or more embodiments of this disclosure. Figure 6 As shown, a PDU session is the association between a UE and the data network (DN) that provides PDU connection services. Intermediate network nodes (such as RAN nodes (gNB) and user plane functions (UPFs)) exist within the PDU session between the UE and the DN. One or more QoS flows can be transmitted through the PDU session. A QoS flow is the smallest granularity for implementing QoS differentiation within a PDU session. User plane traffic within the QoS flows of a PDU session undergoes the same traffic forwarding processing (such as scheduling, admission thresholds, latency, and packet loss rate).

[0247] On the network side, user plane tunnels (such as GTP-U tunnels) are established to transmit PDU session data. For example, there is an NG-U tunnel (such as the N3 tunnel) between the RAN and UPF, a tunnel between two UPFs (such as the N9 tunnel), a tunnel between the UPF and DN (such as the N6 tunnel), and so on. PDU session data is transmitted through the network-side tunnels.

[0248] To establish PDU sessions for data forwarding, 5G control plane functions (such as AMF, SMF, and RAN CP) configure user plane functions (such as UPF and RAN UP) to establish resources for PDU sessions, for example, by establishing tunnels on the network side (such as GTP-U tunnels described in the 3rd Generation Partnership Project (3GPP) technical specification (TS 29.281)). For example, GTP-U tunnels (such as N3 and N9 tunnels) are established per PDU session, and these GTP-U tunnels are dedicated to PDU sessions. For instance, in 5G, the GTP-U tunnel between the RAN and UPF is specifically established for PDU sessions. For downlink packets on the user plane, when the RAN receives a packet from a configured tunnel of a PDU session, the RAN can distinguish that the packet belongs to that PDU session. Similarly, for uplink packets on the user plane, when the UPF receives a packet from a configured tunnel of a PDU session, the UPF can distinguish that the packet belongs to that PDU session.

[0249] A QoS flow is the smallest unit of granularity for QoS differentiation within a PDU session. A QoS flow ID (QFI) is used to identify QoS flows in a 5G system. Within a PDU session, user plane traffic with the same QFI undergoes the same traffic forwarding processing (such as scheduling and admission thresholds). The QFI is carried in the encapsulation header of packets transmitted over an N3 tunnel (or an N9 tunnel), meaning no changes are required to the end-to-end packet header. The QFI applies to all PDU session types. A QFI should be unique within a PDU session. A QFI can be dynamically assigned or equal to a 5G QoS identifier (5QI). QoS flows are associated with QoS requirements, which are specified through QoS parameters and QoS characteristics.

[0250] In order for user plane network entities (such as UPF, RAN) to detect and distinguish the QoS flow to which packets received from the tunnel of a PDU session belong, additional information (such as a PDU session container) needs to be encapsulated in the GTP-U packet, as described in 3GPP TS29.281 and TS 38.415.

[0251] GTP-U tunnels are used to carry encapsulated transport PDUs (T-PDUs) and signaling messages between a given pair of GTP-U tunnel endpoints. The tunnel endpoint ID (TEID) present in the GTP header should indicate the tunnel to which a particular T-PDU belongs. In this way, packets are multiplexed and demultiplexed between a given pair of tunnel endpoints via GTP-U. The TEID value to be used in the TEID field should be indicated to the peer GTP-U entity via the control plane protocol.

[0252] Figure 7 This is a schematic diagram illustrating the structure of a GTP-U packet header according to one or more embodiments of this disclosure. (See reference) Figure 7 :

[0253] Tunnel endpoint identifier (TEID): This field explicitly identifies the tunnel endpoint within the receiving GTP-U protocol entity. The receiving end of a GTP tunnel assigns a TEID value locally, which the sending end needs to use. TEID values ​​can be assigned in an unpredictable manner.

[0254] Extended Header Flags (E): This field indicates whether a valid value exists for the next extended header field. When this field is set to "0", it means that the next extended header field does not exist, or even if it does exist, it should not be parsed. When this field is set to "1", it means that the next extended header field exists and should be parsed.

[0255] Next extension header type: This field defines the type of extension header following this field in the GTP-PDU.

[0256] Figure 7 For the meanings and uses of other fields in the GTP-U header, please refer to 3GPP TS 29.281 and TS 38.415, which are omitted here.

[0257] Figure 8 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure. The definition of the extension header type is as follows: Figure 8 As shown. There is an extension header type for PDU session containers, indicated, for example, by setting the value of the next extension header field to 1000 0101.

[0258] Figure 9 This is a schematic diagram illustrating the format of a GTP-U extension header according to one or more embodiments of this disclosure. The format of the GTP-U extension header is as follows: Figure 9 As shown.

[0259] The `ExtensionHeaderLength` field specifies the length of a particular extension header. The `NextExtensionHeaderType` field specifies the type of any extension header that can follow the given extension header. If no such header follows, the value of `NextExtensionHeaderType` should be 0.

[0260] When the type of the extension header is set to PDU session container (e.g., the value of the next extension header field is set to 10000101), the PDU session container is encapsulated in the GTP-U packet header. This PDU session container extension header can be transmitted via the user plane interface, between the RAN and UPF, or between two UPFs, through N3 tunnels and / or N9 tunnels.

[0261] The length of the PDU session container is variable, and the contents of the PDU session container are specified in 3GPP TS 38.415, etc.

[0262] In some cases, PDU session user plane protocol data is carried through the GTP-U protocol mechanism, more specifically, through the "PDU session container" in the GTP-U extension header.

[0263] Figure 10 This is a schematic diagram illustrating the format of downlink (DL) PDU session information according to one or more embodiments of this disclosure. The DL PDU session information can be carried via the GTP-U protocol mechanism, and more specifically, via... Figure 8 and Figure 9 This is implemented using the "PDU session container" in the GTP-U extension header shown. The DL PDU session information is an example of an implementation of the PDU session container content.

[0264] In some cases, the format of the downlink (DL) PDU session information in the PDU session user plane protocol is as follows: Figure 10 As shown, this DL PDU session information is carried through a PDU session container (e.g., in the GTP-U extension header). This information can be transmitted between RAN nodes and UPFs, between UPFs, between RAN nodes, or between other network entities. DL PDU session information can also be referred to as a DL PDU session information frame.

[0265] The DL PDU session information frame includes a QoS flow identifier (QFI) field associated with the transmitted packet. Network entities (such as RAN nodes) can use the received QFI to determine the QoS flow and QoS profile associated with the received packet. For example, when a network entity (such as a RAN node or UPF) receives a packet from the GTP-U tunnel of a PDU session, it can detect and distinguish the QoS flow to which the packet belongs based on the QFI included in the PDU session container (carrying PDU session information).

[0266] DL PDU session information frames may include a reflective QoS indicator (RQI) field to indicate whether user plane reflective QoS can be activated.

[0267] Figure 10 The meanings and uses of other fields in the DL PDU session information frame can be found in 3GPP TS 29.281 and TS 38.415, which are omitted here.

[0268] Figure 11 This is a schematic diagram illustrating the format of uplink (UL) PDU session information according to one or more embodiments of this disclosure. The UL PDU session information can be carried via the GTP-U protocol mechanism, more specifically, through... Figure 8 and Figure 9 This is implemented using the "PDU session container" in the GTP-U extension header shown. The UL PDU session information is an example of an implementation of the PDU session container content.

[0269] In some cases, the format of the PDU session information in the PDU session user plane protocol uplink (UL) is as follows: Figure 11 As shown, this UL PDU session information is carried through a PDU session container (e.g., in the GTP-U extension header). This information can be transmitted between RAN nodes and UPFs, between UPFs, between RAN nodes, or between other network entities. UL PDU session information can also be referred to as a UL PDU session information frame.

[0270] The UL PDU session information frame includes a QoS flow identifier (QFI) field associated with the transmitted packet. Network entities (such as RAN nodes) can encapsulate the QFI to enable peer nodes to determine the QoS flow and QoS profile associated with the packet. For example, when a network entity (such as a RAN node or UPF) sends a packet through a GTP-U tunnel of a PDU session, the network entity can enable peer nodes to detect and distinguish the QoS flow to which the packet belongs based on the QFI encapsulated in the PDU session container (carrying PDU session information).

[0271] If QoS monitoring of the included QFI fields has been requested, the UL PDU session information frame may include a QoS monitoring packet (QMP) field, a DL transmit timestamp repeat field, a DL receive timestamp field, a UL transmit timestamp field, and / or the UL or DL ​​delay result.

[0272] Figure 11 The meanings and uses of other fields in the DL PDU session information frame can be found in 3GPP TS 29.281 and TS 38.415, which are omitted here.

[0273] User plane functions (such as UPF and RAN UP) perform appropriate operations to deliver uplink and / or downlink data. For example, the UPF classifies PDU layer packets for QoS flow marking (e.g., based on packet detection rules) and maps QoS flows to GTP-U tunnels. Furthermore, other user plane functions (such as UPF and RAN) determine the QoS flow to which a received packet belongs based on the QoS flow identifier (ID) marked in the packet header, and determine the PDU session to which the received packet belongs based on the tunnel used to deliver the packet. The RAN maps the QoS flows of PDU sessions received in a specific GTP-U tunnel to data radio bearers.

[0274] However, for next-generation networks (such as sixth-generation (6G) or higher), or traditional networks in the 6G era (such as 5G, 4G, 3G, or 2G), it is expected that 6G networks will not only support connectivity but also data processing. Therefore, in the 6G era, intra-network data processing (computation) will be supported.

[0275] To achieve the above objectives, task services are designed for 6G networks. A task is used to achieve a specified objective, referred to as a task objective, which includes (1) providing PDU connectivity and optionally (2) providing data processing. A task service is a service that achieves a task objective (i.e., PDU connectivity and / or data processing). When a task objective includes providing data processing, the task objective is associated with one or more specific computational problems, and providing data processing refers to solving these one or more specific computational problems. In this case, the task includes one or more computing blocks (CBs) and is associated with networking processes between CBs to solve these one or more specific computational problems. A CB within a task corresponds to a defined computational step that achieves the task objective (i.e., solving one or more specific computational problems) and can be executed by functions of XaaS services (in the form of tasks), data networks (DNs), or other task services; therefore, a CB is called a work CB, an external CB, or a subtask CB. A CB corresponds to a specific operation in data processing, such as AI training, AI inference, data preprocessing, data de-identification, data cleaning, data collection, data analysis, sensing, etc. Different CBs of a task can be executed sequentially or in parallel.

[0276] When the mission objective only includes providing PDU connectivity, the mission service can be simplified to 5G PDU connectivity service. When the mission objective includes providing data processing, the data is forwarded to one or more CB entities for processing, and then the processed data is forwarded to the next hop, such as one or more other CB entities, until the mission objective is achieved.

[0277] Figure 12 This is a schematic diagram illustrating a task service provided by a 6G network according to one or more embodiments of this disclosure. Figure 12 As shown, each CB entity executes one or more CBs. These CB entities can be deployed in devices (such as UEs, vehicles, radars, sensors, drones, and actuators), RAN, CN, and even DN. In some cases, CB entities are deployed on top of XaaS service functions. XaaS service functions can reside in devices, RAN, CN, and DN. In some cases, the mission services including CB entities are configurable and under the control of C / M plane functions (such as mission management (MM) functions). Figure 12As shown, devices deploying CB entities, along with other CB entities provided by XaaS service functions, participate in the task service to perform data processing in parallel and / or sequentially. The XaaS service functions can reside in one or more of the following: RAN, CN, and DN. For example, CB entities 1, 2, 3, and 4 are provided by the functions of XaaS services 1, 2, 3, and 4, respectively. Two devices may also provide other CB entities (not shown in the figure), or none at all. In some cases, CB entities 1, 2, 3, and 4 may be provided by one or more functions of the same XaaS service, rather than by four different functions of the XaaS service. In some cases, zero or more of the four CB entities reside in the DN, while the other CB entities reside in one or more of the following: RAN and CN. CB entities and devices are connected via a data trustworthy gateway (Data-TW-GW). In some cases, CB entities and the Data-TW-GW are deployed on the 6G data plane, which may also be referred to as the user plane or enhanced user plane, etc. In some cases, the Data-TW-GW may be a UPF or an enhanced UPF. CB entities (e.g., deployed in devices, RANs, CNs, DNs, and third parties) are connected via Data-TW-GW. Data-TW-GW helps eliminate mesh topologies between CBs and supports anonymous communication between CBs. Data-TW-GW can also be referred to as a GW entity.

[0278] For the data processing (computation) workflow within the task service:

[0279] Two devices can transfer data (data that has not been processed by the CB entity in the device or data that has been processed by it) to CB entity 1 provided by the functionality of XaaS service 1 (such as Data Analytics and Management (DAM) service).

[0280] CB entity 1 directly transmits data or processed data to CB entity 2 provided by XaaS service 2 (such as NET4AI service) through Data-TW-GW 1;

[0281] In parallel, CB entity 2 receives data from CB entity 4 provided by the functionality of XaaS service 4 (such as NET4DW service) through Data-TW-GW 1 and Data-TW-GW 2;

[0282] Furthermore, the data received by CB entity 2 from CB entity 4 is the result of processing the data received by CB entity 4 from CB entity 3 via Data-TW-GW 2, which is provided by the functionality of XaaS service 3 (such as NET4Data).

[0283] Then, CB entity 2 uses all the data received from CB entities 1, 3 and 4 to perform data processing for AI training (or AI inference, etc.) and sends the processing results to CB entity 4;

[0284] CB entity 4 uses the data sent by CB entity 2 and the data from CB entity 3 to perform data processing and sends the processing results back to CB entity 2; then, data processing and forwarding are performed back and forth between CB entities 2, 3 and 4 until the task objective is achieved.

[0285] In some cases, a task corresponds to a service function chain defined by the Internet Engineering Task Force (IETF) in Request for Comment (RFC) 7665, etc. A service function chain is defined as a logical representation of an ordered set (sequence) of service functions that need to process certain traffic sequentially. For example, traffic might first be processed by service function 1 (such as deep packet inspection), then by service function 2 (such as TCP / IP optimization), and finally by service function 3 (such as a firewall).

[0286] Figure 13 This is a schematic diagram of a task session for task services according to one or more embodiments of this disclosure. Figure 13 As shown, task service subscribers (such as 6G devices, AS) access task services through one or more task sessions.

[0287] A task session is used to provide task services to task clients, which are services that simultaneously support packet data unit (PDU) connectivity and data processing. In some cases, a task service subscriber may also be referred to as a task client requesting access to the task service.

[0288] Specifically, Task Session This refers to the association between network entities (such as UEs, network functions (NFs), and ASs) and the data network (DN) used to provide mission services. Furthermore, this DN can be a virtual DN or a pseudo-DN. A mission session includes data forwarding and data processing resources used to perform the mission. Data Session Sets (groups) and optional GW Inter-session .

[0289] Task ServiceIt is a service that achieves the mission objective (i.e., PDU connectivity and / or data processing). When the mission objective includes providing data processing, the mission objective is associated with one or more specific computational problems, and providing data processing means solving these one or more specific computational problems. In this case, the mission includes one or more... Computing block, CB) These processes are linked to the networking flow between task CBs to solve one or more specific computational problems. A task CB within a task corresponds to a defined computational step that achieves the task objective (i.e., solves one or more specific computational problems). In some cases, CBs are performed by functions of XaaS services (in the form of jobs), data networks (DNs), or other task services; therefore, CBs are called job CBs, external CBs, or subtask CBs. CBs correspond to specific operations in data processing, such as AI training, AI inference, data preprocessing, data de-identification, data cleaning, data collection, data analysis, sensing, etc. Different CBs within a task can be executed sequentially or in parallel.

[0290] A task session includes one or more data sessions, each data session including an association terminating at a computing block (CB) entity that executes at least one CB of a task. The task comprises one or more CBs, each CB corresponding to a computational step that implements the task service. Data processing includes executing at least one CB of the task. The computational steps that implement the task service can also be referred to as computational steps that achieve the task objectives mentioned above.

[0291] A task session includes one or more data sessions. These data sessions are used to transmit data from one or more CBs. Establishing either or both of the PDU connection resources and data processing resources for a task session includes establishing at least one of the one or more data sessions. Each data session includes an association terminating at a CB entity. A CB entity participates in one or more data sessions, and a CB entity participates in one or more task sessions. PDU connection resources can also be referred to as the data forwarding resources mentioned above.

[0292] In addition, the CB entity is used to execute at least one CB for a task, which includes one or more CBs, each CB corresponding to a computational step that implements the task service; data processing includes executing at least one CB for the task.

[0293] The computational steps for implementing the task service include one or more of the following: artificial intelligence (AI) training, AI inference, data preprocessing, data privacy protection, data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, data aggregation, data segmentation, useless data filtering, data formatting, data adaptation, data feature engineering, data compression, data embedding, data representation learning, or data feature extraction.

[0294] Specifically, Data Session It is an association that terminates at least at a computing block (CB) entity, which is used to perform one or more CBs for tasks. CB entity Used to perform operations corresponding to one or more CBs. Specific data transmissions and / or data processing are performed among CB entities in a specific order (e.g., sequential and / or parallel) to complete the task. A CB entity is a network entity that can be deployed in devices (such as UEs, vehicles, radars, sensors, drones, and actuators), RAN, CN, and DN. In some cases, CB entities are deployed on functions of XaaS services. XaaS service functions can reside in devices, RAN, CN, and DN. In some cases, CB entities are deployed on the 6G data plane. In some cases, CB entities are supported by XaaS services, for example, by the processing service function (PSF) of an XaaS service. Different CB entities can perform the same or different CBs. In some cases, a data session corresponds to one CB for a task. In some cases, a data session corresponds to multiple CBs for a task. In some cases, a CB entity may also be referred to as a CB DP entity.

[0295] In some cases, a data session can be viewed as consisting only of data forwarding resources of one or more CBs that support the execution of tasks, i.e., the pipeline connecting CB entities with other network entities, while data processing resources configured in CB entities do not belong to the data session.

[0296] In some cases, a data session can be considered as including both data forwarding and data processing resources of one or more CBs used to perform tasks; that is, data processing resources configured in a CB entity also belong to a data session.

[0297] A data session includes one of the following: an association between a CB entity and a GW entity, or an association between a CB entity and other CB entities.

[0298] Specifically, a data session is the association between a CB entity and a Data-TW-GW; or, a data session is the association between a CB entity and other CB entities.

[0299] In addition, when a data session includes an association between a CB entity and a GW entity, the CB entity and the GW entity participate in one or more data sessions, and the CB entity and the GW entity participate in one or more task sessions.

[0300] In some cases, to achieve this, a data session is an association between a device with a CB entity deployed (such as a UE, vehicle, radar, sensor, drone, and actuator) and the Data-TW-GW. The Data-TW-GW can be deployed in the RAN or CN.

[0301] In some cases, to achieve this, the data session is an association between the Data-TW-GW and the processing service function (PSF) of the XaaS service, with the CB entity deployed on the PSF. The Data-TW-GW can be deployed in the RAN or CN. The PSF can be deployed in the RAN or CN.

[0302] In some cases, to achieve this, a data session is an association between a device and a PSF (Power Service Provider) of an XaaS service. The PSF can be deployed in the RAN (RAN) or CN (CN).

[0303] In some cases, to achieve this, a data session is an association between a PSF and other PSFs, which can be functionalities of the same or different XaaS services. Either or both of these PSFs can be deployed in the RAN or CN.

[0304] In some cases, to achieve this, a data session is an association between a DN and a PSF (Power Service Provider) of an XaaS service. The PSF can be deployed in the RAN (RAN) or CN (CN).

[0305] In some cases, to achieve this, a data session is an association between the DN and the Data-TW-GW. The Data-TW-GW can be deployed in the RAN or CN.

[0306] In some cases, a data session is an association between two devices to achieve this.

[0307] In some cases, to achieve this, a data session is an association between two DNs.

[0308] In some cases, to achieve this, a data session is an association between a device and a DN.

[0309] The task session also includes one or more gateway (GW) sessions. Each GW session includes the association between two GW entities, and each GW entity is used to support communication between CB entities.

[0310] A task session includes one or more data sessions and / or one or more inter-GW sessions, which are used to transmit data from one or more CBs. At least one of the one or more data sessions and one or more inter-GW sessions terminates at a GW entity, which is used to support communication between CB entities. Establishing any one or both of PDU connection resources and data processing resources for a task session includes establishing at least one of the following: one or more data sessions and one or more inter-GW sessions; each data session includes an association terminating at a CB entity; each inter-GW session includes an association between two GW entities; and a GW entity participates in at least one of the following: one or more data sessions and one or more inter-GW sessions; and a GW entity participates in one or more task sessions.

[0311] Specifically, GW Inter-session This refers to the association between two Data-TW-GWs used for data forwarding. In some cases, the Data-TW-GW may be a UPF or an enhanced UPF. CB entities (e.g., deployed in devices, RANs, CNs, and DNs) are connected via the Data-TW-GW. The Data-TW-GW helps eliminate mesh topologies between CBs and supports anonymous communication between CBs.

[0312] A CB entity (deployed in a device, RAN, CN, or DN) can participate in one or more mission sessions. A CB entity can participate in one or more data sessions.

[0313] Task sessions can be identified by task session ID or session group ID. Data sessions can be identified by data session ID.

[0314] like Figure 13As shown, a task session includes one or more data sessions. Two CB entities are deployed in the RAN, and two CB entities are also deployed in the core network function (NF) or DN. Devices can also deploy CB entities or be active as CB entities, as not shown in the figure. CB entities can be supported by XaaS service functions. Radio bearers are established between the device and the 6G RAN node via the air interface. Data sessions are established between the device deploying the CB entity and the Data-TW-GW. Each device establishes one or more data sessions belonging to the task session. One or more devices participate in the task session. Flexible mapping between radio bearers and data sessions is possible. On the network side, data sessions are established between the CB entity and the Data-TW-GW. One or more data sessions can exist between the CB entity and the Data-TW-GW, and the CB entity (e.g., deployed in the PSF of XaaS) may participate in one or more data sessions. CB entities (e.g., deployed in the PSF of XaaS) can participate in one or more task sessions. One or more inter-GW sessions are established between the Data-TW-GWs. Figure 13 As shown, two devices participate in a task session, with each device establishing two data sessions. A data session can be mapped to one radio bearer, or multiple data sessions can be mapped to one radio bearer. This does not preclude the possibility of one data session being mapped to multiple radio bearers. Within the RAN, one CB entity establishes two data sessions (as shown in the small rectangles), while the other CB entity establishes one data session. Within the NF or DN, one CB entity establishes two data sessions, and another CB entity within the NF or DN establishes one data session. Two inter-GW sessions are established between the two Data-TW-GWs.

[0315] When the goal of a task is simply to provide PDU connectivity, the task does not include any compute-related functions (i.e., it does not include any computation-related functions). In this case, the task session is simplified to a PDU session. Different PDU sessions can be defined. Task Session Type : PDU-only connection type and data connection and processing type (i.e., not PDU-only connection type). The PDU-only connection type indicates that no CB entity participates in the task session; in this case, the task session is simplified to a PDU session. In this case, the task service is simplified to a service supporting only PDU connections. The data connection and processing type (i.e., not PDU-only connection type) indicates that at least one CB entity participates in the task session, and data forwarding and processing are both supported through the task session, for example, to support 6G services (such as AI, sensing, and data services) that support data processing.

[0316] In some cases, the CB entity of a task session is a virtual entity or a pseudo entity, for example, for task sessions with only PDU connection types.

[0317] Furthermore, for PDU-only connection types, there are no data sessions belonging to the task session; all data sessions belonging to the task session are pseudo-data sessions.

[0318] In this disclosure, the terms "forwarding," "transmitting," and "delivering" are used interchangeably. Data connection and data forwarding are used interchangeably.

[0319] Similarly, an inter-GW session corresponds to one or more QoS flows. Data traffic for one or more QoS flows is transmitted through the inter-GW session. A QoS flow is the smallest granularity for implementing QoS differentiation in the task service. Data traffic within a QoS flow undergoes the same data processing and the same data forwarding processing. Additionally, an inter-GW session can also be implemented as a QoS flow or a PDU session.

[0320] For example, one or more QoS flow Transmitted within a data session. A QoS flow is the smallest granularity for implementing QoS differentiation within a task service. Traffic within the same QoS flow undergoes the same data processing and forwarding. In some cases, a data session is implemented as a QoS flow.

[0321] New radio bearers dedicated to mission services can be established over the air interface on both the C / M plane and the data plane to provide services with specific QoS. For example, a new data radio bearer dedicated to mission sessions can be established over the air interface on the data plane to provide services with specific QoS.

[0322] Different data sessions of a task session can be mapped and connected through one or more Data-TW-GWs, depending on whether Data-TW-GWs are deployed and how many Data-TW-GWs are deployed.

[0323] Different data sessions of a task session can be mapped and connected within the CB entity.

[0324] Figure 14 This is a schematic diagram illustrating the configuration of tunnels per data (inter-GW) session according to one or more embodiments of this disclosure. Figure 14As shown, rectangles represent data sessions or inter-GW sessions for a task session, and cylinders represent tunnels specifically configured for data sessions or inter-GW sessions for a task session. Tunnels are configured per data session of a task session and cannot be shared between different data sessions or inter-GW sessions between two network entities. Tunnel types are not limited to GTP-U tunnels, Quick UDP Internet Connection (QUIC) connections, etc. In the following text, the term "QUIC connection" may also be referred to as a tunnel. CB entity 1 establishes data sessions 1 and 2 with Data-TW-GW 1. CB entity 2 establishes data sessions 3, 4, and 5 with Data-TW-GW 1. CB entity 3 establishes data sessions 1 and 2 with Data-TW-GW 2. Inter-GW sessions 1 and 2 are established between Data-TW-GW 1 and Data-TW-GW 2. Seven tunnels are established, each dedicated to a data session; two tunnels are established, each dedicated to an inter-GW session. As shown by the dashed lines, data sessions 1 and 2 of CB entity 1 are mapped to data session 3 of CB entity 2 via Data-TW-GW 1. Data session 3 of CB entity 2 is mapped within CB entity 2 to data session 4 of CB entity 2. Data session 4 of CB entity 2 is mapped to inter-GW session 1 via Data-TW-GW 1. Inter-GW session 1 is mapped to data session 2 of CB entity 3 via Data-TW-GW 2. Data session 2 of CB entity 3 is mapped within CB entity 3 to data session 1 of CB entity 3. Data session 1 of CB entity 3 is mapped to inter-GW session 2 via Data-TW-GW 2. For example, CB entity 1 executes CB 1 and CB 2, corresponding to data sessions 1 and 2 respectively. CB entity 1 sends the data processing results of CB 1 and CB 2 (corresponding to data sessions 1 and 2 respectively) to data session 3 of CB entity 2 via Data-TW-GW 1. CB entity 2 executes CB 3 to use the data received from CB entity 1, and then sends the new data processing result back to CB entity 1. Data forwarding and processing are performed back and forth between CB entity 1 and CB entity 2 until CB 1 and CB 2 of CB entity 1 and CB 3 of CB entity 2 are completed. CB entity 2 sends the final data processing result of CB 3 to data session 4 of CB entity 2. CB entity 2 executes CB 4 corresponding to data session 4 and uses inter-GW session 1 to send the data processing result to data session 2 of CB entity 3 via Data-TW-GW 1 and Data-TW-GW 2. CB entity 3 executes CB 6 corresponding to data session 2.Data forwarding and processing are performed back and forth between CB entity 2 and CB entity 3 until CB 4 of CB entity 2 and CB 6 of CB entity 3 are completed. CB entity 3 sends the final data processing result of CB 6 to data session 1 of CB entity 3. CB entity 3 executes CB 7 corresponding to data session 1 and uses inter-GW session 2 to send the data processing result to data session 5 of CB entity 2 via Data-TW-GW 2 and Data-TW-GW 1. CB entity 2 executes CB 5 corresponding to data session 5. Data forwarding and processing are performed back and forth between CB entity 3 and CB entity 2 until CB 5 of CB entity 2 and CB 7 of CB entity 3 are completed. At this point, the task is complete. It can be seen that some data from CB entity 2 should be sent to CB entity 1 via Data-TW-GW 1, and some data from CB entity 2 should be sent to CB entity 3 via Data-TW-GW 1. In order for the CB entity and Data-TW-GW to transmit data in the specific order of the CB of the task through appropriate tunnels, and in order for the CB entity and Data-TW-GW to detect and identify packets received through tunnels, data forwarding information, such as data mapping information and tunnel information, should be configured for the CB entity and Data-TW-GW, and data processing information, such as CB sequence, should be configured for the CB entity.

[0325] In some cases, CB entity 1, CB entity 2, and Data-TW-GW 1 reside in network domain 1, while CB entity 3 and Data-TW-GW 2 reside in network domain 2. Network domain 1 and network domain 2 may be the same or different. Network domains include, but are not limited to, RAN, CN, DN, and terminal equipment. For example, network domain 1 may be RAN, network domain 2 may be CN, and vice versa. Network domain 1 may be RAN, network domain 2 may be DN, and vice versa. Network domain 1 may be CN, network domain 2 may be DN, and vice versa. Network domain 1 may be RAN, network domain 2 may be a device, and vice versa.

[0326] In some cases, one or more network entities may reside in the DN. For example, CB entity 1, CB entity 2, Data-TW-GW 1, and Data-TW-GW 2 may reside in the CN, while CB entity 3 may reside in the DN. Alternatively, CB entity 1, CB entity 2, and Data-TW-GW 1 may reside in the RAN, Data-TW-GW 2 in the CN, and CB entity 3 in the DN. Another example: Data-TW-GW 2 and CB entity 3 may reside in the RAN, Data-TW-GW 1 in the CN, and CB entity 1 and CB entity 2 in the DN. Yet another example: Data-TW-GW 2, CB entity 3, and Data-TW-GW 1 may reside in the CN, while CB entity 1 and CB entity 2 may reside in the DN.

[0327] Figure 15 This is a schematic diagram illustrating the configuration of tunnels per task session according to one or more embodiments of this disclosure. Figure 15 As shown, the rectangles represent data sessions or inter-GW sessions within a task session, and... Figure 14 The difference lies in the fact that the cylinder represents a tunnel configured for a task session between two network entities. Tunnels are configured per task session and can be shared by different data sessions between the two network entities or between GWs. The type of tunnel is not limited to GTP-U tunnels, QUIC connections, etc. Tunnel 1 for a task session is established between CB entity 1 and Data-TW-GW 1; tunnel 2 for a task session is established between CB entity 2 and Data-TW-GW 1; tunnel 3 for a task session is established between CB entity 3 and Data-TW-GW 2; and tunnel 4 for a task session is established between Data-TW-GW 1 and Data-TW-GW 2. For example, some packets received from tunnel 2 (such as packets from data session 3) should be forwarded by Data-TW-GW 1 to CB entity 1, but some packets received from tunnel 2 (such as packets from data session 4) should be forwarded by Data-TW-GW 1 to Data-TW-GW 2, and then forwarded to CB entity 3. Unlike configuring dedicated tunnels per data session, when configuring tunnels per task session, additional information should be configured to enable the CB entity and / or Data-TW-GW to detect, identify and transmit packets, and the necessary information should be encapsulated in the packet header.

[0328] Figure 16 This is a schematic diagram illustrating the configuration of tunnels by network entity according to one or more embodiments of this disclosure. Figure 16 As shown, with Figure 14 and Figure 15In contrast, two task sessions are shown, represented by dashed and solid lines respectively. Rectangles represent data sessions or inter-GW sessions within a task session, and cylinders represent tunnels shared by two task sessions between network entities. Three data sessions (1, 2, and 3) are established between CB entity 1 and Data-TW-GW 1; four data sessions (4, 5, 6, and 7) are established between CB entity 2 and Data-TW-GW 1; and two data sessions (1 and 2) are established between CB entity 3 and Data-TW-GW 2. Data sessions 1 and 2 of CB entity 1, data sessions 4 and 5 of CB entity 2, and data session 2 of CB entity 3 belong to task session 1. Data sessions 3 of CB entity 1, data sessions 6 and 7 of CB entity 2, and data session 1 of CB entity 3 belong to task session 2. Tunnels are configured per network entity. This means that tunnels can be shared by different task sessions of network entities. The tunnel type is not limited to GTP-U tunnels, QUIC connections, etc. Tunnel 1, used for two task sessions, is established between CB entity 1 and Data-TW-GW 1; tunnel 2, used for two task sessions, is established between CB entity 2 and Data-TW-GW 1; tunnel 3, used for two task sessions, is established between CB entity 3 and Data-TW-GW 2; and tunnel 4, used for two task sessions, is established between Data-TW-GW 1 and Data-TW-GW 2. For example, some packets received from tunnel 2 (such as packets from data session 4) should be forwarded by Data-TW-GW 1 to CB entity 1, but some packets received from tunnel 2 (such as packets from data session 5) should be forwarded by Data-TW-GW 1 to Data-TW-GW 2, and then forwarded to CB entity 3. Unlike configuring tunnels by data session (by inter-GW session) or by task session, when configuring tunnels by network entity, additional information should be configured to enable CB entities and Data-TW-GW to detect, identify, and transmit packets, and necessary information should be encapsulated in the packet header.

[0329] like Figure 14 , Figure 15 and Figure 16 As shown, GTP-U tunnels can be configured at different granularities (e.g., by data session (by inter-GW session), by task session, or by network entity (i.e., the tunnel is shared by multiple task sessions)). The following issues need to be addressed:

[0330] Task services are provided through task sessions and data sessions. This differs from 5G, where connectivity services are provided through PDU sessions. In 5G, GTP-U tunnels are configured per PDU session, and network entities can associate packets received from GTP-U tunnels with PDU sessions because GTP-U tunnels are specifically configured for PDU sessions. For task services, how can network entities detect and distinguish which data session / inter-GW session a packet received from a GTP-U tunnel belongs to?

[0331] Data (inter-GW) sessions can be further refined into one or more QoS flows. For connectivity services, the GTP-U header includes (e.g., in the PDU session container) a QFI to enable network entities to detect and distinguish the data QoS flow to which packets received from the GTP-U tunnel belong. For mission services, how do network entities detect and distinguish which QoS flow packets received from the GTP-U tunnel belong?

[0332] In this disclosure, when GTP-U tunnels can be configured at different granularities (e.g., by data session (or by inter-GW session), by task session, or by network entity), new types of extension headers (e.g., with new type values) are defined: data session container, inter-GW session container, task session container, CB entity container, and Data-TW-GW container.

[0333] A new field has been added to the GTP-U extension header:

[0334] When a GTP-U tunnel is configured by data session (or by inter-GW session), by task session, or by network entity, add one or more of the following to the newly defined GTP-U extension header: task session ID, data session ID (and / or auxiliary information), and inter-GW session ID (and / or auxiliary information).

[0335] The PDU session container is reused for the task session, but the PDU session container has a new meaning and includes new fields.

[0336] Figure 17 This is a schematic flowchart of a communication method according to one or more embodiments of the present disclosure.

[0337] refer to Figure 17 A communication method is provided, including:

[0338] Step 1: Receive packets;

[0339] Step 2: Send GTP-U packets generated based on the packet and General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U). The GTP-U packets include information about the mission session, which is used to provide mission services to mission clients. The mission service is a service used for both packet data unit (PDU) connection and data processing.

[0340] The above method is performed by the first device participating in the task session ( Figure 17 The illustrated device 1) is implemented as a device, or one or more components included in a device, such as a processor or chip. The device may be a user equipment, terminal, network device, network function, network node, or other network element, and this disclosure does not limit this.

[0341] In some cases, the above method also includes a step of determining information about the task session.

[0342] Accordingly, one embodiment of this disclosure also provides a communication method, including:

[0343] Step 2: Receive General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) packets. GTP-U packets are packets based on the GTP-U protocol and include information about the mission session. The mission session is used to provide mission services to mission clients. Mission services are services used for both packet data unit (PDU) connection and data processing.

[0344] Step 3: Determine the task session to which the GTP-U packet belongs based on the information about the task session.

[0345] The above method is provided by a second device participating in the task session ( Figure 17 The second device, as shown in device 2), can be implemented as a device, or one or more components included in a device, such as a processor or chip. The device can be a user equipment, terminal, network device, network function, network node, or other network element, and this disclosure does not limit this.

[0346] In one implementation, information about the task session is included in the packet header of the GTP-U packet or the payload of the GTP-U packet.

[0347] It should be noted that, since network entities include CB entities and Data-TW-GW (also known as GW entities), in this disclosure, for CB entities, the term "by network entity" is equivalent to the term "by CB entity"; for Data-TW-GW, the term "by network entity" is equivalent to the terms "by Data-TW-GW" and "by GW entity".

[0348] Tunneling granularity by data session and / or by inter-GW session

[0349] GTP-U packets are transmitted through GTP-U tunnels, which are dedicated to data sessions. In other words, the granularity of a GTP-U tunnel can be either a data session or an inter-GW session.

[0350] In some cases, information about a task session includes a Quality of Service (QoS) flow identifier (QFI) and / or a CBID. The QFI indicates the QoS flow associated with a GTP-U packet, which is one of one or more QoS flows included in the data session. The CBID indicates the first CB associated with a GTP-U packet, and the data session corresponds to one or more CBs including the first CB.

[0351] Information about the mission session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and QFI and / or CBID are included in the GTP-U extension header.

[0352] In one implementation, the GTP-U extension header can be a Type I GTP-U extension header, which is a data session container. Information about the task session includes a first field, which the Type I GTP-U extension header uses to indicate that the GTP-U tunnel is dedicated to the data session. The value of the first field is 1000 1000. This first field, by indicating the Type I GTP-U extension header, signifies that the GTP-U tunnel is dedicated to the data session.

[0353] In another implementation, the GTP-U extension header can be a type II GTP-U extension header, and the GTP-U packet includes an indication indicating whether the type II GTP-U extension header is used for a data session. This indication is either included in the type II GTP-U extension header or, alternatively, information about the task session includes a second field containing the indication. This indication is 2 bits, and its value indicates whether the type II GTP-U extension header is used for a PDU session or a data session. Alternatively, information about the task session may include a second field, with the indication provided by a range of values ​​for that field.

[0354] GTP-U packets are transmitted through GTP-U tunnels, which are dedicated to inter-GW sessions.

[0355] In some cases, information about a task session includes a QFI and / or a CBID, where the QFI indicates the QoS flow associated with a GTP-U packet, which is one of one or more QoS flows included in an inter-GW session, and the CBID indicates the first CB associated with a GTP-U packet, with a data session or an inter-GW session corresponding to one or more CBs including the first CB.

[0356] In addition, information about the mission session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and QFI and / or CBID are included in the GTP-U extension header.

[0357] In one implementation, the GTP-U extension header can be a Type I GTP-U extension header, which is a container for inter-GW sessions. Information about the task session includes a first field, which is indicated by the Type I GTP-U extension header, and the value of the first field is 1000 1001. This first field indicates that the GTP-U tunnel is dedicated to inter-GW sessions by indicating the Type I GTP-U extension header.

[0358] In another implementation, the GTP-U extension header is a Type II GTP-U extension header. The GTP-U packet includes an indication indicating whether the Type II GTP-U extension header is used for inter-GW sessions. This indication is either included in the Type II GTP-U extension header or, alternatively, information about the task session includes a second field containing the indication. This indication is 2 bits, and its value indicates whether the Type II GTP-U extension header is used for a PDU session or an inter-GW session. Alternatively, information about the task session may include a second field, with the indication provided by a range of values ​​for that field.

[0359] To enable receiving network entities to distinguish between specific data sessions or inter-GW sessions associated with received packets, two main concepts exist: defining new types of GTP-U extension headers to include information about the task session, and reusing existing GTP-U extension headers to include information about the task session.

[0360] Specifically, in the case of defining a new type of GTP-U extension header, such as Figure 14 As shown, for a task session, GTP-U tunnels are configured either per data session or per inter-GW session. New types of GTP-U extension headers can be defined.

[0361] Figure 18 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure. Figure 18As shown, the "Data Session Container" type is defined, along with its corresponding "Next Extension Header Field Value". Additionally, the "Inter-GW Session Container" type is defined, along with its corresponding "Next Extension Header Field Value". The first field included in the task session information can be referred to as the "Next Extension Header Field" mentioned above. For the Data Session Container, the value of the first field (i.e., the Next Extension Header Field) can be 1000 1000; for the Inter-GW Session Container, the value of the first field (i.e., the Next Extension Header Field) can be 1000 1001.

[0362] The characteristics and uses of the new type of GTP-U connector can be followed Figure 7 , Figure 8 and Figure 9 The method for the general GTP-U extension head.

[0363] It should be noted that the format of the GTP-U extension header can be found by referring to [reference needed]. Figure 9 The aforementioned format.

[0364] The type of data session container can be indicated by a specific field value (such as the following extended header field value), for example, 1000 1000 or other reserved values.

[0365] When the extension header type is set to a data session container (e.g., the next extension header field value is set to 10001000), the data session container is encapsulated in the GTP-U packet. This data session container extension header can be transmitted between network entities (e.g., between CB entities, and between a CB entity and a Data-TW-GW) via network interfaces. CB entities can reside in devices, RANs, CNs, and DNs. Data-TW-GWs can reside in devices, RANs, CNs, and DNs. In some cases, the Data-TW-GW can be a UPF or an evolved UPF. The data session container can have a variable length. Furthermore, the data session container includes information to be associated with the data session (control cells, data processing, and / or data forwarding indication information).

[0366] In some cases, a data session comprises one or more QoS flows. One or more QoS flows are transmitted over the data session. A QoS flow is the smallest unit of granularity for implementing QoS differentiation within a data session. Traffic within a QoS flow of a data session undergoes the same data forwarding processing (such as scheduling, admission thresholds, latency, and packet loss rate) and / or data processing (such as data processing latency, data processing accuracy, and data processing privacy). A QoS flow ID (QFI) is used to identify a QoS flow.

[0367] The contents of the data session container include QFI and / or CBID. That is, information about the task session can include QFI and / or CBID. Network entities (such as CB entities, Data-TW-GW) can use the received QFI to determine the QoS flow and QoS profile associated with received packets in the data session, and use the received CBID to determine the CB associated with GTP-U packets.

[0368] In some cases, the contents of the data session containers used for downlink packets (such as inbound packets) and uplink packets (such as outbound packets) can be respectively as follows: Figure 10 and Figure 11 As shown.

[0369] In some cases, data session data plane protocol data is carried through the GTP-U protocol mechanism, more specifically, through the "data session container" in the GTP-U extension header.

[0370] When a network entity receives a packet from a tunnel that includes a data session container (optionally including a QFI, for example, if the data session includes one or more QoS flows), the network entity can determine the data session (optionally, its QFI) to which the packet belongs. The data session can be determined because the tunnel is specifically configured for data sessions. The task session can be determined because the data session belongs to a task (for example, the relationship between task sessions and data sessions is pre-configured to the network entity when a task session is established). QoS flows can be determined based on the QFI.

[0371] The type of the inter-GW session container can be indicated by a specific field value (such as the following extended header field value), for example, 1000 1001 or other reserved values.

[0372] When the extension header type is set to inter-GW session container (e.g., the next extension header field value is set to 10001001), the inter-GW session container is encapsulated in the GTP-U packet. This type of inter-GW session container extension header can be transmitted between network entities (e.g., between CB entities, between a CB entity and a Data-TW-GW, and between Data-TW-GWs) via network interfaces. CB entities can reside in devices, RANs, CNs, and DNs. Data-TW-GWs can reside in devices, RANs, CNs, and DNs. In some cases, the Data-TW-GW can be a UPF or an evolved UPF. The inter-GW session container can have a variable length. Furthermore, the inter-GW session container includes information to be associated with the inter-GW session (control cells and / or data forwarding indication information).

[0373] In some cases, an inter-GW session comprises one or more QoS flows. One or more QoS flows are transmitted over the inter-GW session. A QoS flow is the smallest unit of granularity for implementing QoS differentiation within an inter-GW session. Traffic within a QoS flow of an inter-GW session undergoes the same data forwarding processing (e.g., scheduling, admission thresholds, latency, and packet loss rate) and / or data processing (e.g., data processing latency, data processing accuracy, and data processing privacy). A QoS flow ID (QFI) is used to identify the QoS flow.

[0374] The contents of the inter-GW session container include QFI and / or CBID. That is, information about the task session can include QFI and / or CBID. Network entities (such as CB entities, Data-TW-GW) can use the received QFI to determine the QoS flow and QoS profile associated with received packets in the inter-GW session, and use the received CBID to determine the CB associated with GTP-U packets.

[0375] In some cases, the contents of the inter-GW session containers used for downlink packets (such as inbound packets) and uplink packets (such as outbound packets) can be respectively as follows: Figure 10 and Figure 11 As shown.

[0376] In some cases, inter-GW session data plane protocol data is carried through the GTP-U protocol mechanism, more specifically, through the "inter-GW session container" in the GTP-U extension header.

[0377] When a network entity receives a packet from a tunnel that includes an inter-GW session container (optionally including a QFI, for example, if the inter-GW session includes one or more QoS flows), the network entity can determine the inter-GW session to which the packet belongs (optionally determining its QFI). The inter-GW session can be determined because the tunnel is specifically configured for inter-GW sessions. The task session can be determined because the inter-GW session belongs to a task (for example, the relationship between the task session and the inter-GW session is pre-configured to the network entity when the task session is established). QoS flows can be determined based on the QFI.

[0378] Specifically, when reusing existing GTP-U extension headers, GTP-U tunnels are configured on a data session or an inter-GW session basis for the task session. PDU session containers (or other containers, such as RAN containers) are reused instead of defining new types of GTP-U extension headers. In some cases, the information carried in the PDU session container can be as follows: Figure 10 or Figure 11As shown. Furthermore, the second type of GTP-U extension header can also be called a PDU session container, RAN container, new radio (NR) RAN container, or Xw RAN container, etc. It should be noted that the explanation will use the PDU session container as an example.

[0379] In existing technologies, PDU session containers can be transmitted between NG-RAN and UPF or between two UPFs via the N3 and N9 user plane interfaces; between MB-UPF and NG-RAN or between MB-UPF and UPF via the N3mb and N19mb user plane interfaces; and via data forwarding tunnels in 5GS for data forwarding between 5GS and EPS. PDU session containers have variable lengths, as specified in 3GPP TS 38.415. RAN containers can be transmitted via the X2 user plane interface between eNBs. RAN containers have variable lengths, as specified in 3GPP TS 36.425. NR RAN containers can be transmitted in G-PDUs via the X2-U, Xn-U, and F1-U user plane interfaces. NR RAN containers have variable lengths, as specified in 3GPP TS 38.425. The Xw user plane interface is located between the eNB and the WLAN Termination (WT). The Xw RAN container has a variable length, the contents of which are specified in 3GPP TS 36.465.

[0380] The characteristics and uses of PDU session containers can be followed Figure 7 , Figure 8 and Figure 9 The method for the general GTP-U extension head.

[0381] It should be noted that the format of the GTP-U extension header can be found by referring to [reference needed]. Figure 9 The aforementioned format.

[0382] In some cases, the PDU session container includes an indicator to distinguish whether the PDU session container is used for a PDU session, a data session, or an inter-GW session. For example, this indicator can be 2 bits. When the 2 bits are set to 00, it indicates that the PDU session container is used for a PDU session; when the 2 bits are set to 01, it indicates that the PDU session container is used for a data session; and when the 2 bits are set to 10, it indicates that the PDU session container is used for an inter-GW session.

[0383] In some cases, this indication can also be located outside the PDU session container. For example, the field value of the PDU session container can be extended (as shown in the following extended header field value) to distinguish whether the PDU session container is used for a PDU session, a data session, or an inter-GW session. For example, 1000 0101 indicates that the packet is associated with a PDU session, 1000 1000 indicates that the packet is associated with a data session, and 10001001 indicates that the packet is associated with an inter-GW session. Alternatively, this indication (e.g., 2 bits) can be located in the TEID field. Furthermore, a first range of TEIDs can be reserved for PDU sessions, a second range of TEIDs can be reserved for data sessions, and a third range of TEIDs can be reserved for inter-GW sessions. The second field included in the information about the task session can be referred to as the TEID mentioned above.

[0384] Figure 19 This is a schematic diagram illustrating the evolution format of downlink (DL) PDU session information according to one or more embodiments of this disclosure. In some cases, the format of information (such as PDU session information) included in the PDU session container for downlink packets (such as ingress packets) is as follows: Figure 19 (It is) Figure 10 As shown in the evolved version. (Reference) Figure 19 The spare field includes the aforementioned indication (e.g., 2 bits).

[0385] Similarly, the spare fields for PDU session information included in the PDU session container used for uplink packets include the aforementioned indication (e.g., 2 bits), which are omitted here. Figure 11 The corresponding evolved version.

[0386] It should be noted that the position of the above indication within the PDU session container is not restricted; for example, it can be located within, before, or after other fields. For instance, the above indication (e.g., 2 bits) can be located within, before, or after a padding field.

[0387] When a network entity receives a packet from a tunnel that includes an indication (optionally including a QFI, e.g., if a data session (inter-GW) includes one or more QoS flows), the network entity can determine the PDU session, or the data (inter-GW) session of the task session to which the packet belongs (optionally determining its QFI). The task session can be determined because the tunnel is specifically configured for PDU sessions and / or data (or inter-GW) sessions. The task session can be determined because the data (inter-GW) session belongs to a task (e.g., the relationship between task sessions and data (inter-GW) sessions is pre-configured to the network entity when a task session is established). QoS flows can be determined based on the QFI.

[0388] In some cases, if the smallest granularity of traffic is a data (inter-GW) session rather than a QoS flow, then QFI is not included in the GTP-U header; otherwise, QFI is included in the GTP-U header.

[0389] In some cases, a range of TEID values ​​can be reserved for data sessions.

[0390] In some cases, a range of TEID values ​​can be reserved for inter-GW sessions.

[0391] In some cases, a range of TEID values ​​can be reserved for the task session.

[0392] In some cases, neither the "data session container" nor the "inter-GW session container" type is defined. For example, a range of TEID values ​​can be reserved for data sessions or inter-GW sessions, allowing network entities to determine whether a GTP-U packet belongs to a data session or an inter-GW session, and not to other sessions (such as PDU sessions).

[0393] By tunnel granularity of task session

[0394] GTP-U packets are transmitted through GTP-U tunnels, which are dedicated to a task session and shared by one or more data sessions within the task session and / or one or more inter-GW sessions. In other words, the granularity of a GTP-U tunnel can be at the task session level.

[0395] In some cases, information about a task session includes one or both of the following: a data session ID and auxiliary information. The data session ID is used to identify a data session included in one or more data sessions, and the auxiliary information is used to help distinguish data sessions or CBs.

[0396] In addition, information about the mission session includes QFI and / or CBID, where QFI indicates the QoS flow associated with the GTP-U packet, and the QoS flow is one of one or more QoS flows included in the data session; and CBID indicates the first CB associated with the GTP-U packet, and the data session corresponds to one or more CBs including the first CB.

[0397] In some cases, information about a task session includes one or both of the following: the inter-GW session ID and auxiliary information. The inter-GW session ID is used to identify the inter-GW session, and the auxiliary information is used to help distinguish between inter-GW sessions or between CBs.

[0398] In addition, information about the mission session includes QFI and / or CBID, where QFI indicates the QoS flow associated with the GTP-U packet, and the QoS flow is one of one or more QoS flows included in the inter-GW session; CBID indicates the first CB associated with the GTP-U packet, and a data session or an inter-GW session corresponds to one or more CBs including the first CB.

[0399] In some cases, information about a task session includes a QFI and / or a CBID, where the QFI indicates the QoS flow associated with a GTP-U packet, and the QoS flow is one of one or more QoS flows in the task session; the CBID indicates the first CB associated with a GTP-U packet, and a data session or an inter-GW session corresponds to one or more CBs including the first CB.

[0400] Information about the mission session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header containing one or more of the following: data session ID, inter-GW session ID, auxiliary information, QFI, or CBID.

[0401] In one implementation, the GTP-U extension header is a Type I GTP-U extension header, which is a task session container. Information about the task session includes a first field, which the Type I GTP-U extension header indicates, with a value of 1000 1010. This first field, by indicating the Type I GTP-U extension header, indicates that the GTP-U tunnel is dedicated to the task session.

[0402] In another implementation, the GTP-U extension header is a Type II GTP-U extension header. The GTP-U packet includes an indication indicating whether the Type II GTP-U extension header is used for a task session. This indication is either included in the Type II GTP-U extension header or, alternatively, information about the task session is included in a second field containing the indication. This indication is 2 bits, and its value indicates whether the Type II GTP-U extension header is used for a PDU session or a task session. Alternatively, information about the task session may include a second field, with the indication provided by a range of values ​​for that field.

[0403] Specifically, in the case of defining a new type of GTP-U extension header, such as Figure 15 As shown, the GTP-U tunnel is configured per task session. New types of GTP-U extension headers can be defined.

[0404] Figure 20 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure. Figure 20As shown, the type "Task Session Container" is defined, along with its corresponding "Next Extension Header Field Value". The first field included in the information about the task session can be referred to as the next extension header field mentioned above. For a task session container, the value of the first field (i.e., the next extension header field) can be 1000 1010.

[0405] The characteristics and uses of the new type of GTP-U connector can be followed Figure 7 , Figure 8 and Figure 9 The method for the general GTP-U extension head.

[0406] It should be noted that the format of the GTP-U extension header can be found by referring to [reference needed]. Figure 9 The aforementioned format.

[0407] The type of the task session container can be indicated by a specific field value (such as the following extended header field value), for example, 1000 1010 or other reserved values.

[0408] When the extension header type is set to Task Session Container (e.g., the next extension header field value is set to 10001010), the Task Session Container is encapsulated in the GTP-U packet. This Task Session Container extension header can be transmitted between network entities (e.g., between CB entities, and between a CB entity and a Data-TW-GW) via network interfaces. CB entities can reside in devices, RANs, CNs, and DNs. Data-TW-GWs can reside in devices, RANs, CNs, and DNs. In some cases, the Data-TW-GW can be a UPF or an evolved UPF. The Task Session Container can have a variable length. Furthermore, the Task Session Container includes information (control cells, data processing, and / or data forwarding indication information) to be associated with the data session and / or inter-GW session of the Task Session.

[0409] Data session IDs and / or auxiliary information can be included in the task session container. Based on the data session IDs and / or auxiliary information, network entities (such as CB entities, Data-TW-GW) can detect and distinguish the data session to which packets received from the tunnel of the task session belong.

[0410] Auxiliary information is used to help distinguish the data session to which packets received from / sent to the tunnel of the task session belong.

[0411] When the data session ID alone is sufficient to distinguish the data session to which a packet received from / sent to a task session's tunnel belongs, and that data session ID is encapsulated within the packet (such as in a packet header or packet payload), there is no need to include auxiliary information in the packet. For example, when the data session ID value is assigned to be globally unique within the task session, or is assigned to be globally unique among different data session IDs across all data sessions of the task session, the data session ID alone is sufficient to distinguish the packet.

[0412] When the data session ID alone is insufficient to distinguish the data session to which a packet received from / sent to a task session through the tunnel belongs, or when the data session ID is not encapsulated in the packet (such as in the packet header or packet payload), auxiliary information needs to be configured.

[0413] In some cases, auxiliary information may be one or more of the following: operation ID identifying the data processing operation, CBID identifying the CB, step ID identifying the process step, and task client ID identifying the task session client. Data processing may include, but is not limited to, AI training, AI inference, data preprocessing, data de-identification (data privacy protection), data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0414] In some cases, the data session ID and / or auxiliary information to be detected or encapsulated in packets are configured to the network entity by a C / M plane function (such as a mission control function (MCF)). In other cases, prior to configuration, the data session ID and / or auxiliary information (e.g., information to be detected from packets by the network entity) are reported to the C / M plane function by the peer node of the network entity (such as a Data-TW-GW).

[0415] In some cases, if auxiliary information (such as operation ID, CBID) is sufficient to distinguish the data session to which a packet received from / sent to the tunnel of a task session belongs, and that auxiliary information (such as operation ID) is encapsulated in the packet (such as packet header or packet payload), then it is not necessary to encapsulate the data session ID in the packet header.

[0416] In some cases, if auxiliary information (such as operation ID, CBID) alone is insufficient to distinguish the data session to which a packet received from / sent to the tunnel of a task session belongs, it is necessary to encapsulate both the data session ID and auxiliary information (such as operation ID) in the packet (such as the packet header or packet payload).

[0417] Similarly, inter-GW session IDs and / or auxiliary information can be included in the task session container. Based on the inter-GW session IDs and / or auxiliary information, network entities (such as CB entities, Data-TW-GW) can detect and distinguish the inter-GW session to which packets received from the tunnel of the task session belong.

[0418] Auxiliary information is used to help distinguish the inter-GW session to which packets received from / sent to the tunnel of the task session belong.

[0419] When the inter-GW session ID alone is sufficient to distinguish the inter-GW session to which a packet received from / sent to a task session's tunnel belongs, and the inter-GW session ID is encapsulated within the packet (such as in the packet header or packet payload), there is no need to include auxiliary information in the packet. For example, when the value of the inter-GW session ID is assigned to be globally unique within the task session, or is assigned to be globally unique among different inter-GW session IDs across all inter-GW sessions of the task session, the inter-GW session ID alone is sufficient to distinguish the packet.

[0420] When the inter-GW session ID alone is insufficient to distinguish the inter-GW session to which a packet received from / sent to a task session through the tunnel belongs, or when the inter-GW session ID is not encapsulated in the packet (such as in the packet header or packet payload), auxiliary information needs to be configured.

[0421] In some cases, auxiliary information may be one or more of the following: operation ID identifying the data processing operation, CBID identifying the CB, step ID identifying the process step, and task client ID identifying the task session client. Data processing may include, but is not limited to, AI training, AI inference, data preprocessing, data de-identification (data privacy protection), data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0422] In some cases, the inter-GW session ID and / or auxiliary information to be detected or encapsulated in packets are configured to the network entity by a C / M plane function (such as MCF). In other cases, prior to configuration, the inter-GW session ID and / or auxiliary information (e.g., to be detected by the network entity from packets) are reported to the C / M plane function by the peer node of the network entity (such as Data-TW-GW).

[0423] In some cases, if auxiliary information (such as operation ID, CBID) is sufficient to distinguish the inter-GW session to which a packet received from / sent to the tunnel of a task session belongs, and the auxiliary information (such as operation ID) is encapsulated in the packet (such as packet header or packet payload), then it is not necessary to encapsulate the inter-GW session ID in the packet header.

[0424] In some cases, if auxiliary information (such as operation ID, CBID) alone is insufficient to distinguish the inter-GW session to which a packet received from / sent to the tunnel of a task session belongs, it is necessary to encapsulate both the inter-GW session ID and auxiliary information (such as operation ID) in the packet (such as packet header or packet payload).

[0425] In some cases, task session data plane protocol data is carried through the GTP-U protocol mechanism, more specifically, through the "task session container" in the GTP-U extension header.

[0426] In some cases, a data (inter-GW) session includes one or more QoS flows. One or more QoS flows are transmitted over the data (inter-GW) session. The contents of the task session container include the QFI and / or CBID. That is, information about the task session may include the QFI and / or CBID. Network entities (such as CB entities, Data-TW-GW) can use the received QFI to determine the QoS flows and QoS profiles associated with received packets in the data (inter-GW) session of the task session, and use the received CBID to determine the CB associated with GTP-U packets.

[0427] Figure 21 This is a schematic diagram illustrating the format of DL task session information according to one or more embodiments of this disclosure. In some cases, the format of information (such as task session information) included in the task session container for downlink packets (such as ingress packets) is as follows: Figure 21 (It is) Figure 10 As shown in the evolved version.

[0428] refer to Figure 21 The task session container used for downlink grouping includes the following new fields: data session ID and / or auxiliary information corresponding to the data session ID (such as operation ID), and inter-GW session ID and / or auxiliary information corresponding to the inter-GW session ID (such as operation ID). Information about the task session may include the information carried in the new fields.

[0429] Similarly, the information included in the task session container used for uplink grouping (such as task session information) includes the following new fields: data session ID and / or auxiliary information corresponding to the data session ID (such as operation ID), GW inter-session ID and / or auxiliary information corresponding to the GW inter-session ID (such as operation ID), the format correspondence is omitted here. Figure 11 An evolved version.

[0430] It should be noted that there are no restrictions on the position of the new field within the task session container; for example, it can be located within, before, or after other fields. For instance, the new field can be located within, before, or after a fill field.

[0431] When a network entity receives a packet containing a task session container from a tunnel of a task session, the network entity can determine the data (inter-GW) session to which the packet belongs (optionally, its QFI). The task session can be determined because the tunnel is specifically configured for task sessions. The data session can be determined based on the data session ID and / or auxiliary information (such as the operation ID) encapsulated in the packet (e.g., the packet header). The inter-GW session can be determined based on the inter-GW session ID and / or auxiliary information (such as the operation ID) encapsulated in the packet (e.g., the packet header). QoS flows can be determined based on the QFI.

[0432] In some cases, if the smallest granularity of traffic is a data (inter-GW) session rather than a QoS flow, the QFI is not included in the GTP-U header, for example, by replacing the data (inter-GW) session ID and / or auxiliary information. Figure 10 and Figure 11 The QFI field is included in the header; otherwise, the QFI field is included in the GTP-U header along with the new field.

[0433] Specifically, when reusing existing GTP-U extension headers, GTP-U tunnels are configured per task session. PDU session containers (or other containers, such as RAN containers) are reused instead of defining new types of GTP-U extension headers. In some cases, the information carried in the PDU session container can be as follows: Figure 10 or Figure 11 As shown. Furthermore, the second type of GTP-U extension header can also be called a PDU session container, RAN container, new radio (NR) RAN container, or Xw RAN container, etc. It should be noted that the explanation will use the PDU session container as an example.

[0434] The characteristics and uses of PDU session containers can be followed Figure 7 , Figure 8 and Figure 9 The method for the general GTP-U extension head.

[0435] It should be noted that the format of the GTP-U extension header can be found by referring to [reference needed]. Figure 9 The aforementioned format.

[0436] When either or both of the data session ID (and / or auxiliary information) and the GW inter-session ID (and / or auxiliary information) are included in the PDU session container, this implicitly indicates that the PDU session container is used for a task session; otherwise, the PDU session container is used for a PDU session.

[0437] In some cases, the PDU session container includes an indicator to distinguish whether the PDU session container is used for a PDU session or a task session. For example, this indicator can be 2 bits.

[0438] In some cases, this indication can also be located outside the PDU session container. For example, the field value of the PDU session container can be extended (as shown in the following extended header field value) to distinguish whether the PDU session container is used for a PDU session or a task session. For example, 10000101 indicates that the packet is associated with a PDU session, while 1000 1010 indicates that the packet is associated with a task session. Alternatively, this indication (e.g., 2 bits) can be located in the TEID field. Furthermore, a first range of TEIDs can be reserved for PDU sessions, and a second range of TEIDs can be reserved for task sessions. The second field included in the information about the task session can be referred to as the TEID mentioned above.

[0439] In some cases, the format of information (such as PDU session information) included in the PDU session container used for downlink packets (such as ingress packets) is as follows: Figure 21 As shown. In other words, the information about the task session mentioned above can also be included in the PDU session container.

[0440] Similarly, the PDU session information included in the PDU session container used for uplink packets also includes a new field, which is omitted here. Figure 11 The corresponding evolved version.

[0441] It should be noted that there are no restrictions on the position of the new field within the PDU session container; for example, it can be located within, before, or after other fields. For instance, the new field can be located within, before, or after a fill field.

[0442] When a network entity receives a packet from a tunnel that includes a new field (optionally including the QFI, for example, if the data (inter-GW) session includes one or more QoS flows), the network entity can determine the task session, or the data (inter-GW) session of the task session to which the packet belongs (optionally determining its QFI). The task session can be determined because the tunnel is specifically configured for PDU sessions and / or task sessions. The data session can be determined based on the data session ID and / or auxiliary information (such as the operation ID) encapsulated in the packet (such as the packet header). The inter-GW session can be determined based on the inter-GW session ID and / or auxiliary information (such as the operation ID) encapsulated in the packet (such as the packet header). QoS flows can be determined based on the QFI.

[0443] The above description does not limit the location of the new field in the GTP-U packet. In some cases, the new field (such as data session ID, inter-GW session ID, auxiliary information) may be located in other locations in the GTP-U header, for example, in the TEID.

[0444] In some cases, a range of TEID values ​​can be reserved for data sessions.

[0445] In some cases, a range of TEID values ​​can be reserved for inter-GW sessions.

[0446] In some cases, a range of TEID values ​​can be reserved for the task session.

[0447] In some cases, the "task session container" type is not defined. For example, a range of TEID values ​​can be reserved for task sessions, allowing network entities to determine that GTP-U packets belong to a task session and not to other sessions (such as PDU sessions).

[0448] According to the tunneling granularity of network entities

[0449] GTP-U packets are transmitted through a GTP-U tunnel, which is dedicated to the CB entity and shared by one or more task sessions of the CB entity, including the aforementioned task sessions.

[0450] In some cases, information about a task session may include one or more of the following: task session ID, data session ID, or auxiliary information; the task session ID is used to identify the first task session, the data session ID is used to identify the data sessions included in the first task session, and the auxiliary information is used to help distinguish data sessions or distinguish CBs.

[0451] In addition, information about the mission session includes QFI and / or CBID, where QFI indicates the QoS flow associated with the GTP-U packet, and the QoS flow is one of one or more QoS flows included in the data session; and CBID indicates the first CB associated with the GTP-U packet, and the data session corresponds to one or more CBs including the first CB.

[0452] In some cases, the information in a task session includes a QFI and / or a CBID, where the QFI indicates the QoS flow associated with the GTP-U packet, the QoS flow is one of one or more QoS flows in one or more task sessions of a CB entity, and the CBID indicates the first CB associated with the GTP-U packet, and the data session corresponds to one or more CBs including the first CB.

[0453] Information about the mission session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header containing one or more of the following: mission session ID, data session ID, auxiliary information, QFI, or CBID.

[0454] In one implementation, the GTP-U extension header is a Type I GTP-U extension header, which is a CB entity container. Information about the task session includes a first field, which is indicated by the Type I GTP-U extension header, and the value of the first field is 1000 1011. This first field indicates that the GTP-U tunnel is dedicated to the CB entity by indicating the Type I GTP-U extension header.

[0455] In another implementation, the GTP-U extension header is a Type II GTP-U extension header. The GTP-U packet includes an indication indicating whether the Type II GTP-U extension header is used for a CB entity. This indication is either included in the Type II GTP-U extension header or, alternatively, information about the task session includes a second field containing the indication. This indication is 2 bits, and its value indicates whether the Type II GTP-U extension header is used for a PDU session or a CB entity. Alternatively, information about the task session may include a second field, with the indication provided by a range of values ​​for that field.

[0456] GTP-U packets are transmitted over GTP-U tunnels, which are dedicated to the GW entity and shared by one or more task sessions of the GW entity. The one or more task sessions include task sessions.

[0457] In some cases, information about a task session may include one or more of the following: a task session ID, a data session ID, or first auxiliary information; or one or more of the following: a task session ID, an inter-GW session ID, or second auxiliary information; the task session ID is used to identify a first task session, the data session ID is used to identify a data session included in the first task session, and the first auxiliary information is used to assist in distinguishing data sessions or distinguishing CBs; or, the task session ID is used to identify a first task session, the inter-GW session ID is used to identify an inter-GW session included in the first task session, and the second auxiliary information is used to assist in distinguishing inter-GW sessions or distinguishing CBs.

[0458] In addition, information about the mission session includes QFI and / or CBID, where QFI indicates the QoS flow associated with the GTP-U packet, and the QoS flow is one of one or more QoS flows included in a data session or an inter-GW session; CBID indicates the first CB associated with the GTP-U packet, and a data session or an inter-GW session corresponds to one or more CBs including the first CB.

[0459] In some cases, information about a task session includes a QFI and / or a CBID, where the QFI indicates the QoS flow associated with a GTP-U packet, and the QoS flow is one of one or more QoS flows in one or more task sessions of a GW entity, and the CBID indicates the first CB associated with a GTP-U packet, and a data session or an inter-GW session corresponds to one or more CBs including the first CB.

[0460] Information about the mission session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header containing one or more of the following: mission session ID, data session ID, inter-GW session ID, first auxiliary information, second auxiliary information, QFI, or CBID.

[0461] In one implementation, the GTP-U extension header is a Type I GTP-U extension header, which is a GW entity container. Information about the task session includes a first field, which is indicated by the Type I GTP-U extension header, and the value of the first field is 1000 1100. This first field indicates that the GTP-U tunnel is dedicated to the GW entity by indicating the Type I GTP-U extension header.

[0462] In another implementation, the GTP-U extension header is a Type II GTP-U extension header. The GTP-U packet includes an indication indicating whether the Type II GTP-U extension header is used for a GW entity. This indication is either included in the Type II GTP-U extension header or, alternatively, information about the task session includes a second field containing the indication. This indication is 2 bits, and its value indicates whether the Type II GTP-U extension header is used for a PDU session or a GW entity. Alternatively, information about the task session may include a second field, with the indication provided by a range of values ​​for that field.

[0463] Specifically, in the case of defining a new type of GTP-U extension header, such as Figure 16 As shown, GTP-U tunnels are configured per network entity. A GTP-U tunnel can be shared by multiple task sessions. New types of GTP-U extension headers can be defined.

[0464] Figure 22 This is a schematic diagram illustrating the definition of an extension header type according to one or more embodiments of this disclosure. Figure 22 As shown, the type "CB entity container" is defined, and the corresponding "next extension header field value" is also defined.

[0465] In addition, the type "Data-TW-GW Container" is defined, along with its corresponding "Next Extension Header Field Value". The GW entity container can be referred to as the Data-TW-GW container mentioned above. The first field included in the task session information can be referred to as the Next Extension Header field mentioned above. For the CB entity container, the value of the first field (i.e., the Next Extension Header field) can be 1000 1011; for the GW entity container, the value of the first field (i.e., the Next Extension Header field) can be 1000 1100.

[0466] The characteristics and uses of the new type of GTP-U connector can be followed Figure 7 , Figure 8 and Figure 9 The method for the general GTP-U extension head.

[0467] It should be noted that the format of the GTP-U extension header can be found by referring to [reference needed]. Figure 9 The aforementioned format.

[0468] The type of a CB entity container can be indicated by a specific field value (such as the following extended header field value), for example, 10001011 or other reserved values.

[0469] When the extension header type is set to CB Entity Container (e.g., the next extension header field value is set to 1000 1011), the CB Entity Container is encapsulated in the GTP-U packet. This type of CB Entity Container extension header can be transmitted between network entities (e.g., between CB entities, and between a CB entity and a Data-TW-GW) via network interfaces. CB entities can reside in devices, RANs, CNs, and DNs. Data-TW-GWs can reside in devices, RANs, CNs, and DNs. In some cases, the Data-TW-GW can be a UPF or an evolved UPF. CB Entity Containers can have variable lengths. Furthermore, the CB Entity Container includes information to be associated with the data session of the task session (control cells, data processing, and / or data forwarding indication information).

[0470] One or more of the following are included in the CB entity container: task session ID, data session ID, and auxiliary information. Based on one or more of the task session ID, data session ID, and auxiliary information, a network entity (such as a CB entity) can detect and distinguish the data session to which a packet received from a tunnel shared by multiple task sessions belongs.

[0471] Auxiliary information is used to help distinguish the data session to which packets received from / sent to a tunnel shared by the task session belong.

[0472] In some cases, when the task session ID and data session ID together are sufficient to distinguish the data session to which a packet received from / sent to a tunnel shared by the task sessions belongs, and when the task session ID and data session ID are encapsulated together in the packet (such as in a packet header or packet payload), it is not necessary to include auxiliary information in the packet. For example, when the value of the data session ID is assigned globally unique within a task session, and when the value of the task session ID is assigned globally unique across different task sessions, the task session ID and data session ID together are sufficient to distinguish the packet.

[0473] In some cases, when the data session ID alone is sufficient to distinguish the data session to which a packet received from / sent to a tunnel shared by the task sessions belongs, and that data session ID is encapsulated in the packet (such as in the packet header or packet payload), there is no need to include auxiliary information in the packet. For example, when the data session ID is assigned globally unique among the different data session IDs of all data sessions in all task sessions established between two network entities, the data session ID alone is sufficient to distinguish the packet.

[0474] In some cases, when the task session ID and data session ID together are insufficient to distinguish the data session to which a packet received from / sent to a tunnel shared by the task session belongs, it is necessary to include auxiliary information in the packet header.

[0475] In some cases, when the task session ID and data session ID together are sufficient to distinguish the data session to which a packet received from / sent to a tunnel shared by the task session belongs, but the task session ID or data session ID (e.g., only the task session ID or data session ID is encapsulated in the packet) is not encapsulated in the packet (such as in the packet header or packet payload), it is necessary to include auxiliary information in the packet header.

[0476] In some cases, when configuring auxiliary information, the auxiliary information alone, or the task session ID together with the auxiliary information, or the data session ID together with the auxiliary information, or the task session ID, data session ID, and auxiliary information together should be sufficient to distinguish the data session to which a packet received from / sent to a tunnel shared by the task session belongs, and need to be encapsulated in that packet.

[0477] In some cases, auxiliary information may be one or more of the following: operation ID identifying the data processing operation, CBID identifying the CB, step ID identifying the process step, and task client ID identifying the task session client. Data processing may include, but is not limited to, AI training, AI inference, data preprocessing, data de-identification (data privacy protection), data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0478] In some cases, one or more of the following are configured to the network entity by a C / M plane function (such as MCF): the task session ID to be detected or encapsulated in the packet, the data session ID, and auxiliary information. In some cases, prior to configuration, the data session ID and / or auxiliary information (e.g., to be detected by the network entity from the packet) are reported to the C / M plane function by the peer node of the network entity (such as Data-TW-GW).

[0479] The following description of CB entity containers uses the example of task session ID, data (or inter-GW) session ID, and auxiliary information all being included in the group. This can be extended to other cases, such as task session ID and data (or inter-GW) session ID or auxiliary information being included in the group.

[0480] In some cases, a data session includes one or more QoS flows. One or more QoS flows are transmitted over the data session. The contents of the CB entity container include the QFI and / or CBID. That is, information about the task session may include the QFI and / or CBID. Network entities (such as CB entities, Data-TW-GW) can use the received QFI to determine the QoS flows and QoS profiles associated with received packets in the data session of the task session, and use the received CBID to determine the CB associated with GTP-U packets.

[0481] Figure 23 This is a schematic diagram illustrating the format of DL CB entity information according to one or more embodiments of this disclosure. In some cases, the format of information (such as CB entity information) included in a CB entity container for downlink packets (such as ingress packets) is as follows: Figure 23 (It is) Figure 10 As shown in the evolved version.

[0482] refer to Figure 23 The CB entity container used for downlink grouping includes the following new fields: Task Session ID, Data Session ID, and auxiliary information for the Data Session ID (such as Operation ID). Information about the task session can include the information carried in the new fields.

[0483] Similarly, the information included in the CB entity container used for uplink grouping (such as CB entity information) includes the following new fields: Task Session ID, Data Session ID, and auxiliary information corresponding to the Data Session ID (such as Operation ID). (Formatting details omitted here.) Figure 11 An evolved version.

[0484] It should be noted that there are no restrictions on the position of the new field within the CB entity container; for example, it can be located within, before, or after other fields. For instance, the new field can be located within, before, or after a fill field.

[0485] When a network entity receives a packet containing a CB entity container from a tunnel shared by a task session, the network entity can determine the data session of the task session to which the packet belongs (optionally, its QFI). The task session can be determined based on the task session ID. The data session can be determined based on the data session ID and / or auxiliary information (such as the operation ID) encapsulated in the packet (such as the packet header). QoS flows can be determined based on the QFI.

[0486] The type of the Data-TW-GW container can be indicated by a specific field value (such as the following extended header field value), for example, 1000 1100 or other reserved values.

[0487] When the extension header type is set to Data-TW-GW container (e.g., the next extension header field value is set to 10001100), the Data-TW-GW container is encapsulated in the GTP-U packet. This Data-TW-GW container extension header can be transmitted between network entities (e.g., between CB entities, and between a CB entity and a Data-TW-GW) via network interfaces. CB entities can reside in devices, RANs, CNs, and DNs. Data-TW-GWs can reside in devices, RANs, CNs, and DNs. In some cases, the Data-TW-GW can be a UPF or an evolved UPF. The Data-TW-GW container can have a variable length. Furthermore, the Data-TW-GW container includes information (control cells, data processing, and / or data forwarding indication information) to be associated with the data session of the task session and / or the inter-GW session.

[0488] One or more of the following are included in the task session container: task session ID, data session ID and corresponding auxiliary information for the data session, inter-GW session ID and corresponding auxiliary information for the inter-GW session. Based on one or more of the task session ID, data session ID and corresponding auxiliary information for the data session, and inter-GW session ID and corresponding auxiliary information for the inter-GW session, a network entity (such as Data-TW-GW) can detect and distinguish the data (inter-GW) session to which packets received from a tunnel shared by multiple task sessions belong.

[0489] The auxiliary information corresponding to the data session is used to help distinguish the data session to which packets received from / sent to the tunnel shared by the task session belong.

[0490] The auxiliary information corresponding to the inter-GW session is used to help distinguish the inter-GW session to which packets received from / sent to the tunnel shared by the task session belong.

[0491] In some cases, when the task session ID and the data (inter-GW) session ID together are sufficient to distinguish the data (inter-GW) session to which a packet received from / sent to a tunnel shared by the task sessions belongs, and when the task session ID and the data (inter-GW) session ID are encapsulated together in the packet (such as in a packet header or packet payload), it is not necessary to include auxiliary information in the packet. For example, when the value of the data (inter-GW) session ID is assigned globally unique within a task session, and when the value of the task session ID is assigned globally unique across different task sessions, the task session ID and the data (inter-GW) session ID together are sufficient to distinguish the packet.

[0492] In some cases, when the data (inter-GW) session ID alone is sufficient to distinguish the data (inter-GW) session to which a packet received from a tunnel shared by task sessions belongs, and the data (inter-GW) session ID is encapsulated in the packet (such as in the packet header or packet payload), there is no need to include auxiliary information in the packet. For example, when the data (inter-GW) session ID is assigned globally unique among the different data (inter-GW) session IDs of all data (inter-GW) sessions in all task sessions established between two network entities, the data (inter-GW) session ID alone is sufficient to distinguish packets.

[0493] In some cases, when the task session ID and the data (inter-GW) session ID together are insufficient to distinguish the data (inter-GW) session to which a packet received from / sent to a tunnel shared by the task session belongs, it is necessary to include auxiliary information in the packet header.

[0494] In some cases, when the task session ID and the data (inter-GW) session ID together are sufficient to distinguish the data (inter-GW) session to which a packet received from / sent to a tunnel shared by the task session belongs, but the task session ID or the data (inter-GW) session ID (e.g., only the task session ID or the data (inter-GW) session ID is encapsulated in the packet) is not encapsulated in the packet (such as in the packet header or packet payload), it is necessary to include auxiliary information in the packet header.

[0495] In some cases, when configuring auxiliary information, the auxiliary information alone, or the task session ID together with the auxiliary information, or the data (inter-GW) session ID together with the auxiliary information, or the task session ID, the data (inter-GW) session ID together with the auxiliary information, or the task session ID, the data (inter-GW) session ID together with the auxiliary information should be sufficient to distinguish the data (inter-GW) session to which a packet received from / sent to a tunnel shared by the task session belongs, and need to be encapsulated in that packet.

[0496] In some cases, auxiliary information may be one or more of the following: operation ID identifying the data processing operation, CBID identifying the CB, step ID identifying the process step, and task client ID identifying the task session client. Data processing may include, but is not limited to, AI training, AI inference, data preprocessing, data de-identification (data privacy protection), data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, useless data filtering, data feature engineering, data compression, data embedding, data representation learning, and data feature extraction.

[0497] In some cases, one or more of the following are configured to the network entity by a C / M plane function (such as MCF): the task session ID to be detected or encapsulated in the packet, the data session ID, and the auxiliary information corresponding to the data session, as well as the inter-GW session ID and the auxiliary information corresponding to the inter-GW session. In some cases, prior to configuration, the data (inter-GW) session ID and / or auxiliary information (e.g., to be detected by the network entity from the packet) are reported to the C / M plane function by the peer node of the network entity (such as Data-TW-GW).

[0498] The following description of the Data-TW-GW container takes the example of including the task session ID, data session ID, and auxiliary information corresponding to the data session in the group. It can be extended to other cases, such as including the task session ID, inter-GW session ID, and auxiliary information corresponding to the inter-GW session in the group, but not including the data session ID and auxiliary information corresponding to the data session in the group.

[0499] In some cases, a data (inter-GW) session includes one or more QoS flows. One or more QoS flows are transmitted over the data (inter-GW) session. The contents of the Data-TW-GW container include QFI and / or CBID. That is, information about the task session may include QFI and / or CBID. Network entities (such as CB entities, Data-TW-GWs) can use the received QFI to determine the QoS flows and QoS profiles associated with received packets in the data (inter-GW) session of the task session, and use the received CBID to determine the CB associated with GTP-U packets.

[0500] Figure 24This is a schematic diagram illustrating the format of DL GW entity information according to one or more embodiments of this disclosure. In some cases, the information (such as Data-TW-GW information) included in the Data-TW-GW container for downlink packets (such as ingress packets) is formatted as follows: Figure 23 (It is) Figure 10 As shown in the evolved version.

[0501] refer to Figure 24 The Data-TW-GW container used for downlink grouping includes the following new fields: Task Session ID, Data Session ID, and auxiliary information corresponding to the Data Session ID (such as Operation ID), as well as Inter-GW Session ID and auxiliary information corresponding to the Inter-GW Session ID (such as Operation ID). Information about the Task Session can include the information carried in the new fields.

[0502] Similarly, the information included in the Data-TW-GW container used for uplink grouping (such as Data-TW-GW information) includes the following new fields: task session ID, data session ID, and auxiliary information corresponding to the data session ID (such as operation ID), as well as inter-GW session ID and auxiliary information corresponding to the inter-GW session ID (such as operation ID). Formatting details are omitted here. Figure 11 An evolved version.

[0503] It should be noted that there are no restrictions on the position of the new field within the Data-TW-GW container; for example, it can be located within, before, or after other fields. For instance, the new field can be located within, before, or after a fill field.

[0504] When a network entity receives a packet containing a Data-TW-GW container from a tunnel shared by a task session, the network entity can determine the data (inter-GW) session (optionally, the QFI) to which the packet belongs. The task session can be determined based on the task session ID encapsulated in the packet (e.g., the packet header). The data (inter-GW) session can be determined based on the data (inter-GW) session ID and auxiliary information (e.g., the operation ID) encapsulated in the packet (e.g., the packet header). QoS flows can be determined based on the QFI.

[0505] In some cases, if the smallest granularity of traffic is a data (inter-GW) session rather than a QoS flow, the QFI is not included in the GTP-U header, for example, in data (inter-GW) session and / or auxiliary information replacement. Figure 10 and Figure 11 The QFI field is included in the header; otherwise, the QFI field is included in the GTP-U header along with the new field.

[0506] Specifically, when reusing existing GTP-U extension headers, GTP-U tunnels are configured per network entity. The tunnel is shared by multiple task sessions. PDU session containers (or other containers, such as RAN containers) are reused instead of defining new types of GTP-U extension headers. In some cases, the information carried in the PDU session container can be as follows: Figure 10 or Figure 11 As shown. Furthermore, the second type of GTP-U extension header can be called a PDU session container, RAN container, new radio (NR) RAN container, or XwRAN container, etc. It should be noted that the explanation will use the PDU session container as an example.

[0507] The characteristics and uses of PDU session containers can be followed Figure 7 , Figure 8 and Figure 9 The method for the general GTP-U extension head.

[0508] It should be noted that the format of the GTP-U extension header can be found by referring to [reference needed]. Figure 9 The aforementioned format.

[0509] When one or more of the following are included in a PDU session container: task session ID, data session ID (and / or auxiliary information), and inter-GW session ID (and / or auxiliary information), this implicitly indicates that the PDU session container is used for a task session; otherwise, the PDU session container is used for a PDU session.

[0510] In some cases, the PDU session container includes an indicator to distinguish whether the PDU session container is used for a PDU session or a network entity. For example, this indicator can be 2 bits.

[0511] In some cases, this indication can also be located outside the PDU session container. For example, the field value of the PDU session container can be extended (as shown in the following extended header field value) to distinguish whether the PDU session container is used for a PDU session or a task session. For example, 10000101 indicates that the packet is associated with a PDU session, while 1000 1011 or 1000 1100 indicates that the packet is associated with a task session. Alternatively, this indication (e.g., 2 bits) can be located in the TEID field. Furthermore, a first range of TEIDs can be reserved for PDU sessions, and a second range of TEIDs can be reserved for network entities participating in the task session (including CB entities and GW entities). The second field included in the information about the task session can be referred to as the TEID mentioned above.

[0512] In some cases, the format of information (such as PDU session information) included in the PDU session container used for downlink packets (such as ingress packets) is as follows: Figure 23 or Figure 24As shown. In other words, the information about the task session mentioned above can also be included in the PDU session container.

[0513] Similarly, the PDU session information included in the PDU session container used for uplink packets also includes a new field, which is omitted here. Figure 11 The corresponding evolved version.

[0514] It should be noted that there are no restrictions on the position of the new field within the PDU session container; for example, it can be located within, before, or after other fields. For instance, the new field can be located within, before, or after a fill field.

[0515] When a network entity receives a packet from a tunnel that includes a new field (optionally including QFI, for example, if the data (inter-GW) session includes one or more QoS flows), the network entity can determine the task session, or the data (inter-GW) session of the task session to which the packet belongs (optionally determining its QFI). The task session can be determined based on the task session ID encapsulated in the packet (e.g., packet header). The data session can be determined based on the data session ID and / or auxiliary information (e.g., operation ID) encapsulated in the packet (e.g., packet header). The inter-GW session can be determined based on the inter-GW session ID and / or auxiliary information (e.g., operation ID) encapsulated in the packet (e.g., packet header). QoS flows can be determined based on the QFI.

[0516] The above description does not limit the location of the new field in the GTP-U packet. In some cases, the new field (such as data session ID, inter-GW session ID, auxiliary information) may be located in other locations in the GTP-U header, for example, in the TEID.

[0517] In some cases, a range of TEID values ​​can be reserved for data sessions.

[0518] In some cases, a range of TEID values ​​can be reserved for inter-GW sessions.

[0519] In some cases, a range of TEID values ​​can be reserved for the task session.

[0520] In some cases, neither the "CB entity container" nor the "Data-TW-GW container" type is defined. For example, a range of TEID values ​​can be reserved for CB entities or Data-TW-GW, allowing network entities to determine whether a GTP-U packet belongs to a CB entity or Data-TW-GW and not to other nodes (such as RAN nodes).

[0521] The following will describe embodiments of products related to the communication method.

[0522] Figure 25This is a structural diagram of a communication device according to one or more embodiments of the present disclosure. The communication device may be the first network function or the second network function mentioned above. Figure 25 As shown, the device includes at least one processor 2502, an interface 2504 for communicating with other devices, and a memory 2506. The memory 2506 may store computer-executable instructions. The processor 2502 executes the computer-executable instructions stored in the memory 2506, enabling the device to perform any of the aforementioned communication methods. It should be noted that the memory 2506 may or may not be included in the device depending on actual needs.

[0523] One embodiment of this disclosure provides a communication device, which may include:

[0524] The receiving module is used to receive packets;

[0525] The transmitting module is used to transmit GTP-U packets generated based on the packet and General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U). The GTP-U packets include information about the task session, which is used to provide task services to task clients. The task service is a service used for both packet data unit (PDU) connection and data processing.

[0526] One embodiment of this disclosure provides a communication device, which may include:

[0527] The receiving module is used to receive General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U) packets. GTP-U packets are packets based on the GTP-U protocol and include information about the mission session. The mission session is used to provide mission services to mission clients. The mission service is a service that is used for both packet data unit (PDU) connection and data processing.

[0528] The determination module is used to determine the task session to which the GTP-U packet belongs based on information about the task session.

[0529] One embodiment of this disclosure provides an apparatus including processing circuitry for performing any of the above-described communication methods.

[0530] It should be noted that the apparatus described in this disclosure can also be implemented as a device, or one or more components included in a device, such as a processor or chip. The device can be a user equipment, terminal, network device, network function, network node, or other network element, and this disclosure does not impose any limitations on it.

[0531] One embodiment of this disclosure provides a chip including an input / output (I / O) interface and a processor, wherein the processor is used to call and run a computer program stored in a memory to enable a device equipped with the chip to perform any of the above-described communication methods.

[0532] One embodiment of this disclosure provides an apparatus including one or more processors, wherein the one or more processors are configured to execute instructions stored in a memory, and when the instructions are executed by the one or more processors, to perform any of the above-described communication methods.

[0533] It should be understood that the processor described above can be an integrated circuit chip with signal processing capabilities. In one implementation, the various steps of the above method embodiments can be completed by hardware integrated logic circuits in the processor or by software instructions. The processor described above can be a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), a system-on-chip (SoC), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The processor described above can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this disclosure. The general-purpose processor described above can be a microprocessor, or the processor described above can be any conventional processor, etc. The various steps of the various methods disclosed in the embodiments of this disclosure can be directly executed and completed by a hardware decoding processor, or executed and completed by a combination of hardware and software modules in the decoding processor. The software modules can be located in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. The storage medium is located in memory, and the processor reads the information in the memory and combines it with the hardware in the processor to complete the various steps of the above methods.

[0534] It is understood that the memory in the embodiments of this disclosure can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM) used as an external cache. As an example, rather than now, many forms of RAM can be used, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0535] It should be noted that the memory in the systems and methods described in this specification includes, but is not limited to, these memories and any other suitable types of memory.

[0536] One embodiment of this disclosure provides a communication system including apparatus for performing any of the above-described communication methods.

[0537] One embodiment of this disclosure provides a non-transitory computer-readable medium, wherein the non-transitory computer-readable medium carries program code that, when executed by a processor, performs any of the above-described communication methods.

[0538] Optionally, the storage medium may specifically be a memory.

[0539] One embodiment of this disclosure provides a computer program product, wherein the computer program product includes computer code for executing any of the above-described communication methods.

[0540] It should be noted that when the above request or response includes multiple different contents for indicating multiple different information, the multiple contents can be indicated separately in multiple request / response messages, or they can be indicated together in a single request / response message.

[0541] It should be noted that the network elements mentioned in this disclosure are all logical network elements. They can be implemented as independent devices or as chips or modules that can be integrated into a device.

[0542] Although this disclosure describes methods and processes by way of steps performed in a certain order, one or more steps in the methods and processes may be omitted or modified as appropriate. Where appropriate, one or more steps may be performed in an order other than that described.

[0543] It is important to note that the expression "at least one of A or B" used in this document is interchangeable with the expression "A and / or B". This expression refers to a list in which A or B or A and B can be selected. Similarly, the expression "at least one of A, B, or C" used in this document is interchangeable with "A and / or B and / or C" or "A, B, and / or C". This expression refers to a list in which the following can be selected: A or B or C, or A and B, or A and C, or B and C, or all of A, B, and C. The same principle applies to longer lists with the same format.

[0544] While this disclosure describes at least part of the methodological aspects, those skilled in the art will understand that this disclosure also relates to various components, whether hardware components, software, or any combination thereof, for performing at least some aspects and features of the methods. Accordingly, the technical solutions of this disclosure can be embodied in the form of a software product. Suitable software products can be stored in pre-recorded storage devices or other similar non-volatile or non-transitory computer-readable media, including DVDs, CD-ROMs, USB flash drives, removable hard drives, or other storage media. The software product includes instructions tangibly stored thereon that cause a processing device (e.g., a personal computer, server, or network device) to perform examples of the methods disclosed herein. Machine-executable instructions can be in the form of sequences of code, configuration information, or other data that, when executed, cause a machine (e.g., a processor or other processing device) to perform the steps in the methods according to the examples of this disclosure.

[0545] This disclosure may be implemented in other specific forms without departing from the subject matter of the claims. The exemplary embodiments described are illustrative in all respects and not restrictive. Features selected from one or more of the foregoing embodiments may be combined to create alternative embodiments not explicitly described, and features suitable for such combinations will be understood within the scope of this disclosure.

[0546] All values ​​and subranges within the scope of the disclosure are also disclosed. Furthermore, while the systems, devices, and processes disclosed and shown herein may include a specific number of elements / components, the systems, devices, and components may be modified to include more or fewer such elements / components. For example, while any element / component disclosed may be referenced as a single quantity, embodiments disclosed herein may be modified to include multiple such elements / components. The subject matter described herein is intended to cover and encompass all appropriate technical changes.

[0547] Although embodiments have been described above with reference to the accompanying drawings, those skilled in the art will understand that variations and modifications can be made without departing from the scope defined by the appended claims.

[0548] Please note that different examples can be implemented separately or in combination. While combinations of features are shown in the illustrated embodiments, not all features need to be combined to achieve the advantages of the various examples of this disclosure. In other words, a system or method designed according to one embodiment of this disclosure does not necessarily include any of the features shown in the drawings or in all portions schematically illustrated in the drawings. Furthermore, selected features of one exemplary embodiment may be combined with selected features of other exemplary embodiments.

[0549] Although this disclosure has been described with reference to illustrative embodiments, this specification is not intended to be limiting. Referring to this specification, those skilled in the art will clearly understand various modifications and combinations of the illustrative embodiments and other examples of this disclosure. Therefore, the appended claims are intended to cover any such modifications or embodiments.

Claims

1. A communication method characterized by comprising: include: Receive packets; Send GTP-U packets generated based on the aforementioned packets and the General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) protocol, wherein the GTP-U packets include information about a mission session used to provide mission services to mission clients, the mission services being services that simultaneously support packet data unit (PDU) connectivity and data processing.

2. A communication method characterized by comprising: include: Receive General Packet Radio Service (GPRS) Tunneling Protocol for User Plane (GTP-U) packets, wherein the GTP-U packets are packets based on the GTP-U protocol, and the GTP-U packets include information about a task session, the task session being used to provide task services to task clients, the task services being services that are used for both packet data unit (PDU) connectivity and data processing; Based on the information about the task session, determine the task session to which the GTP-U packet belongs.

3. The method according to claim 1 or 2, characterized in that, The task session includes one or more data sessions, each data session including an association terminating at a computing block (CB) entity, the CB entity executing at least one CB of a task, the task including one or more CBs, each CB corresponding to a computing step that implements the task service.

4. The method of claim 3, wherein, The data processing includes the at least one CB that performs the task.

5. The method according to claim 3 or 4, characterized in that, The CB entity is deployed in one of the following: a device, a radio access network (RAN), a core network (CN), and a data network (DN).

6. The method according to any one of claims 3 to 5, characterized in that, The computational steps for implementing the task service include one or more of the following: artificial intelligence (AI) training, AI inference, data preprocessing, data privacy protection, data cleaning, data collection, data analysis, sensing, data purification, data management, data normalization, data aggregation, data segmentation, useless data filtering, data formatting, data adaptation, data feature engineering, data compression, data embedding, data representation learning, or data feature extraction.

7. The method according to any one of claims 3 to 6, characterized in that, The task session also includes one or more gateway (GW) sessions. Each GW session includes the association between two GW entities, and each GW entity is used to support communication between CB entities.

8. The method according to any one of claims 3 to 7, characterized in that, The information about the mission session is included in the header of the GTP-U packet or in the payload of the GTP-U packet.

9. The method according to any one of claims 3 to 8, characterized in that, The GTP-U packets are transmitted through a GTP-U tunnel, which is dedicated to data sessions.

10. The method according to claim 9, characterized in that, The information about the task session includes a Quality of Service (QoS) flow identifier (QFI) and / or a computing block ID (CBID), wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session, and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

11. The method according to claim 10, characterized in that, The information about the task session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and the QFI and / or the CBID are included in the GTP-U extension header.

12. The method according to claim 11, characterized in that, The GTP-U extension header is a first type of GTP-U extension header, which is a data session container.

13. The method according to claim 12, characterized in that, The information about the task session includes a first field, which is indicated by the first type of GTP-U extension header.

14. The method according to claim 13, characterized in that, The value of the first field is 1000 1000.

15. The method according to claim 13 or 14, characterized in that, The first field indicates that the GTP-U tunnel is dedicated to the data session by indicating the first type of GTP-U extension header.

16. The method according to claim 11, characterized in that, The GTP-U extension header is a type II GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the type II GTP-U extension header is used for a data session.

17. The method according to claim 16, characterized in that, The instruction is included in the second type of GTP-U extension header, or The information about the task session includes a second field, and the indication is included in the second field.

18. The method according to claim 17, characterized in that, The indication is 2 bits, and the value of the 2 bits indicates that the second type of GTP-U extension header is used for a PDU session or a data session.

19. The method according to claim 16, characterized in that, The information about the task session includes a second field, and the indication is indicated by the range of values ​​for the second field.

20. The method according to any one of claims 3 to 8, characterized in that, The GTP-U packets are transmitted through a GTP-U tunnel, which is dedicated to inter-GW sessions.

21. The method according to claim 20, characterized in that, The information about the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the inter-GW session, and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

22. The method according to claim 21, characterized in that, The information about the task session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and the QFI and / or the CBID are included in the GTP-U extension header.

23. The method according to claim 22, characterized in that, The GTP-U extension header is a first type of GTP-U extension header, and the first type of GTP-U header is a GW inter-session container.

24. The method according to claim 23, characterized in that, The information about the task session includes a first field, which is indicated by the first type of GTP-U extension header.

25. The method according to claim 24, characterized in that, The value of the first field is 1000 1001.

26. The method according to claim 24 or 25, characterized in that, The first field indicates that the GTP-U tunnel is dedicated to the inter-GW session by indicating the first type of GTP-U extension header.

27. The method according to claim 22, characterized in that, The GTP-U extension header is a type II GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the type II GTP-U extension header is used for inter-GW sessions.

28. The method according to claim 27, characterized in that, The instruction is included in the second type of GTP-U extension header, or The information about the task session includes a second field, and the indication is included in the second field.

29. The method according to claim 28, characterized in that, The indication is 2 bits, and the value of the 2 bits indicates that the second type of GTP-U extension header is used for PDU sessions or GW sessions.

30. The method according to claim 27, characterized in that, The information about the task session includes a second field, and the indication is indicated by the range of values ​​for the second field.

31. The method according to any one of claims 3 to 8, characterized in that, The GTP-U packets are transmitted through a GTP-U tunnel, which is dedicated to the task session and shared by one or more data sessions and / or one or more inter-GW sessions of the task session.

32. The method according to claim 31, characterized in that, The information about the task session includes one or both of the following: a data session ID and auxiliary information. The data session ID is used to identify the data session included in the one or more data sessions, and the auxiliary information is used to help distinguish the data session or distinguish the CB.

33. The method according to claim 32, characterized in that, The information regarding the task session also includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session; and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

34. The method according to claim 31, characterized in that, The information about the task session includes one or both of the following: GW Inter-session ID and auxiliary information. The GW Inter-session ID is used to identify the GW Inter-session, and the auxiliary information is used to help distinguish between GW Inter-sessions or CBs.

35. The method according to claim 34, characterized in that, The information regarding the task session also includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the inter-GW session; and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

36. The method according to claim 31, characterized in that, The information about the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows in the task session; and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

37. The method according to any one of claims 32 to 36, characterized in that, The information about the task session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and one or more of the following are included in the GTP-U extension header: the data session ID, the inter-GW session ID, the auxiliary information, the QFI, or the CBID.

38. The method according to claim 37, characterized in that, The GTP-U extension header is a first type of GTP-U extension header, and the first type of GTP-U extension header is a task session container.

39. The method according to claim 38, characterized in that, The information about the task session includes a first field, which is indicated by the first type of GTP-U extension header.

40. The method according to claim 39, characterized in that, The value of the first field is 1000 1010.

41. The method according to claim 39 or 40, characterized in that, The first field indicates that the GTP-U tunnel is dedicated to the task session by indicating the first type of GTP-U extension header.

42. The method according to claim 37, characterized in that, The GTP-U extension header is a second type of GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the second type of GTP-U extension header is used for a task session.

43. The method according to claim 42, characterized in that, The instruction is included in the second type of GTP-U extension header, or The information about the task session includes a second field, and the indication is included in the second field.

44. The method according to claim 43, characterized in that, The indication is 2 bits, and the value of the 2 bits indicates that the second type of GTP-U extension header is used for a PDU session or a task session.

45. The method according to claim 42, characterized in that, The information about the task session includes a second field, and the indication is indicated by the range of values ​​for the second field.

46. ​​The method according to any one of claims 3 to 8, characterized in that, The GTP-U packets are transmitted through a GTP-U tunnel dedicated to the CB entity and shared by one or more task sessions of the CB entity, the one or more task sessions including the task session.

47. The method according to claim 46, characterized in that, The information about the task session includes one or more of the following: task session ID, data session ID, or auxiliary information; the task session ID is used to identify the first task session, the data session ID is used to identify the data session included in the first task session, and the auxiliary information is used to assist in distinguishing the data session or distinguishing the CB.

48. The method according to claim 47, characterized in that, The information regarding the task session also includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session; and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

49. The method according to claim 46, characterized in that, The information in the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows of the one or more task sessions of the CB entity, and the CBID indicates a first CB associated with the GTP-U packet, the data session corresponding to the one or more CBs including the first CB.

50. The method according to any one of claims 47 to 49, characterized in that, The information about the task session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and one or more of the following are included in the GTP-U extension header: the task session ID, the data session ID, the auxiliary information, the QFI, or the CBID.

51. The method according to claim 50, characterized in that, The GTP-U extension header is a first type of GTP-U extension header, and the first type of GTP-U extension header is a CB entity container.

52. The method according to claim 51, characterized in that, The information about the task session includes a first field, which is indicated by the first type of GTP-U extension header.

53. The method according to claim 52, characterized in that, The value of the first field is 1000 1011.

54. The method according to claim 52 or 53, characterized in that, The first field indicates that the GTP-U tunnel is dedicated to the CB entity by indicating the first type of GTP-U extension header.

55. The method according to claim 50, characterized in that, The GTP-U extension header is a type II GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the type II GTP-U extension header is used for a CB entity.

56. The method according to claim 55, characterized in that, The instruction is included in the second type of GTP-U extension header, or The information about the task session includes a second field, and the indication is included in the second field.

57. The method according to claim 56, characterized in that, The indication is 2 bits, and the value of the 2 bits indicates that the second type of GTP-U extension header is used for a PDU session or CB entity.

58. The method according to claim 55, characterized in that, The information about the task session includes a second field, and the indication is indicated by the range of values ​​for the second field.

59. The method according to any one of claims 3 to 8, characterized in that, The GTP-U packets are transmitted through a GTP-U tunnel dedicated to the GW entity and shared by one or more task sessions of the GW entity, the one or more task sessions including the task session.

60. The method according to claim 59, characterized in that, The information about the task session includes one or more of the following: task session ID, data session ID, or first auxiliary information; or includes one or more of the following: task session ID, inter-GW session ID, or second auxiliary information. The task session ID is used to identify the first task session, the data session ID is used to identify the data session included in the first task session, and the first auxiliary information is used to assist in distinguishing the data session or distinguishing CB; or The task session ID is used to identify the first task session, the inter-GW session ID is used to identify the inter-GW session included in the first task session, and the second auxiliary information is used to assist in distinguishing the inter-GW session or distinguishing the CB.

61. The method according to claim 60, characterized in that, The information regarding the task session also includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows included in the data session or the inter-GW session; and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

62. The method according to claim 59, characterized in that, The information about the task session includes a QFI and / or a CBID, wherein the QFI indicates a QoS flow associated with the GTP-U packet, the QoS flow being one of one or more QoS flows of the one or more task sessions of the GW entity, and the CBID indicates a first CB associated with the GTP-U packet, a data session or an inter-GW session corresponding to the one or more CBs including the first CB.

63. The method according to any one of claims 60 to 62, characterized in that, The information about the task session is included in the packet header of the GTP-U packet, which includes a GTP-U extension header, and one or more of the following are included in the GTP-U extension header: the task session ID, the data session ID, the inter-GW session ID, the first auxiliary information, the second auxiliary information, the QFI, or the CBID.

64. The method according to claim 63, characterized in that, The GTP-U extension header is a first type of GTP-U extension header, and the first type of GTP-U extension header is a GW entity container.

65. The method according to claim 64, characterized in that, The information about the task session includes a first field, which is indicated by the first type of GTP-U extension header.

66. The method according to claim 65, characterized in that, The value of the first field is 1000 1100.

67. The method according to claim 65 or 66, characterized in that, The first field indicates that the GTP-U tunnel is dedicated to the GW entity by indicating the first type of GTP-U extension header.

68. The method according to claim 63, characterized in that, The GTP-U extension header is a type II GTP-U extension header, and the GTP-U packet includes an indication to indicate whether the type II GTP-U extension header is used for a GW entity.

69. The method according to claim 68, characterized in that, The instruction is included in the second type of GTP-U extension header, or The information about the task session includes a second field, and the indication is included in the second field.

70. The method according to claim 69, characterized in that, The indication is 2 bits, and the value of the 2 bits indicates that the second type of GTP-U extension header is used for a PDU session or GW entity.

71. The method according to claim 68, characterized in that, The information about the task session includes a second field, and the indication is indicated by the range of values ​​for the second field.

72. The method according to any one of claims 17 to 19, 28 to 30, 43 to 45, 56 to 58, and 69 to 71, characterized in that, The second field is the tunnel endpoint identifier (TEID).

73. The method according to any one of claims 32 to 35, 47, 48, 60 and 61, characterized in that, The auxiliary information, the first auxiliary information, or the second auxiliary information includes one or more of the following: an operation ID that identifies a data processing operation, a CB ID that identifies a CB, a step ID that identifies a process step, or a task client ID that identifies a task session client.

74. The method according to any one of claims 16 to 19, 27 to 30, 42 to 45, 55 to 58, and 68 to 71, characterized in that, The second type of GTP-U extension header includes one or more of the following: PDU session container, radioaccess network (RAN) container, new radio (NR) RAN container, or Xw RAN container.

75. The method according to any one of claims 1 to 74, characterized in that, The task service is simplified to support only PDU connections.

76. The method according to claim 75, characterized in that, The task session is simplified to the PDU session used for the PDU connection.

77. The method according to claim 76, characterized in that, There are no CB entities participating in the task session, or all CB entities participating in the task session are pseudo-CB entities.

78. The method according to claim 77, characterized in that, There is no data session belonging to the task session, or all data sessions belonging to the task session are pseudo-data sessions.

79. A communication device, characterized in that, include: The receiving module is used to receive packets; The transmitting module is used to transmit GTP-U packets generated based on the packets and the General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U). The GTP-U packets include information about a task session, which is used to provide task services to task clients. The task services are services that are used for both packet data unit (PDU) connection and data processing.

80. A communication device, characterized in that, include: The receiving module is used to receive General Packet Radio Service (GPRS) user plane tunneling protocol (GTP-U) packets, wherein the GTP-U packets are packets based on the GTP-U protocol, and the GTP-U packets include information about a task session, the task session being used to provide task services to task clients, the task services being services that are used for both packet data unit (PDU) connection and data processing; The determination module is used to determine the task session to which the GTP-U packet belongs based on the information about the task session.

81. An apparatus, characterized in that, Includes processing circuitry for performing the method according to any one of claims 1 to 78.

82. A chip, characterized in that, It includes an input / output (I / O) interface and a processor, wherein the processor is used to call and run a computer program stored in a memory to enable a device on which the chip is mounted to perform the method according to any one of claims 1 to 78.

83. An apparatus, characterized in that, include: One or more processors, wherein The one or more processors are configured to execute instructions stored in memory, and when the instructions are executed by the one or more processors, to perform the method according to any one of claims 1 to 78.

84. An apparatus, characterized in that, include: One or more processors, wherein The one or more processors are configured to execute instructions stored in memory, and when the instructions are executed by the one or more processors, to perform the method according to any one of claims 2 to 78.

85. A communication system, characterized in that, include: The apparatus according to claim 83 and / or the apparatus according to claim 84.

86. A non-transitory computer-readable medium, characterized in that, Carrying program code, when the program code is executed by a processor, the method according to any one of claims 1 to 78 is performed.

87. A computer program product, characterized in that, Includes program code for performing the method according to any one of claims 1 to 78.

Images