KR101999039B1 - 디바이스 트리거링 - Google Patents

Abstract

서비스 계층과 애플리케이션 트리거링이 M2M 환경에 사용될 수 있다. 실시예에서, 등록과 같은 기존 서비스 계층 절차가 디바이스 또는 게이트웨이 서비스 계층 또는 애플리케이션으로 하여금 M2M 서버에게 어느 포트가 트리거들을 청취하는지를 표시하도록 허용할 수 있다. 또 다른 실시예에서, 트리거링은 트리거 요청들에서, 일시적 부트스트래핑 식별자들을 포함하는, 부트스트래핑 명령어들을 제공하기 위해 이용될 수 있다. 또 다른 실시예에서, 트리거링은 이벤트 통지를 돕는데 사용될 수 있다. 서비스 계층 또는 애플리케이션 명령어들은 트리거 페이로드들 내부에 내장될 수 있다. 트리거 페이로드 포맷이 정의된다.

Description

디바이스 트리거링{DEVICE TRIGGERING}

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

본 명세서는, 2013년 5월 6일에 출원되고, 발명의 명칭이 "서비스 계층 및 애플리케이션 트리거링 방법들(SERVICE LAYER AND APPLICATION TRIGGERING METHODS)"인 미국 임시 특허 출원 번호 제61/819,970호에 근거한 이익을 청구하고, 이것의 내용은 본 명세서에 참조로서 이로써 통합된다.

M2M(Machine-to-machine) 기술들은 디바이스들로 하여금 유선 및 무선 통신 시스템들을 이용하여 서로 더 직접적으로 통신하도록 허용한다. M2M 기술들은, 고유하게 식별 가능한 대상들 및 인터넷과 같은 네트워크에 걸쳐서 서로 통신하는 그러한 대상들의 가상 표현들의 시스템인 사물 인터넷(Internet of Things: IoT)의 추가적 실현을 가능하게 한다. IoT는 식료품점에서의 제품들 또는 가정 집에서의 가전 기기들과 같은 매우 평범한 일상적 대상들과의 통신을 용이하게 할 수 있고, 이에 의해 그러한 대상들에 대한 지식을 향상시킴으로써 비용 및 낭비를 줄일 수 있다. 예를 들어, 가게들은 재고 상태에 있을 수 있거나 판매되었을 수 있는 대상들과 통신하거나 그로부터 데이터를 획득할 수 있기 때문에 매우 정확한 재고 데이터를 유지할 수 있다.

3GPP(3^rd　Generation Partnership Project) 및 3GPP 의 일부인 표준 단체들 중 하나인 유럽 전기 통신 표준 연구소(European Telecommunications Standards Institute: ETSI) 양쪽은 M2M 통신을 지원하기 위한 아키텍처들을 정의하였다. 특정적으로, 3GPP는 그 TS 23.682에서 MTC(Machine Type Communication)를 위한 아키텍처를 정의했다. ETSI는 그 TS 102 690에서 그 ETSI M2M 아키텍처를 정의한다.

일반적으로, 양쪽 아키텍처에서, M2M 엔티티(예를 들어, 하드웨어 또는 하드웨어와 소프트웨어의 조합에 의해 구현될 수 있는 디바이스, 게이트웨이, 서버/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. 예를 들어, 광 센서는 검출된 광 레벨들을 표시하는 데이터를 제공할 수 있거나, 또는 온도 조절기는 온도 데이터 및 에어 컨디셔닝 제어를 조절하기 위한 능력을 제공할 수 있다. 이 데이터는, 다른 M2M 엔티티들에 의해 액세스될 수 있고 또한 M2M 엔티티들 간에서 데이터를 교환하기 위한 수단으로서 본질적으로 역할하는 "리소스"로서 이용 가능하게 될 수 있다. 리소스는 URI(Universal Resource Indicator)를 이용하여 어드레싱될 수 있는 고유하게 어드레싱 가능한 데이터 표현일 수 있다. 그와 같은 리소스들의 가용성은 M2M 서비스 능력 층(service capabilities layer: SCL)을 통해 M2M 엔티티들 중에서 통신될 수 있다.

M2M SCL은 하드웨어 또는 하드웨어와 소프트웨어이 조합에 의해 구현될 수 있고 또한 참조 포인트들(즉, M2M 엔티티들 사이의 기능적 인터페이스들)상에 노출되는 기능들을 제공하는 기능적 엔티티이다. 예를 들어, M2M SCL은 상이한 M2M 애플리케이션들 및/또는 서비스들에 의해 공유되거나 공통적으로 이용되는 공통 (서비스) 기능성들을 제공할 수 있다. 이들 공통 기능성들은 개방 인터페이스들의 세트를 이용하여 노출될 수 있다. 추가적으로, M2M 서비스 능력들은 노출된 인터페이스들(예를 들어, 3GPP, 3GPP2, ETSI TISPAN, 기타 등등에 의해 특정되는 기존 인터페이스들)의 세트를 통해 셀 방식 코어 네트워크 기능성들을 이용할 수 있고 하나 이상의 다른 코어 네트워크에 또한 인터페이싱할 수 있다.

도 1은 3GPP TS 23.682에서 정의되는 MTC를 위한 아키텍처를 도해하는 다이어그램이다. 이 아키텍처에서, 서비스 능력 서버(services capability server: SCS)(112)(가끔 M2M 서버로도 지칭됨)는 MTC 애플리케이션들에게 서비스들을 제공하는 엔티티이다. TS 23.682에서 기술된 바와 같이, MTC의 간접 및 하이브리드 모델의 양쪽을 지원하기 위해, MTC 연동 기능(MTC-IWF) 중 하나 이상의 인스턴스들은 라인(118) 위의 HPLMN(home public land mobile network)에 상주한다. MTC-IWF는 독립형 엔티티 또는 또 다른 네트워크 요소의 기능적 엔티티일 수 있다. MTC-IWF는 PLMN(internal public land mobile network) 토폴로지를 숨기며 또한 PLMN에서 특정한 기능성을 호출하기 위해 Tsp 참조 포인트에 걸쳐서 사용되는 시그널링 프로토콜들을 중계하거나 번역한다.

도 1에 도시된 바와 같이, MTC-IWF(116)는 3GPP 코어 네트워크(CN)에 상주하고, 이것은 3GPP에 의해 정의되는 T4 및 T5 참조 포인트들과 같은, 아키텍처의 "제어 평면"의 일부인 몇 개의 인터페이스들에 걸쳐 있는 사용자 장비(UE) - 이것은 휴대폰, 센서, 액추에이터 또는 임의의 다른 유형의 M2M 디바이스와 같은 임의 유형의 컴퓨팅 디바이스일 수 있음 - 와 통신할 수 있다. 추가로 보여진 것처럼, SCS(112)는 3GPP에 의해 정의되는 "Tsp" 인터페이스를 통해 MTC-IWF와 통신한다. UE는 보통은 네트워크의 "사용자 평면"을 통해 SCS와 통신한다. 제어 평면은 주로 네트워크에 걸쳐서 시그널링 트래픽을 전달하는 통신 경로로서 일반적으로 기술될 수 있다. 사용자 평면(때때로 데이터 평면, 포워딩 평면, 반송파 평면, 또는 베어러 평면으로 알려져 있음)은 음성 통신 및 데이터 통신(예를 들어, 전자 우편들 또는 인터넷으로부터의 웹 정보)과 같은 사용자 트래픽을 전달하는 통신 경로이다. 셀 방식 통신에서, 제어 평면 메시징의 예들은 페이지, SMS(short message service) 메시지, 로케이션 지역 갱신, 부착, 분리, 기타 등등이다.

도 2는 그 TS 102 690에서 ETSI에 의해 정의되는 ETSI M2M 아키텍처에 따른 시스템(120)을 도해하는 다이어그램이다. 이 다이어그램이 본 명세서에 개시되는 주제의 설명을 용이하게 하기 위해 단순화된다는 것을 유의한다. 도 2에 도시된 바와 같이, 시스템(120)은 네트워크 도메인(122), 네트워크 도메인(130), 네트워크 도메인(135), 및 네트워크 도메인(138)과 같은 복수의 네트워크 도메인을 포함할 수 있다. 각각의 네트워크 도메인은 NSCL(126), NSCL(131), NSCL(136), 및 NSCL(139)과 같은 네트워크 서비스 능력 계층(network service capability layer: NSCL)을 포함할 수 있다. 각각의 NSCL은 제각기 네트워크 도메인(122)과 네트워크 도메인(130)에서의 네트워크 애플리케이션(127)과 네트워크 애플리케이션(132)과 같은 제각기 네트워크 애플리케이션과 인터페이싱할 수 있다.

추가로 보여진 것처럼, 네트워크 도메인(122)과 같은 네트워크 도메인은 디바이스(145)와 같은 하나 이상 디바이스들, 및 게이트웨이(140)와 같은 하나 이상의 게이트웨이들을 추가로 포함할 수 있다. 3GPP 전문 용어에서, 디바이스들과 게이트웨이들은 UE들의 예들이다. 도면에 도시된 바와 같이, 디바이스(145)는 아키텍처에 의해 정의되는 mId 인터페이스에 걸쳐서 NSCL(126)과 통신하는 디바이스 SCL(DSCL)(146)을 실행하고 있을 수 있다. 디바이스 애플리케이션(DA)(147)은 또한 디바이스(145)상에서 실행되고 있을 수 있고, 이것은 dIa 인터페이스에 걸쳐서 DSCL(146)과 통신할 수 있다. 유사하게, 게이트웨이(140)는 mId 인터페이스에 걸쳐서 NSCL(126)과 통신하는 게이트웨이 SCL(GSCL)(141)을 구현할 수 있다. 게이트웨이(140)상에서 실행되는 게이트웨이 애플리케이션(GA)(142)은 dIa 인터페이스를 통해 GSCL(141)과 통신할 수 있다. 일반적으로, dIa 참조 포인트들은 디바이스 및 게이트웨이 애플리케이션들이 이들의 제각기 국지적 서비스 능력들(즉, 제각기 DSCL 또는 GSCL에서 이용 가능한 서비스 능력들)로 통신하도록 허용한다. mId 참조 포인트는 M2M 디바이스(예를 들어, DSCL(146)) 또는 M2M 게이트웨이(예를 들어, GSCL(141))에 상주하는 M2M SCL이 네트워크 도메인(예를 들어, NSCL(126)) 내의 M2M 서비스 능력들과 통신하도록 허용하고, 그 역도 마찬가지이다.

여전히 도 2를 참조하면, 더 상세하게, NSCL(126)은 도메인(122)에 있을 수 있고 및 M2M 서버 플랫폼(125)상의 네트워크 애플리케이션(NA)(127)으로 구성될 수 있다. NA(127) 및 NSCL(126)은 참조 포인트 mIa(128)를 통해 통신할 수 있다. mIa 참조 포인트들은 NA가 M2M 도메인에서 NSCL로부터 이용 가능한 M2M 서비스 능력들에 액세스하도록 허용할 수 있다.

전형적으로, 디바이스(145), 게이트웨이(140), 및 M2M 서버 플랫폼(125)은 도 7c와 도 7d에 도해되고 또한 아래 기술된 디바이스들과 같은, 컴퓨팅 디바이스들을 포함한다. NSCL, DSCL, GSCL, NA, GA, 및 DA 엔티티들은 전형적으로 시스템(120)에서 이들의 제각기 기능들을 실행하기 위해 기초 디바이스 또는 플랫폼상에서 실행되는 소프트웨어의 형태로 구현되는 논리 엔티티들이다.

추가로 도 2에 도시된 것처럼, NSCL(131)은 NA(132)를 가진 도메인(130)에 있을 수 있다. NA(132)와 NSCL(131)은 mIa 참조 포인트(133)를 통해 통신할 수 있다. 네트워크 도메인(135)에는 NSCL(136)이 있을 수 있고 네트워크 도메인(138)에는 NSCL(139)이 있을 수 있다. mIm 참조 포인트(123)는, 네트워크 도메인(122) 내의 NSCL(126), 네트워크 도메인(130) 내의 NSCL(131), 네트워크 도메인(135) 내의 NSCL(136), 또는 네트워크 도메인(138) 내의 NSCL(139)과 같은 상이한 네트워크 도메인들 내의 M2M 네트워크 노드들이 서로 통신하도록 허용하는 도메인 간 참조 포인트일 수 있다. 본 명세서에서 단순성을 위해, 용어 "M2M 서버"는 서비스 능력 서버(SCS), NSCL, 애플리케이션 서버, NA, 또는 MTC 서버를 표시하는데 사용될 수 있다. 게다가, 용어 사용자 장비(UE)는, 본 명세서에서 논의되는 것처럼, GA, GSCL, DA, 또는 DSCL에 적용될 수 있다. UE는, 본 명세서에서 논의되는 것처럼, 이동국, 고정된 또는 모바일 가입자 유닛, 호출기, 셀 방식 전화, 개인용 정보 단말기(PDA), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서 또는 액추에이터, 소비자 가전, 의료 기기들, 자동차들, 및 그와 유사한 것이라고 생각할 수 있다. 본 명세서에서 논의되는 M2M 네트워크 서비스 능력 계층 엔티티는 M2M 서버 또는 UE를 포함할 수 있다.

3GPP 및 ETSI M2M 아키텍처들이 본 명세서에서 배경으로 기술되고 또한 이후에 기술되는 다양한 실시예들을 도해하는데 사용될 수 있지만, 이후에 기술되는 실시예들의 구현들이 본 개시의 범위 내에 남아 있으면서 변할 수 있다는 것을 이해할 것이다. 통상의 기술자는 또한 개시된 실시예들이 상기 논의한 3GPP 또는 ETSI M2M 아키텍처들을 이용하는 구현들로만 제한되지 않으면, 그보다는 oneM2M, MQTT, 및 다른 M2M 시스템들 및 아키텍처들과 같은 다른 아키텍처들과 시스템들에 구현될 수 있다는 것을 인식할 것이다.

본 명세서에서 논의되는 3GPP와 ETSI M2M 네트워크 아키텍처들과 같은 M2M 네트워크에서 실행될 수 있는 한 기능은 디바이스 트리거(device trigger)로서 알려진다. 디바이스 트리거는, 애플리케이션 서버와 같은 네트워크 엔티티에 의해 개시되고 또한 보통은 네트워크의 제어 평면을 통해 디바이스에게 보내지는 메시지이다. 디바이스 트리거가 제어 평면을 통하여 보내지기 때문에, IP 어드레스가 디바이스를 어드레싱하는 데에 필요하지 않다. 그 대신에, 트리거는 MSISDN(Mobile Station International Subscriber Directory Number) 또는 URI(Uniform Resource Identifier)와 같은, 디바이스의 외부 3GPP 식별자에게 어드레싱될 수 있다. 디바이스 트리거들은 몇 개의 목적을 위해 도움이 될 수 있다. 예를 들어, 디바이스 트리거들은 SCS(M2M 서버)로부터 UE(M2M 디바이스 또는 게이트웨이)로 소량의 애플리케이션 또는 서비스 계층 데이터를 보내는데 사용될 수 있다. 덧붙여, 디바이스 트리거들은 UE상의 DA, GA, DSCL 또는 GSCL이 SCS(M2M 서버)와의 통신을 개시하도록 지시하는데 사용될 수 있다.

도 1에 예시된 3GPP 아키텍처에서, MTC-IWF가 T4와 T5와 같은 제어 평면 인터페이스들을 통해 UE를 트리거링하는 데 사용될 수 있다. MTC-IWF는 Tsp 인터페이스를 통해 SCS로부터 트리거 요청들을 수신할 것이고, UE의 외부 식별자와 IMSI와 같은 내부 식별자 사이의 매핑을 실행할 것이다. MTC-IWF는 트리거 전달의 성공 또는 실패를 SCS에게 보고할 것이다.

디바이스 트리거링 지역에서 기존 M2M 네트워크아키텍처들의 제한들을 해결하는 여러 기법들이 본 명세서에서 기술된다.

기존 M2M 아키텍처들이 가진 한가지 문제점은 어떻게 한 디바이스가 트리거들을 청취할 수 있는 지와 관련된다. 특정적으로, 트리거링될 수 있는 디바이스 서비스 계층 또는 애플리케이션은 특정 포트 번호상에서 트리거들을 청취한다. 포트 번호는 어떤 표준으로도 정의되지 않는다. 특정 포트 번호가 트리거링을 위해 보유되지는 않는데, 그 이유는 이렇게 하면 동일 포트상에서 트리거들을 청취하려고 동시에 시도하는 동일 서비스 계층 또는 애플리케이션의 2개의 인스턴스가 있는 경우에 충돌들을 야기할 것이기 때문이다. 그 대신에, 트리거들에 대해 청취하기 위해 개방 포트를 선택하는 것은 서비스 계층 또는 애플리케이션(즉, D/GSCL)에게 달려있다. 선택된 포트 번호는, 디바이스를 트리거링하도록 허용되는 어떠한 당사자들이든 간에 이들에게 광고되어야 한다. 지금까지, 디바이스 서비스 계층들 및 애플리케이션들은 이 정보를 M2M 서버에게 제공하지 않는다; 어떤 애플리케이션 또는 서비스 계층 프로토콜들도 포트 번호가 SCS에게 광고될 수 있는 방식을 정의하지 않는다. 본 개시의 한 양태는 이 문제에 대한 해결책을 제공한다. 특정적으로, 실시예에서, 등록과 같은 기존 서비스 계층 절차가 디바이스 또는 게이트웨이 서비스 계층 또는 애플리케이션으로 하여금 M2M 서버에게 디바이스 또는 게이트웨이 서비스 계층 또는 애플리케이션이 그 상에서 트리거들을 청취할 포트를 표시하도록 허용할 수 있다.

본 개시에서 다루어지는 또 다른 문제는 디바이스 또는 SCL 아이덴티티들을 "클리어하게" (예를 들어, 보안 콘텍스트 없이) 보내는 것과 관련된다. 특정적으로, M2M 서버/NSCL이 공공 인터넷상에서 디바이스 서비스 계층 또는 애플리케이션에 의해 액세스될 때, 이것이 최초 접촉을 이룰 때 "클리어하게" 그 디바이스 및/또는 D/GSCL 식별자를 보내야만 할 때가 있다. 예를 들어, 애플리케이션 서버 또는 SCS가 디바이스 애플리케이션 또는 디바이스 서비스 계층에게 부트스트래핑 요청을 할 때, 이 요청은 디바이스 애플리케이션 또는 서비스 계층이 보안 콘텍스트를 확립하기 전에 인터넷상에서 보내져야만 한다. 양호한 접근법은 SCS 및 디바이스 서비스 계층 또는 애플리케이션이 부트스트래핑 동안 이용될 수 있고 부트스트래핑 후에 변할 수 있는 일시적 식별자를 확립하는 것일 것이다. 그러나 ETSI M2M과 같은 기존 M2M 아키텍처들은 NSCL이 이 정보를 D/GSCL에게 제공하기 위한 메커니즘을 제공하지 않는다. 본 개시의 제2 양태는 이 문제에 대한 해결책을 제공한다. 특정적으로, 실시예에서, 트리거링이 부트스트래핑을 위해 이용될 수 있다. 부트스트래핑을 위한 일시적 식별자를 포함하는 부트스트래핑 명령어들이 트리거 요청에 내장될 수 있다. 부트스트래핑 명령어들 및 일시적 부트스트래핑 식별자들을 트리거 요청들에 내장시킴으로써, NSCL은 그렇지 않았더라면 도달될 수 없었을 디바이스들과의 부트스트래핑을 개시할 수 있고, 전체적 부트스트래핑 처리가 더 보안성을 가질 수 있다. 덧붙여, 트리거들은 보안 방식으로 일시적 부트스트래핑 식별자들을 할당하는데 사용될 수 있다.

본 개시에서 다뤄지는 제3 문제점은 "긴 폴링(long polling)"으로 지칭되는 ETSI M2M 서비스 계층 처리와 관련된다. 긴 폴링에서, 디바이스 애플리케이션 또는 서비스 계층은 SCS에게 자신이 몇몇 이벤트가 발생할 때 통지 받기를 원한다는 것을 알린다. 이벤트의 예는 SCS상에서의 특정 리소스에의 네트워크 애플리케이션 기입이다. 이벤트가 발생할 때, SCS는 통지를 디바이스 애플리케이션 또는 서비스 계층에게 보낼 것이다. 디바이스 애플리케이션 또는 서비스 계층은, 이것이 통지를 기다리는 동안 SCS와의 그 IP 연결을 유지하도록 요구받을 수 있다. 이것은 디바이스 또는 SCS가 연결을 유지하기 위해 주기적 "키프 얼라이브(keep alive)" 메시지들을 보내는 것을 필요로 하게 만들 수 있다. 이들 "키프 얼라이브" 메시지들은 네트워크 리소소들을 소모한다. 본 명세서에 제시되는 제3 해결책에 따라서, 트리거링이 긴 폴링을 더 효율적이게 하기 위해 이용된다. 특정적으로, 통지들을 디바이스 애플리케이션 또는 서비스 계층에게 보내기 위해 트리거링 특징을 레버리징하기 위한 방법이 정의되어서, 긴 폴링이 더 효율적이 되거나 또는 회피될 수 있도록 한다. 서비스 계층 또는 애플리케이션 명령어들이 트리거 페이로드들 내부에 내장되어 디바이스 및 SCS가 이들이 데이터 평면 연결을 유지할 필요가 있는 시간량을 최소화할 수 있도록 한다.

본 개시에서 다루어지는 마지막 문제는 트리거 페이로드들의 포맷과 관련된다. 현재, 상기에 언급된 Tsp 참조 포인트는 알려진 다이어미터 프로토콜(diameter protocol)에 기초하고 있고, Tsp 참조 포인트상에서의 메시지들은 3GPP에 의해 정의된다. Tsp 참조 포인트는 SCS와 UE 사이에서 소량의 데이터 패킷들을 송수신하는 데에 사용될 수 있다. 이것이 행해질 때, Tsp 다이어미터 메시지들은 페이로드 AVP(Attribute-Value Pair) 또는 필드를 포함할 것이다. 페이로드AVP의 내용들은 3GPP 네트워크에게 완전히 투명하다. 3GPP는 페이로드에 대한 크기 제한들을 부여할 수 있는데, 그렇지 않은 경우에는 페이로드 포맷은 SCS 및 UE 애플리케이션에 사용되는 애플리케이션 프로토콜에 의해 정의되어야 한다. ETSI M2M과 같은 현행의 애플리케이션 및 서비스 계층 프로토콜들은 아직 트리거 페이로드의 포맷을 정의하지 않는다. 본 개시는 이들 인스턴스들에 사용될 수 있는 트리거 페이로드 포맷을 정의한다.

이 요약은 하기 상세한 설명에서 추가로 기술되는 개념들 중 선택된 것들을 단순한 형태로 소개하기 위해 제공된다. 이 요약은 청구되는 주제의 주요 특징들 또는 핵심 특징들을 식별하기 위해 의도된 것이 아니며, 청구된 주제의 범위를 제한하기 위해 사용되도록 의도한 것도 아니다. 또한, 청구된 주제는 본 개시의 임의의 부분에서 주목된 임의의 또는 모든 단점들을 해결하는 한정들로만 제한되지는 않는다.

첨부 도면들과 관련하여 예시적으로 주어지는 하기 설명으로부터 더 세밀한 이해가 얻어질 수 있다.
도 1은 머신 유형 통신(Machine Type Communication: MTC)을 위한 3GPP 아키텍처를 도해한다;
도 2는 디바이스들과 참조 포인트들을 포함하는 예시적 ETSI M2M 아키텍처를 도해한다;
도 3은 본 개시의 제1 양태가 구현될 수 있는 예시적 M2M 시스템을 도해한다;
도 4는 트리거링의 비제한적 예시적 방법을 도해한다;
도 5는 부트스트래핑 및 트리거를 도해한다;
도 6은 예시적 리소스 구조를 도해한다.
도 7a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적 M2M 또는 사물 인터넷(IoT) 통신 시스템의 시스템 도이다.
도 7b는 도 7a에 도해된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적 아키텍처의 시스템 도이다;
도 7c는 도 7a에 도해된 통신 시스템 내에서 이용될 수 있는 예시적 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템 도이다.
도 7d는 도 7a의 통신 시스템의 양태들이 실시될 수 있는 예시적 컴퓨팅 시스템의 블록도이다.

서비스 계층 트리거링과 애플리케이션 트리거링과 같은 트리거링과 관계되는 개념들이 본 명세서에 개시된다. 제1 개념은, 디바이스 또는 게이트웨이 서비스 계층 또는 애플리케이션이 M2M 서버에게 디바이스 또는 게이트웨이 서비스 계층 또는 애플리케이션이 트리거들을 어느 포트상에서 청취하는지를 표시하는 것을 가능하게 하기 위해 디바이스, 게이트웨이 또는 애플리케이션 등록과 같은 기존 서비스 계층 절차를 이용한다. 본 명세서에서 논의되는 제2 개념은, 트리거링이 일시적 부트스트래핑 식별자들을 포함하여, 부트스트래핑 명령어들을 제공하는 데에 이용되는 것을 허용한다. 본 명세서에 개시된 제3 개념에 따라서, 트리거링은 이벤트 통지로 돕는 데에 사용될 수 있다. 마지막으로, 트리거 페이로드 포맷의 예시적 실시예가 정의된다.

트리거 포트 번호 식별을 수반하는 본 명세서에 개시된 제1 개념에 대하여, 도 3은 이 제1 개념이 구현될 수 있는 MTC를 위한 예시적 네트워크(100)를 도해한다. 도 3에서, 점선은 제어 평면 통신을 나타내고 실선은 사용자 평면 통신을 나타낸다. 이 실례의 네트워크(100)에서, M2M 서버(108)는 사용자 평면 참조 포인트(109)(예를 들어, 3GPP Gi/SGi 참조 포인트)를 통해 인터넷(110)과 통신가능하게 연결된다. M2M 서버(108)는 제어 평면 인터페이스(107)를 통해 MTC IWF(MTC Inter Working Function)과 통신가능하게 연결된다. 제어 평면 인터페이스(107)는 3GPP에 의해 정의된 바와 같은 Tsp 참조 포인트일 수 있다. 추가로 보여진 것처럼, M2M 서버(108), MTC-IWF(106), 자동 판매기(101)(즉, 사용자 장비(UE)), 및 SMS-SC(short message service-service center))(104)는 제어 평면 통신 채널들을 통해 서로 통신가능하게 연결될 수 있다. 자동 판매기(101)는 또한, 인터넷(110), 즉 사용자 평면을 통해 M2M 서버(108)와 통신가능하게 연결될 수 있다. M2M 서버(108)는 제어 평면(107) 또는 사용자 평면(109)을 통해 자동 판매기(101)와 통신할 수 있다.

예시적 실시예에 있어서, M2M 서버(108)는 자동 판매기(101)의 애플리케이션 또는 서비스 계층과 통신하기를 원할 수 있지만, 자동 판매기(101)는 어떤 IP 어드레스를 갖지 않을 수 있거나 또는 M2M 서버(108)는 자동 판매기(101)의 IP 어드레스를 알지 못할 수 있다. 이 시나리오에서, 트리거가 M2M 서버(108)와 자동 판매기(101) 간의 통신을 용이하게 하는데 사용될 수 있다. 트리거링 명령어들(예를 들어, 도 4의 방법)이 트리거가 보내지기 전에 M2M 서버(108)에게 제공될 수 있다. 자동 판매기(101)는 MSISDN(international subscriber directory number)(예를 들어, 전화번호), IMSI(International Mobile Subscriber Identity), URI, 또는 3GPP 외부 식별자를 가질 수 있고, 트리거는 M2M 서버(108)에 의해 개시될 수 있고, 자동 판매기(101)의 MSISDN, IMSI, URI, 또는 3GPP 외부 식별자에 기초하여 제어 평면상에서 자동 판매기(101)에게 보내질 수 있다. 트리거는 제어 평면을 이용하여 SMS-SC(104)로부터 보내지는 SMS 메시지일 수 있다. SMS 메시지에서의 필드는 SMS 메시지가 트리거인 것을 자동 판매기(101)에게 표시할 수 있다. 한 예로서, 트리거는, 자동 판매기(101)에게, 이것이 사전에 이런 것을 가지지 않았다면, 동적 호스트 구성 프로토콜 서버 또는 그와 유사한 것으로부터의 IP 어드레스를 제공하는데 사용될 수 있어서, 이것이 이후 사용자 평면(즉, 인터넷(110))을 통해서 M2M 서버(108)와 통신할 수 있도록 한다.

트리거가 제어 평면상에서 보내지기 때문에, IP 어드레스는 초기에 자동 판매기(101)와 통신하기에 필요하지 않다. 트리거는 MSISDN, IMSI, URI, 또는 3GPP 외부 식별자에게 보내질 수 있다. 트리거는 자동 판매기(101)의 애플리케이션 또는 서비스 계층이 M2M 서버(108)와의 통신을 개시하도록 지시하는데 사용될 수 있다. 또 다른 예에서, M2M 서버(108)는 자동 판매기(101)가 턴 온하도록 지시하기 위해 트리거를 이용할 수 있다. M2M 서버(108)가 응답을 기대하지 않거나 또는 응답이 소량의 데이터라면, IP 연결은 확립되지 않을 수 있다.

전술한 바와 같이, 자동 판매기(101)상에서 실행되고 있을 수 있는 서비스 계층 또는 애플리케이션과 같은, 트리거링될 수 있는 디바이스 서비스 계층 또는 애플리케이션은 특정 포트 번호상에서 트리거들을 청취한다. 트리거링에 대해 사용되는 포트 번호는 현재 어떤 표준으로든 정의되지 않는다. 특정 포트 번호가 트리거링을 위하여 보유되지 않는데, 그 이유는 이것이 동일 포트상에서 트리거들을 청취하려고 동시에 시도하는 동일 서비스 계층 또는 애플리케이션의 2개의 인스턴스가 있는 경우에 충돌들을 야기할 것이기 때문이다. 그 대신에, 트리거들을 청취하기 위해 개방 포트를 선택하는 것은 서비스 계층 또는 애플리케이션(즉, D/GSCL, DA, 또는 GA)에 달려 있다. 선택된 포트 번호는 디바이스를 트리거링하도록 허용되는 당사자들은 무엇이든 간에 이들에게 광고되어야 한다. 그러나, 3GPP MTC와 ETSI M2M과 같은 기존 M2M 아키텍처들에서, 디바이스 서비스 계층들과 애플리케이션들은 이 정보를 M2M 서버에게 제공하지 않는다; 어떤 애플리케이션 또는 서비스 계층 프로토콜들도 포트 번호가 SCS에게 광고될 수 있는 방식을 정의하지 않는다.

도 4는 디바이스 또는 게이트웨이 애플리케이션 또는 서비스 계층을 트리거링하는데 사용될 트리거 포트 번호의 식별을 M2M 서버에게 제공하기 위한 방법 160의 한 예시적 실시예를 도해한다. 도 4는 도 3에 의해 표현되는 네트워크에서 발생할 수 있는 처리를 나타낸다. 이 실시예에서, 이 정보는 디바이스 또는 게이트웨이 애플리케이션 또는 서비스 계층의 등록 동안 M2M 서버에게 제공되고, 정보는 트리거 명령어의 형태로 제공된다.

162 단계에서, 디바이스 또는 게이트웨이 서비스 계층 또는 애플리케이션(즉, UE)은 트리거링을 위한 명령어들을 생성한다. 이 실시예에서, 명령어들은 디바이스 또는 게이트웨이 애플리케이션 또는 서비스 계층이 그 상에서 트리거들을 청취하는 포트 번호의 식별을 포함한다.

164 단계에서, 디바이스 또는 게이트웨이 애플리케이션 또는 서비스 계층은, M2M 서버에 등록할 때 M2M 서버에게 트리거를 위한 명령어들 - 이것은 디바이스 또는 게이트웨이 애플리케이션 또는 서비스 계층이 그 상에서 트리거들을 청취하는 포트 번호의 식별을 포함함 - 을 전송할 수 있다. M2M 시스템이 ETSI M2M 아키텍처에 따라서 동작하는 실시예에서, ETSI M2M 사양(TS 102 921)은 SCL 생성 요청(sclCreateRequestIndication) 메시지를 특정하는데, 이것은 M2M 서버에 등록하기 위해UE에 의해 이용되는 것이다. 이 메시지는 RESTful CREATE 동작의 일부이다. ETSI M2M TS 102 921은 sclCreateRequestIndication 메시지의 원시(primitive)들을 정의한다. 이 실시예에 따라서, sclCreateRequestIndication 메시지는 UE가 그 트리거링 명령어들 - 특정적으로는 그 트리거 포트 번호 식별자 - 를 메시지에 삽입할 수 있도록 수정된다.

표 1은 M2M 서버에게 이것이 그 상에서 트리거들을 청취하는 포트 번호를 알리기 위해 UE의 애플리케이션 또는 서비스 계층에 의해 이용될 수 있는 수정된 sclCreateRequestIndication 메시지의 레이아웃의 일 실시예를 설명한다. 특히, 2개의 필드가 추가되었다 - accessNetworkDeviceId 및 accessNetworkPortId. accessNetworkDeviceId는 UE의 3GPP 외부 식별자, MSISDN, 또는 IMSI를 제공하기 위해 이용될 수 있다. accessNetworkPortId 필드는 등록하는 UE의 애플리케이션 또는 서비스 계층이 액세스 네트워크로부터의 제어 평면 메시지들, 즉 트리거들을 그 상에서 청취하는 포트의 번호를 특정하는데 사용될 수 있다.

M2M 서버가 수정된 sclCreateRequestIndication 메시지를 수신할 때, 이것은 accessNetworkDeviceId 및 accessNetworkPortId 필드들로부터 값들을 추출할 수 있는데, 이것들은 함께 UE를 트리거링하기 위한 명령어들을 포함한다. 이들 값들은 이후, 예를 들어 M2M 서버 내의 또는 M2M 서버와 연결되는 데이터베이스 또는 테이블에 저장될 수 있어서, 이들이 M2M 서버가 트리거를 UE에게 보내고 싶을 때 이후의 사용을 위해 검색되도록 할 수 있다.

다시 도 4를 참조하면, 166 단계에서, 트리거는 트리거링을 위해 M2M 서버에게 제공되는 명령어들에 기초하여 수신될 수 있다. 일 실시예에서, 3GPP TS 23.682와 3GPP TS 29.368에 지정되는 방법은 UE를 트리거링하기 위해 M2M 서버(예를 들어, SCS 또는 NSCL)에 의해 이용될 수 있다. 이 방법에서, 다이어미터 프로토콜의 명령인 DAR(Device-Action-Request) 명령은 트리거가 UE에게 발행되기를 요청하는데 사용된다. DAR 명령은 트리거 데이터라고 불리는 AVP(Attribute-Value Pair), 또는 필드를 포함한다. 트리거 데이터 AVP는 애플리케이션 포트 식별자 AVP 또는 필드를 포함한다. 이 애플리케이션 포트 식별자 필드는 UE상의 애플리케이션 또는 서비스 계층이 트리거들을 그 상에서 청취하는 포트를 식별하는데 사용된다.

본 실시예에 따라서, 트리거를 UE에게 발행할 때, M2M 서버는, 애플리케이션 포트 ID 필드를 파퓰레이팅하기 위해 수정된 sclCreateRequestIndication 메시지의 accessNetworkPortId 필드에서 UE 등록 동안 수신되는 포트 번호를 이용할 수 있다.

accessNetworkDeviceId와 accessNetworkPortId가 미리 정해진 시구간에 대응하도록 주기적으로 갱신될 수 있다는 것을 유의한다. 게다가, 식별자들은, 포트 번호에 대한 변경이 이뤄질 때, 포트 번호와 또 다른 식별자의 조합이 변경될 때, 변경이 이뤄진 후의 설정 시간에 또는 상기의 것들의 조합에서 갱신될 수 있다. 예에서, accessNetworkPortId는 47,600과 같은 무부호 정수일 수 있다. accessNetworkDeviceId는 555-555-1234와 같은 MSISDN, 또는 mikes-vending-machine@mobile-network.com과 같은 3GPP 외부 식별자일 수 있다.

SCL 원시 sclCreateRequestIndication

원시 속성	설명
requestingEntity	UE SCL의 URI가 최초로 원시를 요청함
targetID	UE SCL 리소스가 생성될 M2M 서버의 URI
Primitive Type	SCL_CREATE_REQUEST
리소스	설명
Scl	M2M 서버에서 생성될 SCL 리소스의 제안된 명칭. 대안적으로, 이 필드는 UE가 등록된 최종 M2M 서버에 의해 할당된 일시적 sc1Id를 전달하는 데에 또한 사용될 수 있다.
accessNetworkDeviceId	액세스 네트워크 ID는 UE의 3GPP 외부 식별자, MSISDN, 또는 IMSI일 수 있다. 이 필드는 또한 UE가 등록된 최종 M2M 서버에 의해 할당된 일시적 accessNetworkDeviceId를 전달하는 데에 또한 사용될 수 있다.
accessNetworkPortId	액세스 네트워크 포트 Id는 SCL이 액세스 네트워크로부터의 제어 평면 메시지들을 청취하는 포트 번호이다. 제어 평면 메시지들의 예는 트리거들을 포함한다. 트리거 요청을 이룰 때, 이 값은 애플리케이션 포트 ID 필드를 파퓰레이팅하는데 사용된다.

간략히 앞서 언급된 제2 개념을 참조하면, 트리거링이 부트스트래핑을 위해 이용될 수 있다. 특히, 기존 M2M 아키텍처들의 결점이, 트리거 요청들에 부트스트래핑을 위한 일시적 식별자를 포함하는 부트스트래핑 명령어들을 내장함으로써 극복될 수 있다. 또한, 트리거들은 보안 방식으로 일시적 부트스트래핑 식별자들을 할당하는데 사용될 수 있다.

전술한 바와 같이, M2M 서버가 공공 인터넷과 같은, 네트워크를 통해 UE의 서비스 계층 또는 애플리케이션에 의해 액세스될 때, UE가 최초 접촉을 이룰 때 "클리어하게" 그 UE 식별자를 보내는 때가 있다. 예를 들어, M2M 서버가 UE에게 부트스트래핑 요청을 할 때, 요청은, M2M 서버와 UE가 보안 콘텍스트를 확립하기 전에 인터넷을 통해 보내질 수 있다. 선호되는 액세스는 M2M 서버와 UE가 부트스트래핑 동안 이용될 수 있는 일시적 식별자를 확립하는 것을 포함한다. 일시적 식별자는 이후 부트스트래핑 후에 바뀔 수 있다. 그러나 3GPP MTC, ETSI M2M, 및 oneM2M과 같은 기존 M2M 아키텍처들은 NSCL이 이 정보를 D/GSCL에게 제공하기 위한 메커니즘을 제공하지 않는다. 이후에 기술되는 바와 같이, 이 문제는 부트스트래핑 명령어들 및 일시적 부트스트래핑 식별자들을 트리거 요청들에 내장함으로써 해결된다. 부트스트래핑 명령어들 및 일시적 부트스트래핑 식별자들을 트리거 요청들에 내장함으로써, M2M 서버는 그렇지 않았더라면 전체 부트스트래핑 처리 동안 도달되지도 않았고 보안도 안 되었을 디바이스들 및 게이트웨이들과의 부트스트래핑을 또한 개시할 수 있다.

ETSI TS 102 921은 sclCreateResponseConfirm 메시지를 정의한다. 표 2는 성공적 sclCreate의 경우에 대한 sclCreateResponseConfirm 메시지의 원시의 예를 보여준다. 필드 tempAccessNetworkDeviceId는 M2M 서버에 의해 할당되는 일시적 UE 식별자이다. M2M 서버는 UE의 영구적 식별자에의 이 식별자의 매핑을 보유한다. UE는 UE가 미래 등록 요청들을 이룰 때 영구적 식별자 대신에 이 식별자를 이용할 수 있다. 예를 들어, M2M 서버는 도 3a의 자동 판매기(101)에게 tempAccessNetworkDeviceId = qrxp3121994@lmnop.mfs라는 일시적 식별자를 부여할 수 있다. M2M 서버는 qrxp3121994@lmnop.mfs = mikes-vending-machine@mobile-network.com을 표시하는 매핑을 내부적으로 유지할 수 있다.

SCL 원시: sclCreateResponseConfirm

원시 속성	설명
PrimitiveType	SCL_CREATE_RESPONSE
statusCode	STATUS_CREATE
resourceURI	<sclbase>/scls/ 하에서 생성된 scl 리소스의 URI
tempAccessNetworkDeviceId	tempAccessNetworkDeviceId 식별자는 일시적 디바이스 식별자이다. M2M 서버는 UE의 영구적 디바이스 식별자에의 이 식별자의 매핑을 보유한다. UE는 UE가 미래 부트스트래핑 요청들을 이룰 때 영구적 식별자 대신에 이 식별자를 이용할 수 있다.
리소스	설명
scl	호스팅 SCL이 요청에 제공된 값들을 오버라이트한다면, 이것은 생성된 scl 리소스이다

도 5는 UE에게 부트스트래핑 또는 등록 요청들을 하기 위해 트리거링을 이용하기 위한 예시적 절차의 일 실시예를 도해한다. 부트스트래핑은 제1 엔티티(예를 들어, UE)가 제2 엔티티(예를 들어, M2M 서버)와의 인증 및 보안 키 확립을 실행하는 처리이다. 등록은 제1 엔티티(UE)가 제2 엔티티(M2M 서버)와의 서비스 연결을 확립하는 처리이다. 등록 처리 후에, UE에 대응하는 리소스가 M2M 서버 리소스 수형도 하에서 생성되고, M2M 서버에 대응하는 리소스는 UE 리소스 수형도 하에서 생성된다. 종종, 부트스트래핑 및 등록은 조합되어 단일 단계 또는 단계들의 세트가 될 수 있다. 185에서, M2M 서버(184)는 UE(181)을 발견한다. 예를 들어, M2M 서버(184)는 이전 연결로부터의 UE(181)를 알았을 수 있거나 또는 UE(181)는 또 다른 컴퓨터(예를 들어, UE 또는 서버)가 그것을 광고했기 때문에 발견되었을 수 있다. 186에서, M2M 서버(184)는 MTC-IWF(183) 및 액세스 네트워크(182)를 통해 UE(181)를 목적지로 하는 트리거 요청을 보낸다. 이 실시예에서, M2M 서버(184)는, 예를 들어 도 4의 단계 166에서 앞서 기술된 방식으로 UE를 트리거하기 위해 Tsp 참조 포인트상에서, 186 단계에서 DAR 명령을 발행한다. 도 4의 162 단계 및 164 단계와 같은, 트리거링 명령어들을 생성하고 제공하는 것과 관계된 단계들은 도 5에 도시되지 않은 이전 등록에서 이미 발생했을 수 있다. 또한 위에서 기술된 것처럼, UE(181)는 3GPP 외부 식별자, MSISDN, 또는 IMSI와 같은 식별자에 의해 식별될 수 있고, UE상에서 실행되는 애플리케이션 또는 서비스 계층은 이것이 그 상에서 트리거들을 청취하는 지정된 포트 번호를 가질 수 있다. M2M 서버(184)는, 예를 들어 발견 동안 또는 이전 관계성 동안 UE 식별자 및 포트 번호를 알았을 수 있다. 트리거를 UE(181)에게 발행할 때, M2M 서버(184)는 애플리케이션 또는 서비스 계층의 포트 번호를 DAR 명령의 트리거 데이터 필드의 애플리케이션 포트 식별자 필드에 배치할 수 있다. UE가 트리거를 수신할 때, 포트 ID는 트리거를 라우팅할 포트 번호를 결정하는 데에 사용될 수 있다. 하기에서 더 상세하게 기술되는 바와 같이, 트리거 메시지는 UE로 하여금 M2M 서버(184)와 부트스트랩하거나 이것에 등록하도록 지시할 수 있다.

187에서, UE(181)는 M2M 서버(184)와 부트스트랩하기 위해 수신된 트리거에서의 정보를 이용한다. 188에서, UE(181)는 M2M 서버(184)에 등록한다. 원한다면, 트리거링을 위한 명령어들을 갱신하고 또한 디바이스/게이트웨이 등록 동안 트리거링을 위한 갱신된 명령어들을 M2M 서버에게 제공하는 것이 188 단계에서 또는 188 단계에 대해 발생할 수 있다. 189에서, M2M 서버(184)는 UE(181)의 등록을 확인한다. UE(181) 및 M2M 서버(184)는 등록이 발생할 때 관계성을 형성한다. 여기서, UE(181) 및 M2M 서버(184)는 서로의 SCL상에서 리소스들을 생성하고, 통신을 시작할 수 있다. 또한, 등록에서, 트리거링 명령어들이 UE(181)에 의해 M2M 서버(184)에게 주어진다.

더욱 상세하게는, PANA(Protocol for Carrying Authentication for Network Access) 부트스트래핑이 UE(181)와 M2M 서버(184) 간에 실행되면, 이후 트리거의 applicationSpecificPayload 필드가 부트스트래핑을 개시하기 위해 PAR(PANA-Auth-Request) 명령을 전달하는데 사용될 수 있다. PANA 부트스트래핑 절차의 나머지는 이후 사용자 평면상에서 일어날 수 있다. 트리거 요청의 triggerPurpose 필드는 요청을 표시하기 위해 Bootstrap Request에 설정될 수 있다. 트리거 요청의 목적지 포트 번호는 공지된 PANA 포트 번호, 서비스 계층이 부트스트래핑 요청을 청취하기 위해 특정한 포트 번호, 또는 UE(181)가 청취하고 있다고 알려져 있는 포트 번호에 설정될 수 있다.

상기에서 추가로 기술된 것처럼, 도 1의 3GPP 아키텍처에서의 트리거 요청들은 SCS(즉, M2M 서버)와 MTC-IWF 사이의 Tsp 참조 포인트를 통해서 개시될 수 있다. Tsp 참조 포인트를 통해서 넘겨지는 메시지들은 다이어미터 프로토콜에 기초한다. 특정적으로, 트리거 요청을 위한 다이어미터 메시지는 다이어미터 메시지의 페이로드AVP(즉, 필드)에 트리거의 상세 사항들을 포함할 것이다. 그러나, 기존의 M2M 아키텍처들에서의 현행의 애플리케이션 들 및 서비스 계층 프로토콜들은 트리거 페이로드의 포맷을 정의하지 않는다. 이 단점을 해결하기 위해, 본 개시는 이 목적을 위해 사용될 수 있는 트리거 요청들을 위한 페이로드 포맷을 정의한다.

특히, UE에 의해 M2M 서버에게 보내지는 페이로드 전달 Tsp 메시지를 위한 페이로드 포맷의 실시예가 본 명세서에 개시된다. 본 명세서에서 정의되는 Tsp 트리거 페이로드는 예를 들어 ETSI 준수 UE들 및 NSCL들에 의해 사용될 수 있다. 표 3은, 모든 또는 일부 필드들이 이용될 수 있는 이 Tsp 트리거 페이로드 포맷의 예시적 실시예를 펼쳐 보인다. triggerPurpose 필드가 부트스트래핑을 위한 요청으로서 트리거를 식별하는데 사용될 수 있다는 것을 유의한다.

TSP 트리거 페이로드

필드 명	설명
scsContactAddress	M2M 서버의 IPv4 또는 IPv6 어드레스.
scsContactPortNumber	M2M 서버(예를 들어, NSCL)와 접촉하는데 사용되어야 하는 IP 포트 번호(UDP 또는 TCP).
scsProtocol	M2M 서버와 접촉할 때 이용되는 프로토콜(HTTP, CoAP, 기타 등등).
triggerPurpose	0: 부트스트랩 요청 1: 접촉 요청 2: 애플리케이션 소량 데이터 전달 3: SCL 소량 데이터 전달 4: 통신 채널 통지 - 이 선택 사항은 트리거링이 긴 폴링에 대한 대안으로서 이용될 때 이용될 수 있다.
notificationUri	검색된 리소스(또는 컨테이너)(예를 들어, M2M 서버상에 또는 네트워크에서의 애플리케이션에 의해 호스팅되는 리소스)에게 SCL 또는 애플리케이션을 포인팅하는 URI. 리소스(또는 컨테이너)는 트리거가 보내진 이유를 설명할 수 있고, 정보를 제공할 수 있고, 기타 등등을 한다. 트리거 페이로드에서의 통지 URI 필드는, 리소스에 대한 갱신들에 대해 알도록 하기 위해, DSCL이 이전에 가입한 URI에게 DSCL을 포인팅하는데 사용될 수 있다. 트리거의 목적이 통신 채널 통지라면, notificationURI는 통신 채널 URI에게 포인팅한다.
applicationIdentifier	트리거 수신인이 트리거 내용들을 표적 애플리케이션에게 디스패치하는 서비스라면, 이후 이 필드는 표적 애플리케이션을 식별하는데 사용된다. ETSI M2M 기준으로는, dIa 참조 포인트를 통해서 SCL로부터 애플리케이션으로 넘겨져야 할 트리거에서의 애플리케이션 특정적 페이로드가 있다면, 이후 이 필드는 애플리케이션을 식별하는 것을 조력한다.
applicationSpecificPayload	이 페이로드는 dIa를 통해서 applicationIdentifier 필드에서 식별되는 애플리케이션에게 넘겨진다.
sclPayload	이 SCL 페이로드는 UE에게 전달된다.
temporaryDeviceId	트리거의 목적이 - 예를 들어, 도 5에 도해된 방법에 따라서 - UE가 부트스트랩할 것을 요청하는 것이라면, 이후 이 필드는 부트스트래핑할 때 UE를 위한 일시적 디바이스 식별자를 포함할 수 있다.
temporarySclId	트리거의 목적이 - 예를 들어, 도 5에 도해된 방법에 따라서 - UE가 부트스트랩할 것을 요청하는 것이라면, 이후 이 필드는 부트스트래핑할 때 SCL을 위한 일시적 SCL 식별자를 포함할 수 있다. 이것은 M2M 서버와 부트스트랩하고 이것에 등록할 수 있는 서비스 계층 또는 애플리케이션으로 일반화될 수 있다. 애플리케이션들(또는 이들이 호스팅되는 적어도 디바이스들)은 서비스 계층과 부트스트랩하고 이것에 등록할 수 있다.

상기 언급된 제3 개념을 참조하면, 트리거링은 통지들을 디바이스 애플리케이션 또는 서비스 계층에게 보내는데 사용될 수 있다. 이 개시된 기술은 기존 M2M 아키텍처들에서의 "긴 폴링" 처리에 의한 단점을 해결한다. 전술한 바와 같이, 긴 폴링에서, 디바이스 애플리케이션 또는 서비스 계층은 SCS에게 이것이 몇몇 이벤트가 발생할 때 통지되기를 원하는 것을 알린다. 이벤트의 예는 SCS상의 특정 리소스에의 네트워크 애플리케이션 기입이다. 이벤트가 발생할 때, SCS는 통지를 디바이스 애플리케이션 또는 서비스 계층에게 보낼 것이다. 디바이스 애플리케이션 또는 서비스 계층은 이것이 통지를 기다리는 동안 SCS와의 그 IP 연결을 유지하도록 요구 받을 수 있다. 이것은 디바이스 또는 SCS가 연결을 유지하기 위해 주기적 "키프 얼라이브" 메시지들을 보내는 것을 필요로 할 수 있다. 이들 "키프 얼라이브" 메시지들은 네트워크 리소스들을 소모한다. 이후에 기술되는 바와 같이, 트리거링은 긴 폴링을 더 효율적이게 하기 위해 이용될 수 있다. 특정적으로, 통지들을 디바이스 애플리케이션 또는 서비스 계층에게 보내기 위해 트리거링 특징을 레버리징하기 위한 방법이 정의되어서, 긴 폴링이 더 효율적이 되거나 회피될 수 있도록 한다. 서비스 계층 또는 애플리케이션 명령어들은 트리거 페이로드들 내부에 내장되어서 디바이스 및 SCS가 이들이 데이터 평면 연결을 유지하는 데에 필요한 시간량을 최소화할 수 있도록 한다.

현재, ETSI M2M 참조 TS 102 690은 서비스 계층 긴 폴링을 정의하는데, 이것은 전술한 바와 같이 M2M 서버에게 이것이 이벤트가 발생할 때 통보 받기를 원하는 것을 알리기 위해 UE에 의해 이용될 수 있다. 이벤트의 예는 M2M 서버상의 특정 리소스에의 네트워크 애플리케이션 기입하기이다. 도 3의 예시적 M2M 환경을 참조하면, 예는 갱신된 가격 산정 정보로 M2M 서버(108)상의 리소스를 갱신하는 것을 포함할 수 있다. 갱신이 발생할 때, M2M 서버(108)는 통지를 자동 판매기(101)에게 보낸다. 자동 판매기(101)(즉, UE)는 이것이 통지를 기다리는 동안 M2M 서버(108)와의 그 IP 연결을 유지하도록 요구 받을 수 있다. 그 결과, 자동 판매기(101) 또는 M2M 서버(108)는 IP 연결을 유지하기 위해 주기적 "키프 얼라이브" 메시지들을 보낼 수 있다. 이들 "키프 얼라이브" 메시지들은 네트워크 리소스들을 소모한다.

이 문제를 해결하기 위해, 트리거가 UE에게 이벤트들을 통지하기 위해 제어 평면상에서 보내질 수 있다. 트리거 페이로드는, 예를 들어 표 3의 예시적 트리거 페이로드 포맷에 도시된 바와 같이, notificationUri 필드를 포함할 수 있다. notificationUri 필드는 UE 서비스 계층 또는 애플리케이션을 검색되어야 하는 리소스에게 포인팅한다. 표 3의 예시적 트리거 페이로드 포맷에 제공되는 것과 같은 triggerPurpose 필드는 디바이스 애플리케이션 또는 서비스 계층에게 트리거가 "통신 채널 통지(Communication Channel Notification)"인 것을 표시하기 위해 M2M 서버에 의해 이용될 수 있다. 예를 들어, 표 3에 도해된 포맷의 triggerPupose 필드는 4로 설정될 것이다. 이 실시예에서, triggerPurpose 필드에서의 "통신 채널 통지" 값은 몇몇 이벤트가 발생한 표시 또는 UE가 발생한 이벤트에 관한 몇몇 정보를 검색하기 위한 요청이다. 추가로 표 3에 보여진 것처럼, 트리거 페이로드는 applicationIdentfier를 포함할 수 있고, 트리거가 서비스 계층 또는 트리거 디스패치 기능을 통해 보내질 때, applicationIdentfier 필드는 표적 애플리케이션을 식별하는데 사용될 수 있다. 도 3에 도해된 것과 같은 예에서, 자동 판매기(101)는 트리거를 수신하는 DSCL을 가질 수도 있다. DSCL 위에서 실행되는 몇 개의 애플리케이션들이 있을 수 있다. 한 애플리케이션은 가격 산정을 다룰 수 있고 또 다른 것은 유지 관리 기록들을 다룰 수 있다. applicationIdentifier 필드에서의 애플리케이션 식별자는 애플리케이션 특정적 페이로드가 가격 산정 애플리케이션에게 넘겨져야 한다는 것을 식별하는데 사용될 수 있다. 표3의 트리거 페이로드 포맷을 더 참조하면, applicationSpecificPayload 필드는 갱신된 가격 산정 정보를 포함하는 NSCL상의 리소스에의 포인터(예를 들어, URI)를 홀드할 수 있다. 대안적으로, 이 필드는 실제 가격 산정 정보를 전달할 수 있거나, 이 필드는 자동 판매기가 트리거가 보내진 이유를 알아내기 위해 NSCL과 접촉해야 한다는 표시를 포함할 수 있다.

예를 들어, 도 3을 참조하면, 자동 판매기(101)는 몇 개의 자동 판매 아이템들을 포함할 수 있다. M2M 서버(108)는, 예를 들어 리소스 또는 URI에 포함되는 자동 판매 아이템들에 대한 갱신된 가격들을 가질 수 있다. M2M 서버(108)는 자동 판매기(101)에게 새로운 가격 산정을 알아내도록 리소스를 판독하기 위한 트리거를 보낼 수 있다. 트리거 페이로드는 자동 판매기(101)에 의해 판독될 필요가 있는URI를 포함할 수 있다. 페이로드에서의 메시지는 자동 판매기(101)에게 추가적 정보를 위해 특정 URI를 판독할 것을 전달한다. 자동 판매기(101)가 트리거를 수신할 때, 이것은 (만약 이것이 그런 연결을 이미 갖고 있지 않다면) 보통 IP 연결을 확립할 것이고, 이후 이것이 트리거링된 이유를 결정하기 위해 M2M 서버(108)와 접촉한다. 메시지는 SMS 유형 메시지일 수 있다. 페이로드의 사이즈는 매우 제한되어서, 페이로드가, 많은 경우들에서, 자동 판매기(101)가 URI로부터 더 많은 정보를 얻도록 안내만 할 수 있다.

ETSI M2M SCL상에서, 리소스들은 도 6에 도시된 바와 같이 수형도 구조로서 관리된다. <sclBase> 리소스(190)는 호스팅 M2M SCL(예를 들어, 자동 판매기(101) 또는 M2M 서버(108))의 모든 다른 모든 서브 리소스들을 포함한다. <sclBase> 리소스(190)는 이것이 포함하는 다른 리소스들의 루트이다. <sclBase> 리소스(190)는 절대 URI에 의해 표현된다. SCL에 호스팅되는 다른 리소스들은 <sclBase> 리소스(190)의 URI로부터 계층적으로 도출되는 URI에 의해 식별된다. 예를 들어, 본 명세서에서 논의되는 자동 판매기 가격들에 관해서, 디렉토리 구조는 <sclBase>(190)/컨테이너들(193)/자동 판매 아이템들(194)/자동 판매 아이템 가격들(195)일 수 있다.

전술한 바와 같이 트리거 페이로드 내부에 서비스 계층 또는 애플리케이션 명령어들을 내장함으로써, UE와 M2M 서버는, 그렇지 않았더라면 종래의 긴 폴링에 의한 경우에 그러했을 것으로서 이들이 데이터 평면 연결을 유지하는 데에 필요한 시간량을 최소화할 수 있다.

도 7a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적 M2M 또는 사물 인터넷(IoT) 통신 시스템(10)의 또 다른 다이어그램이다. 일반적으로, M2M 기술들은 IoT를 위한 빌딩 블록들을 제공하고, 임의의 M2M 디바이스, 게이트웨이 또는 서비스 플랫폼은 IoT 뿐만 아니라 IoT 서비스 계층, 기타 등등의 컴포넌트일 수 있다.

도 7a에 도시된 바와 같이, M2M/IoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크 또는 무선 네트워크(예를 들어, WLAN, 셀 방식, 또는 그와 유사한 것) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 브로드캐스트, 또는 그와 유사한 것과 같은 콘텐츠를 다중 이용자에게 제공하는 다중 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는 코드 분할 다중 액세스(CDMA), 시분할 다중 액세스(TDMA), 주파수 분할 다중 액세스(FDMA), 직교 FDMA(OFDMA), 단일 반송파 FDMA(SC-FDMA), 및 그와 유사한 것과 같은 하나 이상의 채널 액세스 방법들을 채택할 수 있다. 또한, 통신 네트워크(12)는 예를 들어, 코어 네트워크, 인터넷, 센서 네트워크, 산업적 제어 네트워크, 개인 지역 네트워크(personal area network), 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.

도 7a에 도시된 바와 같이, M2M/IoT 통신 시스템(10)은 M2M 게이트웨이 디바이스(14) 및 M2M 단말 디바이스들(18)을 포함할 수 있다. 임의 개수의 M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18)이 요망에 따라 M2M/IoT 통신 시스템(10)에 포함될 수 있다는 것을 이해할 것이다. 각각의 M2M 게이트웨이 디바이스들(14)과 M2M 단말 디바이스들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 송신 및 수신하도록 구성된다. M2M 게이트웨이 디바이스(14)는 고정 네트워크 M2M 디바이스들(예를 들어, PLC)뿐만 아니라 무선 M2M 디바이스들(예를 들어, 셀 방식 및 비 셀 방식)이 통신 네트워크(12)와 같은 운영자 네트워크들 또는 직접 무선 링크를 통해 통신하도록 허용한다. 예를 들어, M2M 디바이스들(18)은 통신 네트워크(12) 또는 직접 무선 링크를 통해 데이터를 수집할 수 있고 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에게 보낼 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 데이터 및 신호들은 후술하는 바와 같이 M2M 서비스 플랫폼(22)을 통해 M2M 애플리케이션(20)에게 보내질 수 있고 그로부터 수신될 수 있다. M2M 디바이스들(18) 및 게이트웨이들(14)은 예를 들어, 셀 방식, WLAN, WPAN(예를 들어, 지그비(Zigbee), 6LoWPAN, 블루투스), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.

예시된 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 서비스 플랫폼(22)은 또한 데이터를 수집할 수 있고, 상이한 유형들의 M2M 애플리케이션들(20)과 호환적이 되도록 데이터를 변환할 수 있다. M2M 서비스 플랫폼(22)의 기능들은, 예를 들어, 웹 서버로서, 셀 방식 코어 네트워크에서, 클라우드에서, 기타 등등에서 다양한 방식들로 구현될 수 있다.

또한 도 7b를 참조하면, M2M 서비스 플랫폼은, 다양한 애플리케이션들 및 버티컬들이 레버리지할 수 있는, 트리거링과 같은, 서비스 전달 능력들의 핵심 세트를 제공하는 서비스 계층(26)(예로, 본 명세서에서 설명된 NSCL)을 전형적으로 구현한다. 이들 서비스 능력들은 M2M 애플리케이션들(20)로 하여금 디바이스들과 상호 작용하고 또한 데이터 수집, 데이터 분석, 디바이스 관리, 보안성, 계산서 청구, 서비스/디바이스 발견, 기타 등등과 같은 기능들을 실행하게 할 수 있다. 기본적으로, 이들 서비스 능력들은 애플리케이션들이 이들 기능성들을 구현하는 부담으로부터 해방시키고, 따라서 애플리케이션 개발을 단순화하고 마케팅할 시간 및 비용을 절약시킨다. 서비스 계층(26)은 또한 M2M 애플리케이션들(20)이, 서비스 계층(26)이 제공하는 서비스들과 연계하여 다양한 네트워크들(12)을 통해 통신하게 할 수 있다.

몇몇 실시예들에서, M2M 애플리케이션들(20)은 본 명세서에서 논의되는 대로 트리거링을 이용하여 통신하는 요망 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20)은, 수송, 건강 및 건강 관리, 연결된 집, 에너지 관리, 자산 추적, 및 보안과 감시와 같은 것이지만, 이것들에만 한정되지는 않는 다양한 산업들에서의 응용들을 포함할 수 있다. 전술한 바와 같이, 디바이스들, 게이트웨이들, 시스템의 다른 서버들에 걸쳐서 실행되는 M2M 서비스 계층은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 계산서 청구, 로케이션 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능들을 지원하고, 이들 기능들을 서비스들로서 M2M 애플리케이션들(20)에게 제공한다.

도 7c는 예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적 M2M 디바이스(30)의 시스템 도이다. 도 7c에 도시된 바와 같이, M2M 디바이스(30)는 프로세서(32), 송수신기(34), 송신/수신 소자(36), 스피커/마이크(38), 키패드(40), 디스플레이/터치패드(42), 비 착탈식 메모리(44), 착탈식 메모리(46), 전원(48), GPS 칩셋(50), 및 다른 주변 장치들(52)을 포함할 수 있다. M2M 디바이스(40)는 실시예에 부합하도록 남아 있으면서 전술한 요소들의 임의의 하위 조합을 포함할 수 있다는 것을 이해할 것이다. 이 디바이스는 디바이스 트리거링을 위한 개시된 시스템들 및 방법들을 이용하는 디바이스일 수 있다.

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

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

또한, 송신/수신 소자(36)가 단일 요소로서 도 7c에서 묘사되지만, M2M 디바이스(30)는 임의의 개수의 송신/수신 소자(36)를 포함할 수 있다. 더 구체적으로, M2M 디바이스(30)는 MIMO 기법을 채택할 수 있다. 따라서, 실시예에서, M2M 디바이스(30)는 무선 신호들을 송신 및 수신하기 위한 두 개 이상의 송신/수신 소자들(36)(예를 들어, 다중 안테나)을 포함할 수 있다.

송수신기(34)는 송신/수신 소자(36)에 의해 송신될 신호들을 변조하고 송신/수신 소자(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 앞서 주목한 바와 같이, M2M 디바이스(30)는 다중 모드 능력을 가질 수 있다. 그러므로, 송수신기(34)는 M2M 디바이스(30)로 하여금, 예를 들어, UTRA 및 IEEE 802.11과 같은 다중 RAT를 통해 통신할 수 있게 하기 위한 다중 송수신기를 포함할 수 있다.

프로세서(32)는 비 착탈식 메모리(44) 및/또는 착탈식 메모리(46)와 같은, 임의 유형의 적합한 메모리로부터의 정보에 접근할 수 있고 거기에 데이터를 저장할 수 있다. 비 착탈식 메모리(44)는 랜덤 액세스 메모리(RAM), 판독 전용 메모리(ROM), 하드 디스크, 또는 임의의 다른 유형의 메모리 스토리지 디바이스를 포함할 수 있다. 착탈식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, 보안 디지털(SD) 메모리 카드, 및 그와 유사한 것을 포함할 수 있다. 기타 실시예들에서, 프로세서(32)는 서버 또는 홈 컴퓨터상에서 그런 것처럼, M2M 디바이스(30)상에 물리적으로 자리잡지 않은 메모리로부터의 정보에 접근할 수 있고 거기에 데이터를 저장할 수 있다. 프로세서(32)는, 본 명세서에서 기술되는 실시예들 중 몇몇에서의 트리거링(예로, 서비스 계층 트리거 포트 번호들 또는 부트스트래핑 식별자들)이 성공적인지의 여부에 응답하여 디스플레이 또는 표시자들(42)상에 점등 패턴들, 이미지들, 또는 색들을 제어하거나, 또는 다른 식으로는 리소스 전파 처리들의 상태를 표시하도록 구성될 수 있다.

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

프로세서(32)는 또한 M2M 디바이스(30)의 현재 로케이션에 관련한 로케이션 정보(예를 들어, 경도와 위도)를 제공하도록 구성되는, GPS 칩셋(50)에 결합될 수 있다. M2M 디바이스(30)는 본 실시예에 부합하도록 남아 있으면서, 임의의 적합한 로케이션 결정 방법에 의해 로케이션 정보를 획득할 수 있음을 이해할 것이다.

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

도 7d는, 예를 들어 도 7a 및 도 7b의 M2M 서비스 플랫폼(22)이 그 상에서 구현될 수 있는 예시적 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고 또한 주로 컴퓨터 판독 가능 명령어들에 의해 제어될 수 있는데, 이 컴퓨터 판독 가능 명령어들은 그러한 소프트웨어가 저장되거나 접근되면 어디서든 간에 또는 어떠한 수단에 의해서든 간에 소프트웨어의 형태일 수 있다. 그러한 컴퓨터 판독 가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 행하도록 야기하기 위해 중앙 처리 유닛(CPU)(91) 내에서 실행될 수 있다. 많은 알려진 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서로 지칭되는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다중 프로세서를 포함할 수 있다. 보조프로세서(81)는 메인 CPU(91)와는 구별되고, 부가적 기능들을 실행하거나 CPU(91)를 조력하는 선택 사항 프로세서이다. CPU(91) 및/또는 보조프로세서(81)는 제어 평면상에서 트리거링 메시지를 교환하는 것과 같이, 트리거링을 위한 개시된 시스템들 및 방법들과 관계된 데이터를 수신하고, 발생하고, 및 처리할 수 있다.

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

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

또한, 컴퓨팅 시스템(90)은, 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변 장치들에게 CPU(91)로부터의 명령어들을 통신하는 것을 담당하는 주변 장치 컨트롤러(83)를 포함할 수 있다.

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

또한, 컴퓨팅 시스템(90)은 도 7a 및 도 7b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 연결하는 데 이용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.

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

본 개시의 주제의 양호한 실시예들을 기술할 때, 도면에 도시된 바와 같이, 명료성을 위해 특정 전문 용어가 채택된다. 그러나, 청구된 주제는 그렇게 선택된 특정 전문 용어로만 한정되도록 의도되지 않았고, 각각의 특정 요소는 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 균등물들을 포함하는 것으로 이해해야 한다. 일반적으로, SCS(service capability server), NSCL, 애플리케이션 서버, 및 MTC 서버는 본 명세서에서 교환적으로 이용될 수 있다. M2M 서버에게 알려진 애플리케이션 포트 식별자만이 아니라 임의의 적합한 식별자가 본 명세서에 논의되는 대로 사용될 수 있다. 본 명세서에서 논의되는 트리거링의 사용은 임의의 적절하게 구성된 컴퓨팅 디바이스에 의해 이용될 수 있다. 예를 들어 M2M에 관련되지 않은 디바이스들이 본 명세서의 시스템들 및 방법들을 이용할 수 있다.

이 작성된 설명은, 최상의 모드를 포함하여 본 발명을 개시하기 위해, 또한 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제조하고 사용하며 임의의 통합된 방법들을 수행하는 것을 포함하여 본 발명을 실시하는 것을 가능하게 하기 위해 예들을 이용한다. 본 발명의 특허 가능 범위는 청구항들에 의해 정의되며, 통상의 기술자에게 착안되는 다른 예들을 포함할 수 있다. 그러한 다른 예들은 이들이 청구항들의 문자적 기재와 달라지지 않는 구조적 요소들을 갖는 경우에, 또는 이들이 청구항들의 문자적 기재와 미미한 차이들을 갖는 균등한 구조적 요소들을 포함하는 경우에 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (44)

1. 통신 네트워크에서의 장치로서,
   프로세서; 및
   상기 프로세서에 결합되는 메모리
   를 포함하고, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금:
   원격 디바이스로부터 트리거 메시지를 수신하는 동작 - 상기 트리거 메시지는:
   상기 원격 디바이스의 인터넷 프로토콜 어드레스,
   포트 번호, 및
   triggerPurpose 정보 - 상기 triggerPurpose 정보는 상기 장치와의 브트스트랩 요청을 포함함 -를 포함함 -; 및
   상기 트리거 메시지에 기초하여, 상기 원격 디바이스와 부트스트랩하는 동작 - 상기 부트스트랩하는 동작은 서비스를 위해 인증 및 보안 키 확립을 수행하는 것을 포함함 - 을 포함하는 동작들을 실행하도록 야기하는 실행 가능 명령어들을 저장하는
   통신 네트워크에서의 장치.
2. 제1항에 있어서, 상기 트리거 메시지는 상기 장치의 표적 애플리케이션을 위한 식별자를 더 포함하고, 상기 식별자는 상기 표적 애플리케이션을 식별하는데 사용되는, 장치.
3. 제1항에 있어서, 상기 triggerPurpose 정보는 통신 채널 통지를 더 포함하는, 장치.
4. 제1항에 있어서, 상기 트리거 메시지는 URI(Universal Resource Identifier)를 더 포함하고, 상기 URI는 상기 원격 디바이스 상에 호스트된 리소스를 가리키는, 장치.
5. 제1항에 있어서, 상기 트리거 메시지는 상기 장치가 등록하는 서비스 계층의 식별자를 더 포함하는, 장치.
6. 제1항에 있어서, 상기 트리거 메시지는 리소스에 대한 업데이트를 알려주는 URI에 이전에 가입한 것을 나타내는 통지 URI(Universal Resource Identifier) 필드를 더 포함하는, 장치.
7. 제1항에 있어서, 상기 트리거 메시지는 상기 원격 디바이스와의 통신을 위한 프로토콜의 표시를 더 포함하는, 장치.
8. 제1항에 있어서, 상기 원격 디바이스는 네트워크 서버인, 장치.
9. 방법으로서,
   장치에 의해, 원격 디바이스로부터 트리거 메시지를 수신하는 단계 - 상기 트리거 메시는:
   상기 원격 디바이스의 인터넷 프로토콜 어드레스,
   포트 번호, 및
   triggerPurpose 정보 - 상기 triggerPurpose 정보는 상기 장치와의 브트스트랩 요청을 포함함 -를 포함함 -; 및
   상기 트리거 메시지에 기초하여, 상기 원격 디바이스와 부트스트랩하는 단계 - 상기 부트스트랩하는 단계는 서비스를 위해 인증 및 보안 키 확립을 수행하는 것을 포함함 -
   를 포함하는 방법.
10. 제9항에 있어서, 상기 트리거 메시지는 상기 장치의 표적 애플리케이션을 위한 식별자를 더 포함하고, 상기 식별자는 상기 표적 애플리케이션을 식별하는데 사용되는, 방법.
11. 제9항에 있어서, 상기 triggerPurpose 정보는 통신 채널 통지를 더 포함하는, 방법.
12. 제9항에 있어서, 상기 트리거 메시지는 URI(Universal Resource Identifier)를 더 포함하고, 상기 URI는 상기 원격 디바이스 상에 호스트된 리소스를 가리키는, 방법.
13. 제9항에 있어서, 상기 트리거 메시지는 리소스에 대한 업데이트를 알려주는 URI에 이전에 가입한 것을 나타내는 통지 URI(Universal Resource Identifier) 필드를 더 포함하는, 방법.
14. 제9항에 있어서, 상기 트리거 메시지는 상기 원격 디바이스와의 통신을 위한 프로토콜의 표시를 더 포함하는, 방법.
15. 통신 네트워크에서의 장치로서,
    프로세서; 및
    상기 프로세서에 결합되는 메모리
    를 포함하고, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금:
    원격 디바이스로 트리거 메시지를 전송하는 동작 - 상기 트리거 메시지는:
    상기 원격 디바이스의 인터넷 프로토콜 어드레스,
    포트 번호, 및
    triggerPurpose 정보 - 상기 triggerPurpose 정보는 상기 장치와의 브트스트랩 요청을 포함함 -를 포함함 -; 및
    상기 트리거 메시지에 기초하여, 상기 원격 디바이스와의 부트스트랩 요청을 수신하는 동작 - 상기 부트스트랩은 서비스를 위해 인증 및 보안 키 확립을 수행하는 것을 포함함 - 을 포함하는 동작들을 실행하도록 야기하는 실행 가능 명령어들을 저장하는 장치.
16. 제15항에 있어서, 상기 트리거 메시지는 상기 장치의 표적 애플리케이션을 위한 식별자를 더 포함하고, 상기 식별자는 상기 표적 애플리케이션을 식별하는데 사용되는, 장치.
17. 제15항에 있어서, 상기 triggerPurpose 정보는 통신 채널 통지를 더 포함하는, 장치.
18. 제15항에 있어서, 상기 트리거 메시지는 URI(Universal Resource Identifier)를 더 포함하고, 상기 URI는 상기 원격 디바이스 상에 호스트된 리소스를 가리키는, 장치.
19. 제15항에 있어서, 상기 원격 디바이스는 사용자 장비인, 장치.
20. 제15항에 있어서, 상기 트리거 메시지는 리소스에 대한 업데이트를 알려주는 URI에 이전에 가입한 것을 나타내는 통지 URI(Universal Resource Identifier) 필드를 더 포함하는, 장치.
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제
41. 삭제
42. 삭제
43. 삭제
44. 삭제

Images