Mechanisms for supporting the service layer of federated learning groups

Abstract

Methods and systems for service layer support of federated learning groups are described herein. In one embodiment, a method implemented by an application enabler server may include the steps of: receiving a first request to form a federated learning (FL) group; sending one or more requests to the core network to support FL operation; receiving one or more responses from the core network to the requests; and sending a response to the first request which includes one of the following: an FL group identifier, a list of FL clients associated with the FL group, a validity period or schedule for the FL group, or a combination thereof.

Description

Background Art

[0001] Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 518,652, titled "Mechanisms for Service Layer Support of Federated Learning Groups," filed on August 10, 2023, the entire contents of which are incorporated herein by reference for all purposes.

[0002] Application Layer Architecture Applications are becoming increasingly complex, and various mechanisms have been designed to support faster application deployment. One such mechanism is the introduction of different functional layers within (or adjacent to) the application layer to separate functions that can be accessed via application programming interfaces or APIs. Figure 1 shows an example of a generalized application layer architecture that separates application deployment into three distinct layers: an application-specific layer, a vertical application enabler layer, and a services layer. At the bottom of the application stack is the services layer, which provides common services to all applications. These services may include location management, group management, configuration management, and security aspects for application deployment. Above the services layer is the vertical application enabler layer, which manages services for specific vertical applications such as autonomous vehicles, drones, IoT, and gaming. At the top of the application stack is the application-specific layer, which services the specific applications within the vertical application. This layer contains custom logic or business logic for a particular application and can be provided by various service providers within the vertical application domain. One goal of this three-layered approach is to simplify application deployment for faster application deployment by consolidating common services for all applications into a vertical application enabler layer and a services layer.

[0003] The architecture shown in Figure 1 is based on a client-server communication model. One or more client applications on a device can communicate with one or more server applications on an application server. Note that a server application can reside in one or more application servers. Client and server applications at each layer communicate with each other between the device and the application server. Application-specific clients and servers can communicate with client and server applications at any of the lower layers, respectively. For example, an application-specific client can communicate with a client application at either the vertical application enabler layer or the service layer. The network between the client and server applications provides the medium for communication. The network can be a cellular network, such as a mobile operator network, or it can be a broadband service provider network that provides the client and server applications with access to the Internet.

[0004] It is worth noting that the architecture shown in Figure 1 can also be applied to publish-subscribe communication models and subscription-notification communication models. It is also worth noting that in a distributed deployment where devices communicate directly with other devices, server functionality can reside on the devices themselves rather than on the application server. In this case, devices can communicate with each other so that one device can act as a client and another can act as a server.

[0005] Application Data Analytics Enablement Service (ADAES) Architecture 3GPP defines the Application Data Analytics Enablement Service (ADAES), which is available to applications to access application-related analytics. The ADAES architecture is shown in Figure 2. As shown in the figure, an ADAE client communicates with an ADAE server using the ADAE-UU interface over the 3GPP network. The ADAE client resides on the user equipment (UE), and the ADAE server can reside on an application server (AS) or application function (AF). The figure also shows that the ADAE client and server are part of the Service Enabler Architecture Layer (SEAL), which may be similar to the service layer shown in Figure 1.

[0006] The ADAE layer supports generating application layer analysis for VAL servers and VAL clients. The generated analysis can include statistics or predictions associated with the analysis ID. Various analysis IDs, namely application performance, slice-specific and inter-UE application performance, location accuracy, service API, slice usage patterns, and edge load analysis, are currently supported. Data collection is also managed by the ADAE layer to enable the derivation of the corresponding analysis. Finally, the ADAE server has access to core network services through the N33, N6, and ADAE-OAM interfaces, as shown in Figure 2.

[0007] Edge Enabler Layer (EEL) Edge computing architectures enable communication and computing services to be closer to end devices in order to reduce end-to-end latency and to offload the network. Therefore, an edge enabler layer can be incorporated as part of the service layer, as described in Figure 1. Figure 3 shows an example of a layered application deployment architecture that incorporates functionality from the edge enabler layer, SEAL layer, application enabler layer, and application-specific layer. In relation to Figure 1, the edge enabler layer and SEAL layer can be considered together as a service layer that presents horizontal services to all applications.

[0008] Within the Edge Enabler Layer (EEL), Edge Enabler Servers (EES) and Edge Enabler Clients (EECs) provide services to User Equipment (UEs) in the Edge Data Network (EDN). Some of these edge services consist of service provisioning, registration, discovery, capability exposure, security, and service continuity. Application Clients (ACs) on the UE access edge services through the EEC, and Edge Application Servers (EAS) access edge services through the EES. The Edge Configuration Server (ECS) provides provisioning services that enable the EEC to connect with the ESS.

[0009] Service Enabler Architecture Layer (SEAL) As previously explained, the service layer can provide common services to all applications, regardless of their vertical orientation. In 3GPP, the Service Enabler Architecture Layer for Verticals (SEAL) provides such horizontal functionality to all applications. Some of the common services offered by SEAL include location management, group management, configuration management, identity management, key management, and network resource management. These services are independent of the vertical industry and can therefore be available to all applications. Each offered service can be associated with a corresponding management server, for example, a group management server that offers group services, and a location management server that offers location services.

[0010] As shown in Figure 3, a SEAL client residing on a UE can communicate with a SEAL server on the edge data network. However, the SEAL server can also operate independently of the edge data network, acting as an application server in the cloud data network. There are many other deployment scenarios within SEAL, and Figure 4 shows an example of support for a location-based group creation procedure in SEAL, utilizing both a group management server and a location management server. This procedure provides the ability for a group management client or VAL server to request the creation of a group (of UEs) based on a specific location provided in the request. The request is sent to the group management server, which then requests a list of UEs located in the indicated location from the location management server. The group management server creates the group from the list of UEs returned by the location management server and returns the response to the group management client or VAL server.

[0011] Associative Learning Federated Learning (FL) is a machine learning (ML) technique that enables the creation of models trained on distributed data across multiple clients or locations without the need to aggregate and store data in a single central location. An FL server manages multiple FL clients during training and / or inference, and data is kept private and stored locally on individual FL clients. One or more ML models and associated parameters are exchanged between the FL server and FL clients during training. The FL server aggregates model parameters (e.g., weights) in each round of federated training, and FL training is iterated over many rounds. This method has become increasingly popular in recent years as more and more organizations seek to leverage the power of large datasets without compromising the privacy of individual users and / or data sources. FL also offers the additional benefits of reduced data movement and improved scalability.

[0012] There is growing interest in incorporating federated learning within 3GPP cellular systems to leverage the abundant user devices (UEs) available and the associated data that UEs can provide for FL operations (e.g., training and / or inference). The federated learning requirements—frequent communication (e.g., between FL servers and FL clients), data privacy, and FL client availability—align with the strengths of cellular systems in providing ubiquitous access to a large number of subscribers that can act as FL clients.

[0013] Work has already begun to support FL operations by providing support for member selection and network performance exposure within the 3GPP core network. However, support at the application enablement layer for creating and managing FL groups during FL operations is not yet available. Furthermore, application enablers for FL operations, such as FL client registration, discovery, and selection, do not currently exist in the existing 3GPP-defined application enabler layer. Therefore, application users who wish to deploy FL operations on 5G systems are unable to do so. [Overview of the project] [Means for solving the problem]

[0014] Support for some federated learning operations is already defined within the 3GPP 5G cellular core network, with new analytics and network exposures added to assist in creating and managing federated learning groups. However, to leverage these new core network functionalities, the 3GPP-defined application enabler layer lacks complementary federated learning support. Such support is crucial for enabling federated learning processes and procedures for use by applications from different application service providers / vertices. This disclosure proposes both enhancements to existing procedures and the introduction of new procedures for complete federated learning integration within 5G cellular systems.

[0015] This disclosure describes methods and systems for supporting federated learning integration in the application enabler layer within a 5G cellular system. In one embodiment, a method for an application enabler server to create an FL group may include receiving a first request for forming a federated learning group, the request including one or more of the following: an FL server identifier, an FL policy, an FL client list (e.g., a UE identifier), an FL client capability, a minimum number of FL clients, an FL QoS requirement, a location of interest, an enable network analysis indicator, a number of training rounds, an FL training schedule, a time window recommendation, and a policy expiration date. In some cases, an FL policy includes one or more of the following: client / server identifier, FL policy identifier, application identifier, ML model / algorithm, ML application type, FL capability, FL client requirements, dataset requirements, available datasets, dataset capability, dataset identifier, ML application type, dataset description, dataset size, dataset age, target feature, feature list, feature identifier, feature name, data format, dataset metadata, and related features.

[0016] The method may also include sending one or more requests to the cellular 5G core network for assistance with federated learning operations. In some cases, the method may include sending a second request for assistance in selecting UE members from the 5G network, which may include one or more UE member filtering criteria, such as QoS requirements, access type, FL operation transfer time, UE location, and mobility information. In some cases, the method may include sending a third request for an AF session with QoS, which may include QoS requirements for FL operations and a list of UEs that should act as FL clients.

[0017] The method may also include receiving responses to one or more requests from a cellular 5G core network. In some cases, the response may include a response to a second request having a list of candidate UEs that match UE member filtering criteria. In some cases, the response may include a response to a third request having one or more of the following: expected UE movement trajectory, stationary indication, communication duration, periodic time, scheduled communication time, battery indication, traffic profile, scheduled communication type, and expected time and day of the week in the trajectory.

[0018] In some cases, the method may include sending a response to the first request, the response may include one or more of the following: an FL group identifier, a list of FL clients associated with the FL group, and the validity period and / or schedule for the FL group.

[0019] In another embodiment, the method by which an application enabler server performs FL group management may include receiving a first request to form a federated learning group, the request including one or more of the following: FL server identifier, FL policy, FL client list (e.g., UE identifier), FL client capability, minimum number of FL clients, FL QoS requirements, location of interest, enable network analysis indicator, number of training rounds, FL training schedule, time window recommendation, and policy expiration date. In some cases, the FL policy includes one or more of the following: client / server identifier, FL policy identifier, application identifier, ML model / algorithm, ML application type, FL capability, FL client requirements, dataset requirements, available dataset, dataset capability, dataset identifier, ML application type, dataset description, dataset size, dataset age, target features, feature list, feature identifier, feature name, data format, dataset metadata, and related features.

[0020] In some cases, the method may include sending a response to the first request, the response may include one or more of the following: an FL group identifier, a list of FL clients associated with the FL group, and the validity period and / or schedule for the FL group.

[0021] In some cases, this method may include sending one or more subscription requests that should be notified of changes in the FL client's location and / or QoS flow.

[0022] In some cases, this method may include sending one or more subscription requests to receive analysis on the FL client from analysis functions in the network, including from the application analysis server.

[0023] In some cases, the method can include receiving notifications of changes to the location, QoS flow, and / or analysis output for one or more FL clients.

[0024] In some cases, the method can include updating the members of the FL group according to the notifications received for the subscription.

[0025] In another aspect, a method for an application enabler server to support FL registration can include receiving a request for registering FL capabilities, the request including one or more of FL indication support, client / server identifier, FL policy identifier, application identifier, ML model / algorithm, ML application type, FL capabilities, FL client requirements, dataset requirements, available datasets, dataset capabilities, dataset identifier, ML application type, dataset description, dataset size, dataset age, target features, feature list, feature identifier, feature name, data format, dataset metadata, and related features.

[0026] In some cases, the method can include processing the request to authenticate and authorize the requester, assigning an identifier for the FL policy, creating a context for the FL policy identifier, and associating and storing the FL information within the context with a RESTful resource.

[0027] In some cases, the method can include sending a response to the request, the response including a status for the registration request and an FL policy identifier.

[0028] This summary is provided to introduce, in a simplified form, a selection of concepts that are further described in the detailed description below. 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. Further, the claimed subject matter is not limited to features that solve any or all of the disadvantages described in any part of this disclosure. **Brief Description of the Drawings**

[0029] [Figure 1] A diagram showing an application layer architecture model. [Figure 2] A diagram showing an Application Data Analytics Enablement Service (ADAES) architecture model. [Figure 3] A diagram showing a hierarchical application architecture using edge computing. [Figure 4] A diagram showing support for location-based group creation in the Service Enabler Architecture Layer (SEAL). [Figure 5] A diagram showing an example of Federated Learning (FL) client and FL server deployment. [Figure 6] A diagram showing a Federated Learning Application Enabler layer architecture. [Figure 7] A diagram showing enhanced EDGEAPP registration. [Figure 8] A diagram showing the ADAE registration procedure. [Figure 9] A diagram showing the FL client discovery and selection procedure. [Figure 10] A diagram showing the single-request FL group creation procedure. [Figure 11] A diagram showing SEAL-based FL group creation. [Figure 12] A diagram showing the dynamic FL group management procedure. [Figure 13]This diagram shows the analytics-driven FL group management procedure. [Figure 14] This diagram shows a graphical user interface (GUI) for managing FL groups. [Figure 15A] This figure shows an exemplary communication system, which may be an embodiment of the methods and apparatus described and claimed herein. [Figure 15B] This is a block diagram of an exemplary apparatus or device configured for wireless communication. [Figure 15C] This is an illustrative system diagram of a radio access network (RAN) and core network. [Figure 15D] This is another exemplary system diagram of the RAN and core network. [Figure 15E] This is another exemplary system diagram of the RAN and core network. [Figure 15F] This is a block diagram of an exemplary computing system. [Figure 15G] This is a block diagram of another example communication system. [Modes for carrying out the invention]

[0030] Before enabling federated learning support at the application enabler layer, it is crucial that the FL server and FL client register their capabilities with an enabler server, such as an Edge Enabler Server (EES). An EES can be an ideal server for incorporating federated learning support as a server interface to both the Edge Application Server (EAS) and Edge Enabler Client (EEC). Using Figure 3 as a reference, the EAS and EEC (running, for example, on the UE) can function as the FL server and FL client, respectively. Thus, the EES can manage the federated learning behavior by incorporating FL registration, FL client discovery, and FL client selection as additional edge services supporting federated learning. Alternatively, the EES can natively incorporate FL server capabilities and provide FL services to the EEC. Figure 5 shows an exemplary embodiment of the FL client and FL server in the edge computing deployment scenario shown in Figure 3.

[0031] Similarly, the ADAE server can be used to support federative learning integration. The ADAE architecture supports data collection and application-related analysis for the VAL server and VAL client. In addition, the ADAE server has access to core network services that can be used to assist in FL client selection. As a result, the ADAE server and ADAE client can also be ideal candidates for supporting federative learning. Within the ADAE architecture shown in Figure 2, the ADAE client can support FL client functionality, and the VAL server and / or ADAE server can support FL server functionality.

[0032] It can also be such that an application enablement layer is defined to support federated learning. An example of such an architecture is shown in Figure 6. An FL client may reside within the UE and have an FL-C interface with a VAL client on the UE. Similarly, an FL server may reside in a cloud or edge network with an FL-S interface to the VAL server and may also have an FL-NW interface with a 3GPP network. The FL client communicates with the FL server using an FL-UU interface over the 3GPP network.

[0033] In the following, solutions will be deployed either by enhancing existing procedures or introducing new ones, by supporting federative learning integration in the application enabler layer. While the following solutions can focus on the edge enabler layer and the application data analytics enabler layer, it should be noted that other application enabler layers, such as SEAL and / or SEAL Data Delivery (SEALDD), can also be enhanced to support federative learning.

[0034] Enhanced registration for collaborative learning The edge enabler layer is an ideal layer in which federated learning can be incorporated. As shown in Figure 3, the EEC, EES, and ECS all cooperate to provide edge computing services to the UE and EAS. The application client (AC) and / or EEC on the UE can provide FL client functionality, and the EAS can provide services associated with the FL server. The edge enabler layer can provide communication services for model and model parameter exchange between the FL server and FL client, and can also support FL client discovery, selection, and management. Existing procedures in the EEL can be enhanced to integrate federated learning, and Figure 7 shows an exemplary call flow of such an enhancement. The enhancement may include sharing information about federated learning among various entities within the edge enabler layer. An example of federated learning information is shown in Table 1.

[0035] [Table 1-1]

[0036] [Table 1-2]

[0037] The FL client can provide information about federative learning operations as part of the registration procedure within the edge enabler layer (for example, via AC registration or EEC registration). The FL client can share information with the EES about datasets that the FL client may have that are available for FL operations, including the number of datasets available for training and / or inference, the type of ML application to which the dataset applies, a description of the dataset, the dataset size and age, the target feature name or identifier, a list of features found in the dataset, and other information about each feature (e.g., data format, metadata, related features, etc.). In addition, dataset processing capacity may be provided by the FL client to enable feature engineering of the dataset if additional features can be created to meet the dataset requirements.

[0038] Similarly, the FL server can also provide information about federative learning behavior as part of EAS registration. The FL server can provide the EES with federative learning training and / or inference requirements to assist in the creation and management of FL client groups. The FL server can specify FL training / inference, ML application type, FL capability, FL client requirements, dataset requirements, and the ML model / algorithm to be used with the desired dataset capability.

[0039] The information shown in Table 1 can be grouped together as a federated learning policy and assigned a policy identifier. This identifier can be included as part of the AC profile and shared within the edge enabler layer, as shown in the example in Figure 7. The FL policy identifier can be referenced between the FL client (e.g., AC or EEC) and the FL server (e.g., EAS) during configurations and operations that support federated learning.

[0040] Step 1: FL policies can be provisioned to the AC, EEC, and / or EAS as part of FL integration. FL policies may include information about FL clients / servers, as shown in Table 1. Additionally and / or alternatively, indicators can be provisioned to inform the AC, EEC, and EAS of federated learning capabilities. Provisioning of FL information can be done in the AC / EEC as shown in Step 1a, or in the EAS as shown in Step 1b.

[0041] Step 2: Once an FL policy is provisioned to the AC, the AC can share information with the EEC on the UE via federated learning support (for example, by making an AC registration request). The FL policy can be sent as part of the AC profile or may include indicators to specify federated learning capabilities. Additionally and / or alternatively, the AC may request FL services in a list of requested EEC services or a list of EAS characteristic information elements, which may be included in the request message.

[0042] Step 3: The EEC can perform AC request verification, for example, by inspecting security certificates to authenticate and authorize the AC. The EEC can assign identifiers for FL policies and associate them with FL information provided in the request, create a context for the FL policy identifiers, and associate and store the FL information with a context in the RESTful resources maintained by the EEC.

[0043] Step 4: The EEC may return a response to the AC with the status of the request and the assigned FL policy identifier. Additionally and / or alternatively, the EEC may return an indicator in the list of permitted EEC service information elements that the federated learning service is permitted.

[0044] Step 5: The EEC can perform EEC registration with the EES, and the registration may include indicators of FL policies and / or federated learning capabilities. The request may also include an EAS selection request indicator information element to request assistance from the EES for EAS selection, for example, to enable FL client discovery and selection by the EAS as part of the FL service. Alternatively, new information elements such as permitted FL client discovery and selection may be included in the request. New information elements may be used by the EES as part of user consent, thereby signaling the EEC (and therefore the FL client) its intention to participate in federated learning operations.

[0045] Step 6: The EES can perform EEC request verification, for example, by inspecting security certificates to authenticate and authorize the EEC. The EES can further process the request and determine whether it can provide the services requested by the EEC (for example, specified in the AC profile and / or federated learning related information elements). If the EEC specifies requirements for FL services, the EES can add the Application Client (AC) / EEC identifier along with the associated FL information (for example, as shown in Table 1) to the FL client pool. The FL client pool can be used in FL client discovery and selection to form FL groups. The EES can also assign FL policy identifiers to EECs to which information about FL service operation can be associated. Note that FL policy identifiers maintained by the EEC and EES can be the same or different from each other.

[0046] Step 7: If the EEC context ID and source EES endpoint IE were included in the registration request, the EES can further process the request.

[0047] Step 8: The EES may return a response to the EEC, which may include the status of the registration request and whether FL services are enabled for the EEC via an indicator. Additionally and / or alternatively, FL service indications may be included as part of the AC profile. FL service indicators may specify whether the requester can act as an FL client or server and whether the requester can participate in FL operations. If FL services are enabled, an FL configuration identifier may also be returned in the response, or the presence of an FL configuration identifier may signal that FL operations are permitted. FL configuration identifiers may be used by the AC / EEC to update the information found in Table 1.

[0048] Step 9: An EAS interested in acting as an FL server (for example, by offering an FL service) can demonstrate such capability in an EAS registration request to the EAS. The EAS may be provisioned and / or configured with FL information as shown in Step 1b. The EAS profile may be enhanced to include an FL policy containing federated learning-related information as shown in Table 1. Additional and / or alternative, an FL capability indicator may be added to the EAS policy. The FL capability indicator may specify whether the requester will act as an FL server or an FL client, and whether the requester has given consent to participate in FL operations, for example, to discover and select clients for FL operations. FL policies may be pre-provisioned for each entity, and FL capability indicators may be used to trigger FL services and operations.

[0049] Step 10: The EES can perform authorization checks to verify whether the EAS is eligible to register with the EES. During authorization, the EES can assign an identifier for the FL policy, create an internal context for the EAS profile, and locally store the information in a RESTful resource maintained by the EES.

[0050] Step 11: EES can return the FL policy identifier and status in the response message to EAS.

[0051] In some deployments, to simplify communication overhead with FL operations, the EES may also be provisioned with FL policies, or the EES may receive FL policies from the Edge Configuration Server (ECS) during EES registration. In such deployments, the AC, EEC, and EAS registration procedures may be simplified so that only an FL indicator is provided to indicate user consent to participate in FL operations.

[0052] The procedure described in Figure 7 is an enhancement to the existing edge registration procedures for AC, EEC, and EAS for communicating support for federative learning. For FL integration with other application enabler layers, new procedures can be proposed to enable support for federative learning in those enabler layers. As an example, a new registration procedure can be added to the ADAE architecture for ADAE clients and VAL servers / clients to communicate their FL capabilities to the ADAE server. Figure 8 proposes an exemplary ADAE registration procedure in which ADAE clients and VAL servers can register their FL capabilities with the ADAE server, similar to the edge enabler procedure. Note that the registration procedure can be performed in any order; for example, the VAL server can register before the ADAE client.

[0053] Step 1: An FL policy can be provisioned to the ADAE client and / or VAL server / client as part of the FL integration. The FL policy may include information about the FL client / server as shown in Table 1. Additionally and / or alternatively, indicators can be provisioned to inform the ADAE client or VAL server / client of federated learning capabilities. Provisioning of FL information can be done on the ADAE client as shown in Step 1a, or on the VAL server as shown in Step 1b. Note that although not shown in the diagram, an FL policy can also be provisioned to the VAL client, which can then communicate its support for federated learning to the ADAE client.

[0054] Step 2: The ADAE client can send a new registration request to the ADAE server, which may include information about the client identifier, security certificate, and FL policy. Additionally and / or alternatively, the request may include an indicator of the ADAE client's support for federated learning. The indicator can signal user consent to discover and select the ADAE client for participation in the federated learning operation. An example of FL registration request parameters is shown in Table 2.

[0055] [Table 2]

[0056] Step 3: The ADAE server can process requests, including checking security certificates to authenticate and authorize ADAE clients. The ADAE server can assign identifiers for FL policies and associate them with ADAE clients, create contexts for FL policy identifiers, and store FL information in contexts within RESTful resources maintained by the ADAE server.

[0057] Step 4: The ADAE server can return a response to the ADAE client with the status of the request and the assigned FL policy identifier. Additionally and / or alternatively, the ADAE server can return an indicator that the federated learning service is permitted for the ADAE client.

[0058] Step 5: A VAL server interested in offering FL services may indicate such capability in a registration request to the ADAE server, and the request may include information from the VAL server identifier, security certificate, and FL policy. The VAL server may have been provisioned and / or configured with FL information in Step 1b. Additionally and / or alternatively, FL capability indicators may be included in the request.

[0059] Step 6: The ADAE server can process the request, including checking security certificates to authenticate and authorize the VAL server. The ADAE server can assign an identifier for the FL policy and associate it with the VAL server, create a context for the FL policy identifier, and store the FL information, associating it with the context in the RESTful resource maintained by the ADAE server.

[0060] Step 7: The ADAE server can return a response to the VAL server with the status of the request and the assigned FL policy identifier. Additionally and / or alternatively, the ADAE server can return an indicator that the federated learning service is permitted for the VAL server.

[0061] Figure 7 illustrates the registration procedure for the ADAES architecture, but it should be noted that it can be easily applied to other application enabler layers, such as the Service Enabler Architecture Layer (SEAL). For example, the basis of the registration procedure, which provides FL policies or information from FL policies, can be shared with the SEAL server to indicate the requesting FL capability.

[0062] The registration procedures in Figures 7 and 8 share a common element: the FL policy is communicated to the EES / ADAE server to demonstrate support for federated learning. The information in the FL policy can be used not only to indicate FL capability, but also to assist with FL client discovery and selection, FL group creation, and FL group management. These procedures are described in more detail below.

[0063] Client discovery and selection After an application enabler server (e.g., an EES or ADAE server) is informed of the FL clients and their capabilities, the application enabler server can support FL client discovery and selection procedures to form FL groups. Figure 9 shows an exemplary procedure in which the EAS requests FL client discovery from the EES and can use the discovery results to select FL clients to include in an FL group that can be used for federated training and / or inference. In this case as well, an enhancement to the existing procedure at the edge enabler layer is proposed.

[0064] Step 1: The EAS can send an AC information subscription request to the EES to discover all ACs (and therefore FL clients) that support federated learning. In the request within the filter information element, the EAS may include information from FL policies to be matched (e.g., as shown in Table 1) and other filter parameters such as geographic service area, UE location and identifier (if known), and operational schedule. To minimize the size of the AC profile sent in response to the request, the EAS may include a discovery level information element that further filters the information returned to the EAS. For example, the discovery level could indicate all information in the AC profile, including all information in the FL policy, or the discovery level could request only information from the FL policy. Other embodiments for finer granularity levels can be assumed to filter the information included in the response.

[0065] Step 2: The EES can inspect the EAS's security credentials to verify that the EAS is authorized to perform its operations. Authorization checks may include verifying that the EAS is authorized to perform FL operations within the Edge Data Network (EDN). If authorized, the EES can match the FL information provided by the EAS with information on FL clients in a client pool that the EES can manage to fulfill FL client discovery requests.

[0066] Step 3: The EES can return to the EAS the status of the request and the AC information associated with the FL client that fulfills the FL client discovery request. The returned AC information may include information from the FL policy from Table 1, such as client identifier, application identifier, ML model / algorithm, ML application type, FL capability, available dataset, dataset capability and information. If a discovery level filter is provided in the request, the EES can further filter the results and return only the information specified by the discovery level filter.

[0067] Step 4: If the EAS does not have a UE identifier for the FL client received in the response from the EES in Step 3, the EAS may perform a UE identifier request to obtain a UE identifier. The EAS can then use the UE identifier to make further API requests to the EES and the 5G network. It should also be noted that the EAS may also perform a UE identifier request independently of the information returned in Step 3, for example, if the EAS is provisioned with information about the FL client and / or AC profile. In addition and / or alternatively, the EAS may also provide the EES with the discovery criteria described in Step 1, which the EES can use to perform FL client discovery.

[0068] Step 5: The EES can use the information provided in the UE identifier request to find the requested UE identifier. The EES can, for example, communicate with the 5G network via the Network Exposure Function (NEF) to obtain the UE identifier. The EES can then filter the results to obtain a list of only the UEs that can act as FL clients.

[0069] Step 6: The EES returns a status for the UE identifier request and can include a list of UE IDs in the EAS. The EAS can then use the UE identifiers in future edge API calls for federated learning operations.

[0070] Step 7: EAS may also be interested in locating UEs within a specific service area in order to fulfill FL training requirements and make UE location requests to EES. The requests may include UE identifiers and location granularity for the service area of ​​interest to EAS. EAS may make multiple UE location requests for all UEs of which EAS may be interested in FL operation. Similar to Step 4, EAS may also include discovery criteria in the requests to EES described in Step 1.

[0071] Step 8: The EES can either inspect the 5G network to find the UE's location or respond to the UE's location request using the UE's valid locally cached location. The EES can then filter the results to obtain a list of only the UEs that can act as FL clients.

[0072] Step 9: EES can return a list of UEs in its response to EAS.

[0073] Step 10: An EAS presenting an FL service can send an FL group creation request to the EES to form an FL group for associative learning operations. The request may include information such as that shown in Table 3.

[0074] [Table 3]

[0075] Step 11: The EES can examine the security proof of the EAS for authentication and authorization purposes. During authorization, the EES can assign identifiers for FL groups, create a context for associating the information received in the request with the FL groups, and store the information in a RESTful resource within the EES or externally in a data storage entity. The EES can perform FL member selection by examining FL policy information in the AC profile. The EES can also communicate with the 5G network to perform member selection based on requirements provided by the EAS. The EES can call the Nnef_AFsessionWithQoS API with QoS requirements for FL operation and provide a list of UEs that should act as FL clients. The 5G network can respond with results for the request, which may include expected UE movement trajectories, stationary indications, communication duration, periodic time, scheduled communication time, battery indications, traffic profile, scheduled communication type, and expected time and day of the week in the trajectory. The EES can store the information received in the response from the 5G network in a RESTful resource. As an addition and / or alternative, the EES can subscribe to UE member selection assistance from the 5G network by providing UE member filtering criteria, such as QoS requirements, access type, FL operation transfer time, UE location, and mobility information. Accordingly, the 5G network can send notification messages to the EES with a list of candidate UEs that match the UE member filtering criteria. It should be noted that the EES may communicate with the 5G network in a different order than described, and may request UE member selection assistance before calling the Nnef_AFsessionWithQoS API, for example.

[0076] Step 12: The EES can send a notification to all selected EECs (e.g., UEs) of their selection to be part of an FL group. The notification may include a subscription identifier, any previously provisioned FL policy identifiers, an assigned FL group identifier, group management actions to be performed (e.g., add, remove, etc.), and a schedule for when the federated actions can be enabled. Note that the FL policy identifier may indicate what type of FL action (e.g., training, inference, etc.) is required for the FL group.

[0077] Step 13: The EEC may return an acknowledgment to the EES, in which the EEC may specify whether the client is able to perform the federated action on the desired schedule.

[0078] Step 14: EES can return an FL group creation response containing the status of the request, an FL group identifier, and a list of FL clients associated with the FL group. The response may also include the time limit and / or schedule for the FL operation. Other information, such as that found in the FL policy associated with each FL client, may also be returned in the response. To protect the privacy of FL clients, the list of FL client identifiers may be anonymized.

[0079] The previous procedure requires more interaction between FL clients (e.g., EEC, ADAE clients) and FL servers (e.g., EAS, VAL servers) using application enabler servers (e.g., EES, ADAE servers) to support federated learning integration. In some deployments where provisioning can be used to facilitate federated learning adoption, a simpler procedure can be proposed to allow EAS and VAL servers to request the creation of FL groups in a single request. This new procedure can combine FL client discovery, selection, and FL group creation into a single request. An example of such a procedure is shown in Figure 10. Note that in this example, the FL policies or information required for federated learning integration can be pre-provisioned to each entity, such as the ADAE client, ADAE server, and VAL server. This procedure can be applied to ADAES and / or SEAL architectures, which do not define a registration procedure, thus simplifying federated learning integration at the application enabler layer.

[0080] Step 1: FL policies can be pre-provisioned to ADAE clients, ADAE servers, and VAL servers as part of federated learning integration. The provisioned information can be those shown in Table 1 for each entity. Note that, although not shown in the diagram, FL policies can also be provisioned to VAL clients, which can then communicate federated learning support to ADAE clients.

[0081] Step 2: An FL user can decide to create an FL group via a VAL server to train an ML application in a federated manner. The VAL server can send an FL group creation request to an ADAE server, which can then manage the FL group during training and / or inference. This request may include information, such as that shown in Table 3, to help the ADAE server discover and select appropriate FL clients to participate in the federated operation. The request may include explicit indicators for FL client discovery and selection, and the selected FL clients can then be grouped together into an FL group for further FL operations. Alternatively, the request can implicitly infer FL client discovery and selection using FL group creation.

[0082] Step 3: The ADAE server can process the request by first authenticating the VAL server and then checking the VAL server's authorization to make the request. Once authorized, the ADAE server can first query the FL client pool to find FL clients that can fulfill the FL training requirements sent by the VAL server. The ADAE server can then select from the discovered FL clients to become part of an FL group, for example, to fulfill a minimum number of FL clients. The ADAE server can then create the FL group and assign an identifier for it. In addition, the ADAE server can also create a context for associating the information received in the request with the FL group and store the information in a RESTful resource within the ADAE server or externally in a data storage entity. Furthermore, the ADAE server can also communicate with the 5G network to perform member selection based on the requirements provided by the VAL server. The ADAE server can call the Nnef_AFsessionWithQoS API with the QoS requirements for FL operation and a list of UEs that should act as FL clients. The ADAE server can store the response from the 5G network in a RESTful resource. As an addition and / or alternative, the ADAE server can subscribe to UE member selection assistance from the 5G network by providing UE member filtering criteria, such as QoS requirements, access type, FL operation transfer time, UE location, and mobility information. Accordingly, the 5G network can send notification messages to the ADAE server with a list of candidate UEs that match the UE member filtering criteria. It should be noted that the ADAE server may communicate with the 5G network in a different order than described, and may request UE member selection assistance before calling the Nnef_AFsessionWithQoS API, for example.

[0083] Step 4: The ADAE server can send a notification to all selected ADAE clients (e.g., UEs) of their selection to be part of an FL group. The notification may include a subscription identifier, a previously provisioned FL policy identifier, an assigned FL group identifier, the group management action to be performed (e.g., add, remove, etc.), and a schedule for when the federated action can be enabled. Note that the FL policy identifier can indicate what type of FL action (e.g., training, inference, etc.) is required for the FL group.

[0084] Step 5: The ADAE client can return an acknowledgment to the ADAE server, in which the ADAE client can specify whether the client is able to perform the federated action on the desired schedule.

[0085] Step 6: The ADAE server can request the 5G network to provide the required QoS for the FL clients in the FL group. The ADAE server can execute the Nnef_AFsessionWithQoS API if it has not already been called in Step 3 with a list of UE addresses and QoS information for the UEs in the FL group. The 5G network can return a result for each UE identified in the UE list found in the request.

[0086] Step 7: The ADAE server may return a response to the VAL server containing the status of the FL group creation request, the FL group identifier, a list of FL client identifiers selected for the group, and the validity and / or schedule of the FL operation. Other information, such as that found in the FL policy associated with each FL client, may also be returned in the response. To protect the privacy of FL clients, the list of FL client identifiers may be anonymized.

[0087] The procedure in Figure 10 illustrates an enhancement of the ADAE service to support federated learning. Other embodiments can also be implemented to add support for federated learning. For example, the aforementioned SEAL location-based group creation procedure shown in Figure 4 can also be enhanced for federated learning. Figure 11 shows an example of enhancing the SEAL group and location management server to support federated learning. A location management client, which is part of the SEAL layer and can be considered a SEAL client, can demonstrate support for federated learning as part of the location service registration procedure. In that case, the location-based group creation procedure in the group management server can be enhanced with FL-aware filtering criteria to search not only for UEs in a specific location but also for UEs that are FL-aware. Note that within the SEAL architecture, location management clients and group management clients can also be considered SEAL clients, and this extends to other management clients within the SEAL architecture.

[0088] Step 1: For example, a location management client residing on a UE that supports FL client functionality can perform location service registration with a location management server. The location management client and server can be part of the SEAL layer, with the client residing on the UE and the server residing in the network. The location service registration request may include additional information about the FL capabilities supported by the FL client, such as those shown in Table 1. Alternatively, the location management client can provide indications for support for federated learning in the registration request. In addition, FL policies can be pre-provisioned to the VAL server and ADAE server as part of the federated learning integration. The provisioned information can be those shown in Table 1 for each entity.

[0089] Step 2: The VAL server can make a location-based group creation request that may include the desired location and an indication that the UE is FL-enabled. This request may include information such as that shown in Table 3 to help the location management server discover and select the appropriate FL clients to participate in federated operations.

[0090] Step 3: The group management server can communicate with the location management server to obtain a list of UEs that can be found at the desired location and have FL capability. The group management server receives the list of UEs that realize the location using FL capability and can store that list internally.

[0091] Step 4: The group management server can return a response to the location-based group creation request that includes the status of the request, a group identifier, and a list of UEs that meet the location and FL capability criteria.

[0092] Step 5: The VAL server can use the list of UEs received from the group management server as input to the FL group creation request sent to the ADAE server. The ADAE server can assist the VAL server in managing FL groups due to UE mobility entering and leaving the desired location. For example, the ADAE server can dynamically manage the addition of UEs to and removal of UEs from FL groups. In addition, the ADAE server can also use analytics to predict when FL-enabled UEs should be added to and removed from FL groups.

[0093] Step 6: As part of processing requests, the ADAE server can notify ADAE clients (i.e., FL clients) of their selection to an FL group. The notification may include the subscription identifier, any previously provisioned FL policy identifiers, the assigned FL group identifier, the group management actions to be performed (e.g., add, remove, etc.), and the schedule for when the federated actions can be enabled. Note that the FL policy identifier may indicate what type of FL action (e.g., training, inference, etc.) is required for the FL group.

[0094] Step 7: The ADAE server may return a response to the VAL server containing the status of the FL group creation request, the FL group identifier, a list of FL client identifiers that have been notified and accepted for inclusion in the FL group, and the validity and / or schedule of the FL operation. Other information, such as that found in the FL policy associated with each FL client, may also be returned in the response. To protect the privacy of FL clients, the list of FL client identifiers may be anonymized.

[0095] The procedure in Figure 11 proposes enhancing both the location management procedure and the group management procedure by adding an FL-aware indicator to the corresponding request. The enhancement can be limited to the group management server only, or the enhanced functionality can instead be added to the ADAE service using the ADAE server with an existing interface to the group management server as part of the FL group creation request. The ADAE server can use the location-based group creation procedure to first find all UEs in a particular location and then create an FL group based on notification responses received from ADAE clients (e.g., FL clients) that agree to be included in the FL group.

[0096] It should be noted that the procedures shown in Figures 10 and 11 represent a combination of FL client discovery, selection, and FL group creation in the ADAES architecture. It should be apparent to those skilled in the art that the procedures can also be applied to the edge enabler layer, the service enabler architecture layer (SEAL), and other application enabler layers.

[0097] FL Group Management One of the main benefits of integrating federated learning capabilities with application enabler servers such as EES or ADAE servers is that the application enabler server can dynamically manage FL groups in response to changes in FL client availability, for example, as a result of UE mobility. The application enabler server may have access to cellular network APIs that can determine UEs in specific areas of interest. Furthermore, network analysis can be used to predict UE mobility to specific areas of interest, enabling more proactive FL group management.

[0098] Figure 12 illustrates an exemplary procedure for dynamic FL group management, where UE2 (i.e., EEC2) can leave the area of ​​interest and UE1 (i.e., EEC1) can move into the area of ​​interest. The EES managing the FL group can dynamically modify the group by removing EEC2 and adding EEC1. The EAS acting as the FL server can be offloaded from making such decisions to minimize the signaling overhead for such management tasks, which can be easily performed by the application enabler server.

[0099] Step 1: EEC1, EEC2, and EAS may have registered their FL support and capabilities with EES, and FL groups may have been created as previously described. Initially, EEC2 is a member of an FL group with other EECs not shown, but EEC1 is not a member because it is not located in an area of ​​interest where FL operation may be requested. EAS has requested the creation of an FL group to provide FL server functionality, and EES has created contextual information about the FL group. EEC1, EEC2, EES, and EAS all have FL policy information that may have been provisioned for the desired FL application.

[0100] Step 2: The EES can help manage the operation of the FL group by creating subscriptions for UE location and monitoring with the 5G network. The subscriptions can be for monitoring the QoS of individual EECs during FL operation and for obtaining UE locations for areas of interest.

[0101] Step 3: EEC2 leaves the area of ​​interest, and EEC1 moves into the area of ​​interest.

[0102] Step 4: The 5G network may track the mobility of both EEC1 and EEC2 and can inform the EES that EEC1 is within the area of ​​interest while EEC2 has left the area of ​​interest. The 5G network can send notifications of one or more UE locations detected by the network to the EES. Additional and / or alternative, the EES may receive registration update requests from the EEC or ACR detection / requests as indicators of UE location changes. The EES may also receive UE location information from the location management server or application analytics data from the ADAE server. Note that additional and / or alternative update requests are not shown in the diagram.

[0103] Step 5: EES can detect that EEC2 is part of an FL group created by EAS and can remove EEC2 from the FL group. In addition, EES can become aware that EEC1 has entered its area of ​​interest (for example, by receiving a registration request for EEC1 or by receiving the context for EEC1) and can inspect EEC1's FL policy to evaluate whether EEC1 can be added to the FL group. After inspection, EES can determine that EEC1 can act as an FL client for the FL group and can send a request message to EEC1 to obtain its consent to be added to the FL group. This request may include information from the FL policy such as the FL group identifier, ML application, dataset requirements, FL operation schedule, request user consent to participate in FL operations, and other information from the FL group context.

[0104] Step 6: If EEC1 is able to meet the FL operation schedule and wishes to participate in the FL operation, EEC1 can send a response to the request indicating its agreement to be added to the FL group.

[0105] Step 7: EES can perform an FL group modification to add EEC1 as a new member of the group. EES can update the context information associated with the FL group.

[0106] Step 8: EES can send notifications of modifications to FL groups to EAS, and the notifications may include the FL group identifier, the FL group management action (e.g., add or remove), the UE identifier associated with the added / removed EEC1, and a corresponding policy indicating the FL capabilities and dataset information provided by the EEC1 for the FL operation.

[0107] The application enabler server can also utilize analytics to assist in FL group management. Analytics can be performed by analytics functions within the 5G network or by ADAE servers in the ADAES architecture. Within the 5G network, analytics, including but not limited to UE mobility, network and data network performance, location accuracy, end-to-end data volume transfer time, relative proximity, and (UE) movement behavior, can be subscribed to by ADAE servers or analytics functions within the 5G network to assist in creating and managing FL groups. The resulting analytics output, which may be either statistics or forecasts, can be used to proactively manage the addition and removal of FL group members. Within the ADAE server, analytics, including but not limited to edge network load, service experience, network slice usage patterns, location accuracy, and network slice-specific application performance, can be used in conjunction with the dynamic management of FL groups. Figure 13 illustrates an exemplary procedure for an ADAE server assisting in FL group management using network and / or application-level analytics. Note that other analytics may be used to assist in FL group management in addition to those described above.

[0108] Step 1: The ADAE client and VAL server may register their FL support and capabilities with the ADAE server, and FL groups may be created as previously described. The VAL server may provide FL server functionality and request the creation of FL groups, and the ADAE server creates contextual information about the FL groups. The ADAE client, ADAE server, and VAL server all have FL policy information that may be provisioned for the desired FL application.

[0109] Step 2: The ADAE server can configure application-specific analyses for FL groups, such as edge load analysis, to determine whether an FL operation is suitable for a particular edge data network. The ADAE server can also create subscriptions to receive analysis outputs from the 5G network to help manage the operation of the FL group. These subscriptions could be, for example, to obtain UE mobility, user data congestion, QoS sustainability, network functionality load, and network performance analysis for an area of ​​interest. The analysis outputs can provide insights into network performance that allows the FL operation to complete successfully.

[0110] Step 3: ADAE clients on UEs that were not originally part of an FL group are moving towards the area of ​​interest where the FL group was created. The analytics components of the 5G network may be collecting data and performing analysis on UE mobility moving towards the area of ​​interest.

[0111] Step 4: The generated analysis may predict that an ADAE client is moving towards an area of ​​interest and can send (one or more) notifications, prediction results, and estimated arrival times to the ADAE server. Other analysis outputs may also provide network performance and congestion statistics and / or predictions that the FL server can use to make decisions about FL behavior. Additionally, application-specific analysis may be generated, for example, by the ADAE server itself or by another ADAE server, and can be used to manage members of an FL group.

[0112] Step 5: The ADAE server can add ADAE clients to the FL client pool managed by the ADAE server and send FL group management requests to the ADAE clients. These requests may include the FL group identifier and information from the context of the FL group, such as the ML application, dataset requirements, FL operation schedule, and user consent to participate in the FL operation.

[0113] Step 6: If the ADAE client is able to fulfill the FL operation schedule and wishes to participate in the FL operation, the ADAE client can send a response to the request indicating its consent to be added to the FL group.

[0114] Step 7: The ADAE server can perform FL group modifications to add ADAE clients as new members of the group. The ADAE server can update the context information associated with the FL group. Note that an FL group may have a requirement for a minimum number of FL clients, and if the group members meet that minimum, the ADAE server can proactively use analysis to add more members to the FL group so that the minimum number of members is met. In addition, analysis can indicate a time window in which predictions are valid, and the ADAE server can use this information to proactively manage FL groups.

[0115] Step 8: The ADAE server can send a notification to the VAL server of modifications to an FL group. The notification may include the FL group identifier, the FL group management action (e.g., add or remove), the UE identifier associated with the added / removed ADAE clients, and a corresponding policy indicating the FL capabilities and dataset information provided by the ADAE clients for the FL action.

[0116] Note that the FL group management procedures shown in Figures 12 and 13 can also be applied to other application enablement layers, such as the Service Enabler Architecture Layer (SEAL). When analytics is used for FL group management, the application enabler layer server can subscribe to analytics from ADAE servers and / or analytics functions in the 5G network.

[0117] User Interface The processes for discovering and selecting FL clients, as well as creating and managing FL groups, can be presented in a graphical user interface exposed to FL server users, for example, via a VAL server or EAS. An example of such a GUI is shown in Figure 14.

[0118] Within the GUI, the application enabler server can display the FL client pool that it can manage, allowing the user to select which FL clients should be added to an FL group. Correspondingly, the members of the FL group can also be displayed and grouped together as shown in the diagram. Information about the FL group can be retrieved by pressing the More Info button while holding down each client name, and can show FL client-specific information. Subsequently, as the UE hosting the FL client moves from area to area, the FL client pool can be reduced and / or expanded to match the UE mobility. Furthermore, if the UE moves outside the service area of ​​the FL group, the application enabler server can automatically remove the FL client associated with the UE from the FL group and / or client pool.

[0119] Exemplary communication system The Third Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly known as 3G), LTE (commonly known as 4G), LTE Advanced Standards, and New Radio (NR), also known 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 provisioning for new flexible radio access below 7 GHz and provisioning for new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in the new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide set of 3GPP NR use cases with branching requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrums, providing opportunities for ultra-mobile broadband access, for example, for indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, utilizing cmWave and mmWave-specific design optimizations.

[0120] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide range of user experience requirements regarding data rate, latency, and mobility. Use cases include the following common categories: Enhanced Mobile Broadband (eMBB) Ultra-Reliable Low-Latency Communications (URLLC), Massive Machine-Type Communications (mMTC), Network Operations (e.g., network slicing, routing, migration and interworking, energy saving), and Enhanced Vehicle-to-Everything (eV2X) communications, which may include any of the following: Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Network (V2N), Vehicle-to-Pedestrian (V2P), and Vehicle-to-Other-Entity Communications. Specific services and applications in these categories include, to name a few, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones. All of these and other use cases are contemplated herein.

[0121] Figure 15A shows an exemplary communication system 100, of which the methods and apparatus described and claimed herein may be embodiments. As shown in the figure, the exemplary communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (sometimes referred to generally or collectively as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105B, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and V2X servers (or ProSe functions and servers) 113, but it will be understood that the examples disclosed are intended to include any number of WTRUs, base stations, networks, and / or network elements. Each of WTRU102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Each WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g is shown in Figures 15A to 15E as a handheld wireless communication device, but it is understood that in the wide variety of use cases intended for 5G wireless communication, each WTRU may comprise or be embodied in any type of device or apparatus configured to transmit and / or receive wireless signals, including, but are not limited to, user equipment (UEs), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes.

[0122] The communication system 100 may also include base stations 114a and 114b. Base station 114a can be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b can be any type of device configured to wired and / or wirelessly interface with at least one of RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. RRH118a, 118b can be any type of device configured to wirelessly interface with at least one of WTRU102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. TRP119a, 119b can be any type of device configured to wirelessly interface with at least one of WTRU102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. RSU120a, 120b can be any type of device configured to wirelessly interface with at least one of WTRU102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X server (or ProSe function and server) 113.For example, base stations 114a and 114b could be a base transceiver station (BTS), node B, enode B, home node B, home enode B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b can contain any number of interconnected base stations and / or network elements.

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

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

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

[0126] RRH118a, 118b, TRP119a, 119b, and / or RSU120a, 120b can communicate with one or more WTRU102c, 102d, 102e, 102f via air interface 115C / 116c / 117c, where air interface 115C / 116c / 117c can be any suitable radio communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interface 115c / 116c / 117c can be established using any suitable radio access technology (RAT).

[0127] WTRU102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with each other via air interfaces 115d / 116d / 117d (not shown in the figure), which can be any suitable radio communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interfaces 115d / 116d / 117d can be established using any suitable radio access technology (RAT).

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

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

[0130] In some cases, base stations 114a and WTRU102a, 102b, 102c in RAN103 / 104 / 105, or RRH118a, 118b, TRP119a, 119b and / or RSU120a, 120b and WTRU102c, 102d, 102e, 102f in RAN103b / 104b / 105b, are compatible with IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Advanced Rapid Data Rate (EDGE), and GSM Wireless technologies such as EDGE (GERAN) can be implemented.

[0131] In Figure 15A, base station 114c can be, for example, a wireless router, home node B, home enode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area such as a business premises, home, vehicle, or premises. In some cases, base station 114c and WTRU 102e can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, base station 114c and WTRU 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 15A, base station 114b can have a direct connection to the internet 110. Therefore, base station 114c may not be required to access the internet 110 via the core network 106 / 107 / 109.

[0132] RAN103 / 104 / 105 and / or RAN103b / 104b / 105b may communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or implement high-level security features such as user authentication.

[0133] Although not shown in Figure 15A, it will be understood that RAN103 / 104 / 105 and / or RAN103b / 104b / 105b and / or core networks 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN103 / 104 / 105 and / or RAN103b / 104b / 105b. For example, in addition to connecting to RAN103 / 104 / 105 and / or RAN103b / 104b / 105b, which may utilize E-UTRA radio technology, core networks 106 / 107 / 109 may also communicate with another RAN (not shown) employing GSM radio technology.

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

[0135] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability. For example, WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different radio networks via different radio links. For example, WTRU 102e, shown in Figure 15A, may be configured to communicate with base station 114a, which can employ cellular-based radio technology, and may be configured to communicate with base station 114c, which can employ IEEE 802 radio technology.

[0136] Figure 15B is a block diagram of an exemplary apparatus or device configured for wireless communication according to the embodiments described herein, such as WTRU 102. As shown in Figure 15B, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripherals 138. It will be understood that WTRU 102 may include any partial combination of the above elements while remaining consistent with one embodiment. Furthermore, in some cases, base stations 114a and 114b, and / or, but not limited to, transceiver stations (BTS), nodes B, site controllers, access points (APs), home nodes B, advanced home nodes B (e-nodes B), home advanced nodes B (HeNBs), home advanced node B gateways, and proxy nodes, may include some or all of the elements shown in Figure 15B and described herein.

[0137] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can 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 can be coupled to the transceiver 120, which can be coupled to the transceiver element 122. Although Figure 15B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0139] Furthermore, although the transmit / receive element 122 is shown as a single element in Figure 15B, the WTRU 102 can contain any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in some cases, the WTRU 102 can contain two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interfaces 115 / 116 / 117.

[0140] The transceiver 120 can be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal to be received by the transmitting / receiving element 122. As described above, the WTRU 102 can have multimode capability. Therefore, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate through multiple RATs, such as UTRA and IEEE 802.11.

[0141] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Furthermore, the processor 118 can access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In some cases, the processor 118 can access information from memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in it.

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

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

[0144] The processor 118 can also 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, peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, and electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnection interfaces, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, and internet browsers.

[0145] WTRU102 can be embodied in other devices or equipment, such as sensors, home appliances, wearable devices like smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. WTRU102 can be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0146] Figure 15C is a system diagram of RAN103 and core network 106. As described above, RAN103 can employ UTRA radio technology to communicate with WTRU102a, 102b, and 102c via air interface 115. RAN103 may also communicate with core network 106. As shown in Figure 15C, RAN103 may include nodes B140a, 140b, and 140c, each of which may include one or more transceivers to communicate with WTRU102a, 102b, and 102c via air interface 115. Each of nodes B140a, 140b, and 140c may be associated with a specific cell (not shown) within RAN103. RAN103 may also include RNC142a and 142b. It will be understood that RAN103 may include any number of nodes B and RNC while remaining consistent with one aspect of this disclosure.

[0147] As shown in Figure 15C, nodes B140a and B140b may communicate with RNC142a. Furthermore, node B140c may communicate with RNC142b. Nodes B140a, B140b, and B140c can communicate with their respective RNC142a and B142b via the Iub interface. RNC142a and B142b may communicate with each other via the Iur interface. Each of RNC142a and B142b can be configured to control each of the nodes B140a, B140b, and B140c to which it is connected. In addition, each of RNC142a and B142b can be configured to perform or support other functionalities such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[0148] The core network 106 shown in Figure 15C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements is shown as part of the core network 106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0149] The RNC142a in RAN103 can be connected to the MSC146 in the core network 106 via the IuCS interface. The MSC146 can be connected to the MGW144. The MSC146 and MGW144 provide access to circuit-switched networks such as PSTN108 to WTRU102a, 102b, and 102c, facilitating communication between WTRU102a, 102b, and 102c and legacy landline communication devices.

[0150] RNC142a in RAN103 can be connected to SGSN148 in core network 106 via the IuPS interface. SGSN148 can be connected to GGSN150. SGSN148 and GGSN150 provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

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

[0152] Figure 15D is a system diagram of RAN104 and core network 107. As described above, RAN104 employs E-UTRA wireless technology and can communicate with WTRU102a, 102b, and 102c via air interface 116. RAN104 may also communicate with core network 107.

[0153] RAN104 may include enodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of enodes B while remaining consistent with one aspect of this disclosure. Each enode B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In some cases, enodes B160a, 160b, and 160c may implement MIMO technology. Thus, enode B160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a.

[0154] Each of the e-nodes B160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink and / or downlink, etc. As shown in Figure 15D, the e-nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0155] The core network 107 shown in Figure 15D may include a Mobility Management Entity (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the above elements is shown as part of the core network 107, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0156] The MME162 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can also provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0157] The serving gateway 164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The serving gateway 164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The serving gateway 164 can also perform other functions, such as anchoring the user plane during handover between e-nodes B, triggering paging when downlink data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0158] The serving gateway 164 can also be connected to the PDN gateway 166, which provides WTRU 102a, 102b, and 102c with access to a packet-switched network such as the Internet 110, facilitating communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

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

[0160] Figure 15E is a system diagram of RAN105 and core network 109. RAN105 can be an access service network (ASN) that employs IEEE 802.16 wireless technology to communicate with WTRU102a, 102b, and 102c via air interface 117. As will be discussed further below, communication links between different functional entities of WTRU102a, 102b, 102c, RAN105, and core network 109 can be defined as reference points.

[0161] As shown in Figure 15E, RAN105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it will be understood that RAN105 may include any number of base stations and ASN gateways while remaining consistent with one aspect of the present disclosure. Each base station 180a, 180b, 180c may be associated with a specific cell in RAN105 and may include one or more transceivers for communicating with WTRU102a, 102b, 102c via the air interface 117. In some cases, base stations 180a, 180b, 180c may implement MIMO technology. Thus, base station 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a. Base stations 180a, 180b, and 180c can also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, and quality of service (QoS) policy enforcement. The ASN gateway 182 can act as a traffic aggregation point and is responsible for paging, subscriber profile caching, and routing to the core network 109.

[0162] The air interface 117 between WTRU102a, 102b, 102c and RAN105 can be defined as an R1 reference point implementing the IEEE802.16 specification. In addition, each of WTRU102a, 102b, and 102c can establish a logical interface (not shown) with the core network 109. The logical interface between WTRU102a, 102b, 102c and the core network 109 can be defined as an R2 reference point that can be used for authentication, authorization, IP host configuration management, and / or mobility management.

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

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

[0165] The MIP-HA can be responsible for IP address management and can enable WTRU102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA184 can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. The AAA server 186 can be responsible for user authentication and supporting user services. The gateway 188 can facilitate interworking with other networks. For example, the gateway 188 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as the PSTN 108, facilitating communication between WTRU102a, 102b, and 102c and legacy landline communication devices. Furthermore, gateway 188 can provide WTRU 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0166] Although not shown in Figure 15E, it will be understood that RAN105 can be connected to other ASNs, and core network 109 can be connected to other core networks. The communication link between RAN105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRU102a, 102b, and 102c between RAN105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference, which may include protocols for facilitating interworking between the home core network and the visited core network.

[0167] The core network entities described herein and shown in Figures 15A, 15C, 15D, and 15E are identified by the names given to them in some existing 3GPP specifications, but it should be understood that in the future, these entities and functionalities may be identified by other names, and some entities or functionalities may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Therefore, it should be understood that the specific network entities and functionalities described and shown in Figures 15A, 15B, 15C, 15D, and 15E are given merely as examples, and the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or hereafter defined.

[0168] Figure 15F is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks shown in Figures 15A, 15C, 15D, and 15E can be embodied, such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, or several nodes or functional entities in other networks 112. The computing system 90 may comprise a computer or server and may be controlled by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to operate the computing system 90. The processor 91 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 can 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 communication network. The coprocessor 81 is a separate, optional processor from the main processor 91 that can perform additional functions or assist the processor 91. The processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and apparatus disclosed herein.

[0169] During operation, the processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the main data transfer path of the computing system, the system bus 80. Such a system bus connects the components within the computing system 90 and defines the medium for data exchange. The system bus 80 generally includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnection) bus.

[0170] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that enables information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or modified by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide address translation functionality that translates virtual addresses to physical addresses when instructions are executed. The memory controller 92 can also provide memory protection functionality that isolates processes within the system and isolates system processes from user processes. Thus, a program operating in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in another process's virtual address space unless inter-process memory sharing is set up.

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

[0172] A display 86 controlled by a display controller 96 is used to display visual output generated by a 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). The display 86 may be implemented as a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components necessary to generate the video signal sent to the display 86.

[0173] Furthermore, the computing system 90 may include communication circuits, such as a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, the Internet 110, or other network 112 in Figures 15A, 15B, 15C, 15D, and 15E, and to enable the computing system 90 to communicate with other nodes or functional entities on those networks. The communication circuits can be used alone or in combination with the processor 91 to perform the transmit and receive steps of some of the devices, nodes, or functional entities described herein.

[0174] Figure 15G shows an exemplary communication system 111, in which the methods and apparatus described and claimed herein may be embodiments thereof. As shown in the figure, the exemplary communication system 111 may include radio transceiver units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but it will be understood that this disclosure intends any number of WTRUs, base stations, networks, and / or network elements. One or more or all of WTRUs A, B, C, D, E may be outside the network range (for example, outside the cell coverage boundary shown as a dashed line in the figure). WTRUs A, B, C form a V2X group, in which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0175] Any or all of the devices, 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, and it should be understood that when such instructions are executed by a processor, such as processor 118 or 91, the processor will carry out and / or implement the systems, methods, and processes described herein. In detail, any of the steps, actions, or functions described herein may be implemented in the form of such computer-executable instructions that are executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage mediums include volatile and non-volatile, removable and non-removable media, implemented by any non-temporary (e.g., tangible or physical) method or technique for storing information, but such computer-readable storage mediums do not contain signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or any other tangible or physical media that can be used to store desired information and can be accessed by a computing system.

[0176] The definitions of abbreviations found within this disclosure are provided below.

[0177] [Table 4]

[0178] The following are definitions of terms found within the text of this disclosure.

[0179] [Table 5]

Claims

1. A method implemented by the application enabler server, The steps include receiving a request to form a collaborative learning (FL) group, The steps include assigning at least one UE to the FL group, A step of sending a request to the core network to obtain one or more UEs for the FL group, wherein the request includes filter criteria, including QoS requirements, access type, FL operation transfer time, UE location and mobility information, or a combination thereof. The steps include receiving a response from the core network that has a list of one or more UEs, A step of sending a response to the request for forming the FL group, which indicates the status corresponding to the FL group. A method for providing this.

2. The method of claim 1, wherein the response to the request for forming the FL group comprises the status of the request for forming the FL group, an FL group identifier, one or more UE identifiers selected for the FL group, a schedule for FL operation, or a combination thereof.

3. The method of claim 1, wherein the requirement for forming the FL group includes an FL server identifier, an FL group identifier, an FL policy, an FL client list, FL client capability requirements, the number of clients that will be part of the FL group, quality of service requirements, geographical location, or a combination thereof.

4. The steps include sending a notification to the at least one UE indicating its selection as part of the FL group, The steps include receiving a response from at least one UE indicating that the UE is able to participate in the FL operation, and The method according to claim 1, which performs the following.

5. The method of claim 1, wherein the step of assigning a UE to the FL group may be derived from discovering a UE from the list of UEs received from the core network.

6. Steps to discover multiple UEs from the FL client pool The method of claim 1, further comprising the step of assigning the at least one UE to the FL group, wherein the step of finding the method of claim 1 is based on the step of finding the method.

7. Step of assigning an FL group identifier to the FL group. The method of claim 1, further comprising the following:

8. A method implemented by the application enabler server, The steps include sending a location-based group creation request to the group management server, The steps include receiving a response to the location-based group creation request, which includes at least a list of UEs that satisfy location criteria, federated learning (FL) criteria, or both; The steps include sending an FL group creation request based on the aforementioned list of UEs, The steps include receiving a response to the FL group creation request, which includes information corresponding to the FL group; A method for providing this.

9. The method of claim 8, wherein the response to the location-based group creation request further includes the status of the request, a group identifier, or both.

10. The method of claim 8, wherein the information corresponding to the FL group includes the status of the FL group creation request, an FL group identifier, one or more FL client identifiers, a schedule of FL operations, or a combination thereof.

11. The method of claim 8, wherein the location-based group creation request includes an FL server identifier, an FL group identifier, an FL policy, an FL client list, FL client capability requirements, the number of clients that will be part of the FL group, quality of service requirements for the FL group, geographical locations for the FL group, or a combination thereof.

12. The method of claim 8, wherein the application enabler server is pre-provisioned with one or more FL policies.

13. The method of claim 12, wherein the one or more FL policies include a server identifier, an FL configuration identifier, an FL role, an application identifier, a machine learning (ML) model or algorithm, an ML application type, one or more FL capabilities, FL security information, FL user information, FL history information, or a combination thereof.

14. The method of claim 8, wherein the FL group creation request is sent to an Application Data Analysis Activation (ADAE) server.

15. One or more processors, Memory and The set of instructions stored in the memory and A device comprising the following, wherein the set of instructions is executed by one or more processors: We received a request to form a collaborative learning (FL) group. Assign at least one UE to the FL group, Send a notification to the at least one UE indicating its selection as part of the FL group, The FL group sends a request to the core network for a quality of service metric for one or more UEs. Receiving the service quality metrics for one or more UEs, Send a response to the request to form the FL group, indicating the status corresponding to the FL group. Device.

16. The apparatus of claim 15, wherein the response to the request for forming the FL group comprises the status of the request for forming the FL group, an FL group identifier, one or more FL UE identifiers selected for the FL group, a schedule for FL operation, or a combination thereof.

17. The apparatus of claim 15, wherein the requirement for forming the FL group includes an FL server identifier, an FL group identifier, an FL policy, an FL client list, FL client capability requirements, the number of clients that will be part of the FL group, quality of service requirements for the FL group, geographical locations for the FL group, or a combination thereof.

18. The apparatus of claim 15, wherein the request for forming the FL group is received from the VAL server.

19. When the set of instructions is executed by one or more processors, Furthermore, the VAL server is authenticated. The apparatus according to claim 18.

20. When the set of instructions is executed by one or more processors, Discovering multiple UEs from the FL client pool The apparatus of claim 15, which further involves performing the above and assigning the at least one UE to the FL group, based on the discovery.

Images