System and method for creating isolated hosting platform for digital entities

Abstract

Embodiments of the present application provide a method, a network node, and a platform for creating an isolated hosting platform (HOP) for a digital entity (DE) of a real entity that needs privacy protection. In some embodiments, a host network (HN) may receive a request to host one or more DEs that require privacy protection of data associated with the DE or the real entity. In response to the request, a HOP is instantiated in a container of the HN. In one embodiment, the HOP is configured with hosting platform functions (HPFs), where at least some of the HPFs control access to the DE data and / or DE applications to protect their privacy.

Description

Systems and methods for creating isolated hosting platforms for digital entities 1. Cross-references to related applications

[0001] This application claims priority to U.S. Patent Application No. 63 / 591,241, filed October 18, 2023. The contents of that priority application are incorporated herein by reference. Technical Field

[0002] This invention relates to the field of data communications, and more particularly to a system, method, and computer-readable medium for providing a hosting platform to independently host digital entities. Background Technology

[0003] The Public Land Mobile Network (PLMN) aims to provide connectivity services to users and other types of entities and their user equipment (UE). The concept of a user-centric network (UCN) improves the user network experience by dynamically adjusting the network structure to adapt to various user contexts.

[0004] As users or other types of entities need or demand greater ownership and control over their services and privacy, future networks are likely to become increasingly "user-centric," meaning they promise to offer more user empowerment. UCNs are designed to give entities greater control over the services offered by the network, or greater control over the networks that provide those services to them.

[0005] Future networks must also be able to support new network infrastructure capabilities suitable for the large-scale deployment of cloud computing applications. Future networks should be able to support the use of large-scale artificial intelligence (AI) models, data anonymization, blockchain technology, and other technologies that have made significant progress in recent years.

[0006] Furthermore, future networks, including enhanced 5G and 6G networks, should be designed to support new applications and services, including AI and data sensing services, which are widely used not only in industrial applications but also by individuals. These applications enable more global and open collaboration between different entities, and future networks should be designed to provide or improve data confidentiality and reliability, standardization, and rapid application deployment.

[0007] As the digital realm gains increasing control over the real world and requires more precise control over real-world systems, digital twins are being created to provide digital representations of real-world entities. These digital twins can represent any type of entity, including objects such as engines, cars, and robots; infrastructure such as cities and factories; and even users themselves. Replicating users in the virtual world presents additional challenges compared to objects or infrastructure, as the confidentiality and integrity of user data are paramount.

[0008] All of these factors are driving research into future network architectures, including, for example, 6G networks. Therefore, improving communication networks is imperative.

[0009] The purpose of providing this background information is to disclose information that the applicant believes may be relevant to the present invention. It is not intended to acknowledge, nor should it be construed, as any of the foregoing information as prior art opposed to the present invention. Summary of the Invention

[0010] This invention provides a hosting platform (HOP) for instantiating and maintaining digital entities. Digital entities can also be referred to as copies or digital twins of real-world entities. Digital entities may include physical components (memory, processor, network interface card, ports, etc.) and software components that enable the digital entity to communicate with other components outside or inside the network hosting the digital entity.

[0011] In this application, a digital entity (also referred to as a DE, D-XX, DE module, or D-XX module) corresponds to a representation of any entity, such as an asset, process, system, digital world, organization, or user. A digital entity can be a virtual representation or copy of a real-world object, person, or process, which can be used to simulate their behavior in order to better understand and predict their operation in real life. Digital entities can be linked to real-world data sources collected from sensors, as well as other information sources from their environment. Digital entities can be updated in real time to reflect the original, real-world version. Digital entities can be interconnected and can communicate with and influence each other, making it possible to replicate an entire system.

[0012] A digital entity that replicates a physical entity or a collection of physical entities can be called a digital representative (D-Rep or D-Rep module). A digital entity that replicates a more complex system (such as an organization or factory) and includes several D-Reps can be called digital infrastructure (D-Inf). A digital entity that replicates users (including, for example, animals and humans) can be called a D-User.

[0013] Advantageously, HOPs can be created within containers on a hosted network and can have different functionalities for creating, storing, maintaining, and / or controlling digital entities, and / or providing services to digital entities. By isolating the HOP and its associated functionalities within the container, the privacy of digital entities, as well as the data associated with them, and ultimately the users who control these digital entities, can be protected. The proposed HOP can efficiently instantiate digital entities upon request and can include the required functionality to securely and privately connect digital entities to external devices via the hosted network.

[0014] Network operators can be offered different options for instantiating and configuring HOPs, including configuring HOPs for a single digital entity (e.g., a single D-Rep platform) or for multiple entities (e.g., as a multi-D-Rep platform). When a digital entity is a replica of a user, an HOP can be used for a single D-User or multiple D-Users, serving as a multi-D-User platform. HOPs can be instantiated and maintained as isolation functional modules within a managed network.

[0015] A hosting network (NH) can act as either a trusted or untrusted environment for digital entities. For untrusted networks, methods are proposed to prevent the hosting network from accessing data or operations related to digital entities (referred to as DE data) and / or applications executed or accessed by the digital entities (referred to as DE applications). Methods are also proposed to prevent the hosting network from obtaining information about external servers accessed by digital entities.

[0016] According to one aspect, a method is provided for creating an isolated hosting platform (HOP) for a digital entity (DE or D-XX) of a real entity. The method may include receiving a request to create an HOP at a hosting network function (HNF) of a host network (HN), the HOP being used to host one or more DEs for DE data and their associated DE applications. In response to the request, the HOP may be created or instantiated in a container within the HN. The HOP may include or may be configured with a hosting platform function (HPF).

[0017] In possible embodiments, DE data may include parameters defining a DE as an entity, and job data associated with operations performed by a DE application executed by one or more DEs. DE applications may include at least one of the following: home networking applications, AI solutions, user health applications, virtual reality (XR) applications, infrastructure management applications, traffic control applications, data filtering, and data processing.

[0018] The real entity represented by DE can include the following: physical processing device, physical user (P-User), P-User access device (UAD), organization, infrastructure, building, one or more network functions, application server, user equipment (UE), UE sensors, and user application.

[0019] In possible embodiments, each DE may include DE functions. HPF and / or DE functions can be accessed by real entities without the knowledge of the HN. DE functions may include DE network functions, including DE management plane functions, DE control plane functions, and DE data plane functions. DE data plane functions may correspond to functions that process received data according to specific processing specifications and forward that data to a specified destination. DE data plane functions may also forward incoming traffic to a given destination based on destination information included in the data packet.

[0020] In possible embodiments, the HPF can protect the privacy of a real entity, for example, by preventing the visibility of: real entity data and / or DE data, processing of real entity data and / or DE data, or execution of specific functions of a real entity from any other entity using the hosted network or from any other external network. The external network may also host external DEs and / or HNFs.

[0021] In possible embodiments, a request may be received from one of the following: a physical user (P-User), a management plane function (DSMF), an HPF, a DE provider, a P-User access device (UAD), or user equipment (UE).

[0022] In some embodiments, the HNF controls one or more DEs' access to the DE's functionality. A DE that can represent a real entity such as a robot, building, or organization is called a digital representative (D-Rep), and a DE that represents a human is called a digital user (D-User).

[0023] In some embodiments, the parameters defining a D-User may include at least one of the following: age, name, gender, address, physical and / or behavioral characteristics, location, preferences, physiological data, user context, environmental context, mobility, and past activities.

[0024] In some embodiments, job data defining the operations performed by one or more DE functions may include one or more of the following: processing input data; modifying input data; forwarding input data or processed data to a specified destination; deleting input data; creating and managing lifecycles (LCMs); and resource allocation for other functions.

[0025] In some embodiments, HOP corresponds to at least one of the following: a single D-User platform, multiple D-User platforms, a network for digital world (NET4DW) platform, and an isolation function module. In some embodiments, the host network (HN) is one of the following: a Wi-Fi network, a radio access network (RAN), a core network (CN), or a data network (DN). In some embodiments, HN may be trusted by an entity associated with the corresponding DE.

[0026] In some embodiments, at least one HNF facilitates access to one or more DEs for anonymous access to external servers by performing an identification management function (IDMF), wherein the IDMF changes the source ID and / or response address associated with one or more DEs.

[0027] In some embodiments, at least one HNF processes DE data within the HOP by performing a data processing function (DPF) within the HOP. In some embodiments, access to the HNF within the HOP is controlled using a gateway (GW) in the HN's control and management (C / M) plane and a GW in the HN's data plane (DP).

[0028] In some embodiments, when the DE processes DE data within the HOP, or when the DE shares DE data with other entities outside the HN, at least one HPF prevents the HN from accessing the DE data.

[0029] In some embodiments, at least one HPF prevents HN from accessing DE data by instantiating a container in a trusted execution environment (TEE), which corresponds to a confidential computing environment (CEE) within HN, and the container is isolated from HN's operating system (OS).

[0030] In some embodiments, at least one HPF prevents HN from tracking external servers visited by a DE by instantiating a HOP into multiple DE-HOPs that include multiple DEs.

[0031] In some embodiments, at least one HPF prevents HN from accessing operations performed by one or more DEs within a HOP by executing all DE functions within a plurality of DE-HOPs, which are assigned to separate slices of HN.

[0032] In some embodiments, HOP is pre-used to create a hosting platform function (HPF) within the TEE and to interact with one or more DEs therein.

[0033] In some embodiments, the container is an isolated container that runs on hardware managed and controlled by HN.

[0034] In some embodiments, the container is protected by a password key, thereby isolating the container from the operating system (OS) that manages the TEE. The password key is required to access the DE in the HOP hosted in the container.

[0035] In some embodiments, the method includes receiving a verification request from a remote device at the container, and the container providing a password key to the remote device based on a unique identifier of the container's content or functionality to verify the container's authenticity.

[0036] In some embodiments, DE is the digital representative (D-User) of the physical user, and the remote device is the user equipment (UE) of the physical user.

[0037] In some embodiments, the user equipment (UE) verifies the authenticity of the container by providing a password key to an external device, which provides at least one of the container, the contents of the container, and the functionality of the container.

[0038] In some embodiments, the integrity of the HOP, the DE hosted within the HOP, and the DE applications executable within the DE are standardized and certified by a remote certifying entity, and can be verified using its certified signature.

[0039] In some embodiments, the HOP creation and configuration function (HPCCF) performs instantiation and configuration of the HOP, and the HPCCF performs one or more of the following: creating an HPF in a container; providing an interface for the HPF; managing the HPF’s storage, processing and communication resources; and performing life cycle management (LCM) of the HPF within the container according to a set of instructions.

[0040] In some embodiments, different types of HOPs are associated with corresponding HOP design packages, which are stored in the HN blueprint description repository (BDR).

[0041] In some embodiments, HPF's LCM directives are provided as part of the HOP design package.

[0042] In some embodiments, the HOP design package includes at least one of the following: a description of the HPF, the interface of the HPF, program instructions, configuration attributes, and a description or design package of the supported DE.

[0043] In some embodiments, HPF includes a HOP manager function (HMF) created within the HOP, which performs life cycle management (LCM) of one or more DEs and manages communication between the DEs and other entities.

[0044] In some embodiments, HMF also performs the downloading, installation, and configuration of one or more DE-accessible DE applications and / or user devices authorized to access one or more DEs.

[0045] In some embodiments, HMF creates one or more DEs in HOP based on a DE design package, which includes at least one of the following: DE creation instructions, DE LCM, DE module operation, resource requirements, and quality of service (QoS) for messaging with the hosting platform function (HPF).

[0046] In some embodiments, the method further includes an HNF and / or HPF identifying the required privacy level for one or more DEs, and an HPF implementing privacy technologies associated with the privacy level.

[0047] In some embodiments, privacy technologies include at least one of the following: changing the identifier of a DE when interacting with an external entity; encrypting DE data leaving the HOP; preventing a given DE from accessing the data and internal functions of another DE without authorization from that DE; facilitating communication between DEs, including using discovery methods, authentication methods, and authorization methods; preventing HNs or HNFs from accessing DE data within the HOP; preventing HNs or HNFs from accessing the HPF without authorization from the HPF responsible for access control; and providing external entities with random locations within the HOP to respond to requests from DEs.

[0048] In some embodiments, HMF is used to instantiate the portal when requested by the HN's control plane function (CPF) or D-Rep service manager function (DSMF).

[0049] In some embodiments, one or more DE requests to HNF include requests for anything as a service (XaaS) functionality.

[0050] In some embodiments, HPCCF instantiation and HOP configuration are accomplished using the hosting platform installer function (HPIF).

[0051] In some embodiments, a request is received from one of a physical user (P-User), a service management function (SMF), an HPF, a DE provider, a P-User access device (UAD), or user equipment (UE).

[0052] In some embodiments, one or more DEs include a D-User, at least one function within the D-User being controlled by a physical user's user equipment (UE), and at least one function within the one or more DEs providing services to the physical user.

[0053] In some embodiments, one of the HPFs includes a HOP function orchestrator (HFO) to instantiate additional HPFs within the HOP.

[0054] In some embodiments, the HMF establishes secure communication with the HNF, including at least one of the following: the Hosting Platform Control and Configuration Platform Function (HPCCF), the DE Creation Function (DXCF), and the DE Service Manager (DSMF).

[0055] In some embodiments, the discovery process performed by HMF includes: determining the message structure and accessing the HN C / M and DP buses using ingress and egress ports.

[0056] In some embodiments, the method further includes determining the type of the HOP to be instantiated based on at least one of the following: the DE type and the associated DE services it will include and have; the DE's requirements for a trusted or untrusted network; and the privacy level required for the untrusted network.

[0057] In some embodiments, instantiating a HOP includes sending a message to the infrastructure service management function (ISMF) specifying at least one of the following: the HOP category, the requirements of the TEE, the requirements of the HOP, the requirements of the DE to be hosted therein, and the design packages of the HOP and the DE.

[0058] In some embodiments, ISMF requests HOP's hosting creation and configuration function (HPCCF) based on the HOP design package.

[0059] According to the method of claim 48, HPCCF verifies the availability of HOP design packages from the blueprint repository management function (BRMF).

[0060] In some embodiments, HPCCF prepares a final HOP design package that matches the HOP requirements.

[0061] In some embodiments, the HOP installation function (HPIF) creates the HOP, instantiates the initial HPF and interfaces required for the HOP.

[0062] On the other hand, a tangible, non-transient memory is provided that records instructions which will be executed by one or more processors to perform a method, as described herein.

[0063] On the other hand, a network node is provided that is part of a host network, the network node comprising: a processor; and tangible non-transient memory as defined above.

[0064] On the other hand, an isolated hosting platform (HOP) is provided for digitally replicating physical entities (DEs), including control and management (C / M) plane functional modules. The C / M includes at least one of the following: a C / M gateway for controlling message inflow and outflow to the C / M plane functional modules; a C / M plane privacy preserving portal (PPP); a HOP manager function (HMF); an HOP internal function orchestrator (HFO); a public C / M network function (NF) for supporting DE module operation; and a data plane (DP) functional module. The DP functional module includes at least one of a public database, PPP, and a hosting platform function (HPF) supporting DE operation.

[0065] On the other hand, a system is provided that enables a host network (HN) to provide a confidential digital environment to a real entity for its applications. The system includes one or more processors and a tangible, non-transitory memory storing one or more processor-executable instructions to satisfy the following: providing a hosting platform (HOP) within a container of the HN, the HOP being created, configured, and managed by the HN; the HOP enabling the real entity to create a digital entity (DE) representing the real entity within the HOP upon receiving a request from the real entity; the DE including at least one DE function and corresponding resources for performing the at least one DE function; and the HN controlling and managing communication between the DE and the physical entity, and between the DE and other entities outside the HN, to ensure the privacy of the communication.

[0066] In some embodiments, a real entity may perform at least one DE function, the execution of which is private and not visible to HN.

[0067] In some embodiments, the container providing the HOP is a trusted execution environment (TEE).

[0068] In some embodiments, a trusted execution environment (TEE) provides remote proof to a physical entity to ensure the integrity of the TEE.

[0069] In some embodiments, the execution of at least one DE function is private and confidential to the physical entity.

[0070] According to another aspect, an apparatus is provided, the apparatus including a processor and a memory storing one or more instructions executable on the processor, which, when executed, enable the apparatus to perform any of the methods described herein.

[0071] According to another aspect, an apparatus is provided that includes functions or units for performing any of the methods described herein.

[0072] According to another aspect, a computer-readable storage medium is provided that includes one or more instructions, which, when executed on a computer, cause the computer to perform any of the methods described herein.

[0073] According to another aspect, a non-transitory computer-readable medium is provided that stores instructions that cause a processor in a device to implement any of the methods described herein.

[0074] According to another aspect, an apparatus is provided for performing any of the methods described herein.

[0075] According to another aspect, a processor is provided for executing instructions to cause a device to perform any of the methods described herein.

[0076] According to another aspect, an integrated circuit is provided for use in any of the methods described herein.

[0077] A function can be referred to as a block of functional code that can be executed by one or more processors within a network architecture, having predefined external interfaces and behaviors for receiving, processing, and sending data packets.

[0078] A hosting network function (HNF) may include the processing equipment control and management functions of a hosting network (HN) to provide services to end users, HOPs, and digital entities, including end user equipment (UE) and / or end user applications.

[0079] In the context of this application, by way of example only, an HNF may include a hosting platform creation, infrastructure or XaaS service management function (ISMF), a configuration function (HPCCP), and a hosting platform installer function (HPIF).

[0080] The hosting platform function (HPF) includes functions provided to or by the HOP, such as creating, controlling, and managing digital entities within the HOP. In the context of this application, and only as an example, the HPF may include a hosting platform management function (HMF) and a privacy preserving portal (PPP). HOP network functions may include network control and management functions as well as data plane network functions.

[0081] In possible embodiments, when a physical entity uses network services provided by HN, the method and system may create an HOP to host a digital entity (DE or D-XX) or a copy of a real-world entity (e.g., a user) that requires privacy protection. The network services may include performing entity-related applications, processing entity data, performing analysis or simulation on the entity, controlling devices, and providing communication between the entity and external devices or functions within the digital entity (DE / D-XX) (e.g., D-Rep and / or D-User).

[0082] In a possible embodiment, the HOP may be configured with at least one hosting platform function (HPF) within the HOP. The HPF may perform one or more of the following: create additional HPFs within the HOP; create digital entities within the HOP; control access to digital entities and / or HPFs; perform lifecycle management (LCM) on digital entities and / or HPFs; manage resources for HPFs and / or digital entity modules; configure HPFs and digital entity modules; facilitate communication with external and internal HOP entities of HPFs and / or digital entity modules; and support digital entity operations and / or one or more digital entities hosted within the HOP.

[0083] A physical entity can request one or more network services from a digital entity (HNF). The HNF can provide the HPF with information about the digital entity's requests, such as privacy requirements and services, provided by the physical entity. The HPF and / or HNF then create the digital entity using the configuration required to provide one or more network services. Creating a digital entity may include establishing a secure communication link between the physical and digital entities to enable either the physical or digital entity to access the network services.

[0084] In a possible implementation, HNF resources can be used to create containers, the internal functions of those containers, and digital entities. In this case, HNF can create and manage HPF.

[0085] In possible embodiments, containers, their internal functions, and one or more digital entities can be created and executed in an enclave or trusted execution environment (TEE) of one or more processors in a node within the NH. The TEE may correspond to a confidential computing environment (CEE) within an operating system, which may be provided by a TEE provider.

[0086] In the context of this application, a design package of HOPs can be provided to the TEE, which defines the internal HOP function (HPF) and the digital entities that may be instantiated within the HOP.

[0087] In one embodiment, the HNF can be granted access to the internal functions of the TEE to perform a limited number of operations using the HPF. These limited operations can be performed by establishing the necessary communication links and configuring the required authentication functions and procedures to enable the digital entity to benefit from network services. Thus, the HNF can request the HPF to create a digital entity and establish secure communication between the digital entity and its associated real or physical entity, allowing the real-world entity to access network services while protecting its privacy. The physical entity can be owned or controlled by the end user; for example, the physical entity can correspond to the device the end user uses to access the hosted network. The physical entity can obtain credentials for the digital entity (e.g., D-Rep) and can remotely authenticate with the TEE provider to ensure that the HN has no right to access D-Rep data or D-Rep applications, or that the HN is unaware of the operations being performed by D-Rep.

[0088] Digital entity data may include parameters that characterize a digital entity as an entity and job data associated with operations performed by a digital entity application performed by one or more digital entities, or defined by said parameters and job data. Digital entity applications may include at least one of the following: home networking applications, AI solutions, user health applications, virtual reality (XR) applications, infrastructure management applications, data filtering, and data processing.

[0089] According to one aspect, a tangible, non-transient memory is provided that records instructions which will be executed or performed by one or more processors to perform methods as defined above.

[0090] On the other hand, a network node for a managed network is provided. This network node includes one or more processors and one or more tangible, non-transitory memories as defined above. A network node can refer to any device or point in a communication network capable of sending, receiving, processing, or forwarding data. A network node can include devices such as computers, or more complex devices such as routers, switches, and servers.

[0091] According to another aspect, an isolated hosting platform (HOP) for digital entities is provided. The HOP may include a control and management (C / M) plane functional module. This C / M plane functional module may include at least one of the following: a C / M gateway for controlling message inflow and outflow to the C / M plane functional module; a C / M plane privacy preserving portal (PPP); a HOP manager function (HMF); an HOP internal function orchestrator (HFO); and a public C / M network function (NF) for supporting the operation of the digital entity module. The HOP module may also include a data plane (DP) functional module, which includes at least one of a public database, a privacy preserving portal (PPP), and a hosting platform function (HPF) for supporting the operation of the digital entity.

[0092] According to another aspect, a system is provided for enabling a network to provide a confidential digital environment to a physical entity for use in applications. The network can be a network provider, such as a mobile network operator (MNO). The physical entity can be any processing device associated with a physical entity, such as a telephone, computer, vehicle, etc. The physical entity can have one or more processors, memory, and communication devices. The system can include one or more processors, and tangible non-transitory memory storing instructions executable by the one or more processors. The system can provide or create a hosting platform (HOP) within a container of the network. The HOP can be created, configured, and managed by the network. In other words, lifecycle management (LCM) of the HOP can be performed by the network. The HOP can be used to enable a physical entity to create a digital entity associated with a real-world entity within the HOP upon receiving a request from the physical entity. The digital entity can include at least one digital entity function or application within the HOP and corresponding resources to perform at least one digital entity function. The network can control and manage communication between the digital entity and the physical entity, as well as communication between the digital entity and other entities outside the network. Physical entities can perform the functions or applications of digital entities, and this execution is private and confidential to the network. The container providing the HOP can be a trusted execution environment (TEE), which may have authentication features.

[0093] Other features, aspects, and advantages of the invention will become more apparent from the following non-limiting description of specific embodiments given by way of example only with reference to the accompanying drawings. While specific features described in the foregoing summary and the following detailed description may be described with respect to particular embodiments or aspects, it should be noted that these specific features may be combined with each other unless expressly stated otherwise herein. Attached Figure Description

[0094] Figure 1 shows a block diagram of a UE, 3GPP network element, and data network interconnected via a VUE interface according to an embodiment of the present invention.

[0095] Figure 2 illustrates a possible architecture for a network in the digital world according to an embodiment of the present invention.

[0096] Figure 3 shows a schematic diagram of a communication system according to a possible embodiment of the present invention.

[0097] Figure 4 shows a schematic diagram of a communication system according to another possible embodiment of the present invention.

[0098] Figure 5 shows a schematic diagram of an electronic device and a base station according to a possible embodiment of the present invention.

[0099] Figure 6 shows a schematic diagram of the modules of an electronic device according to a possible embodiment of the present invention.

[0100] Figure 7 shows a block diagram of a network system according to a possible embodiment of the present invention.

[0101] Figure 8 illustrates the HOP high-level architecture of a possible embodiment of the present invention, including an instantiated D-User module.

[0102] Figure 9 illustrates an exemplary system architecture of an embodiment of the present invention, including a hosting platform (HOP) and HOP creation functionality.

[0103] Figure 10 is a flowchart of the high-level HOP creation process in a possible embodiment.

[0104] Figure 11 is a diagram illustrating the HOP functional architecture including the D-User creation function in a possible embodiment. Detailed Implementation

[0105] 6.1. Disclaimer and Glossary

[0106] In the following description and accompanying drawings, the same reference numerals refer to similar elements of this application. Furthermore, to avoid unduly cluttering the drawings, the drawings may not include all reference numerals for the elements in the drawings. It is also possible to refer to only some elements or components in one drawing. The elements thus referenced can be readily inferred from the other drawings shown. The embodiments, geometries, materials, and / or dimensions shown in the drawings or described in this invention are merely indicative, illustrating possible embodiments as examples, and should not be construed as limiting the scope of this application.

[0107] One or more systems described herein can be implemented in a computer program that executes on a processing device, each processing device including at least one processor, a data storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. The term "processing device" encompasses computers, servers, and / or dedicated electronic devices that receive, process, and / or transmit data. "Processing device" is generally part of a "system" and includes processing means such as microcontrollers and / or microprocessors, CPUs, or implementations on FPGAs, by way of example only. For example, but not limited to, a processing device can be a programmable logic unit, a mainframe computer, a server, a personal computer, a cloud-based program or system, a laptop computer, a personal data assistant, a smartphone, a wearable device, or a tablet device.

[0108] Each program is preferably implemented in a high-level programming or object-oriented programming and / or scripting language to communicate with the computer system. However, if desired, the program may be implemented in assembly language or machine language. In any case, the language may be a compiled or interpreted language. Each such computer program is preferably stored on a storage medium or device readable by a general-purpose or special-purpose programmable computer for configuring and operating the computer when the computer reads the storage medium or device to execute the program described herein. In some embodiments, the system may be embedded in an operating system running on a programmable computer.

[0109] Furthermore, the systems, processes, and methods of the embodiments described can be distributed within a computer program product, which includes a computer-readable medium carrying computer-usable instructions for one or more processors. The computer-usable instructions can also be in various forms, including compiled code and uncompiled code.

[0110] One or more processors are used in conjunction with one or more storage media (also referred to as "memory" or "storage device"). The storage media may store instructions, algorithms, rules, and / or transaction data to be processed. Storage media encompass volatile or non-volatile / persistent memory, such as registers, caches, RAM, flash memory, ROM, floppy disks, optical disks, magnetic tapes, and chips, to name just one example. The type of memory can be selected based on the intended use, such as whether instructions should be retained, or whether data should be temporarily stored, retained, or updated. The steps of the proposed method are implemented as software instructions and algorithms, stored in computer memory, and executed by the processor.

[0111] The terms “a,” “an,” and “one” are defined herein as meaning “at least one,” that is, unless otherwise stated, these terms do not exclude plural items. In this invention, “at least one” means one or more, and “multiple” means two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist. For example, A and / or B can represent cases including “only A,” “both A and B,” and “only B,” where A and B can be singular or plural. The character “ / ” generally indicates that the related objects are in an OR relationship. “At least one of the following” or similar expressions refer to any combination of these items, including any combination of one or more items. For example, “at least one of a, b, or c” can represent a, b, c, “a and b,” “a and c,” “b and c,” or “a, b, and c,” where a, b, and c can be single or multiple forms.

[0112] Terms such as “basically,” “usually,” and “about,” which modify the values, conditions, or characteristics of the exemplary embodiments, should be understood to mean that the values, conditions, or characteristics are defined within acceptable tolerances to ensure that the exemplary embodiments can function properly in their intended applications.

[0113] Unless otherwise stated, the terms “connection” and “coupling” and their derivatives and variations herein refer to any direct or indirect structural or functional connection or coupling between two or more elements. For example, a connection or coupling between elements can be acoustic, mechanical, optical, electrical, thermal, logical, or any combination thereof.

[0114] Expressions such as “matched,” “matching,” and “matched,” including their variations and derivatives, are intended to refer to the state of two or more elements being identical or within some predetermined tolerance range of each other. That is, these terms not only cover matching two elements “completely” or “perfectly”, but also matching two or more elements “substantially” or “subjectively”, and providing a higher or better match among multiple matching possibilities.

[0115] In this invention, the term "based on" is intended to mean "at least partially based on," that is, this expression can mean "based on only" or "partially based on," and therefore should not be interpreted narrowly. More specifically, the term "based on" can also be understood as "depending on," "representing," "indicating," "associated with," or similar expressions.

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

[0117] Although the present invention has referenced illustrative embodiments, it is not intended to be interpreted in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to those skilled in the art upon reference to this specification. Features disclosed herein in the context of any particular embodiment may also be implemented, or alternatively, in other embodiments. For example, method embodiments may be implemented, in addition to or alternatively, in apparatus, system, and / or computer program product embodiments. Furthermore, although embodiments are described primarily in the context of methods and apparatuses, other implementations are contemplated as instructions stored in one or more non-transitory computer-readable media, etc. These media may store programs or instructions for performing any of the various methods consistent with the present invention.

[0118] 6.2. User equipment (UE) and virtual user equipment (VUE)

[0119] In the context of this invention, the term "UE" can refer to a combination of a network access device (NAD) and a user personal device (UPD). Similarly, in the context of this invention, a VUE is a digital entity located in the network, representing both the NAD and the UPD. UCM services can be provided by deploying a VUE through at least one network node in the network. User applications and user data can be considered higher-level components of the UE. These higher-level components can be considered UPDs. The UE can use its applications in the NAD to support UCM services. The functionality of a VUE may vary depending on the type of UCM service it provides. In the context of this invention, the term "VUE type" refers to a VUE with the capability to provide a specific type of UCM service. VUEs can be deployed hierarchically in different segments of the network (e.g., RAN, CN, mobile edge computing (MEC), etc.) to support various UCM services of the UE. A VUE can represent a specific UE and represent certain operations supported by the UE to support applications and services deployed throughout the network. Different types of VUEs may exist, providing different types of UCM services. Not all UEs may require user authorization; therefore, VUEs or UCM services may be provided to the UE as additional functionality. UEs requiring specific UCM services may need to subscribe to specific VUE types or UCM services (a VUE type can be used to provide multiple UCM services). Subscription can be completed by the UE contacting the service desk of the mobile network operator (MNO) or through an application provided in the UE, in which case the UE can send a special request to the network. The network can request the VUE creation function (VUCF) in the network to instantiate a VUE. VUE instantiation may include the instantiation of at least one NF belonging to the VUE and its required interfaces. In one embodiment, VUE instantiation may include the instantiation of a VUE manager (VUE-M), which has the ability to instantiate other NFs and interfaces belonging to the VUE. Multiple VUEs may exist in different parts of the network (e.g., different parts of a 3GPP network) and in the data network (DN). In some embodiments, the VUE creation request may be issued by another existing VUE. In some embodiments, VUE instantiation may include the instantiation of the NF associated with the VUE type and the corresponding interface.

[0120] When creating (generating) a VUE, the VUE Manager (VUE-M), other network functions (i.e., UPF and CPF), and database can be created simultaneously. VUE creation may include the virtualization infrastructure and the activation of VUE-M. VUE-M can use the virtualization infrastructure to instantiate other network functions and interfaces required for the requested VUE type. The infrastructure can be part of a managed network or a hardware platform provided by a third-party vendor, serving as a trusted execution environment. In some embodiments, instantiating a VUE may include instantiating the NF associated with the VUE type and its corresponding interfaces.

[0121] VUE instantiation can include the instantiation of the functions and interfaces required for the requested UCM function in the network, which can be a wireless network. Once the required interfaces are ready, the VUE can interact with the network on behalf of the UE to enable the requested UCM function without the UE directly interacting with functions in the access network, for example, when the UE is a wireless device, there is no need for direct interaction over the air interface.

[0122] 6.3. X-centric network architecture

[0123] Many emerging trends have triggered considerations and designs for 6G or future wireless networks, including: new network infrastructure capabilities, such as widely deployed cloud-based / user-friendly infrastructure; new and relatively mature technologies, such as large-scale AI models, data privacy, and blockchain, which have made significant progress and had a major impact on society and human life; new applications and services, such as AI services, data (sensing) services, and digital world services, which are widely used in industries / businesses and by individual customers; and a more globalized, open, and collaborative operating trend, where more open and collaborative operating models are becoming common practice in many fields. New expectations and more stringent requirements for future networks are also driving a rethinking and development of next-generation wireless networks. These requirements may include: improved privacy and trustworthiness, simplified standardization of data and exchange, and rapid deployment in digital environments.

[0124] The network architecture described in this article can be applied to 6G networks. It is an X-centric architecture, which means that it is object- and user-centric. Therefore, it is a cloud-native service-based architecture (SBA) to support providing services for different types of entities, where any object or entity can be provided as a service.

[0125] Therefore, the proposed network architecture can be used in, for example, 6G networks, and can support new services that can be developed or deployed by third parties. The proposed network architecture can be used to enable communication and exchange with technically capable third parties, and can also be used to enable trust management.

[0126] 6.4. D-User as a digital representative of the user

[0127] In the context of this invention, a virtual user (also referred to as a D-User or D-User module) is a digital representation of a user instantiated and maintained within a network, referred to as a "hosted network." A D-User is a special case of a digital entity (DE or D-XX). Because one or more D-Users can be stored and maintained within a hosted network, D-Users can interact closely with the hosted network and / or other digital entities maintained within it to provide "real" users with greater control over services obtained from the hosted network; that is, D-Users can implement improved user authorization. Network services can be provided by the hosted network as supplementary services and can be referred to as user controlled and managed (UCM) services. In possible embodiments, a D-User module can be a separate code segment or fragment that includes different functions and routines or provides different services according to a predetermined structure.

[0128] Users may be granted different levels of control and management authority, i.e., authorization levels. Authorization level refers to the degree of permissions, autonomy, and control granted to a user. This invention provides different authorization levels, including, for example:

[0129] - User-defined service capability, that is, users can define the services they need;

[0130] - Users can manage / control the behavior or characteristics of the services provided by the managed network;

[0131] - Hosted networks can be designed to provide each user with access to a specific portion of the network (e.g., an exclusive logical slice) and a degree of control over it;

[0132] - The user's context (e.g., the user is in a loop, and the user context is used for dynamic network function / operation modifications) can be taken into account when providing services;

[0133] - One or more user equipment / networks can become part of the network, for example, UE as BS / relay, drone BS / relay, application server;

[0134] - Users become producers / providers of network services, such as AI services, neighborhood information, video services, and BS services provided by user devices or drones;

[0135] D-Users within the network can interact with the managed network to provide or facilitate these services. To this end, D-Users may include control plane functions, user plane functions, data storage, and the necessary internal and external interfaces.

[0136] 6.5. User Equipment, 3GPP Networks and Data Networks

[0137] Figure 1 shows an example of the D-User interface.

[0138] Figure 1 illustrates UE 102 interconnected with each other via VUE interfaces (also called reference points) according to an embodiment of the present invention, and a communication network (e.g., a third-generation partnership program (3GPP)). rd A block diagram of network 104 and data network (DN) 106 from the Generation Partnership Project (3GPP). Network 104 may include VUE 108, VUE-M 109, core network (CN) control plane (CP) 110, core network user plane (UP) 112, and RAN distributed unit (DU) / central unit (CU) 114. In the embodiment of Figure 1, VUE operation may require several control plane and data plane interfaces between UE 102 and the various elements of 3GPP network 104, and between the various elements of network 104 and DN 106. The required interfaces may depend on the UCM service types supported by the VUE. A given interface may only be used for a portion of the UCM services. In addition to the interfaces defined in the 5G standard, VUE deployment and operation may require additional interfaces or additional messaging through existing interfaces. The operation of VUE 108 may require several interfaces. In the context of this invention, an interface may be referred to as a reference point, and vice versa.

[0139] VUE-UE Control Plane Reference Point (A): Interface A shown in Figure 1 is primarily used for control plane message passing from UE to VUE and is transparent to the network. Interface A can be used to synchronize UE data (such as UE context and location) between UE 102 and VUE 108 to provide authentication, authorization, connection-related information between VUE and UE, packet format, and initialization of any new UCM protocol data unit (PDU) sessions. Depending on the UCM service, the synchronization of large data streams may require a logical data plane connection between UE 102 and VUE 108. This data plane connection can be established by the network in response to a request from VUE 108 or UE 102, for example, via the Uu and B2 interfaces. For this purpose, UE 102 can send control plane messages to VUE 108 through the VUE-UE Control Plane Reference Point A interface. NFs (or at least one NF in the network) in the network can be used to interact with the UE to obtain user context.

[0140] VUE-RAN Control Plane Interface (B1): For example, when VUE 108 requires specific radio access network (RAN) technology or functions, interface B1 is used for certain UCM services. VUE 108 can use this reference point to issue such requests. Additionally, this logical link (interface B1) can be used for direct UE function authentication, similar to the access and mobility-management function (AMF).

[0141] VUE-RAN Data Plane Interface (B2): For some UCM applications, interface B2 can be used for directed transmission of UE traffic to and from VUE108, transparent to the managed network (core network or RAN). Reference points N9 and N4 can be used for the same purpose.

[0142] VUE-CN Control Plane Reference Point I: CN CP 110 can have a single entry reference point (interface C) connected to the VUE control plane, which is responsible for establishing connections, authentication, authorization and accounting (AAA), policy update processing, and lifecycle management of network functions at VUE 108.

[0143] VUE CPF–CN UPF Reference Point (D) Interface: Interface D is used by certain types of UCM services. If the network operator has a certain degree of control over certain UPFs, these UCM services enable the VUE CPF to control the CN UPF for routing and data processing purposes. The D reference point interface can also be used to monitor UE traffic-related information (such as resource usage, quality of experience (QoE), routing to different processing functions, and different flows in the UPF or DN). NFs (or at least one NF in the network) can be used to obtain user traffic / data for internal processing.

[0144] VUE-CN Data Plane Reference Point I Interface: Interface E is used for UCM services when VUE 108 needs to perform some data processing or when some data needs to be terminated or started at VUE 108. In this case, user traffic initiated by UE 102 or DN 106 is routed to VUE 108 through this interface. NFs (or at least one NF in the network) can be used to obtain user traffic / data for internal processing.

[0145] VUE-DN Data Plane Reference Point (F) Interface: Interface F is used to send and receive data directly between VUE 108 and DN 106. This interface is only available for certain UCM services.

[0146] There are multiple approaches to defining reference points for interactions between different VUE control plane functions (CPFs) and different CN CPFs. For example, a standard might define multiple reference points for interactions between a specific VUE CPF and a specific CN CPF. Alternatively, a single reference point could be defined for all control plane communications between VUE 108 and each network domain (such as VUE or CN).

[0147] In addition to the reference points already described, several other 5G network reference points (such as reference points in 23.501, 3GPP), such as N1 and N2, may need to be modified to incorporate UCM functionality and support the messaging required for VUE 108 and UCM services.

[0148] N1 Reference Point: Located between UE 102 and the access and mobility management function (AMF). In addition to the functions defined for this reference point in the 3GPP TS 23.501 standard, to support VUE or UCM services, the N1 reference point can also be used to transfer VUE policies and parameters (including VUE service authorization) from the CN (such as the AMF) to UE 102, and to transfer VUE 108 and UCM interaction capabilities to the CN CPF (such as the AMF). Furthermore, the synchronization channel establishment and initial authentication procedures between VUE 108 and UE 102 can be implemented through the N1 reference point. Synchronization channel establishment and authentication can be performed by the AMF based on requests from the session mobility function (SMF).

[0149] N2 Reference Point: Defines the link between the RAN and CN (such as AMF). In addition to the relevant functions defined in 3GPP TS 23.501, the N2 Reference Point, used to support VUE and UCM services, can transfer VUE policies and parameters (including VUE service authorization) from the AMF to the RAN (or next-generation radio access network (NG-RAN)).

[0150] Uu reference point: Located between UE 102 and RAN, it is used to support UCM functions and can provide additional quality of service (QoS) bearers for specific UCM services and synchronization channels.

[0151] 6.6. Trusted Execution Environment (TEE) for Hosted D-Users

[0152] The TEE (Transmission Equipment Area) is a secure area within the main processor that provides code and data integrity for applications running within it. Examples of processors with this capability include the Intel SGX. TM or AMD SEV TM Processor. Within a TEE (Technical Equipment Environment), applications can securely store and process data that may not even be detected by the processing device or the operating system of the UE (User Equipment). For example, some systems (such as Intel SGX) can run by creating a secure storage area called an enclave, within which applications can run. This enclave may be protected by a set of password keys that are unique to the application and the system on which it runs. An enclave can also be considered a virtual machine (VM) because it can run on a separate CPU within a protected portion of an operating system located on a hosted network. When an application is executed on an enclave, it is sealed within the enclave and can run securely within it without worrying about interference from other processes or operating systems.

[0153] Furthermore, the TEE may include a feature called “remote authentication,” which allows a remote party to verify the integrity and security of the enclave, thus providing a way to trust the enclave. Remote authentication works by allowing the remote party to send a request to the enclave, requesting proof of its identity and integrity. Integrity may refer to the accuracy, consistency, and unaltered nature of the data, functionality, and / or application. The enclave then responds by providing a cryptographic signature, which may be based on the enclave’s unique identity and a set of measurements of the enclave’s code and data. The remote party can then verify the signature using a public key provided by the enclave. If the signature is valid, it indicates that the enclave is trustworthy and has not been tampered with, allowing the remote party to trust the enclave and its data. Therefore, the container may be protected by a cryptographic key, thus isolating the container from the operating system (OS) that manages the TEE, requiring the cryptographic key when accessing the DE in the HOP hosted in the container. In a possible embodiment, the container may receive authentication requests from remote devices and provide the cryptographic key to the remote device based on a unique identifier of the container’s content or functionality to prove the container’s authenticity. The remote device may be any processing device outside the HOP or hosting network and may need to access the content of digital entities hosted in the HOP. For example, a remote device could be a user device that may need to access an application executed by a user's digital representative (i.e., D-User).

[0154] In possible embodiments, the proposed methods and systems can create and maintain digital entities such as D-Users or D-Rep within a TEE, making it impossible for even the hosting network to access digital entity data, including user data or code (i.e., applications) used by the digital entities. In possible embodiments, the entire platform hosting digital entities and HOPs can be instantiated within the TEE, isolating the HOPs and digital entities managed within the platform through their hosting network. The TEE can correspond to a Confidential Computing Environment (CEE) within an HN. In possible embodiments, users or clients using HOP functionality or digital entity functionality (such as D-User or D-Rep functionality) may need to verify that the program code (software) within the HOP and the program code (software) representing each digital entity consists of standard or expected code that cannot be accessed or tampered with by HN functionality or any external entity. For this purpose, remote proof of the program code, software, or application executing within the HOP can be provided.

[0155] According to possible implementations, since HN may be installing the HOP and initial functions required to create digital entities (such as D-Rep), users requesting the creation of digital entities and / or interacting with digital entities may need to ensure that the digital entities, HOPs, or hosting networks do not infringe on privacy.

[0156] Therefore, a method can be provided that allows users and / or clients to verify the program code and applications used by the hosting network and / or HOP according to standard processes. According to possible embodiments, users can be provided with means to upload the program code for functionality to a digital entity and / or instantiate these functions within the digital entity. However, users may not be able to develop such program code themselves and may need to obtain it from a vendor. To allow users to verify the legitimacy and credentials of a given function, the program code can be standardized, and standard testing methods can be provided. Testing methods can also be standardized. An independent organization testing the program code may have the authority to verify that the program code is certified or accredited. Therefore, when users need the program code to execute in the digital world provided by the hosting network, they can access the certified program code.

[0157] In other embodiments, the authentication can be performed directly by a user or customer using a testing program that can remotely verify program code running in the HOP and / or digital entity. The program code or software to be executed by the digital entity may have a cryptographic signature, such as a hash of the program code. The user can verify the hash of the program code using the testing program or software.

[0158] One potential issue is that even if a user has already installed a certified version of an application or function within a digital entity (such as D-Rep or D-User), applications or functions created within the digital entity by HOP or the hosting network may be untrustworthy or uncertified. In this case, it may be necessary to test the trustworthiness / authenticity of functions such as the Digital Entity Manager (D-Rep-M) and the HOP function (HPF).

[0159] According to possible embodiments, an authorized TEE vendor can be trusted to use authorized program code to instantiate or create the HOP and the digital entities hosted within it. According to another embodiment, the TEE vendor can be required to install only the authorized version of this program code, allowing a trusted authority (e.g., an accredited third-party organization certified to verify authorized signatures) to obtain and verify the signatures of the container and / or the program code when a user undergoes remote authentication of the program code within the container. The user equipment (UE) can verify the authenticity of the container by providing a password key to a third-party device. In return, the third-party device can provide at least one of the container, its contents, or its functionality to confirm the container's authenticity. The third party can act as an authentication entity, capable of verifying the authenticity of the HOP content. The third-party device can be a server controlled and managed by the authentication entity.

[0160] Therefore, two types of standardized functionality may be required: a first type of authentication functionality for HOP, and a second type of authentication functionality for digital entities, such as D-Rep, which can be verified using standard tests.

[0161] In a possible embodiment, within the context of this application, the TEE may be pre-configured or pre-installed with specific program code that enables the TEE to perform some of the following functions:

[0162] - When a hosting network function (HNF) requests the creation of a digital entity, an authenticated version of the digital entity is automatically created (or manually created) within the TEE based on a pre-provided design package. The creation of the digital entity may include providing a security key and a physical entity address (e.g., MAC or IP address) to establish secure communication between the digital entity (e.g., D-Rep) and the physical entity. The "authenticated version" of the digital entity can be a digital entity design package, corresponding to a standard description stored within the TEE. The design package may correspond to an accredited version certified by a standards organization.

[0163] - Provides functionalities within the HOP, such as the HOP management function (HMF), to control access to internal HOP functions from outside the HOP;

[0164] - When an HNF request is made, a limited number of operations can be performed. These limited number of operations can include creating or deleting digital entities, allocating resources to digital entities, and establishing links with physical entities.

[0165] Once a secure communication link is established between the digital and physical entities, the physical entity can prove that the HOP and the digital entity's program code are trustworthy or certified, meaning they haven't been tampered with or altered by HN or any other entity. To ensure the integrity of the HOP, the physical entity can obtain the current state of the HOP's program code and can verify the HOP's program code with the TEE provider to ensure its authenticity and / or trustworthiness. Remote verification services can be provided by the TEE, including, for example, hashes of the code used by HOP and D-Rep.

[0166] After remote authentication, physical entities can request the required network services, and HOP can facilitate the provision of network service requests when digital entities request them.

[0167] When the Hosting Network (HN) is not a trusted network for physical entities, using a Telecommunication Equipment (TEE) to create a Hosting Entity (HOP) and the digital entities hosted within it can provide a secure area within the Hosting Network. The Hosting Network (HN) or network provider can assure users and associated physical devices that this area is closed and inaccessible to the network provider. When the HN receives a TEE from a TEE provider, it can provide the TEE with an access key, such as a password, to access the TEE. The access key can be transferred to the end user (or UE), providing an anchoring function through which messages can be sent to and from the digital entity. Data and applications within the TEE should not be tampered with by the HN. This privacy protection can be achieved by allowing the HN to perform specific operations, such as controlling code and functions that the TEE provider has inserted into the TEE, which cannot be tampered with.

[0168] 6.7. NET4DW Service Module

[0169] Referring to Figure 2, in a possible embodiment, a digital world network service module is schematically illustrated, which can provide digital world (DW) services and may have the ability to construct, control, and manage objects and entities in the digital or virtual world. The digital world network service module may also be referred to herein as a "NET4DW" service module. The digital world can be defined as the digital practice or implementation of the physical world, including, for example, people, processes, animals, objects (such as robots, cars, lights), and infrastructure (such as roads, organizations, buildings, and factories). For the purposes of this application, the terms digital entity, DE, D-XX, DE module, or D-XX module may be used to refer to any of the above items. The NET4DW service module can provide different services to allow applications to run or execute within the DW. Specifically, the NET4DW service module may include a D-User, which corresponds to a digital representation of a physical user (P-User). Currently, some form of digital representation of a user can be used in certain metaverses or servers, such as Facebook. TM Amazon TM Google TM The required representation can vary depending on the application, ranging from using user data to representing the user in controlling individual items and operations.

[0170] A D-User can include a set of parameters and data corresponding to the characteristics of a real physical person or animal. This includes not only core data such as name, age, and address, but also other characteristics such as real-time location, heart rate, medical condition, preferences, physiological data, user context, environmental context, mobility, and past activities that can be collected from sensors or not. A D-User can also include one or more software applications or modules that can simulate, predict, or replicate the behavior or condition of the real physical person associated with the D-User. Job data defines the operations performed by the functions of one or more D-Rep or D-User functions. Job data can include one or more of the following: processing input data, modifying input data, forwarding input data or processed data to a specified destination, deleting input data, creating other functions and managing the lifecycle of other functions, allocating resources to other functions, and modifying other functions.

[0171] Figure 2 provides an exemplary high-level architecture for the NET4DW service module.

[0172] As shown in Figure 2, NET4DW can include different types of hosting platforms (HOPs) for hosting digital entities, such as D-User platforms, D-Inf platforms, and any other DW platforms, such as virtual reality (XR) platforms. These platforms can host one or more digital entities, which are generally referred to in this invention as DE, DE modules, D-XX, or D-XX modules. A D-Inf platform may contain digital representations (D-Rep or D-Rep modules) of different physical objects (such as buildings, roads, or lights). D-Inf can replicate infrastructure such as cities, as an example only.

[0173] In the diagram, C / M refers to the control and management plane, and DP refers to the data plane. Net4DW C / M functionality is the control and management function of Net4DW, used to manage and coordinate platform interactions required by different DW applications. It may also include a control and management gateway (C / MG / W) function, through which Net4DW C / M functionality interacts with external C / M functions. Similarly, DP functionality refers to data plane functions such as routing and data processing. Each platform has its own C / M and DP functionality, which can be connected to Net4DW functions via G / W functionality. A HOP platform can be a single digital entity platform or multiple digital entity platforms (multiple DE-HOPs). For example, a single D-User HOP can be used to host a single D-User (a copy of the physical user), or multiple D-User platforms can be used to host multiple D-Users, such as a group of friends or a family.

[0174] When creating a NET4DW platform, you may need to instantiate the details of NET4DW functionality in order to correctly create and run the NET4DW platform.

[0175] Furthermore, the digital entities (D-XXs) used in NET4DW and its operation may require privacy protection. Specifically, the DW operation may need to be isolated from the hosting network. Therefore, the hosting platform discussed in this application can also be used to provide DW within the network.

[0176] One technical problem addressed by this application is to create an isolated hosting platform (HOP) for digital entities (D-XX) within a hosting network, which can instantiate entities when needed. It also includes functionality for creating the hosting platform within the hosting network (referred to as Hosting Network Function - HNF) and functionality for creating digital entities (D-XX) (including D-Users) within the hosting platform (referred to as HOP Network Function - HPF).

[0177] This application also provides network operators with different options for creating hosting platforms (HOPs). Platforms can take various forms, such as a single-entity platform like a D-User platform, a multi-entity platform like a multi-D-User platform or a NET4DW platform, or an isolated functional module within a hosted network. A separate creation procedure is listed for each use case, along with a description of the platform's functional architecture, including its main functions and interfaces.

[0178] The hosting network (NH) can be a trusted network or an untrusted network. In the case of an untrusted network, this application can also provide a method to prevent the hosting network from accessing digital entity data when the user needs to process data within the HOP, or when the user shares data with external devices (such as third parties) outside the hosting network.

[0179] Additionally, in untrusted situations, this application can provide a method for creating a hosting platform (HOP) to prevent a hosting network (HN) from accessing information about external servers accessed by digital entities (such as D-Users).

[0180] Furthermore, in untrusted situations, this application describes how to create an HOP to anonymously access external servers (or third-party servers) and prevent the hosting network from accessing this information.

[0181] 6.8. Communication Network System

[0182] Referring to Figure 3, a simplified schematic diagram of a communication network system is provided as an illustrative example rather than a limitation. Communication system 300 includes a radio access network (RAN) 320. RAN 320 can be a next-generation (e.g., sixth-generation, 6G, or later) RAN or a traditional (e.g., 5G, 4G, 3G, or 2G) RAN. In RAN 320, one or more electronic devices (EDs), including, for example, user equipment (UE) 310a, 310b, 310c, 310d, 310e, 310f, 310g, 310h, 310i, and 310j (collectively referred to as 310), can be interconnected or connected to one or more network nodes (370a, 370b, collectively referred to as 370). Core network 330 can be part of the communication system and can depend on or be independent of the radio access technology used in communication system 300. In addition, the communication system 300 includes the public switched telephone network (PSTN) 340, the Internet 350, and other networks 360.

[0183] 6.9. Communication systems with wired and wireless components

[0184] Figure 4 illustrates an exemplary communication system 400. Generally, the communication system 400 enables multiple wireless or wired components to transmit data and other content. The purpose of the communication system 400 may be to provide content such as voice, data, video, and / or text via broadcast, multicast, unicast, etc. The communication system 400 can operate by sharing resources (e.g., carrier spectrum bandwidth) among its constituent components. The communication system 400 may include terrestrial communication systems and / or non-terrestrial communication systems. The communication system 400 can provide a wide range of communication services and applications (e.g., earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, automated delivery and mobility, etc.). The communication system 400 can provide high availability and robustness through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can form a multi-layered heterogeneous network. Compared to traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0185] Terrestrial communication systems and non-terrestrial communication systems can be considered as subsystems of a communication system. In the example shown in Figure 4, communication system 400 includes electronic devices (EDs) 410a, 410b, 410c, and 410d (collectively referred to as ED 410, which may include user equipment (UE)), radio access networks (RANs) 420a and 420b, a non-terrestrial communication network 420c, a core network 430, a public switched telephone network (PSTN) 440, the Internet 450, and other networks 460. RANs 420a and 420b include corresponding base stations (BSs) 470a and 470b, which can be collectively referred to as terrestrial transmit and receive points (T-TRPs) 470a and 470b. The non-terrestrial communication network 420c includes access nodes 472, which can be collectively referred to as non-terrestrial transmit and receive points (NT-TRPs) 472.

[0186] Any ED 410 can also be used to connect, access, or communicate with any T-TRP 470a, 470b, and NT-TRP 472, Internet 450, core network 430, PSTN 440, other network 460, or any combination thereof. In some examples, ED 410a can communicate uplink and / or downlink with T-TRP 470a via terrestrial air interface 490a. In some examples, ED 410a, 410b, 410c, and 410d can also communicate directly with each other via one or more side air interfaces 190b. In some examples, ED 410d can communicate uplink and / or downlink with NT-TRP 472 via non-terrestrial air interface 190c.

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

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

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

[0190] 6.10. Electronic devices (ED) and T-TRP / NT-TRP

[0191] Figure 5 shows another example of the ED 510 and base stations 570a, 570b, and / or 570c. The ED 510 is used to connect people, objects, machines, etc. The ED 510 can be widely used in various scenarios, including cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communications (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), metaverse, digital twins, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, automated delivery, and mobility.

[0192] Each ED 510 represents any end-user equipment suitable for wireless operation and may include (or be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics, smartbook, vehicle, automobile, truck, bus, train, or IoT device, wearable device (such as watch, glasses, head-mounted device, etc.), industrial equipment, or devices within the aforementioned devices (e.g., communication modules, modems, or chips) or devices including the aforementioned devices. Next-generation ED 510 may be referred to using other terms. Base stations 570a and 570b are T-TRPs and will be referred to as T-TRP 570 below. Also as shown in Figure 5, NT-TRPs will be referred to as NT-TRP 572 below. Each ED 110 connected to the T-TRP 570 and / or NT-TRP 572 can be dynamically or semi-statically enabled (i.e., established, activated, or enabled), disabled (i.e., released, deactivated, or disabled), and / or configured in response to one or more of connectivity availability and connectivity necessity.

[0193] ED 510 includes a transmitter 501 and a receiver 503 coupled to one or more antennas 504. Only one antenna 504 is shown in the figure to avoid congestion. One, some, or all of the antennas 504 may also be panels. The transmitter 501 and receiver 503 may, for example, be integrated as a transceiver. The transceiver is used to modulate data or other content for transmission through at least one antenna 504 or a network interface controller (NIC). The transceiver is also used to demodulate data or other content received by at least one antenna 504. Each transceiver includes any structure suitable for generating signals for wireless or wired transmission and / or processing signals received wirelessly or wiredly. Each antenna 504 includes any structure suitable for transmitting and / or receiving wireless or wired signals.

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

[0195] ED 510 may also include one or more input / output devices (not shown) or interfaces (e.g., a wired interface connected to the Internet 350 in Figure 3). The input / output devices or interfaces can interact with the user or other devices in the network. Each input / output device or interface includes any structure suitable for providing or receiving information from the user and / or for network interface communication. Suitable structures include, for example, speakers, microphones, keypads, keyboards, displays, touchscreens, etc.

[0196] ED 510 includes a processor 511 for performing various operations, including operations related to: preparing uplink transmissions to NT-TRP 572 and / or T-TRP 570, processing downlink transmissions received from NT-TRP 572 and / or T-TRP 570, and processing lateral transmissions to and from another ED 510. Processing operations related to preparing transmissions for uplink transmission may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmission may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to an embodiment, receiver 503 may receive downlink transmissions (possibly using receive beamforming), and processor 511 may extract signaling from the downlink transmissions (e.g., by detecting and / or decoding signaling). For example, an example of signaling may be a reference signal transmitted by NT-TRP 572 and / or T-TRP 570. In some embodiments, processor 511 implements transmit beamforming and / or receive beamforming based on beam direction indications received from T-TRP 570, such as beam angle information (BAI). In some embodiments, processor 511 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and obtaining system information. In some embodiments, processor 511 may perform channel estimation (e.g., using reference signals received from NT-TRP 570 and / or T-TRP 570).

[0197] Although not shown, processor 511 may be part of transmitter 501 and / or receiver 503. Memory 508 may be part of processor 511, but is not shown in the figure.

[0198] The processor 511, the processing components of the transmitter 501, and the processing components of the receiver 503 can each be implemented by one or more processors, which may be the same or different, for executing instructions stored in memory (e.g., memory 508). Optionally, some or all of the processing components of the processor 511, the transmitter 501, and the receiver 203 can each be implemented using dedicated circuitry, such as a programmable field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or a hardware accelerator (such as a graphics processing unit (GPU) or an artificial intelligence (AI) accelerator).

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

[0200] In some embodiments, the various parts of T-TRP 570 may be distributed. For example, some modules of T-TRP 570 may be located remotely from the device housing the antenna 256 for T-TRP 570 and may be coupled to the device housing the antenna 556 via a communication link (not shown) sometimes referred to as a fronthaul (e.g., a common public radio interface, CPRI). Therefore, in some embodiments, the term T-TRP 570 may also refer to modules on the network side that perform processing operations such as ED 510 location determination, resource allocation (scheduling), message generation, and encoding / decoding, which are not necessarily part of the device housing the antenna 556 of T-TRP 570. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 570 may actually be multiple T-TRPs that operate together (e.g., using coordinated multicast) to serve ED 510.

[0201] The T-TRP 570 includes at least one transmitter 552 and at least one receiver 554 coupled to one or more antennas 556. Only one antenna 256 is shown in the figure to avoid congestion. One, some, or all of the antennas 256 may also be panels. The transmitter 552 and receiver 554 may be integrated as a transceiver. The T-TRP 570 also includes a processor 560 for performing various operations, including operations related to: preparing to transmit downlink transmissions to ED 510, processing uplink transmissions received from ED 510, preparing to transmit backlink transmissions to NT-TRP 572, and processing transmissions received from NT-TRP 572 via backlink. Processing operations related to preparing to transmit downlink or backlink transmissions may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backlink may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. Processor 511 can also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 560 also generates a beam direction indication, such as a BAI, which scheduler 553 can schedule for transmission. Processor 560 performs other network-side processing operations described herein, such as determining the location of ED 510, determining the location for deploying NT-TRP 572, etc. In some embodiments, processor 560 can generate signaling, such as one or more parameters for configuring ED 510 and / or one or more parameters for NT-TRP 572. Any signaling generated by processor 560 is transmitted by transmitter 552. Note that the term "signaling" as used herein can also be referred to as control signaling. Signaling can be transmitted in a physical layer control channel (such as a physical downlink control channel (PDCCH)), in which case the signaling can be referred to as dynamic signaling. Signaling transmitted in the downlink physical layer control channel is called downlink control information (DCI). Signaling transmitted in the uplink physical layer control channel is called uplink control information (UCI). Signaling transmitted in the sidelink physical layer control channel is called sidelink control information (SCI).Signaling can be included in higher-layer (e.g., above the physical layer) data packets transmitted in physical layer data channels, such as in the physical downlink shared channel (PDSCH). In this case, the signaling can be referred to as higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling can also refer to radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling.

[0202] Scheduler 553 may be coupled to processor 560. Scheduler 553 may be included within T-TRP 170 or may operate separately from it. Scheduler 553 may schedule uplink, downlink, lateral, and / or backhaul transmissions, including issuing scheduling authorizations and / or configuring schedule-free (e.g., "configuration authorization") resources. T-TRP 170 also includes memory 558 for storing information and data. Memory 558 stores instructions and data used, generated, or acquired by T-TRP 170. For example, memory 558 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by processor 560.

[0203] Although not shown, processor 560 may be part of transmitter 552 and / or receiver 554. Furthermore, although not shown, processor 560 may implement scheduler 553. Although not shown, memory 558 may be part of processor 560.

[0204] The processing components of processor 560, scheduler 553, transmitter 252, and receiver 554 can each be implemented using one or more processors, which may be the same or different, to execute instructions stored in memory (e.g., memory 558). Alternatively, some or all of the processing components of processor 560, scheduler 553, transmitter 552, and receiver 554 can be implemented using dedicated circuitry, such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC.

[0205] Although the NT-TRP 572 is shown as an example of a drone only, it can be implemented in any suitable non-terrestrial form, such as satellites and high-altitude platforms including international mobile telecommunications base stations and unmanned aerial vehicles. Furthermore, in some implementations, the NT-TRP 572 may be referred to by other names, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station. The NT-TRP 572 includes a transmitter 572 and a receiver 574 coupled to one or more antennas 580. Only one antenna 580 is shown in the figure to avoid congestion. One, some, or all of the antennas may also be panels. The transmitter 572 and receiver 574 may be integrated as a transceiver. The NT-TRP 572 also includes a processor 576 for performing various operations, including operations related to: preparing downlink transmissions to ED 510, processing uplink transmissions received from ED 510, preparing return transmissions to T-TRP 570, and processing transmissions received from T-TRP 570 via return transmissions. Processing operations related to preparing for downlink or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, processor 276 implements transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 570. In some embodiments, processor 576 may generate signaling, for example, to configure one or more parameters of ED 510. In some embodiments, NT-TRP 572 implements physical layer processing but does not implement higher-level functions such as medium access control (MAC) or radio link control (RLC) layer functions. Since this is only an example, NT-TRP 572 may generally implement higher-level functions in addition to physical layer processing.

[0206] The NT-TRP 572 also includes a memory 578 for storing information and data. Although not shown, a processor 576 may form part of the transmitter 572 and / or the receiver 574. Although not shown, the memory 578 may form part of the processor 576.

[0207] The processing components of processor 576, transmitter 572, and receiver 574 can each be implemented using one or more processors, which may be the same or different, to execute instructions stored in memory (e.g., memory 578). Optionally, some or all of the processing components of processor 576, transmitter 572, and receiver 574 can be implemented using dedicated circuitry, such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC. In some embodiments, NT-TRP 572 can actually be multiple NT-TRPs that operate together, for example, through coordinated multicast transmissions, to serve ED 510.

[0208] The T-TRP 570, NT-TRP 572 and / or ED 510 may include other components, but these components have been omitted for clarity.

[0209] 6.11. Electronic device modules

[0210] One or more steps of the methods provided herein can be performed by corresponding units or modules according to FIG6. FIG6 illustrates units or modules in a device, such as those in ED 610, T-TRP 670, or NT-TRP 672. For example, a signal can be transmitted by a transmitting unit or transmitting module. A signal can be received by a receiving unit or receiving module. A signal can be processed by a processing unit or processing module. Other steps can be performed by an artificial intelligence (AI) module or a machine learning (ML) module. The corresponding units or modules can be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more units or modules can be circuits such as integrated circuits. Examples of integrated circuits include programmable FPGAs, GPUs, or ASICs. For example, one or more units or modules can be logical functions, such as logical functions executed by circuits, by a portion of an integrated circuit, or by software instructions executed by a processor. It should be understood that if these modules are implemented (for example) using software executed by the processor, then the processor may retrieve these modules in whole or in part as needed, retrieve them individually or collectively for processing, retrieve them in one or more instances, and these modules themselves may include instructions for further deployment and instantiation.

[0211] Additional details regarding ED 610, T-TRP 670, and NT-TRP 672 are known to those skilled in the art. Therefore, these details are omitted herein.

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

[0213] In a possible embodiment, the proposed system architecture is defined as supporting XaaS services by using technologies such as network function virtualization and network slicing. The system architecture leverages service-based interactions between services.

[0214] 6.12. Service-based architecture

[0215] In a possible embodiment, network system 700 can be a network system (e.g., a 6G network system) utilizing a service-based architecture and the XaaS concept. The XaaS services in the system are divided into three layers: 710, 712, and 714. A possible embodiment of the system concept structure is shown in Figure 7.

[0216] In possible embodiments, infrastructure layer 710 may include infrastructure supporting, for example, 6G services. This includes wireless network (RAN, CN) infrastructure, cloud / data center infrastructure, satellite networks, storage / database infrastructure, and sensor networks, etc. This infrastructure may be provided by a single provider or by multiple providers.

[0217] Each infrastructure can have its own control and management functions for infrastructure management, represented as C / M functions. Each infrastructure can also be a type of Infrastructure as a Service.

[0218] In a possible embodiment, the control and management (C / M) layer 712 may include system control and management services. These control and management services are developed and deployed using slicing techniques and leveraging resources provided by the infrastructure layer. Services in the control and management (C / M) layer 712 may include:

[0219] - The resource management module includes resource management (RM) as a service, which has the ability to perform lifecycle management of various slices and to allocate over-the-air resources to wireless devices;

[0220] - Task modules are defined as services provided by the system to clients. A task can be a set of services provided by a single XaaS service, or it can be a type of service that requires multiple XaaS services to provide.

[0221] - The task management module includes mission management (MM) as a service function, which has the ability to programmatically provide XaaS services at the service layer to provide task services;

[0222] The CONET module includes a confederation network (CONET) as a service function, which enables multiple partners to collaboratively provide services. This capability is provided through consortium formation, mutual authentication and authorization among partners, and consensus reached through recording and retrospective negotiation of selected operations performed by partners, ensuring a trusted operating environment for the system.

[0223] - The service provisioning management module includes Service Provisioning Management (SPM) as a Service, which has the ability to control and manage customer access to services and provide requested services. This capability is provided through unified mutual authentication, authorization and policies, key management, QoS guarantees, and billing between any pair of XaaS service providers and customers. Customers include not only end customers in the physical world but also digital representatives in the digital world;

[0224] - The connectivity management module includes connectivity management (CM) as a service function, which utilizes the connectivity management capabilities of current or previous systems (such as 5G), but is extended to include the digital world;

[0225] - The Protocol as a Service (PCS) module includes PCS functionality and has the ability to design custom protocol stacks for recognized interfaces. Protocol stacks can be predefined for on-demand selection or designed on demand.

[0226] - The Cybersecurity as a Service module includes Cybersecurity as a Service capabilities, which enable infrastructure owners to detect potential security risks to their infrastructure.

[0227] The XaaS module, comprising XaaS services in the C / M layer, supports the control and management of the system itself and, upon request, provides support to vertical domains. For example, the RM service can provide air resource management for the RAN and also provide services to vertical domains, enabling them to allocate air interface resources to their end users. XaaS in the C / M layer can be deployed using slicing technology.

[0228] Service layer 714 may include services that provide services to clients. System architecture 700 may include the following modules:

[0229] - The AI ​​service module, referred to as NET4AI as a service, provides AI capabilities and supports various AI applications.

[0230] - The analytics module (DAM) includes services for data collection, data cleansing, data analysis, and data delivery. It is referred to as DAM as a service. This service has the ability to manage the lifecycle of statistical data, including data acquisition, deprivation, analysis, and delivery. The data is statistical information from any type of sensor, device, network function, etc.

[0231] The NET4Data module includes services for storing and sharing data, referred to as NET4Data as a Service. This service module has the ability to reliably store and share data, under the control of the data owner and in accordance with the regulations of recognized authorities regarding the control of identified data.

[0232] The NET4DW module includes services that provide access to the digital world, referred to as NET4DW as a Service. The Digital World module (or system) has the ability to build, control, and manage the digital world. The digital world is defined as the digital realization of the physical world.

[0233] - The blockchain module, including the blockchain service, is represented as NET4BC as a service. The connectivity service is represented as NET4Con as a service. This service has the capability to support blockchain services;

[0234] The NET4CON module includes enhanced connectivity services, such as Connectivity as a Network (NET4CON) service. This service has the ability to support message and data exchange between new services.

[0235] All XaaS services at this layer can be developed and deployed using resources provided in the infrastructure and leveraging network function virtualization and slicing technologies. The capabilities of each service can be provided by its control and management (C / M) functions, as well as service-specific data processing functions.

[0236] In addition to supporting XaaS services at service layer 714, system 700 also leverages existing systems (such as 5G systems) to provide vertical services. The difference between XaaS services and other vertical industries is that vertical industries are purely customers who need other XaaS services to support their operation, while each XaaS service provides its capabilities to the customer.

[0237] Any pair of XaaS services in the system can also be each other's customers and providers. For example, an infrastructure owner can provide its resources to XaaS services in Service Layer 714 and C / M Layer 712; RM services may require the capabilities provided by NET4AI, DAM, and NET4DW for resource management of their vertical slices; CONET services and NET4Data services may require the capabilities provided by NET4BC for operation.

[0238] The proposed system's structure and associated modules / platform can have the following functions and advantages:

[0239] - Define basic XaaS services by decoupling comprehensive service types into basic XaaS services. Basic XaaS services have unique capabilities to enable specific types of services, such as NET4AI services, NET4DW services, DAM services, NET4Data services, blockchain services, task management services, etc.

[0240] - Enables multiple partners to operate this system together;

[0241] - Define the system's data plane, which includes the processing capabilities of the XaaS service's data plane. Program the interconnectivity of these capabilities through the task management service to enable support for various customized customer services;

[0242] -Simplify the system architecture by categorizing basic control and management services and merging them into basic XaaS services in the control and management (C / M) layer;

[0243] - Define the system's C / M plane, which includes C / M functionality in XaaS services and may include 5G CP (e.g., AMF), depending on implementation options;

[0244] - Define a basic architecture structure (BAS), which is a unified basic structure with a minimal number of interfaces and is independent of the infrastructure type.

[0245] - The BAS concept simplifies the standardization, development, and deployment of systems, while supporting various infrastructure deployment scenarios;

[0246] - Adapt BAS or a subset thereof to various deployment scenarios by applying it to the infrastructure network, based on its capabilities, capacity and requirements;

[0247] -Utilize the SBI interface concept and apply SBI interaction in both the C / M plane and the data plane;

[0248] -Simplify the SBI interface by introducing a trusted GW in the system's data plane and C / M plane;

[0249] - By introducing the CONET capability, NET4BC capability, and anonymous service provisioning provided by the Trusted Gateway into the C / M plane and data plane of the system, the trustworthiness of the system is improved from the perspective of system operation;

[0250] - Enhance trustworthiness from the perspective of end-customer privacy protection by providing unified mutual authentication, IDM, data cleansing, etc. through SPM service, DAM service and blockchain service;

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

[0252] - By defining multiple architectural options, it supports various development paths from the current system to the future system without having to put in too much effort to introduce the BAS concept;

[0253] - By leveraging the advantages of SBA and its additional features, backward compatibility is supported. Users of older technologies (such as 5G) can access services of older technologies using newer systems (such as 6G);

[0254] - Support future expansion by adding new XaaS services, while minimizing the impact on standardization and deployment caused by the concept of anonymous service delivery implemented by the trusted GW in the C / M plane and data plane.

[0255] 6.13. D-User and User Controlled and Managed (UCM) Services

[0256] Since any information provided from a user access device (UAD) or user application can be considered personal data, the term "user" is used to refer to one or more of a physical user (P-User), user equipment (UE), user access device (UAD), or user application.

[0257] A physical user (P-User) corresponds to a real physical entity that uses network services, and therefore can be a person, animal, or machine such as a robot.

[0258] User equipment (UE) can correspond to the device used by a P-User to interact with the network. A UE can consist of two parts: a user personal device (UPD), which stores all user applications and other information; and a user access device (UAD), which is used to access the network. The UAD can be a common device that can be used by multiple users. Various sensors connected to the device can be considered part of the UPD because they carry user information. Therefore, a UE can also correspond to a user access device (UAD), user applications, and sensors.

[0259] The term "digital user" (D-User) refers to the digital representation of a user and can be described as a digital representation of one or more of the following:

[0260] ● Real or physical users (P-Users), such as humans, animals, or robots.

[0261] ●P-User access device (UAD)

[0262] ●User equipment (UE)

[0263] ●UE sensor,

[0264] ● User applications.

[0265] The term "D-Rep" refers to a digital representation, corresponding to a type of digital entity (D-XX). A D-Rep is a digital representation of any real physical object or set of objects. A D-Rep can correspond to a copy or digital representation of a physical device, including vehicles such as cars and robots, and can connect to networks and sensors. Other types of digital entities include digital infrastructure (D-Inf) or digital network (D-Net). D-User is another type of digital entity. A D-User can be a digital representation of a real or physical user (P-User), a P-User access device (UAD), user equipment (UE), UE sensors, physical devices, and user applications.

[0266] A hosting platform (HOP) can be placed within any type of network (hosted network) (such as a WiFi network, mobile network (RAN or CN), or any data network (DN), including 6G networks) to instantiate, store, maintain, and control any type of digital entity (DE / D-XX), such as a D-User or D-Rep. When a network provides resources for creating and maintaining HOPs, it can be called a hosting network (HN).

[0267] The following description in this document is a specific example of a service provided by a digital entity, using the perspective of a service provided by a digital user. Therefore, the methods and procedures described in this document can be similarly applied to any digital entity that can be understood by someone skilled in the art.

[0268] For example, similar to the user control and management services provided through D-User, there exist digital entity customer control and management services that utilize digital entities.

[0269] In possible embodiments, the network-based D-User (i.e., the D-User hosted in the HOP) can represent the user and provide D-User services that can be referred to as user-controlled and managed (UCM) services. For example, these D-User services may include: analyzing and processing user data; providing a computing platform to run user applications; providing AI services to the user; user family control; financial and health control; handling data sharing with third parties; processing user data; representing the user; obtaining content from third-party content providers; interacting with the network to obtain better communication services; interacting with the network to obtain network data; facilitating interaction with third-party servers, such as user access to application servers; making and receiving payments, etc.

[0270] Some of these operations are highly private to entities such as users, therefore, the hosting network may be restricted or prevented from exposing D-User data and operations. If the hosting network is a trusted network, then such protection may not be necessary. However, trustworthiness may depend on the type of service or operation being performed by the D-User. The services provided by the D-User (i.e., UCM services) can be categorized into three types:

[0271] ●D-User represents a physical user performing in-network processing, such as processing data, computing tasks (like running their own applications, analytics, and AI), and controlling user devices and health.

[0272] ●D-Users facilitate interactions with third-party entities (e.g., by providing privacy, sharing data, obtaining content from content providers, conducting financial transactions, and establishing agreements and negotiations).

[0273] ● D-Users interact with the hosting network to enhance services obtained from the hosting network or third parties (improving the QoS of communication services, obtaining network data and status, such as load, topology, etc.).

[0274] Hosting network operators (HNOs), such as mobile network operators (MNOs), can determine the type of D-User to be created in the D-User platform in the digital world based on the services they provide to users according to network needs.

[0275] 6.14. Hosting platform (HOP) as an isolation container

[0276] In possible embodiments, a method may be provided for creating an isolated hosting platform (HOP) for digital entities (DEs or D-XXs) representing real entities requiring privacy protection. In some embodiments, the real entity represented by the DE may include a physical entity existing in the real (i.e., non-digital) world. In other embodiments, the real entity may include programs, applications, or functions separate from the HOP. Some examples of real entities include physical processing devices, physical users (P-Users), user access devices (UADs), organizations, infrastructure, buildings, one or more network functions, application servers, user equipment (UEs), UE sensors, and user applications. A platform may refer to a set of software and / or hardware components that provide a foundation on which other applications and services can be built. In the context of this invention, a hosting platform may include hardware components, such as servers including memory and processors, and software functions, such as data plane and control / management plane functions, that facilitate the deployment, maintenance, communication, and management of the digital entity. HOPs can host different types of digital entities (D-XX), such as digital representatives of users (D-User), digital representatives of objects (D-Rep), digital representatives of infrastructure (D-Inf), or any type of entity, including software applications or business processes. In a possible embodiment, an HOP can be provided as an isolated container within a hosting network. An isolated container can encapsulate different functionalities (including libraries, system tools, runtime, and settings) that the platform may need to run into a single package. Different HOPs hosted by the hosting network can therefore be isolated from each other and from the underlying hosting network. The network that provides the resources for the hosting platform to create and maintain digital entities can be called a “hosting network.” Requests, such as messages or commands, can be sent from processing devices to the hosting network (such as a 5G or 6G mobile network) to request the creation of an HOP. For example, the request might come from a city that wants to replicate all its infrastructure in an isolated platform, a factory that wants to replicate its production line, or a utility company that wants to replicate its power distribution network. The hosting platform can provide the necessary resources, including memory space and processors, as well as the functionality to create, manage, and maintain digital entities and control access to the data and applications used by these digital entities. Hosting platforms can ensure the confidentiality of operations and data accessed or generated by digital entities.

[0277] When a digital entity is a user (D-User), it can represent one or more user devices, user applications, or physical users. Within a network, a D-User can be used for many user-controlled and managed (UCM) services, including in-network data storage, in-network processing (e.g., running applications or specific network functions for evaluation, computation, data analysis, and AI schemes), interacting with the managed network to improve communication services provided to users, monitoring, controlling, and managing user devices, and providing privacy protection for interactions with external application servers (e.g., data sharing, protocol negotiation, financial transactions, content downloading, search engines, website access).

[0278] In some embodiments, the isolated container may be a software container in a hosted network, using hosted network hardware controlled, managed, and coordinated by the hosting network operator (HNO).

[0279] In some embodiments, isolated containers can be created via enclaves within a Confidential Computing Environment (CEE), such as a TEE isolated from the hosting network. The enclave can create HOPs and perform lifecycle management (LCM) on the functions within the HOP according to provided instructions. These instructions can be provided to the container manager as design packages for the HOP, where the design packages can contain descriptions of functions, their interfaces and configuration attributes, descriptions of supported digital entities (including design packages for creating digital entities, detailed steps for creating, LCM, and operating digital entities), resource requirements, and QoS requirements for messaging between HOP functions.

[0280] In some embodiments, the method may include different levels of privacy required to identify digital entities (including, for example, the D-user module), and related technical solutions to provide these levels of privacy protection.

[0281] In some embodiments, a HOP creation program may be provided.

[0282] In some embodiments, the network-based digital entity system architecture and HOP functional architecture may include various functions and interfaces required for the HOP creation process.

[0283] In some embodiments, isolating a HOP may have the following capabilities:

[0284] - Create your own functionalities (HPF), prepare interfaces based on the pre-prepared design package provided to HOP, and perform LCM for these functionalities.

[0285] - Download, install, and configure computer programs, AI solutions, and machine learning programs for use by entities.

[0286] - Manage and control network functions, and allocate resources for various functions.

[0287] In some embodiments, a method for protecting privacy may be provided, which includes one or more of the following:

[0288] - Change the ID of the entity (such as a user or asset) when interacting with external entities;

[0289] - Encrypt the digital entity data removed from the HOP;

[0290] - Maintaining HOP functionality isolated from the managed network by creating HOPs within a confidential computing environment or TEE, wherein the isolation includes:

[0291] -Prevent the managed network from accessing data within the HOP;

[0292] -Prevent the hosted network from accessing HOP functionality without authorization from the digital entity;

[0293] - Prevent the hosted network from recognizing external entities that digital entities are interacting with by changing the identifier (ID) of the digital entity (ID) linked to the output packet within the HOP and providing the external entity with a random location within the HOP to provide a response.

[0294] In a possible embodiment, the creation of a hosting platform (HOP) may involve receiving requests to create or host one or more digital entities (e.g., D-Users or D-Rep) within a hosting network (e.g., a mobile network). Requests from physical entities (e.g., user devices or equipment, robots, etc.) may also be received on the network. These requests may be handled by specific servers and services on the network, as defined in more detail in the following sections, “HOP Creation Phase,” “HOP Creation Procedure,” and with reference to Figures 10 and 11.

[0295] HOP instantiation can occur within containers on the network. Containers, often provided as "Kubernetes," utilize lightweight operating system (OS) virtualization technology, allowing containerized applications and dependent components to run in resource-isolated processes. These applications and components can be packaged into images for reuse, ensuring consistent operation of containerized applications. Containers can consist of executable units of software, where application code is packaged along with libraries and dependencies. Instantiation can involve creating real instances or specific implementations of templates or "design packages," such as the D-Rep class. Instantiating a HOP or digital entity means creating an instance of it by allocating resources (storage and / or processing power) and providing a name or label to represent it.

[0296] An HOP can be instantiated as a container with at least one hosting platform function (HPF), where a function or subroutine can include a sequence of program instructions that perform a specific task, packaged into a single unit. The HOP can then use this unit wherever that specific task can be performed, including, for example, the creation, maintenance, control, and termination of digital entities. An HOP typically includes multiple HPFs, including, for example, HOP management functions, control / management functions, orchestration functions, privacy portals, etc. Examples of HPFs are provided and explained, for instance, in the section titled "Functions within an HOP for HOP Operations and a Summary of HOP Functions Created and Set Up via the HOP Platform."

[0297] Access to data associated with one or more digital entities instantiated in HOP (referred to as DE data) can include data that defines and characterizes the digital entity. For example, if the DE is a D-User, then DE data can include: name, age, address, or data collected from sensors such as heart rate, blood pressure, temperature, or location. A digital entity can be a digital copy of a real user (such as a human or animal) or a digital copy of other physical entities (such as robots, cars, and telephones). DE data can also include data related to the services or functions used by the DE, including, for example, access to a specific server, content downloads, AI modules used, products ordered or purchased, etc.

[0298] In a possible implementation, HOP can create digital entities (DEs or D-XXs) based on requests received from real / physical entities (e.g., people, user devices, robots, etc.).

[0299] In a possible embodiment, the DE may have at least one function that can be controlled by a real entity.

[0300] In a possible embodiment, the architecture of the hosting platform can be configured such that the hosting network (HN) can only access the functions in the digital entity when authorized by the hosting platform function (HPF).

[0301] In a possible embodiment, the privacy of the services provided by HOP to digital entities is protected.

[0302] In a possible embodiment, the HOP may have at least one function (HPF) that can control access to digital entities.

[0303] In a possible embodiment, digital entities hosted in the HOP can use their DE functions to provide specific services to physical entities such as humans, animals, user devices, or robots.

[0304] In a possible implementation, when the HN is not a trusted network, the HOP can be created within a confidential computing environment (CCE). The HN can perform installation and transfer access keys to objects (such as robots or user devices), establishing secure communication between the objects and digital entities. The digital entities can prove the trustworthiness of the HOP to ensure that, after secure communication is established, the original trusted functionality remains within the HOP, and the HN has no access to the digital entities.

[0305] 6.15. Create a HOP to install digital entities within the HOP:

[0306] In the above description, HOPs are used to create digital entities. The following embodiments provide a method for creating HOPs capable of creating generic NET4DW service modules (D-XXs). A digital entity (DE) (also called a D-XX or D-XX module) can be a D-User, D-Rep, D-Inf, or any other DW application, such as a virtual reality (VR), augmented reality (AR), or mixed reality (MR) application. Because the NET4DW platform has D-Users, D-Rep, and other D-XX modules, privacy protection methods for DEs can be provided.

[0307] A method can be provided for network operators of communication networks (e.g., mobile networks, fixed wireless networks, or data networks) to create in-network digital entities (D-XXs) of real entities (e.g., people, vehicles, organizations, including digital representations), wherein the digital entities have the ability to interact with service providers and obtain customer service on behalf of the real entities, while protecting the privacy of the real entities. The method may include establishing a hosting platform (HOP) for the digital entities within the hosted network. The HOP may include one or more HOP functions that can be controlled by the customer (or end user).

[0308] Customers can be end users of mobile networks.

[0309] The service provider can be a network operator, and customer service can be the communication service provided by the network operator.

[0310] The service provider can be a network operator, and the customer service provided by the network may include one or more of the following:

[0311] - Data processing, evaluation, or analysis services, such as AI or ML services.

[0312] -Customer equipment monitoring or control services

[0313] Customer service can be provided via D-Rep within the network.

[0314] The service provider can be a third-party operator with application servers, and customer service can be one or more of the following:

[0315] - Data processing, evaluation, or analysis services, such as AI or ML services.

[0316] -Customer equipment monitoring or control services

[0317] Customer service can be provided via D-Rep within the network.

[0318] Customers can be third-party organizations (e.g., vertical industries, OTT, application servers), customer service can be services obtained by the organization's end users from third parties, D-Rep can be a digital representation of the organization, and D-Rep can assist in providing the required network-based services to support end users in obtaining services from the organization.

[0319] Customers can be DW operators, customer service can be DW services provided to users and devices using DW applications, and D-Rep can be D-XX modules that keep various digital representatives and application functions running DW services.

[0320] The details of these embodiments are as follows.

[0321] 6.16. Privacy of UCM Services

[0322] User privacy is likely an important factor for users because they currently have to share their personal data with many organizations, including over-the-top (OTT) solutions such as Google. TM Amazon TM ,Youtube TM And other service providers, such as shops, equipment providers, etc., in order to obtain various services from these organizations.

[0323] Therefore, considering these privacy concerns, possible implementations could provide a method for creating digital entities such as D-Users and obtaining cost-effective and improved services from a hosting network. When creating a D-User within the network, many factors may need to be considered to provide the user with control and management (UCM) capabilities over the services the D-User obtains from the hosting network.

[0324] Because D-Users can act on behalf of users, the operations performed by D-Users (e.g., analyzing and processing user data, providing computing platforms, offering AI services to users, home control, or financial and health control) may not be exposed to the hosting network, and D-User functionality may need to be isolated from the hosting network. This can be important when the hosting network is not a trusted party. Depending on the type of UCM service, the required isolation between the D-User and the hosting network may vary.

[0325] In addition, when users communicate with third parties, the hosting network can provide users with additional capabilities, such as preventing privacy and identity leaks to the third party and the hosting network. This may depend on the type of interaction the user is having with the third party, and could include the user accessing application servers or making / receiving payments to the third party.

[0326] 6.17. Privacy Issues Addressed Using D-User and Hosting Platform (HOP)

[0327] Digital entities (DEs) such as D-Users may be isolated from the hosting network, depending on the level of trust the hosting operator wishes to provide. For example, it may be necessary to prevent the hosting network from accessing the digital entity's data. Furthermore, DEs (such as D-Users) may need to be isolated from external networks accessed by the user. Additionally, users may need protection against malicious attacks to prevent the hosting network from accessing their private data.

[0328] Depending on the isolation requirements, different solutions may be implemented. The complexity and / or cost of providing privacy to D-Users may depend on the level of trust the host is willing to provide. For example, a managed network may provide the level of trust described below.

[0329] A hosted network can serve users as a trusted party or as an untrusted party. Table 1 provides examples of the privacy protection levels that users may require for different types of UCM services. To meet these requirements, D-User may need to be instantiated within a separate network module, which can be referred to as the "hosting platform" (HOP).

[0330] HOP is preferably isolated from the hosting network, and the required level of isolation depends on the trustworthiness of the hosting network and the type of UCM service that the D-User is providing to the P-User. Furthermore, HOP can help users protect their privacy when accessing external servers. These use cases are summarized in Table 1.

[0331] In Table 1, a trusted network (T) refers to a network that a user needs to trust to provide specific services / capabilities to the user. Conversely, a non-trusted network (U) refers to a network from which a user can obtain services while protecting their privacy without disclosing their information to the network providing the service. A network can protect the privacy of a real entity by: 1) preventing the visibility of real entity data and / or DE data, 2) preventing the visibility of the processing of real entity data and / or DE data, or by preventing the visibility of the execution of specific functions of a real entity from any other entity using the hosted network or from any other external network.

[0332]

[0333] Table 1 - Exemplary privacy levels that managed networks can provide for UCM services

[0334] 6.18. HOP Requirements and Solutions / Use Cases

[0335] The HOP requirements and solutions for the situations shown in Table 1 are described below.

[0336] 6.18.1. Current Model (No D-User, No Third-Party Privacy)

[0337] Current mobile networks function as transmission systems that allow users to access external data networks / servers. Data can be encrypted end-to-end, so only the user device and application server have access to and control over the data. Users can filter the data they share with third parties; however, depending on the services they receive, they may be required to provide information such as their identity and other valuable information. Furthermore, in current mobile networks, users may have no control or management over the services they receive from the network (i.e., they cannot run any UCM services).

[0338] 6.18.2. Use Case 1: Provide anonymous access to a third-party server (the service provider's network may be trusted).

[0339] In a possible implementation, the mobile network can hide entity identity (ID change) so that users can anonymously access external servers. The network is trusted to retain the description of the accessed site / server, except in cases of police tracking. In this scenario, the entity associated with the corresponding DE can be trusted by HN.

[0340] Requirement: The external server should not know which digital entity accessed it.

[0341] Solution: The hosted network can perform an ID management function (IDMF) to change the source ID and return address of digital entities hosted in the HOP. However, the hosted network may know which servers the digital entities access (privacy is compromised to the hosted network). The hosted network may include a hosting network function (HNF) that facilitates access to one or more DEs for anonymous access to external servers by performing an identification management function (IDMF), which changes the source identifier (or source ID) and / or response address associated with one or more DEs. For example, the source ID and response address may correspond to IP addresses that can be used to trace the identity of a digital entity (such as a D-User).

[0342] HOP Requirements: HOPs can be isolated network functional modules created using the infrastructure of a managed network.

[0343] 6.18.3. Use Case 2: Network Awareness of In-Network Processing (D-XX Exposed to Trusted Networks)

[0344] In possible implementations, processing data within a hosted network can enable various services for an entity, such as AI services or service optimization solutions. While a hosted network can provide services, there is a risk that data and processing details may be exposed to it.

[0345] Requirements: The managed network can provide entities with a data processing function (DPF).

[0346] Solution: The host can provide a Data Processing Function (DPF) for the entity. For example, an HNF in a managed network can process DE data (i.e., D-XX data, such as D-User data) within the HOP by executing a data processing function (DPF) within the HOP. In this case, the DE data (payload) is exposed to the managed network but is kept confidential from external entities. The managed network can additionally provide entity ID changes similar to those in Use Case 1 to protect the entity's identity from third-party influence, but the managed network can know the external server address and payload.

[0347] HOP Requirements: HOPs can be isolated network functional modules created using the infrastructure of a managed network.

[0348] 6.18.4. Use Case 3: Network-unaware data processing within the network (D-XX isolated from untrusted managed networks)

[0349] Unlike use case 2, DE data can be processed within the managed network without exposing it to the managed network. Similar to use case 1, anonymous access to external / third-party servers can be additionally provided. However, the managed network may be aware of the external server addresses.

[0350] Requirements: The managed network may need to provide entities with isolated data processing functions (DPF) within the managed network, and provide ID changing functionality to allow anonymous access to external servers.

[0351] Solution: Hosted networks can provide DPFs or digital entities, such as D-Users, within isolated enclaves.

[0352] HOP Requirements: An HOP can be an isolated enclave within a Confidential Computing Environment (CEE). By providing containers within a trusted execution environment (TEE) that instantiate the HOP, the HPF of the hosting network (HN) can prevent the HN from accessing DE data. This TEE corresponds to the Confidential Computing Environment (CEE) within the HN. Therefore, the containers can be isolated from the HN's operating system (OS). Consequently, when a DE (or D-XX) processes data within the HOP, or when a DE (or D-XX) shares DE data (or D-XX data) with other entities outside the HN, the HPF can prevent the HN from accessing the digital entity's data (DE data).

[0353] 6.18.5. Use Case 4: Anonymous Access to Third Parties (Unknown to the Network) – Isolation of D-XX from Untrusted Hosted Networks

[0354] Anonymous access to external / third-party servers without exposing the external server address to the hosting network. Furthermore, data processing within the network unknown to the host can be similar to use case 3.

[0355] Requirement: The managed network may need to provide the entity with an isolated IDMF (which is inaccessible from the managed network) within the managed network.

[0356] Solution: A managed network can provide IDMF within an isolated enclave. However, to perform ID changes without knowing the managed network, a minimum number of digital entities should be hosted in an isolated enclave (e.g., a multi-D-User platform). Furthermore, the managed network can perform in-network processing within the enclave, as in use case 3.

[0357] HOP Requirements: An HOP can be an isolated enclave within a Confidential Computing Environment (CEE) that can create at least K digital entities, as described in the following literature: L. Sweeney, “k-anonymity: a privacy-preserving model,” *International Journal of Uncertainty, Fuzziness and Knowledge Systems*, 10(5), 2002; 557-570, the entire contents of which are incorporated herein by reference. In such embodiments, the HOP can have a minimal number of DEs. For example, the proposed k-anonymity model requires that communication between a user and a DN be anonymized (i.e., the hosting network cannot know which user within the HOP is communicating with the DN). The k-anonymity requirement can be summarized as “for each combination of identifier attributes in the dataset, there are at least K-1 other people with the same attributes.” Thus, the source ID can be changed with a randomized ID, and the return address can also be changed with a randomized location.

[0358] 6.18.6. Use Case 5: The network is unaware of the D-User's actions.

[0359] This situation is similar to use case 4, but with the additional benefit that the managed network is unaware of the type of operation performed by the digital entity for its services (i.e., the services obtained by the entity are hidden from the managed network).

[0360] Requirements: The managed network may need to provide isolated data processing function (DPF), isolated IDMF, and full user service functions within HOP.

[0361] Solution: In addition to use case 4 above, the functionality related to digital entities (such as D-Users) is entirely housed within a multi-DE platform, for example, by providing a separate network slice for a multi-entity hosting platform. A slice can refer to a logical network segment dynamically created to meet specific service requirements, traffic types, or user groups within a broader physical network infrastructure. Once a HOP is created, it can be given the ability to operate independently. To this end, when creating a HOP, a HOP Manager function (HOP-M) can be created within the HOP. This HOP-M can perform LCM DE (e.g., creation, modification, and termination of digital entities) and the common functions required for DE functions to interact with entities outside the DE (e.g., other platforms within the HOP, hosted network functions, P-Users and P-User devices, third-party servers), as well as privacy protection functions when D-Users communicate with external entities.

[0362] HOP Requirements: HOPs must be provided as isolated enclaves within a confidential computing environment.

[0363] 6.19. Summary of Use Cases 1 to 5

[0364] In Use Cases 1 and 2 above, the managed network can provide the described UCM services, but entity privacy is exposed to the managed network. For example, exposed D-Users (e.g., using infrastructure managed and controlled by the managed network) can be used for these services.

[0365] In use cases 3, 4, and 5, different UCM services can be provided through a DE installed within a managed network, depending on the privacy requirements of these use cases, without exposing entity functions or entity data to the network.

[0366] Therefore, network operators may have at least two options for providing services to digital entities.

[0367] 6.19.1. Managed network provides DE services as a trusted entity (Use Cases 1 and 2):

[0368] In this scenario, only entities that can trust the hosting network (such as users) would be interested in gaining the ability to restrict the hosting network's public access. The hosting network may not need to provide strict isolation from other entities, although it may need to provide full protection for DE data and operations to prevent them from being exposed to external entities interacting with the DE or entities (e.g., data consumers, servers, etc.). Furthermore, digital entities may need to be isolated from each other to protect their privacy. Additionally, a Gateway in the C / M plane and a Gateway in the DP plane can be used to control access to the internal functions of the HOP. The hosting network can use its own infrastructure to create isolated software containers (HOPs) for the DE, and the hosting network may not need to provide hardware isolation similar to a TEE because the hosting network is trusted. Containers can consist of standard software units that package the code and all its dependencies.

[0369] 6.19.2. A host provides D-User services as an untrusted network, where the user does not need to trust the managed network (use cases 3, 4, 5):

[0370] In this scenario, the managed network may need to perform additional steps to isolate the DE from the managed network in which the HOP is provided. Therefore, the HOP may need to be created within a confidential computing environment (such as a TEE) established within the managed network and pre-configured to enable the creation of necessary functionalities within the HOP and interaction with entities requiring DE services. In this case, the hardware portion of the HOP can be created using a platform manager within the HOP, which can also create additional functionalities and the interfaces required for those functionalities.

[0371] In both cases, the DEs should be isolated from each other, and privacy protection technologies may be needed when accessing external servers. For use cases 3, 4, and 5, isolation from the hosting network may be required.

[0372] 6.20. HOP Placement

[0373] In possible embodiments, the hosting platform (HOP) can be placed within a mobile network (MN), such as a radio access network (RAN), a multi-access edge computing (MEC) network, or a core network (CN), or it can be placed in any type of data network.

[0374] Keeping the HOP within the mobile network (MN) may have many advantages compared to keeping it within the data network because:

[0375] - Bringing the HOP closer to the entity (such as the user) will reduce latency between the entity and its digital twin / digital entity;

[0376] - All communication on mobile devices is conducted through wireless networks, thus wireless networks better serve digital entities. Conversely, users have many ways to select hosts on a data network, and communication with other data networks will not go through the selected host, and the selected host cannot provide all the services that a wireless network can offer;

[0377] - When a host is located in a data network, users may not be aware of the methods the host uses to protect privacy, because hosts in the cloud may not be as trustworthy as network providers that offer mobile access to users.

[0378] The following describes a general approach to creating a hosting platform (HOP) and a generic hosting platform architecture.

[0379] 6.21. General HOP High-Level Architecture

[0380] Figure 8 illustrates the high-level architecture of the General Hosting Platform 800. Some HOP Networking Functions (HPF) may include:

[0381] ●C / M plane function 810 can be divided into the following functions:

[0382] ○C / M Gateway 830 controls the incoming and outgoing messages for internal C / M functions (access control, security, and isolation).

[0383] ○C / M plane privacy preserving portal (PPP) 832, which can be included in C / MGW

[0384] ○HOP Manager Function (HMF) 834

[0385] ○HOP Internal Function Organizer (HFO) 836

[0386] ○ Public C / M network function (NF) 840, which supports the operation of digital entities (D-User or any type of D-XX) 860.

[0387] ●DP function 812 can also be divided into public database 840, PPP 842 and other DP NF 844 to support the operation of digital entities (D-User or any type of D-XX).

[0388] Further details regarding these functions will be provided later in this document. In this invention, a gateway may refer to a network element that acts as an interface between different types of networks or protocols.

[0389] In addition to D-Users, the HOP 800 can also host other types of digital entities (i.e., DEs or D-XXs) for any digital representation of real-world objects such as infrastructure (D-Inf) or organizations. HOP C / M functions, such as the Platform Manager 834 and Function Orchestrator 836, are used for coordinating D-Users and other DEs. Similarly, common DP processing functions 844 and data storage 840 may exist. Each DE or D-XX may have its own specific internal control, management, and data processing functions, isolated from the hosting platform via a specific gateway (i.e., C / M GW or DP GW). A digital entity (D-XX) function or DE function can be referred to as a block of functional code executable by one or more processors within a digital entity (D-XX), with predefined external interfaces and behaviors for receiving, processing, and sending data packets. Examples of DE functions include C / M plane functions and data plane functions. In a possible embodiment, access to DE functions executed by DEs hosted in a network-provided HOP is controlled by the hosting network function (HNF) of the hosting network.

[0390] 6.22. Overview of D-User Creation and UCM Service Establishment

[0391] As mentioned above, to provide UCM services, digital entities, or D-Users, can be created within a hosted network with the required functionality to digitally replicate users. D-User functionality can be isolated based on the type of UCM service the user is using. Therefore, D-Users can be created within containers as isolated software modules within the hosted network. Containers are standard software units that package code and its dependencies, enabling applications to run quickly and reliably on a hosting platform (HOP).

[0392] Containers may run on the same OS used to host the network server, resulting in weak isolation between containers and relative to the hosting network. In this document, the term "software container" refers to this type of container. Additional protection methods exist to safeguard certain functionalities of a given digital entity from other containers within the same hosting platform, but software containers may not be completely isolated from the hosting network.

[0393] In terms of a protected memory region that provides confidentiality for data and code execution, an enclave can be a container that provides hardware isolation. An enclave can be an instance of a hardware-protected trusted execution environment (TEE). Therefore, it is referred to as a hardware container in this document. An enclave can also run on its own CPU, separate from the CPU used by the hosting network. An enclave can also be understood as a virtual machine (VM).

[0394] Therefore, based on the level of privacy required by the entity, a hosting platform (HOP) can be created for digital entities (such as D-Users) using software containers or hardware containers (enclaves).

[0395] A hosting platform (HOP) can be a dedicated platform for a single D-User or a platform for multiple D-Users (multi-D-User platform). This configuration of HOP can also be used for any type of digital entity; that is, HOP can host a single DE or multiple DEs, depending on the privacy requirements of the DEs.

[0396] To support multiple DE platforms or the NET4DW platform, an additional remote attestation layer may be required. First, the hosting network may have access to the HOP. Second, when the HOP creates a DE (D-XX) and connects it to a DE (D-XX) operator (in the case of D-User, the end user is the operator), the DE operator should be able to perform remote attestation of the DE to gain confidence in the DE's security and integrity. This ensures that, if the DE code is provided by a vendor, the hosting network cannot access the DE hosted in the HOP, and the vendor can attest to the DE's integrity during remote attestation. In some embodiments, in addition to providing the HOP in an enclave of the hosting network, each DE may also be provided in an enclave.

[0397] When a host network operator (HNO) decides to provide D-User services, the HNO can first create a HOP platform with a HOP manager that can instantiate the D-User portal when the HNO requests network functionality. Some HNOs may not use a common HOP (such as NET4DW or a multi-D-User platform) to create D-Users and can create separate D-User platforms as needed. In this case, each D-User or D-XX module can have its own enclave.

[0398] Accordingly, establishing a UCM service may require the following procedures:

[0399] - A hosting platform is created that allows you to build and configure the D-User module.

[0400] - The creation of D-Users (e.g., when a user or any network function requests them, or to prepare several different types of D-Users in advance and have them ready when needed).

[0401] -Establishment of specific UCM service capabilities

[0402] These procedures are briefly described below.

[0403] 6.23. Hosting Platform Creation

[0404] When the HNO decides to provide services to digital entities, such as D-Users, the HNO can first create an HOP platform 800 with a HOP manager 834. This HOP manager can instantiate DEs (D-XXs), including, for example, a D-User portal, upon request from the HNO CPF or the HNO's D-XX Service Manager (DSMF). The HOP platform is created within the HNO network but isolated from it, so the hosting network cannot access the digital entity data within the platform. This platform can be created in at least two ways.

[0405] One possibility is that HNO uses its own infrastructure to create isolated software containers for the hosting platform (HOP). In this case, the internal function creators may not be within the hosting platform (HOP). Platform Manager 834 can manage HOP NFs and associated resources using APIs. Without hardware isolation, this option may not be the first choice for operators or end users of digital entities.

[0406] Another possibility is that the HNO can use an enclave, such as a trusted execution environment (TEE), which is pre-configured to create the necessary functionality within the hosting platform (HOP) and interact with DE operators or end users. In this case, the hardware hosting platform could be a standard platform with a platform manager 834, which is capable of creating additional functionality and the necessary interfaces.

[0407] 6.24. Creation of Digital Entities (D-XX):

[0408] The following paragraphs will provide a general explanation of the creation of digital entities (DE or D-XX), and will also refer to the specific use case of creating a digital entity (D-User) for a user. As mentioned above, in this application, a digital entity (also known as an entity copy or digital twin) represents or replicates any type of entity, whether it is for an organization, object, process, application, set of objects, or user. The creation process for these different entities is similar, and similar creation functionalities can be used. The creation of a user entity (D-User) represents a specific use case for the creation of digital entities.

[0409] The creation of a D-User within a HOP can be initiated by a user, a network entity, or another D-User. In a possible implementation, the D-XX Service Manager (DSMF) can request the HOP to create a D-XX module or assign an existing D-XX module created in the system to a specific user. There are several ways to do this.

[0410] A D-User can be created upon request from a user or network entity, such as after a user has subscribed to a D-User service. When the Digital Entity Service Manager (DSMF) receives a message from a user or from the network function of the HNO, the DSMF can send a D-User creation request along with the type of digital entity to be created (e.g., a D-User with strict privacy requirements) to a HOP function (e.g., the HOP Manager function). There can be different types of digital entities and different types of D-Users, as described herein. This request can be generated by a network function when a D-User subscribes to a specific D-User type or UCM service. When an enclave is used for HOP, the HOP Manager function can create the required D-User module using its function orchestrator 836, or when a software container is used for HOP, the HOP Manager function can create the required D-User module through the HNO's function orchestrator. Once the D-User is created, a secure link can be established between the user and the D-User for further communication, and the D-User service can be established.

[0411] For other types of digital entities, the process may be similar. In the general case of requesting the creation of a digital entity, the digital entity's service provider (network operator or external service provider) requests the creation of the digital entity from the DSMF. The DSMF can then request the HOP to create the digital entity, and the HOP can use its function orchestrator 836 to create the digital entity.

[0412] The managed network and / or HOP can create and store one or more digital entities, such as D-User modules, for immediate use. Since the creation process of digital entities (including the creation of various functions and interfaces and the configuration of these functions) can take some time, if a user or the managed network needs to create D-Users without significant latency, the managed network can create and maintain several D-Users in standby mode without assigning them to end users. Other types of digital entities may also have additional unassigned D-XXs so that the HOP can quickly allocate these digital entity modules when a request is received. The number of DEs to be maintained in semi-active mode may depend on the rate at which requests to create D-XXs are received. Pre-configured DEs can be stored within a single HOP or across different HOPs. Pre-deployed and pre-configured D-Users can be of different types to accommodate different user needs. When pre-configured D-Users are available, the managed network can quickly assign these D-Users to users upon receiving a request, based on the instructions in the request. However, some additional configuration steps may be required before the D-Users are fully operational.

[0413] Digital entities can be created dynamically (e.g., within an access network), such as when a user wants to obtain a D-User service (i.e., a UCM service) or when a service provider wants to offer a new D-XX service. In the case of D-Users, a user or network function can request the D-User creation function (DUCF) in the control plane of the hosted network to create a specific D-User type or assign an existing D-User container to the user, who can then use the UCM service. In the case of D-XX modules, a service provider can send a request to the D-XX creation function (DXCF—the appropriate function for that D-XX type) to create a D-XX module or assign an already available D-XX module to the service.

[0414] 6.25. Establishment of specific D-XX services (such as UCM service or D-User service)

[0415] Once a D-User is created, the user may request other UCM services. This can be done by attaching to a service layer function (i.e., DSMF), by dynamically requesting a control plane function (i.e., DUCF), or by dynamically requesting a HOP or D-User management function. However, as mentioned above, a user can request the creation of a UCM service without creating a D-User. In this case, the network treats it as a request for a specific type of D-User with that UCM service and creates the D-User accordingly.

[0416] For a given digital entity (D-XX module), there can be different types of services. A D-XX service operator may need some operations or services from the D-XX module and may need to configure these operations or services. Furthermore, some D-XX service providers, such as mobile virtual network operators (MVNOs), may have end users or terminal devices that obtain services directly from the D-XX module. Both of these service types can be incorporated into the D-XX configuration.

[0417] A user or hosting network function (HNF) can request the establishment of a specific UCM service. This request is received by the D-User Creation and Configuration Function (DUCF) within the HNO. The DUCF function can be incorporated into a more general DXCF module, which is used to create services for digital entities, and specifically for providing D-User-related services. If a D-User has not yet been created, the method can first follow the steps of the D-User creation process described above. Once the D-User is available, the DUCF can request the establishment of the UCM service from the HOP or the D-User, depending on privacy requirements and specific implementation details. Similarly, for D-XX services, the request can originate from the D-XX service operator or its client device and be sent to the DXCF (D-XX Creation and Configuration Function), which can then request the establishment of the service.

[0418] In some cases, it may be necessary to perform UCM service establishment transparently to the managed network, i.e., to perform UCM service establishment without the managed network being aware of the new UCM service. In this case, the D-User Manager has the necessary capabilities and may also have the authority to request the creation of new managed network functions, i.e., HOP functions (HPF), or to configure new managed networks by obtaining authorization from the network. These capabilities can be provided to the D-User Manager when the HOP Manager creates a D-User. Similarly, for D-XX services, if the D-XX service operator requires completely independent operation, various D-XX services can be established by the service provider directly requesting D-XX (e.g., D-XX Manager functions). For this purpose, D-XX capabilities can be provided to the D-XX Manager during the establishment of the D-XX module, and the managed network function can be used to receive and execute specific requests from the D-XX Manager required for the establishment and operation of D-XX services.

[0419] 6.26. Create a managed solution for D-Users with different isolation requirements.

[0420] To meet the requirements of the above use cases, the following steps can be implemented.

[0421] Each D-User can be isolated from other users' D-Users, but they can share the same network functionality. In this case, a D-User can use a software container that provides additional functionality to isolate that D-User from other D-Users. When a user has access to multiple D-Users, the D-Users may not need to be isolated from each other, and they can share common operational functions.

[0422] HOPs can be created within an enclave isolated from the hosting network (i.e., even the hosting network may require permission to access functionality or data within the enclave). This could be useful, for example, for use cases 3, 4, and 5 described above. For these cases, an isolated confidential computing platform, such as a TEE (or CEE), can be used.

[0423] The HOP platform can be used for multiple D-Users to perform ID changes to hide the end-user's identity when communicating with external devices, and even from within the hosted network. This could be useful, for example, in use case 4. A hosting network function (HNF) within a hosted network can ensure that the hosted network cannot track external servers accessed by a specific digital entity (D-XX) by deploying the hosting operations platform (HOP) as multiple DE-HOPs. When an HOP hosts multiple digital entities (DEs), the HOP may be unable to track which specific DE accessed which external server.

[0424] A HOP can also retain a minimum number of DEs (Delegates), such as D-Users. For example, the K-anonymity model requires that communication between users and DNs be anonymized (i.e., the hosting network cannot know which user within the HOP is communicating with the DN). The K-anonymity requirement can be summarized as "for each combination of identity attributes in the dataset, there are at least K-1 other people with the same attributes." Therefore, the source ID of a message sent to a DE can be changed using a randomized ID, and the response address of a message sent by a DE to a user can also be randomly changed using a randomized location (e.g., a random or encrypted IP address).

[0425] The confidentiality requirements of D-Users can also be met by placing one or a limited number of D-Users in an isolated enclave. Communication with third parties via the outgoing and incoming ports of each enclave can be carried out through another isolated enclave on the hosted network. This isolated enclave can be used to perform random ID changes, thereby protecting the confidentiality of D-Users relative to third parties. In this possible embodiment, it is possible to maintain the confidentiality specifications of D-Users even if the number of D-Users in the HOP is limited. Once the HOP is created, it can be given the ability to operate independently. This may be useful, for example, for use case 5 described above.

[0426] Therefore, when creating a HOP, a HOP Manager function 834 (HOP-M) can be created within the HOP. HOP-M 834 may be able to perform LCM for D-Users (e.g., creation, modification, and termination of D-Users). HOP-M may also be able to perform common functions required for D-Users to interact with entities outside of D-Users (e.g., other platforms within the HOP, hosted network functions, P-Users and P-User devices, third-party servers), as well as privacy protection functions when D-Users communicate with external entities.

[0427] Metaverse or digital world (DW) applications can use different types of digital entities (D-XXs), and the operation of digital entities (D-XXs) and DW applications may require privacy protections. Specifically, the operation of a DW may need to be kept confidential from the hosting network. The hosting platform (HOP) discussed here can also be used to provide DWs within the network. A DW can consist of D-Users, various D-Rep (such as D-Inf), and various other applications (such as VR or AR applications).

[0428] 6.27. System Architecture for Creating HOPs within a Network

[0429] Figure 9 illustrates an exemplary system architecture 900, which also includes HOP creation functionality and various interfaces. Note that these interfaces (VR1-VR5, MP1-MP5) are logical interfaces, connected via a common bus under the SBA architecture shown in Figure 11. Users can connect to the managed network 904 via user equipment (UE) 902 through the radio access network (if the managed network is the core network) or via both the RAN and CN (if the managed network is a data network in the cloud). These interfaces are not shown here because they are logical interfaces. The logical interfaces are shown to illustrate the relationships between the different functions involved in creating an HOP.

[0430] Figure 9 also illustrates an exemplary data plane (DP) 912 connecting UE 902, managed network 904, digital entity (D-User), (D-Rep) 908', HOP DP function 914, and external data network and server 980. As shown in Figure 9, data communication between HOP 910 and external server 980 can be performed via HOP DP GW 930. This configuration is given as an example only and may vary depending on how access to the HOP data plane is implemented.

[0431] The HOP creation process can begin with the network operator determining the type of HOP to be created, such as based on the type of digital entity (D-User or others) and the UCM services to be provided. The network operator can then provide the hardware and software requirements for the HOP to the Infrastructure XaaS Service Management Function (ISMF) 950 based on this determination. ISMF 950 can further assess or confirm the resource requirements and capabilities of the hosted network in determining the type of HOP. ISMF 950 can then request the Hosting Platform Creation and Configuration Function (HPCCF) 952 to create the HOP. HPCCF 952 can use the Platform Installer (HPIF) 954 to create the HOP and instantiate the initial functions required to create and manage digital entities (including, for example, D-User and / or D-Rep). These initial functions may include the HOP Network Function (HPF). The HOP Network Function (HPF) may include various functions, including the HOP manager function (HMF) 968, which can be used to create digital entities 908, 908'. HPCCF 952 can configure those initial functions and provide design packages for different functions. Design packages for different functions can be stored in the blueprint description repository (BDR) 956. The blueprint description repository management function (BRMF) 958 can obtain the required design package via interfaces MP4 and MP5 through HPCCF 952 based on the HOP creation request, and send the design package to the HOP manager 968 for use, for example, to create specific types of digital entities, such as D-User or D-Rep. These initial functions may include the HOP managing function (HMF) and other common control and management functions.

[0432] The exemplary HOP 910 shown in Figure 9 also has an internal function creator module (FCM) 962, which may include a HOP function orchestrator (HFO) 964 to instantiate additional functions within the HOP. An orchestrator typically refers to a component or service responsible for coordinating and managing the deployment, configuration, and operation of multiple services or components. For this purpose, the HFO 964 may use the infrastructure provided for the HOP (e.g., storage allocated to containers), which can be managed by an infrastructure manager (IM) 972. The created HOP network functions (HPFs) can be managed by a network function manager (NFM) 970.

[0433] In embodiments where the HOP uses resources from a managed network infrastructure, the entire FCM module 962 can remain outside the HOP, and network function creation and other LCM operations can be accomplished by requesting the external FCM 962 to create the HOP's HPF. Alternatively, the HFO 964 can be located within the HOP, and other functions of the FCM 962 can be placed outside the HOP.

[0434] When a user, network entity, or any other authorized entity requests the creation of a DE, this request can be received by the D-XX creation function (DXCF) 966. The DXCF can then instruct the HOP manager 968 to create a container for the DE, which includes a D-XX manager (D-XX-M) 862 (identified in Figure 8) and certain basic functions (such as access control functions). Instantiation of other functions required by the DE can be performed by either the D-XX-M 862 or the HOP manager, depending on the required independence of the digital entity relative to the HOP. Note that if each digital entity is created within an independent enclave, a separate D-XX-M is not required, and all D-XX-M functions described in this document can be performed by the HOP management function (HMF) 968. Each digital entity (D-XX) can include D-XX functions accessible to the P-User via a P-User access device (UAD) or via the UE, without the HN needing to know or be aware of them. In other words, the functionality, applications, and data of D-XX hosted in HOP may not be visible to the hosting network. HN may not have access to HOP functionality, nor to D-XX data or D-XX operations. HN is in a blind state, unaware of the functionality and operations performed by or within HOP. In some cases, functionality within HOP may be provided by the user or by an external server trusted by the user (a third party).

[0435] To make a request to DSMF 974, the VR2 interface in Figure 9 can be used. This request can include the digital entity or UCM service type, as well as the date and time the digital entity is required. To make a dynamic request to DXCF 966, the user control plane function can use the VR1 interface to indicate the digital entity or UCM service type, user ID, and subscription details. DSMF 974 or DXCF 966 then makes a request to HOP Manager 968 (after authentication and authorization of the request) to create the required digital entity for the requested service using the VR3 interface. HOP Manager 968 then creates the digital entity with D-XX Manager (D-XX-M) 862 and establishes a secure link between D-XX-M and HMF 968 to configure the digital entity (such as D-User1, D-User2, or D-Rep) via interface VR5 and any other appropriate functions.

[0436] 6.28. HOP Design Package

[0437] According to possible embodiments, the HOP design package may include one or more of the following aspects.

[0438] HOP design packages can include types of digital entities (D-XXs) that may be created within HOP, as well as digital entity design packages. For example, there can be several D-User types that can be created with associated UCM services. Therefore, procedures for all D-User types and UCM services that HOP can host and support can be specified. Design packages can also include the necessary functionality required for each service.

[0439] The HOP design package can include an indication of the maximum number of digital entities (D-XX) that the HOP can support. This number can be determined based on the different types of digital entities. For example, an HOP can support 5 D-Rep, 3 D-UE, or some combination thereof. This number can also be defined based on the DE applications that the DE can be used to perform, including, for example, AI algorithms / methods / environments, tasks, services, etc.

[0440] The HOP design package can also include procedures for creating new types of digital entities (D-XX).

[0441] The HOP design package can include common HOP functions and their configuration and association processes.

[0442] The HOP design package can include programs that the HOP manager function (HMF) can execute after the HOP is created. These include programs for establishing secure communication with the managed network, such as HPCCF, DUCF, and DSMF, as well as programs for the managed network function discovery process, including, for example, message passing structures and ingress and egress ports used when communicating on the managed network's C / M and DP buses.

[0443] The HOP design package may also include functions and procedures associated with the HOP managing function (HMF).

[0444] The HOP design package can also include resource requirements for digital entities (D-XX), which may include, for example, storage, compute, and link capacity for different interfaces. Computational resources may include the number and speed of CPUs or GPUs, the percentage of CPU power allocated from the compute engine, and RAM memory requirements. Storage requirements may include storage size and access speed.

[0445] The HOP design package may also include QoS characteristics (e.g., latency, packet loss, data rate, etc.) of the links between digital entities and associated real entities (e.g., users, devices, etc.). This may include, for example, link requirements between the anticipated digital entity (D-XX) and network functions in the HOP or hosted network. (For example, for a D-User, the link between the D-User and the user, the link from the D-User to other networks, and the links to HOP functions (such as the Hosting Platform Creation and Configuration Function (HPCCF), D-User Creation Function (DUCF), and Infrastructure Service Management Function (ISMF)).

[0446] If a digital entity replicates multiple physical devices, for example, in the case of a base station (BS) digital representation (D-Inf) including processing units, antennas, and cables, the links between the digital representations (D-Rep) of these assets are also considered in the HOP design package.

[0447] HOP and / or Digital Entity (D-XX) characteristics may include:

[0448] -Guaranteed / Maximum Downlink Throughput

[0449] -Latency tolerance

[0450] -Energy efficiency

[0451] Group communication support

[0452] - Mission-critical support

[0453] - The maximum number of concurrent sessions supported by HOP

[0454] -Location support and related location methods and functions

[0455] -HOP's service scope may include its region, country, area, etc.

[0456] - Priority: When resources are allocated to multiple D-XXs on the same HOP, each D-XX may have a different priority. For example, a mission-critical D-XX may take priority over many other D-XXs, or a D-XX with critical latency analysis (e.g., XR) may take priority over other D-XXs.

[0457] -Supported real-world mobility levels

[0458] - Edge and main HOP / D-XX support

[0459] - Task management support or task-based traffic support

[0460] - Supports in-network processing, such as traffic, routing schemes, resource allocation, algorithms, and privacy settings.

[0461] The general characteristics of digital entities (D-XX) may include:

[0462] - Information age tolerance, restrictions, and requirements

[0463] -Synchronization requirements

[0464] -Accuracy level of simulation / prediction

[0465] - Resource utilization efficiency, for example, accuracy limitations versus CPU utilization / data volume / training time

[0466] -D-XX granularity levels, for example, representing a BS as a black box, or representing a BS as an associated combination of several entities (e.g., antenna, cable, processor).

[0467] 6.29. HOP Creation Phase

[0468] HOP creation can include at least three stages:

[0469] -Planning, Design and Preparation Phase

[0470] - Creating a HOP container (container available)

[0471] - Complete HOP creation (including required functionality as requested, and preparing to create digital entities (D-XX) upon request).

[0472] The initial stage may involve planning, design, and preparation. Then, a general, basic HOP with all the functionality needed to create any type of digital entity (e.g., HMF) can be considered the initial HOP. After the initial creation of the HOP with HMF functionality, several more steps may be required to bring the HOP to a runnable, ready state. These states of the HOP will be described further below.

[0473] 6.29.1. Planning, Design, and Preparation Phase

[0474] At this stage, network operators can design, plan, and prepare a design package for the HOP, which describes all the functionalities required for operation, their configurations, required interfaces, and all workflows. The resource requirements of the HOP can also be assessed. Furthermore, the isolation requirements of the HOP can be determined. For example, this might involve deciding whether separate hardware, such as an enclave, is needed, especially if the hosting network (HN) is untrusted. Alternatively, the internal infrastructure of the hosting network, such as isolated software containers, can be utilized, for example, when the HN is trusted.

[0475] 6.29.2. Secure Container Readiness Phase (The created HOP container must have at least one HOP management function)

[0476] In this phase, which can be called the “basic HOP phase,” the managed network may have already allocated a separate container for the HOP using a TEE (e.g., a confidential computing environment (hardware container)) or a software container with an internal managed network infrastructure. Providing an enclave for the HOP may involve acquiring, installing, and configuring hardware from a vendor with access security keys. Once the container has been allocated for the HOP, at least a HOP management function (HMF) can be created within the HOP, and a secure communication link can be established between the HMF 968 and the managed network function (HPCCF) 952, where the HPCCF 952 has access to the HOP 910. This means that the HOP 910 is ready to have the functionality and configuration required to establish the type of HOP requested by the customer (e.g., the managed network operator). Essentially, the HPIF 954 can be used to perform container preparation, HMF instantiation, and handing over the HOP container to the managed network function HPCCF 952 with the required access keys.

[0477] 6.29.3. HOP Creation Complete (Running Ready) Stage

[0478] At this stage, all supporting functions and interfaces can be established and configured so that HOP can be ready to create digital entities (D-XX) and support their operation. Once the HOP container is ready with HMF 968, HMF 968 can be used to create and run other functions required for HOP operation, including digital entity (D-XX) creation and supporting D-XX operation and applications.

[0479] Note that in the description above, the second stage of container and HMF readiness is considered the basic HOP state. In this state, the HOP may not yet be ready to provide services to digital entities (D-XX services) because the HOP may require additional functionality and specific configuration to instantiate digital entities. For example, the required additional functionality may depend on the type of digital entity to be supported, the services the digital entity will provide, and the level of trust or confidentiality the hosting operator may wish to offer to users. However, some common functionalities required by any digital entity can be instantiated by HPIF 954 when the HOP is created. Therefore, while HPIF 954's functionality can be used to create containers with HMF, in some implementations, HPIF 954 can instantiate more functionality before handing the HOP over to HPCCF 952.

[0480] In some embodiments, after the creation of a basic HOP (e.g., using a HOP manager (HPM)), the creation of all other functions and operations can be handled by the HPM, allowing the HOP to operate independently of the hosted network. The HOP can be used by external clients or users to create DWs within the hosted network. For example, a D-User might be needed to control a home network, including work robots. Operations might need to be run by a home control application. Users can install home management applications in the D-User, create additional digital copies (D-Rep) of home devices, and configure the home management application to meet user requirements. Applications and data executed within the D-User may not be visible to the hosted network.

[0481] However, in a possible implementation, the HPM may first require access from the hosting network (e.g., from HPCCF) to manage service-related control and data messages using the hosting network's capabilities. Following this initial configuration, the HPM can have full control over its internal processes. Any required software and design packages can also be provided by the hosting network or the user.

[0482] 6.30. HOP Creation Program

[0483] Figure 10 illustrates an exemplary message flow of the HOP creation process 1000 and the different functional modules involved. The following is an exemplary detailed description of the program.

[0484] 6.30.1. Planning, Design and Preparation

[0485] In a possible embodiment, the HOP creation process 1000 may begin with a pre-preparation step, in which the network operator 1010 (e.g., a mobile network operator (MNO)) considers factors such as the following to determine the type of HOP to be created:

[0486] - The types of digital entities (e.g., D-User, D-Rep, or D-Inf) and UCM services that the network may provide;

[0487] - Identify whether end users require confidentiality of the data and applications to be executed in the digital entity, i.e., whether the managed network needs to be regarded as a trusted network;

[0488] If services are to be provided to users as an untrusted network, then the required level of privacy protection for the digital entity relative to the hosted network can be determined.

[0489] - Communicate with TEE vendors (such as TEE manufacturers) to obtain the hardware or software needed to create a confidential computing environment.

[0490] In a possible implementation, the HOP creation process can be triggered by a user requesting the D-User service, even when no HOP is available. This is particularly relevant if the managed network wishes to create a separate HOP for each D-User. In this case, a user or network function can request the creation of a D-User, which includes creating a HOP. However, regardless of the scenario, the HOP creation process can remain unchanged.

[0491] Network operators can also update the latest design packages for HOP and the design packages for digital entity (D-XX) types (e.g., D-User, D-Inf) that the network operator plans to instantiate within HOP. Design packages can be stored in a blueprint description repository (BDR) managed by the blueprint management function (BMF). Digital entity (D-XX) design packages can be standardized and defined by recognized standards, or in some cases, network operators can control their own design packages.

[0492] After the network operator 1010 determines the type of HOP to be created, the network operator can use service interface S0 (identified in Figure 9) to request (1040) the infrastructure service management function (ISMF) 1050, the required HOP type, and any additional specifications related to the HOP, such as the type of container required for the HOP, including, for example, requirements for TEE hardware and software. This request may also include requirements for creating digital entities (D-XX) within the HOP. DE requirements can indicate the required capacity, which can be indicated as the number of digital entity instances of each D-XX type or the total computing capacity, storage, and internal and external link capacity. Furthermore, the request message may include design packages for the HOP and digital entities.

[0493] The ISMF 1050 can assess resource requirements (1041) by: obtaining the availability of resources to provide the required capacity; determining whether additional hardware, such as TEEs, is needed, including associated resources (e.g., compute resources, bandwidth requirements); and determining the network's ability to provide the requested HOP type. The ISMF 1050 can then identify the infrastructure used for HOP creation. This information can be provided to the HPCCF 1052. In some cases, the HPIF 1070 can obtain information about available resources from the ISMF 1050.

[0494] Then, the ISMF 1050 can use interface MP0 (identified in Figure 9) to request the HPCCF 1052 to create a HOP (1042) using the newly acquired hardware or internal infrastructure. The request message issued by the ISMF 1050 to the HPCCF 1052 may include the HOP design package and potential D-XX design packages, as well as the resources to be used.

[0495] The HPCCF 1052 can verify available design packages (1043) from the BRMF 1058. The HPCCF 1052 can send HOP requests and Digital Entity (D-XX) requests to the BRMF 1058. If the ISMF 1050 provides a design package, then that design package can also be sent to the BRMF 1058.

[0496] Design packages can be stored in a blueprint description repository (BDR), and the BRMF 1058 can obtain the required design package (1044) from the BDR based on a HOP request. The BRMF 1058 can query the BDR and send one or more design packages that match the HOP and D-XX requirements to the HPCCF 1052.

[0497] HPCCF 1052 can select or prepare a final set of design packages (1045) to match HOP requirements.

[0498] HPCCF 1052 can request HPIF 1054 to instantiate and configure HOP (1046). HPCCF 1052 can provide necessary design package details and other managed network details.

[0499] HPCCF 1052 can request HPIF 1070 to create a HOP and instantiate the initial functions and interfaces required for creating and managing digital entities. This step may include providing HPIF with a finalized HOP design package. A list of initial functions may be provided to HPIF, which includes at least HOP network functions (HPF), such as the HOP manager (HPM). This list may also include other supporting functions, such as privacy protection functions or LCM functions.

[0500] In some cases where third-party hardware, i.e., hardware provided by vendors other than the managed network, can be used, the HPIF 1070 can communicate with the hardware vendor's external server to obtain an access code to access and create HOPs (1047) with HPM functionality. The HPIF 1070 can also create interfaces with managed network functions such as HPCCF 1052 and DXCF. The HPIF 1070 can also create additional functions to support the proper operation of the HOP.

[0501] The HPIF 1070 can pass an access code or a separate access key to the HPCCF 1052, allowing the HPCCF to complete HOP creation (1048) by deploying (or installing) additional supporting features and providing the necessary configuration. Optionally, these additional features can be created by the HPIF 1070.

[0502] If additional supporting functions are to be installed within the HOP, the HPCCF 1052 can request the HPM to create those functions. The HPCCF 1052 can configure the HPM and all supporting functions, and provide the HPM with design packages for different digital entities (D-XX). The HOP can also have an internal function orchestrator (HFO) to coordinate and manage the internal functions of the HOP. Therefore, optionally, the HPCCF 1052 can pass configuration parameters to the HPM, and the HPM can configure other supporting functions. Whether the HPM can instantiate and configure internal functions depends on how much knowledge the managed network can automatically possess after creation. For some implementations, the managed network may not be able to know the internal configuration of the HOP. The appropriate configuration conforming to the specification is determined individually for each function or by the HPM (1049).

[0503] The HOP configuration can also include establishing a secure link between the DXCF (identified in Figure 9) and the HPM, allowing the DXCF to communicate with the HPM to create a digital entity (D-XX) within the HOP. This D-XX creation request can first be received by the DXCF, which then communicates with the HPM to create the D-XX and establish a communication link between the UE (User Equipment) operating the D-XX and the D-XX. For example, when a user wants to create a D-User, the user request can reach the DXCF (DUCF in this case), and the DUCF can facilitate the creation of the D-User and the establishment of the link between the user and the D-User.

[0504] HPCCF 1052 can notify or inform the network operator or managed network service management that the HOP has been completed and is now ready (1051).

[0505] Then, the operator or end user can request the creation of a digital entity (D-XX) (1053), and after creation, the operator or end user can use the services provided by the digital entity.

[0506] 6.31. HOP Functional Architecture: Functional Description and Interfaces

[0507] Figure 11 illustrates an exemplary functional architecture 1100 of the managed platform 1108, which shows the internal bus structure of the managed network 1104 and details of the platform creation functions. For example, some functions of ISMF 1150, HIPF 1154, DUCF 1166, DSMF 1174, or HPCCF 1152 reside within the managed network 1108, but outside of HOP 1108, they may belong to various other XaaS services. Internal communication within HOP 1108 can be performed using a service-based architecture (SBA) via a common C / M bus 1100 and DP bus 1112. The internal C / M and DP buses can be connected to external buses via HOP C / M GW 1114 and HOP DP GW 1116, respectively.

[0508] 6.32. Function Description: Functions outside of HOP used for HOP creation.

[0509] In the SBA architecture, a function can be described by the services it provides to its customers, the inputs required to provide those services, and the associated outputs. A service can refer to a software component or function that provides specific capabilities or functionalities to a user or other software module. End users or customers can discover service functions using, for example, discovery functions. These services may be limited to authorized end users. End users can connect (through their UE) to network function 1170, which provides services using, for example, the internal C / M1100 and DP 1112 buses. Functions not directly connected to the internal buses can be connected using GW 1114, 1116, and 1118. Reference points for each function are marked on the connection lines to the buses in the diagram; for example, ISMF service 1150 is provided using the NC / M-ISMF reference point.

[0510] The functions and services will be explained below.

[0511] 6.32.1. Infrastructure Service Management Function (ISMF)

[0512] Network operators can use ISMF 1150 to initiate the creation of infrastructure services, in which case HOP is a service. This function provides, allocates, or identifies the infrastructure required for end users to create HOPs. The infrastructure (hardware and / or software) for HOP 1108 can be obtained from third-party vendors for providing and configuring enclaves, or from the network operator's own infrastructure. In some cases, HPIF 1157 may obtain infrastructure from third-party vendors at a later stage after the overall resource requirements are finalized. A basic description of HOP management functions may need to be provided to the infrastructure vendor to prepare the HOP as a customized package, which may include the HPF required to run the HOP, create digital entities, and / or provide services to the digital entities. Additional functions may need to be included in the HOP to facilitate remote authentication of its content. For example, once the HOP is created within a hosted network, the hosted network can use an initial access key to access the HOP and complete its configuration. When creating a digital entity (D-XX module), the end user (owner or operator) of the digital entity can be allowed to prepare an independent access key to communicate with the service operator providing the D-XX service, who needs to authenticate the digital entity. For example, isolation from the managed network may require certification or authentication by the managed network. To this end, a remote certification key can be generated from the digital entity (D-XX module), allowing the service operator to verify the integrity of the digital entity with the infrastructure provider. This capability may be included in the initial enclave provided by the infrastructure provider. In this case, the customer might be the network operator, as the network operator requires HOPs. However, the service can be extended to external customers to create in-network HOPs for their users. For example, an external DW customer might need an in-network DW isolated from the network and could request this service from ISMF 1150 (i.e., DWaaS).

[0513] The ISMF service (provided using NC / M-ISMF reference point 1151) may include initiating the acquisition and allocation of infrastructure based on service requests made by authorized service consumers, to create a hosting platform for one or more of D-User, D-Rep, D-Inf, or DW.

[0514] Potential service consumers include: network operators, HPCCF, HPIF, and third parties looking to create an isolation platform for in-network DW, in-network D-Inf, or any type of in-network D-Rep (including D-User).

[0515] 6.32.2. HOP creation and configuration function (HPCCF)

[0516] HPCCF function 1152 can be initiated by HPIF 1154 requesting the creation of a basic HOP 1108 after obtaining infrastructure information from ISF 1150. After creating the basic HOP, HPCCF 1152 can configure HOP functionality, change access keys, and instantiate additional supporting functions according to the design package for that type of HOP. HOP 1108 can be instantiated and configured by HPCCF 1152, which can perform one or more of the following: manage HPF resources related to storage, processing, and communication; create HPFs within containers; provide interfaces for HPFs; and perform lifecycle management (LCM) on HPFs within containers according to a set of instructions.

[0517] HPCCF services may include:

[0518] - Interpret the HOP service requirements, check available design packages, and finally determine the design package to be executed by HPIF;

[0519] - After finalizing the required design package, request the installation of HOP;

[0520] - Send the new design package to BRMF to be saved in BDR;

[0521] - After creating a HOP, configure the HOP Manager (HMF) and any other basic HOP functions;

[0522] - Request HMF to instantiate the internal functions required for the D-XX module to run.

[0523] Potential service consumers could include: ISMF, BRMF, and HOP-M.

[0524] 6.32.3. Hosting Platform Installation Function (HPIF)

[0525] One of the main functions of HPIF 1154 can include installing HOP 1168 and creating the required initial functions based on the request of HPCCF 1152. HPIF 1154 can be considered an orchestrator for managed network 1104. Initial functions may include at least a HOP manager (HPM). Initial functions may also include other supporting functions, such as privacy protection features for LCM functions.

[0526] When using hardware from a vendor, the HPIF 1154 may need to contact the hardware vendor to obtain an access code to access and create a HOP with the functionality required for the basic HOP. The basic HOP 1108 may include a HOP management function (HMF) 1168 and an internal function orchestrator 1164, which may include access control functions such as C / MG / W function 1114, database function 1120, and DP G / W function 1116. The HPIF can also create interfaces with managed network functions such as HPCCF 1152 and DUCF 1166. The HPIF 1154 can also create additional support functions.

[0527] HPIF 1154 can pass a given access code or a separate access key to HPCCF 1152, enabling HPCCF 1152 to complete HOP creation by instantiating and running additional supporting functions used to create the expected digital entity (D-XX) 1106, and also configuring these functions for the operation of the digital entity (D-XX). Alternatively, the creation of these additional functions can be done by HPIF 1154, and HPCCF 1152 can configure these additional functions.

[0528] Possible services for HPIF 1154 may include:

[0529] - Enclave Preparation: Upon receiving a request to create a HOP as an enclave, HPIF, based on its policy and the requirements received in the creation request, can determine what hardware might be needed from the list of possible infrastructure solutions provided by ISMF 1150, and HPIF can obtain the infrastructure allocation to be used from ISMF. If ISMF 1150 has not yet obtained the required infrastructure from an external vendor, HPIF 1154 can instruct the procurement department to obtain the required HOP hardware from an external vendor. It may be necessary to provide the infrastructure vendor with a basic description of HOP management functions so that the HOP can be used as a customized tool or package to manage the required D-XX services.

[0530] - To this end, the HPIF 1154 can receive a list of hardware vendors, their capabilities, and HOP requirements. After obtaining the hardware, the HPIF 1154 can install the hardware according to the HOP design package or as required, or activate the installed hardware and associated ports to create an isolated enclave.

[0531] - After creating the isolated enclave, HPIF 1154 can obtain the security code for accessing the internal HOP functions and create the HMF 1168 and other initial function sets required for HOP creation according to the procedures given for the enclave.

[0532] When a request to create an HOP as a software container is received, HPIF can instruct the managed network orchestrator to create the HOP using the managed network infrastructure and computing environment, and allocate resources as needed and obtain management of the container.

[0533] - Upon receiving a request, HPIF may provide the HPCCF with a basic HOP, where applicable, in which a security key for access has been established.

[0534] Potential service consumer examples could include HPCCF, ISMF, or DUCF, which could be functions that can request the creation of HOPs.

[0535] 6.32.4. Design the blueprint description repository (BDR) management function (BRMF).

[0536] The BRMF 1158 feature can manage the blueprint description repository (BDR) 1156. The BDR 1156 can contain design packages with different HOP types and options, as well as digital entities (D-XX) 1106 (e.g., D-User) that can be accessed using the BRMF 1158.

[0537] The services provided by BRMF 1158 may include:

[0538] - Update the new HOP, Digital Entity (D-XX) design package, modify and terminate the existing design package in BDR.

[0539] - Matching design packages are available upon request, and HOP requirements may be provided optionally.

[0540] Potential service consumer examples could include HPCCF and HPM.

[0541] 6.32.5. D-User creation function (DUCF)

[0542] DUCF 1166 can schedule D-User creation when requested by a user, network entity, or another D-Rep. DUCF is a special case of DXCF.

[0543] The services of DUCF 1166 may include creating digital entities (in this case, D-Users) within an HOP in response to a request from HMF 1168. The type of D-User to be created can be provided by the consumer.

[0544] Potential service consumers could include: users, authorized managed network functions (e.g., during a switch to an access network), managed network operators, or authorized third-party service providers.

[0545] 6.33. Overview of the functions used for HOP operation within HOP, and the HOP functions set during HOP platform creation.

[0546] The following are some of the functionalities that might be needed within a HOP. Different functionalities can be combined and implemented as one or more functional entities. For example, the HMF might assume most of the responsibilities, or distribute those responsibilities among individual functionalities. Below is an example of responsibility categorization.

[0547] 6.33.1. HOP Management Function (HMF)

[0548] The control and management (C / M) function 1168 can provide the following services:

[0549] - After the initial creation and configuration of the basic HOP (including HMF functionality), continue with the steps to complete the creation of the HOP (creation and configuration of the required supported functions).

[0550] - Continue to participate in the operation of HOP (create digital entities (D-XX) and support their operation).

[0551] Certain digital entities (D-Users or D-XXs) 1106 may have management functions to handle their own internal operations, such as the instantiation of other functions, LCM of these functions, and resource allocation. In some cases, the instantiation of functions within the D-XX module 1106, as well as the LCM and resource allocation of functions, can also be accomplished by the HOP function. For example, the D-User module 1106 may have a D-User manager that enables it to perform internal function instantiation and LCM. This may be important when D-User management is entirely performed by the user. In this case, the HOP can be dedicated to that D-User, and the D-User manager is given the ability to create internal functions, perform LCM, and allocate resources.

[0552] Once created, the HMF 1168 may need to be configured by the HPCCF 1152 for it to perform these operations. Below are some examples of the functions that the HMF 1168 can perform. Some of these functions may be separate functions within the HOP, and whether these functions are handled by the HMF 1168 or by separate functions depends on the implementation. For example, decisions may be made based on HOP AI functions that evaluate operations and provide recommendations or evaluation results (e.g., predictions of the performance of D-XX modules).

[0553] 6.33.1.1. Creation of Digital Entities (D-XX)

[0554] Creating digital entities (D-XX) 1106 and performing LCMs can be primary functions of the HMF 1168. The HMF 1168 can create digital entities 1106 using an internal function orchestrator (HFO) 1164. If the HOP uses a managed network infrastructure, the creation of the D-XX module is accomplished by the managed network's orchestrator based on a request from the HMF 1168. In both cases, the request may include an appropriate design package or basic components of a design package. This request can originate from a DUCF 1166 on the network or be received by an ISMF 1150. If an external host wishes to dynamically create digital entities (D-XX) 1106, such as D-User, D-Rep, or other types of D-XXs, several different types of D-XXs can be pre-installed and kept ready so that, upon receiving a request, the specific functions required for the requested operation type are instantiated. The dynamic creation of these functions can be performed by the HMF 1168.

[0555] When a request is received from one of the managed network functions, such as DUCF 1166, HPCCF 1152, or ISMF 1150, HMF 1168 can create a D-XX 1106 with associated functionality. Then, when HOP 1108 has the capability to create modules within the HOP (e.g., when independent operation is required), HMF 1168 can use the internal function orchestrator (HFO) to create these modules. Otherwise, the managed network function HPCCF 1152 or HPIF 1154 will create those functional modules within HOP 1108. Functionality required outside the HOP (i.e., software container or enclave) can be created by the managed network orchestrator or installer (i.e., HPIF). The request may include a D-User type and user access method, as well as a security key to establish a communication link with the user. Creating a D-User involves creating a set of independent network functions and configuring these functions, as well as configuring common support functions that can be used for D-User services within the HOP or managed network. In some cases, D-User management functionality may be created within the D-User module, rather than by HOP functionality.

[0556] 6.33.1.2. Function Instantiation and LCM Supported in HOP

[0557] For the operation of D-XX module 1106, several supporting functions may be required. These functions can be instantiated when HMF 1168 is created, or HMF 1168 can instantiate these functions. If a managed network infrastructure is used, the instantiation of other supporting functions and LCM can be handled by the managed network orchestrator.

[0558] For this purpose, HMF 1168 can have the full capability to create functions and execute LCMs within HOP, configure them, create GWs outside HOP, provide access control and privacy protection for D-XX module 1106, and support other operations for applications running in HOP 1108 and D-XX module 1106.

[0559] 6.33.1.3. Configuration of Supported Functions

[0560] Once created, the supporting functions can be used to perform the necessary operations based on the HOP design package. For example, one of the supporting functions within HOP could be the HOP function orchestrator (HFO) 1164, which might be able to create functions and perform LCMs within an isolated container. Another supporting function could include a privacy-preserving portal (PPP) 1172, which can be configured based on D-XX modules and their services that require HOP support.

[0561] 6.34. Privacy Preserving Portal (PPP) and Access Control

[0562] To help ensure that the UE's privacy is not leaked to the managed network and vice versa, several PPP functions can be used, each with a different objective, as shown below.

[0563] 6.34.1. Protect UE privacy from being exposed to the host or DN

[0564] One of the functions of PPP 1172 is to protect UE / customer data from exposure to untrusted managed networks. This function can be provided within D-User / D-XX 1106 or HOP 1108. If Trusted Execution Environment (TEE) is used, this function can be placed outside the HOP. Using PPP functions (such as data filtering) in the UE or customer equipment, for example using full homomorphic encryption (FHE), may restrict data consumers' access to data. Therefore, PPP 1172 can be provided within D-User / D-XX / HOP or in a secure location within the HN, allowing all user queries, interests, and other data to be shared exclusively through this PPP. PPP 1172 can have the following core modules:

[0565] 6.34.1.1. Data Portal:

[0566] The data portal provides data processing capabilities, including, for example, data collection, data distribution, and policy application.

[0567] 6.34.1.2. Encryption Suite

[0568] Encryption suites can provide privacy and security features, including

[0569] - The Full Homomorphic Encryption (FHE) module helps enable operations such as privacy-preserving queries.

[0570] - Identity management (IDM) generates and manages pseudo-IDs representing D-User / D-XX information. To ensure anonymity within the hosting network, there should be at least K D-Users / D-XXs within the HOP, as described in the K-anonymity requirement. For example, the K-anonymity model requires that communication between a user / customer and a DN be anonymized (i.e., the hosting network cannot know which user within the HOP is communicating with the DN). The K-anonymity requirement can be summarized as "for each combination of identity attributes in the dataset, there are at least K - 1 other people with the same attributes." Therefore, the source ID can be changed using a randomized ID, and the user / customer's redirect address can also be changed using a randomized location. These locations may change each time they are used.

[0571] 6.34.2. Strategy Engine

[0572] The policy engine can provide updated access policies from users and interact with the cryptographic suite module and data portal to reflect user dynamics.

[0573] 6.35. Access Control and Authorization:

[0574] Access to D-XX 1106 and HOP functions can be strictly controlled. Any incoming message can be authenticated first; if authentication is successful, authorization can then be granted.

[0575] 6.36. Design package storage and storage management functions.

[0576] The Digital Entity (D-XX) design package can be stored in this memory. The Digital Entity design package describes the structure, configuration, and procedures for creating and controlling the Digital Entity (D-XX) 1106 from instantiation to termination. Different Digital Entities (D-XX) 1106 have different characteristics.

[0577] For example, the D-XX design package may include one or more of the following:

[0578] - User ID, user IP address, one or more supported D-User / D-XX types (e.g., a specific D-User / D-XX type and / or one or more UCM service types, supported D-XX service types, D-Inf types and service types, supported XR types).

[0579] The -D-XX module contains the required constituent functions for each service supported by each D-XX type (e.g., UCM service type D-User support in a particular implementation).

[0580] The -D-XX module supports a service setup procedure for each service (e.g., a UCM service setup procedure for each UCM service type of D-user).

[0581] The -D-XX module supports the service runner for each service (e.g., the UCM service runner for each UCM service type of D-user).

[0582] -D-User resource requirements include storage, compute, and link capacity for different interfaces. Computational resources may include the number and speed of CPUs or GPUs, the percentage of CPU power allocated from the compute engine, and RAM memory requirements. Storage requirements may include storage size and access speed.

[0583] - QoS characteristics (e.g., latency, packet loss, data rate, etc.) of links between D-XX modules and associated real entities (e.g., users / clients), and links between D-XX modules (e.g., D-User modules) and network functions in HOP or managed networks. (For example, for D-User, the link between D-User and the user, the link from D-User to other networks, and the link from HOP functions (e.g., HPCCF, DUCF, ISMF).

[0584] 6.37. Billing and Checkout Functions

[0585] This function enables billing for D-XX services. Billing (or billing) can be based on the D-User service type or the traffic used by these services, or both.

[0586] 6.38. Common Database Manager (CDM)

[0587] The CDM 1120 controls access to the database. There may be a shared database used by multiple digital entities (D-XXs). These data areas may need to be isolated from each other, and each D-XX may only be able to access the data stored in that module. Furthermore, when data is stored in a publicly hosted network database outside of the HOP, data transfer with other databases can be controlled by the DP GW of the CDM or HOP.

[0588] 6.39. Fault and resilience management functions

[0589] The fault and resilience management function can monitor the performance of each digital entity (D-XX), and if any quality degradation or anomaly is noticed, the function can provide input to the HMF, which can take appropriate action based on the decision-maker's input.

[0590] 6.40. Performance Management Functions

[0591] The performance management function can monitor the performance of individual communication links supporting the operation of D-XX services, as well as the overall quality of D-XX service delivery. If any performance degradation occurs (e.g., failure to meet expected performance such as overall latency), action can be taken to notify the D-XX Manager and HMF.

[0592] 6.41. Resource Management Functions

[0593] Resource management capabilities can be present in both the HOP and each digital entity (D-XX). This may include monitoring and dynamically allocating resources, including memory and bandwidth, to meet the needs of the digital entity.

[0594] 6.42. In-network processing functions

[0595] For the standard processing types required by a digital entity (D-XX), there may be common in-network processing functions. If a digital entity needs to perform a specific type of processing, it may need to create the necessary functions within the module itself, or the HOP may need to provide the D-XX with the software required to create these functions. As discussed in the next section, AI functions can be considered a type of processing. These AI functions can be standard AI schemes or specific types required by the digital entity. Similar to other processing functions, AI functions can be implemented either within the digital entity or within the HOP. The computational resources required for processing functions can be specified in the digital entity design package. Since processing can be dynamic in nature, computational resources may need to be adjusted.

[0596] 6.43. Artificial Intelligence (AI) Functions

[0597] AI capabilities are specific types of processing functions. AI capabilities can be used as general AI enabling functions within a HOP or digital entity to prevent data used by AI solutions from being exposed to the hosted network. These AI capabilities can be used in many services, including, for example:

[0598] - User decision.

[0599] - Supports user applications.

[0600] - To make various services (such as user home control, user mobility prediction, user interest tracking, etc.) operate more efficiently.

[0601] - For D-XX modules other than the D-User module, these modules may require more specific AI functionality.

[0602] It may be necessary to determine a method to train the aforementioned AI functions.

[0603] 6.44. Creating an isolation container for D-Rep of general real objects

[0604] In some embodiments, a method may be provided for creating a HOP within an isolated container within a hosted network. The HOP can be used to create a digital representation (D-Rep) of any real-world entity. A D-Rep can be created as a specific type of digital entity. Therefore, in this document, the D-Rep module is a special case of a digital entity (D-XX). The real-world entity can be any physical object (e.g., a car, a house, a road, etc.). The physical object can be owned, controlled, or managed by another entity referred to as the "customer".

[0605] In-network D-Rep can be used to provide a variety of services to real entities, including, for example, in-network data storage, in-network data processing (e.g., running applications or specific network functions for evaluation, computation, data analysis, and AI schemes), interacting with hosted networks to improve the communication services provided by the hosted networks to real entities, monitoring, obtaining network data for operation, control and management of devices associated with real entities, and providing privacy protection for interactions with external application servers (e.g., data sharing, protocol negotiation, financial transactions, content downloads, search engines, website access).

[0606] An isolated container can be a software container within a managed network computing platform that uses managed network hardware controlled, managed, and orchestrated by a managed network operator (HOP). In this case, the managed network needs to be sufficiently trustworthy in the operations performed on the D-XX module.

[0607] Isolated containers can be created using enclaves within a confidential computing environment (such as a TEE), which can be isolated from the hosting network. The enclave can create HOPs and perform LCM (Limited Module Management) on the functionality within the HOP according to provided instructions. These instructions can be provided to the container manager as design packages for the HOP, which may include, for example:

[0608] - One or more types of D-Rep and its design package that may be created within HOP.

[0609] -Steps or instructions for creating a new type of module-Rep.

[0610] - Common HOP functions and their configuration and association processes.

[0611] - Steps or instructions associated with HMF after HOP creation. For example, establishing secure communication with managed network functions (such as HPCCF, DUCF, DSMF) and the managed network function discovery process, including message passing structures, ingress ports, and egress ports, to use the managed network C / M and DP buses.

[0612] - Instructions or steps associated with the HOP managing function (HMF).

[0613] -D-Rep's resource requirements include storage, compute, and link capacity for different interfaces. Compute resources may include the number and speed of CPUs or GPUs, the percentage of CPU power allocated from the compute engine, and RAM memory requirements. Storage requirements may include storage size and access speed.

[0614] - QoS characteristics (such as latency, packet loss, data rate, etc.) of the link between the D-Rep module and the associated real entity (such as a user, device, etc.). Expected link requirements between the D-Rep module and network functions in the HOP or managed network.

[0615] Methods for creating D-Rep may include identifying the different privacy levels required for D-Rep and the related technical solutions for providing these privacy levels.

[0616] Isolating a HOP can have software such as:

[0617] - Create your own functionalities and prepare interfaces based on the design package provided to HOP, then perform LCM on these functionalities.

[0618] - Download, install, and configure computer programs, AI solutions, and machine learning programs for use by real entities.

[0619] - Manage and control network functions, and allocate resources for various functions.

[0620] Methods for providing privacy protection may include one or more of the following:

[0621] - When interacting with external entities, change the ID of the real entity.

[0622] - When removing from the HOP, the data of the real entity is encrypted and anonymized.

[0623] - Maintaining HOP functionality isolated from the managed network by creating HOPs within a confidential computing environment or TEE, wherein the isolation may include:

[0624] -Prevent the managed network from accessing data within the HOP.

[0625] -Prevent the hosted network from accessing HOP functionality without D-Rep authorization.

[0626] - Prevent the managed network from recognizing external entities that D-Rep can interact with by changing the ID of the real entity within the HOP for outgoing packets and providing the external entity with a random location within the HOP to provide a response.

[0627] Memory 604 may include any type of non-transitory memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof. Mass storage unit 602 may include any suitable type of non-transitory storage device, such as solid-state drive, hard disk drive, disk drive, optical disk drive, USB drive, or any computer program product for storing data and machine-executable program code. According to some embodiments, memory 604 or mass storage 602 may record statements and instructions executable by processor 601 for performing any of the above-described methods.

[0628] It should be understood that while specific embodiments of the technology have been described herein for illustrative purposes, various modifications can be made without departing from the scope of the technology. Therefore, the specification and drawings are to be considered merely as an illustration of the application as defined by the appended claims, and are intended to cover any and all modifications, variations, combinations, or equivalents falling within the scope of this application. Specifically, computer program products or program elements for storing machine-readable signals, or program memories or storage devices such as magnetic wires, optical fibers, magnetic tapes, or disks, are provided within the scope of this technology for controlling the operation of a computer according to the method of this technology and / or constructing some or all of its components according to the system of this technology.

[0629] The operations associated with the methods described herein can be implemented as coded instructions in a computer program product. In other words, a computer program product is a computer-readable medium (a tangible, non-transitory computer-readable medium or memory) on which software code (instructions) are recorded to execute the methods when the computer program product is loaded into memory and executed on a microprocessor of a wireless communication device, network device, or user equipment device.

[0630] Furthermore, each operation of this method can be performed on any suitable computing device, such as a personal computer, server, or personal digital assistant, based on one or more program units, modules, or objects, or a portion thereof, generated from any programming language such as C++ or Java. Additionally, each operation, or the file or object implementing each operation, can be performed by dedicated hardware or a circuit module designed for this purpose.

[0631] Based on the description of the above embodiments, the present invention can be implemented solely in hardware, or it can be implemented using software and a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transient storage medium, such as a compact disk read-only memory (CD-ROM), a USB flash drive, or a removable hard drive. The software product includes numerous instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in the embodiments of this application. For example, such execution may correspond to the simulation of the logical operations described herein. According to embodiments of the present invention, the software product may additionally or alternatively include multiple instructions that enable a computer device to perform operations for configuring or programming digital logic devices.

[0632] Although the invention has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made without departing from the scope of this application. For example, while some embodiments of the invention provide a VUE instantiated within the core network, the VUE may be instantiated within the RAN and have similar functionality. In this case, the control plane and user plane functions for the core network may also be instantiated within the RAN and have similar functionality. Therefore, the specification and drawings are to be regarded only as illustrative of the invention as defined by the appended claims, and are intended to cover any and all modifications, variations, combinations, or equivalents falling within the scope of this application.

Claims

1. A method for creating an isolated hosting platform (HOP) for digital entities (DEs) representing real entities, characterized in that, The method includes the following steps: receiving a request to create a HOP at a managed network function HNF of a managed network HN, the HOP being used to host one or more DEs that require privacy protection for DE data and their associated DE applications; in response to the request, instantiating the HOP in a container within the HN, the HOP including a HOP network function HPF; configuring the HOP and the HPF therein, at least one of the HPFs being able to create DEs in the HOP and allow real entities associated with the DEs to access the DE data and / or the DE applications, while protecting the privacy of the real entities.

2. The method according to claim 1, characterized in that: The DE data includes parameters that define the DE as an entity, and job data associated with the operations performed by the DE application executed by the one or more DEs; The DE applications include at least one of the following: home network applications, AI solutions, user health applications, virtual reality (XR) applications, infrastructure management applications, traffic control applications, data filtering, and data processing.

3. The method according to claim 1 or 2, characterized in that, The real entity represented by the DE includes one of the following: physical processing device, physical user (P-User), P-User access device (UAD), organization, infrastructure, building, one or more network functions, application server, user equipment (UE), UE sensor, and user application.

4. The method according to claim 3, characterized in that, Each of the DEs includes a DE function, and the HPF and / or the DE function can be accessed by the real entity without the knowledge of the HN.

5. The method according to any one of claims 1 to 4, characterized in that, Protecting the privacy of the real entity is performed by preventing the visibility of: real entity data and / or DE data, processing of the real entity data and / or DE data, or execution of specific functions of the real entity from any other entity using the hosting network or from any other external network.

6. The method according to claim 4, characterized in that, Access to the DE functions by one or more DEs is controlled by the HNF.

7. The method according to any one of claims 3 or 4, characterized in that, The DE representing a real entity such as a robot, building, or organization is called a digital representative (D-Rep), and the DE representing a human is called a digital user (D-User).

8. The method according to claim 2, characterized in that, The job data defining the operations performed by the functions of one or more DEs includes one or more of the following: processing input data; modifying input data; forwarding input data or processed data to a specified destination; deleting input data; creating and managing lifecycle LCMs; and resource allocation for other functions.

9. The method according to any one of claims 1 to 8, characterized in that, The HN can be trusted by the entity associated with the corresponding DE.

10. The method according to claim 9, characterized in that, The at least one HNF facilitates access to the one or more DEs for anonymous access to external servers by performing an Identity Management Function (IDMF), wherein the IDMF changes the source ID and / or response address associated with the one or more DEs.

11. The method according to claim 10, characterized in that, Access to the HNF within the HOP is controlled using the gateway GW in the control and management C / M plane of the HN and the GW in the data plane DP of the HN.

12. The method according to any one of claims 1 to 8, characterized in that, The HN is an untrusted network.

13. The method according to claim 12, characterized in that, When the DE processes DE data within the HOP, or when the DE shares DE data with other entities outside the HN, at least one HPF prevents the HN from accessing the DE data.

14. The method according to claim 13, characterized in that, The at least one HPF prevents the HN from accessing the DE data by instantiating the container in a Trusted Execution Environment (TEE), the TEE corresponding to a Confidential Computing Environment (CEE) within the HN, and the container being isolated from the operating system (OS) of the HN.

15. The method according to claim 14, characterized in that, The at least one HPF prevents the HN from tracking the external servers visited by the DE by instantiating the HOP into multiple DE-HOPs that include multiple DEs.

16. The method according to claim 15, characterized in that, The at least one HPF prevents the HN from accessing the operations performed by one or more DEs within the HOP by executing all DE functions within the plurality of DE-HOPs, which are assigned to separate slices of the HN.

17. The method according to claim 14, characterized in that, The HOP is pre-used to create the Hosted Platform Function (HPF) within the TEE and to interact with one or more DEs therein.

18. The method according to any one of claims 14 to 17, characterized in that, The container is an isolated container that runs on the hardware managed and controlled by the HN.

19. The method according to any one of claims 14 to 18, characterized in that, The container is protected by a password key, thereby isolating the container from the operating system (OS) that manages the TEE. The password key is required to access the DE in the HOP hosted in the container.

20. The method according to claim 19, characterized in that, include: The container receives a request for proof from a remote device; the container provides the password key to the remote device based on a unique identifier of the container's contents or functions to prove the authenticity of the container.

21. The method according to claim 20, characterized in that, The user equipment (UE) associated with the real entity verifies the authenticity of the container by providing the password key to an external device, which provides at least one of the container, the contents within the container, and the functionality of the container.

22. The method according to any one of claims 1 to 21, characterized in that, The integrity of the HOP, the DE hosted within the HOP, and the DE application that can be executed within the DE is standardized and certified by a remote certifying entity, and can be verified using its certified signature.

23. The method according to any one of claims 1 to 22, characterized in that, The instantiation and configuration of the HOP are performed by the HOP creation and configuration function HPCCF, which performs one or more of the following: creates the HPF in the container; provides an interface for the HPF; manages the HPF's storage, processing, and communication resources; and performs lifecycle management (LCM) on the HPF within the container according to a set of instructions.

24. The method according to claim 23, characterized in that, Different types of HOPs are associated with corresponding HOP design packages, which are stored in the HN's design package description repository (BDR).

25. The method according to claim 24, characterized in that, The LCM instructions of the HPF are provided as part of the HOP design package.

26. The method according to claim 24 or 25, characterized in that, The HOP design package includes at least one of the following: a description of the HPF, the interface of the HPF, program instructions, configuration attributes, and a description or design package of the supported DE.

27. The method according to any one of claims 23 to 26, characterized in that, The HPF includes the HOP Manager Function (HMF) created within the HOP, which performs the Lifecycle Management Function (LCM) of the one or more DEs and manages communication between the DEs and other entities.

28. The method according to claim 27, characterized in that, The one or more DEs are created in the HOP by the HMF based on a DE design package, the DE design package including at least one of the following: the DE creation instructions, the LCM of the DE, the operation of the DE module, resource requirements, and Quality of Service (QoS) for messaging with the Hosted Platform Function (HPF).

29. The method according to any one of claims 23 to 28, characterized in that, include: The HNF and / or HPF identify the required privacy level for the one or more DEs; the HPF implements the privacy technology associated with the privacy level.

30. The method according to claim 29, characterized in that, The privacy technology includes at least one of the following: changing the identifier of the DE when interacting with external entities; encrypting the data of the DE leaving the HOP; preventing a given DE from accessing the data and internal functions of another DE without the authorization of that other DE; and facilitating communication between the DEs, including using discovery methods, authentication methods, and authorization methods. Prevent the HN or HNF from accessing the DE data within the HOP; Prevent the HN or HNF from accessing the HPF without authorization from the HPF responsible for access control; provide external entities with a random location within the HOP to respond to requests from the DE.

31. The method according to claim 27 or 28, characterized in that, The HMF is used to instantiate the portal when the HN's control plane function CPF or D-Rep service manager function DSMF is requested.

32. The method according to any one of claims 1 to 31, characterized in that, The requests from one or more DEs to HNFs include requests for XaaS functionality.

33. The method according to claim 23, characterized in that, The instantiation and configuration of the HOP by the HPCCF are accomplished using the managed platform installer function HPIF.

34. The method according to claim 7, characterized in that, The one or more DEs include a D-User, at least one function within the D-User is controlled by the user equipment (UE) of the physical user, and at least one function within the one or more DEs provides services to the physical user.

35. The method according to any one of claims 1 to 34, characterized in that, One of the HPFs includes a HOP function orchestrator (HFO) to instantiate additional HPFs within the HOP.

36. The method according to claim 24, characterized in that, The type of HOP to be instantiated is determined based on at least one of the following: the DE type and its associated DE services; the requirements of the DE for a trusted or untrusted network; and the privacy level required for the untrusted network.

37. The method according to claim 36, characterized in that, Instantiating the HOP involves sending a message to the Infrastructure Service Management Function (ISMF) specifying at least one of the following: the HOP category, the requirements of the TEE, the requirements of the HOP, the requirements of the DE to be hosted therein, and the design package of the HOP and the DE.

38. The method according to claim 37, characterized in that, The ISMF requests the HOP's hosting platform creation and configuration function HPCCF creation based on the HOP design package.

39. The method according to claim 38, characterized in that, The HPCCF prepares the final HOP design package to match the HOP requirements.

40. A tangible, non-transient memory recording instructions, characterized in that, The instructions will be executed by one or more processors to perform the method according to any one of claims 1 to 39.

41. A network node, characterized in that, The network node is part of the host network, and the network node includes: a processor; and tangible non-transient memory as claimed in claim 40.

42. A segregated hosting platform HOP for digitally replicating a digital entity (DE) of a real entity, characterized in that, include: Control and management of C / M plane functional modules, including at least one of the following: a C / M gateway for controlling message input and output of the C / M plane functional modules; a C / M plane privacy protection portal (PPP); a HOP manager function (HMF); a HOP internal function orchestrator (HFO); a public C / M network function (NF) for supporting DE module operations; and a data plane DP functional module, including at least one of the following: a public database; PPP; and a managed platform function (HPF) for supporting DE operations.

43. A system that enables a host network HN to provide a confidential digital environment to a real entity for its applications, characterized in that, The system includes: one or more processors; a tangible, non-transient memory storing instructions executable by the one or more processors to satisfy the following: providing a managed platform HOP within a container of the HN, the HOP being created, configured, and managed by the HN; the HOP enabling a real entity to create a digital entity DE representing the real entity within the HOP upon receiving a request from the real entity; the DE including at least one DE function and corresponding resources for performing the at least one DE function; and the HN controlling and managing communication between the DE and the physical entity, and between the DE and other entities outside the HN, to ensure the privacy of the communication.

44. The system according to claim 43, characterized in that, The real entity is capable of performing at least one DE function, and the execution of the at least one DE function is private and not visible to the HN.

45. The system according to claim 43 or 44, characterized in that, The container that provides the HOP is a Trusted Execution Environment (TEE).

46. ​​The system according to claim 45, characterized in that, The Trusted Execution Environment (TEE) provides remote proof to the physical entity to ensure the integrity of the TEE.

47. The system according to any one of claims 43 to 46, characterized in that, The execution of at least one DE function is private and confidential to the physical entity.

48. An apparatus, characterized in that, The device includes a processor and a memory, the memory storing one or more instructions executable on the processor, which, when executed, enable the device to perform the method according to any one of claims 1 to 39.

49. An apparatus, characterized in that, The apparatus includes functions or units for performing the method according to any one of claims 1 to 39.

50. A computer-readable storage medium, characterized in that, It includes one or more instructions, which, when executed on a computer, cause the computer to perform the method according to any one of claims 1 to 39.

51. A non-transitory computer-readable medium for storing instructions, characterized in that, The instructions cause the processor in the device to implement the method according to any one of claims 1 to 39.

52. A device, characterized in that, Used to perform the method according to any one of claims 1 to 39.

53. A processor, characterized in that, Used to execute instructions to cause the device to perform the method according to any one of claims 1 to 39.

54. An integrated circuit, characterized in that, Used to perform the method according to any one of claims 1 to 39.

Images