WO2025065986A1

WO2025065986A1 - Method, apparatus and system for managing a mission

Info

Publication number: WO2025065986A1
Application number: PCT/CN2024/074115
Authority: WO
Inventors: Xu Li; Weisen SHI; Chenchen YANG; Hang Zhang
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2023-09-29
Filing date: 2024-01-25
Publication date: 2025-04-03
Anticipated expiration: 2026-03-29

Abstract

A method for mission management is provided, which is applied to managing a mission. The method includes: obtaining first description information about a first mission, wherein the first description information includes at least one of: temporal validity condition indicating when the first mission is valid; spatial validity condition indicating where the first mission is valid; a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission; an application indication indicating at least one application that the first mission can support; interface information describing interfaces via which the first mission can be accessed; mission intent information describing a mission intent of the first mission; mission specification describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by the mission intent information; or at least one mission parameter to be specified; and sending a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first description information about the first mission, and the first request indicates a management related to the first mission.

Description

METHOD, APPARATUS AND SYSTEM FOR MANAGING A MISSION

This application claims the priority of U.S. Provisional Patent Application No. 63/586,484, filed on September 29, 2023, the disclosure of which is incorporated, in its entirety, by this reference.

TECHNICAL FIELD

The present disclosure generally relates to the field of wireless communication, and in particular, to a method, apparatus, system for managing a mission, and computer readable storage medium.

BACKGROUND

As the communication technology advances, many new trends will trigger the design of a new generation of wireless network. The new trends may include, for example, new network infrastructure capability (e.g., cloud natured/friendly infrastructures) that are broadly deployed, new (relative) matured techniques (e.g., AI large scale models, data de-privacy, block chain, etc. ) that have made significant progresses and significantly impact on the entire society and human life or new applications and services (e.g., AI services, data (sensing) service, digital world service, etc. ) that are broadly applied in industry/business and used by individual customers. Besides, more global/open/collaborative operations (i.e., a more open and more collaborative operation modes) are becoming common practice in many fields.

New expectation and stricter requirements on future networks also drive rethinking and development of the new generation of wireless networks. These requirements may include privacy and trustworthiness, simplified standardization rapid deployment, etc.

All of the above drives 6G network architecture research work.

This background information is provided to reveal information believed by the applicant to be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present disclosure.

SUMMARY

Embodiments of the present disclosure provide a method and an apparatus for mission management.

To achieve the above objective, the following technical solutions are adopted in the present disclosure.

According to a first aspect, a method performed by an AF network entity is provided. The method includes: obtaining first description information about a first mission, for example, the first description information is in form of part of a mission template, wherein the first description information includes at least one of: temporal validity condition indicating when the first mission is valid; spatial validity condition indicating where the first mission is valid; a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission; an application indication indicating at least one application that the first mission can support; interface information describing interfaces via which the first mission can be accessed; mission intent information describing a mission intent of the first mission; mission specification describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by the mission intent information; or at least one mission parameter to be specified; and sending a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first description information about the first mission, and the first request indicates a management related to the first mission.

In some embodiments, the first description information includes the mission intent information, and the first request indicates creating the first mission.

In some embodiments, the method further includes: receiving a first response from the MEF network entity, the first response indicating that the first request has been rejected or accepted.

In some embodiments, the first response indicates that the first request has been rejected; and the first response further includes a reason for rejection, wherein the reason includes one of: the first description information includes neither the mission intent information nor the mission specification; in the case where the first mission includes a sub-mission computing block, and the sub-mission computing block corresponds to a non-reusable mission; or in the case where the first mission is deprecated.

In some embodiments, the first request indicates modifying at least one element of the first description information of the first mission. For example, the first request indicates modifying the reusability indication as indicated in the first description information.

The beneficial effects brought by the first aspect is that the AF provides mission description information (for example, the mission template) associated to a mission to the system. The mission template provided from the AF may include a mission specification, for example when the AF is a capable AF that is able to determine the mission specification. If the mission template provided from the AF does not include a mission specification, the system will generate a mission specification for the mission according to mission intent information in the mission template. This moves the job of determining the mission specification from the AF into the system, allowing a less capable AF.

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

In some embodiments, the fourth response indicates that the second mission is removed if the third description information about the second mission is deleted by a physical deletion, wherein the physical deletion indicates that the third description information is removed from the storage.

The beneficial effects of the method provided by the second aspect allows a mission template associated to a mission to be removed dynamically and safely according to a request from the AF. The removal is performed in two steps: a logical delete (depreciation/deprecation) and a physical delete. Notification about the depreciation/deprecation is sent to the AF so that no new instance of the mission will be created or requested. The physical delete is performed after all mission instances of the mission are removed. Hence, the dynamical removal of the mission template does not impact usage of existing mission instances of the mission.

According to a third aspect, a method performed by a mission exposure function (MEF) network entity, the method comprises: receiving a first request from an application function (AF) network entity, wherein the first request includes first description information about the first mission, and the first request indicates a management related to the first mission and the first description information includes at least one of: temporal validity condition indicating when the first mission is valid; spatial validity condition indicating where the first mission is valid; a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission; an application indication indicating at least one application that the first mission can support; interface information describing interfaces via which the first mission can be accessed; mission intent information describing a mission intent of the first mission; mission specification information describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by the mission intent information; or at least one mission parameter to be specified; and obtaining second description information about the first mission, wherein the second description information is generated based on the first description information.

In some embodiments, the first description information includes the mission intent information and the second description information includes mission specification generated based on the mission intent.

In some embodiments, obtaining the second description information about the first mission includes: obtaining a mission specification based on the mission intent, wherein the mission specification describes interworking logic between one or more computing blocks of the first mission that are used for achieving the mission intent; and generating the second description information about the first mission, wherein the second description information includes the mission specification.

In some embodiments, obtaining the mission specification based on the mission intent includes: sending a second request instructing to generate the mission specification to a first service control function (SCF) network entity, the second request including the mission intent information; receiving, from the first SCF network entity, a second response including a first mission specification, wherein the first mission specification is generated by the first SCF network entity based on the mission intent; and generating at least part of the mission specification based on the first mission specification.

In some embodiments, the first mission specification includes a computing block ID of a sub-mission computing block that corresponds to a third mission to be created and sub-mission intent information corresponding to the third mission, and the sub-mission intent information describes a sub-mission intent; and obtaining the mission specification based on the mission intent further includes: sending a third request instructing to generate a sub-mission specification to a second SCF network entity, the third request including the sub-mission intent information, wherein the sub-mission specification describes interworking logic between one or more computing blocks of the sub-mission computing block that are used for achieving the sub-mission intent; and receiving, from the second service control function entity, a third response including a second mission specification, wherein the second mission specification is generated by the second SCF network entity based on the sub-mission intent.

In some embodiments, obtaining the mission specification based on the mission intent further includes: generating the mission specification corresponding to the mission intent based on the first mission specification and the second mission specification.

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

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

In some embodiments, the first description information about the first mission satisfies a predefined condition; and the method further includes: sending a first response to the AF network entity indicating that the first request has been rejected.

In some embodiments, the predefined condition includes at least one of: the first description information includes neither the mission intent information nor the mission specification; the first mission includes a sub-mission computing block, and the sub-mission computing block corresponds to a non-reusable mission; or the first mission is deprecated.

In some embodiments, the method further comprises: sending a first confirmation to the first SCF network entity, the first confirmation indicating that the first mission specification has been accepted; and/or sending a second confirmation to the second SCF network entity, the second confirmation indicating that the second mission specification has been accepted.

In some embodiments, any one of the second request and the first confirmation includes a first mission ID identifying the first mission, wherein the first mission ID is included in the first description information or generated by the MEF; and/or any one of the third request and the second confirmation includes the first mission ID.

The beneficial effects brought by the third aspect is that the AF provides a mission template associated to a mission to the system. The mission template provided from the AF may include a mission specification, for example when the AF is a capable AF that is able to determine the mission specification. If the mission template provided from the AF does not include a mission specification, the system will generate a mission specification for the mission according to mission intent information in the mission template. This moves the job of determining the mission specification from the AF into the system, allowing a less capable AF.

According to a fourth aspect, a method performed by a mission exposure function (MEF) network entity is provided, the method comprises: receiving a fourth request from an application function (AF) network entity, wherein the fourth request indicates removing 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, the fifth request including the second mission ID and instructing to remove third description information about the second mission.

In some embodiments, the method further comprises: receiving a fifth response from the MDR network entity, the fifth response indicating a deletion type of the third description information, wherein the deletion type includes a physical deletion indicating that the third description information is removed from the storage and/or a logical deletion indicating that the third description information is stored in a storage and has been processed.

In some embodiments, the method further comprises: sending a fourth response to the application function (AF) network entity, wherein the fourth response includes the second mission ID and indicates a state of the second mission, and the state corresponding to the deletion type.

In some embodiments, the state of the second mission corresponding to the physical deletion is that the second mission is unusable, and the state of the second mission corresponding to the logical deletion is that the second mission is deprecated.

In some embodiments, fourth description information about the second mission satisfies a predefined condition, wherein the fourth description information is obtained based on the second mission ID; and the method further comprises: sending a sixth response to the AF, the sixth response indicating that the fourth request has been rejected.

In some embodiments, the predefined condition includes that the fourth description information about the second mission indicates that the second mission is a reusable mission and is being used.

In some embodiments, the method further comprises: sending the second mission ID to a target network entity; and obtaining the fourth description information from the target network entity.

The beneficial effects of the method provided by the fourth aspect allows a mission template associated to a mission to be removed dynamically and safely according to a request from the AF. The removal is performed in two steps: a logical delete (depreciation/deprecation) and a physical delete. Notification about the depreciation/deprecation is sent to the AF so that no new instance of the mission will be created or requested. The physical delete is performed after all mission instances of the mission are removed. Hence, the dynamical removal of the mission template does not impact usage of existing mission instances of the mission.

According to a fifth aspect, a method performed by a service control function (SCF) network entity is provided, the method comprises: receiving a second request from a mission exposure function (MEF) network entity, the second request instructing to generate a mission specification, and the second request including a mission intent information that describes a goal 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.

In some embodiments, the method further comprises: determining one or more computing blocks of the first mission and a networking logic between the one or more computing blocks; and generating the first mission specification, wherein the first mission specification includes a computing block ID for each of the one or more computing blocks and the networking logic.

In some embodiments, the first mission specification includes a computing block ID of a sub-mission computing block that corresponds to a third mission to be created and a sub-mission intent corresponding to the third mission; and the method further includes: receiving a third request from the MEF network entity, the third request instructing to generate a sub-mission specification, and the third request including the sub-mission intent information, wherein the sub-mission specification describes a networking logic between one or more computing blocks of the sub-mission computing block that are used for achieving a sub-mission intent described by the sub-mission intent information; and sending a second mission specification to the MEF network entity, wherein the second mission specification serves as part of the mission specification corresponding to the mission intent, and the second mission specification is generated by the service control function network entity based on the sub-mission intent.

In some embodiments, the method further comprises: receiving a first confirmation from the MEF network entity, the first confirmation indicating that the first mission specification has been accepted.

In some embodiments, the method further comprises: receiving a second confirmation from the mission exposure function network entity, the second confirmation indicating that the second mission specification has been accepted.

In some embodiments, any one of the second request and the first confirmation includes a first ID identifying the first mission; and/or any one of the third request and the second confirmation further includes the first ID identifying the first mission.

The beneficial effects brought by the fifth aspect is that the AF provides mission description information (for example, the mission template) associated to a mission to the system. The mission template provided from the AF may include a mission specification, for example when the AF is a capable AF that is able to determine the mission specification. If the mission template provided from the AF does not include a mission specification, the system will generate a mission specification for the mission according to mission intent information in the mission template. This moves the job of determining the mission specification from the AF into the system, allowing a less capable AF.

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

In some embodiments, the method further comprises: in the case where the second mission includes a mission instance, removing the third description information by adopting the logical deletion; or in the case where the second mission includes no mission instance, processing the third description information by adopting the physical deletion.

In some embodiments, the method further comprises: sending a sixth request to a mission instance repository (MIR) network entity, the sixth request including the second mission ID and instructing the MIR network entity to send one or more notifications about an information change related to the second mission.

In some embodiments, the method further comprises: receiving a sixth response to the sixth request from the MIR network entity, wherein the sixth response includes an instance ID identifying a mission instance of the second mission and indicates the information change about the mission instance, and the information change indicates that the mission instance has been created for the second mission or has been removed.

In some embodiments, the method further comprises: determining whether the second mission includes a mission instance according to the sixth response.

In some embodiments, determining whether the second mission includes a mission instance according to the sixth response includes: determining a number of existed instances of the second mission according to the instance ID and the information change corresponding to the instance ID; and if the number is equal to 0, determining that the second mission includes no mission instance.

The beneficial effects of the method provided by the sixth aspect allows a mission template associated to a mission to be removed dynamically and safely according to a request from the AF. The removal is performed in two steps: a logical delete (depreciation/deprecation) and a physical delete. Notification about the depreciation/deprecation is sent to the AF so that no new instance of the mission will be created or requested. The physical delete is performed after all mission instances of the mission are removed. Hence, the dynamical removal of the mission template does not impact usage of existing mission instances of the mission.

According to a seventh aspect, an apparatus is provided, the apparatus comprises: at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of the first aspect or the second aspect.

According to an eighth aspect, an apparatus is provided, the apparatus comprises: at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of the third aspect and the fourth aspect.

According to a ninth aspect, an apparatus is provided, the apparatus comprises: at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of the fifth aspect.

According to a tenth aspect, an apparatus is provided, the apparatus comprises: at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of the sixth aspect.

According to an eleventh aspect, a system is provided, the system comprises: the apparatus of the seventh aspect, the apparatus of the eighth aspect; and the apparatus of the ninth aspect.

According to a twelfth aspect, a system is provided, and the system comprises: the apparatus of the seventh aspect, the apparatus of the eighth aspect; and the apparatus of the tenth aspect.

According to a thirteenth aspect, computer-readable storage medium having stored thereon computer program instructions that, when executed by a processing circuit of a computer, cause the computer to implement the method of any one of the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect or the sixth aspect.

According to a fourteenth aspect, a computer program product is provided. A computer program product having instructions that, when executed by a computer, cause the computer to implement the method of any one of the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect or the sixth aspect.

According to a fifteenth aspect, a chip system is provided. The chip system includes: a processing circuit and a storage medium, wherein the storage medium has stored thereon computer program instructions that, when executed by the processing circuit cause the chip system to implement the method of any one of the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect or the sixth aspect.

The advantages brought by any design from the seventh to fifteenth aspects can be referred to the first aspect to the sixth aspect or the different designs of the first aspect to the sixth aspect, which will not be detailed here.

On the basis of the implementations provided in the above aspects, the present disclosure is able to provide more implementations by further combination.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a communication environment in which embodiments of the present disclosure may be implemented;

FIG. 2 shows another communication environment in which embodiments of the present disclosure may be implemented;

FIG. 3 shows an apparatus that wirelessly communicates with at least one of two apparatuses in a communication system in accordance with some embodiments of the present disclosure;

FIG. 4 is a block diagram of an ED or apparatus in accordance with some embodiments of the present disclosure;

FIG. 5 shows a conceptual structure of a 6G System in accordance with some embodiments of the present disclosure;

FIG. 6 shows an architecture for mission management in accordance with embodiments of the present disclosure;

FIG. 7 shows a procedure of a NE accesses an application;

FIG. 8 shows a signaling chart of creating a mission in accordance with some embodiments of the present disclosure; and

FIG. 9 shows a signaling chart of removing a mission template in accordance with some embodiments of the present disclosure;

FIG. 10 shows a flow chart illustrating a method by an application function (AF) network entity in accordance with some embodiments of the present disclosure;

FIG. 11 shows another flow chart illustrating a method by an application function (AF) network entity in accordance with some embodiments of the present disclosure;

FIG. 12 shows a flow chart illustrating a method by a mission exposure function (MEF) network entity in accordance with some embodiments of the present disclosure;

FIG. 13 shows a flow chart illustrating a method by a MEF network entity in accordance with some embodiments of the present

disclosure;

FIG. 14 shows a flow chart illustrating a method by a service control function (SCF) network entity in accordance with some embodiments of the present disclosure;

FIG. 15 shows a flow chart illustrating a method by a mission data repository (MDR) network entity in accordance with some embodiments of the present disclosure; and

FIG. 16 is a schematic structural diagram of a network device in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to the embodiments of the present disclosure. It will be understood that these embodiments are described only for the purpose of illustration and to help those skilled in the art understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than those described below.

References in the present disclosure to "one embodiment" , "an embodiment" , "an example embodiment" , "some embodiments" and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be understood that although the terms "first" , "second" , etc. in front of noun (s) and the like may be used herein to describe various elements; and these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun (s) . For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of the embodiments. As used herein, the term "and/or" includes any and all combinations of one or more of the listed terms.

As used herein, "at least one of: <a list of two or more elements>" and "at least one of <a list of two or more elements>" and similar wording, where the list of two or more elements is joined by "and" or "or" , indicate at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms "a" , "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "includes" , "comprising" , "has" , "having" , "includes" and/or "including" , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

As used herein, the term "communication network" refers to a network following any suitable communication standards, 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, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

As used herein, the term "network device" refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some embodiments, a radio access network (RAN) split architecture includes a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node includes a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

The term "terminal device" refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , a portable computer, a desktop computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback appliance, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , a USB dongle, a smart device, wireless customer-premises equipment (CPE) , an Internet of Things (IoT) device, a watch or other wearables, a head-mounted display (HMD) , a vehicle, a drone, a medical device and application (e.g., remote surgery) , an industrial device and application (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain context) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms "terminal device" , "communication device" , "terminal" , "user equipment" and "UE" may be used interchangeably.

FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented. Referring to FIG. 1, as an illustrative example without limitation, a simplified schematic illustration of a communication system (also referred to as computing and communications environment) 100 is provided. The communication system 100 (which may be a wireless system) includes a radio access network (RAN) 120. The RAN 120 may be a next generation (e.g., sixth generation (6G) or later) radio access network, or a legacy (e.g. 5G, 4G, 3G or 2nd generation (2G) ) radio access network. One or more communication electronic device (ED) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generically referred to as ED110) may be interconnected to one another or connected to one or more network nodes (170a, 170b, generically referred to as 170) in the radio access network 120. A core network 130 may be a part of the communication system 100 and may be dependent or independent of the radio access technology used in the communication system 100. The communication system 100 may also comprise a public switched telephone network (PSTN) 140, the internet 150, and other networks 160.

In general, the communication system 100 enables multiple wireless or wired elements to communicate data and other content. The communication system 100 may provide content, such as voice, data, video, and/or text, via broadcast, multicast, groupcast, unicast, etc. And the communication system 100 may 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, etc. ) The services and/or applications may be mobile broadband (MBB) services, ultra-reliable low-latency communication (URLLC) services, or machine type communication (MTC) services.

The communication system 100 may operate by sharing resources, such as carrier spectrum bandwidth, between its constituent elements.

FIG. 2 illustrates another example communication environment in which example embodiments of the present disclosure can be implemented.

The communication system 100 may include a terrestrial communication system 120a/120b and/or a non-terrestrial communication system 120c. The communication system 100 may provide a high degree of availability and robustness through a joint operation of a terrestrial communication system 120a/120b and a non-terrestrial communication system 120c. For example, integrating a non-terrestrial communication system 120c (or components thereof) into a terrestrial communication system 120a/120b can result in what may be considered a heterogeneous network comprising multiple layers. The heterogeneous network may achieve better overall performance through efficient multi-link joint operation, more flexible functionality sharing, and faster physical layer link switching between terrestrial networks and non-terrestrial networks.

The terrestrial communication system 120a/120b and the non-terrestrial communication system 120c could be considered sub-systems of the communication system.

The communication system 100 may include ED 110a, 110b, 110c, 110d (generically referred to as ED 110) , and RAN 120a, 120b. In addition, the communication system 100 may also include a non-terrestrial communication network 120c. The communication system 100 may also include one or more of a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. The RANs 120a, 120b include respective RAN nodes such as base stations (BSs) 170a, 170b, which may be generically referred to as terrestrial transmit and receive points (T-TRPs) 170a, 170b (generically referred to as T-TRP 170) . In one implementation, the non-terrestrial communication network 120c includes a RAN node such as an access node (or base station) 172, which may be generically referred to as a non-terrestrial transmit and receive point (NT-TRP) 172. As may be surmised on the basis of similarity in reference numerals, the non-terrestrial communication network 120c may be considered to be a radio access network, with operational aspects in common with the RANs 120a, 120b. In another implementations, 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 non-terrestrial network device works as a transport layer device and the at least one corresponding terrestrial network device works as a RAN node, which communicates with the ED 110 via the non-terrestrial network device. In addition, there may be a NTN gateway in the ground (i.e., referred as a terrestrial network device) also as a transport layer device to communication with both the NTN device, and the RAN node communicates with the ED 110 via the NTN device and the NTN gateway. In some embodiments, the NTN gateway and the RAN node may be located in the same device.

Any ED 110 may be alternatively or additionally configured to interface, access, or communicate with any T-TRP 170a, 170b and NT-TRP 172, the Internet 150, the core network 130, the PSTN 140, the other networks 160, or any combination of the preceding. In some examples, ED 110a may communicate an uplink (UL) and/or downlink (DL) transmission over a terrestrial air interface 190a with T-TRP 170a. In some examples, the EDs 110a, 110b, 110c, and 110d may also communicate directly with one another via one or more sidelink (SL) air interfaces 190b. In some examples, ED 110d may communicate an uplink and/or downlink transmission over a non-terrestrial air interface 190c with NT-TRP 172.

The air interfaces 190a and 190b may use similar communication technology, such as any suitable radio access technology. For example, the communication system 100 may implement one or more channel access methods, 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) in the air interfaces 190a and 190b. The air interfaces 190a and 190b may utilize other higher dimension signal spaces, which may involve a combination of orthogonal and/or non-orthogonal dimensions.

The non-terrestrial air interface 190c can enable communication between the ED 110d and one or multiple NT-TRPs 172 via a wireless link or simply a link. For some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of EDs 110 and one or multiple NT-TRPs 172 for multicast transmission.

The RANs 120a and 120b are in communication with the core network 130 to provide the EDs 110a 110b, and 110c with various services such as voice, data, and other services. The RANs 120a and 120b and/or the core network 130 may be in direct or indirect communication 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 employ the same radio access technology as RAN 120a, RAN 120b or both. The core network 130 may also serve as a gateway access between (i) the RANs 120a and 120b or EDs 110a 110b, and 110c or both, and (ii) other networks (such as the PSTN 140, the Internet 150, and the other networks 160) . In addition, some or all of the EDs 110a 110b, and 110c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies and/or protocols. Instead of wireless communication (or in addition thereto) , the EDs 110a 110b, and 110c may communicate via wired communication channels to a service provider or switch (not shown) , and to the Internet 150. PSTN 140 may include circuit switched telephone networks for providing plain old telephone service (POTS) . Internet 150 may include a network of computers and subnets (intranets) or both, and incorporate protocols, such as Internet Protocol (IP) , Transmission Control Protocol (TCP) , User Datagram Protocol (UDP) . EDs 110a 110b, and 110c may be multimode devices capable of operation according to multiple radio access technologies, and incorporate multiple transceivers necessary to support such.

In addition, the communication system 100 may comprise a sensing agent (not shown in the figure) to manage the sensed data from ED110 and/or the T-TRP 170a, 170b and/or NT-TRP 172. In one implementation, the sensing agent is located in the T-TRP 170 and/or NT-TRP 172. In another implementation, the sensing agent is a separate node which has interface to communicate with the core network 130 and/or the RAN 120 (e.g., the T-TRP 170a, 170b and/or NT-TRP 172) .

FIG. 3 illustrates example of an Apparatus 310 wirelessly communicating with at least one of two apparatuses (e.g., Apparatus 320a and Apparatus 320b, referred to as Apparatus 320) in a communication system, e.g., the communication system 100, according to one embodiment. The Apparatus 310 may be a UE (e.g., ED 110 in FIG. 1 or FIG. 2) . The Apparatus 320a may be a terrestrial network device (e.g., T-TRP 170a, 170b as shown in FIG. 2) , and Apparatus 320b may be a non-terrestrial network device (e.g., NT-TRP 172 as shown in FIG. 2) . However, this is not necessary. For example, Apparatus 320a may be a NT-TRP, and 320b may be a T-TRP, both Apparatus 320a and 320b may be T-TRPs or NT-TRPs, according to present disclosure. In the following, the ED 110 as an example of the Apparatus 310 is described, and T-TRP 170 as an example of Apparatus 320a is described, and NT-TRP 172 as an example of Apparatus 320a is described. Although only one Apparatus 310, one Apparatus 320a and one Apparatus 320b. Please note that the number of Apparatus 310 (e.g., ED 110) could be one or more, and the number of Apparatus 320a and/or 320b could be one or more. For example, one ED110 may be served by only one T-TRP 170 (or one NT-TRP172) , 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-TRP172.

The ED 110 is used to connect persons, objects, machines, etc. The ED 110 may be widely used in various scenarios including, for example, cellular communications, 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) , metaverse, digital twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

Each ED 110 represents any suitable end user device for wireless operation and may include such devices (or may be referred to but not limited to) as a user equipment/device (UE) , a wireless transmit/receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a MTC device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus in (e.g. communication module, modem, or chip) or comprising the forgoing devices, among other possibilities. Future generation EDs 110 may be referred to using other terms. The base station 170a and 170b is a T-TRP and will hereafter be referred to as T-TRP 170. Also shown in FIG. 3, a non-terrestrial (NT) device will hereafter be referred to 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 configured in response to one of more of: connection availability and connection necessity.

As shown in FIG. 3, the ED 110 include at least one processor 210. Only one processor 210 is illustrated to avoid congestion in the drawing. The ED 110 may further include a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is illustrated to avoid congestion in the drawing. One, some, or all of the antennas 204 may alternatively be panels. The transmitter 201 and the receiver 203 may be integrated, e.g. as a transceiver. The transceiver is configured to modulate data or other content for transmission by at least one antenna 204 or network interface controller (NIC) . The transceiver is also configured to demodulate data or other content received by the at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and/or processing signals received wirelessly or by wire. Each antenna 204 includes any suitable structure for transmitting and/or receiving wireless or wired signals. The ED 110 may include at least one memory 208. Only the transmitter 201, receiver 203, processor 210, memory 208, and antenna 204 is illustrated for simplicity, but the ED 110 may include one or more other components.

The memory 208 stores instructions. The memory 208 may also store data used, generated, or collected by the ED 110. For example, the memory 208 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described herein and that are executed by one or more processing unit (s) (e.g., a processor 210) . Each memory 208 includes any suitable volatile and/or non-volatile storage and retrieval device (s) . Any suitable type of memory may be used, such as random access memory (RAM) , read only memory (ROM) , hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, and the like.

The ED 110 may further include one or more input/output devices (not shown) or interfaces (such as a wired interface to the Internet 150 in FIG. 1) . The input/output devices or interfaces permit interaction with a user or other devices in the network. Each input/output device or interface includes any suitable structure for providing information to or receiving information from a user, and/or for network interface communications. Suitable structures include, for example, a speaker, microphone, keypad, keyboard, display, touch screen, etc.

The processor 210 performs (or controlling the ED110 to perform) operations described herein as being performed by the ED110. As illustrated below and elsewhere in the present disclosure. For example, the processor 210 performs or controls the ED110 to perform receiving transport blocks (TBs) , using a resource for decoding of one of the received TBs, releasing the resource for decoding of another of the received TBs, and/or receiving configuration information configuring a resource. In details, the operation may include those operations related to preparing a transmission for uplink transmission to the NT-TRP 172 and/or the T-TRP 170; those operations related to processing downlink transmissions received from the NT-TRP 172 and/or the T-TRP 170; and those operations related to processing sidelink transmission to and from another ED 110. Processing operations related to preparing a transmission for uplink transmission may include operations such as encoding, modulating, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulating and decoding received symbols. Processing operations related to processing sidelink transmissions may include operations such as transmit/receive beamforming, modulating/demodulating and encoding/decoding symbols. Depending upon the embodiment, a downlink transmission may be received by the receiver 203, possibly using receive beamforming, and the processor 210 may extract signaling from the downlink transmission (e.g., by detecting and/or decoding the signaling) . An example of signaling may be a reference signal transmitted by the NT-TRP 172 and/or by the T-TRP 170. In some embodiments, the processor 210 implements the transmit beamforming and/or the receive beamforming based on the indication of beam direction, e.g. beam angle information (BAI) , received from the T-TRP 170. In some embodiments, the processor 210 may perform operations relating to network access (e.g., initial access) and/or downlink synchronization, such as operations relating to detecting a synchronization sequence, decoding and obtaining the system information, etc. In some embodiments, the processor 210 may perform channel estimation, e.g. using a reference signal received from the NT-TRP 172 and/or from the T-TRP 170.

Although not illustrated, the processor 210 may form part of the transmitter 201 and/or part of the receiver 203. Although not illustrated, the memory 208 may form part of the processor 210.

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

In some embodiments, the ED 110 may an apparatus (also called component) for example, communication module, modem, chip, or chipset, it includes at least one processor 210, and an interface or at least one pin. In this scenario, the transmitter 201 and receiver 203 may be replaced by the interface or at least one pin, wherein the interface or at least one pin is to connect the apparatus (e.g., chip) and other apparatus (e.g., chip, memory, or bus) . Accordingly, the transmitting information to the NT-TRP 172 and/or the T-TRP 170 and/or another ED 110 may be referred to as transmitting information to the interface or at least one pin, or as transmitting information to the NT-TRP 172 and/or the T-TRP 170 and/or another ED 110 via the interface or at least one pin, and receiving information from the NT-TRP 172 and/or the T-TRP 170 and/or another ED 110 may be referred to as receiving information from the interface or at least one pin, or as receiving information from the NT-TRP 172 and/or the T-TRP 170 and/or another ED 110 via the interface or at least one pin. The information may include control signaling and/or data.

As shown in FIG. 3, the T-TRP 170 include at least one processor 260. Only one processor 260 is illustrated to avoid congestion in the drawing. The T-TRP 170 may further include at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is illustrated to avoid congestion in the drawing. One, some, or all of the antennas 256 may alternatively be panels. The transmitter 252 and the receiver 254 may be integrated as a transceiver. The T-TRP 170 may further include at least one memory 258. The T-TRP 170 may further include scheduler 253. Only the transmitter 252, receiver 254, processor 260, memory 258, antenna 256 and scheduler 253 are illustrated for simplicity, but the T-TRP may include one or more other components.

The T-TRP 170 may be known by other names In some embodiments, such as a base station, a base transceiver station (BTS) , a radio base station, a network node, a network device, a device on the network side, a transmit/receive node, a Node B, an evolved NodeB (eNodeB or eNB) , a Home eNodeB, a next Generation NodeB (gNB) , a transmission point (TP) , a site controller, an access point (AP) , a wireless router, a relay station, a terrestrial node, a terrestrial network device, a terrestrial base station, a base band unit (BBU) , a remote radio unit (RRU) , an active antenna unit (AAU) , a remote radio head (RRH) , a central unit (CU) , a distributed unit (DU) , a positioning node, among other possibilities. The T-TRP 170 may be a macro base station (BS) , a pico BS, a relay node, a donor node, or the like, or combinations thereof. The T-TRP 170 may refer to the forgoing devices or refer to apparatus (e.g., a communication module, a modem, or a chip) in the forgoing devices.

In some embodiments, the parts of the T-TRP 170 may be distributed. For example, some of the modules of the T-TRP 170 may be located remote from the equipment that houses the antennas 256 for the T-TRP 170, and may be coupled to the equipment that houses the antennas 256 over a communication link (not shown) sometimes known as front haul, such as 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 determining the location of the ED 110, resource allocation (scheduling) , message generation, and encoding/decoding, and that are not necessarily part of the equipment that houses the antennas 256 of the T-TRP 170. The modules may also be coupled to other T-TRPs. In some embodiments, the T-TRP 170 may actually be a plurality of T-TRPs that are operating together to serve the ED 110, e.g. through the use of coordinated multipoint transmissions.

The processor 260 performs operations including those related to: preparing a transmission for downlink transmission to the ED 110, processing an uplink transmission received from the ED 110, preparing a transmission for backhaul transmission to the T-TRP 170 and/or NT-TRP 172, and processing a transmission received over backhaul from the T-TRP 170 and/or NT-TRP 172. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulating, precoding (e.g., multiple input multiple output (MIMO) precoding) , transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or over backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. The processor 260 may also perform operations relating to network access (e.g., initial access) and/or downlink synchronization, such as generating the content of synchronization signal blocks (SSBs) , generating the system information, etc. In some embodiments, the processor 260 also generates an indication of beam direction, e.g., BAI, which may be scheduled for transmission by a scheduler 253. The processor 260 performs other network-side processing operations described herein, such as determining the location of the ED 110, determining where to deploy the NT-TRP 172, etc. In some embodiments, the processor 260 may generate signaling, e.g. to configure one or more parameters of the ED 110 and/or one or more parameters of the NT-TRP 172. Any signaling generated by the processor 260 is sent by the transmitter 252.

The scheduler 253 may be coupled to the processor 260 or integrated in the processor 260. The scheduler 253 may be included within or operated separately from the T-TRP 170. The scheduler 253 may schedule uplink, downlink, sidelink, and/or backhaul transmissions, including issuing scheduling grants and/or configuring scheduling-free (e.g., "configured grant" ) resources.

The memory 258 is configured to store information, and optionally data. The memory 258 stores instructions and data used, generated, or collected by the T-TRP 170. For example, the memory 258 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described herein and that are executed by the processor 260.

Although not illustrated, the processor 260 may form part of the transmitter 252 and/or part of the receiver 254. Also, although not illustrated, the processor 260 may implement the scheduler 253. Although not illustrated, the memory 258 may form part of the processor 260.

The processor 260, the scheduler 253, the processing components of the transmitter 252, and the processing components of the receiver 254 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory, e.g., in the memory 258. Alternatively, some or all of the processor 260, the scheduler 253, the processing components of the transmitter 252, and the processing components of the receiver 254 may be implemented using dedicated circuitry, such as a programmed FPGA, a hardware accelerator (e.g., a GPU or AI accelerator) , or an ASIC.

When the T-TRP 170 is an apparatus (also called as component, for example, 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, the transmitter 252 and receiver 254 may be replaced by the interface or at least one pin, wherein the interface or at least one pin is to connect the apparatus (e.g., chip) and other apparatus (e.g., chip, memory, or bus) . Accordingly, the transmitting information to the NT-TRP 172 and/or the T-TRP 170 and/or ED 110 may be referred as transmitting information to the interface or at least one pin, and receiving information from the NT-TRP 172 and/or the T-TRP 170 and/or ED 110 may be referred as receiving information from the interface or at least one pin. The information may include control signaling and/or data.

Although the NT-TRP 172 is illustrated as a drone only as an example, the NT-TRP 172 may be implemented in any suitable non-terrestrial form, such as satellites and high altitude platforms, including international mobile telecommunication base stations and unmanned aerial vehicles, for example. Also, the NT-TRP 172 may be known by other names In some embodiments, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station.

As shown in FIG. 3, the T-TRP 170 may further include at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is illustrated to avoid congestion in the drawing. One, some, or all of the antennas 256 may alternatively be panels. The transmitter 252 and the receiver 254 may be integrated as a transceiver. The T-TRP 170 may further include at least one memory 258. The T-TRP 170 may further include scheduler 253. Only the transmitter 252, receiver 254, processor 260, memory 258, antenna 256 and scheduler 253 are illustrated for simplicity, but the T-TRP may include one or more other components.

As shown in FIG. 3, the NT-TRP 172 include at least one processor 276. Only one processor 276 is illustrated to avoid congestion in the drawing. 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 illustrated to avoid congestion in the drawing. One, some, or all of the antennas may alternatively be panels. The transmitter 272 and the receiver 274 may be integrated as a transceiver. The NT-TRP 172 may further include at least one memory 278. The NT-TRP 172 may further include scheduler. Only the transmitter 272, receiver 274, processor 276, memory 278, antenna 280 are illustrated for simplicity, but the NT-TRP may include one or more other components.

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

The memory 278 is configured to store information and optionally data. The memory 258 stores instructions and data used, generated, or collected by the NT-TRP 172. For example, the memory 278 could store software instructions or modules configured to implement some or all of the functionality and/or embodiments described herein and that are executed by the processor 276.

Although not illustrated, the processor 276 may form part of the transmitter 272 and/or part of the receiver 274. Although not illustrated, the memory 278 may form part of the processor 276.

The processor 276, the processing components of the transmitter 272, and the processing components of the receiver 274 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory, e.g. in the memory 278. Alternatively, some or all of the processor 276, the processing components of the transmitter 272, and the processing components of the receiver 274 may be implemented using dedicated circuitry, such as a programmed FPGA, a hardware accelerator (e.g., a GPU or AI accelerator) , or an ASIC. In some embodiments, the NT-TRP 172 may actually be a plurality of NT-TRPs that are operating together to serve the ED 110, e.g. through coordinated multipoint transmissions.

When the NT-TRP 172 is an apparatus (e.g. 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, the transmitter 272 and receiver 257 may be replaced by the interface or at least one pin, wherein the interface or at least one pin is to connect the apparatus (e.g., chip) and other apparatus (e.g., chip, memory, or bus) . Accordingly, the transmitting information to the T-TRP 170 and/or another NT-TRP 172 and/or ED 110 may be referred as transmitting information to the interface or at least one pin, and receiving information from the T-TRP 170 and/or another NT-TRP 172 and/or ED 110 may be referred as receiving information from the interface or at least one pin. The information may include control signaling and/or data.

Note that "TRP" , as used herein, may refer to a T-TRP or a NT-TRP. A T-TRP may alternatively be called a terrestrial network TRP ( "TN TRP" ) and a NT-TRP may alternatively be called a non-terrestrial network TRP ( "NTN TRP" ) . The T-TRP 170, the NT-TRP 172, and/or the ED 110 may include other components, but these have been omitted for the sake of clarity.

Note that "signaling" , as used herein, may alternatively be called control signaling, control message, control information, or message for simplicity. Signaling between a BS (e.g., the network node 170) and a terminal or sensing device (e.g., ED 110) , or signaling between different terminal or sensing device (e.g., between ED 110i and ED110j) may be carried in physical layer signaling (also called as dynamic signaling) , which is transmitted in a physical layer control channel. For downlink the physical layer signaling may be known as downlink control information (DCI) which is transmitted in a physical downlink control channel (PDCCH) . For uplink, the physical layer signaling may be known as uplink control information (UCI) which is transmitted in a physical uplink control channel (PUCCH) . For sidelink, signaling between different terminal or sensing device (e.g., between ED 110i and ED110j) may be known as sidelink control information (SCI) which is transmitted in a physical sidelilnk control channel (PSCCH) . Signaling may be carried in a higher-layer (e.g., higher than physical layer) signaling, which is transmitted in a physical layer data channel, e.g. in a physical downlink shared channel (PDSCH) for downlink signaling, in a physical uplink shared channel (PUSCH) for uplink signaling, and in a physical sidelilnkshared channel (PSSCH) for sidelink signaling. Higher-layer signaling may also called static signaling, or semi-static signaling. Higher-layer signaling may be radio resource control (RRC) protocol signaling or media access control –control element (MAC-CE) signaling. Signaling may be included in a combination of physical layer signaling and higher layer signaling.

It should be noted that in present disclosure, "information" , when different from "message" , may be carried in one single message, or be carried in more than one separate message.

FIG. 4 is an example block diagram of a device or apparatus in accordance with example embodiments of the present disclosure. One or more steps of the methods provided in this disclosure herein may be performed by corresponding units or modules in a device or apparatus, such as in the ED 110, in the T-TRP 170, or in the NT-TRP 172. For example, a signal may be transmitted by a transmitting unit or by a transmitting module 420. A signal may be received by a receiving unit or by a receiving module 430. A signal may be processed by a processing unit or a processing module 440. Other steps may be performed by an artificial intelligence (AI) or machine learning (ML) module 450.

As shown in the FIG. 4, the device or apparatus may also include operating system module 410 (e.g., an embedded operating system, firmware, etc. ) . The respective units or modules may be implemented using hardware, one or more components or devices that execute software, or a combination thereof. For instance, one or more of the units or modules may be a circuit such as an integrated circuit. Examples of an integrated circuit includes a programmed FPGA, a GPU, or an ASIC. For instance, one or more of the units or modules may be logical such as a logical function performed by a circuit, by a portion of an integrated circuit, or by software instructions executed by a processor. It will be appreciated that where the modules are implemented using software for execution by a processor for example, the modules may be retrieved by a processor, in whole or part as needed, individually or together for processing, in single or multiple instances, and that the modules themselves may include instructions for further deployment and instantiation.

Additional details regarding the EDs 110, the T-TRP 170, and the NT-TRP 172 are known to those of skill in the art. As such, these details are omitted here.

As mentioned above, the new trends drive 6G network architecture research work. The 6G network architecture needs to support new 6G services which could be developed/deployed by third parties. The proposed 6G network architecture needs to embrace more open ecosystem to open door to technical capable third parties. The proposed 6G network architecture needs to enable better trustworthiness management.

FIG. 5 shows an example conceptual structure of a 6G System according to some example embodiments of the present disclosure.

The proposed 6G system architecture is defined to support 6G XaaS services by using techniques such as Network Function Virtualization and Network Slicing. The 6G System architecture utilizes service-based interactions between 6G services.

The 6G System leverages service-based architecture and XaaS concept. XaaS services in the 6G System are categorized into three layers.

Infrastructure Layer 510 includes infrastructures supporting 6G services. Among them are wireless networks (RAN, CN) infrastructures 511, 512, Cloud/data center infrastructures 514, satellite networks 513, storage/database infrastructures 515, and sensing networks and etc. These infrastructures can be provided by a single provider or by multiple providers.

Each of the infrastructures could have its control and management functions, denoted as C/M functions, for infrastructure management. Each of these infrastructures is one type of Infrastructure as a Service.

Control and Management (C/M) layer 520 includes control and management services of the 6G System. They are developed and deployed by using slicing techniques and utilizing resource provided by infrastructure layer 510.6G services in Control and Management (C/M) layer are:

Resource Management (RM) as a Service 521 provides a capability of life-cycle management of a variety of slices and over-the-air resource assignment to wireless devices.

A 6G mission is defined as a service provided to customers by the 6G System. A mission can be a type of services which is provided by a single 6G XaaS service or a type of services that needs contributions from multiple XaaS services.

Mission Management (MM) as a Service 522 provides a capability to program provisioning of XaaS services at Service Layer to provide mission services.

Confederation Network (CONET) as a Service 525 provides a capability to enable multiple partners jointly provide 6G services. This capability is provided by confederation formation, mutual authentication, mutual authorization among partners and negotiation of agreement on recording and retracing of selected actions performed by partners, in order to assure a trustworthy environment of 6G System operations.

Service Provisioning Management (SPM) as a Service 523 provides a capability of control and management of 6G service access by customers and provisioning of requested services. The capability is provided by unified mutual authentication, authorization and policy, key management, QoS assurance and charging between any pair of XaaS service provider and customer. The customers include end-customers not only in physical world, but also digital representatives in digital world.

Connectivity Management (CM) as a Service 524 leverages 5G connectivity management functions, but with extension to include digital world.

Protocol as a Service 526 provides a capability to design service customized protocol stacks for identified interfaces.

The protocol stacks could be pre-defined for on-demand selection, or could be on-demand designed.

Network Security 527 as a Service provides a capability for owners of infrastructures to detect potential security risks of their infrastructures.

XaaS services in C/M Layer 520 support control and management of the 6G System itself and also provide support to verticals if requested. One example is that RM service can serve RAN for over-the-air resource management and can also provide service to a vertical for the vertical’s over-the-air resource allocation to its end-customers. The XaaS in C/M layer 520 can be deployed by using slicing technique.

Service Layer 530 includes 6G services which provide services to customers. In the 6G System conceptual structure:

AI service is denoted as NET4AI as a Service 531. Artificial Intelligence service provides AI capability to support a variety of AI applications.

Service of data collection, data sanitization, data analysis and data delivery are denoted as data analytics and manage (DAM) as a Service, this service provides a capability of lifecycle management of statistic data, including acquisition, de-privatization, analysis and delivery of data which are information statistic data from any types of sensors, devices, network functions, and etc.

Service of storage and sharing of data is denoted as NET4Data as a Service 532, this service provides a capability to trustworthily storage and share data under the control of owners of data and following recognized authorities’ regulations on control of identified data.

Service to provide digital world is denoted as NET4DW as a Service 535, Digital World service provides a capability to construct, control and manage digital world. Digital world is defined as digital realization of physical world.

6G block chain service is denoted as NET4BC as a Service 534.6G connectivity service is denoted as NET4Con as a Service. This service provides a capability to support 6G block chain services.

Enhanced connectivity service, e.g., network for connectivity (NET4CON) as a service 536.

This service provides a capability to support exchange of messages and data among new 6G services.

All XaaS services at this Layer are developed and deployed by using resource provided in infrastructure and utilizing Network Function Virtualization and Slicing techniques. The capability of each of 6G services is provided by its control and management functions and service specific data process functions.

In addition to support 6G XaaS services at Service Layer, 6G System leverages 5G System for provisioning of vertical services. The difference between 6G XaaS services and other verticals are that a vertical is a pure customer which needs other XaaS services to enable its operation, while each of XaaS services provide their capabilities to 6G customers.

Any pair of XaaS services of the 6G System could also be mutual customer and provider of each other. Some of example are that an infrastructure owner provides its resource to XaaS services in Service Layer 530 and C/M Layer 520; RM services may need the capabilities provided by NET4AI 531, DAM 533 and NET4DW 535 for its resource management for vertical slicing; CONET service 525 and NET4Data service 532 may need the capability provided by NET4BC 534 for their operation.

The key concepts of 6G System includes:

- Define Basic XaaS Services by decoupling comprehensive types of services into basic XaaS services. A basic XaaS service provides unique capability to enable a specific type of service, such as NET4AI service 531, NET4DW service 535, DAM service 533, NET4Data service 532, Block chain service 534, mission management service 522, etc.

- Allow joint operation of the 6G System by multiple partners.

- Define Data Plane of the 6G System which includes processing functions of data plane of XaaS services. Programing the interconnection of these functions, by mission management service 522, enables to support a variety of customized customer services.

- Simplify 6G System architecture by categorizing basic control services and management services and combining them as basic XaaS services in Control and Management (C/M) Layer 520.

- Define C/M Plane of the 6G System which includes C/M functions in XaaS services and may include 5G CP (e.g., AMF) depending on implementation options.

- Define Basic Architecture Structure (BAS) which is a unified basic structure with minimized number of interfaces and is independent of types of infrastructures.

- Simplify standardization, development and deployment of the 6G System using the BAS concept, while supporting a variety of infrastructure deployment scenarios.

- Adapt to a variety of deployment scenarios by applying the BAS or a subset of it to infrastructures based on capability, capacity and requirement of the infrastructure networks.

- Leverage service based Interface (SBI) interface concept and apply SBI interaction in both 6G C/M plane and 6G data plane.

- Simplify SBI interfaces by introducing trustworthy GWs in Data Plane and C/M Plane of the 6G System.

- Improve trustworthiness from perspectives of operation of the 6G System by introducing CONET capability, NET4BC capability and anonymous service provisioning provided by the trustworthy GWs in the C/M plane and data plane of the 6G System.

- Improve trustworthiness from perspective of end customer privacy protection by unified mutual authentication, IDM, data sanitization and etc. provided by SPM service, DAM service and 6G Block Chain service.

- Simplify roaming management of wireless devices, in physical world and digital world, by unified authentication including all participated partners and customers.

- Support multiple development paths from 5G System to 6G System by defining multiple architecture options without incurring much efforts due to the introduction of the BAS concept.

- Support backward compatibility by utilizing benefits of SBA and its add-on feature. 5G users can use the 6G System to access 5G services.

- Support future extension by adding new XaaS services with minimized impact on standardization and deployment, due to the introduced anonymous service provisioning concept implemented in trustworthy GWs in 6G C/M plane and in 6G data plane.

For illustrative purposes, specific example embodiments will now be explained in greater detail in conjunction with the figures and above mentioned system, core network, ED and TRP.

The embodiments set forth herein represent information sufficient to practice the claimed subject matter and illustrate ways of practicing such subject matter. Upon reading the following description in light of the accompanying figures, those of skill in the art will understand the concepts of the claimed subject matter and will recognize applications of these concepts not particularly addressed herein. It will be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

The present disclosure provides systems, apparatuses and methods for managing a mission (for example, mission templates which are also called mission slice templates) .

In the present disclosure, a mission is to achieve a designated goal, known as mission goal, which may include at least one of (1) providing PDU connectivity and optionally (2) providing data processing. When the mission goal includes providing data processing, the mission goal is associated with specific computational problem (s) , and providing data processing refers to solving the specific computational problem (s) . In this case, the mission includes one or multiple computing blocks (CBs) and is associated with a networking procedure among the CBs for solving the specific computational problem (s) . A CB within the mission corresponds to a defined computational step toward the mission goal (i.e., solving the specific computational problem (s) ) and may be supported by a service (for example, in the form of a task, a data network (DN) , or another mission) , accordingly, the CB is referred to as a task 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 sub-mission CB (corresponding to another mission) . Mission management includes programming a mission, instantiating a mission and achieving a mission goal.

A mission slice is a logical network that provides specific capabilities and characteristics in networking and computing (including storage) for a mission. A CB within the mission corresponds to a subnet, referred to as CB subnet, of the mission slice. The CB subnet provides computing functionalities of achieving the corresponding computational step toward the mission goal. A mission slice instance incudes a set of network function instances and the required resources (e.g., computing, storage, and networking resources) and computing logic (e.g., in terms of parameter configuration) which form a deployed mission slice. A mission service is a service that provides achieving of a mission goal, a.k.a. executing of a mission, between a network entity (NE) , e.g., a UE or an AS, and a DN. A mission session refers to an association between an NE and a DN, providing a mission service with support from a mission slice instance.

Without ambiguity, mission and mission slice are used interchangeably for ease of presentation unless clarified; likewise, CB and CB subnet are used interchangeably. When a mission is instantiated, a mission slice instance is created for the mission. The mission slice instance is thus considered an instance of the mission. For each CB within the mission, the mission instance includes an instance of the CB. If the CB is a task CB, the CB instance is located in a XaaS service module (or, a service module for simplicity) supporting the task CB; if the CB is an external CB, the CB instance is located in the respective DN; if the CB is a sub-mission CB, the CB instance is an instance of a mission corresponding to the CB. The mission can have multiple instances. A CB instance may be shared by multiple mission instances when the CB instance is stateless. Likewise, a mission instance may be shared by (i.e., support) multiple applications when the mission instance is stateless. A mission instance is stateless if and only if the mission instance does not include stateful CB instances.

FIG. 6 illustrates an architecture for the mission management in this disclosure. As shown in FIG. 6, the architecture 600 includes a number of network functions: AF 610, MDR 615, MIR 620, MCF 625, MEF 630, SCF 635, TCF 640 and PSF 645. In some embodiments, any two or more of the network functions above may be integrated as one network function. For example, the MIR 620 and the MDR 615 are integrated. In the following, the network functions shown in FIG. 6 will be described.

AF (Application function) 610. The AF 610 can request to create/update a mission or remove a mission as described in this disclosure. More specifically, in the present disclosure, creating a mission refers to creating description information of the mission. The description information can be in any form, for example, in the form of mission template. The details relating to the mission template will be further described below. Likewise, updating a mission refers to update the description information of the mission, for example, updating at least one element in the mission template of the mission. And removing a mission refers to remove the description information of the mission, that is, the mission template of the mission. Nature of the AF is not limited. That is, any network entity can act as AF. Without ambiguity, AF and AF network entity are used interchangeably for ease of presentation unless clarified.

MDR (Mission data repository) 615. The MDR 615 stores mission templates. The MDR 615 can also be referred to as MTD (Mission template repository) . As described above, the mission template is a form of description information relating to a mission. The content of a mission template is described in the Table 1 as described below. The MDR receives the mission template from the MEF 630. The MEF 630 may receive part of the mission template from the AF 610, and part of the mission template from one or multiple SCFs. In some embodiments, the MDR 615 provides the mission specification in the mission template or the mission template to the MCF 625 according to the MCF’s request. The MDR 615 may further provide the mission intent information in the mission template to the AF 610 via the MEF 630, e.g., according to a subscription or a request from the AF 610. Without ambiguity, MDR and MDR network entity are used interchangeably for ease of presentation unless clarified.

MIR (Mission instance repository) 620. The MIR 620 stores mission instance information. A mission instance information describes an instance of a mission. Without ambiguity, MIR and MIR network entity are used interchangeably for ease of presentation unless clarified.

MCF (Mission control function) 625. The MCF 625 controls and coordinates an execution of a mission over an instance of the mission, including starting, pausing, resuming, stopping, terminating the mission execution. The MCF 625 starts, pauses, resumes, stops or terminates the mission execution according to a request, e.g., from a device or an AF, or upon certain event, e.g., a time event. The MCF 625 is responsible for establishing data plane paths among CB instance (s) within the mission instance and between mission participants (e.g., UEs) and the CB instance (s) for the mission execution. When coordinating the mission execution, the MCF 625 triggers execution (s) of the CB (s) of the mission at right time and coordinates access of mission participants, e.g., devices, to the mission execution. The MCF 625 may control the mission execution with respect to relevant MM polices, which can be pre-configured at the MCF 625 or obtained by the MCF 625 from another control plane entity. Mission context related to the mission execution is maintained in the control plane and in the data plane before the mission execution is terminated. Without ambiguity, MCF and MCF network entity are used interchangeably for ease of presentation unless clarified.

MEF (Mission exposure function) 630. The MEF 630 exposes MM capabilities (services) to an AF and authenticates/authorizes requests from the AF for the MM capabilities. Via the MEF, an authorized AF can influence the system’s MM decisions. The MEF performs information mapping or resolution for information received from or transmitted to the AF. Possible information mapping includes mapping a mission external ID to a mission internal ID, a device external ID to a device internal ID, etc. Possible information resolution includes resolving a mission intent into a mission specification. Without ambiguity, MEF and MEF network entity are used interchangeably for ease of presentation unless clarified.

SCF (Service control function) 635. The SCF 635 assists the MEF 630 in resolving a mission intent into a mission specification. The SCF 635 is further responsible for preparing resources, e.g. control plane resources such as TCF (s) and data plane resources such as PSFs, within the corresponding service module. The prepared resources will be used to support an execution of a task of the mission within the service module, during the mission execution. Without ambiguity, SCF and SCF network entity are used interchangeably for ease of presentation unless clarified.

TCF (Task control function) 640. The TCF 640 controls and coordinates an execution of a task, including starting, stopping, terminating the task execution. The TCF 640 starts, stops or terminates the task execution, as part of a mission execution, according to a request from the MCF 625. The TCF 640 is informed by the MCF 625 that a network entity, e.g., a device, is accessing/participating the task execution. The TCF 640 can accordingly invite the network entity at right time, e.g., when task resources are ready, to access/participate the task execution, wherein the network entity may provide data to support the task execution or receives data related to the task execution. Task context related to the task execution is maintained in the control plane of the service module and in the data plane of the service module before the task execution is terminated. Without ambiguity, TCF and TCF network entity are used interchangeably for ease of presentation unless clarified.

PSF (Processing service function) 645. The PSF 645 receives and processes data plane traffic. The PSF 645 may generate data plane traffic. The PSF 645 may transmit its received data plane traffic (possibly after processing) or generated data plane traffic to other PSFs or the DN 660 or the UE 650 via one or multiple data plane gateways, a.k.a. data gateways (data GWs) 655, which are similar to UPFs (user plane functions) in the 5G system.

FIG. 7 shows a procedure of a NE accesses an application. As shown in the FIG. 7, the procedure 700 involves a mission (slice) , a mission (slice) instance, a mission session, an application and mission execution.

An application located in a DN can be a customer of a mission and provide an application service to its users by making use of an execution of the mission. The mission can support more than one application. A mission supports an application through a mission instance. A mission can act as an application and natively provides an application service to the application users; in this case, the application is considered located in the mission. An authorized NE uses a mission session to access the application, the mission session targeting a DN where the application is located and being supported by an instance of the mission. When the application is located in the mission, the DN is an abstract DN and corresponds to the mission. The mission instance can be used to support more than one application. Different applications may be supported by different instances of a mission.

In this example of FIG. 7, a mission (slice) 710 includes three types of CB, which are task CB (subnet) 711, sub-mission CB (subnet) 712 and external CB (subnet) 713. To support one or multiple applications, the mission (slice) 710 needs to be instantiated as one or more mission (slice) instance. In other words, instantiate the mission (slice) as one or multiple mission (slice) instance to support one or multiple applications. As we can see in the FIG. 7, the mission (slice) 710 is instantiated as a mission (slice) instance 720. The mission (slice) instances are used for the execution of the mission (slice) 710. Correspondingly, the mission (slice) instance 720 includes a task CB (subnet) instance 721 corresponding to the task CB (subnet) 711, a sub-mission CB (subnet) instance 722 corresponding to the sub-mission CB (subnet) 722 and an external CB (subnet) instance 723 corresponding to the external CB (subnet) 713. It is understandable that the mission (slice) 710 may also be instantiated as other mission (slice) instances. Further, a NE 730 access the application located in the DN 740 via the mission (slice) instance 720.

To support an application through a mission instance as described above, a mission session must be established over the mission instance. During the establishment of the mission session, both the data plane (e.g., data plane path (s) across CB instance (s) ) and the control plane (e.g., MCF (s) 625 and TCF (s) 640) are configured for the mission session. After the mission session establishment, data traffic related to the application can flow through the mission instance and be processed under the coordination of the MM framework, according to a networking logic (if any) associated to the mission. The process of coordinating the data flow and processing is referred to as mission execution.

The mission session is associated with one or multiple data sessions for the device. Each of the data session (s) corresponds to a CB instance in the mission instance, and the CB instance in turn corresponds to an access point of the mission. When accessing the application using the mission session, the device uses the data session (s) to interact with respective CB instance (s) . The interacting with the CB instance (s) involves data traffic and control signals and is part of the mission execution associated to the mission session.

In the example of FIG. 7, a mission session is established over the mission (slice) instance 720. Moreover, the mission session is associated with one or more data sessions. More specifically, in this example, the mission session is associated with a data session between the NE 730 and the task CB (subnet) instance 721, and another data session between the NE 730 and the sub-mission CB (subnet) instance 722, as shown by a solid line with a double-headed arrow in the FIG. 7. It is understandable that there may exist a data session between the NE 730 and the external CB (subnet) instance, although it is not shown in the FIG. 7. Besides, the application located in the DN 740 may get support from the mission (slice) instance, for example, there existed a session between the sub-mission CB instance 722 and the DN 740, and another session between the external CB instance 723 and the DN 740, as shown by a dashed line with a double-headed arrow in the FIG. 7.

A mission is identified by a mission ID (MID) . The MID may be in the form of a network slice ID. The MID may be associated with one or multiple CB IDs (CBIDs) , each identifying a CB of the mission. When a CB is an external CB, the CBID identifying the CB may be in the form of DNN. When a CB is a sub-mission CB, the CBID identifying the CB may be in the form of MID. It is possible that the MID is not associated with any CBID, for example, when the mission includes no CBs.

An instance of the mission is identified by a mission instance ID (MIID) . The MIID may be in the form of a network slice instance ID. The MIID may be associated with one or multiple CB instance IDs (CBIIDs) . Each of the one or multiple CBIIDs identifies a CB instance in the mission instance. The CB instance is an instance of a CB of the mission. When the CB is a sub-mission CB, the CBIID may be in the form of an MIID. It is possible that the MIID is not associated with any CBIID, for example, when the mission includes no CBs.

An application is identified by application ID (AID) , and a service provided by an application is identified by an application service ID (ASID) . The ASID may be in the form of a DNN. An MIID may be corresponded to one or multiple ASIDs, indicating that the mission instance identified by the MIID is being associated to (i.e., used to support) the application (s) identified by the one or multiple ASIDs. In embodiments of the present disclosure, both the AID and the ASID can identify an application. That is, the ASID and AID are equivalent in the present disclosure.

During establishment of a mission session for an application, a mission instance associated to the application is selected. The selection of mission instance may be pre-configured, or dynamically determined in the MM framework. In the former case, the MM frame can identify the mission instance based on an ASID of the application. In the latter case, the MM framework additionally uses mission selection assistance information (MSAI) to identify and select the mission instance. The MSAI may include a list of MID (s) or a list of MIID (s) . When a list of MID (s) is (are) included in the MSAI, the MM framework selects an instance of a mission identified in the list. When a list of MIID (s) is (are) included in the MSAI, the MM framework selects a mission instance identified in the list. The mission session can then be identified globally by a combination of the ASID of the application and the MIID of the mission instance.

The mission session is established upon request from an authorized device or AF. When requesting to establish the mission session, the device or AF provides the ASID and the MSAI. At a device, the mission session is identified locally using a mission session ID (MSID) and associated with a mission session context. The mission session context may include one or multiple data session IDs (DSIDs) , each identifying a data session related to a task CB instance or a DN CB instance in the mission instance. The mission session context may also include one or multiple MSIDs, each of which identifies a mission session corresponding to a sub-mission CB instance in the mission instance.

Among the identifiers described above, MSID, DSID, and ASID are understandable by the device; MID and CBID can be embedded in or mapped to other information such as MSAI, and are not be directly understandable by the device. MIID and CBIID are network-side concepts, not visible to the device.

As described above, a mission is associated with a mission template, which describes the mission. For example, the mission template includes one or multiple information elements as illustrated in the Table 1.

Table 1 Mission template

For each information element mentioned above in the mission template, the detailed description is as follows:

MID, which identifies the mission. This information may be in the form of a network slice ID. The details could refer to previously descriptions.

Temporal validity condition. This information indicates when (e.g., in terms of time) the mission is valid or available (i.e. can be executed) . The temporal validity condition can be expressed by one or multiple time-intervals or durations, each being associated with a start time and possibly an end time too. In some embodiments, each of the one or multiple time-intervals or durations may be associated with a start time and/or an end time.

Spatial validity condition. This information indicates where the mission is valid or available (i.e., can be executed) . The spatial validity condition can be expressed by a list of zone ID (s) , each identifying a geographic area, a list of PLMN ID (s) , or a list of cell ID (s) or a combination thereof.

Reusability indication. This information indicates whether the mission is reusable, i.e. whether the mission can be reused as an CB in another mission. If the mission is reusable, this information may further indicate who can reuse the mission, e.g. by including a list of identifier (s) and/or wildcard (s) . This information may indicate the mission can be used by any entity. When the reusability indication is absent, it implies the mission is not reusable.

Application indication. This information identifies one or multiple applications and indicates whether the one or multiple applications can be supported by the mission or not. The one or multiple applications can be identified using a list of ASID (s) and/or wildcard (s) . This information may indicate the mission can support any application. When the application indication is absent, it may imply the mission can support any application.

Interface information. This information describes one or multiple interfaces via which the mission can be accessed and is generated by the MM. The interface information may, for an interface or a group of interfaces, include an ID or name identifying the interface or the group of interfaces and indicate whether the interface or the group of interfaces is (are) inbound interface (s) or outbound interface (s) . An inbound interface is provided by the mission, while an outbound interface is provided by a network entity (e.g. a device, an AS or a NF) accessing the mission.

Mission intent . This information describes a goal/intent of the mission, which can be achieved by the mission through an execution of the mission. The goal of the mission can be described using application category information and service problem information. Please note that mission intent is also be refereed as mission intent information or mission goal information.

The application category information identifies one or multiple application categories that the mission is related to, e.g., by including a list of application category ID (s) . The service problem information identifies one or multiple service problems that the mission is relate to, e.g., by including a list of problem ID (s) .

The mission intent information may also identify a target service, e.g. by including a service ID. The application categori (es) and the service problem (s) identified in the mission intent information are associated with the target service.

Mission specification. This information specifies a networking logic among building block (s) of the mission for achieving the goal of the mission as indicated in the mission intent information. This information may further indicate whether the mission is a stateless mission or not.

The mission specification includes composition information, workflow information and access point information as further described below, any of which is optional.

The composition information identifies CB (s) of the mission and, if the mission include multiple CBs, specifies interconnection (s) between the multiple CBs. For each CB, the composition information may further indicate one or multiple associated mission parameters. For a task CB, the composition information indicates the respective supporting service module (e.g. using a module ID) . For an external CB, the composition information indicates the respective supporting DN (e.g. using a DNN) . For a sub-mission CB, the composition information indicates the respective mission (e.g. using an MID) . When specifying an interconnection between two CBs, this information may describe interfaces between the two CBs. For a CB, the composition information may indicate whether the CB is a stateless CB or not.

The workflow information specifies a networking logic among the CBs identified in the composition information, e.g. ordering or timing between the CBs. This information may indicate which CB (s) follow (s) or proceed (s) which other CB (s) .

The access point information specifies access point (s) of the mission, each of which is a CB of the mission and identified by a CBID. When specifying an access point, this information may indicate interface (s) associated to the access point as described in the Interface information, for example, by including one or multiple IDs or names that identify the interface (s) .

The structure for mission management and some concepts relating to a mission are described above referring to FIG. 6 and FIG. 7.In the following, a procedure of creating a mission will be described.

In some embodiments, the AF 610 may request to manage a mission. More specifically, the AF 610 obtains description information about a mission, and the AF 610 sends a request to the MEF 630. The request sent by the AF 610 includes the description information about the mission and the request indicates a management related to the mission. For ease of description and for ease in distinguishing between different missions (for example, the mission to be created and the mission to be removed) , the mission to be managed is referred to as first mission, and the description information is referred to as first description information.

In some embodiments, the first description information may be part of the mission template of the first mission. In other words, the first description information includes at least one element in the mission template as described in the Table 1. For example, the first description information includes at least one of : the temporal validity condition indicating when the first mission is valid; the spatial validity condition indicating where the first mission is valid; the reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission; the application indication indicating at least one application that the first mission can support; the interface information describing interfaces via which the first mission can be accessed; the mission intent information describing a mission intent of the first mission; the mission specification describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by the mission intent information; or at least one mission parameter that needs to be specified and respective meta-data describing usage of the at least one mission parameter.

In some embodiments, the management related to the first mission includes modifying at least one element of the first description information (for example, at least one element of the mission template) of the first mission. For example, modifying the temporal validity condition from one time interval (or duration) to another time interval (or duration) . For another example, modifying the reusability indication from indicating the first mission can be used as a CB in another mission to indicating the first mission cannot be used as a CB in another mission. That is, modifying the reusability indication from indicating the first mission is reusable to indicating the first mission is not reusable.

In some embodiments, the management related to the first mission includes creating the first mission, more specifically, creating second description information based on the first description information. For example, the first description information includes mission intent information of the first mission but not a mission specification. In this case, creating the second description information includes at least creating the mission specification of the first mission based on the mission intent. The procedure of resolving (in other words, converting or translating) a mission intent into a mission specification will be described in further details below.

Reference is now made to FIG. 8, which shows a signaling chart 800 for creating/updating a mission according to some embodiments of the present disclosure. The signaling chart 800 involves the AF 610, the MDR 615, the MIR 620, the MEF 630, and the SCF 635. In the FIG. 8, the SCF 1 is shown as SCF 6351 and the SCF 2 is shown as SCF 6352. Nature of the AF 610 is not limited. In some embodiments, any network entity such as a CPF, an AS or a device can act as AF.

As shown in FIG. 8, a mission template (or at least a part of the mission template) is provisioned from an authorized AF 610 and is stored in the MDR 615 when the AF 610 requests to create a mission (for example, the first mission) . The mission template is associated to the mission. The procedure for creating a mission includes one or more of following steps:

In step 810, the AF 610 sends an AF request to the MEF 630 for creating/updating a mission (for example, the first mission) . Accordingly, the MEF 630 receives the AF request. The AF request includes a mission template associated to the mission. The content of the mission template is described in Table 1.

In some embodiments, the AF request may include a part of the mission template of the mission, as described above. For example, the AF request includes the mission intent information of the first mission. The AF 610 obtains the (part of) the mission template from the MDR 615.

The AF request includes the first description information, as described above. In this example of FIG. 8, the mission template included in the AF request corresponds to the first description information.

In the present disclosure, the AF request is also referred to as a first request. In other words, the step 810 is also referred to as sending a first request to the MEF 630, and the first request includes the first description information about the first mission, and the first request may indicate creating the first mission.

In step 820, the MEF 630 validates the mission template in the AF request. In other words, as the mission is referred to as the first mission, and the mission template in the AF request corresponds to the first description information about the first mission, in this step the MEF 630 validates the first description information.

In some embodiments, when the AF request is for creating a mission, and if the first description information about the first mission satisfies a predefined condition, the first description information fails the validation. For example, the predefined condition includes at least one of: the first description information includes neither the mission intent information nor the mission specification; in the case where the first mission includes a sub-mission computing block (CB) , and the sub-mission computing block corresponds to a non-reusable mission (i.e., a mission that is not reusable) ; or in the case where the first mission is deprecated.

In other words, in the following cases, the mission template in the AF request is not valid.

Case 1: The mission template in the AF request is not valid if it includes neither mission intent information nor a mission specification.

Case 2: The mission template is not valid if a sub-mission of the mission as identified in the mission template does not correspond to an existing reusable mission. It is understandable that the sub-mission of the mission refers to a sub-mission CB of the mission. In some embodiments, if the mission includes a sub-mission CB and the sub-mission CB corresponds to an existing reusable mission, the sub-mission CB is valid, accordingly, the mission including the sub-mission CB is valid. Otherwise, the sub-mission CB is not valid, and neither is the mission including the sub-mission CB. If the mission includes a plurality of sub-mission CBs, the mission is only valid in the case where each of the plurality of sub-mission CBs corresponds to an existing reusable mission. Otherwise, any of the plurality of sub-mission CBs does not corresponds to an existing reusable mission, the mission is not valid. In some embodiments, the MEF 630 may interact with the MDR 615 to check whether the sub-mission corresponds to an existing reusable mission. In other words, the MEF 630 may interact with the MDR 615 to check whether the sub-mission CB (s) corresponds to existing reusable mission (s) .

Case 3: The mission template is not valid if the mission is deprecated. In the present disclosure, if a mission has been deleted logically, the mission is deprecated or depreciated. The details of logical deletion of a mission will further be described below.

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

In this case, the first response further includes a reason for rejection. The reason corresponds to the predefined condition that the first description satisfy. That is, the reason may include one of: the first description information includes neither the mission intent information nor the mission specification, in the case where the first mission includes a sub-mission computing block, and the sub-mission computing block corresponds to a non-reusable mission; or in the case where the first mission is deprecated.

In other words, if the mission template is not valid, the MEF 630 will reject the AF request and indicate the rejection to the AF 610 by sending a response sent to the AF 610 (the step 870) , the steps 820 –860 will not be performed.

In some embodiments, when the AF request is for creating the mission, if the first description information is valid and if the first description information includes mission intent information but not a mission specification, the MEF 630 will perform the following steps 830-860 to obtain the mission specification based on the mission intent.

In step 830, the MEF 630 resolves (in other words, converts or translates) the mission intent into a mission specification.

In some embodiments, if the mission template does not include a mission specification, but mission intent information, the MEF 630 resolves (in other words, converts or translates) the mission intent into a mission specification by using an SCF 635, e.g., SCF 1 (SCF 6351 as shown in the FIG. 8) and/or SCF 2 (SCF 6352 as shown in the FIG. 8) . In some embodiments, the SCF 1 (SCF 6351) is associated to a first target service, and the SCF 2 (SCF 6352) is associated to a second target service. The first target service may be different from the second target service. Therefore, the MEF 630 may resolve different mission intent using different SCFs. In details, this step 830 includes at least one of the following sub-steps:

In step 8301, the MEF 630 sends an intent resolution request to the SCF 635. Accordingly, the SCF 635 receives the request. The SCF 635 is associated to a target service indicated in the mission intent information. The mission intent information here refers to the mission intent information included in the first description information (for example, the mission template included in the AF request) . More specifically, the request is sent to the SCF 1 (SCF 6351) as shown in the FIG. 8. In the present disclosure, the SCF 1 is also referred to as a first SCF, and SCF 2 is also referred to as a second SCF. Besides, the intent resolution request in this step is also referred to as a second request. In other words, in step 8301, the MEF 630 sends a second request instructing to generate the mission specification to the SCF 1. Accordingly, the SCF 1 receives the second request from the MEF 630.

In some embodiments, the intent resolution request (also referred to as the second request) includes the mission intent information in the mission template.

In some embodiments, the intent resolution request may include a MID identifying the mission (for example, the first mission) . The MID may be included in the mission template as indicated in the AF request which is received in step 810 by the MEF 630, or the MID may be generated by the MEF 630.

In step 8302, the SCF 1 (SCF 6351) processes the mission intent and generates a mission specification draft based on the mission intent. In the present disclosure, the mission specification draft is also referred to as a first mission specification or a first draft.

In some embodiments, the SCF 1 (SCF 6351) determines one or more computing blocks (CBs) of the first mission and a networking logic between the one or more CBs. Further, the SCF 1 (SCF 6351) generates the first mission specification. The first mission specification generated by the SCF 1 includes a computing block ID (CB ID) for each of the one or more CBs and the networking logic. In other words, the SCF 1 (SCF 6351) determines CBs of the mission and a networking logic among the CBs for the mission. The mission specification draft (i.e. the first mission specification) generated by the SCF describes the CBs and the networking logic. The mission specification draft contains similar information as a mission specification, which is described in the Table 1.

In this step, the SCF (for example, SCF 1) may interact with the MDR 615, e.g., to obtain mission templates of existing reusable missions, in order to determine whether a CB of the mission can correspond to an existing reusable mission. The SCF (for example, SCF 1) may determine that a CB of the mission is a sub-mission to be created.

In step 8303, the SCF 1 responds to the MEF 630. The response is an intent resolution response. The intent resolution response includes the mission specification draft. In the present disclosure, the intent resolution response in this step is also referred to as a second response. In other words, in this step, the SCF 1 sends the second response including the first mission specification to the MEF 630.

In some embodiments, if a sub-mission of the mission is to be created as determined in the step 8302, the intent resolution response includes a sub-mission template associated with the sub-mission. The sub-mission template is a mission template describing the sub-mission and includes information elements for the sub-mission as described in the Table 1.

In step 8304, the MEF 630 sends an intent resolution confirmation to the SCF (for example, SCF 1) , indicating that the mission specification draft is accepted. The intent resolution confirmation includes the MID, which is the MID included in the intent resolution request. This step can be a delayed step, which may happen, for example, after step 8305. In the present disclosure, the intent resolution confirmation sent by the MEF 630 is also referred to as a first confirmation. Correspondingly, the step 8304 refers to that the MEF 630 sends a first confirmation to the SCF 1, the first confirmation indicating that the first mission specification has been accepted.

According to the intent resolution confirmation, the SCF (for example, SCF 1) knows that the mission specification draft (generated in the step 8302) becomes part of a mission specification corresponding to the MID.

Please be noted that the mission specification corresponding to the MID is the mission specification described in step 850. Therefore, the mission specification draft generated in the step 8302 may be part of the mission specification described in step 850. More specifically, if the SCF 1determines that no sub-mission of the mission is to be created, the mission specification draft can become (or serve as or be used as) the mission specification corresponding to the MID. If the SCF 1 determines that one or more sub-missions (that is one or more sub-mission CBs) of the mission are to be created, the mission specification draft can become (or serve as or be used as) part of the mission specification corresponding to the MID. In this case, the MEF 630 will perform the following step 840 to further resolve the sub-mission intent of the sub-mission to be created.

In step 840, the MEF 630 resolves a sub-mission intent, e.g. the sub-mission intent of the sub-mission mentioned above.

In some embodiments, if the first mission specification includes a computing block ID of a sub-mission computing block that corresponds to another mission (also referred to as a third mission in the present disclosure) to be created and sub-mission intent information corresponding to the third mission, wherein the sub-mission intent information describes a sub-mission intent. In this case, the MEF 630 resolves the sub-mission intent in the step 840.

In some embodiments, the MEF 630 performs this step 840 with an SCF, e.g., SCF 2 (for example, SCF 6352 in the FIG. 8) , which is associated to a target service indicated in the sub-mission intent information. More specifically, the MEF 630 sends an intent resolution request (also referred to as a third request) to the SCF 2, the third request instructing to generate a sub-mission specification, and the third request including the sub-mission intent information. The sub-mission specification describes a networking logic between one or more computing blocks of the sub-mission computing block that are used for achieving the sub-mission intent.

In details, if the MEF 630 receives a sub-mission template in the step 830, the MEF 630 takes the sub-mission template as a mission template and performs the step 830 with respect to the sub-mission template, to resolve the corresponding sub-mission intent information (i.e., the mission intent information in the sub-mission template) into a mission specification.

Accordingly, the SCF 2 processes the sub-mission intent to generate the sub-mission specification which is also referred to as a second mission specification or a second draft in the present disclosure. That is, the SCF 2 generates the second mission specification based on the sub-mission intent. The SCF 2 sends a third response including the second mission specification to the MEF 630. Accordingly, the MEF 630 receives the second mission specification from the SCF 2.

As the first mission specification may serve as a part of the mission specification corresponding to the mission intent, the second mission specification serves as another part of the mission specification. Similarly, the MEF 630 may send an intent resolution confirmation to the SCF 2, indicating that the second mission specification is accepted, and the intent resolution confirmation sent to the SCF 2 is also referred to as a second confirmation in the present disclosure. That is, the MEF 630 may send a second confirmation to the SCF 2, the second confirmation indicating that the second mission specification has been accepted.

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

In some embodiments, if the first mission specification includes a plurality of computing block IDs (CB IDs) of a plurality of sub-mission computing blocks that correspond to a plurality of missions to be created and a plurality of sub-mission intents corresponding to the plurality of missions, the MEF 630 resolves the plurality of sub-mission intents. In other words, if the MEF 630 receives a plurality of sub-mission templates, the MEF 630 takes each of the sub-mission template as a mission template and performs the step 830 with respect to the corresponding sub-mission template, to resolve the corresponding sub-mission intent into a mission specification. In some embodiments, the MEF 630 may interact with different SCFs to resolve different sub-mission templates. For example, the MEF 630 may interact with SCF 2 to resolve one sub-mission template and may interact with SCF 3 to resolve another sub-mission template.

In some embodiments, if the SCF 1 determines one or more CBs of the mission correspond to one or more sub-missions that do not exist and are to be created, the SCF 1 may interact with other SCFs such as, SCF 2 and SCF3, to resolve one or more sub-mission intents of the one or more sub-missions. In this case, the SCF 1 may obtain one or more sub-mission specifications corresponding to the one or more sub-mission intents from the other SCFs. For example, for a CB (of the mission) corresponding to a sub-mission that does not exist and is to be created, the SCF1 may send the sub-mission intent of the sub-mission to another SCF (e.g. SCF2 or SCF3) , and the other SCF may send the corresponding sub-mission specification to the SCF 1 after the other SCF have resolved the sub-mission intent. Further, the MEF 630 obtains the sub-mission specification from the SCF 1.

In step 850, the MEF 630 generates a mission specification for the mission based on a first draft (the mission specification draft received in the step 830) and a second draft (the mission specification draft received in the step 840) . In other words, the MEF 630 generates the mission specification based on the first mission specification and the second mission specification.

For example, the MEF 630 performs this step by integrating the second draft into the first draft such that CBs of the corresponding sub-mission are directly included in the mission as CBs and the networking logic among them are directly included into the networking logic corresponding to the mission. After this step, the first draft becomes the mission specification for the mission, and the sub-mission is no longer present in the mission specification.

In some embodiments, the generating the mission specification may include processing the first mission specification and/or the second mission specification, causing the generated mission specification includes the processed first mission specification and/or the processed second mission specification.

Please be noted that this step (step 850) may be optional and the mission specification draft received in the step 830 may be used as the mission specification for the mission, if the step 840 is not performed. In other words, the first mission specification will be used as or become the mission specification if the step 840 is not performed.

In step 860, the MEF 630 update mission (slice) template. In details, it includes the mission specification in the mission template and stores the mission template in the MDR 615.

In some embodiments, the MEF 630 obtains second description information about the first mission. The second description information includes the generated mission specification. Moreover, the second description information may further include the MID generated by the MEF 630 and other information related to the first mission. The MEF 630 sends the second description information about the first mission to the MDR 615, and the MDR 615 stores the second description information.

In step 870, the MEF 630 responds to the AF 610 for the AF request. The response indicates that the AF request is accepted. The response may include the MID.

The embodiments associated to the FIG. 8 allows the AF to provide a mission template associated to a mission to the system. The mission template provided from the AF may include a mission specification, for example when the AF is a capable AF that is able to determine the mission specification. In some embodiments, the mission template provided from the AF does not include a mission specification, and in this case, the system will generate a mission specification for the mission according to mission intent information in the mission template. This moves the job of determining the mission specification from the AF into the system, allowing a less capable AF.

The procedure of mission information provisioning is illustrated in the FIG. 8 as described above. In the following, a procedure of removing a mission (slice) template will be described.

FIG. 9 shows a procedure for removing a mission (slice) template, according to the architecture shown in FIG. 7. The procedure involves the AF 610, the MDR 615, the MIR 620 and the MEF 630.

As shown in FIG. 9, an authorized AF 610 can request to remove a mission. When the mission is removed, the mission template associated to the mission is removed from the MDR 615. The procedure assumes that the MDR 615 maintains information about whether a mission has an instance, for example, an instance count indicating the number of instance (s) of the mission, or an instance ID set. In the present disclosure, the mission to be removed is also referred to as a second mission. Removing a mission corresponds to removing description information about the mission, for example, removing the mission template of the second mission. The procedure includes one or more of following steps:

In step 910, the AF 610 sends an AF request to the MEF 630 for removing a mission. Accordingly, the MEF 630 receives the AF request from the AF 610. The AF request includes an MID identifying the mission.

In some embodiments, a mission may be created to support an application, upon request from an AF 610. The AF 610 may be associated to the application, for example, managing/controlling operation/execution of the application. The mission may be removed when the application no longer needs the support, for example, upon request from the AF 610.

In the present disclosure, for ease in distinguishing different AF requests, the AF request in this step 910 is also referred to as a fourth request. That is, in this step, the AF 610 sends a fourth request to the MEF 630, the fourth request indicating removing a second mission, and the fourth request includes a second mission ID identifying the second mission.

In some embodiments, the MEF 630 may obtain fourth description information about the second mission based on the second mission ID. For example, the MEF 630 may send the second mission ID to a target network entity (for example, the MDR 615) , and the MEF 630 obtains the fourth description information from the target network entity. In the case where the fourth description information satisfies a predefined condition, the MEF 630 may send a response to the AF 610, the response indicating that the fourth request has been rejected.

In other words, if the mission (that is, the second mission) is reusable and is being used (as a sub-mission) in another mission (i.e., corresponds to a sub-mission CB in another mission) , the MEF 630 may reject the AF request in this step. The MEF 630 may interact with the MDR 615 to obtain information whether the mission is reusable and whether the mission is being used (as a sub-mission) in the other mission. For example, the MEF 630 sends a message to the MDR 615. The mission includes the MID. In response, the MDR 615 sends the information to the MEF 630. According to the information, the MEF 630 rejects the AF request. When the MEF 630 rejects the AF request, the MEF 630 sends a response to the AF 610, indicating the rejection. The response sent to the AF 610 may include information indicating why the AF request is rejected, e.g., it is because the mission is reusable and is being used (as a sub-mission) in another mission.

In step 920, the MEF 630 requests the MDR 615 to remove mission template associated to the mission by sending a mission template removal request to the MDR 615. The request includes the MID.

In the present disclosure, the mission template removal request is also referred to as a fifth request. That is, in this step, the MEF 630 sends the fifth request to the MDR 615, the fifth request including the MID (for example, the MID of the second mission) and instructing to remove third description information about the mission (for example, the second mission) .

In step 930, after receiving the mission template removal request, the MDR 615 subscribes to receive notifications about mission instance information change related to the mission. This step is optional if the MDR 615 has already subscribed to receive the notifications.

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

In some embodiments, the MIR 620 responds to the MDR 615, indicating that the subscription is accepted. In the response, the MIR 620 may indicate whether the mission as identified by the MID has a mission instance.

In some embodiments, the MDR 615 may indicate whether the subscription is for receiving continuous notifications or a non-continuous (in other words, one-time) notification in the subscription. If the subscription is for receiving continuous notifications, the MIR 620 will notify the MDR 615 whenever a mission instance of the mission is created or removed, for example, in the step 970. When notifying the MDR 615, the MIR 620 may include the corresponding mission instance ID in the notification. If the subscription is for receiving a non-continuous notification, the MIR 620 will notify the MDR 615 whether a mission instance of the mission is created or removed in the response sent to the MDR 615 and possibly include the corresponding mission instance ID in the response. In the present disclosure, the notifications sent by the MIR 620 are also referred to as a sixth response. That is, the sixth response may be continuous responses or a one-time response.

In step 940, the MDR 615 identifies mission template associated to the mission using the MID and updates the mission template.

In some embodiments, the MDR 615 determines whether the mission is associated with (in other words, has) a mission instance according to the response indicating whether the mission as identified by the MID has a mission instance, as described above.

In some embodiments, the MDR 615 determines whether the mission is associated with (in other words, has) a mission instance according to the notifications (that is, the sixth response) . More specifically, the MDR 615 determines the number of existing instances of the mission according to the mission instance ID (s) received in the notifications and the information change (i.e. whether any of the corresponding mission instances are created or removed) relating to the mission instance ID (s) ; and if the number is equal to 0, the MDR 615 determines that the mission has no mission instance.

In some embodiments, if the mission has a mission instance, when updating the mission template, the MDR 615 logically deletes the mission template, for example, by associating a mark or an indication to the mission template. After the logical deletion (also referred to as logical delete) , the mission template is still in storage, but the mission is considered depreciated or deprecated, and no new mission instances should be created for the mission.

In some embodiments, if the mission has no mission instances, the MDR 615 deletes the mission template in the storage. As opposed to the logical deletion as described above, this is a physical deletion (also referred to as physical delete) after which, the mission template is considered removed.

In step 950, the MDR 615 sends mission (slice) template removal response.

In some embodiments, the MDR 615 responds to the MEF 630. The response indicates whether the mission template is physically deleted or logically deleted, in accordance to the step 940.

In the present disclosure, the mission (slice) template removal response is also referred to as a fifth response.

In step 960, the MEF 630 responds to the AF 610 for the AF request. The response sent to the AF 610 may include the MID. This step is optional.

In some embodiments, if the mission is physically deleted as indicated in the step 950, the response confirms that the mission has been removed. If the mission is logically deleted as indicated in the step 950, the response includes a depreciation indication indicating that the mission has been depreciated, or the response includes a deprecation information indicating that the mission has been deprecated.

In the present disclosure, the respond in this step is also referred to as a fourth response. In other words, the AF 610 receives a fourth response from the MEF 630, the fourth response indicating that the second mission is deprecated or depreciated if third description information about the second mission is deleted by/through a logical deletion (as described above) . In some embodiments, the logical deletion indicates that the third description information is stored in a storage and has been processed. Or, the fourth response may indicate that the second mission is removed if the third description information about the second mission is deleted by/through a physical deletion (as described above) . In some embodiments, the physical deletion indicates that the third description information is removed from the storage. After the physical deletion, the second mission is no longer useable. The third description information in embodiments of the present disclosure refers to mission template of the second mission as described in Tabel 1.

Corresponding to the step 930, in step 970, MIR 620 sends a notification about mission instance. Accordingly, the MDR 615 receives a notification about mission instance information change from the MIR 620, the notification indicates that a mission instance of the mission has been removed. The notification may include an MIID identifying the mission instance. According to the notification, the MDR 615 updates the locally-maintained information about whether a mission has an instance knowledge, for example, by decreasing the instance count by 1, or by removing the MIID from the instance ID set. This step is optional.

In step 980, MDR 615 removes the mission (slice) template.

If the mission has no more mission instances (e.g., if the instance count is equal to 0, or if the instance ID set is empty, containing no MIIDs) , in other words, if all mission instances of the mission have been removed, the MDR deletes the mission template associated to the mission in storage. After the deletion (which is a physical deletion) , the mission is considered removed. This step is optional.

In some embodiments, the steps 970 and 980 are performed in the case where the mission has been logically deleted.

In step 990, The MDR 615 unsubscribes from receiving notifications about mission instance information change related to the mission from the MIR 620. This step is optional, for example, when the MDR 615 has not subscribed to receive the notifications.

In this step, the MDR 615 sends an unsubscription request, which includes the MID, to the MIR 620 indicating the unsubscription (in other words, cancel the subscription) . The MIR 620 responds to the MDR 615, indicating that the unsubscription is accepted.

In step 991, the MDR 615 sends a notification of information change. Accordingly, the MEF 630 receives the notification. The notification includes the MID and a removal indication indicating that the mission has been removed. This step is optional when the step 980 is not performed.

In step 992, the MEF 630 notifies the AF 610 that the mission has been removed. The notification includes the MID and a removal indication indicating that the mission has been removed.

The embodiments described in association to the FIG. 9 allows a mission template associated to a mission to be removed dynamically and safely according to a request from the AF. The removal is performed in two steps: a logical delete (depreciation/deprecation) and a physical delete. Notification about the depreciation/deprecation is sent to the AF so that no new instance of the mission will be created or requested. The physical delete is performed after all mission instances of the mission are removed. Hence, the dynamical removal of the mission template does not impact usage of existing mission instances of the mission.

FIG. 10 shows a flow chart illustrating a method by an AF network entity in accordance with some embodiments of the present disclosure. In step 1010, the AF obtains first description information about a first mission, wherein the first description information includes at least one of: temporal validity condition indicating when the first mission is valid; spatial validity condition indicating where the first mission is valid; a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission; an application indication indicating at least one application that the first mission can support; interface information describing interfaces via which the first mission can be accessed; mission intent information describing a mission intent of the first mission; mission specification describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by the mission intent information; or at least one mission parameter that needs to be specified. In step 1020, the AF sends a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first description information about the first mission, and the first request indicates a management related to the first mission.

FIG. 11 shows another flow chart illustrating a method by an AF network entity in accordance with some embodiments of the present disclosure. In step 1110, the AF 610 sends a fourth request to a mission exposure function (MEF) network entity 630, wherein the fourth request indicates removing a second mission, and the fourth request includes a second mission ID identifying the second mission. In step 1120, the AF 610 receives a fourth response from the MEF network entity 630, the fourth response indicating that the second mission is deprecated if third description information about the second mission is deleted by a logical deletion, wherein the logical deletion indicates that the third description information is stored in a storage and has been processed.

FIG. 12 shows a flow chart illustrating a method by a MEF network entity in accordance with some embodiments of the present disclosure. In step 1210, the MEF 610 receives a first request from an application function (AF) network entity, wherein the first request includes first description information about the first mission, and the first request indicates a management related to the first mission and the first description information includes at least one of: temporal validity condition indicating when the first mission is valid; spatial validity condition indicating where the first mission is valid; a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission; an application indication indicating at least one application that the first mission can support; interface information describing interfaces via which the first mission can be accessed; mission intent information describing a mission intent of the first mission; mission specification information describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by the mission intent information; or at least one mission parameter that needs to be specified. In step 1220, the MEF 630 obtains second description information about the first mission, wherein the second description information is generated based on the first description information.

FIG. 13 shows a flow chart illustrating a method by a MEF network entity in accordance with some embodiments of the present disclosure. In step 1310, the MEF 630 receives a fourth request from an application function (AF) network entity 610, wherein the fourth request indicates removing a second mission, and the fourth request includes a second mission ID identifying the second mission. In step 1320, the MEF 630 sends a fifth request to a mission data repository (MDR) network entity 615, the fifth request including the second mission ID and instructing to remove third description information about the second mission.

FIG. 14 shows a flow chart illustrating a method by a SCF network entity in accordance with some embodiments of the present disclosure. In step 1410, the SCF 635 receives a second request from a mission exposure function (MEF) network entity 630, the second request instructing to generate a mission specification, and the second request including mission intent information that describes a goal of a first mission; and in step 1420, the SCF 635 sends a first mission specification to the 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.

FIG. 15 shows a flow chart illustrating a method by a MDR network entity in accordance with some embodiments of the present disclosure. In step 1510, the MDR 615 receives a fifth request from a mission exposure function (MEF) network entity 630, the fifth request including a second mission ID identifying a second mission and instructing to remove third description information about the second mission; and in step 1520, the MDR 615 sends a fifth response to the fifth request to the MEF network entity 630, the fifth response indicating a deletion type of the third description information, wherein the deletion type includes a physical deletion or a logical deletion, and the physical deletion indicates that the third description is removed from the storage, and the logical deletion indicates that the third description information is stored in a storage and has been processed.

Some embodiments of the present disclosure provide a network device. The network device 1600 is used for performing some steps of the method for mission management as described in the above embodiments/implementations. As shown in FIG. 16, the network device 1601 includes a processing module 1601 and a communication module 1602. The processing module 1601 is used for processing data units/signals. The communication module 1602 is used for transmitting (sending) and/or receiving data units/signals.

For example, the communication module 1602 may include communication interface (s) . The communication module 1602 may be a transceiver module to implement transmitting and/or receiving functions. In this case, the communication module 1602 may be an input/output interface or a transceiver.

In some examples, the network device 1600 corresponds to the AF 610, and performs the steps 810 and 870 of the method in the FIG. 8. In this case, the communication module 1602 performs the steps 810 and 870.

In some other examples, the network device 1600 corresponds to the AF 610, and performs the steps 1010 and 1020 of the method in the FIG. 10. In this case, the communication module 1602 performs the step 1020, and the processing module 1601 performs the step 1010.

In yet some other examples, the network device 1600 corresponds to the AF 610, and performs the steps 910, 960 and 992 of the method in the FIG. 9. In this case, the communication module 1602 performs the steps the steps 910, 960 and 992.

In yet some other examples, the network device 1600 corresponds to the AF 610, and performs the steps 1110 and 1120 of the method in the FIG. 11. In this case, the communication module 1602 performs the steps 1110 and 1120.

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

In yet some other examples, the network device 1600 corresponds to the MEF 630, and performs the steps 1210 and 1220 of the method in the FIG. 12. In this case, the communication module 1602 performs the step 1210, and the processing module 1601 performs the step 1220.

In yet some other examples, the network device 1600 corresponds to the MEF 630, and performs the steps 910, 920, 950, 960, 991 and 992 of the method in the FIG. 9. In this case, the communication module 1602 performs the steps 910, 920, 950, 960, 991 and 992.

In yet some other examples, the network device 1600 corresponds to the MEF 630, and performs the steps 1310 and 1320 of the method in the FIG. 13. In this case, the communication module 1602 performs the steps 1310 and 1320.

In yet some other examples, the network device 1600 corresponds to the SCF 635 (for example, the SCF 1and/or the SCF 2) , and performs the steps 8301, 8302, 8303, 8304 and 840 of the method in the FIG. 8. In this case, the communication module 1602 performs the steps 8301, 8303 and 8304, and the processing module 1601 performs the steps 8302 and 840.

In yet some other examples, the network device 1600 corresponds to the SCF 635 (for example, the SCF 1and/or the SCF 2) , and performs the steps 1410 and 1420 of the method in the FIG. 14. In this case, the communication module 1602 performs the steps 1410 and the step 1420.

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

In yet some other examples, the network device 1600 corresponds to the MDR 615, and performs the steps 1510 and 1520 of the method in the FIG. 15. In this case, the communication module 1602 performs the steps 1510 and the step 1520.

It should be noted that, as for the details, reference can be made to the above description, which will not be repeated here.

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

It will be noted that, beneficial effects of the network device are same as those of the method for mission management described in some of the above embodiments, and details will not be repeated here.

The above embodiments may be implemented in whole or in part through software, hardware, firmware, or any combination thereof. In a case where the above embodiments are implemented by using a software program, the software program may be implemented in whole or in part in a form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, the computer instructions generate some of all of the processes or functions provided in the embodiments of the present disclosure. The computer may be a general-purpose computer, a dedicated computer, a computer network, or any other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center through wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL) ) or wireless (e.g., infrared, wireless, microwave) methods. The computer-readable storage medium may be any available medium that may be accessed by the computer, or a server, a data center or any other data storage device including one or more available media. The available medium may be a magnetic medium (e.g., a floppy disk, a magnetic disk or a magnetic tape) , an optical medium (e.g., a digital versatile disk (DVD) ) , a semiconductor medium (e.g., a solid state drive (SSD) ) , or the like.

From description of the above embodiments, those skilled in the art will clearly understand that, for convenience and brevity of description, an example is only given according to the above division of functional modules. In practical applications, the above functions may be allocated to different functional modules to be completed as needed. That is, an internal structure of a device may be divided into different functional modules to perform all or part of the functions described above. For the specific working process of the above-described system, device, and module, reference may be made to the corresponding process in the foregoing method embodiments, and details will not be repeated here.

In several embodiments provided in the present disclosure, it will be understood that the disclosed systems, devices and methods may be implemented through other manners. For example, the device embodiments described above are merely exemplary. For example, the division of the functional modules is only a logical functional division. In actual implementation, there may be other division manners. For example, in some embodiments, a plurality of devices or components may be combined or integrated into another system, or some features may be ignored or not executed. 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 connections.

The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules. That is, they may be located in one place, or may be distributed to multiple network modules. Some or all of the modules may be selected according to practical needs to achieve the purposes of the solutions in the embodiments.

The functional modules in the embodiments of the present disclosure may be integrated into a single processing module; or, the modules may be separate physical modules; or, two or more modules may be integrated into a single module. The integrated module may be implemented in the form of hardware, or may be implemented in the form of software functional module.

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

Some embodiments of the present disclosure provide a computer-readable storage medium (e.g., a non-transitory computer-readable storage medium) . The computer-readable storage medium has stored thereon program instructions that, when run on a network device/second mission management device, cause the network device/second mission management device to execute one or more steps of the method for mission management as described in any one of the above embodiments.

For example, the computer-readable storage medium includes, but is not limited to, a magnetic storage device (e.g., a hard disk, a floppy disk or a magnetic tape) , an optical disk (e.g., a compact disk (CD) , or a DVD) , a smart card, and a flash memory device (e.g., an erasable programmable read-only memory (EPROM) , a card, a stick or a key driver) . Various computer-readable storage media described in the embodiments of the present disclosure may represent one or more devices and/or other machine-readable storage media, which are used for storing information. The term "computer-readable storage medium" may include, but is not limited to, wireless channels and various other media capable of storing, containing and/or carrying instructions and/or data.

Some embodiments of the present disclosure further provide a computer program product. The computer program product includes program instructions carried on a non-transitory computer-readable storage medium. When executed on a network device/second mission management device, the computer program instructions cause the network device/second mission management device to perform one or more steps of the method for mission management as described in the above embodiments.

Beneficial effects of the computer-readable storage medium and the computer program product are the same as the beneficial effects of the method for mission management as described in some of the above embodiments, and details will not be repeated here.

The foregoing descriptions are merely specific implementations of the present disclosure, but the protection scope of the present disclosure is not limited thereto. Any changes or replacements within the technical scope of the present disclosure shall be included in the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure shall be subject to the protection scope of the claims.

In some aspects of the present disclosure, there is provided a computer program comprising instructions. The instructions, when executed by a processor, may cause the processor to implement a method of the present disclosure.

In some aspects of the present disclosure, there is provided a non-transitory computer-readable medium storing instructions, the instructions, when executed by a processor, may cause the processor to implement a method of the present disclosure.

In some aspects of the present disclosure, there is provided an apparatus/chipset system comprising means (e.g., at least one processor) to implement a method implemented by (or at) a UE of the present disclosure. The apparatus/chipset system may be a network entity illustrated in this disclosure, e.g., AF, PCF, TCF, Device (that is, a terminal device) or a module/component in the network entity. In details, the at least one processor may execute instructions stored in a computer-readable medium to implement the method.

In some aspects of the present disclosure, there is provided a system comprising at least two of the mentioned network entities e.g., AF, PCF, TCF, Device illustrated in this disclosure.

In some aspects of the present disclosure, there is provided a method performed by a system comprising at least two of the mentioned network entities illustrated in this disclosure.

Please note that two or more of the network entities illustrated in this disclosure may be located in physical network entity, or to be implemented as a single function entity. In this case, the interaction between the two or more of the mentioned network entities may be not needed, i.e., the corresponding step (s) may be ignored (optional) .

Please note that although two or more network entities are illustrated in this disclosure, only one of them may be enough for an example solution in this disclosure. For example, in the example shown in FIG. 7, from AF side, only an AF request and response are needed. For operations executed by other network entities (e.g., step 3～5) , the AF does not see it (or they may be transparent to the AF) .

The solutions described in the disclosure is applicable to a next generation (e.g. sixth generation (6G) or later) network, or a legacy (e.g. 5G, 4G, 3G or 2G) network.

It will be appreciated that any module, component, or device disclosed herein that executes instructions may include, or otherwise have access to, a non-transitory computer/processor readable storage medium or media for storage of 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 cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, optical disks such as compact disc read-only memory (CD-ROM) , digital video discs or digital versatile discs (i.e., DVDs) , Blu-ray Disc^TM, or other optical storage, volatile and non-volatile, removable and non-removable media implemented in any method or technology, random-access memory (RAM) , read-only memory (ROM) , electrically erasable programmable read-only memory (EEPROM) , flash memory or other memory technology. Any such non-transitory computer/processor storage media may be part of a device/apparatus or accessible or connectable thereto. Computer/processor readable/executable instructions to implement a method, an application or a module described herein may be stored or otherwise held by such non-transitory computer/processor readable storage media.

It could be noted that the message in the disclosure could be replaced with information, which may be carried in one single message, or be carried in more than one separate message.

The terms “instruct” may be same as “request” or “indicate” in this disclosure unless the content clearly dictates otherwise.

The terms “apparatus” and “device” are used exchangeable.

In the disclosure, the word “a” or “an” when used in conjunction with the term “comprising” or “including” in the claims and/or the specification may mean “one” , but it is also consistent with the meaning of “one or more” , “at least one” , and “one or more than one” unless the content clearly dictates otherwise. Similarly, the word “another” may mean at least a second or more unless the content clearly dictates otherwise.

In the disclosure, the words “first” , “second” , etc., when used before a same term (e.g., ED, or an operating step) does not mean an order or a sequence of the term. For example, the “first ED” and the “second ED” , means two different EDs without specially indicated, and similarly, the “first step” and the “second step” means two different operating steps without specially indicated, but does not mean the first step have to happen before the second step. The real order depends on the logic of the two steps.

The terms “coupled” , “coupling” or “connected” as used herein can have several different meanings depending on the context in which these terms are used. For example, as used herein, the terms coupled, coupling, or connected can indicate that two elements or devices are directly connected to one another or connected to one another through one or more intermediate elements or devices via a mechanical element depending on the particular context.

Note that the expression “at least one of A or B” , as used herein, is interchangeable with the expression “A and/or B” . It refers to a list in which you may select A or B or both A and B. Similarly, “at least one of A, B, or C” , as used herein, is interchangeable with “Aand/or B and/or C” or “A, B, and/or C” . It refers to a list in which you may select: A or B or C, or both A and B, or both A and C, or both B and C, or all of A, B and C. The same principle applies for longer lists having a same format.

The present disclosure encompasses various embodiments, including not only method embodiments, but also other embodiments such as apparatus embodiments and embodiments related to non-transitory computer readable storage media. Embodiments may incorporate, individually or in combinations, the features disclosed herein.

The term “receives” , “detect” and “decode” as used herein can have several different meanings depending on the context in which these terms are used. For example, without special note, the term “receive” may indicate that information (e.g., DCI, or MAC-CE, RRC signaling or TB) is received successfully by the receiving node, which means the receiving side correctly detect and decode it. In this scenario, “receive” may cover “detect” and “decode” or may indicates same thing, e.g., “receive paging” means decoding paging correctly and obtaining the paging successfully, accordingly, “the receiving side does not receive paging” means the receiving side does not detect and/or decoding the paging. “paging is not received” means the receiving side tries to detect and/or decoding the paging, but not obtain the paging successfully. The term “receive” may sometimes indicate that a signal arrives at the receiving side, but does not mean the information in the signal is detected and decoded correctly, then the receiving side need perform detecting and decoding on the signal to obtain the information carried in the signal. In this scenario, “receive” , “detect” and “decode” may indicate different procedure at receiving side to obtain the information. Although this disclosure refers to illustrative embodiments, this is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the disclosure, will be apparent to persons skilled in the art upon reference to the description. When combining two or more embodiments, not all the features in the embodiments to be combined are necessary for the combination.

Features disclosed herein in the context of any particular embodiments may also or instead be implemented in other embodiments. Method embodiments, for example, may also or instead be implemented in apparatus, system, and/or computer program product embodiments. In addition, although embodiments are described primarily in the context of methods and apparatus, other implementations are also contemplated, as instructions stored on one or more non-transitory computer-readable media, for example. Such media could store programming or instructions to perform any of various methods consistent with the present disclosure.

Claims

A method performed by an application function (AF) network entity, the method comprising:

obtaining first description information about a first mission, wherein the first description information includes at least one of:

temporal validity condition indicating when the first mission is valid;

spatial validity condition indicating where the first mission is valid;

a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission;

an application indication indicating at least one application that the first mission can support;

interface information describing interfaces via which the first mission can be accessed;

mission intent information describing a mission intent of the first mission;

mission specification describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by mission intent information; or

at least one mission parameter to be specified; and

sending a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first description information about the first mission, and the first request indicates a management related to the first mission.
The method of claim 1, wherein the first description information includes the mission intent information, and the first request indicates creating the first mission.
The method of claim 2, further comprising:

receiving a first response from the MEF network entity, the first response indicating that the first request has been rejected or accepted.
The method of claim 3, wherein the first response indicates that the first request has been rejected; and

the first response further includes a reason for rejection, wherein the reason includes one of:

the first description information includes neither the mission intent nor the mission specification;

the first mission includes a sub-mission CB, and the sub-mission CB corresponds to a non-reusable mission; or

the first mission is deprecated.
The method of any of claims 1-4, wherein the first request indicates modifying at least one element of the first description information of the first mission.
A method 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 removing a second mission, and the fourth request includes a second mission ID identifying the second mission; and

receiving a fourth response from the MEF network entity, the fourth response indicating that the second mission is deprecated if third description information about the second mission is deleted by a logical deletion, wherein the logical deletion indicates that the third description information is stored in a storage and has been processed.
The method of claim 6, wherein the fourth response indicates that the second mission is removed if the third description information about the second mission is deleted by a physical deletion, wherein the physical deletion indicates that the third description information is removed from the storage.
A method 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 description information about the first mission, and the first request indicates a management related to the first mission and the first description information includes at least one of:

temporal validity condition indicating when the first mission is valid;

spatial validity condition indicating where the first mission is valid;

a reusability indication indicating whether the first mission can be used as a computing block (CB) in another mission;

an application indication indicating at least one application that the first mission can support;

interface information describing interfaces via which the first mission can be accessed;

mission intent information describing a mission intent of the first mission;

mission specification information describing interworking logic between one or more CBs of the first mission that are used for achieving a mission intent described by mission intent information; or

at least one mission parameter to be specified; and

obtaining second description information about the first mission, wherein the second description information is generated based on the first description information.
The method of claim 8, wherein the first description information includes the mission intent information.
The method of claim 9, wherein obtaining the second description information about the first mission includes:

obtaining a mission specification based on the mission intent, wherein the mission specification describes interworking logic between one or more CBs of the first mission that are used for achieving the mission intent; and

generating the second description information about the first mission, wherein the second description information includes the mission specification.
The method of claim 10, wherein obtaining the mission specification based on the mission intent includes:

sending a second request instructing to generate the mission specification to a first service control function (SCF) network entity, the second request including the mission intent information;

receiving, from the first SCF network entity, a second response including a first mission specification, wherein the first mission specification is generated by the first SCF network entity based on the mission intent; and

generating at least part of the mission specification based on the first mission specification.
The method of claim 11, wherein the first mission specification includes a CB ID of a sub-mission CB that corresponds to a third mission to be created and sub-mission intent information corresponding to the third mission;

and obtaining the mission specification based on the mission intent further includes:

sending a third request instructing to generate a sub-mission specification to a second SCF network entity, the third request including the sub-mission intent information, wherein the sub-mission specification describes interworking logic between one or more CBs of the sub-mission CB that are used for achieving a sub-mission intent described by the sub-mission intent information; and

receiving, from the second SCF network entity, a third response including a second mission specification, wherein the second mission specification is generated by the second SCF network entity based on the sub-mission intent.
The method of claim 11 or 12, wherein obtaining the mission specification based on the mission intent further includes:

generating the mission specification corresponding to the mission intent based on the first mission specification and the second mission specification.
The method of claim 13, wherein generating the mission specification corresponding to the mission intent based on the first mission specification and the second mission specification includes:

integrating the second mission specification into the first mission specification to generate the mission specification corresponding to the mission intent.
The method of any of claims 10-14, further comprising:

sending the second description information about the first mission to a mission data repository (MDR) network entity.
The method of any of claims 9-15, wherein the first description information about the first mission satisfies a predefined condition;

and the method further includes:

sending a first response to the AF network entity indicating that the first request has been rejected.
The method of claim 16, wherein the predefined condition includes at least one of:

the first description information includes neither the mission intent information nor the mission specification;

the first mission includes a sub-mission CB, and the sub-mission CB corresponds to a non-reusable mission; or

the first mission is deprecated.
The method of any of claims 11-17, further comprising:

sending a first confirmation to the first SCF network entity, the first confirmation indicating that the first mission specification has been accepted; and/or

sending a second confirmation to the second SCF network entity, the second confirmation indicating that the second mission specification has been accepted.
The method of any of claims 8-18, wherein any one of the second request and the first confirmation includes a first mission ID identifying the first mission, wherein the first mission ID is included in the first description information or generated by the MEF; and/or

any one of the third request and the second confirmation includes the first mission ID.
A method 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 removing 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, the fifth request including the second mission ID and instructing to remove third description information about the second mission.
The method of claim 20, further comprising:

receiving a fifth response from the MDR network entity, the fifth response indicating a deletion type of the third description information, wherein the deletion type includes a physical deletion indicating that the third description information is removed from the storage and/or a logical deletion indicating that the third description information is stored in a storage and has been processed.
The method of claim 21, further comprising:

sending a fourth response to the application function (AF) network entity, wherein the fourth response includes the second mission ID and indicates a state of the second mission, and the state corresponding to the deletion type.
The method of claim 22, wherein the state of the second mission corresponding to the physical deletion is that the second mission is unusable, and the state of the second mission corresponding to the logical deletion is that the second mission is deprecated.
The method of any one of claims 20-23 wherein fourth description information about the second mission satisfies a predefined condition, wherein the fourth description information is obtained based on the second mission ID;

and the method further comprising:

sending a sixth response to the AF, the sixth response indicating that the fourth request has been rejected.
The method of claim 24, wherein the predefined condition includes that the fourth description information about the second mission indicates that the second mission is a reusable mission and is being used.
The method of claim 24 or 25, further comprising:

sending the second mission ID to a target network entity; and

obtaining the fourth description information from the target network entity.
A method performed by a service control function (SCF) network entity, comprising:

receiving a second request from a mission exposure function (MEF) network entity, the second request instructing to generate a mission specification, and the second request including mission intent information that describes a mission intent 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.
The method of claim 27, further comprising:

determining one or more CBs of the first mission and a networking logic between the one or more CBs; and

generating the first mission specification, wherein the first mission specification includes a CB ID for each of the one or more CBs and the networking logic.
The method of claim 27 or 28, wherein the first mission specification includes a CB ID of a sub-mission CB that corresponds to a third mission to be created and sub-mission intent information corresponding to the third mission, and the sub-mission intent information describes a sub-mission intent; and

the method further includes:

receiving a third request from the MEF network entity, the third request instructing to generate a sub-mission specification, and the third request including the sub-mission intent information, wherein the sub-mission specification describes a networking logic between one or more CBs of the sub-mission CB that are used for achieving the sub-mission intent; and

sending a second mission specification to the MEF network entity, wherein the second mission specification serves as part of the mission specification corresponding to the mission intent, and the second mission specification is generated by the SCF network entity based on the sub-mission intent.
The method of any one of claims 27-29, further comprising:

receiving a first confirmation from the MEF network entity, the first confirmation indicating that the first mission specification has been accepted.
The method of claim 30, further comprising:

receiving a second confirmation from the mission exposure function network entity, the second confirmation indicating that the second mission specification has been accepted.
The method of any one of claims 27-31, wherein any one of the second request and the first confirmation includes a first ID identifying the first mission; and/or

any one of the third request and the second confirmation further includes the first ID identifying the first mission.
A method performed by a mission data repository (MDR) network entity, comprising:

receiving a fifth request from a mission exposure function (MEF) network entity, the fifth request including a second mission ID identifying a second mission and instructing to remove third description information about the second mission; and

sending a fifth response to the fifth request to the MEF network entity, the fifth response indicating a deletion type of the third description information, wherein the deletion type includes a physical deletion or a logical deletion, and the physical deletion indicates that the third description is removed from the storage, and the logical deletion indicates that the third description information is stored in a storage and has been processed.
The method of claim 33, further comprising:

in the case where the second mission includes a mission instance, removing the third description information by adopting the logical deletion; or

in the case where the second mission includes no mission instance, processing the third description information by adopting the physical deletion.
The method of claim 33 or 34, further comprising:

sending a sixth request to a mission instance repository (MIR) network entity, the sixth request including the second mission ID and instructing the MIR network entity to send one or more notifications about an information change related to the second mission.
The method of claim 35, further comprising:

receiving a sixth response to the sixth request from the MIR network entity, wherein the sixth response includes an instance ID identifying a mission instance of the second mission and indicates the information change about the mission instance, and the information change indicates that the mission instance has been created for the second mission or has been removed.
The method of claim 36, further comprising:

determining whether the second mission includes a mission instance according to the sixth response.
The method of claim 37, wherein determining whether the second mission includes a mission instance according to the sixth response includes:

determining a number of existed instances of the second mission according to the instance ID and the information change corresponding to the instance ID; and

if the number is equal to 0, determining that the second mission includes no mission instance.
An apparatus, comprising:

at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of claims 1 to 5, or claims 6 to 7.
An apparatus, comprising:

at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of claims 8 to 19, or claims 20 to 26.
An apparatus, comprising:

at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of claims 27 to 32.
An apparatus, comprising:

at least one processor for executing the computer program instructions stored in a memory, to cause the apparatus to implement the method of any one of claims 33 to 38.
A system, comprising:

the apparatus of claims 1 to 5, the apparatus of claims 8 to 19; and

the apparatus of claims 27 to 32.
A system, comprising:

the apparatus of claims 6 to 7, the apparatus of claims 20 to 26; and

the apparatus of claims 33 to 38.
A computer-readable storage medium having stored thereon computer program instructions that, when executed by a processing circuit of a computer, cause the computer to implement the method of any one of claims 1 to 5, claims 6 to 7, claims 8 to 19, claims 20 to 26, claims 27 to 32, or claims 33 to 38.
A computer program product having instructions that, when executed by a computer, cause the computer to implement the method of any one of claims 1 to 5, claims 6 to 7, claims 8 to 19, claims 20 to 26, claims 27 to 32, or claims 33 to 38.
A chip system comprising: a processing circuit and a storage medium, wherein the storage medium has stored thereon computer program instructions that, when executed by the processing circuit cause the chip system to implement the method of any one of claims 1 to 5, claims 6 to 7, claims 8 to 19, claims 20 to 26, claims 27 to 32, or claims 33 to 38.