KR102116401B1

KR102116401B1 - M2m 서비스 계층에 대한 교차 리소스 가입

Info

Publication number: KR102116401B1
Application number: KR1020187016667A
Authority: KR
Inventors: 총강 왕; 로꼬 디 지롤라모; 홍군 리; 칭 리; 쉬 리; 카탈리나 엠. 믈라딘
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2015-11-16
Filing date: 2016-11-15
Publication date: 2020-05-29
Also published as: EP3378217B1; EP3378217A1; US11012839B2; JP2018535605A; CN108353094B; CN108353094A; US20210227367A1; US11711682B2; WO2017087367A1; US20230319534A1; US20200288291A1; JP6892445B2; KR20180082555A

Abstract

가입자는 리소스 호스트에게 메시지를 발행하여 복수의 리소스들에 대한 가입을 요청한다. 이 메시지는 이러한 리소스들의 식별자들, 각각의 개별 리소스에 대한 이벤트 통지 기준들을 표시할 수 있으며, 시간 윈도우 유형 및 시간 윈도우 크기와 같은 교차 리소스 통지 기준들을 정의할 수 있다. 리소스 호스트는 타겟 리소스들에 대한 예상된 변경들이 시간 윈도우 내에서 발생할 때 가입자 또는 그 지정된 통지 타겟들에게 교차 리소스 통지들을 발행한다.

Description

M2M 서비스 계층에 대한 교차 리소스 가입

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

본 출원은 "Cross-Resource Subscription For M2M Service Layer"이라는 명칭으로 2015년 11월 16일에 출원된 미국 가특허 출원 제62/255,649호의 이득을 주장하며, 그 내용은 본 명세서에 참조로서 포함된다.

서비스 계층

도 1은 서비스 계층(100)을 지원하는 예시적인 프로토콜 스택을 도시한다. 도 1에 도시된 바와 같이, 프로토콜 스택의 관점에서, 서비스 계층(100)은 애플리케이션 프로토콜 계층 위에 위치할 수 있고, 애플리케이션들 또는 다른 서비스 계층에 부가 가치 서비스들을 제공할 수 있다. 따라서, 서비스 계층들은 종종 "미들웨어" 서비스들로 분류된다. 예를 들어, 도 1은 IP 네트워크 스택과 애플리케이션들 사이의 예시적인 서비스 계층을 보여준다.

M2M 서비스 계층은 M2M 유형의 디바이스들 및 애플리케이션들에 부가 가치 서비스들을 제공하는 것을 구체적인 목표로 하는 한 가지 유형의 서비스 계층의 예이다. 최근에는, 몇몇 산업 표준 기관들(예를 들어, oneM2M-TS-0001, oneM2M 기능 아키텍처 V-2.3.0(이하 oneM2M))은 M2M 유형의 디바이스들 및 M2M 유형의 애플리케이션들을 인터넷/웹, 셀룰러, 기업 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전들을 해결하기 위해 M2M 서비스 계층들을 개발하여 왔다.

M2M 서비스 계층은 애플리케이션들 및 디바이스들에게 서비스 계층에 의해 지원되는 M2M 지향 능력들의 수집에 대한 액세스를 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝 및 접속성 관리를 포함한다. 이러한 능력들은 M2M 서비스 계층에 의해 정의되는 바와 같은 메시지 포맷들, 리소스 구조들, 리소스 표현들 및 기능 호출들을 사용하는 API들(Application Programming Interfaces)을 통해 애플리케이션들에 사용가능하게 된다. 예를 들어, M2M 서비스 계층은 그 액세스 권한들에 기반하여 M2M 애플리케이션들에 의해 검색되거나 이들에 가입될 수 있는 많은 양의 M2M 데이터를 유지할 수 있다. 가입 기반 데이터 액세스(subscription-based data access)는 가입된 리소스에 대한 원하는 변경들이 발생할 때까지 M2M 애플리케이션에 메시지를 도입하지 않으므로 검색 기반 데이터 액세스보다 더 효율적일 수 있다.

oneM2M 서비스 계층 아키텍처

oneM2M은 다양한 하드웨어 및 소프트웨어 내에 용이하게 내장될 수 있고, 관련분야에서의 매우 다양한 디바이스들을 전세계의 M2M 애플리케이션 서버들과 접속시키는데 의존될 수 있는 공통 M2M 서비스 계층에 대한 필요성을 해결하는 기술 사양들을 제공한다.

oneM2M 공통 서비스 계층은, 도 2에 도시된 바와 같이, CSF들(Common Service Functions)(예를 들어, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, IN(infrastructure node), MN(middle node) 및 ASN(application-service node)) 상에서 호스팅될 수 있는 CSE(Common Services Entity)로서 지칭된다. CSF들은 애플리케이션 엔티티들(AE들) 또는 다른 CSE들에게 서비스들의 세트를 제공한다.

도 3은 oneM2M 기능 아키텍처, 리소스 지향 아키텍처(ROA)를 도시한다. ROA 아키텍처에서, 리소스는, 생성, 검색, 업데이트 및 삭제와 같은 RESTful 메소드들을 통해 조작될 수 있는 표현을 갖는 아키텍처에서의 고유하게 주소지정가능한 엘리먼트이다. 이러한 리소스들은 URI들(Uniform Resource Identifiers)을 사용하여 주소지정가능하게 된다. 리소스는 또한 고유하게 주소지정가능할 수 있는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 그 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 "속성들"의 세트를 지원한다.

CSE(예를 들어, CSE(109))는 다른 CSE(예를 들어, CSE(111))에 등록할 수 있다. 예를 들어, M2M 게이트웨이(예를 들어, MN-CSE/CSE(109))는 자신을 M2M 서버(예를 들어, IN-CSE/CSE(111))에 등록하고, M2M 서버는 M2M 게이트웨이의 등록자 CSE가 된다. 마찬가지로, IN-AE가 IN-CSE에 등록할 때, IN-CSE는 IN-AE의 등록자 CSE라고 지칭된다. CSE(111)는 등록된 AE(103) 또는 AE(118)에 대한 <application> 리소스를 생성할 수 있다.

도 3에서, 애플리케이션 엔티티(AE)(101) 및 AE(118) 또는 AE(117) 및 AE(103)는 인프라스트럭처 도메인(107) 또는 필드 도메인(105)에 각각 존재할 수 있는 상이한 M2M 애플리케이션들을 지칭한다. 필드 도메인(107)은 oneM2M-TS-0011-Definitions and Acronyms-V0.7.0에 따라 "M2M 디바이스들, M2M 게이트웨이들, S&A(Sensing and Actuation) 장비 및 M2M 영역 네트워크들로 구성"되는 반면에, 인프라스트럭처 도메인(105)은 "애플리케이션 인프라스트럭처 및 M2M 서비스 인프라스트럭처로 구성"된다. AE(101)는 Mca 인터페이스(108)를 통해 CSE(109)에서의 CSF들에 액세스하여 이들을 활용할 수 있다. 또한, CSE(109)는 CSF들의 모음을 제공하고, CSE(109)는 Mcc 인터페이스(110)를 통해 다른 CSE(111)와 통신할 수 있다. CSE(109)는 또한 Mcn 인터페이스(112)를 통해 하위 네트워크들로부터 네트워크 서비스 엔티티(NSE)(113)를 활용할 수 있다.

oneM2M 기능 아키텍처 베이스라인에 따르면, oneM2M 기준점들은 Mca(108), Mcc(110), Mcc'(114) 및 Mcn(112)을 포함한다. Mca 기준점(108)(Mca 인터페이스로도 알려짐)은 AE(예를 들어, AE(101))와 CSE(예를 들어, CSE(109)) 간의 통신 흐름들을 지정한다. Mca 기준점(108)은 AE(101)가 CSE(109)에 의해 제공되는 서비스들을 사용하고, CSE(109)가 AE(101)와 통신하도록 허용한다. Mcc 기준점(110)은 2개의 CSE(예를 들어, CSE(109) 및 CSE(111)) 간의 통신 흐름들을 지정한다. Mcc 기준점(110)은 CSE(109)가 필요한 기능을 제공하기 위해 CSE(111)의 서비스들을 사용하도록 허용한다. Mcc 기준점(110)을 통해 제공되는 서비스들은 CSE(109) 및 CSE(111)에 의해 지원되는 기능에 의존한다.

Mcc' 기준점(114)은 oneM2M을 따르고 상이한 M2M SP 도메인들에 존재하는 인프라스트럭처 노드들 내의 2개의 CSE 간의 통신 흐름들을 지정한다. 따라서, 이는 M2M 서비스 제공자의 네트워크 도메인에 존재하는 인프라스트럭처 노드(105)의 CSE(111)가 다른 M2M 서비스 제공자(115)의 네트워크 도메인에 존재하는 다른 인프라스트럭처 노드(도시되지 않음)의 CSE와 통신하여 그 서비스들을 사용하게 하고, 그 반대의 경우도 마찬가지이다. Mcn 기준점(112)은 CSE(109)와 하위 NSE(113) 간의 통신 흐름들을 지정한다. Mcn 기준점(112)은 CSE(109)가 필요한 기능을 제공하기 위해 하위 NSE(113)에 의해 제공되는 서비스들(전송 및 접속 서비스들 이외)을 사용하도록 허용한다.

등록(REG) CSF, 애플리케이션 및 서비스 계층 관리(ASM) CSF, 디바이스 관리(DM) CSF, 데이터 관리 및 저장소(DMR) CSF, 통신 및 메시지 전달 처리(CMDH) CSF, 서비스 과금 및 회계(SCA) CSF 등을 포함하는 약간의 CSF들이 oneM2M 기능 아키텍처 베이스라인에서 정의되었다. 예를 들어, CSE(예를 들어, M2M 서버)는 CSE에 의해 제공되는 다른 CSF들을 활용하기 위해 AE가 먼저 자신을 CSE에 등록할 수 있도록 REG CSF를 제공한다. 이 아키텍처는 복수의 AE들이 동일한 CSE와 독립적으로 등록하도록 허용한다. 등록이 성공한 후에, CSE는 각각의 AE에 대해 별도의 리소스(예를 들어, <application> 리소스)를 생성한다. 종래의 oneM2M 기능 아키텍처 베이스라인은 상이한 애플리케이션들 간의 관계를 지원하기 위한 기능들이 부족하다.

oneM2M 가입 및 통지 CSF

oneM2M 기능 아키텍처는 M2M 서버와 같은 CSE에 의해 다른 CSE들 또는 AE들에 제공될 수 있는 CSF들의 세트를 정의한다. 정의된 CSF들 중 하나는 리소스 상의 변경들(예를 들어, 리소스의 삭제)을 추적하는 가입에 관한 통지들을 제공하는 SUB(Subscription and Notification)이다.

SUB CSF는, 액세스 제어 정책들(ACP들)에 따라, 리소스들에 대한 가입들을 관리하고, 대응하는 통지들을 리소스 가입자들이 이들을 수신하길 원하는 주소(들)에 보낸다. oneM2M에 따르면, ACP들은 oneM2M ROA 아키텍처에서 지정된 대로 리소스들에 대한 액세스를 제어하기 위해 CSE에 의해 사용되어야 한다. ACP는 액세스 제어 리스트들, 역할 기반 액세스 제어 또는 속성 기반 액세스 제어와 같은 상이한 액세스 제어 모델들에 맞게 설계된다. <accessControlPolicy> 리소스는 어떤 M2M 엔티티들이 지정된 컨텍스트들 내에서 특정한 동작들을 수행할 권한을 갖는지를 정의하고, 특정한 리소스들에 대한 액세스를 결정하는데 CSE들에 의해 사용되는 액세스 제어 규칙들의 세트를 나타내는 권한들 및 selfPrivileges 속성들을 포함하는 다양한 ACP들을 지원하도록 지정된다. AE 또는 CSE는 가입 리소스 가입자이다. AE들 및 CSE들은 다른 CSE들의 리소스들에 가입한다. 가입 호스팅 CSE는 리소스에 대한 수정들이 이루어질 때 리소스 가입자에 의해 지정되는 주소(들)에 통지들을 보낸다. 리소스 가입의 범위는 가입된 리소스의 속성(들) 및 직계 자식 리소스(들)의 변경들 및 동작들을 추적하는 것을 포함한다. 이것은 자식 리소스(들)의 속성(들)의 변경을 추적하는 것을 포함하지 않는다. 각각의 가입은 어떠한 통지들이 언제 그리고 어떻게 보내지는지를 지정하는 통지 기준들을 포함할 수 있다. 이러한 통지 기준들은 oneM2M의 통신 관리 및 전달 처리(CMDH) 정책들과 함께 작동할 수 있다.

가입은 CSE 리소스 구조에서 리소스 <subscription>으로 표현된다.

SUB CSF에 의해 지원되는 기능들은 다음과 같다.

· 리소스 가입자 ID, 호스팅 CSE-ID 및 리소스 가입 요청마다의 가입된 리소스 주소(들)를 포함한다. 이것은 다른 기준들(예를 들어, 관심 리소스 수정 및 통지 정책) 및 통지들을 보낼 주소(들)를 또한 포함할 수 있다.

· 단일 가입을 통해 단일 리소스에 가입하거나 그룹화되어 단일 그룹 리소스로 표현될 때 단일 가입을 통해 복수의 리소스들에 가입할 수 있는 능력이다. 가입자가 리소스들의 그룹에 가입할 때, 그룹의 모든 리소스들에 동일한 이벤트 통지 기준들이 사용되며, 차례로, 호스팅 CSE는 개별(모든 리소스가 아닌) 리소스에 대한 변경들이 발생할 때마다 통지를 생성할 수 있다.

oneM2M에서, 가입자들은 AE(들) 또는 CSE(들)일 수 있으며, 호스팅 노드(들) 또는 중계 노드(들)는 CSE(들)이어야 한다. 예를 들어, 가입자로서의 IN-AE는 IN-CSE(즉, 호스팅 노드)에 의해 호스팅되는 리소스들에 가입할 수 있다. 다른 예에서, MN-CSE는 가입자로서의 IN-AE가 가입하기를 원하는 일부 리소스들을 갖지만, IN-AE의 가입 요청은 그 IN-CSE(즉, 중계 노드)를 통해 MN-CSE에 도달해야 한다.

도 4는 가입자(132)(예를 들어, IN-AE)가 호스팅 CSE(131) 상의 리소스(예를 들어, IN-CSE/<subscribed-to-resource>)에 가입하는 oneM2M 사양에 따른 예시적인 절차를 도시한다. 이를 수행하기 위해, 단계(134)에서, 가입자(132)는 CREATE 요청을 발행하여 <subscribed-to-resource> 아래에 <subscription> 리소스를 생성한다. 가입자(132)는 단계(134)에서 eventNotificationCriteria 및 복수의 notificationURI들을 표시할 수 있다. eventNotificationCriteria는 가입자(132)가 <subscribed-to-resource>에 관한 어떤 이벤트들에 관심이 있는지를 나타낸다. 통지는 notificationURI(예를 들어, 이 예에서 가입자(132)에 대한 notificationURI1 및 통지 타겟(133)에 대한 notificationURI2, 다른 통지 타겟)에 의해 표시된 대로 가입자(132) 또는 통지 타겟에 보내질 수 있다. 단계(135)에서, 호스팅 CSE로서 호스팅 CSE(131)는 단계(134)에서 가입 요청을 수신한 후에 <subscribed-to-resource>의 하위 리소스로서 <subscription>을 초기에 생성한다. 단계(136)에서, 호스팅 CSE(131)는 단계(134)의 가입 요청의 성공 또는 실패를 표시할 수 있는 가입 응답을 제공할 수 있다. 단계(137)에서, eventNotificationCriteria(예를 들어, 단계(134)에서 제공된 기준들)를 충족시키는 이벤트가 발생한다. 이어서, 이벤트가 발생하고 eventNotificationCriteria를 충족시킬 때, 단계(138 및 139)에서 호스팅 CSE(131)는 각각의 notificationURI에 의해 표시된 가입자(132) 및 통지 타겟(133)에 2개의 통지 각각을 자동으로 보낸다. 통지 타겟(133)은 단계(134)에서 notificationURI가 그 URI를 포함하면 가입자 자체일 수 있다. 또한, 단계(134)의 가입 요청은 복수의 notificationURI들을 포함할 수 있으며, 이는 가입자(132)가 미래의 통지들이 복수의 통지 타겟들에 보내지도록 요청하고 있다는 것을 의미한다. 이 경우, eventNotificationCriteria는 동일하며 모든 notificationURI들에 적용된다. 도 4에는 도시되지 않았지만, oneM2M은 pendingNotification(sendAllPending)이 사용될 때 배치(batch) 통지들을 수행하는 호스팅 CSE(131)를 지원한다. 호스팅 CSE(131)는 하나의 메시지 내의 동일한 notificationURI에 복수의 통지들을 보낼 수 있다.

M2M/IoT 도메인에서, 가입은 가입자가 리소스들 상의 변화들에 대한 자동 통지를 수신하는 메커니즘을 제공한다. 종래의 M2M 서비스 계층(예를 들어, oneM2M)은 각각의 요청 프리미티브에 대한 단일 리소스에 대한 가입(단일 리소스 가입이라고 지칭됨)을 지원한다. 그러나, 관심 있는 복수의 리소스들(교차 리소스 가입이라고 지칭됨)에 대한 변경들이 발생할 때 통지들을 생성하는 것을 지원하지 않는다. 단일 요청으로 복수의 리소스들(예를 들어, 타겟 리소스들)에 대한 가입을 지원하는 것이 더 효율적일 수 있다. 이 문제를 해결하기 위해, 본 개시내용은 교차 리소스 가입을 지원하기 위한 메커니즘들을 개시한다.

일례로서, 가입자는 복수의 리소스들에 대한 가입을 요청하기 위해 리소스 호스트에게 메시지를 발행한다. 리소스 호스트는 이러한 리소스들 모두가 로컬로 유지되게 한다. 이 메시지는 이러한 리소스들의 식별자들, 각각의 개별 리소스에 대한 이벤트 통지 기준들을 표시할 수 있으며, 시간 윈도우 유형 및 시간 윈도우 크기와 같은 교차 리소스 통지 기준들을 정의할 수 있다. 리소스 호스트는 타겟 리소스들에 대한 예상된 변경들이 시간 윈도우 내에서 발생할 때 가입자 또는 그 지정된 통지 타겟들에게 교차 리소스 통지들을 발행한다.

다른 예에서, 가입자는 복수의 리소스들 상의 가입을 요청하기 위해 제1 리소스 호스트에게 메시지를 발행할 수 있다. 제1 리소스 호스트는 제2 리소스 호스트, 제3 리소스 호스트 등에서 유지될 수 있는 이러한 리소스들 모두를 갖지 않을 수 있다. 제1 리소스 호스트는 각각의 단일 리소스(타겟 리소스)에 가입하기 위해 다른 리소스 호스트들과 접촉할 수 있다. 제1 리소스 호스트는 다른 리소스 호스트들로부터 별도의 통지들을 수신하고 교차 리소스 통지를 생성하여 이를 가입자에게 보낼 수 있다. 제안된 교차 리소스 가입 해결책을 구현하기 위한 새로운 리소스들 및 속성들은 시간 윈도우 메커니즘들을 포함한다.

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

도 1은 서비스 계층을 지원하는 예시적인 프로토콜 스택을 도시한다.
도 2는 예시적인 공통 서비스 엔티티(CSE) 및 공통 서비스 기능(CSF)을 도시한다.
도 3은 예시적인 oneM2M 서비스 계층 기능 아키텍처(ROA)를 도시한다.
도 4는 예시적인 oneM2M 일반 가입 및 통지 절차를 도시한다.
도 5는 예시적인 스마트 빌딩 시나리오를 도시한다.
도 6은 예시적인 oneM2M 가입 메커니즘을 도시한다.
도 7은 예시적인 기본 교차 리소스 가입을 도시한다.
도 8은 예시적인 개선된 교차 리소스 가입을 도시한다.
도 9는 기존의 교차 리소스 가입의 예시적인 업데이트를 도시한다.
도 10은 기존의 교차 리소스 가입의 예시적인 삭제를 도시한다.
도 11은 교차 리소스 통지들을 생성하기 위한 주기적인 시간 윈도우 메커니즘의 예시적인 흐름도를 도시한다.
도 12는 교차 리소스 통지들을 생성하기 위한 슬라이딩 시간 윈도우 메커니즘의 예시적인 흐름도를 도시한다.
도 13은 예시적인 시간 윈도우 메커니즘들을 도시한다.
도 14는 oneM2M ROA로의 예시적인 새로운 향상된 가입 및 통지(eSUB) CSF를 도시한다.
도 15a는 oneM2M에서의 예시적인 교차 리소스 가입을 도시한다.
도 15b는 oneM2M에서의 예시적인 교차 리소스 가입을 도시한다.
도 15c는 oneM2M에서의 예시적인 교차 리소스 가입을 도시한다.
도 16은 가입이 관련 리소스들에 대한 자식인 예시적인 종래의 리소스 구조를 도시한다.
도 17은 교차 리소스 가입 및 통지 시스템을 위한 예시적인 리소스 구조를 도시한다.
도 18은 가입자(예를 들어, oneM2M AE)를 위한 예시적인 사용자 인터페이스를 도시한다.
도 19는 리소스 호스트(예를 들어, oneM2M CSE)를 위한 예시적인 사용자 인터페이스를 도시한다.
도 20a는 개시된 주제가 구현될 수 있는 예시적인 기기간(M2M) 또는 사물 인터넷(IoT) 통신 시스템의 시스템도이다.
도 20b는 도 20a에 도시된 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 20c는 도 20a에 도시된 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다.
도 20d는 도 20a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

종래의 oneM2M 아키텍처에서, 가입자는 단지 단일 리소스에 가입할 수 있고 그 단일 리소스에 대한 예상된 변경이 있을 때 자동 통지들(본 명세서에서 "단일 리소스 가입" 또는 "단일 리소스 통지"로도 알려짐)을 수신할 수 있다. 본 명세서에는 가입자가 복수의 리소스들에 가입하고, 통지 조건들이 복수의 리소스들(본 명세서에서 "타겟 리소스들"이라고 지칭됨)에 대한 의존성들에 기반한 교차 리소스 가입 및 교차 리소스 통지(때로는 교체가능하게 사용됨)가 개시되어 있다. oneM2M에서 정의되는 바와 같은 타겟 리소스들의 예는 <container> 리소스이다. 가입자는 타겟 리소스들과 관련된 일치 기준들에 기반하여 통지들을 수신한다.

도 5는 온도(예를 들어, 온도 센서(147)) 및 연기(예를 들어, 연기 센서(148))와 같은 빌딩 환경 정보를 모니터링하기 위해 다양한 유형들의 센서들이 배치되는 스마트 빌딩 시나리오를 도시한다. 이들 센서들로부터의 판독들은 로컬 M2M 게이트웨이(144)에 저장될 수 있다. 데스크톱 컴퓨터 또는 스마트 폰 상에 있을 수 있는 M2M 애플리케이션(141)은 반드시 모든 개별적인 센서 판독에 관심이 있는 것은 아니지만, "온도가 25℃보다 더 높을 때" 및 "연기가 감지될 때" 자동 통지들을 수신하길 원한다. 이것은 본 개시내용에서 교차 리소스 가입의 예이다. 교차 리소스 가입은 자동 통지가 단일 리소스뿐만 아니라 둘 이상의 리소스들에 의존하는 가입으로 간주될 수 있다. 즉, 복수의 리소스들에 대한 변경들이 발생할 때 통지들이 생성된다. 이 예에서, 자동 통지는 단일 리소스가 아닌 2개의 리소스(예를 들어, 온도 판독 및 연기 판독 - 각각의 타겟 리소스)에 의존하며, 교차 리소스 통지로 지칭된다. 다른 예(도 5에 도시되지 않음)에서, 가입자(예를 들어, M2M 애플리케이션(141))는 1) 검색 동작이 제1 리소스에 대해 수행되고 또한 2) 삭제 동작이 제2 리소스에 대해 거의 동시에 수행될 때 통지를 받도록 가입할 수 있다.

도 5를 참조하여 설명한 바와 같이, 센서들로부터의 판독들은 리소스 호스트로 지칭될 수 있는 로컬 M2M 게이트웨이(144)에 저장될 수 있다. 가입자로서 M2M 애플리케이션(141)은 M2M 게이트웨이(144)에서 리소스들에 가입한다. oneM2M에서 기존의 oneM2M 리소스 가입 메커니즘들이 동일한 이벤트 통지 기준들을 갖는 단일 리소스 또는 리소스들의 그룹에 대한 가입만을 지원하므로(예를 들어, 복수의 온도 센서들이 화씨 90도의 온도를 표시한 후의 통지), M2M 애플리케이션(141)은 통상적으로 M2M 게이트웨이(144)(도 6 참조)에 2개의 별도의 가입을 할 필요가 있다. 도 6은 도 5의 사용 사례를 구현하려고 시도할 수 있는 예시적인 종래의 oneM2M 가입 메커니즘을 도시한다. 단계(151)에서, M2M 게이트웨이(144)는 온도 센서 판독(예를 들어, "25℃보다 더 높은 온도")에 관한 가입 요청을 수신한다. 단계(152)에서, M2M 게이트웨이(144)는 연기 센서 판독(예를 들어, "연기가 감지됨")에 관한 다른 가입 요청을 수신한다. 단계(153)에서, M2M 게이트웨이(144)는 온도 센서 상의 관심 이벤트가 발생하는지를 결정하고, 이어서 단계(154)에서 그 이벤트에 관한 통지를 M2M 애플리케이션(141)에 보낸다. 단계(155)에서, M2M 게이트웨이(144)는 연기 센서 상의 관심 이벤트가 발생하는지를 결정하고, 이어서 단계(156)에서 그 이벤트에 관한 통지를 M2M 애플리케이션(141)에 보낸다. 단계(157)에서, M2M 애플리케이션(141)은 단계(154)의 통지 및 단계(156)의 통지를 분석하여 관심 이벤트가 발생하는지("온도가 25℃보다 더 높은지" 및 "연기가 감지되는지")를 결정한다. 종래의 oneM2M 시스템의 사용은 M2M 애플리케이션(141)에서 가외의 통지들(예를 들어, 단계(154) 및 단계(156)) 및 오버헤드(예를 들어, 더 많은 처리)를 도입한다. M2M 애플리케이션(141)은 온도 센서 또는 연기 센서가 변할 때마다 M2M 게이트웨이로부터 별도의 통지들을 수신할 것이며, 그 다음에 자체 지능에 의존하여 예상된 이벤트가 발생했는지를 결정한다. 종래의 그룹 가입과 관련하여, oneM2M은 모든 그룹 멤버들에게 동일한 이벤트 통지 기준들을 갖는 가입만을 지원하므로, 이러한 사용 사례를 지원할 수 없다는 점을 이해해야 한다. 예를 들어, <group> 리소스는 2개의 멤버(예를 들어, 온도 센서 및 연기 센서)를 갖는 M2M 게이트웨이(144)에서 생성될 수 있지만, M2M 애플리케이션은 그 이용 사례가 동일한 유형(예를 들어, 제1 온도 센서 및 제2 온도 센서가 25℃보다 더 높음)이어야 하기 때문에 본 명세서에서 논의된 바와 같은 이용 사례(예를 들어, "온도가 25℃보다 더 높음" 및 "연기가 감지됨")를 실현하기 위해 <group>/<subscription> 리소스(즉, 그룹을 위한 가입 메커니즘)를 생성할 수 없다. 통상적으로, M2M 애플리케이션(141)은 각각의 멤버 리소스에 대한 상이한 이벤트 통지 기준들을 표시할 수 없으며, 기존의 oneM2M 그룹 가입에 기반하여 교차 리소스 통지들이 생성되는 방법을 표시할 수 없다.

이하는 종래의 oneM2M 가입들에 관한 여러 문제점들에 대한 논의이다. (본 명세서에서 논의되는 바와 같은) 교차 리소스 가입들 및 통지들을 구현하려는 시도들은 가입자로부터 리소스 호스트로의 가외의 가입 요청 메시지들을 도입할 수 있다. 이러한 시도들은 또한 리소스 호스트로부터 가입자로의 가외의 통지 메시지들을 도입할 수 있다. 종래의 oneM2M을 사용하는 리소스 호스트는 교차 리소스 통지를 결정할 능력이 없다. 가입자에게는 가외의 처리 및 오버헤드가 필요하다. 즉, 가입자는 먼저 개별 가입들 간의 관계 및 의존성들에 대한 논리를 유지해야 한다. 그 다음, 각각의 수신된 개별 통지를 분석하여 실제 관심 이벤트가 발생하는지를 결정해야 한다. 마지막으로, 개별 통지가 전송 중에 손실되면, 가입자는 리소스 호스트에서 관심 이벤트가 발생했는지를 알 수 없다. 손실된 전송이 재전송되면, 재전송된 메시지(들)는 본 명세서에서 논의되는 바와 같은 교차 리소스 가입들 및 통지들과 비교해 상당히 많은 메시지들을 통신 채널에 추가할 수 있다.

교차 리소스 가입 및 교차 리소스 통지와 관련하여 본 명세서에 개시된 바와 같이, 가입자는 복수의 리소스들에 가입할 수 있다. 통지 조건들은 복수의 리소스들(타겟 리소스들이라고 지칭됨)에 대한 의존성들에 기반하고, 수신된 통지들은 타겟 리소스들에 대한 예상된 변경들에 기반한다.

가입자는 일반적으로 통지 타겟인 것으로 가정되지만, 그렇지 않을 수도 있다는 점에 유의한다. 가입자가 통지 타겟이 아닌 경우, 본 명세서에서 설명된 절차들은 리소스 호스트로부터 가입자 대신에 특정한 통지 타겟으로 통지들이 발행될 것이라는 점을 제외하고는 유사할 것이다.

이하에는 기본적인 교차 리소스 가입 절차들이 논의된다. 기본적인 교차 리소스 가입의 경우, 가입자는 리소스 호스트에 단일 메시지를 발행하여 복수의 타겟 리소스들에 대한 가입을 요청한다. 리소스 호스트는 이러한 타겟 리소스들을 로컬로 유지한다. 리소스 호스트는 타겟 리소스들에 대한 기준들이 시간 윈도우 내에서 충족될 때 가입자(또는 지정된 통지 타겟들)에게 교차 리소스 통지들을 발행한다.

도 7 내지 도 12에 도시된 단계들을 수행하는 엔티티들은, 도 20c 또는 도 20d에 도시된 것들과 같은 디바이스, 서버 또는 컴퓨터 시스템의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 예시적인 논리 엔티티들인 것으로 이해된다. 즉, 도 7 내지 도 12에 도시된 방법(들)은 도 20c 또는 도 20d에 도시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리에 저장된 소프트웨어(예를 들어, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행가능한 명령어들은 컴퓨팅 디바이스의 프로세서에 의해 실행될 때 도 7 내지 도 12에 도시된 단계들을 수행한다. 일례로서, M2M 디바이스들의 상호작용과 관련된 아래의 추가적인 세부내용과 관련하여, 도 35의 AE(741)는 도 20a의 M2M 단말 디바이스(18) 상에 존재할 수 있는 반면에, 도 35의 CSE(732) 및 Sscl(742)은 도 20a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다.

도 7은 기본적인 교차 리소스 가입에 대한 예시적인 흐름을 도시한다. M2M 엔티티(161)는 리소스 호스트(예를 들어, oneM2M IN-CSE)이고, M2M 엔티티(162)는 가입자(예를 들어, oneM2M IN-AE)이다. 단계(164)에서, M2M 엔티티(162)는 M2M 엔티티(161)에 요청 메시지를 보낸다. 이 요청 메시지는 M2M 엔티티(162)가 복수의 리소스들(예를 들어, 타겟 리소스들)의 변경들에 관심이 있으며 그 기준들이 충족될 때 단일 통지의 수신을 예상한다는 것을 M2M 엔티티(161)에 알리는 교차 리소스 가입을 위한 것이다. 다음의 파라미터들, 즉 listOfTargetResources, listOfEventNotificationCriteria, numOfTargetResourcesForNotification, timeWindowType 및 timeWindowSize가 단계(164)의 메시지에 포함될 수 있다. listOfTargetResources는 M2M 엔티티(162)가 관심이 있는 복수의 타겟 리소스들의 리스트(예를 들어, 타겟 리소스들의 식별자들)이다. 표 1에서의 예를 참조한다. listOfEventNotificationCriteria는 타겟 리소스들에 대한 이벤트 통지 기준들의 리스트이다. 하나의 이벤트 통지 기준들이 listOfTargetResources의 각각의 리소스에 적용된다. 각각의 이벤트 통지 기준들은 oneM2M에서 정의된 바와 같은 eventNotificationCriteria와 유사한다. 모든 타겟 리소스들이 동일한 이벤트 통지 기준들을 갖는 경우, 이 파라미터는 모든 타겟 리소스들에 적용되는 하나의 이벤트 통지 기준들만을 포함한다. numOfTargetResourcesForNotification은 기준들이 충족되는 경우(예를 들어, 타겟 리소스들에 대한 변경들이 일어나는 경우) M2M 엔티티(162)가 통지를 수신하기를 예상하는 타겟 리소스들의 수이다. 기본적으로, 이 파라미터의 값은 listOfTargetResources에 포함된 타겟 리소스들의 수와 동일하다. 이 경우, 통지는 타겟 리소스들에 대한 변경들이 발생하고 기준들을 충족시킬 때 M2M 엔티티(161)에 의해 생성된다. numOfTargetResourcesForNotification의 값은 listOfTargetResources에 포함된 타겟 리소스들의 수보다 더 작을 수 있다. 이 경우, M2M 엔티티(162)는 타겟 리소스들에 대한 변경들이 발생하고 기준들을 충족시킬 때 통지들을 생성할 수 있다. timeWindowType은 M2M 엔티티(161)가 교차 리소스 통지들을 결정하기 위해 사용할 수 있는 시간 윈도우의 유형(예를 들어, 주기적인 시간 윈도우 또는 슬라이딩 시간 윈도우)을 표시한다. timeWindowSize는 이 시간 윈도우 동안 타겟 리소스들에 대한 변경들이 발생하고 기준들을 충족시킬 때 M2M 엔티티(161)가 M2M 엔티티(162)에 통지를 보내도록 경고하는 시간 윈도우 지속기간이다. timeWindowType 및 timeWindowSize에 대해서는 본 명세서에서 더 상세히 논의된다.

<표 1>

계속해서 단계(164)를 참조하면, M2M 엔티티(162)가 M2M 엔티티(161)와의 이전에 설정된 개별 가입들을 갖는 경우, 단계(164)에서 M2M 엔티티(162)는 이전에 설정된 개별 가입들의 URI를 포함하여 교차 리소스 가입을 요청할 수 있는 것으로 고려된다. 또한, 단계(164)와 관련하여 전술한 listOfTargetResources에 대한 listOfEventNotificationCriteria의 매핑은 listOfEventNotificationCriteria 및 listOfTargetResources를 (targetResource, eventNotificationCriteria) 투플들의 리스트로 대체하는 것과 같은 다른 매핑 옵션들을 갖는다. 또한, listOfEventNotificationCriteria 및 listOfTargetResources를 단일 이벤트 통지 기준들에 할당된 타겟 리소스들의 리스트, 예를 들어 (targetResource1, targetResource2, targetResource3, eventNotificationCriteria1), (targetResource4, targetResource5, eventNotificationCriteria2) 등으로 대체하는 다른 예가 있을 수 있다.

단계(165)에서, M2M 엔티티(161)는 단계(164)의 교차 리소스 가입 요청 메시지를 처리한다. M2M 엔티티(162)가 타겟 리소스들(예를 들어, listOfTargetResources 전체)에 대한 액세스 권한을 갖지 않는다면, M2M 엔티티(161)는 수신된 교차 리소스 가입 요청 메시지를 거절할 수 있다. 요청이 승인되면, M2M 엔티티(161)는 M2M 엔티티(162)에 대한 listOfTargetResources, listOfEventNotificationCriteria, numOfTargetResourcesForNotification 및 timeWindow의 기록을 생성할 수 있다. 즉, M2M 엔티티(161)에 의해 승인된 M2M 엔티티(162)로부터의 각각의 교차 리소스 가입 요청에 대해, M2M 엔티티(161)는 이 승인된 교차 리소스 요청을 유지하기 위해 로컬 가입 리소스를 생성한다. 이러한 리소스 구조에 대한 세부내용들은 oneM2M의 맥락에서 나중에 논의된다.

단계(166)에서, M2M 엔티티(161)는 M2M 엔티티(162)에 응답을 보낸다. 이 응답은 단계(165)에서 생성된 로컬 가입 리소스의 URI뿐만 아니라 단계(164)의 요청 메시지의 성공 표시를 포함할 수 있다. 단계(167)에서, M2M 엔티티(161)는 타겟 리소스들에 대한 이벤트들이 발생하는지를 관찰한다. 단계(168)에서, M2M 엔티티(161)는 시간 윈도우 알고리즘들을 수행하여 M2M 엔티티(162)에 통지를 보낼 필요가 있는지 여부를 결정한다. 단계(164)와 관련하여 언급한 바와 같이, 모든 또는 일부 타겟 리소스들(그 수는 파라미터 numOfTargetResourcesForNotification에 의해 지정됨)에 대한 변경들이 파라미터 timeWindowSize에 의해 설계된 시간 윈도우 내에서 발생하면, 통지가 생성될 것이다. 리소스 호스트로서 M2M 엔티티(161)에서 구현되는 이러한 시간 윈도우 메커니즘은 단일 리소스 가입이 사용된 경우 가입자(예를 들어, M2M 엔티티(162))에게 부과될 수 있는 교차 리소스 가입의 지능을 가능하게 한다.

계속해서 도 7의 단계(168)를 참조하면, (numOfTargetResourceForNotification에 의해 표시되는) 타겟 리소스들의 수에 대한 기준들이 충족되는 경우에만 통지가 생성될 수 있음이 개시되어 있다. 이는 논리 및 동작으로 간주될 수 있다. 아래에서 논의되는 바와 같이, 다른 더 개선된 동작들이 M2M 엔티티(161)에 의해 또한 적용될 수 있다. 이 경우, 단계(164)에서 M2M 엔티티(162)는 동작 유형들을 M2M 엔티티(161)에 요청 및 표시할 수 있다. M2M 엔티티(161)는 임의의 타겟 리소스가 시간 윈도우 내에서 예상된 변경을 한 경우(예를 들어, 기준 충족) 교차 리소스 통지를 생성한다. 다른 동작들은 다음의 동작들, 즉 M2M 엔티티(161)는 타겟 리소스들 중 어느 것도 시간 윈도우 내에서 예상된 변경을 하지 않은 경우에 교차 리소스 통지를 생성하는 것, M2M 엔티티(161)는 타겟 리소스들의 수가 시간 윈도우 내에서 예상된 변경들을 하고, 타겟 리소스들의 다른 수가 동일한 시간 윈도우 내에서 예상된 변경들을 하지 않은 경우에 교차 리소스 통지를 생성하는 것, M2M 엔티티(161)는 타겟 리소스들의 수가 약간의 시간 윈도우들 내에서 연속적으로 예상된 변경들을 한 경우에 교차 리소스 통지를 생성하는 것, 및 M2M 엔티티(161)는 약간의 시간 윈도우들 내에서 연속적으로 예상된 변경들이 없는 경우에 교차 리소스 통지를 생성하는 것을 포함할 수 있다. listOfTargetResources와 listOfEventNotificationCriteria 모두가 2개의 정렬된 리스트인 다른 예가 있을 수 있다. 따라서, M2M 엔티티(161)는 제1 numOfTargetResourcesForNotification 타겟 리소스들에 대한 이벤트 통지 기준들이 충족되는 경우, 교차 리소스 통지를 생성하거나, 또는 M2M 엔티티(161)는 이벤트 통지 기준들의 제1 특정 수가 충족되는 경우, 교차 리소스 통지를 생성한다.

단계(169)에서, M2M 엔티티(161)는 M2M 엔티티(162), 및 단계(168)로부터의 결정이 "예"라고 가정하고 notificationURI들에 의해 지정된 다른 엔티티들에게 통지를 보낸다.

도 8은 예시적인 개선된 교차 리소스 가입을 도시한다. 도 8은 M2M 엔티티(162)(예를 들어, oneM2M IN-AE)가 여전히 M2M 엔티티(161)(예를 들어, oneM2M IN-CSE)에 교차 리소스 가입을 하지만, M2M 엔티티(161)가 임의의 타겟 리소스들을 호스팅하지 않는 시나리오이다. 그 대신, 각각의 타겟 리소스는 상이한 M2M 엔티티(예를 들어, 도 8에 도시된 예들과 같은 M2M 엔티티(163) 및 M2M 엔티티(160)(예를 들어, oneM2M MN-CSE))에서 호스팅된다. 단계(171)에서, 도 7에서의 단계(164)와 유사하게, 도 8에서의 M2M 엔티티(162)는 교차 리소스 가입 요청 메시지를 M2M 엔티티(161)에 보낸다. M2M 엔티티(161)가 M2M 엔티티(163) 및 M2M 엔티티(160) 상의 원래 리소스들의 주소들을 가질 수 있거나, 또는 M2M 엔티티(162)가 그 주소들을 직접 발견하고, 파라미터 listOfTargetResources를 통해 M2M 엔티티(161)에 알릴 수 있는 것으로 고려된다.

계속해서 도 8을 참조하면, 단계(172)에서 M2M 엔티티(161)는 가입 요청을 처리한다. 또한, M2M 엔티티(161)는 단계(171)에서 표시된 타겟 리소스들이 로컬로 호스팅되지 않음을 알게 된다. 그 결과, M2M 엔티티(161)는 다른 리소스 호스트들과 접촉해야 한다. 단계(171)에서는 M2M 엔티티(163) 및 M2M 엔티티(160)에서 유지되는 2개의 타겟 리소스에 대한 요청을 포함한다고 가정한다. M2M 엔티티(162)(가입자)는 oneM2M에서 정의된 기존의 리소스 발견 절차들을 사용하여 M2M 엔티티(163) 또는 M2M 엔티티(160)에서 유지되는 로컬 리소스들을 발견할 수 있다. 이 단계(171)에서, M2M 엔티티(161)에 의해 승인된 M2M 엔티티(162)로부터의 각각의 교차 리소스 가입 요청에 대해, M2M 엔티티(161)는 승인된 교차 리소스 요청을 유지하기 위해 로컬 가입 리소스를 생성할 수 있다. 이러한 리소스 구조에 대한 세부내용들은 본 명세서에서 oneM2M의 맥락에서 더 상세히 논의된다.

단계(173)에서, M2M 엔티티(161)는 단일 타겟 리소스에 대해 M2M 엔티티(163)에게 단일 리소스 가입 요청(예를 들어, oneM2M에서 정의된 바와 같은 가입 요청)을 보낸다. 이 타겟 리소스에 대한 이벤트 통지 기준들은 단계(171)로부터 기인한 것이다. notificationURI는 M2M 엔티티(161)일 수 있다. 단계(171)에서, M2M 엔티티(161)는 이 가입이 M2M 엔티티(162)의 교차 리소스 가입에 대한 것임을 표시할 수 있거나, 또는 M2M 엔티티(161)는 M2M 엔티티(162)의 교차 리소스 가입에 관한 어떠한 정보도 표시하지 않을 수 있다. 교차 리소스 가입의 표시가 있는 경우, M2M 엔티티(161)는 이 메시지에 M2M 엔티티(162)의 식별자를 포함시킬 수 있다.

계속해서 도 8을 참조하면, 단계(174)에서 M2M 엔티티(163)는 응답을 M2M 엔티티(161)에 보낸다. 단계(173)에서 M2M 엔티티(162)의 식별자가 포함되면, M2M 엔티티(163)는 M2M 엔티티(162)(또는 M2M 엔티티(161)와 함께)에 대한 허가를 수행하고 허가 결과들에 기반하여 M2M 엔티티(161)에 성공 또는 실패 응답을 보낼 수 있다. 그렇지 않으면, M2M 엔티티(163)는 단지 M2M 엔티티(161)에 대한 허가를 수행하고 응답을 M2M 엔티티(161)에 보낼 수 있다. 단계(175)에서, M2M 엔티티(161)는 단일 타겟 리소스에 대해 M2M 엔티티(160)에 단일 리소스 가입 요청(예를 들어, oneM2M에서 정의된 바와 같은 가입 요청)을 보낸다. 이 타겟 리소스에 대한 이벤트 통지 기준들은 단계(161)로부터 기인한 것이다. notificationURI는 M2M 엔티티(161)에 연결될 수 있다. 단계(171)에서, M2M 엔티티(161)는 이 가입이 M2M 엔티티(162)의 교차 리소스 가입에 대한 것임을 표시할 수 있거나, 또는 M2M 엔티티(161)는 M2M 엔티티(162)의 교차 리소스 가입에 관한 어떠한 정보도 표시하지 않을 수 있다. 교차 리소스 가입의 표시가 있는 경우, M2M 엔티티(161)는 이 메시지에 M2M 엔티티(162)의 식별자를 포함시킬 수 있다.

단계(176)에서, M2M 엔티티(160)는 M2M 엔티티(161)에 응답을 보낸다. M2M 엔티티(162)의 식별자가 단계(175)에서 포함되면, M2M 엔티티(160)는 M2M 엔티티(162)(또는 M2M 엔티티(161)와 함께)에 대한 허가를 수행하고 허가 결과들에 기반하여 M2M 엔티티(161)에 성공 또는 실패 응답을 보낼 수 있다. 그렇지 않으면, M2M 엔티티(160)는 단지 M2M 엔티티(161)에 대한 허가를 수행하고 응답을 M2M 엔티티(161)에 보낼 수 있다. 단계(177)에서, M2M 엔티티(161)는 성공 또는 실패일 수 있는 단계(171)에 대한 결과를 표시하기 위해 M2M 엔티티(162)에 응답을 보낸다. 단계(178)에서, 타겟 리소스에 대한 이벤트가 M2M 엔티티(163)에서 발생한다. 단계(179)에서, M2M 엔티티(163)는 M2M 엔티티(161)에게 통지를 보낸다. M2M 엔티티(161)는 이 통지를 버퍼링하고 단계(182)에서와 같은 나중 기간에 추가적인 처리를 수행할 수 있다. 단계(180)에서, 타겟 리소스에 대한 이벤트가 M2M 엔티티(160)에서 발생한다. 단계(181)에서, M2M 엔티티(160)는 M2M 엔티티(161)에 통지를 보낸다. M2M 엔티티(161)는 단계(182)에서 나중 처리를 위해 이 통지를 버퍼링할 수 있다. 단계(179) 및 단계(181)의 통지들이 충족된 기준들과 일치하는 단계(178) 및 단계(180)의 이벤트들에 응답하는 것으로 가정한다. 이러한 기준들은 단계(171)에서 M2M 엔티티(161)에 초기에 제공될 수 있고, 그 다음에 M2M 엔티티(160) 및 M2M 엔티티(163)와 같은 M2M 엔티티들에 개별적으로 후속하여 배포될 수 있다. 단계(182)에서, 도 7에서의 단계(165)와 유사하게, 도 8의 M2M 엔티티(161)는 시간 윈도우 메커니즘들을 수행하여 통지가 M2M 엔티티(162)에 보내져야 하는지를 결정한다. 단계(179) 및 단계(181)로부터의 통지들 모두가 단계(171)에서 지정된 바와 같이 지정된 시간 윈도우 동안 수신된 경우, M2M 엔티티(161)는 통지를 생성하고 이 통지를 M2M 엔티티(162)에 보낸다(단계(183)). 시간 윈도우 메커니즘에 대한 세부내용들이 본 명세서에서 논의된다. 단계(183)에서, M2M 엔티티(161)는 M2M 엔티티(162)에 통지를 보낸다. 단계(183)의 통지 메시지는 단계들(178 및 180)에서 발생한 이벤트들을 포함할 수 있다. 혹은, 단계(183)의 통지 메시지는 단지 애플리케이션 의존이지만 M2M 엔티티(161)에 의해 결정되는 미리 구성된 규칙에 기반하여 동작을 트리거링하기 위한 표시일 수 있다. 예를 들어, M2M 엔티티(162)는 센서에 명령을 보내서(또는 명령을 수신하여) 물을 틀 수 있다. 단계(183)에서의 통지는 화재 이벤트의 감지와 관련될 수 있다.

도 8과 관련한 몇몇 추가적인 고려사항들이 이하에서 논의된다. 도 8에서, 단일 리소스 가입 요청(예를 들어, 단계(173) 또는 단계(175))이 실패하는 경우들이 있을 수 있다. 이 경우, 단계(177)의 응답 메시지에 포함될 수 있는 M2M 엔티티(162)로부터의 교차 리소스 가입도 실패할 것이다. 단계(173)가 먼저 실패하면, M2M 엔티티(161)는 M2M 엔티티(160)에 접촉하지 않지만 그 대신에 실패 응답을 M2M 엔티티(162)에 보낼 수 있다. 단계(173)가 성공적이지만, 단계(175)가 성공적이지 않으면, M2M 엔티티(161)는 (예를 들어, 단계(177)에서) M2M 엔티티(162)에 실패 응답을 보낼 수 있다. 또한, M2M 엔티티(163)와 관련된 단계(173 및 174)에서 생성된 가입은 비활성화될 수 있다(예를 들어, 삭제될 수 있다). 단계(173) 및 단계(175) 모두가 성공적이지만, M2M 엔티티(163)(또는 M2M 엔티티(160))에서의 타겟 리소스가 나중에 사용가능하지 않게 되거나 기존의 가입들이 무효가 되면, M2M 엔티티(161)는 M2M 엔티티(162)에 대해 로컬로 생성된 교차 리소스 가입을 제거하고 실패 응답을 보낼 수 있다. 또한, M2M 엔티티(161)는 다른 리소스 호스트들(예를 들어, M2M 엔티티(160))과의 기존의 단일 리소스 가입들을 비활성화할 수 있다.

계속해서 도 8을 참조하면, 단계(172)와 관련하여 다른 고려사항이 있다. 단계(172)에서, M2M 엔티티(161)는 임의의 수의 이유들로 M2M 엔티티(162)의 교차 리소스 가입 요청을 거절할 수 있다. 한 가지 이유는 그 요청이 특정한 임계값을 초과하여 처리 또는 메모리를 증가시킬 수 있기 때문일 수 있다. 다른 이유는 특정한 서비스 품질을 충족시킬 수 없을 수 있다는 것이다. 일반적으로, 그 이유들은 요청이 특정한 기준들에 적합하지 않을 수 있으며, 이는 너무 복잡하거나 특정한 시간 윈도우 내에 맞지 않을 수 있음을 포함할 수 있다. 그 결과, 단계(173) 내지 단계(176)는 스킵될 수 있다(또한 단계(178) 내지 단계(183)는 발생하지 않을 것이다). M2M 엔티티(161)는 단지 단계(177)를 사용하여 실패 통지를 포함하는 응답 메시지를 M2M 엔티티(162)에 보낼 수 있다.

도 9는 기존의 교차 리소스 가입을 업데이트하기 위한 예시적인 메시지 흐름을 도시한다. 기존의 교차 리소스 가입은 원래 가입자(또는 다른 적격의 엔티티들)에 의해 업데이트될 수 있다. 예를 들어, 타겟 리소스를 제거하거나 새로운 타겟 리소스를 추가할 수 있다. 또한, 이벤트 통지 기준들 또는 시간 윈도우 크기를 변경할 수 있다. 단계(191)에서, 원래 가입자로서의 M2M 엔티티(162)는 예를 들어 도 7 또는 도 8에서의 절차들에 따라 생성되는 기존의 교차 리소스 가입의 속성들을 업데이트하기 위해 M2M 엔티티(161)에 교차 리소스 가입에 대한 업데이트 메시지를 보낸다. 단계(191)의 업데이트 메시지는 다음의 파라미터들, 즉 subscriptionID, listofTargetResource, eventNotificationCriteria, numOfTargetResourcesForNotification, timeWindowType 또는 timeWindowSize를 포함할 수 있다. subscriptionID는 업데이트될 기존의 교차 리소스 가입의 URI로 간주될 수 있다. listOfTargetResource는 모든 새로운 타겟 리소스들의 리스트로 간주될 수 있다. listOfTargetResource는 또한 삭제될 기존의 타겟 리소스들 또는 부가될 새로운 타겟 리소스들을 단순히 표시할 수 있다. eventNotificationCriteria는 새로운 이벤트 통지 기준들로 간주될 수 있다. 추가될 임의의 새로운 타겟 리소스가 있으면, eventNotificationCriteria는 이러한 새로운 타겟 리소스들에 대한 통지 기준들을 표시한다. numOfTargetResourcesForNotification은 통지를 생성하는데 필요한 새로운 타겟 리소스들의 수로 간주될 수 있다. timeWindowType은 새로운 시간 윈도우 유형이다. timeWindowSize는 통지들을 결정하기 위한 시간 윈도우의 새로운 크기로 간주될 수 있다.

단계(192)에서, M2M 엔티티(161)는 subscriptionID를 사용하여 단계(191)에서 포함된 파라미터들에 따라 기존의 교차 리소스 가입을 찾고 그 속성들을 업데이트한다. timeWindowType 또는 timeWindowSize가 변경되도록 요청되면, M2M 엔티티(161)는 기존의 이벤트들을 무시하고 현재의 시간 윈도우를 리셋하며 새로운 시간 윈도우를 재시작할 것이다. numOfTargetResourcesForNotification이 변경되면, M2M 엔티티(161)는 현재의 시간 윈도우를 유지할 수 있지만, 교차 리소스 통지는 더 빨리(예를 들어, numOfTargetResourcesForNotification이 감소됨) 또는 더 늦게(예를 들어, numOfTargetResourcesForNotification이 증가됨) 생성될 수 있다.

계속해서 도 9를 참조하면, 단계(193)에서 M2M 엔티티(161)는 업데이트된 교차 리소스 가입에 관련된 일부 타겟 리소스들이 존재하는 다른 리소스 호스트들(예를 들어, M2M 엔티티(163))과 접촉할 수 있다. M2M 엔티티(162)가 M2M 엔티티(163)에 존재하는 타겟 리소스에 대한 이벤트 통지 기준들을 업데이트하도록 요청하면, M2M 엔티티(161)는 M2M 엔티티(163)에게 새로운 이벤트 통지 기준들을 알릴 수 있다. M2M 엔티티(162)가 listOfTargetResouce로부터 타겟 리소스를 제거하도록 요청하고, 타겟 리소스가 M2M 엔티티(163)에 위치하면, M2M 엔티티(161)는 M2M 엔티티(163)와 접촉하여 이 타겟 리소스과 관련된 이전에 생성된 단일 리소스 가입을 삭제할 것이다. M2M 엔티티(162)가 새로운 타겟 리소스를 listOfTargetResource에 추가하도록 요청하고, 이 타겟 리소스가 M2M 엔티티(163)에 위치하면, M2M 엔티티(161)는 M2M 엔티티(163)와 접촉하여 M2M 엔티티(163)에서 새로운 단일 리소스 가입을 생성할 수 있다. 단계(194)에서, M2M 엔티티(161)는 특히 성공 또는 실패를 표시하는 정보와 같은, 단계(192) 및 단계(193)에서의 업데이트 동작 결과들에 관한 응답을 M2M 엔티티(162)에 보낸다.

도 10은 기존의 교차 리소스 가입을 업데이트하기 위한 예시적인 메시지 흐름을 도시한다. 기존의 교차 리소스 가입은 원래 가입자(또는 다른 적법한 엔티티들)에 의해 삭제될 수 있다. 단계(201)에서, M2M 엔티티(162)(예를 들어, 원래 가입자)는 예를 들어 M2M 엔티티(161)에 메시지를 보내서 도 7 또는 도 8에서의 절차들에 따라 생성되는 기존의 교차 리소스 가입을 삭제한다. 단계(201)의 이러한 삭제 메시지는 삭제될 기존의 교차 리소스 가입의 URI일 수 있는 subscriptionID를 포함할 수 있다. 단계(202)에서, M2M 엔티티(161)는 subscriptionID를 사용하여 삭제할 기존의 교차 리소스 가입을 찾는다. 단계(203)에서, M2M 엔티티(161)는 삭제된 교차 리소스 가입과 관련된 일부 타겟 리소스들이 존재하는 다른 리소스 호스트들(예를 들어, M2M 엔티티(163))과 접촉하여 삭제된 교차 리소스 가입과 관련된 기존의 단일 리소스 가입을 삭제할 수 있다. 단계(204)에서, M2M 엔티티(161)는 특히 성공 또는 실패를 표시하는 정보와 같은 단계(202) 및 단계(203)에서의 삭제 동작 결과들에 관한 응답을 M2M 엔티티(162)에 보낸다.

이하, 교차 리소스 통지들을 보낼지 여부를 결정하는데 사용되는 시간 윈도우 메커니즘들이 논의된다. 각각의 교차 리소스 가입에서, 복수의 타겟 리소스들이 관련되며, 각각의 타겟 리소스에 대한 이벤트가 상이한 시간에 발생할 수 있다. 그 결과, 리소스 호스트(예를 들어, M2M 엔티티(161))는 원래 가입자에 의해 표시된 파라미터 timeWindowSize에 따라 원래 가입자에게 통지를 발행할 필요가 있는지를 결정할 수 있다. 시간 윈도우 메커니즘들 "주기적인 시간 윈도우" 및 "슬라이딩 시간 윈도우"가 본 명세서에서 논의된다. 주기적인 시간 윈도우과 관련하여, 시간은 동일한 크기의 시간 윈도우들로 분할된다. 각각의 시간 윈도우에 대해, 리소스 호스트는 시간 윈도우 내에서 타겟 리소스들에 대한 기준들이 충족될 때 통지를 발행한다. 슬라이딩 시간 윈도우와 관련하여, 교차 리소스 통지가 생성되거나 현재의 시간 윈도우가 만료될 때마다 시간 윈도우의 시작 시간이 동적으로 변경된다. 리소스 호스트는 (예를 들어, 타겟 리소스에 대한 예상된 이벤트들이 시간 윈도우에서 발생하는 경우에만) 유사한 논리를 사용하여 통지를 발행한다.

timeWindowSize는 제로로 설정될 수 있다는 점에 유의한다. 제로 값을 갖는 이러한 시간 윈도우를 구현하기 위해, 지정된 이벤트 조건들 중 하나가 트리거링될 때, 리소스 호스트는 다른 이벤트 통지 기준들이 또한 충족되는지를 체크해야 한다. 조건들이 실질적으로 동시에 충족되면 통지가 보내진다. 예를 들어, 가입자가 {"event1: (온도>25)" 및 "event2: (smokeSensor='감지됨')"}이 발생할 때 통지를 원하면, 가입자는 제로의 시간 윈도우를 지정하여 두 이벤트가 동시에 발생해야 한다는 것을 나타낼 수 있다.

도 11은 주기적인 시간 윈도우에 대한 예시적인 방법을 도시한다. 단계(211)에서, 리소스 호스트(예를 들어, M2M 엔티티(161) 또는 M2M 엔티티(160))는 시간 윈도우(tWin), 및 비어 있을 수 있는 이벤트 리스트(eList)를 생성한다. 단계(212)에서, M2M 엔티티(161)는 타겟 리소스의 다음 이벤트 또는 시간 윈도우(tWin)의 만료를 기다린다. 단계(213)에서, 타겟 리소스에 대한 새로운 이벤트가 발생하면, 단계(214)로 이동하고, 그렇지 않고 시간 윈도우가 만료되면 단계(215)로 이동한다. 단계(214)에서, M2M 엔티티(161)는 이 이벤트를 eList에 버퍼링할 수 있다. 단계(215)에서, M2M 엔티티(161)는 eList가 타겟 리소스들에 대한 예상된 이벤트들을 포함하는지를(즉, 기준들을 충족시키는지를) 체크한다. "예"라면, 단계(216)로 이동하고, 그렇지 않으면 단계(217)로 진행한다. 단계(216)에서, M2M 엔티티(161)는 통지를 생성하여 이를 notificationURI에 의해 표현되는 타겟들과 같은 타겟들에 보낼 수 있다. 단계(217)에서, M2M 엔티티(161)는 모든 버퍼링된 이벤트들을 제거함으로써 시간 윈도우(tWin)를 제거하고 eList를 비운다. 단계(218)에서, M2M 엔티티(161)는 새로운 시간 윈도우를 생성하고 그 시작 시간을 현재 시간으로 설정한다. 리소스 호스트는 통지를 보내기 위해 시간 윈도우의 끝까지 기다릴 필요가 없다는 점을 이해해야 한다. 리소스 호스트는 시간 윈도우 내에서 기준들이 충족되면 통지를 보낸다. 예를 들어, 통지는 도 13의 tWin(252)에서의 t14에서 보내질 수 있다.

도 12는 슬라이딩 시간 윈도우에 대한 예시적인 방법을 도시한다. 단계(220)에서, 리소스 호스트(예를 들어, M2M 엔티티(161) 또는 M2M 엔티티(163))는 타겟 리소스에 대한 다음 이벤트 또는 개시된 시간 윈도우(tWin)의 만료를 기다린다. 단계(220) 이후, 단계(221)에서 타겟 리소스의 새로운 이벤트가 발생하면, 발생하는 리소스에 대한 이벤트와 관련하여 블록(244)의 시작인 단계(225)로 이동하고, 그렇지 않고 시간 윈도우가 만료되면 단계(222)로 이동한다. 단계(222)는 시간 윈도우 만료에 관한 단계들의 블록(241)의 시작이다.

블록(241) 내의 단계(222)에서, M2M 엔티티(161)는 얼마나 많은 이벤트들이 eList에 포함되는지를 체크한다. 둘 이상의 이벤트가 있으면("예"), 단계(223)로 이동하고, 그렇지 않으면("아니오") 단계(235)로 이동한다. 단계(223)에서, M2M 엔티티(161)는 버퍼링된 이벤트 리스트(예를 들어, eList)의 리스트 내의 제2 이벤트에 따라 현재의 시간 윈도우를 슬라이딩시킨다. 즉, 시간 윈도우의 시작 시간이 제2 이벤트의 발생 시간으로 업데이트될 것이다. eList가 하나의 이벤트만을 포함하면, 리소스 호스트는 단지 현재의 시간 윈도우를 간단히 제거한다는 점에 유의한다. 예를 들어, 도 13에서, "슬라이딩 시간 윈도우"로 지칭되는 도해(270)에서의 tWin(273)은 시간 t4에서 발생하는 하나의 이벤트(이벤트 리소스 유형(281))만을 갖는다. 시간 t5에서, tWin(273)은 만료되고, 하나의 이벤트만이 있었기 때문에 eList 및 시간은 리셋될 것이다. 그 다음, 새로운 시간 윈도우(예를 들어, tWin(274))는 새로운 이벤트(이벤트 리소스 유형(282))가 발생하는 시간 t6에서 재시작될 것이다. 모든 타겟 리소스들이 시간 윈도우 내에서 기준들과 일치하지 않으면 리셋이 또한 발생할 수 있다. 단계(2247)에서, eList에서의 제1 이벤트가 제거될 것이다. 이제, 제2 이벤트가 eList에서의 제1 이벤트가 된다. 그 다음, 단계(220)가 다음 단계이다.

단계(225)에서, M2M 엔티티(161)는 이미 생성된 시간 윈도우가 존재하는지를 체크한다. "아니오"인 경우, 단계(226)로 이동하고, 그렇지 않고 시간 윈도우가 존재하면 단계(228)로 이동한다. 단계(226)에서, M2M 엔티티(161)는 미리 결정된 기준들과 일치하는 이벤트의 표시를 수신하는 거의 그 시간일 수 있는 현재 시간으로서 그 시작 시간을 설정하는 시간 윈도우(본 명세서에서는 tWin으로 지칭됨)를 생성한다. 단계(227)에서, M2M 엔티티(161)는 이벤트 리스트(eList로 지칭됨)를 생성하고 이 이벤트를 제1 이벤트로서 이벤트 리스트에 삽입한다. eList가 생성된 후, 단계(220)가 발생할 수 있다. 단계(228)에서, 이미 생성된 eList가 있다. 리소스 호스트는 eList의 끝에 이 이벤트를 부가한다. 단계(229)에서, M2M 엔티티(161)는 이 이벤트가 타겟 리소스에 대한 제1 이벤트인지 여부를 체크한다. "아니오"인 경우, 단계(230)로 이동하고, 그렇지 않고 "예"이면 단계(233)로 이동한다. 단계(230)에서, 동일한 타겟 리소스에 대한 더 오래된 이벤트가 eList로부터 제거된다. 단계(231)에서, 리소스 호스트는 제거된 더 오래된 이벤트가 eList에서의 제1 이벤트였는지를 체크한다. 단계(231)에서 "예"인 경우, 단계(232)로 이동하고, 그렇지 않으면 단계(220)로 진행한다. 단계(232)에서, M2M 엔티티(161)는 업데이트된 eList에 따라 시간 윈도우를 슬라이딩시킬 수 있다. 즉, 시간 윈도우의 시작 시간은 업데이트된 eList에서의 제1 이벤트의 발생 시간으로 설정된다. 단계(233)에서, M2M 엔티티(161)는 eList가 타겟 리소스들에 대한 예상된 이벤트들을 포함하는지를 체크한다. "예"인 경우, 단계(234)로 이동하고, 그렇지 않으면 단계(220)로 진행한다. 단계(234)에서, M2M 엔티티(161)는 통지를 생성하고 이를 notificationURI에 의해 표현되는 통지 타겟들에 보낸다. 단계(235)에서, M2M 엔티티(161)는 시간 윈도우 및 eList를 제거하고, 그 다음에 단계(220)로 진행한다.

도 13은 주기적인 시간 윈도우 및 슬라이딩 시간 윈도우의 예들을 도시한다. 이 예에서, 2개의 타겟 리소스, 즉 이벤트 리소스 유형(281) 및 이벤트 리소스 유형(282)이 있다고 가정한다. 도시된 이벤트 리소스 유형들은 시간 인스턴스(예를 들어, t11, t12, t13, t14, t15)에서 하나의 타겟 리소스에 대해 적어도 하나의 기준이 충족되었음을 표시하는 것이다. 주기적인 시간 윈도우는 새로운 시간 윈도우의 시작 시간이 대개 고정 시간 인스턴스들 또는 기간들에 나타나는 시간 윈도우 메커니즘이다. 도 13에 도시된 바와 같이, 도해(250)(주기적인 시간 윈도우)와 관련하여, 3개의 연속적인 시간 윈도우(예를 들어, tWin(251), tWin(252) 및 tWin(253))가 생성되지만, tWin(252) 및 tWin(253)만이 두 리소스의 이벤트들을 포함한다. 그 결과, tWin(251)에 통지가 없지만, tWin(252) 및 tWin(253)에 대한 통지가 생성될 것이다. 즉, tWin(251)은 타겟 리소스들에 대한 기준들을 충족시키지 못함에 따라 트리거링된 통지가 없는 시간 윈도우이고, tWin(252) 및 tWin(253)은 타겟 리소스들에 대한 기준들을 충족시킴에 따라 트리거링된 통지를 갖는 시간 윈도우들이다. 도 13에 도시된 바와 같이, 도해(270)(슬라이딩 시간 윈도우)와 관련하여, 4개의 시간 윈도우(예를 들어, tWin(271), tWin(272), tWin(273) 및 tWin(274))가 생성된다. 각각의 시간 윈도우는 실제로 시간 인스턴스(예를 들어, t1, t2, t3, t4, t6, t7)에서 타겟 리소스에 대한 기준과 일치하는 이벤트의 발생에 의해 시작된다는 점에 유의한다. 도해(270)는 tWin(272) 및 tWin(274)이 각각의 타겟 리소스의 미리 결정된 기준들을 충족시키는 이벤트들을 포함하고 통지를 생성할 것임을 도시한다. 도 13에서는, 이벤트 리소스 유형(281) 및 이벤트 리소스 유형(282)이 통지를 트리거링하는데 필요한 유일한 타겟 리소스들이라고 가정한다.

이하는 oneM2M 아키텍처에서 교차 리소스 가입을 구현하기 위한 예들이다. 이하에서는 상위 레벨 아키텍처 옵션들, 새로운 리소스들, 속성들 및 대응하는 호출 흐름들에 대해 논의된다. 또한, 사용자 인터페이스는 교차 리소스 가입 관련 파라미터들 및 정보의 예시적인 표시 또는 구성과 관련하여 논의된다.

oneM2M에 관련하여, 리소스 호스트(예를 들어, M2M 엔티티(161))와 관련된 절차들 및 프로세스들은 CSE(예를 들어, 도 20a의 M2M 서비스 계층(22))에서 구현될 수 있다. 또한, 가입자(예를 들어, 도 8에서의 M2M 엔티티(162))와 관련된 절차들 및 프로세스들이 AE(또는 AE가 가입자인 경우 CSE)에서 구현될 수 있다.

도 14는 oneM2M에 기반하여 eSUB(Enhanced Subscription and Notification) CSF(292)를 형성하기 위해 기존의 SUB CSF에 대해 교차 리소스 가입 또는 통지와 관련하여 개시된 것을 구현하기 위한 예를 도시한다. 이 새로운 eSUB(292)는 본 명세서에서 설명되는 바와 같이 리소스 호스트와 관련된 절차들 및 프로세스들을 지원한다. eSUB(292)는 IN-CSE, MN-CSE 또는 ASN-CSE에 존재할 수 있다.

도 15는 oneM2M에서의 교차 리소스 가입의 세 가지 예시적인 배치를 도시한다. 도 15a는 가입자가 AE(예를 들어, IN-AE, MN-AE, ASN-AE 또는 ADN-AE)인 반면, 리소스 호스트가 eSUB를 갖는 호스팅 CSE인 예를 도시한다. 본 명세서에서 논의되는 절차들은 호스팅 CSE(294)(리소스 호스트)와 AE(296)(가입자) 사이의 Mca 기준점(295)에 적용된다. 제안된 새로운 리소스 <xRsrcSub>는 eSub를 갖는 호스팅 CSE(예를 들어, IN-CSE, MN-CSE 또는 ASN-CSE)에 존재할 것이다. 도 15b는 가입자가 CSE(299)(예를 들어, MN-CSE, IN-CSE)인 반면, 리소스 호스트가 eSUB를 갖는 호스팅 CSE(297)인 예를 도시한다. 본 명세서에서 논의되는 절차들은 호스팅 CSE(297)와 가입자인 CSE(299) 사이의 Mcc/Mcc' 기준점(298)에 적용된다. 개시된 새로운 리소스 <xRsrcSub>는 eSub를 갖는 호스팅 CSE(예를 들어, IN-CSE)에 존재할 것이다. 도 15c는 가입자가 AE(예를 들어, IN-AE)인 반면, 그 타겟 리소스들이 3개의 CSE(예를 들어, eSUB를 갖는 호스팅 CSE(303), MN-CSE(305) 및 MN-CSE(307))에 분포되어 있는 예를 도시한다. 본 명세서에서 논의되는 절차들은 eSUB를 갖는 호스팅 CSE와 가입자 AE(301) 사이의 Mca 기준점(302)에 적용된다. 이 경우, MN-CSE(305) 및 MN-CSE(307)는 eSUB를 지원하지 않지만, oneM2M에서 기존의 SUB 기능들만을 갖는다. 개시된 새로운 리소스 <xRsrcSub>는 eSub를 갖는 호스팅 CSE(303)(예를 들어, IN-CSE)에 존재할 것이다.

도 7 내지 도 10과 관련한 절차들을 지원하기 위해, 예를 들어 oneM2M에 대해 새로운 가입 리소스(<xRsrcSub>로 지칭됨)가 본 명세서에서 논의된다. <xRsrcSub>는 표 1에 도시된 바와 같이 eventNotificationCriteria 및 약간의 새로운 속성들을 제외한 기존의 <subscription> 리소스의 모든 자식 리소스들 및 속성들(예를 들어, notificationURI)을 가질 수 있다. 표 1은 새로운 속성들의 예이다. 타겟 리소스들이 전용 속성 listOfTargetResources로 표시되므로, <sclBase> 리소스 트리 하에서 <xRsrcSub>가 생성되는 위치는 중요하지 않을 수 있다. 도 17은 본 명세서에서 논의되는 교차 리소스 가입 및 통지 시스템의 효과의 예를 도시한다. 기본적으로, <xRsrcSub>는 다양한 장소들(예를 들어, <AE>의 자식 리소스, <CSE>의 자식 리소스, <CSEBase>의 자식 리소스 또는 <group>의 자식 리소스)에 위치할 수 있으며, 이는 oneM2M 아키텍처에서의 종래의 <subscription> 리소스와 상이하다. 도 16은 가입이 관련 리소스들에 대한 자식인 종래의 리소스 구조의 예를 도시한다.

<표 1>

<xRsrcSub> 리소스 절차들은 listOfTargetResources에 의해 표시되는 복수의 타겟 리소스들의 수정들에 대해 통지될 새로운 <xRsrcSub> 리소스의 생성을 요청하는데 사용될 수 있다. 일반 생성 절차는 oneM2M(oneM2M-TS-0001, oneM2M 기능 아키텍처, V-2.3.0, 이하 [1])에서의 10.1.1.1 절에 설명되어 있다. 표 2는 예시적인 <xRsrcSub> CREATE를 보여준다.

<표 2>

절차들은 <xRsrcSub> 리소스의 속성들 및 자식 리소스 정보를 검색하는데 사용될 수 있다. 일반 검색 절차는 [1]에서의 10.1.2 절에 설명되어 있다. 표 3은 예시적인 <xRsrcSub> RETRIEVE이다.

<표 3>

절차들은 기존의 교차 리소스 가입(예를 들어, <xRsrcSub> 리소스)을 업데이트하는데, 예컨대 listOfTargetResources와 같은 그 속성들을 수정하는데 사용될 수 있다. 일반 업데이트 절차는 [1]에서의 10.1.3 절에 설명되어 있다. 표 4는 예시적인 <xRsrcSub> UPDATE이다.

<표 4>

절차들은 기존의 교차 리소스 가입(즉, <xRsrcSub> 리소스)을 가입해제하는데 사용될 수 있다. 일반 삭제 절차는 [1]에서의 10.1.4.1 절에 설명되어 있다. 표 5는 <xRsrcSub> DELETE의 예이다.

<표 5>

호스팅 CSE는 <xRsrcSub> 생성(또는 <xRsrcSub> 업데이트)을 수신한 후, 본 명세서에서 설명되는 바와 같이 시간 윈도우 메커니즘을 수행하여 통지가 발행될 필요가 있는지를 결정한다. 타겟 리소스들에 대한 예상된 변경들이 시간 윈도우 내에서 발생하는 경우에만, 호스팅 CSE가 발신자 또는 그 지정된 통지 수신자들에게 통지를 발행한다.

oneM2M에서의 종래의 <subscription> 리소스는, 예를 들어 표 6에서 설명되는 바와 같이 약간의 새로운 속성들을 추가함으로써 개시된 교차 리소스 가입을 지원하도록 확장될 수 있다. 즉, 이러한 새로운 속성들을 사용함으로써, 가입자(예를 들어, 생성자 또는 <subscription>)는 교차 리소스 가입을 트리거링하거나 가능하게 할 수 있다. 일례로서, IN-CSE가 두 멤버 <container1> 및 <container2>를 갖는 <group> 리소스(예를 들어, <inCSEBase>/<group>)를 갖는다고 가정한다. 두 컨테이너 리소스의 값이 임계값을 초과할 때 IN-AE가 자동 통지를 수신하길 원하면, IN-AE는 이 <group> 리소스의 자식 리소스로서 <subscription>을 생성하고 이하의 CREATE 명령을 사용하여 새로운 속성들에 대해 적합한 값들을 설정할 수 있다. 그 다음, IN-CSE는 두 컨테이너 리소스들의 값이 timeWindowSize(예를 들어, 60초) 내에서 임계값을 초과하도록 변경되면 통지를 발행한다. 예시적인 CREATE 명령은, CREATE <inCSEBase>/<group>/<subscription>; 페이로드: subType=1(교차 리소스 가입), timeWindowType=1(예를 들어, 주기적인 시간 윈도우), timeWindowSize=60초이다.

<표 6>

<subscription> 리소스에 대한 제안된 새로운 속성들로, oneM2M에서 <subscription>을 생성하기 위한 절차가 업데이트될 수 있다. 그러나, <subscription>을 검색하고, <subscription>을 업데이트하며, <subscription>을 삭제하기 위한 절차들은 oneM2M [1]에서의 기존의 절차들과 동일할 수 있다.

<subscription> 생성

이 절차는 복수의 타겟 리소스들에 대해 수정들이 통지될 새로운 <subscription> 리소스의 생성을 요청하는데 사용될 것이다. 일반 생성 절차는 [1]에서의 10.1.1.1 절에 설명되어 있다.

<표 7>

호스팅 CSE는 <subscription> 생성을 수신한 후, 본 명세서에서 설명되는 바와 같이 시간 윈도우 메커니즘을 수행하여 통지가 발행될 필요가 있는지를 결정한다. 타겟 리소스들에 대한 예상된 변경들이 시간 윈도우 내에서 발생하는 경우에만, 호스팅 CSE가 발신자 또는 그 지정된 통지 수신자들에게 통지를 발행한다.

사용자 인터페이스는 타겟 리소스들의 리스트, 이벤트 통지 기준들의 리스트 및 시간 윈도우 크기(도 18 참조)와 같은 교차 리소스 가입의 파라미터들을 구성하거나 표시하기 위해 가입자(예를 들어, AE)와 상호작용할 수 있다. 도 19는 본 명세서에서 논의된 방법들 및 시스템들에 기반하여 생성될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 도시한다. 도 19를 참조하면, 리소스 호스트에 대해, 사용자 인터페이스(321)는 블록(322)의 교차 리소스 가입 파라미터들에 더하여, (예를 들어, 대략 실시간으로) 타겟 리소스 정보(323)의 발생 이벤트들을 표시할 수 있다. 디스플레이 인터페이스(321)(예를 들어, 터치 스크린 디스플레이)는 표 1 내지 표 7의 파라미터들과 같은, 교차 리소스 가입과 관련된 블록(322)의 다른 텍스트를 제공할 수 있다. 다른 예에서, 본 명세서에서 논의되는 임의의 단계의 진행(예를 들어, 도 7 내지 도 12의 단계들의 메시지 보냄 또는 성공)은 디스플레이(321)에 의해 표시될 수 있다. 또한, 그래픽 출력(324)은 디스플레이 인터페이스(321) 상에 표시될 수 있다. 그래픽 출력(324)은 디바이스들의 토폴로지, 본 명세서에서 논의된 임의의 방법 또는 시스템들의 진행의 그래픽 출력 등일 수 있다.

도 20a는 교차 리소스 가입과 관련된 하나 이상의 개시된 개념(예를 들어, 도 7 내지 도 19 및 이에 수반한 논의)이 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT) 또는 사물 웹(Web of Things)(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 계층 등의 구성요소일 수 있다.

도 20a에 도시된 바와 같이, 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), 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 20a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 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(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크, 및 배선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 20b를 참조하면, 필드 도메인에서의 도시된 M2M 서비스 계층(22)(예를 들어, 본 명세서에서 설명되는 바와 같은 호스팅 CSE(294))은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18)과 통신 네트워크(12)에 서비스들을 제공한다. 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')은 하나 이상의 서버, 컴퓨터, 가상 머신(예를 들어, 클라우드/컴퓨팅/저장소 팜 등) 등에 의해 구현될 수 있다.

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

몇몇 예들에서, M2M 애플리케이션들(20 및 20')은 본 명세서에서 논의된 바와 같이 교차 리소스 가입과 관련된 방법을 사용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아닌, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에서 언급한 바와 같이, M2M 서비스 계층, 디바이스들에 걸쳐 실행하는 것, 게이트웨이들, 및 시스템의 다른 서버들은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들의 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.

본 출원의 교차 리소스 가입과 관련된 시스템들은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층(예를 들어, 호스팅 CSE(294))은 API들(application programming interfaces) 및 하위 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M 모두는 본 출원의 교차 리소스 가입과 관련된 방법을 포함할 수 있는 서비스 계층을 사용한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)이라고 지칭된다. SCL은 M2M 디바이스(여기서 이것은 DSCL(device SCL)이라고 지칭됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)이라고 지칭됨) 또는 네트워크 노드(여기서 이것은 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF들(Common Service Functions)(즉, 서비스 능력들)의 세트를 지원한다. CSF들 중의 한 세트의 하나 이상의 특정한 유형의 인스턴스화는 CSE라고 지칭되며, 이는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 교차 리소스 가입과 관련된 시스템들은 서비스 지향 아키텍처(SOA) 또는 리소스 지향 아키텍처(ROA)를 사용하여 본 출원의 교차 리소스 가입과 관련된 시스템들과 같은 서비스들에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.

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

도 20c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 20c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 트랜시버(34), 전송/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변 기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일관성을 유지하면서 위 엘리먼트들의 임의의 부분 조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예를 들어, M2M 엔티티(161), M2M 엔티티(160), M2M 엔티티(163), M2M 엔티티(162), 호스팅 CSE(294), AE(296), MN-CSE(305) 및 다른 디바이스들)는 교차 리소스 가입을 위한 개시된 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

프로세서(32)는, 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 관련되는 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 유형의 IC(integrated circuit), 상태 머신 등일 수 있다. 프로세서(32)는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리 또는 임의의 다른 기능을 수행할 수 있다. 프로세서(32)는 전송/수신 엘리먼트(36)에 결합될 수 있는 트랜시버(34)에 결합될 수 있다. 도 20c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 묘사하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 또는 무선 액세스 계층(radio access-layer)(RAN) 프로그램들 또는 통신들을 수행할 수 있다. 프로세서(32)는 예를 들어, 액세스 계층 또는 애플리케이션 계층과 같은 인증, 보안 키 일치 또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.

전송/수신 엘리먼트(36)는 신호들을 M2M 서비스 플랫폼(22)에 전송하거나 또는 이로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 전송/수신 엘리먼트(36)는 RF 신호들을 전송하거나 수신하도록 구성된 안테나일 수 있다. 전송/수신 엘리먼트(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 일례로서, 전송/수신 엘리먼트(36)는, 예를 들어, IR, UV 또는 가시광 신호들을 전송하거나 수신하도록 구성된 이미터/검출기일 수 있다. 또 다른 예에서, 전송/수신 엘리먼트(36)는 RF 및 광 신호들 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 엘리먼트(36)는 무선 또는 유선 신호들의 임의의 조합을 전송하거나 수신하도록 구성될 수 있다는 점이 이해될 것이다.

또한, 전송/수신 엘리먼트(36)가 단일 엘리먼트로서 도 20c에 묘사되지만, 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)와 같은 임의의 유형의 적합한 메모리로부터의 정보에 액세스하거나 그 메모리에 데이터를 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, M2M 디바이스(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스할 수 있고, 그 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 본 명세서에서 설명된 일부 예들에서 교차 리소스 가입이 성공 또는 실패인지 여부(예를 들어, 가입 셋업, 통지들 수신, 시간 윈도우 업데이트 등)에 응답하여 디스플레이 또는 표시자들(42) 상의 조명 패턴들, 이미지들 또는 색상들을 제어하거나, 아니면 교차 리소스 가입 및 관련된 구성요소들의 상태를 표시하도록 구성될 수 있다. 디스플레이 또는 표시자들(42) 상의 제어 조명 패턴들, 이미지들 또는 색상들은 본 명세서에서 도시되거나 논의된 도면들(예를 들어, 도 7 내지 도 19 등)에서의 방법 흐름들 또는 구성요소들 중 임의의 것의 상태를 반영할 수 있다. 교차 리소스 가입의 메시지들 및 절차들이 본 명세서에 개시되어 있다. 이러한 메시지들 및 절차들은 사용자들이 입력 소스(예로서, 스피커/마이크로폰(38), 키패드(40) 또는 디스플레이/터치패드(42))를 통해 관련 리소스들을 요청하고, 특히 디스플레이(42) 상에 표시될 수 있는 리소스들의 교차 리소스 가입 정보를 요청, 구성 또는 질의하게 하기 위한 인터페이스/API를 제공하도록 확장될 수 있다.

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

프로세서(32)는 또한 GPS 칩셋(50)에 결합될 수 있으며, 이는 M2M 디바이스(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된다. M2M 디바이스(30)는 본 명세서에 개시된 정보와 일관성을 유지하면서 임의의 적합한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 점이 이해될 것이다.

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

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

도 20d는 예를 들어 도 20a 및 도 20b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예로서, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고, 소프트웨어가 어디서든, 또는 무슨 수단에 의하든 저장되거나 액세스되는 그러한 소프트웨어의 형태일 수 있는 컴퓨터 판독가능한 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 행하게 하도록 CPU(central processing unit)(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 지칭되는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 CPU(91)를 보조하는, 주요 CPU(91)와는 별개인, 임의적인 프로세서이다. CPU(91) 또는 코프로세서(81)는 복수의 타겟 리소스들과 관련된 하나 이상의 기준을 충족시키는 것에 기반하여 통지를 생성하는 것과 같이 교차 리소스 가입을 위한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

동작에 있어서, 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)은 컴퓨팅 시스템(90)을 도 20a 및 도 20b의 네트워크(12)와 같은 외부 통신 네트워크에 접속시키는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

본 명세서에서 설명된 시스템들, 방법들 및 프로세스들 중 임의의 것 또는 모두가 컴퓨터 판독가능한 저장 매체 상에 저장된 컴퓨터 실행가능한 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있고, 명령어들은 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스 등과 같은 머신에 의해 실행되는 경우, 본 명세서에서 설명된 시스템들, 방법들 및 프로세스들을 수행 또는 구현하는 것으로 이해된다. 구체적으로, 위에 설명된 단계들, 동작들 또는 기능들 중 임의의 것이 이러한 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독가능한 저장 매체는 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 모두를 포함하지만, 이러한 컴퓨터 판독가능한 저장 매체는 신호들을 포함하지 않는다. 본 명세서의 설명으로부터 명백한 바와 같이, 저장 매체는 35 U.S.C. §101(United States Code, Title 35, Section 101)에 의거하여 법적 주제로 해석되어야 한다. 컴퓨터 판독가능한 저장 매체는, RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disks) 또는 다른 광학 디스크 저장소, 자기 카세트들, 자기 테이프, 자기 디스크 저장소 또는 다른 자기 저장소 디바이스들, 또는 원하는 정보를 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함한다.

도면들에 도시되는 바와 같이, 교차 리소스 가입을 위한 시스템들 및 방법들의 본 개시내용의 주제의 바람직한 방법들, 시스템들, 또는 장치들을 설명함에 있어서, 특정한 용어가 명료성을 위해 사용된다. 그러나, 청구되는 주제는 그와 같이 선택되는 특정한 용어로 제한되는 것으로 의도되는 것이 아니며, 각각의 특정한 엘리먼트가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함하는 것으로 이해되어야 한다.

본 명세서에 설명되는 다양한 기술들은 하드웨어, 펌웨어, 소프트웨어 또는, 적절한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 이러한 하드웨어, 펌웨어, 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치되는 장치들에 존재할 수 있다. 이러한 장치들은 본 명세서에서 설명되는 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 사용되는 용어들 "장치", "네트워크 장치", "노드", "디바이스", "네트워크 노드" 등은 상호 대체가능하게 사용될 수 있다. 또한, "또는"이라는 단어의 사용은 본 명세서에서 달리 규정되지 않는 한 일반적으로 포괄적인 의미로 사용된다.

본 작성된 설명은 최상의 모드를 포함하는 본 발명을 개시하고, 또한 관련 기술분야에서의 임의의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작하고 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있도록 하기 위해 예들을 사용한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 관련 기술분야의 통상의 기술자에게 떠오르는 다른 예들(예를 들어, 본 명세서에 개시된 예시적인 방법들 사이에서의 단계들의 스킵, 단계들의 결합 또는 단계들의 추가)을 포함할 수 있다. 이러한 다른 예들은, 이들이 청구항들의 문자 그대로의 표현과 상이하지 않은 구조적 엘리먼트들을 가지거나, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이가 없는 등가의 구조적 엘리먼트들을 포함하면, 청구항들의 범위 내에 있는 것으로 의도된다.

특히 본 명세서에서 설명되는 바와 같은 방법들, 시스템들 및 장치들은 교차 리소스 가입을 위한 수단을 제공할 수 있다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 교차 리소스 가입에 대한 메시지를 수신하고 - 이 메시지는 시간 윈도우 내에서 기준들을 충족시키는 복수의 타겟 리소스들의 변경이 통지될 원격 디바이스에 의한 가입 요청을 표시함 -, 원격 디바이스가 교차 리소스 가입에 대해 승인되는지를 결정하며, 교차 리소스 가입을 유지하기 위해 로컬 가입 리소스를 생성하기 위한 수단을 갖는다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 교차 리소스 가입의 승인의 표시를 포함하는 응답 메시지를 보내기 위한 수단을 갖는다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 복수의 타겟 리소스들 중 제1 리소스에 대한 가입을 요청하기 위한 수단을 가지며, 이 요청은 기준들 중 하나의 기준을 포함한다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 기준들 중 하나의 기준이 충족되었다는 통지를 수신하고, 통지를 수신하는 것에 기반하여 기준들이 충족되는지를 결정하며, 기준들이 충족되는지를 결정하는 것에 기반하여 원격 디바이스에 통지하기 위한 수단을 갖는다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 로컬 가입 리소스의 정보의 표시를 디스플레이에 게시하기 위한 수단을 갖는다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 교차 리소스 가입에 대한 메시지의 파라미터들을 디스플레이에 게시하기 위한 수단을 갖는다. 이러한 방법, 시스템, 컴퓨터 판독가능한 저장 매체 또는 장치는 시간 윈도우의 그래픽 표현 내의 기준들을 충족시키는 이벤트들을 디스플레이에 게시하기 위한 수단을 갖는다. 이 장치는 공통 서비스 엔티티를 포함할 수 있다. 타겟 리소스들 중 하나의 리소스는 원격 디바이스 상에 위치할 수 있다. 메시지는 시간 윈도우의 유형의 표시를 포함할 수 있으며, 시간 윈도우의 유형은 시리얼 시간 윈도우를 포함한다. 메시지는 시간 윈도우의 유형의 표시를 포함할 수 있다. 메시지는 기준들이 충족될 때 통지가 수신될 것으로 예상되는 타겟 리소스들의 수를 포함할 수 있다. 메시지는 복수의 타겟 리소스들에 대한 이벤트 통지 기준들의 리스트를 포함할 수 있다. 이 단락에서의 모든 조합들(단계들의 제거 또는 추가를 포함)은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

Claims

교차 리소스 가입(cross-resource subscription)을 위한 장치로서,
프로세서; 및
상기 프로세서와 결합된 메모리
를 포함하며,
상기 메모리는 실행가능한 명령어들을 포함하며, 상기 실행가능한 명령어들은, 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금,
교차 리소스 가입에 대한 메시지를 수신하는 것 - 상기 메시지는 원격 디바이스에 의한 가입 요청을 표시하고, 상기 가입은 시간 윈도우 내에서 기준들을 충족시키는 복수의 타겟 리소스들의 변경이 통지될 상기 원격 디바이스에 대한 것이며, 상기 복수의 타겟 리소스들은 상기 장치와는 상이한 하나 이상의 리소스 호스트들 상에서 호스팅됨 -,
상기 메시지에 기반하여, 상기 원격 디바이스가 상기 교차 리소스 가입을 생성할 권한을 갖는지를 결정하는 것, 및
상기 교차 리소스 가입을 생성할 권한을 갖는 것에 기반하여, 상기 교차 리소스 가입을 위한 로컬 가입 리소스를 생성하는 것을 포함하는 동작들을 수행하게 하는 교차 리소스 가입 장치.
제1항에 있어서,
상기 메시지는 상기 복수의 타겟 리소스들에 대한 이벤트 통지 기준들의 리스트를 포함하는 교차 리소스 가입 장치.
제1항에 있어서,
상기 메시지는 상기 기준들이 충족될 때 통지가 수신될 것으로 예상되는 상기 복수의 타겟 리소스들의 수를 포함하는 교차 리소스 가입 장치.
제1항에 있어서,
상기 메시지는 상기 시간 윈도우의 유형의 표시를 포함하는 교차 리소스 가입 장치.
제1항에 있어서,
상기 메시지는 상기 시간 윈도우의 유형의 표시를 포함하며, 상기 시간 윈도우의 유형은 슬라이딩 시간 윈도우를 포함하는 교차 리소스 가입 장치.
제1항에 있어서,
상기 동작들은 교차 리소스 가입의 승인의 표시를 포함하는 응답 메시지를 보내기 위한 명령어들을 제공하는 것을 더 포함하는 교차 리소스 가입 장치.
삭제
제1항에 있어서,
상기 동작들은 상기 복수의 타겟 리소스들 중 제1 리소스에 대한 가입 요청을 제공하는 것을 더 포함하며, 상기 요청은 상기 기준들 중 하나의 기준을 포함하는 교차 리소스 가입 장치.
제8항에 있어서,
상기 동작들은,
상기 기준들 중 하나의 기준이 충족되었다는 통지를 수신하는 것,
상기 통지를 수신하는 것에 기반하여 상기 기준들이 충족되는지를 결정하는 것, 및
상기 기준들이 충족되는지를 결정하는 것에 기반하여 상기 원격 디바이스에 통지하는 것을 더 포함하는 교차 리소스 가입 장치.
제1항에 있어서,
상기 장치는 공통 서비스 엔티티를 포함하는 교차 리소스 가입 장치.
교차 리소스 가입을 위한 방법으로서,
M2M 엔티티(machine-to-machine entity)에 의해, 교차 리소스 가입에 대한 메시지를 수신하는 단계 - 상기 메시지는 원격 디바이스에 의한 가입 요청을 표시하고, 상기 가입은 시간 윈도우 내에서 기준들을 충족시키는 복수의 타겟 리소스들의 변경이 통지될 상기 원격 디바이스에 대한 것이며, 상기 복수의 타겟 리소스들은 상기 교차 리소스 가입을 위한 장치와는 상이한 하나 이상의 리소스 호스트들 상에서 호스팅됨 -;
상기 M2M 엔티티에 의해, 상기 메시지에 기반하여 상기 원격 디바이스가 상기 교차 리소스 가입을 생성할 권한을 갖는지를 결정하는 단계, 및
상기 M2M 엔티티에 의해, 상기 교차 리소스 가입을 생성할 권한을 갖는 것에 기반하여 상기 교차 리소스 가입을 위한 로컬 가입 리소스를 생성하는 단계
를 포함하는 교차 리소스 가입 방법.
제11항에 있어서,
상기 메시지는 상기 복수의 타겟 리소스들에 대한 이벤트 통지 기준들의 리스트를 포함하는 교차 리소스 가입 방법.
제11항에 있어서,
상기 메시지는 상기 기준들이 충족될 때 통지들이 수신될 것으로 예상되는 상기 복수의 타겟 리소스들의 수를 포함하는 교차 리소스 가입 방법.
제11항에 있어서,
상기 메시지는 상기 시간 윈도우의 유형의 표시를 포함하는 교차 리소스 가입 방법.
컴퓨터 프로그램을 저장하는 컴퓨터 판독가능한 저장 매체로서,
상기 컴퓨터 프로그램은, 데이터 처리 유닛에 로딩될 수 있고, 상기 컴퓨터 프로그램이 상기 데이터 처리 유닛에 의해 실행될 때 상기 데이터 처리 유닛으로 하여금 제11항 내지 제14항 중 어느 한 항에 따른 방법의 단계들을 실행하게 하도록 적응되는 컴퓨터 판독가능한 저장 매체.
삭제
삭제
삭제
삭제
삭제