KR20220152912A - 논리 인터페이스를 지원하는 단말 및 카드 간 Proactive Command를 획득하여 처리하는 방법 및 장치 - Google Patents

Abstract

본 개시는 4G 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G 통신 시스템을 IoT 기술과 융합하는 통신 기법 및 그 시스템에 관한 것이다. 본 개시는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스 (예를 들어, 스마트 홈, 스마트 빌딩, 스마트 시티, 스마트 카 혹은 커넥티드 카, 헬스 케어, 디지털 교육, 소매업, 보안 및 안전 관련 서비스 등)에 적용될 수 있다. 본 개시는 단일 eUICC 탑재한 단말에서도 Dual SIM 기능을 제공하는 방법 및 장치를 제공 한다.
특히, 본 개시의 일 실시 예에 따르면, 본 개시가 이루고자 하는 기술적 과제는 통신 시스템에서 1개의 eUICC 탑재 단말에서도 Dual SIM 기능을 제공할 수 있도록 복수 개의 프로파일을 설치 활성화하고 관리하는 방법 및 장치를 제공하는 것이다. 특히, 본 개시에서는 상기 목적을 위한 다음의 실시 예를 포함한다. eUICC에서 프로파일 상태 변경을 수반하는 명령을 LPA로부터 수신하여, Proactive Command를 등록하고 eUICC에서 모뎀에 Proactive Command를 획득할 논리 인터페이스 정보를 알려주는 방법, 모뎀에서 수신된 논리 인터페이스 정보와 모뎀이 수집하여 가지고 있는 논리 인터페이스의 상태 및 해당 메시지가 수신된 인터페이스 번호 등 소정의 정보를 조합하여 eUICC가 특정 논리 인터페이스에 Polling을 수행할 지 여부를 판단하는 방법, 모뎀에서 해당 논리 인터페이스에 Polling을 수행하여 Proactive Command를 수신하여 처리하는 방법, eUICC에서 해당 Proactive Command 처리 결과를 수신하여, 해당 논리 인터페이스에 연결된 프로파일의 상태 변경을 처리 완료하는 방법. 또한, 단말에서 eUICC가 eUICC 메모리 Reset 또는 Profile 상태 변경 요청을 수신하는 경우, eUICC가 모뎀의 MEP 지원 여부에 따라 선택적으로 REFRESH 메시지를 구성하여 모뎀에 구분 전송하는 방법을 제공할 수 있다.

Description

논리 인터페이스를 지원하는 단말 및 카드 간 Proactive Command를 획득하여 처리하는 방법 및 장치 {METHOD AND APPARATUS TO HANDLE PROACTIVE COMMAND(S) BETWEEN A TERMINAL AND A CARD SUPPORTING LOGICAL INTERFACES}

본 개시는 무선 통신 시스템에서 단말에 한 개 이상의 통신 서비스를 다운로드 및 설치하여 통신 연결을 하기 위한 방법 및 장치에 관한 것이다. 또한, 본 개시는 단말 및 카드 간 연결된 하나의 논리 인터페이스에서 다른 논리 인터페이스에서 보류 중인 Proactive Command를 획득하는 방법 및 장치에 관한 것이다.

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 카드 및 고정하지 않는 UICC 카드를 통칭하여 eUICC로 사용할 수 있다. 또한 다운로드 받는 SIM 모듈정보를 통칭하여 프로파일(profile) 이라는 용어로 사용할 수 있다.

상기 eUICC 내의 프로파일은 1개 이상이 존재하더라도 동시에 1개만 활성화(Enabled)가 가능할 수 있다. 따라서, 단말에서 2개의 Baseband(s)를 지원하고, 해당 eUICC에 2개 이상의 프로파일이 존재하더라도 해당 단말에서는 프로파일 2개를 하나의 휴대 전화에서 동시에 사용 가능하게 하는 Dual SIM 기능을 지원하지 못한다. 이를 해결하는 방법으로는 단말에 2개의 eUICC(s)를 탑재하여 해결이 가능하나, 이는 추가적인 eUICC 모듈 탑재 및 eUICC 모듈을 모뎀의 Baseband와 연결하기 위한 Physical Interface 가 필요하므로 단말 제조사는 추가적인 eUICC 모듈 및 Physical Interface를 위한 물리 핀 구매에 따른 비용을 부담해야 한다. 또한, 해당 모듈 및 물리 핀 도입에 따른 단말의 실장 공간 확보도 문제가 된다.

현재 단말 및 카드 간에는 1개의 물리 인터페이스(physical interface)를 통해서 메시지를 주고 받는다. 하지만, eUICC에서 1개 이상의 프로파일의 동시 활성화를 지원하는 MEP(multiple enabled profiles) 논의가 시작됨에 따라, 이를 지원하기 위해 ETSI(european telecommunications standards institute, 유럽전기통신표준협회)에서 단말 및 카드 간 1개의 Physical Interface를 여러 개의 Logical Interface로 분할하여 사용(multiplexing) 하는 개념을 도입하기로 결정하였다. 한편, GSMA(GSM association,GSM 협회)에서 하나의 프로파일은 하나의 Logical Interface를 통해서 모뎀에 있는 하나의 Baseband를 점유하는 개념이 논의되고 있으며, GSMA에서 프로파일을 관리하는 모듈인 ISD-R(issuer security domain-root)을 하나의 Logical Interface를 통해서만 선택 가능한 방법도 논의 중에 있다.

현재, eUICC에서 단말로부터 프로파일의 활성화/비활성화에 대한 명령을 수신하는 경우, eUICC는 단말이 카드에 전송하는 FETCH Command에 대한 Response의 Data로 단말에 프로파일의 상태가 변경되었음을 알리는 'Proactive Command'를 회신함으로써, 모뎀으로 하여금 수신된 해당 'Proactive Command'에 따른 ETSI TS102.223에 정의된 절차를 수행하도록 요청할 수 있다. Proactive Command는 다양한 종류를 가질 수 있으며 예를 들어, 단말이 REFRESH Proactive Command로 eUICC Profile State 모드를 수신 시, 단말은 해당 프로파일에 대한 캐시해 두었던 데이터 삭제, 해당 프로파일이 점유하고 있었던 baseband와 연결을 해제함으로써 네트워크 연결을 끊을 수 있고, 단말과 카드 간 진행 중인 모든 애플리케이션 세션을 닫은 다음 단말 및 카드 간 연결을 선택적으로 재 시작할 수 있다.

Physical Interface는 최대 20개의 논리 채널(logical channel)을 가질 수 있으며, 앞서 언급한 FETCH Command는 논리 채널 0번을 통해서만 전송되어 단말은 해당 채널로 Proactive Command를 수신할 수 있다.

ETSI에서 Physical Interface를 1개 이상의 logical interface로 분할 다중화 하는 개념을 도입함에 따라, 어떤 Logical Interface에서 Proactive Command를 획득하여야 하는지 단말이 파악하여 해당 Logical Interface에 대한 Proactive Command를 처리할 수 있어야 하나, 본 개시를 개시하는 시점에 단말과 카드 간에 이를 지원하는 방법이 정의되지 않았다.

상기와 같은 문제점을 해결하기 위한 본 개시는 무선 통신 시스템에서 제어 신호 처리 방법에 있어서, 기지국으로부터 전송되는 제1 제어 신호를 수신하는 단계; 상기 수신된 제1 제어 신호를 처리하는 단계; 및 상기 처리에 기반하여 생성된 제2 제어 신호를 상기 기지국으로 전송하는 단계를 포함하는 것을 특징으로 한다.

본 개시의 실시 예에 따르면, 사용자는 1개의 eUICC가 탑재된 단말에서, Dual SIM 기능을 사용하는 경우에, eUICC에 동시에 활성화된 제1 프로파일과 제2 프로파일이 상호 간섭 없이 (제1 프로파일의 활성화에 따른 제2 프로파일의 네트워크 접속 종료 등) 단일 eUICC 내에서 동작할 수 있도록 처리할 수 있다.

도 1은 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 본 개시의 구성 요소를 도시한 도면이다.
도 2는 MEP를 지원하지 않는 v2 eUICC와 모뎀 간의 연결 상태에 대해 도시한 도면이다.
도 3은 Logical Interface 개념 도입에 따른 v3 eUICC와 모뎀 간의 연결 상태 및 Logical Interface에서 ISD-R에 대한 접근 방법을 도시한 도면이다.
도 4는 본 개시의 일 실시 예에 따른 MEP 지원 단말에서 프로파일의 상태 변경을 수반하는 프로파일 관리 명령을 처리하는 방법에 대해서 도시한 예시 도면이다.
도 5는 Logical Interface를 사용하지 않는 단말과 카드 간에 Proactive Command를 획득하여 처리하는 동작 순서를 도시한 예시 도면이다.
도 6은 Logical Interface를 사용하는 단말과 카드 간에 특정 Logical Interface에 대한 Proactive Command를 획득하여 처리하는 동작 순서를 도시한 예시 도면이다.
도 7은 Logical Interface를 사용하는 단말과 카드 간에 특정 Logical Interface에 대한 Proactive Command를 획득하여 처리하는 동작 순서를 도시한 다른 예시 도면이다.
도 8은 특정 포트에 대한 Polling을 수행하는 과정에서 발생 가능한 Error 및 Error Handling에 대한 방법들을 도시한 도면이다.
도 9는 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 단말의 내부 구조를 개략적으로 도시한 도면이다.

이하 첨부된 도면을 참조하여 본 개시의 동작 원리를 상세히 설명한다. 하기에서 본 개시를 설명하기에 있어 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략할 것이다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다. 마찬가지 이유로 첨부된 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성 요소에는 동일한 참조 번호를 부여하였다. 본 개시에 따른 기술적 사상의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다. 또한 본 개시를 설명함에 있어서 관련된 기능 또는 구성에 대한 구체적인 설명이 본 개시에 따른 기술적 사상의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.

이하, 기지국은 단말의 자원할당을 수행하는 주체로서, 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과 혼용될 수 있다. 또한, 본 명세서에서 카드, 또는 SE(secure element)는 UICC와 eUICC를 아우르는 상위 개념으로 사용되거나 UICC 또는 eUICC와 혼용되어 사용할 수 있다.

본 명세서에서 프로파일(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), 터미널(terminal), 가입자 유닛(subscriber unit), 가입자 스테이션(SS; subscriber station), 무선 기기(wireless device), 무선 통신 디바이스, 무선 송수신 유닛(WTRU; wireless transmit/receive unit), 이동 노드, 모바일 또는 다른 용어들로서 지칭될 수 있다. 단말의 다양한 실시 예들은 셀룰러 전화기, 무선 통신 기능을 가지는 스마트 폰, 무선 통신 기능을 가지는 개인 휴대용 단말기(PDA), 무선 모뎀, 무선 통신 기능을 가지는 휴대용 컴퓨터, 무선 통신 기능을 가지는 디지털 카메라와 같은 촬영장치, 무선 통신 기능을 가지는 게이밍 장치, 무선 통신 기능을 가지는 음악저장 및 재생 가전제품, 무선 인터넷 접속 및 브라우징이 가능한 인터넷 가전제품뿐만 아니라 그러한 기능들의 조합들을 통합하고 있는 휴대형 유닛 또는 단말기들을 포함할 수 있다. 또한, 단말은 M2M(machine to machine) 단말, MTC(machine type communication) 단말/디바이스를 포함할 수 있으나, 이에 한정되는 것은 아니다. 본 명세서에서 상기 단말은 전자장치 또는 단순히 디바이스라 지칭할 수도 있다. 또한, 본 명세서에서 단말 및 카드 간 Interface를 설명함에 있어, 단말은 카드에 명령을 송수신하는 메시지를 전송하는 메시지 전송부로써, 모뎀으로 혼용되어 사용될 수 있다.

본 명세서에서 상기 단말 또는 기기는 UICC 또는 eUICC를 제어하도록 단말 또는 기기 내에 설치된 소프트웨어 또는 애플리케이션을 포함할 수 있다. 상기 소프트웨어 또는 애플리케이션은, 예를 들어 local profile assistant(LPA)라 지칭할 수 있다. 본 명세서에서 eUICC 식별자(eUICC ID)는, 단말에 내장된 eUICC의 고유 식별자일 수 있고, EID로 지칭될 수 있다. 본 명세서에서 APDU(application protocol data unit)는 ISO 7816-4를 기반으로 정의된 애플리케이션 전송 프로토콜을 사용하는, 단말과 카드 간의 데이터를 송수신하기 위한 메시지를 지칭할 수 있다. APDU는 Command APDU (명령 메시지)와 Response APDU (응답 메시지)의 한 쌍으로 구성될 수 있으며, 단말에서 Command APDU를 카드에 전송하면 이를 수신한 카드 간 Response APDU를 회신하는 형식으로 동작할 수 있다. 카드는 Command APDU를 전송할 수 없으나 카드에서 단말이 수행했으면 하는 요청 사항이 있는 경우에 이를 Proactive Command라는 데이터 형태로 Response APDU, 즉 회신 메시지의 DATA를 전송함으로써, 단말로 하여금 Proactive Command에서 요구하는 명령을 수행하도록 처리할 수 있다.

본 명세서에서 카드가 단말에 전송하는 Command(명령)로 Proactive Command라는 용어를 사용하며, Proactive Command는 단말에서 카드에 보내는 Command APDU에 대한 Response APDU의 데이터로서 전송될 수 있다. Proactive Command의 종류 및 종류에 따른 동작은 ETSI TS(technical specification, 기술 규격) 102.223)에 정의되어 있으며, 이 중에 카드의 System에서 보낼 수 있는 Proactive Command의 종류는 ETSI TS 102.224 기술 규격에 정의되어 있다. 또한, 앞서 언급한 Command APDU와 Response APDU의 메시지 포맷은 ETSI TS102.221 10절에 설명된 하기 [표 1], [표 2]와 같이 표기될 수 있다. [표 1]은 Table 10.1: Contents of command APDU에 관한 것이며, [표 2]는 Contents of Response APDU에 관한 것이다. 이에 대한 상세한 설명은 ETSI TS 102.221의 10절을 따른다.

Code	Length	Description	Grouping
CLA	1	Class of instruction	Header
INS	1	Instruction code
P1	1	Instruction parameter 1
P2	1	Instruction parameter 2
Lc	0 or 1	Number of bytes in the command data field	Body
Data	Lc	Command data string
Le	0 or 1	Maximum number of data bytes expected in response of the command

Code	Length	Description
Data	Lr	Response data string
SW1	1	Status Byte 1
SW2	1	Status Byte 2

본 명세서에서 프로파일 패키지(profile package)는 프로파일과 혼용되거나 특정 프로파일의 데이터 객체(data object)를 나타내는 용어로 사용될 수 있으며, Profile TLV 또는 프로파일 패키지 TLV (profile package TLV)로 명명될 수 있다. 프로파일 식별자는, 프로파일의 고유 식별 번호로 ICCID로 지칭될 수 있다. 프로파일 패키지가 암호화 파라미터를 이용해 암호화된 경우 보호된 프로파일 패키지(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에 저장되어 망에 접속하기 위한 USIM 또는 ISIM과 같은 응용프로그램일 수 있다. NAA는 망 접속 모듈일 수 있다.

본 개시에서 End user, 사용자, 가입자, 서비스 가입자, user는 해당 단말의 사용자로 혼용되어 사용될 수 있다.

본 개시에서 포트는 단말과 카드 간 연결된 Physical Interface를 Multiplexing하여 나누어 사용하는 논리 인터페이스(logical interface)를 지칭하며, 본 명세서에서 eSIM port, eSIM 포트, ePort, SIM 포트, 논리 SE 인터페이스 (logical SE interface) 또는 축약하여 LSI, 논리 인터페이스 (logical interface), 가상 인터페이스 (virtual interface)와 혼용되어 사용될 수 있다.

본 개시에서 단일 eUICC 에 존재하는 복수 개의 프로파일을 활성화하고 관리하는 기능을 통칭하여 multiple enabled profile (MEP) 기능이라 칭한다. 종래 eUICC는 최대 1개의 프로파일만 활성화가 가능하여, 단일 eUICC로는 Dual SIM 또는 Multi SIM 기능을 지원하지 못한다. 단일 eUICC로 Dual SIM 또는 Multi SIM 기능을 지원하기 위해, 단일 eUICC에서 복수 개의 프로파일이 활성화되고 이를 관리하는 기능이 필요하다. MEP 기능이 구현된 eUICC를 MEP 지원 eUICC라 칭할 수 있다. MEP 기능이 구현된 모뎀과, 이를 지원할 수 있는 단말 소프트웨어를 포함하는 단말을 MEP 지원 단말이라 칭할 수 있다.

본 개시에서 단말과 eUICC간에 초기화 과정을 통해 단일 물리 인터페이스에서 1개 이상의 논리적 인터페이스(logical interface)가 사용 가능하도록 분할 다중화하여 전송할 수 있도록 동작하기로 결정한 모드를 MEP 모드라고 할 수 있다. MEP 지원 단말 또는 MEP 지원 eUICC라고 하더라도, 단말과 eUICC간의 초기화 과정에서 MEP 모드로 동작을 결정하지 않은 경우 MEP 모드로 동작하지 않을 수 있다. 해당 모드로 동작하는 경우는 SEP(Single Enabled Profile)모드라고 할 수 있다.

따라서, 본 개시가 이루고자 하는 기술적 과제는 통신 시스템에서 1개의 eUICC가 탑재된 단말에서도 Dual SIM 기능을 제공할 수 있도록 복수 개의 프로파일을 설치 활성화하고 관리하는 방법 및 장치를 제공하는 것이다.

특히, 본 개시에서는 상기 목적을 위한 다음의 실시 예를 포함한다.

- eUICC에서 프로파일 상태 변경을 수반하는 명령을 LPA로부터 수신하여, Proactive Command를 등록하는 방법

- eUICC에서 모뎀에 Proactive Command를 획득할 논리 인터페이스 정보를 알려주는 방법

- 모뎀에서 수신된 논리 인터페이스 정보와 모뎀이 수집하여 가지고 있는 논리 인터페이스의 상태 및 해당 메시지가 수신된 인터페이스 번호 등 소정의 정보를 조합하여 eUICC가 특정 논리 인터페이스에 Polling을 수행할 지 여부를 판단하는 방법

- 모뎀에서 해당 논리 인터페이스에 Polling을 수행하여 Proactive Command를 수신하여 처리하는 방법

- eUICC에서 해당 Proactive Command 처리 결과를 수신하여, 해당 논리 인터페이스에 연결된 프로파일의 상태 변경을 처리 완료하는 방법

또한, 본 개시에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.

그리고, 본 개시를 설명함에 있어서, 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우, 그 상세한 설명은 생략한다.

이하에서는 도면들을 통해 제안하는 실시 예를 설명한다.

도 1은 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 본 개시의 구성 요소를 도시한 도면이다.

단말 (1a-05)은 일반 앱(1a-10)와 LPA (1a-15), 단말 프레임워크(framework) (1a-20), MEP 지원 모뎀 (1a-25)을 포함할 수 있다. 여기서 일반 앱(1a-10)은 통신사업자 앱 또는 SIM 카드 매니저 앱과 같이 단말에 미리 저장(pre-loaded)되어 있거나 다운로드하여 설치 가능한 앱으로 물리 심카드(pSIM: physical SIM)(1a-45) 또는 eUICC (1a-50)의 프로파일에 접근 권한을 가지는 앱을 의미할 수 있다. 한편, LPA(1a-15)는 eUICC 제어를 담당하는 앱으로, SM-DP+(1a-70)와 단말 사용자(1a-01), 그리고 eUICC(1a-50)내의 ISD-R(1a-65)과 통신하면서 프로파일에 대한 관리를 처리한다. LPA(1a-15)는 단독 또는 다른 일반 단말 애플리케이션에 통합 구현될 수 있으며, LPA(1a-15)에서는 UI를 구성하여 프로파일의 로컬 관리에 대한 사용자의 입력(Input)을 획득하거나 또는 SM-DP+(1a-70) 원격 관리 명령어를 SM-DP+서버(1a-70)로부터 수신한 후, 해당 명령에 대한 UI를 구성하여 사용자(1a-01) 입력을 획득한 후, LPA(1a-15)에서 eUICC(1a-50)의 ISD-R(1a-65)로 프로파일의 관리 명령을 전달하여 프로파일의 활성화/비활성화/삭제/업데이트를 처리할 수 있다. 원격 프로파일 관리(RPM: remote profile management)는 SM-DP+(1a-70)에서 단말로 전송하는 명령어에 의해 프로파일 설치/활성화/비활성화/삭제 및 기타 기능이 수행되는 일련의 절차를 통칭할 수 있다. RPM은 통신 사업자, 서비스 제공자, 또는 단말의 소유자에 의해 요청되어 SM-DP+(1a-70)에 의해 명령어가 생성될 수 있다. LPA(1a-15)를 통한 로컬 또는 SM-DP+(1a-70)를 통한 원격 프로파일 관리 명령을 수신하는 경우에, eUICC(1a-50)는 해당 프로파일 관리 명령을 처리하는 과정에서 통신 모뎀(1a-25)에 프로파일의 상태가 변경되었음을 알리는 소정의 정보를 전달할 수 있다.

단말(1a-05)의 통신 모뎀(1a-25)은 정보 전달을 위해 신호를 변조하여 송신하고 수신 측에서 원래의 신호로 복구하기 위해 복조하는 장치로 MEP 지원 모뎀의 경우 무선통신을 위한 기저대역 프로세서(baseband processor) (이하 기저대역(baseband))가 2개 이상 탑재될 수 있다. 기저대역은 모뎀 안에 논리적으로 구현될 수 있다. 모뎀(1a-25)은 카드 1개 즉, UICC 또는 eUICC와 각 1개의 물리 핀 (스마트 카드 인터페이스로 ISO7816 규격을 준용)으로 연결되어 있으며, 해당 인터페이스를 통해서 모뎀이 명령(Command)에 대한 APDU (application protocol data unit)을 eUICC(1a-50)에 송신하면 이에 대해 eUICC(1a-50)가 결과 값을 응답 (response APDU 전송) 하는 방식으로 동작할 수 있다. SIM Card (pSIM)는 물리 핀 1개를 통해 모뎀의 기저대역 1개를 점유하며 pSIM 1개는 SIM 포트 하나를 가진다. SIM 포트는 SIM 카드 슬롯(Slot)과 혼용되어 사용될 수 있으며, ㅠ (technical specification).37에 "physical and electronic housing provided on a device to accommodate a physical SIM card"로 정의되어 있다. MEP 지원 eUICC(1a-50)는 MEP 지원 모뎀(1a-25)과 1개의 물리 핀으로 연결되어 있으며 eUICC 내의 활성화된 프로파일은 MEP 지원 모뎀(1a-25)내의 기저대역 1개를 점유할 수 있다. 각 프로파일 1개는 eSIM 포트 1개를 통해서 eSIM 포트에 맵핑된 기저대역과 통신을 수행할 수 있다. 예를 들어 도 1에서 프로파일 1(1a-55)은 활성화된 상태로 eSIM 포트 1을 사용하여 기저대역 1을 점유하고, 프로파일2(1a-60)는 활성화된 상태로 eSIM 포트 2을 사용하여 기저대역 2를 점유하여 사용할 수 있다. 이 경우에, 도 1에서 pSIM(1a-45)은 삽입되어 있으나 기저대역과 연결이 없는 상태가 될 수 있다. 한편 ISD-R(1a-65)은 LPA(1a-15) 또는 모뎀(1a-25)에서만 선택 가능한 eUICC 내 엔티티(entity)로 프로파일의 메타데이터 또는 eUICC 내 프로파일의 상태 및 설정 정보를 저장 또는 eUICC 내부 동작을 통해 수집하여 LPA(1a-15) 또는 단말(1a-05)로부터 명령을 수신하는 경우에 회신해 줄 수 있다. 일 예로, ISD-R 선택 명령 APDU 또는 APDU의 메시지로 GetProfileInfo()와 같은 명령을 수신하는 경우를 포함할 수 있다. 한편, LPA(1a-15)는 단말 프레임워크(1a-20) 위에서 동작하는 소프트웨어로 LPA(1a-15)의 기능은 단말 프레임워크(1a-20)에 일부 통합될 수 있다. LPA(1a-15)에서 eUICC(1a-50)로 전송하는 메시지는 단말 프레임워크(1a-20)와 모뎀(1a-25)을 경유하여 eUICC(1a-50)로 최종 전송(1a-20)되며, 해당 메시지를 수신한 eUICC(1a-50)은 LPA(1a-15)에서 전송된 APDU에서 ES10x 명령을 확인하여 eUICC의 프로파일 관리 동작을 수행할 수 있다.

도 1에서는 이하 설명의 편의를 위해 eUICC(1a-50)에 프로파일 1과 프로파일 2의 2개 프로파일들이 존재하는 경우를 가정하여 도시하였으나 이에 한정하지 않고 eUICC(1a-50)의 메모리 능력(capability)에 따라서 더 많은 프로파일이 존재할 수 있고 또한 2개 이상의 프로파일이 활성화 상태로 존재할 수 있음에 유의해야 한다. MEP지원 eUICC에서는 프로파일 1(1a-55)과 프로파일 2(1a-60)가 동시에 활성화될 수 있으며, MEP 미지원 eUICC인 경우에는 프로파일 1(1a-55) 또는 프로파일 2(1a-60) 중 1개의 프로파일만 활성화 상태가 가능할 수 있다. ISD-R(1a-65)은 신규 ISD-P(프로파일의 호스팅을 위한 보안 도메인(security domain)을 의미)를 생성하고, 전술한 바와 같이 LPA 기능에 의해 요구되는 필요한 eUICC 데이터 및 서비스(예를 들어 로컬 프로파일 관리, 프로파일의 정보 등)를 저장 또는 eUICC 내에서 수집하여 LPA에 제공할 수 있다.

한편, 도 1에서는 단말(1a-05)의 eUICC(1a-50)에는 설명의 편의를 위해 도시하지 않았으나, eUICC의 보안 도메인들에서 요구하는 인증서들(credentials), 예를 들어 SM-DP+ 인증서를 검증하기 위한 증명서 발급자의 루트 공개 키(certificate issuer's root public key), eUICC 제조사의 키 셋(keyset) 등을 저장하는 공간인 ECASD(embedded UICC controlling authority security domain), eSIM 운영 플랫폼 등이 포함될 수 있다.

단말 프레임워크(1a-20)는 단말의 운영 체제를 의미하며 모뎀 및 기타 단말 시스템과 일반 앱 및 LPA간에 존재한다. 단말 프레임워크(1a-20)은 모뎀(1a-25)으로부터 eUICC에 대한 정보를 획득하여 가지고 있다가 일반 앱 또는 LPA에서 단말 또는 eUICC에 대한 정보를 요청 시 해당 정보를 회신해 줄 수 있다. 또한 단말 프레임워크(1a-20)은 일반 앱 또는 LPA에서 수신 받은 채널 오픈 또는 포트 오픈 명령에 따라 Command APDU를 생성하여 모뎀에 전송하고 모뎀으로부터 해당 APDU에 대한 응답 메시지를 수신 받아 다시 일반 앱 또는 LPA에 전달할 수 있다. 또한, 단말 프레임워크(1a-20)은 일반 앱 또는 LPA에서 호출된 channel.transmit(Command APDU)를 수신 받아 channel.transmit(Response APDU)포맷으로 일반 앱 또는 LPA에서 전달해 줄 수 있다.

SM-DP+서버(1a-70)는 전술한 바와 같이 프로파일을 생성하거나, 생성된 프로파일을 암호화하거나, 프로파일 원격관리 명령어를 생성하거나, 생성된 프로파일 원격관리 명령어를 암호화하는 기능을 포함하고 있거나, 단말의 복수 프로파일 활성화 지원 기능을 포함하는 서버를 의미할 수 있다.

도 2는 MEP를 지원하지 않는 v2 eUICC와 모뎀 간의 연결 상태에 대해 도시한 도면이다.

현재 v2 eUICC에서는 eUICC에서 단일(1개) 프로파일만 활성화가 가능하며, 기 설치된 프로파일의 활성화/비활성화/삭제/업데이트 등을 처리하기 위해 SM-DP+의 개입이 없는 사용자의 로컬 프로파일 관리만 가능하다. MEP 미 지원 모뎀(1b-01)인 경우에, Physical SIM Card를 eUICC 와 동시 사용하는 경우 등을 고려하면 Baseband를 1개 이상 가질 수 있으나, 본 명세서에서는 1개의 Baseband를 가정하여 설명하고자 한다.

단말은 단말 플랫폼, 모뎀(modem) 및 eUICC 간에 초기화하여 재 설정하는 과정(Reset)에서 모뎀(1b-01)과 eUICC(1b-15)간 데이터를 주고 받을 수 있도록 카드 세션을 열고 APDU 데이터 전송 채널을 생성할 수 있다.

v2 eUICC(1b-15)에서는 1개의 프로파일만 동시에 활성화가 가능할 수 있다.

Case 1(1b-100)은 Profile 1(1b-20)이 활성화, Profile 2 (1b-25)는 비활성화 된 경우이며, Case 2(1b-200)는 Profile 1(1b-20)이 비활성화, Profile 2 (1b-25)가 활성화된 경우를 나타낸다. Case 1(1b-100)을 설명하면, 활성화된 1개의 프로파일과 모뎀 간 데이터 송수신이 필요한 경우, eUICC(1b-15)는 모뎀(1b-01)과 연결된 Physical Interface(1b-10)를 통해서 해당 Physical Interface에서 열린 채널 중 1개를 통해서 해당 데이터를 주고 받을 수 있다.

한편, ISD-R(1b-30)이 LPA로부터 프로파일의 상태 변경, 예를 들어 Case 1(1b-100)에서 Case 2(1b-200)로 상태 변경에 대한 ES10c.EnableProfile(Profile2) 요청을 수신하는 경우에, ISD-R(1b-30)은 모뎀(1b-10)에 기존 Cached된 프로파일의 데이터 삭제 처리 및 Application 세션 재 시작을 위한 REFRESH Proactive Command로 전송할 수 있다. REFRESH Proactive Command는 ETSI TS102.223에 정의된 REFRESH type을 가지는 Proactive Command로 이 중에 <eUICC Profile State Change 모드> 또는

<UICC Reset 모드>일 수 있다. 해당 Proactive Command는 eUICC가 단말에 회신하는 응답 메시지 (Response APDU)의 DATA로서 전송될 수 있다.

또한, ISD-R(1b-30)이 LPA로부터 eUICC 메모리 Reset을 요청 받는 경우에, ISD-R(1b-30)은 모뎀(1b-10)에 기존 Cached된 UICC의 데이터 삭제 처리 및 Application 세션 재 시작, 단말 및 카드 간에 리셋 절차 수행을 요청하는 REFRESH Proactive Command를 실어서 전송할 수 있다. 해당 REFRESH Proactive Command는 ETSI TS102.223에 정의된 REFRESH type을 가지는 Proactive Command <UICC Reset 모드>로서 eUICC가 단말에 회신하는 응답 메시지 (Response APDU)의 DATA로서 전송될 수 있다.

ISD-R(1b-30)이 모뎀(1b-01)에 전송하는 해당 APDU도 앞서 언급한 Physical Interface(1b-10)의 1개 채널을 통해서 전송될 수 있다.

도 3은 Logical Interface 개념 도입에 따른 v3 eUICC와 모뎀 간의 연결 상태 및 Logical Interface에서 ISD-R에 대한 접근 방법을 도시한 도면이다.

도 3에서 eUICC(1c-20)은 동시에 복수개의 프로파일을 활성화가 가능한 MEP기능을 지원하는 eUICC를 가정하였다. 한편, 모뎀(1c-01)역시 MEP 기능을 지원하는 모뎀을 가정한다. 도 3에서는 Baseband 2개와 활성화된 프로파일이 2개 있는 상황을 예로 들어 설명하며 모뎀(1c-01)내의 Baseband와 eSIM 포트 간의 맵핑 switch도 가능할 수 있으나, 본 Case 1과 Case 2, Case 3에서는 모뎀(1c-01)내 logical terminal endpoint의 맵핑을 Baseband 1(1c-05)-포트(1c-40), Baseband 2(1c-10)-포트2(1c-45)로 예를 들어 설명할 수 있다.

앞서 도 1에서 서술한 바와 같이, 현재 모뎀(1a-15)은 eUICC (1a-20)와 하나의 물리 핀으로 연결되어 있으며, 해당 모뎀과 eUICC는 해당 물리 핀을 통해 단일 채널을 사용(1b-10)하여 Command APDU를 전송한다. MEP를 지원하는 eUICC(1c-20)은 복수 개의 Profile을 활성화하며, 해당 활성화된 프로파일은 모뎀에서 하나의 baseband를 점유하여 사용하며, 점유한 baseband와의 데이터 송수신이 필요할 수 있다. 따라서, 이를 처리하기 위한 Physical Interface(1c-15)를 Multiplexing해 APDU를 구분해 여러 포트로 전송(1c-40, 1c-45, 1c-60)하는 개념이 도입될 수 있다.

이하 설명의 편의를 위해 eSIM 포트 1(1c-40)과 eSIM 포트 2(1c-45)로 명명하고 각각을 eSIM 포트로 정의할 수 있다.

단말은 단말 플랫폼, Modem 및 eUICC 간에 초기화하여 재 설정하는 과정(Reset)에서 모뎀(1b-01)-eUICC(1b-15)간 데이터를 주고 받을 수 있도록 카드 세션을 열고 APDU 데이터 전송 채널을 생성할 수 있다. 이 때, 1개 이상의 포트를 생성할 수 있으며, 이 경우에 단말 및 카드는 각 포트에서 APDU 데이터 전송 채널을 생성(최대 20개)할 수 있다. 이 때, 단말 및 카드 간에 열린 각 eSIM 포트에 대한 ID를 설정할 수 있다. 해당 포트 ID는 모뎀 또는 단말 플랫폼에서 설정되어 LPA에 전달해 줄 수 있다. 포트 ID는 본 명세서에서 설명의 편의를 위해 포트 번호로 혼용되어 사용하고 있다.

모뎀은 Baseband의 수만큼 eSIM 포트의 개수를 가질 수 있으나, eUICC(1c-20)에서 활용하는 eSIM 포트의 개수는 해당 eUICC에서 동시에 활성화 가능한 프로파일의 수와 동일하거나 작을 수 있다. 프로파일은 해당 eSIM 포트 중 1개를 사용하여 단말(1c-01)과 APDU 메시지를 전송할 수 있다.

MEP 지원 모뎀(1c-01)은 각각의 eSIM 포트로 송수신되는 APDU가 어떤 Baseband와 연결되는 메시지인지 구분하여 처리할 수 있다. 한편, ISD-R(1c-50)은 프로파일 및 eUICC의 상태 관리를 위해서 모뎀에 해당 정보를 전송할 필요가 있다. 이 경우에, ISD-R(1c-35)는 2가지 방식으로 전송이 가능하다.

1) Multi-Selected (Case 2, 1c-200): LPA 또는 모뎀은 eUICC 초기화 과정 때, 복수 개의 eSIM 포트로 ISD-R(1c-35)을 SELECT 할 수 있다. 이러한 상태를 Multi-Selected라 할 수 있다. Multi-Selected 인 경우, 단말은 프로파일 활성화가 필요한 포트를 통해 ISD-R(1c-35)에 접근하여 해당 ISD-R에 프로파일 관리 처리에 대한 command APDU를 보낼 수 있고, ISD-R(1c-35)은 단말이 처리해야 하는 이벤트나 회신해야 할 APDU가 있으면 적용되는 포트를 통해서 Response APDU를 단말에 전송할 수 있다. ISD-R(1c-35)은 단말로부터 수신된 Command APDU가 프로파일 1(1c-25) 또는 프로파일 2(1c-30)에 해당하는 관리 메시지인지, 프로파일 1(1c-25)과 프로파일 2(1c-30) 모두에 해당하는 관리 메시지인지, 또는 eUICC 전체에 대한 메시지인지에 따라, 요청되는 동작을 수행하고 난 후, 대응되는 eSIM 포트를 선택해 해당 포트로 proactive Command가 포함된 Response APDU를 회신할 수 있다. 예를 들어, 단말로부터 eUICC(1c-20)의 ISD-R(1c-35)로 Command APDU의 데이터로 Profile 1 (1c-25)의 비활성화 처리가 전송되는 경우에, 이 때 해당 Command APDU는 포트 1번(1c-40)을 통해 수신되거나 또는 포트 2번(1c-45)를 통해 수신될 수 있다. 다만, 해당 비활성화 명령에 대한 동작을 eUICC가 처리하고 나서 해당 프로파일의 상태가 변경되었음을 알리는 REFRESH Proactive Command를 포함한 Response APDU는 Profile 1(1c-25)이 연결된 포트 1번(1c-40)을 통해서 단말에 전달할 수 있다.

2) Non Multi-Selected (Case 1(1c-100) 또는 Case 3(1c-300)): LPA 또는 모뎀은 eUICC와 초기화 과정을 수행하면서, 또는 단말의 설정에 따라 하나의 eSIM 포트만으로 ISD-R(1-35)을 선택하기로 결정할 수 있다. 이러한 상태를 Non Multi-Selected라 할 수 있다. Non Multi-Selected인 경우, ISD-R 선택을 위해 결정한 단 하나의 eSIM 포트를 통해서만 단말-ISD-R(1c-35)과 메시지를 주고 받을 수 있다.

ISD-R이 사용하는 eSIM Port 하나를 프로파일이 함께 사용하는 경우는 Case 1 (1c-100)의 (1c-40)과 같은 경우일 수 있고, 프로파일과 함께 사용하지 않고 독립적인 ISD-R 전용 eSIM Port를 사용하는 경우는 Case 3(1c-300)의 (1c-60)과 같은 경우일 수 있다.

도 4는 본 개시의 일 실시 예에 따른 MEP 지원 단말에서 프로파일의 상태 변경을 수반하는 프로파일 관리 명령을 처리하는 방법에 대해서 도시한 예시 도면이다.

도 4에서 LPA와 eUICC, 모뎀은 MEP를 지원하고, 단말 및 카드 간 초기화 과정 시 성능 협상 또는 단말 및 카드 간 사전 설정에 의해서 MEP 모드로 동작하기로 합의한 경우를 가정할 수 있다.

본 개시의 실시 예에 따르면, LPA(1d-05)는 단말 사용자(1d-01)로부터 eUICC에 설치된 프로파일의 상태 변경에 대한 요청을 입력 받을 수 있다(1d-20),

이는 프로파일의 활성화 또는 비활성화, 또는 모든 프로파일의 삭제와 같은 명령일 수 있다. 프로파일의 활성화는 해당 프로파일에 있는 파일 시스템에 접근 가능한 상태이며 프로파일의 비활성화는 해당 프로파일에 있는 파일 시스템에 접근 불가능한 상태를 의미하여 광의의 의미로는 프로파일 활성화는 해당 프로파일이 있는 네트워크 서비스 인증 정보 등과 같은 정보를 사용하여 네트워크 서비스를 사용 가능한 상태, 프로파일 비 활성화는 네트워크서비스 접속 불가능한 상태로 변경으로 해석될 수도 있다. LPA(1d-05)는 사용자로부터 해당 명령을 수신 받게 되면 eUICC(1d-10)에 ES10c.command를 전송할 수 있다. ES10c.command는 일 예로 ES10c.enableProfile 또는 ES10c.disableProfile, ES1c.euiccMemoryReset과 같은 메시지 중 하나 일 수 있다. 해당 메시지를 전송할 때 LPA(1d-05)는 eUICC(1d-10)가 모뎀에 REFRESH에 대한 Proactive Command를 보내야 할 지를 결정하는 식별자로 refreshFlag를 포함해 전송(1d-30)할 수 있다. 또한, LPA(1d-05)는 앞서 도 3에서 언급한 바와 같이 ISD-R이 1개의 포트를 통해서만 선택되도록 결정한 경우에 있어서 ISD-R이 사용하는 포트를 통해서 해당 명령을 전송하기 때문에 해당 명령을 적용될 포트의 식별 정보, 예를 들어, 포트 번호를 지정하여 전송할 수 있다. 또한 적용되는 프로파일에 대한 ID인 ICCID 또는 Application ID를 포함하여 전송할 수 있다.

eUICC(1d-10)은 해당 메시지를 수신하면 프로파일 현재 비활성화/활성화 상태, 프로파일의 메타데이터의 프로파일 정책 등을 확인하여 해당 ES10c.command를 처리할 수 있는지를 확인하고 처리가 불가능한 경우 LPA(1d-05)에 에러를 리턴하고 절차를 종료할 수 있다. 일 예로, 프로파일 활성화 명령에 대한 ES10c.EnableProfile (Profile 1의 ICCID, Refresflag, 포트 번호 1) 명령을 수신하였으나 Profile 1에 해당하는 ICCID가 이미 포트 번호 1에 활성화되어 있는 경우 에러를 리턴 하고 절차를 종료할 수 있다. 다른 예로, 프로파일 활성화 명령에 대한 ES10c.EnableProfile (Profile 1의 ICCID, Refresflag, 포트 번호 1) 명령을 수신하였으나 Profile 1의 메타데이터 정보로써 해당 Profile 1이 일반 사용자에 의해서 비활성화가 불가능한 Enterprise향 Profile로 정의된 경우에 에러를 리턴하고 절차를 종료할 수도 있다.

eUICC(1d-10)의 ISD-R이 (1d-40)단계에서 수신된 관리 메시지 명령에 대해 처리가 가능하다고 판단한 경우, eUICC(1d-10)의 ISD-R은 해당 ES10c.command 메시지에서 refreshFlag를 확인하여, 해당 포트에 대한 refresh가 필요함을 확인하여 도 6 내지 도 7에 기술한 절차를 수행할 수 있다. 여기서 해당 포트 라는 의미는 포트 번호가 포함된 ES10c.command가 수신된 경우, ES10c. command에 명시된 포트 번호이며, ES10c.command에 포트 번호 없이 수신된 경우는 수신된 포트의 번호로 해석될 수 있다. (1d-30)에서 포트 번호가 포함된 경우에, 도 6 내지 도 7에서는 해당 수신된 포트 번호를 포함한 Response APDU를 모뎀(1d-15)에 전송함으로써 단말이 해당 포트과 관련된 상태 refresh 처리를 수행할 수 있다. 만약 앞서 도 3에서 언급한 바와 같이 단말이 ISD-R을 하나의 포트로만 선택하는 non-multi selected한 경우이며 (도 3의 Case 1 내지 Case 3)이나 (1d-30)에서 포트 번호가 없거나 또는 eUICC(1d-10)가 포트 번호를 선택하도록 하는 indicator, 예를 들어 -1과 같은 번호로 전송되면 eUICC는 포트의 가용 여부를 판단하여 도 6 내지 도 7에서 eUICC가 선택한 임의의 포트 번호를 포함해 전송할 수 있다.

만약 앞서 도 3에서 언급한 바와 같이 단말이 ISD-R을 multi-selected한 경우이며 (도 3의 Case 2)이며 (1d-30)단계에서 포트 번호가 없이 전송된 경우에는, ISD-R은 해당 전송된 포트에서 도 5와 같이 Response APDU를 모뎀(1d-15)에 전송함으로써 모뎀이 해당 포트과 관련된 상태 refresh 처리를 수행할 수 있다.

(1d-50) 단계 처리 후에 eUICC(1d-10)은 프로파일의 상태를 변경 처리를 완료하고 상태 변경에 대한 notification을 LPA에 회신(1d-05)해 줄 수 있다.

한편, 도 8에서 후술한 바와 같이 모뎀-카드 간 초기화(initialization) 하는 과정에서 단말이 단말의 Capability를 나타내는 정보로 Command APDU <INS=Terminal Profile>으로, 지원하는 Proactive Command의 종류를 지칭하는 bit로 알려줄 수도 있다. 후술한 예에서 이를 Type을 들어 설명하였으나, 도 7에서 설명하고 있는 바와 같이 다른 포트에서의 Polling 요청하는 Proactive Command인지를 구분할 수 있는 최소 단위 식별자, 예를 들어 특정 Type의 특정 Qualifier인 LSI Polling 지원에 대한 bit로 정보가 전송될 수 있음을 포함하는 의미로 사용하고 있음에 유의해야 한다. 한편, 이를 수신한 카드가 Polling을 요청하는 Proactive Command를 지원하지 않는 경우가 발생할 수도 있다.

이 경우, 예를 들어 LPA(1d-05)가 1개의 ISD-R 접근을 위한 전용 포트를 사용해서 eUICC(1d-10)의 ISD-R로 (1d-30)단계와 같이 Refresh Flag를 포함하여 ES10c.command를 전송한 경우에, eUICC(1d-10)가 이를 처리하기 위한 Proactive Command를 지원하지 않는 경우(예를 들어, 특정 포트에 대한 Polling을 요청하는 Proactive Command 미지원), eUICC(1d-10)는 설정에 따라 다음 중 하나의 방법으로 처리하는 것이 가능하다.

특정 포트에 대한 Polling을 요청하는 Proactive Command는 지원하지 않지만, 모뎀에 프로파일 상태 변경에 따른 refresh 요청, 예를 들어 REFRESH Proactive Command<mode=UICC Profile State Change 또는 UICC Reset>는 지원하며 이 방법으로 처리하도록 설정되어 있는 경우: (1d-50)단계에서 eUICC(1d-10)은 Refresh가 요구되는 포트에 REFRESH Proactive Command<mode=UICC Profile State Change 또는 UICC Reset>을 준비해두고, 해당 포트에서 수신된 특정 Command APDU에 대해서 91XX를 회신하여 단말 모뎀으로 하여금 해당 포트에서 준비된 REFRESH Proactive Command를 획득하여 ETSI TS. 102.223에 기 정의된 동작에 따라 처리하는 방법으로 대체하여 처리할 수 있다.

eUICC(1d-10)가 REFRESH Proactive Command를 수반하는 Proactive Command를 모뎀에 요청하여 처리하는 것을 지원하지 않는 경우((1d-65)단계): 다음 중 한가지의 방법으로 처리할 수도 있다.

한편, REFRESH Proactive Command를 수반하여 처리하는 모뎀의 상태 refresh 방법이라고 함은, eUICC(1d-10)가 앞서 언급한 특정 포트에 대한 Polling을 요청하는 Proactive Command를 수신하여 모뎀에서 해당 특정 포트에서 REFRESH proactive command를 획득하여 처리하는 방법을 포함할 수 있다.

eUICC(1d-10)가 LPA(1d-05)에 error를 리턴((1d-70)단계)할 수 있다. 이 경우, undefined error를 회신할 수도 있고 명확한 이유를 추가하기 위해 Refresh Flag 처리 불가에 대한 error reason 또는 이를 나타내는 코드를 포함하여 리턴((1d-70)단계)할 수도 있다. 한편, eUICC(1d-10)가 특정 포트에 대한 Polling을 요청하는 Proactive Command를 수행하는 동작을 반드시 포함하여, 모뎀에 프로파일 상태 변경에 따른 refresh 요청, 예를 들어 REFRESH Proactive Command<mode=UICC Profile State Change 또는 UICC Reset>를 처리하도록 설정되어 있는 경우에도 eUICC(1d-10)가 LPA(1d-05)에 error를 리턴((1d-70)단계)할 수 있다.

LPA(1d-05)는 refresh flag없이, 즉 REFRESH proactive command를 수반하지 않고 처리가 가능한지 추가적으로 판단하여, 만약 가능한 경우 eUICC(1d-10)에 프로파일 상태 변경 처리를 재요청하는 ES10c.command를 전송((1d-40)단계)하여 SGP.22에 정의된 REFRESH proactive command 수반하지 않는 프로파일 변경 처리 방식에 따라서 프로파일 상태 변경에 대한 처리를 완료((1d-80)단계)할 수 있다. 이는 예를 들어 프로파일의 상태를 변경 처리하고 나서 eUICC(1d-10)의 ISD-R이 요청 성공에 대한 응답 메시지에 추가로 특정 포트와 연결된 baseband에 대한 refresh 처리가 필요함을 나타내는 소정의 정보, 예를 들어 포트 번호를 포함하여 회신해 줄 수도 있다. 해당 메시지를 수신 받은 LPA(1d-05)는 이후 동작으로 모뎀에 refresh 처리를 요청하여 모뎀으로 하여금 해당 프로파일과 연결된 baseband에 대한 상태를 refresh 처리하여 절차를 완료할 수 있다.

LPA(1d-05)는 refresh flag없이, 즉 REFRESH proactive command를 수반하지 않고 처리가 가능한지 추가적으로 판단하여, 만약 불가능한 경우에 처리할 수 없는 이유를 선택적으로 사용자(1d-01)에게 고지하고 처리를 종료((1d-85)단계)할 수 있다. 또한, 앞서 리턴된 error 메시지((1d-70)단계)를 통해서 어떤 이유로 처리가 불가능한지 LPA(1d-05)가 판단할 수 없는 경우에, LPA(1d-05)는 선택적으로 사용자(1d-01)에게 고지하고 처리를 종료((1d-85)단계)하는 것도 가능할 수 있다.

eUICC(1d-10)가 REFRESH Proactive Command를 활용하여 프로파일 상태 변경 처리에 대한 정보를 모뎀에 제공하지 못한다는 정보를 위와 같이 수신 받는 경우에, LPA(1d-05)는 해당 정보를 저장해 두었다가 이후 프로파일 상태 변경 처리에 대한 ES10c.command를 전송하는 경우 refresh flag를 포함하지 않고 전송하는 것도 가능할 수 있다.

한편, 논지를 흐리지 않기 위해 도면에 기술하지 않았으나, eUICC는 단말-카드 간 초기화(initialization)하는 특정 시점에서 REFRESH Proactive Command를 수반하는 refresh 처리를 지원하는지 여부를 단말에 알려주어 단말이 해당 정보를 pre-configuration해 둠으로써, LPA(1d-05)가 최초 ES10c.command를 전송할 때((1d-30)단계) 선택적으로 refresh flag를 포함하지 않고 명령을 전송할 수 있도록 할 수도 있다. 이를 알려주는 방법으로는 ATR(Answer-to-Reset), 단말에서 전송하는 Terminal Capability Command APDU에 대한 회신 값, 또는 단말에서 ISD-R을 선택했을 때 회신하는 ISDRProprietaryApplicationTemplate, 단말에서 Master File을 선택했을 때, 회신하는 FCP(File Control Parameter) template, Manage LSI Command APDU로써 configuration 요청에 대한 회신 값 중의 하나로 알려줄 수 있다. 일 예로 (미)지원 REFRESH Proactive Command 종류, (미)지원 LSI ACTIVITY Proactive Command 종류, REFRESH Proactive Command 수반이 필요 또는 필요없이 처리가 필요한지를 나타내는 식별 정보 중 일부 또는 전체로 단말이 해당 정보를 획득하여 판단할 수 있다. 또는 이와 반대로, 위에 언급한 것과 같이 카드가 모든 방식을 지원하고 단말이 지원하는 proactive command 종류를 알려주는 것에 추가하여 어떤 refresh 방식, 즉, REFRESH proactive command를 수반하는 방식 또는 REFRESH proactive command 수반하지 않고 처리하는 방식을 판단할 수 있는 소정의 정보를 추가적으로 카드에 알려주어 카드가 해당 방법으로 설정해 두는 것도 가능할 수 있다.

도 5는 Logical Interface를 사용하지 않는 단말과 카드 간에 Proactive Command를 획득하여 처리하는 동작 순서를 도시한 예시 도면이다.

본 개시의 개시하는 시점에 ETSI에서 정의한 TS 102.221(v16.0.3)에 따르면, Terminal(1e-01)과 UICC(1e-05)간 proactive command를 처리하는 절차는 다음과 같이 수행될 수 있다.

Terminal(1e-01)에서 UICC(1e-05)에 전원을 공급 또는/그리고 초기화 과정 (Activation) 절차를 시작하면, 이에 대한 응답으로 UICC(1e-05)는 ATR(answer to reset)을 Terminal(1e-01)에 전송하여, 단말 및 카드 간의 데이터 송수신을 위한 세션을 생성할 수 있다. 카드-단말 간의 데이터 송수신을 위한 카드 세션을 생성하고 난 이후 특정 시점에 Terminal(1e-01)은 UICC(1e-05)에 Command APDU를 전송(1e-10 단계)할 수 있다. (1e-10 단계)에서 어떤 CLA와 INS를 가진 Command APDU를 수신하였는지 여부와 무관하게, UICC(1e-05)가 pending된 proactive command가 있는 경우에 UICC는 (1e-10 단계)에서 Terminal(1e-01)을 통해 수신한 메시지의 처리 결과 정상 응답인 경우, 정상 응답에 해당하는 SW1SW2=9000 대신에 SW1SW2=91XX로 회신(1e-20 단계)할 수 있다. 이 경우, 91XX에서 91은 Pending된 Proactive Command가 있음을 알리는 식별 정보로 사용될 수 있으며, “XX”는 FETCH해서 받아올 Proactive Command의 데이터 바이트 길이로 16진수로 표현할 수 있다. 한편, LuiccDATA는 (1e-10 단계)에서 수신한 Command APDU에 회신하는 DATA를 의미하며, DATA가 있는 경우에 한해 포함하여 전송할 수 있다. Terminal(1e-01)은 SW1SW2=91XX를 받으면 logical channel 0을 통해(즉, CLA=80 사용. CLA=80은 이 Command는 ETSI에서 정의한 Command로 채널 0번을 통해서만 전송하는 메시지라는 의미를 내포) FETCH Command 전송(즉, INS=12 (12는 FECH를 나타내는 숫자)할 수 있다. 이 때, (1e-20 단계)에서 수신된 'XX'를 회신을 기대하는 메시지 길이 byte (Le (Length of expected data field=XX)로 설정하여 UICC(1e-05)로 설정하여 전송할 수 있다 (1e-30단계).

(1e-40 단계)에서 해당 메시지를 수신한 UICC(1e-05)는 SW1SW2=9000, Data= Proactive Command로 하여 Terminal(1e-01)에 회신할 수 있다. Terminal(1e-01)은 DATA=Proactive Command를 수신하면 ETSI TS 102.223에 정의된 Proactive Command의 종류에 따라 요청되는 동작을 처리하고 나서 logical channel 0(즉, CLA=80)을 통해 Terminal Response(즉, INS=14 (14는 Terminal Response를 나타내는 숫자) Command APDU를 UICC(1e-05)에 전송할 수 있다(1e-50단계). 이 때, command APDU에 DATA field를 포함하여 전송하는 경우에, Terminal(1e-05)은 command APDU의 포함된 DATA의 바이트 길이 Lc 필드에 추가하여 전송할 수도 있다.

본 개시의 개시하는 시점에 v2 eUICC가 프로파일 상태 변경에 대한 ES10c.command를 Refreshflag를 포함하여 수신한 경우에, eUICC는 Proactive Command로 REFRESH Type의 Proactive Command로써 UICC Reset 모드 또는 eUICC Profile State Change모드를 FETCH Command를 수신 받았을 때 회신할 메시지로 등록해 두었다가 이를 전송할 수 있다.

REFRESH Proactive Command <UICC Reset 모드>는 UICC의 CAT(card application toolkit)이 ATR(answer to reset)을 받아야 하거나 UICC 초기화 과정 수행이 필요한 경우 사용할 수 있다. 본 개시가 개시되는 시점에 모뎀이 해당 요청을 수신하는 경우, 모뎀은 UICC 카드와의 모든 Application session 종료 절차를 수행 한 후, UICC의 대한 Cached Value를 삭제하고, UICC로 reset을 요청하여 UICC로 하여금 reset을 수행하고 ATR을 회신하게 할 수 있다. 이를 통해, 모뎀과 eUICC는 새로운 card session 시작하며, 모뎀은 REFRESH 수행을 완료 후 eUICC에 (1e-50단계)의 TERMINAL RESPONSE보내지 않고 절차를 완료하고, eUICC도 이에 따라 (1e-60단계)를 수행하지 않는다. 이에 대한 상세 설명은 TS102.223의 UICC Reset을 참조할 수 있다.

한편, 모뎀이 REFRESH Proactive Command <eUICC Profile State Change모드>를 수신하는 경우, 모뎀에서는 Application session 종료 절차를 수행하고 모뎀에 저장된 해당 Profile에 대한 Cached value를 모두 삭제한 후, Card는 ISD-R과의 전송에 사용하는 Logical channel 0은 남기고 나머지 channel은 모두 close하여 ETSI TS 102 221에 정의된 "default state after UICC activation and ATR" 로 복구한다. 해당 처리를 완료하면 모뎀은 (1e-50단계)에서와 같이 TERMINAL RESPONSE를 eUICC에 전송하게 된다. 이에 대한 상세 설명은 TS102.223의 UICC Reset을 참조할 수 있다.

본 개시를 개시하는 시점에 eUICC는 프로파일의 활성화 또는 비활성화를 처리하는 경우에, 모뎀에 eUICC Profile State Change 또는 UICC Reset 중 하나를 선택하여 전송할 수 있다. 현재까지 eUICC내 프로파일은 1개만 존재 하였으므로, 둘 중에 어떤 명령을 수신 받아 Software적인 Reset (eUICC profile state change을 수신하였을 때의 단말 동작, 또는 UICC Reset을 수신하였을 때 단말이 Software 적으로 초기화를 수행하는 경우)을 하거나, Reset PIN등을 통해 장치의 모든 전원을 끄고 초기화 상태로 복구하여 Reset하는 hard reset을 수행하더라도 문제 상황이 발생하지 않았다.

UICC(1e-05)가 Terminal(1e-01)로부터 수신한 Terminal Response Command APDU(1e-50 단계)에 포함된 정보로써 모든 처리가 문제 없이 처리되었음을 알게 되면, UICC(1e-05)는 SW1SW2=9000(정상 응답)을 Response APDU로 회신함으로써 Terminal(1e-10)과 UICC(1e-05)는 Proactive Command 처리 절차를 완료한다(1e-60단계).

한편, 도 5의 경우에는 Terminal(1e-01)과 UICC(1e-05)는 1개의 물리 인터페이스를 가지므로 하나의 인터페이스에서 다른 인터페이스에 보류 중인 Proactive Command를 획득하는 방법을 고려하지 않는다.

도 6은 Logical Interface를 사용하는 단말과 카드 간에 특정 Logical Interface에 대한 Proactive Command를 획득하여 처리하는 동작 순서를 도시한 예시 도면이다.

Terminal(1f-01)이 UICC(1f-05)로부터 ATR(answer to reset)을 수신하여 단말 및 카드 간의 데이터 송수신을 위한 카드 세션을 생성하고 난 이후 특정 시점에 Terminal(1f-01)은 UICC(1f-05)에 Command APDU를 전송(1f-10 단계)할 수 있다.

Terminal(1f-01)과 UICC(1f-05)간에 복수 개의 논리 인터페이스를 지원하여 동작하는 경우에 있어서는 Terminal(1f-01)과 UICC(1f-05)간의 논리 인터페이스 1개는 기존의 물리 인터페이스인 것처럼 Terminal(1f-01)과 UICC(1f-05)간에 처리해야 하므로, Terminal(1f-01)과 UICC(1f-05)간 연결된 논리 인터페이스에서 ATR을 수신한 경우, 해당 ATR을 수신한 논리 인터페이스에서만 데이터 송수신을 위한 카드 세션을 생성할 수 있다. 예를 들어 단말 및 카드 간 논리 인터페이스를 2개를 사용하는 경우, 단말은 카드의 포트 1에서 ATR을 수신하면 포트 1과 데이터 송수신을 위한 카드 세션을 생성하여 포트 1을 통해 메시지 송수신을 처리할 수 있고, 포트 2에서 ATR을 수신하여 포트 2와 데이터 송수신을 위한 카드 세션을 시작함으로써, 해당 포트 2를 통해 메시지 송수신을 처리할 수 있다.

(1f-10 단계)에서, UICC(1f-05)는 Terminal(1f-01)와 연결된 포트 중 하나에서 Command APDU를 수신할 수 있다. 이는 일 예로 도 5에서 언급한 메시지 포맷, 즉 CLA, INS, P1, P2, Lc, LcDATA, Le 중 일부로 구성된 메시지일 수 있다. UICC(1f-05)가 Terminal(1f-01)로부터 어떤 CLA 또는 INS로 구성된 메시지를 전송 받는지 무관하게 UICC(1f-05)가 메시지가 수신된 현재 포트와 다른 포트에 다른 단말에 전달이 필요한 Proactive Command가 있는 경우에 UICC(1f-05)는 단말에 (1f-10 단계)의 처리 결과로 SW1SW2=9000이 아닌 특정 포트 정보와 해당 포트에 대기 중인 Proactive Command가 있음을 나타내는 식별 정보를 포함하여 단말(1f-01)에 회신해 줄 수 있다. 이는 일 예로 도 1f-10에서 수신된 Command APDU에 회신 메시지에 포함하여 전송하는 SW1(status word1)SW2(status word2)로 나타내어 SW1은 특정 포트에 Proactive Command가 있음을 나타내는 식별 정보로 표기하고, SW2 XX는 FETCH를 수행할 포트 번호일 수 있고 이는 16진수로 표기된 포트 식별 정보로 나타낼 수 있다.

예를 들어, 94XX에서 “XX”는 FETCH를 수행할 포트 번호로, 16진수로 표현할 수 있다. 이 때, 94는 특정 포트에 Proactive Command가 있음을 나타내기로 정의한 임의의 숫자로 94가 아닌 다른 숫자로 정의되는 것도 가능하다. "XX"는 적어도 하나의 포트 번호 또는 모든 포트 번호를 나타내는 식별자를 포함할 수 있다. 모든 포트 번호를 나타내는 식별자로 XX=FF와 같이 표기될 수 있다. 한편, LuiccDATA는 (1f-10단계)에서 수신한 Command에 대한 회신 DATA로, LuiccDATA가 있는 경우에 포함하여 전송할 수 있다.

위 예시와 같이, 단말(1f-01)이 Response APDU의 값으로 94XX를 포함하여 수신하면, UICC(1f-05)는 94XX의 "XX"로 명시한 포트 번호를 통해 해당 Proactive Command를 획득할 수 있다. 이는, (1f-30 단계)에서 표기한 것과 같이 XX로 명시한 포트 번호의 Logical channel 0번을 통해(CLA=80) FETCH(INS=12) Command를 전송하고 해당 Command에 대한 응답 메시지로 (1f-40단계)와 같이 수신될 수 있다.

도 5와 다르게 단말(1f-01)은 앞서 (1f-10단계)에서 Le에 대한 정보를 수신 받지 못하였기 때문에, 단말(1f-01)은 1f-30단계에서 Le=00로 Set하여 전송함으로써 최대 수신 가능한 Response APDU의 데이터 필드 Byte까지 수신할 수 있음을 나타낼 수 있다.

(1f-40단계)에서 단말(1f-01)이 UICC(1f-05)로부터 SW1SW2=9000, Data= Proactive Command로 Proactive Command를 수신하면, 단말은 Proactive Command를 Parsing하여 ETSI TS 102.223에 정의된 Proactive Command의 종류에 따라 정의된 단말의 동작을 수행할 수 있다. 앞서 도 4에서 프로파일의 활성화, 비활성화 또는 eUICC 메모리 리셋과 같은 ES10c.command를 수신하는 경우에 있어서, UICC (1f-05)는 해당 프로파일이 점유하고 사용하고 있는 포트를 지정하여 Proactive Command를 등록할 수 있으며, 이 때 지정하는 Proactive Command의 종류는 ETSI TS 102.223에 정의된 UICC내의 파일의 상태가 변경되었음으로 나타내는 REFRESH 타입의 Proactive Command로 eUICC Profile State Change 모드 또는 UICC Reset 모드일 수 있다.

Terminal(1f-01)은 ETSI TS 102.223에 정의된 바와 같이 요청된 명령을 수행할 수 있다. 이 때, Terminal(1f-01)은 요청된 포트에 한정하여 해당 명령을 수행해야 함에 유의해야 한다. 예를 들어, Terminal(1f-01)이 포트 "3"으로 REFRESH Proactive Command의 UICC Reset을 수신하는 경우에 있어서, Terminal(1f-01)은 이를 해당 UICC와 연결된 모든 캐시된 정보를 삭제하고 해당 카드와의 모든 연결을 재 시작하는 절차로 처리하지 않고, 해당 포트 3에 한정하여 해당 포트 3과 연결된 프로파일과 관련된 캐시된 정보를 삭제하고 해당 포트 3에만 Reset을 요청하여 포트 3로부터 ATR을 수신하는 동작으로 처리해야 한다.

단말(1f-01)은 요청 받은 Proactive Command를 수행하고, 해당 처리한 포트의 logical channel 0(CLA=80)을 통해 Terminal Response (INS=14) Command를 UICC에 회신(1f-50)할 수 있다. 이를 수신 받은 UICC(1f-05)가 단말에 SW1SW2=9000를 보내어 해당 절차의 수행 완료를 알림(1f-60)으로써 절차를 완료할 수 있다. 만약, (1f-40 단계)에서 수신한 Proactive Command가 단말(1f-01)이 Card(1f-05)에 포트 리셋 명령을 수반하는 동작이거나 또는 ETSI TS 102.223에서 (1f-50 단계)과 (1f-60단계)를 강제하지 않는 경우에 단말은 (1f-50 단계)와 (1f-60 단계)를 생략하는 것도 가능할 수 있다.

앞서 "94XX"의 "XX"로 모든 포트 번호 식별자가 포함된 경우에는 Terminal(1f-01)은 해당 UICC와 연결된 모든 포트에 대해 포트 별로 (1f-30)단계에서 (1f-60)단계를 수행할 수도 있고, 또는 예외적으로 단말이 이를 플랫폼 리셋으로 인지하여 포트 별 처리가 아닌 기존 ETSI TS 102.223에 정의된 UICC Reset을 카드에 수행하는 것도 가능할 수 있다. 플랫폼 리셋을 인지하여 포트 별 처리가 아닌 기존 ETSI TS 102.223에 정의된 UICC Reset을 카드에 수행하는 경우에 있어서는 (1f-20 단계)를 수신하면 ETSI TS 102.223에 정의된 UICC Reset을 카드에 수행하는 동작으로 처리하여 완료할 수 있다.

도 7은 Logical Interface를 사용하는 단말과 카드 간에 특정 Logical Interface에 대한 Proactive Command를 획득하여 처리하는 동작 순서를 도시한 다른 예시 도면이다.

앞서 도 6에서 특정 포트에서 보류 중인 Proactive Command가 있음을 나타내는 정보로 Response APDU의 SW1SW2를 신규로 정의하는 방법을 기술하였으며, 도 7은 다른 실시 예로 새로운 Proactive Command 종류를 설정하여 처리하는 방법을 기술한다.

도 5에서 전술한 바와 같이 Terminal(1g-01)에서 UICC(1g-05)로 Command APDU를 보내면 어떤 CLA, INS를 가진 Command이든 무관하게 UICC(1g-05)는 이에 대한 응답 메시지로 Proactive Command가 있고, 해당 Proactive Command의 예상 바이트 길이가 얼마인지를 나타내는 식별 정보를 포함하여 회신할 수 있다. 논리 인터페이스를 지원하는 단말 및 카드에서 해당 메시지는 1개의 논리 인터페이스(즉, 포트)를 통해서 수신될 수 있다. (1g-10 단계)에서 어떤 CLA와 INS를 가진 Command APDU를 수신하였는지 여부와 무관하게, UICC(1g-05)가 pending된 proactive command가 있는 경우에 UICC는 (1g-10 단계)에서 Terminal(1g-01)을 통해 수신한 메시지의 처리 결과 정상 응답인 경우, 정상 응답에 해당하는 SW1SW2=9000 대신에 SW1SW2=91XX로 메시지가 수신된 해당 포트를 통해서 회신(1g-20 단계)할 수 있다. 예를 들어 단말이 0번 포트를 통해서 Command APDU를 전송한 경우, 0번 포트를 통해 SW1SW2=91XX를 수신 받게 될 수 있다.

앞서 91XX에서 91은 Pending된 Proactive Command가 있음을 알리는 식별 정보로 사용될 수 있으며, “XX”는 FETCH해서 받아올 Proactive Command의 데이터 바이트 길이를 나타낼 수 있다. 이는 16진수로 표현될 수 있다. 한편, LuiccDATA는 (1g-10 단계)에서 수신한 Command APDU에 회신하는 DATA를 의미하며, DATA가 있는 경우에 한해 포함하여 전송할 수 있다. Terminal(1g-01)은 SW1SW2=91XX를 받으면 logical channel 0을 통해(즉, CLA=80 사용. CLA=80은 이 Command는 ETSI에서 정의한 Command로 채널 0번을 통해서만 전송하는 메시지라는 의미를 내포) FETCH Command 전송(즉, INS=12 (12는 FECH를 나타내는 숫자)할 수 있다. 이 때, (1g-20 단계)에서 수신된 'XX'를 회신을 기대하는 메시지 길이 byte (Le (length of expected data field=XX)로 설정하여 UICC(1g-05)로 설정하여 전송할 수 있다 (1g-30단계).

해당 메시지를 수신한 UICC(1g-05)는 (1g-40 단계)에서 수신된 해당 포트를 통해서 Terminal(1g-01)에 SW1SW2=9000, Data= Proactive Command로 하여 메시지를 회신할 수 있다.

(1g-40 단계)에서 Terminal(1g-01)은 DATA=Proactive Command를 수신하여 Proactive Command의 종류가 수신된 포트와 다른 특정 포트에 대한 Polling을 요청하는 Proactive Command 것을 확인하는 경우에 있어서, 추가적으로 1g-65 단계를 수행할 수 있다.

Proactive Command는 TLV (Type-Length-Value)의 구성으로 나타낼 수 있으며, 상기 Value중의 하나의 데이터 필드로 Proactive Command의 Type 및 모드를 나타낼 수 있다. ETSI TS.102.223을 참조하면 Proactive command는 TLV 형태로 [표 3]과 같은 구조를 가질 수 있다. 해당 TLV에서 Value에 해당하는 데이터 필드들은 다시 TLV의 구조를 따른다. Proactive command는 TLV에서 Value로 하기 [표 3]에서와 같이 A와 B를 반드시 포함하며, Command details에 정의된 type of command의 값에 따라서 Device Identities 뒤에 추가되는 Value로서 데이터 필드, 예를 들어 Data field C, D..N 값이 추가로 정의될 수 있다.

Description	Clause	M/O/C	Min	Length
Proactive UICC command Tag	9.2	M	Y	1
Length (A+B+C+...+N)	-	M	Y	1 or 2
Command details	8.6	M	Y	A
Device identities	8.7	M	Y	B
Data field C		M/O/C	N	C
Data field N		M/O/C	N	N

상기 [표 3]에서 Command details 필드는 하기 [표 4]와 같은 TLV로 구성되어 있을 수 있다.

Byte(s)	Description	Length
1	Command details tag	1
2	Length = '03'	1
3	Command number	1
4	Type of command	1
5	Command Qualifier	1

한편, 포트 번호를 포함하고 특정 포트에 대한 Polling을 요청하는 Proactive Command는 다음 1)-6)중 조합을 포함하여 구성될 수 있으나, 적어도 포트 번호 그리고 Polling에 에 대한 식별 정보를 반드시 포함해야 한다. 1) [표 3]의 Value로 포트 번호에 대한 데이터 필드 추가

2) [표 3]의 Value로 어떤 동작을 수행할 지에 대한 데이터 필드 추가하고

해당 데이터필드에 대한 TLV의 Value로써 수행할 동작의 하나로 Polling 또는/그리고 포트 번호를 지정

3) [표 3]의 Value로 Polling에 대한 데이터 필드 추가

4) [표 4]의 Type of command로 다른 포트에 대한 동작을 수행하는 Type 정의하고, 해당 Command Qualifier TLV의 Value로써 어떤 동작을 수행(예. Polling)할 것인지에 대한 식별 정보 포함.

5) Type of command로 다른 포트에서의 Polling 요청 Type 정의

6) Type of command로 다른 포트에 대한 동작을 수행을 요청하는 Type을 정의

위의 조합으로 구성한 하나의 예로 아래와 같은 TLV 형태일 수 있으며, 이에 한정되지 않는다,

LSI ACTIVITY Proactive Command

Description	Clause	M/O/C	Min	Length
Proactive UICC command Tag	9.2	M	Y	1
Length (A+B+C)	-	M	Y	1 or 2
command details	8.6	M	Y	A
Device identities	8.7	M	Y	B
Logical SE Interface number	8.XX	M	N	C

Command details의 Type of Command로 8X와 같은 LSI ACTIVITY TYPE 의미하는 숫자 지정하고, 해당 Type of Command로 Command Qualifier로 다음과 같이 지정.- LSI ACTIVITY:

* '00' = LSI Polling;

* '01' to 'FF' = reserved values.

Logical SE Interface number

Byte(s)	Description	Length
1	Logical Interface ID tag	1
2	Length(n) of byte following	1
3	LSI number 1	1
4	LSI number 2	1
n	LSI number n	1

포트 번호로서 LSI number는 적어도 1개 이상을 포함할 수 있다. 1개 이상의 포트 번호가 포함된 경우에 있어서 단말(1g-01)은 해당 숫자만큼 (1g-65 단계) 절차를 수행할 수 있다. 즉, LSI number 1과 LSI number 2가 각 포트 번호 3, 포트 번호 4를 의미하는 정보로 표현된 경우, 1g-65 단계는 2번 수행되며, 각 포트 번호, 포트 번호 4를 통해 각 1번, 총 2번 수행된다. 각 LSI number는 16진수로 표현된 포트 번호 1개 또는 모든 포트 번호를 나타내는 식별자, 예를 들어 FF, 포함하는 것도 가능할 수 있다. 모든 포트 번호 식별자가 포함된 경우에는 해당 UICC와 연결된 모든 포트에 대해 각 포트 별로 1g-65 단계를 수행할 수도 있고, 또는 예외적으로 단말이 플랫폼 리셋으로 인지하여 포트 별 처리가 아닌 기존 ETSI TS 102.223에 정의된 UICC Reset을 카드에 수행하는 것도 가능할 수 있다. 단말(1g-01)은 ETSI TS 102.223에 정의된 Proactive Command의 종류에 따라 요청되는 동작을 처리하고 나서 UICC(1g-05)에 logical channel 0(즉, CLA=80)을 통해 Terminal Response(즉, INS=14 (14는 Terminal Response를 나타내는 숫자) Command APDU를 UICC(1g-05)에 전송한다(1g-50단계). 이 때, command APDU에 DATA field를 포함하여 전송하는 경우에, Terminal(1g-01)은 command APDU의 포함된 DATA의 바이트 길이 Lc 필드에 추가하여 전송할 수도 있다.

앞서 (1g-40)단계에서 단말(1g-01)에서 Proactive Command를 수신하여 단말(1g-01)은 Proactive Command를 파싱한 결과, 해당 Command에 특정 포트 번호를 포함하고 있고, 해당 포트에 대한 Polling 요청에 대한 Proactive Command인지 Command Type 또는 Type에서 요구하는 특정 동작에 대한 식별 정보로써 단말이 판단하여 해당 동작에 대한 수행이 가능하다고 단말이 판단하면 단말은 (1g-65 단계)의 절차를 이어서 처리할 수 있다.

1g-70단계 이후의 동작은 1g-40 절차 이후 1g-50 또는 1g-60 단계 시작 시점 이전에 전송될 수 도 있다. 즉, 단말이 Proactive Command를 0번 포트에서 수신하여 특정 포트 Polling에 대한 요청 임을 판단한 결과, 단말은 해당 특정 포트, 예를 들어 포트 3에 대한 Polling 동작 수행이 필요함을 인지하면 단말은 0번 포트로 1g-50과 1g-60 단계를 처리하지만, 1g-50을 포트 1번으로 수신되는 것과 별개로 1g-70 단계를 포트 3에서 시작할 수 있다.

단말(1g-01)이 3번 포트에 대한 Polling을 요청하는 Proactive Command를 0 포트에서 수신한 후(1g-40 단계)에, 3번 포트에서 Polling을 수행을 시작하는 동작은 예를 들어 FETCH Command와 같은 명령으로 시작(1g-90단계)할 수 있다. 또는, Proactive Polling을 위한 Status Command APDU와 같은 명령(1g-70 단계)일 수도 있다. 예를 들어 Status Command APDU와 같은 명령인 경우, 1g-70단계에서 단말(1g-01)은 포트 3번의 어떤 채널 번호를 통해서든 단말(1g-01)에서 Status Command APDU 명령을 전송할 수 있다. 이 때, ETSI TS.102.221을 참조하면 CLA='8X' or 'CX' or 'EX' 같은 값을 가지고 INS='F2' (STATUS Instruction을 나타냄)을 가진다. 이에 대한 회신 메시지로 UICC(1g-05)는 보낼 proactive command가 있음을 나타내는 식별자인 91과 해당 proactive command의 바이트 길이로서 XX를 포함하여 Response APDU를 단말(1g-01)전송할 수 있다. 해당 메시지를 수신한 Terminal(1g-01)은 해당 포트 3번의 채널 0번을 통해서 FETCH Command를 전송(1g-90)하여 해당 포트 3번에서 대기 중인 Proactive Command를 획득할 수 있다. 이 때, (1g-80단계)에서 Le=XX로 이미 단말에 전달되었기 때문에 단말은 (1g-90단계)에서 앞서 수신한 91XX의 "XX"으로 하여 FETCH command를 전송할 수 있다.

Polling을 수행하는 동작으로 단말(1g-01)은 FETCH Command를 바로 전송(1g-90)할 수 있다. 앞서 1g-40에서 단말(1g-01)이 이미 Pending된 Proactive Command가 있음을 시사하는 Proactive Command를 UICC(1g-05)로부터 받았기 때문에 단말(1g-01)은 해당 포트로 FETCH command를 전송한다. 이 때 수신할 Proactive Command에 대한 데이터 길이를 수신 받지 못했으므로 단말(1g-01)은 Le를 Response APDU의 Data로 수신 가능한 최대 데이터 크기임을 나타내는 값인 00으로 지정하여 전송할 수도 있다.

(1g-100단계)에서 단말(1g-01)이 UICC(1g-05)로부터 SW1SW2=9000, Data= Proactive Command로 Proactive Command를 수신하면, 단말은 Proactive Command를 Parsing하여 ETSI TS 102.223에 정의된 Proactive Command의 종류에 따라 정의된 단말의 동작을 수행할 수 있다. 앞서 도 4에서 프로파일의 활성화, 비활성화 또는 eUICC 메모리 리셋과 같은 ES10c.command를 수신하는 경우에 있어서, UICC (1g-05)는 해당 프로파일이 점유하고 사용하고 있는 포트를 지정하여 Proactive Command를 등록할 수 있으며, 이 때 지정하는 Proactive Command의 종류는 ETSI TS 102.223에 정의된 UICC내의 파일의 상태가 변경되었음을 나타내는 REFRESH 타입의 Proactive Command로 eUICC Profile State Change 모드 또는 UICC Reset 모드일 수 있다. Terminal(1g-01)은 ETSI TS 102.223에 정의된 바와 같이 요청된 명령을 수행할 수 있다. 이 때, Terminal(1g-01)은 요청된 포트에 한정하여 해당 명령을 수행해야 함에 유의해야 한다. 예를 들어, Terminal(1g-01)이 포트 "3"로 REFRESH Proactive Command의 UICC Reset을 수신하는 경우에 있어서, Terminal(1g-01)은 이를 해당 UICC와 연결된 모든 캐시된 정보를 삭제하고 해당 카드와의 모든 연결을 재 시작하는 절차로 처리하지 않고, 해당 포트 3에 한정하여 해당 포트 3과 연결된 프로파일과 관련된 캐시된 정보를 삭제하고 해당 포트 3에만 Reset을 요청하여 포트 3로부터 ATR을 수신하는 동작으로 처리해야 한다. 단말(1g-01)은 요청 받은 Proactive Command를 수행하고, 해당 처리한 포트의 logical channel 0(CLA=80)을 통해 Terminal Response (INS=14) Command를 UICC에 회신(1g-110) 할 수 있다. 이를 수신 받은 UICC(1g-05)가 단말에 SW1SW2=9000를 보내어 해당 절차의 수행 완료를 알림(1g-120)으로써 절차를 완료할 수 있다. 만약, (1g-100 단계)에서 수신한 Proactive Command가 단말(1g-01)이 UICC(1g-05)에 포트 리셋 명령을 수반하는 동작이거나 또는 ETSI TS 102.223에서 (1g-110 단계)과 (1g-120 단계)를 강제하지 않는 경우에 단말은 (1g-110 단계)와 (1g-120 단계)를 생략하는 것도 가능할 수 있다.

만약 Polling을 요청 받은 포트에서 단말(1g-01)이 전송한 명령(Command)을 처리하는 중에 있거나 또는 단말(1g-01)에서 UICC(1g-05)에서 전송할 명령(Command)이 있는 경우에, 단말(1g-01)은 UICC(1g-05)에 Polling을 요청을 수신 받은 포트를 통해 (1g-50)단계에서 에러를 리턴(return)하지 않고 정상 응답(Terminal Response=OK)으로 회신하거나 또는 이 (1g-50)단계를 수행하지 않을 수 있다. 즉, 응답(Terminal Response)을 회신하지 않을 수 있다. 이 경우에, 또한 단말(1g-01)은 단말(1g-01)이 UICC(1g-05)로부터 Polling을 요청 받은 포트로 FETCH Command를 전송하거나 또는 STATUS Command를 전송하는 대신에 처리하고 있는 Command의 Response 값 또는 전송할 any Command의 Response 값으로 UICC로부터 91XX를 수신 받아, 해당 포트에 Pending된 Proactive Command를 처리하는 절차를 시작하는 것도 가능할 수 있다. 즉, (1g-70)단계에서 단말은 앞서 일 예로 든 STATUS Command 대신 어떤 Command도 전송할 수 있다. 이 경우, UICC(1g-05)는 해당 Polling을 요청 받은 포트에서 Proactive Command를 준비하고 있다가, 단말로부터 수신된 어떤 Command가 오더라도 91XX를 회신(1g-80)함으로써, ETSI TS 102.221에 정의된 바와 같이 단말이 다시 FETCH Command를 전송(1g-90)하여 Proactive Command를 획득하게끔 하는 이후 절차를 처리하게 하는 것도 가능하다. 이 경우, (1g-90)에서 Le는 UICC가 회신한 91XX에서 XX 값으로 지정될 수 있다.

도 8은 특정 포트에 대한 Polling을 수행하는 과정에서 발생 가능한 Error 및 Error Handling에 대한 방법들을 도시한 도면이다.

전술한 바와 같이 Terminal(1h-25)은 SE(secure element, 예: UICC)(1h-01)와 복수 개의 Logical SE Interface들을 가질 수 있으며 하나의 Interface를 통해서 단말(1h-25)에서 Logical SE Interface가 점유한 logical SE 안에 있는 데이터 또는 애플리케이션과 메시지를 주고 받을 수 있다. Logical SE은 하나의 SE(예를 들어, UICC일 수 있다.)처럼 동작할 수 있도록 하는 파일들과 애플리케이션들의 그룹을 나타내며, 예를 들어 프로파일 1개가 하나의 예가 될 수 있다. SE(1h-01)에는 여러 개의 logical SE가 동작할 수 있는 플랫폼 기능을 하는 파일들과 애플리케이션들이 존재(1h-10)할 수 있다. ISD-R은 하나의 Logical SE 안에 있는 애플리케이션 또는 플랫폼 기능을 하는 파일들과 애플리케이션(1h-10)들 중의 하나의 애플리케이션으로 존재할 수도 있다. Proactive Command는 CAT (card application toolkit)을 지원하는 Logical SE Interface를 통해 전송할 수 있으며, 애플리케이션에서 직접 Proactive Command를 전송하거나 또는 애플리케이션에서 Proactive Command 전송을 관장하는 S/W 모듈에 Proactive Command를 있음을 등록하여 플랫폼(1h-10)에서 전송하는 것이 가능할 수 있다. 예를 들어 Logical SE에서 전송할 Proactive Command가 있는 경우 이를 플랫폼(1h-10)에서 이를 관장하는 S/W 모듈에 등록하여 플랫폼(1h-10)으로 하여금 Proactive Command를 포함한 Response APDU를 단말에 전송할 수 있도록 처리할 수 있다. Logical SE 0 (1h-15)에 ISD-R이 있는 경우에, ISD-R이 단말(1h-25)에 전송할 Proactive Command, 예를 들어 LSI ACTIVITY Proactive Command <LSI Polling>를 플랫폼의 이를 관장하는 S/W 모듈에 등록(1h-30)하고 해당 S/W 모듈에서 이 Proactive Command를 필터링하여 전송할 수 있도록 처리할 수 있다. 일부 Proactive Command는 플랫폼 레벨(1h-10) 또는 특정 포트에서만 발행하여 전송하도록 처리할 수 있으며 이를 System Proactive Command라고 표현하겠다.

System Proactive Command로 처리하는 경우, SE내의 지정되지 않은 UICC의 앱 또는 포트에서 해당 Proactive Command를 전송하고자 하는 경우 플랫폼 레벨에서 이를 관장하는 S/W모듈에서 해당 Proactive Command를 전송하지 못하도록 필터링하여 처리하는 것도 가능할 수 있다.

앞서 ACTIVITY Proactive Command <LSI Polling>를 System Proactive Command로 정의될 수도 있으며, 이 경우에 Logical SE 0(1h-15)에 있는 파일 또는 애플리케이션으로 존재하는 경우, ACTIVITY Proactive Command <LSI Polling>을 Proactive Command를 관장하는 플랫폼 내의 S/W 모듈에 등록하고자 하면(1h-30)에 해당 S/W 모듈에서 이를 필터링하여 전송할 수 없도록 처리할 수도 있다. 플랫폼(1h-01) 내의 파일 또는 애플리케이션(1h-10)에서 또는 logical SE(1h-15)의 파일 또는 애플리케이션이 해당 S/W 모듈에 ACTIVITY Proactive Command <LSI Polling> 등록(1h-30)하면 S/W 모듈에서 FETCH Command APDU를 수신 받는 경우에, ACTIVITY Proactive Command <LSI Polling>을 전송(1h-45)할 수 있다.

위에서 Proactive Command를 관리하는 S/W 모듈은 ETSI TS 102.224에서 정의하는 Card Application Toolkit(CAT) Runtime Environment와 같은 S/W 모듈일 수 있다. Proactive Command를 관리하는 S/W 모듈은 (1h-10)안에 포함되는 것으로 예로 들어 설명하였으나, 해당 S/W 모듈의 일부 또는 전체 기능이 개별 Logical SE안에 포함될 수도 있다. 일 예로, Logical SE 0, Logical SE 1, Logical SE 2에 Proactive Command를 등록 하는 S/W 기능을 포함하고, 플랫폼 레벨(1h-10)에서 등록된 Proactive Command를 전송할 때의 필터링하는 S/W 기능을 제공할 수 있다.

해당 메시지를 수신 받은 단말(1h-45) 모뎀의 메시지 처리부는 메시지를 파싱하여 처리가 가능한지 판단하여 정상 처리하지 못하는 다음과 같은 상황이 발생하는 경우, 단말은 이에 대한 에러 코드 또는 에러 메시지를 앞서 도 7의 (1g-50) 단계에서 Terminal Response에 포함하여 전송(1h-50)하고 절차를 종료할 수 있다.

· 단말이 해당 Type의 Proactive Command를 모르는 경우

· 단말이 해당 Type의 Proactive Command를 알고 있으나 Proactive Command에 포트 번호가 없는 경우

· 단말이 해당 Type의 Proactive Command를 알고 있고 포트 번호가 포함되어 수신되었으나, 단말이 해당 포트 번호를 모르는 경우 (본 도면에서 예를 들어 포트 번호 4가 수신된 경우)

· 단말에서 해당 Proactive Command를 특정 포트를 통해서만 수신하기로 단말-UICC간 정의한 경우에 있어서, 해당 포트가 아닌 다른 포트로 해당 Proactive Command가 수신되는 경우

한편, SE(1h-01)에서 특정 포트에 대한 Polling을 요청하는 식별자를 도 6과 같이 SW1SW2로 전송하는 경우도 있을 수 있다. 해당 메시지를 수신 받은 단말(1h-45) 모뎀의 메시지 처리부는 메시지를 파싱하여 처리가 가능한지 판단하여 정상 처리하지 못하는 다음과 같은 상황이 발생하는 경우, 단말은 이에 대한 에러 코드 또는 에러 메시지를 도 6의 (1f-30)단계에서 Terminal Response에 포함하여 전송(1h-50)하고 절차를 종료할 수 있다.

· 단말이 SW1SW2=94XX로 정의된 Status Word를 모르는 경우

· 단말이 SW1SW2=94XX를 알고 있으나 XX가 단말이 해당 포트 번호를 모르는 경우 (본 도면에서 예를 들어 포트 번호 4가 수신된 경우)

· 단말이 SW1SW2=94XX을 특정 포트를 통해서만 수신하는 것으로 단말-UICC간 정의한 경우에 있어서, 해당 포트가 아닌 다른 포트에서 SW1SW2=94XX를 수신한 경우

단말이 해당 Type의 Proactive Command를 모르는 경우 또는 단말이 SW1SW2=94XX로 정의된 Status Word를 모르는 경우의 에러는, 단말 및 카드 간의 초기 연결 설정 시 성능 협상 하는 단계에서 단말이 카드에게 해당 Type of Command 또는 SW1SW2 를 지원하는지 알려줌으로써 발생하지 않도록 처리할 수도 있다. 예를 들어, 단말은 카드와의 초기화 과정에서 CAT(Card Application Toolkit)에 대한 단말의 Capability를 나타내는 정보로 Command APDU <INS=Terminal Profile>를 전송하면서 해당 Type of Proactive Command를 지원함을 indicate 하는 bit를 추가하여 전송해 줄 수 도 있다.

도 9는 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 단말의 내부 구조를 개략적으로 도시한 도면이다.

도 9을 참고하면, 단말(1i-00)은 송수신부(1i-10), 메시지 처리부(1i-20), 제어부(1i-30), 메모리(1i-40) 및 화면 표시부(1i-50)를 포함한다. 다만 단말(1i-00)의 구성 요소가 전술한 예에 한정되는 것은 아니다. 예를 들어, 기지국은 전술한 구성 요소보다 더 많은 구성 요소를 포함하거나 더 적은 구성 요소를 포함할 수 있다. 뿐만 아니라, 단말(1i-00)의 적어도 하나의 구성이 하나의 칩 형태로 구현될 수 있다. 일부 실시예에 따르면, 송수신부(1i-10)는 신호의 대역 변환, 증폭 등 무선 채널을 통해 신호를 송수신하기 위한 기능을 수행할 수 있다. 즉, 송수신부(1i-10)는 기저대역 신호를 RF 대역 신호로 상향 변환한 후 안테나를 통해 송신하고, 안테나를 통해 수신되는 RF 대역 신호를 기저대역 신호로 하향 변환하는 RF 처리부를 포함하며, 송신 필터, 수신 필터, 증폭기, 믹서(mixer), 오실레이터(oscillator), DAC(digital to analog convertor), ADC(analog to digital convertor) 등을 더 포함할 수 있다.

또한, 송수신부(1i-10)는 무선 채널을 통해 신호를 수신하여 프로세서(1i-30)로 출력하고, 제어부(1i-30)로부터 출력된 신호를 무선 채널을 통해 전송할 수 있다. 송수신부(1i-10)는 빔포밍(beamforming)을 수행할 수 있다. 빔포밍을 위해, 송수신부(1i-10)는 복수의 안테나들 또는 안테나 요소(element)들을 통해 송수신되는 신호들 각각의 위상 및 크기를 조절할 수 있다. 또한 송수신부(1i-10) 내의 기저대역 처리부는 시스템의 물리 계층 규격에 따라 기저대역 신호 및 비트열 간 변환 기능을 수행할 수 있다. 예를 들어, 데이터 송신 시, 기저대역 처리부는 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성한다. 또한, 데이터 수신 시, 기저대역 처리부는 RF처리부로부터 제공되는 기저대역 신호를 복조 및 복호화를 통해 수신 비트열을 복원한다. 예를 들어, OFDM(orthogonal frequency division multiplexing) 방식에 따르는 경우, 데이터 송신 시, 기저대역 처리부는 송신 비트열을 부호화 및 변조함으로써 복소 심벌들을 생성하고, 복소 심벌들을 부반송파들에 매핑한 후, IFFT(inverse fast Fourier transform) 연산 및 CP(cyclic prefix) 삽입을 통해 OFDM 심벌들을 구성한다.

또한, 데이터 수신 시, 기저대역 처리부는 RF처리부로부터 제공되는 기저대역 신호를 OFDM 심벌 단위로 분할하고, FFT(fast Fourier transform) 연산을 통해 부반송파들에 매핑된 신호들을 복원한 후, 복조 및 복호화를 통해 수신 비트열을 복원할 수 있다.

송수신부(1i-10)는 송수신기(transceiver)로 정의될 수 있으며, 메시지 송수신부를 포함할 수 있다. 메시지 처리부(1i-20)는 송수신부(1i-10)를 통해 송신하거나 혹은 수신한 데이터가 어떠한 메시지인지를 판단하는 동작을 수행할 수 있다. 예를 들어, 상기 메시지 처리부(1i-20)는 수신한 메시지가 (SIB(System Information Block)를 포함한) RRC(Radio Resource Control) 계층의 제어 메시지인지 혹은 사용자의 데이터 메시지인지를 판단할 수 있다. 메시지 처리부(1i-20)는 제어부(1i-30)에 포함될 수 있다.

제어부(1i-30)는 단말(1i-00)의 전반적인 동작들을 제어한다. 예를 들어, 제어부(1i-30)는 메시지 처리부(1i-20)를 통해 신호를 송수신한다. 또한, 제어부(1i-30)는 메모리(1i-40)에 데이터를 기록하고 읽는다. 제어부(1i-30)는 적어도 하나일 수 있다. 예를 들어, 제어부(1i-30)는 통신을 위한 제어를 수행하는 CP(communication processor) 및 응용 프로그램 등 상위 계층을 제어하는 AP(application processor)를 포함할 수 있다. 일부 실시 예에 따르면, 메모리(1i-40)에 사전에 저장된 기기 변경에 대한 사업자 구성(Configuration) 정보가 있는 경우에 제어부(1i-30)는 해당 정보를 메모리(1i-40)에 요청하여 화면 표시부(850)가 표시하거나 해당 정보를 받아서 추가적인 동작을 처리할 수 있다.

상기 제어부(1i-30) 및 메시지 처리부(1i-20), 송수신부(1i-10)는 사용자 또는 단말 설정에 따라 선택한 사업자 망으로의 접속을 수행하도록 단말(1i-00)을 제어할 수 있다. 또한, 일부 실시예에 따르면, 제어부(1i-30)는 메모리(1i-40)를 통해서 읽은 데이터 기록, 또는 제어부(1i-30) 및 메시지 처리부(1i-20), 송수신부(1i-10)를 통해 수집된 정보를 매칭하여 서비스 선택에 참조할 수 있는 정보를 단말이 추론하는 처리 과정을 수행할 수 있다. 일부 실시예에 따르면, 제어부(1i-30)는 단말(1i-00)에 저장된 특정 정보에 대한 사용자 동의가 필요한지 여부를 판단하고, 화면 표시부(1i-50)에 표시할 수 있다.

또한, 제어부(1i-30)는 이에 대응하는 동작을 수행하도록 단말(1i-00)을 제어할 수 있다. 일부 실시 예에 따르면, 제어부(1i-30)는 eUICC의 구동 및 제어를 담당하는 LPA, LPA가 통합 구현된 애플리케이션을 포함할 수 있다. 또한, 일부 실시 예에 따르면, 제어부(1i-30)는 LPA로 또는 애플리케이션에 수신된 정보를 해석하여 CP(communication processor)에 특정 Command APDU 요청을 처리하거나 요청된 정보의 일부 또는 전체를 메모리(1i-40)로부터 수집하여 LPA 또는 애플리케이션에 회신하는 단말 프레임워크를 포함할 수 있다.

제어부(1i-30)는 단말(1i-00)과 송수신부(1i-10)을 통해 eUICC(1i-60)으로 부터 획득한 소정의 정보를 종합하여 MEP 모드로 동작함과 ISD-R 접근 방식을 결정하여 eUICC(1i-60)에 회신해 줄 수 있다. eUICC(1i-60)은 제어부(1i-30)에 의해 제어되며, 본 개시의 실시예에 따라 eUICC(1i-60)는 각 관리 명령을 수행하고, 모뎀 등으로 Proactive Command를 전달할 수 있다.

메모리(1i-40)는 단말(1i-00)의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 실시 예에서는 메모리(1i-40)는 롬(ROM), 램(RAM), 하드디스크, CD-ROM 및 DVD 등과 같은 저장 매체 또는 저장 매체들의 조합으로 구성되며 제어부(1i-30)의 요청에 따라 Terminal Capability로 저장된 데이터를 제공할 수 있다. 또한, 메모리(1i-40)은 제어부(1i-30)와 SoC(System on Chip)으로 통합 구현되어 있을 수 있다.

한편, 본 개시의 실시 예에서는 eUICC(1i-60)은 탈착식으로 단말(1i-00) 외부에 별도의 모듈로 존재하여 단말에 삽입되거나 또는 단말에 탈착 불가능하도록 고정된 형태도 가능할 수 있다. 한편, 단말(1i-00)은 하드웨어 보안 모듈(SE)로 UICC, eUICC, iSSP, iUICC를 포함할 수 있음에 유의해야 한다. 단말 및 카드간 Interface를 구분하여 설명하는 경우에 있어서 단말은 카드를 제외한 단말의 구성부들로 나타낸다. eUICC(1i-60)은 또한 내부에 단말(1i-00)의 모듈에서 화면 표시부(1i-50)를 제외한 다른 부중의 일부 또는 전체를 포함하여 구성될 수 있다. 예를 들어, 본 개시의 일 실시 에에 따라서 eUICC(1i-60)의 제어부는 메시지송수신부를 통해서 수신된 단말(1i-00)의 Terminal Capability 정보를 메시지 처리부를 통해서 처리하여 획득한 후, 해당 메시지 정보를 통해서 ISD-R 접근 방식 및 MEP 지원 여부에 대한 소정의 정보를 획득/조합하여 eUICC(1i-60)내의 ISD-R 접근 방식 및 MEP 지원 여부를 결정하고 이에 따라 포트별 프로파일의 활성화 권한 또는 포트별로 ISD-R AID(Application ID)로 접근을 허용하는지에 대한 권한을 설정할 수 있다. 또한, eUICC(1i-60)의 제어부는 Proactive Command를 필터링하여 메시지를 송수신부틀 통해 단말(1i-00)로 전송할 수도 있다.

화면표시부(1i-50)는 제어부(1i-30)에서 처리/가공한 정보를 표시하거나 제어부(1i-30) 처리를 통해 단말(1i-00)이 수행하는 동작에 대한 진행 과정 또는 사용자에게 수행을 요청하는 이벤트에 대한 동의 등을 표시할 수 있다. 일부 실시 예에 따르면, 저장된 프로파일 정보, 프로파일 활성화 요청 입력 및 입력된 결과를 사용자에게 회신하여 표시할 수 있다. 일부 실시 예에 따르면, LPA 또는 LPA가 통합 구현된 애플리케이션은 화면표시부(1i-50)와 제어부(1i-30)를 포함할 수 있다.

본 문서에 개시된 다양한 실시 예들에 따른 단말은 전자 디바이스가 될 수 있으며, 상기 전자 디바이스는 다양한 형태의 디바이스가 될 수 있다. 상기 전자 디바이스는, 예를 들면, 휴대용 통신 디바이스 (예: 스마트폰), 컴퓨터 디바이스, 휴대용 멀티미디어 디바이스, 휴대용 의료 기기, 카메라, 웨어러블 디바이스, 또는 가전 디바이스를 포함할 수 있다. 본 문서의 일 실시 예에 따른 전자 디바이스는 전술한 기기들에 한정되지 않는다.

본 문서의 다양한 실시 예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시 예들로 한정하려는 것이 아니며, 해당 실시예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 상기 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나","A 또는 B 중 적어도 하나,""A, B 또는 C," "A, B 및 C 중 적어도 하나,"및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제 1", "제 2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제 1) 구성요소가 다른(예: 제 2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 상기 어떤 구성요소가 상기 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제 3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.

본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 상기 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일 실시 예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.

본 문서의 다양한 실시 예들은 머신(machine)(예: 전자 디바이스) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리 또는 외장 메모리)에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램)로서 구현될 수 있다. 예를 들면, 머신(예: 전자 디바이스)의 프로세서는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 기기가 상기 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 상기 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 기기로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 실재(tangible)하는 디바이스고, 신호(signal)(예: 전자기파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.

일 실시 예에 따르면, 본 문서에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 기기로 읽을 수 있는 저장 매체(예: compact disc read only memory (CD-ROM))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어^TM)를 통해 또는 두 개의 사용자 디바이스들(예: 스마트폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 기기로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.

다양한 실시 예들에 따르면, 상기 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시 예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 상기 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 상기 통합 이전에 상기 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 상기 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

한편 본 개시의 상세한 설명에서는 구체적인 실시 예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다. 그러므로 본 개시의 범위는 설명된 실시 예에 국한되어 정해져서는 아니 되며 후술하는 특허청구의 범위뿐만 아니라 이 특허청구의 범위와 균등한 것들에 의해 정해져야 한다.

Claims (1)

1. 무선 통신 시스템에서 제어 신호 처리 방법에 있어서,
   기지국으로부터 전송되는 제1 제어 신호를 수신하는 단계;
   상기 수신된 제1 제어 신호를 처리하는 단계; 및
   상기 처리에 기반하여 생성된 제2 제어 신호를 상기 기지국으로 전송하는 단계를 포함하는 것을 특징으로 하는 제어 신호 처리 방법.

Images