Mechanisms for machine learning enablement

Abstract

A method may include receiving by a Rule Engine (RE) service one or more requests to define an RE definition 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 specified in the DT system, for processing the one or more requests; and sending, by the RE service, one or more responses with a status to the one or more requests, wherein the one or more response comprise one or more of an overall status of processing the RE definition, an individual status for each event condition, action, state, and / or state transition that was specified in the RE definition, and the status for an interconnection of services between the RE and ML services.

Description

MECHANISMS FOR MACHINE LEARNING ENABLEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit of U.S. Provisional Application No. 63 / 582.563 titled “Mechanisms for Machine Learning Enablement” filed September 14, 2023, and U.S. Provisional Application No. 63 / 582,952 titled “Mechanisms for Machine Learning Enablement” filed September 15, 2023 the contents of which are hereby incorporated by reference in their entirety for any and all purposes.BACKGROUNDDigital Twins Service

[0002] A Digital Twin (DT) is a virtual representation of physical objects or systems, created using data from sensors, cameras, and other sources. A DT is essentially a digital replica of a physical asset, process, or system, which allows for real-time monitoring, analysis, and simulation. A DT service provides one or more DT centric capabilities to assist devices and applications with performing DT specific operations, e.g. operations such as creating, storing, updating, and discovering DTs. DT services are typically deployed on network nodes such as cloud or edge servers.Rules Engine Service

[0003] A Rules Engine (RE) service is one in which a set of rules are provided to detect and react to events in a system. A rule consists of conditions for the event and any actions that are taken as a result of the occurrence of the event. The conditions of an event are usually specified as an expression comparing two quantities, an operand and a threshold, using a comparator operator. One or more conditions can be specified to describe more complex events with logical operators. Typically, the operand is associated with data from a digital twin. Similarly, actions are specified to describe what is performed due to the occurrence of an event and may be linked to a DT that controls a physical device.

[0004] When a system is more complex in nature, a RE service may be used to track the states of the system. Within each state, one or more events and actions may be performed due to the different events. State transitions can be specified to link the states together. The states may represent the different operational conditions of a physical system.

[0005] Another common term for a RE service is a policy engine service.Digital Twin Systems

[0006] The combination of a DT service with a RE service enables the definition of a complete DT system. DTs may be created to provide data and to accept actions that may be triggered and rules may be defined to specify events, operations, and states of a DT system. FIG. 1 shows an example architecture of the combination of a DT service with a RE service to enable the creation of a DT system.

[0007] An example is presented to highlight how a DT system is created using the above architecture. The comfort level of a large conference room is monitored by a DT system that comprises temperature and humidify sensors, controls to a heating, ventilation, and air conditioning (HVAC) unit, and RE definitions that have been configured by a DT user. DTs are created for both sensory and actuator devices existing in the room and a DT user interfaces to both a DT and a RE service to define the DT system. A storage server can be used to store information about the DT system, e.g. data from the DTs and rules from the RE service.

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

[0009] State "Normal" - Ideal temperature and humidify range is maintained.

[0010] State "Too Hot" - Temperature is above the desired range.

[0011] State "Too Humid" - Humidity is above the desired range.

[0012] State "Too Cold" - Temperature is below the desired range.

[0013] State "Too Dry" - Humidity is below the desired range.Events:

[0014] Eventl : temperature > 75°F

[0015] Event2: temperature < 68°F

[0016] Event3 : humidify > 50%

[0017] Event4: humidify < 30%

[0018] Event5 : temperature < 75°F and temperature > 68°F

[0019] Event6: humidity < 50% and humidity > 30% Actions:

[0020] Actionl : If Event 1 = True, decrease temperature

[0021] Action2: If Event 2 = True, increase temperature

[0022] Action3 : If Event 3 = True, decrease humidity

[0023] Action4: If Event 4 = True, increase humidity State Transitions:

[0024] Transitionl: "Normal" -> "Too Hot"

[0025] Transition2: "Normal" -> "Too Cold"

[0026] Transitions: "Normal" -> "Too Humid"

[0027] Transition4: "Normal" -> "Too Dry"

[0028] Transitions: "Normal" -> "Normal"

[0029] Transition : "Too Hot" -> "Normal"

[0030] Transition7: "Too Cold" -> "Normal"

[0031] Transitions: "Too Humid" -> "Normal"

[0032] Transition^ "Too Dry" -> "Normal"

[0033] In the above definitions, there are five definitions showing the different states (e.g. comfort level) for the room and six events that may trigger an action, a state transition, or a combination of both. The expression for each event may reference a data input from a DT such as temperature and humidity obtained from the corresponding sensors. Based on the triggering of an event, an action may be specified to increase or decrease the temperature or humidity. Finally, there are nine state transitions defined based on the combination of the current state and the corresponding event. FIG. 2 illustrates the mapping of events and actions to the states in the DT system while FIG. 3 shows the state transitions defined for the DT system.

[0034] As shown in FIG. 2, the DT representations of physical devices are found on the left and right sides of the figure while the states of the DT system are in the center. The DTs on the left may be associated with physical devices that generate data for the DT system while the DTs on the right may be associated with control devices to perform the desired operations. Note that while the control devices are shown separately, they may all be represented by one or more physical devices, e.g. an HVAC unit. Within each of the fivestates are four events that are associated with actions to increase or decrease the temperature or humidity according to the event definition. Note that it is not necessary to show events 5 and 6 since no actions are performed as a result of the event.

[0035] FIG. 3 shows the states and state transitions for the DT system - the five states and the six events defined for the DT system. Within the figure, only the events that are defined are shown and not all events may cause a state transition.

[0036] The above example shows a very simplified use case of defining a DT system using rules managed by a RE service. The events are defined in a very simplistic manner involving data from only a Pew devices. An example of more complex events including both temperature and humidity sensors may be as follows:

[0037] (temperature < 68) and (humidity < 30) -> State: Too Cold and Too Dry

[0038] (temperature < 68) and (humidity > 50) -> State: Too Cold and Too Humid

[0039] (temperature > 75) and (humidity > 50) -> State: Too Hot and Too Humid

[0040] (temperature > 75) and (humidity < 30) -> State: Too Hot and Too Dry

[0041] The above definitions may require the introduction of new' states beyond the original state definitions. If additional inputs are added, e.g. the presence and number of people in the room, the outside weather, the presence of windows, etc., the event definitions become even more complex and more states need to be defined. It can be seen that as the dimensionality’ of the system increases, the complexity for defining events, actions, states, and state transitions increases dramatically, and in some cases, are nearly impossible to define. In addition, defining such a complex system with explicit rules / policies may be error prone and introduce conflicting definitions. As a result, it may be beneficial to replace event, action, state, and state transition definitions with machine learning models that may be trained to handle the higher dimensionality of the problem.ML Services

[0042] Due to the popularity of machine learning, ML services are provided to simplify ML capabilities and make them easily accessible to users who are interested in creating ML applications. A machine learning pipeline can be created to streamline ML development and may consist of data collection, data cleaning, data transformation, feature engineering, data labeling, model training and verification, model deployment, and model monitoring. The ML pipeline can also be used to train ML models with prepared data and deploy the trained ML models for inferencing.

[0043] To date, sendees for creating DTs, configuring rules and policies to mimic physical processes, and training ML models all exist as individual cloud sendees available for users to access. DTs have numerous benefits for physical world systems and environments such as real-time monitoring and analysis, effective issue detection and mitigation, simulation, and testing, via intuitive, real-world interactions with digital systems. However, due to the disparate nature of these services as offered by CSPs, it is fairly difficult to create a system incorporating DTs. rules engine configuration, and trained ML models without having in depth knowledge and expertise of multiple service offerings.

[0044] Consequently, it can be stated that current DT sendees from cloud service providers offer a somewhat static and rigid mechanism for defining a DT system wherein the RE service offers potential mechanisms for actions and interactions between / among DTs that needs to be explicitly defined. However, the inclusion of ML services as a tool for replacing rules to manage the DT system has the potential to offer additional actions / interactions with higher dimensionality than existing RE services. In addition, existing rules engine configuration mechanisms are manual and cumbersome to define for larger, more complex systems. Therefore, the major motivation associated with enhancing and / or replacing rules engines with an ML-driven approach is to support higher dimensionality processes that may be infeasible with rules engine-based sendees.SUMMARY

[0045] Mechanisms for managing complex physical systems with digital twin systems through the utilization of multiple service components are described herein. The proposed mechanisms enable the creation of intelligent DT systems by users / applications interworking Rules Engine (RE) services with Machine Learning (ML) and DT services to enable creating complex, high dimensionality processes within DT systems.

[0046] In one aspect, a method of an ML-enabled RE service may: receive one or more requests to define an RE definition for a DT system. The RE definition may include rules specifying the event conditions, actions, states, and state transitions for the DT system. In some cases, one or more ML policies and service connector identifiers may be specified to replace elements of a rule (event condition, action, state, state transition) with ML models, which may be trained or untrained. In some cases, the service connector may define how to interface to an external service, and includes one or more of a Service Connector Identifier,an ML Policy Identifier, Service Connection Identifier, Sendee name, Service API, Input Connector Information, Interworking Functions, and Output Connector Information.

[0047] The method may further include communicating with one or more of a DT service, a storage service, and an ML service according to the rules specified for the DT system. The method may further include sending one or more responses with the status to the one or more requests, the responses include one or more of an overall status of processing the RE definition; individual status for each event condition, action, state, and / or state transition that was specified in the RE definition: and the status for the interconnection of services between the RE and ML services.

[0048] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0049] FIG. 1 depicts an architecture of a DT system;

[0050] FIG. 2 depicts example DT system event triggered actions;

[0051] FIG. 3 depicts example DT system state transitions;

[0052] FIG. 4 depicts an architecture for ML-enabled DT system;

[0053] FIG. 5 depicts an example procedure of creating ML-enabled DT system;

[0054] FIG. 6 depicts replacing rules of event definitions and actions with ML model;

[0055] FIG. 7 depicts replacing rules of events and state transitions with ML model;

[0056] FIG. 8 depicts replacing rules of states with ML model;

[0057] FIG. 9 depicts a RESTful resource embodiment;

[0058] FIG. 10 depicts a graphical user interface (GUI) system state diagram;

[0059] FIG. 11 A depicts an example communications system in which the methods and apparatuses described and claimed herein may be an aspect of;

[0060] FIG. 1 IB depicts a block diagram of an example apparatus or device configured for wireless communications;

[0061] FIG. 11C depicts a system diagram of an example radio access network (RAN) and core network;

[0062] FIG. 1 ID depicts a system diagram of another example RAN and core network;

[0063] FIG. 1 IE depicts a system diagram of another example RAN and core network;

[0064] FIG. 1 IF depicts a block diagram of an example computing system; and

[0065] FIG. 11G depicts a block diagram of another example communications system.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0066] The present invention describes mechanisms for interfacing DT services, rules engine services, and machine learning services together to enable the creation of more complex and intelligent DT systems. The emergence and popularity of ML capabilities can further enhance and even replace current rules engine that may be too complex to specify’, especially for systems requiring higher dimensionality'. Data from DTs may be routed to pretrained ML models that are trained to simulate expected behavior of the DT system. FIG. 4 shows an example architecture for how an ML-enabled DT system may be realized. Note it is well understood that the use of the term RE service may apply to both rules and / or policy engine services as previously described.

[0067] The architecture shown in FIG. 4 shows a simplified view of an ML-enabled DT system starting from a sensor device generating data for the system, the storage and digital representation of the data associated with the sensor device, the processing of the data using a RE and / or ML services, the sending of commands to a DT representing a control device that can perform the required actions, and a DT user to configure and control the system. Note the figure is for illustrative purposes only where one entity is shown for each component of the DT system. A real-world DT system may include many more physical devices than what is shown in the figure.

[0068] The digital representation, or DT, of the physical system may be realized within a DT service that is part of a cloud or edge platform. Within the platform may exist other sendees such as a RE service, a storage service, and an ML service. These services may operate independently from each other and interfacing between and among the sendees may require API calls that are responsible for linking the services. For the case of interactions between a RE and ML service, a service connector may need to be defined as additional processing and / or orchestration between the sendees may be required. For example, data from DTs may be processed before passing to an ML model and data from ML models may require enumerations and / or scaling before saving data to DTs. Note also that the services may be owned by different service providers, which may require more complex interworking between the sendees.

[0069] FIG. 4 highlights the interactions of a DT service, a rules engine service, a storage sendee, and a machine learning service. A DT system may be created with the definitions of DTs to represent physical devices, policies managed by a RE service, a storage service tostore data for the DT system, and ML models to simulate complex operations of the DT system. Service connector functionality may be utilized to connect, interface, and interwork the RE and ML services. One or more physical devices may be associated with virtual representations created within a DT service to provide data for the DT system. The physical devices may generate data such as from sensors or the physical device may be control (i.e., actuator) type devices for which commands may be sent to execute actions (e.g., turn on / off a switch or open / close a valve). Once data is available within a cloud or edge platform, one or more events may be triggered to be evaluated by a RE service. Additionally and / or alternatively, ML models may be used in conjunction with and / or to replace one or more rules to simulate the behavior of the physical system in the DT system.

[0070] The data for the DT system may be provided by physical devices sending data periodically to the corresponding DTs, which may trigger one or more rules to be evaluated. The rules may cause one or more actions to be executed which may involve the update of one or more DTs. The RE sendee is used to define the events and conditions that govern the behavior of the physical system through the interaction of DTs. For complex operations, one or more ML models may replace one or more rules. Service connectors are used to interwork between the RE service with the ML service to enable the replacement of rules with ML models. For example, the data provided by the DTs may not be in a format required by the ML model and may need to be processed by an interworking function first before the ML model can use the data.

[0071] A DT system may be created from the architecture shown in FIG. 4 to simulate a process flow such as a factory assembly line or a real-w orld hazardous environment such as an industrial construction site. A DT user may start by creating virtual representations of physical entities in a cloud service platform and then interconnect the DTs together to form the overall system. The user may then configure rules and policies to simulate the interactions between and among the DTs in the virtual system according to the behaviors of the physical entities. For some real -world processes, however, it may be easier for the DT user to integrate trained machine learning models representing DT interactions and process flow s instead of configuring explicit rules and policies. An example of such a procedure for creating a DT system incorporating trained machine learning models is shown in FIG. 5.

[0072] The figure is divided into four main procedures: the creation of the DT system, the definition of rules for the DT system, the update of the rules with trained ML modelsrepresenting the operational aspects of the DT system, and the possible retraining of ML models. A DT user may begin by creating DTs to represent components of the physical system, train ML models to emulate operational aspects of the system and configure rules and policies for the system. When configuring the rules and policies, the DT user may integrate trained ML models to replace rules and policies of complex operations for quicker deployments of the DT system.

[0073] Once the DT system and its operational aspects have been created, the system can be deployed to simulate the operations of the physical system. Data from the physical devices may be communicated to the DTs and the rules / policies and / or ML models may emulate the interactions between and among the DTs. If the interactions result in commands sent to actuators of physical devices, the DTs associated with those actuators are updated and the commands are sent to the physical devices to perform the actions.

[0074] During operations of the DT system, the RE service may detect discrepancies between the outputs of the ML models relative to the expected data for the DT. For example, an ML model may output a value to a DT that falls outside the typical range of values or the value may cause the physical device to malfunction. The RE service may be able to detect the abnormal or unexpected event and store the set of inputs and state information associated with the undesired or unexpected output from the ML model. This information may be provided to the ML service, which may notify the DT user of the abnormal event. The DT user may acknowledge the notification and may even trigger retraining of the ML model by providing updated ground truth for the event. Finally, the RE service may provide DT users with periodic or event driven notifications of status updates for the operations of the DT system. The status updates may be displayed on a dashboard for the DT user to review and monitor.

[0075] Step 1: Based on requirements for a DT system, a DT user may create DTs with a DT service to represent components of the actual system. Each DT may be defined using the definitions shown in Table 1 to not only provide information of the data that is collected and stored, but to also include relationship information with other DTs as well as commands that may be executed by the DT. Identifiers and names may be assigned to the DTs to be unique and addressable within the DT service and a description may be included to provide context for the benefit of other DT users.Table 1 - Digital Twin Definition

[0076] The DTs may be created according to the hierarchy of the physical system (e.g. rooms and floors of a building) or according to a process flow (e.g. different locations of a supply chain operation). Information about the data such as the date type, ranges, format, units, update frequencies, etc. that the DT may collect and store may be provided. Device information such as the manufacturer, device model and serial numbers, hardware and software versions, etc. may also be provided and stored within a storage service.

[0077] The DT user may initiate the creation of the DT or the physical devices may be configured and / or triggered to initiate the creation of the DT with a DT service. The information for the DT such as those shown in Table 1 may be stored in a storage service of a service platform hosted in the cloud or at the edge. A RE sendee may also be configured during this step with information regarding DTs and their relationship to one another in theDT system. The RE service may use the relationship parameter to link DTs together. Note that the linking that may be performed in this step may be logical at this point without significant functionality, e.g. to show a logical connection from one DT to another DT in a dashboard display.

[0078] Step 2: Separately, the DT user may train ML models using the capabilities provided by an ML service. The training may be structured for the model to learn certain behaviors required for components of the DT system. The training data may be collected from actual physical devices or the training data may be synthetically generated for what the actual devices may produce. In the latter case, the DT system may represent a simulation model of an actual system that is being designed and developed. The synthetic data may be generated based on product requirements, historical data from similar ty pes of devices, and / or specifications for different operating conditions and from different devices in the system.

[0079] In addition to training the ML model, an ML policy may be created by the DT user to provide information about the ML model, the ML algorithm that was trained, training data information, data preparation steps that need to be applied to real-time data before feeding it into the ML model for inference, and other pertinent information that may be used when interfacing the ML model to the DT system. An important aspect of this information is the service connection information that is shown in Table 2. The service connection information may be provided by the DT user to describe how an ML model may be connected to a DT system, specifically the API calls to orchestrate and configure the operating environment to access the ML model. An API call may be available to first establish an operating environment for which the ML model operates in and another API call may be available to enable and configure the ML model. The API calls may be present as a list of instructions for an interworking service to orchestrate the operating environment, e g. create a virtual machine, and run the ML model. In addition, information about the input and output connectivity between the ML model and one or more DTs within the DT system may be provided. The connectivity information may also contain data processing requirements for connecting DTs to / from the ML model such as data preparation, data cleaning, data scaling, data transformation, data enumeration, etc. Note the connectivity information may be bidirectional such as data processing requirements at both the inputs and outputs of the ML model.Table 2 - ML Policy Information

[0080] The information elements with respect to the ML model may include the type of the ML algorithm, such as supervised, unsupervised, classification, regression, reinforcement, etc. as well as the specific algorithm (Random Forests, SVM, Naive Bayes etc.). There maybe many other elements in the specification of the ML model and ML pipeline such as hyperparameter optimization parameters (specific to algorithm), data preparation requirements, feature engineering, etc. Other crucial aspects are the various dependencies / requirements of an ML pipeline, including the OS, hardware requirements (CPU, GPU, memory-, number of compute nodes etc.), software dependencies (languages, libraries along with their versions), secunty. compliance, scalability-, continuous improvement, etc.

[0081] The service connection information may be used by a RE service when integrating an ML model with components of the DT system. The operating environment information element may reference a script that is executed first to launch a virtual machine or container to run the included ML model and the API references may be a URI to a list of instructions that is called to access the ML model once the operating environment is running. Additionally and / or alternatively, the operating environment and API references may be combined together as a list of instructions for an interworking service to orchestrate and run the ML model. The input information may provide the identification of input features required for the ML model as well as the data format and range of values that each input requires. Similarly, the output information may provide information on what format and range of values the output of the ML model make take. A list of interworking functions may also be available for connecting to inputs and / or outputs of the ML model.

[0082] At the end of this step, multiple models may be available for integration into the DT system. Note the ML models may be trained and operated concurrently with the definition of the DT system in an iterative fashion. ML models may even be trained prior to the specification and creation of the DT system, e.g. as part of requirements for a different DTsystem that is adapted for use in the current DT system. Therefore, steps 1 and 2 may operate in any order and even simultaneously with one another.

[0083] Step 3: The DT user may send one or more requests to a RE service to create one or more ML-enabled rules for the DT system. Each ML-enabled rules may comprise a set of rules defined by the DT user. The rules may specify events that occur within the DT system and that may result in actions performed by the RE service such as operations performed by the RE service upon DTs within the DT system. The rules may also specify states and state transitions for a process flow that may occur within the DT system based on events occurring within the states. Based on this state information, the rules engine may perform a conditional sequenced set of actions involving DTs within the DT system. Events may consist of conditions that are triggered in response to changes in data updated in the DT representations and the actions that are executed as a result. An example of a RE definition is shown in Table 3. Each RE of a DT system may be enabled with ML capabilities with the inclusion of an ML policy identifier and a sen-ice connector identifier.Table 3 - ML-enabled DT System Rules Engine Definition

[0084] A RE may be created and defined after DTs for the components of the DT system have been defined in step 1 or the RE may be created and defined as part of step 1 during the definition of the DT system. The definition of the event conditions, actions, states, and state transitions may be realized using a traditional RE where updates to data in a DT may cause one or more events to be triggered and any resulting action to be executed. As an alternative to using a traditional RE, the DT user may interface trained ML models in place of user defined event conditions, actions, and states, and state transitions.

[0085] The RE service may create a RESTful resource locally to store the DT system RE definition provided by the DT user. A DT system identifier and / or RE identifier may be assigned to the resource and returned to the DT user in a response message, e.g. in step 5. The DT user may use the DT system identifier and / or RE identifier in future requests to update the configuration for the DT system RE definition stored in the resource.

[0086] An expression may 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 a DT may be represented by a URI or by one or more identifiers. For example, / / data / pressure may be a URI that identifies a resource that contains the data for the pressure that is provided by a physical device whose DT identifier is specified as DTI. Additionally and / or alternatively, the following identifier may also be specified:DTI. data. pressure. Note that the example provided shows a simple hierarchy; a morecomplex hierarchy may also be envisioned. For example, / DTl / floorl / pipe2 / data / pressure shows two additional layers of hierarchy from the previous example.

[0087] To complete the expression for an event, the operand may be compared to a threshold value using a comparison operator such >, <, =, >=, <=, / =, etc. Logical operators, such as AND, OR, and NOT, may also be used to combine multiple expressions to create more complex events. Multiple expressions may signify events that depend on multiple inputs, e.g. data from multiple DTs. As more inputs are added to an event, the expression may become even more complex and may make it hard to understand and / or describe what the event is capturing. In such a scenario, the DT user may prefer to use a trained ML model to replace the need to specify all the individual expressions for the complex event. The trained ML model may more readily capture contributions of different inputs and the range of their values than a complex expression for an event.

[0088] Within the DT system RE definition shown in Table 3, an ML policy, such as the one defined in step 2, may be specified to identify a trained ML model. This ML model and associated policy may be used to enhance and / or replace an event condition, action, state, or state transition of an RE. Within the ML policy, there may be a Service Connection specified to provide information on how to interface data from DTs to the ML model, e.g. to process data between the services. The Service Connection information can be used to derive and create a Service Connector to interface an RE service with an ML service and vice versa. Table 4 shows an example of a Service Connector definition that may be specified to provide interconnectivity information between DTs and ML models.Table 4 - ML-Enabled RE Service Connector Definition

[0089] The Machine Learning models may be pretrained and ready to produce inferencing results, or they may be connected to the DT system and use data from the DTs for training purposes. The ML Service API may be exposed to the DT Service through the Service Connection information found in an ML policy and the Service Connector capability may be utilized to interconnect the DT service with the ML service.

[0090] The Service Connector definition may contain information required for the input connection to be made between the DT system and the external service (e.g. ML service), any- interworking functions that may be required to process data from the DTs to meet the requirements of the inputs of the external service (e.g. ML model), and the output connection made from the external service to the DT system.

[0091] When connecting to an external service, certain pre-requisite operations may be required before the actual ML operation (e.g. inferencing and / or training) are performed. Such pre-requisite operations may be specified using the Service API information element. The Service API may reference to an interworking service that executes the necessary operations to set up an environment for the ML model to operate in. For example, the interworking service may orchestrate a virtual machine with associate ML packages required for the ML model to operate. Additionally and / or alternatively, the interworking service may orchestrate and load a previously saved state of the VM to continue from the previous state of the ML model. Furthermore, the interworking service may save the state of the VM upon the completion of a sequence of events in a DT system and pause the VM until the next time the ML model is needed.

[0092] Step 4: The RE service may communicate with the DT service, the Storage serv ice, and the ML service to process the request received in step 3. For each DT referenced in the information elements of RE definition described in Table 3, the RE service may make subscriptions to receive notifications on changes or updates to the DT data, or retrieve the DT data from the storage service (if the DT data has been stored in the storage service).Similarly, for references to an ML policy, the RE service may use the information for the Sendee Connection of the ML policy and the Service Connector information in the RE definition to interconnect the DT service with the ML sendee (and to the storage sen ice. if applicable).

[0093] Step 5: Based on the processing results of step 4, the RE service may return a response showing the status of the creation of the ML-enabled RE. The response may include an overall status of processing the RE definition as well as individual status for each event condition, action, state, and / or state transition that was specified in the RE definition. In addition, the status for the interconnection of sendees between the DT and ML services may be provided. If there were status with indication of failure, then a reason for the failure may be provided as well. Errors may be encountered when making service connections between the RE and ML services and these errors may also be returned to the DT user. One or more identifiers may also be returned in the response as references to the associated item(s) (e.g. DT system, RE, and Service Connector).

[0094] Step 6: If step 5 completes successfully, the DT system RE may be fully specified with functionalities from ML models replacing certain events, actions, states, and state transitions. The operation information element of the RE may be configured to “enable operation”. If ML models are to be trained within the DT system, the operation IE may be configured to “training”. Devices may provide data to the corresponding DT and operation or training of the DT system RE may commence.

[0095] Step 7: The RE service may monitor and detect the updates of the DTs in the DT system and process the appropriate events, actions, and / or state transitions according to the RE definitions. For cases involving ML models, the RE sendee may access the service connectors to route DT data to the appropriate interworking functions to process the data before the results are passed to the ML service and the specified ML model. The (processed) data obtained from the interworking functions can be stored in the storage service for future usage such as to (re)train or update the ML models.

[0096] Step 8: The ML models may generate outputs based on the received inputs and the ML service may pass the outputs to the appropriate service connector functions, where the data may be processed (e.g. enumerated, scaled) according to the output requirements specified by the Output Connector information. The resulting data may be routed back to one or more DTs through the RE sendee and / or the corresponding service connector. The outputs from the ML service can be stored in the storage service for future usage such as to (re)train or update the ML models.

[0097] Step 9: Output data from step 8 that may result in actions being performed by physical devices may be forwarded from the DTs to the physical devices.

[0098] Step 10: For certain combinations of input data provided by step 7 and the output data generated in step 8, the RE service may detect abnormal or unexpected actions that were taken. For example, there may have been an error indicated by one of the service connectors processing an output received from the ML service. As another example, a command may have been sent to a physical device in step 9 that resulted in an error. In these scenarios, the RE sendee may collect the data from steps 7 and 8 and send a message to the ML service with an indication that an error or other undesirable behavior was encountered in the DT system. The message may include additional information about the error / abnormal behavior (e.g. where the error was encountered and what may have caused the error) and an indication that re-training may be needed to update the ML model. Alternatively, the RE service may send this information directly to the DT user with the data generated for steps 7 and 8. The RE service may also save the data in a storage server with an indication that the data generated abnormal and / or unexpected behavior.

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

[0100] Step 12: The DT user may send an acknowledgement back to the ML service (or RE service) and decide whether to enable retraining of the ML model. If requesting retraining, the DT user may provide ground truth labels to associate with the data received from the DT sen-ice. The DT user may also process any input data that may be out of specification. For example, the DT user may notice that a mandatory input w as missing or a certain value was corrupted. A missing input value may signal that a physical device may have failed and hence no data was provided to the DT representation. A corrupt data value may indicate issues with an interworking function that processed the data. For example, a value from a DT was not scaled properly, which caused the interworking function to corrupt the data. Alternatively, the user may also elect not to retrain the ML model.

[0101] Step 13: If requested by the DT user, the ML service may retrain the ML model ith the input data and ground truth received from the DT user. The ML service may then send the results of the re-training to both the DT user and the RE service. The ML service may also save the retrained data in the storage service.

[0102] Step 14: Periodically or triggered by events, the RE service may notify the DT user of the status of the DT system. The notification may highlight events that were captured since the last notification was sent. If there were major events, e.g. such as retraining or errors occurring in the DT system, the RE service may include additional information for the major events such as the DT values, events, states, and state transitions. The RE service may also include information about the service connecters, interworking functions, and VM state information. The additional information may be saved in the storage service and an identifier may be provided to the DT user to retrieve the information.

[0103] The mechanisms specified in step 10 for the detection of abnormal operations or of errors reported by service connectors are reactive in nature. For a more proactive approach, rules may be created as part of the RE definition created in step 3 to detect certain events that may occur and to report such events to the DT user. The rules may be specified such that certain combinations of input data from DTs may trigger a notification to the DT user and / or retraining of the ML model. Additionally and / or alternatively, an ML model specially designed to detect abnormalities in the system may be deployed at various junctions of the DT system to report abnormal or unexpected behaviors to the DT user and may even be configured to retrain the ML model(s). An ML model may also be able to detect data drift in the system and trigger retraining where appropriate. The ML models may be inserted as states of the DT system that monitors the operations of the DT system and report any events and / or errors that the ML models were trained to detect.

[0104] The DT system created by FIG. 5 describes an example deployment in which the components of the DT system were created independently. The DTs and ML models were created by their respective services in steps 1 and 2, respectively. The RE definition was then created in step 3 to complete the operational aspects of the DT system where data from the DTs are connected to the ML models through the use of service connectors. The ML models were previously trained and hence the system could start to operate once the services were connected.

[0105] In addition to the aforementioned deployment, other deployment scenarios may be envisioned where the data from the DTs created in step 1 may be used to train ML algorithms / models specified in step 2. The data collection, data preparation, and ML training may then occur during steps 6 to 13. In this scenario, the ML models are untrained and the RE definition provides connectivity information between the DTs and the untrained MLmodels. Then as data becomes available in step 6, the Rules Engine service and interworking functions may work together to process the data from the DTs for use to train the ML models. Step 9 may be skipped in this scenario while the training process is active. The RE / ML service may decide in step 10 to collect a batch of data before prompting the DT user for ground truth data in step 11. Steps 11 and 12 may be the data labeling steps with either the DT user, a machine synthesized ground truth data, a data labeling sen ice, or a combination thereof. The training may commence in step 13 once the whole or a portion of the dataset is available. Note the training may also be partitioned into batches as part of general ML training and / or hyperparameter optimizations.

[0106] Another potential deployment scenario may be that the RE definition may initially be created in step 1 when the DTs are created. In this scenario, step 1 may generate a fully operational DT system in which the operations are dictated by the RE definitions. A multitude of events, actions, states, and state transitions may be specified to fully describe the operations of the DT system. However, the RE definition may be fairly complex and unwieldy to manage. Therefore, ML models may be trained to replace certain aspects of the RE definition to simplify the specification of the DT system. As the ML models become available, step 3 may be repeated to update the RE definitions accordingly.

[0107] Previously, it was described that a DT system may be created to monitor and maintain the comfort level of a large conference room based on defined rules managed by a RE service. In the following sections, an ML enabled DT system is proposed to enhance existing rules-based DT systems to account for higher dimensionality problems than what was originally described. More complex events may be introduced by ML models to handle more inputs than what was previously used. For example, inputs such as the time of day, the season of the year, the size of the room, the number of people present in the room, the number of windows, the weather forecast, the direction of the sun, etc. may also factor in the comfort of the room. It may be very difficult to craft explicit rules to account for all the aforementioned inputs into explicit event definitions. Therefore, it is proposed that ML models may be trained to account for a multitude of inputs and the desired outputs to a problem and used to replace event conditions, actions, states, and state transitions of an RE definition to account for the higher dimensionality of the multitude of inputs. The RE service may interwork with an ML service to provide seamless operations between the services using sendee connectors.ML Replication of Rules with Event Conditions and Actions

[0108] The DT system created by FIG. 5 shows an example embodiment of interworking services together, e.g. interworking RE, DT and ML services together with one another. Within the RE definition, mechanisms may be made available to allow DT users the abi 1 ity to replace event conditions, actions, states, and state transitions with ML models that may be trained to replace the underlying event condition, action, state, or state transition.

[0109] FIG. 6 shows an example where the conditions and / or actions of an event may be connected to inputs of an ML model. Note that while the figure only shows one event condition and one event action, there may be a multitude of event conditions and actions that may be connected to the inputs of an ML model. Note also that data from DTs may be the source of information used for defining the event conditions and actions can be forwarded to DTs to perform the desired actions. Additionally and / or alternatively, actions from ML model outputs may be forwarded to another DT for further processing, e.g. as to trigger event(s) in another DT.

[0110] FIG. 6 also shows the utilization of service connectors to interwork between the RE and ML services. As previously described, an ML policy may include service connection information with requirements for an external service to interwork with a specified ML model(s) associated with the ML policy. Using this information and the service connector information found in a RE definition, this may allow the two services to interwork with each other. The service connector information may be used to specify both input and output data requirements as well as interworking functions that may be required for the services to work together. The interworking functions may process the data from the DT into a suitable format that will be recognized by the inputs to the ML model. Similarly, interworking functions may be needed to process outputs from ML models to a format suitable for DTs that is receiving the data. The interworking function may be part of the ML service or it may be part of a data preparation service separate from the ML sendee.

[0111] Using the room comfort use case as a basis, an event condition and action may be specified as:

[0112] Room. State 1. Event A. Condition: RoomDTl > 75 and Room.DT2 > 50

[0113] Room.Statel.EventA.Actionl: If EventA.Condition = True, set Room.DT3 =ON

[0114] Note that Room.DTl (temperature), Room.DT2 (humidity), and Room.DT3 (HVAC control) are references to data stored in DTs. Event A may be an event including both condition and action defined for Statel, which in this case represents the “Normal” state. To connect Event A to an ML model, the event condition and action may be specified as:

[0115] Room. Statel. EventA.Condition: serviceConnectorID(<ML service name>,<mlModel API>, <inputConnector(Room.DTl, Room.DT2), interworkingFunctionsQ)

[0116] Room. Statel. EventA. Action: serviceConnectorID(<ML service name>,<mlModel API>. outputConnector(Room.DT3), interworkingFunctions())

[0117] A serviceConnectorlD may be used to refer to the operating environment information required to connect to the external service identified by the service name. An ML model API may specify which ML model the service connector applies to. The inputConnector and outputConnector may identify the mappings of inputs and outputs respectively between the services and the interworkingFunctions may provide a list of processing functions that may be performed on input and output datato / from the ML model, RE, and DTs to seamlessly interface the services together. For example, DTI may need to be converted from °F to °C and DT2 may need to be scaled between 10 and 80 before passing the inputs to the ML model. The previous example for EventA may be revised as:

[0118] Room. Statel. Event A: serviceConnectorID(<ML service name>, <mlModelAPI>, inputConnector(inputA, inputB), interworkingFunctions(f2cFunc(Room.DTl, inputA), scaleFunc(Room.DT2, range(10,80), inputB))

[0119] In the revision, two interworking functions. 12cFunc and scaleFunc, have been specified to receive inputs from DTs to process data before it is sent to the ML model. The functions may be specified as part of the operating environment for the ML model and may be retrieved and installed as part of initialization of the virtual machine that is used to run the ML model. The outputs from the interworking functions are then sent as inputs to the ML model. Note the introduction of new signaling names inputA and inputB to make the connection between the interworking functions and the ML model.ML Replication of Rules with Events and State Transitions

[0120] For certain operational aspects of a given RE, a rule of an event or state transition from one event to another event may be replicated with ML models. For higher dimensionality rules where multiple inputs may be involved or multiple conditions exist for a state transition, an ML model may be more readily created and trained to account for thehigher dimensionality of inputs and state transitions than by specifying explicit rules. FIG. 7 shows an example where rules for events and state transitions may be replaced with trained ML models that capture the same functionalities as the explicit rules. Once again, the presence of service connectors is shown to show the interworking functions that may be required for the RE and ML services to work together.

[0121] For this scenario, the DT sy stem is more complex and there are now four inputs that need to be monitored: temperature, humidity, number of persons in the room, and time of day. With the added inputs, an ML model may be trained to account for other factors that may impact the comfort level of the room. Specifying explicit rules may be more cumbersome to incorporate the contributions of each input. Instead, an ML model may be trained to factor the four inputs based on generated data, e.g. using historical and / or synthetic data. For example, an ML model may be trained to turn on the HVAC system even though the temperature has not exceeded the upper threshold (e.g. 75 degrees) due to the large number of people present in the room and the time is early afternoon. The ML model may then replace one or more events and indicate actions to perform and state transitions to take. An example of the service connector may be:

[0122] Room. State 1. Event A: serviceConnectorID(<ML service name>, <mlModelAPI>, inputConnector(Room.DTl, Room.DT2, Room.DT3, Room.DT4), outputConnector(outputl->Room.DT3, output2->mlTransitionl))

[0123] Room. State 1.Transition: mlTransitionl

[0124] In this scenario, the event conditions and actions are completely replaced with only a reference to EventA. The specified service connector connects data from the DTs (e g. DTI, DT2, DT3, and DT4) to the ML model using positional notation (e.g. to inputl, input2, input3, and input4 respectively) for the inputConnector. The outputConnector connects outputl, which generates the action, is connected to DT5. Output2 is the ML model output that is associated with making the state transition connection, which is named mlTransistionl and connects to Room.Statel. Transition. The explicit mapping notation in the outputConnector makes it easier to separate the two outputs that connect to different aspects of the DT system.ML Replication of Rules with States

[0125] In certain instances where a state may be associated with multiple events and actions and with high dimensionality, it may be very cumbersome or even infeasible to definerules that fully emulate the functionality associated with such complexity'. For those scenarios, an ML model may be trained to replace the complex state and / or states. In fact, if an ML model is trained to replicate particular operations of a DT system, the ML model may be able to replace one or more states in the DT system. FIG. 8 shows an example of such a scenario of an ML model replacing multiple states.

[0126] Once again using the room comfort example, ML models may replace one or more states to incorporate predictive capabilities available with ML models. Using FIG. 8 as a reference, State 1 may incorporate the temperature (DTI) and humidity (DT2) rules previously defined. State 2, on the other hand, may incorporate predictions that an ML model may be trained to provide by proactively turning on or off the HVAC system. DT4 may represent date and time, DT5 may represent calendar of events with set times, and DT6 may represent number of people for each event. One or more ML models may be trained such that predictions are provided to proactively manage the comfort of the room. As an example, ML model(s) may receive information that an event is starting in five minutes where it is expected a large number of people will be attending. In addition, the ML model may have noticed that the temperature has been trending towards the upper threshold. Based on its training, the ML model may proactively turn on the HVAC system as a preemptive action before the room’s temperature reaches an uncomfortable level. The ML model may also be trained to differentiate various levels of comfort such that 69 to 71 degrees may represent optimal comfort while 72 to 75 degrees and 65 to 68 degrees are comfortable but may require actions pending other factors. Therefore, ML models may be able to capture finer levels of granularity than explicit rules can while offering a predictive component that explicit rules does not offer.

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

[0128] Room.Statel: serviceConnectorID(<ML service name>, <mlModel API>, inputC onnector(Room. DTI ->input 1 , Room. DT2->input2), outputC onnector(output 1 - >Room.DT3, output2->mlTransitionl))

[0129] Room.State2: serviceConnectorID(<ML service name>, <mlModel API>. inputConnector(Room.DT4->input3, Room.DT5->input4, Room.DT6->input5), outputConnector(output3->Room.DT7, output4->mlTransition2))

[0130] Room. Statel .Transition: mlTransitionl

[0131] Room. State2.Transition: mlTransition2

[0132] From the example, the ML model has five inputs and four outputs. The first two inputs (e.g. input 1 and input2) originate from inputs to Statel while the remaining inputs originate from inputs to State2. Note the explicit mapping connections made for each of the sendee connectors. In addition, there is no references to events conditions and actions as they have all been replaced by the ML model. For this case, the data from the DTs as well as state information of the DT system serve as interfaces to the ML models.

[0133] Note that the above examples show how to replace rules of a DT system with ML models may be made for event conditions and actions, for event and state transition, and finally for state or multiple states. Each replacement was described independently of each other but in actual deployments, a combination of one or more replacements may be made for a DT system depending on the availability and / or complexity of the ML models.RESTful Resource Embodiment

[0134] The ML-enabled DT system functionality proposed in this invention may be realized via services which support RESTful APIs. In one embodiment, the DT, RE, and / or ML services used to realize an ML-enabled DT system may support RESTful APIs. These APIs may be used by devices, users, applications, and other services to interface to the ML- enabled DT system. The RESTful APIs may support different resource types for each of the different capabilities of the DT, RE, and / or ML services. The resources may be stored and maintained locally by the DT, RE. and / or ML services. Alternatively, they may be stored and / or maintained elsewhere in the DT system such as by a storage service. Relationships between resources may be established and supported by the services of the DT system. The relationships may be supported by the resources supporting attributes specifically used to define relationships between the resources. Alternatively, the resources may be stored in a hierarchical fashion (e.g., within a tree structure). This hierarchy may define relationships between he resources. The resource structure may be divided into hierarchical order and an example is shown in FIG. 9. A top-level RESTful resource may be created and assigned to a DT system to host all information about the DT system within the resource. The top-level resource may contain collection resources for DTs in the system and a system definition, which may consist of event conditions and actions, states, state transitions of the DT system. If ML models are used, ML outputs resource may also be present to show' the outputs of theML models as well as the confidence level associated with the outputs. Alternatively, other types of resources and hierarchies may be defined for DT systems and services.

[0135] There may be additional information about the DT system that may be provided by the DT system identifier resource. A system description may be provided to describe the purpose and operation of the DT system. Within the system definition resource, information about the number of states and the operational status of the DT system may be made available. An Operation attribute may exist to allow the user to specify different operations for the DT system. For example, a user may specify whether the DT system is in configuration mode, training mode, or operational mode. During configuration mode, the user may be designing the DT system and specifying the events and states for the system. The DT system may also be placed in training mode to allow data received from physical devices to train ML models used to emulate the operations of the system.

[0136] When ML models are used to replace event conditions, actions, states, and / or state transitions, an ML policy may be added to the resource tree to provide information about the ML models and the corresponding sendee connection. In addition, information about service connectors that are used to interwork rules / policies to the ML models may also be provided. Graphical User Interface Embodiment

[0137] A graphical user interface (GUI) may be presented to users showing a state diagram of a DT system. The GUI may be one that is shown in FIG. 10. Various states may be shown with state transitions represented by arrows from one state to another state. The user may select a state and get relevant information about the state, such as the event conditions and actions as well as state transitions that state may have.Example Communications System

[0138] The 3rd Generation Partnership Project (3 GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE- Advanced standards, and New Radio (NR), which is also referred to as “5G". 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio accessis expected to consist of a new, non-backwards compatible radio access in new spectrum below 7 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.

[0139] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a w ide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultrareliable low-latency Communication (URLLC). massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle-to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I). Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of these use cases and others are contemplated herein.

[0140] FIG. 11A illustrates an example communications system 100 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 108B, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and V2X server (or ProSe function and server) 113, though it will be appreciated that the disclosed examples contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f,102g may be any t pe of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in FIGS. 11 A-5E as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

[0141] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 1 12. Base stations 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112. and / or V2X server (or ProSe function and server) 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109. the Internet 110, the other networks 112, and / or V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), aNode-B, an eNode B, aHome Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a. 114b may include any number of interconnected base stations and / or network elements.

[0142] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114b may be part of the RAN 103b / l 04b / l 05b. which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In some cases, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0143] The base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF). microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc ). The air interface 115 / 116 / 1 17 may be established using any suitable radio access technology (RAT).

[0144] The base stations 114b may communicate w ith one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b. over a wired or air interface 115b / l 16b / l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 118B / 116b / l 17b may be established using any suitable radio access technology (RAT).

[0145] The RRHs 118a, 118b, TRPs 119a. 119b and / or RSUs 120a. 120b. may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 118C / 116c / l 17c, which may be any suitable wireless communication link (e.g., radiofrequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c / l 16c / l 17c may be established using any suitable radio access technology (RAT).

[0146] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another over an air interface 115d / l 16d / l 17d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface118D / 116d / l 17d may be established using any suitable radio access technology (RAT).

[0147] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b. 102c, or RRHs 118a, 118b, TRPs 119a, 1 19b and RSUs 120a, 120b, in the RAN 103b / l 04b / l 05b and the WTRUs 102c, 102d, 102e, 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using wideband CDMA (WCDMA). 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).

[0148] In some cases, the base station 114a and the WTRUs 102a. 102b, 102c, or RRHs 118a. 118b, TRPs 119a, 119b. and / or RSUs 120a. 120b, in the RAN 103b / 104b / 108B and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or118C / 116c / l 17c respectively using Long Term Evolution (LTE) and / or LTE- Advanced (LTE-A). In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technologies and interface (such as Sidelink communications, etc.) The 3GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.)

[0149] In some cases, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a. 102b, 102c, or RRHs 118a, 118b, TRPs 119a. 119b and / or RSUs 120a. 120b, in the RAN 103b / l 04b / l 05b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access(WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM). Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0150] The base station 114c in FIG. 1 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In some cases, the base station 114c and the WTRUs I02e. may implement a radio technology such as IEEE 802. 11 to establish a wireless local area network (WLAN). In some cases, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802. 15 to establish a wireless personal area network (WPAN). In some cases, the base station 114c and the WTRUs 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 11 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0151] The RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, w hich may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) sendees to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0152] Although not shown in FIG. 11 A. it will be appreciated that the RAN 103 / 104 / 105 and / or RAN 103b / l 04b / 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0153] The core netw ork 106 / 107 / 109 may also sen e as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other netw orks 112.The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 108B or a different RAT.

[0154] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b. 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102e shown in FIG. 1 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0155] FIG. 1 IB is a block diagram of an example apparatus or device configured for wireless communications in accordance with the aspects illustrated herein, such as for example, a WTRU 102. As shown in FIG. 11B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicators 128, non-removable memory 130. removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an example. Also, in some cases the base stations 114a and 114b. and / or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), aNode-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 1 IB and described herein.

[0156] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, amicrocontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0157] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115 / 116 / 117. For example, in some cases, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In some cases, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In some cases, the transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0158] In addition, although the transmit / receive element 122 is depicted in FIG. 1 IB as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in some cases, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0159] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802. 11 , for example.

[0160] The processor 118 of the WTRU 102 may be coupled to. and may receive user input data from, the speaker / microphone 124. the keypad 126, and / or the display / touchpad / indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data tothe speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicators 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity' module (SIM) card, a memory' stick, a secure digital (SD) memory card, and the like. In some cases, the processor 118 may access information from, and store data in, memory’ that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0161] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.

[0162] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115 / 116 / 1 17 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by w ay of any suitable location-determination method while remaining consistent with an aspect.

[0163] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0164] The WTRU 102 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a w earable device such as a smart w atch or smart clothing, amedical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.

[0165] FIG. 11C is a system diagram of the RAN 103 and the core network 106. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 11C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a. 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an aspect of the disclosure.

[0166] As shown in FIG. 11C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an lub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a. 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encry ption, and the like.

[0167] The core network 106 shown in FIG. 11 C 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. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and / or operated by an entity7other than the core network operator.

[0168] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access tocircuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0169] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0170] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other sendee providers.

[0171] FIG. 1 ID is a system diagram of the RAN 104 and the core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 1 16. The RAN 104 may also be in communication with the core network 107.

[0172] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an aspect of the disclosure. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In some cases, the eNode-Bs 160a, 160b, 1 0c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to. and receive wireless signals from, the WTRU 102a.

[0173] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or dow nlink, and the like. As shown in FIG. 1 ID, the eNode-Bs 160a. 160b, 160c may communicate with one another over an X2 interface.

[0174] The core network 107 shown in FIG. 1 ID may include a mobility management gatew ay (MME) 162, a serving gateway 164, and a packet data network (PDN) gatew ay 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0175] The MME 162 may be connected to each of the eNode-Bs 1 0a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a. 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0176] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0177] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a. 102b, 102c and IP- enabled devices.

[0178] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched net orks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b. 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0179] FIG. 1 IE is a system diagram of the RAN 105 and the core netw ork 109. The RAN 105 may be an access service netw ork (ASN) that employs IEEE 802.16 radio technology7to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core netw ork 109 may be defined as reference points.

[0180] As shown in FIG. HE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an aspect of the disclosure. The base stations 180a, 180b, 180c may each be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In some cases, the base stations 180a, 180b, 180c may implement MIMO technology’. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

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

[0182] The communication link between each of the base stations 180a. 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0183] As shown in FIG. 1 IE, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core netw ork 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gatew ay 188. While each of the foregoing elements are depicted as part of the core netw ork109, it will be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0184] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched netw orks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA sen' er 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b. 102c with access to the netw orks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0185] Although not shown in FIG. 1 IE, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core netw orks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0186] The core network entities described herein and illustrated in FIGS. 11A, 15C, 15D, and 15E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in FIGS. 11 A, 15B, 15C, 15D, and 15E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.

[0187] FIG. 1 IF is a block diagram of an exemplary7computing system 90 in which one or more apparatuses of the communications networks illustrated in FIGS. 11 A, 15C, 15D and 15E may be embodied, such as certain nodes or functional entities in the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 1 10, or Other Networks 112. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality' of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array' (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein.

[0188] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data- transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 ty pically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.

[0189] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory^ (ROM) 93. Such memories include circuitry’ that allows information to be stored and retrieved. ROMs 93 generally contain stored data that may not easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory’ controller 92 mayalso provide a memory' protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it may not access memory within another process’s virtual address space unless memory sharing between the processes has been set up.

[0190] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94. keyboard 84. mouse 95, and disk drive 85.

[0191] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such 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). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

[0192] Further, computing system 90 may contain communication circuitry, such as for example a network adapter 97, that may be used to connect computing system 90 to an external communications network, such as the RAN 103 / 104 / 105, Core Network 106 / 107 / 109, PSTN 108, Internet 110, or Other Networks 112 of FIGS. 11 A, 15B, 15C, 15D, and 15E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.

[0193] FIG. 11G illustrates an example communications system 111 in which the methods and apparatuses described and claimed herein may be an aspect of. As shown, the example communications system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or several or all WTRUs A, B, C, D, E may be out of range of the network (for example, in the figure out of the cell coverage boundary shown as the dash line). WTRUs A, B, C form a V2X group, among which WTRU A is the group lead and WTRUs B and Care group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PC5) interface.

[0194] It is 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 which instructions, when executed by a processor, such as processors 118 or 91, cause the processor to perform and / or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless and / or wired network communications. Computer readable storage media include volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g.. tangible or physical) method or technology for storage of 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 technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.Definitions

[0195] Provided below are definitions for abbreviations found within the body of the disclosure.

[0196] Provided below are definitions for terms found within the body of the disclosure.

Claims

What is claimed:

1. A method comprising: receiving by an RE service one or more requests to create a Rule Engine (RE) definition for a Digital Twin (DT) system comprising one or more ML-enabled rules, wherein the ML-enabled rules comprise one or more ML-enabled event condition, action, state, and / or state transition; communicating with a DT service, a storage service, a Machine Learning (ML) service, or a combination thereof, according to the ML-enabled rules specified in the RE definition; and sending, by the RE service, one or more responses with a status to the one or more requests, wherein the one or more response comprise one or more of an overall status of creating the RE definition, an individual status for each ML-enabled rule, event condition, action, state, and / or state transition that was specified in the RE definition, and / or status for an interconnection of services between the RE and ML services.

2. The method of claim 1, wherein the RE definition further comprises ML policy information comprising at least one of a ML model ID, ML model inputs or ML model outputs.

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

4. The method of claim 1 , further comprising sending, by the RE service, DT updates to an ML model of the ML service based on the RE definition.

5. The method of claim 1, further comprising receiving, by the RE service, ML model outputs from the ML service.

6. The method of claim 5, further comprising updating, by the RE service, one or more DTs based on the received ML model outputs from the ML service.

7. The method of claim 1, further comprising detecting, by the RE service, abnormal output received from the ML service; and sending an indication to the ML service that retraining of a ML model is required.

8. An apparatus comprising: one or more processors; memory; and a set of computer-executable instructions stored in the memory that, when executed by the one or more processors, cause: receiving by an RE sendee one or more requests to create a Rule Engine (RE) definition for a Digital Twin (DT) system comprising one or more ML-enabled rules, wherein the ML-enabled rules comprise one or more ML-enabled event condition, action, state, and / or state transition; communicating with a DT service, a storage sendee, a Machine Learning (ML) sendee, or a combination thereof, according to the ML-enabled rules specified in the RE definition; and sending, by the RE service, one or more responses with a status to the one or more requests, wherein the one or more response comprise one or more of an overall status of creating the RE definition, an individual status for each ML-enabled rule, event condition, action, state, and / or state transition that was specified in the RE definition, and / or status for an interconnection of services between the RE and ML services.

9. The apparatus of claim 8, wherein the RE definition further comprises ML policy information comprising at least one of a ML model ID, ML model inputs or ML model outputs.

10. The apparatus of claim 8, wherein the RE definition further comprises service connector information defining DT inputs and outputs the RE service connects to 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 sending, by the RE service, DT updates to an ML model of the ML service based on the RE definition.

12. The apparatus of claim 8, wherein the computer-executable instructions, when executed by the one or more processors, further cause receiving, by the RE service, ML model outputs 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 updating, by the RE service, one or more DTs based on the received ML model outputs from the ML sendee.

14. The apparatus of claim 8, wherein the computer-executable instructions, when executed by the one or more processors, further cause detecting, by the RE service, abnormal output received from the ML service; and sending an indication to the ML service that retraining of a ML model is required.

15. A non-transitory, computer-readable medium comprising a set of computerexecutable instructions that, when executed by one or more processors, cause: receiving by an RE sen ice one or more requests to create a Rule Engine (RE) definition for a Digital Twin (DT) system comprising one or more ML-enabled rules, wherein the ML-enabled rules comprise one or more ML-enabled event condition, action, state, and / or state transition; communicating with a DT service, a storage sendee, a Machine Learning (ML) sendee, or a combination thereof, according to the ML-enabled rules specified in the RE definition; and sending, by the RE service, one or more responses with a status to the one or more requests, wherein the one or more response comprise one or more of an overall status of creating the RE definition, an individual status for each ML-enabled rule, event condition, action, state, and / or state transition that was specified in the RE definition, and / or status for an interconnection of services between the RE and ML sendees.

16. The non-transitory, computer-readable medium of claim 15, wherein the RE definition further comprises ML policy information comprising at least one of a ML model ID. ML model inputs or ML model outputs.

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

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

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

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

Images