Data analysis at service enabled layer

Abstract

Various methods, apparatuses, and systems are provided herein for providing service enabled layer analysis services in a cellular network, such as at a 3GPP service enabler layer. For example, a device may receive a service enabled layer data analysis request from an analytic service consumer, where the request includes requirements for an analytic service, determine to collect data from a service layer server and / or a service layer client based on the service enabled layer analysis request, and transmit the data to the analytic service consumer. And generating an analysis result based on the received server side data, the received client side data and the requirements of the analysis service, sending the analysis result to an analysis service consumer, and performing an action or triggering an action to be performed based on the analysis result.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to U.S. Provisional Application No. 63,324,482, filed on March 28, 2022, entitled “Data Analytics at Service Enablement Layer,” and is incorporated herein by reference. Background Art

[0003] In the 5G Core (5GC), data analytics services are provided to support network and management data analytics. Currently, data analytics services layered on top of the 5GC that support different vertical scenarios have not been defined. Further data analytics services are required to support end-to-end services for application-specific layers to collect data and generate analytics related to the vertical application layer and service enabler layer.

[0004] In addition, the service enabler layer itself may also require data analysis services, which can use statistics and predictions to make decisions or trigger actions to optimize enabled services or vertical applications. In particular, the data analysis services at the service enablement layer can support the collection of data and the generation of statistics and predictions related to application performance and coverage, user presence, user groups, network resource utilization, edge application servers (EAS), edge enabler servers (EES), edge data networks (EDN), network slicing, network openness, and off-network connectivity. Summary of the invention

[0005] Described herein are methods, devices and systems for providing service enabling layer analysis services in a cellular network (such as at a 3GPP service enabler layer), which methods, devices and systems address the shortcomings discussed above. For example, a device such as an ADAE server or an ADAE client can receive a service enabling layer data analysis request from an analysis service consumer, wherein the request contains a requirement for an analysis service, the ADAE server is either independent, or is the capability of a SEAL server or EES, and the ADAE client is either independent, or is the capability of a SEAL server or EEC. The device can determine to collect data from a service layer server based on the service enabling layer analysis request. The device can send a request to a determined service layer server to collect server-side service enabling layer data related to the service enabling layer analysis request. The device can receive server-side service enabling layer data related to the service enabling layer data analysis request from a determined service layer server. The device can determine to collect data from a service layer client based on a service enabling layer analysis request. The device can send a request to a determined service layer client to collect client-side service enabling layer data related to service enabling layer analysis. The apparatus may receive client-side service enablement layer data related to the service enablement layer data analysis request from the determined service layer client. The apparatus may generate an analysis result based on the received server-side data, the received client-side data, and the requirements of the analysis service. The apparatus may send a response indicating the analysis result to the analysis service consumer, and perform an action at the service enabler layer based on the analysis result.

[0006] This summary is provided to introduce some concepts in a simplified form, which will be further explained in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to features that solve any or all deficiencies mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The following detailed description will be better understood when read in conjunction with the accompanying drawings.For purposes of illustration, examples are shown in the drawings; however, the subject matter is not limited to the specific elements and instrumentalities disclosed.

[0008] In the attached figure:

[0009] Figure 1A An example of an in-network functional model for an application data analytics enabling architecture is shown;

[0010] Figure 1B An example of an off-grid functional model applying a data analytics enabled architecture is shown;

[0011] Figure 2An example of applying data analytics to enable service discovery and requests is shown;

[0012] Figure 3 An example of a data analysis request initiated by the server side is shown;

[0013] Figure 4 An example of a data analysis request initiated by the client side is shown;

[0014] Figure 5 An example of a process for enabling off-grid functionality is shown;

[0015] Figure 6 An example of a graphical user interface for requesting application data analysis enabling services and viewing analysis results is shown;

[0016] Fig. 7A An example communication system is illustrated in which the methods and apparatus described and claimed herein may be implemented.

[0017] Figure 7B is a block diagram of an example apparatus or device configured for wireless communications.

[0018] Figure 7C is a system diagram of an example radio access network (RAN) and core network.

[0019] Fig.7D is another example system diagram of the RAN and core network.

[0020] Fig. 7E is another example system diagram of the RAN and core network.

[0021] Figure 7F is a block diagram of an example computing system; and

[0022] Figure 7G is a block diagram of another example communication system. DETAILED DESCRIPTION

[0023] Methods, apparatus and systems for enabling data analysis services at the 3GPP service enabler layer are described herein, which address the shortcomings discussed above. For example, an ADAE server, either standalone or a capability of a SEAL server or EES, can receive data analysis requests, subscribe to other analysis functions in the system to obtain data and / or analysis results of interest to the ADAE server or its clients, receive input data from the vertical application layer, from the service enabler layer, from the 5GC via monitoring events, from the 5GC via interaction with the NWDAF, and / or from the OAM system, generate data analysis results, send a response to the requester, and perform actions or trigger actions to be performed based on the analysis results.

[0024] An ADAE client may be provided that is either standalone or a capability of a SEAL server or EEC. For example, an ADAE client may receive a data analysis request, receive input data from a vertical application layer, a service enabler layer, other ADAE clients, and / or a modem, initiate a data analysis request to an ADAE server, generate a data analysis result, send a response to the requestor, and perform an action at the service enabler layer based on the analysis result.

[0025] Methods and apparatus for supporting redundant transmissions in a cellular system at the application layer are described herein.

[0026] The following abbreviations may be used in this article:

[0027]

[0028]

[0029] An ADAE server, which may be either standalone or may have the capabilities of a SEAL server or EES server, may receive data analysis requests. The requester may be an application server, such as a VAL server or EAS server, an enabling server, such as a SEAL server, an EES server, or an ECS server, a vertical application client, or an enabler client. The request may be forwarded by the ADAE server through an ADAE client.

[0030] The request may include the target of the analysis report, such as UE ID, UE group ID, application server or client ID and / or enabler server or client ID, filter information, such as area of ​​interest and / or application of interest, required analysis target period, data pattern of the input data, required operation, such as average, maximum, minimum and / or comparison with threshold, required or preferred level of accuracy, preferred result order, required or preferred information granularity, notification association ID, such as for subscription, or notification endpoint address, etc.

[0031] Received requests can be further compared with existing data analysis instances. If an existing instance with the same analysis type or goal is found, the request can be merged or rejected.

[0032] The ADAE server can then subscribe to other analysis functions in the system, such as NWDAF or OAM, to obtain data and / or analysis results that the ADAE server or its clients are interested in. The ADAE server can then receive input data from the vertical application layer, from the service enabler layer, from the 5GC via monitoring events, from the 5GC via interaction with NWDAF, or from the OAM system.

[0033] The input data may be received in a notification message in response to a data collection or subscription request sent by the ADAE server, or may be received via a separate request received by the ADAE server. The input data may originate from a vertical application client and / or an enabler client and be forwarded to the ADAE server by the ADAE client.

[0034] Input data may be received from a vertical application server, client, or EAS, and it may include application server or client profiles, such as type, schedule, service area, service KPIs or requirements, performance metrics of the application server, such as server RTT, jitter, throughput, PER, server load, number of connections, etc., or performance metrics of application sessions, such as session RTT, jitter, throughput, PER.

[0035] Input data may be received from a SEAL server / client, which may include location information reports, group information such as group membership or group formation, configuration information such as VAL UE configuration data or VAL user profile, network resource information such as resource adaptation or MBMS status, network slice configuration and adaptation, etc.

[0036] Input data may be received from EES / EEC / ECS, which may include EES profile, EEC context, such as registration information, configuration or service provisioning information, ACR management events, resources or loads of edge platforms, etc. Input data is received from 5GC, which may include analysis data from NWDAF via monitoring events, analysis data from 5GC via interaction with NWDAF, and analysis data from OAM system.

[0037] The ADAE server may then generate data analysis results, which may be derived locally on the ADAE server or may be generated with the help of a third-party service. The ADAE server may then send a response to the requester, which may be sent directly to the requesting server.

[0038] The response may be sent to the notification endpoint specified in the request, or may be forwarded to the requesting client by the ADAE client. The response may include analysis results of the target application, such as predicted schedule, predicted availability based on predicted service area overlap, statistics or predictions of server performance, such as server RTT, jitter, average or peak throughput, PER, server load, number of connections, etc., and / or statistics / prediction of session performance, such as session RTT, jitter, throughput, PER, etc.

[0039] The response may include the analysis results of the target SEAL service, such as location information, group information (such as new members joining the group or changes in group size), configuration information, network resource information, statistics / predictions of network slice configuration and adaptation, etc. The response may include the analysis results of the target edge enabler layer, such as statistics or predictions of edge platform load or performance, faults, service availability, edge resource usage, service continuity planning (such as predicted target EES or EAS) or timing of ACR, etc.

[0040] The ADAE server can then take action or trigger an action to be taken based on the analysis results. The actions of the SEAL layer may include updating location report configuration, triggering location reporting, updating group configuration, creating a group, updating group members, updating UE configuration, triggering network resource adaptation / modification, triggering network slice adaptation, updating network slice configuration, etc.

[0041] The actions of the edge enabler layer may include updating service provisioning configuration, triggering EEC, EES registration, deregistration, triggering or updating service continuity planning, triggering or updating ACR, triggering dynamic EAS instantiation, etc.

[0042] An ADAE client, either standalone or part of a SEAL client or EEC, can receive a data analysis request. The requester can be an application server, such as a VAL client, an enabler server, such as a SEAL client or EEC, or another ADAE client. In the case where the request is forwarded to the ADAE client via an ADAE server, the requester can be an application server, such as a VAL server or EAS, or can be an enabler server, such as a SEAL server, EES, or ECS. The request can be forwarded to the ADAE server.

[0043] The request may include the target of the analysis report, such as UE ID, UE group ID, application server or client ID and / or enabler server or client ID, filter information, such as area of ​​interest and / or application of interest, desired analysis target period, data mode of input data, desired operation, such as average, maximum, minimum and / or comparison with threshold, desired or preferred accuracy level, desired or preferred result order, desired or preferred information granularity, notification association ID, such as for subscription, or notification endpoint address, etc. The received request may be further compared with existing data analysis instances. If an existing instance with the same analysis type or target is found, the request may be merged or rejected.

[0044] The ADAE client can then receive input data from the vertical application layer, the service enabler layer, other ADAE clients, and / or modems. The input data may include application server / client profiles, such as type, schedule, service area, service KPIs or requirements, performance indicators of application servers, such as the server's RTT, jitter, throughput, PER, server load and / or number of connections, or performance indicators of application sessions, such as the session's RTT, jitter, throughput, and / or PER. The input data may be received in a notification message in response to a data collection or subscription request sent by the ADAE client. The input data may be forwarded to the ADAE server.

[0045] The ADAE client may then initiate a data analysis request to the ADAE server. The ADAE client may then generate data analysis results, which may be derived locally on the ADAE client, may be generated with the help of a third-party service, and / or may be obtained from the ADAE server. The ADAE client may then send a response to the requester, which may be sent directly to the requesting server.

[0046] The response may include analysis results of the target application, such as a predicted schedule, predicted availability based on predicted service area overlap, statistics / predictions of server performance, such as server RTT, jitter, average or peak throughput, PER, server load, number of connections, etc., and / or statistics / predictions of session performance, such as session RTT, jitter, throughput, PER.

[0047] The response may include the analysis results of the target SEAL service, such as location information, group information (such as new members joining the group or changes in group size), configuration information, network resource information, statistics / predictions of network slice configuration and adaptation, etc. The response may include the analysis results of the target edge enabler layer, such as statistics or predictions of edge platform load or performance, faults, service availability, edge resource usage, service continuity planning (such as predicted target EES or EAS) or timing of ACR, etc.

[0048] The ADAE client may then take action or trigger an action to be taken based on the analysis results.

[0049] The actions of the SEAL layer may include updating location report configuration, triggering location report, updating group configuration, creating a group, updating group members, updating UE configuration, triggering network resource adaptation / modification, triggering network slice adaptation, updating network slice configuration, etc. The actions of the edge enabler layer may include updating service provisioning configuration, triggering EEC, EES registration, deregistration, triggering or updating service continuity planning, triggering or updating ACR, triggering dynamic EAS instantiation, etc.

[0050] Functional Model

[0051] Figure 1A An example of an on-network functional model of the ADAE architecture is shown. Other examples of enabling clients are SEAL enabler clients and edge enabler clients, and other examples of enabling servers are SEAL enabler servers and edge enabler servers. An ADAE server can communicate with another ADAE server.

[0052] Figure 1B An example of an off-grid functional model for the ADAE architecture is shown.

[0053] Functional Entity Description

[0054] Figure 1A The ADAE server in the 5G system can provide the server-side functions of the ADAE service, including receiving data analysis requests, collecting input data from the vertical application layer and other service enabler servers, and generating output analysis. The ADAE server can support interaction with the ADAE client, VAL server, and other entities in the 5G system. The ADAE server can also support interaction with another ADAE server in a distributed deployment.

[0055] Figure 1A and Figure 1B The ADAE client in can provide the client-side functions of the ADAE service and can act as an application client of the ADAE function. The ADAE client can support interaction with the ADAE server and the VAL client. The ADAE client can also support interaction between two UEs and other ADAE clients.

[0056] Figure 1A The VAL server in can provide server-side functions corresponding to vertical applications. The VAL server can support interaction with ADAE servers and other service enabler layer servers. The VAL server can act as a consumer of ADAE services and initiate data analysis requests. The VAL server can also provide input data to the ADAE server to support ADAE services.

[0057] Figure 1A and Figure 1B The VAL client in can provide client-side functions corresponding to vertical applications. The VAL client supports interaction with ADAE clients and other service enabler layer clients. The VAL client can act as a consumer of ADAE services and initiate data analysis requests. The VAL client can also provide input data to the ADAE client to support ADAE services.

[0058] exist Figure 1AIn the example, service enabler layer servers other than ADAE servers can act as consumers of ADAE services and initiate data analysis requests. Enabler servers can also provide input data to ADAE servers to support ADAE services. For example, enabler servers can be SEAL servers, such as location management servers, group management servers or network resource management servers, EES, ECS, etc.

[0059] exist Figure 1A and Figure 1B In the example, service enabler layer clients other than ADAE clients can act as consumers of ADAE services and initiate data analysis requests. Enabler clients can also provide input data to ADAE clients to support ADAE services. For example, enabler clients can be SEAL clients, such as location management clients, group management clients, or network resource management clients, EEC, etc.

[0060] Reference point description

[0061] exist Figure 1A In the ADAE-UU reference point, the ADAE server and the corresponding ADAE client can support the interaction between the ADAE server and the corresponding ADAE client, such as sending or forwarding data analysis requests, sending data collection requests or responses, sharing input data or output analysis.

[0062] exist Figure 1A In the ADAE-S reference point, the ADAE-S reference point can support interactions between the ADAE server and the VAL server, such as sending or receiving data analysis requests, collecting input data, and sending or receiving data analysis responses with output analysis.

[0063] exist Figure 1A and Figure 1B In the ADAE-C reference point, the ADAE-C reference point can support interactions between ADAE clients and VAL clients, such as sending or receiving data analysis requests, collecting input data, and sending or receiving data analysis responses with output analysis.

[0064] exist Figure 1A In the ADAE-ES reference point, the ADAE server can support the interaction between the ADAE server and other service enabler layer servers, such as sending or receiving data analysis requests, collecting input data, and sending or receiving data analysis responses with output analysis.

[0065] exist Figure 1A In the ADAE-EC reference point, the ADAE client can support the interaction between the ADAE client and other service enabler layer clients, such as sending or receiving data analysis requests, collecting input data, and sending or receiving data analysis responses with output analysis.

[0066] exist Figure 1BIn the ADAE-PC5 reference point, the ADAE-PC5 reference point can support interactions between ADAE clients on two UEs, such as sending or receiving data analysis requests, and sending or receiving data analysis responses with output analysis.

[0067] ADAE service opening

[0068] ADAE service consumers can request ADAE services by sending a one-time request or a subscription request to the ADAE server or client.

[0069] In the ADAE service request or subscription request, the service customer may provide the following information:

[0070]

[0071]

[0072] After receiving the request, the ADAE client or server can generate a service instance for the requested data analysis service. The instance can be associated with a specific analysis type and / or a specific analysis target. The information of the instance is maintained in the ADAE service instance profile, as shown below:

[0073]

[0074]

[0075] The service instance profile may be provided to potential consumers, such as the service enabler layer and / or vertical specific applications, through an advertisement and discovery process.

[0076] Figure 2 shows an example of ADAE service discovery and request. The following steps point to Figure 2 .

[0077] In optional step 1, the requester may send a discovery request to the ADAE service. The discovery request may include filters that specify the type of data analysis and / or the target of the analysis. Alternatively, the request may instruct the requester to subscribe to notifications of data analysis instance profiles available at the ADAE service.

[0078] In optional step 2, the ADAE service may send a response to the requester, including the discovered service instance.

[0079] In step 2A, if in step 1, the requester subscribes to notifications of data analysis instance profiles, a notification may be sent to the requester when a new profile is configured in the ADAE service.

[0080] In step 3, the requester can send a data analysis (subscription) request to the ADAE service, including the information specified in the table above. If the request follows the discovery process, the requester can include the discovered / selected service instance ID in the request.

[0081] In step 4, the ADAE service may process the request. The ADAE service may create or update a service instance profile accordingly. The received request may be compared with existing data analysis instances. If an existing instance with the same analysis type or objective is found, the request may be merged or rejected.

[0082] In step 5, the ADAE service may send a response to the requester.

[0083] In step 6, if the request defined in step 3 is a subscription request, the ADAE service may send one or more notifications to the requester and / or other specified targets. The notification may contain the results of the analysis operation performed by the ADAE service and / or additional information, such as the occurrence of events related to the ADAE service, such as fault conditions, lifecycle management events, etc., or actions performed by the ADAE service based on the request, such as triggering OAM actions based on the analysis results, triggering service enabler actions based on the analysis results, triggering VAL client and / or VAL server actions based on the analysis results, etc.

[0084] Interaction with NWDAF

[0085] ADAE servers can provide analytical services to NFs in 5GCN. For example, analytical services are provided to NWDAF via NEF, however, similar interactions can be directly envisioned for other authorized NFs. For example, NEF can open Nnef_AnalyticsContainer service to allow parties outside CN to provide application-level analytics that can be used in 5GS via ADAE servers. Corresponding Nnef_AnalyticsContainer_Create / Update / Delete / Get / Notify operations can be provided.

[0086] For Nnef_AnalyticsContainer_Create requesters, such as ADAE servers, application-level analytics parameters are stored in NWDAF or UDR via NEF. Inputs may include ADAE service descriptors, such as external application identifiers, target identifiers, and / or analytics types.

[0087] The identified target may be a UE or UE group, such as an IP address or UE (if available), GPSI (if available) and / or external group identifier (if available), application ID, service provider ID, geographic area such as TAI, DNN or EDN identifier, etc. This parameter may allow the 5GCN to determine to which 5GS entity the analysis applies.

[0088] The response to the Nnef_AnalyticsContainer_Create request may indicate to the ADAE server whether the NWDAF wants to subscribe to notifications of the indicated analytics type for the indicated target. If the NWDAF is instructed to subscribe, the response may also provide information about the notification destination.

[0089] Nnef_AnalyticsContainer_Create can be defined so that for each analysis type, the analysis is specified, the parameters are specified in the message, or the analysis can be specified as an opaque container. The container options can also allow custom analysis inputs to be provided.

[0090] The ADAE server may use a Notify operation to provide notifications corresponding to the subscribed analysis. Alternatively, an interaction of ADAE with NWDAF may be envisioned, where the NEF or NWDAF may subscribe to ADAE directly or via the NEF, such as if the NF in 5GS uses the ADAE API. Equivalent interactions may be envisioned for ADAE interactions with OAM.

[0091] ADAE Service Process

[0092] After receiving a service request, the ADAE service can collect input data and can generate the requested output analysis as requested. This section describes the common process of the ADAE service. The details of the information exchanged and the actions taken in each step may vary with different analysis types.

[0093] On-line server-client scenario

[0094] Figure 3 The following steps point to an example process of providing a service enabling layer analysis service in a cellular network such as a 3GPP system when a data analysis request is initiated on the server side, including processing at the on-net ADAE client and sending the results to the ADAE server. Figure 3 .

[0095] In step 1, a requesting server or any analytics service consumer may send a data analytics request, such as a service enablement layer data analytics request, to an ADAE server. The details of the information included in the request are detailed in the table above, but may also include the requirements for the analytics service. The requesting server may be a VAL server, an enabler layer server, such as a SEAL server, or other analytics functions in an EES, EAS, 5G system, such as NWDAF, etc.

[0096] In step 2, based on the request, the ADAE server can determine to collect input data from other servers in the system, such as vertical application servers, SEAL servers, EES / EAS / ECS, etc. The input data can be collected by initiating a data collection or subscription request to the corresponding server, and can be received by the ADAE server in a response or notification message in response to the data collection request. The input data can be collected from the vertical application layer, SEAL layer, or edge enabler layer. The input data can be collected by sending a request to collect server-side service enabling layer data related to the service enabling layer analysis request to the server determined to collect data from, and receiving server-side service enabling layer data related to the service enabling layer data analysis request from the determined server.

[0097] Input data collected from the vertical application layer may include application server / client profiles, such as type, schedule, service area, service KPI, requirements, etc., performance indicators of application servers, such as server RTT, jitter, throughput, PER, server load, number of connections, etc., or performance indicators of application sessions, such as session RTT, jitter, throughput, PER.

[0098] Input data collected from the SEAL layer may include location information reports, such as data indicating data from a location management server, VAL user or UE group information, such as a group member list, group formation information, or information from a group management server, configuration information, such as VAL UE configuration data, VAL user profile, or information from a configuration server, network resource information, such as resource adaptation, MBMS status, or information from a network resource management server, network slice configuration and adaptation information, such as information from a network slice capability enabling server, etc.

[0099] The input data collected from the edge enabler layer may include EES profiles, EEC contexts such as registration information, edge configuration or service provisioning information, ACR management events, resource utilization or load of the edge platform, etc.

[0100] In step 3, if the requested analysis requires client-side input data, the ADAE server sends a data collection request to the corresponding ADAE client. The request may specify what input data may be required from the client side. The request for client-side data may be determined based on the service enabling layer analysis request.

[0101] In step 4, after receiving the data collection request from the ADAE server, the ADAE client can collect client-side input data from VAL clients, enabler layer clients (such as SEAL clients or EEC), other ADAE clients, and modems. The client-side input data may include information as described in step 2.

[0102] In step 5, the collected client-side input data may be sent to the ADAE server.

[0103] In step 6, the ADAE server may also collect input data from other analysis functions in the system (such as NWDAF or OAM) and / or request analysis services from them. For example, the ADAE server may collect input data from 5GC via monitoring events or via interaction with NWDAF, receive input data from the OAM system, receive analysis results from NWDAF via subscription, etc.

[0104] In step 7, based on the collected input data, the ADAE server can derive analysis results. The analysis results can be derived based on the server-side data, the client-side data, and the requirements of the analysis service. The analysis results may include:

[0105] Analysis results of the target application, such as predicted schedule, predicted availability based on predicted service area overlap, statistics or predictions of server performance, such as server RTT, jitter, average or peak throughput, PER, server load, number of connections, etc., statistics and predictions of session performance, such as session RTT, jitter, throughput, PER.

[0106] Analysis results of the target SEAL service, such as statistics / predictions of location information, group information (such as new members joining the group or changes in group size), configuration information, network resource information, network slice configuration and adaptation, etc.

[0107] Analysis results of the target edge enabler layer, such as statistics / predictions of edge platform load or performance, failures, service availability, edge resource usage, service continuity planning (such as predicted target EES or EAS), or timing of ACR, etc.

[0108] Analysis results of a target VAL user or UE, or a group of VAL users or UEs, such as information about the distribution, density or membership of UEs in a certain location or group.

[0109] Analysis results of the target DN, EDN or its network slice, such as load analysis. For example, the number of UEs, VAL users and / or sessions active in the DN, EDN or network slice.

[0110] In step 8, the ADAE server may take action or trigger an action to be taken based on the analysis result, such as by sending a request to a corresponding entity. The action may include:

[0111] Actions of the SEAL layer, such as updating location report configuration, triggering location report, updating group configuration, creating a group, updating group members, updating UE configuration, triggering network resource adaptation or modification, triggering network slice adaptation, updating network slice configuration, etc.

[0112] Operations at the edge enabler layer, such as updating service provisioning configuration, triggering EEC or EES registration or deregistration, triggering or updating service continuity planning, triggering or updating ACR, triggering dynamic EAS instantiation, etc.

[0113] In step 9, the ADAE server may send a response or notification regarding the analysis results. The response or notification may be sent to the requesting server and / or other targets as specified in the reporting targets in the table above.

[0114] On-line client-server scenario

[0115] Figure 4 The following steps point to the following example process when a data analysis request is initiated on the client side, including processing on the ADAE server and sending the results to the ADAE client on the network. Figure 4 .

[0116] In step 1, the requesting client may send a data analysis request to the ADAE client. The details of the information contained in the request are shown in the table above. Error! Reference source not found. The requesting client may be a VAL client, an enabler layer client such as a SEAL client or an EEC, etc. The ADAE client may also initiate a data analysis request on its own, in which case step 1 is skipped.

[0117] In step 2, based on the request, the ADAE client may collect client-side input data in the system. The ADAE client may collect input data from the VAL client, the enabler layer client, other ADAE clients, and the modem. The client-side input data may include, for example, Figure 3 The information described in step 2.

[0118] In step 3, the ADAE client may forward or send the data analysis request with the collected client-side input data to the ADAE server.

[0119] In step 4, based on the request, the ADAE server can collect server-side input data from other servers in the system, such as Figure 3 in step 2.

[0120] In step 5, the ADAE server may also collect input data from other analysis functions in the system and / or request analysis services from them, such as Figure 3 In step 6 of the Error! Reference source not found.

[0121] In step 6, based on the collected input data, the ADAE server can derive analysis results, such as Figure 3 in step 7.

[0122] In step 7, the ADAE server may send a response with the analysis results to the ADAE client.

[0123] In step 8, the ADAE server performs or triggers actions accordingly, such as Figure 3 Alternatively, the ADAE server may send a request to the ADAE client to perform or trigger the desired action.

[0124] In step 9, the ADAE client may send a response or notification regarding the analysis results. The response or notification may be sent to the requesting client and / or other targets as specified in the report target in the table above.

[0125] Enable off-grid functionality

[0126] Figure 5 An example process for processing an analysis request using an off-network ADAE client is shown. The analysis request can be initiated by a client or server requestor and can be distributed via the ADAE server. The following steps point to Figure 5 .

[0127] In step 1, a requester client or server may send a data analysis request to an ADAE server. This may be a request initiated by another ADAE client, which may eventually be forwarded to an ADAE server. Details of the information contained in the request are shown in the table above. Error! Reference source not found.

[0128] In step 2, the ADAE server may perform server-side input data collection and analysis.

[0129] In step 3, the ADAE server may send the data analysis task and the collected server-side input data to the ADAE client. The server may include information about the ADAE clients participating in the task in the message sent to the client. For ADAE clients hosted by an online UE, such as Figure 5 For client A in , step 7 may follow step 3.

[0130] In step 4, UE clients B and C may be connected and operated off-network.

[0131] In step 5, client B may recognize that client C is participating in the analysis task and decide to forward the task.

[0132] In step 6, client B may forward the analysis task corresponding to client C to client C.

[0133] In step 7, the ADAE client can perform necessary analysis tasks.

[0134] In step 8, the off-grid ADAE client may optionally perform inter-ADAE client signaling required to perform the ADAE task. The signaling may involve data exchange and data operation control. For example, one ADAE client may trigger another client to refresh data, restart averaging, etc. based on its own processing.

[0135] In step 9, a previously off-network ADAE client, such as client C, may come online and connect to the ADAE server.

[0136] In step 10, if the UE hosting client C comes online, it can check if client B has unreported data to send to the ADAE server. If so, it can collect that data and can send it along with its report.

[0137] In step 11, the ADAE client may send an analysis report to the ADAE server. This may include reports from off-network clients. Alternatively, off-network clients may provide their analysis reports when online.

[0138] In step 12, the ADAE server may process the report and may provide an analysis response to the requester.

[0139] Figure 5The example shown in describes client C becoming online first. Client C is then shown collecting information from itself and client B and passing the information to the ADAE server. Many equivalents and alternatives can be envisioned. For example, in some off-network deployments, certain UEs may act as repeaters. This may result in client B becoming online and off-network. Similarly, ADAE client C may be located on a non-3GPP device, e.g., a device that can be identified in the network but does not have 3GPP connectivity. Both examples will use similar processes.

[0140] In addition, steps 6 to 11 may also be applicable to other client-to-client communications and are not limited to off-network scenarios.

[0141] Application Analysis

[0142] Application performance analysis may be used to obtain information about the performance and / or functionality of a vertical application client or server or an edge application client or server.

[0143] When requesting application analysis, in addition to the information in the table above, the requester can also specify the identifier of the target application in the request. In addition, the requester can specify what performance and / or functional metrics are required, such as performance metrics such as RTT, jitter, throughput, PER, or functional operations such as the number or distribution of application client requests issued to the application server. If not specified, all available metrics can be applied.

[0144] Input data for application performance analysis can be collected from the vertical application layer (VAL server and / or client), 5GC, OAM, as defined in the following table:

[0145]

[0146]

[0147] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0148]

[0149] ADAE services can trigger actions based on output analysis. For example, if performance degradation is predicted, the ADAE server can send a notification to the affected VAL application so that the latter can take proactive action, or the ADAE server can send a resource adaptation request that can allocate more resources to the affected application, thereby mitigating the potential impact.

[0150] Application coverage analysis

[0151] Application coverage analysis can be used to obtain information about the distribution or coverage of different types of applications at a location.

[0152] When requesting application coverage analysis, in addition to the information in the table above, the requester may also specify the identifier of the target location or service area in the request. If the analysis is related to finding one or more specific types of applications in a certain area, the requester may also need to specify the identifier of the application to be tracked.

[0153] Input data for application coverage analysis can be collected from the vertical application layer, 5GC, and OAM, as defined in the following table:

[0154]

[0155] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0156]

[0157]

[0158] ADAE services can trigger actions based on output analysis. For example, by examining statistics or predictions of application coverage, service coverage gaps can be identified, which can guide decisions on deployment or instantiation of applications.

[0159] User presence analysis

[0160] User presence analysis may be used to obtain information about the distribution or density of VAL users or UEs at a location, or to track the presence of one or more specified VAL users or UEs.

[0161] When requesting a user presence analysis, in addition to the information in the table above, the requester may also specify an identifier for a target location or service area in the request.

[0162] If the analysis is related to determining the number of users at a certain location, then the "number of users" can be specified in the request.

[0163] If the analysis is related to finding one or more specific users within a group in a certain area, then "user presence" can be specified in the request. The requester also needs to specify the ID and group ID of the VAL user or UE to be tracked.

[0164] Input data for user presence analysis can be collected from the vertical application layer, location management SEAL server, 5GC, and OAM, as defined in the following table:

[0165]

[0166]

[0167] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0168]

[0169] ADAE services can trigger actions based on output analysis. For example, statistics on the presence of users at a certain location can be used to predict the user's route information and shared with the VAL server. If the user density is predicted to exceed a certain threshold at some time in the future, the service enabler layer can be notified and an edge application server can be instantiated to offload the surge in traffic. Predictions on the presence of UEs can also be used to determine schedules or trigger ACRs.

[0170] User Group Analysis

[0171] User group analysis can be used to obtain information about VAL user groups or UE groups, and to track the group membership of a certain VAL user or UE.

[0172] When requesting user group analysis, in addition to the information in the table above, the requester may also specify the identifier of the target group, target VAL user or UE in the request.

[0173] If the analysis is related to determining the number of VAL users or UEs of a group, then "Group Size" may be specified in the request. If the analysis is related to tracking the group membership of a specific VAL user or UE, then "User Membership" may be specified in the request. The requester also needs to specify the ID of the VAL user or UE.

[0174] Input data for user group analysis can be collected from the vertical application layer, group management (SEAL) server, 5GC, and OAM, as defined in the following table:

[0175]

[0176] Output analyses that will be made available through ADAE may include statistics and predictions as defined in the following table:

[0177]

[0178]

[0179] The ADAE service can trigger actions based on output analysis. For example, group management actions can be proactively taken based on the predicted time when members join or leave the group.

[0180] User group analysis results can also be combined with user presence analysis or other location-related analysis to generate location-based group analysis.

[0181] Network resource analysis

[0182] Network resource analysis may be used to provide information on resource utilization of a multicast service for a specific VAL user or UE group in a specific service area during a specific time period.

[0183] When requesting network resource analysis, in addition to the information in the above table, the requester may also specify the TMGI or other multicast session identifier, the VAL user ID or UE ID, and the service area identifier in the request.

[0184] Input data for network resource analysis can be collected from the network resource management SEAL server, 5GC, and OAM, as defined in the following table:

[0185]

[0186] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0187]

[0188]

[0189] EAS analysis

[0190] EAS analysis can be used to monitor and predict the load and status of the EAS. When requesting EAS analysis, in addition to the information in the table above, the requester can also specify the identifier of the target EAS in the request. Input data for EAS analysis can be collected from EAS, edge enabler layers (such as associated EES and / or ECS), and other ADAE servers, as defined in the following table:

[0191]

[0192] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0193]

[0194]

[0195] The ADAE service can trigger actions based on output analysis. For example, EAS load information can be included in the EAS discovery filter so that heavily loaded EASs can be excluded from the discovery response. EAS load analysis can also be used to make dynamic EAS instantiation decisions, such as triggering dynamic EAS instantiation when an existing EAS is predicted to be overloaded. EAS load analysis can also be used for ACR planning, such as scheduling and triggering ACRs before the time when the EAS is predicted to be overloaded.

[0196] EES analysis

[0197] EES analytics can be used to monitor and predict the state of an EES and / or an edge platform associated with an EES. When requesting EES analytics, in addition to the information in the table above, the requester can also specify the identifier of the target EES in the request. Input data for EES analytics can be collected from the edge enabler layer (such as EES or ECS) as defined in the following table:

[0198]

[0199]

[0200] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0201]

[0202] ADAE services can trigger actions based on output analysis. For example, EES load statistics can be notified to the ECS so that heavily loaded EESs are not offered to new EECs. EES load analysis can also be used for ACR planning, such as scheduling and triggering ACRs from the current EES to the new EES.

[0203] EDN Analysis

[0204] EDN analysis can be used to monitor and predict the status and resource usage of EDNs. When requesting EDN analysis, in addition to the information in the table above, the requester can also specify the identifier of the target EDN in the request.

[0205] Input data for EDN analysis can be collected from the edge enabler layer (ECS), 5GC, or OAM, as defined in the following table:

[0206]

[0207] Output analyses that will be made public by ADAE may include statistics or predictions as defined in the following table:

[0208]

[0209]

[0210] Similar to EAS and EES analysis, EDN analysis can be used to make decisions about ACRs across different EDNs, such as triggering and scheduling ACRs from overloaded EDNs to lightly loaded EDNs.

[0211] Network Slicing Analysis

[0212] The NSCE server can use network slice analysis to make decisions on slice adaptation, such as determining whether to assign additional ACs and EASs to certain existing slices or to assign new slices. When requesting network slice analysis, in addition to the information in the table above, the requester can also specify the identifier of the target network slice in the request.

[0213] The input data for network slice adaptation analysis can be collected from the service enabler layer, edge enabler layer, 5GC or OAM, as defined in the following table:

[0214]

[0215] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0216]

[0217]

[0218] Network openness analysis

[0219] Network openness analysis can be used to monitor CN open API access, such as applications accessing CN services via SCEF, NEF or PCF, and track information about these API calls in the system. Network openness analysis can be defined as CAPIF API calls in the context of CAPIF. These analyses can be further extended to other CAPIF API calls.

[0220] When requesting network open analysis, in addition to the information in the table above, the requester can also specify the identifier of the target open NF in the request. The requester can further specify other filter information, such as service area, service provider ID, API ID type (such as device triggering, session QoS configuration, UE location monitoring), etc.

[0221] Input data for network openness analysis can be collected from the service enabler layer, 5GC, or OAM, as defined in the following table:

[0222]

[0223]

[0224] Output analyses that will be made available through ADAE may include statistics or predictions as defined in the following table:

[0225]

[0226]

[0227] Off-grid analysis

[0228] Off-network analysis can be used to collect information and generate analysis for off-network communications between ADAE clients and other service enabler clients. When requesting off-network analysis, in addition to the information in the table below, the requester may also specify the identifier of the target UE in the request.

[0229] The input data for off-network analysis can be collected from the service enabler layer, edge enabler layer, 5GC, or OAM, as defined in the following table:

[0230]

[0231]

[0232] Output analyses that will be made public by ADAE may include statistics or predictions as defined in the following table:

[0233]

[0234] Figure 6 An example graphical user interface is shown for requesting ADAE services and viewing analysis results.

[0235] Fig. 7AAn embodiment of an example communication system 100 in which the methods and apparatus described and claimed herein may be implemented is illustrated. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (generally or collectively referred to as WTRUs 102), 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 a V2X server (or ProSe function and server) 113, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Figure 7A-7E , but it should be understood that for the various use cases envisioned for 5G wireless communications, each WTRU may include or be implemented in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a truck, a train or an airplane, and the like.

[0236] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 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 a V2X server (or ProSe function and server) 113. For 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 site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0237] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to send and / or receive wired or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, thus, may utilize multiple transceivers for each sector of the cell.

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

[0239] The base station 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0240] 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 via an air interface 115c / 116c / 117c, 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 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0241] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f and / or 102g may communicate with each other via an air interface 115d / 116d / 117d (not shown), 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 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

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

[0243] In an embodiment, the base station 114a and the WTRU 102a, 102b, 102c, or the RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b and WTRU 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish an air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications, etc.). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0244] In an embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology 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), etc.

[0245] Fig. 7AThe base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, and the like. In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. Fig. 7A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not be required to access the Internet 110 via core network 106 / 107 / 109.

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

[0247] Although not in Fig. 7A 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 the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

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

[0249] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig. 7A The WTRU 102e shown in FIG. 1 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.

[0250] Figure 7B 1 is a block diagram of an example apparatus or device, such as WTRU 102, configured for wireless communication according to the embodiments illustrated herein. Figure 7B As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 113, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the above elements while still being consistent with the embodiment. In addition, the embodiment contemplates that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, such as but not limited to a 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, and a proxy node, etc. may be included in Figure 7BSome or all of the elements depicted in and described herein.

[0251] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 7B The processor 118 and the transceiver 120 are depicted as separate components, although it is appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0252] The send / receive element 122 may be configured to send or receive signals to and from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the send / receive element 122 may be an antenna configured to send and / or receive RF signals. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the send / receive element 122 may be configured to send and receive both RF signals and optical signals. It is to be appreciated that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

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

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

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

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

[0257] 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. The WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 in addition to or in lieu of the information from the GPS chipset 136, and / or determine its location based on the timing of receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0258] The processor 118 may also be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

[0259] The WTRU 102 may be implemented in other devices or equipment, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as one of the peripheral devices 138.

[0260] Figure 7C 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ 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. Figure 7C As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while still being consistent with an embodiment.

[0261] like Figure 7CAs shown in , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node-B 140a, 140b, 140c to which it is connected. In addition, each of RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

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

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

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

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

[0266] Fig.7D1 is a system diagram of the RAN 104 and the core network 107 in accordance with an embodiment. As described 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.

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

[0268] 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, etc. Fig.7D As shown in FIG. , eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0269] Fig.7D The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements is depicted as part of the core network 107, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

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

[0274] Fig. 7E 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As further described below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

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

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

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

[0278] like Fig. 7EAs shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols that facilitate data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the above elements is depicted as part of the core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0279] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 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 communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0280] Although not in Fig. 7E 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between the home core network and the visited core network.

[0281] Described in this article and Fig. 7A , Figure 7C , Fig.7D and Fig. 7EThe core network entities illustrated in the diagram are identified using names given to these entities in certain existing 3GPP specifications, but it should be understood that in the future, these entities and functions may be identified by other names, and in future specifications published by 3GPP, including future 3GPP NR specifications, some entities or functions may be merged. Fig. 7A , Figure 7B , Figure 7C , Fig.7D and Fig. 7E The specific network entities and functions described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0282] Figure 7F is a block diagram of an exemplary computing system 90 in which Fig. 7A , Figure 7C , Fig.7D and Fig. 7E 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or server and may be primarily controlled by computer-readable instructions, which may be in the form of software, regardless of where or how such software is stored or accessed. Such computer-readable instructions may be executed in a processor 91 to enable the computing system 90 to 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 associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication 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 apparatus disclosed herein.

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

[0284] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such a memory includes circuits that allow information to be stored and retrieved. ROM 93 generally contains stored data that is not easily modified. The data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes is set, it cannot access memory in the virtual address space of other processes.

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

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

[0287] In addition, the computing system 90 may include a communication network that can be used to connect the computing system 90 to an external communication network, such as Fig. 7A , Figure 7B , Figure 7C , Fig.7D and Fig. 7EThe RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 of the present invention may be used to enable the computing system 90 to communicate with other nodes or functional entities of these networks through communication circuits, such as a network adapter 97. Alone or in combination with the processor 91, the communication circuits may be used to perform the sending and receiving steps of certain devices, nodes or functional entities described herein.

[0288] Figure 7G An embodiment of an example communication system 111 in which the methods and apparatus described and claimed herein may be implemented is illustrated. As shown, the example communication system 111 may include wireless transmit / receive (WTRU) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B, although it is to be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary represented as a dashed line in the figure). WTRUs A, B, C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over a Uu interface or a sidelink (PC5) interface.

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

Claims

1. A device for providing a service enabling layer analysis service in a cellular network: receiving a service enablement layer data analysis request from an analysis service consumer, wherein the request includes a requirement for the analysis service; Based on the service enabling layer analyzing request, determining to collect data from a service layer server; Sending a request to the determined service layer server to collect server-side service enablement layer data related to the service enablement layer analysis request; receiving, from the determined service layer server, server-side service enabling layer data associated with the service enabling layer data analysis request; Based on the service enabling layer analyzing the request, determining to collect data from the service layer client; Sending a request to the determined service layer client to collect client-side service enablement layer data related to the service enablement layer analysis; receiving, from the determined service layer client, client-side service enabling layer data associated with the service enabling layer data analysis request; generating analysis results based on the received server-side data, the received client-side data, and the requirements of the analysis service; and Sends a response to the analysis service consumer indicating the results of the analysis.

2. The apparatus according to claim 1, wherein the analysis service consumer is an application server or a service enabling layer server.

3. The apparatus according to claim 1, wherein the analysis request further comprises one or more of an analysis type, identifiers of one or more analysis targets, analysis filter information, and an area of ​​interest.

4. The apparatus of claim 1, wherein the analysis request is a subscription request.

5. The apparatus of claim 1, wherein the apparatus further collects data from another entity capable of providing analytical services.

6. The apparatus of claim 1, wherein the analysis results include predictions and corresponding confidence levels.

7. The apparatus of claim 1, wherein the analysis request is related to application performance.

8. The apparatus of claim 1, wherein the analysis request is associated with an edge data network.

9. The apparatus of claim 1, wherein the analysis request is related to a network slice.

10. The apparatus of claim 1, wherein the analysis request is related to access to a service or function.

11. A method for providing a service enabling layer analysis service in a cellular network, comprising: receiving a service enablement layer data analysis request from an analysis service consumer, wherein the request includes a requirement for the analysis service; Based on the service enabling layer analyzing request, determining to collect data from a service layer server; Sending a request to the determined service layer server to collect server-side service enablement layer data related to the service enablement layer analysis request; receiving, from the determined service layer server, server-side service enabling layer data associated with the service enabling layer data analysis request; Based on the service enabling layer analyzing the request, determining to collect data from the service layer client; Sending a request to the determined service layer client to collect client-side service enablement layer data related to the service enablement layer analysis; receiving, from the determined service layer client, client-side service enabling layer data associated with the service enabling layer data analysis request; generating analysis results based on the received server-side data, the received client-side data, and the requirements of the analysis service; and Sends a response to the analysis service consumer indicating the results of the analysis.

12. The method of claim 11, wherein the analytical service consumer is an application server or a service enablement layer server.

13. The method according to claim 11, wherein the analysis request further includes one or more of an analysis type, identifiers of one or more analysis targets, analysis filter information, and a region of interest.

14. The method of claim 11, wherein the analysis request is a subscription request.

15. The method of claim 11, wherein the device also collects data from another entity that can provide analytical services.

16. The method of claim 11, wherein the analysis results include predictions and corresponding confidence levels.

17. The method of claim 11, wherein the analysis request is related to application performance.

18. The method of claim 11, wherein the analysis request is associated with an edge data network.

19. The method of claim 11, wherein the analysis request is related to a network slice.

20. The method of claim 11, wherein the analysis request is related to access to a service or function.

Images