System and method for orchestrating network digital twin map

Abstract

Systems and methods for orchestrating a network digital twin map are described. A Network Digital Twin Map Orchestration (NDTMO) may receive a request to orchestrate a Digital Twin (DT) map from a Digital Twin Verification Control (DTVC). The NDTMO may determine whether to acquire a DT map model corresponding to the request from a knowledge map system (KGS). The NDTMO may orchestrate a DT map.

Description

Technical Field

[0001] This disclosure generally relates to wireless communications, including but not limited to systems and methods for orchestrating network digital twin maps. Background Technology

[0002] In the traditional telecommunications field, there is no mechanism or system for building network maps. Network maps consist of available components, topology, capabilities, and functions, serving as a flexible virtual representation of the physical network. Summary of the Invention

[0003] The exemplary embodiments disclosed herein are intended to address problems related to one or more issues arising in the prior art and provide additional features that will become apparent when taken in conjunction with the accompanying drawings and the following detailed description. Exemplary systems, methods, apparatuses, and computer program products are disclosed herein according to various embodiments. However, it should be understood that these embodiments are presented by way of example and not as limiting, and that various modifications may be made to the disclosed embodiments by those skilled in the art who read this disclosure, while remaining within the scope of this disclosure.

[0004] At least one aspect relates to a system, method, apparatus, or computer-readable medium. Network digital twin map orchestration (NDTMO) can receive requests from digital twin verification control (DTVC) to orchestrate (e.g., build, create, update, assemble) a digital twin (DT) map. NDTMO can determine whether to obtain the DT map model corresponding to the request from a knowledge graph system (KGS). NDTMO can orchestrate the DT map.

[0005] In some embodiments, orchestrating a DT map includes NDTMO determining the arrangement or rearrangement of at least one component of the DT map using a DT map model or an existing DT map instance. At least one component of the DT map may include at least one of the following: at least one network element of the model, at least one network function of the model, the network topology of the model, the performance of the model, or at least one network element or at least one resource allocation of the DT map.

[0006] In some embodiments, the NDTMO can determine the DT map model to be acquired based on the scenario type indicated by the request. The NDTMO can determine the DT map model to be acquired based on the task type indicated by the request. In some embodiments, the NDTMO can determine the DT map model to be acquired based on the service type indicated by the request. In some embodiments, the NDTMO can determine the DT map model to be acquired based on the intent type indicated by the request. A DT application can send a request to the DTVC. This request can indicate the request type. In some embodiments, the DTVC can determine at least one requirement and request type for the DT map based on the request.

[0007] In some implementations, a request to orchestrate a DT map may include an indication of a scene type. A request to orchestrate a DT map may include an indication of a task type. A request to orchestrate a DT map may include an indication of a service type. A request to orchestrate a DT map may include an indication of an intent type. A request to orchestrate a DT map may include an indication of at least one requirement for the DT map.

[0008] In some embodiments, the NDTMO determines whether to acquire the DT map model, which may include at least one of the following: The NDTMO may determine whether an instance of the DT map exists based on the request type. When no DT map instance exists, the NDTMO may determine to acquire the DT map model from the KGS. When a DT map instance exists, the NDTMO may determine to reuse or update the instance.

[0009] In some embodiments, Digital Twin Management (DTM) obtains network element (NE) models, functional models, and / or topology models from the Key Geographic System (KGS) based on the arrangement or rearrangement of at least one component of the DT map. The DTM builds a DT map instance based on the NE model, functional model, and / or topology model. The DTM allocates at least one resource to the instance. The DTM configures or modifies at least one service parameter of the instance. Digital Twin Management (DTM) can update existing DT map instances based on the arrangement or rearrangement of at least one component of the DT map. The DTM can allocate at least one resource to the instance. The DTM can configure or modify at least one service parameter of the instance.

[0010] In some implementations, DTVC sends a request message to DTM to perform digital twin simulation and / or verification of the instance. DTM can perform digital twin simulation and / or verification of the instance based on at least one requirement. DTM can send reports to DTVC regarding the simulation and / or verification. In some implementations, NDTMO can operate in conjunction with DTVC and / or DTM to iteratively update the instance and / or perform simulations and / or verifications until the requirements of the DT application are met. DTVC can send the final results of the simulation and / or verification to the DT application.

[0011] At least one aspect relates to a system, method, apparatus, or computer-readable medium. In some embodiments, the Digital Twin Authentication Control (DTVC) may send a request to the Network Digital Twin Mapping Organization (NDTMO) to organize a digital twin (DT) map. The NDTMO may determine whether to acquire the DT map model corresponding to the request. The NDTMO may organize the DT map. Attached Figure Description

[0012] Various exemplary embodiments of this solution are described in detail below with reference to the accompanying drawings. The drawings are for illustrative purposes only and depict only exemplary embodiments of the solution to facilitate the reader's understanding. Therefore, the drawings should not be construed as limiting the breadth, scope, or applicability of the solution. It should be noted that these drawings are not necessarily drawn to scale for clarity and ease of explanation.

[0013] Figure 1 An example cellular communication network that can implement the techniques disclosed herein, according to embodiments of the present disclosure, is shown; Figure 2 Block diagrams of example base station and user equipment apparatuses according to some embodiments of the present disclosure are shown; Figure 3 An example DTN architecture / system according to some embodiments of this disclosure is shown; Figure 4 Example enhanced DTN architectures / systems according to some embodiments of this disclosure are shown; Figure 5 Example KGS are shown according to some embodiments of this disclosure; Figure 6 An example process for accessing a DT map according to some embodiments of this disclosure is shown; Figure 7 An example process for creating a DT map based on a scene or task type according to some embodiments of this disclosure is shown; Figure 8 An example process for creating a DT map based on service type according to an embodiment of this disclosure is shown; Figure 9An example process for building a DT map according to an intent (e.g., intent type) is illustrated according to an embodiment of this disclosure; Figure 10 An example of updating a digital twin map instance according to an embodiment of this disclosure is shown; and Figure 11 A flowchart of an example method for creating or updating a DT map according to an embodiment of this disclosure is shown. Detailed Implementation

[0014] 1. Mobile Communication Technology and Environment Figure 1 An example wireless communication network and / or system 100 according to an embodiment of this disclosure is illustrated, in which the techniques disclosed herein can be implemented. In the following discussion, wireless communication network 100 can be any wireless network, such as a cellular network or a narrowband Internet of Things (NB-IoT) network, referred to herein as "network 100". Such an example network 100 includes base station 102 (hereinafter referred to as "BS 102"; also referred to as a wireless communication node) and user equipment device 104 (hereinafter referred to as "UE 104"; also referred to as a wireless communication device), which can communicate with each other via communication link 110 (e.g., a wireless communication channel), and a cluster of cells 126, 130, 132, 134, 136, 138, and 140 covering a geographic area 101. Figure 1 In this context, BS 102 and UE 104 are contained within the corresponding geographical boundaries of cell 126. Each of the other cells 130, 132, 134, 136, 138, and 140 may include at least one base station operating on its allocated bandwidth to provide sufficient radio coverage to its target users.

[0015] For example, BS 102 can operate within the allocated channel transmission bandwidth to provide sufficient coverage to UE 104. BS 102 and UE 104 can communicate via downlink radio frame 118 and uplink radio frame 124, respectively. Each radio frame 118 / 124 can be further divided into subframes 120 / 127, and subframes 120 / 147 may include data symbols 122 / 128. In this disclosure, BS 102 and UE 104 are generally described as non-limiting examples of "communication nodes" that can practice the methods disclosed herein. According to various embodiments of this solution, such communication nodes are capable of wireless and / or wired communication.

[0016] Figure 2A block diagram of an example wireless communication system 200 for transmitting and receiving wireless communication signals (e.g., OFDM / OFDMA signals) according to some embodiments of this solution is shown. System 200 may include components and elements configured to support known or conventional operating characteristics that do not need to be described in detail herein. In one illustrative embodiment, system 200 can be used in wireless communication environments (such as...) Figure 1 In a wireless communication environment 100, communication (e.g., transmission and reception) data symbols are as described above.

[0017] System 200 typically includes a base station 202 (hereinafter referred to as "BS 202") and a user equipment unit 204 (hereinafter referred to as "UE 204"). BS 202 includes a BS (base station) transceiver module 210, a BS antenna 212, a BS processor module 214, a BS memory module 216, and a network communication module 218, each module being coupled and interconnected with each other as needed via a data communication bus 220. UE 204 includes a UE (user equipment) transceiver module 230, a UE antenna 232, a UE memory module 234, and a UE processor module 236, each module being coupled and interconnected with each other as needed via a data communication bus 240. BS 202 communicates with UE 204 via a communication channel 250, which can be any wireless channel or other medium suitable for data transmission as described herein.

[0018] Those skilled in the art will understand that system 200 may also include, in addition to Figure 2 Any number of modules other than those shown herein. Those skilled in the art will understand that the various illustrative blocks, modules, circuits, and processing logic described in connection with the embodiments disclosed herein can be implemented in hardware, computer-readable software, firmware, or any practical combination thereof. To clearly illustrate this interchangeability and compatibility of hardware, firmware, and software, various illustrative components, blocks, modules, circuits, and steps are typically described according to their functionality. Whether this functionality is implemented as hardware, firmware, or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement these functions appropriately for each specific application, but these implementation decisions should not be construed as limiting the scope of this disclosure.

[0019] According to some embodiments, UE transceiver 230 may be referred to herein as "uplink" transceiver 230, which includes a radio frequency (RF) transmitter and an RF receiver, each including circuitry coupled to antenna 232. A duplex switch (not shown) may alternatively couple the uplink transmitter or receiver to the uplink antenna in a time-duplex manner. Similarly, according to some embodiments, BS transceiver 210 may be referred to herein as "downlink" transceiver 210, which includes an RF transmitter and an RF receiver, each including circuitry coupled to antenna 212. A downlink duplex switch may alternatively couple the downlink transmitter or receiver to downlink antenna 212 in a time-duplex manner. The operation of the two transceiver modules 210 and 230 may be time-coordinated such that the uplink receiver circuitry is coupled to the uplink antenna 232 for receiving transmissions via wireless transmission link 250 while the downlink transmitter is coupled to the downlink antenna 212. Conversely, the operation of the two transceivers 210 and 230 can be time-coordinated, such that the downlink receiver is coupled to the downlink antenna 212 for receiving transmissions via the wireless transmission link 250 while the uplink transmitter is coupled to the uplink antenna 232. In some embodiments, there is tight time synchronization with a minimum guard time between changes in duplex direction.

[0020] UE transceiver 230 and base transceiver 210 are configured to communicate via wireless data communication link 250 and cooperate with RF antenna devices 212 / 232 that are appropriately configured to support specific wireless communication protocols and modulation schemes. In some illustrative embodiments, UE transceiver 210 and base transceiver 210 are configured to support industry standards such as Long Term Evolution (LTE) and emerging 5G standards. However, it should be understood that this disclosure is not necessarily limited to the application of specific standards and related protocols. Rather, UE transceiver 230 and base transceiver 210 may be configured to support alternative or additional wireless data communication protocols, including future standards or variations thereof.

[0021] According to various embodiments, BS 202 may be, for example, an evolved Node B (eNB), a serving eNB, a target eNB, a femtocell, or a picocell. In some embodiments, UE 204 may be embodied in various types of user equipment, such as mobile phones, smartphones, personal digital assistants (PDAs), tablets, laptops, wearable computing devices, etc. Processor modules 214 and 236 may be implemented or realized using general-purpose processors, content-addressable memory, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), any suitable programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In this way, the processor may be implemented as a microprocessor, a controller, a microcontroller, a state machine, etc. The processor may also be implemented as a combination of computing devices, such as a combination of a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other such configuration.

[0022] Furthermore, the steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be directly embodied in hardware, firmware, software modules executed by processor modules 214 and 236 respectively, or any actual combination thereof. Memory modules 216 and 234 can be implemented as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. In this regard, memory modules 216 and 234 can be coupled to processor modules 210 and 230 respectively, such that processor modules 210 and 230 can read information from memory module 216 and write information to memory module 234 respectively. Memory modules 216 and 234 can also be integrated into their respective processor modules 210 and 230. In some embodiments, memory modules 216 and 234 may each include a cache memory for storing temporary variables or other intermediate information during the execution of instructions executed by processor modules 210 and 230 respectively. Memory modules 216 and 234 may each include non-volatile memory for storing instructions executed by processor modules 210 and 230, respectively.

[0023] Network communication module 218 typically represents the hardware, software, firmware, processing logic, and / or other components of base station 202 that enable bidirectional communication between base transceiver 210 and other network components and communication nodes configured to communicate with base station 202. For example, network communication module 218 may be configured to support Internet or WiMAX traffic. In a typical deployment, network communication module 218 is unrestricted in providing an 802.3 Ethernet interface, allowing base transceiver 210 to communicate with conventional Ethernet-based computer networks. In this way, network communication module 218 may include a physical interface for connecting to a computer network (e.g., a Mobile Switching Center (MSC)). The terms “configured for,” “configured as,” and variations thereof, used herein with respect to a specified operation or function, refer to devices, components, circuits, structures, machines, signals, etc., that are physically constructed, programmed, formatted, and / or arranged to perform the specified operation or function.

[0024] The Open Systems Interconnection (OSI) model (referred to herein as the "OSI model") is a conceptual and logical layout that defines network communication used by systems (e.g., wireless communication devices, wireless communication nodes) that are open to interconnecting and communicating with other systems. The model is divided into seven sub-components or layers, each representing a set of concepts providing services to the layers above and below it. The OSI model also defines logical networks and efficiently describes computer packet transmission using different layer protocols. The OSI model can also be referred to as the seven-layer OSI model or the seven-layer model. In some embodiments, the first layer may be the physical layer. In some embodiments, the second layer may be the Media Access Control (MAC) layer. In some embodiments, the third layer may be the Radio Link Control (RLC) layer. In some embodiments, the fourth layer may be the Packet Data Convergence Protocol (PDCP) layer. In some embodiments, the fifth layer may be the Radio Resource Control (RRC) layer. In some embodiments, the sixth layer may be the Non-Access Stratum (NAS) or Internet Protocol (IP) layer, and the seventh layer is an additional layer.

[0025] Various exemplary embodiments of this solution are described below with reference to the accompanying drawings to enable those skilled in the art to manufacture and use this solution. As will be apparent to those skilled in the art, various changes or modifications can be made to the examples described herein without departing from the scope of this solution after reading this disclosure. Therefore, this solution is not limited to the exemplary embodiments and applications described and illustrated herein. Furthermore, the specific order or hierarchy of steps in the methods disclosed herein is merely exemplary. Based on design preferences, the specific order or hierarchy of steps in the disclosed methods or processes can be rearranged while remaining within the scope of this solution. Therefore, those skilled in the art will understand that the methods and techniques disclosed herein present various steps or actions in an exemplary order, and unless otherwise expressly stated, this solution is not limited to the specific order or hierarchy presented.

[0026] 2. Systems and methods for compiling network digital twin maps Digital twins (DT) can be part of technologies related to system automation. A digital twin object can be a virtual copy of a real-world system (“physical” system) on which operations can be performed.

[0027] In the telecommunications field, a digital twin network reference architecture and related requirements can be defined for use in physical network simulation. This disclosure provides a solution on how to construct a network digital twin map, which can be formed from various components or models (e.g., topology, capabilities, functions) as a flexible virtual mirror of the physical network.

[0028] When applied to the communications industry and communications systems (e.g., combined with...) Figure 1 and Figure 2 When discussing systems, digital twin-based technologies can be used for data collection, element model creation, etc. Fixed-network digital twin platforms can be designed and used to meet digital twin applications (e.g., for simulation). However, fixed-network digital twin platforms with fixed network elements, topology, and functions cannot be flexibly orchestrated / configured according to the specific requirements (or updated requirements) of an application. Therefore, such fixed-network digital twin platforms may generate unnecessary network resources because they cannot be customized / configured to specific requirements.

[0029] To address the aforementioned issues, this invention provides a system, method, and solution for flexibly orchestrating and / or managing network digital twin maps. These maps can be dynamically and effectively created and / or updated according to specific / changing requirements and can be used in corresponding network digital twin applications.

[0030] Introduction A digital twin network (DTN) can be used for network simulation (e.g., combining...) Figure 1 and Figure 2 A digital twin network is an extended platform for simulating networks such as communication networks / systems. Through real-time data interaction between the physical network and its twin network, digital twin networks can help network designers perform / implement simpler, automated, resilient, and full lifecycle operation and maintenance.

[0031] Figure 3 An example architecture for DTN is shown. Referring to digital twin architectures in the industrial sector and combining them with the characteristics of communication networks, a multi-layered (e.g., three-layer) architecture can be used to design digital twin networks. Layers may include a physical network layer, a network digital twin layer, and / or a network application layer for the digital twin network system.

[0032] The underlying layer of a digital twin network can be the physical network layer. Network elements existing in the physical network can exchange large amounts of network data and / or control information with the network's digital twin entity via, for example, a southbound interface. The physical network can be a telecommunications operator network, a data center network, a campus network, an industrial IoT network, or another type of network. The physical network can be used for a single network domain (e.g., access network, transport network, core network, IP operator network, etc.) or for end-to-end cross-domain networks. Furthermore, the physical network can contain all the infrastructure in the network or specific infrastructure (e.g., wireless spectrum resources, user plane functional elements in the core network, etc.).

[0033] The middle layer of a digital twin network can be a network digital twin layer, which can form the core of a DTN system. This layer may include, but is not limited to, subsystems such as a unified data repository, a unified data model, and digital twin entity management.

[0034] A) Data Processing System: Collects and updates real-time operational data of various network entities through the southbound interface, forming a single source of truth for network twins, providing accurate and / or complete information for various network applications. One or more of the following are the responsibilities of the unified data repository.

[0035] - Data Collection: Completes the extraction, transformation, loading, cleaning, and / or processing of network data. Facilitates efficient distributed storage of large-scale data.

[0036] - Data storage: Based on the diverse characteristics of network data, use one or more database technologies to efficiently store data, including but not limited to user and / or service data, operation and / or status data and / or log data, network environment and / or configuration data, etc.

[0037] - Data Services: Provides a variety of data services for the unified data model subsystem, including but not limited to fast retrieval, concurrency conflict resolution, batch processing services, and unified interfaces.

[0038] - Data management: This can include, but is not limited to, data asset management, data security management, data quality management, metadata management, etc.

[0039] The more complete and accurate the data in the unified data repository, the more complete and accurate the unified data model subsystem can be.

[0040] b) Unified Data Model: For certain application scenarios, the unified data model subsystem can be used to perform data-driven modeling, provide model instances for various network applications, and / or maximize the agility and programmability of network services. To ensure the effectiveness and reliability of change control over the data model before distributing change control to the physical network, appropriate model instances can be used to perform complete simulation and verification of one or more of the following objectives in the virtual twin network: prediction, scheduling, configuration, optimization, etc. The data model can be of types including, but not limited to, basic models and functional models.

[0041] - The basic model of a network digital twin entity can refer to a network element model and / or a network topology model. The basic model can be based on, but is not limited to, the basic configuration of network elements, environmental information, operational status, link topology, and / or other information, and can be used to provide a real-time, accurate description of the physical network. The basic model can be used to help validate and / or simulate control changes and / or optimize solutions to ensure the effectiveness and reliability of change controls before sending them to the physical network.

[0042] - Functional models can refer to various data models, including but not limited to network analysis, simulation, diagnosis, prediction, and assurance. By fully utilizing network data in a unified data repository, functional models can be built for application scenarios. Functional models can be built and / or extended through multiple dimensions, such as, but not limited to: Network type (e.g., a functional model can be a model that serves a single network domain or multiple network domains). Functional types (e.g., functional models can be categorized into models including but not limited to status monitoring, traffic analysis, security drills, fault diagnosis, and quality assurance). Generality (e.g., functional models can be divided into general models, special models, etc.).

[0043] Multiple dimensions can be combined to create data models for a wider range of application scenarios. For example, a traffic balancing optimization model can be created on the core switch of a campus network, and this model instance can be used to provide services for the corresponding network applications.

[0044] The more data model types a DTN has, the stronger its ability to meet network application requests and / or requirements.

[0045] c) Digital twin management can be used to complete the management functions of digital twin networks, record the life cycle of entities, and visualize and / or control various elements of the network digital twin (such as topology management, model management, security management, etc.).

[0046] The top layer can be a digital twin application layer. DT applications can input requirements into the network digital twin layer through the northbound interface and deploy services through modeling instances. After verification, the twin network layer can send control updates to the physical entity network through the southbound interface. Applications can be deployed quickly, at a lower cost, with higher efficiency and less impact on network service operations, and can include, but are not limited to, network operation, network maintenance, network optimization, autonomous driving networks, and network innovation technologies.

[0047] Solutions to identified problems Example Implementation 1: Enhanced DTN Reference Architecture Figure 4 An example of an enhanced DTN system is depicted. The DTN architecture can be enhanced (e.g., by combining...). Figure 3 The discussion aims to enhance / provide new features and capabilities, either integrated into new feature blocks or as enhancements to existing feature blocks. These enhancements can be used to orchestrate and / or manage network digital twin maps and digital twin applications that can run on digital twin map instances. In an enhanced DTN system, one or more additional / enhanced feature blocks, capabilities, and / or functions may include: Digital twin verification control: Digital twin verification control is a device / system used to analyze / parse / interpret the requirements of digital twin applications, including but not limited to the configuration requirements of the created digital map and / or the application requirements on the digital map. Digital twin verification control can be responsible for controlling various digital twin functions (e.g., scenario / type-based operations, business or service type operations, intent simulation, policy verification, fault prediction, web search, etc.).

[0048] Network digital twin map orchestration: Network digital twin map orchestration is a device / system that can be responsible for the orchestration and / or lifecycle management of network digital twin map instances according to scenarios and requirements, including but not limited to creating, modifying, querying and / or deleting network digital twin map instances.

[0049] Digital twin management: Digital twin management is an enhanced device / system responsible for building and / or running differentiated network digital map instances (e.g., creating digital twin instances based on a basic model and / or functional model of the arrangement / or orchestration, allocating resources to each network digital twin map instance, etc.).

[0050] Figure 5 An example knowledge graph system (KGS) is described. A KGS is an appliance / system that may include data processing capabilities, various functional models and / or basic models, and can be enhanced by being responsible for storing / maintaining and / or providing / configuring various network digital twin digital map models, which can be evaluated / assessed and / or used to create digital twin map instances through network digital twin map orchestration and management.

[0051] Example Implementation 2: DT Map Model Integration If a model provider (e.g., an operations and / or business support system (OSS / BSS), a supplier) has already built a network digital twin map model, which may include different models identified as different object types based on scenarios and customer requirements, the model provider can integrate the network digital twin map model into the KGS. The network digital twin map model can be associated with and / or identified by one or more object types (e.g., service types).

[0052] Figure 6 An example process for the DT map access model is shown.

[0053] Step 601. After the model provider (e.g., OSS / BSS) designs / builds / establishes the network digital twin map model according to the specified scenario and customer requirements, the model provider can initiate the network digital twin map model access process.

[0054] Model providers may request that DT map models be integrated into DTM. This request may include DT map model information, which may have unique identifiers indicating certain scenarios and / or requirements.

[0055] If there is an interface between the model provider and KGS, the model provider can directly connect the digital twin map model to KGS.

[0056] Step 602. The DTM can check / test / verify the integrity and consistency of the digital twin map model information, and can request to integrate the digital twin map model information into the KGS.

[0057] Step 603. KGS can receive and / or store digital twin map model information, and can be responsible for the management operations of the digital twin map model, including, for example, querying, updating, and deleting. KGS can send a response to DTM to indicate that the digital twin map model information has been successfully integrated, and DTM can notify the model provider that the digital twin map model information has been successfully integrated.

[0058] Example Implementation 3: Creating a DT Map Based on Scene or Task Type Digital twin applications serving communication service customers can propose digital twin simulation requirements based on specific scenarios or tasks (e.g., antenna optimization for specific base stations, performance improvement of specific network elements, fault prediction, network optimization, and verification of innovative service deployment).

[0059] The Digital Twin Validation Control (DTVC) function may have the ability to analyze requests for digital twin applications based on specific scenarios or tasks (e.g., it may include simulation operation request information), and / or may decompose requests into one or more specific scenarios or task types, such as the network digital twin map to be created, network digital twin map requirements, digital twin application requirements, and / or at least one strategy for digital twin simulation and / or validation. The DTVC function may request the Network Digital Map Management and Orchestration (NDTMO) function to perform orchestration and / or execute one or more lifecycle management operations for the network digital twin map.

[0060] The Network Digital Map Management and Orchestration (NDTMO) function can be a device / system that checks whether an existing digital twin map instance exists corresponding to a specific scenario or task type. If no such existing digital twin map instance exists, NDTMO can obtain a network digital twin map model corresponding to the specific scenario or task type from the KGS and configure the corresponding network digital twin map description profile according to the network digital twin map requirements.

[0061] Digital Twin Management (DTM) can be a system / device that instantiates / creates a network digital twin map instance based on a network digital twin map description profile. After successfully creating the digital twin map instance, the Digital Twin Validation and Control (DTVC) function can request the DTM to perform digital twin application simulation and / or validation operations on the network digital twin map instance according to the digital twin application requirements. It can also iteratively update and / or iterate the digital twin map instance based on the simulation and / or validation results until the simulation and / or validation results meet the digital twin application requirements.

[0062] It should be understood that one or more features in the above / below example implementations are not unique to a particular example implementation, but can be combined in any way (e.g., in any priority and / or order, simultaneously or otherwise).

[0063] like Figure 5 The following is an example of a simulation operation for a scenario- or task-based DT application. Figure 7 An example process for creating a DT map based on a scenario or task type is shown.

[0064] Step 701. A scenario- or task-based digital twin application (DT APP) can simulate / emulate / perform network maintenance and / or operational tasks / scenarios (e.g., network optimization, fault prediction, network fault root cause analysis, location, network visualization, etc.). Examples of specific tasks or scenarios may include, but are not limited to, simulating a 5G base station, resource optimization of network elements, verification of network policies, and innovative industrial deployments.

[0065] The DT App can send requests for digital twin simulation and verification operations to the Digital Twin Validation and Control Function (DTVC), which may include information on digital twin application requirements based on specific scenarios or tasks. The DT App can also include scenario or task description information in the message.

[0066] Step 702. Upon receiving the request, DTVC can parse and / or convert the request into at least one of the following: digital twin application simulation and / or verification requirements, network digital twin map requirements, digital twin simulation and / or verification strategy, and / or a specific scenario / task type. The specific scenario / task type can be obtained from scenario or task description information.

[0067] Step 703. DTVC can initiate the orchestration and management of the network digital twin map at the NDTMO by sending a message to the NDTMO that includes orchestration and management requests. DTVC can carry the network digital twin map requirements and / or the corresponding scenario / task type in the message.

[0068] Step 704. NDTMO can receive orchestration and management requests for network digital twin maps. NDTMO can determine whether an existing digital twin map instance exists associated with the corresponding scenario or task type. If no existing digital twin map instance exists, NDTMO can obtain / acquire the corresponding digital twin map model for the specific scenario / task type from KGS. If KGS does not find a digital twin map model associated with this specific scenario or task type, KGS can return a generic digital twin map model to NDTMO, indicating the reason / cause (e.g., no suitable model is available). NDTMO can generate digital twin map configuration parameters according to the requirements of the network digital twin map.

[0069] Step 705. NDTMO may define a new network digital twin map object description profile based on the obtained digital twin map model and / or one or more digital twin map configuration parameters, wherein network elements, network functions, and / or network topology defined in the digital twin map model may be modified and / or customized according to orchestration requirements / processes.

[0070] The orchestration of a digital twin map may involve rearranging, reorganizing, reprogramming and / or reconfiguring the components of the digital twin map based on the corresponding digital twin model, and may include, but is not limited to, at least one of the required digital twin network elements, network topology, network element and / or digital twin map resource allocation, network functions and / or digital twin map performance.

[0071] The new network digital twin map object description profile may include, but is not limited to, at least one of the following: required digital twin network elements, network topology, resource allocation of network elements and / or digital twin map, network functions and / or performance of digital twin map.

[0072] Step 706. The NDTMO can send a request message to request the DTM to instantiate the network digital twin map. The NDTMO can carry / include / convey the relevant network digital twin map object description profile in the request message.

[0073] Step 707. Based on the received network digital twin map object description profile, DTM can obtain / access / receive the NE model, functional model, and / or topology model from KGS, and / or create a network digital twin map instance. To meet the functional and performance requirements of the digital twin map, DTM can allocate compute / storage / network resources to the instance and configure necessary service parameters on the instance. After successfully creating the network digital twin map instance, DTM can notify NDTMO that the network digital twin map instance has been successfully created.

[0074] Step 708. The NDTMO can notify the DTVC that a network digital twin map instance associated with a specific scenario or task type has been successfully created. The NDTMO can notify the DTVC via a notification message or a response.

[0075] Step 709. The DTVC can request the DTM to perform digital twin simulation and / or verification operations on the created network digital twin map instance. The DTVC can carry / convey / transmit the digital twin simulation and / or verification requirements and operational strategies in the message.

[0076] Step 710. The DTM can perform digital twin simulation and / or verification operations on the created network digital twin map instance according to the digital twin simulation and / or verification requirements and operational strategies. The DTM can report / send the results of the digital twin simulation and / or verification (e.g., cause of failure, network optimization strategies, possible future failures, etc.) to the DTVC.

[0077] Step 711. If the simulation and / or verification operations do not meet the requirements / specifications of the digital twin application, DTVC, NDTMO, and / or DTM can collaborate / interoperate to iteratively update the network digital twin instance and simulation operation strategy, and can perform simulation and verification operations until the results meet the needs / requirements / specifications of the digital twin application.

[0078] DTVC can report / send the final results of digital twin simulation and verification to the DT APP.

[0079] Example Implementation 4: Simulated Operation of a Service-Based DT Application Digital twin applications serving communication service customers may have digital twin simulation requirements based on specific communication services (e.g., video services, voice services, conferencing services, etc.). DTVC may have the ability to analyze simulation operation request information of digital twin applications based on specific communication services, and may decompose / parse / translate / interpret simulation operation request messages into at least one specific service type, but not limited to, a network digital twin map, network digital twin map requirements, and / or digital twin application requirements and policies for digital twin simulation and / or verification. DTVC may request / instruct NDTMO to perform orchestration and / or lifecycle management operations on the network digital twin map.

[0080] NDTMO can check if an existing digital twin map instance exists for a specific service type. If no existing digital twin map instance is available, NDTMO can obtain / access the network digital twin map model corresponding to the specific service type from KGS and configure the corresponding network digital twin map description profile according to the network digital twin map requirements.

[0081] Digital Twin Management (DTM) can instantiate / create a network digital twin map instance based on a network digital twin map description profile. After the DTM creates the digital twin map instance, the Digital Twin Validation Control (DTVC) function can request / instruct / cause the DTM to perform digital twin application simulation and / or validation operations on the network digital twin map instance according to the digital twin application requirements. The DTM can iteratively update and / or iterate the digital twin map instance based on the simulation and / or validation results until the simulation and / or validation results meet the digital twin application requirements.

[0082] like Figure 8 As shown, the example process for creating a DT map based on service type is as follows: Step 301. Digital twin applications based on communication services can include, but are not limited to, innovative service deployment applications, service visualization applications, or service performance assurance applications. Communication services can be specified and can include, but are not limited to, E2E 1Gbps performance assurance for video services, innovative service deployment verification, etc.

[0083] DT Apps can send request messages to the Digital Twin Authentication and Control Function (DTVC) to request digital twin simulation and / or authentication operations based on specific communication services. DT Apps can include a description of the communication service in the request message.

[0084] Step 302. DTVC can parse / convert information on digital twin application simulation and / or verification requirements into network digital twin map requirements, digital twin simulation and / or verification requirements and strategies, and / or specific service types. Specific service types can be obtained from communication service description information.

[0085] Step 303. DTVC may initiate / generate an orchestration and / or management request for the network digital twin map to be sent to NDTMO. DTVC may include the network digital twin map requirements and / or the corresponding service type in the orchestration and / or management request.

[0086] Step 304. The NDTMO can receive orchestration and management requests for the network digital twin map from the DVTC and can determine whether an existing digital twin map instance is associated with the corresponding service type. If no existing digital twin map instance is associated with the corresponding service type, the NDTMO can obtain / acquire / access the corresponding digital twin map model for the specific service type from the KGS. If the KGS cannot find a digital twin map model associated with this specific service type, the KGS can return a generic digital twin map model to the NDTMO, indicating the reason / cause (e.g., no suitable model is available). The NDTMO can generate digital twin map configuration parameters according to the requirements of the network digital twin map.

[0087] Step 305. NDTMO can define / create new network digital twin map object description profiles based on the obtained digital twin map model and digital twin map configuration parameters. Network elements, network functions, and network topology defined in the digital twin map model can be modified and customized according to arrangement requirements.

[0088] The arrangement of a digital twin map can be based on the corresponding digital twin model to rearrange, reorganize, reprogram and / or reconfigure the components of the digital twin map, and may include at least one of the following: the required digital twin network elements, network topology, resource allocation of network elements and digital twin map, or network functions and / or performance.

[0089] The new network digital twin map object description profile may include, but is not limited to: the required digital twin network elements, network topology, resource allocation of network elements and digital twin map, network functions and / or digital twin map performance, etc.

[0090] Step 306. The NDTMO can send a request message to request the DTM to instantiate the network digital twin map. The NDTMO can carry / include / convey the relevant network digital twin map object description profile in the request message.

[0091] Step 307. The DTM can obtain / access / receive the required / appropriate NE model, functional model, and / or topology model from the KGS based on the received network digital twin map object description profile. The DTM can create network digital twin map instances. To meet the functional and performance requirements of the digital twin map, the DTM can allocate computing / storage / network resources to the instance and configure necessary / appropriate service parameters on the network digital twin map instance.

[0092] Step 308. The DTM can notify the NDTMO network that a digital twin map instance has been created.

[0093] Step 309. DTVC can send a message to request DTM to perform digital twin simulation and / or verification operations on the created network digital twin map instance, and can carry / convey the digital twin simulation or verification requirements and operational strategies in the message.

[0094] Step 310. The DTM may perform digital twin simulation or verification operations on the created network digital twin map instance based on digital twin simulation and / or verification requirements and operational policies. The DTM may report the results of the digital twin simulation and / or verification to the DTVC (e.g., service performance guarantee policies, new service deployment policies, etc.).

[0095] Step 311. If the simulation operation does not meet the requirements / specifications of the digital twin application, DTVC, NDTMO, and / or DTM can collaborate / interoperate to iteratively update the network digital twin instance and / or simulation operation strategy. DTVC, NDTMO, and / or DTM can collaborate to perform simulation and / or verification operations until the results meet the requirements / specifications / requirements of the digital twin application.

[0096] Step 312. DTVC can report the final results of digital twin simulation and / or verification to the DT APP.

[0097] Example Implementation 5: Simulated Operation of Intent-Based DT Application Digital twin applications serving communication service customers can express digital twin simulation requirements through intents. The Digital Twin Validation Control (DTVC) function can analyze the simulation operation request information of the digital twin application expressed by the intent. DTVC can decompose the intent into specific intent object types (or intent types), but not limited to, network digital twin maps, network digital twin map requirements, and / or digital twin application requirements and policies for digital twin simulation and / or validation. DTVC can request the Network Digital Map Management and Orchestration (NDTMO) function to perform orchestration and / or lifecycle management operations for the network digital twin map.

[0098] NDTMO can check if an existing digital twin map instance exists corresponding to a specific intent object type. If no such existing digital twin map instance is found, NDTMO can obtain / access the web digital twin map model corresponding to that specific intent object type from the KGS, and configure the corresponding web digital twin map description profile according to the web digital twin map requirements.

[0099] Digital Twin Management (DTM) can instantiate / create a network digital twin map instance based on the network digital twin map description profile. After creating the digital twin map instance, DTVC can request DTM to perform digital twin application simulation and / or verification operations on the network digital twin map instance according to the digital twin application requirements. DTVC can iteratively update the digital twin map instance based on the simulation and / or verification results until the simulation and / or verification results meet the intended expectations of the digital twin application requirements.

[0100] Figure 9 The example simulation operation of the intent-based DT application shown is described below.

[0101] Step 401. The DT APP can send intents to the DTVC. The intents can express the requirements and / or strategies for digital twin simulation and / or verification operations, as well as information about the requirements of the digital twin application.

[0102] Step 402. DTVC can analyze and translate intents. DTVC can resolve intent expectations into at least one of the following: network digital twin map requirements, digital twin simulation and / or verification requirements and strategies, and can extract the intent object type (or intent type) from the intent.

[0103] Step 403. DTVC can initiate / send orchestration and management requests for the network digital twin map to NDTMO. DTVC can include the network digital twin map requirements and the corresponding intent object type in the orchestration and management requests.

[0104] Step 404. The NDTMO can receive orchestration and management requests for network digital twin maps. The NDTMO can determine whether an existing digital twin map instance exists associated with the intent object type. If no existing digital twin map instance exists associated with the intent object type, the NDTMO can obtain / access a digital twin map model for that specific intent object type from the KGS. If the KGS cannot find a model associated with this intent object type, the KGS can return / provide a general / configurable digital twin map model to the NDTMO. The NDTMO can generate digital twin map configuration parameters according to the network digital twin map requirements.

[0105] Step 405. NDTMO can define / generate new network digital twin map object description profiles based on the obtained digital twin map model and configuration parameters. Network elements, functions, and / or topology can be modified according to orchestration requirements.

[0106] Step 406. The NDTMO can send a message to request the DTM to instantiate the network digital twin map. The NDTMO can carry a relevant descriptive profile in the message.

[0107] Step 407. Using the received network digital twin map object description profile, the DTM can obtain / retrieve / receive the required / appropriate NE model, functional model, and / or topology model from the KGS. The DTM can create network digital twin map instances. The DTM can allocate compute / storage / network resources to the network digital twin map instances and configure necessary / appropriate service parameters on the network digital twin map instances.

[0108] Step 408. After creating a network digital twin map instance corresponding to the intent object type, DTM can notify NDTMO that the network digital twin map instance has been created.

[0109] Step 409. DTVC can send a message to request DTM to perform digital twin simulation and / or verification operations on the created network digital twin map instance. DTVC can carry the digital twin simulation and / or verification requirements and operational strategies in the message.

[0110] Step 410. The DTM may perform digital twin simulation and / or verification operations on the created network digital twin map instance according to the digital twin simulation and / or verification requirements and operational strategies. The DTM may report the results of the digital twin simulation and / or verification to the DTVC (e.g., cases 2 and 3).

[0111] Step 411. If the simulation operation does not meet the requirements of the digital twin application, DTVC, NDTMO and / or DTM can collaborate / interoperate to iteratively update the network digital twin instance and / or simulation operation strategy, and can perform simulation and / or verification operations until the results meet the needs / specifications / requirements of the digital twin application.

[0112] Step 412. DTVC can report the final intent report (or final result) of the simulation and / or verification to the DT APP, and can indicate whether the intent expectation has been met.

[0113] Example Implementation 6: Updating a Digital Twin Map Instance Existing digital twin map instances can be updated based on new DT application requirements. When the digital twin verification control function requests digital twin map orchestration and lifecycle management operations from the NDTMO based on new / updated / modified DT application requirements, the NDTMO can check whether a corresponding idle / available network digital twin map instance exists. If an idle / available network digital twin map instance exists, the NDTMO can update the description profile of the existing digital twin map object to meet the new requirements of the digital twin map in the use case. The NDTMO can also request the DTM to initiate an update operation for the existing digital twin map instance.

[0114] The DTM can update existing digital twin map instances based on the updated description profile of the digital twin map objects. After the digital twin map instance is updated, the DTVC can request the DTM to perform simulation and / or verification operations for digital twin applications on the network digital twin map instance, and can iteratively update the instance based on the simulation and / or verification results (e.g., until the final simulation verifies the expected results).

[0115] renew Figure 10 An example description of a digital twin map instance depicted in the image is as follows: Step 501. The DT APP can send a message to the Digital Twin Validation Control Function (DTVC) containing a new request for digital twin simulation and / or validation operations, and may carry information required by the digital twin application in the message.

[0116] Step 502. DTVC can analyze the simulation and / or verification requirements of digital twin applications and can resolve these requirements into at least one of network digital twin map requirements, digital twin simulation and / or verification requirements, and strategies. DTVC can also resolve the simulation and / or verification requirements of digital twin applications into corresponding object types, such as scenario / task types, service types, intent object types, etc.

[0117] Step 503. DTVC can initiate / send an orchestration and / or management request for the network digital twin map to NDTMO, and can carry new network digital twin map requirements and corresponding object types in the orchestration and / or management request.

[0118] Step 504. The NDTMO can check if one of the currently unused (or available / idle) network digital twin map instances is associated with a corresponding object type. If one of the NDTMO's currently unused network digital twin map instances is associated with a corresponding object type, the NDTMO can perform an update operation instead of an instantiation operation to minimize the use of allocated / required resources. The NDTMO can first update the description profile of the existing digital twin map object associated with this object type to make the digital twin map object meet the new requirements of the digital twin map in this use case. The NDTMO can request the DTM to initiate an update operation for the existing digital twin map instance.

[0119] Step 505. NDTMO may send a request to update an existing network digital twin map instance, which includes the map ID of the existing network digital twin map instance and / or an update description profile of the new network digital twin map object.

[0120] Step 506. Based on the updated description profile of the received new network digital twin map object, the DTM can update existing network digital twin map instances (e.g., update NE resources and network topology) to meet the functional and / or performance requirements of the digital twin map. The DTM can allocate compute / storage / network resources to the instance and configure updated service parameters on the updated digital twin map instance. After the network digital twin map instance is successfully updated, the DTM can notify the NDTMO that the network digital twin map instance has been updated.

[0121] Step 507. After the network digital twin map instance is updated, DTM can notify NDTMO that the network digital twin map instance has been updated.

[0122] Step 508. DTVC can send a message to request DTM to perform digital twin simulation and / or verification operations on the updated network digital twin map instance, and can carry digital twin simulation and / or verification requirements and operational strategies in the message.

[0123] Step 509. The DTM may perform digital twin simulation and / or verification operations on the created network digital twin map instance according to the digital twin simulation and / or verification requirements and operational strategies. The DTM may report the results of the digital twin simulation and / or verification to the DTVC (e.g., cases 2 and 3).

[0124] Step 510. If the simulation operation does not meet the requirements / specifications of the digital twin application, DTVC, NDTMO, and / or DTM can collaborate / interoperate to iteratively update the network digital twin instance and simulation operation strategy. DTVC, NDTMO, and / or DTM can perform simulation and / or verification operations until the results meet the requirements / specifications of the digital twin application.

[0125] Step 511. DTVC can report the final results of digital twin simulation and / or verification to DT APP.

[0126] Figure 11 A flowchart 1110 illustrates an example method for creating or updating a DT map according to one or more embodiments of the present disclosure. Method 1100 can be used in conjunction with this document. Figures 1 to 10 This can be implemented using any one or more components and devices described in detail. In some embodiments, method 1100 may be performed by NDTMO, DTVC, and / or DTM. Depending on the embodiment, additional, fewer, or different operations may be performed in method 1100. At least one aspect of the operation relates to a system, method, device, or computer-readable medium.

[0127] Regarding (1105), in some embodiments, the Network Digital Twin Map Orchestration (NDTMO) can receive a request to orchestrate the network digital twin (DT) map from the Digital Twin Authentication Control (DTVC). The DTVC can send the request to orchestrate the DT map to the NDTMO. The DVTC can send / provide / transmit the request to the NDTMO. For example, the request can be based on a first request from a digital twin application (DT APP) to perform a simulation operation on the instance. For example, the DVTC can receive the first request from the DT APP, which can be based on intent, service, scenario, and / or task.

[0128] DTVC can translate / parse / interpret the first request as at least one of the following: the object type of the network digital twin map (e.g., intent / service / scenario / task type), the network digital twin map requirements, and / or the digital twin application requirements and strategies for digital twin simulation and / or verification. DVTC can generate or form a request based on any one or more of the above information. This request can be a request to NDTMO to perform orchestration and / or lifecycle management operations of the network digital twin map. DTVC and / or the request can enable NDTMO to determine whether to acquire the DT map model corresponding to the request.

[0129] Regarding (1110), in some embodiments, the NDTMO can determine whether to acquire / access / retrieve the DT map model corresponding to the request. The NDTMO can determine whether to acquire the DT map model corresponding to the request from the KGS. The NDTMO can check whether an existing digital twin map instance corresponding to the object type exists. If no such existing digital twin map instance is found, the NDTMO can acquire / access the DT map model corresponding to that object type (e.g., a web digital twin map model) from the KGS. The NDTMO can configure / update the web digital twin map description profile according to the web digital twin map requirements. The web digital twin map description profile can indicate / describe / represent the arrangement or rearrangement of at least one component of the web DT map.

[0130] Regarding (1115), in some embodiments, the NDTMO can orchestrate DT maps. The NDTMO can orchestrate / design DT maps by generating or updating network digital map description profiles. The orchestration of DT maps may include the arrangement or rearrangement of at least one component of the DT map determined / designed / developed by the NDTMO using a network digital twin map model from the KGS and / or existing DT map instances. At least one component of the DT map may include at least one of the following: at least one network element of the model, at least one network function of the model, the network topology of the model, the performance of the model, or at least one resource allocation for at least one network element or DT map.

[0131] In some implementations, method 1100 may include Digital Twin Management (DTM), such as instantiating / creating / updating a new or existing network digital twin map instance based on a network digital twin map description profile. The DTM may notify the DTVC upon successful instantiation / updating / creation of the network digital twin map instance. After creating / instantiating / updating the digital twin map instance, the DTVC may request the DTM to perform digital twin application simulation and / or verification operations on the network digital twin map instance, based on digital twin application requirements and / or policies. The DTVC may incrementally, repeatedly, or recursively update / modify the digital twin map instance based on the simulation and / or verification results until the simulation and / or verification results meet the specifications / requests / requirements / intents / needs of the digital twin application requirements.

[0132] While various embodiments of the present solution have been described above, it should be understood that they are merely examples and not limitations. Similarly, various accompanying drawings may depict exemplary architectures or configurations provided to enable those skilled in the art to understand exemplary features and functionality of the present solution. However, those skilled in the art should understand that the solution is not limited to the illustrated exemplary architectures or configurations, but can be implemented using various alternative architectures and configurations. Furthermore, as those skilled in the art will understand, one or more features of one embodiment may be combined with one or more features of another embodiment described herein. Therefore, the breadth and scope of this disclosure should not be limited to any of the exemplary embodiments described above.

[0133] It should also be understood that any reference to elements using names such as "first," "second," etc., in this document generally does not restrict the number or order of these elements. Rather, these names can be used as a convenient means of distinguishing two or more elements or instances of elements in this document. Therefore, mentioning the first and second elements does not imply that only two elements can be used, nor does it imply that the first element must precede the second element in some way.

[0134] Furthermore, those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, and symbols that may be referenced in the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0135] Those skilled in the art will further understand that any of the various illustrative logic blocks, modules, processors, devices, circuits, methods, and functions described in conjunction with the aspects disclosed herein can be implemented by electronic hardware (e.g., digital implementation, analog implementation, or a combination of both), firmware, various forms of program or design code containing instructions (which may be referred to herein as "software" or "software module" for convenience), or any combination of these technologies. To clearly illustrate this interchangeability of hardware, firmware, and software, the various illustrative components, blocks, modules, circuits, and steps have been generally described above according to their functionality. Whether such functionality is implemented as hardware, firmware, or software, or a combination of these technologies, depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art can implement the described functionality in various ways for each specific application, but such implementation decisions will not depart from the scope of this disclosure.

[0136] Furthermore, those skilled in the art will understand that the various illustrative logic blocks, modules, devices, components, and circuits described herein can be implemented within or executed by integrated circuits (ICs), which may include general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, or any combination thereof. Logic blocks, modules, and circuits may also include antennas and / or transceivers for communicating with various components within a network or device. A general-purpose processor may be a microprocessor, but may also be any conventional processor, controller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other suitable configuration performing the functions described herein.

[0137] If implemented in software, these functions can be stored as one or more instructions or code on a computer-readable medium. Therefore, the steps of the methods or algorithms disclosed herein can be implemented as software stored on a computer-readable medium. Computer-readable media include computer storage media and communication media, including any medium capable of transferring computer programs or code from one place to another. Storage media can be any available medium accessible to a computer. By way of example and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disc storage, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of instructions or data structures and is accessible to a computer.

[0138] In this document, the term "module" as used herein refers to software, firmware, hardware, and any combination of these elements used to perform the relevant functions described herein. Furthermore, for the purposes of discussion, various modules are described as discrete modules; however, as will be apparent to those skilled in the art, two or more modules can be combined to form a single module that performs the relevant functions according to embodiments of this solution.

[0139] Furthermore, in embodiments of this solution, memory or other storage devices, as well as communication components, may also be employed. It should be understood that, for clarity, the above description, in illustrating embodiments of this solution, references have been made to different functional units and processors. However, it is apparent that any suitable allocation of functions among different functional units, processing logic elements, or domains can be employed without departing from the essence of this solution. For example, functions described as being performed by independent processing logic elements or controllers may actually be performed by the same processing logic element or controller. Therefore, references to specific functional units herein refer only to suitable means of providing said functions and do not imply a strict logical or physical structure or organizational form.

[0140] Various modifications will readily occur to those skilled in the art regarding the embodiments described in this disclosure, and the general principles defined herein can be applied to other embodiments without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the embodiments shown herein, but should be endowed with the broadest scope of protection consistent with the novel features and principles of this disclosure, as specifically set forth in the following claims.

Claims

1. A method comprising: The Network Digital Twin Map Orchestration (NDTMO) receives requests to orchestrate the digital twin DT map from the Digital Twin Verification Control (DTVC). The NDTMO determines whether to obtain the DT map model corresponding to the request from the Knowledge Graph System (KGS); and The DT map is arranged using the NDTMO.

2. The method according to claim 1, wherein, Arranging the DT map includes: Using the NDTMO, the DT map model or an existing DT map instance, determines the arrangement or rearrangement of at least one component of the DT map. At least one component of the DT map includes at least one of the following: at least one network element of the model, at least one network function of the model, network topology of the model, performance of the model, or at least one resource allocation for the at least one network element or the DT map.

3. The method according to claim 1, comprising: The NDTMO determines the DT map model to be acquired based on at least one of the scene type, task type, service type, or intent type indicated in the request.

4. The method according to claim 1, wherein, Includes at least one of the following: The DT application sends a request indicating the request type to the DTVC; or Based on the request type indicated, the DTVC determines at least one requirement for the DT map and the request type.

5. The method according to claim 1, wherein, The request to orchestrate the DT map includes instructions for at least one of the following: scene type, task type, service type, intent type, or at least one requirement for the DT map.

6. The method according to claim 1, wherein, Determining whether to acquire the DT map model includes at least one of the following: The NDTMO determines whether a DT map instance exists based on the request type of the request. In the absence of the DT map instance, the NDTMO determines to obtain the DT map model from the KGS; or If the DT map instance exists, the NDTMO determines whether to reuse or update the DT map instance.

7. The method according to claim 2, wherein, Digital Twin Management (DTM) performs at least one of the following: Based on the arrangement or rearrangement of at least one component of the DT map, obtain the network element NE model, functional model, and topology model from the KGS; Based on the NE model, functional model, and topology model, a DT map instance is created; Allocate at least one resource to the DT map instance; or Configure or modify at least one service parameter of the DT map instance.

8. The method according to claim 2, wherein, Digital Twin Management (DTM) performs at least one of the following: Update the existing DT map instance based on the arrangement or rearrangement of at least one component of the DT map; Allocate at least one resource to the instance; or Configure or modify at least one service parameter of the instance.

9. The method according to claim 7 or 8, wherein, Includes at least one of the following: The DTVC sends a request message to the DTM to perform digital twin simulation and verification of the instance; The DTM performs digital twin simulation and verification of the instance according to at least one requirement; The DTM sends simulation and verification reports to the DTVC; or The NDTMO operates together with the DTVC and the DTM to iteratively update the instance and perform simulations and verifications until the requirements of the DT application are met.

10. The method according to claim 8, wherein, The DTVC sends the final results of the simulation and verification to the DT application.

11. A method comprising: The Digital Twin Verification Control (DTVC) sends a request to the Network Digital Twin Map Orchestration (NDTMO) to orchestrate the digital twin DT map. The NDTMO determines whether to acquire the DT map model corresponding to the request; and The NDTMO then arranges the DT map.

12. A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 11.

13. An apparatus comprising: At least one processor is configured to perform the method according to any one of claims 1 to 11.

Images