KR20150094630A

KR20150094630A - M2m(machine-to-machine)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치

Info

Publication number: KR20150094630A
Application number: KR1020157015421A
Authority: KR
Inventors: 안홍범; 김성윤; 최희동; 정승명; 박승규
Original assignee: 엘지전자 주식회사
Priority date: 2013-01-11
Filing date: 2014-01-10
Publication date: 2015-08-19
Also published as: KR101740449B1; EP2945326B1; CN104904164B; US9717027B2; EP2945326A1; US20150358874A1; EP2945326A4; CN104904164A; WO2014109597A1

Abstract

본 발명은 제1 계층과 제2 계층을 포함하는 M2M(Machine-to-Machine) 시스템에서 제한된 능력(constrained capability)을 갖는 적어도 하나의 M2M 디바이스와 통신하는 M2M 게이트웨이에 의해 수행되는 게이트웨이 변경 방법 및 이를 위한 장치에 관한 것으로서, 상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 트리거 신호를 수신하는 단계; 및 상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 제1 통지를 M2M 서버로 전송하는 단계를 포함하되, 상기 제한된 능력을 갖는 M2M 디바이스는 상기 제1 계층을 갖지 않는 디바이스이고, 상기 제한된 능력을 갖는 M2M 디바이스의 상기 제2 계층에서 생성되는 데이터는 상기 M2M 게이트웨이의 상기 제1 계층에 의해 트리 구조의 데이터 구조(data structure)에서 관리 또는 저장되며, 상기 통지가 상기 M2M 서버로 전송된 후 상기 데이터를 포함하는 상기 데이터 구조가 상기 M2M 서버에 의해 회수(retrieve)되는 방법 및 이를 위한 장치에 관한 것이다.

Description

M2M(MACHINE-TO-MACHINE)시스템에서 게이트웨이 변경 방법 및 이를 위한 장치{METHOD FOR CHANGING GATEWAY IN MACHINE-TO-MACHINE (M2M) SYSTEM AND DEVICE THEREFOR}

본 발명은 무선 통신 시스템에 관한 것으로서, 구체적으로 M2M(Machine-to-Machine) 시스템에서 게이트웨이를 변경하는 방법 및 이를 위한 장치에 관한 것이다.

근래에 들어 M2M(Machine-to-Machine) 통신에 대한 관심이 높아지고 있다. M2M 통신은 사람의 개입 없이 기계(Machine)와 기계 사이에 수행되는 통신을 의미하며, MTC(Machine Type Communication) 또는 IoT(Internet of Things) 통신으로도 지칭된다. M2M 통신에 사용되는 단말을 M2M 디바이스(M2M device)라고 지칭하는데, M2M 디바이스는 일반적으로 낮은 이동성(low mobility), 시간 내성(time tolerant) 또는 지연 내성(delay tolerant), 작은 데이터 전송(small data transmission)등과 같은 특성을 가지며, 기계 간 통신 정보를 중앙에서 저장하고 관리하는 M2M 서버와 연결되어 사용된다. 또한, M2M 디바이스가 서로 다른 통신 방식을 따라 연결되면, 통신 방식이 변경되는 구간에서 M2M 게이트웨이를 통해 M2M 디바이스와 M2M 서버가 연결되며, 이를 통해 전체 M2M 시스템이 구성된다. 해당 시스템을 기반으로 사물 추적(Tracking), 전력 계량(Metering), 자동 지불 시스템(Payment), 의료 분야 서비스, 원격 조정 등의 서비스가 제공될 수 있다.

본 발명은 M2M 시스템에 관한 것이다.

본 발명의 목적은 M2M 시스템에서 효율적으로 신호를 송수신하는 방법 및 이를 위한 장치를 제공하는 데 있다. 본 발명의 다른 목적은 M2M 시스템에서 효율적으로 M2M 게이트웨이를 변경하는 방법 및 이를 위한 장치를 제공하는 데 있다. 본 발명의 또 다른 목적은 M2M 시스템에서 M2M 게이트웨이를 변경하는 동안 데이터를 유실하지 않게 하는 방법 및 이를 위한 장치를 제공하는 데 있다. 본 발명의 또 다른 목적은 M2M 시스템에서 M2M 게이트웨이 변경 과정 동안 M2M 서비스 중단을 최소화하는 방법 및 이를 위한 장치를 제공하는 데 있다.

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

본 발명의 일 양상으로, 제1 계층과 제2 계층을 포함하는 M2M(Machine-to-Machine) 시스템에서 제한된 능력(constrained capability)을 갖는 적어도 하나의 M2M 디바이스와 통신하는 M2M 게이트웨이에 의해 수행되는 게이트웨이 변경 방법이 제공되며, 상기 방법은 상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 트리거 신호를 수신하는 단계; 및 상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 제1 통지를 M2M 서버로 전송하는 단계를 포함하되, 상기 제한된 능력을 갖는 M2M 디바이스는 상기 제1 계층을 갖지 않는 디바이스이고, 상기 제한된 능력을 갖는 M2M 디바이스의 상기 제2 계층에서 생성되는 데이터는 상기 M2M 게이트웨이의 상기 제1 계층에 의해 트리 구조의 데이터 구조(data structure)에서 관리 또는 저장되며, 상기 통지가 상기 M2M 서버로 전송된 후 상기 데이터를 포함하는 상기 데이터 구조가 상기 M2M 서버에 의해 회수(retrieve)될 수 있다.

본 발명의 다른 양상으로, 제1 계층과 제2 계층을 포함하는 M2M(Machine-to-Machine) 시스템에서 제한된 능력(constrained capability)을 갖는 적어도 하나의 M2M 디바이스와 통신하는 게이트웨이가 제공되며, 상기 게이트웨이는 RF(Radio Frequency) 유닛; 및 프로세서를 포함하며, 상기 프로세서는 상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 트리거 신호를 수신하고, 상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 제1 통지를 M2M 서버로 전송하도록 구성되며, 상기 제한된 능력을 갖는 M2M 디바이스는 상기 제1 계층을 갖지 않는 디바이스이고, 상기 제한된 능력을 갖는 M2M 디바이스의 상기 제2 계층에서 생성되는 데이터는 상기 M2M 게이트웨이의 상기 제1 계층에 의해 트리 구조의 데이터 구조(data structure)에서 관리 또는 저장되며, 상기 통지가 상기 M2M 서버로 전송된 후 상기 데이터를 포함하는 상기 데이터 구조가 상기 M2M 서버에 의해 회수(retrieve)될 수 있다.

바람직하게는, 상기 제1 계층은 상기 M2M 시스템이 공통(common)으로 제공하는 서비스들을 포함하는 공통 서비스 계층이고, 상기 제2 계층은 특정 M2M 애플리케이션을 실행하는 애플리케이션 계층일 수 있다.

바람직하게는, 상기 데이터 구조는 게이트웨이 변경 상태를 지시하는 제1 정보와 대상 게이트웨이의 식별 정보를 지시하는 제2 정보를 포함하며, 상기 트리거 신호는 상기 제1 정보의 값이 특정 값으로 설정되는 것을 포함할 수 있다.

바람직하게는, 상기 데이터 구조는 상기 M2M 서버를 위한 제1 하위 데이터 구조를 포함하고, 상기 제1 통지는 제1 하위 데이터 구조의 URI(Universal Resource Identifier)를 포함할 수 있다.

바람직하게는, 상기 M2M 서버는 상기 URI를 이용하여 상기 데이터 구조를 회수(retrieve) 및 저장할 수 있다.

바람직하게는, 상기 데이터 구조는 상기 M2M 디바이스를 위한 제2 하위 데이터 구조를 포함하고, 상기 방법은 상기 제1 계층을 통해 게이트웨이 변경을 지시하는 제2 통지를 상기 M2M 디바이스로 전송하는 단계를 포함하되, 상기 M2M 디바이스는 상기 제2 통지를 수신한 후 게이트웨이 변경이 완료될 때까지 상기 M2M 게이트웨이로 어떠한 정보도 전송하지 않을 수 있다.

본 발명에 의하면, M2M 시스템에서 효율적으로 신호를 송수신할 수 있다. 또한, 본 발명에 의하면, M2M 시스템에서 효율적으로 M2M 게이트웨이를 변경할 수 있다. 또한, 본 발명에 의하면, M2M 시스템에서 M2M 게이트웨이를 변경하는 동안 데이터를 유실하지 않게 할 수 있다. 또한, 본 발명에 의하면, M2M 시스템에서 M2M 게이트웨이 변경 과정 동안 M2M 서비스 중단을 최소화할 수 있다.

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

첨부 도면은 본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되며, 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 사상을 설명한다.
도 1은 M2M 시스템을 예시한다.
도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.
도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다.
도 4는 M2M 시스템의 구성을 예시한다.
도 5는 M2M 시스템에서 사용되는 리소스(resource)를 예시한다.
도 6은 특정 M2M 애플리케이션을 위한 리소스를 예시한다.
도 7은 M2M 시스템의 일 예를 예시한다.
도 8은 본 발명에 따른 게이트웨이 교체 방법을 예시한다.
도 9는 본 발명이 적용될 수 있는 장치의 블록도를 예시한다.

본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시예를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시예를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 본 발명이 속하는 분야에서 통상의 기술자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.

몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다. 또한, 본 명세서에서 동일한 구성요소에 대해 동일한 도면 부호가 사용될 수 있다.

본 명세서에서, M2M 디바이스(M2M device)는 M2M 통신을 위한 디바이스를 지칭한다. M2M 디바이스는 고정되거나 이동성을 가질 수 있으며 M2M 서버와 통신하여 사용자 데이터 및/또는 제어 정보를 송수신할 수 있다. M2M 디바이스는 단말(Terminal Equipment), MS(Mobile Station), MT(Mobile Terminal), UT(User Terminal), SS(Subscribe Station), 무선 장치(wireless device), PDA(Personal Digital Assistant), 무선 모뎀(wireless modem), 휴대 장치(handheld device) 등으로 지칭될 수 있다. 본 발명에 있어서, M2M 서버는 M2M 통신을 위한 서버를 지칭하며 고정국(fixed station) 또는 이동국(mobile station)을 지칭한다. M2M 서버는 M2M 디바이스들 및/또는 다른 M2M 서버와 통신하여 데이터 및 제어 정보를 교환할 수 있다. 또한, 본 발명에 있어서, M2M 게이트웨이는 M2M 디바이스가 연결된 네트워크와 M2M 서버가 연결된 네트워크가 서로 다른 경우, 한 네트워크에서 다른 네트워크로 들어가는 연결점 역할 수행하는 장치를 지칭한다.

또한, 본 명세서에서 “엔티티(entity)”라는 용어는 M2M 디바이스, M2M 게이트웨이, M2M 서버와 같은 하드웨어를 지칭하는 데 사용될 수 있고, 또는 아래에서 설명되는 M2M 애플리케이션 계층과 M2M (공통) 서비스 계층의 소프트웨어 컴포넌트(software component)를 지칭하는 데 사용될 수 있다.

도 1은 M2M 시스템을 예시한다. 도 1은 ETSI(European Telecommunications Standards Institute) 기술 규격(Technical Specification, TS)에 따른 M2M 시스템을 예시한다.

ETSI TS M2M 기술 규격에 따른 M2M 시스템은 다양한 M2M 애플리케이션(Application)을 위한 공통 M2M 서비스 프레임워크(Service Framework)를 정의한다. M2M 애플리케이션은 e헬스(e-Health), 도시 자동화(City Automation), 커넥티드 컨슈머(Connected Consumer), 오토모티브(Automotive)와 같은 M2M 서비스 솔루션을 구현하는 소프트웨어 컴포넌트(software component)를 지칭할 수 있다. M2M 시스템에서는 이러한 다양한 M2M 애플리케이션을 구현하기 위해 공통적으로 필요한 기능들을 제공되며, 공통적으로 필요한 기능들은 M2M 서비스 또는 M2M 공통 서비스라고 지칭될 수 있다. 이러한 M2M 공통 서비스를 이용하면 각 M2M 애플리케이션마다 기본 서비스 프레임워크를 다시 구성할 필요 없이 M2M 애플리케이션이 쉽게 구현될 수 있다.

M2M 서비스는 서비스 능력(Service Capability, SC)의 형태로 제공되며, M2M 애플리케이션은 오픈 인터페이스(open interface)를 통해 SC(Service Capability)에 접근하고 SC(Service Capability)가 제공하는 M2M 서비스를 이용할 수 있다. SC(Service Capability)는 M2M 애플리케이션이 서비스 프레임워크 상에서 제공될 때 사용할 수 있는 M2M 서비스의 기능(function)들의 집합이라고 할 수 있다. SC(Service Capability)는 SC 엔티티(Service Capability Entity)와 SC 계층(Service Capability Layer)을 통칭할 수 있다.

SC(Service Capability)는 xSC로 표현될 수 있다. 여기서, x는 N/G/D 중의 하나로 표현될 수 있으며, SC(Service Capability)가 네트워크(Network)(및/또는 서버), 게이트웨이(Gateway), 디바이스(Device) 중 어디에 존재하는지를 나타낸다. 예를 들어, NSC는 네트워크 및/또는 서버 상에 존재하는 SC(Service Capability)를 나타내고, GSC는 게이트웨이 상에 존재하는 SC(Service Capability)를 나타낸다.

M2M 애플리케이션은 네트워크, 게이트웨이, 또는 디바이스 상에 존재할 수 있다. 네트워크 상에 존재하거나 서버와 직접 연결되어 존재하는 M2M 애플리케이션은 M2M 네트워크 애플리케이션(M2M Network Application)라고 지칭되며 간략히 NA(Network Application)로 나타낼 수 있다. 예를 들어, NA는 서버에 직접 연결되어 구현되는 소프트웨어이며, M2M 게이트웨이 또는 M2M 디바이스와 통신하고 이들을 관리하는 역할을 수행할 수 있다. 디바이스 상에 존재하는 M2M 애플리케이션은 M2M 디바이스 애플리케이션(M2M Device Application)이라고 지칭되며 간략히 DA(Device Application)로 나타낼 수 있다. 예를 들어, DA는 M2M 디바이스에서 구동되는 소프트웨어이며, 센서 정보 등을 NA에게 전달할 수도 있다. 게이트웨이 상에 존재하는 M2M 애플리케이션은 M2M 게이트웨이 애플리케이션(Gateway Application)이라고 지칭되며 간략히 GA(Gateway Application)로 나타낼 수 있다. 예를 들어, GA는 M2M 게이트웨이를 관리하는 역할도 할 수 있고 DA에게 SC(Service Capability)를 제공할 수도 있다. M2M 애플리케이션은 애플리케이션 엔티티(AE)와 애플리케이션 계층을 통칭할 수 있다.

도 1을 참조하면, M2M 시스템 아키텍처는 네트워크 도메인과 디바이스 및 게이트웨이 도메인으로 구분될 수 있다. 네트워크 도메인은 M2M 시스템 관리를 위한 기능(function)들과 네트워크 관리를 위한 기능(function)들을 포함할 수 있다. M2M 시스템 관리를 위한 기능은 디바이스 및 게이트웨이 도메인에 존재하는 디바이스들을 관리하는 M2M 애플리케이션과 M2M SC(Service Capability)에 의해 수행될 수 있고, 네트워크 관리를 위한 기능은 코어 네트워크와 액세스 네트워크에 의해 수행될 수 있다. 따라서, 도 1의 예에서, 코어 네트워크와 액세스 네트워크는 M2M 기능을 수행한다기보다는 각 엔티티들 간의 연결을 제공한다. 코어 네트워크와 액세스 네트워크를 통해 네트워크 도메인과 디바이스 및 게이트웨이 도메인에서 M2M SC(Service Capability) 간에 M2M 통신이 수행될 수 있으며, 각 도메인의 M2M 애플리케이션은 각 도메인의 M2M SC(Service Capability)를 통해 신호 또는 정보를 주고 받을 수 있다.

액세스 네트워크(Access Network)는 M2M 디바이스 및 게이트웨이 도메인이 코어 네트워크와 통신을 가능하게 하는 엔티티이다. 액세스 네트워크의 예로는 xDSL(Digital Subscriber Line), HFC(Hybrid Fiber Coax), 위성(satellite), GERAN, UTRAN, eUTRAN, 무선(Wireless) LAN, WiMAX 등이 있다.

코어 네트워크(Core Network)는 IP(Internet Protocol) 연결, 서비스와 네트워크 제어, 상호연결, 로밍(roaming) 등의 기능을 제공하는 엔티티이다. 코어 네트워크는 3GPP(3rd Generation Partnership Project) 코어 네트워크, ETSI TISPAN(Telecommunications and Internet converged Services and Protocols for Advanced Networking) 코어 네트워크와 3GPP2 코어 네트워크 등을 포함한다.

M2M SC(Service Capability)는 여러 M2M 네트워크 애플리케이션들에서 공유될 수 있는 M2M 공통 서비스 기능(Common Service Function, CSF)을 제공하고 M2M 서비스를 오픈 인터페이스(open interface)를 통해 노출하여 M2M 애플리케이션들이 M2M 서비스를 이용할 수 있게 한다. M2M SC(Service Capability) 엔티티는 공통 서비스 기능(CSF)의 하나의 인스턴스로 이해될 수 있으며 M2M 애플리케이션들에 의해 사용되고 공유될 수 있는 공통 서비스 기능(CSF)들의 서브세트를 제공한다. M2M SCL(Service Capability Layer)은 이러한 M2M SC 엔티티를 포함하는 계층을 지칭할 수 있다.

M2M 애플리케이션은 서비스 로직(service logic)을 동작시키고, 오픈 인터페이스를 통해 M2M SC(Service Capability)를 사용할 수 있는 엔티티이다. M2M 애플리케이션 계층은 이러한 M2M 애플리케이션 및 관련 동작 로직(operational logic)을 포함하는 계층을 지칭할 수 있다.

M2M 디바이스는 M2M SC(Service Capability)를 통해 M2M 디바이스 애플리케이션을 동작시키는 엔티티이다. M2M 디바이스는 직접 네트워크 도메인의 M2M 서버와 통신할 수도 있으며, M2M 게이트웨이를 통해서 네트워크 도메인의 M2M 서버와 통신할 수도 있다. M2M 게이트웨이를 통해서 연결될 경우에는 M2M 게이트웨이는 프록시(proxy)와 같이 동작한다. M2M 디바이스는 M2M 애플리케이션 및/또는 M2M SC(Service Capability)를 포함할 수 있다.

M2M 영역 네트워크(M2M area network)는 M2M 디바이스와 M2M 게이트웨이 간의 연결(connectivity)을 제공한다. 이 경우, M2M 게이트웨이와 M2M 서버 간 네트워크와 M2M 디바이스와 M2M 게이트웨이 간 네트워크가 서로 상이할 수 있다. 예를 들어, M2M 영역 네트워크는 IEEE802.15.1, 지그비(Zigbee), 블루투스(Bluetooth), IETF ROLL, ISA100.11a와 같은 PAN(Personal Area Network) 기술과 PLC(Power Line Communication), M-BUS, 무선 M-BUS, KNX와 같은 로컬 네트워크 기술을 이용하여 구현될 수 있다.

M2M 게이트웨이는 M2M SC(Service Capability)를 통해 M2M 애플리케이션을 관리하고 M2M 애플리케이션에 대해 서비스를 제공하는 엔티티이다. M2M 게이트웨이는 M2M 디바이스와 네트워크 도메인간의 프록시 역할을 수행하고 ETSI 비-호환(non-compliant) M2M 디바이스에도 서비스를 제공하는 역할을 수행할 수 있다. M2M 게이트웨이는 M2M 디바이스들 중 게이트웨이 기능을 갖는 엔티티를 지칭할 수 있다. M2M 게이트웨이는 M2M 애플리케이션 및/또는 M2M SC(Service Capability)를 포함할 수 있다.

도 1에 예시된 M2M 시스템 아키텍처는 예시에 불과하고 각 엔티티의 명칭은 달라질 수 있다. 예를 들어, oneM2M 기술 규격에 따른 시스템(oneM2M 시스템이라 지칭)에서 M2M SC(Service Capability)는 M2M 공통 서비스 엔티티(common service entity, CSE)로 지칭될 수 있고, SCL(Service Capability Layer)는 공통 서비스 계층(Common Service Layer, CSL)으로 지칭될 수 있다. 또한, M2M 애플리케이션은 애플리케이션 엔티티(application entity, AE)로 지칭될 수 있고, M2M 애플리케이션 계층은 간략히 애플리케이션 계층으로 지칭될 수 있다. 마찬가지로, 각 도메인의 명칭 또한 달라질 수 있다. 예를 들어, oneM2M 시스템에서 네트워크 도메인은 인프라스트럭처 도메인(infrastructure domain)으로 지칭될 수 있고, 디바이스 및 게이트웨이 도메인은 필드 도메인(field domain)으로 지칭될 수 있다.

도 1에 예시된 바와 같이, M2M 시스템은 M2M 통신을 위해 M2M 애플리케이션 계층과 M2M SC(Service Capability) 계층을 포함하는 계층 구조로서 이해될 수 있다.

도 2는 M2M 시스템의 계층 구조(layered structure)를 예시한다.

도 2를 참조하면, M2M 시스템은 애플리케이션 계층(202), 공통 서비스 계층(204), 기저 네트워크 서비스 계층(underlying network services layer)(206)을 포함할 수 있다. 앞서 설명된 바와 같이, 애플리케이션 계층(202)은 M2M 애플리케이션 계층에 대응되고, 공통 서비스 계층(204)은 M2M SCL에 대응될 수 있다. 기저 네트워크 서비스 계층(206)은 코어 네트워크에 존재하는 장치 관리(device management), 위치 서비스(location service), 및 장치 트리거링(device triggering)과 같은 서비스들을 공통 서비스 계층(204)에 제공한다.

도 3은 M2M 시스템의 기능적 아키텍처(functional architecture)를 예시한다. 기능적인 측면에서 M2M 시스템 아키텍처는 애플리케이션 엔티티(application entity, AE)(302), 공통 서비스 엔티티(common service entity, CSE)(304), 기저(underlying) 네트워크 서비스 엔티티(network service entity, NSE)(306)를 포함할 수 있다. 각 엔티티들(302, 304, 306)은 공통 서비스 엔티티(304)가 지원하는 기준점(reference point)을 통해 통신할 수 있다. 기준점(reference point)은 각 엔티티들(302, 304, 306) 간의 통신 흐름(communication flow)를 지정하는 역할을 한다. 기준점은 Mcx로 표현될 수 있고 Mc는 “M2M communications”을 의미한다. 본 명세서에서 Mca 기준점, Mcc 기준점, Mcn 기준점은 각각 Mca, Mcc, Mcn으로 표기될 수 있다.

도 3을 참조하면, Mca 기준점(312)은 애플리케이션 엔티티(AE)(302)와 공통 서비스 엔티티(CSE)(304)의 통신 흐름을 지정한다. Mca 기준점(312)은 AE(302)가 CSE(304)에 의해 제공되는 서비스를 이용할 수 있게 하고 CSE(304)가 AE(302)와 통신할 수 있게 한다. Mca 기준점(312)은 M2M 애플리케이션 계층과 M2M 공통 서비스 계층 간의 인터페이스를 지칭할 수 있다.

Mcc 기준점(314)은 서로 다른 공통 서비스 엔티티(CSE)(304)들 간의 통신 흐름을 지정한다. Mcc 기준점(314)은 CSE(304)가 필요한 기능들을 제공할 때 다른 CSE의 서비스를 이용할 수 있게 한다. Mcc 기준점(314)을 통해 제공되는 서비스는 CSE(304)가 지원하는 기능들에 의존적일 수 있다. Mcc 기준점(312)은 M2M 공통 서비스 계층들 간의 인터페이스를 지칭할 수 있다.

Mcn 기준점(316)은 CSE(304)와 기저 네트워크 서비스 엔티티(NSE)(306) 간의 통신 흐름을 지정한다. Mcn 기준점(316)은 CSE(304)가 요구된 기능들을 제공하기 위해 기저 NSE(306)가 제공하는 서비스를 이용할 수 있게 한다. Mcn 기준점(312)은 M2M 공통 서비스 계층과 M2M 기저 네트워크 계층 간의 인터페이스를 지칭할 수 있다.

또한, 도 3의 예에서, CSE(304)는 다양한 공통 서비스 기능(common service function, CSF)들을 제공할 수 있다. 예를 들어, CSE(304)는 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management) 기능, 통신 관리 및 전달 처리(Communication Management and Delivery Handling) 기능, 데이터 관리 및 저장(Data Management and Repository) 기능, 장치 관리(Device Management) 기능, 그룹 관리(Group Management) 기능, 발견(Discovery) 기능, 위치(Location) 기능, 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering) 기능, 등록(Registration) 기능, 보안(Security) 기능, 서비스 과금 및 계산(Service Charging and Accounting) 기능, 서비스 세션 관리 기능(Service Session Management), 구독/통지(Subscription/Notification) 기능 중에서 적어도 하나를 포함할 수 있다. CSE(304)는 상기 공통 서비스 기능들의 인스턴스(instance)를 가리키며, M2M 애플리케이션들이 사용하고 공유할 수 있는 공통 서비스 기능들의 서브세트를 제공한다. 공통 서비스 기능들을 개략적으로 설명하면 다음과 같다.

- 애플리케이션 및 서비스 계층 관리(Application and Service Layer Management, ASM) : AE들과 CSE들의 관리 기능을 제공한다. 예를 들어, ASM 기능은 CSE들의 기능을 설정(configure)하고 문제점을 해결(troubleshoot)하고 업그레이드(upgrade)할 뿐만 아니라 AE들의 기능을 업그레이드할 수 있다.

- 통신 관리 및 전달 처리(Communication Management and Delivery Handling, CMDH): 다른 CSE들, AE들, NSE들과의 통신을 제공한다. 예를 들어, CMDH 기능은 CSE-CSE 통신(CSE-to-CSE communication)을 위한 연결(connection)을 언제 어떻게 사용할지를 결정하고 특정 요청들이 지연 전달될 수 있도록 제어할 수 있다.

- 데이터 관리 및 저장(Data Management and Repository, DMR): M2M 애플리케이션들이 데이터를 교환, 공유할 수 있게 한다. 예를 들어, DMR 기능은 대량의 데이터를 수집(collecting)/병합(aggregating)하고 데이터를 특정 포맷으로 변환(converting)하고 저장(storing)할 수 있다.

- 장치 관리(Device Management, DMG): M2M 게이트웨이 및 M2M 디바이스 뿐만 아니라 M2M 영역 네트워크에 존재하는 디바이스들에 대한 디바이스 기능을 관리한다. 예를 들어, DMG 기능은 애플리케이션 설치 및 설정, 펌웨어(Firmware) 업데이트, 로깅(Logging), 모니터링(Monitoring), 진단(Diagnostics), 네트워크 토폴로지(Topology) 관리 등을 수행할 수 있다.

- 발견(Discovery, DIS): 주어진 범위 및 조건 내에서 요청에 따라 정보 및 리소스(resource)와 같은 정보를 검색(searching)한다.

- 그룹 관리(Group Management, GMG): 예를 들어 리소스(resource), M2M 디바이스, 또는 M2M 게이트웨이를 묶어 그룹을 생성할 수 있는데 그룹 관련 요청을 핸들링(handling)한다.

- 위치(Location, LOC): M2M 애플리케이션이 M2M 디바이스 또는 M2M 게이트웨이의 위치 정보를 획득하는 역할을 수행한다.

- 네트워크 서비스 노출/서비스 실행 및 트리거링(Network Service Exposure/ Service Execution and Triggering, NSSE): 기저 네트워크의 통신을 가능하게 하고 기저 네트워크가 제공하는 서비스 또는 기능을 사용할 수 있게 한다.

- 등록(Registration, REG): M2M 애플리케이션 또는 다른 CSE가 특정 CSE에 등록을 처리하는 역할을 수행한다. 등록은 특정 CSE의 M2M 서비스 기능을 사용하기 위해 수행된다.

- 보안(Security, SEC): 보안 키와 같은 민감한 데이터 핸들링, 보안 연관 관계(Association) 설립, 인증(Authentication), 권한 부여(Authorization), ID(Identity) 보호 등의 역할을 수행한다.

- 서비스 과금 및 계산(Service Charging and Accounting, SCA): CSE에 과금 기능을 제공하는 역할을 수행한다.

- 서비스 세션 관리(Service Session Management, SSM): 단대단(end-to-end) 통신을 위한 서비스 계층의 M2M 세션을 관리하는 역할을 수행한다.

- 구독/통지(Subscription/Notification, SUB): 특정 리소스(resource)에 대한 변경을 구독(Subscription)하면 해당 리소스(resource)이 변경되면 이를 통지(notification)하는 역할을 수행한다.

도 4는 M2M 시스템의 구성을 예시한다. 본 명세서에서, 노드(node)는 하나 이상의 M2M 애플리케이션을 포함하는 엔티티 또는 하나의 CSE와 0개 이상의 M2M 애플리케이션을 포함하는 엔티티를 의미한다.

애플리케이션 전용 노드(Application Dedicated Node, ADN)는 적어도 하나의 애플리케이션 엔티티(AE)를 가지지만 공통 서비스 엔티티(CSE)를 가지지 않는 노드를 지칭할 수 있다. ADN은 Mca를 통해 하나의 중간 노드(Middle Node, MN) 또는 하나의 인프라스트럭처 노드(Infrastructure Node, IN)와 통신할 수 있다. ADN은 제한된 능력을 갖는 M2M 디바이스(M2M device having a constrained capability)로 지칭될 수 있는데, 제한된 능력을 갖는 M2M 디바이스는 공통 서비스 계층(common service layer) 또는 공통 서비스 엔티티(CSE)를 포함하지 않는 M2M 디바이스를 지칭할 수 있다. 제한된 능력을 갖는 M2M 디바이스는 간략히 제한적인 M2M 디바이스(constrained M2M device)라고 지칭될 수 있다.

애플리케이션 서비스 노드(Application Service Node, ASN)는 적어도 하나의 공통 서비스 엔티티(CSE)를 가지고 적어도 하나의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. ASN은 Mcc를 통해 하나의 중간 노드(Middle Node) 또는 하나의 인프라스트럭처 노드(Infrastructure Node)와 통신할 수 있다. ASN은 M2M 디바이스로 지칭될 수 있다.

중간 노드(Middle Node, MN)는 하나의 공통 서비스 엔티티(CSE)와 0개 이상의 M2M 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. MN은 Mcc를 통해 하나의 인프라스트럭처 노드(IN) 또는 다른 중간 노드(MN)와 통신할 수 있으며, 혹은 Mcc를 통해 IN/MN/ASN과 통신할 수 있으며, 혹은 Mca를 통해 ADN과 통신할 수 있다. MN은 M2M 게이트웨이로 지칭될 수 있다.

인프라스트럭처 노드(Infrastructure Node, IN)는 하나의 공통 서비스 엔티티(CSE)를 가지고 0개 이상의 애플리케이션 엔티티(AE)를 가지는 노드를 지칭할 수 있다. IN은 Mcc를 통해 적어도 하나의 중간 노드(MN)와 통신할 수 있고, 및/또는 적어도 하나의 ASN과 통신할 수 있다. 혹은 IN은 Mca를 통해 하나 이상의 ADN과 통신할 수 있다. IN은 M2M 서버로 지칭될 수 있다.

도 4를 참조하면, case 1은 ADN(402)과 IN(422) 간의 통신을 예시한다. ADN(402)은 제한된 능력을 갖는 M2M 디바이스일 수 있다. 이 경우, ADN(402)은 CSE 또는 공통 서비스 계층을 갖지 않으므로 Mca를 통해 IN(422)의 CSE와 통신할 수 있다. 또한, 이 경우, ADN(402)은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 저장할 수 없다. 따라서, case 1에서 ADN(402)의 AE 또는 애플리케이션 계층에서 생성된 데이터는 IN(422)의 CSE에 저장될 수 있다.

case 2는 ADN(404)과 MN(414) 간의 통신을 예시한다. ADN(404)도 제한된 능력을 갖는 M2M 디바이스일 수 있다. 따라서, ADN(404)이 MN(414)의 CSE과 통신한다는 점을 제외하고 case 1과 유사하게 동작할 수 있다. 즉, ADN(404)은 Mca를 통해 MN(414)의 CSE와 통신할 수 있다. 또한, ADN(404)은 CSE 또는 공통 서비스 계층을 갖지 않으므로 AE 또는 애플리케이션 계층에서 생성된 데이터를 저장할 수 없다. 따라서, ADN(404)의 AE 또는 애플리케이션 계층에서 생성된 데이터는 MN(414)의 CSE에 저장될 수 있다.

한편, case 2에서 MN(414)은 MN(412)을 거쳐 IN(422)과 통신할 수 있다. 이 경우 MN(414)과 MN(412), 그리고 MN(412)과 IN(422)은 Mcc를 통해 통신할 수 있다. MN(414)이 MN(412)을 거치지 않고 직접 IN(422)과 통신하는 것도 가능하다.

case 3은 ASN(406)과 MN(414) 간의 통신을 예시한다. case 1 또는 case 2와 달리, ASN(406)은 CSE 또는 공통 서비스 계층을 가지므로 ASN(406)의 AE 또는 애플리케이션 계층에서 생성된 데이터를 자신의 CSE 또는 공통 서비스 계층에 저장할 수 있다. 또한, ASN(406)의 AE는 ASN(406)의 CSE를 통해 MN(414)의 CSE와 통신할 수 있다.

case 4는 ASN(408)과 MN(414) 간의 통신을 예시한다. case 3과 비교하여, ASN(408)의 CSE는 MN을 거치지 않고 직접 IN(422)의 CSE와 통신할 수 있다.

IN(422 또는 424)은 인프라스트럭처 도메인 또는 네트워크 도메인에 위치할 수 있고 하나의 CSE를 포함하고 0개 이상의 AE를 포함할 수 있다. IN들(422, 424)은 Mcc를 통해 서로 통신할 수 있다.

도 5는 M2M 시스템에서 사용되는 리소스(resource)를 예시한다.

M2M 시스템에서 애플리케이션 엔티티(AE), CSE, 데이터 등은 리소스(resource)로서 표현될 수 있다. M2M 시스템에서 리소스는 고유한 주소(예, URI(Universal Resource Identifier 또는 Uniform Resource Identifier))를 이용하여 고유하게 어드레싱될 수 있는 데이터 구조를 지칭한다. M2M 시스템에서 리소스는 트리 구조를 가질 수 있으며 CSE 또는 공통 서비스 계층에 의해 관리되고 저장되며 서로 논리적으로 연결될 수 있다. 따라서, M2M 디바이스, M2M 게이트웨이, M2M 서버의 CSE 또는 공통 서비스 계층에서는 이러한 리소스를 가질 수 있다. 반면, M2M 시스템의 AE 또는 애플리케이션 계층에서는 이러한 리소스 구조를 가질 수 없다. 트리 구조를 가지는 M2M 리소스에서 baseURI는 루트 리소스이며 baseURI는 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다.

M2M 시스템에서는 다양한 리소스가 정의되는데 M2M 애플리케이션들은 리소스를 기반으로 통신을 수행할 수 있다. 예를 들어, 애플리케이션을 등록하고 센서 값을 읽어 오는 등의 M2M 서비스를 수행하는 데 사용될 수 있다. 각각의 리소스는 인스턴스가 생성될 때 고유한 주소 정보(예, URI)가 주어지며, 루트 리소스와 동일하게 속성 및 자녀 리소스를 가질 수 있으며 각 리소스들은 고유한 주소 정보를 이용하여 어드레싱될 수 있다.

속성은 리소스 자체에 대한 정보를 저장하며 자녀 리소스를 가질 수 없다. 자녀 리소스는 자신의 속성과 자신의 자녀 리소스를 가질 수 있으며, 예를 들어 자녀 리소스에는 CSE 리소스, 애플리케이션 리소스(Application Resource), 접근 권한 리소스(Access Right Resource), 컨테이너 리소스(Container Resource), 그룹 리소스(Group Resource), 구독 리소스(Subscription Resource), 발견 리소스(Discovery Resource) 등이 있다.

- CSE 리소스는 baseURI/entity 하위에 존재하는 리소스로서 해당 CSE에 등록(연결)된 다른 CSE의 정보를 포함한다.

- 애플리케이션 리소스(Application Resource): baseURI/application 또는 baseURI/entity/(특정CSE)/application 하위에 존재하는 리소스이며, baseURI/application의 하위에 존재할 경우 해당 CSE에 등록(연결)된 애플리케이션들의 정보가 저장되며, baseURI/cses/(특정CSE)/application 하위에 존재할 경우 “(특정CSE)”라는 이름을 가진 CSE에 등록된 애플리케이션들의 정보를 저장한다.

- 접근 권한 리소스(AccessRight Resource) : baseURI/accessRight 하위에 존재하는 리소스이며, 접근 권한과 관련된 정보를 저장하는 리소스이다. 본 리소스에 포함된 접근 권한 정보를 이용하여 권한 부여(authorization)가 이루어질 수 있다.

- 컨테이너 리소스(Container Resource) : baseURI/container 하위에 존재하는 리소스이며, CSE 또는 AE 별로 생성되는 데이터를 저장한다.

- 그룹 리소스(Group Resource) : baseURI/group 하위에 존재하는 리소스이며, 여러 리소스를 하나로 묶어 함께 처리할 수 있도록 하는 기능을 제공한다.

- 구독 리소스(Subscription Resource) : baseURI/subscription 하위에 존재하는 리소스이며, 리소스의 상태가 변경되는 것을 통지(Notification)를 통해 알려주는 기능을 수행한다.

- 발견 리소스(Discovery Resource) : baseURI/discovery 하위에 존재하는 리소스이며, 특정 리소스를 찾는 데 사용된다.

도 6은 특정 M2M 애플리케이션을 위한 리소스를 예시한다. 앞서 설명된 바와 같이, 특정 M2M 애플리케이션을 위한 리소스는 M2M 게이트웨이의 CSE 또는 공통 서비스 계층의 리소스에서 애플리케이션 리소스(Application Resource)에 저장될 수 있다. 특정 M2M 애플리케이션을 위한 리소스는 전체 리소스와 유사하게 속성(attribute)과 자녀 리소스(child resource)를 가질 수 있다. 도 6에서 notificationChannels 리소스는 구독 리소스(Subscription Resource)에 관련된 리소스일 수 있다.

도 7은 M2M 시스템의 일 예를 예시한다. 도 7은 스마트 그리드 제어 애플리케이션이 스마트 플러그들을 이용하여 전력 제어를 수행하는 예가 예시한다. 스마트 플러그들(smartPlug_1 내지 smartPlug_n)은 ADN을 포함하는 M2M 디바이스로서 동작한다. 각 M2M 디바이스(smartPlug_1 내지 smartPlug_n)는 제한된 능력을 갖는 M2M 디바이스(또는 제한적인 M2M 디바이스)이며 CSE(Common Service Entity)를 갖지 않는다. 따라서, 스마트 플러그에서 생성되는 데이터(예, 전력 검침 정보)는 자체적으로 저장될 수 없으며 스마트 플러그들에 연결된 M2M 게이트웨이 또는 M2M 서버에 저장될 수 있다. 도 7의 예에서, 스마트 플러그들은 M2M 게이트웨이로서 동작하는 홈 게이트웨이(home gateway)에 연결되며 스마트 플러그에서 생성되는 데이터는 모두 홈 게이트웨이에 저장될 수 있다.

도 7을 참조하면, 홈 게이트웨이는 CSE를 가지며 스마트 플러그 애플리케이션들을 위해 트리 구조의 데이터 구조(또는 리소스)를 관리하고 저장할 수 있다. 예를 들어, 홈 게이트웨이에서 관리/저장되는 리소스는 루트에 주소 값 “201.32.42.32”를 가지며 201.32.42.32/application/ 하위에 상기 스마트 플러그들을 위한 리소스를 생성한다. 각각의 스마트 플러그들의 속성과 데이터 정보는 201.32.42.32/application 하위의 해당 리소스에 저장될 수 있다. 예를 들어, SmartPlug_1의 데이터 정보(예, 전력 데이터 정보)는 201.32.42.32/application/smartPlug_1/container 이하에 저장될 수 있다. 또한, SmartPlug_1의 속성 정보는 201.32.42.32/application/smartPlug_1의 attribute 필드들에 저장될 수 있다. 각 스마트 플러그들은 속성이 바뀌거나 새로운 데이터가 생성될 때마다 Mca를 통해 홈 게이트웨이의 리소스 또는 데이터 구조에 저장할 수 있다.

한편, M2M 시스템에서 M2M 게이트웨이는 다양한 이유로 변경될 수 있다. 예를 들어, 단말이 다수의 게이트웨이를 변경하면서 호핑하는 경우, 하나의 M2M 단말에 대해 복수의 M2M 게이트웨이가 서비스를 연결해주는 경우, 또는 일정한 이유로 기존의 게이트웨이가 1대1로 변경되는 경우에 M2M 게이트웨이가 변경될 수 있다. 기존의 게이트웨이가 1대1로 변경되는 경우는 1:1로 게이트웨이가 기존 디바이스(old device)에서 신규 디바이스(new device)로 교체(replace)되는 경우의 서비스 형태를 의미한다. 예를 들어, 펌웨어 업데이트(Firmware update) 또는 배터리 교체 등과 같은 유지 관리 목적(maintenance reason)이나 고장으로 인해 게이트웨이가 1:1로 교체될 수 있다.

M2M 시스템에서 M2M 게이트웨이가 1:1로 변경되는 경우 다음과 같은 문제점이 발생할 수 있다. 새로운 게이트웨이가 교체된 후 M2M 디바이스들에 대해 서비스를 바로 재개하기 위해서는 새로운 게이트웨이가 M2M 애플리케이션들의 설정 정보를 그대로 유지하고 있어야 한다. 하지만, 기존 게이트웨이와 통신하는 M2M 애플리케이션들의 설정 정보가 게이트웨이 변경으로 인해 모두 삭제될 수 있다. M2M 디바이스들은 기존의 서비스 형태를 그대로 유지해야 한다. 해당 정보는 M2M 게이트웨이를 통해서 연결되는 경우에 M2M 게이트웨이에 저장되므로, M2M 게이트웨이가 변경/교체 되는 경우에는 변경/교체 후 해당 설정 정보를 M2M 디바이스와 M2M 게이트웨이간 재설정해야 한다.

하나의 M2M 게이트웨이에 아주 많은 수의 M2M 디바이스가 연결되는 경우를 고려하면, 문제는 더욱 심각해질 수 있다. M2M 게이트웨이가 설정 정보를 유실하는 경우, 새로운 게이트웨이와 다량의 M2M 애플리케이션들 간에 설정 정보를 재설정하기 위해 많은 지연이 발생할 수 있다. 따라서, 새로운 게이트웨이는 해당 정보를 기반으로 수행되는 서비스를 끊김없이(Seamlessly) 제공할 수 없다.

특히, ADN은 CSE를 갖지 않으므로 설정 정보 또는 데이터를 자체적으로 유지할 수 없으므로, ADN과 통신하는 M2M 게이트웨이의 경우 M2M 게이트웨이의 교체로 인해 M2M 게이트웨이 저장된 모든 설정 정보와 데이터가 유실될 수 있다. 이로 인해, M2M 게이트웨이가 교체될 때 상기 M2M 게이트웨이와 통신하는 모든 ADN들의 데이터 및 관리 정보가 유실되거나 다시 설정해야 하는 문제가 발생할 수 있다.

이에, 본 발명에서는 M2M 시스템에서 M2M 게이트웨이를 변경할 때 애플리케이션 설정 정보 및 데이터가 유실되지 않고 M2M 서비스의 끊김을 최소화할 수 있는 게이트웨이 교체(gateway replacement) 방법을 제안한다. 본 발명에 따른 방법은 아래와 같이 2가지 사항을 고려한다. 이하에서 M2M 게이트웨이는 편의상 게이트웨이로 지칭되고 M2M 디바이스는 디바이스로 지칭될 수 있다.

- 게이트웨이가 변경될 필요가 있는 경우, M2M 게이트웨이에 등록된 리소스들은 게이트웨이가 변경되는 동안 어떤 장소에서 어떤 방법으로든 유지되어야 한다. 그렇지 않은 경우, 게이트웨이에 저장된 리소스들은 게이트웨이 변경 후에 다시 등록되어야 하고 이는 운영적인 측면에서 디바이스와 게이트웨이 모두에게 부담일 수 있다.

- 변경되는 게이트웨이와 통신하는 애플리케이션들은 게이트웨이가 교체되는 동안 변경되는 게이트웨이와 통신하지 않도록 교체 과정을 인지할 필요가 있다. 그렇지 않은 경우, 애플리케이션들이 변경되는 게이트웨이로 전송하는 패킷들은 유실될 수 있으며, 애플리케이션들의 설정 정보 또는 데이터가 역시 유실될 수 있다.

도 8은 본 발명에 따른 게이트웨이 교체 방법을 예시한다. 도 8에서 수신자(receiver)(810)는 M2M 디바이스 애플리케이션(device application 또는 DA)을 나타내고, 수신자(810)는 M2M 디바이스의 애플리케이션 엔티티(AE) 또는 애플리케이션 계층에 해당할 수 있다. 또한, 수신자(810)는 애플리케이션 전용 노드(ADN)일 수 있으며 공통 서비스 엔티티(CSE) 또는 공통 서비스 계층을 포함하지 않을 수 있다.

개시자(issuer)(820)는 M2M 게이트웨이 애플리케이션(gateway application 또는 GA) 또는 M2M 네트워크 애플리케이션(network application 또는 NA)을 나타내고, 개시자(820)는 M2M 게이트웨이(또는 중간 노드(MN))의 애플리케이션 엔티티(AE) 또는 애플리케이션 계층에 해당할 수 있다. 로컬 SCL-1(830)은 기존 게이트웨이(old gateway)의 SCL(Service Capability Layer)을 나타내고, 로컬 SCL-2(840)는 새로운 게이트웨이(new gateway) 또는 대상 게이트웨이(target gateway)의 SCL을 나타낸다. 로컬 SCL-1(830)과 로컬 SCL-2(840)은 각각 M2M 게이트웨이(또는 중간 노드(MN))의 CSE 또는 공통 서비스 계층에 해당할 수 있다.

원격 SCL(remote SCL)(850)은 M2M 서버의 SCL(Service Capability Layer)을 나타내고, 원격 SCL(850)은 M2M 서버(또는 인프라스트럭처 노드(IN))의 CSE 또는 공통 서비스 계층에 해당할 수 있다.

도 8을 참조하면, S802 단계에서, 등록과 같은 과정 및 서비스 과정을 통해 애플리케이션들(예, 810, 820)에 대한 리소스가 로컬 SCL-1(830)에 저장될 수 있다.

S804 단계에서, 개시자(820)는 게이트웨이 교체 과정을 개시하기 위해 게이트웨이 교체를 지시하는 트리거 신호를 발생시킬 수 있다. 트리거 신호는 예를 들어 리소스를 업데이트하는 UPDATE 신호일 수 있다. 상기 트리거 신호는 소프트웨어를 통해 자동으로 발생되거나, 외부의 관리 포털 등의 명령으로부터 발생되거나, 사용자와의 상호작용을 통해 발생될 수 있다.

또한, S804 단계에서, 상기 트리거 신호를 발생시키기 위해 개시자(820)는 M2M 공통 서비스 계층을 통해 트리거 신호를 기존 게이트웨이(로컬 SCL-1(830))의 리소스 중 “replacement”라고 하는 컨테이너(container)에 다음과 같이 정보를 저장할 수 있다.

상기 예에서, <replacementStatus>와 </replacementStatus>에 의해 구분되는 정보는 게이트웨이 변경 상태를 지시하는 정보이며, 예를 들어 True 또는 False와 같은 불린(boolean) 값을 가질 수 있다. 예를 들어, 그 값이 True인 경우 게이트웨이 교체가 트리거된 상태를 지시하고, 그 값이 False인 경우 게이트웨이 교체가 트리거되지 않은 일반 상태를 지시할 수 있다. 상기 값과 상태 간의 관계는 달라질 수 있다. 또한, 예를 들어, 교체 상태 정보는 False를 디폴트(default)로 가질 수 있다. 다른 예에서, 상기 정보는 다른 데이터 타입을 가질 수 있다.

게이트웨이 교체가 외부의 상황에 따라 계획적으로 발생하는 경우 기존 게이트웨이가 대상 게이트웨이의 식별 정보를 알 수 있다. 기존 게이트웨이가 대상 게이트웨이를 아는 경우 기존 게이트웨이의 리소스에 대상 게이트웨이의 식별 정보를 추가할 수 있는데, 이는 <replacingDeviceID> 와 </replacingDeviceID>에 의해 구분될 수 있다. 또한 식별 정보의 타입은 <replacingDeviceID type= >에 의해 지정될 수 있다. 상기 예에서, 대상 게이트웨이의 식별 정보의 타입은 MAC(Medium Access Control) 주소로 설정될 수 있다. MAC 주소 이외에 다른 유형의 게이트웨이 식별 정보가 사용될 수도 있다. 또한, 펌웨어 업데이트를 수행하는 경우 게이트웨이 교체가 자체적으로 발생할 수 있으며 자기 자신의 식별 정보(예, Self reference)를 추가할 수 있다.

S806 단계에서, 로컬 SCL-1(830)은 상기 트리거 신호를 수락하는 경우 긍정적으로(positively) 응답할 수 있다.

S808 단계에서, 로컬 SCL-1(830)은 M2M 공통 서비스 계층을 통해 수신자(810)에게 게이트웨이 교체 과정의 개시를 통지할 수 있다. 예를 들어, 로컬 SCL-1(830)은 자신의 리소스 중에서 수신자(810)의 식별 정보(예, URI)가 가리키는 리소스의 구독 리소스(subscription resource)의 컨택 속성(contact attribute)을 이용하여 통지를 전송할 수 있다. 이 통지를 수신하면, 수신자(810)는 게이트웨이 교체 과정이 완료될 때까지 어떠한 요청 또는 정보도 외부로 전송하지 않을 수 있다. 다른 예로, 수신자(810)가 로컬 SCL-1(830)로 요청 또는 정보를 전송하더라도 상기 요청 또는 정보는 수신자(810)에 계류중(pending)인 상태에 있도록 구현될 수 있다.

S810 단계에서, 수신자(810)는 상기 통지에 긍정적으로 응답할 수 있다.

S812 단계에서, S806 단계와 유사하게, 로컬 SCL-1(830)은 M2M 공통 서비스 계층을 통해 원격 SCL(850)에게 게이트웨이 교체 과정의 개시를 통지할 수 있다. 예를 들어, 로컬 SCL-1(830)은 자신의 리소스 중에서 원격 SCL(850)의 식별 정보(예, URI)가 가리키는 리소스의 구독 리소스(subscription resource)의 컨택 속성(contact attribute)를 이용하여 통지를 전송할 수 있다. 이 통지를 수신하면, 원격 SCL(850)은 게이트웨이 교체 과정이 완료될 때까지 로컬 SCL-1(830)으로 어떠한 요청 또는 정보도 전송하지 않을 수 있다. 다른 예로, 원격 SCL(850)이 로컬 SCL-1(830)로 요청 또는 정보를 전송하더라도 상기 요청 또는 정보는 원격 SCL(850)에 계류중(pending)인 상태에 있도록 구현될 수 있다.

다른 예로, S812 단계에서 로컬 SCL-1(830)로부터 원격 SCL(850)로의 통지는 로컬 SCL-1(830)의 리소스에 대한 주소 정보(예, URI)를 포함할 수 있다. 예를 들어, 상기 주소 정보는 <backup>과 </backup>에 의해 표현될 수 있다. 이 경우, 로컬 SCL-1(830) 리소스의 루트 주소가 201.32.42.32/baseURI인 경우 S812 단계의 통지는 <backup>201.32.42.32/baseURI</backup>로서 표현되는 정보를 포함할 수 있다. M2M 서버(예, 원격 SCL(850))는 이 주소 정보를 기반으로 SCL-1(830) 리소스를 회수(retrieve)하여 백업할 수 있다.

S814 단계에서, 원격 SCL(850)은 상기 요청의 유효성을 검사(check)하고 상기 개시자(820)가 리소스를 업데이트하는 데 필요한 접근 권한(access rights)을 가진다는 것을 승인(validate)할 수 있다. 그런 다음, 원격 SCL(850)은 상기 리소스를 업데이트할 것을 요청하고 게이트웨이 교체 전에 상기 리소스를 백업(backup)하기 위해 기존 게이트웨이의 리소스를 자동으로 회수(retrieve)할 수 있다. 예를 들어, 원격 SCL(850)이 상기 리소스를 회수할 때 상기 S812 단계에서 통지된 로컬 SCL-1(830) 리소스를 가리키는 URI(예,<backup>201.32.42.32/baseURI</backup>)가 사용될 수 있다.

S816 단계에서, 원격 SCL(850)은 기존 게이트웨이의 리소스와 관련된 요청에 긍정적으로 응답할 수 있다. 이 때, 기존 게이트웨이(830)는 M2M 시스템에서 제거될 수 있는 상태에 있다.

S818 단계에서, 로컬 SCL-1(830)의 리소스는 원격 SCL(850)로 옮겨져 원격 SCL(850)에 저장된 상태이다.

S820 단계에서, 기존 게이트웨이(830)가 M2M 시스템에서 제거된 후, 로컬 SCL-2(840)(또는 새로운 게이트웨이)가 등록 요청을 원격 SCL(850)로 전송할 수 있다. 예를 들어, 게이트웨이 등록 요청은 CREATE 메시지일 수 있으며, CREATE 메시지는 등록에 관련한 정보, 게이트웨이 교체를 지시하는 지시 정보, 및 기존 게이트웨이의 식별 정보를 포함할 수 있다. 기존 게이트웨이의 식별 정보는 수동으로 또는 OMA(Open Mobile Alliance) 장치 관리(DM) 프로토콜을 통해 대상 게이트웨이에게 미리 제공될 수 있다.

S822 단계에서, 원격 SCL(850)은 상기 게이트웨이 등록 요청이 유효한지 여부를 검사하거나 또는 상기 게이트웨이 등록 요청이 게이트웨이 교체 요청 인지를 판단할 수 있다. 이는 S804 단계에서 제공한 대상 게이트웨이(예, 로컬 CSE-2(840))의 식별 정보가 등록 요청에 포함된 게이트웨이 식별자와 동일한 경우나, S820 단계에서 제공한 기존 게이트웨이(예, 로컬 CSE-1(830))의 식별 정보가 원격 SCL(850)에 백업된 정보와 일치 여부로 판단할 수 있다. 만일 유효한 경우, 원격 SCL(850)은 긍정적으로 응답할 수 있는데, 이 때 응답 신호는 원격 SCL(850)에 저장된 기존 게이트웨이(예, 로컬 CSE-1(830))의 리소스가 저장된 주소 정보(예, URI)를 포함할 수 있다. 또한, 상기 응답 신호는 로컬 SCL-2(840)에게 적정한 접근 권한(proper access right)을 부여(grant)할 수 있다.

S824 단계에서, 로컬 SCL-2(840)는 로컬 SCL-1(830)의 리소스를 획득하기 위해 원격 SCL(850)로 회수 요청을 전송할 수 있다. 예를 들어, 회수 요청은 RETRIEVE 메시지일 수 있다. 로컬 SCL-2(840)는 S822 단계에서 수신된 리소스의 주소 정보를 기반으로 기존 게이트웨이(예, 로컬 SCL-1(830))의 리소스를 회수(retrieve)하여 자신의 CSE 또는 공통 서비스 계층에 저장할 수 있다.

S826 단계에서, 원격 SCL(850)은 기존 게이트웨이의 리소스와 함께 긍정적으로 응답할 수 있다. 로컬 SCL-2(840)는 상기 리소스를 수신한 다음, 기존 애플리케이션들에게 리소스 루트 주소의 업데이트를 알릴 수 있다.

S828 단계에서, 로컬 SCL-1(830)의 리소스는 로컬 SCL-2(840)에 저장될 수 있다.

S830 단계에서, 로컬 SCL-2(840)(또는 새로운 게이트웨이)는 게이트웨이 교체 과정이 완료되었음을 수신자(810)에게 통지할 수 있다.

S832 단계에서, 수신자(810)는 긍정적으로 응답할 수 있다. 그런 다음, 수신자(810)는 생성된 요청 또는 정보를 로컬 SCL-2(840)로 전송할 수 있다.

S834 단계에서, 로컬 SCL-2(840)는 원격 SCL(850)에게 게이트웨이 교체 과정이 완료되었음을 통지할 수 있다.

S836 단계에서, 원격 SCL(850)은 긍정적으로 응답할 수 있다. 그런 다음, 원격 SCL(850)은 생성된 요청 또는 정보를 로컬 SCL-2(840)로 전송할 수 있다.

S808 단계 또는 S812 단계에서 게이트웨이 교체 통지를 수신한 수신자(810) 또는 원격 SCL(850)이 요청 또는 정보를 전송하였으나 계류중인(pending) 상태에 있는 것이 있다면, 게이트웨이 교체 과정이 완료된 후 목적지로 전송될 수 있다.

도 8의 각 단계들은 예시적이며 도 8의 단계들 중 일부는 생략되고 실시되거나 도 8에 도시되지 않은 다른 단계들이 포함되어 실시될 수 있다. 또한, 도 8의 각 단계들은 도시된 순서와 다른 순서로 실시될 수도 있다.

도 9는 본 발명이 적용될 수 있는 장치의 블록도를 예시한다. 본 발명에 있어서, M2M 게이트웨이, M2M 서버 또는 M2M 디바이스는 각각 전송장치(10) 또는 수신장치(20)로 동작할 수 있다.

전송장치(10)와 수신장치(20)는 정보 및/또는 데이터, 신호, 메시지 등을 나르는 무선 신호를 전송 또는 수신할 수 있는 RF(Radio Frequency) 유닛(13, 23)과, 무선통신 시스템 내 통신과 관련된 각종 정보를 저장하는 메모리(12, 22), 상기 RF 유닛(13, 23) 및 메모리(12, 22)등의 구성요소와 동작시 연결(operatively connected)되고, 상기 구성요소를 제어하여 해당 장치가 전술한 본 발명의 실시예들 중 적어도 하나를 수행하도록 메모리(12, 22) 및/또는 RF 유닛(13,23)을 제어하도록 구성된 프로세서(11, 21)를 각각 포함한다.

메모리(12, 22)는 프로세서(11, 21)의 처리 및 제어를 위한 프로그램을 저장할 수 있고, 입/출력되는 정보를 저장할 수 있다. 메모리(12, 22)가 버퍼로서 활용될 수 있다. 또한, 메모리(12, 22)는 각종 설정 정보와 데이터를 포함하는 리소스를 저장하는 데 사용될 수 있다.

프로세서(11, 21)는 통상적으로 전송장치 또는 수신장치 내 각종 모듈의 전반적인 동작을 제어한다. 특히, 프로세서(11, 21)는 본 발명을 수행하기 위한 각종 제어 기능을 수행할 수 있다. 프로세서(11, 21)는 컨트롤러(controller), 마이크로 컨트롤러(microcontroller), 마이크로 프로세서(microprocessor), 마이크로 컴퓨터(microcomputer) 등으로도 불릴 수 있다. 프로세서(11, 21)는 하드웨어(hardware) 또는 펌웨어(firmware), 소프트웨어, 또는 이들의 결합에 의해 구현될 수 있다. 하드웨어를 이용하여 본 발명을 구현하는 경우에는, 본 발명을 수행하도록 구성된 ASICs(application specific integrated circuits) 또는 DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays) 등이 프로세서(11, 21)에 구비될 수 있다. 한편, 펌웨어나 소프트웨어를 이용하여 본 발명을 구현하는 경우에는 본 발명의 기능 또는 동작들을 수행하는 모듈, 절차 또는 함수 등을 포함하도록 펌웨어나 소프트웨어가 구성될 수 있으며, 본 발명을 수행할 수 있도록 구성된 펌웨어 또는 소프트웨어는 프로세서(11, 21) 내에 구비되거나 메모리(12, 22)에 저장되어 프로세서(11, 21)에 의해 구동될 수 있다.

전송장치(10)의 프로세서(11)는 상기 프로세서(11) 또는 상기 프로세서(11)와 연결된 스케줄러로부터 스케줄링되어 외부로 전송될 신호 및/또는 데이터에 대하여 소정의 부호화(coding) 및 변조(modulation)를 수행한 후 RF 유닛(13)에 전송한다. 수신장치(20)의 신호 처리 과정은 전송장치(10)의 신호 처리 과정의 역으로 구성된다. 프로세서(21)의 제어 하에, 수신장치(20)의 RF 유닛(23)은 전송장치(10)에 의해 전송된 무선 신호를 수신한다. 상기 프로세서(21)는 수신 안테나를 통하여 수신된 무선 신호에 대한 복호(decoding) 및 복조(demodulation)를 수행하여, 전송장치(10)가 본래 전송하고자 했던 데이터를 복원할 수 있다.

RF 유닛(13, 23)은 하나 이상의 안테나를 구비한다. 안테나는, 프로세서(11, 21)의 제어 하에 본 발명의 일 실시예에 따라, RF 유닛(13, 23)에 의해 처리된 신호를 외부로 전송하거나, 외부로부터 무선 신호를 수신하여 RF 유닛(13, 23)으로 전달하는 기능을 수행한다. 도 9에서 송신장치와 수신장치가 각각 RF 유닛을 통해 통신하는 것으로 도시되어 있지만 송신장치와 수신장치가 유선 네트워크를 통해 통신하는 것도 가능하다. 이 경우, RF 유닛은 네트워크 인터페이스 유닛(network interface unit, NIU)으로 대체될 수 있다.

이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.

본 문서에서 기지국에 의해 수행된다고 설명된 특정 동작은 경우에 따라서는 그 상위 노드(upper node)에 의해 수행될 수 있다. 즉, 기지국을 포함하는 복수의 네트워크 노드들(network nodes)로 이루어지는 네트워크에서 단말과의 통신을 위해 수행되는 다양한 동작들은 기지국 또는 기지국 이외의 다른 네트워크 노드들에 의해 수행될 수 있음은 자명하다. 기지국은 고정국(fixed station), Node B, eNode B(eNB), 액세스 포인트(access point) 등의 용어에 의해 대체될 수 있다. 또한, 단말은 UE(User Equipment), MS(Mobile Station), MSS(Mobile Subscriber Station) 등의 용어로 대체될 수 있다.

본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.

펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명은 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태를 포함하는 소프트웨어 코드 또는 명령어(instruction)로 구현될 수 있다. 소프트웨어 코드 또는 명령어는 컴퓨터 판독가능한 매체에 저장되어 프로세서에 의해 구동될 수 있으며 프로세서에 의해 구동될 때 본 발명에 따른 동작들을 수행할 수 있다. 상기 컴퓨터 판독가능한 매체는 상기 프로세서 내부 또는 외부에 위치하거나 원격으로 네트워크를 통해 상기 프로세서와 연결될 수 있으며, 상기 프로세서와 데이터를 주고 받을 수 있다.

본 발명은 본 발명의 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.

본 발명은 단말, 서버, 게이트웨이 등과 같은 통신 장치에 사용될 수 있다.

Claims

제1 계층과 제2 계층을 포함하는 M2M(Machine-to-Machine) 시스템에서 제한된 능력(constrained capability)을 갖는 적어도 하나의 M2M 디바이스와 통신하는 M2M 게이트웨이에 의해 수행되는 게이트웨이 변경 방법으로서,
상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 트리거 신호를 수신하는 단계; 및
상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 제1 통지를 M2M 서버로 전송하는 단계를 포함하되,
상기 제한된 능력을 갖는 M2M 디바이스는 상기 제1 계층을 갖지 않는 디바이스이고,
상기 제한된 능력을 갖는 M2M 디바이스의 상기 제2 계층에서 생성되는 데이터는 상기 M2M 게이트웨이의 상기 제1 계층에 의해 트리 구조의 데이터 구조(data structure)에서 관리 또는 저장되며,
상기 통지가 상기 M2M 서버로 전송된 후 상기 데이터를 포함하는 상기 데이터 구조가 상기 M2M 서버에 의해 회수(retrieve)되는, 방법.
제1항에 있어서,
상기 제1 계층은 상기 M2M 시스템이 공통(common)으로 제공하는 서비스들을 포함하는 공통 서비스 계층이고, 상기 제2 계층은 특정 M2M 애플리케이션을 실행하는 애플리케이션 계층인, 방법.
제1항에 있어서,
상기 데이터 구조는 게이트웨이 변경 상태를 지시하는 제1 정보와 대상 게이트웨이의 식별 정보를 지시하는 제2 정보를 포함하며,
상기 트리거 신호는 상기 제1 정보의 값이 특정 값으로 설정되는 것을 포함하는, 방법.
제1항에 있어서,
상기 데이터 구조는 상기 M2M 서버를 위한 제1 하위 데이터 구조를 포함하고, 상기 제1 통지는 제1 하위 데이터 구조의 URI(Universal Resource Identifier)를 포함하는, 방법.
제4항에 있어서,
상기 M2M 서버는 상기 URI를 이용하여 상기 데이터 구조를 회수(retrieve) 및 저장하는, 방법.
제1항에 있어서,
상기 데이터 구조는 상기 M2M 디바이스를 위한 제2 하위 데이터 구조를 포함하고,
상기 방법은 상기 제1 계층을 통해 게이트웨이 변경을 지시하는 제2 통지를 상기 M2M 디바이스로 전송하는 단계를 포함하되,
상기 M2M 디바이스는 상기 제2 통지를 수신한 후 게이트웨이 변경이 완료될 때까지 상기 M2M 게이트웨이로 어떠한 정보도 전송하지 않는, 방법.
제1 계층과 제2 계층을 포함하는 M2M(Machine-to-Machine) 시스템에서 제한된 능력(constrained capability)을 갖는 적어도 하나의 M2M 디바이스와 통신하는 게이트웨이에 있어서, 상기 게이트웨이는
RF(Radio Frequency) 유닛; 및
프로세서를 포함하며, 상기 프로세서는
상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 트리거 신호를 수신하고,
상기 M2M 게이트웨이의 제1 계층을 통해 게이트웨이 변경을 지시하는 제1 통지를 M2M 서버로 전송하도록 구성되며,
상기 제한된 능력을 갖는 M2M 디바이스는 상기 제1 계층을 갖지 않는 디바이스이고,
상기 제한된 능력을 갖는 M2M 디바이스의 상기 제2 계층에서 생성되는 데이터는 상기 M2M 게이트웨이의 상기 제1 계층에 의해 트리 구조의 데이터 구조(data structure)에서 관리 또는 저장되며,
상기 통지가 상기 M2M 서버로 전송된 후 상기 데이터를 포함하는 상기 데이터 구조가 상기 M2M 서버에 의해 회수(retrieve)되는, 게이트웨이.
제7항에 있어서,
상기 제1 계층은 상기 M2M 시스템이 공통(common)으로 제공하는 서비스들을 포함하는 공통 서비스 계층이고, 상기 제2 계층은 특정 M2M 애플리케이션을 실행하는 애플리케이션 계층인, 게이트웨이.
제7항에 있어서,
상기 데이터 구조는 게이트웨이 변경 상태를 지시하는 제1 정보와 대상 게이트웨이의 식별 정보를 지시하는 제2 정보를 포함하며,
상기 트리거 신호는 상기 제1 정보의 값이 특정 값으로 설정되는 것을 포함하는, 게이트웨이.
제7항에 있어서,
상기 데이터 구조는 상기 M2M 서버를 위한 제1 하위 데이터 구조를 포함하고, 상기 제1 통지는 제1 하위 데이터 구조의 URI(Universal Resource Identifier)를 포함하는, 게이트웨이.
제10항에 있어서,
상기 M2M 서버는 상기 URI를 이용하여 상기 데이터 구조를 회수(retrieve) 및 저장하는, 게이트웨이.
제7항에 있어서,
상기 데이터 구조는 상기 M2M 디바이스를 위한 제2 하위 데이터 구조를 포함하고,
상기 방법은 상기 제1 계층을 통해 게이트웨이 변경을 지시하는 제2 통지를 상기 M2M 디바이스로 전송하는 단계를 포함하되,
상기 M2M 디바이스는 상기 제2 통지를 수신한 후 게이트웨이 변경이 완료될 때까지 상기 M2M 게이트웨이로 어떠한 정보도 전송하지 않는, 게이트웨이.