KR20180038540A

KR20180038540A - 서비스 레이어에서 인루트 리소스 발견을 가능하게 하기 위한 방법들

Info

Publication number: KR20180038540A
Application number: KR1020187006966A
Authority: KR
Inventors: 로꼬 디 지롤라모; 홍군 리; 리쥔 둥; 광 루; 칭 리; 카탈리나 엠. 므라딘; 총강 왕
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2015-08-13
Filing date: 2016-08-15
Publication date: 2018-04-16
Also published as: CN108141466B; US20180234908A1; US11259232B2; JP2018529258A; EP3335402B1; CN108141466A; WO2017027869A1; KR102044642B1; JP6599546B2; EP3335402A1

Abstract

본 출원은 적어도 네트워크화된 장치에 관한 것이다. 장치는 네트워크 상의 리소스에 대한 발견 요청 메시지를 처리하기 위한 명령어들이 저장되어 있는 비일시적 메모리를 포함한다. 장치는 또한 일련의 명령어들을 수행하도록 구성된 비일시적 메모리에 작동 가능하게 결합된 프로세서를 포함한다. 하나의 명령어는 필터 기준들을 포함하는 발신자로부터의 발견 요청 메시지를 수신하는 것을 포함한다. 다른 명령어는 임의의 리소스들이 발견 요청 메시지내의 필터 기준들과 일치하는지 여부를 검사하는 것을 포함한다. 추가 명령어는 발견 응답을 준비하는 것을 포함한다. 또한, 본 출원은 네트워크 상의 리소스에 대한 발견 요청 메시지를 처리하는 방법에 관한 것이다. 본 출원은 또한 공통 서비스 엔티티의 발견을 수행하기 위한 장치 및 방법에 관한 것이다.

Description

서비스 레이어에서 인루트 리소스 발견을 가능하게 하기 위한 방법들

관련 출원에 대한 상호 참조

본 출원은 2015년 8월 13일 출원된 미국 가출원 제62/204,546호에 대한 우선권을 주장하며, 그 개시 내용은 그 전부가 본 명세서에 참조로 원용된다.

분야

본 출원은 자원 발견 아키텍처 및 프로토콜들에 관한 것이다. 특히, 본 출원은 서비스 레이어에서의 인루트 리소스 발견 프로토콜들(en-route resource discovery protocols)을 기술한다.

현재, oneM2M 발견 요청들이 발신자 - 애플리케이션 엔티티(Application Entity)(AE) 또는 공통 서비스 엔티티(Common Service Entity)(CSE) -로부터 호스팅 CSE로 전송된다. 발신자와 호스팅 CSE 사이에 위치되는 트랜짓 CSE들은 발견 요청들을 전달하는 것만 할 수 있다. 이것은 발견의 개인 정보(privacy)를 보장하긴 하지만, 그것은 트랜짓 CSE들이 발견 프로세스에 참여하는 것을 허용하지 않는다.

현재의 발견 메커니즘들은 또한 트랜짓 CSE들이 발견 요청을 처리할 수 있는 배치들/시스템들에 대한 지원이 부족하다. 결국 발신자는 리소스의 임의의 일치하는 인스턴스들을 찾거나 트랜짓 CSE들에서 모든 일치하는 리소스들을 찾도록 요청할 수 없다.

게다가, 발신자는 둘 이상의 리소스들에 기초하여 조건부 발견 요청을 할 수 없다. 심지어, 발신자는 최적의 일치하는 리소스를 찾을 수 없으며, 예를 들어, 일치하는 리소스를 갖는 다른 호스팅 CSE가 있을 수 있고, 여기서 일치하는 리소스는 서비스 레벨 홉들(service level hops)의 수에 관련하여 발신자에 더 가깝거나, 발견 요청을 다루는 처리 능력을 더 갖는 CSE에 있을 수 있다.

이러한 단점들이 현장에서 다음과 같은 문제들을 제시한다. 첫째, 발신자로부터 호스트 CSE로의 불필요한 서비스 레이어 시그널링이 있다. 둘째, 필터 기준들과 일치하는 리소스들을 발견하는 데 불필요한 대기시간이 있다. 게다가 리소스 발견에 융통성의 부족이 있다. 즉, 원래의 리소스 및 안내된 리소스 둘 다를 포함하여, 발견 리소스들은 발신자 또는 호스팅 CSE에만 있다.

본 요약은 상세한 설명에서 아래에 더 기술되는 개념들의 발췌를 단순화된 형태로 소개하기 위해 제공된다. 본 요약은 청구된 발명의 범위를 제한하는 것을 의도하지 않는다. 앞서 말한 필요성들은 서비스 레이어에서 인루트 리소스 발견을 용이하게하기 위한 프로세스 및 시스템에 관한 본 출원에 의해 대부분 충족된다.

본 출원의 일 양태에서, 네트워크화된 장치가 기술된다. 장치는 리소스의 발견을 수행하기 위해 명령어들이 저장되어 있는 비일시적인 메모리를 포함한다. 장치는 또한 비일시적 메모리에 작동 가능하게 결합된 프로세서를 포함한다. 프로세서는 적어도, 발견 요청 메시지를 생성하는 명령어를 수행하도록 구성된다. 또한, 프로세서는 발견 요청 메시지를 공통 서비스 엔티티에 전송하는 명령어를 수행하도록 구성된다. 또한, 프로세서는 공통 서비스 엔티티로부터 발견 응답을 수신하는 명령어를 수행하도록 구성된다.

본 출원의 다른 양태에서, 공통 서비스 엔티티에서 발견을 수행하기 위한, 컴퓨터에 의해 구현되는 방법이 기술된다. 방법은 발견 유형을 포함하는 발견 요청 메시지(discovery request message)(DRM)를 생성하는 단계를 포함한다. 방법은 또한 DRM을 CSE로 전송하는 단계를 포함한다. 이 방법은 CSE로부터 발견 응답을 수신하는 단계를 더 포함한다.

본 출원의 다른 양태는 네트워크화된 장치에 관한 것이다. 장치는 리소스에 대한 발견 요청을 처리하기 위해 명령어들이 저장되어 있는 비일시적인 메모리를 포함한다. 장치는 또한 비일시적 메모리에 작동 가능하게 결합된 프로세서를 포함한다. 프로세서는 (i) 필터 기준들을 포함하는 발신자로부터의 발견 요청 메시지를 수신하고; (ii) 임의의 리소스들이 메시지 내의 필터 기준들과 일치하는지 검사하고; 및 (iii) 발견 응답 메시지를 준비하는 명령어들을 수행하도록 구성된다.

본 출원의 또 다른 양태는 공통 서비스 엔티티에서 발견을 수행하기 위한, 컴퓨터에 의해 구현되는 방법에 관한 것이다. 방법은 발견 유형 및 필터 기준들을 포함하는 발견 요청 메시지를 발신자로부터 수신하는 단계를 포함한다. 방법은 또한 리소스가 메시지 내의 필터 기준들과 일치하는지 검사하는 단계를 포함한다. 방법은 발견 응답 메시지를 준비하는 단계를 더 포함한다.

따라서, 이하의 상세한 설명이 더 잘 이해될 수 있고, 본 기술분야에 대한 현재의 기여가 더 잘 이해될 수 있도록, 본 발명의 특정 실시예들을 오히려 광범위하게 개략적으로 설명하였다.

본 출원의 더 견고한 이해를 촉진하기 위해, 이제 유사 요소들이 유사한 숫자들로 참조되는 첨부 도면들이 참조된다. 이들 도면들은 본 출원을 제한하는 것으로 해석되어서는 안되고 단지 예시적이도록 의도된다.
도 1은 애플리케이션 레이어, 공통 서비스 레이어, 및 네트워크 서비스 레이어 사이의 관계를 예시한다.
도 2는 애플리케이션 엔티티, 공통 서비스 엔티티(CSE), 및 기저 네트워크 사이의 관계를 예시한다.
도 3은 필드 도메인(field domain)과 인프라스트럭쳐 도메인(infrastructure domain) 사이의 관계를 예시한다.
도 4는 실시예에 따른 일반적인 리소스 발견 절차를 예시한다.
도 5a는 머신 투 머신(machine-to-machine)(M2M) 또는 IoT 통신 시스템의 실시예를 예시한다.
도 5b는 M2M 서비스 플랫폼의 본 발명의 실시예를 예시한다.
도 5c는 예시적인 M2M 디바이스의 시스템 다이어그램의 본 출원의 실시예를 예시한다.
도 5d는 예시적인 컴퓨팅 시스템의 블록 다이어그램의 본 출원의 실시예를 예시한다.
도 6은 발신자, 복수의 트랜짓 CSE, 및 호스트 CSE 사이의 관계를 보여주는 실시예를 예시한다.
도 7은 실시예에 따른 발견 절차를 예시한다.
도 8은 다른 실시예에 따른 발견 요청 절차를 예시한다.
도 9는 실시예에 따라 트랜짓 CSE에서의 발견 절차들을 예시한다.
도 10은 다른 실시예에 따른 다중 홉 발견 절차들(multi-hop discovery procedures)을 예시한다.
도 11은 다른 실시예에 따른 발견 요청 절차들을 예시한다.
도 12는 다른 실시예에 따라 트랜짓 CSE에서의 발견 절차들을 예시한다.
도 13은 실시예에 따른 조건부 발견 절차들을 예시한다.
도 14는 실시예에 따른 재지향 발견 절차들(redirect discovery procedures)을 예시한다.
도 15는 또 다른 실시예에 따른 발견 프로토콜들을 예시한다.
도 16은 다른 실시예에 따른 공통 서비스 엔티티(common services entity)(CSE)에서의 향상된 발견 프로토콜들을 예시한다.
도 17은 다른 실시예에 따른 그래픽 사용자 인터페이스를 도시한다.
도 18a 및 도 18b는 그래픽 사용자 인터페이스의 예들을 예시한다.

예시적인 실시예의 상세한 설명은 본 명세서에서 다양한 도면들, 실시예들, 및 양태들을 참조하여 논의될 것이다. 상세한 설명은 가능한 구현들의 상세한 예들을 제공함에도 불구하고, 세부 사항은 예들이도록 의도되고 따라서 본 출원의 범위를 제한하지 않는다는 것이 이해되어야 한다.

본 명세서에서 "일 실시예", "실시예", "하나 이상의 실시예", "양태" 등에 대한 언급은 실시예와 관련하여 기술된 특정 특징, 구조, 또는 특성이 본 개시 내용의 적어도 일 실시예에 포함된다는 것을 의미한다. 게다가, 명세서에서의 다양한 부분들에서 용어 "실시예"는 반드시 동일한 실시예를 지칭하는 것은 아니다. 즉, 몇몇 실시예들에 의해서는 보여지지만 다른 것에 의해서는 보여지지 않을 수 있는 다양한 특징들이 기술된다.

일반적으로, oneM2M은 발신자(Originator)가 호스팅 CSE에서 지정된 필터 기준들과 일치하는 리소스들을 찾는 것을 허용하는 간단한 리소스 발견 메커니즘을 제공한다. 발신자는 사전 프로비저닝(pre-provisioning) 또는 사전의 발견 작업을 통해 호스팅 CSE를 알게 된다. 필터 기준들은 발신자가 수신된 응답을 유형, 생성 시간, 업데이트 시간, 크기, 레이블 등에 의해 조정하는 것을 허용한다. 호스팅 CSE는 일치하는 리소스들의 어드레스들의 목록으로 응답한다. 이것은 소정의 발신자 지정 최대 숫자까지 될 수 있다. 발견 요청이 호스팅 CSE로 나아갈 때, 전형적으로 다수의 트랜짓 CSE들을 횡단한다. 본 출원에 따라 트랜짓 CSE들은 발견 프로세스를 지원하는 프로토콜들로 구성되고 향상된 리소스 발견 메커니즘들을 가능하게 한다.

일 실시예에서, 발신자는 향상된 리소스 발견 메커니즘들 중 하나의 선택을 허용하고, 이러한 메커니즘들과 관련된 파라미터들을 특정하기 위해 (새로운 API를 통해) 발견 요청을 발생시킬 수 있다. 발신자는 트랜짓 CSE들이 다중 홉 발견, 조건부 발견, 또는 호스팅 CSE 재지향을 수행하도록 요청할 수 있다. 다중 홉 발견을 이용하면, 발신자는 트랜짓 CSE들에게 호스팅 CSE로의 서비스 레이어 경로 발견을 수행하거나, 처음의 'K'개의 일치 리소스들을 찾을 것을 요청할 수 있다. 별도로, 다른 실시예에서, 조건부 발견을 이용하면, 발신자는 특정 CSE에게 미리 결정된 조건이 충족되는 경우 발견 요청을 전달만 할 것을 요청할 수 있다. 다른 실시예에서, 호스팅 CSE 재지향을 이용하면, 발신자는 트랜짓 CSE들에게 더 나은 호스팅 CSE들을 제안할 것을 요청할 수 있다.

별도로, 발신자는 조건부 발견, 호스팅 CSE 재지향, 및/또는 다중 홉 발견의 상태를 시그널링하는 발견 응답을 수신할 수 있다. 다중 홉 발견에 대해, 응답은 경로 발견을 위해 발신자와 호스팅 CSE 사이의 트랜짓 CSE들뿐만 아니라 이러한 CSE들의 상태를 시그널링할 수 있다. 예를 들어, 조건부 발견에서, 응답은 발신자에게 트랜짓 CSE에서의 조건이 실패했음을 시그널링할 수 있다. 다른 예에서, 호스팅 CSE 재지향에 대해, 응답은 일치하는 리소스를 갖는 호스팅 CSE들의 목록을 발신자에게 시그널링할 수 있다.

일반적으로, 아래에 더 상세하게 논의되는 실시예들에서, 다중 홉 발견 동안, 트랜짓 CSE는 발견 요청을 처리하고 미결(pending) 발견 응답을 준비한다. 이 발견 응답은 즉시 전송되지 않는다. 추가로, 더 많은 일치하는 리소스들이 필요한 경우, 그것들은 발견 요청을 전달하고 발견 응답을 기다린다. 발견 응답을 수신하면, 그것들은 일치하는 리소스들의 목록을 추출하고, 전송 전에 미결 발견 응답에 이 목록을 추가한다. 조건부 발견에서, 트랜짓 CSE는 그것이 조건을 검사할 필요가 있는지 확인한다. 그것은 조건이 충족되는 경우에만 요청을 전달한다. 호스팅 CSE 재지향 동안, 트랜짓 CSE는 다른 호스팅 CSE들이 일치하는 리소스들을 갖는지 판정한다. 그러하면, CSE는 메트릭(metrics)들의 집합과 함께 이 정보를 발신자에게 제공한다.

정의들 및 두문자어들

아래에 표 1에서 본 출원에서 보통 사용되는 용어들 및 어구들에 대한 정의들이 제공된다. 표 2는 본 출원에서 사용된 용어들 및 어구들에 대한 두문자어들을 더 제공한다.

용어/어구	정의
안내된 리소스	원래의 리소스는 원격 CSE에 안내될(공개될) 수 있다. 원격 CSE에서의 리소스는 안내된 리소스로 알려진다. 안내된 리소스는 원래의 리소스에 연결되고 원래의 리소스의 몇몇 특성들을 유지한다.
공통 서비스 엔티티	세트 공통 서비스 기능들의 인스턴스화를 위한 oneM2M 용어.
공통 서비스 기능	서비스 능력을 위한 oneM2M 용어. 공통 서비스 레이어에 있는 능력들/기능들.
조건부 CSE	조건을 평가하고 이 조건이 통과하는 경우에만 발견 요청을 전달하는 CSE.
호스팅 CSE	다양한 리소스들을 호스팅하는 CSE(호스팅 노드에 대한 oneM2M 이름)
호스팅 노드	다양한 리소스들을 호스팅하는 M2M 서비스 노드. 호스팅된 리소스들은 다른 M2M 엔티티들에 의해 액세스되고 가입될 수 있다.
M2M 서비스 노드	M2M 통신을 위한 하나 이상의 서비스 능력을 지원하는 서비스 레이어를 호스팅하는 네트워크 노드.
중간 노드 CSE	중간 노드에 있는 CSE.
중간 노드	발신자와 호스팅 CSE 사이의 노드
원래의 리소스	CSE에서 호스팅되는 생성된 리소스. 원래의 리소스는 원격 CSE에 안내될 수 있다.
서비스 능력	서비스 레이어에 의해 지원되는 특정 유형의 서비스
서비스 레이어	M2M 애플리케이션들과 데이터 전송을 제공하는 통신 HW/SW 사이에 위치하는 소프트웨어 미들웨어 레이어. 그것은 상이한 산업 부분들에 걸쳐 M2M 애플리케이션들에 대해 보통 필요로 한 기능들을 제공한다.
수신기 CSE	요청 동작의 대상인 CSE. 예를 들어 발신자가 리소스 발견을 수행하려고 시도하고 있는 CSE.
레지스트리(registree) CSE	제2 CSE에 의해 제공되는 서비스들을 수신하기 위해 제2 CSE에 등록하는 CSE.
레지스트라(registrar) CSE	레지스트리 CSE로부터 등록 요청들을 받아들이고, 레지스트리 CSE로 서비스들을 제공하는 CSE.
원격 CSE	리소스의 호스팅 CSE가 아닌 CSE.
트랜짓 CSE	서비스 레이어 메시지의 목적지가 아니라, 오히려 수신기 CSE 쪽으로 서비스 레이어 메시지를 전달하거나 중계하기 위한 중개 CSE인 CSE.
트랜짓 노드	서비스 레이어 메시지의 목적지가 아니라, 오히려 목적지 쪽으로 서비스 레이어 메시지를 전달하거나 중계하기 위한 중개 노드인 M2M 서비스 노드.

두문자어	용어/어구
ADN	애플리케이션 전용 노드(Application Dedicated Node)
AE	애플리케이션 엔티티(Application Entity)
App	애플리케이션(Application)
ASM	애플리케이션 및 서비스 레이어 관리(Application and Service Layer Management)
ASN	애플리케이션 서비스 노드(Application Service Node)
CMDH	통신 관리 및 전달 처리(Communication Management and Delivery Handling)
CSE	공통 서비스 엔티티(Common Service Entity)
CSF	공통 서비스 기능(Common Service Function)
DIS	발견(Discovery)
DMR	데이터 관리 및 저장소(Data Management and Repository)
eDis	향상된 발견(Enhanced Discovery)
IN	인프라스트럭쳐 노드(Infrastructure Node)
IoT	사물 인터넷(Internet of Things)
IP	인터넷 프로토콜(Internet Protocol)
LOC	장소(Location)
M2M	머신-대-머신(Machine-to-Machine)
MN	중간 노드(Middle Node)
NSE	기저 네트워크 서비스 엔티티(Underlying Network Services Entity)
NSSE	네트워크 서비스 노출, 서비스 실행 및 트리거링(Network Service Exposure, Service Execution and Triggering)
REG	등록(Registration)
ROA	리소스 지향 아키텍처(Resource Oriented Architecture)
SC	서비스 능력(Service Capability)
LOC	장소(Location)
SCA	서비스 과금 및 회계(Service Charging and Accounting)
SEC	보안(Security)
SOA	서비스 지향 아키텍처(Service Oriented Architecture)
SUB	가입 및 통지(Subscription and Notification)
UDP	사용자 데이터그램 프로토콜(User Datagram Protocol)
URI	고유 리소스 식별자(Uniform Resource Identifier)

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

oneM2M 공통 서비스 레이어 및 공통 서비스 기능

oneM2M은 모든 애플리케이션들 사이에 데이터의 교환 및 공유를 위한 단일 수평 플랫폼을 정의하는 표준들의 집합을 개발해왔다. 이는 상이한 산업 부문들에 걸친 애플리케이션들도 포함한다. oneM2M은 운영 체제처럼, 상이한 기술들과 연동하기 위한 프레임워크를 제공함으로써 단일화를 촉진하는 분산된 소프트웨어 레이어를 생성하고 있다. 이 분산된 소프트웨어 레이어는 M2M 애플리케이션들과 데이터 전송을 제공하는 통신 HW/SW 사이에 위치하는 공통 서비스 레이어에서 구현된다. 이것은 예를 들어 도 1에 예시된다.

공통 서비스 레이어는 기능에 의해 공통 서비스 기능들(Common Services Functions)(CSF)로 그룹화되는 서비스들의 집합을 제공한다. 다수의 인스턴스화 된 CSF들은 공통 서비스 엔티티들(Common Services Entities)(CSE들)을 형성한다. CSE들은: 애플리케이션들(oneM2M 명명법에서 애플리케이션 엔티티들 또는 AE들); 다른 CSE들; 및 기저 네트워크들(oneM2M 명명법에서 네트워크 서비스 엔티티 또는 NSE)과 인터페이스한다.

도 2에 보여진 바와 같이, 이러한 인터페이스들에 걸쳐 흐르는 통신은 Mca, Mcc(및 Mcc'), 및 Mcn 참조점들을 통과한다. 현재 oneM2M에 의해 정의된 12개의 CSF가 또한 도 2에 보여진다. 각 CSF는 아래에 간략하게 기술된다.

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

발견 CSF: 필터 기준들에 기초하여 애플리케이션들 및 서비스들에 대한 정보를 검색한다.

등록 CSF: AE들(또는 다른 원격 CSE들)이 CSE에 등록하기 위한 기능을 제공한다. 이것은 AE들(또는 원격 CSE)이 CSE의 서비스들을 사용하는 것을 허용한다.

통신 관리/전달 처리 CSF: 다른 CSE들, AE들, 및 NSE들과의 통신들을 제공한다. 이 CSF는 어떤 시간 및 어느 통신 연결로 통신들을 전달할지를 결정하고, 필요하고 허용되는 경우 그것들이 나중에 전달될 수 있도록 통신들 요청을 버퍼링하기로 결정한다.

그룹 관리 CSF: 그룹 관련 요청들의 처리를 제공한다. M2M 시스템이 여러 디바이스들, 애플리케이션들 등에 대한 대량 작업들(bulk operations)을 지원하는 것을 가능하게 한다.

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

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

장소 CSF: AE들이 지리적 장소 정보를 획득하는 것을 가능하게 하는 기능을 제공한다.

서비스 과금 및 회계 CSF: 서비스 레이어에 대한 과금 기능들을 제공한다.

디바이스 관리 CSF: M2M 게이트웨이들 및 M2M 디바이스들 상에서 디바이스 능력들의 관리를 제공한다.

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

가입 및 통지 CSF: 이벤트에 가입하는 것을 허용하고 이 이벤트가 발생할 때 통지되는 기능을 제공한다.

기능적인 아키텍처

oneM2M은 도 3에 보여진 바와 같이 리소스 지향 아키텍처(Resource Oriented Architecture)(ROA)라 불리는 서비스 레이어 아키텍처를 개발하고 있다.

ROA에서, 아키텍처는 리소스들 주위에서(around) 개발된다. CSF들은 서비스를 수행하기 위해 이러한 리소스들 상에서 작동한다. 리소스는 CREATE, RETRIEVE, UPDATE, 및 DELETE와 같은 RESTful 메소드들을 통해 조작될 수 있는 표현을 갖는, 아키텍처내의 고유하게 어드레스 지정 가능한 요소이다. 이러한 리소스들은 고유 리소스 식별자(Uniform Resource Identifier)(URI)를 사용하여 어드레스 지정이 가능하게 된다. 리소스는 차일드 리소스(들) 및 특성(들)을 포함할 수 있다. 차일드 리소스는 페어런트 리소스와의 포함 관계를 갖는 리소스다. 결과적으로 리소스들은 기본 리소스로부터 기인하는 계층적 트리로 보여질 수 있다. 페어런트 리소스 표현은 그것의 차일드 리소스들(들)에 대한 참조를 포함한다. 차일드 리소스의 수명은 페어런트의 리소스 수명에 의해 제한된다. 각 리소스는 리소스의 정보를 저장하는 "특성들(attributes)"의 집합을 지원한다. 특성들의 집합은 모든 리소스들에 공통적인 한편, 다른 것들은 특정 리소스들에만 적용된다. 후자는 "리소스 특정 특성들"로 불린다. 하나의 CSE(호스팅 CSE로 불림)에 위치되는 특정 리소스들은 원격 CSE들에 안내될 수 있고, 이것들은 안내된 리소스들로 언급된다. 안내된 리소스들은 원래의 리소스의 특성들뿐만 아니라 그것들의 자체 특성들을 포함할 수 있다. 원래의 리소스와 안내된 리소스 사이의 동기화는 호스팅 CSE의 책임이다.

리소스 발견 CSF

리소스 발견은 예를 들어, 발신자와 같은 엔티티가 특성들 및 리소스들에 포함된 애플리케이션들 및 서비스들에 대한 정보를 검색하는 프로세스이다. 리소스 발견의 발신자는 AE 또는 CSE일 수 있고, 항상 수신기 CSE에서 루트 리소스를 대상으로 삼고 있다(루트 리소스는 검색을 시작할 리소스임). 검색 결과는 발신자에 의해 지정된 필터 기준들 및 발견 결과 유형에 의존하고, 수신기 CSE에서의 액세스 제어 정책에 예속된다. 즉, 발신자가 "DISCOVER" 액세스 권한들을 가지고 있는지 여부. 발신자는 반환된 결과들의 수를 제한하고 예를 들어, 리소스 유형, 리소스 생성 시간, 리소스 크기 등에 기초한 특정 검색 파라미터들과 일치하는 결과들만 반환하기 위해 필터 기준들을 사용할 수 있다. 검색 파라미터들의 전체 목록은 아래에 표 3에서 제공된다. 이러한 파라미터들은 복합 검색 기준들을 생성하기 위해 관계형 작업들(relational operations)에 의해 결합될 수 있다. 예를 들어, 여러 조건들이 함께 사용될 때, 상이한 조건들은 "AND" 논리 연산을 사용할 것인 한편, 동일한 조건들은 "OR" 논리 연산을 사용할 것이다.

검색 파라미터	다음과 같은 경우에 리소스가 일치함:
createdBefore	그것이 createdBefore 전에 생성된 경우
createdAfter	그것이 createdAfter 이후에 생성된 경우
modifiedSince	그것이 modifiedSince부터 수정된 경우
unmodifiedSince	그것이 unmodifiedSince부터 수정되어오지 않은 경우
stateTagSmaller	그것이 stateTagSmaller보다 더 작은 stateTag 특성을 갖는 경우
stateTagBigger	그것이 stateTagBigger보다 더 큰 stateTag 특성을 갖는 경우
expireBefore	그것이 expireBefore 전에 expirationTime 특성을 갖는 경우
expireAfter	그것이 expireAfter 이후에 expirationTime 특성을 갖는 경우
labels	그것이 labels 검색 파라미터와 일치하는 labels 특성을 갖는 경우. labels는 발견 목적들에 대한 열쇠들로 사용되는 토큰들이다.
resourceType	그것이 resourceType 유형인 경우
sizeAbove	<contentInstance> 리소스의 contentSize 특성이 sizeAbove 값과 같거나 더 큰 경우
sizeBelow	<contentInstance> 리소스의 contentSize 특성이 sizeBelow 값보다 작은 경우
contentType	<contentInstance> 리소스의 contentInfo 특성이 contentType 값과 일치하는 경우
attribute	그것이 일치하는 특성이 있는 경우. 이것들은 주로 리소스 특정 특성들을 지칭한다.

발신자는 수신기 CSE에게 반환된 결과의 형식을 나타내기 위해 발견 결과 유형을 사용할 수 있다. 2개의 옵션이 이용 가능하다. 첫 번째는 계층적 어드레스 지정이고 두 번째는 비계층적 어드레스 지정이다. 리소스 발견은 RETRIEVE 메소드를 사용하여 구현된다. 수신기 CSE가 리소스 발견 작업과 일반 검색 작업(generic retrieve operation)을 구별하는 것을 허용하기 위해, 발신자는 전용 플래그를 사용하여 이것을 수신 CSE로 시그널링한다. 일반적인 리소스 발견 절차는 도 4에서 보여진다. 각 단계는 숫자에 의해 표시된다. 먼저, 발신자는 리소스 <CSEBase>/<app01>의 특정 차일드 리소스들을 대상으로 하여, 리소스 발견 요청(단계 001)을 수신기 CSE에 발행한다. 수신기 CSE는 요청을 처리하고, 발견된 리소스들의 적절한 목록을 반환한다(단계 002). 수신기 CSE는 발견된 리소스들의 DISCOVER 특권들에 따라 발견 결과를 제한할 수 있고, 그것의 자체 로컬 정책에 따라 필터 기준들을 변경할 수 있다. 발견된 리소스들의 전체 목록이 반환될 수 없는 경우, 수신기 CSE는 발신자에게 경고할 것이다. 경고는 예를 들어 플래그를 이용할 수 있다. 리소스 발견 응답(단계 003)은 필터 기준들과 일치하는 리소스들의 어드레스들의 목록을 포함한다. 필요할 경우, 어드레스에 의해 가리켜지는 리소스들을 검색하는 것은 발신자의 책임이다.

서비스 발견

DNS-서비스 발견(DNS-Service Discovery)(DNS-SD)은 최근 몇 해에 DNS에 추가된 비교적 새로운 특징이다. DNS-SD는 DNS에 의해 제공되는 보통의 이름 확인 기능에 더하여 이용 가능한 로컬 네트워크 IP 기반 서비스들을 발견하기 위해 DNS를 사용하는 것을 지칭한다. 예를 들어 IP를 통해 액세스될 수 있는 로컬 네트워크내의 이용 가능한 프린터들에 대해 DNS-SD에 쿼리하는 것이다. 특히, 클라이언트가 찾고 있는 서비스의 유형, 예를 들어, 인쇄가 주어지면, 이 메커니즘은 클라이언트들이 표준 DNS-쿼리들을 사용하여 주어진 도메인에서 그러한 원하는 서비스의 디바이스들의 로컬 목록 (명명된 인스턴스들)을 발견하는 것을 허용한다. IETF 표준화된 솔루션의 상업적 효시는 Apple Computer에 의한 것이었고 "AppleTalk"(때때로 "Bonjour"로도 불림)로 불렸다.

일반적인 아키텍처

도 5a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 머신 투 머신(machine-to machine)(M2M), 사물 인터넷(Internet of Things)(IoT), 또는 사물 웹(Web of Things)(WoT) 통신 시스템(10)의 다이어그램이다. 일반적으로 M2M 기술들은 IoT/WoT를 위한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, 게이트웨이, 또는 서비스 플랫폼은 IoT/WoT의 구성 요소뿐만 아니라 IoT/WoT 서비스 레이어 등일 수 있다.

도 5a에 보여진 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크, 예를 들어 이더넷(Ethernet), 파이버(Fiber), ISDN, PLC 등, 또는 무선 네트워크, 예를 들어 WLAN, 셀룰러 등, 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 컨텐츠를 여러 사용자들에게 제공하는 다중 액세스 네트워크들(multiple access networks)로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 코드 분할 다중 액세스(code division multiple access)(CDMA), 시분할 다중 액세스(time division multiple access)(TDMA), 주파수 분할 다중 액세스(frequency division multiple access)(FDMA), 직교 FDMA(orthogonal FDMA)(OFDMA), 단일-캐리어 FDMA(single-carrier FDMA)(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법들을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 5a에 보여진 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭쳐 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭쳐 도메인은 엔드 투 엔드(end-to-end) M2M 배치의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 뒤에 있는 영역 네트워크들을 지칭한다. 필드 도메인은 프록시가 있는 서비스 능력 서버(Service Capability Server)(SCS)와 같은 M2M 게이트웨이들(14), 및 UE 디바이스들과 같은 단말 디바이스들(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), 직접적인 무선 링크, 및 유선(wireline)을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 5b를 참조하면, 필드 도메인에서 예시된 M2M 서비스 레이어(22)는 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18), 및 통신 네트워크(12)에 대한 서비스들을 제공한다. M2M 서비스 레이어(22)는 원하는 대로 임의의 수의 M2M 애플리케이션들, 예를 들어 트랜짓 CSE들과 같은 M2M 게이트웨이 디바이스들(14), 호스트 CSE들 및 발신자들과 같은 M2M 단말 디바이스들(18)뿐만 아니라 통신 네트워크들(12)과 통신할 수 있다는 것이 이해될 것이다. M2M 서비스 레이어(22)는 하나 이상의 서버, 컴퓨터 등에 의해 구현될 수 있다. M2M 서비스 레이어(22)는 M2M 단말 디바이스들(18), M2M 게이트웨이 디바이스들(14), 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 레이어(22)의 기능들은 다양한 방식들로 구현될 수 있다. 예를 들어, 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')는 하나 이상의 서버, 컴퓨터, 가상 머신, 예를 들어, 클라우드/컴퓨트(compute)/스토리지 팜들(storage farms) 등, 또는 유사한 것에 의해 구현될 수 있다.

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

M2M 애플리케이션들(20 및 20')은 제한적인 것은 아니지만 운송, 건강 및 웰빙(health and wellness), 커넥티드 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은 다양한 산업들에서 애플리케이션들을 포함할 수 있다. 위에서 언급된 바와 같이, 디바이스들, 게이트웨이들, 및 시스템의 다른 서버들에 걸쳐 실행되는 M2M 서비스 레이어는 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 장소 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다. 게다가, M2M 서비스 레이어는 또한 본 출원에서 논의되고 도면들에서 예시된 바와 같이 UE들, SCS들, 및 MME들과 같은 다른 디바이스들과 인터페이스하도록 구성될 수 있다.

서비스 레이어는 애플리케이션 프로그래밍 인터페이스들(Application Programming Interfaces)(API들) 및 기저 네트워킹 인터페이스들의 집합을 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어다. ETSI M2M의 서비스 레이어는 서비스 능력 레이어(Service Capability Layer)(SCL)로 불린다. SCL은 M2M 디바이스(디바이스 SCL(device SCL)(DSCL)로 불림), 게이트웨이(게이트웨이 SCL(gateway SCL)(GSCL)로 불림), 및/또는 네트워크 노드(네트워크 SCL(network SCL)(NSCL)로 불림) 내에서 구현될 수 있다. oneM2M 서비스 레이어는 공통 서비스 기능들(Common Service Functions)(CSF들)의 집합, 예를 들어 서비스 능력들을 지원한다. 하나 이상의 특정 유형의 CSF들의 집합의 인스턴스화는 상이한 유형들의 네트워크 노드들, 예를 들어 인프라스트럭쳐 노드, 중간 노드, 애플리케이션 특정 노드(application-specific node) 상에 호스팅될 수 있는 SCS와 같은 공통 서비스들 엔티티(Common Services Entity)(CSE)로 불린다.

도 5c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적인 M2M 디바이스(30)의 시스템 다이어그램이다. 도 5c에 보여진 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드/인디케이터(들)(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), 글로벌 포지셔닝 시스템(Global Positioning System)(GPS) 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 디바이스(30)는 실시예와 일치한 채로 남아있는 한편 앞서 말한 요소들의 임의의 서브컴비네이션을 포함할 수 있다는 것을 잘 알 것이다. M2M 디바이스(30)는 또한 본 출원에서 기술되고 도면들에 예시된 바와 같이 예를 들어 발신자들 및 호스팅/트랜짓 CSE들을 포함하는 다른 디바이스들과 함께 이용될 수 있다.

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

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

추가로, 송신/수신 요소(36)가 도 5c에 단일 요소로 도시되어 있긴 하지만, 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)는 랜덤 액세스 메모리(random-access memory)(RAM), 판독 전용 메모리(read-only memory)(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 식별 모듈(subscriber identity module)(SIM) 카드, 메모리 스틱, 보안 디지털(secure digital)(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 가정용 컴퓨터와 같이 M2M 디바이스(30) 상에 물리적으로 위치되지 않는 메모리로부터 정보에 액세스하고 메모리에 데이터를 저장할 수 있다.

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

또한, 프로세서(32)는 M2M 디바이스(30)의 현재 장소에 관한 장소 정보, 예를 들어 경도 및 위도를 제공하도록 구성된 GPS 칩셋(50)에 결합될 수 있다. M2M 디바이스(30)는 임의의 적절한 장소 판정 방법을 통해 장소 정보를 획득하는 한편, 실시예와 일치한 채로 있을 수 있다는 것을 잘 알 것이다.

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

도 5d는 예를 들어 도 5a 및 도 5b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록 다이어그램이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 소프트웨어의 형태일 수 있는 컴퓨터 판독 가능 명령어들에 의해 주로, 그러한 소프트웨어가 저장되거나 액세스되는 곳 어디에서나, 또는 그러한 소프트웨어가 어떤 수단에 의해 저장되거나 액세스되든 제어될 수 있다. 그러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)이 작업을 수행하게 하기 위해 중앙 처리 장치(central processing unit)(CPU)(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 퍼스널 컴퓨터들에서, 중앙 처리 장치(91)는 마이크로프로세서로 불리는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 장치(91)는 복수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가의 기능들을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개인 임의적인(optional) 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 임베디드 시맨틱 이름들을 갖는 센서 데이터에 대한 쿼리들과 같이, 임베디드 시맨틱 명명을 위한 개시된 시스템들 및 방법들과 관련된 데이터를 수신, 생성, 및 처리할 수 있다.

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

시스템 버스(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)에 의해 생성된 시각적 출력을 디스플레이하기 위해 사용된다. 그러한 시각적 출력은 텍스트, 그래픽, 애니메이션화된 그래픽, 및 비디오를 포함할 수 있다. 이것은 예를 들어 다중 홉 발견, 조건부 발견, 및 호스팅 CSE 재지향에 대한 발견 결과들을 포함할 수 있다. 디스플레이(86)는 CRT-기반 비디오 디스플레이, LCD-기반 평면 패널 디스플레이, 가스 플라즈마-기반 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)로 전송되는 비디오 신호를 생성하기 위해 필요한 전자 구성 요소들을 포함한다. 디스플레이(86)는 임베디드 시맨틱 이름들을 사용하여 파일들 또는 폴더들에 센서 데이터를 디스플레이할 수 있다. 또한, 컴퓨팅 시스템(90)은 컴퓨팅 시스템(90)을 도 5a 및 도 5b의 네트워크(12)와 같은 외부 통신 네트워크로 연결하기 위해 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

인루트 리소스 발견

본 출원의 양태에 따라, 제안된 향상된 발견 CSF 및 인루트 처리는 서비스 레이어에 부가된 이점들을 제공한다. 이것은 예를 들어 트랜짓 CSE들이 자신이 필터 기준들과 일치하는 임의의 리소스들을 갖는지 여부를 판정하는 다중 홉 발견을 포함한다. 이것은 또한 트랜짓 CSE들이 발견 요청을 전달하기 전에 조건이 충족되는지 여부를 판정하는 조건부 발견을 포함한다. 이것은 트랜짓 CSE가 필터 기준들과 일치하는 리소스들을 갖는 대체 호스팅 CSE들을 인식하고 발견 요청들을 이러한 대체 호스팅 CSE들 중 하나로 재지향시킬 수 있는 호스팅 CSE 재지향을 더 포함할 수 있다.

도 6에 예시된 바와 같은 실시예에서, 전형적인 서비스 레이어 배치가 가정될 것이다. 도 6에서, 발신자(AE 또는 CSE)(610) 및 호스팅 CSE(630)는 다수의 트랜짓 CSE들(620)에 의해 분리된다. 일 양태에서, 하나 이상의 트랜짓 CSE들은 복수의 레지스트리 CSE들을 가질 수 있다.

처리는 전형적으로 발신자에서 시작한다. 엔티티들 각각에서 향상된 발견 절차가 있다면, 어떤 향상된 발견 절차가 후속될 것인지 나타내기 위해, 단일 파라미터가 일반적으로 포함된다. 이 새 파라미터 Discovery Type은 발신자에 의해 생성된 발견 요청 메시지에 포함된다. Discovery Type은 다음 유형들의 값 중 하나 이상을 포함할 수 있다: (i) 전달(향상된 발견 절차 없음); (ii) 다중 홉 발견; (iii) 조건부 발견; 및 (iv) 호스팅 CSE 재지향. 대안적으로, Discovery Type 파라미터의 부재를 향상된 발견 절차를 사용하지 않는(즉 전달을 사용하는) 표시로서 취급할 수 있는 CSE들에서, 발신자는 발견 요청에서 Discovery Type 파라미터를 생략하고 암시적 행동에 의존할 수 있다.

CSE들에서, 새로운 discoveryType 특성이 이용될 수 있다. 여기서, 각 CSE는 향상된 발견 절차들 중 하나 이상을 임의적으로(optionally) 지원할 수 있다. 이 정보는 예를 들어 discoveryType과 같은 <CSEBase> 리소스의 특성에 포함될 수 있다. 이 특성은 지원되는 검색 절차들을 나열할 수 있다. 예를 들어 전달(향상된 발견 절차들이 없음)에 대해, CSE는 그것이 트랜짓 CSE면 호스팅 CSE 쪽으로 발견 요청을 포워딩한다. 이 특성에 대한 다른 옵션들은 예를 들어 다중 홉 발견, 조건부 발견, 및 호스팅 CSE 재지향을 포함할 수 있다.

추가로, discoveryType 특성은 CSE가 복수의 향상된 발견 메커니즘들을 동시에 수행할 수 있는지 여부를 또한 나타낼 수 있다. 예를 들어, discoveryType은 다중 홉 발견 및 조건부 발견일 수 있다. discoveryType 특성은 엔티티가 CSE에 의해 지원되는 향상된 발견 절차를 발견하는 것을 허용한다.

다른 양태에 따라, 각각의 CSE에서의 액세스 제어는 DISCOVER 작업에 대한 기존의 액세스 제어 규칙들에 기초할 수 있다. 즉, 리소스에 대한 DISCOVER 특권들이 있는 발신자는 향상된 발견 절차들에 대한 자동 특권들을 갖는다. 대안적으로, 더 많은 융통성을 제공하기 위해, 각각의 향상된 발견 유형에 대해 특정 발견 권한들이 유지될 수 있다. 이것은 개별 규칙들이 다중 홉 발견, 조건부 발견, 및 호스팅 CSE 재지향에 적용되는 것을 허용할 것이다. 예를 들어 3개의 추가 accessControlOperations가 정의될 수 있다: (i) DISCOVER_MULTIHOP은 리소스를 발견하고 요청을 전달하는 특권이다; (ii) DISCOVER_CONDITIONAL은 조건부로 리소스를 발견하는 특권이다; 및 (iii) DISCOVER_REDIRECT는 호스팅 CSE를 재지향시키는 특권이다.

다음으로, 도 7에 예시된 바와 같은 발신자, 트랜짓 CSE, 및 호스팅 CSE 사이의 전체적인 처리가 논의될 것이다. 일반적으로, 원하는 discoveryType을 명시하는 것은 발신자의 책임이다. 예를 들어, 발신자가 특정 호스팅 CSE에 있는 특정 리소스에 관심이 있는 경우, 그것은 아마 향상된 절차 없이 발견 요청을 발행할 것이다. 대안적으로, 향상된 절차들이 필요한 경우, 다수의 옵션들이 발신자에게 이용 가능하다. 발신자는 향상된 발견을 수행하도록 요청된 CSE 유형들을 명시할 수 있다. 예를 들어, 발신자는 향상된 발견이 오직: (i) MN-CSE들(ASN-CSE들이 아님); (ii) 특정 클래스 또는 계층의 CSE들(CSE들이 지정된 계층 또는 클래스 유형을 갖는다고 가정한다); (iii) 중요한 처리(높은 메모리, 낮은 활동 등)를 갖는 CSE들; 또는 (iv) 제공된 목록 내의 CSE에서만 발생하는 것을 요청할 수 있다. 추가의 실시예에 따라, CSE는 오직: (i) 그것이 발신자에 의해 요청되고; (ii)그것이 요청된 확장된 발견 절차를 지원하고; (iii) 발신자가 향상된 절차를 수행할 액세스 권한들을 갖는 경우에만 향상된 발견 절차를 수행할 것이다.

다중 홉 발견 동안, 발신자는(호스팅 CSE를 향한 모든 홉에서) 각각의 트랜짓 CSE에게 그것이 발견 필터 기준들과 일치하는 임의의 리소스를 소유하고 있는지 여부를 검사하고 그 결과들을 발신자에게 반환할 것을 요구하는 발견 요청을 발행할 수 있다. 영향을 받는 엔티티들 각각에서의 처리는 아래에 기술된다.

도 8은 발신자에서 다중 홉 발견 요청을 다루는 작업들을 예시한다. 각 단계는 로마 숫자, 예를 들어 1, 2 등에 의해 표시된다. 단계 1에서, 발신자는 발견 요청을 발행한다. 예시적인 실시예에서, 이 요청은 RETRIEVE 메소드를 통해 전송된다. 그러나, 그것은 전용 방법을 통해, 또는 UPDATE, CREATE, 또는 다른 유사한 메소드를 통해 전송될 수 있다. 요청은 다음 파라미터들을 포함할 수 있다.

To: Hosting CSE 상에서 발견이 시작되는 곳의 루트의 호스팅 CSE 어드레스.

Filter Criteria: 검색을 위한 필터 기준들 및 예상되는 반환 결과.

Discovery Result Type: 반환된 발견 결과들의 임의적 형식.

discoveryType: 트랜짓 CSE들에게 발견 요청을 처리할 것을 요청하는 다중 홉 발견.

MultiHop Discovery SubType: 발신자의 의도에 관해 트랜짓 CSE들 및 호스팅 CSE에 통지한다.

routeDiscovery: 발신자가 호스팅 CSE로의 서비스 레이어 라우팅 경로를 찾고 싶어한다는 것을 시그널링한다. 서비스 레이어 라우팅 경로는 발신자와 호스팅 CSE 사이의 등록 체인을 따르는 특수 라우팅 경로이고, 요청이 트랜짓 CSE들을 횡단할 때 따르게 되는 서비스 레이어 홉들을 보여준다. 예를 들어, 발신자는 CSE1에 등록되고, CSE1은 CSE2에 등록되고, CSE2는 IN-CSE에 등록된다. 서비스 레이어 라우팅 경로는 발신자→CSE1→CSE2→IN-CSE이다. 트랜짓 CSE들은 필터 기준들과 일치하는 리소스들을 검색할 것을 요구받는 것이 아니라, 발신자가 그 자신과 지정된 호스팅 CSE 사이의 서비스 레이어 라우팅 경로를 유지할 수 있도록 Response를 반환할 것을 요구받는다.

findUptoKResourcesDiscovery: 발신자가 필터 기준들에 일치하는 'K'개까지의 리소스들을 원하고 'K'개의 리소스들이 발견되면 트랜짓 CSE들이 발견 요청의 전달을 중단해야 한다는 것을 시그널링한다.

findUptoNHopsResourcesDiscovery: 발신자가 발신자의 N개의 서비스 레이어 홉들 내에서 필터 기준들과 일치하는 리소스들을 찾고 싶어한다는 것을 시그널링한다. N 번째 홉을 처리하는 CSE는 발견 요청의 전달을 중단해야 한다.

findAllResourcesDiscovery: 발신자가 호스팅 CSE 내에서, 그리고 발신자와 호스팅 CSE 사이의 임의의 트랜짓 CSE내에서 필터 기준들과 일치하는 모든 리소스들을 원한다는 것을 시그널링한다.

Aggregated Response: 온(on)/오프(off)로 설정한다. 온이면, 트랜짓 CSE들에게 발신자쪽으로 응답을 전송하기 전에 발견 결과를 집계할 것을 통지한다. 오프이면, 트랜짓 CSE들에게 그들이 필터 기준들과 일치하는 리소스들을 찾으면 발견 결과들을 발신자쪽으로 전송할 것을 통지한다.

matchingResourceLimit 파라미터(필터 기준들에 포함될 수 있음)는 발신자가 찾고 있는 일치하는 리소스들의 수(위에서 기술된 바와 같은 'K'의 값)를 명시한다.

hopLimit 파라미터(필터 기준들에 포함될 수 있음)는 발견 요청에 대한 서비스 레이어 홉들의 최대 수(위에서 기술된 바와 같은 N의 값)를 명시한다.

도 8의 단계 2에 따라, 발신자는 발견 응답 메시지들을 기다린다. discoveryType이 multiHop Discovery로 설정되고 Aggregated Response가 오프로 설정된 경우, 발신자는 복수의 응답 메시지들(트랜짓 CSE들로부터 및 호스팅 CSE로부터)을 수신할 수 있다. 발신자는 응답들을 초기 발견 요청과 상호 참조하기 위해 요청 식별자를 사용한다. 단계 2a에서, MultiHop Discovery SubType이 routeDiscovery로 설정된 경우 발신자는 어드레스들(또는 서비스 레이어에서의 ID들)을 추출하고, 그 자신과 호스팅 CSE 사이의 CSE 어드레스들의 목록을 생성한다. 그러나, 단계 2b에 보여진 바와 같이, MultiHop Discovery SubType이 routeDiscovery가 아닌 경우, 발신자는 반환된 모든 결과들의 업데이트된 목록을 유지한다.

다음 단계 3에서, 발신자는 (i) 호스팅 CSE로부터 응답을 수신한 때; 또는 (ii) 파라미터 matchingResourceLimitReached = TRUE와 함께 트랜짓 CSE로부터 응답을 수신한 때. -이것은 필터 기준들과 일치하는 원하는 수의 리소스들이 발견되었고 발견 요청이 포워딩되는 것을 중지했다는 것을 발신자에게 시그널링함-; (iii) 파라미터 hopLimitReached = TRUE와 함께 CSE로부터 응답을 수신한 때, 발견 절차를 끝낼 수 있다. 이것들은 발신자에게 원하는 홉들의 수가 발견 요청에 의해 횡단되었다는 것을 시그널링한다.

다른 실시예에서, 발신자는 2개의 별개의 목록들을 임의적으로 유지할 수 있다. 하나는 원래의 리소스들용이고, 하나는 안내된 리소스들용이다. 그것은 안내된 리소스들 전부(또는 선택된 수)의 원래의 리소스 어드레스들을 검색하기로 결정할 수 있다. 그것이 안내된 리소스 목록 상의 리소스가 원래의 리소스 목록 상의 리소스를 가리키고 있다고 판정하면, 그것은 안내된 리소스를 중복으로 표시하거나 그것은 안내된 리소스를 삭제하기로 결정할 수 있다.

다중 홉 발견을 위한 트랜짓 CSE에서의 절차

다른 실시예에 따라, 도 9는 Aggregated Response = On인 경우 트랜짓 CSE에서의 절차들을 예시한다. 이것은 트랜짓 CSE에서의 발견 요청 응답 메시지가 발신자로 즉시 반송되지 않는다는 것을 의미한다. 단계 1에 따라, MultiHop Discovery SubType이 routeDiscovery인지에 대한 검사가 이루어진다. 그렇다면, 트랜짓 CSE는 단계 2에서 다음 파라미터들을 포함하지만 이에 제한되지 않는 발견 응답 메시지를 준비한다: (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; 및 (iii) Content: 대상 CSE의 CSE 어드레스. 임의적으로, 트랜짓 CSE는 이 트랜짓 CSE와 관련된 다른 정보, 예를 들어 로딩 조건, 액세스 제어 등을 추가할 수 있다. 메시지는 후속하여 단계 17에서 발신자에게 전송된다.

한편, 단계 1에서 쿼리가 네거티브(negative)로 판정되는 경우, 트랜짓 CSE는 발견을 시작할 로컬 루트 리소스를 결정한다(단계 2). 이것은 트랜짓 CSE 루트, 예를 들어 /CSEBase로 설정될 수 있다. 다음으로, 트랜짓 CSE는 필터 기준들과 일치하는 임의의 리소스들이 있는지 검사한다(단계 3). 쿼리에 대한 응답이 아니오(no)인 경우, 트랜짓 CSE(CSE_A)는 그것이 호스팅 CSE에 등록된 경우에는 호스팅 CSE 쪽으로 요청을 전달하거나; 또는 트랜짓 CSE(CSE_A)가 등록된 다른 트랜짓 CSE(CSE_B)에게 요청을 전달한다(단계 6).

한편, 쿼리에 대한 응답이 예(yes)인 경우, 트랜짓 CSE는 얼마나 많은 결과들을 반환할지를 결정한다(단계 4). 여기서, 트랜짓 CSE는 Multihop Discovery SubType이 findUptoNHopResourcesDiscovery와 같은지 검사한다. 그렇다면, 트랜짓 CSE는 홉 카운트(발견 요청내의 hopLimit == 1)에 기초하여 자신이 마지막 CSE인지 검사한다(단계 5). 검사가 false인 경우, 트랜짓 CSE는 다음 파라미터들을 갖는 응답 메시지를 준비한다(단계 8): (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; (iii) Content: 발견된 리소스들의 목록; 및 (iv) hopLimitReached= FALSE. 트랜짓 CSE는 hopLimit을 1씩 줄임으로써 발견 요청 메시지를 수정한다. 다음으로, 트랜짓 CSE는 발견 요청 메시지를 호스팅 CSE 쪽으로 전달한다. 그 후, 그것은 발견 응답 메시지의 집계를 기다리는 단계 15를 진행한다.

단계 5의 쿼리에 대한 대답이 예인 경우, 트랜짓 CSE는 다음 파라미터들과 함께 응답 메시지를 준비한다(단계 9): (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; (iii) Content: 발견된 리소스들의 목록; 및 (iv) hopLimitReached= TRUE. 여기서, 트랜짓 CSE는 발견 요청 메시지를 전달하지 않는다. 트랜짓 CSE는 그것이 발견 요청 응답 메시지를 발신자에게 전송하는 단계 17로 진행한다.

한편, 단계 4에서 쿼리에 대한 응답이 아니오인 경우, 트랜짓 CSE는 MultiHop Discovery SubType이 findUptoKResourcesDiscovery 또는 findAllResourcesDiscovery인지를 검사한다(단계 10). 그것이 전자인 경우 트랜짓 CSE는 L개의 일치하는 리소스들의 목록을 갖고, 발견 요청에서 지정된 matchingResourceLimit은 'K'이다. 트랜짓 CSE는 L < K인지 검사한다(단계 11). L < K인 경우(단계 12), 트랜짓 CSE는 다음 파라미터들을 갖는 응답 메시지를 준비한다: (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; (iii) Content: L개의 발견된 리소스들의 목록; (iv) matchingResourceLimitReached= FALSE. 다음으로, 트랜짓 CSE는 matchingResourceLimit을 발견된 리소스들의 수만큼 감소시켜(matchingResourceLimit = matchingResourceLimit - L) 발견 요청 메시지를 수정한다. 트랜짓 CSE는 발견 요청 메시지를 호스팅 CSE 쪽으로 전달한다. 다음으로, CSE는 발견 응답 메시지의 집계를 기다린다(단계 15).

그렇지 않은 경우, 단계 11에서 쿼리에 대한 응답이 아니오인 경우, 트랜짓 CSE는 다음 파라미터들과 함께 응답 메시지를 준비한다(단계 13): (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; (iii) Content: K개의 발견된 리소스의 목록; 및 (iv) matchingResourceLimitReached= TRUE. 트랜짓 CSE는 발견 요청 메시지를 전달하지 않고, 그것이 발견 응답 메시지를 발신자에게 전송하는 것으로 진행할 수 있다(단계 17).

단계 10에 대한 쿼리에 대한 응답이 findAllResourcesDiscovery인 경우 단계 14로 진행한다. 여기서, 트랜짓 CSE는 다음 파라미터들과 함께 응답 메시지를 준비한다: (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; (iii) Content: 발견된 리소스들의 목록; 및 (iv) matchingResourceLimitReached= FALSE. 트랜짓 CSE는 발견 요청 메시지를 계속하여 호스팅 CSE 쪽으로 전달한다. 다음으로, 트랜짓 CSE는 단계 15에서 발견 응답 메시지를 기다릴 수 있다. 발견 응답의 수신 시, 트랜짓 CSE는 요청에 대한 응답을 상호 참조하기 위해 요청 ID를 사용한다(단계 16). 다음으로, 수신된 응답으로부터 결과들을 추출하고, 단계(7, 8, 12, 또는 14)에서 준비된 발견 응답으로 이 정보를 집계한다. 마지막으로, 트랜짓 CSE는 그것의 처리를 종료한다(단계 18).

다중 홉 발견을 위한 호스팅 CSE에서의 절차

도 10에 예시된 다른 실시예에 따라, 발견 요청의 수신 시 호스팅 CSE에서의 작업이 기술된다. 단계 1에서, 호스팅 CSE는 MultiHop Discovery SubType이 무엇인지 검사한다. 그것이 RouteDiscovery인 경우, 파라미터들을 갖는 발견 응답 메시지(호스팅 CSE의 어드레스를 가짐)를 생성하는 단계 7로 진행한다. 메시지는: To: 발신자의 ID; From: 호스팅 CSE의 ID; 및 Content: 호스팅 CSE의 CSE 어드레스를 포함한다. 임의적으로, 호스팅 CSE는 이 호스팅 CSE와 관련된 다른 정보, 예를 들어 로딩 조건, 액세스 제어 등을 추가할 수 있다. 다음으로, 발견 응답 메시지가 전송된다(단계 8). 그 후, CSE는 그것의 처리를 종료한다(단계 9).

한편, 단계 1로부터, 발견 서브타입이 findAllResourcesDiscovery인 경우, 단계 4로 진행한다. 단계 4에서, 호스팅 CSE는 다음의 파라미터들을 갖는 발견 응답 메시지를 생성한다: To: 발신자의 ID; From: 호스팅 CSE의 ID; 및 Content: 필터 기준들과 일치하는 모든 리소스들의 어드레스. 다음으로, 프로세스는 위에서 논의된 바와 같이 단계 8로 진행한다.

대안적으로, 단계 1로부터, 발견 서브타입이 findUptoKResourcesDiscovery인 경우, 프로세스는 호스팅 CSE가 필터 기준들과 일치하는 임의의 리소스들이 있는지 검사하는 단계 2로 이동한다. 그렇지 않은 경우, 위에서 기술된 바와 같은 단계 7로 이동한다. 예인 경우, 그것은 얼마나 많은 결과들을 반환해야 하는지 판정한다(단계 3). 구체적으로, 호스팅 CSE는 발견 요청에서 지정된 matchingResourceLimit 및 L개의 일치하는 리소스들의 목록을 갖는다. L < K인 경우, 프로세스는 단계 5로 진행한다. 단계 5에서, 호스팅 CSE는 다음 파라미터들을 갖는 응답 메시지를 준비한다: To: 발신자의 ID; From: 호스팅 CSE의 ID; Content: L개의 발견된 리소스들의 목록; matchingResourceLimitReached= TRUE. 단계 5로부터, 프로세스는 위에서 기술된 바와 같은 단계 8로 진행하고, 다음으로, 위에서 기술된 바와 같은 단계 9로 진행한다.

대안적으로, 단계 3으로부터의 응답이 아니오인 경우, 프로세스는 단계 6으로 진행한다. 단계 6에서, 호스팅 CSE는 다음 파라미터들을 갖는 응답 메시지를 준비한다: To: 발신자의 ID; From: 호스팅 CSE의 ID; Content: K개의 발견된 리소스들의 목록; matchingResourceLimitReached= TRUE. 다음으로, 단계 8로 진행한다.

다중 홉 발견 절차는 대안들을 가질 수 있다. 발신자는 다중 홉 처리를 수행해야 하는 트랜짓 CSE들을 구체적으로 나열할 수 있다. 트랜짓 CSE가 이 목록에 있지 않은 경우, 발견 요청을 호스팅 CSE 쪽으로 전달하는 것으로 되돌아갈 수 있다.

다중 홉 발견 콜 흐름

도 11에 보여진 바와 같은 다른 실시예에 따라, 각각의 엔티티들에서의 처리 및 이들 사이의 시그널링이 기술된다. 콜 흐름은 발신자가 지정된 필터 기준들과 일치하는 처음 3개의 리소스들을 찾고 있다고 가정한다. 이 기준들과 일치하는 리소스들은 트랜짓 CSE 2(2x)에, 트랜짓 CSE 3(2x)에, 및 IN-CSE(1x)에 위치된다. 보여지지는 않았지만, 발신자가 집계된 응답을 요청했다는 것이 가정된다(Aggregated Response = On).

단계 1에서, 발신자는 IN-CSE 쪽으로 발견 요청을 발행하고: Discovery Type = multihopDiscovery; MultiHop Discovery SubType= findUptoKResourcesDiscovery; matchingResourceLimit = 3을 명시한다

이 실시예에서, 단계 2에서, 트랜짓 CSE1에서, 일치하는 리소스가 존재하지 않고, 그래서 발견 요청은 IN-CSE 쪽으로 전달된다. 단계 3에서, 트랜짓 CSE2에서, 2개의 일치하는 리소스들이 존재한다. 트랜짓 CSE는 발견 요청을 업데이트하고 (matchingResourceLimit을 1로 감소시킴) 그것을 IN-CSE 쪽으로 전달한다. 또한, 트랜짓 CSE2는 미결 발견 응답(2개의 일치하는 리소스들의 어드레스를 가짐)을 준비하고, 다음으로, 발견 응답을 기다린다.

단계 4에서, 트랜짓 CSE3에서, 2개의 일치하는 리소스들이 존재하나, 요청은 오직 1개의 더 많은 리소스를 찾고 있다. 트랜짓 CSE3은 발견 응답 (하나의 일치하는 리소스의 어드레스를 가짐)을 준비하고, 다음 중 하나 이상을 명시하며 발신자 쪽으로 발견 응답을 전송한다: content = 일치하는 리소스의 어드레스; 및 matchingResourceLimitReached = TRUE. 발견 요청은 IN-CSE 쪽으로 전달되지 않는다는 점에 유의해야 한다.

단계 5에서, 트랜짓 CSE2에서, 수신된 발견 응답으로부터의 결과들은 (단계 3으로부터의) 미결 발견 응답에 첨부되고, 미결 발견 응답은 발신자 쪽으로 전송된다. 세부 사항은: content = 일치하는 리소스의 어드레스들의 목록(트랜짓 CSE2로부터 2 및 트랜짓 CSE3으로부터 1); 및 matchingResourceLimitReached = TRUE를 포함하나 이에 제한되지 않는다. 단계 6에서, 트랜짓 CSE1에서 미결 발견 응답이 없고, 그래서 수신된 발견 응답은 발신자 쪽으로 전달된다.

조건부 발견

본 출원의 다른 양태에 따라, 발신자는 호스팅 CSE 쪽으로 발견 요청을 발행할 수 있다. 그러나, 그것은 다른 리소스에 대한 조건이 충족되는 경우에만 수행될 필요가 있을 수 있다. 조건은 "조건부 CSE"로 불리는 CSE에서 검사된다. 아래의 상세한 설명은 단일 조건에 적용되지만, 처리는 임의의 수의 조건들을 포함하도록 일반화될 수 있다. 영향을 받는 엔티티들 각각에서의 처리가 아래에 기술된다.

일 실시예에서, 전제 조건으로서, 발신자는 조건이 검사될 리소스의 어드레스를 안다. 이것은 사전의 발견 절차에 의해 획득되어 있을 수 있다. 단계 1에 따라, 발신자는 발견 요청을 발행한다. 이것은 전용 메소드를 통해, 또는 RETRIEVE, UPDATE, CREATE, 또는 다른 유사한 메소드를 통해 전송될 수 있다. 요청은 다음 파라미터들 중 하나 이상을 포함할 수 있다: (i) To: 호스팅 CSE 상에서 발견이 시작되는 루트의 어드레스; (ii) Filter Criteria: 검색을 위한 필터 기준들 및 예상되는 반환되는 결과; (iii) Discovery Result Type: 반환되는 발견 결과들의 임의적인 형식; (iv) 트랜짓 CSE들에게 그것들이 조건부 트랜짓 CSE인 경우 발견 요청을 처리할 것을 요청하는 Discovery Type = conditionalDiscovery; (v) ConditionedOn: 조건이 검사되어야 하는 리소스의 어드레스; (vi) ConditionCriteria: 조건이 검사될 리소스에 대한 기준들 -기준들은 메모리 크기, 리소스 유형, 배터리 상태 등에 기초할 수 있음-; 및 (vii) ConditionPersistence: 조건부 트랜짓 CSE가 조건에 따라 포기하기 전에 얼마나 오래 대기해야 하는지. 0의 값은 발견 요청의 수신 시에만 검사가 수행되어야 함을 나타낸다. 0이 아닌 값은, 조건부 트랜짓 CSE가 발견 요청을 전달하기 전에 조건이 충족될 때까지 대기하는 것이 허용됨을 나타낸다. CSE는 ConditionPersistence 시간 동안, 또는 발견 요청이 만료될 때까지 기다리는 것이 허용된다.

발신자가 발견 응답 메시지를 기다리는 단계 2에 따라. 발신자는 ConditionalDiscoveryStatus = FAIL인 조건부 트랜짓 CSE로부터 응답을 수신한 때 검색 절차를 끝낼 수 있다. 이것은 발신자에게 조건이 충족되지 않았고 조건부 발견과 일치하는 리소스들이 없다는 것을 시그널링한다. 또한, 그것은 호스팅 CSE로부터 응답을 수신하는 경우, 발견 요청을 끝낼 수 있다. 이것은 조건부 트랜짓 CSE에서 조건이 충족되었고 반환된 결과들은 호스팅 CSE에서의 필터 기준들과 일치한다는 것을 발신자에게 시그널링한다.

도 12는 발견 요청의 수신 시 트랜짓 CSE에서의 작업들을 예시한다. 단계 1에서, CSE는 트랜짓 CSE가 조건부 CSE인지(트랜짓 CSE는 발견 요청의 ConditonedOn 파라미터내의 CSE에 대응하는지) 여부를 검사한다. 예인 경우, 프로세스는 단계 3으로 진행할 것이다. 그렇지 않으면, 프로세스는 요청을 호스팅 CSE 쪽으로 계속 전달하기 위해 단계 2로 진행한다. 단계 2에 따라, 트랜짓 CSE(CSE_A)는 그것이 호스팅 CSE에 등록된 경우에는 요청을 호스팅 CSE로 전달하거나, 대안적으로 트랜짓 CSE (CSE_A)가 등록된 다른 트랜짓 CSE(CSE_B)로 요청을 전달한다. 다음으로, 그것은 단계 10으로 진행한다.

다음으로, 단계 3에서, 프로세스는 발견 요청의 ConditonedOn 파라미터에 의해 가리켜진 리소스에 대해 ConditionCriteria가 충족되는지 여부를 검사한다(단계 3). 예인 경우, 그것은 단계 2로 이동한다. 그렇지 않으면, 프로세스는 단계 4로 이동한다. 단계 4에서: ConditionPersistence가 0인지 검사한다. 예인 경우, 다음의 파라미터들을 갖는 발견 응답 메시지를 준비하는 단계 5로 이동한다: (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; 및 (iii) Content: 비어 있는 ConditionalDiscoveryStatus = FAIL. 다음으로, 프로세스는 트랜짓 CSE 처리가 종료되는 단계 10으로 진행한다.

단계 4로부터, 대답이 아니오인 경우, 그것은 Persistence Timer를 시작하는 단계 6으로 이동한다. 이 타이머는 요청된 조건에 대해 포기하기 전에 트랜짓 CSE가 얼마나 오래 대기해야 하는지 나타낸다. 대안적으로, 트랜짓 CSE는 또한 호스팅 CSE쪽으로, 그러나 파라미터 ConditionalDiscoveryStatus = FAIL와 함께, 발견 요청을 전달할 수 있다. 이것은 도면에 보여지지 않는다.

단계 7은 단계 6으로부터 진행한다. 여기서, ConditionPersistence 시간 동안 조건이 충족되는지에 대한 검사가 이루어진다. 예인 경우, 단계 8로 이동한다. 여기서 persistence timer는 중지된다. 다음으로, 발견 요청을 호스팅 CSE 쪽으로 전달하는 단계 2로 진행한다. 대안적으로, 단계 6에서 시작된 persistence timer가 만료되는 경우, 단계 5로 이동한다. 대안적으로, 발견 요청이 만료되는 경우 단계 9로 이동한다.

대안적으로, 단계 7로부터, 발견 요청이 만료되는 경우, Persistence Timer (단계 9)를 중단한 다음, 단계 5로 이동한다. 또한, 처리는 단계 10에서 종료된다.

실시예에서, 트랜짓 CSE가 조건부 CSE인 경우, 그것은 호스팅 CSE로 전달된 발견 요청내에 조건이 성공적이었다는 표시를 포함시킬 수 있다(보여지지 않음). 조건부 CSE는 또한 조건이 충족될 때 발신자로 발견 응답을 전송할 수 있다(보여지지 않음). 발신자는 이것을 자신의 초기 쿼리로부터의 발견 응답이 진행 중이라는 표시로서 사용할 수 있다.

조건부 발견을 위한 호스팅 CSE에서의 절차

호스팅 CSE에서의 절차는 아래에 기술된 바와 같다. 이 절차는 조건부 트랜짓 CSE가 조건이 충족되는 경우에만 발견 요청을 전달한다는 것을 가정한다. 그러한 경우에서, 호스팅 CSE에서 수신된 발견 요청은 파라미터 ConditionalDiscoveryStatus = PASS를 가질 수 있다. 단계 1에 따라, 호스팅 CSE는 필터 기준들과 일치하는 리소스들을 검색한다. 그것은 검색 결과들에 기초하여 발견 응답을 준비하고 단계 2로 진행한다. 여기서, 호스팅 CSE는 발견 응답 메시지를 전송한다. 프로세스를 종료시키는 단계 5로 이동한다.

대안적으로, 호스팅 CSE가 파라미터 ConditionalDiscoveryStatus = FAIL을 갖는 발견 요청을 수신할 수 있다고 가정되는 경우, 호스팅 CSE에서의 절차는 아래에서 기술된 바와 같다. 이것은 조건이 충족되지 않더라도 조건부 트랜짓 CSE가 호스팅 CSE쪽으로 발견 요청을 전달한다는 것을 암시한다. 이것은: (i) 호스팅 CSE가 리소스에 대해 얼마나 많은 발견 시도들이 이루어졌는지의 표시를 원하거나 (ii) 트랜짓 CSE가 발견 응답으로 발견 요청들에 응답하도록 허용되지 않은 경우들에서 발생할 수 있다. 단계 1에서, 호스팅 CSE는 발견 요청이 ConditionalDiscovery의 유형인지 검사한다. 그렇지 않은 경우, 그것은 단계 2로 진행하고, 단계 2에서: 호스팅 CSE는 필터 기준들과 일치하는 리소스들을 검색한다. 그것은 검색 결과들에 기초하여 발견 응답을 준비하고 단계 4로 진행한다.

그렇지 않은 경우, 프로세스는 호스팅 CSE가 ConditionalDiscoveryStatus를 검사하는 단계 3으로 진행한다. PASS라면, 단계 2로 진행한다. FAIL인 경우, 다음의 파라미터들을 갖는 발견 응답 메시지를 준비한다: (i) To: 발신자의 ID; (ii) From: 호스팅 CSE의 ID; (iii) Content: 비어 있음. 그 후, 호스팅 CSE는 발견 응답 메시지를 전송한다(단계 4). 다음으로, 호스팅 CSE에서 처리를 종료시키는 단계 5로 진행하라.

조건부 발견 콜 흐름

다른 실시예에 따라, 도 13에 보여진 바와 같이, 예를 들어, 위에서 언급된 실시예들 중 하나로부터 각각의 엔티티들에서의 처리 및 이들 사이의 시그널링의 예를 보여준다. 콜 흐름은 발신자가 IN-CSE에서 지정된 필터 기준들(리소스 크기가 1Kbyte를 초과함)과 일치하는 리소스들을 찾되 노드 1에서 이용 가능한 메모리를 모니터링하는 리소스1(노드 1, 트랜짓 CSE2)이 1 Kbyte보다 적은 경우에만(조건1→ 노드1/메모리/memAvailable < 1 KByte) 찾는다고 가정한다.

단계 1에 따라, 발신자는 IN-CSE 쪽으로 발견 요청을 발행한다. 요청은 다음 중 하나 이상을 명시할 수 있다: (i) Discovery Type = conditionalDiscovery; (ii) ConditionOn = /트랜짓CSE2/리소스1; 및 (iii) ConditionCriteria: memAvailable< 1 Kbyte. 단계 2에서, 트랜짓 CSE1은 조건부 CSE가 아니고, 따라서 발견 요청은 IN-CSE 쪽으로 전달된다. 단계 3에서, 트랜짓 CSE2는 조건부 CSE이고, 따라서 CSE는 ConditionCriteria가 충족되는지 확인한다. 조건이 충족되는 경우, 트랜짓 CSE2는 추가 처리를 위해 발견 요청을 IN-CSE 쪽으로 전달한다. 조건이 충족되지 않으면, 트랜짓 CSE2는 다음 중 하나 이상을 명시하며 발신자로 반환할 발견 응답을 준비한다: (i) To: 발신자; (ii) content = "empty"; 및 (iii) ConditionalDiscoveryStatus = FALSE. 단계 4에서, 트랜짓 CSE3은 조건부 CSE가 아니고, 따라서 발견 요청은 IN-CSE 쪽으로 전달된다. 또한, 단계 5에서, 발견 요청이 호스팅 CSE에 도달하는 경우, 이것은 조건이 성공적이었음을 암시한다. IN-CSE는 필터 기준들과 일치하는 리소스들의 목록을 획득하고, 발견 응답을 생성하고, 그것을 발신자 쪽으로 전송한다. 세부 사항: (i) To: 발신자; (ii) content = 일치하는 리소스의 어드레스들의 목록; 및 (iii) 임의적으로, ConditionalDiscoveryStatus = TRUE.

호스팅 CSE 재지향을 이용한 검색

본 출원의 추가의 양태에서, 발신자는 호스팅 CSE 쪽으로 발견 요청을 발행할 수 있다. 동시에, 그것은 트랜짓 CSE들에게 그것들이 필터 기준들과 일치하는 리소스들을 갖는 대체 호스팅 CSE들을 알고 있는지 쿼리할 수 있다. 영향을 받는 엔티티들 각각에서의 처리가 아래에 기술된다. 제1 프로토콜은 발신자에서 호스팅 CSE 재지향을 위한 것이다.

단계 1에서, 발신자는 발견 요청을 발행한다. 이것은 전용 메소드를 통해, 또는 RETRIEVE, UPDATE, CREATE, 또는 다른 유사한 메소드를 통해 전송될 수 있다. 요청은 다음 파라미터들을 포함할 수 있다: (i) To: 호스팅 CSE 상에서 발견이 시작되는 루트의 어드레스; (ii) Filter Criteria: 검색을 위한 필터 기준들 및 예상되는 반환된 결과; (iii) Discovery Result Type: 반환된 발견 결과의 임의적 형식; (iv) 트랜짓 CSE들에게 그것들이 필터 기준들과 일치하는 리소스들을 가진 대체 호스팅 CSE들을 알고 있는지 평가할 것을 통지하는 Discovery Type = hostingCSERedirect. 예를 들어, 대상 CSE는 발견 검색 기준들과 일치하는 것이 있는지 확인하기 위해 자신이 호스팅하는 안내된 리소스들 전부를 조사할 수 있다. 대안적으로, 트랜짓 CSE가 처리/전달한 모든 사전의 발견 응답들의 캐시를 유지하는 경우, 그것은 필터 기준들과 일치하는 임의의 리소스들이 있는지 판정하기 위해 이 캐시를 조사할 수 있다.

다른 파라미터는 RequestedAction을 포함할 수 있다. 이것은 트랜짓 CSE들이 대체 호스팅 CSE들을 알고 있는 경우 트랜짓 CSE들에서 수행될 작업일 수 있다. 가능한 옵션들은 notifyOriginator 를 포함하여: 이것은 발신자에게 대체 호스팅 CSE가 존재한다는 것을 알린다. 대체 호스팅 CSE로 새로운 발견 요청을 전송하기 위한 최종 결정은 발신자에게로 남겨진다. 이것은 또한 takeAutonomousAction의 작업을 포함할 수 있다. 이것은 트랜짓 CSE가 호스팅 CSE를 자체적으로 변경하는 것을 허용한다(많은 개인 정보 또는 보안을 요구하지 않는 서비스들 또는 애플리케이션들에 대해).

단계 2에 따라, 발신자는 발견 응답 메시지를 기다린다. 발신자는 다음 작업들 중 하나 이상에서 발견 절차를 끝낼 수 있다. 하나의 작업은 잠재적인 호스팅 CSE들의 목록, 및 임의적으로 이러한 잠재 호스팅 CSE들에 대한 메트릭과 함께 트랜짓 CSE로부터 응답을 수신하는 것을 포함할 수 있다. 다음으로, 발신자는 (제공된 메트릭에 기초하여) 가장 좋은 호스팅 CSE를 결정하고 새 발견 요청을 발행할 수 있다. 다른 작업은 호스팅 CSE로부터 응답을 수신하는 것을 포함할 수 있다. 이것이 발견 요청에서와 동일한 호스팅 CSE인 경우, 호스팅 CSE 재지향이 발생하지 않는다. 이것이 발견 요청에서와 동일한 호스팅 CSE가 아닌 경우, 이것은 발신자에게 트랜짓 CSE가 호스팅 CSE를 자체적으로 변경했음을 시그널링한다. 대안적으로, 발견 응답은 discoveryRedirect 파라미터를 포함할 수 있다. 이 파라미터가 TRUE로 설정되는 경우, 그것은 호스팅 CSE가 재지향되었음을 발신자에게 시그널링한다.

다른 실시예에서, 트랜짓 CSE에서 CSE 재지향을 호스팅하기 위한 절차가 있다. 예를 들어, 도 14는 발견 요청의 수신 시의 트랜짓 CSE에서의 작업들을 예시한다. 단계 1에 따라, 트랜짓 CSE가 필터 기준들과 일치하는 리소스들을 갖는 임의의 대체 호스팅 CSE를 알고 있는지에 대한 검사가 이루어진다. 예를 들어, 이것은 트랜짓 CSE에의 안내들을 통해 달성될 수 있다. 예인 경우, 프로세스는 단계 3으로 진행한다. 단계 3에서, RequestedAction이 notifyOriginator인지에 대한 쿼리가 수행된다. 예인 경우, 그것은 다음의 하나 이상의 파라미터들을 갖는 발견 응답 메시지를 준비하는 단계 4로 진행할 수 있다: (i) To: 발신자의 ID; (ii) From: 트랜짓 CSE의 ID; 및 (iii) Content: 잠재 호스팅 CSE들의 어드레스, 및 임의적으로 이러한 CSE들과 연관된 메트릭. 몇몇 메트릭은: 서비스 레이어 파라미터들, 예를 들어, 트래픽 로드, 서비스 레이어 홉들, 기저 네트워크 파라미터들, 예를 들어, 홉들의 수, 기저 액세스 네트워크의 유형, 및 유지되는 리소스들에 대한 정보, 예를 들어, 유형, 일부 기본 시맨틱 등을 포함할 수 있다. 또한, 트랜짓 CSE는 발견 요청을 전달하지 않는다. 다음으로, 단계 6으로 진행한다.

대안적으로, 단계 3으로부터의 쿼리가 아니오인 경우, 단계 5로 진행한다. 단계 5에서, 그것은 가장 좋은 호스팅 CSE를 선택한다. 이것은 호스팅 CSE에 대한 최저 홉 수(lowest hop count), 호스팅 CSE에의 기저 네트워크 연결성 등에 기초할 수 있다. 선택된 호스팅 CSE가 발견 요청 메시지에 포함된 것과 다르다면, 그것은 "To" 파라미터를 선택된 호스팅 CSE에 일치하도록 변경시키는 것에 의해 발견 요청 메시지를 수정한다. 그것은 이것이 재지향된 발견 요청이라는 표시를 포함한다(discoveryRedirect = TRUE 설정). 다음으로, 그것은 발견 요청을 선택된 호스팅 CSE 쪽으로 전달한다. 다음으로, 프로세스는 단계 6으로 진행한다. 대안적으로, 대상 CSE는 모든 대체 호스팅 CSE들(또는 몇몇 메트릭(예를 들어 더 적은 홉 카운트)에 기초한 이것들의 부분집합)에 대한 발견 요청을 팬 아웃(fan out)할 수 있다. 또한, 처리는 종료된다(단계 6).

심지어, 단계 1로부터의 쿼리가 아니오인 경우, 그것은 요청을 호스팅 CSE 쪽으로 전달하기 위해 단계 2로 진행한다. 단계 2에 따라, 트랜짓 CSE(CSE_A)는 자신이 호스팅 CSE에 등록된 경우 요청을 호스팅 CSE로 전달한다. 대안적으로, 그것은 요청을 트랜짓 CSE(CSE_A)가 등록된 다른 트랜짓 CSE(CSE_B)로 전달할 수 있다. 다음으로, 프로세스는 단계 6으로 진행할 수 있다.

또 다른 실시예에서, 절차는 호스팅 CSE에서의 호스팅 CSE 재지향을 위한 것일 수 있다. 단계 1에 따라, 호스팅 CSE는 필터 기준들과 일치하는 리소스들을 검색한다. 그것은 검색 결과들에 기초하여 발견 응답을 준비하고 단계 2로 진행한다. 단계 2에서, 호스팅 CSE는 발견 응답 메시지를 준비한다. 그것은 다음 파라미터들을 포함할 수 있다: (i) To: 발신자의 ID; (ii) From: 호스팅 CSE의 ID; (iii) Content: 필터 기준들과 일치하는 리소스들의 목록; 및 (iv) discoveryRedirect: 발견 요청 메시지에서 discoveryRedirect 파라미터의 값으로 설정. TRUE로 설정되는 경우, 이것은 발견 요청 메시지에 포함된 호스팅 CSE가 아니라는 것을 발신자에게 나타낸다.

다른 실시예에 따르면, 호스팅 CSE 재지향 콜 흐름이 기술될 것이다. 도 15에 보여진 바와 같이, 콜 흐름은 하나 이상의 실시예들로부터 각각의 엔티티들에서의 처리 및 그 사이의 시그널링의 예를 보여준다. 엔티티들 사이의 굵은 화살표는 등록 관계를 표시한다. 트랜짓 CSE2 및 트랜짓 CSE4는 둘 다 트랜짓 CSE3으로 등록된다. 그러나, 트랜짓 CSE4는 발신자로부터 IN-CSE로의 등록 경로 상에 있지 않다. 이것을 반영하기 위해, 트랜짓 CSE4는 빨간색으로 보여진다. 콜 흐름은 발신자가 지정된 필터 기준과 일치하는 리소스들을 찾고 있다고 가정한다. 발신자는 IN-CSE에서 리소스 발견을 대상으로 하지만, 대상 CSE들이 다른 CSE들내의 일치하는 리소스들을 알고 있는 경우 대상 CSE들이 호스팅 CSE를 자체적으로 변경하는 것을 허용한다. 제시된 예에서, 트랜짓 CSE3은 트랜짓 CSE4내의 일치하는 리소스들을 알아 차린다(예를 들어, 등록 절차 동안 트랜짓 CSE3에서 생성된 원격 CSE의 결과로).

단계 1에 따라, 발신자는 다음 중 하나 이상을 명시하는, IN-CSE 쪽으로의 발견 요청을 발행한다: (i) To: IN-CSE; (ii) Discovery Type = hostingCSERedirect; 및 (iii) RequestedAction = takeAutonomousAction. 단계 2에서, 트랜짓 CSE1은 임의의 다른 잠재적인 호스팅 CSE들을 알고 있지 않고, 따라서 발견 요청은 IN-CSE 쪽으로 전달된다. 단계 3에서, 트랜짓 CSE2는 임의의 다른 잠재적인 호스팅 CSE들을 알고 있지 않고, 따라서 발견 요청은 IN-CSE 쪽으로 전달된다. 단계 4에서: 트랜짓 CSE3는 트랜짓 CSE4에서 필터 기준들과 일치하는 리소스들이 발견될 수 있다는 것을 알고 있다. 그것은 발견 요청의 호스팅 CSE를 자체적으로 변경하기로 결정한다. 그것은 발견 요청을 수정하고, 요청을 추가 처리를 위해 트랜짓 CSE4 쪽으로 전달한다. 수정된 검색 요청: (i) To: 트랜짓 CSE4; (ii) Discovery Type = hostingCSERedirect; 및 (iii) RequestedAction = takeAutonmousAction.

단계 5에서, 트랜짓 CSE4는 필터 기준들과 일치하는 리소스들의 목록을 획득하고, 발견 응답을 생성하고 그것을 발신자 쪽으로 전송한다. 세부 사항은: (i) To: 발신자; 및 (ii) content = 일치하는 리소스의 어드레스들의 목록을 포함하지만 이에 제한되지 않는다.

실시예들

표 4에 나열된 바와 같이 기존의 oneM2M<CSEBase> 리소스에 대해 새로운 특성이 제안된다.

*<CSEBase>* 의 특성들	중복도	RW/ RO/ WO	설명
discoveryType	1(L)	RO	이 특성은 CSE에 의해 지원되는 향상된 발견 절차들의 목록을 나타낸다. discoveryType은: multiHopDiscovery,conditionalDiscovery, hostingCSERedirect, 또는 둘 이상의 이것들의 조합의 목록으로부터의 것이다. 예를 들어: conditionalDiscovery + hostingCSERedirect는 CSE가 동시의 호스팅 CSE 재지향 및 조건부 리소스 발견을 지원한다는 것을 암시한다.

3개의 새로운 지원된 작업들이 accessControlOperations에 의해 허가될 수 있다. 이것들은 표 5에 나열되어 있다.

이름	설명
DISCOVER_MULTIHOP	리소스를 발견하고 요청을 전달하는 특권
DISCOVER_CONDITIONAL	조건부로 리소스를 발견하는 특권
DISCOVER_REDIRECT	호스팅 CSE를 재지향하는 특권

RETRIEVE 요청에 대한 새로운 파라미터들이 있다. 이것들은 다음을 포함한다: Discovery Type: 발견 관련 요청들에 적용되고, 발신자에 의해 요청된 향상된 발견 절차를 나타내기 위해 사용되는 임의적 파라미터. Discovery Type에 대해 다음 값들이 정의된다:

multiHopDiscovery: 트랜짓 CSE들은 본 출원에서 위에서 기술된 바와 같이 로직을 따른다.

conditionalDiscovery: 트랜짓 CSE들은 본 출원에서 위에서 기술된 바와 같이 로직을 따른다.

hostingCSERedirect: 트랜짓 CSE들은 본 출원에서 위에서 기술된 바와 같이 로직을 따른다.

forwarding: 트랜짓 CSE들은 발견 요청을 전달하기만 한다.

발신자는 자신의 요청에서 복수의 발견 유형들, 예를 들어, multiHopDiscovery+conditionalDiscovery를 명시할 수 있다. 대안적으로, DiscoveryType이 없다면, 트랜짓 CSE는 요청을 처리하지 않아야 하고, 위에서 기술된 바와 같이 요청을 단순히 전달하는데, 예를 들어 현재 발견으로 롤백(rollback)한다.

MultiHop Discovery SubType: Discovery Type = multiHopDiscovery인 때 임의적 파라미터가 발견 관련 요청들에 적용된다. 다중 홉 발견의 목적 및 트랜짓 CSE들에서 요구되는 로직을 나타내기 위해 사용된다. MultiHop Discovery Type에 대해 다음 값들이 정의된다:

routeDiscovery : 발신자가 호스팅 CSE에 대한 서비스 레이어 라우팅 경로를 찾기를 원한다는 것을 시그널링한다.

findUptoKResourcesDiscovery: 발신자가 필터 기준들과 일치하는 K개까지의 리소스들을 원한다는 것을 시그널링한다.

findUptoNHopResourcesDiscovery: 발신자가 발신자로부터의 K개의 서비스 레이어 홉들 내에서 필터 기준들과 일치하는 리소스들을 발견하기를 원한다는 것을 시그널링한다.

findAllResourcesDiscovery: 발신자가 필터 기준들과 일치하는 모든 리소스들을 원한다는 것을 시그널링한다.

RequestedAction: Discovery Type = hostingCSERedirect일 때 발견 관련 요청들에 적용되는 임의적 파라미터. 트랜짓 CSE가 발견 요청을 자체적으로 재지향시킬 수 있는지 여부 또는 발신자에 의해 이것이 수행될지 여부를 나타내기 위해 사용된다. RequestedAction에 대한 다음 값들이 정의된다:

notifyOriginator. 대체 호스팅 CSE에 새로운 발견 요청을 전송하기 위한 최종 결정은 발신자에게 남겨진다.

takeAutonomousAction: 트랜짓 CSE가 호스팅 CSE를 자체적으로 변경하는 것을 허용한다.

ConditionedOn: Discovery Type = conditionalDiscovery일 때 포함되는 임의적 리소스 어드레스. 이것은 조건이 확인될 리소스를 표시한다.

ConditionCriteria: Discovery Type = conditionalDiscovery일 때 포함되는 임의적 기준들. 이것은 ConditionedOn 리소스 상에서 테스트되는 기준들을 표시한다.

ConditionPersistence: Discovery Type = conditionalDiscovery일 때 포함되는 임의적 타이머 값. 이것은 조건부 트랜짓 CSE가 얼마나 오래 ConditionedOn 리소스 상에서 조건을 모니터링할지를 표시한다. 0인 경우, 조건부 트랜짓 CSE는 발견 요청 상에서 수신 시에 조건을 검사할 것이다. 0이 아닌 경우, 조건부 트랜짓 CSE는 조건이 충족되는 것을 기다릴 것이다. 그것은 ConditionPersistence 시간 후에 또는 발견 요청의 만료 후에 (어느 것이든 먼저인 것에서) 포기하고 조건 실패에 관해 발신자에게 통지할 것이다.

추가로, 필터 기준 파라미터는 아래에 표 6에 나열된 바와 같이 다중 홉 발견을 위해 구체적으로 2개의 새로운 조건을 갖는다.

조건 태그	중복도	일치 조건
:	:	:
Limit	0..1	일치하는 리소스들의 수를 지정된 값으로 제한.
matchingResourceLimit	0..1	발신자에 의해 요구되는 일치하는 리소스들의 수
hopLimit	0..1	발견 요청이 횡단하는 것이 허용될 서비스 레이어 홉들의 수

RETRIEVE 응답에 대한 새로운 파라미터들이 있다. 이것들은 다음을 포함한다.

matchingResourceLimitReached: matchingResourceLimit이 획득되었는지 여부를 표시하는 임의적 플래그.

hopLimitReached: 발견 요청에 의해 서비스 레이어 홉들의 최대 수가 횡단됐는지 여부를 표시하는 임의적 플래그.

ConditionalDiscoveryStatus: ConditionedOn 리소스에서의 조건 검사가 충족되었는지 또는 아닌지 표시하는 임의적 플래그.

discoveryRedirect: 트랜짓 CSE가 연관된 발견 요청을 새로운 호스팅 CSE로 재지향시켰는지를 표시하는 임의적 플래그.

도 16은 현재의 oneM2M 기능 아키텍처에 기초하여 향상된 발견 CSF를 형성하기 위해 기존의 발견 CSF에 제안된 아이디어들을 구현하는 것에 대한 예시적인 실시예를 보여준다. 향상된 발견 CSF는 ASN-CSE, MN-CSE, 및 IN-CSE에서 발견될 수 있다. 이 새로운 향상된 발견(enhanced Discovery)(eDIS) CSF는 리소스들을 발견하기 위해 발견 요청내의 정보(발신자 제공 발견 유형, 필터 기준들, 목적지/대상 노드)를 사용한다.

요청을 수신할 때, eDIS CSF는 제공된 발견 유형을 사용하여 어떻게 요청을 처리할지를 결정한다. 발견 유형이 다중 홉 발견인 경우, eDIS CSF는 요청된 다중 홉 발견 서브타입에 기초하여, 일치하는 리소스들을 발견하고, 더 많은 일치하는 리소스들이 요구되는 경우에는 다른 MN-CSE들 또는 IN-CSE들로 요청을 전달하는 작업을 수행한다. 발견 유형이 조건부 발견이고 이러한 eDIS CSF를 호스팅하는 노드가 조건의 대상이라면, eDIS CSF는 조건을 평가할 수 있고, 조건이 충족되는 경우 다른 MN-CSE들 또는 IN-CSE들로 요청을 전달하기만할 수 있다. 발견 유형이 호스팅 CSE 재지향인 경우, eDIS CSF는 먼저 필터 기준들과 일치하는 리소스들을 호스팅하고 있는 임의의 다른 CSE들을 알고 있는지 여부를 판정하고, 그렇다면, 그것은 요청을 이러한 다른 CSE들로 재지향시킬 수 있다.

도 17은 제안된 아이디어들이 어떻게 GUI 인터페이스를 통해 디스플레이될 수 있는지를 예시한다: (i) 발신자로 행동하는 노드 상에서, 및 (ii) 서비스 레이어 소프트웨어 모듈을 동작시키는 중간 노드 상에서. 서비스 레이어 참조 포인트들을 통해 제안된 메시지들이 있기 때문에, 메시지는 노드들 사이의 스니퍼 도구(sniffer tool)를 사용하여 감지될 수 있다. GUI 인터페이스는 서비스 레이어 소프트웨어에 구성을 제공하기 위해, 예를 들어 본 출원에서 제안된 파라미터들/리소스들 중 일부를 설정하기 위해 이용될 수 있다. GUI 인터페이스는 또한 작업 동안 파라미터들/리소스들의 변경들을 디스플레이하기 위해 사용될 수 있다. 일 실시예에서, 디스플레이 상의 GUI는 특정 검색 파라미터들과 일치하는 반환된 결과들을 포함할 수 있다. 검색 파라미터들은 리소스 유형, 리소스 생성 시간, 리소스 크기 등에 기초할 수 있다. 예를 들어, 필터 기준들과 일치하는 'k'개의 리소스들이 GUI 상에 디스플레이될 수 있다. 추가로, 서비스 레이어 홉들의 수가 디스플레이된다. 예시적인 실시예에 따라, GUI는 "ParkingFinder" 애플리케이션으로서 디스플레이될 수 있다. 애플리케이션은 사용자들이 검색 파라미터와 같은 정보를 입력할 수 있는 사용자 인터페이스를 포함할 수 있다. 그렇게 함으로써, GUI는 이용 가능한 프리 스팟들(free spots)의 수를 나타내는 결과를 출력한다.

발신자에서의 GUI는 사용자가 발견 요청을 생성하고, 후속하여 다양한 발견 유형들(다중 홉 발견, 조건부 발견, 호스팅 CSE 재지향) 하에서 발견 응답을 디스플레이하기 위해 중간 노드로 전송하는 것을 허용할 수 있다. 중간 노드에서의 GUI는 다양한 발견 유형들(다중 홉 발견, 조건부 발견, 호스팅 CSE 재지향)에 대한 조건들을 야기하도록 서비스 레이어를 구성하기 위해 사용될 수 있다. 예를 들어, 사용자는 FALSE로 평가될 조건부 발견을 갖는 발견 요청을 생성하기 위해 발신자에서 GUI를 사용할 수 있다. GUI는 발견 응답을 디스플레이할 수 있다.

프로세서(32)는 본 명세서에 기술된 몇몇 예들에서의 학습 관리 시스템이 성공적인지 또는 성공적이지 않은지(예를 들어, 서비스 요청들, 문맥 검색, 또는 문맥 통지 등)에 대응하여 디스플레이 또는 인디케이터들(42) 상의 조명 패턴들, 이미지들, 또는 색들을 제어하거나, 또는 서비스 요소들 및 연관된 구성 요소들의 상태를 다르게 나타내도록 구성될 수 있다. 디스플레이 또는 인디케이터들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들의 제어는 본 명세서에 예시되거나 논의된 표들 또는 도면들(예를 들어, 도 4 및 도 7-15)내의 임의의 방법 흐름들 또는 구성 요소들의 상태를 반영할 수 있다. 본 명세서에 서비스 요소들의 메시지들 및 절차들이 개시된다. 메시지들 및 절차들은 입력 소스 (예를 들어, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치패드(42))를 통해 리소스 관련 리소스들을 요청하고, 디스플레이(42) 상에 디스플레이될 수 있는 것들 중에서도 특히 서비스 요소 연관 정보를 요청, 구성, 또는 쿼리하기 위해, 사용자들에게 인터페이스/API를 제공하도록 확장될 수 있다,

본 출원에 따라, 본 명세서에 기술된 임의의 또는 모든 시스템들, 방법들, 및 프로세스들은 컴퓨터 판독 가능한 저장 매체에 저장될 수 있는 컴퓨터 실행 가능 명령어들, 예를 들어, 프로그램 코드의 형태로 구현될 수 있고, 그러한 명령어들은 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스, 트랜짓 디바이스 등과 같은 기계에 의해 실행될 때, 본 명세서에 기술된 시스템들, 방법들, 및 프로세스들을 수행 및/또는 구현한다는 것이 이해된다. 구체적으로, 위에서 기술된 임의의 단계들, 작업들, 또는 기능들은 그러한 컴퓨터 실행 가능한 명령들의 형태로 구현될 수 있다. 컴퓨터 판독 가능한 저장 매체는 정보의 저장을 위해 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함하지만, 그러한 컴퓨터 판독 가능한 저장 매체는 신호들을 포함하지 않는다. 컴퓨터 판독 가능한 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD ROM, 디지털 다용도 디스크(digital versatile disk)(DVD), 또는 다른 광 디스크 저장소, 자기 카세트들, 자기 테이프, 자기 디스크 저장 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하기 위해 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 물리적 매체를 포함하지만 이에 제한되지 않는다.

본 출원의 다른 양태에 따라, 컴퓨터 판독 가능한 또는 실행 가능한 명령어들을 저장하기 위한 비일시적 컴퓨터 판독 가능한 또는 실행 가능한 저장 매체가 개시된다. 매체는 도 4 및 도 7-15에 따른 복수의 콜 흐름에서 위에서 개시된 바와 같은 하나 이상의 컴퓨터 실행 가능한 명령어들을 포함할 수 있다. 컴퓨터 실행 가능한 명령어들은 메모리에 저장될 수 있고, 위에서 도 5c 및 도 5d에서 개시된 프로세서에 의해 실행될 수 있으며, UE들, HSS들, 및 SCS들을 포함하는 디바이스들에 이용될 수 있다. 일 실시예에서, 위에서 도 5c 및 도 5d에서 기술된 바와 같이, 비일시적 메모리 및 그것에 작동 가능하게 결합된 프로세서를 갖는, 컴퓨터에 의해 구현되는 UE가 개시된다. 구체적으로, 발신자의 비일시적 메모리는 그 안에 위치되는 리소스들에 대한 CSE들의 발견을 수행하기 위해 그 안에 저장된 명령어들을 갖는다. 프로세서는 (i) 발견 유형을 포함하는 발견 요청 메시지(Discovery request message)(DRM)를 생성하고; (ii) DRM을 CSE로 전송하고; (iii) CSE로부터 발견 응답을 수신하는 명령어들을 수행하도록 구성된다.

다른 실시예에 따라, 트랜짓 CSE의 비일시적인 메모리는 리소스들에 대한 발견 요청을 처리하기 위해 그 안에 저장된 명령어들을 갖는다. 프로세서는 (i) 프로세서로부터 발견 요청을 수신하는 명령어들을 수행하도록 구성된다. 요청은 (ii) 임의의 리소스들이 메시지 내의 필터 기준들과 일치하는지 여부를 검사하고; (iii) 발견 응답 메시지를 준비하는 발견 유형 및 필터 기준들을 포함할 수 있다. 예시적인 실시예에서, 프로세서는 필터 기준들에 기초하여 얼마나 많은 결과들을 반환할 것인지를 결정한다.

현실의 예들

위에서 언급된 출원은 현실의 상황들에서 유용할 수 있다. 이것은 예를 들어, 여러 수준들/층들을 갖는 주차 단지에서 이용 가능한 주차 지점을 찾는 것을 포함할 수 있다. 도 18a는 이용 가능한 주차 지점들의 그래픽 사용자 인터페이스를 예시한다. 즉, 각 층은 하나의 게이트웨이(1801)를 가질 수 있고, 단지 내의 각각의 주차 지점은 각각의 지점의 상태에 관한 표시(비어 있음/점유됨)를 제공하기 위해 그것의 가장 가까운 게이트웨이와 통신하는 센서(1804)를 갖추고 있다. 또한 그것은 주차 지점에 대한 세부 사항을 포함할 수 있다(예를 들어 지점이 미니밴에 대해 충분히 큰지의 여부, 그것이 휠체어 주차 지점인지의 여부, 그것이 엘리베이터에 가까운지의 여부, 및 주차 지점으로부터 비디오 피드(video feed)). 각각의 주차 지점의 이용 가능성은 이 건물뿐만 아니라, 이 서비스 제공자에 의해 관리되는 다른 건물들에 대한 모든 주차 지점들에 대한 안내들을 갖는 "ParkingFinder" 서비스 제공자(1802)와 공유된다.

이 예에서, 자동차는 주차 단지로 들어가고 운전자는 임의의 이용 가능한 주차 지점을 찾고 있다. 자동차 네비게이션 시스템은 자동적으로 주차 단지의 Wi-Fi 네트워크로 연결되는 "Parking Finder" 애플리케이션(1803)을 갖추고 있다. "ParkingFinder" 애플리케이션은 안내된 비어 있는 지점들 중 하나를 선택하고 서비스 제공자로부터 세부 사항을 검색할 수 있다. 대안적으로, "ParkingFinder" 애플리케이션은 "ParkingFinder" 서비스 제공자에게 층/수준 게이트웨이로부터 비어 있는 지점에 대한 세부 사항(예를 들어, 지점이 미니밴에 대해 충분히 큰지의 여부, 그것은 휠체어 액세스를 위해 지정된다는 것, 그것이 엘리베이터에 가까운지의 여부, 이 지점을 위한 비디오 피드 등)을 검색하는 것을 요청할 수 있다. 별도로 경찰 차량은 주차 단지로 들어가고, 지정된 지점, 예를 들어 휠체어 전용에 불법 주차한 사람이 있는지 여부를 검사할 수 있다.

다른 예는 도 18b에서 그래픽 사용자 인터페이스에 보여진 소규모 사무실의 보안에 관련 된다. 사무실 입구는 그것의 피드를 비디오 게이트웨이(1805) 및 MN-CSE 센서 게이트웨이(1804)에 주기적으로 보고하는 비디오 카메라로 모니터링된다. 게이트웨이는 매 24 시간 주기 동안 모든 비디오 피드들을 저장하고, 그것들이 효율적으로 검색될 수 있도록 녹화들에 타임 스탬프를 찍는다. IT 부서가 문제를 보고할 때(예를 들어 알 수 없는 사용자가 로컬 머신에 로그온하는 것을 시도함), 사무실 관리자는 이것이 침입 때문이었는지 또는 몇몇 다른 원인으로 인한 것인지 여부를 판정하기 위해 문제를 해결할 필요가 있다. 결과적으로, 관리자는 가장 최근의 수신 데스크 비디오 피드에 관한 정보를 보기를 원하되, 프론트 도어가 열린 경우에만 보기를 원한다. 사무실 관리자 애플리케이션은 그것이 사무실 관리자에 의해 트리거되는 경우 비디오 피드의 정보를 중계한다(예를 들어 문제 해결되는 것이 필요한 보고된 문제).

도 18a 및 도 18b는 본 명세서에 논의된 방법들 및 시스템들에 기초하여 생성될 수 있는 예시적인 디스플레이(예를 들어, 그래픽 사용자 인터페이스)를 예시한다. 디스플레이 인터페이스(예를 들어, 터치 스크린 디스플레이)는 표 2-6의 파라미터들과 같은 서비스 요소 호스트 선택과 연관된 텍스트를 제공할 수 있다. 다른 예에서, 본 명세서에서 논의된 단계들 중 임의의 것의 진행이 디스플레이될 수 있다. 추가로, 그래픽 출력이 디스플레이 인터페이스 상에 디스플레이될 수 있다.

시스템들 및 방법들이 특정 양태들로 현재 고려되는 것에 관련하여 기술되있지만, 본 출원은 개시된 양태들에 제한될 필요는 없다. 청구항들의 사상 및 범위 내에 포함되는 다양한 수정들 및 유사한 방식들을 포함하도록 의도되고, 그것의 범위는 그러한 모든 수정들 및 유사한 구조들을 포함하도록 가장 넓은 해석과 일치되어야 한다. 본 개시 내용은 다음 청구항들의 임의의 및 모든 양태들을 포함한다.

Claims

네트워크 상의 장치로서,
상기 네트워크 상의 리소스에 대한 발견 요청 메시지(discovery request message)를 처리하기 위한 명령어들이 그 안에 저장된 비일시적 메모리(non-transitory memory); 및
프로세서
를 포함하고, 상기 프로세서는, 상기 비일시적 메모리에 작동 가능하게 결합되고,
발신자로부터 필터 기준들을 포함하는 발견 요청 메시지를 수신하고;
임의의 리소스들이 상기 발견 요청 메시지 내의 상기 필터 기준들과 일치하는지 여부를 검사하고; 및
발견 응답을 준비하는 명령어들을 수행하도록 구성되는, 네트워크 상의 장치.
제1항에 있어서,
상기 프로세서는, 상기 필터 기준들, 및 상기 발견 요청 메시지의 발견 유형에 기초하여 얼마나 많은 결과들을 반환할지 결정하는 명령어들을 수행하도록 더 구성되는, 네트워크 상의 장치.
제2항에 있어서,
상기 결정하는 명령어는 일치하는 리소스 제한 'k'보다 적은 일치하는 리소스들 'L'에 기초하는, 네트워크 상의 장치.
제3항에 있어서,
상기 결정하는 명령어는:
필터 기준들과 일치하는 다른 공통 서비스 엔티티들을 검사하고,
검사하는 명령어에 기초하여 호스팅 공통 서비스 엔티티를 업데이트하는 것
을 포함하는, 네트워크 상의 장치.
제1항에 있어서,
상기 프로세서는 상기 발견 요청 메시지를 다른 공통 서비스 엔티티로 전달하거나 상기 발견 응답 메시지를 상기 발신자에게 전송하는 명령어들을 수행하도록 더 구성되는, 네트워크 상의 장치.
제1항에 있어서,
상기 프로세서는,
제2 발견 응답 메시지를 수신하고;
상기 제2 발견 응답 메시지로부터의 결과들에 기초하여 상기 발견 응답을 업데이트하는
명령어들을 수행하도록 더 구성되는, 네트워크 상의 장치.
제1항에 있어서,
상기 발견 요청 메시지는 경로 발견, 다중홉 발견, 조건부 발견, 호스팅 공통 서비스 엔티티 재지향, 및 그것들의 조합들로 구성되는 군으로부터 선택된 발견 유형을 포함하는, 네트워크 상의 장치.
제7항에 있어서,
상기 발견 유형은 조건부 지속(conditional persistence) 또는 대체 공통 서비스 엔티티 재지향(alternate common service entity redirect)을 갖는, 네트워크 상의 장치.
제1항에 있어서,
상기 발견 요청 메시지는 k개까지의 리소스들을 찾는 발견(find up to k resources discovery), N개까지의 홉들에서 리소스들을 찾는 발견(find up to N hops resources discovery), 모든 리소스들을 찾는 발견(find all resources discovery), 일치하는 리소스 제한, 및 홉 제한 중 적어도 하나를 포함하는, 네트워크 상의 장치.
네트워크 상에서 공통 서비스 엔티티의 발견을 수행하기 위한 방법으로서,
발견 유형 및 필터 기준들을 포함하는 발견 요청 메시지를 발신자로부터 수신하는 단계;
리소스가 상기 발견 요청 메시지 내의 상기 필터 기준들과 일치하는지 여부를 검사하는 단계;
발견 응답을 준비하는 단계; 및
상기 필터 기준들 및 상기 발견 유형에 기초하여 발견 응답에서 얼마나 많은 결과들을 반환할지를 결정하는 단계
를 포함하는 방법.
제10항에 있어서,
상기 결정하는 단계는 일치하는 리소스 제한 'k'보다 적은 일치하는 리소스들 'L'에 기초하는, 방법.
제10항에 있어서,
상기 결정하는 단계는:
상기 필터 기준들과 일치하는 다른 공통 서비스 엔티티들을 검사하는 단계; 및
상기 검사하는 단계에 기초하여 호스팅 공통 서비스 엔티티를 업데이트하는 단계
를 포함하는, 방법.
제10항에 있어서,
상기 발견 요청 메시지를 다른 공통 서비스 엔티티로 전달하거나 상기 발견 응답 메시지를 상기 발신자에게 전송하는 단계를 더 포함하는, 방법.
제1항에 있어서,
제2 발견 응답 메시지를 수신하는 단계; 및
상기 제2 발견 응답 메시지로부터의 결과들에 기초하여 상기 발견 응답을 업데이트하는 단계
를 더 포함하는, 방법.
네트워크 상의 장치로서,
상기 네트워크 상의 리소스의 발견을 수행하기 위한 명령어들이 그 안에 저장된 비일시적 메모리; 및
프로세서
를 포함하고, 상기 프로세서는, 상기 비일시적인 메모리에 작동 가능하게 결합되고,
발견 요청 메시지를 생성하고;
상기 발견 요청 메시지를 상기 네트워크 상의 공통 서비스 엔티티로 전송하고; 및
상기 공통 서비스 엔티티로부터 발견 응답을 수신하는
명령어들을 수행하도록 구성되는, 네트워크 상의 장치.
제15항에 있어서,
상기 발견 요청 메시지는 발견 유형을 포함하는, 네트워크 상의 장치.
제16항에 있어서,
상기 발견 유형은 다중홉 발견, 조건부 발견, 호스팅 공통 서비스 엔티티 재지향, 및 그것들의 조합들로 구성되는 군으로부터 선택되는, 네트워크 상의 장치.
제17항에 있어서,
상기 다중홉 발견은 경로 발견, k개까지의 리소스들을 찾는 발견, N개까지의 홉들에서 리소스들을 찾는 발견, 모든 리소스들을 찾는 발견, 일치하는 리소스 제한, 및 홉 제한 중 적어도 하나를 포함하는, 네트워크 상의 장치.
제15항에 있어서,
상기 발견 요청 메시지는 요청을 수행하는 공통 서비스 엔티티의 유형, 특정 계층의 공통 서비스 엔티티, 중요한 처리(significant processing)를 갖는 공통 서비스 엔티티, 목록 내의 공통 서비스 엔티티, 및 그것들의 조합들로 구성되는 군으로부터 선택되는 필터를 포함하는, 네트워크 상의 장치.
제15항에 있어서,
상기 발견 응답은 홉 제한이 도달된 것, 상기 일치하는 리소스 제한이 도달된 것, 및 그것들의 조합들로 구성되는 군으로부터 선택되는, 네트워크 상의 장치.
네트워크 상에서 공통 서비스 엔티티의 발견을 수행하기 위한 방법으로서,
발견 유형을 포함하는 발견 요청 메시지를 생성하는 단계;
상기 발견 요청 메시지를 상기 네트워크 상의 상기 공통 서비스 엔티티로 전송하는 단계; 및
상기 공통 서비스 엔티티로부터 발견 응답을 수신하는 단계
를 포함하고, 상기 발견 유형은 다중홉 발견, 조건부 발견, 호스팅 공통 서비스 엔티티 재지향, 및 그것들의 조합들로 구성되는 군으로부터 선택되는, 방법.
제21항에 있어서,
상기 발견 요청 메시지는 요청을 수행하는 공통 서비스 엔티티의 유형, 특정 계층의 공통 서비스 엔티티, 중요한 처리를 갖는 공통 서비스 엔티티, 목록 내의 공통 서비스 엔티티, 및 그것들의 조합들로 구성되는 군으로부터 선택되는 필터를 포함하는, 방법.
제21항에 있어서,
상기 발견 응답은 적어도 2개의 공통 서비스 엔티티로부터 수신되고,
적어도 2개의 공통 서비스 엔티티로부터 수신되는 중복 발견 응답들은 삭제되는, 방법.
제23항에 있어서,
상기 발견 응답은 홉 제한이 도달된 것 및 일치하는 리소스 제한이 도달된 것에 관한 정보를 포함하는, 방법.