KR20190065405A - 서비스 계층 그룹 동작을 위한 멀티캐스트의 인에이블 - Google Patents

Abstract

서비스 계층 멀티캐스트 통신 관리는 서비스 계층 등록 동안의 멀티캐스트 능력들의 엔티티들에 의한 표시, 및 엔티티들에 의한 서비스 계층에의 자기-가입을 통해 달성될 수 있다. 다음으로, 서비스 계층, 또는 서비스 계층과 통신하는 관리 애플리케이션은 멀티캐스트 구성들을 위한 리소스들을 유지관리하고, 멀티캐스트 그룹들을 동적으로 생성하고, 그룹들 내의 엔티티들을 그들의 자기-가입을 통해 구성원들에게 통지할 수 있다. 다음으로, 서비스 계층은 멀티캐스트 메시지들을 더 팬아웃할 수 있고, 그에 의해 멀티캐스트 메시지의 발원자가 직접 통신들을 구성할 필요 없이 복수의 기저 네트워크 내의 수신자들에 액세스하는 것을 허용한다. 팬아웃은 멀티캐스트 능력들을 갖지 않는 엔티티들에의 유니캐스트들을 포함할 수 있다. 자기-가입은 또한 예를 들어 제3자 애플리케이션에 액세스 제어를 허가할 때 이용될 수 있다.

Description

서비스 계층 그룹 동작을 위한 멀티캐스트의 인에이블

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

본 출원은 2016년 10월 13일자로 출원되고 발명의 명칭이 "서비스 계층 그룹 동작을 위한 멀티캐스트의 인에이블(Enabling multicast for service layer group operation)"인 미국 가출원 제62/407,818호의 혜택을 주장하며, 그 개시내용은 전체가 참조에 의해 본 명세서에 통합된다.

머신 대 머신(Machine-to-Machine)(M2M), 사물 웹(Web-of-Things)(WoT) 및 사물 인터넷(Internet-Of-Things)(IoT) 네트워크 배치는 M2M/IoT 애플리케이션들 및 서비스들을 호스팅하는 M2M/IoT 서버들, 게이트웨이들, 및 디바이스들과 같은 노드들에 걸쳐 동작하는 oneM2M, ETSI M2M, 및 OMA LWM2M과 같은 M2M/IoT 서비스 계층들을 지원할 수 있다. 이러한 종류의 동작들은 예를 들어, oneM2M-TS-0001 기능적 아키텍처; 3GPP TS 23.682 그룹 서비스들 및 시스템 양태들; 제약된 애플리케이션 프로토콜(Constrained Application Protocol)(CoAP)에 대한 IETF RFC 7390 그룹 통신; IETF RFC 7252 제약된 애플리케이션 프로토콜(CoAP); 및 IETF RFC 3810 멀티캐스트 청취자 발견 버전 2(Multicast Listener Discovery Version 2)(MLDv2)에 설명된 것과 같은 그룹 통신들을 포함할 수 있다.

멀티캐스트 그룹들의 서비스 계층 관리는 서비스 계층 등록 동안의 멀티캐스트 능력들의 표시, 서비스 계층에서의 엔티티에 의한 자기-가입(self-subscription), 멀티캐스트 구성을 위한 서비스 계층 리소스들의 유지관리, 서비스 계층 또는 관리 애플리케이션에 의한 멀티캐스트 그룹들의 생성, 멀티캐스트 및 서비스 계층 그룹 생성에 대한 동적 통지, 및 멀티캐스트 메시지들을 복수의 기저 네트워크에 팬아웃(fan-out)하기 위한 서비스 계층에 의한 트리거를 통해 달성될 수 있다.

엔티티들은 등록 요청에 포함된 표시자를 통해 멀티캐스트에 대한 자신들의 지원을 나타낼 수 있다. 다음으로, 이 정보는 멀티캐스트 그룹들을 생성할지의 여부와 그것들을 어떻게 구성할지를 결정하기 위해, 서비스 계층 또는 관리 애플리케이션에 의해 사용될 수 있다.

자기-가입을 통해, 엔티티는 자발적 요청(unsolicited request)을 디바이스 엔티티에 송신하도록 서비스 계층에 대한 가입을 설정할 수 있다. 이것은 엔티티가 엔티티의 리소스들 중 하나에 대한 동작을 통지받는 것을 허용한다. 예를 들어, 엔티티는 관리 애플리케이션에 의해 생성된 그룹 구성원 자격에 추가된다는 것을 통지받을 수 있다. 또한, 자기-가입은 예를 들어 제3자 애플리케이션에 대한 액세스 제어를 허가하거나 제3자 애플리케이션에 의해 요청된 관리 기능을 수행하는 데에 사용될 수 있다.

서비스 계층은 멀티캐스트 그룹을 생성할 때 멀티캐스트 파라미터들을 구성하기 위한 리소스를 노출할 수 있다. 이러한 리소스는 또한 멀티캐스트 그룹을 생성하는 관리 애플리케이션에 의해 생성될 수 있다. 예를 들어, 서비스 계층들, 엔티티들, 및 디바이스들의 네트워크 파라미터들을 구성하기 위한 기능성이 제공될 수 있다.

서비스 계층 멀티캐스트 그룹 생성의 동적 서비스 계층 통지는, 예를 들어, 엔티티들에게 네트워크 파라미터들이 지정되는 멀티캐스트 그룹의 생성에 대해 통지하는 것을 포함할 수 있다. 이러한 통지들은 요청되는 애플리케이션 콘텐츠에 관한 정보를 더 포함할 수 있다.

본 개요는 아래에서 상세한 설명에 더 설명되는 단순화된 형태의 개념들의 선택을 소개하기 위해 제공된다. 본 개요는 청구된 주제의 핵심적인 특징들 또는 필수적인 특징들을 식별하도록 의도되지 않으며, 청구된 주제의 범위를 제한하는 데 사용되도록 의도되지도 않는다. 또한, 청구된 주제는 본 개시내용의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 제한들에 한정되지 않는다.

도 1은 예시적인 oneM2M 서비스 계층 아키텍처를 도시한다.
도 2는 oneM2M에 대한 예시적인 group 리소스를 도시한다.
도 3은 oneM2M 팬아웃 동작의 관리의 예시적인 호출 흐름을 도시한다.
도 4는 oneM2M과 같은 서비스 계층 아키텍처들에 의해 제공될 수 있는 서비스들을 도시한다.
도 5는 영역 네트워크 정보를 제공하기 위해 사용되는 oneM2M 리소스를 도시한다.
도 6은 네트워크 구성 정보를 제공하기 위해 사용되는 oneM2M 리소스를 도시한다.
도 7은 CoAP 서버들이 멀티캐스트 요청에 대한 유니캐스트 응답을 반환하는 예시적인 호출 흐름을 도시한다.
도 8은 멀티캐스트 가능 애플리케이션을 수반하는 예시적인 호출 흐름을 도시한다.
도 9는 셀룰러 네트워크에 의해 제공되는 그룹 서비스들에 대한 예시적인 3GPP 아키텍처를 도시한다.
도 10은 UE들의 그룹들을 생성하고 관리할 때의 SCS/AS와 SCEF 사이의 통신을 위한 예시적인 호출 흐름을 도시한다.
도 11은 도 10의 호출 흐름의 계속이다.
도 12는 예시적인 태양광 발전소의 시스템도를 도시한다.
도 13은 디바이스 애플리케이션들이 서비스 계층에 등록하는 예시적인 호출 흐름을 도시한다.
도 14는 도 13의 호출 흐름의 계속이다.
도 15는 SL이 가입 리소스를 생성하는 예시적인 호출 흐름을 도시한다.
도 16은 SL이 가입 리소스를 생성하는 예시적인 대안의 호출 흐름을 도시한다.
도 17은 서비스 계층이 멀티캐스트 그룹들을 생성하는 예시적인 호출 흐름을 도시한다.
도 18은 관리 애플리케이션이 netConfig 리소스를 생성하는 예시적인 대안의 호출 흐름을 도시한다.
도 19는 관리 애플리케이션이 기저 네트워크에서의 멀티캐스트 그룹의 생성을 트리거하는 예시적인 호출 흐름을 도시한다.
도 20은 멀티캐스트 그룹의 생성을 원격 서비스 계층들에 통지하기 위한 예시적인 호출 흐름을 도시한다.
도 21은 서비스 계층이 멀티캐스트 그룹에 대한 변경들에 관하여 기저 네트워크를 업데이트하는 예시적인 호출 흐름을 도시한다.
도 22는 SL 팬아웃 동작에 대한 예시적인 호출 흐름을 도시한다.
도 23은 ADN-AE가 MN-CSE에 등록하는 예시적인 호출 흐름을 도시한다.
도 24는 MN-CSE가 IN-CSE에게 그것이 멀티캐스트 가능임을 알리는 예시적인 호출 흐름을 도시한다.
도 25는 oneM2M 팬아웃 동작이 유니캐스트 및 복수의 멀티캐스트 그룹으로의 팬아웃을 야기하는 예시적인 호출 흐름을 도시한다.
도 26은 AE2가 AE1으로부터의 리소스를 요청하는 예시적인 호출 흐름을 도시한다.
도 27은 다수의 인터페이스 각각에 대한 리소스들을 갖는 MN-CSE에 대한 예시적인 oneM2M 리소스 트리를 도시한다.
도 28은 멀티캐스트 기능성을 실현하는 애플리케이션을 위한 사용자 인터페이스의 예시적인 스크린을 도시한다.
도 29는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 머신 대 머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템의 시스템도이다.
도 30은 도 29에 도시된 M2M/IoT/WoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처의 시스템도이다.
도 31은 도 29 및 도 30에 도시된 통신 시스템 내에서 사용될 수 있는 M2M/IoT/WoT 디바이스, 게이트웨이, 또는 서버와 같은 예시적인 통신 네트워크 노드의 시스템도이다.
도 32는 도 29 및 도 30의 통신 시스템의 노드가 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다.

멀티캐스트 그룹들의 서비스 계층 관리는 서비스 계층 등록 동안의 멀티캐스트 능력들의 표시, 서비스 계층에서의 엔티티에 의한 자기-가입, 멀티캐스트 구성을 위한 서비스 계층 리소스들의 유지관리, 서비스 계층 또는 관리 애플리케이션에 의한 멀티캐스트 그룹들의 생성, 멀티캐스트 및 서비스 계층 그룹 생성에 대한 동적 통지, 및 멀티캐스트 메시지들을 복수의 기저 네트워크에 팬아웃하기 위한 서비스 계층에 의한 트리거를 통해 달성될 수 있다.

엔티티들은 등록 요청에 포함된 표시자를 통해 멀티캐스트에 대한 자신들의 지원을 나타낼 수 있다. 다음으로, 이 정보는 멀티캐스트 그룹들을 생성할지의 여부와 그것들을 어떻게 구성할지를 결정하기 위해, 서비스 계층 또는 관리 애플리케이션에 의해 사용될 수 있다. 자기-가입을 통해, 엔티티는 자발적 요청을 디바이스 엔티티에 송신하도록 서비스 계층에 대한 가입을 설정할 수 있다. 이것은 엔티티가 엔티티의 리소스들 중 하나에 대한 동작을 통지받는 것을 허용한다. 예를 들어, 엔티티는 관리 애플리케이션에 의해 생성된 그룹 구성원 자격에 추가된다는 것을 통지받을 수 있다. 예를 들어, 제3자 애플리케이션에 대한 액세스 제어를 허가할 때 자기-가입이 또한 사용될 수 있다. 자기-가입의 세번째 사용 사례는 디바이스들이 제3자 애플리케이션에 의해 요청될 수 있는 관리 커맨드들을 통지받는 것이다. 서비스 계층은 멀티캐스트 그룹을 생성할 때 멀티캐스트 파라미터들을 구성하기 위한 리소스를 노출할 수 있다. 그러한 리소스는 또한 멀티캐스트 그룹을 생성하는 관리 애플리케이션에 의해 생성될 수 있다. 예를 들어, 서비스 계층들, 엔티티들, 및 디바이스들의 네트워크 파라미터들을 구성하기 위한 기능성이 제공될 수 있다. 서비스 계층 멀티캐스트 그룹 생성의 동적 서비스 계층 통지는, 예를 들어, 엔티티들에게 네트워크 파라미터들이 지정되는 멀티캐스트 그룹의 생성을 통지하는 것을 포함할 수 있다. 그러한 통지들은 요청되는 애플리케이션 콘텐츠에 관한 정보를 더 포함할 수 있다.

서비스 계층은 네트워크 서비스 아키텍처 내의 기능적 계층일 수 있다. 서비스 계층들은 전형적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 놓이며, 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어 제어 계층 및 전송/액세스 계층과 같은 하위 리소스 계층에서 코어 네트워크에 대한 인터페이스를 제공한다.

그룹 동작들은 시스템 내에서 메시지 트래픽을 감소시키는 데 중요한 역할을 할 수 있다. 표준 서비스 계층 아키텍처들은 group 리소스들 및 팬아웃 절차들을 통해 그룹 동작들을 지원한다. 그러나, 그러한 아키텍처들에서의 전통적인 팬아웃 절차들의 기저 실행은 기저 네트워크들의 멀티캐스트 능력들을 고려하지 않는다. 그러한 능력들을 활용하는 것은, 예를 들어 잠재적으로 수십억 개의 디바이스를 수반할 수 있는 IoT 시스템에서 매우 바람직하다.

oneM2M과 같은 전통적인 서비스 계층 아키텍처들은 <group> 및 <fanOutPoint> 리소스들의 사용을 통해 그룹 동작들을 위한 능력들을 제공한다. 요청자는 복수의 구성원으로 <group> 리소스를 생성할 수 있고, 서비스 계층이 <fanOutPoint> 리소스를 타겟팅함으로써 구성원들 각각에 대한 동작들을 실행하게할 수 있다. 그룹 요청을 실행하기 위해, 서비스 계층은 개별 요청들을 각각의 그룹 구성원에게 송신하고 결과들을 다시 요청자에게 집계한다.

기저 네트워크들 내부에서는, 서비스 계층이 그룹 동작들을 실행할 때 잠재적으로 사용할 수 있는 멀티캐스팅 능력들이 종종 존재한다. 예는 CoAP 그룹 통신들이다. 다른 것은 3GPP 서비스 능력 노출 기능(Service Capability Exposure Function)(SCEF)을 통한 그룹 메시지 전달이다. 표준 CoAP 프로토콜은 oneM2M과 같은 SL 아키텍처들에 바인딩된다. 3GPP SCEF는 셀룰러 네트워크들을 위한 그룹 통신 능력들을 제공한다. 그러나, 표준 서비스 계층은 이러한 능력을 활용할 수 있는 메커니즘을 갖지 않는다.

여기에서 사용되는 일부 3GPP, IETF, 및 다른 약어들에 대한 설명들이 아래에 제공된다. 3GPP 약어들의 더 완전한 목록에 대해서는, 예를 들어 3GPP 사양들에 대한 3GPP TR 21.905 어휘집을 참조하면 된다.

oneM2M은 M2M/IoT 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업, 및 홈 네트워크와의 배치들에 통합하는 것에 연관된 난제들을 해결하기 위해 M2M/IoT 서비스 계층(SL) 기술을 개발하는 글로벌 표준 기구이다. 예를 들어, TS-0001 oneM2M 기능적 아키텍처, V-2.6.0을 참조하면 된다. "서비스 계층"이라는 용어는 네트워크 서비스 아키텍처 내의 기능적 계층을 지칭한다. 서비스 계층들은 전형적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 놓이며, 클라이언트 애플리케이션들에 부가 가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어 제어 계층 및 전송/액세스 계층과 같은 하위 리소스 계층에서 코어 네트워크들에 대한 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 런타임 활성화(service runtime enablement), 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함하는 복수의 카테고리의 (서비스) 능력들 또는 기능성들을 지원한다.

M2M 서비스 계층은 애플리케이션들 및/또는 다양한 디바이스들에, CSE 또는 SCL이라고 지칭될 수 있는 서비스 계층에 의해 지원되는 위에서 언급된 능력들 또는 기능성들의 모음 또는 그것들의 세트에 대한 액세스를 제공할 수 있다. 몇가지 예는 다양한 애플리케이션들에 의해 공통적으로 사용될 수 있는 보안, 요금청구, 데이터 관리, 디바이스 관리, 발견, 프로비저닝 및 접속성 관리를 포함하지만 이에 제한되지는 않는다. 이러한 능력들 또는 기능성들은 M2M 서비스 계층에 의해 정의된 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 활용하는 API들을 통해 그러한 다양한 애플리케이션에게 이용가능하게 된다. CSE 또는 SCL은 하드웨어 및/또는 소프트웨어에 의해 구현될 수 있으며, 다양한 애플리케이션들 및/또는 디바이스들이 그러한 능력들 또는 기능성들을 사용하도록, 그것들에 노출되는 (서비스) 능력들 또는 기능성들을 제공하는 기능적 엔티티이다(즉, 그러한 기능적 엔티티들 사이의 기능적 인터페이스들).

M2M/IoT 서비스 계층은 M2M/IoT 디바이스들 및 애플리케이션들을 위한 부가가치 서비스들을 제공할 수 있다. 예시적인 oneM2M 서비스 계층 아키텍처는 도 1에 도시된다. 이 아키텍처는 공통 서비스 엔티티(CSE)에 연관된 다양한 참조 포인트들을 보여준다. Mca 인터페이스는 애플리케이션들 또는 AE들에 대한 서비스 계층 액세스를 제공하는 한편, Mcc 및 Mcc' 참조 포인트들은 CSE 대 CSE 통신들을 허용한다. Mcn 인터페이스는 기저 네트워크 기술에 대한 액세스를 제공한다. Mcn 인터페이스는 통상적으로 3GPP 네트워크에 대한 인터페이스이다. 여기에서, "Mcn"이라는 용어는 그것이 셀룰러인지, 아니면 이더넷 및/또는 WiFi와 같은 IP 기반 네트워크인지에 관계없이 기저 네트워크들에 대한 인터페이스들을 일반적으로 지칭한다.

SL과 같은 수평 시스템과 통신하는 다수의 디바이스가 존재할 수 있다. 그러한 경우에서, 그룹 관리 기능성은 통신들에서 중요한 역할을 담당할 수 있다. 이 서비스는 oneM2M에 대해 도 2에 도시된 것과 같은 group 리소스의 사용을 통해 수행될 수 있으며, 여기서 그룹 구성원들은 memberIDs 속성에 지정된다. 다음으로, 사용자, 예를 들어 AE는 <group>의 <fanOutPoint> 가상 리소스 상의 동작을 타겟팅함으로써 <group> 리소스의 구성원들에 대한 그룹 동작들을 수행할 수 있다. 결국, 서비스 계층은 그룹 구성원들 각각에게 개별 동작 요청들을 송출하고, 응답들을 다시 사용자에게 집계할 수 있다.

도 3은 oneM2M <fanOutPoint> 동작의 관리를 위한 예시적인 호출 흐름을 도시한다. 단계 1에서, 발원자 AE 또는 CSE는 <fanOutPoint> 가상 리소스를 타겟팅하는 그룹 요청을 그룹 호스팅 CSE에 송신한다. 단계 2에서, 그룹 호스팅 CSE는 요청자가 액세스 제어 권한들을 갖고 있는지를 검사한다. 요청자가 그러한 권한을 갖는다면, 단계 3에서, 그룹 호스팅 CSE는 <group> 리소스의 memberIDs 속성 내에서 찾아진 그룹 구성원들 각각에게 요청을 "팬아웃"한다. 여기서 "팬아웃한다" 및 "팬아웃"이라는 용어는 CSE가 개별 유니캐스트 요청을 그룹의 각각의 구성원에 송신하는 것을 지칭한다. 단계 3의 팬아웃 요청들은 단계 1에서 송신된 원래의 요청과 유사하다. 단계 3에서, 각각의 메시지의 타겟이 각각의 그룹 구성원에 대해 변경된다. 단계 4에서, 각각의 구성원은 액세스 제어 검사들과 같은 검사들을 수행하고 응답을 만들어낸다(formulate). 단계 5에서, 각각의 구성원은 응답을 송신한다. 단계 6에서, 각각의 구성원으로부터 응답들을 수신하면, 그룹 호스팅 CSE는 응답들을 집계한다. 단계 7에서, 그룹 호스팅 CSE는 발원자 AE 또는 CSE에게 집계된 응답을 반환한다.

디바이스 관리(DM)는 도 4의 예에 도시된 바와 같이, oneM2M과 같은 서비스 계층 아키텍처들에 의해 제공되는 중요한 특징이다. 원격으로 배치된 디바이스들은 서비스 계층과 통신하는 애플리케이션을 통해 관리될 수 있다. 그러면, 애플리케이션은 디바이스의 구성을 관리할 수 있고, 디바이스에서 소프트웨어를 다운로드 및 설치하며, 심지어는 디바이스를 원격으로 진단할 수도 있다. DM 기능성은 그것이 일부 운영 체제(Operating System)(OS) 호출들, 범용 입력/출력(General Purpose Input/Output)(GPIO) 핀과 같은 소정의 하위 레벨 하드웨어를 제어하기 위한 디바이스 드라이버, 또는 프로토콜 스택에 대한 일부 API 호출들에의 인터페이싱을 위한 것인지에 상관없이, 기저 디바이스 플랫폼에 대한 서비스 계층 액세스를 제공한다. 예를 들어, oneM2M TS-0001의 9.6.15절을 참조하면 된다.

서비스 계층들 내에서, 리소스들은 디바이스 관리 목적들을 위해 존재한다. oneM2M에서 관리 객체(<mgmtObj>) 리소스들이라고 지칭되는 이러한 리소스들은, 서비스 계층에 등록된 애플리케이션들이 디바이스 상에서의 액션들을 구성, 관리 및 개시할 수 있게 하는 것을 허용한다. 도 5는 영역 네트워크 정보를 제공하기 위해 사용되는 DM 특정 <mgmtObj> 리소스인 oneM2M areaNwkInfo <mgmtObj> 리소스를 보여준다. 표 3에서, areaNwkType 및 listOfDevices는 영역 네트워크의 속성들이다.

네트워크 구성 정보를 제공하는 다른 oneM2M <mgmtObj> 리소스는 도 6에 도시된 [areaNwkDeviceInfo]이다. 이 리소스는 [areaNwkInfo]와는 대조적으로, 로컬 네트워크가 아닌 디바이스들 자체에 관한 네트워크 정보를 제공한다. 표 4는 sleepInterval, sleepDuration, status 및 listOfNeighbors 속성 내의 디바이스의 예시적인 네트워크 정보를 보여준다.

제약된 애플리케이션 프로토콜(CoAP)에 대한 IETF RFC 7390 그룹 통신은 CoAP 계층에서 그룹 통신들을 수행하기 위한 프로세스들 및 절차들을 설명한다. 프로토콜은 MLD와 같은 기저 IP 멀티캐스트 프로토콜을 사용하는 한편 RESTful 매서드를 사용하는 일-대-다 엔드포인트들을 수반하는 통신들을 위해 CoAP를 사용하는 데 중점을 둔다. 수신 CoAP 서버들은 유니캐스트 요청을 통해 임의로(optionally) 응답할 수 있으며, CoAP 클라이언트는 자신이 송신한 멀티캐스트 요청에 연관된 다양한 응답 코드들을 수신할 수 있다. IETF RFC 7390에 따르면, 그룹 통신의 사용은 "다른 혜택들 중에서도 특히 개선된 네트워크 효율성과 대기시간을 제공한다". RFC 7390에는 그룹들을 셋업하고 관리하는 방법, 그룹 통신들을 위한 보완 기술들, 및 CoAP 프로토콜 관련 업데이트들을 설명하는 다수의 다른 세부사항이 존재한다. 2개의 주된 CoAP 요건은, URI 경로가 선택될 때 그룹 내의 모든 CoAP 서버에 걸쳐 반드시 동일한 경로가 사용되어야 하며, IP 멀티캐스트를 통해 송신되는 모든 CoAP 요청은 확인불가능(Non-confirmable)해야 한다는 것이다.

CoAP 멀티캐스트는 컨텍스트-인식 애플리케이션들에서 리소스 디렉토리(Resource Directory)(RD) 엔티티들 내에서 사용될 수 있고, 그에 의해 CoAP 서버들은 RD에 등록하고, 그들의 리소스에 관한 정보, 예컨대 정확도를 제공한다. 다음으로, CoAP 클라이언트는 소정의 정확도를 갖는 리소스들에 관해 RD에게 질의할 수 있고, 그러면 RD는 정확도 기준을 충족하는 CoAP 서버들의 목록을 반환한다. 다음으로, CoAP 클라이언트는 CoAP 서버들 각각에 대한 멀티캐스트 구성원 자격을 구성한 다음, 멀티캐스트 동작을 수행한다. CoAP 서버들은 요청된 리소스를 갖는 CoAP 클라이언트에 유니캐스트 응답을 각각 반환한다. 도 7은 이 프로세스를 도시한다. 단계 1a 및 1b에서, CoAP 서버 1 및 2는 리소스 디렉토리(RD)에 리소스 등록 요청,예를 들어 {Req: POST coap://rd.example.com/rd?ep=node1 Payload: </temp1>; rt="temp";accuracy=91%}를 각각 송신한다. 단계 2a 및 2b에서, RD는 요청들을 확인응답한다. 단계 3에서, CoAP 클라이언트는 RD에 리소스 룩업 요청, 예를 들어 {GET coap:// rd.example.com/ rd-lookup/res? rt=temp;accuracy>=90%}을 송신한다. 단계 4에서, RD는 CoAP 클라이언트에 2.05 콘텐츠, 예를 들어 {2.05 Content <coap://{ip1:port1}/temp1>;rt="temp"; accuracy=91%, <coap://{ip2:port2}/temp2>;rt="temp"; accuracy=92%}로 응답한다. 단계 5에서, CoAP 클라이언트는 멀티캐스트 구성원 자격 구성에 대해 CoAP 서버 1 및 2와 통신한다. 단계 6에서, CoAP 클라이언트는 예를 들어 {Multicast Address, contextType=accuracy}와 함께 CoAP 서버 1 및 2에 멀티캐스트 요청을 송신한다. 단계 7a 및 7b에서, CoAP 서버 1 및 2 각각은 예를 들어 {Content, contextValue=accuracyValue}와 함께 유니캐스트 응답들로 CoAP 클라이언트에 응답한다.

IETF RFC 7252 제약된 애플리케이션 프로토콜(CoAP)은 CPU, RAM 및 ROM과 같은 디바이스 리소스들이 제한된 IoT 시스템들에서의 사용을 위해 설계되었다. 이러한 경량 프로토콜은 인터넷에서 널리 사용되는 HTTP와 유사한 기능성을 제공하지만, 동작을 위해 더 적은 리소스들을 필요로 한다. 작은 센서 디바이스들은 전형적으로 이 프로토콜을 사용할 것이고, 결과적으로 oneM2M은 CoAP에의 바인딩을 제공했다. 또한, CoAP는 비접속형 프로토콜인 UDP를 사용하므로, CoAP는 멀티캐스트 능력들을 제공하는 한편, HTTP는 그렇지 않다.

IPv6를 위한 IETF RFC 3810 멀티캐스트 청취자 발견 버전 2(Multicast Listener Discovery Version 2)(MLDv2)는 IPv6 네트워크에서의 멀티캐스트 동작들의 사용을 설명한다. MLDv2는 멀티캐스트 청취자들 및 멀티캐스트 라우터들에 대해 별개의 거동들을 지정하는 비동기 프로토콜이다. IETF RFC 3376 인터넷 그룹 관리 프로토콜 버전 3(Internet Group Management Protocol Version 3)(IGMPv3)은 유사한 동작들을 따르지만 IPv4 네트워크들에 적용된다. 2가지 프로토콜 모두에서, 멀티캐스트 메시지들을 수신하는 것에 관심이 있는 애플리케이션은 디바이스 상에서 API를 호출하고, 그것이 청취하고 있을 멀티캐스트 주소를 제공한다. 이는 멀티캐스트 라우터에 송신되는 MLD 리포트를 트리거한다. 라우터는 멀티캐스트 주소를 라우터가 메시지를 포워딩하는 IP 주소들의 목록에 추가한다. 애플리케이션이 멀티캐스트 메시지들을 수신하는 것에 더 이상 관심이 없으면, 그것은 MLD Done(MLD 완료) 메시지가 송신될 것을 요청하고, 이는 라우터의 목록으로부터 멀티캐스트 주소가 제거되게 할 것이다. 멀티캐스트 라우터들은 멀티캐스트 주소에 청취자가 있는 경우에만 멀티캐스트 메시지들을 포워딩할 것이다. 추가로, 멀티캐스트 라우터들은 얼마나 많은 청취자가 존재하는지, 또는 청취자들이 누구인지를 추적하지 않는다. 라우터들은 적어도 하나의 청취자가 존재하는지 여부에만 관심이 있다.

전형적으로, 멀티캐스트 가능 애플리케이션이 런칭될 때, 도 8에 도시된 MLD 리포트를 송신하는 것을 가능하게 하기 위해, 아래에 나열된 것과 유사한 API를 통해 Start Listening(청취 시작) 동작을 호출할 것이다. 멀티캐스트 주소의 구성은 애플리케이션 코드 자체에 의해, 애플리케이션 사용자에 의해, 또는 네트워크 관리자에 의해 프로비저닝될 수 있다. 다음으로, 애플리케이션이 닫히면, MLD 리포트를 송신하는 것을 중지하기 위해, Stop Listening(청취 중지) 동작이 호출된다. 예 1 및 2에서, 동일한 API가 호출되지만, 상이한 파라미터들 EXCLUDE 및 INCLUDE을 갖는다. 실제로는 별개의 API 호출들이 사용될 수 있다. 멀티캐스트는 멀티캐스트 주소의 네트워크 구성, 및 애플리케이션이 구성된 주소를 청취하도록 디바이스를 개시하는 것의 조합을 통해 가능해진다.

예 1

청취 시작

예 2

청취 중지

도 8은 MLDv2 프로토콜의 예시적인 사용을 보여준다. 단계 1에서, 디바이스 상의 애플리케이션은 멀티캐스트 주소 mcAddr로부터 멀티캐스트 메시지들을 수신하는 데에 관심이 있다. 이는 사용자를 통해 애플리케이션 계층에서 트리거될 수 있다. 단계 2에서, 디바이스는 mcAddr을 타겟팅하는 멀티캐스트 메시지들을 수신하는 데에 관심이 있음을 나타내기 위해 mcAddr을 갖는 MLD 리포트 메시지를 멀티캐스트 라우터에 송신한다. 단계 3에서, 라우터는 mcAddr를 자신이 유지보관하는 멀티캐스트 주소들의 목록에 추가하고, mcAddr을 타겟팅하는 임의의 메시지를 포워딩할 것이다. 그것은 목록 내에 mcAddr을 유지보관하기 위해 내부적으로 멀티캐스트 청취자 간격(Multicast Listener Interval)(MLI) 타이머를 시작한다.

단계 4에서, MLI 타이머가 만료되면, 라우터는 네트워크 내의 임의의 노드들이 멀티캐스트 메시지들을 수신하는 데에 여전히 관심이 있는지 검사하기 위해, MLD 일반 질의를 송신한다. 단계 5에서, 디바이스는 여전히 관심이 있고, mcAddr을 갖는 다른 MLD 리포트 메시지를 송신한다. 멀티캐스트 메시지들을 수신하는 데에 관심이 있는 노드가 존재하는 한, 단계 4 및 단계 5가 반복된다. 디바이스는 자기 자신의 타이머를 가지며, 그것이 만료되면 mcAddr을 갖는 MLD 리포트를 송신한다. 타이머 값들은 RFC 3810에 지정되어 있다.

단계 6에서 애플리케이션은 더 이상 멀티캐스트 메시지들을 수신하는 데에 관심이 없다. 단계 7에서, 디바이스는 라우터에게 자신이 mcAddr에 대한 관심을 취소하기를 원한다는 것을 나타내기 위해 MLD 완료 메시지를 송신한다. 단계 8에서, 라우터는 mcAddr에 관심있는 임의의 다른 노드들이 존재하는지를 검사하기 위해 MLD 멀티캐스트 주소 특정(Multicast Address Specific)(MAS) 질의를 송신한다. 단계 9에서, 라우터는 어떤 다른 노드도 mcAddr에 관심이 없음을 확인하기 위해 M.A.S. 질의를 재송신한다. 단계 10에서, 라우터는 자신의 멀티캐스트 주소 포워딩 목록으로부터 mcAddr을 제거한다.

도 9는 셀룰러 네트워크에 의해 제공되는 그룹 서비스들에 대한 예시적인 3GPP 아키텍처를 도시한다. 예를 들어, 3GPP TS 23.682 그룹 서비스들 및 시스템 양태들(Group Services and System Aspects), V13.5.0을 참조하면 된다. "SCS/AS"는 3GPP에서 서버에 대해 사용되는 용어이다. SCS/AS는 예를 들어 서비스 계층 또는 애플리케이션을 구현할 수 있다. 도 9의 예에서, 서비스 능력 노출 기능(Service Capability Exposure Function)(SCEF)은 SL과 셀룰러 네트워크 사이의 인터페이스 역할을 하며, SCS/AS가 코어 네트워크의 서비스들에 액세스하는 것을 허용하는 API들 또는 인터페이스를 노출시킨다. SL에 제공되는 서비스들 중에는, 그룹들을 생성하고, 그룹들을 관리하고, 사용자 장비(User Equipment)(UE) 디바이스들의 그룹들에 메시지들을 송신하는 능력이 있을 수 있다.

도 10 및 도 11은 UE들의 그룹을 생성하고 관리하는 데에 있어서의 SCS/AS와 SCEF 사이의 통신들을 위한 예시적인 방법을 도시한다. SCS/AS가 그룹을 생성한 후, 그것은 도 10 및 도 11의 단계들을 따라 셀룰러 네트워크 내에 대응하는 그룹을 생성할 수 있다. 3GPP 네트워크는 우선 그룹을 식별하기 위해 임시 모바일 그룹 신원(Temporary Mobile Group Identity)(TMGI)을 할당할 수 있다. 이 TMGI는 멀티캐스팅 능력들을 제공하는 서비스인 3GPP 멀티미디어 브로드캐스트 멀티캐스트 서비스(3GPP Multimedia Broadcast Multicast Service)(MBMS)의 일부로서 사용된다. 도 10 및 도 11의 예는 3GPP TS 23.682 그룹 서비스들 및 시스템 양태들, V13.5.0에 기술되어 있다. 유효한 TMGI 할당이 이미 존재하거나 MBMS 베어러 활성화가 TMGI 사전 할당없이 수행되는 경우, 단계 1 내지 5는 스킵될 수 있다. SCEF와 SCS/AS 사이의 상호작용들(단계들 1, 4, 6, 11 및 13에서)은 3GPP의 범위를 벗어나며, 정보를 주는 목적으로만 제시된다.

단계 1에서, 외부 그룹 ID를 위한 할당된 TMGI가 존재하지 않는 경우, SCS/AS는 TMGI 할당 요청(외부 그룹 ID, SCS 식별자, 위치/영역 정보) 메시지를 SCEF에 송신한다. SCS/AS는 외부 그룹 식별자를 사용하거나 로컬로 구성된 SCEF 식별자/주소를 사용하여 DNS 질의를 수행함으로써 SCEF의 IP 주소들 또는 포트들을 결정할 수 있다. SCEF는 SCS/AS가 TMGI 할당을 요청하도록 인가되는지를 검사한다.

단계 2에서, SCEF는 SCS/AS가 TMGI 할당을 요청하도록 인가되는지를 결정한다. 단계 3에서, SCEF는 TS 23.468에 지정된 TMGI 할당 절차에 따라, BM-SC에 의한 TMGI 할당을 개시한다. 단계 4에서, SCEF는 수신된 TMGI 및 만료 시간 정보를 SCS/AS에 송신한다. SCEF는 서빙 BM-SC 신원 정보, 및 외부 그룹 ID와 TMGI 사이의 맵핑을 캐싱할 수 있다.

단계 5에서, 관련된 MBMS 서비스 정보, 예를 들어, TMGI, 시작 시간을 리트리브하기 위해, 특정 그룹의 디바이스들에 대해 애플리케이션 레벨 상호작용들이 발생할 수 있다.

단계 6에서, SCS/AS는 그룹 메시지 요청(외부 그룹 식별자, SCS 식별자, 위치/영역 정보, RAT(들) 정보, TMGI, 시작 시간) 메시지를 SCEF에 송신한다. SCS/AS에 의해 나타나는 위치/영역 정보는 지리적 영역 정보일 수 있다.

단계 7에서, SCEF는 SCS/AS가 그룹 메시지 요청을 송신하도록 인가되는지를 검사한다. 이 검사가 실패하면, SCEF는 실패 조건의 이유를 나타내는 원인 값을 갖는 그룹 메시지 확인(Group Message Confirm) 메시지를 송신하고, 이 단계에서 흐름이 중지된다. 도 10의 예에서, SCS/AS는 명시적 할당 해제를 요청함으로써 단계 3에서 할당된 TMGI를 후속하여 해제할 수 있거나, 만료 타이머에 의존할 수 있다. 특정 그룹에 대한 MBMS를 이용한 그룹 메시지 인가 전달(Authorization of Group Message delivery)은 규격의 이번 릴리스에서 지정되지 않는다.

도 10의 호출 흐름은 도 11로 계속된다. 도 11의 단계 8에서, SCEF는 MBMS 베어러 활성화 요청(Activate MBMS Bearer Request)(MBMS 브로드캐스트 영역, TMGI, QoS, 시작 시간) 메시지를 BM-SC에 송신한다. SCEF는 운영자 도메인에서의 구성에 기초하여, SCS/AS에 의해 제공되는 위치/영역 정보와 그룹에의 콘텐츠의 배포를 위한 MBMS 브로드캐스트 영역 사이를 맵핑한다. SCEF는 선택된 MBMS 브로드캐스트 영역이 SCS/AS에 의해 나타날 수 있는 영역보다 큰 영역에 걸친 콘텐츠의 브로드캐스트를 야기할 수 있음을 인식할 필요가 있다.

단계 9에서, BM-SC는 세션 시작 절차를 수행한다. 단계 10에서, BM-SC는 MBMS 베어러 활성화 응답(Activate MBMS Bearer Response)을 SCEF에 송신한다. 단계 11에서, SCEF는 요청이 그룹에 전달되도록 수락되었는지 여부를 나타내기 위해, 그룹 메시지 확인[TMGI(임의적), SCEF IP 주소들/포트] 메시지를 SCS/AS에 송신한다.

단계 12에서, 애플리케이션 레벨 상호작용들은 MBMS 서비스 정보, 예컨대 TMGI, 시작 시간의 리트리브를 위해 특정 그룹의 디바이스들 사이에서 발생할 수 있다.

단계 13에서, 요청된 시작 시간에서 또는 요청된 시작 시간 후에, 그러나 만료 시간 전에, SCS/AS는 단계 11에서 수신된 IP 주소와 포트를 이용하여 그룹에 전달될 콘텐츠를 SCEF에 이전한다. SCEF는 단계 9에서 수신된 IP 주소 및 포트를 사용하여, MB2-U를 통해 BM-SC에 콘텐츠를 전달한다. BM-SC는 대응하는 콘텐츠를 UE들에 이전한다. SCS/AS가 UE들이 전달된 콘텐츠에 응답할 것을 기대한다면, 매우 많은 수의 디바이스에 의한 브로드캐스트 메시지에의 잠재적 응답들이 거의 동시에 송신되는 것을 피하기 위해, SCS/AS는 UE들이 반드시 응답 시간 창을 제공받게 할 수 있다. 이 단계에 후속하여, MBMS 베어러들이 활성 상태로 유지되고 할당될 것인지의 여부, 및 얼마나 오랫동안 그러할 것인지는 SCS/AS에 달려있다. TS 23.468에 정의된 메커니즘들은 MBMS 리소스들을 해제하기 위해 SCEF에 의해 사용될 수 있다.

단계 14에서, 수신된 콘텐츠에 응답하여, UE는 곧바로 또는 나중에 SCS/AS와의 통신을 개시할 수 있다. UE 애플리케이션은 임의의 응답들의 배포가 응답 시간 창 내에서 발생할 것을 보장한다.

도 12는 무선 태양 전지 패널, 현장의 액세스 포인트들, 및 태양 전지 패널들의 조절들을 제어하기 위한 백엔드 애플리케이션으로 구성된 태양광 발전소 구성을 보여준다. 태양 전지 패널들은 oneM2M ADN-AE들을 구동한다. 액세스 포인트들은 oneM2M MN-CSE를 운영하고, 백엔드 애플리케이션은 oneM2M MN-AE 또는 IN-AE이다. 각각의 MN-CSE는 그것에 근접한 모든 패널을 관리하고, 각각의 MN-CSE가 관리하는 태양 전지 패널들을 위해 그룹이 생성된다. 태양의 위치가 변경됨에 따라, MN-AE 또는 IN-AE는 전동 마운트들(motorized mounts)을 가장 최적의 위치로 회전시키고/거나 기울이기 위한 팬아웃 커맨드를 송신한다. MN-CSE는 각각의 태양 전지 패널에 커맨드를 유니캐스트하여 조절들을 함으로써 팬아웃 커맨드를 실행한다. 다음으로, 그것은 각각의 태양 전지 패널로부터의 응답들을 집계하고, MN-AE 또는 IN-AE에 결과들로 응답한다.

태양광 발전소 사용 사례에서 볼 수 있는 바와 같이, 팬아웃 동작을 실행할 때 표준 SL 그룹 동작들은 비효율적이다. 이러한 경우들에서의 SL은 그룹의 각각의 구성원에게 요청을 유니캐스트한다. CoAP 그룹 통신들(IP 멀티캐스팅 지원을 가짐) 및 3GPP MBMS와 같은 현재 기술들은 기저 네트워크들에서의 멀티캐스팅을 허용한다. 그러나, 현재, SL은 이러한 기저 기술들을 가능하게 하는 메커니즘들을 지원하지 않는다.

표준 SL들은 로컬 영역 네트워크 내의 디바이스들의 목록, 디바이스의 이웃들의 목록, 및 디바이스들의 슬립 상태와 같은, 로컬 영역 네트워크 자체뿐만 아니라 디바이스들의 네트워크 파라미터들을 제공하는 일부 리소스들을 갖는다. 이 정보는 디바이스들이 슬립 중인 경우 멀티캐스트 메시지들을 다시 스케줄링하는 것과 같이 멀티캐스트 동작들을 위해 사용될 수 있다. 그러나, 리소스들은 SL이 멀티캐스트 그룹들을 생성하고 관리하는 것을 허용하는 충분한 정보를 제공하지 않는다.

일반적으로, 그룹 동작들은 유사한 기능성들을 제공하는 디바이스들, 서로에 매우 가깝게 위치되는 디바이스들, 또는 주기적으로 반복되는 동작에 대해 바람직할 수 있다. 그러나, 표준 SL 그룹 절차들은 일반적으로 팬아웃 동작을 실행할 때 이러한 특성들을 고려하지 않는다.

도 13 및 도 14는 SL 그룹 동작에서 멀티캐스트를 가능하게 하는 예시적인 방법들을 요약하는 하이 레벨의 호출 흐름을 도시하며, 그에 의해 SL은 디바이스 애플리케이션들에 의해 제공된 정보에 기초하여 멀티캐스트 그룹을 생성할 수 있고, SL 애플리케이션은 멀티캐스트 정보로 프로비저닝될 수 있고 필요한 SL 리소스들을 구성할 수 있다. 도 13의 단계 0에서, 애플리케이션들, 서비스 계층, 및 기저 네트워크들이 프로비저닝되어, 서로 통신할 수 있다.

단계 1에서, 디바이스 애플리케이션들은 서비스 계층에 등록한다. 이러한 등록의 일부로서, 디바이스 애플리케이션들은 SL에게 멀티캐스트 그룹들을 생성하고 관리할 권한을 부여하기 위해 멀티캐스트 가능 및 자기-가입 표시자들을 제공할 수 있다. 이 시나리오에서, SL은 디바이스 애플리케이션을 대신하여 self -subscription 리소스를 암시적으로 생성한다. 대안적으로, 디바이스 애플리케이션들은 self - subscription 리소스들 자체를 명시적으로 생성할 수 있고, 다음으로 관리 애플리케이션은 멀티캐스트 그룹을 생성할 것이다.

단계 2에서, netConfig 리소스가 생성된다. 이 리소스는 MLDv2에서 사용되는 것과 유사한 엔티티들/디바이스들 내에서 네트워크 파라미터들을 구성하는 능력을 제공한다. 그것은 엔티티 애플리케이션들이 멀티캐스트 메시지들을 모니터링하기 위해 사용하는 멀티캐스트 주소 및 다른 네트워크 파라미터들을 구성한다. 구성은 MLDv2에서와 같이 디바이스 자체에 의해 수행될 수 있다. 대안적으로, 리소스는 MLDv2의 네트워크 관리자와 유사한 관리 애플리케이션에 의해, 또는 SL 자신에 의해 구성될 수 있다. netConfig 리소스는 디바이스 애플리케이션이 리소스를 생성하는 경우에 그러한 것이 제공되지 않는다면, 기저 네트워크 식별자들을 획득하기 위한 프로세스를 트리거할 수 있다. 마찬가지로, 관리 애플리케이션은 netConfig 리소스가 기저 네트워크 식별자들로 프로비저닝되었다면, netConfig 리소스를 생성할 때 기저 네트워크 식별자들을 제공할 수 있다.

단계 3에서, SL은 netConfig 리소스에 의해 제공되는 네트워크 파라미터들로 기저 네트워크 또는 다른 SL을 임의로 구성할 수 있다. 이것은 예를 들어 SL 멀티캐스트 그룹 형성의 동적 통지들을 지원하기 위해 사용될 수 있다.

단계 4에서, 단계 9에서 송신된 실제 멀티캐스트 요청의 콘텐츠를 제공하기 위해, SL 멀티캐스트 group 리소스들이 생성된다.

도 13에서 시작된 호출 흐름은 도 14로 계속된다. 도 14를 참조하면, 단계 5에서, SL 멀티캐스트 그룹들은 서비스 계층 내에 형성된다. 이는 netConfig 리소스에 의해 제공되는 네트워크 파라미터 구성을 단계 4에서 제공된 SL group 리소스 의 콘텐츠를 결합하는 것을 수반한다. 즉, SL group 리소스는 멀티캐스트 요청에 들어갈 콘텐츠를 제공한다. 결과적으로, SL 멀티캐스트 그룹을 생성하기 위해, netConfig 및 group 리소스 둘 다가 요구된다. SL 멀티캐스트 그룹은 실시간으로 netConfig 및 SL group 리소스들의 결합에 의해 동적으로 구축된다는 점에서 "가상"이다.

단계 6에서, SL 멀티캐스트 그룹이 생성되고 나면, SL은 엔티티들에게 멀티캐스트 그룹에서의 그것들의 구성원 자격을 통지한다. 이러한 통지는 엔티티들이 SL에 대한 그들의 "자기" 가입을 생성할 때 인에이블되었다. 통지는 소스 SL로부터 목적지 엔티티들로의 멀티캐스트 시스템의 셋업을 완료한다. 통지는 또한 요청된 콘텐츠가 모든 엔티티에 대해 동일하지 않을 때 차별화된 콘텐츠를 공유하도록 허용한다. 예를 들어, 구성원 리소스들이 다를 수 있으며 상이한 URI들을 가질 수 있다. 다음으로, 통지는 차이점들을 해결하기 위해 멀티캐스트 URI와 리소스 URI 둘 다를 제공할 수 있다.

단계 7에서, 엔티티들 내에서, 통지는 기저 멀티캐스트 API를 호출하는 것을 가능하게 한다. 이 단계는 사용자가 전통적인 IP 멀티캐스트 사례들을 사용하여 멀티캐스트 애플리케이션을 런칭하는 것과 유사하지만, 여기에는 전통적인 IP 멀티캐스트에서는 발견되지 않는 소스 엔티티와 목적지 엔티티 사이의 소정 수준의 조정(coordination)이 존재한다. 다음으로, 엔티티들은 멀티캐스트 메시지들을 청취하기 시작한다. 대안적으로, 단계 6에서 수신된 통지는 멀티캐스트 메시지들의 청취를 언제 시작할지에 관한 스케줄을 제공할 수 있다.

단계 8에서, SL 애플리케이션은 RESTful 동작에 기초하여 이전에 생성된 그룹에 팬아웃을 수행한다.

단계 9에서, SL은 멀티캐스트 메시지들을 송신하고 엔티티들로부터의 개별 응답들을 기다린다. SL은 다양한 리소스들을 통해 각각의 디바이스의 슬립 상태를 알 수 있으므로, SL은 슬립 중인 디바이스로부터의 응답을 기다리지 않아도 될 수 있다. 이것은 SL 내의 멀티캐스트 동작을 최적화한다.

단계 10에서, 일단 모든 응답이 수신되고 나면, SL은 요청 애플리케이션에 집계된 응답들을 반환한다.

IoT 시스템에서 멀티캐스트 동작들을 인에이블하기 위한 SL 상호작용들은 다수의 방식으로 발생할 수 있다. SL 게이트웨이는 그 뒤에 있는 다수의 디바이스를 관리할 수 있으며, 멀티캐스트 메시지를 개시하는 엔티티일 수 있다. SL은 기저 네트워크와 상호작용하여 그룹 메시징을 구성할 수 있다. 두 경우 모두에서, SL 멀티캐스트 그룹의 생성은 관리 애플리케이션에 의해 개시될 수 있다. 액세스 권한들을 갖는 임의의 SL 애플리케이션은 멀티캐스트 그룹의 생성을 개시할 수 있다. 또한, 멀티캐스트 메시지의 궁극적인 타겟들인 디바이스 애플리케이션들은 SL group 리소스에 자신을 추가함으로써 참여할 수 있다. 이러한 경우들에서, 디바이스 애플리케이션은 group 리소스의 multicastIDs 속성을 리트리브하여 netConfig 리소스를 식별한다. 다음으로, 애플리케이션은 netConfig 리소스를 리트리브하여 멀티캐스트 주소 및 네트워크 파라미터들을 획득하고, 그 후에, 그것은 예를 들어 예 1 및 예 2에 도시된 바와 같이 멀티캐스트에 대한 청취를 시작/중지하기 위해 API를 호출한다. 마지막으로, 디바이스 애플리케이션은 group 리소스 내의 그룹의 구성원들에 자기 자신을 추가할 수 있다.

SL은 기존 IP 멀티캐스트 기반구조의 멀티캐스트 능력을 이용할 수 있다. netConfig 리소스에 의해 제공되는 정보로, SL은 멀티캐스트 주소에서 트래픽을 모니터링하고 디바이스를 관리하고 있는 멀티캐스트 라우터에 멀티캐스트 메시지를 송신하도록 디바이스를 구성할 수 있다. 멀티캐스트 그룹 내의 자신의 포함에 대한 통지를 수신하면, 디바이스는 멀티캐스트 라우터에게 특정 멀티캐스트 주소에 대한 자신의 관심을 통보하기 위해 기저 MLD 프로토콜을 사용할 수 있다. 그러한 데이터는 netConfig 리소스에 포함될 수 있다.

복수의 SL 멀티캐스트 그룹 구성이 특정 SL group 리소스에 대해 인에이블되는 경우들이 있을 수 있다. 그러한 경우들은 예를 들어 SL 그룹의 구성원들이 멀티캐스트를 지원하는 별개의 네트워크들, 예를 들어, 로컬 영역 네트워크 및 셀룰러 네트워크 멀티캐스트 그룹에 위치될 때 발생할 수 있다. 그러한 경우들에서, 복수의 로컬 영역 네트워크, 셀룰러 네트워크, 또는 이러한 네트워크들의 조합들이 존재할 수 있다. 그룹의 일부 구성원이 멀티캐스트를 지원하지 않는 것이 또한 가능하고, 따라서 그러한 구성원에 대해 유니캐스트 요청이 이루어질 수 있다. 그러한 경우들에서, 멀티캐스트 요청과 유니캐스트 요청의 결합이 사용된다.

전통적인 서비스 계층 등록은 엔티티가 멀티캐스팅을 지원할 수 있다는 표시, 예컨대 등록 요청 내의 플래그에 의해 향상될 수 있다. 등록은 등록 요청 내의 다른 플래그일 수 있는 자기-가입 표시의 사용에 의해 더 향상될 수 있다. 멀티캐스트 능력 표시자는 엔티티가 멀티캐스트 가능한지, 및 엔티티가 멀티캐스트 그룹에 포함될 수 있는지 둘 다를 나타낼 수 있다. 자기-가입 표시자는 SL이 엔티티에게 그 엔티티가 일부를 이루는 그룹 및 멀티캐스트 구성원 자격을 통지하기 위해 사용될 수 있는 통지 URI를 포함할 수 있다.

도 15는 SL이 SL 등록 요청 내의 애플리케이션 또는 다른 SL에 의해 제공되는 자기-가입 표시자에 기초하여 암시적으로 가입 리소스를 생성하는 예시적인 호출 흐름을 도시한다. 엔티티는 또한 멀티캐스트 가능 표시자를 제공한다.

단계 0에서, 디바이스 및 서비스 계층은 서로 통신할 수 있도록 적절하게 부트스트랩되며, 이는 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차를 포함한다.

단계 1에서, 디바이스 애플리케이션(또는 다른 서비스 계층)은 등록 요청을 송신한다. 요청은 애플리케이션이 멀티캐스트 가능임을 나타낸다. 요청은 또한 자기-가입 표시자 및 통지 URI를 포함한다. 멀티캐스트 가능 속성에 더하여, 등록 메시지는 엔티티가 수신할 수 있는 멀티캐스트 메시징의 유형들을 포함할 수 있다. 멀티캐스트 메시징의 유형들의 예들은 MBMS, 셀 브로드캐스트, IP 멀티캐스트 등이다. 추가로, 네트워크 표시자는 메시징 방법의 각각의 유형을 동반할 수 있다. 네트워크 표시자는 각각의 메시징 방법과 함께 사용될 수 있는 네트워크의 유형(예를 들어, 3GPP/셀룰러) 또는 네트워크 이름(예를 들어, PLMN 이름)을 나타낼 수 있다. 추가로, 엔티티가 이미 그룹에 연관되어 있는 경우, 또는 엔티티가 이미 그룹에 연관된 디바이스 상에서 호스팅되는 경우, 등록 메시지는 또한 그룹 이름을 포함할 수 있다.

단계 2에서, 등록 요청을 수신하면, 서비스 계층은 엔티티가 등록하도록 허용되는지를 확인하기 위해 인가 정책을 검사한다. 허용된 경우, SL은 단계 3으로 진행한다. 그렇지 않은 경우, SL은 단계 4로 이동한다.

단계 3에서, 요청이 애플리케이션 리소스를 생성하는 데 요구되는 모든 정보를 포함하는 경우, SL은 멀티캐스트 가능 메타데이터를 갖는 리소스를 생성한다. 추가로, 엔티티가 자기-가입 표시자를 포함하는 경우, SL은 또한 연관된 통지 URI가 제공되었다면 그것과 함께 애플리케이션에 대한 가입 리소스를 생성한다. 통지 URI가 제공되지 않았으면, SL은 자신이 선택한 URI를 지정할 수 있고, 단계 4에서 송신되는 응답에 그것을 포함시킬 수 있다. "자기" 가입 리소스 내의 통지 URI는 나중에 디바이스 애플리케이션/SL에 멀티캐스트 그룹 내로의 그것의 포함을 통지하기 위해 SL에 의해 이용될 수 있다.

단계 4에서, SL은 가입 리소스가 생성된 경우 가입 리소스에 대한 임의의 정보를 포함하여, 등록 요청의 결과들에 기초하여 응답을 송신한다.

SL이 가입 리소스를 암시적으로 생성하는 것에 대한 대안으로서, 디바이스 애플리케이션/SL은 또한 도 16의 예에 도시된 것과 같이 별도의 요청으로 가입을 명시적으로 생성할 수 있다. 엔티티는 그것이 멀티캐스트 가능임을 나타내기 위해 등록 요청에 새로운 멀티캐스트 가능 리소스 속성을 포함시킬 수 있다. 다음으로, 그것은 명시적으로 가입 리소스를 생성하고, 새롭게 제안된 자기-가입 리소스 속성을 포함시킬 수 있다.

도 16의 단계 0에서, 엔티티 및 SL은 서로 통신할 수 있도록 적절하게 부트스트랩된다. 이것은 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견을 포함한다.

단계 1에서, 엔티티는 multicastCapable 리소스 속성과 함께 등록 요청을 송신한다.

단계 2에서, 등록 요청을 수신하면, SL은 엔티티가 등록하도록 허용되는지 확인하기 위해 인가 정책을 검사한다. 허용되면, SL은 단계 3로 이동하고; 그렇지 않으면 SL은 단계 4로 이동한다.

단계 3에서, SL은 애플리케이션 리소스를 생성하고, multicastCapable 리소스 속성을 설정한다. 이 속성은 SL이 디바이스가 멀티캐스트를 지원하는지 여부, 및 그것이 멀티캐스트 그룹의 일부일 수 있는지 여부를 자율적으로 결정할 수 있게 한다.

단계 4에서, SL은 요청을 처리한 결과에 기초하여 등록 요청에 대한 응답을 송신한다.

단계 5에서, 엔티티는 적절한 통지 URI를 갖는 self - subscription 속성을 포함하여, 자신의 애플리케이션 리소스 하에 가입을 생성한다.

단계 6에서, SL은 엔티티의 액세스 제어 정책을 검사하여, 그것이 self -subscription을 생성할 수 있을 것을 보장한다. 액세스가 허가되는 경우, SL은 단계 7로 이동하고, 그렇지 않으면 단계 8로 이동한다.

단계 7에서, SL은 <subscription> 리소스를 생성하고, self - subscription 리소스 속성을 포함시킨다. 단계 8에서, SL은 가입 생성의 적절한 응답을 엔티티에 송신한다.

자기-가입 속성은 SL이 자발적인 방식으로 가입 엔티티와 통신하는 것을 허용함으로써 SL 가입 기능성을 향상시킨다. 자기-가입은 디바이스 애플리케이션에 의한 소정의 액션을 요구하는 SL 상의 디바이스 애플리케이션의 리소스들 중 하나를 타겟팅하는 임의의 요청이 디바이스 애플리케이션이 송신될 수 있음을 나타낸다. 이는 전통적인 가입 거동과 다르며, 여기서 가입은 부모 리소스의 변경들에만 적용된다.

자기-가입 기능성은 다른 방식들로 사용될 수 있다. 예를 들어, SL은 제3자 애플리케이션에 대한 액세스 제어 권한들을 허가하기 위해 엔티티로부터의 승인을 얻어야 할 수 있다. 여기서, 멀티캐스팅과 마찬가지로, 요청들은 제3자 애플리케이션들에 의해 개시된 요청들에 의해, 또는 효율적인 해결(resolution)을 위해 엔티티와의 통신을 요구하는, 엔티티에 속한 리소스들 상의 서비스 계층들에 의해 트리거될 수 있다.

자기-가입의 다른 용도는 서비스 계층이 관리 커맨드들을 최종 디바이스에 송신하기를 원할 수 있는 네이티브 서비스 계층 디바이스 관리에 있다. 등록 시에, 디바이스는 서비스 계층 내에 디바이스 관리 리소스들을 생성할 수 있다. 다음으로, 서비스 계층이 디바이스 상에서 관리 기능들을 수행하라는 외부 요청들이 존재하는 경우 디바이스에 통지할 것을 요청하기 위해, 자기-가입 기능성이 사용될 수 있다. 제3자가 관리 액션이 디바이스 상에서 수행될 것을 요청하면, 자기-가입 기능성이 트리거될 것이고, 서비스 계층은 관리 기능의 콘텐츠와 함께 디바이스에 통지를 송신할 것이다.

서비스 계층 netConfig 리소스는 멀티캐스트 그룹들을 생성하는 데에 사용할 네트워크 구성 파라미터들을 제공함으로써 기저 네트워크들 내의 멀티캐스트 능력들의 구성을 가능하게 하기 위해 사용될 수 있다. netConfig 리소스는 또한 네트워크 파라미터들의 전체적인 구성을 위해 사용될 수 있다. netConfig 리소스에 대한 일부 예시적인 파라미터가 표 5에 제공된다. netConfig 리소스는 oneM2M의 [areaNwkInfo] 및 [areaNwkDeviceInfo] 관리 객체들과 같은 기존 SL 리소스의 자식 리소스일 수 있다. 대안적으로, netConfig는 자체적인 독립형 SL 리소스일 수 있다. netConfig 리소스는 기저 네트워크 기술의 네트워크 파라미터들을 지닐 수 있으며, 그것의 속성들은 예를 들어 IP, 셀룰러, 블루투스 등과 같은 네트워크 유형에 의존한다.

netConfig 리소스는 통신을 위해 사용되는 등록된 디바이스의 로컬 네트워크 인터페이스의 네트워크 파라미터들을 제공하는 데 사용될 수 있다. 대안적으로, 멀티캐스트 그룹 구성에서 네트워크 파라미터들을 지정하기 위해 netConfig 리소스가 사용될 수 있다. 디바이스 애플리케이션들은 전형적으로 로컬 netConfig 리소스를 생성할 것이고 멀티캐스트 netConfig 리소스를 또한 생성할 수 있다. 관리 애플리케이션들은 디바이스 로컬 및 멀티캐스트 netConfig 리소스 둘 다의 생성을 개시할 수 있다. SL들은 멀티캐스트 netConfig 리소스의 생성을 개시할 수 있다.

엔티티가 SL에 성공적으로 등록한 후, 네트워크 리소스들이 생성될 수 있고, 영역 네트워크 유형, 영역 네트워크 내의 디바이스들의 목록, 이웃 노드들의 목록, 및 디바이스가 가질 수 있는 임의의 슬립 상태와 같은 정보를 제공받을 수 있다. 이 정보는 oneM2M의 [areaNwkInfo] 및 [areaNwkDeviceInfo]와 같은 SL 리소스에서 찾아질 수 있다.

SL이 기저 네트워크 리소스들의 더 지능적인 사용을 할 수 있게 하는 추가의 네트워크 파라미터들은, 하나 이상의 netConfig 리소스들을 생성함으로써 제공될 수 있다. 이러한 netConfig 리소스들은 이더넷 및 WiFi 인터페이스들과 같이, 디바이스들이 통신들을 위해 지원하는 네트워크 인터페이스들에 연관될 수 있다. 표 5는 표준 서비스 계층에는 완전히 지정되지 않았지만 새로운 netConfig 리소스들에는 포함될 수 있는 상이한 네트워크 액세스 기술들에 대한 일부 네트워크 파라미터들을 보여준다. 예를 들어, 디바이스가 복수의 네트워크 액세스 기술을 지원하거나, 디바이스가 멀티-홈(multi-homed)이거나, SL이 복수의 멀티캐스트 그룹을 생성하기를 원하는 경우, 복수의 netConfig 리소스 인스턴스가 이용될 수 있다. 리소스의 콘텐츠는 [areaNwkInfo]에 의해 지정된, 또는 부모 네트워크 리소스가 없을 때는 netConfig 내의 속성으로서 지정된 네트워크 유형에 의존할 것이다.

netConfig 리소스는 디바이스 애플리케이션에 의해 또는 관리 애플리케이션에 의해 생성될 수 있다. netConfig 리소스에 제공된 정보는 디바이스의 네트워크 파라미터들을 포함한다. 이들은 통신을 위해 디바이스에 의해 이용되는 디바이스 특정 네트워크 구성들, 예컨대 IP 주소 및 도메인 이름일 수 있다. 추가로, ProtocolsSupported 파라미터는 디바이스 애플리케이션이 어느 프로토콜들을 이해하는지의 표시를 제공하며, 디바이스에 어떻게 통신할지의 SL 지식을 제공하기 위해 사용될 수 있다. SL은 디바이스에 통신할 때 사용할 바람직한 프로토콜 바인딩(예를 들어, HTTP, CoAP)을 식별하기 위해 이 목록을 사용할 수 있다. 예를 들어, MTU는 디바이스가 처리할 수 있는 최대 크기 메시지이다. CoAP와 함께 사용될 때, 이것은 사용되는 블록 크기를 결정할 수 있다. 마지막으로, 디폴트 게이트웨이 및 지원되는 프로토콜 내의 MLD의 존재는 디바이스가 MLD 리포트들을 게이트웨이로 송신할 수 있고 SL이 게이트웨이에 의해 포워딩될 멀티캐스트 메시지를 게이트웨이에 송신할 수 있음을 나타낼 수 있다.

netConfig 리소스는 또한 멀티캐스트 그룹의 파라미터들을 구성하기 위해 사용될 수 있다. 각각의 그룹에 대한 netConfig 리소스로 상이한 동작들에 대해 복수의 멀티캐스트 그룹이 생성될 수 있다. 예를 들어, SL 게이트웨이는 그것이 관리하는 각각의 멀티캐스트 그룹들에 대해 상이한 netConfig 리소스들을 가질 수 있는데, 하나는 펌웨어를 다운로드하기 위한 것이고, 하나는 정보를 리트리브하기 위한 것이고, 다른 하나는 상이한 정보를 리트리브하기 위한 것이며, 네번째 것은 정보를 업데이트하기 위한 것이다.

SL이 등록 엔티티들로부터 멀티캐스트 능력 표시들을 수신하고, 서비스 계층 netConfig 리소스가 생성되고 나면, 서비스 계층(및 관리 애플리케이션들)은 SL 그룹 동작들을 수행할 수 있다. SL은 netConfig 및 group 리소스들로부터의 정보를 사용하여 멀티캐스트 그룹을 형성할 수 있다. SL group 리소스의 생성 동안, 그룹의 구성원들이 지정된다. SL이 SL 멀티캐스트 그룹들을 자율적으로 생성하는 경우, 그것은 그룹 내의 어느 구성원들이 멀티캐스트 능력을 지원하는지, 및 동일한 영역 네트워크 내의 어느 다른 디바이스들이 각각의 멀티캐스트 가능 디바이스를 통해 도달될 수 있는지를 검사할 수 있다. 그룹의 구성원이 멀티캐스트를 지원하고, 동일한 영역 네트워크 내에 다른 그룹 구성원들이 존재하는 경우, 멀티캐스트 그룹이 생성될 가능성이 크다. 예를 들어, SL은 netConfig 리소스의 디폴트 게이트웨이(Default Gateway) 파라미터를 사용하여 동일한 로컬 영역 네트워크에 속하는 디바이스들을 결정할 수 있다. 멀티캐스트 그룹이 생성될 수 있다고 결정되면, SL은 다음으로 netConfig 리소스를 생성한다.

SL은 group 리소스 내의 새로운 속성 multicastIDs로서 netConfig 리소스의 URI를 제공할 수 있고, 그것을 응답으로 요청자에게 반환할 수 있다. multicastIDs 속성은 하나보다 많은 멀티캐스트 그룹을 포함할 수 있고, 하나 이상의 netConfig 리소스를 가리키는 URI들의 목록으로 구성될 수 있다. group 리소스가 별개의 네트워크들에 상주하는 구성원들을 포함하는 경우, 복수의 멀티캐스트 그룹이 생성될 수 있다. 예를 들어, 그룹의 일부 구성원들이 특정 게이트웨이에 의해 관리되는 한편, 다른 구성원들이 3GPP 코어 네트워크에 의해 관리되는 경우, 동일한 SL 그룹에 대해 2개의 멀티캐스트 그룹이 생성될 수 있다.

도 17은 SL이 group 리소스 생성 요청으로부터 멀티캐스트 그룹들을 자율적으로 생성하는 예시적인 호출 흐름을 도시한다. 단계 0에서, 관리 애플리케이션 및 서비스 계층은 서로 통신할 수 있도록 적절하게 부트스트랩된다. 이는 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견을 포함한다. 또한, 이 단계에서, 디바이스 애플리케이션들(도시되지 않음)은 멀티캐스트 능력, 자기-가입 URI, 및 네트워크 파라미터들과 같은 SL 정보를 제공했다.

단계 1에서, 관리 애플리케이션은 디바이스 애플리케이션들을 위해 SL 내에 group 리소스를 생성할 것을 요청하고, 여기서 디바이스 애플리케이션들은 memberIDs들에 연관된다.

단계 2에서, SL은 애플리케이션이 group 리소스를 생성하기 위한 액세스 권한들을 갖는 것을 검사한다. 액세스가 허가되는 경우, SL은 단계 3으로 이동하고, 그렇지 않으면 단계 5로 이동한다.

단계 3에서, SL은 요청을 처리하고, 제공된 정보에 기초하여 group 리소스가 생성되어야 하는지 여부를 결정한다. SL은 memberIDs를 조사하고, 각각의 구성원이 멀티캐스트 가능인지를 검사한다. 복수의 구성원이 멀티캐스트 가능이고, 그것들이 동일한 로컬 영역 네트워크 상에 상주하는 경우, SL은 다음으로 멀티캐스트 그룹을 생성할 수 있다. 멀티캐스트 그룹이 생성되면, SL은 단계 4로 이동하고, 그렇지 않으면 단계 5로 이동한다. 멀티캐스트 그룹이 생성될 수 없는 경우들, 예컨대, 디바이스들이 멀티캐스트를 지원하지 않거나 동일한 영역 네트워크 내에 위치되지 않는 경우가 존재할 수 있다. 이러한 경우들에서, SL은 디폴트로 유니캐스트 메시지들을 송신할 수 있다. 멀티캐스트 및 유니캐스트 메시지 둘 다가 송신되는 경우들도 존재할 수 있고, 여기서 구성원들의 일부는 멀티캐스트를 지원하지만 다른 구성원들은 그렇지 않다. SL은 복수의 디바이스가 별개의 로컬 네트워크들 각각에 위치되는 상황을 처리하기 위해 하나보다 많은 멀티캐스트 그룹을 만들기로 더 결정할 수 있다.

단계 4에서, SL은 단계 3에서 이루어진 결정에 기초하여 하나 이상의 멀티캐스트 그룹을 형성한다. SL은 각각의 멀티캐스트 그룹에 대한 netConfig 리소스를 생성한다. group 리소스는 2개의 상이한 로컬 영역 네트워크로부터의 구성원들로 이루어질 수 있고, 결과적으로 2개의 멀티캐스트 그룹이 생성될 수 있다. 멀티캐스트 주소는 all - nodes 또는 all - COAP - node 멀티캐스트 주소들과 같은 소정의 잘 알려진 멀티캐스트 주소일 수 있다. 대안적으로, 멀티캐스트 주소는 소정의 SL 정책 또는 구성에 기초할 수 있다.

단계 5에서, SL은 요청을 처리한 결과에 기초하여 애플리케이션에 대한 응답을 송신하고, multicastIDs의 속성을 임의로 포함할 수 있다. 관리 애플리케이션은 멀티캐스트가 인에이블되었는지를 결정하고, 멀티캐스트가 인에이블되었다면, 멀티캐스트 구성을 어디에서 찾을지를 결정하기 위해, multicastIDs에 의해 제공된 정보를 사용할 수 있다. 이는 관리 애플리케이션이 장래에 멀티캐스트 주소를 변경하는 것을 허용한다.

도 18은 관리 애플리케이션이 netConfig 리소스를 생성하는 예시적인 대안의 호출 흐름이다. netConfig 리소스는 영역 네트워크의 지식, 및 멀티캐스트가 시스템 내에서 사용되는 방법의 지식을 갖는 관리 애플리케이션에 의해 생성될 수 있다. 이 경우, 관리 애플리케이션은 멀티캐스트 그룹의 세부사항들로 프로비저닝될 수 있으며, SL이 netConfig를 생성하게 하는 대신에 그것을 선제적으로 생성할 수 있다.

단계 0에서, 관리 애플리케이션 및 서비스 계층은 서로 통신할 수 있도록 적절하게 부트스트랩된다. 이것은 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차를 포함한다. 이러한 시나리오에서, 관리 애플리케이션은 멀티캐스트 시스템 및 디바이스의 동작들에 관한 지식을 갖는다.

단계 1에서, 관리 애플리케이션은 멀티캐스트 네트워크에 대해 사전 프로비저닝된 정보에 기초하여 netConfig 리소스를 생성할 것을 요청한다. 이는 멀티캐스트 네트워크를 구성하는 네트워크 관리자에 의해 수행될 수 있다. 또한, 서비스 제공자의 콘텐츠를 멀티캐스팅하는 것을 통해 그것의 고객들을 서빙하기 위해 서비스 제공자에 의해 수행될 수 있다.

단계 2에서, SL은 애플리케이션이 netConfig 리소스를 생성하기 위해 액세스 권한들을 갖는 것을 검사한다. 액세스가 허가되는 경우, SL은 단계 3으로 이동한다. 그렇지 않으면, 단계 4로 이동한다.

단계 3에서, 제공된 정보가 유효한 경우, SL은 netConfig 리소스를 생성한다.

단계 4에서, SL은 처리 결과에 기초하여 관리 애플리케이션에 응답을 송신한다. netConfig 리소스의 성공적인 생성의 경우, 응답은 netConfig 리소스의 URI들을 갖는 multicastIDs를 포함한다. 단계 1 내지 단계 4는 각각 상이한 멀티캐스트 주소들을 위한 것인 복수의 [netConfig] 리소스들을 생성하기 위해 반복될 수 있다.

단계 5에서, 다음으로, 관리 애플리케이션은 연관된 memberIDs 및 multicastIDs 속성을 갖는 group 리소스를 생성할 것을 요청한다.

단계 6에서, SL은 애플리케이션이 group 리소스를 생성할 액세스 권한들을 갖는 것을 검사한다. 액세스가 허가되면, SL은 단계 7로 이동하고; 그렇지 않으면 단계 8로 이동한다.

단계 7에서, SL은 multicastIDs 속성을 갖는 group 리소스를 생성한다. 단계 8에서, SL은 multicastIDs 속성을 갖는 애플리케이션에 적절한 응답을 송신한다.

도 19는 관리 애플리케이션이 기저 네트워크 내의 멀티캐스트 그룹의 생성을 트리거하기 위해 netConfig 리소스를 생성하게 하는 예시적인 방법을 보여준다. 이러한 경우에서의 netConfig 리소스는 도 10 및 도 11에 도시된 것과 같은 3GPP 멀티캐스트 그룹의 셋업에 적용된다. 3GPP 파라미터들이 프로비저닝을 통해 관리 애플리케이션에 의해 알려진 경우, 그것들은 netConfig 리소스 내에 파라미터들로서 제공될 수 있다. 단계 0에서, 관리 애플리케이션, SL, 및 기저 네트워크는 서로 통신할 수 있도록 적절하게 부트스트랩되며, 그것은 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차를 포함한다. 이 경우의 기저 네트워크는 3GPP 네트워크이며, SL은 특히 SCEF와 통신한다.

단계 1에서, 관리 애플리케이션은 그것에 프로비저닝된 일부 3GPP 식별자를 갖는 netConfig 리소스를 생성한다. 이러한 netConfig 리소스 생성 요청은 SL이 멀티캐스트 그룹을 생성하기 위한 SCEF에의 요청을 트리거할 것이다.

단계 2에서, SL은 애플리케이션이 netConfig 리소스를 생성하기 위한 액세스 권한들을 갖고 있는 것을 검사하고, 액세스가 허가되는 경우, 단계 3으로 이동한다. 그렇지 않으면 단계 6으로 이동한다.

단계 3에서, SL은 SCEF에 3GPP 그룹 생성 요청을 송신한다. 그룹 생성 요청은 그룹에 속할 디바이스들의 식별자들(예를 들어, 3GPP 외부 또는 내부 디바이스 ID); 요청된 3GPP 외부 그룹 ID 이름; 그룹이 네트워크로부터 자동으로 퍼징될 수 있기 전에 얼마나 오랫동안 존재해야 하는지를 나타내는 그룹 지속시간; 및 그룹과 통신하기 위해 사용될 APN을 포함할 수 있다.

단계 4에서, SCEF는 3GPP 그룹 생성 응답을 반환한다. 그룹 생성 응답은 URI 또는 TMGI와 같은 할당된 3GPP 외부 그룹 ID 이름; 할당된 그룹 지속시간; 단계 3에서 APN이 제공되지 않은 경우, 또는 APN이 SCEF 또는 모바일 코어 네트워크에 의해 할당되는 경우의 할당된 APN; 및 그룹 메시지를 송신하기 위해 이용될 수 있는 EBI를 포함할 수 있다.

단계 5에서, SL은 3GPP 외부 그룹 ID 이름 및 애플리케이션에 의해 제공된 다른 속성들을 갖는 netConfig 리소스를 생성한다. 단계 6에서, SL은 netConfig 생성 요청에 대한 적절한 응답을 반환한다.

netConfig 리소스를 통해 생성된 멀티캐스트 그룹은 메시지의 멀티캐스팅을 실행하기 위한 네트워크 파라미터들만을 제공한다. 그것은 SL의 group 리소스에 의해 제공되는 구성원들의 목록은 포함하지 않는다. 그러므로, 기존 SL group 요청들을 사용하여 그룹 구성원들의 추가 또는 제거가 수행된다. 그러나, SL은 구성원을 제거하는 것이 멀티캐스트 그룹을 제거하는지, 또는 멀티캐스트 그룹 내에 구성원이 존재하지 않는지를 여전히 검사할 수 있다. netConfig 리소스의 제거는 또한 관리 애플리케이션에 의해 행해질 수 있다. 마찬가지로, 새로운 구성원들을 추가하는 것은 하나 이상의 새로운 멀티캐스트 그룹에 대한 새로운 netConfig 리소스들의 생성을 야기할 수 있다.

특정 SL group 리소스를 위해 생성된 하나보다 많은 멀티캐스트 그룹이 존재할 수 있다. 이것은 SL 그룹의 구성원들이 상이한 로컬 영역 네트워크들에 상주할 때, 또는 특정 구성원들이 셀룰러 네트워크 내에 상주하는 한편, 다른 구성원들이 다른 셀룰러 네트워크 내에 상주하는 경우의 사례일 수 있다. 이것이 발생할 때, 복수의 netConfig 리소스가 생성되고, SL group 리소스의 multicastIDs 속성은 각각의 netConfig 리소스들의 URI를 포함한다. 추가로, 동일한 netConfig 리소스가 복수의 SL group 리소스에서 사용될 수 있는데, 예를 들면 멀티캐스트 그룹이 상이한 SL 팬아웃 동작들에 적용된다.

SL 멀티캐스트 그룹 생성에는 멀티캐스트 그룹 구성 통지들 및 멀티캐스트 엔드포인트 통지들과 같은 통지들이 후속될 수 있다. 이러한 통지들은 새로운 netConfig 리소스들의 생성을 나타낼 수 있다. 멀티캐스트 그룹 구성 통지는 어떻게 멀티캐스트 그룹이 생성되어 기저 네트워크 또는 다른 SL들 내의 네트워크 파라미터들을 구성하는 엔티티들에 송신되는지에 관한 네트워크 파라미터들을 운반할 수 있다. 멀티캐스트 엔드포인트 통지들은 멀티캐스트 그룹의 구성원들에게 유니캐스트될 수 있고, 네트워크 파라미터들; 타겟 및 리소스 URI를 포함하는 SL 그룹 요청의 콘텐츠; 및 동작이 생성 또는 업데이트인 경우의 페이로드를 포함한다.

이러한 통지 방법은 netConfig 및 SL group 리소스들의 상태에 기초하여 동적으로 실행된다. 리소스가 다른 SL 또는 소정의 기저 네트워크와 같은 외부 엔티티들에 적용되는 경우, netConfig 리소스가 생성되거나 업데이트될 때마다 통지가 송신되어야 할 수 있다. 추가로, netConfig 및 SL group 리소스들에 기초하여 멀티캐스트 그룹이 생성되는 경우, 디바이스 애플리케이션들이 통지되어야 할 수 있다. 새로운 구성원이 관리 애플리케이션에 의해 멀티캐스트를 지원하는 기존 그룹에 추가되는 경우, 그 새로운 구성원은 자신이 속하는 멀티캐스트 그룹을 통지받아야한다. 추가로, netConfig 리소스 내의 멀티캐스트 주소가 변경된 경우, 그룹의 모든 구성원이 이 변경을 통지받을 필요가 있을 수 있다.

SL이 멀티캐스트 그룹을 생성하고 나면, 그것은 다른 SL들 및 기저 네트워크들과 같은 멀티캐스트 동작들을 수행하는 데 도움을 주는 임의의 엔티티를 포함하여, 관여되는 디바이스들에게 통지할 필요가 있다. 디바이스들의 경우, SL은 자기-가입 통지 URI를 사용하여, 멀티캐스트 주소, 멀티캐스트 요청이 스케줄링된 경우 그것이 이루어질 시간, 디바이스 상의 리소스 URI, 멀티캐스트 요청의 타겟 URI, 및 그것이 생성 또는 업데이트 동작인 경우의 페이로드와 같은 정보를 포함하여, SL이 생성한 멀티캐스트 그룹에 관한 정보와 함께 자발적 요청을 보낼 수 있다. 타겟 URI와 리소스 URI는 다를 수 있다. 타겟 URI는 SL에 의해 생성되며, 후속 멀티캐스트 메시지에서 사용된다. 리소스 URI는 group 리소스의 구성원 ID들로부터 도출되고, 디바이스 내의 리소스에 적용된다. 이 메커니즘은 디바이스들 상의 리소스 URI들이 상이한 그룹 리트리브들을 제공한다. RFC 7390에 언급된 바와 같이, 단 하나의 멀티캐스트 요청만이 송신되므로 타겟 URI는 동일할 필요가 있다. 그러면, 디바이스 애플리케이션은 멀티캐스트 메시지의 타겟 URI를 리소스 URI로서 해석할 것을 알 것이다. 어드레싱되는 모든 리소스가 그룹의 디바이스들 내에서 동일하다면, 리소스 URI 및 타겟 URI도 서로 동일할 수 있다.

디바이스 애플리케이션들에 대한 통지는 두 가지 목적으로 작용한다. 첫째, 통지는 디바이스가 어웨이크하여 적절한 멀티캐스트 주소에서 청취하고 있을 것을 보장한다. 둘째, MLD 또는 IGMP를 지원하는 디바이스들에 대해, 통지는 멀티캐스트 라우터들에게 멀티캐스트 메시지를 포워딩할 것을 지시하기 위한 적절한 MLD/IGMP 리포트의 송신을 트리거한다. 디바이스가 MLD를 지원하는 경우들에 대해, 디바이스 애플리케이션은 통지를 수신한 후 MLD 리포트를 송신한다. 디바이스들이 MLD 또는 IGMP를 지원하지 않는 경우에서, SL은 멀티캐스트 메시지를 포워딩할 디바이스들을 관리하는 SL에 통지할 필요가 있다. 결과적으로, 이러한 통지 메커니즘은 메시지를 멀티캐스팅하는 것이 가능한 한 효율적일 것임을 보장하는 데 도움을 줄 것이다.

도 20은 멀티캐스트 그룹 생성을 원격 SL들에게 통지하기 위한 예시적인 방법을 도시한다. 도 20에서, 게이트웨이는 SL 서버에 등록되고, 적절한 관리 리소스들이 SL 서버 상에 생성되었다. oneM2M에서, 이러한 리소스들은 <node> 및 <areaNwkInfo> 리소스를 포함할 수 있다. 관리 애플리케이션은 멀티캐스트 그룹 구성 파라미터들 함께 SL 서버 상에 netConfig 리소스를 생성한다. 결국, SL 서버는 netConfig 리소스를 생성함으로써 게이트웨이에 통지한다. 추가로, 관리 애플리케이션은 구성원들 중 일부는 SL 게이트웨이에 의해 관리되고 다른 것들은 제2 SL 게이트웨이(도시되지 않음)에 의해 관리되는 group 리소스를 생성한다. 이 요청은 또한 게이트웨이가 관리하는 구성원들만을 포함하는 SL 게이트웨이들 상의 group 리소스를 생성하도록 SL 서버를 트리거한다.

단계 0에서, 관리 애플리케이션, SL 서버, 및 SL 게이트웨이는 서로 통신하도록 프로비저닝된다. SL 게이트웨이는 SL 서버에 등록되고, 적절한 네트워크 리소스들이 생성된다. SL 게이트웨이에 접속된 디바이스들은 멀티캐스트 동작들을 위해 구성된다. 관리 애플리케이션은 먼저 멀티캐스팅을 위해 사용할 멀티캐스트 주소 및 네트워크 파라미터들을 제공하기 위해 netConfig 리소스를 생성한다. 다음으로, 일부 구성원들이 SL 게이트웨이에 의해 관리되는 group 리소스를 생성한다.

추가 구성원들은 다른 게이트웨이(도시되지 않음)에 의해 관리된다. 2개의 게이트웨이에 대해 단계 2-4 및 단계 6-8이 실행된다. 각각의 게이트웨이 상에 생성되는 netConfig 리소스는 그것들이 별개의 로컬 영역 네트워크들 상에 있기 때문에 동일한 정보를 포함할 수 있다. 그러나, 각각의 게이트웨이 상에서 생성되는 group 리소스의 콘텐츠는 상이한 그룹 구성원들을 갖는 것으로 인해 상이할 수 있다.

단계 1에서, 서비스 계층은 관리 애플리케이션으로부터 netConfig를 생성하라는 요청을 수신한다. 도 18의 단계 1-4를 참조하여 설명된 바와 같이, 서비스 계층은 리소스를 생성하기 전에 관리 애플리케이션의 액세스 제어 권한들을 검사하고, 이러한 처리의 결과들을 관리 애플리케이션에 통지한다. 대안적으로, 도 20의 단계 1에서, 관리 애플리케이션 및 서비스 계층은 도 19의 단계 1-6을 실행할 수 있다. 멀티캐스트 네트워크 파라미터들은 netConfig 리소스에 제공된다. 필요에 따라 복수의 멀티캐스트 그룹을 지원하기 위해, 하나보다 많은 netConfig 리소스가 생성될 수 있다.

도 20을 다시 참조하면, 단계 2에서, netConfig 리소스를 생성한 후, SL 서버는 SL 게이트웨이 상에 대응하는 netConfig 리소스를 생성함으로써 SL 게이트웨이에게 그것이 멀티캐스트 메시지들을 송신할 것임을 통지한다. netConfig 리소스의 콘텐츠는 관리 애플리케이션에 의해 제공된 정보를 반영한다.

단계 3에서, SL 게이트웨이는 netConfig 리소스를 로컬로 생성한다.

단계 4에서, SL 게이트웨이는 성공을 나타내는 적절한 응답을 SL 서버에 송신한다.

단계 5에서, 관리 애플리케이션은 예를 들어 도 18의 단계 5-8을 참조하여 설명된 방법들에 따라, 구성원들이 2개의 상이한 게이트웨이에 위치되는 그룹을 생성한다. SL 서버는 생성된 그룹이 SL 등록 동안 multicastCapable 표시자를 통해 각각의 게이트웨이에 의해 제공된 정보를 이용함으로써 2개의 게이트웨이에 의해 서비스되는 2개의 멀티캐스트 그룹으로 최적화될 수 있음을 결정한다. 각각의 게이트웨이는 netConfig 리소스의 생성에 대한 성공 응답을 제공한다. 응답이 성공적이지 않았으면, SL 서버는 SL 게이트웨이들 상에서 멀티캐스트를 사용할 수 없다.

도 20의 단계 6에서, SL 서버는 각각의 SL 게이트웨이 상에서 각각의 게이트웨이가 관리하는 구성원들만을 갖는 group 리소스를 생성한다. 단계 7에서, 각각의 SL 게이트웨이는 group 리소스를 생성하고, 자기 자신의 netConfig 리소스의 URI를 가리키도록 multicastIDs 속성을 설정한다. 단계 8에서, SL 게이트웨이는 SL 서버에 적절한 응답을 반환한다.

도 21은 SL이 도 19를 참조하여 설명된 방법에 의해 생성된 멀티캐스트 그룹과 같은 멀티캐스트 그룹에 대한 변경들에 관련하여 기저 네트워크를 업데이트하는 예시적인 경우를 도시한다. 도 19의 예에서, 멀티캐스트 그룹이 구성될 때, SL은 그룹의 구성원들에 관한 정보를 갖지 않았다. 단계 9에서 SL group 리소스가 생성될 때, SL은 그룹 업데이트 요청을 수행함으로써 변경을 기저 네트워크에 통지한다. 추가로, 디바이스 애플리케이션들이 통지받을 필요가 있다. 이 통지는 네트워크 파라미터들뿐만 아니라 멀티캐스트 메시지의 콘텐츠에 관한 정보, 예를 들어 어떤 애플리케이션 콘텐츠가 요청되고 있는지를 포함하기 때문에 멀티캐스트 그룹 구성 통지와 다르다.

도 21을 다시 참조하면, 단계 0에서, 관리 애플리케이션, 서비스 계층, 기저 네트워크, 및 디바이스 애플리케이션들은 서로 통신할 수 있도록 적절하게 부트스트랩되고, 이는 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차를 포함한다. 도 21의 예에서, 관리 애플리케이션은 멀티캐스트 시스템, 및 디바이스의 동작들에 관한 지식을 가지고 있다. 이 경우에서의 기저 네트워크는 3GPP 네트워크이며, SL은 특히 SCEF와 통신한다.

도 21의 단계 1 내지 6은 도 19의 단계 1 내지 6과 동일하다. 여기서, 도 21에서, SL이 그룹 생성 요청을 할 때, 그것은 그룹의 구성원들을 알지 못했다. 그것은 멀티캐스트 그룹에 대한 네트워크 파라미터들만을 구성했다.

단계 7에서, 관리 애플리케이션은 연관된 memberIDs 및 multicastIDs 속성들을 갖는 SL group 리소스를 생성한다. multicastIDs 속성은 단계 1-6에서 생성된 netConfig 리소스의 URI를 포함한다.

단계 8에서, SL은 애플리케이션이 group 리소스를 생성할 액세스 권한들을 갖는지를 검사한다. 액세스가 허가되면, SL은 단계 9로 이동하고; 그렇지 않으면 단계 12로 이동한다.

단계 9에서, SL은 memberIDs 및 multicastIDs 속성들을 갖는 group 리소스를 생성한다. multicastIDs 속성 내의 URI들은 하나 이상의 netConfig 리소스를 가리키며, 이는 멀티캐스트 그룹에 대한 네트워크 파라미터들을 제공한다. 이러한 2개의 리소스의 결합으로, SL은 SL 멀티캐스트 그룹들을 동적으로 생성할 수 있다. 결과적으로, 멀티캐스트 그룹에 대한 다른 리소스를 생성할 필요가 없다. 또한, 이것은 netConfig 리소스가 재사용되는 것을 허용한다. 예를 들어, netConfig 리소스의 URI는 수 개의 SL group 리소스의 multicastIDs에서 찾을 수 있다.

단계 10에서, SL은 그룹에 속할 디바이스 식별자들을 제공하기 위해 기저 네트워크에 대한 그룹 업데이트 요청을 수행한다. 이전에, SL은 단계 1-6에서 그룹 생성 요청을 실행했다. 그룹 업데이트 요청은 group 리소스 생성 방법에 의해 제공되는 구성원들의 ID들을 포함하도록 그룹 생성 요청의 정보를 업데이트한다.

단계 11에서, 기저 네트워크는 SL에 그룹 업데이트 응답을 반환하고, 이는 SL이 멀티캐스트 메시지를 송신하기 위해 사용해야 하는 식별자들을 포함할 수 있다.

단계 12에서, SL은 그것의 처리의 결과에 기초하여 관리 애플리케이션에 응답을 송신한다.

단계 13에서, SL은 각각의 디바이스가 생성한 자기-가입에 기초하여 각각의 디바이스에게 멀티캐스트 그룹에 그것이 포함됨을 통지한다. 그룹의 각각의 구성원에 대해 하나씩, 복수의 통지가 송신될 수 있고, 통지들은 각각의 구성원에게 유니캐스트된다.

단계 14에서, 각각의 디바이스는 SL에 적절한 응답을 반환한다. 멀티캐스트 메시지들을 수신하는 것에 더 이상 관심이 없거나 그것들을 수신할 수 없는 디바이스는 응답에서 그와 같이 나타낼 수 있다. 이것이 발생하면, SL은 디바이스의 multicastCapable 속성이 디스에이블될 것을 보장해야 하고, 그에 의해 SL은 팬아웃 동작이 트리거될 때 디바이스 메시지에 대한 유니캐스트를 송신할 것이다.

netConfig 및 SL group 리소스들이 구성되고 나면, 그룹을 타겟팅하는 임의 SL 그룹 팬아웃 동작이 요청의 멀티캐스팅을 트리거할 수 있다. netConfig 리소스가 멀티캐스트를 실행하기 위한 네트워크 파라미터들만을 포함하는 한편, group 리소스는 멀티캐스트 메시지의 콘텐츠를 제공하므로, 이 관계는 중요하다. 이 메커니즘은 2개의 리소스의 보다 유연하고 독립적인 사용을 제공한다.

도 22는 기저 네트워크에의 SL 팬아웃 동작을 위한 예시적인 방법을 도시한다. 단계 0에서, 관리 애플리케이션, 서비스 계층, 기저 네트워크 및 디바이스 애플리케이션들은 서로 통신할 수 있도록 적절하게 부트스트랩되며, 이는 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차를 포함한다. 도 22의 예에서, 관리 애플리케이션은 멀티캐스트 시스템 및 디바이스의 동작들에 대한 지식을 가지고 있다. 이 경우의 기저 네트워크는 3GPP 네트워크이며, SL은 특히 SCEF와 통신한다

도 22의 단계 1 내지 14는 도 21의 단계 1 내지 14와 동일하다. 도 22의 이 시점에서, netConfig 및 group 리소스 둘 다가 생성되었다. 추가로, 그룹의 구성원들은 물론, 기저 네트워크도 통지를 받았다.

도 22를 다시 참조하면, 단계 15에서, 관리 애플리케이션은 group 리소스 상에서 팬아웃 동작을 실행한다.

단계 16에서, SL은 기저 네트워크에 대해 멀티캐스트 메시지를 포함하는 그룹 메시지 요청을 행한다. 이 메시지는 또한 외부 또는 내부 그룹 ID; TMGI; APN; 및 EBI를 포함한다.

단계 17에서, 기저 네트워크는 디바이스들에 메시지를 멀티캐스트하고, 디바이스들로부터 응답을 수신한다.

단계 18에서, 기저 네트워크는, 예를 들어 도 11의 단계 11을 참조하여 설명된 바와 같이, 요청이 전달에 대해 수락되었는지에 관한 그룹 메시지 확인(Group Message Confirm)을 반환한다. 여기서, 도 22에서, 응답은 멀티캐스트 메시지에 응답하지 않은 구성원들에 대한 표시들을 포함한다. 이러한 표시들은 예를 들어 구성원 ID, 및 멀티캐스트 메시지가 송신된 시간을 포함할 수 있다.

단계 19에서, 단계 18로부터의 응답이 모든 멤버가 멀티캐스트 요청에 응답한 것은 아님을 나타낸다. SL은 구성원 ID 및 멀티캐스트 메시지가 송신된 시간을 사용하고, 디바이스가 슬립 중이거나 오프라인인지를 검사할 수 있다. 만약 그렇다면, SL은 소정 시간 후에 응답에서 식별된 그룹 구성원(들)에게 멀티캐스트 메시지의 콘텐츠를 재송신하기로 결정할 수 있다. 대안적으로, SL은 응답하지 않은 모든 그룹 구성원에게 단순히 자동으로 재송신하기로 결정할 수 있다.

단계 20에서, 단계 19의 결과로서, SL은 멀티캐스트에 응답하지 않은 임의의 그룹 구성원들에게 멀티캐스트 메시지의 콘텐츠를 유니캐스트한다.

단계 21에서, 디바이스 애플리케이션은 적절한 응답을 SL에 송신한다.

단계 22에서, SL은 애플리케이션에 대한 응답을 송신한다. SL이 메시지를 멀티캐스팅 및/또는 유니캐스팅하는 것을 통해 그룹 구성원으로부터 응답을 수신하는 데에 성공하지 못한 경우, SL은 구성원 ID, 각각의 메시지가 송신된 시간들, 및 멀티캐스트 및 유니캐스트 주소를 보고할 수 있다. 프로토콜들, 및 SL이 응답을 기다린 시간과 같은 다른 정보가 포함될 수 있다. 멀티캐스트를 사용한 성공적이지 못한 시도가 있었던 경우, 관리 애플리케이션은 후속 요청에서 팬아웃 동작을 다시 트리거할 수 있지만, SL에게 그것이 기저 네트워크에서 멀티캐스트를 사용하기를 원하지 않음을 나타낼 수 있다. 그러한 경우에서, 방법은 단계 15 이후로 반복될 수 있지만, 단계 16 내지 19는 실행으로부터 생략될 수 있다.

멀티캐스트 동작의 일부로서, 개별 디바이스들은 요구되는 정보 또는 상태로 응답할 것이다. 그러나, 일부 디바이스들은 슬립 중일 수 있고, 멀티캐스트 메시지에 응답하지 않을 것이다. SL은 이러한 디바이스들의 슬립 상태의 지식을 가지므로, 이 정보를 사용하여 특정 디바이스로부터의 응답을 기다릴지를 결정할 수 있다. 이 경우, SL은 슬립 디바이스로부터의 응답을 기다리지 않고 논-슬립 디바이스들의 응답을 계속해서 수집할 수 있다.

도 4를 다시 참조하면, 기존 oneM2M CSF들은 능력들의 서비스 계층 자기-등록, 구성 리소스들, 멀티캐스트 그룹 생성, 동적 멀티캐스트 통지들, 및 서비스 계층 팬아웃을 통한 멀티캐스트의 트리거, 및 본 명세서에서 설명된 다른 방법들 및 장치들을 구현하도록 향상될 수 있다. 예를 들어, oneM2M 등록 CSF는 멀티캐스트 능력 표시자들의 등록을 용이하게 하도록 향상될 수 있다. oneM2M 가입 및 통지 CSF는 멀티캐스트 자기-가입 기능성 및 동적 멀티캐스트 통지 기능성을 용이하게 하도록 향상될 수 있다.

oneM2M 디바이스 관리 CSF는 멀티캐스트 기능성의 서비스 계층 구성을 위한 oneM2M <mgmtObj> 리소스로서 netConfig 리소스를 수용하도록 향상될 수 있다. 데이터 관리 및 리포지토리 CSF는 또한 netConfig 리소스 저장을 지원하도록 향상될 수 있다.

oneM2M 그룹 관리 CSF는 서비스 계층 그룹 생성 및 멀티캐스트 트리거 기능성을 제공하기 위해 향상될 수 있다. 네트워크 서비스 노출/서비스 확장 트리거(Network Service Exposure/Service Ex+Triggering) 및 기저 네트워크 서비스 엔티티(Underlying Network Service Entity)(NSE) CSF에도 동일하게 적용된다.

도 23은 ADN-AE가 oneM2M 시스템에서의 CSE 팬아웃 동작에서 멀티캐스트 능력들을 인에이블하기 위해 MN-CSE에 등록하는 예시적인 호출 흐름을 도시한다. 그러한 호출 흐름은 예를 들어 도 12에 도시된 예를 참조하여 설명된 각각의 태양 전지 패널의 등록에 사용될 수 있다. 여기서, 도 23에서, CSE는 예를 들어 IN, MN 또는 ASN CSE일 수 있는 한편, 디바이스 AE들은 MN, ASN 또는 ADN AE일 수 있다. 관리 AE는 예를 들어 IN, MN 또는 ASN AE일 수 있다.

도 23에서, <AE>는 등록 요청 내에 multicastCapable 속성을 제공한다. 이러한 사용 사례에 대해, 이 속성은 다른 관련있는 <AE> 속성들과 함께 표 6에 보여진다. multicastCapable 속성은 또한 표 7에 보여진 것과 같은 <node> 리소스의 부분으로서 추가될 수 있고, MN-CSE에게 멀티캐스트 그룹들을 생성하고 관리하는 능력을 제공한다. 추가로, pointOfAccess 및 requestReachability 속성 둘 다가 그에 따라 요청 내에 설정된다. pointOfAccess는 requestReachability와 함께 ADN-AE에게 멀티캐스트 그룹에 그것이 포함됨을 통보하기 위한 통지를 송신하기 위해 사용될 수 있다. 별개로, <AE>는 또한 self - subscription 속성을 갖는 <subscription> 리소스를 생성한다. 이 속성은 <subscription> 리소스의 notificationCriteria 속성 내에 eventType 및 eventTypeCategories로서 표현된다. 이 속성은 CSE가 <AE>에게 그것이 멀티캐스트 그룹에 포함될 때마다 통지하는 것을 허용한다.

단계 0에서, <AE> 및 CSE는 서로 통신할 수 있도록 적절하게 부트스트랩된다. 이는 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차를 포함한다. 단계 1에서, <AE>는 표 6에서 <AE> 리소스의 새로운 속성으로서 보여진 multicastCapable 속성을 갖는 등록 요청을 송신한다. 대안적으로, multicastCapable 속성은 표 7에 보여진 것과 같이 <node> 리소스에 추가될 수 있다. 단계 2에서, 등록 요청을 수신하면, CSE는 <AE>가 등록하도록 허용되는지를 확인하기 위해 인가 정책을 검사하고, 허용된다면 단계 3으로 이동하고 그렇지 않으면 단계 4로 이동한다.

단계 3에서, CSE는 <AE> 리소스를 생성하고, multicastCapable 속성을 설정한다. 단계 4에서, CSE는 등록 요청에 대한 적절한 응답을 송신한다. 단계 5에서, <AE>는 그것의 <AE> 리소스 하에서 <subscription>을 생성하고, 적절한 notificationURI를 갖는 self - subscription 속성을 포함한다. 이 경우, eventType = F 및 eventTypeCategories = 1이다. eventTypeCategories 정의들의 예들이 표 8에 보여진다. 단계 6에서, CSE는 <AE>의 액세스 제어 정책을 검사한다. 액세스가 허가된다면 단계 7로 이동하고, 그렇지 않으면 단계 8로 이동한다.

단계 7에서, CSE는 <subscription> 리소스를 생성하고, 표 9에 보여진 것과 같은 notificationCriteria 속성의 새롭게 정의된 eventType 및 eventTypeCategories로서 self-subscription 값을 포함한다. 단계 8에서, CSE는 <subscription> 생성의 적절한 응답을 <AE>에 송신한다.

<subscription> 리소스에서, CSE는 eventType을 표 9에 보여진 것과 같은 새로운 값 "F"로 설정한다. 이 이벤트 타입은 CSE가 가입자의 주의를 요구하는 CSE 내의 소정의 활동으로 인해 가입자에게 자발적 요청을 송신할 필요가 있을 때 사용된다. 예를 들어, CSE는 가입자에게 그것이 멀티캐스트 그룹의 일부임을 통보하거나, CSE는 액세스 제어에 대한 가입자의 승인을 필요로 한다. 이러한 자발적 요청은, 예를 들어 <group>이 생성될 때, 또는 제3자 애플리케이션이 가입자의 리소스에의 액세스를 얻기를 원할 때, CSE 내에서 다른 요청들에 의해 트리거된다.

eventType과 연관되는 것은, 가입이 어떤 이벤트들에 대한 통지를 트리거하는지를 설명하는 정책이다. 이 정책은 가입 생성자가 그것이 어떤 유형의 이벤트를 통지받기를 원하는지 지정하는 것을 허용한다. 정책은 표 8에 보여진 바와 같이 eventTypeCategories라고 지칭되는 <subscription> 리소스에의 새로운 속성을 추가함으로써 실현될 수 있다. 대안적으로, 정책은 [cmdhDefEcValue] 리소스의 requestContext 속성과 같은 CMDH 정책에 링크될 수 있다.

<AE> 및 <subscription> 리소스들이 성공적으로 생성된 후, ADN-AE는 디바이스의 슬립 상태들 및 임의의 공지된 이웃들의 MN-CSE 정보를 제공하기 위해 <node> 및 [areaNwkDeviceInfo] 리소스를 생성한다. AE를 [areaNwkDeviceInfo] 리소스에 연관시키기 위해, AE의 nodeLink 속성은 이 프로세스 동안 업데이트된다. 다른 태양 전지 패널들도 MN-CSE에 등록하기 위해 동일한 절차를 따른다.

전동 마운트들의 제어를 가능하게 하기 위해, 태양 전지 패널 ADN-AE는 2개의 디바이스 능력 관리 객체 [rotateCap] 및 [tiltCap]을 생성한다. 이러한 <mgmtObj> 리소스들은 각각 마운트들의 반경방향 회전 및 수직 경사를 제어한다. 각각의 태양 전지 패널은 특정 디바이스에 대한 모든 <mgmtObj> 리소스의 부모 리소스인 그것들의 연관된 <node> 리소스 하에서 이러한 리소스들을 생성할 것이다.

MN-CSE 내에서, [areaNwkInfo] 리소스는 CSE가 관리하는 영역 네트워크에 관한 정보를 제공하기 위해 배치 동안 구성되었다. 각각의 태양 전지 패널 ADN-AE가 성공적으로 등록되면, 이 네트워크에 연결된 모든 디바이스를 보여주기 위해 [areaNwkInfo] 리소스의 listOfDevices 속성이 업데이트된다. [areaNwkInfo]가 <mgmtObj> 리소스이므로, 그것은 동적으로, 또는 CSE 정책에 의해 결정되는 소정의 주기적 간격으로 업데이트될 수 있다. 나중에, 이 정보는 멀티캐스트 그룹을 생성할지를 결정하는 데 도움을 주기 위해 CSE에 의해 사용될 것이다.

태양 전지 패널 ADN-AE들이 서비스 계층에 등록하고, 리소스들이 생성되고 나면, CSE는 멀티캐스트 그룹들을 생성하기에 충분한 정보를 갖는다. 다음으로, 관리 AE는 모든 태양 전지 패널 ADN-AE들을 구성원들로서 갖는 4개의 <group> 리소스를 생성할 수 있고, 여기서 그룹들은 예를 들어 <rotateRight>, <rotateLeft>, <tiltUp> 및 <tiltDown>이다. "rotate*" 그룹들은 패널들을 수평으로 회전시키는 [rotateCap] 리소스를 타겟팅하는 한편, "tilt*" 그룹들은 패널들을 수직으로 기울이기 위한 [tiltCap] 리소스를 타겟팅한다.

각각의 group 리소스의 생성 시에, MN-CSE는 그룹의 모든 구성원을 식별하기 위해 memberIDs 속성을 검사한다. 다음으로, MN-CSE는 그것이 멀티캐스트를 지원함을 나타내기 위해 각각의 구성원이 multicastCapable 속성을 갖는지를 검사한다. 추가로, CSE는 각각의 구성원의 이웃들을 식별하기 위해 [areaNwkDeviceInfo] 리소스로부터 네트워크 파라미터들을 획득할 수 있다. 마지막으로, 그것은 멀티캐스트를 지원하는 모든 구성원을 포함하도록 자신이 생성한 멀티캐스트 그룹에 대한 [areaNwkInfo] 리소스 하에 멀티캐스트에 사용되는 [netConfig] 리소스를 생성한다.

CSE가 멀티캐스트 그룹을 생성하는 결정을 내리기 위해 사용할 수 있는 대안적인 방법은 각각의 ADN-AE의 로컬 네트워크 인터페이스에 연관된 [netConfig] 리소스를 사용하는 것이다. 이 방법에서, 각각의 ADN-AE의 defaultGateway 속성이 비교될 수 있으며, 그것들이 모두 일치하면, CSE는 그것들이 모두 동일한 게이트웨이에 의해 서비스되고 있다고 결론을 내릴 수 있다. 추가 검사로서, CSE는 [areaNwkDeviceInfo] 리소스에서 찾아진 각각의 ADN-AE의 이웃 목록 속성을 검증하여, 그것이 동일한 로컬 영역 네트워크 내에 있을 것을 보장할 수 있다.

[netConfig] 리소스는 CSE의 소정의 정책 또는 구성에 기초하는 멀티캐스트 IP 및 타겟 URI를 포함하고, 이것은 이 경우에서 모든 ADN-AE가 동일한 기능성들을 갖는 것과 동일하다. 다음으로, CSE는 <group> 리소스의 multicastIDs 속성을 [netConfig] 리소스의 URI로 업데이트한다. multicastIDs 속성을 위한 oneM2M 실시예가 표 10에 보여진다. [netConfig]와 <group> 리소스들 사이에 링크를 제공하는 것에 더하여, multicastIDs 속성은 관리 AE가 멀티캐스트 그룹이 생성되었는지를 확인하고, 어떤 멀티캐스트 주소가 사용되었는지를 찾는 것을 허용한다. 대안적으로, 관리 AE는 group 리소스를 생성하기 전에 [netConfig] 리소스를 명시적으로 생성할 수 있고, 각각의 <group> 리소스의 multicastIDs 속성에 [netConfig] URI를 제공할 수 있다.

멀티캐스트 및 CSE 그룹이 생성되고 나면, CSE는 자기-가입 메커니즘을 통해 그룹 내의 각각의 구성원에게 통지한다. 표 11은 CSE가 SCEF 또는 디바이스 애플리케이션들에게 송신할 수 있는 통지 메시지의 요소들을 보여준다. CSE는 [netConfig] 내의 네트워크 파라미터들, 및 CSE <group> 리소스로부터의 리소스 URI를 각각의 태양 전지 패널에 송신한다. 이 경우의 타겟 URI는 "/rotateRight"일 수 있으며, 이는 멀티캐스트 메시지에 나타난다. 이 경우에 대해, 리소스 URI는 또한 "/rotateRight"이다. 각각의 태양 전지 패널은 통지를 수신하고, URI들과 멀티캐스트 주소를 기록한다.

또한, 멀티캐스트는 CSE 대 CSE 통신을 위해 관리될 수 있다. 도 24는 MN-CSE가 multiCapable 속성을 갖는 IN-CSE 상의 <node> 리소스를 생성함으로써 IN-CSE에게 그것이 멀티캐스트 가능하다는 것을 통보하는 예시적인 호출 흐름을 도시한다. 다음으로, IN-AE는 MN-CSE에 의해 관리되는 복수의 구성원을 포함하는 <group> 리소스를 생성한다. 성공적인 <group> 생성의 IN-AE에 응답한 후, IN-CSE는 MN-CSE 상에서의 멀티캐스팅을 인에이블하기 위해 MN-CSE 상에 [netConfig] 및 <group> 리소스를 생성한다.

단계 0에서, IN-AE 및 CSE들은 서로 통신할 수 있도록 적절하게 부트스트랩되며, 이는 다른 것들 중에서도 특히 보안 프로비저닝, 서비스 발견, 및 등록 절차를 포함한다. 추가로, 적절한 [areaNwkInfo] 및 [areaNwkDeviceInfo] 리소스가 MN-CSE를 위해 생성된다. 추가로, IN-AE는 멀티캐스트 주소를 갖는 [netConfig] 리소스를 생성한다. 이 [netConfig] 리소스는 예를 들어 멀티캐스트 및 SL 그룹 생성의 동적 통지를 위한 것과 같이 복수의 원격 CSE에 대한 멀티캐스트 주소들을 구성하기 위해 사용될 수 있다.

단계 1에서, MN-CSE는 multicastCapable 속성을 갖는 <node> 생성 요청을 생성한다. 이는 IN-CSE에게, MN-CSE가 그것이 관리하는 디바이스들에 대한 멀티캐스트 동작들을 지원함을 통보한다. 단계 2에서, IN-CSE는 MN-CSE를 위한 <node> 리소스를 생성하고, multicastCapable 속성을 설정한다. 단계 3에서, IN-CSE는 <node> 생성 요청에 대한 적절한 응답을 송신한다. 단계 4에서, IN-AE는 MN-CSE에 의해 관리되는 구성원들을 포함하는 구성원 ID들을 갖는 <group> 리소스를 생성한다. IN-AE는 또한 단계 0에서 생성된 [netConfig] 리소스의 URI를 가리키는 multicastIDs 속성을 포함한다.

단계 5에서, IN-CSE는 <group> 리소스를 생성하고, 제공된 multicastIDs를 설정한다. 추가로, IN-CSE는 또한 MN-CSE가 멀티캐스트를 지원한다는 것을 인식하고, SL 멀티캐스트 그룹을 생성하기로 결정한다. 단계 6에서, IN-CSE는 IN-AE에 성공 응답을 반환한다. 대안적으로, IN-CSE는 단계 7-10을 완료할 때까지 이 응답의 송신을 지연시킬 수 있다.

단계 7에서, 다음으로, IN-CSE는 연관된 네트워크 파라미터들과 함께 MN-CSE 상에서 [netConfig] 리소스를 생성한다. 단계 8에서, MN-CSE는 [netConfig] 리소스의 URI를 포함하여 [netConfig] 생성에 대한 적절한 응답을 반환한다. 단계 9에서, IN-CSE는 또한 MN-CSE 상에 <group> 리소스를 생성하고, MN-CSE 상에서 로컬 [netConfig] 리소스의 URI로 multicastIDs 속성을 설정한다. memberIDs의 목록은 IN-CSE 상에서 생성된 <group> 리소스의 서브세트일 수도 있거나, 동일한 구성원들을 가질 수 있다.

단계 10에서, MN-CSE는 <group> 생성의 적절한 응답을 IN-CSE에 송신한다. 단계 11에서, 다음으로, IN-AE는 단계 5에서 생성된 <group> 리소스에 대한 팬아웃 동작을 실행한다. 단계 12에서, IN-CSE는 multicastIDs 속성을 통해 SL 멀티캐스트 그룹이 존재함을 인식하고, 팬아웃 동작을 MN-CSE에 재지향시킨다.

단계 13에서, IN-CSE는 MN-CSE 상의 <group> 리소스를 타겟팅하는 팬아웃 실행 요청을 MN-CSE에 송신한다. 이 절차는 현재 oneM2M에 존재하지만, 그것이 생성되는 방법의 컨텍스트는 새로운 것이다. 타겟 URI는 원래의 요청으로부터의 MN-CSE 상의 <group> 리소스의 URI로 전환되었다.

단계 14에서, MN-CSE는 자신이 관리하는 모든 구성원들에게 메시지를 멀티캐스트하고, 그들의 유니캐스트 응답을 집계한다. 소정의 이유로 인해 특정 구성원들이 응답을 반환하지 않은 경우, MN-CSE는 또한 응답을 얻기 위한 추가 시도로서 메시지를 유니캐스트할 수 있다. 단계 15에서, MN-CSE는 집계된 결과들과 함께 응답을 송신한다. 응답에서, 그것은 성공적이지 않은 경우들에 대한 추가의 정보, 예컨대 멀티캐스트 또는 유니캐스트 요청(또는 둘 다), 각각의 시도된 요청의 시간, 및 MN-CSE가 응답을 기다리는 시간의 길이를 제공할 수 있다. 단계 16에서, IN-CSE는 MN-CSE에 의해 제공된 응답을 IN-AE에 중계한다.

도 25는 oneM2M 팬아웃 동작이 복수의 멀티캐스트 그룹에의 팬아웃은 물론, 멀티캐스트 능력들을 지원하지 않는 구성원에게의 유니캐스트 요청을 사용하는 팬아웃을 야기하는 예시적인 호출 흐름을 도시한다. 이 경우에서의 <group> 리소스는 multicastIDs를 위한 2개의 엔트리를 포함하고, 그룹의 하나의 구성원은 멀티캐스트를 지원하지 않는다. 이 능력은 SL이 복수의 멀티캐스트 그룹의 조합은 물론, 유니캐스트 구성원들을 가질 수 있다는 점에서 표준 IP 멀티캐스트와 다르다.

단계 0에서, 모든 관련자가 프로비저닝되고, 따라서 서로 통신할 수 있다. 단계 1에서, SL 절차들은 멀티캐스트 그룹들을 생성하고, 모든 관련 당사자에게 통지하기 위해 사용된다. 예를 들어, 멀티캐스트 능력 표시자들은 SL 등록 요청들에서 사용될 수 있고, 서비스 계층 멀티캐스트 구성 리소스가 생성 및 유지관리될 수 있으며, 멀티캐스트 및 SL 그룹 생성에 관한 동적 통지들이 송신될 수 있고, 서비스 계층 팬아웃을 통해 멀티캐스트에 대한 트리거들이 성립될 수 있다. 도 25의 예에서, 2개의 멀티캐스트 그룹, 즉 하나의 3GPP 그룹, 및 전통적인 IP 멀티캐스트 그룹을 위한 두 번째 그룹이 생성된다. 추가로, 멀티캐스트를 지원하지 않는 <AE>도 존재한다. 예를 들어, 하나의 SL <group> 리소스에 의해 지정된 복수의 3GPP 및 IP 멀티캐스트 그룹과 같이 더 많은 멀티캐스트 그룹이 지원된다는 점에 유의해야 한다. 단계 2에서, 관리 <AE>는 단계 1에서 생성된 <group> 리소스의 fanOutPoint를 실행한다.

단계 3, 4, 및 5는 복수의 3GPP 및 IP 멀티캐스트 네트워크 상의 복수의 디바이스와 독립적으로 통신하고 병렬로 수행될 수 있다. 단계 3, 4, 및 5는 각각의 기저 네트워크에 대해 수행된다. 단계 3에서, 멀티캐스트 또는 유니캐스트 메시지가 CSE로부터 각각의 당사자들, 즉 SCEF/CN, IP 멀티캐스트 그룹 라우터 또는 원격 CSE, 및 디바이스 <AE>로 송신된다. 멀티캐스트 IP 주소는 [netConfig] 리소스로부터 획득된다. 단계 4에서, 멀티캐스트 또는 유니캐스트 메시지의 수신자들이 요청을 처리한다. 단계 5에서, 수신자들에 의해 적절한 응답이 CSE에게 다시 제공된다. 이것들은 유니캐스트 메시지들이다.

단계 6에서, CSE는 단계 5로부터의 응답들을 집계한다. 단계 7에서, CSE는 팬아웃 동작의 결과들의 적절한 응답을 <AE>에 송신한다.

유사한 기술들이 멀티캐스트가 아닌 기능들을 위해 적용될 수 있다. 예를 들어, ADN 노드가 제3자 애플리케이션에 의해 요청되는 소정의 관리 기능을 수행하기 위해 CSE로부터 통지를 얻기를 원할 때 자기-가입이 사용될 수 있다. 다른 예는 아래 설명된 바와 같이 액세스 제어에서 자기-가입을 사용하는 것이며, [netConfig] 리소스는 CSE 또는 디바이스의 네트워크 파라미터들을 구성하는 데 사용될 수 있다.

self - subscription은 제3자 애플리케이션들에 대한 액세스 제어를 허가하는 데 사용될 수 있다. 표 12는 AEID에 의해 이루어진 요청에 대한 액세스 제어를 허가하기 위해 CSE가 디바이스 애플리케이션에 송신하는 예시적인 통지 메시지의 요소들을 보여준다. 도 26은 AE2가 AE1으로부터의 리소스를 요청하고 있고, AE1의 리소스에 대한 액세스 제어를 이전에는 가지고 있지 않던 예시적인 호출 흐름을 보여준다. AE1이 self - subscription을 구성했기 때문에, CSE는 AE2에 대한 액세스 제어의 허가를 요청하기 위해, 그것에 자발적 통지를 송신할 수 있다. AE1은 응답하고, CSE가 자신의 리소스를 AE2에 송신하는 것을 허용한다.

도 26의 단계 0에서, AE1 및 AE2은 CSE와 통신할 수 있도록 적절하게 부트스트랩되고, 이는 다른 것들 중에서도 특히 보안 프로비저닝 및 서비스 발견 절차들을 포함한다. AE1 및 AE2 둘 다가 CSE에 등록된다. AE1은 또한 eventType = F 및 eventTypeCategories = 2로 CSE에의 self - subscription을 생성했다. 이 구성은 CSE에게, 임의의 제3자 AE가 액세스 권한들 없이 AE1의 리소스에 액세스하려고 시도하는 경우 AE1에 통지할 것을 통보한다.

단계 1에서, AE2는 AE1으로부터 리소스를 리트리브한다. 단계 2에서, CSE는 액세스 제어 정책을 검사하지만, AE2가 액세스 권한을 갖지 않음을 알아차린다. 액세스 제어 정책 검사의 일부로서, CSE는 AE1이 그러한 경우에 통지를 받도록 자기-가입을 구성했음을 인식한다. 결과적으로, CSE는 AE2 액세스를 거부하는 대신, 단계 3으로 계속된다.

단계 3에서, AE1이 self - subscription을 셋업한 이후로, CSE는 AE2가 액세스를 허가받을 것을 요청하는 통지를 AE1에 보낸다. 단계 4에서, AE1은 AE2에 대한 액세스를 허가하고 CSE에 응답한다. 단계 5에서, CSE는 리소스를 리트리브한다. 단계 6에서, CSE는 리소스의 콘텐츠를 AE2에 송신한다.

현장에서 호스팅되는 oneM2M MN-CSE는 그것이 통신하는 다수의 네트워크 인터페이스를 가질 수 있다. 인터넷에 상주하는 IN-CSE와 통신하기 위한 셀룰러 인터페이스, 그것이 관리하는 현장 노드들에 통신하기 위한 Wifi 인터페이스, 및 멀티캐스트 동작들을 위한 복수의 인터페이스가 존재할 수 있다. 도 27은 인터페이스들 각각에 대한 [netConfig] <mgmtObj> 리소스들을 갖는 MN-CSE를 위한 예시적인 oneM2M 리소스 트리를 보여준다. mnAE는 MN-CSE를 관리하고, 그것의 nodeLink 속성이 mnCseNode 리소스를 가리키게 하고, 여기서 MN-CSE에 대한 모든 네트워크 리소스가 상주한다. 대응하는 인터페이스들의 상이한 슬립 상태들을 설명하는 2개의 [areaNwkDeviceInfo] 리소스가 존재한다. 셀룰러 인터페이스에 대해, 슬립 상태는 월요일부터 금요일까지의 오전 7시에서 오후 7시까지이다. 다른 3개의 인터페이스에 대한 슬립 상태는 항상 켜져 있으며, 어떠한 슬립 상태도 인에이블되어 있지 않다.

MN-CSE가 관리하는 디바이스들 중 하나에 대한 리소스들이 또한 도시되어 있다. 리소스 mnAE1은 또한 노드 리소스 mnAE1Node 및 자식 [netConfig] 리소스를 가지며 - 예시적인 oneM2M 실시예가 표 14에 보여진다. [netConfig] 리소스는 MN-AE에 의해 DHCP, 사용자 구성, 또는 소정의 다른 방법을 통해, 그것이 수집한 네트워크 구성에 기초하여 생성된다. DHCP로부터의 새로운 IP 주소와 같이, 네트워크 파라미터들이 변경되면, MN-AE는 그에 따라 [netConfig] 리소스를 업데이트할 수 있다. mnAE1의 [netConfig] 리소스는 MN-CSE에게 그것과 통신하는 방법, 예를 들어 서비스 계층 구성 리소스를 지원하는 방법에 관한 정보를 제공할 수 있다. 구체적으로, protocolsSupported(CoAP) 및 mtu(최대 전송 유닛/메시지 크기) 속성들의 결합은 디바이스에 송신되는 적절한 블록 크기들을 사용하여 CoAP 메시지들을 적절하게 구성하기 위해 사용될 수 있다. 이는 MN-CSE가 mnAE1이 멀티캐스트를 지원함을 추론하기 위해 사용될 수 있는 정보에 추가된다.

도 28은 멀티캐스트 기능성을 실현하기 위한 애플리케이션에 대한 사용자 인터페이스의 예시적인 화면을 보여준다. 사용 사례는 원격 영역에서, 예를 들어 산을 따른 환경 센서들 AE1 내지 AE8의 현장 배치이다. 게이트웨이 디바이스는 메시지들을 센서들에 멀티캐스트하는 MN-CSE를 호스팅한다. 사용자 애플리케이션은 MN-CSE에 센서들의 근접성을 보여주고, 터치 인터페이스를 사용하여 멀티캐스트 그룹으로 그룹화할 센서들을 선택한다. 선택되면, 센서 위에 원이 놓이고, 선은 그것을 MN-CSE에 연결한다. 최상위에는 사용자가 사용할 내비게이션 및 액션 버튼들이 있다. 뒤로가기 버튼은 애플리케이션을 홈 화면으로 다시 내비게이션한다. 구성 버튼은 사용자가 멀티캐스트 메시지에 포함시키기 위해 네트워크 파라미터들 및 콘텐츠를 조정하는 것을 허용할 수 있다. 구성 버튼을 누르면, 사용자가 멀티캐스트 메시지의 멀티캐스트 주소 및 콘텐츠를 구성하는 것을 허용하는 다른 화면(도시되지 않음)이 나타난다. 송신 버튼은 사용자가 구성 버튼에 연관된 화면에서 제공한 정보에 따라 멀티캐스트 메시지의 송신을 활성화한다.

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

도 29는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 머신 대 머신(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 구축 블록들을 제공하며, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트 또는 노드는 물론 IoT/WoT 서비스 계층 등일 수 있다. 도 3-9, 11-13, 15, 16, 18, 19 및 21-28 중 임의의 것에 도시된 클라이언트, 프록시, 또는 서버 디바이스들 중 임의의 것은 도 2, 4, 및 14에 도시된 것들과 같은 통신 시스템의 노드를 포함할 수 있다.

도 29에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예를 들어, 이더넷, 광섬유, ISDN, PLC 등), 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등), 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 사용자에게 제공하는 복수의 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 코드 분할 다중 액세스(CDMA), 시분할 다중 액세스(TDMA), 주파수 분할 다중 액세스(FDMA), 직교 FDMA(OFDMA), 싱글 캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 이용할 수 있다. 또한, 통신 네트워크(12)는 예를 들어 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크, 개인 영역 네트워크, 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 29에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 기반구조 도메인 및 필드 도메인을 포함할 수 있다. 기반구조 도메인은 단-대-단 M2M 배치의 네트워크 측을 지칭하고, 필드 도메인은 통상적으로 M2M 게이트웨이 배후에 있는 영역 네트워크들을 지칭한다. 필드 도메인 및 기반구조 도메인 둘 다는 네트워크의 다양한 상이한 노드들(예를 들어, 서버들, 게이트웨이들, 디바이스 등)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 디바이스들(18)을 포함할 수 있다. 임의의 수의 M2M 게이트웨이 디바이스들(14) 및 M2M 디바이스들(18)은 요구되는 대로 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있음을 알 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 디바이스들(18) 각각은 통신 회로를 이용하여, 통신 네트워크(12) 또는 직접적인 무선 링크를 통해 신호들을 송신 및 수신하도록 구성된다. M2M 게이트웨이(14)는 무선 M2M 디바이스들(예를 들어, 셀룰러 및 비-셀룰러)은 물론, 고정 네트워크 M2M 디바이스들(예를 들어, PLC)이 통신 네트워크(12) 또는 직접 무선 링크와 같은 운영자 네트워크를 통해 통신하는 것을 허용한다. 예를 들어, M2M 디바이스들(18)은 데이터를 수집하고, 통신 네트워크(12) 또는 직접적인 무선 링크를 통해 M2M 애플리케이션(20) 또는 다른 M2M 디바이스들(18)에 데이터를 송신할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하에 설명되는 바와 같이 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 송신되고 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비, 6LoWPAN, 블루투스), 직접 무선 링크 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스들은 태블릿, 스마트 폰, 의료 디바이스, 온도 및 날씨 모니터, 커넥티드 카, 스마트 미터, 게임 콘솔, 개인용 정보 단말, 헬스 및 피트니스 모니터, 조명, 서모스탯, 가전 제품, 차고 문 및 다른 액추에이터 기반 디바이스, 보안 장치 및 스마트 콘센트를 포함하지만, 그에 제한되지 않는다.

도 30을 참조하면, 필드 도메인 내의 도시된 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')은 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예를 들어, 클라우드 컴퓨팅/스토리지 팜 등) 등을 포함할 수 있는 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.

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

M2M 애플리케이션들(20 및 20')은 운송, 헬스 및 웰니스, 커넥티드 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은, 그러나 그에 제한되지는 않는 다양한 산업 분야의 애플리케이션들을 포함할 수 있다. 위에서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들, 및 다른 노드들에 걸쳐 운영되는 M2M 서비스 계층은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능들을 지원하고, 이러한 기능들을 M2M 애플리케이션들(20 및 20')에 대한 서비스들로서 제공한다.

일반적으로, 도 29 및 도 30에 도시된 서비스 계층들(22 및 22')과 같은 서비스 계층은 애플리케이션 프로그래밍 인터페이스들(API) 및 기저 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M 및 oneM2M 아키텍처 둘 다는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 서비스 능력 계층(SCL)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양한 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스[디바이스 SCL(DSCL)이라고 지칭됨], 게이트웨이[게이트웨이 SCL(GSCL)이라고 지칭됨], 및/또는 네트워크 노드[네트워크 SCL(NSCL)이라고 지칭됨] 내에서 구현될 수 있다. oneM2M 서비스 계층은 공통 서비스 기능들(CSF)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 기반구조 노드, 중간 노드, 애플리케이션-특정 노드)에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)로 지칭된다. 3세대 파트너쉽 프로젝트(3GPP)는 또한 머신 유형 통신(MTC)을 위한 아키텍처를 정의했다. 그러한 아키텍처에서, 서비스 계층, 및 그것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL 또는 NSCL에서 구현되는지, 3GPP MTC 아키텍처의 서비스 능력 서버(SCS)에서 구현되는지, oneM2M 아키텍처의 CSF 또는 CSE에서 구현되는지, 또는 네트워크의 소정의 다른 노드에서 구현되는지에 무관하게, 서비스 계층의 인스턴스는 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는 네트워크 내의 하나 이상의 독립형 노드 상에서, 또는 하나 이상의 기존 노드의 일부로서 실행되는 논리적 엔티티(예를 들어, 소프트웨어, 컴퓨터 실행가능 명령어들 등)로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 컴포넌트의 인스턴스는 이하에 설명되는 도 31 또는 도 32에 도시된 일반적인 아키텍처를 갖는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등)에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

또한, 본 명세서에 설명된 방법들 및 기능성들은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 31은 도 29 및 도 30에 도시된 것과 같은 M2M 네트워크 내에서 M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드로서 동작할 수 있는, 도 3-9, 11-13, 15, 16, 18, 19, 및 21-28에 도시된 클라이언트들, 서버들, 또는 프록시들 중 하나와 같은 네트워크의 노드의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 31에 도시된 바와 같이, 노드(30)는 프로세서(32), 고정식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 전지구적 측위 시스템(global positioning system)(GPS) 칩셋(50), 및 다른 주변장치들(52)을 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 송신/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 노드(30)는 실시예와의 일관성을 유지하면서, 상술한 요소들의 임의의 서브컴비네이션(sub-combination)을 포함할 수 있다는 것을 알아야 한다. 이 노드는 본 명세서에 설명된 엔드-투-엔드 인증 기능성의 양태들을 구현하는 노드일 수 있다.

프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어에 연관된 하나 이상의 마이크로프로세서, 제어기, 응용 특정 집적 회로(ASIC: Application Specific Integrated Circuits), 필드 프로그래머빌 게이트 어레이(FPGA: Field Programmable Gate Array) 회로, 임의의 다른 유형의 집적 회로(IC), 상태 머신(state machine) 등일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 요구된 기능들을 수행하기 위해 노드의 메모리[예를 들어, 메모리(44) 및/또는 메모리(46)]에 저장된 컴퓨터 실행가능한 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 노드(30)가 무선 또는 유선 환경에서 동작할 수 있게 하는 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 애플리케이션 계층 프로그램들(예를 들어, 브라우저들) 및/또는 무선 액세스 계층(RAN: radio access-layer) 프로그램 및/또는 다른 통신 프로그램을 실행할 수 있다. 또한, 프로세서(32)는 예를 들어 액세스 계층 및/또는 애플리케이션 계층에서와 같이, 인증, 보안 키 협의, 및/또는 암호 연산들과 같은 보안 동작들을 수행할 수 있다.

도 31에 도시된 바와 같이, 프로세서(32)는 자신의 통신 회로[예컨대, 송수신기(34) 및 송신/수신 요소(36)]에 연결된다. 프로세서(32)는 컴퓨터 실행가능한 명령어들의 실행을 통해, 노드(30)가 자신이 접속된 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 구체적으로, 프로세서(32)는 본 명세서(예를 들어, 도 3-9, 11-13, 15, 16, 18, 19 및 21-28) 및 청구항들에 설명된 송신 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 31은 프로세서(32) 및 송수신기(34)를 별개의 컴포넌트들로서 도시하지만, 프로세서(32) 및 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있음을 알 것이다.

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

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

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

프로세서(32)는 고정식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터 정보에 액세스하고 그러한 메모리에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 위에서 설명된 바와 같이 세션 컨텍스트를 그것의 메모리 내에 저장할 수 있다. 고정식 메모리(44)는 랜덤 액세스 메모리(RAM: random-access memory), 판독 전용 메모리(ROM: read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 가입자 신원 모듈(SIM) 카드, 메모리 스틱, 보안 디지털(SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터와 같이 노드(30) 상에 물리적으로 위치하지 않는 메모리로부터 정보에 액세스하고 그러한 메모리에 데이터를 저장할 수 있다. 프로세서(32)는 M2M 서비스 계층 세션 마이그레이션 또는 공유의 상태를 반영하거나, 노드의 세션 마이그레이션 또는 공유 능력들 또는 세팅들에 관해 사용자로부터 입력을 획득하거나 사용자에게 정보를 디스플레이하기 위해, 디스플레이 또는 인디케이터들(42) 상의 조명 패턴들, 이미지들, 또는 색상들을 제어하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관하여 정보를 보여줄 수 있다.

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

프로세서(32)는 또한 노드(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된 GPS 칩셋(50)에 연결될 수 있다. 노드(30)는 실시예와의 일관성을 유지하면서, 임의의 적절한 위치 결정 방법을 통해 위치 정보를 취득할 수 있다.

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

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

도 32는 도 29 및 도 30에 도시된 것과 같은 M2M 네트워크 내에서 M2M 서버, 게이트웨이, 디바이스 또는 다른 노드로서 동작할 수 있는, 도 3-9, 11-13, 15, 16, 18, 19, 및 21-28에 도시된 클라이언트들, 서버들, 또는 프록시들과 같은 네트워크의 하나 이상의 노드를 구현하기 위해 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 소프트웨어가 저장 또는 액세스되는 모든 장소에서, 또는 소프트웨어가 저장 또는 액세스되는 모든 수단에 의해, 그러한 소프트웨어 형태로 되어 있을 수 있는 컴퓨터 판독가능한 명령어들에 의해 주로 제어될 수 있다. 그러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)이 작업을 수행하도록 하기 위해, 중앙 처리 장치(CPU)(91)와 같은 프로세서 내에서 실행될 수 있다. 다수의 공지된 워크스테이션, 서버, 및 개인용 컴퓨터에서, 중앙 처리 장치(91)는 마이크로프로세서라고 지칭되는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서를 포함할 수 있다. 코프로세서(81)는 추가의 기능들을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와 구별되는 임의적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 세션 자격증명들을 수신하는 것, 또는 세션 자격증명들에 기초하여 인증하는 것과 같은 E2E M2M 서비스 계층 세션들에 대해 개시된 시스템들 및 방법들에 관련된 데이터를 수신하고 발생하고 처리할 수 있다.

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

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

추가로, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변장치들에 명령어들을 전달하는 것을 책임지는 주변장치 제어기(83)를 포함할 수 있다.

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

또한, 컴퓨팅 시스템(90)은 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하기 위해 컴퓨팅 시스템(90)을 도 29 및 도 30의 네트워크(12)와 같은 외부 통신 네트워크에 접속하는 데 사용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다. 통신 회로는 단독으로, 또는 CPU(91)와 함께, 본 명세서, 예를 들어, 도 3-9, 11-13, 15, 16, 18, 19 및 21-28 및 청구항에 설명된 전송 및 수신 단계들을 수행하기 위해 이용될 수 있다.

본 명세서에서, 도 3-9, 11-13, 15, 16, 18, 19, 및 21-28, 그것의 설명들, 및 청구항들은 엔드-투-엔드 인증 기능성을 인에이블하기 위한 방법들 및 장치들의 다양한 실시예들을 도시한다. 이러한 도면들에서, 다양한 단계들 또는 동작들은 하나 이상의 클라이언트, 서버 및/또는 프록시에 의해 수행되는 것으로 도시된다. 이러한 도면들에 도시된 클라이언트들, 서버들, 및 프록시들은 통신 네트워크 내의 논리적 엔티티들을 표현할 수 있고, 본 명세서에 설명된 것과 같은 도 29 또는 도 30에 도시된 일반적 아키텍처들 중 하나를 포함할 수 있는 그러한 네트워크의 노드의 메모리 내에 저장되고 그것의 프로세서 상에서 실행되는 소프트웨어, 즉 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있다. 즉, 도 3-9, 11-13, 15, 16, 18, 19 및 21-28, 및 청구항들에 보여진 방법들은 예를 들어 도 31 또는 도 32에 도시된 노드 또는 컴퓨터 시스템과 같은 네트워크 노드의 메모리에 저장된 소프트웨어, 즉 컴퓨터 실행가능한 명령어들의 형태로 구현될 수 있으며, 그 컴퓨터 실행가능한 명령어들은 노드의 프로세서에 의해 실행될 때 도면들에 도시된 단계들을 수행한다. 또한, 이러한 도면들에 도시된 임의의 전송 및 수신 단계는 노드의 프로세서의 제어 하에 있는 노드의 통신 회로[예를 들어, 각각 도 31 및 도 32의 회로(34 또는 97)], 및 그것이 실행하는 컴퓨터 실행가능한 명령어들(소프트웨어)에 의해 수행될 수 있음을 이해해야 한다.

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

이러한 서술된 설명은 예들을 사용하여 최선의 모드를 포함하는 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제작 및 사용하고 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시할 수 있게 한다. 본 발명의 특허가능한 범위는 청구항들에 의해 정의되며, 본 기술분야의 통상의 기술자에게 떠오를 수 있는 다른 예들을 포함할 수 있다. 그러한 다른 예들은 그것들이 청구항들의 문자 언어와 다른 요소들을 갖는 경우 또는 청구항들의 문자 언어와 사소한 차이를 갖는 등가의 요소들을 포함하는 경우, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

1. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
   상기 장치는 자신의 통신 회로를 통해 통신 네트워크에 접속되고, 상기 장치는 상기 장치의 메모리 내에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 컴퓨터 실행가능한 명령어들은 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금:
   a. 서비스 계층 엔티티를 제공하고;
   b. 복수의 엔티티에 의해 제공되는 멀티캐스트 능력들의 표시들을 수신하고;
   c. 멀티캐스트 구성을 위해 하나 이상의 서비스 계층 리소스를 유지관리하고;
   d. 상기 복수의 엔티티 중에서 구성원들을 선택함으로써 - 상기 선택은 상기 멀티캐스트 능력들의 표시들에 적어도 부분적으로 기초함 - 서비스 계층 그룹을 생성하게 하는, 장치.
2. 제1항에 있어서,
   a. 상기 멀티캐스트 능력들의 표시들은 IP 멀티캐스트 능력 또는 3GPP 멀티캐스트 능력의 표시들을 포함하고;
   b. 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 멀티캐스트 구성을 위해 상기 하나 이상의 서비스 계층 리소스에 IP 멀티캐스트 능력 또는 3GPP 멀티캐스트 능력의 표시들을 저장하게 하는, 장치.
3. 제2항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 상기 서비스 계층 그룹 내에 2 이상의 멀티캐스트 그룹을 포함하게 하고, 상기 멀티캐스트 그룹들은 개별적으로,
   a. 공통 기저 네트워크에 상주하는 구성원들의 세트; 또는
   b. 공통 멀티캐스트 기술을 사용하는 구성원들의 세트 - 상기 공통 멀티캐스트 기술은 IP 멀티캐스트 또는 3GPP 멀티캐스트임 -
   를 포함하는, 장치.
4. 제2항에 있어서,
   a. 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 영역 네트워크 정보 또는 영역 네트워크 디바이스 정보를 제공하는 리소스들에 기초한 상기 멀티캐스트 구성을 위해 상기 서비스 계층 리소스들 중 하나 이상을 유지관리하게 하고;
   b. 영역 네트워크 정보 또는 영역 네트워크 디바이스 정보를 제공하는 리소스들에 기초한 상기 멀티캐스트 구성을 위한 상기 서비스 계층 리소스들 중 하나 이상은 IP 멀티캐스트 능력 또는 3GPP 멀티캐스트 능력의 표시들을 포함하는, 장치.
5. 제1항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 상기 서비스 계층 그룹에 합류하기 위한 제1 엔티티에 의한 요청에 기초하여 상기 서비스 계층 그룹 내에 상기 제1 엔티티를 포함시키게 하는, 장치.
6. 제1항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 상기 서비스 계층 그룹 내에 제1 엔티티를 포함시키기 위한 관리 애플리케이션으로부터의 요청에 기초하여 상기 서비스 계층 그룹 내에 상기 제1 엔티티를 포함시키게 하는, 장치.
7. 제1항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금:
   a. 상기 복수의 엔티티에 의해 제공된 멀티캐스트 능력들의 표시들을 분석하고;
   b. 상기 분석에 기초하여 상기 서비스 계층 그룹의 생성을 개시하게
   하는, 장치.
8. 제1항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금:
   a. 자기-가입 정보(self-subscription information)를 수신하고 - 상기 자기-가입 정보는 자기-가입 엔티티에 관한 것이며, 상기 자기-가입 정보는 가입을 허용하고, 그에 의해 상기 서비스 계층 엔티티는 자발적 요청들(unsolicited requests)을 상기 자기-가입 엔티티에 송신할 수 있음 -;
   b. 자발적 요청을 상기 자기-가입 엔티티에 송신하게 하는, 장치.
9. 제7항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 상기 자기-가입 엔티티로부터 상기 자기-가입 정보를 수신하게 하는, 장치.
10. 제7항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 관리 애플리케이션으로부터 상기 자기-가입 정보를 수신하게 하는, 장치.
11. 제7항에 있어서, 상기 자기-가입 정보는 상기 자발적 요청을 송신하기 위한 조건들을 포함하는, 장치.
12. 제7항에 있어서, 상기 자발적 요청을 송신하기 위한 조건들은 하나 이상의 자발적 요청들이 송신될 수 있을 때의 스케줄을 포함하는, 장치.
13. 제7항에 있어서, 상기 자발적 요청을 송신하기 위한 조건들은 하나 이상의 종류의 자발적 요청을 송신하기 위한 목적으로 주어진 유니폼 리소스 식별자를 사용하라는 지시를 포함하는, 장치.
14. 제1항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 팬아웃 동안 유니캐스트 메시지를 상기 서비스 계층 그룹의 제1 구성원에게 송신하게 하고, 상기 서비스 계층 그룹의 상기 제1 구성원은 멀티캐스트 능력을 갖지 않고, 상기 유니캐스트 메시지는 상기 멀티캐스트 메시지의 콘텐츠를 포함하는, 장치.
15. 제1항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 팬아웃 동안 유니캐스트 메시지를 상기 서비스 계층 그룹의 제1 구성원에게 송신하게 하고, 상기 제1 구성원은 이전에 송신된 멀티캐스트 메시지의 확인응답을 송신하는 데 실패한, 장치.
16. 프로세서, 메모리, 및 통신 회로를 포함하는 장치로서,
    상기 장치는 자신의 통신 회로를 통해 통신 네트워크에 접속되고, 상기 장치는 상기 장치의 메모리 내에 저장된 컴퓨터 실행가능한 명령어들을 더 포함하며, 상기 컴퓨터 실행가능한 명령어들은 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금:
    a. 서비스 계층 엔티티를 제공하고;
    b. 자기-가입 정보를 수신하고 - 상기 자기-가입 정보는 상기 서비스 계층 엔티티에 제공되고 자기-가입 엔티티에 관한 것이며, 상기 자기-가입 정보는 가입을 허용하며, 그에 의해 서비스 계층은 상기 자기-가입 엔티티에 자발적 요청을 송신할 수 있음 - ;
    c. 상기 자발적 요청을 상기 자기-가입 엔티티에 송신하게 하는, 장치.
17. 제16항에 있어서, 상기 자발적 요청은 제3자 애플리케이션이 상기 자기-가입 엔티티의 리소스에 액세스하는 것을 허용하기 위한 요청을 포함하는, 장치.
18. 제16항에 있어서, 상기 자발적 요청은 상기 자기-가입 엔티티에게 제3자 애플리케이션에 의해 요청된 관리 기능을 수행하라는 요청을 포함하는, 장치.
19. 제16항에 있어서, 상기 컴퓨터 실행가능한 명령어들은 추가로 상기 장치로 하여금 상기 자기-가입 엔티티로부터 또는 관리 애플리케이션으로부터 상기 자기-가입 정보를 수신하게 하는, 장치.
20. 제16항에 있어서, 상기 자기-가입 정보는,
    a. 하나 이상의 자발적 요청이 송신될 수 있을 때의 스케줄; 또는
    b. 하나 이상의 종류의 자발적 요청을 송신할 목적으로 주어진 유니폼 리소스 식별자를 사용하라는 지시
    를 포함하는, 장치.

Images