KR101111141B1

KR101111141B1 - 무선 통신 네트워크를 통하여 무선 단말을 구성하는 방법,관련 네트워크 및 이를 위한 컴퓨터 프로그램 제품

Info

Publication number: KR101111141B1
Application number: KR1020077011839A
Authority: KR
Inventors: 엔리코 부라치니; 파올로 고리아; 알레산드로 트로골로
Original assignee: 텔레콤 이탈리아 소시에떼 퍼 아찌오니
Priority date: 2004-10-28
Filing date: 2004-10-28
Publication date: 2012-03-08
Also published as: ATE483334T1; JP2008518528A; BRPI0419171A; BRPI0419171A8; CN101077024A; US20090067367A1; KR20070074637A; WO2006045334A1; DE602004029403D1; ES2353877T3; EP1806015B1; US9031550B2; CN101077024B; EP1806015A1

Abstract

통신 시스템에 따른 통신 네트워크 동작을 통하여 재구성가능한 무선 단말을 구성하기 위한 방법에 있어서, 상기 무선 단말은 상기 통신 시스템을 사용하는 것에 의해 상기 통신 네트워크의 적어도 하나의 노드와 정보를 교환하도록 설계된다. 상기 방법은 상기 프로토콜 계층(RR, GMM)을 사용하도록 구성되고 상기 무선 단말(MS)을 재구성하는데 적합한 적어도 하나의 프로토콜 스택 요소들의 세트로 상기 무선 단말(UE/MS)을 구성하기 위한 운영 소프트웨어 모듈들의 세트를 포함하는 서버 엔터티(OTA 서버)를 상기 통신 네트워크의 적어도 하나의 노드와 연관시키는 단계; 상기 서버 엔터티(OTA 서버)의 상기 프로토콜 계층(RR, GMM)에 대응하는 각각의 프로토콜 계층들을 사용하도록 구성된 클라이언트 엔터티(OTA 클라이언트)를 상기 무선 단말(MS)에 연관시키는 단계; 상기 프로토콜 계층들을 사용하는 것에 의하여 상기 무선 단말(UE/MS)과 상기 서버(OTA 서버) 사이의 OTA 연결을 확립하는 단계; 및wjrdjeh 부분적으로 상기 무선 단말(UE/MS)을 구현하기 위하여 상기 서버(OTA 서버)로부터 상기 무선 단말(UE/MS)로 상기 운영 소프트웨어 모듈들의 세트 중 적어도 하나의 모듈을 다운로드하는 단계를 포함하는 것을 특징으로 한다.

무선 단말, 통신 네트워크, GSM, GPRS, UTMS, 운영 소프트웨어, 단말 재구성

Description

무선 통신 네트워크를 통하여 무선 단말을 구성하는 방법, 관련 네트워크 및 이를 위한 컴퓨터 프로그램 제품{A METHOD FOR CONFIGURING A RADIO TERMINAL THROUGH A RADIO COMMUNICATION NETWORK, RELATED NETWORK AND COMPUTER PROGRAM PRODUCT THEREFOR}

본 발명은 일반적으로 무선 통신 네트워크 및 무선 통신 네트워크를 사용한 재구성가능한 무선 단말들에 관한 것이다.

좀 더 구체적으로, 본 발명은 무선 단말의 재구성에 관한 것으로, 상기 재구성은 무선 통신 네트워크로부터 OTA(Over the air) 방식으로 다운로드된 운영 소프트웨어를 상기 무선 단말에 설치하는 것에 의하여 수행된다.

단말들, 기지국들, 네트워크 노드들과 같이 재구성가능한 시스템은 동작 장동 모드가 재구성가능한 장치라는 것이 논문(J. Mitola의 "The Software Radio Architecture", IEEE Communiations Magazaine, May 1995 및 E. Buracchini의 "The Software Radio Concept", IEEE Communications Magazine, September 2000)으로부터 공지되어 있다. 예를 들면, GSM/GPRS(Global System for Mobile Communication/General Packet Radio Service)와 같은 2세대 시스템(2G)으로 동작할 수 있는 재구성가능한 무선 단말은 DVB-T(Digital Video Broadcasting Terrestrial) 또는 WLAN(Wireless Local Area Network) 시스템 등을 구비한 UMTS(Universal Mobile Telecommunication Wywtem) 또는 CDMA 2000(Code Division Multiple Access 2000)과 같은 3세대 시스템(3G)으로 동작가능하게 하기 위하여 재구성될 수 있다. 본 명세서에 따르면, "시스템"이라는 용어는 기결정된 조건에 따라 그들 사이에서 조정되는 복수의 소자들을 의미한다. 즉, 예를 들면 통신 네트워크로서 동작하는 것과 같이 특정 기능을 수행하기 위하여 "표준"에 따라 조정되는 복수의 소자들을 의미하는 것이다.

상기 문서에서, 시스템들의 예는 GSM 시스템, GPRS 시스템, UMTS 시스템, WLAN 시스템 등이며, 각각은 해당 표준을 따른다.

단말 재구성을 수행하기 위하여, 상기 언급된 논문에 따르면, 단말의 작동 기능들이 재구성가능한 기술로 실현될 필요가 있다. 이점을 고려하여, 재구성가능한 단말 또는 장치들에는 예를 들면 복수의 FPGAs(Field Programmable Gate Arrays), DSPs(Digital Single Processors) 및 마이크로프로세서들로 구성된 재프로그램가능한 하드웨어가 제공될 필요가 있다. 장치의 기능은 심지어 가장 낮은 레벨에서도 소프트웨어 코드에 의해 수행된다. 결과적으로, 재프로그램가능한 장치를 재구성하기 위하여는 장치의 하드웨어를 관리하는 운영 소프트웨어를 교체하는 것으로 충분하다.

"운영 소프트웨어"라는 용어는 본 명세서에서 예를 들면 GSM/GPRS, UMTS 등과 같은 고려되는 시스템의 프로토콜 스택의 무선 인터페이스(예를 들어, L1, L2, L3) 및 상부 계층(예를 들면, L4에서 L7까지) 모두를 정의하는 라이브러리 내에 존 재하는 소프트웨어를 의미한다.

공지된 바와 같이, 통신 도메인에서, 기능 그룹핑(grouping)을 획득하기 위하여 가장 많이 채용되는 방법은 OSI(Open System Interconnection) 모델이다. 기능들을 스택 형태로 나타내는 기능 평면으로 그룹화된다.

프로토콜 스택의 각 계층은 바로 위 계층에 서비스들을 제공하고, 상기 서비스는 바로 아래 계층에 의해 제공된 서비스의 향상이다.

최하부 계층(계층 1)은 일반적으로 정보를 물리적으로 전송하기 위한 것이다.

OSI 사양에 따르면, 계층의 표준 개수는 7개이며, 각각 물리적 계층, 연결 계층, 네트워크 계층, 전송 계층, 세션 계층, 프리젠테이션 계층 및 어플리케이션 계층이다.

예를 들어, GSM/GPRS, UMTS 등과 같은 각 시스템은 OSI 프로토콜 스택의 필요한 부분을 구현한다.

무선 단말을 고려할 때, 재구성가능한 하드웨어를 사용할 때 제공되는 이익들이 많지만, 하나의 이득이 명백히 직면되어 있다. 무선 단말은 단말이 위치되는 영역(워킹 영역)을 커버(cover)하는 시스템에 따라 재구성될 수 있다. 따라서, 만약 단말이 GSM/GPRS와 같은 2세대 시스템에 의해 커버되는 영역에서 사용된다면, 단말은 상기 시스템을 수신할 수 있도록 재구성될 수 있다. 그렇지 않고, 이 영역이 UMTS와 같은 3세대 시스템에 의해 커버된다면, 단말은 그에 따라 구성될 수 있다.

소프트웨어 코드가 적어도 다음의 세 개의 다른 방식으로 즉 무선 이동 단말 내부에 삽입될 SIM(Subscriber Identity Module)을 사용하는 것에 의한 스마트 카드를 통하거나; 예를 들면 적외선/시리얼/USB(Universal Serial Bus) 포트를 통하여 개인 컴퓨터와의 링크를 사용하는 것에 의한 외부 연결을 통하거나; 특정 무선 채널을 사용하는 것에 의한 무선 또는 OTA(Over-the-air)를 통하여 단말에 전송되거나 다운로드될 수 있음이 논문(AA. VV.의 "Software Radio: The Challenges for Reconfigurable Terminals", Annals of telecommunication-Jul/Aug 2002, GET Hermes 및 E. Buracchini의 "The Software Radio Concept")으로부터 공지된다.

소프트웨어 다운로딩에 관하여, 단말로의 소프트웨어 다운로딩을 관리하게 하는 일반적인 프로토콜의 기본 단계들은 소프트웨어 URL www.sdrforum.org를 통하여 접근할 수 있는 무선 포럼의 프레임워크(framework)에서 정의되어 있다.

SDPF에 의해 정의된 바와 같이 프로토콜은 공지된 클라이언트-서버 타입이다.

다운로딩 프로토콜 단계들은 다음과 같다:

- 다운로드 초기화: 이 단계 동안 단말은 소프트웨어 다운로드를 시작하기 위하여 다운로드될 소프트웨어가 존재하는 서버와 통신한다;

- 상호 인증: 단말과 서버가 서로 인증해야만 한다;

- 능력 교환: 서버는 다운로드될 소프트웨어와 관련된 능력 정보를 통신하고, 단말은 그 소프트웨어가 단말 메모리에 로드되어 거기에 설치되고 실행될 수 있는지 여부를 확인한다;

- 다운로드 수용: 서버는 다운로딩, 설치 및 과금 옵션들을 단말로 통신하고, 단말은 서버에 의해 제공된 지시가 수용가능한지 여부를 결정한다;

- 다운로드 및 무결성 테스트: 소프트웨어 다운로드 동안, 수신된 코드가 테스트되고, 단말은 잘못 수신된 무선 블록들의 재전송을 요청한다;

- 설치: 설치 단계에서, 소프트웨어 과금 및 라이센싱 조건이 서버에 의해 제공된다;

- 제 위치 테스트: 소프트웨어 시작 전, 단말은 소프트웨어 코드와 함께 다운로드된 테스트 벡터들로 몇몇 테스트들을 수행한다;

- 거절 없음 교환: 인단 소프트웨어 코드가 설치되고 테스트되면, 단말은 과금 과정을 시작하기 위하여 설치가 성공적임을 서버에 확인해 준다.

무선 또는 OTA를 통한 소프트웨어 코드의 다운로딩은 무선 채널의 단말의 사용을 예견함이 종래 기술, 예를 들면 E. Buracchini의 "The Software Radio Concept", IEEE Communication Magazine, September 2000으로부터 공지되어 있다. 상술한 논문에 따르면, 소프트웨어 코드를 무선 채널의 타이폴로지(typology)에 따라 두 개의 다른 방식으로 다운로드하는 것이 공지된다:

- "대역 외(out of band)" 방식: 현재 시스템과 독립적인 "범용" 채널에 의해, 단말이 켜질 때, 자동으로 상기 채널을 튜닝하고 워킹 영역에서 동작하는 시스템과 관련된 운영 소프트웨어의 다운로드를 수행한다;

- "대역 내(in band)" 방식: 각각 GSM/GPRS 및 UMTS와 같은 2세대 및 3세대의 표준 셀룰러 시스템의 무선 채널을 사용하는 것에 의하여, 이 방식은, 이 채널 들 중 하나에서 이미 동작하고 있는 단말이 현재 사용되는 것과 다른 시스템에 관한 운영 소프트웨어를 수신할 수 있게 한다. 예를 들면, GSM/GPRS과 같은 2세대 시스템으로 동작하는 재구성가능한 단말은 그에 따라 동작 중인 2세대 무선 채널을 사용하는 것에 의하여 UMTS와 같은 3세대 시스템의 다운로드를 수행할 수 있다.

"대역 외" 소프트웨어 다운로드의 예는 예를 들면, 일본특허출원 No. 2001061186에 개시되어 있다. 이 문서는 OTA 방식으로 소프트웨어 컨텐츠를 다운로드하는 시스템 및 방법을 개시한다. 무선 단말이 켜졌을 때, 그것은 동작 영역 내의 현재 시스템이 무엇인지를 범용 채널 상에서 검색하여 지시된 시스템에 대한 소프트웨어 다운로드를 수행한다.

"대역 외" 모드에 대하여, 종래 기술에 따르면, 전용 무선 채널을 구현할 필요가 있고 따라서 구현을 위하여 네트워크 내에 전용 장치들을 구현할 필요가 있다.

"대역 내" 소프트웨어 다운로드의 예는 예를 들면 미국특허출원 No. 2003/0163551에 개시되어 있다. 이 문서는 서버와 단말 사이의 협상 단계 동안(능력 교환, 인증, 과금 등) 전용 채널들을 사용하는 것에 의하여, 그리고 사용가능한 무선 자원에 장애를 주지 부과하지 않고 동시에 가능한 많은 사용자에게 다운로드 서비스를 제공하기 위하여 다운로드 과정 동안 공유되는 공통 채널들을 사용하는 것에 의하여 OTA 방식으로 소프트웨어를 다운로드하는 시스템을 개시하고 있다.

"대역 내" 다운로드 방식을 고려하면, AA. VV.의 "Architecture Of IP Based Network Elements Supporting Reconfigurable Terminals", SCOUT Workshop, 16 September 2003, 및 IST-2001-34091 SCOUT, D4.1.1 "Requirements on network and security architecture and traffic management schemes for download traffic based on IP principles in cellular and ad hoc network"는 몇몇 프로토콜 및 예를 들면 무선 접속 노드 및/또는 UMTS의 해제 5 및 다음에 근거하여 코어 네트워크(Core Networks) 노드들과 같은 몇몇 네트워크 노드들을 완전히 변경시킬 것을 제안하고, 여기서 코어 네트워크는 운영 소프트웨어의 다운로드를 관리할 수 있게 하기 위하여 IP(인터넷 프로토콜)에 완전히 근거한다.

그러한 변경은 네트워크 운영자 및 장치 제조자에게 상당한 효과를 수반하며, 기존 셀룰러 시스템의 표준들에 극적인 영향을 준다.

따라서, 공지된 "대역 내" 기술은 이미 존재하는 셀룰러 네트워크에 추가되기를 원하는 경우, 재구성가능한 단말들에 대한 운영 소프트웨어 다운로드 관리, 프로토콜 및 네트워크 노드들에 대한 엄청난 변경이 필요하다는 제한을 나타낸다.

출원인은 공지된 종래 기술이 "대역 내" 방식 및 "대역 외" 방식 모두에 몇몇 프로토콜들 및 몇몇 네트워크 노드들의 큰 변경을 제공한다는 사실을 언급한다.

공지된 종래 기술의 다른 문제는 현재 표준에 따라 다음과 같이 정의된 시스템간 핸드-오버(inter-system hand-over) 관리이다:

- GSM/GPRS 시스템으로부터 UMTS 시스템으로의 핸드-오버;

- UMTS 시스템으로부터 CDMA 2000 시스템으로의 핸드-오버;

- UMTS 시스템으로부터 GSM/GPRS 시스템으로의 핸드-오버;

- CDMA 2000 시스템으로부터 UMTS 시스템으로의 핸드-오버.

공지된 표준에 따르면, 시스템간 핸드-오버는 다중모드 단말, 즉 ASIC(Application Specific Intergrated Circuit) 기술을 사용하는 것에 의하여 각 셀룰러 시스템의 전체 프로토콜 스택을 지원하는 단말을 요구한다.

예를 들면, RAT GSM/GPRS로 불리는 GSM/GPRS 시스템의 전체 무선 프로토콜 스택, RAT UMTS로 불리는 UMTS 시스템의 전체 무선 프로토콜 스택, 및 RAT CDMA 2000으로 불리는 CDMA 2000 시스템의 전체 무선 프로토콜 스택을 포함하는 다중모드 단말을 나타내는 도 1을 참조하라.

공지된 솔루션은 높은 전력 소모, 큰 장치 큭, 및 높은 구현 비용과 같은 몇 가지 단점들을 갖는다.

요약하면, 출원인은 공지된 종래 기술이 다음과 같음을 언급한다.

- 표준에 의해 정의된 데이터 시그널링(signalling) 및 전송 프로토콜을 변경하기 위하여, 네트워크 노드의 큰 변경 없이, 즉 새로운 노드들 및 인터페이스의 추가 없이 소프트웨어를 다운로드하는 문제를 해결하지 못하며, 이것은 무선 자원의 비효율적인 사용을 수반할 수 있다;

- 시스템간 핸드-오버를 관리하기 위하여 재구성가능한 단말들을 사용할 수 없다.

따라서 본 발명의 목적은 네트워크 노드들 및 관련 프로토콜들의 큰 변경 없이 무선 단말을 구성하기 위한 운영 소프트웨어 다운로드 방법 및 이를 위한 통신 네트워크를 제공하고자 하는 것이다.

또한, 본 발명의 다른 목적은 구성가능한 단말들을 사용하는 것에 의하여 시스템간 핸드-오버 과정을 가능하게 하기 위한 방법 및 이를 위한 통신 네트워크를 제공하고자 하는 것이다.

상술한 목적들은 여기에 첨부된 청구범위에 청구된 방법 및 통신 네트워크를 통하여 달성된다.

또한 본 발명의 목적들은 적어도 하나의 컴퓨터 메모리에 로딩될 수 있으며, 제품이 청구된 컴퓨터 상에서 동작할 때 본 발명의 방법의 단계들을 수행하기 위한 소프트웨어 코드 부분을 포함하는 컴퓨터 프로그램 제품 및 컴퓨터 프로그램 제품들의 세트를 통하여 달성될 수 있다. 여기에 사용된 바와 같이 그러한 컴퓨터 프로그램 제품에 대한 인용은 본 발명의 방법의 수행을 조정하기 위하여 컴퓨터 시스템을 조정하는 명령어들을 포함하는 컴퓨터 판독가능 매체에 대한 인용과 동일한 것으로 의도된다. "적어도 하나의 컴퓨터"에 대한 언급은 본 발명이 분산 모듈 방식으로 구현될 수 있음을 강조하고자 하는 것이다.

바람직한 실시예에서, 무선 단말을 재구성하기 위한 운영 소프트웨어의 다운로드는 단말 및 예를 들어 네트워크의 BSC(Base Station Controller) 또는 RNC(Radio Network Controller)와 같은 무선 제어기 내와 같이 표준에 대한 네트워크의 적어도 하나의 노드 내의 무선 프로토콜 스택의 단지 하나의 계층만을 변경시키는 것에 의하여 달성될 수 있다.

본 발명에 따르면, 변경된 계층의 프로토콜은 SDR 포럼에 의해 제공된 추천에 따른다.

본 발명의 바람직한 실시예에 따르면, 동작 소프트웨어를 다운로드할 수 있는 서버는 예를 들어 네트워크의 BSC 또는 RNC와 같은 무선 제어기 내에 존재한다.

본 발명의 가능한 이점들 중에는:

- 소프트웨어 다운로드 서비스가 투명하고 임의의 다른 시그널링 및 트래픽 데이터 흐름으로 네트워크에 의해 관측된다;

- 기존 또는 미래의 표준에 대한 모든 특징들이 완전히 이용되고, 그에 의하여 무선 자원의 효율적이고 유연한 사용을 가능하게 한다;

- 서로 다른 데이터 흐름 사이에서 그들(음성, 데이터 및 소프트웨어 다운로드)의 우선권을 구별하고 관리할 수 있다; 예를 들면, 음성 호출의 우선권이 소프트웨어 다운로드의 우선권보다 크다면, 상기 다운로드를 성공적으로 재시작하기 위하여 소프트웨어 다운로드를 임시적으로 멈출 수 있다.

게다가, 본 발명은 시스템간 핸드-오버를 관리하기 위한 재구성가능한 단말들의 사용을 제공한다.

실제로, 본 발명의 바람직한 실시예에 따르면, 지원되는 시스템들 상에서 측정을 수행하기 위한 최소의 기능들만이 단말의 물리적 계층에서 구현되는 것이 충분하다.

예를 들여, GSM/GPRS 시스템으로 동작하도록 설계되고 UMTS 시스템으로 시스템간 핸드-오버를 관리하기 위하여 준비된 단말을 고려해 보자. 본 발명에 따르면, GSM/GPRS 시스템의 무선 인터페이스의 전체 프로토콜 스택으로 설계된 단말에는 UMTS 시스템 상의 전력 특정을 수행하기 위하여 단지 최소 물리적 계층 기능만이 제공된다.

시스템간 핸드-오버는 GSM/GPRS 무선 채널을 통하여 단말로 전체 UMTS 동작 소프트웨어를 다운로딩하고 UMTS 시스템에 따라 단말을 재구성하며, GSM/GPRS 시스템 상의 전력 측정을 수행하기 위하여 최소 물리적 계층 기능들을 제공하는 것에 의하여 관리된다.

도 1은 종래기술에 따른 다중모드 단말을 나타낸다.

도 2는 본 발명의 일 실시예에 따른 GSM/GPRS 시스템의 네트워크 구조를 도시한다.

도 3은 도 1의 구조에 대한 재구성가능한 네트워크 단말을 나타낸다.

도 4는 무선 단말 측에서 클라이언트에 의해 수행되는 프로토콜 단계들의 상태도이다.

도 5는 기지국 제어기 측에서 서버에 의해 수행되는 프로토콜 단계들의 상태도이다.

도 6 내지 도 17은 서비와 클라이언트 사이에서 교환되는 프로토콜 메시지의 구조를 도시한다.

도 18은 회로 호출을 위하여 GSM부터 UMTS로의 시스템간 핸드-오버 과정을 도시한다.

도 19는 무선 단말을 재구성하기 위한 소프트웨어 다운로드 과정을 상세히 도시한다.

도 20은 셀(cell) 재선택의 경우 운영 소프트웨어의 다운로드 과정을 도시한다.

도면 전체에서 동일한 참조부호는 동일하거나 실질적으로 균등한 기능을 구현하는 구성요소들을 가리키기 위하여 사용되고 있다.

도 2를 참조하여, 재구성가능한 단말 또는 이동국(MS), 송수신 기지국(BTS) 또는 BTS 노드, 및 기지국 제어기(BSC) 또는 BSC 노드를 포함하는 GSM/GPRS 시스템의 네트워크 구조가 도시된다.

네트워크는 도 2에 도시되지 않은 예를 들면, 이동 교환국(Mobile Switching Centers; MSC) 및/또는 서비스 중인 GPRS 지원 노드(Serving GPRS Support Nodes; SGSN) 및/또는 게이트웨이 GPRS 지원 노드(Gateway GPRS Support Nodes; GGSN)와 같은 코어 네트워크 노드들을 더 포함한다.

단말(MS)은 무선 인터페이스를 통하여 BSC 노드가 연결된 BTS 노드에 연결된다.

본 발명의 바람직한 실시예에 따르면, 단말(MS)은 OTA 클라이언트로 불리는 제1 엔터티(entity) 및 무선 자원 프로토콜(RR)로 불리는 공지된 타입의 제2 엔터티를 포함하고, OTA 클라이언트는 무선 자원 프로토콜(RR)과 동일한 프로토콜 레벨 또는 계층에 있으며, 무선 자원 프로토콜(RR)과 함께 동작한다.

RR 엔터티는 예를 들면, GSM/GPRS 표준 ETSI 04.18에 따라 동작하며, 기지국 제어기(BSC) 내의 RR 대응 엔터티 및 OTA 클라이언트와 통신하기 위하여 이하에서 개시될 기능들을 포함한다.

OTA 클라이언트는 OTA 서버로 불리는 기지국 제어기(BSC) 내의 OTA 대응 엔터티로부터 완전한 운영 소프트웨어 또는 그것의 일부의 다운로드 과정을 완전히 관리할 수 있는 소프트웨어 모듈을 포함한다.

BSC는 OTA 서버로 불리는 제1 엔터티 및 무선 자원 프로토콜(RR)로 불리는 공지된 타입의 제2 엔터티를 포함한다.

OTA 서버는 무선 자원 프로토콜(RR)과 동일한 프로토콜 레벨에서 무선 자원 프로토콜(RR)과 함께 동작한다.

RR 엔터티는 예를 들면, GSM/GPRS 표준 ETSI 04.18에 따라 동작하며, 이동국(MS) 내의 RR 대응 엔터티 및 OTA 서버와 통신하기 위하여 이하에서 개시될 기능들을 포함한다.

OTA 서버는 OTA 클라이언트로 완전한 운영 소프트웨어 또는 그것의 일부의 다운로드 과정을 완전히 관리할 수 있는 소프트웨어 모듈을 포함한다.

OTA 서버는 운영 소프트웨어를 더 포함하거나 그것을 복구할 수 있다.

OTA 서버의 구조는 이하에서 설명될 바와 같이 활성 다운로드 세션을 갖는 각 OTA 클라이언트에 대하여 클라이언트-콘텍스트(Client-Context)로 불리는 콘텍스트를 제공한다.

도 3은 본 발명에 따라 구성된 단말(MS)의 예를 도시한다.

단말(MS)은 GSM/GPRS 프로토콜의 상부 계층 및 하부 계층을 포함한다.

하부 계층들은 RAT(Radio Access Technology) GSM/GPRS로 언급되며 GSM/GPRS 표준에 따른 OTA 클라이언트, 무선 자원(RR) 및 물리 계층(L1) 및 DL(Data Link)(L2)를 포함한다.

단말(MS)은 예를 들면 다른 표준에 따른 수행 계층(10) 측정을 위한 적어도 하나의 기능을 포함하는 UMTS 표준과 같이 다른 표준에 따른 물리 계층(L1U)을 포함한다.

개시된 단말(MS)은 나중에 설명될 바와 같이 다른 표준의 운영 소프트웨어를 다운로드하는 것에 의하여 구성될 수 있다.

본 발명의 바람직한 실시예에서 고려되는 바와 같이, 운영 소프트웨어는 운영 소프트웨어 모듈들의 세트, 바람직하게는 기결정된 통신 시스템에 따른 단말(MS)을 구성하기 위한 복수의 소프트웨어 모듈들을 포함한다.

본 발명은 예를 들면 다른 기결정된 통신 시스템에 따른 무선 단말(MS)을 구성하기 위하여 채용된 프로토콜 스택을 구성하는 모든 운영 소프트웨어 모듈들의 다운로딩을 제공한다.

당업자에게 자명한 바와 같이 본 발명의 다른 실시예들에 따르면, 사용 중인 통신 시스템 및 다른 통신 시스템에 대응하는 프로토콜 스택의 단지 일부만을 구성하는 소프트웨어 모듈을 다운로드하는 것 또한 가능하다.

그러한 다른 실시예들은 예를 들면, 단말(MS)에 새로운 기능을 추가하거나 업데이트 또는 버그 치료 목적에 유용할 수 있다.

도 4를 참조하면, 단말(MS) 내에 OTA-클라이언트의 상태도가 나타난다.

상태들을 명명하기 위하여 사용되는 용어들은, 설명된 바와 같은 대응 행동 들을 나타내는 것으로 단지 지시를 위한 것이다.

본 발명의 바람직한 실시예에 따르면, OTA 클라이언트의 상태들 및 상대적 변화는 다음과 같다:

- IDEL 상태: OTA 클라이언트가 어떤 소프트웨어 다운로드 과정도 활성화되지 않을 때의 상태에 있을 때이다. OTA 클라이언트는 과정이 바르게 종료되거나 오류가 발생한 경우 이 상태로 돌아간다;

- DOWNLOAD INITIATION 상태: 네트워크가 운영 소프트웨어의 다운로드 과정의 시작을 요구할 때, OTA 클라언트는 이 상태로 들어가서 타이머 T100을 시작할 수 있다; 타이머(T100)는 상태 변화의 경우 종료된다; 만약 타이머(T100)가 상태 변화 전에 만료되었다면, OTA 클라이언트는 IDEL 상태로 돌아간다;

- MUTUAL AUTHENTICATION 상태: 이 상태에서 OTA 클라이언트는 OTA 서버와의 상호 인증을 수행한다; OTA 클라이언트는 인증 요구가 OTA 서버로부터 온 경우 이 상태로 진입한다; OTA 클라이언트는 타이머 T200을 시작한다; 타이머(T200)는 상태 변화의 경우 종료된다; 만약 타이머(T200)가 상태 변화 전에 만료되거나 인증이 실패한 경우, OTA 클라이언트는 IDEL 상태로 돌아간다;

- CAPABILITY REQEUST 상태: 이 상태에서 OTA 클라이언트는 OTA 서버로 그것의 능력을 제공한다; OTA 클라이언트는 OTA 서버가 그것의 능력을 요청한 경우 이 상태로 진입한다; OTA 클라이언트는 타이머 T300을 시작한다; 타이머(T300)는 상태 변화의 경우에 종료된다; 만약 타이머(T300)가 상태 변화 전에 만료된다면, OTA 클라이언트는 IDEL 상태로 돌아간다;

- DOWNLOAD ACCEPTANCE 상태: 이 상태에서 OTA 클라이언트는 OTA 서버에 의해 수신된 정보에 따라 다운로드를 계속할지 여부를 결정한다; OTA 클라이언트는 OTA 서버로부터 수행될 다운로드 프로파일을 수신한 경우 이 상태로 진입한다; 만약 수신된 프로파일이 거절된다면, OTA 클라이언트는 IDEL 상태로 돌아간다;

- SOFTWARE DOWNLOAD 상태; 이 상태에서 OTA 클라이언트는 소프트웨어 다운로드를 시작한다; OTA 클라이언트는 다운로드 프로파일이 받아들여진다면 이 상태로 진입한다; OTA 클라이언트는 타이머 T400을 시작한다; 이 타이머(T400)는 OTA 서버로부터 수신된 각 소프트웨어 블록에서 리셋되고 재시작된다; 타이머(T400)는 상태 변화의 경우 종료된다; 만약 타이머(T400)가 상태 변화 전에 만료되거나, 다운로드가 실패하거나, 다운로드 소프트웨어가 능력에 맞지 않다면, OTA 클라이언트는 IDEL 상태로 돌아간다;

- INSTALLATION 상태: 이 상태에서 OTA 클라이언트는 OTA 서버로 라이센스에 대한 요청을 전송하고 운영 소프트웨어를 설치한다; OTA 클라이언트는 다운로드 끝에서 이 상태에 진입한다; OTA 클라이언트는 타이머 T500을 시작한다; 타이머(T500)는 상태 변화의 경우 종료된다; 만약 타이머(T500)가 상태 변경 전에 종료되거나 라이센스가 받아들여지지 않는다면, OTA 클라이언트는 IDEL 상태로 돌아간다;

- IN SITU TESTING 상태: 이 상태에서 OTA 클라이언트는 OTA 서버로부터 수신된 몇몇 테스트 벡터들을 사용하여 다운로드된 소프트웨어 상에서 몇몇 테스트를 수행한다; OTA 클라이언트는 운영 소프트웨어가 설치된 경우 이 상태로 진입한다; 테스트들이 종료되면, OTA 클라이언트는 IDEL 상태로 돌아간다.

도 5를 참조하여, OTA 서버에 의해 관리되는 클라이언트-콘텍스트의 상태도가 도시된다.

상술한 바와 같이, 상태들을 명명하기 위하여 사용되는 용어는 설명된 바와 같은 대응 행동들을 나타내는 것으로 단지 지시를 위한 것이다.

클라이언트-콘텍스트의 상태들 및 상대적 변화는 다음과 같다:

- IDEL 상태: OTA 서버에 의해 관리되는 OTA 클라이언트 콘텍스트가 어떠한 소프트웨어 다운로드 과정도 활성화되지 않는 상태에 있는 경우이다; OTA 클라이언트 콘텍스트는 과정이 바르게 종료되거나 오류가 발생한 경우 이 상태로 돌아간다;

- DOWNLOAD INITIATION 상태: 이 상태에서 OTA 클라이언트 콘텍스트는 다운로드를 수행하기 위하여 OTA 클라이언트를 트리거링(triggering)한다; 운영 소프트웨어 다운로드를 수행하는 것이 필요한 경우, OTA 클라이언트 콘텍스트는 이 상태로 진입하고 타이머 T101을 시작한다; 타이머(T101)는 상태 변화의 경우 종료된다; 만약 타이머(T101)가 상태 변화 전에 만료되었다면, OTA 클라이언트 콘텍스트는 IDEL 상태로 돌아간다;

- MUTUAL AUTHENTICATION 상태: 이 상태에서 OTA 클라이언트-콘텍스트는 자신을 인증하고 OTA 클라이언트에게 자신을 식별할 것을 요청한다; OTA 클라이언트 콘텍스트는 OTA 클라이언트로부터 다운로드 확인을 수신한 경우 이 상태로 진입한다; OTA 클라이언트 콘텍스트는 타이머 T201을 시작한다; 타이머(T201)는 상태 변화의 경우 종료된다; 만약 타이머(T201)가 상태 변화 전에 만료되거나 인증이 실패 한 경우, OTA 클라이언트 콘텍스트는 IDEL 상태로 돌아간다;

- CAPABILITY REQEUST 상태: 이 상태에서 OTA 클라이언트 콘텍스트는 OTA 클라이언트에 그것의 능력을 요청한다; OTA 클라이언트 콘텍스트는 인증이 완료된 경우 이 상태로 진입한다; OTA 클라이언트 콘텍스트는 타이머 T301을 시작한다; 타이머(T301)는 상태 변화의 경우에 종료된다; 만약 타이머(T301)가 상태 변화 전에 만료되거나 능력이 다운로드를 허용하지 않는다면, OTA 클라이언트 콘텍스트는 IDEL 상태로 돌아간다;

- DOWNLOAD ACCEPTANCE 상태: 이 상태에서 OTA 클라이언트 콘텍스트는 OTA 클라이언트로 다운로드 프로파일을 통신한다; OTA 클라이언트 콘텍스트는 단말 능력이 수신되고 그 단말 능력이 받아들여진 경우 이 상태로 진입한다; OTA 클라이언트 콘텍스트는 타이머 T302를 시작한다; 타이머(T302)는 상태 변화의 경우 종료된다; 만약 타이머(T302)가 상태 변화 전에 만료되거나 OTA 클라이언트가 제안된 다운로드를 거절한다면, OTA 클라이언트 콘텍스트는 IDEL 상태로 돌아간다;

- SOFTWARE DOWNLOAD 상태; 이 상태에서 OTA 클라이언트 콘텍스트는 OTA 클라이언트를 향하여 소프트웨어 다운로드를 수행한다; OTA 클라이언트 콘텍스트는 다운로드 프로파일이 OTA 클라이언트에 의해 받아들여진다면 이 상태로 진입한다; OTA 클라이언트 콘텍스트는 타이머 T401을 시작한다; 이 타이머(T401)는 OTA 클라이언트로부터 수신된 각 확인 신호(Ack)에서 리셋되고 재시작된다; 타이머(T401)는 상태 변화의 경우 종료된다; 만약 타이머(T401)가 상태 변화 전에 만료되거나 다운로드가 실패한다면, OTA 클라이언트는 IDEL 상태로 돌아간다;

- INSTALLATION 상태: 이 상태에서 OTA 클라이언트 콘텍스트는 OTA 클라이언트로 라이센스 기간을 통신하고 OTA 클라이언트가 설치 및 다운로드된 소프트웨어으 테스트를 수행할 때까지 기다린다; OTA 클라이언트 콘텍스트는 다운로드가 종료되면 이 상태에 진입한다; OTA 클라이언트 콘텍스트는 타이머 T501을 시작한다; 타이머(T501)는 상태 변화의 경우 종료된다; 만약 타이머(T501)가 상태 변경 전에 종료되거나 라이센스가 OTA 클라이언트에 의해 받아들여지지 않는다면, OTA 클라이언트는 IDEL 상태로 돌아간다; 만약 OTA 클라이언트 콘텍스트가 OTA 클라이언트에 의해 성공적인 설치에 대한 확인 신호를 수신한다면, IDEL 상태로 돌아간다.

GSM/GPRS의 경우, 본 발명의 바람직한 실시예에서, RR 프로토콜은 도 6 내지 17을 참조하여 상세히 설명될 OTA 서버와 OTA 클라이언트 사이에서 교환된 관련 필드들 및 새로운 프로토콜 메시지들을 도입하는 것에 의하여 변경된다.

다른 시스템들에서, 예를 들면, UMTS 시스템에서 RRC(Radio Resource Control)과 같은 무선 자원 프로토콜은 당업자에게 자명한 바와 같이 유사한 방식으로 변경된다.

이하에서, 메시지들 및 관련 필드들을 명명하기 위하여 사용되는 용어는 설명된 바와 같은 대응 행동들을 나타내는 것으로 단지 지시를 위한 것이다.

도 6을 참조하여, Packet Download Request 메시지의 구조가 설명된다. 이 메시지는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다. 이 메시지를 사용하여, OTA 서버는 OTA 클라이언트가 다운로드 세션을 시작하도록 명령한다.

GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Download Request)을 식별한다;

- OTA-Client_ID; 요청이 수행되는 OTA 클라이언트를 식별한다;

- PDCH(Packet Data Channel); 네트워크에 의해 할당된 소프트웨어 다운로드가 수행될 채널들을 특정한다;

- RRBP(Relative Reserved Black Period): 표준 GPRS에서 이미 정의된 바와 같이 단말(MS) 측에서 무선 자원(RR)이 응답해야할 무선 블록을 특정한다;

- Requested Download; 이 요소는 네트워크에 의한 요청된 다운로드의 설명 문자열 및 숫자 식별자를 포함한다.

도 7을 참조하여, Packet Download Ack 메세지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버로 다운로드 세션이 시작되었다는 확인을 통신한다.

- Message_Type: 전송된 메시지 타입(Packet Download Ack)을 식별한다;

- OTA-Client_ID; 이 메시지를 전송하는 OTA 클라이언트를 식별한다;

- OTA-Client_Challenge_Number; 상호 인증의 제1 단계를 수행하기 위하여, OTA 서버가 자신의 키 및 예를 들면 AES(Advanced Encryption Standard) 알고리즘과 같은 적절한 암호화 알고리즘으로 암호화할 무작위 수이다.

도 8을 참조하여, Packet Download Nack 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버로 다운로드 세션이 시작될 수 없음을 통신한다.

- Message_Type: 전송된 메시지 타입(Packet Download Nack)을 식별한다;

- OTA-Client_ID; 이 메시지를 전송하는 OTA 클라이언트를 식별한다.

도 9를 참조하여, Packet Authentication Request 메시지의 구조가 설명된다. 이 메시지는 OTA 서버로부터 OTA 클라이언트로 전송된다. 이 메시지를 사요하여 OTA 서버는 OTA 클라이언트로 자신의 자격(credentials)을 통신하고, OTA 클라이언트가 자신을 식별할 것을 요청한다. GSM/GPRS의 겨우 제공된 이 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Authentication Request)을 식별한다;

- OTA-Client_ID; 이 메시지가 전송된 OTA 클라이언트를 식별한다;

- OTA-Server_Response_Number: OTA 서버에 의해 자신의 키 및 예를 들면 AES 알고리즘과 같이 적절한 암화화 알고리즘으로 암호화된, 상호 인증의 제1 단계를 완결하는 수이다;

- OTA-Server_Challenge_Number; 상호 인증의 제2 단계를 수행하기 위하여, OTA 클라이언트가 자신의 키 및 예를 들면 AES 알고리즘과 같은 적절한 암호화 알 고리즘으로 암호화할 무작위 수이다;

- RRBP: 표준 GPRS에서 이미 정의된 바와 같이 단말(MS) 측의 무선 자원(RR)이 응답해야할 무선 블록을 특정한다;

도 10을 참조하여, Packet Authentication Response 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버로 OTA 서버를 이미 인증하고 있는 자신의 자격을 통신한다: GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Authentication Response)을 식별한다;

- OTA-Client_Response_Number: OTA 클라이언트에 의해 자신의 키 및 예를 들면 AES 알고리즘과 같이 적절한 암화화 알고리즘으로 암호화된, 상호 인증의 제2 단계 및 마지막 단계를 완결하는 수이다;

도 11을 참조하여, Packet Capability Request 메시지의 구조가 설명된다. 이 메시지는 OTA 서버로부터 OTA 클라이언트로 전송된다. 이 메시지를 사용하여 OTA 서버는 OTA 클라이언트로 자신의 변형가능한 옵션들을 요청한다. GSM/GPRS의 경우에 제공된 이 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Capability Request)을 식별한다;

도 12를 참조하여, Packet Capability Response 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버로 자신의 변형가능한 옵션들에 대하여 알려준다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Capability Response)을 식별한다;

- OTA-Client_Capability: 단말의 변형가능 옵션들을 설명한다.

도 13을 참조하여, Packet Download Description 메시지의 구조가 설명된다. 이 메시지는 OTA 서버로부터 OTA 클라이언트로 전송된다. 이 메시지를 사용하여 OTA 서버는 OTA 클라이언트로 다운로드와 관련된 정보를 보고한다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Download Description)을 식별한다;

- Downloads_list: OTA 클라이언트에 의해 선택된 각 다운로드에 대한 하나의 요소를 포함하며, 이 필드는 다음과 같은 필드들을 포함한다:

- Download_Block_Number: 운영 소프트웨어가 OTA 클라이언트로 전송되기 전에 분할될 무선 블록들의 수이다.

- Billing_criteria: 가능한 다운로드 과금에 관한 조건이다;

- Installation_criteria: 소프트웨어 설치에 관한 조건이다.

도 8을 다시 참조하여, Packet Download Accept 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 다운로드를 확인한다.

- Message_Type: 전송된 메시지 타입(Packet Download Accept)을 식별한다;

도 8을 다시 참조하여, Packet Download Reject 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 다운로드를 거절한다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Download Reject)을 식별한다;

도 8을 다시 참조하여, Packet License Request 메시지의 구조가 설명된다. 이 메시지는 OTA 서버로부터 OTA 클라이언트로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버로 다운로드된 운영 소프트웨어를 복호화하여 그것을 설치하기 위한 키를 요청한다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet License Request)을 식별한다;

도 14를 참조하여, Packet License Response 메시지의 구조가 설명된다. 이 메시지는 OTA 서버로부터 OTA 클라이언트로 전송된다. 이 메시지를 사용하여 OTA 서버는 OTA 클라이언트와 다운로드된 운영 소프트웨어를 복호화하고 설치하기 위한 키를 통신한다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet License Response)을 식별한다;

- Decrypt_key: 운영 소프트웨어를 복호화하기 위하여 사용되는 키이다.

도 8을 다시 참조하여, Packet License Accept 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버에게 다운로드된 운영 소프트웨어가 정확하게 복호화되었음을 알려준다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet License Accept)을 식별한다;

도 8을 다시 참조하면, Packet License Failed 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버에게 다운로드된 운영 소프트웨어가 정확하게 복호화되지 않았음을 알려준다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet License Failed)을 식별한다;

도 15를 참조하면, Packet Test Description 메시지의 구조가 설명된다. 이 메시지는 OTA 서버로부터 OTA 클라이언트로 전송된다. 이 메시지를 사용하여 OTA 서버는 OTA 클라이언트에게 운영 소프트웨어 시작 전에 다운로드된 운영 소프트웨어 상에서 수행될 테스트를 가리킨다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Test Description)을 식별한다;

- OTA-Client_ID; 이 메시지가 전송되는 OTA 클라이언트를 식별한다;

- Test_list: 수행될 각 테스트에 대한 하나의 요소를 포함하고 다음으로 필드를 포함한다.

- Test_vector: 테스트 설명을 포함한다.

도 8을 다시 참조하여, Packet Installation Successful 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사 용하여 OTA 클라이언트는 OTA 서버에게 다운로드된 운영 소프트웨어의 테스트가 성공적임을 지시한다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Installation Successful)을 식별한다;

- OTA-Client_ID; 이 메시지를 전송한 OTA 클라이언트를 식별한다;

도 8을 다시 참조하여, Packet Installation Failed 메시지의 구조가 설명된다. 이 메시지는 OTA 클라이언트로부터 OTA 서버로 전송된다. 이 메시지를 사용하여 OTA 클라이언트는 OTA 서버로 다운로드된 운영 소프트웨어의 테스트가 성공적이지 못함을 알려준다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Packet Installation Failed)을 식별한다;

바람직한 실시예에서, 운영 소프트웨어는 OTA 서버로부터 OTA 클라이언트로 예를 들면 이후에 설명될 바와 같이 Block 및 Ack로 불리는 두 개의 기본 프로토콜 데이터 유닛들(Protocol Data Units) 또는 PDU들에 근거한, 공지된 타입의 윈도우를 사용하는 것에 의하여 전송된다.

도 16을 참조하여, 운영 소프트웨어가 분할된 무선 블록(Block)의 구조가 설명된다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함 한다:

- Message_Type: 블록 타입을 식별한다;

- Block_Number: 무선 블록의 순차적인 번호를 식별한다; 이 연속 번호는 OTA 클라이언트에 의하여 전체 운영 소프트웨어를 재조합하는데 사용된다;

- Data: 이것은 전체 운영 소프트웨어의 일부를 포함하는 필드이다.

도 17을 참조하여, 단말 수신 상태를 가리키는데 사용되는 Ack 메시지의 구조가 설명된다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- Message_Type: 전송된 메시지 타입(Ack)을 식별한다;

- Ack_Bitmap: 이것은 운영 소프트웨어가 분할된 무선 블록들의 전체 수와 같은 크기를 갖는 비트 마스크이다. 각 무선 블록에 대하여, 그것은 블록이 성공적으로 수신된 경우 "1"로 설정되고, 블록이 수신되었으나 손상되어 있거나, 전혀 수신되지 않은 경우 "0"으로 설정된다.

본 발명의 바람직한 실시예에 따른 RR 프로토콜의 변경은 단말(MS) 측의 OTA 클라이언트와 무선 자원(RR) 사이의 프리미티브(primitive) 도입과 기지국 제어기(BSC) 측에서 OTA 서버와 무선 자원(RR) 사이의 프리미티브 도입에 근거한다.

프리미티브를 명명하기 위하여 사용되고 필드들과 관련된 용어는 설명된 바와 같이 대응 정의를 의미하는 바와 같이 단지 지시를 위한 것이다.

먼저, OTA 클라이언트와 단말(MS) 측의 무선 자원(RR) 사이의 프리미티브가 설명된다.

Download Request Ind 프리미티브가 단말(MS) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

GSM/GPRS의 경우 제공된 필드는 적어도 다음과 같은 것들의 세트를 포함한다:

- OTA-Client_ID: 요청이 수행되는 OTA 클라이언트를 식별한다;

- Requested Download: 이 요소는 네트워크에 의해 요청된 다운로드의 설명 문자열 및 숫자 식별자를 포함한다.

Download Ack Ind 프리미티브는 OTA 클라이언트에 의해 단말(MS) 측의 무선 자원(RR)으로 전송된다. 이 프리미티브에서 제공된 필드는 다음과 같다:

- OTA-Client_ID: 이 프리미티브와 관련된 OTA 클라이언트를 식별하다;

- OTA-Client_Challenge_Number: 이것은 OTA 서버가 자신의 키 및 예를 들면 AES(Advanced Encryption Standard) 알고리즘과 같은 적절한 암호화 알고리즘으로 암호화할 무작위 수이다.

Download Nack Ind 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- OTA-Client_ID: 이 프리미티브와 관련된 OTA 클라이언트를 식별한다.

Authentication Req 프리미티브는 단말(MS) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

이 프리미티브에 제공된 필드들은 다음과 같다:

- OTA-Client_ID: 이 프리미티브와 관련된 OTA 클라이언트를 식별한다;

- OTA-Server_Response_Number: 상호 인증의 제1 단계를 수행하기 위하여, OTA 서버 자신의 키 및 예를 들면 AES(Advanced Encryption Standard) 알고리즘과 같은 적절한 암호화 알고리즘으로 OTA 서버에 의해 암호화된 수이다;

- OTA-Server_Challenge_Number: 상호 인증의 제2 단계를 수행하기 위하여, 클라이언트가 자신의 키 및 예를 들면 AES 알고리즘과 같은 적절한 암호화 알고리즘으로 암호화할 무작위 수이다.

Authentication Rsp 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

- OTA-Client_Response_Number: 상호 인증의 제1 단계를 수행하기 위하여, OTA 클라이언트 자신의 키 및 예를 들면 AES 알고리즘과 같은 적절한 암호화 알고리즘으로 OTA 클라이언트에 의해 암호화된 수이다;

Capability Req 프리미티브는 MS 측의 무선 자원(RR)로부터 OTA 클라이언트로 전송된다.

GSM/GPRS의 경우 전송된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

Capability Rep 프리미티브는 OTA 클라이언트로부터 MS 측의 무선 자원(RR)로 전송된다.

- OTA-Client_ID: 이이 메시지를 전송한 OTA 클라이언트를 식별한다;

- OTA-Client_Capability: 단말 재구성가능성 옵션들을 설명한다.

Download Description Req 프리미티브는 단말 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- Downloads_list: OTA 클라이언트에 의해 선택된 각 다운로드에 대하여 다음과 같은 필드들을 포함하는 하나의 요소들을 포함한다:

- Download_Block_Number는 OTA 클라이언트로 전송되기 전에 운영 소프트웨어가 분할될 무선 블록들의 수이다;

- Billing_criteria는 가능한 다운로드 과금에 관한 조건이다;

- Installation_criteria는 소프트웨어 설치에 관한 조건이다.

Download Accept Cnf 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한 다:

Download Accept Rej 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

License Req 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

License Rsp 프리미티브는 단말(MS) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

License Cnf 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

License Rej 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

Test Description Req 프리미티브는 단말(MS) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- Test_list: 수행될 각 테스트에 대한 하나의 요소를 포함하고 다음으로 필드를 포함한다:

- Test_vector: 테스트 설명을 포함한다.

Installation Cnf 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

Installation Rej는 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

Data Ind 프리미티브는 단말(MS) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- 운영 소프트웨어가 분할된 무선 블록들 중 하나.

Data Req 프리미티브는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원(RR)으로 전송된다.

- Ack의 무선 블록.

OTA 서버와 기지국 제어기(BSC) 측의 무선 자원(RR) 사이에 교환되는 프리미티브들이 이하에서 설명된다.

Download Initiation Ind 프리미티브는 OTA 클라이언트로부터 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다. GSM/GPRS의 경우 제공된 필드들은 적어도 다음과 같은 것들의 세트를 포함한다:

- OTA-Client_ID: 요청이 수행되는 OTA 클라이언트를 식별한다;

Download Ack Ind 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- OTA-Client_Challenge_Number: 상호 인증의 제1 단계를 수행하기 위하여, OTA 서버가 자신의 키 및 예를 들면 AES(Advanced Encryption Standard) 알고리즘과 같은 적절한 암호화 알고리즘으로 암호화할 무작위 수이다.

Download Nack Ind 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

Authentication Req 프리미티브는 OTA 클라이언트로부터 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다.

- OTA-Server_Response_Number: 상호 인증의 제1 단계를 포함하여, OTA 서버 자신의 키 및 예를 들면 AES 알고리즘과 같은 적절한 암호화 알고리즘으로 OTA 서버에 의해 암호화된 수이다;

- OTA-Server_Challenge_Number: 상호 인증의 제2 단계를 수행하기 위하여, OTA 클라이언트가 자신의 키 및 예를 들면 AES 알고리즘과 같은 적절한 암호화 알고리즘으로 암호화할 무작위 수이다.

Authentication Rsp 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- OTA-Client_Response_Number: 상호 인증의 제2 단계 및 마지막 단계를 완결하는, OTA 클라이언트 자신의 키 및 예를 들면 AES 알고리즘과 같은 적절한 암호화 알고리즘으로 OTA 클라이언트에 의해 암호화된 수이다.

Capability Req 프리미티브는 OTA 클라이언트로부터 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다.

Capability Rsp 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- OTA-Client_ID: 메시지를 전송하는 OTA 클라이언트를 식별한다;

- OTA-Client_Capability: 단말 재구성가능성 옵션들을 설명한다.

Download Description Req 프리미티브는 OTA 클라이언트로부터 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다.

- Download_list: OTA 클라이언트에 의해 선택된 각 다운로드에 대하여 이하의 필드를 포함하는 하나의 요소를 포함한다:

- Billing_criteria: 가능한 다운로드 과금에 관한 조건이다;

- Installation_criteria: 소프트웨어 설치에 관한 조건이다.

Download Accept Cnf 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

Download Accept Rej 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

License Req 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

License Rsp 프리미티브는 OTA 클라이언트에 의해 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다.

License Cnf 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

License Rej 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

Test Description Req 프리미티브는 OTA 서버로부터 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다.

- Test_list: 수행될 각 테스트를 위한 하나의 요소를 포함하고 다음 필드를 포함한다:

- Test_vector: 테스트 설명을 포함한다.

Installation Cnf 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로 부터 OTA 클라이언트로 전송된다.

Installation Rej 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

Data Req 프리미티브는 OTA 서버로부터 기지국 제어기(BSC) 측의 무선 자원(RR)으로 전송된다.

- 운영 소프트웨어가 분할된 무선 블록들 중 하나.

Data Ind 프리미티브는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 서버로 전송된다.

- Ack의 무선 블록.

도 4 및 5를 참조하면, 각각의 RR에 의해 수신된 각 프리미티브에 대하여 OTA 클라이언트 또는 클라이언트 콘텍스트의 상태에 따른 상대적인 행동을 가리키는 것에 의하여 OTA 클라이언트와 OTA 서버 사이의 절차적 상호작용들이 설명될 것이다.

OTA 클라이언트 및 OTA 서버의 행동은 시스템과 독립적이다.

OTA 클라이언트 또는 OTA 서버와 각각의 RR 사이에 교환되는 프리미티브는 시스템에 종속적이며, 본 발명의 예에 따르면, GSM/GPRS 시스템을 참조한다.

이하의 설명에서, 타이머들의 시작/종료 행동들은 이전에 설명된 바와 같이 그들이 엔터티들의 상태와 연결되기 때문에 설명되지 않는다.

도 4를 참조하여, OTA 클라이언트의 행동이 이제 설명된다.

일반적으로, OTA-Client_ID 필드가 프리미티브를 수신하는 OTA 클라이언트와 매칭되지 않으면, 그 프리미티브는 무시된다.

OTA 클라이언트가 Download Reqeust Ind 프리미티브를 수신할 때:

- 만약 상태가 IDEL이라면, OTA 클라이언트는 DOWNLOAD INITIATION으로 진행한다;

- 만약 상태가 DOWNLOAD INITIATION이 아니라면, 그 프리미티브는 무시되고 과정은 계속되지 않는다;

- 만약 단말이 그 다운로드를 수행할 수 있다면:

- 무작위 수 RNUM이 획득되고 저장되며;

- OTA-Client_Challenge_Number 필드 내에 획득된 수(RNUM)의 값을 포함하는 Download Ack Ind 프리미티브가 전송된다.

- 만약 단말이 그 다운로드를 수행할 수 없다면, 그 프리미티브는 무시되고 과정이 계속되지 않는다;

- 만약 저장된 무작위 수(RNUM)가 유효하지 않다면, 과정은 계속되지 않는다;

- OTA 클라이언트는 MUTUAL AUTHENTICATION 상태로 진행한다;

- 저장된 무작위 수(RNUM)의 값은 선택된 암호화 알고리즘, 예를 들면 AES 알고리즘을 사용하는 것에 의하여 내부 키(CIK)로 암호화된다;

- 이전 단계에서 암호화된 값이 OTA-Server_Response_Number 필드의 값과 매칭되지 않는다면, OTA 클라이언트는 IDEL 상태로 통과하고 과정은 계속되지 않는다;

- OTA-Server_Challenge_Number 필드의 값이 선택된 암호화 알고리즘, 예를 들면 AES 알고리즘을 사용하는 것에 의하여 내부 키(CIK; Clienti Identity Key)로 암호화된다;

- Authetication Rsp 프리미티브가 OTA-Client_Response_Number 필드 내에 이전 단계에서 암호화된 값으로 전송된다;

- 만약 상태가 MUTUAL AUTHENTICATION이 아니라면, 이 프리미티브는 무시되고 과정이 계속되는 않는다;

- OTA 클라이언트는 CAPABILITY REQUEST 상태로 진행한다;

- Capability Response 프리미티브가 전송된다.

OTA 클라이언트가 Download Description Req 프리미티브를 수신한 경우:

- 상태가 CAPABILITY REQUEST가 아니라면, 그 프리미티브는 무시되고 과정은 계속되지 않는다;

- OTA 클라이언트는 DOWNLOAD ACCEPTANCE 상태로 진행한다;

- 만약 단말이 소프트웨어를 설치할 수 있다면:

- Download Accept Cnf 프리미티브가 전송된다;

- 만약 단말이 소프트웨어를 설치할 수 없다면:

- Download Accept Rej 프리미티브가 전송되며;

- OTA 클라이언트는 IDEL 상태로 진행한다.

OTA 클라이언트가 License Rsp 프리미티브를 수신한 경우:

- 만약 상태가 INSTALLATION이 아니라면, 그 프리미티브는 무시되고 과정이 계속되지 않는다;

- 다운로드 소프트웨어는 Decrypt Key 필드에 나타난 키를 사용하여 암호화된다;

- 만약 암호화가 성공적이라면:

- License Cnf 프리미티브가 전송되며;

- 다운로드 운영 소프트웨어가 저장된다;

- 만약 암호화가 성공적이지 않다면:

- License Rej 프리미티브가 전송되며;

- 상기 과정은 IDEL 상태로 진행한다.

OTA 클라이언트가 Test Description Req 프리미티브를 수신한 경우:

- 만약 상태가 INSTALLATION이 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않는다;

- OTA 클라이언트는 IN-SITU TESTING 상태로 나아간다;

- 수신된 테스트들은 이전에 저장된 운영 소프트웨어 상에서 수행된다;

- 만약 모든 테스트들이 성공적이라면:

- Installation Cnf 프리미티브가 전송되고;

- 새로운 운영 소프트웨어가 설치되고 시작된다;

- 만약 적어도 하나의 테스트가 성공적이지 않다면:

- Installation Rej 프리미티브가 전송되고;

- 다운로드 운영 소프트웨어가 메모리로부터 삭제된다;

- OTA 클라이언트는 IDEL 상태로 간다.

도 5를 참조하여, 이제 OTA 서버의 행동이 설명된다.

일반적으로, 수신된 각 프리미티브에서, OTA-Client_ID 필드가 분석되고 식별자에 관한 OTA 클라이언트 콘텍스트(OTA-Client-Context)가 고려된다; 만약 수신된 식별자에 대한 OTA 클라이언트 콘텍스트가 존재하지 않는다면, 이 프리미티브는 무시된다.

OTA-서버가 Download Ack Ind 프리미티브를 수신한 경우:

- 만약 OTA 클라이언트 콘텍스트의 상태가 DOWNLOAD INITIATION이 아니라면, 그 프리미티브는 무시되고 과정은 계속되지 않는다;

- OTA 클라이언트 콘텍스트는 MUTUAL AUTHETICATION 상태로 진행하며;

- 무작위 수가 획득되어 저장되고;

- OTA-Client_Challenge_Number의 값이 선택된 암호화 알고리즘, 예를 들어 AES 알고리즘을 사용하는 것에 의하여 내부 키(SIK; Server Identity Key)로 암호화되며;

- Authentication Req 프리미티브가 OTA 클라이언트로 OTA-Server_Response_Number 필드의 이전 단계에서 암호화된 값 및 OTA-Server_Challenge_Number 필드 내의 획득된 수의 값으로 전송된다.

OTA 클라이언트 콘텍스트가 Download Nack Ind를 수신한 경우:

- OTA 클라이언트 콘텍스트의 상태가 DOWNLOAD INITIATION이 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않으며;

- OTA 클라이언트 콘텍스트는 IDEL 상태로 진행한다.

OOTA 클라이언트 콘텍스트가 Authentication Rsp 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트의 상태가 MUTUAL AUTHETICATION이 아니라면, 그 프리미티브는 무시되고 과정은 계속되지 않으며;

- 저장된 무작위 수의 값이 선택된 암호화 알고리즘, 예를 들면 AES 알고리즘을 사용하는 것에 의하여 내부 키(SIK)로 암호화되고;

- 이전 단계에서 암호화된 값이 OTA-Client_Response_Number 필드의 값과 매칭되지 않는다면, OTA 클라이언트 콘텍스트는 IDEL 상태로 진행하고 더 이상 계속 되지 않는다;

- OTA 서버는 CAPABILITY REQUEST 상태로 진행하고;

- Capability Req 프리미티브가 전송된다.

OTA 클라이언트 콘텍스트가 Capability Rsp 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트의 상태가 CAPABILITY REQUEST가 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않는다;

- 이 프리미티브에 포함된 능력이 다운로드될 소프트웨어와 호환가능하지 않다면, OTA 클라이언트 콘텍스트는 IDEL 상태로 진행하고;

- 이 프리미티브에 포함된 능력이 다운로드될 소프트웨어와 호환가능하다면, OTA 클라이언트 콘텍스트는 DOWNLOAD ACCEPTANCE 상태로 진행하고 Download Description Req 프리미티브가 전송된다.

OTA 클라이언트 콘텍스트가 Download Accept Cnf 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트의 상태가 DOWNLOAD ACCEPTANCE가 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않으며;

- OTA 클라이언트 콘텍스트는 SOFTWARE DOWNLOAD 상태로 진행하고;

- 소프트웨어 다운로드가 시작된다.

OTA 클라이언트 콘텍스트가 Download Accept Rej 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트는 IDEL 상태로 진행한다.

OTA 클라이언트 콘텍스트가 License Req 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트의 상태가 SOFTWARE DOWNLOAD가 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않으며;

- 과정은 INSTALLATION 상태로 진행하고;

- 복호화 키를 포함하는 License Rsp 프로토콜 프리미티브가 전송된다.

OTA 클라이언트 콘텍스트가 License Cnf 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트의 상태가 INSTALLATION이 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않으며;

- Test Description 프리미티브가 전송된다.

OTA 클라이언트 콘텍스트가 License Rej 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트는 IDEL 상태로 진행한다.

OTA 클라이언트 콘텍스트가 Installation Cnf 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트는 IDEL 상태로 진행한다.

OTA 클라이언트 콘텍스트가 Installation Rej 프리미티브를 수신한 경우:

- OTA 클라이언트 콘텍스트는 IDEL 상태로 진행한다.

윈도우 프로토콜에 따라 OTA 서버로부터 OTA 클라이언트로 데이터가 전송되는, 그 윈도우 프로토콜의 동작이 이제 설명된다.

OTA 서버의 관점에서, 소프트웨어 다운로드가 시작될 때, 운영 소프트웨어는 공지된 타입의 암호화 알고리즘, 예를 들어 AES 알고리즘 및 암호화 키에 의해 암호화된다.

암호화된 운영 소프트웨어는 예를 들면 제한된 크기, 1-2 kBytes를 갖는 블록들로 분할된다. 운영 소프트웨어가 분할된 무선 블록의 수와 같은 수의 비트를 갖는 비트 마스크(BITMASK)가 할당되고, 각 비트에 대하여, 그 값이 "0"으로 설정된다. 마스크의 각 비트는 무선 블록에 대응되며, 무선 블록의 수는 비트 위치와 같다. 즉, 제1 비트는 제1 무선 블록에 대응하며, 제2 비트는 제2 무선 블록에 대응한다. 운영 소프트웨어를 구성하는 처음 N개의 무선 블록들(BLOCK)이 전송된다. 타이머 T401이 시작된다. 각 메시지(Ack) 수신시:

- 타이머 T401이 재시작되고;

- 메시지(Ack)의 비트맵에 존재하는 값 "1"에 대하여, 대응 위치에 할당된 마스크(BITMASK)의 값이 "1"로 설정되며;

- 아직 전송되지 않은 블록들을 고려하여 마스크(BITMASK) 내에서 값 "0"에 대응하는 처음 N개의 무선 블록들(BLOCK)이 최대로 전송되고;

- 마스크(BITMASK)의 모든 비트들이 "1"과 같은 값을 가지면, 다운로드가 종료된다.

OTA 클라이언트 관점에서, 소프트웨어 다운로드가 시작될 때, 소프트웨어가 분할되는 무선 블록들의 수와 같은 비트 마스크(BITMASK)가 할당되고, 각 비트의 값이 "0"으로 설정된다. 마스크의 각 비트는 무선 블록에 대응하고, 무선 블록의 번호는 비트 위치와 같다. 즉, 제1 비트는 제1 무선 블록에 대응하고 제2 비트는 제2 무선 블록에 대응한다. 그 다음 타이머 T400가 시작된다. 각 무선 블록(BLOCK) 수신시:

- 타이머 T400가 재시작되고;

- 수신된 무선 블록의 블록 번호에 대응한 마스크(BITMASK)의 비트는 "1"로 설정되며;

- 마스크(BITMASK)에 대응하는 비트맵을 구비한 메시지(Ack)가 전송되고;

- 마스크(BITMASK)의 모든 비트들이 "1" 값을 가질 때 다운로드가 종료된다.

요약하면, 실시예에 따라, OTA 클라이언트 및 OTA 서버의 기능 행동은 다음과 같다:

- 다운로드 과정은 예를 들면 MSC(Mobile Switching Center)에 의해 기지국 제어기(BSC)로 전송된 프로토콜 메시지(Handover_Command) 수신시 시작된다;

- OTA 클라이언트와 OTA 서버 사이의 상호 인증은 예를 들어 "시도-응답(Challenge-response)" 방법에 따라 일어난다;

- 다운로드될 운영 소프트웨어는 트래픽 채널, 예를 들어 GPRS 트래픽 채널 상에서 전송된다;

- 다운로드될 운영 소프트웨어는 OTA 서버에 의해 감소된 크기(예를 들어 1 또는 2 kByte)를 갖는 블록들로 분할된다;

- 운영 소프트웨어의 전송은 간단한 윈도우 프로토콜에 의해 관리되며, 크기 윈도우는 운영 소프트웨어가 분할된 블록들의 수와 매칭된다;

- 다운로드된 운영 소프트웨어는 암호화되고, 이 경우 암호화된 운영 소프트웨어의 복호화 및 설치를 위한 키가 필요하다;

- 운영 소프트웨어를 시작하기 전에, OTA 클라이언트는 OTA 서버에 의해 제안된 적절한 테스트로 그것을 조사한다.

도 18을 참조하여, 단말(MS)을 재구성할 수 있는 운영 소프트웨어의 다운로드 과정이 도입된 표준에 의해 정의된 바와 같이, 회로 호출을 위한 GSM으로부터 UMTS로의 내부 시스템 핸드-오버 과정의 적용가능한 예가 도시된다.

도 19를 참조하여, 네트워크 내에 존재하는 다른 엔터티들 사이의 상호작용을 나타내는 상기 소프트웨어 다운로드 과정이 어떻게 동작하는지가 설명된다.

1. OTA 클라이언트와 고려된 OTA 클라이언트에 관련되고 OTA 서버 내에 존재하는 OTA 클라이언트 콘텍스트가 IDEL 상태에 있다.

2. 이동 교환국(Mobile Switching Center; MSC)으로부터의 프로토콜 메시지(Handover_Command)을 수신하면, OTA 클라이언트 콘텍스트는 IDEL 상태로부터 DOWNLOAD INITIATION 상태로 진행하며, 타이머 T101을 시작하고 요청된 다운로드를 가리키면서 Download_Initiation_Ind 프리미티브를 무선 자원(RR)으로 전송한다.

3. 무선 자원(RR)은 Download_Initiation_Ind 프리미티브를 수신한다. 무선 자원(RR)은 무선 자원 관리(RRM)에 소프트웨어 다운로드를 수행하는 것을 가능하게 하는데 필요한 다운링크 자원들을 요청한다.

a. 만약 자원이 사용가능하면, 무선 자원(RR)은 제어 채널(FACHH; Fast Associated Control Channel)을 통하여 단말(MS)의 무선 자원(RR)에 프로토콜 메시지 Packet_Download_Request, RRBP(Ralative Reserved Block Period) 및 요청된 다운로드를 전송하며, 여기서 채널은 단말이 다운로드요청된 다운로드를 수행할 채널들(PDCH)을 가리킨다.

b. 만약 자원이 사용가능하지 않다면, 무선 자원(RR)은 OTA 클라이언트 콘텍스트로 Download_Nack_Ind 프리미티브를 전송한다.

4. 단말(MS)의 무선 자원은 프로토콜 메시지 Packet_Download_Reqeust를 수신하고, 채널들(PDCH)을 구성하며, Download_Reqeust_Ind 프리미티브를 전송한다.

5. OTA 클라이언트는 Download_Reqeust_Ind 프리미티브를 수신한다. 단말이 다운로드를 수행할 수 있다면, OTA 클라이언트는 IDEL 상태에서 DOWNLOAD_INITIATION 상태로 진행하며, 타이머 T100을 시작하며, Download_Ack_Ind 프리미티브를 전송하고, 여기서 OTA 클라이언트는 무선 자원(RR)에 자신의 식별자를 특정한다. 무선 자원(RR)은 OTA 클라이언트의 식별자를 지역적으로 저장한다.

6. 무선 자원(RR)은 Download_Ack_Ind 프리미티브를 수신하고, PACCH(Packet Associated Control Channel)을 통하여 RRBP(Ralative Reserved Block Period)에 의해 특정된 시간에 프로토콜 메시지 Packet_Download_Ack를 기지국 제어기(BSC)의 무선 자원(RR)으로 전송하고, 여기서 그것은 OTA 클라이언트의 식별자를 나타낸다.

7. 기지국 제어기(BSC)의 무선 자원은 프로토콜 메시지 Packet_Download_Ack 를 수신하고, 프리미티브 Download_Ack_Ind를 OTA 클라이언트 콘텍스트에 전송하며, 여기서 그것은 OTA 클라이언트의 식별자를 특정한다.

8. OTA 클라이언트 콘텍스트는 프리미티브 Download_Ack_Ind를 수신한다. OTA 클라이언트 콘텍스트는 타이머 T101을 멈추고, 타이며 T201을 시작하면서 DOWNLOAD_INITIATION 상태에서 MUTUAL_AUTHENTICATION 상태로 나아간다. 프리미티브 Authentication_Req가 무선 자원(RR)으로 전송된다.

9. 무선 자원(RR)은 프리미티브 Authetication_Req를 수신하고, 제어 채널(PACCH)을 통하여 RRBP가 지시된 프로토콜 메시지 Packet_Authentication_Request를 단말(MS)의 무선 자원(RR)으로 전송한다.

10. 단말(MS)의 무선 자원은 프로토콜 메시지 Packet_Authentication_Request를 수신하고, OTA 클라이언트로 프리미티브 Authentication_Req를 전송한다.

11. OTA 클라이언트는 프리미티브 Authentication_Req를 수신하고, 타이머 T100을 멈추며, 타이머 T200을 시작하면서 MUTUAL_AUTHENTICATION 상태로 나아간다. 이 단계에서, OTA 서버의 인증이 수행된다.

a. OTA 서버가 인증되지 않는다면, OTA 클라이언트는 타이머 T200을 멈추고 IDEL 상태로 돌아간다.

b. OTA 서버가 인증되면, OTA 클라이언트는 무선 자원(RR)으로 프리미티브 Authentication_Rsp를 전송한다.

12. 무선 자원(RR)은 프리미티브 Authentication_Rsp를 수신하고 PACCH를 통 하여 RRBP에 의해 특정된 시간에 기지국 제어기(BSC)의 무선 자원(RR)으로 프로토콜 메시지 Packet_Autentication_Response를 전송한다.

13. 기지국 제어기(BSC)의 무선 자원(RR)은 프로토콜 메시지Packet_Autentication_Response를 수신하고 OTA 클라이언트 콘텍스트로 프리미티브 Authetication_Rsp를 전송한다.

14. OTA 클라이언트 콘텍스트는 프리미티브 Authetication_Rsp를 수신하고 OTA 클라이언트 인증을 검증한다:

a. OTA 클라이언트가 인증되지 않는다면, 타이머 T201가 중단되고 OTA 클라이언트 콘텍스트가 IDEL 상태로 돌아온다.

b. OTA 클라이언트가 인증된다면, 타이머 T201가 중단되고 OTA 클라이언트 콘텍스트는 타이머 T301을 시작하면서 CAPABILITY REQUEST 상태로 진행한다. OTA 클라이언트 콘텍스트는 무선 자원(RR)으로 프리미티브 Capability_Req를 전송한다.

15. 무선 자원(RR)은 프리미티브 Capability_Req를 수신하고 제어 채널 PACCH을 통하여 단말(MS)의 무선 자원(RR)으로 프로토콜 메시지 Packet_Capability_Req를 전송하며, 여기서 PPBP가 특정된다.

16. 단말(MS)의 무선 자원(RR)은 프로토콜 메시지 Packet_Capability_Req를 수신하고 프리미티브 Capability_Req를 OTA 클라이언트로 전송한다.

17. OTA 클라이언트는 프리미티브 Capability_Req를 수신하고, 타이머 T200를 종료하고, 타이머 T300을 시작하면서 CAPABILITY REQUEST 상태로 진행한다. OTA 클라이언트는 무선 자원(RR)으로 프리미티브 Capability_Rsp를 전송한다.

18. 무선 자원(RR)은 프리미티브 Capability_Rsp를 수신하고 PACCH를 통하여 RRBP에 의해 특정된 시간에 프로토콜 메시지 Packet_Capability_Response를 기지국 제어기(BSC)의 무선 자원(RR)으로 전송한다.

19. 기지국 제어기(BSC)의 무선 자원(RR)은 프로토콜 메시지 Packet_Capability_Response를 수신하고 프리미티브 Capability_Rsp를 OTA 클라이언트 콘텍스트로 전송한다.

20. OTA 클라이언트 콘텍스트는 프리미티브 Capability_Rsp를 수신하고 단말의 능력을 검증한다:

a. 만약 능력이 소프트웨어 다운로드와 호환가능하면, 타이머 T301이 중단되고 OTA 클라이언트 콘텍스트는 IDEL 상태로 돌아간다.

b. 만약 능력이 소프트웨어 다운로드와 호환가능하지 않다면, 타이머 T301가 중단되고 OTA 클라이언트 콘텍스트는 DOWNLOAD ACCPETANCE 상태로 진행하는 한편, 타이머 T302를 시작하고 무선 자원(RR)으로 프리미티브 Download_Description_Req를 전송하며, 여기서 다운로드 동작과 관련된 정보(다운로드될 무선 블록의 수, 과금, 설치 등)가 지시된다.

21. 무선 자원(RR)은 프리미티브 Download_Description_Req를 수신하고 제어 채널 PACCH를 통하여 프로토콜 메시지 Packet_Download_Description을 단말(MS)의 무선 자원(RR)으로 전송하며, 여기서 RRBP가 특정된다.

22. 단말(MS)의 무선 자원(RR)은 프로토콜 메시지 Packet_Download_Description을 수신하고 프리미티브 Download_Description_Req를 OTA 클라이언트로 전송한다.

23. OTA 클라이언트는 프리미티브 Download_Description_Req를 수신하고 DOWNLOAD ACCEPTANCE 상태로 간다. OTA 클라이언트는 수신된 정보를 검증한다:

a. 다운로드가 받아들여지지 않으면, OTA 클라이언트는 프리미티브 Download_Accept_Rej를 무선 자원(RR)으로 전송하고 IDEL 상태로 돌아간다.

b. 다운로드가 받아들여지면, OTA 클라이언트는 프리미티브 Download_Accept_Cnf를 무선 자원(RR)에 전송하고 SOFTWARE DOWNLOAD 상태로 진행하는 한편, 타이머 T400을 시작한다.

24. 무선 자원(RR)은 프리미티브 Download_Accept_Cnf를 수신하고 PACCH를 통하여 RRBP에 의해 특정된 시간에 프로토콜 메시지 Packet_Download_Accept를 기지국 제어기(BSC)의 무선 자원(RR)으로 전송한다.

25. 기지국 제어기(BSC)의 무선 자원(RR)은 프로토콜 메시지 Packet_Download_Accept를 수신하고 프리미티브 Download_Accept_Cnf를 OTA 클라이언트 콘텍스트로 전송한다.

26. OTA 클라이언트 콘텍스트는 프리미티브 Download_Accept_Cnf를 수신하고, 타이머 T302를 중단시키며 OTA 클라이언트 콘텍스트는 SOFTWARE DOWNLOAD 상태로 가는 한편, 타이머 T400을 활성화시킨다. OTA 클라이언트 콘텍스트는 다운로드를 시작하고, 무선 자원(RR)으로 프리미티브 Data_Req를 전송하는 것에 의하여 다운로드될 소프트웨어의 다양한 블록들을 전송하기 시작한다. 무선 블록의 전송은 종래 윈도우 프로토콜에 의해 일어난다. 무선 블록들은 채널 PDTCH(Packet Data Transfer Channel)을 통하여 전송된다.

27. OTA 클라이언트는 무선 자원(RR)으로부터의 프리미티브 Data Ind의 수신을 통하여 각 무선 블록을 수신한다. 수신된 각 블록에서, 타이머 T400이 재시작된다. 주기적으로 OTA 클라이언트는 프리미티브 Data_Req를 무선 자원(RR)에 전송하는 것에 의하여 OTA 클라이언트 콘텍스트에 확인 신호(Ack)를 전송한다. 무선 자원(RR)은 다운로드될 마지막 무선 블록에 관한 Ack를 전송하고, 타이머 T400을 중단시키며, INSTALLATION 상태로 나아가는 한편, 타이머 T500을 시작한다. 프리미티브 License_Req는 무선 자원(RR)으로 전송된다.

28. OTA 클라이언트 콘텍스트는 무선 자원(RR)으로부터의 프리미티브 Data_req의 수신을 통하여 다양한 메시지들(Ack)을 수신하고, 수신된 각 Ack에서 타이머 T401이 재시작된다. OTA 클라이언트 콘텍스트는 마지막 무선 블록에 대한 Ack를 수신하고, 타이머 T401을 중단시키며, INSTALLATION 상태로 진행하는 한편, 타이머 T501을 시작한다.

29. 무선 자원(RR)은 프리미티브 License_Req를 수신하고 관련 제어 채널 PACCH을 통하여 프로토콜 메시지 Packet_License_Reqeust를 기지국 제어기(BSC)의 무선 자원(RR)에 전송한다.

30. 기지국 제어기(BSC)의 무선 자원은 프로토콜 메시지 Packet_License_Request를 수신하고, 프리미티브 License_Req를 OTA 클라이언트 콘텍스트로 전송한다.

31. OTA 클라이언트 콘텍스트는 프리미티브 License_Req를 수신하고 무선 자 원(RR)으로 프리미티브 License_Rsp를 전송하는 한편, 소프트웨어 암호화를 수행하기 위한 키를 가리킨다.

32. 무선 자원(RR)은 프리미티브 License_Rsp를 수신하고 관련 제어 채널 PACCH를 통하여 프로토콜 메시지 Packet_License_Response를 단말(MS)의 무선 자원(RR)으로 전송한다.

33. 단말(MS)의 무선 자원(RR)은 프로토콜 메시지 Packet_License_Response를 수신하고 프리미티브 License_Rsp를 OTA 클라이언트로 전송한다.

34. OTA 클라이언트는 프리미티브 License_Rsp를 수신하고, 수신된 키로 소프트웨어를 복호화한다.

a. 복호화 동작이 성공하면, OTA 클라이언트는 프리미티브 License_Cnf 를 무선 자원(RR)으로 전송한다.

b. 복호화 동작이 성공하지 못하면, OTA 클라이언트는 프리미티브 License_Rej를 무선 자원(RR)으로 전송하고, 타이머 T500을 중단시키며 IDEL 상태로 돌아간다.

35. 무선 자원(RR)은 프리미티브 License_Cnf를 수신하고 관련 제어 채널 PACCH를 통하여 프로토콜 메시지 Packet_License_Accept를 기지국 제어기(BSC)의 무선 자원(RR)으로 전송한다.

36. 기지국 제어기(BSC)의 무선 자원(RR)은 프로토콜 메시지 Packet_License_Accept를 수신하고 프리미티브 Licesne_Cnf를 OTA 클라이언트 콘텍스트에 전송한다.

37. OTA 클라이언트 콘텍스트는 프라미티브 License_Cnf를 수신하고, 무선 자원(RR)으로 프리미티브 Test_Description_Req를 전송하는 한편 수행될 테스트에 관한 정보를 가리킨다.

38. 무선 자원(RR)은 프리미티브 Test_Description_Req를 수신하고 관련 제어 채널 PACCH을 통하여 프로토콜 메시지 Packet_Test_Description을 단말(MS)의 무선 자원(RR)으로 전송한다.

39. 단말(MS)의 무선 자원(RR)은 프로토콜 메시지 Packet_Test_Description을 수신하고 프리미티브 Test_Description_Req를 OTA 클라이언트로 전송한다.

40. OTA 클라이인터는 프리미티브 Test_Description_Req를 수신하고, 타이머 T500을 중단시키며, IN-SITU TESTING 상태로 간다. OTA 클라이언트는 OTA 클라이언트 콘텍스트에 의해 지시된 바와 같이 다운로드된 소프트웨어 상에서 테스트를 수행한다.

a. 만약 테스트가 성공적이지 못하다면, OTA 클라이언트는 프리미티브 Installation_Rej를 무선 자원(RR)으로 전송하고 IDEL 상태로 돌아간다.

b. 만약 테스트가 성공적이라면, OTA 클라이언트는 프리미티브 Installation_Cnf를 무선 자원(RR)으로 전송하고 새로운 소프트웨어를 시작하며, IDEL 상태로 돌아간다.

41. 무선 자원(RR)은 프리미티브 Installation_Cnf를 수신하고 관련 제어 채널 PACCH을 통하여 프로토콜 메시지 Packet_Installation_Accept를 기지국 제어기(BSC)의 무선 자원(RR)으로 전송하고 단말(MS)의 무선 인터페이스를 재구성한다.

42. 기지국 제어기(BSC)의 무선 자원(RR)은 프로토콜 메시지 Packet_Installation_Accept를 수신하고, 프리미티브 Installation_Cnf를 OTA 클라이언트 콘텍스트에 전송하며, 표준에 의해 제공된 자원의 해제 과정을 시작하며, 상기 과정이 종료되면, 표준에 의해 제공된 핸드-오버 과정이 계속된다.

43. OTA 클라이언트 콘텍스트는 프리미티브 Installation_Cnf를 수신하고 IDEL 상태로 돌아간다.

도 19에 개시된 과정은 운영 소프트웨어 다운로드 과정에 관한 것이다.

이 과정은 당업자에게 자명한 바와 같이 표준에 의해 정의된 회로 호출을 위한 GSM으로부터 UMTS로의 내부 시스템 핸드-오버 과정 내에 삽입될 수 있다.

특히, 삽입은 기지국 서브시스템 어플리케이션부(Base Station Subsystem Application Part; BSSAP) 프로토콜의 HANDOVER COMMAND 메시지의 MSC로부터의 수신과 RR 프로토콜의 INTERSYSTEM TO UTRAN HANDOVER COMMAND 메시지의 MS로의 전송 사이에서, RR 계층에서 수행될 수 있다.

본 발명은 현재 표준들에 의해 특정된 모든 가능한 시스템간 핸드-오버 과정에 대하여 일반화될 수 있다.

예를 들어, 상기 과정은 당업자에게 자명한 바와 같이 표준에 의해 정의된 회로 호출을 위한 UMTS로부터 GSM으로의 시스템간 핸드-오버 과정에 삽입될 수 있다. 특히, 상기 삽입은 무선 접속 네트워크 어플리케이션부(Radio Access Network Application Part; RANAP) 프로토콜의 RELOCATION COMMAND 메시지의 MSC로부터의 수신과 무선 자원 제어(Radio Resource Control; RRC) 프로토콜의 HANDOVER FROM UTRAN COMMAND 메시지의 사용자 장치(User Equipment; UE)로의 전송 사이에서, 무선 자원 제어(Radio Resource Control; RRC) 계층에서 수행될 수 있다.

본 발명은 또한 예를 들어 IMT 2000(International Mobile Telecommunication 2000)과 WLAN 또는 IEEE 802.16 또는 IEEE 802.20 시스템들 사이의 시스템간 핸드-오버 과정과 같이, 아직 표준화되지 않은 시스템간 핸드-오버 과정에 대하여도 일반화될 수 있다.

당업자에게 자명한 바와 같이, 본 발명은 음성 호출, 특별히 회로 타입 호출의 경우에 호출을 방해하지 않고 운영 소프트웨어의 다운로드를 수행하도록 한다. 이것은 GSM/GPRS의 예의 경우에 회로 통신을 위하여 사용되는, 예를 들어 TCH(Traffic Channel) GSM 채널과 같은 회로 타입 채널에 병렬로 PDTCH GPRS 채널들과 같은 하나 이상의 패킷 채널들을 할당하는 것에 의하여 가능해진다.

이 특징은 음성, 데이터 및 소프트웨어 다운로드 사이의 우선권을 관리할 수 있게 한다.

본 발명은 GSM/GPRS 시스템 및 상기 시스템의 무선 채널들의 사용을 참조로 하여 개시되었으나, 당업자에게 자명한 바와 같이 본 발명은 예를 들면 "범용" 채널을 사용하는 것에 의하여 적용될 수 있다.

"범용" 채널을 사용하는 것의 가능한 예는 OTA 서버로부터 OTA 클라이언트로 운영 소프트웨어 다운로드 과정에 대하여 문서에 정의된 바와 같이 "범용" 채널을 사용하는 것일 수 있다.

시스템간 핸드-오버의 경우, "범용" 채널 사용의 구현은 예를 들어 GSM/GPRS 시스템인 능동 시스템의 무선 채널을 통한 능동 연결을 유지하기 위한 것으로 예상되는 반면, 도 18에 개시된 과정을 적용하는 OTA 서버로부터 OTA 클라이언트로의 운영 소프트웨어 다운로드 과정은 상술한 "범용" 채널을 통하여 동시에 이용될 수 있다.

"범용" 채널은 전체 운영 소프트웨어 다운로드 과정 또는 그것의 일부, 예를 들어 OTA 서버로부터 OTA 클라이언트로의 운영 소프트웨어 전송에 사용될 수 있다.

"범용" 채널의 부분 사용의 경우, 운영 소프트웨어 다운로드 과정의 나머지 부분은 능동 시스템의 무선 채널을 사용하는 것에 의해 구현될 수 있다.

"범용" 채널의 채용은 능동 채널과 관련된 무선 자원을 좀 더 효율적인 방식으로 로드할 수 있게 하고, 그것을 다른 사용자에게 이용가능하게 남겨두며, "범용" 채널이 이러한 형식의 동작에 전용인 채널인 것에 비하여 훨씬 빠르게 운영 소프트웨어 다운로드 과정을 수행할 수 있게 한다.

본 발명의 다른 실시예는 당업자에게 공지된 바와 같이 단말이 두 시스템들, 예를 들어 GSM/GPRS로부터 UMTS 사이에서 IDEL 상태에 있을 때, 셀 재선택 과정의 관리 가능성을 제공하는 것이다.

상술한 바와 같이, 프리미티브 및 관련 필드들을 명명하기 위하여 사용되는 용어는 단지 지시를 위한 것이며, 설명된 바와 같이 대응 정의의 의미이다.

이러한 확장은 OTA 클라이언트와 단말(MS) 측의 무선 자원(RR) 사이에 다음과 같은 프리미티브의 도입을 제공한다:

- Download Initiation: 이 메시지는 OTA 클라이언트로부터 단말(MS) 측의 무선 자원으로 전송된다.

GSM/GPRS의 경우에 이 프리미티브에 제공된 필드들은 적어도 다음과 같은 것들의 세트이다:

- OTA-Client_ID: 요청을 수행하는 OTA 클라이언트를 식별한다;

그리고, OTA 서버와 기지국 제어기(BSC) 측의 무선 자원(RR) 사이의 다음과 같은 프리미티브의 도입을 제공한다:

- Request Download Initiaion Ind: 이 메시지는 기지국 제어기(BSC) 측의 무선 자원(RR)으로부터 OTA 클라이언트로 전송된다.

- OTA-Client_ID: 요청을 수행하는 OTA 클라이언트를 식별한다.

이하에서, 프리미티브 Request Download Initiation Ind를 수신할 때 OTA 클라이언트 콘텍스트이 단말(MS)과 관련된 콘텍스트의 행동이 지시된다:

- 만약 OTA 클라이언트 콘텍스트의 상태가 IDEL이 아니라면, 이 프리미티브는 무시되고 과정은 계속되지 않으며;

- OTA 클라이언트 콘텍스트는 DOWNLOAD INITIATION 상태가 되고;

- 프리미티브 Download Initiation Ind가 OTA 클라이언트로 전송되는 반면, 다양한 가능한 다운로드를 가리킨다.

도 19를 참조하여, 셀 재선택의 경우 운영 소프트웨어의 다운로드 과정의 작업이 도시되며, 네트워크 내에 존재하는 다른 엔터티들 사이의 상호작용을 지시한 다. 이하에서는, 과정의 제1 단계의 작업에 상세히 설명되며, 나머지 과정들은 도 18의 설명과 동일하다.

Ⅰ. OTA 클라이언트 및 고려되는 OTA 클라이언트에 대한 OTA 클라이언트 콘텍스트는 IDEL 상태에 있다.

Ⅱ. 물리적 계층으로부터 온 셀 재선택 명령 수신시, OTA 클라이언트는 IDEL 상태에서 DOWNLOAD INITIATION 상태로 변경되고, 타이머 T100을 시작하며, 자신의 식별자를 특정하는 프리미티브 Download_Initiation_Req을 무선 자원(RR)으로 전송한다. 무선 자원(RR)은 OTA 클라이언트의 식별자를 지역적으로 저장한다.

Ⅲ. 무선 자원(RR)은 프리미티브 Download_Initiation_Req를 수신한다. 무선 자원은 PRACH(Packet Random Access Channel)를 통하여 표준에 의해 제공된 프로토콜 메시지 Packet_Channel_Request를 전송하며, 그것은 사용자에 의한 운영 소프트웨어의 다운로드 요청 및 OTA 채널의 식별자를 특정한다. 운영자에 의해 설치된 구성이 PBCCH(Packet Broadcast Control Channel) 및 PCCCH(Packet Common Control Channel)에 의해 구성된 마스터 채널을 제공하지 않는 GPRS의 경우, 설명된 과정은 설명된 바와 같이 PRACH(Packet Random Access Channel) 및 PAGCH(Packet Access Grant Channel) 대신 RACH(Random Access Channel) 및 AGCH(Access Grant Channel) 상에 그 과정의 처음 두 개의 메시지들을 맴핑하는 것에 의해 유효하게 남아있다.

Ⅳ. 기지국 제어기(BSC)의 무선 자원(RR)은 프로토콜 메시지 Packet_Channel_Request를 수신한다. 이것은 소프트웨어 다운로드 요청에 따라 인식되기 때문에 OTA 클라이언트 콘텍스트로 프리미티브 Request_Download_Initiation_Ind를 전송하고, 그것은 수신된 메시지에 의해 판독된 OTA 클라이언트의 식별자를 특정한다.

Ⅴ. OTA 서버는 프리미티브 Request_Download_Initiation_Ind를 수신하고 지시된 OTA 클라이언트에 대한 OTA 클라이언트 콘텍스트가 어떤 상태인지를 확인한다:

a. 만약 상태가 IDEL이라면, OTA 클라이언트 콘텍스트는 DOWNLOAD INITIATION으로 진행하고, 타이머 T101을 시작하며, 무선 자원(RR)으로 프리미티브 Download_Initiation_Ind를 전송하는 반면, 요청된 다운로드를 가리킨다.

b. 만약 상태가 IDEL이 아니라면, 미 메시지는 무시된다.

Ⅵ. 무선 자원(RR)은 프리미티브 Download_Initiation_Ind를 수신한다. 무선 자원(RR)은 무선 자원 관리(RRM)에 소프트웨어 다운로드를 가능하게 하는데 필요한 다운링크 자원을 요청한다:

a. 만약 자원이 이용가능하다면, 무선 자원(RR)은 제어 채널 PAGCH을 통하여 프로토콜 메시지 Packet_Download_Request를 단말(MS)의 무선 자원(RR)으로 전송하며, 그것은 단말이 다운로드를 수행할 채널인 채널들 PDCH, RRBP 및 요청된 다운로드를 가리킨다.

b. 만약 자원이 이용가능하지 않다면, 무선 자원(RR)은 프리미티브 Download_Nack_Ind를 OTA 클라이언트 콘텍스트로 전송한다.

Ⅶ. 단말(MS)의 무선 자원(RR)은 프로토콜 메시지 Packet_Download_Request를 수신하고, 채널 PDCH를 구성하며, 프리미티브 Download_Request_Ind를 전송한 다.

Ⅷ. OTA 클라이언트는 프리미티브 Download_Request_Ind를 수신한다. 만약 단말이 다운로드를 수행할 수 있다면, OTA 클라이언트는 프리미티브 Download_Ack_Ind를 전송하고, 그것은 자신의 식별자를 특정한다. 무선 자원(RR)은 OTA 클라이언트의 식별자를 지역적으로 저장한다.

상기 과정은 도 18을 참조하여 설명된 과정 앞에 6번째로부터의 단계들을 수행하는 것에 의하여 계속된다.

본 발명에 따라 설명된 구조와 방법은 GSM/GPRS 시스템의 접속 네트워크를 참조하여 개시되었다.

본 발명은 또한 UMTS, UTRAN(UMTS Terretrial Radio Access Network) 또는 WAN, IEEE 802.16, IEEE 802.20과 같은 임의의 다른 접속 네트워크들에도 적용될 수 있다.

예를 들어, UTRAN의 경우, 본 발명은 UMTS 시스템의 RRC 계층에서 OTA 클라이언트 및 OTA 서버, 관련 과정들, 프리미티브들 및 프로토콜 메시지들을 삽압하는 것으로 구현될 수 있다.

본 발명은 접속 네트워크 및 네트워크 측과 단말 측 모두의 대응 프로토콜 계층들을 사용하는 것에 의해 개시된다.

본 발명은 또한 코어 네트워크 및 네트워크 측과 단말 측 모두의 대응 프로토콜 계층들을 사용하는 것에 의해 구현된다.

이 경우, 예를 들어 GSM/GPRS 및 UMTS 시스템의 패킷 교환 코어 네트워 크(Packet Switched Core Network)를 고려하면, 본 발명은 코어 네트워크의 서빙 GPRS 지원 노드(SGSN) 및 단말 각각의 GPRS 이동 관리(GMM) 계층에, OTA 클라이언트, OTA 서버, 관련 과정들, 프리미티브들 및 프로토콜 메시지들을 삽입하는 것에 의해 구현될 수 있다.

좀 더 구체적으로, GSM/GPRS의 경우, GPRS 이동성 관리(GMM) 계층은 OTA 서버와 OTA 클라이언트 사이에서 교환된 새로운 프로토콜 메세지들 및 관련 필드들을 도입하는 것에 의해 변경된다. 동일한 방법이 UMTS 시스템에 대하여도 적용될 수 있다.

본 발명은 시스템간 핸드-오버 과정 동안 하나의 운영 소프트웨어의 다운로딩 및 활성화를 고려하여 개시되고 있다.

당업자에게 자명한 바와 같이, 운영 소프트웨어는 즉시 설치 및 작동되는 대신에 단말 측으로 다운로드되어 저장될 수 있다.

이 추가 실시예에 따르면, 네트워크 또는 사용자로부터 온 요청에 따라 운영 소프트웨어를 성공적으로 설치 및 작동시키는 것이 가능하다. 무선 단말(UE/MS)이충분한 메모리 및 프로세싱 능력을 갖는다면, 다운로드된 운영 소프트웨어는 이미 존재하는 그리고 현재 작동 중인 시스템에 동시에 저장되고 설치될 수 있다.

이 옵션은 단말(UE/MS)의 다중 모드 작동을 허용하는데 유용하다. 다시 말해, 이 옵션은 단말이 운영 소프트웨어를 다운로드할 필요 없이 하나의 동작 모드에서 다른 동작 모드로 변경될 수 있게 한다.

요양하면, 본 발명에 의해 적어도 다음과 같은 이점들을 획득할 수 있다.

- 어떠한 노드들 또는 물리적 인터페이스들도 이미 존재하고 있는 것들에 추가되지 않기 때문에 2세대 및 3세대 네트워크에 존재하는 프로토콜들과 노드들에 대한 영향력이 유지된다;

- 과정의 시그널링 상태가 표준에 의해 제공된 동일한 시그널링 채널들을 채용하는 반면 데이터 채널들은 소프트웨어 다운로드 과정을 위하여만 할당되기 때문에 무선 자원의 점유가 최소화된다;

- 본 발명은 기존의 2세대 및 3세대 네트워크에 근거하기 때문에 종래 기술에 언급된 바와 같이 IP 기반 미래 UMTS 해제를 기다릴 필요가 없다.

구체적으로, 접속 네트워크 및 네트워크 측 및 단말 측 모두의 대응 프로토콜 계층을 사용하는 경우, RR 프로토콜은 단말이 예를 들면 GSM/GPRS,US95, PDC(Phone Digital Cellular)와 같은 2세대 셀룰러 시스템 또는 IMT 2000 계열에 속하는 3세대 셀룰러 시스템을 구현할 수 있는 새로운 운영 소프트웨어를 다운로드 하는 것을 허용하는 몇몇 변경에 통합되기 때문에 네트워크는 소프트웨어 다운로드 과정 및 상대적인 무선 자원들을 완전히 제어할 수 있다.

명세서 내에 포함되어 있음

Claims

적어도 하나의 프로토콜 계층(RR, GMM)을 포함하고,

통신 시스템을 사용하는 것에 의하여 통신 네트워크 내의 정보 교환을 관리하도록 구성된 적어도 하나의 재구성가능한 무선 단말(UE/MS); 및

무선 OTA 연결을 통해 상기 재구성가능한 무선 단말(UE/MS)과의 정보 교환을 관리하도록 구성된 상기 통신 네트워크의 적어도 하나의 노드(BSC, RNC, SGSN)를 구비하는 통신 시스템에 따라 동작하는 통신 네트워크에 있어서,

상기 적어도 하나의 노드는 상기 통신 네트워크의 상기 프로토콜 계층(RR, GMM)을 사용하고 상기 무선 단말(MS)을 구성하는 적어도 하나의 프로토콜 스택 요소들의 적어도 하나의 세트를 구현하도록 설계된 운영 소프트웨어 모듈들의 세트를 포함하도록 구성된 서버 엔터티(OTA 서버)를 포함하고,

상기 무선 단말(UE/MS)은 상기 서버 엔터티의 상기 프로토콜 계층(RR, GMM)에 대응하는 각각의 프로토콜 계층을 사용하도록 구성된 클라이언트 엔터티(OTA 클라이언트)를 포함하며,

상기 서버 엔터티 및 상기 클라이언트 엔터티에는 적어도 부분적으로 상기 무선 단말(UE/MS)을 구성하기 위한 운영 소프트웨어 모듈들의 상기 세트 중 적어도 하나의 모듈을 다운로드하기 위하여, 상기 프로토콜 계층(RR, GMM)을 사용하는 것에 의하여 상기 무선 단말(UE/MS)과 상기 노드(BSC, RNC, SGSN) 사이의 OTA(Over-The-Air) 다운로드 과정을 관리할 수 있는 소프트웨어 모듈들이 OTA 방식으로 각각 제공되는 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

상기 서버 엔터티(OTA 서버)는 상기 프로토콜 계층(RR, GMM)의 적어도 하나의 변경 메시지들의 세트를 포함하고,

상기 클라이언트 엔터티(OTA 클라이언트)는 상기 프로토콜 계층(RR, GMM)의 적어도 하나의 추가 변경 메시지들의 세트를 포함하며,

상기 서버 엔터티(OTA 서버) 및 상기 클라이언트 엔터티(OTA 클라이언트)와 각각 관련된 변경 메시지들의 상기 세트는 상기 OTA 다운로드 과정을 관리하도록 구성되는 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

무선 접속 네트워크(GERAN; UTRAN) 및 코어 네트워크를 포함하고,

상기 프로토콜 계층(GMM)은 상기 코어 네트워크의 프로토콜 계층인 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

무선 접속 네트워크(GERAN; UTRAN) 및 코어 네트워크를 포함하고,

상기 프로토콜 계층(RR)은 상기 무선 접속 네트워크(GERAN; UTRAN)의 프로토콜 계층인 것을 특징으로 하는 통신 네트워크.
제4항에 있어서,

상기 무선 접속 네트워크(GERAN; UTRAN)는 무선 제어기(BSC, RNC)를 포함하며,

상기 프로토콜 계층은 상기 무선 제어기(BSC, RNC)의 프로토콜 계층인 것을 특징으로 하는 통신 네트워크.
제3항에 있어서,

상기 무선 접속 네트워크는 2세대 네트워크(GERAN)에 따라 동작하는 것을 특징으로 하는 통신 네트워크.
제3항에 있어서,

상기 무선 접속 네트워크는 3세대 네트워크(UTRAN)에 따라 동작하는 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

상기 무선 OTA 연결은 상기 통신 네트워크의 범용 채널을 통하여 확립되는 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

상기 무선 OTA 연결은 상기 통신 네트워크의 무선 채널을 통하여 확립되는 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

상기 통신 시스템은 음성 호출, 데이터 전송 및 상기 운영 소프트웨어 모듈들의 상기 세트 중 적어도 하나의 모듈의 다운로드 사이의 우선권을 관리하도록 구성된 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

OTA 소프트웨어 모듈들은 음성 호출 동안 운영 소프트웨어 모듈들의 상기 세트 중 적어도 하나의 모듈을 다운로드하도록 구성된 것을 특징으로 하는 통신 네트워크.
제1항에 있어서,

상기 운영 소프트웨어 모듈들의 세트는 적어도 부분적으로 상기 무선 단말(MS)을 다른 통신 시스템으로 재구성하는 것을 특징으로 하는 통신 네트워크.
제12항에 있어서,

상기 무선 단말(MS)은 상기 다른 통신 시스템 상에서 적어도 측정을 수행하 기 위한 프로토콜 스택 계층을 포함하는 것을 특징으로 하는 통신 네트워크.
적어도 하나의 프로토콜 계층(RR, GMM)을 포함하는 통신 시스템에 따라 동작하는 통신 네트워크에 속하는 적어도 하나의 재구성가능한 무선 단말(UE/MS)을 구성하기 위한 방법에 있어서,

상기 무선 단말은 무선 OTA 연결을 통해 상기 통신 네트워크의 적어도 하나의 노드와 정보를 교환하도록 설계되며,

상기 프로토콜 계층(RR, GMM)을 사용하도록 구성되고 상기 무선 단말(MS)을 재구성하는 적어도 하나의 프로토콜 스택 요소들의 세트로 상기 무선 단말(UE/MS)을 구성하기 위한 운영 소프트웨어 모듈들의 세트를 포함하는 서버 엔터티(OTA 서버)를 상기 통신 네트워크의 적어도 하나의 노드와 연관시키는 단계;

상기 서버 엔터티(OTA 서버)의 상기 프로토콜 계층(RR, GMM)에 대응하는 각각의 프로토콜 계층들을 사용하도록 구성된 클라이언트 엔터티(OTA 클라이언트)를 상기 무선 단말(MS)에 연관시키는 단계;

상기 프로토콜 계층들을 사용하는 것에 의하여 OTA 다운로드 과정을 확립하는 단계; 및

상기 OTA 다운로드 과정을 사용하는 것에 의해 적어도 부분적으로 상기 무선 단말(UE/MS)을 구현하기 위하여 상기 서버 엔터티(OTA 서버)로부터 상기 무선 단말(UE/MS)로 상기 운영 소프트웨어 모듈들의 세트 중 적어도 하나의 모듈을 다운로드하는 단계를 포함하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제14항에 있어서,

상기 OTA 다운로드 과정을 확립하는 단계는 각 프로토콜 단계에 대하여 상기 프로토콜 계층의 변경 프로토콜 메시지들을 교환하는 단계를 포함하는 프로토콜 단계들의 세트를 포함하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제15항에 있어서,

상기 변경 프로토콜 메시지들을 교환하는 단계는,

상기 메시지의 타입을 식별하는 제1 필드(Massage_Type),

상기 메시지와 관련된 무선 단말(MS)을 식별하는 제2 필드(OTA-Client_ID), 및

데이터 정보를 포함하는 제3 필드의 세트를 각각 포함하는 메시지들을 교환하는 단계를 포함하는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제15항에 있어서,

상기 프로토콜 단계들의 세트는,

a) 상기 적어도 하나의 운영 소프트웨어 모듈을 다운로딩하기 위한 요청을 수행하는 단계;

b) 상기 클라이언트 엔터티(OTA 클라이언트) 및 상기 서버 엔터티(OTA 서버)를 상호 인증하는 단계;

c) 상기 서버 엔터티(OTA 서버)로부터 다운로드가능한 상기 적어도 하나의 운영 소프트웨어 모듈을 수용하는 상기 무선 단말(UE/MS)의 능력을 조사하는 단계;

d) 다운로드 옵션들에 관한 정보를 제공하는 단계;

e) 상기 적어도 하나의 운영 소프트웨어 모듈들을 블록들로 분할하는 단계;

f) 상기 블록들을 상기 서버 엔터티(OTA 서버)로부터 상기 적어도 하나의 무선 단말(UE/MS)로 전송하는 단계;

g) 프로토콜 스택 요소들의 하나의 세트로 상기 적어도 하나의 운영 소프트웨어 모듈을 재구성하고 상기 요소들의 세트를 테스트하기 위하여 상기 블록들을 재조립하는 단계; 및

h) 상기 무선 단말(UE/MS)로 상기 요소들의 세트를 설치하는 단계들 중 적어도 하나를 포함하는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제17항에 있어서,

상기 프로토콜 단계들의 세트는,

상기 무선 단말(UE/MS)로 다운로드된 상기 블록들의 구조를 감시하는 단계; 를 포함하는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제17항에 있어서,

상기 프로토콜 단계들의 세트는,

상기 OTA 다운로드 과정을 수행하도록 허용된 시간을 제한하는 타이머들(T100, T200, T300, T400, T500, T101, T201, T301, T302, T401, T501)의 세트를 관리하는 단계를 포함하는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제17항에 있어서,

상기 프로토콜 단계들의 세트는,

각 프로토콜 단계들에 적어도 한 쌍의 타이머들 즉, 상기 무선 단말(UE/MS)에 의해 수행된 프로토콜 단계들을 감시하기 위한 제1 타이머, 및 상기 서버 엔터티(OTA 서버)에 의해 수행된 프로토콜 단계들을 감시하기 위한 제2 타이머를 할당하는 단계를 포함하며, 상기 각 타이머들은 하나의 프로토콜 단계가 시작될 때 시작되고 상기 하나의 프로토콜 단계가 수행될 때 종료되는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제17항에 있어서,

상기 상호 인증 단계는 "시도-응답(challenge-response)" 방법에 기초한 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제17항에 있어서,

상기 적어도 하나의 모듈을 블록들로 분할하는 단계는 1 내지 2 kByte의 크기를 갖는 블록들로 분할하는 단계를 포함하며, 상기 블록들을 전송하는 단계는 윈도우 프로토콜을 관리하는 단계를 포함하고, 윈도우 크기는 상기 적어도 하나의 운영 소프트웨어 모듈이 분할된 블록들의 크기에 매칭되는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제17항에 있어서,

상기 요소들의 세트를 상기 무선 단말에 설치하기 전에, 라이센스가 요구되는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제14항에 있어서,

상기 무선 단말(UE/MS)로 다운로드되기 전에, 상기 적어도 하나의 운영 소프트웨어 모듈은 키로 암호화되는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제14항에 있어서,

적어도 두 세트의 운영 소프트웨어 모듈들을 상기 재구성가능한 무선 단말(UE/MS)에 저장하는 단계를 더 포함하는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제14항에 있어서,

상기 적어도 하나의 모듈들의 세트 중 적어도 하나의 모듈을 다운로드하는 단계는,

적어도 부분적으로 상기 무선 단말(MS)을 다른 통신 시스템으로 구성하는 운영 소프트웨어 모듈들의 세트를 다운로드하는 단계를 포함하는 것을 특징으로 하는 적어도 하나의 재구성가능한 무선 단말의 구성 방법.
제14항 내지 제26항 중 어느 한 항에 따른 방법을 수행하는 것에 의하여 구성되는 재구성가능한 무선 단말(UE/MS).
제14항 내지 제26항 중 어느 한 항에 따른 방법을 수행하는 것에 의하여 재구성가능한 무선 단말(UE/MS)을 구성하는 서버 엔터티(OTA 서버)를 포함하는 네트워크 노드.
제14항 내지 제26항 중 어느 한 항에 따른 단계들을 수행하기 위한 소프트웨어 코드 부분들을 포함하는 컴퓨터 프로그램을 기록한 컴퓨터 판독가능한 기록매체.