Analytics-assisted satellite access optimization function

Abstract

An analytics-assisted satellite access optimization (SAO) function is described herein. In an example, an application / service enabler layer server supporting the SAO function may receive, from a requestor, a request to provide analytics information for satellite access. The server may send, to a satellite service provider, a request, for satellite information. The server may receive, from the satellite service provider, satellite information. The server may send, to a core network and / or one or more UEs, a request for UE information. The server may receive, from the core network and / or the one or more UEs, the UE information. The server may generate, based on the satellite information and the UE information, analytics information for satellite access. The server may send a notification indicating the generated analytics information. The server may receive updated satellite information and / or UE information, based on a generation of updated analytics information.

Description

CNV15053W001 / 101859.002174ANALYTICS-ASSISTED SATELLITE ACCESS OPTIMIZATION FUNCTIONCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 681,404, filed August 9, 2024, which is hereby incorporated by reference in its entirety.BACKGROUND

[0002] Non-terrestrial networks via satellite access can improve the connectivity of networks to achieve ubiquitous network coverage. Satellite access for 5G systems will increase network coverage and availability of 5G services with the integration of satellite access. Satellite may be used as part of the backhaul between (R)AN and 5G core network. 3GPP has developed specifications to support the integration of satellite components within the 5G system.

[0003] 5G networks may need to predict coverage and availability information of satellites to take proactive actions to ensure seamless satellite connectivity and / or to optimize satellite access performance. Moreover, the network, application and / or satellite service provider may require predictive information about UEs in the service area of a satellite to optimize their service deployment. Currently, there is a lack of support of proactive approach for optimizing satellite access for service providers.

[0004] Accordingly, there is a need for improved satellite access techniques.SUMMARY

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

[0006] An analytics-assisted satellite access optimization function is described herein to support various features including satellite performance analytics, satellite selection andCNV15053W001 / 101859.002174 recommendation, UE access pattern optimization, satellite transmission pattern optimization, etc. Functions supported include but are not limited to:

[0007] Satellite access analytics for vertical application layer and application enablement layer;

[0008] Satellite access analytics for satellite service providers; and

[0009] Distributed satellite access analytics.

[0010] In an example, an application / service enabler layer server supporting a satellite access optimization (SAO) function may receive, from a requestor, a request to provide analytics information for satellite access. The application / service enabler layer server may send, to a satellite service provider, a request, for satellite information. The application / service enabler layer serv er may receive, from the satellite service provider, satellite information. The application / service enabler layer server may send, to a core network and / or one or more UEs, a request for UE information. The application / service enabler layer server may receive, from the core network and / or the one or more UEs, the UE information. The application / service enabler layer server may generate, based on the satellite information and the UE information, analytics information for satellite access. The application / service enabler layer server may send a notification indicating the generated analytics information. The application / service enabler layer server may receive updated satellite information and / or UE information, based on a generation of updated analytics information.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to facilitate a more robust understanding of the application, reference is now made to the accompanying drawings, in which like elements are referenced with like numerals. These drawings should not be construed to limit the application and are intended only to be illustrative.

[0012] FIG. 1 show s an example architecture diagram of general data networks;

[0013] FIG. 2 shows an example architecture diagram of edge networks;

[0014] FIG. 3 shows an example procedure for satellite access analytics for Vertical Application Layer (VAL) / Application Enabler Layer (AEL);

[0015] FIG. 4 show s an example procedure for satellite access analytics for satellite service provider;

[0016] FIG. 5 shows an example procedure for distributed satellite access analytics;CNV15053W001 / 101859.002174

[0017] FIG. 6 shows an example graphical user interface (GUI);

[0018] FIG. 7A illustrates an example communications system;

[0019] FIG. 7B shows a system diagram of an example RAN and core network;

[0020] FIG. 7C shows a system diagram of an example RAN and core network;

[0021] FIG. 7D shows a system diagram of an example RAN and core network;

[0022] FIG. 7E illustrates another example communications system;

[0023] FIG. 7F is a block diagram of an example apparatus or device, such as a WTRU; and

[0024] FIG. 7G is a block diagram of an exemplary computing system.DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0025] Methods are described herein for an analytics-assisted satellite access optimization function to support various features including satellite performance analytics, satellite selection and recommendation, UE access pattern optimization, satellite transmission pattern optimization, etc.

[0026] The following abbreviations are described herein:CNV15053W001 / 101859.002174

[0027] The deployment of terrestrial networks can be driven by the coverage of population centers rather than by the coverage of geographical areas. This can lead to the creation of geographical areas where access to 5G services through the radio coverage of a terrestrial network will not be possible. In such cases, UEs whether associated with pedestrian users, or on moving land / airbome / maritime mobile platforms can experience conditions where 5G services cannot be offered continuously by a single or a combination of terrestrial networks. In addition, conditions such as natural or human-made disasters may lead to temporary outage or destruction of the terrestrial network infrastructures, which may also cause the unavailability of terrestrial networks.

[0028] Non-terrestrial network via satellite access can improve the connectivity of networks to achieve ubiquitous network coverage. Satellite access for 5G systems will increase network coverage and availability of 5G services with the integration of satellite access. In comparison with terrestrial networks, satellite networks may help achieve better serv iceCNV15053W001 / 101859.002174 scalability due to the larger coverage area (ty pically corresponding to tens of thousands of cells of a terrestrial network) and the ability to offload traffic from terrestrial networks.

[0029] Satellite may be used as part of the backhaul between (R)AN and 5GC. For some deployments, UPF may be deployed on the satellite. In these cases, edge computing or local switch via UPF deployed on the satellite may be performed.

[0030] 3GPP has developed specifications to support the integration of satellite components within the 5G system. Service requirements, architecture and solutions have been specified including the support of discontinuous coverage which is inherent to NGSO satellite deployments. 3GPP further studied use cases to support new capabilities such as store and forward satellite operation and UE-satellite-UE communication. These capabilities are implicitly requiring a regenerative payload approach.

[0031] 3GPP SA6 developed several 5G vertical application enablers and enabler frameworks (e.g. SEAL, EDGEAPP) with various capabilities that enable vertical application communication over terrestrial 3GPP networks. SA6 is currently studying the impacts to the enabler layer in order to support satellite access, such as how to use satellite access characteristics to optimize application layer enablement behavior, how to support the discontinuous / intermittent connectivity patterns between UEs and application servers / functions, how to support edge computing on-board the satellite, etc.

[0032] 5G networks may need to predict coverage and availability information of satellites to take proactive actions to ensure seamless satellite connectivity and / or to optimize satellite access performance. Whether a specific UE will be in the coverage of a satellite may be estimated by comparing the UE’s location with the satellite’s service area, which may depend on predictive information of both the satellite and the UE. A satellite’s sendee area information may be obtained from the satellite service provider or calculated based on the satellite’s ephemeris. The location / mobility information of a UE may be obtained from the 5G network and / or from the UE itself. Particularly, predicted location / mobility information of UEs may be obtained from analytics sendees in the 5G network such as NWDAF, which may provide information such as the predicted location of UE, predicted UE distribution in a certain area, etc. The existing satellite coverage / availability information does not consider the mobility of UEs, which may rely on analytics information of UE’s location and mobility.

[0033] Moreover, the VAL, AEL, and / or satellite sendee provider may require predictive information about UEs in the service area of a satellite, such as how many UEs willCNV15053W001 / 101859.002174 be in the coverage area of the satellite, how much uplink / downlink traffic will be generated for the UEs accessing the satellite, etc. Existing services may be able to generate predictive UE distribution information for a certain service area (analytics area). As the service areas of satellites may be dynamic (e.g. for NGSO satellites), the analytics consumer (e.g. VAL server, AEL server, and / or satellite service provider) may need to constantly update their analytics request with the updated service area based on the satellite's trajectory, resulting in a communication burden for the consumer and the network.

[0034] Existing satellite access services only consider the coverage / availability of satellites, while the performance of satellite access may also affect the decision of satellite selection and configuration. Different from terrestrial access, performance of satellite access may depend on many more factors such as the limited coverage window, limited feeder link availability, cooperation with other satellites via inter-satellite communication, dynamic switching between satellite and terrestrial accesses, etc. In addition, considering the limited access window, satellite accesses from multiple UEs may need to be coordinated to optimize the overall performance. A holistic view of various factors may be required to optimize the performance of satellite access.

[0035] Systems, apparatuses, and methods are described herein to enable analytics- assisted satellite access optimization (SAO) function. Features described herein include the following:

[0036] An application / service enabler layer server supporting SAO function (SAO server) with the following operations:

[0037] Receiving a request to provide analytics information for satellite access from a requestor. The requestor may be a VAL server / client, a SEAL server / client, an edge configuration server, a satellite service provider, a SAO client, etc.;

[0038] Sending a request to a satellite service provider for satellite information.

[0039] Receiving satellite information from the satellite service provider. The satellite information may include ephemeris, satellite capacity, satellite schedule, feeder link availability and status, inter-satellite communication availability and status, coverage information, gaps in satellite coverage, etc.

[0040] Sending a request to the core network and / or one or more UEs for UE information. The request may be sent to a network function in the core network. The request may be sent to the SAO client on the UE.CNV15053W001 / 101859.002174

[0041] Receiving UE information from the core network and / or UEs. The UE information may include UE location and mobility information, access methods, schedule, UE application requirements, UE application schedule, application traffic pattern, UE density, UE distribution, etc. The UE information may include analytics information.

[0042] Generating analytics information for satellite access based on the collected data. The analytics information may include recommendations on which satellites should be accessed by a specific UE or a specific group of UEs. list of selected / recommended satellites, satellite coverage analytics, satellite performance analytics, ranking list of satellites based on specific performance metrics, recommended satellite access patterns for a UE or a group of UEs, estimated satellite access patterns from UEs, satellite sendee areas, recommended transmission patterns of satellites, etc.

[0043] Sending a notification indicating the generated analytics information. The notification may be sent to the requestor, one or more UEs, satellite service providers, etc.

[0044] Receiving updated satellite information and / or UE information, based on which generating updated analytics information.

[0045] An application / service enabler layer client supporting SAG function (SAO client) with the following operations:

[0046] Receiving a request to provide analytics information for satellite access from a requestor. The requestor may be an application client on the same UE, the SAO client of another UE, the SAO server, etc.

[0047] Sending a request to the SAO server for satellite information and receiving satellite information from the SAO server

[0048] Collecting UE information locally at the UE. The UE information may be collected from one or more application clients on the UE. The UE information may include UE location and mobility information, access methods, schedule, UE application requirements, UE application schedule, application traffic pattern, measurements of the satellite access performance, etc.

[0049] Sending at least a portion of the collected UE information to the SAO client of another UE.

[0050] Receiving information of another UE from the corresponding SAO client.

[0051] Generating analytics information for satellite access based on the collected and received data. The analytics information may be generated locally, or cooperatively withCNV15053W001 / 101859.002174 one or more SAO clients of other UEs, or cooperatively with the SAO server, or a combination thereof.

[0052] Sending a notification indicating the generated analytics information. The notification may be sent to the requestor, SAO clients of one or more UEs, the SAO server, etc.

[0053] Receiving updated satellite information and / or UE information, based on which generating updated analytics information.

[0054] The analytics-assisted satellite access optimization (SAO) function described herein may generate and expose analytics information about satellite access to VAL clients and servers, AEL clients and servers, satellite service providers and other entities. The analytics information may include statistics and predictions about satellite coverage / availability information, satellite access performance, ranking of satellites according to specific performance metrics, etc. In addition, the proposed function may generate and provide instructions on how to optimize satellite access based on the analytics information, such as suggesting access patterns for group of UEs, suggesting transmission patterns for group of satellites, etc. Note that analytics information or analytics results may include statistics, predictions, and other information that is derived based on such statistics or predictions, such as recommendations, instructions, etc.

[0055] The proposed function may be integrated into an existing service such as SEAL, EEL, ADAE, or other AEL services. The proposed function may be integrated in multiple AEL services, e.g. the analytics aspect may be integrated in ADAE and the satellite selectiorf recommendation aspect may be integrated in SEAL / EEL. Alternatively, the proposed function may be implemented as a standalone function / service which may interact with the other AEL services and entities.

[0056] FIG. 1 shows an example architecture 100 with SAO function integration in general data networks.

[0057] FIG. 2 shows an example architecture 200 with SAO function integration in edge data networks.

[0058] The SAO function may be split into a SAO client and SAO server performing client-side and server-side functionalities respectively. The SAO client may be hosted on a UE as an application enabler client, SEAL client, edge enabler client, etc. The SAO server may be implemented as an application enabler server, a SEAL server, an edge enabler server, etc.CNV15053W001 / 101859.002174

[0059] The proposed SAO function may leverage analytics and / or AIML capabilities (internal or external) to enhance / optimize the communication and service performance of satellite accesses. Particularly, the SAO function may collect and generate estimations / predictions of the mobility information of UEs and satellites, satellite access performance, access patterns of UEs, and other relevant information. An example embodiment is defining one or more analytics IDs, as described in the following.

[0060] In order to generate the desired analytics information, input data as shown in Table 1 may be collected by the SAO function.Table 1. Input data for satellite access analyticsCNV15053W001 / 101859.002174CNV15053W001 / 101859.002174CNV15053W001 / 101859.002174CNV15053W001 / 101859.002174CNV15053W001 / 101859.002174

[0061] Based on the input data, the following analytics output may be generated by the SAO function, as shown in Table 2. Note that the analytics outputs shown in Table 2 can consist of statistics and / or predictions, and other information that is derived based on the statistics / predictions.Table 2. Output data of satellite access analyticsCNV15053W001 / 101859.002174CNV15053W001 / 101859.002174

[0062] Some of the analytics outputs from Table 2 may be derived based on the output of other analytics IDs. The SAG function may decode an analytics request (analytics ID) into multiple sub-requests, where each sub-request may be associated with an analytics request (analytics ID) or query7. The response and / or results of the sub-requests will be used as the input for the original analytics request. The SAG function may then perform aggregation or fusion of analytics outputs from multiple analytics IDs to generate the desired analytics results. For example,

[0063] To predict the coverage of one or more satellites regarding a UE, the SAG function may need to determine whether the UE will be in the coverage of the satellite(s) at each time instance within a (future) time period, which requires the location information of both the satellite(s) and the UE at that time instance. The location of the satellite(s) at the futureCNV15053W001 / 101859.002174 time instance may be determined or predicted based on satellite information such as its ephemeris. The location of the UE at the future time instance may be predicted with UE mobility analytics (e.g. provided by NWDAF). By comparing the predicted locations of the satellite(s) and the UE, the SAO function may determine whether the UE is in coverage of the satellite(s) for each future time instances, and further calculate the overall coverage.

[0064] To predict the load of a satellite, the SAO function may need UE density information for the satellite's service area. For NGSO satellites, the service area may change over time. The SAO function may first derive the service area information of the satellite in future time instances based on its ephemeris. For each time instance, the SAO function may predict the density of UEs that will be using satellite access in the predicted satellite sendee area by using the predicted satellite service area as the analytics area or area of interest for UE density analytics. The SAO function may then estimate the amount of data traffic requiring satellite access for applications on the UEs, based on which, the SAO function may estimate the load of the satellite.

[0065] A UE may switch between terrestrial network and satellite access. To generate se ice performance analytics for the UE, the SAO function may consider both terrestrial and satellite-based access methods. The SAO function may first predict the schedule of both types of accesses, based on which the analytics periods for each ty pe of access can be determined. The SAO function may then use separate analytics IDs for performance prediction in each access method with the segmented analytics periods. Based on these predictions, the SAO function may make a recommendation to a UE whether it should use terrestrial network and satellite access at certain scheduled times.

[0066] The network KPIs for a given UE (target UE) may depend on the access patterns of other competing UEs that may be located in the same area as the target UE and / or accessing the same satellite(s) during the same time period as the target UE. To predict the network KPIs for the target UE, the SAO function may collect and / or generate information such as predicted density' of competing UEs and their mobility information, application network requirements of the target and competing UEs, predicted mobility pattern of the one or more satellites that the target UE may be accessing and their corresponding KPIs, etc. Based on the collected or generated information, the SAO function may make an estimation of the expected network KPIs of the target UE, which may be further used to generate a recommendation on satellite selection and / or satellite access pattern.CNV15053W001 / 101859.002174

[0067] Satellite access analytics for VAL / AEL are described herein. The SAO function, as a SAO server and / or other enabler server(s), may receive a request from an application or service provider (e.g. VAL server, SEAL server, EES / ECS) to determine the optimal selection of satellites via which a UE or a group of UEs may access the application / service based on the estimated performance of service that the UE(s) may receive. Alternatively, the SAO function, as a SAO client and / or other enabler client(s), may receive a request from an application or service client to perform satellite access analytics. In this procedure, the SAO function may assist the exposure of satellite information to VAL servers.

[0068] FIG. 3 shows an example procedure 300 in which an SAO function may assist the exposure of satellite information to VAL servers. Note that the steps may be performed in an order different than shown in the figure. Although not shown in the figure, each request message may be followed by a response message indicating the request is accepted / declined and / or an acknowledgement.

[0069] Pre-conditions: The SAO function may be pre-provisioned with information of the satellite service providers and the satellites they may provide, such as identifiers of the satellites.

[0070] At step 1, the requestor (e.g. VAL server / chent, SEAL server / client, ECS) may send a satellite access analytics request to the SAO function (SAO server or client), requesting the SAO function to provide analytics information of the satellites that the UEs may access and recommendations on which satellite(s) should be accessed by a specific UE or a specific group of UEs. The request may specify what information is required to be generated by the SAO function, such as a list of selected satellites, satellite performance analytics, a ranking list of satellites based on specific performance metrics, recommended satellite access patterns for a group of UEs, etc. The request may include the following information as well as other information in Table 1.

[0071] Satellite information: The requestor may specify’ a list of candidate satellites from which the SAO function may make the selection and recommendation. Alternatively, the requestor may specify one or more satellite service providers. If the requestor does not provide any information on candidate satellite or satellite service provider, then the SAO function may determine the candidate satellite(s) and / or satellite service provider based on other information, such as matching the location and / or schedule of UE and satellites.CNV15053W001 / 101859.002174

[0072] UE (group) information: The requestor may provide information of the UE or group(s) of UEs which may need satellite access, such as the identifier, schedule, traffic pattern, current or expected location(s), etc. The requestor may also provide information of the corresponding application / service associated with the UEs such as network KPI requirements of an application / service.

[0073] Selection criteria: The requestor may specify the selection criteria of satellites, such as number of satellites, QoS requirements, capacity requirements, availability requirements, coverage requirements, etc. If the request is for a group of UEs. then the requestor may specify whether the requirements are regarding each UE in the group or the entire group of UEs.

[0074] Performance metrics: If the requestor requests the SAG function to provide satellite performance analytics and / or a ranked / recommended list of satellites, the requestor may specify the corresponding performance or ranking / recommendation metrics, such as coverage, satellite load, communication latency, etc. If the request is for a group of UEs, then the requestor may specify whether the metrics are regarding each UE in the group or the entire group of UEs.

[0075] Analytics parameters: The requestor may specify analytics requirements and related information such as the required analytics period, analytics area (area of interest), required level of confidence, etc. The requestor may send an updated request with updated analytics parameters if the UE and / or satellite information has changed. The requestor may also specify adaptive analytics parameters such that the SAG function may determine the exact values for the parameters. For example, the requestor may specify the analytics period for satellite performance analytics to be the time period when the satellite is accessible to a certain UE.

[0076] Notification requirements: The requestor may specify the conditions of when a notification should be generated / sent, the notification target, and what information should be included in the notification. Particularly, the requestor may request the SAG function to dynamically adjust the condition or schedule of sending notification according to the analytics results. For example, depending on whether the selected satellite is a GEO satellite or NGSO satellite, the SAG function may apply different notification intervals (e.g. longer notification interval for GEO satellite, shorter notification interval for MEO satellite, even shorter notification interval for LEO satellite).CNV15053W001 / 101859.002174

[0077] At step 2, the SAO function may obtain satellite information from the satellite sen-ice provider(s). If the request in step 1 had specified satellite service provider(s), the SAO function may request information from the specified satellite service provider(s). If the request in step 1 had specified one or more satellites as candidates, the SAO function may request information of the candidate satellites from the corresponding satellite service provider(s). Alternatively, the SAO function may identify candidate satellites and / or satellite sen-ice provider and request their information. The satellite information obtained by the SAO function may include satellite ephemeris, satellite capacity, satellite schedule, feeder hnk information, inter-satellite communication information, gaps in satellite coverage (e.g., certain times or locations), and other information as shown in Table 1.

[0078] At step 3, the SAO function may make a subscription or request to the terrestrial core network (and other services / functions in the cellular or terrestrial system) to obtain information of the UE(s) specified in the satellite access analytics request, such as UE location information, UE mobility analytics (e.g. predicted UE location), etc. The SAO function may also request for information of the network.

[0079] At step 4, based on the satellite access analytics request and information collected in the previous steps and the selection criteria in the satellite access analytics request, the SAO function may make an initial selection of satellites. For example, the selection may be based on whether the satellite’s capacity can meet the requirement of the UE, whether the UE will be in the coverage of the satellite for at least a pre-defined period of time, etc.

[0080] The SAO function may select a list of satellites that may jointly provide access to one or more UEs. For example,

[0081] A UE at a fixed location may require consistent satellite access throughout the day while each satellite may only be accessible for a limited period of time. The SAO function may then select a list of satellites such that the satellites may jointly provide full coverage to the UE. The SAO function may alternatively select satellites for certain periods of time or locations and terrestrial networks for others.

[0082] A group of UEs may be reporting data to a VAL server (on ground) via satellite access. A satellite may be selected to provide access to the group of UEs while the feeder link of the satellite may not be always available. The SAO function may select satellites with storage function such that the data can be temporarily stored at the satellite when the feeder link is unavailable and transmitted to the VAL server when the feeder hnk becomesCNV15053W001 / 101859.002174 available. Alternatively, the SAO function may select additional satellites with inter-satellite communication capability to relay the data. The SAO function may provide such instructions / recommendations on the storing and relaying of data, which may be indicated as the '‘Transmission pattern’’ in the analytics results (as shown in Table 2).

[0083] A group of UEs located in different geographical regions may utilize UE- satellite-UE connections to enable communication among UEs in the group. The SAO function may select one or more satellites to provide access for UEs in each region and may select additional satellites (as relay) to support inter-satellite communications if the satellites associated with the different regions are not able to directly communicate with each other. The SAO function may provide such instructions / recommendations as the “Transmission pattern” in the analytics results (as shown in Table 2).

[0084] At steps 5a. 5b. 5c, after the initial selection, the SAO function may continue to collect more information from the network and the satellite service provider(s) to obtain detailed or updated information of UEs and the selected satellites, which may be used to update or trim dow n the list of satellites selected in step 4. The information may be collected by the SAO server and / or the SAO client, and shared between them. The SAO function may receive updated UE information (as notifications) as a result of the subscription request in step 3. The SAO function may request dynamic or updated information of the satellites from the satellite sendee providers and / or the netw ork, such as the (updated) ephemeris information and current load of the satellite, feeder link status of the satellite, inter-satellite communication quality between the satellite and the other satellites, etc. The SAO function may also collect information from the UE directly when the UE is using either terrestrial access or satellite access. For example, the SAO server may collect information from the UE by interacting wdth the corresponding SAO client on the UE, where the SAO client may further interact with the application client and / or other enabler client on the UE, such as the SEAL client (e.g. to obtain location information) or the edge enabler client.

[0085] At step 6, based on the collected information, the SAO function may generate required analytics results of the satellite(s), such as predicted satellite load, predicted availability, predicted satellite access performance, and other analytics outputs as shown in Table 2 and / or Table 1. The SAO function may then update the selection of the satellites and / or make recommendations based on the selection criteria and performance metrics specified in the satellite access analytics request. For example,CNV15053W001 / 101859.002174

[0086] If the request is to select one optimal satellite with the highest coverage regarding a single UE, the SAO function may calculate statistics of the coverage information and / or predict the coverage of each satellite in the selected list (from step 4) and recommend the one with the highest coverage.

[0087] If the request is to rank the satellites in a given list based on their performance or available KPIs, the SAO function may generate statistics and predictions of the satellites’ loads, communication latency, and other information to evaluate or predict performance of the satellites according to the performance metrics specified in the satellite access analytics request. The SAO function may then rank the satellites based on their (predicted) performance or available KPIs.

[0088] If the request is to suggest an access pattern from a group of UEs to the selected satellites to optimize the group-wide performance, the SAO function may monitor and / or predict the traffic patterns of the UEs and the availability information of the satellites, and determine the optimal access schedule / pattem for each UE in the group, such as staggering the satellite access from different UEs, prioritizing bulky data transmission, postponing a data transmission, determining how many UEs to steer to using satellite access (while the rest using terrestrial access), etc. The SAO function may provide such instructions / recommendations as the “Access pattern” in the analytics results (as shown in Table 2).

[0089] If the request is to determine when to switch between satellite and terrestrial access, the SAO function may monitor and / or predict the communication latency for each access method at future time instances. The communication latency for satellite access may be estimated when taking into consideration feeder link avail ability and status, inter-satellite communication availability7and latency, etc. If the predicted latency at a time instance is acceptable according to the requirements specified in the satellite access analytics request, then the SAO function may suggest satellite access for the corresponding time period. Otherwise, the SAO function may suggest terrestrial access for that time period. The SAO function may provide such instructions / recommendations as the “UE access schedule” in the analytics results (as shown in Table 2).

[0090] At step 7. the SAO function may send a notification to the requestor or the designated notification target according to the notification requirements specified in the request. The notification may include the generated analytics result and / or the selection / recommendations. According to the notification requirements, when to send theCNV15053W001 / 101859.002174 notification may be determined based on the analytics information generat ed / obtained by the SAO function. For example,

[0091] A notification may be sent during the UE's initial configuration or provisioning process and then an updated notification may be sent whenever the UE is predicted to have terrestrial access.

[0092] The SAO function may be requested to send a notification including information of the next selected satellite before the predicted time when the current satellite becomes unavailable or moves out of coverage.

[0093] The requestor may send updated application / service information to the SAO function after receiving the notification (not shown in the figure).

[0094] At step 8, the SAO function may also send a notification to the satellite service provider(s) with the generated analytics result (e.g. statistics and / or predictions of satellite performance, UE connection density, traffic / access patterns). The notification may be sent based on a subscription request made by the satellite service provider (not shown in the figure).

[0095] At step 9, the UE(s) may be informed with the selection of satellites and / or the corresponding access patterns. The UE may be informed by the requestor after the requestor receives the notification from the SAO function. Alternatively, the UE may be informed directly by the SAO function. For example, the UE may be informed via the SAO client or other enabler client (e.g. SEAL client) on the UE.

[0096] At step 10, after the UE accesses the satellite or due to other dynamics of the UE and / or the network (e.g.. UE’s current or expected location changes), the UE information may be updated. As a result, the core network may send the updated UE information (as notification) to the SAO function. Based on the updated UE information, the SAO function may determine to update the analytics results and the selection / recommendation of satellites. Steps 4 to 10 may be repeated.

[0097] Satellite access analytics for the satellite service provider are described herein. The SAO function (as a SAO server, a SAO client, or both) may receive a request (e.g. from satellite service provider) to optimize the performance of a given set of satellites (e.g. a constellation of satellites) for UEs or areas that the satellites pass by, including adjusting the transmission pattern of satellites, coordinating the satellites, load balancing on satellites, determining the deployment / activation of applications / services on satellites, etc. In thisCNV15053W001 / 101859.002174 procedure, the S AO function may assist the exposure of UE / V AL information to satellite sen-ice providers.

[0098] FIG. 4 shows an example procedure 400 in which an SAO function may assist the exposure of UE / V AL information to satellite service providers. Note that in the case the SAO function is implemented as part of a SEAL or other AEL server, the satellite sendee provider may be a VAL server. Note that the steps may be performed in an order different than shown in the figure. Although not shown in the figure, each request message may be followed by a response message indicating the request is accepted / dechned and / or an acknowledgement.

[0099] At step 1, the requestor (e.g. satellite service provider) may send a satellite access analytics request to the SAO function, requesting the SAO function to provide analytics information on the satellite accesses and recommendations on how to schedule and coordinate satellites to optimize their performance. The request may specify what information is required to be generated by the SAO function, such as satellite performance analytics, estimated satellite access patterns (from UEs), predicted / recommended transmission patterns of satellites, etc. The request may include the following information as well as other information in Table 1.

[0100] Satellite information: The requestor may specify a list of satellites as the analytics targets, i.e. the SAO function is requested to generate analytics information regarding these satellites. The requestor may provide information of the satellites such as their ephemeris, availability, (initial) schedule, capacity, EDN support, supported applications / services, etc.

[0101] UE (group) information: If the satellites are providing access to specific UEs or specific groups of UEs. types of UEs, or specific service areas, the requestor may include information of the UEs or groups, or service areas in the request, such as UE identifier and / or group identifier and / or service areas.

[0102] Performance metrics: The requestor may specify the performance metrics if it is requesting the SAO function to generate analytics information on the performance of the satellites. For example, the performance of a satellite may be indicated by its load, communication qualify, latency, feeder link status, inter-satellite communication qualify / latency, coverage regarding a specific area or a specific group of UEs, etc.

[0103] Analytics parameters: The requestor may specify analytics requirements and related information such as the required analytics period, analytics area (area of interest), statistics and / or predictions, recommendations, required level of confidence, etc.CNV15053W001 / 101859.002174

[0104] Notification requirements: The requestor may specify the conditions of when a notification should be generated / sent, the notification target, and what information should be included in the notification. Particularly, the requestor may request the SAO function to dynamically adjust the condition or schedule of sending notification according to the analytics results.

[0105] At step 2, based on the information received in step 1, the SAO function may determine the service area of the satellites. The service area of a satellite may be determined based on the satellite information provided by the requestor, such as its ephemeris, availability, schedule, etc. The service area of a satellite may not be a static geographical area. The determination may also be based on terrestrial network coverage information such as where there is no radio coverage, where terrestrial service is not available, etc. Terrestrial network coverage information may be pre-provisioned to the SAO function or obtained from the cellular or terrestrial system.

[0106] At step 3, the SAO function may make a subscription or request to the terrestrial core network (and other services / functions in the cellular or terrestrial system) to obtain UE information in the service area of the satellites, such as number of UEs, UE density, UE distribution, applications / services used by the UEs, QoS requirements of the UEs and applications, etc. Since the service area of a satellite may change over time, the SAO function may constantly update the subscription or request (e.g. by updating the area of interest) to obtain UE information in the updated service area. If the requestor has specified UEs or UE groups to which the satellites are providing access, the SAO function may request information of the specified UEs.

[0107] At step 4, the SAO function may receive UE information as a response to the request of step 3. In addition, the SAO function may receive UE information directly from the UE via the corresponding SAO client.

[0108] At step 5, based on the satellite access analytics request and the collected information, the SAO function may generate analytics results for the satellites, such as statistics and / or predicted satellite load, statistics and / or predicted satellite performance, and other analytics output as shown in Table 2. The SAO function may further determine the recommendations on how to schedule and coordinate the satellites, such as whether traffic offloading is needed, which satellites should be cooperating with each other, which satellite’s feeder link should be used, etc. The SAO function may provide suchCNV15053W001 / 101859.002174 instructions / recommendations as the “Transmission pattern” in the analytics results (as shown in Table 2). For example,

[0109] A satellite with limited storage and intermittent feeder link availability may be receiving data from UEs in the areas of the satellite’s orbit. The data will be stored at the satellite when the feeder link is not available and transmitted when the feeder link becomes available. The SAO function may predict whether the storage limit will be reached before the feeder link becomes available, based on analytics information such as the predicted number of UEs that will be uploading data to the satellite, the amount of data to be uploaded, the estimated time when the feeder link will become available, etc. If the storage limit is predicted to be exceeded, the SAO function may suggest transferring part of the stored data to another satellite in the same constellation via inter-satellite communication.

[0110] The SAO function may generate statistics of the load and performance of a satellite, which may indicate whether the satellite is overloaded and trigger operations such as offloading to other satellites, load balancing among the constellation, adjusting resource allocation, etc.

[0111] Load balancing: Several satellites in a constellation may provide access to UEs in a certain area in sequence during their orbit. If the feeder link of the satellite currently serving the area is predicted to be overloaded (which may be indicated by statistics of the feeder link status or increased latency), the satellite may cooperate with the preceding or succeeding satellites by offloading part of the data traffic to the other satellites and using their feeder links instead of using its own feeder link (e.g. transferring high priority or delay-sensitive traffic via its own feeder link while forwarding low priority or delay -insensitive traffic to the cooperating satellites). If the traffic of the area is predicted to be increasing, the SAO function may suggest the satellite which is currently serving the area to offload traffic to the preceding satellite that is leaving the area. If the traffic is predicted to decrease, the SAO function may suggest the cooperation to be performed with the succeeding satellite that is going to enter the area.

[0112] The SAO function may suggest satellites with EDN support to instantiate EASs on the satellites if the traffic of a specific application is predicted to be increased and / or the feeder link status is predicted to be unavailable.

[0113] The SAO function may provide recommendations on a sequence of satellites to provide coverage throughout the day for a certain area and / or a certain group of (stationary)CNV15053W001 / 101859.002174UEs. The SAO function may schedule the service time for each satellite in the sequence so that they may jointly provide full coverage.

[0114] At step 6, the SAO function may send a notification to the requestor or the designated notification target according to the notification requirements specified in the request. The notification may include the generated analytics results and / or recommendations.

[0115] At step 7, the satellite service provider may update service deployment based on the analytics results and recommendations received from the SAO function, which may result in updated satellite information, such as updated schedule, availability, capabilities. The satellite service provider may send the updated satellite information and / or an updated satellite access analytics request to the SAO function. In addition, the satellite service provider may use the analytics results obtained from the SAO function to configure UEs with satellite connectivity to ensure seamless connectivity between terrestrial and satellite access nodes.

[0116] At step 8, the SAO function may update the satellite service area based on the updated information.

[0117] At step 9, the SAO function may update the subscription with the core network and / or send an updated request with the updated service area to obtain UE information in the updated service area. Steps 4 to 9 may be repeated.

[0118] Distributed satellite access analytics are described herein. Satellite access related information may be collected and processed locally at the UE by the SAO client to generate analytics results, which may reduce the delay caused by exchanging information with the SAO server and / or the core network, especially when the UE is using intermittent satellite access. Multiple UEs may cooperate with each other to optimize their satellite accesses, if they are located in the same area or are accessing the same (set of) satellites.

[0119] FIG. 5 shows an example procedure 500 where distributed satellite access analytics is performed at one or more UEs locally, optionally in a collaborative manner. Note that the steps may be performed in an order different than shown in the figure. Although not shown in the figure, each request message may be follow ed by a response message indicating the request is accepted / declined and / or an acknowledgement.

[0120] At steps la, lb, 1c, the SAO client may receive a satellite access analytics request from an application client (VAL client) on the UE or the SAO client from another UE. If the SAO client is not able to generate the required analytics results, it may forward the request to the SAO server (then the procedure in FIG. 3 may follow) or forw ard the request to the SAOCNV15053W001 / 101859.002174 client of another UE. Alternatively, the SAO client may receive a satellite access analytics request from the SAO server. For example, after the SAO server receives a satellite access analytics request (step 1 of FIG. 3), the SAO server may determine to redirect the request to the SAO client if the SAO client is capable of generating the required analytics results and the SAO server does not have consistent connection with the SAO client. The request may include information as described in step 1 of FIG. 3 and Table 1.

[0121] At step 2, if the SAO client accepts the satellite access analytics request received in step 1, then the SAO client may send a response or notification to the SAO server indicating the acceptance of the request. The SAO client may also request satellite information, network information and other information (as shown in Table 1) from the SAO server and / or other entities in the core netw ork or the enabler layer. The SAO client may also request updated information from the SAO server and / or other entities in the later steps.

[0122] At step 3a, 3b, the SAO client may collect information of the UE and the satellite access locally (e.g. from the VAL client), which may include location / mobility information of the UE, traffic patterns of one or more applications on the UE, measurements of the satellite access performance, and other information as described in Table 1.

[0123] At step 4, to enable the cooperation / coordination among UEs located in the same area or accessing the same (set of) satellites, the SAO clients may share the collected information with each other, such as (expected) UE location, selection of satellite(s), application schedule, traffic pattern, etc. The information may be shared by sending a request and / or making a subscription to the SAO client of another UE for the required information. The shared information may be used by the SAO clients to generate collective UE information (as described in Table 1) and / or analytics results according to the satellite access analytics request. The SAO client may also report the collected and / or shared information to the SAO server (similar to step 5-c of FIG. 3).

[0124] At step 5, the SAO client may generate required analytics results based on the information received in previous steps (similar to step 6 of FIG. 3). The analytics results may be generated in one of the following methods or a combination of them.

[0125] The SAO client may receive information of other UEs from the corresponding SAO clients and generate analytics results locally. For example, the SAO client may suggest the application client to schedule the application traffic so that it may avoid burstyCNV15053W001 / 101859.002174 periods from other UEs that are accessing the same satellite, or choose to connect to a different satellite if available.

[0126] The SAO client may cooperate with one or more other SAO clients to generate analytics results jointly. The SAO client may contribute to a portion of the analytics results (e.g. using distributed computing / leaming, federated learning), or generate and send intermediate results to other SAO clients which may continue to generate fmal / complete results (e.g. using split computing, model splitting).

[0127] The SAO client may cooperate with the SAO server to generate analytics results jointly. The SAO client may contribute to a portion of the analytics results, or generate and send intermediate results to the SAO server which may continue to generate final / complete results.

[0128] At step 6, the generated analytics results (including partial result, intermediate result, and / or final result) may be shared among the SAO clients of multiple UEs and / or sent to the SAO client which requests the results.

[0129] At Step 7a, 7b: Based on the received analytics results, the SAO client may determine the selection of satellites and / or the access pattern.

[0130] At step 8a, 8b, 8c, the SAO client may send a notification to the VAL client, other SAO client(s), or the SAO server about the generated analytics results and the determined satellite access information.

[0131] Steps 3 to 8 may be repeated to update the analytics results based on realtime information. Note that step 8-c may be performed at a much lower frequency as compared to the other steps and the notification message may be more latency -tolerant. Steps 3 to 7 may be performed locally at the UEs with UE-to-UE communication (direct communication or UE- satellite-UE communication). Therefore the distributed analytics procedure is less prone to the impact of intermittent satellite and / or feeder link availability.

[0132] In one embodiment (e.g., a RESTful embodiment), AEL servers and / or clients may implement SAO function related information elements (such as but not limited to those defined in the aforementioned tables) as one or more RESTful resources. The RESTful resources may have unique addresses (e.g. URIs, URNs, etc.) and may also have one or more attributes that comprise resource data and / or metadata. These resources may be created, retrieved, discovered, updated, or deleted by VAL clients and servers, as well as by other entities in the system such as but not limited to those shown in the aforementioned figures.CNV15053W001 / 101859.002174SAO function-enhanced AEL servers and clients may support RESTful APIs based on these resources. Via these APIs the satellite access analytics operations defined in this invention may be initiated. In addition, the APIs may also be used to initiate the satellite access optimization procedures defined in this invention. These APIs may be based on RESTful protocols such as HTTP and CoAP.

[0133] In another embodiment (e.g., a Pub / Sub embodiment), SAO function- enhanced AEL serv ers and / or clients may implement satellite access analytics related information elements (such as but not limited to those defined in aforementioned tables) as one or more topics within a topic space of a message broker (e g., MQTT broker, AMQP broker, etc.). A SAO function-enhanced AEL server and / or client may function as the message broker. Alternatively, the message broker may be hosted external to SAO function-enhanced AEL server and / or client. For example, by another entity in the system which the SAO function- enhanced AEL server or client may communicate with. A SAO function-enhanced AEL server and / or client may send and / or receive publish and / or subscribe requests to topics within a message broker. The topics may have unique addresses (e.g. topic names, etc.) and one or more attributes that contain topic data and / or metadata.

[0134] These satellite access analytics topics may be created, retrieved, discovered, updated, or deleted by VAL clients and servers, as well as by other entities in the system such as but not limited to those shown in the aforementioned figures. SAO function-enhanced AEL servers and clients may support APIs based on these topics. Via these APIs the satellite access analytics operations defined in this invention may be initiated. In addition, the APIs may also be used to initiate the satellite access optimization procedures defined in this invention. These APIs may be based on Pub / Sub protocols such as MQTT and AMQP.

[0135] FIG. 6 show s an example of a graphical user interface (GUI) 600 for the satellite access optimization function. A requestor may specify the analytics area, analytics period, and requirements for the SAO function, and view the analytics results, such as the selection and recommendation of satellites, suggested access patterns, predicted satellite performance, etc.

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

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

[0138] FIG. 7A illustrates an example communications system 700 in which the systems, methods, and apparatuses described and claimed herein may be used. The communications system 700 may comprise wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which generally or collectively may be referred toCNV15053W001 / 101859.002174 as WTRU 102 or WTRUs 102. The communications system 700 may comprise, a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108. the Internet 110. other networks 112, and Network Services 113. 113. Network Services 113 may comprise, for example, a V2X server, V2X functions, a ProSe server, ProSe functions, loT services, video streaming, federated learning (FL) services, and / or edge computing, etc.

[0139] It may be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In the example of FIG. 7A, each of the WTRUs 102a-d is depicted in FIGs. 7A-7E as a hand-held wireless communications apparatus. It is understood that with the wide variety of use cases contemplated for wireless communications, each WTRU may comprise or be comprised in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, bus or truck, a train, or an airplane, and the like.

[0140] The communications system 700 may also comprise a base station 114a and a base station 114b. In the example of FIG. 7A. each base stations 114a and 114b is depicted as a single element. In practice, the base stations 114a and 114b may comprise any number of interconnected base stations and / or network elements. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 1 10, Network Services 113, and / orthe other networks 112. Similarly, base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the Remote Radio Heads (RRHs) 118a, 118b, Transmission and Reception Points (TRPs) 119a, 119b, and / or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109. the Internet 110. othernetworks 112, and / or Network Services 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102, e.g., WTRU 102c, toCNV15053W001 / 101859.002174 facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, Network Sendees 113, and / or other networks 112.

[0141] TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, Network Services 113, and / or other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or Network Services 113. By way of example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.

[0142] The base station 114a may be part of the RAN 103 / 104 / 105, which may also comprise other base stations and / or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base station 114b may be part of the RAN 103b / 104b / 105b, which may also comprise other base stations and / or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base station 114a may be configured to transmit and / or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit and / or receive wired and / or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, for example, the base station 114a may comprise three transceivers, e g., one for each sector of the cell. The base station 114a may employ Multiple-Input Multiple Output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell, for instance.

[0143] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light. cmWave. mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable Radio Access Technology (RAT).CNV15053W001 / 101859.002174

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

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

[0146] The WTRUs 102 may communicate with one another over a direct air interface 115d / l 16d / l 17d, such as Sidelink communication which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.) The air interface 115d / l 16d / l 17d may be established using any suitable RAT.

[0147] The communications system 700 may be a multiple access system and mayemploy one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC- FDMA, and the like. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, and 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 and / or 115c / l 16c / 117c respectively using Wideband CDMA (WCDMA). WCDMA may comprise communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may comprise High-Speed Downlink Packet Access (HSDPA) and / or High- Speed Uplink Packet Access (HSUPA).

[0148] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, and 102g, or RRHs 118a and 118b, TRPs 119a and 119b, and / or RSUs 120a and 120b in the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115 / 116 / 117 or 115c / l 16c / l 17c respectively using Long Term Evolution (LTE) and / or LTE- Advanced (LTE- A), for example. The air interface 115 / 1 16 / 117 or 115c / l 16c / l 17c may implement 3GPP NR technology7. The LTE and LTE-A technology mayCNV15053W001 / 101859.002174 comprise LTE D2D and / or V2X technologies and interfaces (such as Sidelink communications, etc.) Similarly, the 3GPP NR technology may comprise NR V2X technologies and interfaces (such as Sidelink communications, etc.)

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

[0150] The base station 114c in FIG. 7A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a train, an aerial, a satellite, a manufactory, a campus, and the like. The base station 114c and the WTRUs 102, e.g., WTRU 102e, may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRUs 102, e.g., WTRU 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRUs 102, e.g., WRTU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE. LTE- A, NR. etc.) to establish a picocell or femtocell. As shown in FIG. 7A. the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106 / 107 / 109.

[0151] The RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may be in communication with the core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, and / or Voice Over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing sendees, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity. Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.CNV15053W001 / 101859.002174

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

[0153] The core network 106 / 107 / 109 may also serve as a gatew ay for the WTRUs 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may comprise circuit-switched telephone networks that provide Plain Old Telephone Service (POTS). The Internet 110 may comprise a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and the internet protocol (IP) in the TCP / IP internet protocol suite. The other networks 112 may comprise wired or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may comprise any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

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

[0155] Although not shown in FIG. 7A, it may be appreciated that a User Equipment may make a wired connection to a gateway. The gateway maybe a Residential Gateway (RG). The RG may provide connectivity to a Core Network 106 / 107 / 109. It may be appreciated that many of the ideas contained herein may equally apply to UEs that are WTRUs and UEs that use a wired connection to connect to anetw ork. For example, the ideas that apply to the wireless interfaces 115, 116, 117 and 1 15c / 116c / 117c may equally apply to a wired connection.CNV15053W001 / 101859.002174

[0156] FIG. 7B is a system diagram of an example RAN 103 and core network 106. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a. 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 7B, the RAN 103 may comprise Node-Bs 140a, 140b, and 140c, which may each comprise one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node- Bs 140a, 140b. and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also comprise RNCs 142a. 142b. It may be appreciated that the RAN 103 may comprise any number of Node-Bs and Radio Network Controllers (RNCs.)

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

[0158] The core network 106 shown in FIG. 7B may comprise a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it may be appreciated that any one of these elements may be owned and / or operated by an entity other than the core netw ork operator.

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

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

[0161] The core network 106 may also be connected to the other networks 112, which may comprise other wired or wireless networks that are ow ned and / or operated by other service providers.

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

[0163] The RAN 104 may comprise eNode-Bs 160a, 160b, and 160c, though it may be appreciated that the RAN 104 may comprise any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each comprise one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

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

[0165] The core network 107 shown in FIG. 7C may comprise a Mobility Management Gateway (MME) 162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it may be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

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

[0170] FIG. 7D is a system diagram of an example RAN 105 and core network 109. The RAN 105 may employ an NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may employ a non-3GPP radio technology7to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core netw ork 109.

[0171] The RAN 105 may comprise gNode-Bs 180a and 180b. It may be appreciated that the RAN 105 may comprise any number of gNode-Bs. The gNode-Bs 180a and 180b may each comprise one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When integrated access and backhaul connection are used, the sameCNV15053W001 / 101859.002174 air interface may be used between the WTRUs and gNode-Bs, which may be the core network 109 via one or multiple gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU- MIMO, and / or digital beamforming technology. Thus, the gNode-B 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It should be appreciated that the RAN 105 may employ of other types of base stations such as an eNode-B. It may also be appreciated the RAN 105 may employ more than one type of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.

[0172] The N3IWF 199 may comprise a non-3GPP Access Point 180c. It may be appreciated that the N3IWF 199 may comprise any number of non-3GPP Access Points. The non-3GPP Access Point 180c may comprise one or more transceivers for communicating with the WTRUs 102c over the air interface 198. The non-3GPP Access Point 180c may use the 802. 11 protocol to communicate with the WTRU 102c over the air interface 198.

[0173] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and / or downlink, and the like. As shown in FIG. 7D, the gNode-Bs 180a and 180b may communicate with one another over an Xn interface, for example.

[0174] The core netw ork 109 shown in FIG. 7D may be a 5G core network (5GC). The core network 109 may offer numerous communication services to customers who are interconnected by the radio access network. The core network 109 comprises a number of entities that perform the functionality’ of the core network. As used herein, the term “core network entity” or “network function” refers to any entity that performs one or more functionalities of a core netw ork. It is understood that such core network entities may be logical entities that are implemented in the form of computer-executable instructions (softw are) stored in a memory of, and executing on a processor of, an apparatus configured for wireless and / or network communications or a computer system, such as system 90 illustrated in FIG. 7G.

[0175] In the example of FIG. 7D, the 5G Core Network 109 may comprise an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPFs) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, a User Data Repository (UDR) 178. While each of the foregoing elements are depicted as partCNV15053W001 / 101859.002174 of the 5G core network 109, it may be appreciated that any one of these elements may be owned and / or operated by an entity other than the core network operator. It may also be appreciated that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. FIG. 7D shows that network functions directly connect to one another, however, it should be appreciated that they may communicate via routing agents such as a diameter routing agent or message buses.

[0176] In the example of FIG. 7D. connectivity between network functions is achieved via a set of interfaces, or reference points. It may be appreciated that network functions may be modeled, described, or implemented as a set of services that are invoked, or called, by other network functions or services. Invocation of a Netw ork Function service may be achieved via a direct connection betw een network functions, an exchange of messaging on a message bus. calling a software function, etc.

[0177] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive the user plane tunnel configuration information from the SMF via an Ni l interface. The AMF 172 may generally route and forward NAS packets to / from the WTRUs 102a, 102b, and 102c via an N1 interface. The N 1 interface is not shown in FIG. 7D.

[0178] The SMF 174 may be connected to the AMF 172 via an Ni l interface. Similarly the SMF may be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for Session Management. IP address allocation for the WTRUs 102a. 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.

[0179] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a. 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b. and 102c with access to other types of packet data networks. For example, Other Networks 112 may be Ethernet Netw orks or any ty pe of network that exchanges packets of data. The UPF 176a and UPF 176b may receiveCNV15053W001 / 101859.002174 traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting a packet data network with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In addition to providing access to packet data networks, the UPF 176 may be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.

[0180] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates a connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same, or similar, manner that it interacts with the RAN 105.

[0181] The PCF 184 may be connected to the SMF 174 via an N7 interface, connected to the AMF 172 via an N1 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 7D. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. The PCF 184, may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via an N1 interface. Policies may then be enforced, or applied, at the WTRUs 102a, 102b, and 102c.

[0182] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may connect to network functions, so that network function may add to, read from, and modify the data that is in the repository. For example, the UDR 178 may connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196 via an N37 interface, and the UDR 178 may connect to the UDM 197 via an N35 interface.

[0183] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access of the UDR 178. For example, the UDM 197 may connect to the AMF 172 via an N8 interface, the UDM 197 may connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13 interface. The UDR 178 and UDM 197 may be tightly integrated.

[0184] The AUSF 190 performs authentication related operations and connects to the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.CNV15053W001 / 101859.002174

[0185] The NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AF) 188. Exposure may occur on the N33 API interface. The NEF may connect to an AF 188 via an N33 interface and it may connect to other network functions in order to expose the capabilities and sendees of the 5G core network 109.

[0186] Application Functions 188 may interact with network functions in the 5G Core Network 109. Interaction between the Application Functions 188 and network functions may be via a direct interface or may occur via the NEF 196. The Application Functions 188 may be considered part of the 5G Core Network 109 or may be external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.

[0187] Network Slicing is a mechanism that may be used by mobile network operators to support one or more ‘virtual’ core networks behind the operator’s air interface. This involves ‘slicing’ the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g., in the areas of functionality, performance and isolation.

[0188] 3GPP has designed the 5G core network to support Network Slicing. Network Slicing is a good tool that network operators may use to support the diverse set of 5G use cases (e.g., massive loT, critical communications. V2X, and enhanced mobile broadband) which demand very diverse and sometimes extreme requirements. Without the use of network slicing techniques, it is likely that the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, introduction of new network services should be made more efficient.

[0189] Referring again to FIG. 7D, in a network slicing scenario, a WTRU 102a, 102b, or 102c may connect to an AMF 172, via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU 102a, 102b, or 102c with one or more UPF 176a and l76b, SMF 174, and othernetwork functions. Each of the UPFs 176a and 176b, SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may beCNV15053W001 / 101859.002174 isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

[0190] The core network 109 may facilitate communications with other networks. For example, the core network 109 may comprise, or may communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and a PSTN 108. For example, the core network 109 may comprise, or communicate with a short message service (SMS) service center that facilities communication via the short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and servers or applications functions 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may comprise other wired or wireless networks that are owned and / or operated by other service providers.

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

[0192] FIG. 7E illustrates an example communications system 111 in which the systems, methods, apparatuses described herein may be used. Communications system 111 may comprise Wireless Transmit / Receive Units (WTRUs) A, B, C, D, E, F, abase station gNB 121, a V2X server 124, and Road Side Units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base station gNBs, V2X networks, and / or other network elements. One or several or all WTRUs A, B, C, D, E, and F may be out of range of the access network coverage 131. WTRUs A, B, and C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members.

[0193] WTRUs A, B. C, D, E, and F may communicate with each other over a Uu interface 129 via the gNB 121 if they are within the access network coverage 131. In the example of FIG. 7E, WTRUs B and F are shown within access network coverage 131. WTRUsCNV15053W001 / 101859.002174A, B, C, D, E, and F may communicate with each other directly via a Sidelink interface (e.g., PC5 or NR PC5) such as interface 125a, 125b, or 128, whether they are under the access network coverage 131 or out of the access network coverage 131. For instance, in the example of FIG. 7E, WRTU D, which is outside of the access network coverage 131, communicates with WTRU F, which is inside the coverage 131.

[0194] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via a Vehicle-to-Network (V2N) 133 or Sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to aV2X Server 124 via a Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface 128.

[0195] FIG. 7F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communications and operations in accordance with the systems, methods, and apparatuses described herein, such as a WTRU 102 of FIG. 7A, 7B, 7C, 7D, or 7E. As shown in FIG. 7F, the example WTRU 102 may comprise a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It may be appreciated that the WTRU 102 may comprise any sub-combination of the foregoing elements. Also, the base stations 114a and 114b, and / or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP). a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, a next generation node-B (gNode- B), and proxy nodes, among others, may comprise some or all of the elements depicted in FIG. 7F and described herein.

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

[0197] The transmit / receive element 122 of a UE may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a of FIG. 7A) over the air interface 115 / 116 / 117 or another UE over the air interface 115d / l 16d / l 17d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and receive both RF and light signals. It may be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

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

[0199] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may comprise multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, for example NR and IEEE 802. 11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

[0200] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / mi crophone 124, the keypad 126, and / or the display / touchpad / indicators 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126. and / or the display / touchpad / indicators 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The nonremovable memory' 130 may comprise random-access memory7(RAM), read-only memory7CNV15053W001 / 101859.002174(ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may comprise a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. The processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server that is hosted in the cloud or in an edge computing platform or in a home computer (not shown).

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

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

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

[0204] The WTRU 102 may be comprised in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane. The WTRU 102 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.CNV15053W001 / 101859.002174

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

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

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

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

[0209] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may comprise text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touchpanel. Display controller 96 comprises electronic components required to generate a video signal that is sent to display 86.

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

[0211] It is understood that any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by one or more processors, such as processors 118 or 91, cause the one or more processors to perform and / or implement the systems, methods and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor(s) of an apparatus or computing system configured for wireless and / or wired netw ork communications. Computer readable storage media comprises volatile and nonvolatile, removable and non-CNV15053W001 / 101859.002174 removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer readable storage media do not comprise signals. Computer readable storage media comprise, but are not limited to. RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.

Claims

CNV15053W001 / 101859.002174What is claimed:

1. An apparatus comprising one or more processors and memory storing instructions which, when executed by the one or more processors, cause the apparatus to: receive, from a requestor, a first request to provide analytics information for satellite access, the request comprising an identifier of one or more user equipments (UEs); send, to a service or function in a network, a second request for location information of the one or more UEs; receive, from the service or function in the network, the location information of the one or more UEs; generate, based on the first request and the location information, analytics information for satellite access; and send a notification indicating the generated analytics information.

2. The apparatus of claim 1, wherein the first request further comprises expected location information of the one or more UEs.

3. The apparatus of claim 1, wherein the sendee or function in the network comprises a network data analytics function (NWDAF).

4. The apparatus of claim 1, wherein the location information received from the service or function in the network comprises UE mobility analytics.

5. The apparatus of claim 1, wherein the analytics information for satellite access comprises an indication of the predicted satellite access type of the one or more UEs at a specific location / area.

6. The apparatus of claim 1, wherein the analytics information for satellite access comprises an indication of the predicted satellite access type of the one or more UEs at a specific time period.

7. The apparatus of claim 1, wherein the apparatus is an application data analytics enablement (ADAE) server.CNV15053W001 / 101859.0021748. A method for use in an apparatus, the method comprising: receiving, from a requestor, a first request to provide analytics information for satellite access, the request comprising an identifier of one or more user equipments (UEs); sending, to a service or function in a network, a second request for location information of the one or more UEs; receiving, from the service or function in the network, the location information of the one or more UEs; generating, based on the first request and the location information, analytics information for satellite access; and send a notification indicating the generated analytics information.

9. The method of claim 8, wherein the first request further comprises expected location information of the one or more UEs.

10. The method of claim 8, wherein the service or function in the network comprises a network data analytics function (NWDAF).

11. The method of claim 8, wherein the location information received from the service or function in the network comprises UE mobility analytics.

12. The method of claim 8, wherein the analytics information for satellite access comprises an indication of the predicted satellite access type of the one or more UEs at a specific location / area.

13. The method of claim 8, wherein the analytics information for satellite access comprises an indication of the predicted satellite access type of the one or more UEs at a specific time period.

14. The method of claim 8, wherein the apparatus is an application data analytics enablement (ADAE) server.CNV15053W001 / 101859.00217415. An apparatus comprising one or more processors and memory' storing instructions which, when executed by the one or more processors, cause the apparatus to: receive, from a server, a first request for location information of one or more user equipments (UEs), wherein the first request is based on a second request to provide analytics information for satellite access and comprising an identifier for the one or more UEs; and send, to the server, the location information of the one or more UEs to cause: generation, based on the second request and the location information, analytics information for satellite access, and sending of a notification indicating the generated analytics information.

16. The apparatus of claim 15. wherein the second request further comprises expected location information of the one or more UEs.

17. The apparatus of claim 15, wherein the apparatus comprises a network data analytics function (NWDAF).

18. The apparatus of claim 15, wherein the location information comprises UE mobility analytics.

19. The apparatus of claim 15, wherein the analytics information for satellite access comprises an indication of the predicted satellite access type of the one or more UEs at a specific location / area.

20. The apparatus of claim 15, wherein the analytics information for satellite access comprises an indication of the predicted satellite access type of the one or more UEs at a specific time period.

Images