KR20180136521A - 서비스 레이어에서의 데이터 스트림 애널리틱스 - Google Patents

서비스 레이어에서의 데이터 스트림 애널리틱스 Download PDF

Info

Publication number
KR20180136521A
KR20180136521A KR1020187033823A KR20187033823A KR20180136521A KR 20180136521 A KR20180136521 A KR 20180136521A KR 1020187033823 A KR1020187033823 A KR 1020187033823A KR 20187033823 A KR20187033823 A KR 20187033823A KR 20180136521 A KR20180136521 A KR 20180136521A
Authority
KR
South Korea
Prior art keywords
dsas
stream
data
query
data stream
Prior art date
Application number
KR1020187033823A
Other languages
English (en)
Other versions
KR102372219B1 (ko
Inventor
스네하 아만 싱
쉬 리
취앙 리
그레고리 에스. 스턴버그
샤밈 아크바르 라만
충강 왕
Original Assignee
콘비다 와이어리스, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 콘비다 와이어리스, 엘엘씨 filed Critical 콘비다 와이어리스, 엘엘씨
Publication of KR20180136521A publication Critical patent/KR20180136521A/ko
Application granted granted Critical
Publication of KR102372219B1 publication Critical patent/KR102372219B1/ko

Links

Images

Classifications

    • G06F17/30516—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24568—Data stream processing; Continuous queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/18—Protocol analysers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Automation & Control Theory (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)
  • Computer Hardware Design (AREA)

Abstract

DSAS(Data Stream Analytics Service)라고 불리는, 데이터 스트림 애널리틱스 능력들을 IoT/M2M 서비스 레이어에 통합하기 위한 데이터 스트림 프로세싱 및 분석을 위한 모듈식 분산 아키텍처가 기술된다. DSAS를 호스팅하는 각각의 서비스 레이어 노드는 2개의 독립적 모듈, 스트림 포워더 및 스트림 애널리틱스 엔진으로 분할될 수 있다. 스트림 포워더는 데이터 프리프로세싱 및 라우팅을 책임지고 있을 수 있는 경량 프로세싱 모듈들이다. 스트림 애널리틱스 엔진은 데이터 스트림에 대해 실제 애널리틱스를 수행하는 일을 책임지고 있다. 2개의 기능성을 분리하는 것은 서비스 레이어 노드들이 스트림 애널리틱스 태스크들을 다수의 노드들에 걸쳐 효율적으로 분산시키는 것을 가능하게 해준다.

Description

서비스 레이어에서의 데이터 스트림 애널리틱스
관련 출원들의 상호 참조
본 출원은 2016년 4월 25일자로 출원된 미국 가특허출원 제62/326,894호의 이익을 주장하며, 이 미국 출원의 개시내용은 이로써 그 전체가 기재된 것처럼 참고로 포함된다.
데이터 스트림은 이벤트들, 메시지들 등의 형태로 상호접속된 통신 채널들을 거쳐 노드들 사이에서 전송되는 중인 연속적이고 동적인 데이터(정보) 시퀀스이다. 데이터 스트림은 전형적으로 디스크 메모리와 같은 스토리지에 아직 저장되지 않은 데이터이다. 데이터 스트림은 거대할 수 있으며 잠재적으로 크기가 무제한이고, 시변이며, 그리고 많은 경우들에서, 고 처리량을 갖는다.
거대하고, 고 처리량이며 동적인 데이터의 좋은 예는 인터넷 트래픽 데이터이다. Internet Live Stats 웹 사이트에 따르면, 수천 페타바이트의 인터넷 트래픽 데이터가 매일 생성된다. 데이터 스트림들의 어떤 다른 예들은 통신 데이터, 위성 데이터, 주식 시장/금융 거래 데이터이다.
IoT/M2M(Internet of Things/Machine to Machine) 응용분야들도 많은 양의 데이터 스트림들을 생성한다. IoT/M2M 시스템들 내의 "사물들/머신들"의 수가 증가함에 따라, IoT/M2M 디바이스들로의 그리고 그것들로부터의 스트리밍 데이터의 볼륨이 기하급수적으로 증가하고 있다. 도 1은 스마트 홈 셋업에서의 접속된 디바이스들을 도시하고 있다. 이러한 디바이스들은 데이터를 계속 생성하며 그리고 데이터를 전송/수신함으로써 시스템 내의 다른 디바이스들과 통신하여, 분산된 소스들 및 디바이스들로부터의 많은 양의 데이터 스트림들의 연속적인 생성을 가져온다.
데이터 스트림 'S'는 튜플들(tuples)의 시퀀스로서 표기될 수 있으며, 여기서 각각의 튜플은 <a1, a2, ..., an> 포맷을 가지며 여기서 'ai'는 튜플의 i 번째 애트리뷰트(attribute)(또는 속성(property))이다. 도 2는 GPS(Global Positioning System) 트래킹 차량과 같은 GPS 프로브 디바이스에 의해 생성된 예시적인 데이터 스트림을 도시하고 있다. 도면에서의 각각의 행(line)은 하나의 튜플을 나타내고, 각각의 튜플은 6개의 애트리뷰트: 타임스탬프, GPS 데이터의 유효성('A'는 데이터가 유효하다는 것을 표기함), 위도, 경도, 고도, 및 속도로 이루어져 있다. (GPS 데이터 스트림 튜플은 일반적으로 도 2에 도시된 것보다 더 많은 애트리뷰트들을 포함한다. 도 2에 예시된 GPS 데이터 스트림 튜플은 간단함을 위해 단축되었다.)
많은 응용분야들에서, 데이터 스트림으로부터 검색된 정보에 기초하여 필요한 조치들 또는 대책들이 실시간으로 취해질 수 있도록 여전히 스트리밍하는 중인 데이터를 이해하는 것이 매우 중요하다.
스트리밍 데이터의 기하급수적 증가에 따라, 데이터로부터 실시간으로 의미 있는 통찰들을 도출하는 것이 점점 더 중요해지고 있다. 데이터 스트림 애널리틱스(analytics)(또는 스트림 애널리틱스 또는 스트리밍 데이터 애널리틱스)는 연속적이고 스트리밍하는 데이터로부터 유용한 정보를 실시간으로 추출하고 도출하는 프로세스이다. 스트림 애널리틱스는 데이터 스트림들로부터 이벤트들, 패턴들 또는 추세(trend)들을 검출하거나 식별하는 것, 데이터 스트림들에 대한 통계적 집계를 계산하는 것, 및 데이터 스트림들에 대한 상관 및 예측 분석을 수행하는 것을 포함하지만, 이들로 제한되지 않는다. 실시간 스트림 애널리틱스가 많이 사용되는 하나의 예시적인 응용분야는 네트워크 공격들을 실시간으로 식별하고 예측하는 것이 노드 또는 노드들의 네트워크가 손상되는 것을 방지할 수 있는 네트워크 보안 도메인이다. 데이터 스트림 애널리틱스의 어떤 다른 중요한 예시적인 응용분야들은 주가 예측, 동적 네트워크 성능 모니터링 및 튜닝, 및 실시간 사기 탐지(fraud detection)이다.
IoT/M2M의 진화와 세상의 센서들 및 디바이스들에 대한 의존성의 증가에 따라, 이 디바이스들에 의해 생성되는 풍부한 데이터를, 데이터가 생성되는 것과 거의 동시에(almost as fast as), 분석할 필요성이 증가하고 있다. 이 데이터의 대부분에 대해, 진정한 가치는 데이터에 숨겨진 정보를 실시간으로 활용하고 데이터에 의해 제공되는 통찰들에 기초하여 즉각적인 조치들을 취하는 데 있다. 따라서, 실시간 데이터 애널리틱스는 IoT/M2M 시스템들의 필요불가결한 부분이 되기 시작하고 있다.
교차로에서의 교통의 효율적이고 안전한 관리를 위한 프레임워크인 지능형 교차로 교통 시스템(Intelligent Intersection Traffic System)(IITS)의 예를 생각해본다. IITS의 효율적인 구현은 교차로에서의 교통 조건들에 따라 실시간 의사 결정을 하는 것 및 필요한 실시간 경보들을 생성하는 것에 의해 교차로에서의 교통 충돌들을 크게 감소시킬 수 있다.
데이터 스트림의 동적 성질, 즉 데이터 스트림의 시변 속성들로 때문에, 전통적인 방법들을 사용하여 스트림을 프로세싱하고 분석하는 것은 몇 가지 과제들을 제기한다. 애널리틱스가 다수의 이유들로 동적 데이터에 대해서는 어렵다.
온-더-플라이 프로세싱(On-the-fly processing) - 데이터 스트림의 가장 기본적인 개념은 데이터 스트림이 연속적인 스트리밍 상태에 있으며 그것의 관찰 시간 동안에는 어떠한 디스크 또는 데이터베이스에도 저장되지 않는다는 것이다. 이것은 데이터 스트림에 대한 다중 패스(multiple passes), 즉 데이터 스트림을 백트래킹(backtracking)하는 것을 거의 불가능하게 만든다. 따라서, 스트리밍 애널리틱스를 위해 요구되는 필요한 정보 전부가 증분적 방식으로 단일 패스에서 데이터로부터 검색될 필요가 있다.
데이터 스트림의 거대한 크기, 작은 프로세싱 시간 및 제한된 메인 메모리 제약 - 크고, 어쩌면 무제한인 데이터 스트림의 크기로 인해, 실시간 분석을 위해 데이터 스트림 전체를 디스크에 일시적으로 저장하는 것은 일반적으로 현실적으로 실현불가능하다. 실시간 분석을 수행하기 위해, 데이터 스트림이 (응용분야에 따라) 작은 프로세싱 시간 내에 프로세싱되고 분석될 필요가 있다. 게다가, 매우 작은 프로세싱 시간을 사용하여 실시간으로 데이터를 분석해야 한다는 부가의 요구사항은 데이터를 분석을 위해 디스크에 저장하는 것을 훨씬 더 실현불가능하게 만든다. 데이터를 디스크로부터 판독하는 것 및/또는 데이터를 디스크에 기입하는 것(디스크 입력/출력 또는 디스크 I/O라고도 불림)의 오버헤드는 매우 높으며 메인 메모리(예를 들어, 랜덤 액세스 메모리 또는 RAM)에서의 데이터 프로세싱 - 데이터의 인-메모리 프로세싱(in-memory processing)이라고도 불림 - 과 비교할 때 데이터의 프로세싱 시간에 상당한 지연을 추가한다. 이러한 부가의 오버헤드는 데이터의 저장을 실시간 분석에 부적합하게 만든다.
게다가, 데이터 스트림의 거대한 크기 및 메인 메모리의 제한된 크기로 인해, 데이터 스트림 전체를 메인 메모리에 저장하는 것이 현실적으로 실현가능하지 않다. 메인 메모리의 크기는 요즈음 일반적으로 기가바이트 또는 GB(109 바이트) 정도인 반면, 데이터 스트림의 크기는 페타바이트 또는 PB(106 GB) 이상의 정도일 수 있다. 따라서, 많은 경우들에서, 애널리틱스 목적으로 요구된, 데이터로부터의 중요한 정보만이 추출되고 메인 메모리에 간결한 방식으로 저장된다.
데이터 스트림의 고 처리량 - 많은 응용분야들에서, 데이터의 생성 레이트는 테라바이트/초(TB/s) 이상의 정도로 매우 높을 수 있다. 그러한 고 처리량의 데이터를 작은 시간 윈도에서 프로세싱하는 것은 스트림 애널리틱스에 부가의 과제를 추가한다.
데이터 스트림의 동적이고 일시적인 성질로 인해, 스트림 프로세싱/분석을 위해 전통적인 데이터베이스 관리 시스템(Database Management System)(DBMS) 또는 다른 전통적인 배치 프로세싱 시스템(batch processing system)을 사용하는 것이 현실적으로 실현가능하지 않다. 실시간 애널리틱스를 위해 전통적인 DBMS를 사용하는 것의 주된 과제는 데이터 스트림을 디스크 상에 로컬로 저장하거나 데이터 스트림에 걸쳐 백트래킹하는 것이 현실적으로 실현가능하지 않다는 사실로부터 발생한다. 따라서, 저장된 데이터가 가능한 한 여러 번 백트래킹될 수 있는 DBMS에서와 달리, 데이터 스트림이 단일 패스에서 프로세싱되고 분석될 필요가 있다. 데이터 스트림에 대한 단일 패스 제약은 또한, 데이터 스트림이 관찰되자마자 데이터 스트림이 증분적으로 분석되도록, 데이터 분석에 관련된 쿼리들이 오래 실행되고 연속적이며 지속적일 필요가 있다는 것을 의미한다. 이것은 데이터가 일반적으로 정적이고 따라서 쿼리들이 애드혹(ad hoc)인 전통적인 DBMS와 정반대이다. 표 1은 (디스크에 저장된) 디스크 상주 데이터(disk resident data)와 비교하여 데이터 스트림을 프로세싱하는 것에 대한 요구사항들의 주요 차이점들을 나타내고 있다.
Figure pct00001
도 3은 데이터 스트림 프로세싱 시스템(DSPS)(302) 또는 데이터 스트림 관리 시스템(DSMS)의 일반적인 논리 프레임워크를 도시하고 있다. 이 시스템은 데이터 스트림을 계속 관리하고 프로세싱하는 프로세싱 엔진(304)을 갖는다. 데이터 스트림 전체를 메모리에 저장하는 것의 실현불가능성은 관찰된 데이터 스트림을 요약하고 스트림으로부터의 중요한 정보만을 간결한 방식으로 저장하는 것을 의미한다. 우리는 데이터 스트림을 요약하기 위해 데이터로부터 추출된 간결한 정보를 스트림 시놉시스(stream synopsis) 또는 스트림 상태(stream state)라고 지칭한다. 스트림 상태는 일반적으로 데이터 스트림의 크기와 비교하여 크기가 훨씬 더 작다. 따라서, 스트림 상태는 보다 빠른 액세스를 위해 메모리에 저장될 수 있다.
DSPS(302)는 DSPS(302)에서 실행 중인 쿼리들에 따라 스트림 상태를 생성한다. 이러한 쿼리들은, 앞서 논의된 바와 같이, 오래 지속되고 연속적이며, 즉, DSPS가 쿼리들에 따라 대응하는 시놉시스를 생성하도록 쿼리들이 미리 정의될 필요가 있다. 스트림 상태가 스트림 전체의 요약에 불과하기 때문에, 쿼리에 대한 대답들이 대략적일 수 있다. 일반적으로 대략적인 쿼리들의 경우에, 그러한 쿼리들로부터 결과들을 도출하는 데 관심이 있는 사용자들 또는 애플리케이션들은 자원 대 정확도 트레이드오프를 제공받는다. 쿼리에 관련된 분석 동작을 위해 할당(allocate)된 메모리(및/또는 프로세싱 용량)의 크기가 클수록 대답이 높다.
데이터 스트림 프로세싱 시스템을 이해하기 위해, 우리는 가장 근본적이고 기본적인 문제들 중 하나인 카운팅(counting)을 생각해본다. 우리는, 교통 제어 허브(traffic control hub)라고도 알려진, 중앙집중식 서버 상에 설치된 DSPS(302)를 갖는 지능형 교차로 교통 시스템(IITS)의 예를 생각해본다. 이 교통 제어 허브는, 예를 들어, 게이트웨이일 수 있다. 교통 제어 허브는 각각의 방향에서 교차로를 가로지르는 자동차들의 수를 실시간으로 트래킹하기 위해 DSPS(302)를 사용한다. 자동차들의 수를 카운팅하는 것의 잠재적인 이점들 중 하나는 교통 양상 변화(traffic phase change)를 실시간으로 관리하는 것, 즉, 교차로에서의 교통 흐름 상태에 따라, 실시간으로 교통 신호를 빨간색에서 녹색으로, 기타 등등으로 변경하는 것이다. 교통 카메라들이 주변의 비디오를 캡처하도록, 교차로의 각각의 측면과 마주하게, 교차로에 설치된다. 스트림 애널리틱스 컨텍스트로부터, 각각의 교통 카메라에 의해 생성된 비디오는 데이터 스트림으로서 간주될 수 있으며, 각각의 비디오 프레임은 하나의 데이터 요소로서 간주될 수 있다.
이 경우에, 데이터 스트림 프로세싱 시스템이 다음과 같은 쿼리를 얻는다고 가정한다: 각각의 방향에서 교차로를 가로지르는 자동차들의 수를 카운트하기. 교통 제어 허브(302)는 실시간으로 비디오로부터 유용한 특징들을 추출함으로써 비디오 스트림에서 자동차들을 식별하기 위해 비디오 애널리틱스 기법들을 사용한다. 자동차들이 식별되고 각각의 방향으로부터 교차로를 가로지르는 자동차들의 카운트가 실시간으로 유지된다. 이 경우에, 메모리에 저장된 스트림 상태는 교통 흐름의 각각의 방향에 대한 단일 정수 변수, 말하자면 count 만큼 간단할 수 있다. 도 4는 스트리밍 환경에서의 이 문제를 예시하고 있다. 간단함을 위해 그리고 일반성을 잃지 않으면서, 우리는 도면에서 왼쪽에서 오른쪽으로 이동하는 자동차들에 대해 유지된 카운트만 나타내고 있다.
교차로를 왼쪽에서 오른쪽으로 가로지르는 매 자동차에 대해, 제어 허브에 있는 DSPS(302)는 비디오 스트림을 분석함으로써 자동차를 식별하고 DSPS(302)의 메모리에 저장된 'count' 변수를 1만큼 증가시킨다. 예를 들어, 도 4a에서, 제어 허브(302)는 분석의 시작 이후 교차로를 가로지른 첫 번째 자동차를 관찰한다. 제어 허브(302)는 인-메모리 상태 "count"를 (초기에서의) 0으로부터 1로 업데이트한다. 도 4b에서, 제어 허브(302)는 교차로를 가로지르는 두 번째 자동차를 관찰하고, 따라서 상태 "count = 2"를 업데이트한다. 이와 유사하게, 도 4에서, 상태 "count"가 제어 허브에 의해 5로 업데이트되었다. 자동차들의 카운트를 계산하기 위해, 데이터 스트림 전체가 저장될 필요는 없으며, 즉, 데이터 스트림인 스트리밍 비디오가 실시간으로 프로세싱/분석될 필요가 있다. 이 문제에 대해 메모리에 저장된 유일한 정보는 업데이트된 카운트이며, 이는 그것이 정수 데이터 타입이라고 가정하면 8 바이트의 메모리 공간을 필요로 한다. 이러한 메모리 공간의 양(8 바이트)은 붐비는 교차로에서 생성되는 수 기가바이트의 스트리밍 비디오와 비교하여 상당히 적다.
상기 예는 매우 간단한 것이다. 여기서, 스트림 상태가 쿼리에 대답하는 데 직접 사용된다. 그러나 많은 복잡한 쿼리들에서, 스트림 상태는 일반적으로 대답을 직접 포함하지 않지만 필요에 따라 대답을 계산하는 데 사용된다. 다양한 복잡도들의 상이한 문제들에 대해서도 실시간 스트림 애널리틱스를 위해 작은 공간 스트림 상태를 메모리에 유지하기 위한 효율적인 알고리즘들을 설계하기 위해 많은 연구가 행해지고 있다.
분산 데이터 스트림 프로세싱 시스템은 하나 이상의 데이터 스트림이 단일 또는 다수의 쿼리에 대답하기 위해 다수의 스트림 프로세싱 노드들에 걸쳐 프로세싱되고 분석되는 경우이다. 일반적으로, 분산 스트림 프로세싱 시스템은 분산 노드들 간의 데이터 통신을 조율하는 코디네이터 노드(coordinator node)를 갖는다. 상기 예(도 4)에서, DSPS(302) 기능성을 갖는 제어 허브가 쿼리에 대답하기 위해 스트림 애널리틱스 동작들 전부를 수행하는 경우, 이는 중앙집중식 스트림 프로세싱 시스템이라고 불린다.
다른 한편으로, 도 5에 도시된 바와 같이, 애널리틱스 전체가 제어 허브에서 행해지는 대신에 비디오 애널리틱스 동작들 중 일부가 또한 교통 카메라들에 의해 수행된다고 가정한다. 교통 카메라 1, 교통 카메라 2, 교통 카메라 3 및 교통 카메라 4가, 제각기, 동쪽, 남쪽, 서쪽 및 북쪽으로부터 오는 교통을 캡처한다고 가정한다. 이러한 카메라들 각각은 비디오 데이터 스트림을 생성한다. 스트림 애널리틱스 능력을 갖는 이러한 카메라들이 또한 설치된다고 가정한다. 따라서, 차량들을 카운팅하는 상기 예에서, 차량일 확률이 높은 물체들을 식별하는 것과 같은, 비디오 애널리틱스 동작들 중 일부가 교통 카메라에 의해 수행된다. 이제, 비디오 스트림 전체를 송신하는 대신에, 교통 카메라 1, 교통 카메라 2, 교통 카메라 3 및 교통 카메라 4 각각은 그 각자의 스트림 상태(제각기, S1, S2, S3 및 S4)만을 제어 허브에게 송신한다. 이 상태들은 차량일 확률이 높은 그 물체들만을 포함한다. 제어 허브(302)는 여기서 코디네이터로서 기능하고, 이 카메라들 각각으로부터 상태를 수신한다. 이제 제어 허브(302)는 교차로에서의 교통 흐름의 전체 볼륨을 제공하기와 같은 쿼리들에 대답하기 위해 S1, S2, S3 및 S4의 합집합(union)을 사용한다. 교통 카메라들이, 스트림 전체 대신에, 그 각자의 스트림 상태만을 제어 허브에게 전송하기 때문에, 데이터 프로세싱의 통신 비용이 대폭 감소된다.
이러한 종류의 시스템은 데이터 스트림 전체 대신에 통신 채널을 거쳐 필요한 정보만을 송신함으로써 통신 비용을 상당히 감소시킨다. 분산 데이터 스트림 프로세싱 시스템은 또한 분산 시스템에 걸쳐 데이터 스트림 애널리틱스의 로드를 밸런싱하는 데 도움을 주는데, 그 이유는 이제 제어 허브가 상당히 더 낮은 볼륨의 데이터 스트림을 관리하게 되고, 따라서 시스템의 효율성을 개선시키기 때문이다.
현재의 데이터 스트림 프로세싱 플랫폼들
적은 메모리 비용을 사용하여, 실시간으로 큰 데이터 스트림으로부터 최대/최소, 고유 요소들의 수, 빈번한 항목들 등을 찾아내는 것과 같은, 중요한 문제들을 해결하는 것에 관한 연구가 행해져왔다. 데이터 스트림 프로세싱의 아키텍처 상세들의 복잡한 사항들에 들어가지 않으면서, 데이터 스트림 애널리틱스를 수행하도록 비즈니스 또는 사용자들에게 추상화를 제공하는, 오픈 소스는 물론 독점적인, 많은 스트림 프로세싱 플랫폼들이 있다. 그러한 복잡한 사항들은 메시지 큐잉, 확장성, 결함 허용(fault tolerance), 병렬성(parallelism) 등을 포함할 수 있다.
데이터 스트림 프로세싱 플랫폼들의 예들은 Apache Storm, IBM Infosphere Stream 및 Apache Spark Streaming을 포함한다. 이러한 스트림 프로세싱 플랫폼들은 스트리밍 방식으로 데이터를 캡처하고 결함 허용이며 신뢰성 있는 스트림 프로세싱을 위한 플랫폼을 제공하는 수단을 제공한다. 이러한 플랫폼들은, 스트림 프로세싱을 지원하는 플랫폼들의 아키텍처 관점보다는, 데이터 스트림이 어떻게 실시간으로 프로세싱되는지에 대한 논리적 관점을 제공하는 상기 데이터 스트림 프로세싱 시스템(도 3에 도시됨)에 직접 매핑되지 않을 수 있다.
Apache Storm은 오픈 소스 분산 스트림 프로세싱 플랫폼이다. 이는 신뢰성 있고 결함 허용이며 확장가능한 시스템이다. 도 6에 도시된 바와 같이, 이는 두 가지 종류의 노드: 마스터(Master)(602) 및 워커(Worker)(604)를 갖는다. 마스터 노드(602)는 태스크들을 모든 워커 노드들(604)에 배정(assign)하고 클러스터에서의 장애들을 모니터링하는 Nimbus 데몬을 실행한다. 워커 노드(604)는 Nimbus 데몬에 의해 배정된 임의의 작업(work)이 있는지 리스닝하고 워커 노드에 배정된 작업을 시작/중지하기 위해 워커 프로세스들을 스포닝(spawn)하는 Supervisor 데몬을 실행한다. Apache Storm은 마스터 노드(602)와 워커 노드(604) 간의 조율을 위해, 중앙집중식 서비스인, Zookeeper에 의존한다.
Apache Storm은 세 가지 추상화를 사용한다:
Figure pct00002
스파우트(Spout) - Storm 프로세싱 시스템의 계산 프레임워크 내의 스트림들의 소스,
Figure pct00003
볼트(Bolt) - 데이터 스트림을 프로세싱하기 위한, 최대(maximum), 평균(average)과 같은, 주요 계산 로직으로 이루어져 있다. 각각의 볼트는 입력 데이터 스트림들의 세트를 프로세싱하고 그것들을 계산 로직을 사용하여 다른 출력 스트림들의 세트로 변환하며, 그리고
Figure pct00004
토폴로지(Topology) - 이는 "유향 비순환 그래프(directed acyclic graph)"로서 서로 접속된 스파우트들 및 볼트들의 네트워크이다. Storm에서 작성되는 매 애플리케이션은 토폴로지로서 설계된다.
도 7은 문장들의 스트림으로부터 상이한 단어들의 출현을 카운팅하는 단어 카운트 애플리케이션의 일 예를 도시하고 있다. 도면은 스파우트들 및 볼트들의 토폴로지를 나타낸다. 다수의 스파우트들이 분산 클러스터의 단일 노드 또는 상이한 노드들 상에 있을 수 있다. 소스는 (원시 포맷의) 문장들로 이루어진 데이터 스트림을 로드 밸런싱을 위해 2개의 스파우트를 거쳐 송신한다. 각각의 스파우트는 차례로, 각각의 문장을 튜플로서 갖는, 스트림을 그 각자의 Split 볼트에게 포워딩한다. 각각의 Split 볼트는 자신이 수신하는 문장을 토큰화하고 문장에서의 각각의 단어의 출현 횟수를 카운팅한다. 동일한 단어가 다수의 볼트들에서 카운팅되는 것을 피하기 위해 상이한 Count 볼트들이 항상 비중첩 단어들의 세트를 수신하도록, [단어, 카운트]를 튜플로서 갖는, 각각의 Split 볼트에 의한 출력 스트림이 이어서 Count 볼트들 중 하나에게 포워딩된다. 따라서, 도 7에서 도시된, 동일한 수직 칼럼 내의 스파우트들 또는 볼트들은 애플리케이션의 로드 밸런싱 및 병렬화에 도움을 주어, 애플리케이션의 보다 빠르고 확장가능한 실행을 가져온다. 단어 카운트 응용분야를 구현하는 다른 방식들이 있으며 도 7은 접근법들 중 단지 하나를 예시하고 있다.
IBM Infosphere Streams는 다른 인기 있는 분산 스트림 프로세싱 플랫폼이다. 이는 결함 허용이고, 신뢰성 있으며 확장가능한 시스템이다. IBM Infosphere Streams 분산 클러스터 내의 노드들 전부는 스트림 애플리케이션을 실행하는 데 똑같이 참여할 수 있다. Infosphere Streams는 다음과 같은 주요 개념들을 갖는다:
1) 연산자들(operators): 데이터 스트림을 변환하고 조작하는 데 사용되는, 최대, 평균과 같은, 계산 로직으로 이루어져 있다. 연산자들은 데이터 스트림들의 세트를 입력으로서 취하고 그것들을 계산 로직에 기초하여 변환하여 다른 출력 스트림들의 세트를 생성한다.
2) 데이터 흐름 그래프: 그래프의 노드들이 연산자들이고 연산자들을 접속시키는 에지들이 다른 연산자에 입력 스트림으로서 접속되는 하나의 연산자로부터의 나가는 스트림(outgoing stream)이도록, 스트림 애플리케이션이 그래프의 형태로 작성된다.
3) 프로세싱 요소(PE): 데이터 흐름 그래프가 streams 애플리케이션의 분산 및 병렬화를 가능하게 해주기 위해 분해되는, 하나 이상의 연산자로 이루어진, 개별 실행 유닛들.
도 8은 IBM Infosphere Streams의 런타임 실행을 도시하고 있으며, 여기서 IBM Infosphere Streams의 각각의 런타임 인스턴스에 대응하는 하나 이상의 잡(job)이 생성된다. 단어 카운트 문제와 같은, 특정한 애널리틱스 동작을 수행하는 각각의 스트림 애플리케이션이 고유 잡에 제출된다. 이 스트림 애플리케이션은 이어서 애플리케이션의 데이터 흐름 그래프에 기초하여 하나 초과의 PE로 분할된다.
IBM Infosphere Stream에서 데이터 스트림 애플리케이션을 작성하는 개념은 Apache Storm과 매우 유사하다. 우리는, IBM Infosphere Streams에서의 스트림 애플리케이션의 실행을 예시하기 위해, 이하에서 도 9에서 Apache storm에 대해 사용되는 것과 동일한 단어 카운트를 사용한다. 이 예에서, 각각의 연산자는 개별 PE들에 의해 실행된다. 동일한 수직 칼럼에 있는 PE들은 병렬화될 수 있으며 수평 로우들에 걸쳐 있는 PE들은 다수의 노드들에 분산될 수 있다.
Apache Spark Streaming은, 최근에 아주 인기를 얻게 된, 다른 분산 스트림 프로세싱 플랫폼이다. 이는 또한 결함 허용이고, 신뢰성 있으며 확장가능한 시스템이다. 그렇지만, Apache Spark Streaming에 의해 사용되는 접근법은 앞서 언급된 플랫폼들의 접근법과 비교하여 상이하다. Apache Spark Streaming(1002)은 데이터 스트림들을 프로세싱하기 위해 마이크로 배치 프로세싱(micro batch processing)을 사용하며, 즉 도 10에 도시된 바와 같이, 데이터 스트림을 작은 배치들(batches)로 분할하고 데이터의 작은 배치들을 프로세싱하는 데 배치 프로세싱 시스템인 Apache Spark Engine(1004)을 사용한다.
Apache Spark Streaming은 이산 스트림(discretized stream)(D-Stream)이라고 불리는 하이 레벨 추상화를 제공한다. D-stream들은, RDD(Resilient Distributed Dataset)라고 불리고 작은 결정적 배치 잡들(deterministic batch jobs)로서 실행되는, 작은 시간 간격들의 배치들로 초핑(chop)된 데이터 스트림들이다. 도 11은 D-Stream과 RDD의 개념을 도시하고 있다.
도 12는 D-stream 프로세싱을 예시하고 있다. 데이터 스트림은 시간 간격들에 기초하여 RDD라고 불리는 작은 배치들로 분할된다. 이러한 RDD들은, 최종 출력을 생성하기 위해, 애널리틱스 동작들을 수행하는 계산/집계 로직을 사용하여 몇 라운드의 변환을 거친다. 각각의 세로 칼럼에 있는 RDD들은 다른 칼럼들에 있는 RDD들과 독립적으로 변환될 수 있으며 따라서 병렬화 및 효율적인 로드 분산(load distribution)을 가능하게 해준다.
데이터 스트림 애널리틱스의 중요성이 IoT/M2M 도메인에서 상당히 증가하고 있다. 점점 더 많은 수의 디바이스들이 인터넷에 접속되고 상호접속된 IoT/M2M 디바이스들의 배포들(deployments)의 수가 증가함에 따라, 이러한 디바이스들과 그것들의 사용자들의 데이터에 대한 의존성도 증가하고 있다. 이러한 다양한 데이터 스트림들이 생성되는 것과 거의 동시에(almost as soon as) 그것들로부터 어떤 신속한 통찰들을 도출하는 것이 점점 더 중요해지고 있다. IoT/M2M에서의 실시간 애널리틱스의 중요성의 일부는 다음과 같다:
1) 실시간 정보 추출/의사 결정 : IoT/M2M 센서들 및 디바이스들은 많은 양의 데이터를 생성한다. 엔터프라이즈들과 비즈니스들은 데이터를 분석하는 것, 의미 있는 통찰들을 도출하는 것 및 결과들에 따라 신속하게 대처하는 것에 의해 많은 것을 얻을 수 있다. 많은 IoT/M2M 응용분야들에서, 디바이스/머신은 즉각적이고 적절한 조치들을 취하기 위해 자율적으로 또는 다른 디바이스들과의 부가의 컨텍스트 또는 관계를 사용하여 실시간 의사 결정을 하는 것을 필요로 한다.
2) 데이터의 적시성 : 많은 경우들에서, 디바이스에 의해 생성된 데이터로부터 도출되는 통찰들은, 데이터가 생성되는 것과 거의 동시에, 데이터가 실시간으로 분석되는 경우 최대 잠재력을 가져올 수 있다.
3) 제한된 저장 자원 : 제한된 자원들로 인해, 디바이스 데이터의 일부가 그것으로부터 유용한 정보를 추출한 후에 폐기될 수 있다면 비용 효과적일 수 있다. 데이터 스트림 애널리틱스는 데이터 전부를 저장할 필요가 없으면서 데이터를 필터링, 집계 및 분석할 수 있다. 스토리지 요구사항들이, 많은 응용분야들에서, 데이터 스트림을 실시간으로 그리고 메모리에서 프로세싱하는 것 및 가치 있는 결과적인 정보만을 존속시키는 것에 의해 대폭 감소될 수 있다.
4) 효율성 : 많은 경우들에서, 실시간 분석이 요구되지 않더라도, 데이터를 저장하는 것 그리고 이어서 정보를 찾아내기 위해 배치 프로세싱을 행하는 것보다 데이터가 관찰되는 때에 데이터를 프로세싱하는 것이 훨씬 더 효율적일 수 있다.
위의 사항들이 또한 스트림 애널리틱스를 필요로 하는 다른 도메인들의 대부분에 대해서도 적용가능하지만 이러한 요구사항들이 IoT/M2M 시스템과 강하게 관련될 수 있다. 데이터 스트림 애널리틱스를 지원하는 강건한 IoT 플랫폼들을 제공하는 많은 벤더들/회사들이 있다. 이하는, IoT 플랫폼 또는 통합 스트림 프로세싱 시스템 중 어느 하나를 통해, 이러한 IoT 인프라스트럭처들의 대부분에 의해 제공되는 주요 이점들이다.
Figure pct00005
복잡한 데이터 애널리틱스 능력들
Figure pct00006
결함 허용
Figure pct00007
로드 밸런싱 및 확장성을 위한 분산 서비스
Figure pct00008
병렬 프로세싱
이러한 특징들은 IoT/M2M 아키텍처에 강인한 서비스로서 데이터 스트림 애널리틱스를 추가하는 필요불가결하고 중요한 부분을 형성한다. 아래에서 우리는 데이터 스트림 애널리틱스 능력들을 갖는 몇몇 인기 있는 IoT 아키텍처들에 관해 논의한다. Microsoft Azure Stream Analytics(도 13) 및 Intel IoT 플랫폼(도 14a 및 도 14b)은 IoT 플랫폼들의 아키텍처에 대한 상세한 설명을 제공하는 반면, Oracle IoT 플랫폼(도 15)은 데이터 스트림 애널리틱스 능력들을 갖는 서비스 레이어의 아키텍처 프레임워크를 예시하고 있다. 이러한 플랫폼들은 매우 IoT 특정적이며 앞서 논의된 DSPS 개념들을 자신들의 데이터 스트림 애널리틱스를 위한 컴포넌트로서 사용한다.
도 13은 Microsoft Stream Analytics 플랫폼의 아키텍처 프레임워크를 도시하고 있다. 이벤트 생성자들(Event Producers)에 의해 생성된 데이터 스트림이, 게시-가입 모델(publish-subscribe model)에 기초하고 큰 데이터 볼륨들을 높은 레이트로 소비하는 데 사용되는, 인제스터(Ingestor)(이벤트 허브(Event Hub))에 의해 수신된다. 이것은 다양한 응용분야들로부터의 데이터 스트림들에 대한 단일 수집 지점(collection point)으로서 역할한다. 데이터 스트림이 인제스터에 의해 일단 수신되면, 데이터 스트림이 스트림 프로세싱 시스템을 사용하여 분석되고 이어서 장기 저장을 위해 송출된다.
IoT 플랫폼은 데이터 스트림 프로세싱을 위해 Microsoft Azure Streaming 서비스를 사용한다. Microsoft Azure Streaming은 실시간 애널리틱스를 위해 사용되는 Microsoft 독점적 스트림 프로세싱 클라우드 서비스이다. 이 시스템은 머신 러닝 모듈과 같은 복잡한 데이터 스트림 애널리틱스 모듈들을 사용한다. IoT 디바이스들은 디바이스 등록 능력들을 사용하여 이 시스템에 등록될 수 있다. 대안으로서, 이 플랫폼은 또한 Apache Storm을 인프라스트럭처에서의 스트림 프로세싱 시스템으로서 추가하는 유연성을 제공한다.
도 14a 및 도 14b는 인텔 IoT 플랫폼의 상세한 아키텍쳐 프레임워크를 도시하고 있다. 데이터 스트림이 게이트웨이로부터 로드 밸런서(Load Balancer)를 경유하여 스트림 프로세싱 시스템으로 전송된다. 이 시스템은 또한 데이터 스트림 애널리틱스를 위해 클라우드 서비스를 사용한다.
도 15는, 데이터 스트림 애널리틱스를, 이벤트 프로세싱 및 빅 데이터 및 애널리틱스 아래에, 서비스 레이어에서의 서비스들 중 하나로서 통합한, Oracle에 의해 제안된 IoT 서비스 레이어를 도시하고 있다. Oracle 서비스 레이어의 실시간 애널리틱스 서비스는 복잡한 이벤트 스트림 프로세싱을 수행할 수 있고 쿼리 프로세싱을 위해 쿼리 언어 CQL(Continuous Query Language)을 사용한다. 이는 Oracle에 의한 IoT에 대한 독점적 서비스 레이어이며, Oracle 라이센스 제품들을 사용함으로써 확장가능하고 분산된다.
이 섹션은 서비스 레이어(1602)에 관련된 배경 정보를 간단히 소개한다. 프로토콜 스택 관점에서, 서비스 레이어(1602)는 전형적으로 애플리케이션 프로토콜 레이어(1606) 위에 위치되며 부가 가치 서비스들(예컨대, 디바이스 관리, 데이터 관리 등)을 애플리케이션들(1604)(예시를 위해 도 16을 참조)에 또는 다른 서비스 레이어에 제공한다. 따라서, 서비스 레이어(1602)는 종종 '미들웨어' 서비스들로서 카테고리화된다.
네트워크 내에 인스턴스화되어 있는, M2M/IoT 서비스 레이어(1602)의 예시적인 배포가 도 17에 도시되어 있다. 이 예에서, 서비스 레이어 인스턴스(1602)는 서비스 레이어(1602)의 실현이다. 다수의 서비스 레이어 인스턴스들(1602)은 네트워크 애플리케이션들, 디바이스 애플리케이션들에는 물론 네트워크 노드들 자체에 부가 가치 서비스들을 제공하기 위해 다양한 네트워크 노드들(즉, 게이트웨이들 및 서버들) 상에 배포된다. 최근에, 몇 개의 산업 표준 단체들(예컨대, oneM2M -"oneM2M-TS-0001 oneM2M Functional Architecture-V-2.4.0")이 M2M/IoT 타입들의 디바이스들 및 애플리케이션들을 인터넷, 셀룰러, 엔터프라이즈, 및 홈 네트워크들과 같은 배포들에 통합시키는 것과 연관된 과제들을 해결하기 위해 M2M/IoT 서비스 레이어들을 개발해오고 있다.
M2M 서비스 레이어(1602)는 M2M 지향 서비스 능력들의 모음(collection)에 대한 액세스를 애플리케이션들 및 디바이스들에게 제공할 수 있다. 이러한 능력들의 몇몇 예들은 보안, 과금(charging), 데이터 관리, 디바이스 관리, 발견(discovery), 프로비저닝, 및 연결성 관리(connectivity management)를 포함한다. 이러한 능력들은 M2M 서비스 레이어(1602)에 의해 정의된 메시지 프리미티브들(message primitives)을 사용하는 API들(Application Programming Interfaces)을 통해 애플리케이션들에 이용가능하게 된다.
oneM2M의 목표는 현장에서 매우 다양한 디바이스들을 지원하기 위해 하드웨어 장치들 및 소프트웨어 모듈들 내에 용이하게 임베딩될 수 있는 공통 서비스 레이어의 필요성을 해결하는 기술 규격들을 개발하는 것이다. oneM2M 공통 서비스 레이어는, 도 18에 도시된 바와 같이, 공통 서비스 기능들(Common Service Functions)(CSF들)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입의 CSF들의 세트의 인스턴스화(instantiation)는, 상이한 타입들의 네트워크 노드들(예컨대, 인프라스트럭처 노드(Infrastructure Node)(IN) 및 미들 노드(Middle Node)(MN), 및 애플리케이션-특정 노드(Application-Specific Node)(ASN)) 상에서 호스팅될 수 있는, 공통 서비스 엔티티(Common Services Entity)(CSE)(1802)라고 지칭된다. 그러한 CSE들은 oneM2M-TS-0001 oneM2M Functional Architecture-V-2.4.0에서 정의된 바와 같이, 제각기, IN-CSE, MN-CSE 및 ASN-CSE라고 지칭된다. CSE들은 다른 CSE들(1802)에는 물론 애플리케이션 엔티티들(AE들)(1804)에 서비스 능력들을 제공한다. 전형적으로, AE(1804)는 엔드-투-엔드 M2M 솔루션들을 위한 애플리케이션 로직의 인스턴스화를 나타내며 AE(1804)의 예들은 차량군 트래킹 애플리케이션(fleet tracking application), 원격 혈당 모니터링 애플리케이션, 전력 계량 애플리케이션, 또는 제어 애플리케이션 등의 인스턴스일 수 있다.
처음에, oneM2M 서비스 레이어는, 상이한 자원들이 (도 19에 도시된 바와 같은) oneM2M ROA RESTful 아키텍처 내에 정의된다는 의미에서, ROA(Resource-Oriented Architecture)(oneM2M-TS-0001 oneM2M Functional Architecture-V-2.4.0) 설계 원칙들에 부합하도록 개발되었다. 자원은 아키텍처에서의 일의적으로 어드레싱가능한 요소이며, Create, Retrieve, Update, 및 Delete와 같은 RESTful 메소드들을 통해 조작될 수 있다. 이러한 자원들은 URI들(Uniform Resource Identifiers)을 사용하여 어드레싱가능하다. 자원은 자식 자원(들) 및 애트리뷰트(들)를 포함할 수 있다.
최근에, OneM2M은, RESTful 기반이 아닌 배포들을 고려하기 위해, (도 20에 도시된 바와 같은) M2M 서비스 컴포넌트 아키텍처(Service Component Architecture)를 개발하기 시작하였다. 이 아키텍처는 CSE가 서비스 컴포넌트들의 세트로서 간주되는 인프라스트럭처 도메인에 주로 적합하다. 이는 대체로 도 19에 도시된 기존의 서비스 레이어 아키텍처를 재사용하지만 서비스 레이어 내에서 이는 다양한 M2M 서비스들 및 다수의 서비스들을 서비스 컴포넌트들로 조직화한다. 기존의 기준점에 부가하여, SoA 아키텍처는 인터-서비스 기준점(Msc)을 도입한다. M2M 서비스 컴포넌트들 사이의 통신(Msc 기준점을 거쳐 지나감)은 SOA(Service-Oriented Architecture) 기반 소프트웨어 시스템들을 구축하는 데 가장 인기 있는 기술인 웹 서비스 접근법을 이용한다.
데이터 스트림 애널리틱스(또는 실시간 애널리틱스)는 스트리밍 데이터를 실시간으로 프로세싱하고 분석하는 것을 포함한다. 이는 연속적이고 스트리밍하는 데이터로부터 유용한 정보를 실시간으로 추출하고 도출하는 프로세스이다. 데이터 스트림에 대해 수행될 수 있는 몇몇 타입의 실시간 애널리틱스 동작들은 패턴/이상 탐지(pattern/anomaly detection), 통계적 집계, 예측 분석, 머신 러닝을 포함한다. 데이터 스트림 애널리틱스는 IoT/M2M 디바이스 생성 데이터(IoT/M2M device generated data)로부터 실시간으로 통찰력 있는 정보를 추출할 필요성으로 인해 IoT/M2M 시스템에서 핵심적 역할을 한다.
IoT 서비스 레이어가, 모든 중간 노드들에서의 데이터 관리 및 다른 서비스들을 책임지고 있는, M2M 디바이스들과 엔터프라이즈 인프라스트럭처 서버들 사이의 미들웨어로서 기능하기 때문에, 스트림 애널리틱스 능력들이 IoT/M2M 서비스 레이어에 통합할 수 있다. 데이터 수집 지점들에서 서비스 레이어들에 의해 데이터가 저장되기 전에(이는 데이터가 저장된 후에 통상적으로 수행되는 전통적인 데이터 애널리틱스와 상이함), 데이터 생성 소스에 가까이에서 데이터 스트림에 대해 실시간 분석이 수행될 수 있다.
기존의 IoT/M2M 플랫폼들은 데이터 스트림 애널리틱스를 위해 IoT 플랫폼들의 (에지 디바이스들 또는 게이트웨이들에 접속된 클라우드 서비스들과 같은) 상이한 레벨들에서의 클라우드 서비스들에 의존한다. 물리 서비스 레이어 노드들에 대한 모듈식 설계는 데이터 스트림 애널리틱스에 대한 문헌에 기술되어 있지 않다. DSAS(Data Stream Analytics Service)라고 불리는, 데이터 스트림 애널리틱스 능력들을 IoT/M2M 서비스 레이어에 통합하기 위한 데이터 스트림 프로세싱 및 분석을 위한 모듈식 분산 아키텍처가 기술된다. DSAS를 호스팅하는 각각의 서비스 레이어 노드는 2개의 독립적 모듈, 스트림 포워더(Stream Forwarder) 및 스트림 애널리틱스 엔진(Stream Analytics Engine)으로 분할될 수 있다. 스트림 포워더는 데이터 프리프로세싱 및 라우팅을 책임지고 있을 수 있는 경량 프로세싱 모듈들인 반면, 스트림 애널리틱스 엔진은 데이터 스트림에 대해 실제 애널리틱스를 수행하는 일을 책임지고 있을 수 있다. 2개의 기능성을 분리하는 것은 서비스 레이어 노드들이 스트림 애널리틱스 태스크들을 다수의 노드들에 걸쳐 효율적으로 분산시키는 것을 가능하게 해준다.
oneM2M과 같은, 현재의 서비스 레이어들은 데이터 스트림 애널리틱스 능력들을 제공하기 위한 표준화된 서비스가 없다. 데이터 애널리틱스 능력들은 이미 저장된 데이터에 대해서만 인에이블될 수 있다. IoT/M2M 서비스 레이어에서 분산 스트림 애널리틱스 능력들을 인에이블하기 위한 표준 서비스의 상세한 엔드 투 엔드 솔루션이 기술된다. 데이터 스트림 애널리틱스를 서비스 레이어에 통합하기 위한 표준 솔루션을 갖는 것은 다중 도메인(multi-domain) 애플리케이션들에 걸친 그리고 상이한 벤더들에 걸친 데이터 스트림 실시간 분석을 가능하게 해줄 것이다.
실시예들은 다음과 같은 것들을 포함한다:
Figure pct00009
데이터 스트림 애널리틱스 서비스(DSAS)라고 불리는, IoT/M2M 서비스 레이어에서의 데이터 스트림 애널리틱스 능력들을 가능하게 해주기 위한 표준 서비스
Figure pct00010
DSAS의 아키텍처 레이아웃 및 컴포넌트들
Figure pct00011
DSAS의 상세 동작 절차들
Figure pct00012
서비스 레이어에서의 DSAS 호스팅 노드들의 분산 레이아웃
이 요약은 이하에서 상세한 설명에 추가로 설명되는 선택된 개념들을 간략화된 형태로 소개하기 위해 제공되어 있다. 이 요약은 청구된 주제(subject matter)의 핵심 특징들 또는 필수 특징들을 식별해주도록 의도되어 있지도 않고, 청구된 주제의 범주를 제한하는 데 사용되도록 의도되어 있지도 않다. 게다가, 청구된 주제는 본 개시내용의 임의의 부분에서 살펴본 임의의 또는 모든 단점들을 해결하는 한정사항들로 제한되지 않는다.
첨부 도면과 관련하여 예로서 주어진, 이하의 설명으로부터 보다 상세한 이해가 얻어질 수 있다.
도 1은 스마트 홈에서의 데이터 스트림을 예시하는 다이어그램이다.
도 2는 GPS 프로브 디바이스로부터의 예시적인 데이터 스트림을 예시하는 다이어그램이다.
도 3은 데이터 스트림 프로세싱 시스템(DSPS)의 일반적인 논리 프레임워크를 예시하는 다이어그램이다.
도 4a 내지 도 4c는 데이터 스트림에서의 카운팅 문제를 예시하는 다이어그램들이다.
도 5는 예시적인 분산 데이터 스트림 프로세싱 시스템을 예시하는 다이어그램이다.
도 6은 Apache Storm 아키텍처 레이아웃을 예시하는 다이어그램이다.
도 7은 단어 카운트 애플리케이션에 대한 Apache Storm 토폴로지를 예시하는 다이어그램이다.
도 8은 IBM Infosphere streams 런타임 실행을 예시하는 다이어그램이다.
도 9는 단어 카운트 예에 대한 IBM Infosphere streams 데이터 흐름 그래프를 예시하는 다이어그램이다.
도 10은 Apache Spark streaming에서의 마이크로 배치 프로세싱을 예시하는 다이어그램이다.
도 11은 Apache Spark streaming 및 RDD(Resilient Distributed Dataset)를 예시하는 다이어그램이다.
도 12는 spark streaming에서의 이산 스트림 프로세싱을 예시하는 다이어그램이다.
도 13은 IoT에 대한 Azure Stream analytics 플랫폼의 아키텍처 프레임워크를 예시하는 다이어그램이다.
도 14a 및 도 14b는 Intel의 IoT 플랫폼에 대한 아키텍처 프레임워크를 예시하는 다이어그램이다.
도 15는 Oracle의 IoT 서비스 레이어에 대한 아키텍처 프레임워크를 예시하는 다이어그램이다.
도 16은 서비스 레이어를 지원하는 예시적인 프로토콜 스택을 예시하는 다이어그램이다.
도 17은 네트워크 내에서의 예시적인 M2M/IoT 서비스 레이어 배포를 예시하는 다이어그램이다.
도 18은 oneM2M 서비스 레이어에서의 공통 서비스 기능들(Common Services Functions)(CSF들)을 예시하는 다이어그램이다.
도 19는 oneM2M 서비스 레이어 ROA(Resource-Oriented Architecture)를 예시하는 다이어그램이다.
도 20은 oneM2M 서비스 컴포넌트 아키텍처(Services Component Architecture)를 예시하는 다이어그램이다.
도 21a 및 도 21b는 지능형 교차로 교통 시스템을 예시하는 다이어그램이다.
도 22는 IoT/M2M 서비스 레이어에서의 DSAS 레이아웃을 예시하는 다이어그램이다.
도 23은 DSAS의 상세들을 예시하는 다이어그램이다.
도 24는 DSAS의 전체적인 절차적 설명(procedural description)을 예시하는 플로차트이다.
도 25는 데이터 소스 등록을 예시하는 플로차트이다.
도 26a 및 도 26b는 대역외(out-of-band) 스트림 프로비저닝을 예시하는 플로차트이다.
도 27은 대역내(in-band) 스트림 프로비저닝을 예시하는 플로차트이다.
도 28은 데이터 스트림 파싱을 예시하는 다이어그램이다.
도 29는 스트림 파싱을 위한 절차를 예시하는 플로차트이다.
도 30a 및 도 30b는 쿼리 배포 절차의 상세들을 예시하는 플로차트이다.
도 31은 데이터 스트림 애널리틱스 절차의 상세들을 예시하는 다이어그램이다.
도 32a 및 도 32b는 출력 트리거링의 상세들을 예시하는 플로차트이다.
도 33a 내지 도 33c는 서비스 레이어에서의 DSAS의 분산 레이아웃을 예시하는 다이어그램들이다.
도 34는 분산 시스템에서의 중앙 코디네이터의 아키텍처를 예시하는 다이어그램이다.
도 35는 서비스 레이어에서의 DSAS를 디스에이블하는 옵션을 예시하는 다이어그램이다.
도 36은 서비스 레이어에서의 DSAS를 인에이블하는 옵션을 예시하는 다이어그램이다.
도 37은 oneM2M 서비스 레이어에서의 새로운 CSF로서의 DSAS를 예시하는 다이어그램이다.
도 38은 oneM2M 서비스 레이어에 DSAS를 통합하는 것을 예시하는 다이어그램이다.
도 39는 DSAS에 대한 oneM2M 자원을 예시하는 다이어그램이다.
도 40은 <streamDescriptor> 자원을 예시하는 다이어그램이다.
도 41은 <queryDescriptor> 자원을 예시하는 다이어그램이다.
도 42는 <streamInfo> 자원을 예시하는 다이어그램이다.
도 43은 <output> 자원을 예시하는 다이어그램이다.
도 44은 대역내 스트림 프로비저닝을 위한 oneM2M 절차를 예시하는 플로차트이다.
도 45는 대역외 스트림 프로비저닝을 위한 oneM2M 절차를 예시하는 플로차트이다.
도 46a 및 도 46b는 쿼리 배포, 데이터 스트림 애널리틱스 및 출력 트리거링을 위한 oneM2M 절차를 예시하는 플로차트이다.
도 47은 DSAS 클라이언트들이 쿼리를 트리거링하기 위한 GUI를 예시하는 다이어그램이다.
도 48a 및 도 48b는 쿼리 배포를 위한 GUI를 예시하는 다이어그램이다.
도 49a는 통신 네트워크를 포함하는 M2M/IoT/WoT 통신 시스템의 다이어그램이다.
도 49b는 M2M 애플리케이션, M2M 게이트웨이 디바이스들, 및 M2M 단말 디바이스들 그리고 통신 네트워크에 대한 서비스들을 제공하는 필드 도메인에서의 예시된 M2M 서비스 레이어의 다이어그램이다.
도 49c는 본 명세서에 기술된 네트워크 노드들, 디바이스들 또는 장치들 중 임의의 것을 구현하는 데 사용될 수 있는 예시적인 디바이스의 다이어그램이다.
도 49d는 본 명세서에 기술된 네트워크 노드들, 디바이스들 또는 장치들 중 임의의 것을 구현하는 데 사용될 수 있는 컴퓨터 시스템 또는 서버의 블록 다이어그램이다.
이 섹션에서, 우리는 서비스 레이어가 스트림 애널리틱스 능력을 왜 필요로 하는지 및 그것이 이러한 IITS 사용 사례 또는 다른 실제의 응용분야들에서 어떻게 도움이 될 수 있는지를 정당화하기 위해 IITS(Intelligent Intersection Traffic System) 사례를 보다 상세히 검토한다.
IITS는 상이한 레벨들에서 구현될 수 있다. 가장 간단한 레벨에서, 교차로에 있는 신호등들은 교통 조건들에 기초하여 양상들(phases)을 자동으로 변경하도록 스마트하게 만들어지며, 경보 시스템들은 교통 상황에 기초하여 임의의 가능한 충돌들을 자동차들 및 보행자들에게 경고하기 위해 실시간 경보들을 생성하도록 지능적으로 만들어진다. 가장 복잡한 레벨에서, 교차로는 교통 또는 정지 신호를 갖지 않으며 차량들은 모두가 자율적일 것으로 예상된다. 교차로에 있는 중앙 코디네이터 - 이를 테면 우리는 그것을 교차로 관리 게이트웨이라고 부름 - 는 교차로로부터 통신 범위 내에 있는 모든 차량들과 직접 통신하여, 차선을 변경하거나, 속도를 감소/증가시키거나 또는 교차로를 효율적으로 가로지르는 데 필요한 다른 조치들을 취하도록 차량들을 안내하여, 다른 차량들, 자전거들 또는 보행자들과의 충돌을 회피한다.
이 시스템에서, 차량들에 설치된 GPS 프로브들 및 센서들, 교차로에 있는 교통 카메라들 및 다른 도로 센서들과 같은 종단 디바이스들(end devices)은 교통 데이터의 연속적인 스트림(예를 들어, GPS 프로브들에 의한 GPS 데이터 스트림, 비디오 카메라들에 의한 비디오 스트림 등)을 교차로 관리 게이트웨이에게 전송하고, 교차로 관리 게이트웨이는 차례로 교차로에서의 효율적인 교통 관리를 위한 실시간 의사 결정을 하기 위해 디바이스들로부터 수신된 교통 데이터를 분석한다. 교차로 관리 게이트웨이는 일반적으로 또한 이 교통 데이터를, 보다 나은 장래의 예측들 및 상관 분석들을 위한 추가 분석 그리고 가능한 영구적 저장을 위해, 인프라스트럭처 서버들 및 클라우드 서버들로 포워딩한다. 도 21a 및 도 21b에 도시된 이러한 사용 사례에서, 간단함을 위해, 우리는 2가지 타입의 M2M 디바이스들로서 차량들 및 교통 카메라들에서의 GPS 프로브들만을 고려하였다.
교차로 관리 게이트웨이는 게이트웨이에서 호스팅되는 스트림 애널리틱스 서비스들로 인해 실시간 의사 결정을 수행할 수 있다. 게이트웨이에서의 스트리밍 애널리틱스 서비스는 교통 데이터를 프로세싱하고 분석하기 위해 게이트웨이를 갖추고 있다. 스트림 애널리틱스는 주로 그것이 디바이스들, 사용자들 또는 애플리케이션들로부터 수신하는 쿼리들에 기초하여 수행된다.
단지 예시를 위해, 이 시스템 상에서 행해지는 두 가지 간단한 예시적인 쿼리가 이하에 있다:
1. 쿼리 1: 교차로의 통신 범위 내의 임의의 두 대의 차량 간의 충돌까지의 시간을 계산하기 - 자동차들이 교차로를 가로지르고 충돌들을 피하기 위해, 필요한 경우, 어떻게 차선을 변경하고 속도를 변경하거나 정지해야 하는지의 실시간 의사결정을 하기 위해 이 쿼리는 GPS 데이터와 교통 카메라 비디오 분석을 사용한다.
2. 쿼리 2: 교차로의 통신 범위 내의 임의의 차량과 보행자 간의 충돌까지의 시간을 계산하기 - 충돌 위험이 있는 경우 보행자에게 실시간 경보들을 송출하고 충돌 가능성이 있는 경우 보행자들에 관해 자동차들에게 경고하기 위해 이 쿼리는 GPS 데이터 및 도로 센서들을 사용한다.
IoT/M2M 시스템의 서비스 레이어는 종단 디바이스들, 인프라스트럭처 서버들 간의 브리지로서 기능하고 운영 효율을 개선시키는 데 필요한 서비스들 및 인프라스트럭처를 제공하는, 미들웨어로서 핵심적인 역할을 한다. IoT/M2M 서비스 레이어는 데이터 관리 및 다른 서비스들을 통해, 각각의 중간 노드와 함께, 종단 디바이스들과 엔터프라이즈 인프라스트럭처 사이에서 데이터를 관리하여, 데이터의 수명 사이클 전체 동안 필요한 신뢰성 및 보안을 제공하는 일을 책임지고 있다.
교차로가 실시간으로 효율적으로 관리되도록, IITS, 그리고 이와 유사하게 다른 스마트 IoT/M2M 솔루션들을 구현하기 위해, 서비스 레이어는 스트림 애널리틱스 능력을 부여받는데, 그 이유는 데이터가 데이터의 수명 사이클 전체 동안 서비스 레이어에 의해 관리되기 때문이다. 예를 들어, 도 21a 및 도 21b에 도시된 바와 같이, 교차로 관리 허브는 네트워크 채널을 통해 데이터 스트림을 계속 수신하고, 데이터가 서비스 레이어의 저장 노드들(storage nodes)로 포워딩되기 전에 교차로에서의 교통을 효율적으로 관리하기 위해 데이터로부터 유용한 교통 정보를 추출한다. 이 사용 사례에서, 의사 결정은 데이터가 생성된 직후에(즉, 실시간으로), 그리고 데이터가 서비스 레이어의 중간 수집 지점들 저장되기 전에 수행되어야 한다. 데이터를 디스크(예컨대, 자기 디스크들, 솔리드 스테이트 드라이브들(SSD들))에 저장하는 것 그리고 나중에 분석을 위해 데이터를 검색하는 것은 다음과 같은 이유들로 실시간 애널리틱스에 적합하지 않다:
Figure pct00013
데이터를 디스크에 기입하는 것 또는 데이터를 디스크로부터 판독하는 것으로 인한 디스크 입력/출력(I/O) 동작들은 I/O 오버헤드들로 인해 부가의 상당한 지연들을 추가한다. 디스크에 저장된 데이터를 프로세싱하는 것은 인-메모리 정보(in-memory information)를 사용하여 데이터를 온 더 플라이로(on the fly) 프로세싱하는 것보다 수십 및 수백 정도의 크기만큼 더 느리다.
Figure pct00014
데이터를 디스크에 저장하는 프로세스는 다른 오버헤드들, 예컨대, 데이터를 인덱싱하는 것을 역시 가지며, 이는 실시간 분석에 부적합한 추가적인 지연들을 추가한다.
이전에 강조된 바와 같이, 실시간 애널리틱스는, IoT/M2M 시스템과 관련하여, 엔터프라이즈들 및 산업들의 대부분에 의해 많은 주목을 받았다. 따라서, 이전의 사용 사례에서 논의된, 데이터 스트림 애널리틱스 능력들을 IoT/M2M 시스템에 통합하는 것이 매우 중요하다. 이제, IoT 서비스 레이어이 엔드 투 엔드 IoT 시스템 내에서 데이터의 수명 사이클 전체 동안 다양한 서비스들을 제공하기 때문에, IoT/M2M 시스템의 서비스 레이어에 데이터 스트림 애널리틱스 능력들을 추가하는 것이 매우 유용하다.
IoT/M2M 서비스 레이어에서 다른 서비스로서 데이터 스트림 애널리틱스를 추가하는 것에 의해, 필요한 서비스들이 데이터로부터 실시간으로 유용한 통찰들을 도출하는 데 도움이 될 수 있고, 데이터가 인프라스트럭처 서버들에 있는 중간 서비스 레이어 노드들 또는 영구 저장 노드들 중 임의의 것에 저장되기 전에 데이터 스트림에 대해 실시간 애널리틱스가 수행되는 것이 보장될 수 있다. 가능한 한 데이터 소스(에지)에 가까이에서 실시간 애널리틱스를 가능하게 해주는 기법들을 제안한, 포그 컴퓨팅(Fog Computing)과 클라우드렛(Cloudlet)과 같은, 많은 연구들이 있다. 그렇지만, 이하의 이슈들은 기존의 솔루션들에 의해 완전히 해결되지는 않았으며 이 연구의 주된 초점이다.
현재의 기존 IoT 플랫폼들에서, IoT에서의 효율적인 실시간 애널리틱스를 가능하게 해주는 기법들의 대부분은 클라우드 서버들 또는 가상 머신들 상에서 구현된다. 클라우드 시스템은 에지 근방에서의 데이터 스트림 애널리틱스를 최적화하기 위해 계층적 및 연합된(federated) 방식으로 구축된다. 그렇지만, 게이트웨이들 또는 라우터들과 같은, 에지들 근방에 있는 IoT/M2M 시스템의 물리 서비스 레이어 노드들 상에 스트림 애널리틱스 능력들을 통합하기 위한 모듈식 시스템을 구축하는 것에 거의 초점을 맞추지 않는다.
실제로, IoT/M2M 서비스 레이어 시나리오 내에서, 스트리밍 애널리틱스 아키텍처가 높은 유연성 및 강건성으로 서비스 레이어에 통합될 수 있도록 각각의 개별 모듈에 대해 정의된 독립적인 기능성들을 갖는, 모듈식 스트리밍 애널리틱스 시스템을 서비스 레이어 노드들에 구축하는 것이 매우 중요하다. 도 21a 및 도 21b에 도시된 예로 돌아가서, 교차로 관리 허브가 에지에 가까이 있기 때문에, 허브에 이용가능한 자원들의 양이 제한될 수 있다. 이러한 경우들에서, 복잡한 애널리틱스가 에지로부터 보다 멀리 떨어진 보다 강력한 노드로 이동될 수 있고 경량 스트림 프로세싱이 에지 근방에 있는 노드들에 의해 수행되도록 하는 프레임워크를 갖는 것이 요망된다. 서비스 레이어 노드들에서의 스트림 애널리틱스 능력의 모듈식 설계가 사용될 수 있다.
현재의 IoT/M2M 서비스 레이어 표준화 노력은 데이터 스트림 애널리틱스를 지원하지 않는다. 앞서 논의된 바와 같이, IoT에 스트림 애널리틱스를 통합하기 위한 몇 가지 독점적 아키텍처들은 물론 오픈 소스 아키텍처들이 제안되었다. 그렇지만, 기존의 배포들은 대체로 독점적이며 특정한 산업에 특정적이다. 현재, 다중 도메인 애플리케이션들에 걸쳐 스트리밍 애널리틱스 능력들을 가능하게 해줄 수 있는 표준 스트리밍 애널리틱스 서비스가 IoT/M2M 서비스 레이어에 없다. oneM2M과 같은, 현재의 IoT/M2M 서비스 레이어 표준들은 추후 검색, 추론 및 분석을 위해 센서들 또는 다른 M2M 디바이스들로부터 검색된 데이터를 M2M 서버들에 저장하는 메커니즘들을 제공한다. 서비스는 데이터가 어딘가에 저장되기 전에 데이터로부터 유용한 정보를 실시간으로 추출할 수 있다.
도 22에서, IoT/M2M 서비스 레이어에서의 DSAS(Data Stream Analytics Service)(2202)는 스트리밍 애널리틱스 능력들을 그 레이어에 통합한다. 특히, IoT/M2M 서비스 레이어에서의 모듈식 데이터 스트림 애널리틱스 서비스가 정의되었다: DSAS(2202)는 2개의 주요 모듈로 설계되었다 - a) 데이터 프리프로세싱 및 데이터 라우팅과 같은 경량 태스크들을 수행하는, DSAS 스트림 포워더(2212) 또는 DSAS-SF(2212)라고 불리는, 경량 데이터 스트림 프로세싱 모듈, 및 b) DSAS 스트림 애널리틱스 엔진 또는 DSAS-SAE(2210)라고 불리는, 보다 많은 자원을 소비하는 데이터 스트림 프로세싱 모듈인, 사용자, 애플리케이션 또는 디바이스 요구사항들에 기초한 스트림 애널리틱스 동작. 2개의 기능성을 분리하는 것에 의해, 애널리틱스 동작이 IoT 서비스 레이어 및 클라우드 내의 분산 스트림 애널리틱스 시스템에 걸쳐 쉽게 분산될 수 있도록 우리는 데이터 스트림 애널리틱스 아키텍처를 보다 유연하고 모듈식으로 만든다.
일반적으로, DSAS(2202)는 다음과 같은 4개의 주요 컴포넌트, DSAS 스트림 포워더(DSAS-SF)(2212), DSAS 스트림 애널리틱스 엔진(DSAS-SAE)(2210), DSAS 관리자(2206), DSAS API(2208)를 주로 갖는다.
DSAS 스트림 포워더(DSAS-SF)(2212)는 다음과 같은 일을 하는 경량 스트림 프로세싱 모듈이다:
Figure pct00015
스트림 애널리틱스를 위한 데이터 스트림에 대한 엔트리 포인트(entry point)로서 기능한다. 고유 데이터 스트림을 그의 속성들 및 애트리뷰트들을 사용하여 식별하고, 데이터에 대한 제어를 관리하기 위해 액세스 제어 정책(ACP)을 사용한다.
Figure pct00016
스트림을 프리프로세싱하고 감소된 스트림만(분석을 위해 요구된 데이터 스트림 애트리뷰트들만)을 메인 스트림 애널리틱스 엔진(DSAS-SAE(2210))으로 라우팅하며, 따라서 스트림 애널리틱스 엔진으로 포워딩되는 트래픽의 크기를 제어한다.
Figure pct00017
스토리지의 요구사항에 따라 데이터를 프리프로세싱한 후에, 들어오는 스트림을 데이터 저장 노드로 포워딩하기 위한 라우터로서 기능한다(스트림 애널리틱스 엔진과 상이할 수 있음).
DSAS 스트림 애널리틱스 엔진(DSAS-SAE)(2210)은 통계 집계, 패턴/이벤트 탐지 및 예측 분석과 같은 메인 스트림 애널리틱스 동작을 수행하는 모듈이다. 이 모듈은 DSAS-SF(2212) 또는 다른 DSAS-SAE(2210)로부터 분석을 위한 데이터 스트림을 수신한다.
DSAS 관리자(2206)는 다음과 같은 일을 하는 DSAS(2202)의 메인 관리 모듈이다:
Figure pct00018
메타데이터, 테이블들, 로그들 등을 저장하는 데 요구된 물리 자원들과 같은 DSAS(2202)에 할당된 자원들을 관리한다.
Figure pct00019
DSAS 컴포넌트들(2202) 내의 보안 관리자(2302), 쿼리 관리자(2316) 등과 같은, 개별 서비스들 및 모듈들을 호출하고 이러한 서비스들을, 에러 없이 실행되도록 하기 위해, 모니터링하는 일을 책임지고 있다.
Figure pct00020
결함 허용을 책임지고 있다. 장애들의 경우에, 그것은 시스템에서의 장애 있는(failed) 프로세스들 및 잡들을 복구하려고 시도하여, 시스템이 계속하여 원활하게 동작하도록 보장한다. 접근법들 중 하나는 주기적으로 시스템의 상태를 체크포인트(checkpoint)하는 것이다.
Figure pct00021
(이하에서 DSAS API(2208) 하에서 상세히 논의될) DSAS(2202) 내의 관리 서비스들을 구성하고 모니터링하기 위해 DSAS 호스팅 노드에 접속하는 외부 클라이언트에게 ACP를 통한 보안 액세스를 제공하는 일을 책임지고 있다.
Figure pct00022
결함 복구, 로드 밸런싱 및 다른 통신을 위해 분산 시스템에서의 다른 DSAS 호스팅 노드들과 통신하는 일을 책임지고 있다. 분산 시스템에서, DSAS 호스팅 노드들은 그 각자의 DSAS 관리자(2206)를 통해 서로 통신한다.
DSAS API(2208)는 DSAS(2202)에 대한 API들(Application Programming Interfaces)의 구현을 포함한다. DSAS API(2208)는 다음과 같은 목적들을 위해 사용될 수 있다:
Figure pct00023
IoT/M2M 디바이스 데이터로부터 값들을 도출하는 데 관심이 있는 클라이언트들, 예컨대, 사용자들, 애플리케이션들 또는 디바이스들을 서비스 레이어 노드 상에서 호스팅되는 DSAS(2202)에 접속시킴으로써, 클라이언트들이 쿼리들을 DSAS(2202)에 빌드/배포하고 DSAS(2202)에 배포된 쿼리에 의해 출력되는 분석 결과에 액세스할 수 있도록 하는 것.
Figure pct00024
DSAS(2202) 자체를 관리하고 제어하는 것 - 이 API(2208)는 다음과 같은 것들을 하도록, 예를 들어, 관리 서비스들을 구성하는 일을 책임지고 있다:
Figure pct00025
결함 허용 정책을 관리하는 것
Figure pct00026
보안 관리자(2302)에, ACP와 같은, 액세스 제어 메커니즘들을 동적으로 구성하는 것
Figure pct00027
자원들에 액세스하기 위해 정책을 업데이트하는 것(예컨대, 다수의 엔티티들에 의한 테이블에서의 동시적인 판독들/기입들에 대한 잠금 메커니즘)
Figure pct00028
저장 노드들의 저장 정책 또는 디바이스 가이드라인들에 의해 제공되는 정보에 기초하여 데이터 스트림이 프리프로세싱되도록 프리프로세서(2306)를 구성하는 것
Figure pct00029
디바이스 가이드라인들에 기초하여 (대역외 스트림 식별의 경우에) 스트림 식별 정책을 업데이트하는 것.
도 22는 IoT/M2M 서비스 레이어에서의 DSAS(2202)의 일반적인 레이아웃을 도시하고 있다. 우리는 IoT/M2M 서비스 레이어(SL)에 접속된 노드들을 4개의 상이한 타입으로 카테고리화한다:
1) DSAS 호스팅 서비스 레이어(SL) 노드(2204): DSAS(2202)는 이러한 SL 노드들에서 호스팅된다. 각각의 DSAS 호스팅 SL 노드는 그 자신의 독립적인 DSAS(2202)를 갖는다. 그렇지만, 분산 데이터 스트림 애널리틱스 능력들을 IoT/M2M 서비스 레이어에 제공하기 위해, 호스팅된 DSAS(2202)를 갖는 다수의 서비스 레이어 노드들이 메시징 프로토콜, 예컨대, MQTT(message queueing telemetry)를 통해 서로 접속될 수 있다.
2) 데이터 소스(2218): 이러한 노드들은 IoT/M2M 데이터의 생성기들이다. 데이터는, 이러한 노드들로부터 시작하여, 통신 채널들을 거쳐 스트림으로서 전송된다. 이전의 IITS 사용 사례에서의 데이터 소스들의 예들은 로컬 교통 비디오를 생성하는 교통 카메라들 및 GPS 데이터를 생성하는 GPS 프로브 차량들이다. 논리적으로, 데이터 소스 및 DSAS 호스팅 SL 노드는 별개의 엔티티들이지만, 그것들이 동일한 디바이스 또는 물리 노드에서 호스팅될 수 있다.
3) DSAS 클라이언트 노드(2216): 실시간으로 스트리밍 데이터로부터 유용한 정보 또는 통찰들을 도출하는 데 관심이 있는, 사용자, 애플리케이션 또는 IoT/M2M 디바이스와 같은, 엔티티를 호스팅한다. 클라이언트(2216)는 SL 노드 또는 비-SL 노드 중 어느 하나일 수 있다.
4) 데이터 저장 노드(2214): 유용한 정보가 데이터 스트림으로부터 일단 추출되면, 추후 분석을 위해 요구되는 경우, 데이터 스트림이 저장을 위해 포워딩되는 임의적 노드. 저장 노드(2214)는 서비스 레이어에서의 일시적 데이터 수집 노드, 예컨대, oneM2M <contentInstance> 자원 노드, 또는 영구 저장을 위한 인프라스트럭처 서버/데이터 웨어하우스일 수 있다.
도 22에 예시된 기능성이, 이하에서 기술되는 도 49c 또는 도 49d에 예시된 것들 중 하나와 같은, M2M 네트워크의 장치(예컨대, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다는 것이 이해된다.
도 23은 DSAS(2202) 내의 컴포넌트들 및 모듈들을 도시하고 있다. 앞서 논의된 바와 같이, DSAS(2202)는 4개의 주요 컴포넌트 - DSAS-SF(2212), DSAS-SAE(2210) 및 DSAS API(2208) 및, DSAS 관리자(2206)라고 불리는, 이 컴포넌트들을 지원하기 위한 메인 관리 서비스 - 를 갖는다. 이러한 컴포넌트들은 또한 테이블들, 트레이스 파일들(trace files) 등의 형태로 저장되는 공유 자원들을 사용한다. 이하에서, 각각의 그 컴포넌트들에 대한 상세한 설명이 하기의 서브 섹션들 각각에서 제시될 것이다.
DSAS 스트림 포워더(DSAS-SF)(2212): 앞서 논의된 바와 같이, DSAS-SF(2212)는 DSAS(2202)의 경량 스트림 프로세싱 컴포넌트이다. 프리프로세싱은 저장 및 분석 이전에 데이터를 클리닝(cleaning)하는 것, 저장 노드들에게 송신되기 전에 불필요한 데이터를 폐기하는 것, 및 DSAS-SAE(2210)에게 포워딩되기 전에, DSAS-SAE(2210)의 요구사항에 따라, 데이터 스트림의 차원을 감소시키는 것을 위해 행해질 수 있다. 그것은 또한 간단한 라우터로서 기능할 수 있다. 하기의 모듈들은 DSAS-SF(2212)에서 실행된다:
Figure pct00030
보안 관리자(2302)는 서비스 레이어 또는 벤더들에 의해 미리 정의되거나 관리 인터페이스를 통해 동적으로 구성될 수 있는 액세스 제어 정책(ACP)과 같은 메커니즘들을 사용하여 데이터 스트림의 보안 액세스를 책임지고 있다. 보안 관리자(2302)는 액세스 제어 메커니즘들(예컨대, ACP)을 통한 상호 인증(mutual authentication)을 위해 주로 사용된다. 세 가지 주요 인증은: 1) 특정한 디바이스로부터 수신된 데이터 스트림이 DSAS(2202)에 액세스할 권한을 부여받도록 보장하는 것, 2) 디바이스로부터의 특정한 데이터 스트림이 DSAS(2202)에 액세스할 권한을 부여받도록 보장하는 것 및 3) DSAS(2202)가 특정의 디바이스의 들어오는 데이터 스트림에 액세스할 권한을 부여받도록 보장하는 것이다
Figure pct00031
스트림 식별 관리자/파서(SIM/P)(2304)는 각각의 고유 스트림을 식별하고, 스트림이 고유 스트림 식별자를 이미 갖지 않는 경우 고유 스트림 식별자를 스트림에 배정하며, DSAS(2202)에 의해 수신된(환언하면, 관찰된) 모든 고유 스트림의 정보를 저장하는, 스트림 ID 스토어(나중에 표 2에 나타냄)라고 불리는 테이블을 유지한다. 그것은 또한 스트림의 애트리뷰트들에 기초하여 스트림을 파싱한다.
Figure pct00032
프리프로세서(2306)는 스트림에 의해 생성된 데이터를 프리프로세싱한다. IoT 데이터는 일반적으로 리던던시 및 잡음을 제거하기 위해 프리프로세싱을 필요로 하는데, 그 이유는 IoT 디바이스로부터의 데이터가 일반적으로 몇 개의 누락된 지점들 및 리던던시들로 매우 더티(dirty)하고 잡음이 있기(noisy) 때문이다. 프리프로세싱은 또한 공지된 샘플링 또는 집계 기법들을 사용하여 데이터의 손실 압축을 위해 사용된다. 데이터의 프리프로세싱은 다음과 같은 주요 목적들을 달성한다: 1) 데이터로부터 리던던시 및 잡음을 제거함으로써, 일반적으로 더티하고 잡음으로 가득찬(full of noise), 디바이스 데이터를 클리닝하는 것, 2) 집계, 샘플링 또는 다른 기법들에 의해 데이터를 압축하는 것, 및 3) 상기 두 가지 목적은 차례로 전송 채널을 통한 데이터의 통신 비용과 데이터의 저장 비용을 감소시킨다.
Figure pct00033
저장 필터(2308)는 저장 노드들 또는 디바이스 가이드라인들에 의해 미리 정의되거나 관리 인터페이스를 통해 클라이언트에 의해 동적으로 구성되는 정책들에 기초하여, 데이터 스트림으로부터 불필요한 애트리뷰트들을 제거함으로써, 저장을 위해 프리프로세서(2306)에 의해 포워딩되는 데이터 스트림의 크기를 감소시키며, 따라서 또한 발생되는(incurred) 전송 및 저장 비용을 감소시킨다. 저장 정책은, 저장을 위해 최상으로 최적화되게, 데이터를 압축하는 방법들을 정의할 수 있다.
Figure pct00034
애널리틱스 필터(2310)는 시스템에 배포된 쿼리들에 기초하여, 애널리틱스 동작들 중 임의의 것에 대해 필요하지 않은 애트리뷰트들을 프리프로세싱된 데이터 스트림으로부터 필터링 아웃(filter out)한다. 결과적인 스트림은 필터링된 스트림이라고 불린다. 이 필터링은, 효율성 및 DSAS-SAE(2210)에 대한 로드를 감소시키는 것을 위해 DSAS-SAE(2210)에 의해 핸들링되는 데이터 스트림의 크기를 최소화하기 위해, 실제 애널리틱스 동작을 위해 애널리틱스 필터(2310)에 의해 DSAS-SF(2212)로부터 DSAS-SAE(2210) 내의 SAE 소스(2314)로 송신되는 데이터 스트림의 차원을 감소시키기 위해 행해진다. 분산 셋업(distributed setup)의 경우에, 애널리틱스 동작이 상이한 노드 상에서 호스팅되는 DSAS(2202)의 SAE 모듈 상에서 수행되는 경우 이것은 또한 통신 비용을 감소시킨다.
DSAS 스트림 애널리틱스 엔진(DSAS-SAE)(2210)은 다음과 같은 것을 포함할 수 있다:
Figure pct00035
쿼리 연산자들(Query Operators)(2312) - 쿼리는 데이터 스트림으로부터 특정 정보를 검색하고/하거나 특정한 조건들 또는 이벤트들의 발생에 기초하여 특정한 액션들을 수행하는 메커니즘이다. 이러한 쿼리들은 시스템에서의 특정 데이터 스트림 애널리틱스 동작들에 관련이 있다. 계산, 통계, 집계 또는 보다 복잡한 로직으로 이루어진 알고리즘들은 시스템에 배포된 쿼리를 프로세싱하고 대응하는 데이터 스트림 분석을 수행하도록 구현된다. 이러한 알고리즘들의 구현들은 쿼리 연산자들(2312)이라고 지칭된다. 이러한 구현들은, 쿼리 연산자들(2312)을 실행하기 위해 DSAS(2202) 내에서 사용되는 스트림 애널리틱스 엔진에 따라, C/C ++ 또는 Java와 같은 네이티브 프로그래밍 언어들, 또는 플랫폼 특정 언어들로 행해질 수 있다. 각각의 쿼리 연산자는 DSAS(2202)에서 하나 이상의 쿼리를 프로세싱하는 데 사용될 수 있다. 쿼리 연산자의 인스턴스는 대응하는 쿼리를 프로세싱하기 위해 쿼리 관리자(2316)에 의해 인보크(invoke)된다.
Figure pct00036
SAE 소스(2314)는 DSAS-SF(2212) 내의 '애널리틱스 필터' 모듈(2310)로부터 필터링된 데이터 스트림을 수신하는 DSAS-SAE(2210) 내의 첫 번째 모듈이다. SAE 소스(2314)는 원하는 애트리뷰트들을 갖는 요구된 스트림 또는 스트림들의 세트를 각각의 쿼리 연산자 인스턴스에 피드하기 위해 쿼리 ID 스토어(2318)를 참조한다.
Figure pct00037
쿼리 관리자(2316)는 DSAS(2202)에 배포된 각각의 쿼리의 설명 및 메타데이터를 포함하는 쿼리 ID 스토어(2318)를 관리한다. 쿼리 관리자(2316)는 또한 대응하는 쿼리를 프로세싱하고 데이터 스트림 애널리틱스 동작들을 수행하기 위해 쿼리 연산자를 인보크하고 실행하는 일을 책임지고 있다. 쿼리를 프로세싱하기 위해 쿼리 관리자(2316)에 의해 실행되는 쿼리 연산자의 런타임 인스턴스는 잡(Job)이라고 불리며, 잡 ID, 잡이 프로세싱하는 대응하는 쿼리 ID, 잡 상태, 대응하는 로그/트레이스 정보와 같은 모든 잡들에 관련된 정보는 잡 테이블(2320)(나중에 표 9에 나타내어져 있음)에 저장된다. 쿼리 관리자(2316)는 또한 잡 테이블(2320)의 유지 및 모든 잡들의 모니터링을 책임지고 있다.
DSAS 관리자(2206): 앞서 논의된 바와 같이, DSAS 관리자(2206)의 주요 기능들은 DSAS 호스팅 노드 내에서의 자원 관리 및 할당, 프로세스 장애들의 경우에 결함 허용을 관리하는 것, DSAS(2202) 내에서의 관리 서비스들을 모니터링하는 것 및 분산 시스템의 경우에, 다른 DSAS 호스팅 노드들과 그 각자의 DSAS 관리자들(2206)을 통해 통신하는 것을 포함한다.
DSAS 애플리케이션 프로그래밍 인터페이스(API)(2208): DSAS API(2208)는, DSAS 클라이언트(2216) 컴포넌트들이 동일한 또는 상이한 노드들 상에서 호스팅되는 DSAS 컴포넌트들과 어떻게 상호작용할 것인지를 결정하는 루틴들 및 프로토콜들의 세트로 이루어진, 클라이언트 종단(client end) 및 DSAS 호스팅 노드 종단(DSAS hosting node end) 둘 다 상에 구축된 인터페이스이다. DSAS API(2208)는 DSAS(2202)를 사용하여 데이터로부터 유용한 통찰들을 도출하는 데 관심이 있는 클라이언트들(예컨대, IoT 디바이스들, 애플리케이션들, 사용자들)과 DSAS 호스팅 SL 노드 사이의 접속을 확립하는 데 사용된다. 이 접속은 DSAS 호스팅 노드로의 클라이언트(2216) 액세스를 검증(validate)하기 위해 (서비스 레이어에 미리 정의되거나 동적으로 구성될 수 있는) ACP 기능성에 의해 적격화된다(qualified).
도 23의 작동 상세들은 아래의 상세한 절차들에 대한 논의 동안 부분적으로 그리고 상세하게 제시된다.
데이터 스트림 애널리틱스 서비스를 용이하게 하기 위해, 일부 메타데이터는, 스트림 ID 스토어(DSAS(2202)에 의해 분석된 고유 스트림들의 리스트를 유지함), 쿼리 스토어(3218)(DSAS(2202)에 의해 프로세싱되는 쿼리들의 리스트를 유지함) 및 잡 테이블(2320)(쿼리들을 프로세싱하기 위해 DSAS(2202)에 의해 핸들링되는 잡들의 리스트를 유지함)과 같은, DSAS 호스팅 SL 노드에 테이블들 또는 리포지토리들의 형태로 저장된다. 이러한 테이블들에 의해 사용되는 자원들은 DSAS 관리자(2206)에 의해 관리되고 DSAS(2202)의 모든 컴포넌트들에 걸쳐 공유된다.
도 23에 예시된 기능성이, 이하에서 기술되는 도 49c 또는 도 49d에 예시된 것들 중 하나와 같은, M2M 네트워크의 장치(예컨대, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다는 것이 이해된다.
도 24는 DSAS(2202)에 대한 전반적이고 일반적인 절차적 설명을 도시하고 있다. 일반적인 단계들은 다음과 같다:
A. 스트림 입수(Stream Ingestion) - 이것은 데이터 스트림을 처리하는 DSAS에서의 첫 번째 절차적 단계이다. 데이터 스트림은 보안 관리자(2302)를 통해 ACP를 거쳐 DSAS(2202)에 입수(ingest)되고, 식별 목적을 위해 고유 ID를 배정받으며, 추가 프로세싱을 위해 포워딩되기 전에 파싱된다. 이것은 나중에 상세히 논의될 것이다.
B. 쿼리 배포 - 이것은 쿼리를 DSAS(2202)에 배포하는 데 필요하고, 이 쿼리에 기초하여 데이터 스트림에 대해 데이터 스트림 애널리틱스가 수행된다. 절차 A 및 절차 B는 임의의 순서로 발생할 수 있다. 쿼리는 스트림 입수 이에 DSAS(2202)에 배포될 수 있거나, 심지어 DSAS(2202)가 관련 데이터 스트림들을 수신하기 시작하기 전에 쿼리가 DSAS(2202)에 배포되었을 수 있다.
C. 데이터 스트림 애널리틱스 - 실제 데이터 스트림 애널리틱스는 시스템에 배포된 쿼리에 기초하여 수행된다.
D. 출력 트리거링 - 비록 데이터 스트림이 계속 프로세싱되고 분석되지만, 쿼리에 대한 대답은 계속 출력되지 않을 수 있다. 출력은 클라이언트(2216)에 의해 명시적으로 요청될 수 있거나 트리거에 대한 응답으로서 생성될 수 있다.
E. 데이터 저장 - 중요한 정보가 데이터 스트림으로부터 추출된 후에, 데이터가 저장을 위해 포워딩될 수 있다.
기본적인 시나리오는 단지 하나의 DSAS(2202)를 제자리에 가지고 있다. 이하에서 기술되는 바와 같이, 분산 시나리오에서, 다수의 DSAS가 시스템에 배포될 수 있다.
도 24에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 24에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 24에 예시된 단계들을 수행한다. 도 24에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
절차 A: 스트림 입수
일반적으로, 스트림 입수는 다음과 같은 3개의 주요 단계를 가질 것이다: 다음과 같이 상세히 기술된, 1) 데이터 소스 등록, 2) 데이터 스트림 식별 및 3) 데이터 스트림 파싱.
데이터 소스 등록
이것은 IoT/M2M 시스템에서의 데이터 소스가 DSAS(2202)를 호스팅하는 서비스 레이어 노드에 등록하기 위한 초기 셋업 프로세스이다. 데이터 소스 등록의 절차적 상세는 도 25에 도시되어 있다.
도 25의 단계 1에서, 데이터 소스는 DSAS 호스팅 서비스 레이어 노드에 접속(또는 등록)하기 위해 요청 메시지를 전송한다. 데이터 소스는 서비스 레이어 노드에서의 DSAS(2202)를 인식할 수 있거나 그렇지 않을 수 있다. 데이터 소스는 데이터를 다음 목적지로 포워딩하기 위해 서비스 레이어 노드에 등록하는 데 단지 관심이 있을 수 있다.
도 25의 단계 2에서, DSAS 호스팅 서비스 레이어 노드에 대한 데이터 스트림의 등록은 표준 액세스 제어 메커니즘을 사용하여 서비스 레이어에서의 표준 디바이스 등록 프로세스에 기초하여 수행된다. 그렇지만, 데이터 소스가, 표준 디바이스 등록과 함께, 노드 내의 DSAS(2202)의 존재를 인식하거나 인식하지 못한다는 사실에도 불구하고, DSAS-SF(2212) 컴포넌트에서의 보안 관리자(2302)는 또한 데이터 소스가 DSAS(2202)를 이용하는 데 필요한 권한들(privileges)을 갖는다는 것을 보장하기 위해, ACP와 같은, 액세스 제어 메커니즘을 사용하여 데이터 소스의 권한들을 체크한다. 이러한 권한들은 네트워크에서의 데이터 소스의 배포 동안 또는 나중에 필요에 따라 (사용자들 또는 애플리케이션들과 같은) 클라이언트(2216)에 의해 지정된다. 클라이언트(2216)는 DSAS(2202)에 대해 정의된 액세스 제어 메커니즘을 사용하여 데이터 소스에 대한 권한들을 셋업하기 위해 DSAS API 모듈(2308)을 사용한다. 이 체크는 데이터 소스(또는 디바이스)의 다음과 같은 정보 - 디바이스 호스트 어드레스, 자동차 또는 스마트폰과 같은, 디바이스 타입(이용가능한 경우, 왜냐하면 디바이스의 타입이 항상 정의될 수 있는 것은 아니기 때문임) 및 디바이스 ID(이용가능한 경우, 왜냐하면 모든 디바이스들이 ID를 배정받을 수 있는 것은 아니기 때문임) - 에 대해 수행된다.
도 25의 단계 3에서, DSAS 호스팅 SL 노드는 SL 노드에서의 데이터 소스의 등록의 완료를 확인해주는 응답을 데이터 소스에게 다시 송신한다.
도 25에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 25에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 25에 예시된 단계들을 수행한다. 도 25에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
데이터 스트림 식별
이것은 DSAS(2202)에 의해 수신되는 각각의 고유 스트림을 식별하고, 이미 배정되지 않은 경우, 고유 식별자라고 불리는, 고유 ID를 고유 스트림들 각각에 배정하는 프로세스이다. 데이터 스트림 식별은 스트림 식별 관리자/파서(SIM/P)(2304)에 의해 행해진다.
특히, 그것은 DSAS(2202)에서 두 가지 방식 중 하나로 행해질 수 있다: 이하에서 기술될, 대역외 스트림 프로비저닝 및 대역내 스트림 프로비저닝.
대역외 스트림 프로비저닝
각각의 스트림이 IoT 디바이스 가이드라인들 및 사전 프로비저닝 문서들에 기초하여 클라이언트(2216)에 의해 제공되는 정보를 사용하여, DSAS-SF(2212)에서 스트림 식별 관리자에 의해 일의적으로 식별될 수 있다. DSAS(2202)는 식별을 위한 스트림 정보를 획득하기 위해 데이터 소스들, 즉 IoT/M2M 디바이스들에 의존하지 않는다. DSAS-SF(2212)는 데이터 소스로부터 어떠한 정보도 수신하지 않는다. 이 경우에, 데이터 소스들은 서비스 레이어 내의 데이터 스트림 애널리틱스 시스템의 존재에 관해 전혀 인식하지 못할 수 있다. 대역외 스트림 프로비저닝에 관한 추가 정보는 도 26a 및 도 26b에 도시된 절차적 설명에서 발견될 수 있다.
도 26a 및 도 26b의 단계 1에서, 클라이언트(2216)(예컨대, 사용자 또는 애플리케이션)는 DSAS(2202)와의 접속을 확립하기 위해 포털, 예를 들어, GUI 또는 웹 브라우저를 통해 요청을 송신한다. 이러한 요청은 인증 및 권한부여(authorization)를 위해 사용될 클라이언트 어드레스를 포함한다.
도 26a 및 도 26b의 단계 2에서, 접속을 위한 클라이언트 요청이, 클라이언트 측 포털들이 DSAS(2202)와 상호작용할 수 있게 해주는 API(2208)를 포함하는, DSAS(2202)의 DSAS API 컴포넌트(2308)에 의해 수신된다. 이 요청은 DSAS 관리자(2206) 컴포넌트로 포워딩된다.
도 26a 및 도 26b의 단계 3에서, DSAS 관리자(2206) 내의 보안 관리자(2302)는 DSAS(2202) 내에서의 클라이언트(2216)의 권한들을 체크하기 위해 미리 정의된 액세스 제어 메커니즘을 사용한다. 이는 클라이언트(2216)가 DSAS(2202)에 액세스할 권한들을 갖는지를 체크한다. 이는 또한 클라이언트(2216)가 액세스할 권한을 부여받은 자원들 및 서비스들을 찾아낸다. 자원들은 클라이언트(2216)가 액세스할 수 있는 테이블들로 이루어져 있다 - 스트림 ID 스토어(2321)(나중에 기술됨) 및 쿼리 스토어(2318)에 대한 판독 및 기입 액세스, 그리고 로그 테이블에 대한 판독 전용 액세스. 서비스들은, 액세스 제어 메커니즘 및 프리프로세서 구성과 같은, 클라이언트(2216)가 구성할 수 있는 관리 서비스들로 이루어져 있다.
도 26a 및 도 26b의 단계 4에서, DSAS 관리자(2206) 내의 보안 관리자(2302)는 클라이언트의 접속 요청에 대한 응답을 DSAS API(2208)에게 다시 송신한다. 클라이언트(2216)가 보안 관리자(2302)에 의해 인증되고 DSAS에 액세스할 권한들을 갖는 경우, 보안 관리자(2302)는 또한 클라이언트(2216)가 액세스할 권한을 부여받은 자원들 및 서비스들을 송신한다.
도 26a 및 도 26b의 단계 5에서, DSAS API(2208)는 응답 메시지를 클라이언트 포털, 예컨대, 웹 브라우저 또는 GUI에게 송신한다. 클라이언트(2216)가, 응답 메시지에 지정된 바와 같이, 인증되는 경우, 응답 메시지는 또한 클라이언트(2216)가 액세스할 권한을 부여받은 자원들 및 서비스들을 포함한다.
도 26a 및 도 26b의 단계 6에서, 클라이언트(2216)가, 수신된 응답 메시지에 의해 명시된 바와 같이, 액세스 제어 메커니즘을 사용하여 보안 관리자(2302)에 의해 인증된 경우, 클라이언트(2216) 측 포털, 예컨대, 웹 브라우저 또는 GUI를 통해 클라이언트(2216)와 DSAS(2202) 사이에 접속이 확립된다. 클라이언트(2216)는 자신이 포털을 통해 액세스할 수 있는 자원들 및 서비스들의 뷰를 얻는다. 클라이언트(2216)가 스트림 ID 스토어(2321)에 액세스할 권한을 부여받은 경우, 클라이언트(2216)는 자신이 DSAS(2202) 내에 프로비저닝하는 데 관심이 있는 데이터 스트림의 정보를 포털을 통해 입력한다. 표 1은 스트림 ID 스토어(2321)에 대한 설명을 나타내고 있다. 예를 들어, 입력된 정보는 스트림 ID(이용가능한 경우), 데이터 스트림을 생성하는 디바이스의 디바이스 정보(디바이스 어드레스, ID 및 타입, 이용가능한 경우), 각각의 애트리뷰트에 대한 메트릭들을 갖는 스트림 애트리뷰트들, 및 원시 데이터 스트림 포맷이다. 예를 들어, ID 'VH1'을 갖고, 'VH'라고 표기된, 차량 타입을 갖는 디바이스로부터 생성된, ID 'A1'의 원시 GPS 데이터 스트림을 생각해본다. 클라이언트(2216)에 의해 DSAS(2202)에게 제출된 가능한 정보는 다음과 같을 수 있다(통상적으로, 이 경우에, 클라이언트(2216)가 관련 정보를 획득하기 위해 디바이스 가이드라인들 또는 다른 사전 프로비저닝 문서를 사용할 수 있다고 가정된다).
Figure pct00038
스트림 ID: A1
Figure pct00039
디바이스 어드레스: 디바이스의 IP 어드레스 및 데이터를 전송하는 포트의 포트 번호
Figure pct00040
디바이스 ID: VH1
Figure pct00041
디바이스 타입: VH
Figure pct00042
데이터 스트림의 각각의 메시지에 포함된 애트리뷰트들의 리스트: <위도, 경도, 고도(미터), 타임스탬프(hh:mm:ss:ff), 속도(mph)>
Figure pct00043
메시지 포맷: 콤마 분리 값(CSV)
[표 1]
Figure pct00044
도 26a 및 도 26b의 단계 7에서, 포털을 통해 클라이언트(2216)에 의해 제출된 데이터 스트림 정보가 DSAS API(2208)에 의해 수신된다.
도 26a 및 도 26b의 단계 8에서, DSAS API(2208)는 클라이언트(2216)에 의해 제출된 데이터 스트림 정보를 DSAS 관리자(2206)에게 송신한다.
도 26a 및 도 26b의 단계 9에서, DSAS 관리자(2206)는 스트림 ID 스토어를, 자신이 DSAS API(2208)를 통해 수신한, 클라이언트(2216)에 의해 제공된 모든 정보로 업데이트한다. 표 2는 (IITS 사용 사례, 즉 GPS 데이터 스트림을 여전히 사용하여) 2개의 데이터 스트림에 대해 클라이언트(2216)에 의해 스트림 ID 스토어(2321)에 만들어지는 예시적인 엔트리들을 나타낸다. 이 스트림들은 단지 프로비저닝되고 있으며 DSAS(2202)에 의해 아직 관찰 또는 수신되지 않았고, 따라서 마지막 칼럼은 '아니오'로 마킹된다.
Figure pct00045
도 26a 및 도 26b의 단계 10에서, DSAS 관리자(2206)는 클라이언트(2216)에 의해 제공된 정보를 이용해 자신이 스트림 ID 스토어에 만든 엔트리에 관한 확인을 DSAS API(2208)에게 송신한다.
도 26a 및 도 26b의 단계 11에서, DSAS API(2208)는 대응하는 데이터 스트림의 식별을 용이하게 하기 위해, 데이터 스트림 프로비저닝의 완료, 즉 새로운 고유 데이터 스트림의 정보가 DSAS(2202)에 제공되었다는 것을 확인해주는 확인응답을 클라이언트(2216)에게 송신한다.
도 26a 및 도 26b에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 26a 및 도 26b에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 26a 및 도 26b에 예시된 단계들을 수행한다. 도 26a 및 도 26b에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
대역내 스트림 프로비저닝
대역내 스트림 프로비저닝의 경우에, DSAS-SF(2212)는 각각의 스트림을 일의적으로 식별하기 위해 데이터 소스들에 의해 직접 송신된 정보/메타데이터를 사용한다. 이 정보는, 디바이스들이 실제 데이터를 DSAS(2202)에게 송출하기 시작하기 전이라도, 데이터 소스들과 DSAS-SF(2212) 사이에 접속이 일단 확립되면 송출된다. 이 셋업에서, 데이터 소스가 DSAS(2202)와의 접속을 확립할 수 있도록 DSAS(2202)가 서비스 레이어 내에 배포될 때 자신을 발견가능하게 만든다고 가정된다. 따라서, 이 경우에, 데이터 소스들은 일반적으로 시스템 내의 데이터 스트림 애널리틱스 툴의 존재를 인식하고 그 각자의 스트림들에 관한 정보를 그것들에게 명시적으로 송신한다. 데이터 스트림 정보가 스트림 식별 관리자에 의해 수신되고, 스트림 식별 관리자는 각각의 고유 스트림에 대한 수신된 정보에 대응하는 엔트리를 스트림 ID 스토어에 만든다. 이 기법에 관한 추가 정보는 도 27에서 발견될 수 있다.
도 27의 단계 0에서, DSAS(2202)가 서비스 레이어에 의해 특정된(service layer specified) 서비스 발견 절차를 통해 그 자신을 발견가능하게 만든 것으로 간주된다. 데이터 소스는 도 27에 기술된 절차를 사용하여 DSAS(2202)에 등록되었다. 데이터 소스는 등록 시간 동안 DSAS(2202)의 존재를 인식할 수 있거나 그렇지 않을 수 있으며, 데이터 소스는 데이터 포워딩 및 저장을 위해 서비스 레이어 노드에 등록하는 것에만 관심이 있을 수 있다. 그렇지만, 데이터 소스가 등록 동안 DSAS(2202)를 인식하지 못하는 경우라도, 일부 경우들에서 데이터 소스는 DSAS(2202)를 나중에 인식하게 될 수 있고 대역외 프로비저닝의 일부로서 자신의 데이터 스트림 정보를 명시적으로 송출할 수 있다.
도 27의 단계 1에서, DSAS(2202)가 제공된 정보에 기초하여 대응하는 데이터 스트림을 일의적으로 식별할 수 있도록, 데이터 소스는 자신의 데이터 스트림 정보 - 이 데이터 스트림 정보에 대해 데이터 소스는 데이터 스트림 애널리틱스 서비스를 이용하기를 원함 - 를 스트림 프로비저닝을 위해 DSAS-SF(2212)에게 송출한다. 데이터 소스에 의해 송신된 스트림 정보는 대역외 스트림 프로비저닝의 절차적 설명에 대한 도 26a 및 도 26b의 단계 6에 도시된 것과 동일하다. 대안적으로, SL 노드가 데이터 스트림 레지스트리를 유지하는 경우, 데이터 소스는 단지 스트림 ID를 DSAS(2202)에게 송출하고, DSAS(2202)는 이어서 시맨틱 설명(semantic description)으로부터 데이터 스트림의 다른 정보를 발견하기 위해, 제공된 스트림 ID에 기초하여, 데이터 스트림 레지스트리에 대한 룩업을 수행한다.
도 27의 단계 2에서, DSAS-SF(2212)의 스트림 식별 관리자/파서(SIM/P)(2304) 모듈은 데이터 소스로부터 정보를 수신하고 이를 DSAS 관리자(2206)에게 포워딩함으로써, 대응하는 엔트리가 스트림 ID 스토어(2321)에 만들어지도록 한다.
도 27의 단계 3에서, 보안 관리자(2302)에 의해 체크되는 바와 같이, 데이터 소스가 DSAS(2202)를 이용하는 데 요구된 권한들을 갖는 경우, 데이터 소스에 대한 엔트리가 스트림 ID 스토어(2321)(표 1)에 만들어지며, 따라서 테이블에서의 디바이스 어드레스 속성은 데이터 소스의 호스트 어드레스로 설정되고, 테이블에서의 디바이스 타입 속성은, 정보가 이용가능한 경우, 스마트폰과 같은, 스트림을 송출하는 디바이스의 타입으로 설정되며, 테이블에서의 디바이스 ID 속성은, 이용가능한 경우, 디바이스 식별자로 설정되고, 그리고 테이블에서의 나머지 속성들은 널(NULL)로 설정된다. DSAS 관리자(2206)는 자신이 데이터 소스로부터 수신한 데이터 스트림 정보에 대한 엔트리를 스트림 ID 스토어(2321)에 만든다. DSAS 관리자(2206)에 의해 만들어진 예시적인 스트림 ID 스토어(2321) 엔트리가 표 2에 나타내어져 있다.
도 27의 단계 4에서, DSAS 관리자(2206)는 데이터 소스에 의해 제공된 정보를 이용해 자신이 스트림 ID 스토어(2321)에 만든 엔트리에 관한 확인을 DSAS-SF(2212)의 SIM/P 모듈(2304)에게 송신한다.
도 27의 단계 5에서, DSAS-SF(2212)의 SIM/P 모듈(2304)은 대응하는 데이터 스트림의 식별을 용이하게 하기 위해, 데이터 스트림 프로비저닝의 완료, 즉 새로운 고유 데이터 스트림의 정보가 DSAS(2202)에 제공되었다는 것을 확인해주는 확인응답을 다시 데이터 소스에게 송신한다.
도 27에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 27에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 27에 예시된 단계들을 수행한다. 도 27에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
데이터 스트림 파싱
이는, 애트리뷰트들이 스트림 프로세싱 시스템에 의해 식별가능하도록, 데이터 스트림의 각각의 스트림 튜플(또는 메시지)을 개별 애트리뷰트들로 분해하는 프로세스이다. 이는 또한 권한 체크(authorization check)를 위해 관련 데이터 스트림의 스트림 ID를 검색하는 데 사용되고 추후 애널리틱스 동작에 의해 사용된다.
예를 들어, 다음과 같은 스트림 튜플 <37, 145, 9:41:00.01, 30, A1, VH>을 생각해본다. 도 28은 입력 스트림 튜플을 파서(2304)를 통과시킬 때의 출력 스트림 튜플을 도시하고 있다.
도 29는 스트림 ID 스토어(2321)에 저장된 정보를 사용하여 데이터 스트림을 일의적으로 식별하기 위한 스트림 파싱의 절차적 상세들을 예시하고 있다.
도 29의 단계 1에서, 데이터 스트림이 DSAS-SF(2212) 컴포넌트의 SIM/P 모듈(2304)을 통해 DSAS(2202)에 입수된다. DSAS(2202)는 데이터 소스 자체에서 호스팅될 수 있다.
도 29의 단계 2에서, 스트리밍 데이터가 이어서 스트림 식별 관리자/파서(SIM/P)(2304)를 통과한다. 데이터 스트림의 첫 번째 메시지를 수신할 때, SIM/P(2304)는 디바이스 - 이로부터 데이터 스트림이 수신됨 - 의 정보에 기초하여 데이터 스트림을 스트림 ID 스토어(2321) 내의 대응하는 엔트리(또는 엔트리들)와 매칭시킨다. 단일 디바이스로부터 다수의 스트림들이 있는 경우, 디바이스 포트 번호가 스트림을 식별하는 데 사용된다. 디바이스 포트 번호가 이용가능하지 않은 경우, 데이터 스트림 포맷과 같은, 스트림의 다른 정보가 파서(2304)를 사용하여 데이터 스트림을 파싱하는 데 사용된다. 파싱된 데이터 스트림 애트리뷰트들이 이어서 대응하는 스트림을 찾아내기 위해 스트림 ID 스토어(2321) 엔트리들과 매칭된다. 이 단계는 데이터 스트림의 스트림 ID를 검색하기 위해 행해진다.
도 29의 단계 3에서, 스트림 엔트리가 스트림 ID 스토어(2321)에서 발견되지 않으면, DSAS(2202)는 관련 데이터 스트림을 프로세싱하는 것을 진행하지 않는다. 대응하는 스트림의 스트림 엔트리가 발견되면, DSAS(2202)가 주어진 스트림에 액세스하기 위한 적절한 권한을 갖는지를 체크하기 위해 보안 관리자(2302)에 의해 스트림 ID가 사용된다.
도 29의 단계 4에서, 데이터 스트림이 권한 체크를 통과(clear)하면, 파서(2304)는 스트림 ID가 파싱된 스트림의 애트리뷰트들 중 하나인지를 체크한다. 아니오인 경우, 파서(2304)는 스트림 ID를 애트리뷰트들 중 하나로서 어펜드(append)한다. 추후 데이터 스트림 애널리틱스 동작이 스트림들을 식별하고 그것들을 구별하는 것이 유용하다. SIM/P(2304)는, DSAS 관리자(2206)를 통해, 이전에 '아니오'로 설정된 경우, 스트림 ID 스토어(2321) 내의 '스트림 관찰됨' 속성을 '예'로 업데이트한다.
도 29의 단계 5에서, 파싱된 스트림이 이어서 데이터 스트림의 프리프로세싱을 위해 프리프로세서(2306)로 포워딩된다. 파싱된 스트림에 부가하여, SIM/P(2304)는 또한 원시 데이터가 저장을 위해 송출되기 전에 원시 데이터 스트림을 프리프로세싱을 위해 프리프로세서(2306)로 포워딩한다. IoT 데이터 스트림의 실시간 프리프로세싱 시에 많은 작업이 행해졌다. 그것이 IoT 데이터 프로세싱의 중요한 부분인데, 그 이유는 데이터가 일반적으로 더티하고 잡음이 있기 때문이다. 더티한 데이터는 데이터가 누락된 부분들을 갖거나 리던던시들을 가질 수 있다는 것을 의미한다. 데이터 클리닝이라고 불리는, 실시간 프리프로세싱 방법들은 누락된 데이터를 핸들링하고 데이터로부터 잡음들 및 리던던시들을 제거하는 데 사용된다. 데이터 클리닝 방법들은, 일부 경우들에서, 대략적이다. 프리프로세싱은 또한 전송 채널을 통한 통신 비용을 감소시키기 위해 데이터의 압축을 수행하는 데 사용된다. 압축 기법들은, 일부 경우들에서, 손실(lossy)일 수 있다. 통신 비용을 감소시키기 위해, 데이터의 크기가 또한 샘플링, 통계적 집계들과 같은 기법들을 사용하여 감소될 있다.
도 29에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 29에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 29에 예시된 단계들을 수행한다. 도 29에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
절차 B: 쿼리 배포
DSAS(2202)에서의 쿼리 배포 절차는 다음과 같은 활동들로 이루어져 있다:
새로운 쿼리를 DSAS(2202)에 추가하기 - DSAS 클라이언트(2216)는 클라이언트들이, 쿼리 스토어(2318) 및 쿼리 연산자들(2312)과 같은, 쿼리에 관련된 자원들과 상호작용하기 위한 API 구현을 포함하는, DSAS API 모듈(2208)을 통해 새로운 쿼리를 DSAS(2202)에 추가한다. 새로운 쿼리를 DSAS(2202)에 추가할 때, 쿼리에 관련된 클라이언트(2216)에 의해 송신된 모든 정보가 쿼리 스토어(2318)(표 4에 나타내어져 있음)에 추가되고 쿼리의 구현은 쿼리 연산자로서 저장된다. (표 4에 기술된) 쿼리 스토어(2318)에 지정된 모든 속성들은 클라이언트(2216)에 의해 지정된다. 예를 들어, IITS 사용 사례에서 교차로 관리 시스템의 서비스 레이어의 DSAS(2202)에 "교차로의 통신 범위 내의 임의의 두 대의 차량 간의 충돌까지의 시간을 계산하기" 쿼리를 추가하는 것은 표 5에 나타낸 예와 같이 쿼리 스토어(2318)에 새로운 엔트리를 생성한다. 쿼리가 DSAS(2202)에 추가될 때, 쿼리 스토어(2318)에서의 대응하는 쿼리의 스위치(Switch) 속성의 디폴트 값이 애플리케이션의 요구사항에 따라 "인에이블(Enable)" 또는 "디스에이블(Disable)"로 설정될 수 있다.
DSAS(2202)에서의 기존의 쿼리를 수정하기 - DSAS 클라이언트(2216)는 기존의 쿼리를 수정한다. 기존의 쿼리를 수정하는 것은 쿼리 스토어(2318)에서의 대응하는 쿼리 엔트리를 업데이트하고/하거나 대응하는 쿼리 연산자를 업데이트하는 것을 의미한다. 예컨대: 상기 쿼리를 "임의의 두 대의 차량 사이의 충돌까지의 시간을 계산하고, 충돌까지의 시간이 10 초 미만이 되면 경보를 생성하기"로 수정한다. 기존의 쿼리의 수정은 또한 관련 쿼리에 대한 쿼리 스토어(2318)에서의 스위치의 값을 업데이트함으로써 시스템에서의 쿼리를 인에이블하거나 디스에이블하는 것을 포함한다.
DSAS(2202)로부터 기존의 쿼리를 삭제하기 - DSAS 클라이언트(2216)는 DSAS API를 통해 DSAS(2202)로부터 쿼리를 삭제할 수 있으며, 이는 쿼리 스토어(2318)로부터 대응하는 엔트리를 삭제하고 대응하는 쿼리 연산자를 삭제하는 것을 가져온다.
Figure pct00046
Figure pct00047
도 30a 및 도 30b는 쿼리 배포에 대한 상세한 절차적 설명을 도시하고 있다.
도 30a 및 도 30b의 단계 1에서, 클라이언트(2216)는 DSAS(2202)에 의해 관찰되는 데이터 스트림으로부터 어떤 유용한 통찰을 도출하는 데 관심이 있는 사용자, 애플리케이션 또는 IoT/M2M 디바이스일 수 있다. DSAS(2202)에 쿼리를 배포하기 위해, 제1 단계로서, 클라이언트(2216)는 DSAS API(2208)를 통해 DSAS 호스팅 노드와의 접속을 개시한다. 클라이언트(2216)는 DSAS(2202)와의 접속을 확립하기 위해 포털, 예를 들어, GUI 또는 웹 브라우저를 통해 요청을 송신한다. 이 요청은 클라이언트(2216)가 DSAS(2202)에 접속하기 위해 필요한 액세스 권한들을 갖는지, 클라이언트(2216)가 액세스하는 자원들 및 서비스들, 그리고 자원들 각각에 대해 클라이언트(2216)가 갖는 액세스의 종류를 결정하는 데 사용될 클라이언트 어드레스를 포함한다.
도 30a 및 도 30b의 단계 2에서, 접속을 위한 클라이언트 요청이, 클라이언트 측 포털들이 DSAS(2202)와 상호작용할 수 있게 해주는 API(2208)를 포함하는, DSAS(2202)의 DSAS API(2208) 컴포넌트에 의해 수신된다. 이러한 접속 요청은, DSAS API(2208) 내의 관리 API를 통해, DSAS 관리자(2206) 컴포넌트로 포워딩된다.
도 30a 및 도 30b의 단계 3에서, DSAS 관리자(2206) 내의 보안 관리자(2302)는 DSAS(2202) 내에서의 클라이언트(2216)의 권한들을 체크하기 위해 미리 정의된 액세스 제어 메커니즘을 사용한다. 이는 클라이언트(2216)가 DSAS(2202)에 액세스할 권한들을 갖는지를 체크한다. 이는 또한 클라이언트(2216)가 액세스할 권한을 부여받은 자원들 및 서비스들을 찾아낸다. 자원들은, 스트림 ID 스토어(2321) 및 쿼리 스토어(2318)와 같은, 클라이언트(2216)가 액세스할 수 있는 테이블들로 이루어져 있다. 액세스 제어 메커니즘은 또한 클라이언트(2216)가 이러한 자원들 각각에 대해 가지는 액세스의 종류를 체크한다. 클라이언트(2216)는 스트림 ID 스토어(2321) 및 쿼리 스토어(2318)에 대한 판독 및 기록 액세스를 가질 수 있다. 로그 테이블의 경우, 로그 테이블이 DSAS 모듈들에 의해서만 업데이트될 수 있기 때문에, 클라이언트(2216)는 판독 액세스만을 가질 수 있다. 보다 제한된 권한부여는 클라이언트(2216)의 액세스를, 제각기, 스트림 ID 스토어(2321) 및 쿼리 스토어(2318) 내의 특정 스트림 및 쿼리들로만 제한할 수 있다. 서비스들은, 액세스 제어 메커니즘 및 프리프로세서 구성과 같은, 클라이언트(2216)가 구성할 수 있는 관리 서비스들로 이루어져 있다.
도 30a 및 도 30b의 단계 4에서, DSAS 관리자(2206) 내의 보안 관리자(2302)는 클라이언트의 접속 요청에 대한 응답을 DSAS API(2208)에게 다시 송신한다. 클라이언트(2216)가 보안 관리자(2302)에 의해 인증되고 DSAS에 액세스할 권한들을 가지는 경우, 보안 관리자(2302)는 또한 클라이언트(2216)가 액세스할 권한을 부여받은 자원들 및 서비스들을 송신한다(도 30a 및 도 30b의 단계 3에서 논의됨).
도 30a 및 도 30b의 단계 5에서, DSAS API(2208)는 응답 메시지를 클라이언트 포털, 예컨대, 웹 브라우저 또는 GUI에게 송신한다. 클라이언트(2216)가, 응답 메시지에 지정된 바와 같이, 인증되는 경우, 응답 메시지는 또한 클라이언트(2216)가 액세스할 권한을 부여받은 자원들 및 서비스들을 포함한다.
도 30a 및 도 30b의 단계 6에서, 클라이언트(2216)가, 수신된 응답 메시지에 의해 지정된 바와 같이, 액세스 제어 메커니즘을 사용하여 보안 관리자(2302)에 의해 인증된 경우, 클라이언트(2216) 측 포털, 예컨대, 웹 브라우저 또는 GUI를 통해 클라이언트(2216)와 DSAS(2202) 사이에 접속이 확립된다. 클라이언트는 자신이 포털을 통해 액세스할 수 있는 자원들 및 서비스들의 뷰를 얻는다. 클라이언트가, 클라이언트에 의해 기술된 바와 같이, 쿼리 배포들을 수행하는 데 필요한 권한을 가지는 경우, 클라이언트는 요구된 쿼리 정보를 포털을 통해 DSAS(2202)에게 제출한다.
클라이언트가 수행하는 데 관심이 있는 쿼리 배포의 종류에 기초하여, 클라이언트는, 다음과 같은 상이한 사례들을 가질 수 있는, 대응하는 쿼리 정보를 송출할 수 있다:
Figure pct00048
클라이언트가 새로운 쿼리를 시스템에 추가하는 데 관심이 있는 경우, 클라이언트는, 표 5에 나타낸 바와 같은, 정보를 포털을 통해 제출한다. 클라이언트는 또한 쿼리 연산자의 구현을 DSAS(2202) 내에 배포한다.
Figure pct00049
Figure pct00050
클라이언트가 DSAS(2202)에서의 기존의 쿼리를 수정하는 데 관심이 있는 경우, 클라이언트는, 표 7에 나타낸 바와 같은, 정보를 포털을 통해 제출한다. 클라이언트는 쿼리 스토어(2318)의 단지 하나의 속성을 업데이트하는 데 관심이 있을 수 있다. 따라서, 클라이언트가 자신이 수정하는 데 관심이 있는 쿼리를 식별하기 위해 선택하도록 요구받는 쿼리 설명을 제외하고, 클라이언트에 의한 업데이트를 필요로 하지 않는 나머지 파라미터들은 임의적이다. 클라이언트는 또한 쿼리 연산자 구현을 업데이트하는 데 관심이 있을 수 있으며, 이 경우에 클라이언트는 포털을 통해 새로운 쿼리 연산자 구현을 재업로드하거나 DSAS(2202) 내에서의 구현을 직접 업데이트한다.
Figure pct00051
Figure pct00052
클라이언트가 DSAS(2202)로부터 쿼리를 삭제하는 데 관심이 있는 경우, 클라이언트는, 표 7에 나타낸 바와 같은, 정보를 포털을 통해 제출한다. 따라서, 클라이언트는 포털을 통해 쿼리 설명을 송신하기만 하면 된다.
Figure pct00053
도 30a 및 도 30b의 단계 7에서, 포털을 통해 클라이언트에 의해 제출된 쿼리 정보가 DSAS API(2208)에 의해 수신된다.
도 30a 및 도 30b의 단계 8에서, DSAS API(2208)는 클라이언트에 의해 제출된 쿼리 정보를 DSAS 관리자(2206)에게 송신한다.
도 30a 및 도 30b의 단계 9에서, DSAS 관리자(2206)는 포털을 통해 클라이언트에 의해 송신된 정보에 기초하여 쿼리 스토어(2318)를 업데이트한다. 새로운 쿼리를 시스템에 추가하는 경우에, DSAS 관리자(2206)는 시스템에 추가된 각각의 새로운 쿼리에 고유 쿼리 ID를 배정하고, 클라이언트에 의해 송신된 정보에 기초하여, 쿼리 ID에 대한 새로운 엔트리를 쿼리 스토어(2318)에 만든다. 쿼리 연산자 구현이 또한 DSAS 관리자(2206)를 통해 DSAS(2202)에 저장된다. 기존의 쿼리를 수정하는 경우에, DSAS 관리자(2206)는 클라이언트에 의해 송신된 파라미터들의 리스트를 참조하고 그에 따라 쿼리 스토어(2318)를 업데이트한다. 클라이언트가 연산자 구현 업데이트를 요청한 경우, 쿼리 연산자가 DSAS 연산자를 통해 수정된다. DSAS(2202)로부터 쿼리를 삭제하는 경우에, DSAS 관리자(2206)는 클라이언트에 의해 송신된 쿼리 설명을 참조하고, 엔트리를 쿼리 스토어(2318)로부터 그리고 대응하는 연산자 구현을 DSAS-SAE(2210)로부터 삭제한다. 쿼리 스토어(2318)에서의 '호스트 어드레스' 필드는 localhost로 설정되는데, 그 이유는 쿼리를 수신하는 동일한 노드가 쿼리에 대답하기 위해 스트림 애널리틱스를 수행하기 때문이다. 분산 시나리오에서의 '호스트 어드레스'의 값은 다음 섹션(분산 서비스로서의 데이터 스트림 애널리틱스 서비스)에서 추후에 논의되었다.
도 30a 및 도 30b의 단계 10에서, DSAS 관리자(2206)는 쿼리 스토어(2318) 및 쿼리 연산자에 대해 행해진 업데이트들에 관한 확인을 DSAS API(2208)에게 송신한다.
도 30a 및 도 30b의 단계 11에서, DSAS API(2208)는 쿼리 배포 절차의 완료를 확인해주는 확인응답을 클라이언트에게 송신한다.
상기 절차들 외에도, 지능형 쿼리 배포에 대한 논의들이 좀 더 제시된다: 앞서 기술된 바와 같이, 쿼리를 DSAS(2202)에 생성하거나, DSAS(2202)에서의 쿼리를 수정, 삭제 또는 인에이블/디스에이블할 수 있는, 외부 클라이언트에 의해 쿼리가 DSAS(2202)에 배포된다. 그렇지만, DSAS(2202)에 스마트 쿼리 관리자(2316)를 도입하는 것이 가능하다. 쿼리 관리자(2316)는 시스템에서 머신 러닝 알고리즘을 구현하는 것, 및 쿼리에 관한 스마트한 의사 결정을 하도록 쿼리 관리자(2316)를 트레이닝하기 위해 머신 러닝 기법들을 사용하는 것에 의해 지능형으로 될 수 있다.
스마트 쿼리 관리자(2316)는 장시간 사용되지 않은 쿼리들이 있는지 체크하고, 자원들을 해방시키기 위해 그 쿼리들을 시스템으로부터 제거하는 데 사용될 수 있다. 응용분야들에 의해 요구되는 경우, 이는 또한 DSAS(2202)에서의 쿼리 수정들이 빈번히 행해지지 않도록 하는 데 사용될 수 있다. 매우 빈번한 쿼리 수정들이 생성된 결과들의 품질에 영향을 줄 수 있으며 특정한 응용분야들에 대해 바람직하지 않을 수 있다. DSAS(2202)가 또한 배치 애널리틱스 서비스(batch analytics service)를 그 안에 통합하고 있는 경우, 스마트 쿼리 관리자(2316)는 또한 배치 애널리틱스에서 빈번히 사용되는 적절한 쿼리들을 식별하고, 이들이 스트리밍 애널리틱스 시나리오에 배포될 것을 제안하거나, 배치 애널리틱스로부터 스트림 애널리틱스로의 쿼리의 변환이 실현가능한 경우, 이러한 쿼리들을 자동으로 배포하는 데 사용될 수 있다.
배치 애널리틱스는, 큰 데이터 볼륨들이 일정 시간 기간 동안 수집되고 이어서 일괄적으로(in a batch) 프로세싱되고 분석되는, 데이터를 프로세싱하는 한 방식이다. 따라서, 배치 애널리틱스의 경우, 데이터는 일반적으로, 데이터베이스 또는 데이터 웨어하우스와 같은, 데이터 리포지토리에 저장된다.
도 30a 및 도 30b에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 30a 및 도 30b에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 30a 및 도 30b에 예시된 단계들을 수행한다. 도 30a 및 도 30b에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
절차 C: 데이터 스트림 애널리틱스
이전에 언급된 바와 같이, '인에이블됨(Enabled)'으로 설정된 쿼리 스토어(2318) 내의 모든 쿼리들을 프로세싱하기 위해 데이터 스트림 애널리틱스가 수행된다. 도 31은 데이터 스트림 애널리틱스 프로세스에 대한 상세한 워크플로를 도시하고 있다.
도 31의 단계 1에서, 제1 단계로서, 쿼리 관리자(2316)는 쿼리 스토어(2318)에서 임의의 업데이트들이 있는지 주기적으로 체크한다.
Figure pct00054
쿼리 스토어(2318)가 이전에 비어 있었고, 쿼리 관리자(2316)가 쿼리 스토어(2318)에서 첫 번째 쿼리 엔트리를 방금 발견한 경우, 쿼리 관리자(2316)는 애널리틱스 필터(2310)를 처음으로 인보크하는 DSAS 관리자(2206)에게 업데이트에 관해 보고하고, 프리프로세싱된 파싱된 데이터 스트림이 이제 프리프로세서(2306)로부터 애널리틱스 필터(2310)로 포워딩된다. 애널리틱스 필터(2310)는 DSAS(2202)에 의해 관찰되는 모든 데이터 스트림으로부터, 쿼리 스토어(2318)에 저장된 쿼리들 중 어떠한 것에 의해서도 요구되지 않는, 모든 애트리뷰트들을 프루닝 아웃(prune out)하는 데 사용된다. 필터링된 스트림은 DSAS-SAE(2210) 컴포넌트 내의 SAE 소스(2314)로 보내진다. 우리는 이어서 단계 2로 이동한다. 불필요한 애트리뷰트들이 쿼리들의 리스트 및 데이터 스트림에 기초하여 프루닝되도록, 애널리틱스 필터(2310)가 최적화된 방식으로 구현된다.
Figure pct00055
쿼리 스토어(2318)가 비어 있지 않고, 쿼리 스토어(2318) 및/또는 쿼리 연산자들(2312)에 업데이트가 없는 경우, 쿼리 관리자(2316)는 진행 중인 잡을 계속 관리한다.
Figure pct00056
쿼리 스토어(2318)가 비어 있지 않고, 쿼리 스토어(2318) 및/또는 쿼리 연산자들(2312)에 업데이트들이 있는 경우, 단계 2로 이동한다.
도 31의 단계 2에서, 쿼리 스토어(2318)에서의 업데이트에 따라, 다음과 같은 4개의 단계 중 하나가 취해진다:
Figure pct00057
새로운 쿼리가 DSAS(2202)에 도입되었고 새로운 엔트리가 쿼리 스토어(2318)에 만들어지는 경우, 쿼리 스토어(2318) 내의 '스위치' 엔트리가 인에이블됨으로서 설정되면, 쿼리 관리자(2316)는 이 쿼리에 대한 새로운 잡을 생성하고 잡 테이블(2320)(표 8에 나타내어져 있음)을 업데이트한다. 테이블에서의 잡 ID 필드는 각각의 잡을 일의적으로 식별해준다. 잡 ID 필드는, 관련 프로세스 및 자식 프로세스들을 모니터링하는 데도 사용될 수 있는, 잡의 부모 프로세스 ID일 수 있다. 잡은 새로 입력된 쿼리에 대응하는, 쿼리 스토어(2318)에 지정된 연산자를 인보크한다.
Figure pct00058
DSAS(2202)에서 쿼리가 수정된 경우, 수정이 대응하는 연산자의 재-인보케이션(re-invocation)를 요구하면, 쿼리 관리자(2316)는 이전의 잡을 잡 테이블(2320)로부터 삭제하고 새로운 잡을 생성하여, 수정된 쿼리를 프로세싱하는 연산자를 재-인보크(re-invoke)한다.
Figure pct00059
DSAS(2202)에서 쿼리가 삭제된 경우, 대응하는 잡이 잡 테이블(2320)로부터 삭제되어, 대응하는 연산자 인스턴스들을 킬링(killing)한다. 인-메모리 상태는 휘발성 메모리에 저장되며 따라서 잡을 킬링하는 것이 또한 인-메모리 상태를 자동으로 삭제한다.
Figure pct00060
쿼리 스위치가 쿼리 스토어(2318)에서 디스에이블됨으로부터 인에이블됨으로 변경되는 경우, 쿼리 관리자(2316)는 이 쿼리에 대한 새로운 잡을 생성하고 잡 테이블(2320)(표 8에 나타내어져 있음)을 업데이트한다. 잡은 새로 인에이블된 쿼리에 대응하는, 쿼리 스토어(2318)에 지정된 연산자를 인보크한다. 쿼리가 인에이블됨으로부터 디스에이블됨으로 스위칭되는 경우, 대응하는 잡이 쿼리 관리자(2316)에 의해 잡 테이블(2320)로부터 삭제된다.
Figure pct00061
도 31의 단계 3에서, SAE 소스(2314)는 원하는 애트리뷰트들을 갖는 요구된 스트림들의 세트를 각각의 쿼리에 대응하는 각각의 연산자에 피드하고, 각각의 연산자는 차례로 쿼리를 프로세싱하기 위해 인-메모리 상태를 생성한다. 이러한 인-메모리 상태가 계속 유지된다.
도 31에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 31에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 31에 예시된 단계들을 수행한다. 도 31에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
절차 D: 출력 트리거링
우리는 데이터 스트림 프로세싱 시스템에서의 쿼리가 오래 지속되고 계속 실행된다는 것을 알고 있다. 비록 쿼리에 대한 메모리 상태가 계속 유지되지만, 상태가 쿼리에 대답하는 데 계속 사용되지 않을 수 있다. 쿼리에 대한 대답이 계속 생성될 수 있거나 이벤트가 트리거링될 때만 가끔 요구될 수 있다. 출력 트리거링은 응용분야의 요구사항에 기초하여 쿼리에 대답하는 단계이다. IITS 사용 사례에서 논의된 바와 같은 쿼리 1 및 쿼리 2를 검토해보자:
1) 쿼리 1: 교차로의 통신 범위 내의 임의의 두 대의 차량 간의 충돌까지의 시간을 계산하기
2) 쿼리 2: 교차로의 통신 범위 내의 임의의 자동차와 보행자 간의 충돌까지의 시간을 계산하기
상기 예에서, 교차로 관리 허브가 교차로에 가까이 있는 임의의 두 대의 차량 간의 충돌 이전에 그 시간을 계속 추적할 필요가 있기 때문에, 쿼리 1에 대한 출력이 계속 트리거링된다. 그렇지만, 쿼리 2에 대한 출력은 교차로를 건너가려고 하는 보행자가 교차로에서 탐지될 때에만 트리거링된다. 이 경우에, 쿼리 2에 대한 출력을 트리거링하는 이벤트는 교차로에서의 보행자의 탐지이다.
그렇지만, 쿼리 출력이 또한 클라이언트(3202)에 의해 수동으로 트리거링될 수 있다. 예를 들어, 교차로에서의 교통 흐름의 조건을 알아보기 위해 스마트 앱을 사용하는 자동차 운전자를 생각해본다. 이 경우에, 스마트 앱은 클라이언트(3202)로서 간주될 수 있다. 앱을 핸들링하는 운전자는 교차로에서의 교통 조건을 명시적으로 요청할 수 있다. 이 예에서, 비록 교통 조건이 백엔드에서 계속 분석되고 있지만 운전자/앱에 의해 명시적으로 요청될 때에만 앱 상에 보여진다.
클라이언트(3202)가 쿼리로부터의 결과를 트리거링하기 위해 DSAS(2202)에 접속하는 경우, 그의 퍼미션(permission)이 ACP를 통해 검증되고, 이어서 각각의 쿼리에 관한 정보가 DSAS에 의해 DSAS API(2208)를 통해 주어진다. 출력 트리거링 절차에 대한 상세한 설명은 이하에서 주어진다.
클라이언트(3202)가 쿼리를 트리거링하기 위해 DSAS(2202)에 접속하는 경우, 그의 퍼미션이 ACP를 통해 검증되고, 이어서 각각의 쿼리에 관한 정보가 DSAS(2202)에 의해 DSAS API(2208)를 통해 주어진다. 쿼리 트리거링 절차에 대한 상세한 설명은 이하에서 주어진다.
도 32a 및 도 32b의 단계 1에서, 클라이언트(3202)는 DSAS(2202)에 의해 관찰되는 데이터 스트림으로부터 어떤 유용한 통찰을 도출하는 데 관심이 있는 사용자, 애플리케이션 또는 IoT/M2M 디바이스일 수 있다. 클라이언트(3202)는 도 22에 도시된 클라이언트(3202)와 상이한 클라이언트(2216)일 수 있다. DSAS(2202)에서의 쿼리에 대한 출력 또는 결과들을 얻기 위해, 제1 단계로서, 클라이언트는 DSAS API(2208)를 통해 DSAS 호스팅 노드와의 접속을 개시한다. 클라이언트(3202)는 DSAS(2202)와의 접속을 확립하기 위해 포털, 예를 들어, GUI 또는 웹 브라우저를 통해 요청을 송신한다. 이 요청은 클라이언트(3202)가 DSAS(2202)에 접속하기 위해 필요한 액세스 권한들을 갖는지, 클라이언트(2216)가 액세스하는 자원들 및 서비스들, 그리고 자원들 각각에 대해 클라이언트(2216)가 갖는 액세스의 종류를 결정하는 데 사용될 클라이언트 어드레스를 포함한다.
도 32a 및 도 32b의 단계 2에서, 접속을 위한 클라이언트 요청이, 클라이언트 측 포털들이 DSAS(2202)와 상호작용할 수 있게 해주는 API(2208)를 포함하는, DSAS(2202)의 DSAS API(2208) 컴포넌트에 의해 수신된다. 이러한 접속 요청은, DSAS API(2208) 내의 관리 API를 통해, DSAS 관리자(2206) 컴포넌트로 포워딩된다.
도 32a 및 도 32b의 단계 3에서, DSAS 관리자(2206) 내의 보안 관리자(2302)는 DSAS(2202) 내에서의 클라이언트(3202)의 권한들을 체크하기 위해 미리 정의된 액세스 제어 메커니즘을 사용한다. 이는 클라이언트(3202)가 DSAS(2202)에 액세스할 권한들을 갖는지를 체크한다. 이는 또한 클라이언트(3202)가 액세스할 권한을 부여받은 자원들 및 서비스들을 찾아낸다. 자원들은, 스트림 ID 스토어(2321) 및 쿼리 스토어(2318)와 같은, 클라이언트(3202)가 액세스할 수 있는 테이블들로 이루어져 있다. 액세스 제어 메커니즘은 또한 클라이언트(3202)가 이러한 자원들 각각에 대해 가지는 액세스의 종류를 체크한다. 이 경우에, 클라이언트(3202)는 쿼리 설명들 - 클라이언트(3202)는 이들에 대한 출력을 얻는 데 관심이 있음 - 의 리스트에 대한 판독 액세스를 필요로 한다. 이는 또한 결과들을 위해 필요한 파라미터들을 DSAS(2202)에게 송신하기 위해 액세스를 필요로 한다.
도 32a 및 도 32b의 단계 4에서, DSAS 관리자(2206) 내의 보안 관리자(2302)는 클라이언트의 접속 요청에 대한 응답을 DSAS API(2208)에게 다시 송신한다. 클라이언트(3202)가 보안 관리자(2302)에 의해 인증되고 DSAS(2202)에 액세스할 권한들을 갖는 경우, 보안 관리자(2302)는 또한 클라이언트가 액세스할 권한을 부여받은 자원들 및 서비스들을 송신한다(단계 3에서 논의됨). 이 경우에, 클라이언트는 쿼리 설명 - 클라이언트는 이에 대한 결과를 보는 데 관심이 있음 - 의 리스트를 DSAS(2202)로부터 수신해야만 한다.
도 32a 및 도 32b의 단계 5에서, DSAS API(2208)는 응답 메시지를 클라이언트 포털, 예컨대, 웹 브라우저 또는 GUI에게 송신한다. 클라이언트가, 응답 메시지에 지정된 바와 같이, 인증되는 경우, 응답 메시지는 또한 클라이언트가 액세스할 권한을 부여받은 자원들 및 서비스들을 포함한다.
도 32a 및 도32b의 단계 6에서, 클라이언트가, 수신된 응답 메시지에 의해 지정된 바와 같이, 액세스 제어 메커니즘을 사용하여 보안 관리자(2302)에 의해 인증된 경우, 클라이언트 측 포털, 예컨대, 웹 브라우저 또는 GUI를 통해 클라이언트와 DSAS(2202) 사이에 접속이 확립된다. 클라이언트는 자신이 포털을 통해 액세스할 수 있는 자원들 및 서비스들의 뷰를 얻는다. 클라이언트가, 클라이언트에 의해 기술된 바와 같이, 특정 쿼리들에 대한 출력을 트리거링하는 데 필요한 권한을 가지는 경우, 클라이언트는 요구된 쿼리 정보를 포털을 통해 DSAS(2202)에게 제출한다.
표 9는 클라이언트(3202)가 특정 쿼리들에 대한 출력을 트리거링하기 위해 송신하는 파라미터들을 나타내고 있다. 클라이언트(3202)는 하나 이상의 쿼리에 대한 출력을 트리거링하기 위한 요청을 제출할 수 있다.
Figure pct00062
도 32a 및 도 32b의 단계 7에서, 포털을 통해 클라이언트(3202)에 의해 제출된 쿼리 정보가 DSAS API(2208)에 의해 수신된다.
도 32a 및 도32b의 단계 8에서, DSAS API(2208)는 클라이언트(3202)에 의해 제출된 쿼리 정보를, DSAS 관리자(2206)를 경유하여, DSAS-SAE(2210) 내의 쿼리 관리자(2316)에게 송신한다.
도 32a 및 도 32b의 단계 9에서, 쿼리 관리자(2316)는 대응하는 실행 중인 연산자 인스턴스(들)를 트리거링한다 - 사용자는 하나 초과의 쿼리에 대한 결과들에 관심이 있을 수 있다.
도 32a 및 도 32b의 단계 10에서, 연산자 인스턴스들은, 쿼리에 대한 출력을 생성하기 위해, 각각이 그 각자의 쿼리에 대해 유지하는 그들의 대응하는 인-메모리 상태들, 및 각각의 쿼리에 대해 클라이언트(3202)에 의해 송신된 대응하는 출력 파라미터들을 사용한다.
도 32a 및 도 32b의 단계 11에서, 쿼리 관리자(2316)는 쿼리의 대응하는 결과들을 DSAS 관리자(2206)를 경유하여 DSAS API(2208)에게 송출한다. 쿼리의 출력은 쿼리 스토어(2318)에서의 지정된 출력 위치로부터 쿼리 관리자(2316)에 의해 검색된다. 클라이언트(2216)가, 쿼리 연산자(2312)에 의해 DSAS 관리자(2206) 및 API(2208)를 경유하여 클라이언트(2216) 포털로 직접 송신되는 출력과 같은, 출력에 액세스하는 다른 방식들이 있을 수 있다.
도 32a 및 도32b의 단계 12에서, DSAS API(2208)는 요구된 결과들을, 클라이언트(3202)에 의해 원하는 바에 따라, 클라이언트(3202)에게 송신한다.
도 32a 및 도 32b에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 32a 및 도 32b에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 32a 및 도 32b에 예시된 단계들을 수행한다. 도 32a 및 도 32b에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
절차 E: 데이터 저장
대부분의 경우들에서, 데이터는 관리 이유들로 서비스 레이어의 상이한 데이터 수집 지점들에 저장된다. 많은 응용분야들에서, 이러한 데이터는 추후 분석 및/또는 심층 분석을 목적으로 데이터를 웨어하우징(warehousing)하기 위해 클라우드 또는 인프라스트럭처 노드 노드들로 추가로 포워딩된다.
따라서, DSAS의 SIM/P(2304) 모듈이 데이터 스트림을 일단 파싱하면, 데이터는, 적용가능한 경우, 저장을 위해 프리프로세서(2306) 및 저장 필터(2308)를 통해 전달된다.
저장 필터(2308)는, IoT 디바이스들에 의해 그 자신의 특정 사용을 위해 생성되고 전송들의 나중 부분에서 중요하지 않을 수 있는 애트리뷰트들과 같은 불필요한 애트리뷰트들을 각각의 튜플로부터 프루닝 아웃함으로써 데이터 스트림의 차원을 감소시키는데 사용된다. 이 필터는 또한 저장을 위해 데이터를 최적화하기 위해, 저장 정책에 기초하여, 압축 기법들을 사용할 수 있다. 저장 필터(2308)는 IoT 서비스 레이어에 다음과 같은 두 가지 이점을 제공한다:
1. 데이터를 서비스 레이어 노드들을 거쳐 인프라스트럭처 노드로 전송하는 통신 비용을 감소시킨다.
2. 서비스 레이어에서의 데이터 수집 지점들의 저장 요구사항들을 감소시킨다. 클라우드에서의 또는 인프라스트럭처 노드들에서의 데이터 웨어하우스들에 대해 저장 비용이 또한 대폭 감소될 수 있다.
데이터 스트림을 데이터 저장을 위해 송출하기 전에 데이터 스트림을 감소시키는 저장 필터(2308)는, 저장 노드들의 저장 정책 또는 디바이스 가이드라인들에 기초하여, 클라이언트에 의해 구성된다. 이러한 정책들은 데이터 스트림 내의 그리고/또는 프리프로세서로부터 추출된 어느 애트리뷰트들이 저장되는지를 지정하는 규칙들을 정의한다. 예를 들어, 데이터 스트림의 일부 애트리뷰트들은 나중에 요구되지 않을 수 있으며, 데이터를 생성하는 디바이스의 참조를 위해서만 존재한다. 디바이스 가이드라인들을 사용하여, 이러한 애트리뷰트들이 프리프로세서를 사용하여 데이터 스트림으로부터 프루닝 아웃될 수 있다.
분산 서비스로서의 데이터 스트림 애널리틱스 서비스
이 섹션에서, 우리는 다수의 DSAS가 시스템에 배포될 수 있는 분산 시나리오를 생각해본다. 특히, 아래의 이유들로 분산 DSAS 서비스가 필요하다:
Figure pct00063
분산 데이터 소스들로부터의 데이터 스트림에 대한 실시간 애널리틱스를 용이하게 한다. 코디네이터 노드에서 또는 클라우드 서비스를 사용하는 클라우드 상에서 분산 셋업으로부터의 스트림들의 전부의 합집합(union of all) 또는 그 서브세트(subset)에 대해 스트리밍 애널리틱스가 수행될 수 있다. 예를 들어, 개별 교차로를 통해 흐르는 교통은 교차로 자체에서 로컬로 수행되는 실시간 애널리틱스를 이용할 수 있다. 그렇지만, 교차로들에 걸친(예컨대, 도시 전체 내에서의) 교통 흐름을 최적화하기 위해, 중앙 위치에서(예컨대, 클라우드에서) 부가의 레벨의 애널리틱스가 수행될 수 있다. 이것은 개별 교차로들이 그들의 결과들의 데이터 스트림들을 다시 클라우드에 제공하는 것에 의해 행해질 수 있으며, 클라우드는 이어서 이러한 스트림들에 대해 애널리틱스를 수행하고 교차로들이 조율된 방식으로 조정을 할 수 있게 해줄 수 있다.
Figure pct00064
에지 애널리틱스를 용이하게 한다 - 가능한 한 많은 애널리틱스를 에지로 이동시키고, 에지 노드들의 오버로딩을 회피하기 위해, 보다 복잡한 애널리틱스를 에지로부터 보다 멀리 이동시킨다
Figure pct00065
로드 밸런싱 - 거대한 데이터가 주어지면, 보다 빠르고 어쩌면 병렬 분석을 위해 복잡한 애널리틱스가 몇 개의 노드에 걸쳐 분산될 수 있다
Figure pct00066
확장성 - 데이터 스트림의 처리율 또는 크기가 증가함에 따라 시스템을 보다 확장성 있게 만든다.
DSAS 호스팅 SL 노드들의 분산 셋업은 앞서 언급된 장점들을 서비스 레이어에 제공할 것이다. 데이터 스트림이 MQTT, XMPP(Extensible Messaging and Presence Protocol) 등과 같은 경량 메시지 전달 모델들(light weight message passing models)을 통해 상이한 노드들에 전달될 수 있다. 이러한 모델들은 또한 메시지 배달(message delivery)에 대한 신뢰성을 보장한다. 시스템이 강건하고 필요에 따라 애널리틱스 동작들을 클라우드로 이동시킬 수 있도록, 이러한 SL 노드들의 전부 또는 일부가 경량 클라우드 서비스들에 접속될 수 있다. SL 노드들의 분산 셋업은, 분산 클라우드 서비스들과 함께, 데이터 스트림 애널리틱스의 맥락에서 유연성 및 강건성을 DSAS(2202)에 추가한다.
우리는 IoT/M2M 서비스 레이어에서의 다수의 분산 DSAS 노드들의 다음과 같은 세 가지 일반 레이아웃을 식별하였다.
도 33a는 DSAS-SF(2212) 및 DSAS-SAE(2210) 컴포넌트들이 2개의 별개의 DSAS 호스팅 서비스 레이어 노드 상에서 호스팅되는 분산 셋업을 도시하고 있다. 이것은 DSAS-SF(2212) 컴포넌트를 갖는 하나 이상의 DSAS 노드가 있고, 각각이 상이한 데이터 스트림들의 세트를 수신하는 경우를 커버한다. DSAS-SF(2212) 컴포넌트들을 갖는 이러한 DSAS 호스팅 노드들은 DSAS-SAE(2210) 컴포넌트를 갖는 하나 이상의 DSAS 노드에만 접속된다. 이러한 셋업은 특히 에지에 보다 가까운 노드가 낮은 프로세싱 능력들을 갖고 데이터 스트림을 프리프로세싱하고 스트림 애널리틱스 및 저장을 위해 다른 노드들로 포워딩하는 데만 사용될 때 유용하다.
보다 신속하고 효율적인 데이터 분석을 위해 애널리틱스 동작을 다수의 노드들에 걸쳐 분산 및 병렬화하기 위해, DSAS-SAE(2210) 컴포넌트를 갖는 DSAS 노드가 다른 DSAS 노드들의 DSAS-SAE(2210) 컴포넌트들에 또는 스트림 애널리틱스 능력들을 갖는 클라우드 노드들에 계층적으로 접속될 수 있다.
도 33b는 데이터 소스에 가장 가까운 DSAS 호스팅 노드가 프리프로세싱을 위한 DSAS-SF(2212) 컴포넌트 및 애널리틱스 동작들을 위한 DSAS-SAE(2210) 컴포넌트 둘 다를 가지는 시나리오를 도시하고 있다. 이것은 DSAS-SF(2212) 컴포넌트를 갖는 하나 이상의 DSAS 노드가 있고, 각각이 상이한 데이터 스트림들의 세트를 수신하는 경우를 커버한다. 이제 클라이언트는 데이터 스트림을 직접 수신하지 않는 DSAS 호스팅 노드를 통해 쿼리를 배포하거나 쿼리에 대한 출력을 요청한다. 클라이언트가 도 33b에서의 DSAS #3을 통해 쿼리를 배포하도록 요청했다고 생각해본다. 이어서 이 DSAS-SAE(2210)는 어느 DSAS-SF(2212) 컴포넌트들이 쿼리를 위해 요구된 데이터 스트림들을 수신하는지에 따라 DSAS-SF #1 및/또는 DSAS #2와 통신한다. 이 경우에, 데이터 애널리틱스 동작들을 위해 동일한 노드들의 DSAS-SAE(2210) 컴포넌트와 통신하는 것과 함께, 이 DSAS-SF(2212) 컴포넌트들은 또한 다른 DSAS 호스팅 SL 노드들의 하나 이상의 DSAS-SAE(2210) 컴포넌트와 통신한다. 보다 신속하고 효율적인 데이터 분석을 위해 애널리틱스 동작을 다수의 노드들에 걸쳐 분산 및 병렬화하기 위해, DSAS-SAE(2210) 컴포넌트를 갖는 DSAS 노드가 다른 DSAS 노드들의 DSAS-SAE(2210) 컴포넌트들에 또는 스트림 애널리틱스 능력들을 갖는 클라우드 노드들에 계층적으로 접속될 수 있다.
도 33c는 DSAS 호스팅 SL 노드들 각각이 데이터 프리프로세싱 및 스트림 애널리틱스를 위해 DSAS-SF(2212) 및 DSAS-SAE(2210) 둘 다를 포함하는 분산 셋업을 도시하고 있다. 클라이언트가 스트림에 직접 접속되지 않는 DSAS 호스팅 노드를 통해 쿼리를 배포하도록 요청하는 앞서 주어진 예에서, DSAS #3의 DSAS-SAE 노드(도 33c)는 DSAS #1 및/또는 DSAS #2의 DSAS-SF(2212) 컴포넌트들에 직접 접속할 수 있거나, 그 자신의 노드의 DSAS-SF(2212) 컴포넌트를 통해 접속할 수 있다. 이 셋업은 첫 번째 DSAS 호스팅 노드가 스트림 애널리틱스 동작을 수행하지만 로드 분산 및 병렬화를 위해 스트리밍 애널리틱스 능력들을 갖는 다른 DSAS-SAE 노드들 및/또는 클라우드에도 접속되는 시나리오에서 유용할 수 있다.
도 33에서, 데이터 스트림 애널리틱스 동작들의 로드 분산 및 병렬화를 위해 상이한 DSAS 호스팅 SL 노드들의 임의의 2개의 DSAS-SAE(2210) 컴포넌트 사이의 통신이 하위 분산 데이터 스트림 애널리틱스 엔진의 아키텍처 셋업 및 구현에 대체로 의존한다는 점에 주목하는 것은 흥미로운 일이다. 스트림 애널리틱스 동작을 분산시키는 데 사용되는 로직에 기초한다(예를 들어, Apache Storm 및 IBM Infosphere Stream은 분산 노드들에 걸친 데이터 스트림 애플리케이션의 로드 분산 및 병렬화를 위해, 제각기, 그 각자의 로직, 토폴로지 및 데이터 흐름 그래프를 사용한다).
그렇지만, DSAS-SF(2212)와 DSAS-SAE(2210) 사이의 통신은 단일 DSAS 호스팅 노드에 대해 앞서 명시된 것과 동일한 절차적 상세들을 따르지만, 차이점은 이제 컴포넌트들이 상이한 노드들에서 호스팅되고 DSAS 관리자(2206)를 통해 서로 통신한다는 것이다.
분산 시스템은 서로 조율하여 동작할 필요가 있다. 분산 시스템에 걸친 통신, 분산 시스템에 걸친 서비스들 및 스트리밍 애널리틱스 동작의 로드 밸런싱, 스트리밍 애널리틱스 시스템의 스트리밍 애널리틱스 동작의 병렬화, 시스템이 시스템에 대한 로드에 기초하여 스케일 업 또는 다운될 수 있도록 하는 확장성, 및 노드에서의 서비스들 또는 동작들의 장애의 경우에 다른 노드들이 장애 있는 서비스들 또는 동작들을 재개할 수 있도록 하는 결함 복구(fault recovery)를 위해 이러한 조율이 요구된다. 분산 노드들 간의 조율을 관리하는 두 가지 방식이 있다: 중앙집중식 모니터링 및 피어-투-피어 모니터링:
중앙집중식 모니터링을 갖는 분산 시스템: 중앙집중식 모니터링의 경우에, 단일 중앙집중식 노드가 분산 시스템에 대한 코디네이터로서 기능한다. 그것이 분산 시스템에 걸친 로드 밸런싱, 결함 복구 및 통신을 책임지고 있다. 이 셋업은 분산 노드에 걸친 조율을 수행할 코디네이터 노드 내의 부가의 관리 서비스를 필요로 한다.
중앙집중식 모니터링을 갖는 분산 시스템에서, 클라이언트는 쿼리를 배포하거나 분석 결과들을 요청하기 위해 코디네이터에 접속하고, 코디네이터는 잡을 시스템에 걸쳐 분배한다. 네트워크 상에 또는 클라우드에 위치된 IoT/M2M 서비스 레이어 내의 DSAS 호스팅 SL 노드 중 하나가 코디네이터로서 기능할 수 있다. 이 노드는, 코디네이터 모듈이라고 불리는, DSAS(2202) 내의 부가의 컴포넌트를 가질 것이다. 클라이언트는 DSAS API(2208)를 사용하여 이 코디네이터 모듈을 통해 DSAS와 통신한다. 이 코디네이터는 각각의 노드의 DSAS 관리자(2206)를 통해 모든 분산 DSAS 호스팅 SL 노드들 간의 통신을 조율하는 데 사용된다. 이 셋업에서, 개별 DSAS 호스팅 노드 내에서 실행 중인 프로세스들 및 서비스들은 여전히 DSAS 관리자(2206)에 의해 관리되지만, DSAS 관리자(2206)가 장애 있는 프로세스들 또는 잡들을 복구할 수 없는 경우에, 가능한 경우, 장애 있는 잡이 코디네이터에 의해 다른 노드(들)에서 재개될 수 있도록, DSAS 관리자(2206)는 코디네이터 노드와 통신한다.
표 3에 나타내어진 쿼리 스토어(2318)에서의 호스트 ID 필드는 코디네이터 노드의 호스트 어드레스여야 한다. DSAS-SF(2212)는 필터링된 데이터 스트림을 DSAS 관리자(2206)를 경유하여 코디네이터 노드의 DSAS-SAE(2210) 컴포넌트로 송출하고, DSAS-SAE(2210) 컴포넌트는 이어서 그것을 코디네이터(3402) 컴포넌트를 통해 분산 시스템에 걸쳐 배포한다.
도 33a 내지 도 33c에 예시된 기능성이, 이하에서 기술되는 도 49c 또는 도 49d에 예시된 것들 중 하나와 같은, M2M 네트워크의 장치(예컨대, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다는 것이 이해된다.
코디네이터(3402) 컴포넌트를 갖는 DSAS에 대한 가능한 아키텍처가 도 34에 도시되어 있다.
피어-투-피어 모니터링을 갖는 분산 시스템: 피어 투 피어 모니터링의 경우에, 시스템 내의 각각의 노드가 분산 시스템에 대한 코디네이터(3402)로서 기능한다. 클라이언트는 쿼리를 배포하거나 분석 결과들을 요청하기 위해 노드 중 임의의 것에 접속할 수 있고 그 노드는 자신이 수신하는 쿼리에 대해 분산 시스템에 걸친 로드 밸런싱, 결함 복구 및 통신을 완전히 책임지고 있다. 이 셋업에서, 노드 내의 DSAS 관리자(2206)는 자신이 수신한 쿼리에 대해 분산 시스템에 걸쳐 코디네이터(3402)로서 기능한다. 표 3에 나타내어져 있는 쿼리 스토어(2318)에서의 호스트 ID 필드는 쿼리가 배포된 DSAS 호스팅 노드의 호스트 어드레스여야 한다. DSAS-SF(2212)는 필터링된 데이터 스트림을 DSAS 관리자(2206)를 경유하여 호스트 어드레스에 지정된 노드의 DSAS-SAE(2210) 컴포넌트로 송출하고, DSAS-SAE(2210) 컴포넌트는 이어서 쿼리에 관련된 애널리틱스 동작을 DSAS 관리자(2206)를 통해 시스템 내의 다른 DSAS 호스팅 노드들에 분배하는 일을 책임지고 있다.
이 셋업에서, 개별 DSAS 호스팅 노드 내에서 실행 중인 프로세스들 및 서비스들은 여전히 DSAS 관리자(2206)에 의해 관리되지만, DSAS 관리자(2206)가 장애 있는 프로세스들 또는 잡들을 복구할 수 없는 경우에, 가능한 경우, 장애 있는 잡이 각자의 DSAS 관리자(2206)에 의해 다른 노드(들)에서 재개될 수 있도록, DSAS 관리자(2206)는 다른 DSAS 호스팅 노드들의 DSAS 관리자(2206)와 통신한다.
서비스 레이어에서 DSAS를 인에이블/디스에이블하는 것의 용이성
임의의 다른 서비스와 유사하게, DSAS(2202)는 데이터 스트림 애널리틱스 능력들을 제공하기 위해 어느 정도의 자원들을 필요로 할 것이다. 이 오버헤드가 서비스 레이어 내에서 항상 바람직한 것은 아닐 수 있다. 따라서, 프로세싱하고 분석할 서비스 레이어의 현재의 요구사항에 기초하여, 서비스 레이어 내에서 DSAS(2202)를 인에이블하거나 디스에이블하는 것이 유연해야만 한다. 도 35 및 도 36은, 제각기, 서비스 레이어에서 DSAS(2202)를 디스에이블하거나 인에이블하기 위한 스위치의 등가물을 도시하고 있다. 도 35는 서비스 레이어에서 DSAS(2202)가 디스에이블되는 경우, DSAS 호스팅 노드가 데이터를 첫 번째 데이터 수집 지점으로, 상이한 노드에 위치하는 경우, 포워딩하는 라우터로서 기능할 뿐이라는 것을 도시하고 있다.
이 섹션은 oneM2M 아키텍쳐 내의 DSAS 기능성들의 실시예들을 제시한다. 먼저, DSAS(2202)가 CSF로서 CSE에 통합될 수 있다. 이어서 oneM2M 자원 트리와의 통합을 보여주기 위해 DSAS(2202) 관련 자원들 및 애트리뷰트들이 제시된다. 마지막으로, 다양한 DSAS 절차들을 실현하기 위해 oneM2M 절차들이 제공된다.
도 35 및 도 36에 예시된 기능성이, 이하에서 기술되는 도 49c 또는 도 49d에 예시된 것들 중 하나와 같은, M2M 네트워크의 장치(예컨대, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다는 것이 이해된다.
새로운 CSF로서의 DSAS
공통 서비스 기능(CSF)은 개념적으로 다수의 서브-기능들을 함께 그룹화하는 유익한 아키텍처 구성(informative architectural construct)으로서 정의된다. 각각의 oneM2M 공통 서비스 엔티티(CSE)는 oneM2M 환경의 CSF들의 세트의 인스턴스화이다. DSAS(Data Stream Analytics Service)의 실현은 도 37에 도시된 바와 같이 oneM2M CSE에 대한 새로운 CSF(DSAS CSF(3702))일 수 있다. DSAS 호스팅 CSE(3704)는 DSAS CSF(3702)를 포함할 수 있다.
oneM2M 서비스 레이어에서의 DSAS의 아키텍처 레이아웃
DSAS(Data Stream Analytics Service)(2202)는 도 38에 도시된 바와 같이 oneM2M 서비스 레이어 아키텍처에 통합될 수 있다. 센서들 및/또는 다른 IoT/M2M 디바이스들로 이루어진 애플리케이션 엔티티(AE)는 데이터 스트림의 소스 또는 데이터 소스들로서 간주될 수 있다. 하나 이상의 DSAS 호스팅 CSE(3704)가 있을 수 있다. 다수의 DSAS 호스팅 CSE들(3704)은 oneM2M 서비스 레이어에서의 데이터 스트림 애널리틱스 서비스의 분산 셋업을 의미한다. CSE가 물리적 서버이든 클라우드 서버이든 간에, DSAS 호스팅 CSE(3704)는 ASN-CSE, MN-CSE, 또는 IN-CSE일 수 있다. 데이터 저장 CSE(3802)는 일시적으로 데이터를 수집하고 그것을 <contentInstance> 자원들로서 저장하는 MN-CSE일 수 있거나, 데이터가 영구적으로 저장되는 IN-CSE일 수 있다. 데이터 저장 노드는 또한 oneM2M 클라우드 서버일 수 있다.
이러한 아키텍처에서, DSAS(2202)는, 보다 빠른 실시간 데이터 분석을 위해, 데이터가 처음으로 <contentInstance> 자원으로서 저장되기 전에도 데이터 스트림을 분석하는 데 사용된다. 따라서, DSAS(2202)는 AE와 데이터 저장 CSE 사이에 있는 CSE에서 호스팅된다. DSAS(2202)가 데이터 저장 CSE 내에서도 호스팅될 수 있다. 그 경우에, 데이터 스트림 애널리틱스는 데이터가 저장 노드에 저장되기 전에 수행된다. 데이터 스트림으로부터 유용한 통찰들을 도출하는 데 관심이 있는 DSAS 클라이언트(2216)는 동일한 네트워크 또는 상이한 네트워크로부터의 AE 또는 CSE일 수 있다.
도 37 및 도 38에 예시된 기능성이, 이하에서 기술되는 도 49c 또는 도 49d에 예시된 것들 중 하나와 같은, M2M 네트워크의 장치(예컨대, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있다는 것이 이해된다.
DSAS에 대한 oneM2M 자원
도 39에 도시된 바와 같은 oneM2M 시스템 내에서의, <DSAS>라고 불리는, DSAS(2202)에 대한 새로운 oneM2M 자원 타입이 기술된다. CSE 베이스가 모든 DSAS(2202) 관련 자원들을 호스팅하는 경우 이 <DSAS> 자원이 CSE 베이스에 중앙집중식으로 위치될 수 있다. 대안적으로, 그것이 또한 <AE>, <node>, 또는 다른 oneM2M 자원들의 자식 자원으로서 존재할 수 있다. 자원은 애트리뷰트 switch 및 2개의 자식 자원, <streamDescriptor> 및 <queryDescriptor>를 포함한다. 새로운 애트리뷰트는 표 10에 나타내어져 있는 반면, <DSAS>의 자식 자원들은 표 11에 나타내어져 있다.
애트리뷰트 switch는 CSE 내의 DSAS(2202)를 인에이블 또는 디스에이블하는 데 사용되고, 2개의 값 - 0 또는 1 - 을 취할 수 있다. 값 0은 도 35에 도시된 바와 같이 oneM2M 서비스 레이어에서의 DSAS(2202)를 디스에이블하고, 값 1은 도 36에 도시된 바와 같이 oneM2M 서비스 레이어에서의 DSAS(2202)를 인에이블한다.
Figure pct00067
자원 <streamDescriptor>는 DSAS(2202)에 의해 수신된 각각의 고유 데이터 스트림을 기술해야 한다. 이는 자신이 기술하고 있는 스트림의 메타데이터 및 부가 정보를 포함한다. 이는 표 2에 나타내어진 스트림 ID 스토어(2321)의 oneM2M 시스템에 대한 매핑이다. 자원 <queryDescriptor>는, 쿼리당 하나의 자원씩, DSAS(2202)에 내장된(built into) 쿼리들에 관련된 모든 정보를 저장하는 데 사용되어야 한다. 이는 표 3에 나타내어진 쿼리 스토어(2318)의 oneM2M 시스템에 대한 매핑이다.
Figure pct00068
<streamDescriptor> 자원
<streamDescriptor> 자원에 대한 자원 트리는 도 40에 도시되어 있다. DSAS(2202)가 모니터링하는 각각의 스트림은 그 자신의 <streamDescriptor> 자원을 가질 것이며, 이 자원은 대역내 또는 대역외 방법들을 통해 생성될 수 있다.
<streamDescriptor> 자원의 애트리뷰트들의 리스트는 표 12에 기술되어 있다.
Figure pct00069
<streamDescriptor> 자원의 자식 자원이 표 13에 기술되어 있다.
Figure pct00070
<queryDescriptor> 자원
<queryDescriptor> 자원에 대한 자원 트리가 도 41에 도시되어 있다. <queryDescriptor> 자원은 데이터 스트림 애널리틱스 엔진에 의해 사용되는 쿼리 동작을 제공한다.
<queryDescriptor> 자원의 애트리뷰트들의 리스트가 표 14에 기술되어 있다.
Figure pct00071
<queryDescriptor> 자원의 자식 자원이 표 15에 기술되어 있다.
Figure pct00072
<streamInfo> 자원
<streamInfo> 자원의 자원 트리는 도 42에 도시되어 있다. <streamInfo> 자원은 요구된 쿼리를 수행하기 위해 데이터 스트림 애널리틱스 엔진에 의해 사용되는 데이터 소스 입력(들)을 제공한다.
<streamInfo> 자원의 애트리뷰트들은 표 16에 기술되어 있다.
Figure pct00073
1.1.1.1 <output> 자원
<streamInfo> 자원의 자원 트리는 도 43에 도시되어 있다. <output> 자원 내의 정보는 대응하는 쿼리에 의해 트리거링되는 출력의 포맷 및 출력을 어디에 저장할지를 DSAS(2202)에 지시한다.
<output> 자원의 애트리뷰트들은 표 17에 기술되어 있다.
Figure pct00074
<output> 자원의 자식 자원이 표 18에 기술되어 있다.
Figure pct00075
데이터 스트림 식별 및 프로비저닝을 위한 oneM2M 절차들 도 44는 oneM2M 시스템 내에서의 대역내 스트림 프로비저닝을 위한 절차를 도시하고 있다. 이 경우에, DSAS(2202)는 CSE(DSAS 호스팅 CSE(3704)) 내에 통합되어 있다.
도 44의 단계 0에서, DSAS 아키텍처 전체가 협력하도록 oneM2M 시스템에 관련된 모든 구성이 수행되는 것이 생각된다. 데이터 소스 AE(4402), CSE(3704) 및 DSAS(2202) 모두가 서로 통신할 수 있다.
도 44의 단계 1에서, AE에 의해 전송된 데이터 스트림에 대한 <streamDescriptor> 자원을 생성하라는 요청이 AE(데이터 스트림을 생성하는 디바이스)에 의해 CSE(3704)에게 송신된다. AE는 데이터 스트림의 정보 및 메타데이터를 요청에 포함시킨다.
도 44의 단계 2에서, AE(4402)가 <streamDescriptor> 자원을 생성하기 위한 액세스 권한을 갖도록 보장하기 위해 CSE(3704)가 ACP를 체크한다. 액세스 제어가 승인(grant)되는 경우, 단계 3으로 계속되고; 그렇지 않으면, 단계 4로 간다.
도 44의 단계 3에서, CSE(3704)는 AE로부터 수신된 정보에 기초하여 <streamDescriptor> 자원을 생성한다. DSAS(2202) 내의 스트림 ID 스토어(2321)에 대한 엔트리가 또한 생성된다.
도 44의 단계 4에서, CSE(3704)는 적절한 상태를 갖는 응답을 AE에게 송신한다.
도 44에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 44에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 44에 예시된 단계들을 수행한다. 도 44에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
도 45는 oneM2M 시스템 내에서의 대역외 스트림 프로비저닝의 일 실시예를 도시하고 있다. DSAS(2202)가 CSE(4504) 외부에 도시되어 있지만, 그것이 또한 CSE(4504) 내에 통합될 수 있다. AE(DSAS 클라이언트)(4502)가 DSAS 클라이언트로서 기능하는 다른 CSE일 수 있다는 것에 유의한다.
도 45의 단계 0에서, DSAS 아키텍처 전체가 협력하도록 oneM2M 시스템에 관련된 모든 구성들이 수행되는 것이 생각된다. DSAS(2202), CSE, 및 DSAS 클라이언트 AE(4502) 모두가 서로 통신할 수 있다.
도 45의 단계 1에서, 다른 AE(도시되지 않음)에 의해 전송된 데이터 스트림에 대한 <streamDescriptor> 자원을 생성하라는 요청이 AE(DSAS 클라이언트)에 의해 CSE(4504)에게 송신된다. AE는 데이터 스트림의 정보 및 메타데이터를 요청에 포함시킨다.
도 45의 단계 2에서, DSAS 클라이언트 AE(4502)가 <streamDescriptor> 자원을 생성하기 위한 액세스 권한을 갖도록 보장하기 위해 CSE가 ACP를 체크한다. 액세스 제어가 승인되는 경우, 단계 3으로 계속되고; 그렇지 않으면, 단계 7로 간다.
도 45의 단계 3에서, CSE(4504)는 DSAS 클라이언트 AE(4502)로부터 수신된 정보에 기초하여 <streamDescriptor> 자원을 생성한다.
도 45의 단계 4에서, CSE(4504)는 스트림 ID 스토어(2321)에 엔트리를 생성하라는 요청을 DSAS에게 송신한다. DSAS가 CSE(4504) 내에 통합되어 있는 경우에, 이 단계는 내부 프로세스이다.
도 45의 단계 5에서, DSAS는 스트림 ID 스토어(2321)에 엔트리를 생성한다.
도 45의 단계 6에서, DSAS는 스트림 ID 스토어(2321) 엔트리 생성의 상태를 갖는 응답을 송신한다. DSAS가 CSE(4504) 내에 통합되어 있는 경우에, 이 단계는 내부 프로세스이다.
도 45의 단계 7에서, CSE(4504)는 적절한 상태를 갖는 응답을 DSAS 클라이언트 AE(4502)에게 송신한다.
도 45에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 45에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 45에 예시된 단계들을 수행한다. 도 45에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
쿼리 배포, 데이터 스트림 애널리틱스 및 출력 트리거링을 위한 oneM2M 절차들
도 46a 및 도 46b는 쿼리 배포, 데이터 스트림 애널리틱스, 및 출력 트리거링을 위한 oneM2M 절차들의 일 실시예를 도시하고 있다. DSAS가 CSE(4504)와 별개로 위치된 것으로 도시되어 있지만, 그것이 또한 CSE(4504) 내에 통합될 수 있다. 통합될 때, 단계 2 내지 단계 7이 CSE(4504) 내에서 실행되고 메시징은 CSE(4504)와 DSAS(2202) 사이에서 내부적으로 발생한다. AE2(DSAS 클라이언트)(4502) 또는 AE3(DSAS 클라이언트)(4602)이 DSAS 클라이언트로서 기능하는 다른 CSE일 수 있다는 것에 유의한다.
도 46a 및 도 46b의 단계 0에서, DSAS 아키텍처 전체가 협력하도록 시스템에 관련된 모든 구성들이 수행되는 것이 생각된다. 데이터 스트림은 데이터 소스로부터 DSAS(2202)에 입수되고 연속적인 스트림이다. 스트림은 쿼리가 시스템에 배포되기 이전에 또는 그 이후에 입수될 수 있다.
도 46a 및 도 46b의 단계 1에서, AE2(DSAS 클라이언트)(4502)는 새로운 <queryDescriptor> 자원을 CSE(4504)에 생성하라는 요청을 송신함으로써 쿼리 배포를 수행한다.
도 46a 및 도 46b의 단계 2에서, CSE(4504)는 액세스 제어를 위해 ACP를 체크하고, 승인된 경우, AE2(4502)에 의해 제공된 정보를 사용하여 새로운 <queryDescriptor> 자원을 생성한다.
도 46a 및 도 46b의 단계 3에서, CSE(4504)는 새로운 <queryDescriptor> 자원에 관하여 DSAS(2202)에 통보한다. DSAS(2202)가 CSE(4504) 내에 통합되어 있는 경우에, 이 단계는 내부 프로세스이다.
도 46a 및 도 46b의 단계 4에서, DSAS는 쿼리의 대응하는 연산자 구현을 DSAS-SAE(2210) 내에 배포하기 위해 CSE(4504)에 의해 송신된 정보를 사용한다. 쿼리 관리자(2316)는, 쿼리가 <queryDescriptor> 자원 내에서 "인에이블됨"(애트리뷰트 switch가 값 '1'을 가져야 함)으로 설정되어 있는 경우, 이 연산자를 인보크한다. 쿼리 배포가 성공적인 경우 데이터 스트림 애널리틱스가 시작된다.
도 46a 및 도 46b의 단계 5에서, DSAS(2202)는 쿼리 배포의 완료에 관한 확인을 CSE(4504)에게 송신한다. DSAS(2202)가 CSE(4504) 내에 통합되어 있는 경우에, 이 단계는 내부 프로세스이다.
도 46a 및 도 46b의 단계 6에서, CSE(4504)는 쿼리 배포의 완료에 관한 확인응답을 AE2에게 송신한다.
도 46a 및 도 46b의 단계 7에서, 데이터 스트림 분석 프로세싱이 계속된다. 이 프로세싱은 단계 4에서 시작되었으며, 이 단계는, 쿼리 배포가 성공적인 한, 분석 프로세싱의 계속적인 동작을 나타낸다.
도 46a 및 도 46b의 단계 8에서, 쿼리를 배포한 AE와 동일한 AE이거나 상이한 AE일 수 있는, AE3(DSAS 클라이언트)(4602)은 배포된 쿼리로부터 결과들을 획득하는 데 관심이 있다. 그것은 <queryDescriptor>의 <output> 자원에 가입하기 위해 가입 요청을 CSE(4504)에게 송신한다.
도 46a 및 도 46b의 단계 9에서, CSE(4504)는 AE3에 대한 가입 프로세스를 완료하고, 동일한 것에 관한 확인을 다시 송신한다.
도 46a 및 도 46b의 단계 10에서, 가입된 쿼리에 대한 출력은 어떤 트리거링된 이벤트에 기초하여 DSAS에서 또는 DSAS 클라이언트에 의해 외부적으로 트리거링된다.
도 46a 및 도 46b의 단계 11에서, DSAS(2202)는 출력을 CSE(4504)에게 송신하고, CSE(4504)는 그것을 <output> 자원에 저장한다.
도 46a 및 도 46b의 단계 12에서, CSE(4504)는 이어서 출력을 AE3(4602)에게 송신한다.
도 46a 및 도 46b의 단계 13에서, AE3(4602)은 출력을 수신하는 것에 대한 확인을 송신한다.
도 46a 및 도 46b에 예시된 단계들을 수행하는 엔티티들이 도 49c 및 도 49d에 예시된 것들과 같은 네트워크 장치 또는 컴퓨터 시스템의 메모리에 저장되고 그의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들이라는 것이 이해된다. 즉, 도 46a 및 도 46b에 예시된 방법(들)은, 도 49c 또는 도 49d에 예시된 장치 또는 컴퓨터 시스템과 같은, 네트워크 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능 명령어들)의 형태로 구현될 수 있고, 이 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때, 도 46a 및 도 46b에 예시된 단계들을 수행한다. 도 46a 및 도 46b에 예시된 임의의 전송 및 수신 단계들이 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능 명령어들(예컨대, 소프트웨어)의 제어 하에서 장치의 통신 회로부에 의해 수행될 수 있다는 것이 또한 이해된다.
GUI들(Graphical User Interfaces)과 같은, 인터페이스들은 사용자가 서비스 레이어에서의 데이터 스트림 애널리틱스에 관련된 기능성들을 제어 및/또는 구성하는 것을 지원하기 위해 사용될 수 있다. 도 47은 클라이언트가 쿼리들을 생성하거나 DSAS(2202)에 배포되고 인에이블된 쿼리들에 액세스하기 위한 GUI(4702)를 도시하고 있다. 클라이언트는 드롭다운 메뉴를 통해 시스템에 인에이블된 쿼리들의 리스트를 제공받는다. 또한, 클라이언트는 쿼리의 출력이 저장되는 포맷을 선택하기 위한 옵션을 제공받는다. 출력이 CSV 파일, 텍스트 파일, HTML 등으로 저장될 수 있다. 쿼리가 시간 윈도를 지원하는 경우, 클라이언트는 또한 윈도 길이, 즉 데이터 - 그에 대한 쿼리가 프로세싱되었음 - 의 스코프를 선택하는 옵션을 갖는다. 데이터 스트림 애널리틱스가 대략적인 대답들을 수반할 수 있기 때문에, 클라이언트는 또한 자신이 자신의 대답에서 허용할 수 있는 최대 에러를 선택하는 옵션을 제공받는다.
쿼리를 배포하기 위한 GUI는 대화형일 수 있으며, 여기서 클라이언트가 수행하는 데 관심이 있는 쿼리 배포의 종류에 기초하여(클라이언트가 필요한 권한을 가지고 있다고 가정함), GUI는 상이한 옵션들을 클라이언트에게 제공한다. 클라이언트가 수행하는 데 관심이 있는 배포의 종류에 기초하여 클라이언트에게 제공되는 예시적인 인터페이스들이 도 48a 및 도 48b에 도시되어 있다.
도 47 및 도 48의 것과 같은 인터페이스들이 이하에서 설명되는 도 49c 및 도 49d에 도시된 것들과 같은 디스플레이들을 사용하여 생성될 수 있다는 것이 이해될 것이다.
예시적인 M2M/IoT/WoT 통신 시스템
본 명세서에 설명된 다양한 기법들이 하드웨어, 펌웨어, 소프트웨어, 또는 적절한 경우, 이들의 조합들과 관련하여 구현될 수 있다. 그러한 하드웨어, 펌웨어, 및 소프트웨어는 통신 네트워크의 다양한 노드들에 위치된 장치들에 존재할 수 있다. 장치들은 본원에 기술되는 방법들을 수행하기 위해 단독으로 또는 서로 조합하여 동작할 수 있다. 본 명세서에서 사용되는 바와 같이, "장치", "네트워크 장치", "노드", "디바이스", 및 "네트워크 노드"라는 용어들은 서로 바꾸어 사용될 수 있다.
"서비스 레이어"는 네트워크 서비스 아키텍처 내의 기능 레이어(functional layer)일 수 있다. 서비스 레이어들은 전형적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 레이어 위쪽에 위치되고 클라이언트 애플리케이션들에게 부가 가치 서비스들을 제공한다. 서비스 레이어는 또한, 예를 들어, 제어 레이어 및 전송/액세스 레이어와 같은, 하위 자원 레이어(lower resource layer)에서 코어 네트워크들에 대한 인터페이스를 제공한다. 서비스 레이어는 서비스 정의, 서비스 런타임 인에이블먼트(service runtime enablement), 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함한 다수의 카테고리들의 (서비스) 능력들 또는 기능성들을 지원한다. 최근에, 몇 개의 산업 표준 단체들, 예컨대, oneM2M이 M2M 타입의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크들과 같은 배포들에 통합시키는 것과 연관된 과제들을 해결하기 위해 M2M 서비스 레이어들을 개발해오고 있다. M2M 서비스 레이어는 애플리케이션들 및/또는 다양한 디바이스들에게, CSE 또는 SCL이라고 지칭될 수 있는, 서비스 레이어에 의해 지원되는, 앞서 언급된 능력들 또는 기능들의 모음 또는 세트에 대한 액세스를 제공할 수 있다. 몇몇 예들은, 다양한 애플리케이션들에 의해 흔히 사용될 수 있는, 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 접속 관리(connectivity management)를 포함하지만, 이들로 제한되지 않는다. 이 능력들 또는 기능들은 M2M 서비스 레이어에 의해 정의되는 메시지 포맷들, 자원 구조들, 및 자원 표현들을 사용하는 API들을 통해 이러한 다양한 애플리케이션들에게 이용가능하게 된다. CSE 또는 SCL은 하드웨어 및/또는 소프트웨어로 구현될 수 있는 그리고 다양한 애플리케이션들 및/또는 디바이스들에 노출된 (서비스) 능력들 또는 기능들(즉, 이러한 기능 엔티티들 간의 기능 인터페이스들)을, 그들이 이러한 능력들 또는 기능들을 사용하도록, 제공하는 기능 엔티티이다.
도 49a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 M2M(machine to machine), IoT(Internet of Things), 또는 WoT(Web of Things) 통신 시스템(10)의 다이어그램이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구성 블록들(building blocks)을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트 또는 노드는 물론 IoT/WoT 서비스 레이어 등일 수 있다. 통신 시스템(10)은 개시된 실시예들의 기능성을 구현하는 데 사용될 수 있고, 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들 및 기능성을 포함할 수 있다.
도 49a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는 고정 네트워크(예컨대, 이더넷, 파이버(Fiber), ISDN, PLC, 또는 이와 유사한 것) 또는 무선 네트워크(예컨대, WLAN, 셀룰러, 또는 이와 유사한 것) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는 음성, 데이터, 비디오, 메시징, 방송, 또는 이와 유사한 것과 같은 콘텐츠를 다수의 사용자들에게 제공하는 다수의 액세스 네트워크들로 이루어져 있을 수 있다. 예를 들어, 통신 네트워크(12)는, CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA), 및 이와 유사한 것과 같은, 하나 이상의 채널 액세스 방법을 이용할 수 있다. 게다가, 통신 네트워크(12)는, 예를 들어, 코어 네트워크, 인터넷, 센서 네트워크, 산업 제어 네트워크(industrial control network), 개인 영역 네트워크(personal area network), 융합 개인 네트워크(fused personal network), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.
도 49a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배포(end-to-end M2M deployment)의 네트워크 측을 지칭하고, 필드 도메인은, 보통 M2M 게이트웨이 뒤에 있는, 영역 네트워크들(area networks)을 지칭한다. 필드 도메인 및 인프라스트럭처 도메인 둘 다는 각종의 상이한 네트워크 노드들(예컨대, 서버들, 게이트웨이들, 디바이스들, 및 이와 유사한 것)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 단말 디바이스들(18)을 포함할 수 있다. 원하는 바에 따라, 임의의 수의 M2M 게이트웨이 디바이스(14) 및 M2M 단말 디바이스(18)가 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 것이 이해될 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 단말 디바이스들(18) 각각은, 통신 회로부를 사용하여, 통신 네트워크(12) 또는 직접 라디오 링크(direct radio link)를 통해 신호들을 전송 및 수신하도록 구성된다. M2M 게이트웨이(14)는 무선 M2M 디바이스들(예컨대, 셀룰러 및 비-셀룰러)은 물론 고정 네트워크 M2M 디바이스들(예컨대, PLC)이 통신 네트워크(12)와 같은 운영자 네트워크들 또는 직접 라디오 링크 중 어느 하나를 통해 통신할 수 있게 해준다. 예를 들어, M2M 단말 디바이스들(18)은 데이터를 수집하고, 데이터를 통신 네트워크(12) 또는 직접 라디오 링크를 통해 M2M 애플리케이션(20) 또는 M2M 디바이스들(18)에게 송신할 수 있다. M2M 단말 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 단말 디바이스(18)로부터 데이터를 수신할 수 있다. 게다가, 이하에서 기술되는 바와 같이, 데이터 및 신호들이 M2M 서비스 레이어(22)를 통해 M2M 애플리케이션(20)에게 송신되고 그로부터 수신될 수 있다. M2M 단말 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN(예컨대, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 유선(wireline)을 비롯한 다양한 네트워크들을 통해 통신할 수 있다.
예시적인 M2M 단말 디바이스들(18)은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카들(connected cars), 스마트 미터들(smart meters), 게임 콘솔들, PDA들(personal digital assistants), 건강 및 피트니스 모니터들, 전등들, 서모스탯들, 어플라이언스들, 차고문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 콘센트들을 포함할 수 있지만, 이들로 제한되지 않는다.
도 49b를 참조하면, 필드 도메인에 예시된 M2M 서비스 레이어(22)는 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), 및 M2M 단말 디바이스들(18) 그리고 통신 네트워크(12)에 대한 서비스들을 제공한다. 통신 네트워크(12)는 개시된 실시예들의 기능성을 구현하는 데 사용될 수 있고, 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들 및 기능성을 포함할 수 있다. M2M 서비스 레이어(22)는, 예를 들어, 이하에 기술되는 도 49c 및 도 49d에 예시된 디바이스들을 비롯한, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예컨대, 클라우드/스토리지 팜(storage farm) 등) 또는 이와 유사한 것에 의해 구현될 수 있다. M2M 서비스 레이어(22)가 원하는 바에 따라 임의의 수의 M2M 애플리케이션, M2M 게이트웨이(14), M2M 단말 디바이스(18), 및 통신 네트워크(12)와 통신할 수 있다는 것이 이해될 것이다. M2M 서비스 레이어(22)는 서버들, 컴퓨터들, 디바이스들, 또는 이와 유사한 것을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다. M2M 서비스 레이어(22)는 M2M 단말 디바이스들(18), M2M 게이트웨이들(14), 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 레이어(22)의 기능들은 각종의 방식들로, 예를 들어, 웹 서버로서, 셀룰러 코어 네트워크에서, 클라우드에서, 기타로 구현될 수 있다.
예시된 M2M 서비스 레이어(22)와 유사하게, 인프라스트럭처 도메인에 M2M 서비스 레이어(22')가 있다. M2M 서비스 레이어(22')는 인프라스트럭처 도메인 내의 M2M 애플리케이션(20') 및 하위 통신 네트워크(underlying communication network)(12)에 대한 서비스들을 제공한다. M2M 서비스 레이어(22')는 또한 필드 도메인 내의 M2M 게이트웨이들(14) 및 M2M 단말 디바이스들(18)에 대한 서비스들을 제공한다. M2M 서비스 레이어(22')가 임의의 수의 M2M 애플리케이션, M2M 게이트웨이 및 M2M 디바이스와 통신할 수 있다는 것이 이해될 것이다. M2M 서비스 레이어(22')는 상이한 서비스 제공자에 의한 서비스 레이어와 상호작용할 수 있다. M2M 서비스 레이어(22')는 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/스토리지 팜들등) 또는 이와 유사한 것을 포함할 수 있는, 네트워크의 하나 이상의 노드에 의해 구현될 수 있다.
또한 도 49b를 참조하면, M2M 서비스 레이어들(22 및 22')은 다양한 애플리케이션들 및 버티컬(vertical)들이 이용할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이러한 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 빌링(billing), 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 해준다. 본질적으로, 이러한 서비스 능력들은 애플리케이션들을 이러한 기능성들을 구현하는 부담으로부터 자유롭게 해주고, 따라서 애플리케이션 개발을 단순화시키며 출시까지의 비용 및 시간(cost and time to market)을 감소시킨다. 서비스 레이어들(22 및 22')은 또한 M2M 애플리케이션들(20 및 20')이 서비스 레이어들(22 및 22')이 제공하는 서비스들과 관련하여 네트워크들(12)을 통해 통신할 수 있게 해준다.
본 출원의 방법들은 서비스 레이어(22 및 22')의 일부로서 구현될 수 있다. 서비스 레이어(22 및 22')는 API들(application programming interfaces) 및 하위 네트워킹 인터페이스들(underlying networking interfaces)의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어이다. ETSI M2M과 oneM2M 둘 다는 본 출원의 접속 방법들을 포함할 수 있는 서비스 레이어를 사용한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)이라고 지칭된다. SCL은 M2M 디바이스(여기서 이는 DSCL(device SCL)이라고 지칭됨), 게이트웨이(여기서 이는 GSCL(gateway SCL)이라고 지칭됨), 및/또는 네트워크 노드(여기서 이는 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 레이어는 CSF들(Common Service Functions)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입의 CSF들의 세트의 인스턴스화는, 상이한 타입들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 미들 노드(middle node), 애플리케이션 특정 노드(application-specific node)) 상에서 호스팅될 수 있는, CSE(Common Services Entity)라고 지칭된다. 게다가, 본 출원의 접속 방법들은 본 출원의 접속 방법들과 같은 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(resource-oriented architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.
일부 실시예들에서, M2M 애플리케이션들(20 및 20')은 개시된 시스템들 및 방법들과 관련하여 사용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호작용하는 애플리케이션들을 포함할 수 있고, 또한 다른 개시된 시스템들 및 방법들과 관련하여 사용될 수 있다.
일 실시예에서, 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은, 도 49b에 도시된 바와 같은, M2M 서버, M2M 게이트웨이, 또는 M2M 디바이스와 같은, M2M 노드에 의해 호스팅되는 M2M 서비스 레이어 인스턴스 내에 호스팅될 수 있다. 예를 들어, 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은 M2M 서비스 레이어 인스턴스 내에 또는 기존의 서비스 능력 내의 서브-기능(sub-function)으로서 개별 서비스 능력을 포함할 수 있다.
M2M 애플리케이션들(20 및 20')은 운송, 건강 및 웰니스(health and wellness), 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시 - 이들로 제한되지 않음 - 와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 앞서 언급된 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들 및 다른 노드들에 걸쳐 실행되는 M2M 서비스 레이어는, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 빌링, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들 통합과 같은 기능들을 지원하고, M2M 애플리케이션들(20 및 20')에 대한 서비스들로서 이러한 기능들을 제공한다.
일반적으로, 서비스 레이어들(22 및 22')은 애플리케이션 프로그래밍 인터페이스들(API들) 및 하위 네트워크 인터페이스들의 세트를 통해 부가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 레이어를 정의한다. ETSI M2M 아키텍처와 oneM2M 아키텍처 둘 다는 서비스 레이어를 정의한다. ETSI M2M의 서비스 레이어는 SCL(Service Capability Layer)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 각종의 상이한 노드들에 구현될 수 있다. 예를 들어, 서비스 레이어의 인스턴스는 M2M 디바이스(여기서 이는 DSCL(device SCL)이라고 지칭됨), 게이트웨이(여기서 이는 GSCL(gateway SCL)이라고 지칭됨), 및/또는 네트워크 노드(여기서 이는 NSCL(network SCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 레이어는 CSF들(Common Service Functions)(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정 타입의 CSF들의 세트의 인스턴스화는, 상이한 타입들의 네트워크 노드들(예컨대, 인프라스트럭처 노드, 미들 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는, CSE(Common Services Entity)라고 지칭된다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)에 대한 아키텍처를 정의하였다. 그 아키텍처에서, 서비스 레이어, 및 서비스 레이어가 제공하는 서비스 능력들이 SCS(Service Capability Server)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 SCS(Service Capability Server)에, oneM2M 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 레이어의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함한, 네트워크 내의 하나 이상의 독립형 노드(standalone node) 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능 명령어들 등)로서 또는 하나 이상의 기존의 노드의 일부로서 구현될 수 있다. 일 예로서, 서비스 레이어의 인스턴스 또는 그의 컴포넌트는 이하에서 기술되는 도 49c 또는 도 49d에 예시된 일반적인 아키텍처를 가지는 네트워크 노드(예컨대, 서버, 컴퓨터, 게이트웨이, 디바이스 또는 이와 유사한 것) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.
게다가, 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들이 본 출원의 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(Resource-Oriented Architecture)를 사용하는 M2M 네트워크의 일부로서 구현될 수 있다.
도 49c는, M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버, 또는 이와 유사한 것과 같은, M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록 다이어그램이다. 노드(30)는 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들을 실행하거나 포함할 수 있다. 디바이스(30)는 도 49a 및 도 49b에 도시된 바와 같은 M2M 네트워크의 일부이거나 비-M2M 네트워크의 일부일 수 있다. 도 49c에 도시된 바와 같이, M2M 노드(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), GPS(global positioning system) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 노드(30)는 또한, 트랜시버(34) 및 송신/수신 요소(36)와 같은, 통신 회로부를 포함할 수 있다. M2M 노드(30)가 일 실시예와 부합한 채로 있으면서 전술한 요소들의 임의의 서브컴비네이션(sub-combination)을 포함할 수 있다는 것이 이해될 것이다. 이 노드는 본 명세서에 기술되는 기능성을 구현하는 노드일 수 있다.
프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, DSP(digital signal processor), 복수의 마이크로프로세서들, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로컨트롤러, ASIC들(Application Specific Integrated Circuits), FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입의 IC(integrated circuit), 상태 머신, 및 이와 유사한 것일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 요구된 기능들을 수행하기 위해 노드의 메모리(예컨대, 메모리(44) 및/또는 메모리(46))에 저장된 컴퓨터 실행가능 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 신호 코딩, 데이터 프로세싱, 전력 제어, 입력/출력 프로세싱, 및/또는 M2M 노드(30)가 무선 또는 유선 환경에서 동작할 수 있게 해주는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 애플리케이션 레이어 프로그램들(예컨대, 브라우저들) 및/또는 RAN(radio access-layer) 프로그램들 및/또는 다른 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 또한, 예를 들어, 액세스 레이어 및/또는 애플리케이션 레이어에서와 같이, 인증, 보안 키 일치(security key agreement), 및/또는 암호화 동작들(cryptographic operations)과 같은 보안 동작들을 수행할 수 있다.
도 49c에 도시된 바와 같이, 프로세서(32)는 자신의 통신 회로부(예컨대, 트랜시버(34) 및 송신/수신 요소(36))에 커플링되어 있다. 프로세서(32)는, 컴퓨터 실행가능 명령어들의 실행을 통해, 노드(30)로 하여금 그에 접속되어 있는 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로부를 제어할 수 있다. 상세하게는, 프로세서(32)는 본 명세서에 그리고 청구항들에 기술된 전송 및 수신 단계들을 수행하기 위해 통신 회로부를 제어할 수 있다. 도 49c가 프로세서(32) 및 트랜시버(34)를 별개의 컴포넌트들로서 도시하고 있지만, 프로세서(32) 및 트랜시버(34)가 전자 패키지 또는 칩에 함께 통합되어 있을 수 있다는 것이 이해될 것이다.
송신/수신 요소(36)는 M2M 서버들, 게이트웨이들, 디바이스, 및 이와 유사한 것을 포함한, 다른 M2M 노드들에게 신호들을 전송하거나 그들로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 송신/수신 요소(36)는 RF 신호들을 전송 및/또는 수신하도록 구성된 안테나일 수 있다. 송신/수신 요소(36)는, WLAN, WPAN, 셀룰러, 및 이와 유사한 것과 같은, 다양한 네트워크들 및 에어 인터페이스들(air interfaces)을 지원할 수 있다. 일 실시예에서, 송신/수신 요소(36)는, 예를 들어, IR, UV 또는 가시 광 신호들을 전송 및/또는 수신하도록 구성된 방출기/검출기일 수 있다. 또 다른 실시예에서, 송신/수신 요소(36)는 RF 및 광 신호들 둘 다를 전송 및 수신하도록 구성될 수 있다. 송신/수신 요소(36)가 무선 또는 유선 신호들의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 것이 이해될 것이다.
그에 부가하여, 송신/수신 요소(36)가 도 49c에 단일 요소로서 도시되어 있지만, 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)와 같은, 임의의 타입의 적당한 메모리로부터의 정보에 액세스하고 그에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 세션 컨텍스트(session context)를, 앞서 기술된 바와 같은, 자신의 메모리에 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드, 및 이와 유사한 것을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터와 같은, M2M 노드(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 데이터를 그에 저장할 수 있다. 프로세서(32)는 시스템의 상태를 반영하기 위해 또는 사용자로부터 입력을 획득하기 위해 또는 능력들 또는 설정들에 관한 정보를 사용자에게 디스플레이하기 위해 디스플레이 상의 시각적 표시들을 제어하도록 구성될 수 있다. 디스플레이 상에 보여질 수 있는 그래픽 사용자 인터페이스는 사용자가 본 명세서에 기술된 기능성을 대화식으로 행할 수 있게 해주기 위해 API 상에 레이어링될(layered) 수 있다.
프로세서(32)는 전원(48)으로부터 전력을 받을 수 있고, M2M 노드(30) 내의 다른 컴포넌트들에게 전력을 분배하고 그리고/또는 전력을 제어하도록 구성될 수 있다. 전원(48)은 M2M 노드(30)에 전력을 공급하기 위한 임의의 적당한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 건전지 배터리(예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬 이온(Li 이온) 등), 태양 전지, 연료 전지, 및 이와 유사한 것을 포함할 수 있다.
프로세서(32)는 또한 M2M 노드(30)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성되는 GPS 칩셋(50)에 커플링될 수 있다. M2M 노드(30)가 일 실시예와 부합한 채로 있으면서 임의의 적당한 위치 결정 방법을 통해 위치 정보를 취득할 수 있다는 것이 이해될 것이다.
프로세서(32)는, 부가의 특징들, 기능성 및/또는 유선 또는 무선 연결성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는, 다른 주변기기들(52)에 추가로 커플링될 수 있다. 예를 들어, 주변기기들(52)은 가속도계, 생체측정(예컨대, 지문) 센서들, e-나침반(e-compass)과 같은 다양한 센서들, 위성 트랜시버, (사진 또는 비디오를 위한) 디지털 카메라, USB(universal serial bus) 포트 또는 다른 상호접속 인터페이스들, 진동 디바이스, 텔레비전 트랜시버, 핸즈프리 헤드셋, 블루투스® 모듈, FM(frequency modulated) 라디오 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 및 이와 유사한 것을 포함할 수 있다.
노드(30)는, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 차량과 같은 다른 장치들 또는 디바이스들에 구현될 수 있다. 노드(30)는, 주변기기들(52) 중 하나를 포함할 수 있는 상호접속 인터페이스와 같은, 하나 이상의 상호접속 인터페이스들을 통해 이러한 장치들 또는 디바이스들의 다른 컴포넌트들, 모듈들, 또는 시스템들에 접속할 수 있다. 대안적으로, 노드(30)는, 센서, 소비자 전자제품, 스마트 워치 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차, 또는 비행기와 같은 차량과 같은 다른 장치들 또는 디바이스들을 포함할 수 있다.
도 49d는, M2M 서버, 게이트웨이, 디바이스, 또는 다른 노드와 같은, M2M 네트워크의 하나 이상의 노드를 구현하는 데 또한 사용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록 다이어그램이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능 명령어들 - 소프트웨어의 형태로 되어 있을 수 있고, 이러한 소프트웨어는 어느 곳에든 또는 어떤 수단에 의해서든 저장되거나 액세스됨 - 에 의해 제어될 수 있다. 컴퓨팅 시스템(90)은 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(90)은, 예를 들어, M2M 디바이스, 사용자 장비, 게이트웨이, UE/GW 또는 모바일 코어 네트워크의 노드들을 포함한 임의의 다른 노드들, 서비스 레이어 네트워크 애플리케이션 제공업자, 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)일 수 있다. 이러한 컴퓨터 판독가능 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업을 수행하게 하기 위해, 중앙 처리 유닛(central processing unit, CPU)(91)과 같은, 프로세서 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서라고 불리는 단일 칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서들을 포함할 수 있다. 코프로세서(81)는 메인 CPU(91)와 구별되고, 부가의 기능들을 수행하거나 CPU(91)를 보조하는, 임의적인 프로세서이다. CPU(91) 및/또는 코프로세서(81)는 세션 자격증명들을 수신하는 것 또는 세션 자격증명들에 기초하여 인증하는 것과 같은, E2E M2M 서비스 레이어 세션들에 대한 개시된 시스템들 및 방법들에 관련된 데이터를 수신, 생성, 및 프로세싱할 수 있다.
동작 중에, CPU(91)는 명령어들을 페치, 디코딩, 및 실행하고, 정보를 컴퓨터의 메인 데이터 전송 경로인 시스템 버스(80)를 통해 다른 자원들에게 그리고 그들로부터 전송한다. 그러한 시스템 버스는 컴퓨팅 시스템(90) 내의 컴포넌트들을 접속시키고, 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 전형적으로 데이터를 송신하기 위한 데이터 라인들, 어드레스들을 송신하기 위한 어드레스 라인들, 및 인터럽트들을 송신하고 시스템 버스를 작동시키기 위한 제어 라인들을 포함한다. 그러한 시스템 버스(80)의 일 예는 PCI(Peripheral Component Interconnect) 버스이다.
시스템 버스(80)에 커플링된 메모리들은 RAM(random access memory)(82) 및 ROM(and read only memory)(93)을 포함한다. 그러한 메모리들은 정보가 저장 및 검색될 수 있게 해주는 회로부를 포함한다. ROM들(93)은 일반적으로 용이하게 수정될 수 없는 저장된 데이터를 포함한다. RAM(82)에 저장된 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에의 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는, 명령어들이 실행될 때, 가상 어드레스들을 물리 어드레스들로 변환하는 어드레스 변환 기능(address translation function)을 제공할 수 있다. 메모리 제어기(92)는 또한 시스템 내에서 프로세스들을 격리시키고 시스템 프로세스들을 사용자 프로세스들로부터 격리시키는 메모리 보호 기능을 제공할 수 있다. 따라서, 제1 모드에서 실행 중인 프로그램은 그 자신의 프로세스 가상 어드레스 공간에 의해 매핑되는 메모리에만 액세스할 수 있고; 프로세스들 간의 메모리 공유가 셋업되어 있지 않은 한, 다른 프로세스의 가상 어드레스 공간 내의 메모리에는 액세스할 수 없다.
그에 부가하여, 컴퓨팅 시스템(90)은 명령어들을 CPU(91)로부터, 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은, 주변기기들에게 전달하는 일을 책임지고 있는 주변기기들 제어기(83)를 포함할 수 있다.
디스플레이 제어기(96)에 의해 제어되는, 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성된 시각적 출력을 디스플레이하는 데 사용된다. 그러한 시각적 출력은 텍스트, 그래픽스, 애니메이티드 그래픽스(animated graphics), 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평판 디스플레이, 가스 플라즈마 기반 평판 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에게 송신되는 비디오 신호를 생성하는 데 필요한 전자 컴포넌트들을 포함한다.
게다가, 컴퓨팅 시스템(90)은 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하기 위해 컴퓨팅 시스템(90)을, 도 49a 및 도 49b의 네트워크(12)와 같은, 외부 통신 네트워크에 접속시키는 데 사용될 수 있는, 예를 들어, 네트워크 어댑터(97)와 같은, 통신 회로부를 포함할 수 있다.
사용자 장비(UE)는 통신하기 위해 최종 사용자에 의해 사용되는 임의의 디바이스일 수 있다. 사용자 장비(UE)는 핸드헬드 전화기, 모바일 브로드밴드 어댑터를 갖춘 랩톱 컴퓨터, 또는 임의의 다른 디바이스일 수 있다. 예를 들어, UE는 도 49a 및 도 49b의 M2M 단말 디바이스(18) 또는 도 49c의 디바이스(30)로서 구현될 수 있다.
본 명세서에 기술되는 시스템들, 방법들 및 프로세스들 중 일부 또는 전부가 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 실행가능 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있고, 이 명령어들이, 예를 들어, M2M 서버, 게이트웨이, 디바이스 등을 포함한 M2M 네트워크의 노드와 같은 머신에 의해 실행될 때, 본 명세서에 기술되는 시스템들, 방법들 및 프로세스들을 수행 및/또는 구현한다는 것이 이해된다. 구체적으로는, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크의 노드들, 서비스 레이어 또는 네트워크 애플리케이션 제공자 중 임의의 것의 동작들을 비롯한, 앞서 기술된 단계들, 동작들 또는 기능들 중 임의의 것이 그러한 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 서비스 레이어(1602), 데이터 소스(2218), DSAS(2202), DSAS-SF(2212), DSAS-SAE(2210), DSAS 관리자(2206), DSAS API(2208), 데이터 저장 노드(2214), 보안 관리자(2302), 관리자/파서(2304), 프리프로세서(2306), 저장 필터(2308), 애널리틱스 필터(2310), 쿼리 스토어(2318), 잡 테이블(2320), 로그 스토어(2323), 스트림 ID 스토어(2321), SAE 소스(2314), 쿼리 연산자들(2312), 클라이언트(2216 및 3202), 코디네이터(3402), DSAS CSF(3702), DSAS 호스팅 CSE(3704), 데이터 소스 AE(4402), DSAS 클라이언트 AE(4502 및 4602), CSE(4504) 그리고 도 47 및 도 48의 인터페이스들과 같은 인터페이스들을 생성하기 위한 논리 엔티티들과 같은 논리 엔티티들은 컴퓨터 판독가능 저장 매체 상에 저장된 컴퓨터 실행가능 명령어들의 형태로 구체화될 수 있다. 컴퓨터 판독가능 저장 매체는 정보의 저장을 위해 임의의 비일시적(즉, 유형적 또는 물리적) 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 둘 다를 포함하지만, 그러한 컴퓨터 판독가능 저장 매체가 신호들은 포함하지 않는다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 다른 광학 디스크 스토리지, 자기 카세트들, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 저장 디바이스들, 또는 원하는 정보를 저장하는 데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 유형적 또는 물리 매체를 포함하지만, 이들로 제한되지 않는다.
본 개시내용의 주제의 바람직한 실시예들을 기술함에 있어서, 도면들에 예시된 바와 같이, 명확함을 위해 특정 용어가 이용된다. 그렇지만, 청구된 주제는 그렇게 선택된 특정 용어로 제한되는 것으로 의도되어 있지 않으며, 각각의 특정 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물들을 포함한다는 것이 이해될 것이다.
이러한 서면 설명은 최상의 모드(best mode)를 포함한 본 발명을 개시하기 위해 그리고 또한 본 기술분야의 통상의 기술자가, 임의의 디바이스들 또는 시스템들을 제조 및 사용하는 것 그리고 임의의 포함된 방법들을 수행하는 것을 포함한, 본 발명을 실시할 수 있게 해주기 위해 예들을 사용한다. 본 발명의 특허가능 범주는 청구항들에 의해 한정되고, 본 기술분야의 통상의 기술자에게 안출되는 다른 예들을 포함할 수 있다. 그러한 다른 예들은, 청구항들의 문언적 표현(literal language)과 상이하지 않은 요소들을 가지는 경우, 또는 청구항들의 문언적 표현과 비실질적인 차이(insubstantial difference)를 갖는 등가의 요소들을 포함하는 경우, 청구항들의 범주 내에 속하는 것으로 의도된다.

Claims (28)

  1. 프로세서와 메모리를 포함하는 장치로서, 상기 장치는, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금
    데이터 스트림을 수신하게 하고;
    상기 데이터 스트림을 분석 및 필터링하게 하며;
    상기 필터링된 데이터 스트림을 추가 분석을 위해 노드에 제공하게 하는
    상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능 명령어들을 추가로 포함하는, 장치.
  2. 제1항에 있어서, 상기 장치는 스트림 포워더(Stream Forwarder)(SF)인, 장치.
  3. 제1항에 있어서, 상기 노드는 스트림 애널리틱스 엔진(Stream Analytics Engine)(SAE)인, 장치.
  4. 제3항에 있어서, 상기 스트림 애널리틱스 엔진은 상기 장치와 별개의 위치에 있는, 장치.
  5. 제1항에 있어서, 상기 데이터 스트림은 하나 이상의 활성 쿼리에 따라 필터링되는, 장치.
  6. 제4항에 있어서, 상기 하나 이상의 활성 쿼리는 클라이언트로부터 획득되는, 장치.
  7. 제1항에 있어서, 상기 장치는 서비스 레이어 컴포넌트를 포함하는, 장치.
  8. 제1항에 있어서, 상기 데이터 스트림은 하나 이상의 IoT(Internet of Things) 디바이스로부터 오는, 장치.
  9. 제1항에 있어서, 상기 데이터 스트림은 필터링 이전에 파싱되는, 장치.
  10. 제9항에 있어서, 상기 파싱된 데이터 스트림은 필터링 이전에 프리프로세싱되는, 장치.
  11. 프로세서와 메모리를 포함하는 장치로서, 상기 장치는, 상기 장치의 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금
    필터링된 데이터 스트림을 노드로부터 수신하게 하고;
    상기 필터링된 데이터 스트림을 적어도 하나의 쿼리를 사용하여 분석하게 하는
    상기 장치의 상기 메모리에 저장된 컴퓨터 실행가능 명령어들을 추가로 포함하는, 장치.
  12. 제11항에 있어서, 상기 장치는 스트림 애널리틱스 엔진(SAE)인, 장치.
  13. 제11항에 있어서, 상기 노드는 스트림 포워더(SF)인, 장치.
  14. 제11항에 있어서, 상기 장치는 상기 노드와 상이한 위치에 있는, 장치.
  15. 제14항에 있어서, 적어도 하나의 쿼리가 적어도 하나의 클라이언트로부터 수신되는, 장치.
  16. 제15항에 있어서, 상기 필터링된 데이터 스트림은 상기 클라이언트에 의해 수신된 상기 쿼리에 기초한 쿼리 연산자(Query Operator)를 사용하여 분석되는, 장치.
  17. 제14항에 있어서, 상기 적어도 하나의 쿼리에 대한 응답은 클라이언트에게 송신되는, 장치.
  18. 제11항에 있어서, 상기 장치는 서비스 레이어 컴포넌트를 포함하는, 장치.
  19. 제11항에 있어서, 상기 장치는 쿼리 스토어(Query Store)와 상호작용하는 적어도 하나의 쿼리 연산자를 포함하는, 장치.
  20. 제14항에 있어서, 상기 적어도 하나의 쿼리를 프로세싱하기 위한 알고리즘은 상기 클라이언트에 의해 배포되는, 장치.
  21. 장치에 의해 사용하기 위한 방법으로서, 상기 장치는 프로세서와 메모리를 포함하고, 상기 장치는, 상기 프로세서에 의해 실행될 때, 방법의 기능들을 수행하는 상기 메모리에 저장된 컴퓨터 실행가능 명령어들을 추가로 포함하며, 상기 방법은:
    데이터 스트림을 수신하는 단계;
    상기 데이터 스트림을 분석 및 필터링하는 단계; 및
    상기 필터링된 데이터 스트림을 추가 분석을 위해 노드에 제공하는 단계
    를 포함하는, 방법.
  22. 제21항에 있어서, 상기 장치는 스트림 포워더인, 방법.
  23. 제21항에 있어서, 상기 장치는 IoT 디바이스들로부터 데이터 스트림을 수신하는, 방법.
  24. 제21항에 있어서, 상기 노드는 스트림 포워더 또는 스트림 애널리틱스 엔진인, 방법.
  25. 장치에 의해 사용하기 위한 방법으로서, 상기 장치는 프로세서와 메모리를 포함하고, 상기 장치는, 상기 프로세서에 의해 실행될 때, 방법의 기능들을 수행하는 상기 메모리에 저장된 컴퓨터 실행가능 명령어들을 추가로 포함하며, 상기 방법은:
    필터링된 데이터 스트림을 노드로부터 수신하는 단계; 및
    상기 필터링된 데이터 스트림을 적어도 하나의 쿼리를 사용하여 분석하는 단계
    를 포함하는, 방법.
  26. 제25항에 있어서, 상기 노드는 스트림 포워더인, 방법.
  27. 제25항에 있어서, 상기 장치는 스트림 애널리틱스인, 방법.
  28. 제25항에 있어서, 상기 장치는 분산 데이터 스트림 애널리틱스를 위한 하나 이상의 부가 장치에 접속되는, 방법.
KR1020187033823A 2016-04-25 2017-04-25 서비스 레이어에서의 데이터 스트림 애널리틱스 KR102372219B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662326894P 2016-04-25 2016-04-25
US62/326,894 2016-04-25
PCT/US2017/029341 WO2017189533A1 (en) 2016-04-25 2017-04-25 Data stream analytics at service layer

Publications (2)

Publication Number Publication Date
KR20180136521A true KR20180136521A (ko) 2018-12-24
KR102372219B1 KR102372219B1 (ko) 2022-03-08

Family

ID=58692590

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187033823A KR102372219B1 (ko) 2016-04-25 2017-04-25 서비스 레이어에서의 데이터 스트림 애널리틱스

Country Status (3)

Country Link
US (3) US10956423B2 (ko)
KR (1) KR102372219B1 (ko)
WO (1) WO2017189533A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102001253B1 (ko) * 2019-03-14 2019-10-02 (주)미래로택 Ibm 클라우드 기반 스마트 홈 터치 스위치 시스템 및 그 동작 방법

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018170444A1 (en) 2017-03-17 2018-09-20 The Regents Of The University Of Michigan Method and apparatus for constructing informative outcomes to guide multi-policy decision making
US20180316555A1 (en) * 2017-04-29 2018-11-01 Cisco Technology, Inc. Cognitive profiling and sharing of sensor data across iot networks
US11025693B2 (en) 2017-08-28 2021-06-01 Banjo, Inc. Event detection from signal data removing private information
US10313413B2 (en) 2017-08-28 2019-06-04 Banjo, Inc. Detecting events from ingested communication signals
US10581945B2 (en) 2017-08-28 2020-03-03 Banjo, Inc. Detecting an event from signal data
US10755115B2 (en) * 2017-12-29 2020-08-25 Here Global B.V. Method, apparatus, and system for generating synthetic image data for machine learning
US10261846B1 (en) 2018-02-09 2019-04-16 Banjo, Inc. Storing and verifying the integrity of event related data
US10585724B2 (en) 2018-04-13 2020-03-10 Banjo, Inc. Notifying entities of relevant events
US10956246B1 (en) * 2018-07-16 2021-03-23 Amazon Technologies, Inc. Isolated read channel management interfaces at streaming data service
US11893036B2 (en) * 2018-07-19 2024-02-06 Ab Initio Technology Llc Publishing to a data warehouse
EP3824404A4 (en) 2018-07-20 2022-04-27 May Mobility, Inc. MULTI-PERSPECTIVE SYSTEM AND BEHAVIORAL POLICY SELECTION PROCESS BY AN AUTONOMOUS AGENT
US10614709B2 (en) 2018-07-24 2020-04-07 May Mobility, Inc. Systems and methods for implementing multimodal safety operations with an autonomous agent
US10965728B2 (en) * 2018-10-22 2021-03-30 Tesla, Inc. Method and system for aggregating and converting sensor data streams
US10969470B2 (en) 2019-02-15 2021-04-06 May Mobility, Inc. Systems and methods for intelligently calibrating infrastructure devices using onboard sensors of an autonomous agent
US11816089B2 (en) * 2019-07-30 2023-11-14 Sap Se Supporting reportability of Internet of Things (IoT) data in the cloud for enterprise contexts
US10826801B1 (en) * 2019-07-31 2020-11-03 Bank Of America Corporation Multi-level data channel and inspection architectures
US11115310B2 (en) 2019-08-06 2021-09-07 Bank Of America Corporation Multi-level data channel and inspection architectures having data pipes in parallel connections
US11470046B2 (en) 2019-08-26 2022-10-11 Bank Of America Corporation Multi-level data channel and inspection architecture including security-level-based filters for diverting network traffic
US10971005B1 (en) * 2019-12-26 2021-04-06 Continental Automotive Systems, Inc. Determining I2X traffic-participant criticality
CN111597058B (zh) * 2020-04-17 2023-10-17 微梦创科网络科技（中国）有限公司 一种数据流处理方法及系统
CN111475317B (zh) * 2020-04-17 2023-09-15 上海中通吉网络技术有限公司 Spark批次时间修改方法、装置、设备和存储介质
WO2022006418A1 (en) 2020-07-01 2022-01-06 May Mobility, Inc. Method and system for dynamically curating autonomous vehicle policies
CN112019869B (zh) * 2020-08-21 2022-04-22 广州欢网科技有限责任公司 一种直播数据处理方法和装置
SE545771C2 (en) 2020-08-28 2024-01-09 Stream Analyze Sweden Ab Method and system for data processing
EP4260009A1 (en) 2020-12-14 2023-10-18 May Mobility, Inc. Autonomous vehicle safety platform system and method
EP4264181A1 (en) 2020-12-17 2023-10-25 May Mobility, Inc. Method and system for dynamically updating an environmental representation of an autonomous agent
WO2022212944A1 (en) 2021-04-02 2022-10-06 May Mobility, Inc. Method and system for operating an autonomous agent with incomplete environmental information
WO2022256249A1 (en) 2021-06-02 2022-12-08 May Mobility, Inc. Method and system for remote assistance of an autonomous agent
US11544079B1 (en) * 2021-07-30 2023-01-03 Qualtrics, Llc Domain events for a multi-platform data stream
CN113779131A (zh) * 2021-09-14 2021-12-10 树根互联股份有限公司 一种数据流联动的方法、装置、终端及存储介质
WO2023102098A1 (en) 2021-12-01 2023-06-08 May Mobility, Inc. Method and system for impact-based operation of an autonomous agent
WO2023141506A1 (en) * 2022-01-19 2023-07-27 Commscope Technologies Llc System and method of cloud based congestion control for virtualized base station
WO2023154568A1 (en) 2022-02-14 2023-08-17 May Mobility, Inc. Method and system for conditional operation of an autonomous agent
US20240161621A1 (en) * 2022-11-11 2024-05-16 GridMatrix, Inc. Systems that predict accidents and ameliorate predicted accidents

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140304006A1 (en) * 2006-09-26 2014-10-09 Ralph A. Korpman Individual health record system and apparatus

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6237031B1 (en) * 1997-03-25 2001-05-22 Intel Corporation System for dynamically controlling a network proxy
US7246318B2 (en) * 2002-06-28 2007-07-17 Microsoft Corporation Application programming interface for utilizing multimedia data
FR2847404B1 (fr) * 2002-11-15 2005-03-11 Thales Sa Procede d'analyse recursive et statistique de communications reseaux
US6865517B2 (en) * 2002-12-11 2005-03-08 International Business Machines Corporation Aggregation of sensory data for distributed decision-making
US7388871B2 (en) * 2004-02-05 2008-06-17 Broadcom Corporation Method and system for changing message filter coefficients dynamically
US7703040B2 (en) * 2005-06-29 2010-04-20 Microsoft Corporation Local search engine user interface
US8023409B2 (en) * 2005-12-20 2011-09-20 Broadcom Corporation Method and system for reconfigurable pattern filtering engine
US7698962B2 (en) * 2006-04-28 2010-04-20 Amsted Rail Company, Inc. Flexible sensor interface for a railcar truck
US20110231360A1 (en) * 2010-03-19 2011-09-22 Carrier Iq, Inc. Persistent flow method to define transformation of metrics packages into a data store suitable for analysis by visualization
US8301645B1 (en) 2010-08-26 2012-10-30 Adobe Systems Incorporated Aggregated web analytics request systems and methods
US9495713B2 (en) * 2010-12-10 2016-11-15 Quib, Inc. Comment delivery and filtering architecture
CN102740361B (zh) * 2011-04-13 2016-01-13 华为技术有限公司 无线网络汇聚传输方法、系统及设备
US9529752B2 (en) * 2011-07-25 2016-12-27 Ford Global Technologies, Llc Method and apparatus for communication between a vehicle based computing system and a remote application
US8800056B2 (en) * 2011-08-12 2014-08-05 Palo Alto Research Center Incorporated Guided implicit authentication
WO2013098543A1 (en) * 2011-12-29 2013-07-04 British Telecommunications Public Limited Company Distributed system management
EP2674876A1 (en) * 2012-06-14 2013-12-18 Alcatel Lucent Streaming analytics processing node and network topology aware streaming analytics system
EP2936341B1 (en) * 2012-12-18 2016-09-14 Telefonaktiebolaget LM Ericsson (publ) Load shedding in a data stream management system
SG2013096748A (en) * 2013-01-08 2014-08-28 Reliance Ind Ltd System and method for preparing hydrocarbon blend from multiple component streams
US20140280338A1 (en) 2013-03-14 2014-09-18 Cisco Technology, Inc. Distributed network analytics
US9749430B2 (en) * 2013-05-06 2017-08-29 Microsoft Technology Licensing, Llc Scalable data enrichment for cloud streaming analytics
US9438648B2 (en) 2013-05-09 2016-09-06 Rockwell Automation Technologies, Inc. Industrial data analytics in a cloud platform
EP3005660B1 (en) * 2013-05-28 2019-10-23 Convida Wireless, LLC Data aggregation
WO2014209363A1 (en) * 2013-06-28 2014-12-31 Rider Tomer Live crowdsourced media streaming
US9806902B2 (en) * 2014-03-20 2017-10-31 Verizon Patent And Licensing Inc. Scalable framework for monitoring machine-to-machine (M2M) devices
US9774451B2 (en) * 2015-02-10 2017-09-26 Qualcomm Incorporated Using secure elements to authenticate devices in point-to-point communication
US9916229B2 (en) * 2015-10-14 2018-03-13 International Business Machines Corporation Decomposing application topology data into transaction tracking data
US9858213B2 (en) * 2015-12-14 2018-01-02 Afero, Inc. Interface and method for efficient communication between a microcontroller and a communication module
US9792259B2 (en) * 2015-12-17 2017-10-17 Software Ag Systems and/or methods for interactive exploration of dependencies in streaming data
US10853359B1 (en) * 2015-12-21 2020-12-01 Amazon Technologies, Inc. Data log stream processing using probabilistic data structures
US10348739B2 (en) * 2016-02-09 2019-07-09 Ca, Inc. Automated data risk assessment

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140304006A1 (en) * 2006-09-26 2014-10-09 Ralph A. Korpman Individual health record system and apparatus

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102001253B1 (ko) * 2019-03-14 2019-10-02 (주)미래로택 Ibm 클라우드 기반 스마트 홈 터치 스위치 시스템 및 그 동작 방법

Also Published As

Publication number Publication date
WO2017189533A1 (en) 2017-11-02
US10956423B2 (en) 2021-03-23
KR102372219B1 (ko) 2022-03-08
US20190138524A1 (en) 2019-05-09
US11727012B2 (en) 2023-08-15
US20230334051A1 (en) 2023-10-19
US20210240719A1 (en) 2021-08-05

Similar Documents

Publication Publication Date Title
US11727012B2 (en) Data stream analytics at service layer
Bansal et al. A survey on iot big data: current status, 13 v’s challenges, and future directions
US20230319534A1 (en) Cross-resource subscription for m2m service layer
US10680958B2 (en) Policy enforcement as a service for third party platforms
US10560349B2 (en) Data consistency of policy enforcement for distributed applications
US11991198B1 (en) User-specific data-driven network security
US11714830B2 (en) Mechanisms for multi-dimension data operations
US10778543B2 (en) Opaque interface for enclosed/wrapped asynchronous pushing and/or pulling data between policy enforcement as a service (PEaaS) components
US10771353B2 (en) Policy enforcement as a service for third party platforms with asynchronous user tracking mechanisms
CN109313587B (zh) 用于在服务层处使能数据分析服务的方法
US20230254330A1 (en) Distinguishing user-initiated activity from application-initiated activity
US20240089343A1 (en) Service layer-based methods to enable efficient analytics of iot data
Prabhu Overview-fog computing and internet-of-things (IOT)
Almeida et al. A distributed event-driven architectural model based on situational awareness applied on internet of things
US11985195B2 (en) Methods to enable data continuity service
US20210026904A1 (en) Mechanisms for service layer resource ranking and enhanced resource discovery
US20210336862A1 (en) Data sample template (dst) management for enabling fog-based data processing
US20240106846A1 (en) Approval Workflows For Anomalous User Behavior
WO2023034444A1 (en) Generating user-specific polygraphs for network activity
US20220101962A1 (en) Enabling distributed semantic mashup
US20230120915A1 (en) Security intelligence platform architecture and functionality
Huang et al. A distributed proactive service framework for crowd-sensing process
Ghaly et al. Scalable Incident Reporting Framework: A Sensor and IoT Research
WO2024010747A1 (en) Approval workflows for anomalous user behavior
CN115225637A (zh) 云数据的显示方法和装置、存储介质及电子设备

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant