KR20110087650A

KR20110087650A - 원격 접속 서비스에서 아이피 주소 충돌 해결 방법 및 장치

Info

Publication number: KR20110087650A
Application number: KR1020100007164A
Authority: KR
Inventors: 한세희; 이주열; 정동신; 맹제영; 패이패이 팽
Original assignee: 삼성전자주식회사
Priority date: 2010-01-26
Filing date: 2010-01-26
Publication date: 2011-08-03
Also published as: KR101614548B1

Abstract

본 발명은 UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 제1서버 및 제2서버에 연결된 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서, 상기 제1서버가 상기 제2서버와 RAT(Remote Access Transport) 채널을 생성하는 과정과, 상기 제1서버가 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하는 과정과, 상기 제1서버가 상기 제1서버의 네트워크의 서브넷 주소(subnet address) 정보를 제2서버로 전달하는 과정과, 상기 제2서버가 상기 제1서버로부터 상기 제1서버의 네트워크의 주소 정보를 수신하는 과정과, 상기 제2서버가 상기 제2서버의 네트워크의 서브넷 주소 정보와 상기 수신한 제1서버의 네트워크의 서브넷 주소 정보를 비교하여, 상기 제1서버와 제2서버의 네트워크의 서브넷 주소에 충돌이 발생한지 판단하는 과정과, 상기 판단 결과 충돌이 발생한 경우 충돌이 발생한 주소를 변환하는 과정을 포함한다.

Description

원격 접속 서비스에서 아이피 주소 충돌 해결 방법 및 장치{METHOD AND APPARATUS FOR PREVENTING IP ADDRESS CONFLICT IN REMOTE ACCESS SERVICE}

본 발명은 홈 네트워크 미들웨어 프로토콜인 UPnP(Universal Plug and Play)를 이용한 원격 접속(Remote Access) 서비스에서 홈 네트워크의 장치와 원격 네트워크에서의 장치 간에 동일한 아이피(IP) 주소 사용으로 인한 충돌을 해결하기 위한 방법 및 장치에 관한 것이다.

일반적으로 홈 네트워크는 인터넷 프로토콜(IP, internet protocol) 기반의 사설 망(private network)으로 이루어지는 것으로, 가정 내에서 사용되는 모든 형태의 개인 컴퓨터(PC, personal computer)와 지능형 제품, 무선 장치 등의 다양한 기기들을 미들웨어(middleware)라 불리는 공통의 가상 컴퓨팅 환경을 통해 하나의 네트워크로 연결하여 통제하는 것이다.

미들웨어란 다양한 디지털 기기들을 피어-투-피어(peer-to-peer) 방식으로 연결하여 기기들 간의 통신이 가능하도록 하는 것으로, HAVI(Home AV Interoperability), UPnP(Universal Plug and Play control device), Jini(Java Intelligent Network Infra-structure), HWW(Home Wide Web) 등이 현재까지 제안되어 있다.

현재 운영 체제에 PnP(Plug and Play) 기능이 추가된 이후로 PC 주변 장치를 설치하고 설정하는 것이 훨씬 쉬워졌지만, UPnP는 이러한 편리한 기능을TCP/IP(transmission control protocol/internet protocol), HTTP(hypertext transfer protocol) 및 XML(extensible markup language)과 같은 인터넷 표준 기술을 기반으로 전체 네트워크로까지 확장시켜 여러 가전 제품, 네트워크 프린터, 인터넷 게이트와 같은 네트워크 디바이스가 네트워킹 특히, 홈 네트워킹이 가능하도록 하는 기술이다.

UPnP 네트워크는 IP 기반의 홈 네트워크에 연결되어 제어를 받는 기기인 피제어 장치(controlled device; CD) 및 상기 피제어 장치를 제어하기 위한 제어 포인트(control point; CP)로 구성된다. 또한, UPnP 네트워크는 TCP/IP, HTTP와 같은 인터넷 프로토콜들과 XML, SOAP(simple object access protocol)와 같은 기술을 포함하는 UPnP 프로토콜 스택 구조를 이용하여 제어 포인트와 피제어 장치 간에 다음과 같은 단계를 통하여 통신을 한다.

제1 단계는 주소 부여(addressing) 단계로, 제어 포인트와 피제어 장치는 각각 IP 주소를 가지게 된다. 피제어 장치는 네트워크에 참여하게 되면 자신의 IP 주소를 DHCP(Dynamic Host Configuration Protocol)를 이용하여 받아 오거나 네트워 크에 DHCP 서버가 없는 경우 자동 IP 기능을 이용하여 IP 주소를 가지게 된다.

제2 단계는 발견(discovery) 단계로서, 제어 포인트는 피제어 장치를 찾거나 피제어 장치가 자신의 위치를 광고하게 된다. 발견 단계는 SSDP(Simple Service Discovery Protocol)를 사용하여 이루어진다. 만일, 피제어 장치가 네트워크에 추가되었을 경우 피제어 장치는 SSDP의 출현(alive) 메시지를 네트워크에 IP 멀티캐스트 기능을 이용하여 전달하며, 제어 포인트는 출현 메시지를 받아서 피제어 장치의 존재 여부를 알 수 있게 된다. 또한, 제어 포인트가 네트워크에 새로 참여하게 되는 경우 제어 포인트는 SSDP의 M-검색(M-search, multicast-search) 메시지를 네트워크에 멀티캐스트하며 M-검색 메시지를 확인한 피제어 장치들은 모두 자신의 정보를 담은 M-검색 응답(M-search response) 메시지를 제어 포인트에 보내게 된다.

제3 단계는 설명(description) 단계로서, 제어 포인트는 피제어 장치의 설명내용을 확인한다. 제어 포인트는 응답 메시지를 확인하고 원하는 경우 피제어 장치에 관련된 상세한 정보를 피제어 장치에 요청할 수 있으며, 요청 받은 피제어 장치는 자신의 정보를 XML 문서로 보낸다.

제4 단계는 제어(control) 단계로서, 제어 포인트는 피제어 장치의 기능을 제어하여 피제어 장치를 동작시킨다. 제어 포인트가 임의의 피제어 장치를 제어하고자 하는 경우 피제어 장치와 관련된 상세한 정보를 바탕으로 원하는 서비스를 SOAP(Simple Object Access Protocol)를 이용하여 피제어 장치에 보낸다. SOAP는 원격지 함수 호출을 목적으로 HTTP 상에서 XML을 기반으로 작성된 프로토콜이다.

제5 단계는 이벤팅(eventing) 단계로서, 제어 포인트는 피제어 장치의 이벤 트 변화를 수신한다. 피제어 장치의 이벤트 메시지를 수신하기 원하는 경우 제어 포인트는 피제어 장치로 해당 이벤트에 대한 가입 요청을 보낸다. 가입이 성공하면 피제어 장치는 GENA(General Event Notification Architecture)를 사용하여 제어 포인트로 이벤트 메시지를 전송한다.

제6 단계는 표시(presentation) 단계로서, 제어 포인트는 피제어 장치의 HTML을 활용하여 장치의 상태를 표시한다.

이러한 UPnP 기본 제어 방법 (UPnP 디바이스 아키텍처)을 바탕으로 UPnP 피제어 장치는 제어 포인트에게 다양한 서비스(기능)를 제공할 수 있다. 예를 들어, 상기 UPnP 기본 제어 방법을 바탕으로 UPnP 제어 포인트는 UPnP 피제어 장치를 제어하여 UPnP 피제어 장치에 저장되어 있는 A/V 컨텐츠를 또 다른 UPnP 피제어 장치에서 재생되도록 제어할 수 있다. UPnP 피제어 장치가 게이트웨이인 경우 UPnP 제어 포인트는 UPnP 게이트웨이 피제어 장치를 제어하여 홈 내 디바이스에 할당될 IP 주소 대역과 서브넷, 게이트웨이 주소 등을 변경, 설정할 수 있다. 또한 UPnP 홈 네트워크에 원격으로 접속할 수 있는 원격 접속 서비스를 제공할 수 있다.

도 1은 종래의 UPnP(Universal Plug and Play) 원격 접속(Remote Access) 아키텍쳐(Architecture)의 블록 구성도이다. 도 1에 도시된 UPnP 원격 접속 아키텍쳐는 UPnP 포럼(Forum)의 'Remote Access Architecture v1.0' 문서에서 인용하였다. 도 1을 참조하면, 원격 접속 클라이언트(Remote Access Client, 1100)는 CP(1130)와, RADA(Remote Access Discovery Agent)(1110)와, UPnP RAC(Remote Access Client) 디바이스(1120)와, UPnP 디바이스(1140)와, RATA(Remote Access Transport Agent)(1150)를 포함한다. 원격 접속 서버(Remote Access Server, 1200)는 RADA(1210)와 UPnP RAS(Remote Access Server) 디바이스(1220)와 RATA(1230)를 포함한다. 홈 디바이스(Home Device, 1300)와 관리 콘솔(Management Cons, 1400)은 LAN으로 원격 접속 서버(1200)에 연결된다.

원격 접속 클라이언트(1100)의 RAC 디바이스(1120)와 RADA(1110) 및 원격 접속 서버(1200)의 RAS 디바이스(1220)와 RADA(1210)는 UPnP 장치(Device)를 나타낸다. RADASync CP(1113), RADASync CP(1212)는 원격 접속 관련 UPnP 컨트롤 포인트(CP)를 나타내고, RADASync(1112), RATAConfig(1224), RADASync(1211), RADAConfig(1223), RATAConfig(1121), Inbound Connection Config(1221)는 원격 접속 관련 UPnP 서비스(Service)를 나타낸다. 상기RADA Listener/Relay(1222), RADA Listener/Relay(1111)는 RADA(Remote Access Discovery Agent)의 서포트 컴포넌트(Support Component)이며, CP(1130), 디바이스(1140), CP(1310), 디바이스(1320)는 원격 접속과 관련 없는 UPnP CP, 디바이스, 서비스를 나타낸다.

현재의 기본 UPnP 아키텍쳐(v1.0)는 UPnP 장치 탐색(Discovery) 등에서SSDP(Simple Service Discovery Protocol)를 기반으로 동작하며 SSDP는 IP 멀티캐스트(Multicast)를 기본으로 사용하는 프로토콜이다. 하지만, 현재의 IP 멀티캐스트는 인터넷 범위에서의 정상적인 동작을 보장할 수 없으므로 인터넷을 통한 UPnP 장치의 제어 또한 불가능하다. 따라서, UPnP 장치 또는 CP 장치가 인터넷에 위치한 경우에도 마치 물리적으로 홈 네트워크 내에 존재하는 것처럼 동작할 수 있도록 하기 위해 UPnP 원격 접속 아키텍쳐가 제안되었다.

UPnP 원격 접속 아키텍쳐는 도 1에 도시된 바와 같이 UPnP 원격 접속 서버(1200)와, UPnP 원격 접속 클라이언트(1100), UPnP RADA(Remote Access Discovery Agent)(1110,1220) 장치를 정의 하였고, RATA(Remote Access Transport Agent)(1150,1230)를 통해 RAT 채널을 생성한다. 물리적인 원격 접속 서버(1200)와 원격 접속 클라이언트(1100)는 공통적으로 UPnP RADA(1110,1220)를 포함하며, 각각 UPnP RAC 디바이스(1120), UPnP RAS 디바이스(1220)를 포함한다.

UPnP RADA(1110,1220) 장치는 내부의 RADASync(1112,1211) 서비스와 RADASync CP(1113,1212)를 통해 원격 접속 서버(1200)가 속해 있는 홈 네트워크 상에 동작하는 UPnP 장치 목록과 원격 접속 클라이언트(1100)가 가지고 있는 UPnP 장치 목록을 동기화 하는 역할을 하며, 자신이 속한 홈 네트워크 상의 UPnP CP 장치가 원격 네트워크 상의 UPnP 장치를 발견할 수 있도록 SSDP 메시지를 처리하는 역할을 한다.　원격 네트워크의 UPnP 장치를 발견한 UPnP CP 장치는 해당 장치가 제공하는 서비스를 사용하기 위해 제어(Control) 메시지를 전송하게 되며, 이 메시지는 전송 채널(Transport Channel)을 통해 원격 네트워크의 UPnP 장치에 직접 전달된다.

도 2는 UPnP 원격 접속 서비스 동작 시 UPnP 장치 간의 IP 주소가 동일하여 충돌이 발생한 상황을 도시한 예시도이다. 상기 도 1에서 설명한 UPnP 원격 접속 아키텍쳐는 도 2와 같은 원격 접속 상황에서 정상적으로 동작할 수 없다. 도 2를 참조하면, 원격 접속 서버는 게이트웨이(Gateway)(201)에 함께 위치한다고 가정하고 있으며 원격 접속 클라이언트(203)는 다른 게이트웨이(202)의 원격 네트워크에 위치한다. 원격 접속 클라이언트(203)는 상기 UPnP 원격 접속 아키텍쳐에 의해 홈 네트워크에서 동작하는 UPnP 장치(205) 정보를 획득할 수 있다. UPnP 장치(205)의 정보를 획득한 원격 접속 클라이언트(203)는 홈 네트워크의 UPnP 장치(205)의 서비스를 이용하기 위해 제어 메시지를 전송하려고 하는데 이때 원격 접속 클라이언트(203)가 속한 네트워크에 홈 네트워크에 연결된 UPnP 장치(205)와 동일한 IP 주소를 가진 장치(204)가 존재한다면 원격 접속 클라이언트(203)는 어떤 장치로 메시지를 전송해야 하는지 알 수 없다.

일반적으로 이러한 경우의 IP 주소 충돌 해결을 위해서는 원격 접속 서버나 원격 접속 클라이언트 장치에 NAT(Network Address Translation) 장치를 두어 충돌이 생긴 IP 주소를 충돌이 생기지 않는 IP 주소로 변환하여 문제를 해결할 수 있다. 하지만, UPnP 원격 접속 환경 하에서 원격 접속 서버와 원격 접속 클라이언트간에 IP 주소 충돌이 생긴 경우에는 충돌이 생긴 IP 주소에 관한 정보를 전달할 수 있는 방법이 없다는 문제점이 있다.

또한, IP 충돌이 생긴 정보를 전달했다고 하더라도 NAT는 일반적으로 IP 패킷 헤더의 소스 IP 주소나 목적지 IP 주소를 기계적으로 다른 값으로 변환하므로 IP 패킷의 페이로드(Payload)에 있는 IP 주소값(예를 들어, SSDP 헤더의 URL에 포함된 UPnP 장치의 IP 주소값)에 대해서는 ALG(Application Level Gateway)를 통해 변환해야 한다. 이 경우 원격 접속 연결(RA Connection)을 통하는 모든 패킷에 대해 IP 헤더뿐만 아니라 IP 페이로드까지 모두 파싱을 하고 필요한 부분을 찾아 변경하는 등의 작업이 필요한데 이 작업을 위해서는 원격 접속 클라이언트 또는 원격 접속 서버 장치가 많은 자원을 소비해야 하는 문제점이 있다.

본 발명은 UPnP 원격 접속 환경에서 원격 접속된 서버에 연결된 장치들 간의 IP 주소 충돌로 인해 발생하는 문제를 해결하기 위한 방법 및 장치를 제공하고자 한다.

이를 달성하기 위한 본 발명의 일 형태에 따르면, UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속된 제1서버 및 제2서버에 연결된 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서, 상기 제1서버가 상기 제2서버와 RAT(Remote Access Transport) 채널을 생성하는 과정과, 상기 제1서버가 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하는 과정과, 상기 제2서버가 상기 제1서버로부터 상기 제1서버의 네트워크의 서브넷 주소 정보를 수신하는 과정과, 상기 제2서버가 상기 제2서버의 네트워크의 서브넷 주소 정보와 상기 수신한 제1서버의 네트워크의 서브넷 주소 정보를 비교하여, 상기 제1서버와 제2서버의 네트워크의 주소에 충돌이 발생한지 판단하는 과정을 포함함을 특징으로 하며, 상기 판단 결과 충돌이 발생한 경우, 상기 제1서버는 제1서버가 속한 네트워크 상의 기기의 IP 주소와 포트 정보를 상기 RAT 채널에서 사용하는 상기 제1서버의 IP 주소와 동적으로 할당한 포트 번호를 매핑하여 변환하는 과정과, 상기 제2서버는 제2서버가 속한 네트워크 상의 기기의 IP 주소와 포트 정보를 상기 RAT 채널에서 사용하는 상기 제2서버의 IP 주소와 동적으로 할당한 포트 번호를 매핑하여 변환하는 과정과, 상기 매핑 정보를 바탕으로 지속적으로 주소 변환을 수행하고, 외부에서 상기 제1서버와 상기 제2서버가 속한 네트워크로 접근하근 IP 트래픽에 대해 원래의 IP 주소로 역변환하는 과정을 포함함을 특징으로 한다.

본 발명의 다른 형태에 따르면, UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속된 제1서버 및 제2서버에 연결된 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서, 상기 제1서버가 상기 제2서버와 RAT(Remote Access Transport) 채널을 생성하는 과정과, 상기 제1서버가 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하는 과정과, 상기 제1서버가 상기 제1서버의 네트워크의 서브넷 주소 목록을 제2서버로 전송하는 과정과, 제2서버가 제1서버의 네트워크 서브넷 주소를 기반으로 주소 충돌 여부를 판단하고, 제1서버의 변환 서브넷 주소 목록을 참고하여 충돌이 발생하지 않는 서브넷 주소를 결정하는 과정과, 결정된 서브넷 주소로 실제 트래픽을 변환하는 과정을 포함함을 특징으로 한다.

본 발명의 다른 형태에 따르면, UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속된 제1서버 및 제2서버에 연결된 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서, 상기 제1서버가 상기 제2서버와RAT(Remote Access Transport) 채널을 생성하는 과정과, 상기 제1서버가 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하는 과정과, 상기 제1서버가 상기 제1서버의 네트워크의 서브넷 주소를 제2서버로 전송하는 과정과, 상기 제2서버가 상기 제2서버의 네트워크의 서브넷 주소 정보와 상기 수신한 제1서버의 네트워크의 주소 정보를 비교하여, 상기 제1서버와 제2서버의 네트워크의 주소에 충돌이 발생한지 판단하는 과정과, 상기 판단 결과 충돌이 발생한 경우 제2서버가 속한 네트워크의 DHCP 서버를 제어하여 제2서버에 포함된 장치의 IP 주소 영역을 변환하는 과정을 포함함을 특징으로 한다.

본 발명의 다른 형태에 따르면, UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속된 제1서버 및 제2서버에 연결된 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서, 상기 제1서버가 상기 제2서버와RAT(Remote Access Transport) 채널을 생성하는 과정과, 상기 제1서버가 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하는 과정과, 상기 제1서버가 상기 제1서버의 네트워크 상의 기기가 사용하는 IP 주소 목록을 제2서버로 전송하는 과정과, 상기 제2서버가 상기 제2서버의 네트워크 상의 기기가 사용하는 IP 주소 목록을 상기 수신한 제1서버의 네트워크 상의 기기가 사용하는 IP 주소 목록을 비교하여, 상기 제1서버와 제2서버의 네트워크 상의 기기가 사용하는 IP 주소에 충돌이 발생한지 판단하는 과정과, 상기 판단 결과 충돌이 발생한 경우 상기 충돌이 발생한 IP 주소를 다른 IP 주소로 변경하는 과정을 포함함을 특징으로 한다.

본 발명의 또 다른 형태에 따르면, UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속된 서버들 간에 연결된 장치들의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 상기 서버에 있어서, 상기 원격 접속 서비스를 통해 상대방 측 서버로 DDD(Device Description Document)를 전달하며, 상기 원격 접속된 상기 상대방 측 서버로부터 상기 상대방 측 서버의 네트워크의 서브넷 주소 정보를 수신하며, 상기 서버의 네트워크의 서브넷 주소 정보와 상기 수신한 상대방 측 서버의 네트워크의 서브넷 주소 정보를 비교하여, 상기 상대방 측 서버와 상기 자신의 네트워크의 주소에 충돌이 발생한지 판단하는 RADA(Remote Access Discovery Agent)와, 상기 상대방 측 서버와 RAT(Remote Access Transport) 채널을 생성하는 RATA를 포함함을 특징으로 하며, 상기 RATA는 네트워크 주소에 충돌이 발생한 경우, 상기 충돌이 발생한 IP주소를 미리 설정된 다른 IP 주소로 변환하는 ALG(Application Level Gateway)를 포함함을 특징으로 하며,

본 발명의 또 다른 형태에 따르면, 상기 RATA는 네트워크 주소에 충돌이 발생한 경우, 외부에서 인식하는 상기 서버의 서브넷 주소를 미리 설정된 서브넷 주소로 변환하는 ALG(Application Level Gateway)를 포함함을 특징으로 하며,

본 발명의 또 다른 형태에 따르면, 상기 RATA는 네트워크 주소에 충돌이 발생한 경우, 상기 충돌이 발생한 IP주소를 미리 설정된 다른 IP 주소로 변환하는 ALG(Application Level Gateway)를 포함함을 특징으로 하며, 네트워크 주소에 충돌이 발생한 경우, 상기 RATA는 DHCP 서버를 제어하여 상기 서버에 포함된 장치의 서브넷 주소를 변환하는 것을 특징으로 하며,

본 발명의 또 다른 형태에 따르면, 상기 RATA는 서브넷 주소를 변환하기 위해 상기 서브넷 주소에 속한 장치가 사용하는IP 주소와 포트 정보를 상기 RAT 채널에서 사용하는 IP 주소와 미리 설정된 포트 정보로 변환하며, 상기 변환된 정보를 기반으로 지속적으로 해당 장치의 주소 변환을 수행하며, RAT 채널을 통해 수신되는 변환된 IP 패킷의 목적지 주소와 포트 정보를 원래 서브넷 IP 주소와 포트로 역변환하는 ALG(Application Level Gateway)를 포함함을 특징으로 한다.

본 발명은 UPnP 프로토콜을 이용한 원격 접속 서버에서 원격 접속 클라이언트 또는 원격 접속 서버에 접속한 경우, 상대편 원격 접속 서버 또는 클라이언트가 속한 네트워크에 동일한 IP 주소 영역에 속하는 IP 주소를 가지고 있는 장치가 존재함으로 인해 발생하는 네트워크 간의 라우팅 문제를 해결 할 수 있다.

또한, DHCP서버를 제어하여 IP 주소 충돌 문제를 해결하는 방법의 경우, 원격 접속 클라이언트 또는 원격 접속 서버가 IP 헤더 및 IP 페이로드의 IP 주소 변환을 위해 필요한 리소스를 제공하기 힘든 제한된 리소스를 가진 경우에도 적용할 수 있는 효과가 있다.

네트워크 상의 모든 기기가 DHCP FORCERENEW 명령어를 지원하는 경우에는 DHCP 서버를 제어하는 방법을 사용하고 DHCP를 통해서 IP 변경이 불가능한 경우에만 ALG(Application Level Gateway)를 이용한 IP 주소 변환을 이용함으로서 주소 변환을 최소화할 수 있다.

IP 주소 변환 방법에 있어서, 원격 접속 서버가 속한 네트워크 상의 기기의 IP 주소를 별도의 협상과정을 통해 결정된 다른 주소 영역의 서브넷 주소로 변환하는 것은 주소 변환 과정에서 패킷 헤더의 포트 번호와 메시지 본문에 사용된 포트 번호는 그대로 유지할 수 있으므로 주소 변환 과정을 상대적으로 간단히 할 수 있으며, 관리해야 하는 매핑 테이블의 크기를 줄여, 원격 접속 서버의 부하를 줄여 줄 수 있다.

한편, IP 주소 변환 방법에 있어서, 원격 접속 서버가 속한 네트워크 상의 기기의 IP 주소를 별도의 협상과정 없이 RAT 채널에서 사용하는 원격 접속 서버의 IP 주소와 동적으로 할당된 포트 번호로 매핑 변환하는 것은 변경할 주소 결정을 위한 절차에 따른 메시지 교환 시간 등을 절약하여 원격 접속 완료까지 걸리는 시간을 단축할 수 있는 효과가 있다.

도 1은 종래의 UPnP 원격 접속 아키텍쳐의 블록 구성도
도 2는 UPnP 원격 접속 서비스 동작 시 UPnP 장치간의 IP 주소가 동일하여 충돌이 발생한 상황을 도시한 예시도
도 3은 본 발명의 일 실시 예에 따른 UPnP 원격 접속 아키텍쳐의 블록 구성도
도 4는 본 발명의 실시 예에 따른 UPnP 원격 접속 서비스 동작 시 IP 주소의 충돌을 해결하기 위한 동작 흐름도
도 5는 본 발명의 실시 예에 따른 UPnP 원격 접속 서비스 동작 시 IP 주소의 충돌을 해결하기 위한 원격 접속 서버의 동작 흐름도
도 6은 Home-to-Home 원격 접속 서비스 동작 시 장치간의 IP 주소의 충돌이 발생한 경우를 도시한 예시도
도 7은 본 발명의 실시 예에 따른 충돌된 IP 주소를 업데이트하는 동작을 나타내는 예시도
도 8은 본 발명의 실시예에 따른 UPnP Home-to-Home 원격 접속 서비스 동작 시 충돌된 서브넷 주소를 변환하는 동작을 나타내는 예시도
도 9는 상기 도 8의 동작 시 ALG의 동작을 개략적으로 나타낸 예시도
도 10은 본 발명의 실시 예에 따른 UPnP Home-to-Home 원격 접속 서비스 동작 시 충돌된 서브넷 주소를 변환하는 동작을 나타내는 예시도

이하 첨부된 도면을 참조하여 본 발명을 구성하는 장치 및 동작 방법을 본 발명의 실시 예를 참조하여 상세히 설명한다. 하기 설명에서는 구체적인 구성 소자 등과 같은 특정 사항들이 나타나고 있는데 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐 이러한 특정 사항들이 본 발명의 범위 내에서 소정의 변형이나 혹은 변경이 이루어질 수 있음은 이 기술분야에서 통상의 지식을 가진 자에게는 자명하다 할 것이다. 또한, 본 발명을 설명함에 있어서 본 발명과 관련된 공지 기술에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에 그 상세한 설명을 생략하기로 한다.

도 3은 본 발명의 일 실시 예에 따른 UPnP 원격 접속 아키텍쳐의 블록 구성도이다. 도 3을 참조하면, 본 발명의 일 실시 예에 따른 UPnP 원격 접속 아키텍쳐는 도 1에서 설명한 기존의 UPnP 원격 접속 아키텍쳐에서 새로운 구성이 추가된다.

상세히 살펴보면, 원격 접속 서버(3200)에는 UPnP IP Management(3213) 서비스와 DHCP Control(3260) 모듈이 더 포함되며, 원격 접속 클라이언트(3100)에는 원격 접속 서버(3200)의 UPnP IP Management(3213) 서비스를 이용하는 IP Management 서비스 CP(3114)가 추가로 구성된다.

상기 구성은 실시 예 중 하나로서 IP Management(3213) 서비스, DHCP Control(3260) 모듈, IP Management Service CP(3114)의 위치는 다양한 형태로 구현될 수 있다.

본 발명의 제 1 실시 예로 IP Management 서비스를 별도로 정의한 경우에는, IP Management 서비스 CP(3114)는 자신이 속한 네트워크에서 사용 중인 IP 서브넷 주소 정보를 수집하여 상대방 네트워크, 즉 원격 접속 서버(3200)의 IP Management(3213) 서비스에 전달하는 역할을 담당한다.

UPnP IP Management(3213) 서비스 역시 자신이 속한 네트워크에서 사용 중인 IP 서브넷 주소 정보를 수집한 다음 IP Management CP(3114)가 보내온 IP 서브넷 주소 정보와 비교하여 IP 주소 충돌 여부를 판단한다. IP Management(3213) 서비스는 IP 주소 충돌을 감지한 경우, DHCP Control 모듈(3260)을 제어하여 네트워크 상의 모든 기기에 다른 IP 주소를 할당하도록 제어한다. 이를 위해 충돌이 생긴 IP 주소에 대한 해결이 완료될 때까지는 상기 원격 접속 서버(3200) 및 원격 접속 클라이언트(3100)의 RAT 인터페이스와 LAN 인터페이스 간의 라우팅은 일시적으로 정지된다.

원격 접속 서버(3200)가 게이트웨이 장치에 구현된 경우 원격 접속 서버(3200)가 DHCP 서버와 동일한 장치에 위치한다고 가정할 수 있으므로, RAS는 DHCP 서버를 내부 인터페이스 호출을 통해 제어하여 DHCP FORCERENEW 메시지를 DHCP 클라이언트(DHCP Client)로 전송함으로 충돌이 생긴 주소를 가지고 있는 장치에 새로운 IP 주소를 할당할 수 있다.

또 다른 방법으로는, DHCP 서버가 할당하는 IP 주소 영역에 대한 설정을 변경하고 네트워크 상의 모든 기기에 DHCPRELEASE 메시지를 전송하고, 해당 기기가 IP 할당을 재요청할 때 충돌이 발생하지 않도록 설정된 IP 주소 영역에 속하는 새로운 IP 주소를 할당할 수 있다.원격 접속 서버(3200)가 게이트웨이 장치와는 별도의 장치에서 동작하는 경우, 게이트웨이 장치는 DHCP 서버에 대한 제어를 제공하는 UPnP IGD(Internet Gateway Device) DCP를 구현하는 것이 바람직하며, 원격 접속 서버(3200)는 UPnP IGD CP를 이용하여 게이트웨이 장치 내의 DHCP 서버가 네트워크 상의 모든 기기에 DHCP FORCERENEW 메시지를 전송하도록 제어할 수 있다(현재 UPnP IGD 장치는 DHCP 서버에 대한 제어를 제공하지만, DHCP FORCERENEW 메시지를 전송하도록 제어하는 인터페이스를 제공하지 않음).

또 다른 방법으로는, 상기 UPnP IGD CP를 이용하여 게이트웨이 장치 내의 DHCP 서버의 IP 할당 주소 영역 설정값을 변경하고, DHCP 서버가 네트워크 상의 모든 기기에 DHCPRELEASE 메시지를 전송하도록 제어할 수 있다.

상기 과정을 통해 충돌이 생긴 IP 주소에 대한 재할당이 완료가 되면 원격 접속 서버(3200)와 원격 접속 클라이언트(3100)의 RAT 인터페이스와 LAN 인터페이스의 라우팅을 재개한다.

또한, 상기 실시 예에서 자신이 속한 네트워크에서 사용중인 IP 서브넷 주소 정보를 수집하는 동작은 IP Management 관련 모듈이 DHCP 서버로부터 DHCP 서버의 설정을 획득하는 방법이 사용될 수 있다.

도 4는 본 발명의 실시 예에 따른 UPnP 원격 접속 서비스 동작 시 IP 주소의 충돌을 해결하기 위한 원격 접속 클라이언트의 동작 흐름도이다. 도 4를 참조하면, 410단계에서 원격 접속 클라이언트는 자신이 속한 네트워크가 사용중인 IP 서브넷 주소 정보를 수집한다. 이 경우 본 발명의 제 1 실시 예의 경우에는 새로 추가된 IP Management CP(3114)에서 상기 동작을 수행할 수 있다. 다음 420단계에서는 상기 410단계에서 수집한 IP 서브넷 주소 정보를 원격 접속 서버로 전송한다.

도 5는 본 발명의 일 실시 예에 따른 UPnP 원격 접속 서비스 동작시 IP 주소의 충돌을 해결하기 위한 원격 접속 서버의 동작 흐름도이다.

도 5를 참조하면, 510단계에서 원격 접속 서버는 자신이 속한 네트워크가 사용중인 IP 서브넷 주소 정보를 수집한다. 다음 520단계에서 원격 접속 서버는 원격 접속 클라이언트로부터 원격 접속 클라이언트 측의 IP 서브넷 주소 정보를 수신한다. 다음 530단계에서 원격 접속 서버는 자신의 IP 서브넷 주소 정보와 상기 520단계에서 수신한 IP 서브넷 주소 정보를 비교한다. 다음 540단계에서 비교 결과 두 네트워크 간에 IP 주소의 충돌이 발생한지 판단한다. 상기 비교 결과 IP 주소의 충돌이 발생하였으면 550 단계로 진행하여 네트워크에 새로운 IP 주소를 할당한다. 상기 540 단계에서 IP 주소의 충돌이 발생하지 않았으면 종료한다. 이 경우 상기 실시 예의 경우에는 새로 추가된 IP Management(3213) 서비스에서 상기 동작을 수행할 수 있다.

도 6은 Home-to-Home 원격 접속 서비스 동작 시 장치 간의 IP 주소의 충돌이 발생한 경우를 도시한 예시도이다. 도 6은 제1원격 접속 서버(601, 이하 제1서버라 표기함)와 제2원격 접속 서버(602, 이하 제2서버라 표시함)가 원격 접속 서비스로 연결되어 있는 상태를 도시한다. 도 6의 제1서버(601)와 제2서버(602)가 속해 있는 네트워크는 192.168.1.0 (서브넷마스크 255.255.255.0) 대역의 서브넷으로 설정되어 있으며, 동일한 주소(192.168.1.3)의 네트워크 장치(608, 603)가 양측 서버에 동시에 할당되어 IP 주소 충돌이 발생한 상황을 나타낸다. 제1서버(601)와 제2서버(602) 각각에 프록시 ARP(Address Resolution Protocol)가 존재하는 경우 제2서버(602)가 속한 네트워크의 IP 주소 192.168.1.2를 갖는 장치(603)가 IP 주소 192.168.1.3의 장치 발견을 위해 ARP 요청(ARP Request) 메시지를 보내게 되면, 제1서버(601) 측의 IP주소 192.168.1.3을 갖는 장치(607)를 위한 제2서버(602)의 프록시 ARP와 네트워크 내의 IP 주소 192.168.1.3을 갖는 장치(608)가 동시에 응답하게 된다. 이로 인해 IP 주소를 필요한 하드웨어 주소로 변환하는 과정에 오동작이 발생하게 된다.

도 7은 본 발명의 실시 예에 따라 DHCP 서버를 이용하여 IP 주소 충돌을 방지하기 위한 원격 접속 시스템의 구성을 나타내는 예시도이다. 도 7은 두 서버(701, 702)가 원격 접속 서비스를 통해 연결된 상태를 나타낸다.

도 7은 본 발명의 실시 예에 따른 충돌된 IP 주소를 업데이트하는 동작을 나타내는 예시도이다. 도 7의 (a)는 두 서버(701, 702)가 원격 접속 서비스를 통해 연결된 상태를 나타내며, 도 7의 (b)는 각 서버(701, 702)의 네트워크에 연결된 장치들의 IP주소 정보를 개략적으로 나타낸 도면이며, 도 7의 (c)는 제2서버(702)가 포함하는 NAT 테이블의 정보를 나타낸다.

도 7을 참조하면, 먼저 제2서버(702)의 RADA 장치(706)는 제1서버(701)의 RADA 장치(707)의 DDD(Device Description Document)를 얻는다. 양 측의 가상 인터페이스에 할당된 IP 주소들은 VPN 서버에 의해 IP 주소들이 할당되었기 때문에 충돌이 발생하지 않으며, 따라서 RADA 장치들 간의 동기화는 정상적으로 이루어질 수 있다. 가상 인터페이스의 그것처럼 제1서버(701)와 제2서버(702) RADA(706, 707)의 DDD의 URL에 관련된 주소 공간은 동일할 수 있다.

제2서버(702)는 IP 주소의 충돌을 위해 도 7의 (c)에 도시된 바와 같은 NAT(Network Address Translation) 테이블(703)을 생성한다. 먼저 제2서버(702)는 710단계에서 로컬 네트워크와 원격 네트워크 간에 동일한 IP 주소가 존재하는지 비교하고, 동일한 IP 주소가 존재하는 경우 711단계에서 로컬 네트워크 이미지(image)를 위해 NAT 테이블(703)에 동일한 주소를 추가하며, NAT 테이블(703)에서 로컬 네트워크 image의 IP 주소를 타겟 주소로 변경한다. 712단계에서 제1서버(701)는 변경된 IP주소를 업데이트한다.

720단계에서 제2서버(702)는 원격 네트워크 이미지에 IP 주소들을 위해 로컬 인터페이스로 ARP Probe를 하나씩 방송(broadcast)하며, 이에 대해 721단계에서 Non-UPnP 장치(704)가 응답하면, 722단계에서 응답된 IP 주소들을 NAT 테이블(703)에 추가하며, NAT 테이블(703)에서 타겟 주소들에 대응되도록 로컬 네트워크 이미지에IP 주소들을 변경한다. 이에 따라 IP 주소가 충돌된 Non-UPnP 장치들도 응답할 수 있다.

제2서버(702)는 NAT 테이블(703)에 열거된 장치들을 위해 ALG(Application Level Gateway)로서 동작한다.

추가적으로, 랜(LAN)의 장치가 DHCP FORCERENEW 메소드를 지원하면, 제2서버(702)는 IP 주소를 해제하고 IP 주소를 재할당하기 위해 클라이언트에게 DHCP FORCERENEW 메세지를 전송할 수 있다.

원격 네트워크에 변경된 IP 주소들로 업데이트할 것을 요청한다.

제2서버(702)의 NAT 테이블(703)은 원격 네트워크에서 충돌된 IP 주소들로 업데이트된다.

730단계에서 제1서버(701)는 원격 네트워크 image의 IP 주소들을 위해 로컬 인터페이스에 ARP Probe를 하나씩 방송한다. 이에 대해 731단계에서 Non-UPnP 장치(705)가 응답하면, 740단계에서 제1서버(701)는 NAT 테이블(703)에 충돌된 IP 주소들을 추가할 것을 제2서버(702)에 요청한다. 이에 제2서버(702)는 741단계에서 충돌된 IP 주소를 업데이트하고, 742단계에서 NAT 테이블(703)에 충돌된 IP 주소들을 추가하고, 로컬 네트워크 이미지의 IP 주소들을 변경한다. 다음 743단계에서 제1서버(701)에서 변경된 IP 주소를 업데이트 한다.

NAT 테이블(703)은 ARP와 UPnP를 포함하는 모든 트래픽에서 IP 변경을 제공해야 한다. 유사하게 프록시 ARP는 ARP probe에 대한 응답 시 NAT 테이블(703)을 조회한다.

도 8은 본 발명의 실시 예에 따른 UPnP Home-to-Home 원격 접속 서비스 동작 시 충돌된 서브넷 주소를 변환하는 동작을 나타내는 예시도이다. 도 8은 IP주소 192.168.1.3의 UPnP 장치(814)와 IP주소 192.168.1.5의 Non-UPnP 장치가 포함된 제1서버(801)와, IP주소 192.168.1.2의 UPnP 장치(813)와 IP주소 192.168.1.3의 Non-UPnP 장치가 포함된 제2서버(802)가 원격 접속된 상황을 도시한다. 도 8에서는 제1서버(801)가 Home-to-Home 원격 접속을 위한 요청자(Requestor) 역할을 수행한다.

도 8에 도시한 바와 같이 RAT(RA Transport) 채널이 생성되면(850) 제2서버(802)는 일반적인 UPnP 원격 접속(Remote Access) 방법에 따라 제1서버(801)의 DDD(Device Description Document)를 획득할 수 있으며, 제1서버(801) 또한 일반적인 UPnP 원격 접속 방법에 따라 제2서버(802)의 DDD를 획득할 수 있다. 서로의 DDD를 획득한 제1서버(801)와 제2서버(802)는 각자가 속한 네트워크간의 IP 충돌 여부와는 상관없이 RADA(RA Discovery Agent) 장치와(803, 804) RADA 상의 서비스인 RADASync(805, 807) 서비스를 이용할 수 있게 된다. 본 발명의 실시 예로서 RADASync(805, 807) 서비스에 SetALGSubnetConfig() 액션을 정의할 수 있으며, 상기 액션의 아규먼트와 관련된 상태 변수는 하기 표 1과 같다.

Argument	Direction	relatedStateVariable
CurrentSubnet	IN	SubnetInfo
CurrentALGSubnetConfigList	IN	SubnetInfoList
NewALGSubnetConfig	OUT	SubnetInfo

제1서버(801)의 RADA 디바이스(803)의 RADASync CP(806)는 제2서버(802) RADA 디바이스(804)의 RADASync 서비스(807)의 상기 SetALGSubnetConfig() 액션을 호출함으로서 제1서버(801)가 속한 네트워크가 사용하는 서브넷 주소 정보 (192.168.1.0/24)와 제1서버(801) 상의 RATA(809)의 ALG(811)에 설정되어 있는 변환 서브넷 주소 목록을 제2서버(802) (NULL)에 전달한다(851). 상기와 같이 변환 서브넷 주소 목록을 제2서버(802)로 전달한 경우에, 제2서버(802)는 이전에 사용하던 변환 서브넷과의 충돌 여부를 확인하여 앞으로 변환에 사용할 서브넷 주소를 결정할 수 있다. 제2서버(802) RADA 디바이스(804)의 RADASync 서비스(807)는 먼저 제1서버(801)가 속한 서브넷 주소(192.168.1.0/24)가 제2서버(802)가 속한 서브넷 주소 (192.168.1.0/24)와 충돌이 발생하는지 확인하고(852), 충돌이 발생한 경우 제2서버(802)의 ALG(812)의 변환 서브넷 주소 대역을 설정한다(853). 이 때, 제1서버(801)의 ALG 변환 서브넷 주소 목록을 참조하여 이와 충돌하지 않는 대역의 서브넷 주소(10.66.1.0/24)를 선택한다. 이 후, 제2서버(802)가 속한 네트워크 상의 모든 기기의 IP 주소는 상기 과정을 통해 선택된 제2서버(802) ALG의 변환 서브넷 주소 (10.66.1.0/24)의 주소로 변환되어 제1서버(801)으로 전송될 것이다.

제2서버(802) RADA 디바이스(804)의 RADASync 서비스(807)는 상기 절차를 통해 제2서버(802)의 ALG 변환 주소 설정 후 해당 정보를 상기 액션의 응답으로 반환하며(854), 제1서버(801)는 응답에 포함된 변환 주소와 자신의 ALG(811)의 변환 주소 목록을 참조하여 충돌되지 않는 변환 서브넷 주소 대역을 선택할 수 있다 (10.32.4.0/24)(855). 제2서버(802)와 마찬가지로 이 후, 제1서버(801)가 속한 네트워크 상의 모든 기기의 IP 주소는 제1서버(801) ALG(811)의 변환 서브넷 주소 (10.32.4.0/24)의 주소로 변환되어 제2서버(802)로 전송될 것이다.

상기 과정을 통해 제1서버(801)과 제2서버(802)는 서로 충돌하지 않는 ALG(811, 812)의 변환 서브넷 주소 대역을 결정할 수 있다.

도 9는 상기 도 8의 동작 시 ALG의 동작을 개략적으로 나타낸 예시도이다. 도 9에서 ALG(812)는 내부에서 외부로 발송되는 IP 패킷 헤더의 소스 IP 주소를 설정된 변환 서브넷 주소 대역으로 변환하고 IP 패킷 페이로드의 IP주소 중 내부 서브넷 주소를 변환 서브넷 주소로 치환하는 역할을 담당한다(950). 반대로 외부에서 수신된 IP 패킷 헤더의 목적지 IP 주소를 내부 서브넷 주소로 변환하며, IP 패킷 페이로드의 IP 주소 중 변환 서브넷 주소를 내부 서브넷 주소로 치환하는 역할을 담당한다(951). 이 때, 프로토콜의 종류에 따라 다른 변환 방식을 적용할 수 있다. 예를 들어, HTTP 메시지의 경우 주소 변환으로 인한 'Content Length' 헤더 값 변경을 반영하기 위해 전체 HTTP 메시지를 버퍼링하여 본문의 IP 주소에 대해 변환을 한 후, 본문 길이를 재계산하여 Content Length 헤더 값을 업데이트할 수 있다.

도 9는 상기 과정을 통해 변환 서브넷 주소가 설정된 환경 하에서, 제2서버(802)가 속한 네트워크에 192.168.1.2의 IP 주소를 가진 기기(813)가 접속했을 때의 동작 예를 보인 것이다. 즉, 192.168.1.2의 IP 주소를 가진 기기(813)가 네트워크에 접속하면 제2서버(802) RADA 네트워크 이미지의 로컬(Local) 노드에 해당 기기(813)의 정보가 추가될 것이며, 제2서버(802) RADA 디바이스(804)의 RADASync CP(808)는 제1서버(801)에 해당 기기에 대한 정보를 추가하기 위한 SOAP 액션을 호출할 것이다. 제2서버(802)의 ALG(812)는 해당 메시지 내의 IP 주소(192.168.1.2)를 설정된 변환 서브넷 주소 (10.66.1.2)로 변환하며, 변환된 주소 (10.66.1.2)에 대한 HTTP GET 메시지에 대해서는 반대로 내부 IP 주소 (192.168.1.2)로 변환한다. 또한 이에 대한 응답으로 XML 형태의 디바이스 디스크립션(Device Description) 문서가 리턴될 경우 이에 포함되어 있는 모든 내부 IP 주소를 변환 서브넷 주소로 변환한다(952).

도 10은 본 발명의 실시 예에 따른 UPnP Home-to-Home 원격 접속 서비스 동작 시 충돌된 서브넷 주소를 변환하는 동작을 나타내는 예시도이다. 도 10은 상기 도 8에 도시된 시스템과 같은 IP 설정 환경을 가정한다. 도 8의 과정과 동일한 과정을 거쳐 DDD를 획득한 제1서버(801)와 제2서버(802)는 각자가 속한 네트워크간의 IP 충돌 여부와는 상관없이 RADA(RA Discovery Agent) 장치(803, 804)와 RADA 상의 서비스인 RADASync(805, 807) 서비스를 이용할 수 있게 된다. 본 발명의 다른 형태의 실시 예로서 RADASync(805, 807) 서비스에 GetSubnetInfo() 액션을 정의할 수 있으며, 상기 액션의 아규먼트와 관련된 상태 변수는 하기 표 2와 같다.

Argument	Direction	relatedStateVariable
LocalSubnetInfo	IN	SubnetInfo
RemoteSubnetInfo	OUT	SubnetInfo

1010단계에서 제1서버(801)의 RADA 디바이스(803)의 RADASync CP(806)는 제2서버(802) RADA 디바이스(804)의 RADASync 서비스(807)의 상기 GetSubnetInfo() 액션을 호출함으로서 제1서버(801)가 속한 네트워크가 사용하는 서브넷 주소 정보 (192.168.1.0/24)를 제2서버(802) 에 전달한다. 1020단계에서 제2서버(802) RADA 디바이스(804)의 RADASync 서비스(807)는 먼저 제1서버(801)가 속한 서브넷 주소(192.168.1.0/24)가 제2서버(802)가 속한 서브넷 주소 (192.168.1.0/24)와 충돌이 발생하는지 확인하고, 충돌이 발생한 경우 제2서버(802)의 ALG(812)를 활성화 시킨다. 이 후, 제2서버(802)가 속한 네트워크 상의 모든 기기의 IP 주소는 ALG에 의해 제2서버(802)가 RAT 채널에서 사용하는 IP 주소 10.8.1.1와 동적으로 기기에 할당한 포트 번호 쌍으로 변환되어 제1서버(801)로 전송될 것이다. 예를 들어, 도 10의 제2서버(802)가 속한 네트워크 상의 기기가 사용하는 IP 주소192.168.1.2 (포트번호 1900)는 10.8.1.1:46789로, 192.168.1.3 (포트번호 1900)은 10.8.1.1:46791로 각각 변환된다. 이 후, 제1서버(801)로부터 10.8.1.1:46789로 요청되는 모든 트래픽의 IP 주소와 포트번호는 IP 주소 192.168.1.2와 포트번호 1900으로 변환되어 제2서버(802)가 속한 네트워크로 전달된다. 상기 제2서버 (RAT 채널에서 사용하는 IP 주소: 10.8.1.1) 가 관리하는 IP 주소 매핑 테이블은 하기 표 3과 같다.

Private IP 주소	Port	할당 Port
192.168.1.2	1900	46789
192.168.1.3	1900	46791

한편, GetSubnetInfo() 액션을 호출한 상기 제1서버(801)는 액션의 결과값에 따라 상기 제2서버(802)와 유사하게 ALG(811)를 활성화 하고, 이 후 제1서버(801)가 속한 네트워크 상의 기기의 IP 주소를 제1서버(801)가 RAT 채널에서 사용하는 IP 주소 10.8.1.2와 동적으로 기기에 할당한 포트 번호 쌍으로 변환하여 제2서버(802)로 전송한다.

이러한 주소 변환은 IP 트래픽 헤더에 국한되는 것이 아니고, IP 페이로드 상의 IP 주소 및 포트에도 적용되어야 한다. 제1서버(801)와 제2서버(802)는 ALG(811, 812)가 처리하는 이러한 변환을 위해 충분한 프로세싱 능력과 메모리를 제공할 수 있어야 할 것이다.

상기와 같이 본 발명의 실시 예에 따른 UPnP 네트워크의 원격 접속 서비스에서 아이피 주소 충돌 해결 방법 및 장치의 구성 및 동작이 이루어질 수 있으며, 여러 가지 변형이 본 발명의 범위를 벗어나지 않고 실시될 수 있다.

Claims

UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서,
원격 접속 제1서버가 원격 접속 제2서버와 RAT(Remote Access Transport) 채널을 생성하는 과정과,
상기 제1서버가 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하는 과정과,
상기 제1서버가 상기 제1서버의 로컬 네트워크의 주소(address) 정보를 상기 제2서버로 전달하는 과정을 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 1항에 있어서, 상기 로컬 네트워크의 주소 정보는,
상기 로컬 네트워크의 서브넷 주소(subnet address) 정보임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 2항에 있어서, 상기 제1서버가 상기 제1서버의 로컬 네트워크의 주소 정보를 제2서버로 전달하는 과정은,
상기 제1서버가 상기 제1서버의 로컬 네트워크의 서브넷 주소(subnet address) 정보와 주소 충돌 시 변환할 서브넷 주소의 목록을 제2서버로 전달하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 장치들 간의 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서,
원격 접속 제2서버가 원격 접속 제1서버와 RAT(Remote Access Transport) 채널을 생성하는 과정과,
상기 제2서버가 상기 제1서버에게 DDD(device Description Document)를 전달하는 과정과,
상기 제2서버가 상기 제1서버로부터 상기 제1서버의 로컬 네트워크의 주소 정보를 수신하는 과정과,
상기 제2서버가 상기 제2서버의 네트워크의 주소 정보와 상기 수신한 제1서버의 네트워크의 주소 정보를 비교하여, 상기 제1서버와 제2서버의 네트워크의 주소에 충돌이 발생한지 판단하는 과정과,
상기 판단 결과 충돌이 발생한 경우, 충돌이 발생한 주소를 변환하는 과정을 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 4항에 있어서, 상기 서버는
상기 서버의 네트워크에 포함된 클라이언트 장치를 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 4항에 있어서, 상기 로컬 네트워크의 주소 정보는,
상기 로컬 네트워크의 서브넷 주소(subnet address) 정보임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 6항에 있어서, 상기 제1서버와 제2서버의 네트워크의 주소에 충돌이 발생한지 판단하는 과정은,
상기 제1서버와 상기 제2서버의 서브넷 주소가 동일한지 판단하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 7항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
상기 제2서버의 ALG(Application Level Gateway)가 충돌이 발생한 IP주소를 미리 설정된 다른 IP 주소로 변환하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 7항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
상기 제2서버의 ALG(Application Level Gateway)가 외부에서 인식하는 자신의 서브넷 주소를 미리 설정된 서브넷 주소로 변환하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 7항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
상기 제2서버가 DHCP(Dynamic Host configuration Protocol) 서버를 제어하여 상기 제2서버의 네트워크에 포함된 장치의 서브넷 주소를 변환하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 7항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
상기 제2서버의 ALG(Application Level Gateway)가 상기 제2서버에 포함된 장치의 IP 주소와 포트 정보를 RAT 채널에서 사용하는 IP 주소와 미리 설정된 포트 정보로 변환하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 서버들 간에 IP(Internet Protocol) 주소 충돌을 해결하기 위한 방법에 있어서,
원격 접속 제1서버와 원격 접속 제2서버가 RAT(Remote Access Transport) 채널을 생성하는 과정과,
상기 제2서버가 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 상기 제1서버로 전달하는 과정과,
상기 제2서버가, 상기 제1서버의 로컬 네트워크의 주소(address) 정보를 수신하는 과정과,
상기 제2서버의 네트워크의 주소 정보와 상기 수신한 제1서버의 네트워크의 주소 정보를 비교하여, 상기 제1서버와 상기 제2서버의 네트워크 주소 간에 충돌이 발생한지 판단하는 과정과,
상기 판단 결과 충돌이 발생한 경우, 충돌이 발생한 주소를 변환하는 과정을 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 12항에 있어서, 상기 로컬 네트워크의 주소 정보는,
상기 로컬 네트워크의 서브넷 주소(subnet address) 정보임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 13항에 있어서, 상기 제2서버가, 상기 제1서버의 로컬 네트워크의 주소(address) 정보를 수신하는 과정은,
상기 제2서버가, 상기 제1서버의 로컬 네트워크의 서브넷 주소(subnet address) 정보와 주소 충돌 시 변환할 서브넷 주소의 목록을 수신하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 14항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
상기 제2서버의 로컬 네트워크의 서브넷 주소를 상기 제1서버로부터 수신한 충돌 시 변환할 서브넷 주소 중 하나로 변환하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 13항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
상기 제2서버의 로컬 네트워크에 포함된 장치의 IP 주소와 포트 정보를, RAT 채널에서 사용하는 IP 주소와 동적으로 할당한 포트 정보로 변환하는 단계와,
상기 변환 정보를 기반으로 지속적으로 주소 변환을 수행하는 단계와,
상기 RAT 채널을 통해 상기 변환된 주소로 수신되는 IP 패킷의 목적지 주소와 포트 정보를 원래의 IP 주소와 포트로 역변환하는 단계를 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
제 13항에 있어서, 상기 충돌이 발생한 주소를 변환하는 과정은,
DHCP 서버를 제어하여 상기 제 2서버의 로컬 네트워크에 포함된 장치의 서브넷 주소를 변환하는 과정임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 방법.
UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 서버들 간에 IP(Internet Protocol) 주소 충돌을 해결하기 위한 시스템에 있어서,
원격 접속 제2서버와 RAT(Remote Access Transport) 채널을 생성하고, 상기 원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하며, 자신의 로컬 네트워크의 주소(address) 정보를 제2서버로 전달하는 제1서버와,
상기 원격 접속 제1서버와 RAT(Remote Access Transport) 채널을 생성하고, 상기 제1서버에게 DDD(device Description Document)를 전달하며, 상기 제1서버로부터 상기 제1서버의 로컬 네트워크의 주소 정보를 수신하며, 자신의 네트워크의 주소 정보와 상기 수신한 제1서버의 네트워크의 주소 정보를 비교하여, 상기 제1서버와 자신의 네트워크의 주소 간에 충돌이 발생한지 판단하며, 상기 판단 결과 충돌이 발생한 경우, 충돌이 발생한 주소를 변환하는 제 2서버를 포함함을 특징으로 하는 시스템.
제 18항에 있어서, 상기 로컬 네트워크의 주소 정보는,
상기 로컬 네트워크의 서브넷 주소(subnet address) 정보임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 시스템.
제 18항에 있어서, 상기 제 1서버가 자신의 로컬 네트워크의 주소(address) 정보를 제2서버로 전달하는 것은,
상기 제1서버의 로컬 네트워크의 서브넷 주소(subnet address) 정보와 주소 충돌 시 변환할 서브넷 주소의 목록을 제2서버로 전달하는 것임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 시스템.
제 20항에 있어서, 상기 제2서버는 상기 판단 결과 충돌이 발생한 경우, 상기 제2서버의 로컬 네트워크의 서브넷 주소를 상기 제1서버로부터 수신한 충돌 시 변환할 서브넷 주소 중 하나로 변환하는 것을 특징으로 하는 IP 주소 충돌을 해결하기 위한 시스템.
제 19항에 있어서, 상기 제2서버는
상기 판단 결과 충돌이 발생한 경우, 상기 제2서버의 로컬 네트워크에 포함된 장치의 IP 주소와 포트 정보를, RAT 채널에서 사용하는 IP 주소와 동적으로 할당한 포트 정보로 변환하며, 상기 변환 정보를 기반으로 지속적으로 주소 변환을 수행하며, 상기 RAT 채널을 통해 상기 변환된 주소로 수신되는 IP 패킷의 목적지 주소와 포트 정보를 원래의 IP 주소와 포트로 역변환하는 ALG(Application Level Gateway)를 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 시스템.
제 19항에 있어서, 상기 제2서버는 상기 판단 결과 충돌이 발생한 경우, DHCP 서버를 제어하여 상기 제 2서버의 로컬 네트워크에 포함된 장치의 서브넷 주소를 변환하는 것을 특징으로 하는 IP 주소 충돌을 해결하기 위한 시스템.
UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 서버들 간에 IP(Internet Protocol) 주소 충돌을 해결하기 위한 상기 서버에 있어서,
원격 접속 상대방 측 서버와 RAT(Remote Access Transport) 채널을 생성하는 RATA(Remote Access Transport Agent)와,
원격 접속 서비스를 통해 상기 제2서버의 DDD(Device Description Document)를 획득하며, 자신의 로컬 네트워크의 주소(address) 정보를 수집하여 상기 상대방 측 서버로 전달하는 RADA(Remote Access Discovery Agent)를 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
제 24항에 있어서, 상기 로컬 네트워크의 주소 정보는,
상기 로컬 네트워크의 서브넷 주소(subnet address) 정보임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
제 25항에 있어서, 상기 자신의 로컬 네트워크의 주소 정보를 상기 상대방 측 서버로 전달하는 것은,
상기 서버가 자신의 로컬 네트워크의 서브넷 주소(subnet address) 정보와 주소 충돌 시 변환할 서브넷 주소의 목록을 상기 상대방 측 서버로 전달하는 것임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
UPnP(Universal Plug and Play) 원격 접속 서비스에서 원격 접속 서버들 간에 IP(Internet Protocol) 주소 충돌을 해결하기 위한 상기 서버에 있어서,
상기 상대방 측 서버와 RAT(Remote Access Transport) 채널을 생성하는 RATA(Remote Access Transport Agent)와,
상기 원격 접속 서비스를 통해 원격 접속 상대방 측 서버로 DDD(Device Description Document)를 전달하며, 상기 상대방 측 서버로부터 상기 상대방 측 서버의 로컬 네트워크의 주소 정보를 수신하며, 상기 서버의 로컬 네트워크의 주소 정보와 상기 수신한 상대방 측 서버의 네트워크의 주소 정보를 비교하여, 상기 서버와 상기 상대방 측 서버의 네트워크 주소에 충돌이 발생한지 판단하는 RADA(Remote Access Discovery Agent)를　포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
제 27항에 있어서, 상기 로컬 네트워크의 주소 정보는,
상기 로컬 네트워크의 서브넷 주소(subnet address) 정보임을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
제 28항에 있어서, 상기 서버는,
상기 판단 결과 충돌이 발생한 경우, 상기 서버의 로컬 네트워크의 서브넷 주소를 상기 상대방 측 서버로부터 수신한 충돌 시 변환할 서브넷 주소 중 하나로 변환하는 ALG(Application Level Gateway)를 더 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
제 28항에 있어서, 상기 서버는
상기 판단 결과 충돌이 발생한 경우, 상기 서버의 로컬 네트워크에 포함된 장치의 IP 주소와 포트 정보를, RAT 채널에서 사용하는 IP 주소와 동적으로 할당한 포트 정보로 변환하며, 상기 변환 정보를 기반으로 지속적으로 주소 변환을 수행하며, 상기 RAT 채널을 통해 상기 변환된 주소로 수신되는 IP 패킷의 목적지 주소와 포트 정보를 원래의 IP 주소와 포트로 역변환하는 ALG(Application Level Gateway)를 더 포함함을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.
제 28항에 있어서, 상기 서버는
상기 판단 결과 충돌이 발생한 경우, DHCP(Dynamic Host configuration Protocol) 서버를 제어하여 상기 서버에 포함된 장치의 서브넷 주소를 변환하는 것을 특징으로 하는 IP 주소 충돌을 해결하기 위한 원격 접속 서버.