WO2022147313A1

WO2022147313A1 - Efficient application-layer sim management on multi-sim ue

Info

Publication number: WO2022147313A1
Application number: PCT/US2021/065771
Authority: WO
Inventors: Xu Li; Dale Seed; Lu Liu
Original assignee: Convida Wireless, Llc
Priority date: 2020-12-30
Filing date: 2021-12-30
Publication date: 2022-07-07

Abstract

Methods are described for improved application-layer Subscriber Identification Module (SIM) management on Multi-SIM user equipment (UEs). For example, application- layer SIM management solutions are defined for Multi-SIM UEs for supporting different applications. In one aspect, Dynamic SIM Switching based on Application Priority is provided.

Description

EFFICIENT APPLICATION-LAYER SIM MANAGEMENT ON MULTI-SIM UE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/132,024, filed December 30, 2020, entitled “Efficient Application-Layer SIM Management on Multi-Sim UE,” which is hereby incorporated by reference in its entirety.

BACKGROUND

[0002] User equipment (UE) having multiple subscriber identification module (SIM) cards (e.g., two SIM cards) are increasing in popularity. With separate SIMs, users may easily separate activities performed on the UE, e.g., between their business subscription and their personal subscription. For example, users may separate work life (e.g., corresponding to business subscription) from private life (e.g., corresponding to personal subscription). Recent initiatives in 3GPP to study Multi-SIM UE related aspects in order to enable operators to best serve this type of UE. However, the current focus in 3GPP for Multi - SIM UEs has been on communications aspects including connectivity, paging, etc. However, there are many other application-layer aspects that need to be addressed. In particular, depending on different use cases and scenarios as well as different types of Multi-SIM UEs, the Multi-SIM UEs may have different behaviors and strategies on how to operate with or switch between different SIM cards (e.g., each SIM card corresponding to a particular mobile network operator), in order to best serve the hosted client applications on UEs.

[0003] Multiple USIM UEs and edge computing (e.g., fog computing) deployments may encompass a wide variety of scenarios, servers, gateways, and devices, such as those described in, for example: 3GPP SA Meeting #87, Contribution # SP-200297, Revised SID: Study on system enablers for multi-SIM devices, March. 2020; 3GPP Rel-17 TR 22.834 (V17.2.0, 2019-12); 3GPP Rel-17 TR 23.761 (V0.4.0, 2020-06); OpenFog Reference Architecture for Fog Computing, February 2017; and 3GPP TR 23.758 (VI.0.0 2019-10).

SUMMARY

[0004] Described herein are methods, apparatus, and systems for improved application-layer SIM management on multi-SIM UEs, which may address the shortcomings discussed above. For example, application-layer SIM management solutions are defined for Multi-SIM UEs for supporting different applications. [0005] According to some aspects, operational modes of Multi-SIM UE are provided. According to some aspects, a Dual SIM Dual Standby (DSDS) operational mode of Multi-SIM UE is provided. For example, both SIMs may be used for idle-mode network connection, but when a radio connection is active the second connection may be inactive. Moreover, a Multi-SIM UE having DSDS mode may be called a DSDS-UE.

[0006] According to some aspects, a Dual SIM Dual Active (DSDA) operational mode of Multi-SIM UE is provided. For example, both SIMs may be used in both idle and connected modes independently. Each SIM may have a dedicated transceiver, e.g., there may be no interdependencies on idle or connected mode operation at the modem level. Moreover, a multi-SIM UE having DSDA mode may be called a DSDA-UE.

[0007] For example, a number of individual aspects are provided, e.g., each aspect having a respective scenario or setting and solution. In one aspect, Dynamic SIM Switching based on Application Priority on a DSDS-UE is provided. In one aspect, Dynamic SIM Selection and Network Resource Allocation on a DSDA-UE is provided. In one aspect, SIM Alignment for facilitating group communication between Multi-SIM UEs is provided. In one aspect, Enabling Edge Server Deployments with Multi-SIM UEs is provided. In one aspect, Cross-operator Load Balancing with Multi-SIM UEs is provided.

[0008] According to some aspects, a UE may be operated in a DSDS mode. For example, the UE may include a first SIM card corresponding to a first cellular system and a second SIM card corresponding to a second cellular system. A first client application installed on the UE may be designated (e.g., by a user) to use the first SIM card and the first client application may be assigned with a service priority. One or more other client applications installed on the UE using the second SIM card may communicate with the second cellular system.

[0009] According to some aspects, the UE may collect information from the user. For example, the collected information may include metadata, context information, or trigger events. A determination may be made (e.g., by the UE based on the collected information and/or the service priority) to switch from using the second SIM card to using the first SIM card for serving the first client application. According to some aspects, whether the first client application can be served by the first SIM card may be determined (e.g., by the UE based on the collected information and/or the service priority). In an example, an advisory may be received from a network entity and determining whether the first client application can be served by the first SIM card may be based in part on the advisory from the network entity. In another example, a command may be received from a user and determining whether the first client application can be served by the first SIM card may be based in part on the command from the user.

[0010] The second cellular system of one or more affected client applications installed on the UE may be notified (e.g., based on determining the first client application can be served by the first SIM card). An acknowledgment may be received from the second cellular system. One or more actions may be performed on one or more affected client applications that are currently using the second SIM card (e.g., based on the acknowledgment from the second cellular system). The second SIM card may be deactivated (e.g., by the UE based on determining to switch from using the second SIM card to using the first SIM card for serving the first client application) and first SIM card may be activated (e.g., based on deactivating the second SIM card). The first client application may be operated using the first SIM card. The first cellular system corresponding to the first SIM card may be notified about a new launch of the first client application. An acknowledgement may be received from the first cellular system.

[0011] According to some aspects, a network entity may designate a first client application installed on a UE to use a first SIM card corresponding to a first cellular system. The UE may include a second SIM card corresponding to a second cellular system. For example, the UE may be operated in a DSDS mode. A first client application installed on the UE may be designated to use the first SIM card. The first client application may be assigned a service priority and information may be collected from the UE. The collected information may be associated with use, by one or more other client applications installed on the UE, of the second SIM card and the collected information may include metadata, context information, and/or trigger events.

[0012] According to some aspects, the network entity may determine (e.g., based on the collected information, the service priority, and/or an advisory) for the UE to switch from using the second SIM card to using the first SIM card for serving the first client application. The network entity may determine (e.g., based on the collected information and/or the service priority) whether the first client application can be served by the first SIM card. According to some aspects, a command may be received from a user and determining whether the first client application can be served by the first SIM card may be further based on the command from the user. [0013] According to some aspects, the second cellular system may be notified (e.g., based on determining the first client application can be served by the first SIM card) of one or more affected client applications installed on the UE. For example, the second SIM card may be deactivated and the first SIM card may be activated. According to some aspects, the UE may receive an acknowledgment from the second cellular system and may perform (e.g., based on the acknowledgment from the second cellular system) one or more actions on one or more affected client applications that are currently using the second SIM card. The UE may notify the first cellular system corresponding to the first SIM card about a new launch of the first client application and/or an acknowledgement from the first cellular system may be received by the UE.

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

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0016] Figure 1 shows an example of a Fog Computing System Architecture;

[0017] Figure 2(a) shows an example of a UE with Two SIM Cards and One Shared Transceiver;

[0018] Figure 2(b) shows an example of a Client Applications on UE using Edge Applications Provided by Different Operators;

[0019] Figure 3 shows an example of a Decision Flow for A UE to Decide Whether to Serve a Newly-Launched Client Application;

[0020] Figure 4 shows an example of a Procedure of Dynamic SIM Switching based on Application Priority on a DSDS-UE (e.g., When A Client Application Is Being Launched);

[0021] Figure 5 shows an example of a Procedure of Dynamic SIM Switching based on Application Priority on a DSDS-UE (e.g., When a Specific Client Application Is being Closed or Updated); [0022] Figure 6 shows an example of a Procedure of Dynamic SIM Selection based on Application Priority on a DSDA-UE (e.g., When A Client Application Is Being Launched);

[0023] Figure 7 shows an example of a Procedure of SIM Card Alignment for Facilitating Group Communication;

[0024] Figure 8 shows an example of a Procedure of Enabling Edge Server Deployments with Multi-SIM UEs;

[0025] Figure 9 shows an example of a Procedure of Cross-operator Load Balancing with Multi-SIM UEs;

[0026] Figure 10 shows an example of an Application Architecture for Multi-SIM UE Management in 3 GPP System;

[0027] Figure 11 shows an example of an Application Architecture for Multi-SIM UE Management under 3 GPP SA6 Edge Enabler Architecture;

[0028] Figure 12 shows an example of a User Interface;

[0029] Figure 13A illustrates an example communications system in which the methods and apparatuses described and claimed herein may be embodied;

[0030] Figure 13B is a block diagram of an example apparatus or device configured for wireless communications;

[0031] Figure 13C is a system diagram of an example radio access network (RAN) and core network;

[0032] Figure 13D is a system diagram of another example RAN and core network;

[0033] Figure 13E is a system diagram of another example RAN and core network;

[0034] Figure 13F is a block diagram of an example computing system; and

[0035] Figure 13G is a block diagram of another example communications system.

DETAILED DESCRIPTION

[0036] Table 0.1 describes some of the abbreviations used herein.

Table 0.1 - Abbreviations

[0037] Terms and Definitions.

[0038] The following is a list of terms that may appear in the following description. Unless otherwise specified, the terms used herein are defined as follows.

[0039] 3GPP System - The communications of Client Applications on UEs are mainly supported by the 3GPP system. When a UE has multiple SIM cards, each SIM card is associated with a specific mobile network operator (MNO). The SIM cards may be associated with the same MNO or with different MNOs. The 3GPP system may also provide computing infrastructure at its edge. In addition, the term 3GPP system of a SIM card (e.g., SIM-1 card) refers to the 3GPP system of the corresponding operator of the SIM-1 card. The following terms are used interchangeably: the 3GPP system of a particular SIM = a particular Mobile Network Operator (MNO).

[0040] Application Server - An application server is basically a server-side software for supporting the corresponding client application on UEs. Typically, an application server can either be deployed in the cloud, or an application server can be deployed in the network edge.

[0041] Client App - A client application is an application or software program that is installed on a UE. A client application can either interact with its corresponding application server, or can interact with the same type of client applications installed on other UEs.

[0042] Designated SIM - There are multiple Client Applications installed on the UE, and a client application may only use its designated SIM. For example, a UE may have two SIM cards, and one SIM card (e.g., SIM-1) is corresponding to business subscription for serving work-related client applications, and the other (SIM-2) is corresponding to personal subscription for serving private life-related client applications. In other words, the following terms are used interchangeably in this disclosure: one particular SIM = one particular subscription to the corresponding MNO. Accordingly, the work-related client applications must use SIM1 for any communication (including all the voice and data services) while the private life-related client applications must use SIM-2 for any communication. [0043] Dual SIM Dual Standby (DSDS) - Both SIMs can be used for an idle-mode network connection, but when a radio connection is active for one SIM then the radio connection is not active for the second SIM. The SIMs in a DSDS device share a single transceiver. Through time-multiplexing two radio connections are maintained, but only a single SIM can be used when the transceiver is in connected and active.

[0044] DSDS-UE - A Dual-SIM UE having DSDS mode is called a DSDS-UE. A SIM card that is currently in use is called an active SIM card while a SIM card that is currently not in use (e.g., in the standby mode) is called an inactive SIM card.

[0045] Dual SIM Dual Active (DSDA) - Both SIMs can be used in both idle and connected modes independently. Each SIM has a dedicated transceiver, meaning that there are no interdependencies on idle or connected mode operation at the modem level.

[0046] DSDA-UE - A Dual-SIM UE having DSDA mode is called a DSDA-UE.

[0047] Dual-SIM UE - A Dual-SIM UE is a type of UE having two SIM cards and it is the most popular form of Multi-SIM UE. A Dual-SIM UE can be either a DSDA-UE, or a DSDS-UE.

[0048] Edge Infrastructure - A 3GPP operator not only provides the communication infrastructure for supporting traditional call/data services, but also may have computing infrastructure built at the network edge, such as base stations, road-side small cells, etc. Software instances can be deployed at the edge infrastructure for supporting edge-related applications. For example, an application server can be deployed at the edge and become an Edge Application Server, (compared to an application server deployed in the cloud).

3GPP Multi-SIM UE Study Item

[0049] Commercially deployed devices may support more than one SIM card (e.g., typically two). For example, UEs with multiple USIMs may be applied to various use cases that take advantage of having subscriptions with two or more network operators. For example, Multi-SIM devices typically address the following two use cases: 1) The user has both a personal and a business subscription and wishes to use them both from the same device. 2) The user has multiple personal subscriptions and chooses which one to use based on the selected service (e.g., use one individual subscription and one “family circle” plan).

[0050] In one aspect, a MUSIM UE may refer to a UE with multiple SIMs that are in operation at the same time. There could be different types of Multi-SIM UEs.

[0051] For example, in one aspect, a Dual SIM Dual Standby (DSDS) Multi-Sim UE may use both SIMs may be used for idle-mode network connection, but when a radio connection is active the second connection is inactive. As in the passive case, the SIMs in a DSDS device may share a single transceiver. Two radio connections may be maintained through time-multiplexing, but only a single SIM may be used when the transceiver is in connected and active.

[0052] As another example, a Dual SIM Dual Active (DSDA) Multi-Sim UE may use both SIMs in both idle and connected modes independently. Each SIM may have a dedicated transceiver, meaning that there are no interdependencies on idle or connected mode operation at the modem level.

Edge Computing and Fog Computing

General Concept and Architecture

[0053] Edge computing may allow data produced by loT devices to be processed closer to where it is created instead of sending it across long routes to data centers or clouds.

[0054] For example, edge computing deployments may be ideal in a variety of circumstances. One example may be when loT devices have poor connectivity and it is not efficient for loT devices to be constantly connected to a central cloud. Other use cases may relate to latency-sensitive processing of information. For example, edge computing may reduce latency because data does not have to traverse over a network to a data center or cloud for processing.

[0055] In one aspect, fog may refer to the network connections between edge devices and the cloud (e.g., fog computing) and edge, on the other hand, may refer more specifically to the computational processes being done close to the edge devices (e.g., edge computing). Thus, fog computing may include edge computing, but fog computing may also incorporate the network needed to get processed data to its final destination. Fog computing, or briefly, fog, is a system-level architecture that moves resources and services including computing, storage, control and networking closer to the end-users along the continuum from Cloud to Things. For example, Figure 1 illustrates a Fog Computing System Architecture, e.g., a fog enabled continuum.

3GPP SA6 FS EDGEAPPLICATION Study Item

[0056] In one aspect, a 3GPP FS EDGEAPPLICATION study item may focus on the study of application architecture for enabling edge applications over 3GPP networks. In one aspect, this study includes identifying architecture requirements (e.g., discovery of edge services, authentication of the clients), supporting an application layer functional model, and corresponding solutions to enable the deployment of applications on the edge of 3GPP networks with minimal impact to edge-based applications on the UE. See 3 GPP Rel-17 TR 23.758.

Example Use Case

[0057] More and more people tend to use a UE having multiple SIM cards (e.g., typically two SIM cards). With separate SIMs, users may easily separate work activities from personal activities (as illustrated in Figure 2 (a)). For example, all the work-related business (e.g., calls and data services) may only use a specifically designated SIM card. Multi-USIM UEs have been in the market (e.g., especially in Asian countries such as China), but are seeing more widespread use. In the past, support for multi-USIM was mainly handled in an implementation-specific manner without any support from 3GPP specifications, but recently there are some initiatives in 3GPP to study Multi-SIM UE related aspects in order to enable the operators to best serve these types of UEs. For example, one of the requirements is that the 3GPP system should be able to allow a Multi-SIM UE to provide voice service from one USIM and data services from another USIM simultaneously, etc.

[0058] A current focus in 3GPP for Multi-SIM UE has been communications, e.g., connectivity, paging, etc. Beyond the basic connectivity-oriented aspects, there are many other aspects that need to be addressed. In one aspect, application-layer related issues are focused on and a number of technical issues are addressed from the application layer perspective. Below, the scope of this disclosure is discussed, and the following two factors are being considered and those two factors may lead to different use case scenarios and application requirements and therefore require different solutions.

[0059] Due to different implementations of cellphones, there could be different types of Multi-SIM UEs. Therefore, in one aspect considers various behaviors of different Multi-SIM UEs are considered. The following two types of UEs are studied:

[0060] Dual SIM Dual Standby (DSDS): both SIMs may be used for idle-mode network connection, but when a radio connection is active, the second connection is inactive. An example of this type of UEs is illustrated in Figure 2 (a).

[0061] Dual SIM Dual Active (DSDA): both SIMs may be used in both idle and connected modes independently. Each SIM has a dedicated transceiver, meaning that there are no interdependencies on idle or connected mode operation at the modem level.

[0062] From an application-layer perspective, various client applications may be installed on a specific Multi-SIM UE, and the intended behaviors of those client applications are also different. For example: [0063] Use Case-1 : A client application may need to interact with its server which is deployed in the cloud. Therefore, this client application needs to rely on the 3GPP system for communication. In particular, those client applications may have their own designated SIM cards, which means all of their communications have to go through the designated SIM cards respectively. For example, the traffic of all the work-related client applications may need to be served by a specific SIM card (and corresponding operator) for work usage. In the meantime, in Use Case-1, the focused UE is a DSDS type of UE.

[0064] Therefore, some fundamental application-layer technical issues in Use Case-

1 need to be addressed. For example, how can the UE best serve client applications which require use of different SIM cards. As another example, if client applications have different priorities, how can a DSDS UE dynamically switch its SIM cards in order to serve the highest-priority client app(s) using their designated SIM cards.

[0065] Use Case-2 : A client application may need to interact with its server which is deployed in the cloud. Therefore, this client application needs to rely on the 3GPP system for communication. In particular, in Use Case-2, the focused UE is a DSDA type of UE, and it is assumed that some of the client applications do not have designated SIM cards (e.g., those client applications may use any of the SIM cards).

[0066] Therefore, some fundamental application-layer technical issues in Use Case-

2 need to be addressed For example, how to split the traffic generated by all the client applications if each of the SIM cards can only provide a certain amount of network resources (such as bandwidth)? In other words, how to best serve each specific client application by selecting an appropriate SIM card for communication especially if those client applications may have certain QoS requirements. As another example, if the traffic on one SIM card is getting congested, how to offload certain traffic from one SIM card to the other SIM card.

[0067] Use Case-3 : A client application may also need to interact with its edge server, which may be directly deployed at the network edge, which is managed by the 3 GPP network operator. As illustrated in Figure 2(b), a UE-1 is a DSDS type of UE residing in Location- 1 and UE-1 is equipped with two SIM cards belonging to two different operators (e.g., Operator-1 and Operator-2) and is covered by two gNodeBs of the respective operators. There are two client applications (e.g., client app-1 and client app-2) installed on the UE-1. Client app-1 needs to interact with its corresponding edge application server- 1 which is managed and deployed in the edge infrastructure of Operator-1 (corresponding to SIM-1 card) while Client app-2 needs to interact with its corresponding edge application server-2 which is managed and deployed in the edge infrastructure of Operator-2 (corresponding to SIM-2 card).

[0068] Therefore, some fundamental application-layer technical issues in Use Case-

3 need to be addressed, e.g., in Use Case 3, it is assumed that the UE could either be a DSDS UE or a DSDA UE and its client applications do not have designated SIM cards (e.g., those client applications may use either of the SIM cards). For example, for a given application server to be deployed to the network edge (e.g., for serving a corresponding client application installed on many UEs), where should this application server be deployed, e.g., in the operator-l’s edge infrastructure or in the operator-2’s edge infrastructure? Also, how to inform the associated client applications on UEs to interact with the deployed edge application server using the correct SIM card. For example, if the application server is deployed in the operator-l’s edge infrastructure, the corresponding client application on the UEs should use the SIM-1 card for interacting with this edge application server. Moreover, if the edge infrastructure of an operator is getting overloaded, how to offload deployed edge application servers from one operator’s edge infrastructure to another operator’s edge.

[0069] Use Case-4 : A client application may need to interact with the same type of client application installed on other UEs (e.g., in the proximity) in order to support some local P2P interaction between UEs.

[0070] Therefore, some fundamental application-layer technical issues in Use Case-

4 need to be addressed. For example, assuming UEs are DSDS types of UEs, how to inform and coordinate all the related UEs to switch to the same SIM card, e.g., so that the traffic of P2P interactions can be limited just within in the same/single operator and therefore reduce the potential cross-operator traffic.

[0071] From the above discussion, it may be seen that with the different scenarios and use cases, there are a number of technical issues to be solved and currently there is no solution regarding those issues. Therefore, aspects propose corresponding new solutions accordingly.

Summary

Aspect 1 (Dynamic SIM Switching based on Application Priority on a DSDS-UE):

[0072] A UE entity is a DSDS-UE. The UE has two or more SIM cards, (e.g., a first SIM card and a second SIM card) and currently is operating on the second SIM card. The UE has an installed first client app, which may be dynamically designated to use the first SIM card by the UE, by a network-side entity/function or by a user. The first client application may also be dynamically assigned with a service priority by the UE, by a network-side function or by a user. The UE has installed one or more other client applications, which are currently using the second SIM card for communication. The UE collects various information, including metadata, context information, trigger events, or receives advisory from network-side entity or receives command from a user. Based on the collected information or received advisory/command, the UE decides to switch to the first SIM card for serving the first client application and decides whether the first client application may be served based on its current priority. If the first client application can be served, the UE notifies the second cellular system corresponding to the second SIM card about one or more client applications on the UE that are to be affected and receives an acknowledgment from the second cellular system. The UE conducts appropriate actions to one or more affected client applications that are currently using the second SIM card, deactivates the second SIM card and activates the first SIM card. The UE notifies the first cellular system corresponding to the first SIM card about the new launch of the first client app, receives an acknowledgment from the first cellular system, and starts to operate the first client application using the first SIM card.

Aspect 2 (Dynamic SIM Selection and Network Resource Allocation on a DSDA- UE):

[0073] A UE entity is a DSDA-UE. The UE has two or more SIM cards, e.g., the first SIM card and the second SIM card (the first SIM card corresponds to the first cellular system and the second SIM card corresponds to the second cellular system). The UE has an installed first client app, which is designated to the first SIM card. The UE has an installed second client app, which does not have a designated SIM card, and currently is using the first SIM card for communication and has a service priority. The UE receives a trigger to launch the first client application with a service priority, sends a request to ask the first cellular system regarding how the first client application will be served, and receives one or more potential choices regarding how the first client application will be served. The choice may include: the first client application can be served immediately with the desired QoS performance; the first client application can only be served with the minimum QoS performance; the QoS performance of the second client application needs to be downgraded in order to serve the first client application; the second client application should be served by a second SIM card; and the first client application cannot be served at this time. Based on the received options, the UE makes a decision that the second client application should be served by the second SIM card, contacts the second cellular system for serving the second client app, and receives an acknowledgment from the second cellular system. The UE starts to operate the first client application using the first SIM card with the required QoS performance and starts to operate the second client application using the second SIM card with the required QoS performance.

Aspect 3 (SIM Alignment for facilitating group communication between Multi-SIM

UEs):

[0074] A first UE entity is a Multi-SIM UE, where the UE has two or more SIM cards, e.g., the first SIM card and the second SIM card (the first SIM card corresponds to the first cellular system and the second SIM card corresponds to the second cellular system). The UE has an installed first client app, which does not have a designated SIM card. The UE receives a trigger to initiate group communication for the first client application to communicate with the first client application installed on one or more other UEs. The UE contacts the first cellular system and the second cellular system for specifying the group communication request and asks for SIM card alignment. The request may indicate which other UEs are the group communication targets, the QoS requirements for the group communication, or the operating time schedule of the first client application on the first UE for the group communication. The request also indicates the desired SIM card for the group communication between the first client application on the first UE and the first client application on other UEs, where the first cellular system and the second cellular system will further contact one or more other UEs (as the group communication targets) to inform them of the group communication request and specification as indicated by the first client application on the first UE. The UE receives an acknowledgment from the first cellular system and the second cellular system that the SIM card alignment for group communication is complete. The acknowledgment may indicate that the first client application installed on one or more other UEs (as the group communication targets) are already operating on the desired SIM card as selected by the first client application on the first UE. The UE starts to initiate group communication between the first client application on the first UE and the first client application on the other UEs through the desired SIM card.

Aspect 4 (Enabling Edge Server Deployments with Multi-SIM UEs):

[0075] A first UE entity is a Multi-SIM UE, where the UE has two or more SIM cards, e.g., the first SIM card and the second SIM card (the first SIM card corresponds to the first cellular system and the second SIM card corresponds to the second cellular system). The UE has an installed first client application and the first application is communicating with a first application server which is located in the cloud. The first application may conduct communication either through the first SIM card or through the second SIM card. The UE receives a query from the first application server for the location and cellular system coverage information of the first UE and returns a response to the first application server about the location and cellular system coverage information of the first UE. The UE receives a notification that a second application server is available in the first cellular system’s infrastructure at a first edge location. The UE obtains verification that the corresponding SIM card (e.g., the first SIM card) of the selected (e.g., the first) cellular system is active. The UE starts to operate the first client application over the corresponding SIM card (e.g., the first SIM card) of the first cellular system, where the first client application starts to communicate with the second application server at the edge infrastructure of the first cellular system. The UE obtains improved performance compared to communicating with the first application server.

[0076] A network-side entity is a first application server and sends a query to multiple UEs for the location and cellular system coverage information. The network side entity receives feedback from multiple UEs, aggregates the feedback from multiple UEs, and decides a first edge location that a second application server is to be deployed. The network side entity contacts the first cellular system and the second cellular system to query whether a second application server can be deployed on their infrastructure at the first edge location with a certain QoS performance and receives the feedback from the first cellular system and the second cellular system. The network side entity makes a final decision for deploying the second application server to which cellular system’s infrastructure at the first edge location and deploys the second application server to the selected cellular system’s infrastructure (e.g., the first cellular system’s infrastructure) at the first edge location. The second application server may better serve the UE with improved performance, e.g., reduce delay, etc.

Aspect 5 (Cross-operator Load Balancing with Multi-SIM UEs):

[0077] A first UE entity is a Multi-SIM UE, where the UE has two or more SIM cards, e.g., the first SIM card and the second SIM card (the first SIM card corresponds to the first cellular system and the second SIM card corresponds to the second cellular system). The UE has an installed first client application and the first application is communicating with a first edge application server which is deployed in the edge infrastructure of the first cellular system. The UE receives a query from the first cellular system whether the UE is willing to use the second SIM card for serving the first client application and returns a response to the first cellular system that the UE is willing to use the second SIM card for serving the first client application. The UE receives a notification that a second edge application server is available in the second cellular system’s infrastructure at a first edge location and makes sure the second SIM card (corresponding to the second cellular system) is active. The UE starts to operate the first client application over the second SIM card, where the first client application starts to communicate with the second application server at the edge infrastructure of the second cellular system.

[0078] A cellular system is a first cellular system server and sends a query to multiple UEs to ask each UE whether the UE is willing to use the second SIM card for serving the first client application. The cellular system receives a response from each UE that it is willing to use the second SIM card for serving the first client application and aggregates the feedback from multiple UEs. The cellular system decides a first edge location that a second edge application server is to be deployed and negotiates with the second cellular system for deploying a second edge application server on the edge infrastructure of the second cellular system at the first edge location (with a certain QoS performance). The cellular system sends a deployment request message to deploy a second edge application server on the edge infrastructure of the second cellular system at the first edge location and receives from the second cellular system that the second edge application server is ready for use.

The Overview of the Proposed Solutions

[0079] In one aspect, the terms SIM and USIM are used interchangeably. See TR 22.834. In one aspect, the term multi-SIM is used to refer to multiple USIMs.

[0080] A number of individual aspects are proposed and each of them has respective use case scenarios, assumptions, and solutions. In addition, the terms SIM and USIM may be used interchangeably. See TR 22.834. In addition, the term Multi-SIM may be used to refer to multiple USIMs.

[0081] The below aspects are mainly defined in the case of a Dual-SIM UE, but those aspects are also applicable to the general Multi-SIM UE case.

[0082] In addition, the following terms may be used interchangeably: the 3GPP system of a particular SIM may be equivalent to a particular Mobile Network Operator (MNO); One particular SIM may be equivalent to one particular subscription to the corresponding MNO. Aspect 1 (Dynamic SIM Switching based on Application Priority on a DSDS-UE)

[0083] Use Case Scenario: This scenario has the following settings: 1) A UE is a DSDS-UE, which means only one SIM can be in active at a time; 2) There are multiple Client Applications installed on the UE, and in a basic case, each application can only use its designated SIM. For example, a user may have a UE with two SIM cards, and one SIM card (e.g., SIM-1) is corresponding to business subscription for serving work-related business, and the other (e.g., SIM-2) is corresponding to personal subscription for serving private life- related business. In other words, the work-related client applications have to use SIM1 for any communication (including all the voice and data services) while the private life-related client applications have to use SIM-2 for any communication; Note that, in a more advanced case, the designated SIM can be changed dynamically as well. In particular, different scenarios for how to set a designated SIM for a given client application are listed in Table 1. In the meantime, when conducting the SIM designation for a given client app, there could be different ways for how to select a SIM for a particular client application as its designated SIM and those potential ways are listed in Table 2 (which is not an exhaustive list and can also be extended). 3) Those client applications (no matter they are work-related or private life related) may have different and dynamic service priorities for being served. For example, a particular work-related client app-1 may have the highest priority during 9am-5pm Monday- Friday (such as a work-related conference app) in the sense that as long as this work-related client app-1 is being launched for use on the UE, its communication request should be immediately served. In comparison, another private life-related client application (such as an entertainment video streaming app) may have the highest priority during the weekend. To be more general, the user may also dynamically assign a service priority to a client app-1 (otherwise, a default priority may be assumed). Alternatively, there could be other ways for assigning a service priority to a particular client application. Accordingly, Table 3 lists several potential ways based on setting the service priority. 4) On the operator side, the operator may differentiate the traffic of various client applications by conducting certain management optimizations for that traffic based on their respective priorities.

Table 1. SIM Card Designation Approaches

Table 2. SIM Card Selection Criteria When Designating a SIM Card to A Specific Client App

Table 3. Different Ways for Configuring Service Priority for A Client App

[0084] From an application-oriented perspective (which is the focus of this disclosure), a specific client application (client app-1) can interact with its corresponding application server, which can only be accessed through a designated SIM card (e.g., SIM-1 card) only when SIM-1 card is in active mode, not in standby mode. In other words, client app-1 cannot interact with its application server when UE is just occasionally switched to SIM-1 card to receive pages (e.g., if in most of the time, the UE-1 chooses to be operating over the SIM-2 card). This aspect justifies the major novelty of the proposed aspect-1 from the existing works only focusing on connection-oriented aspects.

[0085] Features of Aspect 1: Features of Aspect- 1 are as follows:

[0086] For a given client application (e.g., client app-1), when it is installed on a DSDS-UE, the user needs to categorize this client app-1 and assign it with a designated SIM, e.g., it is a work-related client application or a private life-related client application. The client app-1 will have a designated SIM for serving all its communication requests. Note that, for easy illustration, in one aspect client app-1 is assigned with a designated SIM based on static designation as shown in Table 1, but all the proposed aspects can also be applied to other scenarios where the client app-1 is assigned with a designated SIM using other approaches shown in Table l.The UE stores the designated SIM information of all the client applications installed on the UE.

[0087] The UE can monitor various events or collect various context information, such that those events or context info can serve as triggers for initiating potential SIM switching operations. In particular, those example triggers are listed in Table 4, which is not an exhaustive list.

Table 4. Various Trigger Conditions for Initiating SIM Switching Operation

_ _

[0088] Every time any of the trigger conditions shown in Table 4 are met (assuming client app-1 is the focused/involved client app), the UE needs to conduct the following actions:

[0089] If the currently active SIM being used by the UE is the designated SIM for the client app-1, the client app-1 can immediately be served with its corresponding priority. [0090] Otherwise (e.g., client app-1 needs to use a SIM card which currently is inactive), the UE will check whether there are other client applications in use (e.g., operating via another SIM) that have an equal or a higher priority than client app-1 :

[0091] If no, it means client app-1 now has the highest priority, and then UE will conduct the following actions:

[0092] Inform all the launched client applications that are currently using the active SIM (e.g., SIM-2) of the upcoming, disconnections due to the SIM card switching.

[0093] Those launched client applications using SIM-2 may conduct certain wrap- up actions, for example:

[0094] Contact their corresponding application servers to halt/suspend certain tasks.

[0095] Those client applications will be configured appropriately. For example, those potential configurations may include: 1. Those client applications may get closed. 2. Those client applications may run in the background, e.g., they will not communicate with their respective servers, but users may still use them locally.

[0096] Those client applications may also indicate the UE that next time when the UE switches SIM again (e.g., switch back to SIM-2 card in this example), whether those client applications like to be restarted automatically.

[0097] Contact the 3GPP operator (e.g., certain NFs in the 3GPP Core Network) to report this event so that operator can also make corresponding adjustments, e.g., to release network resources reserved for those client applications.

[0098] UE also records which client applications have been configured (as well as which type of configurations) during this switching.

[0099] Switch active status of the SIM cards on the UE, e.g., to activate SIM-1 and de-active SIM-2.

[00100] The UE launches client app-1. The UE may also advise the user (e.g., popup certain notifications) whether to re-configure other client applications, which are designated to SIM-1 card but were configured to not operate on the SIM-2 card during a previous SIM card switching (e.g., the last SIM card switching was to switch from SIM-1 card to SIM-2 card). Alternatively, this process can also be conducted automatically. Any of those re-started client applications needs to be set with anew priority.

[00101] Communicate with the Core Network of SIM-1 about the newly -launched client app-1 (as well as other re-started client applications if exists) and the newly-assigned priorities. The Core Network of SIM-1 will record this information for further usage. For example, the operator may conduct optimizations on their management based on the priority list (e.g., to allocate more network resources to a high-priority client app, etc.).

[00102] If yes, it means client app-1 does not have the highest priority, as a result client app-1 will not be served at this time (certain notifications can be sent to inform the user that client app-1 cannot be served at this time.).

[00103] A complete and formal decision flow of UE-1 for the above process is shown in Figure 3, and the details of the decision process have been introduced regarding aspect 1. Note that, to be more general, in Figure 3, the trigger condition (e.g., “for a newly- launched client app-1”) can also be changed to other trigger conditions as listed in Table 4.

[00104] For any time when a client application in use (e.g., client app-1) is being closed (e.g., the user is about to close this application or UE is about to close this application because it has been idle for a long time) or when a new priority is assigned to it, the UE needs to conduct the following actions:

[00105] In the case where the client app-1 is being closed, the UE will communicate with the Core Network of SIM-1 in order to indicate that the client app-1 is now being closed and its current priority is also voided.

[00106] In case where the client app-1 is assigned with a new priority, the UE will communicate with the Core Network of SIM-1 in order to indicate that the client app-1 now has a new priority.

[00107] In the case where a specific client application is being launched on the UE, the detailed procedure design is illustrated in Figure 4:

[00108] Pre-condition: UE-1 is a DSDS-UE (having two SIM cards, e.g., SIM-1 card and SIM-2 card) and a UE-1 is currently using the SIM-2 card. There are multiple client applications installed on UE-1. Some of the client applications are designated to SIM-1 card (such as client app-1) while some other client applications are designated to SIM-2 card (such as client app-2). Currently, Client App-2 is interacting with its corresponding Application Server-2 through the SIM-2 card.

[00109] Step 1: Client App-1 is launched, which is assigned with a high priority. Note that, the trigger condition in step 1 (e.g., when client app-1 is launched), is just one of the example trigger conditions as listed in Table 4. Therefore, the proposed procedure is not only limited to this parti cular/example trigger condition and all other trigger conditions may also be applied in Step 1. For example, the client app-1 can either be launched by the user manually, or the client app-1 can be launched automatically due to a work schedule. In the meantime, when launching the client app-1, it will be assigned with a service priority for this launch. For example, if client app-1 is a meeting video conference application and needs to support important work meetings during the work time, this client application will be assigned with the highest priority. Such a priority means: 1) this client application needs to be served immediately using its designated SIM card; 2) For better serving this client app, sufficient network resources should also be allocated to this client application.

[00110] Step 2: Based on priority, UE-1 decides that it needs to switch from Sim-2 card to SIM-1 card and launches client app-1. More specifically, the UE-1 may have an application status table which may record the following information:

[00111] Which client applications are currently being used.

[00112] For each of those running client applications, what are their designated SIM card, which in fact should be the SIM card that currently is in active status.

[00113] For each of those client applications, what their priorities respectively are.

[00114] Accordingly, UE-1 may check the following things:

[00115] 1) whether the currently active SIM card is the same as the designated SIM card of the newly -launched client application. In the above example, the UE-1 is currently using a SIM-2 card (meaning SIM-2 card is active) but the designated SIM card of client app- 1 is a SIM-1 card.

[00116] 2) whether the newly -launched client application has a higher priority over other client applications in use. In the above example, it is assumed that the client app-1 is assigned with the highest priority, and therefore, client app-1 should be served.

[00117] Based on the above, the UE-1 may decide that UE-1 needs to serve client app-1 and in order to serve it, the UE-1 also needs to switch SIM card from SIM-1 card to SIM-2 card.

[00118] Step 3a: UE-1 can proactively notify the 3GPP system of SIM-2 card for the upcoming closure of PDU sessions used by the client applications (such as client app-2 in this example) that are currently using SIM-2 for communication. The following information can be carried in the request:

[00119] The PDU sessions used by those client applications are to be closed.

[00120] The actions to be done by the 3GPP system for each of PDU sessions used by those client applications. For example:

[00121] The client app-2 may ask the 3GPP system to release all the network resources allocated to the specific PDU session or a data flow related to client app-2. For example, in the 3 GPP system, such a data flow may correspond to a QoS flow or a network slice in the access and core network.

[00122] In an advanced scenario, the client app-2 may ask the 3GPP system to set up a proxy for itself, so that this proxy can help to receive messages from the corresponding application server-2, caches certain notifications when the client app-2 is closed by UE-1 during the usage of SIM-1 card.

[00123] It is worth noting that from a connection-oriented perspective, as a DSDS- UE, although UE-1 is to operate on a SIM-1 card, UE-1 itself may still occasionally receive pages from the 3GPP system of the SIM-2 card. However, from an application-oriented perspective (which is the focus of this disclosure), a specific client application can interact with its corresponding application server through the designated SIM card only when the designated SIM card is in active mode, not in standby mode. In other words, client app-2 cannot interact with application server-2 when UE-1 just occasionally switches to SIM-2 card to receive pages (e.g., in most of the time, the UE-1 is operating over the SIM-1 card).

[00124] Step 3b: Depending on the specific implementations of the client applications (e.g., client app-2 in this example), optionally UE-1 can also proactively notify corresponding application servers (e.g., application server-2) for the upcoming configuration of those client applications on the UE (For example, 1. Those client applications may get closed. 2. Those client applications may run in the background, e.g., they will not communicate with their respective servers, but users may still use them locally.). In this way, the application servers may have a better understanding of the status of their client applications, compared to sudden disconnections due to a hard SIM card switching (With this approach, the application servers may need to detect the unreachability of their client applications).

[00125] Step 4a: Based on the indication and information sent from Step 3a, the 3GPP system of SIM-2 card needs to conduct corresponding adjustments and actions accordingly. In addition, the 3GPP system will void all the priorities of those client applications that are currently operating on SIM-2.

[00126] Step 4b: Alternatively, depending on the specific implementation of application servers (e.g., application server-2), they may also conduct certain adjustments for the upcoming closure of client applications, such as client app-2.

[00127] Step 5a: The 3GPP system of SIM-2 sends an acknowledgment to UE-1. [00128] Step 5b: The application server (e.g., application server-2) sends an acknowledgment to UE-1.

[00129] Step 6: UE-1 closes all the client applications designated to SIM-2 card (e.g., client app-2) and switches from SIM-2 card to SIM-1 card. Now, UE-1 is operating on the SIM-1 card.

[00130] Step 7: UE-1 notifies the 3GPP system of the SIM-1 card for the newly- launched app-1. The following information can be carried in the request:

[00131] The newly -launched client app, e.g., client app-1. The 3GPP system needs to add a new record for client app-1 including its assigned service priority. For example, the 3GPP system needs to allocate appropriate network resources allocated to the specific QoS flow related to client app-1.

[00132] Alternatively, in this step, UE-1 may notify the 3GPP system of the SIM-1 card for multiple newly -launched applications. In other words, the UE-1 may decide to start multiple client applications that are designated to the SIM-1 card.

[00133] Step 8: Based on the indication and information sent from Step 7, the 3GPP system of SIM-1 card needs to conduct corresponding adjustments and actions. For example:

[00134] 3GPP system needs to allocate appropriate network resources and conduct necessary configurations to the data flow related to client app-1.

[00135] In an advanced scenario, the 3GPP system needs to check whether a proxy has been set up for client app-1 during a previous SIM switching (this proxy can help to receive messages from the corresponding application server- 1, caches certain notifications when the UE was using SIM-2 card). If so, the 3GPP system may choose to close this proxy and also try to deliver any pending notifications or cached messages to the client app-1.

[00136] In the case where the client app-1 requires certain edge computing resources, the 3GPP system also needs to assign certain edge computing resources/capabilities to the client app-1, and potential activities may include:

[00137] Set up an edge computing server

[00138] Register to an edge configuration server

[00139] Deploy an edge working instance

[00140] Any other potential activities done by the 3GPP system for serving client app-1.

[00141] Step 9: The 3GPP system of SIM-1 sends an acknowledgment to UE-1. [00142] Step 10: The Client App-1 interacts with its corresponding Application Server- 1 through the SIM-1 card.

[00143] In the case where a specific client application is being closed or the client application’s priority is being updated (based on the approaches as listed in Table 3), the detailed procedure design is illustrated in Figure 5:

[00144] Pre-condition: UE-1 is a DSDS-UE (having two SIM cards, e.g., SIM-1 card and SIM-2 card) and a UE-1 is currently using the SIM-1 card. There are multiple client applications installed on UE-1. Some of the client applications are designated to SIM-1 card (such as client app-1) while some other client applications are designated to SIM-2 card (such as client app-2). Currently, Client App-1 is interacting with its corresponding Application Server- 1 through the SIM-1 card.

[00145] Step 1: Client App-1 is being closed by the user or client app-1 is being assigned with a new priority.

[00146] Step 2: The UE-1 may also send a notification to the application server-1 of client app-1 in case the client app-1 is being closed. Note that, when a client app-1 is closed, it may not lead to a SIM card switching because it is assumed that all other currently -running client applications should be the ones that are designated to SIM-1 card. But if the closure of client app-1 may trigger UE to open some other applications designated to SIM-2 card, then SIM card switching may happen by using the procedure as shown in Figure 4 if those client applications has the highest priority.

[00147] Step 3: UE-1 proactively notifies the 3GPP system of SIM-1 card for the upcoming closure of client app-1 in case the client app-1 is being closed by the user or UE-1 proactively notifies the 3GPP system of SIM-1 card for the new priority of client app-1 in case the client app-1 is being assigned with a new priority.

[00148] Step 4: Based on the indication and information sent from Step 2, the 3GPP system of SIM-1 card needs to conduct corresponding adjustments and actions accordingly. For example, in case the client app-1 is being closed by the user, the 3GPP system will release all the allocated network resources and corresponding network configuration for client app-1. In case the client app-1 is assigned with the new priority, the 3GPP system will also re-adjust the allocated network resources for client app-1 and corresponding network configurations. Another example, if client app-1 is not going to access an edge application server deployed in the 3GPP system, the edge application server inside the 3GPP system can release certain computing resources for this client app-1. [00149] Step 5: The 3GPP system of SIM-1 sends an acknowledgment to UE-1.

Aspect 2 (Dynamic SIM Selection and Network Resource Allocation on a DSDA-UE)

[00150] Use Case Scenario: This scenario has the following settings: 1) A UE is a DSDA-UE, which means two SIM cards can be in use at the same time (this is the essential difference with Aspect 1 and requires a new and different solution); 2) There are multiple Client Applications installed on the UE, and applications can be assigned with a designated SIM in different ways (as shown in Table 1). For example, a user may have a UE with two SIM cards, and one SIM card (e.g., SIM-1) is corresponding to business subscription for serving work-related business, and the other (e.g., SIM-2) is corresponding to personal subscription for serving private life-related business. In other words, the work-related client applications have to use SIM1 for any communication (including all the voice and data services) while the private life-related client applications have to use SIM-2 for any communication; In the meantime, some other applications can either use SIM-1 or SIM-2, such as navigation and map application (which can be used for both work and private life purpose), etc. 3) Those client applications (no matter if they are work-related or private life related) may have different and dynamic service priorities for being served. To be more general, there could be other ways for assigning a service priority to a particular client application. Accordingly, Table 3 listed all the potential way regarding how to set the service priority. In the meantime, each application may have some QoS requirements for its needed network resources, such as cellular bandwidth; 4) On the operator side, the operator may differentiate the traffic of various client applications (e.g., as different QoS flow) and allocate appropriate network resources (such as bandwidth) based on their priorities and the QoS requirements. Overall, aspect 2 also adopts the “SIM card selection criteria” as proposed in Table 2.

[00151] Features of Aspect 2: Features of Aspect 2 are as follows:

[00152] For a given client application (e.g., client app-1), when it is installed on a DSDA-UE, the user needs to categorize this client app-1. Optionally, the user may assign client app-1 with a designated SIM, e.g., it is a work-related application or a private life- related application. If not assigned, it means the client app-1 can use both SIM cards. In addition, client app-1 may have QoS requirements for the needed network resources, such as minimum bandwidth requirements of the cellular networks, etc.

[00153] The UE can monitor various events or collect various context information, such that those events or context info can be used as triggers for initiating potential SIM switching operations. Table 4 defines several types of triggers. [00154] Each time a trigger condition shown in Table 4 is met (assuming client app- 1 is the focused/involved client app), the UE conducts the following actions:

[00155] 1) If the client app-1 does not have a designated SIM card, UE needs to check with the two operators (e.g., some NFs in the Core Network) regarding whether client app-1 can have a QoS guarantee for the desired network resources. 2) If the client app-1 has a designated SIM card, UE only needs to check with the operator of its designated SIM or the preferred SIM respectively.

[00156] Operator(s) will return their QoS related performance parameters regarding how client app-1 will be served, For example, the cases may include: 1) the client app-1 can be served immediately with minimum QoS guarantee, or 2) the client app-1 can be served immediately with desired QoS guarantee, or 3) the client app-1 can be served by downgrading the QoS of another client app-2 or even closing of client app-2 (e.g., the allocated network resources of client app-2 will be partially or totally re-allocated to client app-1 due to its high priority); or 4) the client app-1 cannot be served at this time.

[00157] The UE will examine the plan(s) returned by the operator(s), and then:

[00158] in case client app-1 does not have a designated SIM, UE decides whether client app-1 can be served and which SIM card should be used for serving client app-1 (e.g., UE will conduct a SIM selection for the client app-1).

[00159] For the selected SIM for serving client app-1, further decides which client applications should be closed in order to release more network resources to be allocated to client app-1.

[00160] For the selected SIM for serving client app-1, further decides whether to offload some client applications from the selected SIM card to the other. For example, UE may decide to serve client app-1 using the SIM-1 card and at the same time, the UE may offload another client app-2 (currently using SIM-1 card) to SIM-2 card (assuming client app-2 can use both SIM cards for communications).

[00161] After the determination, UE may start to serve client app-1 based on its SIM card selection.

[00162] Operators may monitor the performance/status of its serving client applications and report to UE when any of client applications cannot be served with guaranteed QoS in order to let UE further decide what actions to be made.

[00163] In the case where a specific client application is being launched on the UE, the detailed procedure design is illustrated in Figure 6: [00164] Pre-condition: UE-1 is a DSDA-UE (having two SIM cards, e.g., SIM-1 card and SIM-2 card). There are multiple client applications installed on UE-1. Some of the client applications have designated SIM cards (such as client app-1) while some other client applications do not have designated SIM (such as client app-2). Now, Client App-2 is using the SIM-1 card for communication.

[00165] Step 1: Client App-1 is launched, which is assigned with a priority (note that, the trigger condition in step 1, e.g., “when client app-1 is launched”, is just one example trigger condition as listed in Table 4. Therefore, the proposed procedure does not mean to be only limited to this parti cular/example trigger condition and other trigger conditions may also be applied in Step 1). In particular, client app-1 has a designated SIM, e.g., SIM-1 card, therefore, UE-1 needs to contact the 3GPP system of SIM-1 card regarding how client app-1 will be served.

[00166] Step 2: UE-1 contacts the 3GPP system of the SIM-1 card regarding how client app-1 will be served. The following information can be carried in the request:

[00167] The client application to be started, e.g., client app-1.

[00168] The QoS requirements of client app-1.

[00169] The operating time schedule of client app-1.

[00170] Alternatively, in case client app-1 does not have a designated SIM card, then, UE-1 will contact the 3GPP systems of all its SIM cards, including SIM-1 card and SIM-2 card.

[00171] Step 3: The 3GPP system of SIM-1 card evaluates the request sent from UE-1 as well as client app-l’s priority, and come up with the proposal or plan regarding how client app-1 will be served. For example, it may have the following cases:

[00172] the client app-1 can be served immediately with minimum QoS guarantee (when the 3GPP system now has network resources but can only guarantee minimum QoS requirement), or

[00173] the client app-1 can be served immediately with the desired QoS guarantee (when the 3 GPP system now has sufficient network resources), or

[00174] the client app-1 can be served by downgrading the QoS of another client app-2 or even closing of client app-2 (e.g., the allocated network resources of client app-2 will be partially re-allocated to client app-1 due to its high priority); or

[00175] the client app-1 should be offloaded to another 3GPP system if possible (e.g., all the current client applications using SIM-1 have the higher priority than client app-1 and they already use up all the network resource of the 3GPP system of SIM-1 card, and therefore no network resource can be allocated to client app-1), or

[00176] the client app-1 cannot be served at this time.

[00177] Step 4: The 3GPP system of the SIM-1 card returns the plan to the UE-1 for its decision.

[00178] Step 5: The UE-1 receives the plan or proposal sent from the 3GPP system of SIM-1 card and evaluate which one is the best choice. In particular, the SIM card selection criteria will be considered for both client app-1 and client app-2. Accordingly, the UE-1 makes a decision regarding how client app-1 should be finally served. For example, in this example, UE-1 may decide to offload client app-2 (because client app-2 does not have a designated SIM card) to another 3GPP system of SIM-2 card in order to serve client app-1.

[00179] Step 6: The UE-1 contacts the 3GPP system of SIM-2 card about offloading client app-2, along with the QoS requirements. In particular, offloading client app- 2 may have different implementations, for example:

[00180] If the client app-2 intends to connect to its corresponding application server (which is not hosted within the 3GPP system, e.g., an application server on the Internet), then such an offloading mainly refers to establishing a new PDU session through the 3GPP system of SIM-2 so that the client app-2 can communicate with its application server through the SIM-2 card.

[00181] If the client app-2 intends to connect its corresponding application server (which is hosted within the 3GPP system, e.g., an application server inside the core network), then such an offloading mainly refers to 1) creating/discovering anew compatible application server inside the 3GPP system of the SIM card, and 2) establishing a new PDU session in the 3GPP system of SIM-2 so that the client app-2 can communicate with the new application server through the SIM-2 card.

[00182] Step 7: The 3GPP system of the SIM-2 card will evaluate the request. And if agrees, it will start to prepare for serving the client app-2.

[00183] Step 8: The 3GPP system of SIM-2 sends an acknowledgment to UE-1.

[00184] Step 9: The UE-1 informs the 3GPP system of the SIM-1 card about its decision. For example, in this example, UE-1 decided to offload the client app-2 from SIM-1 card to SIM-2 card. [00185] Step 10: Once receiving the decision of UE-1, the 3GPP system will conduct corresponding actions. For example, in this example, the 3GPP system will release all the resources allocated to client app-2 and also void the priority of client app-2.

[00186] Step 11: The 3GPP system of SIM-1 sends an acknowledgment to UE-1.

[00187] Step 12: Client app-1 is now using SIM-1 card for communication while Client app-2 is now using SIM-2 card for communication

[00188] It is worth noting that the two 3GPP systems can periodically monitor the performances of the client applications served by them respectively and if at a later time a specific client application cannot acquire sufficient network resources and cannot have guaranteed the QoS, the 3GPP system also can report such an event to the UE-1 and let UE-1 decide how to serve this client application. Accordingly, the procedure illustrated in Figure 6 can be fully re-used with the following minimum modifications:

[00189] Precondition: Client app-1 is using the SIM-1 card for communication and the 3GPP system of SIM-1 card is also monitoring the performance of the SIM-1 card.

[00190] Step 1: A 3GPP system (e.g., 3GPP system of SIM-1 card) identifies that a particular client application (client app-1) cannot have desired QoS performance, and comes up with a proposal or plan regarding how client app-1 will be served. For example, it may have the following cases:

[00191] the client app-1 can be served by downgrading the QoS of another client app-2 or even closing of client app-2 (e.g., the allocated network resources of client app-2 will be partially or totally re-allocated to client app-1 due to its high priority); or

[00192] the client app-1 should be offloaded to another 3GPP system if possible, or [00193] the client app-1 cannot be served anymore.

[00194] The later steps are as same as the steps 4-12 in Figure 6.

Aspect 3 (SIM Alignment for facilitating group communication between Multi-SIM

UEs)

[00195] Use Case Scenario: This scenario has the following settings: 1) A UE could either be a DSDS-UE or a DSDA-UE; 2) There are Client Applications installed on the UE, and those applications can either use SIM-1 or SIM-2. 3) A client app-1 may need to conduct group communication with the client app-1 installed on other UEs (e.g., for group data sharing, etc.) and no central application server is used, e.g., the group communication is conducted in a P2P manner (e.g., the data does not have to be first routed to the application server, and then forwarded to its destination). [00196] Features of Aspect 3: Features of Aspect 3 are as follows:

[00197] For a given client application (e.g., client app-1), when it intends to communicate with the same type of applications on other UEs, it is better to limit the traffic within the same operator (so that communication costs and overhead can be reduced, compared to the cross-operator communication). For example, if client app-1 on UE-1 intends to share data with a client app-1 on other proximal UEs, it is preferred that data communication is limited to a local area. In order to do that, a solution is to inform all the involved UEs to let their respective client app-1 operate over the same SIM card as client app-1. In doing this, most of the group communications can be performed using only local communication, or at least communication within the same operator network.

[00198] When a client application (e.g., client app-1) on UE-1 intends to conduct group communications with the same type of client applications on other UEs, the UE needs to conduct the following actions,

[00199] UE-1 first decides which SIM card should be used for serving the client app-1 (e.g., SIM-1 card).

[00200] UE-1 sends a group communication request to the operators of all its SIM cards (e.g., a new SIM card alignment NF in the Core Network) and the information may include 1) a selected SIM card for group communication of client app-1, 2) a UE list.

[00201] Some UEs may be already running client app-1, in this case, it is known which SIM card is being used by the client app-1 (based on the PDU session). If client app-1 is already using the SIM-1 card, then those UEs do not need to be notified. However, there are another two cases that UEs need to be notified: 1) For those UEs that are already running the client app-1, but over SIM-2 card; 2) Some UEs may not start/open client app-1 yet. In both two cases, both of the operators send a broadcast notification to all the involved UEs in order to ask those UEs to operate their client app-1 on the selected SIM card, e.g., SIM-1 Card.

[00202] After receiving such notifications, those involved UEs may make adjustments accordingly and start to operate client app-1 on the SIM-1 card.

[00203] The operators will collect the acknowledgments from the involved UEs and return an acknowledgment to UE-1 that all the involved UEs already or will operate their client app-1 on the SIM-1 card.

[00204] UE-1 may start to serve client app-1 through the selected SIM card, e.g.,

SIM-1 card. [00205] UE-1 sends out a group communication message through SIM-1.

[00206] The detailed procedure design for SIM card alignment for facilitating group communication is illustrated in Figure 7:

[00207] Step 1: Client App-1 on UE-1 wants to send group communication messages to client app-1 on other UEs.

[00208] Step 2: UE-1 decides which SIM card to use for this group communication (e.g., SIM-1 card). In other words, the group messages of client app-1 are to be sent through the SIM-1 card. In the meantime, UE-1 also decides which UEs are the group message recipients, e.g., the group messages are to be delivered to the client app-1 on those receipt UEs.

[00209] Step 3: UE-1 contacts the 3GPP systems of both SIM-1 and SIM-2 cards about the group communication request. The following information can be carried in the request:

[00210] The client application initiating the group communication, e.g., client app- 1.

[00211] The recipient UEs which are to receive the group messages.

[00212] The QoS requirements for the group communication.

[00213] The operating time schedule of client app-1 on UE-1 for the group communication.

[00214] Note that, this message will be sent to the 3GPP systems of both SIM-1 card and SIM-2 cards. The reason is that it is not known currently which specific SIM cards are used by recipient UEs.

[00215] Step 4: For the whole step 4, it can be conducted by a new proposed NF in the 3GPP system, e.g., defined as “SIM card alignment NF” in the 3GPP Core Network. In particular, after receiving the group request from Step 3, each of the 3GPP systems of both SIM-1 and SIM-2 cards will check among all the recipient UEs, which ones are using SIM-1 card and which ones are using SIM-2 card. After that, they will individually contact the involved UEs for the group communication request and indicate the SIM card to be used for the group communication (In this example, it is SIM-1 card). In general, if a UE is a DSDS- UE, then a specific recipient UE may not receive two different messages from the two 3GPP systems, because at any time, a UE can only have one active SIM card, and the corresponding 3GPP system of that active SIM card will deliver the message to the UE. However, if a UE is a DSDA-UE, it is possible that the UE may receive two same messages from the two 3GPP systems of both SIM cards. In such a case, the UE just needs to ignore the repetitive message.

[00216] Step 5: For each involved UE, after receiving the group communication request, they will evaluate the request and decide whether to accept the request. For example, if a UE is a DSDS-UE, it is possible that there may be more important communication that has to use a different SIM-2 card. In this case, this UE may not agree to switch to SIM-1 card for supporting group communication for client app-1. In such a case, it will reject the request.

[00217] If a UE agrees to accept the group communication request, it needs to complete the following actions:

[00218] If a UE is a DSDS-UE, it needs to make its SIM-1 card active, e.g., operating on the SIM-1 card.

[00219] If a UE is DSDA-UE, then it needs to make sure its client app-1 operates on the SIM-1 card.

[00220] In addition, the UE needs to make sure its respective client app-1 has already been opened or started.

[00221] In this example, UE-2 agrees to the group communication request and starts to operate its client app-1 using the SIM-1 card.

[00222] Step 6: The recipient UEs send acknowledgments to the 3GPP systems.

[00223] Step 7: The 3GPP systems send acknowledgments to UE-1. Also, for the UE, it may switch to different operators in order to receive the acknowledgments.

[00224] Step 8: Client app-1 on UE-1 is now sending group messages to client app- 1 on other UEs using the SIM-1 card. Note that, in case some of the recipient UEs may reject the group communication request through the SIM-1 card (as discussed in Step 5), then the UE-1 may choose other approaches for delivering messages to those UEs.

[00225] Step 9: The group message will go through the 3GPP system of the SIM-1 card and finally will be delivered to the recipient UEs.

[00226] Aspect 4 (Enabling Edge Server Deployments with Multi-SIM UEs)

[00227] Use Case Scenario: This scenario has the following settings: 1) UEs have dual SIM cards, which belong to two different operators (e.g., operator-1 corresponds to SIM-1 card while operator-2 corresponds to SIM-2 card); 2) There are Client Applications installed on the UEs, and those client applications need to communicate with their corresponding application servers (which may be deployed in the cloud). 3) for the application servers, they may need to be re-deployed to the network edge by instantiating new server instances (e.g., edge application servers) in order to provide improved QoS. In other words, the client applications do not have to communicate with the servers in the cloud but instead they communicate with the edge application servers. However, operators own their own edge computing infrastructure, which may also have different workloads and availability. Therefore, where to deploy the edge sever, e.g., to which operator’s edge, is to be decided.

[00228] Features of Aspect 4: Features of Aspect-4 are as follows:

[00229] For a given application server (e.g., application server- 1), it was originally deployed in the cloud but now needs to be deployed to the network edge in order to provide better services to a particular group of UEs hosting a corresponding client application (e.g., client app-1).

[00230] The application server- 1 contacts UEs hosting client app-1 and collects their locations and their network coverage.

[00231] The application server- 1 decides the approximate geographical area regarding where the edge server is to be instantiated.

[00232] The application server- 1 contacts the two operators to ask whether they have available edge infrastructure resources for instantiating the needed edge server, along with a list of resource requirements.

[00233] The operators (e.g., certain NFs in the Core Network) will evaluate the requests and return their feedback to the application server- 1.

[00234] Based on the feedback, the application server- 1 will decide which operator’s edge infrastructure is to be used for instantiating anew application edge server (e.g., operator- 1 corresponding to SIM-1 card is selected).

[00235] The application server- 1 contacts the selected operator and instantiates a new edge instance of application server-1, which is called edge application server-1.

[00236] The application server- 1 notifies all the involved UEs about the newly available edge application server- 1, and in particular, in order to communicate with this edge application server-1, a particular operator (a particular SIM card) should be used (e.g., SIM-1 card).

[00237] Accordingly, when client app-1 on the involved UEs start to operate, those UEs will make sure to use SIM-1 card for their client app-1 to communicate with the edge application server- 1. [00238] The detailed procedure design for enabling edge server deployments with Multi-SIM UEs is illustrated in Figure 8:

[00239] Step 1: Application server- 1 is the corresponding cloud server for serving requests sent from the client app-1. Client app-1 is installed on many UEs (and those UEs are Multi-SIM UE and equipped with two SIM cards. Each SIM card corresponds to a specific operator, e.g., Operator-1 and Operator-2). Depending on various application needs, such as improved QoS requirements, a new application server- 1 needs to be created at the network edge. In particular, the two operators own their respective edge computing infrastructure.

[00240] Step 2: The application server- 1 contacts involved UEs for their locations and network coverage. Those involved UEs are the UEs that have installed the specific client app-1.

[00241] Step 3: The involved UEs (e.g., UE-1) decide their locations and network coverage. For example, based on their on-board GPS sensors, those UEs may know their geographical locations. In the meantime, those UEs may also measure their network coverage.

[00242] Step 4: The involved UE returns their feedback to the application server- 1 in the cloud.

[00243] Instead of conducting steps 2-4, alternatively, the application server- 1 can also contacts certain NFs in the 3GPP systems in order to get the location information about the involved UEs.

[00244] Step 5: Based on the feedback sent from UE, the cloud application server- 1 decides the desired edge location where the new application server- 1 is to be deployed. Then, the application server-1 in the cloud contacts the 3GPP systems of both SIM-1 and SIM-2 cards about a potential new application server deployment at their network edge, along with the certain performance requirements.

[00245] Step 6: Each of 3GPP system evaluates the request, and based on the current workload of their respective edge infrastructure at the desired location and the QoS requirements, each 3GPP system will return their feedback.

[00246] Step 7: Based on the feedback from the 3GPP systems, the application server-1 in the cloud decides where to create a new application server-1, e.g., in this example, the new application server- 1 should be deployed in the edge infrastructure of the 3 GPP system of the SIM-1 card. Alternatively, it is also possible that two new application servers may be deployed in the edge infrastructures of two different 3GPP systems respectively. [00247] Step 8: The application server- 1 in the cloud sends a request to the 3GPP system of SIM-1 card for deploying a new application server- 1 to its edge.

[00248] Step 9: The 3GPP system of SIM-1 card deploys a new edge application server- 1, which is called an edge application server- 1.

[00249] Step 10: The 3 GPP system of the SIM-1 card informs that the edge application server- 1 was deployed successfully.

[00250] Step 11: The application server- 1 in the cloud informs the involved UEs that edge application server-1 is ready for use. In other words, those UEs can just communicate with the edge application server- 1, instead of communicating with the application server- 1 in the cloud.

[00251] Step 12: The involved UEs send their acknowledgments and accordingly they need to make sure:

[00252] If a UE is a DSDS-UE, then this UE may start to operate on SIM-1 card so that its client app-1 can communicate with the edge application server-1 through the SIM-1 card.

[00253] If a UE is DSDA-UE, then this UE may need to make sure the client app-1 will operate over the SIM-1 card.

[00254] Step 13: The involved UEs start to communicate with edge application server-1 through their SIM-1 card. Note that, it is possible that some of the UEs cannot communicate with the edge server-1 through SIM-1 card. For example, some of DSDS-UEs cannot switch their active SIM card to SIM-1 card. In such a case, those UEs may still need to communicate with the application server- 1 in the cloud.

Aspect 5 (Cross-operator Load Balancing with Multi-SIM UEs)

[00255] Use Case Scenario: This scenario has the following settings: 1) Multi-SIM UEs have two SIM cards, which belong to two different operators (e.g., operator- 1 corresponds to SIM-1 card while operator-2 corresponds to SIM-2 card); 2) There are Client Applications installed on the UEs and those client applications can either use SIM-1 card or SIM-2 card. Those client applications mainly communicate with their corresponding edge application servers. An edge application server is often deployed by a specific operator (e.g., operator-1) at its network edge, which means a client application on the UE needs to use a specific SIM card (e.g., SIM-1 card) to interact with its edge application server (e.g., deployed by operator-1). 3) Operators may have dynamic system performances. For example, one example is that the performance of the deployed edge application servers may be downgraded due to the overloading of the edge infrastructure. Another example is that a client application on a UE may not have good connections to communicate with its edge application server due to the low-quality cellular channels when using a specific SIM card.

[00256] Features of Aspect 5: Features of Aspect 5 are as follows:

[00257] For a given application server (e.g., edge application server-1), it was already deployed to the network edge of a particular operator (e.g., operator-1) in order to provide better services to a particular group of UEs hosting a given client application (e.g., client app-1). For example, the solution described in Aspect-4 can achieve this purpose. Now client app-1 on UEs mainly interact with their edge application server- 1 through the SIM-1 card (corresponding to operator-1).

[00258] When edge application server-1 is serving client app-1 on different UEs, the system/network performance of operator-1 may be getting worse due to either edge computing resource shortage, or poor cellular network connection of the 3GPP system of the operator- 1.

[00259] The 3GPP system of operator-1 contacts those UEs and ask whether they are willing to switch to another SIM card, e.g., SIM-2 (Some UEs may agree to the proposal and some UEs may reject).

[00260] Based on the feedback from UEs, operator-1 contacts operator-2 and asks operator-2 to instantiate a new instance of edge application server- 1 at operator-2 ’s edge network infrastructure.

[00261] If operator-2 agrees, it will create a new instance of edge application server-1 at its network edge based on needs/requirements, e.g., how many UEs will be served. It will notify operator-1 that anew instance of edge application server-1 is ready.

[00262] The operator- 1 notifies all the involved UEs (who agreed to switch to SIM- 2 card) about the newly available edge application server- 1 at operator-2 ’s edge.

[00263] After receiving this notification, those UEs will switch from SIM-1 to SIM- 2 and start to communicate with the new instance of edge application server- 1 deployed by operator-2’ s edge.

[00264] Operator- 1 may still serve the remaining UEs who did not agree to switch their SIM cards. In this way, all the UEs can be well served with the help of the crossoperator load balancing.

[00265] The detailed procedure design for cross-operator load balancing with Multi- SIM UEs is illustrated in Figure 9: [00266] Precondition: UEs are communicating with edge application server- 1 through the SIM-1 card.

[00267] Step 1: The 3GPP system of SIM-1 identifies performance issues of edge application server-1. For example, the edge infrastructure for hosting the edge application server- 1 may be getting overloaded, and therefore the request processing time is getting longer, which significantly increases the processing delay. Alternatively, the connection quality between UEs and the 3GPP system of the SIM-1 card becomes poor, and therefore many messages cannot be delivered between UEs and the 3GPP system.

[00268] Step 2: The 3GPP system of SIM-1 card contacts involved UEs whether they are willing to switch to a different SIM card for facilitating the client app-1 on those UEs. In the meantime, the 3GPP system of SIM-1 card also collects performance-related data regarding where those UEs are distributed, and the QoS requirements of the client app-1 of those UEs.

[00269] Step 3: UEs may return their feedback. For example, some UEs may be willing to switch to another SIM card, e.g., SIM-2 card. For example, if client app-1 is a very important client application for them, then those UEs may like to switch to another SIM card to better serve client app-1. However, some of UEs may not be willing to switch to the SIM-2 card if they have to stick with the SIM-1 card.

[00270] Step 4: After receiving the feedback of UEs, the 3GPP system may decide to offload some workload from its edge infrastructure to another operator. For example, the 3GPP system of SIM-1 card can negotiate with another 3GPP system of SIM-2 (e.g., operator-2) to see whether the latter is willing to help for offloading by deploying a new edge application server. If so, the 3GPP system of SIM-1 will decide to create anew edge application server- 1 at a selected edge location, which can best serve UEs that did not obtain the desired QoS performance from the current edge application server- 1 deployed by the operator- 1.

[00271] Step 5: The 3GPP system of the SIM-1 card sends a request to the 3GPP system of SIM-2 card for deploying anew edge application server-1 to its edge. The following information can be carried in the request:

[00272] The location of where to deploy a new edge application server- 1.

[00273] The detailed deployment instruction for the edge application server- 1. [00274] The performance requirement of the new edge application server- 1. [00275] The UEs’ information regarding which UEs may potentially use this edge application server- 1.

[00276] Step 6: The 3GPP system of the SIM-2 card deploys a new edge application server- 1 at the desired location based on the information provided in Step 5.

[00277] Step 7: The 3GPP system of the SIM-2 card sends an acknowledgment to the 3GPP system of the SIM-1 card that the new edge application server-1 is ready.

[00278] Step 8: The 3GPP system of SIM-1 card will further inform involved UEs (which were willing to switch to SIM-2 card) that a new edge application server- 1 is ready and include contact information for this new edge application server- 1 (e.g., identifiers, credentials, network addresses). Note, that it is possible that the new application server-1 may only have limited capacity. Accordingly, in this step, the 3GPP system of the SIM-1 card may just select partial of involved UEs to ask them to access the new edge application server-1.

[00279] Step 9: The involved UEs will send acknowledgments to the 3GPP system of the SIM-1 card.

[00280] Step 10: In the meantime, those UEs (e.g., UE-1) will switch their active SIM card to the SIM-2 card.

[00281] Step 11: Those involved UEs (e.g., UE-1) start to communicate with new edge application server-1 at operator-2's edge through SIM-2 card.

[00282] Step 12: Some of the other UEs (which did not want to switch to SIM-2 card) may still communicate with edge application server-1 at operator-l's edge (through SIM-1 card).

[00283] It is worth noting that the proposed procedure can also be applied in other scenarios, as long as it involves coordination and collaboration between two operators. For example, in another scenario, UEs may interact with their application server through SIM-1 card, and the application server is deployed in the cloud and may not provide the desired performances. In particular, the 3GPP system of the SIM-1 card does not have edge infrastructure and cannot be deployed on an edge application server. Accordingly, in this case, the 3GPP system of the SIM-1 card can also contact the 3GPP system of SIM-2 card if an edge application server can be deployed in the edge infrastructure of 3GPP system of the SIM-2 card. In this scenario, the proposed procedure as shown in Figure 9 can also be reused. Embodiment

3GPP Embodiment

[00284] Entity Embodiment for 3GPP Service Architecture [00285] In the first embodiment, it is proposed that the entities defined in this disclosure can have the following embodiments (accordingly, the entities in the procedures defined in the previous section will also have the following embodiments):

[00286] The client application can be mapped to the Application Client defined by 3GPP, which resides on UE.

[00287] All the UE-side SIM management related activities can be implemented by a new module, which is defined as a new SIM Card Management Client on the UE, which can interact with the corresponding SIM card management NF in the 3GPP system.

[00288] In the meantime, all the 3 GPP system-side SIM management related activities can be implemented by a new NF, which is defined as a new SIM Card Management NF. This NF will interact with SIM card management client hosted on UEs.

[00289] The application server can be either hosted inside the 3GPP system or outside the 3GPP system (e.g., in the cloud).

Entity Embodiment for 3GPP SA6 Application Architecture for Enabling Edge Applications

[00290] In 3GPP SA6, the specification TS 23.758 defines an Application Architecture for Enabling Edge Applications, in which there are several key functional entities:

[00291] Edge Enabler Server provides supporting functions needed for Edge Application Servers to run in an Edge Data Network;

[00292] Edge Enabler Client provides supporting functions needed for Application Client(s);

[00293] Edge Application Server: An Application Server resident in the Edge Hosting Environment; and

[00294] Application Client: Application software resident in the UE performing the client function.

[00295] In the below embodiment, it is proposed that the entities defined in this disclosure can have the following embodiments:

[00296] The client application can be mapped to the Application Client defined by 3GPP, which resides on UE;

[00297] All the UE-side SIM management related functionality can be defined as a new function (e.g., a SIM Card Management Client. Alternatively, the UE-side SIM management functionality can be defined as a feature of the existing Edge Enabler Client function;

[00298] In the meantime, all the 3 GPP system-side SIM management related activities can be defined as a new NF (e.g., a SIM Card Management NF. Alternatively, the 3GPP system-side SIM management functionality can be defined as a feature of one or more existing functions existing within the 3GPP Core Network, or within an Edge Enabler Server or Edge Configuration Server; and

[00299] The application server can be mapped to the Edge Application Server defined by 3GPP.

User Interface

[00300] A GUI interface is illustrated in Figure 12, which can be used for a human user to configure the SIM card usage for the installed client applications, e.g., conduct SIM management on the UE. For example, a human user can select a particular client application to be configured. If the user chooses to assign a designated SIM card for this particular client app, then the user can select a particular SIM card for this client application as its designated SIM card. However, if the user does not select a designated SIM card for this client app, it means that this client application is not bound to a specific SIM card and can use any of the SIM cards. Also, the user can indicate the priority of this client application. In other words, after selecting a SIM card for this client app, the user can indicate what kind of priority this client application should have. Such a priority will be considered by the corresponding operator of the selected SIM card (e.g., a higher priority client application will be allocated with more network resources if needed). In addition, the user may also indicate the desired QoS or performance requirement, which will also be taken into consideration by the operator. Then, the operator should try and serve the client application with the desired QoS but still take into account the serving priority of this client application.

Example Communications System

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

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

[00303] Figure 13 A illustrates one embodiment of an example communications system 100 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and/or 102g (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105/103b/l 04b/l 05b, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110„ other networks 112, and V2X server (or ProSe function and server) 113, though it will be appreciated that the disclosed embodiments contemplate any number ofWTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of apparatus or device configured to operate and/or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is depicted in Figures 13A-13E as a handheld wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit and/or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, and the like.

[00304] The communications system 100 may also include a base station 114a and a base station 114b. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. Base stations 114b may be any type of device configured to wiredly and/or wirelessly interface with at least one of the RRHs (Remote Radio Heads) 118a, 118b, TRPs (Transmission and Reception Points) 119a, 119b, and/or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, the other networks 112, and/or V2X server (or ProSe function and server) 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, the other networks 112, and/or V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), aNode-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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

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

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

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

[00309] The WTRUs 102a, 102b, 102c,102d, 102e, 102f, and/or 102g may communicate with one another over an air interface 115d/l 16d/l 17d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d/l 16d/l 17d may be established using any suitable radio access technology (RAT).

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

[00311] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, and/or RSUs 120a, 120b, in the RAN 103b/104b/105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 or l l5c/116c/117c respectively using Long T erm Evolution (LTE) and/ or LTE- Advanced (LTE-A). In the future, the air interface 115/116/117 may implement 3GPP NR technology. The LTE and LTE-A technology includes LTE D2D and V2X technologies and interface (such as Sidelink communications, etc.) The 3GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.)

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

[00313] The base station 114c in Figure 13A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In an embodiment, the base station 114c and the WTRUs 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRUs 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 13A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106/107/109.

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

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

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

[00317] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102e shown in Figure 13A may be configured to communicate with the base station 114a, which may employ a cellularbased radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[00318] Figure 13B is a block diagram of an example apparatus or device configured for wireless communications in accordance with the embodiments illustrated herein, such as for example, a WTRU 102. As shown in Figure 13B, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit/ receive element 122, a speaker/microphone 124, a keypad 113, a display/touchpad/indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node- B gateway, and proxy nodes, among others, may include some or all of the elements depicted in Figure 13B and described herein.

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

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

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

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

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

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

[00325] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface

115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

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

[00328] Figure 13C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in Figure 13C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

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

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

[00331] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. [00332] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

[00334] Figure 13D is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

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

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

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

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

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

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

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

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

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

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

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

[00346] As shown in Figure 13E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

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

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

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

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

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

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

[00353] In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85. [00354] Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touchpanel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.

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

[00356] Figure 13G illustrates one embodiment of an example communications system 111 in which the methods and apparatuses described and claimed herein may be embodied. As shown, the example communications system 111 may include wireless transmit/receive units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and a RSUs A and B, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. One or several or all WTRUs A, B, C, D, E can be out of range of the network (for example, in the figure out of the cell coverage boundary shown as the dash line). WTRUs A, B, C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F may communicate over Uu interface or Sidelink (PC5) interface.

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

Claims

CLAIMS What is claimed is:

1. A method for Application-layer Subscriber Identification Module (SIM) Management, the method comprising: designating, by a user, a first client application installed on a user equipment (UE) to use a first Subscriber Identification Module (SIM) card corresponding to a first cellular system; assigning, by the user, the first client application with a service priority; communicating, by one or more other client applications installed on the UE using a second Subscriber Identification Module (SIM) card corresponding to a second cellular system, with the second cellular system; collecting information from the user, wherein the collected information includes metadata, context information, or trigger events; determining, based on the collected information and the service priority, whether the first client application can be served by the first SIM card; notifying, based on determining the first client application can be served by the first SIM card, the second cellular system of one or more affected client applications installed on the UE; deactivating, based on determining to switch from using the second SIM card to using the first SIM card for serving the first client application, the second SIM card; and activating, based on deactivating the second SIM card, the first SIM card.

2. The method of claim 1, further comprising receiving an advisory from a network entity, wherein determining whether the first client application can be served by the first SIM card is further based on the advisory from the network entity.

3. The method of claim 1, further comprising receiving a command from the user, wherein determining whether the first client application can be served by the first SIM card is further based on the command from the user.

4. The method of claim 1 , further comprising receiving an acknowledgment from the second cellular system and performing, based on the acknowledgment from the second cellular system, one or more actions on one or more affected client applications that are currently using the second SIM card.

5. The method of claim 1, further comprising notifying the first cellular system corresponding to the first SIM card about a new launch of the first client application.

6. The method of claim 1 , further comprising receiving an acknowledgement from the first cellular system.

7. The method of claim 1, further comprising operating the first client application using the first SIM card.

8. An apparatus for Application-layer Subscriber Identification Module (SIM) Management, the apparatus being a User Equipment (UE) comprising a processor, communications circuitry, and a memory comprising instructions which, when executed by the processor cause the apparatus to: designate, by a user, a first client application installed on the UE to use a first Subscriber Identification Module (SIM) card corresponding to a first cellular system; assign, by the user, the first client application with a service priority; communicate, by one or more other client applications installed on the UE using a second Subscriber Identification Module (SIM) card corresponding to a second cellular system, with the second cellular system; collect information from the user, wherein the collected information includes metadata, context information, or trigger events; determine, based on the collected information and the service priority, whether the first client application can be served by the first SIM card; notify, based on determining the first client application can be served by the first SIM card, the second cellular system of one or more affected client applications installed on the UE; deactivate, based on determining to switch from using the second SIM card to using the first SIM card for serving the first client application, the second SIM card; and activate, based on deactivating the second SIM card, the first SIM card.

9. The apparatus of claim 8, wherein the instructions further cause the apparatus to receive an advisory from a network entity, wherein determining whether the first client application can be served by the first SIM card is further based on the advisory from the network entity.

10. The apparatus of claim 8, wherein the instructions further cause the apparatus to receive a command from the user, wherein determining whether the first client application can be served by the first SIM card is further based on the command from the user.

11. The apparatus of claim 8, wherein the instructions further cause the apparatus to receive an acknowledgment from the second cellular system and perform, based on the acknowledgment from the second cellular system, one or more actions on one or more affected client applications that are currently using the second SIM card.

12. The apparatus of claim 8, wherein the instructions further cause the apparatus to notify the first cellular system corresponding to the first SIM card about a new launch of the first client application.

13. The apparatus of claim 8, wherein the instructions further cause the apparatus to receive an acknowledgement from the first cellular system.

14. The apparatus of claim 8, wherein the instructions further cause the apparatus to operate the first client application using the first SIM card.

15. Designating, by a network entity, a first client application installed on a user equipment (UE) to use a first subscriber identification module (SIM) card corresponding to a first cellular system, wherein the UE comprises a second SIM card corresponding to a second cellular system; designating a first client application installed on the UE to use the first SIM card; assigning the first client application a service priority; collecting information from the UE, wherein the collected information is associated with use, by one or more other client applications installed on the UE, of the second SIM card and the collected information includes metadata, context information, or trigger events; determining, based on the collected information and the service priority, whether the first client application can be served by the first SIM card; and notifying, based on determining the first client application can be served by the first SIM card, the second cellular system of one or more affected client applications installed on the UE, wherein the second SIM card is deactivated and the first SIM card is activated.

16. The method of claim 15, wherein determining whether the first client application can be served by the first SIM card is further based on an advisory.

17. The method of claim 15, further comprising receiving a command from a user, wherein determining whether the first client application can be served by the first SIM card is further based on the command from the user.

18. The method of claim 15, wherein the UE receives an acknowledgment from the second cellular system and performs, based on the acknowledgment from the second cellular system, one or more actions on one or more affected client applications that are currently using the second SIM card.

19. The method of claim 15, wherein the UE notifies the first cellular system corresponding to the first SIM card about a new launch of the first client application.

20. The method of claim 15, wherein an acknowledgement from the first cellular system is received by the UE.