KR20180027564A - 서비스 레이어 애니캐스트 및 썸캐스트 - Google Patents

Abstract

썸캐스트/애니캐스트(somecast/anycast) 서비스는 서비스 레이어에서 기능할 수 있으며 서비스 노드들/그룹들 선택 및 사후-선택 처리를 포함할 수 있다. 썸캐스트/애니캐스트 정보는 애니캐스트/썸캐스트의 상이한 시나리오들을 식별하고, 서비스 노드들 선택을 용이하게 하고, 재송신을 취급하는데 사용될 수 있다.

Description

서비스 레이어 애니캐스트 및 썸캐스트

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

본 출원은 2015년 7월 8일자로 출원된 "Service Layer Anycast and Somecast"라는 명칭의 미국 임시 출원 제62/190,007호의 혜택을 주장하며, 그 내용은 본 명세서에 참조로 원용된다.

<배경기술>

M2M 서비스 레이어

프로토콜 스택 관점에서, 서비스 레이어들은 애플리케이션 프로토콜 레이어 상부에 통상적으로 레이어화되고 부가 가치 서비스들을 클라이언트 애플리케이션들에 제공한다. 따라서 서비스 레이어들은 '미들웨어(middleware)' 서비스들로서 종종 분류된다. 예를 들어, 도 1은 IP 네트워크 스택(102)과 애플리케이션들(103) 사이에 있는 예시적인 서비스 레이어(101)를 도시한다.

네트워크 내의 서비스 레이어 인스턴스의 예시적인 배치 시나리오가 도 2에 도시된다. 도 2에서, 서비스 레이어 인스턴스(105)는 다양한 네트워크 노드들(게이트웨이들 및 서버들) 상에 배치되어, 예를 들어, 네트워크 애플리케이션 도메인(106)에서 발견되는 네트워크 애플리케이션들에, 디바이스 애플리케이션 도메인(107)에서 발견되는 디바이스 애플리케이션들에, 뿐만 아니라 네트워크 서비스들 도메인(108)에서 발견되는 네트워크 노드들에 부가 가치 서비스들을 제공하는 것으로 도시된다. 서비스 레이어 인스턴스(105)는 서비스 레이어의 실현이다.

M2M/IoT 서비스 레이어는 M2M/IoT 타입 디바이스들 및 애플리케이션들에 대해 부가 가치 서비스들을 제공하는 것을 향해 구체적으로 타겟화되는 일 타입의 서비스 레이어의 예이다. 업계 표준 기관들(예를 들어, oneM2M - oneM2M Functional Architecture, oneM2M-TS-0001 oneM2M Functional Architecture-V-2.1.0)은 M2M/IoT 타입들의 디바이스들 및 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전과제들에 대처하기 위해 M2M/IoT 서비스 레이어들을 개발해 왔다. M2M 서비스 레이어는 애플리케이션들 및 디바이스들에게 서비스 레이어에 의해 지원되는 M2M 중심 능력들의 수집(collection)에 대한 액세스를 제공할 수 있다. 몇몇 예들은 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 공급, 및 접속성 관리를 포함한다. 이러한 능력들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 사용하는 API들을 통해 애플리케이션들에 이용 가능하게 된다.

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

oneM2M 공통 서비스 레이어들은, 도 3에 도시되는 바와 같이, CSF들(Common Service Functions)(예를 들어, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화는 CSE(common services entity)(예를 들어, CSE(111))라고 지칭되며, 이는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정적 노드) 상에서 호스팅될 수 있다.

oneM2M은 RoA(resource oriented architecture)(예를 들어, 도 4), 및 SoA(service oriented architecture)(예를 들어, 도 5)라 불리우는 2개의 아키텍처 접근방식들로 서비스 레이어를 개발하고 있다. oneM2M RoA RESTful 아키텍처에 따르면, CSF들은 "리소스들(resources)"의 세트로서 표현된다. 리소스는 CRUD(Create, Retrieve, Update, and Delete)와 같이 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 아키텍처에서의 고유하게 어드레스 지정 가능한 엘리먼트이다. 이러한 리소스들은 URI들(universal resource identifiers)을 사용하여 어드레스 지정 가능하게 된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 자신의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 "속성들(attributes)"의 세트를 지원한다.

SoA 아키텍처는 RESTful 기반이 아닌 레거시 배치를 고려하도록 개발되고 있다. 이것은 도 5에 도시되는 것과 동일한 서비스 레이어 아키텍처를 주로 재-사용한다. 이러한 서비스 레이어는 다양한 M2M 서비스들을 포함하고, 다수의 서비스들이 서비스 컴포넌트들로 그룹화될 수 있다. 기존 참조 지점들에 추가하여, 이것은 서비스간 참조 지점 Msc를 도입하였다. Msc 참조 지점을 통과하는 M2M 서비스 컴포넌트들 사이의 통신은 웹 서비스들 접근방식, 예를 들어, 웹 서비스들 MEP(message exchange patterns)를 이용한다.

oneM2M에서의 그룹 관리

oneM2M에는 그룹 관련 동작들을 취급하는 것을 담당하는 GMG(group management) CSF가 존재한다. GMG는 다음 동작들을 취급할 수 있다:

그룹 및 관련된 그룹 멤버들을 생성, 검색, 업데이트, 및 삭제하라는 요청들.

특정 목적(예를 들어, 액세스 제어, 디바이스 관리, 디바이스 그룹에 대한 팬-아웃 공통 동작들 등)을 위해 oneM2M 시스템에서의 노드들에서의 CSE들에 하나 이상의 그룹들을 생성함.

그룹 멤버쉽을 관리하고 그룹의 멤버 목록에 멤버들을 추가하라는 또는 이로부터 멤버들을 제거하라는 요청들을 취급함.

GMG CSF 서비스 기능들에 의해 지원되는 기능성들을 완수하기 위해 다른 CSF들의 능력들을 활용함. 예들은, 인증 및 권한부여에 대한 보안 CSF를 포함함.

그룹에 있는 모든 멤버들에게 요청들을 전달함. 그룹이 멤버로서 다른 그룹을 포함하는 사례에서는, 전달 프로세스가 반복적으로 수행됨. GMG CSF가 그룹 멤버들로부터 대응하는 응답들을 종합하여 종합 응답을 생성함.

개별 그룹들에 대한 가입들을 지원함.

브로드캐스팅/멀티캐스팅을 포함하는 기본 네트워크의 기존 능력들을 활용함.

도 6은 그룹 관리를 위해 oneM2M에 의해 정의되는 <group> 리소스를 도시한다. 가상 리소스 <fanOutPoint>는 각각의 그룹 멤버에게 구체적인 요청을 전달하도록 정의된다. 도 7은 <group> 리소스에 대한 예시적인 방법 흐름이다. 도 8은 <fanOutPoint> 리소스에 대한 예시적인 방법 흐름을 도시한다.

썸캐스트/애니캐스트(somecast/anycast) 서비스는 서비스 레이어에서 기능할 수 있으며 서비스 노드들/그룹들 선택 및 사후-선택 처리를 포함할 수 있다. 썸캐스트/애니캐스트 정보는 애니캐스트/썸캐스트의 상이한 시나리오들을 식별하고, 서비스 노드들 선택을 용이하게 하고, 재송신을 취급하는데 사용될 수 있다.

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

첨부 도면들과 연계하여 예에 의해 주어지는 이하의 설명으로부터 보다 상세한 이해를 가질 수 있을 것이다.
도 1은 IP 네트워크 스택과 애플리케이션들 사이에 있는 예시적인 서비스 레이어를 도시한다.
도 2는 네트워크 내의 서비스 레이어 인스턴스들의 예시적인 배치 시나리오를 도시한다.
도 3은 공통 서비스 기능들이 있는 예시적인 oneM2M 공통 서비스 레이어를 도시한다.
도 4는 예시적인 oneM2M 서비스 레이어 기능적 아키텍처를 도시한다.
도 5는 예시적인 oneM2M 서비스들 컴포넌트 아키텍처를 도시한다.
도 6은 그룹 관리를 위해 oneM2M에 의해 정의되는 예시적인 <group> 리소스를 도시한다.
도 7은 <group> 리소스에 대한 예시적인 프로시저들(CRUDN)을 도시한다.
도 8은 <fanOutPoint> 리소스에 대한 예시적인 프로시저들(CRUDN)을 도시한다.
도 9는 인터넷 프로토콜 레이어에서의 예시적인 애니캐스트를 도시한다.
도 10은 인터넷 프로토콜 레이어에서의 예시적인 썸캐스트를 도시한다.
도 11은 예시적인 그룹 동작을 도시한다.
도 12는 예시적인 그룹 동작을 도시한다.
도 13은 썸캐스트/애니캐스트 서비스의 예시적인 아키텍처를 도시한다.
도 14는 메시지 전-처리에 대한 예시적인 방법을 도시한다.
도 15는 서비스 레이어에서의 비-그룹 기반 애니캐스트/썸캐스트에 대한 예시적인 방법 흐름을 도시한다.
도 16a는 그룹 선택이 수행되지 않는 예시적인 방법 흐름을 도시한다.
도 16b는 그룹 선택이 수행되는 예시적인 방법 흐름을 도시한다.
도 17은 재송신 동작들을 수행하기 위한 예시적인 옵션들을 나타낸다.
도 18은 oneM2M 기능 아키텍처에 기초하는 SL 썸캐스트/애니캐스트 CSF로서의 썸캐스트/애니캐스트 서비스의 예시적인 구현을 도시한다.
도 19는 oneM2M 그룹 관리 등에 대한 예시적인 썸캐스트/애니캐스트 방법 흐름을 도시한다.
도 20은 oneM2M 서비스 컴포넌트 아키텍처에서의 SAS의 예시적인 구현 아키텍처를 도시한다.
도 21은 애니캐스트/썸캐스트에 대한 예시적인 서비스 상호 작용들을 도시한다.
도 22는 썸캐스트/애니캐스트 서비스를 이용하기 위한 예시적인 사용자 인터페이스를 도시한다.
도 23a는 개시되는 주제가 구현될 수 있는 예시적인 M2M(machine-to-machine) 또는 IoT(Internet of Things) 통신 시스템의 시스템 도면이다.
도 23b는 도 23a에 도시되는 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템 도면이다.
도 23c는 도 23a에 도시되는 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템 도면이다.
도 23d는 도 23a의 통신 시스템의 양상들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

본 명세서에는 서비스 레이어 애니캐스트(anycast) 및 썸캐스트(somecast)에 대한 개념들이 개시된다. SAS(somecast/anycast service)는, 다른 것들 중에서, 서비스 노드들/그룹들 선택 및 사후-선택 처리에 대해 제공한다. 본 명세서에 설명되는 바와 같은 SAS는 기본 전송 네트워크 또는 기본 라우팅 프로토콜에 의해 제공되는 애니캐스트 및/또는 썸캐스트를 사용하지 않고 서비스 레이어에서의 그룹 관리에 의하거나 또는 의하지 않고 애니캐스트 및/또는 썸캐스트 통신을 인에이블하고 지원하는데 도움이 될 수 있다.

도 9는 IP 레이어에서의 애니캐스트 통신을 도시한다. IP 레이어에서의 애니캐스트는 단일 전송자로부터의 데이터그램들이 잠재적 수신자들의 그룹에서 위상적으로 가장 가까운 노드에 라우팅되는 네트워크 어드레스 지정 및 라우팅 방법론이며, 이것은 여러 노드들에 전송될 수 있더라도, 모두 동일한 목적지 어드레스에 의해 식별된다. 인터넷 상에서, 애니캐스트는 단일 서비스 어드레스에서 다수 노드들의 도달 가능성을 알리는 BGP(Border Gateway Protocol)를 사용하여 일반적으로 구현된다. 이러한 범위에 있는 목적지 어드레스들에 어드레스 지정되는 패킷들은 주어진 목적지 IP 어드레스를 알리는 넷 상의 "가장 가까운(nearest)" 지점에 라우팅될 수 있다. 인터넷의 성장에 따라, 네트워크 서비스들은 애니캐스트에 대한 고-가용성 요건들을 점점 더 갖는다. IETF RFC 4786, "Operation of anycast services": http://tools.ietf.org/html/rfc4786은 네트워크 오퍼레이터들에 대한 애니캐스트를 사용하여 분산 서비스를 배치하거나 동작시키는 현재의 관행으로서 동작한다. 애니캐스트는 네트워크 내에서 서비스를 배포하는 것에 의해 어느 정도의 로드 밸런싱을 제공할 수 있다.

도 10은 IP 레이어에서의 썸캐스트를 도시한다. 썸캐스트(예를 들어, IETF Draft, IPv4 option for somecast, 2000)는 패킷이 목적지들의 세트에 전송되게 하는 다-지점 전달 기술이다. 썸캐스트 전달에 의해 네트워크는 패킷의 하나의 사본을 패킷에 목록화되는 각각의 목적지에 전달한다. 썸캐스트는 멀티미디어 회의들 및 멀티플레이어 게임들과 같은 소형 다수-사용자 세션들에서 사용되거나, 또는 더 큰 세션들에 대해 최종 호스트 멀티캐스트와 함께 사용될 수 있다.

IP 썸캐스트는 어드레스 지정 스킴의 면에서 멀티캐스트의 수단이다. IP 멀티캐스트는 단일 송신으로 관심있는 수신자들의 그룹에 IP(Internet Protocol) 데이터그램들을 전송하는 방법이다. IP 멀티캐스트는 네트워크에서 IP 인프라스트럭처를 통한 일-대-다수(one-to-many) 및 다수-대-다수(many-to-many) 실시간 통신에 대한 기술이다. IP 멀티캐스트에서의 주요 개념들은 IP 멀티캐스트 그룹 어드레스, 멀티캐스트 배포 트리 및 수신자 구동 트리 생성을 포함한다. IP 멀티캐스트 그룹 어드레스는 소스들 및 수신자들에 의해 멀티캐스트 메시지들을 전송하고 수신하는데 사용된다.

도 11은 서비스 레이어 애니캐스트를 사용하는 그룹 동작으로부터 혜택을 얻을 수 있는 예시적인 사용 사례를 도시한다. 서비스 제공자는 온도 센서(115) 및 온도 센서(117)와 같은 많은 온도 센서들을 배포하여 서비스로서 실시간 온도 판독 사항들을 제공할 수 있다. 용이한 관리 및 구성, 예를 들어, 소프트웨어 업데이트 및 보안 구성을 위해, 그룹이 형성될 수 있고, 도 11의 센서들(예를 들어, 다른 것들 중에서, 온도 센서(115), 온도 센서(117) 등)은 서비스 제공자에 의해 그룹으로서 관리될 수 있다. 예시적인 종래의 시나리오에서, 단계 121에서, 서비스 레이어 클라이언트(118)는, 다른 온도 센서들 중에서, 온도 센서(115), 온도 센서(117)가 배치되는 영역(116)에 대한 온도 판독 사항을 검색하라는 요청을 전송할 수 있다. 종래의 서비스 레이어 그룹 관리 메커니즘들에 기초하여, 단계 122에서, 그룹 호스팅 노드(119)는 단계 121의 요청을, 다른 것들 중에서, 각각의 온도 센서(115), 온도 센서(117)에 (즉, 각각의 그룹 멤버에 개별적으로) 전달한다. 단계 123에서, 각각의 온도 센서는, 단계 122의 요청에 응답하여, 온도 판독 사항들이 있는 응답을, 각각, 리턴한다. 단계 124에서, 각각의 응답은 서비스 레이어 클라이언트(118)에 리턴된다.

도 11의 논의를 계속 참조하면, 서비스 레이어 애니캐스트가 없는 종래의 그룹 동작들은, 여분의 온도 판독 사항들 뿐만 아니라, 불필요한 데이터 흐름들(예를 들어, 각각의 센서에서의 통신 오버헤드 및 동작 오버헤드)을 초래할 수 있다. 또한, 과도한 메시지들(요청/응답)이 존재할 수 있다. 하나의 센서로부터 보고되는 가장 가능성 있는 온도 데이터가 충분하고, 서비스 레이어 클라이언트(118)는 영역(116)에 있는 임의의 온도 센서(예를 들어, 온도 센서(115) 또는 온도 센서(117))를 수용 가능하다고 간주할 수 있다. 이러한 시나리오에서, 온도 센서들은 서로 가깝게 위치될 수 있으며, 모든 센서들이 유사한 감지 능력을 갖는다고 가정하면, 동일하거나 매우 유사한 온도 판독 사항들을 제공할 수 있다.

서비스 레이어 애니캐스트는, 본 명세서에 논의되는 바와 같이, 서비스 레이어 동작들(예를 들어, CRUD)을 수행하기 위한 서비스 레이어 통신이다. 요약하면, 발신자(예를 들어, 서비스 레이어 클라이언트(118))는 서비스 레이어 노드들의 그룹(예를 들어, 영역(116)에 있는 온도 센서들)을 타겟화하는 것에 의하거나 또는 의하지 않고 등록자 노드(예를 들어, 그룹 호스팅 노드(119))에 요청 메시지를 전송한다. 이러한 동작은 복수의 자격을 갖춘 서비스 노드 중 하나에 의해 수행되고, 발신자는 어느 서비스 노드가 이러한 동작을 수행하는지 신경 쓰지 않거나 의식하지 않을 수 있다. 예시적인 타입들의 서비스 레이어 애니캐스트는 그룹 기반 애니캐스트 및 비-그룹 기반 애니캐스트를 포함한다. 그룹 기반 애니캐스트에서 발신자는 그룹 정보(예를 들어, 그룹 ID, <group> 리소스의 URI)를 명백하게 명시할 수 있어, 등록자 노드는 원하는 동작들을 수행하기 위해 명시된 그룹(들)(예를 들어, 영역(116))의 멤버들로부터 하나의 서비스 노드를 선택할 수 있다. 비-그룹 기반 애니캐스트에서, 발신자는 어떠한 그룹 정보도 명백하게 명시하지 않을 수 있고, 대신에 메시지에서의 일부 조건들(예를 들어, 위치 정보, 액세스 권한 요건)을 제공할 수 있다. 등록자 노드는 서비스 노드의 범위를 결정하고 조건들에 기초하여 서비스 노드를 선택할 수 있다.

도 12는 종래의 조명들의 그룹 동작들이 서비스 레이어 썸캐스트를 사용하여 혜택을 얻을 수 있는 사용 사례의 예를 도시한다. 여기서, 이동 전화는 거실(136)에 있는 n개의 조명들(예를 들어, 조명(133) 및 조명(134))을 원격으로 제어하는 애플리케이션(131)을 포함한다. 거실(136)의 n개의 조명들은 서비스 레이어에서의 관리를 위해 함께 그룹화될 수 있다. 거실(136)에 있는 조명들의 그룹은, 거실(136)에 있는 조명을 켜고 끄는 것 및 거실(136)에 있는 조명들의 밝기를 조절하는 것과 같은, 동작들을 수행하도록 애플리케이션(131)을 통해 제어될 수 있다. 시나리오에서, 거실(136)에 있는 모든 조명들을 켤 필요는 없을 수 있고, 한편 거실(136)에 있는 조명들의 서브세트를 켜는 것이면 충분하다. 광도계 등으로 검출될 수 있는 원하는 정도의 밝기를 제공하는 한, 거실(136)에 있는 어느 조명들이 켜지는지는 중요하지 않을 수 있다.

계속해서 도 12를 참조하면, 애플리케이션은 그룹에 있는 3개의 조명들을 켜라는 요청을 그룹 호스팅 노드(132)(예를 들어, IN-CSE)에 전송한다(단계 137). 그러나, 기존 서비스 레이어 그룹 관리 메커니즘들에 기초하여, 그룹 호스팅 노드(132)는 단계 137의 요청 메시지를 그룹에 있는 각각의 조명에 전달한다(단계 138). 거실(136)에 있는 각각의 조명이 켜질 수 있고 동작 결과들이 있는 응답을 그룹 호스팅 노드에 개별적으로 리턴할 수 있다(단계 139). 기존 그룹 동작들은 다른 것들을 꺼 두면서 3개의 조명들을 켜지 않고, 이는, 다른 것들 중에서, 불필요한 에너지의 소비, 및 여분의 메시지 교환들을 초래할 수 있다. 본 명세서에 설명되는 바와 같은 SAS는 기본 전송 네트워크 또는 기본 라우팅 프로토콜에 의해 제공되는 애니캐스트 및/또는 썸캐스트를 사용하지 않고 서비스 레이어에서의 그룹 관리에 의하거나 또는 의하지 않고 애니캐스트 및/또는 썸캐스트 통신을 인에이블하고 지원하는데 도움이 될 수 있다.

본 명세서에 논의되는 바와 같이, 서비스 레이어 썸캐스트는 서비스 레이어 동작들(예를 들어, CRUD)을 수행하기 위한 서비스 레이어 통신이다. 요약하면, 발신자(예를 들어, 애플리케이션(131))는 요청 메시지를 등록자 노드(예를 들어, 그룹 호스팅 노드(132))에 전송하며, 이는 원하는 동작을 수행하기 위해 요청을 선택하여 복수의 자격을 갖춘 서비스 노드들(예를 들어, 조명(133) 또는 조명(134))에 전달한다. 발신자는 일반적으로, 최종 기능이 수행되는 한(예를 들어, 거실(136)에 있는 조명의 양), 복수의 서비스 노드들 중 어느 것이 동작들을 수행하는지 신경 쓰지 않는다. 서비스 레이어 썸캐스트의 예시적인 타입들은 그룹 기반 썸캐스트 및 비-그룹 기반 썸캐스트를 포함한다. 그룹 기반 썸캐스트에서 발신자는 하나 이상의 그룹들의 그룹 정보(예를 들어, 거실(136))를 명백하게 명시할 수 있다. 등록자 노드는 그룹(들)로부터 결정된 수의 서비스 노드들을 선택할 수 있으며, 요청을 선택된 서비스 노드에 전달하며, 이는 그룹에 또는 상이한 그룹에 머무를 수 있다. 특별한 사례는, 발신자가 서비스 노드들의 목록의 어드레스들(예를 들어, URI들, IP 어드레스들)을 제공하는 것이고, 그래서 등록자 노드는 서비스 노드들을 선택하지 않고 요청을 전달하기만 하면 된다. 비-그룹 기반 썸캐스트에서, 발신자는 어떠한 그룹 정보도 명백하기 명시하지 않을 수 있지만, 대신에 발신자는 등록자 노드에 일부 조건들(예를 들어, 거실(136)에 있는 조명의 양)을 제공한다. 등록자 노드는 조건에 기초하여 서비스 노드들의 범위를 결정하고, 요청을 전달한다.

서비스 노드 범위는 등록자 노드가 애니캐스트 및 썸캐스트 요청을 선택할 때 후보 서비스 노드로서 고려되는 서비스 노드의 세트의 범위를 명시한다. 그룹 기반 시나리오에 대해, 발신자는 그룹 ID를 표시하여 범위를 명시할 수 있고, 따라서 등록자 노드는 범위를 결정할 필요가 없고; 한편 비-그룹 기반 시나리오에 대해, 그룹 ID 정보가 제공되지 않으므로 등록자 노드는 범위를 결정할 필요가 있다. 본 명세서에서는 서비스 레이어에서 그룹 기반 및 비-그룹 기반 애니캐스트/썸캐스트를 지원하기 위한 방법들, 시스템들, 및 디바이스들이 논의된다.

도 13 내지 도 17 및 도 19에 도시되는 단계들을 수행하는 엔티티들은, 다른 것들 중에서, 도 23c 또는 도 23d에 도시되는 것들 같은 디바이스, 서버, 또는 다른 컴퓨터 시스템의 메모리에 저장되고, 그 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들이라는 점이 이해된다. 즉, 도 13 내지 도 17 및 도 19에 도시되는 방법(들)은, 도 23c 또는 도 23d에 도시되는 디바이스 또는 컴퓨터 시스템과 같은, 컴퓨팅 디바이스의 메모리에 저장되는 소프트웨어(예를 들어, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있으며, 컴퓨터 실행 가능 명령어들은, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 도 13 내지 도 17 및 도 19에 도시되는 단계들을 수행한다. 예에서, M2M 디바이스들의 상호 작용에 관해 이하에서 추가로 상세히 설명하면, 도 15의 발신자(161)는 도 23a의 M2M 단말 디바이스(18) 상에 존재할 수 있다. 도 15의 발신자(161), 등록자 노드(164), 및 서비스 노드(165)는 도 23a의 M2M 게이트웨이 디바이스(14) 상에 존재할 수 있다.

본 명세서에서, 서비스 레이어 애니캐스트/썸캐스트를 지원하기 위한 서비스는 SAS(somecast/anycast service)라고 지칭될 수 있다. 도 13은 SAS의 아키텍처(141)의 예시적인 도면이며, 이는 서브-기능들 및 다른 서비스 레이어 엔티티들과의 상호 작용들을 도시한다. 도 13에 도시되고 이하 추가로 논의되는 바와 같은 서브-기능들은 메시지 전-처리(142)(도 14 참조), 서비스 노드들/그룹들 선택(143), 및 사후-선택 처리(144)를 포함한다.

도 14는 메시지 전-처리에 대한 예시적인 방법을 도시한다. 블록 154에서, 파라미터들이 검증된다. 예를 들어, 메시지에 의해 요구되는 값들 및 동작들이 유효한지 여부를 결정하도록 메시지에 있는 파라미터들이 점검된다. SAS를 인에이블하기 위한 정보 및 파라미터가 본 명세서에서 보다 상세히 설명된다. 예를 들어, <container> 리소스가 썸캐스트에 대한 검색 동작만 지원하면, 이러한 리소스 상의 임의의 다른 동작은 애니캐스트/썸캐스트에 대해 유효하지 않은 것으로 고려될 것이다. 썸캐스트/애니캐스트가 요청에 설정되었음을 등록자 노드가 식별하면, SAS는 요청 메시지를 처리하기 시작할 것이다.

계속해서 도 14를 참조하면, 블록 155에서, 애니캐스트/썸캐스트 시나리오가 식별된다. 애니캐스트/썸캐스트의 적절한 시나리오는 수신된 메시지에 있는 정보에 기초할 수 있다. 예를 들어, 다른 것들 중에서, 시나리오가 애니캐스트인지 또는 썸캐스트인지 여부, 그룹 기반인지 또는 비-그룹 기반인지, 또는 다수의 그룹들이 썸캐스트에 대해 관련되는지에 대한 결정이 존재할 수 있다.

블록 156에서, 서비스 노드들의 범위가 결정된다. 이것은 주로 비-그룹 기반 시나리오에 대해서이며, 그 이유는 발신자가 일반적으로 그룹 기반 시나리오에 대한 요청 메시지에서 범위를 정의하기 때문이다. 등록자 노드는 비-그룹 기반 사례에 대해 요청 메시지에 있는 정보에 기초하여 어떤 서비스 노드들이 어떤 범위/영역으로부터 선택되어야 하는지 결정한다. 시나리오를 식별하고 범위를 결정하는 것은 본 명세서에 논의되는 호출 흐름들에서 소개된다.

이제 도 13을 참조하면, 메시지 전-처리(142)는 다른 기능들 또는 서비스 레이어 엔티티들과의 다음과 같은 상호 작용들을 가질 수 있다. 단계 145에서, 메시지 전-처리(142)는 애니캐스트 또는 썸캐스트에 대한 발신자로부터의 요청을 수신할 수 있다. 본 명세서에 논의되는 바와 같이 발신자는 도 23a 내지 도 23d에 관하여 논의되는 바와 같은 M2M 디바이스(18)일 수 있다. 146에서, 메시지 전-처리(142)는 애니캐스트 또는 썸캐스트에 대해 다른 서비스 레이어 노드들로부터 전달된 요청을 수신할 수 있다. 이러한 사례에서는, 그룹 호스팅 노드가 선택될 수 있고 전달된 요청을 수신하며, 애니캐스트 또는 썸캐스트에 대해 하나 이상의 그룹 멤버들을 선택할 수 있다. 단계 147에서, 메시지 전-처리(142)는 식별된 애니캐스트/썸캐스트 시나리오, 서비스 노드들/그룹들의 범위, 또는 애니캐스트/썸캐스트 파라미터를 서비스 노드들/그룹들 선택(143)에 전송할 수 있다.

계속해서 도 13을 참조하면,서비스 노드들/그룹들 선택(143)이 존재할 수 있으며, 이는 메시지 전-처리(142)에 의해 결정되는 범위에 기초하여 서비스 노드들 또는 그룹들을 선택한다. 또한, 원래 선택된 서비스 노드들이 실패 응답을 리턴하면 또는 임의의 메시지 손실이 존재하면 재선택을 수행하도록 서비스 노드들/그룹들 선택(143)이 트리거될 수 있다. 선택 프로세스는 일반적으로 메시지 전-처리(142)의 출력 뿐만 아니라, 선택 방법 및 기준 또는 얼마나 많은 서비스 노드들이 예상되는지와 같은 다른 파라미터들에 기초하여 수행된다. 다수의 그룹들로부터 단일 그룹만 선택되고 그룹 호스팅 노드가 서비스 노드들을 선택하는 것이 또한 가능하다. 서비스 노드 선택은 본 명세서에 논의되는 통화 흐름들에서 소개된다. 서비스 노드들 또는 그룹들을 선택한 후에, 선택된 노드들 또는 그룹들의 정보는 148에서 사후-선택 처리(144)로 전달될 수 있다. 선택된 서비스 노드들 또는 그룹들이 원하는 동작을 수행하는 것에 실패할 때 선택 프로세스가 재선택(149)에 의해 트리거되는 것이 또한 가능하다.

계속해서 도 13을 참조하면, 사후-선택 처리(144)가 존재할 수 있으며, 이는 애니캐스트/썸캐스트에 대한 서비스 노드들 또는 그룹들의 선택 이후 태스크들을 취급하는 것을 담당한다. 태스크들은 선택된 서비스 노드들 또는 그룹들에 메시지를 152에서 전달하는 단계, 151에서 리턴되는 메시지들을 처리하는 단계, 에러 또는 메시지 손실이 존재하면 재송신을 착수하는 단계, 및 150에서 다른 서비스 레이어 기능들(예를 들어, 그룹 관리)을 트리거하는 단계를 포함할 수 있다. 재송신을 착수하기 위해, 선택된 서비스 노드들이 실패하거나 요청을 거절하기 때문에 재선택 프로세스를 트리거하게될 가능성이 있다. 재송신에 대한 상이한 방식들이 본 명세서에서 보다 상세히 논의된다. 그룹 관리와 같은 다른 서비스 레이어 동작들을 트리거하기 위해, 이것은 발신자 요청 및 서비스 레이어 구성에 의존하는 옵션형이다.

종래의 서비스 레이어는 애니캐스트 및 썸캐스트 서비스를 지원하기 위한 정보 및 메커니즘들을 정의하지 않는다. 서비스 레이어에서 애니캐스트 및 썸캐스트 통신을 인에이블하는데 도움이 될 수 있는 정보가 이하 보다 상세히 논의된다. 서비스 레이어 애니캐스트 및 썸캐스트를 인에이블하기 위해 발신자(예를 들어, 도 15의 발신자(161))로부터의 요청 메시지에 포함되는 정보는, 다른 것들 중에서, 애니캐스트/썸캐스트 표시, 서비스 노드들의 수, 그룹 관련 타입, 그룹 ID, 그룹 선택 인에이블먼트, 재송신 옵션, 그룹 관리 트리거, 서비스 노드 ID 요건, 및 선택 기준/방법과 같은 정보 중 하나 이상을 포함할 수 있다.

애니캐스트/썸캐스트 표시는 요청 메시지에 포함되는 동작에 대해 애니캐스트/썸캐스트 통신이 요구됨을 표시할 수 있다. 서비스 노드들의 수의 표시는 애니캐스트/썸캐스트 통신에 대한 메시지에서 사용될 수 있다. 애니캐스트에 대해, 요구되는 수는 1이다. 1보다 큰 임의의 수는 썸캐스트를 암시한다. 그룹 관련 타입에 대하여, 애니캐스트/썸캐스트 동작이 그룹 기반인지 또는 비-그룹 기반인지 표시할 수 있다. 하나보다 많은 그룹이 애니캐스트/썸캐스트 프로세스에 관련될 수 있다. 그룹 기반 애니캐스트/썸캐스트가 존재하면, 그룹 ID는 그룹 식별자(예를 들어, <group> 리소스의 URI)를 표시한다.

애니캐스트/썸캐스트와 관련된 메시지는 재송신 옵션을 포함할 수 있으며, 이는 실패가 발생할 때 사용될 재송신 접근방식을 표시한다. 재송신 옵션 파라미터는 하나보다 많은 옵션들을 포함할 수 있으며, 이는 상이한 선호도들로 할당된다. 예를 들어, 재송신 옵션 파라미터에는 세트 '재선택(reselection)' 옵션 또는 '재송신(retransmission)' 옵션이 존재할 수 있다. 재선택에 대하여, 선택된 서비스 노드가 실패 응답을 리턴하면, 등록자 노드는 먼저 다른 서비스 노드를 재선택하려고 시도한다는 것을 의미할 수 있다. 등록자 노드가 다른 자격을 갖춘 서비스 노드를 찾을 수 없는 경우에만, 선택된 서비스 노드에 메시지를 재송신할 것이다. 재송신 접근방식은 본 명세서에 다루어 진다. 명백히 하자면, 재선택 옵션은, 예를 들어, 제1 서비스 노드가 실패하거나 요청을 거절할 때 다른 서비스 노드(또는 이와 유사한 것)를 선택하고 요청을 전송하기 위한 것일 수 있다. 재송신 옵션은, 예를 들어, 선택된 노드에 요청을 재송신하는 것일 수 있다.

애니캐스트/썸캐스트와 관련된 메시지는 그룹 관리 트리거링을 포함할 수 있으며, 이는 일단 원하는 동작이 애니캐스트/썸캐스트를 통해 성공적으로 수행되면 그룹 관리 동작(예를 들어, 신규 그룹 생성, 2개의 그룹들 병합)을 표시한다. 그룹 관리 동작은 특정 그룹 관리 정책들 및 규칙들에 의해 또한 트리거될 수 있다. 예를 들어, 서비스 제공자는 동일한 애플리케이션에 의해 생성되는 모든 <container> 리소스들이 용이한 관리를 위해 그룹화되어야 한다는 규칙을 설정할 수 있다.

애니캐스트/썸캐스트와 관련된 메시지는 선택된 서비스 노드의 ID가 발신자(161)에 대한 응답에서 요구되는지 표시하는 서비스 노드 ID 파라미터를 포함할 수 있다. 일반적으로, 발신자(161)는 어떤 서비스 노드가 선택되는지 신경 쓰지 않고 인식하지 않으며, 애니캐스트 및 썸캐스트에 대해 원하는 동작을 수행한다. 일부 사례들에서는, 서비스 노드 ID 또는 어드레스가 제공되면 이로울 것이다. 예를 들어, 발신자(161)는 일부 데이터를 저장하는 3개의 <container> 리소스들을 생성하라고 요청한다. 리소스를 생성한 서비스 노드들의 ID를 발신자(161)가 알면, 발신자(161)는 장래에 신규 리소스를 관리하기 위해 서비스 노드를 직접 액세스할 수 있다.

애니캐스트/썸캐스트와 관련된 메시지는 애니캐스트 및 썸캐스트 통신에 대한 서비스 노드를 선택하기 위한 기준 또는 방법의 세트를 포함할 수 있다. 서비스 노드를 선택하기 위한 기준 또는 방법에 대한 제1 예에서는, 랜덤 선택의 인에이블먼트가 존재할 수 있으며, 이는 서비스 노드들 또는 그룹들이 범위 내에서 랜덤하게 선택될 수 있음을 표시한다. 서비스 노드를 선택하기 위한 기준 또는 방법에 대한 제2 예에서는, 서비스 노드들이 위치(논리적 위치 또는 물리적 위치일 수 있음)에 기초하여 선택될 수 있으며, 예를 들어, 선택된 서비스 노드는 서비스 제공자 1의 네트워크 내에 있어야 한다. 위치 기준은 발신자에 의해 구성될 수 있다. 서비스 노드를 선택하기 위한 기준 또는 방법에 대한 제3의 예에서는, 서비스 노드가 로드 밸런싱에 기초하여 선택될 수 있다. 예를 들어, 다른 잠재적 서비스 노드보다 트래픽 로드가 적은 서비스 노드들, 예를 들어, 그룹 호스팅 노드는 유휴인 센서에 요청을 전달하거나 또는 온도 판독 사항들을 검색하기 위한 더 적은 수의 요청들을 서비스한다. 서비스 노드를 선택하기 위한 기준 또는 방법에 대한 제4 예에서는, 서비스 노드가 라우팅에 기초하여 선택될 수 있다. 예를 들어, 발신자로부터 최소 수의 홉들을 갖는 서비스 노드들에 기초하는 선택. 서비스 노드를 선택하기 위한 기준 또는 방법에 대한 제5 예에서는, 기본 네트워킹 프로토콜들에 기초할 수 있다. 예를 들어, 서비스 노드들은 발신자(161)와 동일한 기본 전송 레이어(예를 들어, CoAP)를 지원하는 것에 기초하여 선택될 수 있다. 마지막으로, 서비스 노드를 선택하기 위한 기준 또는 방법에 대해 고려되는 다른 컨텍스트 정보가 존재할 수 있다. 예를 들어, 발신자는 감지의 정확도, 계산 능력, 시간 인식, 및 휴면 스케줄과 같은 컨텍스트 정보를 또한 명시할 수 있다.

표 1은 도 11과 관련될 수 있는 요청 메시지의 예를 도시한다. 썸캐스트/애니캐스트와 관련된 속성들/파라미터들이 표 1에 제공된다.

또한, 애니캐스트 및 썸캐스트에 관한 일부 정보는 서비스 레이어에서 관리될 수 있고, 그래서 서비스 레이어는 애니캐스트 또는 썸캐스트에 대한 요청을 수신할 때 요청 메시지에 있는 파라미터들을 검증할 수 있다. 명확성을 위해, SAS는 서비스, 예를 들어 CSE에서의 CSF일 수 있다. 그러나 SAS는 또한 다른 서비스들에 통합되거나 또는 그렇지 않으면 다른 서비스들과 함께 제공될 수 있다. 썸캐스트/애니캐스트 정보는 서비스 레이어 소유자/제공자에 의해 서비스 레이어에서 구성되고 유지될 수 있다. 구현하기 위해, 서비스 레이어에 대해 정의되는 신규 속성들 또는 파라미터들이 존재할 수 있다. 제1 예시적 속성은 anycastSomecastEnable일 수 있으며, 이는 애니캐스트/썸캐스트 통신이 서비스 노드 또는 구체적인 리소스 상에서 인에이블되는지 여부를 표시한다. 제2 예시적 속성은 supportOpAnycastSomecast일 수 있으며, 이는 애니캐스트/썸캐스트에 대해 허용되는 동작들의 타입들을 표시한다. 예를 들어, 온도 판독 사항들을 저장하는 일부 <container> 리소스에 대해서는, 애니캐스트/썸캐스트에 대해 RETRIEVE 동작들만 허용될 수 있다. 달리 말하면 이러한 예에서, 발신자(161)는 애니캐스트 또는 썸캐스트를 통해 <container> 리소스들의 서브-세트를 업데이트하라고 또는 삭제하라고 요청할 수 없다. 제3 예시적 속성은 mixedTypesEnable일 수 있으며, 이는 썸캐스트를 통해 혼합된 타입들의 서비스 노드들 또는 리소스들 상에서 동작이 수행될 수 있는지 여부를 표시한다. 이것은 그룹에 관련되고, 이는 멤버 리소스들 그룹을 포함한다. 멤버 리소스들의 타입은 동일하거나 또는 상이할 수 있다. mixTypeEnable는 썸캐스트를 통해 상이한 타입들의 멤버 리소스들 상에서 동작을 수행하라고 발신자가 요청할 수 있는지 의미한다.

도 15는 서비스 레이어에서의 비-그룹 기반 애니캐스트/썸캐스트에 대한 예시적인 방법 흐름을 도시한다. 서비스 레이어에서 비-그룹 기반 애니캐스트/썸캐스트를 지원하는 프로시저들에 대해 이하 논의된다. 비-그룹 기반 애니캐스트/썸캐스트는 어떠한 그룹 정보도 명백하게 명시하지 않는 발신자를 특징으로 하고, 한편 서비스 노드들의 범위를 결정하는데 도움이 되는 조건들을 제공할 수 있다. CREATE 동작이 예로서 사용되고 서비스 노드(166)는 서비스 노드(165)에 의해서만 도달 가능하다. 이하 소개되는 프로시저들은 썸캐스트를 예로서 사용하며, 그 이유는 애니캐스트가 썸캐스트의 특별한 사례로 고려될 수 있기 때문이며, 여기서 요구되는 서비스 노드들의 수는 1이다.

계속해서 도 15를 참조하면, 단계 168에서, 발신자(161)(예를 들어, oneM2M에 있는 애플리케이션 엔티티)는 일부 <container> 리소스들을 생성하기 위한 요청을 등록자 노드(164)에 전송한다. 단계 168의 요청 메시지에서, 썸캐스트 관련 파라미터들은 요청 메시지에서 명시될 수 있다. 예를 들어, 썸캐스트 파라미터들은 표 2에 도시되는 바와 같이 설정될 수 있다. 호출 흐름에는 도시되지 않지만, 서비스 노드들의 수를 표시하는 대안적인 방식들이 존재한다. 하나의 대안적인 예에서, 단계 168의 요청 메시지는 서비스 노드들의 수의 범위, 예를 들어, 최소 수가 2이고 최대 수가 5임을 표시하는 (2, 5)를 포함한다. 이것은 등록자 노드(164)에게 노드들을 선택하는 것에 대한 일부 유연성을 제공한다. 또 다른 방식은 등록자 노드(164)가 유연한 수의 서비스 노드들을 선택하는 것을 허용하는 'numberflexibilityIndicator' 플래그를 단계 168의 요청 메시지가 설정한다는 것이다. 등록자 노드(164)가 애니캐스트/썸캐스트를 지원하지 않으면, 일부 파라미터들이 지원되지 않기 때문에 단계 168의 요청 메시지가 무효 메시지로서 취급될 수 있고, 요청 메시지는 애니캐스트/썸캐스트를 포함하는 응답이 인에이블되지 않음 등을 리턴한다.

계속해서 도 15를 참조하면, 단계 169에서, 등록자 노드(164)는 단계 168의 요청 메시지를 수신하고 요청 메시지에 있는 파라미터들을 검증한다. 예를 들어, 등록자 노드(164)는 신규 리소스를 생성하기 위해 애니캐스트/썸캐스트가 허용되는지 점검한다. 다음으로 등록자 노드(164)는 애니캐스트/썸캐스트에 대한 시나리오를 식별한다. 이러한 예에서는, 비-그룹 기반 썸캐스트가 명시되고, 따라서 등록자 노드(164)가 서비스 노드들의 범위를 결정한다. 범위를 결정하기 위해, 등록자 노드(164)는 단계 168의 요청 메시지에 있는 선택 기준 및 자신이 등록한 서비스 레이어 네트워크를 참조할 수 있다. 단계 170에서, 등록자 노드(164)는 선택 기준 및 결정된 범위에 기초하여 서비스 노드들을 선택한다. 도 15의 방법 흐름에서는, 등록자 노드(164)에 등록한 서비스 노드(163) 및 서비스 노드(162)가 선택된다. 등록자 노드(164)는 다음으로 각각의 선택된 서비스 노드에 대한 요청 메시지를 생성한다. 단계 171에서, 등록자 노드(164)는 선택된 노드들(예를 들어, 서비스 노드(163) 및 서비스 노드(162))에 각각 CREATE 요청을 전송한다. 단계 172에서, 응답 메시지들이 등록자 노드(164)에 의해 수신된다. 응답 메시지들은 서비스 노드(163) 및 서비스 노드(162)에 의해 그들이 CREATE 동작을 성공적으로 완료할 때 전송될 수 있다. 본 명세서에서는 선택된 노드들(예를 들어, 서비스 노드(163) 및 서비스 노드(162))이 동작을 성공적으로 수행한다고 가정된다. 실패 사례 및 대응하는 재송신 프로세스에 대처하는 방법들이 본 명세서에 논의된다.

계속해서 도 15를 참조하면, 등록자 노드(164)는 이러한 사례에서 후보들인 3개의 서비스 노드들만을 알고 있지만, 하나는 자격이 없는 IN-CSE이다. 자격을 갖춘 서비스 노드는 서비스 노드가 단계 168의 요청 메시지에 있는 조건들을 충족함을 의미한다. 등록자 노드(164)는 추가의 선택을 위해 다른 서비스 노드들에 요청을 전달할 필요가 있는지 결정한다. 일반적으로, 등록자 노드(164)는 그 수의 서비스 노드들에 접속하지 않거나, 또는 그 수의 자격을 갖춘 노드들에 접속하지 않거나, 또는 일부 자격을 갖춘 노드들이 그 요청을 거절하기 때문에 필요한 만큼 많은 서비스 노드들을 선택할 수 없다는 것이 가능하다. 이러한 사례에서 단계 173에서, 등록자 노드(164)는 애니캐스트 요청을 서비스 노드(165)에 전달할 수 있으며, 이는 요청을 완료하기 위해 하나 이상의 서비스 노드를 선택할 것이다. 리마인더로서 애니캐스트는 썸캐스트의 특별한 사례로 고려될 수 있으며, 여기서 요구되는 서비스 노드의 수는 1이다. 따라서, 단계 172가 성공적이면, 단계 173 내지 단계 179는 애니캐스트에 필요하지 않다.

계속해서 도 15를 참조하면, 단계 174에서, 등록자 노드(164)는 썸캐스트 요청 메시지를 서비스 노드(165)에 전달한다. 서비스 노드들의 수가 1이라는 것을 제외하고는 이러한 메시지에 있는 내용은 단계 168의 요청 메시지의 내용과 실질적으로 동일할 수 있고, 애니캐스트가 예상된다는 것을 표시한다. 등록자 노드(164)에 의해 선택되는 2개의 서비스 노드들은 이미 리소스를 생성하였고 따라서 하나만 더 필요하다. 단계 175에서, 서비스 노드(165)는 단계 169 및 단계 170과 유사한 동작들을 뒤따른다. 단계 179에서, 단계 171 및 단계 172와 유사한 동작들이 뒤따른다. 단계 177에서, 등록자 노드(164)는 단계 174의 요청 메시지와 관련된 응답 메시지를 수신한다. 응답 메시지는, 다른 것들 중에서, 파라미터를 표시할 수 있거나, 또는 요청이 완료되었음을 표시할 수 있다.

계속해서 도 15를 참조하면, 단계 178에서, 단계 168의 요청이 일단 달성되면(예를 들어, 이러한 사례에서는 3개의 서비스 노드들이 <container> 리소스들을 성공적으로 생성함), 등록자 노드(164)는 신규로 생성된 리소스들을 관리하기 위해 그룹을 생성할 필요가 있는지 결정할 수 있다. 이렇게 하는 것은 일부 혜택들을 갖을 수 있다. 이러한 사례에 대해, 3개의 신규 <container> 리소스들은 그룹 관리 방법을 통해 관리, 검색 및 액세스될 수 있으며, 이는 보다 효율적이다. 다른 가능한 사례는 발신자(161)가 3개의 신규 리소스들을 기존 그룹에 추가하라고 요청할 수 있다는 것이며, 이는 발신자(164)에 의해 생성되고 관리되는 리소스들의 목록를 포함한다. 임의의 그룹 관련 동작들을 수행할지는 상이한 요인들에 의존할 수 있다. 예를 들어, 하나의 요인은 발신자(164)가 요청 메시지에서 구체적인 그룹 관리 관련 동작을 명시적으로 요청하는지 일 수 있다. 다른 요인은 구체적인 그룹 관리 동작이 서비스 레이어 구성에 기초하여 수행되어야하는지의 결정에 기초할 수 있다. 예를 들어 서비스 레이어 플랫폼은 리소스들이 동일한 타입의 것인 한 효율적인 관리를 위해 썸캐스트를 통해 생성되는 리소스들이 함께 그룹화될 것을 요구하는 방식으로 구성될 수 있다. 또한, 단계 178에 대한 그룹 관련 동작은 이러한 프로세스에서의 예에 불과하다. 이러한 옵션형 단계는 액세스 제어 및 과금과 같은 다른 양상들에 관련될 수 있다. 단계 179에서, 등록자 노드(164)는 응답을 발신자(164)에게 전송하며, 이는 단계 168의 요청과 관련된 요청된 리소스들 생성하는 서비스 노드들의 ID를 포함할 수 있다.

도 15의 시나리오를 계속 참조하면, 등록자 노드(164)가 요청된 만큼 많은 서비스 노드들을 선택하는데 실패하는 사례에서는, 다른 라운드의 선택을 수행하라는 썸캐스트 요청을 다른 서비스 노드에 전달하는 대신에, 대안적인 방식은 등록자 노드가 발견 프로세스를 수행하고, 고려될 수 있는 일부 다른 자격을 갖춘 서비스 노드들에 관한 보다 많은 정보를 획득하는 것이다. 이러한 발견 단계는 도 15에 도시되는 바와 같이 단계 173으로부터 착수될 수 있다. 등록자 노드(164)에서 발견을 인에이블하기 위해, 발신자(161)는 "optionalAction"이라 불리우는 옵션형 플래그를 요청 메시지에서 설정할 수 있으며, 이는 등록자 노드가 요청된 수의 서비스 노드들을 찾지 못하면 행해야 할 것을 표시한다. "optionalAction"의 가능한 값들은 없음, 발견, 전달 등이다.

도 16a 및 도 16b는 서비스 레이어에서의 그룹 기반 애니캐스트/썸캐스트에 대한 예시적인 방법 흐름을 도시한다. 비-그룹 기반 시나리오와 대조적으로, 발신자(161)는 그룹 ID, <group> 리소스의 URI, 또는 서비스 노드들의 어드레스의 목록과 같은 그룹 정보를 제공한다. 그룹 기반 애니캐스트 및 썸캐스트에 대해 하나보다 많은 그룹이 관련될 수 있다. 예를 들어, 영역의 온도 판독 사항들에 관심이 있는 애플리케이션은 상이한 오퍼레이터들에 의해 관리되는 여러 그룹들의 센서들이 데이터를 제공할 수 있다는 것을 알 수 있고, 그래서 이러한 애플리케이션은 자신의 등록자 노드(161)에게 애니캐스트 또는 썸캐스트를 통해 온도 데이터를 검색하기 위한 모든 이러한 그룹들에 관하여 통보할 수 있다. 따라서, 등록자 노드는 그룹 호스팅 노드 중 임의의 것에 요청 메시지를 전달하기 이전에 그룹을 선택하는 것이 요구될 수 있다. 다수-그룹 시나리오는 하나의-그룹 시나리오에 대한 일반적인 사례이며, 여기서 그룹 선택 동작은 생략된다.

도 16a는 그룹 선택이 수행되지 않는 예시적인 방법 흐름을 도시하고, 한편 도 16b는 그룹 선택이 수행되는 예시적인 방법 흐름을 도시한다. 도 16a 및 도 16b 양자 모두에 대해, RETRIEVE 동작이 예로서 사용된다.

도 16a를 참조하면, 단계 191에서, 등록자 노드(184)는 내용을 검색하기 위한 요청을 수신한다. 단계 191의 요청 메시지에는, 표 3에 제공되는 애니캐스트/썸캐스트에 관련되는 파라미터들을 포함한다. 그룹 선택이 없다는 것은 등록자 노드가 요청 메시지를 전달하기 이전에 그룹을 선택할 필요가 없음을 암시한다. 발신자(181)는 2개의 그룹들에서 타겟화하기 때문에, 서비스 노드는 그룹 1로부터만, 그룹 2로부터만, 또는 양쪽 그룹들 모두로부터 선택될 수 있다. 도 16a는 그룹 선택이 없는 프로시저를 도시한다.

계속해서 도 16a를 참조하면, 단계 192에서 등록자 노드(184)는 단계 191의 요청 메시지에 있는 파라미터들을 검증한다. 등록자 노드(184)는 2개의 그룹들이 썸캐스트에 대해 관련되고, 그룹 선택이 요구되지 않는다는 것을 식별한다. 단계 193에서, 등록자 노드(184)는 그룹 호스팅 노드들, 그룹 1 호스팅 노드(183) 및 그룹 2 호스팅 노드(185)에 요청 메시지를 전송한다. 등록자 노드(184)는 자신이 전달하는 각각의 요청에서 서비스 노드들의 수 및 그룹 ID를 제공한다. 요청을 전달하기 이전에, 등록자 노드(184)는 요구되는 노드들의 수를 그룹 1에 대해 1개로 그리고 요구되는 노드들의 수를 그룹 2에 대해 2개로 설정하라는 결정을 행한다. 단계 194a에서, 그룹 1 호스팅 노드(183)는 단계 193의 요청 메시지를 처리하고, 그것이 그룹 기반 애니캐스트임을 식별한다. 따라서, 그룹 1 호스팅 노드(183)는 자신의 그룹 멤버들 중 요청된 동작을 수행할 하나를 선택한다. 단계 193의 요청은, 애니캐스트/썸캐스트, 타입: 그룹, 요구되는 수: 1(2), 타겟: /group1(/group2), 검색할 콘텐츠, selectionCriteria를 포함할 수 있다. 단계 194b에서, 그룹 2 호스팅 노드(185)에서의 SAS는 단계 194a와 유사한 프로세스를 뒤따른다. 그러나, 그룹 2 호스팅 노드(185)는 요청된 동작을 수행할 2개의 그룹 멤버들을 선택하고, 그 이유는 그룹 기반 썸캐스트가 2개의 서비스 노드들로 요청된다는 것을 등록자 노드로부터의 요청이 표시하기 때문이다.

계속해서 도 16a를 참조하면, 단계 195a에서, 그룹 1 호스팅 노드(183)는 그룹 1 멤버 노드들(182)의 선택된 그룹 멤버에 요청들을 전송하고, 이에 따라 응답을 수신한다. 단계 195b에서, 이것은 선택된 그룹 멤버들(예를 들어, 그룹 2 멤버 노드들(186))과 요청 및 응답 메시지들을 교환하는 단계 195a와 유사한 프로세스이다. 단계 196a 및 단계 196b에서, 그룹 1 호스팅 노드(183) 및 그룹 2 호스팅 노드(185)는, 각각, 요청된 동작이 그룹 1 멤버 노드들(182) 및 그룹 2 멤버 노드들(186)의 선택된 그룹 멤버들에 의해 성공적으로 수행되었음을 표시하는 응답 메시지들을 등록자 노드(184)에 전송한다. 단계 197에서, 등록자 노드(184)는 서비스 노드들의 수가 요청된 바와 같은 동작을 수행하기에 충분한지 확인한다. 단계 198에서, 등록자 노드(184)는 단계 191의 요청 메시지와 관련된 응답 메시지를 발신자(181)에게 전송한다.

그룹 선택과 관련된 도 16b가 이하 논의된다. 단계 201 및 단계 202는 도 16a의 단계 191 및 단계 192와 유사하다. 단계 203에서, 단계 201의 요청 메시지에서 그룹 선택이 요구되는 대로 표시되고, 등록자 노드는 썸캐스트 요청을 전달하기 이전에 다른 것을 통해 그룹을 선택하는 것을 담당한다. 이러한 사례에서는, 그룹 2가 선택된다. 등록자 노드(184)는, 단계 201의 요청 메시지에 있는 선택 기준에 기초하여, 로컬하게 유지되는 서비스 레이어 구성에 기초하여, 등으로 선택을 행할 수 있다. 예를 들어, 등록자 노드(184)는 보다 많은 그룹 멤버들이 있는 그룹을 선택할 수 있으며, 이는 보다 큰 선택 기반을 의미한다. 등록자 노드(184)는 보다 많은 서비스 레이어 클라이언트들 또는 가입자들을 갖는 그룹을 선택할 수 있어, 썸캐스트를 통해 원하는 동작을 수행하는 것에 의해 보다 많은 클라이언트들 또는 가입자들에게 신규 특징/서비스가 통지될 수 있다. 단계 204에서, 등록자 노드(184)는 단계 201의 요청으로부터 그룹 ID를 업데이트하는 것에 의해 그룹 2 호스팅 노드(185)에 썸캐스트 요청을 전송한다. 단계 204의 요청은, 애니캐스트/썸캐스트, 타입: 그룹, 타겟: /그룹 2 요구되는 수: 3, 검색할 콘텐츠, selectionCriteria를 포함할 수 있다. 단계 205 내지 단계 207은 도 15의 단계 175 내지 단계 177과 유사한 동작들을 뒤따른다. 단계 208에서, 등록자 노드(184)는 요청된 바와 같이 충분한 수의 성공 동작들이 존재하는지 확인한다. 단계 209에서, 등록자 노드(184)는 응답을 발신자(181)에 전송한다. 대안적으로, 단계 202는 그룹 호스팅 노드(185)가 등록자 노드(184)로부터 애니캐스트/썸캐스트 요청을 수신할 때 그룹 2 호스팅 노드(185)에 의해 행해질 수도 있다. 이러한 의미에서, 등록자 노드(184)는 그룹을 직접 선택하고 각각의 그룹에 대해 요구되는 수를 결정하는 것으로 고려될 수 있다.

재송신 접근방식들이 이하 논의된다. 도 15, 도 16a, 및 도 16b는 프로세스 동안 처리 에러들도 메시지 손실들도 존재하지 않아, 재송신이 요구되지 않는다고 가정하여 비-그룹 기반 및 그룹 기반 애니캐스트/썸캐스트 양자 모두의 프로시저들을 도시한다. 메시지 손실(예를 들어, 기본 프로토콜 레이어에서의 패킷 손실) 또는 처리 에러(예를 들어, 거절된 요청)에 대한 재송신이 존재할 수 있다. 도 17에 도시되는 재송신 동작들을 수행하기 위한 다수의 옵션들이 존재한다. 요약하고 이하 보다 상세히 논의되는 옵션 219에 대해, 등록자 노드(184)가 비-그룹 기반 시나리오에 대해 다른 서비스 노드를 선택하거나, 또는 그룹 호스팅 노드가 그룹 기반 시나리오에 대해 동일한 그룹으로부터 상이한 그룹 멤버 노드를 선택한다. 요약하고 이하 보다 상세히 논의되는 옵션 220에 대해, 등록자 노드(184)가 비-그룹 기반 시나리오에 대해 선택된 서비스 노드에 요청을 재송신하거나, 또는 그룹 호스팅 노드가 선택된 그룹 멤버 노드에 요청을 재송신한다. 경우에 따라서는, 이러한 옵션이 사용되지 않을 것이다. 예를 들어, 선택된 서비스 노드가 일부 액세스 제어 쟁점으로 인해 요청을 거절하거나, 또는 선택된 서비스 노드가 리소스를 단지 삭제하고, 한편 애니캐스트 요청은 삭제된 리소스로부터 데이터를 검색하는 것이다. 요약하고 이하 보다 상세히 논의되는 옵션 230에 대해, 선택된 그룹 멤버들로부터 성공 응답을 얻는데 실패할 때 그룹 호스팅 노드는 등록자 노드로 리턴한다. 신규 서비스 노드를 선택하기 위해 상이한 그룹으로 이동한다. 이러한 옵션은 일반적으로 여러 그룹들이 관련될 때의 그룹 기반 시나리오에 대한 것이다.

도 17을 참조하면, 단계 210은 사전-구성에 대한 일련의 단계들을 포함하며, 이는 발신자(181)가 오직 하나의 서비스 노드에게 동작(예를 들어, 애니캐스트)을 수행하라고 요청한다는 것을 제외하고는, 도 16b에 도시되는 바와 같은 단계 201 내지 단계 205를 뒤따른다. 이러한 예에서의 애니캐스트의 사용은 주로 재송신 접근방식의 도시의 용이성에 대한 것이다. 발신자(181)은 관련된 2개의 그룹들이 있는 애니캐스트 요청을 착수한다. 등록자 노드(184)는 그룹 선택 요청을 수행하고 썸캐스트 요청을 그룹 2 호스팅 노드(185)에 전송한다. 다음으로 그룹 2 호스팅 노드(185)는 하나의 그룹 멤버를 선택한다. 단계 211에서, 그룹 2 호스팅 노드(185)는 단계 210에서 제공되는 바와 같이 요청된 동작을 수행하기 위해 선택된 그룹 멤버에게 요청 메시지를 전송한다. 단계 212에서, 재송신을 도시하기 위해, 그룹 2 멤버 노드(187)로부터의 것을 표시하는 그룹 2 호스팅 노드(185)에 의해 수신되는 실패 응답이 존재한다. 단계 213에서, 그룹 2 호스팅 노드(185)는, 존재한다면, 어떤 재송신이 요구되는지 결정하기 위해 애니캐스트 요청 메시지를 점검한다. 발신자(181)가 어떠한 재송신 방법도 명시하지 않으면, 디폴트 방법이 사용될 것이다. 그룹 2 호스팅 노드(185)가 메시지 손실로 인해 응답을 얻지 못하는 것 또한 가능하다. 이러한 사례에서는, 그룹 2 호스팅 노드(185)는 응답이 타임 아웃될 때 재송신 프로세스를 착수할 수 있다.

도 17의 옵션 219을 참조하면, 단계 214에서, 그룹 2 호스팅 노드는 다른 그룹 멤버를 선택하기로 결정하고, 그룹 2 멤버 노드(188)를 선택한다. 그룹 2 호스팅 노드(185)가 발신자(181)에 의해 설정된 요건들을 충족시키는 임의의 자격을 갖춘 그룹 멤버를 찾을 수 없는 것이 가능하다. 이러한 시나리오에서, 그룹 2 호스팅 노드(185)는 대안적인 재송신 방법을 대신 이용할 수 있다. 다수의 재송신 방법들이 발신자(181)에 의해 명시될 수 있고, 따라서 제1 옵션이 작동하지 않으면(예를 들어, 이러한 사례에서는 자격을 갖춘 그룹 멤버가 더 이상 없음), 그룹 2 호스팅 노드(185)는 제2 옵션으로 전향할 수 있다. 단계 215에서 그리고 단계 216에서, 요청 및 성공 응답 교환은, 각각, 그룹 2 호스팅 노드(185)와 그룹 2 멤버 노드(188) 사이에서 발생한다. 단계 217에서, 등록자 노드(184)는 단계 210의 요청과 관련된 응답을 수신한다. 단계 218에서, 등록자 노드(184)는 발신자(181)에게 단계 210의 요청과 관련된 응답을 전송한다.

도 17의 옵션 220을 참조하면, 단계 221에서, 이러한 옵션에 대해, 그룹 2 호스팅 노드(185)는 선택된 그룹 멤버(예를 들어, 그룹 2 멤버 노드(187))에게 요청을 재송신하기로 결정한다. 이러한 결정을 행하기 이전에, 그룹 2 호스팅 노드(185)는 그룹 2 멤버 노드(187)가 요청된 동작을 성공적으로 수행하는 것이 가능한지 확인할 수 있다. 예를 들어, 그룹 2 멤버 노드(187)가 검색 동작을 위해 콘텐츠를 저장하는 리소스를 이미 삭제하였으면, 그룹 2 호스팅 노드(185)는 재송신을 위해 옵션 220을 사용하지 않을 것이며 대안적인 옵션으로 전향한다. 그룹 2 호스팅 노드(185)는 단계 212의 응답에 있는 응답 코드를 점검하여 실패 원인을 식별할 수 있다. 단계 222에서 그리고 단계 223에서, 요청 및 성공 응답 교환은, 각각, 그룹 2 호스팅 노드(185)와 그룹 2 멤버 노드(187) 사이에서 발생한다. 단계 224에서, 등록자 노드(184)는 단계 210의 요청과 관련된 응답을 수신한다. 단계 225에서, 등록자 노드(184)는 단계 210의 요청과 관련된 응답을 발신자(181)에게 전송한다.

도 17의 옵션 230을 참조하면, 단계 221에서, 그룹 2 호스팅 노드(185)는 재송신을 위해 등록자 노드(184)로 되돌아 간다. 또한, 그룹 2 호스팅 노드(185)는 이전의 두 옵션이 작동하지 않기 때문에(예를 들어, 자격을 갖춘 그룹 멤버가 더 이상 없고 선택된 그룹 멤버가 요구되는 동작을 수행할 수 없음) 이러한 옵션을 사용할 수 있다. 단계 232에서, 그룹 2 호스팅 노드(185)는 실패 원인을 표시하는 응답을 등록자 노드(184)에 전송한다. 단계 233에서, 등록자 노드(184)는 실패 원인 및 재송신 옵션을 식별하고, 애니캐스트 요청에 대해 그룹 1로 가기로 결정한다. 단계 234 내지 단계 239에서, 등록자 노드는 애니캐스트 요청을 그룹 1 호스팅 노드(183)에 전송하며, 이는 애니캐스트에 대한 단계들을 뒤따른다. 이러한 단계들은 도 16b에 도시되는 단계 204 내지 단계 209와 유사하다.

도 18은 개시된 SAS를 종래의 oneM2M 기능 아키텍처에 기초하는 신규 SL 썸캐스트/애니캐스트 CSF(244)로서 구현하기 위한 예를 도시한다. 대안적으로, 개시된 SAS는 종래의 그룹 관리 CSF의 일부로서 구현되고 추가될 수도 있다.

애니캐스트 및 썸캐스트를 인에이블하는 리소스에 대해서는 이하 표 4에 도시되는 공통 속성들이 개시된다.

발신자(예를 들어, 발신자(181))로부터 수신자(예를 들어, 등록자 노드(184))로, Mca 및 Mcc 참조 지점들을 통하는 요청들은 표 5에 도시되는 바와 같은 파라미터들을 포함할 수 있다.

종래의 oneM2M 그룹 관리를 통해 그룹 기반 애니캐스트/썸캐스트를 지원하는 것이 가능하다. 표 6에 목록화되는 바와 같이 <group> 리소스에 대해 일부 속성들이 개시된다.

도 19는 oneM2M 그룹 관리 등에 대한 예시적인 썸캐스트/애니캐스트 방법 흐름들을 도시한다. 요약하면, 제1 접근방식(예를 들어, 도 19의 사례 271)에서, 그룹 호스팅 CSE(252)는 AE(251)(예를 들어, 발신자)로부터의 요청에 기초하여 요청된 수의 그룹 멤버들을 선택하고, 각각의 선택된 멤버 호스팅 CSE(예를 들어, 멤버 호스팅 CSE(254) 또는 멤버 호스팅 CSE(255))에게 요청을 전달한다. 제2 접근방식(예를 들어, 도 19의 사례 272)에서, 그룹 호스팅 CSE(252)는 AE(251)에 의해 요청되는 수보다 많은 수의 그룹 멤버들을 선택한다. 그룹 호스팅 CSE(252)는 충분한 수의 응답들을 수집한 이후 응답들을 종합하고 종합 응답을 AE(251)에 전송한다. 그룹 호스팅 CSE(252)는 충분한 수의 응답들이 도달된 이후에 응답들을 무시할 수 있다. 이것은 시간에 민감한 일부 애플리케이션들/서비스들에 대해 유용할 수 있다. 예를 들어, 모니터링 서비스는 원자력 발전소로부터의 실시간 온도 판독 사항들을 제공하여 동작을 조절한다. 비상 사태가 발생하면, 온도 판독 사항들을 안정적이고 신속하게 리턴하는 것이 요구될 수 있다. 일부 센서들이 고장 날 잠재성이 존재하고 그룹 호스팅 CSE(252)가 그것을 인식하지 못할 수 있다. 이러한 접근방식은 선택된 그룹 멤버들이 에러들을 갖는 사례에서 애니캐스트/썸캐스트에 대해 일정 정도의 신뢰성을 제공할 수 있다.

도 19가 이하 보다 상세히 논의된다. 단계 261에서, AE(251)는 가상 리소스 <fanOutPoint>를 타겟화하는 요청을 전송하고, 2개의 그룹 멤버들에게 동작들을 수행하라고 요청한다. 이러한 요청은 다음을 포함할 수 있다:(<group>/<FanOutPoint>, anycastSomecastIndicator: 설정, numberOfAnycastSomecastNode: 2, groupBasedIndication: 그룹 기반, serviceNodeSelectionCriteria: 랜덤 선택, retransOption: 그룹 멤버 재선택, reliableRequirement: 요구되는 신뢰성). 단계 262에서, 그룹 호스팅 CSE(262)는 단계 261의 요청 메시지에서 발견되는 수신된 파라미터들을 검증할 수 있다. 예를 들어, 검증은, 다른 것들 중에서, 다음 중 하나 이상을 결정하는 것을 포함할 수 있다: 요청 동작이 애니캐스트/썸캐스트 캐스트에 대해 지원되는지; 요청된 그룹 멤버의 수가 그룹 멤버의 총 수를 초과하지 않는지, 또는 요청된 썸캐스트가 혼합 타입의 그룹 멤버들에 대해 동작하고 이것이 허용되는지 여부. 또한 단계 262에서, 그룹 멤버들의 수가 선택될 수 있다. 이것은 단계 261의 요청 메시지에 있는 요청된 수 또는 일부 애플리케이션/서비스 특정적 파라미터들에 기초할 수 있다. 예를 들어, 비상 사태 모니터링 및 보고 서비스는 임의의 비상 사태 상황을 보고하기 위한 일정 정도의 "신뢰성(reliability)"을 요청할 수 있고, 그래서 그룹 호스팅 CSE는 애니캐스트/썸캐스트를 통해 이러한 서비스에 가입하는 애플리케이션에 대한 가입을 생성하기 위해 실제 필요한 멤버 호스팅 CSE보다 많이 선택할 수 있다. 요구되는 것보다 많이 선택하는 이러한 접근 방식은 일부 선택된 노드들이 요청을 거절하거나 또는 에러/메시지 손실이 존재하는 사례에서 일부 마진을 제공할 수 있다. 주요 아이디어는 그룹 호스팅 CSE가 발신자에 의해 요구되는 것보다 많은 수의 노드들을 선택한다는 것이다. 예를 들어, 발신자가 3개의 멤버들을 선택하라고 요청하지만, 그룹 호스팅 CSE는 5개의 멤버들을 선택할 수 있어, 2개의 선택된 멤버들이 거절하거나 접속이 끊기거나, 또는 2개의 메시지들이 손실되더라도, 발신자는 3개의 응답들을 여전히 수신할 수 있고, 이는 재송신으로 인한 너무 많은 대기 시간을 회피할 수 있다. 단계 262에서, 그룹 멤버들은 서비스 레이어에서 유지되는 요청 또는 디폴트 방법에 있는 방법들 및 기준들에 기초하여 선택될 수 있다.

계속해서 도 19를 참조하면, 단계 263에서, 그룹 호스팅 CSE(252)는 각각의 선택된 멤버 호스팅 CSE(예를 들어, 다른 것들 중에서, 멤버 호스팅 CSE(253), 멤버 호스팅 CSE(254), 및 멤버 호스팅 CSE(255))에게 요청을 전송한다. 이러한 예시적인 사례에서는, 3개의 멤버들이 선택되고, 이것은 요청된 2개의 멤버들보다 많다. AE(251)이 랜덤 선택을 명시하므로, 그룹 호스팅 CSE(252)는 3개의 그룹 멤버들을 랜덤하게 선택한다.

도 19의 사례 271이 이하 논의되며, 이는 모든 응답들을 수신하기 이전에 요청된 수의 성공 응답들을 수집하기 위한 예시적인 흐름이다. 단계 264에서, 처음 2개의 리턴 응답들이 수신되어, 요청 동작이 성공적으로 수행되었음을 표시한다. 단계 265에서, 그룹 호스팅 CSE(252)는 AE(251)에 대한 응답을 종합하기로 결정하며, 그 이유는 요청된 수의 성공 응답들을 수신하였기 때문이다. 단계 266에서, 그룹 호스팅 CSE(252)는 AE(251)에게 종합 응답 메시지를 전송한다. 267에서, 그룹 호스팅 CSE(252)에 의해 수신되는 응답들은 그 후 단계 261의 요청에 대해 무시될 것이다.

도 19의 사례 272가 이하 논의되며, 이는 요청된 수의 성공 응답들을 수집하는데 실패한 경우의 예시적인 흐름이다. 단계 281 및 단계 282에서, 2개의 선택된 그룹 멤버들은 프로세스 에러 및 메시지 손실로 인해 그룹 호스팅 CSE(252)에 성공 응답들을 리턴하지 않는다. 단계 283에서, 그룹 호스팅 CSE(252)는 단계 281 및 단계 282와 관련된 응답들에 기초하여 상이한 그룹 멤버들을 재선택한다. 그룹 호스팅 CSE(252)는 요청 동작에 대해 요청된 수의 성공 응답을 수집하는 것에 실패한 것으로 결정하였다. 이것은 둘 중 하나를 수집하였다. 단계 284에서, 그룹 호스팅 CSE(284)는 요청 메시지를 신규로 선택된 그룹 멤버(예를 들어, 단계 283에서 선택되는 멤버 호스팅 CSE(255))에게 전송한다. 단계 285에서, 그룹 호스팅 CSE(252)는 단계 284의 요청 메시지와 관련된 성공 응답을 수신한다. 단계 286에서, 그룹 호스팅 CSE(252)는 수신된 응답들을 종합한다. 단계 287에서, 그룹 호스팅 CSE(252)는 AE(251)에 종합 응답을 전송한다.

도 20은 oneM2M 서비스 컴포넌트 아키텍처(oneM2M Service Component Architecture, oneM2M-TS-0007 oneM2M Functional Architecture-V-0.7.0에서의 SAS의 예시적인 구현 아키텍처를 도시한다. 도시되는 바와 같이 CSE(276)에는 SAS 컴포넌트(275)가 존재한다. 이러한 서비스 능력은 요청에 있는 파라미터들을 검증하고, 애니캐스트/썸캐스트 시나리오를 식별하고, 선택에 대한 서비스 노드 범위를 결정하는 능력을 제공한다.

이하는 서비스 능력에 관한 추가의 논의이다. processingAnycastSomecastMessage 서비스 능력은 요청에 있는 파라미터들을 검증하고, 애니캐스트/썸캐스트 시나리오를 식별하고, 선택에 대한 서비스 노드의 범위를 결정하는 능력을 제공한다. 사전-조건은 발신자(예를 들어, AE 또는 CSE)가 서비스 노드들의 세트 또는 그 중 하나에 대한 애니캐스트/썸캐스트를 착수하기 원하는 것을 포함한다. Signature - processingAnycastSomecastMessage는 이전의 하나 이상의 테이블들과 유사하다.

도 21은 애니캐스트/썸캐스트에 대한 예시적인 서비스 상호 작용들을 도시하며, 이는 SOA에 대한 흐름들을 갖는다. oneM2M 리소스 연동 서비스 능력은 서비스 레이어 이웃에 대한 서비스 레이어 링크 상의 가중치를 검색하는데 사용될 수 있다. 이러한 서비스 능력은 <group> 리소스와 정렬되고 리소스에 대한 CRUD 프로시저에 매핑된다.

도 22는 SAS와 관련된 예시적인 그래픽 사용자 인터페이스 상에 디스플레이될 수 있는 것을 도시한다. 디스플레이는 임의의 컴퓨팅 기반 디바이스와 통신 가능하게 접속될 수 있다. 아이콘(291)은 SAS에 대한 것이며, 선택될 때 블록 292에서 그룹 기반 또는 비-그룹 기반 옵션을 디스플레이할 수 있다. 그룹-기반 옵션이 선택되면, 블록 293에 있는 정보가 본 명세서에 논의되는 바와 같은 썸캐스트/애니캐스트 파라미터들과 함께 디스플레이될 수 있다. 블록 293에 있는 파라미터들 중 하나 이상은 추가 정보를 가져 오기 위해 선택될 수 있다. 예를 들어, serviceNodeSelectionCriteria가 선택될 수 있고 블록 294에 있는 정보를 제공할 수 있다. 다른 예에서는, 본 명세서에서 논의되는 단계들 중 임의의 것의 진행(예를 들어, 전송된 메시지들 또는 단계들의 성공)이 디스플레이될 수 있다. 다른 것들 중에서, 도 15 내지 도 17의 방법 흐름들이 본 명세서에 논의되는 바와 같이 디스플레이될 수 있다. 사용자 인터페이스는, 애니캐스트/썸캐스트 서비스에 대한 특정 특징들을 인에이블하기 위한 또는 디스에이블하기 위한 제어 스위치들 뿐만 아니라, 디폴트 값들로 이러한 파라미터들을 구성하기 위해 또는 프로그래밍하기 위해 구현될 수 있다.

어떠한 방식으로든 본 명세서에 출현하는 청구항들의 범위, 해석 또는 적용을 부당하게 제한하지 않으면서, 본 명세서에 개시되는 예들 중 하나 이상의 기술적 효과는 디바이스들 및 애플리케이션들이 서비스 레이어를 통해 어떻게 통신되는지에 대한 조절들을 제공하는 것이다. SAS는 통신이 서비스 레이어와 관련될 때 일부 사례들에서 보다 효율적인 통신을 제공할 수 있다.

도 23a는 하나 이상의 개시되는 개념들이 구현될 수 있는 예시적인 M2M(machine-to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이 또는 M2M 서비스 플랫폼은 이러한 IoT/WoT는 물론이고 IoT/WoT 서비스 레이어 등의 컴포넌트일 수 있다.

도 23a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정형 네트워크(예를 들어, Ethernet, Fiber, 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), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 23a에 도시되는 바와 같이, 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(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 배선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 23b를 참조하면, 필드 도메인에 도시되는 M2M 서비스 레이어(22)는 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')는 하나 이상의 서버들, 컴퓨터들, 가상 머신들(예를 들어, 클라우드/계산/스토리지 팜들, 기타 등등) 등에 의해 구현될 수 있다.

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

일부 예들에서, M2M 애플리케이션들(20 및 20')은, 본 명세서에 논의되는 바와 같이, SAS를 사용하여 통신하는 원하는 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아니지만, 운송, 건강 및 건강관리, 접속된 홈, 에너지 관리, 자산 추적, 및 보안과 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 위에 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들 및 다른 서버들에 걸쳐 실행되는 M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다.

논의된 바와 같이, 본 출원의 SAS는 서비스 레이어의 일부로서 구현될 수 있다. 이러한 서비스 레이어는 API들(application programming interfaces) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어이다. M2M 엔티티(예를 들어, 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 디바이스, 게이트웨이, 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M 및 oneM2M 양자 모두는 본 출원의 SAS를 포함할 수 있는 서비스 레이어를 사용한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)이라고 지칭된다. 이러한 SCL은 M2M 디바이스(DSCL(device SCL)이라고 지칭됨), 게이트웨이(GSCL(gateway SCL)이라고 지칭됨) 및/또는 네트워크 노드(NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 레이어는 CSF들(Common Service Functions)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화는 CSE(Common Services Entity)라고 지칭되며, 이는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정적 노드) 상에서 호스팅될 수 있다. 또한, 본 출원의 SAS는 본 출원의 SAS와 같은 서비스들을 액세스하는데 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 사용하는 M2M 네트워크의 부분으로서 구현될 수 있다.

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

도 23c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적 M2M 디바이스(30)의 시스템 도면이다. 도 23c에 도시되는 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(30)는 개시되는 주제와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. M2M 디바이스(30)(예를 들어, 발신자(161), 발신자(184), 서비스 노드(165), 등록자 노드(164), 등록자 노드(184), 그룹 2 호스팅 노드(185), 그룹 2 멤버 노드(187) 등)는 디바이스 SAS에 대해 개시되는 시스템들 및 방법들을 수행하는 예시적인 구현일 수 있다.

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

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

또한, 도 23c에는 송신/수신 엘리먼트(36)가 단일 엘리먼트로서 묘사되지만, 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)는 본 명세서에 설명되는 예들 중 일부에서 SAS와 관련된 요청들 또는 응답들이 성공인지 여부(예를 들어, 재송신, 그룹 선택 등)에 응답하여 디스플레이 또는 표시자들(42) 상의 조명 패턴들, 이미지들, 또는 컬러들을 제어하도록, 또는 다른 방식으로 SAS 및 관련 컴포넌트들에 대한 응답 또는 요청들의 상태를 표시하도록 구성될 수 있다. 도 22는 디스플레이(42) 상에 디스플레이될 수 있는 예시적 SAS 정보 및 대화형 링크들이다. 디스플레이 또는 표시자들(42) 상의 제어 조명 패턴들, 이미지들, 또는 컬러들은 본 명세서에서 도시되거나 또는 논의되는 도면들(예를 들어, 도 13 내지 도 19 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다. 본 명세서에는 SAS의 메시지들 및 프로시저들이 개시된다. 이러한 메시지들 및 프로시저들은, 사용자들에 대한 인터페이스/API를 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40), 또는 디스플레이/터치패드(42))를 통해 SAS에 제공하도록, 그리고 디스플레이(42) 상에 디스플레이될 수 있는 다른 것들 중에서, SAS를 요청하거나, 구성하거나, 또는 쿼리하도록 확장될 수 있다.

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

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

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

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

도 23d는, 예를 들어, 도 23a 및 도 23b의 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)는, 다른 것들 중에서, 정보를 검색하거나 서비스를 실행하라고 서비스 노드들에게 요청하는 것과 같이, SAS에 대해 개시되는 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

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

시스템 버스(80)에 연결되는 메모리 디바이스들은 RAM(random access memory)(82) 및 ROM(read only memory)(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)은 도 23a 및 도 23b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

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

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

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

본 명세서에 설명되는 바와 같은, 다른 것들 중에서, 방법들, 시스템들, 및 장치들은 SAS에 대한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체, 또는 장치는 서비스 레이어를 사용하는 썸캐스트로의 명령어들을 포함하는 제1 요청 메시지를 수신하기 위한 수단; 요청 메시지에 있는 선택 기준에 기초하여 타겟 노드들을 결정하는 수단; 및 원하는 동작을 수행하는 것일 수 있는 제2 요청 메시지를 타겟 노드들에 전송하는 수단을 갖는다. 제1 요청 메시지는 썸캐스트와 관련된 제1 요청을 완료하는데 요구되는 서비스 노드들의 수의 표시를 포함할 수 있다. 제1 요청 메시지는 그룹 기반 또는 비-그룹 기반 썸캐스트의 표시를 포함할 수 있다. 제1 요청 메시지는 그룹 기반 썸캐스트에 대한 그룹 식별자를 포함할 수 있다. 선택 기준은 서비스 노드의 타입을 포함할 수 있다. 제1 요청 메시지는 제1 요청을 충족시키는데 사용될 수 있는 서비스 노드들의 양의 수 범위의 표시를 포함할 수 있다. 제1 요청 메시지는 애니캐스트(예를 들어, 서비스 노드 상에만 표시함) 또는 재송신 옵션의 표시를 포함할 수 있다. 제1 요청 메시지는 재송신 옵션을 포함할 수 있다. (단계들의 제거 또는 추가를 포함하는) 이 단락에서의 모든 조합들은 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.

본 명세서에 설명되는 바와 같은, 다른 것들 중에서, 방법들, 시스템들, 및 장치들은 SAS에 대한 수단을 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능 저장 매체, 또는 장치는 제1 타입의 원하는 정보를 결정하기 위한 수단- 제1 타입의 정보는 복수의 통신 가능하게 접속되는 노드들에 의해 획득될 수 있으며, 제1 타입의 정보는 물리적 세계를 감지하는 것에 기초함 -; 복수의 노드들의 대표 서브세트를 결정하는 수단- 대표 서브세트는 제1 기준에 기초함 -; 및 제1 타입의 정보에 대한 요청 메시지를 복수의 노드들의 대표 서브세트에 전송하는 수단을 갖는다.

Claims (20)

1. 장치로서,
   프로세서; 및
   상기 프로세서와 연결되는 메모리를 포함하고, 상기 메모리는 상기 프로세서에 의해 실행될 때 상기 프로세서로 하여금 동작들을 수행하게 하는 실행 가능한 명령어들을 포함하며, 상기 동작들은,
   서비스 레이어를 사용하는 썸캐스트로의 명령어들을 포함하는 제1 요청 메시지를 수신하는 단계;
   상기 요청 메시지에 있는 선택 기준에 기초하여 타겟 노드들을 결정하는 단계; 및
   원하는 동작을 수행하라는 제2 요청 메시지를 상기 타겟 노드들에 전송하는 단계를 포함하는 장치.
2. 제1항에 있어서,
   상기 제1 요청 메시지는 서비스 노드들의 수를 포함하는 장치.
3. 제1항에 있어서,
   상기 제1 요청 메시지는 그룹 기반 또는 비-그룹 기반 썸캐스트의 표시를 포함하는 장치.
4. 제1항에 있어서,
   상기 제1 요청 메시지는 그룹 기반 썸캐스트에 대한 그룹 식별자를 포함하는 장치.
5. 제1항에 있어서,
   상기 선택 기준은 서비스 노드의 타입을 포함하는 장치.
6. 제1항에 있어서,
   상기 선택 기준은 서비스 노드와 함께 사용되는 네트워킹 프로토콜의 타입을 포함하는 장치.
7. 제1항에 있어서,
   상기 제1 요청 메시지는 상기 제1 요청을 충족시키는데 사용될 수 있는 서비스 노드들의 양의 수 범위의 표시를 포함하는 장치.
8. 제1항에 있어서,
   상기 제1 요청 메시지는 애니캐스트의 표시를 포함하는 장치.
9. 제1항에 있어서,
   상기 제1 요청 메시지는 재송신 옵션을 포함하는 장치.
10. 컴퓨터 판독 가능 저장 매체로서,
    컴퓨팅 디바이스에 의해 실행될 때 상기 컴퓨팅 디바이스로 하여금 동작들을 수행하게 하는 컴퓨터 실행 가능 명령어들을 포함하고, 상기 동작들은,
    서비스 레이어 플랫폼 내에서 썸캐스트로의 명령어들을 포함하는 제1 요청 메시지를 수신하는 단계;
    상기 요청 메시지에 있는 선택 기준에 기초하여 타겟 노드들을 결정하는 단계; 및
    원하는 동작을 수행하라는 제2 요청 메시지를 상기 타겟 노드들에 전송하는 단계를 포함하는 컴퓨터 판독 가능 저장 매체.
11. 제10항에 있어서,
    상기 제1 요청 메시지는 서비스 노드들의 수를 포함하는 컴퓨터 판독 가능 저장 매체.
12. 제10항에 있어서,
    상기 제1 요청 메시지는 그룹 기반 또는 비-그룹 기반 썸캐스트의 표시를 포함하는 컴퓨터 판독 가능 저장 매체.
13. 제10항에 있어서,
    상기 제1 요청 메시지는 그룹 기반 썸캐스트에 대한 그룹 식별자를 포함하는 컴퓨터 판독 가능 저장 매체.
14. 제10항에 있어서,
    상기 선택 기준은 서비스 노드의 타입을 포함하는 컴퓨터 판독 가능 저장 매체.
15. 제10항에 있어서,
    상기 선택 기준은 서비스 노드와 함께 사용되는 네트워킹 프로토콜의 타입을 포함하는 컴퓨터 판독 가능 저장 매체.
16. 제10항에 있어서,
    상기 제1 요청 메시지는 상기 제1 요청을 충족시키는데 사용될 수 있는 서비스 노드들의 양의 수 범위의 표시를 포함하는 컴퓨터 판독 가능 저장 매체.
17. 방법으로서,
    서비스 레이어 플랫폼 내에서 썸캐스트에 표시하는 제1 요청 메시지를 수신하는 단계;
    상기 요청 메시지에 있는 선택 기준에 기초하여 타겟 노드들을 결정하는 단계; 및
    원하는 동작들을 수행하라는 제2 요청 메시지를 상기 타겟 노드들에 전송하는 단계
    를 포함하는 방법.
18. 제17항에 있어서,
    상기 제1 요청 메시지는 서비스 노드들의 수를 포함하는 방법.
19. 제17항에 있어서,
    상기 제1 요청 메시지는 그룹 기반 또는 비-그룹 기반 썸캐스트의 표시를 포함하는 방법.
20. 제17항에 있어서,
    상기 제1 요청 메시지는 그룹 기반 썸캐스트에 대한 그룹 식별자를 포함하는 방법.

Images