Mechanism for machine learning enablement

Abstract

A method may include receiving, by a Rule Engine (RE) service, one or more requests to define RE definitions for a Digital Twin (DT) system; communicating with a DT service, a storage service, a machine learning (ML) service, or a combination thereof, according to rules defined in the DT system for processing the one or more requests; and sending, by the RE service, one or more responses to the one or more requests regarding a state, wherein the one or more responses comprise one or more of the following: processing an overall state defined by the RE; individual states for each event condition, action, state and / or state transition specified in the RE definition; and a status for a service interconnect between the RE service and the ML service.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 582,563, filed September 14, 2023, entitled “Mechanisms for Machine Learning Enablement,” and U.S. Provisional Application No. 63 / 582,952, filed September 15, 2023, entitled “Mechanisms for Machine Learning Enablement,” the contents of which are incorporated herein by reference in their entirety for any and all purposes. Background Technology

[0002] Digital twin services A digital twin (DT) is a virtual representation of a physical object or system created using data from sensors, cameras, and other sources. Essentially, a DT is a digital copy of a physical asset, process, or system that allows for real-time monitoring, analysis, and simulation. DT services provide one or more DT-centric capabilities to help devices and applications perform DT-specific operations, such as creating, storing, updating, and discovering DTs. DT services are typically deployed on network nodes such as cloud or edge servers.

[0003] Rule Engine Service A rules engine (RE) service is a service that provides a set of rules to detect and react to events in a system. A rule consists of conditions for an event and any actions taken in response to the event. The conditions for an event are typically specified as expressions that compare two quantities (i.e., operands and a threshold) using comparator operators. One or more conditions can be specified to describe more complex events using logical operators. Operands are typically associated with data from a digital twin. Similarly, actions are specified to describe what is performed in response to the event and can be linked to the data engine (DT) that controls the physical device.

[0004] When the system becomes more complex in nature, RE services can be used to track the system's state. In each state, one or more events and actions can be executed due to different events. State transitions can be specified to link states together. States can represent different operating conditions of the physical system.

[0005] Another common term for RE services is policy engine service.

[0006] Digital twin system The combination of DT (Data Provider) and RE (Resource Provider) services enables the definition of a complete DT system. DTs can be created to provide data and accept actions that can be triggered, and rules can be defined to specify the events, operations, and states of the DT system. Figure 1 An example architecture combining DT services and RE services is shown to enable the creation of DT systems.

[0007] An example is provided to illustrate how to create a DT system using the architecture described above. The comfort of the large conference room is monitored through a DT system that includes temperature and humidity sensors, controls for the heating, ventilation, and air conditioning (HVAC) units, and RE definitions configured by the DT user. The DT is created for the sensing and actuator devices present in the room, and the DT user interfaces with both the DT service and the RE service to define the DT system. A storage server can be used to store information about the DT system, such as data from the DT and rules from the RE service.

[0008] The following definitions of events, actions, states, and state transitions can be defined in one or more rules used to create a DT system. Multiple physical devices can be deployed in a room to provide temperature and humidity measurements; however, for simplicity in this example, only one device will provide the necessary data. Similarly, for simplicity, the DT system has five states to manage room comfort by processing data received from the DT (i.e., events) and performing necessary actions in response to triggered events.

[0009] state: "Normal" status - maintaining the ideal temperature and humidity range.

[0010] The condition is "overheated"—the temperature exceeds the expected range.

[0011] The condition is "too humid" – the humidity level is higher than expected.

[0012] The condition is "overcooled"—the temperature is below the expected range.

[0013] The condition is "too dry" - the humidity is below the desired range.

[0014] event: Event 1: Temperature > 75°F Event 2: Temperature < 68°F Event 3: Humidity > 50% Event 4: Humidity < 30% Event 5: Temperature < 75°F and temperature > 68°F Event 6: Humidity < 50% and humidity > 30% action: Action 1: If event 1 = true, then decrease the temperature. Action 2: If event 2 = true, then increase the temperature. Action 3: If event 3 = true, then reduce humidity. Action 4: If event 4 = true, then increase humidity. State transition: Transition 1: "Normal" -> "Overheating" Transition 2: "Normal" -> "Overcooled" Transition 3: "Normal" -> "Too Humid" Transition 4: "Normal" -> "Extremely Dry" Transformation 5: "Normal" -> "Normal" Transition 6: "Overheating" -> "Normal" Transition 7: "Excessively Cold" -> "Normal" Transition 8: "Too humid" -> "Normal" Transition 9: "Too dry" -> "Normal" Of the definitions above, five describe different room states (e.g., comfort levels), and six events can trigger actions, state transitions, or a combination of both. The expression for each event can reference data input from the DT (Data Center), such as temperature and humidity from the corresponding sensors. Based on the event trigger, actions can be specified to increase or decrease the temperature or humidity. Finally, nine state transitions are defined based on a combination of the current state and the corresponding event. Figure 2 The diagram illustrates the mapping between events and actions and states in the DT system. Figure 3 The state transitions defined for the DT system are shown.

[0015] like Figure 2 As shown, the physical devices represented by DTs are located on the left and right sides of the diagram, while the state of the DT system is located in the center. The DTs on the left can be associated with the physical devices that generate data for the DT system, while the DTs on the right can be associated with the control devices that perform the desired operations. Note that although the control devices are shown separately, they can all be represented by one or more physical devices (e.g., HVAC units). In each of the five states, there are four sub-states, which are associated with actions that increase or decrease temperature or humidity according to event definitions. Note that events 5 and 6 are not necessarily shown because no action is performed as a result of these events.

[0016] Figure 3The diagram illustrates the states and state transitions of a DT system—five states and six events defined for a DT system. Only the defined events are shown in this diagram, and not all events will necessarily lead to a state transition.

[0017] The example above illustrates a very simplified use case for defining a DT system using rules managed by the RE service. Events are defined in a very simple way, involving data from only a few devices. A more complex example of an event involving both temperature and humidity sensors could be as follows: (Temperature < 68°C) and (Humidity < 30%) -> State: Too cold and too dry (Temperature < 68°C) and (Humidity > 50%) -> State: Too cold and too humid (Temperature > 75°C) and (Humidity > 50%) -> State: Overheated and excessively humid (Temperature > 75°C) and (Humidity < 30%) -> State: Overheated and excessively dry The above definition may require introducing new states beyond the original state definition. If additional inputs are added, such as the presence and number of people in the room, the outdoor weather, the presence of windows, etc., the event definition becomes even more complex, requiring the definition of even more states. It can be seen that as the dimensionality of the system increases, the complexity of defining events, actions, states, and state transitions rises dramatically, and in some cases, becomes virtually impossible. Furthermore, defining such complex systems with explicit rules / policies can be error-prone and introduce conflicting definitions. Therefore, it can be advantageous to replace the definitions of events, actions, states, and state transitions with machine learning models (which can be trained to handle higher dimensions of the problem).

[0018] ML services Due to the widespread adoption of machine learning, ML services are provided to simplify ML capabilities and make them easily accessible to users interested in creating ML applications. Machine learning pipelines can be created to streamline ML development, and these pipelines can consist of data collection, data cleaning, data transformation, feature engineering, data labeling, model training and validation, model deployment, and model monitoring. ML pipelines can also be used to train ML models using prepared data and deploy the trained ML models for inference.

[0019] To date, the services used to create DTs, configure rules and policies to mimic physical processes, and train ML models have all existed as individual cloud services accessible to users. DTs bring numerous benefits to physical world systems and environments through intuitive real-world interaction with digital systems, such as real-time monitoring and analysis, effective problem detection and mitigation, simulation, and testing. However, due to the diverse nature of the services offered by CSPs, creating a system that incorporates DTs, rule engine configuration, and trained ML models is quite challenging without a deep understanding and expertise in the various services offered.

[0020] Therefore, it can be said that current DT services from cloud service providers offer relatively fixed and rigid mechanisms for defining DT systems, where RE services provide potential mechanisms for actions and interactions between / within DTs, which need to be explicitly defined. However, including ML services as tools to replace rules for managing DT systems has the potential to provide additional actions / interactions with higher dimensions than existing RE services. Furthermore, existing rule engine configuration mechanisms are manual and cumbersome to define for larger, more complex systems. Therefore, the primary motivation associated with enhancing and / or replacing rule engines using ML-driven approaches is to support higher-dimensional processes that may be infeasible for rule engine-based services. Summary of the Invention

[0021] This paper describes a mechanism for managing complex physical systems using digital twin systems by leveraging multiple service components. The proposed mechanism enables users / applications to create intelligent DT systems by interoperating with rule engine (RE) services with machine learning (ML) and DT services, thereby enabling the creation of complex, high-dimensional processes within the DT system.

[0022] In one aspect, the approach of ML-enabled RE services can be to: receive one or more requests to define RE definitions for a DT system. RE definitions can include rules that specify the event conditions, actions, states, and state transitions of the DT system. In some cases, one or more ML policies and service connector identifiers can be specified to replace the rule elements (event conditions, actions, states, state transitions) with ML models, which can be trained or untrained. In some cases, service connectors can define how to interface with external services and include one or more of the following: service connector identifier, ML policy identifier, service connection identifier, service name, service API, input connector information, interoperability, and output connector information.

[0023] The method may further include: communicating with one or more of the DT service, storage service, and ML service according to rules specified for the DT system. The method may further include: sending one or more responses to one or more requests regarding state, the responses including one or more of the following: processing the overall state defined by the RE; individual states for each event condition, action, state, and / or state transition specified in the RE definition; and states for the service interconnection between the RE service and the ML service.

[0024] This summary is provided to introduce the selection of concepts in a simplified form, which will be described below in detailed description. This summary is not intended to identify the principal or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that address any or all of the shortcomings mentioned in any part of this disclosure. Attached Figure Description

[0025] Figure 1 The architecture of the DT system is described; Figure 2 The actions triggered by the example DT system event are described; Figure 3 The state transitions of the example DT system are described; Figure 4 The architecture of an ML-enabled DT system is described; Figure 5 An example process for creating an ML-enabled DT system is described; Figure 6 It describes the rules for replacing event definitions and actions with ML models; Figure 7 The rules for replacing events and state transitions with ML models are described; Figure 8 The rules for replacing states with ML models are described; Figure 9 An example of a RESTful resource is described; Figure 10 A graphical user interface (GUI) system state diagram is depicted; Figure 11A An example communication system is described, in which the methods and apparatus described and claimed herein may be one aspect; Figure 11B A block diagram depicts an example device or apparatus configured for wireless communication; Figure 11C A system diagram of an example radio access network (RAN) and core network is depicted; Figure 11DA system diagram of another example RAN and core network is depicted; Figure 11E A system diagram of another example RAN and core network is depicted; Figure 11F A block diagram of the example computing system is depicted; and Figure 11G A block diagram of another example communication system is depicted. Detailed Implementation

[0026] This invention describes a mechanism for connecting DT (Data Technology) services, rule engine services, and machine learning service interfaces, thereby enabling the creation of more complex and intelligent DT systems. The emergence and widespread adoption of ML capabilities can further enhance and even replace current rule engines, which may be too complex to be specified, especially for systems requiring higher dimensions. Data from DT can be routed to pre-trained ML models trained to simulate the expected behavior of the DT system. Figure 4 An example architecture for an ML-enabled DT system is shown. Note that, as is well known, the term "RE service" can be used for both the rules and / or policy engine services described earlier.

[0027] Figure 4 The architecture shown illustrates a simplified view of an ML-enabled DT system, which begins with sensor devices generating data for the system, storing and digitally representing the data associated with the sensor devices, processing that data using RE and / or ML services, sending commands to the DT representing a control device (which can perform the desired actions), and the DT user configuring and controlling the system. Note that this diagram is for illustrative purposes only, showing one entity for each component of the DT system. Real-world DT systems can include many physical devices, far more numerous than those shown in the diagram.

[0028] The digital representation (DT) of a physical system can be implemented within a DT service, which is part of a cloud or edge platform. Within this platform, other services may exist, such as RE services, storage services, and ML services. These services can operate independently of each other, and interface connections between and within services may require API calls that link these services. For interactions between RE and ML services, service connectors may need to be defined as additional processing, and / or coordination between services may be required. For example, data from the DT may be processed before being passed to the ML model, and data from the ML model may need to be enumerated and / or scaled before being saved to the DT. It's also important to note that services can be owned by different service providers, which may necessitate more complex interoperability between services.

[0029] Figure 4 The interaction between DT (Data Technology) services, rule engine services, storage services, and machine learning services is emphasized. A DT system can be created using the definition of DT to represent physical devices, policies managed by RE (Relational Engine) services, storage services for storing data within the DT system, and ML (Machine Learning) models for simulating the complex operations of the DT system. Service connector functionality can be used to connect, interface, and interoperate between RE and ML services. One or more physical devices can be associated with a virtual representation created in the DT service, thereby providing data to the DT system. Physical devices can generate data, such as data from sensors, or they can be control (i.e., actuator) type devices for which instructions can be sent to perform actions (e.g., turning a switch on / off, or a valve on / off). Once the data is available in the cloud or edge platform, one or more events can be triggered for evaluation via the RE service. Additionally and / or alternatively, ML models can be used in conjunction with one or more rules and / or supersede these rules to simulate the behavior of the physical system within the DT system.

[0030] Data from the Data Transmission (DT) system can be provided by periodically sending data from physical devices to the corresponding DTs, which can trigger one or more rules for evaluation. Rules can lead to the execution of one or more actions, which may involve updates to one or more DTs. The Reality Service (RE) is used to define events and conditions that govern the behavior of the physical system through interactions with the DTs. For complex operations, one or more Machine Learning (ML) models can replace one or more rules. Service connectors are used to interoperate between RE services and ML services, enabling the replacement of rules with ML models. For example, data provided by the DTs may not be in the format required by the ML model, and may need to be processed through interoperability before the ML model can use the data.

[0031] DT system can be composed of Figure 4 The architecture shown is created to simulate process flows (such as factory assembly lines) or real-world hazardous environments (such as industrial building sites). DT users can begin by creating virtual representations of physical entities in a cloud service platform, then interconnecting DTs to form an entire system. Users can then configure rules and policies to simulate interactions between and within DTs in the virtual system based on the behavior of physical entities. However, for some real-world processes, DT users may find it easier to integrate trained machine learning models representing DT interactions and process flows compared to configuring explicit rules and policies. Figure 5 An example of the process of creating a DT system containing a trained machine learning model is shown.

[0032] The diagram is divided into four main processes: creating the DT system, defining rules for the DT system, updating the rules using a trained ML model representing the operational aspects of the DT system, and possibly retraining the ML model. DT users can begin by creating a DT to represent the components of a physical system, training an ML model to simulate the operational aspects of the system, and configuring rules and policies for the system. When configuring rules and policies, DT users can integrate the trained ML model to replace the rules and policies for complex operations, enabling faster deployment of the DT system.

[0033] Once the Data Transmission (DT) system and its operational aspects are created, the system can be deployed to simulate the operation of the physical system. Data from physical devices can be passed to the DT, and rules / policies and / or ML models can simulate interactions between and within DTs. If an interaction results in a command being sent to the actuators of the physical device, the DT associated with those actuators is updated, and the command is sent to the physical device to execute the action.

[0034] During the operation of the DT system, the RE service can detect discrepancies between the output of the ML model and the expected data for the DT. For example, the ML model might output values ​​to the DT that are outside the typical range, or that could cause physical equipment malfunction. The RE service may be able to detect anomalous or unexpected events and store a collection of input and state information associated with the unexpected or unexpected output from the ML model. This information can be provided to the ML service, which can notify the DT user of the anomalous event. The DT user can acknowledge the notification and can even trigger the retraining of the ML model by providing the updated ground truth value of the event. Finally, the RE service can provide the DT user with periodic or event-driven notifications of the status updates for the operation of the DT system. These status updates can be displayed on a dashboard for the DT user to view and monitor.

[0035] Step 1: Based on the requirements of the DT system, DT users can create DTs using the DT service to represent components of the actual system. Each DT can be defined using the definitions shown in Table 1, thus providing not only information about the collected and stored data, but also information about its relationships with other DTs and the commands that can be executed by the DT. DTs can be assigned identifiers and names to make them unique and addressable within the DT service, and can include descriptions to provide context for the benefit of other DT users.

[0036] Table 1 – Definition of Digital Twin .

[0037] Data stacks (DTs) can be created based on the hierarchical structure of a physical system (e.g., rooms and floors of a building) or based on process flows (e.g., different locations in a supply chain operation). Information about the data that a DT can collect and store (such as data type, scope, format, units, update frequency, etc.) can be provided. Equipment information, such as manufacturer, equipment model and serial number, hardware and software versions, can also be provided and stored in storage services.

[0038] A DT user can initiate the creation of a DT, or a physical device can be configured and / or triggered to initiate the creation of a DT using the DT service. Information about the DT, such as that shown in Table 1, can be stored in a storage service hosted on a cloud or edge platform. In this step, information about the DT and its relationships within the DT system can also be configured for the RE service. The RE service can link DTs together using relationship parameters. Note that the links that can be executed in this step can be logical and do not have significant functionality, such as displaying a logical connection between one DT and another in a dashboard display.

[0039] Step 2: Individually, DT users can train ML models using the capabilities provided by the ML service. Training can be structured to learn certain behaviors required by the components of the DT system. Training data can be collected from actual physical devices, or it can be synthetically generated based on results that actual devices can produce. In the latter case, the DT system can represent a simulation model of the actual system being designed and developed. Synthetic data can be generated based on product requirements, historical data from similar types of devices, and / or specifications from different devices within the system for different operating conditions.

[0040] In addition to training the ML model, DT users can create ML policies to provide information about the ML model, the trained ML algorithm, training data, data preparation steps required for inference on real-time data before it is input into the ML model, and other relevant information available when interfacing the ML model with the DT system. A key aspect of this information is the service connectivity information shown in Table 2. This service connectivity information, provided by the DT user, describes how the ML model can be connected to the DT system, specifically API calls used to coordinate and configure the operating environment to access the ML model. API calls are available to initially establish the operating environment in which the ML model operates, and another API call is available to enable and configure the ML model. API calls can exist as a list of instructions for interoperability services to coordinate the operating environment, such as creating a virtual machine and running the ML model. Furthermore, information about input and output connections between the ML model and one or more DTs within the DT system can be provided. The connectivity information can also include data processing requirements for connecting the DT to the ML model / connecting the ML model to the DT, such as data preparation, data cleaning, data scaling, data transformation, data enumeration, etc. Note that connectivity information can be bidirectional, such as data processing requirements at the input and output of an ML model.

[0041] Table 2 – ML Strategy Information .

[0042] Information elements regarding ML models may include: the type of ML algorithm, such as supervised ML, unsupervised ML, classification ML, regression ML, reinforcement ML, etc.; and the specific algorithm (random forest, SVM, Naive Bayes, etc.). The specifications of ML models and ML pipelines may contain many other elements, such as hyperparameter optimization parameters (for the algorithm), data preparation requirements, feature engineering, etc. Other important aspects are the various dependencies / requirements of the ML pipeline, including OS, hardware requirements (CPU, GPU, memory, number of compute nodes, etc.), software dependencies (language, libraries, and their versions), security, compliance, scalability, continuous improvement, etc.

[0043] When integrating ML models with components of a DT system, service connectivity information can be used by RE services. Operating environment information elements can reference scripts that are first executed to start a virtual machine or container, thereby running the included ML model, and API references can be URIs pointing to a list of instructions that are invoked to access the ML model once the operating environment is running. Additionally and / or alternatively, the operating environment and API references can be combined as a list of instructions for interoperability services to coordinate and run the ML model. Input information can provide identifiers of the input characteristics required by the ML model, as well as the required data format and value range for each input. Similarly, output information can provide information about the format and value range used by the ML model's output. An interoperability function list can also be used to connect to the inputs and / or outputs of the ML model.

[0044] At the end of this step, multiple models can be used to integrate into the DT system. Note that the ML model can be trained and manipulated while the DT system is defined iteratively. The ML model can even be trained before the DT system is specified and created, for example, as part of adapting to the requirements of different DT systems used in the current DT system. Therefore, steps 1 and 2 can be performed in any order, or even simultaneously.

[0045] Step 3: DT users can send one or more requests to the RE service to create one or more ML-enabled rules for the DT system. Each ML-enabled rule can include a set of rules defined by the DT user. These rules can specify events that occur within the DT system, and these events can cause actions performed by the RE service, such as operations performed by the RE service on DTs within the DT system. These rules can also specify the state and state transitions of a process flow that can occur within the DT system based on events occurring under that state. Based on this state information, the rule engine can execute a set of conditional sequences involving actions on DTs within the DT system. An event can consist of the following: a condition triggered in response to a change in data being updated in the DT representation, and the action performed thereafter. Table 3 shows an example of an RE definition. Each RE in the DT system can have ML capabilities, including an ML policy identifier and a service connector identifier.

[0046] Table 3 – Definition of DT System Rule Engine Enabled by ML .

[0047] After defining the DT of the components of the DT system in Step 1, the RE can be created and defined, or during the definition of the DT system, the RE can be created and defined as part of Step 1. The definition of event conditions, actions, states, and state transitions can be implemented using traditional REs, where updates to the data in the DT can cause one or more events to be triggered and cause any resulting actions to be executed. As an alternative to using traditional REs, the DT user can interface with a trained ML model to replace user-defined event conditions, actions, states, and state transitions.

[0048] The RE service can create RESTful resources locally to store the DT system RE definitions provided by the DT user. The DT system identifier and / or the RE identifier can be assigned to the resources and returned to the DT user in the response message, such as in Step 5. The DT user can use the DT system identifier and / or the RE identifier in future requests to update the configuration of the DT system RE definition stored in the resources.

[0049] An expression can be specified for the condition of an event, where the value of the operand is based on data provided by one or more DTs in the DT system. The data from the DTs can be represented by a URI or one or more identifiers. For example, / / data / pressure can be a URI identifying a resource that contains data on the pressure provided by a physical device, whose DT identifier is specified as DT1. Additionally and / or alternatively, the following identifier can also be specified: DT1.data.pressure. Note that the example provided shows a simple hierarchy; more complex hierarchies can also be envisioned. For example, / DT1 / floor 1 / pipeline 2 / data / pressure shows two additional levels of hierarchy compared to the previous example.

[0050] To complete the expression for an event, comparison operators (such as >, <, =, >=, <=, / =, etc.) can be used to compare the operand with a threshold. Logical operators, such as AND, OR, and NOT, can also be used to combine multiple expressions to create more complex events. Multiple expressions can identify events that depend on multiple inputs, such as data from multiple DTs. As more inputs are added to the event, the expression may become more complex and may be difficult to understand and / or describe what the event is capturing. In such cases, the DT user may prefer to use a trained ML model to replace the need to specify all the individual expressions for complex events. Compared to complex expressions for events, a trained ML model may be more likely to capture the contributions of different inputs and the range of their values.

[0051] In the DT system RE definition shown in Table 3, ML strategies (such as those defined in step 2) can be specified to identify the trained ML model. This ML model, along with the associated strategy, can be used to enhance and / or replace the event conditions, actions, states, or state transitions of the RE. Within the ML strategy, service connections may be specified to provide information about how data is connected from the DT interface to the ML model, such as data processing between services. Service connection information can be used to derive and create service connectors to interface RE services with ML services and vice versa. Table 4 shows an example of a service connector definition that can be specified to provide interconnection information between the DT and ML models.

[0052] Table 4 – Definition of ML-enabled RE service connectors .

[0053] Machine learning models can be pre-trained and ready to produce inference results, or they can be connected to a DT system and trained using data from the DT. ML service APIs can be exposed to DT services through service connection information found in ML policies, and service connector capabilities can be used to interconnect DT services with ML services.

[0054] A service connector definition may include the information required for input connections between the DT system and external services (such as ML services), any interoperability that may be required to process data from the DT to meet the input requirements of external services (such as ML models), and output connections from external services to the DT system.

[0055] When connecting to external services, certain prerequisite operations may be required before performing actual ML operations (such as inference and / or training). These prerequisite operations can be specified using service API information elements. The service API can reference an interworking service that performs the necessary operations to set up the environment for ML model operations. For example, the interworking service can coordinate the virtual machine with the relevant ML packages required for ML model operations. Additionally and / or alternatively, the interworking service can coordinate and load a previously saved state of the VM to continue from the previous state of the ML model. Furthermore, the interworking service can save the state of the VM after a series of events have completed in the DT system and pause the VM until the next time the ML model is needed.

[0056] Step 4: The RE service can communicate with the DT service, storage service, and ML service to process the requests received in Step 3. For each DT referenced in the information elements of the RE definition described in Table 3, the RE service can subscribe to receive notifications of changes or updates to the DT data, or retrieve the DT data from the storage service (if the DT data is already stored in the storage service). Similarly, for references to ML policies, the RE service can use information about service connections for the ML policy, as well as service connector information in the RE definition, to interconnect the DT service with the ML service (and with the storage service, if applicable).

[0057] Step 5: Based on the processing results of Step 4, the RE service can return a response indicating the creation status of the ML-enabled RE. The response may include the overall status of processing the RE definition, as well as the individual status of each event condition, action, state, and / or state transition specified in the RE definition. Additionally, the status of the service interconnection between the DT service and the ML service can be provided. If a status regarding fault indication exists, the cause of the fault can also be provided. Errors may occur during service connections between the RE service and the ML service, and these errors can also be returned to the DT user. One or more identifiers may also be returned in the response as references to (multiple) related items, such as the DT system, the RE, and the service connector.

[0058] Step 6: If Step 5 is successfully completed, the DT system RE can be fully specified based on the functionality from the ML model, which replaces certain events, actions, states, and state transitions. The RE's operation information element can be configured as "Enable Operation". If the ML model is to be trained in the DT system, the operation IE can be configured as "Train". The device can provide data to the corresponding DT, and the operation or training of the DT system RE can begin.

[0059] Step 7: The RE service can monitor and detect updates to the DT in the DT system and process appropriate events, actions, and / or state transitions according to the RE definition. For cases involving ML models, the RE service can access service connectors to route DT data to the appropriate interoperability functions, thereby processing the data before passing the results to the ML service and the specified ML model. The (processed) data obtained from the interoperability functions can be stored in storage services for future use, such as for (re)training or updating the ML model.

[0060] Step 8: The ML model can generate output based on the received input, and the ML service can provide the output to the appropriate service connector functionality, where the data can be processed according to the output requirements specified by the output connector information (e.g., enumeration, scaling). The resulting data can be routed back to one or more DTs via the RE service and / or the corresponding service connector. The output from the ML service can be stored in the storage service for future use, such as for (re)training or updating the ML model.

[0061] Step 9: The output data from Step 8 (which can cause the physical device to perform an action) can be forwarded from DT to the physical device.

[0062] Step 10: For certain combinations of the input data provided in Step 7 and the output data generated in Step 8, the RE service can detect any anomalous or unexpected actions taken. For example, an error may have existed, indicated by one of the service connectors processing the output received from the ML service. As another example, in Step 9, a command may have been sent to a physical device, which could lead to an error. In these cases, the RE service can collect data from Steps 7 and 8 and send a message to the ML service indicating that an error or other undesirable behavior has occurred in the DT system. The message may include additional information about the error / abnormal behavior (e.g., the location of the error and its possible cause) and indications that retraining may be necessary to update the ML model. Alternatively, the RE service can send this information directly to the DT user using the data generated in Steps 7 and 8. The RE service may also store the data, along with indications that the data generated anomalies and / or unexpected behavior, in a storage server.

[0063] Step 11: The ML service can send a notification to the DT user based on the feedback received from the RE service. As part of the notification, the ML service can provide input data to the ML model, such as the data received from the DT service, and include the corresponding output generated by the ML model. The ML service may also include the information provided by the RE service in step 10.

[0064] Step 12: The DT user can send a confirmation back to the ML service (or RE service) and decide whether to enable retraining of the ML model. If retraining is requested, the DT user can provide ground truth labels to correlate with the data received from the DT service. The DT user can also process any input data that may not conform to specifications. For example, the DT user may notice a forced input missing or an incorrect value. Missing input values ​​may indicate that the physical equipment may be malfunctioning, and therefore no data is being provided to the DT representation. Incorrect data values ​​may indicate a problem with the interoperability that processes the data. For example, values ​​from the DT may not be properly scaled, which can cause interoperability to corrupt the data. Alternatively, the user can choose not to retrain the ML model.

[0065] Step 13: If the DT user makes a request, the ML service can retrain the ML model based on the input data received from the DT user and the ground truth. The ML service can then send the retrained results to both the DT user and the RE service. The ML service can also store the retrained data in its storage service.

[0066] Step 14: Periodically or through event triggering, the RE service can notify DT users of the status of the DT system. Notifications can highlight events captured since the last notification was sent. If a significant event occurs, such as retraining or an error in the DT system, the RE service can include additional information for the significant event, such as DT values, events, states, and state transitions. The RE service can also include information about service connectors, interoperability, and VM status. This additional information can be stored in the storage service, and DT users can be provided with identifiers to retrieve the information.

[0067] The mechanism specified in step 10 for detecting anomalous operation or errors reported by the service connector is inherently reactive. For a more proactive approach, rules can be created as part of the RE definition created in step 3 to detect certain events that may occur and report such events to the DT user. Rules can be specified so that certain combinations of input data from the DT can trigger notifications to the DT user and / or retraining of the ML model. Additionally and / or alternatively, ML models specifically designed to detect anomalies in the system can be deployed at various junctions of the DT system to report anomalous or unexpected behavior to the DT user and can even be configured to retrain (multiple) ML models. The ML model may also be able to detect data drift in the system and trigger retraining when appropriate. The ML model can be inserted as the state of the DT system to monitor its operation and report any events and / or errors detected by the ML model after training.

[0068] Figure 5 The created DT system describes an example deployment where the components of the DT system are created independently. In steps 1 and 2, the DT and the ML model are created by their respective services. Then, in step 3, RE definitions are created to complete the operational aspects of the DT system, where data from the DT is connected to the ML model using a service connector. The ML model has been previously trained, so the system can begin operation once the services are connected.

[0069] In addition to the deployments described above, other deployment scenarios can be envisioned where the data created in step 1 (DT) can be used to train the ML algorithm / model specified in step 2. Data collection, data preparation, and ML training can then be performed in steps 6 through 13. In this case, the ML model is not trained, and the RE definition provides connection information between the DT and the untrained ML model. Then, when the data becomes available in step 6, the rule engine service and interoperability can work together to process the data from the DT for use in training the ML model. In this case, step 9 can be skipped when the training process is active. In step 10, the RE / ML service can decide to collect a batch of data and then prompt the DT user with ground truth data in step 11. Steps 11 and 12 can be data annotation steps concerning the DT user, machine-synthesized ground truth data, data annotation services, or a combination thereof. Once all or part of the dataset is available, training can begin from step 13. Note that training can also be divided into multiple batches as part of general ML training and / or hyperparameter optimization.

[0070] Another possible deployment scenario is that the RE definition can initially be created in step 1 when the DT is created. In this case, step 1 can generate a fully operational DT system, where operations are determined by the RE definition. A large number of events, actions, states, and state transitions can be specified to comprehensively describe the operation of the DT system. However, the RE definition can be quite complex and difficult to manage. Therefore, an ML model can be trained to replace certain aspects of the RE definition, thereby simplifying the specification of the DT system. As the ML model becomes available, step 3 can be repeated to update the RE definition accordingly.

[0071] Previously, it was described that DT (Digital Technology) systems could be created to monitor and maintain the comfort of large conference rooms based on defined rules managed by RE (Relational Environment) services. In the following sections, an ML-enabled DT system is proposed to enhance existing rule-based DT systems, thereby addressing higher-dimensional problems than those initially described. ML models can introduce more complex events to handle a wider range of inputs than previously used. For example, inputs such as time of day, season, room size, number of people in the room, number of windows, weather forecast, and sun direction can also influence room comfort. Developing explicit rules to incorporate all of these inputs into explicit event definitions can be very difficult. Therefore, it is suggested that ML models can be trained to consider multiple inputs and the desired outputs for the problem, and these models can be used to replace the event conditions, actions, states, and state transitions defined by RE to consider higher dimensions of multiple inputs. RE services can interoperate with ML services to provide seamless operation between services using service connectors.

[0072] ML replication of rules regarding event conditions and actions Figure 5 The created DT system demonstrates an example implementation of interoperability between services, such as interoperability between RE, DT, and ML services. Within the RE definition, mechanisms can be provided to allow DT users to replace event conditions, actions, states, and state transitions with ML models, which can be trained to replace the underlying event conditions, actions, states, or state transitions.

[0073] Figure 6 An example is shown where the conditions and / or actions of an event can be connected to the input of an ML model. Note that while the diagram only shows one event condition and one event action, there may be multiple event conditions and actions that can be connected to the input of the ML model. Also note that data from a Data Dependency Injector (DT) can be a source of information for defining event conditions and actions, and data from a DT can be forwarded to another DT to perform the desired action. Additionally and / or alternatively, actions from the output of the ML model can be forwarded to another DT for further processing, such as triggering (multiple) events in another DT.

[0074] Figure 6Interworking between the RE service and the ML service using a service connector is also shown. As described above, the ML policy may include service connection information regarding requirements for interworking of an external service with a (plurality of) specific ML models associated with the ML policy. Using this information and the service connector information found in the RE definition, this can allow the two services to interwork with each other. The service connector information can be used to specify input and output data requirements and the interworking functions that may be required for the services to work together. The interworking functions can process the data from the DT into a suitable format that will be recognized by the input of the ML model. Similarly, interworking functions may be required to process the output from the ML model into a format suitable for the DT that is receiving the data. The interworking functions can be part of the ML service or can be part of a data preparation service independent of the ML service.

[0075] Using the room comfort use case as a basis, the event conditions and actions can be specified as: Room.State1.EventA.Condition: Room.DT1 > 75 and Room.DT2 > 50 Room.State1.EventA.Action1: If EventA.Condition is true, then set Room.DT3 to on Note that Room.DT1 (temperature), Room.DT2 (humidity), and Room.DT3 (HVAC control) are references to the data stored in the DT. EventA can be an event that includes the conditions and actions defined for State1 (in this case, which represents the "normal" state). To connect EventA to an ML model, the event conditions and actions can be specified as: Room.State1.EventA.Condition: serviceConnectorID (<ML service name>, <mlmodelapi>, <inputConnector(Room.DT1, Room.DT2), interworkingFunctions()) Room.State1.EventA.Action: serviceConnectorID(<ML service name>, <mlmodelapi>, outputConnector(Room.DT3), interworkingFunctions()) The serviceConnectorID can be used to indicate the operational environment information required to connect to an external service identified by a service name. The ML model API can specify which ML model the service connector applies to. The InputConnector and outputConnector can respectively identify the input and output mappings between services, and the interworkingFunctions can provide a list of processing functions that can be performed on the input and output data to / from the ML model, RE, and DT to seamlessly interface the services together. For example, DT1 may need to convert from °F to °C, and DT2 may need to scale between 10 and 80, and then pass the input to the ML model. The previous example of EventA can be revised to: Room.State1.EventA: serviceConnectorID(<ML service name>, <mlModel API>, inputConnector(inputA, inputB), interworkingFunctions(f2cFunc(Room.DT1, inputA), scaleFunc(Room.DT2, range(10,80), inputB))) In the revision, two interworking functions (i.e., f2cFunc and scaleFunc) have been specified to receive the input from the DT in order to process the data before sending it to the ML model. The functions can be specified as part of the operational environment of the ML model and can be retrieved and installed as part of the initialization of the virtual machine used to run the ML model. Then, the output from the interworking functions is sent as input to the ML model. Note that new signaling names (i.e., inputA and inputB) have been introduced to connect between the interworking functions and the ML model.

[0076] ML replication of rules regarding events and state transitions For some operational aspects of a given RE, the rules for events or state transitions from one event to another can be replicated using an ML model. For higher-dimensional rules (where multiple inputs may be involved or there are multiple conditions for state transitions), it may be easier to create and train an ML model to consider the higher-dimensional inputs and state transitions than to specify explicit rules. Figure 7 An example is shown where rules for events and state transitions can be replaced with trained ML models that capture the same functionality as explicit rules. The presence of the service connector is again shown to demonstrate the interoperability functionality that may be required for the RE service and the ML service to work together.

[0077] For this scenario, the DT system is more complex and now has four inputs to monitor: temperature, humidity, the number of people present in the room, and the time of day. With the added inputs, the ML model can be trained to consider additional factors that may affect the comfort of the room. Specifying explicit rules may make incorporating the contribution of each input more cumbersome. Instead, the ML model can be trained to consider the four inputs as factors based on the data generated, for example using historical and / or synthetic data. For example, the ML model can be trained to turn on the HVAC system even if the temperature has not exceeded the upper limit (e.g., 75 degrees) because there are a lot of people in the room and the time is early afternoon. Then, the ML model can replace one or more events and indicate the actions to be performed and the state transitions to be made. An example of a service connector could be: Room.State1.EventA: serviceConnectorID (<ML service name>, <mlModel API>, inputConnector (Room.DT1, Room.DT2, Room.DT3, Room.DT4), outputConnector (output1->Room.DT3, output2->mlTransition1)) Room.State1.Transition: mlTransition1 In this case, the event conditions and actions are completely replaced only by the reference to EventA. The specified service connector uses location notation for the inputConnector to connect data from the DT (e.g., DT1, DT2, DT3, and DT4) to the ML model (e.g., to input1, input2, input3, and input4 respectively). The outputConnector connects output1, which generates the action, to DT5. Output2 is the output of the ML model associated with the state transition connection, which is named mlTransistion1 and is connected to Room.State1.Transition. The explicit mapping notation in the outputConnector makes it easier to distinguish between the two outputs that connect to different aspects of the DT system.

[0078] ML replication of rules regarding state In some cases (i.e., where the state can be associated with multiple events and actions and with high dimensions), it may be very cumbersome or even infeasible to define rules that fully simulate the functions associated with such complexity. For these cases, an ML model can be trained to replace the complex state and / or multiple states. In fact, if the ML model is trained to replicate the specific operations of a DT system, the ML model may be able to replace one or more states in the DT system. Figure 8 An example of the case where an ML model replaces multiple states is shown.

[0079] Using the room comfort example again, an ML model can replace one or more states to incorporate the predictive capabilities available to the ML model. Using Figure 8 As a reference, State 1 can include the previously defined temperature (DT1) and humidity (DT2) rules. On the other hand, State 2 can include the predictions that the ML model can provide by actively turning on or off the HVAC system after being trained. DT4 can represent the date and time, DT5 can represent the schedule of events with set times, and DT6 can represent the number of people for each event. One or more ML models can be trained to provide predictions to actively manage the comfort of the room. As an example, the (multiple) ML models can receive the information that an event will start in five minutes, with a large number of people expected to attend. Additionally, the ML model may have noticed that the temperature has been trending towards the upper threshold. Based on its training, the ML model can actively turn on the HVAC system as a preemptive action before the temperature in the room reaches an uncomfortable level. The ML model can also be trained to distinguish various levels of comfort, so that 69 degrees to 71 degrees can represent optimal comfort, while 72 degrees to 75 degrees and 65 degrees to 68 degrees are comfortable, but actions may need to be determined based on other factors. Therefore, the ML model may be able to capture a finer level of granularity than explicit rules, while providing predictive factors that explicit rules cannot provide.

[0080] The replacement of multiple states may require explicit mapping of the inputConnector, outputConnector, or both. Here is an example where two states of a DT system are replaced by an ML model.

[0081] Room.State1: serviceConnectorID (<ML service name>, <mlModel API>, inputConnector (Room.DT1 -> input1, Room.DT2 -> input2), outputConnector (output1 -> Room.DT3, output2 -> mlTransition1)) Room.State2: serviceConnectorID (<ML service name>, <mlModel API>, inputConnector (Room.DT4 -> input3, Room.DT5 -> input4, Room.DT6 -> input5), outputConnector (output3 -> Room.DT7, output4 -> mlTransition2)) Room.State1.Transition: mlTransition1 Room.State2.Transition: mlTransition2 From the example, the ML model has five inputs and four outputs. The first two inputs (e.g., input1 and input2) originate from the inputs to State1, while the remaining inputs originate from the inputs to State2. Note that explicit mapping connections are made for each service connector. Additionally, no event conditions and actions are referenced as they have all been replaced by the ML model. For this case, the data from DT and the state information of the DT system act as the interface to the ML model.

[0082] Note that the above example shows how the rules of the DT system can be replaced by an ML model, which can be for event conditions and actions, for events and state transitions, and ultimately for a state or multiple states. Each replacement is described separately, but in actual deployment, for a DT system, one or a combination of multiple replacements can be made based on the availability and / or complexity of the ML model.

[0083] RESTful resource examples The ML-enabled DT system functionality proposed in this invention can be implemented through services that support RESTful APIs. In one embodiment, the DT, RE, and / or ML services used to implement the ML-enabled DT system can support RESTful APIs. These APIs can be used by devices, users, applications, and other services to interface with the ML-enabled DT system. For each capability of the different capabilities of the DT, RE, and / or ML services, the RESTful API can support different resource types. Resources can be stored and maintained locally through the DT, RE, and / or ML services. Alternatively, they can be stored and / or maintained elsewhere in the DT system, such as through storage services. Relationships between resources can be established and supported through the services of the DT system. Relationships can be supported by resources that support attributes specifically designed to define the relationships between resources. Alternatively, resources can be stored in a hierarchical structure (e.g., in a tree structure). This hierarchical structure can define the relationships between resources. The resource structure can be divided into hierarchical orders, and examples are shown below. Figure 9 As shown, top-level RESTful resources can be created and assigned to DT systems to store all information about the DT system. Top-level resources can contain collection resources for the DT within the system, as well as system definitions, which can consist of the DT system's event conditions, actions, states, and state transitions. If an ML model is used, ML output resources can also exist to demonstrate the ML model's output and the associated confidence levels. Alternatively, other types of resources and hierarchical structures can be defined for DT systems and services.

[0084] Additional information about the DT system may exist, which can be provided through the DT system identifier resource. A system description can be provided to describe the purpose and operation of the DT system. Information about the number of states and the operational states of the DT system can be provided in the system definition resource. Operational attributes may exist to allow users to specify different operations for the DT system. For example, a user can specify whether the DT system is in configuration mode, training mode, or operational mode. In configuration mode, the user may be designing the DT system and specifying the system's events and states. The DT system can also be in training mode to allow data received from physical devices to train ML models, which are used to simulate the system's operation.

[0085] When an ML model is used to replace event conditions, actions, states, and / or state transitions, ML policies can be added to the resource tree to provide information about the ML model and its corresponding service connections. Additionally, information about service connectors used to interoperate between rules / policies and the ML model can be provided.

[0086] Graphical User Interface Examples A graphical user interface (GUI) can be presented to the user to display the state diagram of the DT system. The GUI can be... Figure 10 The GUI shown here can display various states, with state transitions indicated by arrows from one state to another. Users can select a state and obtain relevant information about it, such as event conditions and actions, as well as possible state transitions.

[0087] Example Communication System The 3rd Generation Partnership Project (3GPP) has developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities—including codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), Advanced LTE, and New Radio (NR), also known as "5G." 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technologies (new RATs), which are expected to include new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new, non-backward-compatible radio access in new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with varying requirements. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. Specifically, Ultra Mobile Broadband is expected to share a common design framework with flexible radio access below 7 GHz through centimeter-wave and millimeter-wave specific design optimizations.

[0088] 3GPP has indicated that NR is expected to support a variety of use cases, leading to diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: Enhanced Mobile Broadband (eMBB) Ultra-Reliable Low-Latency Communications (URLLC), Massive Machine-Type Communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and Enhanced Vehicle-to-Everything (eV2X) communications, which can include any of the following: Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Network (V2N), Vehicle-to-Pedestrian (V2P), and vehicle-to-vehicle communications with other entities. Specific services and applications within these categories include, for example, monitoring and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive emergency call systems, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases, and others, are mentioned herein.

[0089] Figure 11A An example communication system 100 is depicted, in which the methods and apparatus described and claimed herein may be one aspect. As shown, the example communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f and / or 102g (which may be generally or collectively referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 108B, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, Internet 110, other networks 112, and V2X servers (or ProSe functions and servers) 113, although it will be understood that the disclosed examples contemplate any number of WTRUs, base stations, networks and / or network elements. Each of the WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although in Figure 11A-11E In this document, each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted as a handheld wireless communication device. However, it will be understood that, given the diverse use cases envisioned for 5G wireless communication, each WTRU may include or embody any type of device or equipment configured to transmit and / or receive wireless signals, including (by example only) user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, tablet, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robot, industrial equipment, drone, vehicle (such as car, truck, train, or airplane), etc.

[0090] The communication system 100 may also include base stations 114a and / or 114b. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of RRHs (Remote Radio Headers) 118a and 118b, TRPs (Transmit and Receive Points) 119a and 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. RRH 118a and 118b can be any type of device configured to wirelessly interface with at least one WTRU 102c to access one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. TRP 119a and 119b can be any type of device configured to wirelessly interface with at least one WTRU 102d to access one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. RSU 120a and RSU 120b can be any type of device configured to wirelessly interface with at least one WTRU 102e or 102f to access one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. For example, base stations 114a and 114b can be transceiver base stations (BTS), node B, eNode B, home node B, home eNode B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0091] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals in a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or radio signals in a specific geographical area, which may be referred to as a cell (not shown). A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In some cases, base station 114a can employ multiple-input multiple-output (MIMO) technology, and therefore, multiple transceivers can be used for each sector of the cell.

[0092] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115 / 116 / 117 can be established using any suitable radio access technology (RAT).

[0093] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b, which can be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 118b / 116b / 117b can be established using any suitable radio access technology (RAT).

[0094] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 118C / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interface 115c / 116c / 117c can be established using any suitable radio access technology (RAT).

[0095] WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with each other via air interfaces 115d / 116d / 117d (not shown in the figures), which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 118D / 116d / 117d can be established using any suitable radio access technology (RAT).

[0096] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b in RAN 103b / 104b / 105b and WTRU 102c, 102d, 102e, 102f can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can respectively use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0097] In certain situations, base stations 114a and WTRUs 102a, 102b, 102c, or RANs 103b / 104b / 108B and WTRUs 102c, 102d, including RRHs 118a, 118b, TRPs 119a, 119b, and RSUs 120a, 120b, can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA). This technology can establish air interfaces 115 / 116 / 117 or 118C / 116c / 117c using Long Term Evolution (LTE) and / or LTE-A Advanced (LTE-A), respectively. In the future, air interfaces 115 / 116 / 117 can implement 3GPP NR technologies. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communication).

[0098] In some cases, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c, or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b in RAN 103b / 104b / 105b and WTRU 102c, 102d, 102e, 102f, can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Interconnection Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSMEDGE (GERAN), etc.

[0099] For example, Figure 11A Base station 114c can be a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, home, vehicle, or campus. In some cases, base station 114c and WTRU 102e can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 11A As shown, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114c may not need to access the Internet 110 through core networks 106 / 107 / 109.

[0100] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication.

[0101] Although Figure 11A Although not shown, it will be understood that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b which can utilize E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) that uses GSM radio technology.

[0102] Core networks 106 / 107 / 109 may also act as gateways for WTRUs 102a, 102b, 102c, 102d, 102e to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 108B or a different RAT.

[0103] Some or all of the WTRUs 102a, 102b, 102c, and 102d in communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 11A The WTRU 102e shown can be configured to communicate with a base station 114a that can use cellular-based radio technology and a base station 114c that can use IEEE 802 radio technology.

[0104] Figure 11B This is a block diagram of an example apparatus or device configured for wireless communication according to the aspects described herein, such as WTRU 102. Figure 11B As shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It will be understood that WTRU 102 may include any sub-combination of the above elements while remaining consistent with the example. Furthermore, in some cases, base stations 114a and 114b and / or base stations 114a and 114b may represent nodes such as (but not limited to) transceiver stations (BTS), Node Bs, site controllers, access points (APs), home node Bs, evolved home node Bs (eNodeBs), home evolved node Bs (HeNBs), home evolved node B gateways, and proxy nodes, etc., which may include... Figure 11B Some or all of the elements depicted in and described herein.

[0105] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 11B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0106] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in some cases, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In some cases, for example, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In some cases, transmitting / receiving element 122 can be configured to transmit and receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0107] Furthermore, although the transmitting / receiving element 122 is in Figure 11B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in some cases, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0108] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs (such as UTRA and IEEE 802.11).

[0109] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad / indicator 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data therein. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a Memory Stick, a Secure Digital (SD) memory card, etc. In some cases, the processor 118 may access information from memory that is not physically on the WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0110] The processor 118 can receive power from the power supply 134 and can be configured to distribute the power to other components in the WTRU 102 and / or control that power. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell battery packs, solar cells, fuel cells, etc.

[0111] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or in lieu of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the aspects.

[0112] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0113] WTRU 102 may be embodied in other devices or equipment, such as sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, or vehicles (such as cars, trucks, trains, or airplanes). WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0114] Figure 11C This is a system diagram of RAN 103 and core network 106. As described above, RAN 103 can use UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 115. RAN 103 can also communicate with core network 106. Figure 11C As shown, RAN 103 may include nodes B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Nodes B 140a, 140b, and 140c may each be associated with a specific cell (not shown) in RAN 103. RAN 103 may also include RNCs 142a and 142b. It will be understood that RAN 103 may include any number of nodes B and RNCs while remaining consistent with aspects of this disclosure.

[0115] like Figure 11C As shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control its connected node B 140a, 140b, or 140c. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, admission control, group scheduling, handover control, macro diversity, security functions, and data encryption.

[0116] Figure 11C The core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the above elements is depicted as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0117] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via the IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment.

[0118] The RNC 142a in RAN 103 can also connect to the SGSN 148 in core network 106 via the IuPS interface. The SGSN 148 can connect to the GGSN 150. The SGSN 148 and GGSN 150 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0119] As described above, the core network 106 can also be connected to the network 112, which may include other wired or wireless networks owned and / or operated by the service provider.

[0120] Figure 11D This is a system diagram of RAN 104 and core network 107. As described above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with core network 107.

[0121] RAN 104 may include eNode-B 160a, 160b, 160c, although it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with aspects of this disclosure. eNode-B 160a, 160b, 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In some cases, eNode-B 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNode-B 160a may use multiple antennas to transmit radio signals to WTRU 102a and / or receive radio signals from WTRU 102a.

[0122] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink and / or downlink, etc. Figure 11D As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0123] Figure 11D The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0124] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, performing bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0125] Service Gateway 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. Service Gateway 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. Service Gateway 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0126] Service gateway 164 can also be connected to PDN gateway 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0127] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between core network 107 and PSTN 108. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0128] Figure 11E This is a system diagram of RAN 105 and core network 109. RAN 105 may be an Access Service Network (ASN) that uses IEEE 802.16 radio technology and communicates with WTRUs 102a, 102b, and 102c via air interface 117. As will be further described below, the communication links between the different functional entities of WTRUs 102a, 102b, 102c, RAN 105, and core network 109 can be defined as reference points.

[0129] like Figure 11E As shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182, although it will be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with aspects of this disclosure. Base stations 180a, 180b, and 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 117. In some cases, base stations 180a, 180b, and 180c may implement MIMO technology. Thus, for example, base station 180a may use multiple antennas to transmit radio signals to WTRU 102a and / or receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, service classification, Quality of Service (QoS) policy enforcement, etc. ASN Gateway 182 can act as a service aggregation point and can be responsible for paging, caching user profiles, and routing to the core network 109.

[0130] The air interface 117 between WTRUs 102a, 102b, and 102c and RAN 105 can be defined as an R1 reference point implementing the IEEE 802.16 standard. Furthermore, each of WTRUs 102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. The logical interface between WTRUs 102a, 102b, and 102c and the core network 109 can be defined as an R2 reference point, which can be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0131] The communication links between base stations 180a, 180b, and 180c can be defined as R8 reference points, which include protocols for facilitating WTRU handover and data transmission between base stations. The communication links between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as R6 reference points. These R6 reference points may include protocols for facilitating mobility management based on mobility events associated with each of WTRUs 102a, 102b, and 102c.

[0132] like Figure 11E As shown, RAN 105 can be connected to core network 109. For example, the communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which includes protocols for facilitating data transmission and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, Accounting (AAA) server 186, and a gateway 188. While each of the above elements is depicted as part of core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0133] MIP-HA manages IP addresses and enables WTRU 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 provides WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. AAA server 186 handles user authentication and supports user services. Gateway 188 facilitates interoperability with other networks. For example, gateway 188 provides WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and legacy terrestrial communication equipment. In addition, gateway 188 can provide WTRU 102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by a service provider.

[0134] Although Figure 11E Although not shown, it will be understood that RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0135] The description in this article and Figure 11A The core network entities shown in Figures 15C, 15D, and 15E are identified by the names given to these entities according to certain existing 3GPP specifications. However, it will be understood that in the future, these entities and functions may be identified by other names, and some entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Therefore, the described and Figure 11A The specific network entities and functions shown in Figures 15B, 15C, 15D and 15E are provided by way of example only, and it will be understood that the subject matter disclosed and claimed herein can be embodied or implemented in any similar communication system, whether currently defined or to be defined in the future.

[0136] Figure 11F This is a block diagram of an exemplary computing system 90, which can illustrate... Figure 11A The computing system 90 may include one or more devices of the communication network shown in Figures 15C, 15D, and 15E, such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed in a processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the computing system 90 to operate within the communication network. The coprocessor 81 is an optional processor, unlike the main processor 91, which can perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 can receive, generate, and process data in relation to the methods and apparatus disclosed herein.

[0137] In operation, processor 91 fetches instructions, decodes and executes them, and transmits information to and from other resources via the main data transfer path of the computing system (system bus 80). This system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for transmitting data, address lines for transmitting addresses, and control lines for transmitting interrupts and for the operating system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0138] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows the storage and retrieval of information. ROM 93 typically contains stored data that may not be easily modified. Data stored in RAM 82 can be read or modified by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide address translation functionality, which translates virtual addresses into physical addresses during instruction execution. The memory controller 92 can also provide memory protection functionality, which isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped by its own process virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing is configured.

[0139] In addition, the computing system 90 may include a peripheral device controller 83, which is responsible for passing instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

[0140] A display 86, controlled by a display controller 96, is used to display the visual output generated by the computing system 90. This visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented as a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchscreen. The display controller 96 includes the electronic components required to generate the video signal, which is then sent to the display 86.

[0141] Furthermore, the computing system 90 may include communication circuitry, such as a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as... Figure 11A The computing system 90 is connected to RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other networks 112 as shown in Figures 15B, 15C, 15D, and 15E, enabling it to communicate with other nodes or functional entities in these networks. Communication circuitry (alone or in conjunction with processor 91) can be used to perform the transmitting and receiving steps of certain means, nodes, or functional entities described herein.

[0142] Figure 11G An example communication system 111 is illustrated, in which the methods and apparatus described and claimed herein may be one aspect. As shown, the example communication system 111 may include wireless transceiver units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it will be understood that this disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or more or all of WTRUs A, B, C, D, and E may be outside the range of the network (e.g., outside the cell coverage boundary shown by the dashed line in the figure). WTRUs A, B, and C form a V2X group, where WTRU A is the group leader, and WTRUs B and C are group members. WTRUs A, B, C, D, E, and F may communicate via a Uu interface or a sidelink (PC5) interface.

[0143] It will be understood that any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium that, when executed by a processor (such as processor 118 or 91), cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein may be implemented in the form of such computer-executable instructions that execute on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented using any non-transitory (e.g., tangible or physical) method or technique for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include (but are not limited to) RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital multi-purpose optical disc (DVD) or other optical disc storage devices, magnetic tape, magnetic tape, disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and is accessible by a computing system.

[0144] definition The following are definitions of the abbreviations that appear in the text of this disclosure.

[0145] .

[0146] The following are definitions of the terms that appear in the text of this disclosure.

[0147] .< / mlmodelapi> < / mlmodelapi>

Claims

1. A method, the method comprising: The rules engine (RE) service receives one or more requests to create an RE definition for the digital twin (DT) system. The definition includes one or more ML-enabled rules, wherein the ML-enabled rules include one or more ML-enabled event conditions, actions, states and / or state transitions. According to the ML-enabled rules specified in the RE definition, communicate with DT services, storage services, machine learning (ML) services, or a combination thereof; as well as The RE service sends one or more responses regarding the status of the one or more requests, wherein the one or more responses include one or more of the following: creating the overall status of the RE definition; the individual status for each rule, event condition, action, status and / or status transition enabled by each ML specified in the RE definition; and / or the status for the service interconnection between the RE service and the ML service.

2. The method of claim 1, wherein the RE definition further includes ML strategy information, the information including at least one of ML model ID, ML model input, or ML model output.

3. The method of claim 1, wherein the RE definition further includes service connector information, the information defining DT inputs and outputs, the RE service connecting the DT inputs and outputs to the ML model inputs and outputs of the ML service.

4. The method according to claim 1, wherein the method further comprises: Based on the RE definition, the RE service sends DT updates to the ML model of the ML service.

5. The method according to claim 1, wherein the method further comprises: The RE service receives the ML model output from the ML service.

6. The method according to claim 5, wherein the method further comprises: Based on the ML model output received from the ML service, the RE service updates one or more DTs.

7. The method according to claim 1, wherein the method further comprises: The RE service detects abnormal output received from the ML service and sends an instruction to the ML service that the ML model needs to be retrained.

8. An apparatus comprising: One or more processors; Memory; as well as A set of computer-executable instructions stored in the memory, which, when executed by the one or more processors, cause: The rules engine (RE) service receives one or more requests to create an RE definition for the digital twin (DT) system. The definition includes one or more ML-enabled rules, wherein the ML-enabled rules include one or more ML-enabled event conditions, actions, states and / or state transitions. According to the ML-enabled rules specified in the RE definition, communicate with DT services, storage services, machine learning (ML) services, or a combination thereof; as well as The RE service sends one or more responses regarding the status of the one or more requests, wherein the one or more responses include one or more of the following: creating the overall status of the RE definition; the individual status for each rule, event condition, action, status and / or status transition enabled by each ML specified in the RE definition; and / or the status for the service interconnection between the RE service and the ML service.

9. The apparatus of claim 8, wherein the RE definition further includes ML policy information, the information including at least one of ML model ID, ML model input, or ML model output.

10. The apparatus of claim 8, wherein the RE definition further includes service connector information, the information defining DT inputs and outputs, the RE service connecting the DT inputs and outputs to the ML model inputs and outputs of the ML service.

11. The apparatus of claim 8, wherein the computer-executable instructions, when executed by the one or more processors, further cause: based on the RE definition, the RE service sends a DT update to the ML service's ML model.

12. The apparatus of claim 8, wherein the computer-executable instructions, when executed by the one or more processors, further cause the RE service to receive ML model output from the ML service.

13. The apparatus of claim 12, wherein the computer-executable instructions, when executed by the one or more processors, further cause the RE service to update one or more DTs based on the ML model output received from the ML service.

14. The apparatus of claim 8, wherein the computer-executable instructions, when executed by the one or more processors, further cause: the RE service to detect abnormal output received from the ML service; and to send an instruction to the ML service that the ML model needs to be retrained.

15. A non-transitory computer-readable medium comprising a set of computer-executable instructions, which, when executed by one or more processors, cause: The rules engine (RE) service receives one or more requests to create an RE definition for the digital twin (DT) system. The definition includes one or more ML-enabled rules, wherein the ML-enabled rules include one or more ML-enabled event conditions, actions, states and / or state transitions. According to the ML-enabled rules specified in the RE definition, communicate with DT services, storage services, machine learning (ML) services, or a combination thereof; and The RE service sends one or more responses regarding the status of the one or more requests, wherein the one or more responses include one or more of the following: creating the overall status of the RE definition; the individual status for each rule, event condition, action, status and / or status transition enabled by each ML specified in the RE definition; and / or the status for the service interconnection between the RE service and the ML service.

16. The non-transitory computer-readable medium of claim 15, wherein the RE definition further includes ML policy information, the information including at least one of ML model ID, ML model input, or ML model output.

17. The non-transitory computer-readable medium of claim 15, wherein the RE definition further includes service connector information defining DT inputs and outputs, the RE service connecting the DT inputs and outputs to the ML model inputs and outputs of the ML service.

18. The non-transitory computer-readable medium of claim 15, wherein the computer-executable instructions, when executed by the one or more processors, further cause: based on the RE definition, the RE service to send DT updates to the ML service's ML model.

19. The non-transitory computer-readable medium of claim 15, wherein the computer-executable instructions, when executed by the one or more processors, further cause the RE service to receive ML model output from the ML service.

20. The non-transitory computer-readable medium of claim 19, wherein the computer-executable instructions, when executed by the one or more processors, further cause the RE service to update one or more DTs based on the ML model output received from the ML service.

Images