<4D F736F F D20BCAEBBE7B3EDB9AE2DB9DAC3A2B1D92E646F63>

Transcription

1 석사학위논문 SNMP 기반의 이종 PLC 네트워크를위한 통합관리방법 박창근 ( 朴昌根 ) 전자컴퓨터공학부 ( 컴퓨터공학 ) 네트워크전공포항공과대학교대학원 2008 i

2 SNMP 기반의이종 PLC 네트워크를 위한통합관리방법 An SNMP-based Integrated Management Method for Heterogeneous Power Line Communication Networks ii

3 An SNMP-based Integrated Management Method for Heterogeneous Power Line Communication Networks By Chang-Keun Park Division of Electrical and Computer Engineering (Computer Science and Engineering) POSTECH A thesis submitted to the faculty of POSTECH in partial fulfillment of the requirements for the degree of Master of Science in the Division of Electrical and Computer Engineering (Computer Science and Engineering) Pohang, Korea June 26, 2008 Approved by Major Advisor: James Won-Ki Hong iii

4 SNMP 기반의이종 PLC 네트워크를 위한통합관리방법 박창근 위논문은포항공과대학교전자컴퓨터공학부 ( 컴 퓨터공학 ) 석사학위논문으로학위논문심사위원회를 통과하였음을인정함 년 6 월 26 일 학위논문심사위원회위원장홍원기 ( 인 ) 위원김치하 ( 인 ) 위원서영주 ( 인 ) iv

5 MCC 박창근, Chang-Keun Park, An SNMP-based Integrated Management Method for Heterogeneous Power Line Communication Networks, SNMP 기반의이종 PLC 네트워크통합관리방법, Division of Electrical and Computer Engineering (Computer Science and Engineering), 2008, 88P, Advisor: J. Won-Ki Hong, Text in Korean. ABSTRACT Power Line Communication (PLC) is an evolving technology which uses the existing power lines for data transmission. Like any other communication networks, PLC networks need to be managed for efficient use of resources and secure operations. Major PLC chipset vendors are trying to provide network management solutions using SNMP by defining their own management information, but it is not sufficient to manage heterogeneous PLC networks comprised of PLC devices from various chipset vendors. This thesis proposes a method for integrated management of heterogeneous PLC networks. It has focused on three aspects: 1) defining a common PLC MIB, the common management information for all types of PLC devices, by analyzing existing legacy PLC MIBs, 2) developing integrated PLC network management system and buiding heterogeneous PLC networks testbed to verify the proposed method, and 3) providing a PLC proxy agent for managing legacy PLC devices which do not support the common PLC MIB. This thesis can be a reference model for developing an integrated PLC network management. Further, this work can be a basis for international standardization for PLC network management. v

6 목 차 1 서론 관련연구 PLC 기술과네트워크소개 SNMP 기반의관리체계소개 관리정보모델 관리정보정의 PLC 기술동향조사 PLC Forum OPERA(Open PLC European Research Alliance) PLC J IEEE P1901 WG IEEE P1675 WG IEEE P1775 WG CEPCA(Consumer Electronics Powerline Communication Alliance) UPA(Universal Powerline Association) HomePlug UPLC(The United Power Line Council) CABA(Continental Automated Building Association) PLC 네트워크관리기술동향 기존 PLC 네트워크관리구조비교분석 기존 PLC MIB 비교분석 COMMON PLC MIB 설계 요구사항 구조 system 그룹 interface 그룹...39 vi

7 3.2.3 plcinfo 그룹 trap 그룹 통합 PLC PROXY AGENT 요구사항 구조 개발환경 확장성성능측정 성능측정방법 성능측정결과 통합 PLC NMS 요구사항 구조 동작흐름 DATABASE 설계 구현 테스트베드구축 테스트결과 결론및향후연구...73 참고문헌...75 부록 A. COMMON PLC MIB DEFINITION...79 vii

8 그림목차 그림 1. PLC 기술을이용한조명제어...6 그림 2. PLC 네트워크구조...7 그림 3. SNMP 기반의네트워크관리구조...9 그림 4. 이종 PLC 네트워크구조...24 그림 5. OPERA MIB 구조...27 그림 6. XELINE MIB 구조...28 그림 7. HOMEPLUG MIB 구조...29 그림 8. COMMON PLC MIB 구조...35 그림 9. 통합 PLC PROXY AGENT 동작...46 그림 10. 통합 PLC PROXY AGENT 구조...48 그림 11. 성능측정환경...51 그림 12. 칩셋업체별평균 RESPONSE TIME...54 그림 13. 통합 PLC NMS 구조...57 그림 14. FRONTEND MANAGER 구조...58 그림 15. BACKEND MANAGER 구조...59 그림 16. 성능데이터수집...60 그림 17. PLC 장비의구성정보설정...61 그림 18. 트랩처리...62 그림 19. DATABASE 구조...63 그림 20. 이종 PLC 네트워크테스트베드구조...68 그림 21. 통합 PLC NMS 메인화면...69 그림 22. 통합 PLC NMS 장비정보화면...70 그림 23. 통합 PLC NMS 장비설정화면...71 그림 24. 통합 PLC NMS 통계정보화면...72 viii

9 표목차 표 1. PLC 기술의응용분야...6 표 2. PLC 단체비교분석...12 표 3. OPERA의기술목표...15 표 4. PLC 네트워크관리기술동향...23 표 5. 기존 PLC MIB 비교분석...31 표 6. SYSTEMCONFTABLE...38 표 7. SYSTEMSTATISTICSTABLE...39 표 8. INTERFACETABLE...42 표 9. PLCINFOTABLE...43 표 10. TRAP 그룹...45 표 11. 칩셋업체별 GET REQUEST의 RESPONSE TIME...53 표 12. DEVICETABLE...64 표 13. STATISTICSTABLE...65 표 14. FALUTTABLE...65 표 15. USERTABLE...65 ix

10 1 서론 전력선통신 (Power Line Communication, PLC) 은전력을공급하기위해이미존재하고있는전력선에고주파데이터신호를실어서통신할수있는네트워크를구축하는것을가능하게해주는기술이다 [1, 2]. 최근에 200 Mbps PLC 장비가상용화되는등 PLC 기술이성장함에따라, 동남아시아나아프리카와같이통신인프라가구축되지않은나라에서는전력선을통신수단으로활용하여접근망 (access network) 뿐만아니라백본망 (backbone network) 까지구축하려는연구가진행중이다. 이외에원격검침서비스 (Automatic Meter Reading, AMR), 홈네트워킹서비스및 TPS(Triple Play Service) 등 PLC를이용할수있는부가서비스개발을위한많은연구가진행되고있다 [3, 4]. 위와같이 PLC를이용한다양한부가서비스가개발되고 PLC 네트워크의규모가커짐에따라 PLC 네트워크자원에대한효율적인관리의중요성은더욱커지고있다. PLC 네트워크는대체적으로다음 4개의주요업체들이제공하는칩셋 (chipset) 으로만들어진장비들로구성이되어있다 : 1) DS2 [5], 2) Intellon [6], 3) Xeline [7], 4) Panasonic [8]. 현재는각각의칩셋별로서로통신이불가능하기때문에, 칩셋업체별로소규모네트워크가독립적으로구성되어서비스가제공되고있다. 그러나최근에는기존의소규모 PLC 네트워크뿐만아니라, 한국전력공사의 U-PLC PowerIT [9] 와같은대규모 PLC 사업이진행되고있고, 동남아시아에서는 PLC를이용한대규모백본망을구축하려고하고있다. 이와같은대규모 PLC 사업으로인한네트워크는다양한칩셋의 PLC 장비들로구성된이종 PLC 네트워크 (Heterogeneous PLC Networks) 로구성될것으로예상된다. 현재각주요칩셋업체들은자체적으로 PLC 관리정보 (Management Information Base, MIB [10]) 를정의하고, EMS(Element Management System) 수준의관리시스템을제공하고있지만, 각칩셋 1

11 업체에서제공하는 PLC MIB들과관리시스템만으로는이종 PLC 네트워크를통합관리하는데부족한점이많다 [11]. 첫째, 기존의관리체계는자사의제품만을관리하기위한사적인 (proprietary) 점이많다. 즉, 기존의관리체계는자사의 PLC 네트워크특징과관리구조에맞게정의되어있기때문에자사의 PLC 네트워크이외의타사의 PLC 네트워크에바로적용하기가어렵고, 제공되는네트워크관리시스템 (Network Management System, NMS) 도자사의소규모네트워크만관리가능한 EMS 수준의관리시스템만제공하기때문에대규모네트워크를관리하기엔확장성이떨어진다. 둘째, 기존칩셋업체에서제공하는 PLC MIB들에는기능적으로중복된정보들이많다. 따라서이종 PLC 장비로구성된 PLC 네트워크를통합관리하기위해중복되는정보가많은모든 PLC MIB들을제공해야한다. 따라서 NMS의메모리공간이비효율적으로이용되고, 관리정보 (MIB) 의유지보수의복잡도가증가한다. 뿐만아니라같은기능의관리정보에대해업체별관리정보변환 (translation) 에따른로드가증가한다. 셋째, 모든 PLC 장비를관리할수있는공통관리정보가없다. 따라서 PLC 장비개발자의입장에서는자사제품의관리정보를정의하기위한개발비용및시간이증가하고, NMS 개발자의입장에서는모든 PLC 네트워크특징을고려한통합 NMS 개발에따른개발로드가증가한다. 따라서통합된관리뷰 (view) 를제공하는 NMS를개발하기어렵다. 이러한이유때문에현재개발된 PLC NMS는 SW 전문업체에의해개발되기보다는 PLC 장비업체가자사의제품만을위해자체적으로개발하여제공하고있는실정이다. 위와같은문제점을해결하기위해서는이종 PLC 네트워크를통합관리하기위한통합관리체계가필요하다. 첫째, PLC 네트워크의관리정보에대한표준화가이루어져야한다. 즉모든 PLC 장비가제 2

12 공해야할정보를 Common PLC MIB 1 으로정의하고, 그외업체들의특정한정보는각업체들의 Private MIB으로정의해야한다. 둘째, 표준화된관리정보를이용하여이종 PLC 네트워크를통합관리할수있는통합관리시스템이제공되어야한다. 마지막으로표준화된관리정보를제공하지못하는기존에설치된 PLC 장비를포용할수있는방법이제공되어야한다. 본연구에서는다양한칩셋의 PLC 장비들로구성된이종 PLC 네트워크를통합적으로관리하기위한통합관리체계에대한연구를수행하였다. 모든 PLC 장비가제공해야할공통관리정보인 Common PLC MIB [12] 을설계하고, Common PLC MIB을이용하여이종 PLC 네트워크를통합관리할수있는통합 PLC NMS [13] 를개발하였다. 뿐만아니라, Common PLC MIB을지원하지않는기존 PLC 장비까지도포용하기위한통합 PLC Proxy Agent도개발하였다 [14]. 통합 PLC Proxy Agent는 Common PLC MIB이반영되지않은기존의 PLC 장비도통합관리하기위한시스템으로, 기존 PLC MIB 기반의 SNMP [14, 15] 상호작용 (interaction) 과 Common PLC MIB 기반의 SNMP 상호작용사이의변환을수행하는 Gateway 장비이다. 본연구에서는통합 PLC Proxy Agent가관리가능한 SNMP 에이전트 (agent) 의개수를측정하기위해, SNMP 에이전트시뮬레이터 (Agent Simulator) [16] 를이용하여가상의테스트베드 (testbed) 를구축하고, SNMP 에이전트의개수를늘려가며성능항목을측정함으로써, 통합 PLC Proxy Agent의확장성 (scalability) 을검증하였다. 그리고제안한통합관리체계의실현가능성을보이기위해 DS2 모뎀, Xeline 모뎀, Common MIB PLC 모뎀으로구성된실제이종 PLC 네트워크테스트 1 Common PLC MIB 은다양한관리구조의모든 PLC 장비들이기본적으로제공해야할관리정보로, 특정업체의 PLC 장비에의존적인것이아니라, 전반적인 PLC 네트워크관리를위한관리정보. 3

13 베드를구축하고, 통합 PLC NMS를이용하여여러통합관리기능에대한테스트를수행하였다. 본논문에서는이종 PLC 네트워크의통합관리를위한통합관리체계를제시했으며, 본연구결과는이종 PLC 네트워크의통합관리를위한참조모델 (reference model) 이될수있다. 또한, Common PLC MIB의정의를포함한통합관리시스템체계는 PLC 네트워크관리기술의표준화에기여할수있다. 본논문의구성은다음과같다. 2장에서는관련연구로 PLC 네트워크와 SNMP 기반의관리체계에대해서소개한다. 또 PLC 네트워크에대한기술동향과기존 PLC 네트워크의관리동향에대해서설명한다. 3장에서는 2장에서비교분석한기존 PLC 네트워크관리체계를바탕으로설계한 Common PLC MIB에대해설명한다. 4장에서는 Common PLC MIB을지원하지않은기존 PLC 장비까지도포용하기위해제안한통합 PLC Proxy Agent에대해서설명하고, 통합 PLC Proxy Agent의확장성측면의성능측정결과를제시한다. 5장에서는 Common PLC MIB을이용하여이종 PLC 네트워크를통합관리할수있는관리시스템인통합 PLC NMS에대해설명한다. 끝으로 6장에서는결론및향후연구에대해설명한다. 4

14 2 관련연구 이장에서는 PLC 네트워크관리의관련연구로 PLC 기술과응용분야및 PLC 네트워크의구조에대해서소개한다. 또 SNMP 기반의관리체계에대해서소개하고, PLC 기술동향파악을위해 PLC 관련단체와업체에대해서소개한다. 마지막으로 PLC 네트워크관리기술동향에대해소개하고비교분석한다. 2.1 PLC 기술과네트워크소개 PLC 기술은가정이나사무실에설치되어있는전력선을통하여통신신호를 100KHz ~ 300KHz의고주파신호로바꿔실어보내고이를고주파필터를이용, 따로분리해신호를수신하는방식을말한다. 국내에서사용되는전력은 60Hz의교류신호로서가전제품은이를전력변환기를통해직류로바꿔사용하며, PLC에서의고주파신호는저출력의신호이므로일반가전기기작동에는어떠한영향도미치지않는다. PLC 기술은별도의통신선로없이구내에설치된전원콘센트를통신단자로활용할수있고, 벽에의한간섭이없다는점등의장점이있어그응용분야가풍부하다. 최근에는최대 200Mbps속도의전송기술이상용화되어낮은비용으로고속인터넷이나디지털전화등다양한고속정보통신서비스가가능하게되었으며디지털가전시대를맞아, TV, 디지털냉장고, PC, 전등등각종전자기기들을하나로연동해고속의홈오토메이션시스템을구축하고, 이를원격제어하는일도가능하게되었다. 전력회사에서는전력사용량을검침원없이원격으로검침을수행할수있으며, 전기소모가많은여름철에는직접부하제어가가능하다. 또수용가서비스를위한선진전력사업용통신망으로도활용할수있다. 표 1은 PLC의다양한응용분야를보 5

15 여준다. 응용분야자동검침에너지관리보안서비스의료경보인터넷접속홈오토메이션구내전화연결 유형전기, 가스, 수도원격검침전기사용부하제어도난, 화재, 가스누출경보감시카메라제어의료기기모니터링을통한경보서비스인터넷접속다수 PC를연결하는홈네트워킹에어컨, 냉장고, 전등, 보일러등을원격제어구내전화서비스 표 1. PLC 기술의응용분야 PLC 기술이가정에활용될경우의상황을예를통해살펴보자. 먼저조명제어시스템을사용하여모든방의조명을제어할수있다. 추가배선없이아래그림과같이신호송 / 수신을위한모듈을콘센트와연결하는것만으로도모든기능을수행할수있다. 그림 1. PLC 기술을이용한조명제어 또한휴가로장기간집을비우게될경우휴가지에서전화기를 6

16 통해집안의조명을On/Off 할수있으므로집안에사람이있는것처럼외부에보일수있어, 도난사고를예방할수도있다. 또한, 내리는비의양을감지하여창문을자동으로닫을수있다. PLC 네트워크는그림 2와같이크게고압배전선로를이용한 MV(Medium Voltage) PLC와저압배전선로를이용한 LV(Low Voltage) PLC로나눌수있다 [17]. 그림 2. PLC 네트워크구조 MV PLC는변전소에서가정앞까지오는변압기까지 22.9 kv의고압전력선을이용하고, LV PLC는변압기에서가정까지들어오는 220V의저압전력선을이용한다. PLC 네트워크는마스터 (Master) 모뎀, 슬레이브 (Slave) 모뎀, 리피터 (Repeater) 모뎀, MV/LV Gateway 등의장비들로구성되어있다 [18]. 마스터모뎀은광네트워크, xdsl이나케이블네트워크같은백본망과 PLC 네트워크를연결하기위해서사용된다. 리피터모뎀은 PLC 모뎀들사이의신호를증폭시키기위해서사용된다. 슬레이브모뎀은데스크탑등의인터넷에연결하기위한 7

17 장비와전력선을연결하기위해서사용된다. MV/LV Gateway는 LV PLC와 MV PLC를연결하기위해서사용된다. 위와같은장비들이 PLC 네트워크의관리대상이된다. PLC 네트워크운영센터에서는인터넷을통하여이와같이구축된 PLC 네트워크를관리할수있어야한다. 2.2 SNMP 기반의관리체계소개 SNMP(Simple Network Management Protocol) [14, 15] 는 IETF(Internet Engineering Task Force) [19] 에서표준화된가장널리쓰이는네트워크관리프로토콜이다. 관리구조는그림 3과같이매니저-에이전트패러다임으로되어있다. 관리대상의장치에는 SNMP 에이전트가삽입되어서관리대상장비의정보를수집한다. 그리고 SNMP 매니저 (manager) 는네트워크운용자가장비를관리할수있도록 SNMP 에이전트 (agent) 로부터정보를수집하고처리하는기능을한다. 에이전트의정보를매니저가수집하는방법은매니저의요청에대해에이전트가응답하는방법과에이전트가매니저요청없이통보하는방법이있다. 전자를폴링 (polling) 이라고하고후자를트랩 (trap) 이라고한다. 또한폴링은요청과응답으로메시지전송이이루어지며 UDP 포트 161번을사용한다. 트랩은 UDP 포트 162번을사용하여통신을한다. 그림 3에서보는바와같이 SNMP 동작에는크게 3가지가존재한다. 첫번째는매니저가에이전트에게요청하여관리정보값을조회하는동작인 Get과 GetNext 이고, 두번째는매니저가에이전트에게값을보내어에이전트값을변경하는동작인 Set이있다. 마지막으로에이전트에서이벤트가발생하면요청없이매니저로통보하는트랩이존재한다. 8

18 그림 3. SNMP 기반의네트워크관리구조 관리정보모델관리할정보를나타내는방식으로관리정보정의를위한문법이라고할수있다. SNMP에서는 SMI(Structure of Management Information) [20] 에이를정의하고있다. SMI는 SNMP에서사용하기위한관리정보모델링방법을 ASN.1(Abstract Syntax Notation One) [21] 으로정의해놓은것으로매크로와데이터타입을정의하고있다. SMI의정의에따라서모든관리정보는계층적인트리구조를가지고있으며트리의마지막노드만이실제데이터를가지는노드이다. 데이터는단순스칼라값을가지거나스칼라값의이차원배열인단순한테이블만을지원하다. 각노드는고유한 OID(Object Identifier) 에의해구분된다. 9

19 2.2.2 관리정보정의실제로관리할대상정보를정의하는것으로 SNMP에서는관리정보를 MIB(Management Information Base) 로나타낸다. 즉 SNMP SMI를이용하여어떤것을관리할것인가하는관리대상정보를정의한것이 MIB이다. MIB는모든장비에서공통적으로필요한사항을표준으로작성한표준 MIB(Standard MIB) 이있고, 각각의장비제조업체에서개별장비의관리를위해특별히정의한사설 MIB(Private MIB) 이있다. SNMPv1의표준 MIB으로는 RFC1213에정의된 MIB-II [22] 가있고, SNMPv2의표준 MIB으로는 RFC1907에정의된 SNMPv2-MIB [23] 등다양한표준이있다. 2.3 PLC 기술동향조사 이번절에서는 PLC 기술동향에대해서설명한다. 현재 PLC 관련단체들은 PLC 기술보급과 PLC 장비들의상호호환성을확보하기위해여러활동을진행중이다. 표준화측면에서, 단체표준으로는 Intellon PLC 기술을중심으로하는 HPA(Homeplug Powerline Alliance) [32] 와 DS2 PLC 기술을중심으로하는 UPA(Universal Powerline Association) [31] 가있다. 국제표준으로는 IEEE P1901 WG(Working Group) [27] 을중심으로진행중인고속 PLC 기술의물리계층과 MAC 계층의규격 (specification) 에대한국제표준안이있다. 고속 PLC에대한국제표준은 2008년 12월에나올것으로기대되고있다. 표 2는세계적으로 PLC 기술동향및표준화동향에대해알아보기위해, 총 11개의단체의설립목적, 구성및결과물을조사하고, 비교분석한것이다. PLC 단체를여러특성에따라분류해보면다음과같다. 지역별로분류해보면, PLC Forum [24] 과 OPERA [25] 는유럽을중심으로, 10

20 HomePlug [32], UPLC [33], CABA [34] 는미국을중심으로, PLC-J [26], CEPCA [30] 는일본을중심으로되어있다. 그외에 IEEE의 WG들과 UPA [31] 는표준안제정을위해전세계적으로여러단체들로구성되어있다. 목적별로분류해보면, PLC Forum과 UPA는 PLC 업체들의기술정보교류를위해서, OPERA, HomePlug, CEPCA는 PLC 기술연구와표준 SPEC을만들기위해서, IEEE WG은업계표준안을정하기위해서만들어졌다. 세분화된특정목표를가진단체들도있다. PLC-J는고속 PLC 를위해서, CABA 는홈과빌딩의자동화를위해서만들어졌다. PLC Forum OPERA PLC - J 목표 (vision) 결과물 (output) 구성 - 멤버들사이에 PLC 관련기술교류 - PLC 기술규정안제정및표준화추진 - 비즈니스모델생성 - PLC 기술연구 - PLC 기술을유럽대륙에전파 - PLC 의속도향상에필요한기술을연구 - 고속 PLC 를일본에서조기에구현 - 2 개의 WG: Marketing WG, Technical WG - 1 개의 Project: OPERA - PLC 기술에대한연구자료 - OPERA Specification - 비지니스레포트 - 기술레포트 - 고속 PLC 기술에관한문서 - 고속 PLC 기술을이 용한부가서비스에관한문서 - 고속 PLC 기술의 demonstration 활동 - 유럽을중심으로 PLC 장비업체, 공공기관등 50 개이상의멤버로구성 - 유럽을중심으로 PLC 장비업체, 공공기관등 36 개이상의멤버로구성 - 일본을중심으로 50 여업체와공공기관이 A, B 멤버로구성 IEEE P1901 WG - 고속 PLC 의물리계층과 MAC 계층의표준안을지정 년 12월에첫번째 draft specification 이나올것으로예상 - DS2, Intellon 등 30 여개의중심적인 PLC 업체들로구성 11

21 IEEE P1675 WG IEEE P1775 WG CEPCA UPA Home Plug UPLC - PLC 장비에사용되 - PLC 장비의표준안, - 30여개의중심적인는테스트및검증현재 3_V15 까지나 PLC 업체들로구성표준안지정왔고, 진행중 - PLC 의 EMC 자격요건에테스트수행 - EMC 표준안, 1st draft 검토중 - 다른통신기술과공 - PLC 장비의기술표존가능한 PLC 장비준안의업계표준지정 - 전세계의여러 PLC 표준안의일치와그 - 여러 PLC Specific 를통한 PLC 기술의 ation 들 성장촉진 - 가정을위한 PLC 의공동표준개발 - PLC 개발추진 - PLC 을통한비즈니스모델생성 - HomePlug HomePlug AV - HomePlug BPL - HomePlug C&C - PLC 을이용한상용화프로젝트 - PLC 관련법률안 - 30여개의 PLC 업체와공공기관으로구성 - 일본을중심으로여러 PLC 업체와공공기관으로구성 - 20여 PLC 업체로 구성 - 협력단체 : OPERA 및 PLC Forum 등 - 미국을중심으로 50 여개의전세계 PLC 업체로구성 - 미국을중심으로 PLC 업체들이중심멤버와보조멤버로구성 CABA - PLC 기술을이용하는홈과빌딩의자동화를위한통합시스템구축정보제공 - ihomes & Buildings Magazine 발간 - CABA 제품과서비스디렉토리제공 - 20 여개의홈네트워크업체와 PLC 업체로구성 표 2. PLC 단체비교분석 PLC Forum 1. 단체목적 PLC Forum [24] 은 PLC 기술에관심있는활동적인조직들을대표하는국제적인모임이다. 이단체의가장큰목적은멤버들사이의 PLC 관련기술의정보교류이다. 이외에도다음과같은목적이있다. 12

22 PLC Forum은 PLC 기술에대한규제안을만들어그규제안에맞는 PLC 체계가존재할수있게한다. PLC Forum 내에서비전, 문제점을공유하고, 상호호환성과표준화추진을통해, PLC 기술이시장에서성공하도록한다. 또한, 멤버들의적절한사업모델또는비즈니스모델을생성하도록지원한다. PLC Forum은 Event 활동, 정보보급활동, 출판활동등의마케팅을통해 PLC의잠재성을널리알린다. 2. 단체구성 PLC forum은 2000년에기존의 2개의모임이합쳐져만들어졌다. 그이후로멤버가계속늘어서, 현재는 50 여개의멤버로구성되어있다. 멤버는 DS2, Intellon, Mitsubishi, Avisto Telecom과같은 PLC 장비업체 (manufactures) 와 EDF(Electricité de France), MOSENERGO, SENELEC 과같은공공기관 (utilities), CEPRI(China Electric Power Research Institute), PLC-J, UPLC와같은 PLC 관련단체로구성되어있다. 3. 결과물 2개의 Working Group(A Marketing WG, A Technical & Regulatory WG) 과 1개의 Project(OPERA) 를진행하고있다 OPERA(Open PLC European Research Alliance) 1. 단체목적 OPERA [25] 는새로운 PLC 통합네트워크를위한연구모임 (Research Alliance) 이다. OPERA는 2004년 1월부터시작된 4년기간의프로젝트이다. 2개의단계로구성되어있고, 각각의단계는 2년기간을갖는다. OPERA의가장큰목적은현재 PLC 기술의한계를극복하기위해필요한연구를수행하고, PLC 기술을유럽대륙에전파하는것이다. OPERA의정책적인목적은유럽시민들에게전력선을이용하 13

23 여값싼인터넷서비스를제공하는것이다. 이외에도기술적인목적은다음과같다. 현재 PLC 시스템들의개선 사용자가장소에구애받지않고, PLC 네트워크를이용가능 PLC 기술을통해제공할수있는다양한서비스개발 PLC 시스템들의표준화아래표 3은 OPERA가제시한분야별현재 PLC 기술의상태와 OPERA의목표가아래표에잘나타나있다. 현재상태 OPERA 목표 속도 45 Mbps 이상 200 Mbps 이상 시스템 Proprietary 솔루션 표준 plug & play 솔루션 멀티 - 벤더솔루션 표준안없음국제표준 LV 설치비용고비용저비용 MV 커플링기법 Capacitive Inductive 사용자적용범위 80% - 90% 100% EMC Standard & Compliance 국가표준 유럽표준 AV 서비스테스트단계제공 사용자친숙도 Not user friendly User friendly 댁내 PLC 호환수준비보장보장 14

24 백본망통합수준비효율적효율적 표 3. OPERA 의기술목표 2. 단체구성 OPERA는 PLC 기술과관련있는 36개의조직으로구성되어있다. 유럽대륙뿐만아니라다른대륙의조직들도포함되어있다. 대표적인멤버구성은다음과같다. Diseño de Sistemas en Silicio, S.A. (DS2) Eichhoff GmbH Electricité De France Endesa Ingeniería de Telecomunicaciones, S.L. Endesa Net Factory ENEL Distribuzione SpA Mitsubishi Electric Information Technology PLCforum Association Power Plus Communications AG Yitran Communications S.A. Ltd 3. 결과물 OPERA 시스템표준안 (v1, v2), PLC 시스템의요구사항에관한문서, 비지니스레포트, 기술레포트등다양한문서들을제공하고있다. 이외의 PLC 기술에대해연구한자료들이홈페이지에링크되어있다 PLC J 1. 단체목적 PLC-J [26] 의목적은기존의시스템들과공존할수있는기술과 15

25 PLC의속도향상에필요한기술을고안하여, 고속 PLC를일본에서조기에구현하는것이다. PLC-J의활동분야는다음과같다. 고속 PLC 의기술적인표준안검토 고속 PLC 의기술검토 고속 PLC 실현을위한방법구현 기존의무선통신시스템과공존할수있는방법에대한검토 고속 PLC 기술홍보와교육활동 2. 단체구성 PLC-J는 2003년 3월 1일에설립되었고, 두종류의멤버로구성되어있다. 13개의 A 멤버와 36개의 B 멤버로이루어져있다. A 멤버는 PLC-J에기술적으로공헌할수있는법인조직으로투표할권리와운영진들의모임에참가할수있는멤버이다. FUJITSU, Hitachi, Mitsubishi 등의기업으로구성되어있다. B 멤버는 PLC-J의목적에부합하는법인조직으로미팅에참가할수있는멤버이다. POWEREDCOM, SEGA, ALPS 등의기업으로구성되어있다. 3. 결과물 PLC-J의결과물은고속 PLC 기술에관한문서, 고속 PLC 기술을이용한부가서비스에관한문서, 고속 PLC 기술의 demonstration 활동등이있다 IEEE P1901 WG 1. 단체목적 IEEE P1901 WG [27] 의목적은 Access PLC와 in-home PLC의공존과상호운용을위한, 하나또는여러가지의물리계층과 MAC계층의표준안을지정하는것이다. 즉, 고속 PLC 장비의 MAC과물리계층의 16

26 표준을지정하는것이다. 이표준안은거의모든종류의 PLC 장비에적용될것이다. 이표준안은다양한 PLC 장비사이에공존과상호운용을위한메커니즘을정의하고, 적절한대역폭과 QoS를보장함으로써, 모든종류의 PLC 장비에의해 PLC 채널이효율적으로사용되게하는것에중점을두고있다. 또한이표준안은다양한보안문제도다루고있다. 2. 단체구성 IEEE P1901 WG은다양한 PLC 기업과단체로구성되어있다. 기업멤버로는 Ambient, DS2, Intellon, Current Technologies, Corinex, Mitsubishi, Intel 등이있고, 단체멤버로는 CEPCA, HomePlug Powerline Alliance, Universal Powerline Association 등이있다. 3. 결과물 2008 년 12 월, 첫번째 draft specification 이나올것으로예상된다 IEEE P1675 WG 1. 단체목적 IEEE P1675 WG [28] 의목적은 PLC 장비에사용되는테스팅및검증의표준과표준에맞는지확인하기위한표준설치방법을제공하는것이다. 그러나이표준안은 PLC 장비내부작동원리와관련된요소는포함하지않는다. 2. 단체구성 IEEE P1675 WG은 30여개의중심적인 PLC 업체들로구성되어있다. 17

27 3. 결과물 IEEE P1675 WG의결과물은 PLC 장비의표준안이다. 이는현재 3_V15까지나왔고, 계속진행중이다 IEEE P1775 WG 1. 단체목적 IEEE P1775 WG [29] 의목적은 PLC 시스템이 EMC(Electromagnetic Compatibility) 자격요건에일치하는지를테스트하고, EMC 의측정절차를정의하는것이다. 표준안은현재존재하는여러각국가들의표준안을참조할것이고, 구체적인대역폭을제공하지않는다. 2. 단체구성 IEEE P1775 WG은 30여개의중심적인 PLC 업체와공공기관으로구성되어있다. 3. 결과물 EMC 표준의첫번째 draft 를검토하는중이다 CEPCA(Consumer Electronics Powerline Communication Alliance) 1. 단체목적 CEPCA [30] 는 2005년 5월 20일에설립된비영리조직이다. CEPCA의목적은같은주파수대역을사용하지만다른기술을사용하는 PLC 시스템사이의방해요소를제거하고, 서로다른 PLC 시스 18

28 템이공존하고최상의성능을달성하는것을가능하게하는기술을문서로만들고표준화하는것이다. 2. 단체구성 CEPCA는 Hitachi, Sony, Panasonic, Toshiba 등의 프로모터 (promoter) 멤버와 Delta Electronics, Mitsubishi, Xeline과같은공헌자 (contributor) 멤버로구성되어있다. 3. 결과물 CEPCA의결과물은 20005년 11월에완성된기술표준안과 2005년 4월에발표한 Evaluation and field trials 문서이다. 2007년에는 IEEE P1901 WG과 PLC-J에 CEPCA의표준제안서를제출하였다 UPA(Universal Powerline Association) 1. 단체목적 UPA [31] 는 2004년 5월에설립된 PLC 회사를연합하여대표하는국제비영리무역협회이다. UPA는빠르게발전중인 PLC 시장에서세계표준안및규정이일치되도록노력하고있다. UPA의목적은다음과같다. 첫째, 통일된표준안을제공함으로써표준안을따르는 UPA 제품들을만들수있게하여 PLC 기술의성장을촉진시킨다. 둘째, 고성능을보장하고 PLC 어플리케이션에대한스펙트럼사용률을최대화한다. 마지막으로, 상호운영성, 보안및공존을기반으로하는개방형표준안을제공함으로서모든 PLC 관련업체가고객의기대에부응할수있는기회를제공한다. 2. 단체구성 19

29 UPA는 AcBel Polytech, Ambient, Corinex, DS2, Ilevo와같은기업멤버와 OPERA, UPLC, PLC Forum과같은협력단체로구성되어있다. 3. 결과물 UPA는 2가지 PLC 관련표준안문서 (Access/In-home & In-home/In-home coexistence mechanism General specifications Version 1.0, Digital Home Standard Market Requirements) 를발표하였고, IEEE P1901 WG에 3가지표준문서 (Coexistence Functional and Technical Requirements, Access Functional and Technical Requirements, In-home Cluster Requirements) 를제출하였다 HomePlug 1. 단체목적 HomePlug [32] 는북미지역의 PLC 기술에관련된단체로가정을위한 PLC 네트워크의공동표준개발을위해 2000년 3월결성된단체이다. 2. 단체구성 Homeplug는 Linksys, Intel, Motorola, Samsung, Sharp, Sony와같은스폰서 (sponsor) 멤버와 Intellon, Arkados, Conexant와같은공헌자 (contributor) 멤버와 Current Technologies, Texas Instruments, Yitran Communications, Ariane Controls 등과같은참가자 (participant) 멤버와 CABA, UPLC와같은협력단체로구성되어있다. 3. 결과물 Homeplug 는여러가지 PLC 표준안을발표하였다. 첫번째는홈 20

30 네트워크에중점을둔 HomePlug 1.0이다. 이는 Intellon사의 PowerPacket 기술을기반기술로선정하여 500개의가정을대상으로서비스를한후, 2001년 6월에최종규격을발표하였다. 두번째는가정내에서다양한실시간멀티미디어통신에중점을둔 HomePlug AV 이다. 이는 200 Mbps의전송속도를제공하는기술로, 2005년 12월에최종규격을발표하였다. 세번째는기존의광대역망과 PLC 네트워크연결하는것에중점을둔 HomePlug BPL이다. 이는 2006년상반기에책정을완료하여현재개발중에있다. 마지막은조명의온 / 오프등가정내의각종기기의제어를목적으로하는 HomePlug Control & Command이다. 이는 2007년 10월에최종규격을발표하였다 UPLC(The United Power Line Council) 1. 단체목적 UPLC [33] 는미국내배전회사를중심으로 PLC 초고속인터넷사업을촉진하고이를보급하기위한단체이다. UPLC는여러배전회사를중심으로활발한시범사업을진행중에있으며몇개배전회사를중심으로상용서비스를일부시행중이다. UPLC는사업기회 (Business Opportunities), 상호호환성 (Technical Operability) 등의전략분야에중심을두고있다. 2. 단체구성 UPLC는 Ambient, Current Technologies, DS2, IBM, Mitsubishi 등의중심 (principal) 멤버와 Austin Energy, BPL Global, Motorola, Broadband Energy Networks 등의보조 (associate) 멤버로구성되어있다. 3. 결과물 UPLC 는 PLC 를이용한상용화프로젝트및법률보완등을주 21

31 도하고있다. FCC(Federal Communications Commission) 에 PLC 관련법률안을제출했다 CABA(Continental Automated Building Association) 1. 단체목적 CABA [34] 는북미지역의홈과빌딩자동화와관련된전문적인정보와교육기회를제공하는비영리단체로서, 홈과빌딩자동화를제공하는통합시스템구축에대한리소스및정보를제공하는것을목적으로하고있다. 이를위해홈과빌딩자동화와관련한정보교류와토론을위한포럼을제공하고, 홈과빌딩자동화와관련된프로토콜과표준의상호운용성을장려하고촉진한다. 2. 단체구성 CABA는 Bell Canada, Bell-Northern Research, Ontario Hydro, Hydro-Québec, Consumers Gas 등과같은 20여개의홈네트워크업체와 PLC 업체로구성되어있다. 3. 결과물 CABA는홈과빌딩자동화기술경향에따른정보와최신연구결과를제공하는 ihomes & Buildings Magazine을발간하고, CARA 멤버의제품과서비스및표준안을포함하는상품디렉토리제공한다. 2.4 PLC 네트워크관리기술동향 이번장에서는 PLC 네트워크관리기술동향에대해서설명한다. 기존 PLC 칩셋업체와단체들의 PLC 네트워크관리체계에대해서조사하고비교분석한다. DS2(OPERA), Intellon(Homeplug) 및 Xeline의 3 22

32 개의 PLC 칩셋업체에대해서관리구조와관리정보 (MIB) 대해서비교분석한다. 표 4는 PLC 네트워크관리기술동향을보여주고있다. 관리프로토콜관리정보관리구조 Xeline SNMP Xeline Private MIB SNMP Proxy Agent DS2 (OPERA) Intellon (HomePlug) SNMP OPERA Private MIB SNMP Agent SNMP HomePlug Private MIB SNMP Proxy Agent Panasonic SNMP In Progress In Progress 표 4. PLC 네트워크관리기술동향 현재 PLC 네트워크는대체적으로 DS2, Intellon, Xeline, Panasonic, 4개의주요업체들이제공하는칩셋으로만들어진장비들로구성되어있다. 4개의업체모두 SNMP 기반의 PLC 네트워크관리체계를구축했거나계획하고있다. DS2(OPERA) 와 Xeline은자체적으로 Private MIB을정의하였고, 자사의 PLC 장비를위한 SNMP 에이전트를독자적으로개발하여관리기능을제공하고있고, EMS 수준의관리시스템도함께제공하고있다. 반면 Intellon(Homeplug) 과 Panasonic은그들의 PLC 장비를위한관리정보를정의하였지만, Private MIB 형태로는정의하지못하였고, 자사의 PLC 장비를위한 SNMP 에이전트를제공하기위해현재개발중에있다 기존 PLC 네트워크관리구조비교분석 그림 4는 DS2(OPERA), Intellon(Homeplug), Xeline, 3개업체의 PLC 장비로구축된이종 PLC 네트워크를보여준다. 23

33 그림 4. 이종 PLC 네트워크구조 Xeline 네트워크는마스터-슬레이브구조로마스터 (master) 모뎀과슬레이브 (slave) 모뎀으로구성되어있다 [35]. 거리가먼경우에슬레이브모뎀이리피터 (repeater) 모뎀기능까지할수있다. Xeline의관리구조는각 PLC 장비가 SNMP 에이전트 (agent) 를탑재하고있지않기때문에, SNMP 매니저와 PLC 모뎀사이에 EU 200B 라는프록시에이전트 (proxy agent) 를두어서관리가이루어진다. 프록시에이전트는관리매니저로부터받은 SNMP 메시지를 PLC 모뎀에서제공하는사적인 (proprietary) 메시지로변환시켜주는역할을수행한다. OPERA 네트워크는기본적으로 1개또는그이상의 PLC 셀 24

34 (cell) 로구성된다 [36]. PLC 셀은 MV 셀과 LV 셀로나눌수있는데, MV 셀은링 (ring) 구조로 1개이상의 MV 노드 (node) 로구성되어있다. LV 셀은 1개의 Head End(HE) 와여러개의 Repeater(REP) 와 Customer Premises Equipment(CPE) 로구성된다. OPERA PLC 네트워크는링구조의광통신 (Optic Fiber) 나 MV-PLC를이용하여, 넓은망을구축할수있고, LV 셀내에서는마스터-슬레이브구조로네트워크가구성된다. LV 셀은관리대상의기본단위가된다. HE는 PLC 셀을제어하는핵심노드이며직접연결된모든노드들의마스터모뎀역할을담당한다. 예를들면 QoS 자원의할당을 HE에서수행한다. REP는신호를중개해주는역할과증폭시켜주는리피터모뎀역할을담당하며 HE나다른 REP에연결되어있다. 이때 HE에게는마스터모뎀역할을하고, 다른 REP에게는마스터모뎀또는슬레이브모뎀역할을수행한다. CPE는고객의집에설치되는슬레이브모뎀이다. OPERA의관리구조는모든 PLC 장비들이 IP 어드레스와 SNMP 에이전트를탑재하고있기때문에, SNMP 매니저에의해 PLC 모뎀의관리가직접적으로이루어진다. Homeplug 네트워크는셀기반으로한개이상의셀로구성되어있다 [37]. 셀은 Core 셀 (cell), AV Sub 셀 (cell), BPL Sub 셀 (cell) 로구성되어있다. Core 셀은같은 Encryption Key를사용하는그룹으로 Head End(HE), Repeater(RP), Network Terminal Unit(NTU) 로구성되어있다. AV Sub 셀은 AV protocol 기반의셀로, NTU를통해서복수의 AV-CPE(In-home CPE) 는 Core 셀에연결되어있다. BPL Sub 셀은 BPL protocol 기반의셀로, NTU를통해서복수의 BPL-CPE(Access CPE) 는 Core 셀에연결되어있다. Homeplug의관리구조는 Head End 장비가셀내의장비를위한프록시에이전트를가지고있는 SNMP 프록시에이전트관리구조이다. SNMP 프록시에이전트는 SNMP 메세지를 MME(Management Messae Entry) 2 로번역해준다. 2 HE 와 Station 사이에주고받는 Management Message Entry Data 25

35 2.4.2 기존 PLC MIB 비교분석 PLC 장비를관리하기위해서는해당장비의관리정보가정의되어야한다. 현재는 PLC 기술의표준안도나오지않은상황에서, PLC 장비를위한표준 MIB은아직정의되지않았지만, PLC 관련단체나업체들은자신들의장비를관리하기위해각자 Private MIB을정의하고있다. 이번절에서는기존 PLC MIB 들에대해서소개하고, 비교분석한다. 이절에서논의된기존 PLC MIB 들의비교분석결과는 Common PLC MIB을설계하는데기초자료가된다. OPERA MIB [36] 은스페인의 DS2사가주축인유럽의 PLC 표준화단체인 OPERA에서 OPERA 표준을따르는 PLC 장비를위한관리정보를정의한것이다. ROOT OID는 이고총 10개의하위그룹으로구성되어있다. 전체적인구조는그림 5와같다. plsystem은 PLC 시스템의일반적인정보를포함하는그룹이고, plbasic 은일반적인전력선구성정보에대한그룹이다. plphy은물리계층에관한정보를, plmac은 MAC 계층에관한정보를가지고있다. plqos 는전력선링크의 QoS에관한정보를가지고있고, plovlan는 VLAN에관한정보를가지고있다. plstatistics는성능통계정보인 Counter 정보에대한그룹이고, pltraps는 Trap에관한정보로이루어져있다. plstp는 spanning tree protocol에관한정보를, plsecurtiy는보안에관한정보를가지고있다. OPERA MIB은 SNMP 에이전트관리구조를가정하고있기때문에, 프록시에이전트구조의 PLC 네트워크를관리할수없다는문제점이있다. 26

36 그림 5. OPERA MIB 구조 Xeline MIB [38] 은앞에서설명한 LV-PL를이용한댁내인터넷가입자망시스템인 XPAS-200B System의모뎀들을관리하기위한 MIB 이다. Root OID는 이고, 전체적인구조는그림 6과같다. Xeline MIB의특징은각제품군별로독립된 MIB tree를가지고있다는것이다. 이중에서실질적으로현재 PLC 시스템들을관리하기위한정보는 xelinexpas200bmodule 과 xelineeu200bmodule에정의되어있다. xelinexpas200bmodule은 XPAS 200B System을구성하고있는 PLC 모뎀의정보를포함하고있고, xelineeu200bmodule은프록시에이전트인 EU- 200B System의정보를포함하고있다. Xeline PLC 네트워크를구성하는장비들은 SNMP 에이전트를탑재하고있지않기때문에 EU-200B 라는장비내의프록시에이전트를통해서관리가이루어진 27

37 다. Xeline MIB은 SNMP를통해관리되면위험한보안정보와자사의제품에특화된관리정보를너무많이포함하고있고, 하나의 MIB value에복수의관리정보가포함되어있는등의문제점이있다. 그림 6. Xeline MIB 구조 Homeplug MIB [37] 은미국의 Intellon 사가주축인북미의 PLC 표준화단체인 Homeplug에서 Homeplug 표준을따르는 PLC 장비를위한관리정보를정의한것이다. 아직 MIB Definition 형태로정의되지않았기때문에, OID 정보는없다. 그림 7은 Homeplug MIB의구조를보여준다. Homeplug MIB은네트워크관리기능별로 6개그룹으로구성되어있다. Inventory 그룹은 PLC 장비와 PLC 네트워크 Topology 의 Discovery 정보를포함하고있고, Alarm 그룹은발생할수있는 Alarm 에관한정보로 Alarm MIB(RFC 3877) 을이용하였다. Configuration 그룹은 PLC 장비설정정보를포함하고있고, Service Provisioning 그룹은 28

38 Provisioning traffic shaping parameters 에대한정보를포함하고있다. Performance 그룹은장비의성능, 통계정보를포함하고있고, Security 는 join Key 값과같은보안관련정보를포함하고있다. 그림 7. Homeplug MIB 구조 29

39 표 5는 OPERA MIB, Homeplug MIB, Xeline MIB을구조, 관리범위, 관리구조, 관리기능 (FCAPS) 별로비교분석한것이다. OPERA MIB Homeplug MIB Xeline MIB 목적구조관리범위관리구조 OPERA 장비가제공해야할관리정보정의 Homeplug장비가제공해야할관리정보정의 자사제품 (XPAS-200B) 을관리하기위한 MIB 정의 10개의 Sub 그룹 6개의 Sub 그룹 9개의 Sub 그룹 LV-PLC 와 MV-PLC LV-PLC 와 MV-PLC LV-PLC 로구성된 구성된 OPERA 망의모든 구성된 PLC 망의모든 XPAS-200B PLC 망의 장비 장비 모든장비 PLC 장비에 SNMP PLC 장비에 SNMP 모든 PLC 장비에 SNMP 에이전트가탑재되지않는 에이전트가탑재되지않는 에이전트탑재 프록시에이전트구조 프록시에이전트구조 DeviceInfoTable 의 구성관리 plsystemtable의 plsyscard 정보 plmacconnected-node stable정보 plmacslavetable 정보 Inventoryp Group의 InvStaTable의정보 Configuration Group의 CfgStaGroup의정보 StationID DeviceInfoTable의 LinkedStationID 와EURegistration의 MACArray EUManagementTable의 ManagementMAC 장 XPAS200BTrapGroup 의 애관 pltrapsgroups 의정보 Alarm Group 의정보 정보 EU200BTrapGroup의 리 정보 30

40 성 능 plstaticstable 정보 Performance Group 의 NodeInfoTable 의정보 관 plphygroup 의정보 정보 InterfaceTable 의정보 리 보안관리 plsecurity Group 의정보 Security Group 의정보 DeviceInfoTable의 GroupID ( 네트워크참여 Key값역할 ) 업 원격업그레이드지원 원격업그레이드지원 원격업그레이드지원 그 plsystemtable 의 Configuration Group 의 RemoteUpgradeTable 의 레 plsysupgradestatus 와 CfgStaSWGroup 의정보 정보 이 plsysupdate 드 표 5. 기존 PLC MIB 비교분석 기존의관리체계는모두 SNMP 를사용하지만관리구조가다르고, 자사의 PLC 장비만을관리하기위해서정의되었기때문에관리정보측면에서서로다른내용과구조를가지고있다. 예를들어, SNMP 프록시에이전트구조를가진 Homeplug MIB과 Xeline MIB은 System의기본정보를가진 Table의 Index가 MAC Address 이지만, SNMP 에이전트관리구조를가진 OPERA MIB은 System의기본정보를가진 Table의 Index를 IP Address로가정하고있다. 그러나 PLC 장비의기본정보와구성정보, 성능정보, 장애정보등의네트워크관리기능적인측면에서는공통적인정보를가지고있다. PLC 장비의기본정보측면에서는 MAC Address, NodeType( 마스터, 슬레이브, 리피터 ), 상태 (status) 등의공통정보가있다. 구성정보측면에서는마스터모뎀의 MAC Address, 연결된노드의개수등의연결정보와 AGCGain 값, ToneMAP 등의 PLC 기술관련설정정보등이있 31

41 다. 성능관리정보측면에서는송수신속도, 송수신데이타양, 전송실패패킷수등의통계정보와 BPS(bits per symbol) 3 와같은 PLC 기술과관련된성능정보등이있다. 장애관리측면에서는 PLC 모뎀의상태가변화하는경우알려주는 Trap 정보등이있다. 이외에도원격업그레이드정보, 보안정보등과같은비슷한기능을수행하는공통정보가있다. 3 symbol 당실을수있는 bit 의수, PLC 통신은 noise 가심하기때문에, noise 상태에따라 symbol 당실을수있는 bit 의수가시간에따라변함 32

42 3 Common PLC MIB 설계 기존 PLC 관리체계를이용하여이종 PLC 네트워크를관리하기에는서론에제시한많은문제점이있다. 이를해결하기위해서는관리정보의표준화가이루어져야한다. 즉모든 PLC 장비가제공해야할정보는 Common PLC MIB으로정하고, 그외의업체들의특수한 (specific) 정보는각업체들의 private MIB으로정의해야한다. 이장에서는 2장에서기존 PLC 네트워크관리체계중관리정보에대해비교분석한내용을바탕으로설계한 Common PLC MIB의요구사항과구조및내용에대해서설명한다. 앞에서분석한기존 PLC MIB 들은각칩셋업체별로통신기술의세부내용과관리구조가다르기때문에, 서로다른정보를가지고있다. 하지만 MIB 노드의이름만다를뿐, PLC 네트워크를관리하기위한기능적으로서로비슷한공통관리정보를많이포함하고있음을알수있다. 이결과를바탕으로 Common PLC MIB의요구사항을도출하고설계한다. 관리자는 Common PLC MIB을이용하여그림 4와같은서로다른관리구조를가진이종 PLC 네트워크를통합적으로관리할수있어야한다. Common PLC MIB은다양한관리구조의모든 PLC 장비들이기본적으로제공해야할관리정보로이루어져있다. 즉, 특정업체의 PLC 장비에의존적인것이아니라전반적인 PLC 네트워크관리를위한관리정보이다. 3.1 요구사항 우리가정의할 Common PLC MIB은다양한칩셋업체의 PLC 장비로구성된일반적인 PLC 네트워크의관리정보를포함해야한다. 33

43 따라서각회사의특수한정보는 private MIB으로정의되고, Common PLC MIB은모든 PLC 장비에적용될수있는공통정보만을포함해야한다. 또각 PLC 장비에 SNMP 에이전트가탑재한관리구조와프록시에이전트를사용하는모든구조를포함할수있어야한다. Common PLC MIB의요구사항은다음과같다. 1. 프록시에이전트관리구조의네트워크인경우는프록시에이전트이외의 PLC 장비들이 MIB-II의정보를지원할수없기때문에, 일반적인통신망관리정보인 RFC 1213에정의된 MIB-II의관리정보를기본적으로포함해야한다. 2. 모든 PLC 장비를설정할수있는공통시스템구성정보를포함해야한다. 3. PLC 장비의장애상태와원인을판단을위한정보를포함해야한다. 4. PLC 인터페이스의장애상태를판단할수있는성능정보 ( 예 : TxBPS, RxBPS) 를포함해야한다. 5. 신속한장애경고를위한트랩 (trap) 이정의되고트랩의발생기준인임계치 (threshold) 정보를포함해야한다. 6. 전체적인망구조를보여주기위한장비들간의연결정보를포함해야한다. 3.2 구조 Common PLC MIB 의 ROOT OID는 이고총 4개의하위그룹으로구성되어있다. 전체적인구조는그림 8과같다. 34

44 그림 8. Common PLC MIB 구조 system 그룹 System 그룹은 MAC Address, NodeType, 시스템의상태 (status) 등시스템에대한일반적인모든정보를담고있다. 프록시에이전트관리구조일경우, SNMP 에이전트를포함하지않는복수의 PLC 장비정보를포함하기위해, table 형태로정의하였다. 폴링의효율성을증가시키기위하여, 정적인시스템설정에관한정보를담고있는 systemconftable과동적인시스템통계적인정보를담고있는 systemstatisticstable로나누어정의하였다. systemconftable의자세한정보는표 6에, systemstatisticstable의자세한정보는표 7에정리하였다. 35

45 Table Field Type Access Description &Entry systemconf sysconfdeviceindexmb Unsigned32 Not System 의 MAC Table (Primary Key) accessible Address 의상위 3 ( ( ) Byte ) sysconfdeviceindexlb Unsigned32 Not System 의 MAC systemconfe (Primary Key) accessible Address 의하위 ntry ( ) 3 Byte ( sysdescr Display READ 하드웨어, OS 타입 ) ( ) String ONLY 등엔티티에대한 설명 sysobjectid OBJECT READ 엔티티의포함되 ( ) IDENTIFIER ONLY 는전산망관리 서브시스템제공 자의권한구별 sysuptime TimeTicks READ 시스템의전산망 ( ) ONLY 관리부분이마지 막으로재초기화 된이후의시간 syscontact Display READ/ 피관리노드를위 ( ) String WRITE 해접촉할사람의 구별과이사람과 접촉하는방법에 관한정보 sysname Display READ/ 피관리노드를위 ( ) String WRITE 해승인된이름 syslocation Display READ/ 노드의물리적인 ( ) String WRITE 위치 sysservice Unsigned32 READ 해당엔티티가주 36

46 ( ) ONLY 로제공하는서비스의집합을가리키는값 (ex. S/W=64) sysnodetype Unsigned32 READ/ System Node 의 ( ) WRITE Type (2 Digit 로 표현 (1Digit 는 Type, 1Digit 는 RepeaterEnable 상 태 ) sysfwversion Display READ System 의 ( ) String ONLY Firmware Version sysreset Unsigned32 READ/ System Reset ( ) WRITE sysfactoryreset Unsigned32 READ/ System ( ) WRITE FactoryReset sysstatus INTEGER READ/ System 의상태 ( ) WRITE Type ( Active(0), Pending(1), Fault(2), Unregistered(3), UnregisteredFault( 4), Unauthorized(5) ) sysrtsctsenable Unsigned32 READ/ RTS/CTS 사용여 ( ) WRITE 부 sysserialrate Unsigned32 READ/ Serial Interface 의 ( ) WRITE 초당비트수 (bps) 37

47 sysserialwordbit Unsigned32 READ/ Serial Interface 의 ( ) WRITE 데이터비트수 sysserialstopbit Unsigned32 READ/ Serial Interface 의 ( ) WRITE 정지비트수 sysserialparitytype INTEGER READ/ Serial Interface 의 ( ) WRITE 패리티 Type ( notused(0), Odd(1), Even(2) ) sysusedhcp INTEGER READ/ DHCP 사용여부 ( ) WRITE ( notused(0), used(1) ) sysipaddr IpAddress READ/ IP 주소 ( ) WRITE sysnetmask IpAddress READ/ Netmask ( ) WRITE sysgwaddr IpAddress READ/ GW 주소 ( ) WRITE sysdnsaddr IpAddress READ/ DNS 주소 ( ) WRITE sysmemroythreshold Unsigned32 READ/ Memory Threshold ( ) WRITE 값 syscputhreshold Unsigned32 READ/ CPU Threshold 값 ( ) WRITE syschannelstatethreshold Unsigned32 READ/ Channel 속도의 ( ) WRITE Threshold 값 sysservicestatethreshold Unsigned32 READ/ Master 로부터서 ( ) WRITE 비스받는 BPS Threshold 값 표 6. systemconftable 38

48 Table &Entry Field Type Access Description systemstatisticstable sysstatisticsdeviceindexmb Unsigned32 Not System 의 MAC ( ) (Primary Key) accessible Address 의상위 systemstatisticsentry ( ) 3 Byte ( ) sysstatisticsdeviceindexlb Unsigned32 Not System 의 MAC (Primary Key) accessible Address 의하 ( ) 위 3 Byte sysinbps Counter32 READ Master Station 와 ( ) ONLY 의들어오는 BPS 값 (bit/symbol) sysoutbps Counter32 READ Master Station 와 ( ) ONLY 의나가는 BPS 값 (bit/symbol) sysfreememory Unsigned32 READ Free Memory 양 ( ) ONLY syscpuutilization Unsigned32 READ CPU 사용률 ( ) ONLY sysparentmacaddr Physaddress READ 상위단모뎀 ( ) ONLY 의 MACAddr 표 7. systemstatisticstable interface 그룹 interface 그룹은인터페이스의 index, 인터페이스의현재동작상태, 인터페이스의송수신옥텟수등의시스템의 interface와관련된정보를담고있다. 프록시에이전트를사용하는관리구조인경우, 프록시에이전트장비이외에 PLC 장비의 interface 기본정보를보여주기위해 MIB-II interface 그룹의주요한관리정보를 Common PLC MIB에 39

49 포함하였다. interfacetable 의자세한정보는표 8 에정리하였다. Table Field Type Access Description &Entry Interface ifdeviceindexmb Unsigned32 Not System 의 MAC Address 의상위 Table (Primary Key) accessible 3 Byte ( ( ) 1) ifdeviceindexlb Unsigned32 Not System 의 MAC Address 의하 Interface (Primary Key) accessible 위 3 Byte Entry ( ( ) ifnumber INTEGER READ Index, System 의 Interface Index 1.1) (Primary Key) ONLY ( ) ifdescr DisplayStri READ 인터페이스에관한정보를포 ( ng ONLY 함하는문자열 ( 제조자, 상품 1.4) 명, 버전 ) iftype INTEGER READ 물리 / 연결프로토콜에따라구 ( ONLY 별되는인터페이스의유형 1.5) ifmtu INTEGER READ 인터페이스에서송수신할수 ( ONLY 있는옥텟으로명시된가장 1.6) 큰데이터그램의크기 ifadminstaus INTEGER READ/ 인터페이스의원하는상태 ( WRITE (up - 1, down - 2, testing - 3) 1.7) iflastchange TimeTicks READ 인터페이스가현재동작상태 ( ONLY 에들어갔을때의 sysuptime 40

50 1.8) 의값 ifoperstatus INTEGER READ 인터페이스의현동작상태 ( ONLY (up - 1, down - 2, testing - 3) 1.9) ifinspeed INTEGER READ BPS(Bit/Symbol) 값으로추정되 ( ONLY 는현재가능한대역폭 1.10) ifinoctets Counter32 READ 인터페이스에서수신된총옥 ( ONLY 텟개수 (Serial Interface 인경 1.11) 우, 수신된 Byte 값 ) ifinucastpkts Counter32 READ 상위계층의프로토콜에전달 ( ONLY 되는 서브네트웍 - 유니캐스트 1.12) 패킷의개수 ifinnucastpkts Counter32 READ 상위계층의프로토콜에전달 ( ONLY 되는비유니캐스트패킷의개 1.13) 수 ifindiscards Counter32 READ 상위계층의프로토콜에전달 ( ONLY 되는것을막는오류가검출 1.14) 되지않을지라도버려지는도 착패킷의개수 ifoutspeed INTEGER READ BPS(Bit/Symbo) 값으로추정되 ( ONLY 는현재가능한대역폭 ) 1.15) ifoutoctets Counter32 READ 인터페이스에서전송되는총 ( ONLY 옥텟개수 (Serial Interface 인 1.16) 경우, 전송된 Byte 값 ) ifoutucastpkts Counter32 READ 서브네트워크 - 유니캐스트주소 ( ONLY 에전송되는패킷의총개수 1.17) 41

51 ifoutnucastpkts Counter32 READ 비유니캐스트주소에전송되 ( ONLY 는패킷의총개수 1.18) ifoutdiscards Counter32 READ 오류때문에전송되지못한패 ( ONLY 킷이없을지라도버려지는발 1.19) 신패킷의개수 표 8. interfacetable plcinfo 그룹 plcinfo 그룹은시스템 interface 정보중에송수신 BPS 값, 전체적인 PLC 통신의채널상태를보여주는 Tonemap 등의 PLC 관련정보를담고있다. 이그룹의 plcoutbps와 plcinbps는 PLC 네트워크의성능을보여주는 ifinspeed와 ifoutspeed를계산할때, 사용되는정보로, 장애판단에중요한정보이다. plcinfotable의자세한정보는표 9에정리하였다. Table &Entry Field Type Access Description plcinfotable plcdeviceindexmb Unsigned32 Not System 의 ( ) (Primary Key) accessible MAC Address plcinfoentry ( ) 의상위 3 ( ) Byte plcdeviceindexlb Unsigned32 Not System 의 (Primary Key) accessible MAC Address ( ) 의하위 3 Byte plcoutagcgain INTEGER READ 보내는 AGC ( ) ONLY Gain INTEGER READ 받는 AGC plcinagcgain 42

52 ( ) ONLY Gain plcoutbps INTEGER READ Total number ( ) ONLY of allocated bits per symbol for Tx plcinbps INTEGER READ Total number ( ) ONLY of allocated bits per symbol for Rx plcrxtonemap Octet READ Rx tone map ( ) String ONLY plctxtonemap Octet READ Tx tone map ( ) String ONLY 표 9. plcinfotable trap 그룹 Trap 그룹은네트워크의구조가변하거나장애가발생했을때발생되는 trap정보를담고있다. 각그룹에포함된 table의 index는모든 PLC 장비의구분기준이될수있는 MAC Address를이용하였다. Trap 그룹의자세한정보는표 10에정리하였다. Trap Object & OID Field Type Description trapstatuschange ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte sysstatus INTEGER 해당 System 의상태 Type ( ) (Active(0), Pending(1), 43

53 trapdetectednewpeer ( ) trapdisappearedpeer ( ) trapcpuwarning ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) Falut(2),Unregistered(3), UnregisteredFault(4), Unauthorized(5) ) Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte syscpuutilization ( ) Unsigned32 해당 System 의 CPU 사용률 trapmemorywarning ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte sysfreememory ( ) Unsigned32 해당 System 의 Free Memory 사용량 trapchannelstatewarning ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) ifnumber ( ) Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte INTEGER Index, System의 Interface Index 44

54 ifinspeed ( ) ifoutspeed ( ) INTEGER INTEGER 해당 System 의 InSpeed 해당 System 의 OutSpeed trapservicestatewarning ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte sysinbps ( ) sysoutbps ( ) Counter32 Counter32 해당 System 의 InBPS 값 해당 System 의 OutBPS 값 trapunauthorizedaccess ( ) sysconfdeviceindexmb ( ) sysconfdeviceindexlb ( ) Unsigned32 해당 System의 MAC Address의상위 3 Byte Unsigned32 해당 System의 MAC Address 의하위 3 Byte sysparentmacaddr ( ) Physaddress 해당 System 의상위단모 뎀의 MACAddr 표 10. Trap 그룹 Common PLC MIB은기존 PLC MIB과달리네트워크관리의기본기능적인측면에서모든 PLC 장비가제공해야할공통정보이다. 따라서 PLC 네트워크매니저입장에서 Common PLC MIB을이용하여관리한다면, 기존 PLC MIB들을이용하였을때보다, 관리정보의양이줄었기때문에, 서버의공간을효율적으로이용할수있고, 관리정보와매니저의수정및유지보수가수월해진다. 또관리정보변환에따른로드도감소한다. 뿐만아니라 NMS와 PLC 장비개발자입장에서는관리정보정의에따른시간과비용이감소된다. Common PLC MIB Definition은부록 A를참고하기바란다. 45

55 4 통합 PLC Proxy Agent 이장에서는 Common PLC MIB을지원하지않는기존 PLC 장비를포용하기위해제안된통합 PLC Proxy Agent의요구사항, 구조및개발환경에대해서설명한다. 통합 PLC Proxy Agent의확장성을검증하기위해관리가능한 SNMP 에이전트의개수의변화에따른성능측정및결과에대해설명한다. 통합 PLC Proxy Agent는 SNMP 매니저와 Common PLC MIB을지원하지않는기존 PLC 장비사이에서같은기능을하는관리정보를변환해주는 gateway 장비이다. 그림 9는통합 PLC Proxy Agent의동작을보여준다. 그림 9. 통합 PLC Proxy Agent 동작 통합 PLC Proxy Agent는 Common PLC MIB을이용하여작성된 SNMP 메세지를, Common PLC MIB을지원하지않는 PLC 장비가이해 46

56 할수있게하기위해서, 기존 PLC MIB 기반의 SNMP 상호작용 (interaction) 과 Common PLC MIB 기반의 SNMP 상호작용 (interaction) 사이의변환을수행한다. 4.1 요구사항 통합 PLC Proxy Agent의요구사항은다음과같다. 1. Common PLC MIB과기존 PLC MIB 사이의관리정보변환을수행해야한다. 기존 PLC MIB에서해당 Common PLC MIB 정보를제공하는경우는같은기능의관리정보에대해 OID mapping을수행한다. 예 ) Xeline 장비의경우, Common PLC MIB의 sysnodetype 정보는 Xeline MIB의 xxpas200bdevicetype 정보제공 기존 PLC MIB에서해당 Common PLC MIB 정보를제공하지않는경우는가공할수있는정보에대해서는통합 PLC Proxy Agent가가공하여, SNMP 매니저에게제공한다. 예 ) DS2 장비인경우, Common PLC MIB의 ifinspeed 정보는 DS2 MIB의 plstatisticsplcinputwords 값을시간으로나누어서제공 Xeline 장비의경우, Common PLC MIB의 sysmemroythreshold 정보는, Xeline MIB의, xeu200bsetting Parameter 정보의하위 4byte 정보를 Bit 연산을통해얻은후제공 2. 관리하는 PLC 장비들의목록및업체정보를유지해야한다. 3. SNMP 메세지를처리할수있어야한다. 4. 통합 PLC Proxy Agent를통하여기존장비를관리하더라도, Common PLC MIB으로관리되는장비와비교해서차이를느끼지못할정도로빠른성능을보장해야한다. 5. 대규모의기존 PLC 장비를관리할수있도록확장성을가져야 47

57 한다. 4.2 구조 통합 PLC Proxy Agent 구조는그림 10 과같다. 그림 10. 통합 PLC Proxy Agent 구조 48

58 통합 PLC Proxy Agent는 Msg Handler, Msg Translator, Repository, Device Scanner 4개의모듈로구성되어있다. Msg handler는 Manager System과 PLC 장비로받은 SNMP 메세지를 type에맞게분류하여, Msg Translator에게전달해주는기능을한다. Request Handler는관리시스템 (Manager System) 으로부터의 SNMP request 메세지를처리하고, Response Handler는 PLC 장비로부터오는 SNMP response 메세지를처리하고, Trap Handler는 PLC 장비로부터오는 SNMP trap을처리한다. Msg Translator는 Common PLC MIB SNMP 메세지와기존 PLC MIB SNMP 메세지사이를변환해주는기능을한다. Msg Parser는 SNMP 메세지를 parsing 하여해당장비의 IP와 OID 정보를 Selector에넘겨주는기능을한다. Selector는 parser로부터받은 IP와 OID와 Repository의변환정보를 Msg Generator에게전달해준다. Msg Generator는 Selector로받는 IP, 변환정보를이용하여, SNMP 메세지를생성하여 Msg Handler 에게전달하는기능을한다. Repository 모듈은 Common PLC MIB과기존 PLC MIB 사이에변환정보와통합 PLC Proxy Agent 가관리하는장비의정보를가지고있다. Device Scanner는통합 PLC Proxy Agent 가관리하는장비의목록과정보를유지하는기능을한다. IP & Vendor Checker는통합 PLC Proxy Agent가관리하는장비의업체 (vendor) 정보를체크한다. 4.3 개발환경 통합 PLC Proxy Agent는 AdventNet사에서제공하는 SNMP Agent Toolkit Java Edition 6.0 [39] 을이용하여개발하였다. 개발환경은다음과같다. Language: JDK 1.5.0_06 OS: Windows XP Professional Service Pack 2 49

59 IDE: AdventNet SNMP Agent Toolkit Java Edition 6.0 Library: AdventNet SNMP API [40] 4.4 확장성성능측정 이번절에서는통합 PLC Proxy Agent의칩셋업체별로관리가능한 SNMP 에이전트개수에대한확장성을알아보기위한성능측정및결과에대해설명한다 성능측정방법성능측정은 2대의서버를이용하여수행하였다. 1대의서버에는 SNMP GetRequest 동작 (operation) 을수행하는 Test Manager와통합 PLC Proxy Agent가동작하고, 나머지 1대의서버에는가상의 SNMP 에이전트를시뮬레이션할수있는 SNMP 에이전트시뮬레이터가동작한다. 2 대의서버는 100 Mbps 이더넷네트워크로연결되어있다. PLC 장비에탑재된실제 SNMP 에이전트를이용하여성능측정을하지못한이유는확장성성능측정을수행할수있을만큼의다수의 SNMP 에이전트가동작하고있는 PLC 네트워크를구축할수없기때문이다. 따라서다수의 SNMP 에이전트를시뮬레이션할수있는 SNMP 에이전트시뮬레이터를이용하여성능을측정하였다. SNMP 에이전트시뮬레이터는네트워크장비로부터실제정보를가져오지는못하지만, SNMP 메시지를처리하는과정은실제 SNMP 에이전트와똑같이수행하기때문에, 성능측정에는차이가없다. 그림 11은확장성성능측정환경을보여주고있다. 50

60 그림 11. 성능측정환경 성능측정방법은다음과같다. Test Manager가특정 SNMP 에이전트에게 Common PLC MIB의 systemconftable의 10개의정보를가져오는동작 (GetRequest) 을수행하는 thread를실행시킨다. 이때, thread의개수를변화시켜가면서, 모든 thread가수행될때까지의시간을측정한다. 즉, 특정개수의 SNMP 에이전트로부터 Common PLC MIB의 systemconftable의 10개의정보에대해가져오는데드는응답시간 (response time) 을측정하는것이다. 수식 (1) 과같이전체응답시간 (RT) 은 Test Manager가 SNMP 메세지를처리하는시간 (T tm ), 통합 PLC Proxy Agent가 SNMP 메세지를처리하는시간 (T pa ), 통합 PLC Proxy Agent가 Common PLC MIB과기존 PLC MIB 사이의관리정보변환을수행하는시간 (T trans ), SNMP 에이전트시뮬레이터가 SNMP 메세지를처리하는시간 (T as ) 의합으로구성된다. RT = T + T + T + T (1) tm pa tran as 성능측정은총 3가지경우의응답시간 (RT) 을측정하였다. 첫번째는 Xeline 에이전트의개수에따른 systemconftable의 10개의정보를가져오는데걸리는응답시간 (RT) 이다. 즉, Test Manager가특정개수의 51

61 thread를수행하여, 통합 PLC Proxy Agent를통해 systemconftable의 10 개의정보를특정개수의 Xeline 에이전트로가져오는데걸리는시간이다. 두번째는 DS2 에이전트의개수에따른 systemconftable의 10개의정보를가져오는데걸리는응답시간 (RT) 이다. 마지막은 Common PLC MIB 에이전트의개수에따른 systemconftable의 10개의정보를가져오는데걸리는 (RT) 이다. 마지막경우는통합 PLC Proxy Agent를통하지않기때문에수식 (2) 와같이전체응답시간 (RT cm ) 이 Test Manager가 SNMP 메세지를처리하는시간 (T tm ) 과 SNMP 에이전트시뮬레이터가 SNMP 메세지를처리하는시간 (T as ) 의합으로구성된다. RT + cm = Ttm Tas (2) 성능측정을하는동안, SNMP 에이전트시뮬레이터는 Xeline MIB을지원하는 SNMP 에이전트 100대, DS2 MIB을지원하는 SNMP 에이전트 100대, Common PLC MIB을지원하는 SNMP 에이전트 100대, 총 300대의 SNMP 에이전트를항상실행하고있다. 이는 SNMP 에이전트시뮬레이터의동작상태를항상같게하여, 성능측정에 SNMP 에이전트시뮬레이터의영향을최소화시키기위한것이다. 또 Test Manager가 thread를이용하여, 성능측정을수행한이유는여러개의 SNMP 에이전트로부터정보를순차적인아닌, 동시에받아오기위한것이다 성능측정결과 3가지경우에대해성능측정한결과는표 11과그림12와같다. 측정결과는응답시간을 50번씩측정을하여측정값들의평균값을이용하였다. 평균응답시간은 Xeline 에이전트경우, DS2 에이전트경우, Common PLC MIB 에이전트경우, 순서대로나타났다. Common PLC 에이전트의경우가가장낮은응답시간이나온이유는통합 PLC 52

62 Proxy Agent를통하지않아서, T pa 와 T trans 이전체응답시간 (RT cm ) 에서빠졌기때문이다. Xeline 에이전트경우가 DS2 에이전트경우보다더높은응답시간이나온이유는 Xeline MIB에는하나의 MIB value에복수의관리정보가포함되어있는 MIB정보가많아 Common PLC MIB과기존 PLC MIB 사이의관리정보변환을수행하는시간이길어졌기때문이다. 예를들어, Xeline MIB의 xxpas200binitialuartconfig 정보는다양한정보 (Serial data transmission type, Word length, Stop bit selection 등 ) 를 bit 별로가지고있다. 만약 SNMP 매니저가 Common PLC MIB의 sysserialrate 정보를요구한다면, 통합 PLC Proxy Agent는 xxpas200binitialuartconfig 정보를 Xeline 에이전트로부터받아서, bit 연산을통해상위 11~12 bit 값을추출하여 SerialRate 정보를얻어야한다. SNMP 통신에서일반적인 Timeout 값이 5초라는것을고려했을때, 성능측정서버사양 (Pentium Dual Core 1.6 GHz CPU와 2GB RAM) 을가진통합 PLC Proxy Agent는 Xeline 에이전트의경우는 25대, DS2 에이전트의경우는 50대를관리하는것이적당하다고할수있다. 평균 Response Time (ms) Agent 개수 Common PLC Xeline Agent DS2 Agent MIB Agent 표 11. 칩셋업체별 Get Request 의 Response Time 53

63 그림 12. 칩셋업체별평균 Response Time 54

64 5 통합 PLC NMS 이장에서는통합 PLC NMS의요구사항을분석하고그요구사항을바탕으로설계된구조, 동작흐름및개발환경에대해서설명한다. 또제안한통합관리체계의실현가능성을보이기위해 DS2 모뎀, Xeline 모뎀, Common MIB PLC 모뎀으로구성된실제이종 PLC 네트워크테스트베드 (testbed) 를구축하고, 통합 PLC NMS를이용하여통합관리기능에대한테스트를수행하였다. 5.1 요구사항 통합 PLC NMS는그림 4와같은이종 PLC 네트워크를 Common PLC MIB을이용하여관리하는시스템이다. 따라서 OPERA PLC 네트워크와같이모든장비에 SNMP 에이전트를탑재한관리구조뿐만아니라 Xeline PLC 네트워크와같은장비에 SNMP 에이전트를탑재하지않은프록시에이전트관리구조도관리할수있어야한다. 즉복수의셀로구성된다양한칩셋업체의 PLC 네트워크를통합적으로관리할수있어야한다. 통합 PLC NMS의기능적인요구사항은다음과같다. 첫째, PLC 장비의등록, 정보수정및삭제를할수있고, PLC 장비간의연결정보를조회할수있는구성정보관리기능을제공해야한다. 둘째, 성능장애발생시트랩을발생해사용자에게알려주고, 장애이력을조회할수있는장애정보관리기능을제공해야한다. 셋째, 성능관련데이터를처리 ( 수집, 분석, 보고서작성 ) 할수있는성능정보관리기능을제공해야한다. 넷째, 가입자정보를조회, 추가, 삭제, 변경할수있는가입자정보관리기능을제공해야한다. 55

65 마지막으로사용자를변경하고, 등급을관리할수있는사용자관리기능을제공해야한다. 통합 PLC NMS의비기능적인요구사항은다음과같다. 첫째, 통합 PLC NMS는다양한장비및관리정보의추가, 수정, 삭제가빈번히발생할수있으므로, 변경시다른모듈에주는영향을최소화하기위해, 모든모듈들이기능적으로독립되게설계되어야한다. 둘째, 통합 PLC NMS는수천만개이상의관리대상장비를관리해야하는시스템이기때문에, 수천건의서버부하발생시에도서버가다운되지않는대용량처리기능을갖추어야한다. 셋째, Multi-tier 기반의구조를제공하기위해서다중플랫폼을지원하고, 타시스템과의연동을위한표준인터페이스를제공해야한다. 5.2 구조 이절에서는 5.1 절에서분석한요구사항을바탕으로설계한통합 PLC NMS의구조에대해서살펴본다. 그림 13은통합 PLC NMS의전체구조를보여준다. 통합 PLC NMS는크게 Backend Manager와 Frontend Manager로나누어진다. 이둘은같은시스템내에존재할수도있고, 다른시스템에존재할수도있다. 둘간의인터페이스는 TCP를이용한소켓 (socket) 으로할수도있고, RMI(Remote Method Invocation) [41] 를사용할수도있다. Backend Manager는구성관리기능, 성능관리기능및장애관리기능등의실질적인매니저의기능을제공하는모듈이고, Frontend Manager는클라이언트의요구사항에대한서비스를제공하기위한서버와클라이언트사이의통신을관리하는모듈이다. 56

66 그림 13. 통합 PLC NMS 구조 Frontend Manager는 Backend Communication Manager, Session Component Manager, Data Manager, Client Communication Manager, Log Handler로구성되어있다. 그림 14는 Frontend Manager의구조를보여준다. Backend Communication Manager는 Backend Manager와통신을담당하는모듈이다. Session Component Manager는 Web Browser Client 의 request를기초로 DB의뷰 (view) 를제공하거나, Backend Manager로부터들어오는 commit request를 Web Browser에게전달하는 Frontend Manager 의핵심모듈이다. Data Manager는 DB Operation을처리하는모듈이다. Client Communication Manager는 HTTP Protocol을통해서 Web Browser Client와통신을담당하는모듈이다. Log Handler는각모듈에서발생하는 log를기록하고처리하는모듈이다. 57

67 그림 14. Frontend Manager 구조 Backend Manager는 Communication Manager, Trap Manager, Configuration Manager, Performance Manager, Fault Manager, Data Manager, Frontend Communication Manager, Log Handler로구성되어있다. 그림 15 는 Backend Manager의구조를보여준다. Agent Communication Manager는 SNMP 에이전트와통신을담당하는모듈이다. Trap Manager는 SNMP 에이전트로부터발생된 trap을처리하는모듈이다. Configuration Manager는구성관리기능을담당하는모듈이고, Performance Manager 는성능관리기능을담당하는모듈이다. Fault Manager는장애관리기능을담당하는모듈이고, Data Manager는 DB Operation을처리하는모듈이다. Frontend Communication Manager는 Frontend Manager와통신을담당하는모듈이고, Log Handler는각모듈에서발생하는 log를기록하고처리하는모듈이다. 58

68 그림 15. Backend Manager 구조 59

69 5.3 동작흐름 이절은통합 PLC NMS의동작흐름을 Sequence Diagram을통해서보여준다. :FrontendMa nager :DataManag er :BackendMa nager 1: initialize :Performanc emanager :SnmpPoller :DBManager :Agent 2: setpoller 3: polling 4: result 5: set 6: get 7: getdata 그림 16. 성능데이터수집 그림 16은통합 PLC NMS가성능데이터를수집하여, 사용자에게보여주는동작을보여준다. Backend Manager가 Performance Manager 를생성하면, Performance Manager는성능데이터를주기적으로수집하는 SnmpPoller 객체를생성한다. SnmpPoller는에이전트로부터주기적으로성능데이터를받아와서 Performance Manager에게주면, Performance Manager는 DB Manager를이용하여성능데이터를 Database(DB) 에저장한다. Frontend Manager는 Data Manager를이용하여성능데이터를 DB로부터받아와서사용자에게보여준다. 60

70 client :FrontendMa nager :Communicat ionmanager : BackendManager : ConfigurationManager : SnmpRequestServer : DBManager 1: setdata 2: setparameter 3: setparameter(systemstatus) 4: setsystemstatus( ) 5: addresultlistener( ) 6: setresult( ) 7: set( ) 그림 17. PLC 장비의구성정보설정 그림 17은 PLC 장비의구성정보를설정하는동작의흐름을보여준다. Client로부터장비구성정보설정요청을받으면 Frontend Manager는 Communication Manager를통해서 Backend Manager에게구성정보설정을요청한다. 요청을받은 Backdend Manager는 Configuration Manager에게구성정보설정을요청한다. Configuraton Manager는 SnmpRequestServer 객체를이용하여 PLC 장비에구성정보를설정하고, DB Manager를통해서 DB의구성정보도업데이트한다. 그림 18은통합 PLC NMS의트랩처리과정의흐름을보여준다. 처음에 Frontend Manager는 Backend Manager로부터트랩메시지를받기위해 listener를동작시킨다. Trap Manager가 SnmpTrapReceiver 객체를이용하여트랩메세지를받게되면, 어떤종류의트랩인지분석한후, Fault Manager에전달한다. Fault Manager는해당 fault 맞는동작을수행하고, 사용자에게알리기위해 Frontend Manager에게트랩메세지를전달한다. 61

71 :FrontendManager :TrapListener : BackendManager : FaultManager : TrapManager : SnmpTrapReceiver 1: initialize 2: addtraplistener 3: receivedtrap(trapevent) 4: processtrap( ) 5: sendtrap( ) 6: receivetrap() 7: processfault 8: receivedtrap(trapevent) 9: trap 그림 18. 트랩처리 5.4 Database 설계 이절에서는통합 PLC NMS가이종 PLC 네트워크를관리하기위해사용할 DB의구조에관해설명한다. DB Table은 4개로구성되어있다. 그림 19는 DB의구조를보여준다. 62

72 그림 19. Database 구조 DeviceTable은관리하는 PLC 장비에관한정보를가진 table 이 다. Primary key는 indexnumber와 MACAddr이다. Field Name Type Description IndexNumber NUMBER Table Primary Key MACADDR VARCHAR MAC address 정보 NODETYPE NUMBER System Type 정보 (Master,Slave 등 ) STATUS NUMBER System의상태정보 FWVERSION VARCHAR System의 Fireware 버전 INPKTS NUMBER Interface로들어온 Packet 수 OUTPKTS NUMBER Interface로나간 Packet 수 INBPS NUMBER Interface로들어오는 BPS 값 OUTBPS NUMBER Interface로나가는 BPS 값 63

73 INSPEED NUMBER Interface로들어오는속도 (Mbps) OUTSPEED NUMBER Interface로나가는속도 (Mbps) INFAILS NUMBE Interface로들어오는 Fail Pakcet 수 OUTFAILS NUMBE Interface로나가는 Fail Pakcet 수 RTSCTSSTATUS NUMBER RTC/CTS Enable 상태 IPADDR VARCHAR IP 주소 NETMASK VARCHAR Netmask 정보 GATEWAY VARCHAR Gateway 주소 DNSADDR VARCHAR DNS 주소 SPEEDTHRESHOLD NUMBER Interface 속도경고 Threshold 값 CPUTHRESHOLD NUMBER CPU 사용률경고 Threshold 값 MEMTHRESHOLD NUMBER Memory 사용률경고 Threshold 값 CPUUTILIZATION NUMBER CPU 사용률 FREEMEMSIZE NUMBER Memory 사용률 INAGCGAIN NUMBER Interface로들어오는 AGC Gain 값 OUTAGCGAIN NUMBER Interface로나가는 AGC Gain 값 PARENTMAC VARCHAR 부모장비의 MAC Address 표 12. DeviceTable StatisticsTable은성능관리를위한정보를가진 table로, 폴링을 통해얻은성능통계정보를시간별로기록한것이다. Primary key는 IndexNumber와 MACAddr이다. Field Name Type Description IndexNumber NUMBER Table Primary Key MACAddr VARCHAR2 MAC address 정보 Timestamp TIMESTAMP 정보를기록한시간 InPkts NUMBER interface로부터들어오는 Packet 수 64

74 OutPkts NUMBER interface로부터나가는 Packet 수 InSpeed NUMBER interface로부터들어오는속도 OutSpeed NUMBER interface로부터나가는속도 InFails NUMBER Interface로들어오는 Fail Pakcet 수 OutFails NUMBER Interface로나가는 Fail Pakcet 수 표 13. StatisticsTable FaultTable은 fault의정보를발생한시간별로기록한 table이다. Primary key는 IndexNumber와 MACAddr이다. Field Name Type Description IndexNumber NUMBER Table Primary Key MACaddr VARCHAR2 MAC address 정보 Timestamp TIMESTAMP Fault 난시간 Type NUMBER Fault Type 표 14. FalutTable UserTable은사용자관리를위한정보를가진 table 이다. Primary key는 ID이다. Field Name Type Description ID VARCHAR2 사용자의 ID Passwd VARCHAR2 사용자의비밀번호 Priority NUMBER Admin[0], normal[1] 표 15. UserTable 65

75 5.5 구현 이절에서는통합 PLC NMS의구현에관해설명한다. 통합 PLC NMS의개발환경은다음과같다. Language : JDK 1.5.0_06 OS : Windows XP Service Pack 2 IDE : Eclipse 3.1 Library : AdventNet SNMP API, Lomboz(JSP plugin) Web server engine for JSP : Apache Tomcat 5.5 Web Client : JSP(Java Server Pages) Database : Oracle database 10g 통합 PLC NMS는 JDK 1.5와 eclipse를활용하여구현하였다. Oracle 10g가설치되어있는서버를 JDBC를통해 Backend Manager와 Frontend Manager가접근하여사용할수있게하였다. 또 AdventNet에서제공하는 SNMP API를이용하였다. AdventNet SNMP API는 SNMP를개발하기위해서필요한 SNMP의기본적인동작 ( 예 : SNMPGET, SNMPSET 등 ) 뿐만아니라, 확장된동작 ( 예 : GetTable, SnmpTrapReceiver 등 ) 들과같은다양한 class와 interface를제공하는 API이다. Frontend Manager와 Backend Manager의통신을위해서는 RMI 를사용하였다. RMI는기본적으로 Java가제공하는분산환경객체의메소드를호출하는방법으로밑단의소켓통신등을고려하지않고원격의객체를자신의 VM에가지고있는것과마찬가지로사용할수있도록도와준다. RMI를이용한통신은 Eclipse 3.1에최적화되어있는 RMI plug-in인 RMI Plugin for Eclipse (ver ) [42] 를이용하여구현하였다. 66

76 5.6 테스트베드구축 이절에서는제안한통합관리체계의실현가능성을보이기위해구축된이종 PLC 네트워크테스트베드 (testbed) 에대해서설명한다. 이종 PLC 네트워크테스트베드는 Xeline 셀 (cell), DS2 셀, Common PLC MIB 셀로구성되었다. Xeline 셀은 Xeline의 XPAS-200B Internet Access 시스템 [43] 을이용하여, 연구실에설치하였다. Xeline의 XPAS-200B의시스템사양은다음과같다. 마스터모뎀 : MM-200B 1개 슬레이브모뎀 : SU-200B 5개 프록시에이전트 : EU-200B 1개 DS2 셀은 Corinex [44] 사의 AV200 Enterprise Powerline Ethernet Adapter [45] 를이용하여, 연구실의컴퓨터실에설치하였다. AV200 Enterprise Powerline Ethernet Adapter는마스터모뎀역할과슬레이브모뎀역할모두할수있는장비이다. 사양은다음과같다. 마스터모뎀 : AV200 Enterprise Powerline Ethernet Adapter 1개 슬레이브모뎀 : AV200 Enterprise Powerline Ethernet Adapter 2개 Common PLC MIB 네트워크는 Xeline 사에서개발한 Common PLC MIB 에이전트를제공하는 PLC 장비로, 대전에구축되었다. 사양은다음과같다. IRM 모뎀 ( 마스터모뎀과프록시에이전트가합쳐진장비 ): 1 개 마스터모뎀 : 1개 슬레이브모뎀 : 30개 67

77 그림 20 은전체적인테스트베드의구조를보여준다. Common PLC MIB Cell PLC NMS Slave Modem Slave Modem SNMP Manager Master Modem SNMP Agent IRM (Proxy Agent) Switching Hub Internet Switching Hub Slave Modem Slave Modem Ethernet Adapter SNMP Agent UTP Ethernet Adapter SNMP Agent PLC Proxy Agent SNMP Agent Master Modem Switching Hub SNMP Agent EU 200B (Proxy Agent) SNMP Agent Eternet Adapter DS2 Cell Xeline Cell Slave Modem 그림 20. 이종 PLC 네트워크테스트베드구조 5.7 테스트결과 이절에서는이종 PLC 네트워크테스트베드에서통합 PLC NMS 를이용하여여러통합관리기능을테스트한결과에대해서설명한다. 우리가테스트한관리기능은이종 PLC 네트워크테스트베드의구성관리, 성능관리및장애관리이다. 68

78 그림 21은 통합 PLC NMS의 메인 화면으로, 로그인하였을 때 처 음보이는 화면이다. 이 화면은 트리(tree) 프레임(frame), 맵(map) 프레 임, 트랩(trap) 프레임, 3개의 프레임으로 구성되어있다. 트리 프레임은 이종 PLC 네트워크 테스트베드의 전체적인 연결구조를 트리형태로 보여주는 것이고, 맵 프레임은 이종 PLC 네트워크 테스트베드의 전체 적인 연결구조를 맵 형태로 보여준다. 트랩 프레임은 발생 된 트랩의 정보를 최근 순으로 보여준다. 관리자는 메인 화면을 통해서, 관리하 고 있는 이종 PLC 네트워크 테스트베드의 전체 상태를 알 수 있다. 그림 21. 통합 PLC NMS 메인 화면 그림 22는 메인 화면에서 원하는 장비를 선택했을 때, 해당 장 비의 세부적인 관리정보를 보여주는 장비정보 화면이다. 이 화면에서 69

79 는 Information, Settings, Statistics, 총 3개의메뉴를제공한다. Information 메뉴는 NodeType, Status, IP 등의일반적인정보, In/Out Packet 수, In/Out Speed 등의 interface 정보, CPU threshold, Memory threshold 등의 setting 정보등을보여준다. 그림 22. 통합 PLC NMS 장비정보화면 70

80 그림 23은장비정보화면 ( 그림22) 에서 Settings 메뉴를선택했을때보여주는장비설정화면이다. 이화면에서는 SpeedThreshold, CPUThreshold, MemoryThreshold 등과같은설정가능한관리정보를보여주고, 원하는값으로수정할수있다. 그림 23. 통합 PLC NMS 장비설정화면 71

81 그림 24는장비정보화면 ( 그림22) 에서 Statistics 메뉴를선택했을때보여주는통계정보화면이다. 이화면은 In/Out Packet 수, In/Out Speed, In/Out BPS 와같은성능정보를그래프형태로시간에따른변화를보여준다. 그림 24. 통합 PLC NMS 통계정보화면 72