Mechanism for service layer support for federated learning groups

Abstract

Methods and systems for service layer support for federated learning groups are described herein. In one aspect, a method performed by an application enabler server may include receiving a first request to form a federated learning (FL) group; sending one or more requests corresponding to assistance for the FL operation to the core network; receiving a response to the one or more requests from the core network; and transmitting a response to the first request, the response comprising one of: an FL group identifier, a list of FL clients associated with the FL group, a validity time or schedule of the FL group, or a combination thereof.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 518,652, filed August 10, 2023, entitled “Mechanisms for Service Layer Support of Federated Learning Groups,” the contents of which are incorporated herein by reference in their entirety for any and all purposes. Background Technology

[0002] Application layer architecture.

[0003] Applications are becoming increasingly complex, and various mechanisms have been designed to facilitate faster application development. One such mechanism is to introduce different functional layers within (or adjacent to) the application layer to separate functionalities that can be accessed via application programming interfaces (APIs). Figure 1 This illustrates an example of a generalized application layer architecture that separates application development into three distinct layers: an application-specific layer, a vertical application enabler layer, and a service layer. At the bottom of the application stack is the service layer, which provides common services to all applications. Services may include location management, group management, configuration management, and security aspects of application development. Above the service layer is the vertical application enabler layer, which manages services for specific vertical applications (such as autonomous vehicles, drones, IoT, games, etc.). At the top of the application stack is the application-specific layer, which serves specific applications within a vertical application. This layer contains custom logic or business logic for the specific application and may be provided by various service providers within the vertical application domain. The goal of this three-layer approach is to abstract common services for all applications into the vertical application enabler and service layers to simplify application development and enable faster application deployment.

[0004] Figure 1 The architecture shown 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 server applications can reside on 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 layer below. For example, an application-specific client can communicate with a client application at a vertical application enabler or service layer. The network between the client and server applications provides the communication medium. This network can be a cellular network such as a mobile operator's network, or it can be a broadband service provider network that provides internet access for the client and server applications.

[0005] It is worth noting that, Figure 1 The architecture shown can also be applied to publish-subscribe and subscription-notification communication patterns. It's also worth noting that in decentralized deployments where devices communicate directly with each other, server functionality may reside on the device itself, rather than on an application server. In this case, devices can communicate with each other, allowing one device to act as a client and another as a server.

[0006] Application Data Analytics Enabled Services (ADAES) architecture.

[0007] 3GPP defines Application Data Analytics Enablement Services (ADAES) that are available to applications to access application-related analytics. Figure 2 The diagram illustrates the ADAE architecture. As shown, the ADAE client communicates with the ADAE server via the ADAE-UU interface over a 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 diagram also shows that the ADAE client and server are part of a Service Enabler Architecture Layer (SEAL), which can interact with... Figure 1 The service layers shown are similar.

[0008] The ADAE layer supports the generation of application-layer analytics for VAL servers and VAL clients. The generated analytics can include statistics or predictions associated with analytics IDs. Currently supported analytics IDs include: application performance, slice-specific and UE-to-UE application performance, location accuracy, service APIs, slice usage patterns, and edge load analysis. Data collection is also managed by the ADAE layer to enable the derivation of corresponding analytics. Finally, the ADAE server can access core network services, such as N33, N6, and ADAE-OAM interfaces. Figure 2 As shown in the figure.

[0009] Edge enabler layer (EEL).

[0010] Edge computing architectures allow communication and computing services to reside closer to end devices, reducing end-to-end latency and offloading the network. Therefore, edge enabler layers can be merged as... Figure 1 It is part of the service layer described in [the document / document]. Figure 3 An example of a layered application deployment architecture is shown, which combines functionality from the edge enabler layer, the SEAL layer, the application enabler layer, and the application-specific layer. About Figure 1 The edge enabler layer and the SEAL layer can be collectively recognized as a service layer that provides horizontal services to all applications.

[0011] Within the Edge Enabler Layer (EEL), Edge Enabler Servers (EES) and Edge Enabler Clients (EECs) provide services to User Equipment (UEs) within the Edge Data Network (EDN). Some of these edge services include: service provisioning, registration, discovery, capability exposure, security, and service continuity. Application Clients (ACs) on the UEs access edge services through the EECs, while Edge Application Servers (EASs) access edge services through the EES. Edge Configuration Servers (ECSs) provide provisioning services, enabling EECs to connect to the EES.

[0012] Service Enabler Architecture Layer (SEAL).

[0013] As previously described, the service layer can provide common services to all applications, regardless of the vertical application. In 3GPP, the Service Enabler Architecture Layer (SEAL) for vertical applications provides such horizontal functionality to all applications. Some of the common services provided by SEAL are location management, group management, configuration management, identity management, key management, and network resource management. These services are available to all applications because they are industry-agnostic. Each of the provided services can be associated with a corresponding management server (e.g., a group management server providing group services and a location management server providing location services).

[0014] like Figure 3 As shown, the SEAL client residing on the UE can communicate with the SEAL server on the edge data network. However, the SEAL server can also operate as an application server in a data network in the cloud, independent of the edge data network. There are many other deployment scenarios within SEAL, and... Figure 4 An example of a location-based group creation procedure supported in SEAL is shown, where both a group management server and a location management server are utilized. This procedure provides either the group management client or the VAL server with the ability 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 at the indicated location from the location management server. The group management server creates the group based on the UE list returned from the location management server and returns a response to either the group management client or the VAL server.

[0015] Federal learning.

[0016] Federated learning (FL) is a machine learning (ML) approach that enables the creation of models trained on data distributed across multiple clients or locations, without requiring data aggregation and storage in a central location. During training and / or inference, an FL server manages multiple FL clients, and data remains private and is stored locally on each individual FL client. During training, one or more ML models and their associated parameters are exchanged between the FL server and the FL clients. The FL server aggregates the model parameters (e.g., weights) at each round of federated training, and FL training iterates through many rounds. In recent years, this approach has become increasingly popular as more organizations seek the ability to leverage large datasets without compromising the privacy of individual users and / or data sources. FL also offers the added benefits of reduced data movement and improved scalability.

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

[0018] Support for member selection and network performance exposure has begun in the 3GPP core network to facilitate FL operations. However, support for creating and managing FL groups during FL operations is not yet available at the application enablement layer. Furthermore, application enablers for FL operations (such as FL client registration, discovery, and selection) are currently absent from the existing 3GPP-defined application enabler layer. Therefore, application users wishing to deploy FL operations on 5G systems cannot implement this functionality. Summary of the Invention

[0019] Some support for federated learning operations has already been defined within the 3GPP 5G cellular core network, adding new analytics and network exposures to facilitate the creation and management of federated learning groups. However, supplementary federated learning support is lacking at the 3GPP-defined application enabler layer to leverage these new core network capabilities. Such support is crucial for implementing federated learning processes and procedures for use by applications from different application service providers / vertical industries. This disclosure proposes both: enhancements to existing procedures and the introduction of new procedures for complete federated learning integration within 5G cellular systems.

[0020] According to this disclosure, methods and systems for supporting federated learning integration at the application enabler layer within a 5G cellular system are described herein. In one aspect, a method for an application enabler server to create an FL group may include: receiving a first request for forming a federated learning group; wherein the request includes one or more of the following: an FL server identifier, an FL policy, a list of FL clients (e.g., a UE identifier), FL client capabilities, a minimum number of FL clients, FL QoS requirements, locations of interest, enabled network analytics indicators, training rounds, FL training scheduling, time window recommendations, and policy expiration. In some cases, the FL policy includes one or more of the following: a client / server identifier, an FL policy identifier, an application identifier, an ML model / algorithm, an ML application type, FL capabilities, FL client requirements, dataset requirements, available datasets, dataset capabilities, a dataset identifier, an ML application type, a dataset description, a dataset size, a dataset age, target features, a feature list, feature identifiers, feature names, data formats, dataset metadata, and related features.

[0021] The method may also include sending one or more requests to the cellular 5G core network to assist federated learning operations. In some cases, the method may include sending a second request from the 5G network for UE member selection assistance, which may include one or more UE member filtering criteria, such as QoS requirements, access type, FL operation transmission 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 acting as FL clients.

[0022] The method may also include receiving a response to one or more requests from the cellular 5G core network. In some cases, the response may include a response to a second request, which has a list of candidate UEs matching the UE member filtering criteria. In some cases, the response may include a response to a third request, which has one or more of the following: the desired UE movement trajectory, a fixed indication, communication duration, periodicity, scheduled communication time, battery indication, traffic profile, scheduled communication type, and the desired time and day of the week in the trajectory.

[0023] In some cases, the method may include sending a response to the first request, which 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 scheduling of the FL group.

[0024] On the other hand, a method for an application enabler server to perform FL group management may include: receiving a first request for forming a federated learning group; the request includes one or more of the following: FL server identifier, FL policy, FL client list (e.g., UE identifier), FL client capabilities, minimum number of FL clients, FL QoS requirements, location of interest, enabled network analysis indicator, number of training rounds, FL training schedule, time window suggestion, and policy expiration. 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 capabilities, FL client requirements, dataset requirements, available dataset, 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.

[0025] In some cases, the method may include sending a response to the first request, which 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 scheduling of the FL group.

[0026] In some cases, the method may include sending one or more subscription requests to notify FL clients of changes in location and / or QoS flows.

[0027] In some cases, the method may include sending one or more subscription requests to receive analytics about the FL client from analytics capabilities in the network, including from application analytics servers.

[0028] In some cases, the method may include receiving change notifications for location, QoS flow, and / or analytics output for one or more FL clients.

[0029] In some cases, the method may include updating the members of the FL group based on the received notifications used for subscription.

[0030] On the other hand, a method for an application enabler server to support FL registration may include: receiving a request for registering FL capabilities, the request including one or more of the following: FL indication support, client / server identifier, FL policy identifier, application identifier, ML model / algorithm, ML application type, FL capability, 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.

[0031] In some cases, this method may include processing requests to authenticate and authorize requesters; assigning identifiers to FL policies; creating contexts for FL policy identifiers; and associating and storing FL information within the context of RESTful resources.

[0032] In some cases, the method may include sending a response to the request, which includes the status of the registration request and an FL policy identifier.

[0033] This invention provides a summary of a series of concepts in a simplified form, which are further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that address any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

[0034] Figure 1 It describes the application layer architecture model.

[0035] Figure 2 An architecture model for Application Data Analytics Enabled Services (ADAES) is described.

[0036] Figure 3 A layered application architecture with edge computing is described.

[0037] Figure 4 It describes support for location-based group creation in the Service Enabler Architecture Layer (SEAL).

[0038] Figure 5 An example of a Federated Learning (FL) client and FL server deployment is depicted.

[0039] Figure 6 The architecture of the enabler layer for federated learning applications is described.

[0040] Figure 7 The enhancements to EDGEAPP registration are described.

[0041] Figure 8 The ADAE registration procedure is described.

[0042] Figure 9 The FL client discovery and selection process is described.

[0043] Figure 10 The procedure for creating a single request FL group is described.

[0044] Figure 11 The creation of FL groups based on SEAL is described.

[0045] Figure 12The dynamic FL group management procedure is described.

[0046] Figure 13 An analysis-driven FL group management procedure is described.

[0047] Figure 14 A graphical user interface (GUI) for managing FL groups is described.

[0048] Figure 15A An example communication system is described, wherein the methods and apparatus described and claimed herein may be aspects of the example communication system; Figure 15B A block diagram depicts an example device or apparatus configured for wireless communication; Figure 15C A system diagram of an example radio access network (RAN) and core network is depicted; Figure 15D A system diagram of another example RAN and core network is depicted; Figure 15E A system diagram of another example RAN and core network is depicted; Figure 15F A block diagram of the example computing system is depicted; and Figure 15G A block diagram of another example communication system is depicted. Detailed Implementation

[0049] Before implementing federated learning support at the application enabler layer, it is important that both the FL server and FL client register their capabilities with an enabler server, such as an Edge Enabler Server (EES). An EES is likely the ideal server for incorporating federated learning support as a server interface into both the Edge Application Server (EAS) and the Edge Enabler Client (EEC). Figure 3 For reference, EAS and EEC (e.g., running on UE) can act as FL servers and FL clients, respectively. Therefore, EES can manage federated learning operations by incorporating FL registration, FL client discovery, and FL client selection as additional edge services supporting federated learning. Alternatively, EES can natively incorporate FL server capabilities and provide FL services to EEC. Figure 5 It shows Figure 3 The example shown is an embodiment of an FL client and an FL server in an edge computing deployment scenario.

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

[0051] This also allows defining application enable layers to support federated learning. Examples of such a structure are... Figure 6 As shown in the diagram, the FL client can reside within the UE and has an FL-C interface with the VAL client on the UE. Similarly, the FL server can reside in a cloud or edge network with an FL-S interface to the VAL server, and can also have an FL-NW interface with the 3GPP network. The FL client communicates with the FL server via the FL-UU interface through the 3GPP network.

[0052] The following sections describe solutions developed to support federated learning integration within the application enabler layer by enhancing existing procedures or introducing new ones. Note that while the solutions described below may focus on the edge enabler and application data analytics enabler layers, other application enabler layers (such as SEAL and / or SEAL Data Delivery (SEALDD)) can also be enhanced to support federated learning.

[0053] Enhanced enrollment features for federated learning.

[0054] Edge enabler layers are ideal layers for incorporating federated learning. For example, by... Figure 3 As shown, the EEC, EES, and ECS all coordinate to provide edge computing services to the UE and EAS. The application client (AC) on the UE and / or the EEC can provide FL client functionality, while 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 clients, 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 An example call flow for such an enhancement is shown. Enhancements can 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.

[0055] Table 1—FL Information for the Registration Process .

[0056] The FL client can provide information about federated learning operations as part of a registration process within the edge enabler layer (e.g., via AC registration or EEC registration). The FL client can share information with the EES about the datasets available for FL operations, such as the number of datasets available for training and / or inference, the type of ML application to which the dataset is applied, a description of the dataset, its 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.). Additionally, the FL client can provide dataset processing capabilities to allow feature engineering for datasets where additional features can be created to meet dataset requirements.

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

[0058] The information shown in Table 1 can be grouped together as federated learning strategies and assigned policy identifiers. For example... Figure 7 As shown in the example, the identifier can be included as part of the AC profile and shared within the edge enabler layer. During the configuration and operation of federated learning, the FL policy identifier can be referenced between FL clients (e.g., AC or EEC) and FL servers (e.g., EAS).

[0059] Step 1: The FL policy can be supplied to the AC, EEC, and / or EAS as part of FL integration. The FL policy may include information about the FL client / server, as shown in Table 1. Additionally and / or alternatively, indicators may be supplied to inform the AC, EEC, and EAS of federated learning capabilities. The supply of FL information can be done at the AC / EEC as shown in Step 1a or at the EAS as shown in Step 1b.

[0060] Step 2: If an FL policy is supplied to the AC, the AC can share information with the EEC on the UE that has federated learning support (e.g., by performing an AC registration request). The FL policy can be sent as part of the AC profile, or it can include indicators to specify federated learning capabilities. Additionally and / or alternatively, the AC can request a list of requested EEC services or FL services from a list of EAS feature information elements that may be included in the request message.

[0061] Step 3: The EEC can perform AC request confirmation, for example, checking security credentials to authenticate and authorize the AC. The EEC can assign identifiers to FL policies to associate with the FL information provided in the request, create contexts for the FL policy identifiers, and associate and store the FL information with the context in a RESTful resource maintained by the EEC.

[0062] Step 4: The EEC can return a response to the AC with the requested status and the assigned FL policy identifier. Additionally and / or alternatively, the EEC can return an indicator that allows the Federated Learning service in the list of permitted EEC service information elements.

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

[0064] Step 6: EES can perform request confirmation from the EEC, for example, checking security credentials to authenticate and authorize the EEC. EES can also process the request and determine whether the service requested by the EEC can be provided (e.g., as specified in the AC profile and / or Federated Learning-related information elements). If the EEC specifies FL service requirements, EES can add the Application Client (AC) / EEC identifier along with associated FL information (e.g., 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. EES can also assign FL policy identifiers to EECs, to which information about FL service operations can be associated. Note that the FL policy identifiers maintained by the EEC and EES can be the same or different from each other.

[0065] Step 7: If the EEC context ID and the source EES endpoint IE are included in the registration request, EES can also process the request.

[0066] Step 8: The EES can return a response to the EEC, which may include the status of the registration request and whether the FL service has been implemented for the EEC via an indicator. Additionally and / or alternatively, the FL service indicator may be included as part of the AC profile. The FL service indicator may specify whether the requester can operate as an FL client or server, and whether the requester can participate in FL operations. If the FL service is implemented, an FL configuration identifier may also be returned in the response, or the presence of the FL configuration identifier may signal that FL operation is permitted. The AC / EEC may use the FL configuration identifier to update the information found in Table 1.

[0067] Step 9: An EAS interested in acting as an FL server (e.g., by providing FL services) can specify such capability in its EAS registration request to the EES. As shown in Step 1b, the EAS may already be provisioned and / or configured with FL information. The EAS profile can be enhanced to include an FL policy containing federated learning-related information as shown in Table 1. Additionally and / or alternatively, FL capability indicators can be added to the EAS policy. FL capability indicators can specify whether the requester operates as an FL server or an FL client, and whether the requester agrees to participate in FL operations, such as discovering and selecting clients for FL operations. The FL policy may already be provisioned to each entity, and the FL capability indicators can be used to trigger FL services and operations.

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

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

[0070] For some deployments, the EES can also be supplied with FL policies to streamline communication overhead by leveraging FL operations, or the EES can receive FL policies from the Edge Configuration Server (ECS) during EES registration. In such deployments, the AC, EEC, and EAS registration procedures can be simplified so that only FL indicators can be provided to instruct users to agree to participate in FL operations.

[0071] Figure 7The procedure described herein is an enhancement to the existing edge registry procedures of AC, EEC, and EAS to convey support for federated learning. For the integration of FL with other application enabler layers, new procedures can be proposed to implement support for federated learning in those enabler layers. As an example, a new registry procedure can be added to the ADAE architecture of ADAE clients and VAL server / clients to convey their FL capabilities to the ADAE server. Figure 8 An example ADAE registration procedure is presented, where 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 occur in any order; for example, the VAL server can register before the ADAE client.

[0072] Step 1: The FL policy can be supplied to the ADAE client and / or VAL server / client as part of 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 supplied to notify the ADAE client or VAL server / client of federated learning capabilities. The supply of FL information can be done at the ADAE client as shown in Step 1a or at the VAL server as shown in Step 1b. Note that, although not shown in the figure, the FL policy can also be supplied to the VAL client, which can then communicate support for federated learning to the ADAE client.

[0073] Step 2: The ADAE client can send a new registration request to the ADAE server. The registration request may include the client identifier, security credentials, and information about the FL policy. Additionally and / or alternatively, the request may include an indicator of the ADAE client's support for federated learning. This indicator can signal the user's consent for discovering and selecting ADAE clients to participate in federated learning operations. Table 2 shows an example of FL registration request parameters.

[0074] Table 2—FL's ADAE Registration Request Parameters .

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

[0076] Step 4: The ADAE server can return a response to the ADAE client with the requested status and the assigned FL policy identifier. Additionally and / or alternatively, the ADAE server can return an indicator of the federated learning services permitted by the ADAE client.

[0077] Step 5: VAL servers interested in providing FL services can specify this capability in their registration request to the ADAE server. This request may include the VAL server identifier, security credentials, and information from the FL policy. In Step 1b, the VAL server may have already been provisioned and / or configured with FL information. Additionally and / or alternatively, an FL capability indicator may be included in the request.

[0078] Step 6: The ADAE server can process requests, including checking security credentials to authenticate and authorize the VAL server. The ADAE server can assign identifiers to FL policies to associate with VAL servers, create contexts for FL policy identifiers, and associate and store FL information with contexts in RESTful resources maintained by the ADAE server.

[0079] Step 7: The ADAE server can return a response to the VAL server with the requested status and the assigned FL policy identifier. Additionally and / or alternatively, the ADAE server can return an indicator of the federated learning services permitted by the VAL server.

[0080] Note that, although Figure 7 The registration procedure for the ADAES architecture is described, but this registration procedure can be easily applied to other application enabler layers, such as the Service Enabler Architecture (SEAL) layer. The basis of the registration procedure, such as providing FL policies or information from FL policies, can be shared with the SEAL server to indicate the requester's FL capabilities.

[0081] Figure 7 and Figure 8 The registration process shares common elements, so the FL policy is communicated to the EES / ADAE server to indicate support for federated learning. The information in the FL policy not only indicates FL capabilities but also assists in FL client discovery and selection, FL group creation, and FL group management. These procedures will be described in more detail below.

[0082] Client discovery and selection.

[0083] After the application enabler server (e.g., an EES or ADAE server) is notified 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 An example procedure is shown, in which the EAS can request FL client discovery from the EES and use the discovery results to select FL clients to be included in a group of FLs that can be used for federated training and / or inference. Again, enhancements to existing procedures in the edge enabler layer are proposed.

[0084] 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. The EAS can include information from the FL policy to be matched (e.g., as shown in Table 1) and other filtering parameters, such as geographic service area, UE location and identifier (if known), operation scheduling, etc., in the request within the filtering information element. To minimize the size of the AC profile sent in the response to the request, the EAS can include discovery-level information elements that further filter 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 with finer granularity are conceivable for filtering the information included in the response.

[0085] Step 2: EES can check the security credentials of EAS to verify that EAS is authorized to perform the operation. Authorization checks may include verifying that EAS is authorized to perform FL operations within the Edge Data Network (EDN). If authorized, EES can match the FL information provided by EAS with information about FL clients in the client pool that EES can attempt to fulfill FL client discovery requests.

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

[0087] Step 4: If the EAS does not have any UE identifiers for FL clients received from the EES response 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 additional API requests to the EES and the 5G network. Note that, for example, if the EAS is provided with information about FL clients and / or AC profiles, the EAS may also make a UE identifier request independently of the information returned in Step 3. Additionally 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.

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

[0089] Step 6: The EES can return the status of the UE identifier request to the EAS, including a list of UE IDs. The EAS can then use the UE identifiers in future edge API calls for federated learning operations.

[0090] Step 7: The EAS may also be interested in locating UEs within a certain service area to fulfill FL training requirements and will make a UE location request to the EES. This request may include the UE identifier and location granularity of the service area of ​​interest to the EAS. The EAS may make multiple UE location requests for all UEs that may be interested in FL operations. Similar to Step 4, the EAS may also include discovery criteria in its requests to the EES as described in Step 1.

[0091] Step 8: The EES can check the 5G network to locate the UE's position, or respond to a UE position request using a valid UE position cached locally. The EES can then filter the results to obtain a list containing only UEs that can operate as FL clients.

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

[0093] Step 10: The EAS providing FL services can send an FL group creation request to the EES to request the formation of FL groups for federated learning operations. This request may include information as shown in Table 3.

[0094] Table 3—FL Group Creation Request Parameters .

[0095] Step 11: For authentication and authorization purposes, the EES can check the security credentials of the EAS. During authorization, the EES can assign an identifier to the FL group, create a context to associate information received in the request with the FL group, and store the information externally in a RESTful resource within the EES or in a data storage entity. The EES can perform FL membership selection by examining FL policy information in the AC profile. The EES can also communicate with the 5G network to perform membership selection based on requirements provided by the EAS. The EES can invoke the Nnef_AFsessionWithQoS API with QoS requirements for FL operations and provide a list of UEs to act as FL clients. The 5G network can respond with the results of the request, which may include the expected UE movement trajectory, fixed indication, communication duration, periodicity time, scheduled communication time, battery indication, traffic profile, scheduled communication type, and the expected time and day of the week in the trajectory. The EES can store the information received from the 5G network's response in a RESTful resource. Additionally and / or alternatively, 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 transmission time, UE location, and mobility information). In response, the 5G network can send a notification message to the EES containing a list of candidate UEs that match the UE member filtering criteria. Note that the EES may communicate with the 5G network in a different order than described, for example, requesting UE member selection assistance before invoking the Nnef_AFsessionWithQoS API.

[0096] Step 12: The EES can send a notification to all selected EECs (e.g., UEs) informing them that their selection is part of an FL group. This notification may include a subscription identifier, a previously supplied FL policy identifier, an assigned FL group identifier, the group management operation to be performed (e.g., add, remove, etc.), and when the scheduling of federated operations can be implemented. Note that the FL policy identifier can indicate what type of FL operation (e.g., training, inference, etc.) the FL group requests.

[0097] Step 13: The EEC can return a response to the EES, in which the EEC can specify whether the client is able to execute and whether the federated operation can be executed in the desired schedule.

[0098] Step 14: EES can return an FL group creation response containing the requested status, FL group identifier, and a list of FL clients associated with the FL group. This response may also include the validity period and / or scheduling 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 maintain the privacy of the FL clients, the list of FL client identifiers can be anonymous.

[0099] The existing procedures require the use of application enabler servers (e.g., EES, ADAE servers) to facilitate more interaction between FL clients (e.g., EEC, ADAE clients) and FL servers (e.g., EAS, VAL servers) for federated learning integration. For certain deployments where provisioning can be leveraged to accelerate 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 combines FL client discovery, selection, and FL group creation into a single request. An example of such a procedure is provided in [link to example]. Figure 10 As shown in the example. Note that in this example, the FL policies or information required for federated learning integration can be pre-provisioned to the individual entities, such as the ADAE client, ADAE server, and VAL server. This procedure can be applied to ADAES and / or SEAL architectures to simplify federated learning integration in the application enabler layer, since those architectures do not have a defined registration procedure.

[0100] Step 1: The FL policy can be pre-provisioned to the ADAE client, ADAE server, and VAL server as part of the federated learning integration. The provisioned information can be the information of the corresponding entities shown in Table 1. Note that, although not shown in the figure, the FL policy can also be provisioned to the VAL client, which can then convey its support for federated learning to the ADAE client.

[0101] Step 2: FL users via the VAL server can decide to create FL groups to train ML applications in a federated manner. The VAL server can send an FL group creation request to the ADAE server, which can be responsible for managing the FL groups during training and / or inference. This request can include information such as that shown in Table 3 to assist the ADAE server in discovering and selecting appropriate FL clients to participate in the federated operation. The request can contain explicit indicators for FL client discovery and selection, for which the selected FL clients can then be grouped together into FL groups for further FL operations. Alternatively, the request can implicitly infer FL client discovery and selection, as well as FL group creation.

[0102] Step 3: The ADAE server processes the request by first authenticating the VAL server and then checking its authorization. Once authorized, the ADAE server can first query the FL client pool to search for FL clients capable of fulfilling the FL training requirements sent by the VAL server. The ADAE server can then select from the discovered FL clients, for example, to fulfill the minimum number of FL clients required to become part of an FL group. The ADAE server can then create the FL group and assign an identifier to it. Additionally, the ADAE server can create a context to associate information received in the request with the FL group and store this information externally in a RESTful resource within the ADAE server or in a data storage entity. Furthermore, the ADAE server can communicate with the 5G network to perform member selection based on the requirements provided by the VAL server. The ADAE server can invoke the Nnef_AFsessionWithQoS API with QoS requirements for FL operations, along with a list of UEs used as FL clients. The ADAE server can store the response from the 5G network in a RESTful resource. Additionally and / or alternatively, the ADAE server can subscribe to UE membership selection assistance based on the 5G network by providing UE membership filtering criteria (such as QoS requirements, access type, FL operation transmission time, UE location, and mobility information). In response, the 5G network can send a notification message to the ADAE server containing a list of candidate UEs that match the UE membership filtering criteria. Note that the ADAE server may communicate with the 5G network in a different order than described, for example, requesting UE membership selection assistance before calling the Nnef_AFsessionWithQoS API.

[0103] Step 4: The ADAE server can send a notification to all selected ADAE clients (e.g., UEs) informing them that their selection is part of an FL group. This notification may include a subscription identifier, a previously supplied FL policy identifier, an assigned FL group identifier, the group management operation to be performed (e.g., add, remove, etc.), and when the federated operation can be scheduled. Note that the FL policy identifier can indicate what type of FL operation (e.g., training, inference, etc.) the FL group requests.

[0104] Step 5: The ADAE client can return a response to the ADAE server, and in the response, the ADAE client can specify whether the client can execute and whether it can execute the federated operation in the desired schedule.

[0105] Step 6: The ADAE server can make a request to the 5G network to provide the requested QoS to the FL clients in the FL group. If the Nnef_AFsessionWithQoS API has not yet been invoked in Step 3 using a list of UE addresses and QoS information of the UEs in the FL group, the ADAE server can execute the Nnef_AFsessionWithQoS API. The 5G network can return the result for each UE identified in the UE list found in the request.

[0106] Step 7: The ADAE server can 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 scheduling 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 maintain the privacy of FL clients, the list of FL client identifiers can be anonymous.

[0107] Figure 10 The procedure demonstrates enhancements to the ADAE service that support federated learning. Other embodiments can also be implemented to add support for federated learning. For example, Figure 4 The aforementioned SEAL-based group creation procedure shown can also be enhanced for federated learning. Figure 11 An example of enhancing SEAL groups and location management servers to support federated learning is shown. A location management client, as part of the SEAL layer and which can be considered a SEAL client, can instruct support for federated learning as part of the location service registration process. The location-based group creation process in the group management server can then be enhanced using filtering criteria with FL capabilities, thereby searching not only for UEs in specific locations but also for UEs with FL capabilities. Note: Within the SEAL architecture, location management clients and group management clients can also be considered SEAL clients, and this can be extended to other management clients within the SEAL architecture.

[0108] Step 1: The location management client (e.g., residing on a UE that supports FL client functionality) can perform location service registration with the 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 can 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 include instructions in the registration request to support federated learning. Additionally, FL policies can be pre-provisioned to the VAL server and ADAE server as part of federated learning integration. The provisioned information can be information specific to the respective entities, as shown in Table 1.

[0109] Step 2: The VAL server may make a location-based group creation request, which may include the desired location and an indication that the UE is FL-capable. This request may include information (such as that shown in Table 3) to assist the location management server in discovering and selecting appropriate FL clients to participate in federated operations.

[0110] Step 3: The group management server can communicate with the location management server to obtain a list of UEs that are located in the desired location and also have FL capability. The group management server can receive the list of UEs that have FL capability in the desired location and store the list internally.

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

[0112] 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. Due to the mobility of UEs within and outside their desired locations, the ADAE server may be able to assist the VAL server in managing FL groups. For example, the ADAE server may be able to dynamically manage the addition and removal of UEs from FL groups. Additionally, the ADAE server can also use analytics to predict when to add and remove FL-capable UEs from FL groups.

[0113] Step 6: As part of processing the request, the ADAE server can notify the ADAE clients (i.e., FL clients) of their selection of FL groups. This notification may include a subscription identifier, a previously supplied FL policy identifier, an assigned FL group identifier, the group management operation to be performed (e.g., add, remove, etc.), and when the federated operation can be scheduled. Note that the FL policy identifier can indicate what type of FL operation (e.g., training, inference, etc.) the FL group requests.

[0114] Step 7: The ADAE server can return a response to the VAL server, which includes the status of the FL group creation request, the FL group identifier, the list of FL client identifiers that have been notified and accepted to be included in the FL group, and the validity and / or scheduling 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 maintain the privacy of FL clients, the list of FL client identifiers can be anonymous.

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

[0116] Notice, Figure 10 and Figure 11 The procedure shown illustrates a combination of FL client discovery, selection, and FL group creation in the ADAES architecture. Those skilled in the art will understand that this procedure can also be applied to the edge enabler layer, the service enabler architecture layer (SEAL), and other application enabler layers.

[0117] FL group management.

[0118] A key benefit 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 due to changes in FL client availability, for example, as a result of UE mobility. The application enabler server may have access to the cellular network API, which may be able to identify UEs in a given area of ​​interest. Furthermore, network analytics may be used to predict UE mobility to that area of ​​interest, enabling more proactive FL group management.

[0119] Figure 12 An example procedure for dynamic FL group management is shown, where UE2 (i.e., EEC2) can leave the area of ​​interest, and UE1 (i.e., EEC1) can move to 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 to make such decisions, thereby minimizing the signaling overhead of such management tasks that the application enabler server could easily perform.

[0120] Step 1: EEC1, EEC2, and EAS may have registered their FL support and capabilities with EES and may have created FL groups as previously described. Initially, EEC2 is a member of the FL group, where other EECs are not shown, but EEC1 is not, as it is not located in the region of interest that might request FL operations. EAS provides FL server functionality and has requested the creation of the FL group, and EES has created context information for the FL group. EEC1, EEC2, EES, and EAS all have FL policy information that may have been provided for desired FL applications.

[0121] Step 2: The EES can leverage the 5G network to create subscriptions for UE location and monitoring to assist in managing FL group operations. Subscriptions can monitor the QoS of individual EES during FL operations and also obtain UE locations in areas of interest.

[0122] Step 3: EEC2 leaves the region of interest, and EEC1 moves to the region of interest.

[0123] Step 4: The 5G network can track the UE mobility of both EEC1 and EEC2 and can notify the EES that EEC2 has left the Area of ​​Interest (OI), while EEC1 is still in the OI. The 5G network can send one or more notifications to the EES at the location of the UE detected by the network. Additionally and / or alternatively, the EES can receive registration update requests from the EEC, or receive ACR detections / requests as indicators of UE location changes. The EES can 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 figure.

[0124] Step 5: EES can detect that EEC2 is part of an FL group created by EAS and can remove EEC2 from the FL group. Additionally, EES can notice that EEC1 has entered the area of ​​interest (e.g., by receiving a registration request for EEC1 or receiving the context of EEC1) and can examine EEC1's FL policy to assess whether EEC1 can be added to the FL group. During the examination, 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 consent for adding it to the FL group. This request may include the FL group identifier, information from the FL policy such as ML application, dataset requirements, FL operation scheduling, a request for user consent to participate in FL operations, and other information from the context of the FL group.

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

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

[0127] Step 8: The EES can send a notification to the EAS regarding modifications to the FL group. This notification may include the FL group identifier, the FL group management operation (e.g., addition or removal), the UE identifiers associated with the EEC1 that are added / removed, and the corresponding policy showing the FL capabilities and dataset information provided by the EEC1 for the FL operation.

[0128] Application enabler servers can also leverage analytics to assist in FL group management. Analytics can be performed by analytics functions within the 5G network or by the ADAE server within the ADAE architecture. Within the 5G network, the ADAE server or analytics functions within the 5G network can subscribe to 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 to assist in the creation and management of FL groups. The resulting analytics outputs (statistics or predictions) 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 loading, 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 This demonstrates an example program where the ADAE server uses network and / or application-level analytics to assist in FL group management. Note that other analytics besides those mentioned above may also be available to assist in FL group management.

[0129] Step 1: The ADAE client and VAL server may have registered their FL support and capabilities with the ADAE server and may have created FL groups as previously described. The VAL server can provide FL server functionality and may have requested the creation of FL groups, and the ADAE server has created context information for the FL groups. The ADAE client, ADAE server, and VAL server all have FL policy information that may already be provided for the desired FL applications.

[0130] Step 2: The ADAE server can configure application-specific analytics for FL groups, such as edge load analysis, to determine whether FL operations are suitable for a specific edge data network. The ADAE server can also create subscriptions to receive analytics output from the 5G network, thereby aiding in the management of FL group operations. For example, a subscription could be for obtaining UE mobility, user data congestion, QoS sustainability, network function load, and network performance analytics for areas of interest. The analytics output can provide insights into the network performance required for successful FL operations.

[0131] Step 3: An ADAE client on the UE that was not originally part of the FL group is moving toward the area of ​​interest that created the FL group. The 5G network's analytics component can collect data and perform analysis on the UE's mobility toward the area of ​​interest.

[0132] Step 4: The generated analysis can predict that ADAE clients are moving toward the area of ​​interest and can send the prediction results and estimated arrival times(one or more) notifications to the ADAE server. Other analysis outputs can also provide statistics and / or predictions of network performance and congestion, which the FL server can use to make decisions about FL operations. Application-specific analyses can also be generated, for example, by the ADAE server itself or by another ADAE server, and used to manage the members of FL groups.

[0133] Step 5: The ADAE server can add ADAE clients to the FL client pool managed by the ADAE server and can send FL group management requests to ADAE clients. This request can include the FL group identifier and contextual information from the FL group, such as ML application, dataset requirements, FL operation scheduling, and requests for user consent to participate in FL operations.

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

[0135] Step 7: The ADAE server can perform FL group modifications to add ADAE clients as new members of the FL group. The ADAE server can update the context information associated with the FL group. Note that the FL group may have a minimum number of FL clients required, and if the number of members falls below the minimum, the ADAE server can proactively use analytics to add more members to the FL group to meet the minimum number of members. Additionally, analytics can indicate a valid time window for forecasting, and the ADAE server can use this information to proactively manage the FL group.

[0136] Step 8: The ADAE server can send a notification to the VAL server regarding the modification of the FL group. This notification may include the FL group identifier, the FL group management operation (e.g., addition or removal), the UE identifier associated with the ADAE client that was added / removed, and the corresponding policy showing the FL capabilities and dataset information provided by the ADAE client for the FL operation.

[0137] It is worth noting that, Figure 12 and Figure 13 The FL group management procedure shown can also be applied to other application enablement layers, such as the Service Enabler Architecture (SEAL) layer. For scenarios where analytics is used for FL group management, the application enabler layer server can subscribe to analytics based on analytics capabilities within the ADAE server and / or 5G network.

[0138] user interface.

[0139] The processes of FL client discovery, selection, and FL group creation and management can be presented in a graphical user interface, such as one exposed to users of the FL server via a VAL server or EAS. An example of such a GUI is... Figure 14 As shown in the image.

[0140] Within the GUI, the application enabler server can display the FL client pool that it can manage, allowing users to select which FL clients to add to FL groups. Correspondingly, the members of each FL group can also be displayed and grouped together, as shown in the figure. Information about the FL group can be obtained by pressing the "More Information" button, while pressing each client name displays FL client-specific information. Then, as a UE hosting an FL client moves from one area to another, the FL client pool can shrink and / or expand to align with UE mobility. Furthermore, if a UE moves out of the FL group's service area, the application enabler server can automatically remove the FL clients associated with that UE from the FL group and / or client pool.

[0141] Example communication system.

[0142] The 3rd 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 referred to as 3G), LTE (commonly referred to as 4G), Advanced LTE—Standard—and New Radio (NR), also known as “5G.” 3GPP NR standard development is expected to continue and include the definition of Next Generation Radio Access Technologies (New RATs), which are expected to include new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to include new, non-backward-compatible radio access in new spectrum below 7 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to handle a wide set of 3GPP NR use cases with varying requirements. Ultra-mobile broadband is expected to include both cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for, for example, indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with flexible radio access below 7 GHz, featuring cmWave and mmWave-specific design optimizations.

[0143] 3GPP has identified a variety of use cases expected to be supported by NR, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: Enhanced Mobile Broadband (eMBB) Ultra-Reliable Low-Latency Communications (URLLC), Massive Machine-Type Communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and Enhanced Vehicle-to-Everything (eV2X) communications, which can include any of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N), vehicle-to-pedestrian (V2P), and vehicle-to-other-entities communications. Specific services and applications within these categories include, for example, monitoring and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first-responder connectivity, automotive electronic calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases, as well as others, are anticipated in this document.

[0144] Figure 15AAn example communication system 100 is illustrated, in which the methods and apparatus described and claimed herein may be one aspect. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f and / or 102g (generally or collectively referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 108B, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, Internet 110, other networks 112 and V2X servers (or ProSe functions and servers) 113, although it will be appreciated that any number of WTRUs, base stations, networks and / or network elements are contemplated in the disclosed examples. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and 102g is... Figure 15A-5 While described as a handheld wireless communication device, it is to be understood that each WTRU may include or be embodied in any type of device or equipment configured to transmit and / or receive wireless signals, in the context of the wide variety of use cases anticipated for 5G wireless communication. Examples, by way of example only, include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, laptops, personal computers, wireless sensors, consumer electronics devices, wearable devices such as smartwatches or smart clothing, medical or electronic healthcare devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes, and the like.

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

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

[0147] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115 / 116 / 117.

[0148] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b. The wired or air interface 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.). Any suitable radio access technology (RAT) can be used to establish air interfaces 118b / 116b / 117b.

[0149] RRH 118a, 118b, TRP119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 118C / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

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

[0151] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 103 / 104 / 105, or RRHs 118a, 118b, TRPs 119a, 119b, RSUs 120a and 120b, and WTRUs 102c, 102d, 102e, and 102f in RAN 103b / 104b / 105b, can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), and air interfaces 115 / 116 / 117 or 115c / 116c / 117c can be established using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

[0153] In some cases, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 103 / 104 / 105, or RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b, and WTRUs 102c, 102d, 102e, and 102f in RAN 103b / 104b / 105b, can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate Evolution (EDGE) of GSM, and GSM EDGE (GERAN) and similar substances.

[0154] Figure 15ABase 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 local area (such as a business location, home, vehicle, campus, and the like). In some cases, base station 114c and WTRU 102e can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In some cases, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In some cases, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 15A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114c may not be required to access Internet 110 via core network 106 / 107 / 109.

[0155] RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b can 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 WTRUs 102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform high-level security functions such as user authentication.

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

[0157] Core networks 106 / 107 / 109 can also serve 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 Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 108B or a different RAT.

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

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

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

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

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

[0163] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., such as UTRA and IEEE 802.11).

[0164] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from these. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad / indicator 128. Additionally, 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 in said suitable memory. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital storage (SD) card, and the like. In some cases, processor 118 can access information from memory that is not physically located on WTRU 102 (such as a server or home computer (not shown)) and store the data in that memory.

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

[0166] Processor 118 may also be coupled to GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of WTRU 102. Attached to or in lieu of the information from GPS chipset 136, WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 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 WTRU 102 may acquire location information by means of any suitable location determination method while maintaining consistency with one side.

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

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

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

[0170] like Figure 15CAs shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control the corresponding node B 140a, 140b, or 140c to which it is connected. Additionally, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

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

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

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

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

[0175] Figure 15DThis is a system diagram of RAN 104 and core network 107. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

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

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

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

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

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

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

[0182] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between core network 107 and PSTN 108. Additionally, core network 107 can provide WTRUs 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.

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

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

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

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

[0187] like Figure 15EAs shown, 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, which includes, for example, protocols for facilitating data delivery and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, Accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0188] MIP-HA manages IP addresses and enables WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 provides WTRUs 102a, 102b, and 102c with access to packet-switched networks such as the Internet (110), facilitating communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA Server 186 handles user authentication and user support services. Gateway 188 facilitates interoperability with other networks. For example, Gateway 188 provides WTRUs 102a, 102b, and 102c with access to circuit-switched networks such as the PSTN (108), facilitating communication between WTRUs 102a, 102b, and 102c and legacy terrestrial communication equipment. Additionally, gateway 188 may provide WTRUs 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.

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

[0190] The descriptions in this article and Figure 15A , 15CThe core network entities illustrated in 3GPP 15D and 15E are identified by names given to these entities in existing 3GPP specifications. However, it should be understood that these entities and functions may be identified by other names in the future, and certain entities or functions may be combined in future specifications released by 3GPP (including future 3GPP NR specifications). Therefore, Figure 15A , 15B The specific network entities and functions described and illustrated in 15C, 15D and 15E are provided as examples only, and it is to be understood that the subject matter disclosed and claimed herein can be embodied or implemented in any similar communication system, whether currently defined or in the future.

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

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

[0193] 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 allows for the storage and retrieval of information. ROM 93 generally contains stored data that is unlikely to be modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide address translation functionality, which translates virtual addresses into physical addresses during instruction execution. The memory controller 92 can also provide memory protection functionality, which isolates processes within the system and separates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; it may not access memory within the virtual address space of another process unless memory sharing has been established between the processes.

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

[0195] 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 using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touchpad. The display controller 96 includes the electronic components required to generate the video signals sent to the display 86.

[0196] Furthermore, the computing system 90 may include communication circuitry, such as, for example, 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, Internet 110, or... Figure 15A , 15B Other networks 112, such as 15C, 15D, and 15E, enable the computing system 90 to communicate with other nodes or functional entities in these networks. The communication circuitry, either alone or in combination with the processor 91, can be used to perform the transmission and reception steps of certain means, nodes, or functional entities described herein.

[0197] Figure 15GAn example communication system 111 is illustrated, in which the methods and apparatus described and claimed herein may be an aspect. As shown, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it will be appreciated that this disclosure contemplates any number of WTRUs, base stations, networks, and / or network elements. One or more or all WTRUs A, B, C, D, and E may be outside the network range (e.g., outside the cell coverage boundary shown as a dashed line in the figure). WTRUs A, B, and C form a V2X group, in which WTRU A is the lead of the group, and WTRUs B and C are group members. WTRUs A, B, C, D, E, and F may communicate via a Uu interface or a Sidelink (PC5) interface.

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

[0199] definition.

[0200] Definitions of the abbreviations found within the scope of this disclosure are provided below.

[0201] .

[0202] Definitions of terms within the subject of this disclosure are provided below.

[0203] 。

Claims

1. A method executed by an application enabler server, comprising: Receive requests for forming federated learning (FL) groups; Assign at least one UE to the FL group; Send a request to the core network to obtain one or more UEs in the FL group, wherein the request may include filtering criteria, which include QoS requirements, access type, FL operation transmission time, UE location and mobility information, or a combination of the above. Receive a response from the core network containing a list of one or more UEs; and Send a response to the request for forming the FL group, the response indicating the status corresponding to the FL group.

2. The method of claim 1, wherein the response to the request for forming the FL group includes the status of the request for forming the FL group, an FL group identifier, one or more UE identifiers selected for the FL group, scheduling of FL operations, or a combination of the above.

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

4. The method of claim 1, wherein a notification is sent to the at least one UE, the notification indicating the selection of the at least one UE as part of the FL group; and Receive a response from the at least one UE, the response indicating that the UE is able to participate in FL operation.

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

6. The method according to claim 1, further comprising: Multiple UEs are discovered from the FL client pool, and at least one UE is assigned to the FL group based on the discovery.

7. The method according to claim 1, further comprising: Assign the FL group identifier to the FL group.

8. A method executed by an application enabler server, comprising: Send a location-based group creation request to the group management server; Receive a response to the location-based group creation request, the response including at least a list of UEs that satisfy location criteria, federated learning (FL) criteria, or both. Based on the UE list, send an FL group creation request; as well as Receive a response to the FL group creation request, the response including information corresponding to the FL group.

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, the FL group identifier, one or more FL client identifiers, the scheduling of FL operations, or a combination of the above.

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, a list of FL clients, FL client capability requirements, the number of clients to be part of the FL group, the FL group's quality of service requirements, the FL group's geographic location, or a combination of the above.

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

13. The method of claim 12, wherein the one or more FL policies include server identifiers, FL configuration identifiers, FL roles, application identifiers, machine learning (ML) models or algorithms, ML application types, one or more FL capabilities, FL security information, FL user information, FL history information, or combinations thereof.

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

15. An apparatus comprising: One or more processors; Memory; as well as A set of instructions stored in the memory, which, when executed by the one or more processors, cause: Receive requests for forming federated learning (FL) groups; Assign at least one UE to the FL group; Send a notification to the at least one UE, the notification indicating that the at least one UE is selected as part of the FL group;    Send a request to the core network for quality of service metrics for one or more UEs in the FL group;    Receive the quality of service metric from the one or more UEs; as well as Send a response to the request for forming the FL group, the response indicating the status corresponding to the FL group.

16. The apparatus of claim 15, wherein the response to the request for forming the FL group includes a status of the request for forming the FL group, an FL group identifier, one or more FLUE identifiers selected for the FL group, scheduling of FL operations, or a combination of the above.

17. The apparatus of claim 15, wherein the request for forming the FL group includes an FL server identifier, an FL group identifier, an FL policy, a list of FL clients, FL client capability requirements, the number of clients to be part of the FL group, the quality of service requirements of the FL group, the geographical location of the FL group, or a combination of the above.

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

19. The apparatus of claim 18, wherein the set of instructions, when executed by the one or more processors, further causes: Authenticate the VAL server.

20. The apparatus of claim 15, wherein the set of instructions, when executed by the one or more processors, further causes: Multiple UEs are discovered from the FL client pool, and based on the discovery, at least one UE is assigned to the FL group.

Images