KR101985118B1 - 서비스 레이어에서 협상 서비스를 지원하기 위한 방법 - Google Patents

Abstract

본 출원은 서비스 레이어 속성들을 협상하기 위한 컴퓨터 구현 장치에 관한 것이다. 이러한 장치는 서비스 속성들을 협상하기 위해 협상 서비스 레이어에 대해 저장되어 있는 명령어들을 포함하는 비-일시적 메모리를 포함한다. 이러한 장치는 비-일시적 메모리에 동작가능하게 연결되는 프로세서를 또한 포함한다. 프로세서는 피-협상자로부터 수신되는 협상가능 서비스 레이어 속성을 검토하라는 명령어를 수행하도록 구성된다. 프로세서는 검토된 속성에 기초하여 피-협상자에게 협상 요청을 송신하라는 명령어를 수행하도록 또한 구성된다. 프로세서는 피-협상자로부터 제출된 제안을 수신하라는 명령어를 수행하도록 또한 구성된다. 본 출원의 다른 양상은 서비스 레이어 속성들을 협상하기 위해 컴퓨터 구현 피-협상자 및 컴퓨터 구현 협상자를 포함하는 네트워크형 시스템에 관한 것이다.

Description

서비스 레이어에서 협상 서비스를 지원하기 위한 방법{METHOD FOR SUPPORTING NEGOTIATION SERVICE AT A SERVICE LAYER}

관련 출원에 대한 상호 참조

본 출원은 2014년 12월 1일 출원된 미국 임시 출원 제62/086,102호에 대한 우선권을 주장하며, 그 개시 내용은 그 전부가 본 명세서에 참조로 원용된다.

배경기술

M2M(machine-to-machine) 기술들은 디바이스들이 유선 및 무선 통신 시스템들을 사용하여 서로 보다 직접적으로 통신하게 한다. M2M 기술들은, 고유하게 식별가능한 오브젝트들, 및 인터넷과 같은 네트워크를 통해 그리고 서로 통신하는 이러한 오브젝트들의 가상 표현들의 시스템인 IoT(Internet of Things)의 추가 실현을 가능하게 한다. IoT는, 심지어, 식료품 상점에서의 제품들 또는 가정에서의 가전제품들과 같은, 일상적인 매일의 오브젝트들과의 통신을 촉진할 수 있고, 이에 의하면 이러한 오브젝트들의 지식을 향상시키는 것에 의해 비용과 낭비를 절감할 수 있다. 예를 들어, 상점들은 재고에 있을 수 있거나 판매되었을 수도 있는 오브젝트들과 통신할 수 있거나 이들로부터 데이터를 획득할 수 있는 것에 의해 매우 정확한 재고 데이터를 유지할 수 있다.

M2M 서비스 노드들 및 애플리케이션들은 M2M 서비스 레이어로부터의 서비스들을 제공/액세스하기 위해 정적 구성들 또는 사전 프로비저닝에 현재 의존한다. 즉, 상이한 시간에 구체적인 서비스의 다양한 특징들 또는 기능들을 동적으로 요청하기 위한 비효율적인 지원이 존재한다. 예를 들어, 기존 oneM2M은 MN(middle node) CSE(common service entity)가 IN(infrastructure node)-CSE로부터 스토리지를 동적으로 요청하는 메커니즘들을 제공하지 않는다. 또한, IN-CSE는 IN-AE(application entity)가 관리할 수 있는 디바이스들의 수 및/또는 IN-AE가 얼마나 자주 IN-CSE에 요청들을 발행할 수 있는지를 관리하는 서비스를 갖지 않는다.

정적 구성들은 처리량에 직접적으로 영향을 미친다. 즉, M2M 애플리케이션에 서비스들을 제공함에 있어서 M2M 서버의 유연성이 매우 제한된다. 따라서, 미리 구성된 서비스들이 M2M 서버 및/또는 M2M 디바이스에 대해 최적의 선택이 아닐 수 있다. 예를 들어, 요구되는 서비스들이 요건 변경 또는 컨텍스트 변경으로 인해 변경될 수 있다, 예를 들어, M2M 서버는 등록된 디바이스들을 더 많이 갖거나 M2M 디바이스는 통신 제약들이 더 많은 새로운 위치로 이동한다.

본 내용은 아래 상세한 설명에서 추가로 설명되는 개념들의 선택을 단순화된 형태로 소개하도록 제공된다. 이러한 내용은 청구된 주제의 범위를 제한하려고 의도되는 것이 아니다. 전술한 요구들은, M2M 서비스 레이어에서 협상 서비스들을 향상시키고 서비스들을 동적으로 요청하기 위한 능력들을 제공하기 위한 프로세스 및 시스템에 관한 본 출원에 의해 크게 충족된다.

본 출원의 일 양상에서는, 컴퓨터 구현 방법이 설명된다. 본 방법은 피-협상자로부터 수신되는 협상 가능 서비스 레이어 속성을 검토하는 단계를 포함한다. 본 방법은 검토된 속성에 기초하여 협상 요청을 피-협상자에게 전송하는 단계를 또한 포함한다. 본 방법은 제출된 제안을 피-협상자로부터 수신하는 단계를 또한 포함한다. 일 실시예에서, 본 방법은 미리 결정된 협상 정책들 점검시 제출된 제안을 선택하는 단계를 포함한다. 다른 실시예에서, 본 방법은 수신되는 제출된 제안이 피-협상자의 미리 결정된 협상 정책들에 대해 점검되는 단계를 포함한다. 다른 실시예에서, 협상 요청이 서비스 id, 제안들을 행하기 위한 입력, 제출된 제안들 및 이들의 조합으로부터 선택되는 정보를 포함하는 단계를 포함한다. 다른 실시예에 따르면, 제출된 제안은 제안, 다른 피-협상자와 협상하라는 추천, 및 이들의 조합으로부터 선택되는 정보를 포함한다. 다른 실시예에 따르면, 협상 요청을 전송하는 단계는 브로커를 통해 피-협상자에게 전송된다. 다른 실시예에 따르면, 제출된 제안을 수신하는 단계는 브로커를 통해 피-협상자로부터 수신된다.

본 출원의 다른 양상에서는, 피-협상자로부터 협상 가능 서비스 레이어 속성을 협상하기 위한 정책을 수신하는 단계를 포함하는 컴퓨터 구현 방법이 설명된다. 본 방법은 협상자로부터 속성을 협상하라는 요청을 수신하는 단계를 또한 포함한다. 본 방법은 요청이 피-협상자 정책의 미리 결정된 기준을 준수하는지 결정하는 단계를 또한 포함한다. 또한, 본 방법은 제출된 제안을 협상자에게 전송하는 단계를 포함한다. 일 실시예에서, 본 방법은 협상자로부터 협상 확인을 수신하고 피-협상자에게 협상 확인의 수신확인을 전송하는 단계를 포함한다.

본 출원의 또 다른 양상에서는, 협상 가능 서비스 레이어 속성에 대한 협상 요청을 협상자로부터 수신하는 단계를 포함하는 컴퓨터 구현 방법이 설명된다. 본 방법은 이러한 속성을 갖는 피-협상자의 위치를 찾아내는 단계를 또한 포함한다. 본 방법은 협상 요청을 피-협상자에게 전송하는 단계를 또한 포함한다. 또한, 본 방법은 피-협상자로부터 협상 가능 서비스에 대해 제출된 제안을 수신하는 단계를 포함한다. 실시예에 따르면, 본 방법은 제출된 제안을 협상자에게 전송하고, 협상자로부터 협상 확인을 수신하고, 피-협상자에게 협상 확인의 수신확인을 전송하는 단계를 포함한다.

다른 양상에 따르면, 컴퓨터 구현 장치가 개시된다. 이러한 장치는 서비스 속성을 협상하기 위해 명령어들을 저장하고 있는 협상 서비스 레이어를 포함하는 비-일시적 메모리를 포함한다. 이러한 장치는 비-일시적 메모리에 동작가능하게 연결되는 프로세서를 또한 포함한다. 프로세서는 피-협상자로부터 수신되는 속성을 검토하라는 명령어를 수행하도록 구성된다. 프로세서는 검토된 속성에 기초하여 협상 요청을 피-협상자에게 전송하도록 또한 구성된다. 실시예에 따르면, 프로세서는 피-협상자로부터 제출된 제안을 수신하라는 명령어들을 수행하도록 추가로 구성된다. 일 실시예에서, 이러한 컴퓨터 구현 장치는 비-일시적 메모리 및 프로세서에 동작가능하게 연결되는 사용자 인터페이스를 갖는 디스플레이를 포함한다.

본 출원의 또 다른 양상에서는, 서비스 속성의 협상을 위해 명령어들을 저장하고 있는 협상 서비스 레이어를 포함하는 비-일시적 메모리를 갖는 컴퓨터 구현 장치가 설명된다. 이러한 장치는 비-일시적 메모리에 동작가능하게 연결되고, (ⅰ) 피-협상자로부터 속성을 협상하기 위한 정책을 수신하는 단계; (ⅱ) 협상자로부터 속성을 협상하라는 요청을 수신하는 단계; 및 (iii) 이러한 요청이 피-협상자 정책의 기준을 준수하는지 결정하는 단계의 명령어들을 수행하도록 구성되는 프로세서를 또한 포함한다. 일 실시예에 따르면, 프로세서는 제출된 제안을 협상자에게 전송하라는 명령어들을 수행하도록 추가로 구성된다. 일 실시예에서, 비-일시적 메모리는 공통 속성들, 생성, 검색, 삭제, 업데이트, 실행, 레이블, 브로커, 타입, 제안을 행하기 위한 입력들, 제안을 선택하기 위한 입력들, 시작, 상태, 타겟, 참조, 제출된 제안들, 선택된 제안들, 출력 파라미터들, 가입 및 이들의 조합으로부터 선택되는 협상 리소스를 저장한다. 다른 실시예에서, 프로세서는 이러한 협상 리소스를 사용하여 속성을 협상한다. 다른 실시예에서, 메모리는 공통 속성들, 레이블, 협상 타입, 협상자, 피-협상자, 조건, 결과, 선택 규칙, 가입 및 이들의 조합으로부터 선택되는 정책 리소스를 저장한다. 다른 실시예에서, 프로세서는 이러한 정책 리소스를 사용하여 속성을 협상한다. 또 다른 실시예에서, 메모리는 공통 속성들, 레이블, 클라이언트, 현재의 협상 브로커, 새로운 협상 브로커, 위임 인에이블, 시작 시간, 지속시간, 결과, 가입 및 이들의 조합으로부터 선택되는 위임 리소스를 저장한다. 또 다른 실시예에서, 프로세서는 이러한 위임 리소스를 사용하여 속성을 협상한다.

본 출원의 다른 양상은 컴퓨터 구현 네트워크를 설명한다. 이러한 네트워크는 협상자 및 피-협상자를 포함한다. 협상자 및 피-협상자 각각은 데이터를 송신 및 수신하기 위한 송수신기를 포함한다. 협상자 및 피-협상자 각각은 서비스 레이어 속성을 협상하기 위한 명령어들이 저장되는 협상 서비스 레이어를 갖는 비-일시적 메모리를 또한 포함한다. 협상자 및 피-협상자 각각은 비-일시적 메모리에 동작가능하게 연결되고, 서비스 레이어 속성의 협상을 수행하도록 구성되는 프로세서 프로세서를 또한 포함한다. 실시예에 따르면, 협상자 및 피-협상자의 메모리는 협상 리소스, 정책 리소스, 위임 리소스 및 이들의 조합으로부터 선택되는 리소스를 포함한다.

본 발명의 상세한 설명이 더 잘 이해될 수 있도록 하기 위해, 그리고 관련분야에 대한 본 발명의 기여가 더 잘 인식될 수 있도록 하기 위해, 본 발명의 특정 실시예들이 다소 광범위하게 이와 같이 약술되었다.

본 출원의 보다 견고한 이해를 용이하게 하기 위해서, 동일한 엘리먼트들은 동일한 번호들로 참조되는 첨부 도면들에 대한 참조가 이제 이루어진다. 이러한 도면들은 본 출원을 제한하는 것으로 해석되어서는 안 되며, 단지 예시적인 것으로 의도된다.
도 1은 서비스 레이어를 지원하는 프로토콜 스택을 도시한다.
도 2는 CSE(common service entity) 및 CSF(common service function)을 도시한다.
도 3a는 oneM2M 서비스 레이어 아키텍처를 도시한다.
도 3b는 oneM2M 서비스들 컴포넌트 아키텍처를 도시한다.
도 4a는 M2M(machine-to-machine) 또는 IoT 통신 시스템의 실시예를 도시한다.
도 4b는 M2M 서비스 플랫폼의 애플리케이션의 실시예를 도시한다.
도 4c는 예시적인 M2M 디바이스의 시스템 다이어그램의 애플리케이션의 실시예를 도시한다.
도 4d는 예시적인 컴퓨팅 시스템의 블록도의 애플리케이션의 실시예를 도시한다.
도 5a는 본 출원의 양상에 따라 협상 서비스들을 이용하는 동적 서비스들의 아키텍처 도면을 도시한다.
도 5b는 본 출원의 양상에 따라 협상 정책들을 구성 및 디스플레이하기 위한 그래픽 사용자 인터페이스를 도시한다.
도 6은 본 출원의 양상에 따라 개별 협상 요청을 위한 서비스 협상 프로토콜을 도시한다.
도 7은 본 출원의 양상에 따라 피-협상자에서 제안들을 행하기 위한 결정 질의를 도시한다.
도 8은 본 출원의 양상에 따라 협상자에서 제안들을 선택하기 위한 결정 질의를 도시한다.
도 9는 본 출원의 양상에 따라 다수의 협상 요청들에 대한 서비스 협상을 위한 흐름도를 도시한다.
도 10은 본 출원의 양상에 따라 투명 모드에서의 브로커-기반 서비스 협상을 위한 흐름도를 도시한다.
도 11은 본 출원의 다른 양상에 따라 협상을 위한 프록시로서 브로커-기반 서비스 협상을 위한 흐름도를 도시한다.
도 12는 본 출원의 다른 양상에 따라 인증 및 승인 프로토콜들이 있는 브로커-기반 서비스 협상을 위한 흐름도를 도시한다.
도 13은 본 출원의 다른 양상에 따라 협상 요청들의 조합을 이용하는 브로커-기반 서비스 협상을 위한 흐름도를 도시한다.
도 14는 본 출원의 다른 양상에 따라 브로커-기반 서비스 위임을 위한 흐름도를 도시한다.
도 15는 CSF 비트맵의 예시적인 실시예를 도시한다.
도 16은 CSF 특징 비트맵의 예시적인 실시예를 도시한다.
도 17은 본 출원의 양상에 따라 NGS(negotiation service)를 포함하는 oneM2M 아키텍처를 도시한다.
도 18은 본 출원의 양상에 따라 oneM2M ROA(resource oriented architecture)에서의 NGS CSF를 도시한다.
도 19는 본 출원의 다른 양상에 따라 oneM2M ROA에서의 NGS CSF를 도시한다.
도 20은 본 출원의 양상에 따라 oneM2M <ngtn> 리소스의 구조를 도시한다.
도 21은 본 출원의 양상에 따라 oneM2M <ngtnPolicy> 리소스의 구조를 도시한다.
도 22는 본 출원의 양상에 따라 oneM2M <ngtnDelegation> 리소스의 구조를 도시한다.
도 23은 본 출원의 양상에 따라 MN-CSE와 IN-CSE 사이의 서비스 협상의 예시적인 실시예를 도시한다.
도 24는 oneM2M SOA(service-oriented architecture)에 추가되는 협상 서비스의 예시적인 실시예를 도시한다.

예시적인 실시예의 상세한 설명이 본 명세서에서 다양한 도면들, 실시예들 및 양상들을 참조하여 논의될 것이다. 이러한 설명은 가능한 구현들의 상세한 예들을 제공하지만, 이러한 상세사항들은 예들로 의도되었으므로 본 출원의 범위를 제한하지 않는다는 점이 이해되어야 한다.

본 명세서에서 "일 실시예", 실시예", "하나 이상의 실시예들", 양상" 등에 대한 지칭은 그 실시예와 연계하여 설명되는 특정한 특징, 구조, 또는 특성이 본 개시내용의 적어도 하나의 실시예에 포함된다는 점을 의미한다. 더욱이, 본 명세서에서의 다양한 곳에 있는 "실시예"라는 용어가 반드시 동일한 실시예를 지칭하는 것은 아니다. 즉, 일부 실시예들에 의해서는 드러나지만 다른 실시예에 의해서는 그렇지 않을 수 있는 다양한 특징들이 설명된다.

본 출원은, 서비스 레이어에서 NGS(negotiation service)와 같이, 새로운 기능을 이용하기 위한 기술들을 설명하며, 이는 서비스 노드들 및 애플리케이션들이 다른 서비스 노드들 또는 애플리케이션들로부터 서비스들을 동적으로 요청하고 조절하는 것을 돕는다. 일 실시예에서, 협상 서비스에 따르면, 협상자(Negotiator)는 협상 요청(Negotiation Request)을 발행하는 M2M 엔티티이고, 피-협상자(Negotiatee)는 이러한 협상 요청을 수신하고 제안들을 제출하는 M2M 엔티티이다. 피-협상자는 제안들을 행하고, 협상자들은 미리 구성된 협상 정책들에 기초하여 제안들을 선택한다. 이러한 정책 기반 협상 프로세스들은 정책 기반 공통 서비스 기능들을 사용하여 다양한 서비스들이 협상될 수 있는 M2M 시스템들에 매우 적합한다. 이러한 기능들은 제안들을 행하는 것 및 상이한 서비스들을 협상하기에 적합한 제안들을 선택하는 것을 포함한다.

일 양상에서, 협상자는 협상 프로세스를 촉진시키고 협상 오버헤드를 감소시키는데 도움이 되는 특정 제안들을 능동적으로 제시할 수 있으며, 이는 제한된 M2M 디바이스들에 특히 유익하다. 또한, 피-협상자는 협상 프로세스 동안 협상 성공률을 향상시키고 전반적인 협상 시그널링 오버헤드를 또한 감소시킬 수 있는 다른 피-협상자들 추천할 수 있다. 피-협상자는 또한 다수 협상자들의 요청들을 조합하여 모든 협상자를 만족시키기 위한 보다 현명한 제안들을 행할 수 있다.

다른 양상에서, 협상 브로커(Negotiation Broker)는 협상자 및/또는 피-협상자를 위한 프록시 역할을 할 수 있는 M2M 엔티티이다. 협상 브로커는 또한 협상 관련 메시지들을 협상자와 피-협상자 사이에 전달할 수 있다. 이것은 협상 작업들을 협상 브로커에 오프로드함으로써 제한된 디바이스들에서 협상 오버헤드를 완화하는데 도움이 된다. 일 실시예에 따르면, 협상 브로커가 대응 피-협상자를 자동으로 선택할 수 있는 투명 모드가 설명된다. 투명 모드에서, 협상 브로커는 제한된 M2M 디바이스들, 즉 협상자들이 피-협상자들을 자동으로 선택하도록 도울 수 있다. 이와 같이, 제한된 M2M 디바이스들은 피-협상자의 아이덴티티를 알 필요가 없다. 투명 모드에서 협상 브로커는 제한된 M2M 디바이스들, 즉 협상자들이 피-협상자들을 자동으로 선택하도록 도울 수 있다. 이와 같이, 제한된 M2M 디바이스들은 피-협상자를 알 필요가 없다.

프록시 모드에서, 협상 브로커는 제한된 M2M 디바이스들이 협상 작업들을 수행하기 위한, 예를 들어, 제안들을 행하고 제안들을 선택하기 위한 프록시 역할을 할 수 있다. 제한된 M2M 디바이스들은 협상 결과들을 수신하기만 하면 된다. 제시된 브로커-기반 협상 접근방식은 제한된 M2M 디바이스들이 보다 쉬운 방식으로 협상을 수행하도록 돕는다. 이러한 접근방식은 제한된 디바이스들과의 통신 오버헤드를 완화할 수 있다.

다른 실시예에서는, 협상 브로커가 피-협상자를 대신하여 제안들을 행하는 피-협상자를 위한 프록시가 설명된다. 이러한 프록시 모드에서, 협상 브로커는 제한된 M2M 디바이스들이 협상 작업들을 수행하기 위한, 즉 제안들을 행하고 제안들을 선택하기 위한 프록시 역할을 할 수 있다.

다른 실시예에서는, 하나의 협상 브로커로부터 다른 협상 브로커로 협상 기능들을 위임하는 협상 브로커 위임이 제시된다. 피-협상자들을 추천하기 위해 제시되는 아이디어는 협상 성공률을 향상시키고 그에 따라 오버헤드를 감소시키는데 도움이 될 수 있다. 양상에 따르면, 다수의 협상 요청들을 조합 및 처리하기 위해 제시되는 아이디어는 다양한 M2M 애플리케이션들로부터의 협상 요청들을 공동으로 처리할 수 있고, 결국은 협상 성공률을 향상시키고 협상 오버헤드를 낮추는데 도움을 준다.

서비스 레이어

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

M2M 서비스 레이어는 M2M 타입 디바이스들 및 애플리케이션들에 대한 부가 가치 서비스들을 제공하는 것을 구체적으로 목표로 하는 일 타입의 서비스 레이어의 예이다. 최근에, 수개의 산업 표준 기관들, 예를 들어, oneM2M은 M2M 타입들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈 및 홈 네트워크와 같은 배치들에 통합하는 것과 관련된 도전과제들에 대처하기 위해 M2M 서비스 레이어들을 개발해 왔다.

M2M 서비스 레이어는 애플리케이션들 및 디바이스들에게 서비스 레이어에 의해 지원되는 M2M 지향 능력들의 집합에 대한 액세스를 제공할 수 있다. 몇몇 예는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속성 관리를 포함하지만 이에 제한되는 것은 아니다. 이러한 능력들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 리소스 구조들, 및 리소스 표현들을 사용하는 API들을 통해 애플리케이션들에 이용 가능하게 된다.

OneM2M 서비스 레이어 아키텍처

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

oneM2M 공통 서비스 레이어는 도 2에 도시되는 바와 같이 일련의 CSF들(Common Service Functions), 즉, 서비스 능력들을 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화(instantiation)는, 상이한 타입들의 네트워크 노드들, 예를 들어, 인프라스트럭처 노드, 미들 노드, 애플리케이션-특정 노드 상에 호스팅될 수 있는 CSE(Common Services Entity)라고 지칭된다. oneM2M은 도 3a에 도시되는 ROA(Resource Oriented Architecture) 및 도 3b에 도시되는 SOA(Service Oriented Architecture)라 불리우는 2개의 아키텍처 접근방식들로 서비스 레이어를 개발하고 있다.

도 3a에 도시되는 바와 같이, 리소스는, Create, Retrieve, Update, 및 Delete와 같은 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 아키텍처에서의 고유하게 어드레스 지정 가능한 엘리먼트이다. 이러한 리소스들은 URI들(Uniform Resource Identifiers)을 사용하여 어드레스 지정 가능하게 된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 자신의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 "속성들(attributes)"의 세트를 지원한다.

SOA 아키텍처는 RESTful 기반이 아닌 레거시 개발을 고려하도록 개발되고 있다. 도 3b에 도시되는 바와 같이, 이것은 기능적 아키텍처가 동일한 서비스 레이어를 주로 재사용한다. 이러한 서비스 레이어는 다양한 M2M 서비스들을 포함하고, 다수의 서비스들이 서비스 컴포넌트들로 그룹화될 수 있다. 기존 참조 포인트들에 추가하여, 이것은 서비스간 참조 포인트 Msc를 도입하였다. Msc 참조 포인트를 통과하는 M2M 서비스 컴포넌트들 사이의 통신은 웹 서비스들 접근방식, 예를 들어, 웹 서비스들 MEP(Message Exchange Patterns)를 이용한다.

OneM2M CSF들

다음 12개의 CSF들은 M2M 서버 또는 엔드포인트 M2M 디바이스와 같은 CSE에 의해 다른 CSE들 또는 AE들에 제공될 수 있는 oneM2M에서 현재 정의된다. 이들은 도 2에 도시된다.

ASM(Application and Service Layer Management): AE들 뿐만 아니라 CSE들의 기능들을 구성하고, 중재하고 및 업그레이드하는 관리 능력들을 제공함.

CMDH(Communication Management and Delivery Handling): 통신, 예를 들어, 예: CSE-to-CSE 통신을 전달하기 위해 구체적인 통신 접속을 어느 시간에 사용할지, 그리고 필요할 때 및 허용될 때, 통신 요청들을 차후에 전달될 수 있도록 버퍼링할지 결정함.

DMR(Data Management and Repository): 데이터 저장 및 조정 기능들을 제공하는 것을 담당함. 이것은 대량의 데이터를 종합하고, 이러한 데이터를 명시된 포맷으로 변환하고, 분석론 및 의미론 처리를 위해 이를 저장하기 위한 목적으로 데이터를 수집하는 능력을 포함한다.

DMG(Device Management): M2M 영역 네트워크 내에 존재하는 디바이스들 뿐만 아니라, MN들, 예를 들어, M2M 게이트웨이들, ASN들 및 ADN들, 예를 들어, M2M 디바이스들 상의 디바이스 능력들의 관리를 제공함.

DIS(Discovery): 속성들 및 리소스들에 포함되는 바와 같은 애플리케이션들 및 서비스들에 관한 정보를 검색함.

GMG(Group Management): 그룹 관련 요청들을 취급하는 것을 담당함. 이러한 요청은 그룹에 의해 지원되는 대량 작업들을 위해서 뿐만 아니라 그룹 및 그 구성원을 관리하기 위해 전송된다.

LOC(Location): AE가 위치 기반 서비스들을 위해 노드들(예를 들어, ASN, MN)의 지리적 위치 정보를 획득하게 함.

NSSE(Network Service Exposure, Service Execution and Triggering): Mcn 참조 포인트를 통해 네트워크 서비스 기능들을 액세스하기 위해 기본 네트워크들(Underlying Networks)과의 통신을 관리함.

REG(Registration): 등록된 엔티티들이 등록자(Registrar) CSE에 의해 제공되는 서비스들을 사용하게 하기 위해 AE 또는 다른 CSE로부터의 요청을 처리하여 등록자 CSE에 등록함.

SEC(Security): 민감한 데이터 취급, 보안 관리, 보안 관련 수립, 식별/인증/승인을 포함하는 액세스 제어, 및 아이덴티티 관리와 같은 능력들을 포함함.

SCA(Service Charging and Accounting): 서비스 레이어에 대한 과금 기능들을 제공함. 이것은 온라인 실시간 신용 제어를 또한 포함하는 상이한 과금 모델들을 지원한다.

SUB(Subscription and Notification): 리소스 상의 변경들, 예를 들어, 리소스의 위임을 추적하는 가입에 관한 통지들을 제공함.

서비스 레이어 협상

다음의 기존 서비스들 및/또는 프로토콜들이 서비스 레이어 협상에 이용될 수 있다:

협상 요청 진입(Negotiation Request Admission): 이러한 협상 서비스는, 과거 요청들 및 협상 결과들의 이력 뿐만 아니라 관련 컨텍스트들에 기초하여, 요청자들로부터의 협상 요청을 수락할지 결정할 수 있다. 이러한 협상 서비스는 협상의 긴급성에 기초하여 요청들의 우선순위를 설정할 수도 있다.

협상 당사자 제어(Negotiation Party Control): 이러한 협상 서비스는 누구와 협상을 수행할지 결정할 수 있다. 협상 당사자는 요청자들에 의해 통보되거나 이용 가능한 IoT 서비스 제공자들 등에 대한 발견 결과에 기초하여 인식 능력(Cognition Capability)에 의해 결정될 수 있다.

협상 전략 제어(Negotiation Strategy Control): 이러한 협상 서비스는 요청자를 대신하여 협상 전략을 선택할 수 있다. 이러한 협상 서비스는 요청자의 입력 협상 목표에 기초하여 요청자의 최선의 이익을 항상 고려한다.

협상 적응(Negotiation Adaptation): 이러한 협상 서비스는 정책 변경 또는 컨텍스트 변경으로 인해 적응될 수 있다. 이러한 협상 서비스 정책들은 컨텍스트, 소프트웨어 정의 설정들 및 다른 서비스들로부터의 입력과 같은 것들에 기초하여 동적으로 적응될 수 있다. 정책들의 동적인 적응을 통해, 결정이 결국 동적으로 적응될 수 있다. 컨텍스트 인식 서비스(Context-aware Service)가 협상 적응을 위해 관련 컨텍스트를 이러한 협상 서비스로 동적으로 업데이트할 수 있거나 또는 이러한 협상 서비스가 컨텍스트 인식 서비스로부터 관련 컨텍스트들을 사전에 검색할 수 있다.

협상 일반화(Negotiation Generalization): 이러한 협상 서비스는, 차후 협상 요청자들에 의해 사용될 수 있는, 과거 협상 프로세스들로부터 요약되는 일반화되고 공통인 협상 전략을 세우고, 각각의 요청자에 대한 협상 전략을 결정함에 있어서 인지 능력의 과부하를 감소시킬 수 있다.

협상 가입(Negotiation Subscription): 임의의 적응이 가입자들에게 통지될 수 있도록 협상 결과로의 가입이 제공된다. 이러한 가입 메커니즘은 자율적인 적응을 가능하게 한다. 가입자가 자신이 가입하는 것과 동일한 협상 결과를 사용하면, 가입된 협상 결과에 대한 변경은 가입자가 이에 자동으로 적응하도록 트리거할 수 있다. 협상 가입이 없으면, 다른 엔티티들은 협상 결과를 재사용하여 따를 수 없다. 본 개시내용은 제시되는 지능형 협상 서비스의 컴포넌트들, 및 다른 IoT 서비스들, IoT 엔티티들 및 IoT 애플리케이션들에 대한 인터페이스들을 또한 설명한다.

일반적 아키텍처

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

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

도 4a에 도시되는 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 후방에 있는 영역 네트워크들(area networks)을 지칭한다. 필드 도메인은 프록시를 갖는 SCS와 같은 M2M 게이트웨이들(14), 및 UE 디바이스들과 같은 단말 디바이스들(18)을 포함한다. 임의의 수의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)이 원하는 바에 따라 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 점이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말기 디바이스들(18) 각각은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 송신 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 무선 M2M 디바이스들(예를 들어, 셀룰러 및 논-셀룰러) 뿐만 아니라 고정형 네트워크 M2M 디바이스들(예를 들어, PLC)이 통신 네트워크(12)와 같은 오퍼레이터 네트워크들 또는 직접 무선 링크를 통해 통신하게 한다. 예를 들어, M2M 디바이스들(18)은, 통신 네트워크(12) 또는 직접 무선 링크를 통해, 데이터를 수집할 수 있고, 이러한 데이터를 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에 전송할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 이하 설명되는 바와 같이 M2M 서비스 레이어(22)를 통해 M2M 애플리케이션(20)에 송신될 수 있고 그로부터 수신될 수 있다. 일 실시예에서, 서비스 레이어(22)는 PCE일 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN, 예를 들어, Zigbee, 6LoWPAN, Bluetooth, 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

도 4b를 참조하면, 필드 도메인에 도시되는 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 서비스 레이어(22')가 있다. M2M 서비스 레이어(22')는 인프라스트럭처 도메인에서 M2M 애플리케이션(20') 및 기본 통신 네트워크(12')에 대한 서비스들을 제공한다. M2M 서비스 레이어(22')는 필드 도메인에서 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)에 대한 서비스들을 또한 제공한다. M2M 서비스 레이어(22')는 임의 수의 M2M 애플리케이션들, M2M 게이트웨이 디바이스들 및 M2M 단말 디바이스들과 통신할 수 있다는 점이 이해될 것이다. M2M 서비스 레이어(22')는 상이한 서비스 제공자에 의해 서비스 레이어와 상호작용할 수 있다. M2M 서비스 레이어(22')는 하나 이상의 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예를 들어, 클라우드/컴퓨트/스토리지 팜들 등) 등에 의해 구현될 수 있다.

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

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

본 출원에서 논의되는 바와 같은 서비스들을 동적으로 요청하는 방법이 서비스 레이어의 일부로서 구현될 수 있다. 이러한 서비스 레이어는 API들(Application Programming Interfaces) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어이다. ETSI M2M 및 oneM2M 아키텍처들 양자 모두 UE들 PSM 모드를 제어 및 조정하는 이러한 방법을 포함할 수 있는 서비스 레이어를 사용한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)이라고 지칭된다. SCL은 M2M 디바이스(여기서 이것은 DSCL(Device SCL)이라고 지칭됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)이라고 지칭됨) 및/또는 네트워크 노드(여기서 이것은 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 레이어는 CSF들(Common Service Functions), 예를 들어 서비스 능력들의 세트를 지원한다. 하나 이상의 특정 타입들의 CSF들의 세트의 인스턴스화(instantiation)는 상이한 타입들의 네트워크 노드들, 예를 들어 인프라스트럭처 노드, 미들 노드, 애플리케이션-특정 노드 상에 호스팅될 수 있는 SCS와 같은 CSE(Common Services Entity)라고 지칭된다. 또한, 본 출원에 설명되는 바와 같은 협상자와 피-협상자 사이에서 서비스를 협상하는 방법은 본 출원에 따라 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 사용하여 요청 서비스들을 동적으로 요청하는 M2M 네트워크의 일부로서 구현될 수 있다.

도 4c는 예를 들어 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적 M2M 디바이스(30)의 시스템 다이어그램이다. 도 4c에 도시되는 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 엘리먼트(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드/표시기(들)(42), 비-이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. M2M 디바이스(40)는 실시예와 일관성을 유지하면서 전술한 엘리먼트들의 임의의 하위 조합을 포함할 수 있다는 점이 이해될 것이다. 이러한 디바이스는 센서 데이터(sensory data)의 내장된 의미론적 명명을 위해 개시된 시스템들 및 방법들을 사용하는 디바이스일 수 있다. M2M 디바이스(30)는 예를 들어 본 출원에 설명되는 바와 같은 그리고 도면에 도시되는 바와 같은 LLN 디바이스들, 백본 라우터들 및 PCE들을 포함하는 다른 디바이스들과 함께 이용될 수도 있다.

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

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

또한, 도 4c에는 송신/수신 엘리먼트(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)는 전원(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) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.

도 4d는, 예를 들어, 도 4a 및 도 4b의 M2M 서비스 플랫폼(22)이 구현될 수 있는 예시적 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있으며, 이러한 소프트웨어가 어디에 또는 어떤 수단에 의해 저장되거나 액세스되든, 소프트웨어의 형태일 수 있는 컴퓨터 판독 가능 명령어들에 의해 주로 제어될 수 있다. 이러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)이 작업할 수 있도록 CPU(central processing unit)(91) 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 추가적인 기능들을 수행하거나 CPU(91)를 지원하는, 메인 CPU(91)와는 별개인 선택적 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 내장된 의미론적 명칭을 갖는 센서 데이터에 대한 질의들 같은, 내장된 의미론적 명명을 위한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성, 및 처리할 수 있다.

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

시스템 버스(80)에 연결되는 메모리 디바이스들은 RAM(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)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 컴포넌트들을 포함한다. 디스플레이(86)는, 내장된 의미론적 명명을 사용하여 파일들 또는 폴더들에 센서 데이터를 디스플레이할 수 있다. 또한, 컴퓨팅 시스템(90)은 도 4a 및 도 4b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

본 출원의 양상에 따르면, NGS는 M2M 엔티티들이 보다 유연하게 서비스들을 동적으로 그리고 효율적으로 요청할 수 있게 한다. 예를 들어, 도 5a는 NGS가 3개의 시나리오들을 지원할 수 있는 방법을 도시한다. NGS는 M2M 디바이스 및 M2M 서버 양자 모두에 그들의 서비스 레이어의 새로운 기능으로서 존재한다. '시나리오 1'로서 도시되는 예시적인 실시예에서, M2M 디바이스의 NGS는 M2M 서버의 NGS와 상호 작용하여 이들 사이의 서비스 협상을 이행한다. '시나리오 2'로서 도시되는 다른 예시적인 실시예에서, M2M App A(또는 App B)는 M2M App A(또는 App B)에 의해 요청되는 바와 같이 서비스들을 협상하라고 M2M 서버의 NGS와 통신한다. '시나리오 3'으로서 도시되는 추가의 예시적인 실시예에서, M2M App A와 M2M App B는 M2M 서버를 통해 서로 서비스들을 협상한다. 즉, 애플리케이션들 양자 모두 M2M 서버의 NGS와 통신하고, 이는 결국 애플리케이션들 양자 모두 서비스 협상을 수행하는데 도움을 준다.

일 실시예에서, 예를 들어, 도 5b에 도시되는 바와 같은 GUI(graphical user interface)는 M2M 디바이스, 게이트웨이 또는 서버에서 협상 정책들을 구성/디스플레이하는데 사용할 수 있다. 예를 들어, GUI는 협상 정책들의 구성을 디스플레이하기 위한 텍스트 상자를 포함하는 영역을 포함할 수 있다. GUI는 협상 정책들 및 결과들을 디스플레이하는 텍스트 상자를 포함하는 영역을 또한 포함할 수 있다. 예시적인 실시예에서, 사용자는 터치 스크린 인터페이스를 통해 GUI와 상호 작용할 수 있다.

개별 협상 요청에 대한 프로시저들

일 실시예에 따르면, 도 6은 개별 협상 요청들에 대한 서비스 협상 프로세스를 도시한다. 도 6에서의 단계들 각각은 로마 숫자로 나타난다. 피-협상자 A는 협상자에게 협상 가능 서비스들을 표시하거나 통지한다. 여기서, 협상 가능 서비스들은 그 특징들, 또는 구성이 동적으로 협상되어 상이한 M2M 엔티티들에 제공될 수 있다면 임의의 서비스로서 정의된다. 예를 들어, 상이한 M2M 디바이스들에 대한 스토리지 크기 및 요금율이 동적으로 협상되고 할당할 수 있다면 M2M 서버에 의해 제공되는 데이터 관리 서비스는 협상 가능한다. 그러나, 각각의 M2M 디바이스가 항상 동일한 등록 서비스를 사용하여 M2M 서버와 관련될 필요가 있다면 M2M 서버에 의해 제공되는 등록 서비스는 협상 가능하지 않을 수 있다.

협상자는 피-협상자 A와 제안된 협상 프로세스를 수행한다. 협상자는 일 실시예에서 서비스들의 세트를 협상할 수 있다. 다른 실시예에서, 협상자는 구체적인 서비스의 특징들을 협상할 수 있다. 이러한 협상 프로세스로부터 2가지 결과들이 존재할 것이다. 1) 협상자와 피-협상자 A가 합의에 도달한다; 또는 2) 피-협상자 A는 협상자의 요구사항을 충족시킬 수 없으며, 다른 피-협상자, 예를 들어, 피-협상자 B를 추천한다. 협상 프로세스의 일부로서, 협상자는 피-협상자 A에 의해 선택적으로 인증될 수 있으며 선택적으로, 피-협상자 A가 협상자에 의해 인증될 수 있다. 인증 프로세스의 일부로서, 협상자와 피-협상자 A는 미리 구성된 자격 증명들을 사용하여 인증될 수 있다. 예를 들어, 메시지 인증/무결성 보호를 위한 키들인 추가 자격 증명이 제공될 수 있으며, 이는 협상자와 피-협상자 A 사이의 추가의 메시지들 교환들 동안 인증 목적으로 사용될 수 있다. 협상자 및/또는 피-협상자에 의한 키들의 소유를 보장하는 것이 일 형태의 암시적 인증일 수 있다. 선택적으로, 협상된 서비스들을 액세스하는데 사용될 수 있는 승인 자격 증명들이 협상자에게 공급될 수 있다.

위에 논의된 대안적인 실시예에 따르면, 협상자가 피-협상자 A와 합의를 하지 않으면, 피-협상자 A에 의해 추천되는 바와 같은 다른 피-협상자 B와 협상을 수행할 수 있다.

협상자와 피-협상자 A 사이의 인증 프로세스 또는 선택적 상호 인증 프로세스와 유사하게, 협상자와 피-협상자 B 사이에 인증 및 승인 프로세스가 수행될 수 있다.

도 7에서의 단계들 각각은 로마 숫자로 표현된다. 예를 들어, 단계 0-1에서, 협상자는 "협상 가능 서비스들에 대한 가입"을 피-협상자 A에게 발행한다. 결과적으로, 서비스가 협상 가능하게 되면 협상자는 피-협상자 A로부터 단계 0-2에서 자동 통지를 수신할 것이다. 이것은 그 부분적 또는 전체 특징들/기능성들이 동적으로 요청, 변경 및/또는 구성될 수 있음을 의미한다. 협상자는 이러한 단계에서 타겟 서비스들의 리스트와 같은 다양한 가입 기준을 포함할 수 있다. 가입 기준은 그 순간 협상될 수 없는 특징들을 또한 포함할 수 있다. 대안적으로, 피-협상자는, 예를 들어, RESTful RETRIEVE 작업을 사용하여, 피-협상자 A에서 협상 가능 서비스들의 리스트를 발견하거나 검색하라는 구체적인 메시지를 협상자에게 전송할 수 있다. 따라서, 피-협상자 A는 협상자가 제공하는 협상 가능 서비스들의 리스트로 협상자에게 다시 응답할 것이다.

이후의 인스턴스에서, 그 서비스들 중 임의의 것이 협상 가능하게 되고 변경이 단계 0-1에서 가입 기준을 충족하면, 피-협상자 A는 "협상 가능 서비스들에 대한 통지" 메시지를 협상자에게 전송한다. 이러한 메시지의 목적은 협상자에게 피-협상자 A에서 협상 가능한 서비스들의 리스트를 통보하는 것이다. 이러한 메시지는 다음의 정보를 포함할 수 있다:

ListOfNegotiableService: 이것은 각각의 협상 가능 서비스의 명칭, 식별자 및/또는 설명, 예를 들어, ServiceID를 포함한다. 각각의 협상 가능 서비스에 대해, 피-협상자 A는 서비스의 어떤 특징들이 협상 가능하고 서비스 및 그 특징들이 얼마나 오래 이용 가능할 것인지 표시할 수 있다. 또한, 피-협상자 A는 각각의 협상 가능 서비스에 대해 협상자로부터 예상되는 입력들을 명시할 수 있다.

다음으로, 단계 1에서, 협상자는 협상을 개시하기 위해 "협상 요청" 메시지를 피-협상자 A에게 전송한다. 이러한 메시지는 다음 정보를 포함할 수 있다:

ServiceID: 피-협상자 A와 협상될 서비스들의 명칭, 식별자 및/또는 설명. 협상될 각각의 서비스에 대해, 협상자는 이러한 서비스의 하나 이상의 특징들에 대해 협상할 것을 명시적으로 요청할 수 있다. 협상자는 단계 0-2로부터 이러한 정보를 알 수 있을 것이다. 예를 들어, 서비스 ID는 협상자가 더 많은 또는 더 빠른 스토리지를 취득하기 원한다는 점을 표시할 수 있다.

InputForMakeSuggestion: 협상자는 단계 2에서 협상을 행하기 위해 피-협상자 A에 의해 영향을 받을 필요한 입력들을 제공한다. 기본적으로, 이러한 단계에서, 피-협상자 A는 이러한 파라미터를 사용하여 각각의 협상 정책의 "Condition" 파라미터에 대해 비교하여 각각의 협상 정책의 적용 가능성을 점검한다. 협상자는 단계 0-2로부터 어떤 입력 정보가 제공되어야 하는지 알 수 있게 될 것이다. 예를 들어, 협상자가 더 많은 및/또는 더 빠른 스토리지를 취득하기 원한다는 점을 서비스 ID가 표시하면, InputForMakeSuggestion ID는 얼마나 많은 스토리지가 요구되는지 또는 어떠한 액세스 속도들이 그 스토리지에 요구되는지 표시할 수 있다.

ProposedSuggestions: 협상자는 피-협상자 A에게 특정 제안들을 제시할 수 있으며, 이는 피-협상자 A에서 동작들을 간소화하고 협상 프로세스를 촉진하는데 도움이 될 수 있다. 기본적으로 ProposedSuggestions 파라미터는 피-협상자 A에서 유지되는 각각의 협상 정책에서의 "Result" 파라미터와 동일한 의미를 갖는다. ProposedSuggestions는 협상자가 수용 가능한 것으로 찾을 수 있는 서비스의 예를 나타낸다.

다음으로 단계 2에서, 피-협상자 A는 자신의 로컬 정책들에 기초하여 제안들을 행하기 위한 입력으로서 단계 1로부터의 정보를 취한다. 이러한 단계의 출력은 단계 3에서 협상자에게 전송될 OfferedSuggestions이다. 도 7은 이러한 제안들을 행하는 것에 관하여 피-협상자가 진행할 수 있는 방법에 대한 프로시저를 제공한다. 피-협상자 A는 자신의 정책들을 점검하지 않고 또는 적용 가능한 정책들이 존재하지 않으면 협상자로부터 ProposedSuggestions를 단순히 수락할 수 있다.

다음으로, 단계 3에서, 피-협상자 A는 협상자에게 "협상 응답" 메시지를 전송한다. 이러한 메시지는 OfferedSuggestions를 포함한다. 이러한 파라미터는 협상자에 대한 다수의 제안들을 포함할 수 있거나, 또는 현재 수행되는 협상 라운드들의 수가 피-협상자 A에서 미리 구성된 임계값을 초과하면 다른 피-협상자 B를 단순히 나타낼 수 있다. 피-협상자 A와 B는 동일한 서비스 도메인에 존재할 수 있다는 점에 주목하자. 피-협상자 A는 안다면 피-협상자 B에서 ListOfNegotiableServices를 또한 표시할 수 있다, 예를 들어, 피-협상자 A와 피-협상자 B는 조기에 단계 0-1과 단계 0-2를 수행하고 서로의 협상 가능 서비스들을 알 수 있다. OfferedSuggestions이 다른 피-협상자 B만 포함하면, 협상자는 현재 협상을 중단하고 피-협상자 B와 직접 새로운 협상 프로세스를 시작할 것이다. 이러한 경우에, 단계 4, 단계 5 및 단계 6은 생략될 것이다.

"협상 응답" 메시지를 수신한 후, 협상자는 OfferedSuggestions에 만족하지 못하면 단계 1을 반복하여 다른 협상 라운드를 시작할 수 있다. 그렇지 않고, 협상자는 OfferedSuggestions에 포함되는 특정 제안들에 만족하면 단계 4를 수행한다. 반복되는 단계 1에서, 협상자는 ServiceID, InputForMakeSuggestion 및 ProposedSuggestions에 대한 새 파라미터 값들을 제출할 수 있다.

단계 4에서, 협상자는 자신이 유지하는 협상 정책들에 기초하여 OfferedSuggestions로부터 적절한 제안들을 선택한다. 협상자는 자신의 정책들을 점검하지 않고 또는 적용 가능한 정책들이 존재하지 않으면 수신된 OfferedSuggestions를 단순히 선택할 수 있다는 점에 주목하자. 단계 5에서, 협상자는 피-협상자 A에게 "협상 확인" 메시지를 전송한다. 이러한 메시지는 단계 4로부터의 SelectedSuggestions와 ServiceID를 포함한다. ServiceID는 단계 1에서의 것과 동일하거나 그 서브-세트일 수 있다. 단계 6에서, 피-협상자 A는 협상자에게 "수신확인" 메시지를 전송할 수 있다. 그 결과, 협상자와 피-협상자 A는 협상중인 서비스들에 대한 합의에 도달한다. 협상자는 반복될 협상 라운드들, 즉 반복되는 단계들 1, 2, 및 3의 최대 수에 대한 임계값을 설정할 수 있다. 대안적으로, 피-협상자 A는 반복되는 요청들, 즉 단계 1의 수가 미리 구성된 임계값보다 크면 협상자의 요청을 거절할 수 있다. 수행되는 협상 라운드들의 수가 이러한 임계값을 초과할 때 그리고 협상자와 피-협상자 A(또는 B) 사이에 아직 합의가 전혀 없으면, 협상자는 협상 프로세스를 중단하거나 또는 자신의 협상 정책을 변경할 수 있다. 다른 실시예에 따르면, 사용자가 결정을 행하고 있으면 정책들이 이용되지 않는 것이 예상된다.

도 7은 피-협상자가 제안을 행할 수 있는 방법(예를 들어, 도 6에서의 단계 2)을 도시한다. 피-협상자는 정책 기반 접근방식을 사용하여 제안들을 행한다. 즉, 피-협상자는 모든 협상 가능 서비스들에 대해 특정 협상 정책들을 유지한다. 각각의 협상 정책은 다음과 같은 정보 또는 파라미터들을 가질 수 있다:

ServiceID: 이러한 협상 정책이 적용 가능한 서비스들의 명칭, 식별자, 및/또는 설명을 표시함.

Condition: 이러한 협상 정책이 적용될 수 있는 상황들을 표시함.

Results: "Condition"이 충족되면 행해질 제안들을 표시함.

Negotiator: 이러한 협상 정책이 적용 가능한 협상자들의 리스트를 표시함. 정책 예들은 표 1에 주어진다. 예로서, 피-협상자 역할을 하는 M2M 서버는 보다 유연한 디바이스 관리 서비스들을 제공하기 위해 이러한 정책들을 유지할 수 있다. 이러한 정책들은 M2M 서버 자체에 의해 또는 특별한 관리자 애플리케이션에 의해 생성될 수 있다.

피-협상자가 제안들을 행하기 위해서는 다음 단계들이 필요하다. 피-협상자는 수신되는 "협상 요청"에서의 파라미터 값들을 입력으로서 취하여 로컬 협상 정책들과 비교하여 모든 잠재적 제안들을 획득한다. 정책이 적용 가능하면, 예를 들어, "InputForMakeSuggestion"이 정책에서의 "Condition"과 매칭되면, 정책의 "Result"는 잠재적인 제안들일 것이다. 정책 후보들이 도 7에서 점검되더라도, 피-협상자는 특정 수의 정책 후보를 선택적으로 점검할 수 있다는 점이 예상된다. 도 7에서의 각각의 단계들은 로마 숫자로 나타난다.

단계 1에서, 피-협상자는 수신되는 "협상 요청" 메시지를 입력들로서 취한다. 이러한 메시지는 3개의 파라미터들: ServiceID, InputForMakeSuggestion, 및 ProposedSuggestions를 포함한다는 점에 주목하자. 단계 2에서, 피-협상자는 "ServiceID"를 사용하여 현재 "협상 요청"에 대한 자신의 로컬 협상 정책 데이터베이스로부터 정책 후보들의 위치를 찾는다. 로컬 정책은 자신의 "ServiceID"가 "협상 요청"에 포함되는 "ServiceID"를 커버하면 정책 후보가 된다. 피-협상자는 "협상자" 정보를 사용하여 정책들을 필터링하고 정책 후보 리스트를 보다 정확하게 할 수 있다. 이러한 단계의 출력은 수신되는 "협상 요청"에 잠재적으로 적용될 수 있는 특정 정책들을 포함하는 정책 후보 세트이다. 피-협상자가 미리 공급된 자격 증명들에 기초하여 협상자를 인증하는지 정책들이 지시할 수 있다. 협상자는 피-협상자를 유사한 방법으로 선택적으로 인증할 수 있다.

단계 3에 따르면, 피-협상자는 단계 2에서 발견되는 임의의 정책 후보가 존재하는지 점검한다. '예'이면, 단계 4로 이동할 수 있다; 그렇지 않으면, 단계 13으로 진행한다. 단계 4에서, 피-협상자는 단계 2에서 발견된 정책 후보 세트에서의 제1 정책으로서 CurrentPolicy를 설정한다. 다음으로, OfferedSuggestions를 비어 있게 설정한다. 단계 5에서, 피-협상자는 CurrentPolicy가 현재 "협상 요청"에 대한 자신의 적용 가능성에 관한 결정을 행한다. 단계 6에서, CurrentPolicy가 적용 가능한지 확인이 행해진다. 그렇다면, 피-협상자는 단계 7로 진행하여 제안들을 행한다. 그렇지 않으면, 피-협상자는 단계 9로 이동하여, 이용 가능하다면, 다음 정책을 점검한다. 예를 들어, 후보 정책은 만료될 수 있거나 협상자에게 허용되지 않는다.

단계 7에 따르면, 피-협상자는 CurrentPolicy에 기초하여 제안을 행한다. 단계 7.1에서, NGS는 InputForMakeSuggestion을 CurrentPolicy의 "Condition"과 비교한다. 양쪽이 서로 매칭되면, CurrentPolicy가 적용될 것이고; 그렇지 않으면, CurrentPolicy는 제안을 행하는데 영향을 주지 않는다. "Condition"은 피-협상자의 로컬 컨텍스트 정보에 관련된 특정 정보를 포함할 수 있다. 이러한 경우에, 피-협상자는 "Condition"에 대한 자신의 현재 컨텍스트 정보를 점검할 수도 있다.

단계 7.2에서, CurrentPolicy의 "Results"는 newSuggestions로서 뽑힐 것이다. 단계 7.3에서 OfferedSuggestions는 함수 f(OfferedSuggestions, newSuggestion)에 따라 업데이트될 것이며, 이는 OfferedSuggestions에 newSuggestions을 단순히 추가하는 것일 수 있다. 단계 7.4에서는, OfferedSuggestions에 대한 변경이 존재하지 않는다.

다음으로, 단계 8에서, 피-협상자는 OfferedSuggestions이 협상자로부터의 "ProposedSuggestions"을 포함하는지 점검한다. '예'이면, ProposedSuggestions은 OfferedSuggestions"으로서 설정될 것이다(단계 13). OfferedSuggestions과 ProposedSuggestions의 교차가 협상자에 대한 최종 OfferedSuggestions으로서 선택될 것이다.

제안을 행하는 프로세스가 종료된다. '아니오'이면, 단계 9는 다른 정책 후보들을 점검한다. 피-협상자는 협상자의 ProposedSuggestions를 단순히 무시할 수 있다.

단계 9에서, 피-협상자는 CurrentPolicy가 정책 후보 세트에서의 마지막 정책인지 점검한다. '아니오'이면, 정책 후보 세트에서의 다음 정책이 CurrentPolicy로서 선택될 것이다(단계 10). 다음으로, 프로세스는 단계 5로 돌아간다.

예이면, OfferedSuggestions가 비어 있는지 점검이 행해진다. '아니오'이면, 출력은 제출된 제안들이다(단계 12). '예'이면, 피-협상자는 수신되는 "협상 요청"에 적용될 수 있는 정책들 중 아무것도 찾지 못하고, 협상자에게 다른 피-협상자를 추천할 수 있다(단계 14).

협상자에서 제안들을 선택함

도 8은 협상자에 의해 수행되는 제안들을 선택하는 상세사항들을 도시한다. 이것은 도 6의 단계 4에 관련된다. 본 개시내용에서는 협상자가 정책 기반 접근방식들을 사용하여 제안을 선택한다는 점이 제시된다. 기본적으로, 협상자는 특정 협상 정책들을 유지한다. 각각의 협상 정책은 다음과 같은 정보 또는 파라미터들을 가질 수 있다:

ServiceID: 이러한 협상 정책이 적용 가능한 서비스들의 명칭, 식별자, 및/또는 설명을 표시함.

Condition: 이러한 협상 정책이 적용될 수 있는 상황들을 표시함. 예를 들어, Condition은 협상중인 서비스가 어떤 프로토콜을 사용하는지 포함하거나 표시할 수 있음.

Results: "Condition"이 충족되면 선택될 제안들을 표시함.

Negotiatee: 이러한 협상 정책이 적용 가능한 피-협상자들의 리스트를 표시함.

몇몇 정책 예들이 표 2에 주어진다. 예로서, 협상자로서의 M2M 디바이스는 보다 유연한 디바이스 관리 서비스들을 요청하기 위해 이러한 정책들을 유지할 수 있다. 이러한 정책들은 M2M 디바이스 상의 애플리케이션에 의해 또는 특별한 관리자 애플리케이션에 의해 생성될 수 있다. 협상자는 위에 논의된 것과 유사한 프로시저들을 따르는 것에 의해 ProposedSuggestions를 획득하는데 이러한 정책들을 사용할 수도 있다.

협상자가 도 8에서 제안들을 선택하기 위해서는 다음의 단계들이 필요하다. 협상자는 수신되는 "협상 응답"에서의 파라미터 값들을 입력으로서 취하여 자신의 로컬 협상 정책들과 비교하여 적절한 제안들을 선택한다. 정책이 적용 가능하면, 즉, "InputForSelectSuggestion"이 정책에서의 "Condition"과 매칭되면, 정책의 "Result"는 잠재적인 SelectedSuggestion일 것이다. 도 8에서는 모든 정책 후보들이 점검되지만, 협상자는 특정 수의 정책 후보들만 선택적으로 점검할 수 있다.

단계 1에서, 협상자는 입력들로서 다음 파라미터들을 취한다:

피-협상자로부터의 "협상 응답" 메시지에서 수신된 ServiceID.

피-협상자로부터의 "협상 응답" 메시지에서 수신된 OfferedSuggestions.

협상자에 의해 결정되고 유지되는 로컬 파라미터인 InputForSelectSuggestion. 이러한 파라미터는 정책 의존적이라는 점에 주목하자. 표 2에서의 정책들에 대해, InputForSelectSuggestion은 "관리될 디바이스들의 수"일 것이다. 협상자는 이러한 파라미터를 사용하여 각각의 정책 후보의 "Condition"에 대해 비교하여 적절한 제안들을 결정하고 선택한다.

다음으로, 단계 2에서, 협상자는 "ServiceID"를 사용하여 자신의 로컬 협상 정책 데이터베이스로부터 정책 후보들의 위치를 찾는다. 로컬 정책은 자신의 "ServiceID"가 단계 1에서 "ServiceID"를 커버하면 정책 후보가 된다. 협상자는 더 이상 관련없는 정책들을 필터링해 내기 위해 "피-협상자" 정보를 사용할 수도 있다. 이러한 단계의 출력은 수신되는 "협상 응답"에 잠재적으로 적용될 수 있는 특정 정책들을 포함하는 정책 후보 세트이다.

단계 3에서, 협상자는 단계 2에서 발견되는 정책 후보가 존재하는지 점검한다. '예'이면, 협상자가 단계 2에서 발견된 정책 후보 세트에서의 제1 정책으로서 CurrentPolicy를 설정하는 단계 4로 프로시저가 이동한다. 다음으로, SelectedSuggestions를 비어 있는 세트로 설정한다. 그렇지 않으면, 단계 11로 진행한다.

단계 5에서, 협상자는 현재의 "협상 응답"에 대한 자신의 적용 가능성에 관해서 CurrentPolicy를 점검한다. 단계 6에서, CurrentPolicy가 적용 가능하면, 협상자는 단계 7로 진행하여 CurrentPolicy에 기초하여 제안들을 선택한다.

단계 7.1에서, NGS는 InputForSelectSuggestion을 CurrentPolicy의 "Condition"과 비교한다. 양자 모두 서로 매칭되면, CurrentPolicy가 적용될 것이다. 그렇지 않으면, CurrentPolicy는 제안을 선택하는데 영향을 주지 않는다. "Condition"은 협상자의 로컬 컨텍스트 정보에 관련된 특정 정보를 포함할 수 있다. 이러한 경우에, 협상자는 자신의 현재 컨텍스트 정보를 "Condition"에 대해 점검할 수도 있다. 단계 7.2에서, CurrentPolicy의 "Results"가 NewSelections로서 선택될 것이다. 단계 7.3에서, SelectedSuggestions는 함수 f(NewSelections, SelectedSuggestions, OfferedSuggestions)에 따라 업데이트될 것이며, 이는 NewSelections과 OfferedSuggestions의 교차를 현재 SelectedSuggestions에 단순히 추가하는 것일 수 있다. 단계 7.4에서는, SelectedSuggestions에 대한 변경이 존재하지 않는다.

단계 6으로부터의 대답이 '아니오'이면, 협상자는 단계 8로 이동하여, 존재한다면, 다음 정책을 점검한다. 예를 들어, 후보 정책은 만료될 수 있거나 "협상 응답"을 전송한 피-협상자에게 허용되지 않을 수 있다. 단계 8에서, 협상자는 CurrentPolicy가 정책 후보 세트에서의 마지막 정책인지 점검한다. '아니오'이면, 프로시저는 정책 후보 세트에서의 다음 정책이 CurrentPolicy로서 선택될 단계 9로 이동한다. 다음으로, 단계 5로 돌아가서 CurentPolicy를 점검한다.

단계 8로부터의 대답이 '예'이면, 협상자가 SelectedSuggestions가 비어 있는지 점검하는 단계 10으로 진행한다. '예'이면, 프로시저는 단계 12로 이동하고, 협상자는 정책들 중 어느 것도 수신되는 "협상 응답"에 적용될 수 없음을 발견한다. SelectedSuggestions는 비어 있을 것이다. 협상자는 새로운 협상 라운드를 시작할 수 있다. 그렇지 않고, 단계 10으로부터의 대답이 '아니오'이면, 단계 11로 진행한다. 여기서, 협상자는 모든 정책 후보들을 점검한 이후 이러한 단계로 오고, SelectedSuggestions을 출력한다. 협상자에 의해 선택되는 SelectedSuggestions는 OfferedSuggestion의 서브-세트가 아닐 수 있다, 즉, SelectedSuggestions와 OfferedSuggestion 사이에 교차가 존재하지 않는다. 이러한 경우에, 협상자는 새로운 "협상 요청"을 재전송하는 것, 즉, 도 6에서의 단계 1을 재개할 수 있고, SelectedSuggestions는 새로운 "협상 요청"에 ProposedSuggestions으로서 포함될 수 있다.

다수의 협상 요청들을 위한 프로시저들

도 6에 도시되는 바와 같이, 피-협상자(A 또는 B 중 하나)는 각각의 협상 요청 또는 협상자를 독립적으로 취급한다. 사실, 상이한 협상자들로부터의 다수의 요청들을 공동으로 고려함으로써, 피-협상자는, 특히 다수의 협상자들이 서로 논리적으로 관련되고, 예를 들어, 동일한 위치로부터, 동일한 타입의 서비스들을 요청하고, 동일한 타입의 디바이스들을 가지고, 과거에 유사한 협상 이력 및 거동을 가지는 등일 수 있는 시나리오들에 대해, 협상자들에게 더 나은 제안들을 행할 수 있다. 일 예에서, 동일한 ServiceID를 갖는 협상 요청들은 공동으로 고려될 수 있다. 피-협상자는 이러한 조합을 수행하기 위해 수신되는 협상 요청을 버퍼링할 수 있다. 피-협상자는 다수의 요청들이 공동으로 고려될 때만 적용 가능한 특별 정책들을 구성했을 수 있다. 이러한 목적으로, 기본 서비스 협상을 위한 대안적인 프로시저가 도 9에서 전개되며, 여기서 피-협상자는 두 협상자들 A 및 B로부터의 협상 요청들을 공동으로 고려하여 제안들을 행한다. 도 9에서의 단계들 각각은 로마 숫자로 표현된다.

단계 1A에서, 협상자 A는 피-협상자에게 "협상 요청"을 전송한다. 단계 1B에서 협상자 B는 피-협상자에게 "협상 요청"을 전송한다. 단계 2에서, 피-협상자는 협상자 A 및 B로부의 요청들 양자 모두를 고려하여 제안들을 행한다. 피-협상자는 협상자 A와 협상자 B에 대해 독립적으로 도 7에서의 프로시저를 먼저 수행하여 OfferedSuggestions의 2개의 값들을 얻을 수 있다. 다음으로, 최종 OfferedSuggestions가 이러한 2개의 값들의 교차가 된다. 교차가 존재하지 않으면, 피-협상자는 단지 2개의 OfferedSuggestions 값들(하나는 협상자 A에 대한 것이고, 다른 하나는 협상자 B에 대한 것임)을 단순히 제안할 수 있다.

교차가 존재하지 않으면, 피-협상자는 이러한 2개의 제출된 OfferedSuggestions 중 하나를 취하여 양쪽 협상자들에게 전송할 수 있다. 교차가 존재하지 않으면, 2개의 OfferedSuggestions의 교차가 다음 번에 잠재적으로 도달될 수 있도록 그들의 다음 번 협상 요청을 변경하라고 피-협상자가 양쪽 협상자들에게 통지할 수 있다.

대안적으로, 피-협상자는 협상자 A 및 협상자 B 양자 모두에 적용 가능한 정책들의 위치를 먼저 찾을 수 있다. 다음으로, 도 7에서의 동일한 프로시저에 따라 이러한 정책들에 기초하여 제안들을 행한다. 협상자 A 및 협상자 B에 대한 OfferedSuggestions은 피-협상자가 OfferedSuggestions를 결정하는데 사용하는 정책들에 의존하여 상이할 수 있다.

단계 3A에서, 피-협상자는 협상자 A에게 "협상 응답"을 전송한다. 단계 3B에서, 피-협상자는 협상자 B에게 "협상 응답"을 전송한다.

단계 4A에서, 협상자 A는 단계 3A에서의 OfferedSuggestions로부터 제안들을 선택한다. 단계 4B에서, 협상자 B는 단계 3B에서의 OfferedSuggestions로부터 제안들을 선택한다. 단계 5A에서, 협상자 A는 피-협상자에게 "협상 확인"을 전송한다. 단계 5B에서 협상자 B는 피-협상자에게 "협상 확인"을 전송한다. 단계 6A에서, 피-협상자는 협상자 A에게 "수신확인"을 전송한다. 단계 6B에서, 피-협상자는 협상자 B에게 "수신확인"을 전송한다.

브로커-기반 서비스 협상

제안을 행하거나 또는 제안들을 선택하는 프로세스는 제한된 M2M 디바이스들에 대해 너무 무거울 수 있다. 이러한 쟁점을 해결하기 위해, 피-협상자를 대신하여 제안을 행하거나 협상자를 대신하여 제안들을 선택하는데 협상 브로커가 도움이 되는 브로커 기반 서비스 협상이 설명된다. 협상 브로커는 한 브로커에서 다른 브로커로 위임될 수도 있다. 도 10 및 도 11에 따르면, 협상 브로커가 취급할 수 있는 협상 가능 서비스들의 리스트에 관한 자동 통지를 협상자가 얻을 수 있도록, 도 6에 도시되는 바와 같은 단계 0-1 및 단계 0-2가 협상자와 협상 브로커 사이에 사용될 수 있다.

투명 모드에서, 협상 브로커는 제안들을 행하거나 또는 제안들을 선택하지 않고, 협상자가 적절한 피-협상자를 찾도록 돕는다, 예를 들어, 그 리스트가 요청에 적합한 피-협상자에게 또는 부하가 가벼운 피-협상자에게 요청을 전달하고, 협상자와 피-협상자 사이에 협상 관련 메시지들을 간단히 전달한다. 다음 단계들이 도 10에 도시되는 바와 같이 도입된다.

단계 1에서, 피-협상자는 협상 브로커에게 "협상 요청들에 대한 가입"을 전송한다. 메시지는 기본적으로 협상자 브로커에게 ServiceID로 나타나는 서비스들에 대해 피-협상자가 협상을 수행할 수 있다는 점을 알린다. 단계 2: 협상 브로커는 피-협상자에게 "응답"을 전송한다. 각각의 서비스에 대해, 협상 브로커는 서비스에 관심이 있고 이에 대해 협상들을 제공할 수 있는 피-협상자들의 리스트를 유지할 것이다. 다음으로 단계 3에서, 협상자가 협상 브로커에게 "협상 요청"을 전송한다. 이러한 단계는 도 6에서의 단계 1과 동일하다. 단계 4에서, 협상 브로커는 수신되는 "협상 요청"에 대한 적절한 피-협상자들을 찾는데 "협상 요청"에 포함되는 "ServiceID"를 사용한다.

단계 5에 따르면, 협상 브로커는 대응하는 피-협상자에게 단계 1에서의 가입에 대한 응답으로서 "통지"를 전송한다. 이러한 통지는 실제로 "협상 요청"을 전달하는 것이다. 단계 6에서, 피-협상자는 제안들을 행한다. 또한 단계 7에서, 피-협상자는 협상 브로커를 통해 협상자에게 "협상 응답"을 전송한다. 일 실시예에서, 협상 브로커는 제출된 제안들을 협상자에 의해 설정되는 미리 구성된 정책들에 대해 점검한다.

협상자는 단계 8에서 제안들을 선택한다. 단계 9에서, 협상자는 협상 브로커를 통해 피-협상자에게 "협상 확인"을 전송한다. 단계 10에서, 피-협상자는 협상 브로커를 통해 협상자에게 "수신확인"을 전송한다.

다수의 피-협상자들이 존재할 수 있기 때문에 단계 1 및 단계 2는 1회 이상 발생할 수 있다. 단계 1 및 2 각각의 세트는 개별 피-협상자를 위한 것이다. 다수의 피-협상자들이 존재할 수 있기 때문에 단계 5, 단계 6, 및 단계 7가 1회 이상 발생할 수 있다. 단계 5, 단계 6, 및 단계 7의 각각의 세트는 개별 피-협상자를 위한 것이다.

다른 실시예에 따르면, 도 11은 협상 브로커가 피-협상자를 위한 프록시 역할을 하는 시나리오를 도시한다. 단계 1에서, 피-협상자는 협상 브로커에게 "협상 프록시 요청"을 전송한다. 피-협상자는 이러한 단계에서 자신의 협상 정책들을 협상 브로커에게 전달할 수 있다. 피-협상자는 자신의 협상 브로커에서 자신의 협상 정책들을 생성하는데 별도의 프로시저들을 사용할 수 있다.

단계 2에서, 협상 브로커는 피-협상자에게 "협상 프록시 응답"을 전송한다. 이러한 단계는 생략될 수 있으며 단계 9는 피-협상자에 대한 최종 응답일 것이라는 점에 주목하자. 피-협상자가 협상 브로커에 이미 등록되었거나, 이와 관련되었으면, 단계 1 및 단계 2가 필요하지 않을 수 있으며, 디폴트로, 협상 브로커는 피-협상자를 위한 프록시 기능들을 수행할 것이다. 단계 1 및 단계 2는 피-협상자와 협상 브로커 사이의 발견 및 관련 단계들에 의해 선행될 수 있다. 관련 단계의 일부로서, 협상 브로커 및 피-협상자는 이후 단계들에서 인증을 위해 사용될 수 있는 인증 자격 증명들을 공급받거나, 또는 도출할 수 있다.

다음으로, 단계 3에서, 협상자는 협상 브로커에게 "협상 요청"을 전송한다. 이러한 단계는 도 6에서의 단계 1과 동일하다. "협상 요청" 메시지를 전송하기 이전에 협상 브로커에 의해 협상자가 인증될 수 있거나 또는 대안적으로, 협상자와 피-협상자는 수립된 자격 증명들에 기초하여 서로를 상호 인증할 수 있다. 대안적으로, 인증/상호 인증은 "협상 요청" 단계 동안 수행될 수 있으며, 여기서 올바른 자격 증명의 소유는 암호화 프로시저들을 사용하여 "협상 요청" 메시지의 일부로서 검증된다.

단계 4에서, 협상 브로커는 단계 1에서 전송된 협상 정책들에 따라 피-협상자를 대신하여 제안을 행한다. 이러한 단계는 도 6에서의 단계 2와 동일하다. 단계 5에서, 협상 브로커가 협상자에게 "협상 응답"을 전송한다. 이러한 단계는 도 6에서의 단계 3과 동일하다. 협상자가 단계 5에 포함되는 OfferedSuggestions에 만족하지 못하면, 단계 3, 단계 4 및 단계 5가 반복될 수 있다.

단계 6에 따르면, 협상자는 적절한 제안들을 선택한다. 이러한 단계는 도 6에서의 단계 4와 동일하다. 단계 7에서, 협상자는 협상 브로커에게 "협상 확인"을 전송한다. 이러한 단계는 도 6에서의 단계 5와 동일하다. 단계 8에서, 협상 브로커가 협상자에게 "수신확인"을 전송한다. 이러한 단계는 도 6에서의 단계 6과 동일하다. 다음으로, 단계 9에서, 협상 브로커는 피-협상자에게 "협상 통지"를 전송한다. 이러한 메시지에는 다음 정보를 포함할 수 있다: (i) 협상자의 명칭 또는 식별자; (ii) 협상중인 서비스들의 명칭, 식별자 및/또는 설명; 및 (iii) 협상자에 의해 선택된 제안. 또한 단계 10에서, 피-협상자는 협상 브로커에게 "수신확인"을 전송한다.

다수의 피-협상자들이 존재할 수 있기 때문에 단계 1 및 단계 2는 여러 번 발생될 수 있다는 점이 주목된다. 단계 1 및 단계 2의 각각의 세트는 개별 피-협상자를 위한 것이다. 또한 다수의 피-협상자들이 존재할 수 있기 때문에 단계 9 및 단계 10이 여러 번 발생될 수 있다. 단계 9 및 단계 10의 각각의 세트는 개별 피-협상자를 위한 것이다.

다른 실시예에 따르면, 도 12는 협상 브로커가 협상자를 위한 프록시 역할을 하는 시나리오를 도시하며, 여기서 인증 및 승인 기능들이 관련된 엔티티들에 추가된다. 단계 1에서, 협상자는 협상 브로커에게 "협상 프록시 요청"을 전송한다. 협상자는 이러한 단계에서 협상 정책들을 자신의 협상 브로커에게 전달할 수 있다. 협상자는 별도의 프로시저들을 사용하여 자신의 협상 브로커에서 자신의 협상 정책들을 생성할 수 있다. 협상자는 인증, 승인 및 보안 통신을 가능하게 하기 위해 특정 보안 메커니즘들 및 기능들을 요청할 수 있다. 대안적으로, 보안 기능들을 설정하기 요청은 단계 2에서 협상 브로커에 의해 수행될 수 있다. 협상 요청은 보안 통신 채널을 통해 전송될 수 있다.

단계 2에서, 협상 브로커는 협상자에게 "협상 프록시 응답"을 전송한다. 이러한 단계는 생략될 수 있으며 단계 10이 협상자에 대한 최종 응답일 것이라는 점에 주목하자. 협상자가 협상 브로커에 이미 등록되었거나, 이와 관련되었으면, 단계 1 및 단계 2가 필요하지 않을 수 있으며, 디폴트로, 협상 브로커는 협상자를 위한 프록시 기능들을 수행할 것이다.

단계 3에서, 협상자는 협상 브로커에게 "협상 요청"을 전송한다. 이러한 단계는 도 6에서의 단계 1과 유사하다. 또한, 협상자와 협상 브로커는 서로를 상호 인증할 수 있다. 선택적으로, 협상 요청 메시지의 일부로서, 협상자는 피-협상자 또는 제3자 엔티티에 의해 협상자에게 공급된 세션 기반 승인 파라미터들을 전송할 수 있다.

단계 4: 협상 브로커는 승인 파라미터들과 함께 협상 요청을 피-협상자에게 전송한다. 피-협상자의 관점에서 볼 때, 이러한 메시지는 협상 브로커로부터의 것이라고 느껴진다. 단계 5에서, 피-협상자가 승인 파라미터들을 검증하는 것에 기초하여, 피-협상자는 다음으로 제안들을 행한다. 이러한 단계는 도 6에서의 단계 2와 유사하다. 단계 6은 도 6에서의 단계 3과 유사하다. 협상자 브로커가 단계 6에 포함되는 OfferedSuggestions에 만족하지 못하면, 단계 4, 단계 5 및 단계 6이 반복될 수 있다.

단계 7에 따르면, 협상자 브로커는 적절한 제안들을 선택한다. 이러한 단계는 도 6에서의 단계 4와 유사하다. 단계 8에서, 협상 브로커는 "협상 확인"을 피-협상자에게 전송한다. 이러한 단계는 도 6에서의 단계 5와 유사하다. 그 후 단계 9에서, 피-협상자는 협상 브로커에게 "수신확인"을 전송한다. 이러한 단계는 도 6에서의 단계 6과 동일하다. 다음으로 단계 10에서, 협상 브로커는 협상자에게 "협상 응답"을 전송한다. 이러한 메시지는 도 6에서의 단계 3과 유사하다. 또한 단계 11에서, 협상자는 협상 브로커에게 "수신확인"을 전송한다. 위에 설명된 보안 메커니즘들(인증, 승인 및 보안 통신) 및 기능들은 제3자 신뢰가 요구될 수 있는 다른 실시예들에 대해 사용되고 적용될 수 있다.

도 13에 도시되는 바와 같은 추가의 실시예에 따르면, 협상 브로커는 다수의 협상 요청들을 조합할 수 있고, 조합된 협상 요청을 피-협상자에게 전송하여 협상 효율을 향상시킨다. 도 13은 두 협상자들을 도시하지만, 협상 브로커는 둘보다 많은 협상자들로부터의 협상 요청들을 조합할 수 있다. 도 13은 협상자들과 협상 브로커 사이의 "협상 프록시 요청 & 응답"을 도시하지 않으며, 이는 실제로 도 12와 동일하다는 점에 주목하자. 이하의 단계들은 도 13에 대해 설명된다.

단계 1에서, 협상자 A 및 B가 각각 협상 브로커에게 협상 요청을 전송한다. 단계 2에서, 협상 브로커는 조합된 새로운 협상 요청에 양자 모두를 집어넣는 것에 의해 이러한 2개의 협상 요청들을 조합하며, 이는 피-협상자에게 전송된다. 단계 3에서, 피-협상자가 제안들을 행한다. 이러한 단계는 도 6에서의 단계 2와 유사하다. 단계 4에서, 피-협상자는 협상 브로커에게 "협상 응답"을 전송한다. 이러한 단계는 도 6에서의 단계 3과 유사하다. 다음으로 단계 5에서, 협상 브로커는 양쪽 협상자들을 대신하여 제안들을 선택한다. 이러한 단계는 도 6에서의 단계 4와 동일하다. 후속하여 단계 6에서, 협상 브로커는 "협상 확인"을 피-협상자에게 전송한다. 이러한 단계는 도 6에서의 단계 5와 유사하다.

단계 7에서, 피-협상자는 협상 브로커에게 "수신확인"을 전송한다. 이러한 단계는 도 6에서의 단계 6과 동일하다. 단계 8에 따르면, 협상 브로커는 2개의 "협상 응답"을 협상자 A와 B에게 각각 전송한다. 이러한 단계는 도 6에서의 단계 10과 동일하다. 다음으로 단계 9에서, 협상자 A 및 B는 각각 협상 브로커에게 "수신확인"을 전송한다. 이러한 단계는 도 6에서의 단계 11과 유사하다. 도 13이 다수의 피-협상자들을 도시하지는 않지만, 단계 2 내지 단계 7은 협상 브로커와 다른 피-협상자 사이의 상호작용들에 적용될 수 있다.

다른 실시예에 따르면, 협상 브로커는 과부하가 될 수 있고, 결국 다른 협상 브로커에 자신의 기능들을 위임할 수 있다. 이러한 브로커 위임은 협상자/피-협상자에 의해 착수될 수 있거나(현재의 협상 브로커가 위임될 필요가 있다는 것을 협상자/피-협상자가 알 수 있고/있거나 새로운 협상 브로커를 결정할 수 있는 경우) 또는 현재의 협상 브로커에 의해 능동적으로 착수될 수 있다. 도 14는 현재의 협상 브로커 A로부터 새로운 협상 브로커 B로의 브로커 위임에 대한 프로시저들을 도시한다.

단계 1에 따르면, 협상자(또는 피-협상자)는 현재의 협상 브로커 A에게 "브로커 위임 요청"을 전송한다. 이러한 메시지는 이에 제한되는 것은 아니지만 새로운 협상 브로커 B의 어드레스, 명칭, 및/또는 식별자를 포함할 수 있다. 대안적으로, 현재의 협상 브로커 A는 협상자/피-협상자를 위한 새로운 협상 브로커를 선택할 수 있다. 브로커 위임이 현재의 협상 브로커 A에 의해 능동적으로 트리거되면, 이러한 단계는 선택적이다.

단계 2에서, 현재의 협상 브로커 A는 새로운 협상 브로커 B에게 "브로커 위임 요청"을 전송한다. 이러한 메시지는 이에 제한되는 것은 아니지만 다음과 같은 정보: 협상자/피-협상자의 어드레스, 명칭, 및 식별자. 현재의 협상 브로커 A가 협상자/피-협상자에 대한 합법적 브로커인지 검증하는데 사용될 수 있는 인증 정보. 새로운 협상 브로커 B가 협상자/피-협상자에 대해 유효하게 되는 시작 시간. 새로운 협상 브로커 B가 협상자/피-협상자의 브로커 역할을 하는 기간을 포함할 수 있다.

단계 3에서, 새로운 협상 브로커 B는 현재의 협상 브로커 A에게 "브로커 위임 응답"을 전송한다. 새로운 협상 브로커 B가 위임 요청을 거절하면, 다음의 단계 4 및 단계 5는 생략될 것이고, 브로커 위임은 실패다. 단계 4에 따르면, 현재의 협상 브로커 A는 새로운 협상 브로커 B에게 "협상 컨텍스트 이송"을 전송한다. 이러한 메시지는 협상자/피-협상자를 위한 협상 정책들과 같은 필요한 컨텍스트 정보를 새로운 협상 브로커 B에 이송하는데 사용된다. 단계 5에 따르면, 새로운 협상 브로커 B는 현재의 협상 브로커 A에게 "협상 컨텍스트 응답"을 전송한다.

다음으로 단계 6에서, 현재의 협상 브로커 A는 협상자/피-협상자에게 "브로커 위임 응답"을 전송한다. 이러한 메시지는 다음과 같은 정보: 새로운 협상 브로커 B의 어드레스, 명칭, 및/또는 식별자. 새로운 협상 브로커 B가 협상자/피-협상자를 위한 역할을 할 시작 시간 및 지속기간을 포함할 수 있다. 또한 단계 7에서, 협상자/피-협상자는 새로운 협상 브로커 B와 서비스 협상을 수행하기 위해 설명된 것과 유사한 프로시저들을 사용한다.

또 다른 실시예에 따르면, 협상자가 서비스 협상 프로세스를 착수하는 다양한 트리거들이 설명된다. 예를 들어, M2M 디바이스가 증가된 데이터 볼륨들을 생성하기 시작할 때, 이는 모든 데이터를 로컬에 저장하지 못할 수 있고, 이는 더 많은 스토리지를 얻기 위해 자신의 M2M 서버와의 협상 프로세스를 착수할 수 있다. M2M 디바이스가 데이터를 업로드하는 속도를 증가시켜야 한다고 확인하면, 저장된 데이터에 대한 보다 빈번한 작업들을 요청하기 위해 M2M 서버와 다시 협상할 수 있다.

새로운 M2M 디바이스들이 시스템에 추가될 때, 디바이스 관리를 위한 M2M 애플리케이션은 더 많은 M2M 디바이스들을 관리하라고 요청하기 위해 자신의 M2M 서버와 협상을 시작할 수 있다. M2M 애플리케이션은 자기 자신과 다른 M2M 애플리케이션 사이의 엔드-투-엔드 지연이 증가했음을 확인한다. 예시적인 실시예에서, 통신은 M2M 서버에 의해 중계된다. M2M 애플리케이션은 M2M 서버에서 자신의 요청 메시지를 버퍼링하는 시간을 감소시키기 위해 M2M 서버와의 서비스 협상을 착수하기를 원할 수 있다.

협상 가능 서비스들

oneM2M 아키텍처의 컨텍스트에서, 어느 M2M 서비스들이 그리고 어떠한 방식으로 협상될 수 있는지 설명하는 예들 개시된다. 기본적으로 서비스 협상의 2개 레벨들이 존재한다:

레벨-1에서는, M2M 디바이스가 자신이 사용할 필요가 있는 원하는 CSF들에 관하여 M2M 서버와 협상한다. 달리 말하면, M2M 디바이스는 M2M 서버에 의해 제공되는 CSF들의 서브세트를 사용할 것을 요청할 수 있다. 레벨-1 서비스 협상을 위해, 도 15에 도시되는 바와 같은 16비트 CSF 비트맵은, 자신의 선호도를 표시하기 위해 M2M 디바이스에 의해, 그리고 승인된 CSF들을 표시하기 위해 M2M 서버에 의해 영향을 받을 수 있다. 각각의 비트는 CSF를 나타내며 마지막 4비트는 미래 사용을 위해 예약된다. REG CSF는 다른 CSF들을 사용하기 위해 M2M 디바이스가 선택해야 하는 디폴트 CSF라는 점에 주목하자.

레벨-2에서는, M2M 디바이스가 각각의 개별 CSF의 특징들 또는 기능들에 관하여 M2M 서버와 또한 협상할 수 있다. 레벨-2 서비스 협상을 위해, 각각의 CSF는 협상될 수 있는 상이한 특징들 및 기능들을 갖는다. 예를 들어, M2M 디바이스는 M2M 서버에 의해 제공되는 모든 DM 기능들을 사용할 필요가 없을 수 있기 때문에 원하는 DMG 기능들에 관하여 M2M 서버와 협상할 수 있다. 더 많은 예들 및 상세사항들이 표 3에 주어진다. CSF 비트맵의 예와 유사하게, 도 16은 CSF가 M개의 특징들을 갖고 M비트를 필요로 한다고 가정할 때 CSF의 각각의 특징, 예를 들어, F1, F2가 하나의 비트에 의해 표현되는 CSF 특징 비트맵의 예를 도시한다.

시나리오 1에서, M2M 디바이스가 더 많은 데이터를 생성할 때, 더 많은 스토리지를 얻기 위해 M2M 서버와의 협상 프로세스를 착수할 수 있다. 나중에, 데이터가 너무 빠르게 변경되고 더 빈번한 데이터 업데이팅을 필요로 한다고 M2M 디바이스가 결정하면, 저장된 데이터 상의 보다 빈번한 작업들을 요청하기 위해 M2M 서버와 다시 협상할 수 있다.

새로운 CSF : NGS (negotiation service)

도 17은 제시된 협상 서비스를 현재의 oneM2M 기능적 아키텍처에 기초하여 새로운 CSF로서 구현하기 위한 예시적인 실시예를 도시한다. 대안적으로, 디바이스 부트스트랩, 디바이스 펌웨어 업로드 등 동안 발생할 수 있거나 요구될 수 있는 디바이스 관리 관련 협상들을 수행하기 위해 일부 NGS 기능들이 DMG CSF의 일부로서 추가될 수 있다.

일 실시예에서, NGS 기능은 M2M 서버, M2M 게이트웨이, 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅되는 M2M 서비스 레이어 인스턴스 내에서 호스팅될 수 있다. 예를 들어, NGS는 개별 서비스 능력을 M2M 서비스 레이어 인스턴스 내에 또는 기존 서비스 능력 내의 서브-기능으로서 포함할 수 있다.

도 18의 실시예에 도시되는 바와 같이, 제시되는 NGS CSF는 MN-CSE, ASN-CSE, 또는 IN-CSE 내에 존재할 수 있다. NGS CSF는 위에서 설명되는 바와 같이 협상자, 협상 브로커 및/또는 피-협상자의 기능성들을 갖는다. 서비스 협상은 다음과 같은 방식들로 수행될 수 있다.

MN-CSE가 IN-CSE와 서비스들을 직접 협상하면, MN-CSE의 NGS는 제안들을 선택하는 협상자일 것이며, IN-CSE의 NGS는 제안들을 행하는 피-협상자일 것이다. MN-CSE가 IN-CSE를 통해 ASN-CSE와 서비스들을 간접적으로 협상하면, MN-CSE의 NGS는 제안들을 선택하는 협상자일 것이다. 또한, IN-CSE의 NGS는 투명 모드에서의 협상 브로커일 것이다. 또한, ASN-CSE의 NGS는 제안들을 행하는 피-협상자일 것이다.

IN-AE1이 IN-CSE를 통해 MN-CSE와 서비스들을 간접적으로 협상하면, IN-AE1은 협상자일 것이고, IN-CSE의 NGS는 제안들을 선택하는 IN-AE1의 협상 브로커일 것이며, ASN-CSE의 NGS는 제안들을 행하는 피-협상자일 것이다.

IN-AE2가 IN-CSE를 통해 IN-AE1과 서비스들을 간접적으로 협상하면, IN-AE2는 협상자일 것이고, IN-CSE의 NGS는 IN-AE1 및 IN-AE1 양자 모두가 제안들을 행하고 제안들을 선택하는 협상 브로커일 것이며, IN-AE1은 피-협상자일 것이다.

도 19는 ASN-CSE가 중간에 있는 MN-CSE를 통해 IN-CSE와 서비스들을 협상하는 다른 예시적인 실시예를 도시한다. ASN-CSE의 NGS는 협상자일 것이고, MN-CSE의 NGS는 협상 브로커일 것이며, IN-CSE의 NGS는 피-협상자일 것이다.

NGS CSF를 지원하는 새로운 리소스들 /속성들

다른 실시예에서, NGS CSF 서비스를 지원하는 oneM2M 리소스 구조 개선들이 제시된다. 리소스 구조들을 설명하기 위한 OneM2M 정의 그래픽 표현은 다음과 같다: (i) 사각형 상자들은 리소스들 및 자식 리소스들에 대해 사용되고; (ii) 둥근 모서리들이 있는 사각형 상자들은 속성들에 대해 사용되며; (iii) 새로운 리소스는 <ngtn>이다.

<ngtn> 리소스는 M2M 엔티티가 협상 요청을 발행하고 협상 응답을 수신/검색하는 것에 대해 정의된다. 각각의 <ngtn> 리소스는 2개의 M2M 엔티티들 사이의 구체적인 협상 요청 또는 응답에 대응한다. 이는 도 6에 도시되는 바와 같이 협상 요청 및 협상 응답 메시지에 포함되는 정보 또는 파라미터들을 유지한다.

<ngtn>은 도 20 및 표 4에 도시되는 바와 같이 몇몇 속성들 및 서브-리소스들을 갖는다. <ngtn>의 부모 리소스는 <AE>, <CSEBase>, 및/또는 <remoteCSE>일 수 있다. 예를 들어, IN-AE는 자신의 호스팅 CSE와 협상을 착수하기 위해, 자신의 호스팅 CSE, 예를 들어, M2M 서버 상의 자신의 <AE> 아래에 <ngtn> 리소스를 생성한다.

예를 들어, MN-CSE는, 자신의 호스팅 CSE와 협상을 착수하기 위해, 자신의 호스팅 CSE, 예를 들어, M2M 서버 상의 자신의 <remoteCSE> 아래에 <ngtn> 리소스를 생성한다.

대안적으로, IN-CSE 및 IN-AE로부터의 협상 요청들은 모두 그들의 호스팅 CSE 바로 아래에 생성될 수 있다. 이러한 경우에, <ngtn>은 호스팅 CSE의 <CSEBase> 서브-리소스로서 생성될 것이다.

또 다른 실시예에 따르면, <ngtnPolicy>라 불리우는 새로운 리소스, 예를 들어 협상 정책은, 1) 피-협상자(또는 그 브로커)가 정책에 기초하여 제안들을 행하는 방법을 특정하는데, 또는 2) 협상자(또는 그 브로커)가 정책에 기초하여 제안들을 선택하는 방법을 특정하는데 사용된다. 달리 말하면, 2개 타입의 정책들: 1) 제안들을 행하기 위한 정책들 및 2) 제안들을 선택하기 위한 정책들이 존재한다. 각각의 협상 정책은 적어도 2가지 정보: Conditions 및 Results를 포함할 필요가 있다. 즉, "Conditions"가 충족되면 "Results"가 정책의 출력일 것이다. 2개 타입들의 정책들이 존재하기 때문에, "Results"는: 1) 피-협상자 또는 그 브로커에 의해 행해질 제안들; 또는 2) 협상자 또는 그 브로커에 의해 선택될 제안들일 수 있다.

<ngtnPolicy> 리소스는 도 21 및 아래의 표 5에 도시되는 바와 같이 몇몇 속성들 및 서브-리소스를 갖는다. <ngtnPolicy>의 부모 리소스는 <AE>, <CSEBase>, 및/또는 <remoteCSE>일 수 있다. <AE>, <CSEBase>, 및 <remoteCSE>는 전부 참조로 원용되는 2014년 8월자 oneM2M-TS-0001, oneM2M Functional Architecture-V1.1.0에 설명되는 것에 정의된다는 점에 주목하자.

도 22 및 아래의 표 6에 도시되는 바와 같이 또 다른 실시예에 따르면, '협상 리소스'라 불리우는 새로운 리소스, 예를 들어, <ngtnDelegation)>이 본 출원에서 위에 설명된 바와 같은 협상 위임 브로커 기능을 지원하도록 제시된다. 각각의 <ngtnDelegation>은 협상 브로커 위임 요청에 대응한다. 이는 <AE>, <remoteCSE>, 또는 <CSEBase> 리소스의 서브-리소스일 수 있다.

새로운 속성 'ngtnBroker'는 <AE> 또는 <remoteCSE> 리소스의 새로운 속성으로서 제시된다. <AE>, <CSEBase> 및 <remoteCSE>는 전부 참조로 원용되는 2014년 8월자 oneM2M-TS-0001, oneM2M Functional Architecture-V1.1.0에 설명되는 것에 정의된다는 점에 주목하자. ngtnBroker가 <AE> 리소스의 속성이면, 이는 <AE>의 협상 브로커들을 표시한다. ngtnBroker가 <remoteCSE> 리소스의 속성이면, 이는 <remoteCSE>의 협상 브로커들을 표시한다.

CsfBitMap은 <AE>, <CSEBase> 또는 <remoteCSE> 리소스의 새로운 속성으로서 제시된다. <AE>, <CSEBase> 및 <remoteCSE>는 전부 참조로 원용되는 2014년 8월자 oneM2M-TS-0001, oneM2M Functional Architecture-V1.1.0에 설명된다는 점에 주목하자. csfBitMap이 <AE> 리소스의 속성이면, 이는 <AE>가 사용할 것을 요청하는 CSF들의 리스트, 및/또는 <AE>의 호스팅 CSE에 의해 승인된 CSF들의 리스트를 의미한다. AE가 자신의 호스팅 CSE에 자신을 등록할 때, AE는 자신의 원하는 CSF들을 표시하기 위해 애플리케이션 등록 요청 메시지에 csfBitMap을 포함할 수 있고; 결국, 호스팅 CSE는 AE에 할당되는 승인된 CSF들을 표시하기 위해 승인된 csfBitMap을 다시 반환할 수 있다.

csfBitMap이 <remoteCSE> 리소스의 속성이면, 이는 <remoteCSE>가 사용할 것을 요청하는 CSF들의 리스트, 및/또는 <remoteCSE>의 호스팅 CSE에 의해 승인된 CSF들의 리스트를 의미한다. CSE가 자신의 호스팅 CSE에 자신을 등록할 때, CSE는 자신의 원하는 CSF들을 표시하기 위해 CSE 등록 요청 메시지에 csfBitMap을 포함할 수 있고; 결국, 호스팅 CSE는 CSE에 할당되는 승인된 CSF들을 표시하기 위해 승인된 csfBitMap을 다시 반환할 수 있다. csfBitMap이 <CSEBase>의 속성이면, 이는 이러한 CSE가 소유하는 CSF들의 리스트를 의미한다.

NGS CSF를 지원하는 리소스 프로시저들

아래 표 9에 제공되는 프로토콜들은 <ngtn> 리소스를 생성하기 위해 이용된다. 특히, 이러한 프로시저는 호스팅 CSE에서 구체적인 <ngtn> 리소스를 생성하는데 사용될 것이다.

또한, 표 10에서의 프로토콜들은 기존의 <ngtn> 리소스로부터 정보를 검색하는데 사용될 것이다.

표 11에서의 아래의 프로토콜들은 기존의 <ngtn> 리소스의 정보를 업데이트하는데 이용된다.

아래의 표 12에 제공되는 프로토콜들은 기존의 <ngtn> 리소스를 삭제하는데 사용될 것이다.

아래 표 13에 제공된 프로토콜은 호스팅 CSE에서 보류중인 협상 요청 <ngtn>을 실행하는데 사용된다.

아래 표 14에 제공되는 프로토콜은 호스팅 CSE에서 구체적인 <ngtnPolicy> 리소스를 생성하는데 사용될 것이다.

아래 표 15에 제공되는 프로시저는 기존의 <ngtnPolicy> 리소스로부터 정보를 검색하는데 사용될 것이다.

아래 표 16에 제공되는 프로시저는 기존의 <ngtnPolicy> 리소스의 정보를 업데이트하는데 사용될 것이다.

아래 표 17에서의 프로토콜은 기존의 <ngtnPolicy> 리소스를 삭제하는데 사용될 것이다.

아래 표 18에서의 프로시저는 호스팅 CSE에서 구체적인 <ngtnDelegation> 리소스를 생성하는데 사용될 것이다.

아래 표 19에서의 프로토콜은 기존의 <ngtnDelegation> 리소스로부터 정보를 검색하는데 사용될 것이다.

아래 표 20에서의 프로토콜들은 기존의 <ngtnDelegation> 리소스의 정보를 업데이트하는데 사용될 것이다.

아래 표 21에서의 프로토콜들은 기존의 <ngtnDelegation> 리소스를 삭제하는데 사용될 것이다.

아래 표 22에서의 프로토콜들은 호스팅 CSE 상의 계류중인 협상 브로커 위임 요청 <ngtnDelegation>을 실행하는데 사용될 것이다.

도 23은 위에 설명된 제시된 프로시저들을 사용하는 서비스 협상의 예를 도시한다. 각각의 단계는 로마 숫자 포맷, 예를 들어, 001, 002 등으로 제공된다. 여기서, MN-CSE는 협상자이고 IN-CSE는 피-협상자이다. 단계 1에 따르면, MN-CSE는 CREATE 요청을 발행한다. 이것은 도 6에서의 단계 1과 유사하다. 다음으로 단계 2에서, IN-CSE는 CREATE 요청을 처리한다. 다음으로 단계 3에서, IN-CSE는 MN-CSE에 CREATE 응답을 전송한다. 그 후, 단계 4에서, MN-CSE는 위에 설명된 바와 같이 생성된 <ngtn>을 실행하라는 특별한 UPDATE 요청을 발행한다. 이것은 도 6에서의 단계 1과 유사하다. 후속하여 단계 5에서, IN-CSE는 제안들을 행하라는 UPDATE 요청을 처리한다. 이것은 도 6에서의 단계 2와 유사하다.

IN-CSE는 단계 6에서 MN-CSE에 UPDATE 응답을 전송한다. 이것은 도 6에서의 단계 3과 유사하다. 단계 7에서, MN-CSE는 적절한 제안들을 선택하라는 UPDATE 응답을 처리한다. 이것은 도 6에서의 단계 4와 유사하다. 다음으로 단계 8에서, MN-CSE는 위에 설명된 바와 같이 <ngtn>/선택된 제안들을 업데이트하라는 정상적인 UPDATE 요청을 발행한다. 이것은 도 6에서의 단계 5와 유사하다. 다음으로 단계 9에서, IN-CSE는 선택된 제안들을 확인하라는 UPDATE 요청을 처리한다. 또한, 단계 10에서: IN-CSE는 MN-CSE에 UPDATE 응답을 전송한다. 이것은 도 6에서의 단계 6과 유사하다.

도 24는 전부 참조로 원용되는 oneM2M-TS-0007, oneM2M Service Component Architecture-V-0.4.0에서 제시되는 바와 같이 oneM2M SoA 아키텍처에서 제시되는 협상 서비스의 실시예를 도시하며, 여기서 협상 서비스는 새로운 서비스 컴포넌트로서 삽입된다. 다른 서비스 컴포넌트들은 Msc 참조 점을 통해 협상 서비스와 통신할 수 있다. NGS는 Mca 참조 점에 적용될 수 있으며, 본 개시내용에서 제시되는 데이터 구조 및 메시지들은 SOA 아키텍처에도 마찬가지로 적용될 수 있다는 점에 주목하자.

본 출원에 따른 적용 가능한 사용 경우에서, M2M 서비스 오퍼레이터, 예를 들어, AT&T는 다양한 M2M 서버들로 구성되는 스마트 이송 M2M 서비스 플랫폼을 배치한다. 각각의 M2M 서버는 디바이스 관리를 위한 DMG와 같은 서비스들의 묶음을 제공한다. 자동차 대여 회사, 예를 들어, Hertz는 이러한 플랫폼을 사용하여 자신의 차량들을 관리하여 왔다. 이제, 이러한 자동차 회사는 더 많은 새로운 하이브리드 자동차들을 시장에 투입하기를 원한다. 새로운 하이브리드 자동차는 디바이스 관리 관점에서 더 많은 진단 및 모니터링 기능을 필요로 한다. 이러한 새로운 요건과 관리될 새로운 자동차들의 수로 인하여, 자동차 회사의 M2M 애플리케이션은 오퍼레이터와 함께 원하는 DMG 기능성들, 예를 들어, 이러한 새로운 자동차들에 대한 보다 고급의 진단 기능, 그룹 디바이스 관리, 보다 빈번한 위치 업데이트들 등에 관하여 협상한다.

다른 사용 경우에서, M2M 서비스 오퍼레이터, 예를 들어, 구글(Google)은, 클라우드에서의 M2M 서버들 및 고객의 집에서의 M2M 게이트웨이, 예를 들어, 구글의 NEST로 구성되는 스마트 홈 M2M 서비스 플랫폼을 배치한다. M2M 서버와 M2M 게이트웨이 양자 모두는 데이터 관리를 위한 DMR과 같은 서비스들의 묶음을 제공한다. 고객은, 예를 들어, 집에 설치된 카메라들로부터, 로컬로 센서 데이터를 저장하는데 M2M 게이트웨이를 사용하였다. 이제는 여름 시간이며 고객은 여행을 계획하고 집을 한 달 동안 떠날 것이다. 고객은 스마트 폰을 통해 이전보다 더 빈번히 카메라 데이터를 액세스할 필요가 있다. 카메라가 임의의 이상을 검출하면 고객은 오퍼레이터의 서비스 플랫폼으로부터 자동 통지를 수신하기를 또한 원한다. 고객의 스마트폰 상의 M2M 애플리케이션은, 그의 새로운 필요성을 충족시키기 위해, 집안의 M2M 게이트웨이에서의 것 대신에 클라우드에서의 카메라 데이터를 저장/분석할지 및 그 방법에 관해 오퍼레이터 서비스 플랫폼과 협상한다. NGS의 기능성은 M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어의 형태(즉, 컴퓨터 실행 가능한 명령어들)로 구현될 수 있다는 점이 이해된다.

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

본 출원의 또 다른 양상에 따르면, 컴퓨터 판독 가능 또는 실행 가능 명령어들을 저장하기 위한 비-일시적 컴퓨터 판독 가능 또는 실행 가능 저장 매체가 개시된다. 이러한 매체는 도 6 내지 도 14 및 도 23에 따른 복수의 호출 흐름들에 위에 개시된 것과 같은 하나 이상의 컴퓨터 실행 가능 명령어들을 포함할 수 있다. 이러한 컴퓨터 실행가능 명령어들은 도 4c 및 도 4d에서 위에 개시된 메모리에 저장되고 프로세서에 의해 실행될 수 있으며, M2M 디바이스들 및 서버들을 포함하는 디바이스들에서 이용될 수 있다. 일 실시예에서는, 도 4c 및 도 4d에서 위에 설명된 바와 같이, 비-일시적 메모리 및 이에 동작가능하게 연결되는 프로세서를 갖는 컴퓨터 구현 UE가 개시된다. 구체적으로, 이러한 장치는 서비스 속성을 협상하기 위한 명령어들을 그 상에 저장하고 있는 협상 서비스 레이어를 갖는 비-일시적 메모리를 포함한다.

본 출원의 다른 양상은 컴퓨터 구현 네트워크형 시스템을 설명한다. 이러한 네트워크는 협상자 및 피-협상자를 포함한다. 협상자 및 피-협상자 각각은 데이터를 송신 및 수신하기 위한 송수신기를 포함한다. 협상자 및 피-협상자 각각은 서비스 레이어 속성을 협상하기 위한 명령어들이 저장되는 협상 서비스 레이어를 갖는 비-일시적 메모리를 또한 포함한다. 협상자 및 피-협상자 각각은, 비-일시적 메모리에 동작가능하게 연결되고, 서비스 레이어 속성의 협상을 수행하도록 구성되는 프로세서를 또한 포함한다. 실시예에 따르면, 협상자 및 피-협상자의 메모리는 협상 리소스, 정책 리소스, 위임 리소스 및 이들의 조합으로부터 선택되는 리소스를 포함한다.

시스템들 및 방법들이 현재 구체적인 양상들인 것으로 고려되는 것과 관련하여 설명되었지만, 본 출원이 개시된 양상들에 제한될 필요는 없다. 본 출원은 청구항들의 사상 및 범위 내에 포함되는 다양한 수정들 및 유사한 배열들을 커버하도록 의도되며, 그 범위는 모든 이러한 수정들 및 유사한 구조들을 포괄하도록 가장 넓게 해석되어야 한다. 본 개시 내용은 다음의 청구항들의 임의의 및 모든 양상들을 포함한다.

Claims (22)

1. 컴퓨터 구현 장치로서,
   서비스 속성을 협상하기 위해 협상 서비스 레이어(negotiation service layer)에 대해 저장되어 있는 명령어들을 포함하는 비-일시적 메모리; 및
   상기 비-일시적 메모리에 동작가능하게 연결된 프로세서
   를 포함하고,
   상기 프로세서는,
   피-협상자(negotiatee)로부터 수신되는 상기 속성을 검토하는 명령어;
   상기 검토된 속성에 기초하여 협상 요청을 상기 피-협상자에게 송신하는 명령어; 및
   상기 피-협상자로부터 제출된 제안(offered suggestion)을 수신하는 명령어
   를 수행하도록 구성되고,
   상기 협상 요청은 제시된 제안들(proposed suggestions)을 포함하고, 상기 제출된 제안은 상기 제시된 제안들로부터 선택되는, 컴퓨터 구현 장치.
2. 제1항에 있어서,
   상기 프로세서는 상기 제출된 제안을 선택하도록 추가로 구성되는 컴퓨터 구현 장치.
3. 제2항에 있어서,
   상기 선택은 상기 피-협상자의 미리 결정된 협상 정책들에 대해 점검되는 컴퓨터 구현 장치.
4. 제1항에 있어서,
   상기 협상 요청을 송신하는 단계는 브로커를 통해 상기 피-협상자에게 송신되는 컴퓨터 구현 장치.
5. 제4항에 있어서,
   상기 제출된 제안을 수신하는 단계는 상기 브로커를 통해 상기 피-협상자로부터 수신되는 컴퓨터 구현 장치.
6. 제1항에 있어서,
   상기 메모리 및 상기 프로세서에 동작가능하게 접속된 그래픽 사용자 인터페이스를 포함하는 디스플레이를 더 포함하고, 상기 그래픽 사용자 인터페이스는 상기 제출된 제안을 디스플레이하도록 구성되는 컴퓨터 구현 장치.
7. 제6항에 있어서,
   상기 디스플레이 상의 상기 제출된 제안은, 제안, 다른 피-협상자와 협상하라는 추천 및 이들의 조합으로부터 선택되는 정보를 포함하는 컴퓨터 구현 장치.
8. 컴퓨터 구현 장치로서,
   서비스 속성을 협상하기 위해 협상 서비스 레이어에 대해 저장되어 있는 명령어들을 포함하는 비-일시적 메모리; 및
   상기 비-일시적 메모리에 동작가능하게 연결된 프로세서
   를 포함하고,
   상기 프로세서는,
   피-협상자로부터 상기 속성을 협상하기 위한 정책을 수신하는 명령어;
   협상자(negotiator)로부터 상기 속성을 협상하라는 요청을 수신하는 명령어;
   상기 요청이 상기 피-협상자의 정책의 기준을 준수하는지를 결정하는 명령어; 및
   상기 협상에 대한 제출된 제안을 수신하는 명령어
   를 수행하도록 구성되고,
   상기 요청은 제시된 제안들을 포함하고, 상기 제출된 제안은 상기 제시된 제안들로부터 선택되는, 컴퓨터 구현 장치.
9. 제8항에 있어서,
   상기 프로세서는 제출된 제안을 상기 협상자에게 송신하도록 추가로 구성되는 컴퓨터 구현 장치.
10. 제8항에 있어서,
    상기 비-일시적 메모리는, 공통 속성들, 생성, 검색, 삭제, 업데이트, 실행, 레이블, 브로커, 타입, 제안을 행하기 위한 입력들, 제안을 선택하기 위한 입력들, 시작, 상태, 타겟, 참조, 제출된 제안들, 선택된 제안들, 출력 파라미터들, 가입 및 이들의 조합으로부터 선택되는 협상 리소스를 저장하고,
    상기 프로세서는 상기 협상 리소스를 이용하여 상기 속성을 협상하는 컴퓨터 구현 장치.
11. 제8항에 있어서,
    상기 메모리는, 공통 속성들, 레이블, 협상 타입, 협상자, 피-협상자, 조건, 결과, 선택 규칙, 가입 및 이들의 조합으로부터 선택되는 정책 리소스를 저장하고,
    상기 프로세서는 상기 정책 리소스를 이용하여 상기 속성을 협상하는 컴퓨터 구현 장치.
12. 제8항에 있어서,
    상기 메모리는, 공통 속성들, 레이블, 클라이언트, 현재의 협상 브로커, 새로운 협상 브로커, 위임 인에이블(delegation enable), 시작 시간, 지속시간, 결과, 가입 및 이들의 조합으로부터 선택되는 위임 리소스를 저장하고,
    상기 프로세서는 상기 위임 리소스를 이용하여 상기 속성을 협상하는 컴퓨터 구현 장치.
13. 네트워크형 시스템(networked system)으로서,
    컴퓨터 구현 협상자 및 컴퓨터 구현 피-협상자를 포함하고,
    상기 협상자 및 상기 피-협상자 각각은,
    데이터를 송신 및 수신하기 위한 송수신기;
    서비스 레이어 속성을 협상하기 위한 명령어들이 저장되어 있는 협상 서비스 레이어를 갖는 비-일시적 메모리; 및
    상기 비-일시적 메모리에 동작가능하게 연결되고, 상기 서비스 레이어 속성의 협상을 수행하도록 구성된 프로세서
    를 포함하고,
    상기 서비스 레이어 속성의 협상은 요청 및 제출된 제안들을 포함하고, 상기 요청은 제시된 제안들을 포함하고, 상기 제출된 제안은 상기 제시된 제안들로부터 선택되는, 네트워크형 시스템.
14. 제13항에 있어서,
    상기 프로세서는,
    피-협상자로부터 상기 속성을 협상하기 위한 정책을 수신하는 명령어;
    협상자로부터 상기 속성을 협상하라는 요청을 수신하는 명령어; 및
    상기 요청이 상기 피-협상자의 정책의 기준을 준수하는지를 결정하는 명령어
    를 수행하도록 구성되는 네트워크형 시스템.
15. 제13항에 있어서,
    상기 비-일시적 메모리는, 협상 리소스, 정책 리소스, 위임 리소스 및 이들의 조합으로부터 선택되는 리소스를 포함하는 네트워크형 시스템.
16. 컴퓨터 구현 방법으로서,
    피-협상자로부터 수신되는 협상가능 서비스 레이어 속성을 검토하는 단계;
    상기 검토된 속성에 기초하여 협상 요청을 상기 피-협상자에게 송신하는 단계;
    상기 피-협상자로부터 제출된 제안을 수신하는 단계; 및
    상기 제출된 제안을 선택하는 단계
    를 포함하고,
    상기 협상 요청은 제시된 제안들을 포함하고, 상기 제출된 제안은 상기 제시된 제안들로부터 선택되는, 컴퓨터 구현 방법.
17. 제16항에 있어서,
    상기 수신되는 제출된 제안은 상기 피-협상자의 미리 결정된 협상 정책들에 대해 점검되는 컴퓨터 구현 방법.
18. 제16항에 있어서,
    상기 협상 요청은, 서비스 id, 제안들을 행하기 위한 입력들, 제시된 제안들 및 이들의 조합으로부터 선택되는 정보를 포함하는 컴퓨터 구현 방법.
19. 컴퓨터 구현 방법으로서,
    피-협상자로부터 협상가능 서비스 레이어 속성을 협상하기 위한 정책을 수신하는 단계;
    협상자로부터 상기 속성을 협상하라는 요청을 수신하는 단계;
    상기 요청이 상기 피-협상자의 정책의 미리 결정된 기준을 준수하는지를 결정하는 단계; 및
    제출된 제안을 상기 협상자에게 송신하는 단계
    를 포함하고,
    상기 협상 요청은 제시된 제안들을 포함하고, 상기 제출된 제안은 상기 제시된 제안들로부터 선택되는, 컴퓨터 구현 방법.
20. 제19항에 있어서,
    상기 협상자로부터 협상 확인을 수신하는 단계; 및
    상기 협상 확인의 수신확인을 상기 피-협상자에게 송신하는 단계
    를 더 포함하는 컴퓨터 구현 방법.
21. 컴퓨터 구현 방법으로서,
    협상자로부터 협상가능 서비스 레이어 속성에 대한 협상 요청을 수신하는 단계;
    상기 속성을 갖는 피-협상자의 위치를 찾는(locating) 단계;
    상기 협상 요청을 상기 피-협상자에게 송신하는 단계; 및
    상기 협상가능 서비스에 대해 상기 피-협상자로부터 제출된 제안을 수신하는 단계
    를 포함하고,
    상기 협상 요청은 제시된 제안들을 포함하고, 상기 제출된 제안은 상기 제시된 제안들로부터 선택되는, 컴퓨터 구현 방법.
22. 제21항에 있어서,
    상기 제출된 제안을 상기 협상자에게 송신하는 단계;
    상기 협상자로부터 협상 확인을 수신하는 단계; 및
    상기 협상 확인의 수신확인을 상기 피-협상자에게 송신하는 단계
    를 더 포함하는 컴퓨터 구현 방법.

Images