Method, device and system for managing tasks

Abstract

The invention provides a task management method which is applied to task management. The method includes: acquiring first description information about a first task, the first description information including at least one of the following items: a time validity condition indicating when the first task is valid; a spatial validity condition indicating where the first task is valid; the reusability indication is used for indicating whether the first task can be used as a computing block (CB) in another task or not; the application indication indicates at least one application supported by the first task; describing interface information of an interface through which the first task can be accessed; the task intention information describes a task intention of the first task; the task specification describes intercommunication logic among one or more CBs of the first task, and the one or more CBs are used for realizing the task intention described by the task intention information; or at least one task parameter to be specified; a first request is sent to a task open function (MEF) network entity, where the first request includes the first description information about the first task, and the first request indicates a management related to the first task.

Description

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 586,484, filed September 29, 2023, the entire disclosure of which is incorporated herein by reference. Technical Field

[0002] This invention relates generally to the field of wireless communication, and more particularly to a method, apparatus, and system for managing missions, as well as a computer-readable storage medium. Background Technology

[0003] With the development of communication technologies, numerous new trends will drive the design of next-generation wireless networks. These trends may include, for example, the widespread deployment of new network infrastructure capabilities (e.g., cloud-native / friendly infrastructure); new (relatively) mature technologies that have made significant progress and have a major impact on society and human life (e.g., large-scale AI models, data privacy, blockchain, etc.); or new applications and services that are widely used in industrial / commercial sectors and by individual users (e.g., AI services, data (sensing) services, digital world services, etc.). Furthermore, more globalized / open / collaborative operations (i.e., more open and collaborative operating methods) are becoming common practice in many fields.

[0004] New expectations and stricter requirements for future networks have also driven a rethinking and development of next-generation wireless networks. These requirements may include privacy and trustworthiness, standardization and simplification, and rapid deployment.

[0005] All of the above factors have driven the research on sixth-generation (6G) network architecture.

[0006] The purpose of describing this background information is to disclose information that the applicant believes may be relevant to the present invention, and it is not intended to acknowledge, nor should it be construed as, any of the foregoing information constituting prior art in relation to the present invention. Summary of the Invention

[0007] This invention provides a task management method and apparatus.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: According to a first aspect, a method is provided performed by an Application Function (AF) network entity. The method includes: obtaining first descriptive information about a first task, for example, the first descriptive information being a portion of a task template, wherein the first descriptive information includes at least one of the following: a time validity condition indicating when the first task is valid; a spatial validity condition indicating where the first task is valid; a reusability indicator indicating whether the first task can be used as a computing block (CB) in another task; an application indicator indicating at least one application supported by the first task; interface information describing an interface through which the first task can be accessed; task intent information describing the task intent of the first task; a task specification describing the interoperability logic between one or more CBs of the first task, the one or more CBs being used to implement the task intent described in the task intent information; or at least one task parameter to be specified; sending a first request to a Mission Exposure Function (MEF) network entity, wherein the first request includes the first descriptive information about the first task, and the first request indicates management related to the first task.

[0009] In some embodiments, the first description information includes the task intent information, and the first request instructs the creation of the first task.

[0010] In some embodiments, the method further includes receiving a first response from the MEF network entity, wherein the first response indicates that the first request has been rejected or accepted.

[0011] In some embodiments, the first response indicates that the first request has been rejected; the first response further includes a reason for rejection, wherein the reason includes one of the following: the first description information does not include the task intent or the task specification; the first task includes a sub-mission computation block and the sub-mission computation block corresponds to a non-reusable task; or the first task is deprecated.

[0012] In some embodiments, the first request instructs modification of at least one element of the first description information of the first task. For example, the first request instructs modification of the reusability indication indicated in the first description information.

[0013] The first beneficial effect is that the Task Assignment (AF) provides the system with task-related description information (e.g., task templates). For example, when the AF is capable of determining task specifications, the task template provided by the AF can include task specifications. If the task template provided by the AF does not include task specifications, the system will generate the task specifications based on the task intent information in the task template. This shifts the task of determining task specifications from the AF to the system, allowing the use of less capable AFs.

[0014] According to a second aspect, a method is provided performed by an application function (AF) network entity, the method comprising: sending a fourth request to a mission exposure function (MEF) network entity, wherein the fourth request indicates the removal of a second task, and the fourth request includes a second task ID identifying the second task; and receiving a fourth response from the MEF network entity, wherein the fourth response indicates that the second task is deprecated if third description information regarding the second task is deleted via logical deletion, wherein the logical deletion indicates that the third description information is stored in memory and has been processed. For example, the third description information is in the form of a task template.

[0015] In some embodiments, the fourth response indicates that the second task is removed if the third description information regarding the second task is deleted by physical deletion, wherein the physical deletion indicates that the third description information is removed from the memory.

[0016] The beneficial effect of the method provided in the second aspect is that it allows for the dynamic and secure removal of task templates associated with a task based on the request of the Task Allocation Filter (AF). Removal is performed in two steps: logical deletion (deprecation / abolishment) and physical deletion. A notification regarding deprecation / abolishment is sent to the AF so that no new instances of the task are created or requested. Physical deletion is performed after all task instances of the task have been removed. Therefore, dynamically removing task templates does not affect the use of existing task instances of the task.

[0017] According to a third aspect, a method is provided performed by a mission exposure function (MEF) network entity, the method comprising: receiving a first request from an application function (AF) network entity, wherein the first request includes first descriptive information about a first task, and the first request indicates management related to the first task, the first descriptive information including at least one of the following: a time validity condition indicating when the first task is valid; a spatial validity condition indicating where the first task is valid; a reusability indication indicating whether the first task can be used as a computing block (CB) in another task; an application indication indicating at least one application supported by the first task; interface information describing an interface through which the first task can be accessed; task intent information describing the task intent of the first task; task specification information describing the interoperability logic between one or more CBs of the first task, the one or more CBs being used to implement the task intent described by the task intent information; or at least one task parameter to be specified; and obtaining second descriptive information about the first task, wherein the second descriptive information is generated based on the first descriptive information.

[0018] In some embodiments, the first description information includes the task intent information, and the second description information includes the task specification generated based on the task intent.

[0019] In some embodiments, obtaining the second description information about the first task includes: obtaining a task specification based on the task intent, wherein the task specification describes the interoperability logic between one or more computational blocks of the first task, the one or more CBs being used to implement the task intent; and generating the second description information about the first task, wherein the second description information includes the task specification.

[0020] In some embodiments, obtaining the task specification according to the task intent includes: sending a second request to a first service control function (SCF) network entity, wherein the second request instructs the generation of the task specification and includes the task intent information; receiving a second response from the first SCF network entity including the first task specification, wherein the first task specification is generated by the first SCF network entity according to the task intent; and generating at least a portion of the task specification according to the first task specification.

[0021] In some embodiments, the first task specification includes a computation block ID of a subtask computation block corresponding to the third task to be created and subtask intent information corresponding to the third task, wherein the subtask intent information describes the subtask intent; obtaining the task specification according to the task intent further includes: sending a third request to a second SCF network entity, wherein the third request indicates the generation of a subtask specification, and the third request includes the subtask intent information, wherein the subtask specification describes the interoperability logic between one or more computation blocks of the subtask computation block, and the one or more computation blocks of the subtask computation block are used to implement the subtask intent described by the subtask intent information; receiving a third response from the second service control function entity including a second task specification, wherein the second task specification is generated by the second SCF network entity according to the subtask intent.

[0022] In some embodiments, obtaining the task specification according to the task intent further includes: generating the task specification corresponding to the task intent based on the first task specification and the second task specification.

[0023] In some embodiments, generating the task specification corresponding to the task intent based on the first task specification and the second task specification includes: integrating the second task specification into the first task specification to generate the task specification corresponding to the task intent.

[0024] In some embodiments, the method further includes sending the second description information about the first mission to a mission data repository (MDR) network entity.

[0025] In some embodiments, the first description information regarding the first task satisfies predefined conditions; the method further includes sending a first response to the AF network entity indicating that the first request has been rejected.

[0026] In some embodiments, the predefined conditions include at least one of the following: the first description information does not include the task intent information or the task specification; the first task includes a subtask computation block, the subtask computation block corresponding to a non-reusable task; or the first task is deprecated.

[0027] In some embodiments, the method further includes: sending a first acknowledgment to the first SCF network entity, wherein the first acknowledgment indicates that the first task specification has been accepted; and / or sending a second acknowledgment to the second SCF network entity, wherein the second acknowledgment indicates that the second task specification has been accepted.

[0028] In some embodiments, either the second request or the first confirmation includes a first task ID that identifies the first task, wherein the first task ID is included in the first description information or generated by the MEF; and / or either the third request or the second confirmation includes the first task ID.

[0029] The third beneficial effect is that the Task Assignment (AF) provides the system with task templates associated with the task. For example, when the AF is capable of determining task specifications, the task template provided by the AF can include the task specifications. If the task template provided by the AF does not include task specifications, the system will generate the task specifications based on the task intent information in the task template. This shifts the task of determining task specifications from the AF to the system, allowing the use of AFs with lower capabilities.

[0030] According to a fourth aspect, a method is provided performed by a mission exposure function (MEF) network entity, the method comprising: receiving a fourth request from an application function (AF) network entity, wherein the fourth request indicates the removal of a second mission and the fourth request includes a second mission ID identifying the second mission; and sending a fifth request to a mission data repository (MDR) network entity, wherein the fifth request includes the second mission ID and indicates the removal of third descriptive information about the second mission.

[0031] In some embodiments, the method further includes: receiving a fifth response from the MDR network entity, wherein the fifth response indicates a deletion type of the third descriptive information, the deletion type including physical deletion and / or logical deletion, the physical deletion indicating that the third descriptive information is removed from memory, and the logical deletion indicating that the third descriptive information is stored in the memory and has been processed.

[0032] In some embodiments, the method further includes sending a fourth response to the application function (AF) network entity, wherein the fourth response includes the second task ID and indicates the status of the second task, the status corresponding to the deletion type.

[0033] In some embodiments, the state of the second task corresponding to the physical deletion is that the second task is unavailable, and the state of the second task corresponding to the logical deletion is that the second task is abandoned.

[0034] In some embodiments, the fourth description information regarding the second task satisfies predefined conditions, wherein the fourth description information is obtained based on the second task ID; the method further includes: sending a sixth response to the AF, wherein the sixth response indicates that the fourth request has been rejected.

[0035] In some embodiments, the predefined conditions include: the fourth description information about the second task indicates that the second task is a reusable task and is being used.

[0036] In some embodiments, the method further includes: sending the second task ID to the target network entity; and obtaining the fourth description information from the target network entity.

[0037] The beneficial effect of the method provided in the fourth aspect is that it allows for the dynamic and secure removal of task templates associated with a task based on the request of the Task Allocation Filter (AF). Removal is performed in two steps: logical deletion (deprecation / abolishment) and physical deletion. A notification regarding deprecation / abolishment is sent to the AF so that no new instances of the task are created or requested. Physical deletion is performed after all task instances of the task have been removed. Therefore, dynamically removing task templates does not affect the use of existing task instances of the task.

[0038] According to a fifth aspect, a method is provided performed by a service control function (SCF) network entity, the method comprising: receiving a second request from a mission exposure function (MEF) network entity, wherein the second request instructs the generation of a mission specification, and the second request includes mission intent information describing the objective of a first mission; and sending a first mission specification to the MEF network entity, wherein the first mission specification is generated by the SCF network entity based on the mission intent information included in the second request.

[0039] In some embodiments, the method further includes: determining one or more computing blocks of the first task and networking logic between the one or more computing blocks; generating a first task specification, wherein the first task specification includes a computing block ID of each computing block in the one or more computing blocks and the networking logic.

[0040] In some embodiments, the first task specification includes a computation block ID of a subtask computation block corresponding to a third task to be created and a subtask intent corresponding to the third task; the method further includes: receiving a third request from the MEF network entity, wherein the third request indicates the generation of a subtask specification, and the third request includes the subtask intent information, the subtask specification describing the networking logic between one or more computation blocks of the subtask computation block, the one or more computation blocks of the subtask computation block being used to implement the subtask intent described by the subtask intent information; sending a second task specification to the MEF network entity, wherein the second task specification is part of the task specification corresponding to the task intent, and the second task specification is generated by the service control function network entity according to the subtask intent.

[0041] In some embodiments, the method further includes: receiving a first confirmation from the MEF network entity, wherein the first confirmation indicates that the first task specification has been accepted.

[0042] In some embodiments, the method further includes: receiving a second confirmation from the Task Open Function Network entity, wherein the second confirmation indicates that the second task specification has been accepted.

[0043] In some embodiments, either the second request or the first confirmation includes a first ID identifying the first task; and / or either the third request or the second confirmation further includes the first ID identifying the first task.

[0044] The fifth beneficial effect is that the Task Assignment (AF) provides the system with task-related description information (e.g., task templates). For example, when the AF is capable of determining task specifications, the task template provided by the AF can include task specifications. If the task template provided by the AF does not include task specifications, the system will generate the task specifications based on the task intent information in the task template. This shifts the task of determining task specifications from the AF to the system, allowing the use of less capable AFs.

[0045] According to a sixth aspect, a method is provided performed by a mission data repository (MDR) network entity, the method comprising: receiving a fifth request from a mission exposure function (MEF) network entity, wherein the fifth request includes a second mission ID identifying a second mission and instructing the removal of third descriptive information about the second mission; and sending a fifth response to the fifth request to the MEF network entity, wherein the fifth response indicates a deletion type of the third descriptive information, the deletion type including physical deletion or logical deletion, the physical deletion indicating that the third descriptive information is removed from memory, and the logical deletion indicating that the third descriptive information is stored in the memory and has been processed.

[0046] In some embodiments, the method further includes: if the second task includes a task instance, using the logical deletion to remove the third description information; or if the second task does not include a task instance, using the physical deletion to process the third description information.

[0047] In some embodiments, the method further includes sending a sixth request to a mission instance repository (MIR) network entity, wherein the sixth request includes the second mission ID and instructs the MIR network entity to send one or more notifications regarding information changes related to the second mission.

[0048] In some embodiments, the method further includes: receiving a sixth response to the sixth request from the MIR network entity, wherein the sixth response includes an instance ID identifying a task instance of the second task and indicating information changes regarding the task instance, the information changes indicating that the task instance has been created for the second task or that the task instance has been removed.

[0049] In some embodiments, the method further includes: determining whether the second task includes a task instance based on the sixth response.

[0050] In some embodiments, determining whether the second task includes the task instance based on the sixth response includes: determining the number of existing instances of the second task based on the instance ID and the information changes corresponding to the instance ID; if the number is equal to 0, then determining that the second task does not include a task instance.

[0051] The beneficial effect of the method provided in the sixth aspect is that task templates associated with a task can be dynamically and safely removed based on the request of the Task Allocation Filter (AF). Removal is performed in two steps: logical deletion (deprecation / abolishment) and physical deletion. A notification regarding deprecation / abolishment is sent to the AF so that no new instances of the task are created or requested. Physical deletion is performed after all task instances of the task have been removed. Therefore, dynamically removing task templates does not affect the use of existing task instances of the task.

[0052] According to a seventh aspect, an apparatus is provided, the apparatus comprising: at least one processor for executing computer program instructions stored in a memory, such that the apparatus implements the method according to either the first or second aspect.

[0053] According to an eighth aspect, an apparatus is provided, the apparatus comprising: at least one processor for executing computer program instructions stored in a memory, such that the apparatus implements the method according to any one of the third and fourth aspects.

[0054] According to a ninth aspect, an apparatus is provided, the apparatus comprising: at least one processor for executing computer program instructions stored in a memory, such that the apparatus implements the method according to a fifth aspect.

[0055] According to a tenth aspect, an apparatus is provided, the apparatus comprising: at least one processor for executing computer program instructions stored in a memory, such that the apparatus implements the method according to any one of the sixth aspects.

[0056] According to the eleventh aspect, a system is provided, the system comprising: the apparatus according to the seventh aspect, the apparatus according to the eighth aspect, and the apparatus according to the ninth aspect.

[0057] According to the twelfth aspect, a system is provided, the system comprising: the apparatus according to the seventh aspect, the apparatus according to the eighth aspect, and the apparatus according to the tenth aspect.

[0058] According to a thirteenth aspect, a computer-readable storage medium is provided, the computer-readable storage medium storing computer program instructions, which, when executed by a computer's processing circuitry, cause the computer to perform the method according to any one of the first, second, third, fourth, fifth, or sixth aspects.

[0059] According to the fourteenth aspect, a computer program product is provided. The computer program product has instructions that, when executed by a computer, cause the computer to perform the method according to any one of the first, second, third, fourth, fifth, or sixth aspects.

[0060] According to a fifteenth aspect, a chip system is provided. The chip system includes: processing circuitry and a storage medium, wherein the storage medium stores computer program instructions, which, when executed by the processing circuitry, cause the chip system to implement the method according to any one of the first, second, third, fourth, fifth, or sixth aspects.

[0061] The advantages of any of the designs in aspects seven through fifteen can be found in aspects one through six, or in different designs of aspects one through six, and will not be repeated here.

[0062] Based on the implementation methods provided in the above aspects, the present invention can provide more implementation methods through further combinations. Attached Figure Description

[0063] Figure 1 This illustrates a communication environment in which embodiments of the present invention can be implemented; Figure 2 This illustrates another communication environment in which embodiments of the present invention can be implemented; Figure 3 An apparatus is shown that enables wireless communication with at least one of two devices in a communication system according to some embodiments of the present invention; Figure 4 This is a block diagram of an electronic device (ED) or apparatus according to some embodiments of the present invention; Figure 5 The conceptual structure of a 6G system according to some embodiments of the present invention is shown; Figure 6 A task management architecture according to an embodiment of the present invention is shown; Figure 7 This illustrates the process of NE accessing the application; Figure 8 A signaling diagram of a creation task according to some embodiments of the present invention is shown; Figure 9 A signaling diagram of removing a task template according to some embodiments of the present invention is shown; Figure 10 A flowchart is shown of a method performed by an application function (AF) network entity according to some embodiments of the present invention; Figure 11 Another flowchart of a method performed by an application function (AF) network entity according to some embodiments of the present invention is shown; Figure 12A flowchart illustrating a method performed by a mission exposure function (MEF) network entity according to some embodiments of the present invention is shown; Figure 13 A flowchart illustrating a method performed by a Mission Open Function (MEF) network entity according to some embodiments of the present invention is shown; Figure 14 A flowchart is shown illustrating a method performed by a service control function (SCF) network entity according to some embodiments of the present invention; Figure 15 A flowchart illustrating a method performed by a mission data repository (MDR) network entity according to some embodiments of the present invention is shown; Figure 16 This is a schematic diagram of the structure of a network device according to some embodiments of the present invention. Detailed Implementation

[0064] The principles of the present invention will now be described in conjunction with embodiments thereof. It should be understood that these embodiments are described merely to illustrate and assist those skilled in the art in understanding and implementing the invention, and do not impose any limitations on the scope of the invention. The embodiments described herein can be implemented in various ways other than those described below.

[0065] In this invention, references to "an embodiment," "an embodiment," "an exemplary embodiment," "some embodiments," etc., indicate that the described embodiments may include specific features, structures, or characteristics, but not every embodiment needs to include specific features, structures, or characteristics. Furthermore, these phrases do not necessarily refer to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in connection with an embodiment, it should be understood that, whether explicitly described or not, those skilled in the art will recognize how such features, structures, or characteristics can be combined with other embodiments to achieve the desired effect.

[0066] It should be understood that although terms such as "first," "second," etc., preceding one or more nouns may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and do not restrict the order of one or more nouns. For example, a first element may be referred to as a second element, and similarly, a second element may be referred to as a first element, without departing from the scope of the embodiments. The term "and / or" as used herein includes any and all combinations of one or more of the listed terms.

[0067] As used in this document, “at least one of the following: ”, “at least one of ”, and similar wording mean at least one of these elements, or at least any two or more of these elements, or at least all of these elements, wherein the list of two or more elements is connected by “and” or “or”.

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

[0069] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as New Radio (NR), Long-Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed ​​Packet Access (HSPA), and Narrow Band Internet of Things (NB-IoT). Furthermore, communication between terminal devices and network devices within a communication network can be performed according to any suitable generation of communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, fifth-generation (5G), sixth-generation (6G) communication protocols and / or any other currently known or future protocols. Embodiments of this invention can be applied to various communication systems. Given the rapid development of communication, future communication technologies and systems embodying this invention will inevitably emerge in the future. The scope of this invention should not be limited to the system described above.

[0070] As used in this document, the term "network device" refers to a node in a communication network through which terminal devices access the network and receive services. Network devices can refer to base stations (BS) or access points (APs), such as Node B (NodeB or NB), evolved Node B (eNodeB or eNB), NR NB (also known as gNB), Remote Radio Unit (RRU), radio header (RH), remote radio head (RRH), relay, integrated access and backhaul (IAB) node, low-power nodes such as femtoseconds and picoseconds, and non-terrestrial network (NTN) or non-terrestrial network devices such as satellite network equipment, low earth orbit (LEO) satellites and geosynchronous earth orbit (GEO) satellites, and spacecraft network equipment, depending on the terminology and technology used. In some embodiments, the radio access network (RAN) split architecture includes a centralized unit (CU) and a distributed unit (DU) at the IAB host node. The IAB node includes a mobile terminal (IAB-MT) portion that behaves similarly to a UE facing the parent node, and the DU portion of the IAB node that behaves similarly to a base station facing the next-hop IAB node.

[0071] The term "terminal equipment" refers to any terminal device capable of wireless communication. By way of example and not limitation, terminal equipment may also be referred to as communication equipment, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices may include, but are not limited to: mobile phones, cellular phones, smartphones, voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (e.g., digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, customer-premises equipment (CPE), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks, etc. The terminal device may also correspond to the mobile termination (MT) portion of an IAB node (e.g., a relay node). In the following description, the terms "terminal device," "communication device," "terminal," "user equipment," and "UE" are used interchangeably.

[0072] Figure 1 An exemplary communication environment in which exemplary embodiments of the present invention can be implemented is shown. Reference Figure 1This diagram, provided as an illustrative example and not as limiting, provides a simplified schematic of a communication system (also referred to as a computing and communication environment) 100. The communication system 100 (which may be a wireless system) includes a radio access network (RAN) 120. RAN 120 may be a next-generation (e.g., sixth-generation, 6G, or later) radio access network, or a traditional (e.g., 5G, 4G, 3G, or second-generation, 2G) radio access network. One or more electronic devices (EDs) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generally referred to as ED 110) may interconnect with each other or be connected to one or more network nodes (170a and 170b, generally referred to as 170) in the radio access network 120. A core network 130 may be part of the communication system 100 and may depend on or be independent of the radio access technology used in the communication system 100. The communication system 100 may also include a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0073] Generally, communication system 100 enables multiple wireless or wired units to transmit data and other content. Communication system 100 can provide voice, data, video, and / or text content through broadcasting, multicast, ensemble broadcasting, unicast, etc. Furthermore, communication system 100 can provide a wide range of communication services and applications (such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery, and mobility). These services and / or applications can be mobile broadband (MBB) services, ultra-reliable low-latency communication (URLLC) services, or machine-type communication (MTC) services.

[0074] The communication system 100 can operate by sharing resources such as carrier spectrum bandwidth among its constituent components.

[0075] Figure 2 Another exemplary communication environment in which exemplary embodiments of the present invention can be implemented is shown.

[0076] Communication system 100 may include terrestrial communication systems 120a / 120b and / or non-terrestrial communication system 120c. Communication system 100 can provide high availability and robustness through the joint operation of terrestrial communication systems 120a / 120b and non-terrestrial communication system 120c. For example, integrating non-terrestrial communication system 120c (or components thereof) into terrestrial communication systems 120a / 120b can create a multi-layered heterogeneous network. Heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0077] The terrestrial communication system 120a / 120b and the non-terrestrial communication system 120c can be regarded as subsystems of the communication system.

[0078] Communication system 100 may include ED 110a, ED 110b, ED 110c, ED 110d (generally referred to as ED 110) and RAN 120a and RAN 120b. Additionally, communication system 100 may include a non-terrestrial communication network 120c. Communication system 100 may also include one or more of the following: core network 130, public switched telephone network (PSTN) 140, Internet 150, and other networks 160. RAN 120a and RAN 120b include corresponding RAN nodes such as base stations (BS) 170a and 170b, which are generally referred to as terrestrial transmit and receive points (T-TRP) 170a and 170b (generally referred to as T-TRP 170). In one implementation, the non-terrestrial communication network 120c includes RAN nodes such as access nodes (base stations) 172, which can generally be referred to as a non-terrestrial transmit and receive point (NT-TRP) 172. Based on the similarity of the reference numerals, it can be inferred that the non-terrestrial communication network 120c can be considered a radio access network sharing common operational characteristics with RAN 120a and RAN 120b. In another implementation, the non-terrestrial communication network 120c may include at least one non-terrestrial network (NTN) device and at least one corresponding terrestrial network device, wherein the at least one NTN device acts as a transport layer device, and the at least one corresponding terrestrial network device acts as a RAN node, communicating with ED 110 through the NTN device. Additionally, an NTN gateway (i.e., a terrestrial network device) may also exist on the ground as a transport layer device communicating with the NTN device, and the RAN node communicates with ED 110 through the NTN device and the NTN gateway. In some embodiments, the NTN gateway and the RAN node may reside in the same device.

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

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

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

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

[0083] Additionally, the communication system 100 may include a sensing agent (not shown) to manage sensing data from ED 110 and / or T-TRP 170a, T-TRP 170b and / or NT-TRP 172. In one implementation, the sensing agent resides within T-TRP 170 and / or NT-TRP 172. In another implementation, the sensing agent is a separate node with an interface for communicating with core network 130 and / or RAN 120 (e.g., T-TRP 170a, T-TRP 170b and / or NT-TRP 172).

[0084] Figure 3An example of a device 310 is shown that wirelessly communicates with at least one of two devices (e.g., device 320a and device 320b, referred to as device 320) in a communication system (e.g., communication system 100) according to one embodiment. Device 310 may be a UE (e.g., Figure 1 or Figure 2 ED 110 in the example). Device 320a can be a terrestrial network device (e.g., such as ED 110). Figure 2 As shown in T-TRP 170a and T-TRP 170b, device 320b can be a non-terrestrial network device (e.g., such as...). Figure 2 (NT-TRP 172 shown). However, this is not a necessary condition. For example, according to the invention, device 320a can be NT-TRP, 320b can be T-TRP, and both devices 320a and 320b can be either T-TRP or NT-TRP. ED 110 is described below as an example of device 310, T-TRP 170 is described as an example of device 320a, and NT-TRP 172 is described as an example of device 320a. Although there is only one device 310, one device 320a, and one device 320b, note that the number of devices 310 (e.g., ED 110) can be one or more, and the number of devices 320a and / or 320b can be one or more. For example, an ED110 can be served by only one T-TRP 170 (or one NT-TRP 172), by more than one T-TRP 170, by more than one NT-TRP 172, or by one or more T-TRP 170 and one or more NT-TRP 172.

[0085] The ED 110 is used to connect people, objects, and machines. It can be widely used in various scenarios, including cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), MTC, Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), digital twins, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery, and mobility.

[0086] Each ED 110 represents any suitable end-user equipment for wireless operation and may include (or may be referred to as, but is not limited to): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), MTC equipment, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smart book, vehicle, car, truck, bus, train, or IoT device, wearable device such as a watch, a pair of glasses, a head-mounted device, industrial equipment, or devices within the aforementioned devices (e.g., communication modules, modems, or chips), or any device including the aforementioned devices. Next-generation ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs, hereinafter referred to as T-TRP 170. Also in Figure 3 As shown, the non-terrestrial (NT) device is referred to below as NT-TRP 172. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically turned on (i.e., established, activated, or enabled), turned off (i.e., released, deactivated, or disabled), and / or used in response to one or more of the following: connectivity availability and connectivity necessity.

[0087] like Figure 3As shown, ED 110 includes at least one processor 210. Only one processor 210 is shown in the figure to avoid clutter. ED 110 may also include a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown in the figure to avoid clutter. Alternatively, one, some, or all of the antennas 204 may be panels. The transmitter 201 and receiver 203 may, for example, be integrated as a transceiver. The transceiver is used to modulate data or other content for transmission by at least one antenna 204 or via a network interface controller (NIC). The transceiver is also used to demodulate data or other content received by at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals. ED 110 may include at least one memory 208. For simplicity, only transmitter 201, receiver 203, processor 210, memory 208 and antenna 204 are shown, but ED 110 may include one or more other components.

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

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

[0090] Processor 210 performs (or controls ED 110 to perform) operations described herein as being performed by ED 110, as shown below and in other parts of the invention. For example, processor 210 performs or controls ED 110 to perform the following operations: receive a transport block (TB), use resources for decoding one TB of the received TB, release resources for decoding another TB of the received TB, and / or receive configuration information for configuration resources. Specifically, operations may include transmission-related operations for preparing uplink transmissions to NT-TRP 172 and / or T-TRP 170, operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170, and operations related to processing sidelink transmissions to and from another ED 110. Processing operations related to preparing uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. Processing operations related to downlink transmissions may include transmit / receive beamforming, modulation / demodulation, and encoding / decoding symbols. According to embodiments, downlink transmissions may be received by receiver 203, possibly using receive beamforming, and processor 210 may extract signaling from the downlink transmissions (e.g., by detecting and / or decoding signaling). Examples of signaling may be reference signals transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, processor 210 implements transmit beamforming and / or receive beamforming based on beam direction indications received from T-TRP 170, such as beam angle information (BAI). In some embodiments, processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some embodiments, processor 210 may perform channel estimation, for example, using reference signals received from NT-TRP 172 and / or T-TRP 170.

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

[0092] The processing components of processor 210, transmitter 201, and receiver 203 may be implemented by the same or different one or more processors, which execute instructions stored in memory (e.g., memory 208). Alternatively, some or all of the processing components of processor 210, transmitter 201, and receiver 203 may be implemented using dedicated circuitry such as a programmable field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or hardware accelerator (e.g., a graphics processing unit (GPU) or artificial intelligence (AI) accelerator).

[0093] In some embodiments, ED 110 may be a device (also referred to as a component) such as a communication module, modem, chip, or chipset, including at least one processor 210 and an interface or at least one pin. In this scenario, transmitter 201 and receiver 203 may be replaced by an interface or at least one pin, wherein the interface or at least one pin is used to connect the device (e.g., a chip) and other devices (e.g., a chip, memory, or bus). Therefore, sending information to NT-TRP 172 and / or T-TRP 170 and / or another ED 110 can be referred to as sending information to an interface or at least one pin, or as sending information to NT-TRP 172 and / or T-TRP 170 and / or another ED 110 via an interface or at least one pin, while receiving information from NT-TRP 172 and / or T-TRP 170 and / or another ED 110 can be referred to as receiving information from an interface or at least one pin, or as receiving information from NT-TRP 172 and / or T-TRP 170 and / or another ED 110 via an interface or at least one pin. This information may include control signaling and / or data.

[0094] like Figure 3As shown, the T-TRP 170 includes at least one processor 260. Only one processor 260 is shown in the figure to avoid clutter. The T-TRP 170 may also include at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid clutter. Alternatively, one, some, or all of the antennas 256 may be a panel. The transmitter 252 and receiver 254 may be integrated as a transceiver. The T-TRP 170 may also include at least one memory 258. The T-TRP 170 may also include a scheduler 253. For simplicity, only the transmitter 252, receiver 254, processor 260, memory 258, antenna 256, and scheduler 253 are shown, but the T-TRP may include one or more other components.

[0095] In some embodiments, the T-TRP 170 may be referred to by other names, such as: base station, base transceiver station (BTS), wireless base station, network node, network device, network-side device, transmit / receive node, Node B, evolved NodeB (eNodeB or eNB), femtocell, next-generation NodeB (gNB), transmission point (TP), site controller, access point (AP), wireless router, relay station, ground node, ground network device, ground base station, base band unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. The T-TRP 170 can be a macro base station (BS), micro BS, relay node, host node, etc., or a combination thereof. T-TRP 170 may refer to the aforementioned device or a component within the aforementioned device (e.g., a communication module, modem, or chip).

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

[0097] Processor 260 performs various operations, including those related to: preparing transmissions for downlink transmission to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmission to T-TRP 170 and / or NT-TRP 172, and processing transmissions received from T-TRP 170 and / or NT-TRP 172 via backhaul. Processing operations related to preparing transmissions for downlink or backhaul transmission may include encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received uplink transmissions or transmissions received via backhaul may include receive beamforming, demodulating received symbols, and decoding received symbols. Processor 260 may also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB) and generating system information. In some embodiments, processor 260 also generates beam direction indications, such as BAI, which can be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110 and the location for deploying NT-TRP 172. In some embodiments, processor 260 may generate signaling, for example, for configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252.

[0098] Scheduler 253 may be coupled to or integrated into processor 260. Scheduler 253 may be included in T-TRP 170 or may operate separately from T-TRP 170. Scheduler 253 may schedule uplink, downlink, lateral link, and / or backhaul transmissions, including issuing scheduling grants and / or configuring unscheduled (e.g., "configured grants") resources.

[0099] Memory 258 is used to store information and optional data. Memory 258 stores instructions and data used, generated, or collected by T-TRP 170. For example, memory 258 may store software instructions or modules that implement some or all of the functions and / or embodiments described herein and are executed by processor 260.

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

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

[0102] When T-TRP 170 is a device (also referred to as a component) such as a communication module, modem, chip, or chipset in a device, it includes at least one processor and an interface or at least one pin. In this scenario, transmitter 252 and receiver 254 can be replaced by an interface or at least one pin, wherein the interface or at least one pin is used to connect the device (e.g., a chip) and other devices (e.g., a chip, memory, or bus). Therefore, sending information to NT-TRP 172 and / or T-TRP 170 and / or ED110 can be referred to as sending information to an interface or at least one pin, while receiving information from NT-TRP 172 and / or T-TRP 170 and / or ED 110 can be referred to as receiving information from an interface or at least one pin. This information may include control signaling and / or data.

[0103] Although the NT-TRP 172 is shown as an example of a drone only, the NT-TRP 172 can be implemented in any suitable non-terrestrial form, such as satellites and high-altitude platforms, including international mobile communication base stations and unmanned aerial vehicles. Furthermore, in some embodiments, the NT-TRP 172 may be referred to by other names, such as non-terrestrial node, non-terrestrial network device, or non-terrestrial base station.

[0104] like Figure 3 As shown, the T-TRP 170 may also include at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid clutter. Alternatively, one, some, or all of the antennas 256 may be a panel. The transmitter 252 and receiver 254 may be integrated as a transceiver. The T-TRP 170 may also include at least one memory 258. The T-TRP 170 may also include a scheduler 253. For simplicity, only the transmitter 252, receiver 254, processor 260, memory 258, antenna 256, and scheduler 253 are shown, but the T-TRP may include one or more other components.

[0105] like Figure 3 As shown, the NT-TRP 172 includes at least one processor 276. Only one processor 276 is shown in the figure to avoid clutter. The NT-TRP 172 may include a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure to avoid clutter. Alternatively, one, some, or all of the antennas may be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 may also include at least one memory 278. The NT-TRP 172 may also include a scheduler. For simplicity, only the transmitter 272, receiver 274, processor 276, memory 278, and antenna 280 are shown, but the NT-TRP may include one or more other components.

[0106] NT-TRP 172 includes a processor 276 for performing operations including those related to: preparing a transmission for downlink transmission to ED 110, processing an uplink transmission received from ED 110, preparing a transmission for backhaul transmission to T-TRP 170 and / or another NT-TRP 172, and processing a transmission received from T-TRP 170 and / or another NT-TRP 172 via backhaul. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received uplink transmissions or transmissions received via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling, for example, for configuring one or more parameters of ED 110. In some embodiments, NT-TRP 172 implements physical layer processing but does not implement higher-level functions such as medium access control (MAC) or radio link control (RLC) layer functions. Since this is only an example, in general, NT-TRP 172 may implement higher-level functions in addition to physical layer processing.

[0107] Memory 278 is used to store information and optional data. Memory 258 stores instructions and data used, generated, or collected by NT-TRP 172. For example, memory 278 may store software instructions or modules that implement some or all of the functions and / or embodiments described herein and are executed by processor 276.

[0108] Processor 276 may be part of transmitter 272 and / or receiver 274, but is not shown in the figure. Memory 278 may be part of processor 276, but is not shown in the figure.

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

[0110] When NT-TRP 172 is a device within a machine (e.g., a communication module, modem, chip, or chipset), it includes at least one processor and an interface or at least one pin. In this scenario, transmitter 272 and receiver 257 can be replaced by an interface or at least one pin, wherein the interface or at least one pin is used to connect the device (e.g., a chip) and other devices (e.g., a chip, memory, or bus). Therefore, sending information to T-TRP 170 and / or another NT-TRP 172 and / or ED 110 can be referred to as sending information to an interface or at least one pin, while receiving information from T-TRP 170 and / or another NT-TRP 172 and / or ED 110 can be referred to as receiving information from an interface or at least one pin. This information may include control signaling and / or data.

[0111] It should be noted that "TRP" as used in this article can refer to either T-TRP or NT-TRP. T-TRP can also be called terrestrial network TRP (TN TRP), and NT-TRP can also be called non-terrestrial network TRP (NTN TRP). T-TRP 170, NT-TRP 172, and / or ED 110 may include other components, but these are omitted for clarity.

[0112] It should be noted that, for simplicity, the term "signaling" used in this document can also be referred to as control signaling, control message, control information, or message. Signaling between a BS (e.g., network node 170) and a terminal or sensing device (e.g., ED 110), or between different terminals or sensing devices (e.g., between ED 110i and ED 110j), can be carried in physical layer signaling (also known as dynamic signaling) and transmitted in the physical layer control channel. For the downlink, physical layer signaling can be referred to as downlink control information (DCI) transmitted in the physical downlink control channel (PDCCH). For the uplink, physical layer signaling can be referred to as uplink control information (UCI) transmitted in the physical uplink control channel (PUCCH). For sidelinks, signaling between different terminals or sensing devices (e.g., between ED 110i and ED110j) can be referred to as sidelink control information (SCI) transmitted in the physical sidelink control channel (PSCCH). This signaling can be carried in higher-layer (e.g., above the physical layer) signaling and transmitted in physical layer data channels, such as the physical downlink shared channel (PDSCH) for downlink signaling, the physical uplink shared channel (PUSCH) for uplink signaling, and the physical sidelink shared channel (PSSCH) for sidelink signaling. Higher-layer signaling can also be referred to as static or semi-static signaling. Higher-layer signaling can be radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling. Signaling can be included in a combination of physical layer signaling and higher layer signaling.

[0113] It should be noted that in this invention, when "information" is different from "message", the information can be carried in a single message or in more than one single message.

[0114] Figure 4 This is an exemplary block diagram of a device or apparatus according to an exemplary embodiment of the present invention. One or more steps of the method provided in this invention can be performed by corresponding units or modules in the device or apparatus (e.g., ED 110, T-TRP 170, or NT-TRP 172). For example, a signal can be transmitted by a transmitting unit or transmitting module 420. A signal can be received by a receiving unit or receiving module 430. A signal can be processed by a processing unit or processing module 440. Other steps can be performed by an artificial intelligence (AI) or machine learning (ML) module 450.

[0115] like Figure 4 As shown, the device or apparatus may also include an operating system module 410 (e.g., an embedded operating system, firmware, etc.). The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more of these units or modules may be circuits such as integrated circuits. Examples of integrated circuits include programmable FPGAs, GPUs, or ASICs. For example, one or more of these units or modules may be logic, such as logical functions executed by circuits, by a portion of an integrated circuit, or by software instructions executed by a processor. It should be understood that if these modules are implemented, for example, using software executed by a processor, the processor may retrieve these modules, in whole or in part, as needed, individually or collectively for processing, in one or more instances, and these modules themselves may include instructions for further deployment and instantiation.

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

[0117] As mentioned above, emerging trends have driven research into 6G network architecture. The 6G network architecture needs to support new 6G services that can be developed / deployed by third parties. The proposed 6G network architecture needs to include a more open ecosystem, allowing access to technically capable third parties. The proposed 6G network architecture also needs to achieve better trust management.

[0118] Figure 5 An exemplary conceptual structure of a 6G system according to some exemplary embodiments of the present invention is shown.

[0119] The proposed 6G system architecture is defined as supporting 6GXaaS services through technologies such as network function virtualization and network slicing. The 6G system architecture leverages service-based interactions between 6G services.

[0120] 6G systems utilize a service-based architecture and the XaaS concept. XaaS services in 6G systems are divided into three layers.

[0121] The infrastructure layer 510 includes the infrastructure that supports 6G services. This includes wireless network (RAN, CN) infrastructure 511 and 512, cloud / data center infrastructure 514, satellite network 513, storage / database infrastructure 515, and sensing networks, etc. This infrastructure can be provided by a single provider or by multiple providers.

[0122] Each infrastructure can have its own control and management functions (referred to as C / M functions) for infrastructure management. Each of these infrastructures is a type of Infrastructure as a Service.

[0123] The Control and Management (C / M) layer 520 includes control and management services for the 6G system. These services are developed and deployed using slicing technology and leveraging the resources provided by the Infrastructure layer 510. The 6G services in the Control and Management (C / M) layer are as follows: Resource Management (RM) as a Service 521 provides lifecycle management capabilities for various slices and the ability to allocate over-the-air resources to wireless devices.

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

[0125] Mission Management (MM) as a Service (522) provides the capability to program the provision of XaaS services in the service layer to provide mission services.

[0126] The Confederation Network (CONET) as a Service 525 provides the capability for multiple partners to jointly deliver 6G services. This capability is provided through the formation of the consortium, mutual authentication and authorization among partners, and the recording and retrospective negotiation protocols for selected operations performed by partners, with the aim of ensuring a trusted environment for the operation of 6G systems.

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

[0128] Connectivity Management (CM) as a Service 524 utilizes 5G connectivity management capabilities, but extends to include the digital world.

[0129] Protocol as a Service (PAS) 526 provides the ability to design custom protocol stacks for services that are identified by the interface.

[0130] Protocol stacks can be predefined for selection on demand, or they can be designed on demand.

[0131] Cybersecurity 527 as a Service provides infrastructure owners with the ability to detect potential security risks to their infrastructure.

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

[0133] Service layer 530 includes 6G services that provide services to customers. In the 6G system conceptual architecture: The AI ​​service is represented as NET4AI as a Service 531. The Artificial Intelligence Service provides AI capabilities that support a wide range of AI applications.

[0134] The service of data collection, data cleaning, data analysis, and data delivery is represented as data analytics and manage (DAM) as a service. This service provides the ability to manage the lifecycle of statistical data, which includes the acquisition, de-identification, analysis, and delivery of data (information statistics from any type of sensor, device, network function, etc.).

[0135] The data storage and sharing service is represented as NET4Data as a Service 532, which provides the ability to reliably store and share data under the control of the data owner, in accordance with the regulations of recognized authorities regarding the control of the identified data.

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

[0137] The 6G blockchain service is represented as NET4BC as a service 534. The 6G connectivity service is represented as NET4Con as a service. This service provides the capability to support 6G blockchain services.

[0138] Enhanced connectivity services, such as network for connectivity (NET4CON) as a service 536.

[0139] This service provides the ability to exchange messages and data between new 6G services.

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

[0141] In addition to supporting 6G XaaS services at the service layer, the 6G system also leverages the 5G system to provide vertical services. The difference between 6G XaaS services and those in other vertical sectors is that vertical sectors are purely customer-facing and require other XaaS services to operate, with each XaaS service providing its capabilities to the 6G customer.

[0142] Any pair of XaaS services in a 6G system can also be each other's customers and providers. For example, an infrastructure owner provides its resources to XaaS services in Service Layer 530 and C / M Layer 520; RM services may require the capabilities provided by NET4AI 531, DAM 533, and NET4DW 535 for managing their vertical slice resources; CONET service 525 and NET4Data service 532 may require the capabilities provided by NET4BC 534 for operation.

[0143] Key concepts of 6G systems include: - Basic XaaS services are defined by decoupling comprehensive service types into basic XaaS services. Basic XaaS services provide the unique capability to implement specific types of services such as NET4AI service 531, NET4DW service 535, DAM service 533, NET4Data service 532, blockchain service 534, and task management service 522.

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

[0145] - Define the data plane of the 6G system, which includes the data plane processing functions of XaaS services. Programming the interconnection of these functions through the task management service 522 can support various customized customer services.

[0146] -Simplify the 6G system architecture by categorizing basic control and management services and combining them into basic XaaS services in the control and management (C / M) layer 520.

[0147] - Define the C / M plane of the 6G system. The C / M plane includes the C / M function in the XaaS service and may include 5G CP (e.g., AMF), depending on the implementation scheme.

[0148] - Define the Basic Architecture Structure (BAS). BAS is a unified basic structure with a minimum number of interfaces, independent of infrastructure type.

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

[0150] - Adapt to various deployment scenarios by applying BAS or a subset thereof to the infrastructure based on the infrastructure network's capabilities, capacity, and requirements.

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

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

[0153] From the perspective of 6G system operation, trustworthiness can be improved by introducing the CONET capability, NET4BC capability, and anonymity service provided by the trusted GW in the C / M plane and data plane of the 6G system.

[0154] - From the perspective of protecting end-customer privacy, trustworthiness is enhanced through unified mutual authentication, IDM, data cleansing, and other services provided by SPM, DAM, and 6G blockchain services.

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

[0156] - By defining multiple architectural schemes, it supports multiple development paths from 5G systems to 6G systems without having to spend too much effort on introducing the BAS concept.

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

[0158] - By implementing the concept of anonymous service provision in the trusted GW of 6G C / M plane and 6G data plane, future expansion is supported by adding new XaaS services, while minimizing the impact on standardization and deployment.

[0159] For illustrative purposes, specific exemplary embodiments will be explained in more detail below with reference to the accompanying drawings and the above-described system, core network, ED, and TRP.

[0160] The embodiments described herein illustrate information sufficient to practice the claimed subject matter and explain methods for practicing such subject matter. Upon reading the following description with reference to the accompanying drawings, those skilled in the art will understand the concept of the claimed subject matter and recognize that the application of these concepts is not specifically set forth herein. It should be understood that these concepts and applications are within the scope of the invention and the appended claims.

[0161] The present invention provides systems, apparatus and methods for managing tasks (e.g., task templates, also known as task slice templates).

[0162] In this invention, a task aims to achieve a specified objective, referred to as a task objective, which may include at least one of the following: (1) providing PDU connectivity, and (2) optionally, providing data processing. When the task objective includes providing data processing, the task objective is associated with one or more specific computational problems, and providing data processing means solving one or more specific computational problems. In this case, the task includes one or more computing blocks (CBs) and is associated with a networking process between CBs for solving one or more specific computational problems. A CB within a task corresponds to a computational step defined for the task objective (i.e., solving one or more specific computational problems) and may accordingly be supported by a service (e.g., in the form of a task, a data network (DN), or another task), referred to as a work CB (corresponding to a service in the form of a task), an external CB (corresponding to a service in the form of a data network), or a subtask CB (corresponding to another task). Task management includes programming the task, instantiating the task, and implementing the task objective.

[0163] A task slice is a logical network that provides specific capabilities and characteristics in terms of networking and computation (including storage) for a task. A task slice (CB) corresponds to a subnet of the task slice (called a CB subnet). The CB subnet provides the computational functionality to implement the corresponding computational steps for the task objective. A task slice instance includes a set of network function instances and the required resources (e.g., computation, storage, and network resources) and computational logic (e.g., in terms of parameter configuration); these three elements constitute the deployed task slice. Task services are services between a network entity (NE) (e.g., a UE or AS) and a DN that achieve the task objective (also known as task execution). A task session refers to the association between an NE and a DN, providing task services with the support of task slice instances.

[0164] Unless otherwise specified, "task" and "task slice" are used interchangeably for ease of representation; similarly, "CB" and "CB subnet" are used interchangeably. When a task is instantiated, a task slice instance is created for that task. Therefore, a task slice instance is considered an instance of the task. For each CB within a task, the task instance includes an instance of that CB. If the CB is a working CB, the CB instance resides in the XaaS service module (or, for simplicity, a service module) that supports that working CB; if the CB is an external CB, the CB instance resides in the corresponding DN; if the CB is a subtask CB, the CB instance is an instance of the task corresponding to that CB. A task can have multiple instances. When a CB instance is stateless, it can be shared by multiple task instances. Similarly, when a task instance is stateless, it can be shared (i.e., supported) by multiple applications. A task instance is stateless if and only if it does not contain any stateful CB instances.

[0165] Figure 6 The task management architecture of this invention is illustrated. For example... Figure 6 As shown, architecture 600 includes multiple network functions: AF610, MDR 615, MIR 620, MCF 625, MEF 630, SCF 635, TCF 640, and PSF 645. In some embodiments, any two or more of the above network functions can be integrated into a single network function. For example, MIR 620 and MDR 615 are integrated together. The following will describe... Figure 6 The network functions shown.

[0166] Application function (AF) 610. AF 610 can request the creation / update or removal of tasks, as described in this invention. More specifically, in this invention, creating a task means creating descriptive information about the task. The descriptive information can take any form, such as a task template. Details related to task templates will be further described below. Similarly, updating a task means updating the descriptive information of the task, for example, updating at least one element in the task template of the task. Removing a task means removing the descriptive information of the task, i.e., the task template of the task. The nature of the AF is not limited. That is, any network entity can act as an AF. Unless otherwise specified, AF and AF network entity are used interchangeably for ease of representation.

[0167] Mission data repository (MDR) 615. MDR 615 stores mission templates. MDR 615 may also be referred to as mission template repository (MTD). As mentioned above, a mission template is a form of descriptive information related to a mission. Table 1 below describes the contents of a mission template. MDR receives mission templates from MEF 630. MEF 630 may receive a portion of a mission template from AF 610 and a portion of a mission template from one or more SCFs. In some embodiments, MDR 615 provides the mission specification or mission template from the mission template to MCF 625 upon request from an MCF. MDR 615 may also provide mission intent information from the mission template to AF 610 via MEF 630, for example, upon subscription or request from AF 610. Unless otherwise specified, MDR and MDR network entity are used interchangeably for ease of representation.

[0168] Mission instance repository (MIR) 620. MIR 620 stores mission instance information. This information describes instances of missions. Unless otherwise specified, MIR and MIR network entities are used interchangeably for ease of representation.

[0169] The Mission Control Function (MCF) 625 controls and coordinates mission execution on mission instances, including starting, pausing, resuming, stopping, and terminating mission execution. The MCF 625 starts, pauses, resumes, stops, or terminates mission execution based on requests from devices or AFs, or on specific events such as time events. The MCF 625 is responsible for establishing data plane paths between one or more CB instances within a mission instance and between mission participants (e.g., UEs) and one or more CB instances to facilitate mission execution. When coordinating mission execution, the MCF 625 triggers one or more executions of one or more CBs of the mission at appropriate times and coordinates access to mission execution by mission participants (e.g., devices). The MCF 625 can control mission execution in conjunction with relevant MM policies, which can be pre-configured at the MCF 625 or obtained by the MCF 625 from another control plane entity. Before terminating mission execution, the mission context related to the mission execution is maintained in both the control plane and data plane. In the absence of ambiguity, MCF and MCF network entity are used interchangeably for ease of representation, unless otherwise specified.

[0170] The Mission Exposure Function (MEF) 630 exposes MM capabilities (services) to the Application Firewall (AF) and authenticates / authorizes AF MM capability requests. Through the MEF, authorized AFs can influence the system's MM decisions. The MEF performs information mapping or parsing on information received from or sent to the AF. Possible information mapping includes mapping external task IDs to internal task IDs, mapping external device IDs to internal device IDs, etc. Possible information parsing includes resolving task intents into task specifications. Unless otherwise specified, the MEF and MEF network entity are used interchangeably for ease of representation.

[0171] Service Control Function (SCF) 635. SCF 635 assists MEF 630 in resolving task intent into task specifications. SCF 635 is also responsible for preparing resources within the corresponding service module, such as one or more control plane resources (TCF) and data plane resources (PSF). During task execution, the prepared resources are used to support the task's execution within the service module. Unless otherwise specified, SCF and SCF network entity are used interchangeably for ease of representation.

[0172] Task control function (TCF) 640. TCF 640 controls and coordinates the execution of tasks, including starting, stopping, and terminating task execution. TCF 640 starts, stops, or terminates task execution as part of task execution based on requests from MCF 625. MCF 625 notifies TCF 640 that a network entity (e.g., a device) is accessing / participating in task execution. Accordingly, TCF 640 can invite the network entity to access / participate in task execution at appropriate times (e.g., when task resources are ready), whereby the network entity can provide data to support task execution or receive data related to task execution. Before terminating task execution, the task context related to the task execution is maintained in the control plane and data plane of the service module. Unless otherwise specified, TCF and TCF network entity are used interchangeably for ease of representation.

[0173] The processing service function (PSF) 645 receives and processes data plane traffic. The PSF 645 can generate data plane traffic. The PSF 645 can send its received (possibly processed) or generated data plane traffic to other PSFs, DNs 660, or UEs 650 through one or more data plane gateways (also known as data gateways, GWs) 655. Data plane gateways are similar to user plane functions (UPFs) in 5G systems.

[0174] Figure 7 The process of NE access application is illustrated. For example... Figure 7 As shown, process 700 involves tasks (slices), task (slice) instances, task sessions, applications, and task execution.

[0175] An application residing in a DN can be a client of a task, providing application services to its users through task execution. A task can support more than one application. Tasks support applications through task instances. A task can act as an application, directly providing application services to application users; in this case, the application is considered to reside within the task. Authorized NEs use task sessions to access applications; these sessions are specific to the DN where the application resides and are supported by task instances. When an application resides within a task, the DN is an abstract DN corresponding to the task. A task instance can be used to support more than one application. Different instances of a task may support different applications.

[0176] exist Figure 7In this example, task (slice) 710 includes three types of task blocks (CBs): job CBs (subnets) 711, subtask CBs (subnets) 712, and external CBs (subnets) 713. To support one or more applications, task (slice) 710 needs to be instantiated as one or more task (slice) instances. In other words, tasks (slices) are instantiated as one or more task (slice) instances to support one or more applications. Figure 7 As can be seen, task (slice) 710 is instantiated as task (slice) instance 720. The task (slice) instance is used for the execution of task (slice) 710. Accordingly, task (slice) instance 720 includes: work CB (subnet) instance 721 corresponding to work CB (subnet) 711, subtask CB (subnet) instance 722 corresponding to subtask CB (subnet) 722, and external CB (subnet) instance 723 corresponding to external CB (subnet) 713. It is understood that task (slice) 710 can also be instantiated as other task (slice) instances. Furthermore, NE 730 accesses the application located in DN 740 through task (slice) instance 720.

[0177] To support an application using task instances as described above, a task session must be established on the task instance. During task session establishment, both the data plane (e.g., one or more data plane paths between one or more CB instances) and the control plane (e.g., one or more MCF 625s and one or more TCF 640s) are configured for the task session. After the task session is established, application-related data traffic can flow through the task instance and be processed under the coordination of the MM framework according to the task-related networking logic (if any). The process of coordinating data flow and processing is called task execution.

[0178] A task session is associated with one or more data sessions on the device. Each data session corresponds to a CB instance within a task instance, and the CB instance corresponds to the task's access point. When a task session is used to access an application, the device interacts with one or more corresponding CB instances using one or more data sessions. Interaction with one or more CB instances involves data traffic and control signals and is part of the task execution associated with the task session.

[0179] exist Figure 7 In the example, a task session is established on task (slice) instance 720. Furthermore, the task session is associated with one or more data sessions. More specifically, in this example, the task session is associated with a data session between NE 730 and work CB (subnet) instance 721, and another data session between NE 730 and subtask CB (subnet) instance 722, as shown below. Figure 7The solid line with double arrows indicates this. It can be understood that a data session can exist between the NE 730 and the external CB (subnet) instance, but... Figure 7 Not shown in the diagram. Furthermore, applications located in DN 740 can obtain support from task (slice) instances; for example, a subtask CB instance 722 has a session with DN 740, and an external CB instance 723 has another session with DN 740, such as... Figure 7 The dashed line with double arrows is shown in the middle.

[0180] Tasks are identified by a Mission ID (MID). The MID can take the form of a network slice ID. An MID can be associated with one or more CB IDs (CBIDs), each CBID identifying a CB within a task. When a CB is an external CB, the CBID identifying that CB can take the form of a DNN. When a CB is a subtask CB, the CBID identifying that CB can take the form of a MID. For example, when a task does not include a CB, the MID may not be associated with any CBID.

[0181] An instance of a task is identified by a Mission Instance ID (MIID). The MIID can take the form of a Network Slice Instance ID. An MIID can be associated with one or more CB Instance IDs (CBIIDs). Each of the one or more CBIIDs identifies a CB instance within the task instance. A CB instance is an instance of a CB within a task. When a CB is a subtask CB, the CBIID can take the form of an MIID. For example, when a task does not include a CB, the MIID may not be associated with any CBIID.

[0182] An application is identified by an Application ID (AID), and the services provided by the application are identified by an Application Service ID (ASID). ASIDs can be in the form of a Data Network Neural Network (DNN). A MIID can correspond to one or more ASIDs, indicating that a task instance identified by the MIID is associated with one or more applications identified by one or more ASIDs (i.e., used to support one or more applications identified by one or more ASIDs). In embodiments of this invention, both AID and ASID can identify an application. That is, ASID and AID are equivalent in this invention.

[0183] During the establishment of a task session for an application, a task instance associated with the application is selected. The selection of the task instance can be pre-configured or dynamically determined within the MM framework. In the former case, the MM framework identifies the task instance based on the application's ASID. In the latter case, the MM framework also uses Mission Selection Assistance Information (MSAI) to identify and select the task instance. MSAI can include a list of one or more MIDs or a list of one or more MIIDs. When the MSAI includes a list of one or more MIDs, the MM framework selects the instance of the task identified in that list. When the MSAI includes a list of one or more MIIDs, the MM framework selects the task instance identified in that list. Therefore, a task session can be globally identified using a combination of the application's ASID and the task instance's MIID.

[0184] A task session is established upon a request from an authorized device or AF. When requesting the establishment of a task session, the device or AF provides an ASID and MSAI. At the device, the task session is locally identified using a mission session ID (MSID), which is associated with a task session context. The task session context may include one or more data session IDs (DSIDs), each DSID identifying a data session associated with a working CB instance or DN CB instance within the task instance. The task session context may also include one or more MSIDs, each MSID identifying a task session corresponding to a subtask CB instance within the task instance.

[0185] Of the identifiers mentioned above, MSID, DSID, and ASID are understandable to the device. MID and CBID can be embedded in or mapped to other information such as MSAI, and are not directly understandable to the device. MIID and CBIID are network-side concepts and are not visible to the device.

[0186] As mentioned above, a task is associated with a task template that describes the task. For example, a task template includes one or more information elements, as shown in Table 1.

[0187] Table 1 Task Template

[0188] Each of the above information elements in the task template is described in detail below: MID identifies the task. This information can be in the form of a network slice ID. Please refer to the previous description for details.

[0189] Time validity conditions. This information indicates when a task is valid or available (i.e., can be executed) in terms of time. Time validity conditions can be represented by one or more time intervals or durations, each of which is associated with a start time and may also be associated with an end time. In some embodiments, each of the one or more time intervals or durations can be associated with a start time and / or an end time.

[0190] Spatial validity conditions. This information indicates where the task is valid or available (i.e., can be performed). Spatial validity conditions can be represented by a list of one or more area IDs, a list of one or more Public Land Mobile Network IDs (PLMN IDs), or a list of one or more cell IDs, or a combination thereof, where each area ID identifies a geographic area.

[0191] Reusability Indicator. This information indicates whether a task is reusable, that is, whether the task can be reused as a CB in another task. If the task is reusable, this information can also indicate, for example, who can reuse the task through a list including one or more identifiers and / or one or more wildcards. This information can indicate that the task can be used by any entity. When no reusability indicator is present, it indicates that the task is not reusable.

[0192] Application Indicator. This information identifies one or more applications and indicates whether the task can support those applications. One or more applications can be identified using one or more ASIDs and / or a list of one or more wildcards. This information can indicate that the task can support any application. If no application indicator is present, it means the task can support any application.

[0193] Interface Information. This information describes one or more interfaces through which a task can be accessed, and is generated by the MM. For an interface or a group of interfaces, the interface information may include an ID or name identifying the interface or group of interfaces, and indicating whether the interface or group of interfaces is one or more inbound interfaces or one or more outbound interfaces. Inbound interfaces are provided by the task, while outbound interfaces are provided by the network entity (e.g., device, AS, or NF) accessing the task.

[0194] Task Intent. This information describes the goal / intent of the task, which can be achieved by the task through its execution. The goal of the task can be described using application category information and service issue information. Note that task intent is also known as task intent information or task goal information.

[0195] Application category information, for example, identifies one or more application categories related to the task through a list including one or more application category IDs. Service issue information, for example, identifies one or more service issues related to the task through a list including one or more issue IDs.

[0196] Task intent information can also identify the target service, for example, by including a service ID. One or more application categories and one or more service issues identified in the task intent information are associated with the target service.

[0197] Task Specification. This information specifies the networking logic between one or more building blocks of the task used to achieve the task objectives indicated in the task intent information. This information may also indicate whether the task is a stateless task.

[0198] The task specification includes component information, workflow information, and access point information, which will be described further below. Any of these items is optional.

[0199] Composition information identifies one or more task blocks (CBs) for a task, and if the task includes multiple CBs, specifies one or more interconnections between the multiple CBs. For each CB, composition information may also indicate one or more associated task parameters. For a working CB, composition information (e.g., using a module ID) indicates the corresponding supporting service module. For an external CB, composition information (e.g., using a DNN) indicates the corresponding supporting DN. For a subtask CB, composition information (e.g., using a MID) indicates the corresponding task. When specifying an interconnection between two CBs, this information can describe the interface between the two CBs. For a CB, composition information can indicate whether the CB is a stateless CB.

[0200] Workflow information specifies the networking logic between CBs identified in the composition information, such as the order or timing of CBs. This information can indicate which CB(s) comes after or before which other CB(s).

[0201] Access point information specifies one or more access points for a task, each access point being a task's CB and identified by a CBID. When specifying an access point, this information may, for example, indicate one or more interfaces associated with that access point as described in the interface information by including one or more IDs or names that identify one or more interfaces.

[0202] The above reference Figure 6 and Figure 7 This section describes the structure of task management and some concepts related to tasks. The process of creating a task will be described below.

[0203] In some embodiments, AF 610 may request management of a task. More specifically, AF 610 obtains descriptive information about the task and sends a request to MEF 630. The request sent by AF 610 includes descriptive information about the task, and the request instructs management related to the task. For ease of description and to distinguish between different tasks (e.g., tasks to be created and tasks to be removed), the task to be managed is referred to as the first task, and the descriptive information is referred to as the first descriptive information.

[0204] In some embodiments, the first description information may be part of a task template for a first task. In other words, the first description information includes at least one element of the task template described in Table 1. For example, the first description information includes at least one of the following: a time validity condition indicating when the first task is valid; a space validity condition indicating where the first task is valid; a reusability indicator indicating whether the first task can be used as a computing block (CB) in another task; an application indicator indicating at least one application that the first task can support; interface information describing the interface through which the first task can be accessed; task intent information describing the task intent of the first task; a task specification describing the interoperability logic between one or more CBs used to implement the task intent described in the task intent information; or at least one task parameter that needs to be specified and corresponding metadata describing the use of the at least one task parameter.

[0205] In some embodiments, management related to the first task includes modifying at least one element of the first description information of the first task (e.g., at least one element of the task template). For example, changing the time validity condition from one time interval (or duration) to another time interval (or duration). Or, changing the reusability indicator from indicating that the first task can be used as a CB in another task to indicating that the first task cannot be used as a CB in another task. That is, changing the reusability indicator from indicating that the first task is reusable to indicating that the first task is not reusable.

[0206] In some embodiments, management related to the first task includes: creating the first task, and more specifically, creating second description information based on the first description information. For example, the first description information includes task intent information for the first task, but does not include task specifications. In this case, creating the second description information includes at least: creating task specifications for the first task based on the task intent. The process of parsing (in other words, converting or transforming) the task intent into task specifications will be described in more detail below.

[0207] The following is for reference. Figure 8 , Figure 8Signaling diagram 800 for a creation / update task according to some embodiments of the present invention is shown. Signaling diagram 800 relates to AF 610, MDR 615, MIR 620, MEF 630, and SCF 635. Figure 8 In the diagram, SCF 1 is shown as SCF6351, and SCF 2 is shown as SCF 6352. The nature of AF 610 is not limited. In some embodiments, any network entity such as CPF, AS, or device can act as AF.

[0208] like Figure 8 As shown, when AF 610 requests the creation of a task (e.g., the first task), a task template (or at least a portion of a task template) is provided from the authorized AF 610, and this task template is stored in MDR 615. The task template is associated with a task. The process of creating a task includes one or more of the following steps: In step 810, AF 610 sends an AF request to MEF 630 to create / update a task (e.g., the first task). Accordingly, MEF 630 receives the AF request. The AF request includes a task template associated with the task. The contents of the task template are described in Table 1.

[0209] In some embodiments, the AF request may include a portion of the task template for the task as described above. For example, the AF request may include task intent information for the first task. AF 610 obtains a portion of the task template from MDR 615.

[0210] The AF request includes the first descriptive information as described above. Figure 8 In this example, the task template included in the AF request corresponds to the first description information.

[0211] In this invention, the AF request is also referred to as the first request. In other words, step 810 is also referred to as sending a first request to the MEF 630, the first request including first descriptive information about the first task, which may instruct the creation of the first task.

[0212] In step 820, MEF 630 verifies the task template in the AF request. In other words, since the task is referred to as the first task, and the task template in the AF request corresponds to the first descriptive information about the first task, MEF 630 verifies the first descriptive information in this step.

[0213] In some embodiments, when the AF request is to create a task, the first description information fails validation if it meets predefined conditions. For example, the predefined conditions include at least one of the following: the first description information does not include task intent information or task specifications; the first task includes a subtask computing block (CB) and the subtask computing block corresponds to a non-reusable task; or the first task is deprecated.

[0214] In other words, the task template in the AF request is invalid in the following cases.

[0215] Case 1: If the task template in the AF request does not include either task intent information or task specifications, then the task template is invalid.

[0216] Scenario 2: If a subtask of the task identified in the task template does not correspond to an existing reusable task, the task template is invalid. It is understood that a subtask of a task refers to a subtask CB of the task. In some embodiments, if a task includes a subtask CB, and the subtask CB corresponds to an existing reusable task, then the subtask CB is valid, and correspondingly, the task including the subtask CB is also valid. Otherwise, the subtask CB is invalid, and the task including the subtask CB is also invalid. If a task includes multiple subtask CBs, the task is valid only if each of the multiple subtask CBs corresponds to an existing reusable task. Otherwise, if any one of the multiple subtask CBs does not correspond to an existing reusable task, the task is invalid. In some embodiments, the MEF 630 can interact with the MDR 615 to check whether a subtask corresponds to an existing reusable task. In other words, the MEF 630 can interact with the MDR 615 to check whether one or more subtask CBs correspond to one or more existing reusable tasks.

[0217] Scenario 3: If the task is deprecated, the task template is invalid. In this invention, if a task has been logically deleted, the task is deprecated or abolished. The details of logical deletion of tasks will be further described below.

[0218] In some embodiments, if the first description information fails to be verified, the MEF 630 sends a first response to the AF 610 indicating that the first request has been rejected.

[0219] In this case, the first response also includes a reason for rejection. This reason corresponds to a predefined condition satisfied by the first description. That is, the reason may include one of the following: the first description information does not include task intent information or task specifications; the first task includes subtask computation blocks and the subtask computation blocks correspond to non-reusable tasks; or the first task is deprecated.

[0220] In other words, if the task template is invalid, MEF 630 will reject the AF request and indicate the rejection to AF 610 by sending a response sent to AF 610 (step 870), without executing steps 820 to 860.

[0221] In some embodiments, when the AF request is to create a task, if the first description information is valid, and if the first description information includes task intent information but does not include task specifications, then MEF 630 will perform the following steps 830 to 860 to obtain the task specifications according to the task intent.

[0222] In step 830, MEF 630 resolves (in other words, converts or transforms) the task intent into a task specification.

[0223] In some embodiments, if the task template does not include task specifications but includes task intent information, the MEF630 uses SCF 635, such as SCF 1 (e.g., ...). Figure 8 SCF 6351 and / or SCF 2 (as shown) Figure 8 The SCF 6352 shown resolves (in other words, transforms or converts) the task intent into a task specification. In some embodiments, SCF 1 (SCF 6351) is associated with a first target service, and SCF 2 (SCF 6352) is associated with a second target service. The first target service may be different from the second target service. Therefore, MEF 630 can use different SCFs to resolve different task intents. Specifically, step 830 includes at least one of the following sub-steps: In step 8301, MEF 630 sends an intent resolution request to SCF 635. Accordingly, SCF 635 receives the request. SCF 635 is associated with the target service indicated in the task intent information. Here, task intent information refers to the task intent information included in the first description information (e.g., the task template included in the AF request). More specifically, the request is sent to, as... Figure 8The SCF 1 shown is SCF 6351. In this invention, SCF 1 is also referred to as the first SCF, and SCF 2 is also referred to as the second SCF. Furthermore, the intent resolution request in this step is also referred to as the second request. In other words, in step 8301, MEF 630 sends a second request to SCF 1 instructing the generation of task specifications. Accordingly, SCF 1 receives the second request from MEF 630.

[0224] In some embodiments, the intent resolution request (also known as the second request) includes task intent information from the task template.

[0225] In some embodiments, the intent resolution request may include a MID that identifies a task (e.g., a first task). The MID may be included in a task template as indicated in the AF request received by MEF 630 in step 810, or the MID may be generated by MEF 630.

[0226] In step 8302, SCF 1 (SCF 6351) processes the task intent and generates a task specification draft based on the task intent. In this invention, the task specification draft is also referred to as the first task specification or the first draft.

[0227] In some embodiments, SCF 1 (SCF 6351) determines one or more computing blocks (CBs) of a first task and the networking logic between the one or more CBs. Furthermore, SCF 1 (SCF 6351) generates a first task specification. The first task specification generated by SCF 1 includes the computing block ID (CB ID) of each CB in the one or more CBs and the networking logic. In other words, SCF 1 (SCF 6351) determines the CBs of the task and the networking logic between the CBs of the task. The task specification draft generated by SCF (i.e., the first task specification) describes the CBs and the networking logic. The task specification draft includes information similar to that described in Table 1.

[0228] In this step, the SCF (e.g., SCF 1) can interact with the MDR 615, for example, to obtain task templates for existing reusable tasks, thereby determining whether the task's CB corresponds to an existing reusable task. The SCF (e.g., SCF 1) can determine that the task's CB is a subtask to be created.

[0229] In step 8303, SCF 1 responds to MEF 630. This response is an intent resolution response. The intent resolution response includes a draft mission specification. In this invention, the intent resolution response in this step is also referred to as the second response. In other words, in this step, SCF 1 sends a second response to MEF 630 that includes the first mission specification.

[0230] In some embodiments, if a subtask to be created is determined in step 8302, the intent parsing response includes a subtask template associated with the subtask. The subtask template is a task template describing the subtask, including the information elements of the subtask described in Table 1.

[0231] In step 8304, MEF 630 sends an intent resolution confirmation to SCF (e.g., SCF 1), indicating that the draft task specification has been accepted. The intent resolution confirmation includes a MID, which is the MID included in the intent resolution request. This step can be a delayed step, for example, it can be performed after step 8305. In this invention, the intent resolution confirmation sent by MEF 630 is also referred to as a first confirmation. Accordingly, step 8304 refers to MEF 630 sending a first confirmation to SCF 1, wherein the first confirmation indicates that the first task specification has been accepted.

[0232] Based on intent resolution, the SCF (e.g., SCF 1) knows that the task specification draft (generated in step 8302) is part of the task specification corresponding to the MID.

[0233] Please note that the task specification corresponding to the MID is the task specification described in step 850. Therefore, the task specification draft generated in step 8302 can be part of the task specification described in step 850. More specifically, if SCF 1 determines that there are no subtasks for which the task does not need to be created, the task specification draft can become (or be, or be used as) the task specification corresponding to the MID. If SCF 1 determines that there are one or more subtasks (i.e., one or more subtasks CB) for which the task needs to be created, the task specification draft can become (or be, or be used as) part of the task specification corresponding to the MID. In this case, MEF 630 will perform the following step 840 to further parse the subtask intent of the subtask to be created.

[0234] In step 840, MEF 630 parses the subtask intent, for example, the subtask intent of the subtask mentioned above.

[0235] In some embodiments, if the first task specification includes a computation block ID of a subtask computation block corresponding to another task to be created (also referred to as a third task in this invention) and subtask intent information corresponding to the third task, wherein the subtask intent information describes the subtask intent, then in this case, the MEF 630 parses the subtask intent in step 840.

[0236] In some embodiments, the MEF 630 uses an SCF, such as SCF 2 (e.g., Figure 8The MEF 630 performs step 840 by sending an intent resolution request (also known as a third request) to the SCF 6352, which is associated with the target service indicated in the subtask intent information. More specifically, the MEF 630 sends an intent resolution request to the SCF 2, which instructs the generation of a subtask specification and includes subtask intent information. The subtask specification describes the networking logic between one or more computing blocks that implement the subtask intent.

[0237] Specifically, if MEF 630 receives a subtask template in step 830, MEF 630 uses the subtask template as a task template and performs step 830 on the subtask template to parse the corresponding subtask intent information (i.e., the task intent information in the subtask template) into a task specification.

[0238] Accordingly, SCF 2 processes the subtask intent to generate a subtask specification, which is also referred to in this invention as a second task specification or a second draft. That is, SCF 2 generates the second task specification based on the subtask intent. SCF 2 sends a third response, including the second task specification, to MEF 630. Accordingly, MEF 630 receives the second task specification from SCF 2.

[0239] Since the first task specification can be considered as part of the task specification corresponding to the task intent, the second task specification is considered as another part of the task specification. Similarly, MEF 630 can send an intent resolution confirmation to SCF 2, indicating that the second task specification has been accepted. This intent resolution confirmation sent to SCF 2 is also referred to as the second confirmation in this invention. In other words, MEF 630 can send a second confirmation to SCF 2, whereby the second confirmation indicates that the second task specification has been accepted.

[0240] In some embodiments, the first task specification may correspond to a first CB, and the second task specification may correspond to a second CB. These two CBs may be identified by two different CB IDs. The first CB ID and the second CB ID may be generated by SCF 1 (SCF6351) and included in the first task specification sent from SCF 1 to MEF 630 in step 8303.

[0241] In some embodiments, if the first task specification includes multiple computing block IDs (CB IDs) of multiple subtask computing blocks corresponding to multiple tasks to be created, and multiple subtask intents corresponding to multiple tasks, then the MEF 630 parses the multiple subtask intents. In other words, if the MEF 630 receives multiple subtask templates, the MEF 630 treats each subtask template as a task template and performs step 830 for the corresponding subtask template to parse the corresponding subtask intent into a task specification. In some embodiments, the MEF 630 can interact with different SCFs to parse different subtask templates. For example, the MEF 630 can interact with SCF 2 to parse one subtask template and with SCF 3 to parse another subtask template.

[0242] In some embodiments, if SCF 1 determines that one or more CBs of a task correspond to one or more non-existent and yet-to-be-created subtasks, SCF 1 can interact with other SCFs (e.g., SCF 2 and SCF 3) to parse one or more subtask intents of the one or more subtasks. In this case, SCF 1 can obtain one or more subtask specifications corresponding to the one or more subtask intents from the other SCFs. For example, for a CB corresponding to a non-existent and yet-to-be-created subtask, SCF 1 can send the subtask intent of that subtask to another SCF (e.g., SCF 2 or SCF 3), and after the other SCF parses the subtask intent, the other SCF can send the corresponding subtask specification to SCF 1. Furthermore, MEF 630 obtains the subtask specification from SCF 1.

[0243] In step 850, MEF 630 generates the task specification based on the first draft (the task specification draft received in step 830) and the second draft (the task specification draft received in step 840). In other words, MEF 630 generates the task specification based on the first task specification and the second task specification.

[0244] For example, MEF 630 performs this step by integrating the second draft into the first draft, such that the corresponding subtask's CB is directly included as a CB in the task, and the networking logic between CBs is directly included in the networking logic corresponding to the task. After this step, the first draft becomes the task specification, and the subtasks no longer appear in the task specification.

[0245] In some embodiments, generating a task specification may include: processing a first task specification and / or a second task specification such that the generated task specification includes the processed first task specification and / or the processed second task specification.

[0246] Please note that this step (step 850) is optional. If step 840 is not performed, the draft task specification received in step 830 can be used as the task specification. In other words, if step 840 is not performed, the first task specification will be used as or become the task specification.

[0247] In step 860, MEF 630 updates the task (slice) template. Specifically, MEF 630 includes the task specification in the task template and stores the task template in MDR 615.

[0248] In some embodiments, MEF 630 obtains second description information about the first task. The second description information includes the generated task specification. Furthermore, the second description information may also include the MID generated by MEF 630 and other information related to the first task. MEF 630 sends the second description information about the first task to MDR 615, and MDR 615 stores the second description information.

[0249] In step 870, MEF 630 responds to the AF request from AF 610. This response indicates that the AF request is accepted. The response may include MID.

[0250] In Figure 8 In a related embodiment, the AF (Action Function) can provide the system with a task template associated with the task. For example, when the AF is a capable AF that can determine task specifications, the task template provided by the AF may include task specifications. In some embodiments, the task template provided by the AF does not include task specifications; in this case, the system will generate the task specifications for the task based on the task intent information in the task template. This shifts the task of determining the task specifications from the AF to the system, allowing the use of a less capable AF.

[0251] The above Figure 8 The process of providing task information is shown in the diagram. The process of removing the task (slice) template will be described below.

[0252] Figure 9 It shows that according to Figure 7 The illustrated process involves removing task (slice) templates from the architecture shown. This process applies to AF 610, MDR 615, MIR 620, and MEF 630.

[0253] like Figure 9As shown, the authorized AF 610 can request the removal of a task. When a task is removed, the task template associated with the task is removed from MDR 615. This process assumes that MDR 615 maintains information about whether a task has instances, such as an instance count indicating the number of one or more instances of the task, or a set of instance IDs. In this invention, the task to be removed is also referred to as a second task. Removing a task corresponds to removing descriptive information about the task, such as removing the task template of the second task. The process includes one or more of the following steps: In step 910, AF 610 sends an AF request to MEF 630 to remove the task. Accordingly, MEF 630 receives the AF request from AF 610. The AF request includes the MID identifying the task.

[0254] In some embodiments, tasks can be created upon request from AF 610 to support an application. AF 610 can be associated with an application, for example, to manage / control the operation / execution of the application. When the application no longer needs support, for example, upon request from AF 610, the task can be removed.

[0255] In this invention, to facilitate the differentiation of different AF requests, the AF request in step 910 is also referred to as the fourth request. That is, in this step, AF 610 sends a fourth request to MEF 630, which instructs the removal of the second task, and the fourth request includes a second task ID that identifies the second task.

[0256] In some embodiments, MEF 630 can obtain fourth descriptive information about the second task based on the second task ID. For example, MEF 630 can send the second task ID to a target network entity (e.g., MDR 615), and MEF 630 can obtain the fourth descriptive information from the target network entity. If the fourth descriptive information satisfies predefined conditions, MEF 630 can send a response to AF 610, wherein the response indicates that the fourth request has been rejected.

[0257] In some embodiments, the predefined conditions include: fourth descriptive information about the second task indicating that the second task is a reusable task and is being used.

[0258] In other words, if a task (i.e., the second task) is reusable and is being used in another task (as a subtask) (i.e., corresponding to subtask CB in another task), the MEF 630 can reject the AF request in this step. The MEF 630 can interact with the MDR 615 to obtain information about whether the task is reusable and whether it is being used in another task (as a subtask). For example, the MEF 630 sends a message to the MDR 615. The task includes MID. In response, the MDR 615 sends a message to the MEF 630. The MEF 630 rejects the AF request based on this message. When the MEF 630 rejects the AF request, it sends a response to the AF 610 indicating the rejection. The response sent to the AF 610 may include information indicating the reason for the AF request being rejected, such as the reason being that the task is reusable and is being used in another task (as a subtask).

[0259] In step 920, MEF 630 requests MDR 615 to remove the task template associated with the task by sending a task template removal request to MDR 615. This request includes the MID.

[0260] In this invention, the task template removal request is also referred to as the fifth request. That is, in this step, MEF 630 sends a fifth request to MDR 615, wherein the fifth request includes the MID (e.g., the MID of the second task) and instructs the removal of the third descriptive information about the task (e.g., the second task).

[0261] In step 930, after receiving the task template removal request, the MDR 615 subscribes to receive notifications about changes to task instance information related to the task. This step is optional if the MDR 615 is already subscribed to receiving notifications.

[0262] In this step, MDR 615 sends a subscription request indicating subscription to MIR 620, which includes MID. In this invention, the subscription request is also referred to as the sixth request.

[0263] In some embodiments, MIR 620 responds to MDR 615, indicating that the subscription is accepted. In this response, MIR 620 may indicate whether the task identified by the MID has a task instance.

[0264] In some embodiments, MDR 615 can indicate whether the subscription is for receiving continuous or non-continuous (in other words, one-time) notifications. If the subscription is for receiving continuous notifications, MIR 620 will notify MDR 615 whenever a task instance is created or removed, for example, in step 970. When notifying MDR 615, MIR 620 may include the corresponding task instance ID in the notification. If the subscription is for receiving non-continuous notifications, MIR 620 will notify MDR 615 in the response sent to MDR 615 whether a task instance has been created or removed, and may include the corresponding task instance ID in the response. In this invention, the notification sent by MIR 620 is also referred to as the sixth response. That is, the sixth response can be a continuous response or a one-time response.

[0265] In step 940, MDR 615 uses MID to identify the task template associated with the task and updates the task template.

[0266] In some embodiments, MDR 615 determines whether a task is associated with a task instance (in other words, whether it has a task instance) based on a response indicating whether the task identified by the MID has a task instance as described above.

[0267] In some embodiments, MDR 615 determines whether a task is associated with a task instance (in other words, whether it has a task instance) based on a notification (i.e., a sixth response). More specifically, MDR 615 determines the number of existing instances of a task based on one or more task instance IDs received in the notification and information changes associated with one or more task instance IDs (i.e., whether any corresponding task instances have been created or removed); if the number is equal to 0, MDR 615 determines that the task has no task instances.

[0268] In some embodiments, if the task has a task instance, when the task template is updated, MDR 615 logically deletes the task template, for example, by associating a tag or indication with the task template. After logical deletion, the task template remains in memory, but the task is considered obsolete or deprecated, and no new task instance should be created for the task.

[0269] In some embodiments, if there is no task instance, the MDR 615 deletes the task template from memory. This is the opposite of the logical deletion described above; it is a physical deletion, after which the task template is considered removed.

[0270] In step 950, MDR 615 sends a task (slice) template removal response.

[0271] In some embodiments, MDR 615 responds to MEF 630. According to step 940, this response indicates whether the task template was physically or logically deleted.

[0272] In this invention, the task (slice) template removal response is also referred to as the fifth response.

[0273] In step 960, MEF 630 responds to AF 610's AF request. The response sent to AF 610 may include MID. This step is optional.

[0274] In some embodiments, if the response in step 950 indicates physical deletion, then the response in step 960 indicates that the task has been removed. If the response in step 950 indicates logical deletion, then the response in step 960 includes a deprecation indication that the task has been deprecated, or the response includes deprecation information indicating that the task has been deprecated.

[0275] In this invention, the response in this step is also referred to as the fourth response. In other words, AF 610 receives a fourth response from MEF 630, wherein the fourth response indicates that the second task is deprecated or terminated if the third description information regarding the second task is deleted via / through logical deletion (as described above). In some embodiments, logical deletion indicates that the third description information is stored in memory and has been processed. Alternatively, if the third description information regarding the second task is deleted via / through physical deletion (as described above), the fourth response may indicate that the second task is removed. In some embodiments, physical deletion indicates that the third description information is removed from memory. After physical deletion, the second task is no longer available. The third description information in this embodiment refers to the task template of the second task described in Table 1.

[0276] Corresponding to step 930, in step 970, MIR 620 sends a notification regarding the task instance. Accordingly, MDR 615 receives a notification from MIR 620 regarding changes to the task instance information, indicating that the task instance has been removed. This notification may include the MIID identifying the task instance. Based on the notification, MDR 615 updates its locally maintained information about whether the task has instance knowledge, for example, by decrementing the instance count by 1 or by removing the MIID from the set of instance IDs. This step is optional.

[0277] In step 980, MDR 615 removes the task (slice) template.

[0278] If there are no more task instances for the task (e.g., if the instance count is 0, or if the set of instance IDs is empty, excluding MIIDs), in other words, if all task instances for the task have been removed, the MDR deletes the task template associated with the task from storage. After deletion (physical deletion), the task is considered removed. This step is optional.

[0279] In some embodiments, steps 970 and 980 are performed if the task has been logically deleted.

[0280] In step 990, MDR 615 unsubscribes from receiving notifications from MIR 620 regarding changes to task instance information related to the task. This step is optional, for example, if MDR 615 is not subscribed to receiving notifications.

[0281] In this step, MDR 615 sends an unsubscribe request to MIR 620, which includes the MID. MIR 620 responds to MDR 615, indicating that the unsubscribe is accepted.

[0282] In step 991, MDR 615 sends an information change notification. Accordingly, MEF 630 receives this notification. This notification includes the MID and a removal instruction indicating that the task has been removed. This step is optional if step 980 is not performed.

[0283] In step 992, MEF 630 notifies AF 610 that the task has been removed. This notification includes the MID and a removal instruction indicating that the task has been removed.

[0284] In combination Figure 9 In the described embodiment, task templates associated with a task can be dynamically and securely removed based on a request from the Task Allocation Filter (AF). Removal is performed in two steps: logical deletion (deprecation / abolishment) and physical deletion. A notification regarding deprecation / abolishment is sent to the AF so that no new instances of the task are created or requested. Physical deletion is performed after all task instances of the task have been removed. Therefore, dynamically removing task templates does not affect the use of existing task instances of the task.

[0285] Figure 10A flowchart of a method performed by an AF network entity according to some embodiments of the present invention is shown. In step 1010, the AF obtains first description information about a first task, wherein the first description information includes at least one of the following: a time validity condition indicating when the first task is valid; a spatial validity condition indicating where the first task is valid; a reusability indication indicating whether the first task can be used as a computing block (CB) in another task; an application indication indicating at least one application that the first task can support; interface information describing an interface through which the first task can be accessed; task intent information describing the task intent of the first task; a task specification describing the interoperability logic between one or more CBs for implementing the task intent described in the task intent information; or at least one task parameter that needs to be specified. In step 1020, the AF sends a first request to a Task Open Function (MEF) network entity, wherein the first request includes the first description information about the first task and the first request indicates management related to the first task.

[0286] Figure 11 Another flowchart of a method performed by an AF network entity according to some embodiments of the present invention is shown. In step 1110, AF 610 sends a fourth request to Task Open Function (MEF) network entity 630, wherein the fourth request indicates the removal of a second task, and the fourth request includes a second task ID identifying the second task. In step 1120, AF 610 receives a fourth response from MEF network entity 630, wherein the fourth response indicates that the second task is deprecated if third descriptive information about the second task is deleted by logical deletion, wherein logical deletion indicates that the third descriptive information is stored in memory and has been processed.

[0287] Figure 12A flowchart illustrating a method performed by a MEF network entity according to some embodiments of the present invention is shown. In step 1210, MEF 610 receives a first request from an Application Function (AF) network entity, wherein the first request includes first descriptive information about a first task, and the first request indicates management related to the first task. The first descriptive information includes at least one of the following: a time validity condition indicating when the first task is valid; a spatial validity condition indicating where the first task is valid; a reusability indication indicating whether the first task can be used as a computing block (CB) in another task; an application indication indicating at least one application that the first task can support; interface information describing an interface through which the first task can be accessed; task intent information describing the task intent of the first task; task specification information describing the interoperability logic between one or more CBs of the first task for implementing the task intent described in the task intent information; or at least one task parameter that needs to be specified. In step 1220, MEF 630 obtains second descriptive information about the first task, wherein the second descriptive information is generated based on the first descriptive information.

[0288] Figure 13 A flowchart illustrating a method performed by a MEF network entity according to some embodiments of the present invention is shown. In step 1310, MEF 630 receives a fourth request from Application Function (AF) network entity 610, wherein the fourth request instructs the removal of a second task, and the fourth request includes a second task ID identifying the second task. In step 1320, MEF 630 sends a fifth request to Task Data Repository (MDR) network entity 615, wherein the fifth request includes the second task ID and instructs the removal of third descriptive information about the second task.

[0289] Figure 14 A flowchart illustrating a method performed by an SCF network entity according to some embodiments of the present invention is shown. In step 1410, SCF 635 receives a second request from Mission Open Function (MEF) network entity 630, wherein the second request instructs the generation of a mission specification and includes mission intent information describing the objective of a first mission; in step 1420, SCF 635 sends the first mission specification to MEF network entity 630, wherein the first mission specification is generated by the SCF network entity based on the mission intent information included in the second request.

[0290] Figure 15A flowchart illustrating a method performed by an MDR network entity according to some embodiments of the present invention is shown. In step 1510, MDR 615 receives a fifth request from a Mission Open Function (MEF) network entity 630, wherein the fifth request includes a second task ID identifying a second task and instructing the removal of third descriptive information about the second task; in step 1520, MDR 615 sends a fifth response to the fifth request to the MEF network entity 630, wherein the fifth response indicates the deletion type of the third descriptive information, the deletion type including physical deletion or logical deletion, physical deletion indicating that the third description is removed from memory, and logical deletion indicating that the third descriptive information is stored in memory and has been processed.

[0291] Some embodiments of the present invention provide a network device. The network device 1600 is used to perform some steps of the task management method described in the above embodiments / implementations. For example... Figure 16 As shown, network device 1601 includes a processing module 1601 and a communication module 1602. The processing module 1601 is used to process data units / signals. The communication module 1602 is used to transmit (send) and / or receive data units / signals.

[0292] For example, communication module 1602 may include one or more communication interfaces. Communication module 1602 may be a transceiver module for implementing send and / or receive functions. In this case, communication module 1602 may be an input / output interface or a transceiver.

[0293] In some examples, network device 1600 corresponds to AF 610 and performs... Figure 8 Steps 810 and 870 of the method are described above. In this case, the communication module 1602 performs steps 810 and 870.

[0294] In other examples, network device 1600 corresponds to AF 610 and performs... Figure 10 Steps 1010 and 1020 of the method. In this case, communication module 1602 executes step 1020, and processing module 1601 executes step 1010.

[0295] In some other examples, network device 1600 corresponds to AF 610 and performs... Figure 9 Steps 910, 960, and 992 of the method are described. In this case, the communication module 1602 performs steps 910, 960, and 992.

[0296] In some other examples, network device 1600 corresponds to AF 610 and performs... Figure 11 Steps 1110 and 1120 of the method are described above. In this case, the communication module 1602 performs steps 1110 and 1120.

[0297] In some other examples, network device 1600 corresponds to MEF 630 and performs... Figure 8 Steps 810, 820, 8301, 8303, 850, 860, and 870 of the method. In this case, the communication module 1602 performs steps 810, 8301, 8303, and 870, and the processing module 1601 performs steps 820, 850, and 860.

[0298] In some other examples, network device 1600 corresponds to MEF 630 and performs... Figure 12 Steps 1210 and 1220 of the method. In this case, communication module 1602 performs step 1210, and processing module 1601 performs step 1220.

[0299] In some other examples, network device 1600 corresponds to MEF 630 and performs... Figure 9 Steps 910, 920, 950, 960, 991, and 992 of the method. In this case, the communication module 1602 performs steps 910, 920, 950, 960, 991, and 992.

[0300] In some other examples, network device 1600 corresponds to MEF 630 and performs... Figure 13 Steps 1310 and 1320 of the method are described above. In this case, the communication module 1602 performs steps 1310 and 1320.

[0301] In some other examples, network device 1600 corresponds to SCF 635 (e.g., SCF 1 and / or SCF 2) and performs... Figure 8 Steps 8301, 8302, 8303, 8304, and 840 of the method. In this case, the communication module 1602 executes steps 8301, 8303, and 8304, and the processing module 1601 executes steps 8302 and 840.

[0302] In some other examples, network device 1600 corresponds to SCF 635 (e.g., SCF 1 and / or SCF 2) and performs... Figure 14 Steps 1410 and 1420 of the method are described above. In this case, the communication module 1602 performs steps 1410 and 1420.

[0303] In some other examples, network device 1600 corresponds to MDR 615 and performs... Figure 9Steps 920, 930, 940, 950, 970, 980, 990, and 991 of the method. In this case, the communication module 1602 performs steps 920, 930, 950, 970, 990, and 991, and the processing module 1601 performs steps 940 and 980.

[0304] In some other examples, network device 1600 corresponds to MDR 615 and performs... Figure 15 Steps 1510 and 1520 of the method are described above. In this case, the communication module 1602 performs steps 1510 and 1520.

[0305] It should be noted that the details can be found in the description above, and will not be repeated here.

[0306] In some embodiments, the network device 1600 further includes a memory module 1603 for storing program instructions and / or data. The processing module 1601 can read the program instructions and / or data stored in the memory module 1603 to implement the above-described method.

[0307] It should be noted that the beneficial effects of the network device are the same as those of the task management method described in the above embodiments, and will not be repeated here.

[0308] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When the above embodiments are implemented by software programs, the software programs can be implemented, in whole or in part, in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the computer instructions generate a portion of the processes or functions provided in all the embodiments of the present invention. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or any other programmable device. Computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, computer instructions can be transferred from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave) methods. A computer-readable storage medium can be any available medium accessible to a computer, or a server, data center, or any other data storage device that includes one or more available media. The available media can be magnetic media (e.g., floppy disks, magnetic disks, or magnetic tapes), optical media (e.g., digital versatile disks (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0309] Through the description of the above embodiments, those skilled in the art will clearly recognize that, for the sake of convenience and brevity, the above functional module division is only used as an example. In practical applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the device can be divided into different functional modules to perform all or part of the above functions. The specific working process of the above system, device, and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0310] In the several embodiments provided in this invention, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the above device embodiments are merely exemplary. For example, the division of functional modules is only a logical functional division. In actual implementation, there may be other division methods. For example, in some embodiments, multiple devices or components may be merged or integrated into another system, or some features may be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or modules, and may be an electrical connection, a mechanical connection, or other forms of connection.

[0311] Modules described as individual components may or may not be physically separate, and components shown as modules may or may not be physical modules. That is, they may be located in one place or distributed across multiple network modules. Some or all modules can be selected according to actual needs to achieve the purpose of the solution in the embodiments.

[0312] In the embodiments of the present invention, the functional modules can be integrated into a single processing module; the module can also be a separate physical module; or two or more modules can be integrated into a single module. The integrated module can be implemented in hardware or as a software functional module.

[0313] If the integrated module is implemented as a software functional module and sold or used as an independent product, the integrated module can be stored in a readable storage medium. Based on this understanding, the technical solution of this invention, or all or part of the technical solution, can essentially be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this invention. The storage medium includes various types of media capable of storing program code, such as flash memory (USB flash drive), portable hard drives, read-only memory (ROM), random-access memory (RAM), magnetic disks, or optical disks.

[0314] Some embodiments of the present invention provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium). This computer-readable storage medium stores program instructions that, when executed on a network device / second task management device, cause the network device / second task management device to perform one or more steps of the task management method as described in any of the above embodiments.

[0315] For example, computer-readable storage media include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, or magnetic tapes), optical disks (e.g., compact disks (CDs) or DVDs), smart cards, and flash memory devices (e.g., erasable programmable read-only memory (EPROMs), cards, memory sticks, or key drives). The various computer-readable storage media described in embodiments of this invention can represent one or more devices and / or other machine-readable storage media for storing information. The term "computer-readable storage medium" can include, but is not limited to, wireless channels and various other media capable of storing, including, and / or carrying instructions and / or data.

[0316] Some embodiments of the present invention also provide a computer program product. This computer program product includes program instructions carried on a non-transitory computer-readable storage medium. When executed on a network device / second task management device, the computer program instructions cause the network device / second task management device to perform one or more steps of the task management method as described in the above embodiments.

[0317] The beneficial effects of computer-readable storage media and computer program products are the same as those of the task management methods described in the above embodiments, and will not be repeated here.

[0318] The above description is merely a specific implementation of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications or substitutions falling within the technical scope of the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0319] In some aspects of the invention, a computer program comprising instructions is provided. When executed by a processor, these instructions cause the processor to implement the method of the invention.

[0320] In some aspects of the invention, a non-transitory computer-readable medium is provided that stores instructions which, when executed by a processor, cause the processor to implement the method of the invention.

[0321] In some aspects of the present invention, a device / chipset system is provided, comprising components (e.g., at least one processor) for implementing the methods implemented by a UE (or at a UE) of the present invention. The device / chipset system may be a network entity as shown in the present invention, such as an AF, PCF, TCF, device (i.e., terminal device), or a module / component within a network entity. Specifically, at least one processor may execute instructions stored in a computer-readable medium to implement the described methods.

[0322] In some aspects of the invention, a system is provided that includes at least two of the network entities described above (e.g., AF, PCF, TCF, device) shown in the invention.

[0323] In some aspects of the present invention, a method is provided that is performed by a system comprising at least two of the network entities described above as shown in the present invention.

[0324] Please note that the two or more network entities shown in this invention can reside within a physical network entity or be implemented as a single functional entity. In this case, the interaction between the two or more network entities described above may not be required, i.e., one or more corresponding steps can be omitted (one or more corresponding steps are optional).

[0325] Please note that although two or more network entities are shown in this invention, for the exemplary embodiments of this invention, only one network entity may be sufficient. For example, in Figure 7 In the example shown, from the AF's perspective, only AF requests and responses are needed. AF cannot see the operations performed by other network entities (e.g., steps 3 through 5) (or the operations performed by other network entities may be transparent to AF).

[0326] The solutions described in this invention are applicable to next-generation (e.g., sixth generation, 6G or higher) networks, or traditional (e.g., 5G, 4G, 3G or 2G) networks.

[0327] It should be understood that any module, component, or device disclosing executable instructions herein may include or otherwise access one or more non-transitory computer / processor-readable storage media for storing information, such as computer / processor-readable instructions, data structures, program modules, and / or other data. A non-exhaustive list of examples of non-transitory computer / processor-readable storage media includes: magnetic tape cassettes, magnetic tape, disk storage, or other magnetic storage devices; compact disc read-only memory (CD-ROM), digital video disc or digital versatile disc (i.e., DVD), Blu-ray disc™, or other optical storage devices; volatile and non-volatile, removable and non-removable media, random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other storage technologies implemented in any method or technology. Any such non-transitory computer / processor storage medium may be part of a device or apparatus, or may be accessed or connected to a device or apparatus. Computer / processor-readable / executable instructions used to implement the methods, applications, or modules described herein may be stored by such non-transitory computer / processor-readable storage media or otherwise preserved.

[0328] It should be noted that the message in this invention can be replaced with information, which can be carried in a single message or in more than one single message.

[0329] In this invention, the term "instruct / indicate" may be used interchangeably with "request" unless otherwise explicitly stated in the content.

[0330] The terms “device” and “equipment” are used interchangeably.

[0331] In this invention, when used in conjunction with the term "comprising" in the claims and / or specification, the word "a" may mean "one," but it also has the same meaning as "one or more," "at least one," and "one or more," unless otherwise expressly stated. Similarly, the word "another" may mean at least a second or more, unless otherwise expressly stated.

[0332] In this invention, when used before the same term (e.g., ED or operational step), the words "first," "second," etc., do not imply an order or sequence of the terms. For example, without specific indication, "first ED" and "second ED" refer to two different EDs; similarly, without specific indication, "first step" and "second step" refer to two different operational steps, but this does not mean that the first step must occur before the second step. The actual order depends on the logic of the two steps.

[0333] The terms “coupling” or “connection” as used herein may have several different meanings depending on the context in which they are used. For example, the terms “coupling” or “connection” as used herein may mean that two elements or devices are directly connected to each other or connected to each other via mechanical elements through one or more intermediate elements or devices, depending on the specific context.

[0334] Please note that the expression "at least one of A or B" used in this document is interchangeable with the expression "A and / or B". This expression refers to a list in which you can choose either A or B, or A and B. Similarly, the expression "at least one of A, B, or C" used in this document is interchangeable with "A and / or B and / or C" or "A, B, and / or C". This refers to a list in which you can choose: A or B or C, or A and B, or A and C, or B and C, or all of A, B, and C. The same principle applies to longer lists with the same format.

[0335] This invention includes various embodiments, not only method embodiments but also other embodiments, such as apparatus embodiments and embodiments related to non-transitory computer-readable storage media. Embodiments may individually or in combination include the features disclosed herein.

[0336] The terms “receive,” “detect,” and “decode” as used herein may have several different meanings depending on the context in which they are used. For example, without specific indication, the term “receive” may mean that information (e.g., DCI or MAC-CE, RRC signaling, or TB) has been successfully received by the receiving node, meaning that the receiving side correctly detected and decoded the information. In this scenario, “receive” can include both “detect” and “decode,” or it may mean the same thing; for example, “receive paging” means that the paging was correctly decoded and successfully retrieved, and correspondingly, “received paging” means that the receiving side did not detect and / or decode the paging. For example, “not received paging” means that the receiving side attempted to detect and / or decode the paging but failed to retrieve it. The term “receive” may sometimes mean that a signal has arrived at the receiving side, but this does not necessarily mean that the information in the signal has been correctly detected and decoded. In this case, the receiving side needs to detect and decode the signal to obtain the information carried in the signal. In this scenario, “receive,” “detect,” and “decode” may represent different processes by which the receiving side obtains information. Although the invention has referenced illustrative embodiments, it is not intended to be interpreted in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to those skilled in the art upon reference to this specification. When combining two or more embodiments, not all features of the embodiments to be combined are necessary for the combination.

[0337] Alternatively or additionally, features disclosed herein in the context of any particular embodiment may be implemented in other embodiments. For example, alternatively or additionally, method embodiments may be implemented in apparatus, system, and / or computer program product embodiments. Furthermore, although embodiments have been described primarily in the context of methods and apparatus, other implementations are contemplated, such as instructions stored on one or more non-transitory computer-readable media. Such media may store programs or instructions to perform any of the methods consistent with the present invention.

Claims

1. A method performed by an application function (AF) network entity, characterized in that, The method includes: Obtain first descriptive information about the first task, wherein the first descriptive information includes at least one of the following: The time validity condition indicates when the first task is valid; Spatial validity conditions indicate where the first task is valid; Reusability indicator, indicating whether the first task can be used as a computation block CB in another task; Application indication, indicating at least one application supported by the first task; The interface information describes the interface through which the first task can be accessed; Task intent information, describing the task intent of the first task; The task specification describes the communication logic between one or more task blocks (CBs) of the first task, wherein the one or more CBs are used to implement the task intent described in the task intent information; or At least one task parameter to be specified; A first request is sent to the MEF network entity that provides the mission opening function, wherein the first request includes the first description information about the first mission, and the first request instructs management related to the first mission.

2. The method according to claim 1, characterized in that, The first description information includes the task intent information, and the first request indicates the creation of the first task.

3. The method according to claim 2, characterized in that, Also includes: Receive a first response from the MEF network entity, wherein the first response indicates that the first request has been rejected or accepted.

4. The method according to claim 3, characterized in that, The first response indicates that the first request has been rejected; The first response also includes a reason for rejection, wherein the reason includes one of the following: The first description information includes neither the task intent nor the task specifications; The first task includes a subtask CB, wherein the subtask CB corresponds to a non-reusable task; or The first task has been abandoned.

5. The method according to any one of claims 1 to 4, characterized in that, The first request instructs modification of at least one element of the first description information of the first task.

6. A method performed by an application function (AF) network entity, characterized in that, The method includes: A fourth request is sent to the MEF network entity that enables the mission to be opened, wherein the fourth request indicates the removal of the second mission and includes a second mission ID that identifies the second mission; A fourth response is received from the MEF network entity, wherein the fourth response indicates that the second task is deprecated if the third description information regarding the second task is deleted by logical deletion, wherein the logical deletion indicates that the third description information is stored in memory and has been processed.

7. The method according to claim 6, characterized in that, The fourth response indicates that the second task is removed if the third description information regarding the second task is deleted by physical deletion, wherein the physical deletion indicates that the third description information is removed from the memory.

8. A method executed by a Task Open Function (MEF) network entity, characterized in that, The method includes: Receive a first request from an Application Function (AF) network entity, wherein the first request includes first descriptive information about a first task, and the first request indicates management related to the first task, the first descriptive information including at least one of the following: The time validity condition indicates when the first task is valid; Spatial validity conditions indicate where the first task is valid; Reusability indicator, indicating whether the first task can be used as a computation block CB in another task; Application indication, indicating at least one application supported by the first task; The interface information describes the interface through which the first task can be accessed; Task intent information, describing the task intent of the first task; Task specification information describes the communication logic between one or more task blocks (CBs) of the first task, wherein the one or more CBs are used to implement the task intent described in the task intent information; or At least one task parameter to be specified; Obtain second description information about the first task, wherein the second description information is generated based on the first description information.

9. The method according to claim 8, characterized in that, The first description information includes the task intent information.

10. The method according to claim 9, characterized in that, Obtaining the second descriptive information about the first task includes: The task specification is obtained according to the task intent, wherein the task specification describes the communication logic between one or more CBs of the first task, and the one or more CBs are used to implement the task intent; Generate second description information about the first task, wherein the second description information includes the task specification.

11. The method according to claim 10, characterized in that, Obtaining the task specifications based on the task intent includes: Send a second request to the first service control function (SCF) network entity, wherein the second request instructs the generation of the task specification and includes the task intent information; Receive a second response from the first SCF network entity including a first task specification, wherein the first task specification is generated by the first SCF network entity according to the task intent; At least a portion of the task specification is generated based on the first task specification.

12. The method according to claim 11, characterized in that, The first task specification includes the CB ID of the subtask CB corresponding to the third task to be created and the subtask intent information corresponding to the third task; Obtaining the task specifications based on the task intent also includes: A third request is sent to a second SCF network entity, wherein the third request indicates the generation of a subtask specification, and the third request includes the subtask intent information, wherein the subtask specification describes the interoperability logic between one or more CBs of the subtask CB, and the one or more CBs of the subtask CB are used to implement the subtask intent described by the subtask intent information; Receive a third response from the second SCF network entity, including a second task specification, wherein the second task specification is generated by the second SCF network entity based on the subtask intent.

13. The method according to claim 11 or 12, characterized in that, Obtaining the task specifications based on the task intent also includes: The task specification corresponding to the task intent is generated based on the first task specification and the second task specification.

14. The method according to claim 13, characterized in that, Generating the task specification corresponding to the task intent based on the first task specification and the second task specification includes: The second task specification is integrated into the first task specification to generate the task specification corresponding to the task intent.

15. The method according to any one of claims 10 to 14, characterized in that, Also includes: Send the second description information about the first task to the task data repository MDR network entity.

16. The method according to any one of claims 9 to 15, characterized in that, The first description information regarding the first task satisfies the predefined conditions; The method further includes: Send a first response to the AF network entity indicating that the first request has been rejected.

17. The method according to claim 16, characterized in that, The predefined conditions include at least one of the following: The first description information does not include the task intent information, nor does it include the task specifications; The first task includes a subtask CB, wherein the subtask CB corresponds to a non-reusable task; or The first task has been abandoned.

18. The method according to any one of claims 11 to 17, characterized in that, Also includes: Send a first acknowledgment to the first SCF network entity, wherein the first acknowledgment indicates that the first task specification has been accepted; and / or A second acknowledgment is sent to the second SCF network entity, wherein the second acknowledgment indicates that the second task specification has been accepted.

19. The method according to any one of claims 8 to 18, characterized in that, Either the second request or the first confirmation includes a first task ID that identifies the first task, wherein the first task ID is included in the first description information or generated by the MEF; and / or Either the third request or the second confirmation includes the first task ID.

20. A method executed by a Task Open Function (MEF) network entity, characterized in that, The method includes: Receive a fourth request from the Application Function (AF) network entity, wherein the fourth request indicates the removal of the second task, and the fourth request includes a second task ID that identifies the second task; A fifth request is sent to the MDR network entity, wherein the fifth request includes the second task ID and instructs the removal of third descriptive information about the second task.

21. The method according to claim 20, characterized in that, Also includes: A fifth response is received from the MDR network entity, wherein the fifth response indicates the deletion type of the third description information, the deletion type including physical deletion and / or logical deletion, the physical deletion indicating that the third description information is removed from the memory, and the logical deletion indicating that the third description information is stored in the memory and has been processed.

22. The method according to claim 21, characterized in that, Also includes: A fourth response is sent to the application function AF network entity, wherein the fourth response includes the second task ID and indicates the status of the second task, the status corresponding to the deletion type.

23. The method according to claim 22, characterized in that, The status of the second task corresponding to the physical deletion is that the second task is unavailable, and the status of the second task corresponding to the logical deletion is that the second task is abandoned.

24. The method according to any one of claims 20 to 23, characterized in that, The fourth description information regarding the second task satisfies predefined conditions, wherein the fourth description information is obtained based on the second task ID; The method further includes: A sixth response is sent to the AF, wherein the sixth response indicates that the fourth request has been rejected.

25. The method according to claim 24, characterized in that, The predefined conditions include: the fourth description information about the second task indicates that the second task is a reusable task and is being used.

26. The method according to claim 24 or 25, characterized in that, Also includes: Send the second task ID to the target network entity; Obtain the fourth description information from the target network entity.

27. A method performed by a Service Control Function (SCF) network entity, characterized in that, include: Receive a second request from the Mission Open Function (MEF) network entity, wherein the second request instructs the generation of a mission specification, and the second request includes mission intent information describing the mission intent of the first mission; A first task specification is sent to the MEF network entity, wherein the first task specification is generated by the SCF network entity based on the task intent information included in the second request.

28. The method according to claim 27, characterized in that, Also includes: Determine one or more CBs for the first task and the networking logic between the one or more CBs; Generate the first task specification, wherein the first task specification includes the CB ID of each of the one or more CBs and the networking logic.

29. The method according to claim 27 or 28, characterized in that, The first task specification includes the CB ID of the subtask CB corresponding to the third task to be created and the subtask intent information corresponding to the third task, wherein the subtask intent information describes the subtask intent; The method further includes: Receive a third request from the MEF network entity, wherein the third request indicates the generation of a subtask specification, and the third request includes the subtask intent information, the subtask specification describing the networking logic between one or more CBs of the subtask CB, the one or more CBs of the subtask CB being used to implement the subtask intent; A second task specification is sent to the MEF network entity, wherein the second task specification is part of the task specification corresponding to the task intent, and the second task specification is generated by the SCF network entity according to the sub-task intent.

30. The method according to any one of claims 27 to 29, characterized in that, Also includes: Receive a first acknowledgment from the MEF network entity, wherein the first acknowledgment indicates that the first task specification has been accepted.

31. The method according to claim 30, characterized in that, Also includes: Receive a second confirmation from the task open function network entity, wherein the second confirmation indicates that the second task specification has been accepted.

32. The method according to any one of claims 27 to 31, characterized in that, Either the second request or the first confirmation includes a first ID identifying the first task; and / or Either the third request or the second confirmation further includes the first ID that identifies the first task.

33. A method performed by a Task Data Repository (MDR) network entity, characterized in that, include: Receive a fifth request from the Mission Open Function (MEF) network entity, wherein the fifth request includes a second mission ID that identifies the second mission and instructs the removal of third descriptive information about the second mission; A fifth response to the fifth request is sent to the MEF network entity, wherein the fifth response indicates the deletion type of the third description information, the deletion type including physical deletion or logical deletion, the physical deletion indicating that the third description is removed from the memory, and the logical deletion indicating that the third description information is stored in the memory and has been processed.

34. The method according to claim 33, characterized in that, Also includes: In the case where the second task includes a task instance, the logical deletion is used to remove the third description information; or If the second task does not include a task instance, the third description information is processed using the physical deletion method.

35. The method according to claim 33 or 34, characterized in that, Also includes: A sixth request is sent to the task instance repository MIR network entity, wherein the sixth request includes the second task ID and instructs the MIR network entity to send one or more notifications regarding information changes related to the second task.

36. The method according to claim 35, characterized in that, Also includes: Receive a sixth response from the MIR network entity to the sixth request, wherein the sixth response includes an instance ID identifying a task instance of the second task and indicating information changes regarding the task instance, the information changes indicating that the task instance has been created for the second task or that the task instance has been removed.

37. The method according to claim 36, characterized in that, Also includes: The sixth response determines whether the second task includes a task instance.

38. The method according to claim 37, characterized in that, Determining whether the second task includes the task instance based on the sixth response includes: The number of existing instances of the second task is determined based on the instance ID and the information changes corresponding to the instance ID; If the quantity is equal to 0, then it is determined that the second task does not include task instances.

39. An apparatus, characterized in that, include: At least one processor is configured to execute computer program instructions stored in a memory, such that the apparatus implements the method according to any one of claims 1 to 5 or claims 6 and 7.

40. An apparatus, characterized in that, include: At least one processor is configured to execute computer program instructions stored in a memory, such that the apparatus implements the method according to any one of claims 8 to 19 or claims 20 to 26.

41. An apparatus, characterized in that, include: At least one processor is configured to execute computer program instructions stored in a memory, such that the apparatus implements the method according to any one of claims 27 to 32.

42. An apparatus, characterized in that, include: At least one processor is configured to execute computer program instructions stored in a memory, such that the apparatus implements the method according to any one of claims 33 to 38.

43. A system, characterized in that, include: The apparatus according to claims 1 to 5, and the apparatus according to claims 8 to 19; The apparatus according to claims 27 to 32.

44. A system, characterized in that, include: The apparatus according to claims 6 and 7, and the apparatus according to claims 20 to 26; The apparatus according to claims 33 to 38.

45. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by the processing circuitry of a computer, cause the computer to perform the method according to any one of claims 1 to 5, 6 and 7, 8 to 19, 20 to 26, 27 to 32, or 33 to 38.

46. ​​A computer program product, characterized in that, The computer program product has instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 5, 6 and 7, 8 to 19, 20 to 26, 27 to 32, or 33 to 38.

47. A chip system, characterized in that, The system includes processing circuitry and a storage medium, wherein the storage medium stores computer program instructions that, when executed by the processing circuitry, cause the chip system to implement the method according to any one of claims 1 to 5, 6 and 7, 8 to 19, 20 to 26, 27 to 32, or 33 to 38.

Images