WO2025065987A1

WO2025065987A1 - Method, apparatus and system for managing mission instance

Info

Publication number: WO2025065987A1
Application number: PCT/CN2024/074117
Authority: WO
Inventors: Xu Li; Chenchen YANG; Weisen SHI; 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 is provided. The method includes: obtaining first mission instance information about a first mission instance of a first mission, wherein the first mission instance information includes at least one of: a mission instance identifier (MIID) identifying the first mission instance; amission identifier (MID) identifying the first mission; instantiation information describing at least one CB instance in the first mission instance; execution pattern information describing a pattern of executing the first mission on the first mission instance; authorization information indicating a plurality of devices allowed to access the first mission instance; temporal validity condition indicating when the first mission instance is valid; spatial validity condition indicating where the first mission instance is valid; or application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and sending a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first mission instance information, and the first request indicates a management related to the first mission instance.

Description

METHOD, APPARATUS AND SYSTEM FOR MANAGING MISSION INSTANCE

This application claims the priority of U.S. Provisional Patent Application No. 63/586, 636, 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 instance, 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 managing a mission instance.

According to a first aspect, a method is provided. The method is performed by application function (AF) . The method includes: obtaining first mission instance information about a first mission instance of a first mission, wherein the first mission instance information includes at least one of following elements: a mission instance identifier (MIID) identifying the first mission instance; amission identifier (MID) identifying the first mission; instantiation information describing at least one CB instance in the first mission instance; execution pattern information describing a pattern of executing the first mission on the first mission instance; authorization information indicating a plurality of devices allowed to access the first mission instance; temporal validity condition indicating when the first mission instance is valid; spatial validity condition indicating where the first mission instance is valid; or application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and sending a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first mission instance information, and the first request indicates a management related to the first mission instance.

In some embodiments, the management includes creating the first mission instance, and the first mission instance is to be created for a first application related to the first mission; and the first mission instance information includes at least one of a first mission ID identifying the first mission, a first application ID identifying the first application or an application service ID identifying a service provided by the first application.

In some embodiments, the first mission instance information further includes a first mission instance ID (MIID) identifying the first mission instance.

In some embodiments, the method further comprises receiving a first response from the MEF network entity, and 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 that the first application is not supported by the first mission.

In some embodiments, the first request indicates modifying at least one element of the first mission instance information of the first mission.

The beneficial effects brought by the first aspect is that the AF provides mission instance information associated to a mission to the system (for example, the MEF network entity) and requests the system to create a mission instance for the mission. The system will generate a mission instance for the mission according to the AF request. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a second aspect, a method is provided. The method is performed by application function (AF) , and the method comprises: sending a fourth request to a mission exposure function (MEF) network entity, wherein the fourth request includes mission selection assistance information (MSAI) for identifying a second mission instance of a second mission and indicates removing the second mission instance of the second mission; and receiving a fourth response from the MEF network entity, the fourth response indicating that the second mission instance has been removed.

In some embodiments, the fourth response includes the MSAI and at least one of an application ID identifying an application associated to the second mission instance or an application service ID identifying the application associated to the second mission instance.

The beneficial effects brought by the second aspect is that the AF provides mission instance information associated to a mission instance to the system (for example, the MEF network entity) and requests the system to delete the mission instance for the mission. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a third aspect, a method is provided. The method is performed by a mission exposure function (MEF) network entity, and the method comprises: receiving a first request from an application function (AF) network entity, wherein the first request indicates a management related to a first mission instance of a first mission, and the first request includes first mission instance information about the first mission instance, wherein the first mission instance information includes at least one of: a mission instance identifier (MIID) identifying the first mission instance; amission identifier (MID) identifying the first mission; instantiation information describing at least one CB instance in the first mission instance; execution pattern information describing a pattern of executing the first mission on the first mission instance; authorization information indicating a plurality of devices allowed to access the first mission instance; temporal validity condition indicating when the first mission instance is valid; spatial validity condition indicating where the first mission instance is valid; or application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and obtaining second mission instance information about the first mission instance, wherein the second mission instance information is generated based on the first mission instance information.

In some embodiments, if the first MIID is not included in the first mission instance information, generating the first MIID.

In some embodiments, the method further comprises: obtaining mission information about the first mission from mission data repository (MDR) , wherein the mission information includes application indication indicating at least one application that the first mission is associated to; and according to the application indication and at least one of the first application ID or the application service ID, validating that whether the first mission supports the first application.

In some embodiments, if the first mission does not support the first application, sending a first response to the AF network entity, wherein the first response indicates that the first request has been rejected.

In some embodiments, the first response further indicates a reason for a rejection of the first request.

In some embodiments, if the first mission supports the first application and the first mission instance information does not include the instantiation information, creating the at least one computing block (CB) instance for the first mission instance.

In some embodiments, creating the at least one CB instance for the first mission instance includes: sending a second request to a service control function (SCF) network entity, wherein the second request includes a CB identifier (CBID) identifying a CB and instructs/requests/indicates the SCF network entity to create the CB instance for the CB; and receiving a second response from the SCF network entity, wherein the second response indicates that the CB instance has been created.

In some embodiments, the first mission includes a task CB and the SCF network entity includes a first SCF network entity, and sending the second request to the SCF network entity includes: sending the second request to the first SCF network entity, wherein the second request includes a task CB identifier (CBID) identifying the task CB and instructs/requests/indicates the first SCF network entity to create the task CB instance for the task CB; and receiving the second response from the first SCF network entity, wherein the second response indicates that the task CB instance has been created.

In some embodiments, the second response includes a task CB instance identifier (CBIID) identifying the task CB instance, and the task CBIID is generated by the first SCF network entity.

In some embodiments, the first mission includes a sub-mission CB and the SCF network entity includes a second SCF network entity, and sending the second request to the SCF network entity includes: sending the second request to the second SCF network entity, wherein the second request includes a sub-mission CB identifier (CBID) identifying the sub-mission CB and instructs/requests/indicates the second SCF network entity to create the sub-mission CB instance for the sub-mission CB; and receiving the second response from the second SCF network entity, wherein the second response indicates that the sub-mission CB instance has been created.

In some embodiments, the method further comprises: sending a third request to a mission control function (MCF) network entity, wherein the third request instructs/requests/indicates the MCF network entity to establish communication tunnels between CB instances that have been created for the first mission instance; and receiving a third response from the MCF network entity, wherein the third response indicates that the communication tunnels have been created.

In some embodiments, the second mission instance information includes at least one of: the first MIID, the task CBID, the task CBIID, the sub-mission CBID, or the sub-mission CBIID.

In some embodiments, the method further comprises: sending the second mission instance information to a mission instance repository (MIR) network entity.

In some embodiments, the method further comprises: sending a first response to the AF network entity, wherein the first response indicates that the first request has been accepted and the first response includes mission selection assistance information (MSAI) for selecting the first mission instance.

In some embodiments, the management includes modifying at least one element of the first mission instance information of the first mission instance.

The beneficial effects brought by the third aspect is that the AF provides mission instance information associated to a mission to the system (for example, the MEF network entity) and requests the system to create a mission instance for the mission. The system will generate a mission instance for the mission according to the AF request. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a fourth aspect, a method is provided. The method is performed by a mission exposure function (MEF) network entity, and the method comprises: receiving a fourth request from an application function (AF) network entity, wherein the fourth request includes mission selection assistance information (MSAI) for identifying a second mission instance of a second mission and indicates removing the second mission instance of the second mission; obtaining mission instance information associated to the second mission instance; and if the second mission is being executed over the second mission instance, terminating execution of the second mission by using a first mission control function (MCF) network entity; and according to the mission instance information, removing at least one computing block (CB) instance of the second mission instance.

In some embodiments, obtaining the mission instance information associated to the second mission instance includes: sending a second mission instance ID (MIID) identifying the second mission instance to a mission instance repository (MIR) network entity; and receiving the mission instance information from the MIR network entity.

In some embodiments, the method further comprises: sending the second MIID to a target network entity; and receiving information identifying the first MCF from the target network entity, wherein the information identifying the first MCF is determined based on the second MIID.

In some embodiments, removing the at least one CB instance of the second mission instance includes: sending a fifth request to a service control function (SCF) network entity, wherein the fifth request includes a CB instance identifier (CBIID) identifying the CB instance, and the CBIID is included in the mission instance information, and the fifth request requests the SCF network entity to remove the CB instance; and receiving a fifth response from the SCF network entity, wherein the fifth response indicates that the CB instance has been removed.

In some embodiments, the fifth response includes the CBIID.

In some embodiments, the at least one CB instance includes a task CB instance and the SCF network entity includes a third SCF network entity, and removing the at least one CB instance of the second mission instance includes: sending the fifth request to the third SCF network entity, wherein the fifth request includes a task CBIID identifying the task CB instance, and the fifth request requests the third SCF network entity to remove the task CB instance; and receiving the fifth response from the third SCF network entity, wherein the fifth response indicates that the task CB instance has been removed.

In some embodiments, the at least one CB instance includes a sub-mission CB instance, and the SCF network entity includes a fourth SCF network entity, and removing the at least one CB instance of the second mission instance includes: sending the fifth request to the fourth SCF network entity, wherein the fifth request includes a sub-mission CBIID identifying the sub-mission CB instance, and the fifth request requests the fourth SCF network entity to remove the sub-mission CB instance; and receiving the fifth response from the fourth SCF network entity, wherein the fourth response indicates that the sub-mission CB instance has been removed.

In some embodiments, the method further comprises: releasing communication resources associated to the second mission instance by using a second MCF.

In some embodiments, the method further comprises: sending a sixth request to the MIR network entity, wherein the sixth request includes the second MIID and requests the MIR network entity to remove the mission instance information; and receiving a sixth response from the MIR network entity, the sixth response confirming that the mission instance information has been removed.

The beneficial effects brought by the fourth aspect is that the AF provides mission instance information associated to a mission instance to the system (for example, the MEF network entity) and requests the system to delete the mission instance for the mission. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a fifth aspect, a method performed by a service control function (SCF) network entity is provided, and the method comprises: receiving a second request from a mission exposure function (MEF) network entity, wherein the second request includes a computing block identifier (CBID) identifying a computing block (CB) and instructs/requests/indicates to create a CB instance for the CB;and sending a second response to the MEF network entity, wherein the second response indicates that the CB instance has been created.

In some embodiments, a CB instance identifier (CBIID) identifying the CB instance is included in the second request or generated by the SCF network entity.

In some embodiments, the method further comprises: creating the CB instance according to information describing composition and functionalities of the CB, wherein the information corresponds to the CBID.

In some embodiments, creating the CB instance includes: sending the CBIID to a first task resource network entity allocated to the CB instance, wherein the CBIID is for indicating that the first task resource network entity.

In some embodiments, the method further comprises: sending association information to the first task resource network entity, wherein the association information indicates that the first task resource is associated to a second task resource network entity allocated to the CB instance.

In some embodiments, the association information includes a resource ID or a network address of the second task resource network entity.

In some embodiments, creating the CB instance further includes: sending registration request including a resource ID and/or a network address of the first task resource network entity, the CBID, and the association information to a network repository function (NRF) network entity.

In some embodiments, the CB includes a task CB and/or a sub-mission CB.

The beneficial effects brought by the fifth aspect is that the AF provides mission instance information associated to a mission to the system (for example, the MEF network entity) and requests the system to create a mission instance for the mission. The system will generate a mission instance for the mission according to the AF request. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a sixth aspect, a method performed by a service control function (SCF) network entity is provided, and the method comprises: receiving a fifth request from a mission exposure function (MEF) network entity, wherein the fifth request includes a CB instance identifier (CBIID) identifying a computing block (CB) instance, and the fifth request instructs/requests/indicates the SCF network entity to remove the CB instance; and sending a fifth response to the MEF network entity, wherein the fifth response indicates that the CB instance has been removed.

In some embodiments, the fifth response includes the CBIID.

In some embodiments, the method further comprises: releasing a task resource network entity associated to the CB instance to remove the CB instance.

In some embodiments, releasing the task resource network entity includes: sending the CBIID to the task resource network entity, wherein the CBIID is for indicating that the task resource network entity is released from the CB instance.

In some embodiments, the method further comprises: sending deregistration request including the CBIID to an NRF.

In some embodiments, the CB instance includes a task CB instance and/or a sub-mission CB instance.

The beneficial effects brought by the sixth aspect is that the AF provides mission instance information associated to a mission instance to the system (for example, the MEF network entity) and requests the system to delete the mission instance for the mission. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a seventh aspect, a method performed by a mission control function (MCF) network entity is provided, the method comprises: receiving a third request from a mission exposure function (MEF) network entity, wherein the third request instructs/requests/indicates the MCF network entity to establish communication tunnels between CB instances that have been created for a first mission instance; and sending a third response to the MEF network entity, wherein the third response indicates that the communication tunnels have been created.

In some embodiments, the method further comprises: determining how one or more processing service functions (PSFs) belonging to different CB instances should interconnect; and configuring the communication tunnels between the one or more PSFs and one or more GW (s) .

The beneficial effects brought by the seventh aspect is that the AF provides mission instance information associated to a mission to the system (for example, the MEF network entity) and requests the system to create a mission instance for the mission. The system will generate a mission instance for the mission according to the AF request. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to an eighth aspect, a method performed by a mission control function (MCF) network entity is provided, the method comprises: receiving a termination request from a mission exposure function (MEF) network entity, wherein the termination request includes a second mission instance ID (MIID) identifying a second mission instance of a second mission and instructs/requests/indicates the MEF network entity to terminate an execution of the second mission instance; and sending a termination response to the MEF network entity, wherein the termination response indicates that the execution of the second mission has been terminated.

The beneficial effects brought by the eighth aspect is that the AF provides mission instance information associated to a mission instance to the system (for example, the MEF network entity) and requests the system to delete the mission instance for the mission. Thus, a less capable AF is allowed and a mission instance can be managed by the system.

According to a ninth aspect, an apparatus is provided, and the apparatus comprises: at least one processor coupled with a memory storing thereon computer program instructions, to cause the apparatus to implement the method of the first aspect or the second aspect.

According to a tenth aspect, an apparatus is provided, and the apparatus comprises: at least one processor coupled with a memory storing thereon computer program instructions, to cause the apparatus to implement the method of any one of the third aspect, or the fourth aspect.

According to an eleventh aspect, an apparatus is provided, and the apparatus comprises: at least one processor coupled with a memory storing thereon computer program instructions, to cause the apparatus to implement the method of the fifth aspect or the sixth aspect.

According to a twelfth aspect, an apparatus is provided, and the apparatus comprises: at least one processor coupled with a memory storing thereon computer program instructions, to cause the apparatus to implement the method of the seventh aspect or the eighth aspect.

According to a thirteenth aspect, a system is provided, and the system comprises: the apparatus of the ninth aspect, the apparatus of the tenth aspect; the apparatus of the eleventh aspect and the apparatus of the twelfth aspect.

According to a fourteenth aspect, 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 the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, the sixth aspect, the seventh aspect or the eighth aspect.

According to a fifteenth aspect, 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, the sixth aspect, the seventh aspect or the eighth aspect.

According to a sixteenth aspect, 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 the first aspect, the second aspect, the third aspect, the fourth aspect, the fifth aspect, the sixth aspect, the seventh aspect or the eighth aspect.

The advantages brought by any design from the ninth to sixteenth aspects can be referred to the first aspect to the eighth 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 instance in accordance with some embodiments of the present disclosure; and

FIG. 9 shows a signaling chart of removing mission instance information 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 another 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 another flow chart illustrating a method by a SCF network entity in accordance with some embodiments of the present disclosure;

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

FIG. 17 shows a flow chart illustrating a method by a MCF network entity in accordance with some embodiments of the present disclosure; and

FIG. 18 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.

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 sidelink 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 sidelink shared 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 instance or remove a mission instance as described in this disclosure. For example, in the present disclosure, creating a mission instance refers to creating description information of the mission instance (the description information is also referred to as mission instance information) . The mission instance information can be in any form, for example, in the form of mission instance template. The details relating to the mission instance information will be further described below. Likewise, updating a mission instance refers to update the mission instance information, for example, updating at least one element of the mission instance information. And removing a mission instance refers to remove the description information of the mission instance, that is, the mission instance information. 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. 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 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. 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 (also referred to as an external 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.

An instance of a mission (i.e., a mission instance) is described using mission instance information. The mission instance information includes one or multiple information elements as illustrated in the Table 1.

Table 1 Mission instance information

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

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

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

Instantiation information, which describes CB instances in the mission instance and is generated by the MM. This information includes a list of CBIIDs. Each of the CBIIDs identifies a CB instance, and the CB instance corresponds to a CB in the mission. For a CB instance, this information includes a list of CBIAI (s) , each identifying an access point to the CB instance. If two CB instances should be interconnected (e.g. as described in the mission information associated to the mission) , this information may further indicate how the two CB instances are interconnected, for example, by including a list of tunnel information (s) each corresponding to a tunnel between an access point of one of the CB instances and an access point of the other CB instance. A tunnel information may include, e.g., a tunnel ID, a tunnel end point ID, and a tunnel protocol ID.

Execution pattern information, which describes a pattern of executing the mission on the mission instance. This information describes when (for example, in the forms of time of the day, day of the week, week of the month, month of the year) or under what condition (s) (for example, in the forms of event IDs) an execution of the mission on the mission instance should be started, paused, resumed, stopped, or terminated. The MCF may obtain the execution pattern information as part of the mission instance information from the MIR, and according to the execution pattern information, the MCF can starts, pause, resume, stop or terminate the mission execution when the MCF coordinates the mission execution.

Authorization information, which indicates device (s) that are allowed to access the mission instance. This information may include a of list of ID (s) or network address (es) , each identifying a device or a device group. This information may include one or multiple wildcards. A device identified in, or belonging to a device group identified in this information is considered allowed to access the mission instance.

Temporal validity condition. This information indicates when (e.g. in terms of time) the mission instance is valid or available. 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.

Spatial validity condition. This information indicates where the mission instance is valid or available. 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.

Application information, which indicates a list of application (s) that the mission instance is associated to. This information may include a list of ASID (s) , each identifying an application. For each application, this information further specifies value (s) for mission parameter (s) of the mission. The mission parameter (s) is (are) parameter (s) associated to the mission and related to, functionalities/behaviors of one or multiple CBs in the mission. In the present disclosure, the application information may be also referred to as application indication.

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

In some embodiments, the AF 610 may request to manage a mission instance. For example, the AF 610 obtains mission instance information about a mission instance, 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 instance and the request indicates a management related to the mission instance. For ease of description and for ease in distinguishing between different mission instances (for example, the mission instance to be created and the mission instance to be removed) , the mission instance to be managed (for example, the mission instance to be updated or to be created) is also referred to as a first mission instance, and the description information is referred to as first mission instance information.

In some embodiments, the first mission instance information may be part of the entire mission instance information of the first mission instance. In other words, the first mission instance information includes at least one element in the entire mission instance information as described in the Table 1. For example, the first mission instance information includes any one or multiple of : the mission instance identifier (MIID) identifying the first mission instance; the mission identifier (MID) identifying the first mission; the instantiation information describing at least one CB instance in the first mission instance; the execution pattern information describing a pattern of executing the first mission on the first mission instance; the authorization information indicating a plurality of devices allowed to access the first mission instance; the temporal validity condition indicating when the first mission instance is valid; the spatial validity condition indicating where the first mission instance is valid; and the application information indicating, at least one application that the first mission instance is associated to, and specifying, a value of a mission parameter associated to the at least one application. Besides, the application information may further include respective meta-data describing usage of the mission parameter.

In some embodiments, the management related to the first mission instance includes modifying at least one element of the first description information (for example, at least one element of the mission instance information) of the first mission instance. For example, modifying the temporal validity condition from one time interval (or duration) to another time interval (or duration) . For another example, modifying the execution pattern information from one pattern to another pattern.

In some embodiments, the management related to the first mission instance includes creating the first mission instance for a first application related to the first mission, for example, generating second description information based on the first description information. For example, the first description information includes a first mission ID of the first mission but does not include the instantiation information. In other words, the first description information does not include information describing at least one CB instance in the first mission instance. In this case, the MEF generates the instantiation information. Furthermore, the MEF generates the second description information including the instantiation information. The procedure of generating the second description information will be described in further details below. The MEF may create the at least on CB instance by using one or multiple SCFs, as further described below.

Reference is now made to FIG. 8, which shows a signaling chart 800 for creating/updating a mission instance according to some embodiments of the present disclosure. The signaling chart 800 involves the AF 610, the MDR 615, the MIR 620, the MCF 625, the MEF 630, the SCF 635 and the NET4CON 536. In the FIG. 8, the SCF 635 is an XaaS service. 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, mission instance information (or at least a part of the mission instance information as shown in the table 1) is provisioned from the AF 610 and stored in the MDR 615 when the AF 610 requests to create an instance (for example, the first mission instance as described above) of a mission (for example, the first mission as described above) for an application (i.e. to support an application) . The mission instance information is associated to the instance of the mission. The procedure for creating a mission instance includes one or more of following steps:

In step 810, the AF 610 requests to create an instance of a mission for an application, by sending an AF request to the MEF 630. Accordingly, the MEF 630 receives the AF request from the AF610.

In some embodiments, the AF request includes an AF-Service-Identifier, which may be associated or corresponding to a contract (the contract, for example, being between the system and the party represented by or owning/operating/managing the AF) and be used by the MEF 630 to authorize the AF request. Besides, the AF request includes mission instance information. The mission instance information includes at least one of an MID identifying the mission and an ASID (e.g., in the form of DNN) identifying the application. Alternatively, or additionally, the mission instance information may include an application ID identifying the application. Alternatively, or additionally, the mission instance information may include a MIID that identifies the instance of the mission (i.e., the mission instance) to be created. The content of the mission instance information is further described in the Table 1.

In the present disclosure, the AF request in the steps 810-860 is also referred to as first request. In steps 810-860, the instance to be created is also referred to as a first mission instance, and the mission related to the instance to be created is also referred to as a first mission. The application that the instance is created for is also referred to as a first application. Furthermore, the mission instance information included in the AF request is also referred to as first mission instance information.

In other words, in the step 810, the AF 610 sends a first request to the MEF 630, and the first request indicates a management related to the first mission instance of the first mission (the management in this step 810 corresponds to creating the first mission instance) , and the first request includes first mission instance information about the first mission instance. Besides, the first mission instance information may include at least one information element of the information elements as described in the Table 1. In the case where the AF request indicates creating the first mission instance, the first mission instance information includes at least one of a first mission ID identifying the first mission, a first application ID identifying the first application or an application service ID identifying a service provided by the first application.

In some embodiments, the first mission instance information may further include a first mission instance ID (MIID) identifying the first mission instance.

In step 820, the MEF 630 validates the mission usage.

In some embodiments, the MEF 630 validate that the mission can support the application based on local configuration or using the MDR 615. For example, the MEF 630 obtains mission template associated to the mission from the MDR 615.

The mission template includes one or multiple information elements as illustrated in the Table 2.

Table 2 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/or possibly an end time too.

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 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.

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 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 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. 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) .

In some embodiments, the MEF 630 may interact with the MDR 615 to obtain the mission template or the application indication in the mission template. For example, The MEF 630 sends the MID to the MDR 615. The MDR 615 identifies the mission template using the MID and sends the application indication in the mission template (or the entire mission template including the application indication) to the MEF 630 in response. In this way, according to the application indication and the AID, the MEF 630 validates that the mission can support the application.

As described above, the mission is also referred to as the first mission. Correspondingly, in other words, in this step, the MEF 630 obtains mission information (that is, the mission template as described above) about the first mission from the MDR 615. Referring to the table 2 as described above, the mission information includes the application indication indicating at least one application that the first mission is associated to. In this way, the MEF 630 validates that whether the first mission supports the first application according to the application indication and at least one of the first application ID or the application service ID, wherein the first application ID or the application service ID is included in the first mission instance information (that is, the mission instance information carried in the first request) as described above. For example, if the at least one application indicated by the application indication includes an application corresponds to the first application ID or the application service ID, it is considered as that the first mission supports the first application. Otherwise, it is considered that the first mission does not support the first application.

Optionally, if the validation fails, the MEF 630 sends a response to the AF 610 to reject the AF request and the procedure stops. The response may include a cause value or code indicating the reason why the AF request is rejected.

In the present disclosure, the response is also referred to as a first response to the first request. That is, if the first mission does not support the first application, which means that the validation fails, the MEF 630 sends the first response to the AF 610, wherein the first response indicates that the first request has been rejected.

In some embodiments, the first response further indicates a reason for a rejection of the first request. For example, the reason may be that the first mission does not support the first application.

In some embodiments, if the first mission supports the first application, which means that the AF request has passed the validation, and further if the first mission instance information (that is, the information included in the AF request) does not include the instantiation information which describes at least one CB instance in the first mission instance, the MEF 630 creates at least one computing block (CB) instance for the first mission instance. In details, the MEF 630 interacts with the SCF 635 to create the at least one CB instance. In one implementation, the MEF 630 sends a request to the SCF 635. The request is also referred to as a second request in the present disclosure, and the second request includes a CB identifier (CBID) identifying a CB and instructs/requests/indicates the SCF network entity to create the CB instance for the CB.

In some embodiments, the first mission includes one or more task CBs and/or one or more sub-mission CBs. Correspondingly, one or more task CB instances and/or one or more sub-mission CB instances are to be created.

In the following, the procedure for creating a task CB instance will be further described below.

In step 830, the MEF 630 generates an MIID to identify the mission instance. This step is optional if an MIID is already included in the mission instance information carried in the AF request.

In the present disclosure, since the MIID is for identifying the first mission instance, the MIID is also referred to as a first MIID.

In step 840, the MEF 630 creates a task CB instance (also called CB instance) .

This step is optional if the mission (that is, the first mission as described above) includes no task CB.

In some embodiments, for each task CB of the mission that is supported by an XaaS service as identified in the mission template, the MEF 630 interacts with an SCF 635 to create a CB instance for the task CB. The SCF 635 is selected from SCFs associated to the XaaS service. The CB instance includes task resources (i.e. TCF (s) , PSF (s) ) allocated for the CB instance and is part of the mission instance. The task resources are selected by the SCF 635 from those associated to the XaaS service; each of them can be identified by a resource ID (e.g., a TCF ID or a PSF ID. Or a network address (e.g., an IP address or an Ethernet address) . In the present disclosure, a task resource is also referred to as a task resource network entity. One or more task resource network entities are allocated to a CB instance. In this way, the said CB instance includes the said task resource network entities and the mission related to the mission instance can be executed through the task resource network entities.

In details, the step 840 may include at least one of the following sub-steps:

In step 8401, the MEF 630 sends a CB instance creation request to the SCF 635. Accordingly, the SCF 635 receives the request. The request includes a CBID that identifies the CB.

In some embodiments, the request may include a CBIID identifying the CB instance and being generated by the MEF 630. In some embodiments, the request may not include the CBIID and the CBIID may be generated by the SCF 635.

In the present disclosure, the CB instance creation request is also referred to as the second request. For ease in distinguishing different SCFs for creating task CB instance and sub-mission CB instance, the SCF for generating the task CB is also referred to as a first SCF. That is, in this step, the MEF 630 sends the second request to the first SCF. The second request includes a task CB identifier (CBID) identifying the task CB and instructs/requests/indicates the first SCF to create the task CB instance for the task CB.

It is understandable that if a plurality of task CB instances are to be created, the MEF 630 may interact with different SCFs to create the plurality of task CB instances. For example, the MEF 630 may interact with SCF1 to create one task CB instance and interact with SCF 2 to create another task CB instance.

In step 8402, the SCF 635 creates the CB instance (that is, the task CB instance for the task CB) .

For example, after receiving the CB instance creation request, the SCF 635 creates the CB instance according to information describing composition and functionalities of the CB, the information being corresponding to the CBID. The information is obtained from the mission information of the mission, for example, from the mission template of the mission, as described in the table 2.

In some embodiments, if the CB instance creation request (that is, the second request) does not include a CBIID for identifying the CB instance, the SCF 635 generates a CBIID to identify the CB instance as described above.

In some embodiments, the SCF 635 configures the CB instance by configuring each of the task resources in the CB instance.

For example, the SCF 635 sends the CBIID to a first task resource (network entity) in the CB instance, wherein the CBIID is for indicating that the first task resource (network entity) is allocated to the CB instance. The first task resource (network entity) here refers to any task resource (network entity) in the CB instance, e.g. a PSF or a TCF.

In other words, when configuring a task resource (i.e., a PSF or a TCF) in the CB instance, the SCF 635 provides the CBIID (provided by the MEF 630 in the step 8401 or generated by the SCF 635) to the task resource, indicating that the task resource is allocated to the CB instance (identified by the CBIID) .

Optionally, the SCF 635 may send association information to the first task resource, wherein the association information indicates that the first task resource is associated to a second task resource within the CB instance. Moreover, the association information may include a resource ID or a network address of the second task resource. The second task resource here refers to a task resource that is different from the first task resource in the CB instance.

In other words, when configuring a task resource (i.e., a PSF or a TCF) in the CB instance, the SCF 635 may provide association information that indicates the task resource is associated to some other task resource (s) , e.g., TCF (s) or PSF (s) , within the CB instance. The association information may include resource ID (s) or network address (es) of the other task resources. The association between two task resources a PSF and a TCF implies that the PSF can be controlled or managed by the TCF, for example, for tunnel end configuration as described in the step 860.

In some embodiments, after configuring a task resource as described above, the SCF 635 may perform a registration for the task resources with a network repository function (NRF) .

In one implementation, the SCF 635 sends registration request including a resource ID and/or a network address of the first task resource, the CBID, and the association information to the NRF. In other words, the SCF 635 sends registration information including a resource ID and/or a network address of the task resource (for example, the first task resource) , the CBID, and the association information to the NRF.

In another implementation, the task resource performs self-registration with the NRF. In other words, alternatively, the task resource, after being configured by the SCF 635 as described above, performs self-registration with the NRF. For example, the task resource sends the registration information to the NRF by itself.

Accordingly, the NRF stores the registration information of the task resource, whether received from the SCF 635 or from the task resource, and associates the registration information to a profile of the task resource (e.g., by storing it as part of the profile of the task resource) .

In step 8403, the SCF 635 sends a CB instance creation response. The SCF 635 responds to the MEF 630, by using a CB instance creation response. The response is sent to the MEF 630 and indicates that the CB instance has been created. The CB instance creation response may include the CBIID generated by the SCF 635 in the step 8402.

In the present disclosure, since the CB instance creation response is a response to the CB instance creation request and the CB instance creation request is referred to as the second request, correspondingly, the CB instance creation response in the step 8403 is also referred to as a second response.

The procedure for creating a task CB instance is described above in step 840. In some cases, the mission (that is, the first mission) may further include at least one sub-mission CB. In those cases, at least one sub-mission CB instance corresponding to the at least one sub-mission CB is to be created. Therefore, step 850 is described as below.

In step 850, the MEF 630 creates a sub-mission CB instance.

This step is optional if the mission (that is, the first mission) includes no sub-mission CBs.

In some embodiments, as a sub-mission CB corresponds to a mission, creating a sub-mission CB instance is equivalent to creating at least one CB instance for a mission instance. Therefore, for each sub-mission CB of the mission as identified in the mission information, the MEF 630 generates a sub-mission instance ID and creates a sub-mission instance by recursively performing the steps 830-step 860 using the sub-mission instance ID. In other words, if the first mission instance includes a sub-mission CB instance, creating the sub-mission CB instance may include creating at least one task CB instance and/or another one or more sub-mission CB instances.

In some embodiments, the sub-mission instance ID may include the sub-mission CBID and the first MIID.

The order of performing the step 840 and the step 850 is not limited in the present disclosure.

After the one or more CB instances have been created for the first mission instance, the step 860 is further performed as described below.

In step 860, the MEF 630 establish communication resources for the mission instance (that is, the first mission instance) .

In some embodiments, the MEF 630 selects an MCF 625 and requests the MCF 625 to establish communication tunnels between the CB instances created in the steps 840 and 850 for the mission instance. This step is optional.

In one implementation, the MEF 630 sends a request (also referred to as third request in the present disclosure) to the MCF 625, wherein the third request instructs/requests/indicates the MCF 625 to establish communication tunnels between CB instances that have been created for the first mission instance.

According to the request from the MEF 630, the MCF 625 determines how PSFs belonging to different CB instances should interconnect (e.g., via which data GW (s) ) and configures the communication tunnels between the PSFs and the data GW (s) . For example, if a tunnel has an end at a PSF, the MCF 625 uses a TCF associated to the PSF to configure the tunnel end at the PSF. If a tunnel has an end at a data GW, the MCF 625 may configure the tunnel end at the data GW directly or may use the NET4CON service 536 to configure the tunnel end at the data GW.

After the communication tunnels have been created, the MCF 625 may send a response (also referred to as a third response in the present disclosure) to the MEF 630. Accordingly, the MEF 630 receives the response from the MCF 625, and the third response indicates that the communication tunnels have been created.

Creating a task CB instance and a sub-mission CB instance are described above. In some embodiments, the first mission instance may further include an external CB instance to be created. In this case, the MEF 625 may interact with an AF to create the external CB instance. The AF is associated to the external CB and may be different from the AF in the FIG. 8.

In step 870, the MEF 630 updates (adds) the mission instance information.

In some embodiments, the MEF 630 may generate instantiation information according to the generated CB instances by steps 840-860. For example, the instantiation information describes the CB instances and includes at least one of: the first MIID, the task CBID, the task CBIID, the sub-mission CBID, or the sub-mission CBIID. In some embodiments, the MEF 630 generates second mission instance information. The second mission instance information is associated to the first mission instance and corresponds to the first mission instance information. The second mission instance information may include the first mission instance information (or a part of the first mission instance information) . The second mission instance information further includes the instantiation information. In some embodiments, the MEF 630 generates the second mission instance information by updating the first mission instance information, and the updated first mission instance information is the second mission instance information. When updating the first mission instance information, the MEF 630 may insert/add additional information into the first mission instance information, wherein the additional information may include, for example, the instantiation information.

In some embodiments, the MEF 630 sends the second mission instance information to the MIR 620. Correspondingly, the MIR 620 stores the second mission instance information. The second mission instance information is associated to the first mission instance as described above. If the MIR 620 does not already store mission instance information of the first mission instance, the second mission instance information will be stored as the mission instance information of the first mission instance. If the MIR 620 already stores mission instance information of the first mission instance, the storing causes content of the mission instance information to be updated with the content of the second mission instance information.

In other words, in this step, the MEF 630 stores the second mission instance information in the MIR 620. For example, if the MIID is not yet included in the first mission instance information (e.g., if the MIID is generated by the MEF 630 in the step 830) , the MEF 630 includes the MIID in the second mission instance information before storing the second mission instance information in the MIR 620. In this step, for a CBIID (which identifies either a task CB instance or a sub-mission CB instance) , the MEF 630 stores the corresponding CBID and possibly the corresponding MID in the MIR 620. This information is associated to the CBIID and is included in the second mission instance information.

In step 880, the MEF 630 responds to the AF 610 for the AF request. The response is sent to the AF 610 and indicates that the AF request is accepted. The response includes a MSAI, which can be used to select the mission instance. The MSAI may include the MID, the MIID, or both in the response.

In the present disclosure, since the response corresponds to the AF request which is also referred to as a first request, the response here is also referred to as a first response. And the first response indicates that the first request has been accepted. Furthermore, the first response includes mission selection assistance information (MSAI) for selecting the first mission instance.

Please be noted that, in the present disclosure, if the AF request fails the validation in the step 820, the MEF 630 sends the first response indicating that the AF request has been rejected. If the AF request has passed the validation in the step 820, the MEF 630 sends the first response indicating that the AF request has been accepted.

The embodiments described in association to the FIG. 8 allows a mission instance of a mission to be dynamically created according to a request from the AF 610.

The procedure of creating a mission instance is described above referring to FIG. 8. In the following, a procedure of removing a mission instance will be described.

FIG. 9 shows a signaling chart for removing mission instance information, according to the architecture shown in FIG. 7. The signaling chart 900 involves the AF 610, the MDR 615, the MIR 620, the MCF 625, the MEF 630, the SCF 635 and the NET4CON 536. In the FIG. 8, the SCF 635 is an XaaS service. 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. 9, An authorized AF can request to remove an instance of a mission, which is created or used to support an application. When the instance of the mission (i.e., the mission instance) is removed, mission instance information associated to the mission instance is removed from the MIR 620. The procedure of mission instance information removal is illustrated in the FIG. 9, wherein the MEF 630 is assumed to be able to identify whether the mission is being executed over the mission instance. 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 an instance of a mission. Accordingly, the MEF 630 receives the AF request from the AF 610.

In some embodiments, the AF request includes an MSAI, which can be used to identify the instance of the mission (i.e., the mission instance) . The AF request may further include an ASID, which identifies an application that the mission instance is associated to.

In the present disclosure, for ease in distinguishing the AF request in the step 810 and the AF request in the step 910, the AF request in steps 910-990 is also referred to as a fourth request. The instance to be removed in steps 910-990 is also referred to as a second mission instance. The mission related to the instance to be removed in steps 910-990 is also referred to as a second mission.

That is, in the step 910, the AF 610 sends the fourth request to the MEF 630, wherein the fourth request includes the MSAI for identifying the second mission instance of the second mission and indicates removing the second mission instance of the second mission.

In step 920, the MEF 630 responds to the AF 610. The response is sent to the AF 610 and acknowledges the recipient of the AF request. This step is optional.

In step 930, the MEF 630 obtains mission instance information associated to the second mission instance.

In some embodiments, the MEF 630 identifies the second mission instance using the MSAI, the ASID or both. The MEF 630 obtains the mission instance information associated to the second mission instance from the MIR 620, by providing an MIID identifying the second mission instance to the MIR 620 and receives the mission instance information from the MIR 620 in response. The MIID identifying the second mission instance is determined based on the MSAI, the ASID or both.

In the present disclosure, the MIID identifying the second mission instance as described above is also referred to as a second MIID. That is, the MEF 630 sends the second MIID to the MIR 620, and the MIR 620 sends the mission instance information associated to the second mission instance to the MEF 630. Accordingly, the MEF 630 receives the mission instance information from the MIR 620.

In step 940, the MEF 630 terminates the mission execution.

In some embodiments, if the second mission is being executed over the second mission instance, the MEF 630 terminates the execution of the second mission by using an MCF. In the present disclosure, the MCF herein is also referred to as a first MCF.

In some embodiments, the MEF 630 sends the second MIID to a target network entity and the MEF 630 receives information identifying the first MCF from the target network entity. And the information identifying the first MCF may be determined by the target network entity based on the second MIID. For example, the target network entity maintains a mapping between the information identifying the first MCF and the second MIID, identifies the information identifying the first MCF based on the mapping after receiving the second MIID from the MEF 630, and sends the information identifying the first MCF to the MEF.

In other words, if the second mission is being executed over the second mission instance, the MEF 630 terminates the execution of the second mission by using the first MCF 625. The MCF 625 may be an MCF that is managing the mission execution and selected using the MIID. For example, a target network function stores a mapping relation between the MCF 625 and the MIID, and the MEF 630 interacts with the target network function to select the MCF 625. For example, the MEF 630 may send a message including the MIID to the target network function, and the target network function responds to the MEF 630 by sending the information identifying the first MCF (e.g., a MCF ID or a network address) .

In some embodiments, after the mission execution has been terminated, the MEF 630 removes at least one CB instance of the second mission instance according to the mission instance information.

In one implementation, the MEF 630 sends a CB instance removal request to a SCF, the CB instance removal request including a CBIID identifying the CB instance. The CBIID is included in the mission instance information as described in the step 930, and the CB instance removal request requests the SCF to remove the CB instance.

In the present disclosure, the CB instance removal request is also referred to as a fifth request.

In some embodiments, the CB instance to be removed may be a task CB instance or a sub-mission CB instance. In the following, a procedure of removing a task CB instance and a procedure of removing a sub-mission CB instance will be described, respectively.

In step 950, the MEF 630 removes a task CB instance. This step is optional if the second mission includes no task CB.

For each task CB instance in the second mission instance as identified in the mission instance information, the MEF 630 interacts with an SCF 635 to remove the task CB instance. The task CB instance corresponds to an XaaS service. The SCF 635 is selected from SCFs associated to the XaaS service.

In details, the step 950 includes at least one of the following sub-steps:

In step 9501, the MEF 630 sends a CB instance removal request to the SCF 635. The CB instance removal request includes a CBIID that identifies the CB instance. The MEF 630 obtains the CBIID from the mission instance information.

In the present disclosure, the CB instance removal request is also referred to as the fifth request as described above. Besides, the SCF in the step 950 is also referred to as a third SCF to distinguish from the SCFs for creating CB instances as described above in the FIG. 8.

In step 9502, after receiving the CB instance removal request, the SCF 635 removes the CB instance by releasing task resources (i.e., PSF (s) and TCF (s) ) associated to the CB instance.

In some embodiments, for a task resource, the SCF 635 sends the CBIID to the task resource, and the CBIID is for indicating that the task resource is released from the CB instance.

For example, when releasing a task resource (i.e., a PSF or a TCF) associated to the CB instance, the SCF 635 provides the CBIID to the task resource, indicating that the task resource is released from the CB instance identified by the CBIID. Accordingly, the task resource removes information related to the CB instance in local configuration, e.g., association information describing association of the task resource to other task resources associated to the CB instance, tunnel end information related to the CB instance, and stops processing data related to the CB instance.

In some embodiments, the SCF 635 may further deregister the task resources associated to the CB instance from the C/M GW.

In one implementation, the SCT 635 sends deregistration request including the CBIID to a NRF (e.g., the NRF mentioned in description associated to the step 8402, for example relating to the registration of task resources) . According to the request, the NRF removes any registration information related to the CBIID.

Alternatively, in another implementation, each task resource, after being released by the SCF 635 as described above, performs self-deregistration with the NRF. For example, the task resource sends a deregistration request to the NRF, including the CBIID, and the NRF removes only the task resource’s registration information related to the CBID according to the request.

In step 9503, the SCF 635 responds to the MEF 630, by using a CB instance removal response. The CB instance removal response is sent to the MEF 630 and indicates that the CB instance has been removed. The CB instance removal response may include the CBIID.

In the present disclosure, the CB instance removal response is also referred to as a fifth response.

In step 960, the MEF 630 removes a sub-mission CB instance.

In some embodiments, as a sub-mission CB corresponds to a mission, removing a sub-mission CB instance is equivalent to removing at least one CB instance for a mission instance. That is, each sub-mission CB instance in the mission instance is a mission instance, and the corresponding CBIID is in the form of MIID. For each sub-mission CB instance in the mission instance as identified in the mission instance information, the MEF 630 recursively performs the steps 930 –960 using the corresponding CBIID such that the sub-mission CB instance is removed.

When removing the sub-mission CB instance, the MEF 630 may interact with a SCF, which is also referred to as a fourth SCF in the present disclosure. The fourth SCF may be different or the same as the third SCF as described above.

NOTE: The steps 950 and 960 may be performed in parallel.

In step 970, the MEF 630 releases communication resources associated to the mission instance by using an MCF. The MCF may be an MCF that is managing the mission execution and selected using the MIID. The MCF in this step is also referred to as a second MCF in the present disclosure. The MCF in the step 940 and the MCF in this step may be the same MCF. That is, the second MCF may be the same as the first MCF.

In some embodiments, the MEF 630 requests the MCF 625 to release the communication resources. In one implementation, the MEF 630 sends a termination request to the second MCF, wherein the termination request includes the second MIID identifying the second mission instance and instructs/requests/indicates the MEF 630 to terminate an execution of the second mission instance. According to the request from the MEF 630, the MCF 625 release communication tunnels associated to the mission instance. If a tunnel has an end at a PSF, the MCF uses a TCF associated to the PSF to release the tunnel end at the PSF. If a tunnel has an end at a data GW, the MCF 625 may directly configure the data GW to release the tunnel end or use the NET4CON service to release the tunnel end at the data GW.

Further, the second MCF sends a termination response to the MEF 630, wherein the termination response indicates that the execution of the second mission has been terminated.

In step 980, the MEF 630 update (remove) mission instance information.

In some embodiments, the MEF 630 requests the MIR 620 to remove the mission instance information in the MIR 620, by sending the MIID to the MIR 620. In the present disclosure, the request is also referred to as a sixth request. According to the request, the MIR 620 identifies the mission instance information using the MIID and deletes the mission instance information in storage. The MIR 620 responds to the MEF 630, confirming that the mission instance information is removed. In the present disclosure, the response is also referred to as a sixth response.

In step 990, the MEF 630 notifies the AF 610 that the mission has been removed. The notification sent to the AF 610 may include the MASI and the ASID.

In the present disclosure, since the notification corresponds to the AF request, which is also referred to as a fourth request in the step 910, the notification is also referred to as a fourth response.

NOTE: The notification is used as a response to the AF request if the step 920 is not performed.

The embodiments described in association to the FIG. 9 allows a mission instance of a mission to be dynamically removed according to a request from the AF.

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 610 obtains first mission instance information about a first mission instance of a first mission, wherein the first mission instance information includes at least one of: a mission instance identifier (MIID) identifying the first mission instance; a mission identifier (MID) identifying the first mission; instantiation information describing at least one CB instance in the first mission instance; execution pattern information describing a pattern of executing the first mission on the first mission instance; authorization information indicating a plurality of devices allowed to access the first mission instance; temporal validity condition indicating when the first mission instance is valid; spatial validity condition indicating where the first mission instance is valid; or application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and in step 1020, the AF 610 sends a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first mission instance information, and the first request indicates a management related to the first mission instance.

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 includes mission selection assistance information (MSAI) for identifying a second mission instance of a second mission and indicates removing the second mission instance of the second mission; and in step 1120, the AF 610 receives a fourth response from the MEF network entity 630, the fourth response indicating that the second mission instance has been removed.

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 630 receives a first request from an application function (AF) network entity 610, wherein the first request indicates a management related to a first mission instance of a first mission, and the first request includes first mission instance information about the first mission instance, wherein the first mission instance information includes at least one of: a mission instance identifier (MIID) identifying the first mission instance; amission identifier (MID) identifying the first mission; instantiation information describing at least one CB instance in the first mission instance; execution pattern information describing a pattern of executing the first mission on the first mission instance; authorization information indicating a plurality of devices allowed to access the first mission instance; temporal validity condition indicating when the first mission instance is valid; spatial validity condition indicating where the first mission instance is valid; or application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and in step 1320, the MEF 630 obtains second mission instance information about the first mission instance, wherein the second mission instance information is generated based on the first mission instance information.

FIG. 13 shows another 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, wherein the fourth request includes mission selection assistance information (MSAI) for identifying a second mission instance of a second mission and indicates removing the second mission instance of the second mission; and in step 1320, the MEF 630 obtains mission instance information associated to the second mission instance; and if the second mission is being executed over the second mission instance, the MEF 630 terminates execution of the second mission by using a first mission control function (MCF) network entity; and according to the mission instance information, the MEF 630 removes at least one computing block (CB) instance of the second mission instance.

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, wherein the second request includes a computing block identifier (CBID) identifying a computing block (CB) and instructs/requests/indicates to create a CB instance for the CB; and the SCF 635 sends a second response to the MEF network entity 630, wherein the second response indicates that the CB instance has been created.

FIG. 15 shows another flow chart illustrating a method by a SCF network entity in accordance with some embodiments of the present disclosure. In step 1510, the SCF receives a fifth request from a mission exposure function (MEF) network entity, wherein the fifth request includes a CB instance identifier (CBIID) identifying a computing block (CB) instance, and the fifth request instructs/requests/indicates the SCF network entity to remove the CB instance; and in step 1520, the SCF sends a fifth response to the MEF network entity, wherein the fifth response indicates that the CB instance has been removed.

FIG. 16 shows a flow chart illustrating a method by a MCF network entity in accordance with some embodiments of the present disclosure. In step 1610, the MCF receives a third request from a mission exposure function (MEF) network entity, wherein the third request instructs/requests/indicates the MCF network entity to establish communication tunnels between CB instances that have been created for a first mission instance; and in step 1620, the MCF sends a third response to the MEF network entity, wherein the third response indicates that the communication tunnels have been created.

FIG. 17 shows a flow chart illustrating a method by a MCF network entity in accordance with some embodiments of the present disclosure. In step 1710, the MCF receives a termination request from a mission exposure function (MEF) network entity, wherein the termination request includes a second mission instance ID (MIID) identifying a second mission instance of a second mission and instructs/requests/indicates the MEF network entity to terminate an execution of the second mission instance; and in step 1720, the MCF sends a termination response to the MEF network entity, wherein the termination response indicates that the execution of the second mission has been terminated.

Some embodiments of the present disclosure provide a network device. The network device 1600 is used for performing some steps of the method for managing a mission instance as described in the above embodiments/implementations. As shown in FIG. 18, the network device 1600 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 880 of the method in the FIG. 8. In this case, the communication module 1602 performs the steps 810 and 880.

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, 920 and 990 of the method in the FIG. 9. In this case, the communication module 1602 performs the steps 910, 920 and 990.

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, 830, 8401, 8403, 850, 860, 870 and 880 of the method in the FIG. 8. In this case, the communication module 1602 performs the steps 810, 8401, 8403 and 880, and the processing module 1601 performs the steps 820, 830, 850, 860 and 870.

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, 930, 940, 9501, 9503, 960, 970, 980 and 990 of the method in the FIG. 9. In this case, the communication module 1602 performs the steps 910, 920, 9501, 9503, and 990.

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

In yet some other examples, the network device 1600 corresponds to the SCF 635, and performs the steps 8401, 8402, 8403 and 860 of the method in the FIG. 8. In this case, the communication module 1602 performs the steps 8401and 8403, and the processing module 1601 performs the steps 8402 and 860.

In yet some other examples, the network device 1600 corresponds to the SCF 635, 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 SCF 635, and performs the steps 9501, 9502, 9503 and 970 of the method in the FIG. 9. In this case, the communication module 1602 performs the step 9501 and 9503.

In yet some other examples, the network device 1600 corresponds to the SCF 635, 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 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 “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 “A and/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 mission instance information about a first mission instance of a first mission, wherein the first mission instance information includes at least one of following elements:

a mission instance identifier (MIID) identifying the first mission instance;

a mission identifier (MID) identifying the first mission;

instantiation information describing at least one CB instance in the first mission instance;

execution pattern information describing a pattern of executing the first mission on the first mission instance;

authorization information indicating a plurality of devices allowed to access the first mission instance;

temporal validity condition indicating when the first mission instance is valid;

spatial validity condition indicating where the first mission instance is valid; or

application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and

sending a first request to a mission exposure function (MEF) network entity, wherein the first request includes the first mission instance information, and the first request indicates a management related to the first mission instance.
The method of claim 1, wherein the management includes creating the first mission instance, and the first mission instance is to be created for a first application related to the first mission; and

the first mission instance information includes at least one of a first mission ID identifying the first mission, a first application ID identifying the first application or an application service ID identifying a service provided by the first application.
The method of claim 2, wherein the first mission instance information further includes a first mission instance ID (MIID) identifying the first mission instance.
The method of any of claims 1-3, further comprising:

receiving a first response from the MEF network entity, wherein the first response indicates that the first request has been rejected; and the first response includes a reason for rejection, wherein the reason includes that the first application is not supported by the first mission.
The method of any of claims 1-4, wherein the first request indicates modifying at least one element of the elements included in the first mission instance information.
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 includes mission selection assistance information (MSAI) for identifying a second mission instance of a second mission; and

receiving a fourth response from the MEF network entity, the fourth response indicating that the second mission instance has been removed.
The method of claim 6, wherein the fourth response includes the MSAI and at least one of an application ID identifying an application associated to the second mission instance or an application service ID identifying the application associated to the second mission instance.
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 indicates a management related to a first mission instance of a first mission, and the first request includes first mission instance information about the first mission instance, wherein the first mission instance information includes at least one of following elements:

a mission instance identifier (MIID) identifying the first mission instance;

a mission identifier (MID) identifying the first mission;

instantiation information describing at least one computing block (CB) instance in the first mission instance;

execution pattern information describing a pattern of executing the first mission on the first mission instance;

authorization information indicating a plurality of devices allowed to access the first mission instance;

temporal validity condition indicating when the first mission instance is valid;

spatial validity condition indicating where the first mission instance is valid; or

application information, wherein the application information indicates at least one application that the first mission instance is associated to and specifies a value of a mission parameter associated to the at least one application; and

obtaining second mission instance information about the first mission instance, wherein the second mission instance information is generated based on the first mission instance information.
The method of claim 8, wherein the management includes creating the first mission instance, and the first mission instance is to be created for a first application related to the first mission; and

the first mission instance information includes at least one of a first mission ID identifying the first mission, a first application ID identifying the first application or an application service ID identifying a service provided by the first application.
The method of claim 9, wherein the first mission instance information further includes a first mission instance ID (MIID) identifying the first mission instance.
The method of claim 9, further comprising:

generating a first MIID identifying the first mission instance, if the first mission instance information does not include the first MIID.
The method of any of claims 9-11, further comprising:

obtaining mission information about the first mission from mission data repository (MDR) , wherein the mission information includes application indication indicating at least one application that the first mission is associated to; and

according to the application indication and at least one of the first application ID or the application service ID, validating whether the first mission supports the first application.
The method of claim 12, further comprising:

If the first mission does not support the first application, sending a first response to the AF network entity, wherein the first response indicates that the first request has been rejected.
The method of claim 13, wherein the first response further indicates a reason for a rejection of the first request.
The method of any of claims 9-14, further comprising:

If the first mission supports the first application and the first mission instance information does not include the instantiation information, creating the at least one CB instance.
The method of claim 15, wherein creating the at least one CB instance includes:

sending a second request to a service control function (SCF) network entity, wherein the second request includes a CB identifier (CBID) identifying a CB and instructs the SCF network entity to create the CB instance for the CB; and

receiving a second response from the SCF network entity, wherein the second response indicates that the CB instance has been created.
The method of claim 16, wherein the first mission includes a task CB and the SCF network entity includes a first SCF network entity, and sending the second request to the SCF network entity includes:

sending the second request to the first SCF network entity, wherein the second request includes a task CB identifier (CBID) identifying the task CB and instructs the first SCF network entity to create the task CB instance for the task CB; and

receiving the second response from the first SCF network entity, wherein the second response indicates that the task CB instance has been created.
The method of claim 17, wherein the second response includes a task CB instance identifier (CBIID) identifying the task CB instance, and the task CBIID is generated by the first SCF network entity.
The method of any of claims 15-18, wherein the first mission includes a sub-mission CB and the SCF network entity includes a second SCF network entity, and sending the second request to the SCF network entity includes:

sending the second request to the second SCF network entity, wherein the second request includes a sub-mission CB identifier (CBID) identifying the sub-mission CB and instructs the second SCF network entity to create the sub-mission CB instance for the sub-mission CB; and

receiving the second response from the second SCF network entity, wherein the second response indicates that the sub-mission CB instance has been created.
The method of any of claims 15-19, further comprising:

sending a third request to a mission control function (MCF) network entity, wherein the third request instructs the MCF network entity to establish communication tunnels between CB instances that have been created for the first mission instance; and

receiving a third response from the MCF network entity, wherein the third response indicates that the communication tunnels have been created.
The method of any of claims 15-20, wherein the second mission instance information includes at least one of: the first MIID, the task CBID, the task CBIID, the sub-mission CBID, or the sub-mission CBIID.
The method of claim 21, further comprising:

sending the second mission instance information to a mission instance repository (MIR) network entity.
The method of claim 22, further comprising:

sending a first response to the AF network entity, wherein the first response indicates that the first request has been accepted and the first response includes mission selection assistance information (MSAI) for selecting the first mission instance.
The method of claim 23, wherein the management includes modifying at least one element of the first mission instance information of the first mission instance.
A method performed by a mission exposure function (MEF) , the method comprising:

receiving a fourth request from an application function (AF) network entity, wherein the fourth request includes mission selection assistance information (MSAI) for identifying a second mission instance of a second mission and indicates removing the second mission instance of the second mission;

obtaining mission instance information associated to the second mission instance; and

if the second mission is being executed over the second mission instance, terminating execution of the second mission by using a first mission control function (MCF) network entity; and

according to the mission instance information, removing at least one computing block (CB) instance of the second mission instance.
The method of claim 25, wherein obtaining the mission instance information associated to the second mission instance includes:

sending a second mission instance ID (MIID) identifying the second mission instance to a mission instance repository (MIR) network entity; and

receiving the mission instance information from the MIR network entity.
The method of claim 26, further comprising:

sending the second MIID to a target network entity; and

receiving information identifying the first MCF from the target network entity, wherein the information identifying the first MCF is determined based on the second MIID.
The method of claim 27, wherein removing the at least one CB instance of the second mission instance includes:

sending a fifth request to a service control function (SCF) network entity, wherein the fifth request includes a CB instance identifier (CBIID) identifying the CB instance, and the CBIID is included in the mission instance information, and the fifth request requests the SCF network entity to remove the CB instance; and

receiving a fifth response from the SCF network entity, wherein the fifth response indicates that the CB instance has been removed.
The method of claim 28, wherein the fifth response includes the CBIID.
The method of claim 28 or 29, wherein the at least one CB instance includes a task CB instance and the SCF network entity includes a third SCF network entity, and removing the at least one CB instance of the second mission instance includes:

sending the fifth request to the third SCF network entity, wherein the fifth request includes a task CBIID identifying the task CB instance, and the fifth request requests the third SCF network entity to remove the task CB instance; and

receiving the fifth response from the third SCF network entity, wherein the fifth response indicates that the task CB instance has been removed.
The method of claim 28 or 29, wherein the at least one CB instance includes a sub-mission CB instance, and the SCF network entity includes a fourth SCF network entity, and removing the at least one CB instance of the second mission instance includes:

sending the fifth request to the fourth SCF network entity, wherein the fifth request includes a sub-mission CBIID identifying the sub-mission CB instance, and the fifth request requests the fourth SCF network entity to remove the sub-mission CB instance; and

receiving the fifth response from the fourth SCF network entity, wherein the fourth response indicates that the sub-mission CB instance has been removed.
The method of any of claims 25-31, further comprising:

releasing communication resources associated to the second mission instance by using a second MCF.
The method of any of claims 25-32, further comprising:

sending a sixth request to the MIR network entity, wherein the sixth request includes the second MIID and requests the MIR network entity to remove the mission instance information; and

receiving a sixth response from the MIR network entity, the sixth response confirming that the mission instance information has been removed.
A method performed by a service control function (SCF) network entity, the method comprising:

receiving a second request from a mission exposure function (MEF) network entity, wherein the second request includes a computing block identifier (CBID) identifying a computing block (CB) and instructs to create a CB instance for the CB; and

sending a second response to the MEF network entity, wherein the second response indicates that the CB instance has been created.
The method of claim 34, further comprising:

a CB instance identifier (CBIID) identifying the CB instance is included in the second request or generated by the SCF network entity.
The method of claim 35, further comprising:

creating the CB instance according to information describing composition and functionalities of the CB, wherein the information corresponds to the CBID.
The method of claim 35 or 36, wherein creating the CB instance includes:

sending the CBIID to a first task resource network entity , wherein the CBIID indicates that the first task resource network entity is allocated to the CB instance.
The method of claim 37, further comprising:

sending association information to the first task resource network entity, wherein the association information indicates that the first task resource network entity is associated to a second task resource network entity allocated to the CB instance.
The method of claim 38, wherein the association information includes a resource ID or a network address of the second task resource network entity.
The method of any of claims 36-39, wherein creating the CB instance further includes:

sending registration request including a resource ID and/or a network address of the first task resource network entity, the CBID, and the association information to a network repository function (NRF) network entity.
The method of any of claims 36-40, wherein the CB includes a task CB and/or a sub-mission CB.
A method performed by a service control function (SCF) network entity, the method comprising:

receiving a fifth request from a mission exposure function (MEF) network entity, wherein the fifth request includes a CB instance identifier (CBIID) identifying a computing block (CB) instance, and the fifth request instructs the SCF network entity to remove the CB instance; and

sending a fifth response to the MEF network entity, wherein the fifth response indicates that the CB instance has been removed.
The method of claim 42, wherein the fifth response includes the CBIID.
The method of claim 42 or 43, further comprising:

releasing a task resource network entity associated to the CB instance to remove the CB instance.
The method of claim 44, wherein releasing the task resource network entity includes:

sending the CBIID to the task resource network entity, wherein the CBIID is for indicating that the task resource network entity is released from the CB instance.
The method of any of claims 42-45, the method further comprising:

sending deregistration request including the CBIID to an NRF.
The method of any of claims 42-46, wherein the CB instance includes a task CB instance and/or a sub-mission CB instance.
A method performed by a mission control function (MCF) network entity, the method comprising:

receiving a third request from a mission exposure function (MEF) network entity, wherein the third request instructs the MCF network entity to establish communication tunnels between CB instances that have been created for a first mission instance; and

sending a third response to the MEF network entity, wherein the third response indicates that the communication tunnels have been created.
The method of claim 48, further comprising:

determining how one or more processing service functions (PSFs) belonging to different CB instances should interconnect; and

configuring the communication tunnels between the one or more PSFs and one or more GW (s) .
A method performed by a mission control function (MCF) network entity, the method comprising:

receiving a termination request from a mission exposure function (MEF) network entity, wherein the termination request includes a second mission instance ID (MIID) identifying a second mission instance of a second mission and instructs the MEF network entity to terminate an execution of the second mission instance; and

sending a termination response to the MEF network entity, wherein the termination response indicates that the execution of the second mission has been terminated.
An apparatus, comprising:

at least one processor coupled with a memory storing thereon computer program instructions, when the program instructions executed by the at least one processor, 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 coupled with a memory storing thereon computer program instructions, when the program instructions executed by the at least one processor, cause the apparatus to implement the method of any one of claims 8 to 24, or claims 25 to 33.
An apparatus, comprising:

at least one processor coupled with a memory storing thereon computer program instructions, when the program instructions executed by the at least one processor, to cause the apparatus to implement the method of any one of claims 34 to 41, or claims 42 to 47.
An apparatus, comprising:

at least one processor coupled with a memory storing thereon computer program instructions, when the program instructions executed by the at least one processor, cause the apparatus to implement the method of any one of claims 48 to 49 or claim 50.
A system, comprising:

the apparatus of claim 51, the apparatus of claim 52, the apparatus of claim 53; and

the apparatus of claim 54.
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 24, claims 25 to 33, claims 34 to 41, claims 42 to 47, claims 48 to 49, or claim 50.
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 24, claims 25 to 33, claims 34 to 41, claims 42 to 47, claims 48 to 49, or claim 50.
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 24, claims 25 to 33, claims 34 to 41, claims 42 to 47, claims 48 to 49, or claim 50.