WO2021242071A1 - 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치 - Google Patents

이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치 Download PDF

Info

Publication number
WO2021242071A1
WO2021242071A1 PCT/KR2021/006757 KR2021006757W WO2021242071A1 WO 2021242071 A1 WO2021242071 A1 WO 2021242071A1 KR 2021006757 W KR2021006757 W KR 2021006757W WO 2021242071 A1 WO2021242071 A1 WO 2021242071A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
authentication
information
profile
server
Prior art date
Application number
PCT/KR2021/006757
Other languages
English (en)
French (fr)
Inventor
강수정
이덕기
이혜원
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020200103768A external-priority patent/KR20210147822A/ko
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to CN202180039118.3A priority Critical patent/CN115699837A/zh
Priority to US17/999,759 priority patent/US20230209340A1/en
Priority to EP21814202.4A priority patent/EP4142319A4/en
Publication of WO2021242071A1 publication Critical patent/WO2021242071A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/43—Security arrangements using identity modules using shared identity modules, e.g. SIM sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/42—Security arrangements using identity modules using virtual identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data

Definitions

  • the present invention relates to a method and apparatus for re-installing connection information for accessing a communication system installed in one device to another device in a wireless communication system.
  • the 5G communication system or the pre-5G communication system is called a system after a 4G network (Beyond 4G Network) communication system or a Long Term Evolution (LTE) system after (Post LTE).
  • the 5G communication system is being considered for implementation in a very high frequency (mmWave) band (eg, such as a 60 gigabyte (60 GHz) band).
  • mmWave very high frequency
  • FQAM Hybrid FSK and QAM Modulation
  • SWSC Small Cell Superposition Coding
  • ACM Advanced Coding Modulation
  • FBMC Fan Bank Multi Carrier
  • NOMA Non orthogonal multiple access
  • SCMA sparse code multiple access
  • IoT Internet of Things
  • IoE Internet of Everything
  • M2M Machine Type Communication
  • MTC Machine Type Communication
  • IoT an intelligent IT (Internet Technology) service that collects and analyzes data generated from connected objects and creates new values in human life can be provided.
  • IoT is a field of smart home, smart building, smart city, smart car or connected car, smart grid, health care, smart home appliance, advanced medical service, etc. can be applied to
  • 4G and 5G communication technologies such as sensor network, machine to machine (M2M), and MTC (Machine Type Communication) are developed by techniques such as beam forming, MIMO, and array antenna. it is being implemented.
  • a UICC Universal Integrated Circuit Card
  • An access control module for accessing a network of a mobile communication service provider may be included in the UICC. Examples of the access control module include a Universal Subscriber Identity Module (USIM), a Subscriber Identity Module (SIM), and an IP Multimedia Service Identity Module (ISIM).
  • USIM Universal Subscriber Identity Module
  • SIM Subscriber Identity Module
  • ISIM IP Multimedia Service Identity Module
  • a UICC including a USIM is usually called a USIM card.
  • a UICC including a SIM module is commonly referred to as a SIM card.
  • SIM card will be used in a general sense including a UICC card, a USIM card, a UICC including an ISIM, and the like. That is, even for a SIM card, the technical application 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 subscriber authentication and traffic security key generation when accessing a mobile communication network, thereby enabling safe use of mobile communication.
  • the SIM card is generally manufactured as a dedicated card for a corresponding operator at the request of a specific mobile communication operator when the card is manufactured, and authentication information for network access of the operator, for example, a USIM (Universal Subscriber Identity Module) application and IMSI (International Mobile Subscriber Identity), K value, OPc value, etc. are loaded on the card in advance and shipped. Accordingly, the manufactured SIM card is delivered to the subscriber by the corresponding mobile communication service provider and provided to subscribers, and then, if necessary, using technologies such as over-the-air (OTA), etc. to install, modify, and delete applications in the UICC are also performed. can do.
  • OTA over-the-air
  • Subscribers can use the network and application services of the mobile communication operator by inserting the UICC card into their own mobile communication terminal, and when replacing the terminal, the UICC card stored in the UICC card Authentication information, mobile phone number, personal phone book, etc. can be used as it is in the new terminal.
  • the SIM card is inconvenient for a mobile communication terminal user to receive services from other mobile carriers.
  • a user of a mobile communication terminal has the inconvenience of having to physically obtain a SIM card in order to receive a service from a mobile communication service provider.
  • 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 between the telecommunication companies is not made.
  • a SIM module of a mobile communication service that a user wants to use at a desired time can be downloaded to the UICC card.
  • Such a UICC card can also be used by downloading and installing a plurality of SIM modules, and selecting and using only one SIM module among them.
  • Such a UICC card may or may not be fixed to the terminal.
  • a UICC that is fixed to a terminal and used is called an eUICC (embedded UICC).
  • the eUICC refers to a UICC card that is fixed to the terminal and used, and can be selected by downloading a SIM module remotely.
  • a UICC card that can be selected by downloading a SIM module remotely will be collectively referred to as eUICC. That is, among UICC cards that can be remotely downloaded and selected by downloading a SIM module, UICC cards that are fixed to the terminal or not fixed will be collectively used as eUICC. Also, the downloaded SIM module information will be collectively used as the term eSIM profile. That is, among UICC cards that can be remotely downloaded and selected by downloading a SIM module, a UICC card fixed to a terminal and a UICC card that is not fixed are collectively used as eUICC. In addition, the downloaded SIM module information will be collectively used as the term Profile.
  • On Device Service Activation is a generic term for a solution that enables users to sign up for and open new communication services through a web portal or app on a terminal, or to install and open communication services before changing devices.
  • the On Device Service Activation service may be used interchangeably with the terms ODSA or ODA.
  • ODSA Client a module that needs to be installed in the terminal to support ODSA is called ODSA Client, and it can be used interchangeably with the terms ODSA or ODA.
  • a service provider may introduce an Entitlement Configuration Server (ECS) to determine whether a terminal or a subscriber who wants to use a specific service has the right to access or use the corresponding service.
  • ECS Entitlement Configuration Server
  • the ECS determines whether the requesting terminal can provide the communication-based service in consideration of the subscriber information of the terminal user and the network state of the terminal, and when it is determined that it is possible, the terminal transmits predetermined information for providing the communication-based service to the terminal can ECS is currently being introduced for services such as Voice over LTE (VoLTE), Voice over Wi-Fi (VoWiFi), and On Device Service Activation (ODSA).
  • VoIP Voice over LTE
  • VoIP Voice over Wi-Fi
  • ODSA On Device Service Activation
  • ECS acts as an ODSA Gateway server of the operator accessed by the ODSA Client of the terminal, and the message protocol between the ODSA Client and the ECS is defined in the TS.43 standard by the GSMA (GSM Association).
  • the ECS address can be expressed in various ways, but one example of the notation is FQDN (Full Qualified Domain Name), which is ase.mnc ⁇ MNC>.mcc ⁇ MCC>.pub. It can be created and used together with 3gppnetwork.org.
  • ⁇ MNC> and ⁇ MCC> are in the decimal format of the corresponding MNC and MCC, respectively, and if the corresponding information is a 2-digit number, it may be used as a 3-digit number by adding a zero to the beginning.
  • the communication service subscriber can use the mobile communication network connection as it is by using the authentication information stored in the UICC card by moving and inserting the SIM card from the existing terminal to the new terminal.
  • the downloaded profile is decrypted and installed only inside the corresponding eUICC, and after installation, it cannot be extracted back to the outside of the terminal, so a profile download and (re)installation is required in a new terminal.
  • telecommunication service providers are standardizing the GSMA method using LPA and SM-DP+ and the method using ODSA Client and ECS to provide a transfer installation of communication service when the device of the eUICC-equipped terminal is changed. It is expected that operators will select one of the methods to support the transfer installation of telecommunication services. However, depending on each method, support is available only from the existing terminal (the existing terminal with the profile installed) or the new terminal to be changed, so depending on the combination of the user's starting terminal and the operator's support method, the user cannot install the communication service before There is discomfort. This will be further described with reference to FIG. 2 .
  • existing mobile carriers provide a procedure for reissuing a SIM card by verifying the identity or ID authentication process of a subscriber when the SIM card is lost.
  • this process is usually processed only when a subscriber visits an offline branch or when processed online, a stricter identity authentication or ID verification process is required compared to an offline branch.
  • the subscriber has to go through such strict identity authentication or ID verification process in order to reinstall the profile to a new terminal.
  • the telecommunication service provider may authenticate the subscriber using the EAP-AKA method, which is a method commonly used by telecommunication service providers for subscriber authentication in telecommunication services. Authentication is possible only when information is accessible, and it cannot be used when the SIM module is deactivated.
  • the technical problem to be achieved by the present invention is to use a communication service used in an existing terminal in a communication system by re-installing/opening the communication service to a replaced new terminal.
  • the device change method is selected in consideration of the combination of the user-initiated terminal and the operator support method.
  • it is intended to provide a method for supporting the ODSA method in the existing terminal and the LPA method support in the new terminal.
  • it is intended to provide a download method that does not require additional subscriber ID authentication, which can be provided even when the SIM module is inactive.
  • the present invention for solving the above problems is a method performed by a terminal in a wireless communication system, the method comprising: acquiring information related to a device change; determining a device change method based on the information related to the device change; Transmitting, to a server, a first message including authentication-related information and an identifier of the terminal through the determined device change method, wherein the server is identified based on the device change-related information to the server 1 sending a message; and receiving, by the server, a second message including an authentication method determined based on the information related to the authentication and the identifier of the terminal, from the server.
  • the device change method is characterized in that at least one of an On Device Service Activation (ODSA) method and a Local Profile Assistant (LPA) method.
  • ODSA On Device Service Activation
  • LPA Local Profile Assistant
  • the information related to the device change is characterized in that it is obtained through at least one of information received by the second server, information stored in advance in the terminal, and profile metadata information.
  • the authentication method is authentication using Subscription Manager Data Preparation plus (SM-DP+), Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement (EAP-AKA) authentication, Entitlement Configuration Server (ECS) and the SM - It is characterized in that it is at least one of authentication using DP+ and authentication based on OAuth/Open ID protocol.
  • SM-DP+ Subscription Manager Data Preparation plus
  • EAP-AKA Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement
  • ECS Entitlement Configuration Server
  • OAuth/Open ID protocol OAuth/Open ID protocol
  • a first message including information related to authentication and an identifier of the terminal is received from a terminal through a device change method determined by the terminal to do; determining a processable authentication method based on the authentication-related information and the identifier of the terminal; and transmitting, to the terminal, a second message including the determined authentication method, wherein the device change method is determined based on information related to the device change obtained by the terminal.
  • a transceiver capable of transmitting and receiving at least one signal; and a control unit coupled to the transceiver, wherein the control unit is configured to: obtain information related to device change, determine a device change method based on the device change related information, and send to a server, the determined device change method transmits a first message including authentication-related information and an identifier of the terminal through and receiving a second message including an authentication method determined based on the identifier of the terminal.
  • the transmitting and receiving unit capable of transmitting and receiving at least one signal; and a control unit coupled to the transceiver, wherein the control unit: receives, from a terminal, a first message including information related to authentication and an identifier of the terminal through a device change method determined by the terminal, and performs the authentication based on information related to and the identifier of the terminal, determine an authentication method that can be processed, and transmit a second message including the determined authentication method to the terminal, wherein the device change method is determined by the terminal It is characterized in that it is determined based on information related to the acquired device change.
  • the method of the first terminal according to an embodiment of the present invention for solving the above problems includes the steps of receiving an input for moving an installed first profile, acquiring information on whether a communication service provider supports device change and a support method Transmitting predetermined information necessary for selecting a subscriber authentication method including support for the profile server authentication method to ECS and performing subscriber authentication through the profile server and returning it to the ECS.
  • the method of the terminal for solving the above problems, the step of determining the operator support method to be used in the terminal by checking the user-initiated terminal and the operator support method, the user authentication method supportable in the terminal Collecting and sending to the ECS server.
  • an ECS method for solving the above problems, selecting an authentication method with reference to possible authentication method information provided by a first terminal, a predetermined method to be used for authentication according to the selected authentication method generating and transmitting data to the terminal, verifying the user's authentication result received from the terminal, processing a series of procedures necessary for device change according to the verification result, and sending predetermined information required for profile download to the first terminal It includes the step of transmitting.
  • a method of a profile server for solving the above problems includes the steps of receiving a subscriber authentication request including data generated by ECS from a first terminal, performing subscriber authentication, and then performing the first terminal replying to
  • the communication service in the method of re-installing a communication service when a device change of an eSIM terminal of a communication service provider is changed, the communication service is provided seamlessly to the user in consideration of the combination of the communication service provider's device change support method and the user's device change start terminal UI/UX can be provided.
  • the terminal and the ECS can conveniently move the profile between the devices by using the authentication information with the USIM or the profile server without inputting additional information about the user's identity authentication information. .
  • a profile can be conveniently moved between devices by using authentication information with a profile server without requiring an ID input from the user.
  • the telecommunication service provider may delete the profile installed in the existing terminal as needed to reuse the profile later.
  • FIG. 1 is a diagram showing the configuration of a communication system to which an embodiment of the present invention is applied.
  • FIG. 2 is a diagram illustrating whether device change is supported according to a combination of a communication service movement support scheme of a communication company and a user-initiated terminal for eSIM device change.
  • FIG. 3 is a diagram illustrating an eSIM device change procedure processing procedure and a determination criterion of a terminal.
  • FIG. 4 is a diagram illustrating a method of acquiring eSIM device change setting information of an operator in a terminal.
  • 5A is a diagram illustrating an embodiment in which a telecommunication company provides an ODSA scheme and uses EAP-AKA authentication.
  • 5B is a diagram illustrating an embodiment in which a telecommunication company provides an ODSA scheme and uses ECS/SM-DP+ authentication.
  • 5C is a diagram illustrating an embodiment of a procedure for a user interface (UI) and a user experience (UX) when a communication company provides an LPA method and a user starts to change a device.
  • UI user interface
  • UX user experience
  • 5D is a diagram illustrating a representative processing procedure for UI (User Interface) and UX (User Experience) for changing the eSIM device starting from the first terminal.
  • UI User Interface
  • UX User Experience
  • 6A is a diagram illustrating an embodiment in which a telecommunication company provides an ODSA method and uses OTP or OAuth/Open ID authentication.
  • 6B is a diagram illustrating an embodiment in which a communication company provides an LPA method and uses LPA and SM-DP+ authentication in the first terminal (old terminal).
  • 6C is a diagram illustrating a representative processing procedure for UI (User Interface) and UX (User Experience) for changing the eSIM device starting from the second terminal.
  • UI User Interface
  • UX User Experience
  • FIG. 7 is a diagram illustrating a block configuration of a terminal in a wireless communication system according to an embodiment of the present invention.
  • the base station may be at least one of gNode B, eNode B, Node B, a base station (BS), a radio access unit, a base station controller, or a node on a network.
  • the 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.
  • a downlink (DL) is a wireless transmission path of a signal transmitted from a base station to a terminal
  • an uplink (UL) is a wireless transmission path of a signal transmitted from the terminal to a flag station.
  • LTE or LTE-A system may be described below as an example, embodiments of the present disclosure may be applied to other communication systems having a similar technical background or channel type.
  • 5G mobile communication technology (5G, new radio, NR) developed after LTE-A may be included in a system to which embodiments of the present disclosure can be applied, and 5G below is the existing LTE, LTE-A and It may be a concept that includes other similar services.
  • the present disclosure may be applied to other communication systems through some modifications within a range that does not significantly depart from the scope of the present disclosure as judged by a person having skilled technical knowledge. At this time, it will be understood that each block of the flowchart diagrams and combinations of the flowchart diagrams may be performed by computer program instructions.
  • These computer program instructions may be embodied in a processor of a general purpose computer, special purpose computer, or other programmable data processing equipment, such that the instructions performed by the processor of the computer or other programmable data processing equipment are not described in the flowchart block(s). It creates a means to perform functions.
  • These computer program instructions may also be stored in a computer-usable or computer-readable memory that may direct a computer or other programmable data processing equipment to implement a function in a particular manner, and thus the computer-usable or computer-readable memory. It is also possible that the instructions stored in the flow chart block(s) produce an article of manufacture containing instruction means for performing the function described in the flowchart block(s).
  • the computer program instructions may also be mounted on a computer or other programmable data processing equipment, such that a series of operational steps are performed on the computer or other programmable data processing equipment to create a computer-executed process to create a computer or other programmable data processing equipment. It is also possible that instructions for performing the processing equipment provide steps for performing the functions described in the flowchart block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • functions recited in blocks it is also possible for the functions recited in blocks to occur out of order. For example, two blocks shown one after another may in fact be performed substantially simultaneously, or it is possible that the blocks are sometimes performed in the reverse order according to the corresponding function.
  • the term ' ⁇ unit' used in this embodiment means software or hardware components such as FPGA (Field Programmable Gate Array) or ASIC (Application Specific Integrated Circuit), and ' ⁇ unit' refers to what roles can be done However, '-part' is not limited to software or hardware.
  • the ' ⁇ unit' may be configured to reside on an addressable storage medium or may be configured to refresh one or more processors.
  • ' ⁇ ' denotes components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, and procedures. , subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.
  • the functions provided in the components and ' ⁇ units' may be combined into a smaller number of components and ' ⁇ units' or further separated into additional components and ' ⁇ units'.
  • components and ' ⁇ units' may be implemented to play one or more CPUs in a device or secure multimedia card.
  • ' ⁇ unit' may include one or more processors.
  • UICC is a smart card inserted into a mobile communication terminal and used to store personal information such as network access authentication information, phone book, and SMS of a mobile communication subscriber to access mobile communication systems such as GSM, WCDMA, LTE, 5G, etc. It refers to a chip that enables secure mobile communication by performing subscriber authentication and traffic security key generation.
  • UICC is loaded with communication applications such as SIM (Subscriber Identification Module), USIM (Universal SIM), and ISIM (IP Multimedia SIM) depending on the type of mobile communication network the subscriber accesses. It is possible to provide a high-level security function for mounting various application applications.
  • SIM Subscriber Identification Module
  • USIM Universal SIM
  • ISIM IP Multimedia SIM
  • an eUICC embedded UICC
  • eUICC embedded UICC
  • eUICC can be installed by downloading a profile using OTA (Over The Air) technology.
  • OTA Over The Air
  • the eUICC can be named as a UICC that can download and install a profile.
  • the method of downloading and installing a profile using OTA technology in the eUICC may be applied to a removable UICC that can be inserted and removed from a terminal. That is, in an embodiment of the present invention, it can be applied to a UICC that can be installed by downloading a profile using OTA technology.
  • UICC may be used interchangeably with SIM
  • eUICC may be used interchangeably with eSIM
  • a profile may mean that an application, a file system, an authentication key value, etc. stored in the UICC are packaged in software form. Also, the profile can be named as access information.
  • the USIM Profile may have the same meaning as a profile or may mean that information included in a USIM application within the profile is packaged in a software form.
  • the profile server generates a profile, encrypts the generated profile, generates a profile remote management command, or includes a function to encrypt the generated profile remote management command, SM-DP (Subscription Manager Data Preparation), It may be expressed as Subscription Manager Data Preparation plus (SM-DP+) or Subscription Manager Secure Routing (SM-SR).
  • SM-DP Subscription Manager Data Preparation
  • SM-SR Subscription Manager Secure Routing
  • the term 'terminal' or 'device' is a mobile station (MS), user equipment (UE), user terminal (UT), wireless terminal, access terminal (AT), terminal, subscriber unit. may be referred to as a (Subscriber Unit), Subscriber Station (SS), wireless device, wireless communication device, Wireless Transmit/Receive Unit (WTRU), mobile node, mobile or other terms.
  • 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, and a digital camera having a wireless communication function.
  • PDA personal digital assistant
  • the terminal may include a machine to machine (M2M) terminal and a machine type communication (MTC) terminal/device, but is not limited thereto.
  • M2M machine to machine
  • MTC machine type communication
  • the terminal may be referred to as an electronic device or simply a device.
  • the 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).
  • LPA Local Profile Assistant
  • the eUICC identifier eUICC ID
  • EID unique identifier of the eUICC embedded in the terminal
  • an application protocol data unit may be a message for a terminal or a controller in a device to interwork with the eUICC.
  • a profile package may be used interchangeably with a profile or a term indicating a data object of a specific profile, and may be named as Profile TLV or Profile Package TLV.
  • the profile identifier is a unique identification number of the profile and may be referred to as an Integrated Circuit Card Identifier (ICCID).
  • ICCID Integrated Circuit Card Identifier
  • the profile package is encrypted using an encryption parameter, it may be named as a Protected Profile Package (PPP) or a Protected Profile Package TLV (PPP TLV).
  • PPP Protected Profile Package
  • PPP TLV Protected Profile Package TLV
  • BPP Bound Profile Package
  • BPP TLV Bound Profile Package TLV
  • the profile package TLV may be a data set expressing information constituting a profile in a TLV (Tag, Length, Value) format.
  • AKA authentication and key agreement, and may indicate an authentication algorithm for accessing 3GPP and 3GPP2 networks.
  • K is an encryption key value stored in the eUICC used for the AKA authentication algorithm
  • OPc is a parameter value that can be stored in the eUICC used for the AKA authentication algorithm in this specification.
  • NAA is a network access application (Network Access Application) application, and may be an application program such as USIM or ISIM stored in UICC or eUICC to access a network.
  • the NAA may be a network access module.
  • ECS may be used in combination with Entitlement Configuration Server, subscription authentication server, subscription server, entitlement authentication server, and Entitlement Server (ES), and ODSA Client may be used in combination with ODSA and ODA.
  • an end-user, a user, a subscriber, a service subscriber, and a user means a person who performs a device change and may be used interchangeably.
  • eSIM Transfer device change, subscription transfer, transfer of subscription information between terminals of communication service, and profile movement when changing a device are eUICC-equipped profiles corresponding to the USIM card movement when a device is changed from the first terminal to the second terminal It means to move, and can be used interchangeably. This should be interpreted according to the context.
  • FIG. 1 is a diagram showing the configuration of a communication system to which an embodiment of the present invention is applied.
  • the shaded parts indicate the standard entities and interfaces defined in GSMA TS.43, and the shaded parts indicate the standard entities and interfaces defined in GSMA.22.
  • the end user 100 is a user who performs profile movement between devices, and the device 105 means a terminal or device capable of a wireless communication service.
  • the corresponding Device 105 includes the LPA 140 and the eUICC 160 , and includes the ODSA Client 110 when supporting Entitlement Configuration exchange with the ECS.
  • the LPA 140 and the SM-DP+ 150 are standard entities defined in GSMA SGP.22, and the LPA may be involved in downloading and installing a profile in the eUICC, and moving the profile to another profile when changing a device.
  • the terminal 105 may receive an input for profile movement from the user 100 from the ODSA Client 110 or the LPA 140 and start a device change procedure in the terminal. At this time, when there is no predetermined information on whether to support device change and a processing method, etc. defined in advance, the terminal accesses a separate server, the Configuration Server 170 to obtain the information, and determines the device change method of the terminal All or part of the necessary information can be obtained and utilized.
  • the corresponding Configuration Server 170 may be implemented alone or as one of the BSS/OSS 130 of the communication service provider.
  • the MNO (Mobile Network Operator) BSS/OSS 130 is a server system for a communication service operator to operate and process a communication service, and is also called a communication company's Back-end System.
  • MNO BSS/OSS handles subscription and cancellation of communication service in eUICC device, and processing of device change through information exchange with SM-DP+ (150) server, which is a profile server, or ECS (120), which is a server that handles service subscription management.
  • SM-DP+ (150) server which is a profile server, or ECS (120), which is a server that handles service subscription management.
  • the ECS 120 and the SM-DP+ 150 server are interlocked with the back-end system of the communication service provider and may be implemented independently of the back-end system of the communication service or as a part of the back-end system.
  • the ODSA Client 110 and the LPA 140 may be integrated into one application or implemented separately.
  • Configuration Server 170 is indicated as being connected to ODSA Client 110, but it is not limited thereto, and other applications of the terminal or LPA directly access Configuration Server 170 to obtain information for device change processing. The procedure can then be processed.
  • FIG. 2 is a diagram illustrating whether device change is supported according to a combination of a communication service movement support scheme of a communication company and a user-initiated terminal for eSIM device change.
  • the As-Is table 200 shows methods that can be provided in consideration of the combination of the user-initiated terminal and the operator support method at the time of disclosing the present invention.
  • the operator support method is the ODSA method, and the operator does not provide for the user to start changing the device in the first terminal 300, and TS. 43 There is nothing defined in the standard.
  • the operator support method is the LPA method and the user starts to change the device in the second terminal 350 , there is no method for processing this in the corresponding second terminal 350 .
  • the LPA method uses the ICCID information of the profile that is already installed in the terminal and wants to move, the second terminal 350 cannot currently support the method, but when the user 100 can use the first terminal 100 It may be usable by allowing it to be processed through the corresponding terminal.
  • the terminal does not provide a corresponding processing method. Therefore, the method of device change to be provided when the present invention is introduced is shown in the To-Be table 210 .
  • As-Is table 200 all unsupported parts marked as FAIL can be supported through the present invention, and for this purpose, UI (User Interface) and UX (User Experience) when supporting them through FIGS. and Call Flow are shown.
  • FIG. 3 is a diagram illustrating an eSIM device change procedure processing procedure and a determination criterion of a terminal.
  • the terminal 105 determines whether the terminal generating the event for the device change by the user is the existing terminal from which the user wants to move the existing profile or the new terminal to receive the profile reinstallation.
  • the terminal to which the existing profile is to be moved will be referred to as the first terminal 300
  • the terminal to which the profile is to be reinstalled will be referred to as the second terminal 350 .
  • the device 105 may identify whether the user enters from the first terminal or the second terminal by separating the user 100 entry menu.
  • the device 105 When the user selects the device change menu in the device 105 and a request for device change is input 300, the device 105 is information stored in advance in the Configuration Server 170 terminal, as described later in FIG. 4, or a profile By checking the information collected through the metadata of By checking the state of the terminal including whether it is the first terminal 300 or the second terminal 350 , a device change method of the communication service to be used in the terminal 105 may be finally determined 310 .
  • Whether to support device change 305 refers to determining whether or not it is possible to download a profile pre-installed in the eUICC of the first terminal 300 as a profile having the same or the same communication service subscription setting to the second terminal 350. it means.
  • the terminal 105 changes the device using the ODSA Client and ECS as the carrier change support method for the profile. It is possible to obtain information on whether the method supports the method or whether the device change method using the LPA and SM-DP+ server is supported.
  • a communication service provider may support one or more device change methods among the above-mentioned two device change methods. If there is more than one device change support method for the profile to be moved by the carrier collected from the terminal, the carrier may additionally provide information on the priority of applying the device change method to the profile metadata or Configuration Server ( 170) may be stored and provided to the terminal.
  • the terminal 105 may display a screen requesting selection to the user 100 so that the user can select it, or may select and apply one of the two methods according to the terminal default setting.
  • the device change method using the ODSA Client and ECS will be described in the ODSA method for convenience of explanation later, and the device change method using the LPA and SM-DP+ server will be described in the LPA method.
  • Detailed procedures including each device change method are shown in Fig. 5a It will be described in detail with reference to FIGS. 5D and 6A to 6C.
  • the terminal 105 needs to process in the LPA method according to the information obtained in the above manner, whether the terminal 105 that starts the device change is the first terminal 300 or the second terminal 350 Subsequent procedures should be handled differently accordingly.
  • the LPA 140 of the terminal is the SM-DP+ 150 ), including predetermined information about the profile to be changed in the device, may request a command for requesting profile movement.
  • the SM-DP+ 150 notifies the communication service provider 130 of the device change request, and the SM-DP+ 150 communicates with the communication service provider 130 through the ES2+ Interface defined in GSMA SGP.22 to the second terminal ( 350) to create and process a profile that will be downloaded for device change.
  • the SM-DP+ 150 exchanges the signature value of the SM-DP+ and the eUICC certificate between the eUICC 160 of the first terminal 300 in which the profile to be moved is installed (Common Mutual Authentication), and the corresponding terminal in which the profile is installed. And by authenticating the eUICC (160), it is possible to authenticate the subscriber.
  • the method is referred to as the SM-DP+ authentication method 315 .
  • the SM-DP+ 150 may return data necessary for downloading the profile generated by the second terminal 350 to the first terminal 300 .
  • the second terminal 350 scans the QR code displayed on the screen of the first terminal. (340) and receiving and installing the profile from the profile server 150 included in the QR code, it is possible to complete (390) the profile movement and installation according to the device change.
  • the first terminal 300 may transmit the information to the second terminal 350 via short-distance communication such as NFC, Bluetooth, UWB, or WiFi communication, or a server.
  • short-distance communication such as NFC, Bluetooth, UWB, or WiFi communication
  • the second terminal 350 can install the profile through the normal eSIM profile download process of scanning the QR code, so that There is an advantage in performing a device change operation without modification.
  • it will be described as an example using a QR code, but the embodiment of the present invention is not limited thereto.
  • the following shows an example of a configuration of data required to download a profile to be displayed as a QR code.
  • SMDP.TEST.COM means the profile server address as an example, $ is a delimiter that separates each information, LPA: means this data is in the Activation Code format used for profile download, x The part means the type of Activation Code. For example, this value may be a number such as 1, or 2, or 3, or 4, and the XXXXX part is the data of the ACToken (Activation Code Token) area, and the ASN.1 Data below It may be information that encodes information including part or all of
  • NotificationMetadata [47] SEQUENCE ⁇ -- Tag 'BF2F'
  • the encoding is 1) ASN.1 format data as shown below is encoded by DER method, and then hexadecimal encoding is performed again so that it can be expressed as characters 2) ASN.1 format data as shown below is DER method It may be a method of encoding with BASE64 encoding and then BASE64 encoding so that it can be expressed as characters.
  • the data required to download the profile is collectively referred to as the activation code.
  • the first terminal 300 obtains device information (eg, eUICCInfo, DeviceInfo) of the second terminal 350 .
  • the first terminal 300 obtains and requests an IMEI (International Mobile Equipment Identity) of the second terminal 350 through the user screen (for example, *# on the terminal keypad) 06#, etc.) to add and transmit a device change request to ECS or LPA.
  • IMEI International Mobile Equipment Identity
  • the terminal 105 acquires the operator's device change method is the LPA method
  • the terminal 105 initiating the device change is the second terminal 350
  • the second terminal 380 provides the user with the first terminal. (300) Creates a menu that can guide different procedures depending on whether or not it is used and displays it on the screen.
  • the second terminal 350 displays a guide message about the progress in the first terminal 300 and scans the QR code displayed from the first terminal 300 to a menu. You can go and wait.
  • the user acquires the data necessary for the first terminal to download the profile from the profile server, and displays it on the first terminal 300 in the form of a QR code.
  • the second terminal 350 scans (385) the corresponding QR code to process the subsequent procedure in the same way.
  • the second terminal 350 displays a guide message stating that the communication service provider cannot support the device change service of the profile without the existing first terminal 300 and The procedure may end 308 .
  • the terminal 105 acquires the operator's device change method is the ODSA method, and the terminal 105 that starts the device change is the first terminal 300 , the terminal provides status information of the profile to be moved installed in the terminal and the terminal Information on the authentication method implemented in the ODSA Client 110 is transmitted to the ECS 120, and the terminal or server may determine the authentication method for the corresponding profile.
  • the profile status information is information on whether the profile is enabled or disabled. Enabled means that the network is activated while the terminal 105 can access the file data of the corresponding profile. Disabled means that the terminal 105 is not able to access the file data of the profile and the network is not activated.
  • the terminal may determine the authentication method by determining the authentication method according to the priority of the authentication method set in the terminal, transmitting it to the ECS 120 , and finally confirming, determining, and replying to the ECS 120 .
  • the terminal transmits the profile state information to be moved from the terminal 120 and information on all authentication methods supported by the terminal to the ECS 120, and the ECS 120 applies the service provider's authentication method and authentication method for the profile In consideration of the priority for , it may be possible to select one and reply in a method to use.
  • the first terminal 300 is ECS 120 and SM-DP + 150 cooperative authentication method 315 ECS & DP + method 325 , Select one of the EAP-AKA method 330 using IMSI (Internal Mobile Subscriber Identifier), which is the subscriber identifier information stored in the SIM module, and the k value, and the OAuth/Open ID method 335, which is a web service login-based authentication method. Accordingly, it is possible to perform whether the corresponding access terminal and the subscriber have ODSA service qualification authentication through data exchange with the ECS 120 thereafter. A procedure including each authentication method will be described later in detail with reference to FIGS. 5A to 5D .
  • IMSI Internal Mobile Subscriber Identifier
  • the ECS 120 When the qualification of the terminal and subscription for ODSA service access is authenticated in the ECS 120, the ECS 120 is the second terminal 350 through the carrier back-end system 130.
  • the profile from the SM-DP+ 150 Data necessary for download may be acquired and returned to the ODSA Client of the first terminal 300 .
  • the telecommunication company back-end system 130 may reply, including a method of obtaining the first terminal 300 by its own generation, etc., instead of transmitting the data required to download the profile from the corresponding SM-DP+ 150 . may be A detailed method for the first terminal 300 to acquire the corresponding data will be described later with reference to FIG. 5C .
  • the second terminal 350 scans the QR code displayed on the screen of the first terminal (340) and , by receiving and installing the profile from the profile server 150 included in the corresponding QR code, it is possible to complete the installation of the profile movement according to the device change (390).
  • the terminal 105 acquires the operator's device change method is the ODSA method
  • the terminal 105 initiating the device change is the second terminal 350
  • the terminal determines whether the first terminal 300 has Corresponding information may be obtained from the user 100 through a user input.
  • the second terminal 350 is the first terminal 300 to receive the authentication code from the user.
  • the phone number (MSISDN) of the first terminal 300 may be input and transmitted to the ECS 120 .
  • the ECS 120 may exchange messages with a separate authentication server of the telecommunication company, and transmit the authentication code as a text message to a corresponding phone number (MSISDN) from the separate authentication server of the telecommunication company.
  • MSISDN phone number
  • the second terminal 350 can be authenticated by selecting the OAuth/Open ID method 370, which is a subscriber authentication method through a login method, by connecting to a web portal or web application.
  • the OAuth/Open ID method 370 is a subscriber authentication method through a login method, by connecting to a web portal or web application.
  • the ECS 120 is the second terminal
  • the 350 may transmit data required for profile download from the profile server 170 to the ODSA Client 110 of the second terminal 350 in an Activation Code format.
  • the data is transmitted from the ODSA Client 110 of the terminal to the LPA 140, and the LPA 140 downloads the profile to be moved from the SM-DP+ server 150 and installs the eUICC 160 to move the profile according to the device change. can be processed.
  • the terminal uses information obtained in FIG. 4 (eg, operator support authentication methods) and user input ( For example, whether the first terminal can be used), profile status information (eg profile activation status), and the like, authentication for handling device change may be strengthened by processing authentication with one or more authentication methods.
  • the second terminal 350 uses the ODSA method and the first terminal 300 is usable (360)
  • the operator supports both the OAuth/OpenID and SMS-OTP methods
  • OAuth/Open ID The subscriber is authenticated by logging in to the web portal of the operator in the method 370 , and since the first terminal 300 is usable, the authentication 355 through SMS-OTP may be additionally provided.
  • FIG. 4 is a diagram illustrating a method of acquiring setting information for profile movement processing when a device is changed in the terminal 105 equipped with an eUICC.
  • the terminal converts MCC + MNC ( The values of mobile country codes (MCC) and mobile network codes (MNC) defined in The ITU-T Recommendation E.212 can be obtained.
  • MCC mobile country codes
  • MNC mobile network codes
  • the terminal 105 provides a menu for the user 100 to select a communication operator, thereby providing MCC + MNC information of the communication operator can be obtained.
  • MCC+MNC information the terminal can determine which operator's profile should be checked for movement setting.
  • the terminal 105 also provides the End User 100 to select a menu for moving the profile, so as to start performing the procedure for changing the device of the corresponding profile and either the first terminal 300 or the second terminal 350 . It is possible to obtain information through which terminal to access.
  • the terminal 105 may now select ( 470 ) one of the LPA method or the ECS method as a method to be used for the profile movement by checking the operator's device change setting information for the profile movement.
  • Device change setting information required by the terminal including whether the carrier supports device change for the corresponding profile User authentication method, for example, authentication method identification information such as EAP-AKA, ECS&DP+, OAuth/Open ID, and information on preference priority may be included.
  • authentication method identification information such as EAP-AKA, ECS&DP+, OAuth/Open ID, and information on preference priority may be included.
  • the terminal 105 may perform the following.
  • the terminal 105 does not receive all of the device change setting information of the telecommunication providers stored in the Configuration Server 170 for memory and battery saving, etc. at a specific period or when the first terminal is booted, and the terminal 105 does not allow the user
  • (100) selects a carrier in the UI of the terminal 105, it requests the configuration server 170 for device change setting information for the MCC + MNC of the carrier, and in response to the request, sets the device change of a specific operator information can be obtained.
  • the terminal 105 In the case where the Configuration Server 170 exists to process the device change execution and the corresponding server address is set in the terminal 105, the terminal is configured in the corresponding server at the time of initial booting or at a specific period according to the terminal settings. You can import and save some or all of the device change setting information and use it. When the user selects a specific carrier or selects a profile to move, the terminal 105 may obtain and utilize a matching value by checking the corresponding information stored in the memory of the terminal.
  • the device change method of the carrier is preloaded and, as described above, if the user 105 selects a profile or a carrier of the profile to be moved from the menu, The terminal 105 may check device change setting information by matching information stored in the memory.
  • the terminal 105 may use one or more of the above-mentioned four methods in combination, and when the device change setting information obtained through the corresponding option is different, the method may be determined and set according to the terminal setting. As an example, the terminal may determine the most recent configuration information or as another example, the priority in selecting profile metadata.
  • the terminal may determine the most recent configuration information or as another example, the priority in selecting profile metadata.
  • 5A to 5D show embodiments of a device change method when starting from the first terminal 300 .
  • the entire procedure for device change processing can be broadly divided into the following procedures.
  • the step of the first terminal 300 grasping the eSIM setting information
  • the step of performing terminal and user authentication for checking the ODSA service qualification the step of issuing an Activation Code when the authentication is completed
  • the second terminal 350 This is the step to obtain the relevant information, download the profile, and complete the moving installation.
  • 5A is a diagram illustrating an embodiment in which a telecommunication company provides an ODSA scheme and uses EAP-AKA authentication.
  • the end user 100 may select a profile to be moved for device change on the screen of the LPA or an LPA-implemented application of the first terminal 300, and select a menu to move the profile (steps 5a-10).
  • the terminal 300 has the carrier identification ID information (MCC+MNC) of the corresponding profile, and checks whether the setting information for changing the eSIM device of the corresponding carrier is stored in the terminal, while the terminal's LPA1
  • the status information of the corresponding profile may be obtained by performing the ES10c.GetProfilesInfo() function call defined in GSMA SGP.22 to the eUICC 160 of the terminal.
  • the LPA1 410 may additionally check whether or not device change support, identification information on a support method, or a server address for subsequent processing is included in the metadata of the corresponding profile from the eUICC 160 of the terminal.
  • steps 5a-10 to 5a-30 a method of checking through option 1 and option 3 is illustrated as an example, but the method of obtaining is not limited thereto, and one or more options 1 to 4 are used as described above in FIG. And it can be obtained in combination.
  • the first terminal 300 uses the corresponding profile to support the ODSA method using the ODSA Client 110 and the ECS 120 by the carrier, and acquires an ECS address for processing the corresponding method.
  • the ODSA Client of the first terminal 300 or the ODSA1 500 which is an app in which the ODSA Client is implemented, obtains the profile status information obtained through the profile metadata check (steps 5a-30) from the LPA1 510, and the terminal It is possible to transmit an authentication request to the ECS 120 by checking the capability of the terminal to collect possible authentication methods of the terminal. As an example, it can be expressed as (steps 5a-50).
  • the corresponding authentication request message includes IMEI as a terminal identifier, identification information on authentication methods implemented in the terminal, and ICCID, IMEI, or Extensible Authentication Protocol (EAP) as identification information that can infer that the requesting terminal is the first terminal 300 ID or a new identifier may be defined and included, and ICCID and status information of the corresponding profile may be included as the target profile ID to be moved.
  • EAP Extensible Authentication Protocol
  • identification information indicating that the requesting terminal is the first terminal 300, ICCID as the target profile ID to be moved, and information required for device change processing, such as status information of the corresponding profile are included in the authentication request message.
  • the device change request time (steps 5a-160) after authentication is completed and transmit it from the terminal.
  • the identification information on the authentication method implemented in the terminal may be used as an identifier indicating whether the corresponding authentication method is implemented in the terminal or is implemented in the terminal and is available at the time of transmission.
  • the terminal may transmit the profile status information without including the profile status information.
  • EAP-AKA Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement
  • the terminal includes the EAP ID in the authentication request and transmits it (steps 5a-50) )can do.
  • a new identifier to distinguish it can be defined or an existing identifier (eg, SM-DP+Address) can be used as the corresponding identification information.
  • the corresponding identifier will be described as DP+AuthSupport for convenience in the present invention. If there is no identification information or authentication token for the authentication method in the terminal, the ECS may determine that the terminal can provide only OAuth/Open ID.
  • the ECS 120 When the ECS 120 receives authentication identification information for one or more authentication methods supported by the terminal from the terminal (steps 5a-60), for example, an EAP ID as an EAP-AKA identifier, an identifier for ECS&DP+ authentication When receiving including DP+AuthSupport, the ECS 120 selects one possible method according to the operator's preference and whether the operator supports the authentication server, and may reply to the terminal.
  • authentication identification information for one or more authentication methods supported by the terminal from the terminal (steps 5a-60), for example, an EAP ID as an EAP-AKA identifier, an identifier for ECS&DP+ authentication
  • the ECS 120 selects one possible method according to the operator's preference and whether the operator supports the authentication server, and may reply to the terminal.
  • the ECS 120 determines whether relay with the AAA (Authentication, Authorization and Accounting) authentication server of the operator can be supported in order to perform EAP-AKA authentication.
  • AAA Authentication, Authorization and Accounting
  • Steps 5a-60 to 5a-170 show a method when the ECS 120 performs authentication as EAP-AKA through the corresponding confirmation.
  • identification information on the authentication method implemented in the terminal when EAP-AKA (Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement) is implemented in the terminal, the terminal includes EAP_ID in the authentication request as described above and transmits (5a) -50 steps) can be done.
  • the first terminal 300 may include the International Subscriber Identity Module (IMSI) value of the profile selected by the user to move to the EAP ID and transmit it to the ECS 120, and cannot obtain the corresponding value, but EAP-AKA is provided to the terminal
  • IMSI International Subscriber Identity Module
  • the EAP ID value may be transmitted as NULL or empty value, or a separate identifier or value to indicate this may be defined and provided.
  • the IMSI value is information obtainable from the profile's internal data or profile's metadata when the profile's status information is Enabled.
  • EAP-AKA is implemented so that it can be provided, and the corresponding authentication is performed at the current request to perform device change. It can indicate that it can be used.
  • the failure to acquire the corresponding information means that EAP-AKA is implemented in the terminal at the time point, but the profile status information is disabled, the ECS 120 may determine.
  • the first terminal 300 can clearly inform the ECS 120 that EAP-AKA authentication can be used in the corresponding terminal by transmitting the status information of the profile acquired in steps 5a-30 together with the ECS 120. There is (steps 5a-50). If EAP-AKA is implemented in the terminal through the received authentication request message from the ECS 120, but the profile state is Disabled, the ECS 120 determines whether to perform user authentication with EAP-AKA and a processing guide, etc. It is possible to reply to the terminal including the operator message (steps 5a-70).
  • the terminal obtains the user's consent by displaying the operator message on the terminal, and the user 100 may accept or reject the EAP-AKA authentication process (steps 5a-80).
  • the user permits
  • 10c.EnabldProfile() can be processed from LPA1 510 to eUICC.
  • the LPA1 510 may obtain the corresponding profile state information and IMSI value from the eUICC and transmit it to the ODSA1 500 .
  • the ODSA1 500 of the first terminal may transmit an authentication request message to the ECS 120 using the EAP_ID as an IMSI value as in steps 5a-95.
  • the profile state information may be additionally included and sent to notify the ECS 120 that the profile state has been changed and that EAP-AKA authentication is possible. If the user rejects (steps 5a-170), the first terminal 300 transmits a corresponding rejection message to the ECS 120, and when the ECS 120 receives the rejection message, the existing received ( The authentication procedure may be processed by selecting an authentication method to be used with reference to another authentication method of the terminal received through steps 5a-50) (steps 5a-180).
  • the EAP-AKA method uses a challenge-response mechanism and can create an encrypted session through symmetric key-based authentication.
  • the ECS 120 determines that the EAP-AKA method can be used based on the authentication identification information of the terminal or the combination of the terminal identification information and the profile state information, and selects the EAP-AKA method, the ECS 120 is the operator authentication server 540 ) can request the EAP-AKA Challenge (steps 5a-120).
  • the operator authentication server 540 performs the AKA algorithm to generate an EAP-AKA Challenge value as defined in "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)" and returns it to the ECS 120 And the ECS 120 may reply to the terminal together with the EAP-AKA Challenge with the selected authentication method (here, the EAP-AKA method) and the value required for verification (steps 5a-110).
  • EAP-AKA Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement
  • the authentication method selected by the ECS 120 may be notified as a separate identifier (eg, AuthType (EAP-AKA) in steps 5a-110), or upon reception of predetermined information that can determine that the authentication method is the corresponding authentication method (for example, , by receiving only the EAP-AKA Challenge value of steps 5a-110), it may be determined that the ECS 120 has determined the corresponding authentication method.
  • AuthType EAP-AKA
  • the eUICC of the first terminal 300 performs the EAP-AKA algorithm using the corresponding challenge value and the security key value of the SIM module, and returns to the ECS 120 including the corresponding result value. (Steps 5a-130) can be done.
  • the ECS 120 relays the received information to the operator authentication server 440, and the operator authentication server 440 verifies the EAP-AKA Challenge value from the value received from the first terminal 300 (steps 5a-130). In this way, it is possible to reply to the ECS 120 (steps 5a-140) whether or not the authentication is performed. If the corresponding authentication result (steps 5a-140) is successful, the ECS 120 generates an authentication token (AuthToken) that can be used for a session connection with the ECS 120 thereafter and transmits it to the first terminal 300 (5a). -150 steps) can be done.
  • AuthToken authentication token
  • the first terminal 300 may request the movement of the device subscribed to the communication service (steps 5a-160) by using the IMEI and the received authentication token as the terminal's unique identification information as parameters (steps 5a-160).
  • information required for device change processing such as identification information indicating that the requesting terminal is the first terminal 300, ICCID as the target profile ID to be moved, and state information of the corresponding profile is not added to the authentication request message, and authentication is performed
  • a method of including the device change request time (steps 5a-160) and transmitting the device from the terminal is also possible. This may be equally applied to another embodiment of requesting a device change from the first terminal 300 .
  • EAP-AKA Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement
  • the ECS 120, the SM-DP+ server 150, and the MNO BSS/OSS 130 acquire information necessary to change service subscription information, and the SM-DP+ server 150 and the MNO BSS/OSS ( 130) may prepare to create a profile (steps 5a-190).
  • the ECS 120 transmits the new subscription information including the Subscription ID mapped to the current ICCID of the corresponding profile, or the IMEI of the new terminal in addition to the communication carrier's Back-end system 130 can be requested to Upon receiving this, the MNO BSS/OSS 130 performs a series of processes for profile creation through the SM-DP+ server 150 and the ES2+Interface defined in SGP.
  • the ICCID and the Activation Code may be obtained and returned to the ECS 120 .
  • Information necessary for changing the ECS service subscription information may be updated at that time or at a later specific time to change the subscription information stored in the ECS 120 .
  • the ECS 120 may transmit the received Activation Code to the ODSA1 500 of the first terminal (steps 5a-200).
  • the ECS 120 may transmit (steps 5a-200) including a value for whether to delete the corresponding profile from the first terminal 300 together.
  • the first terminal 300 launches a method for obtaining the Activation Code received from the second terminal 350 to the first terminal 300 as a user guide message of the corresponding terminal (steps 5a-210) .
  • the first terminal 300 informs the user of the deletion of the existing profile and deletes the device to process the device change. You can obtain the user's consent by notifying that you can. If the user agrees to the deletion, if the ODSA Client or ODSA Client, which is an app implemented with the ODSA Client, in the first terminal requests the LPA1 510 to delete the profile, the LPA1 510 "ES10c" for the profile to be moved .DeleteProfile" Function Call can be performed to delete a corresponding profile from the eUICC, and the corresponding profile can return a notification about deletion to the LPA1 510 or ODSA1 500 .
  • the terminal may process so that the ODSA1 500 receives a notification for deletion of the corresponding profile through the LPA1 510 or LPA1 to activate and provide the Activation Code.
  • the end user 100 may acquire an activation code from the second terminal 350 (steps 5a-220) according to the guidance in steps 5a-210.
  • the activation code may be displayed in the form of a QR code as the user's UI of the second terminal 350 and the corresponding QR code may be scanned using the camera of the first terminal 300 .
  • the Activation Code is acquired from the LPA2 430 and connected to the SM-DP+ server address set in the Activation Code to GSMA SGP.
  • the profile may be downloaded to the second terminal and installation may be completed (steps 5a-230).
  • the MNO's Back-end system 130 transmits the ICCID or ICCID of the new profile installed in the second terminal 350 to the ECS 120 together with the IMEI of the second terminal 350, If the ECS 120 matches the corresponding ICCID with the ICCID value obtained in steps 5a-120 and is the same, the ECS 120 may update the corresponding subscription information and optionally return the update result to the operator back-end system 130 .
  • 5B is a diagram illustrating an embodiment in which the ECS/DP+ method is used as an authentication method as a profile movement supporting the ODSA method starting from the first terminal.
  • the first terminal 300 may acquire configuration information for device change through a profile, memory, and configuration server 170 . Thereafter, in performing the terminal and subscriber authentication, when the ECS&DP+ authentication method is to be performed, the terminal may request authentication by including an identifier indicating that DP+AuthSupport is possible in the authentication request transmitted to the ECS 120 .
  • DP+AuthSupport of steps 5a-50 is indicated as an arbitrary identifier, but the name is not limited, and the terminal performs authentication with identifier information indicating that authentication can be performed with SM-DP+ This possible SM-DP+ address can also be used as an identifier.
  • the ECS 120 checks the capability for supporting the corresponding authentication method, including whether the GSMA Root CI (Certification Issuer) certificate and the SM-DP+ address to be redirected to perform the corresponding authentication are configured, The processing can be decided by the corresponding authentication method.
  • the ECS 120 may additionally determine whether to use the received SM-DP+ address as the SM-DP+ address to be redirected.
  • the ECS 120 When the corresponding authentication method is determined, the ECS 120 generates a nonce value, which is arbitrary data (steps 5b-20), and sends the ECS&DP+ authentication method to the first terminal 300, the SM-DP+ server address to be authenticated, and the generated nonce. You can reply with the value (steps 5b-30).
  • the ECS 120 may explicitly inform the terminal of the selected authentication type, and even if there is no explicit provision of the selected authentication type, through provision of predetermined information that the terminal can determine, That is, for example, a reply to the SM-DP+ server address to be authenticated may be determined by the terminal.
  • the ECS may request redirection to the SM-DP+ server address to be authenticated with the HTTP(s) "302 Found" response structure that the ECS returns when the OAuth/Open ID authentication method is selected. In this case, the following examples One of them may be included.
  • Body contains:
  • Client ID ⁇ ID pre-issued from SM-DP+ to be authenticated by ECS>&
  • Body contains:
  • client ID ⁇ ID pre-issued from SM-DP+ to be authenticated by ECS>&
  • redirect URI ⁇ AES-encrypted ECS address as reply-to address>
  • Example 1 As in Example 1) or Example 2), if an identifier indicating DP+ authentication is included in the scope or response type of the HTTP(s) "302 Found" response structure, the terminal uses ECS&DP+ instead of OAuth/Open ID method. It is determined that authentication is requested, and as an internal operation of the first terminal 300, the ODSA1 500 transmits the received data to the LPA1 510 (steps 5b-40), which can then be processed as performing the DP + authentication procedure as follows. have. In the case of OAuth/Open ID authentication method, client id, redirection URI and binding are required for the code received as response type, and client id and redirection URI must be included in the initial Http(s) Response - 302 Found and transmitted.
  • OAuth/Open ID authentication method client id, redirection URI and binding are required for the code received as response type, and client id and redirection URI must be included in the initial Http(s) Response - 302 Found and transmitted.
  • OAuth2.0/OIDC Sever issues a client ID for ECS in advance through a contract in advance and has information about redirection URI. If the terminal requests authentication with a specific client ID and redirection URI, the code You can issue and reply. However, since ECS/SM-DP+ authentication can be processed without a contract between SM-DP+ and ECS in advance, if an identifier indicating DP+ authentication is included in Http(s) Response - 302 Found in ECS, one of client ID and redirect URI or Even if the whole is not included, the terminal does not process it as an error and must process it as a DP+ authentication procedure.
  • a mutual authentication procedure may be performed first before performing the procedure (steps 5b-50) between the eUICC and SM-DP+.
  • the LPA1 510 requests ES10b.GetEUICCChallenge from the eUICC of the first terminal 300 in which the corresponding profile is installed, receives the eUICCChallenge value as the corresponding message value, and ES9+.InitiateAuthenticate as a message including the corresponding eUICCChallenge value in the LPA1 510 .
  • a request message may be transmitted to the SM-DP+ 150 .
  • the profile server can generate a Transaction ID by verifying the corresponding value, and generate and reply to the profile server's signature for the data including the Transaction ID and eUICCChallenge values.
  • the reply InitiateAuthenticate reply message may include the profile signature value and Transaction ID.
  • the first terminal 300 After receiving the InitiateAuthenticate reply message, the first terminal 300 generates and includes the nonce value (steps 5b-40) received from the ECS 120, the ICCID of the device change target profile, and the eUICC signature data in which the ICCID is installed. data to be transmitted to the SM-DP + server 150 .
  • the EID may be included and transmitted.
  • the SM-DP+ server 150 receives the AuthenticateClientRequest message, Verification of eUICC installation of the first terminal of the corresponding ICCID by performing a validation process including verification of the ICCID (indicated as ICCID1) of the profile to be processed before the subscription information included in the AuthenticateClientRequest message and the signature data of the corresponding eUICC of the first terminal
  • the signature of the profile server is generated as a result of verification, and the authentication token including the nonce received in steps 5b-50, eUICC signature data, and signature data of the profile server can be included in the AuthenticateClientResponse message (steps 5b-60) and returned.
  • the corresponding reply information may additionally include the EID mapped to the ICCID.An example of the corresponding reply message is ES9+.
  • AuthResponse AuthToken (EID, ICCID, Nonce, DP+ Signature)
  • steps 5b-60 can be marked.
  • the signature data verification of the eUICC 160 of the first terminal 300 is the ICCID or additional data to the ICCID (ECS Nounce, eUICC signature value, processing sequence number) For data including It may be signature verification using the certificate of the eUICC 160 of the first terminal 300 .
  • the signature verification may be Elliptic Curve Digital Signature Authentication (ECDSA).
  • the eUICC certificate may be authenticated by the EUM (eUICC Manufacturer) certificate.
  • the EUM certificate may be verified with a Certificate Authority (CA) certificate possessed by the profile server 150 .
  • CA certificate may also be referred to as a root certificate issuer (CI) certificate.
  • the validation process includes a process of confirming that the eUICC that was finally installed for the ICCID is the eUICC 160 of the first terminal 300 and a process of confirming the validity of the message using the message processing sequence number information (Sequence Number) may include
  • the profile server 150 queries the operator server whether to allow reinstallation of the profile for authentication of the ICCID, and returns the result. process may be included.
  • the LPA1 510 receives the corresponding authentication token from the SM-DP+ 150 (steps 5b - 60)
  • the LPA1 510 delivers the corresponding information to the ODSA1 500, and the ODSA1 500 identifies the corresponding authentication token as the terminal. It may reply to the ECS 120 together with the information (steps 5b-70).
  • the ECS 120 verifies the validity of the nonce value initially generated (steps 5b-20) and delivered from the received authentication token, and verifies the SM-DP+signature value (steps 5b-80), and the subsequent procedure is described above (steps 5a- 5a- Steps 190 to 5a-230) may be performed to complete the device change procedure.
  • the corresponding nonce value generated by the ECS 120 may be used as an identifier for determining whether to reuse the corresponding authentication request and verifying/verifying whether it is a request from the corresponding ECS 120 .
  • the ECS 120 When the ECS 120 receives a message including a nonce value, the ECS 120 includes a process of determining that the transmitted message is a reply value to the message generated in the first ECS and whether the nonce value is not reused. Thus, the validity of the corresponding Nonce value can be determined.
  • the ECS 120 supporting the corresponding authentication since the ECS 120 supporting the corresponding authentication stores the GSMA CI certificate as the same root CI certificate as the SM-DP+ server 150, the SM-DP+ signature value is the ECS server 120 It can be verified with the corresponding CI certificate you have (steps 5b-80).
  • the SM-DP+ 150 and the ECS 120 have the GSMA Root CI certificate, and the ECS 120 is in the same GSMA certificate chain as the SM-DP+ 150, so the ECS 120 is the SM-DP+ (150) Even if there is no direct linkage with the server, the corresponding authentication can be supported.
  • 5C is a diagram illustrating an embodiment in which a communication company provides an LPA method and uses LPA and SM-DP+ authentication in a first terminal (old terminal).
  • the terminal checks the configuration information on the device change method and determines the processing in the LPA method (5c) -30 steps) can be done. Since the procedure for checking the configuration information for the device change method is the same as or similar to that described above in FIG. 4 , a detailed description thereof will be omitted.
  • the LPA1 510 may request a device change including the ICCID and device change indicator of the profile to be moved to the ES9+.AuthenticationClientRequest message (steps 5c-40).
  • the profile server 150 receiving the message may include (steps 5c-50) of inquiring whether to allow the reinstallation of the profile for the ICCID to the operator server 130, and returning the result (steps 5c-50).
  • the operator's policy on the profile may be notified to the profile server before the operator server starts steps 5c-20 or as one of the processes in steps 5c-50.
  • the SM-DP+ and the operator server 130 may process the profile order, preparation, and generation (steps 5c-60).
  • the corresponding message may be an ES2+.DownloadOrder or ES2+.ConfirmOrder or ES2+.ReleaseProfile command message.
  • the SM-DP+ 150 server may reply (steps 5c-70) including the TransferType, ServiceProviderMesage, and additionally the Activation Code as an ES9+.AuthenticationClientResponse message.
  • TransferType is an identifier for the operator's device change support method. Either it is a profile download through reissuance of a new Activation Code with the corresponding identification information, or the existing profile is deleted and the Activation Code including the information is retrieved from the terminal with Delete Notification. It can indicate whether or not to verify through the Delete Notification in part or all included in the generated Activation Code later in the profile server.
  • ServiceProviderMesage represents data for informing the user of profile processing for device change, etc.
  • the LPA1 510 may reply to the SM-DP+ 150 including the user response to the device change processing.
  • it may be an ES9+.CancelSession (End User confirmation result) (steps 5c-90) message.
  • the first terminal 300 deletes the previously installed profile when moving the profile, and generates and utilizes an Activation Code in the terminal through the corresponding deletion message (5c-95) step, step 5c-100) may be performed.
  • steps 5c-95 and 5c-100 may be provided even when a request (DeleteOldProfile) for deleting a profile is included as in steps 5a-200.
  • the first terminal 300 may delete the profile (steps 5c-95), and configure and display the QR code using all or part of the generated Delete Notification information (steps 5c-100).
  • the user 100 inputs an input to delete a profile for device change through local profile management (eg, clicks the OK button in steps 5d-40)
  • the eUICC 160 deletes the profile (steps 5c-95)
  • the result message may be delivered to the LPA1 510 .
  • the LPA1 510 may set a bit indicating DeleteProfile in the Event information (NotificationEvent) data to be received in the second control message (eg, ES10c.ListNotificationRequest message) and transmit it to the eUICC 160 .
  • the eUICC 160 may return all notification information corresponding to the DeleteProfile to the LPA1 510 .
  • the notification includes at least one of processing sequence number information (indicated by Sequence or Seq or seqNumber) and a profile ID (or iccid or ICCID).
  • the LPA1 510 may select a notification corresponding to the deleted profile or a Seq value and send a third control message (eg, ES10c.RetrieveNotification message) including the corresponding Seq value to the eUICC.
  • the eUICC 160 may deliver Notification information corresponding to the corresponding Seq value among the stored Notification information to the LPA1 510 .
  • the information included in the Notification information may include at least one of the following information.
  • the first terminal 300 can display the information including the information by encoding the QR code (steps 5c-100).
  • this QR code is information to be transmitted to the second terminal 350 for profile download and installation.
  • the second terminal 350 may finally transmit some or all of the information obtained through the QR code. It can be sent to the profile server.
  • the second terminal 350 may scan the QR code to initiate the profile download procedure (steps 5a-230).
  • GSMA SGP.22 defines v2 in GSMA SGP.22 when the Activation Code is issued (steps 5c-70) and installed from the operator in steps 5c-95 and 5c-100 without creating an Activation Code with Profile Delete Notification in steps 5a-230.
  • the profile download procedure can then be performed according to the prescribed procedure.
  • the second terminal 350 corresponds to the profile server address included in the QR code.
  • the InitiateAuthenticate message can be sent to the profile server including the eUICCChallenge value of the eUICC to install the corresponding profile.
  • the profile server can generate a Transaction ID by verifying the corresponding value, and generate and reply to the profile server's signature for the data including the Transaction ID and eUICCChallenge values.
  • the reply InitiateAuthenticate reply message may include the profile signature value and Transaction ID.
  • the second terminal 350 After receiving the InitiateAuthenticate reply message, the second terminal 350 includes Data including the ICCID included in the QR Code and the eUICC signature data of the first terminal 300 and the eUICC of the second terminal 350 for this data. You can create eUICC signature data signed by , and send it to the profile server by including it in the AuthenticateClientRequest message.
  • the profile server 150 receives the AuthenticateClientRequest message, the ICCID of the profile to be moved included in the AuthenticateClientRequest message, the signature data verification of the eUICC in which the corresponding profile of the first terminal 300 is installed, and the profile of the second terminal 350 are installed.
  • the signature data verification of the eUICC 160 of the first terminal is data including the ICCID and additional data (processing sequence number, profile deletion identifier, profile server address, deleted profile ICCID, eUICC signature value). It may be signature verification using the certificate of the eUICC 160 of the first terminal 300 .
  • the second terminal 350 receives the AuthenticateClientResponse message and, if ProfileMetadata is included, performs a process of obtaining consent to receive the profile through a UI displayed to the user, a process of requesting input of a Confirmation Code and receiving input; , it is also possible to perform some or all of the process of generating the one time public key (otpk.eUICC) of the eUICC.
  • the second terminal 350 transmits the GetBoundProfilePackage Request including the otpk.eUICC to the profile server 150
  • the profile server transmits the BoundProfilePackage including information encrypted with the encryption key generated using otpk.eUICC to the second terminal. You may reply to (350).
  • the second terminal 350 may complete all procedures by installing the profile in the eUICC of the second terminal 350 .
  • Figure 5d is a view showing a representative processing procedure for UI (User Interface) and UX (User Experience) for the eSIM device change starting from the first terminal.
  • Figure 5d is the process processing of Figures 5a to 5c implemented in the terminal This is an example of the expected user interface (UI) and user experience (UX) of the user.
  • the order indicated by the number is the processing order of the corresponding procedure
  • the order indicated by 3-A to 3-C is the processing of the corresponding procedure. It shows the timing of branching according to the device change method and the operator support method.
  • the user 100 can check the information of the SIM card currently installed in the corresponding terminal through the menu such as the terminal setting of the first terminal 300.
  • information on the profile stored in the SIM card and eUICC can be shown to the user as shown in Figure 1.
  • the user selects a profile to move (step 5d-10) or a separate menu (eg, move all), etc.
  • You can select more than one profile through A separate menu may be provided as an identifier indicating that a device change is being performed, and when entering the corresponding menu, the menu is processed differently from processing in a new terminal, or even when entering the same device change menu, the profile to be moved by the user in the terminal In the case of selecting and selecting the corresponding menu, it may be recognized and processed as the first terminal 300.
  • the LPA1 510 of the first terminal 300 to the eUICC
  • MCC+MNC can be checked with the carrier's unique identification number of the corresponding profile. You can also check the status information.
  • the terminal acquires the operator identification number of the profile to be moved by the user from the terminal without user interaction, and along with this, the screen as in No. 2 can be configured and displayed through predetermined information obtained through metadata of the corresponding profile. .
  • the terminal determines whether the communication service provider supports the device change and whether and how to change the device as described above in FIG. 4 .
  • a device change method to be used in the terminal can be determined through the metadata of the profile to be moved, the memory of the terminal, or information obtained from a separate configuration server by starting the procedure for obtaining the operator setting information for the change.
  • the first terminal 300 is connected to each other depending on whether and how the device change method is supported, such as steps 5d-30, 5d-40, and 5d-50. You can show another screen.
  • Steps 5d-30 show an example of displaying on the screen when the carrier of the selected profile does not support the device change method.
  • the terminal fetches the operator's device change setting information from the metadata or the terminal's memory, and there is no information about device change support in the corresponding information. It is also possible to handle not selectively exposing the device change menu on the menu itself in steps 5d-20. In this case, only the device change support provider may expose the corresponding device change menu.
  • the operator determines the EAP-AKA method support information and profile status information, and informs the user that the profile must be enabled to support the EAP-AKA method.
  • the terminal determines processing in the LPA method as a result of checking the information obtained in steps 5d-10 and 5d-20
  • the first terminal 300 processes authentication through SM-DP+ as shown in FIG. 5c and A carrier message preset in LPA or received through SM-DP+ may be displayed on the terminal screen.
  • a carrier message preset in LPA or received through SM-DP+ may be displayed on the terminal screen.
  • a message for processing user consent for deleting an existing profile for moving a corresponding profile may be displayed.
  • the terminal when the terminal decides to process in the ODSA method as a result of checking the information obtained in steps 5d-10 and 5d-20, the terminal triggers ODSA1 (500), the ODSA Client of the terminal, and When a device change request is requested to the ECS 120 (steps 5a-50), subscriber authentication is performed as shown in FIGS. 5a or 5b, and the subscriber is authenticated as a result of the corresponding subscriber-performed authentication, it moves as in steps 5d-50. It is possible to show the web screen of the operator for information for device movement processing of the (profile) communication service. The configuration of the corresponding web screen may vary depending on the operator.
  • the ECS 120 may select OAuth/Open ID as a subscriber authentication method as shown in steps 6a-140 of FIG. 6a.
  • the ECS 120 may select one method. For example, the EAP_ID is transmitted as an identifier for making an EAP-AKA request in the authentication method requested by the terminal, but the ECS receiving it relays with the AAA server This cannot be processed for reasons such as not supporting OAuth/Open ID, but if OAuth/Open ID is supported, the initial Http(s) Response - 302 Found may be returned including the client ID and redirection URI to request processing with OAuth/Open ID. .
  • the terminal receives a log-in page (ie, redirection URI) requesting input of the user's ID and password from the ECS 120 and displays it on the user's screen (steps 6c-70) to process subscriber authentication with the ID and password, and Then, you can move to the same screen as in step 5d-50.
  • a log-in page ie, redirection URI
  • the EAP-AKA method or the ECS&DP+ authentication method is determined through terminal setting, user selection, or ECS selection as described above, the user can complete the subscriber authentication process without any interaction in the terminal UI such as ID generation.
  • the first terminal 300 When the subscriber authentication is completed by changing the device to the LPA or ODSA method, the first terminal 300 generates an Activation Code and provides it with a method of obtaining it from the second terminal 350 (steps 5d-60). have. In step 5d-60, a method of providing this in the form of a QR code is illustrated, but Activation Code information can also be transmitted through an inter-terminal transmission protocol. Now, the user 100 may input the activation code information into the LPA2 530 of the second terminal 350 through the method provided in (steps 5d-60) (steps 5d-70 and 5d-80).
  • the second terminal 350 downloads and installs the profile as described above in steps 5a-230 and completes it, and when the corresponding information is completed, the user communicates in the first terminal 300 as in the example of steps 5d-90 You can confirm that the reinstallation of the profile has been completed.
  • the profile for which the device change processing has been completed is deleted from the profile list of the first terminal 300 according to the operator's policy of the first terminal 300 and the user's consent for the deletion processing, and the user is no longer It can be treated so that it is not exposed to
  • 6A to 6C are diagrams illustrating procedures in which a user initiates a device change in a second terminal (new terminal).
  • 6A is a diagram illustrating an embodiment in which a telecommunication company provides an ODSA method and uses OTP or OAuth/Open ID authentication.
  • the end user 100 selects a communication company for the user to change the device in the second terminal 350, and the terminal acquires the configuration information as mentioned in FIG. (Steps 6a-30) can be done. Since the detailed method for obtaining the configuration information has been described in FIG. 4 , an additional description will be omitted here.
  • the second terminal 350 creates and displays a menu as to whether there is a user-owned terminal capable of receiving SMS (steps 6a-40), and when the user 100 can receive an authentication code through the existing terminal 300
  • a subscriber phone number that is, MSISDN, which is a unique number for identifying a subscriber in a mobile network, may be input on the screen (steps 6a-60).
  • messages are exchanged between the ODSA 110 and the ECS 120 of the terminal using an HTTP(s)-based mechanism.
  • the ODSA2 520 of the second terminal 350 that has received the input transmits an authentication request Https Request message including the IMEI of the requesting terminal 350 and the MSISDN of the first terminal 300 to the ECS 120 (6a) -70 step) can be done.
  • the ECS 120 parses the message and, if there is an MSISDN value, the ECS 120 transmits the OTP to the phone number (MSISDN) provided by the End User 100 (steps 6a-90)
  • HTTP(S) 200 OK may include a cookie and transmitted to the ODSA2 520 (steps 6a-80).
  • the ODSA2 520 replies to the ECS 120 a new Get Request including the OTP parameters received and input by the End User 100 through the first terminal 300 and the Cookie received from the previous HTTP 200 OK response. (Steps 6a-110) can be done.
  • the ECS 120 may verify the received OTP, generate a new authentication token (AuthToken) in the ECS, and reply to the ODSA2 520 (steps 6a-120). Thereafter, the ODSA2 520 may request the ECS 120 to change the device including the corresponding authentication token (steps 6a-130).
  • AuthToken new authentication token
  • the ECS 120 may process the request and return a result value from the ODSA 110 .
  • the ECS 120 performs OAuth/Open ID authentication when it is indicated that EAP_ID, DP+AuthSupport, or MSISDN is not included in the received Get request, or that the corresponding or other authentication means provided by the terminal is not available. (steps 6a-140) may be requested from the terminal.
  • steps 6a-100 The following describes in more detail how to perform OAuth/Open Id authentication (steps 6a-100).
  • the ECS 120 does not have an available authentication means. Retransmitting the received GET request from the ODSA Client of the terminal to the authentication server of the Service Provider. "302 Found" can be returned as a response.
  • the URL address of the authentication point to be redirected to the corresponding "302 Found" for Open ID processing may be transmitted as the Location value of the Header.
  • the Open ID authentication server selects an authentication method (additional SMS authentication, etc.) according to the policy of the corresponding service provider to authenticate the user 100, and may return a code value as a result of this.
  • the OAuth2.0 authentication code temporary code provided for exchange with an access token
  • the terminal transmits the ECS 120 including the corresponding authentication code as a return value for "302 Found".
  • the ECS 120 may transmit the corresponding authentication code to the Open ID authentication server to request an access token and an ID token.
  • the Open ID authentication server verifies and approves the OAuth2.0 authentication code, it may return an access token and an ID token to the ECS 120 .
  • the ECS 120 may check the subscriber information of the corresponding user with the corresponding token values, resume the original GET resource request, and perform a subsequent procedure for device change. Since the procedure for updating subscriber information and creating a profile for a communication service of a subscriber between the ECS 120, SM-DP+ 150, and MNO BSS/OSS 130 has been previously described with reference to FIG. 5A, a detailed description thereof will be omitted. On the other hand, after processing the corresponding procedure, the ECS 120 receives the Activation Code from the MNO BSS/OSS 130 or SM-DP+ 150 as predetermined information required for downloading the corresponding profile and transmits it to the ODSA2 520 .
  • ODSA2(520) transmits Activation Code information to LPA2(530) through LPA API, LPA2(530) triggers profile download from SM-DP+(150) and defined in GSMA SGP.22 According to the procedure, the process of downloading and installing the profile may be completed (steps 5a-230).
  • 6B is a diagram illustrating an embodiment in which a communication company provides an LPA method and uses LPA and SM-DP+ authentication in the first terminal (old terminal).
  • the End User 100 selects a communication company through which the user performs device change in the second terminal, and the terminal acquires the configuration information as described in FIG. 4 and through the combination, changes the operator's device It can be confirmed that the method is LPA.
  • the terminal may proceed by determining the process (steps 6b-10) in the LPA method.
  • the terminal displays a message to the user to confirm whether the existing terminal is used or not on the screen of the second terminal 350 (Steps 6b-20) can be done.
  • the message on whether to use the existing terminal in steps 6b-20 may be processed differently from steps 6a-40.
  • the message in steps 6a-40 may check whether the existing terminal is used and whether it is a terminal capable of receiving SMS, but in steps 6b-20, it may be possible to process only by checking whether the existing terminal is used.
  • the second terminal 350 operates in the first terminal 300 as in steps 6b-40.
  • LPA procedures can be used to handle device change procedures. As an example, steps 5c-10 to 5c-100 of FIG.
  • 5c are displayed on the screen of the second terminal 350 so that the user 100 can proceed with the subsequent procedure in the first terminal 300 .
  • the screen of the second terminal 350 may move to the screen of the LPA2 530 for receiving the Activation Code and wait.
  • the UI/UX for the corresponding processing will be described later with reference to FIG. 6C .
  • the user 100 now processes the LPA-based device change in the first terminal 300 as described above in 5c and receives (steps 5c-70) or generates (steps 5c-100) the activation code and displays it on the screen.
  • the second terminal 350 receives the corresponding information through the corresponding displayed Activation Code scan (step 5c-110) through the camera in the LPA2 530 and connects to the SM-DP+ server address extracted from the Activation Code, downloads the profile and You can complete the installation. If the terminal receives an input that the user does not have the first terminal 300 (steps 6b-30), the terminal may display a user guide message to inquire to a communication service provider (steps 6b-50) and end all procedures.
  • Figure 6c is a view showing a representative processing procedure for UI (User Interface) and UX (User Experience) for the eSIM device change starting from the second terminal.
  • Figure 6c is the user starts the device change in the second terminal (350)
  • It is a diagram representatively showing the UI/UX implemented in Figs. 6A and 6B.
  • (4-A, 4-B) and (6-A) of the mobile phone screen , 6-B) represents a representative branching point.
  • the terminal responds to the device change as described above in FIG.
  • Operator configuration information can be collected and displayed on the screen (steps 6-30) For example, using the configuration server (option 2 and option 3 in FIG. 4) or information stored in memory (option 4 in FIG. 4) It is possible to list all carrier information obtained through the service, or extract only carriers that can provide device change in the area by combining the location information of the terminal additionally from the information, and then expose the list on the screen. For example, if the user 100 provides information on a carrier for profile movement, as in option 2 of FIG. 4 , the selected carrier name or MCC + MNC of the carrier is checked in the memory in the configuration server or terminal in the terminal.
  • step 6c-40 it is also possible to selectively display only the information of the mapped operator. In this case, check and if the corresponding operator does not support device change, although not shown in FIG. 6c, after step 6c-30, step 6c-40 or step 6c A separate guide message is displayed on the screen and the procedure can be ended without entering step -90.
  • processing in step 6c-40 the selected carrier supports ODSA-based device change.
  • the terminal provides an additional menu as to whether or not the existing terminal is possessed as in step 6c-50, and according to the user's response, the terminal The SMS-OTP authentication progress screen provided (step 6c-60) or the provider provided screen (step 6c-70) can be displayed.
  • Activation Code information is received from the communication service subscription app or web portal of the second terminal 350, and the corresponding Activation Code information is delivered to the LPA2 530 through the LPA API.
  • the LPA2 530 receiving this completes all of the profile download processing/installation it can be displayed and displayed to the user 100 as the profile to be moved has been installed as in steps 6c-80.
  • the second terminal 350 processes according to whether the user has the existing terminal 300 as in steps 6c-90. It informs that whether or not there is a change, and if the existing terminal 300 is unavailable, the operator Contact message may be displayed as in step 6c-100 and all procedures may be terminated. On the other hand, if the user responds that use is possible, an additional guide message is generated to guide the user to process in the first terminal 300, and an Activation Code such as a Scan QR code may be waiting in the procedure for input (6c) -110 steps).
  • an Activation Code such as a Scan QR code
  • the terminal displays a user guide message and terminates the device change procedure or may extend the waiting period.
  • the terminal displays a user guide message and terminates the device change procedure or may extend the waiting period.
  • the second terminal 350 receives the Activation Code as in the example of steps 6c-110.
  • the device change may be completed by processing the subsequent procedure of FIG. 5D through the menu selection.
  • FIG. 7 is a diagram illustrating a block configuration of a terminal in a wireless communication system according to an embodiment of the present invention.
  • the terminal 700 includes a transceiver 710 , a message processing unit 720 , a processor (controller) 730 , a memory 740 , and a screen display unit 750 .
  • the components of the terminal 700 are not limited to the above-described example.
  • the base station may include more or fewer components than the aforementioned components.
  • at least one configuration of the terminal 700 may be implemented in the form of one chip.
  • the transceiver 710 may perform a function for transmitting and receiving a signal through a wireless channel, such as band conversion and amplification of the signal.
  • the transceiver 710 includes an RF processing unit that up-converts a baseband signal into an RF band signal, transmits it through an antenna, and down-converts an RF band signal received through the antenna into a baseband signal, and a transmit 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.
  • the transceiver 710 may receive a signal through a wireless channel, output it to the processor 730 , and transmit a signal output from the processor 730 through a wireless channel.
  • the terminal may include a plurality of antennas.
  • the transceiver 710 may include a plurality of RF chains.
  • the transceiver 710 may perform beamforming. For beamforming, the transceiver 710 may adjust the phase and magnitude of each of signals transmitted and received through a plurality of antennas or antenna elements.
  • the baseband processing unit in the transceiver 710 may perform a conversion function between the baseband signal and the bit stream according to the physical layer standard of the system. For example, when transmitting data, the baseband processing unit generates complex symbols by encoding and modulating the transmitted bit stream. Also, upon data reception, the baseband processing unit restores the received bit stream by demodulating and decoding the baseband signal provided from the RF processing unit.
  • the baseband processing unit when data is transmitted, the baseband processing unit generates complex symbols by encoding and modulating the transmission bit stream, and after mapping the complex symbols to subcarriers, IFFT ( OFDM symbols are constructed through inverse fast Fourier transform (CP) operation and cyclic prefix (CP) insertion.
  • CP inverse fast Fourier transform
  • CP cyclic prefix
  • the baseband processing unit divides the baseband signal provided from the RF processing unit into OFDM symbol units, restores signals mapped to subcarriers through a fast Fourier transform (FFT) operation, and performs demodulation and decoding. can restore the received bit string.
  • FFT fast Fourier transform
  • the transceiver 710 may be defined as a transceiver and may include a message transceiver.
  • the message processing unit 720 may perform an operation of determining which message is the data transmitted or received through the transceiver 710 . For example, the message processing unit 720 may determine whether the received message is a radio resource control (RRC) layer control message (including a system information block (SIB)) or a user data message.
  • RRC radio resource control
  • SIB system information block
  • the message processing unit 720 may be included in the control unit 730 .
  • the controller 730 controls overall operations of the terminal 700 .
  • the control unit 730 transmits and receives signals through the message processing unit 720 .
  • the controller 730 writes and reads data in the memory 740 .
  • the controller 730 may include a communication processor (CP) that controls for communication and an application processor (AP) that controls an upper layer such as an application program.
  • CP communication processor
  • AP application processor
  • the control unit 730 requests the information from the memory 740 and the screen display unit 750 displays the information or can be received to handle additional operations.
  • the control unit 730, the message processing unit 720, and the transceiver unit 710 may control the terminal 700 to access the network of the operator selected according to the user or terminal setting.
  • the controller 730 selects a service by matching the data recorded through the memory 740 or information collected through the controller 730 and the message processing unit 720 and the transceiver 710 .
  • the terminal may perform a process of inferring information that can be referred to.
  • the control unit 730 may determine whether user consent is required for specific information stored in the terminal 700 , and display it on the screen display unit 750 .
  • the controller 730 may control the terminal 700 to perform a corresponding operation.
  • the control unit 730 may include an LPA in charge of driving and controlling the eUICC, an ODSA Client for communication service subscription and device change processing, and an LPA or ODSA Client or an application in which the two are integrated.
  • the control unit 730 obtains predetermined information necessary for device change through the control unit 730 and the memory 740, determines whether LPA or ODSA Client operation is necessary to change the communication service device, and processes the subsequent process. have.
  • control unit 730 acquires device change information that can be provided by a telecommunication service provider collected through the message processing unit 720 and the transceiver 710 , and device change additional information identified through the memory 740 of the terminal 700 . And in combination with the profile state information acquired through the control unit 730 , it is possible to control which method of the LPA or ODSA device change method is processed and which authentication method is applied to the terminal 700 .
  • the control unit 730 obtains the terminal capability information from the message processing unit 720 , the transceiver unit 710 , and the memory 740 . In the case of determining whether to support profile movement in the terminal by combining the device change method information of the operator and predetermined information input from the screen display unit 750, and support, whether to perform the role of the first terminal or the second terminal; And it can be determined whether to proceed with which device change method procedure.
  • the control unit 730 requests the memory 740 to secure whether the operator's device change support for device change, the support method and the Configuration Server address to be connected for support, the ECS or DP + server address, or the supported subscriber authentication method, etc. It is possible to control the terminal 700 to transmit and process. According to some embodiments, in addition to the terminal's authentication method support capability, device change configuration information is received from the memory 740 and the information is transmitted to the ECS server through the message processing unit 720 and the message transceiver 710 or a specific parameter is selected. Thus, information may be transmitted through the message processing unit 720 and the message transceiving unit 710 . In addition, if the processor 740 determines that the terminal cannot provide the EAP-AKA function at the time (eg, when the profile is inactive), the terminal 700 to limit the operation for EAP-AKA processing. can be controlled.
  • the memory 740 stores data such as a basic program, an application program, and setting information for the operation of the terminal 700 .
  • the memory 740 may include UICC, eUICC, iSSP, and iUICC, which are hardware security modules built into the terminal.
  • the memory 740 is composed of a storage medium or a combination of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD, and is stored such as Transfer Configuration according to the request of the controller 730 . data can be provided.
  • the memory 740 may be integrated with the controller 730 and a system on chip (SoC).
  • SoC system on chip
  • the screen display unit 750 displays information processed/processed by the control unit 730, a process for an operation performed by the terminal 700 through processing of the control unit 730, or consent to an event requesting the user to perform, etc. can be displayed.
  • stored profile information, a menu for moving between profile devices, and input and input results for an activation code may be displayed in response to the user.
  • the LPA or ODSA application, or an application in which the two are integrated may include a screen display unit 750 and a control unit 730 . Of course, it is not limited to the above example.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 발명은 기기 간의 프로파일 이동 시 사용자가 어떤 단말에서 기기 변경을 시작하더라도 사용자의 기기 변경 시작 단말과 사업자 지원 방식을 조합하여 편리한 기기간 통신서비스 이동이 가능하도록 하기 위한 방법 및 장치를 제안한다. 특히, 본 발명의 일 실시 예에 따르면, 제1 단말에 설치된 제1 프로파일을 이동시키는 입력이 수신 되는 단계, 제1 단말에서 통신사업자의 기기 변경 방식을 프로파일 메타데이터 또는 Configuration Server 또는 단말 메모리로부터 확인하여 ODSA 방식임을 결정하는 단계, ECS가 기기 변경을 위한 가입자 인증 방식으로 ECS/DP+인증 방식을 결정하여, ECS 생성 Nonce, SM-DP+주소와 함께 단말에 송신하는 단계, ECS가 제 1 단말로부터 SM-DP+에서 처리한 인증 결과 데이터를 회신 받아서 해당 데이터에 포함된 ECS 생성하여 전달한 Nonce와 SM-DP+서버의 서명 데이터를 GSMA Root CI 인증서를 통해서 검증하는 단계, 검증되면 Activation Code를 단말에 제공하고 제 1 단말의 화면에 QR 코드로 Display하는 단계를 포함하는 방법을 제공할 수 있다.

Description

이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치
본 발명은 무선 통신 시스템에서 하나의 기기에 설치된 통신 시스템에 접속하기 위한 접속 정보를 다른 기기에 이전 재설치 하는 방법 및 장치에 관한 것이다.
4G 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후 (Beyond 4G Network) 통신 시스템 또는 LTE(Long Term Evolution) 시스템 이후 (Post LTE) 이후의 시스템이라 불리어지고 있다. 높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역 (예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO: FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나 (large scale antenna) 기술들이 논의되고 있다. 또한 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀 (advanced small cell), 클라우드 무선 액세스 네트워크 (cloud radio access network: cloud RAN), 초고밀도 네트워크 (ultra-dense network), 기기 간 통신 (Device to Device communication: D2D), 무선 백홀 (wireless backhaul), 이동 네트워크 (moving network), 협력 통신 (cooperative communication), CoMP (Coordinated Multi-Points), 및 수신 간섭제거 (interference cancellation) 등의 기술 개발이 이루어지고 있다. 이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation: ACM) 방식인 FQAM (Hybrid FSK and QAM Modulation) 및 SWSC (Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(non orthogonal multiple access), 및 SCMA(sparse code multiple access) 등이 개발되고 있다.
한편, 인터넷은 인간이 정보를 생성하고 소비하는 인간 중심의 연결 망에서, 사물 등 분산된 구성 요소들 간에 정보를 주고 받아 처리하는 IoT(Internet of Things, 사물인터넷) 망으로 진화하고 있다. 클라우드 서버 등과의 연결을 통한 빅데이터(Big data) 처리 기술 등이 IoT 기술에 결합된 IoE (Internet of Everything) 기술도 대두되고 있다. IoT를 구현하기 위해서, 센싱 기술, 유무선 통신 및 네트워크 인프라, 서비스 인터페이스 기술, 및 보안 기술과 같은 기술 요소 들이 요구되어, 최근에는 사물간의 연결을 위한 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication)등의 기술이 연구되고 있다. IoT 환경에서는 연결된 사물들에서 생성된 데이터를 수집, 분석하여 인간의 삶에 새로운 가치를 창출하는 지능형 IT(Internet Technology) 서비스가 제공될 수 있다. IoT는 기존의 IT(information technology)기술과 다양한 산업 간의 융합 및 복합을 통하여 스마트홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 스마트 그리드, 헬스 케어, 스마트 가전, 첨단의료서비스 등의 분야에 응용될 수 있다.
이에, 기존 4G 및 5G 통신 시스템을 IoT 망에 적용하기 위한 다양한 시도들이 이루어지고 있다. 예를 들어, 센서 네트워크(sensor network), 사물 통신(Machine to Machine, M2M), MTC(Machine Type Communication) 등의 기술이 4G 및 5G 통신 기술이 빔 포밍, MIMO, 및 어레이 안테나 등의 기법에 의해 구현되고 있는 것이다.
UICC (Universal Integrated Circuit Card)는 이동 통신 단말기 등에 삽입하여 사용하는 스마트 카드(smart card)이고 UICC 카드라고도 부른다. 상기 UICC에 이동통신사업자의 망에 접속하기 위한 접속 제어 모듈이 포함될 수 있다. 이러한 접속 제어 모듈의 예로는 USIM(Universal Subscriber Identity Module), SIM(Subscriber Identity Module), ISIM(IP Multimedia Service Identity Module) 등이 있다. USIM이 포함된 UICC를 통상 USIM 카드라고 부르기도 한다. 마찬가지로 SIM 모듈이 포함된 UICC를 통상적으로 SIM 카드라고 부르기도 한다. 본 발명의 이후 설명에서 SIM 카드라 함은 UICC 카드, USIM 카드, ISIM이 포함된 UICC 등을 포함하는 통상의 의미로 사용하도록 하겠다. 즉 SIM 카드라 하여도 그 기술적 적용이 USIM 카드 또는 ISIM 카드 또는 일반적인 UICC 카드에도 동일하게 적용될 수 있다.
상기 SIM 카드는 이동 통신 가입자의 개인정보를 저장하고, 이동통신 네트워크에 접속 시 가입자 인증 및 트래픽(traffic) 보안 키(key) 생성을 수행하여 안전한 이동통신 이용을 가능하게 한다.
상기 SIM 카드는 일반적으로 카드 제조 시 특정 이동통신 사업자의 요청에 의해 해당 사업자를 위한 전용 카드로 제조되며, 해당 사업자의 네트워크 접속을 위한 인증 정보, 예를 들어, USIM(Universal Subscriber Identity Module) 어플리케이션 및 IMSI(International Mobile Subscriber Identity), K 값, OPc 값 등이 사전에 카드에 탑재되어 출고된다. 따라서 제조된 상기 SIM 카드는 해당 이동통신 사업자가 납품 받아 가입자에게 제공되며, 이후 필요시에는 OTA(Over The Air) 등의 기술을 활용하여 상기 UICC 내 어플리케이션의 설치, 수정, 삭제 등의 관리도 수행할 수 있다. 가입자는 소유한 이동통신 단말기에 상기 UICC 카드를 삽입하여 해당 이동통신 사업자의 네트워크 및 응용 서비스의 이용이 가능하며, 단말기 교체 시 상기 UICC 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 상기 UICC 카드에 저장된 인증정보, 이동통신 전화번호, 개인 전화번호부 등을 새로운 단말기에서 그대로 사용이 가능하다.
그러나, 상기 SIM카드는 이동통신 단말기 사용자가 다른 이동통신사의 서비스를 제공받는데 있어 불편한 점이 있다. 이동통신 단말기 사용자는 이동통신사업자로부터 서비스를 받기 위해 SIM 카드를 물리적으로 획득해야 되는 불편함이 있다. 예를 들면, 다른 나라로 여행을 했을 때 현지 이동통신 서비스를 받기 위해서는 현지 SIM 카드를 구해야 하는 불편함이 있다. 로밍 서비스의 경우 상기 불편함을 어느 정도 해결해 주지만, 비싼 요금 및 통신사간 계약이 되어 있지 않은 경우 서비스를 받을 수 없는 문제도 있다.
한편, UICC 카드에 상기 SIM 모듈을 원격으로 다운로드 받아서 설치할 경우, 이러한 불편함을 상당부분 해결할 수 있다. 즉 사용자가 원하는 시점에 사용하고자 하는 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드 받을 수 있다. 이러한 UICC 카드는 또한 복수개의 SIM 모듈을 다운로드 받아서 설치하고 그 중의 한 개의 SIM 모듈만을 선택하여 사용할 수 있다. 이러한 UICC 카드는 단말기에 고정하거나 고정하지 않을 수 있다. 특히 단말에 고정하여 사용하는 UICC를 eUICC(embedded UICC)라고 하는데, 통상적으로 eUICC는 단말에 고정하여 사용하고, 원격으로 SIM 모듈을 다운로드 받아서 선택할 수 있는 UICC 카드를 의미한다. 본 발명에서는 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드를 eUICC로 통칭하겠다. 즉 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하거나 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용하겠다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 eSIM 프로파일 이라는 용어로 사용하겠다. 즉, 원격으로 SIM 모듈을 다운로드 받아 선택할 수 있는 UICC 카드 중 단말에 고정하는 UICC 카드 및 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용한다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 프로파일(Profile) 이라는 용어로 사용하겠다.
한편, 이동통신 서비스의 SIM 모듈을 UICC 카드에 다운로드하여 통신 서비스를 개통할 수 있는 이점을 충분히 활용하고자, 통신사업자들은 단말에서 On Device Service Activation 서비스를 도입하고 있다. On Device Service Activation은 사용자가 단말기에서 웹 포탈 또는 앱을 통해서 신규 통신 서비스 가입 및 개통, 기기 변경 시 통신서비스 이전 설치 개통 등을 가능하게 하는 솔루션을 통칭한다. On Device Service Activation 서비스는 ODSA 또는 ODA라는 용어로 혼용될 수 있다. 또한 ODSA를 지원하기 위해 단말에 설치가 필요한 모듈을 ODSA Client라고 하는데, ODSA 또는 ODA라는 용어와 혼용되어 사용할 수 있다.
서비스 사업자는 단말 또는 특정 서비스를 사용하고자 하는 가입자가 해당 서비스를 접근 또는 사용할 권한이 있는지를 판단하기 위해서 Entitlement Configuration Server(ECS)를 도입할 수 있다. ECS는 요청 단말에서 통신 기반 서비스 제공이 가능한지를 해당 단말 사용자의 가입자 정보 및 단말의 네트워크 상태를 고려해 판단하고, 가능하다고 판단한 경우, 해당 단말에서 통신 기반 서비스를 제공하기 위한 소정의 정보를 단말에 전송할 수 있다. ECS는 현재 VoLTE(Voice over LTE), VoWiFi(Voice over Wi-Fi), ODSA(On Device Service Activation) 등 서비스를 위해 도입되고 있다. ODSA에서 ECS는 단말의 ODSA Client가 접근하는 사업자의 ODSA Gateway 서버로의 역할을 수행하며, ODSA Client와 ECS간 메시지 프로토콜은 GSMA(GSM Association, 통신사업자연합)에서 TS.43 규격에 정의하고 있다. ECS 주소는 다양하게 표기될 수 있으나, 표기의 한 예로는 FQDN(Full Qualified Domain Name)으로 통신사업자의 고유 식별 번호인 MCC와 MNC 조합에 따른 ase.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org 와 같이 생성하여 사용할 수 있다. <MNC>와 <MCC>는 각 해당 MNC와 MCC의 decimal format으로 만약 해당 정보가 2자리 수인 경우에 0을 맨 앞에 추가하여 3자리 수로 사용할 수도 있다.
단말기 교체 시, 통신 서비스 가입자는 상기 SIM 카드를 기존 단말기에서 새로운 단말기로 이동 삽입함으로써 상기 UICC 카드에 저장된 인증정보를 이용하여 이동통신망 접속을 그대로 사용할 수 있다. 그러나 상기 eUICC를 탑재한 단말의 경우, 다운로드된 프로파일은 해당 eUICC 내부에서만 복호화되어 설치되는 것으로, 설치된 후에는 다시 단말 외부로 추출될 수 없어 새 단말에서 프로파일 다운로드 및 (재) 설치가 필요하다.
본 발명을 개시하는 시점에 통신사업자들은 eUICC 탑재 단말기의 기기 변경 시 통신서비스를 이전 설치를 제공하고자 LPA와 SM-DP+를 사용하는 방식과 ODSA Client와 ECS를 사용하는 방식을 GSMA 표준화하고 있으며, 통신사업자들은 해당 방식 중 하나를 선택하여 통신서비스 이전 설치를 지원할 것으로 예상된다. 하지만, 현재 각 방식에 따라 기존 단말(프로파일이 설치되어 있는 기존 단말) 또는 변경할 신규 단말에서만 지원 가능하여 사용자의 시작 단말과 사업자의 지원 방식의 조합에 따라서, 사용자가 통신서비스를 이전 설치하지 못한다는 불편함이 있다. 이는 도 2에서 추가적으로 설명하겠다.
한편 기존에 이동통신사는 SIM 카드 분실 시, 가입자의 신원 또는 ID 인증 과정을 확인하여, SIM카드를 재발급하는 절차를 제공하고 있으며, eUICC 탑재 단말기의 기기 교체 시 신규 단말기의 eUICC로 프로파일을 다운로드하는 용도에 적용이 가능하다. 하지만, 이러한 과정은 통상 가입자가 오프라인 영업점에 방문한 경우에만 처리해 주거나 온라인으로 처리할 경우에는 오프라인 영업점 대비 더욱 엄격한 신원 인증 또는 ID 확인 과정이 요구된다. 단말기 변경 시 가입자는 프로파일을 신규 단말기에 재설치를 위해서, 이러한 엄격한 신원 인증 또는 ID 확인 과정을 거쳐야 하는 불편이 있다. 가입자가 기존 단말기를 보유하고 있는 경우, 통신사업자는 통신서비스에서 가입자 인증을 위해 통신사업자가 보편적으로 사용하는 방식으로 EAP-AKA 방식을 사용하여 가입자 인증을 할 수도 있으나, 이는 SIM 모듈이 활성화되어 SIM 정보에 접근이 가능한 상태여야 인증이 가능하며 SIM 모듈이 비활성화 되어 있는 경우에 사용할 수 없다.
본 발명이 이루고자 하는 기술적 과제는, 통신 시스템에서 기존 단말에서 사용하던 통신 서비스를 교체된 신규 단말로 이전 재 설치/개통하여 사용하게 하는 것이다. 이를 위해, 기존 단말의 eUICC에 저장된 프로파일에 대응되는 신규 eUICC 프로파일을 온라인으로 다운로드 하여 설치할 때, 사용자 시작 단말과 사업자 지원 방식의 조합을 고려해 기기 변경 방식을 선택하는 것이다. 특히, 기존 단말에서의 ODSA 방식 지원, 신규 단말에서의 LPA 방식 지원을 지원하는 방법을 포함해 제공하고자 한다. 또한, SIM 모듈이 비 활성화 되어 있는 경우에도 제공 가능한, 별도의 가입자 ID 인증이 필요 없는 다운로드 방안을 제공하고자 한다.
본 발명의 실시 예에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
상기와 같은 문제점을 해결하기 위한 본 발명은 무선 통신 시스템에서 단말에 의해 수행되는 방법에 있어서, 기기 변경과 관련된 정보를 획득하는 단계; 상기 기기 변경과 관련된 정보를 기반으로, 기기 변경 방식을 결정하는 단계; 서버로, 상기 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 전송하는 단계로서, 상기 서버는 상기 기기 변경과 관련된 정보를 기반으로 식별되는, 상기 서버로 제 1 메시지를 전송하는 단계; 및 상기 서버로부터, 상기 서버에 의해 상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로 결정된 인증 방식을 포함하는 제2 메시지를 수신하는 단계를 포함하는 것을 특징으로 한다.
일부의 예들에서는, 상기 기기 변경 방식은 ODSA(On Device Service Activation) 방식 또는 LPA(Local Profile Assistant) 방식 중 적어도 하나인 것을 특징으로 한다.
일부의 예들에서는, 상기 기기 변경과 관련된 정보는 제2 서버에 의해 수신된 정보, 상기 단말에 미리 저장된 정보, 프로파일 메타 데이터 정보 중 적어도 하나를 통하여 획득되는 것을 특징으로 한다.
일부의 예들에서는, 상기 인증 방식은 SM-DP+(Subscription Manager Data Preparation plus)를 사용하는 인증, EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement) 인증, ECS(Entitlement Configuration Server) 와 상기 SM-DP+를 사용하는 인증, OAuth/Open ID 프로토콜 기반 인증 중 적어도 하나인 것을 특징으로 한다.
본 발명의 다른 예에서는, 무선 통신 시스템에서 서버에 의해 수행되는 방법에 있어서, 단말로부터, 상기 단말에 의해 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 수신하는 단계; 상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로, 처리 가능한 인증 방식을 결정하는 단계; 및 상기 단말로, 상기 결정된 인증 방식을 포함하는 제2 메시지를 전송하는 단계를 포함하고, 상기 기기 변경 방식은 상기 단말에 의해 획득된 기기 변경과 관련된 정보를 기반으로 결정되는 것을 특징으로 한다.
본 발명의 또 다른 예에서는, 단말에 있어서, 적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및 상기 송수신부와 결합된 제어부를 포함하고, 상기 제어부는: 기기 변경과 관련된 정보를 획득하고, 상기 기기 변경과 관련된 정보를 기반으로, 기기 변경 방식을 결정하고, 서버로, 상기 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 전송하고, 상기 서버는 상기 기기 변경과 관련된 정보를 기반으로 식별되고, 및 상기 서버로부터, 상기 서버에 의해 상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로 결정된 인증 방식을 포함하는 제2 메시지를 수신하도록 구성되는 것을 특징으로 한다.
본 발명의 또 다른 예에서는, 서버에 있어서, 적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및 상기 송수신부와 결합된 제어부를 포함하고, 상기 제어부는: 단말로부터, 상기 단말에 의해 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 수신하고, 상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로, 처리 가능한 인증 방식을 결정하고, 및 상기 단말로, 상기 결정된 인증 방식을 포함하는 제2 메시지를 전송하도록 구성되고, 상기 기기 변경 방식은 상기 단말에 의해 획득된 기기 변경과 관련된 정보를 기반으로 결정되는 것을 특징으로 한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 다음 제1 단말의 방법은, 설치된 제1 프로파일을 이동시키는 입력이 수신되는 단계, 통신사업자의 기기변경 지원 여부 및 지원 방식 정보를 획득하는 단계, 프로파일 서버 인증 방식 지원을 포함한 가입자 인증 방식 선택에 필요한 소정의 정보를 ECS에 전송하는 단계, ECS로부터 프로파일 서버로 가입자 인증 처리에 대한 ECS 요청 임을 증빙하는 ECS 생성 데이터와 프로파일 서버 주소를 획득하는 단계, 프로파일 서버를 통해 가입자 인증을 수행하고 이를 ECS에 회신하는 단계를 포함한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 단말의 방법은, 사용자 시작 단말과 사업자 지원 방식을 확인하여 단말에서 사용할 사업자 지원 방식을 결정하는 단계, 단말에서 지원 가능한 사용자 인증 방식을 수집하여 ECS 서버에 송신하는 단계를 포함한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 ECS의 방법은, 제 1단말이 제공하는 가능한 인증 방식 정보를 참조하여 인증 방식을 선택하는 단계, 선택된 인증 방식에 따라 인증에 활용할 소정의 데이터를 생성하여 단말에 전송하는 단계, 단말로부터 수신한 사용자의 인증 결과를 검증하는 단계, 검증 결과에 따라 기기 변경에 필요한 일련의 절차를 처리하고 프로파일 다운로드에 필요한 소정의 정보를 제 1 단말에 전송하는 단계를 포함한다.
상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 프로파일 서버의 방법은, ECS에서 생성한 데이터가 포함된 가입자 인증 요청을 제 1단말 로부터 수신하는 단계, 가입자 인증을 수행하여 제 1 단말에 회신하는 단계를 포함하다.
상기와 같은 문제점을 해결하기 위한 본 발명의 일 실시 예에 따른 제 2 단말의 방법은, ECS가 제 1 단말에 전송한 소정의 정보를 제 1 단말로부터 획득하는 단계, 해당 소정의 정보를 프로파일 서버에 전송하여 프로파일을 수신하여 설치하는 단계를 포함한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 실시 예에 따르면, 통신사업자의 eSIM 단말의 기기 변경 시 통신서비스를 이전 설치하는 방법에 있어서, 통신사업자의 기기 변경 지원 방식과 사용자의 기기 변경 시작 단말의 조합을 고려하여 사용자에게 Seamless한 UI/UX를 제공해 줄 수 있다. 또한, 사용자가 eUICC를 탑재한 단말의 단말 교체 시, 사용자의 신원 인증 정보에 대한 추가적인 정보 입력 없이, 단말과 ECS가 USIM 또는 프로파일 서버와의 인증 정보를 활용하여 편리하게 기기 간 프로파일을 이동할 수 있다. 특히, USIM 인증이 불가능한 경우에도 사용자에게 ID 입력을 요구하지 않고, 프로파일 서버와의 인증 정보를 활용하여 편리하게 기기 간 프로파일을 이동할 수 있다. 또한, 통신 사업자는 필요에 따라 기존 단말에 설치된 프로파일을 삭제 처리하여 추후 프로파일을 재사용할 수 있다.
도 1은 본 발명의 실시 예가 적용되는 통신 시스템의 구성을 나타낸 도면이다.
도 2는 eSIM 기기 변경에 대한 통신사의 통신 서비스 이동 지원 방식과 사용자 시작 단말의 조합에 따른 기기 변경 지원 여부를 도시하는 도면이다.
도 3은 eSIM 기기 변경 절차 처리 절차 및 단말의 판단 기준을 나타낸 도면이다.
도 4는 단말에서 사업자의 eSIM 기기 변경 설정 정보를 획득하는 방법을 도시하는 도면이다.
도 5a는 통신사가 ODSA 방식을 제공하며 EAP-AKA 인증을 사용하는 실시 예를 나타내는 도면이다.
도 5b는 통신사가 ODSA 방식을 제공하며 ECS/SM-DP+ 인증을 사용하는 실시 예를 나타내는 도면이다.
도 5c는 통신사가 LPA 방식을 제공하며 사용자가 기기 변경을 시작 시 UI(User Interface) 및 UX(User Experience)에 대한 절차를 나타낸 실시 예를 나타내는 도면이다.
도 5d는 제 1단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience)에 대한 대표적인 처리 절차를 나타낸 도면이다.
도 6a는 통신사가 ODSA 방식을 제공하며 OTP 또는 OAuth/Open ID 인증을 사용하는 실시 예를 나타내는 도면이다.
도 6b는 통신사가 LPA 방식을 제공하며 제 1단말(구 단말)에서 LPA와 SM-DP+인증을 사용하는 실시 예를 나타내는 도면이다.
도 6c는 제 2단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience)에 대한 대표적인 처리 절차를 나타낸 도면이다.
도 7은 본 발명의 실시 예에 따른 무선 통신 시스템에서 단말의 블록 구성을 도시하는 도면이다.
이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명하기에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성 요소에는 동일한 참조 번호를 부여하였다. 본 개시에 따른 기술적 사상의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다. 또한 본 개시를 설명함에 있어서 관련된 기능 또는 구성에 대한 구체적인 설명이 본 개시에 따른 기술적 사상의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
이하, 기지국은 단말의 자원할당을 수행하는 주체로서, gNode B, eNode B, Node B, BS(Base Station), 무선 접속 유닛, 기지국 제어기, 또는 네트워크 상의 노드 중 적어도 하나일 수 있다. 단말은 UE(User Equipment), MS(Mobile Station), 셀룰러폰, 스마트폰, 컴퓨터, 또는 통신기능을 수행할 수 있는 멀티미디어시스템을 포함할 수 있다. 본 개시에서 하향링크(Downlink; DL)는 기지국이 단말에게 전송하는 신호의 무선 전송 경로이고, 상향링크는(Uplink; UL)는 단말이 기국에게 전송하는 신호의 무선 전송경로를 의미한다. 또한, 이하에서 LTE 혹은 LTE-A 시스템을 일 예로서 설명할 수도 있지만, 유사한 기술적 배경 또는 채널형태를 갖는 다른 통신시스템에도 본 개시의 실시예가 적용될 수 있다. 예를 들어 LTE-A 이후에 개발되는 5세대 이동통신 기술(5G, new radio, NR)이 본 개시의 실시예가 적용될 수 있는 시스템에 포함될 수 있으며, 이하의 5G는 기존의 LTE, LTE-A 및 유사한 다른 서비스를 포함하는 개념일 수도 있다. 또한, 본 개시는 숙련된 기술적 지식을 가진 자의 판단으로써 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 일부 변형을 통해 다른 통신시스템에도 적용될 수 있다. 이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다.
이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예를 들면, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다. 이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA(Field Programmable Gate Array) 또는 ASIC(Application Specific Integrated Circuit)과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행할 수 있다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다. 또한 실시예에서 '~부'는 하나 이상의 프로세서를 포함할 수 있다.
먼저, 본 명세서에서 사용되는 용어에 대해서 정의한다.
본 명세서에서 UICC는 이동통신 단말기에 삽입하여 사용하는 스마트카드로서 이동통신 가입자의 네트워크 접속 인증 정보, 전화번호부, SMS와 같은 개인정보가 저장되어 GSM, WCDMA, LTE, 5G 등과 같은 이동통신 시스템에 접속 시 가입자 인증 및 트래픽 보안 키 생성을 수행하여 안전한 이동통신 이용을 가능케 하는 칩을 의미한다. UICC에는 가입자가 접속하는 이동통신 네트워크의 종류에 따라 SIM(Subscriber Identification Module), USIM(Universal SIM), ISIM(IP Multimedia SIM)등의 통신 어플리케이션이 탑재되며, 또한 전자지갑, 티켓팅, 전자여권 등과 같은 다양한 응용 어플리케이션의 탑재를 위한 상위 레벨의 보안 기능을 제공할 수 있다.
본 명세서에서 eUICC(embedded UICC)는 단말에 삽입 및 탈거가 가능한 착탈식 이 아닌 단말에 내장된 칩 형태의 보안 모듈이다. eUICC는 OTA(Over The Air)기술을 이용하여 프로파일을 다운받아 설치할 수 있다. eUICC는 프로파일 다운로드 및 설치가 가능한 UICC로 명명할 수 있다.
본 명세서에서 eUICC에 OTA 기술을 이용하여 프로파일을 다운받아 설치하는 방법은 단말에 삽입 및 탈거가 가능한 착탈식 UICC에도 적용될 수 있다. 즉, 본 발명의 실시 예에는 OTA 기술을 이용하여 프로파일을 다운 받아 설치 가능한 UICC에 적용될 수 있다.
본 명세서에서 용어 UICC는 SIM과 혼용될 수 있고, 용어 eUICC는 eSIM과 혼용될 수 있다.
본 명세서에서 프로파일(Profile)은 UICC내에 저장되는 어플리케이션, 파일시스템, 인증키 값 등을 소프트웨어 형태로 패키징 한 것을 의미할 수 있다. 또한, 프로파일을 접속정보로 명명할 수도 있다.
본 명세서에서 USIM Profile은 프로파일과 동일한 의미 또는 프로파일 내 USIM 어플리케이션에 포함된 정보를 소프트웨어 형태로 패키징 한 것을 의미할 수 있다.
본 명세서에서 프로파일서버는 프로파일을 생성하거나, 생성된 프로파일을 암호화 하거나, 프로파일 원격관리 명령어를 생성하거나, 생성된 프로파일 원격관리 명령어를 암호화하는 기능을 포함하고, SM-DP(Subscription Manager Data Preparation), SM-DP+(Subscription Manager Data Preparation plus), SM-SR(Subscription Manager Secure Routing)으로 표현될 수 있다.
본 명세서에서 사용하는 용어 '단말' 또는 '기기'는 이동국(MS), 사용자 장비(UE; User Equipment), 사용자 터미널(UT; User Terminal), 무선 터미널, 액세스 터미널(AT), 터미널, 가입자 유닛(Subscriber Unit), 가입자 스테이션(SS; Subscriber Station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; Wireless Transmit/Receive Unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(Machine to Machine) 단말, MTC(Machine Type Communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자장치 또는 단순히 디바이스라 지칭할 수도 있다.
본 명세서에서 상기 단말 또는 기기는 UICC 또는 eUICC를 제어하도록 단말 또는 기기 내에 설치된 소프트웨어 또는 애플리케이션을 포함할 수 있다. 상기 소프트웨어 또는 애플리케이션은, 예를 들어 Local Profile Assistant(LPA)라 지칭할 수 있다. 본 명세서에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC의 고유 식별자일 수 있고, EID로 지칭될 수 있다.
본 명세서에서 APDU(application protocol data unit)는 단말 또는 기기내의 Controller가 eUICC와 연동하기 위한 메시지 일수 있다.
본 명세서에서 프로파일 패키지(Profile Package)는 프로파일과 혼용되거나 특정 프로파일의 데이터 객체(data object)를 나타내는 용어로 사용될 수 있으며, Profile TLV 또는 프로파일 패키지 TLV(Profile Package TLV)로 명명될 수 있다. 프로파일 식별자는, 프로파일의 고유 식별 번호로 ICCID(Integrated Circuit Card Identifier)로 지칭될 수 있다. 프로파일 패키지가 암호화 파라미터를 이용해 암호화된 경우 보호된 프로파일 패키지(Protected Profile Package(PPP)) 또는 보호된 프로파일 패키지 TLV(PPP TLV)로 명명될 수 있다. 프로파일 패키지가 특정 eUICC에 의해서만 복호화 가능한 암호화 파라미터를 이용해 암호화된 경우 묶인 프로파일 패키지(Bound Profile Package(BPP)) 또는 묶인 프로파일 패키지 TLV(BPP TLV)로 명명될 수 있다. 프로파일 패키지 TLV는 TLV(Tag, Length, Value) 형식으로 프로파일을 구성하는 정보를 표현하는 데이터 세트(set) 일 수 있다.
본 명세서에서 AKA는 인증 및 키 합의(Authentication and Key agreement)로, 3GPP 및 3GPP2망에 접속하기 위한 인증 알고리즘을 나타낼 수 있다. K 는 AKA 인증 알고리즘에 사용되는 eUICC에 저장되는 암호키 값이며, 본 명세서에서 OPc는 AKA 인증 알고리즘에 사용되는 eUICC에 저장될 수 있는 파라미터 값이다.
본 명세서에서 NAA는 네트워크 접속 어플리케이션(Network Access Application) 응용프로그램으로, UICC 또는 eUICC에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망접속 모듈일 수 있다.
본 명세서에서 ECS는 Entitlement Configuration Server, 가입증명서버, 가입서버, 자격증명서버, Entitlement Server(ES)와 혼용되어 사용될 수 있고 ODSA Client는 ODSA, ODA와 혼용되어 사용될 수 있다.
본 발명에서 End-user, 사용자, 가입자, 서비스 가입자, user는 기기 변경을 수행하는 자를 의미하며 혼용되어 사용될 수 있다.
본 발명에서 eSIM Transfer, 기기 변경, subscription Transfer, 통신서비스의 단말간 가입 정보 이동, 기기변경 시 프로파일 이동은 eUICC를 탑재한, 제 1단말에서 제 2단말로 기기 변경 시 USIM카드 이동에 상응하는 프로파일 이동을 의미하며, 혼용되어 사용될 수 있다. 이는 문맥에 따라 해석되어야 한다.
그리고, 본 발명을 설명함에 있어서, 관련된 공지기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.
이하에서는 도면들을 통해 제안하는 실시 예를 설명한다.
도 1은 본 발명의 실시 예가 적용되는 통신 시스템의 구성을 나타낸 도면이다.
도 1에서 사선으로 표기된 부분은 GSMA TS.43에 정의된 표준 Entity 및 Interface 를 나타내며, 음영으로 표기된 부분은 GSMA.22에 정의된 표준 Entity 및 Interface를 나타낸다. 본 발명에서 End User(100)는 기기 간 프로파일 이동을 수행하는 사용자이며, Device(105)는 무선통신서비스가 가능한 단말 또는 기기를 의미한다. 해당 Device(105)는 LPA(140), eUICC(160)을 포함하며, ECS와의 Entitlement Configuration 교환을 지원하는 경우에, ODSA Client(110)을 포함한다. LPA(140)와 SM-DP+(150)는 GSMA SGP.22에 정의된 표준 Entity로써, LPA는 eUICC에 프로파일을 다운로드 및 설치, 기기 변경 시 프로파일을 타 프로파일로 이동에 관여할 수 있다. 단말(105)은 사용자(100)로부터 프로파일 이동에 대한 Input을 ODSA Client(110) 또는 LPA(140)로부터 입력 받아 단말에서 기기 변경 절차를 시작할 수 있다. 이 때, 단말은 사전에 정의된 기기변경을 지원 여부 및 처리 방식 등에 대한 소정의 정보가 없는 경우에, 해당 정보를 획득하기 위해 별도 서버인 Configuration Server(170)에 접속하여 단말의 기기 변경 방식 결정에 필요한 전체 또는 일부 정보를 획득하여 활용할 수 있다. 해당 Configuration Server(170)는 단독 또는 통신사업자의 BSS/OSS(130)의 하나로 구현될 수도 있다. MNO(Mobile Network Operator) BSS/OSS(130)는 통신사업자가 통신서비스의 운영 및 처리를 위한 서버 시스템으로 통신사의 Back-end System이라고 불리기도 하며, 본 발명의 일부 설명에서 MNO BSS/OSS(130)와 통신사업자가 혼용해서 사용될 수 있다. MNO BSS/OSS는 프로파일 서버인 SM-DP+(150)서버 또는 서비스 가입 관리를 처리하는 서버인 ECS(120)와 정보 교환을 통해서 eUICC 기기에서의 통신서비스의 가입 및 해지, 기기 변경에 대한 처리를 수행할 수 있다. ECS(120)와 SM-DP+(150)서버는 통신사업자의 Back-end 시스템과 연동되고 통신 서비스의 Back-end 시스템과 독립 또는 Back-end 시스템의 일부로 구현되어 있을 수도 있다. ODSA Client(110)와 LPA(140)는 하나의 애플리케이션에 통합 구현 또는 개별적으로 구현될 수 있다. 도 1에서 Configuration Server(170)은 ODSA Client(110)와 연결된 것으로 표기되어 있으나, 이에 한정하지 아니하고 단말의 다른 애플리케이션 또는 LPA에서도 직접 Configuration Server(170)에 접속하여 기기 변경 처리를 위한 정보를 획득해 이후 절차를 처리할 수 있다.
도 2는 eSIM 기기 변경에 대한 통신사의 통신 서비스 이동 지원 방식과 사용자 시작 단말의 조합에 따른 기기 변경 지원 여부를 도시하는 도면이다.
전술한 바와 같이 eUICC 단말(200)의 기기 변경 시 통신 서비스를 이전 설치하는 방법에 있어서 2가지 방식이 혼재할 것으로 보이며, 사업자는 이 중 한 가지 방식을 선택하여 지원할 것으로 예상된다. As-Is 표(200)는 본 발명을 개시하는 시점에서 사용자 시작 단말과 사업자 지원 방식의 조합을 고려하여 제공 가능한 방법을 나타낸 것이다. 사업자 지원 방식이 ODSA 방식이며 제 1단말(300)에서 사용자가 기기변경을 시작하는 것에 대하여 사업자가 제공하지 않고 있으며, 해당 처리 절차에 대해서도 TS. 43 표준에 정의된 바가 없다. 한편, 사업자 지원 방식이 LPA 방식이며 제 2단말(350)에서 사용자가 기기변경을 시작하는 경우에, 해당 제 2단말(350)에서 이를 처리하기 위한 방법이 없다. LPA 방식은 해당 단말에 기 설치되어 이동하고자 하는 프로파일의 ICCID 정보를 사용하므로, 제 2단말(350)에서 현재는 지원할 수 없는 방식이나, 사용자(100)가 제 1단말(100)을 사용 가능한 경우에 해당 단말을 통해서 처리할 수 있도록 하여 사용 가능할 수 있다. 하지만, 현재 본 발명을 개시하는 시점에서 단말에서는 해당 처리 방법을 제공하지 않고 있다. 따라서 본 발명을 도입했을 때 제공하고자 하는 기기 변경의 방법은 To-Be 표(210)와 같다. As-Is 표(200)에서 미지원 즉, FAIL로 표기된 부분에 대해서 본 발명을 통해서 모두 지원할 수 있고, 이를 위해서 도 5d와 도 6c을 통해 이를 지원할 경우의 UI(User Interface) 및 UX(User Experience)와 Call Flow를 도시하였다.
도 3은 eSIM 기기 변경 절차 처리 절차 및 단말의 판단 기준을 나타낸 도면이다.
먼저, 기기 변경 시 프로파일 이동을 진행함에 있어 단말(105)은 사용자가 기기 변경에 대한 이벤트를 발생시키는 단말이 기존 프로파일을 이동시키고자 하는 기존 단말인지 또는 프로파일을 재설치 받을 신규 단말인지 여부를 판단할 수 있다. 이하 설명의 편의를 위해, 기존 프로파일을 이동하고자 하는 단말은 제 1단말(300), 프로파일을 재설치 받을 단말은 제 2단말(350)이라고 칭하기로 한다. 제 1단말과 제 2단말의 구분이 필요 없는 경우에, Device(105)로 사용할 수 있다. Device(105)는 사용자(100) 진입 메뉴를 분리하여 사용자가 제 1단말인지 또는 제 2단말에서 진입하는지 식별할 수 있다. Device(105)에서 사용자가 기기 변경 메뉴를 선택하여 기기 변경에 대한 요청이 입력(300)되면, Device(105)는 도 4에서 후술한 바와 같이 Configuration Server(170) 단말에 사전 저장된 정보, 또는 프로파일의 메타데이터를 통해서 수집된 정보를 확인하여 해당 프로파일에 대한 통신사업자의 기기 변경 지원 여부(305) 및 지원 방식(310)을 확인하고, 기기 변경을 수행함에 있어 해당 기기 변경 요청 단말(105)이 제 1단말(300)인지 제 2단말(350)인지를 포함하여 단말의 상태를 확인하여, 단말(105)에서 사용할 통신 서비스의 기기 변경 방식을 최종 결정(310)할 수 있다. 기기 변경의 지원 여부(305)라 함은 제 1단말(300)의 eUICC에 기 설치된 프로파일을 제 2단말(350)에 동일 또는 동일한 통신서비스 가입 설정을 가지는 프로파일로 다운로드 가능한지 여부에 대하여 판단하는 것을 의미한다.
해당 프로파일에 대한 통신사업자의 기기 변경 지원 여부(305) 및 지원 방식(310)을 확인하여, 단말(105)은 통신사업자의 해당 프로파일에 대한 기기 변경 지원 방식으로 ODSA Client와 ECS를 활용한 기기 변경 방식을 지원하는지, LPA와 SM-DP+ 서버를 활용한 기기 변경 방식을 지원하는 지에 대한 정보를 획득할 수 있다. 통신 사업자는 상기 언급한 2개의 기기 변경 방식 중에 1개 이상의 기기 변경 방식을 지원할 수 있다. 만약 단말에서 수집한 해당 통신사업자의 이동하고자 하는 프로파일에 대한 기기 변경 지원 방식이 1개 보다 많은 경우에 통신사업자는 해당 기기 변경 방식 적용에 대한 우선 순위에 대한 정보를 추가적으로 프로파일 메타데이터 또는 Configuration Server(170)에 저장해 두었다가 이를 단말에 제공하여 줄 수도 있다. 또한, 단말(105)은 사용자(100)에게 선택을 요청하는 화면을 표기하여 사용자가 선택하게 하거나, 단말 기본 설정에 의해서 해당 2개 방식 중에 하나를 골라서 적용해 사용할 수도 있다. ODSA Client와 ECS를 활용한 기기 변경 방식은 이후 설명의 편의를 위해 ODSA 방식, LPA와 SM-DP+ 서버를 활용한 기기 변경 방식은 LPA 방식으로 설명하며, 각 기기 변경 방식을 포함한 상세 절차는 도 5a 내지 도 5d 및 도 6a 내지 도 6c에서 상세 설명하기로 한다. 단말(105)이 상기와 같이 방식으로 획득한 정보에 따라 LPA 방식으로 처리해야 하는 경우에, 해당 기기 변경을 시작하는 단말(105)이 제 1단말(300)인지 제 2단말(350)인지 여부에 따라 이후 절차를 다르게 처리해야 한다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 LPA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 1단말(300)인 경우, 단말의 LPA(140)가 SM-DP+(150)에 기기 변경을 할 프로파일에 대한 소정의 정보를 포함하여 프로파일 이동을 요청하는 Command를 요청할 수 있다. SM-DP+(150)는 통신사업자(130)에 해당 기기 변경 요청에 대해 통보하고, SM-DP+(150)는 통신사업자(130)와 GSMA SGP.22에 정의된 ES2+ Interface를 통해 제 2단말(350)에 기기 변경을 위해 다운로드를 해 줄 프로파일을 생성 처리할 수 있다. SM-DP+(150)는 이동할 프로파일이 설치되어 있는 제 1단말(300)의 eUICC(160)와 상호 간에 SM-DP+와 eUICC 인증서의 서명 값을 교환(Common Mutual Authentication)하여, 프로파일이 설치된 해당 단말 및 eUICC(160)를 인증하는 것으로, 가입자를 인증할 수 있다. 이하 설명의 편의를 위해 본 발명에서는 상기 방식을 SM-DP+ 인증 방식(315)으로 지칭하도록 한다. SM-DP+ 인증을 통해 가입자가 인증되면, SM-DP+(150)는 제 2단말(350)이 생성한 프로파일을 다운로드 받기 위해 필요한 데이터를 제 1단말(300)로 회신할 수 있다. 제 1단말(300)이 해당 데이터는 획득하여 QR(Quick Response) 코드 형태로 제 1단말(300)에 Display하면 제 2단말(350)은 해당 상기 제 1단말의 화면에 Display된 QR 코드를 스캔(340)하고, 해당 QR 코드에 포함된 프로파일서버(150)로부터 상기 프로파일을 수신하여 설치하여 기기 변경에 따른 프로파일 이동 설치를 완료(390)할 수 있다. 제 1단말(300)은 정보를 QR 코드로 디스플레이(Display)하는 대신, 제 2단말(350)에 NFC, 블루투스, UWB 등의 근거리 통신이나 WiFi 통신, 서버를 경유해서 전달 할 수 있다. 그러나, 제 1단말(300)에서 QR 코드로 Display 할 경우, 제 2단말(350)에서는 QR 코드를 스캔(Scan)하는 통상의 eSIM 프로파일 다운로드 과정을 통해 프로파일을 설치할 수 있어서, 기존 프로파일 다운로드 절차의 수정 없이도 기기 변경 동작을 수행하는데 장점이 있다. 이하 QR 코드를 사용하는 것으로 예를 들어 설명하지만, 본 발명의 실시 예가 이에 한정되지는 않는다. 다음은 QR 코드로 Display할 프로파일을 다운로드 받기 위해 필요한 데이터의 일 구성 예를 보여준다.
LPA:x$SMDP.TEST.COM$XXXXX
상기 예시에서, SMDP.TEST.COM은 예시로 든 프로파일 서버 주소를 의미하며, $는 각 정보를 구분하는 구분자이며, LPA: 부분은 이 데이터가 프로파일 다운로드에 사용되는 Activation Code 포맷임을 의미하며, x부분은 Activation Code의 종류를 뜻하는 것으로 일 예로 이 값은 1, 또는 2, 또는 3, 또는 4 등의 숫자일 수 있으며, XXXXX 부분은 ACToken(Activation Code Token) 영역의 데이터로 아래 ASN.1 Data의 일부분 또는 전부를 포함한 정보를 Encoding 한 정보일 수 있고 편의상 XXXXX로 표시한 것이다.
ASN.1 Data
OtherSignedNotification ::= SEQUENCE {
tbsOtherNotification NotificationMetadata,
euiccNotificationSignature [APPLICATION 55] OCTET STRING, -- eUICC signature of tbsOtherNotification, Tag '5F37'
euiccCertificate Certificate, -- eUICC Certificate (CERT.EUICC.ECDSA) signed by the EUM
eumCertificate Certificate -- EUM Certificate (CERT.EUM.ECDSA) signed by the requested CI
}
NotificationMetadata ::= [47] SEQUENCE { -- Tag 'BF2F'
seqNumber [0] INTEGER,
profileManagementOperation [1] NotificationEvent, /*Only one bit SHALL be set to 1*/
notificationAddress UTF8String, -- FQDN to forward the notification
iccid Iccid OPTIONAL
}
이 때 상기 Encoding은 1) 하기와 같은 ASN.1형식의 Data를 DER 방식으로 인코딩을 한 후 다시 Hexademical 인코딩을 하여 문자로 표현 가능하게 하는 방식 2) 하기와 같은 ASN.1형식의 Data를 DER 방식으로 인코딩을 한 후 다시 BASE64 인코딩을 하여 문자로 표현 가능하게 하는 방식일 수 있다. 이하 설명의 편의를 위해 프로파일을 다운로드 받기 위해 필요한 해당 데이터는 Activation Code로 통칭하여 사용하고자 한다. 한편, 도면에는 기술되지 않았지만, 제 1단말(300)에서 프로파일 이동을 위해 프로파일을 삭제하기 전, 제 1단말(300)은 제 2단말(350)의 기기정보(예를 들면 eUICCInfo, DeviceInfo)를 획득 후, 프로파일서버에 이를 전달하여 제 2단말(350)에 프로파일 재설치가 가능한지를 체크한 후, 이후 과정을 진행할 수도 있다. 또한, 도면에서는 기술하지 않았으나, 제 1단말(300)에서 사용자 화면을 통해서 제 2단말(350)의 IMEI(International Mobile Equipment Identity)를 획득 및 입력을 요청하여(예를 들어, 단말 키패드에서 *#06#로 확인 등)하여 ECS 또는 LPA에 기기 변경 요청 전송 시 추가하여 전송할 수도 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 LPA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 2단말(350)인 경우, 제 2단말(380)은 사용자에게 제 1단말(300) 사용 여부에 따라 다른 절차를 안내할 수 있는 메뉴를 생성하여 화면에 표기한다. 제 1단말(300) 사용이 가능한 경우, 제 2단말(350)은 제 1단말(300)에서 진행에 대한 안내 메시지를 띄우고 제 1단말(300)로부터 Display된 QR 코드를 스캔할 수 있는 메뉴로 이동하여 대기할 수 있다. 사용자는 제 1단말(300)에서 상기 언급한 LPA 방식을 수행한 다음에 제 1단말이 프로파일 서버로부터 프로파일을 다운로드 받는데 필요한 해당 데이터를 획득하여 QR 코드 형태로 제 1단말(300)에 Display(340)하면 해당 QR 코드를 제 2단말(350)에서 스캔(385)하여 이후 절차를 동일하게 처리할 수 있다. 사용자(100)로부터 제 1단말(300)이 없다고 입력되는 경우에, 제 2단말(350)은 해당 통신사업자는 기존 제 1단말(300) 없이 프로파일의 기기 변경 서비스를 지원할 수 없다는 안내 메시지를 띄우고 절차를 종료(308)할 수 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 ODSA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 1단말(300)인 경우, 단말은 단말에 설치된 이동할 프로파일의 상태 정보와 단말에 구현된 인증 방식에 대한 정보를 수집하여 ODSA Client(110)에서 ECS(120)로 전송하고, 단말 또는 서버에서는 해당 프로파일에 대한 인증 방식을 결정할 수 있다. 프로파일의 상태 정보라 함은 프로파일이 enabled 또는 disabled 되어 있는 지에 대한 정보로 enabled되었다는 의미는 단말(105)이 해당 프로파일의 파일 데이터에 접근 가능한 상태로 네트워크가 활성화되어 있는 상태를 의미한다. disabled되었다는 의미는 단말(105)에서 해당 프로파일의 파일 데이터에 접근 불가능한 상태로 네트워크가 활성화되어 있지 않은 상태를 의미한다. 단말은 단말에 설정된 인증 방식의 우선 순위에 따라 인증 방식을 결정하여 ECS(120)에 전송하고 ECS(120)에서 이를 최종 확인하고 결정하여 회신하는 방식으로 인증 방식을 결정할 수 있다. 또는, 단말이 단말(120)에서 이동할 프로파일 상태 정보와 단말에서 지원 가능한 모든 인증 방식에 대한 정보를 ECS(120)에 전송하고 ECS(120)에서 해당 프로파일에 대한 서비스 사업자의 인증 방식 및 인증 방식 적용에 대한 우선 순위를 고려하여 1개를 선택해 사용할 방식으로 회신하는 방법도 가능할 수 있다. 본 발명에서는 ODSA 서비스 접근 자격에 대한 증명을 위해 단말에서 지원 가능한 인증 방식으로 제 1단말(300)은 ECS(120)와 SM-DP+(150) 협력 인증 방식(315)인 ECS&DP+방식(325), 전술한 SIM 모듈에 저장된 가입자 식별자 정보인 IMSI(Internal Mobile Subscriber Identifier)와 k값을 활용하는 EAP-AKA 방식(330), 웹 서비스 로그인 기반 인증 방식인 OAuth/Open ID 방식(335) 중 하나를 선택하여 이후 ECS(120)와 데이터 교환을 통해 해당 접근 단말 및 가입자가 ODSA 서비스 자격 인증이 있는지 수행할 수 있다. 각각의 인증 방식을 포함한 절차는 도 5a 내지 도 5d에서 상세하게 후술한다. ECS(120)에서 ODSA 서비스 접근에 대한 단말 및 가입의 자격이 인증되면, ECS(120)는 통신사 Back-end 시스템(130)를 통해서 제 2단말(350)이 SM-DP+(150)로부터 프로파일을 다운로드 받기 위해 필요한 데이터를 획득하여 제 1단말(300)의 ODSA Client로 회신할 수 있다. 또는, 통신사 Back-end 시스템(130)은 해당 SM-DP+(150)로부터 프로파일을 다운로드 받기 위해 필요한 데이터를 전송하는 대신, 제 1단말(300)이 자체 생성 등으로 획득하는 방법을 포함하여 회신할 수도 있다. 제 1단말(300)이 해당 데이터를 획득하는 자세한 방법에 대해서는 도 5c에서 후술하기로 한다. 제 1단말(300)이 해당 데이터는 획득하여 QR 코드 형태로 제 1단말(300)에 Display하면 제 2단말(350)은 해당 상기 제 1단말의 화면에 Display된 QR 코드를 스캔(340)하고, 해당 QR 코드에 포함된 프로파일서버(150)로부터 상기 프로파일을 수신하여 설치하여 기기 변경에 따른 프로파일 이동 설치를 완료(390)할 수 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 ODSA 방식이며, 해당 기기 변경을 시작하는 단말(105)이 제 2단말(350)인 경우, 단말은 제 1단말(300) 보유 여부에 대한 사용자 입력을 통해 사용자(100)로부터 해당 정보를 획득할 수 있다. 제 2단말(350)에서 사용자(100)가 제 1단말(300)을 사용할 수 있다는 정보가 입력되는 경우, 제 2단말(350)은 제 1단말(300)은 사용자로부터 인증 코드를 수신할 제 1단말(300)의 전화번호(MSISDN) 입력 받아 ECS(120)로 전송할 수 있다. ECS(120)는 통신사의 별도 인증 서버와의 메시지 교환을 진행하고, 통신사의 별도 인증 서버에서 해당 전화번호(MSISDN)에 문자 메시지로 인증코드를 송신할 수 있다. 제 1단말(300)에서 문자 메시지로 인증 코드가 수신되면, 사용자는 인증 코드를 제 2단말(350)에 입력하여 ODSA 서비스에 대한 접근 권한이 있음을 인증할 수 있다. 단말(105)이 상기 획득한 사업자의 기기 변경 방식이 ODSA 방식이며, 제 2단말(350)에 사용자(100)가 제 1단말(300)을 사용할 수 없다고 입력하는 경우에, 제 2단말(350)은 웹 포탈 또는 웹 애플리케이션으로 연결하여 로그인 방식을 통한 가입자 인증 방식인 OAuth/Open ID 방식(370)을 선택하여 인증할 수 있다. 이러한 SMS-OTP(One time Password or Password) 방식(365) 또는 OAuth/Open ID 방식(370)을 통해 접근 단말 및 해당 가입자가 ODSA 서비스 접근 자격이 있음이 인증되면, ECS(120)는 제 2단말(350)이 프로파일 서버(170)로부터 프로파일 다운로드에 필요한 데이터를 Activation Code 포맷으로 제 2단말(350)의 ODSA Client(110)에 전송할 수 있다. 해당 데이터는 단말의 ODSA Client(110)에서 LPA(140)에 전달되며, LPA(140)에서는 이동 설치할 프로파일을 SM-DP+서버(150)로부터 다운로드하여 eUICC(160)설치함으로써 기기 변경에 따른 프로파일 이동을 처리할 수 있다. 한편, 도 3 및 이후 도면에서 논점을 해칠 수 있어 복수 개의 인증 방식을 결합 사용하는 절차에 대해서 상세 언급하지 않았으나, 단말은 도 4에서 획득한 정보(예. 사업자 지원 인증 방식들)와 사용자 Input(예. 제 1단말의 사용 가능 여부), 프로파일의 상태 정보(예. 프로파일의 활성화 상태) 등에 따라서 1개 이상의 인증 방식으로 인증을 처리함으로써 기기 변경을 처리하기 위한 인증을 강화할 수도 있다. 예를 들어, 제 2단말(350)이 ODSA 방식을 사용하며 제 1단말(300)을 사용 가능한 경우(360)에 사업자가 OAuth/OpenID와 SMS-OTP 방식을 모두 지원하는 경우, OAuth/Open ID방식(370)으로 사업자의 웹 포탈에 로그인하는 것으로 가입자 인증을 하고, 제 1단말(300)이 사용 가능하므로 추가적으로 SMS-OTP를 통한 인증(355)를 제공할 수도 있다.
도 4는 eUICC를 탑재한 단말(105)에서 기기 변경 시 프로파일 이동 처리를 위한 설정 정보를 획득하는 방법을 도시하는 도면이다.
Device(105)에서 End User(100)는 단말에서 기기 변경 시 신규 단말로 이동할 프로파일을 선택하는 경우, 해당 프로파일을 선택하는 경우에 단말은 프로파일의 메타데이터 정보에서 모바일 통신사 식별 정보로 MCC+MNC(The ITU-T Recommendation E.212에 정의된 mobile country codes(MCC)와 mobile network codes(MNC)를 의미) 값을 획득할 수 있다. 또는, 단말에 이동할 프로파일이 없는 경우, 즉 신규 단말에서 기기 변경을 시도하는 하는 경우, 단말(105)는 사용자(100)로 하여금 통신사업자를 선택하는 메뉴를 제공함으로써, 통신사업자의 MCC+MNC 정보를 획득할 수 있다. 해당 MCC+MNC 정보를 통해 단말은 어떤 사업자의 프로파일을 이동 설정을 확인해야 하는지 판단할 수 있다. 단말(105)은 또한, End User(100)가 프로파일 이동에 대한 메뉴를 선택할 수 있도록 제공하여, 해당 프로파일의 기기 변경을 위한 절차 수행 시작 및 제 1단말(300) 또는 제 2단말(350) 중 어떤 단말을 통해 접속하는지 정보를 획득할 수 있다. 단말(105)은 이제 단말은 이후 프로파일 이동을 위한 사업자의 기기 변경 설정 정보를 확인하여 프로파일 이동에 사용할 방식으로 LPA 방식 또는 ECS 방식 중 하나를 선택(470)할 수 있다. 단말이 필요한 기기 변경 설정 정보로 해당 프로파일에 대한 통신사업자의 기기 변경 지원 여부를 포함하며, 기기 변경 지원 방식(LPA 방식 또는 ODSA 방식), 및 지원 방식에 따른 SM-DP+ 서버 주소 또는 ECS 주소, 지원하는 사용자 인증 방식, 예를 들어 EAP-AKA, ECS&DP+, OAuth/Open ID 등의 인증 방식 식별 정보 및 선호 우선 순위에 대한 정보를 포함할 수 있다. 기기 변경 설정 정보를 확인하는 방법으로는, 단말(105)은 다음을 수행할 수 있다.
- 옵션 1: 사용자(100)가 단말의 UI를 통해 이동할 프로파일을 선택하는 경우에, LPA(140)에서 eUICC(160)로 GSMA SGP.22에 정의된 ES10c.GetProfilesInfo() Function Call을 수행하여 해당 프로파일의 상태 정보와 메타데이터 정보를 획득할 수 있다.
- 옵션 2: 단말(105)은 메모리 및 배터리 절약 등을 위해서 Configuration Server(170)에 저장된 통신사업자들의 기기 변경 설정 정보를 특정 주기 또는 최초 단말 부팅 시 모두 한꺼번에 받아 오지 않고, 단말(105)이 사용자(100)가 단말(105)의 UI에서 통신사를 선택하면, Configuration Server(170)에 해당 통신사의 MCC+MNC에 대한 기기 변경 설정 정보를 요청하고, 해당 요청에 대한 회신으로 특정 사업자의 기기 변경 설정 정보를 획득할 수 있다.
- 옵션 3: 기기 변경 수행을 처리하기 위해 Configuration Server(170)가 존재하고, 단말(105)에 해당 서버 주소가 설정되어 있는 경우에, 단말은 최초 부팅 시 또는 단말 설정에 따라 특정 주기로 해당 서버에서 기기 변경 설정 정보를 일부 또는 전체를 가져와 저장해 두었다가 활용할 수 있다. 사용자가 특정 통신사업자를 선택 또는 이동할 프로파일을 선택하는 경우에, 단말(105)은 단말의 메모리에 저장된 해당 정보를 확인하여 매칭되는 값을 획득하여 활용할 수 있다.
- 옵션 4: 통신사업자 별 기기 변경 방식 또는 사업자 향 단말로 출시된 경우, 해당 통신사의 기기 변경 방식을 preloaded 해 두었다가 전술한 바와 같이 사용자(105)가 프로파일 또는 이동할 프로파일의 통신사업자를 메뉴에서 선택하면 단말(105)은 메모리에 저장된 정보와 매칭하여 기기 변경 설정 정보를 확인할 수 있다.
단말(105)은 위의 언급한 4가지 방법 중 하나 또는 그 이상을 복합적으로 활용할 수 있으며, 해당 옵션을 통해서 획득한 기기 변경 설정 정보가 다른 경우, 단말 설정에 따라 방법을 결정하여 설정할 수 있다. 한 예로, 단말은 가장 최근에 설정 정보 또는 다른 예로 프로파일의 메타데이터를 선택하는 데 있어 우선 순위로 결정할 수 있다. 이하 도 5a 내지 도 5d 및 도 6a 내지 도 6c에서 언급할 실시 예 들을 통해 해당 설정 정보를 받아오고 활용하는 절차를 상황 별로 구체적으로 설명하겠다.
도 5a 내지 도 5d는 제 1단말(300)에서 시작하는 경우의 기기 변경 방식에 대한 실시 예들을 도시한다. 기기 변경 처리에 대한 전체 절차는 다음과 같은 절차로 크게 구분할 수 있다. 제 1단말(300)이 eSIM 설정 정보를 파악하는 단계, ODSA 서비스 자격을 확인하기 위한 단말 및 사용자 인증을 진행하는 단계, 인증이 완료되면 Activation Code를 발급해 주는 단계, 제 2단말(350)에서 해당 정보를 획득하여 프로파일을 다운로드 받아 이동 설치를 완료하는 단계이다.
도 5a는 통신사가 ODSA 방식을 제공하며 EAP-AKA 인증을 사용하는 실시 예를 나타내는 도면이다.
End User(100)는 제 1단말(300)의 LPA 또는 LPA가 구현된 애플리케이션의 화면에서 기기 변경을 위해 이동할 프로파일을 선택하고, 해당 프로파일을 이동 메뉴를 선택(5a-10 단계)할 수 있다. 해당 메뉴가 선택되면, 단말(300)은 해당 프로파일의 통신사업자 식별 ID 정보(MCC+MNC)를 가지고, 해당 통신사의 eSIM 기기 변경을 위한 설정 정보가 단말에 저장되어 있는지 확인하는 한편, 단말의 LPA1(140)에서 단말의 eUICC(160)로 GSMA SGP.22에 정의된 ES10c.GetProfilesInfo() Function Call을 수행하여 해당 프로파일의 상태 정보를 획득할 수 있다. 상태 정보와 더불어 LPA1(410)는 단말의 eUICC(160)로부터 해당 프로파일의 메타데이터에 기기변경 지원 여부, 지원 방식에 대한 식별 정보 또는 이후 처리를 위한 서버 주소가 있는지 추가적으로 확인할 수 있다. 5a-10 단계 내지 5a-30 단계에서는 옵션 1과 옵션 3을 통해서 확인하는 방법을 예로 도시하였으나, 획득하는 방법은 이에 한정하지 아니하고 도 4에서 전술한 바와 같이 옵션 1 내지 옵션 4를 1개 이상 활용 및 조합하여 획득할 수 있다. 해당 수집된 정보를 통해 제 1단말(300)은 해당 프로파일을 통신사가 ODSA Client(110)와 ECS(120)를 활용하는 ODSA 방식을 지원하는 것과 해당 방식을 처리하기 위한 ECS 주소를 획득하여 이후 단말에서 처리할 기기 변경 방식을 결정(5a-40 단계)할 수 있다. 제 1단말(300)의 ODSA Client 또는 ODSA Client가 구현된 앱인 ODSA1(500)은 앞서 프로파일 메타데이터 확인(5a-30 단계)을 통해서 획득한 프로파일의 상태 정보를 LPA1(510)으로부터 획득하고, 단말의 Capability를 확인하여 가능한 단말의 인증 방식을 수집하여 ECS(120)에 인증 요청을 송신할 수 있다. 한 예로 (5a-50 단계)와 같이 나타낼 수 있다. 해당 인증 요청 메시지에는 단말 식별자로 IMEI, 단말에서 구현된 인증 방식들에 대한 식별 정보, 요청 단말이 제 1단말(300)임을 추측할 수 있는 식별 정보로써 ICCID, IMEI, 또는 EAP(Extensible Authentication Protocol) ID 또는 신규 식별자를 정의하여 포함할 수 있으며, 이동할 대상 프로파일 ID로 ICCID, 해당 프로파일의 상태 정보를 포함할 수 있다. 해당 인증 요청 메시지에 포함된 상기 정보에서 요청 단말이 제 1단말(300)임을 나타내는 식별 정보, 이동할 대상 프로파일 ID로 ICCID, 해당 프로파일의 상태 정보와 같은 기기 변경 처리에 요구되는 정보들은 인증 요청 메시지에 추가하지 않고, 인증이 완료된 후에 기기 변경 요청하는 시점(5a-160 단계)에 포함하여 단말에서 전송하는 방법도 가능하다. 단말에서 구현된 인증 방식에 대한 식별 정보라 함은 해당 인증 방식이 단말에 구현되었거나 또는 단말에 구현되었으며 해당 송신하는 시점에서 사용 가능한지를 나타내는 식별자로 사용할 수 있다. 해당 인증 방식에 대한 식별 정보를 통해 ECS(120)에서 프로파일의 상태 정보를 판단할 수 있는 경우에 단말은 프로파일 상태 정보를 포함하지 않고 송신할 수 있다. 단말에 구현된 인증 방식에 대한 식별 정보로, 단말에 EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement)가 구현된 경우에 단말은 인증 요청에 EAP ID를 포함해 전송(5a-50 단계)할 수 있다. 단말에서 사용 가능한 인증 방식으로써 ECS&DP+ 방식을 사용하는 경우에 이를 구분할 신규 식별자를 정의하거나 기존 식별자(예를 들어 SM-DP+Address)를 해당 식별 정보로 활용할 수 있다. 해당 식별자는 본 발명에서는 편의를 위해 DP+AuthSupport라고 칭하여 설명하겠다. 만약 단말에서 인증 방식에 대한 식별 정보 또는 인증 토큰이 없는 경우에 ECS는 해당 단말이 OAuth/Open ID 만 제공 가능하다고 판단할 수 있다. ECS(120)가 단말로부터 단말이 지원하는 1개 또는 그 이상의 인증 방식에 대한 인증 식별 정보를 수신(5a-60 단계)하면, 예를 들어, EAP-AKA 식별자로 EAP ID, ECS&DP+ 인증을 위한 식별자로 DP+AuthSupport를 포함해 수신하면, ECS(120)는 사업자의 선호도 및 사업자의 인증 서버 지원 여부에 따라 가능한 1개의 방식을 선택하여, 단말에 회신할 수 있다. 한편, 요청 단말이 제 1단말(300)임을 나타내는 식별 정보 또는 신규 식별자의 일 예는 5a-50 단계의 OldTerminal=True, old terminal ID=Old terminal IMEI와 같은 신규 값일 수 있고, 또는 이동할 프로파일의 고유 식별 번호인 ICCID가 포함 된 경우, 일 예로 old_termnal_iccid=ICCID, ECS(120)가 제 1단말(300)로 판단하는 것도 가능하다. 또한, ECS(120)가 해당 ICCID 정보와 OldTerminal=True 또는 old terminal ID=Old terminal IMEI를 조합하여 제 1단말(300)로 판단할 수도 있다. ECS(120)는 EAP-AKA 인증을 수행하기 위해 사업자의 AAA(Authentication, Authorization and Accounting) 인증 서버와의 Relay가 지원 가능한지 여부, 여러 개의 인증 방식이 가능한 경우에 사업자가 제공하고자 하는 인증 방식의 우선 순위 등을 확인할 수 있다. 5a-60 단계에서 5a-170 단계까지는 해당 확인을 통해서 ECS(120)가 인증을 EAP-AKA로 진행했을 때의 방법을 도시한다. 단말에 구현된 인증 방식에 대한 식별 정보로, 단말에 EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement)가 구현된 경우에 단말은 전술한 바와 같이 인증 요청에 EAP_ID를 포함해 전송(5a-50 단계)할 수 있다. 제 1단말(300)은 사용자가 이동하고자 선택한 프로파일의 IMSI(International Subscriber Identity Module)값을 EAP ID 에 포함하여 ECS(120)에 전송할 수 있고, 해당 값을 획득할 수 없으나 단말에 EAP-AKA가 구현된 경우에 EAP ID 값을 NULL, empty value로 하여 전송하거나 또는 이를 나타내기 위한 별도 식별자 또는 값을 정의하여 제공할 수 있다. IMSI 값은 프로파일의 상태 정보가 Enabled 되어 있을 때 프로파일의 내부 데이터 또는 프로파일의 메타데이터에서 획득 가능한 정보로, EAP-AKA가 제공 가능하게 구현되어 있고, 기기 변경을 수행하는 현 요구 시점에서 해당 인증을 사용할 수 있음을 나타낼 수 있다. 한편, 해당 정보를 획득하지 못한다는 것은 해당 시점에 단말에 EAP-AKA가 구현되어 있으나 프로파일의 상태 정보가 disabled라는 것으로 ECS(120)가 판단할 수도 있다. 한편, 제 1단말(300)은 5a-30 단계에서 취득한 프로파일의 상태 정보를 ECS(120)에 함께 포함해 전송함으로써 ECS(120)에게 해당 단말에서 EAP-AKA 인증을 사용 가능함을 명확하게 알려줄 수 있다(5a-50 단계). ECS(120) 수신된 인증 요청 메시지를 통해서 단말에 EAP-AKA가 구현되어 있으나 프로파일 상태가 Disabled 되어 있는 경우에, ECS(120)는 EAP-AKA로 사용자 인증을 수행할 지 여부와 처리 가이드 등을 포함해 사업자 메시지를 포함해 단말에 회신(5a-70 단계)할 수 있다. 해당 경우에 단말은 사업자 메시지를 단말에 표시하여 사용자의 동의를 획득하며, 사용자(100)는 EAP-AKA로 인증을 처리를 승낙하거나 거절할 수 있다(5a-80 단계). 만약 승낙하는 경우에, LPA1(510)에서 eUICC로 프로파일의 상태를 일시적으로 disabled 상태에서 enabled 상태로 변경(5a-90 단계)하여 EAP-AKA 인증이 가능하도록 사용자 동의를 획득한 후, 사용자가 허가한 경우 LPA1(510)에서 eUICC로 10c.EnabldProfile() 처리할 수 있다. enabled 상태로 변경되면 LPA1(510)에서는 eUICC로부터 해당 프로파일 상태 정보와 IMSI 값을 획득하여 ODSA1(500)에 전달할 수 있다. 이를 받은 제 1단말의 ODSA1(500)은 5a-95 단계와 같이 EAP_ID를 IMSI값으로 하여 인증 요청 메시지를 ECS(120)에 전송할 수 있다. 또는 프로파일 상태 정보를 추가적으로 포함하여 보내어 프로파일 상태가 변경되었고 EAP-AKA 인증이 가능함으로 ECS(120)에 알릴 수 있다. 만약 사용자가 거절(5a-170 단계)하는 경우에, 제 1단말(300)은 해당 거절 메시지를 ECS(120)에 송신하고, ECS(120)는 해당 거절 메시지를 받게 되면, 기존의 수신된 (5a-50 단계)를 통해 수신된 단말의 다른 인증 방식을 참조하여 사용할 인증 방식을 선택해 인증 절차를 처리할 수 있다(5a-180 단계). EAP-AKA방식은 Challenge-response 메커니즘을 사용하며 대칭키 기반의 인증을 통한 암호화된 세션을 생성할 수 있다. ECS(120)가 단말의 인증 식별 정보 또는 단말의 식별 정보와 프로파일 상태 정보의 조합으로 EAP-AKA 방식 사용이 가능하다고 판단되어 EAP-AKA 방식을 선택하면, ECS(120)는 사업자 인증 서버(540)에 EAP-AKA Challenge를 요청(5a-120 단계)할 수 있다. 사업자 인증 서버(540)는 AKA 알고리즘을 수행하여 "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement(EAP-AKA)" 에 정의된 바와 같이 EAP-AKA Challenge 값을 생성하여 ECS(120)에 회신하고 ECS(120)는 선택한 인증 방식(여기서는 EAP-AKA 방식)과 검증에 필요한 값으로 EAP-AKA Challenge를 함께 단말에 회신(5a-110 단계)할 수 있다. ECS(120)가 선택한 인증 방식은 별도 구분자로 알려줄 수도 있고(예를 들면, 5a-110 단계의 AuthType(EAP-AKA)) 해당 인증 방식임을 판단할 수 있는 소정의 정보의 수신으로(예를 들면, 5a-110 단계의 EAP-AKA Challenge 값만을 수신)하여 해당 인증 방식을 ECS(120)가 결정했다고 판단할 수 있다. 해당 EAP-AKA Challenge가 수신되면, 제 1단말(300) eUICC은 해당 Challenge 값과 해당 SIM 모듈의 보안 키 값을 활용해 EAP-AKA 알고리즘을 수행하여 해당 결과 값을 포함해 ECS(120) 에 회신(5a-130 단계)할 수 있다. ECS(120)는 해당 수신된 정보를 사업자 인증 서버(440)에 Relay하고 사업자 인증 서버(440)는 제 1단말(300)로부터 수신된 값(5a-130 단계)으로부터 EAP-AKA Challenge값을 검증하여 인증 여부를 ECS(120)에 회신(5a-140 단계)할 수 있다. 해당 인증 결과(5a-140 단계)가 성공인 경우에, ECS(120)는 이후 ECS(120)와의 세션 연결에 사용할 수 있는 인증토큰(AuthToken)을 생성하여 제 1단말(300)에 전송(5a-150 단계)할 수 있다. 이제 제 1단말(300)은 단말의 고유 식별 정보로 IMEI와 수신된 인증토큰을 파라미터로 하여(5a-160 단계) 통신 서비스 가입된 기기의 이동을 요청(5a-160 단계)할 수 있다. 전술한 바와 같이 요청 단말이 제 1단말(300)임을 나타내는 식별 정보, 이동할 대상 프로파일 ID로 ICCID, 해당 프로파일의 상태 정보와 같은 기기 변경 처리에 요구되는 정보들은 인증 요청 메시지에 추가하지 않고, 인증이 완료된 후에 기기 변경 요청하는 시점(5a-160 단계)에 포함하여 단말에서 전송하는 방법도 가능하다. 이는 제 1단말(300)에서 기기 변경을 요청하는 다른 실시 예에서도 동일하게 적용될 수 있다. EAP-AKA를 활용한 단말과 인증 서버 간의 구체적인 인증 절차 및 파라미터는 "RFC4187 Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement(EAP-AKA)" 규격을 참조한다.
해당 인증이 완료되면, ECS(120)와 SM-DP+서버(150), MNO BSS/OSS(130)은 서비스 가입 정보 변경에 필요한 정보를 획득하고 SM-DP+서버(150) 및 MNO BSS/OSS(130)은 프로파일을 생성을 준비(5a-190 단계)할 수 있다. 해당 5a-190 단계에서 ECS(120)는 현재의 해당 프로파일의 ICCID에 맵핑되어 있는 Subscription ID, 또는 여기에 추가로 신규 단말의 IMEI를 포함하여 신규 가입 정보를 통신사업자의 Back-end 시스템(130)에 요청할 수 있다. 이를 수신한 MNO BSS/OSS(130)에서는 SM-DP+서버(150)와 SGP.22에 정의된 ES2+Interface를 통해 프로파일 생성에 대한 일련의 과정을 수행하여 제 2단말(350)에 설치할 프로파일의 ICCID와 Activation Code를 포함하여 획득하여 ECS(120)에 회신할 수 있다. ECS 서비스 가입 정보 변경에 필요한 정보를 해당 시점에 또는 이후 특정 시점에 업데이트하여 ECS(120)에 저장된 가입 정보를 변경 처리할 수 있다. ECS(120)는 제 1단말의 ODSA1(500)에 수신된 Activation Code를 송신(5a-200 단계)할 수 있다. 사업자의 정책에 따라 ECS(120)는 해당 프로파일의 제 1단말(300)에서의 삭제 여부에 대한 값을 함께 포함하여 송신(5a-200 단계)할 수 있다. 해당 정보가 수신되면, 제 1단말(300)은 해당 단말의 사용자 안내 메시지로 제 2단말(350)에서 제 1단말(300)에 수신한 Activation Code를 획득하는 방법을 띄운다(5a-210 단계). 만약, 제 1단말(300)에서의 삭제 여부에 대한 값을 함께 수신(5a-200 단계)한 경우, 제 1단말(300)은 사용자에게 기존 프로파일의 삭제를 안내하고 삭제해야만 기기 변경을 처리할 수 있음을 알려주어 사용자의 동의를 획득할 수 있다. 사용자가 삭제를 동의하는 경우에, 제 1단말에서 ODSA Client 또는 ODSA Client가 구현된 앱인 ODSA1(500)에서 LPA1(510)에 프로파일 Delete을 요청하면, LPA1(510)에서 해당 이동할 프로파일에 대한 "ES10c.DeleteProfile" Function Call을 수행해 eUICC에서 해당 프로파일을 삭제 처리하고, 해당 프로파일이 삭제에 대한 notification을 LPA1(510) 또는 ODSA1(500)에 회신할 수 있다. 단말은 LPA1(510) 또는 LPA1을 통해 ODSA1(500)이 해당 프로파일 삭제에 대한 notification을 수신해야 Activation Code를 활성화하여 제공해 주도록 처리할 수도 있다. End User(100)는 제 2단말(350)에서 5a-210 단계에 안내된 바에 따라 Activation Code를 획득(5a-220 단계)할 수 있다. 예를 들어, 제 2단말(350)의 사용자의 UI로 Activation Code가 QR 코드 형태로 Display하고 제 1단말(300)의 카메라를 사용해 해당 QR 코드를 스캔할 수 있다. 해당 Activation Code가 제 2단말(350)에 입력되면, LPA2(430)에서 Activation Code를 획득하여 Activation Code에 설정된 SM-DP+ 서버 주소로 접속하여 GSMA SGP. 22에 정의된 Remote SIM Provisioning 절차에 따라 프로파일을 제 2단말에 다운로드하여 설치 완료(5a-230 단계)할 수 있다. 다운로드 설치 처리가 완료되면, MNO의 Back-end 시스템(130)은 ECS(120)에 제 2단말(350)에 설치된 신규 프로파일의 ICCID 또는 ICCID와 제 2단말(350)의 IMEI를 함께 전송하고, ECS(120)는 해당 ICCID와 (5a-120 단계)에서 획득한 ICCID 값을 매칭하여 동일한 경우, 해당 Subscription 정보를 업데이트하고 선택적으로 업데이트 결과를 사업자 Back-end 시스템(130)에 회신할 수도 있다.
도 5b는 제 1단말에서 시작하는 ODSA 방식을 지원하는 프로파일 이동으로, 인증 방식으로 ECS/DP+ 방식을 사용하는 실시 예를 나타내는 도면이다.
도 5a의 5a-10 단계 내지 5a-50 단계에 대한 설명으로 전술한 바와 같이 제 1단말(300)은 프로파일, 메모리, Configuration Server(170)를 통해 기기 변경에 대한 Configuration 정보를 획득할 수 있다. 이후 단말 및 가입자 인증을 수행함에 있어, ECS&DP+ 인증 방식을 수행하고자 하는 경우에 단말은 ECS(120)에 송신하는 인증 요청에 DP+AuthSupport 이 가능함을 나타내는 식별자를 포함하여 인증을 요청할 수 있다. 본 발명에서는 이후 설명의편의를 위해 임의의 식별자로 5a-50 단계의 DP+AuthSupport로 표기하였으나, 해당 이름에 한정하지 않으며, SM-DP+로 인증이 수행이 가능함을 나타내는 식별자 정보로 단말은 인증 수행이 가능한 SM-DP+ 주소를 식별자로 사용할 수도 있다.
해당 인증 방식이 수신되면 ECS(120)는 GSMA Root CI(Certification Issuer) 인증서와 해당 인증을 수행을 위해 Redirect할 SM-DP+ 주소가 Configure 되어 있는지를 포함하여 해당 인증 방식 지원을 위한 Capability를 확인하여, 해당 인증 방식으로 처리를 결정할 수 있다. 앞서 단말에서 인증 수행이 가능한 SM-DP+주소를 식별자로 사용한 경우에 ECS(120)는 수신된 SM-DP+ 주소를 Redirect할 SM-DP+ 주소로 사용할지 여부를 추가적으로 결정할 수 있다.
해당 인증 방식을 결정하면, ECS(120)는 임의의 데이터인 Nonce값을 생성(5b-20 단계)하여 제 1단말(300)에 ECS&DP+ 인증 방식, 인증 받을 SM-DP+ 서버 주소, 그리고 생성한 Nonce값을 포함해 회신(5b-30 단계)할 수 있다.
도 5a에서 전술한 바와 같이 ECS(120)는 단말에 선택한 인증 타입을 명시적으로 알려줄 수도 있고, 선택한 인증 타입에 대한 명시적으로 제공이 없더라도, 단말이 판단할 수 있는 소정의 정보 제공을 통해서, 즉 예를 들어 인증 받을 SM-DP+ 서버 주소 회신, 단말이 이를 판단하여 결정할 수도 있다. 일 예로 ECS는 ECS가 OAuth/Open ID 인증 방식을 선택 시 회신하는 HTTP(s) "302 Found" 응답 구조로, 인증 받을 SM-DP+서버 주소로의 Redirection 을 요청할 수 있으며, 이 경우에 다음 예시들 중 하나가 포함될 수도 있다.
예시 1) Http(s) Response - 302 Found
Header에 다음을 포함
Location: <인증을 수행할 SM-DP+주소>/authorize?
Body에 다음을 포함
response type=code&
scope= SM-DP+Auth&
nonce=<ECS 생성 nonce 값>&
Client ID=<ECS가 인증을 수행할 SM-DP+로부터 사전 발급 받은 ID>&
redirect URL=<회신할 주소로 AES로 암호화된 ECS 주소>
예시 2) Http(s) Response - 302 Found
Header에 다음을 포함
Location: < 인증을 수행할 SM-DP+주소>/authorize?
Body에 다음을 포함
response type=SM-DP+Auth&
nonce=ECS 생성 nonce 값&
client ID=<ECS가 인증을 수행할 SM-DP+로부터 사전 발급 받은 ID>&
redirect URI=<회신할 주소로 AES로 암호화된 ECS 주소>
예시 1) 또는 예시 2)와 같이 HTTP(s) "302 Found" 응답 구조의 scope 또는 response type에 DP+인증을 나타내는 식별자가 포함되어 회신 되는 경우, 단말은 ECS가 OAuth/Open ID 방식이 아닌 ECS&DP+로 인증 수행을 요청함으로 판단하고 제 1단말(300) 내부 동작으로 ODSA1(500)가 LPA1(510)에 해당 수신된 데이터를 전달(5b-40 단계) 하여 이후 아래와 같이 DP+인증 절차 수행으로 처리할 수 있다. OAuth/Open ID 인증 방식인 경우, response type으로 수신되는 code는 client id와 redirection URI와 binding이 요구되며, 최초 Http(s) Response - 302 Found에 client id와 redirection URI가 포함되어 전송되어야 한다. OAuth2.0/OIDC Sever는 사전 계약을 통해 ECS에 대한 Client ID를 사전 발급, redirection URI에 대한 정보를 가지고 있다가 단말이 특정 Client ID와 redirection URI를 가지고 인증 요청하면, 해당 정보를 검증하여 code를 발급하여 회신해 줄 수 있다. 하지만, ECS/SM-DP+ 인증은 사전 SM-DP+와 ECS의 계약 없이 처리가 가능하므로 ECS에서 Http(s) Response - 302 Found에 DP+인증을 나타내는 식별자가 포함된 경우 client ID와 redirect URI 중 하나 또는 전체를 포함하지 않아도 단말은 이를 에러 처리하지 않고 DP+인증 절차 수행으로 처리해야 한다.
해당 도면에서는 도시하지 않았으나, eUICC와 SM-DP+ 간에 (5b-50 단계)절차를 수행하기에 앞서, 상호 인증 절차를 먼저 수행할 수 있다. 먼저 LPA1(510)은 해당 프로파일이 설치된 제 1단말(300)의 eUICC에 ES10b.GetEUICCChallenge를 요청하여 해당 메시지 값으로 eUICCChallenge 값을 수신하여, LPA1(510)에서 해당 eUICCChallenge 값을 포함한 메시지로 ES9+.InitiateAuthenticate 요청 메시지를 SM-DP+(150)에 전송할 수 있다. 해당 프로파일 서버에서는 해당 값을 검증하여 Transaction ID를 생성하고 Transaction ID와 eUICCChallenge 값이 포함된 데이터에 대한 프로파일 서버의 서명을 생성하여 회신할 수 있다. 이때 회신 하는 InitiateAuthenticate 회신 메시지는 상기 프로파일 서명값, Transaction ID를 포함할 수 있다. 제 1단말(300)은 상기 InitiateAuthenticate 회신 메시지를 수신 후, ECS(120)로부터 수신된 Nonce값(5b-40 단계), 기기 변경 대상 프로파일의 ICCID, 해당 ICCID가 설치된 eUICC 서명 데이터를 생성해 이를 포함하는 데이터를 SM-DP+서버(150)에 전송할 수 있다. eUICC 서명 데이터에 추가적으로 또는 eUICC 서명 데이터를 대체하는 정보로 EID를 포함해 전송할 수도 있다. 전송되는 메시지의 일 예는 ES9+.AuthenticateClient Request (MatchingID=ICCID1, AuthRequest (Nonce, eUICC Signature) (5b-50 단계)와 같은 메시지일 수 있다. SM-DP+서버(150)는 상기 AuthenticateClientRequest 메시지를 수신하면 AuthenticateClientRequest메시지에 포함된 가입 정보 이전 처리하고자 하는 프로파일의 ICCID(ICCID1로 표기), 제 1단말의 해당 eUICC의 서명 Data 검증을 포함한 유효성 검증과정을 수행하여, 해당 ICCID의 제 1단말의 eUICC 설치를 검증하여 검증 결과로 프로파일 서버의 서명을 생성하고 5b-50 단계에서 수신한 Nonce, eUICC서명데이터, 프로파일 서버의 서명 데이터를 포함한 인증 토큰을 AuthenticateClientResponse 메시지(5b-60 단계)에 포함하여 회신할 수 있다. 해당 회신하는 정보는 ICCID에 매핑되는 EID가 추가적으로 포함될 수 있다. 해당 회신 메시지의 일 예로ES9+.AuthenticateClient Response (AuthResponse (AuthToken (EID, ICCID, Nonce, DP+ Signature))) (5b-60 단계)와 같이 표기될 수 있다.
SM-DP+(150)서버에서 상기 제 1단말(300)의 eUICC(160)의 서명데이터검증은 상기 ICCID 또는 상기 ICCID에 추가적인 데이터(ECS Nounce, eUICC 서명 값, 처리 순번 번호)를 포함한 데이터에 대해서 제 1단말(300)의 eUICC(160)의 인증서를 이용한 서명 검증일 수 있다. 상기 서명검증은 ECDSA(Elliptic Curve Digital Signature Authentication)일 수 있다. 상기 eUICC 인증서는 상기 EUM(eUICC Manufacturer)인증서로 인증할 수 있다. 상기 EUM 인증서는 프로파일 서버(150)가 가지고 있는 CA(Certificate Authority) 인증서로 검증할 수 있다. 상기 CA 인증서는 Root CI(Certificate Issuer) 인증서로도 명명할 수 있다. 또한 상기 유효성 검증과정은 상기 ICCID에 대해서 최종 설치되었던 eUICC가 제 1단말(300)의 eUICC(160)임을 확인하는 과정 및 메시지의 처리순번정보(Sequence Number)를 이용하여 메시지의 유효성을 확인하는 과정을 포함할 수도 있다. 또한 프로파일서버(150)의 상기 유효성 검증 과정은, 도면에는 표시되어 있지 않지만, 프로파일서버(150)가 사업자 서버에게 상기 ICCID에 대한 인증을 위해 프로파일의 재설치 허용 여부를 질의하고, 그 결과를 회신하는 과정을 포함할 수도 있다. LPA1(510)이 SM-DP+(150)로부터 해당 인증 토큰을 수신(5b-60 단계)하면 LPA1(510)은 해당 정보를 ODSA1(500)에 전달하고 ODSA1(500)은 해당 인증 토큰을 단말 식별 정보와 함께 ECS(120)에 회신(5b-70 단계)할 수 있다.
ECS(120)는 수신된 인증 토큰에서 최초 생성(5b-20 단계)해 전달했던 Nonce 값의 유효성을 검증하고, SM-DP+서명 값을 검증(5b-80 단계)하여 이후 절차를 전술(5a-190 단계 내지 5a-230 단계)한 바와 같이 수행하여 기기 변경 절차를 완료할 수 있다. ECS(120)가 생성한 해당 Nonce값은 해당 인증 요청에 대한 재사용 여부 판단 및 해당 ECS(120)에서의 요청인지를 증명/검증하는 식별자로 사용될 수 있다. ECS(120)가 Nonce값이 포함된 메시지를 수신 받으면, ECS(120)는 해당 전달된 메시지가 최초 ECS에서 발생한 메시지에 대한 회신 값이라는 것과 해당 Nonce 값의 재 사용되지 않았는지 판단하는 과정을 포함하여 해당 Nonce 값의 유효성을 판단할 수 있다. 또한, 전술한 바와 같이, 해당 인증을 지원하는 ECS(120)는 SM-DP+서버(150)와 동일한 Root CI 인증서로 GSMA CI 인증서를 저장하고 있으므로, SM-DP+ 서명 값은 ECS 서버(120)가 가지고 있는 해당 CI 인증서로 검증할 수 있다(5b-80 단계). 또한, SM-DP+(150)와 ECS(120)가 GSMA의 Root CI 인증서를 가지고 있고, 해당 ECS(120)가 SM-DP+(150)와 동일 GSMA 인증서 체인에 있으므로 ECS(120)는 SM-DP+(150) 서버에 직접적인 연동이 없더라도 해당 인증을 지원할 수 있다.
도 5c는 통신사가 LPA 방식을 제공하며 제 1단말(구 단말)에서 LPA와 SM-DP+인증을 사용하는 실시 예를 나타내는 도면이다.
전술한 바와 같이 사용자(300)가 제 1단말(300)의 UI에서 이동할 프로파일을 선택하고 프로파일 이동 메뉴를 선택하면, 단말은 기기 변경 방식에 대한 Configuration 정보를 확인하여 LPA 방식으로 처리를 결정(5c-30 단계)할 수 있다. 기기 변경 방식에 대한 Configuration 정보를 확인에 대한 절차는 도 4에서 전술한 것과 동일하거나 또는 유사하므로 여기서의 상세 설명은 생략한다. LPA1(510)은 SM-DP+(150)와 상호 인증을 수행하고 나서 ES9+.AuthenticationClientRequest 메시지로 이동할 프로파일의 ICCID, 기기변경 Indicator를 포함하여 기기변경을 요청(5c-40 단계)할 수 있다. 해당 메시지를 수신한 프로파일서버(150)는 사업자 서버(130)에게 상기 ICCID에 대한 프로파일의 재설치 허용 여부를 질의하고, 그 결과를 회신하는 과정을 포함(5c-50 단계)할 수도 있다 또한, 해당 프로파일에 대한 사업자의 정책은 사업자 서버가 5c-20 단계을 시작하기 전 또는 5c-50 단계 의 과정 중의 하나로 하여 프로파일 서버에 알려줄 수도 있다. 통신사업자가 해당 ICCID에 대한 프로파일 기기변경을 지원하는 경우, SM-DP+와 사업자 서버(130)에 프로파일 주문, 준비, 생성을 처리(5c-60 단계)할 수 있다. 해당 메시지는 ES2+.DownloadOrder 또는 ES2+.ConfirmOrder 또는 ES2+.ReleaseProfile 명령메시지 일 수 있다. 해당 처리를 완료(5c-60 단계)하면, SM-DP+(150)서버는 ES9+.AuthenticationClientResponse 메시지로 TransferType, ServiceProviderMesage, 그리고 추가적으로 Activation Code를 포함하여 회신(5c-70 단계)할 수 있다. TranferType은 해당 사업자의 기기 변경 지원 방식에 대한 식별자로 해당 식별 정보로 신규 Activation Code 재발급을 통한 프로파일 다운로드 인지 아니면, 기존 프로파일을 삭제 처리하고 이에 대한 Delete Notification을 가지고 단말에서 해당 정보를 포함하여 Activation Code를 생성하고 프로파일 서버에서 추후에 해당 생성된 Activation Code에 포함된 일부 또는 전체의 Delete Notification을 통해서 검증할지 여부 등을 나타낼 수 있다. ServiceProviderMesage는 기기 변경을 위한 프로파일 처리 등을 사용자에게 안내하기 위한 데이터를 나타낸다. 사용자(100)가 최종적으로 기기 변경 절차 처리에 동의하는 경우(5c-80 단계), LPA1(510)은 SM-DP+(150)에 기기 변경 처리에 대한 사용자 답변을 포함하여 회신할 수 있다. 일 예로 ES9+.CancelSession (End User confirmation result) (5c-90 단계)메시지 일 수 있다. 5c-70 단계에서 수신된 통신사업자는 정책에 따라, 제 1단말(300)은 프로파일 이동 시 기존 설치된 프로파일을 삭제 처리하고 해당 삭제 메시지를 통해서 Activation Code를 단말에서 생성하여 활용하는 절차(5c-95 단계, 5c-100 단계)를 수행할 수 있다. 한편, 5c-95 단계 및 5c-100 단계 절차는 5a-200 단계와 같이 프로파일을 삭제에 대한 요청 (DeleteOldProfile)이 포함된 경우에도 제공할 수 있다. 제 1단말(300)은 프로파일을 삭제(5c-95 단계)하고, 생성된 Delete Notification 정보의 전부 또는 일부 정보를 이용하여 QR 코드는 구성하여 보여줄 수 있다(5c-100 단계). 사용자(100)가 로컬 프로파일 관리를 통해서 기기 변경을 위해 프로파일을 삭제하는 Input이 입력되면(예. 5d-40 단계 에서 OK 버튼 클릭), eUICC(160)는 프로파일을 삭제(5c-95 단계) 후 결과 메시지를 LPA1(510)에 전달할 수 있다. LPA1(510)는 제2 제어 메시지(예를 들어, ES10c.ListNotificationRequest 메시지)에 수신 받을 Event정보(NotificationEvent) 데이터에서 DeleteProfile을 의미하는 bit를 set해서 eUICC(160)에 전달할 수 있다. 상기 제2 메시지를 수신한 eUICC(160)는 DeleteProfile에 해당하는 모든 notification 정보를 LPA1(510)에 회신할 수 있다. 해당 notification은 처리순번정보(Sequence 또는 Seq 또는 seqNumber로 표기), 프로파일 ID(또는 iccid 또는 ICCID) 중 적어도 하나를 포함한다. LPA1(510)은 삭제한 프로파일과 대응되는 notification을 또는 Seq값을 선별하고 해당 Seq값을 포함한 제3 제어 메시지(예를 들어, ES10c.RetrieveNotification 메시지)를 eUICC에 보낼 수 있다. eUICC(160)는 저장된 Notification정보들 중 해당 Seq값에 대응되는 Notification 정보를 LPA1(510)에게 전달할 수 있다. 상기 Notification정보에 포함되는 정보는 다음 정보들 중 적어도 하나를 포함할 수 있다. 이후 제 1단말(300)은 상기 정보를 포함한 정보를 QR 코드로 Encoding 하여 보여줄 수 있다(5c-100 단계).
- seqNumber: 처리순번정보
- profileManagementOperation: 해당 프로파일이 삭제됐는지 구분자
- notificationAddress: 프로파일서버주소
- ICCID: 삭제된 프로파일 ID
- euiccNotificationSignature: 해당 프로파일의 ICCID를 증빙하고, 처리된 동작은 삭제됨을 의미하는 Indicator임을 증빙하고, 처리순번정보는 SEQ값임을 증빙하는데 사용되는 eUICC(160)의 디지털 서명
- eUICCCertificate: eUICC서명의 유효성을 증빙하는데 사용되는 eUICC인증서
- EUMCertificate: eUICC인증서의 유효성을 증빙하는데 사용되는 추가 인증서
한편, 이러한 QR 코드는 제 2단말(350)에 프로파일 다운로드 설치를 위해 전달할 정보인데, 본 발명의 실시 예에 의하면 제 2단말(350)은 QR 코드를 통해 얻은 정보의 일부 또는 전부를 최종적으로는 프로파일서버로 전달할 수 있다. 제 2단말(350)은 QR 코드를 스캔하여 프로파일 다운로드 절차를 개시할 수 있다(5a-230 단계). 5a-230 단계에서 프로파일 Delete Notification으로 Activation Code를 생성하지 않고 5c-95 단계 및 5c-100 단계에서 사업자로부터 Activation Code를 발급(5c-70 단계)받아서 설치하는 경우는 GSMA SGP.22에 v2에 정의된 절차에 따라 이후 프로파일 다운로드 절차를 수행할 수 있다. 만약, 5a-230 단계에서 5c-95 단계 또는 5c-100 단계와 같이 프로파일 삭제를 처리하고 해당 삭제 정보를 활용하는 경우에 있어서 제 2단말(350)은 QR 코드에 포함된 프로파일서버주소에 해당하는 프로파일서버로 해당 프로파일을 설치할 eUICC의 eUICCChallenge 값을 포함하여 InitiateAuthenticate 메시지를 전송할 수 있다. 해당 프로파일 서버에서는 해당 값을 검증하여 Transaction ID를 생성하고 Transaction ID와 eUICCChallenge 값이 포함된 데이터에 대한 프로파일 서버의 서명을 생성하여 회신할 수 있다. 이때 회신 하는 InitiateAuthenticate 회신 메시지는 상기 프로파일서명값, Transaction ID를 포함할 수 있다. 제 2단말(350)은 상기 InitiateAuthenticate 회신 메시지를 수신한 후, QR Code에 포함된 ICCID 및 제 1단말(300)의 eUICC서명데이터를 포함하는 Data와 이 데이터에 대해 제 2단말(350)의 eUICC가 서명한 eUICC 서명 데이터를 생성하여 AuthenticateClientRequest 메시지에 포함하여 프로파일서버에 전송할 수 있다. 프로파일서버(150)는 상기 AuthenticateClientRequest를 메시지를 수신하면 AuthenticateClientRequest메시지에 포함된 이동할 프로파일의 ICCID, 제 1단말(300)의 해당 프로파일이 설치된 eUICC의 서명Data 검증, 제 2단말(350)의 프로파일을 설치할 eUICC의 서명 Data 검증을 포함한 유효성 검증 과정을 수행하여, 해당 프로파일의 다운로드 여부를 결정하고, 해당 프로파일에 대응되는 ProfileMetadata를 포함한 데이터를 AuthenticateClientResponse 메시지에 포함하여 회신할 수 있다. 또한, 상기 제 1단말의 eUICC(160)의 서명Data 검증은 상기 ICCID및 추가적인 데이터를 포함한 Data(처리 순번번호, 프로파일삭제 구분자, 프로파일 서버 주소, 삭제된 ㅍ로파일 ICCID, eUICC 서명 값)에 대해서 상기 제 1단말(300)의 eUICC(160)의 인증서를 이용한 서명검증일 수 있다. 이후 제 2단말(350)은 상기 AuthenticateClientResponse 메시지를 수신하여 ProfileMetadata가 포함되어 있으면, 사용자에게 보여주는 UI를 통해 해당 프로파일의 수신을 동의 받는 과정을 수행하는 과정과, Confirmation Code 입력을 요청하여 입력 받는 과정과, 또한 eUICC의 one time Public key(otpk.eUICC)를 생성하는 과정 중 일부 또는 전체 과정을 수행할 수 있다. 이어 제 2단말(350)이 상기 otpk.eUICC를 포함하는 GetBoundProfilePackage Request 를 프로파일서버(150)에 전달하면, 프로파일서버는 otpk.eUICC를 활용하여 생성된 암호키로 암호화한 정보를 포함한 BoundProfilePackage 를 제 2단말(350)로 회신할 수 있다. 제 2단말(350)은 BoundProfilePackage 를 수신하면, 프로파일을 제 2단말(350)의 eUICC 내부에 설치하여 모든 절차를 완료할 수 있다.
도 5d는 제 1단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience에 대한 대표적인 처리 절차를 나타낸 도면이다. 도 5d는 도 5a 내지 도 5c의 절차 처리를 단말에 구현했을 때, 예상되는 사용자의 UI(User Interface) 및 UX(User Experience)의 일 예시이다. 숫자로 표기된 순서는 해당 절차 처리 순서이며, 3-A 내지 3-C로 표기된 순서는 해당 절차를 처리함에 있어 기기 변경 방식 및 사업자 지원 방식에 따라 분기되는 시점을 나타낸 것이다. 사용자(100)은 제 1단말(300)의 단말 설정 등의 메뉴를 통해서 현재 해당 단말에 설치된 SIM 카드 정보를 확인할 수 있다. 예를 들어 SIM카드와 eUICC에 저장된 프로파일의 정보를 1번 그림과 같이 사용자에게 보여 줄 수 있다. 해당 화면에서 사용자는 이동할 프로파일을 선택(5d-10 단계)하거나 또는 별도의 메뉴(예. 모두 이동) 등을 통해서 1개 이상의 프로파일을 선택할 수 있다. 해당 이동할 프로파일을 선택하면 5d-20 단계와 같이 해당 프로파일에 대한 어떤 명령을 처리할지를 단말이 수신할 수 있도록 별도의 메뉴 목록이 보여질 수 있으며 이 중의 하나로 기기 변경을 수행함을 나타내는 식별자로 별도 메뉴를 제공해 줄 수 있다. 해당 메뉴 진입은 신규 단말에서 처리하는 경우와 구별되게 메뉴를 처리하거나 또는 동일 기기 변경 메뉴에 진입을 하는 경우라도 단말에서 사용자가 이동할 프로파일을 선택하고 해당 메뉴를 선택하는 경우에 제 1단말(300)로 인식하여 처리할 수도 있다. 해당 프로파일에 대한 기기 변경을 선택하는 경우에, 제 1단말(300)의 LPA1(510)에서 eUICC에 ES10c.GetProfilesInfo() Function Call을 수행하여 프로파일의 메타데이터 정보를 가져옴으로써, 해당 프로파일의 통신사업자의 고유 식별 번호로 MCC+MNC를 확인할 수도 있다. 또한, 이 때 해당 프로파일의 상태 정보도 확인할 수 있다. 단말은 사용자의 Interaction 없이 단말에서 사용자가 이동할 프로파일의 사업자 식별 번호를 획득하고 또한 이와 함께 해당 프로파일의 메타데이터 등을 통해 획득한 소정의 정보를 통해서 2번과 같은 화면을 구성하여 표기해 줄 수 있다. 사용자(100)가 해당 2번 화면의 5d-20 단계와 같이 기기 변경 메뉴 선택을 통해 기기 변경 요청을 발생 시키면, 단말은 도 4에서 전술한 바와 같이 통신사업자의 기기 변경 지원 여부 및 방식을 포함한 기기 변경에 대한 사업자 설정 정보를 획득하기 위한 절차를 시작하여 이동할 프로파일의 메타데이터, 또는 단말의 메모리, 또는 별도 Configuration Server로부터 획득한 정보를 통해서 단말에서 사용할 기기 변경 방식을 확정할 수 있다. 사용자(100)가 기기 변경 메뉴 선택 시(5d-20 단계)의 제 1단말(300)은 5d-30 단계, 5d-40 단계, 5d-50 단계와 같이 기기 변경 방식 지원 여부 및 방식에 따라 서로 다른 화면을 보여줄 수 있다. 5d-30 단계는 선택한 프로파일의 통신사가 기기변경 방식을 지원하지 않는 경우에 화면에 표기에 대한 예를 나타낸 것이다. 도 5d에서는 명시하지 않았으나, 5d-10 단계에서 프로파일을 선택하였을 때, 단말이 메타데이터 또는 단말의 메모리에서 사업자의 기기 변경 설정 정보를 가져오고, 해당 정보에 기기 변경 지원에 대한 정보가 없는 경우에 5d-20 단계의 메뉴 자체에 기기 변경 메뉴를 선택적으로 노출하지 않게 처리할 수도 있다. 이 경우에 기기 변경 지원 사업자의 경우에만 해당 기기 변경 메뉴를 노출시킬 수도 있다. 또한, eSIM Transfer 메뉴를 진입하는 5d-20 단계의 시점에 사업자가 EAP-AKA 방식을 지원 정보와 프로파일 상태 정보에 대해 판단하여, EAP-AKA 방식을 지원을 위해서는 프로파일을 Enabled해야 함을 사용자에게 알려줄 수도 있다. 단말이 5d-10 단계와 5d-20 단계에서 획득한 정보를 통해 확인한 결과로 LPA 방식으로 처리를 결정하는 경우, 해당 제 1단말(300)은 도 5c와 같이 SM-DP+를 통해 인증을 처리하고 LPA에 사전 설정되었거나 또는 SM-DP+를 통해 수신한 사업자 메시지를 단말 화면에 표시할 수 있다. 일 예로 5d-40 단계와 같이 해당 프로파일 이동에 대한 기존 프로파일 삭제에 대한 사용자 동의를 처리하기 위한 메시지를 표시해 줄 수 있다. 한편, 단말이 5d-10 단계와 5d-20 단계에서 획득한 정보를 통해 확인한 결과로 ODSA 방식으로 처리를 결정하는 경우, 단말은 단말의 ODSA Client인 ODSA1(500)을 trigger하여 ODSA1(500)에서 ECS(120)에 기기변경 요청을 요청(5a-50 단계)하여 도 5a 또는 도 5b와 같이 가입자 인증을 수행하고 해당 가입자 수행 인증을 결과로 가입자가 인증되는 경우에, 5d-50 단계와 같이 이동할 (프로파일의) 통신 서비스의 기기 이동 처리를 위한 정보에 대한 사업자의 웹 화면을 보여줄 수 있다. 해당 웹 화면의 구성은 사업자에 따라 달라질 수 있다. 만약 ODSA1(500)에서 ECS(120)로 단말에서 인증 식별자 없이 기기 변경 요청하는 경우에, ECS(120)는 도 6a의 6a-140단계와 같이 가입자 인증 방식으로 OAuth/Open ID를 선택할 수 있다. 또한, 전술한 바와 같이 ECS(120)가 하나의 방법을 선택할 수도 있는데, 예를 들어 단말에서 요청한 인증 방식에 EAP-AKA 요청을 하는 식별자로 EAP_ID를 전송하였으나 이를 수신한 ECS에서 AAA서버와의 Relay를 지원하지 않는 등 이유로 이를 처리하지 못하지만, OAuth/Open ID를 지원하는 경우 OAuth/Open ID로 처리를 요청하도록 최초 Http(s) Response - 302 Found에 client id와 redirection URI를 포함하여 회신할 수도 있다.
이 경우, 단말은 ECS(120)로부터 사용자의 ID와 패스워드 입력을 요청하는 로그인 페이지 (즉, redirection URI)를 회신 받아 사용자 화면에 Display(6c-70 단계)하여 ID 및 패스워드로 가입자 인증을 처리하고 나서, 5d-50 단계와 같은 화면으로 이동할 수 있다. EAP-AKA 방식 또는 ECS&DP+인증 방식을 전술한 바와 같이 단말 설정, 사용자 선택 또는 ECS 선택을 통해 결정한 경우에 사용자는 ID 생성 등과 같은 단말 UI에서의 Interaction 없이 가입자 인증 처리를 완료할 수 있다. LPA 또는 ODSA 방식으로 기기 변경을 진행하여 가입자 인증까지 완료되면, 제 1단말(300)은 Activation Code를 생성하여 제 2단말(350)에서 이를 획득하는 방법과 함께 제공(5d-60 단계)할 수 있다. 5d-60 단계에서는 이를 QR 코드 형태로 제공하는 방법을 도시하였으나 단말간 전송 프로토콜을 통해서 Activation Code 정보를 전달할 수도 있다. 이제 사용자(100)는 (5d-60 단계)에서 제공된 방법을 통해서 제 2단말(350)의 LPA2(530)에 Activation Code 정보를 입력할 수 있다(5d-70 단계 및 5d-80 단계). 해당 정보가 입력되면 제 2단말(350)은 앞서 5a-230 단계에 전술한 바와 같이 프로파일 다운로드 및 설치하여 완료하고 해당 완료되면 사용자는 5d-90 단계의 예와 같이 제 1단말(300)에서 통신프로파일의 재설치가 완료되었음을 확인할 수 있다. 한편, 5d-100 단계와 같이 기기 변경 처리가 완료된 프로파일은 제 1단말(300)의 사업자 정책 및 삭제 처리에 대한 사용자의 동의에 따라 제 1단말(300)의 프로파일 리스트에서 삭제 처리되어 더 이상 사용자에게 노출되지 않게 처리할 수 있다.
도 6a 내지 도 6c 는 제 2단말(신 단말)에서 사용자가 기기 변경을 시작하는 절차들을 도시하는 도면이다. 도 6a는 통신사가 ODSA 방식을 제공하며 OTP 또는 OAuth/Open ID 인증을 사용하는 실시 예를 나타내는 도면이다. End User(100)가 제 2단말(350)에서 사용자가 기기변경을 진행할 통신사를 선택하고, 단말이 도 4에서 언급한 바와 같이 Configuration 정보를 획득함으로써, 단말에서 ODSA 방식으로 이후 기기 변경 처리를 결정(6a-30 단계)할 수 있다. 도 4에서 Configuration 정보 획득에 대한 상세 방법을 전술하였으므로 여기서는 추가 설명을 생략한다. 제 2단말(350)에서는 SMS 수신이 가능한 사용자 보유 단말이 있는지에 대한 메뉴를 생성하여 표시하고(6a-40 단계), 사용자(100)는 기존 단말(300)을 통해 인증 코드 수신이 가능한 경우에 모바일 네트워크에서 가입자를 식별하는 고유 번호인 가입자 전화 번호 즉, MSISDN을 화면에 입력(6a-60 단계)할 수 있다. 한편, 앞서 명시하지 않았으나, 단말의 ODSA(110)과 ECS(120) 간에는 HTTP(s)기반의 메커니즘을 사용하여 메시지를 주고 받는다. 해당 입력을 받은 제 2단말(350)의 ODSA2(520)은 해당 요청 단말(350)의 IMEI와 제 1단말(300)의 MSISDN를 포함하여 인증 요청 Https Request 메시지를 ECS(120)로 전송(6a-70 단계)할 수 있다. 해당 메시지를 전송 받은 ECS(120)는 해당 메시지를 parsing하여 MSISDN값이 있는 경우에, ECS(120)는 End User(100)가 제공한 전화번호(MSISDN)로 OTP를 전송(6a-90 단계)하는 한편, HTTP(S) 200 OK 에 Cookie를 포함하여 ODSA2(520)에 전송(6a-80 단계)할 수 있다. 해당 ODSA2(520)은 End User(100)가 제 1단말(300)을 통해 수신하여 입력한 OTP 파라미터와 이전의 HTTP 200 OK response로부터 수신된 Cookie를 포함하여 새로운 Get Request를 ECS(120)에 회신(6a-110 단계)할 수 있다. ECS(120)는 수신된 OTP를 검증하고, ECS에서 새로운 인증토큰(AuthToken)을 생성하여 ODSA2(520)에 회신(6a-120 단계)할 수 있다. 이후 ODSA2(520)는 해당 인증토큰을 포함하여 기기 변경을 ECS(120)에 요청(6a-130 단계)할 수 있다. 전술한 바와 같이 기기 변경 처리를 위한 프로파일 설치를 위한 기기 변경 설정 정보를 획득하고 단말의 서비스 상태를 검증하기 위해서 ODSA(110)은 ECS(120)에 HTTP(s) Request를 전송하면 ECS(120)에서는 해당 요청을 처리하여 ODSA(110)에서 결과값을 회신할 수 있다. 한편, ECS(120)는 수신된 Get request에서 EAP_ID, DP+AuthSupport, 또는 MSISDN이 포함되지 않았거나 또는 단말에서 제공하는 해당 또는 다른 인증 하는 수단이 사용 가능하지 않다고 표기된 경우에, OAuth/Open ID 인증(6a-140 단계)을 단말에 요청할 수 있다.
다음에서는 OAuth/Open Id 인증(6a-100 단계) 수행에 대한 방법을 좀 더 상세하게 설명한다. 제 2단말(350)에서 시작하는 경우에 기존 단말(300)이 사용 불가(6a-40 단계)하여 ECS(120)에서 MSISDN 정보를 수신하지 못하면, ECS(120)는 사용 가능한 인증 수단이 없으므로 해당 수신 받은 GET request를 단말의 ODSA Client로부터 Service Provider의 인증 서버로 재전송하기 "302 Found" 를 Response로 회신할 수 있다. 해당 "302 Found"에 Open ID 처리를 위해 Redirect할 인증 포인트의 URL 주소를 전술한 바와 같이 Header의 Location 값으로 전송할 수 있다. 또한, "302 Found"의 본문 메시지로, response type=code와 함께 scope의 value로 "openid"를 포함하여 scope= openid 와 같이 회신할 수 있다. 'openid'는 Scope 파라미터가 가질 수 있는 값 중의 하나로, 애플리케이션이 Open ID Connect 표준 프로토콜을 사용자 신원 확인에 사용하고자 함을 나타낼 수 있다. Response type=code는 해당 Location에 표기된 인증 서버로부터 code를 회신해야 함을 나타내는 식별자로 사용될 수 있다.
Open ID 인증 서버(Redirect할 인증 포인트)는 해당 서비스 사업자의 정책에 따라 인증 방식을 선택(추가적인 SMS 인증 등)해 사용자(100)를 인증하고 이에 대한 결과로 code값을 회신할 수 있다. 여기서는 OAuth2.0 인증코드(접속 토큰으로 교환을 위해 제공되는 임시 코드)를 단말에 회신할 수 있다. 단말은 ECS(120)에 "302 Found"에 대한 회신 값으로 해당 인증코드를 포함하여 송신한다. ECS(120)가 해당 인증코드를 받으면, ECS(120)는 해당 인증코드를 Open ID 인증 서버에 송신하여 접속 토큰과 ID 토큰을 요청할 수 있다. Open ID 인증 서버가 OAuth2.0 인증코드를 검증하여 승인되면, ECS(120)에 접속 토큰과 ID 토큰을 회신할 수 있다. ECS(120)는 해당 토큰 값들을 가지고 해당 사용자의 가입자 정보를 확인할 수 있고 original GET resource 요청을 재개하여 기기 변경에 대한 이후 절차를 수행할 수 있다. ECS(120), SM-DP+(150), MNO BSS/OSS(130)간 가입자의 통신서비스에 대한 가입자 정보 업데이트와 프로파일 생성에 대한 절차는 앞서 도 5a에서 설명한 바 있으므로 자세한 설명은 생략한다. 한편, 해당 절차를 처리하고 나서 ECS(120)는 MNO BSS/OSS(130) 또는 SM-DP+(150)로부터 해당 프로파일의 다운로드에 필요한 소정의 정보로 Activation Code를 전달 받아 이를 ODSA2(520)에 전송해 주고, ODSA2(520)가 LPA API를 통해 해당 에 Activation Code 정보를 LPA2(530)에 전달함으로써, LPA2(530)가 SM-DP+(150)에서 프로파일 다운로드를 Trigger하여 GSMA SGP.22에 정의된 절차에 따라서 프로파일 다운로드 및 설치를 처리를 완료(5a-230 단계)할 수 있다.
도 6b는 통신사가 LPA 방식을 제공하며 제 1단말(구 단말)에서 LPA와 SM-DP+인증을 사용하는 실시 예를 나타내는 도면이다.
도 5a에서 전술한 바와 End User(100)가 제 2단말에서 사용자가 기기변경을 진행할 통신사를 선택하고, 단말이 도 4에서 언급한 바와 같이 Configuration 정보를 획득하여 해당 조합을 통해, 사업자의 기기 변경 방식을 LPA임을 확인할 수 있다. 단말은 이 경우 LPA 방식으로 처리(6b-10 단계)를 결정하여 진행할 수 있다. 제 2단말(350)에서 본 발명을 개시하는 현 시점에는 LPA 방식을 처리할 수 있는 방법이 없으므로, 단말은 사용자에게 기존 단말의 사용 여부를 확인하는 메시지를 제 2단말(350)의 화면에 Display(6b-20 단계)할 수 있다. LPA 기반 기기 변경 방식은 기존 단말의 프로파일 상태 정보와 관계 없이 제공 가능하므로, 6b-20 단계에서의 기존 단말의 사용 여부 메시지는 6a-40 단계와 다르게 처리할 수 있다. 예를 들어 6a-40 단계의 메시지는 기존 단말의 사용 여부 및 SMS 수신 가능한 단말인지 여부를 함께 확인할 수 있으나, 6b-20 단계에서는 기존 단말의 사용 여부만 확인하여 처리가 가능할 수 있다. 사용자가 해당 제 2단말(350)에서 제 1단말(300)의 사용이 가능하다고 입력 (6b-30 단계)한 경우, 제 2단말(350)은 6b-40 단계과 같이 제 1단말(300)에서 LPA 절차를 통해 기기 변경 절차를 처리하도록 할 수 있다. 한 예로, 사용자(100)가 이후 절차를 제 1단말(300)에서 진행할 수 있도록 제 2단말(350)의 화면에 제 1단말(300)에서 도 5c의 5c-10 단계에서 5c-100 단계의 절차로 처리(6b-50 단계)하라고 안내 메시지를 생성하여 표기한 다음에, 제 2단말(350)의 화면은 Activation Code 수신을 위한 LPA2(530)의 화면으로 이동하여 대기할 수 있다. 해당 처리에 대한 UI/UX는 도 6c에서 후술하기로 한다. 사용자(100)는 이제 5c에서 전술한 바와 같이 제 1단말(300)에서 LPA 기반 기기 변경을 처리하고 Activation Code를 수신(5c-70 단계) 또는 생성(5c-100 단계)하여 화면에 Display하게 되면, 제 2단말(350)은 LPA2(530)에서 카메라를 통해 해당 Display된 Activation Code 스캔(5c-110 단계)을 통해 해당 정보를 입력 받아 Activation Code에서 추출한 SM-DP+서버 주소로 접속, 프로파일 다운로드 및 설치를 완료할 수 있다. 만약 단말이 사용자가 제 1단말(300)이 없다고 입력 받는 경우(6b-30 단계), 단말은 통신사업자로 문의하라는 사용자 안내 메시지를 표시하고(6b-50 단계) 모든 절차를 종료할 수 있다.
도 6c는 제 2단말에서 시작하는 eSIM 기기 변경에 대한 UI(User Interface) 및 UX(User Experience에 대한 대표적인 처리 절차를 나타낸 도면이다. 도 6c는 사용자가 제 2단말(350)에서 기기변경을 시작하는 경우로 도 6a 및 도 6b가 구현된 UI/UX를 대표적으로 나타낸 도면이다. 해당 제 2단말(350)에서 시작하는 시나리오에서 핸드폰 화면의 (4-A, 4-B)와 (6-A, 6-B)는 대표적으로 분기되는 시점을 나타낸다. 사용자가 제 2단말(350)에서 기기변경을 메뉴에 진입(6c-20 단계)하면 단말은 도 4에서 전술한 바와 같이, 기기 변경에 대한 사업자 Configuration 정보를 수집하여 화면에 표시할 수 있다(6-30 단계). 예를 들어, Configuration Server를 이용(도 4의 옵션 2 및 옵션 3)하거나 메모리에 저장된 정보(도 4의 옵션 4)를 통해 획득한 모든 통신사업자 정보를 나열할 수 있고, 또는 해당 정보에서 추가적으로 단말의 위치 정보 등을 조합하여 해당 지역에서 기기변경을 제공 가능한 사업자 만을 추출한 다음에 화면에 해당 리스트를 노출할 수도 있다. 다른 예로, 사용자(100)가 프로파일 이동을 진행할 통신사업자 정보를 제공하면, 도 4의 옵션 2와 같이 단말에서 해당 선택한 통신사업자 이름 또는 해당 통신사업자의 MCC+MNC를 Configuration Server 또는 단말에 메모리에서 확인하여 맵핑 되는 사업자의 정보만을 선택적으로 띄워줄 수도 있다. 이 경우에, 확인하여 만약 해당 사업자가 기기 변경을 지원하지 않는 경우, 도 6c에서는 도시하지 않았으나, 6c-30 단계 다음에 6c-40 단계 또는 6c-90 단계로 진입하지 않고 별도 안내 메시지를 화면에 띄워주고 해당 절차를 종료할 수 있다. 6c-30 단계에서 사용자(100)이 사업자를 선택하면 확인한 해당 사업자의 기기변경 지원 방식에 따라 단말은 6c-40 단계 또는 6c-90 단계의 화면으로 분기하여 처리할 수 있다. 6c-40 단계로 처리시는 선택 통신사가 ODSA 기반 기기 변경을 지원하는 경우로 이 때, 단말은 6c-50 단계와 같이 기존 단말의 보유 여부에 대한 추가 메뉴를 제공하고 사용자의 응답에 따라 단말에서 제공하는 SMS-OTP 인증 진행 화면(6c-60 단계) 또는 ECS(120)로부터 302 Found Http(s) Response 를 통해 수신된 Location Header에 있는 URL로 연결 처리하여, 사업자 제공 화면(6c-70 단계)을 표시할 수 있다. 해당 인증 방식에 따라 가입자 인증이 처리 완료되면, 제 2단말(350)의 통신서비스 가입 앱 또는 웹 포탈에서 Activation Code 정보를 수신하여, LPA2(530)로 LPA API를 통해 해당 Activation Code 정보를 전달하고, 이를 수신한 LPA2(530)가 프로파일 다운로드 처리/설치를 모두 완료하면, 6c-80 단계와 같이 이동할 프로파일이 설치되었음으로 사용자(100)에게 표기하여 보여줄 수 있다. 한편, 6c-30 단계를 통해서 단말이 판단한 사업자의 기기 변경 지원 방식이 LPA 방식인 경우에, 제 2단말(350)에서는 6c-90 단계와 같이 사용자에게 기존 단말(300)의 보유 여부에 따라 처리 여부가 달라짐을 알려주고 만약 기존 단말(300)이 사용 불가한 경우, 6c-100 단계와 같이 사업자 Contact 메시지를 띄우고 모든 절차를 종료할 수 있다. 한편, 사용이 가능하다고 응답하는 경우에, 추가적인 안내 메시지를 생성하여 사용자가 제 1단말(300)에서 처리할 수 있도록 안내하고 Scan QR 코드 등 Activation Code가 입력을 위한 절차에서 대기할 수 있다(6c-110 단계). 단말의 설정에 따라 Timer를 통해 사용자의 응답(예. Activation Code 입력)이 일정 시간 동안 발생하지 않는 경우에 단말은 사용자 안내 메시지를 띄우고 기기 변경 절차를 종료하거나 대기를 연장할 수 있다. 한편, 사용자는 도 5d에서의 제 1단말(300)에서 LPA 처리 절차를 따라서 기기 변경을 진행하고 Activation Code를 발급받으면, 6c-110 단계의 예와 같이 제 2단말(350)에서 Activation Code 수신을 위한 메뉴 선택을 통해 도 5d의 이후 절차를 처리하여 기기 변경을 완료할 수 있다.
도 7은 본 발명의 실시 예에 따른 무선 통신 시스템에서 단말의 블록 구성을 도시하는 도면이다.
도 7을 참고하면, 단말(700)은 송수신부(710), 메시지 처리부(720), 프로세서(제어부)(730), 메모리(740), 화면 표시부(750)를 포함한다. 다만 단말(700)의 구성 요소가 전술한 예에 한정되는 것은 아니다. 예를 들어, 기지국은 전술한 구성 요소보다 더 많은 구성 요소를 포함하거나 더 적은 구성 요소를 포함할 수 있다. 뿐만 아니라, 단말(700)의 적어도 하나의 구성이 하나의 칩 형태로 구현될 수 있다. 일부 실시예에 따르면, 송수신부(transceiver)(710)에는 신호의 대역 변환, 증폭 등 무선 채널을 통해 신호를 송수신하기 위한 기능을 수행할 수 있다. 즉, 송수신부(710)는 기저대역 신호를 RF 대역 신호로 상향 변환한 후 안테나를 통해 송신하고, 안테나를 통해 수신되는 RF 대역 신호를 기저대역 신호로 하향 변환하는 RF 처리부를 포함하며, 송신 필터, 수신 필터, 증폭기, 믹서(mixer), 오실레이터(oscillator), DAC(digital to analog convertor), ADC(analog to digital convertor) 등을 더 포함할 수 있다.
또한, 송수신부(710)는 무선 채널을 통해 신호를 수신하여 프로세서(730)로 출력하고, 프로세서(730)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다. 도 7에서 하나의 안테나만이 도시되었으나, 상기 단말은 다수의 안테나들을 구비할 수 있다. 또한, 송수신부(710)에는 복수의 RF 체인들을 포함할 수 있다.
송수신부(710)는 빔포밍(beamforming)을 수행할 수 있다. 빔포밍을 위해, 송수신부(710)는 복수의 안테나들 또는 안테나 요소(element)들을 통해 송수신되는 신호들 각각의 위상 및 크기를 조절할 수 있다. 또한 송수신부(710) 내의 기저대역 처리부는 시스템의 물리 계층 규격에 따라 기저대역 신호 및 비트열 간 변환 기능을 수행할 수 있다. 예를 들어, 데이터 송신 시, 기저대역 처리부는 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성한다. 또한, 데이터 수신 시, 기저대역 처리부는 RF처리부로부터 제공되는 기저대역 신호를 복조 및 복호화를 통해 수신 비트열을 복원한다. 예를 들어, OFDM(orthogonal frequency division multiplexing) 방식에 따르는 경우, 데이터 송신 시, 기저대역 처리부는 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성하고, 복소 심벌들을 부반송파들에 매핑한 후, IFFT(inverse fast Fourier transform) 연산 및 CP(cyclic prefix) 삽입을 통해 OFDM 심벌들을 구성한다.
또한, 데이터 수신 시, 기저대역 처리부는 RF처리부로부터 제공되는 기저대역 신호를 OFDM 심벌 단위로 분할하고, FFT(fast Fourier transform) 연산을 통해 부반송파들에 매핑된 신호들을 복원한 후, 복조 및 복호화를 통해 수신 비트열을 복원할 수 있다.
송수신부(710)는 송수신기(transceiver)로 정의될 수 있으며, 메시지 송수신부를 포함할 수 있다. 메시지 처리부(720)는 송수신부(710)를 통해 송신하거나 혹은 수신한 데이터가 어떠한 메시지인지를 판단하는 동작을 수행할 수 있다. 예를 들어, 상기 메시지 처리부(720)는 수신한 메시지가 (SIB(System Information Block)를 포함한) RRC(Radio Resource Control) 계층의 제어 메시지인지 혹은 사용자의 데이터 메시지인지를 판단할 수 있다. 메시지 처리부(720)는 제어부(730)에 포함될 수 있다.
제어부(730)는 단말(700)의 전반적인 동작들을 제어한다. 예를 들어, 제어부(730)는 메시지 처리부(720)를 통해 신호를 송수신한다. 또한, 제어부(730)는 메모리(740)에 데이터를 기록하고 읽는다. 제어부(730)는 적어도 하나일 수 있다. 예를 들어, 제어부(730)는 통신을 위한 제어를 수행하는 CP(communication processor) 및 응용 프로그램 등 상위 계층을 제어하는 AP(application processor)를 포함할 수 있다. 일부 실시 예에 따르면, 메모리(740)에 사전에 저장된 기기 변경에 대한 사업자 Configuration 정보가 있는 경우에 제어부(730)는 해당 정보를 메모리(740)에 요청하여 화면 표시부(750)가 표시하거나 해당 정보를 받아서 추가적인 동작을 처리할 수 있다.
상기 제어부(730) 및 메시지 처리부(720), 송수신부(710)는 사용자 또는 단말 설정에 따라 선택한 사업자 망으로의 접속을 수행하도록 단말(700)을 제어할 수 있다. 또한, 일부 실시예에 따르면, 제어부(730)는 메모리(740)를 통해서 읽은 데이터 기록, 또는 제어부(730) 및 메시지 처리부(720), 송수신부(710)를 통해 수집된 정보를 매칭하여 서비스 선택에 참조할 수 있는 정보를 단말이 추론하는 처리 과정을 수행할 수 있다. 일부 실시예에 따르면, 제어부(730)는 단말(700)에 저장된 특정 정보에 대한 사용자 동의가 필요한지 여부를 판단하고, 화면 표시부(750)에 표시할 수 있다.
또한, 제어부(730)는 이에 대응하는 동작을 수행하도록 단말(700)을 제어할 수 있다. 일부 실시 예에 따르면, 제어부(730)는 eUICC의 구동 및 제어를 담당하는 LPA, 통신서비스 가입 및 기기 변경 처리를 위한 ODSA Client, 그리고 LPA 또는 ODSA Client 또는 이 둘이 통합 구현된 애플리케이션을 포함할 수 있다. 또한, 제어부(730)는 제어부(730), 메모리(740)를 통해 기기 변경에 필요한 소정의 정보를 취득하여 통신 서비스 기기 변경을 위해 LPA 또는 ODSA Client 동작이 필요한지를 판단하여 이후 과정을 처리할 수 있다. 또한, 제어부(730)는 메시지 처리부(720), 송수신부(710)를 통해 수집된 통신사업자가 제공 가능한 기기 변경 정보를 취득하여, 단말(700)의 메모리(740)를 통해 파악한 기기 변경 추가 정보 및 제어부(730)를 통해 취득한 프로파일 상태 정보와 결합하여 LPA 또는 ODSA 기기 변경 방식 중 어떤 방식으로 처리할 지와 어떤 인증 방식을 적용할 지 단말(700)을 제어할 수 있다.
제어부(730)는 메시지 처리부(720), 송수신부(710), 메모리(740)로부터 취득한 단말의 Capability 정보. 사업자의 기기변경 방식 정보와 화면 표시부(750)에서 입력된 소정의 정보를 조합하여 단말에서 프로파일 이동을 지원할지 여부를 판별하고 지원하는 경우에, 제 1단말 또는 제 2단말의 역할로 수행할지, 그리고 어떤 기기 변경 방식 절차로 진행할지를 여부를 판별할 수 있다.
제어부(730)는 메모리(740)에 기기 변경에 대한 사업자의 기기 변경 지원 여부, 지원 방식 및 지원을 위해 연결할 Configuration Server 주소, ECS 또는 DP+서버 주소, 또는 지원하는 가입자 인증 방식 등을 확보하기 위한 요청을 전송하여 처리하도록 단말(700)을 제어할 수 있다. 일부 실시 예에 따르면, 단말의 인증 방식 지원 Capability에 추가적으로 기기변경 Configuration 정보를 메모리(740)로부터 받아 메시지 처리부(720) 및 메시지 송수신부(710)을 통해서 ECS 서버로 정보를 전송하거나 특정 파라미터를 선택하여 메시지 처리부(720) 및 메시지 송수신부(710)을 통해서 정보를 전송할 수 있다. 또한, 프로세서(740)는 단말이 EAP-AKA 기능을 해당 시점에서 제공하지 못한다고 판단하는 경우(예를 들어 프로파일이 비 활성화 되어 있는 경우), EAP-AKA 처리를 위한 동작을 제한하도록 단말(700)을 제어할 수 있다.
메모리(740)는 단말(700)의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 메모리(740)는 단말에 내장된 하드웨어 보안 모듈인 UICC, eUICC, iSSP, iUICC를 포함할 수 있다. 실시 예에서는 메모리(740)는 롬(ROM), 램(RAM), 하드디스크, CD-ROM 및 DVD 등과 같은 저장 매체 또는 저장 매체들의 조합으로 구성되며 제어부(730)의 요청에 따라 Transfer Configuration 등 저장된 데이터를 제공할 수 있다. 또한, 메모리(740)은 제어부(730)와 SoC(System on Chip)으로 통합 구현되어 있을 수 있다.
화면 표시부(750)는 제어부(730)에서 처리/가공한 정보를 표시하거나 제어부(730) 처리를 통해 단말(700)이 수행하는 동작에 대한 진행 과정 또는 사용자에게 수행을 요청하는 event에 대한 동의 등을 표시할 수 있다. 일부 실시 예에 따르면, 저장된 프로파일 정보, 프로파일 기기간 이동 메뉴, Activation Code에 대한 입력 및 입력된 결과를 사용자에게 회신하여 표시할 수 있다. 일부 실시 예에 따르면, LPA 또는 ODSA 애플리케이션, 또는 이 둘이 통합 구현된 애플리케이션은 화면 표시부(750)와 제어부(730)를 포함할 수 있다. 물론 상기 예시에 제한되지 않는다.
상술한 본 개시의 구체적인 실시 예들에서, 본 개시에 포함되는 구성 요소는 제시된 구체적인 실시 예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위 뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (15)

  1. 무선 통신 시스템에서 단말에 의해 수행되는 방법에 있어서,
    기기 변경과 관련된 정보를 획득하는 단계;
    상기 기기 변경과 관련된 정보를 기반으로, 기기 변경 방식을 결정하는 단계;
    서버로, 상기 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 전송하는 단계로서, 상기 서버는 상기 기기 변경과 관련된 정보를 기반으로 식별되는, 상기 제 1 메시지를 전송하는 단계; 및
    상기 서버로부터, 상기 서버에 의해 상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로 결정된 인증 방식을 포함하는 제2 메시지를 수신하는 단계를 포함하는 방법.
  2. 제1항에 있어서,
    상기 기기 변경 방식은 ODSA(On Device Service Activation) 방식 또는 LPA(Local Profile Assistant) 방식 중 적어도 하나인 것을 특징으로 하는 방법.
  3. 제1항에 있어서,
    상기 기기 변경과 관련된 정보는 제2 서버에 의해 수신된 정보, 상기 단말에 미리 저장된 정보, 프로파일 메타 데이터 정보 중 적어도 하나를 통하여 획득되는 것을 특징으로 하는 방법.
  4. 제1항에 있어서,
    상기 인증 방식은 SM-DP+(Subscription Manager Data Preparation plus)를 사용하는 인증, EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement) 인증, ECS(Entitlement Configuration Server) 와 상기 SM-DP+를 사용하는 인증, OAuth/Open ID 프로토콜 기반 인증 중 적어도 하나인 것을 특징으로 하는 방법.
  5. 무선 통신 시스템에서 서버에 의해 수행되는 방법에 있어서,
    단말로부터, 상기 단말에 의해 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 수신하는 단계;
    상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로, 처리 가능한 인증 방식을 결정하는 단계; 및
    상기 단말로, 상기 결정된 인증 방식을 포함하는 제2 메시지를 전송하는 단계를 포함하고,
    상기 기기 변경 방식은 상기 단말에 의해 획득된 기기 변경과 관련된 정보를 기반으로 결정되는 것을 특징으로 하는 방법.
  6. 제5항에 있어서,
    상기 기기 변경 방식은 ODSA(On Device Service Activation) 방식 또는 LPA(Local Profile Assistant) 방식 중 적어도 하나인 것을 특징으로 하는 방법.
  7. 제5항에 있어서,
    상기 기기 변경과 관련된 정보는 제2 서버에 의해 수신된 정보, 상기 단말에 미리 저장된 정보, 프로파일 메타 데이터 정보 중 적어도 하나를 통하여 획득되는 것을 특징으로 하는 방법.
  8. 제5항에 있어서,
    상기 인증 방식은 SM-DP+(Subscription Manager Data Preparation plus)를 사용하는 인증, EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement) 인증, ECS(Entitlement Configuration Server) 와 상기 SM-DP+를 사용하는 인증, OAuth/Open ID 프로토콜 기반 인증 중 적어도 하나인 것을 특징으로 하는 방법.
  9. 단말에 있어서,
    적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및
    상기 송수신부와 결합된 제어부를 포함하고,
    상기 제어부는:
    기기 변경과 관련된 정보를 획득하고,
    상기 기기 변경과 관련된 정보를 기반으로, 기기 변경 방식을 결정하고,
    서버로, 상기 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 전송하고, 상기 서버는 상기 기기 변경과 관련된 정보를 기반으로 식별되고, 및
    상기 서버로부터, 상기 서버에 의해 상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로 결정된 인증 방식을 포함하는 제2 메시지를 수신하도록 구성되는 것을 특징으로 하는 단말.
  10. 제9항에 있어서,
    상기 기기 변경 방식은 ODSA(On Device Service Activation) 방식 또는 LPA(Local Profile Assistant) 방식 중 적어도 하나인 것을 특징으로 하는 단말.
  11. 제9항에 있어서,
    상기 기기 변경과 관련된 정보는 제2 서버에 의해 수신된 정보, 상기 단말에 미리 저장된 정보, 프로파일 메타 데이터 정보 중 적어도 하나를 통하여 획득되는 것을 특징으로 하는 단말.
  12. 제9항에 있어서,
    상기 인증 방식은 SM-DP+(Subscription Manager Data Preparation plus)를 사용하는 인증, EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement) 인증, ECS(Entitlement Configuration Server) 와 상기 SM-DP+를 사용하는 인증, OAuth/Open ID 프로토콜 기반 인증 중 적어도 하나인 것을 특징으로 하는 단말.
  13. 서버에 있어서,
    적어도 하나의 신호를 송수신을 할 수 있는 송수신부; 및
    상기 송수신부와 결합된 제어부를 포함하고,
    상기 제어부는:
    단말로부터, 상기 단말에 의해 결정된 기기 변경 방식을 통해 인증과 관련된 정보 및 상기 단말의 식별자를 포함하는 제1 메시지를 수신하고,
    상기 인증과 관련된 정보 및 상기 단말의 식별자를 기반으로, 처리 가능한 인증 방식을 결정하고, 및
    상기 단말로, 상기 결정된 인증 방식을 포함하는 제2 메시지를 전송하도록 구성되고,
    상기 기기 변경 방식은 상기 단말에 의해 획득된 기기 변경과 관련된 정보를 기반으로 결정되는 것을 특징으로 하는 서버.
  14. 제13항에 있어서,
    상기 기기 변경 방식은 ODSA(On Device Service Activation) 방식 또는 LPA(Local Profile Assistant) 방식 중 적어도 하나인 것을 특징으로 하는 서버.
  15. 제13항에 있어서,
    상기 기기 변경과 관련된 정보는 제2 서버에 의해 수신된 정보, 상기 단말에 미리 저장된 정보, 프로파일 메타 데이터 정보 중 적어도 하나를 통하여 획득되고, 및
    상기 인증 방식은 SM-DP+(Subscription Manager Data Preparation plus)를 사용하는 인증, EAP-AKA(Extensible Authentication Protocol for 3rd Generation Authentication and Key Agreement) 인증, ECS(Entitlement Configuration Server) 와 상기 SM-DP+를 사용하는 인증, OAuth/Open ID 프로토콜기반 인증 중 적어도 하나인 것을 특징으로 하는 서버.
PCT/KR2021/006757 2020-05-29 2021-05-31 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치 WO2021242071A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180039118.3A CN115699837A (zh) 2020-05-29 2021-05-31 移动通信系统中终端之间传送网络接入信息的方法及装置
US17/999,759 US20230209340A1 (en) 2020-05-29 2021-05-31 Method and apparatus for transferring network access information between terminals in mobile communication system
EP21814202.4A EP4142319A4 (en) 2020-05-29 2021-05-31 METHOD AND APPARATUS FOR TRANSFERRING NETWORK ACCESS INFORMATION BETWEEN TERMINALS IN A MOBILE COMMUNICATION SYSTEM

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20200064948 2020-05-29
KR10-2020-0064948 2020-05-29
KR10-2020-0103768 2020-08-19
KR1020200103768A KR20210147822A (ko) 2020-05-29 2020-08-19 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2021242071A1 true WO2021242071A1 (ko) 2021-12-02

Family

ID=78744814

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/006757 WO2021242071A1 (ko) 2020-05-29 2021-05-31 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치

Country Status (4)

Country Link
US (1) US20230209340A1 (ko)
EP (1) EP4142319A4 (ko)
CN (1) CN115699837A (ko)
WO (1) WO2021242071A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024079534A1 (en) * 2022-10-10 2024-04-18 Telefonaktiebolaget Lm Ericsson (Publ) Fifth generation overlays virtual private network with zero touch provisioning

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11983284B2 (en) * 2021-01-19 2024-05-14 Arm Cloud Technology, Inc. Consent management methods
US20220311626A1 (en) * 2021-03-24 2022-09-29 Cisco Technology, Inc. Cloud-based identity provider interworking for network access authentication

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140064601A (ko) * 2012-11-19 2014-05-28 주식회사 케이티 단말 장치에 내장되어 설치되는 가입자 인증 모듈의 프로파일 구성 방법 및 이를 이용하는 장치
KR20160115048A (ko) * 2015-03-25 2016-10-06 삼성전자주식회사 이동통신시스템에서 단말을 변경하여 이동 통신 서비스를 이용하는 방법 및 장치
US20180146365A1 (en) * 2016-11-23 2018-05-24 Qualcomm Incorporated Device capability exchange in multi-sim and concurrent-rat devices
US20190253884A1 (en) * 2016-10-20 2019-08-15 Huawei Technologies Co., Ltd. Method and Apparatus for Managing Embedded Universal Integrated Circuit Card EUICC
US20200084610A1 (en) * 2016-06-23 2020-03-12 Telefonaktiebolaget Lm Ericsson (Publ) Methods and Entities for Ending a Subscription

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10785645B2 (en) * 2015-02-23 2020-09-22 Apple Inc. Techniques for dynamically supporting different authentication algorithms
CN110352605B (zh) * 2017-03-31 2020-12-08 华为技术有限公司 一种鉴权算法程序的添加方法、相关设备及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20140064601A (ko) * 2012-11-19 2014-05-28 주식회사 케이티 단말 장치에 내장되어 설치되는 가입자 인증 모듈의 프로파일 구성 방법 및 이를 이용하는 장치
KR20160115048A (ko) * 2015-03-25 2016-10-06 삼성전자주식회사 이동통신시스템에서 단말을 변경하여 이동 통신 서비스를 이용하는 방법 및 장치
US20200084610A1 (en) * 2016-06-23 2020-03-12 Telefonaktiebolaget Lm Ericsson (Publ) Methods and Entities for Ending a Subscription
US20190253884A1 (en) * 2016-10-20 2019-08-15 Huawei Technologies Co., Ltd. Method and Apparatus for Managing Embedded Universal Integrated Circuit Card EUICC
US20180146365A1 (en) * 2016-11-23 2018-05-24 Qualcomm Incorporated Device capability exchange in multi-sim and concurrent-rat devices

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024079534A1 (en) * 2022-10-10 2024-04-18 Telefonaktiebolaget Lm Ericsson (Publ) Fifth generation overlays virtual private network with zero touch provisioning

Also Published As

Publication number Publication date
US20230209340A1 (en) 2023-06-29
CN115699837A (zh) 2023-02-03
EP4142319A1 (en) 2023-03-01
EP4142319A4 (en) 2023-11-01

Similar Documents

Publication Publication Date Title
US11082855B2 (en) Secure onboarding of a device having an embedded universal integrated circuit card without a preloaded provisioning profile
WO2021242071A1 (ko) 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치
CN102349319B (zh) 中继节点的设置和配置
US20220385445A1 (en) EMBEDDED UNIVERSAL INTEGRATED CIRCUIT CARD (eUICC) PROFILE CONTENT MANAGEMENT
US11496883B2 (en) Apparatus and method for access control on eSIM
KR20220150843A (ko) 무선 통신 시스템에서 디바이스들의 프로파일 이동을 지원하는 방법 및 장치
US11805409B2 (en) System and method for deriving a profile for a target endpoint device
US9288671B2 (en) Device authentication method and devices
WO2019009557A1 (ko) Esim 단말과 서버가 디지털 인증서를 협의하는 방법 및 장치
CN110808942B (zh) 一种签约信息配置方法、网络设备和终端设备
US20220078615A1 (en) Device changing method and apparatus of wireless communication system
KR20200145775A (ko) 통신서비스를 제공하는 방법 및 장치
TW201513632A (zh) 用於對非蜂巢式裝置在ｗｉｆｉ之上提供電話服務之系統與方法
US11956375B2 (en) Digital letter of approval (DLOA) for device compliance
KR20210147822A (ko) 이동 통신 시스템에서 단말 간 네트워크 액세스 정보를 이전하는 방법 및 장치
WO2024093923A1 (zh) 通信方法和通信装置
WO2024094319A1 (en) First node, second node, third node, fourth node and methods performed thereby for handling registration of the second node
CN115706973A (zh) 一种安全通信的方法及通信装置
KR20210029648A (ko) 무선 통신 시스템에서 비가입자 등록된 단말에게 가입 데이터를 제공하기 위한 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21814202

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021814202

Country of ref document: EP

Effective date: 20221122

NENP Non-entry into the national phase

Ref country code: DE