Traffic steering enhancements for cellular networks

Abstract

Methods, systems, and apparatuses can help enhance the PMF protocol and new ATSSS steering modes to enable support for analytics-driven steering or multi-USIM steering. The following functions are disclosed: 1) enabling a UE to use the PMF protocol to provide UE-specific data to a NWDAF for analytics; 2) enabling a multi-USIM UE to inform the core network, over the user plane, of the UE's desire to suspend communication with the CN associated with one USIM so that the UE can communicate with the CN associated with another USIM; 3) defining new ATSSS steering modes to support data analytics-driven steering; and 4) defining new ATSSS steering modes to support multi-USIM steering, among others.

Description

[0001] Citation of relevant applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 967,125, filed January 29, 2020, entitled “TRAFFIC STEERING ENHANCEMENTS FOR CELLULAR NETWORKS,” and U.S. Provisional Patent Application No. 63 / 012,969, filed April 21, 2020, entitled “TRAFFIC STEERING ENHANCEMENTS FOR CELLULAR NETWORKS,” the contents of which are incorporated herein by reference. Background Technology

[0003] 5G system architecture

[0004] Figure 1 This describes the 3GPP 5G non-roaming system architecture, in which various entities interact with each other through designated reference points. User Equipment (UE) can communicate with the core network (CN) to establish control signaling and enable the UE to use services from the network. Examples of control signaling functions include: registration, connection and mobility management, authentication and authorization, session management, etc.

[0005] The following explanation highlights Figure 1 Some network functions (NFs) related to control signaling:

[0006] • Access and Mobility Function (AMF): The UE sends N1 messages to the AMF through the RAN node to perform many control plane signaling functions, such as registration, connection management, mobility management, access authentication, and authorization.

[0007] • Session Management Function (SMF): The SMF is responsible for session management related to establishing PDU sessions, allowing the UE to send data to a data network (DN) such as the Internet, or to application servers and other session management-related functions.

[0008] • Policy and Control Function (PCF): PCF provides a policy framework for managing network behavior, accessing subscription information for policy decisions, and more.

[0009] • Authentication Server Function (AUSF): AUSF supports UE authentication for both 3GPP and untrusted non-3GPP access.

[0010] • Unified Data Management (UDM): UDM supports the generation of 3GPP AKA authentication credentials, user identification processing, subscription management, etc.

[0011] • Network Slice Selection Function (NSSF): NSSF covers all aspects of network slice management, such as the selection of network slice instances for the UE and the management of NSSAI.

[0012] • Radio Access Network (RAN): RAN nodes provide communication access from the UE to the core network for both control plane communication and user plane communication.

[0013] Access traffic redirection, switching, and offloading

[0014] Cellular systems already support UE connectivity with both 3GPP and non-3GPP access methods (such as Wi-Fi). However, prior to Rel-16, data flows could only use either 3GPP or non-3GPP access at any given time, and could not use both simultaneously in a standardized manner. With the increase in mobile data traffic, network operators are seeking ways to balance data traffic between these two access methods to maintain service quality while remaining transparent to users. With the increasing prevalence of Wi-Fi networks, operators can more dynamically offload data traffic from mobile networks to Wi-Fi networks, thereby fully utilizing their resources, especially in indoor scenarios where mobile coverage is decreasing. This will improve the user experience, particularly for newer use cases introduced by 5G systems, such as real-time video streaming, virtual or augmented reality, gaming, and more.

[0015] Figure 2 This indicates 5G architecture support for the Access Traffic Direction, Handover, and Offloading (ATSSS) feature in Rel-16. This feature allows both the UE and CN to direct, handover, and offload traffic between 3GPP access and non-3GPP access. In other words, the UE uses ATSSS rules to determine whether to send UL data through 3GPP access or non-3GPP access, or both simultaneously. Similarly, the UPF in the CN uses N4 rules to route DL data to the UE through 3GPP access or non-3GPP access, or both simultaneously. ATSSS and N4 rules are created by the SMF and provided to the UE and UPF respectively during the MA PDU session establishment process. The MA PDU session is defined as “a PDU session that provides services that can use one access network at a time, or simultaneously use one 3GPP access network and one non-3GPP access network” in 3GPP TS 23.501, System Architecture for the 5G System; Stage 2, V16.2.0 (2019-09) (hereinafter referred to as [1]).

[0016] Figure 3This describes the PDU session establishment process requested by the UE. The PDU session is used to transmit UL or DL ​​data between the UE and the data network (DN) via the CN's user plane (UP).

[0017] MA PDU session establishment process based on Figure 3 The PDU session establishment process shown has the following differences (according to 3GPP TS 23.502, Procedure for the 5G System; Stage 2, V16.2.0 (2019-09) - hereinafter referred to as [2]).

[0018] • PDU session establishment request messages can be sent via 3GPP access or non-3GPP access. In the following steps, it is assumed that it is sent via 3GPP access.

[0019] • In step 1, the UE provides an “MA PDU Request” indication in the UL NAS transmission message and provides the ATSSS capability (e.g., “MPTCP capability” or “ATSSS-LL capability”) as defined in Section 5.32.2 (Multi Access PDU Sessions) of TS 23.501 in the PDU session establishment request message.

[0020] • In step 2, if the AMF supports MA PDU sessions, the AMF selects an SMF that supports MA PDU sessions.

[0021] • In step 3, the AMF informs the SMF that the request is for an MA PDU session (e.g., it includes an “MA PDU request” indication), and also indicates to the SMF whether the UE has registered through both access methods.

[0022] • In step 7, the SMF sends an "MA PDU Request" instruction to the PCF in the SM Policy Control Creation message. The PCF decides whether to allow the MA PDU session based on operator policies and subscription data.

[0023] The PCF provides PCC rules for the MA PDU session, such as PCC rules that include ATSSS policy control information, as specified in 3GPP TS23.503, Policy and Charging Control Framework for the 5G System; Stage 2, V16.2.0 (2019-09) (hereinafter referred to as [3]). Based on the received PCC rules, the SMF derives (a) ATSSS rules, which will be sent to the UE to control uplink traffic routing, handover, and offloading, and (b) N4 rules, which will be sent to the UPF to control downlink traffic routing, handover, and offloading. If the UE indicates support for “ATSSS-LL capability”, the SMF can derive measurement assistance information.

[0024] ·exist Figure 3 The remaining steps involve the SMF establishing user plane resources via 3GPP access (e.g., access via sending a PDU session establishment request):

[0025] In step 10, the N4 rule derived by the SMF for the MA PDU session is sent to the UPF, while the two N3 UL CN tunneling information are allocated by either the SMF or the UPF. If the ATSSS capability of the MA PDU session indicates "ATSSS-LL capability," the SMF can include measurement information in the N4 rule to instruct the UPF to initiate performance measurements for that MA PDU session. In step 10a, the UPF allocates addressing information for the Performance Measurement Function (PMF) in the UPF. In step 10b, the UPF sends the addressing information of the PMF in the UPF to the SMF.

[0026] In step 11, for an MA PDU session, the SMF includes an "MA PDU session accepted" indication in the Namf_Communication_NlN2MessageTransfer message sent to the AMF. Based on the received "MA PDU session accepted" indication, the AMF marks the PDU session as an MA PDU session.

[0027] In step 13, the UE receives a PDU session establishment acceptance message, which indicates to the UE that the requested MA PDU session has been successfully established. This message includes the ATSSS rules for the MA PDU session derived by the SMF. If the ATSSS capability for the MA PDU session indicates "ATSSS-LL capability", the SMF can include the PMF addressing information from the UPF in the measurement auxiliary information.

[0028] • After step 18, if the SMF was notified in step 2 that the UE has registered via both access methods, the SMF also initiates the establishment of user plane resources via non-3GPP access. The SMF sends an N1N2 message transmission containing N2 SM information to the AMF and instructs the AMF that the N2 SM information should be sent via non-3GPP access. The N1N2 message transmission does not contain the N1SM container for the UE because the N1 SM container has already been sent to the UE in step 13. After this step, two N3 tunnels are established between the PSA and the RAN / AN.

[0029] When creating an MA PDU session, the UE specifies the guidance function it supports, whether it is ATSSS-SLL or MPTCP, or both. The guidance function determines how data traffic is sent along the UE201's protocol stack. Figure 4 This example shows a UE model with both ATSSS-LL and MPTCP routing capabilities. ATSSS-LL is a lower-layer routing function that supports all traffic types such as TCP, UDP, and Ethernet. On the other hand, MPTCP routing is an upper-layer routing function that supports the MPTCP protocol.

[0030] Each ATSSS rule specifies a guidance mode to inform the UE how to allocate UL traffic via 3GPP access and non-3GPP access. The following guidance modes are currently defined in [1].

[0031] -Active-Backup: Active-Backup is used to route SDF on an active access when it is available, and to switch the SDF to another available access (backup access) when the active access becomes unavailable. When the active access becomes available again, the SDF is switched back to that active access. If the backup access is not specified, SDF is only allowed on the active access and cannot be transmitted on other accesses.

[0032] - Minimum Latency: Minimum latency is used to direct SDF traffic to an access determined to have the minimum round-trip time (RTT). As defined in Clause 5.32.5, the UE and UPF can obtain measurements to determine the RTT via 3GPP access and via non-3GPP access. Additionally, if an access becomes unavailable, all SDF traffic is switched to another available access if permitted by PCC rules (as specified in Clause 5.32.4).

[0033] - Load balancing: If both access methods are available, load balancing is used to offload SDF traffic between them. Load balancing includes the percentage of SDF traffic that should be sent via the 3GPP access and the percentage that should be sent via the non-3GPP access. Load balancing only applies to non-GBR QoS flows. Additionally, if one access becomes unavailable, all SDF traffic is switched to the other available access as if the percentage of SDF traffic transmitted via that available access were 100%.

[0034] - Priority-based: Priority-based traffic is used to direct all SDF traffic to a high-priority access until congestion is determined on that access. In this case, SDF traffic is also sent to a low-priority access, for example, SDF traffic is split between the two access methods. Additionally, when the high-priority access becomes unavailable, all SDF traffic is switched to the low-priority access. How the UE and UPF determine when congestion occurs on the access depends on the implementation method.

[0035] To support ATSSS features, both the UE and UPF obtain access network performance measurements. Performance Measurement Functions (PMFs) exist in both the UE and UPF to obtain these measurements. When using ATSSS-SLL, performance measurement results are sent between the PMF and UPF in the UE via the PMF protocol. For MPTCP routing, the MPTCP protocol provides round-trip time (RTT) measurements. For ATSSS-LL, RTT measurements are obtained from echo request / response messages between the UE's PMF and UPF. Currently, performance measurement results consist of an availability report and RTT measurements. The availability report specifies whether access is available for traffic routing, and the RTT measurements provide the time taken for request-response messages to traverse the access network.

[0036] 3GPP FS_ATSSS_Ph2 SID (SP-190558, Study on Access Traffic Steering, Switch, and Splitting support in the 5G system architecture Phase 2; SP#84 (2019-06) - hereinafter referred to as [5]) has confirmed that although ATSSS support was added in Rel-16, some aspects of the initial scope are still not supported. As a result, the SID revealed that it will continue to study to add support for these aspects of ATSSS features. For convenience, some of the SID's goals are listed below:

[0037] - Whether and how to support traffic offloading for GRB traffic.

[0038] - Whether and how to support additional guided modes.

[0039] - Whether and how to support additional guided methods.

[0040] - Is it necessary to perform additional measurements on the performance of both paths for multi-access PDU sessions to better support existing and newly defined guidance modes, and how can such measurements be performed, for example, through an extension of performance monitoring capabilities?

[0041] - Whether and how to improve the performance measurement mechanism (e.g., in addition to responding to requests / echo responses) to minimize UE battery consumption and reduce overhead traffic between the UE and UPF.

[0042] - For roaming scenarios not supported in Rel-16, whether and how to support ATSSS.

[0043] - Whether and how to support further differentiation of 3GPP access within the ATSSS rules, and whether and how to improve the ATSSS rules with conditions related to access quality.

[0044] - Whether and how to utilize one access branch via EPC and another access branch via non-3GPP access 5GS to support multi-access PDU sessions.

[0045] - Whether and how UEs under both 3GPP and non-3GPP coverage can switch traffic from one access to another based on various conditions (e.g., access quality conditions).

[0046] - For multi-access PDU sessions, whether and how to support routing traffic to secondary PDU session anchors (using a UPF that acts as a UL-CL / branch point).

[0047] Network data analysis function

[0048] Network Data Analysis Function (NWDAF) provides data analysis services to different Network Functions (NFs) through the NNF interface, such as... Figure 5 As shown, NWDAF can request a subscription to collect data from NF via the NNF interface based on a specific context. In addition to NF, NWDAF also provides data analysis services for the OAM system. The entities connected to the NWDAF interface are: AMF, SMF, PCF, UDM, AF (directly or via NEF), and OAM.

[0049] Some of the data collected by NWDAF falls under categories such as loading information within network slice instances, specific NFs, and regions of interest. However, other data collected by NWDAF is UE-centric information, such as UE service experience, UE mobility, UE communication, user data congestion, and QoS statistics. NWDAF collects this data from the corresponding NFs and OAMs, performs analysis on the data, and makes the analysis available to the NF and OAM systems.

[0050] Work is underway in the 3GPP FS_eNA_Ph2 (SP-190557, Study on Enablers for Network Automation for 5G-phase 2; SP#84 (2019-06) - hereinafter referred to as [6]) study to investigate further enhancements to NWDAF. A key issue that has not yet been addressed in Rel-16 is how NWDAF can collect data from the UE for analysis. For convenience, the questions raised in 3GPP TR 23.791, Study of Enablers for Network Automation for 5G; SP#84 (2019-06) (hereinafter referred to as [7]) regarding this key issue are listed below.

[0051] - What types of information from the UE can be collected by the network (e.g., NWDAF) as input for analysis?

[0052] - What types of analytical information can NWDAF provide to other NEs to fully utilize the data provided by the UE?

[0053] How often should such data provided by the UE be shared with NWDAF?

[0054] What triggers the UE to provide data as an input for analysis to the NWDAF?

[0055] - How can we ensure the integrity and carrier-grade accessibility of the information provided by the UE to avoid the use of misleading or untrusted information in the network?

[0056] Are there any privacy aspects that need to be considered, such as those related to information provided by the UE? If so, how can privacy be ensured regarding the collection and use of UE data?

[0057] How does NWDAF collect information from the UE (data collection methods)?

[0058] Multiple USIM SID

[0059] The 3GPP FS_MUSIM study (3GPP SP-190248, Study on system enablers for multi-USIM devices; SP#83 (2019-03) - hereinafter referred to as [8]) affirms the need for 3GPP to standardize the operation of devices with multiple USIMs. According to [8], "Support for multiple USIMs is currently handled in an implementation-specific manner without any support from the 3GPP specification, resulting in a wide variety of implementations and UE behaviors. For cost-efficiency reasons, multi-USIM device implementations often use common radio and baseband components shared among multiple USIMs, which leads to several problems affecting the performance of 3GPP systems." The study further describes the paging conflict problem between USIMs in such implementations.

[0060] For convenience, some of the confirmed targets in [8] are listed below.

[0061] - A mechanism for delivering a paging message intended for USIM A while the UE actively communicates with USIM B.

[0062] - A mechanism that allows the suspension (release) and resumption of an ongoing connection in a 3GPP system associated with USIM A, enabling the UE to temporarily leave the 3GPP system associated with USIM B and then return to the 3GPP system in a network-controlled manner. This study will determine how the network handles MT data or MT control plane activity occurring on suspended connections.

[0063] - A mechanism to avoid paging conflicts in the UE between USIM A and USIM B.

[0064] This background information is provided to disclose information that the applicant deems relevant. It is not required to acknowledge, nor should it be construed, that any of the foregoing information constitutes prior art. Summary of the Invention

[0065] The ATSSS, eNA, and MUSIM operations found in 3GPP offer potential synergies. For example, the PMF feature in ATSSS can be used by the UE to provide data to the NWDAF in the eNA operation for analysis. Additionally, the PMF can help a multi-USIM UE notify the network of another USIM to suspend communication while the UE is communicating with the network of one USIM. Furthermore, new ATSSS guidance modes can be introduced to support analysis-driven guidance or multi-USIM guidance. The following functions are disclosed: 1) enabling the UE to provide UE-specific data to the NWDAF via the user plane using the PMF protocol for analysis; 2) enabling a multi-USIM UE to notify the network via the user plane that the UE wishes to suspend communication with the network associated with one USIM, so that the UE can communicate with the network associated with another USIM; 3) defining new ATSSS guidance modes to support data analysis-driven guidance; and 4) defining new ATSSS guidance modes to support multi-USIM guidance, etc.

[0066] This synopsis is provided to introduce some concepts in a simplified form, which will be further illustrated in the detailed description below. This synopsis is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the deficiencies mentioned in any part of this disclosure. Attached Figure Description

[0067] A more detailed understanding can be obtained by referring to the following explanations with reference to the accompanying drawings:

[0068] Figure 1 A diagram illustrating an exemplary non-roaming 5G system architecture with reference point representation;

[0069] Figure 2 The diagram illustrates an exemplary roaming and non-roaming architecture with localized routing for ATSSS support.

[0070] Figure 3 The diagram illustrates the establishment of a PDU session for an exemplary UE request for roaming and non-roaming with local routing;

[0071] Figure 4 Illustrated explanation of exemplary guidance functions in a UE model;

[0072] Figure 5 Illustrated examples of data collection architectures from any NF;

[0073] Figure 6 Illustrated examples of road trip use cases;

[0074] Figure 7 Illustrated explanation of exemplary NWDAF data analysis based on UE data and other NF data;

[0075] Figure 8A Illustrated explanation of an exemplary registration process;

[0076] Figure 8B Illustrated explanation of an exemplary registration process;

[0077] Figure 9 Illustrated explanation of an exemplary multi-USIM pause request process;

[0078] Figure 10 Illustrated guides for exemplary data analytics-driven approaches;

[0079] Figure 11 Illustrated explanation of exemplary multi-USIM guidance modes;

[0080] Figure 12 Illustrated explanation of an exemplary event-driven data collection strategy structure;

[0081] Figure 13 Illustrated examples of data collection rules and policy configurations based on UE capabilities;

[0082] Figure 14 The illustration shows an exemplary NWDAF-driven UE timer update with a UE configuration update command;

[0083] Figure 15 This diagram illustrates an exemplary UE data collection strategy for delivery using the UE configuration update process;

[0084] Figure 16 Illustrated example GUI;

[0085] Figure 17 The illustration shows an exemplary GUI of a UE application for user privacy and configuration of data collection policies;

[0086] Figure 18A Illustrated example of a communication system;

[0087] Figure 18B Illustrated example systems including the RAN and core network;

[0088] Figure 18C Illustrated example systems including the RAN and core network;

[0089] Figure 18D Illustrated example systems including the RAN and core network;

[0090] Figure 18E Illustrated another example communication system;

[0091] Figure 18F It is a block diagram of an example device or apparatus such as a WTRU;

[0092] Figure 18G This is a block diagram of an exemplary computing system. Detailed Implementation

[0093] Use Case 1

[0094] exist Figure 6 Use cases demonstrating the potential benefits of ATSSS features can be found in the road trip use case illustrated. In this scenario, a family might be traveling to visit their grandparents for vacation. During the commute, children might be watching different videos streaming to their respective phones (e.g., UE 201) using cellular access (e.g., connected to RAN base station 202). When the family arrives at their grandparents' house, UE 201 can switch to using both Wi-Fi access (e.g., connected to wireless LAN (WLAN) base station 203) and cellular access to avoid video interruption. Once inside the home, UE 201 can switch to using only Wi-Fi, but shortly thereafter, congestion may occur on the Wi-Fi network as more devices connect. UE 201 can then transparently and dynamically switch back and forth between RAN base station 202 and WLAN base station 203 to avoid video interruption (e.g., the switching is imperceptible to the user). Through the ATSSS feature, UE 201, one or more WLAN devices, or one or more RAN devices can dynamically monitor network connectivity and determine how best to direct traffic between cellular access (e.g., RAN base station 202) and Wi-Fi access (e.g., WLAN base station 203) to provide a good user experience that meets certain thresholds, such as reduced latency, reduced data bandwidth, or increased connectivity and thus increased connection reliability.

[0095] Use Case 2

[0096] UE 201 data can help the network (e.g., one or more network devices) make decisions to optimize the entire 5G system. For example, UE 201 location data can help identify UE density in various geographic sectors, allowing the network to adjust and optimize resources accordingly. Shared UE capability data from UE 201s allows the network to identify the nature of data and interfaces between UE 201s, enabling efficient data transmission between UE 201s and across the network. Having diverse UE data can help the network identify whether a UE 201 is vulnerable and whether the network can protect it. UE data can also help identify whether a UE 201 poses a threat to the network and mitigate the risk of broader network attacks. Aggregated data from UEs can help the network identify broader issues and user social behaviors, etc. Thus, having UE data helps the network collectively manage UE 201s, enabling the provision of the most efficient and optimal services. Furthermore, data collected from UE 201s can help the network provide value-added services to UE 201s.

[0097] Data-driven security is one of the latest technologies in the field of computer security. It involves data collection from various points within the network and the analysis of that data. Data analysis has proven helpful in identifying network threats, the nature of network attacks, and the degree of risk with significant probability—something that would otherwise be impossible. Therefore, data collection can be a crucial step in identifying potential network risks.

[0098] Figure 7 This diagram illustrates an exemplary system that can be analyzed using NWDAF. Because cyberattacks can occur in unfamiliar ways and can be difficult to detect, data analysis can provide administrators with the possibility of early attack detection. In 5G systems, by leveraging tools such as machine learning (ML) algorithms, rule-based reasoning, or graph-based analysis within NWDAF 205, monitoring events and collecting data from UE 201 and the network, it is possible to effectively detect system cyberattacks and potential cyberattack risks. Some examples of cyberattacks include distributed denial-of-service (DDoS), replay attacks, hijacked UE 201, denial of UE connections, etc. Furthermore, certain UE behaviors (such as the frequency of certain requests, requests for certain services at unusual times, UE sensor data, and corresponding timestamps), or data from NF put together, can provide a holistic consideration of potential vulnerabilities or the risk of future attacks. Figure 7 This illustrates an example where UE 201 (IoT device, mobile phone, etc.) data can be sent to NWDAF 205 for analysis. The data analysis generated by NWDAF 205 can help optimize the entire 5GS, including mitigating cyberattacks.

[0099] NWDAF 205 can be configured to collect information from UE 201 and NF in the network. Additionally, NWDAF 205 can have an algorithm for processing the collected data / information. Based on the results of this algorithm, NWDAF 205 can help identify network attacks and associated risks, the probability of future network attacks, and mitigate the risk of network attacks. Network attack risk indicators can include vulnerabilities in the network, malicious activities, or potential targets in the network. The network can then take appropriate measures to mitigate or prevent network attacks upon risk detection.

[0100] While NWDAF 205 can help identify potential network attacks that a hijacked UE 201 may be launching against the network (e.g., core network 204), NWDAF 205 can also help identify potentially hijacked UE 201s that may be able to launch further, more extensive network attacks.

[0101] As highlighted in the FS_ATSSS_Ph2 study discussed here, many aspects of ATSSS features still need to be addressed. Support for ATSSS defines the PMF protocol used to transmit access network performance measurement results between UE 201 and UPF 206. Currently, only two performance measurements are defined for Rel-16; more measurements can be added to support ATSSS. Additionally, the network's ability to collect data from UE 201 for analysis can be increased. This functionality can be supported by extending the PMF protocol to provide a mechanism for UE 201 to send NWDAF data that can then be analyzed. The PMF protocol can also be used in multi-USIM scenarios, where UE 201 notifies the network (e.g., one or more devices) to suspend communication with UE 201's active USIM for a period of time, allowing UE 201 to switch communication to UE 201's inactive USIM.

[0102] Additional routing modes can be added to those already defined in REL-16. Typically, all defined ATSSS routing modes cannot adapt to constantly changing network or UE conditions. Combined with enhancements to the PMF protocol (where UE201 provides data to NWDAF 205 for analysis), new routing modes can be defined to take advantage of this new capability. NWDAF 205 can then analyze network and UE conditions and adjust traffic routing and offloading between 3GPP and non-3GPP access accordingly. This not only improves the user experience but also optimizes network utilization and threat assessment. Similarly, new routing modes can be defined for multi-USIM scenarios, where traffic from one USIM on one access network can be redirected to another access network used by another USIM. For example, USIM A on UE 201 can utilize 3GPP access, while USIM B simultaneously utilizes non-3GPP access. New routing modes can be created to allow UE 201 to configure the network to dynamically route traffic between the two access networks for different USIMs based on the availability of each access.

[0103] In addition, the Rel-17eNA_Ph2 study [9] and the Rel-16eNA study [7] illustrate, with use cases similar to those discussed above, how to optimize 5G networks using UE data collection in the network and data collection from NF.

[0104] This disclosure describes how to configure rules and policies for a UE to determine what UE-specific data needs to be reported and when to report it for analysis. This disclosure describes how to configure rules and policies for a UE using protocols such as NAS and PMF. Additionally, this disclosure describes how a UE reports UE-specific information that needs to be reported for analysis. This disclosure describes how a UE uses protocols such as NAS and PMF to report UE-specific data.

[0105] like Figure 7 As shown, NWDAF 205 in core network 204 can collect data from UE 201 and perform data analysis. Depending on the type of analysis required by NWDAF 205, it may also require data from other NFs. The results of the analysis can be sent to the OAM system or other NFs. In this scenario, UE 201 needs to be configured with information about which data to collect and send to the network for processing in NWDAF 205. Typically, such a configuration mechanism does not exist in 5G systems.

[0106] Data collection can be scheduled. This ensures that the data to be collected will be available, allowing for the specification of data parameters, collection frequency, batch processing, etc., before collection. On the other hand, data collection can be event-driven. Therefore, different types of data collection rules can trigger UE201 to send different data at different times. Enhanced 5GS needs to address how to trigger data collection on UE201.

[0107] When NWDAF 205 generates analysis results based on UE-driven data, the 5G network may need to take certain actions based on the corresponding events. Actions may simply be notifications to the corresponding NF or forwarding of notifications to UE 205. Furthermore, actions may include system-level actions, such as commands for reassembling UE 201, redirecting or isolating UE 201, slice reconfiguration, etc. 5GS needs to provide NWDAF 205 with a mechanism to take action whenever these events are detected.

[0108] Additionally, core network 204 may need to reconfigure UE 201 (e.g., UE policies, new timers, etc.) based on events detected in NWDAF 205. Current 5GS does not provide such a mechanism.

[0109] The various data collected from UE 201 may need to be restricted in their use to mitigate certain privacy and security risks, such as misuse of data. Furthermore, users may need at least some control over the data collected from their UE 201, for example, accepting or rejecting data collection from the network. Therefore, 5GS may need to provide mechanisms for tagging data and specifying rules regarding data usage controls.

[0110] Potential synergies between ATSSS, eNA, and MUSIM, which are currently under investigation by 3GPP, are provided. For example, the PMF feature in ATSSS can be used by UE 201 to provide data to NWDAF 201 in eNA operation for analysis. Additionally, PMF can help a multi-USIM UE notify another USIM network to suspend communication while UE 201 is communicating with the network of one USIM. Furthermore, new ATSSS guidance modes can be introduced to support analysis-driven guidance or multi-USIM guidance. The following functions are disclosed: 1) enabling UE 201 to provide UE-specific data to NWDAF 205 for analysis using the PMF protocol; 2) enabling a multi-USIM UE 201 to notify the network via the user plane that UE 201 wishes to suspend communication with the network associated with one USIM, so that UE 201 can communicate with the network associated with another USIM; 3) defining new ATSSS guidance modes to support data analysis-driven guidance; or 4) defining new ATSSS guidance modes to support multi-USIM guidance, etc.

[0111] The 3GPP eNA_Ph2[9] study further attempts to investigate the types of information that need to be collected from UE 201, the methods of data collection, and data privacy and utilization. Therefore, this disclosure also discloses the following. A UE configuration mechanism can identify data that can be collected from UE 201 but is not yet available in the core network 204. The configuration mechanism also identifies triggers that enable UE 201 to send data to the core network 204 for analysis. A mechanism is disclosed by which a network entity with data analysis capabilities analyzes data collected from UE 201 and other network functions and generates a data analysis report. Based on this analysis, network functions in the core network 204 can take actions that can indirectly affect UE 201 (e.g., through the reorganization of UE 201), thereby directing UE 201 to different slices, etc. A mechanism is disclosed by which a network entity with data analysis capabilities analyzes data collected from UE 201 and other network functions and generates a data analysis report. Based on this analysis, network functions in core network 204 can take actions that directly affect UE 201, for example, through UE configuration update commands. Several aspects of managing UE data privacy and mechanisms for controlling the use of data collected from UE 201 are disclosed.

[0112] In a first exemplary implementation (also referred to herein as Concept 1), UE 201 may use the PMF protocol to provide data for analysis purposes. UE 201 may include an analysis reporting capability indicator in a request message to the network; the network may generate a data analysis collection policy; the network may return the data analysis collection policy in a response to UE 201; and UE 201 may use the PMF protocol to report data for analysis purposes.

[0113] This document discloses supporting features for a first exemplary implementation (e.g., Concept 1). For the first feature, the request message may be a registration request or a PDU session establishment request message. For the second feature, if UE 201 does not indicate an analytics reporting capability indicator in the request message, the network may prompt UE 201 in its response to the request whether it supports analytics reporting capabilities. For the third feature, the network may use local policies or subscribed data to create a data analytics collection policy. For the fourth feature, the network may contact analytics functions used for information to create a data analytics collection policy. For the fifth feature, the data analytics collection policy may include rules describing what data UE 201 should provide for analytics, how often UE 201 may need to provide data, contact information for the network nodes to which the data should be sent, data analytics identifiers to be included when sending data, or the validity period of the data analytics collection policy.

[0114] In a second exemplary embodiment, UE 201 can request the network to suspend and halt communication of the first USIM via the user plane. UE 201 can send a suspension request to the user plane function of the CN; this request can be forwarded to the session management entity or the mobility management function; the mobility management function can determine whether to enable communication suspension and return session information of other UE sessions affected by the suspension to the session management entity; the session management entity can notify the user plane function of the suspension of the session associated with UE 201; and the user plane function returns the status of the suspension request to UE 201.

[0115] This document discloses exemplary supporting features for a second exemplary implementation. For the first feature, a pause request can be sent using the PMF protocol. For the second feature, the pause request can include one or more of the following: the duration of the pause, a list of PDU sessions associated with UE 201, a list of paging reasons to be ignored during the suspension, a list of paging reasons for paging UE 201 during the suspension, or a request to buffer future downlink data. For the third feature, a suspension indication can be added to the UE context maintained by the mobility management function. For the fourth feature, a suspension timer can be enabled to indicate the duration of the suspension. For the fifth feature, a registration timer can be suspended during the suspension. For the sixth feature, a suspension can be applied to one or more PDU sessions associated with UE 201. For the seventh feature, the network can buffer data for UE 201. For the eighth feature, the connection state of UE 201 can be set to idle in both the mobility management function and UE 201.

[0116] In a third exemplary embodiment, a data analytics-driven redirection mode may exist. UE 201 may notify the core network 204 that UE 201 can support providing data for analytics and has traffic redirection capabilities; the core network 204 may generate and return a data analytics report policy to UE 201; UE 201 may dynamically redirect UL traffic between 3GPP access and non-3GPP access based on performance measurement results obtained by UE 201; and the network may dynamically redirect DL traffic to UE 201 between 3GPP access and non-3GPP access based on analytics information provided by the analytics function.

[0117] This document discloses exemplary support features for a third exemplary implementation. For a first feature, UE 201 may send a data analytics capability indication to core network 204 to indicate support for providing data for analytics. For a second feature, the data analytics capability indication may be included in an MA or a separate PDU session establishment request. For a third feature, analytics-driven indicators or guidance patterns are specified as information elements in Multi-Access Rules (MAR) and ATSSS rules. For a fourth feature, traffic guidance involves sending data traffic to 3GPP access, non-3GPP access, or both. For a fifth feature, UE 201 performance measurements may include one or more of the following: received signal strength, UL data bit rate, UL data latency, UL retransmission count, access availability, mobility mode, MOS, or battery level. For a sixth feature, analytics information can be derived from data provided by UE 201, such as received signal strength, Wi-Fi network measurements, signal-to-noise ratio and interference, DL data bit rate, DL data latency, access availability, mobility mode, mobility type, battery level, connection failure count, or location.

[0118] In a fourth exemplary embodiment, a multi-USIM-driven routing pattern is disclosed herein. UE 201 creates a PDU session for a first USIM via a first access network. This PDU session has a multi-USIM indicator (e.g., an indication to the core network that the UE has multi-SIM capability. Based on this knowledge, the network can enhance certain processes to account for UEs with multiple USIMs) and a temporary identifier for a second USIM (e.g., a temporary identifier used to identify the UE's subscription associated with the USIM. The temporary identifier can be changed periodically, hence it is "temporary"). UE 201 creates a PDU session for a second USIM via a second access network. This PDU session has a multi-USIM indicator, a temporary identifier for the first USIM, and an optional PDU session identifier associated with the first USIM. Depending on access network availability, the network routes data traffic for the first USIM to the access network of the second USIM, and vice versa. And depending on access network availability, UE 201 routes data traffic for the first USIM to the access network of the second USIM, and vice versa. Note that when a UE creates a PDU session, the UE sends a message to the core network through the base station, and the core network returns a response indicating whether the PDU session has been successfully established. Also note that the PDU session ID is associated with the established PDU session.

[0119] This document discloses supporting features for a fourth exemplary implementation. For the first feature, a multi-USIM guidance mode is added to the guidance rules in both UE 201 and UPF. For the second feature, the guidance rules are the ATSSS rule of UE 201 and the multi-access rule of UPF. For the third feature, the PDU session is either an MA PDU session or a separate PDU session. For the fourth feature, the first and second PDU sessions are linked together. For the fifth feature, the first and second PDU session IDs are the same.

[0120] In the fifth exemplary embodiment, UE 201 can identify data parameters and collect UE 201 data based on UE data collection rules and policies received from the network or configured locally. UE 201 can send the collected data to the network based on triggers specified by the configured UE data collection rules and policies.

[0121] Supporting features that can be built for the fifth exemplary implementation may include the following: For the first feature, UE data collection rules and policies may be pre-configured in UE 201 or delivered to UE 201 via the network. For the second feature, data collection rules may be on-demand, and may include scheduled data collection from UE 201. For the third feature, data requests may originate from the network without scheduling. For the fourth feature, data collection policies may be event-based. For the fifth feature, data may be collected, held, and delivered to the network after a trigger. For the sixth feature, data may be collected, stored, and sent to the network only when UE 201 is out of coverage and when UE 201 returns to coverage. For the seventh feature, when UE 201 leaves coverage, UE 201 may continue to collect data under constraints such as data priority, time limits, and storage limits. For the eighth feature, data collection from UE 201 may be based on the UE's data collection capabilities shared with the network.

[0122] In the sixth exemplary embodiment, a network entity may send the data analysis results to other network entities in the network, and the other network entities may take action based on the received analysis, which may indirectly affect UE 201.

[0123] Supporting features that can be constructed for the sixth exemplary implementation may include the following. For the first feature, the actions taken by the network may be internal changes within the network. For the second feature, internal actions taken by network entities may affect UE 201 due to changes in entities that UE 201 may depend on.

[0124] In the seventh exemplary embodiment, a network entity can send the data analysis results to other network entities in the network, and other network entities can take actions based on the received analysis, which may directly affect UE 201.

[0125] Supporting features that can be built for the seventh exemplary implementation may include the following. For the first feature, the data analysis report can influence UE 201 through changes to UE data collection rules and policies. For the second feature, the data analysis report can influence UE 201 via configuration policy updates, registration updates, etc., caused by other network entities subscribing to the data analysis report.

[0126] In the eighth exemplary embodiment, UE 201 may provide options regarding whether to discard or allow UE data collection from UE 201. UE 201 may limit the UE data to be sent to the network. UE 201 may be compatible with the network in terms of data collection, data delivery, or data utilization. Support features that may be built for the eighth exemplary embodiment may include the following: For a first feature, UE 201 may limit the collected data by preprocessing the data before sending it to the network. For a second feature, UE 201 may limit the data based on which sector of UE 201 the data originates from. For a third feature, UE 201 may allow data to be discarded or allowed to be collected from UE 201 via a GUI.

[0127] PMF protocol enhancement

[0128] The following disclosed PMF protocol enhancement extends UE 201 to CN communications. In the first enhancement, UE 201 uses the PMF protocol to provide NWDAF 205 with information that can be used for analysis. In other words, UE 201 can use the network's user plane to provide NWDAF 205 with UE-specific information for analysis. Some information from UE 201 can be considered as supplementing information about UE 201 that NWDAF 205 has already collected from other NFs in the cellular system, while other information is UE-specific and can only be provided by UE 201. As a result, UE information can be used to verify predictions currently made by NWDAF 205, or it can be used to provide a more complete analysis of the operation of the entire system. This analysis can be broad and take into account several parties of interest, ranging from network functions such as AMF 208, SMF 207, PCF 209, and UPF 206 to the UE or UE group.

[0129] The second enhancement allows a multi-USIM UE 201 to notify the network using the first USIM that it needs to suspend communication with the network, so that UE 201 can communicate with the network of the second USIM. When UE 201 uses the second USIM to communicate, it may be communicating with the same network or a different network. In other words, the other network can be the same network as the first USIM or a different network associated with the second USIM. The multi-USIM UE 201 sends a suspension request to the PMF within the UPF via the user plane, indicating that UE 201 wants to temporarily suspend communication with the network. The PMF forwards the request to the SMF, which in turn forwards the request to the AMF serving UE 201, enabling the temporary suspension of communication with UE 201. Note that the PMF is represented as a logical entity residing within UPF 206, although the PMF can be located separately from UPF 206. For example, a PMF can be aggregated with multiple UPFs in a network slice. Hereinafter, PMF and UPF 206 can be used interchangeably in the context of the PMF protocol.

[0130] Enhancement of NWDAF

[0131] As previously mentioned, the PMF protocol introduced for ATSSS features provides a mechanism for both UE 201 and UPF 206 to obtain performance measurements for traffic redirection, handover, or offloading. To further leverage this capability, the protocol can be extended to include a set of UE information that can be used by NWDAF 205 for analysis purposes. To achieve this, UE 201 can indicate its support for collecting data for analysis purposes when registering with core network 204, in turn, core network 204 provides UE 201 with data analysis collection policies. UE 201, using these policies, can then be triggered to send the collected data to the PMF using the PMF protocol. Triggering can be periodic in nature or event-driven, such as based on mobility or handover events. NWDAF 205 can retrieve data from the PMF (or UPF 206) using a service-based interface. This process will be illustrated in the example below.

[0132] Figures 8A-8B (Also referred to herein as Figure 8) illustrates the general registration process in TS 23.502[2]. This registration process is enhanced to allow UE 201 to convey its support for providing data for analysis purposes in a registration request message. Alternatively, the CN may prompt UE 201 in a registration acceptance response to determine whether UE 201 supports providing data for analysis purposes. UE 201 may respond in a registration completion message with an indication that UE 201 supports providing data for analysis purposes.

[0133] refer to Figures 8A-8B The following enhancements are disclosed to enable UE 201 to receive data analysis collection strategies. Figure 8A In step 1, UE 201 includes an analytics reporting capability indicator in its registration request to notify core network 204 that UE 201 can provide data to NWDAF 205 for analytics purposes. This could also mean that UE 201 supports providing data to the PMF using the PMF protocol. Figure 8A In step 3, the registration request is forwarded to AMF 208. In step 16 of Figure 8, when establishing AM policy association for UE 201, AMF 208 includes an analytics reporting capability indicator for the PCF. This indicator is sent along with other information from the Npcf_AMPolicyControl_Create request. PCF 209 uses information from local policies or subscription data to generate a data analytics collection policy suitable for UE 201. The data analytics collection policy may contain rules describing what data UE 201 should provide for analytics, how often UE 201 needs to provide data, contact information for the PMF to which the data should be sent, data analytics identifiers to be included when sending data, or the validity period of the data analytics collection policy. PCF 209 may have already been provided with such information, or PCF 209 may have communicated with NWDAF 205 to obtain such information. Alternatively, PCF may provide data analytics reporting information to AMF 208, and then AMF 208 derives the data analytics collection policy from the information provided by PCF. AMF 208 can also communicate with NWDAF 205 to obtain information for data analysis collection strategies, such as contact information for the PMF to which data is to be sent and data analysis identifiers.

[0134] about Figures 8A-8B As an additional enhancement, in step 21 of Figure 8, the data analysis collection strategy is returned to UE 201 in the registration acceptance message. If UE 201... Figure 8AIn step 1, if the analytics reporting capability indicator is not included, AMF 208 can prompt UE 201 in the registration acceptance message whether it wants to provide analytics data for NWDAF 205. This prompt can be achieved by including the analytics reporting capability indicator. In step 22, if UE 201 is prompted by AMF 208 to enable analytics reporting and UE 201 accepts, UE 201 returns the analytics reporting capability indicator to AMF 208 in the registration completion message. Upon receiving the analytics reporting capability indicator, AMF 208 can trigger the execution of the UE configuration update procedure for transparent UE policy delivery to generate and send a data analytics collection policy to UE 201. After receiving the data analytics collection policy, UE 201 will collect the required data specified by the policy and send them to the PMF at a specified frequency using the PMF protocol.

[0135] To enable PCF 209, SMF, or another NF to obtain the necessary information to generate a data analytics collection policy for UE 201, support for additional operations has been disclosed to be added to the NWDAF service already supplied to the NF. Table 1 shows the existing NF services provided by NWDAF 205, as well as the newly disclosed service Nnwdaf_AnalyticsPolicyInfo, listed in bold. This new service enables NFs such as PCF 209 or AMF 208 to request information from NWDAF 205 for generating a data analytics collection policy for UE 201. In other words, this service can be used to query NWDAF 205 for the type of analysis that NWDAF 205 is interested in for a given combination of UEs, UE groups, slices, or information elements. The requested output can even be the data analytics collection policy itself, which the requesting NF can then forward to UE 201.

[0136]

[0137]

[0138] The following describes the exemplary Nnwdaf_AnalyticsPolicylnfo service operation in more detail.

[0139] • Service operation name: Nnwdaf_AnalyticsPolicylnfo_Request.

[0140] • Description: Requests information needed to generate a data allocation collection strategy for UE 201.

[0141] • Input, required: UE 201 (e.g., SUPI) or group identifier.

[0142] • Input, optional: Service AMF or NF ID, list of recently visited areas (TAI or cell ID), S-NSSAI.

[0143] • Output, required: Data analysis strategy ID, set of tuples (analysis ID, analysis-specific parameters, reporting frequency, reporting event, association ID), and target address of the PMF receiving the UE data.

[0144] • Output, optional: policy validity period, (one or more) region IDs.

[0145] 3GPP TS 23.288, Architecture enhancements for 5G System (5GS) to support network data analytics services; V16.1.0 (2019-09) (hereinafter referred to as [4]) describes a list of analytics IDs provided by NWDAF 205 to its consumers. The data for these analyses can be collected from NF or OAM entities in the system, and the output can be in the form of statistics or predictions. In the case where NWDAF 205 provides predictions, there is a lack of validation of the NWDAF predictions. Therefore, the data collected from UE 201 can be considered as supplement to these predictions, which affects the analysis of UE 201 (such as UE mobility, UE communication, etc.). As a result, NWDAF 205 can use the information provided by UE 201 as feedback to evaluate the overall effectiveness of its analytics outputs or system configuration.

[0146] While UE 201 can utilize some of the existing analytics IDs defined in [4] to report data to NWDAF 205, it may be advantageous to group UE-specific information into new, separate analytics IDs. This simplifies the reporting structure of UE 201 and minimizes the number of subscription requests required by NWDAF 205. Table 2 shows an example list of data elements that UE 201 can provide to NWDAF 205 when reporting data for analytics. Some information comes from other analytics IDs found in [4], while other information is UE-specific and new information that only UE 201 can provide. This information can be grouped into separate analytics IDs that NWDAF 205 configures in UE 201 via a data analytics collection strategy and are also used to subscribe to PMFs within the UPF to collect data from UE 201.

[0147]

[0148]

[0149] Using the analytics reporting capability indicator in the registration request is one way for UE 201 to notify core network 204 that it supports sending data for analytics. This method provides a mechanism where data can be collected for some or all PDU sessions associated with the UE's registration to provide information to NWDAF regarding the data to be used for analytics. The data analytics collection strategy may require UE 201 to collect data on: mobility scenarios, handover scenarios, 3GPP access and (vs) non-3GPP access connection percentages, received network bandwidth, received network latency, received signal strength, etc.

[0150] Alternatively, UE 201 can be used as follows: Figure 3 The PDU session establishment process (steps 1-21) shown includes sending an analysis report capability indicator. In this scenario, UE 201 can include the analysis report capability indicator in the PDU session establishment request or when modifying the PDU session. In this case, SMF 207 will receive the indicator, and when it communicates with PCF 209, for example in... Figure 3 In step 7b, the data analysis collection strategy can be generated by PCF 209 and returned to SMF 207. Alternatively, after SMF 207 obtains the data analysis collection information from PCF, SMF 207 can... Figure 3 Following step 9 or 10b, a data analysis collection policy is generated. This policy is then returned to UE 201 in the PDU session establishment acceptance response. Alternatively, an analysis reporting capability indicator can be integrated into the MA PDU session establishment process. In this case, the data analysis collection policy can be part of the measurement support information returned to UE 201. The PDU session establishment acceptance response can include an indication that UE 201 should send analysis information in the PDU session, or the presence of a data analysis collection policy in the PDU session establishment acceptance response can be an indication that UE 201 should send analysis information in the PDU session.

[0151] As an alternative to introducing a new service operation within NWDAF 205 to provide information for data analytics collection policies, PCF 209 can be enhanced to provide this information. PCF 209 can obtain this information from operator policies, local configuration, or externally via NEF through OAM or AF. PCF 209 can provide the data analytics collection policy to AMF 208 or SMF 207 during the corresponding policy association establishment / modification steps in the registration process or PDU session. The data analytics collection policy is then returned to UE 201 in the corresponding response to these processes.

[0152] The target address found in the output of the Nnwdaf_AnalyticsPolicyylnfo request or in the data analysis collection policy can be the address of the PMF within a specific UPF 206. Note that if the data analysis collection policy is sent as part of the Measurement Auxiliary Information (MAI) returned to UE 201 for the MA PDU session procedure, the PMF's IP address is already included as part of the MAI. The configuration of the PMF address in the data analysis collection policy can be specified as the PMF within UPF 206 responsible for associated PDU sessions. For example, UE 201 can send data analysis reports to the PMF(s) within UPF 206 that manage PDU sessions for UE 201 on one or more user plane tunnels. However, if UE 201 has multiple PDU sessions on different UPFs, each with its own PMF, this can separate data collection across multiple UPFs and require NWDAF 205 to subscribe to multiple UPFs to obtain data from UE 201. As an alternative to enabling PMFs within multiple UPFs to collect UE data for analysis, a target address can be specified in the data analysis reporting policy, allowing UE 201 to report to a single PMF when sending data for analysis. This can be achieved when a single PMF handles data collection from multiple UPFs within the same network slice. PCF 209 or SMF 207 may have already been provided with the PMF address within the network slice as part of the network configuration or policy. NWDAF 205 can also provide this address to other NFs in the response to an Nnwdaf_AnalyticsPolicyylnfo request.

[0153] It's also possible that operator policies identify one or more PMFs acting as anchor PMFs, which are used to store data analytics reports from UEs in the system. In this scenario, the address of the anchor PMF can be provided to the NF via operator policy or via the OAM system. One reason for having a dedicated anchor PMF is that the UPF needs to implement the PMF internally to handle PMF protocol signaling from the UE. Thus, some UPFs can be deployed with the PMF, eliminating the need for other UPFs to implement the PMF. Another reason for having a separate anchor PMF is that metrics collected through the user plane will not be distorted by the presence of the PMF that receives data analytics reports from the UE.

[0154] Enhancement of multiple USIM UEs

[0155] In the dual-USIM scenario, the operation of the multi-USIM UE 201 with single Rx and single Tx capabilities requires the UE to communicate via time division multiplexing (TDM) between USIM A and USIM B. Therefore, the dual-USIM UE 201 can be configured with periodic service gaps to allow for communication handover between the USIM networks. Figure 9 An exemplary method flow is illustrated, in which a dual-USIM UE 201 may initially receive downlink data for USIM A, and then, during a service interval, UE 201 receives a paging request for USIM B. This paging may include a paging reason that causes UE 201 to decide to switch to using USIM B. Then, during another service interval or in response to a user request, UE 201 notifies the network of USIM A via the PMF protocol in the user plane to temporarily suspend communication with UE 201. The suspension request is then forwarded to SMF 207 and ultimately to AMF 208, where the UE context is updated, thus suspending future communication with UE 201 until UE 201 resumes communication with the network of USIM A. The disclosed enhancement allows a multi-USIM UE 201 to initiate a suspension of communication with the network of a USIM using the user plane in order to connect to the network of another USIM. In this case, the networks of the USIMs can be the same or different network operators. Reference Figure 9 In step 211: For USIM A, UE 201 may be in the CM_CONNECTED state and may currently be receiving downlink data. For USIM B, UE 201 may be in the CM_IDLE state. In step 212, during a service gap for USIM B, UE 201 monitors and receives paging associated with USIM B. UE 201 retrieves the paging reason associated with the paging and determines that it wants to switch to using USIM B. The paging reason may indicate the service that the user of UE 201 is interested in. In step 213, during a service gap for USIM A or when the user of UE 201 prompts UE 201 to switch SIMs (e.g., via GUI), UE 201 issues a request to suspend downlink data via the PMF protocol in the user plane. This request means that UE 201 intends to suspend network-associated activities with USIM A and may include a list of PDU sessions to be suspended. The request may include the length of time that UE 201 may be requesting to suspend its operations with USIM A. The request may also include information regarding which paging reasons are important to UE 201 for USIM A, thus enabling paging of UE 201 during the pause. Alternatively, UE 201 may request to suspend all paging regardless of the paging reason for the duration of the pause. This paging filter may be a whitelist or blacklist of paging reasons. UE 201 may also request to buffer all new mobile-terminated data until UE 201 returns and makes a service or recovery request to re-establish communication.

[0156] Continue to refer to Figure 9In step 214: UPF 206 forwards a suspension notification to SMF 207 to notify SMF 207 of the UE's request. This notification includes the information provided by UE 201 in step 213, as well as the PDU session ID and other context information that UPF has for UE 201. In step 215: SMF 207 forwards a suspension notification to AMF 208, which contains the information provided by UE 201 in step 213 and from UPF in step 214. SMF 207 may also include other information, such as the UE's SM context ID for the current PDU session ID or other PDU session IDs associated with UE 201. In step 216, AMF 208 updates the UE context maintained internally by AMF 208 to suspend the UE's CM state while maintaining the UE's registered state, such as being in the RM_REGISTERED state. In other words, communication with UE 201 is temporarily suspended until UE 201 resumes communication with core network 204 by making a service request or recovery request. For example, the suspension indication can be associated with the UE's context in AMF 208. AMF 208 can also implement the association of a timer for the suspension's validity period if the UE does not promptly resume communication with the network. AMF 208 can use a time provided by UE 201 or some other value that may come from network configuration or policy for the validity period timer. If necessary, AMF 208 updates the UE's CM state to CM_IDLE, or it can suspend UE 201's registration update timer. AMF 208 returns an acknowledgment to SMF 207, which may include: whether the suspension is activated, the validity period maintained by AMF 208 for the suspension, whether SMF 207 or UPF 206 should buffer data for UE 201, and for which PDU session of UE 201 to buffer data, etc.

[0157] refer to Figure 9In step 217, SMF 207 receives an acknowledgment from AMF 208. If suspend is activated, SMF 207 can also update the SM context it maintains for UE 201 and enable data buffering for UE 201's PDU sessions belonging to UE 201 with which AMF 208 has instructed SMF 207 to buffer data. It can also contact other UPFs with which UE 201 may have PDU sessions and, if AMF 208 has instructed UPFs to buffer data for UE 201, notify them to buffer any future data when suspend is activated. SMF 207 can provide these UPFs with the time provided by AMF 208 to indicate how long to buffer data. SMF 207 returns a pause notification to the requesting UPF, which includes the status of the pause request from AMF 208, the duration of the pause, whether UPF 206 should buffer data for UE 201, the pause and buffering status of other PDU sessions associated with UE 201, and so on. In step 208, UPF 206 notes whether buffering is enabled and when it was activated, so it can buffer any downlink data for UE 201 if requested. UPF 206 then returns a pause acceptance response to UE 201, which includes information about the status of the pause request, the duration of the pause, whether data buffering is enabled and for which PDU session IDs, and other information from the responses of both AMF 208 and SMF 207. At this point, UE 201 can release any RRC signaling with the network and switch operations to the USIM B network. The RAN node can also automatically release RRC signaling to save signaling overhead between UE 201 and the RAN node, so that UE 201 does not need to explicitly release the RRC connection.

[0158] When UE 201 is ready to return to using USIM A, UE 201 can perform the process of PLMN selection, cell (re)selection, and RRC connection establishment with RAN node 202 associated with USIM A before sending a service request procedure to core network 204 to restore operation with the network. The service request will cause AMF 208 to send a notification to SMF 207 that the connection can be restored. The notification to SMF 207 will cause SMF 207 to send a notification to UPF that the connection can be restored, and any buffered data can be sent to UE 201. Alternatively, UE 201 can restore the connection by sending a restoration request to PMF. Then, UPF 206 can notify SMF 207 that the connection has been restored, and SMF 207 can notify AMF 208 that the connection has been restored.

[0159] The recovery request will be similar to Figure 9 The pause request shown will be processed, and will follow the same steps as steps 213-218, but will resume rather than suspend communication with the network. The UE context within UPF 206, SMF207, and AMF 208 will (where appropriate) disable the pause, any validity timers used for the pause will be disabled, buffered data will be sent to UE201, the registration update timer will be re-enabled, the UE's CM state will transition to CM-CONNECTED, and so on.

[0160] ATSSS Guided Mode

[0161] The 3GPP FS_ATSSS_Ph2 SID has confirmed that additional defined orientation modes are possible besides those already defined in Rel-16. The operation of existing orientation modes depends on two defined performance measurements: availability report and round-trip time. However, based on data analysis provided by NWDAF 205, a more dynamic orientation mode can be introduced. This new orientation mode can adapt to changing network and UE conditions and provides more dynamic orientation capabilities than existing modes.

[0162] In addition to the data analytics-driven redirection mode, another redirection mode can be introduced to leverage multiple accesses in multi-USIM use cases. This new redirection mode can be configured where one USIM is used to connect to a 3GPP access network (e.g., gNode-B 180a), while another USIM is used to connect to a non-3GPP access network (e.g., non-3GPP access point 180c). This redirection mode can then instruct the UPF to redirect data traffic for UE 201 from an unavailable access network to another access network with which UE 201 can actively communicate. Furthermore, this new redirection mode can also be supported when the multi-USIM UE 201 is connected to multiple 3GPP RATs, such as simultaneously between 5G systems or between 5G and LTE systems that support ATSSS through mutual cooperation. In one scenario, the UE performs time-division multiplexing (TDM) operation between one USIM on a 5G system and another USIM on the same or different 5G systems.

[0163] Data analytics-driven orientation

[0164] By leveraging publicly available UE-driven analytics capabilities, new traffic redirection patterns can be supported, autonomously redirecting, switching, or offloading traffic based on analytics generated by NWDAF 205. NWDAF 205 can combine data from NFs and UE 201 for analysis, providing a holistic approach to traffic redirection. The UE can provide feedback to NWDAF 205 on the analytics generated based on data collected from various NFs. The resulting analytics can represent both system status and UE QoS experience to optimize traffic redirection, making it beneficial to both the network and UE 201. On one hand, system resources are optimized to balance traffic load in the network; on the other hand, the user experience of UE 201 is maintained or improved due to the automatic selection of optimal access for traffic redirection.

[0165] UE 201 can influence the selection of this new redirection mode by providing a previously disclosed analytics reporting capability indicator during the MA PDU session establishment process. This indicator can signal to SMF 207 to generate MAR rules to include the newly disclosed “analysis-driven” or “dynamic” redirection mode for more dynamic traffic redirection or offloading. Table 3 shows an example of using this new redirection mode for Multi-Access Rules (MAR), where the analytics-driven redirection mode instructs UPF 206 to use analytics from NWDAF 205 to help redirect traffic via 3GPP or non-3GPP access. NWDAF 205 can even provide weights for the MAR offloading percentage based on its analytics results.

[0166]

[0167]

[0168]

[0169] For the analytics-driven routing mode disclosed in Table 3, the initial traffic offloading can be set to the default 50-50 offloading. Then, when analytics data becomes available, traffic offloading can be determined by NWDAF 205 based on the analytics data. NWDAF 205 can present the analytics data as the percentage of traffic offloaded between 3GPP access and non-3GPP access to UPF 206. Within the structure of the MAR rule, the offloading percentage can be specified for each access as the weight for forwarding actions. Alternatively, UPF can determine the offloading percentage based on analytics provided by NWDAF 205 or performance measurements obtained by UPF 206.

[0170] Similarly, when establishing or modifying an MA PDU session, if SMF 207 creates an ATSSS rule with an analytics-driven guided mode as shown in Table 4, UE 201 can utilize this guided mode. In this case, UE 201 uses the data from its UL retransmissions, possibly along with the signal strength of the access network, and other metrics to adjust traffic offloading between 3GPP access and non-3GPP access. Some of the data in Table 2 can be used by UE 201 for this purpose. UE 201 can adapt the offloading percentage to changing network or UE conditions, such as lower received signal strength, UE mobility, or battery level.

[0171]

[0172]

[0173] By using these analytics-driven routing patterns, UE 201 and UPF 206 can dynamically and promptly route traffic to the best available access network in any given situation, and adjust traffic routing to account for changes in the access network or conditions within UE 201. As a result, traffic routing is optimally adjusted according to constantly changing network and UE conditions.

[0174] To provide this data analytics-driven guidance, NWDAF 205 can collect data from UE 201 as previously disclosed for PMF protocol enhancements. NWDAF 205 can use the data from UE 201 to generate an analytical prediction confidence level for the analytics ID associated with UE 201. Then, by using network performance and system load metrics, NWDAF 205 can subsequently allocate a traffic offloading percentage between 3GPP access and non-3GPP access. NWDAF 205 can adjust the offloading percentage accordingly as system conditions change. UE 201 or UPF 206 can use rules or formulas to determine which access a packet or flow should use. NWDAF 205 can send the rules to UPF 206 via SMF 207, or the rules can be provided as operator policies from another NF, or configured locally. NWDAF 205 can send the rules as ATSSS rules to UE 201 via SMF 207 and NAS message handling. The input to the rules can be measurement data. NWDAF 205 can update rules when network conditions change.

[0175] To further illustrate this method, such as... Figure 10An example is provided. This example shows the NWDAF205 receiving data from UE 201 and adjusting the offloading percentage between 3GPP (RAN) access and non-3GPP (WLAN) access; the same procedure can be used to adjust offloading, redirection, or handover criteria. Reference Figure 10 In step 221: UE 201 has received a data analysis collection policy according to one of the methods proposed in this disclosure. Based on this policy, UE 201 periodically provides data to the PMF within UPF 206, and the PMF then notifies NWDAF 205. It is assumed that NWDAF 205 subscribes to the PMF to be informed of the data collected from UE 201. Additionally, UE 201 can be configured to report data due to certain events (such as connection loss, reduced service experience or QoS, or mobility-based events). In step 222: NWDAF 205 provides the PMF with a percentage of traffic split between 3GPP access and non-3GPP access. In this case, the UE data from step 221 indicates that Wi-Fi (e.g., WLAN 203) is available and has good receive bandwidth. As a result, as an example, NWDAF 205 supplies the following percentages: 20% for 3GPP access and 80% for non-3GPP access. As an alternative, NWDAF 205 can provide data to UPF 206 for evaluation using rules or guidelines previously provided by NWDAF 205 to UPF 206. In steps 223a and 223b: UPF 206 offloads traffic to UE 201 based on the percentage specified by NWDAF 205 or based on the results of the evaluation rules or guidelines.

[0176] Continue to refer to Figure 10In step 224: After a period of time, the Wi-Fi network becomes congested as more users connect to it. This could happen, for example, in a coffee shop where there are initially only a few users. Then, as time goes on, more users arrive and connect to the Wi-Fi network. UE 201 experiences service degradation and notices the Wi-Fi network congestion based on its current receive bandwidth. In step 225: UE 201 can be configured to report events that affect the service experience and thus send data to UPF 206 via the PMF protocol. The data sent can be packaged into a single analytics ID as disclosed in Table 2, or the data can be categorized according to the analytics IDs defined in [4]. When using the disclosed analytics IDs, UE 201 can provide the available data in Table 2. Not all the data in Table 2 needs to be available before sending a report to the PMF. In step 226: UPF 206 notifies NWDAF 205 of the new data from UE 201. In step 227: Based on data from UE 201, NWDAF 205 adjusts the traffic offloading percentage to divert some traffic from non-3GPP access to 3GPP access. In this case, NWDAF 205 sets the offloading percentage to, for example, 70% for 3GPP access and 30% for non-3GPP access. Alternatively, NWDAF 205 can provide data to UPF 206 for evaluation using rules or guidelines provided by NWDAF 205. In steps 228a and 228b: UPF 206 offloads traffic to UE 201 based on the new percentage specified by NWDAF 205 or based on the evaluation results of rules or guidelines provided by NWDAF 205.

[0177] When UE 201 leaves the coffee shop and then UE 201 sends a report to PMF that non-3GPP access is no longer available, Figure 10 The illustrated use case can be further extended. The NWDAF 205 will then receive a notification and adjust the routing percentage so that 100% of the traffic is routed via 3GPP access routes and 0% of the traffic is routed via non-3GPP access routes.

[0178] Multiple USIM guidance

[0179] An alternative ATSSS redirection mode can be defined to support multi-USIM UEs connecting to both 3GPP and non-3GPP access points, or between two 3GPP access points, such as between two 5G access points, using time-demultiplexed connections. This new redirection mode may require the multi-USIM UE 201 to register one USIM to a 3GPP access point and another USIM to a non-3GPP (or another 3GPP) access point. Then, a PDU session can be created using the MA PDU session establishment procedure across both the 3GPP and non-3GPP (or another 3GPP) access points, triggering the creation of ATSSS rules with the new redirection mode by adding a multi-USIM indicator. In the case of two 3GPP access points, two independent PDU session establishment procedures can be performed in their respective systems, using the multi-USIM indicator to enable the new redirection mode. For PDU sessions belonging to different USIMs, this new redirection mode can instruct the network to redirect traffic from an unavailable access point to another available access point. This new guidance mode can be applied to scenarios where USIMs originate from multiple USIMs within the same MNO with intra-MNO coordination, as well as scenarios where USIMs originate from multiple USIMs within different MNOs with inter-MNO coordination. This new guidance mode can also be utilized in scenarios where UE 201 communicates with the PLMN and SNPN to provide seamless communication between the PLMN and SNPN.

[0180] use Figure 3 Referring to the MA PDU session establishment procedure in [2], the following enhancements are disclosed to enable a new guidance mode for multi-USIM UEs. For scenarios where the new guidance mode is only applied to 3GPP RATs, the MA PDU session procedure is replaced by a separate PDU session establishment procedure. Regarding Figure 3 In step 1, UE 201 provides a 3-tuple in the MA PDU session establishment request, consisting of a multiple USIM indicator, a temporary identifier for another USIM, and a PDU session ID. If UE 201 has not yet created a PDU session for that USIM, the PDU session ID for the other USIM can be empty. Figure 3Step 3: AMF 208 notifies SMF 207 that the request is for an MA PDU session and includes a multiple USIM indicator and the PDU session ID of another USIM (if available). In a standalone PDU session scenario, the MA PDU indicator may not be included. AMF 208 may have been informed by UE 201 during the registration process that the two USIMs are linked together. Therefore, the UE context maintained by AMF 208 will indicate that the MA PDU session may include the PDU session ID of any one USIM. Additionally, authentication and authorization procedures have been performed to enable the creation of PDU sessions between USIMs. Figure 3 In step 7, SMF 207 sends an "MA PDU Request" instruction and a multi-USIM instruction to the PCF in the SM Policy Control Creation message. The PCF determines whether to allow an MA PDU session based on operator policy or subscription data. In standalone PDU session scenarios, the MA PDU session is replaced by a single PDU session. Additionally, the PCF includes Policy Charging and Control (PCC) rules with ATSSS information containing a new guidance pattern for multi-USIM. SMF 207 derives both ATSSS and MAR rules to incorporate this new multi-USIM guidance pattern.

[0181] exist Figure 3 In the remaining steps, SMF 207 establishes user plane resources via 3GPP access (e.g., access via sending a PDU session establishment request). The N4 rule sent to UPF 206 includes the new redirection mode "Multi-USIM" or "MUSIM" in a Multi-Access Rule (MAR) with appropriate CN tunneling information to redirect data packets to the corresponding access network, whether 3GPP or non-3GPP (or another 3GPP RAT). Similarly, the ATSSS rule includes the "Multi-USIM" or "MUSIM" redirection mode in the acceptance response and sends it to UE 201. The acceptance response may also include the same PDU session ID of another USIM that will be used as the PDU session ID of the current USIM. This links the PDU sessions together.

[0182] Figure 11An example procedure is shown for a multi-USIM UE 201 that interacts with core network 204 to utilize a multi-USIM-oriented mode between 3GPP access (RAN 202) and non-3GPP access (WLAN 203). In step 231: Multi-USIM UE 201 registers USIMs A and B using a multi-USIM indicator and a temporary identifier for another USIM, linking the registrations together. During each registration, core network 204 authenticates and authorizes the other USIM to allow sharing of the multi-access PDU session created for each USIM. In step 232: UE 201 creates an MA PDU for USIM A using the previously described procedure. In step 233: Similarly, UE 201 creates an MA PDU for USIM B, and SMF 207 generates ATSSS rules and MAR rules for UE 201 and UPF 206, respectively. The PDU session ID can be the same as the PDU session ID associated with USIM A, or it can be different. If the PDU session IDs are different, SMF 207 should notify UPF 206 that the PDU session IDs are linked together, so downlink data can be routed between the two PDU sessions. A new MAR will be created, which instructs UPF 206 to route data packets from unavailable access to available access.

[0183] Continue to refer to Figure 11 In step 234: Downlink data is available and routed by UPF 206 through the appropriate access network: DL data for USIM A is routed via 3GPP access, and DL data for USIM B is routed via non-3GPP access. Step 235: After a period of time, UE 201 enters the CM_IDLE state for UEIM A. In step 236: Downlink data is available for USIM A, but no tunnel information is available in UPF 206 for USIM A. UPF 206, based on MAR and FAR, utilizes a new multi-USIM redirection mode to redirect DL data from the PDU session associated with USIM A to the PDU session associated with USIM B, instead of forwarding DL data to SMF 207 and AMF 208 to page UE 201. In step 237: UPF 206 uses the MAR created in step 233 to redirect DL data for USIM A to UE 201 via non-3GPP access. As an example of this situation, one of the MARs generated for the MA PDU session associated with USIM A specifies that if 3GPP access is unavailable, data packets should be forwarded to the FAR corresponding to the non-3GPP access associated with USIM B. The guidance mode tells the UPF how to handle 3GPP and non-3GPP access (e.g., see [link to UPF documentation] for the meaning of "access"). Figure 2Traffic is routed between USIMs. In this case, we state that the UPF "directs DL data from the PDU session associated with USIM A to the PDU session associated with USIM B". Step 234 provides details of which access is assigned to which USIM, and step 236 explains why the UPF uses the new redirection mode to redirect data.

[0184] When multi-USIM redirection mode is enabled, UPF 206 can redirect data traffic from a PDU session of an inactive USIM on one access to a PDU session of an active USIM on another access to avoid paging conflicts for the inactive USIM. These PDU sessions are linked together during the PDU session setup process, which allows UPF 206 to redirect traffic between two PDU sessions via different accesses. When sending UL data to the network, UE 201 also performs similar redirection via different accesses (e.g., between 3GPP and non-3GPP accesses or between two 3GPP accesses). In the UE case, if UE 201 has UL data for USIM A, but the 3GPP access is unavailable and the non-3GPP access is available, UE 201 can use multi-USIM redirection mode to send data for USIM A via the non-3GPP access associated with USIM B. The multi-USIM guided mode can also be applied to support the following situations: between two 5G systems that support ATSSS, or between a 5G system supported by ATSSS and an LTE system that supports ATSSS by cooperating with the 5G system in multi-USIM UE TDM.

[0185] Configuration for UE data collection for analysis

[0186] NWDAF 205 can process data originating from UE 201. The analysis results obtained by processing UE data can be used by OAM or other NFs to make decisions. The 5GS system can be designed to capture appropriate data describing events detected at UE 201 and describing the UE's context or state. Data collection can be based on UE data collection rules and policies. These rules and policies can be configured by the network at UE 201. (See the previous section...) Figures 8A-8B The general UE registration process is described, in which a UE data collection policy is delivered to UE 201 upon successful UE registration. In the event of a UE policy update, UE data collection rules and policies can also be configured at UE 201, as described later in the 5G Examples section of this disclosure. The following sections describe what UE data is captured, when, and how this UE data is collected and sent to NWDAF 205 in the core network 204.

[0187] UE 201 can also be configured with data collection rules and policies in the following ways:

[0188] First, on-demand; for example, data is available and can be collected when needed. Available and requestable data can be scheduled. Scheduled data is based on timers.

[0189] Secondly, event-driven data, which can be based on local rules or events (e.g., each time a storage device is accessed) or system events (e.g., data collected after each registration update).

[0190] UE 201 can also be configured with reporting rules. Reporting rules can be part of a data collection strategy. UE reporting rules can be one of the following:

[0191] First, scheduling, for example, based solely on timers.

[0192] Secondly, event-driven events, such as those based on system events, for example, when UE 201 regains coverage.

[0193] While Table 2 provides a method for grouping UE data into analysis IDs, the following description discloses alternative methods for grouping UE data.

[0194] Configuration for on-demand data collection from UE

[0195] On-demand data can be data that can be collected when needed. On-demand data can also be scheduled for collection. Scheduled data collection can be used in various situations (e.g., for collecting reflective data whose occurrence is known in advance), and therefore scheduling can be set for data collection. Data collection can be triggered by rules configured in UE 201. The configuration process includes configuring rules, which can include identifiers indicating which data parameters need to be collected, the time of collection, and the frequency. Thus, UE data collection can be based on some predefined scheduling. Therefore, the rules for data collection at UE 201 can include desired data parameters and supporting time attributes. Time attributes can indicate when data should be collected and when the collected data should be reported. The parameters in Table 5 show further UE-centric data that can be collected by the UE, which can be used by NWDAF 205 to detect the presence of network attacks.

[0196]

[0197]

[0198] Each layer in UE 201 may have its own dataset that NWDAF 205 may need for analysis. Scheduled data collection can be a continuous data collection process, such as tracking the GPS location of UE 201 after each pre-specified interval. Collection scheduling can be pre-configured directly in UE 201 or sent to UE 201 after registration with the network.

[0199] It should also be recognized that, since the capabilities of different UEs may differ, UE 201 may need to communicate its data collection and provisioning capabilities to the network. The collection of UE data and its delivery to the network is based on the UE's data collection and provisioning capabilities, as described later in this disclosure.

[0200] UE data can be sensor data, system data, time values, etc. Sensor data can be data sensed and recorded from available sensors in UE 201. For example, a typical smartphone has multiple sensors. When activated, these sensors can continuously sense environmental conditions, such as the orientation of UE 201, the acceleration of UE 201, GPS data, etc. Additionally, data can also be collected from within UE 201; for example, UE 201 can be configured to collect time data for each storage device access; battery level every few minutes; execution of UE policies; the type of applications running; the state of UE memory periodically or when limits are met; the number of notifications received, etc.

[0201] UE sensor data can be configured to be collected on demand, or data collection can be scheduled. However, system data can be either on demand or event-driven. For example, battery life monitoring can be scheduled every 15 minutes. However, storage device access time cannot be scheduled. In other words, the timing of when the storage device will be accessed is not known in advance.

[0202] Note that data collection rules can be thought of as templates that specify what data to collect, as well as when and how frequently to collect it.

[0203] In data-driven cybersecurity applications, UE 201 can be configured to observe memory and CPU utilization, battery depletion rate over a given duration, device location, number of requests within a given interval, accessed URLs, downloaded files, types of running applications, types of requested services, UE 201 speed when a request occurs, frequency of PDU session requests, requested target slices, number of requested PDU sessions, and so on. An adversary's primary objective might be to gain access to the UE system and further attack the core network 204. If an adversary gains access to the UE, it can exploit UE 201 in various ways. Based on combinations of different types of data collected from UE 201 and strategically designed algorithms, it can be possible to identify potentially compromised or at-risk UEs.

[0204] Network-enabled data requests

[0205] The network can collect data on demand in an "ad-hoc" manner. This type of data collection involves network-requested data that is not pre-configured in UE 201. Instead, the network can request some data from UE 201 at any time. For example, it can instruct NWDAF 205 to verify certain system procedures or a set of data, which requires requesting data from UE 201. For example, UE 201 can execute several URSP rules, based on which UE 201 selects a certain S-NSSAI, DNN, or SSC mode for the application ID. URSP execution results in data being sent through network slicing and ultimately to the designated data network. NWDAF 205 can be instructed to periodically verify whether URSP rules are being correctly executed in UE 201. To do this, the network can request data about the executed URSP rules. NWDAF 205 can subscribe to events in network functions involved in network slices, as well as the routes taken by these packets, and ultimately compare the data collected from UE 201 with the actual routes executed in the network to see if URSP rules are correctly enforced on UE 201. If any discrepancies are encountered, NWDAF 205 can report them to OAM or other functions, enabling appropriate action procedures to be taken. Alternatively, UE 201 data for accountability can be scheduled and collected periodically. Similarly, mechanisms for verifying QoS rules and other SLA-related policies can be implemented.

[0206] Data requested via the network can be categorized into two types: target data or supporting data.

[0207] The target data is appropriate data that can be compared with some other data, such as the example of the URSP rules requested from UE 201 discussed earlier.

[0208] Supporting data can be data that helps establish correlations between collected data, thereby drawing certain conclusions; such as contextual data. For example, supporting data can help improve the probability or reliability of accuracy.

[0209] Configuration for event-driven data collection

[0210] Event-driven data is data generated when an event occurs. These events can be collected using various methods, such as monitoring and capturing existing events, or capturing events by configured policies.

[0211] Monitor and capture existing events

[0212] Numerous processes occur within the UE. UE 201 can be configured to monitor these processes and trigger data collection within points of interest. Examples include data on the execution count of URSP policies for each given time period; storage device access times; notifications when storage limits exceed specified capacities; and the types of commands executed consecutively. Table 6 describes various event-driven data attributes and their descriptions.

[0213]

[0214]

[0215]

[0216] Events captured by the configured policy

[0217] The second category of event-driven data collection can be determined by a configured data collection strategy. Strategy-driven data collection specifies that data with specified parameters can be collected when certain predefined rules and specified constraints converge. The strategy configuration can be directed to capture events and corresponding data of interest that would otherwise not be captured. For example, a strategy for data collection can be designed to capture data from the following scenarios:

[0218] If UE 201's speed may be higher than 35 mph and UE battery power is lower than 50%; UE 201 reaches an altitude of 50 ft above the ground; UE 201 may be within a given cell number (e.g., 143, 144, and 146), then continuously capture and hold the UL data rate for each PDU session for 20 seconds.

[0219] Therefore, strategies for data collection can employ conditional statement structures, such as if-else statements that use logical operators in a sequential chain to involve one or more conditions. Figure 12The document describes a data collection strategy structure with if-else-elseif conditions. Conditions can be a set of events cascaded through combinations of logical OR and AND operators. Some example combinations of conditions are as follows:

[0220] a. Event A, Event B, and Event C

[0221] b. Event A, event B, or event C

[0222] c. (Event A and Event B) or Event C

[0223] Decisions based on conditions (such as condition 1) will be based on the collection of results from an aggregation of logically guided events.

[0224] In an "if-else-elseif" strategy structure, the two independent conditions refer to OR logical structures with priority. For example, if condition 1 is not satisfied, then condition 2 is considered, and then the next condition is considered. It should be noted that condition 2 should be considered if and only if condition 1 is not satisfied. Furthermore, only one condition will be implemented from this series of conditions. The same applies to multiple conditions in a chain. Figure 12 The strategy structure is shown.

[0225] Depending on the context, UE policies may have additional constraints. There may be time constraints, such as how long data can be collected, or there may be constraints regarding the amount of data, such as how much data can be collected. Data volume may be driven by storage capacity or other requirements. In scenarios such as resource scarcity or security compliance similar to least privilege, UE 201 may need to establish data collection priorities. This means that some data or sensors take precedence over others. These constraints can be incorporated into the UE data collection policy.

[0226] Collect, maintain and transmit UE data

[0227] UE 201 can be configured to continuously collect data over a period of time and send the data to NWDAF 205. For example, UE 201 can be configured to collect GPS or sensor readings every 5 minutes over a 24-hour period and then send them to NWDAF 205. The collected timestamped data and other contextual data can be packaged and sent to the network at the end of the day. Similarly, UE 201 can be configured to send the collected data only when a certain event occurs. For example, UE 201 can be configured to collect memory utilization data every 60 seconds for certain UE 201 processes. This data is temporarily stored in the UE's storage device, and the information is only reported to the network when UE 201 moves to a new cell (which acts as a trigger). The trigger for sending data to the network can also be time-based. For example, UE application crash data can be collected and sent to the network throughout the day. The collected data may include the time of the crash, the application ID, the memory used at that time, and other contextual information such as how many other applications were open, CPU utilization, cell strength, etc. This data can be collected and stored locally in UE 201 and sent to the network at the end of the day or at a specified time.

[0228] In local roaming scenarios, the VPLMN can be configured to send Call Detail Records (CDRs) and other billing information to the HPLMMN. Additionally, UE 201 can be configured to later report the same information and other billing information contained in the CDR to the HPLMMN to verify the accuracy of the CDR collected from the VPLMN. UE 201 can collect and store this data for future transmission to the HPLMMN. When UE 201 returns to the HPLMMN, processes such as registration updates can trigger UE 201 to send CDR information to its home network.

[0229] Send UE data using PDU session

[0230] The general method for sending the collected data is via a PDU session established between UE 201 and core network 204. However, PDU sessions can be temporary. Therefore, if data is being continuously sent via a PDU session, and if the PDU session is released or deactivated, collection and delivery will be interrupted. Several different scenarios may arise in this case.

[0231] First, if other PDU sessions are in progress, data delivery continuity can be achieved by directing data to different PDU sessions.

[0232] Secondly, if no other ongoing PDU sessions exist, data delivery will be interrupted. However, data collection can still continue and be stored in a temporary UE storage device along with a timestamp. This data can then be transferred to NWDAF 205 when a new PDU session is established later. However, if data collection and delivery are real-time, the collected data may need to be refreshed until UE 201 establishes a new PDU session and can send data.

[0233] Alternatively, depending on the type of data delivery, data can be sent to the network via NAS message forwarding. The UE can include the data collected for NWDAF 205 in a NAS container and send the NAS container containing the data to the AMF, which then forwards the container to NWDAF 205.

[0234] Collect and maintain data from UEs outside coverage area

[0235] There are various scenarios for UE data collection, and there are also scenarios where UE 201 may be outside the coverage area.

[0236] In the first scenario, UE 201 begins collecting data during coverage, and then UE 201 leaves the coverage area.

[0237] In the second scenario, UE 201 only needs to collect data if UE 201 may be outside the coverage area.

[0238] The UE begins collecting data during coverage, and then the UE leaves the coverage area.

[0239] Data collection may be ongoing, during which UE 201 may continuously collect data and transmit it to the network. When UE 201 leaves the coverage area, sensors such as GPS and accelerometers can still function, and UE 201 can continue to collect data from these sensors.

[0240] If UE 201 is configured to report collected data to the network, such as when it encounters itself outside of coverage, it can begin storing the collected data in a temporary storage device within UE 201. Whenever UE 201 returns to network coverage, it can then send the collected data to the network when establishing a connection.

[0241] Data collection when the UE is outside the coverage area

[0242] On the other hand, data collection may only begin when UE 201 is outside coverage. Similar to the previous case, UE 201 may need to start collecting data and storing it in a temporary storage device within UE 201, and then send the data to the network when UE 201 returns to online.

[0243] In both scenarios, it may be necessary to limit how long (time) and / or how much data (capacity) UE 201 should continue collecting when the UE leaves coverage area. Additionally, if there are many active data collection points, the amount of data collected can easily increase rapidly. Consequently, UE storage space may not be able to handle the amount of data collected for an extended period. In this scenario, UE 201 may need to establish data collection priorities. This means that some sensor data or system data collection may need to be temporarily disabled, so that only the most important data may be collected for a given time or capacity. Limiting data collection priorities can also depend on the type of UE 201.

[0244] Another factor is the duration that UE 201 may be outside coverage. The duration a UE is outside coverage can be variable and sometimes minimal. Therefore, frequently disabling and enabling data collection can lead to performance degradation and potentially drain battery power. Thus, time limits should be set when UE 201 needs to stop or disable data collection. This may also be limited by temporary storage capacity.

[0245] UE 201 can also utilize sidelinks and use UE-to-network relays to transmit data. Policies can be designed to utilize the PC5 (ProSe) interface to transmit data collected by the UE to the network when UE 201 may be outside coverage area.

[0246] Data selection and collection based on UE capabilities

[0247] Based on the preceding description, data can be configured according to what NWDAF 205 requires. Once the required data is identified, it can be used as scheduling data to configure parameters for data collection, or an appropriate data collection strategy can be configured in UE 201 to collect data based on an event-driven strategy.

[0248] However, data collection may be limited by what UE 201 can provide. Not all UE 201s have the same ability to provide data or collect a certain type of data. This ability can be based on the type of UE, the type of application running on the UE, privacy and security constraints, etc. Therefore, UE 201 may need to communicate its data collection capabilities before the NWDAF 205 in the core network 204 can request the required data or configure a policy that requires the required data. Figure 13 Enhancements to the registration process are illustrated, in which UE 201 is able to send its data provisioning capability to core network 204. Based on this data provisioning capability, NWDAF 205 is able to formulate data collection requests and policies and send these requests and policies to UE 201. Note that it has been previously disclosed that UE 201 can provide analytics reporting capability indicators to core network 204 and receive data analytics collection policies. Figure 13 The process adds support for UE 201 to provide UE 201 capabilities to the core network 204, so that NWDAF 205 can derive collection rules from the available capabilities in UE 201.

[0249] exist Figure 13 In step 241, UE 201 sends a registration request to the network via RAN 202. In the registration request message, UE 201 may include UE Data Collection Capability (UDCC). UDCC includes details about what data UE 201 can collect and supply to the network upon request. It includes the type of data, sensor type parameters for each sensor, sensor data type, context data parameters, data parameters from different layers of the UE system, data pattern information for each data type, etc. UDCC may also include constraints regarding what data can be collected from UE 201. For example, UDCC may already cover privacy or security aspects of UE 201, without supplying data such as UE memory utilization data for analysis. Alternatively, UDCC may be pre-configured on UE 201.

[0250] exist Figure 13 In step 242, AMF 208 receives the registration request and identifies the UDCC indication. NWDAF 205 may have already subscribed to AMF 208, and thus, AMF 208 calls Namf_Communication_NlMessageNotify to NWDAF 205 to convey the UDCC information.

[0251] exist Figure 13 In step 243-a, NWDAF 205 receives UDCC information from AMF. NWDAF 205 can parse the UDCC information and identify what data can be obtained from UE 201. Based on the available data parameters, NWDAF 205 can prepare rules and policy requirements, such as what type of policy is needed. For example, NWDAF 205 can consider simple configuration commands or data collection rules, rather than complex context-aware data collection policies.

[0252] Based on the identified policy requirements, NWDAF 205 can use its built-in policy generator functionality to generate the required data collection policy. As mentioned earlier, data collection requirements may consist of only the configuration of scheduled data collection rules or event-driven data collection policies, or both.

[0253] Alternatively, the UDCC can be sent to the OAM, where it can be inspected. The OAM can then write policies or prepare requirements for those policies and send them to the PCF, where the PCF builds the policies.

[0254] Or, in Figure 13 In step 243-b, NWDAF 205 can request PCF 209 to generate a data collection policy. Once NWDAF 205 receives the UDCC from UE 201 via AMF 208, it identifies the UE's data collection and delivery capabilities and prepares requirements for policy generation. It can request a data collection policy from PCF 209 by sending rules and policy requirements. PCF 209 can prepare the requested data collection policy and send it back to NWDAF 205 or AMF.

[0255] exist Figure 13 In step 244, if NWDAF 205 generates UE data collection rules and policies, it sends the UE data collection rules and policies to AMF 208.

[0256] exist Figure 13 Step 245 continues the normal registration process. When Figure 13 While steps 242-244 are occurring, there may be an ongoing general registration process.

[0257] exist Figure 13 In step 246, if the UE registration process is successful, AMF 208 prepares a registration acceptance message for UE 201. AMF 208 can include the UE data collection rules and policies in the registration acceptance message and send it to UE 201 via RAN.

[0258] exist Figure 13 In step 247, UE 201 receives the UE data collection rules and policies from the registration acceptance message. UE 201 can configure itself to perform data collection. Thus, the data collection falls within the UDCC guidelines.

[0259] Actions based on NWDAF data analysis

[0260] As described in previous sections, NDWAF 205 can be enhanced to collect data from UE 201. NWDAF 205 can use data collected from the UE and data collected from NFs as input data for analysis. The data analysis results can be sent to different NFs, and based on the results, the NFs can take action.

[0261] NWDAF Analysis for NF

[0262] NWDAF analysis can guide an NF to take actions that may require NF reconfiguration. Reconfiguration can involve reconfiguring different policies, updating subscriptions, updating NF timer values, restricting UE services, etc., with impacts potentially extending to the core network 204. This can indirectly affect UE 201. For example, core network 204 could initiate (e.g., generate or activate) two different UPFs and offload UE traffic.

[0263] Impact of NWDAF Analysis on UE

[0264] On the other hand, NWDAF analysis may affect UE 201 in ways that can alter its behavior. When NF acts, it can affect UE 201 in a variety of ways.

[0265] In the first approach, NWDAF data analysis results can influence the NF to make changes as described above. For example, NWDAF 205 can track UE behavior and the behavior of different network slices. Based on data received from UE 201, NWDAF 205 generates analysis and sends the analysis to the NF. Based on the received data analysis report, the NF can therefore treat UE 201 differently. For example, traffic from UE 201 can be segmented into a separate UPF, multiple SMF 207 instances can be assigned to the UE's traffic, timer values ​​within SMF 207 or AMF 208 can be changed, timer values ​​sent to UE 201 can be changed, and so on.

[0266] In the second approach, NWDAF data analysis results can influence changes made by the NF, but the changes made by the NF can affect UE 201, thus the direct impact on UE 201 is significant. For example, based on UE behavior data, NWDAF 205 can perform data analysis, which may include data about registration behavior, access locations, handover frequency, services requested from the network, applications used, and the type of tunnel used. As a result of the NWDAF data analysis report communicated to the NF (e.g., AMF, PCF, UDM, etc.), the network can decide to redirect UE 201 to a different network slice. This decision can translate into updating UE subscription information in the UDM, sending a new set of permitted S-NSSAI to UE 201, sending updated URSP policies, UE configuration updates, and so on.

[0267] Figure 14 An example procedure involving NWDAF analysis affecting NF to make changes that affect UE 201.

[0268] Periodic registration timer update driven by NWDAF via UE configuration update

[0269] This section provides an example procedure in which data analysis generated by NWDAF based on data collected from UE 201 and NF in core network 204 enables AMF 208 to update UE configuration. Figure 14 This process is described.

[0270] exist Figure 14 Step 250a of -a, ANWDAF 205 is equipped with data analysis capabilities, which consist of algorithms (recursive algorithms, machine learning algorithms, numerical algorithms, etc.) whose analysis results can help make decisions.

[0271] exist Figure 14 In step 250-b, NWDAF 205 uses Nnf_EventExposure_Subscribe to subscribe to data events from the NF that includes AMF208. Similarly, the NF can subscribe to NWDAF analytics using Nnwdaf_AnalyticsSubscription_Subscribe.

[0272] exist Figure 14 Step 250-c can enhance 5GS, where the network configures UE data collection rules and policies in UE 201. As previously mentioned, these rules and policies can be delivered during UE registration, UE registration update, or UE configuration update procedures. Alternatively, the rules and policies can be pre-configured locally in UE 201.

[0273] exist Figure 14In step 251, the configured UE data collection rules or policies are executed, and UE 201 is ready to send data to the network.

[0274] exist Figure 14 In step 252, UE 201 may notify AMF 208 that it is ready to supply data to NWDAF 205.

[0275] exist Figure 14 In step 253, AMF 208 can notify NWDAF 205 that the UE is ready to send data. NWDAF 205 can then prepare itself to receive UE data and send an acknowledgment back to AMF.

[0276] exist Figure 14 In step 254, when an acknowledgment is received from NWDAF 205, AMF 208 may send a signal to UE 201 indicating that it is ready to receive UE data.

[0277] Note that the messages in steps 250-c to 254 can be exchanged via NAS or PDU sessions.

[0278] exist Figure 14 Step 255 can enhance UE 201 to collect data based on UE data collection rules and policies configured by the network on UE 201, and send the collected data to NWDAF 205 during the PDU session. The data can be scheduled data or event-driven data. Alternatively, UE 201 can use NAS message passing to send the collected data.

[0279] exist Figure 14 In step 256, NWDAF 205 can analyze the collected data. NWDAF 205 can also collect data from other NFs, including AMF 208, and then generate data analysis results. The analysis results can be submitted to the various NFs in the core network 204.

[0280] exist Figure 14In step 257, NWDAF 205 can send the data analysis results to AMF 208 using NWDAF_AnalyticsSubscription_Notify. Based on the analysis results, AMF 208 can choose to update the periodic registration timer value of UE 201. AMF 208 can update this change in the UE subscription at UDM / UDR. Alternatively, the network can establish new timer policies that can include dynamic conditions for UE 201, where the policy instructs UE 201 which timer value to use when a certain condition is met. Therefore, timer policies can take the form of conditional if-else statements. For example, if UE 201 chooses to use S-NSSAI 'X' and the goal is to reach DNN 'Q', then UE 201 can use the registration update timer 'A'; otherwise, it can use the registration timer 'B'. Below is a list of example timer policies that can be sent to the AMF.

[0281] In the first timer policy, the timer policy can provide UE 201 with a service gap timer for each slice in the S-NSSAI that is allowed or configured for the UE, and UE 201 can apply the maximum service game timer value for any slice with an active PDU session.

[0282] In the second timer policy, the timer policy can provide rules that instruct the reflection QoS timer and PDU session release timer to be extended or shortened when UE 201 can register to certain slices, certain regions, or run certain types of applications. This is useful in scenarios where the optimal reflection QoS timer and PDU session release timer depend on the applications that UE 201 may be running.

[0283] In the third timer policy, the timer policy can indicate that the periodic RAN notification area update timer or UE non-3GPP deregistration timer should be extended or shortened when UE 201 can register to certain slices, in certain areas, running certain types of applications, or moving at a certain speed.

[0284] exist Figure 14 In step 258, AMF 208 sends a UE configuration update command that includes UE parameters, such as updated periodic registration timer values ​​or updated UE timer policies. Changes to the periodic registration timer affect changes to other timer values, such as the mobility reachability timer and mobility management backoff time for UE 201.

[0285] exist Figure 14In step 259, if the UE configuration update instruction requires confirmation of the UE configuration update command, then UE 201 will send a UE configuration update complete message to the AMF.

[0286] UE data privacy and utilization

[0287] The 3GPP TR 23.700-91 V0.3.0[9] study points out the need for user privacy during the collection and use of UE data in NWDAF 205. Although the study covers the user consent aspect of authorizing data collection for data analysis, data privacy and usage control are crucial for many aspects of data collection. This section discusses mechanisms for controlling data and data use to protect the privacy aspects of UE 201.

[0288] Control over data utilization

[0289] Data utilization can be restricted by establishing compliance and utilization policies in 5GS. A contract can be established between the UE 201 user and the MNO, where the use of collected data can be restricted by establishing the following:

[0290] First, a cardinality for the types of data collected can be established, which mandates the number of times NWDAF 205 can use the data for analysis. UE 201 can be enhanced to mark the cardinality of the data before it sends the data to the network.

[0291] Secondly, a time limit can be established for how long the data collected by UE 201 can be stored in the network for the MNO.

[0292] Third, without the user's consent, any resulting NWDAF analysis data (whether modified or not) may not be shared by the network with any third party. If UE data analysis information is shared outside the PLMN that UE 201 can register with, user consent is required. The 5GS system may be enhanced such that if the network intends to share collected UE data or data analysis results with a third party, the core network 204 must obtain user consent from UE 201.

[0293] Fourth, when necessary, the user of UE 201 must have access to the collected data and be able to trigger 5GS to refresh the data collected from UE 201 or collected on behalf of the UE in core network 204. Note that this user privacy feature is enforced in Europe through GDPR.

[0294] Note that an accountability report can be created for each point discussed. The requirement to control data utilization can be driven by the Service Provider (MNO) and the Service and UE 201's users (consumers) SLAs. Accountability reports form the basis for whether governance policies (e.g., GDPR) or SLAs meet satisfactory standards. Accountability reports can be stored on the network on behalf of UE 201, reported to the OAM, or sent to UE 201.

[0295] UE restricted data

[0296] UE 201 data can be restricted through mechanisms such as preprocessing or sector-based methods.

[0297] By preprocessing the restricted data

[0298] Data collected from UE 201 in its raw form may be valuable. However, for privacy, security, or compliance reasons, data may need to be restricted. To reduce the risk of collected data being used against UE 201, UE 201 can be configured to preprocess the data before sending it for data analysis. Preprocessing may involve the following:

[0299] Packaging data: Data can be packaged so that only the information that needs to be shared is included in the schema.

[0300] Data filtering: Data can be restricted based on certain criteria (such as intensity, sensor type, layer from which the data is collected, user information, system sector, location of data collection, device processing entity (authority), etc.). For example, UE CPU utilization and memory utilization data may be more critical than gyroscope data shared by the UE.

[0301] Anonymizing data: Data can be anonymized before being sent to the network. Anonymization can include removing information, which is not limited to user identity, but also includes information such as CPU type, manufacturer ID, model batch number, and country of origin.

[0302] Data aggregation: Data can be aggregated before being sent to the network. For example, the average of the collected data can be sent. This may be for privacy or network performance reasons.

[0303] Based on sector restriction data

[0304] Data can be collected from various layers and sectors within UE 201. UE 201 can be configured to limit the collection and delivery of UE data based on where the data is collected from. For example, application layer data or data related to CPU and memory utilization may not be sent for analysis.

[0305] User control over UE data collection

[0306] Users may need control over data collection on their devices. While a different set of agreements may have already been reached regarding data collection, users may need the ability to control when and where data should not be collected. Stopping data collection can be dynamic and driven by user expectations. For example, a user may not want data collected while the user is sleeping, between specific times, for a certain duration, or at a specific location. Therefore, UE 201 may be equipped with the ability to provide users with the ability to disable or enable data collection from UE 201.

[0307] During data collection policy updates from the network, user control over data collection can be further expanded. When a new policy update is requested to UE 201 or a new policy update arrives at UE 201, UE 201 can trigger user consent to accept or reject the data collection policy update. This is because the UE data collection policy may be driven by UE 201 capabilities, which may further depend on the UE context, such as location, time, active users and user attributes (e.g., multi-user scenarios), multiple SIMs, etc.

[0308] 5G Examples

[0309] The preceding chapters disclosed various aspects of UE data collection, including the types of UE data collected, the triggers for data collection, and the rules and policies that guide the timing of collection triggers. Furthermore, the methods for instructing the network on the UE's data collection capabilities during the UE registration process and for delivering UE data collection policies to UE 201 using UE registration acceptance or UE configuration update messages were disclosed.

[0310] The data collection rules and event-driven UE data collection strategies described in the preceding chapters can be delivered via UE registration acceptance messages and configured in UE 201 during the UE's general registration process or UE registration update process.

[0311] The UE data collection strategies discussed above include data collection from UE 201 during PDU sessions. However, various types of data can also be collected via the control plane through NAV message transmission.

[0312] In addition to the UE registration process, UE data collection rules and policies can also be delivered and configured at any time via the UE configuration update process. For example... Figure 15 As described in the document, the general UE configuration update procedure for transparent UE policy delivery can be used with some modifications, as described in Clause 4.2.4.3 of TS 23.502[2].

[0313] exist Figure 15 Step 260-a, NWDAF 205 can be used with AMF 208 and other NF ( Figure 15 (Not shown in the image) together participate in generating requirements for UE data collection rules and policies, which can be based on OAM requirements, NF requirements, current algorithms, available data, and UE data delivery capabilities ( Figure 13 This requirement can be communicated to PCF 209. PCF 209 can generate UE data collection rules and policies.

[0314] exist Figure 15 In step 260-b, UE 201 can be configured to accept or reject UE configuration updates for UE data collection from the network. The user of UE 201 can select this configuration using the GUI.

[0315] exist Figure 15 In step 261, the PCF determines the process of updating the UE data collection rules and policies based on triggering conditions (such as initial registration, when UE 201 registers with 5GS when it moves from EPS to 5GS) or the need to update the UE policy (such as network-triggered UE policy update situations (e.g., changes in UE location, changes in subscribed S-NSSAI, etc.), triggering the start of data collection with the updated policy).

[0316] exist Figure 15 In step 262, the PCF invokes the Namf_Communication_NlN2MessageTransfer service provided by the AMF. The UE policy container includes UE data collection rules and policies.

[0317] exist Figure 15 In step 263, the network can notify UE 201 of the UE data collection policy update. UE 201 sends a response to AMF208 regarding its choice to accept or reject the policy configuration update.

[0318] exist Figure 15 In step 264, AMF 208 uses Namf_Communication_NlMessageNotify to PCF 209 whether UE 201 can accept policy configuration updates.

[0319] exist Figure 15 In step 265, if UE 201 is able to accept the UE configuration update, AMF 208 may trigger a service request as described in section 4.2.3.3 of TS 23.502[2].

[0320] If the user has chosen not to accept updated UE data collection policy configuration, AMF 208 may not send a configuration update. Otherwise, UE 201 may receive UE policy updates.

[0321] Note that UE 201 can be configured to always receive UE configuration updates from the network. In this case, UE 201 can always receive UE configuration updates from the network. By using local policy configuration on UE 201, data collection configurations, such as what data to collect, when to collect data, and how to send it to the network, can be adjusted.

[0322] exist Figure 15 In step 266, if UE 201 is configured to receive updates, AMF 208 sends a UE configuration update via RAN.

[0323] In addition to the important topics of UE data collection rules and policies included in the policy container, PCF 209 also includes... Figure 15 Step 267 and Figure 15 Step 268 is similar to TS 23.502[2]. Figure 4 Steps 4-5 of .2.4.3-1.

[0324] UE configuration updates for UE data collection rules and policies can be frequent and triggered by previously configured UE data collection policies. For example, a UE's battery may deplete much faster than normal within a given time period. For instance, NWDAF 205 might analyze that for UE 201, it is unusual for the battery percentage to fall below the daily average of 30% to 60% within 30 minutes. Simultaneously, UE 201 might be using a non-3GPP access type, requesting service too frequently for a period of time during which UE traffic is typically low. These events can then trigger the collection of certain data provided by UE 201 to NWDAF 205. For example, NWDAF 205 might encounter situations where it may need additional sensor data or the frequency of data collection may need to differ from previously configured data collection policies. Therefore, NWDAF205 can formulate an event-driven policy to include an “event representation” as described above, which states that “if the change in battery level is >70%, collect data on all applications in use and their percentage of use”, and use the UE configuration update procedure to send the updated data collection policy to UE 201 in the policy container.

[0325] Figure 16 It shows the use of Figure 9 Example GUI for a scenario. After receiving the paging reason from a paging request for USIM B, in Figure 9During step 212, the GUI is displayed to the user of UE 201. The user is given the option to ignore the paging and continue the ongoing activity using USIM A, or to request a suspension of communication with the USIM A network. In this case, the user decides to suspend communication with the USIM A network and presses the Suspend Communication button. If UE 201 requests a suspension of communication with the USIM A network, the operation continues to... Figure 9 Step 213 and the remaining steps.

[0326] Figure 17 A sample GUI is depicted, showing a front-end that provides users with an application to enable or disable UE data collection, as well as buttons to activate data privacy and limit the UE data collected. Figure 17 The backend is also described, in which UE 201 is configured with data collection rules and event-driven data collection strategies received from the network.

[0327] It should be understood that, in carrying out activities such as those described in this article... Figure 3 , Figures 8A-11 or Figures 12-15 The entities illustrating the steps can be logical entities. Each step can be stored in, for example,... Figure 18C or Figure 18D The memory of those devices, servers, or computer systems illustrated in the diagram is used, and execution takes place on their processors. It is conceivable in this document (e.g., Figure 3 , Figures 8A-15 Skipping, merging, or adding steps between the disclosed exemplary methods. Table 7 discloses exemplary abbreviations and definitions that may be used herein.

[0328]

[0329]

[0330] The 3rd Generation Partnership Project (3GPP) has developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities—including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as “5G.” Development of the 3GPP NR standard is expected to continue and include the definition of next-generation radio access technologies (new RATs), anticipated to include the provision of new flexible radio access below 7 GHz and new ultra-mobile broadband radio access above 7 GHz. Flexible radio access is expected to consist of new, non-backward-compatible radio access in the new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with varying requirements. Ultra-mobile broadband is expected to include cmWave (centimeter wave) and mmWave (millimeter wave) spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with Flexible Radio Access below 7 GHz, featuring design optimizations specific to cmWave and mmWave.

[0331] 3GPP has identified a wide range of use cases expected to be supported by NR, resulting in diverse user experience requirements regarding data rates, latency, and mobility. Use cases include the following general categories: Enhanced Mobile Broadband (eMBB) Ultra-Reliable Low-Latency Communications (URLLC), Massive Machine-Type Communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and Enhanced Vehicle-to-Everything (eV2X) communications, which can include any of the following: Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Network (V2N), Vehicle-to-Pedestrian (V2P), and vehicle-to-other-entities communications. To name just a few, specific services and applications within these categories include, for example, surveillance and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones. All of these use cases, and others, are envisioned in this document.

[0332] Figure 18A The illustration depicts an example communication system 100 in which methods and apparatus for traffic redirection enhancement of cellular networks, such as those described and claimed herein, can be used. Figures 1-11The system and method are illustrated in the diagram. Communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g (which may generally or collectively be referred to as WTRU 102). Communication system 100 may include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. Network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, or edge computing, etc.

[0333] It should be understood that the concepts disclosed herein can be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g can be any type of device or apparatus configured to operate or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, or 102g is... Figure 18A , Figure 18B , Figure 18C , Figure 18D , Figure 18E or Figure 18F A WTRU can be described as a handheld wireless communication device; however, it should be understood that, for the various use cases envisioned for 5G wireless communication, each WTRU can include or be embodied in any type of device or apparatus configured to transmit or receive wireless signals. As an example only, such devices or apparatuses include user equipment (UE), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical or e-health devices, robots, industrial equipment, drones, and vehicles such as cars, buses, trucks, trains, or airplanes.

[0334] The communication system 100 may also include base station 114a and base station 114b. Figure 18AIn the example, each base station 114a and 114b is depicted as a single element. In reality, base stations 114a and 114b may include any number of interconnected base stations or network elements. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112. Similarly, base station 114b may be any type of device configured to wired or wirelessly interface with at least one of Remote Radio Headers (RRHs) 118a and 118b, Transmit and Receive Points (TRPs) 119a and 119b, or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network services 113. RRH 118a, 118b can be any type of device configured to wirelessly interface with at least one of WTRU 102 (e.g., WTRU 102c) to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112.

[0335] TRPs 119a and 119b can be any type of device configured to wirelessly interface with at least one of WTRUs 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, network services 113, or other networks 112. RSUs 120a and 120b can be any type of device configured to wirelessly interface with at least one of WTRUs 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, or network services 113. For example, base stations 114a and 114b can be base transceiver stations (BTS), Node-Bs, eNode Bs, home node Bs, home eNode Bs, next-generation Node-Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, etc.

[0336] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Similarly, base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base station or network elements (not shown), such as BSCs, RNCs, relay nodes, etc. Base station 114a may be configured to transmit or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Similarly, base station 114b may be configured to transmit or receive wired or radio signals within a specific geographical area, which may be referred to as a cell (not shown) for the traffic-directed enhancement methods, systems, and apparatus for cellular networks disclosed herein. Similarly, base station 114b can be configured to transmit or receive wired or wireless signals within a specific geographical area, which may be referred to as a cell (not shown). The cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in this example, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In this example, base station 114a may employ Multiple-Input Multiple-Output (MIMO) technology, thus allowing multiple transceivers to be used for each sector of the cell.

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

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

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

[0340] WTRUs 102a, 102b, 102c, 102d, 102e, or 102f can communicate with each other via air interfaces 115d / 116d / 117d (such as sidelink communication). Air interfaces 115d / 116d / 117d can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115d / 116d / 117d.

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

[0342] In the example, base station 114a can implement radio technologies (such as Evolved UMTS Terrestrial Radio Access (E-UTRA)) with WTRUs 102a, 102b, and 102c, or RRH118a, 118b, TRP 119a, and 119b in RANs 103b / 104b / 105b, or RSU 120a and 120b with WTRUs 102c and 102d. It can establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c using Long Term Evolution (LTE) or LTE-Advanced (LTE-A), respectively. In the future, air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies can include LTE D2D and V2X technologies and interfaces (such as sidelink communication). Similarly, 3GPP NR technology includes NR V2X technology and interfaces (such as sidelink communication).

[0343] Base station 114a in RAN 103 / 104 / 105 with WTRU 102a, 102b, 102c and 102g, or RRH 118a, 118b, RP 119a, 119b or RSU 120a, 120b with WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate for GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0344] Figure 18ABase station 114c can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, trains, airplanes, satellites, factories, campuses, etc., to implement the traffic-directed enhancement methods, systems, and apparatuses for cellular networks disclosed herein. In the example, base station 114c and WTRU 102, such as WTRU 102e, can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN), and similarly, base station 114c and WTRU 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another example, base station 114c and WTRU 102, such as WTRU 102e, can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish picocells or femtocells. Figure 18A As shown, base station 114c can have a direct connection to the Internet 110. Therefore, it is not required for base station 114c to access the Internet 110 via core network 106 / 107 / 109.

[0345] RAN 103 / 104 / 105 or RAN 103b / 104b / 105b can communicate with core networks 106 / 107 / 109, which can be any type of network configured to provide voice, data, messaging, authorization and authentication, application, or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, or advanced security features such as user authentication.

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

[0347] Core networks 106 / 107 / 109 can also serve as gateways for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, the Internet 110, or other networks 112. PSTN 108 may include a line-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, which may use the same RAT as or a different RAT than RAN 103 / 104 / 105 or RAN 103b / 104b / 105b.

[0348] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multimode capability. For example, WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks via different wireless links to implement the traffic-oriented enhancement methods, systems, and apparatuses for cellular networks disclosed herein. For example, Figure 18A The WTRU 102g shown can be configured to communicate with a base station 114a that can employ cellular-based radio technology and with a base station 114c that can employ IEEE 802 radio technology.

[0349] Although not in Figure 18A As shown, however, it should be understood that user equipment can establish a wired connection to a gateway. The gateway can be a residential gateway (RG). The RG can provide connectivity to the core network 106 / 107 / 109. It should be understood that many of the topics contained herein can be equally applied to UEs acting as WTRUs and UEs using wired connections to the network. For example, topics applicable to radio interfaces 115, 116, 117, and 115c / 116c / 117c can be equally applied to wired connections.

[0350] Figure 18BThis is a system diagram of an example RAN 103 and core network 106 for implementing the traffic-directed enhancement methods, systems, and apparatuses for cellular networks disclosed herein. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 18B As shown, RAN 103 may include Node-B 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via air interface 115. Node-B 140a, 140b, and 140c may be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNC 142a and 142b. It should be understood that RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

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

[0352] Figure 18B The core network 106 shown may include a Media Gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, or a Gateway GPRS Support Node (GGSN) 150. While each of the above elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned or operated by an entity other than the core network operator.

[0353] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 can provide WTRU 102a, 102b and 102c with access to line-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b and 102c and conventional landline communication equipment.

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

[0355] The core network 106 can also be connected to other networks 112, which may include other wired or wireless networks owned or operated by other service providers.

[0356] Figure 18C This is a system diagram of an example RAN 104 and core network 107 for implementing the traffic-directed enhancement methods, systems, and apparatuses for cellular networks disclosed herein. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0357] RAN 104 may include eNode-B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs. eNode-B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via air interface 116. For example, eNode-B 160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B 160a may, for example, use multiple antennas to transmit and receive radio signals from WTRU 102a.

[0358] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink or downlink. For example... Figure 18CAs shown, eNode-B 160a, 160b and 160c can communicate with each other via the X2 interface.

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

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

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

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

[0363] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between core network 107 and PSTN 108, or can communicate with it. Additionally, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned or operated by other service providers.

[0364] Figure 18D This is a system diagram of an example RAN 105 and core network 109 for implementing the traffic-directed enhancement methods, systems, and apparatuses for cellular networks disclosed herein. RAN 105 can communicate with WTRUs 102a and 102b via air interface 117 using NR radio technology. RAN 105 can also communicate with core network 109. Non-3GPP Interoperability Function (N3IWF) 199 can communicate with WTRU 102c via air interface 198 using non-3GPP radio technology. N3IWF 199 can also communicate with core network 109.

[0365] RAN 105 may include gNode-B 180a and 180b. It should be understood that RAN 105 may include any number of gNode-Bs. gNode-B 180a and 180b may each include one or more transceivers for communicating with WTRU 102a and 102b via air interface 117. When using integrated access and backhaul connections, the same air interface can be used between the WTRU and the gNode-B, which may be via the core network 109 of one or more gNBs. gNode-B 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming technologies. Thus, gNode-B 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. It should be understood that RAN 105 may employ other types of base stations, such as eNode-B. It should also be understood that RAN 105 may employ more than one type of base station. For example, RAN may employ both eNode-B and gNode-B.

[0366] The N3IWF 199 may include a non-3GPP access point 180c. It should be understood that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c via air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c via air interface 198 using the 802.11 protocol.

[0367] gNode-B 180a and 180b can be associated with specific cells (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink or downlink. For example... Figure 18D As shown, gNode-B 180a and 180b can communicate with each other, for example, via the Xn interface.

[0368] Figure 18D The core network 109 shown may be a 5G core network (5GC). The core network 109 can provide numerous communication services to customers interconnected via a radio access network. The core network 109 includes multiple entities performing the functions of the core network. As used herein, the terms "core network entity" or "network function" refer to any entity performing one or more functions of the core network. It should be understood that such a core network entity may be a logical entity implemented in the form of computer-executable instructions (software), which are stored in devices configured for wireless or network communications, or in computer systems (such as…). Figure 18G (In the memory of the system shown in the diagram), and executed on its processor.

[0369] exist Figure 18D In the example, the 5G core network 109 may include Access and Mobility Management Functions (AMF) 172, Session Management Functions (SMF) 174, User Plane Functions (UPF) 176a and 176b, User Data Management Functions (UDM) 197, Authentication Server Functions (AUSF) 190, Network Openness Functions (NEF) 196, Policy Control Functions (PCF) 184, Non-3GPP Interoperability Functions (N3IWF) 199, and User Data Repository (UDR) 178. While each of the above elements is depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Figure 18DThis indicates that network functions are directly interconnected; however, it should be recognized that they can communicate via routing proxies, such as diameter routing proxies or message buses.

[0370] exist Figure 18D In the example, connectivity between network functions is achieved through a set of interfaces or reference points. It's important to understand that network functions can be simulated, described, or implemented as a set of services invoked or called by other network functions or services. Enabling network function services can be achieved through direct connections between network functions, the exchange of messages on a message bus, invoking software functions, etc.

[0371] The AMF 172 can connect to RAN 105 via the N2 interface and can be used as a control node. For example, the AMF 172 can be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF can forward user plane tunnel configuration information to RAN 105 via the N2 interface. The AMF 172 can receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 can typically route and forward NAS packets between WTRU 102a, 102b, and 102c via the N1 interface. The N1 interface is not... Figure 18D As shown in the image.

[0372] SMF 174 can connect to AMF 172 via interface N11. Similarly, SMF 174 can connect to PCF184 via interface N7 and to UPF 176a and 176b via interface N4. SMF 174 can be used as a control node. For example, SMF 174 can be responsible for session management, IP address allocation for WTRU 102a, 102b and 102c, management and configuration of traffic routing rules in UPF 176a and UPF 176b, and generation of downlink data notifications to AMF 172.

[0373] UPF 176a and UPF 176b can provide WTRU 102a, 102b, and 102c with access to a packet data network (PDN) (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and other devices. UPF 176a and UPF 176b can also provide WTRU 102a, 102b, and 102c with access to other types of packet data networks. For example, other networks 112 can be Ethernet or any type of network that switches data packets. UPF 176a and UPF 176b can receive traffic routing rules from SMF 174 via the N4 interface. UPF 176a and UPF 176b can provide access to packet data networks by connecting to the packet data network via the N6 interface, or by interconnecting with each other or connecting to other UPFs via the N9 interface. In addition to providing access to packet data networks, UPF 176 can also be responsible for packet routing and forwarding, policy and rule enforcement, quality of service processing for user plane traffic, and downlink packet buffering.

[0374] The AMF 172 can also connect to the N3IWF 199, for example, via the N2 interface. The N3IWF facilitates connectivity between, for example, the WTRU 102c and the 5G core network 170 via a radio interface technology not defined by 3GPP. The AMF can interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0375] PCF 184 can be connected to SMF 174 via N7 interface, to AMF 172 via N15 interface, and to Application Function (AF) 188 via N5 interface. N15 and N5 interfaces are not... Figure 18D As shown in the diagram, PCF 184 can provide policy rules to control plane nodes such as AMF172 and SMF 174, allowing these rules to be enforced. PCF 184 can send policies to AMF 172 for WTRUs 102a, 102b, and 102c, enabling AMF to deliver policies to WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied on WTRUs 102a, 102b, and 102c.

[0376] UDR 178 can be used as a repository for authentication credentials and subscription information. The UDR can connect to network functions, allowing them to add, read, and modify data within the repository. For example, UDR 178 can connect to PCF184 via interface N36. Similarly, UDR 178 can connect to NEF 196 via interface N37, and UDR 178 can connect to UDM 197 via interface N35.

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

[0378] The AUSF 190 performs authentication-related operations, connects to the UDM 178 via the N13 interface, and connects to the AMF 172 via the N12 interface.

[0379] The NEF 196 exposes the capabilities and services of the 5G core network 109 to the Application Function (AF) 188. This exposure can occur on the N33 API interface. The NEF can connect to the AF 188 via the N33 interface, and it can connect to other network functions to expose the capabilities and services of the 5G core network 109.

[0380] Application function 188 can interact with network functions in the 5G core network 109. The interaction between application function 188 and network functions can occur via a direct interface or via NEF 196. Application function 188 can be considered part of the 5G core network 109, or it can be outside the 5G core network 109 and deployed by an enterprise with a business relationship with the mobile network operator.

[0381] Network slicing is a mechanism that mobile network operators can use to support one or more 'virtual' core networks behind the operator's air interface. This involves 'slicing' the core network into one or more virtual networks to support different RANs or different service types operating across a single RAN. Network slicing enables operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements, such as functionality, performance, and isolation.

[0382] 3GPP designed the 5G core network to support network slicing. Network slicing is a powerful tool for network operators to support a diverse range of 5G use cases with highly varied and sometimes extreme requirements, such as massive IoT, critical communications, V2X, and enhanced mobile broadband. Without network slicing, when each use case has its own specific set of performance, scalability, and availability requirements, the network architecture may not be flexible and scalable enough to effectively support a wider range of use case needs. Furthermore, the introduction of new network services should be made more efficient.

[0383] See you again Figure 18D In a network slicing scenario, WTRU 102a, 102b, or 102c can connect to AMF 172 via the N1 interface. AMF 172 can logically be part of one or more slices. AMF 172 can coordinate connections or communication between WTRU 102a, 102b, or 102c and one or more UPF 176a and 176b, SMF 174, and other network functions. Each of UPF 176a and 176b, SMF 174, and other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in terms of the different computing resources, security credentials, etc., they can utilize.

[0384] Core network 109 can facilitate communication with other networks. For example, core network 109 may include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) serving as an interface between 5G core network 109 and PSTN 108, or may communicate with an IP gateway. For example, core network 109 may include a Short Message Service (SMS) service center facilitating communication via SMS service, or may communicate with an SMS service center. For example, 5G core network 109 can facilitate the exchange of non-IP data packets between WTRUs 102a, 102b, and 102c and server or application function 188. Additionally, core network 170 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned or operated by other service providers.

[0385] The descriptions in this article and Figure 18A , 18C The core network entities illustrated in 3GPP 18D or 18E are identified using the names assigned to these entities in certain existing 3GPP specifications. However, it should be understood that in the future, these entities and functions may be identified using other names, and some entities or functions may be combined in future 3GPP specifications, including future 3GPP NR specifications. Therefore, in Figure 18A, 18B The specific network entities and functions described and illustrated in 18C, 18D or 18E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein can be implemented or realized in any similar communication system, whether currently defined or hereafter defined.

[0386] Figure 18E The diagram illustrates an example communication system 111 in which the systems, methods, and devices described herein can be used to implement traffic redirection enhancement in cellular networks. Communication system 111 may include radio transceiver units (WTRUs) A, B, C, D, E, and F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein can be applied to any number of WTRUs, base station gNBs, V2X networks, or other network elements. One or more, or all, WTRUs A, B, C, D, E, and F may be located outside the coverage area 131 of the access network. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader, and WTRUs B and C are group members.

[0387] WTRUs A, B, C, D, E, and F can communicate with each other via gNB 121 through Uu interface 129 if they are within the access network coverage 131. Figure 18E In the example, WTRUs B and F are represented within access network coverage 131. WTRUs B, C, D, E, and F can communicate directly with each other via sidelink interfaces (e.g., PC5 or NR PC5) such as interfaces 125a, 125b, or 128, regardless of whether they are within or outside access network coverage 131. For example, in Figure 18E In the example, WTRU D, which is outside the access network coverage 131, communicates with WTRU F, which is inside the coverage 131.

[0388] WTRUs A, B, C, D, E, and F can communicate with RSUs 123a or 123b via Vehicle-to-Network (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F can communicate with V2X server 124 via Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F can communicate with another UE via Vehicle-to-Pedestrian (V2P) interface 128.

[0389] Figure 18F This is a block diagram of an example device or apparatus WTRU 102 (such as...). Figure 18A , 18B WTRU 102 of type 18C, 18D, or 18E, or Figures 3-11 (For example, a UE) can be configured for wireless communication and operation according to the systems, methods, and apparatuses described herein for implementing traffic-oriented enhancements in cellular networks. Figure 18F As shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that WTRU 102 may include any sub-combination of the above elements. Additionally, base stations 114a and 114b, or nodes that base stations 114a and 114b may represent, such as, but not limited to, transceiver stations (BTS), Node-B, site controllers, access points (APs), home node-B, evolved home node-B (eNodeB), evolved home node-B (HeNB), home evolved node-B gateways, next-generation node-B (gNode-B), and proxy nodes, etc., may be included in... Figure 18F Some or all of the elements depicted herein may be exemplary implementations of the disclosed systems and methods for traffic-oriented enhancement of cellular networks disclosed herein.

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

[0391] The UE's transmit / receive element 122 can be configured to transmit data to the base station (e.g., via air interface 115 / 116 / 117). Figure 18A The base station 114a) sends signals or receives signals from the base station (e.g., Figure 18AThe base station 114a) receives signals, or transmits signals to or receives signals from another UE via air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit or receive RF signals. The transmit / receive element 122 may, for example, be a transmitter / detector configured to transmit or receive IR, UV, or visible light signals. The transmit / receive element 122 may be configured to transmit and receive both RF signals and optical signals. It should be appreciated that the transmit / receive element 122 may be configured to transmit or receive any combination of wireless signals or wired signals.

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

[0393] Transceiver 120 can be configured to modulate signals to be transmitted by transmit / receive element 122 and demodulate signals received by transmit / receive element 122. As described above, WTRU 102 can have multimode capability. Thus, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 or NR and E-UTRA, or via multiple beams to different RRHs, TRPs, RSUs, or nodes using the same RAT.

[0394] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from them. The processor 118 can also output user data to the speaker / microphone 124, keypad 126, or display / touchpad / indicator 128. Additionally, the processor 118 can access and store data from any suitable type of memory, such as non-removable memory 130 or removable memory 132. Non-removable memory 130 can include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of storage device. Removable memory 132 can include a subscriber identification module (SIM) card, memory stick, secure digital storage (SD) card, etc. The processor 118 can access and store information from memory that is not physically located in WTRU 102, such as memory hosted on a server in the cloud or edge computing platform, or memory in a home computer (not shown). Processor 118 may be configured to control the illumination mode, image, or color on display or indicator 128, or otherwise indicate the status of cellular network traffic-directing enhancement and associated components, in response to whether the settings for some of the examples illustrated herein are successful or unsuccessful. The control illumination mode, image, or color on display or indicator 128 may reflect the accompanying drawings shown or discussed herein (e.g., ...). Figure 3 Figure 8- Figure 11 The state of any one of the methods, flows, or components in (etc.). This document discloses messages and procedures for traffic-directed enhancement of cellular networks. These messages and procedures can be extended to provide interfaces / APIs for users to request resources, and request, configure, or query information related to traffic-directed enhancement of cellular networks, as well as other information that can be displayed on display 128, via input sources (e.g., speaker / microphone 124, keypad 126, or display / touchpad / indicator 128).

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

[0396] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 115 / 116 / 117, or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method.

[0397] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software or hardware modules that provide additional features, functions, or wired or wireless connectivity. For example, peripheral devices 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, etc. Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

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

[0399] Figure 18G This is a block diagram of an exemplary computing system 90, which can be embodied in... Figure 18A , Figure 18C , Figure 18D and Figure 18E The diagram illustrates one or more devices in a communication network, and traffic enhancements in the cellular networks described and claimed herein, such as... Figures 3-16The systems and methods illustrated in the diagram include certain nodes or functional entities in RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, other networks 112, or network services 113. 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. These computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, or any other function that enables the computing system 90 to operate within a communication network. The coprocessor 81 is an optional processor, distinct from the main processor 91, that can perform additional functions or assist the main processor 91. The processor 91 or the coprocessor 81 can receive, generate, and process data related to the methods and apparatus disclosed herein for traffic-oriented enhancements in cellular networks, such as receiving messages via the control plane or user plane.

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

[0401] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This memory includes circuitry that allows the storage and retrieval of information. ROM 93 typically contains data that is not easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide address translation functionality, converting virtual addresses to physical addresses when instructions are executed. The memory controller 92 can also provide memory protection functionality that isolates processes within the system and separates system processes from user processes. Thus, a program running in first mode can only access memory mapped by its own process virtual address space; unless inter-process memory sharing is configured, it cannot access memory in the virtual address space of another process.

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

[0403] A display 86, controlled by a display controller 96, is used to display visual output generated by a computing system 90. This 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 signals sent to the display 86.

[0404] Furthermore, the computing system 90 may include communication circuitry, such as a wireless or wired network adapter 97, which can be used to connect the computing system 90 to an external communication network or device, such as... Figure 18A , 18B The communication circuitry can be configured to communicate with other nodes or functional entities in the following networks: RAN103 / 104 / 105 (18C, 18D, or 18E), core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other networks 112, enabling the computing system 90 to communicate with other nodes or functional entities in these networks. Either alone or in conjunction with the processor 91, the communication circuitry can be used to perform certain transmission and reception steps of certain devices, nodes, or functional entities described herein.

[0405] It should be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, cause the processor to perform 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 that execute 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 using any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, Digital Universal Disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other tangible or physical medium that can be used to store desired information and can be accessed by a computing system.

[0406] In describing preferred methods, systems, or apparatuses for traffic redirection enhancement of cellular networks—as illustrated in the figures—specific terminology has been used for clarity. However, the claimed subject matter is not intended to be limited to these chosen specific terms.

[0407] The various techniques described herein can be implemented using a combination of hardware, firmware, software, or, where appropriate, a combination thereof. Such hardware, firmware, and software can reside in devices located at various nodes of a communication network. Devices can operate individually or in combination with each other to implement the methods described herein. The terms “device,” “network device,” “node,” “apparatus,” “network node,” etc., used herein are used interchangeably. Furthermore, unless otherwise stated herein, the use of the word “or” is generally inclusive.

[0408] This written description uses examples to disclose the invention, including the best mode, and also enables any person skilled in the art to practice the disclosed subject matter, including making and using any apparatus or system and performing any included methods. The disclosed subject matter may include other examples that would occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between exemplary methods disclosed herein).

[0409] The methods, systems, and devices described herein can provide means for traffic steering enhancement in cellular networks. The methods, systems, and devices described herein can specify that the UE includes an analysis reporting capability indicator in a request message to the network; the network generates a data analysis collection strategy; the network returns the data analysis collection strategy in a response to the UE; and the UE uses the PMF protocol to report data for analysis purposes. The UE sends a suspension request to the CN's user plane function; this request is forwarded to the session management entity and mobility management function; the mobility management function determines whether to enable communication suspension and returns session information of other UE sessions affected by the suspension to the session management entity; the session management entity notifies the user plane function of the suspension of all sessions associated with the UE; and the user plane function returns the status of the suspension request to the UE 201. The UE notifies the core network that it supports providing data for analysis and has traffic redirection capabilities; the core network generates and returns a data analysis report policy to the UE; based on performance measurement results obtained by the UE, the UE dynamically redirects UL traffic between 3GPP access and non-3GPP access; and the core network dynamically redirects DL traffic to the UE between 3GPP access and non-3GPP access based on analysis information provided by the analysis function. The UE creates a PDU session for a first USIM through a first access network, which has a multi-USIM indicator or a temporary identifier for a second USIM; the UE creates a PDU session for a second USIM through a second access network, which has a multi-USIM indicator, a temporary identifier for the first USIM, and an optional PDU session identifier associated with the first USIM; depending on access network availability, the network redirects data traffic of the first USIM to the access network of the second USIM, and vice versa; and depending on access network availability, the UE redirects data traffic of the first USIM to the access network of the second USIM, and vice versa. All combinations (including deletions or additions of steps) in this and the next paragraph can be conceived in a manner consistent with the detailed description.

[0410] The methods, systems, and devices described herein can provide means for traffic-directed enhancement of cellular networks. The collected data can also be enhanced for other purposes; for example, NWDAF can take action based on the resulting analysis and its impact on other NFs and UEs. The methods, systems, and devices described herein can specify sending a first message via a user equipment (UE), which may notify the core network (e.g., a core network server) that the UE is available or capable of collecting or sending data for analysis (e.g., data to be used in the analysis); in response to sending the first message, receiving a second message via the UE, which may include an acknowledgment of the first message or an indication of a strategy for collecting data for analysis over a period of time, wherein the strategy may be sent in the second message or a subsequent message, retrieved from another network device, or pre-configured on the UE; collecting data for analysis based on the second message (e.g., based on the strategy indication or information for a table such as Table 2 meeting a threshold); and sending the data for analysis to the network for processing for analysis based on a trigger (e.g., an elapsed time period, an event that occurred, or information for a table such as Table 2 meeting a threshold). The methods, systems, and devices described herein can specify receiving a first message via a network device, the first message indicating that the user equipment (UE) can or is capable of collecting UE-specific data for analysis by the core network; in response to receiving the first message, sending a second message via the UE to the user equipment, the second message including an indication of a policy for the UE to collect data for analysis over a period of time, wherein the policy can be sent in the second message or a subsequent message, or pre-configured on the UE; receiving the collected data for analysis; and using the collected data for analysis. The first message can be a registration request or a PDU session establishment request. The policy can provide an indication of time scheduling or the occurrence of a predefined event that triggers the collection of data for analysis. Table 5 lists the attributes of scheduled data collection. Table 6 describes the attributes of event-driven data collection. The policy can provide an indication that a data collection request can be received from the core network at any time, and that the data request triggers the collection of data for analysis. The first message can be a request message typically used for connecting to an access network. The first message can include the UE's specific ability to collect various types of data or how often data can be collected. The methods, systems, and devices described herein can specify receiving a first message from a user equipment, the first message indicating that the user equipment is capable of collecting data for analysis; in response to the first message, sending a second message, the second message containing an indication of a strategy for the user equipment to collect the data for analysis; and, based on a trigger, receiving data from the user equipment for processing for analysis, the data being collected by the user equipment based on the second message. The strategy can provide instructions for time scheduling or the occurrence of a predefined event that triggers the collection of data for analysis.All combinations (including the deletion or addition of steps) in this paragraph and the previous paragraph can be envisioned in a manner consistent with the detailed description.

Claims

1. A method for traffic steering enhancement for a wireless network by a user equipment, the method comprising: sending, to a cellular network, a first message as a multiple access, MA, packet data unit, PDU, session establishment request, the first message including an indication of support for dynamic traffic steering; in response to sending the first message, receiving a second message as a MA PDU session establishment accept, the second message including traffic steering rules for a MA PDU session and measurement assistance information, wherein the traffic steering rules are produced by a session management function, SMF; based on the second message, sending, to a user plane function, UPF, access network performance measurement results using a performance measurement function, PMF, protocol; and performing traffic steering with the UPF based on the access network performance measurement results. 2.The method of claim 1, wherein the measurement assistance information includes a policy for collecting data for analytics. 3.The method of claim 2, wherein the policy is pre-configured on the user equipment. 4.The method of claim 1, wherein the first message includes a capability of the user equipment to collect various types of data or how often the data can be collected. 5.The method of claim 2, wherein the policy provides an indication of a time schedule or occurrence of a pre-defined event that triggers collecting the data for analytics. 6.The method of claim 2, wherein the policy provides an indication of a capability to receive a data collection request from a core network at any time and a data request that triggers collecting the data for analytics. 7.The method of claim 2, wherein the policy provides an indication of a battery power threshold that triggers collecting the data for analytics. 8.The method of claim 2, wherein the policy provides an indication of a handover number threshold that triggers collecting the data for analytics. 9.The method of claim 2, wherein the policy provides an indication of a MA PDU session number threshold that triggers collecting the data for analytics. 10.A user equipment for traffic steering enhancement for a wireless network, the user equipment comprising: a processor; and a memory coupled with the processor, the memory storing executable instructions that when executed by the processor cause the processor to perform operations of the method of any of claims 1-9. 11.A method for traffic steering enhancement for a wireless network by a communication device, the method comprising: receiving, from a user equipment, a first message as a multiple access, MA, packet data unit, PDU, session establishment request, the first message including an indication of support for dynamic traffic steering; in response to receiving the first message, sending a second message as a MA PDU session establishment accept, the second message including traffic steering rules for a MA PDU session and measurement assistance information, wherein the traffic steering rules are produced by a session management function, SMF; receiving, from the user equipment, access network performance measurement results sent based on the second message using a performance measurement function, PMF, protocol; and performing traffic steering with the user equipment based on the access network performance measurement results. perform traffic steering with the user equipment based on the access network performance measurement results.

12. The method of claim 11, wherein the measurement assistance information comprises a policy for collecting data for analytics.

13. The method of claim 12, wherein the policy provides an indication of a threshold number of handovers to trigger collection of the data for analytics.

14. The method of claim 12, wherein the policy provides an indication of a data collection request and data request from a core network at any time to trigger collection of the data for analytics.

15. The method of claim 12, wherein the policy is preconfigured on the user equipment.

16. The method of claim 11, wherein the first message comprises a capability of the user equipment to collect various types of data or how often data can be collected.

17. The method of claim 12, wherein the policy provides an indication of a time schedule or occurrence of a pre-defined event to trigger collection of the data for analytics.

18. The method of claim 12, wherein the policy provides an indication of a battery level threshold to trigger collection of the data for analytics.

19. The method of claim 12, wherein the policy provides an indication of a threshold number of MAPDU sessions to trigger collection of the data for analytics.

20. A communication device for traffic steering enhancements for wireless networks, the communication device comprising: a processor; and a memory coupled with the processor, the memory storing executable instructions that when executed by the processor cause the processor to perform operations of the method of any of claims 11-19.

Images