KR102091069B1 - 향상된 RESTful 동작들 - Google Patents

Abstract

CRUD 동작들의 배치는 새로운 CRUD 요청들을 시작하지 않고 리소스 발견 동작과 결합되어 일치된 리소스들에 대해 직접 수행될 수 있다. 발신자 및 수신자에서의 새로운 기능은 발견/필터링 결과들에 포함된 리소스들로부터 기준 일치가 적용되는 리소스들을 구분할 수 있다. 발신자 및 수신자에서의 향상된 기능은 발견된 리소스들과 상이하지만 관련된 리소스 세트를 목표로 하는 RESTful 동작들과 발견을 결합할 수 있다. 다른 향상들은 필터와 일치하는 리소스들에 대해 지정 관계의 리소스들의 발견을 요청하거나 그 결과에 기반하여 그룹 형성을 요청하는데 이용될 수 있다.

Description

향상된 RESTful 동작들

관련 출원들에 대한 상호 참조

본 출원은 2015년 9월 23일에 출원된 미국 가특허 출원 제62/222,536호의 이득을 주장하며, 그 개시 내용은 전체가 개시된 바와 같이 본 명세서에 참조로 포함된다.

최근에는 머신들/디바이스들이 서로 통신할 수 있도록 하는 M2M 솔루션들이 의료 분야, 에너지 분야 및 자동차 분야에서 개발되고 있다. 최적화의 다음 단계는 동일한 플랫폼들에서 상이한 분야들로부터의 머신들과 사물들을 통합하는 솔루션들을 제공하는 것이다.

이를 위해, 산업 분야들과 독립적인 애플리케이션들 간의 데이터의 교환 및 공유를 위한 수평 플랫폼을 정의하는 단일 표준 세트가 oneM2M에 의해 시작되었다. "oneM2M은 운영 시스템처럼 분산된 소프트웨어 계층을 생성하고 있으며, 이는 상이한 기술들과 상호연동하기 위한 프레임워크를 제공함으로써 통합을 촉진하고 있다"("The Interoperability Enabler for the Entire M2M and IoT Ecosystem", oneM2M 백서에서 인용됨). 이러한 분산된 소프트웨어 계층은 애플리케이션 계층(104)에서의 M2M 애플리케이션들과, 네트워크 서비스 계층에서 데이터 전송을 제공하는 통신 하드웨어/소프트웨어 사이에 있는 공통 서비스 계층(106)에서 구현된다(도 1 참조).

서비스 계층(106)은 공통 서비스 기능들(CSF들)에 의해 기능적으로 인에이블링된다. CSF들의 그룹은 공통 서비스 엔티티들(CSE들) 상에서 그룹으로 인스턴스화될 수 있다. 예시적인 CSE(202)가 도 2에 도시되어 있다. CSF들의 예들은 다음의 단락들에서 설명된다.

애플리케이션 및 서비스 계층 관리 CSF(204)는 AE들 및 CSE들의 관리를 제공한다. 이것은 AE들을 업그레이드할뿐만 아니라 CSE의 기능들을 구성, 문제해결 및 업그레이드하는 능력들을 포함한다.

발견 CSF(206)는 필터 기준에 기반하여 애플리케이션들 및 서비스들에 관한 정보를 검색한다. 이 CSF에 대한 추가 정보는 아래에 설명되어 있다.

등록 CSF(208)는 AE들(또는 다른 원격 CSE들)이 CSE에 등록하기 위한 기능을 제공한다. 이를 통해, AE들(또는 원격 CSE)이 CSE의 서비스들을 이용할 수 있다.

통신 관리/전달 처리 CSF(210)는 다른 CSE들, AE들 및 NSE들과의 통신들을 제공한다. 이 CSF는 통신들의 전달을 위해 언제 및 어떤 통신 접속을 이용할지 결정하고 필요하고 허용된다면 통신 요청을 버퍼링하여 나중에 전달될 수 있도록 결정한다.

그룹 관리 CSF(212)는 그룹 관련 요청들의 처리를 제공한다. 이것은 M2M 시스템이 다중의 디바이스들, 애플리케이션들 등에 대한 대량 동작들을 지원할 수 있게 한다.

보안 CSF(214)는 식별, 인증 및 허가를 포함하는 액세스 제어와 같은 서비스 계층에 대한 보안 기능들을 제공한다.

데이터 관리 및 저장소 CSF(216)는 데이터 저장 및 중재 기능들(집계를 위한 데이터 수집, 데이터 재포맷팅, 및 분석과 시맨틱 처리를 위한 데이터 저장)을 제공한다.

위치 CSF(218)는 AE들이 지리적 위치 정보를 얻을 수 있게 하는 기능을 제공한다.

서비스 과금 및 회계 CSF(220)는 서비스 계층에 대한 과금 기능들을 제공한다.

디바이스 관리 CSF(224)는 M2M 게이트웨이들 및 M2M 디바이스들에 대한 디바이스 관리 능력들을 제공한다.

네트워크 서비스 노출, 서비스 실행 및 트리거링 CSF(226)는 네트워크 서비스 기능들에 액세스하기 위한 하위 네트워크들과의 통신들을 관리한다.

가입 및 통지 CSF(228)는 이벤트에의 가입을 허용하고 이 이벤트가 발생할 때 통지될 수 있는 기능을 제공한다.

oneM2M 아키텍처는 CSE(202)에게 Mca, Mcc(및 Mcc') 및 Mcn 기준점들 (각각)을 통한 애플리케이션 엔티티들(AE)(230), 다른 CSE들, 및 네트워크 서비스 엔티티(NSE)(232), 즉 하위 네트워크와의 인터페이스를 제공한다.

oneM2M은 서비스 계층 아키텍처 사양들, 즉 도 3a에 도시된 리소스 지향 아키텍처(ROA) 및 도 3b에 도시된 서비스 지향 아키텍처(SOA)를 개발하기 위한 두 가지 아키텍처 접근법을 이용한다.

ROA 아키텍처는 oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0에 상세히 설명되어 있다. 이것은 그 기능을 가능하게 하도록 CSF들에 의해 수행되는 동작들 및 리소스들에 대해 개발되었다. 리소스들은 URI들(Uniform Resource Identifiers)을 통해 고유하게 주소지정가능한 아키텍처 요소들이다.

리소스들은 이들 간에 다수의 관계들이 정의되고 기반에서 나온 계층적 트리들로 볼 수 있다. 예를 들어, 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있으며, 자식 리소스는 부모 리소스와 포함 관계를 갖는다. 따라서, 부모 리소스 표현은 그 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모 리소스의 수명에 의해 제한된다.

속성들은 리소스 정보를 저장하는 아키텍처 요소들이다. oneM2M은 모든 리소스들에 공통인 속성들의 세트를 정의하고, 다른 속성들은 개별적인 리소스들에 특정되며 "리소스 특정 속성들"로 지칭된다. 하나의 CSE에 위치한 리소스들(호스팅 CSE로 지칭됨)은 원격 CSE들에 알려질 수 있으며, 이러한 리소스들은 "알려진 리소스들"로 지칭된다. 알려진 리소스들은 자체 속성들뿐만 아니라 원래 리소스의 속성들을 포함할 수 있다. 원래 리소스와 알려진 리소스 간의 동기화는 호스팅 CSE의 책임이다.

SOA 아키텍처는 oneM2M-TS-0007, 서비스 구성요소 아키텍처 V0.8.1에 상세히 설명되어 있다. 이것은 서비스들 자체에 대해 개발되었으며 RESTful 기반이 아닌 레거시 전개들에서 이용될 수 있다. SOA 서비스 계층은 서비스 구성요소들로 그룹화될 수 있는 다양한 M2M 서비스들을 포함한다. SOA 아키텍처는 ROA 아키텍처에서 도입된 기존의 기준점들 외에도 서비스간 기준점 Msc를 도입한다.

oneM2M에서 정보 교환을 관리하는 일반적인 흐름은 oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0에 설명되어 있으며 도 4에 도시된 통신 절차에서 요청 및 응답 메시지들의 이용에 기반한다. 발신자(402)는 수신자(404)에 요청 메시지를 보내고, 수신자(404)는 응답 메시지로 응답한다.

이 절차는 (Mcc 기준점을 통한) CSE들 간의 통신들뿐만 아니라 (Mca 기준점을 통한) AE들과 CSE 간의 통신들에 적용된다. 메시지들에 의해 수행되는 동작에 따라, 이 절차들은 생성, 검색, 업데이트 및 삭제와 같은 RESTful 메소드(method)들을 통해 표준화된 리소스 표현들에서의 정보를 조작할 수 있다.

요청 및 응답 메시지들 모두는 지정되며 필수, 임의적인 또는 조건부 파라미터들을 포함한다. 표 1은 간단한 설명들을 가진 요청 파라미터들의 리스트이며, 전체 설명들은 oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0에서 찾을 수 있다.

<표 1>

위의 요청 파라미터들 중 일부의 이용은 발견 동작들에서 중요한 역할을 하며 다음 섹션에서 상세히 설명한다.

마찬가지로, 표 2는 간단한 설명들을 가진 응답 파라미터들의 리스트를 제공하며, 전체 설명들은 oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0에서 찾을 수 있다.

<표 2>

리소스 발견은 엔티티(발신자(402)로 지칭됨)가 속성들 및 리소스들에 포함된 애플리케이션들 및 서비스들에 관한 정보를 검색하는 프로세스이다. oneM2M에서, 리소스 발견의 발신자(402)는 AE 또는 CSE일 수 있으며, 검색이 시작될 수신자 CSE(404')에서 루트 리소스를 목표로 할 수 있다.

검색 결과의 콘텐츠는 (예를 들어, 리소스 유형, 리소스 생성 시간, 리소스 크기 등에 기반하여) 특정 검색 파라미터들을 일치시킴으로써 필터 기준 일부에 의존한다. 일부 동작 파라미터들(예를 들어, 발견 결과 유형)과 함께 다른 필터 기준 파라미터들(예를 들어, 한계)은 검색 결과의 콘텐츠가 발신자(402)에게 되돌려 제공되는 방식으로 역할을 한다. CRUD와 마찬가지로, 발견 동작은 수신자 CSE(404')에서의 액세스 제어 정책의 적용을 받으며, 즉 발신자(402)가 "발견" 액세스 권한을 갖게 한다.

검색 파라미터들의 완전한 리스트는 표 3에 제공되며, oneM2M-TS-0001(oneM2M 기능 아키텍처 V2.1.0)에서의 표 8.1.2-1을 기반으로 한다. 그러나, 본 발명자들은 본 명세서에서 일치를 위해 제공된 필터 기준과, 기준 이용의 유형을 지정하는 것 또는 결과들이 회신되는 방식과 같이 다른 역할들을 가진 기준을 구별한다. 이러한 파라미터들은 관계형 동작들에 의해 결합되어 복합 검색 기준을 생성할 수 있다.

<표 3>

oneM2M ROA에서, 리소스 발견은 검색 메소드를 이용하여 구현되며, 리소스 발견 동작과 일반 검색 동작을 구별하기 위해 filterUsage를 이용하여 수신자 CSE(404')에 표시한다.

일반 리소스 발견 절차가 도 5에 도시되어 있다. 발신자(402)는 리소스 <CSEBase>/<ae01>의 특정 자식 리소스들을 목표로 하는 리소스 발견 요청(단계(001))을 수신자 CSE(404')에 발행한다. 수신자 CSE(404')는 이 요청을 처리하고 발견된 리소스들의 적합한 리스트를 회신한다. 수신자 CSE(404')는 발견된 리소스들의 발견 권한들에 따라 발견 결과를 제한할 수 있으며, 자체 로컬 정책에 따라 필터 기준을 변경할 수 있다. 발견된 리소스들의 전체 리스트가 회신될 수 없는 경우, 수신자 CSE(404')는 (플래그로) 발신자(402)에게 경고할 것이다. 리소스 발견 응답(단계(003))은 필터 기준과 일치하는 리소스들의 주소 리스트를 포함한다. 필요할 경우, 주소들이 가리키는 리소스들을 검색하는 것은 발신자(402)의 책임이다.

CRUD 동작들의 배치(batch)들은 새로운 CRUD 요청들을 시작하지 않고 리소스 발견 동작과 결합되어 리소스 발견 결과에 대해 직접 수행될 수 있다.

발신자 및 수신자에서의 새로운 기능은 발견/필터링 결과들에 포함된 리소스들로부터 기준 일치가 적용되는 리소스들을 구분할 수 있다. 발신자는 리소스 발견 결과가 필터링 결과에 제공되도록 요청할 수 있다. 필터링 결과는 발신자 지정 필터 기준을 충족시키는 일치된 리소스 세트와 상이할 수 있지만 관련이 있을 수 있다. 필터링 결과에서의 리소스들과 일치된 리소스 세트에서의 리소스들 간의 관계는 또한 발신자에 의해 지정될 수 있다.

발신자 및 수신자에서의 향상된 기능은 RESTful 및 발견 동작들과 연결될 수 있다. 발신자는 목표 리소스 세트에 대한 동작을 요청할 수 있다. 목표 리소스 세트는 발신자 발견 요청에 기반하여 발견된 리소스들의 세트(필터링 결과)와 상이할 수 있지만 관련이 있을 수 있다. 목표 리소스 세트에서의 리소스들과 필터링 결과에서의 리소스들 간의 관계는 또한 발신자에 의해 지정될 수 있다.

특정 필터 기준과 일치하는 부모 또는 자식을 갖는 리소스들을 발견하는 것과 같은 향상된 필터 기준이 이용될 수 있다.

향상된 필터 지시는 예를 들어 필터 기준과 일치하는 리소스들에 대한 그룹의 생성을 요청하거나 필터링 결과와 일치된 리소스들 간의 관계를 지정하는데 이용될 수 있다.

향상된 예외 처리는 예를 들어 발신자 요청에 기반하여 특정 조건들이 발생할 때 수행될 CRUD 동작을 포함하여 수신자 행동을 변경하는데 이용될 수 있다.

도입된 RESTful 동작들의 새로운 파라미터들 및 처리는 다음과 같이 새롭거나 향상된 기능을 추가로 가능하게 할 수 있다.

· 수신자에서만 처리하고 발신자와 수신자 간에 앞뒤로 메시지를 보내지 않고, 발견된 리소스들에 대해 생성 동작이 후속되도록 리소스 발견을 요청할 수 있는 능력

· 수신자에서만 처리하고 발신자와 수신자 간에 앞뒤로 메시지를 보내지 않고, 발견된 리소스들에 대해 업데이트 동작이 후속되도록 리소스 발견을 요청할 수 있는 능력

· 수신자에서만 처리하고 발신자와 수신자 간에 앞뒤로 메시지를 보내지 않고, 발견된 리소스들에 대해 삭제 동작이 후속되도록 리소스 발견을 요청할 수 있는 능력

· 동일한 메시지를 이용하여 요청되었지만 발견 절차와 CRUD 동작에 대해 상이한 목표들을 제공할 수 있는 능력

· 리소스 트리의 다양한 레벨들에서 일치되는 조건들을 이용하여 CRUD 동작들 이전에 수행된 발견 동작 또는 필터링을 향상시킬 수 있는 능력

· 주어진 기준에 기반하여 일치되는 리소스들과 필터링/발견 결과를 구성하는 리소스들 간의 차이/관계를 지정할 수 있는 능력

· 필터링/발견 결과로부터 동작 목표를 결정할 때 예를 들어, 부모/자식, 시맨틱 설명자(semantic descriptor) 등과 같은 리소스 관계들을 이용함으로써 필터링/발견 결과를 구성하는 리소스들과 CRUD 동작들이 목표로 하는 리소스들 간의 차이/관계를 지정할 수 있는 능력

· 발견 동작의 일치되거나 필터링된 리소스들로 구성된 그룹의 생성을 요청할 수 있는 능력

· 특정 조건들/예외들이 발생할 때 수행될 동작에서의 변경들을 요청할 수 있는 능력.

본 내용은 아래의 상세한 설명에서 추가로 설명되는 개념들의 선택을 단순화된 형태로 소개하기 위해 제공된다. 본 내용은 청구되는 주제의 주요한 특징들 또는 필수적 특징들을 식별하고자 의도되는 것도 아니고, 청구되는 주제의 범위를 제한하는데 이용되고자 의도되는 것도 아니다. 게다가, 청구되는 주제는 본 개시 내용의 임의의 부분에서 언급되는 임의의 또는 모든 단점들을 해결하는 제한들에 국한되지 않는다.

첨부 도면들과 관련하여 예로서 주어져 있는 이하의 설명으로부터 보다 상세한 이해가 이루어질 수 있다.
도 1은 oneM2M 계층 모델의 도면이다.
도 2는 공통 서비스 기능들의 도면이다.
도 3a는 oneM2M 기능 아키텍처에서의 리소스 지향 아키텍처(ROA)의 도면이다.
도 3b는 oneM2M 기능 아키텍처에서의 서비스 지향 아키텍처(SOA)의 도면이다.
도 4는 oneM2M에서의 일반 통신 흐름의 도면이다.
도 5는 oneM2M 일반 리소스 발견 절차의 도면이다.
도 6은 작업관리자 이용 사례의 도면이다.
도 7은 기존의 oneM2M 동작들을 갖는 이용 사례 흐름의 도면이다.
도 8a 및 도 8b는 기존의 oneM2M 동작들을 갖고 그룹 기능을 이용하는 이용 사례 흐름의 도면이다.
도 9는 일반적인 향상된 동작들에 대한 콜 흐름의 도면이다.
도 10은 작업관리자 이용 사례에 대해 향상된 생성 동작을 이용하는 예시적인 콜 흐름의 도면이다.
도 11은 처리 예들에 대한 일반적인 콜 흐름의 도면이다.
도 12a 및 도 12b는 요청 처리 흐름도의 도면이다.
도 13은 일 실시예의 그래픽 이용자 인터페이스의 도면이다.
도 14a는 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 도면이다.
도 14b는 M2M 애플리케이션, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들 및 통신 네트워크를 위한 서비스들을 제공하는 필드 도메인 내의 예시적인 M2M 서비스 계층의 도면이다.
도 14c는 본 명세서에서 설명되는 네트워크 노드들 중 임의의 네트워크 노드를 구현하는데 이용될 수 있는 예시적인 디바이스의 도면이다.
도 14d는 본 명세서에서 설명되는 네트워크 노드들 중 임의의 네트워크 노드를 구현하는데 이용될 수 있는 컴퓨터 시스템 또는 서버의 블록도이다.

약어들

AE 애플리케이션 엔티티

App 애플리케이션

ACP 액세스 제어 정책

ASN 애플리케이션 서비스 노드

CRUD 생성, 판독, 업데이트 및 삭제

CSE 공통 서비스 엔티티

CSF 공통 서비스 기능

DIS 발견

DMR 데이터 관리 및 저장소

HW/SW 하드웨어/소프트웨어

IN 인프라스트럭처 노드

IoT 사물 인터넷

M2M 사물 통신

MN 중간 노드

ROA 리소스 지향 아키텍처

SOA 서비스 지향 아키텍처

URI 통합 리소스 식별자

정의들

공통 서비스 엔티티(CSE): 공통 서비스 기능들의 세트의 인스턴스화에 대한 oneM2M 용어이다.

공통 서비스 기능(CSF): 서비스 능력에 대한 oneM2M 용어이다. 공통 서비스 계층에 있는 능력들/기능들이다.

호스팅 CSE: 다양한 리소스들(호스팅 노드에 대한 oneM2M 이름)을 호스팅하는 CSE일 수 있다.

호스팅 노드: 다양한 리소스들을 호스팅하는 M2M 서비스 노드일 수 있다. 호스팅된 리소스들은 다른 M2M 엔티티들에 의해 액세스되고 가입될 수 있다.

M2M 엔티티들: 필드 및 인프라스트럭처 도메인들 모두에서 M2M 통신들에 참여하는 임의의 노드일 수 있다.

M2M 서비스 노드: M2M 통신을 위한 하나 이상의 서비스 능력을 지원하는 서비스 계층을 호스팅하는 네트워크 노드일 수 있다.

중간 노드 CSE: 중간 노드에서의 CSE일 수 있다.

중간 노드: 필드 도메인 M2M 엔티티와 인프라스트럭처 노드 또는 엔티티 사이의 노드일 수 있다.

발신자: RESTful 동작에 대한 요청 메시지를 시작하는 엔티티일 수 있다. 예를 들어, 발신자가 검색을 통해 리소스 발견을 수행하려고 시도하는 CSE일 수 있다.

서비스 능력: 서비스 계층에 의해 지원되는 특정 유형의 서비스일 수 있다.

서비스 계층: M2M 애플리케이션들과 데이터 전송을 제공하는 통신 HW/SW 사이에 있는 소프트웨어 미들웨어 계층일 수 있다. 상이한 산업 부문들에 걸친 M2M 애플리케이션들에게 일반적으로 필요한 기능들을 제공할 수 있다.

수신자: RESTful 동작을 갖는 요청 메시지를 수신하는 엔티티일 수 있으며, 메시지를 처리하고 대응하는 응답 메시지를 보낼 수 있다.

이용 사례: 산업 작업관리자

도 6은 다양한 고정 머신류, 이동 차량들 및 로봇들뿐만 아니라 이동가능한 툴들(일반적으로 "장비"로 지칭됨)을 갖는 산업 층(600)을 도시한다. 머신들, 차량들, 툴들, 로봇들 및 바닥에 다양한 센서들이 있다. 사람들은 또한 지역을 이동하고 개별적인 작업들을 수행한다.

불규칙한 층에는 다양한 수준들의 복잡한 서비스들을 제공하는 장비와 통신하는 다중의 게이트웨이들이 있다. oneM2M 기반 플랫폼을 이용하는 예에서, 게이트웨이들은 MN-CSE들 및 장비를 가장 가까운 게이트웨이에 등록된 ASN들 또는 ADN들에 있는 AE들(예를 들어, AE1, 2 ... 또는 AEx, y, z ...)에 매핑한다. 따라서, 개별적인 MN은 자동화된 밀링 머신들 또는 선반들과 같은 정적이고 복잡한 머신들을 제어하는데 필요한 리소스들뿐만 아니라 다양한 주변 센서들에 의해 제공되는 센서 측정들을 호스팅할 수 있다. 이동적인 로봇들은 또한 이동(transition) 후에 가장 가까운 게이트웨이에 등록된다. M2M 플랫폼은 공장에 서비스들을 제공하고 MN-CSE들을 통합하여 위치 및 시맨틱 서비스들을 또한 제공한다. 예를 들어, M2M 플랫폼은 대응하는 리소스들을 통해 등록된 장비의 각각의 부분에 대한 위치, 동작 상태, 유지보수 상태 등의 정보를 유지한다. 이 경우, 본 발명자들은 관련 리소스들에 적용된 라벨들을 통해 위치 및 유지보수 상태가 유지된다고 가정한다.

정비공은 바닥 구역들 중 하나에서 유지보수를 수행하였으며, 동작을 수행하기 위해 정지할 때 해당 영역에서 유닛들을 찾고 싶어한다. 예를 들어, 정비공은 장비 유형에 따라 상이할 수 있는 여러 구성요소들/품목들(예를 들어, 휠들, 베어링들, 축적된 잔해들)의 물리적 상태를 체크할 필요가 있다. 정비공은 산업 단지의 Wi-Fi 네트워크에 접속하고 가장 가까운 게이트웨이(MN-CSE1)(602)에 자체 등록하는 풍부한 능력들을 갖춘 모바일 디바이스에 액세스할 수 있다.

이 일에서, 정비공은 그 동작 준비가 된 임의의 장비를 검색하고 관련 디바이스들의 동작 상태 정보에 가입하는 "작업관리자" 애플리케이션(AE_tm)(604)을 이용한다. 가입들은 유지보수가 최신이 아닌 정비공 부근의 장비를 목표로 한다. 관련 리소스들에 적용된 라벨들(즉, 전문 리소스 속성들)을 통해 위치 및 유지보수 상태를 발견할 수 있다고 가정한다. 작업관리자는 관련 검색 기준(예를 들어, label=Sector#42 && label=maintenanceNotCurrent)을 이용하여 게이트웨이(MN-CSE1)(602)에 발견 요청 메시지를 발행하여 이 기능을 수행하고, 회신된 결과들에 기반하여, 애플리케이션은 동작 상태(예를 들어, 끄기, 유휴, 실행)에 대한 가입 통지를 생성한다. 여러 섹터들을 처리하는 게이트웨이는 정비공 부근에서 등록된 모든 장비의 리스트를 회신하고 동작 상태 컨테이너에 대한 가입을 생성한다.

작업관리자(AE_tm)(604)는 유휴이거나 꺼져 있는 하나의 장비에 대해 통보되자마자, 장비 유형(정적 대 비정적), 예상 유휴 시구간 등과 같은 추가 세부사항들을 검색한다. 정비공이 자신의 상태를 이용가능한 상태로 업데이트하면, 작업관리자는 정비공을 서비스할 다음 장비로 안내하고 장비의 특정 부분에 맞춰진 작업 체크리스트를 제공할 수 있다.

동작 상태의 동적 특성으로 인해(머신이 이용가능하게 된 다음 서비스를 받기 전에 다시 이용중일 수 있기 때문에), 동작 상태의 값을 기반으로 정규적으로 발견을 수행하는 것보다는 동작 상태에 가입하는 것이 더 효율적이다. 이것은 발견 요청들이 최소화되는 것을 보장할 것이다.

또한, 부근에 있는 모든 장비가 서비스되었거나, 유휴인 것이 없거나 장시간 유휴인 것으로 예상되는 것이 없거나 이용가능한 위치들이 변경된 경우, 특정 시간들에서 이용가능한 작업들이 없을 수 있다. 이러한 상황들 중 어떠한 상황에서도, 작업관리자는 새로운 위치와 같은 상이한 파라미터들을 이용하여 (자체 또는 정비공의 안내에 따라) 새로운 발견을 시작할 수 있다.

현재의 oneM2M 구현예에서 이 시나리오를 제공하기 위해, 작업관리자(AE_tm)(604) 애플리케이션은 발견 요청을 수행하여 영역 내의 장비를 찾고, 그 다음에 발견 결과들을 기반으로 가입 생성할 수 있다. 발견에서 장비의 많은 수의 부분들(예를 들어, N)이 회신되면, 도 7에 도시된 바와 같이 많은 수의 생성 요청들이 이어진다.

AE_tm(604)이 oneM2M 그룹 생성 메커니즘을 이용하는 경우, 그룹은 도 8a 및 도 8b에 도시된 바와 같이 매우 제한된 시간 동안 그리고 매우 적은 동작들 동안 글자 그대로 생성될 것이며 그 후에 삭제되어야 한다. 이는 현재 제공되는 메커니즘들이 최적화되지 않은 그룹 동작을 단순히 이용하는 것이다.

따라서, 이러한 메커니즘들은 필요한 메시징의 양 및/또는 (매우 제한된 용도로) 생성된 수명이 짧은 그룹들의 수에서의 오버헤드로 인해 최적이 아니다. 이 이용 사례는 생성 동작을 예로 들고 있지만, 이 사안은 모든 CRUD 동작들에 대해서도 유효하다.

기준 일치에 이용된 라벨들이 리소스 트리 전체의 다양한 레벨들에서 상이한 관리 애플리케이션들에 적용되면 다른 문제가 제기될 수 있다. 예를 들어, 유지보수 상태 라벨이 <AE> 부모 리소스에 적용된 동안 섹터 라벨이 <location> 자식 컨테이너에 적용되는 경우이다. 동일한 리소스에 대해 일치되는 필터 기준을 제공하는 현재의 메커니즘들은 임의의 단일 발견 요청을 통해 얻을 수 있는 결과들의 유용성을 제한한다.

때때로 작업관리자에 의해 이용된 절차는, 예를 들어 유지보수 업데이트를 수행하기 전에 머신이 이전에 서비스된 섹터로부터 이동한 경우에 이미 가입된 머신들을 발견할 수 있다. 이 경우, 작업관리자는 변경된 이름으로 새로운 리소스를 생성하는 대신에 생성 동작이 기존의 리소스를 업데이트하도록 요구할 수 있다.

동시에, 동일한 게이트웨이를 이용하는 다른 애플리케이션들은 유사한 사례에 대해 다른 처리를 요구할 수 있다. 예를 들어, 새로운 리소스를 생성하려고 시도할 때 동일한 이름의 기존의 자식 리소스가 있는 경우, 다른 애플리케이션은 기존의 리소스를 삭제하고, 동일한 이름과 새로운 콘텐츠를 가진 새로운 리소스를 생성해야 할 수 있다. 그러나, 일반적으로 이러한 조건들 또는 예외 사례들의 처리는 수신자(404)에서 디폴트 처리에 의존한다. 이것은 수신자(404)에서의 예외/조건 처리에서 차별화가 현재 달성될 수 없음을 의미한다.

현재의 RESTful 절차들은 CRUD(Create, Retrieve, Update 및 Delete) 동작들의 실행을 목표로 하며 또한 특정 기준 또는 조건들이 발생했는지 체크하는 것도 허용할 수 있다.

발견 요청의 결과를 목표로 하며, 이에 따라 발견 단계에서 제공한 리소스들에 대해 CRUD 동작들을 실행할 때 발견 및 다른 동작들을 수행하기 위한 일부의 별도의 하위 절차들와 단계들이 필요한 CRUD 동작들을 수반하는 많은 이용 사례들이 있다. 리소스들의 (둘 이상의) 세트를 야기하는 발견의 결과로서, 세트 내의 각각의 리소스에 대한 동작을 실행하기 위해 몇 가지 별도의 요청/응답 절차들이 필요하거나 그룹 생성이 필요하다.

그룹 동작들에 최적화된 특별한 절차들은 향상된 메시징 효율성을 제공하며 리소스들의 동일한 세트가 그룹으로 추가 처리를 필요로 하는 사례들에 매우 유용하다. 그러나, 발견 결과들을 기반으로 영구적인 리소스 그룹들을 생성할 필요가 없는 특별한 사례들이 있다. 결과 세트 유효 기간이 제한적인 경우(동일한 파라미터들을 이용하는 다른 발견 동작이 매우 빨리 상이한 결과들을 낼 경우) 또는 결과 세트에 대해 수행할 제한된 수의 동작들(가능하게는 하나)이 있는 경우의 사례들이 있다.

많은 사례들에서, 초기 리소스 트리 구조가 발견되면, 발견 동작은 검색 및 필터링에 이용되어 향후 동작들을 준비한다. 순차적인 메시징 및 처리를 요구하는 기존의 절차들은 일부 검색들을 수행하기 전에 발신자(402)에서 이미 이용가능한 리소스 트리 정보를 이용하지 않기 때문에 비효율적이다. 유사하게, 수신자(404)는 개별적인 단계들(예를 들어, 발견, 개별적인 CRUD 동작들)의 실행을 위해 별도로 정보를 획득하므로 이들을 함께 최적화할 수 없다. 이와 같이, 전술한 현재의 메커니즘들은 필요한 메시징의 양 및/또는 제한된 이용의 수, 생성된 수명이 짧은 그룹들의 오버헤드를 야기한다. 그러나, 원하는 CRUD 동작들과 동시에 리소스 발견을 요청할 수 있는 능력을 갖추면 상당한 최적화들이 이루어질 수 있다.

또한, 다중의 필터 기준이 다중의 관련된 리소스들 보다는 동일한 리소스에 대해 일치되도록 제공하는 현재의 메커니즘들은 임의의 단일 발견 요청을 통해 획득될 수 있는 결과들의 유용성을 제한하게 된다.

마지막으로, RESTful 동작 요청들의 현재의 처리는 수신자(404)에서 예외/조건 처리의 차별화를 허용하지 않으며 차별화된 요구들이 있는 애플리케이션들에 의한 이용을 제한한다.

명명법

위에서 논의된 바와 같이, 많은 사례들에서 리소스 발견 동작은 리소스 발견 결과를 목표로 하는 새로운 CRUD 요청들의 배치가 후속된다. 새로운 솔루션에서, CRUD 동작들의 배치는 리소스 발견 동작과 결합되어, 새로운/별도의 CRUD 요청들을 시작하지 않고, 발견된 리소스들에 대해 직접 수행될 수 있다.

이러한 향상들은 필터링 및 발견의 요소들을 기존의 CRUD 동작들과 통합시킨다. 이 섹션에서 제공되는 명명 규칙은 다음의 설명들에서 이용되는 용어들을 명확히 하기 위한 것이다.

필터 기반: 발견 동작의 시작점으로 이용되는 리소스이며, 이 리소스의 하위항목들은 필터 기준에 따른다.

일치된 리소스: 필터 기준이 참인 리소스이다.

필터링 결과: 필터링 또는 발견 동작의 결과는 동작 파라미터들에 따라 일치된 리소스들 또는 일치된 리소스들과 관련된 리소스들로 구성될 수 있다. 이는 하나 이상의 리소스로 구성될 수 있다.

목표 리소스 세트: CRUD 동작의 목표인 하나 이상의 리소스이다. 목표 리소스 세트는 발견 동작의 필터링 결과와 같을 수 있거나 동작 파라미터들에 따라 필터링 결과와 관련된 리소스들로 구성될 수 있다.

동작 결과: 목표 리소스 세트에 대한 CRUD의 결과를 표시한다. 본 명세서에서 설명되는 향상된 동작들에 있어서, 목표 리소스 세트가 다중의 리소스들로 구성된 경우 다중의 리소스들에 대한 동작의 결과일 수 있다. 결과 메시지에 포함된 동작 결과의 형식은 요청에서 제공된 옵션들, 예를 들어 리소스들, 리소스들 및 자식 리소스들 등에 기반하여 변할 수 있다.

개요

다음 섹션들에서는 RESTful 동작들의 향상들에 대해 설명한다. 요청 메시지들에 대한 전반적인 향상들은 다음을 포함하여 설명된다.

· 발견/필터링 결과들에 포함되는 리소스들과 기준 일치가 적용되는 리소스들을 구분하는 발신자(402) 및 수신자(404)에서의 새로운 기능 및 새로운 요청 메시지 파라미터들이다. RESTful 및 발견 동작들을 연결하는 발신자(402) 및 수신자(404)에서의 향상된 기능이다.

· (예를 들어, 특정 필터 기준과 일치하는 부모 또는 자식을 갖는 리소스들을 발견하기 위한) 필터 기준에 대한 향상들이다. 또한, (예를 들어, 필터 기준과 일치하는 리소스들에 대한 그룹 생성을 요청하거나 목표 리소스들과 일치된 리소스들 간의 관계를 지정하기 위한) 향상된 필터 지시들을 도입한다.

· 향상된 예외 처리: 예를 들어 특정 조건들 또는 예외 상황들이 발생했을 때 행동을 변경하기 위한 것이다.

위에 요약된 향상들의 절차적인 효과들과 발신자(402) 및 수신자(404) 모두에서의 파라미터 이용에 대한 추가적인 세부사항들을 제공한다.

oneM2M 실시예들은 설명된 동작들에 대한 구체적이고 표준화된 리소스들의 예들을 이용할 수 있으므로 처리에 대한 추가적인 세부사항들과 함께 설명된다.

요청 메시지 향상들

새로운 요청 메시지 파라미터들

이 섹션에서는 새로운 동작 파라미터들을 도입하여 요청 메시지들의 기능 향상들을 설명한다.

일반적으로 정보 교환 절차들을 관리하는 흐름은 요청 및 응답 메시지들의 이용을 기반으로 한다. 요청들은 발신자(402)에 의해 수신자(404)에게 보내지며, 필수적이거나 임의적일 수 있는 파라미터들을 포함한다. 특정 파라미터들은 요청된 동작에 따라 필수 또는 임의적일 수 있다.

다음의 요청 메시지 파라미터들이 있다고 가정한다.

· Operation: 실행될 정확한 RESTful 동작, 예를 들어 생성 등을 지정한다.

· To: 동작이 실행될 목표 리소스의 주소이다.

· FilterCriteria: 조건 일치 기준이다.

· Content: 동작에서 이용될 리소스 콘텐츠, 예를 들어 생성될 리소스의 콘텐츠이다. 그 존재는 모든 동작들에 필수적인 것으로 간주되지 않는다.

또한, 다음의 응답 메시지 파라미터들이 있다고 가정한다.

· Response Code: 동작의 성공 또는 실패를 표시하는 파라미터이다. 추가 실행 세부사항들을 제공하는 상태 정보를 포함할 수 있다.

· Content: 동작 결과에 기반한 리소스 콘텐츠, 예를 들어 생성된 리소스의 콘텐츠이다. 그 존재는 모든 동작들에 필수적인 것으로 간주되지 않는다.

새로운 동작 파라미터들이 RESTful 요청 동작에 대해 설명된다.

(새로운) FilterBase: 호스팅 CSE에서 발견이 시작되는 루트의 주소이다.

선택들은 다음을 포함하지만 이에 국한되지는 않는다.

o FilterCSEBase: 수신자(404)는 CSEBase에서 발견을 시작한다.

o (FilterAddress): 수신자(404)는 이 필드에 포함된 지정된 주소에서 발견을 시작한다.

o NULL 또는 DEFAULT(또는 존재하지 않음): 향상된 기능이 요청되지 않고 정규 처리가 수행된다.

FilterBase가 있고 NULL 또는 DEFAULT와 상이한 경우, 동작이 향상된 동작으로 취급됨을 표시할 수 있다.

때로는 요청들이 운송 CSE를 통해 수신자(404)인 최종 목적지로 라우팅된다. 정규 동작들의 경우, 운송 CSE는 To 주소가 가리키는 수신자(404)로 메시지들을 라우팅한다. FilterBase 주소의 존재로 표시되는 향상된 동작들의 경우, 운송 CSE는 메시지들을 FilterBase 주소로 라우팅할 것이다. 다른 모든 처리는 이 문서에 제시된 직접 통신 사례들에서와 동일하다.

FilterCSEBase 선택은 수신자(404)에서 대응하는 URI로 결정된다. 구현예는 전술한 기능 중 어떤 것을 잃지 않고 실제 주소가 제공되는 제2 선택만을 이용할 수 있다.

(새로운) CompositeResult: 발신자(402)에게 결과 메시지에서의 Content 필드의 예상된 구성요소들을 표시한다.

설명된 기능을 기반으로 하는 선택들은 다음을 포함하지만 이에 국한되지는 않는다.

o FilteringResult: 수신자(404)는 발신자(402)에 의해 지정된 파라미터들을 기반으로 발견 동작의 필터링 결과를 회신할 것이다(아래의 필터 기준 참조).

o OperationResult: 수신자(404)는 목표 리소스 세트에 대한 RESTful 동작의 결과를 회신할 것이다.

o FilteringAndOperationResult: 수신자(404)는 필터링 결과와 목표 리소스 세트에 대한 RESTful 동작의 결과 모두를 회신할 것이다.

o Nothing 또는 DEFAULT(또는 존재하지 않음): 수신자(404)는 결과를 회신하지 않는다.

(새로운) ExceptionHandling: 특정 조건들 또는 예외들의 처리를 표시한다.

선택들은 다음을 포함하지만 이에 국한되지는 않는다.

o UpdateExistingName: 수신자(404)가 리소스를 생성할 때 이용된다. 발신자(402)가 "UpdateExistingName"을 요청하면, 수신자(404)는 발신자(402)가 제공 한 이름을 이용해야 한다. 그 결과, 특정 동작 조치들(예를 들어, 생성)이 수정될 필요가 있을 수 있다.

o NULL 또는 DEFAULT(또는 존재하지 않음): 수신자(404)는 디폴트 예외 처리를 이용한다.

기존의 RESTful 요청 파라미터의 기능을 다음과 같이 향상시킬 수 있다.

(향상된) To: CRUD 동작이 실행될 목표 리소스를 주소지정하는 고유 URI로 결정하는데 현재 필요한 주소이다.

이 제안에서, 본 발명자들은 발견된 리소스들(필터링 결과들)과 RESTful 동작이 수행될 리소스들(목표 리소스들) 간의 상대 관계를 제공하기 위해 To 파라미터를 이용하는 옵션을 추가한다.

이 옵션은 향상된 동작들에 대해서만 유효하며, 이 목적을 위해, To 필드는 목표 리소스 세트를 획득하기 위해 필터링 결과와 연관될 상대 경로로서 제공되어야 한다. To 필드에 제공된 주소가 상대 주소가 아닌 경우, 목표 리소스 세트는 필터링 결과와 동일하다.

필터 기준에 대한 다른 가능한 향상들은 실시예 섹션에서 상세히 설명된다.

필터링 기준 및 지시들에 대한 향상들

본 발명자들은 필터링 또는 발견 목적들에 이용되는 기존의 RESTful 동작들에서 필터 기준을 제공하는 가능성을 가정한다. 기존의 필터링 및 발견 프로세스들을 강화하기 위해, 본 발명자들은 관련된 리소스들을 일치시키는데, 즉 자식 또는 부모 리소스들의 속성들을 일치시키는데 이용되는 필터링 기준을 표시하기 위한 몇 가지 새로운 파라미터들의 도입을 제안한다.

여기서, 다음의 새로운 검색 파라미터들에 대해 설명한다.

· (새로운) childResourceType: 일치된 리소스는 이 유형의 자식 리소스를 가져야 한다.

· (새로운) childResourceName: 일치된 리소스는 이 이름을 가진 자식 리소스를 가져야 한다.

· (새로운) childLabels: 일치된 리소스는 주어진 값과 일치하는 라벨을 가진 자식 리소스를 가져야 한다.

· (새로운) childAttribute: 일치된 리소스는 주어진 값과 일치하는 속성을 가진 자식 리소스를 가져야 한다.

· (새로운) parentResourceType: 일치된 리소스는 이 유형의 리소스를 그 부모로서 가져야 한다.

· (새로운) parentResourceName: 일치된 리소스는 이 이름의 리소스를 그 부모로서 가져야 한다.

· (새로운) parentLabels: 일치된 리소스는 주어진 값과 일치하는 라벨을 가진 리소스를 그 부모로서 가져야 한다.

· (새로운) parentAttribute: 일치된 리소스는 주어진 값과 일치하는 속성을 가진 리소스를 그 부모로서 가져야 한다.

필터 기준이 이용되어야 하는 방법을 표시하고, 이에 따라 필터링 지시들로서 기능하는 파라미터들이 또한 이용될 수 있다.

(새로운) returnRelativeRelationship은 발견 결과(필터링 결과)가 발견 기준이 적용되는 리소스들(일치된 리소스 세트)과 다음의 관계 옵션들로 관련되는 방식을 수신자(404)에게 알린다.

o 자기: 발견된 리소스들은 일치된 리소스들과 동일하다.

o 부모: 발견된 리소스들은 일치된 리소스들의 부모들이다. 수신자(404)는 필터링 결과로부터 중복 부모 리소스들을 제거하기 위한 논리를 구현할 수 있다.

o 시맨틱스: 발견된 리소스들은 각각의 일치된 리소스들에 대한 시맨틱 정보를 포함하는 하위 리소스들이며, 예를 들어 oneM2M에서 <semanticDescriptor> 하위 리소스는 필터링 결과에서 회신될 것이다.

o 가입: 발견된 리소스들은 각각의 일치된 리소스들에 대한 가입 정보를 포함하는 하위 리소스들이며, 예를 들어 oneM2M에서 <subscription> 하위 리소스는 필터링 결과에서 회신될 것이다.

o 가장 최근의: 발견된 리소스들은 각각의 일치된 리소스의 가장 최근의 인스턴스들이다. 이것은 주어진 기준이 다중의 인스턴스화들을 유지하는 리소스들, 예를 들어 oneM2M에서 <container> 리소스들을 목표로 할 때 적용된다.

o 가장 오래된: 발견된 리소스들은 각각의 일치된 리소스의 가장 오래된 인스턴스들이다. 이 옵션은 기준이 다중의 인스턴스화들을 유지하는 리소스들, 예를 들어 oneM2M에서 <container> 리소스들에 적용될 때 유효하다.

모든 returnRelativeRelationship 값들에 대해, 리소스가 일치되지만 주어진 상대 관계를 가진 리소스가 발견되지 않으면, 그 결과는 일치하는 것이 발견되지 않은 것으로 취급된다.

oneM2M을 기반으로 한 예: <AE1> 리소스는 주어진 기준과 returnRelativeRelationship==Subscription에 기반하여 일치되지만, <AE1>은 <subscription> 하위 리소스들을 갖지 않는다. 이 경우, <AE1>이 제1 장소에서 주어진 기준과 일치하지 않는 것으로 취급되어 일치된 리소스 세트로부터 제거된다.

(새로운) formGroup: 필터링 프로세스의 결과들을 기반으로 그룹을 형성한다. 선택들은 MatchedResources, FilteredResources, OperationResult를 포함하지만 이에 국한되지는 않는다.

(새로운) groupID: formGroup이 있는 경우, groupID는 발신자(402)에 의해 표시될 수 있다. formGroup이 없으면, 이 파라미터는 무시된다.

예외 처리 표시들

각각의 동작은 디폴트 예외 처리를 갖지만, 발신자(402)는 향상된 예외 또는 조건부 처리를 지정할 수 있다. 예를 들어, 특정 <AE> 리소스(즉, AE1)가 이미 자식 <subscriptionX> 리소스, 즉 "subscriptionX"라는 이름의 <subscription> 유형의 자식 리소스를 가지고 있는 oneM2M 사례를 고려해 보자. 이러한 경우에, 발신자(402)가 "subscriptionX"라는 이름의 새로운 <subscription> 리소스를 생성하려고 할 때, 수신자(404)의 현재 행동은 발신자(402)가 제공한 이름을 변경하여 다른 자식 리소스, 예를 들어 <subscriptionAlt>를 생성하고 동작 결과로 새로운 이름을 회신하는 것일 수 있다.

본 발명자들은 발신자(402)가 ExceptionHandling = UpdateExistingName을 이용하여 가입 생성을 요청할 수 있다는 것을 제안한다. 이러한 경우에, 수신자(404)는 그 동작을 기존의 <subscriptionX> 자식 리소스에 대한 업데이트로서 해석하고 다른 것을 생성하지 않도록 강제된다. 수신자(404)는 먼저 주소지정된 리소스 <AE1>에서 발신자(402)의 생성 권한을 검증하고 업데이트될 리소스 <AE1/subscriptionX>에서 발신자(402)의 업데이트 권한을 검증할 것이다. 이러한 권한들이 그 동작을 허용하면, 제공된 콘텐츠로 <AE1/subscriptionX>의 업데이트를 실행할 것이다.

ExceptionHandling에 대한 가능한 선택들은 구현 요구들에 따라 확장될 수 있다. 예를 들어, 다른 값 "IgnoreExistingName"은 수신자(404)가 주어진 이름을 가진 자식 리소스의 존재를 무시하도록 요청하는데 이용될 수 있다. 따라서, 수신자(404)는 오래된 리소스를 삭제하고 이를 새로운 생성 동작의 콘텐츠로 대체하여야 한다.

대안들

위에 제시된 향상들은 대안적인 구현예들을 가질 수 있다.

기존의 파라미터들의 수정들: 새로운 기능을 반영하기 위해, 새로운 파라미터 FilterBase를 도입하는 대신에, To 파라미터의 이용을 추가로 수정할 수 있다. 간단한 비트 플래그(예를 들어, Eflag)는 향상된 동작을 표시하는데 이용될 수 있으며, To 필드는 이 경우 FilterBase 주소를 제공하기 위해 재이용된다. 이 경우, 상대 경로가 제공될 수 없으므로, 목표 리소스 세트는 이러한 구현예를 이용하는 모든 향상된 동작들에 대해 필터링된 결과와 동일한 것으로 기본적으로 간주될 수 있다. 대안적으로, returnRelativeRelationship과 유사한 필터링 지시가 이용될 수 있다. 예를 들어, targetRelativeRelationship 필터 지시는 값들의 유사한 선택들(예를 들어, 자기, 부모, 시맨틱스 등)과 함께 도입될 수 있다.

새로운 동작 유형들: 새로운 기능을 반영하기 위해, 새로운 RESTful 동작 유형들, 예를 들어 DiscCreate(발견 및 생성), DiscUpdate(발견 및 업데이트), DiscDelete(발견 및 삭제)이 생성될 수 있다. 마찬가지로, 정규 발견이 검색 동작을 이용하여 구현된다고 가정하면, 별도의 EnhDisc(향상된 발견) 동작은 검색 또는 정규 발견/필터링 기능을 이용한 검색과는 별도로 향상된 발견 동작을 반영하도록 생성될 수 있다.

새로운 동작 유형들은 요청 메시지의 Operation 파라미터에 대한 C, R, U, D 값들의 추가적인 선택들로서 구현될 수 있으며, 예를 들어 DiscC, DiscU, DiscD 및 EnhDisc가 유효한 동작 값들의 리스트에 추가될 수 있다. 위의 새로운 동작 유형들을 가정하면, FilterBase 파라미터는 향상된 기능에 대한 표시자로서 더 이상 필요하지 않을 수 있다. 이와 같이, FilterBase 및 To 파라미터들은 이전 섹션들에서 설명된 바와 같이 동작 유형에 기반하여 그 중요성이 조건부인 하나의 파라미터(예를 들어, To)로 축소될 수 있다.

새로운 동작들의 경우, 새로운 액세스 제어 정책들이 정의될 수 있거나, 수신자 기능이 다음 섹션들에서 상세히 설명되는 바와 같이 개별적인 동작들의 액세스 권한을 이용하도록 지정된다.

동작 절차들

도 9는 하나의 솔루션의 일반적인 향상된 동작들에 대한 콜 흐름을 도시하고 새로운 파라미터들에 기반하여 수신자(404) 처리를 상세히 설명한다. 도 10은 상세히 설명될 작업관리자 이용 사례에 대해 향상된 생성 동작을 이용하는 예시적인 콜 흐름을 도시한다. 도 10은 도 9의 일반적인 콜 흐름의 일 예를 도시한 것이다.

다음의 하위 섹션들은 oneM2M 이용 사례를 이용하여 추가적인 세부사항들을 제공하며, 작업관리자 애플리케이션은 주어진 섹터 및 유지보수 상태 기준을 충족하는 경우에만 등록된 AE들의 StatusContainer에 가입한다.

도 10의 예에서, 발신자(402)는 수신자(404)쪽으로 생성(C) 요청을 발행하지만, 주어진 기준을 평가함으로써 수신자(404)에 의해 먼저 발견될 리소스들에 대해 동작이 수행될 필요가 있다.

대응하는 처리는 다른 CRUD 동작들에도 또한 적용된다.

유사하게, 이 처리는 다른 유효 값들 및 파라미터들의 조합을 포함하도록 일반화될 수 있다. 추가적인 설명들이 또한 이하에서 제공된다.

도 10의 단계(0)에서, 전제 조건으로서, 발신자(402)는 동작이 수행될 리소스의 상대 주소를 알고 있다. 이는 이전의 발견 절차 또는 사전 구성을 통해 획득되었을 수 있다. 예를 들어, 작업관리자(AE_tm)(604)는 이전의 검색들에서 MN-CSE1(602)에서 발견 절차들을 수행하였고, 이에 따라 그 트리 구조, 특히 동작 상태 정보(이 경우, <AE> 리소스들의 자식 <statusContainer>)를 저장하는 것을 포함하여 장비(AE들)가 MN-CSE1(602)에 등록할 때 생성된 리소스들을 이해한다. MN-CSE1(602)은 보다 일반화된 용어들을 이용하는 절차들에서 호스팅 CSE뿐만 아니라 요청 메시지들의 수신자(404)의 일반적인 역할을 갖는다.

도 10의 단계(1)에서, 발신자(402)는 다음의 파라미터들을 포함하는 생성 요청을 발행한다.

· (새로운) FilterBase = FilterCSEBase

전체 CSEBase 트리가 본 발명자들의 이용 사례에 대해 검색될 것이라는 사실을 반영한다.

· FilterCriteria: (label=sector#42 및 label=maintenanceNotCurrent 및 returnRelativeRelationship=self).

본 발명자들의 이용 사례에 대한 리소스 일치 기준을 반영한다.

· Content: 모든 목표 리소스들의 자식 리소스로서 생성될 <subscription> 하위 리소스의 표현이다.

· (새로운) CompositeResult=OperationResult

본 발명자들의 이용 사례의 경우, 결과의 예상되는 구성요소들이 모든 생성된 리소스들이라는 것을 표시한다.

· (새로운) ExceptionHandling=NULL

본 발명자들의 이용 사례의 경우, 특별한 처리가 필요하지 않다.

· (수정된) To=.../StatusContainer

본 발명자들의 이용 사례의 경우, 향상된 동작 처리는 FilterBase의 존재에 의해 표시되므로, To 필드는 상대 경로일 수 있다. 수신자(404)는 .../StatusContainer를 필터링 결과에서의 리소스들의 주소들과 연관시켜 목표 리소스 세트에서의 리소스들의 주소들을 결정하도록 지시를 받는다.

수신자(404) 처리는 수신된 요청의 유형뿐만 아니라, 필터링 기준을 포함하여 요청에서 발신자(402)에 의해 제공된 모든 파라미터들의 콘텐츠들에 기반한다.

도 10의 단계(2)에서, 수신자(404)는 동작 요청을 수신하고 파라미터들을 체크한다. 하위 단계들(2a-2g)은 아래에서 설명된다.

도 10의 단계(2a)에서, 수신자(404)는 FilterBase에 기반하여 검색(즉, 발견) 기반 주소를 찾는다. 본 발명자들의 이용 사례에서는 /CSEBase이다. FilterBase가 존재하지 않는다면, 이것은 향상된 동작이 아니므로, 동작 목표의 존재를 검증하는 단계(D)로부터 진행한다.

도 10의 단계(2b)에서, 수신자(404)는 Filter Base/CSEBase로부터 시작하여 조건들(Filter Criteria)을 충족시키는 리소스들을 검색한다. 각각의 반복에서, 수신자(404)는 리소스 /AEk를 찾고, 여기서 k는 필터 기준과 일치하는 찾아진 AE 리소스들의 인덱스이며 각각의 반복 i마다 증분된다. 단순화를 위해, 찾아진 리소스들은 문서의 나머지 부분에서 AEk(k번째 일치 리소스에 대해 증분된 k)로 표시된다. 각각의 AEk 리소스는 일치된 리소스이다.

도 10의 단계(2c)에서, returnRelativeRelationship=self에 기반하여, 각각의 일치된 리소스는 필터링 결과에 추가될 후보가 된다. 수신자(404)는 AEk에서 발신자(402)의 발견 권한을 체크한 후 필터링 결과에 이 후보를 추가한다. ACP가 발견 동작을 허용하지 않는 경우, 대응하는 오류 코드가 생성된다.

현재의 검색 기반 발견에서, 검색 결과의 전체 트리 표현이 동작 결과에 대해 생성된다는데 유의한다. 본 명세서에서 설명되는 처리에서, 필터링 결과는 그 대신에 전체 트리 표현이 없이 단지 조건들을 충족시키는 리소스들의 리스트일 수 있다.

도 10의 단계(2d)에서, To:.../StatusContainer에 기반하여, 수신자(404)는 각각의 경로 /AEk/StatusContainer가 유효한지, 즉 필터링 결과의 자식 리소스에 대응하는지를 검증한다. 대응하지 않은 경우, 수신자(404)는 필터링 결과로부터 AEk를 폐기하고 대응하는 오류 코드를 생성한다.

도 10의 단계(2e)에서, ACP 및 /AEk/StatusContainer에서의 발신자(402) 생성 권한에 기반하여, 수신자(404)는 <subscription> 리소스의 /AEk/StatusContainer에 대해 생성 동작을 수행한다. 생성 동작이 허용되지 않으면, 대응하는 오류 코드가 생성된다.

도 10의 단계(2f)에서, 수신자(404)는 동작 요건들에 의해 지시된 바와 같이, 생성된 리소스의 일부 속성들에 대해 값들을 할당할 수 있다. 예를 들어, 이 동작은 수신자(404)가 새롭게 생성된 리소스에 대해 리소스 ID를 할당하거나 ParentID, 생성 시간 등과 같은 특정 속성들에 값들을 할당하는 것을 필요로 할 수 있다.

도 10의 단계(2g)에서, 수신자(404)는 이전 단계들에서의 개별적인 오류 코드들에 기반하여 합성 응답 코드를 생성한다. 수신자(404)는 또한 CompositeResult에 기반하여 응답의 콘텐츠를 모은다. 이 경우, CompositeResult=OperationResult이므로, 콘텐츠 필드는 생성된 <subscription> 리소스들을 포함할 것이다. 트리 검색이 샅샅이 이루어진 경우, 수신자(404)는 발신자(402)에게 보낼 응답을 생성한다.

formGroup 표시자(및 가능하게는 groupID)가 요청에 포함되면, 수신자(404)에서의 처리는 다음을 포함한다. 수신자(404)는 주어진 groupID(또는 자기 선택된 ID)를 가진 리소스 그룹을 형성하고, 각각의 검색 반복에서 새로운 멤버들을 추가할 것이다. 추가될 멤버들은 formGroup에 제공된 값(예를 들어, MatchedResources, ReturnedResources, OperationResult)에 의존한다. 이와 같이, 이 처리는 일치된 리소스 세트 또는 필터링 결과에 대해 새로운 유효 리소스가 찾아질 때마다 또는 동작 결과가 결정된 후에 단계들(B, C 또는 E)에서 통합될 수 있다.

도 10의 단계(3)에서, 발신자(402)는 응답 메시지를 수신하고 합성 응답 코드를 포함하여, 포함된 필수 및 임의적인 파라미터들을 처리한다. 요청 파라미터들에 기반하여, 발신자(402)에서의 추가 처리에 이용될 수 있는 모든 새롭게 생성된 리소스들의 리스트와 같은 추가 정보가 포함될 수 있다.

도 9 및 도 10에 도시된 단계들을 수행하는 엔티티들은 도 14c 또는 도 14d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 9 및 도 10에 도시된 방법(들)은 도 14c 또는 도 14d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 9 및 도 10에 도시된 단계들을 수행한다. 또한, 도 9 및 도 10에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.

oneM2M 실시예

다음의 섹션들은 전술한 새로운 파라미터들이 oneM2M 실시예들에 어떻게 적용될 수 있는지를 보여준다. 이후 섹션들에서는 그 결과의 기능, 처리 및 결과들에 대한 세부사항들과 함께 메시지들의 특정예들에 대해 설명한다.

이 섹션에서는 향상된 oneM2M 실시예를 위한 솔루션에 대해 설명한다.

표 4는 새롭게 도입된 파라미터(FilterBase, Composite Result 및 ExceptionHandling) 및 다른 파라미터들의 이용에서의 가능한 변경들과 함께 앞에서 상세히 설명한 oneM2M 요청 파라미터 리스트를 도시한다.

표 5는 FilterCriteria에 대해 새롭게 도입된 파라미터들과 함께 대응하는 oneM2M FilterCriteria 리스트를 도시한다.

두 표 모두에서는 또한 기존의 파라미터들의 이용에 도입될 수 있는 가능한 수정들 및 설명들에 대해 강조된다.

아래에 설명된 솔루션들의 경우에, FilterBase 파라미터의 존재는 향상된 기능의 표시자이다. 발견 기능은 oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0에 설명되어 있으며 발견을 위해 검색 동작을 이용해야 한다는 표시자로서 다른 파라미터, 즉 filterUsage를 이용한다. FilterBase의 존재는 기존의 검색 기반 발견 동작에 있어서도 FilterCriteria를 이용하기 위한 더 나은 표시자일 수 있다. 그러나, 어느 방법이든 이러한 목적으로 작동할 것이다.

<표 4>

<표 5>

이 섹션에서는 이전 섹션에서 제공된 oneM2M 실시예 및 파라미터 설명들을 이용하며 상이한 구성들에 기반한 이용 예들을 제공한다. 모든 가능한 순열들이 예시되지는 않았다.

다음의 예들에서, 전제 조건으로서, 발신자(402)는 일반적으로 이전의 발견 절차에 기반하여 To 파라미터에서 이용될 상대 경로를 알고 있다. 이는 발신자(402)가 특정 발견 및 CRUD 동작들을 여러 번 수행한 많은 이용 사례들에서 이러한 향상된 동작들을 이용하는 것과 대응하므로 리소스 트리 구조에 대한 사전 지식이 있다.

이 경우, 필터링 요청은 리소스 트리 구조를 발견하기 보다는 리소스들에 포함된 정보를 기반으로 검색 역할을 수행한다. 향상된 RESTful 동작들은 기존의 CRUD 동작들 또는 리소스 트리 구조 발견 기능을 대체하기 위한 것이 아니라 이를 보완하기 위한 것이다.

도 11은 일반적인 요청 및 응답 흐름을 도시한다. 각각의 경우에 특정된 파라미터 값들은 각각의 섹션들에서 상세히 설명한다.

예 1: 2개의 계층적 레벨에서 속성 조건들을 충족시키기 위해 찾아진 모든 리소스들에 대한 하위 리소스를 생성한다.

기능: 속성 appName==myApp를 가진 AE들의 자식인 모든 더 새로운 컨테이너들(시간 "myDate" 이후에 생성된 컨테이너들)에 대한 가입을 생성한다.

많은 사례들에서, 상이한 디바이스들에 있는 디바이스 애플리케이션들(AE들)은 동일한 appName 속성을 이용하여 등록한다. 동일한 CSE에 등록된 모든 디바이스들로부터의 특정 서비스에 관심이 있는 이용자는 발견 및 가입 생성을 함께 수행하면서 이러한 서비스들에 의해 생성된 모든 더 새로운 컨테이너들에 가입할 수 있다.

예 1에 대한 도 11의 단계(1)에서, 다음의 요청 형식을 이용하여 요청이 보내진다.

To: CSEBase

Operation: CREATE (C)

FilterBase: FilterCSEBase

Filter Criteria:

resourceType==<container>, createdAfter==myDate,

parentResourceType==<AE>, parentAttribute appName==myApp

returnRelativeRelationship==Self

Content: <subscription>

ResultContent: hierarchical-address+attributes

CompositeResult: OperationResult

ExceptionHandling: NULL

예 1에 대한 도 11의 단계(2)에서, 처리는 하위 단계들(2a-2g)로 수행된다.

예 1에 대한 도 11의 단계(2a)에서, 호스팅 CSE는 검색 기반 FilterBase, 즉 CSEBase를 찾는다.

예 1에 대한 도 11의 단계(2b)에서, 호스팅 CSE는 검색 기반 CSEBase로부터 시작하여 조건들(resourceType==<container>, createdAfter==myDate, parentResourceType==<AE>, parentAttribute appName=myApp)을 충족시키는 모든 리소스들을 검색한다. 호스팅 CSE는 일치된 리소스로서 CSEBase/AEk/containerX를 찾는다.

예 1에 대한 도 11의 단계(2c)에서, returnRelativeRelationship==Self에 기반하여, 동일한 리소스는 ACP 및 발신자(402) 발견 권한에 따라 필터링 결과에 추가될 후보이다. 발신자(402)는 CSEBase/AEk/containerX에 대한 발견 권한을 갖는다고 가정한다.

예 1에 대한 도 11의 단계(2d)에서, 상대 경로가 아닌 To 주소에 기반하여, 목표 리소스 세트는 필터링 결과와 동일하다. 호스팅 CSE는 경로 CSEBase/AEk/containerX가 목표 리소스 세트에서의 각각의 리소스에 대해 유효한지를 검증한다.

예 1에 대한 도 11의 단계(2e)에서, ACP 및 CSEBase/AEk/containerX에서의 발신자(402) 생성 권한에 기반하여, 호스팅 CSE는 <subscription> 리소스의 생성 동작을 수행한다. 발신자(402)는 생성 권한을 갖는다고 가정한다. ExceptionHandling: NULL에 기반하여, RESTful 동작에 대한 특별한 처리가 필요하지 않다.

예 1에 대한 도 11의 단계(2f)에서, 호스팅 CSE는 정규 동작 요건들에 의해 지시된 바와 같이, 생성된 리소스의 일부 속성들에 대해 값들을 할당할 수 있다.

예 1에 대한 도 11의 단계(2g)에서, 호스팅 CSE는 합성 응답 코드 및 응답 콘텐츠를 생성한다. CompositeResult, 즉 OperationResult 및 ResultContent: hierarchical-address+attributes에 기반하여, 결과 콘텐츠는 생성된 모든 가입 리소스들의 주소들, 즉 SEBase/AEk/containerX/subscription 및 그 속성들을 포함할 것이다.

예 2: 각각의 일치된 리소스의 특정 자식에 대한 하위 리소스를 생성하고, 2개의 계층적 상대 레벨(부모 및 자식)에서 필터들에 기반하여 일치시킨다.

기능: 많은 플랫폼들/센서들로부터의 온도 판독들을 위한 컨테이너를 형성하는 애플리케이션(AE1)이 주어지므로, 여러 중첩 및 병렬 컨테이너들이 포함될 수 있다. ZigBee 온도 센서 온톨로지를 가리키는 컨테이너의 ontologyRef에 의해 설명된 대로 ZigBee 온도 정보를 가진 컨테이너들을 저장하는 모든 측정을 찾는다. 그 다음, 시맨틱 설명 변경들을 모니터링하기 위해 필터링 결과의 시맨틱 설명 리소스에 대한 가입을 생성한다. 생성된 가입 리소스들의 계층적 주소들을 회신한다.

예 2에 대한 도 11의 단계(1)에서, 다음의 요청 형식을 이용하여 요청이 보내진다.

To: CSEBase

Operation: CREATE (C)

FilterBase: /CSEBase/AE1

Filter Criteria:

parentType==<container>, resourceType==<container>,

attribute ontologyRef==http://[ZigBeeOntology]#TemperatureSensor

returnRelativeRelationship==Semantics

Content: <subscription>

ResultContent: hierarchical-address

CompositeResult: OperationResult

ExceptionHandling: NULL

예 2에 대한 도 11의 단계(2)에서, 처리의 하위 단계들(2a-2g)이 수행된다.

예 2에 대한 도 11의 단계(2a)에서, 호스팅 CSE는 검색 기반, 즉 FilterBase=/CSEBase/AE1을 찾는다.

예 2에 대한 도 11의 단계(2b)에서, 호스팅 CSE는 검색 기반 /CSEBase/AE1로부터 시작하여 조건들(parentType==<container>, resourceType==<container>, attribute ontologyRef==http://[ZigBeeOntology]#TemperatureSensor)을 충족시키는 모든 리소스들을 검색하고, 모든 일치하는 컨테이너들을 찾을 것이며, 즉 (/CSEBase/AE1에 기반한 트리에서의 다양한 레벨들에 있을 수 있는) 모든 .../containerK 일치를 찾는다.

예 2에 대한 도 11의 단계(2c)에서, returnRelativeRelationship==Semantics에 기반하여, .../containerK/semanticDescriptor 리소스는 ACP 및 발신자(402) 발견 권한에 따라 필터링 결과에 추가될 후보이다. 발신자(402)는 발견 권한을 갖는다고 가정한다.

예 2에 대한 도 11의 단계(2d)에서, 상대 경로가 아닌 To 주소에 기반하여, 목표 리소스 세트는 필터링 결과와 동일하다. 호스팅 CSE는 .../containerK/semanticDescriptor로의 경로가 목표 리소스 세트에서의 각각의 결과에 대해 유효한지를 검증한다.

예 2에 대한 도 11의 단계(2e)에서, ACP 및 .../containerK/semanticDescriptor에서의 발신자(402) 생성 권한에 기반하여, 호스팅 CSE는 <subscription> 리소스의 생성 동작을 수행한다. 발신자(402)는 생성 권한을 갖는다고 가정한다.

예 2에 대한 도 11의 단계(2f)에서, 호스팅 CSE는 정규 동작 요건들에 의해 지시된 바와 같이, 생성된 리소스의 일부 속성들에 대해 값들을 할당할 수 있다.

예 2에 대한 도 11의 단계(2g)에서, 호스팅 CSE는 합성 응답 코드 및 응답 콘텐츠를 생성한다. CompositeResult, 즉 OperationResult 및 ResultContent: hierarchical-address에 기반하여, 결과 콘텐츠는 생성된 모든 가입 리소스들의 주소들, 즉 .../containerK/semanticDescriptor/subscription을 속성들 없이 포함할 것이다.

예 3: 필터링 결과에서의 리소스들과 주어진 관계를 가진 모든 리소스들에 대한 속성을 업데이트한다.

기능: 위치 컨테이너들이 최근에 업데이트된(즉, 시간 "myTime" 이후의) 모든 디바이스들(AE들)을 찾고, 그 다음 tempMeasurement 리소스들만의 향후의 필터링을 위해 이러한 모든 AE들에 존재하는 것으로 알려진 tempMeasurement 컨테이너의 라벨을 업데이트한다. 이 기능은 새롭게 업데이트된 위치들을 갖는 디바이스들을 효과적으로 발견함과 동시에 향후의 쉬운 식별을 위해 측정 컨테이너들이 쉽게 발견될 수 있도록 라벨링한다.

예 3에 대한 도 11의 단계(1)에서, 다음의 요청 형식을 이용하여 요청이 보내진다.

To: .../tempMeasurement

Operation: UPDATE (U)

FilterBase: FilterCSEBase

Filter Criteria:

parentResourceType==<AE>, resourceType==<container>,

resourceName==locationContainer, modifiedSince==myTime

returnRelativeRelationship==Parent

Content: labels=tempSensorMoved

ResultContent: nothing

CompositeResult: OperationResult

ExceptionHandling: NULL

예 3에 대한 도 11의 단계(2)에서, 처리의 하위 단계들(2a-2g)이 수행된다.

예 3에 대한 도 11의 단계(2a)에서, 호스팅 CSE는 검색 기반 FilterBase=CSEBase를 찾는다.

예 3에 대한 도 11의 단계(2b)에서, 호스팅 CSE는 검색 기반 CSEBase로부터 시작하여 조건들(parentResourceType==<AE>, resourceType==<container>, resourceName==locationContainer, modifiedSince==myTime)을 충족시키는 모든 리소스들을 검색한다.

호스팅 CSE는 일치된 리소스들: CSEBase/AEk/locationContainer로서 대응하는 locationContainer 컨테이너들을 찾을 것이다.

returnRelativeRelationship==Parent를 기반으로, 각각의 CSEBase/AEk는 필터링 결과의 후보가 된다.

예 3에 대한 도 11의 단계(2c)에서, 각각의 반복에 대해, ACP 및 CSEBase/AEk에서의 발신자(402) 발견 권한에 따라, 호스팅 CSE는 이 리소스를 필터링 결과에 추가한다. 발신자(402)는 발견 권한을 갖는다고 가정한다.

예 3에 대한 도 11의 단계(2d)에서, To==.../tempMeasurement에 기반하여, 호스팅 CSE는 업데이트 동작의 목표 리소스 세트를 형성하므로, 이 세트는 모든 CSEBase/AEk/tempMeasurement 리소스들로 구성될 것이다.

호스팅 CSE는 경로 CSEBase/AEk/tempMeasurement가 목표 리소스 세트에서의 각각의 리소스에 대해 유효한지를 검증한다.

예 3에 대한 도 11의 단계(2e)에서, ACP 및 Base/AEk/locationContainer에서의 발신자(402) 업데이트 권한에 기반하여, 호스팅 CSE는 라벨 속성을 업데이트하여(즉, "tempSensorMoved"를 추가하여) CSEBase/AEk/tempMeasurement 리소스의 업데이트 동작을 수행한다. 발신자(402)는 업데이트 권한을 갖는다고 가정한다.

예 3에 대한 도 11의 단계(2f)에서, 호스팅 CSE는 정규 동작 요건들에 의해 지시된 바와 같이, 업데이트된 리소스의 일부 속성들에 대해 값들을 할당할 수 있다.

예 3에 대한 도 11의 단계(2g)에서, 호스팅 CSE는 합성 응답 코드 및 응답 콘텐츠를 생성한다. CompositeResult, 즉 OperationResult 및 ResultContent, 즉 Nothing에 기반하여, 응답과 함께 어떠한 콘텐츠도 되돌려 보내지지 않는다.

예 4: 3개의 계층적 레벨에서 조건들을 충족시키도록 찾아진 일치들에 대한 리소스 인스턴스를 삭제한다.

기능: 특정 목적지에 가입들이 있는 <container> 리소스들을 가진 모든 AE들을 찾고, 그 다음 tempMeasurement 컨테이너의 가장 최근의 <contentInstance>를 삭제한다.

이는 통지들에 대한 가입자가 특정 조건이 발생하였음을 인지할 수 있고(예를 들어, 가장 최근의 측정이 무효인 것으로 알려짐), 하나의 동작을 이용하여 모든 관련 리소스들을 발견하고 가장 최근의 결과들을 삭제할 수 있는 사례일 수 있다.

예 4에 대한 도 11의 단계(1)에서, 다음의 요청 형식을 이용하여 요청이 보내진다.

To: CSEBase

Operation: DELETE (D)

FilterBase: FilterCSEBase

Filter Criteria:

resourceType==<container>, resourceName==tempMeasurement,

childResourceType==<subscription>,

childAttribute notificationURI==myURI

parentResourceType==<AE>

returnRelativeRelationship==Latest

Content: N/A

ResultContent: N/A

CompositeResult: Nothing

ExceptionHandling: NULL

예 4에 대한 도 11의 단계(2)에서, 처리의 하위 단계들(2a-2g)이 수행된다.

예 4에 대한 도 11의 단계(2a)에서, 호스팅 CSE는 검색 기반, 즉 FilterBase=CSEBase를 찾는다.

예 4에 대한 도 11의 단계(2b)에서, 호스팅 CSE는 검색 기반 CSEBase로부터 시작하여 조건들(resourceType==<container>, resourceName==tempMeasurement, childResourceType==<subscription>, childAttribute notificationURI==myURI, parentResourceType==<AE>)을 충족시키는 모든 리소스들을 검색하므로, 가입에서 대응하는 속성을 가진 모든 컨테이너들을 찾을 것이며, 즉 일치된 리소스들로서 모든 CSEBase/AEk/tempMeasurement를 찾는다. returnRelativeRelationship==Latest를 기반으로, 각각의 CSEBase/AEk/tempMeasurement의 가장 최근의 <contentInstance>가 필터링 결과의 후보이다.

예 4에 대한 도 11의 단계(2c)에서, 각각의 반복에 대해, ACP 및 CSEBase/AEk/tempMeasurement/latest에서의 발신자(402) 발견 권한에 따라, 호스팅 CSE는 이 리소스를 필터링 결과에 추가한다. 발신자(402)는 발견 권한을 갖는다고 가정한다.

예 4에 대한 도 11의 단계(2d)에서, To==CSEBase를 기반으로, 호스팅 CSE는 삭제 동작의 목표 리소스 세트를 필터링 결과와 동일하게 설정한다. 또한, 호스팅 CSE는 경로 CSEBase/AEk/tempMeasurement/latest가 목표 리소스 세트에서의 각각의 리소스에 대해 유효한지를 검증한다.

예 4에 대한 도 11의 단계(2e)에서, ACP 및 CSEBase/AEk/tempMeasurement/latest에서의 발신자(402) 삭제 권한을 기반으로, 호스팅 CSE는 가장 최근의 <contentInstance> 리소스의 삭제 동작을 수행한다. 발신자(402)는 삭제 권한을 갖는다고 가정한다.

예 4에 대한 도 11의 단계(2f)에서, 호스팅 CSE는 합성 응답 코드를 생성한다. CompositeResult==Nothing을 기반으로, 응답에 어떠한 콘텐츠도 포함될 필요가 없다. 트리 검색이 샅샅이 이루어진 경우, 호스팅 CSE는 발신자(402)에 대한 응답을 생성한다.

oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0에서, 가상 리소스 <container>/latest를 목표로 하는 동작은 <container> 리소스의 <contentInstance> 자식의 가장 최근의 인스턴스화에 적용된다. 따라서, 이 예에서는, <contentInstance> 리소스에 대해 CSEBase/AEk/tempMeasurement/latest에 대한 동작이 실행된다.

예 5: exceptionHandling을 이용하여 필터링 결과에서의 리소스들과 관련된 리소스들을 선택적으로 생성하거나 업데이트하고 향후에 이용할 그룹을 생성한다.

기능: 최근에 업데이트된(즉, 시간 "myTime" 이후의) 위치 컨테이너들을 가진 모든 디바이스들(AE들)을 찾고, 그 다음에 특정 컨테이너에 대한 가입을 생성하거나 업데이트한다. 일치된 리소스들의 그룹이 가능한 향후의 이용을 위해 형성된다.

이 기능은 새롭게 업데이트된 위치들을 가진 디바이스들을 발견하고 새로운 통지 목표로 가입들을 업데이트하거나 새로운 가입들을 생성하는데 이용될 수 있다. 동시에, 이 기능은 향후의 이용을 위해, 예를 들어 그룹으로 모두에 대해 향후의 위치 업데이트들을 요청하기 위해 locationContainer 하위 리소스들의 그룹을 형성한다.

예 5에 대한 도 11의 단계(1)에서, 다음의 요청 형식을 이용하여 요청이 보내진다.

To: .../tempMeasurement

Operation: CREATE (C)

FilterBase: FilterCSEBase

Filter Criteria:

parentResourceType==<AE>, resourceType==<container>,

resourceName==locationContainer, modifiedSince==myTime

returnRelativeRelationship==Parent

formGroup==MatchedResources

groupID: 35

Content: <mySubscription>

ResultContent: nothing

CompositeResult: OperationResult

ExceptionHandling: UpdateExistingName

유의: 현재의 oneM2M 생성 절차는 수신자(404)에서의 처리에 대한 oneM2M-TS-0001, oneM2M 기능 아키텍처 V2.1.0 섹션 10.1.1.1에 명시된다.

"생성 요청 메시지에서 발신자(402)가 제공한 경우, 콘텐츠 파라미터에서의 resourceName 속성으로 제안된 대로 생성된 리소스의 이름이 목표 리소스의 자식 리소스들 사이에 이미 존재하지 않는지를 검증한다. 목표 리소스 내에서 발신자(402)가 제안한 것과 동일한 resourceName을 가진 자식이 없으면, 생성될 리소스에 그 이름을 이용한다. 자식이 이미 resourceName을 이용하면, 수신자(404)는 새로운 이름을 할당하고, 이 새로운 이름은 발신자(402)에게 회신되어야 한다. 이름이 발신자(402)에 의해 제안되지 않으면, 수신자(404)에 의해 생성된 이름을 생성될 리소스에 할당한다".

ExceptionHandling: UpdateExistingName을 이용하여, 수신자(404)는 다음과 같이 이 디폴트 행동을 수정하도록 지시를 받을 수 있다.

ExceptionHandling이 UpdateExistingName을 표시하며 자식이 이미 resourceName을 이용하면, 수신자(404)는 새로운 이름을 생성하지 않고 새로운 리소스를 생성하지 않는다. 그 대신에, 수신자(404)는 주어진 콘텐츠를 이용하여 기존의 자식 리소스에 대한 업데이트 동작을 실행하는 것으로 진행한다. ExceptionHandling이 NULL이거나 비어 있으면, 디폴트 처리가 발생한다.

예 5에 대한 도 11의 단계(2)에서, 처리의 하위 단계들(2a-2g)이 수행된다.

예 5에 대한 도 11의 단계(2a)에서, 호스팅 CSE는 검색 기반 FilterBase=CSEBase를 찾는다.

예 5에 대한 도 11의 단계(2b)에서, 호스팅 CSE는 검색 기반 CSEBase로부터 시작하여 조건들(parentResourceType==<AE>, resourceType==<container>, resourceName==locationContainer, modifiedSince==myTime)을 충족시키는 모든 리소스들을 검색한다.

호스팅 CSE는 일치된 리소스들: CSEBase/AEk/locationContainer로서 대응하는 locationContainer 컨테이너들을 찾을 것이다.

formGroup==MatchedResources 및 groupID: 35를 기반으로, 호스팅 CSE는 groupID가 35인 그룹을 형성하고 찾아진 각각의 CSEBase/AEk/locationContainer 일치된 리소스를 그 그룹에 추가한다.

returnRelativeRelationship==Parent를 기반으로, 각각의 CSEBase/AEk는 필터링 결과의 후보가 된다.

예 5에 대한 도 11의 단계(2c)에서, 각각의 반복에 대해, ACP 및 CSEBase/AEk에서의 발신자(402) 생성 권한에 기반하여, 호스팅 CSE는 이 리소스를 필터링 결과에 추가한다. 발신자(402)는 발견 권한을 갖는다고 가정한다.

예 5에 대한 도 11의 단계(2d)에서, To==.../tempMeasurement에 기반하여, 호스팅 CSE는 생성 동작이 CSEBase/AEk/tempMeasurement에 대해 수행될 필요가 있다는 것을 알고 있다.

호스팅 CSE는 경로 CSEBase/AEk/tempMeasurement가 목표 리소스 세트에서의 각각의 리소스에 대해 유효한지를 검증한다.

예 5에 대한 도 11의 단계(2e)에서, ACP 및 CSEBase/AEk/tempMeasurement에서의 발신자(402) 생성 권한에 기반하여, 호스팅 CSE는 <mySubscription> 리소스의 생성 동작을 수행한다. 발신자(402)는 업데이트 권한을 갖는다고 가정한다.

ExceptionHandling: UpdateExistingName에 기반하여, <mySubscription>이라는 이름의 가입 리소스가 존재하면, 호스팅 CSE는 기존의 <mySubscription> 리소스를 업데이트한다.

예 5에 대한 도 11의 단계(2f)에서, 호스팅 CSE는 정규 동작 요건들에 의해 지시된 바와 같이, 업데이트된 리소스의 일부 속성들에 값들을 할당할 수 있다.

예 5에 대한 도 11의 단계(2g)에서, 호스팅 CSE는 합성 응답 코드 및 응답 콘텐츠를 생성한다. CompositeResult, 즉 OperationResult 및 ResultContent, 즉 Nothing에 기반하여, 응답과 함께 어떠한 콘텐츠도 되돌려 보내지지 않는다.

도 12a 및 도 12b는 예시적인 요청 처리 흐름도를 도시한다.

도 11 및 도 12에 도시된 단계들을 수행하는 엔티티들은 도 14c 또는 도 14d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리 엔티티들인 것으로 이해된다. 즉, 도 11 및 도 12에 도시된 방법(들)은 도 14c 또는 도 14d에 도시된 노드와 같은 네트워크 노드 또는 컴퓨터 시스템의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은, 노드의 프로세서에 의해 실행될 때, 도 11 및 도 12에 도시된 단계들을 수행한다. 또한, 도 11 및 도 12에 도시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 노드의 통신 회로, 및 노드가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있는 것으로 이해된다.

oneM2M 실시예에 대한 대안들

이 섹션에서는 전술한 oneM2M 실시예에 대한 대안적인 솔루션에 대해 설명한다. 먼저, 본 발명자들은 요청 파라미터들에 대한 대안들을 제시하고 필터 기준에 대한 몇몇 대안들을 제시한다.

이 섹션에서, 전술한 새로운 속성들 중 일부는 시작점과 동일한 oneM2M 요청 형식을 이용하면서 몇 가지 상이한 필드들/파라미터들을 이용하여 구현된다. 구현예가 상이하지만, 해결된 문제와 이용 사례는 동일하다.

다중의 논리 중첩된 필터 기준

기존의 파라미터들의 이용에 도입될 수 있는 가능한 수정들 및 설명들과 함께 이 솔루션의 새로운 파라미터들이 표 6에서 강조되어 있다. 이 예에서는, 요청에서 둘 이상이 유사하게 작동할 세 개의 상이한 필터 기준 파라미터를 이용하는 예를 보여주고 있다.

<표 6>

다중의 중첩된 필터 기준이 이용될 때, 호스팅 CSE는 다음과 같이 도 11에서의 흐름의 단계(0002)를 수행한다.

If (Filter Criteria 1 exists)

{

Hosting CSE searches starting from the search base FilterBase for all resources meeting FilterCriteria 1, forms Filtering Result 1

If (Filter Criteria 2 exists)

{

Hosting CSE searches starting from Filtering Result 1 for all resources meeting FilterCriteria 2, forms Filtering Result 2

If (Filter Criteria 3 exists)

{

Hosting CSE searches starting from Filtering Result 2 for all resources meeting FilterCriteria 3, forms Filtering Result 3 == final filtering Result

}

}

}

상이한 계층 레벨들에서 적용되는 다중의 필터 기준

기존의 파라미터들의 이용에 도입될 수 있는 가능한 수정들 및 설명들과 함께 이 솔루션의 새로운 파라미터들이 표 7에서 강조되어 있다. 이 예에서는, 요청에서 둘 이상이 유사하게 작동할 세 개의 상이한 필터 기준 파라미터를 이용하는 예를 보여주고 있다.

<표 7>

다중 레벨의 필터 기준이 이용될 때, 호스팅 CSE는 다음과 같이 도 11에서의 흐름의 단계(0002)를 수행한다.

If (BaseFilterCriteria NOT NULL)

{

Hosting CSE searches starting from the search base FilterBase

While (Resource X meets BaseFilterCriteria)

{

If ((ChildFilterCriteria NOT NULL) AND (child Y of resource X meets ChildFilterCriteria))

OR (ChildFilterCriteria == NULL)

{

If ((ParentFilterCriteria NOT NULL) AND (Parent Z of resource X meets ParentFilterCriteria))

OR (ParentFilterCriteria == NULL)

{

Resource X = matchCandidate

Hosting CSE adds Resource X to Filtering Result

}

}

} do search through the tree

}

추가적인 필터 기준 검색 파라미터들

표 8의 파라미터들은 위에서 논의된 파라미터들에 추가하여 이용될 수 있다.

<표 8>

이용자 인터페이스

그래픽 이용자 인터페이스들(GUI들)과 같은 인터페이스들은 이용자가 향상된 RESTful 동작들과 관련된 기능들을 제어 및/또는 구성하도록 돕는데 이용될 수 있다. 도 13은 인터페이스(1302)를 도시하는 도면이다. 향상된 RESTful 동작들은 이용자 또는 애플리케이션에 의해 인에이블링되어 통신 효율성을 향상시킬 수 있으며, 표 4, 표 5, 표 6, 표 7 및 표 8에 나열된 파라미터들 중 일부는 또한 인터페이스(1302)에 도시된 바와 같이 디폴트 값들로 이용자 또는 애플리케이션에 의해 사전 구성될 수 있다. 인터페이스(1302)는 이하에서 설명되는 도 14c 및 도 14d에 도시된 것들과 같은 디스플레이들을 이용하여 생성될 수 있다는 것을 이해해야 한다.

예시적인 M2M/IoT/WoT 통신 시스템

본 명세서에 설명되는 다양한 기술들은 하드웨어, 펌웨어, 소프트웨어 또는, 적합한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치되는 장치들에 상주할 수 있다. 이러한 장치들은 본 명세서에 설명되는 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 이용되는 용어들 "장치", "네트워크 장치", "노드", "디바이스" 및 "네트워크 노드"는 교체가능하게 이용될 수 있다.

서비스 계층은 네트워크 서비스 아키텍처 내의 기능 계층일 수 있다. 서비스 계층들은 통상적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 있으며 클라이언트 애플리케이션들에 부가가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어 제어 계층 및 전송/액세스 계층과 같은 더 하위의 리소스 계층에서 코어 네트워크들에 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 런타임 인에이블먼트, 정책 관리, 액세스 제어 및 서비스 클러스터링을 포함하는 다수 카테고리들의(서비스) 능력들 또는 기능들을 지원한다. 최근에, 수 개의 산업 표준 기관들, 예를 들어 oneM2M은 M2M 유형들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업 및 홈 네트워크들과 같은 전개들에 통합하는 것과 관련된 도전들을 해결하기 위해 M2M 서비스 계층들을 개발해 왔다. M2M 서비스 계층은 애플리케이션들 및/또는 다양한 디바이스들에게, CSE 또는 SCL이라고 지칭될 수 있는, 서비스 계층에 의해 지원되는, 앞서 언급된 능력들 또는 기능들의 모음 또는 세트에 대한 액세스를 제공할 수 있다. 몇몇 예들은, 이에 제한되는 것은 아니지만, 다양한 애플리케이션들에 의해 흔히 이용될 수 있는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속 관리를 포함한다. 이러한 능력들 또는 기능들은 M2M 서비스 계층에 의해 정의되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 이용하는 API들을 통해 이러한 다양한 애플리케이션들에 이용가능하게 된다. CSE 또는 SCL은, 하드웨어 및/또는 소프트웨어로 구현될 수 있으며 다양한 애플리케이션들 및/또는 디바이스들에 노출되어 이들이 이러한 능력들 또는 기능들을 이용하게 하는(서비스) 능력들 또는 기능들(즉, 이러한 기능 엔티티들 간의 기능 인터페이스들)을 제공하는 기능 엔티티이다.

도 14a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M, 사물 인터넷(IoT) 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구성 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT는 물론 IoT/WoT 서비스 계층 등의 구성요소 또는 노드일 수 있다. 통신 시스템(10)은, 개시된 실시예들의 기능을 구현하는데 이용될 수 있으며, 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들 및 기능을 포함할 수 있다.

도 14a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예를 들어, 이더넷, 파이버, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등)일 수 있거나 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다중의 이용자들에게 제공하는 다중의 액세스 네트워크들로 이루어져 있을 수 있다. 예를 들어, 통신 네트워크(12)는 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 융합형 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 14a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 종단간 M2M 전개의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들을 지칭한다. 필드 도메인 및 인프라스트럭처 도메인 둘 다는 각종의 상이한 네트워크 노드들(예컨대, 서버들, 게이트웨이들, 디바이스 등)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 대로 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은, 통신 회로를 이용하여, 통신 네트워크(12) 또는 직접 무선 연결을 통해 신호들을 전송 및 수신하도록 구성되어 있다. M2M 게이트웨이(14)는 무선 M2M 디바이스들(예컨대, 셀룰러 및 비셀룰러)은 물론 고정 네트워크 M2M 디바이스들(예컨대, PLC)이 통신 네트워크(12)와 같은 오퍼레이터 네트워크들 또는 직접 무선 연결 중 어느 하나를 통해 통신할 수 있게 한다. 예를 들어, M2M 단말 디바이스들(18)은 데이터를 수집할 수 있고, 데이터를 통신 네트워크(12) 또는 직접 무선 연결을 통해 M2M 애플리케이션(20) 또는 다른 M2M 디바이스들(18)에 보낼 수 있다. M2M 단말 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 단말 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하 설명되는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 보내질 수 있고 그로부터 수신될 수 있다. M2M 단말 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어 셀룰러, WLAN, WPAN(예컨대, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 연결, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

예시적인 M2M 단말 디바이스들(18)은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카(connected car)들, 스마트 미터(smart meter)들, 게임 콘솔들, PDA들, 건강 및 피트니스 모니터들, 전등들, 서모스탯들, 가전기기들, 차고문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 아웃렛들을 포함하지만, 이들로 제한되지는 않는다.

도 14b를 참조하면, 필드 도메인에서의 예시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 및 통신 네트워크(12)에 서비스들을 제공한다. 통신 네트워크(12)는, 개시된 실시예들의 기능을 구현하는데 이용될 수 있으며, 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들 및 기능을 포함할 수 있다. M2M 서비스 계층(22)은 예를 들어, 이하 설명되는 도 14c 및 도 14d에 도시된 디바이스들을 포함하는, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예를 들어, 클라우드/스토리지 팜 등) 등에 의해 구현될 수 있다. M2M 서비스 계층(22)이 원하는 대로 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들(14), M2M 단말 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 것을 잘 알 것이다. M2M 서비스 계층(22)은 서버들, 컴퓨터들, 디바이스들 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 단말 디바이스들(18), M2M 게이트웨이들(14), 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은 다양한 방식들로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서 등으로 구현될 수 있다.

도시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인에서 M2M 애플리케이션(20') 및 하위 통신 네트워크(12)에 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인 내의 M2M 게이트웨이들(14) 및 M2M 단말 디바이스들(18)에 서비스들을 제공한다. M2M 서비스 계층(22')이 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들 및 M2M 디바이스들과 통신할 수 있다는 점을 이해할 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의한 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/스토리지 팜들 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.

또한 도 14b를 참조하면, M2M 서비스 계층들(22 및 22')은 다양한 애플리케이션들 및 버티클들이 활용할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용할 수 있게 하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 빌링, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이러한 서비스 능력들은 이러한 기능들을 구현하는 애플리케이션들의 부담을 없애고, 따라서 애플리케이션 개발을 단순화하고 마케팅 비용 및 시간을 감소시킨다. 서비스 계층들(22 및 22')은 또한 M2M 애플리케이션들(20 및 20')이 서비스 계층들(22 및 22')이 제공하는 서비스들과 관련하여 네트워크들(12)을 통해 통신할 수 있게 한다.

본 출원의 방법들은 서비스 계층(22 및 22')의 일부로서 구현될 수 있다. 서비스 계층(22 및 22')은 애플리케이션 프로그래밍 인터페이스들(APIs) 및 하위 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. ETSI M2M과 oneM2M 둘 다는 본 출원의 접속 방법들을 포함할 수 있는 서비스 계층을 이용한다. ETSI M2M의 서비스 계층은 SCL이라고 지칭된다. 이러한 SCL은 M2M 디바이스(DSCL(device SCL)이라고 지칭됨), 게이트웨이(GSCL(gateway SCL)이라고 지칭됨) 및/또는 네트워크 노드(NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는, 상이한 유형들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 CSE라고 지칭된다. 게다가, 본 출원의 접속 방법들은 본 출원의 접속 방법들과 같은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

일부 실시예들에서, M2M 애플리케이션들(20 및 20')은 개시된 시스템들 및 방법들과 함께 이용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 또한 다른 개시된 시스템들 및 방법들과 관련하여 이용될 수 있다.

일 실시예에서, 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들은 도 14b에 도시된 바와 같이 M2M 서버, M2M 게이트웨이 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅되는 M2M 서비스 계층 인스턴스 내에 호스팅될 수 있다. 예를 들어, 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들은 M2M 서비스 계층 인스턴스 내에서 또는 기존의 서비스 능력 내의 하위 기능으로서 개별적인 서비스 능력을 포함할 수 있다.

본 개시 내용의 주제의 바람직한 실시예들을 설명함에 있어서, 도면들에 도시된 바와 같이, 특정한 용어가 명료성을 위해 이용된다. 그러나, 청구되는 주제는 그와 같이 선택되는 특정한 용어로 제한되는 것으로 의도되지 않으며, 각각의 특정한 요소는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 것을 이해해야 한다.

M2M 애플리케이션들(20 및 20')은 운송, 건강 및 웰빙(health and wellness), 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 보안 및 감시(이들로 제한되지 않음)와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 앞서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들 및 다른 노드들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에게 제공한다.

일반적으로, 서비스 계층들(22 및 22')은 API들 및 하위 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M 아키텍처와 oneM2M 아키텍처 둘 다는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 각종의 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(DSCL이라고 지칭됨), 게이트웨이(GSCL이라고 지칭됨), 및/또는 네트워크 노드(NSCL이라고 지칭됨) 내에서 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는, 상이한 유형들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 CSE라고 지칭된다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)에 대한 아키텍처도 정의하였다. 그 아키텍처에서, 서비스 계층과, 서비스 계층이 제공하는 서비스 능력들이 서비스 능력 서버(Service Capability Server: SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)에, oneM2M 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는, 네트워크 내의 하나 이상의 독립형 노드 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능한 명령어들 등)로서 또는 하나 이상의 기존의 노드의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 구성요소의 인스턴스는 이하에 설명되는 도 14c 또는 도 14d에 도시된 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

또한, 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들은 본 출원의 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 14c는 M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버 등과 같은 M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 노드(30)는 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들을 실행하거나 포함할 수 있다. 디바이스(30)는 도 14a 및 도 14b에 도시된 바와 같은 M2M 네트워크의 일부 또는 비M2M 네트워크의 일부일 수 있다. 도 14c에 도시된 바와 같이, M2M 노드(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시자들(42), 전원(48), 글로벌 포지셔닝 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. M2M 노드(30)가 일 실시예와 일치한 채로 있으면서 전술한 요소들의 임의의 하위 조합을 포함할 수 있다는 것을 잘 알 것이다. 이 노드는 본 명세서에서 설명되는 SMSF 기능을 구현하는 노드일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 통상의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit), 상태 머신과 관련되는 하나 이상의 마이크로프로세서 등일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 필수 기능들을 수행하기 위해 노드의 메모리(예컨대, 메모리(44) 및/또는 메모리(46))에 저장된 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입출력 처리, 및/또는 M2M 노드(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 애플리케이션 계층 프로그램들(예컨대, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 다른 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 또한, 예를 들어, 액세스 계층 및/또는 애플리케이션 계층 등에서 인증, 보안 키일치(security key agreement), 및/또는 암호 동작들과 같은 보안 동작들을 수행할 수 있다.

도 14c에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 송수신기(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)로 하여금 그에 접속되어 있는 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 상세하게는, 프로세서(32)는 본 명세서 및 청구항들에 설명된 전송 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 14c가 프로세서(32)와 송수신기(34)를 별도의 구성요소들로서 도시하고 있지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.

전송/수신 요소(36)는 M2M 서버들, 게이트웨이들, 디바이스 등을 포함하는, 다른 M2M 노드들에게 신호들을 전송하거나 그들로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 전송/수신 요소(36)는 RF 신호들을 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 일 실시예에서, 전송/수신 요소(36)는, 예를 들어, IR, UV 또는 가시 광 신호들을 전송 및/또는 수신하도록 구성된 이미터/검출기일 수 있다. 또 다른 실시예에서, 전송/수신 요소(36)는 RF 및 광 신호들 둘 다를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 점이 이해될 것이다.

또한, 전송/수신 요소(36)가 단일 요소로서 도 14c에 도시되지만, M2M 노드(30)는 임의의 수의 전송/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로는, M2M 노드(30)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, M2M 노드(30)는 무선 신호들을 전송 및 수신하기 위한 2개 이상의 전송/수신 요소들(36)(예컨대, 다중의 안테나들)을 포함할 수 있다.

송수신기(34)는 전송/수신 요소(36)에 의해 전송될 신호들을 변조하고 전송/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, M2M 노드(30)는 다중 모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는 M2M 노드(30)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 다중의 RAT들을 통해 통신할 수 있게 하기 위한 다중의 송수신기들을 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적합한 메모리로부터의 정보에 액세스하거나 그 메모리에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는, 전술한 바와 같이, 세션 컨텍스트(session context)를 그 메모리에 저장할 수 있다. 비이동식 메모리(44)는 RAM, ROM, 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터와 같은, M2M 노드(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 그 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 M2M 서비스 계층 세션 마이그레이션 또는 공유의 상태를 반영하기 위해 또는 이용자로부터 입력을 획득하거나 노드의 세션 마이그레이션 또는 공유 능력들 또는 설정들에 관한 정보를 이용자에게 표시하기 위해 디스플레이 또는 표시자들(42) 상에서의 조명 패턴들, 이미지들, 또는 색상들을 제어하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관한 정보를 보여줄 수 있다. 본 개시 내용은 oneM2M 실시예에서 RESTful 이용자/애플리케이션 API를 정의한다. 디스플레이 상에 보여질 수 있는 그래픽 이용자 인터페이스는 이용자가, 본 명세서에서 설명되는 하위 서비스 계층 세션 기능을 통해, E2E 세션 또는 그 마이그레이션 또는 공유를 상호작용적으로 설정 및 관리할 수 있게 하기 위해 API 위에 계층화될 수 있다.

프로세서(32)는 전원(48)으로부터 전력을 받을 수 있고, M2M 노드(30) 내의 다른 구성요소들에게 전력을 분배 및/또는 제어하도록 구성될 수 있다. 전원(48)은 M2M 노드(30)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양광 전지, 연료 전지 등을 포함할 수 있다.

프로세서(32)는 또한 M2M 노드(30)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성되어 있는 GPS 칩셋(50)에 결합될 수 있다. M2M 노드(30)가 일 실시예와 일치한 채로 있으면서 임의의 적합한 위치 결정 방법을 통해 위치 정보를 획득할 수 있다는 것을 잘 알 것이다.

프로세서(32)는 추가적인 특징들, 기능, 및/또는 유선 또는 무선 접속을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변기기들(52)에 또한 결합될 수 있다. 예를 들어, 주변기기들(52)은 가속도계, 생체측정(예컨대, 지문) 센서들, 전자 나침반(e-compass)과 같은 다양한 센서들, 위성 송수신기,(사진 또는 비디오용의) 디지털 카메라, USB 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

노드(30)는, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 운송 수단과 같은 다른 장치들 또는 디바이스들에서 구현될 수 있다. 노드(30)는, 주변기기들(52) 중 하나를 포함할 수 있는 상호접속 인터페이스와 같은, 하나 이상의 상호접속 인터페이스를 통해 이러한 장치들 또는 디바이스들의 다른 구성요소들, 모듈들, 또는 시스템들에 접속할 수 있다. 대안적으로, 노드(30)는, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 운송 수단과 같은 장치들 또는 디바이스들을 포함할 수 있다.

도 14d는, M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드와 같은, M2M 네트워크의 하나 이상의 노드를 구현하는데 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 어딘가의 소프트웨어의 형태일 수 있는 컴퓨터 판독가능한 명령어들에 의하거나 그 소프트웨어가 저장되거나 액세스되는 어떠한 수단에 의해서도 주로 제어될 수 있다. 컴퓨팅 시스템(90)은 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(90)은, 예를 들어, M2M 디바이스, 이용자 장비, 게이트웨이, UE/GW 또는 모바일 코어 네트워크의 노드들을 포함하는 임의의 다른 노드들, 서비스 계층 네트워크 애플리케이션 제공자, 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)일 수 있다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 동작을 수행하게 하기 위해, 중앙 처리 유닛(CPU)(91)과 같은 프로세서 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 지칭되는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다중의 프로세서들을 포함할 수 있다. 코프로세서(81)는, 추가적 기능들을 수행하거나 CPU(91)를 보조하는, 주 CPU(91)와는 별개인, 임의의 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 세션 자격증명들을 수신하는 것 또는 세션 자격증명들에 기반하여 인증하는 것과 같은, E2E M2M 서비스 계층 세션들에 대한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

동작에 있어서, CPU(91)는 명령어들을 페치, 디코딩 및 실행하고, 컴퓨터의 주 데이터 전송 경로인 시스템 버스(80)를 통해 다른 리소스들에 정보를 전송하고 다른 리소스들로부터의 정보를 전송한다. 이러한 시스템 버스는 컴퓨팅 시스템(90)에 있는 구성요소들을 접속시키고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 데이터를 보내기 위한 데이터 라인들, 주소들을 보내기 위한 주소 라인들, 및 인터럽트들을 보내고 시스템 버스를 동작시키기 위한 제어 라인들을 통상적으로 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.

시스템 버스(80)에 결합된 메모리들은 RAM(82) 및 ROM(93)을 포함한다. 이러한 메모리들은 정보가 저장되고 검색되게 하는 회로를 포함한다. ROM들(93)은 쉽게 수정될 수 없는 저장된 데이터를 일반적으로 포함한다. RAM(82)에 저장되는 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독되거나 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 주소들을 물리 주소들로 변환하는 주소 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 시스템 내의 프로세스들을 격리하고 시스템 프로세스들을 이용자 프로세스들로부터 격리하는 메모리 보호 기능을 또한 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 주소 공간에 의해 매핑되는 메모리에만 액세스할 수 있으며, 프로세스들 사이의 메모리 공유가 설정되지 않는다면 다른 프로세스의 가상 주소 공간 내의 메모리에 액세스할 수 없다.

또한, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변기기들로 명령어들을 통신하는 것을 담당하는 주변기기 제어기(83)를 포함할 수 있다.

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 표시하는데 이용된다. 이러한 시각적 출력은 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 보내지는 비디오 신호를 생성하는데 필요한 전자 구성요소들을 포함한다.

또한, 컴퓨팅 시스템(90)은 도 14a 및 도 14b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속시켜, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하는데 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.

이용자 장비(UE)는 통신하기 위해 최종 이용자에 의해 이용되는 임의의 디바이스일 수 있다. 이용자 장비(UE)는 핸드헬드 전화기, 모바일 광대역 어댑터가 장착된 랩톱 컴퓨터, 또는 임의의 다른 디바이스일 수 있다. 예를 들어, UE는 도 14a 및 도 14b의 M2M 단말 디바이스(18) 또는 도 14c의 디바이스(30)로서 구현될 수 있다.

본 명세서에서 설명되는 시스템들, 방법들 및 프로세스들 중 일부 또는 전부가 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있고, 이 명령어들이, 예를 들어, M2M 서버, 게이트웨이, 디바이스 등을 포함하는 M2M 네트워크의 노드와 같은 머신에 의해 실행될 때, 본 명세서에서 설명되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다는 것을 알 것이다. 구체적으로, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크의 노드들, 서비스 계층 또는 네트워크 애플리케이션 제공자 중 임의의 것의 동작들을 포함하는, 전술한 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 발신자(402), 수신자(404), 수신자 CSE(404'), AE_tm(604), MN-CSE1(602)과 같은 논리 엔티티들과 인터페이스(1302)와 같은 인터페이스들을 생성하기 위한 논리 엔티티들은 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는 정보의 저장을 위해 임의의 비일시적(즉, 유형적 또는 물리적) 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 둘 다를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체가 신호들은 포함하지 않는다. 컴퓨터 판독가능한 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 디스크 저장소, 자기 카세트, 자기 테이프, 자기 디스크 저장소 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 유형적 또는 물리적 매체를 포함하지만, 이들로 제한되지 않는다.

이 기재된 설명은 최상의 모드를 포함하는 본 발명을 개시하기 위해, 또한 관련 기술분야에서의 임의의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작하고 이용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 하기 위해 예들을 이용한다. 본 발명의 특허가능한 범주는 청구항들에 의해 한정되고, 관련 기술분야에서의 통상의 기술자에게 안출되는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 본 청구항들의 문언적 표현과 상이하지 않은 요소들을 가지는 경우, 또는 청구항들의 문언적 표현과 그다지 차이를 갖지 않는 등가의 요소들을 포함하는 경우, 본 청구항들의 범주 내에 속하는 것으로 의도된다.

Claims (24)

1. 프로세서 및 메모리를 포함하는 장치로서,
   상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며,
   상기 컴퓨터 실행가능한 명령어들은, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
   관련된 필터 기준을 갖는 리소스 발견 동작을 표시하고 또한 관련된 동작 파라미터들을 갖는 RESTful 동작을 표시하는 요청을 보내게 하고 - 상기 리소스 발견 동작은 상기 관련된 필터 기준과 일치하는 하나 이상의 리소스를 포함하는 결과 리소스 세트에 대한 요청을 포함하고, 상기 RESTful 동작은 상기 결과 리소스 세트와 관련된 하나 이상의 리소스를 포함하는 목표 리소스 세트에 대해 상기 관련된 동작 파라미터들에 따라 수행되어야 함 -,
   상기 RESTful 동작이 수행되었다는 것을 표시하는 응답을 수신하게 하는 장치.
2. 제1항에 있어서,
   상기 목표 리소스 세트는 상기 결과 리소스 세트와 동일하며, 상기 RESTful 동작은 상기 리소스 발견 동작에 기인하는 상기 결과 리소스 세트에 대해 수행되는 장치.
3. 제1항에 있어서,
   상기 요청은 또한 상기 관련된 필터 기준과 일치하는 상기 결과 리소스 세트로부터의 그룹의 생성을 표시하는 장치.
4. 제1항에 있어서,
   상기 요청은 상기 RESTful 동작이 상기 리소스 발견 동작의 상기 결과 리소스 세트와 관련되어 있지만 상이한 목표 리소스 세트에 대해 수행되어야 한다는 것을 표시하는 장치.
5. 제1항에 있어서,
   상기 요청은 상기 목표 리소스 세트에 포함되지 않은 리소스에 대해 상기 리소스 발견 동작을 수행하기 위한 루트 리소스를 더 포함하는 장치.
6. 프로세서 및 메모리를 포함하는 장치로서,
   상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며,
   상기 컴퓨터 실행가능한 명령어들은, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
   관련된 필터 기준을 갖는 리소스 발견 동작을 표시하고 또한 관련된 동작 파라미터들을 갖는 RESTful 동작을 표시하는 요청을 수신하게 하고 - 상기 리소스 발견 동작은 상기 관련된 필터 기준과 일치하는 하나 이상의 리소스를 포함하는 결과 리소스 세트에 대한 요청을 포함하고, 상기 RESTful 동작은 상기 결과 리소스 세트와 관련된 하나 이상의 리소스를 포함하는 목표 리소스 세트에 대해 상기 관련된 동작 파라미터들에 따라 수행되어야 함 -,
   상기 요청에 의해 표시된 대로 상기 결과 리소스 세트를 결정하게 하고,
   상기 요청에 의해 표시된 대로 상기 목표 리소스 세트를 결정하게 하며,
   상기 요청에 의해 표시된 대로 상기 목표 리소스 세트에 대해 상기 RESTful 동작을 수행하게 하는 장치.
7. 제6항에 있어서,
   상기 목표 리소스 세트는 상기 결과 리소스 세트와 동일하며, 상기 RESTful 동작은 상기 리소스 발견 동작에 기인하는 상기 결과 리소스 세트에 대해 수행되는 장치.
8. 제6항에 있어서,
   상기 장치는 상기 RESTful 동작이 수행되었다는 것을 표시하는 응답을 보내는 장치.
9. 제6항에 있어서,
   상기 요청은 또한 상기 관련된 필터 기준과 일치하는 상기 결과 리소스 세트로부터의 그룹의 생성을 표시하는 장치.
10. 제6항에 있어서,
    상기 요청은 상기 RESTful 동작이 상기 리소스 발견 동작의 상기 결과 리소스 세트와 관련되어 있지만 상이한 목표 리소스 세트에 대해 수행되어야 한다는 것을 표시하는 장치.
11. 제6항에 있어서,
    상기 요청은 상기 목표 리소스 세트에 포함되지 않은 리소스에 대해 상기 리소스 발견 동작을 수행하기 위한 루트 리소스를 더 포함하는 장치.
12. 제6항에 있어서,
    상기 요청은 리소스들 간의 관계 유형을 표시하는 리소스 관계 파라미터를 더 포함하며, 상기 목표 리소스 세트는 상기 리소스 관계 파라미터에 의해 표시된 상기 관계 유형에 의해 상기 결과 리소스 세트의 하나 이상의 리소스와 관련된 하나 이상의 리소스를 포함하는 장치.
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 프로세서 및 메모리를 포함하는 장치로서,
    상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며,
    상기 컴퓨터 실행가능한 명령어들은, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금,
    관련된 필터 기준을 갖는 리소스 발견 동작을 표시하고 또한 리소스 관계 파라미터를 표시하는 요청을 보내게 하고 - 상기 리소스 발견 동작은 상기 관련된 필터 기준과 일치하는 하나 이상의 리소스를 포함하는 결과 리소스 세트에 대한 요청을 포함하며, 상기 리소스 관계 파라미터는 리소스들 간의 관계 유형을 표시함 -,
    상기 리소스 관계 파라미터에 의해 표시된 상기 관계 유형에 의해 상기 결과 리소스 세트의 하나 이상의 리소스와 관련된 하나 이상의 리소스를 포함하는 결과 리소스 세트를 표시하는 응답을 수신하게 하는 장치.
20. 제19항에 있어서,
    상기 요청은 결과 리소스 세트에 기반한 그룹의 생성을 표시하는 장치.
21. 제12항에 있어서,
    상기 리소스 관계 파라미터는 부모 관계 유형을 표시하는 장치.
22. 제12항에 있어서,
    상기 리소스 관계 파라미터는 시맨틱 관계 유형을 표시하며, 제1 리소스와 제2 리소스 간의 시맨틱 관계 유형은 상기 제2 리소스에 대한 시맨틱 정보를 포함하는 상기 제1 리소스를 포함하는 장치.
23. 제12항에 있어서,
    상기 리소스 관계 파라미터는 가입 관계 유형을 표시하며, 제1 리소스와 제2 리소스 간의 가입 관계 유형은 상기 제2 리소스에 대한 가입 정보를 포함하는 상기 제1 리소스를 포함하는 장치.
24. 제19항에 있어서,
    상기 리소스 관계 파라미터는 부모 관계 유형을 표시하는 장치.

Images