Method and device for establishing task tunnel

Abstract

A method and apparatus for establishing a task tunnel, the method comprising: a TFF receives a first request message from a TCF, the first request message being used for requesting the TFF to establish a tunnel of a first task; the TFF sends a first response message responding to the first request message to the TCF, wherein the first response message comprises tunnel information of the TFF associated with the first task; and the TFF receives tunnel information of the access network equipment associated with the first task from the TCF. Through the design, a tunnel for the task can be established between the access network equipment and the TFF, at least one terminal and / or at least one TPF participating in the task can share the task tunnel and interact task data, and the complexity of the access network equipment and the TPF is simplified.

Description

A method and device for establishing a task tunnel Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a method and device for establishing a task tunnel. Background Art

[0002] In the future sixth generation (6 th In the 6G generation (6G) communication system, in order to support new services, the network needs to efficiently and collaboratively schedule various heterogeneous resources, such as computing power, data or models. In the 6G communication system, the process of collaboratively completing a specific goal through multi-dimensional resources (such as computing power, data, models, etc.) is called a "task". In order to make the execution of tasks controllable in the network, new logical functions are required, such as task anchors (TA) and task executors (TE). TA is responsible for the life cycle management of tasks, including task deployment, startup, deletion, modification, monitoring, etc. TE is responsible for the specific execution of tasks and performs data interaction in business logic. TA can receive external task requests and deploy tasks to one or more TEs for execution. In the 6G communication system, a new task control function (TCF) is added to the core network to provide TA functions, and a new task process function (TPF) is added to provide TE functions. In addition, the terminal can provide TE functions.

[0003] The TCF deploys a task to at least one terminal and / or at least one TPF. During task execution, different task executors need to exchange task data. Establishing a tunnel specific to a task to enable this data exchange is a technical challenge that needs to be addressed.

[0004] Summary of the Invention

[0005] The present application provides a method and apparatus for establishing a task tunnel, which establishes a tunnel for a first task between an access network device and a TFF, and utilizes the tunnel to route and forward task data of different task execution bodies.

[0006] In a first aspect, a method for establishing a task tunnel is provided, wherein the execution entity is a TFF, or a module (such as a chip or circuit) in the TFF, including: receiving a first request message from a task control function (TCF), the first request message being used to request a task forwarding function (TFF) to establish a tunnel for a first task, where the first task is completed through the collaboration of multi-dimensional resources; sending a first response message to the TCF in response to the first request message, the first response message including tunnel information of the TFF associated with the first task; and receiving tunnel information of an access network device associated with the first task from the TCF. Optionally, the tunnel of the first task includes a tunnel between the access network device associated with the first task and the TFF associated with the first task.

[0007] Through the above design, a tunnel for the first task can be established between the access network device and the TCF. At least one terminal and / or at least one TPF participating in the first task can use this tunnel to transmit task data. Furthermore, for uplink task data sent by the terminal to the TPF, the access network device only needs to forward it to the TFF. The access network device does not need to know which TPF the data is being sent to, thus simplifying the complexity of the access network device. For downlink task data sent by the TPF to the access network device, the TPF only needs to forward it to the TFF. It does not need to know the location of the terminal, thus simplifying the complexity of the TPF.

[0008] In one design, the first request message includes: an identifier of the first task and information about a task processing function (TPF) associated with the first task. Furthermore, the first request message also includes at least one of the following: information about a terminal associated with the first task, a packet detection rule associated with the first task, a packet forwarding rule associated with the first task, or an identifier of the TCF.

[0009] Optionally, the first request message may further include: a session identifier of the first task.

[0010] With the above design, the tunnel for the first task can be established at the task granularity. Alternatively, the tunnel for the first task can be established at the session granularity. When establishing the tunnel for the first task at the session granularity, the first request message may include, in addition to the above content, the session identifier of the first task. When establishing the tunnel for the first task at the session granularity, a finer-grained tunnel can be established.

[0011] In one implementation, upon receiving the first request message, TFF may establish a tunnel context for the first task. TFF then routes and forwards the task data for the first task based on the tunnel context. The content included in the tunnel context for the first task is similar to the content included in the first request message, and the two can refer to each other.

[0012] In one design, the tunnel information of the TFF includes: an identifier of the first task, an Internet Protocol (IP) address of the TFF, and a tunnel endpoint identifier (TEID) of the TFF. The tunnel information of the access network device includes: an identifier of the first task, an IP address of the access network device, and a TEID of the access network device. Optionally, when establishing the tunnel of the first task at the granularity of a session, the tunnel information of the TFF and / or the tunnel information of the access network device also includes: a session identifier of the first task.

[0013] Through the above design, since TFF may participate in the routing and forwarding of multiple tasks, the IP address of TFF cannot uniquely identify a task. In an embodiment of the present application, when TFF receives the first request message, it can assign a unique identifier to the first task on the TFF side, which can be called the TEID of TFF. Similarly, the access network device assigns a unique identifier to the first task on the access network device side, which can be called the TEID of the access network device. For the access network device to obtain the TEID of TFF, TFF can obtain the TEID of the access network device. At this time, it is considered that a tunnel for the first task is established between the access network device and TFF, thereby realizing the configuration of a dedicated tunnel for the task data of the first task.

[0014] In one design, it also includes: receiving a second request message from TCF, the second request message is used to request an update of the terminal and / or TPF associated with the first task; updating the tunnel context of the first task according to the second request message, the tunnel context of the first task is established by TFF when receiving the first request message; and sending a second response message to TCF in response to the second request message.

[0015] Through the above design, TFF can dynamically update the tunnel context of the first task according to the adjustment of the executor topology, ensuring that the access network equipment and TFF can correctly route and forward the task data of different executors.

[0016] In one design, the second request message includes: the identifier of the first task, the update reason, and information about the terminal to be updated and / or TPF information. Optionally, the second request message also includes: the session identifier of the first task and / or the identifier of the TCF. The second response message includes the identifier of the first task. Optionally, the second response message also includes: the session identifier of the first task and / or the identifier of the TCF.

[0017] The second aspect is the TCF end corresponding to the first aspect. The beneficial effects can be found in the description of the first aspect. A method for establishing a task tunnel is provided, the execution subject of which is TCF, or a module in TCF (for example, a chip or circuit, etc.), including: sending a first request message to the task forwarding function TFF, the first request message is used to request TFF to establish a tunnel for the first task, and the first task is completed through the collaboration of multi-dimensional resources; receiving a first response message from TFF in response to the first request message, the first response message includes tunnel information of TFF associated with the first task; sending tunnel information of TFF and information of the terminal associated with the first task to the access network device; receiving tunnel information of the access network device associated with the first task from the access network device; sending tunnel information of the access network device to TFF. Optionally, the tunnel of the first task includes: a tunnel between the access network device associated with the first task and the TFF associated with the first task.

[0018] In one design, the first request message includes: an identifier of the first task and information about a task processing function (TPF) associated with the first task. Optionally, the first request message also includes at least one of the following: information about a terminal associated with the first task, a packet detection rule associated with the first task, a packet forwarding rule associated with the first task, or an identifier of a task control function (TCF).

[0019] Optionally, when the tunnel of the first task is established at the granularity of a session, the first request message further includes: a session identifier of the first task.

[0020] In one design, the tunnel information of the TFF includes: an identifier of the first task, an Internet Protocol (IP) address of the TFF, and a tunnel endpoint identifier (TEID) of the TFF. The tunnel information of the access network device includes: an identifier of the first task, an IP address of the access network device, and a TEID of the access network device. Optionally, when establishing the tunnel of the first task at the granularity of a session, the tunnel information of the TFF and / or the tunnel information of the access network device also includes: a session identifier of the first task.

[0021] In one design, it also includes: TCF sends a second request message to TFF, where the second request message is used to request updating the terminal and / or TPF associated with the first task; and TCF receives a second response message from TFF in response to the second request message.

[0022] In one design, the second request message includes: the identifier of the first task, the update reason, and information about the terminal to be updated and / or TPF information. Optionally, the second request message also includes: the session identifier of the first task and / or the identifier of the TCF. The second response message includes the identifier of the first task. Optionally, the second response message also includes: the session identifier of the first task and / or the identifier of the TCF.

[0023] In one design, when the second request message is used to request an update of the terminal associated with the first task, it also includes: TCF sends a third request message to the access network device, and the third request message is used to request an update of the terminal associated with the first task; TCF receives a third response message from the access network device in response to the third request message.

[0024] In one design, the third request message includes: an identifier of the first task, an update reason, and information about the terminal to be updated. Optionally, the third request message also includes an identifier of the TCF and / or a session identifier of the first task. The third response message includes an identifier of the first task. Optionally, the third response message also includes a session identifier of the first task.

[0025] The third aspect is the access network device side of the first aspect. The beneficial effects can be found in the description of the first aspect. A method for establishing a task tunnel is provided, the execution subject of which is the access network device, or a module (chip or circuit, etc.) in the access network device, including: receiving tunnel information of the task forwarding function TFF associated with the first task and information of the terminal associated with the first task from the task control function TCF, where the first task is completed through the collaboration of multi-dimensional resources; sending the tunnel information of the access network device to the TCF, and the access network device is associated with the tunnel of the first task. Optionally, the tunnel of the first task includes: a tunnel between the access network device associated with the first task and the TFF associated with the first task.

[0026] In one design, the tunnel information of the TFF includes: an identifier of the first task, an Internet Protocol (IP) address of the TFF, and a tunnel endpoint identifier (TEID) of the TFF. The tunnel information of the access network device includes: an identifier of the first task, an IP address of the access network device, and a TEID of the access network device. Optionally, when establishing the tunnel of the first task at the granularity of a session, the tunnel information of the TFF and / or the tunnel information of the access network device also includes: a session identifier of the first task.

[0027] In one design, the method further includes: determining a data radio bearer (DRB) associated with the first task; and sending DRB information to a terminal associated with the first task.

[0028] In one design, it also includes: receiving a third request message from TCF, the third request message is used to request an update of the terminal associated with the first task; updating the context of the tunnel of the first task according to the third request message, the context of the tunnel of the first task is established by the access network device when receiving the tunnel information of the TFF associated with the first task and the information of the terminal associated with the first task; sending a third response message to TCF in response to the third request message.

[0029] In one design, the third request message includes: an identifier of the first task, an update reason, and information about the terminal to be updated. Optionally, the third request message also includes an identifier of the TCF and / or a session identifier of the first task. The third response message includes an identifier of the first task. Optionally, the third response message also includes a session identifier of the first task.

[0030] In a fourth aspect, a device is provided that can implement the method of the first aspect. For example, the device includes means for executing the corresponding method of the first aspect. The device can be implemented through hardware, software, or hardware executing the corresponding software implementation.

[0031] In one design, the apparatus includes means for performing the first aspect.

[0032] In one design, the apparatus includes a processor and a memory, the processor being configured to execute a computer program or instructions stored in the memory, so that the apparatus implements the method of the first aspect.

[0033] In one design, the device includes a processor and an interface circuit, the interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device, and the processor is used to implement the method in the first aspect through logic circuits or executing code instructions.

[0034] In a fifth aspect, a device is provided that can implement the method of the second aspect. For example, the device includes means for executing the corresponding method of the second aspect. The device can be implemented by hardware, software, or by hardware executing the corresponding software implementation.

[0035] In one design, the apparatus includes means for performing the second aspect.

[0036] In one design, the apparatus includes a processor and a memory, the processor being configured to execute a computer program or instructions stored in the memory, so that the apparatus implements the method of the second aspect.

[0037] In one design, the device includes a processor and an interface circuit, the interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device, and the processor is used to implement the method in the second aspect through logic circuits or executing code instructions.

[0038] In a sixth aspect, a device is provided that can implement the method of the third aspect. For example, the device includes means for executing the corresponding method of the third aspect. The device can be implemented through hardware, software, or hardware executing the corresponding software implementation.

[0039] In one design, the apparatus includes means for performing the third aspect.

[0040] In one design, the apparatus includes a processor and a memory, the processor being configured to execute a computer program or instructions stored in the memory, so that the apparatus implements the method of the third aspect.

[0041] In one design, the device includes a processor and an interface circuit, the interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device, and the processor is used to implement the method in the third aspect through logic circuits or executing code instructions.

[0042] In a seventh aspect, a computer-readable storage medium is provided, storing a computer program or instruction. When the computer program or instruction is executed on a computer, the computer implements the method of any one of the first to third aspects.

[0043] In an eighth aspect, a computer program product is provided, comprising a computer program or instructions, which enables the method of any one of the first to third aspects to be executed when the computer program or instructions are executed by a computer.

[0044] In the ninth aspect, a chip is provided, comprising a processor coupled to a memory for executing a computer program or instruction stored in the memory, so that the chip implements the method of any one of the first to third aspects.

[0045] In the tenth aspect, a communication system is provided, comprising: a first communication device, a second communication device and a third communication device; wherein the first communication device is used to implement the method of the first aspect, the second communication device is used to implement the method of the second aspect, and the third communication device is used to implement the method of the third aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] FIG1 is a schematic diagram of the architecture of a communication system provided in an embodiment of the present application;

[0047] FIG2 is a schematic diagram of a process provided in an embodiment of the present application;

[0048] FIG3 is another schematic diagram of the process provided in an embodiment of the present application;

[0049] FIG4 is a schematic diagram of a structure provided in an embodiment of the present application;

[0050] FIG5 is another structural diagram provided in an embodiment of the present application. DETAILED DESCRIPTION

[0051] In order to make the purpose, technical solutions and advantages of this application more clear, the application will be further described in detail below with reference to the accompanying drawings. The specific operation methods and functional descriptions in the method embodiments can also be applied to the device embodiments or system embodiments.

[0052] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the previous and next related objects are in an "or" relationship; in the formulas of this application, the character " / " indicates that the previous and next related objects are in a "division" relationship.

[0053] The various numbers used in the embodiments of this application are for ease of description and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above processes does not necessarily indicate the order in which they are executed. The order in which the processes are executed should be determined by their functions and internal logic.

[0054] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0055] FIG1 shows a possible, non-limiting system schematic diagram. As shown in FIG1 , a communication system 10 includes a radio access network (RAN) 100 and a core network (CN) 200 .

[0056] RAN 100 includes at least one RAN node. A terminal can connect to a RAN node wirelessly. The RAN node is connected to core network 200 wirelessly or via a wired connection. The core network devices in core network 200 and the RAN nodes in RAN 100 can be separate physical devices, or they can be a single physical device that integrates the logical functions of the core network device and the logical functions of the radio access network.

[0057] RAN100 may be a cellular system related to the 3rd Generation Partnership Project (3GPP). For example, a 4th generation (4G) mobile communication system, a 5th generation (5G) mobile communication system, or a future-oriented evolution system, for example, a 6th generation (6G) mobile communication system. RAN100 may also be an open access network (open RAN, O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. RAN100 may also be a communication system that integrates two or more of the above systems.

[0058] RAN nodes, also known as access network equipment, RAN entities, or access nodes, form part of a communication system and facilitate wireless access for terminals. In the subsequent description of this application, "access network equipment" will be used unless otherwise specified. RAN nodes and terminals are sometimes referred to as communication devices. For example, a RAN node can be understood as a communication device with base station functionality, and a terminal can be understood as a communication device with terminal functionality.

[0059] In one possible scenario, the RAN node may be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next generation NodeB (gNB), a next generation base station in a 6G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system, etc. The RAN node may be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a wireless controller in a CRAN scenario. Optionally, the RAN node may also be a server, a wearable device, a vehicle or an on-board device, etc. For example, the access network device in the vehicle to everything (V2X) technology may be a road side unit (RSU). All or part of the functions of the RAN node in the embodiment of the present application may also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (such as a cloud platform). The RAN node in the embodiment of the present application may also be a logical node, a logical module or software that can implement all or part of the functions of the RAN node.

[0060] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, and different RAN nodes respectively implement part of the functions of the base station. For example, the RAN node can be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU and DU can be set separately, or they can be included in the same network element, for example, a baseband unit (BBU). The RU can be included in a radio frequency device or radio frequency unit, for example, a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH).

[0061] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0062] The communication system 10 may further include: a terminal 300. The terminal may also be referred to as a terminal device, user equipment (UE), a mobile station, or a mobile terminal. The terminal can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), the Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, etc. The terminal can be a mobile phone, a head-mounted display device, a tablet computer, a computer with wireless transceiver function, a wearable device, a vehicle, a drone, a helicopter, an airplane, a ship, a robot, a robotic arm, a smart home device, etc. The embodiments of the present application do not limit the device form of the terminal.

[0063] In one design, core network 200 includes a task control function (TCF) and a task process function (TPF).

[0064] Among them, TCF provides the task anchor function on the core network side, including task deployment, startup, modification or deletion, etc. TPF provides the task execution function on the core network side and exchanges task data with other task execution bodies.

[0065] In one implementation, the TCF can deploy a task on at least one terminal and / or at least one TPF for execution. The terminal and the TPF can be referred to as executors. During the execution of the task, task data can be exchanged between different executors. For example, task data can be exchanged between different terminals, between different TPFs, or between a terminal and a TPF. If the TPF is directly connected to the access network device, the functions of the access network device and the TPF may be more complicated. For example, for the access network device, it needs to sense which TPF or terminal the task data sent by the terminal is sent to. For the TPF, it needs to sense which terminal or TPF the task data sent by the TPF is sent to. Furthermore, for the task data sent to the terminal, the TPF also needs to sense the location information of the terminal, so as to know through which access network device the task data is sent to the terminal.

[0066] To reduce the complexity of access network equipment and TPF and efficiently forward task data of different executors, a task forwarding function (TFF) is added to the core network 200. TFF can implement at least one of the following functions:

[0067] 1. Task data forwarding: For example, task data sent by the TPF is sent to the terminal or other TPFs, and task data sent by the terminal is sent to the TPF or a terminal connected to another access network device.

[0068] 2. Task routing: For example, routing task data to a specific TPF based on the Internet Protocol (IP) address or TPF load.

[0069] 3. Task data cache: For example, cache task data sent by the terminal or TPF.

[0070] 4. Maintain (e.g., create, update, or delete) the context of the task tunnel.

[0071] 5. Task data multicast. For example, task data sent by a terminal can be copied multiple times and sent to multiple TPFs or multiple other terminals. Alternatively, task data sent by a TPF can be copied multiple times and sent to multiple terminals or multiple other TPFs.

[0072] It is understood that there is no limitation on the number of TFFs, TCFs, and TPFs deployed in the core network 200 in FIG1 . The schematic diagram of FIG1 illustrates an example of deploying one TCF, one TFF, and multiple TPFs in the core network 200. In addition to the description in FIG1 , the core network 200 may also include other network elements, such as an access and mobility management function (AMF) or a session management function (SMF), without limitation.

[0073] In one possible scenario, a TCF deploys a task to at least one terminal and at least one TPF for execution. During task execution, task data needs to be exchanged between terminals, between terminals and TPFs, and between TPFs. Establishing a tunnel between access network equipment and the TFF for a task is a technical issue to be addressed in this application.

[0074] In the solution of this application, the TCF can initiate a tunnel establishment request for a task to the TFF. The TFF can return the TFF-side tunnel information for the task to the TCF, and the TCF can send the TFF tunnel information to the access network device. The access network device returns the access network device tunnel information for the task to the TCF, and the TCF sends the access network device tunnel information for the task to the TFF. Through the above process, the TFF can obtain the access network device tunnel information for the task, and the access network device can obtain the TFF tunnel information for the task. At this point, it is considered that a tunnel for the task has been established between the TFF and the access network device.

[0075] [Example 1]

[0076] As shown in FIG2 , a process is provided, including:

[0077] Step 210: TCF sends a first request message to TFF, and TFF receives the first request message from TCF.

[0078] In one design, the first request message is used to request TFF to establish a tunnel for the first task. There is no limitation on the name of the first request message. For example, the name of the first request message can be task tunnel establishment request or task session establishment request.

[0079] In one design, the first task is accomplished through the collaboration of multi-dimensional resources. For example, the terminal is located on the user side, and the TPF is located on the core network side. The terminal and TPF have resources of different dimensions (such as computing power, data, and models), and the terminal and TPF can collaborate to achieve a certain goal. For example, the first task can be a distributed training task, which the TCF deploys and executes in the terminal and TPF. In the first round of model training, the initial model can be sent to the terminal and TPF. The terminal and TPF can each train the initial model using local data. At the end of the first round of training, the terminal and TPF can each send the trained models to a central node. The central node aggregates the models sent by the terminal and TPF to obtain the initial model for the second round of training. The initial model is then sent to the terminal and TPF again for the second round of model training. This cycle repeats until the trained model meets the requirements, at which point model training ends. It is understood that the central node can be a terminal or TPF, without limitation. Alternatively, the first task can be a joint inference task, which the TCF deploys and executes in executors such as the terminal and TPF. For example, TCF can split a model into multiple layers and send them to corresponding executors. For example, the first executor performs reasoning on the first layer and sends the inference results to the second executor. The second executor then performs reasoning on the second layer based on the inference results of the first executor, and so on. This cycle continues until the last executor completes reasoning, and the inference results of the last executor are considered the final inference results.

[0080] In one implementation, during the execution of the first task, task data may be exchanged between different terminals, between a terminal and a TPF, or between different TPFs. Task data may refer to data that needs to be exchanged between different executors during the execution of the first task. For example, if two terminals are connected to the same access network device, the transmission path between the two terminals is: terminal - access network device - terminal. Alternatively, task data may be transmitted directly between the two terminals. Alternatively, if the two terminals are connected to different access network devices, the transmission path between the two terminals is: terminal - access network device - other access device - terminal, or terminal - access network device - TFF - other access network device - terminal. The transmission path between a terminal and a TPF is: terminal - access network device - TFF - TPF. The transmission path between two TPFs is: TPF - TFF - TPF. In the embodiments of this application, the focus is on the process of establishing a tunnel between the access network device and the TFF, which enables task data to be transmitted between the access network device and the TFF. The process of transmitting task data between a terminal and an access network device, or between a TFF and a TPF, is not limited. For example, the terminal can send task data to the access network device through the air interface. The TFF can determine the TPF based on the IP address or load information of the task data.

[0081] In this embodiment of the present application, the tunnel for the first task requested by the first request message includes a tunnel between an access network device associated with the first task and a Transmission Function (TF) associated with the first task. The access network device associated with the first task can be described as follows: the executor of the first task may include a terminal, that is, the terminal can execute the first task. The access network device to which the terminal executing the first task is connected can be referred to as the access network device associated with the first task. The TFF associated with the first task can refer to the TFF that performs routing and forwarding of task data for the first task. For example, one or more TFFs can be deployed in the core network. If a single TFF is deployed in the core network, then that TFF performs routing and forwarding of task data for all tasks and can be considered associated with all tasks. Alternatively, if multiple TFFs are deployed in the core network, each TFF can be assigned to a corresponding task. For example, if the multiple TFFs include a first TFF and a second TFF, and the first TFF is used to perform routing and forwarding of task data for the first task, while the second TFF is used to perform routing and forwarding of task data for the second task, then the first TFF is considered the TFF associated with the first task.

[0082] In one implementation, the first request message includes: an identifier of the first task and information about the TPF associated with the first task. Optionally, the first request message may also include at least one of the following: information about the terminal associated with the first task, packet detection rules associated with the first task, packet forwarding rules associated with the first task, an identifier of the TCF, or a session identifier of the first task.

[0083] The first task identifier is used to identify a task. The TPF information associated with the first task may refer to information about the TPF executing the first task, such as the identifier or address of the TPF executing the first task. The terminal information associated with the first task may refer to information about the terminal executing the first task, such as the identifier or address of the terminal executing the first task. The packet detection rule (PDR) associated with the first task refers to the PDR that the TFF uses when routing and forwarding packets of the first task. The packet forwarding rule (FAR) associated with the first task refers to the FAR that the TFF uses when routing and forwarding packets of the first task. For example, one PDR is associated with one FAR. When the TFF receives a packet, it matches the PDR corresponding to the packet based on the destination IP address and the task identifier carried in the packet. Furthermore, the TFF matches the FAR corresponding to the packet based on the FAR associated with the PDR. The FAR may indicate the packet forwarding rule (e.g., forward, cache, or discard) and parameters corresponding to the forwarding action (e.g., destination interface, encapsulation parameters, etc.). It should be noted that, for downlink data packets, the encapsulation parameters may refer to the encapsulation parameters of the General Packet Radio Service Tunneling Protocol User Plane (GTP-U). The TCF identifier is used to identify the TCF. The first task may include one or more sessions, and the session identifier of the first task is used to identify a session of the first task. In other words, the first task may correspond to one first task identifier and may also correspond to one or more first task session identifiers.

[0084] It is understood that the tunnel for the first task can be established at a task granularity. For example, a tunnel is established for the first task. The first task may include one session or multiple sessions. When the first task includes multiple sessions, the multiple sessions use a single tunnel. Alternatively, the tunnel for the first task can be established at a session granularity. For example, when the first task includes one session, a tunnel is established for the session of the first task. Alternatively, when the first task includes multiple sessions, a corresponding tunnel is established for each session. Each session uses a corresponding tunnel to transmit task data. In one implementation, when the tunnel for the first task is established at a task granularity, the first request message includes: the identifier of the first task and information about the TPF associated with the first task. Optionally, the first request message may also include at least one of the following: information about the terminal associated with the first task, packet detection rules associated with the first task, packet forwarding rules associated with the first task, or the identifier of the TCF. Alternatively, when the tunnel for the first task is established at a session granularity, in addition to the aforementioned information, the first request message may also include: the session identifier of the first task.

[0085] In one design, upon receiving the first request message from the TCF, the TFF may establish a tunnel context for the first task. The tunnel context for the first task includes at least one of the following: the identifier of the first task, information about the TPF associated with the first task, information about the terminal associated with the first task, packet detection rules associated with the first task, packet forwarding rules associated with the first task, or the identifier of the TCF. Furthermore, when establishing the tunnel for the first task at session granularity, the tunnel context for the first task may also include the session identifier of the first task.

[0086] Step 220: TFF sends a first response message to TCF, and TCF receives the first response message from TFF.

[0087] In one design, the first response message is a response to the first request message, or the first response message is a response to the first request message. The name of the first response message is not limited. For example, the name of the first response message can be task tunnel establishment response, task session establishment response, etc.

[0088] In one implementation, the first response message includes the tunnel information of the TFF associated with the first task. The tunnel information of the TFF associated with the first task includes: the identifier of the first task, the IP address of the TFF, and the tunnel endpoint identifier (TEID) of the TFF. In one implementation, the TFF routes and forwards task data for the executors of multiple tasks, so the IP address of the TFF cannot uniquely identify a tunnel. When the TFF receives the first request message, it can assign a unique identifier to the tunnel of the first task, and the identifier can uniquely identify the tunnel of the first task on the TFF side. The identifier is the aforementioned TEID. Furthermore, the tunnel information associated with the first task can also include: the session identifier of the first task.

[0089] Step 230: The TCF sends the tunnel information of the TFF associated with the first task and the information of the terminal associated with the first task to the access network device. The access network device receives the tunnel information of the TFF and the information of the terminal associated with the first task from the TCF.

[0090] Step 240: The access network device sends the tunnel information of the access network device to the TCF. The TCF receives the tunnel information of the access network device from the access network device.

[0091] In one design, the tunnel information of the access network device includes: an identifier of the first task, the IP address of the access network device, and the TEID of the access network device. Upon receiving the tunnel information of the TFF associated with the first task and the information of the terminal associated with the first task in step 230, the access network device can assign a unique identifier to the tunnel of the first task on the access network device side. This identifier is the TEID of the access network device. Furthermore, the tunnel information of the access network device also includes: a session identifier of the first task.

[0092] Step 250: The TCF sends the tunnel information of the access network device associated with the first task to the TFF.

[0093] In one design, the terminal information associated with the first task in step 230 may refer to information about the terminal executing the first task. It is understood that the terminal executing the first task may be located on the same access network device or on multiple access network devices. In one implementation, if the terminal executing the first task is located on a single access network device, the TCF sends both the TFF's tunnel information and the terminal information associated with the first task to the access network device, allowing the access network device to obtain the TFF's tunnel information. Simultaneously, the access network device may send its own tunnel information to the TCF, which forwards the access network device's tunnel information to the TFF, allowing the TFF to obtain the access network device's tunnel information. At this point, it can be considered that a tunnel for the first task has been established between the TFF and the access network device. In another implementation, if the terminal executing the first task is located on multiple access network devices, steps 230 to 250 need to be performed for each access network device. In other words, the TCF needs to send the TFF's tunnel information and the terminal information associated with the first task to each access network device. Each access network device also needs to send the tunnel information of its own access network device to TCF. TCF forwards the tunnel information of each access network device to TFF, so that TFF can obtain the tunnel information of each access network device. At this time, it can be considered that a tunnel for the first task is established between TFF and each access network device. The difference is that in this implementation, the terminal information associated with the first task sent by TCF to the access network device is no longer all the terminal information associated with the first task, but can be part of the terminal information associated with the first task. For example, the terminal associated with the first task is located under two access network devices, that is, the terminal executing the first task is respectively located under two access network devices. Among them, in step 230, TCF sends the tunnel information of TFF and the information of the terminal under the access network device to one access network device. TCF sends the tunnel information of TFF and the information of the terminal under the other access network device to another access network device, etc.

[0094] In one implementation, the TCF can deploy the first task across multiple terminals and multiple TPFs. In one design, if multiple terminals are located on the same access network device and multiple TPFs are connected to the same TFF, then according to the process in Figure 2 , the access network device can obtain the TFF's tunnel information, the TFF can obtain the access network device's tunnel information, and a tunnel for the first task can be established between the access network device and the TFF. Alternatively, in one design, if multiple terminals are located on the same access network device and multiple TPFs are connected to different TFFs, then according to the process in Figure 2 , the access network device can obtain the tunnel information of each TFF, each TFF can obtain the access network device's tunnel information, and a tunnel for the first task can be established between the access network device and each TFF. Alternatively, in one design, if multiple terminals are located on different access network devices and multiple TPFs are connected to the same TFF, then according to the process in Figure 2 , each access network device can obtain the TFF's tunnel information, the TFF can obtain the tunnel information of each access network device, and a tunnel for the first task can be established between each access network device and the TFF. Alternatively, in one design, if multiple terminals are located under different access network devices and multiple TPFs are connected to different TFFs, then according to the process of Figure 2, each access network device obtains the tunnel information of each TFF, each TFF obtains the tunnel information of each access network device, and a tunnel for the first task is established between each access network device and each TFF.

[0095] Furthermore, after step 230, the method further includes: step 260: the access network device determines a data radio bearer (DRB) associated with the first task, and sends information of the DRB to the terminal associated with the first task.

[0096] In one implementation, the information of the DRB includes: an identifier of the DRB and an identifier of the first task. Furthermore, the information of the DRB also includes: an identifier of the TCF and / or a session identifier of the first task. In one implementation, the DRB associated with the first task is used to transmit task data of the first task. For example, in downlink transmission, the access network device can use the DRB associated with the first task to send task data of the first task to the terminal. In uplink transmission, the terminal can use the DRB associated with the first task to send task data of the first task to the access network device. The DRB associated with the first task can be called a task data radio bearer (T-DRB).

[0097] Through steps 210 to 260, a tunnel for the first task can be established between the access network device and the TFF, and the tunnel is used to transmit the task data of the first task. The tunnel of the first task can be used between the access network device and the TFF to transmit the task data of the first task. In one design, the access network device and the TFF can route and forward the task data packet of the first task according to the tunnel context of the first task. For example, the TCF sends the FAR associated with the first task to the access network device, and the tunnel context of the first task established by the access network device includes: the identifier of the first task, the information of the terminal associated with the first task, or the FAR associated with the first task. Furthermore, the tunnel context of the first task can also include: the identifier of the TCF and / or the session identifier of the tunnel of the first task. The process of TFF establishing the tunnel context of the first task can be referred to the above description.

[0098] In one design, when TFF receives a data packet: if TFF receives the data packet from an access network device, TFF can determine the task corresponding to the data packet based on the TEID of the access network device carried in the GTP-U header of the data packet. Alternatively, if TFF receives the data packet from TPF, TFF can determine the task corresponding to the data packet based on the task identifier carried in the data packet. TFF matches the corresponding PDR in the tunnel context corresponding to the above task based on the destination IP address carried by the data packet. In one implementation, as shown in Table 1, the attributes of the PDR include parameters such as the PDR identifier, priority parameters, packet detection information, and FAR identifier. The packet detection information includes parameters such as the source interface, destination IP address, network entity, and task identifier.

[0099] Table 1. Attributes of PDR

[0100] The PDR attributes in Table 1 include a FAR identifier. The FAR corresponding to this FAR identifier is the FAR associated with the PDR. The FAR may indicate the corresponding action rule (e.g., forwarding, caching, or discarding) for the data packet, as well as the corresponding forwarding parameters (e.g., destination interface, encapsulation parameters, etc.). In one implementation, the TFF may match the corresponding PDR based on the destination IP address carried by the data packet and the destination IP address included in the packet detection information in the PDR attributes. The TFF then forwards, caches, or discards the data packet based on the action rule indicated by the FAR associated with the PDR. When forwarding the data packet, the TFF may forward the data packet to an access network device or TPF. When forwarding the data packet to the access network device, the TFF may encapsulate the data packet based on the encapsulation parameters indicated by the FAR. Optionally, the encapsulation parameters indicated by the FAR may be referred to as outer header creation parameters, which may be GTP-U encapsulation parameters.

[0101] In one design, when an access network device receives a data packet, it first identifies the task corresponding to the data packet. If the data packet is received by the access network device from a terminal, the access network device can determine the task corresponding to the data packet based on the DRB carrying the data packet, or the task identifier carried in the data packet. Alternatively, if the data packet is received by the access network device from the TPF via the TFF, the access network device can determine the task corresponding to the data packet based on the TEID of the TFF carried in the data packet. The TEID and the task are associated or bound. The TEID of the TFF is different for different tasks. Therefore, the access network device can determine the task corresponding to the data packet based on the TEID of the TFF carried in the data packet. Afterwards, the access network device parses the destination IP address in the data packet and matches the FAR corresponding to the destination IP address. The access network device operates on the data packet based on the FAR.

[0102] For example, the terminal sends an IP data packet of the first task to the access network device, the source IP address of the IP data packet is the IP address of the terminal, and the destination IP address of the IP data packet is the IP address of the TPF. The access network device can match the corresponding FAR in the tunnel context of the first task based on the destination IP address of the IP data packet. If the destination interface corresponding to the forwarding parameter in the FAR corresponds to the TPF, the access network device sends the IP data packet to the TFF. When the TFF receives the IP data packet, it matches the corresponding PDR and FAR in the tunnel context of the first task. If the destination interface in the forwarding parameter corresponding to the FAR is a certain TPF, the TFF sends the IP data packet to the corresponding TPF; alternatively, the TFF can send the IP data packet directly to the corresponding TPF based on the destination IP address carried in the IP data packet.

[0103] It is understandable that the PDR and FAR can be configured at the task granularity, that is, corresponding PDRs and FARs can be configured for different tasks. Different tasks correspond to different PDRs and FARs. Furthermore, multiple PDRs and FARs can be configured for one task. For example, the corresponding PDR and FAR can be configured for the task data sent by the terminal to the TPF. The corresponding PDR and FAR can be configured for the task data sent by the terminal to other terminals. The corresponding PDR and FAR can be configured for the task data sent by the TPF to the terminal. The corresponding PDR and FAR can be configured for the task data sent by the TPF to other TPFs, etc. In one implementation, the TCF can configure the PDR and FAR for the TFF, for example, through the first request message configuration, etc., without limitation.

[0104] For example, a terminal sends a first data packet carrying task data associated with a first task. The terminal sends the first data packet to an access network device via an air interface. The access network device may forward the first data packet to the TFF. The TFF matches the PDR corresponding to the first data packet based on the destination IP address and the identifier of the first task carried in the first data packet. The PDR includes the identifier of the FAR associated with the PDR. The TFF performs the corresponding operation on the first data packet based on the forwarding rule and / or parameters corresponding to the forwarding operation indicated by the FAR associated with the PDR. For example, if the forwarding rule indicated by the FAR is forwarding, the first data packet is sent to the device corresponding to the destination interface, based on the destination interface included in the parameters corresponding to the forwarding operation. If the device corresponding to the destination interface is an access network device, the TFF sends the first data packet to the corresponding access network device. Upon receiving the first data packet, the corresponding access network device may send the first data packet to the corresponding terminal. In this case, task data may be exchanged between the two terminals. Alternatively, if the device corresponding to the destination interface is a TPF, the TFF sends the first data packet to the TPF. In this case, task data may be exchanged between the terminal and the TPF. Of course, if the forwarding rule indicated by FAR is cache or discard, TFF caches the first data packet, or discards the first data packet, etc.

[0105] Take the case where the TPF sends a second data packet, which includes task data associated with the first task. The TPF sends the second data packet to the TFF. The TFF matches the PDR corresponding to the second data packet based on the destination IP address carried in the second data packet and the identifier of the first task. According to the forwarding rule indicated by the FAR associated with the PDR and / or the parameters corresponding to the forwarding operation, the second data packet is subjected to corresponding operations. For example, when the forwarding rule indicated by the FAR is forwarding, the second data packet is sent to the corresponding device based on the destination interface in the forwarding operation parameters corresponding to the forwarding. For example, when the device corresponding to the destination interface is the TPF, the TFF sends the second data packet to the corresponding TPF, and it is considered that task data is exchanged between the two TPFs. Alternatively, when the device corresponding to the destination interface is an access network device, the TFF sends the second data packet to the access network device, and the access network device sends the second data packet to the terminal, and it is considered that task data is exchanged between the TPF and the terminal.

[0106] As can be seen, whether a terminal or a TPF sends service data, the destination interface in the corresponding FAR varies depending on the destination of the service data. In other words, taking the example of a terminal sending service data, the corresponding PDR and FAR need to be configured for each task data sent by the terminal to other terminals and TPFs. Taking the example of a TPF sending service data, the corresponding PDR and FAR need to be configured for each service data sent by the TPF to other TPFs and terminals.

[0107] Furthermore, in one implementation, upon receiving a data packet carrying task data from a terminal, an access network device may perform the following operations on the data packet: sending the data packet to another terminal of the current access network device, or sending the data packet to another access network device, which then sends the data packet to its connected terminal. In this case, task data can be considered to be exchanged between the two terminals. Alternatively, the access network device may send the data packet to a TFF, which then sends the data packet to a TPF. In this case, task data can be considered to be exchanged between the terminal and the TPF. Alternatively, the TFF may send the data packet to another access network device, which then sends the data packet to its connected terminal. In this case, task data can also be considered to be exchanged between the two terminals. In one implementation, a FAR can be configured for the access network device. For example, a TCF can configure a FAR for the access network device, and the access network device can then determine whether to send the data packet to the TFF, the terminal, or another access network device.

[0108] Through the above design, a tunnel for a specific task can be established between the access network device and the TFF. At least one terminal and / or at least one TPF participating in the task can share this task tunnel, and task data can be exchanged through this shared task tunnel. Furthermore, for uplink task data sent by the terminal to the TPF, the access network device only needs to forward it to the TFF, without having to know which TPF the data is being sent to, thus simplifying the complexity of the access network device. For downlink task data sent by the TPF to the access network device, the TPF only needs to forward it to the TFF, without having to know the location of the terminal, thus simplifying the complexity of the TPF.

[0109] [Example 2]

[0110] Through Example 1, a tunnel for the first task can be established between the access network device and the TCF. Different executors can use this tunnel to exchange task data for the first task. When conditions are met, the TCF can update the executor, including but not limited to replacement, addition, or deletion. These conditions include at least one of the following: the battery level is lower than a first threshold, the load is higher than a second threshold, or the terminal is moving. When the executor is updated, the tunnel context of the first task also needs to be updated.

[0111] As shown in FIG3 , a process is provided, including:

[0112] Step 310: TCF sends a second request message to TFF, and TFF receives the second request message from TCF.

[0113] In one design, the second request message is used to request an update of the terminal and / or TPF associated with the first task. There is no limitation on the name of the second request message. For example, the name of the second request message can be task tunnel update request, task session update request, etc.

[0114] In one implementation, the second request message may include: the identifier of the first task, the update reason, and information about the terminal and / or TPF that needs to be updated. The update reason may include at least one of the following: adding a terminal, adding a TPF, deleting a terminal, deleting a TPF, replacing a terminal, or replacing a TPF. The information about the terminal and / or TPF that needs to be updated may include the identifier or address of the terminal and / or TPF that needs to be updated. Furthermore, the second request message may also include: the session identifier of the first task and / or the identifier of the TCF.

[0115] Step 320: TFF updates the tunnel context of the first task according to the second request message. The tunnel context of the first task is established by TFF when receiving the first request message.

[0116] In one design, the TFF may update the tunnel context of the first task based on the content included in the second request message. For example, the TFF may determine the tunnel context corresponding to the first task, i.e., the tunnel context of the first task, based on the identifier of the first task included in the second request message. Of course, if the tunnel for the first task is established at the session granularity, the session identifier of the first task also needs to be considered. That is, if a tunnel is established for each session, the TFF may determine the tunnel context of the first task based on the identifier of the first task and the session identifier of the first task. In one implementation, the tunnel context of the first task includes at least one of the following: the identifier of the first task, information about the TPF associated with the first task, information about the terminal associated with the first task, packet detection rules associated with the first task, packet forwarding rules associated with the first task, or the identifier of the TCF. Furthermore, the tunnel context of the first task also includes the session identifier of the first task. If the update reason in the second request message is the addition of a terminal and / or TPF, the TFF adds the information of the newly added terminal and / or TPF to the information of the terminal and / or TPF associated with the first task. Alternatively, if the update reason in the second request message is to delete the terminal and / or TPF, the corresponding terminal and / or TPF is deleted from the information of the terminal and / or TPF associated with the first task. Alternatively, if the update reason in the second request message is to replace the terminal and / or TPF, etc., the corresponding terminal and / or TPF information is replaced in the terminal and / or TPF associated with the first task.

[0117] Step 330: TFF sends a second response message to TCF, and TCF receives the second response message from TFF.

[0118] In one design, the second response message is a response to the second request message, or the second response message is a response in response to the second request message. There is no limitation on the name of the second response message. For example, the name of the second response message may be Task Tunnel Update Response, Task Session Update Response, etc. The second response message includes the identifier of the first task. Furthermore, the second response message also includes: the session identifier of the first task and / or the TCF identifier.

[0119] In one scenario, if the second request message is used to request updating the terminal associated with the first task, it also includes:

[0120] Step 340: The TCF sends a third request message to the access network device, and the access network device receives the third request message from the TCF.

[0121] In one design, a third request message is used to request an update of the terminal associated with the first task, and the name of the third request message is not limited. For example, the third request message may be named "Task Tunnel Update Request" or "Task Session Update Request." The third request message may include: the identifier of the first task, the reason for the update, and information about the terminal to be updated. Optionally, the third request message also includes the identifier of the TCF and / or the session identifier of the first task.

[0122] Step 350: The access network device updates the tunnel context of the first task according to the third request message.

[0123] For example, the access network device may determine the tunnel context corresponding to the first task, i.e., the tunnel context of the first task, based on the identifier of the first task included in the third request message. The tunnel context of the first task includes at least information about the terminal associated with the first task. The access network device may update the information about the terminal associated with the first task included in the tunnel context of the first task based on the update reason and the terminal information to be updated, etc., included in the third request message. This is similar to how the TFF updates the tunnel context of the first task. If the update reason is a newly added terminal, the identifier or address of the newly added terminal is added to the information about the terminal associated with the first task, for example, by adding it to the identifier list or address list of the terminals associated with the first task. Alternatively, if the update reason is a terminal deletion, the corresponding terminal information is deleted from the information about the terminals associated with the first task. For example, the identifier or address of the corresponding terminal is deleted from the identifier list or address list of the terminals associated with the first task. Alternatively, if the update reason is a terminal replacement, the corresponding terminal information is replaced with the new terminal information in the information about the terminal associated with the first task. For example, the identifier or address of the corresponding terminal is replaced in the identifier list or address list of the terminals associated with the first task.

[0124] Step 360: The access network device updates the DRB associated with the first task according to the terminal information that needs to be updated.

[0125] For example, if the access network device adds a new terminal or replaces a terminal, the access network device needs to configure the DRB associated with the first task for the new or replaced terminal, and in step 360, send information about the DRB associated with the first task to the new or replaced terminal. Alternatively, if the access network device deletes a terminal, the access network device may delete the DRB associated with the first task configured for the terminal. Furthermore, the access network device may send a notification message to the terminal to inform the terminal that the DRB associated with the first task has been deleted.

[0126] Step 370: The access network device sends a third response message to the TCF, and the TCF receives the third response message from the access network device.

[0127] In one design, the third response message is a response to the third request message, or the third response message is a response to the third request message. The name of the third response message is not limited. For example, the third response message can be named "Task Tunnel Update Response" or "Task Session Update Response." The third response message includes the identifier of the first task. Furthermore, the third response message also includes the session identifier of the first task.

[0128] Through the above design, TFF can dynamically update the tunnel context of the first task according to the adjustment of the executor topology, ensuring that the access network equipment and TFF can correctly route and forward the task data of different executors, and ensure efficient interaction of task data between different executors.

[0129] It is understood that in the embodiments of the present application:

[0130] 1. Focus on describing the differences between different processes. The descriptions of different processes can refer to each other.

[0131] 2. In the processes of Figures 2 and 3, the order of the different steps is not limited. For example, the order of step 250 and step 260 in Figure 2. In addition, each process may include fewer steps or more steps than the process diagram or text description.

[0132] 3. In the processes of Figures 2 and 3, the TCF, TFF, access network equipment, and terminals are used as examples for description. It is understandable that in each process, the functions of the TCF can be implemented by the TCF, or by a module (such as a chip or circuit, etc.) in the TCF. The functions of the TFF can be implemented by the TFF, or by a module in the TFF. The functions of the access network equipment can be implemented by the access network equipment, or by a module in the access network equipment, or by a logical node, logical module, or software that can fully or partially implement the functions of the access network equipment. The functions of the terminal can be implemented by the terminal, or by a module in the terminal.

[0133] 4. In the embodiments of the present application, "(e.g., TFF) receives a message from (e.g., TCF)" can be understood as the source of the message being TCF and the destination being TFF, which may include TFF directly or indirectly receiving the message from TCF. The message may undergo necessary processing between the source and destination, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application should be understood similarly and will not be repeated here.

[0134] In the embodiments provided in the present application, the methods provided in the embodiments of the present application are introduced from the perspective of the interaction between each device. In order to implement the various functions in the methods provided in the embodiments of the present application, TFF, TCF and access network equipment, etc., may include hardware structures and / or software modules, and may implement the above functions in the form of hardware structures, software modules, or hardware structures plus software modules. Whether a certain function of the above functions is executed in the form of hardware structures, software modules, or hardware structures plus software modules depends on the design constraints of the specific application of the technical solution.

[0135] Figures 4 and 5 are schematic diagrams of possible apparatuses provided in embodiments of the present application. These communication devices can implement one or more corresponding functions in the above-described method embodiments. For example, functions implemented by a TFF, TCF, or access network device may thus achieve the beneficial effects of the above-described method embodiments.

[0136] As shown in FIG. 4 , the communication device 400 includes a processing unit 410 and a transceiver unit 420 .

[0137] For example, the processing unit 410 may also be referred to as a processor, a processing board, a processing module, a processing device, etc. The transceiver unit 420 may also be referred to as a transceiver, a transceiver, a transceiver module, a transceiver device, a communication unit, etc. Furthermore, the transceiver unit 420 may include at least one of a transmitting unit and a receiving unit. The transmitting unit and the receiving unit may be integrated together or two independent units.

[0138] In one design, the communication device 400 is used to implement the functions of the TFF in Figures 2 and 3. Taking the implementation of the functions of the TFF in Figure 2 as an example, specifically:

[0139] The transceiver unit 420 is used to receive a first request message from the task control function TCF, where the first request message is used to request the task forwarding function TFF to establish a tunnel for the first task, where the first task is completed through the collaboration of multi-dimensional resources; the processing unit 410 is used to generate a first response message; the transceiver unit 420 is also used to send a first response message to the TCF in response to the first request message, where the first response message includes tunnel information of the TFF associated with the first task; the transceiver unit 420 is also used to receive tunnel information of the access network device associated with the first task from the TCF.

[0140] In one design, communication device 400 is used to implement the functions of TCF in Figures 2 and 3. Taking the implementation of the functions of TCF in Figure 2 as an example, specifically:

[0141] The processing unit 410 is used to generate a first request message; the transceiver unit 420 is used to send the first request message to the task forwarding function TFF, the first request message is used to request TFF to establish a tunnel for the first task, and the first task is completed through the collaboration of multi-dimensional resources; the transceiver unit 420 is also used to receive a first response message from TFF in response to the first request message, the first response message includes tunnel information of TFF associated with the first task; the transceiver unit 420 is also used to send the tunnel information of TFF and the information of the terminal associated with the first task to the access network device; the transceiver unit 420 is also used to receive tunnel information of the access network device associated with the first task from the access network device; the transceiver unit 420 is also used to send the tunnel information of the access network device to TFF.

[0142] In one design, the communication device 400 is used to implement the functions of the access network devices in Figures 2 and 3. Taking the implementation of the functions of the access network device in Figure 2 as an example, specifically:

[0143] The transceiver unit 420 is used to receive tunnel information of the task forwarding function TFF associated with the first task of the task control function TCF and information of the terminal associated with the first task, and the first task is completed through the collaboration of multi-dimensional resources; the processing unit 410 is used to generate tunnel information of the access network device; the transceiver unit 420 is also used to send the tunnel information of the access network device to the TCF, and the access network device is associated with the tunnel of the first task.

[0144] In one implementation, when the access network device adopts the O-RAN architecture, the processing unit 410 may be located on the O-CU entity, and the transceiver unit 420 may be located on the O-DU or O-RU entity. Optionally, when the O-CU entity includes an O-CU-CP entity, the processing unit 410 may be located on the O-CU-CP entity. Alternatively, the processing unit 410 is located on the O-DU entity, and the transceiver unit 420 is located on the O-RU entity. Alternatively, both the processing unit 410 and the transceiver unit 420 are located on the O-DU entity or the O-RU entity, etc., without limitation.

[0145] For a more detailed description of the processing unit 410 and the transceiver unit 420, reference may be made to the description of FIG. 2 and FIG. 3 in the above method embodiment, which will not be repeated here.

[0146] It is understood that the division of units in the embodiments of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods. In addition, the various functional units in the embodiments of the present application can be integrated into a physical device (for example, a processor), or each functional unit can be a separate physical device, or two or more units can be integrated into a unit for implementation. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional modules.

[0147] Figure 5 shows another schematic diagram of the structure of a communication device 500 provided in an embodiment of the present application. For example, the communication device 500 shown in Figure 5 can be a hardware circuit implementation of the communication device 400 shown in Figure 4. For ease of illustration, Figure 5 only shows the main parts of the communication device.

[0148] As shown in Figure 5, the communication device 500 includes a processor 510 and an interface circuit 520. The processor 510 and the interface circuit 520 are coupled to each other.

[0149] For example, the processor 510 may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor. The interface circuit 520 may be a transceiver or an input / output circuit, etc.

[0150] Optionally, the communication device 500 may further include a memory 530 for storing instructions executed by the processor 510, or storing input data required by the processor 510 to execute instructions, or storing data generated after the processor 510 executes instructions. For example, instructions may also be referred to as computer programs, or computer program codes, etc.

[0151] For example, the memory 530 can be a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a register, a hard disk, a mobile hard disk, a compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art.

[0152] When the communication device 500 is used to implement the functions of the TFF, TCF or access network device in Figures 2 and 3, the processor 510 is used to implement the functions of the processing unit 410, and the interface circuit 520 is used to implement the functions of the transceiver unit 420.

[0153] In one design, the interface circuit 520 is used to receive signals from other communication devices outside the communication device 500 and transmit them to the processor 510, or to send signals from the processor 510 to other communication devices outside the communication device. The processor 510 uses logic circuits or executes code instructions to implement the functions of the TFF, TCF or access network device in Figure 2 or Figure 3 above.

[0154] An embodiment of the present application provides a communication device, including a processor and a memory, the processor and the memory being coupled, and the processor being used to implement the functions of the TFF, TCF, or access network device in Figure 2 or Figure 3. For example, the processor can execute instructions in the memory so that the communication device implements one or more functions in the above-mentioned method embodiments, such as the functions implemented by the TFF, TCF, or access network device in Figure 2. In an exemplary embodiment, a storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in the TFF, TCF, or access network device in Figure 2 or Figure 3. The processor and the storage medium can also exist as discrete components in the TFF, TCF, or access network device in Figure 2 or Figure 3.

[0155] The present application provides a computer-readable storage medium storing instructions, which may also be referred to as a computer program, computer program code, etc. The instructions are executed on a computer, causing the computer to perform the functions of the TFF, TCF, or access network device in FIG. 2 or FIG. 3 in the above method embodiments.

[0156] Alternatively, the computer may be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, or other programmable device. A computer program or instruction may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, a computer program or instruction may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired or wireless method. A computer-readable storage medium may be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. Available media may be magnetic media, such as a floppy disk, a hard disk, or a magnetic tape; optical media, such as a digital video disk; or semiconductor media, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0157] The present application provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed on a computer, the method of the TFF, TCF, or access network device in Figure 2 or Figure 3 is executed. For example, the computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on the computer, the process or function of the TFF, TCF, or access network device in Figure 2 or Figure 3 of the present application is fully or partially executed.

[0158] It is understood that the methods in the embodiments of the present application can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented by software, they can be implemented in whole or in part in the form of a computer program product.

[0159] An embodiment of the present application provides a chip, which includes a processor coupled to a memory, and the processor is configured to execute a computer program or instruction stored in the memory, so that the chip implements the functions of the TFF, TCF, or access network device in Figure 2 or Figure 3. For example, taking the example of a chip implementing the functions of an access network device, the chip can receive information from other modules in the access network device (such as a radio frequency or antenna, etc.), and the information can be sent by the TCF to the access network device. Alternatively, the access network device can send information to other modules in the access network device (such as a radio frequency or antenna, etc.), and the information is sent by the access network device to the TCF, etc.

[0160] An embodiment of the present application provides a communication system, including: a first communication device and a second communication device.

[0161] The first communication device can implement the functionality of the TFF in Figure 2 or Figure 3. The second communication device can implement the functionality of the TCF in Figure 2 or Figure 3. Furthermore, the device further includes a third communication device, which can implement the functionality of the access network device in Figure 2 or Figure 3. For the specific structure of the TFF, TCF, or access network device, please refer to the previous description, such as the structural description in Figure 4 or Figure 5.

Claims

1. A method for establishing a task tunnel, characterized in that: include: receiving a first request message from a task control function TCF, wherein the first request message is used to request a task forwarding function TFF to establish a tunnel for a first task, wherein the first task is completed through collaboration of multi-dimensional resources; Sending a first response message in response to the first request message to the TCF, wherein the first response message includes tunnel information of the TFF associated with the first task; Receive tunnel information of an access network device associated with the first task from the TCF.

2. The method according to claim 1, characterized in that The tunnel of the first task includes: a tunnel between the access network device associated with the first task and the TFF associated with the first task.

3. The method according to claim 1 or 2, characterized in that The first request message includes: an identifier of the first task and information of a task processing function TPF associated with the first task.

4. The method according to claim 3, characterized in that The first request message also includes at least one of the following: information of a terminal associated with the first task, a data packet detection rule associated with the first task, a data packet forwarding rule associated with the first task, or an identifier of the TCF.

5. The method according to any one of claims 1 to 4, characterized in that The tunnel information of the TFF includes: an identifier of the first task, an Internet Protocol IP address of the TFF, and a tunnel endpoint identifier TEID of the TFF.

6. The method according to any one of claims 1 to 5, characterized in that The tunnel information of the access network device includes: an identifier of the first task, an IP address of the access network device, and a TEID of the access network device.

7. The method according to any one of claims 1 to 6, characterized in that Also includes: receiving a second request message from the TCF, where the second request message is used to request updating of the terminal and / or TPF associated with the first task; updating, according to the second request message, a tunnel context of the first task, wherein the tunnel context of the first task is established by the TFF when receiving the first request message; A second response message is sent to the TCF in response to the second request message.

8. The method according to claim 7, characterized in that The second request message includes: the identifier of the first task, the update reason, and the information of the terminal that needs to be updated and / or the information of the TPF.

9. The method according to claim 7 or 8, characterized in that The second response message includes an identifier of the first task.

10. A method for establishing a task tunnel, characterized in that: include: Sending a first request message to a task forwarding function TFF, wherein the first request message is used to request the TFF to establish a tunnel for a first task, where the first task is completed through collaboration of multi-dimensional resources; receiving a first response message from the TFF in response to the first request message, wherein the first response message includes tunnel information of the TFF associated with the first task; Sending the tunnel information of the TFF and the information of the terminal associated with the first task to the access network device; Receiving tunnel information of the access network device associated with the first task from the access network device; Send tunnel information of the access network device to the TFF.

11. The method according to claim 10, characterized in that The tunnel of the first task includes: a tunnel between the access network device associated with the first task and the TFF associated with the first task.

12. The method according to claim 10 or 11, characterized in that The first request message includes: an identifier of the first task and information of a task processing function TPF associated with the first task.

13. The method according to claim 12, characterized in that The first request message also includes at least one of the following: information of a terminal associated with the first task, a data packet detection rule associated with the first task, a data packet forwarding rule associated with the first task, or an identifier of a task control function TCF.

14. The method according to any one of claims 10 to 13, characterized in that The tunnel information of the TFF includes: an identifier of the first task, an Internet Protocol IP address of the TFF, and a tunnel endpoint identifier TEID of the TFF.

15. The method according to any one of claims 10 to 14, characterized in that The tunnel information of the access network device includes: an identifier of the first task, an IP address of the access network device, and a TEID of the access network device.

16. The method according to any one of claims 10 to 15, characterized in that Also includes: Sending a second request message to the TFF, where the second request message is used to request updating the terminal and / or TPF associated with the first task; A second response message is received from the TFF in response to the second request message.

17. The method according to claim 16, characterized in that The second request message includes: the identifier of the first task, the update reason, and the information of the terminal that needs to be updated and / or the information of the TPF.

18. The method according to claim 16 or 17, characterized in that The second response message includes an identifier of the first task.

19. The method according to any one of claims 16 to 18, characterized in that When the second request message is used to request to update the terminal associated with the first task, it also includes: Sending a third request message to the access network device, where the third request message is used to request updating the terminal associated with the first task; A third response message is received from the access network device in response to the third request message.

20. The method of claim 19, wherein: The third request message includes: the identifier of the first task, the update reason, and the information of the terminal that needs to be updated.

21. The method according to claim 19 or 20, characterized in that The third response message includes the identifier of the first task.

22. A method for establishing a task tunnel, characterized in that: include: Receiving tunnel information of a task forwarding function TFF associated with a first task from a task control function TCF and information of a terminal associated with the first task, wherein the first task is completed through collaboration of multi-dimensional resources; Send tunnel information of an access network device to the TCF, where the access network device is associated with the tunnel of the first task.

23. The method of claim 22, wherein: The tunnel of the first task includes: a tunnel between the access network device associated with the first task and the TFF associated with the first task.

24. The method according to claim 22 or 23, characterized in that The tunnel information of the TFF includes: an identifier of the first task, an Internet Protocol IP address of the TFF, and a tunnel endpoint identifier TEID of the TFF.

25. The method according to any one of claims 22 to 24, characterized in that The tunnel information of the access network device includes: an identifier of the first task, an IP address of the access network device, and a TEID of the access network device.

26. The method according to any one of claims 22 to 25, characterized in that Also includes: Determine a data radio bearer DRB associated with the first task; Send the DRB information to the terminal associated with the first task.

27. The method according to any one of claims 22 to 26, characterized in that Also includes: receiving a third request message from the TCF, where the third request message is used to request updating a terminal associated with the first task; According to the third request message, updating the context of the tunnel of the first task, where the context of the tunnel of the first task is established by the access network device when receiving the tunnel information of the TFF associated with the first task and the information of the terminal associated with the first task; A third response message is sent to the TCF in response to the third request message.

28. The method of claim 27, wherein: The third request message includes: the identifier of the first task, the update reason, and the information of the terminal that needs to be updated.

29. The method according to claim 27 or 28, characterized in that The third response message includes the identifier of the first task.

30. A communication device, characterized in that: The method comprises means for implementing the method according to any one of claims 1 to 9.

31. A communication device, characterized in that: The method comprises a processor and a memory, wherein the processor and the memory are coupled, and the processor is used to implement the method according to any one of claims 1 to 9.

32. A communication device, characterized in that: The device comprises a processor and an interface circuit, wherein the interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device, and the processor is used to implement the method as described in any one of claims 1 to 9 through logic circuits or execution code instructions.

33. A communication device, characterized in that: Comprising units for implementing the method according to any one of claims 10 to 21.

34. A communication device, characterized in that: The method comprises a processor and a memory, wherein the processor and the memory are coupled, and the processor is used to implement the method according to any one of claims 10 to 21.

35. A communication device, characterized in that: It includes a processor and an interface circuit, wherein the interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device, and the processor is used to implement the method as described in any one of claims 10 to 21 through logic circuits or executing code instructions.

36. A communication device, characterized in that: Comprising means for implementing the method according to any one of claims 22 to 29.

37. A communication device, characterized in that: The method comprises a processor and a memory, wherein the processor and the memory are coupled, and the processor is configured to implement the method according to any one of claims 22 to 29.

38. A communication device, characterized in that: It includes a processor and an interface circuit, wherein the interface circuit is used to receive signals from other devices outside the device and transmit them to the processor or send signals from the processor to other devices outside the device, and the processor is used to implement the method as described in any one of claims 22 to 29 through logic circuits or executing code instructions.

39. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, which are executed on a computer to cause the computer to execute the method of any one of claims 1 to 9, or the method of any one of claims 10 to 21, or the method of any one of claims 22 to 29.

40. A computer program product, characterized in that The method comprises a computer program or an instruction, which, when executed by a device, causes the method described in any one of claims 1 to 9 to be executed, or the method described in any one of claims 10 to 21 to be executed, or the method described in any one of claims 22 to 29 to be executed.

41. A chip, characterized in that: The invention comprises a processor coupled to a memory and configured to execute a computer program or instruction stored in the memory, so that the chip implements the method of any one of claims 1 to 9, or the method of any one of claims 10 to 21, or the method of any one of claims 22 to 29.

42. A communication system, characterized in that: include: A first communication device, the first communication device being configured to perform the method according to any one of claims 1 to 9; as well as A second communication device, wherein the second communication device is configured to execute the method according to any one of claims 10 to 21.

43. A communication system, characterized in that: include: A first communication device, the first communication device being configured to perform the method according to any one of claims 1 to 9; A second communication device, the second communication device being configured to perform the method according to any one of claims 10 to 21; as well as A third communication device, configured to execute the method according to any one of claims 22 to 29.

Images