KR101467173B1

KR101467173B1 - Ｍ２ｍ 네트워크의 리소스 관리 방법 및 리소스 관리 장치

Info

Publication number: KR101467173B1
Application number: KR1020130012342A
Authority: KR
Inventors: 양정엽
Original assignee: 주식회사 케이티
Priority date: 2013-02-04
Filing date: 2013-02-04
Publication date: 2014-12-01
Also published as: KR20140099663A; US9215551B2; US20140221032A1

Abstract

본 발명은 M2M 네트워크의 리소스 관리 방법에 관한 것으로서, M2M 네트워크의 리소스들 간의 상관도에 관한 정보를 저장하는 가상 SCL을 생성하는 단계; 요청자의 요청에 상응하는 리소스를 제공할 수 없는 경우 상기 가상 SCL이 상기 상관도에 기초하여 상기 요청된 리소스를 대체하는 대체 리소스를 선택하는 단계; 및 상기 가상 SCL이 상기 대체 리소스가 존재하는 SCL에 대한 도달 정보를 기초로 상기 대체 리소스를 요청하는 단계를 포함하는 것을 특징으로 한다.

Description

Ｍ２Ｍ 네트워크의 리소스 관리 방법 및 리소스 관리 장치 {Method and Apparatus of resource management of M2M network}

본 발명은 M2M 네트워크의 리소스 관리 방법 및 리소스 관리 장치에 대한 것으로, 특히 M2M 네트워크에서 장애가 발생된 디바이스를 대체하고 서비스 준비 시간을 최적화시킬 수 있는 M2M 네트워크의 리소스 관리 방법 및 리소스 관리 장치에 관한 것이다.

M2M(Machine-to-Machine)은 방송통신망을 이용하여 사람이나 지능화된 기기에게 사물정보를 제공하거나, 사람이나 지능화된 기기가 사물의 상태를 제어하기 위한 통신을 의미한다. M2M은 IOT(Internet of Things), 사물지능통신(O2N : Object to Object Intelligent Network)란 이름으로도 불린다.

과거 1990년대 전·후반의 M2M 통신은 단순한 P2P(Point-to-Point) 연결을 위한 일대일 혹은 일대 다수의 통신을 의미하였다면, 궁극적으로 M2M 통신에서 지향하고자 하는 것은 위치인식, 상황인식, 증강현실 도입 등으로 개인 혹은 상황에 맞춤적으로 인간의 제어없이 또는 인간의 개입을 최소화한 상태에서 자동적으로 동작하면서 보다 향상된 M2M 통신 서비스의 품질과 안정성을 목표로 한다.

M2M 네트워크 통신은 종래의 u-City, u-Health, u-교통, u-환경 사업 등을 통해 사회 현안 해결, 재난 및 재해 방지, 에너지 절감 등에 기여할 수 있는 필수적인 인프라로 활용될 수 있다. 현재 대표적으로 원격검침, 건물·시설물 관리, 자판기 관리, 실내 조명 조절 서비스, 교통정보·차량관제, 긴급출동, 화재 경보기, 방범 경보 장치, 자판기, 텔레매틱스, 무선 결재 분야 서비스 등 매우 다양한 서비스가 M2M 서비스로서 제공되고 있다. 또한, 최근에는 맥박계, 심전도계 등의 의료기기에 적용되어 원격 진료 서비스 등을 포함하는 e-Health 분야에서의 적용도 활발하게 진행되고 있다.

M2M 통신은 사물장치간의 통신으로 기존의 사람 중심 H2H(Human-to-Human) 통신과는 여러 특징에서 차이를 보인다. 이러한 특성의 차이에서부터 기술적으로 필요한 기술이 달라질 수 있고 M2M 통신을 이용하는 활용 분야에 따라서도 필요한 특성은 조금씩 달라질 수 있다. 현재 대표적으로 ETSI(European Telecommunication Standard Institute)를 포함한 세계 각국의 표준화 그룹에서는 성공적인 M2M 통신의 표준화를 위한 연구개발이 계속되고 있다. 도 1은 ESTI 표준 문서들 중 ETSI TS(Technical Specification) 102 690[Machine-to-Machine Communications (M2M); Functional architecture] 의 제 4 장에서 제공하는 디바이스 및 게이트웨이 도메인과 네트워크 도메인을 포함하는 M2M 서비스를 위한 아키텍처를 도시한다. 이하에서는 상기 ETSI TS(Technical Specification) 102 690을 포함하여 ETSI에서 진행되는 표준화 작업의 내용을 “ETSI 표준”이라고 한다.

도 1을 참조하면, M2M 디바이스들(10, 10')은 인간의 입력 및 개입이 없거나 이를 최소화한 상태에서 통신하는 단말기기로서, 요청에 의해 혹은 자동적으로 자신이 보유한 데이터를 송출 및 전달하는 모든 종류의 디바이스를 일컫는다.

또한 상기 ETSI 표준에 따르면, M2M 디바이스(10')가 액세스 네트워크(40)에 직접 접속하는 경우에는 M2M 디바이스(10')의 M2M 서비스 능력(M2M Service Capability)(11)을 이용하여 M2M 디바이스의 M2M 애플리케이션(M2M Application)인 디바이스 애플리케이션(DA, 12)을 실행하는 것으로 규정되고 있으며, M2M 디바이스(10)가 M2M 게이트웨이(30)를 통해 액세스 네트워크(40)에 접속하는 경우에는 M2M 게이트웨이(30)의 M2M 서비스 능력(31)을 이용하는 것으로 규정되고 있다.

또한 M2M 지역 네트워크(M2M Area Network)(20)는 M2M 디바이스(10)와 M2M 게이트웨이(30) 간의 연결을 제공한다. M2M 지역 네트워크(20)의 예로는 IEEE 802.15.x, Zigbee, Bluetooth, IETF ROLL, ISA100.11a 등과 같은 개인 영역 네트워크(Personal Area Network; 이하에서 "PAN"이라 한다)이나 무선 로컬 지역 네트워크(Wireless Local Area Network; 이하에서 "LAN"이라 한다), PLC, M-BUS, Wireless M-BSU, KNX와 같은 LAN을 포함할 수 있다.

M2M 게이트웨이(30)는 M2M 서비스 능력(31)을 이용하여 M2M 게이트웨이(30)의 M2M 애플리케이션인 게이트웨이 애플리케이션(GA, 32)를 실행하는 게이트웨이이며, M2M 디바이스(10)와 액세스 네트워크(40) 사이에서 프록시(Proxy) 역할을 수행한다.

액세스 네트워크(40)는 M2M 디바이스(10') 내지 M2M 게이트웨이(30)가 코어 네트워크(50)와 통신할 수 있도록 하는 네트워크이다. 액세스 네트워크(40)의 예로는 xDSL, HFC, FTTH, PLC, Satellite망, GERAN, UTRAN, eUTRAN, Wireless LAN, WiMAX(WiBro) 등이 있다.

코어 네트워크(50)는 IP 연결, 액세스 네트워크 제어 및 네트워크 서비스 제어 기능, 다른 네트워크와의 상호 연결, 로밍(Roaming) 기능 등을 제공하는 네트워크이다. 코어 네트워크(50)의 예로는 3GPP CN, ETSI TISPAN CN, 3GPP2 CN, IMS 등이 있다.

네트워크 도메인의 M2M 서비스 능력(60)은 서로 다른 애플리케이션들에 의해 공유될 수 있는 기능을 제공하며, 개방형 인터페이스를 통해 다른 서비스 능력에 접근할 수 있는 환경을 제공한다. 이와 같은 M2M 서비스 능력들을 사용하여, 하위 네트워크 계층의 특성들을 고려하지 않고도 최적의 애플리케이션을 개발하고 배포할 수 있게 된다.

네트워크 도메인의 M2M 애플리케이션인 네트워크 애플리케이션(NA, 70)들은 M2M 서비스 로직을 실행하고 M2M 시스템에서 제공하는데 개방형 인터페이스를 통해 M2M 서비스 능력들을 이용한다.

한편, 도 1에 따르면 네트워크 도메인에는 M2M 관리 함수들(M2M Management Functions)과 네트워크 관리 함수들(Network Management Functions)를 포함하는 것으로 규정되어 있다. 여기서, M2M 관리 기능들(M2M Management Functions)(80)은 네트워크 도메인에서 M2M 서비스 능력들을 관리하기 위해 요구되는 모든 기능들로 구성되며, M2M 디바이스 내지 M2M 게이트웨이의 관리는 특정 M2M 서비스 능력을 이용하게 된다. 또한, 네트워크 관리 기능들(90)은 액세스 네트워크(40)와 코어 네트워크(50)를 관리하기 위해 요구되는 모든 기능들로 구성되며, 프로비저닝(Provisioning), 감시(Supervision), 장애 관리(Fault Management) 등의 기능을 포함한다.

또한 상기 ETSI 표준에 따르면 네트워크 도메인에 있는 M2M 서비스 능력들을 나타내는 계층을 네트워크 서비스 능력 계층(Network Service Capability Layer; 이하 “NSCL”이라 함), 게이트웨이의 M2M 서비스 능력들을 나타내는 계층을 게이트웨이 서비스 능력 계층(Gateway Service Capability Layer; 이하 “GSCL”이라 함), M2M 디바이스의 M2M 서비스 능력들을 나타내는 계층을 디바이스 서비스 능력 계층(Device Service Capability Layer; 이하 “DSCL”이라 함)이라고 정의되고 있다. 상기 NSCL, GSCL 및 DSCL을 총칭하여 서비스 능력 계층(Service Capability Layer; 이하 “SCL”이라 함)이라고 한다. 여기서 NSCL은 각각의 M2M 서비스를 제공하는 서비스 제공업자에 의해 각각의 서비스 별로 개별적으로 구축되는 플랫폼을 의미하는 것이다.

GSCL의 SC는 다음과 같은 SC가 포함될 수 있다: 디바이스의 도달 가능성 상태 및 도달 가능성에 관한 스케줄링 정보를 관리하고, 디바이스 그룹을 생성, 삭제 및 조회하며, NA/DA/GA와 GSCL 또는 NSCL의 데이터를 저장하고 접근권한을 설정하는 등의 기능을 제공하는 게이트웨이 도달가능성, 주소할당 및 저장소(Gateway Reachability, Addressing and Repository; 이하 “GRAR”이라 함) 능력; 참조 포인트 또는 GSCL 내부에서 교환되는 메시지와 관련 정보를 기록하는 등의 기능을 제공하는 게이트웨이 이력 및 데이터 유지(Gateway History and Data Retention; 이하 “GHDR”이라 함) 능력 등.

DSCL의 SC는 GSCL의 경우와 마찬가지로 디바이스 그룹을 생성, 삭제 및 조회하며, DA 등록정보와 NSCL 정보 저장, 디바이스 관련 도달가능성이나 스케쥴링 정보를 NSCL에 전달하는 등의 기능을 수행하는 디바이스 도달가능성, 주소할당 및 저장소(Device Reachability, Addressing and Repository; 이하 “DRAR”이라 함) 능력; 참조 포인트 또는 DSCL 내부에서 교환되는 메시지와 관련 정보를 기록하는 등의 기능을 제공하는 디바이스 이력 및 데이터 유지(Device History and Data Retention; 이하 “DHDR”이라 함) 능력 등을 포함할 수 있다.

한편, 상기 ETSI 표준에는 M2M 네트워크에 RESTful 구조 형식을 적용하여 M2M 애플리케이션(DA, GA 또는 NA)과 M2M SCL들이 서로 어떻게 정보를 교환하는 지에 대해 규정되어 있다. 여기서 REST(Representational State Transfer)란 로이 티 필딩(Roy T. Fielding)에 의해 제안된 소프트웨어 아키텍처럴 스타일(soferware architectural style)을 일컫는 것으로 주로 웹에서 데이터 접근에 이용되는 방법이다. 이러한 RESTful 웹 서비스는 리소스 URI를 알면 서버/클라이언트 종류에 상관없이 HTTP 프로토콜만으로 접근 가능한 특성을 갖는다. ETSI 표준에서는 RESTful 구조를 이용하여 유일하게 정의된 리소스들의 표현정보를 전달하는 방법에 대해 규정하고 있다. 또한 상기 ETSI 표준에서는 SCL에 위치하는 리소스들에 대한 명세(specification)도 정의하고 있다.

도 2는 ETSI 표준에 따른 M2M 애플리케이션들과 SCL 사이의 데이터 교환을 위한 리소스 데이터 흐름과 SCL이 중간에서 어떤 역할을 하는 지에 대한 예를 보여준다. 본 예시는 DA가 NSCL의 리소스에 데이터를 기록하고, NA가 그 리소스를 조회하는 경우이다. 다른 경우로써 DA에 의해 NSCL의 리소스 데이터가 갱신되었을 경우에 NA는 NSCL으로부터 통지를 받는 방법으로 데이터 정보를 얻을 수도 있다.

도 2의 화살표 방향은 작업의 흐름이 아니라 데이터의 흐름을 나타내는데, 먼저 단계 1에서 디바이스의 리소스 데이터가 갱신/생성(update/create)되었을 때 DA는 생성된 리소스 데이터를 DSCL을 거쳐 NSCL의 컨테이너(container)(20)에 기록하면, 단계 2에서 NSCL은 NA에 리소스 데이터가 갱신되었음을 통보(notify)하고, 단계 3에서 NA는 NSCL의 컨테이너로 데이터를 읽어들이는(read) 과정을 거치게 된다.

도 2에 도시된 예시와 같이, ETSI 표준의 RESTful 구조에서 유일하게 정의된 엔터티(entity)로서의 리소스(resource)는 동사(verb)와 함께 전송되고 조작되어야 하는 표현정보(representation)를 가진다. 상기 리소스는 URI (Universal Resource Indentifier)를 사용하여 식별되는 것으로 규정되어 있다.

ETSI 표준에서 상술한 바와 같은 동사에 대응되는 메소드들은 CRUD(Create/Retrieve/Update/Delete)로 기술되며 이들 기본 메소드 외에 추가적인 메소드로서 NOTIFY[가입(subscription)의 결과로서 리소스의 변경에 대한 통지를 보고하는 작업을 지칭하는데 사용되며, 롱 폴링(long polling)의 경우에 대해서는 RETRIEVE 메소드의 응답으로 매핑될 수 있으며, 비동기 전송의 경우에는 UPDATE 메소드로 매핑될 수 있음], EXECUTE[리소스에 의해 대표되는 관리 명령과 작업을 수행하는데 사용되며, 이 메소드는 내부 데이터가 없는 UPDATE 메소드에 대응됨] 메소드도 아울러 규정되어 있다.

한편, 상기 ETSI 표준에 따르면 요청(request)을 수행하는 주체(actor)를 요청자(issuer)로 정의하는데, 상기 요청자는 M2M 애플리케이션 또는 SCL일 수 있다고 규정되고 있다. 또한, 어나운스된 리소스(Announced Resource)는 그 리소스의 내용이 호스팅 SCL(Hosting SCL)에 의해 호스팅된 리소스를 참조하는 것으로 규정되어 있다. 이 리소스의 목적은 탐색을 원하는 요청자들이 리소스를 찾기 위해 모든 SCL에 접근할 필요가 없도록 하고 원본 리소스의 탐색을 용이하게 하는데 있다.

이를 보다 자세히 살펴보기 위해서는 다음과 같다.

우선 ETSI 표준에서 규정된 용어를 살펴보면, 로컬 SCL(Local SCL)은 애플리케이션이나 SCL이 등록되어야 하는 SCL으로서, 요청의 원래 요청자로부터 요청을 수신하는 첫번째 SCL을 말한다. 따라서 만일 NA가 요청자라면 로컬 SCL은 NSCL이 되고, GA가 요청자라면 로컬 SCL은 GSCL이 되며, 디바이스(D)의 DA가 요청자라면 로컬 SCL은 DSCL이 되며, 디바이스(D')의 DA가 요청자라면 로컬 SCL은 GSCL이 된다. 또한 GSCL이 요청자라면 로컬 SCL은 NSCL이 되고, D 디바이스의 DSCL이 요청자라면 로컬 SCL은 NSCL 혹은 GSCL이 된다. 여기서 호스팅 SCL은 주소가 지정된 리소스가 상주하는 SCL이다. 또한 리소스는 다양한 SCL들에 어나운스될 수 있는데, 어나운스된 리소스를 포함하고 있는 SCL을 어나운스투 SCL(Announced-to SCL)로 정의하고 있다.

여기서 어나운스된 리소스는 다른 SCL에서 호스팅되는 원본 리소스를 가리키는 것으로서, searchStrings, 원본 리소스로의 링크, 접근 권한(access right) 등을 포함하는 한정된 세트의 속성(attribute)으로 구성된다. 이를 이용하여 어나운스투 SCL로 문의(query)하여 원본 리소스를 발견(discovery)할 수 있도록 함으로써 발견(discovery)의 요청자(issuer)는 리소스를 찾기 위해 모든 SCL과 접촉할 필요가 없게 된다. 또한 어나운스된 리소스 자체는 full URI를 통해 직접 접근되므로, 발견(discovery) 과정에서 원본 리소스에 대한 직접적인 레퍼런스(direct reference)가 리턴될 수 있다. ETSI 표준에서는 로컬 생성된 리소스만이 어나운스될 수 있다고 규정한다. 어나운스된 리소스를 제거하는 것, 예를 들어 SCL의 등록철회(degeneration)는 원본 리소스를 제거하지 아니하며, 반대로 원본 리소스가 제거되면 어나운스된 리소스는 제거된다.

도 3a 및 도 3b는 ETSI 표준에 따른 C/R/U/D 중 Retrieve 동작의 예시를 나타내는 도면들로서, 원본 리소스의 위치에 따라 홉(hop)이 필요 없는 경우 및 2번의 홉(2-hop)이 필요한 경우의 발견(discovery) 절차 메시지 플로우를 각각 도시한다.

도 3a에 도시된 바와 같이 홉(hop)이 필요 없는 경우는 로컬 SCL과 호스팅 SCL이 동일한 엔티티인 경우이다. 요청자(issuer)는 NA, DA, GA, 또는 SCL이 될 수 있다. 요청자가 리소스에 접근하기 위해 발견(discovery)을 요청하면(RETRIEVE 이용)(단계 S31), 로컬 SCL은 접근 권한(access right)을 체크한 후, 로컬 처리(local processing; 단계 S32)에 의해 리소스를 발견하여 정상적인 응답을 요청자에게 제공하거나 에러 응답을 요청자에게 전달한다(단계 S33).

도 3b에 도시된 바와 같이 2번의 홉(2-hop)이 필요한 경우는, 로컬 SCL(SCL-1), 중간(intrmediate) SCL(SCL-2) 및 호스팅 SCL(SCL-y)이 서로 달라서 요청자(issuer)가 호스팅 SCL과 직접 통신할 수 없는 경우이다.

먼저 도 3a와 관련하여 위에서 설명한 바와 같이 요청자(issuer)가 리소스에 접근하기 위해 로컬 SCL(SCL-1)에 리소스 접근 메시지를 전달(S301)한다. 로컬 SCL(SCL-1)은 요청된 리소스가 자신이 가지고 있지 않음을 확인하면(단계 S302), 자신에게 미리 등록된 중간(intermediate) SCL(SCL-2)(여기서 중간 SCL은 주로 NSCL이 될 것이다)에 요청자의 요청을 전달하기로 결정하고(단계 S303) 요청자의 접근 메시지를 중간 SCL(SCL-2)에 전달한다(단계 S304). 여기서 요청을 전달하기 전에 접근 권한과 메시지 형식을 선택적으로 체크할 수 있다.

이후 단계 S305에서 중간 SCL(SCL-2)은 자신에게 미리 등록된 호스팅 SCL(SCL-y)로 요청자의 요청을 전달하기로 결정하고(단계 S305), 요청자의 접근 메시지를 호스팅 SCL(SCL-y)로 전달한다(단계 S306). 여기서도 요청을 전달하기 전에 접근 권한과 메시지 형식을 선택적으로 체크할 수 있다. 호스팅 SCL(SCL-y)은 접근 권한을 확인(단계 S307)하고 요청된 리소스에 접근(단계 S308)한다. 이 후, 호스팅 SCL(SCL-y)로부터의 정상적인 응답 또는 에러 응답이 요청자에게 순차적으로 전달된다(단계 S309, S310 및 S311).

이상 ETSI 표준에 따른 C/R/U/D 중 Retrieve 동작의 예시를 살펴보았으나, 현재의 ETSI 표준은 RESTful 구조를 적용하여 네트워크, 게이트웨이, 디바이스를 리소스로 간주하고, 상술한 Retrieve 메소드를 포함하는 4가지의 메소드, 즉 Create/Retrieve/Update/Delete (CRUD) 메소드들을 통해 각 리소스를 관리하는 방법을 채택하고 있다. 이 때 각각의 리소스에는 URI 정보만 있으면 액세스가 가능하며, 이를 효과적으로 관리하기 위하여 리소스의 특징(속성)인 속성(attribute) 만으로 구성된 어나운스된 리소스(Announced Resource)라는 개념을 도입하여 각 리소스로의 액세스의 효율성을 높이고 있다.

그러나, ETSI 표준에서 제안하고 있는 어나운스된 리소스(Announced Resource) 중심의 리소스 관리 방법은 주요 리소스를 찾기 위한 방법으로는 효과적이나, 어나운스된 리소스(Announced Resource)를 액세스(호출)할 때 장애가 발생하는 경우 리소스간의 유사성이나 상관도를 고려하여 다른 리소스로의 대체 등과 같은 장애 복구와 관련된 해결책에 대해서는 전혀 언급하고 있지 않는다는 문제점이 있다.

또한 리소스의 접근 시 리소스의 액세스 빈도 등도 전혀 고려하고 있지 않기 때문에 준비 시간이나 응답 속도를 빠르게 하는 것도 불가능하여 비효율적이라는 문제점이 있다.

예를 들면, 상기 ETSI 표준에 따르면 환자 치료를 위한 이헬스(e-Health) 서비스를 제공하는 M2M 서비스의 경우 치료 장비가 제대로 동작하지 않으면 해당 치료 장비에 대한 리소스 액세스 시 실패(failure) 처리로 끝날 뿐 다른 대체 리소스를 제공하는 것은 불가능하게 된다. 또한, 반복적이고 지속적인 치료를 위한 장비의 경우도 그 빈도나 이력을 고려하지 않기 때문에 매번 서비스 제공을 위한 준비시간을 최적화하여 단축하는 것도 불가능하게 된다.

본 발명은 상술한 바와 같은 문제점을 해결하기 위하여 안출된 것으로서, M2M 네트워크에서 발생할 수 있는 다양한 상황을 고려한 종합적인 리소스 관리 방법을 제공하고자 하는 것을 목적으로 한다.

상술한 목적을 달성하기 위한 본 발명의 일실시예에 따른 M2M 네트워크의 리소스 관리 방법은, M2M 네트워크의 리소스들 간의 상관도에 관한 정보를 저장하는 가상 SCL을 생성하는 단계; 요청자의 요청에 상응하는 리소스를 제공할 수 없는 경우 상기 가상 SCL이 상기 상관도에 기초하여 상기 요청된 리소스를 대체하는 대체 리소스를 검색하는 단계; 및 상기 대체 리소스가 존재하는 경우 상기 가상 SCL이 상기 대체 리소스가 존재하는 SCL에 대한 도달 정보를 기초로 상기 대체 리소스를 요청하는 단계를 포함하는 것을 특징으로 한다.

여기서, 상기 상관도는 상기 리소스들 각각에 대한 액세스 이력에 기초하여 산출되는 도달 가능성에 대한 상관 계수 또는 상기 리소스들 각각에 대하여 다른 리소스로부터의 호출 이력에 기초하여 산출되는 재이용 가능성에 대한 상관 계수일 수 있다.

또한 상기 도달 정보는 상기 요청된 리소스 또는 상기 대체 리소스가 존재하는 SCL의 URI일 수 있다.

또한, 상기 대체 리소스를 요청하는 단계는, 상기 대체 리소스에 대한 홉(hop) 타입 정보와 함께 상기 요청자의 요청을 관련 SCL에 전달하는 단계를 포함할 수 있다.

한편, 상술한 목적을 달성하기 위한 본 발명의 다른 실시예에 따른 M2M 네트워크의 리소스 관리 장치는, 리소스들의 URI 및 상기 리소스들 간의 상관도에 관한 정보를 생성하기 위하여 상기 리소스들을 분석하는 분석 모듈; 및 요청자가 요청한 리소스의 응답 가능 여부에 따라 상기 상관도에 관한 정보에 기초하여 대체 리소스를 선택하는 가상 SCL을 생성하는 가상 SCL 생성모듈을 포함하는 것을 특징으로 한다.

여기서, 상기 가상 SCL은, 상기 리소스 요청에 대한 응답이 불가능한 경우에는 대체 리소스를 검색할 수 있으며, 상기 대체 리소스가 존재하는 SCL에, 상기 요청자의 요청과 함께 상기 요청된 리소스에 대한 홉 타입 정보를 함께 전달할 수 있다.

또한, 상기 M2M 네트워크의 리소스 관리 장치는, 상기 M2M 네트워크의 구성 여부 또는 리소스에 대한 요청자(issuer)의 요청이 발생하는 경우 어나운스된 리소스(annouced resource)가 있는지를 모니터링하는 모니터링 모듈을 더 포함할 수 있다.

본 발명에 따르면, M2M 네트워크에서 리소스 간의 상관도를 고려하여 요청자의 리소스에 대한 요청을 가상 SCL에서 우선적으로 처리하도록 함으로써, M2M 네트워크 또는 디바이스에 장애가 발생한 경우 즉시 유사 리소스로 대체하여 서비스를 제공하는 것이 가능하게 된다.

또한 본 발명에 따르면, 이용 빈도가 높은 M2M 서비스의 경우 서비스 제공을 위한 리소스 준비 시간을 효과적으로 단축시킬 수 있어 전체적인 M2M 네트워크의 성능 향상을 가능하게 하는 효과가 있다.

도 1은 ETSI 표준에 따른 디바이스 및 게이트웨이 도메인과 네트워크 도메인을 포함하는 M2M 서비스를 위한 아키텍처의 일례를 도시한다
도 2는 ETSI 표준에 따른 M2M 애플리케이션들과 SCL 사이의 데이터 교환을 위한 리소스 데이터 흐름과 SCL이 중간에서 어떤 역할을 하는 지에 대한 예를 보여준다.
도 3a 및 도 3b는 ETSI 표준에 따른 C/R/U/D 중 Retrieve 동작의 예시를 나타내는 도면들로서, 원본 리소스의 위치에 따라 홉(hop)이 필요 없는 경우 및 2번의 홉(2-hop)이 필요한 경우의 발견(discovery) 절차 메시지 플로우를 각각 도시한다.
도 4는 본 발명의 일실시예에 따른 M2M 리소스 관리 장치의 일례를 도시한다.
도 5는 본 발명의 일실시예에 따른 가상 SCL의 리소스의 구성의 일례를 도시한다.
도 6은 도 6는 본 발명의 일실시예에 따른 M2M 리소스 관리 방법을 개략적으로 설명하는 순서도이다.
도 7은 본 발명의 일실시예에 따라 가상 SCL을 이용하여 M2M 네트워크에서 M2M 서비스에 대한 리소스 요청 발생 시 대체 리소스를 제공하는 과정을 예시적으로 설명하는 도면이다.

이하, 첨부한 도면들을 참조하여, 본 발명을 보다 상세하게 설명하고자 한다. 본 발명은 다양한 변경을 가할 수 있고 여러 가지 형태를 가질 수 있는바, 특정 실시예들을 도면에 예시하고 본문에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 개시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.

각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다. 여기서, 제1, 제2 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.

본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서 상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

또한, 다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

도 4는 본 발명의 일실시예에 따른 M2M 리소스 관리 장치의 일례를 도시한다.

본 발명에 따른 M2M 리소스 관리 장치(400)는 상술한 바와 같은 디바이스 및 게이트웨이 도메인 또는 네트워크 도메인 중 임의의 적절한 네트워크 엔티티에 통합되거나 별도의 독립적인 엔티티가 될 수 있으며, 이에는 모니터링 모듈(401), 분석 모듈(402) 및 가상 SCL 생성 모듈(403)이 포함된다.

모니터링 모듈(401)은 M2M 네트워크가 최초로 구성되거나 새로운 M2M 디바이스의 편입 등으로 M2M 네트워크가 재구성되는 경우 또는 리소스에 대한 요청자(issuer)의 요청이 발생하는 경우 어나운스된 리소스(annouced resource)가 있는지를 모니터링한다.

분석 모듈(402)은, 상기 모니터링 모듈(401)의 모니터링 결과 어나운스된 리소스가 발생되었음을 확인한 경우, 어나운스된 리소스들의 속성을 수집하여 그 리소스들 간의 상관도를 분석한다. 상기 분석 모듈(402)이 분석하는 리소스들의 상관도는, 예를 들어 각 리소스의 도달 가능성에 대한 상관도 및/또는 각 리소스의 재사용가능성에 대한 상관도를 포함할 수 있다.

상기 분석 모듈(402)에 의해 분석되는 리소스의 도달 가능성에 대한 상관도는, M2M SC(Service Capability) 중에서 상술한 바와 같은 RAR(Reachability, Addressing and Repository)를 이용할 수 있다. 즉, 상기 분석 모듈(402)은 디바이스나 게이트웨이의 RAR을 이용하여 그들의 매핑 정보, 도달가능성, 스케쥴링 정보 등을 종합적으로 분석하고, 어떤 상황에서 그 리소스가 이용되는지에 대한 상관도를 산출한다. 이와 같은 도달가능성에 대한 리소스 간의 상관도를 산출하기 위한 상관 계수 공식은, 예를 들어 다음 수학식 1을 이용할 수 있다.

[수학식 1]

상기 수학식 1은 리소스들 각각에 대한 액세스 이력을 기초한 상관 계수 산출 공식으로서, DRAR는 GSCL 또는 NSCL이 해당 디바이스에 액세스를 시도하여 실제로 요청한 리소스 값이 반환되었거나 URI 값이 반환된 횟수를 의미하며, GRAR는 DSCL 또는 NSCL이 해당 게이트웨이에 액세스를 시도하여 실제로 요청한 리소스 값이 반환되었거나 URI 값이 반환된 횟수를 의미하며,

및

은 각각 DRAR 및 GRAR의 평균값을 의미한다.

또한, 상기 분석 모듈(402)에 의해 분석되는 리소스의 재사용 가능성에 대한 상관도는 M2M SC 중에서 상술한 바와 같은 HDR(History and Data Retention)을 이용하여 분석할 수 있다. 즉, 상기 분석모듈(402)는 디바이스나 게이트웨이의 HDR을 이용하여 리소스의 액세스 또는 호출 빈도수 등을 분석하고, 디바이스나 게이트웨이의 어떤 리소스가 어떤 리소스와 연계되어 얼마나 자주 이용되는지에 대한 상관도를 산출한다. 이와 같은 재사용 가능성에 대한 리소스 간의 상관도를 산출하기 위한 상관 계수 공식은, 예를 들어 다음 수학식 2를 이용할 수 있다.

[수학식 2]

상기 수학식 2는 리소스들 각각에 대하여 다른 리소스로부터의 호출 이력을 기초로 하는 상관 계수 산출 공식으로서, DHDR은 각각의 디바이스를 리소스로 간주할 때 다른 리소스에서 해당 리소스를 호출하거나 값을 전달한 횟수를 의미하며, GHDR은 각각의 게이트웨이를 리소스로 간주할 때 다른 리소스에서 해당 리소스를 호출하거나 값을 전달한 횟수를 의미하며,

및

은 각각 DHDR 및 GHDR의 평균값을 의미한다.

여기서 상기 수학식 1 및 2는 단지 예시로 든 것이고, 본 기술분야의 통상의 지식을 가진 자라면 리소스의 도달가능성 및 재사용가능성에 대한 상관도 산출을 위한 공지의 또는 다른 임의의 상관 계수 공식이 사용될 수 있음이 이해될 것이다.

가상 SCL 생성 모듈(403)은 가상 SCL을 생성하는 역할을 담당한다. 여기서 상기 가상 SCL은, 요청자의 리소스 요청 발생 시 리소스의 응답 가능 여부에 따라, 리소스의 응답이 가능한 경우에는 리소스의 위치 파악을 통한 해당 리소스로의 직접적인 리소스 요청을 전달하거나, 리소스의 응답이 불가능한 경우에는 분석 모듈(402)에 의해 분석된 상관도를 바탕으로 결정된 대체 리소스로 리소스 요청을 전달하는 기능을 한다.

도 5는 본 발명의 일실시예에 따른 가상 SCL 생성 모듈(403)에 의해 생성되는 가상 SCL의 리소스의 구성의 일례를 도시한다.

먼저 <virtual scl>(500)이라고 정의된 가상 SCL의 리소스에는 일반적인 다른 M2M 리소스와 마찬가지로 “attribute", scls, applications, groups accessrights, discovery 등과 같은 리소스를 포함할 수 있다. “attribute”(501)에는 리소스의 생성 시간에 대한 정보인 “creationTime”과 최근 수정된 시간에 대한 정보인 “lastModifiedTime”이 포함될 수 있다. 한편 본 실시예에 따른 가상 SCL은 일반적인 다른 M2M 리소스와는 달리 correlation(502)이라는 리소스를 별도로 포함할 수 있는데, 이 리소스는 상술한 바와 같은 방법으로 산출된 리소스의 도달가능성에 대한 상관도(correlation of reachable) 및 재사용가능성에 대한 상관도(correlation of resuable)를 나타내는 값을 저장하는 테이블 등에 대한 URI에 해당한다. 상기 테이블은, 예를 들어 모든 리소스 각각에 대하여 상술한 도달 가능성 및 재사용 가능성에 대한 상관 계수를 포함할 수 있다.

도 6는 본 발명의 일실시예에 따른 M2M 리소스 관리 방법을 개략적으로 설명하는 순서도이다.

먼저 단계 S61에서는 M2M 네트워크가 최초로 구성되거나 새로운 M2M 디바이스의 편입 등으로 M2M 네트워크가 재구성되는 경우 또는 리소스에 대한 요청자(issuer)의 요청이 발생한 후에, 상술한 바와 같은 모니터링 모듈에 의해 어나운스된 리소스가 있을 때까지 계속하여 어나운스된 리소스가 있는지를 모니터링한다(단계 S62).

어나운스된 리소스가 존재하게 되면 이들에 대한 속성을 수집하고, 상술한 바와 같은 방법을 이용하여 복수의 리소스들 간의 상관도를 분석한다(단계 S63).

단계 S64에서는, 요청자의 M2M 리소스에 대한 요청을 우선적으로 처리하기 위하여 상기 분석된 상관도에 관한 정보를 저장하는 가상 SCL을 생성한다.

단계 S64에서 생성된 가상 SCL은, 요청자로부터 예를 들어 C/R/U/D 요청이 있는 경우 이에 상응하는 리소스의 정보를 분석하여 처리한다(단계 S65).

이 경우 요청된 리소스에 상응하는 리소스가 있는지를 판단하고(단계 S66), 상기 요청된 리소스에 상응하는 리소스가 있다고 판단하는 경우에는 해당 리소스까지 도달하기 위한 홉(hop) 타입 정보와 함께 리소스 요청 메시지를 각각의 관련 SCL(예를 들어 2 홉인 경우에는 로컬 SCL, 중간 SCL 및 호스팅 SCL)에게 전달한다(단계 S67).

단계 S67에서 가상 SCL이 홉 타입 정보를 함께 리소스 요청 메시지를 관련 SCL들에 전달하는 이유는, 가상 SCL이 이미 수집하고 있는 각 리소스의 위치 정보를 이용하여 리소스 준비 시간을 단축시키기 위함이다. 만약 가상 SCL에 해당 리소스에 대한 위치 정보가 없다면 최초에는 홉 타입 정보가 제공될 수 없을 것이나, 해당 리소스를 발견하고 나면 그에 대한 홉 타입 정보를 축적할 수 있게 되므로 이후부터는 해당 리소스에 대한 홉 타입 정보를 제공할 수 있게 된다.

이후 요청을 받은 SCL들은 해당 리소스의 요청에 대한 응답 메시지를 가상 SCL을 거치거나 또는 직접 요청자에게 전달한다(단계 68).

단계 S66에서 요청된 리소스와 관련된 디바이스나 게이트웨이의 오류 등에 의해 요청된 리소스에 상응하는 리소스를 발견할 수 없다고 판단하는 경우에는, 상기 가상 SCL은 자신이 저장하고 있는 리소스들간의 상관도에 관한 정보를 기초로 상기 요청된 리소스를 대처할 수 있는 대체 리소스가 있는지를 판단하여 대체 리소스를 선택한다(단계 S69).

단계 S69에서 대체 리소스가 있는지를 판단하고 대체 리소스를 선택하는 하는 구체적인 방법은 다음과 같다. 먼저 가상 SCL은 요청된 리소스에 대한 다른 리소스들의 상관도에 관한 정보를 참조하여, 최소 상관도보다 높은 상관도를 갖는 대체 리소스들을 검색한다. 이후 검색된 대체 리소스들 중에 상관도가 높은 순으로 차례로 액세스를 시도하여 상기 요청된 리소스에 대한 대체 리소스를 결정한다. 여기서 상기 최소 상관도는 전체 리소스들 간의 상관 계수의 평균값으로 미리 설정될 수도 있으나, 이에 한정되지 않고 사용자에 의해 미리 임의로 설정된 상관 계수 값을 의미할 수 도 있다.

단계 S69에서 가상 SCL이 대체 리소스도 발견할 수 없는 경우에는 실패 또는 거절 메시지를 요청자에게 제공하고(단계 S70), 대체 리소스를 발견한 경우에는 그 대체 리소스에 대해 단계 S67 및 S68의 과정을 수행한다. 단계 S69에서 대체 리소스를 발견할 수 없는 경우란, 예를 들어 다른 리소스와의 상관도가 모두 최소 상관도 이하인 경우나, 최소 상관도 이상인 리소스가 존재하여도 해당 리소스를 호출할 수 없는 경우 등을 포함할 수 있다.

도 7은 본 발명의 일실시예에 따라 가상 SCL을 이용하여 M2M 네트워크에서 M2M 서비스에 대한 리소스 요청 발생 시 대체 리소스를 제공하는 과정을 예시적으로 설명하는 도면이다.

단계 S71에서 요청자(issuer)가 가상 SCL로 리소스 발견(discovery)를 요청한다.

단계 S72에서 가상 SCL은 자신에게 저장되어 있는 상술한 바와 같은 리소스들 간의 상관도에 관한 테이블을 이용하는 등의 로컬 프로세싱에 의해 대체 리소스를 검색하여 선택한다.

단계 S73에서 선택된 대체 리소스에 대한 어나운스된 리소스를 포함하고 있는 어나운스투 SCL(Announced-to SCL)에 대체 리소스에 대한 위치 정보를 요청한다.

단계 S74에서 어나운스투 SCL은 대체 리소스에 대한 위치정보를 포함하는 응답 메시지를 가상 SCL에 리턴한다.

이후 가상 SCL은 어나운스투 SCL로부터 전달받은 대체 리소스에 대한 위치 정보를 관련 SCL들의 홉타입 정보와 함께 관련 SCL에 대체 리소스 요청 메시지를 전송한다(단계 S75). 도시된 도면에서는 2홉의 경우를 예시하며, 이 경우 관련 SCL들은 로컬 SCL, 중간 SCL 및 호스팅 SCL이 될 것이다.

단계 S76에서는 관련 SCL들은 각각 리소스 요청 메시지에 대한 응답 메시지를 가상 SCL 또는 요청자에게 직접 전송한다.

본 발명은, 예를 들어, 댁 내의 소리를 감시하는 음파 센서, 댁 내에 사람 또는 동물 등의 움직임을 감지하는 적외선 센서, 가정 외부의 정보를 감시하기 위한 온라인 정보 기기, 댁내의 영상의 기록하는 영상 정보 감시 장치를 포함하고, 이들로부터의 정보를 서버(즉, NSCL)로 전송하는 게이트웨이(즉, GSCL) 및 NSCL로부터 댁내 감시 정보를 전송받기 위한 NA가 구현된 원격 무선 단말로 이루어진 홈 네트워크의 방범 시스템에 적용될 수 있다.

상술한 바와 같은 구성을 갖는 홈 네트워크 방범 시스템에서, 예를 들어 적외선 센서에 장애가 발생한 경우, 종래 기술에 따르면 적외선 센서를 이용하는 홈 네트워크 방범 서비스는 적외선 센서의 장애가 복구될 때까지 중단된다. 그러나 본 발명에 따르면 예를 들어, 상관 계수 분석 결과 음파 센서가 적외선 센서와 상관도가 높아서 적외선 센서와 유사한 효과를 발생시킬 수 있다고 판단되면, 적외선 센서를 대체하여 음파 센서로부터 데이터를 제공함으로써 서비스의 중단 없이 안정적으로 홈 네트워크의 방범 서비스를 제공할 수 있게 된다.한편, 맥박계와 심전도계 등 복수의 의료기기를 이용하여 이헬스 서비스를 제공받는 환자의 경우에도, 본 발명에 따르면, 예를 들어 각 의료기기의 사용 빈도 및 유사성 등에 대한 상관도를 미리 파악하고 있으므로, 반복적으로 사용되는 기기는 거의 준비 시간 없이 곧바로 대체 리소스 사용이 가능하도록 준비될 수 있는 효과를 가지며, 또한 특정 기기에서 장애가 발생할 경우 대체가능한 기기가 즉시 이용될 수 있으므로 보다 안정적인 의료서비스를 제공받을 수 있는 효과가 있다. 또한, 본 발명은 상술한 바와 같은 효과를 ETSI 표준 문서에서 제안하고 있는 기능을 응용 또는 활용하여 구현될 수 있기 때문에, ETSI 표준에 따르는 한 특정 회사나 국가에 관계없이 누구라도 어떠한 제품에라도 범용적으로 적용될 수 있는 효과도 있다.

Claims

M2M 네트워크의 리소스들 간의 상관도에 관한 정보를 저장하는 가상 SCL을 생성하는 단계;
요청자의 요청에 상응하는 리소스를 제공할 수 없는 경우 상기 가상 SCL이 상기 상관도에 기초하여 상기 요청된 리소스를 대체하는 대체 리소스를 선택하는 단계; 및
상기 가상 SCL이 상기 대체 리소스가 존재하는 SCL에 대한 도달 정보를 기초로 상기 대체 리소스를 요청하는 단계
를 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 1 항에 있어서
상기 상관도는 상기 리소스들 간의 도달 가능성에 대한 상관 계수 또는 상기 리소스들 간의 재사용 가능성에 대한 상관 계수 중 하나 이상인 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 2 항에 있어서,
상기 도달 가능성에 대한 상관 계수는 상기 리소스들 각각에 대한 액세스 이력에 기초하여 산출되는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 2 항에 있어서,
상기 재사용 가능성에 대한 상관 계수는 상기 리소스들 각각에 대하여 다른 리소스로부터의 호출 이력에 기초하여 산출되는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 1 항에 있어서,
상기 도달 정보는 상기 요청된 리소스 또는 상기 대체 리소스가 존재하는 SCL의 URI인 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 1 항에 있어서,
상기 대체 리소스를 요청하는 단계는, 상기 대체 리소스에 대한 홉(hop) 타입 정보와 함께 상기 요청자의 요청을 관련 SCL에 전달하는 단계를 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 1 항에 있어서,
상기 요청된 리소스를 제공할 수 있는 경우에는 상기 요청된 리소스가 존재하는 SCL에 상기 요청자의 요청을 전달하는 단계를 더 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 7항에 있어서,
상기 요청된 리소스가 존재하는 SCL에 상기 요청자의 요청을 전달하는 단계는, 상기 요청된 리소스에 대한 홉 타입 정보를 함께 전달하는 단계를 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
제 6 항 또는 제8 항에 있어서,
상기 홉 타입 정보를 이용하여 상기 요청된 리소스 또는 상기 대체 리소스가 존재하는 SCL이, 상기 가상 SCL 또는 상기 요청자에게 상기 요청자의 요청에 대한 응답 메시지를 제공하는 단계를 더 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 방법.
리소스들의 URI 및 상기 리소스들 간의 상관도에 관한 정보를 생성하기 위하여 상기 리소스들을 분석하는 분석 모듈; 및
요청자가 요청한 리소스의 응답 가능 여부에 따라 상기 상관도에 관한 정보에 기초하여 대체 리소스를 선택하는 가상 SCL을 생성하는 가상 SCL 생성모듈
을 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 장치.
제 10 항에 있어서,
상기 상관도는 상기 리소스들 간의 도달 가능성에 대한 상관 계수 또는 상기 리소스들 간의 재사용 가능성에 대한 상관 계수 중 하나 이상인 것을 특징으로 하는 M2M 네트워크의 리소스 관리 장치.
제 10 항에 있어서,
상기 가상 SCL은, 상기 리소스 요청에 대한 응답이 불가능한 경우 상기 상관도가 높은 리소스들 중에서 상기 대체 리소스를 선택하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 장치.
제 12 항에 있어서,
상기 가상 SCL은 상기 대체 리소스가 존재하는 SCL에, 상기 요청자의 요청과 함께 상기 요청된 리소스에 대한 홉 타입 정보를 함께 전달하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 장치.
제 10 항에 있어서,
상기 M2M 네트워크의 구성 여부 또는 리소스에 대한 요청자(issuer)의 요청이 발생하는 경우 어나운스된 리소스(annouced resource)가 있는지를 모니터링하는 모니터링 모듈을 더 포함하는 것을 특징으로 하는 M2M 네트워크의 리소스 관리 장치.