CN116848867A

CN116848867A - Method and apparatus for processing profiles by considering removable EUICC supporting multiple enabled profiles

Info

Publication number: CN116848867A
Application number: CN202180077842.5A
Authority: CN
Inventors: 姜秀姃; 李德基; 具宗会; 尹江镇
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2020-11-19
Filing date: 2021-11-18
Publication date: 2023-10-03

Abstract

A method and apparatus for aggregating User Equipments (UEs) of a communication technology of a 5G communication system and an Internet of things technology supporting higher data rates after a 4G system are provided. The method comprises the following steps: performing an activation and a cold reset to configure an operating environment for a removable eUICC supporting MEP mode; receiving an ATR message indicating whether the eUICC supports at least one eUICC function; determining a transmission protocol based on the received ATR message; transmitting an APDU message indicating whether the UE supports eUICC-related capabilities; receiving a response message including a response code; determining to operate in a non-MEP mode; transmitting a command APDU message for managing channel opening, which is transmitted for channel opening; receiving a conventional response message for generating a basic channel; and performing initialization between the eUICC and the UE.

Description

Method and apparatus for processing profiles by considering removable EUICC supporting multiple enabled profiles

Technical Field

The present disclosure relates to a method and apparatus for downloading at least one communication service to a terminal and installing and enabling the communication service to establish a communication connection in a wireless communication system. In particular, the present disclosure relates to a method for handling profiles between a terminal and an eUICC supporting a plurality of enabled profiles (multiple enabled profiles, MEP).

Background

In order to meet the increasing demand for wireless data services since the deployment of 4G communication systems, efforts have been made to develop improved 5G or front 5G communication systems. Thus, a 5G or former 5G communication system is also referred to as a "beyond 4G network" communication system or a "long term evolution after (LTE) system. A 5G communication system is considered to be implemented in a higher frequency (millimeter wave) band (e.g., 60GHz band) in order to achieve a higher data rate. In order to reduce propagation loss of radio waves and increase transmission distance, beamforming, massive Multiple Input Multiple Output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, massive antenna techniques are discussed in 5G communication systems. Further, in the 5G communication system, development of system network improvement is underway based on an evolved small cell, an advanced small cell, a cloud Radio Access Network (RAN), an ultra dense network, device-to-device (D2D) communication, wireless backhaul, a mobile network, cooperative communication, coordinated multipoint (CoMP), reception-side interference cancellation, and the like. Hybrid FSK and QAM modulation (FQAM) and Sliding Window Superposition Coding (SWSC) as Advanced Code Modulation (ACM) and Filter Bank Multicarrier (FBMC), non-orthogonal multiple access (NOMA) and Sparse Code Multiple Access (SCMA) as advanced access technologies have also been developed in 5G systems.

The internet is an artificially-centric connected network in which humans generate and consume information, and is now evolving towards the internet of things (IoT) in which distributed entities, such as things, exchange and process information without human intervention. Through connection with cloud servers, internet of everything (IoE) has emerged that combines IoT technology with big data processing technology. As technical elements required to implement IoT, such as "sensing technology", "wired/wireless communication and network infrastructure", "service interface technology" and "security technology", sensor networks, machine-to-machine (M2M) communication, machine Type Communication (MTC), etc., have recently been studied. Such IoT environments may provide intelligent internet technology services that create new value for human life by collecting and analyzing data generated between the interconnects. With the convergence and integration between existing Information Technology (IT) and various industrial applications, ioT may be applied in a variety of fields including smart homes, smart buildings, smart cities, smart cars or networked cars, smart grids, healthcare, smart appliances, and advanced medical services.

In keeping with this, various attempts have been made to apply existing 4G and 5G communication systems to IoT networks. For example, technologies such as sensor networks, machine-to-machine (M2M) communications, machine Type Communications (MTC), and may be implemented by beamforming, MIMO, and array antenna technologies as 4G and 5G communication technologies.

A Universal Integrated Circuit Card (UICC) is a smart card inserted and used in a mobile communication terminal or the like, also called a UICC card. The UICC may include an access control module for accessing a network of the mobile communications provider. Examples of access control modules include Universal Subscriber Identity Module (USIM), subscriber Identity Module (SIM), IP multimedia services identity module (ISIM), and the like. UICCs including USIMs are also commonly referred to as USIM cards. Similarly, UICCs comprising SIM modules are often also referred to as SIM cards. In the following description of the present disclosure, a "SIM card" may be used in a conventional sense, including UICC cards, USIM cards, UICCs including ISIM, and the like. In other words, the technical application of the SIM card can be equally applied to USIM cards, ISIM cards or UICC cards in general.

The SIM card is used to store personal information of a mobile communication subscriber, authenticate the user when accessing the mobile communication network, and generate a service security key so that the mobile communication can be safely used.

The SIM card is generally manufactured as a dedicated card for a specific mobile communication provider at the request of the corresponding provider, and authentication information (e.g., USIM application, international Mobile Subscriber Identity (IMSI), K value, OPc value) for accessing the provider's network is pre-installed in the card, which is then commercially available. Thus, the manufactured SIM card is delivered to the corresponding mobile communication provider and then provided to the subscriber, and techniques such as Over The Air (OTA) may be used later to install applications in the UICC, modify applications, delete applications, or otherwise manage applications, if necessary. By inserting the UICC card into an owned mobile communication terminal, the user can use the network and application services of the corresponding mobile communication provider. When the terminal is to be replaced, the UICC card can be taken out of the existing terminal and inserted into a new terminal, so that the same authentication information, mobile communication phone number, personal phone directory, etc. stored in the UICC can be used in the new terminal.

However, the SIM card may cause inconvenience to the mobile communication terminal user when receiving services from another mobile communication provider. In other words, the mobile communication terminal user needs to physically acquire the SIM card to receive services from the corresponding mobile communication provider. For example, when a person travels to another country, a local SIM card needs to be obtained to use a local mobile communication service. This inconvenience can be solved to some extent by using the roaming service, but there is also a problem in that the roaming service is expensive and cannot provide a service if there is no connection between providers.

By remotely downloading the SIM module and installing it in the UICC card, this inconvenience can be solved to a large extent. That is, the SIM module of the mobile communication service to be used may be downloaded to the UICC card at a point of time desired by the user. In addition, multiple SIM modules may be downloaded and installed into such UICC cards, and only a single SIM module therein may be selected and used. Such UICC card may or may not be fixed to the terminal. In particular, UICCs fixed to terminals and used as such are called euiccs (embedded UICCs). In general, an eUICC refers to a UICC card that is fixed to a terminal and so used, and that is configured so that a SIM module can be downloaded and selected remotely. In the present disclosure, a UICC card configured such that a SIM module can be remotely downloaded and selected may be referred to as an eUICC. In other words, among UICC cards configured so that the SIM module can be remotely downloaded and selected, both the UICC card fixed to the terminal and the UICC card not fixed to the terminal may be referred to as eUICC. In addition, the downloaded SIM module information will be referred to as a profile hereinafter.

Even if multiple profiles are present in the eUICC, only one can be enabled at a time. Thus, if the terminal supports two baseband and even if there are two or more profiles in the corresponding eUICC, the terminal cannot support dual SIM functionality that can use both profiles simultaneously in a single mobile phone. This can be solved by installing two euiccs in the terminal, but this requires the installation of an additional eUICC module and a physical interface for connecting the eUICC module to the baseband of the modem. Thus, the end manufacturer is burdened with the cost of the additional eUICC module and physical pins for the physical interface. There is also a problem in that a space in the terminal must be ensured to mount the corresponding module and physical pins.

Disclosure of Invention

Technical problem

When an eUICC supporting multiple enabled profiles (multiple enabled profiles, MEP) so that multiple profiles can be enabled is inserted into a terminal, the method for profile processing needs to be determined in conjunction with the number of profiles to be maintained enabled or the number of profiles to be disabled by the terminal, the eUICC, or both the terminal and the eUICC, and operations need to be processed differently accordingly. However, this is not considered at present, and this problem needs to be solved.

In particular, when a removable MEP-enabled eUICC is inserted into a terminal and a profile with a "impossible to disable" service provider policy (profile policy rule 1 (PPR 1)) configured in metadata is inserted into the eUICC, no consideration is given to a method of handling the corresponding profile by the terminal or the MEP-enabled eUICC. This problem needs to be solved.

Problem solution

According to the present disclosure, a method of a User Equipment (UE) is provided. The method comprises the following steps: performing an activation and a cold reset to configure an operating environment for operation with a removable embedded universal integrated circuit card (eUICC) that supports a plurality of enabled profile (MEP) modes; in response to performing the activating and cold resetting, receiving an Answer To Reset (ATR) message from the eUICC, the ATR message including information indicating whether the eUICC supports at least one eUICC function; determining a transport protocol to be used between the UE and the eUICC based on the received ATR message; transmitting an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities to the eUICC over a transport protocol to be used between the UE and the eUICC; receiving a response message including a response code from the eUICC in response to sending the APDU message; determining to operate in a non-MEP mode; transmitting a command APDU message for managing channel (MANAGE CHANNEL) open (open) to the eUICC, the command APDU message being transmitted for channel open upon initialization between a general eUICC and UE that do not support MEP mode; in response to sending the command APDU message, receiving a conventional response message from the eUICC for generating a basic channel for APDU transmission between the UE and the eUICC; and performing initialization between the eUICC and the UE.

In accordance with an embodiment of the present disclosure, a method of supporting Multiple Enabled Profile (MEP) modes for a removable embedded universal integrated circuit card (eUICC) is provided. The method comprises the following steps: transmitting, to a User Equipment (UE), a reset Answer (ATR) message for an activation and a cold reset of the UE, the ATR message including information indicating whether the eUICC supports at least one eUICC function; receiving an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities from the UE through a transport protocol to be used between the UE and the eUICC determined based on the ATR message; in response to receiving the APDU message, transmitting a response message including a response code to the UE; determining whether the UE supports eUICC-related capabilities based on the APDU message; if the UE does not support the eUICC related capability, determining that the UE is operating in a non-MEP mode; if the UE supports the eUICC-related capability, determining whether the eUICC receives a command APDU message from the UE for managing channel opening, the command APDU message being sent for channel opening upon initialization between a general eUICC that does not support the MEP mode and the UE; if the eUICC receives a command APDU message from the UE, determining that the UE is operating in a non-MEP mode, and in response to receiving the command APDU message, sending a regular response message to the UE for generating a basic channel for APDU transmission between the UE and the eUICC; initialization is performed between the eUICC and the UE.

According to an embodiment of the present disclosure, a User Equipment (UE) includes: a transceiver; and a controller coupled to the transceiver, wherein the controller is configured to: performing an activation and a cold reset for configuring an operating environment for operation with a removable embedded universal integrated circuit card (eUICC) that supports a plurality of enabled profile (MEP) modes; in response to performing the activating and cold resetting, receiving an Answer To Reset (ATR) message from the eUICC, the ATR message including information indicating whether the eUICC supports at least one eUICC function; determining a transport protocol to be used between the UE and the eUICC based on the received ATR message; transmitting an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities to the eUICC over a transport protocol to be used between the UE and the eUICC; receiving a response message including a response code from the eUICC in response to sending the APDU message; determining to operate in a non-MEP mode; transmitting a command APDU message for managing channel opening to the eUICC, the command APDU message being transmitted for channel opening upon initialization between a general eUICC and a UE that do not support the MEP mode; in response to sending the command APDU message, receiving a conventional response message from the eUICC for generating a basic channel for APDU transmission between the UE and the eUICC; and performing initialization between the eUICC and the UE.

According to an embodiment of the present disclosure, a removable embedded universal integrated circuit card (eUICC) supporting Multiple Enabled Profile (MEP) modes is configured to send a reset Answer (ATR) message to a User Equipment (UE) for activation and cold reset of the UE, the ATR message including information indicating whether the eUICC supports at least one eUICC function; receiving an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities from the UE through a transport protocol to be used between the UE and the eUICC determined based on the ATR message; in response to receiving the APDU message, transmitting a response message including a response code to the UE; determining whether the UE supports capability related to the eUICC based on the APDU message; if the UE does not support the eUICC related capability, determining that the UE is operating in a non-MEP mode; if the UE supports the eUICC-related capability, determining whether the eUICC receives a command APDU message from the UE for managing channel opening, the command APDU message being sent for channel opening upon initialization between a general eUICC that does not support the MEP mode and the UE; if the eUICC receives a command APDU message from the UE, determining that the UE is operating in a non-MEP mode, and in response to receiving the command APDU message, sending a regular response message to the UE for generating a basic channel for APDU transmission between the UE and the eUICC; and performing initialization between the eUICC and the UE.

Advantageous effects of the invention

Embodiments of the present disclosure provide a method in which one can be selected from the enabled profiles when a user inserts an MEP removable eUICC with one or more enabled profiles into an eSIM terminal that does not support eUICC or MEP modes.

According to embodiments of the present disclosure, during initialization between a terminal and a card in MEP mode, baseband connection with respect to a default profile may be ensured, and profile maintenance enablement in which profile policy rule 1 (PPR 1) is configured may be ensured.

Embodiments of the present disclosure provide a method in which a user can switch a connection to and use another profile or connect to and use another UICC in conjunction with a baseband currently occupied by a profile that cannot be disabled in MEP mode.

Before starting the following modes of the invention, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprise," along with derivatives thereof, mean inclusion without limitation; the term "or" is inclusive, meaning and/or; the phrases "associated with" and "associated therewith," and derivatives thereof, may mean including, included within, interconnected with, contained within, connected to or coupled with … …, coupled to or coupled with … …, communicable with … …, cooperative with, interleaved with, juxtaposed with, proximate to, combined with or otherwise coupled with … …, having characteristics, etc.; the term "controller" refers to any device, system, or portion thereof that controls at least one operation, such device may be implemented in hardware, firmware, or software, or some combination of at least two. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely.

Furthermore, the various functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. "non-transitory" computer-readable media do not include wired, wireless, optical, or other communication links that transmit transitory electrical signals or other signals. Non-transitory computer readable media include media that can permanently store data and media that can store data and be later rewritten, such as rewritable optical disks or erasable storage devices.

Definitions for certain words and phrases are provided throughout this patent document, those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

Drawings

For a more complete understanding of the present disclosure and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which like reference numerals represent like components:

fig. 1 illustrates components of a wireless communication system according to an embodiment of the present disclosure;

fig. 2 schematically illustrates an example of a connection between a current v2 embedded universal integrated circuit card (eUICC) and a modem that does not support MEPs in a wireless communication system according to an embodiment of the present disclosure;

fig. 3 schematically illustrates an example of a connection between an incoming eUICC and a modem according to the concept of a virtual interface (which may be used interchangeably with a logical interface) in a wireless communication system according to an embodiment of the present disclosure;

fig. 4 illustrates a method of a UE and eUICC to handle local profile activation when the UE is operating in MEP mode, according to an embodiment of the present disclosure;

fig. 5 schematically illustrates maintaining a connection between an eUICC and a modem of an existing configuration when a MEP-enabled UE restarts in a wireless communication system in accordance with an embodiment of the present disclosure;

Fig. 6 illustrates a method of configuring a default profile by an MEP-enabled eUICC inserted or fixed in a UE in accordance with an embodiment of the present disclosure;

fig. 7 illustrates a process of configuring a default profile in the LPA of a UE according to an embodiment of the present disclosure;

fig. 8 illustrates a method in which the MEP eUICC determines profile processing using default profile information in an initialization process between a UE and the MEP eUICC, in accordance with an embodiment of the present disclosure;

FIG. 9 illustrates a method of processing profile processing with reference to default profile information in the eUICC when operating as a generic eUICC in FIG. 8, according to embodiments of the present disclosure;

fig. 10A and 10B illustrate a method of referencing default profile information handling profile processing in an eUICC and a UE when operating as the MEP eUICC in fig. 8, according to an embodiment of the present disclosure;

11A and 11B illustrate a method of handling exchanges of ports to be used between a UE operating in MEP mode and a profile in an eUICC, according to embodiments of the present disclosure;

fig. 12 schematically illustrates an internal structure of a UE in a wireless communication system according to an embodiment of the present disclosure;

fig. 13 illustrates a method of handling changes between ports to be used by a UE operating in MEP mode and a profile in an eUICC, according to another embodiment of the disclosure;

Fig. 14 illustrates a method of returning profile state information when a removable MEP-enabled eUICC is inserted into an eSIM UE that does not support MEPs, according to an embodiment of the present disclosure;

fig. 15 illustrates a method of handling activation of a profile in a temporary enabled state when a removable MEP-enabled UICC is inserted into an eSIM UE that does not support MEPs, according to an embodiment of the present disclosure; and

fig. 16 illustrates a method of handling deactivation of a profile in a temporary enabled state when a removable MEP-enabled UICC is inserted into an eSIM UE that does not support MEPs, according to an embodiment of the present disclosure.

Detailed Description

Figures 1 through 16, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will appreciate that the principles of the present disclosure may be implemented in any suitably arranged system or device.

Hereinafter, the operation principle of the present disclosure will be described in detail with reference to the accompanying drawings. In the following description of the present disclosure, a detailed description of known functions or configurations incorporated herein will be omitted when it may be determined that the description may make the subject matter of the present disclosure unnecessarily unclear. The terms to be described below are terms defined in consideration of functions in the present disclosure, and may be different according to users, intention of users, or custom. Accordingly, the definition of the terms should be based on the contents of the entire specification. For the same reason, in the drawings, some elements may be exaggerated, omitted, or schematically shown. Furthermore, the size of each element does not fully reflect the actual size. In the drawings, identical or corresponding elements have identical reference numerals. The advantages and features of the present disclosure and the manner in which they are accomplished will become apparent by reference to the embodiments that are described in detail below in conjunction with the accompanying drawings. However, the present disclosure is not limited to the embodiments set forth below, but may be implemented in various forms. The following examples are provided solely for the purpose of fully disclosing the present disclosure and informing those skilled in the art the scope of the present disclosure and are limited only by the scope of the appended claims. Throughout the specification, the same or similar reference numerals denote the same or similar elements. Further, in describing the present disclosure, a detailed description of known functions or configurations incorporated herein will be omitted when it may be determined that the description may make the subject matter of the present disclosure unnecessarily unclear. The terms to be described below are terms defined in consideration of functions in the present disclosure, and may be different according to users, intention of users, or custom. Accordingly, the definition of the terms should be based on the contents of the entire specification.

In the following description, a base station is an entity that allocates resources to a terminal, and may be at least one of a node, a base station, a radio access unit, a base station controller, and a node on a network. A terminal may include a User Equipment (UE), a Mobile Station (MS), a cellular phone, a smart phone, a computer, or a multimedia system capable of performing a communication function. In the present disclosure, "downlink" refers to a radio link through which a base station transmits signals to a terminal, and "uplink" refers to a radio link through which a terminal transmits signals to a base station. Furthermore, although the following description may be directed to an LTE or LTE-a system by way of example, embodiments of the present disclosure may also be applied to other communication systems having similar technical contexts or channel types as embodiments of the present disclosure. Examples of other communication systems may include fifth generation mobile communication technologies (5G, new radio, NR) developed outside LTE-a, and in the following description, "5G" may be a concept covering existing LTE, LTE-a, and other similar services. Further, based on the determination by those skilled in the art, the present disclosure may be applied to other communication systems with some modifications without significantly departing from the scope of the present disclosure. Here, it will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions.

These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-usable or computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-usable or computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Furthermore, each block of the flowchart illustrations may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. As used herein, a "unit" refers to a software element or a hardware element, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), that performs a predetermined function. However, the "unit" does not always have a meaning limited to software or hardware. The "unit" may be configured to be stored in an addressable storage medium or to execute one or more processors. Thus, a "unit" includes, for example, software elements, object-oriented software elements, class elements or task elements, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and parameters. The elements and functions provided by the "unit" may be combined into a smaller number of elements or "units" or divided into a larger number of elements or "units" and further, the elements and "units" may be implemented to replicate one or more CPUs within a device or secure multimedia card. Further, a "unit" in an embodiment may include one or more processors.

First, terms used in the present disclosure are defined.

In the present disclosure, the UICC is a smart card inserted into a mobile communication terminal for use, and refers to a chip storing personal information such as network access authentication information, a phonebook, and SMS of a mobile communication subscriber, and performs user authentication and service security key generation when accessing a mobile communication system such as GSM, WCDMA, LTE, 5G, etc., to achieve secure mobile communication use. Communication applications such as a Subscriber Identity Module (SIM), a Universal SIM (USIM), and an IP multimedia SIM (ISIM) are installed in the UICC according to the type of mobile communication network to which the user accesses. UICCs provide advanced security functions for installing various applications such as electronic wallets, ticketing, electronic passports, and the like.

In the present disclosure, an embedded UICC (eUICC) is not limited to a security module embedded in a terminal, and includes a removable security module that can be inserted into and removed from the terminal. The eUICC can be installed by downloading the profile using over-the-air (OTA) technology. The eUICC can be named UICC that can download and install profiles.

In the present disclosure, the method of downloading and installing a profile in an eUICC by using OTA technology can be applied to a removable UICC that can be inserted into and removed from a terminal as described above. For example, embodiments of the present disclosure may be applied to removable UICCs that may be installed by downloading profiles using OTA technology.

In this disclosure, the term UICC can be used interchangeably with SIM, and the term eUICC can be used interchangeably with eSIM.

In this disclosure, a profile may refer to a software package of an application, a file system, an authentication key value, etc. stored in the UICC being packaged in the form of software. Further, the profile may be named access information.

In the present disclosure, a USIM profile may have the same meaning as a profile, or may represent a software package that packages information included in a USIM application within a profile in the form of software.

In the present disclosure, a profile server is a server that generates a profile, encrypts the generated profile, generates a profile remote management instruction, and provides a function of encrypting the generated profile remote management instruction, or includes a function of supporting multi-profile activation of a terminal. The profile server may be expressed as subscription manager data preparation (SM-DP), subscription manager data preparation plus (SM-dp+) or subscription manager secure routing (SM-SR).

The term "terminal" or "device" as used in this disclosure may be referred to as a Mobile Station (MS), user Equipment (UE), user Terminal (UT), wireless terminal, access Terminal (AT), terminal, subscriber Unit (SU), subscriber Station (SS), wireless device, wireless communication device, wireless transmit/receive unit (WTRU), mobile node, mobile, or other terminology. Various embodiments of the terminal include a cellular phone, a smart phone having a wireless communication function, a Personal Digital Assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, a photographing device such as a digital camera having a wireless communication function, a game device having a wireless communication function, a music storage and playback device having a wireless communication function, an internet device implementing wireless internet access and browsing, and a portable unit or terminal incorporating a combination of these functions. Further, terminals may include, but are not limited to, machine-to-machine (M2M) terminals and Machine Type Communication (MTC) terminals/devices. In this disclosure, a terminal may be referred to as an electronic device or simply a device.

In the present disclosure, a terminal or device may include software or an application installed in the terminal or device to control the UICC or eUICC. The software or application may be referred to as, for example, a Local Profile Assistant (LPA). In the present disclosure, the eUICC identifier (eUICC ID) may be a unique identifier of the eUICC embedded in the terminal, and may be referred to as EID.

In the present disclosure, an Application Protocol Data Unit (APDU) may be a message for a controller in a terminal or device to interwork with an eUICC.

In this disclosure, a profile software package may be used interchangeably with profile, or may be used as a term for a data object that indicates a particular profile, and may be named a profile TLV or profile software package TLV. The profile identifier may be referred to as ICCID as the unique identification number of the profile. When the profile software package is encrypted using encryption parameters, the profile software package may be named a protected profile software package (PPP) or a protected profile software package TLV (PPP TLV). When the profile package is encrypted using encryption parameters that can only be decrypted by a particular eUICC, the profile package can be named a Binding Profile Package (BPP) or binding profile package TLV (BPP TLV). The profile software package TLV may be a data set expressing information constituting a profile in TLV (tag, length, value) format.

In the present disclosure, AKA may indicate authentication and key agreement, and may indicate authentication algorithms for accessing 3GPP and 3GPP2 networks. K is an encryption key value stored in the eUICC for the AKA authentication algorithm, and in this disclosure OPc is a parameter value for the AKA authentication algorithm that can be stored in the eUICC.

In the present disclosure, the NAA is a network access application, and may be an application stored in the UICC to access a network, such as USIM or ISIM. The NAA may be a network access module.

In the present disclosure, an end user, subscriber, service subscriber, and user may be interchangeably used as a user of a corresponding terminal.

In the present disclosure, eSIM ports refer to virtual interfaces used by multiplexing and dividing physical interfaces connected to eUICC-modems, and can be used interchangeably with eSIM ports, SIM ports, virtual interfaces, logical interfaces, and Logical SE Interfaces (LSIs).

The eSIM ports used by ISD-R can be denoted as ISD-R eSIM ports, and the eSIM ports used by the profile can be classified and used as profile eSIM ports.

In the present disclosure, information about a profile that can be returned to the LPA through GetProfileInfo () can be used as a term such as profile metadata or profile information. The information on the profile may be profile information provided by SM-dp+ when the profile is installed to the terminal, status or configuration information of the profile processed by the eUICC receiving the ES10c command from the LPA, or status/configuration information of the profile processed when the eUICC satisfies a specific condition.

In the present disclosure, the functionality for activating and managing multiple profiles present in a single eUICC is collectively referred to as Multiple Enabled Profile (MEP) functionality. In a traditional eUICC, only one profile can be activated, so a single eUICC cannot support dual SIM or multi SIM functionality. In order to support dual SIM or multi SIM functionality with a single eUICC, it is necessary to enable and manage multiple profiles in a single eUICC. The eUICC in which the MEP functionality is implemented may be referred to as an MEP-enabled eUICC. A terminal including a modem in which the MEP function is implemented and terminal software capable of supporting the modem may be referred to as a MEP-capable terminal.

In the present disclosure, a mode determined to operate in the following manner may be referred to as an MEP mode: the partitioning, multiplexing, and transmission are performed through an initialization process between the terminal and the eUICC such that one or more logical interfaces can be used in a single physical interface. It should be noted that if operation in the MEP mode is not determined during the initialization process between the terminal and the eUICC, even the MEP-enabled terminal or the MEP-enabled eUICC will not operate in the MEP mode.

In this disclosure, an enabled state of a profile may refer to a state in which all files and/or applications (e.g., network access applications) in the profile as defined in GSMA sgp.21 are selectable. Further, the disabled state of a profile may refer to a state in which all files and/or applications (e.g., network access applications) in the profile as defined in GSMA sgp.21 are non-selectable.

In the present disclosure, when it is determined that detailed descriptions of related known functions or configurations may unnecessarily obscure the subject matter of the present disclosure, the detailed descriptions thereof will be omitted.

Hereinafter, embodiments provided by the present disclosure will be described with reference to the accompanying drawings.

First, a Universal Integrated Circuit Card (UICC) is a smart card inserted and used in a terminal (e.g., a mobile communication terminal), and is also called a UICC card. An access control module for accessing a network of a mobile communication service provider may be included in the UICC. Examples of such access control modules include Universal Subscriber Identity Modules (USIMs), subscriber Identity Modules (SIMs), internet protocol multimedia service identity modules (ISIMs), and the like.

UICCs including USIMs are commonly referred to as USIM cards. Similarly, a UICC comprising a SIM module is often referred to as a SIM card. It should be noted that in the following description, SIM cards may be used in a conventional sense, including UICC cards, USIM cards, UICCs including ISIM, and the like. That is, it is apparent that the technical application of the SIM card can be equally applied to a USIM card, an ISIM card, or a general UICC card.

The SIM card stores personal information of a mobile communication subscriber and performs user authentication and service security key generation when accessing a mobile communication network, thereby realizing secure mobile communication use.

In manufacturing a SIM card, the SIM card is generally manufactured as a dedicated card for a corresponding mobile communication carrier, and authentication information for network access of the corresponding carrier, such as USIM application and IMSI, K value, OPc value, etc., are all loaded on the card in advance and shipped at the request of a specific mobile communication carrier. Thus, the manufactured SIM card is provided to the user by the corresponding mobile communication service provider, and if necessary, management such as installation, modification, deletion, etc. of the application in the UICC can be performed by using a technology such as OTA.

By inserting the UICC card into the mobile communication terminal owned by the user, network and application services corresponding to the mobile communication carrier can be used. When the mobile communication terminal is replaced, the UICC card is removed from the existing mobile communication terminal and a new mobile communication terminal is inserted, so that the authentication information, mobile communication phone number, personal phone book, etc. stored in the UICC can be used as the UICC card in the new mobile communication terminal.

However, it is inconvenient for a user of a mobile communication terminal for the SIM card to receive services from other mobile operators. It is inconvenient for a user of the mobile communication terminal to physically obtain the SIM card to receive services from the mobile communication carrier. For example, when traveling to another country, it is inconvenient for a user to obtain a local SIM card in order to receive a local mobile communication service. In the case of the roaming service, the above inconvenience is solved to some extent, but there is a problem in that the service cannot be received if there is an expensive fee and a contract is not made between the corresponding mobile operators.

Meanwhile, when the SIM module is remotely downloaded and installed on the UICC card, the above-mentioned inconveniences can be solved to a great extent. That is, a SIM module of a mobile communication service that a user wants to use at a desired time may be downloaded to the UICC card. Such UICC card can download and install a plurality of SIM modules, and can select and use only one SIM module among the plurality of SIM modules. Such UICC card may or may not be fixed to the terminal. In particular, the UICC fixed to the terminal and used is called eUICC. In general, the eUICC refers to a UICC card that is fixed for use on a terminal and can download and select SIM modules remotely. In the present disclosure, UICCs that can remotely download and select SIM modules are collectively referred to as euiccs. That is, among UICC cards capable of remotely downloading and selecting a SIM module, a UICC card fixed to a terminal and a UICC card not fixed are commonly used as euiccs. In addition, the downloaded SIM module information is collectively referred to as the term "profile".

Even if there are multiple profiles in the eUICC, only one profile can be enabled at a time. Thus, even if a terminal supports two or more baseband and two or more profiles exist in the corresponding eUICC, the terminal cannot support dual SIM functionality that can use both profiles simultaneously in one mobile phone. As a method to solve this problem, two euiccs can be installed in the terminal, but this requires the installation of additional eUICC modules and physical interfaces for connecting the eUICC modules to the baseband of the modem, so that the terminal manufacturer may incur the cost of purchasing the additional eUICC modules and physical pins for the physical interfaces. In addition, ensuring the installation space of the terminal is also a problem due to the module and the physical pins.

Since both the current terminal and the eUICC handle the initialization between them based on the assumption that only one profile can be enabled at the same time in the eUICC, during the initialization process between the UE and the eUICC, no method for determining support for the MEP and the operations handled by the terminal or the eUICC according to the determination are defined. In particular, when a removable MEP-enabled eUICC is inserted into a terminal, the operations handled by the eUICC are not defined. Accordingly, the present disclosure aims to solve this problem. Furthermore, when a user in an eSIM terminal wants to use a PPR1 profile enabled in an eUICC by swapping a connection from a baseband occupied by the PPR1 profile to another baseband, there is no consideration of a method of swapping the connection of the corresponding profile, and thus there is a need to solve this problem.

In existing wireless communication systems, it is assumed that a terminal and an eUICC can simultaneously enable only one profile in the eUICC, and methods of handling initialization between the terminal and the eUICC are contemplated. Thus, during initialization between the terminal and the eUICC, a method for determining support for the MEP and operations handled by the terminal or the eUICC according to the determination are not defined. Accordingly, various embodiments of the present disclosure provide a profile processing method when initializing between a UE and an eUICC depending on whether or not to operate in MEP mode in a wireless communication system.

Further, various embodiments of the present disclosure provide a method in a wireless communication system supporting MEPs, wherein the eUICC configures a default profile in consideration of PPR1 profiles between the terminal and the eUICC, and the terminal or the eUICC uses the configured default profile information to efficiently manage the profile.

Hereinafter, embodiment(s) provided by the present disclosure will be described with reference to the accompanying drawings.

Fig. 1 illustrates components of a wireless communication system according to an embodiment of the present disclosure.

UE 105 may include generic applications 110, LPA 115, UE framework 120, and MEP-enabled modem 125. Here, the general application 110 is an application that is preloaded in the UE or that can be downloaded and installed, such as an operator application or a SIM card manager application, and can access a profile of the physical SIM (pSIM) 145 or the eUICC 150. On the other hand, the LPA 115 is the application responsible for controlling the eUICC and handles profile management while communicating with the SM-DP+170, the UE user 101, and the ISD-R165 in the eUICC 150. The LPA 115 can be implemented alone or integrated into other general-purpose UE applications. The LPA 115 can configure the UI to obtain user input for local management of the profile, or can configure the UI for corresponding commands to obtain input of the user 101 after receiving a remote management command of the SM-dp+170 from the SM-dp+170, and can then send the management command of the profile to the ISD-R165 of the eUICC 150 to handle activation/deactivation/deletion/update of the profile. Remote Profile Management (RPM) refers to a series of processes in which profile installation/activation/deactivation/deletion and other functions are performed by an instruction transmitted from the SM-dp+170 to the UE. RPM may be requested by a communication carrier, a service provider, or an owner of the UE, so that an instruction may be generated by SM-dp+170.

The communication modem 125 of the UE 105 is a device that modulates and transmits a signal to transmit information and demodulates the transmitted signal at a receiving side to restore an original signal. In the case of an MEP-enabled modem, two or more baseband processors (hereinafter baseband) for wireless communications may be installed in the communications modem 125. The baseband may be logically implemented within the modem 125 is connected to the UICC or eUICC through one physical pin (a smart card interface compliant with the ISO7816 standard) and when the modem sends an Application Protocol Data Unit (APDU) for a command to the eUICC 150 through the corresponding interface, the eUICC 150 operates to respond to the resulting value for the APDU. The SIM card (pSIM) occupies one baseband of the modem through one physical pin and one SIM port, SIM port is used interchangeably with SIM card slot and is defined in the GSMA Technical Specification (TS) as "physical and electronic shells provided on the device for housing a physical SIM card".

The MEP-enabled eUICC 150 connects to the MEP-enabled modems 125 through one physical pin, and the profile in the eUICC occupies one baseband in the MEP-enabled modems 125. Each profile communicates through an eSIM port with a baseband mapped to the eSIM port. For example, in fig. 1, profile 1 155 occupies baseband 1 130 using eSIM port 1 in the enabled state, and profile 2160 occupies baseband 2 135 using eSIM port 2 in the enabled state. In this case, in fig. 1, pSIM 145 is inserted, but there is no baseband connection. On the other hand, ISD-R165 is an entity in the eUICC 150 that can only be selected in the LPA 115 or modem 125 and can store metadata of the profile (155, 160) or state and configuration information of the profile (155, 160) in the eUICC 150 or collect such information through eUICC internal operations and can return the collected state and configuration information when a command is received from the LPA 115 or UE 105. For example, as a message of the ISD-R select command APDU or APDU, a command such as GetProfileInfo () may be received. Meanwhile, the LPA 115 is software running on the UE framework 120, and the functions of the LPA 115 may be partially integrated into the UE framework 120. The message sent from the LPA 115 to the eUICC 150 is ultimately sent (120) to the eUICC 150 via the UE framework 120 and the modem 125, and the eUICC 150 that receives the message recognizes the ES10c command in the APDU sent from the LPA 115 and performs the profile management operations of the eUICC 150.

In fig. 1, for convenience of explanation below, it is assumed that there are two profiles in the eUICC 150, profile 1 155 and profile 2 160, but is not limited thereto. It may be noted that depending on the memory capabilities of the eUICC 150, there may be more profiles, and two or more profiles may exist in an enabled state. In an eUICC supporting an MEP, profile 1 155 and profile 2 160 can be enabled at the same time, while in an eUICC not supporting an MEP, only one of profile 1 155 or profile 2 160 can be enabled. The ISD-R165 generates a new ISD-P (meaning a security domain for hosting the profile) and the necessary eUICC data and services (e.g., local profile management, profile information, etc.) required for LPA functions as described above) are stored or collected in the eUICC 150 and provided to the LPA115.

Meanwhile, although not shown in fig. 1, for ease of description, the eUICC 150 of the UE 105 can include an embedded UICC control authority security domain (ECASD), which is a space for storing certificates required by the security domain of the eUICC 150, e.g., a root public key of a certificate issuer for verifying SM-dp+ certificates, a key set of eUICC manufacturers, etc., an eSIM operation platform, etc.

UE framework 120 refers to the operating system of UE 105 and exists between modem 125/other UE systems and general application 110/LPA 115. The UE framework 120 can obtain information about the eUICC 150 from the modem 125 and have the obtained information and can return corresponding information when the generic application 110 or LPA115 requests information about the UE 105 or eUICC 150. In addition, the UE framework 120 generates a command APDU according to a channel opening or port opening command received from the general application 110 or the LPA115, and transmits the generated command APDU to the modem 125, receives a response message corresponding to the APDU from the modem 125, and transmits the received response message back to the general application 110 or the LPA115. Further, the UE framework 120 may receive a channel. Transmit (command APDU) called from the general application 110 or the LPA115, and may transmit a corresponding response in a channel. Transmit (response APDU) format to the general application 110 or the LPA115.

The SM-dp+ server 170 refers to a server including a function of generating a profile, encrypting the generated profile, generating a profile remote management command, or encrypting the generated profile remote management command as described above, or a function of supporting activation of a plurality of profiles of the UE 105.

Fig. 2 schematically illustrates an example of a connection between a current v2 embedded universal integrated circuit card (eUICC) and a modem that does not support MEPs in a wireless communication system according to an embodiment of the present disclosure.

In existing v2 euiccs 215, only a single (one) profile can be enabled in the eUICC 215, and local profile management of the unique user is possible without intervention of SM-dp+ in order to handle activation/deactivation/deletion/updating of pre-installed profiles. In the case where the modem 201 does not support MEPs, the modem 201 may have one or more baseband in consideration of the case where the pSIM card is used simultaneously with the eUICC 215, but in the present disclosure, one baseband is assumed so as not to obscure the gist of the present disclosure. During initialization between the UE and the eUICC 215, the modem 201 can determine the maximum number of openable channels through reset Answer (ATR) information received by the eUICC 215 and can generate up to 20 (# 0 through # 19) existing channels. During an initialization process between the modem 201 and the eUICC 215, the modem 201 can select the ISD-R230 in the eUICC 215 and can generate a channel for transmitting APDUs by managing channel-on commands. Next, when a channel-opening request is received from the UE framework at a specific point in time, the modem 201 additionally opens each independent channel for processing the profile between the application and the eUICC 215 or the APDU transmission between the LPA and the ISD-R230 to transmit APDUs. In the prior art, since only one physical interface 210 is used between the modem 201 and the eUICC 215, the modem 201 allocates separate channels to send APDUs so that APDUs transmissions to the end between the application and the eUICC 215 or between the LPA and the ISD-R230 in the profile can be handled in the physical interface 210.

In the eUICC up to the v2 eUICC 215, only one profile can be enabled at a time. An enabled profile, such as case 1 (2100) or case 2 (2200), occupies one baseband 205 of the modem 201, and when a REFRESH (REFRESH) proactive command needs to be sent to the modem 201 in the enabled profile of the eUICC 215, the modem 201 can send APDUs over the channel of the application ID pre-assigned to the enabled profile. For example, in case 1 (2100), the USIM application of profile 1 220 may transmit APDUs through any channel #0 240 allocated by the modem between baseband 1 205 and profile 1 220.

On the other hand, when ISD-R230 receives an esa.enableprofile (profile 2) request from LPA for a state change of a profile, e.g., a state change from case 1 (2100) to case 2 (2200), or when an eUICC memory reset is requested, ISD-R230 may send an active command including an eUICC reset and/or a profile state change (eUICC profile state change) to modem 201 via a refresh active command in order to handle data deletion and/or restart an application session for a previously cached profile. In this case, the ISD-R230 transmits a response APDU to the modem 201 indicating that there is an proactive command as a return value of the APDU transmitted by the modem 201 to the ISD-R230, and the modem 201 may receive the response APDU and may issue a retrieve (FETCH) APDU command to the basic channel to return the proactive command for UICC reset or eUICC profile state change as a body of the response APDU of the corresponding message. When the state change from case 1 (2100) to case 2 (2200) is completed, in case 2 (2200), the USIM application of profile 2 225 can transmit APDUs through any channel 245 between baseband 1 205 and profile 2 225 allocated by modem 201.

Fig. 3 schematically illustrates an example of a connection between an eUICC and a modem according to the introduction of virtual interface concepts in a wireless communication system according to an embodiment of the present disclosure.

For ease of description, in fig. 3, it is assumed that the eUICC 320 supports MEP functionality that enables multiple profiles simultaneously. Meanwhile, it is assumed that the modem 301 also supports the MEP function. In fig. 3, a case where there are two base bands (base band 1 305 and base band 2 310) and two enabled profiles (profile 1 325 and profile 2 330) will be described as an example. The mapping between baseband and eSIM ports in modem 301 may be switchable, but in case 1 (3100) to case 3 (3300) of fig. 3, the mapping of logical terminal endpoints in modem 301 may be described restrictively between baseband 1 305 and channel 1 340 and between baseband 2 310 and channel 2 345 in order not to obscure the gist of the present disclosure.

The MEP-enabled eUICC 320 can enable multiple profiles, and each enabled profile can occupy and use a particular baseband of the modem 301. In MEPs, since two or more profiles may be enabled simultaneously, a logical interface concept for multiplexing the existing physical interfaces 315 and dividing the multiplexed interfaces for each enabled profile to transmit APDUs may be introduced. Hereinafter, for convenience of description, the corresponding logical interfaces are referred to as eSIM ports, and are divided into eSIM port #1 340, eSIM port #2 345, and eSIM port #0 360.

As a result of the initialization between the UE and the eUICC 320, a port and a transmission channel in the port for APDU transmission between the modem 301 and the eUICC 320 can be generated. In this case, eSIM port IDs mapped to each baseband can be configured. The corresponding port ID may be configured in the modem 301 or the UE platform and sent to the LPA. In the present disclosure, for convenience of description, a port ID is interchangeably used as a port number. The modem 301 may have the same number of eSIM ports as the baseband number, but the number of eSIM ports used by the eUICC 320 may be equal to or less than the number of profiles that can be simultaneously enabled in the eUICC 320. The profile can receive APDU messages using one of the corresponding eSIM ports and can send proactive commands to the modem 301.

In the examples of cases 1 through 3 of fig. 3, the modem 301 may send APDU commands to the enabled profile 1 325 through eSIM port # 1340. Profile 1 325 can send proactive commands to baseband 1 305 through eSIM port #1 340. The modem 301 may send APDU commands to the enabled profile 2 330 through eSIM port # 2345. Profile 2 330 can send an proactive command to baseband 2 310 through eSIM port #2 345.

Meanwhile, as in case 1 (3100), case 2 (3200), or case 3 (3300) to be described below, the UE modem 301 may configure a channel for transmitting APDUs to the ISD-R335 as one of the following methods.

-case 1 (3100): the transport channel is turned on so that ISD-R335 can be selected through only one of the eSIM ports. The eSIM port used by ISD-R335 shares a port with the profile, but uses a single independent channel within the port. In this case, for example, the LPA transmits and receives APDUs to/from the ISD-R335 only through the channel 350 allocated to the ISD-R335 in port #1 340.

-case 2 (3200): a transport channel is opened for each port to select ISD-R335 through all eSIM ports occupied by the profile. The eSIM port used by ISD-R335 shares a port with the profile occupying the port, but uses a single independent channel within the port. In this case, for example, the LPA selects one of the channel 355-1 allocated to the ISD-R335 in the port #1 340 or the channel 355-2 allocated to the ISD-R335 in the port #2 345, and simultaneously or asynchronously transmits and receives APDUs to/from the ISD-R335.

-case 3 (3300): the dedicated port and transport channels in the dedicated port are turned on so that ISD-R335 is selected through the dedicated port for ISD-R335. The dedicated port is independent of the eSIM port used by the profile and uses a single channel within the dedicated port. In this case, the LPA transmits and receives APDUs to/from the ISD-R335 using channels 350 allocated in the separate dedicated ports 360 of the ISD-R335, for example.

Fig. 4 illustrates a method by which a UE and eUICC handle local profile activation when the UE operates in MEP mode, according to an embodiment of the present disclosure.

As described above, v2 euiccs that do not support MEP functions are designed to enable only one profile. When there is a previously enabled profile, the previously enabled profile may be changed to a disabled state in the v2 eUICC in order to enable another profile. However, in the case of an eUICC supporting MEP functions, when processing profile activation commands, other currently enabled profiles may not be disabled depending on the location of the eSIM port on which the profile is to be enabled. For example, when an eSIM has an eSIM port 1 and an eSIM port 2, and profile 2 is currently enabled on the eSIM port 2, further, when profile 1 is desired to be enabled on the eSIM port 1, profile 2 currently enabled on the eSIM port 2 is treated as not disabled. Furthermore, when the UE has a baseband supporting different RATs, it is necessary to provide information so that the user or server (at RPM) can determine with which eSIM port the profile to enable matches, since the Radio Access Technology (RAT) that can be provided by the corresponding profile varies depending on the baseband with which the eSIM port matches. For example, where eSIM port 1 matches the baseband supporting a 4G network and eSIM port 2 matches the baseband supporting a 5G network, it may be helpful to select an appropriate eSIM port to enable a particular profile when the user or server performing remote management knows this information.

The number of profiles that are simultaneously enabled in the eUICC at a particular point in time can be limited to be equal to or less than the number of eSIM ports allocated by the eUICC. When it is desired to handle activation of a profile by a user or SM-dp+, the eUICC can return to the eUICC, LPA, or SM-dp+ server the maximum number of profiles that can be enabled, taking into account the number of currently active profiles and the number of eSIM ports.

The LPA or UE software can utilize information sent from the eUICC (e.g., the number of eSIM ports allocated by the eUICC) as predetermined information for informing the user that the currently enabled profile needs to be disabled. Fig. 4 shows a process for enabling a profile as an example of a method for an end user 401 to manage a profile by LPA405 in a MEP enabled UE. The case where all of the eUICC 410, modem 415, and LPA405 in fig. 4 support MEPs will be described as an example.

In operation 420, the end user 401 executes an activate command for a profile installed in the UE through information displayed on the LPA405 or an application in which the LPA405 is integrated and implemented. The LPA405 or LPA-implemented application of the UE can display the list of profiles installed in the eUICC 410 and the current state information of the profiles to the end user 401. Further, radio access technologies that may be provided from the UE for each baseband of the UE modem, information about eSIM ports that match the corresponding baseband for APDU transmission, and occupancy state information from the profile of the corresponding port of the eUICC may additionally be displayed. In this case, LPA405 may determine the profile policy rules for the profile and additionally display a warning message to end user 401, e.g., that it is not possible to activate the profile. In operation 430, when the end user 401 selects a particular profile (designated profile 3) through information displayed on the screen and determines to enable the selected profile, the LPA405 sends an esa 10c.enableprofile (ISD-P AID) or ICCID (profile ID), refreshFlag, port number) command to the eUICC 410 for enabling the profile while including a port number matching the selected baseband. When a refresh proactive command is required, a refreshFlag is additionally configured and sent. The LPA405 may also send the above-described esa10c.enableprofile command without configuring the refreshFlag. However, in this case, before the LPA405 sends the esa 10c.enableprofile command, when an enabled profile exists in the port, the UE may process the end of the application session on the port occupied between the eUICC 410 and the modem 415, close the logical channel opened for selection of the application, and close the active command session between the modem 415 and the eUICC 410, if present, in operation 425.

When an activate profile command is received from the LPA405, in operation 430, the eUICC 410 can perform a deactivation process on the profile occupying the corresponding port (for explanation, referred to as profile 1) and can enable the profile (for explanation, referred to as profile 3) with the ICCID (profile ID) sent to the corresponding port by being included in the ES10c. In operation 435, the ISD-R of the eUICC 410 can determine whether profile 3 can be fully enabled by identifying the enablement status of the profile 3 to be enabled and the existing profile installed in the eUICC 410 and Profile Policy Rules (PPR), and when activation is not possible, the ISD-R of the eUICC 410 can return an error message to the end user 401. In determining whether profile 3 can be enabled in the MEP-enabled eUICC 410, when it is desired to activate profile 3 in the eUICC 410 using a port occupied by an existing profile (referred to as profile 1), it can be determined that the eUICC changes the state of the profile to disabled and changes profile 3 to enabled only for profile 1 using that port. When profile 3 occupies an empty port, the MEP-enabled eUICC 410 can proceed without performing a deactivation process on other profiles in the eUICC.

When the refreshFlag is configured in the ES10c.EnableProfile command in operation 440, then in operation 445 the eUICC 410 may send a refresh active command to the modem 415 requesting a profile state change process or a UICC reset process. In operation 450, the modem 415 may send a terminal response to the eUICC 410 (when the eUICC 410 sends an eUICC profile state change) or not send a terminal response (when the eUICC 410 sends a UICC reset) depending on the results of processing the refresh in the modem 415. In operation 455, after receiving the terminal response by transmitting the eUICC profile state change, or after transmitting the UICC reset, the eUICC 410 can match profile 3 with the port number transmitted in operation 430, and can disable profile (e.g., profile 1) and enable profile 3 when the profile is enabled in the port corresponding to the port number, or can enable only profile 3 when the port is unoccupied.

In operation 460, when the refreshFlag is not configured in the ES10c.EnableProfile command, the eUICC 410 can match the profile 3 selected after operation 435 with the port number sent in operation 430, and in operation 465, can disable the profile (e.g., profile 1) and enable the profile 3 when the profile is enabled in the port corresponding to the port number, or can enable only the profile 3 when the port is an unoccupied port. When the eUICC 410 returns the result of performing the above procedure to the LPA 405 in operation 470, in the UE, the LPA 405 changes the command corresponding to the refresh, such as deleting the cache value, requested and performed by the modem 415 according to the PROFILE state, and in operation 475, the modem 415 performs a UICC activation procedure including a TERMINAL PROFILE (termial PROFILE) defined in ETSI TS. After performing the above procedure, the modem 415 performs a network attach procedure in the baseband connected to the port using information of the profile (e.g., profile 3) newly connected to the port in operation 480.

Meanwhile, although not shown in fig. 4, when the ISD-R receives port information mapped to a profile from the LPA 405, the ISD-R stores mapping information of the corresponding profile and port, and when the LPA 405 requests getProfileInfo () from the ISD-R, or when the LPA 405 requests information for remote profile management from the SM-dp+, the ISD-R may include the profile and port information mapped with the profile, and provide them together. Further, as described in detail later in fig. 6, the eUICC operating in the MEP mode determines whether to configure a default profile of a corresponding profile, updates default profile configuration information with profile information, and provides default profile configuration information with profile information when getProfileInfo () is received from the LPA. That is, the ISD-R may provide at least one of status information of an installed profile, mapping information of an installed profile and a port, ICCID of a profile configured as a default profile, or a port number used by a profile configured as a default profile.

Fig. 5 schematically illustrates maintaining a connection between an eUICC and a modem of an existing configuration when a MEP-enabled UE restarts in a wireless communication system, according to an embodiment of the present disclosure.

In the case of a restart by performing a reset between the UE and the eUICC, such as powering off and on the UE or inserting a removable eUICC into the UE, the MEP-enabled modem 501 and the MEP-enabled eUICC 505 can process to maintain the association between baseband, eSIM ports, and profiles prior to the restart. When the eUICC 505 receives an esa.enableprofile (profile ID to be enabled or application ID, port number) command to enable a profile in a particular eSIM port, the eUICC 505 can enable the profile and store mapping information between the profile and the eSIM port as metadata for the profile or profile information in the eUICC's memory. As described above, when the eUICC 505 has an eSIM port of the profile enabled during initialization with the UE, the number(s) of the eSIM port in which the profile is enabled can be returned to the modem 501 via one of ATR, a response message to terminal capabilities, an isdroprimaryapplication template, or a response message to a configuration information request sent by the eUICC 505 in the UE via a port. On the other hand, the modem 501 stores mapping information between baseband and eSIM ports configured before power is turned off and on again (power cycling), and performs a mapping process with the same eSIM port number by resetting the connection to the eSIM port number provided by the eUICC when information for the eSIM port number(s) for which a profile is enabled is received from the eUICC.

In fig. 5, it is assumed that a baseband 1 (4G supported) 510 to eSIM port #1 520 connection and a baseband 2 (5G supported) 515 to eSIM port #2525 connection are configured in the MEP-enabled modem 505, and that profile 1 530 is enabled in eSIM port #2525 and profile 2 535 is enabled in eSIM port #1 520 in the MEP-enabled eUICC 505. When the initialization between the UE and the eUICC is performed by a restart, the eUICC 505 can return to the modem 501 one of #1 and #2, eSIM port numbers as enabled profiles, and #1, port numbers as enabled default profiles, through ATR, a response message of terminal capabilities, an isdroprimary application template, or a response message to a configuration information request sent by the eUICC 505 in the UE through a port during initialization with the UE. When the modem 501 determines operation under the MEP by receiving port number information, the modem 501 may determine the fact that at least two eSIM ports need to be generated for the profile connection based on previously stored mapping information between the eSIM ports and the baseband, and may map eSIM port #1 520 to baseband 2 (5G) 515 and eSIM port #2525 to baseband 1 (4G) 510.

On the other hand, the eUICC505 has mapping information between eSIM port numbers and profiles stored as profile information, and can handle connections for activating profile 2 535 on eSIM port #1 520 and connections for activating profile 1 530 on eSIM port #2 525. On the other hand, when the eSIM port number(s) #1 and #2 cached by the modem 501 prior to the restart are different from the eSIM port number(s) received from the eUICC505, or when the ID (EID) of the eUICC505 received as one of an ATR, a response message to a terminal capability, an isdroprimarypapplication template, or a response message to an eUICC505 in the UE through a port-transmitted configuration information request is different from the previously cached EID, the modem 501 may determine that a new removable eUICC has been inserted, delete the previously cached eSIM port number(s) when generating the new eSIM port(s), allocate the new port number(s), and provide the new port number(s) to the eUICC505.

Fig. 6 illustrates a method of configuring a default profile by an MEP-enabled eUICC inserted or fixed in a UE, according to an embodiment of the present disclosure.

When the eUICC 610 performs default profile configuration via a profile activation command, the eUICC 610 in communication with the eSIM-enabled UE can be a removable eUICC or an eUICC that is fixed to the UE, which supports MEPs. In operation 620, the end user 601 may select a profile to be enabled in the LPA 605. In operation 625, when the end user 601 selects a profile to be enabled in the LPA 605, the LPA 605 can send a profile activation command to the eUICC 610. In this case, the LPA 605 operating in MEP mode may include and transmit the ICCID of the profile to be enabled, as well as eSIM port numbers as identification information indicating on which eSIM port the profile is to be enabled. For example, the command may include an ES10c.EnableProfile (ICCID, refreshFlag and Port# -of profile to be enabled) message. In operation 630, the eUICC 610 that has received the profile activation command can determine whether the corresponding profile has been enabled and can verify information regarding the profile policy rules for the corresponding profile. At operation 635, when it is determined through verification that activation of the corresponding profile is possible, the eUICC 610 processes the activation of the corresponding profile and selectively sends information regarding the change in profile state to the modem 615, e.g., by refreshing an proactive command message, to cause the modem 615 to perform necessary operations, such as a reset, to complete the activation of the corresponding profile.

In operation 640, when there is one enabled profile as a result of enabling the corresponding profile, the eUICC 610 can configure the corresponding profile as a default profile and store the default profile. When there are one or more enabled profiles as a result of the corresponding profile being enabled, and the corresponding profile to be enabled in operation 630 is the profile in which PPR1 is configured, the eUICC 610 can change and configure the profile in which PPR1 is enabled to be configured as a default profile, regardless of whether the previous default profile is configured. In the case where the removable MEP-enabled eUICC is inserted into an eSIM UE that does not support MEPs, when a profile activation command is received from the LPA, the eUICC can configure and store the default profile through the determination process in operation 640, regardless of whether the activation command includes an eSIM port number and is received.

In another embodiment of configuring the default profile (operations 645 through 680), the lpa 605 can provide a screen to the end user 601 for configuring the default profile in operation 645 so that the end user 601 can configure the default profile through the UI.

In this case, the LPA 605, eUICC 610, and modem 615 are all MEP-enabled modules and can operate in MEP mode during initialization between the UE and eUICC. Further, the eUICC 610 can be a removable eUICC or an eUICC that is fixed to the UE. LPA 605 may not selectively display the UI for configuring the default profile when there is one enabled profile in the UE or when the profile that has been configured with PPR1 is enabled.

When the end user 601 selects one of the profiles through a screen for configuring the default profile of the UE and inputs the configuration as the default profile in operation 645, the LPA 605 of the UE may send a command to the eUICC 610 to configure the selected profile as the default profile in operation 650. For example, the command may include a message such as ES10c.SetDefaultProfile (ICCID of the selected profile). When the eUICC 610 receives the esa.setdefaultprofile (ICCID of the selected profile) from the LPA 605, the eUICC 610 verifies whether the profile corresponding to the ICCID is enabled and verifies whether a profile with PPR1 exists in the existing profile of the eUICC 610 at operation 655. Depending on the validation result, the euicc 610 can send an error message to the LPA 605 at operation 660, or process the default profile configuration at operation 670, and can successfully return a response to the configuration to the LPA 605 at operation 675.

As a result of the verification in the eUICC 610, the case of sending an error message may be that the ICCID of the profile configured in the ES10c.setdefaultprofile (ICCID of the selected profile) is the ICCID of the disabled profile, or that a change to the default configuration of the PPR1 profile is required by the corresponding request. In this case, the error message returned by the eUICC 610 can be, for example, one of the error messages such as profilenonenabledstate and changeNotAllowedbyPPR 1.

On the other hand, when the UE determines to operate in a non-MEP mode during an initialization process between the UE and the eUICC (such as a restart between the UE and the eUICC), it is also possible to disable or not display a method for configuring a user selection menu of default profiles in the LPA605 supporting MEPs. However, there may be a possibility that the user selection menu is exposed and ES10c.SetDefaultProfile (ICCID of the selected profile) is transmitted to the eUICC 610 according to the end user's selection. In the event that the eUICC 610 receives this message, when the eUICC operates as a generic eUICC in an initialization procedure between the UE and the eUICC (such as a restart between the UE and the eUICC), the eUICC 610 can return an error message to the LPA605 because even if the eUICC is an MEP-enabled eUICC, it is not possible to handle the default profile configuration in the same manner as if the generic eUICC was not supported.

LPA605, having received the error or success response message, can optionally provide a message to end user 601UI regarding the default profile configuration results to direct the processing results to end user 601. That is, when the LPA605 receives the error message, the LPA605 may notify the end user 601 of the error of the default profile configuration and may end the process in operation 665. Further, when the LPA605 receives the success response message, the LPA605 may inform the end user 601 that the default profile configuration has been completed and may end the process in operation 680.

Meanwhile, the method for the eUICC 610 to configure the default profile in operations 620 to 640 of fig. 6 can be similarly applied even when the previously configured default profile is disabled. For example, when the end user 601 selects a profile to disable and the LPA605 requests an esa 10c.disable profile (ICCID, refreshFlag, [ port# ]) from the eUICC 610 for profile deactivation, the eUICC 610 can verify whether the profile corresponding to the ICCID is in an enabled state and not a PPR1 profile. Deactivation of the profile corresponding to the ICCID defined in sgp.22 can be handled if possible. Next, similar to operation 640, when the eUICC 610 determines that there is an enabled profile in the eUICC 610 as a result of the deactivation of the default profile, the eUICC 610 can change and configure the one enabled profile to the default profile. When the eUICC 610 determines that there are two or more remaining enabled profiles in the eUICC 610 due to deactivation of the default profile, the eUICC 610 can configure the profile configured in the particular port (e.g., low port number) as the default profile based on the stored configuration, or request reconfiguration of the default profile through other operations (operations 645 to 680) while returning the profile deactivation process results to the LPA605.

Fig. 7 illustrates a process of configuring a default profile in the LPA of a UE according to an embodiment of the present disclosure.

Referring to fig. 6 above, the lpa may or may not operate in MEP mode, and the MEP-enabled eUICC may or may not operate in MEP mode. In fig. 7, a case where the LPA operates in the MEP mode will be described as an example.

Referring to fig. 7, in operation 705, the LPA operating in the MEP mode may provide a menu for configuring a default profile to a user, thereby receiving input of the user's default profile configuration. When the UE does not determine to operate in the MEP mode during an initialization process between the UE and the eUICC, the LPA may operate as a MEP-non-supporting LPA without displaying a menu for selecting a default profile or a disable menu on the screen so that the user cannot select the default profile. Further, even when the LPA operates in the MEP mode, the LPA can identify the number of profiles enabled in the eUICC using information obtained by sending a GetProfileInfo () or ISD-rproprimantarttemplate command to the eUICC, and can not expose a menu or disable selection so that the user cannot select a default profile when there is one enabled profile in the eUICC.

In operation 710, when the user clicks on a profile to be selected as a default profile or selects a profile as a default profile by selecting one of the specific ports for which the profile is enabled, the LPA may detect an event for configuring the default profile and may send an esa.setdefaultprofile (ICCID) command to the eUICC while including the ICCID of the selected profile or the ICCID of the profile enabled in the selected port.

In operation 715, the LPA may receive a processing response result for the corresponding command from the eUICC. The corresponding received response may be an error message (such as profilenonenabledstate and changeNotAllowedbyPPR 1) or one of the messages used for conventional response processing. As described above in fig. 6, a case in which an MEP-capable eUICC, which does not operate in MEP mode, is inserted into a UE is possible. In this case, the LPA may receive an error message in response, which includes the inability to process the corresponding message.

At operation 720, the LPA receiving the corresponding message may optionally notify the user of the processing result based on the returned code value and the message. Upon receipt of profileNotInEnabledState, changeNotAllowedbyPPR or other error message, the LPA may display a notification message to the user that the default profile cannot be configured and may end. Upon receipt of the success response message, the LPA may display information to the UI indicating that the default profile configuration has been completed, and may end. For example, the success response message may be a response message such as status code=ok, error cause=setdefaultprofileResults.

Fig. 8 illustrates a method in which the eUICC uses default profile information in an initialization process between a UE and a MEP eUICC to determine profile processing, according to an embodiment of the present disclosure.

The removable eUICC supporting the MEP may be an eUICC that was inserted into another UE before being inserted into the UE in fig. 8 and has performed the above-described procedure of fig. 6.

In operation 805, when an eUICC supporting an MEP is inserted into a UE, the eUICC can determine whether the corresponding UE is a UE supporting an eUICC function through predetermined information received from the UE. Regarding whether the UE supports the eUICC function, in the initialization process between the UE and the MEP eUICC as described above in fig. 5, the eUICC may receive a terminal capability (TERMINAL CAPABILITY) command message from the UE, and when an "83" tag, which is an identifier indicating eUICC-related capability, is not included in the terminal capability command message received from the UE, it may be determined that the UE does not support the eUICC function. In operation 815, when the eUICC determines that the UE does not support the eUICC function, the eUICC can determine whether an enabled profile exists.

Meanwhile, when the "83" tag is included in the terminal capability command message received from the UE, the eUICC can determine that the UE supports the eUICC function in operation 805. However, when a command for channel opening is received from the command APDU received from the UE later in operation 810 without an identifier indicating that the eUICC has entered the MEP mode, the eUICC determines the UE as an MEP-non-supporting UE and checks whether an enabled profile exists in operation 815.

The modem may transmit the command APDU by including identification information indicating that the operation in the MEP mode is determined in a header of the command APDU. In operation 810, when the header of the command APDU includes a Class (CLA) related to a management PORT (management PORT) and an instruction code (INS) indicating an initialization request for the management PORT as identifiers indicating entry into the MEP mode, or when the header of the command APDU includes a CLA related to a management channel (MANAGE CHANNEL) and an INS indicating connection to a logical interface as identifiers indicating entry into the MEP mode, the euicc may determine to enter the MEP mode in operation 840.

In operation 815, when the corresponding identifier is not received, the eUICC can determine whether an enabled profile exists and process the operations as follows.

In operation 835, when there is no enabled profile as a result of the determination, the eUICC operates as a general eUICC that does not support the MEP defined in sgp.22 and processes subsequent operations.

In operation 820, when an enabled profile exists, it is determined whether an enabled profile exists.

As a result of the determination, when there is only one profile enabled, the eUICC maintains the state of the profile in an enabled state in operation 825, and operates as a general eUICC that does not support MEPs defined in sgp.22 to handle subsequent operations in operation 835.

As a result of the determination, when there are two or more enabled profiles, the euicc determines stored information about the profiles configured as default profiles and changes the states of the remaining profiles other than the default profiles to a disabled state in operation 830. The eUICC can handle the change to the disabled state without receiving an explicit command from the LPA for the received disabled profile and can handle the change to the disabled state without sending a refresh command to the modem for reset. At operation 835, the eUICC, which has changed the status of the remaining profiles except the default profile to the disabled state, operates as a general eUICC that does not support the MEP defined in sgp.22 and processes subsequent operations.

When the "83" tag is included in the terminal capability command message received from the UE, and the command APDU received from the UE includes an identifier indicating entry into the MEP mode, the eUICC can determine operation in the MEP mode in operation 810. A method of the eUICC entering the MEP mode and processing the profile with reference to default profile information in operation 840 will be described in detail later with reference to fig. 10.

Fig. 9 illustrates a method of processing profile processing with reference to default profile information in the eUICC when operating as a generic eUICC in fig. 8, according to embodiments of the present disclosure.

Fig. 9 schematically illustrates an example of an initialization procedure between a UE and an eUICC in a wireless communication system, and describes a procedure for handling profiles by referring to default profile information in the eUICC and operating as a general eUICC.

Referring to fig. 9, the modem 905 may determine whether the eUICC 910 is inserted by receiving a response to a periodic STATUS COMMAND (STATUS COMMAND) or an electrical signal according to eUICC insertion, and may recognize that the eUICC is inserted when the eUICC 910 is inserted into the UE. In fig. 9, the removable eUICC 910 supporting the MEP can be an eUICC that has been inserted into another UE before being inserted into the UE and has performed the process described above in fig. 6. In operation 915, the UE performs an activation and a cold reset to configure an operating environment (such as power, clock synchronization, current, and voltage) for operation with the eUICC to use the eUICC. At operation 920, the eUICC 910 returns a reset Answer (ATR) message to the modem 905 when the configuration of the operating environment in which the eUICC is used is complete. The ATR message is the first message the eUICC sends to the UE, and message blocks consisting of up to 32 bytes are sent in a continuous chain.

In operation 920, the eUICC 910 can return the ATR message to the UE by including the eUICC function defined in GSMA sgp.22 as one of the message blocks defined as interface bytes in the message block of the ATR message. Meanwhile, the eUICC 910 can include the supported transport protocol and information indicating whether the transport protocol is changeable in an ATR message and then return the ATR message to the UE. The modem 905 may determine to use the transport protocol supported by the eUICC based on the information included in the received ATR message. Alternatively, when there is an identifier in the ATR message that whether the transport protocol can be changed, the modem 905 can negotiate the transport protocol to be used between the modem 905 and the eUICC 910 at operation 925 by additionally sending a request to the eUICC 910 to determine the transport protocol and parameters, and finally determining the transport protocol to be used by the modem 905 at operation 930.

After receiving the ATR, the modem 905 can implicitly select the Master File (MF) of the eUICC 910 in operation 923. When there is no enabled profile, the MEP-enabled eUICC 910 can process to display only MF-level base files (EF) as a default file system, and when there is more than one enabled profile in the eUICC 910, can further process to display only the default file system and the file system of one default profile so that the UE can selectively process the default profile at the corresponding point in time. Alternatively, when there is more than one enabled profile in the eUICC 910, the eUICC 910 can process to not display the file systems of all enabled profiles at the corresponding points in time, even if a default profile is present. Thereafter, in operation 935, in the event that the eUICC 910 receives terminal capabilities without identifiers for eUICC support or without identifiers for eUICC support and MEP support, or when terminal capabilities without initialization information are received by the MEP in operation 950, only the file system of the default profile may be additionally displayed in the default file system. As will be described later, in operation 935 or operation 950, when only the default profile remains and there are other enabled profiles, the eUICC can disable the other enabled profiles. In operation 935 or operation 950, when other enabled profiles are present, a file system that additionally displays only the default profile through the eUICC 910 can be executed before or after the other enabled profiles are deactivated.

Through operation 930, the ue and the eUICC 910 can send an Application Protocol Data Unit (APDU) message, which is a transport protocol defined in ISO 7816-3, using t=0 or t=1. APDUs are data units consisting of a pair of commands and responses and are used for message processing between other ones of the applications. The modem 905 may allow eUICC-related capabilities, such as whether the UE supports LTA, whether the UE supports enterprise functions, whether the UE supports MEPs, etc., among the UEs to be included in the terminal capabilities, defined in sgp.22, and may transmit the terminal capabilities to the eUICC 910 at operation 935. As described above, whether the UE has eUICC-related capabilities may be determined by an "83" tag (tag "A9") defined in the terminal capability template. The UE may inform the UE of whether the MEP is supported by a bit as to whether the MEP is supported in the "83" tag or whether there is a newly defined tag (non "83" tag) for the MEP in the terminal capability template (tag "A9").

In operation 940, the euicc 910 can allow a response code (status word) of the processing result to be included in an APDU header as a response to the terminal capability and can transmit the APDU header. The response code may be one of the terminal capability answer response codes defined in the European Telecommunications Standards Institute (ETSI) Technical Specification (TS). For example, when the eUICC 910 sends default file information, etc., to the modem 905 as examples of additional information, the eUICC 910 can send a response code that indicates that additional data is present.

The eUICC 910 can determine whether an MEP is supported in the received terminal capabilities, and when no identity information for the MEP is supported, can determine whether an enabled profile exists in the eUICC 910, and can determine that at most one profile is enabled.

When only one profile is enabled, the enabled state of the enabled profile may be maintained as described above. When two or more profiles are enabled, the eUICC 910 can selectively determine whether there is a profile configured as a default profile through stored profile information or stored configuration information, in the event that the profile(s) are not configured as default profiles, all states can be changed to disabled, and subsequent operations can be handled as in a general eUICC that does not support MEPs. When the eUICC 910 operates to leave only one profile and implicitly change the other profile state(s) to the disabled state without user consent, the eUICC 910 can complete the deactivation process without sending a refresh command to the modem 905 according to the profile state change.

On the other hand, when the eUICC 910 identifies a tag value of the eUICC-related capability or a tag identifying the eUICC-related capability and an MEP-supported identifier from the received terminal capabilities, in operation 935, the eUICC 910 does not determine the profile to be maintained enabled, but rather can determine to select one or more profiles to be maintained enabled at or a particular point in time after a point in time that indicates an identifier operating in MEP mode is received. As described above, in operation 945, the UE may determine to operate in a non-MEP mode. When the UE operates in the non-MEP mode, the UE does not transmit an extended management channel including an identifier of a logical interface distinguishable to a management port or management channel, and may transmit a command APDU for management channel opening, which is transmitted for channel opening at the time of initialization between a general eUICC and the UE, in operation 950. The eUICC 910 that has received the APDDU may recognize that there are no identifiers for MEP support described above in fig. 9, and may determine that the operation can be handled in the general eUICC rather than MEP mode.

When determining that the eUICC 910 operates as a generic eUICC, the eUICC 910 can determine whether an enabled profile exists in the eUICC 910 and can determine that at most one profile is enabled. When only one profile is enabled, the enabled state of the enabled profile may be maintained as described above. When two or more profiles are enabled, the eUICC 910 can selectively identify, through information of the stored profiles or configuration information, whether there is a profile configured as a default profile, and if the profile is not a profile configured as a default profile, the eUICC itself can change all profiles to disabled and can be configured to handle subsequent operations as in a general eUICC. Meanwhile, a profile configured as a default profile may be defined as an enabled profile having the lowest port number among the enabled profiles. For example, in the case where the removable MEP-enabled eUICC 910 was previously installed in the first MEP-enabled UE and performs the operations as shown in fig. 6, the default profile with the lowest port number in the enabled profile may be the profile with port #0 when ISD-R dedicated ports are not used. Alternatively, when using the ISD-R specific port, the ISD-R specific port uses port #0, and the default profile having the lowest port number among the enabled profiles may be the profile having port # 1.

When the eUICC 910 implicitly changes other profiles to disabled without user consent by determining that only one profile is maintained in an enabled state during initialization between the UE and the eUICC 910, the eUICC 910 can complete the deactivation process without sending a refresh command message to the modem 905 according to the profile state change (i.e., change to disabled state). Further, when logical interfaces are not supported, the eUICC 910 can recognize one interface generated by the modem 905 with the eUICC 910 as port #0 and can change the port number of the default profile in the initialization process to port #0 to process the mapping.

The eUICC 910 can return a conventional response to a logical interface OPEN command (e.g., a management channel OPEN (MANAGE CHANNEL OPEN) command APDU) received from the modem 905 to complete basic channel generation for APDU transmission between the modem 905 and the eUICC 910 in the logical interface. On the other hand, when the modem 905 needs to receive additional information from the eUICC 910 during the initialization process between the UE and the eUICC, the modem 905 can selectively send a SELECT command (application ID of ISD-R) to obtain the additional information in operation 955. When the eUICC 910 receives the command APDU, the eUICC 910 returns an isdropprioraryapplication template in operation 960 to provide additional information to the modem 905 including the presence or absence of an enabled profile in the eUICC 910, as an example. In operation 965, the modem 905 may transmit the additional information received from the eUICC 910 to the UE framework 901 to provide additional information to be used in an application or system of the UE. In fig. 9, the additional information transmitted is shown as if after receiving isdropprietaryapplication template is integrated by modem 905 and transmitted to UE framework 901, but modem 905 may sequentially or collectively transmit the additional information at a specific time after obtaining the additional information from eUICC 910.

Fig. 10A and 10B illustrate a method of referring to default profile information handling profile processing in an eUICC and a UE when operating as the MEP eUICC in fig. 8, according to an embodiment of the present disclosure.

Referring to fig. 10A and 10B, when the eUICC 1010 is inserted into the UE, in operation 1015, the modem 1005 recognizes the eUICC 1010 and performs activation and cold reset to configure an operating system (such as power, clock synchronization, current, voltage, etc.) for operation with the eUICC 1010 in order to use the eUICC. When the configuration of the operating environment using the eUICC 1010 is complete, the eUICC 1010 returns an ATR message to the modem 1005 at operation 1020. The ATR message is the first message that the eUICC 1010 sends to the UE, and the ATR message includes a message block consisting of up to 32 bytes sent in a continuous chain.

In operation 1020, the eUICC 1010 can include, as one of the message blocks defined as interface bytes, whether the eUICC function defined in GSMA sgp.22 is supported in the message block of the ATR message and return the ATR message to the UE. Meanwhile, the eUICC 1010 can return an ATR message that includes information indicating supported transport protocols and information indicating whether the transport protocols can change together. The modem 1005 may determine to use the transport protocol supported by the eUICC based on information included in the received ATR message. Alternatively, when there is an identifier in the ATR message that whether the transport protocol can be changed, the modem 1005 can negotiate in operation 1025 the transport protocol to be used between the modem 1005 and the eUICC 1010 by additionally sending a request to the eUICC 1010 to determine the transport protocol and parameters, and can ultimately determine in operation 1030 the transport protocol to be used by the modem 1005.

In fig. 10A and 10B, after receiving the ATR, the modem 1005 can implicitly select the MF of the eUICC 1010 in operation 1028. When there is no enabled profile, the MEP-enabled eUICC 1010 can process to display only MF-level base files (EF) as a default file system, and when there is more than one enabled profile in the eUICC 1010, can further process to display only the default file system and the file system of one default profile so that the UE can select the default profile at the corresponding point in time. Alternatively, when there is more than one enabled profile in the eUICC 1010, the MEP-enabled eUICC 1010 can be treated as a file system that does not display all enabled profiles at the corresponding point in time, even if there is a default profile.

Through operation 1030, the ue and the eUICC can transmit the APDU message using t=0 or t=1, t=0 or t=1 being a transmission protocol defined in ISO 7816-3. APDUs are data units consisting of a pair of commands and responses and are used for message processing between other applications in one application. The modem 1005 may allow for including in the terminal capability the eUICC-related capability in the UE defined in sgp.22, such as whether the UE supports LPA, whether the UE supports enterprise functions, whether the UE supports MEPs, etc., and may send the terminal capability to the eUICC 1010 in operation 1035. Further, as described above, whether to support the MEP may be added as a separate tag inside or outside the eUICC support capability in the template of the terminal capability and sent. In operation 1040, the eUICC 1010 that has received the terminal capability message can recognize whether the UE is an eUICC-enabled and MEP-enabled UE in addition as described in fig. 9, so that configuration values in the eUICC can be determined and a conventional response to the command APDU can be returned to the modem 1005. The regular response code may be one of the terminal capability reply response codes defined in the 10.2.2 section status word of the command of ETSI TS 102.221. For example, the eUICC 1010 can send, for example, default profile information as additional information to the modem 1005. Meanwhile, in operation 1030, the configuration determination in the eUICC can include the following.

-when there is no indication whether an MEP is supported in the terminal capability or it is displayed as not supporting an MEP: as described above in fig. 9, the enabled profiles other than the default profile are processed to be disabled, and when the file system of the default profile is processed to be not displayed in operation 923 of fig. 9, the file system of the default profile is processed to be displayed in the default file system.

The eUICC 1010 can also process the configuration determination of the file system at the point in time when the eUICC 1010 receives a command APDU that is capable of determining operations starting with the MEP, rather than at the point in time when terminal capabilities are received.

In operation 1045, the modem 1005 may determine the operation as an MEP by predetermined information for determining eUICC function support and MEP support collected through ATR messages. During the initialization process between the UE and the eUICC 1010, at a particular point in time after the modem 1005 recognizes whether the eUICC 1010 supports MEPs, an operation determination of the modem 1005 in MEP mode may be performed, and when it is determined to operate in MEP mode, the modem 1005 may include identification information indicating the start of operation in MEP mode in a header of a command APDU, and may transmit the command APDU to the eUICC 1010 in operation 1050. The time point at which the operation in the MEP mode is determined and the time point at which the operation in the MEP mode is started may or may not be the same time.

Although the present disclosure has been described as an example of a command APDU having a management PORT (MANAGE PORT) as an INS, the present disclosure is not limited thereto, and it may also be determined as an APDU that can be recognized as logical interface management. An example of the transmission of the command APDU may include a CLA related to the management port and an INS indicating the management port initialization in a header of the command APDU. Alternatively, although not shown in fig. 10, the MEP mode start may be determined when the header of the command APDU includes CLA related to the management channel and INS indicating connection to the logical interface. The eUICC 1010, having received the identification information indicating to begin operation in MEP mode, can generate an eSIM port and return a response APDU to the modem 1005 for generating the eSIM port. The generated eSIM port can be generated in a way in which the eUICC (1010) maps an interface to the port that was used in a previous operation for communication between the eUICC 1010 and the modem 1005.

In this case, in operation 1028, during the selection of MF, the eUICC 1010 can maintain a display of only the file system that has been processed to be displayed to the modem 1005. As a value of the returned ATR, a part or all of the ATR message sent in operation 1015 may be returned in operation 1055. For ease of explanation, FIG. 10 illustrates the operation of selecting SELECT ISD-R after operation 1050, and illustrates the eUICC generating an ISD-R eSIM port as a result of operation 1050. However, depending on the configuration in the UE or eUICC, the ports originally generated between the UE and eUICC may not be limited to eSIM ports used by ISD-R. For example, the ISD-R does not use a port originally generated between the UE and the eUICC according to the configuration of the UE or the eUICC, and the UE can select and use another eSIM port as the port used by the ISD-R or the eUICC can select and use another eSIM port as the port used by the ISD-R.

After entering MEP mode, in operation 1060, the modem 1005 may generate an APDU transmission channel with ISD-R and select ISD-R such that in operation 1065, the modem 1005 may additionally receive ISD prioraryapplication template (presence and absence of enabled profile, maximum number of supported profile eSIM ports, profile-enabled eSIM port number(s), or additional profile-enabled eSIM port number(s) in addition to default profile, eSIM port number with default profile) from ISD-R and obtain the information required for port generation and allocation. Further, the eUICC 1010 can send an isdroprimaryapplication template that includes information regarding whether the eUICC is removable. Although the eSIM port number with the default profile enabled is designated as the information about the default profile in operation 1065, it is not limited thereto, and information about the default profile may be indicated and provided in one of the following methods:

-eSIM port number with default profile enabled;

ICCID of default profile

ICCID and mapped port number of default profile

PPR1 Profile ICCID

-eSIM port number enabling PPR1 profile;

default port number (only displayed when there is an enabled profile); and/or

-displaying eSIM port numbers in order, but indicating the default port first.

The modem 1005, having received the information on the default profile, can specify the number of eSIM ports to open and the eSIM port number by combining the information received with ISDR ProprietaryApplicationTemplate with the information obtained from the UE.

On the other hand, when the removable MEP-enabled eUICC 1010 does not support PPR1 or does not install a PPR1 profile, the default profile or the port number of the enabled default profile may not be sent from ISDR ProprietaryApplicationTemplate to the modem 1005. On the other hand, some or all of the presence or absence of the enabled profile obtained through ISDR ProprietaryApplicationTemplate, the maximum number of profile eSIM ports supported, the profile-enabled eSIM port number, the default profile-enabled eSIM port number, ISD-R selection methods, information about whether the eUICC is removable, may be returned by the ATR message (in operation 1020), the reply value of the terminal capability (in operation 1040), or the template of the MF file of the eUICC 1010 that is selected by default in the modem 1005 after receiving the ATR message.

In operation 1070, the modem 1005 can determine the number of profile eSIM ports as the smaller of the maximum number of available baseband and the maximum number of supported profile eSIM ports sent from the eUICC 1010 and can determine the number of ports to open with reference to the number of enabled eSIM ports. The maximum number of available baseband may be equal to or different than the number of baseband supported by modem 1005. For example, when the total number of baseband supported by modem 1005 is three, but one is occupied by a physical SIM card, the maximum number of available baseband may be two. In operation 1075, the modem 1005, having determined the number of profile eSIM ports and the port number to be opened, can send a port open command to the eUICC 1010 through the number of profile eSIM ports. Further, in the case where the modem 1005 determines a port number, when receiving port information mapped to a default port, the eSIM port can be opened by first allocating a corresponding port number. The eUICC 1010, having received information about eSIM ports opened by the modem 1005, can generate the eSIM ports and can process the file system of the profile to be visible when the profile is mapped to the eSIM ports and enabled.

If no profile maps to an eSIM port and is enabled, only the default file system may be visible when the eSIM port is selected. Further, after opening one basic channel to the eSIM port, the eUICC 1010 can return a response APDU to the modem 1005 to generate the eSIM port in operation 1080. When the default profile is not received or the port number of the default profile is enabled in operation 1065, the modem 1005 may generate ports without regard to the default profile, may map the profile in an enabled state to as many ports as the number of available ports (i.e., the number of open ports of the profile that is opened by the modem 1005) in the order of the lowest number of ports for which the profile is enabled in the eUICC 1010, and may determine to maintain other profiles enabled or disabled according to the configuration of the eUICC 1010.

As a reply value to the ATR returned in operation 1080, a portion or all of the ATR message sent in operation 1020 may be included and returned. For example, when the modem 1005 generates a port for allocation to a default profile in operation 1075 after generating an ISD-R eSIM port, the eUICC can process the file system of the default profile to make the modem 1005 visible while mapping the port to the default profile. Thereafter, when the modem generates an additional port and maps the additional port to an enabled profile in the eUICC 1010, the file system for the mapped enabled profile can be displayed to the modem 1005.

When the port numbers assigned to the profiles enabled in the eUICC 1010 are eSIM port #1, eSIM port #3, and eSIM port #5, respectively, and wherein the default port #3 is received as the default profile enabled port number, and there are two connectable baseband in the modem 1005, the modem 1005 can turn on up to 2 profile eSIM ports. In this case, the profile eSIM port on command sent from the modem 1005 to the eUICC 1010 can include port #3. For example, when the eSIM PORT number for which the default profile is enabled is #3, the modem 1005 may prioritize opening of the eSIM PORTs by designating the eSIM PORT number as #3, as in C-APDU < cla=man PORT, ins=open, pi=port #3>, and may allocate the eSIM PORTs in which the profile is enabled in the order of the next lower of the numbers provided by the eUICC 1010 that map with the eSIM PORTs.

For example, the following profile eSIM port opening command sent to the eUICC 1010 can include eSIM port #1 and can be sent. The eUICC 1010, having received the profile eSIM port open command, can map the default profile enabled in eSIM port #3 to the received eSIM port #3 and can map the profile enabled in eSIM port #1 to the received eSIM port #1. The modem 1005 can open as many ports as the number of previously determined profile eSIM ports, and when all eSIM port generation is completed in the modem 1005, the modem 1005 can send an indicator informing the eUICC 1010 that all eSIM port generation for operation as a MEP has been completed. For example, in operation 1085, the modem 1005 may send a management port (initialization complete) message to the eUICC 1010.

At the same time, the modem 1005 can notify the eUICC 1010 of the number of eSIM ports to generate at a particular point in time in the process described above, rather than notifying that all eSIM ports have been generated.

As described above in fig. 9, when the modem 1005 does not acquire the port number assigned to the default profile, the modem 1005 can determine the port number without consideration of the default profile port number and notify the eUICC 1010 of the determined port number. When the port number allocated in the first open management port command APDU is different from the port number of the default profile stored in the eUICC 1010, the eUICC 1010 can send a reply value to the modem 1005 that includes the port number of the stored default profile. Modem 1005 may change the open port number with the port number received in the reply value.

Alternatively, the eUICC 1010 can change an eSIM port number of a default profile stored by the eUICC 1010 to an eSIM port number received from the modem 1005, store the changed eSIM port number, and can connect the default profile to the changed eSIM port number.

Also as described above in fig. 9, when there is no configuration information for the default profile in the eUICC 1010, the eUICC 1010 maintains the enabled state of the profile(s) in the order of the lowest number in eSIM port numbers according to the ports allocated as available for the profile among the ports opened by the UE, and can determine that the profile that is maintained not mapped to the eSIM port is enabled or disabled. When a portion of the number of ports that can be allocated to the eUICC 1010 in the UE is not for use with the profile, the UE can notify the eUICC 1010 of the corresponding information. As an example, the UE may send a command APDU to the eUICC 1010 to obtain a configuration that includes information about the number of ports with the eUICC 1010 that can be opened by the UE and the number of openable ports for the profile in these ports as data for the command APDU.

When the eUICC 1010 receives an indicator (e.g., a management port (initialization complete) message) that informs the eUICC 1010 of the completion of the generation of all eSIM ports, the eUICC 1010 can disable a profile in port numbers mapped to its own enabled profile that does not allocate an eSIM port. For example, the profile assigned to port #5 may be changed to be in a disabled state by the eUICC 1010. Meanwhile, as described above, the modem 1005 can inform the eUICC 1010 of the number of eSIM ports to be generated at a particular point in time in the above-described process, rather than informing that all eSIM ports have been generated. In this case, when the number of eSIM ports is received by referring to information about the number of eSIM ports to be generated by the modem 1005, the eUICC 1010 can disable the profile that no eSIM ports are allocated.

When the eUICC 1010 implicitly processes the deactivation of the profile without user consent as an operation of the initialization process between the UE and the eUICC 1010, the eUICC 1010 can complete the deactivation process without sending a refresh command to the modem 1005 according to the profile state change. On the other hand, the modem 1005 may provide information such as eSIM ports, generated profile eSIM port numbers, default profile enabled port numbers, etc. to the UE framework 1001 by referring to the ISD-R finalized by the information obtained from the eUICC 1010 in operation 1090, so that the corresponding information may be utilized by an application (including LPA) or system of the UE.

Fig. 11A and 11B illustrate a method of handling exchanges of ports to be used between a UE operating in MEP mode and a profile in an eUICC, according to an embodiment of the present disclosure.

For descriptive convenience, it will be assumed that profile 1 is enabled in eSIM port #2 and profile 2 is enabled in eSIM port #1 as shown in fig. 5 above, and that profile 1 is a PPR1 configured profile. There may be situations where end user 1101 would like to change the baseband used by profile 1 and profile 2. That is, referring to FIG. 5, when profile 1 uses 5G and profile 2 uses 4G, end user 1101 may select a user menu for port change in LPA1105 or a SIM management application that is integrated with LPA1105 to use 4G for profile 1. In the prior art, when input is received from a user (e.g., clicking on a menu or changing the location between profiles in the UI), the eUICC 1115 can first disable the state of profile 1, but since the profile cannot be disabled, the eUICC 1115 returns an error to the LPA1105 that it cannot handle, and the LPA1105 cannot handle the corresponding command.

Referring to fig. 11A and 11B, in operation 1118, the end user 1101 may select a user menu for port change in the LPA1105 or the SIM management application in which the LPA1105 is integrated to use 4G for profile 1. The LPA1105 supporting the MEP that has received the corresponding message may generate a command for port-to-port exchange and send the generated command to the eUICC 1115. The command may be one of messages such as ES10c.SwapPort (ports #1, # 2) or ES10c.SwapPort (ICCID #1, # 2).

The order of entry in the switch port SwapPort () may indicate the order in which the processing ports change. For example, in the case of SwapPort (ports #1, # 2) of option 1 (1120), port #1 may be changed to port #2, and in the case of SwapPort (ICCID #1, # 2) of option 2 (1140), it may be appreciated that port #1 with ICCID #1 enabled may be changed to port #2 with ICCID #2 enabled first. In the above case, sequential processing means that the eUICC requests a refresh command (reset or profile state change) from the modem in the order of port #2 and then port #1, port #2 being the port to be changed and used by port #1 or ICCID # 1.

In option 1 (1120), in operation 1125, the eUICC 1115 can receive an esa10c.swapport (port #1, # 2). In operation 1130, the eUICC 1115 that has received the esalport (ports #1, # 2) can determine whether the requested ports #1 and #2 are both open and valid ports. As a result of the determination, when at least one of the ports is not open, the eUICC 1115 can return an error message to the LPA1105 in operation 1135. For example, in operation 1135, an error cause such as error noport, port# may be returned.

In option 2 (1140), the eUICC 1115 can receive an esa10c.swapport (ICCID #1, # 2) in operation 1145. In operation 1150, the eUICC 1115 that has received the esalport (ICCID #1, # 2) can determine whether all profiles corresponding to ICCIDs #1 and #2 are enabled. As a result of the determination, when one of the profiles corresponding to ICCIDs #1 and #2 is not enabled, the eUICC 1115 can return an error message to the LPA1105 in operation 1155. For example, in operation 1155, an error cause such as profileNotInEnabledState, ICCID may be returned. Upon receiving the error message, the LPA1105 may notify/end the processing method upon receiving the error.

Further, although not shown in fig. 11, by combining option 1 and option 2 with option 3, iccid#1 and Port #2 changed to be used by iccid#1 may be indicated in pairs as parameters of Swap Port () (e.g., swap Port (iccid#1, port # 2). In this case, it is determined whether iccid#1 is enabled, whether Port # to be changed is turned on, and whether another enabled ICCID other than iccid#1 exists.

As a result of the determination by operation 1130 of option 1 (1120) or operation 1150 of option 2 (1140) according to the received SwapPort command, when processing is possible, in operation 1160, the eUICC 1115 may indicate that port information may be changed in metadata from the profile of stored profile information (e.g., profile to be enabled on port #2 in metadata of profile 1 (ICCID # 1) or profile to be enabled on port #2 in metadata of profile 2 (ICCID # 2)), and in operations 1165 and 1170, refresh may be processed for eSIM ports included in SwapPort ().

In operation 1165, one or more refresh commands may be sent. That is, the proactive command for one refresh may include a plurality of port numbers, or a proactive command for refresh may be transmitted for each port.

In operation 1170, a reset may be performed for each destination port to be changed.

The refresh and reset may include at least one of the following methods.

For example, the eUICC 1115 can request a refresh from the modem 1110 that includes a port number to be changed by a sequential eSIM port in SwapPort (), or an ICCID-enabled eSIM port, and the modem 1110 can process the port refresh sequentially starting from the port number to be changed. In other words, when option 1 (1120) is SwapPort (port #1, # 2) in operation 1165, the eUICC 1115 can request the port refresh process from the modem 1110 by sending an active command including the port number to be changed via port #1, and can request the port refresh process from the modem 1110 by sending an active command including the port number to be changed via port #2, thereby requesting the refresh process for the port to be changed.

As an example, in the reverse order included in SwapPort (), the eUICC 1115 can sequentially request a refresh of the port reset from the modem 1110 through the eSIM port or the eSIM port with ICCID enabled, and the modem 1110 can process the port refresh according to the order of the eSIM ports to be changed. In other words, the eUICC 1115 can send refresh proactive commands corresponding to port resets in order of port #2 and port #1 without sending port numbers. The modem 1110 that has received the corresponding message performs a reset with the eUICC 1115 on the port.

For example, through one of the eSIM ports used by ISD-R or a dedicated port, the eUICC 1115 can send a request to the modem 1110 to begin executing refresh proactive commands for the entire eUICC platform. The modem 1110 that has received the request can perform a reset on the entire eUICC.

For example, as described above, through a port used by one ISD-R, the eUICC 1115 sends two independent proactive commands to the modem 1110 that include the port number to be changed and used by the profile to request a port refresh process.

For example, through a port used by an ISD-R as described above, the eUICC 1115 sends an proactive command to the modem 1110 that includes the port number to be changed and used by the profile to request the port refresh process.

Further, although not shown in fig. 11, as another example of the alternative operations 1165 and 1170, the eUICC 1115 can send a refresh active command for the exchange via one of the eSIM ports used by ISD-R, the command including a list (of existing port numbers and changed port numbers) to request a port refresh from the modem 1110.

Modem 1110 that has received the proactive command(s) may perform a refresh command on the port(s) or the entire platform. Upon receiving an proactive command including a plurality of port numbers, the modem 1110 may perform a bulk network release procedure on the received ports instead of deleting the cache values after a network detach request for each port, and may begin a new eUICC session by a reset for each port after bulk deleting the cache values of the ports. When the modem 1110 receives a plurality of refresh commands for port reset with one port number or without a port number, the modem 1110 may sequentially perform refresh processing for each port. That is, modem 1110 may release the network connection for each port's profile and may delete the cache value and perform a reset for each port.

When a reset is performed on the port(s) or platform as a result of the refresh process, the eUICC 115 can change the profile and mapping of the port in operation 1175 and can return the conventional response results to the processing of the port change to the LPA1105 in operation 1180.

In operation 1185, LPA1105 having received the response may recognize that the profile-port mapping change has completed normally and may provide the processing results to end user 1101. In lieu of operation 1180, after the reset is complete, the LPA1105 can determine whether the port-profile mapping of the eUICC 1115 has been completed normally by the information of the profile returned by the GetProfileInfo () command in the eUICC 1115 and the template that was invoked when ISD-R was selected.

Meanwhile, in operation 1195, there may be a case where a refresh command cannot be transmitted from the ISD-R port to the modem 1110. In this case, in operation 1196, the eUICC 1115 can change the port number of the enabled profile to the port number to be changed and enabled and can store the corresponding results.

Thereafter, the euicc 1115 can return a success response message to the LPA1105 including the changed port number to be used by each profile, at operation 1197, or after adding the changed port number to the success response message, the LPA1105 can send the corresponding result to the modem 1105, at operation 1198. At operation 1198, modem 1110, having received the corresponding results, performs a bulk network release procedure for the networks used by each existing profile and may delete the cache value of the changed port to perform a reset on the changed port. After performing the reset, modem 1110 may perform a network attachment procedure by using profile information enabled on the changed port in the baseband connected to the changed port.

Fig. 12 schematically illustrates an internal structure of a UE in a wireless communication system according to an embodiment of the present disclosure.

Referring to fig. 12, the ue 1200 includes a transceiver 1210, a message processor 1220, a controller 1230, a memory 1240, and a screen display unit 1250. However, the components of the UE 1200 are not limited to the above examples. For example, a base station may include more or fewer components than those described above. Furthermore, at least one component of the UE 1200 may be implemented in the form of one chip. According to some embodiments, the transceiver 1210 may perform functions for transmitting and receiving signals over a wireless channel, such as frequency band conversion and amplification of signals. That is, the transceiver 1210 may include an RF processor that up-converts a baseband signal into an RF band signal, transmits the up-converted signal through an antenna, and down-converts the RF band signal received through the antenna into a baseband signal, and may further include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital-to-analog converter (DAC), an analog-to-digital converter (ADC), and the like.

In addition, the transceiver 1210 may receive a signal through a wireless channel, output the received signal to the processor 1230, and transmit the signal output from the controller 1230 through the wireless channel. The transceiver 1210 may perform beamforming. For beamforming, the transceiver 1210 may adjust the phase and amplitude of each signal transmitted and received through multiple antennas or antenna elements. In addition, a baseband processor in the transceiver 1210 may perform a conversion function between baseband signals and a bit stream according to a physical layer standard of a system. For example, in data transmission, the baseband processor generates complex symbols by encoding and modulating a transmitted bit stream. Further, upon data reception, the baseband processor restores the received bit stream by demodulating and decoding the baseband signal supplied from the RF processor. For example, in the case of Orthogonal Frequency Division Multiplexing (OFDM), when transmitting data, a baseband processor may generate complex symbols by encoding and modulating a transmission bit stream, and after mapping the complex symbols to subcarriers, may configure OFDM symbols by an Inverse Fast Fourier Transform (IFFT) operation and Cyclic Prefix (CP) insertion.

Further, at the time of data reception, the baseband processor may divide a baseband signal provided from the RF processor into OFDM symbol units, recover a signal mapped to subcarriers through a Fast Fourier Transform (FFT) operation, and recover a received bit stream through demodulation and decoding.

The transceiver 1210 may be defined as a transceiver and may include a messaging transceiver. The message processor 1220 may perform an operation of transmitting data through the transceiver 1210 or an operation of determining which message the data transmitted or received through the transceiver 1210 is. For example, the message processor 1220 may determine whether the received message is a control message (including a System Information Block (SIB)) of a Radio Resource Control (RRC) layer or a user data message. The message processor 1220 may be included in the controller 1230.

A controller 1230 controls the overall operation of the UE 1200. For example, the controller 1230 transmits and receives signals through the message processor 1220. In addition, the controller 1230 writes and reads data in the memory 1240. There may be at least one controller 1230. For example, the controller 1230 may include a Communication Processor (CP) controlling communication and an Application Processor (AP) controlling an upper layer such as an application. According to some embodiments, when operator configuration information for device change is stored in the memory 1240 in advance, the controller 1230 may request corresponding information from the memory 1240 and may display the requested information through the screen display unit 850 or may receive the information to perform additional operations.

Controller 1230, message processor 1220, and transceiver 1210 may control UE 1200 to access the network of the selected operator according to a user or UE configuration. Further, according to some embodiments, the controller 1230 may match the data records read through the memory 1240 or the information collected through the controller 1230, the message processor 1220 and the transceiver 1210 to perform a process in which the UE infers information that may be referenced for service selection. According to some embodiments, the controller 1230 may determine whether specific information stored in the UE 1200 requires user consent and display the corresponding information on the screen display unit 1250.

Further, the controller 1230 may control the UE 1200 to perform operations corresponding thereto. According to some embodiments, the controller 1230 may include an LPA responsible for driving and controlling the eUICC, as well as an application that integrates the LPA. Further, according to some embodiments, the controller 1230 may include a UE framework that processes specific command APDU requests to a Communication Processor (CP) by interpreting information received at the LPA or application, or gathers some or all of the requested information from the memory 1240 to return the gathered information to the LPA or application.

The controller 1230 may determine to operate in the MEP mode by synthesizing predetermined information obtained from the eUICC 1260 through the UE 1200 and transceiver 1210, and may return corresponding information to the eUICC 1260. The eUICC 1260 is controlled by the controller 1230, and according to embodiments of the disclosure, the eUICC 1260 can execute each management command and send proactive commands to a modem or the like.

The memory 1240 stores data, such as basic programs, applications, and configuration information, for the operation of the UE 1200. In an embodiment, the memory 1240 is composed of a storage medium such as a ROM, a RAM, a hard disk, a CD-ROM, and a DVD, or a combination of storage media, and may provide data stored as terminal capabilities according to a request of the controller 1230. In addition, the memory 1240 may be integrated and implemented with the controller 1230 and a system-on-chip (SoC).

Meanwhile, in embodiments of the present disclosure, the eUICC 1260 may exist in a removable manner as a separate module external to the UE 1200 and may be inserted into the UE 1200. The eUICC 1260 can also be configured to include some or all of the other parts of the module of the UE 1200 in which it is located, except for the screen display unit 1250. For example, according to embodiments of the present disclosure, the controller of the eUICC 1260 can process and obtain terminal capability information of the UE 1200 received through the message transceiver, and can then obtain/combine the following information through the corresponding message information: information regarding whether there is an enabled profile with respect to status information of the profile stored in memory and information regarding a profile configured as a default profile when the corresponding UE is a non-eSIM or an eSIM UE that does not support MEP, thereby changing and processing the status of the profile in the eUICC 1260. Meanwhile, it should be noted that the UE 1200 may include UICC, eUICC, iSSP and the uicc as built-in hardware security modules.

The screen display unit 1250 may display information processed/handled by the controller 1230, or display the progress of an operation performed by the UE 1200 through the processing of the controller 1230, or agree with an event or the like requested to be performed from the user. According to some embodiments, stored profile information, default profile configuration menus, default profile inputs, and input results may be returned to the user and displayed. According to some embodiments, the LPA or an application integrating and implementing the LPA may include a screen display unit 1250 and a controller 1230.

Fig. 13 illustrates a method of handling changes between ports to be used by a profile in a UE and eUICC operating in MEP mode according to another embodiment of the disclosure. Specifically, fig. 13 describes a method of transmitting a command (esa10c.enableprofile) for enabling a profile including an exchange indicator.

In fig. 4, a procedure of the profile activation process for a specific port in the MEP is described, and in fig. 13, the exchange indicator will be mainly described.

Referring to fig. 13, when an esa 10.Enableprofile command including an exchange indicator is transmitted in operation 1330, the eUICC 1310 may not return an error even when a target profile (profile with ICCID of the esa 10.Enableprofile command) is enabled, and further, in operation 1335, it may be determined whether another profile is enabled in a target port number to enable the target profile. At this point, when both are enabled, the eUICC 1310 can perform a subsequent process for changing ports, otherwise the eUICC 1310 can return an error to the LPA 1305 and terminate the process.

When the eUICC 1310 determines that the port of the profile can be changed as a result of the determination of operation 1335, the eUICC 1310 marks the port number to be changed and used by the profile on the information of the profile to change the port before requesting a refresh command from the modem 1315 in operation 1345.

When the refreshFlag is configured in the ES10c.EnableProfile in operation 1340, the eUICC 1310 can send a refresh active command to the port to be changed to the modem 1315 in operation 1345. As described above in fig. 11, the refresh active command may be sent one by one for each port to which the application changes, or two active commands may be sent sequentially through one of the target ports or ISD-R dedicated ports. Alternatively, one proactive command may be sent while including a plurality of port numbers. In fig. 13, as an example, a case where one proactive command is transmitted through an ISD-R dedicated port while including a plurality of port numbers is shown.

Upon receiving an proactive command including a plurality of port numbers (2 port numbers due to port changes), the modem 1315 may perform a bulk network connection procedure for the network in which the received port numbers are mapped and used, and may start a new eUICC session by resetting for each port after bulk deleting the cache value of the port in operation 1350. When performing the reset, the eUICC 1310 can map the profile to the marked new port to complete the eUICC initialization process in operation 1355.

When the refreshFlag is not configured in operation 1360, the eUICC 1310 can change the port mapping of the profile to a port number to be enabled as described above in operation 1365. Next, at operation 1370, the euicc 1310 can return a success response message to the LPA1305 that includes the port number to be changed by each profile. Alternatively, the LPA1305 may add the port number to be changed to the success response message and then may send a success response to the modem 1315. In operation 1375, the modem 1315 having received a successful response including the port number to be changed may perform a bulk network release procedure for the network used by each existing profile, delete the cache value of the changed port, and process the reset of the changed port. After performing the reset, the modem 1315 may perform a network connection procedure in a baseband connected to the changed port by using profile information enabled for the changed port in operation 1380.

As described above, when an eUICC supporting an MEP has been inserted into a first UE and operated in MEP mode before being inserted into a second UE, there may be two or more profiles in the eUICC inserted into the second UE and a state in which both or more profiles are enabled may be obtained.

As described above in operation 830 of fig. 8 and fig. 9, when the eUICC has received information about eUICC-related capabilities as information about the terminal capabilities of the UE, but has not received information about MEP support of the UE as information about the terminal capabilities or information received from the UE through a separate APDU, the eUICC maintains only a default profile of baseband connection in an enabled state and implicitly disables the other enabled profile(s).

However, with respect to configuration of the eUICC supporting the MEP, all states of the profile in the eUICC can be maintained and handled in an enabled state. For example, when profile a, profile B, and profile C exist as three profiles in an eUICC inserted into a second UE and all three profiles are enabled, the eUICC can maintain state information of remaining profiles (e.g., profile B, profile C) in an enabled state without any change of state of the remaining profiles to disabled, even if only the profile (e.g., profile a) configured as a default profile in the eUICC is processed during the UE-eUICC initialization process. In this case, the eUICC maintains the state of profile B and profile C in an enabled state, but is unable to access the network because there is no baseband connection. Thus, the eUICC can process profile B and profile C as disabled states defined in GSMA sgp.22. In the present disclosure, for convenience of description, this state may be described as a "temporary enabled state".

As described above, in the enabled state, but in a state in which no channel is provided from the modem for the baseband connection, initialization of the profile in the eUICC can be accomplished in SEP mode. As described above, for a profile in a state in which the profile is enabled but the baseband connection is not present, the eUICC can tag the identification information of the "temporary enabled state" in the state information of the profile and store the corresponding results. The corresponding point in time at which the eUICC can tag the status information of the profile with the identification information of the "temporary enabled status" and store the corresponding results can be a specific point in time for initialization between the UE and the eUICC.

As a method of marking and storing the identification information, a method of indicating the temporary enable state as a new state value by the eUICC or a method of using a separate identifier indicating the temporary enable state by the eUICC is also possible. For example, temporaryEnabled (2) may be added as one of the profileTate values included in ProfileInfo (profileTate: = inter { disable (0), enable (1), temporaryEnabled (2)), or an identifier such as a temporaryEnabled flag may be added as additional data to ProfileInfo.

In fig. 14 to 16, a profile in the "temporary enabled state" is referred to as profile 1A, which is not connected to the baseband, even though the state of the profile is maintained in the enabled state during the initialization process. Further, unless otherwise indicated, LPAs in fig. 14 to 16 refer to LPAs that do not support MEPs, and modems refer to modems that do not support MEPs.

Fig. 14 illustrates a method of returning profile state information when a removable MEP-enabled eUICC is inserted into an eSIM UE that does not support MEPs, according to an embodiment of the present disclosure.

As described above, in the enabled state, but in a state in which no channel is provided from the modem for the baseband connection, initialization of the profile in the eUICC can be accomplished in SEP mode. As described above, for a profile that is in the state of an enabled profile but in a state in which there is no baseband connection, the eUICC can tag, store, and use state information for the corresponding profile.

Referring to fig. 14, in option 1 (1401), in 1415, the non-MEP LPA 1405 in SEP mode may request ES10c.getprofileinfo () from the MEP-enabled eUICC 1410 to obtain profile information. In operation 1420, the eUICC 1410, having received a request for profile information from the LPA 1405, can return status information of the profile as profile information to the LPA 1405.

When two profiles (e.g., profile 1A and profile 2) are present in the eUICC, the eUICC 1410 can identify whether identification information indicating that the states of profile 1A and profile 2 are temporarily enabled is tagged.

Among the values included in ProfileInfo of Profile 1A, for example:

Profilestate=temporaryEnable (2) or

2. Profilesate = enabled (1) and temporaryEnabled flags are configured.

When the information regarding the temporary enabled state is marked as shown above, the eUICC 1410 returns the corresponding information to the LPA1405 as it does when operating in MEP mode, and when not operating in MEP mode, both cases 1 and 2 above can be changed to profilesate=disabled (0) to return to the LPA1405. For example, the eUICC 1410 can flag the corresponding information as profile 1A state = disabled, profile 2 state = enabled, and the tagged information can be returned to the LPA1405. The LPA1405 can tag the profile list and status information to the user by referencing predetermined information, such as profile information obtained from the eUICC 1410 through the esa.getprofileinfo (), and radio access information received from the UE.

With continued reference to fig. 14, in option 2 (1402), when the eUICC 1410 receives an esa 10 c.getprofileinffor () from the LPA1405 in operation 1425, the status information of the profile may be included as profile information in operation 1430 and may be returned to the LPA1405.

In this case, when two profiles (e.g., profile 1A and profile 2) are present in the eUICC 1410, the eUICC 1410 can identify whether an identification indicating that the states of profile 1A and profile 2 are in a temporary enabled state is marked.

Among the values included in ProfileInfo of Profile 1A, for example:

Profilestate=temporaryEnable (2) or

2.ProfileState＝enabled(1)the temporaryEnabled flag is configured.

When the identification information regarding the temporary enabled state is marked as shown above, the eUICC 1410 returns the corresponding information to the LPA 1405 as it does when operating in MEP mode, and when not operating in MEP mode, both cases 1 and 2 above can be changed to profilesate=enabled (1) to return to the LPA 1405. For example, the eUICC 1410 can flag the corresponding information as profile 1A state = enabled, profile 2 state = enabled, and the tagged information can be returned to the LPA 1405. In operation 1435, the lpa 1405 may display the profile list and status information to the user by referencing predetermined information (such as profile information obtained from the eUICC 1410 through the ES10c.getprofileinfo (), and radio access information received from the UE). On the other hand, in the case of LPA that does not support MEPs, LPA 1405 may be implemented such that only one value is possible for which the profile state is returned as "enabled".

In this case, when there are two or more "enabled", the LPA that does not support the MEP may recognize it as an error, and predetermined information obtained from the UE, for example, baseband or IMEI information allocated for each profile, may be combined to configure and display the combined information to the user, so that the user may refer to the corresponding information to determine the deactivation process of one profile. Upon receiving user input, the LPA 1405 can send the esa 10c.disable profile to the eUICC 1410 to handle explicit deactivation of one profile. This will be further described in the example of fig. 16 below.

Fig. 15 illustrates a method of handling activation of a profile in a temporary enabled state when a removable MEP-enabled UICC is inserted into an eSIM UE that does not support MEPs, according to an embodiment of the present disclosure.

As in the embodiment of fig. 14, LPA 1505 may collect profile information and display the collected information to end user 1501, and end user 1501 may identify and change the status of a particular profile by the displayed profile information.

Referring to fig. 15, end user 1501 may perform input to LPA 1505 to receive web services via profile 1A at a particular time, instead of profile 2, with reference to the tagged profile list and profile state information. As an example, in operation 1520, the end user 1510 may select profile 1A for the communication service in LPA 1505. Through user input, the LPA 1505 can send a profile activation request command to the eUICC 1510. For example, in operation 1525, the LPA 1505 may send an esa.enableprofile command to the eUICC 1510 that includes the ICCID of profile 1A.

Upon receiving the esa 10c.enableprofile including the ICCID from the LPA 1505, the euicc 1510 can determine whether identification information regarding the temporary enablement status additionally exists in verifying whether a profile activation process is possible in operation 1530.

When the identification information of the temporary enabled state does not exist, the MEP-enabled eUICC 1510 can return an error code to the LPA 1505 as a processing result at operation 1535. The error code may be one of profileNotInDisabledState, disallowedByPolicy or undofinederror.

When the identification information indicating that the profile is temporarily activated is marked in the profile information stored and managed by the eUICC 1510, the eUICC 1510 does not return an error code, but the corresponding information can be identified as a profile activation procedure defined in GSMA sgp.22, then profile 2 can be implicitly disabled, and profile 1A can be treated as being in an enabled state at operation 1535. As an example, profile 1A may be processed as in the profile activation procedure defined in GSMA sgp.22 above, and when the refresh flag is configured, for example, the following procedure may be included for processing.

Step 1. In the eUICC 1510, the status of profile 1A can be marked as "to enable" status and the status of profile 2 can be marked as "to disable" status.

Step 2. A refresh active command < mode=profile state change or eUICC memory reset > can be sent from the eUICC 1510 to the modem 1515.

Step 3. After deleting the cached information regarding profile 2 and performing the network detach procedure, the modem 1515 can request a terminal response or reset from the eUICC 1510.

Step 4. When the modem-eUICC is initialized, the eUICC 1510 can perform a state change process from "temporary enabled state" to enabled state for profile 1A, and a state change process to disabled state for profile 2.

Referring to fig. 16, as in the embodiment of fig. 14, in operation 1620, the LPA 1605, which does not support MEPs, may display information for managing profiles by the end user 1601 on the user screen with reference to the information of the profile received from the eUICC 1610 and additionally the information collected from the UE. In the case where the MEP-enabled eUICC 1610 receives GetProfileInfo () from the LPA 1605, the LPA 1605 may receive the status of two or more profiles configured in the enabled state when the MEP-enabled eUICC 1610 returns the profile in the temporarily enabled state to profile 1A state = enabled. In this case, the LPA 1605 can process the profile information of the end user 1601 in the following way, as it may cause interference to the end user 1601 as if two baseband were available.

In one embodiment, a method wherein an error occurs when the status of two or more profiles is received in an enabled state and a screen is displayed requesting deactivation of one profile from end user 1601 to request a change of the status of one profile to a disabled state by the end user.

In one embodiment, a method is provided: when it is determined that the corresponding profile is a profile of an unassigned baseband by predetermined information received from the UE (i.e., information indicating whether the corresponding profile is connected to the radio access network when the status of the received profile is indicated as two enabled statuses), the end user is notified that only one profile is available for network use by indicating additional information indicating that the profile is not connected to the network.

When the end user 1601 selects the profile 1A at a specific point in time and wants to put the selected profile 1A in a network available state for a communication service, processing is performed according to the procedure of the embodiment of fig. 15.

Referring to fig. 16, in option 1 (1625), at a particular point in time, in operation 1630, the end user 1601 may select profile 1A to change a profile state to an enabled state. For example, when LPA1605 detects activation of two or more profiles and requests deactivation of one of the two enabled profiles from end user 1601 in operation 1620, end user 1601 may select profile 1A. In operation 1635, when input from the end user 1601 is received, the LPA1605 can request a status change of profile 1A from the eUICC 1610 by sending an e 10c.disable profile command including the ICCID of profile 1A to the eUICC 1610 according to the procedure defined in sgp.22 for changing profile status. The ISD-R (not shown) of the eUICC 1610 that has received the esa.disable profile may change the state of profile 1A to a disabled state and may return the result of the deactivation change process to the LPA 1605. At this point, since profile 1A was not previously connected to the network, in operation 1640, the eUICC 1610 can omit the refresh processing request to the modem 1615 that does not support MEPs directly (or through LPA 1605) according to the state change.

With continued reference to fig. 16, in option 2 (1645), in operation 1650, the end user 1601 may select profile 2 at a particular point in time to change the profile state to a disabled state. For example, when LPA 1605 detects activation of two or more profiles and requests deactivation of one of the two activated profiles from end user 1601 in operation 1620, end user 1601 may select profile 2. At this point, in operation 1650, the end user 1601 may disable only profile 2, or may provide the LPA 1605 with user consent to activate process profile 1A and disable profile 2 so that the LPA 1605 may determine whether to additionally process activation of profile 1A and perform the process.

When the end user 1601 determines that only profile 2 is disabled, the LPA 1605 may request a state change by sending an e 10c.disable profile command including the ICCID of profile 2 to the eUICC 1610 according to the procedure for changing profile states defined in sgp.22 in operation 1655. The ISD-R (not shown) of the eUICC 1610, which has received the esa.disable profile command, may change the state of profile 2 to a disabled state and may return a processing result according to the state change to the LPA 1605. At this point, since profile 2 was not previously connected to the network, at operation 1660, the euicc 1610 can perform a refresh processing request to the modem 1615 directly (or through LPA 1605) according to the state change.

When the end user 1601 determines to enable profile 1A and disable profile 2, the LPA 1605 may perform operations 1655 and 1660 and, in operation 1665, additionally send an es10c.enableprofile command to the eUICC 1610 including the ICCID of profile 1A to request a state change of profile 1A. In operation 1670, the eUICC 1610, having received the es10c.enableprofile command including the ICCID of profile 1A, can identify whether to process the identification information regarding the temporary enablement status as in operations 1525 through 1535 of the embodiment of fig. 5. On the other hand, not limited to the non-MEP UE, when the MEP-enabled eUICC 1610 is inserted into the UE operating in the MEP mode, in case of completing eUICC initialization by maintaining an enabled state without changing a profile to a disabled state according to a configuration of the eUICC 1610, when a profile activation process is requested from the LPA supporting the MEP after being marked as a temporary enabled state, identification information on the temporary enabled state may be identified to determine whether to enable the profile or return an error.

It should be understood that the various embodiments of the disclosure and the terminology used therein are not intended to limit the technical features set forth herein to the particular embodiments, but rather include various changes, equivalents, or alternatives to the corresponding embodiments. With respect to the description of the drawings, like reference numerals may be used to identify like or related elements. It is to be understood that the singular form of a noun corresponding to an item may include one or more items unless the relevant context clearly dictates otherwise. As used herein, each of the phrases such as "a or B", "at least one of a and B", "at least one of a or B", "at least one of A, B or C", "at least one of A, B and C", and "at least one of A, B or C" may include all possible combinations of items listed together in a corresponding one of the phrases. As used herein, terms such as "first," "second," "first," and "second" may be used to simply distinguish one corresponding element from another element and not to limit the elements in other respects (e.g., importance or order). It will be understood that if an element (e.g., a first element) is referred to as being "coupled" to, "connected" to … … or "connected" to another element (e.g., a second element), whether or not the term "operatively" or "communicatively" is used, it is intended that the element can be directly (e.g., wired), wirelessly, or coupled/connected to the other element via a third element.

As used herein, the term "module" may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with other terms, e.g., "logic," "logic block," "component," or "circuit," "module" may be the smallest unit of a single integrated component adapted to perform one or more functions, or be part thereof. For example, according to one embodiment, a "module" may be implemented in the form of an Application Specific Integrated Circuit (ASIC).

The various embodiments set forth herein may be implemented as software (e.g., a program) comprising one or more instructions stored on a storage medium (e.g., internal memory or external memory) readable by a machine (e.g., an electronic device). For example, a processor of a machine (e.g., an electronic device) may invoke at least one of one or more instructions stored in a storage medium and execute it. This allows the machine to be operated to perform at least one function in accordance with the at least one instruction invoked. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Wherein the term "non-transitory" merely means that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves), but the term does not distinguish between locations where data is semi-permanently stored in the storage medium and locations where data is temporarily stored in the storage medium.

According to an embodiment, a method according to various embodiments of the present disclosure may be included in a computer program product and provided therein. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium, such as a compact disc read only memory (CD-ROM), or distributed online (e.g., downloaded or uploaded) via an application store, such as a playstore (tm), or distributed directly between two user devices, such as smart phones. If distributed online, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as a memory of a manufacturer's server, a server of an application store, or a relay server.

According to various embodiments, each of the elements (e.g., modules or programs) described above may include a single entity or multiple entities. According to various embodiments, one or more of the above elements may be omitted, or one or more other elements may be added. Alternatively or additionally, multiple elements (e.g., modules or programs) may be integrated into a single element. In this case, according to various embodiments, the integrated element may still perform one or more functions of each of the plurality of elements in the same or similar manner as performed by a corresponding one of the plurality of elements prior to integration. According to various embodiments, operations performed by a module, a program, or another element may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations may be performed in a different order or omitted, or one or more other operations may be added.

In the above detailed embodiments of the present disclosure, elements included in the present disclosure are expressed in singular or plural numbers according to the detailed embodiments given. However, for convenience of description, the singular or plural forms are appropriately selected as the presented case, and the present disclosure is not limited to the elements expressed in the singular or plural. Accordingly, an element expressed in a plurality of numbers may include a single element, or an element expressed in a singular may include a plurality of elements.

While the present disclosure has been described with various embodiments, various changes and modifications may be suggested to one skilled in the art. The present disclosure is intended to embrace such alterations and modifications that fall within the scope of the appended claims.

Claims

1. A method of a User Equipment (UE), the method comprising:

performing an activation and a cold reset to configure an operating environment for operation with a removable embedded universal integrated circuit card (eUICC) that supports a plurality of enabled profile (MEP) modes;

in response to performing the activating and cold resetting, receiving a reset Answer (ATR) message from the eUICC, the reset answer message including information indicating whether the eUICC supports at least one eUICC function;

determining a transport protocol to be used between the UE and the eUICC based on the received ATR message;

Transmitting an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities to the eUICC over a transport protocol to be used between the UE and the eUICC;

receiving a response message including a response code from the eUICC in response to sending the APDU message;

determining to operate in a non-MEP mode;

when an initialization operation between a general eUICC and a UE that do not support the MEP mode is performed, transmitting a command APDU message for channel opening to the eUICC;

in response to sending the command APDU message, receiving a regular response message from the eUICC to generate a basic channel for APDU transmission between the UE and the eUICC; and

an initialization operation is performed between the eUICC and the UE.

2. The method of claim 1, wherein the ATR message further comprises information about a transport protocol supported by the eUICC and information indicating whether the transport protocol supported by the eUICC is changeable.

3. The method of claim 1, wherein the eUICC-related capability includes information whether the UE supports MEP mode.

4. The method of claim 1, further comprising:

after receiving the ATR message, a Master File (MF) of the eUICC is selected.

5. The method of claim 2, wherein determining a transport protocol to be used between the UE and the eUICC comprises:

Determining whether a transport protocol supported by the eUICC is changeable based on the ATR message;

determining a transport protocol to be used between the UE and the eUICC as the transport protocol supported by the eUICC based on a determination that the transport protocol supported by the eUICC is immutable; and

based on a determination that the transport protocol supported by the eUICC is changeable, a request is sent to the eUICC to determine the transport protocol to use between the UE and the eUICC.

6. The method of claim 1, wherein performing initialization between the eUICC and the UE comprises:

transmitting a selection command to the eUICC, the selection command comprising an identifier of an issuer security domain root (ISD-R) of the UE; and

a response is received from the eUICC, the response including information indicating whether at least one enabled profile corresponding to ISD-R is in the eUICC.

7. A method of a removable embedded universal integrated circuit card (eUICC) that supports Multiple Enabled Profile (MEP) modes, the method comprising:

transmitting, to a User Equipment (UE), a reset Answer (ATR) message for activation and cold reset of the UE, the ATR message including information indicating whether the eUICC supports at least one eUICC function;

receiving an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities from the UE through a transport protocol to be used between the UE and the eUICC determined based on the ATR message;

In response to receiving the APDU message, transmitting a response message including a response code to the UE;

determining whether the UE supports eUICC-related capabilities based on the APDU message;

determining that the UE is operating in a non-MEP mode based on a determination that the UE does not support eUICC related capabilities;

determining, based on a determination that the UE supports eUICC-related capabilities, whether the eUICC receives a command APDU message for channel opening from the UE when performing an initialization operation between a general eUICC that does not support an MEP mode and the UE;

when the eUICC receives the command APDU message from the UE, determining that the UE is operating in a non-MEP mode, and in response to receiving the command APDU message, sending a regular response message to the UE to generate a basic channel for APDU transmission between the UE and the eUICC; and

an initialization operation is performed between the eUICC and the UE.

8. The method of claim 7, wherein the ATR message further comprises information about a transport protocol supported by the eUICC and information indicating whether the transport protocol supported by the eUICC is changeable.

9. The method of claim 7, wherein the eUICC-related capability includes information whether the UE supports MEP mode.

10. The method of claim 7, wherein determining that the UE is operating in a non-MEP mode comprises:

Determining whether one or more profiles in the eUICC are in an enabled state;

maintaining a state of one of the profiles in an enabled state based on a determination that the one of the profiles is in the enabled state;

identifying, based on the determination that the two or more profiles are in an enabled state, whether a profile configured as a default profile exists in the two or more profiles based on the stored profile information; and

the state of the default profile is maintained in an enabled state and the state of the remaining profiles is changed to a disabled state.

11. The method of claim 10, wherein performing initialization between the eUICC and the UE comprises:

receiving a selection command from a UE, the selection command including an identifier of an issuer security domain root (ISD-R) of the UE; and

a response is sent to the UE, the response including information indicating whether at least one enabled profile corresponding to the ISD-R is in the eUICC.

12. A User Equipment (UE), the UE comprising:

a transceiver; and

a controller operably coupled to the transceiver, the controller configured to:

performing an activation and a cold reset to configure an operating environment for operation with a removable embedded universal integrated circuit card (eUICC) that supports Multiple Enabled Profile (MEP) modes,

In response to performing the activating and cold resetting, receiving an Answer To Reset (ATR) message from the eUICC, the ATR message including information indicating whether the eUICC supports at least one eUICC function,

a transport protocol to be used between the UE and the eUICC is determined based on the received ATR message,

an Application Protocol Data Unit (APDU) message including information indicating whether the UE supports eUICC-related capabilities is sent to the eUICC via a transport protocol to be used between the UE and the eUICC,

in response to sending the APDU message, receiving a response message including a response code from the eUICC,

it is determined to operate in a non-MEP mode,

when an initialization operation between a general eUICC, which does not support the MEP mode, and a UE is performed, a command APDU message for channel opening is transmitted to the eUICC,

receiving a regular response message from the eUICC in response to sending the command APDU message to generate a basic channel for APDU transmission between the UE and the eUICC, and

an initialization operation is performed between the eUICC and the UE.

13. The UE of claim 12, wherein the controller is configured to perform the method of any of claims 2-6.

14. A removable embedded universal integrated circuit card (eUICC) supporting a plurality of enabled profile (MEP) modes, configured to perform the method of any one of claims 7-11.