Method and related apparatuses for managing mission configuration

Abstract

Embodiments of the present disclosure provide a method and related apparatuses for configuring entities for the execution of a mission. Mission configuration may include triggering a device's subscription to services required for the execution of the mission; aligning the format of input and / or output data between the device and a service, or between services; configuring entities according to mission specifications, for which actions are performed on the data plane or control and management (C / M) plane; and finally removing the configurations of these entities, once the mission has been completed.

Description

METHOD AND RELATED APPARATUSES FOR MANAGING MISSION CONFIGURATIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to US provisional patent application No. 63 / 725,353, filed on November 26, 2024, which is hereby incorporated by reference in its entirety.TECHNICAL FIELD

[0002] The present disclosure relates to the field of communication technologies, and to a method and related apparatuses for the configuration of missions comprising one or more services rendered by the network or by service providers.BACKGROUND

[0003] Many emerging trends are driving the consideration and design of wireless networks, such as 6G networks, including new network infrastructure capabilities, advances in maturing technologies, including large-scale Artificial Intelligence (AI) models, data de-privacy techniques, and blockchain, emerging applications and services, such as AI-driven solutions, data sensing services, and digital world services, and a shift towards global, open, and collaborative operations.

[0004] New expectations and stricter requirements on future networks also drive rethinking and development of a new generation of wireless networks. These requirements include privacy and trustworthiness, simplified standardization and rapid deployment.

[0005] In the fifth generation (5G) era, a new core network has been introduced by 3GPP, relying on an open and modular service platform, the Service-Based Architecture (SBA) . SBA provides a cloud-native service framework, in which mobile core network functionalities (authentication, mobility management, etc. ) are supported by network functions (NFs) . Service providers can provide services to any other authorized service consumer through Application Programming Interfaces (APIs) .

[0006] In this service framework, each NF can consume the services provided by other NFs and expose services as well. There can be a centralized repository, the Network Repository Function (NRF) , in which NFs can publish new services. The service information maintained in the NRF is accessible to all the NFs to enable service discovery. The consumer NFs can also retrieve required routing information from the NRF to interact with the service producer NFs.

[0007] To expose services to consumers, a service provider may describe its services using API specifications. For example, the OpenAPI specification provides a formal standard for describing HTTP APIs. An OpenAPI description allows both people and computers to discover and understand how an API works, including available resources and authorized operations on each resource, operation parameters, input and output for each operation, etc.

[0008] However, there are gaps between the requirements of future network capability descriptions and existing API specifications. A service-based architecture requires automatic programming of network capabilities and services to enable the provision of mission services based on collaboration and interaction between several networks and / or service providers. It is therefore desirable to align the interfaces between services and capabilities to enable automated mission configuration.

[0009] 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

[0010] In a first aspect, a method applied at a first node is provided. The method comprises: sending a subscription trigger request to a device required for executing a mission, to enable the device to subscribe to one or more services required to execute the mission, wherein the subscription trigger request comprises information related to each of the one or more services; and receiving, from the device, a subscription trigger response, wherein the subscription trigger response indicates whether the one or more services required for the mission have been subscribed to by the device.

[0011] In possible implementations, the subscription trigger request may include at least one of: a number of subscriptions required to execute the mission; identifiers of the one or more services; identifiers of actions associated with each of the one or more services; a geographic area required for a service; and a period required for use of each of the one or more services.

[0012] In possible implementations, the subscription trigger response may include at least one of: an identifier of the device; the identifiers of the one or more services; the identifiers of the actions associated with each of the one or more services; a subscription indicator for each of the one or more services and / or the actions; and subscription results for successfully subscribed services.

[0013] In possible implementations, the subscription results may also comprise a subset of subscription results indicating one or more settings for the actions, wherein the one or more settings are determined by the device.

[0014] In possible implementations, the method may also include checking, at a second node, the subscription status of the device to the one or more services involved in executing the mission.

[0015] In possible implementations, checking the subscription status may be performed prior to sending the subscription trigger request or after receiving the subscription trigger response from the device.

[0016] In possible implementations, the second node may be a subscription library node.

[0017] In possible implementations, if the subscription trigger response sent by the device indicates that subscription to the at least one of the one or more services is unsuccessful, the first node may attempt a different intent resolution for the mission, for which unsubscribed services are replaced with other services and / or actions.

[0018] In possible implementations, a subscription request is received at a third node from the device, to enable the device to subscribe to the one or more services to which the device has not yet subscribed to. The subscription request may specify one or more subscription settings to subscribe to the one or more services needed to perform the mission. The third node may enable the device to subscribe to the one or more services according to the one or more subscription settings specified in the subscription request. A subscription response is received at the device from the third node. The subscription response indicates information of whether the one or more services have been subscribed to by the device, wherein the information is utilized by the device to generate the subset of subscription results in the subscription trigger response.

[0019] In possible implementations, the third node may send an update message to the second node, to update the second node regarding the one or more services to which the device has subscribed to.

[0020] In possible implementations, the first node may be a node which provides an autonomous network capability programming (A-CAP) service.

[0021] According to another aspect, a method applied at a first node is provided. The first node may be a device or an NC provider. The method comprises receiving, from a second node, at least one of an input data format and an output data format corresponding to each action of one or more actions associated one or more services carried out on a data plane (DP) . The one or more services may be involved in executing a mission. For the one or more actions associated with the one or more services for which the input data format and the output data format are acceptable for the first node, a subscription request is sent to subscribe to the one or more actions, wherein the one or more actions are aligned actions. For the one or more actions for which at least one of the input data format and the output data format are not acceptable for the first node, wherein the one or more actions are unaligned actions, a data format conversion (DFC) subscription request is sent to the second node, to subscribe to a DFC action to convert at least one of the input data and the output data to a desired input data format and / or a desired output data format. If the subscription to the DFC action by the first node is successful, a subscription request is sent to the second node, to subscribe to the unaligned actions, wherein at least one of the input data format and the output data format are converted to the desired input data format and / or the desired output data format by the DFC action. The subscription request may include the subscription results of the DFC action. A regenerated version of the subscription request may be transmitted by the second node to a service provider node of the one or more actions and / or of the DFC action.

[0022] In possible implementations, for the unaligned actions: the first node obtains from the second node information on available DFC actions providing capabilities of data format conversion; and based on the available DFC actions, the first node determines which DFC actions to subscribe to in order to perform a desired format conversion.

[0023] In possible implementations, a first update message may be sent to a third node, such as CONfederated Network (CONET) or subscription library node, by the second node, to confirm subscription to the DFC actions by the first node. The CONET enables multiple partners or service providers to jointly provide 6G services.

[0024] In possible implementations, a second update message to the third node may be sent by the second node, to confirm which actions are to implement the DFC actions, wherein the second update message includes subscription parameters defined for the DFC actions.

[0025] In possible implementations, if the subscription to the DFC actions by the first node is unsuccessful, the first node is unable to subscribe to and use the unaligned actions.

[0026] In possible implementations, the subscription request to the one or more services involved for executing the mission may comprise at least one of: the input data format of the one or more actions; an indicator of whether the input data format is aligned or not; the DFC actions to be used to convert the input data format to the desired input data format; the output data format; an indicator of whether the output data format is aligned or not; the DFC actions to be used to convert the output data format to the desired output data format.

[0027] In possible implementations, the subscription request to subscribe to the DFC actions may comprise at least one of: a source data format, and a target data format.

[0028] In possible implementations, when the first node calls an action for executing the mission: subscription to the action by the first node based on a specification of the mission is verified by a fourth node. If the action requires execution of one or more DFC actions, the specification of the mission is updated by the fourth node, by including the DFC actions subscribed to by the first node in the specification of the mission.

[0029] In possible implementations, the specification of the mission may be updated to include the one or more DFC actions in a flow of actions required to execute the mission, wherein placement of the one or more DFC actions depends on whether data format conversion is to be performed on at least one of an input data or an output data.

[0030] According to another aspect, a method applied at a first node is provided. The method may be for configuring entities according to mission specifications. The method may include the following steps: determining, based on a specification of a mission, one or more entities for which a configuration is required for executing the mission, wherein the one or more entities provide one or more services; sending a configuration request to each of the one or more entities to be configured, wherein the configuration request indicates one or more parameters for executing the mission; and receiving, from each of the one or more entities, a configuration response indicating whether operations related to the mission have been successfully configured.

[0031] In possible implementations, a subscription from a first service provider of one of the one or more services to the first node may comprise an indication of whether a subscription to a service will be carried by an action call from a first entity of the one or more entities to a second entity, wherein the indication is used to determine the one or more entities for which the configuration is required.

[0032] In possible implementations, the one or more configuration parameters for the operations related to the mission may comprise at least one of: an identifier of an established mission session, a number of configuration profiles, and at least one configuration profile, wherein the at least one configuration profile comprises an operation identifier of the mission, processing logic settings, and action settings.

[0033] In possible implementations, the configuration response may comprise, for each configuration profile, a set of operation identifier (s) of the mission and corresponding indicator (s) indicating whether the operations related to the mission of the one or more services have been successfully configured.

[0034] In possible implementations, the mission is carried out on a data plane (DP) and the one or more services are data plane services.

[0035] In other possible implementations, the mission is carried out on a control and management (C / M) plane and the one or more services are C / M plane services.

[0036] In possible implementations, the first node has knowledge of which of the one or more services and / or actions are required for the mission, and which of the one or more entities will be used when executing the mission.

[0037] In possible implementations, the identifier of the established mission session and the operation identifier of the mission are used in each interaction occurring during the execution of operations belonging to the mission session, such that a corresponding configuration profile is associated with each of the identifier of the established mission session and the operation identifier of the mission.

[0038] In possible implementations, the processing logic settings specify the relationship between a target mission operation and other mission operations belonging to the same mission session, wherein the target mission operation is identified by the operation identifier of the mission.

[0039] In possible implementations, the processing logic settings comprise at least one of: a precondition operation setting, indicating other mission operation (s) to be executed before the target mission session operation; a combination operation setting, indicating other mission operation (s) to be executed within the execution of the target mission operation; and a next operation setting, indicating the next mission operation (s) to be executed after the target mission session operation.

[0040] In possible implementations, the action settings specify how to perform a target mission session operation in the execution of the mission.

[0041] In possible implementations, the mission is carried on the data plane and the action settings comprise at least one of: an indication of whether the entity that received the configuration request is a customer or a service provider of a corresponding service of the target mission operation; an entity identifier, comprising an identifier of a device or an entity, to identify one or more subscription (s) between the service provider of the corresponding service and the customer; a subscription identifier for identifying subscription parameters of the corresponding service; a processing Quality of Service (QoS) requirement; a connection identifier to identify a one-way connection to be used for forwarding data packets, wherein a destination of the one-way connection is an entity that receives data from the entity that received the configuration request during execution of the target mission operation; and a transmission QoS indicator (QoSI) to identify a predefined or preconfigured QoS rule when forwarding the data packets.

[0042] In possible implementations, the mission is carried out on the C / M plane and the action settings comprise at least one of: an indication of whether an entity that received the configuration request is a customer or a service provider of a corresponding service of the target mission operation; an entity identifier comprises an identifier of a device or an entity, to identify one or more subscription (s) between the service provider of the corresponding service and the customer; a subscription identifier for identifying subscription parameters of the corresponding service; and an identification of a destination entity with which the entity that received the configuration request needs to communicate during the execution of the target mission session operation.

[0043] In possible implementations, a method applied at a first node is provided. The method may be for removing the configuration of one or more entities after the execution or expiration of a mission. The method comprises sending a configuration removal request to remove configurations from one or more entities involved in the execution of one or more missions, wherein the one or more entities have received one or more configuration requests from the first node, wherein the configuration removal request includes information about a plane type, mission session (s) and mission operation (s) involved in carrying out the one or more missions.

[0044] In possible implementations, the configuration removal request comprises at least one of: whether the plane type is a data plane (DP) or a control and management (C / M) plane; a number of mission session operations, wherein each mission session operation is identified by a set of: IDs of established mission sessions of the one or more missions and operation IDs of the mission operations of the one or more missions.

[0045] The configuration removal method may be performed when the one or more missions have been completed or when the one or more missions are outdated.

[0046] In another aspect, the apparatus may include one or more processors; and one or more memories storing instructions which, when executed by the one or more processors, cause the apparatus to perform the method according to any one of the implementations described above.

[0047] In another aspect, a computer program product is provided, and comprises program code for performing the method according to any one of the implementations described above.

[0048] In another aspect, a computer program is provided, comprising computer execution instructions which, when executed by a processor, cause the processor to execute the method according to any one of the implementations described above.

[0049] In another aspect, a computer-readable medium is provided, storing computer execution instructions which, when executed by a processor, cause the processor to execute the method according to any one of the implementations described above.

[0050] In another aspect, a chip is provided, comprising an input / output (I / O) interface and a processor, wherein the processor is configured to call and run a computer program stored in a memory, to enable a device installing with the chip to perform the method according to any one of the implementations described above.BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The accompanying drawings are used to provide a further understanding of the present disclosure, constitute a part of the specification, and are used to explain the present disclosure together with the following specific embodiments, but should not be construed as limiting the present disclosure.

[0052] FIG. 1 shows a simplified schematic illustration of a 6G system conceptual structure according to one or more example implementations of the present disclosure.

[0053] FIG. 2A shows a simplified schematic illustration of an example of an apparatus in a communication system according to one or more example implementations of the present disclosure.

[0054] FIG. 2B shows connections related to a wireless device in a communication system according to one or more example implementations of the present disclosure.

[0055] FIG. 3A shows a schematic flowchart of a mission management method according to a possible embodiment of the present disclosure.

[0056] FIG. 3B shows a schematic flowchart of another mission management method according to a possible embodiment of the present disclosure.

[0057] FIG. 4 shows a schematic flowchart of a method according to one or more embodiments of the present disclosure, for triggering on-demand subscription of a device to a service.

[0058] FIG. 5 shows a schematic flowchart of yet another method according to one or more embodiments of the present disclosure, for setting data format alignment between a device and a service, or between services.

[0059] FIG. 6 shows a schematic flowchart an exemplary implementation of steps involved in setting up data format alignment, according to possible embodiments of the present disclosure.

[0060] FIG. 7 shows a schematic flowchart of yet another method according to one or more embodiments of the present disclosure, for establishing the configuration of one or more entities involved in the execution of a mission on a C / M plane or on a data plane.

[0061] FIG. 8 shows a schematic flowchart of yet another method according to one or more embodiments of the present disclosure, for removing the configuration of one or more entities involved following the execution or expiration of a mission on a C / M plane or on a data plane.

[0062] FIG. 9 shows a schematic flowchart of yet another method according to one or more embodiments of the present disclosure, for generating a feasible specification of a data-plane mission.

[0063] FIG. 10 shows a schematic flowchart of yet another method according to one or more embodiments of the present disclosure, for configuring and executing a mission.

[0064] FIG. 11 shows a block diagram of an apparatus according to one or more embodiments of the present disclosure.

[0065] FIG. 12 shows a block diagram of another apparatus according to one or more embodiments of the present disclosure.

[0066] FIG. 13 shows a schematic structural diagram of a communication apparatus according to one or more embodiments of the present disclosure.

[0067] FIG. 14 shows a schematic diagram of an architecture of a computing device cluster according to one or more embodiments of the present disclosure.

[0068] FIG. 15 shows a schematic diagram of a connection between computing devices over a network according to one or more embodiments of the present disclosure.DETAILED DESCRIPTION

[0069] In the following description, reference is made to the accompanying figures, which form part of the present disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and include structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0070] The present disclosure generally relates to wireless communications.

[0071] The solution described in the present disclosure is applicable to a next generation (e.g., sixth generation (6G) or later) network, or a legacy (e.g. 5G or 4G) network.

[0072] The proposed 6G System architecture is defined to support 6G X as a service (XaaS) services by using techniques such as Network Function Virtualization and Network Slicing. The 6G System architecture utilizes service-based interactions between 6G services.

[0073] The 6G System leverages service-based architecture and the XaaS concept. XaaS services in the 6G System are categorized into three layers. The 6G System conceptual structure is shown in FIG. 1.

[0074] Infrastructure Layer includes infrastructures supporting 6G services. Among them are wireless networks (radio access network (RAN) , core network (CN) ) infrastructures, Cloud / data center infrastructures, satellite networks, storage / database infrastructures, and sensing networks, and etc. These infrastructures can be provided by a single provider or by multiple providers. As shown in FIG. 1, each of the infrastructures on the infrastructure Layer 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.

[0075] Control and Management (C / M) layer 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. 6G services in Control and Management (C / M) layer are: -Resource Management (RM) as a Service 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 service  which is provided by a single 6G XaaS service or a type of service that needs contributions from multiple XaaS services. -Mission Management (MM) as a Service provides a capability to program provisioning of XaaS services at Service  Layer to provide mission services. -Confederation Network (CONET) as a Service 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 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 leverages 5G connectivity management functions, but with extension  to include digital world. -Protocol as a Service 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 as a Service provides a capability for owners of infrastructures to detect potential security risks  of their infrastructures. -XaaS services in C / M Layer 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 can be deployed by using slicing technique.

[0076] Service Layer includes 6G services which provide services to customers. In the 6G System conceptual structure: -AI service is denoted as NET4AI as a Service. 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 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, 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, 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. 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. This service provides a  capability to support exchange of messages and data among new 6G services.

[0077] All XaaS services at this Layer are developed and deployed by using resources 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.

[0078] 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 who needs other XaaS services to enable its operation, while each of XaaS services provide their capabilities to 6G customers.

[0079] 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 and C / M Layer; RM services may need the capabilities provided by NET4AI, DAM and NET4DW for its resource management for vertical slicing; CONET service and NET4Data service may need the capability provided by NET4BC for their operation.

[0080] Concepts of a 6G Systems 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, NET4DW service, DAM service, NET4Data service, Block chain service, mission management service, 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, enables them 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. - 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 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 the 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 many efforts due to the introduction of the BAS concept. - Support backward compatibility by utilizing the 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.

[0081] In the present disclosure, the 6G customer can be of various types, including a device (e.g., electronic device ED, terminal device) , apparatus, a chip, an equipment (e.g., user equipment) etc. For example, the customer may be an individual customer, a business customer, etc. The 6G customer is used to connect persons, objects, machines, etc. The 6G customer 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.

[0082] Each 6G customer 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 (UE) or a user device or a terminal device, 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. module, modem, or chip) or comprising the forgoing devices, among other possibilities. Future generation 6G customer may be referred to using other terms. When a 6G customer performs (or is configured to perform) a method described herein, it may be interpreted as the ED, one or more module (or units) in the ED, a circuit or chip, or a combination thereof, may perform the method. For example, the circuit or chip may include a modem chip, also referred to as a baseband chip, a system on chip (SoC) including a modem core, or system in packages (SIP) ) , and the like, and may be responsible for one or more communication functions in the ED.

[0083] FIG. 2A shows a simplified schematic illustration of a deployment of a 6G system according to one or more example implementations of the present disclosure. In details, FIG. 2A illustrates an example of an apparatus 320 in a communication system (e.g., the 6G system) . The apparatus 320 may be a device (e.g. a device representing the customer) , a network node such as RAN, any components in RAN, CN or any Network Function in the 6G service of the present disclosure, or an apparatus includes one or more of the network functions (as mentioned above) . As shown in FIG. 2A, the apparatus 320 may include at least one processor 260. Only one processor 260 is illustrated to avoid congestion in the drawing. The processor 260 may perform (or control the apparatus 320 to perform) operations (or methods) described herein as being performed by the apparatus 320.

[0084] When the apparatus is RAN, components of the RAN or the apparatus is the UE, the apparatus 320 may further include a transmitter 252 and a receiver 254 coupled to one or more antennas. One, some, or all of the antennas 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 or network interface controller (NIC) . The transceiver is also configured to demodulate data or other content received by the at least one antenna. 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 includes any suitable structure for transmitting and / or receiving wireless or wired signals. In present disclosure, the transceiver (or transmitter 252 and / or receiver 254) may be viewed as an interface circuit.

[0085] The apparatus 320 may include at least one memory 258. The memory 258 stores instructions used to perform operations described herein. The memory 258 may also store data used, generated, or collected by the apparatus 320. 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 one or more processor 260.

[0086] For ease of understanding, different connections related to the device will be described in the first place. As shown in FIG. 2B, the device would be connected to its serving gateways, including a C / M gateway shown as C / M-TW-GW-1 and a data gateway shown as Data-TW-GW-1, it should be noted that although C / M-TW-GW-1 and Data-TW-GW-1 are shown as being deployed on the infrastructure of CN (e.g., CN infrastructure as shown in FIG. 1) , they could also be deployed on other infrastructures, such as RAN infrastructure, which is not limited in the embodiments of the present disclosure.

[0087] The connections related to the device may include but are not limited to following: 1) Device CN-C / M RB: an RB between a wireless device and its serving RAN (Cell, RB handler) that carries C / M  session traffic; 2) Device CN-data RB: an RB between a wireless device and its serving RAN (Cell, RB handler) that carries data  session traffic; 3) Device RAN-C / M RB: an RB between a wireless device and its serving RAN that carries RAN related C / M traffic; 4) Device RAN-data RB: an RB between a wireless device and its serving RAN that carries RAN related data traffic; 5) Device data session: a logical connection between a device and its serving Data-TW-GW, e.g., Data-TW-GW-1; 6) Device C / M session: a logical connection between a device and its serving C / M-TW-GW, e.g., C / M-TW-GW-1; 7) Device-NC connection: a logical connection between a device and a Network Capability (NC) (C / M NC or data  NC) . The connection carries data / information traffic; the connection would be a downlink connection or an uplink connection; 8) Device-ext (external) connection: a logical connection between a device and an entity, e.g., server, located in  external networks. A GW that has connection with external networks is an ext-Data-TW-GW or an ext-C / M-TW-GW, e.g., C / M-TW-GW-2 and Data-TW-GW-2 in this figure. Network needs to establish a tunnel between the device and an ext-GW to support a device-ext connection.

[0088] In 6G system, both new 6G XaaS services and network C / M XaaS services are categorized as basic XaaS services, a XaaS service (which is also referred to as service herein) is defined as a NC. The NCs at the C / M layer may be referred to as C / M NCs, and the NCs at the service layer may be referred to as data NCs.

[0089] There would be downlink and uplink RBs, downlink and uplink sessions, downlink and uplink device-NC connections, which are not shown in details.

[0090] With respect to the RBs between the device and the RAN shown in FIG. 2B, the RBs generally include device CN RB and device RAN RB. The device CN RB includes the above device CN-C / M RB and device CN-data RB, and the device RAN RB includes the above device RAN-C / M RB and device RAN-data RB. From the perspective of directions, the RB may be a downlink RB from RAN to a wireless device or an uplink RB from the wireless device to RAN, so the RB can be of a downlink type or an uplink type, the downlink and uplink RB may be referred to as a pair of RB; from the perspective of traffic types, the RB could be a C / M RB for carrying control signaling traffic on the C / M plane or a data RB for carrying data traffic on the data plane, so the RB can be of a C / M type or a data type; from the perspective of traffic destinations, the RB could be called a RAN-RB or a CN-RB, the RAN-RB is a RB that carries signaling messages or data traffic between a wireless device and RAN, the CN-RB is a RB that carries signaling messages or data traffic between a device and core network (CN) on the over-the-air interface, so in this case, the RB can be of a RAN-RB type or a CN-RB type. When combining the above different perspectives, different RBs may be downlink / uplink RAN-C / M RB (RAN-RB for carrying signaling messages on the C / M plane) , downlink / uplink RAN-data RB (RAN-RB for carrying data traffic on the data plane) , downlink / uplink CN-C / M RB (CN-RB for carrying signaling messages on the C / M plane) , downlink / uplink CN-data RB (CN-RB for carrying data traffic on the data plane) . That is, a RAN-RB may be an uplink / downlink RAN-C / M RB or RAN-data RB, a CN-RB could be an uplink / downlink CN C / M RB or CN-data RB; a C / M RB could be an uplink / downlink RAN-C / M RB or uplink / downlink CN-C / M RB, a data RB could be an uplink / downlink RAN-data RB or uplink / downlink CN-data RB.

[0091] With respect to the session related to a wireless device, from the perspective of traffic types, the session could be a C / M session which is a logical connection between a wireless device and its serving C / M-TW-GW for control signaling exchanging therebetween on the C / M plane, or a data session which is a logical connection between a device and its serving data-TW-GW for data exchanging therebetween on the data plane, so the session can be of a C / M type or a data type; from the perspective of directions, the session may be a downlink session from a serving GW (serving C / M-TW-GW or serving data-TW-GW) to a wireless device or an uplink session from the wireless device to the serving GW, so the session can be of a downlink type or an uplink type, the downlink and uplink sessions may be referred to as a pair of session. When combining the above different perspectives, different sessions may be downlink / uplink C / M session (C / M session for control signaling exchanging therebetween on the C / M plane) , or downlink / uplink data session (data session for data exchanging therebetween on the data plane) . That is, a session may be an uplink / downlink C / M session or data session.

[0092] With respect to the NC connection between a wireless device and a NC, from the perspective of traffic types, the NC connection could be a C / M NC connection which is a logical connection between a wireless device and a C / M entity of the NC, or a data NC connection which is a logical connection between the wireless device and a data entity of the NC, so the NC connection can be of a C / M type or a data type; from the perspective of directions, the NC connection may be a downlink NC connection from a entity (C / M entity or data entity) of the NC to a wireless device or an uplink NC connection from the wireless device to the entity, so the NC connection can be of a downlink type or an uplink type, the downlink and uplink NC connections may be referred to as a pair of NC connections. When combining the above different perspectives, different NC connections may be downlink / uplink C / M NC connections, or downlink / uplink data NC connections. That is, a NC connection may be an uplink / downlink C / M NC connection or a data NC connection.

[0093] As described above, both new 6G XaaS services and network C / M XaaS services are categorized as basic XaaS services, a XaaS service is defined as a NC. Each of these NCs can provide a single or a group of specific capabilities to enable 6G system control and management and 6G service provisioning, an NC can provide one or more sub-services, each sub-service being enabled by one or more basic network capabilities, i.e., actions. Each basic network capability or action could be described in a consistent format, and could be AI / LLM (large language model) friendly (for AI enabled full automation) , such a consistent format is defined as a network capability description language (NCDL) . In a possible implementation, a XaaS service can be implemented / achieved through execution of one or more actions corresponding to the XaaS service, the one or more actions are used for reflecting one or more capabilities for implementing a requirement of the service, the one or more actions may correspond to the one or more capabilities one-by-one, or a combination of multiple actions may correspond to one capability. Taking a case where the XaaS service is NET4AI service as an example, NET4AI service can provide AI related services to 6G customers or to other NCs. These AI related services can be enabled by its inference capability or sub-service, training capability or sub-service, and model management capability or sub-service. That is, the requirement for NET4AI service can include but is not limited to: a training requirement, an inference requirement, a model management requirement which can be related to storing of a model or a library related to provision of NET4AI service, enhancement / improvement of the model, or the like; for the training requirement, and there could be multiple algorithms / schemes such as algorithm / scheme A, algorithm / scheme B and algorithm / scheme C for implementing the training requirement, then the multiple algorithms / schemes can be regarded as multiple actions corresponding to NET4AI service. It should be noted that here the algorithm / scheme is just an implementation of the action, the action of a service may be characterized in other forms, which are not limited in the implementations of the present disclosure. For the purposes of this disclosure, a network capability (NC) may encompass one or more services related to a common purpose, such as providing connectivity, making predictions using AI models, or maintaining decentralized ledgers with blockchains, as examples. Accordingly, the terms "network capability" and "service" may be used interchangeably. A network capability provider, or service provider, refers to an entity comprising both physical and logical components that deliver services to other entities, whether users or other services.

[0094] The NCDL defines a language which could be understandable by both parties, i.e., a first NC calling the action and a second NC executing the action called by the first NC. The actions may be classified into different types as follows: Type 1: In-out-action: when being called, action codes are run based on input and produce output. (Input-> action-> output) ; Type 2: In–action: when being called, action codes are run based on input and local configuration / update is then  conducted (input->action-> local update) ; Type 3: Out-action: when a local condition (triggering condition) is met, action codes are run to provide output (local  ->action->output) .

[0095] For Type 1 action and Type 2 action, the first NC calls an action to be performed by the second NC, the first NC provides an NCDL input to the second NC. The NCDL input follows a certain agreement for the second NC to correctly recognize the NCDL input and execute the action. For Type 1 action, the second NC provides an NCDL output corresponding to the NCDL input. This NCDL output may be provided to the first NC, or to other NC (s) , which is not limited in the embodiments of the present disclosure. For Type 2 action, the second NC performs a local configuration update based on the NCDL input, and no NCDL output is transmitted.

[0096] For Type 3 action, there is no NCDL input, and when a local condition (triggering condition) is met, the second NC automatically executes the operation associated with the action and provides an NCDL output to the first NC which subscribes to this action.

[0097] For an NCDL of a C / M NC, the input dimensions (NCDL input) can include one or multiple input information without defining corresponding input information format; for an NCDL of a data NC, this dimension can include one or multiple input data dimensions along with the definition of corresponding input data format.

[0098] Before discussing in greater detail, the objectives of the various embodiments of the invention, the problems they solve, and how they operate, definitions of concepts to which we will refer in the remainder of the disclosure are presented below.

[0099] As explained in the previous paragraphs, a Network Capability (NC) can refer to a XaaS (Anything as a Service) provided by a 6G system. A NC can encompass one or more services with a common purpose or function. A NC may also be called a service. NCs can be provided by NC providers, which manage and operate different physical and / or logical components, collectively called “nodes” , to render the services supported by a NC.

[0100] Action (provided by an NC) : The functionalities of an NC provider can be supported by one or multiple operations. Each of the operations is defined as an action provided by the NC.

[0101] Network Capability Description Language (NCDL) : The collection of information on network capability description. To provide this capability, a NC provider defines its supported actions and provide capability description of each action.

[0102] Mission service: Mission service is a novel concept of the proposed 6G System. The provisioning of a mission service results from the contribution of one or multiple NCs, i.e., mission involved NCs, and one or multiple actions are required for the mission service provisioning.

[0103] Mission intent: The information related to a mission intent describes a mission goal that can be achieved by the mission service through the execution of the mission.

[0104] Mission operation: Each action that is required by the mission service is known as a mission operation. Thus, the execution of the mission consists of the execution of its mission operation (s) .

[0105] Mission instantiation: The creation of an instance of a mission.

[0106] Mission session: A mission session is a collection of actions performed, in a certain order, by one or multiple NCs (entities) involved in executing the mission. Also involved in a mission session are 6G devices and mission service consumers.

[0107] Mission specification: The information related to a mission specification describes the operations of the mission and the interworking logic among them to achieve the mission goal, as outlined in the mission intent. The information of a mission specification further details the interconnection between the NCs (entities) involved in executing the mission. Since each mission operation is associated with a specific action, the mission specification is also referred to as the action-level mission workflow, in some embodiments.

[0108] Data plane NC (entity) : an NC (entity) which can contribute to a data plane mission service, i.e., can be involved by a data plane mission session.

[0109] C / M plane NC: an NC which can contribute to a C / M plane mission service i.e., can be involved by a C / M plane mission session.

[0110] Data format conversion (DFC) : DFC is a 6G service in the service layer of 6G System conceptual structure. Services related to data format conversion are denoted as DFC as a Service, which may also be referred to as DFC NC. This service provides a capability of data format conversion, such as changing file formats (e.g., from CSV to XML) , adapting character encoding (e.g., from UTF-8 to UTF-16) , converting data types (e.g., from int to bool) , and performing customized data format conversion (e.g., process data based on conversion method provided by customers) .

[0111] In possible implementations, a mission management service, also known as Autonomous Network Capability Programming (A-CAP) , is proposed for next-generation communication systems, including 6G. For any customer (e.g., a 6G customer, device, or network controller) that has subscribed to a mission management service (or A-CAP service) , including intent resolution, and is connected to an A-CAP service, a mission management service tailored to the customer’s requirements (e.g., mission intent) can be provided. Possible steps that may be performed by an A-CAP service to manage mission service provisioning for a given customer is illustrated in FIG. 3A.

[0112] The steps of FIG. 3A may be described as follows: 1. Intent acceptance: The A-CAP service receives a mission intent from a customer. 2. Intent resolution: The A-CAP service may resolve the received mission intent, based on the capability information and  device profiles obtained from a NCDL library and a Device library. The NDCL library may store the capability descriptions (NCDL) registered by NC providers. The Device library may store the device profiles (e.g., equipment type, security requirement, area information) collected by the network. The resolution result may correspond to a sub-intent diagram, i.e., the A-CAP service may obtain a NC-level mission workflow with sub-intent for each step. 3. Mission specification generation: 3.1 Sub-intent resolution: The A-CAP service may send the sub-intents to the corresponding candidate NCs  based on the designed sub-intent diagram. Then, each candidate NC may resolve the sub-intents considering its own capability and may send back the resolution results to the A-CAP service. The resolution results may be an action (or API) -level decision, i.e., a sequence of actions which may be provided by the NC candidate to resolve the sub-intent. 3.2 Mission specification generation: The A-CAP service may design the action-level mission workflow (or  mission specification) according to its designed NC-level mission workflow and based on the action (or API) -level sub-intent resolution results that were provided by the candidate NCs. 4. Mission instantiation: The A-CAP service determines mission involved Trustworthy Gateways (TW-GWs) and NC  entities, which can be decided based on statuses of network resources. 5. Mission configuration: The A-CAP service creates configuration profiles for the involved NC entities and TW-GWs,  which may be distributed in a NC configuration phase (step 5.1) and a GW configuration phase (step 5.2) respectively. 6. Mission execution: The mission can be carried out thanks to the coordination between TW-GW and the NC entities  involved, which is made possible by the mission configuration.

[0113] When considering the workflow shown in FIG. 3A, there are gaps between the requirements of interface alignment for mission service provision and the steps performed by the A-CAP service. These gaps include: - For a given mission, if there is no subscription to a given service required to perform the mission (i.e. the action (s)  related to the mission) , the service interface has not been agreed by the customer and the service provider. Consequently, interface alignment for this service provision is not guaranteed. To enable the provision of a mission service, it is therefore necessary to check the subscription to the actions involved in the mission and to subscribe to an on-demand service for the invalid actions detected. - For data plane (DP) missions, when a customer subscribes to a mission involving a DP service, a mechanism for  setting up data format alignment is needed. Such a mechanism enables a customer to subscribe to a Data Format Conversion (DFC) service to achieve the required data format, and the conversion will be applied to guarantee data format alignment for future mission service provisioning. - For mission configuration, which is a service provided by the A-CAP service for other NC or services, a description  of this service may be needed to enable other NCs to subscribe to the mission configuration service.

[0114] The methods and systems disclosed herein better align the interfaces of services and / or devices involved for rendering mission services. The solutions proposed herein aim to solve or alleviate the above-mentioned drawbacks by answering at least one of the following questions: - How can an A-CAP service trigger the on-demand subscription of a service or a network capability (NC) , so as to  guarantee interface alignment for the provisioning of a specific mission service? - How can a A-CAP service describe its ability to generate and distribute configuration profiles for the services or  NCs involved in the mission, so that the A-CAP services be known and subscribed to by the NCs, and so that NCs may accept the mission configuration? - How can data format alignment be established for a data plan mission?

[0115] As shown in FIG. 3B, the present disclosure proposes new steps in the generation of mission specifications, indicated as steps 3.2 to 3.6. These new steps include: a step for checking or verifying the subscriptions required by one or more devices to services (or actions or NC (s) ) needed for executing the mission (step 3.2) ; a step for triggering the device (s) to initiate subscription to services (or action (s) or NC (s) ) involved in executing the mission (step 3.3) ; a step for the device (s) subscribing to a service (or action (s) or NC (s) ) (step 3.4) ; a step for updating a subscription library (step 3.5) and a step for setting up data format alignment when devices and  / or services do not have aligned input and / or output data format in between them (step 3.6) . The present disclosure also introduces a description of the mission configuration for the entities concerned (NC) by the mission, indicated by step 5.1, and referred to as NC configuration, in order to guarantee the interface alignment for the provision of mission services.

[0116] Improvements proposed for the process of mission management, including the configuration of mission service to enable automatic network capability programming, may include the following aspects : - The introduction of a description or message structure (i.e., NCDL) for the on-demand subscription of a device to  entities and / or services (NCs) , the on-demand subscription being a service is provided by the A-CAP; - The introduction of descriptions (i.e., NCDL) for the actions supporting mission configuration, which are provided  by A-CAP; and - The introduction of a data format alignment setup scheme, the steps of which include identifying data conversion  requirement, subscribing to a data conversion service as required, and inserting the data conversion service within the flow of steps to be executed for a mission.

[0117] The present disclosure provides a method performed at a first node, to implement one or more actions. FIG. 4 shows a schematic flowchart of a method according to one or more embodiments of the present disclosure, which reflects the execution of an action (including reception and transmission steps) performed by the first node.

[0118] In step S401, a first node sends a subscription trigger request to a device. The subscription of the device to a service is required for executing a mission. A subscription may be referred to as an agreement between specific nodes regarding modalities for carrying out operations / actions required to render the one or more services. As mentioned earlier, a mission comprises a set of tasks or actions that need to be carried out by one or more NCs, which may be internal or external to the network. A mission refers to a sequence of capabilities / actions to solve an intention received from the customer / device, as per steps 2 and 3.1 of FIG. 3B. The subscription trigger request comprises information related to each of the one or more services.

[0119] The first node may provide a capability to program the provisioning of XaaS services at the service layer, for mission services. In other words, the first node may be part of a service that provides autonomous network capability programming (A-CAP) .

[0120] The subscription trigger request may for example include: a number of subscriptions required to execute the mission; identifiers of the one or more services; identifiers of actions associated with each of the one or more services; a geographic area required for a service; and a period required for use of each of the one or more services. This information may be provided in fields, in the request message sent by the first node.

[0121] In step 402, the first node receives, from the device, a subscription trigger response. The subscription trigger response indicates whether the one or more services required for the mission have been subscribed to by the device. The response provided by the device thus indicates to the first node the results of the subscription process, i.e., whether the device was able to successfully subscribe to the services required to execute the mission.

[0122] For example, the subscription results may comprise a subset of subscription results indicating one or more settings for the actions, where the settings are determined by the device.

[0123] As illustrated in FIG. 3B, in step 3.2, the method may further include a step of checking or verifying, at a second node, the subscription status of the device regarding the one or more services involved in executing the mission. The first node must therefore have first obtained the information concerning the NCs and / or actions required to carry out the mission. The second node may be for example a subscription library node. This step can be performed before the NC subscription trigger message is sent, to check which NCs the device must subscribe to, or after the subscription response is received from the device, to confirm that the device has subscribed to the required NCs.

[0124] In cases where the subscription trigger response sent by the device indicates that subscription to a given service is unsuccessful, the first node may attempt a different intent resolution for the mission, for which the unsubscribed service is replaced with another service or action. In such cases, steps 2 and 3.1 indicated in FIG. 3B may need to be performed again.

[0125] Following the subscription trigger request initiated by the first node, a subscription request, send by the device, may be received at a third node, as per step 3.4 of FIG. 3B. The third node may be for example a node in charge of service provisioning management (SPM) . The third node may also be a service which provides the capability to enable multiple partners to jointly provide 6G services. The subscription request is sent to enable the device to subscribe to one or more services provided by a given network capacity, and to which the device has not yet been subscribed to. In addition, the subscription request may specify one or more subscription settings, to configure a given service according to the needs of the device. These settings may correspond to negotiable parameters for certain aspects of the service, such as Quality of Service (QoS) , or data privacy. The third node (such as a SPM node) enables the device subscribes to the one or more services according to the one or more subscription settings specified in the subscription request.

[0126] After receiving the subscription request from the device, and upon successful subscription to the service, the third node may send an update message to the second node (i.e., a subscription library node) to inform it about the one or more services the device has subscribed to, as shown in step 3.5 of FIG. 3B. This may involve updating a subscription table, for example. A subscription response is received at the device from the third node. The subscription response indicates information of whether the one or more services have been subscribed to by the device. The information is utilized by the device to generate the subset of subscription results in the subscription trigger response.

[0127] The following paragraphs will describe an example NCDL of the action of triggering an on-demand subscription for a device, pertaining to a customer.

[0128] The action provider and consumer: the action is provided by the first node, which may provide autonomous (automatic or advanced) capability programming, which may be referred to as A-CAP. The action may be subscribed to by a customer, via one of its devices.

[0129] Name of the action: Trigger on-demand NC subscription for device / customer.

[0130] Purpose of the action: a node, such as an A-CAP node that provides capability programming, prompts a customer-via their device (s) -to subscribe to a specific service or network capability necessary for the execution of a mission.

[0131] Pre-condition: the customer, via its device (s) , has subscribed to the automatic capability programming (A-CAP) services and has established a connection with the A-CAP node.

[0132] Post-condition: Once executed, the action results in the device successfully subscribing to the services it was prompted or triggered to subscribe to.

[0133] The NCDL of this action is provided in Table 1. Table 1: NCDL of Action “Trigger on-demand NC subscription for device / customer”

[0134] The parameters shown represent different capability dimensions (or fields) for the action of triggering or prompting on-demand NC subscription, the capability dimensions can include input dimensions and output dimensions (NCDL output) , in which the input dimensions are used to indicate required input information in order for the execution of the action, the output dimensions are used to indicate outputs of the action.

[0135] Definition of capability dimension type: - Output: The output from the action provider for the execution of an action. For example, the dimensions in Table 1  that belong to the output type are used to describe the information provided by the NC subscription trigger message for a device / customer, which is sent from the A-CAP to the mission-involved device / customer. - The input from the action consumer for the execution of an action. For example, the dimensions in Table 1 that  belong to the input type are used to describe the information provided in response to the NC subscription trigger message, which is sent by the device / customer that received the trigger message.

[0136] Definition of capability dimensions: - Number of subscriptions: indicates the number of subscriptions triggered by the request, where each subscription  is for a specific combination of NC (entity) identifier (ID) and Action ID. In Table 1, the subscription information of n actions is provided as an example. - Action ID: corresponds to an identifier of an action that needs to be subscribed to. In Table 1, there are n actions  to be subscribed, the ID of which are Action-1 to Action-n as an example. - NC (entity) ID: identifier of NC entity that needs to be subscribed to, identifying which NC (entity) provides each  of the actions (for example, Action-1 to Action-n in Table 1) . - Required effective area: refers to a potential processing area (or geographic region) of the subscribed action,  according to the spatial validity condition of the mission and service restrictions of the action. The spatial validity condition indicates where the mission is valid or available (i.e. can be executed) , which 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. - Required effective time: refers to a potential processing time of the subscribed action, according to the temporal  validity condition of the mission and service restrictions of the action. The temporal validity condition indicates when (e.g. in terms of time) the mission is valid or available (i.e. can be executed) , which can be expressed by one or multiple time-intervals or durations. - Customer ID: corresponds to the identifier of a device or customer used for subscribing to a service. This identifier  may be a temporary identifier, also referred to as a Subscriber Temporary Identifier (STID) . A STID may be generated by a SPM for each device to access a network, such as a 6G network. - Subscription indicator: indicates whether the subscription has succeeded or failed, for a specific subscription  request, which is specified by the combination of NC (entity) identifier and action identifier. - Subscription results: if successful, indicates the subscription results if necessary. The results may include the  selection, by the device, of negotiable parameters for the action concerned.

[0137] Use of this NCDL: After obtaining the mission specification (i.e., the mission workflow at the action level) , the first node (A-CAP) verifies its validity by ensuring successful subscription for each API call (action) . If the first node (A-CAP) identifies the need for a new service subscription for a device involved in the mission, such as when the device has not yet subscribed to an action provided by a NC participating in the mission, the first node can send a subscription trigger request to the device and update the device’s subscription library based on the subscription results. The above-described procedure is illustrated by step 3.2 to step 3.5 of FIG. 3B.

[0138] Subscription check (step 3.2) : In the action-level mission workflow, for each action involving a device, the first node (A-CAP) checks with a second node (which may be a subscription library) , to determine the subscription status of the device and verifies whether its subscription to the action is complete.

[0139] Based on the subscription check results, if an incomplete subscription is detected, the first node (A-CAP) triggers a subscription process for each device with an uncompleted subscription.

[0140] Table 2 below provides an example of a subscription trigger request and table 3 provides an example response to the request: Table 2: Example of a request sent by the first node (A-CAP) for a NC subscription of a device to a set of actions, provided  by different entities Table 3: Example of a subscription trigger response sent by the device as the reply to a request as per Table 2

[0141] Subscription trigger (step 3.3 in FIG. 3B) : the first node (A-CAP) sends a subscription trigger request to the device. The request format follows the output fields, or dimensions, indicated in Table 1 and for which an example is given in Table 2.

[0142] NC Subscription (step 3.4 in FIG. 3B) : After receiving the request, the device sends a subscription request to a third node, such as a node in charge of managing service provisioning and / or in charge of enabling multiple partners to jointly provide 6G services (SPM / CONET) node, to subscribe to the action specified in the received subscription trigger request. Upon completing the subscription procedure, the device sends a subscription trigger response to the first node, which may be a node in charge of automatically programming network capabilities (referred to as A-CAP) . The response format follows the input dimensions outlined in Table 1, with an example provided in Table 3, notifying the A-CAP of the subscription result.

[0143] Subscription library update (step 3.5) : The third node (SPM / CONET) updates the second node (such as a subscription library) with the NC subscription results.

[0144] Steps 3.3 to 3.5 are repeated for each device with an incomplete subscription.

[0145] If the subscription check (step 3.2) remains invalid, A-CAP will perform a new sub-intent resolution or another intent resolution to obtain an updated action-level mission workflow, returning to step 3.1 or step 2 as necessary.

[0146] According to another aspect, the following paragraphs describe possible implementations and case scenarios for data format alignment, for a device or for a service. FIG. 5 shows the general steps of the method, and FIG. 6 shows a possible implementation for a specific application.

[0147] FIG. 5 shows a schematic flowchart of a method according to one or more embodiments, performed by a first node, which reflects the execution of an action (including receiving input and / output data format required for actions to be executed on a data plane, determining whether the input and / or output data format are acceptable, and if not, requesting a subscription to a data format conversion service to have the required input and / or output data format converted to desired input and / or output data format) . The first node may be a device, or a network capacity (or service) provider node, involved in executing a mission.

[0148] In step S501 of FIG. 5, the first node receives, from a second node, an input data format and / or output data format for each action associated with one or more services carried out on a data plane (DP) . For data plane actions, there may be three types of data interaction: input and output; input only or output only. Thus, a required data format for actions carried on the data plane may apply to inputs and / or outputs, depending on the action type. The one or more services are involved in executing the mission, and the second node may be a service provisioning management node (SPM) , or a node having a similar function. Step 1 in FIG. 6 provides an exemplary interaction between a first node, i.e., the device, and the second node, i.e., the SPM, where the second node provides information, including required input and / output data format, for a network capability (NC1) . While in FIG. 6, the first node is embodied as a device, the first node could also be a service provider.

[0149] Different actions involved in the execution of a mission may have different input and / or output data format. For some actions, data format may be suitable for the first node, while for other actions, the data format may not be acceptable. For the one or more actions associated with the one or more services for which the input data format and the output data format is acceptable, the first node sends a subscription request to subscribe these actions, as per step S502 of FIG. 5. The subscription may be sent to a second node, such as a service provisioning managing node, for the aligned actions. The actions for which the data input format and data output format is suitable for the device may be referred to as “aligned actions” . In this case, the first node can subscribe to the actions for which the data input and output formats are aligned.

[0150] In cases where there are one or more actions for which the input data format and / or the output data format is / are not acceptable for the first node, a data format conversion service may have to be called and / or integrated in the sequence of actions involved in executing the mission. These actions for which the input and / or output data format is not suitable or acceptable can be referred to as “unaligned actions” . The first node would then send a data format conversion (DFC) subscription request to subscribe to a DFC action, to convert the required input data and / or output data format to a desired input and / or output data format, as per step S503 of FIG. 5. The data format conversion (DFC) subscription request can be addressed to the second node, which will communicate with a DFC provider. A DFC subscription request may comprise for example a source data format, and a target (or desired) data format.

[0151] An example of such a communication occurring between a device, the second node (such as a service provisioning managing node) and a DFC node is shown in step 5.1 of FIG. 6, where the device subscribes to DFC actions, via the SPM node, for data plane (DP) actions which data input and / or output is / are not aligned. Step 5.1 may include two sub-steps: 1) first, the first node sends the subscription request (to subscribe to a DFC action) to the second node and then, 2) the second node will regenerate the subscription request and send the regenerated subscription request to the service provider node (i.e. the DFC node) .

[0152] The SPM node may then update a Confederation Network (CONET) as a Service node, with the DFC subscription (step 5.2 in FIG. 6) .

[0153] Referring to step 504 of FIG. 5, if the subscription to the DFC action (s) by the first node is successful, a subscription request may be sent to subscribe to the unaligned actions, for which the input and / or output data format are converted to the desired input and / or output data format by the DFC action. The subscription request can be sent to the provider of the unaligned action (s) , via the SPM node. The subscription request also includes the subscription results of the DFC actions concerned. Thus, a subscription request to one or more services involved for executing the mission may comprise the following information : the input data format of the one or more actions; an indicator of whether the input data format is aligned or not; the DFC actions to be used to convert the input data format to the desired input data format; the output data format; an indicator of whether the output data format is aligned or not; the DFC actions to be used to convert the output data format to the desired output data format. Step 6.1 of FIG. 6 shows possible interactions between the device, the SPM service, and a given data plane service / NC provider (DP NC1) , where the device may subscribe to a data plane action for which data input and output is unaligned, by integrating a DFC action. Similar to step 5.1, step 6.1 may include two sub-steps: 1) first, the first node sends the subscription request to subscribe to the unaligned actions to the second node and then, 2) the second node will regenerate the subscription request and send the regenerated subscription request to the service provider node of the unaligned action.

[0154] In cases where the first node needs to subscribe to one or more unaligned actions, the first node may need to first obtain from the second node (such as an SPM node) , information on available DFC actions, that provide capabilities of data format conversion, as illustrated in step 3 of FIG. 6. Based on the available DFC actions, the first node (which may be a device) determines which DFC actions to subscribe to obtain a desired format conversion, as illustrated in step 4 of FIG. 6.

[0155] The second node (SPM) may then send a first update message to a third node (CONET) , including a subscription library, to confirm a subscription to the DFC actions by the first node, as illustrated in steps 5.2 and 5.3 of FIG. 6. The second node may also send a second update message to this third node, to confirm which actions are to implement the DFC actions. This second update message would include subscription parameters defined for the DFC actions. Possible communications involved are illustrated in steps 6.2 and 6.3 of FIG. 6.

[0156] In cases where the subscription to one or more DFC actions by the first node is unsuccessful, as in step S505 of FIG. 5, the device is prevented from subscribing to and use the unaligned actions. Some of the actions required for executing the mission may need to be replaced with other suitable actions.

[0157] In use, as per steps 7 to 9.3 in FIG. 6, when a node (i.e., a device or a NC provider) calls an action for executing a mission, verification can be made to ensure that this node has subscribed to the action based on a specification of the mission (step 9.1) . This verification can be made by a fourth node, which may provide autonomous network capability programming (A-CAP) , as an example only. If the action requires execution of one or more DFC actions, the node in charge of programming the network capabilities may update the specification of the mission by including the DFC actions subscribed to by the first node in the specification of the mission (step 9.2) . The specification of the mission may thus be updated to include the one or more DFC actions in a flow of actions required to execute the mission (step 9.3) . The inclusion of the one or more DFC actions will depend on whether data format conversion is to be performed on at least one of an input data or an output data.

[0158] The following paragraphs will describe a data alignment scheme, for ensuring proper data format alignment of actions involved in the execution of a mission.

[0159] To enable provisioning of data plane mission services, data format alignment between NC entities or between an NC entity and a customer / device may be required.

[0160] With reference to FIG. 6, possible steps for setting up data format alignment include: 1. Identification of the requirements for data format conversion: steps 1 to 4

[0161] All actions provided by a service or NC provider that requires the input or output of data (referred to as a “data interaction type” action, where data interaction occurs during the execution of this action) , may be defined by a description. This description of the action should specify the input and / or output data format required for interacting with the action. For instance, the format specification can be given in the NCDL of the data interaction type action. An example of a description of a “data interaction type” action is provided in Table 4 below. This description can be provided by the action provider, denoted by DP NC1 in FIG. 6. When a device or customer tries to subscribe to the data interaction type action, the device may first obtain capability information of the action (e.g., NCDL of the action) , as per step 1 of FIG. 6. The device / customer may then select action parameters or settings when subscribing to the action, based on the capability information provided, as per step 2 of FIG. 6. Table 4: Example of NCDL of a data interaction type action.

[0162] If the input / output data format is acceptable for the device / customer, the device / customer can select preferred settings for configuring the action according to its requirements. An example of an action subscription is shown in Table 5, in which a format alignment indicator for input and output data is set to ‘yes’ and format conversion subscription for both input and output format are set to ‘not applied’ or other similar indications. In this case, the steps 3, 4, and 5.1 to 5.3 in FIG. 6 may be skipped. Table 5: Example of NCDL subscription of the action described by Table 4.

[0163] If the input and / or output data format is not acceptable for the device / customer, the device / customer may still be able to subscribe to the action by trying to subscribe to a data format conversion (DFC) action, to convert the unacceptable data format (s) to acceptable data format (s) . The steps 3 and 4 of FIG. 6 show how the device / customer can subscribe to required DFC actions. For example, the ‘Output Data format’ provided in Table 4 may not be acceptable, i.e., . CSV may not be an acceptable output data format. In step 3, the device / customer can obtain capability information for a DFC action which provides capabilities of file format changing. An example NCDL of a DFC action is given in Table 6. As shown in Table 6, the format changing from ‘csv’ (as Source file format) to other formats (as Target file format) is supported by the action. In step 4, the device / customer can determine format change service needed. An example of the determined subscription is shown in Table 7, in which the acceptable file format is selected as ‘Target file format’ . Table 6: Example of NCDL of a ‘file format changing’ action provided by DFC. Table 7: Example of NCDL subscription of the action described by Table 6. 2. Subscription of data format conversion service: steps 5.1 to 5.3, steps 6.1 to 6.3

[0164] If data format conversion is required and feasible (as determined in step 2 and step 4) , the device / customer may first subscribe to the needed data format conversion action according to the decision of step 4, which is shown by steps 5.1～5.3.

[0165] If the subscription of DFC is successful, the device / customer may further subscribe to the data interaction type action with the DFC subscription result, as shown by steps 6.1～6.3. An example of a subscription of the action described in Table 4 is shown in Table 8, in which the format alignment indicator for “output data” is set to ‘No’ and the format conversion subscription for “Output data format conversion” is given. In this example, the value of ‘Output Data format conversion subscription’ is associated with the subscription of DFC action, i.e., ‘NCDL-1’ in Table 8 is associated with the subscription results in Table 7. Table 8: Example of NCDL subscription of the Action described by Table 4.

[0166] If the subscription to a data format conversion (DFC) action has failed, the device / customer may not be able to subscribe the data interaction type action, due to the unacceptable data format. In this case, the procedure may be terminated, and the subscription and utilization of the data interaction type action is not possible. A new mission specification may be needed. 3. Use of data format conversion: steps 7 to 9.3

[0167] Still referring to FIG. 6, when a node, such as an automatic capability programming node (A-CAP) , receives a mission intent and when the initial specification (action-level workflow) involves a data interaction type action, the A-CAP checks the NCDL subscription results, between the involved action and its consumer, as specified by the mission, as shown in steps 7 and 8. If a data format conversion is required and the corresponding DFC action (s) is / are subscribed to, the A-CAP inserts the subscribed DFC action (s) in the mission specification, as shown by steps 9.1～9.3. The placement or insertion of the DFC action will depend on whether the DFC action (s) has / have been subscribed for input and / or output data format conversion. For example, if the mission requires the action as subscribed to as in Table 8, the A-CAP inserts the required DFC action after the action, as indicated by the value of ‘Output Data format alignment indicator’ and ‘Output Data format conversion subscription’ in Table 8.

[0168] The updated mission specification may be applied in a future mission configuration and execution. In this way, the required data format conversion can be used to guarantee data format alignment of any data interaction type action. As previously specified, the consumer of the data interaction type action may be a device or a NC (entity) . FIG. 6 shows an example where the action is called by a device, but in other examples, the device may be replaced by a NC provider.

[0169] FIG. 7 shows a schematic flowchart of a method according to one or more embodiments of the present disclosure, which reflects the execution of an action performed by the first node to establish the configuration of one or more entities involved in the execution of a mission.

[0170] As step S701 of FIG. 7, the first node determines, based on a specification of a mission, one or more entities for which a configuration is required for executing the mission. The first node may be a node in charge of configuring the services involved in executing the mission, including for example a node which automatically configures network capabilities (A-CAP) . The mission may be carried out on a data plane (DP) and the one or more services are data plane services. Alternatively, the mission may be carried out on a control and management (C / M) plane and the one or more services are C / M plane services. To implement this method, the first node must know which of the one or more services and / or actions are required for the mission and which of the one or more entities will be used during its execution.

[0171] It will also be noted that not all entities involved in a mission need to be configured, and that the present method focuses on the steps related to the configuration of entities which need to be configured. Also, by “entities” , we refer to the physical nodes which implement the one or more services. An entity provides one or more services needed for executing the mission, and services are logically implemented on the physical nodes (i.e. the entities. ) A mission may be carried on data plane (DP) or on control and management (C / M) plane. Whether the mission is a DP or C / M plane mission, a mission specification is first generated (as per step 3.7 on FIG. 3B) , and the mission is then instantiated (step 4 in FIG. 3B) . These steps may be performed by the first node (A-CAP) .

[0172] At step S702 of FIG. 7, the first node sends a configuration request to each of the one or more entities needing to be configured. The configuration request indicates one or more configuration parameters for executing the mission, based on the mission specification. The configuration parameters included in the configuration request may include the following information: an identifier of an established mission session, a number of configuration profiles, and one or more configuration profiles.

[0173] A configuration profile comprises: an operation identifier of the mission, processing logic settings, and action settings. Each configuration request can include a single or multiple configuration profiles, the number of which is indicated by the ‘number of configuration profiles’ . The processing logic settings may specify the relationship between the execution of a target operation and the execution of other operation (s) belonging to the same mission session, including for example, whether the target operation should be executed before or after which operation. A target operation is related to the operation identifier, i.e. it is identified by the operation identifier. Given a configuration profile, the target operation is identified by the operation identifier of the mission included in the configuration profile. Examples of processing logic settings include a precondition operation setting, indicating other mission operation (s) to be executed before the target mission session operation; a combination operation setting, indicating other mission operation (s) to be executed within the execution of the target mission operation; and a next operation setting, indicating the next mission operation (s) to be executed after the target mission session operation. Also, the identifier of the established mission session and the operation identifier of the mission may be used in each interaction occurring during the execution of operations belonging to the mission session, such that a corresponding configuration profile is associated with each of the identifier of the established mission session and the operation identifier of the mission.

[0174] The first node then receives, from the one or more entities, a configuration response indicating whether operations related to the mission have been successfully configured, as in step S703. The configuration response includes, for each configuration profile, operation identifier (s) of the mission and corresponding indicator (s) indicating whether the operations related to the mission of the one or more services have been successfully configured.

[0175] It will be noted that, before the first node can send the configuration requests, an agreement between the different entities and the first node will have been established, by which the entities have agreed to receive configuration requests from the first node. In other words, the configuration action provided by the first node must first be subscribed to by the different entities, for example with a specific field in an action call, such as an “operation agreement” parameter.

[0176] In some implementation, a subscription from a first service provider of one or more of the services, to the first node, will include an indication of whether a subscription to a service will be carried by an action call from a first entity of the one or more entities to a second entity. This indication may be used by the first node to determine the one or more entities for which the configuration is required.

[0177] The action settings included in the configuration request will vary depending on whether the mission is to be carried out on the data plane or on the control and management plane. An action setting may correspond to indications specifying how to perform an operation of the target mission session as part of the execution of the mission. In cases where the mission is to be carried on the data plane, and that the services are data plane services, the action settings may comprise an indication of whether the entity that received the configuration request is a customer or a service provider of a corresponding service of the target mission operation. The action settings may also comprise an entity identifier, which will correspond to an identifier of a device or an entity, to identify one or more subscription (s) between the service provider of the corresponding service and customer. The action settings may also comprise a subscription identifier for identifying subscription parameters of the corresponding service; a processing Quality of Service (QoS) requirement; and a connection identifier to identify a one-way connection to be used for forwarding data packets. A destination of the one-way connection may be an entity that receives data from the entity that received the configuration request during the execution of the target mission operation. The action settings may also comprise a transmission QoS indicator (QoSI) to identify a predefined or preconfigured QoS rule when forwarding the data packets.

[0178] In cases where the mission is to be carried on the C / M plane, the action settings may comprise an indication of whether an entity that received the configuration request is a customer or as service provider of a corresponding service of the target mission operation; an entity identifier which may correspond to an identifier of a device or an entity, permitting to identify one or more subscription (s) between the service provider of the corresponding service and the customer. The action settings may also comprise a subscription identifier for identifying subscription parameters of the corresponding service; and an identification of a destination entity with which the entity that received the configuration request needs to communicate during the execution of the target mission session operation.

[0179] The following paragraphs will describe an example NCDL of the action of establishing the configuration of an entity, such as a network capability provider, by a first node in order to perform a mission on a data plane.

[0180] The action provider and customer / client: the action is provided by the first node, which may provide automatic or advanced capability programming, referred to as A-CAP. The action may be subscribed to by a customer, via one of its devices.

[0181] The name of the action may be: establishment of NC (entity) configuration for a data plane mission.

[0182] Purpose of the action: for a given data plane mission, the services involved in executing the mission (such as network capabilities) can provide their functionalities during mission execution based on the received A-CAP configuration messages.

[0183] Pre-condition: A control and management (C / M) access session must first be set up for the data plane services (DP NCs) which are to be configured. A mission specification must also be available at the first node (A-CAP) and the mission instantiation must have been performed, i.e., the involved NC (entity) identifier and the actions required by each entity involved in executing the mission are determined.

[0184] Post-condition: The data plane mission services (including entities involved for mission execution) are configured as needed.

[0185] The NCDL of the action is given in Table 9. Table 9: NCDL of Action ‘Establishment of NC configuration for a Data plane mission’

[0186] The parameters shown represent different capability dimensions (or fields) for the action of the establishment of an entity configuration for a data plane mission. The capability dimensions can include an operation agreement, input dimensions and output dimensions (NCDL output) , in which the input dimensions are used to indicate required input information in order for the execution of the action, the output dimensions are used to indicate outputs of the action.

[0187] The definitions of the capability dimensions illustrated in Table 9 are as follows: - Operation agreement : This field corresponds to the input from the client or customer during service subscription for this  action, which is used to indicate the operation parameters that govern the operation of an action. For example, when the client subscribes to this action with a service provisioning management node (SPM) , this field can indicate the client’s preference by specifying the operation agreement dimensions. - Output: This field corresponds to the output from the action provider for the execution of the action. For example, the  dimensions in Table 9 which belong to the Output type are used to describe the information provided by the mission configuration message for the NC, which is sent from the A-CAP to the mission-involved DP NC (entity) . - Input: This field corresponds to the input from the action consumer for the execution of the action. For example, the  dimensions in Table 9 that belong to the Input type are used to describe the information provided in response to the mission configuration message, which is sent by the DP NC (entity) that received the configuration message.

[0188] Definition of capability dimensions: the attribute (M) or (O) indicates the dimension is mandatory or optional. - Action call type (M) : this is a type of action call made by the DP NC, e.g., the underlined option in the above table  indicating that the action call made by this DP NC will carry the NCDL subscription information related to the action. This field value may be used by the first node (A-CAP) to determine which NC (entity) needs to receive the configuration message. - Mission session ID (M) : this dimension provides the identifier (ID) of the established DP mission session (MSID) which  is the target of the configuration. - Number of configuration profiles (M) : this dimension indicates the number of configuration profiles included in the  request for the DP mission session (specified by MSID) , where each configuration profile (comprising processing logic settings and perform action setting) is for a specific mission operation. - Mission operation ID (M) : ID of mission operation (MOID) , the configuration profile of which is given in this request.  Note that the execution of each operation at most requires the communication between one pair of NC (entity) . In Table 9, n MOIDs are given as an example and each of them is associated with the ‘Processing logic setting’ and ‘Perform Action setting’ given in the same row.

[0189] It should be noted that both MSID and MOID must be indicated in each interaction (e.g., action call, action response) occurring during the execution of the target operation within the target mission session (referred to as the target mission session operation) . These identifiers can be used to associate the interaction with the corresponding configuration profile. - Processing logic settings: These settings specify the relationship between the execution of the target operation and the  execution of other operation (s) belonging to the same mission session. For example, they specify whether the target operation should be executed before or after a particular operation. The dimension consists of following Information Elements (IEs) , where the attribute (M) or (O) indicates the IE is mandatory IE or optional. ο Pre-condition operation set (O) : ID of the other mission operation (s) that has to be executed before the target  mission session operation, i.e., precondition for the execution of target operation. If there is no precondition operation or this operation is triggered by its action call, the IE is not applied. ο Combination operation set (O) : ID of the other mission operation (s) that has to be executed within the execution  of the target mission session operation, i.e., involved operation (s) for the execution of target operation. If there is no involved operation, the IE is not applied. ο Next operation set (O) : ID of the next mission operation (s) that will be executed just after the target mission  session operation. In some cases, the output of the target operation can be utilized as the input / trigger of the next operation (i.e., the trigger of next operation is included by the target operation) , in which case ID of the triggered next operation is needed by the input / trigger. If there is no next operation or the trigger of the next operation is not included in this operation, the IE is not applied. - Perform Action setting: This dimension or field specifies how to perform the corresponding action for the target mission  session operation. The dimension consists of following IEs, where the attribute (M) or (O) indicates the IE is mandatory IE or optional. ο Side (M) : an indication of the NC (entity) which has received the configuration request is either the ‘Customer’  or ’ Provider’ of the corresponding action. ο Other side ID (M) : identifier of the other side (which can be a device / customer or other NC (entity) ) used during  the subscription of the corresponding action, e.g., if the configuration is sent to the action provider (Side = ’Provider’ ) , the ID of ‘Customer’ of the corresponding Action is given in this IE. ο NCDL subscription ID (M) : subscription results of the corresponding action, which specifies how to perform  the target mission session operation, e.g., action ID, action parameters, Input  / Output format, etc. ο Processing QoS requirements (O) : QoS requirements of performing the action, e.g., learning accuracy, learning  latency. If not additional QoS is required other than the QoS requirement indicated by the action subscription results, the IE is not applied. ο Connection ID (O) : ID of a one-way connection (CID) between two NC (entity) , source of which is this  configured NC (entity) . Data packet sent by this NC (entity) for the target mission session operation needs to carry the CID for data forwarding. If no data sent by this NC (entity) for the execution of the target mission session operation, the IE is not applied. ο Transmission QoS indicator (O) : ID of a predefined or preconfigured QoS rule (QoSI) . Data packets sent by  this NC (entity) for the target mission session operation needs to carry the QoSI (if any) for data forwarding. If no QoS is required for data transmission of the target mission session operation, the IE is not applied. - Configuration results indicator: An indicator showing whether the configuration was successful or failed for the target  mission session operation, which can be identified by a mission operation ID. Use of this NCDL:

[0190] For a DP mission, once the first node (e.g., A-CAP) generates the feasible mission specification and completes the mission instantiation, A-CAP generates and sends a configuration request to the relevant NC (entity) based on the feasible mission specification. A feasible mission specification requires a valid NC subscription and adequate data format alignment. The first node (A-CAP) may need to perform steps 1 to 3.7 in FIG. 3B, including the action "trigger on-demand NC subscription for device / customer" and the utilization phase of the data alignment setup scheme, as shown in FIG. 6. When the action described in Table 9 is triggered, the first node sends a configuration request according to the output dimensions of Table 9 to each NC (entity) concerned. The NC (entity) concerned is configured on the basis of the configuration request (s) received, then sends a configuration response to the first node, whose format follows the input dimensions of Table 9.

[0191] When the first node (A-CAP) sends a configuration request to the relevant NC (entity) , the first node must identify the appropriate NC (entity) based on the feasible mission specification, specifically for each action call (i.e., mission operation) determined by the mission specification. For each action call, the first node must configure its Client NC (action consumer) and / or Server NC (action provider) . The first node considers two factors when identifying the relevant NC (entity) for configuration: 1. Action type: Actions can be classified into two types based on their trigger. One type is externally triggered actions, which  require external input (e.g., an action call from NC (entity) or device / customer) to be initiated. The other type is non-externally triggered actions, which can be initiated without external input (e.g., the action is triggered by a change in monitored status) . 2. Action call type: This is indicated by the Client NC when subscribing to the configuration action provided by A-CAP. In  the subscription table (Table 9) between the Client NC and A-CAP, the value of "Action call type" is either "NCDL subscription carried" or "NCDL subscription not carried, " which indicates whether or not the Client NC will carry the corresponding NCDL subscription results in the action call it makes. In other words, if the Client NC selects "NCDL subscription carried" for "Action call type" it means that when the Client NC calls any externally triggered action, the Server NC can obtain the subscription results for this action in the action call received. In this case, the Server NC can receive instructions on how to perform the action based on the action call, rather than relying on the three mandatory IEs of the "Perform Action setting" dimension in the mission configuration profile. Therefore, the mission configuration profile related to this action is not required by the Server NC if none of the optional IEs in the configuration profile are applied. This means the Server NC does not require the mission configuration for the action (i.e., mission operation) .

[0192] Table 10 summarizes which NC (entity) requires the mission configuration. Table 10: The summary of mission configuration requirements.

[0193] The following paragraphs will describe an example NCDL of the action for establishing the configuration of an entity, such as a network capability provider, by a first node, in order to perform a mission on a control and management plane.

[0194] The action provider and customer / client: the action is provided by the first node, which may provide automatic or advanced capability programming, referred to as A-CAP. The action may be subscribed to by a customer, via one of its devices.

[0195] The name of the action may be: establishment of NC configuration for a C / M plane mission.

[0196] Purpose of the action: for a given C / M plane mission, the services involved in executing the mission (such as network capabilities) can provide their functionalities during mission execution based on the received A-CAP configuration messages.

[0197] Pre-condition: A control and management (C / M) access session must first be set up for the C / M plane services (C / M plane NCs) which are to be configured. A mission specification must also be available at the first node (A-CAP) and the mission instantiation must have been performed, i.e., the identifiers of the involved NCs (entities) and the actions required by each entity involved in executing the mission are determined.

[0198] Post-condition: The C / M plane mission services (including entities involved for mission execution) are configured as needed

[0199] The NCDL of the action is given in Table 11. Table 11: NCDL of Action ‘Establishment of NC configuration for a C / M plane mission’

[0200] The parameters shown represent different capability dimensions (or fields) for the action of the establishment of an entity configuration for a data plane mission. The capability dimensions can include input dimensions and output dimensions (NCDL output) , in which the input dimensions are used to indicate required input information in order for the execution of the action, the output dimensions are used to indicate outputs of the action.

[0201] The definitions of the capability dimensions illustrated in Table 11 are as follows: - Operation agreement: This field corresponds to the input from the client or customer during service subscription for this  action, which is used to indicate the operation parameters that govern the operation of an action. For example, when the client subscribes to this action with a service provisioning management node (SPM) , this field can indicate the client’s preference by specifying the operation agreement dimensions. - Output: This field corresponds to the output from the action provider for the execution of the action. For example, the  dimensions in Table 11 that belong to the Output type are used to describe the information provided by the mission configuration message for the NC, which is sent from the A-CAP to the mission-involved C / M plane NC (entity) . - Input: This field corresponds to the input from the action consumer for the execution of the action. For example, the  dimensions in Table 11 which belong to the Input type are used to describe the information provided in response to the mission configuration message, which is sent by the C / M plane NC (entity) that received the configuration message.

[0202] Definition of capability dimensions: the attribute (M) or (O) indicates the dimension is mandatory or optional. - Action call type (M) : this is a type of action call made by the C / M plane NC, e.g., the option with underline in the above  table indicating action call made by this DP NC will carry the NCDL subscription information related to the action. This field value may be used by the first node (A-CAP) to determine which NC (entity) needs to receive the configuration message. - Mission session ID (M) : this dimension provides the identifier (ID) of the established C / M plane mission session (MSID)  which is the target of the configuration. - Number of configuration profiles (M) : this dimension indicates the number of configuration profiles included in the  request for the C / M plane mission session (specified by MSID) , where each configuration profile (comprising processing logic settings and perform action setting) is for a specific mission operation. - Mission operation ID (M) : ID of mission operation (MOID) , the configuration profile of which is given in this request.  Note that the execution of each operation at most requires the communication between one pair of NC (entity) . In Table 11, n MOIDs are given as an example and each of them is associated with the ‘Processing logic setting’ and ‘Perform Action setting’ given in the same row.

[0203] It should be noted that both MSID and MOID must be indicated in each interaction (e.g., action call, action response) occurring during the execution of the target operation within the target mission session (referred to as the target mission session operation) . These identifiers can be used to associate the interaction with the corresponding configuration profile. - Processing logic setting: These settings specify the relationship between the execution of the target operation and the  execution of other operation (s) belonging to the same mission session. For example, they specify whether the target operation should be executed before or after a particular operation. The dimension consists of following Information Elements (IEs) , where the attribute (M) or (O) indicates the IE is mandatory IE or optional. ο Pre-condition operation set (O) : ID of the other mission operation (s) that has to be executed before the target  mission session operation, i.e., precondition for the execution of target operation. If there is no precondition operation or this operation is triggered by its action call, the IE is not applied. ο Combination operation set (O) : ID of the other mission operation (s) that has to be executed within the execution  of the target mission session operation, i.e., involved operation (s) for the execution of target operation. If there is no involved operation, the IE is not applied. ο Next operation set (O) : ID of the next mission operation (s) that will be executed just after the target mission  session operation. In some cases, the output of the target operation can be utilized as the input / trigger of the next operation (i.e., the trigger of next operation is included by the target operation) , in which case ID of the triggered next operation is needed by the input / trigger. If there is no next operation or the trigger of the next operation is not included in this operation, the IE is not applied. - Perform Action setting: This dimension or field specifies how to perform the corresponding action for the target mission  session operation. The dimension consists of following IEs, where the attribute (M) or (O) indicates the IE is mandatory IE or optional. ο Side (M) : an indication of the NC (entity) which has received the configuration request is either the ‘Customer’  or ’Provider’ of the corresponding action. ο Other side ID (M) : identifier of the other side (which can be a device / customer or other NC (entity) ) used during  the subscription of the corresponding action, e.g., if the configuration is sent to the action provider (Side = ’Provider’ ) , the ID of ‘Customer’ of the corresponding Action is given in this IE. ο NCDL subscription ID (M) : subscription results of the corresponding action, which specifies how to perform  the target mission session operation, e.g., action ID, action parameters, Input  / Output format, and etc. ο Destination NC (entity) ID (O) : ID of NC entity which needs to be communicated with during the execution of  target mission session operation. Message (C / M plane packet) sent by this NC (entity) for the target mission session operation needs to carry the destination NC (entity) ID for message forwarding. If no message sent by this NC (entity) for the execution of the target mission session operation, the IE is not applied. If this NC (entity) only sends message (s) as reply to its received messages (i.e., the Destination ID can be obtained from the received messages) , the IE is not applied. - Configuration results indicator: An indicator indicating whether the configuration was successful or failed for the target  mission session operation, which can be identified by a mission operation ID. Use of this NCDL:

[0204] For a C / M plane mission, once the first node (e.g. A-CAP) has generated a feasible mission specification and completes the mission instantiation, the first node sends a configuration request to the relevant NC (entity) based on the mission specification. A feasible mission specification requires a valid NC subscription. The first node may need to perform steps 1～3.5 and step 3.7 in in FIG. 3B, including the action "trigger on-demand NC subscription for device (s) . When the action described in table 11 is called, the first node sends a configuration request to each NC (entity) concerned according to the output dimensions in table 11. The concerned NC (entity) is configured on the basis of the configuration request (s) received, and then sends a configuration response to the first node, whose format follows the input dimensions of table 11.

[0205] When the first node (A-CAP) sends a configuration request to the relevant NC (entity) , the first node must identify the appropriate NC (entity) based on the feasible mission specification, specifically for each action call (i.e., mission operation) determined by the mission specification. For each action call, the first node must configure its Client NC (action consumer) and / or Server NC (action provider) . The detailed description as to which NC (entity) needs configuration for executing the mission is similar to that presented in the paragraphs above, relating to establishing NC configuration for DP services, and a summary is given in Table 10.

[0206] FIG. 8 provides a description of a step which reflects the execution of an action performed by the first node to remove the configuration of one or more entities involved in the execution of a mission.

[0207] As per step S801 of FIG. 8, the first node (which can be a node configured to automatically program network capabilities needed for the executing of missions, also referred to as A-CAP) sends a configuration removal request to remove configurations from one or more entities involved in the execution of one or more missions. The entities will typically have first received configuration requests from the first node for the execution of a mission, and once the mission is executed, the configurations applied to conduct the mission may need to be removed. The mission removal action can delete the configuration related to one or multiple missions in a single request. The configuration removal request includes information about a plane type, mission session (s) and mission operation (s) involved in carrying out each mission which has been completed.

[0208] The configuration removal request may comprise whether the plane type is a data plane (DP) or a control and management (C / M) plane and a number of mission session operations. Each mission session operation may be identified by a set of identifiers of the established mission sessions and identifiers of the mission operations. In other words, mission session operations can each be identified by a combination of a mission session identifier and a mission operation identifier. In a single mission configuration removal request, the configuration to be removed may be associated with one or multiple mission sessions, each of which may involve one or multiple mission operations.

[0209] This configuration removal request may be sent by the first node when one or more missions have been completed or when one or more missions are outdated.

[0210] The following paragraphs will describe an exemplary NCDL of an action for removing the configuration of an entity, such as a network capability provider, by a first node. This action may be called in cases where the mission has been completed and / or is outdated.

[0211] The action provider and customer / client: the action is provided by the first node, which may provide automatic or advanced capability programming, and which may be referred to as A-CAP. The action may have been subscribed to by a service provided on the data plane or by a service performed on a C / M plane.

[0212] The name of the action may be: removal of NC configuration for data plane or C / M plane mission.

[0213] Purpose of the action: the service removes the current configuration of one or more entities for a specific data plane or C / M plane mission session (s) .

[0214] Pre-condition: The configuration for the Data Plane or C / M Plane mission session is outdated, e.g., when the mission execution has been terminated.

[0215] Post-condition: The configuration for the data or C / M mission session is removed from the entities having provided the network capability services.

[0216] The NCDL of the action is given in Table 12. Table 12: NCDL of Action ‘Removal of NC configuration for a Data plane or C / M plane mission’

[0217] The definitions of the capability dimension type, as in Table 12, is as follows: - Output: The outputs comprise information to allow the action provider to execute the configuration removal action. For  example, the dimensions in Table 12 describe the information provided in the mission configuration removal message intended for an NC. This message is sent from A-CAP to the Data Plane or C / M Plane NC (entity) that has been configured for a specific mission session.

[0218] The definitions of the capability dimensions provided in Table 12 are as follows: - Mission plane: this dimension indicates the type of mission session plane (DP or C / M plane) to be removed. - Number of mission session operations to be removed: this dimension or field indicates the number of mission session  operations which are to be removed based on the request, where each mission session operation is associated with a specific combination of a mission session identifier and a mission operation identifier. - Mission session ID (M) : this dimension or field corresponds to an identifier of the established data plane or C / M plane  mission session (MSID) which is the target of the removal request. It will be noted that the configuration related to one or multiple mission sessions within the same plane type can be removed via one request message. - Mission operation ID (M) : this dimension corresponds to the mission operation identifier (MOID) which is the target of  the removal request. The configuration related to one or multiple mission operations can be removed via one request message. Use of this NCDL: After the execution of a mission, the mission session is terminated and the first node (e.g. A-CAP) may instruct the involved  NCs (entity) to remove their configuration related to this mission. The instruction to remove the mission configuration can be sent in a configuration removal request. The request format follows the output dimensions indicated in Table 12, which specify the configuration to be removed for the NC (entity) . An example of a request message is provided in Table 13, where the removal of configurations for three mission operations across two different mission sessions is requested. Table 13: Example of a request sent by A-CAP of Action ‘Removal of NC configuration for a Data plane or C / M plane mission’

[0219] Referring now to FIG. 9, an example of the process for generating a feasible mission specification, i.e. which can be implemented, is provided. The example provided is for a DP mission. The mission specification generation is performed by a node responsible for automatic or advanced network capability programming, also referred to as the first node, and indicated as A-CAP in FIG. 9. Before the process can be initiated, a mission specification needs to be available in the A-CAP node (shown as step 0 in FIG. 9) , which can be created through mission intent and sub-intent resolution (e.g., steps 1 to 3.1 in FIG. 3B) . After the procedure, an updated mission specification is created, in which NC subscription required by the mission is completed and the alignment for data interaction is guaranteed.

[0220] In this example, two NCs, also referred to as entities, identified by NC1 and NC2, are involved in the mission and the initial mission specification consists of two sequential mission operations, as shown in Table 14 below. In this example, prior to initiating the process, the subscription for NC1 is incomplete. More specifically, the device has not subscribed to the services of entity NC1. Table 14: Example of initial mission specification and related subscription information

[0221] Referring to FIG. 9, the method comprises the following steps: 1. The A-CAP node checks the device's NC subscription with SPM / CONET based on the initial mission specification.  The incomplete subscription between the device and NC1 is detected, as shown in Table 14. 2. The A-CAP node performs the action ‘Trigger on-demand NC subscription for device / customer” , defined above.  Specifically, A-CAP generates an NC subscription trigger request (REQ) for the device, indicating the ID of the required action and NC (entity) , e.g., the ID of Action1 and NC1. 3. The A-CAP node sends the NC subscription trigger REQ to the Device. 4. The device subscribes to the Action1 provided by node NC1 by calling an action named ‘Subscription of NC by 6G  customers’ , which is provided by an SPM / CONET node. The device sends an NC subscription request to the SPM / CONET node, following the instruction contained in the on-trigger request received from the A-CAP node. 5. The SPM / CONET node performs the action ‘Subscription of NC by 6G customers’ according to the request (REQ)  received from the Device. 6. Once the NC subscription Action has been performed, the SPM / CONET node sends a response to the Device, which  may include the NCDL subscription results between the Device and the NC1 node. Meanwhile, the maintained subscription information is updated accordingly, as shown in Table 14. 7. The device sends an NC subscription trigger response to the A-CAP node, which may include the subscription results  obtained in Step 6. 8. The A-CAP node checks the NCDL subscription results related to data format conversion requirements. As shown in  Table 14, the requirement for a DFC action (specified by DFC-NCDL2) is detected from the input data of Action3. The subscription result of the required DFC action is determined by node NC1 when subscribing to Action3, which is provided by NC2. This process of data format alignment has been described in detail in previous paragraphs. 9. The A-CAP node inserts the required data format conversion action as an additional operation in the flow of operations  specified in the initial mission specification. In this example the DFC action is added between Action1 and Action3. 10. The A-CAP node updates the mission specification and the local cache accordingly. The updated mission specification  is shown in Table 15, which can be applied in the future mission configuration procedure, and such that the data format alignment is guaranteed during mission execution. Table 15: Example of an updated mission specification generated as per Figure 9

[0222] Referring now to FIG. 10, an exemplary implementation of a data plane mission configuration is illustrated. To support packet forwarding required for a DP mission, a forwarding rule should be preconfigured at the anchor data plane trustworthy gateways (Data-TW-GWs) of each NC (entity) involved in the mission's execution. It should be noted that an anchor Data-TW-GW is a gateway (GW) with which the NC has an established connection. Each forwarding rule is associated with a Connection ID (the CID discussed in previous paragraphs, in relation to the action for establishing an NC configuration for a data plane mission) , which is the ID of a one-way connection between two NCs (entities) . Examples of forwarding rules maintained at the anchor Data-TW-GW of NC-a and NC-b (denoted by Data-TW-GW-NC-a and Data-TW-GW-NC-b) is given in Table 16, in which the three IDs (CID-ba, CID-ab, CID-ac) are for three one-way connections that are related to NC-a and NC-b (from NC-b to NC-a, from NC-a to NC-b, from NC-a to NC-c) . - For a connection for which NC-a is the destination, the forwarding rule at NC-a’s anchor Data-TW-GW indicates that the  packet should be forwarded to NC-a, such as CID-ba in Table 16. - For a connection for which NC-a is the source, if the anchor Data-TW-GW of the destination NC (entity) (i.e., destination  anchor Data-TW-GW) is different from that of NC-a, the forwarding rule at NC-a’s anchor Data-TW-GW indicates that the packet should be forwarded to the destination anchor Data-TW-GW, such as CID-ab in Table 16. - For a connection for which NC-a is the source, if the anchor Data-TW-GW of the destination NC (entity) is the same as  that of NC-a, the forwarding rule at NC-a’s anchor Data-TW-GW indicates the packet should be forwarded to the destination NC (entity) , such as CID-ac in Table 16. - For a one-way connection, if the anchor Data-TW-GW for source and destination NC (entities) are different, the  forwarding rule needs to be configured at both of them, such as CID-ba and CID-ab in Table 16. - For a one-way connection, if the anchor Data-TW-GW for the source and destination NCs (entities) are the same, the  forwarding rule needs to be configured at the anchor Data-TW-GW, such as CID-ac. Table 16: Example of forwarding rule at the anchor Data-TW-GW of NC-a and NC-b

[0223] The Data-TW-GW maintains the forwarding rule for the DP mission-required connection, which is established or removed according to the request of the A-CAP node. The A-CAP maintains the information of CID that is existing in network, i.e., the ID of which connection that has forwarding rule (s) maintained at the according Data-TW-GW (s) . For each DP mission operation, one-way or two-way data transmission between a determined pair of NCs (entities) may be needed, which is based on one or two one-way connections. For a DP mission, the A-CAP needs to assign CID for each connection required by each mission operation. - If there is an existing a CID with the required one-way connection (i.e., same source and destination NC (entity) and same  QoS requirement if any) , the A-CAP node may assign the existing CID to the DP mission operation. The assigned CID should be utilized by the NC configuration phase (as discussed for the establishment of the NC configuration action) , while it may not be needed for the GW configuration phase. - If no existing CID can match the requirement of the DP mission operation, a new CID is created by the A-CAP node that  is bound to the required one-way connection and assigned to the DP mission operation. The corresponding forwarding rule at the anchor Data-TW-GW (s) for both source and destination NC (entity) should be generated and configured in the GW configuration phase for the mission. For the NC configuration phase, the assigned CID should be utilized.

[0224] Referring to FIG. 10, an exemplary implementation for a DP mission is provided. FIG. 10 shows how the A-CAP node can configure the mission-involved elements (e.g., NCs (entities) for processing, and anchor Data-TW-GW for forwarding) to enable the execution of the mission.

[0225] Prior to initiating the process, a feasible mission specification should be available at the A-CAP node, which can be created via the procedure shown in FIG. 9. The mission instantiation should also be completed, since it determines the involved NC (entity) and Data-TW-GW. After this process, the mission configuration (which comprises the NC configuration and the GW configuration phases in FIG. 10) is completed and the execution of the mission (referring to the mission execution phase in FIG. 10) is enabled. In this example, three NCs (entities) (NC1, NC2, and NC3 (data format conversion) ) are involved in the execution of the mission and the feasible mission specification consists of three sequential mission operations, as shown in Table 15. In FIG. 10, one anchor Data-TW-GW is shown to illustrate anchor Data-TW-GW of all involved NCs (entities) .

[0226] Referring to FIG. 9, the method comprises the following steps:

[0227] NC configuration phase: 1. The A-CAP node performs the Action ‘Establishment of NC configuration for a Data plane mission’ , as described  above: 1.1. The A-CAP node assigns (reuses or creates) IDs for each connection required by each mission operation. 1.2. The A-CAP node creates one or more configuration request (s) for related NCs (entity) based on the feasible  mission specification and mission instantiation result. A relevant NC (entity) is determined as indicated in previous paragraphs. One or two configuration profiles can be created for each mission operation, following the ‘Output’ dimensions in Table 9, which are referenced in the description of the action for establishing an NC configuration for a data plane mission. 1.3 The A-CAP node sends configuration request to NCs (entity) involved in the mission. It will be noted that one  or multiple configuration profiles may be included in the configuration request, based on the involvement of the relevant NCs (entities) in mission operation (s) . 1.4. The relevant NCs (entities) are configured based on the received configuration request (s) . 1.5 The relevant NCs (entities) send configuration response (s) to the A-CAP node, the format of which follows the  ‘Input’ dimension in Table 9.

[0228] GW configuration phase (optional) : If the configuration of all NCs is completed and a new connection ID is created for this DP mission, in Step 1.1: 2. The A-CAP node creates configuration request (s) for the related Data-TW-GW based on the newly created  connection ID and its bound one-way connection, as discussed above. 3. The A-CAP node sends a forwarding rule establishment request to the related network for connectivity node  (NET4CON entity) to trigger a NET4CON action ‘Establishment of forwarding rule for a DP mission’ . The format of the request may follow a description of the NET4CON action’s input. 4. The related Data-TW-GW is configured by the NET4CON node (entity) based on the received configuration  request (s) . 5. The related NET4CON node (entity) sends the configuration response (s) to the A-CAP node, the format of  which is following the description of the NET4CON action’s output.

[0229] Mission execution phase: When the required configuration for NCs (entity) and Data-TW-GWs is completed, the mission is ready to be executed. The mission execution can be controlled by the A-CAP node by sending an execution request and by receiving execution status reports.

[0230] The coordination among the mission-involved NCs (entities) and Data-TW-GW enables the mission execution, in which each NC (entity) and Data-TW-GW operates following the pre-configuration established for the DP mission: - The involved NC entity is able to perform the actions for each mission operation, which is defined by the feasible mission  specification as shown in Table 15, and triggers the next mission operation if needed. - The involved Data-TW-GW is able to forward data based on the received connection ID (CID) and the forwarding rule  which is associated with the CID.

[0231] FIG. 11 shows a schematic structural diagram of an apparatus according to one or more implementations of the present disclosure. As shown in FIG. 11, the apparatus 1100 may include: a receiving module 1101, configured to receive, from a second node, a request related to the management of an  identifier of a device for one or more services, wherein the request comprises at least one operation to be performed by the first node; a processing module 1102, configured to manage the identifier of the device based on the request; a transmitting module 1103, configured to a response to the second node, wherein the response is based on the at  least one operation performed by the first node.

[0232] FIG. 12 shows a schematic structural diagram of an apparatus according to one or more implementations of the present disclosure. As shown in FIG. 12, the apparatus 1200 may include: a receiving module 1201, configured to receive, from a second node, generate credentials for a device, the request  comprising information including an identifier of the device, an authentication method and a corresponding algorithm; a processing module 1202, configured to generate the credentials for the device based on the information in the  request; and a transmitting module 1203, configured to a response to the second node, wherein the response comprises the  credentials generated for the device based on at least one of the identifiers of the device, the authentication method and the corresponding algorithm.

[0233] FIG. 13 shows a schematic structural diagram of an apparatus according to one or more implementations of the present disclosure, the apparatus may be a transmitting node or a receiving node. As shown in FIG. 13, the apparatus 1300 includes a processor 1301, an interface 1302 for communicating with other devices, a memory 1303 is coupled to the processor 1301. The memory 1303 may be stored with computer execution instructions, and the processor 1301 executes computer execution instructions stored in the memory 1303 to enable the apparatus to execute any of the above methods. In some implementations, the memory 1303 may be included or may not be included in the apparatus.

[0234] In some aspects of the present disclosure, there is provided an apparatus which includes a processor and a memory. The memory is storing instructions that cause the processor to perform any of the above methods.

[0235] It should be understood that the processor may be an integrated circuit chip and has a data processing capability. In an implementation process, steps of the foregoing method embodiments may be completed by using a hardware integrated logic circuit in the processor, or by using instructions in a form of software. The processor may be a general-purpose processor, a central processing unit (CPU) , a graphics processing unit (GPU) , a neural processing unit (NPU) , a system on chip (SoC) or another programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The processor may implement or perform the methods, the steps, and the logical block diagrams that are disclosed in the embodiments of the present disclosure. The general-purpose processor may be a microprocessor, or the processor may be any conventional processor or the like. The steps of the methods disclosed with reference to the embodiments of the present disclosure may be directly performed and completed by a hardware decoding processor, or may be performed and completed by using a combination of hardware in the decoding processor and a software module. The software module may be located in a mature storage medium in the art, such as a random-access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, or a register. The storage medium is located in the memory, and the processor reads information in the memory and completes the steps of the foregoing methods in combination with hardware in the processor.

[0236] It may be understood that the memory in the embodiments of the present disclosure may be a volatile memory or a non-volatile memory, or may include both a volatile memory and a non-volatile memory. The non-volatile memory may be a read-only memory (Read-Only Memory, ROM) , a programmable read-only memory (Programmable ROM, PROM) , an erasable programmable read-only memory (Erasable PROM, EPROM) , an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM) , or a flash memory. The volatile memory may be a random-access memory (Random Access Memory, RAM) and is used as an external cache. By way of example rather than limitation, many forms of RAMs may be used, and are, for example, a static random access memory (Static RAM, SRAM) , a dynamic random access memory (Dynamic RAM, DRAM) , a synchronous dynamic random access memory (Synchronous DRAM, SDRAM) , a double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM) , an enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM) , a synchronous link dynamic random access memory (Synchronous link DRAM, SLDRAM) , and a direct rambus random access memory (Direct Rambus RAM, DR RAM) .

[0237] It should be noted that the memory described in this specification includes but is not limited to these memories and could be a memory of any other appropriate type.

[0238] In some aspects of the present disclosure, there is provided a system, including apparatuses used to execute the steps in any of the above methods.

[0239] In some aspects of the present disclosure, there is provided a computing device cluster, including a processing circuitry for performing any of the above methods.

[0240] FIG. 14 shows a schematic diagram of an architecture of a computing device cluster according to one or more embodiments of the present disclosure. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0241] As shown in FIG. 14, the cluster of computing devices described includes at least one computing device 1400. As shown in FIG. 14, for each of the at least one computing device 1400, it includes a processor 1402, an interface 1404 and optional a memory 1406, where the processor 1402, the interface 1404 and the memory 1406 may be connected through a bus 1408. The memory 1406 in one or more of the computing devices 1400 in the cluster of computing devices can hold the same instructions, so that the processor 1402 executes the instructions to execute the method described in the above embodiments.

[0242] In some possible implementations, some of the instructions for performing the method described in the above embodiments can also be separately held in the memory 1406 of the one or more computing devices 1400 in the cluster of computing devices. In other words, a combination of the one or more computing devices 1400 can jointly execute instructions for performing the method described in the above embodiments.

[0243] It is noted that the memories 1406 in the different computing devices 1400 in the cluster of computing devices can store different instructions for performing some of the functions of the computing devices 1400, respectively.

[0244] In some possible implementations, one or more computing devices in a cluster of computing devices can be connected via a network. Among other things, the network can be a wide area network or a local area network, etc. FIG. 15 illustrates one possible implementation. FIG. 15 shows a schematic diagram of a connection between computing devices 1500A and 1500B over a network according to one or more embodiments of the present disclosure. As shown in FIG. 15, the computing device 1500A includes a processor 1502A, an interface 1504A and optional a memory 1506A, where the processor 1502A, the interface 1504A and the memory 1506A may be connected through a bus 1508A; the computing device 1500B includes a processor 1502B, an interface 1504B and optional a memory 1506B, where the processor 1502B, the interface 1504B and the memory 1506B may be connected through a bus 1508B. The memory 1506A and the memory 1506B may be stored with computer execution instructions, and the processor 1502A and the processor 1502B execute computer execution instructions stored in the memory 1506A and the memory 1506B to enable the computing devices 1500A and 1500B to execute any of the above methods. The two computing devices 1500A and 1500B are connected to each other via a network. Specifically, the connection to said network is made through a communication interface in each computing device. In this class of possible implementations, the memory 1506A in the computing device 1500A holds instructions for performing a part of the method described in the above embodiments. At the same time, the memory 1506B in the computing device 1500B holds instructions for performing other part (s) of the method described in the above embodiments.

[0245] The functions of computing device 1500A illustrated in FIG. 15 can also be accomplished by multiple computing devices. Similarly, the functions of computing device 1500B can be accomplished by multiple computing devices.

[0246] In some aspects of the present disclosure, there is provided a computer program product including computer execution instructions which, when executed by a processor, cause the processor to execute any of the above methods.

[0247] In some aspects of the present disclosure, there is provided a computer program including computer execution instructions which, when executed by a processor, cause the processor to execute any of the above methods.

[0248] In some aspects of the present disclosure, there is provided a computer-readable medium storing computer execution instructions which, when executed by a processor, cause the processor to execute any of the above methods.

[0249] In some aspects of the present disclosure, there is provided a chip, including an input / output (I / O) interface and a processor, where the processor is configured to call and run computer execution instructions stored in a memory, to enable a device installing with the chip to execute any of the above methods.

[0250] A person skilled in the art should understand that embodiments of this application may be provided as a method, an apparatus (or system) , computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

[0251] 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.

[0252] Although the present disclosure describes methods and processes with steps in a certain order, one or more steps of the methods and processes may be omitted or altered as appropriate. One or more steps may take place in an order other than that in which they are described, as appropriate.

[0253] 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.

[0254] Although the present disclosure is described, at least in part, in terms of methods, a person of ordinary skill in the art will understand that the present disclosure is also directed to the various components for performing at least some of the aspects and features of the described methods, be it by way of hardware components, software or any combination of the two. Accordingly, the technical solution of the present disclosure may be embodied in the form of a software product. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer readable medium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk, or other storage media, for example. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein. The machine-executable instructions may be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform steps in a method according to examples of the present disclosure.

[0255] The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example implementations are to be considered in all respects as being only illustrative and not restrictive. Selected features from one or more of the above-described implementations may be combined to create alternative implementations not explicitly described, features suitable for such combinations being understood within the scope of this disclosure.

[0256] All values and sub-ranges within disclosed ranges are also disclosed. Also, although the systems, devices and processes disclosed and shown herein may include a specific number of elements / components, the systems, devices and assemblies could be modified to include additional or fewer of such elements / components. For example, although any of the elements / components disclosed may be referenced as being singular, the implementations disclosed herein could be modified to include a plurality of such elements / components. The subject matter described herein intends to cover and embrace all suitable changes in technology.

[0257] Although implementations have been described above with reference to the accompanying drawings, those of skill in the art will appreciate that variations and modifications may be made without departing from the scope thereof as defined by the appended claims.

Claims

1.A method applied to a first node, the method comprising:sending a subscription trigger request to a device required for executing a mission, to enable the device to subscribe to one or more services required to execute the mission, wherein the subscription trigger request comprises information related to each of the one or more services;receiving, from the device, a subscription trigger response, wherein the subscription trigger response indicates whether the one or more services required for the mission have been subscribed to by the device.2.The method of claim 1, wherein the subscription trigger request comprises at least one of: a number of subscriptions required to execute the mission; identifiers of the one or more services; identifiers of actions associated with each of the one or more services; a geographic area required for a service; and a period required for use of each of the one or more services.3.The method of claim 2, wherein the subscription trigger response comprises at least one of: an identifier of the device; the identifiers of the one or more services; the identifiers of the actions associated with each of the one or more services; a subscription indicator for each of the one or more services and / or the actions; and subscription results for successfully subscribed services.4.The method of claim 3, wherein the subscription results comprise a subset of subscription results indicating one or more settings for the actions, wherein the one or more settings are determined by the device.5.The method of any one of claims 1 to 4, comprising checking, at a second node, the subscription status of the device to the one or more services involved in executing the mission.6.The method of claim 5, wherein checking the subscription status is performed prior to sending the subscription trigger request or after receiving the subscription trigger response from the device.7.The method of claim 5 or 6, wherein the second node is a subscription library node.8.The method of any one of claims 1 to 7, wherein, if the subscription trigger response sent by the device indicates that subscription to the at least one of the one or more services is unsuccessful, the first node attempts a different intent resolution for the mission, for which unsubscribed services are replaced with other services and / or actions.9.The method of any one of claims 1 to 8, wherein:a subscription request is received at a third node from the device, to enable the device to subscribe to the one or more services to which the device has not yet subscribed to, wherein the subscription request specifies one or more subscription settings to subscribe to the one or more services needed to perform the mission;the third node enables the device subscribes to the one or more services according to the one or more subscription settings specified in the subscription request; anda subscription response is received at the device from the third node, wherein the subscription response indicates information of whether the one or more services have been subscribed to by the device, wherein the information is utilized by the device to generate the subset of subscription results in the subscription trigger response.10.The method of claim 9, wherein:the third node sends an update message to the second node, to update the second node regarding the one or more services to which the device has subscribed to.11.The method of any one of claims 1 to 10, wherein the first node provides an autonomous network capability programming (A-CAP) service.12.A method applied at a first node (device or NC provider) , the method comprising:receiving, from a second node, at least one of an input data format and an output data format corresponding to each action of one or more actions associated one or more services carried out on a data plane (DP) , the one or more services being involved in executing a mission,for the one or more actions associated with the one or more services for which the input data format and the output data format are acceptable for the first node, sending a subscription request to subscribe to the one or more actions, wherein the one or more actions are aligned actions;for the one or more actions for which at least one of the input data format and the output data format are not acceptable for the first node, wherein the one or more actions are unaligned actions,sending to the second node, a data format conversion (DFC) subscription request to subscribe to a DFC action to convert at least one of the input data and the output data to a desired input data format and / or a desired output data format;if the subscription to the DFC action by the first node is successful, sending to the second node a subscription request to subscribe to the unaligned actions, wherein at least one of the input data format and the output data format are converted to the desired input data format and / or the desired output data format by the DFC action, wherein the subscription request includes subscription results of the DFC action.13.The method of claim 12, wherein a regenerated version of the subscription request is transmitted by the second node to a service provider node of the one or more actions and / or of the DFC action.14.The method of claim 12 or 13, wherein for the unaligned actions:the first node obtains from the second node information on available DFC actions providing capabilities of data format conversion; andbased on the available DFC actions, the first node determines which DFC actions to subscribe to in order to perform a desired format conversion.15.The method of claim 14, wherein a first update message to a third node is sent by the second node, to confirm subscription to the DFC actions by the first node.16.The method of claim 15, wherein a second update message to the third node is sent by the second node, to confirm which actions are to implement the DFC actions, wherein the second update message includes subscription parameters defined for the DFC actions.17.The method of claim 12, wherein if the subscription to the DFC actions by the first node is unsuccessful, the first node is unable to subscribe to and use the unaligned actions.18.The method of any one of claims 12 to 17, wherein the subscription request to the one or more services involved for executing the mission comprises at least one of:the input data format of the one or more actions; an indicator of whether the input data format is aligned or not; the DFC actions to be used to convert the input data format to the desired input data format; the output data format; an indicator of whether the output data format is aligned or not; the DFC actions to be used to convert the output data format to the desired output data format.19.The method of any one of claims 12 to 18, wherein the subscription request to subscribe to the DFC actions comprises at least one of:a source data format, and a target data format.20.The method of any one of claims 12 to 19, wherein when the first node calls an action for executing the mission:subscription to the action by the first node based on a specification of the mission is verified by a fourth node;if the action requires execution of one or more DFC actions, the specification of the mission is updated by the fourth node by including the DFC actions subscribed to by the first node in the specification of the mission.21.The method of claim 20, wherein the specification of the mission is updated to include the one or more DFC actions in a flow of actions required to execute the mission, wherein placement of the one or more DFC actions depends on whether data format conversion is to be performed on at least one of an input data or an output data.22.A method applied at a first node comprising:determining, based on a specification of a mission, one or more entities for which a configuration is required for executing the mission, wherein the one or more entities provide one or more services;sending a configuration request to each of the one or more entities to be configured, wherein the configuration request indicates one or more parameters for executing the mission; andreceiving, from each of the one or more entities, a configuration response indicating whether operations related to the mission have been successfully configured.23.The method of claim 22, wherein a subscription from a first service provider of one of the one or more services to the first node comprises an indication of whether a subscription to a service will be carried by an action call from a first entity of the one or more entities to a second entity, wherein the indication is used to determine the one or more entities for which the configuration is required.24.The method of claim 22, wherein the one or more configuration parameters for the operations related to the mission comprises at least one of: an identifier of an established mission session, a number of configuration profiles, and at least one configuration profile, wherein the at least one configuration profile comprises an operation identifier of the mission, processing logic settings, and action settings.25.The method of any one of claims 22 to 24, wherein the configuration response comprises, for each configuration profile, a set of operation identifier (s) of the mission and corresponding indicator (s) indicating whether the operations related to the mission of the one or more services have been successfully configured.26.The method of any one of claims 22 to 25, wherein the mission is carried out on a data plane (DP) and the one or more services are data plane services.27.The method of any one of claims 22 to 25, wherein the mission is carried out on a control and management (C / M) plane and the one or more services are C / M plane services.28.The method of any one of claims 22 to 27, wherein the first node has knowledge of which of the one or more services and / or actions are required for the mission, and which of the one or more entities will be used when executing the mission.29.The method of claim 24 or 25, wherein the identifier of the established mission session and the operation identifier of the mission are used in each interaction occurring during the execution of operations belonging to the mission session, such that a corresponding configuration profile is associated with each of the identifier of the established mission session and the operation identifier of the mission.30.The method of claim 24 or 25, wherein the processing logic settings specify the relationship between a target mission operation and other mission operations belonging to the same mission session, wherein the target mission operation is identified by the operation identifier of the mission.31.The method according to claim 30, wherein processing logic settings comprise at least one of:a precondition operation setting, indicating other mission operation (s) to be executed before the target mission session operation;a combination operation setting, indicating other mission operation (s) to be executed within the execution of the target mission operation; anda next operation setting, indicating the next mission operation (s) to be executed after the target mission session operation.32.The method of any of claim 24 or 25, wherein the action settings specify how to perform a target mission session operation in the execution of the mission.33.The method of claim 32, wherein the mission is carried on the data plane and the action settings comprise at least one of:an indication of whether the entity that received the configuration request is a customer or a service provider of a corresponding service of the target mission operation;an entity identifier, comprising an identifier of a device or an entity, to identify one or more subscription (s) between the service provider of the corresponding service and the customer;a subscription identifier for identifying subscription parameters of the corresponding service;a processing Quality of Service (QoS) requirement;a connection identifier to identify a one-way connection to be used for forwarding data packets, wherein a destination of the one-way connection is an entity that receives data from the entity that received the configuration request during execution of the target mission operation; and a transmission QoS indicator to identify a predefined or preconfigured QoS rule (QoSI) when forwarding the data packets.34.The method of claim 33, wherein the mission is carried out on the C / M plane and the action settings comprise at least one of:an indication of whether an entity that received the configuration request is a customer or as service provider of a corresponding service of the target mission operation;an entity identifier comprises an identifier of a device or an entity, to identify one or more subscription (s) between the service provider of the corresponding service and the customer;a subscription ID for identifying subscription parameters of the corresponding service; andan identification of a destination entity with which the entity that received the configuration request needs to communicate during the execution of the target mission session operation.35.A method applied at a first node comprising:sending a configuration removal request to remove configurations from one or more entities involved in the execution of one or more missions, wherein the one or more entities have received one or more configuration requests from the first node, wherein the configuration removal request includes information about a plane type, mission session (s) and mission operation (s) involved in carrying out the one or more missions.36.The method of claim 35, wherein the configuration removal request comprises at least one of: whether the plane type is a data plane (DP) or a control and management (C / M) plane; a number of mission session operations, wherein each mission session operation is identified by a set of: IDs of established mission sessions of the one or more missions and operation IDs of the mission operations of the one or more missions.37.The method of any one of claims 35 to 36, wherein, the method of claim 34 is performed, when the one or more missions have been completed or when the one or more missions are outdated.38.An apparatus, configured to perform the method according to any one of claims 1 to 11, the method according to any one of claims 12 to 21, the method according to any one of claims 22 to 34, or the method according to any one of claims 35 to 37.39.An apparatus comprising:one or more processors; andone or more memories storing instructions which, when executed by the one or more processors, cause the apparatus to perform the method according to any one of claims 1 to 11, the method according to any one of claims 12 to 21, the method according to any one of claims 22 to 34, or the method according to any one of claims 35 to 37.40.A computer program product comprising program code for performing the method according to any one of claims 1 to 11, the method according to any one of claims 12 to 21, the method according to any one of claims 22 to 34, or the method according to any one of claims 35 to 37.41.A computer program comprising computer execution instructions which, when executed by a processor, cause the processor to execute the method according to any one of claims 1 to 11, the method according to any one of claims 12 to 21, the method according to any one of claims 22 to 34, or the method according to any one of claims 35 to 37.42.A computer-readable medium storing computer execution instructions which, when executed by a processor, cause the processor to execute the method according to any one of claims 1 to 11, the method according to any one of claims 12 to 21, the method according to any one of claims 22 to 34, or the method according to any one of claims 35 to 37.43.A chip, comprising an input / output (I / O) interface and a processor, wherein the processor is configured to call and run a computer program stored in a memory, to enable a device installing with the chip to perform the method according to any one of claims 1 to 11, the method according to any one of claims 12 to 21, the method according to any one of claims 22 to 34, or the method according to any one of claims 35 to 37.

Images