수동형 광 가입자 망을 구성하는 광 가입자 단말 및 광 가입자 단말의 소프트웨어 이미지 업데이트 방법{ONT in gigabit-capable passive optical network and method of updating the ONT software image}
기가비트 수동형 광 가입자 망(Gigabit-capable Passive Optical Network, GPON)에 관한 것으로, 특히 수동형 광 가입자 망을 구성하는 광 가입자 단말에서 사용될 실행 가능한 소프트웨어 이미지를 업데이트하는 방법에 관한 것이다. 여기서 광 가입자 단말은 광 네트워크 단말(Optical Network Termination, ONT) 혹은 광 네트워크 유닛(Optical Network Unit, ONU)으로서, 이하에서는 ONT로 지칭하기로 한다.
ITU-T G.984.4 OMCI(ONT Management Control and Interface) 권고안에서는 광 회선 단말(Optical Line Termination, OLT)이 원격으로 OMCI 채널을 통해 ONT 소프트웨어 이미지를 업데이트하는 방법에 대해 기술하고 있다. OMCI 권고안에 따르면, ONT의 OMCI 프로토콜 소프트웨어는 소프트웨어 이미지(software image) 관리를 위해 소프트웨어 이미지 관리 엔티티(software image ME(Managed Entity))를 두 개 생성한다. 이 관리 엔티티(ME)들은 각각 독립적으로 실행 가능한 두 개의 소프 트웨어 이미지에 관한 정보를 가지고 있다. 이 소프트웨어는 ONT 자체를 구동하기 위한 소프트웨어가 될 수 있고, ONT의 circuit pack 구동을 위한 소프트웨어가 될 수도 있다. OLT는 OMCI의 소프트웨어 이미지 관리 엔티티의 동작(action) 명령들을 이용하여 ONT에서 실행할 소프트웨어 이미지를 업데이트 및 선택할 수 있다. 소프트웨어 이미지 관리 엔티티는 ME id, Version, Is committed, Is active, Is valid 속성(attribute)으로 이루어져 있다. ME id는 생성된 ME의 instance를 구분하기 위한 식별자이다. Version은 소프트웨어 이미지의 버전 정보를 나타낸다. Is committed 속성은 소프트웨어 이미지가 committed인지 uncommitted인지를 나타낸다. 오직 Is committed 속성값이 '1'인 이미지만이 실행될 수 있으며, ONT가 가지고 있는 두 개의 이미지가 동시에 committed일 수는 없다. Is active 속성은 현재 실행되고 있는 ONT 혹은 circuit pack의 이미지가 실행 중인지를 나타낸다. Is active 속성은 Is committed 속성과 마찬가지로 두 개의 이미지의 Is active 속성값이 동시에 '1'일 수는 없다. Is valid 속성은 소프트웨어 이미지가 유효(valid) 상태인지를 나타낸다. ITU-T의 G.984.4 권고안에서는 소프트웨어 이미지의 유효성(validation) 검사 방법에 대해 다루고 있지는 않지만, 소프트웨어 이미지 전체에 대해 최소한 CRC(Cyclic Redundancy Check) 검사는 수행할 것을 권고하고 있다. OLT는 OMCI의 소프트웨어 이미지 관리 엔티티를 통해 새로운 소프트웨어 다운로드를 위한 Start download, Download section, End download 동작 명령과 소프트웨어 이미지의 load/execute를 위한 Active image, 그리고 기본적으로 실행할 소 프트웨어 이미지를 선택하기 위한 Commit image 동작 명령을 ONT에 전송할 수 있다. 소프트웨어 이미지의 업데이트를 위해 OLT와 ONT는 소프트웨어 이미지 상태(software image state)를 관리하며, 이는 ITU-T G.984.4 권고안의 소프트웨어 이미지 상태 다이어그램(Software image state diagram)에 설명되어 있다.
ITU-T G.984.4의 소프트웨어 이미지 업데이트를 위한 규격을 만족시키면서 리눅스와 같은 운영체제가 탑재되어 동작하고 있는 경우와 운영체제 없이 standalone 형태로 동작하는 경우의 ONT에서 소프트웨어 이미지를 업데이트할 수 있는 기술적 방안을 제공함을 목적으로 한다.
전술한 기술적 과제를 달성하기 위한 본 발명의 일 양상에 따른 광 가입자 단말의 소프트웨어 이미지 업데이트 방법은 업데이트를 위해 다운로드 완료된 소프트웨어 이미지에 대한 소프트웨어 이미지 관리 엔티티를 비휘발성 메모리에 저장하는 저장 단계, 소프트웨어 이미지 관리 엔티티의 저장이 완료되면 부팅을 수행하는 부팅 단계, 부팅이 수행되면 비휘발성 메모리에 저장된 소프트웨어 이미지 관리 엔티티를 해석하는 해석 단계, 해석 결과로부터 소프트웨어 이미지를 선택하는 선택 단계, 및 선택된 소프트웨어 이미지를 로드하여 실행하는 실행 단계를 포함한다. 한편, 전술한 기술적 과제를 달성하기 위한 본 발명의 일 양상에 따른 광 가입자 단말은 업데이트를 위해 다운로드된 소프트웨어 이미지들이 저장되며, 소프트웨어 이미지들에 대한 소프트웨어 이미지 관리 엔티티가 저장된 비휘발성 메모리, 및 부팅시 비휘발성 메모리에 저장된 소프트웨어 이미지 관리 엔티티를 해석하여 액티브 가능한 소프트웨어 이미지를 확인하고, 확인된 액티브 가능한 소프트웨어 이미지를 로드하여 실행하는 제어부를 포함한다.
본 발명에 따르면, ONT는 소프트웨어 이미지 업데이트 과정에서 재부팅되거나 갑작스런 재부팅 과정이 발생해도 저장된 OMCI 소프트웨어 이미지 관리 엔티티의 상태정보를 바탕으로 부팅 가능한 소프트웨어 이미지를 실행시킬 수 있다.
일반적으로 플래시 롬과 램을 가진 임베디드 시스템인 ONT의 경우, 다수의 가입자 수용을 위해 L2/L3 스위치를 사용하는 경우가 많기 때문에, 리눅스와 같은 운영체제를 사용하여 시스템을 구동한다. ONT의 소프트웨어는 커널 계층에서 동작하는 디바이스 드라이버 형태로 동작하거나, 사용자 계층에서 리눅스의 일반 어플리케이션처럼 동작한다. 따라서 소프트웨어 이미지를 업데이트한 후에 다시 실행시키려면, 디바이스 드라이버 형태인 경우는 기존의 모듈을 제거하고 새로운 모듈을 적재하는 과정이 필요하다. 이는 OMCI 소프트웨어의 동작이 아니라 운영체제에서 수행되는 동작이기 때문에, OMCI 내에서 상태를 관리할 수 없다. 또한 어플리케이션 형태의 소프트웨어인 경우도 프로그램을 종료하고 다시 실행해야 한다. 운영체제 없이 standalone 형태로 동작하는 ONT의 경우, 플래시 롬(Flash ROM)과 같은 비휘발성(non-volatile) 형태의 메모리에 두 개의 소프트웨어 이미지를 저장하고 있다가 액티브(active) 가능한 소프트웨어 이미지를 구동시켜야 한다. 따라서 ONT 소프트웨어가 운영체제 위에서 동작하거나 standalone 형태로 동작하는 경우, ONT는 부팅 초기에 두 개의 소프트웨어 이미지에 대한 정보를 필요로 하며 OMCI의 소프트웨어 이미지 관리 엔티티의 속성 정보를 바탕으로 이미지를 로딩해야 한다. 본 발명은 ITU-T G.984.4 권고안에서 기술하고 있는 소프트웨어 이미지 관리 엔티티 정보를 ONT의 비휘발성 메모리 영역에 저장하여 ONT가 이 정보를 바탕으로 소프트웨어 이미지를 실행함을 특징으로 한다. 전술한, 그리고 추가적인 본 발명의 양상들은 첨부된 도면을 참조하여 설명되는 바람직한 실시예들을 통하여 더욱 명백해질 것이다. 이하에서는 본 발명을 이러한 실시예를 통해 당업자가 용이하게 이해하고 재현할 수 있도록 상세히 설명하기로 한다. 도 1은 본 발명의 일 실시예에 따른 ONT의 블록도이며, 도 2는 특정 영역에 소프트웨어 이미지 및 소프트웨어 이미지 관리 엔티티가 저장된 비휘발성 메모리의 영역 예시도이다. ONT는 통신부(100), 비휘발성 메모리(110) 및 제어부(120)를 포함한다. 통신부(100)는 외부와의 네트워크 통신을 위한 것으로, ONT(410)는 통신부(100)를 통해 OLT와 데이터를 송수신할 수 있다. 비휘발성 메모리(110)는 플래시 롬일 수 있다. 비휘발성 메모리(110)에는 제1소프트웨어 이미지(image_0)와 제2소프트웨어 이미지(image_1)가 저장되며, 제1소프트웨어 이미지와 제2소프트웨어 이미지에 대한 소프트웨어 이미지 관리 엔티티가 저장된다. 도 2를 참조하면, address A부터는 제1소프트웨어 이미지가 저장되고, address B부터는 제2소프트웨어 이미지가 저장되며, address C부터는 소프트웨어 이미지 관리 엔티티가 저장된다. 저장되는 위치는 정해진 것은 아니며, 구현 방법에 따라 변경될 수 있다. 제어부(120)는 ONT 전반을 제어하기 위한 컨트롤러일 수 있다. 이러한 제어 부(120)는 OLT로부터 OMCI 채널을 통해 업데이트용 소프트웨어 이미지를 다운로드한다. 그리고 다운로드된 소프트웨어 이미지를 도 2와 같이 비휘발성 메모리(110)에 저장한다. 여기서 비휘발성 메모리(110)에 저장된 제1소프트웨어 이미지와 제2소프트웨어 이미지는 원본과 복사본일 수 있으며, 서로 다른 소프트웨어 이미지일 수도 있다. 또한 제어부(120)는 제1소프트웨어 이미지와 제2소프트웨어 이미지를 관리하기 위한 소프트웨어 이미지 관리 엔티티를 생성하여 비휘발성 메모리(110)에 저장한다. 일 실시예에 있어서, ONT가 리눅스와 같은 운영체제로 구동되는 시스템이면, 제어부(120)는 소프트웨어 이미지 관리 엔티티를 스크립트 파일 형태로 비휘발성 메모리(110)에 저장한다. 소프트웨어 이미지 관리 엔티티가 비휘발성 메모리(110)에 저장된 이후에, 제어부(120)는 재부팅을 수행한다. 여기서 재부팅은 OLT로부터 소프트웨어 이미지의 로드 및 실행을 위한 active image 명령에 따른 것이다. 부팅이 수행되면, 제어부(120)는 부팅 과정에서 비휘발성 메모리(110)에 저장된 소프트웨어 이미지 관리 엔티티 정보를 읽어들여 해석(parsing)을 수행한다. 제어부(120)는 해석된 정보를 바탕으로 제1소프트웨어 이미지와 제2소프트웨어 이미지 중 어느 소프트웨어 이미지를 로딩해야 하는지 결정한다. 이 결정 과정에서 제어부(120)는 commit 정보가 '1'인 이미지를 선택한다. 제어부(120)는 로딩이 결정된 소프트웨어 이미지가 저장된 메모리 영역의 시작 번지로부터 소프트웨어 이미지를 램에 로딩하여 실행한다. 이에 의해 소프트웨어 이미지가 업데이트된다. 도 3은 소프트웨어 이미지 관리 엔티티 정보를 스크립트 파일 형태로 표현한 예시도이다. 스크립트 파일(310)에는 두 개의 소프트웨어 이미지 관리 엔티티 상태(300)가 기록되어 있다. 이 스크립트 파일(310)에는 소프트웨어 이미지 상태 다이어그램의 상태를 기록한 SW_image0과 SW_image1, 그리고 ME의 속성을 기록한 Active, Committed, Valid 및 Version 정보가 들어있다. 도 4는 본 발명의 일 실시예에 따라 ONT가 운영체제로 구동되는 시스템인 경우의 소프트웨어 이미지 업데이트 절차도이다. OLT(400)는 OMCI 채널을 통해 ONT(410)로 소프트웨어 이미지를 다운로드하고, 다운로드가 완료되면 active image 동작 명령을 ONT(410)로 전송한다(단계 401). ONT(410)는 OLT(400)로부터 전송된 active image 동작 명령을 수신하고, 수신한 active image 동작 명령을 해석(parsing)한다(단계 411). Active image 동작 명령은 소프트웨어 이미지를 로딩하고 실행하라는 명령이므로, ONT(410)는 우선 소프트웨어 이미지를 관리하기 위한 소프트웨어 이미지 관리 엔티티를 스크립트 파일 형태로 비휘발성 메모리의 특정 영역에 저장한다(단계 412). 그리고 재부팅 프로세스(rebooting process)를 호출한다(단계 413). ONT(410)는 호출된 재부팅 프로세스를 실행하여 부팅 과정을 수행한다. 우선 제어부(120)는 운영체제 부팅을 수행하여 완료한다(단계 414). 운영체제 부팅을 완료한 후, ONT(410)는 비휘발성 메모리에 저장된 소프트웨어 이미지 스크립트 파일을 읽어들이고 해석한다(단계 415)(단계 416). ONT(410)는 소프트웨어 이미지 스크립트 파일을 해석한 결과로부터 비휘발성 메모리에 저장된 두 개의 소프트웨어 이미지 중 하나의 소프트웨어 이미지를 선택하는데, commit 정보가 '1'인 소프트웨어 이미지를 선택한다(단계 417). ONT(410)는 선택된 소프트웨어 이미지를 로드하고 실행한다(단계 418)(단계 419). 소프트웨어 이미지를 실행하는 과정에서, 소프트웨어 이미지가 디바이스 드라이버 형태인 경우는 모듈 적재 과정이 이루어지며, 어플리케이션 형태인 경우는 소프트웨어 이미지 자체가 실행 가능한 형태이므로 바로 실행된다. 한편, ONT의 재부팅 프로세스에 의한 부팅이 아닌 일반적인 부팅 시에도, ONT(410)는 도 4의 단계 414부터 단계 419의 부팅 과정을 따른다. 이 부팅 과정은 C 코드로 작성되거나 쉘 스크립트 혹은 펄(Perl)과 같은 스크립트 언어를 통해 작성될 수 있다. 그리고 위 부팅 과정은 리눅스가 아닌 여타의 다른 운영체제에서도 파일을 읽어들여 실행시키는 방법은 다를 수 있으나 일련의 과정들은 동일할 것이다. 도 5는 본 발명의 일 실시예에 따라 광 가입자 단말이 운영체제 없이 스탠드얼론(standalone) 형태로 구동되는 시스템인 경우의 소프트웨어 이미지 업데이트 절차도이다. OLT(500)는 OMCI 채널을 통해 ONT(510)로 소프트웨어 이미지를 다운로드하고, 다운로드가 완료되면 active image 동작 명령을 ONT(510)로 전송한다(단계 501). ONT(510)는 OLT(500)로부터 전송된 active image 동작 명령을 수신하고, 수신한 active image 동작 명령을 해석(parsing)한다(단계 511). Active image 동작 명령은 소프트웨어 이미지를 로딩하고 실행하라는 명령이므로, ONT(510)는 우선 소 프트웨어 이미지를 관리하기 위한 소프트웨어 이미지 관리 엔티티를 아스키 코드 등과 같은 형태로 비휘발성 메모리의 특정 영역에 저장한다(단계 512). 그리고 재부팅 프로세스(rebooting process)를 호출한다(단계 513). ONT(510)는 호출된 재부팅 프로세스를 실행하여 부팅 과정을 수행한다. 우선 제어부(120)는 운영체제 부팅을 수행하여 완료한다(단계 514). 운영체제 부팅을 완료한 후, ONT(510)는 하드웨어 설정을 위한 start-up code를 수행한다(단계 515). Start-up code 수행 완료 후, ONT(510)는 비휘발성 메모리에 저장된 소프트웨어 이미지 관리 엔티티 정보를 읽어들이고 해석한다(단계 516)(단계 517). ONT(510)는 소프트웨어 이미지 스크립트 파일을 해석한 결과로부터 비휘발성 메모리에 저장된 두 개의 소프트웨어 이미지 중 하나의 소프트웨어 이미지를 선택하는데, commit 정보가 '1'인 소프트웨어 이미지를 선택한다(단계 518). ONT(510)는 선택된 소프트웨어 이미지를 로드하고 실행한다(단계 519)(단계 520). 한편, ONT(510)의 재부팅 프로세스에 의한 부팅이 아닌 일반적인 부팅 시에도, ONT(510)는 도 5의 단계 514부터 단계 520의 부팅 과정을 따른다. 이 부팅 과정은 C 코드 등을 이용하여 작성될 수 있다. 이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.
도 1은 본 발명의 일 실시예에 따른 광 가입자 단말의 블록도. 도 2는 특정 영역에 소프트웨어 이미지 및 소프트웨어 이미지 관리 엔티티가 저장된 비휘발성 메모리의 영역 예시도. 도 3은 소프트웨어 이미지 관리 엔티티 정보를 스크립트 파일 형태로 표현한 예시도. 도 4는 본 발명의 일 실시예에 따라 광 가입자 단말이 운영체제로 구동되는 시스템인 경우의 소프트웨어 이미지 업데이트 절차도. 도 5는 본 발명의 일 실시예에 따라 광 가입자 단말이 운영체제 없이 스탠드얼론(standalone) 형태로 구동되는 시스템인 경우의 소프트웨어 이미지 업데이트 절차도. |
