KR20210049812A

KR20210049812A - 포그 기반 데이터 처리를 가능하게 하기 위한 데이터 샘플 템플릿(dst) 관리

Info

Publication number: KR20210049812A
Application number: KR1020217005636A
Authority: KR
Inventors: 쉬 리; 충강 왕; 취앙 리; 루 류
Original assignee: 콘비다 와이어리스, 엘엘씨
Priority date: 2018-08-27
Filing date: 2019-08-21
Publication date: 2021-05-06
Also published as: JP7458377B2; JP2021536606A; CN112236979A; US20210336862A1; CN112236979B; EP3804232A1; WO2020046667A1

Abstract

데이터 샘플 수집 서비스(DSCS)는 사용자들로부터 다양한 데이터 샘플 수집 요청들을 수신하고 사용자들을 대신하여 하나 이상의 요청을 처리하도록 구성될 수 있다. 사용자가 어떤 종류의 RDS(Ready-to-Use Data Sample)를 필요로 하는지를 적절하게 설명하기 위해, DSCS는 데이터 샘플 템플릿(DST)을 채택할 수 있다. DST를 이용함으로써, 사용자는 데이터 샘플들에 관한 다양한 품질 요건들과 함께, 그 원하는 데이터 샘플들이 어떤 모양인지를 명확하게 묘사할 수 있다. DSCS는 사용자들에게 DST 관리 기능을 추가로 제공할 수 있다. 일반적으로, DST 관리는 DST 생성, DST 업데이트, DST 삭제 및 DST 활성화/비활성화의 프로세스들을 포함한다. 예를 들어, 사용자는 그 데이터 샘플 수집 요구에 기반하여 DST를 생성할 수 있다. 나중에, 생성된 DST는 또한 사용자의 요구에 대한 동적 변경들에 기반하여 업데이트 및/또는 삭제될 수 있다.

Description

포그 기반 데이터 처리를 가능하게 하기 위한 데이터 샘플 템플릿(DST) 관리

최근에, 세계의 데이터량이 다양한 분야들에서 폭발적으로 증가하고 있다. 예를 들어, 웹 검색 엔진은 수백 페타바이트(PB)의 검색 데이터를 처리할 수 있고, 소셜 네트워크 애플리케이션은 한 달에 10 PB를 넘는 로그 데이터를 생성할 수 있다. 폭발적인 글로벌 데이터의 결과로, "빅 데이터"라는 용어가 대규모 데이터세트들을 설명하기 위해 만들어졌다. 전통적인 데이터세트들과 비교하여, 빅 데이터는 전형적으로 대량의 비구조화된 데이터를 포함하며, 이 데이터는 이 데이터로부터 심층적인 통찰력을 얻기 위해, 예를 들어 고객들의 쇼핑 이력 기록들로부터 잠재적인 구매들을 발견하기 위한 방법을 얻기 위해 분석되어야 한다.

DSCS(Data Sample Collection Service)를 구현하기 위한 방법들 및 시스템들이 개시된다. DSCS는 사용자들로부터 다양한 데이터 샘플 수집 요청들을 수신하고 사용자들을 대신하여 하나 이상의 요청을 처리하도록 구성될 수 있다. 사용자에게 어떤 종류의 RDS(Ready-to-Use Data Sample)가 필요한지를 적절하게 설명하기 위해, DSCS는 데이터 샘플 템플릿(DST)을 채택할 수 있다. DST를 이용함으로써, 사용자는 데이터 샘플들에 관한 다양한 품질 요건들과 함께, 그 원하는 데이터 샘플들이 어떤 모양인지를 명확하게 묘사할 수 있다.

DSCS는 사용자들에게 DST 관리 기능을 추가로 제공할 수 있다. 일반적으로, DST 관리는 DST 생성, DST 업데이트, DST 삭제 및 DST 활성화/비활성화의 프로세스들을 포함한다. 예를 들어, 사용자는 그 데이터 샘플 수집 요구에 기반하여 DST를 생성할 수 있다. 나중에, 생성된 DST는 또한 사용자의 요구에 대한 동적 변경들에 기반하여 업데이트 및/또는 삭제될 수 있다. DST에 대해 이루어진 변경들은 또한 대응하는 DST의 대응하는 데이터 샘플들에 대한 변경들을 낳을 수 있다.

협력적 데이터 소스(DS) 식별 및 포그(fog) 기반 서비스 계층(SL)에 대한 RDS 생성을 위한 방법들 및 시스템들이 추가로 개시된다. 협력적 DS 식별 절차 동안, 데이터 샘플 수집 요청(DSCR)에 대응하는 RDS 내의 데이터 요소들(DE들) 각각에 대해, 이들이 이 DSCR을 서빙하기 위한 원하는 DS들인지를 결정하기 위해 발견 및/또는 평가될 필요가 있는 로컬 포그 영역(LFA)에서 수천 개의 잠재적인 DS들이 존재할 수 있다. 데이터 소스 발견들(DSD들)로서 동작할 수 있는 LFA 내의 상이한 LFN들(Local Fog Nodes)은 상이한 DS 식별 및 발견 능력들을 가질 수 있다. 따라서, 주어진 DSCR에 대한 원하는 DS들을 식별하기 위해 하나 이상의 LFA에서 (DSD들로서) 복수의 LFN들이 협력적으로 함께 작업하는 것을 허용하는 방법들 및 시스템들이 제공된다.

주어진 LFN은 DS 식별 능력들을 가질 수 있지만, 원하는/식별된 DS로부터 데이터를 수집하기 위한 것과 같은 데이터 수집 능력, 또는 RDS들을 생성하기 위해 원시 데이터를 처리하기 위한 것과 같은 특정 데이터 처리 능력을 갖지 않을 수 있다. 따라서, 본 명세서에 개시된 DS 식별 프로세스는 주어진 DSCR에 의해 요구되는 바와 같이 RDS들 내의 각각의 DE에 대한 원하는 DS들을 식별하는 것을 지칭할 뿐만 아니라, 그 식별된 DS들로부터 원시 데이터를 수집하기 위한 원시 데이터 수집기(RDC)들로서 동작할 수 있는 적절한 LFN들을 찾는 것뿐만 아니라 RDS들을 생성하기 위해 원시 데이터를 처리하기 위한 원시 데이터 프로세서들(RDP들)로서 동작할 수 있는 적절한 LFN들을 찾는 것을 지칭한다. 본 명세서에 개시된 협력적 DS 식별을 위한 방법들 및 시스템들은 RDC 발견, DS 식별 결과 통합 및 RDC/RDP 작업 할당을 갖는 DS 식별을 포함하지만 이에 제한되지 않는다.

RDS 생성 절차 동안, DS들로부터 수집된 원시 데이터는 많은 양일 수 있고, 대규모 원시 데이터에 대한 데이터 처리는 또한 협력적으로 수행될 필요가 있을 수 있다. 주어진 DSCR에 대해, 그 데이터 처리는 복수의 RDP들에 걸칠 수 있는데, 그 이유는 상이한 LFN들이 이 DSCR에 대한 RDS들을 생성하기 위해 요구되는 다양한 데이터 처리 능력들을 가질 수 있기 때문이다. 본 명세서에 개시된 협력적 RDS 생성에 대한 주요 해결책들은 주어진 DSCR에 대한 RDS 생성, 주어진 DE에 대한 RDS 생성, 및 주어진 DSCR에 대한 RDS 조립을 트리거링하는 것을 포함하지만 이에 제한되지는 않는다.

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

본 출원의 보다 탄탄한 이해를 용이하게 하기 위해, 유사 요소들이 유사 번호들로 참조된 첨부 도면들이 이제 참조된다. 이들 도면들은 본 출원을 제한하는 것으로 해석되어서는 안되며 단지 예시일 뿐이다.
도 1은 예시적인 포그 컴퓨팅 시스템 아키텍처의 블록도를 도시한다.
도 2는 예시적인 oneM2M 아키텍처의 블록도를 도시한다.
도 3은 예시적인 oneM2M 공통 서비스 기능들(CSF들)의 블록도를 도시한다.
도 4는 예시적인 스마트 도시 분석 이용 사례의 흐름도를 도시한다.
도 5는 데이터 샘플 템플릿(DST)을 이용하는 DSCS(data sample collection service)에 대한 예시적인 상위 레벨 아키텍처의 흐름도를 도시한다.
도 6은 LFA들에서의 리액티브 DS 식별에 의한 DST 생성에 대한 예시적인 절차의 흐름도를 도시한다.
도 7은 LFA들에서의 프로액티브 DS 식별에 의한 DST 생성에 대한 예시적인 절차의 흐름도를 도시한다.
도 8은 재이용을 통한 DST 생성에 대한 예시적인 절차의 흐름도를 도시한다.
도 9는 R-DST 분할을 이용한 DST 생성에 대한 예시적인 절차의 흐름도를 도시한다.
도 10은 RDS 생성에 대한 제1 예시적인 구성을 도시한다.
도 11은 RDS 생성에 대한 제2 예시적인 구성을 도시한다.
도 12는 기존의 DST에 하나 이상의 새로운 데이터 요소(DE)를 추가하기 위한 DST 업데이트에 대한 예시적인 절차의 흐름도를 도시한다.
도 13은 DST 업데이트 또는 하나 이상의 DST를 삭제하거나 전체 DST를 삭제하기 위한 예시적인 절차의 흐름도를 도시한다.
도 14는 DST 상태의 예시적인 상태 머신 모델의 블록도를 도시한다.
도 15는 oneM2M 서비스 계층에 대한 예시적인 새로운 DSCS CSF의 블록도를 도시한다.
도 16은 새로운 oneM2M 리소스 <dscs>의 예를 도시한다.
도 17은 예시적인 사용자 인터페이스를 도시한다.
도 18은 예시적인 데이터 샘플 수집 서비스의 아키텍처 도면을 도시한다.
도 19는 로컬 포그 노드 리더에 대한 로컬 포그 노드 능력 등록을 위한 예시적인 방법의 흐름도를 도시한다.
도 20은 원시 데이터 수집기 발견에 의한 데이터 샘플 식별을 위한 예시적인 방법의 흐름도를 도시한다.
도 21은 데이터 소스 식별 결과 통합을 위한 예시적인 방법의 흐름도를 도시한다.
도 22는 로컬 포그 영역들에서 RDS 생성 절차를 개시하기 위한 예시적인 방법의 흐름도를 도시한다.
도 23은 주어진 데이터 요소에 대한 RDS 생성을 위한 예시적인 방법의 흐름도를 도시한다.
도 24는 주어진 데이터 샘플 수집 요청에 대한 RDS 생성을 위한 예시적인 방법의 흐름도를 도시한다.
도 25는 예시적인 사용자 인터페이스를 도시한다.
도 26a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 기기간(M2M) 또는 사물 인터넷(IoT) 통신 시스템의 예시적인 시스템도를 도시한다.
도 26b는 도 26a에 도시된 M2M/IoT 통신 시스템 내에서 이용될 수 있는 예시적인 아키텍처의 예시적인 시스템도를 도시한다.
도 26c는 도 26a에 도시된 통신 시스템 내에서 이용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 예시적인 시스템도를 도시한다.
도 26d는 도 26a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 예시적인 블록도를 도시한다.

전통적인 데이터세트들과 비교하여, 빅 데이터는 전형적으로 대량의 비구조화된 데이터를 포함하며, 이 데이터는 이 데이터로부터 심층적인 통찰력을 얻기 위해, 예를 들어 고객들의 쇼핑 이력 기록들로부터 잠재적인 구매들을 발견하기 위한 방법을 얻기 위해 분석되어야 한다. 일반적으로, 여러 "Vs"를 지칭하는 빅 데이터의 인기 있는 정의가 있다:

볼륨: 대량의 데이터의 생성 및 수집에 의해, 데이터 스케일링이 점점 더 커지게 된다(예를 들어, 인터넷 회사들에 의해 생성된 데이터는 하루에 수십 PB에 쉽게 도달할 수 있다).

다양성: 이는 오디오, 비디오, 웹페이지 및 텍스트와 같은 반구조화된 데이터와 비구조화된 데이터는 물론 데이터베이스 표들과 같은 전통적인 잘 정의된 구조화된 데이터를 포함하는 다양한 유형들의 데이터를 나타낸다.

속도: 빅 데이터(예를 들어, 데이터 수집 및 분석)의 적시성은 빅 데이터의 상업적 가치를 최대화할 수 있도록 시기적절한 방식으로 처리되어야 한다.

가치: 데이터에 숨겨진 유용한 지식 및 통찰력이 있지만, 이들은 밀도가 매우 낮을 수 있다.

물리적 세계에 내장되고 네트워크들에 의해 컴퓨팅 리소스들에 접속된 예를 들어 센서들 및 디바이스들을 전형적으로 지칭하는 기기간(M2M) 및 사물 인터넷(IoT) 통신들의 출현은 빅 데이터에서의 성장을 이끄는 주요 경향인 점에 주목할 가치가 있다. 예를 들어, 세계에 배치된 접속된 IoT 노드들의 수는 연간 30 퍼센트를 초과하는 속도로 성장할 것으로 예상된다. 이러한 대규모 IoT 노드들은 대량의 데이터를 생성할 것으로 예상되며, 이는 IoT 데이터 처리를 위한 비용 효율적인 해결책을 요구한다.

에지 컴퓨팅은 IoT 디바이스들에 의해 생성된 데이터가 이를 데이터 센터들 또는 클라우드들에 대한 긴 경로들에 걸쳐 전송하는 대신에 데이터가 생성되는 곳에 더 가까이 처리되도록 허용한다.

에지 컴퓨팅 배치들은 다양한 상황들에서 이상적일 수 있다. 하나의 예시적인 시나리오는 IoT 디바이스들이 열악한 접속성을 갖는 경우이고, IoT 디바이스들이 중앙 클라우드에 지속적으로 접속되는 것은 효율적이지 않다. 다른 시나리오들은 정보의 레이턴시에 민감한 처리를 행할 필요가 있을 수 있다. 에지 컴퓨팅은 레이턴시를 감소시키는데, 그 이유는 데이터가 처리를 위해 네트워크를 통해 데이터 센터 또는 클라우드로 횡단할 필요가 없기 때문이다.

포그 컴퓨팅은 에지 디바이스들과 클라우드 사이의 네트워크 접속들을 지칭한다. 반면, 에지 컴퓨팅은 에지 디바이스들에 근접하여 행해지는 계산 프로세스들을 더 구체적으로 지칭한다. 따라서, 포그 컴퓨팅은 에지 컴퓨팅을 포함할 수 있지만, 포그 컴퓨팅은 또한 그 최종 목적지로의 처리된 데이터를 얻는데 필요한 네트워크를 포함할 수 있다. 공식적으로, 포그 컴퓨팅(또는 간략하게는, 포그)은 클라우드로부터 사물로의 연속체를 따라 최종 사용자들에게 더 가깝게 컴퓨팅, 저장, 제어 및 네트워킹과 같은 서비스들 및 리소스들을 이동시키는 시스템 레벨 아키텍처이다. 예시적인 포그 가능 연속체가 도 1에 도시되어 있다.

일반적으로, "데이터 분석"은 광범위한 용어이다. 그러므로, 시장에는 많은 유형들의 데이터 분석 제품들(예컨대, 구글 분석(Google Analytics), IBM 왓슨(IBM Watson), 분산형 데이터 처리를 위한 개방-소스 Apache Hadoop 에코시스템 등)이 있다.

Microsoft Azure IoT 에지는 클라우드 분석 및 맞춤 비즈니스 로직을 에지에서의 디바이스들로 이동시키는 예시적인 제품이다. 일반적으로, Azure IoT 에지는 3개의 구성요소로 구성된다:

IoT 에지 모듈들은 Azure 서비스들, 제3자 서비스들 또는 개발자 자신의 코드를 실행하는 컨테이너들이다. 이들은 IoT 에지 디바이스들에 배치되고 이들 디바이스들 상에서 로컬로 실행될 수 있다. IoT 에지 모듈들은, 에지에서 사용자의 비즈니스 로직을 실행하는, 도커 호환가능한 컨테이너들로서 현재 구현되는 실행 유닛들이다. 복수의 모듈들은 서로 통신하도록 구성될 수 있고, 데이터 처리의 파이프라인을 생성하고;

IoT 에지 실행시간은 각각의 IoT 에지 디바이스 상에서 실행되고, 각각의 디바이스에 배치된 모듈들을 관리하며;

클라우드 기반 인터페이스는 사용자가 IoT 에지 디바이스들을 원격으로 모니터링하고 관리하는 것을 가능하게 한다.

AWS Greengrass는 사용자들이 접속된 디바이스들에 대한 로컬 계산, 메시징 및 데이터 캐싱 능력들을 실행하게 하는 소프트웨어이다. AWS Greengrass에 의해, 접속된 디바이스들은 AWS 람다 기능들(이벤트 처리 서비스)을 실행하고, 디바이스 데이터를 동기화로 유지하고, 인터넷에 접속되지 않을 때에도 다른 디바이스들과 안전하게 통신할 수 있다.

AWS Greengrass는 사용자들이 상이한 유형들의 디바이스들을 클라우드와 서로 접속시키는 IoT 솔루션들을 구축하게 한다. AWS Greengrass 코어를 실행하는 디바이스들은 Amazon FreeRTOS를 실행하고 있거나 AWS IoT 디바이스 SDK가 설치된 다른 디바이스들과 통신할 수 있는 허브로서 동작한다.

AWS Greengrass 코어 디바이스들, AWS IoT 디바이스 SDK-가능 디바이스들, 및 Amazon FreeRTOS 디바이스들은 에지에서의 Greengrass 그룹에서 서로 통신하도록 구성될 수 있다. 만약 Greengrass 코어 디바이스가 클라우드에 대한 접속성을 잃으면, Greengrass 그룹 내의 디바이스들은 로컬 네트워크를 통해 서로 계속 통신할 수 있다. Greengrass 그룹은, 예를 들어, 건물의 하나의 층, 하나의 트럭, 또는 전체 채굴 지점을 나타낼 수 있다.

개발 하에 있는 oneM2M 표준은 "CSE(Common Service Entity)"라고 지칭되는 서비스 계층을 정의한다(oneM2M-TS-0001 oneM2M 기능적 아키텍처-V3.8.0 참조). 서비스 계층의 목적은 상이한 "수직(vertical)" M2M 시스템들 및 애플리케이션들에 의해 이용될 수 있는 "수평(horizontal)" 서비스들을 제공하는 것이다. CSE는 도 2에 도시된 바와 같이 4개의 참조 포인트를 지원한다. Mca 참조 포인트는 애플리케이션 엔티티(AE)와 인터페이싱한다. Mcc 참조 포인트는 동일한 서비스 제공자 도메인 내의 다른 CSE와 인터페이싱하고, Mcc' 참조 포인트는 상이한 서비스 제공자 도메인에서의 다른 CSE와 인터페이싱한다. Mcn 참조 포인트는 기반 네트워크 서비스 엔티티(NSE))와 인터페이싱한다. NSE는 디바이스 관리, 위치 서비스들 및 디바이스 트리거링과 같은 기반 네트워크 서비스들을 CSE들에게 제공한다.

CSE는, "발견" 및 "데이터 관리 및 저장소"와 같은, "공통 서비스 기능들(CSF들)"이라고 불리는 복수의 논리적 기능들을 포함한다. 도 3은 oneM2M에 의해 정의되는 CSF들 중 일부를 예시한다.

oneM2M 아키텍처는 이하의 예시적인 유형들의 노드들을 가능하게 한다:

애플리케이션 서비스 노드(ASN): ASN은 하나의 CSE를 포함하고 적어도 하나의 애플리케이션 엔티티(AE)를 포함하는 노드이다. 물리적 매핑의 예: ASN은 M2M 디바이스에 존재할 수 있다.

애플리케이션 전용 노드(ADN): ADN은 적어도 하나의 AE를 포함하고 CSE를 포함하지 않는 노드이다. oneM2M 시스템의 필드 도메인에 0개 이상의 ADN이 있을 수 있다. 물리적 매핑의 예: 애플리케이션 전용 노드는 제약된 M2M 디바이스에 존재할 수 있다.

중간 노드(MN): MN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. oneM2M 시스템의 필드 도메인에 0개 이상의 MN이 있을 수 있다. 물리적 매핑의 예: MN은 M2M 게이트웨이에 존재할 수 있다.

인프라스트럭처 노드(IN): IN은 하나의 CSE를 포함하고 0개 이상의 AE를 포함하는 노드이다. 인프라스트럭처 도메인에 oneM2M 서비스 제공자당 정확히 하나의 IN이 있다. IN의 CSE는 다른 노드 유형들에 적용가능하지 않은 CSE 기능들을 포함할 수 있다. 물리적 매핑의 예: IN은 M2M 서비스 인프라스트럭처에 존재할 수 있다.

비-oneM2M 노드(NoDN): 비-oneM2M 노드는 oneM2M 엔티티들을 포함하지 않는(AE들도 CSE들도 포함하지 않는) 노드이다. 이러한 노드들은, 관리를 포함한, 연동 목적들을 위해 oneM2M 시스템에 부착된 디바이스들을 나타낸다.

예시적인 스마트 도시 분석 이용 사례가 도 4에 도시되어 있다. 스마트 도시를 구축하기 위해, 도시 기관은 (oneM2M과 같은) 표준 기반 서비스 계층(SL) 플랫폼을 채택하고, (예컨대, 도로들 및 거리들 상에, 공공 건물들에서, 버스들 및 지하철들 상에서 등과 같이) 도시 공공 인프라스트럭처 상에 많은 IoT 센서들 및 디바이스들을 배치한다. 한편, 제한된 예산으로 인해, 도시 기관은 또한 이 스마트 도시 계획에 대한 개인 조직들 및 개인들의 참여를 요청한다. 따라서, 개인 재산들(예컨대, 개인 자동차들, 셀폰들 등)에 설치된 이러한 IoT 디바이스들은 또한 시스템 내에 통합되며, 이는 도시의 실시간 실행 상태를 반영하는 대량의 포괄적 IoT 데이터를 생성할 수 있다.

도시는 LFA(Local Fog Area)로서 지칭될 수 있는 CBD(Central Business District), 교외 주거 영역 등과 같은 많은 지리적 영역들을 가질 수 있다. 이러한 LFA들에는 엄청난 양의 IoT 디바이스들이 배치될 수 있고, 이러한 LFA들로부터 많은 양의 IoT 데이터가 생성될 수 있다. 통신 네트워크 관점에서, 상이한 도시 영역들은 복수의 LFA를 구성한다(예컨대, 도 4에 도시된 바와 같이, CBD는 LFA-1에 대응하고, 교외 주거 영역은 LFA-2에 대응한다).

스마트 도시 제어 콘솔은 사용자들이 그들의 요구들에 기반하여 다양한 데이터 분석 요청들을 제기하게 하는 클라우드에 배치된다. 예를 들어, 조직-A로부터의 사용자는 주어진 영역(예컨대, 도 4에 도시된 바와 같이, 대규모 도로 작업 및 건물 건설 중인 영역인 LFA-X)에 대한 현재의 날씨 및 환경 오염 상태를 평가하고자 하는 요청(요청-1로 표시됨)을 가질 수 있다. 실제로, 데이터 분석 결과들은 일반적으로 다양한 차트들(예를 들어, 선 차트 또는 막대 차트)을 통해 표현된다. 사용자가 어떤 유형의 분석 차트들을 보고자 하는지에 더하여, 이들은 또한 데이터 샘플들이 어떤 것이어야 하는지, 어떤 것들이 차트를 그리기 위한 입력들인지를 지정할 수 있다. 차트들을 그리기 위한 이러한 데이터 샘플들을 준비하기 위해, 관련된 원시 데이터는 (온도 센서들, 습도 센서들, 오염 센서들, 잡음 센서들 등과 같은) LFA들에서의 다양한 IoT 디바이스들로부터 수집될 필요가 있다. 특히, 이러한 센서들 또는 디바이스들은 (사용자가 가입된) 조직-A 이외의 상이한 조직들에 의해 설치될 수 있다. 상이한 조직들에 걸친 상호동작을 처리할 때, 다양한 제약들(예컨대, 상이한 조직들에 걸친 상호동작의 복잡성들) 및 잠재적으로 발생된 대규모 IoT 데이터의 통신 및 처리 비용들을 고려함으로써 이것을 효율적인 방식으로 수행하는 것이 주요한 과제이다.

예에서, 요청-1에서, 사용자는 LFA-X에 대한 선 차트를 보고자 하고, 이는 매 3분마다 하나의 데이터 샘플을 요구한다고 가정한다. 특히, 각각의 데이터 샘플은 다음의 2개의 데이터 요소에 의해 구성될 수 있고, 데이터 요소들 각각은 품질 요건과 연관될 수 있다:

데이터 요소(DE)-1: 마지막 3분에서의 LFA-X의 평균 온도이다.

DE-1의 품질 요건: 온도 판독치들은 정확도를 보장하기 위해 LFA-X에 배치된 적어도 100개의 상이한 온도 센서로부터 수집될 필요가 있다.

DE-2: 마지막 3분에서의 LFA-X의 평균 잡음 레벨이다.

DE-2의 품질 요건: 잡음 판독치들은 LFA-X에서 30개의 주요 교차로에 배치된 잡음 센서들로부터 수집될 필요가 있다.

클라우드에 배치된 스마트 도시 제어 콘솔 상에 선 차트를 그리기 위해, (DE-1, DE-2, 타임스탬프)의 포맷을 갖는 데이터 샘플이 매 3분마다 필요할 것이다.

이하의 기술적 과제들은 위의 이용 사례와 관련하여 식별될 수 있다:

문제 1: 스마트 도시 분석 이용 사례를 실현하기 위한 간단한 해결책은 LFA들로부터 모든 필요한 IoT 데이터를 수집하고 클라우드에서 중앙집중화된 데이터 처리를 수행하는 것이다. 예를 들어, 처음 예에서 DE-1을 고려하면, 100개의 온도 판독치가 매 3분마다 LFA로부터 수집될 것이고, 이어서 클라우드로 전송되며, 여기서 데이터 처리(예컨대, 이러한 100개의 판독치의 평균 값의 계산)가 수행될 것이다. 알 수 있는 바와 같이, 중앙집중화된 데이터 처리는 LFA들로부터 클라우드로의 많은 양의 데이터 이동으로 인해 상당한 통신 오버헤드를 초래한다.

문제 2: 사용자는 LFA들 내의 이용가능한 IoT 데이터 소스들에 대한 지식을 갖지 않을 수 있다. 예를 들어, 스마트 도시 이용 사례에서, 배치된 SL 플랫폼은 또한 상이한 조직들 및 개인들로부터 많은 IoT 디바이스들을 통합한다. 따라서, 클라우드측으로부터의 사용자는 이러한 IoT 디바이스들을 배치한 동일한 당사자가 아닐 수 있다. 그 결과, 사용자는 그 원하는 데이터 샘플들에 대한 데이터 소스들로서 이용될 수 있는 원하는 IoT 디바이스들을 식별하기 위해 LFA들을 자체적으로 탐색해야 한다. 이러한 요건은 특히 LFA들에서 적절한 발견 능력을 갖지 않으면 사용자에게 추가 부담을 제기한다.

문제 3: 기존의 IoT 에지 제품들은 사용자가 "에지-대-클라우드" 구성 능력들을 갖지 않을 수 있다는 사실로 인해 유용하지 않을 수 있다. 예를 들어, (Microsoft Azure IoT 에지 또는 Amazon Greengrass와 같은) 기존의 제품들의 대부분은 사용자들이 LFA들에서 디바이스들/노드들(예컨대, 에지에서의 센서들, 게이트웨이들 등)에 대한 지식 및 구성 능력들을 통상적으로 갖는 비교적 간단한 경우를 지원하도록 구성된다. 다시 말해서, 사용자가 자신의 이용을 위해 에지 분석 애플리케이션을 구축하기를 원할 때, 이들은 어떤 에지 디바이스들이 접속되어야 하는지를 알 수 있고, 또한 에지측에서 직접 데이터 처리를 수행하기 위한 분석 처리 코드/유닛을 실행하기 위해 이러한 노드들(예컨대, 게이트웨이들)을 구성하는 능력을 가질 수 있다. 그러나, 이것은 사용자가 LFA들 내의 많은 IoT 디바이스들의 소유자가 아니거나 다른 상이한 당사자들 또는 조직들에 의해 소유될 수 있는 LFA들 내의 임의의 노드들을 구성하기 위한 어떠한 능력도 갖지 않는 예에서의 사례가 아니다. 그 결과, 기존의 IoT 에지 제품들은 이러한 혼성 시나리오에서 작동할 수 없다.

전체적으로, 서비스 계층 관점에서, SL 기반 플랫폼은 종종 상이한 도메인들에 걸쳐 애플리케이션들을 가능하게 하는 수평 플랫폼인 것으로 가정된다. 다시 말해서, 이러한 수평 플랫폼은 상이한 당사자들 및/또는 조직들로부터의 리소스들의 통합 시에 양호해야 하며, 이는 혼성 애플리케이션 시나리오에 대한 원하는 특성이다. 그렇게 하기 위해, SL 기반 플랫폼들(예컨대, oneM2M)은 종종 많은 유형들의 공통 서비스들을 제공하며, 이는 사용자들이 상세들에 관련되게 하거나 요구하지 않고 (발견, 디바이스 관리 등과 같은) 상이한 유형들의 동작들을 수행할 수 있게 할 수 있다. 그러나, 기존의 SL 기반 플랫폼 해결책들은 포그 컴퓨팅 패러다임을 활용함으로써 효율적인 데이터 샘플 수집 및 처리를 지원하기 위한 공통 서비스 또는 능력을 현재 제공하지 않는다.

포그 기반 서비스 계층(SL)에 대한 데이터 샘플 수집 서비스(DSCS)가 본 명세서에 개시된다. DSCS는 포그 컴퓨팅 패러다임에 기반한 SL에서의 서비스이다. DSCS에 의해, DSCS의 사용자들은 그들이 어떤 유형의 RDS(들)를 수신하고자 하는지에 대한 그들의 요구를 지정할 수 있고, DSCS는 LFA들에서 모든 것을 처리하고 원하는 RDS(들)를 생성하도록 구성될 수 있다.

또한 데이터 샘플 템플릿(DST)이 개시된다. DST는 사용자가 어떤 유형의 RDS(들)를 수신하고자 하는지에 관한 모든 상세들을 설명하고, 이는 DSCS가 LFA들에서 IoT 원시 데이터 수집 및 원시 데이터 처리를 수행하기 위한 가이드라인일 것이다.

또한 이하의 양태들 중 하나 이상을 포함할 수 있는 "DST 관리"를 위한 방법들 및 시스템들이 개시된다:

이에 제한되는 것은 아니지만 다음을 포함하는, 상이한 애플리케이션 시나리오들에서 이용될 수 있는 "DST 생성 프로세스"에 대한 다수의 예시적인 해결책들이 본 명세서에 개시되어 있다:

시나리오 1: LFA들에서 리액티브 DS 식별에 의한 DST 생성;

시나리오 2: LFA들에서 프로액티브 DS 식별에 의한 DST 생성;

시나리오 3: DE 재이용을 통한 DST 생성; 및

시나리오 4: DST 분할에 의한 DST 생성.

"DST 업데이트/삭제 프로세스"에 대한 다수의 해결책이 개시되며, 이는 다음을 포함하지만 이에 제한되지는 않는다:

기존의 DST에 새로운 DE들을 추가하거나 기존의 DST 내의 일부 정보를 간단히 업데이트하기 위한 DST 업데이트 프로세스; 및

기존의 DST에서 하나 이상의 DE를 삭제하거나 전체 DST를 삭제하기 위한 DST 업데이트 프로세스.

"DST 활성화 프로세스"에 대한 다수의 해결책들이 개시되며, 이는 다음을 포함하지만 이에 제한되지는 않는다:

주어진 DST는 DST 내의 "RDS_Production_Schedule" 파라미터에 표시된 파라미터에 기반하여 활성화될 수 있고;

주어진 DST는 사용자 자체로부터의 신호에 기반하여 활성화될 수 있고;

주어진 DST는 LFA들에서 발생한 이벤트들에 기반하여 활성화될 수 있다.

본 개시내용 전체에 걸쳐 사용되는 용어들 중 일부에 대한 예시적인 정의들이 아래에 설명된다:

클라우드 노드(CN): 배치 계층구조에서 더 낮은 다른 포그 노드들의 동작들을 관리하는 클라우드 능력들을 갖는 노드이다. 용어 "클라우드"는 클라우드 노드를 지칭하는데 사용될 수 있다는 점에 유의한다. 또한, 클라우드는 함께 애플리케이션들에 대한 포그 서비스 계층을 가능하게 하는 상이한 포그 노드들 사이의 상호작용들을 감독하고 관리한다.

로컬 포그 영역(LFA): 지리적 영역(예를 들어, 도시)은 상이한 애플리케이션 시나리오들에 따라 복수의 LFA로 분할될 수 있다. 예를 들어, 스마트 도시 시나리오에서, 특정 주거 영역은 LFA일 수 있거나, 시내 영역 내의 CBD가 LFA일 수 있다.

로컬 포그 노드(LFN): LFN은 계산, 저장, 및 통신 능력들을 갖는 LFA 내의 노드일 수 있다. LFN은 그 대응하는 LFA에서 LFNL과 통신하고 상호작용할 수 있다. 예를 들어, LFN은 사람의 셀폰, 이동 버스, 또는 집의 홈 게이트웨이 등일 수 있다. LFN은 네트워크의 최저 레벨에 있는 FN의 유형이다. LFN은 LFA 내의 다른 LFN들과 상호작용하고 협력할 수 있고, DS들로부터의 데이터의 발견, 획득 및 처리를 수행할 수 있다.

데이터 소스(DS): 노드는 IoT 데이터의 소스인 경우 DS일 수 있다. 예를 들어, DS는 센서, 카메라, 신호등, 또는 데이터를 생성하는 임의의 IoT 디바이스들일 수 있다. 도로변 유닛은 또한, 그것이 노면과 관련된 센서 데이터를 생성하기 때문에 DS일 수 있다. 한편, 도로변 유닛은 또한 특정 데이터 처리 능력을 수행할 수 있고/있거나 LFNL과 통신할 수 있기 때문에 LFN일 수 있다. 감지할 뿐만 아니라 컴퓨팅, 저장 및 통신 능력들도 갖는 LFA 내의 노드는 LFN뿐만 아니라 DS일 수 있다.

LFN 리더(LFNL): 주어진 LFA는 포그 영역에서 LFN 리더를 가질 수 있다. LFNL은 그 LFA 내의 모든 LFN들을 관리하고, 또한 더 높은 레벨 상에 있는 FN들에 접속된다. 예를 들어, 스마트 도시 예에서, LFNL은 특정 주거 영역의 주요 게이트웨이일 수 있다.

포그 노드(FN): 계산, 저장, 통신, 분석 등과 같은 임의의 포그 리소스를 갖는 노드이다. 포그 노드는 이러한 리소스들 중 적어도 하나를 가질 수 있고, 또한 포그 노드 상에서 실행 중인 다른 소프트웨어 또는 서비스들을 가질 수 있다. FN은 LFN의 레벨보다 높은 하나의 레벨에 배치되는 것으로 가정된다. CN이 가장 높은 레벨에 있는 여러 레벨들의 FN 배치들이 있을 수 있다. 예를 들어, 스마트 도시 이용 사례에서, FN은 네트워크 내의 더 높은 레벨의 라우터일 수 있다.

본 개시내용에서 제안된 아이디어들이 포그 관련 용어들을 사용하여 설명되지만, 본 개시내용에서 제안된 아이디어들은 또한 에지 시나리오에 적용될 수 있다는 점에 주목할 만하다. 예를 들어, LFA는 또한 에지에서 특정 영역으로서 해석될 수 있고, LFN은 에지측에 있는 노드일 수 있고, LFNL은 에지에서의 게이트웨이 또는 에지에서의 도로변 유닛 등일 수 있다.

데이터 샘플 수집 서비스(DSCS)라고 지칭될 수 있는 서비스 계층에 대한 새로운 공통 서비스가 본 명세서에 개시된다. DSCS의 상위 레벨 아키텍처가 도 5에 도시되어 있다. 개시된 DSCS는 다음의 능력들 중 하나 이상을 가질 수 있다:

DSCS는 사용자들로부터 다양한 데이터 샘플 수집 요청들을 수신하고 그 사용자들을 대신하여 모든 상세들을 처리할 수 있다.

사용자에게 어떤 종류의 RDS가 필요한지를 적절하게 설명하기 위해(예를 들어, 제어 콘솔 상에 선 차트를 그리기 위해), DSCS는 데이터 샘플 템플릿(DST)이라고 불리는 새로운 개념을 채택한다. DST를 이용함으로써, 사용자는 데이터 샘플들에 관한 다양한 품질 요건들과 함께, 그 원하는 데이터 샘플들이 어떤 모양인지를 명확하게 묘사할 수 있다.

DSCS는 사용자들에게 DST 관리 기능을 제공할 수 있다. 일반적으로, DST 관리는 DST 생성, DST 업데이트, DST 삭제 및 DST 활성화/비활성화의 프로세스들을 포함한다. 예를 들어, 사용자는 그 데이터 샘플 수집 요구에 기반하여 DST를 생성할 수 있다. 나중에, 생성된 DST는 또한 그 요구에 대한 동적 변경들에 기반하여 업데이트 및/또는 삭제될 수 있다. DST에 대해 이루어진 변경들은 또한 이 DST의 대응하는 데이터 샘플들에 대한 변경들을 낳을 수 있다.

DSCS는 생성된 DST를 활성화 또는 비활성화하기 위한 인터페이스들을 사용자들에게 제공할 수 있다. 일 예에서, DST의 실제 RDS 생성은 이 DST가 활성화 상태에 있을 때까지 시작되지 않을 수 있다는 점에 유의한다.

예시적인 방법은, 데이터 샘플 템플릿을 생성하라는 요청을 수신하는 단계 - 데이터 샘플 템플릿을 생성하라는 요청은 하나 이상의 데이터 요소와 연관된 정보를 포함함 -; 하나 이상의 데이터 요소와 연관된 정보에 기반하여, 데이터 샘플 템플릿을 생성하는 단계; 데이터 샘플 수집 서비스의 제2 에이전트에, 하나 이상의 데이터 요소와 연관된 하나 이상의 데이터 소스를 식별하라는 요청을 전송하는 단계 - 데이터 샘플 수집 서비스의 제2 에이전트는 로컬 포그 노드 상에 위치됨 -; 데이터 샘플 수집 서비스의 제2 에이전트로부터, 하나 이상의 데이터 소스와 연관된 정보를 수신하는 단계; 및 하나 이상의 데이터 소스와 연관된 정보에 기반하여, 데이터 샘플 템플릿을 구성하는 단계를 포함하는 동작들을 수행하도록 구성된 데이터 샘플 수집 서비스의 제1 에이전트를 포함할 수 있다.

데이터 샘플 템플릿을 생성하라는 요청은 생성될 데이터 샘플의 유형의 표시를 포함할 수 있다. 데이터 샘플 템플릿을 생성하라는 요청은 하나 이상의 파라미터의 표시를 더 포함할 수 있고, 하나 이상의 파라미터는 데이터 샘플과 연관된 표적화된 영역; 데이터 샘플과 연관된 빈도; 데이터 샘플과 연관된 생성 스케줄; 및 데이터 샘플과 연관된 컨텍스트를 포함한다. 이 방법은, 하나 이상의 파라미터에 기반하여, 복수의 로컬 포그 노드 중 어느 것을 표적으로 할지를 결정하는 단계를 더 포함할 수 있다. 하나 이상의 데이터 요소와 연관된 정보는, 데이터 요소의 원시 데이터 유형; 데이터 요소의 단위; 데이터 요소의 데이터 처리 동작; 데이터 요소의 하나 이상의 맞춤화된 처리 상세; 및 데이터 요소의 하나 이상의 품질 요건 중 하나 이상을 포함할 수 있다. 이 방법은 데이터 샘플 수집 서비스의 제2 에이전트에, 구성된 데이터 샘플 템플릿을 전송하는 단계를 더 포함할 수 있다. 데이터 샘플 수집 서비스의 제2 에이전트는, 구성된 데이터 샘플 템플릿에 기반하여, RDS를 생성하도록 구성될 수 있다.

예시적인 방법은, 제1 데이터 샘플 템플릿에 기반하여, 제2 데이터 샘플 템플릿 및 제3 데이터 샘플 템플릿을 생성하는 단계 - 제2 데이터 샘플 템플릿은 데이터 요소들의 제1 세트와 연관되고, 제3 데이터 샘플 템플릿은 데이터 요소들의 제2 세트와 연관됨 -; 데이터 샘플 수집 서비스의 제2 에이전트에, 데이터 요소들의 제1 세트와 연관된 데이터 소스들의 제1 세트를 식별하라는 요청을 전송하는 단계 - 데이터 샘플 수집 서비스의 제2 에이전트는 제1 로컬 포그 노드에 위치됨 -; 데이터 샘플 수집 서비스의 제3 에이전트에, 데이터 요소들의 제2 세트와 연관된 데이터 소스들의 제2 세트를 식별하라는 요청을 전송하는 단계 - 데이터 샘플 수집 서비스의 제3 에이전트는 제2 로컬 포그 노드에 위치됨 -; 데이터 샘플 수집 서비스의 제2 에이전트로부터, 데이터 소스들의 제1 세트와 연관된 정보를 수신하는 단계; 데이터 샘플 수집 서비스의 제3 에이전트로부터, 데이터 소스들의 제2 세트와 연관된 정보를 수신하는 단계; 및 데이터 소스들의 제1 세트와 연관된 정보 및 데이터 소스들의 제2 세트와 연관된 정보 중 하나 이상에 기반하여, 제2 데이터 샘플 템플릿 및 제3 데이터 샘플 템플릿 중 적어도 하나를 구성하는 단계를 포함하는 동작들을 수행하도록 구성된 데이터 샘플 수집 서비스의 제1 에이전트를 포함할 수 있다.

이 방법은 데이터 샘플 템플릿을 생성하라는 요청을 수신하는 단계 - 데이터 샘플 템플릿을 생성하라는 요청은 하나 이상의 데이터 요소와 연관된 정보를 포함함 -; 및 하나 이상의 수신된 데이터 요소와 연관된 정보에 기반하여, 제2 데이터 샘플 템플릿 및 제3 데이터 샘플 템플릿을 생성하는 단계를 더 포함할 수 있다. 하나 이상의 수신된 데이터 요소와 연관된 정보는 데이터 요소들의 제1 세트와 연관된 정보 및 데이터 요소들의 제2 세트와 연관된 정보를 포함할 수 있다. 이 방법은, 하나 이상의 수신된 데이터 요소와 연관된 정보에 기반하여, 표적으로 할 복수의 로컬 포그 노드 중 하나 이상을 결정하는 단계를 더 포함할 수 있다. 제2 데이터 샘플 템플릿 및 제3 데이터 샘플 템플릿 각각은 다음의 파라미터들: 각각의 데이터 샘플 세트와 연관된 표적화된 영역; 각각의 데이터 샘플 세트와 연관된 빈도; 각각의 데이터 샘플 세트와 연관된 생성 스케줄; 및 각각의 데이터 샘플 세트와 연관된 컨텍스트 중 하나 이상을 포함할 수 있다. 이 방법은, 구성된 제2 데이터 샘플 템플릿을 데이터 샘플 수집 서비스의 제2 에이전트에 전송하는 단계; 및 구성된 제3 데이터 샘플 템플릿을 데이터 샘플 수집 서비스의 제3 에이전트에 전송하는 단계를 더 포함할 수 있다. 데이터 샘플 수집 서비스의 제2 에이전트는, 구성된 제2 데이터 샘플 템플릿에 기반하여, 제1 RDS를 생성하도록 구성될 수 있다. 데이터 샘플 수집 서비스의 제3 에이전트는, 구성된 제3 데이터 샘플 템플릿에 기반하여, 제2 RDS를 생성하도록 구성될 수 있다.

예시적인 방법은, 새로운 데이터 요소를 기존의 데이터 샘플 템플릿에 추가하라는 요청을 수신하는 단계 - 기존의 데이터 샘플 템플릿은 복수의 데이터 요소를 포함하는 RDS와 연관됨 -; 새로운 데이터 요소에 기반하여, 기존의 샘플 템플릿을 업데이트하는 단계; 데이터 샘플 수집 서비스의 제2 에이전트에, 새로운 데이터 요소와 연관된 하나 이상의 데이터 소스를 식별하라는 요청을 전송하는 단계 - 데이터 샘플 수집 서비스의 제2 에이전트는 로컬 포그 노드 상에 위치됨 -; 데이터 샘플 수집 서비스의 제2 에이전트로부터, 하나 이상의 데이터 소스와 연관된 정보를 수신하는 단계; 및 하나 이상의 데이터 소스와 연관된 정보에 기반하여, 업데이트된 데이터 샘플 템플릿을 구성하는 단계를 포함하는 동작들을 수행하도록 구성된 데이터 샘플 수집 서비스의 제1 에이전트를 포함할 수 있다.

새로운 데이터 요소를 추가하라는 요청은 기존의 데이터 샘플 템플릿의 식별자 및 새로운 데이터 요소에 대한 표적화된 영역 중 하나 이상을 포함할 수 있다. 새로운 데이터 요소와 연관된 정보는, 데이터 요소의 원시 데이터 유형; 데이터 요소의 단위; 데이터 요소의 데이터 처리 동작; 데이터 요소의 하나 이상의 맞춤화된 처리 상세; 및 데이터 요소의 하나 이상의 품질 요건 중 하나 이상을 포함한다. 새로운 데이터 요소를 추가하라는 요청은 기존의 데이터 요소를 업데이트하라는 요청을 포함할 수 있다. 데이터 요소를 업데이트하라는 요청은 기존의 데이터 샘플 템플릿의 식별자 및 업데이트될 데이터 요소의 하나 이상의 파라미터 중 하나 이상을 포함할 수 있다. 이 방법은 데이터 샘플 템플릿을 업데이트하기 전에, 데이터 샘플 템플릿을 비활성화하는 단계를 더 포함할 수 있다.

전술한 DSCS의 능력들을 구현하기 위해, 이하의 상세들이 설명된다:

일반적으로, (LFN, FN 또는 CN에서 구현된 것과 같은) 서비스 계층 노드는 이 노드가 데이터 샘플 수집 관련 서비스를 제공하고자 하는 경우 DSCS 에이전트를 가질 수 있다. SL 노드 상의 DSCS 에이전트는 DSCS 사용자들과 상호작용할 수 있을 뿐만 아니라 사용자들에 의해 제기된 다양한 데이터 샘플 수집 작업들을 수행하기 위해 다른 DSCS 에이전트들과 협력할 수 있는 소프트웨어의 부분이다.

DSCS 에이전트와 DSCS 사용자 사이의 상호작용에 관하여, DSCS 에이전트는 DST 생성, DST 업데이트 및 DST 삭제에 관하여 DST 관리를 지원하기 위해 DSCS 사용자에게 인터페이스들을 제공할 수 있다. 예를 들어, 도 5에 도시된 바와 같이, DSCS 에이전트(예컨대, DSCS 에이전트-1)가 CN에 배치되고, 이는 CN 내의 상이한 사용자들로부터의 분석 요청들을 수락할 수 있다.

DSCS 에이전트들 사이에 상호작용들 및 협력들이 또한 존재할 수 있다. 예를 들어, DSCS 에이전트는 또한 LFA의 LFNL에 배치될 필요가 있을 수 있다(이는 그 LFA에서의 모든 원시 데이터 수집 및 처리를 취급할 수 있다). 통상적으로, CN에서의 DSCS 에이전트-1은 사용자들의 요구에 기반하여 DST를 생성할 수 있고, 이 DST가 배치되어야 하는 LFA(들)를 알아낼 수 있다. 예를 들어, 사용자가 단지 특정 LFA로부터 데이터 샘플들을 수집하기를 원한다면, DST는 그 LFA에서의 DSCS 에이전트(예컨대, DSCS 에이전트-2)에 배치될 수 있다. 배치 동안, 특정 작업 스레드들(예컨대, 코드 스니펫들)이 DSCS 에이전트-2 상에서 셋업될 수 있다. 특히, DSCS 에이전트-2는 이 LFA에서 원하는 DS들을 식별하고, 요구된 데이터 처리 동작들을 수행하고, RDS를 생성하고, 단지 RDS들을 CN 내의 사용자들에게 다시 전송하는 것을 담당할 수 있다. 전반적으로, 이 DSCS 에이전트들은 다양한 데이터 샘플 수집 요청들을 서빙하기 위해 함께 작업할 수 있다.

SL에서의 공통 서비스로서, DSCS는 시스템이 상이한 당사자들 또는 조직들로부터 (디바이스들, 노드들 등의 면에서) 리소스들을 통합하더라도 포그 컴퓨팅 패러다임을 실현할 수 있다. 더 중요하게는, DSCS는 사용자들이 LFA들에서 원시 데이터를 수집하고 LFA들에 배치된 DSCS 에이전트 상의 원시 데이터를 직접적으로 분석/처리하는 것을 도울 수 있다. 다시 말해서, 이 프로세스 전체에 걸쳐, 사용자들은 LFA들에서 자격있는 DS들을 식별하는 방법 및 원시 데이터 처리를 위해 이들 LFA들에서 LFN들을 구성하는 방법에 관한 임의의 상세들에 관여될 필요가 없을 수 있다. 그 결과, 사용자는 DST를 생성함으로써 원하는 RDS들에 대한 그 요구만을 지정할 필요가 있을 수 있다. 나머지 모든 다른 처리는 개시된 DSCS에 의해 처리될 수 있다.

DSCS 사용자가 LFA들로부터 데이터 샘플들을 수집할 필요성을 가질 때, 이들은 DSCS 에이전트에 전송될 수 있는 데이터 샘플 수집 요청에서 그 요구를 설명할 수 있다. 따라서, 이 DST에 대한 RDS 생성을 어떻게 수행하는지에 관한 모든 상세들을 포함하는 DST가 생성될 수 있다. 아래에 도시된 바와 같이, 표 1은 DST에 대한 상세한 정의들을 제공한다.

<표 1>

본 개시내용의 제1 양태에서, DST 생성 프로세스를 위한 방법들 및 시스템들이 개시된다.

생성될 주어진 DST에 대해, 이들이 이 DST에 대한 원하는 DS들인지를 결정하기 위해 발견되고 평가될 필요가 있는 LFA에서 많은 수(예컨대, 수 천개)의 잠재적인 DS들이 존재할 수 있다(이러한 프로세스는 DS 식별 프로세스로서 지칭될 수 있다). 한편, 이러한 DS들로부터 수집된 원시 데이터는 또한 많은 양일 수 있고, RDS들을 생성하기 위한 대규모 원시 데이터에 대한 데이터 처리는 RDS 생성 프로세스라고 지칭될 수 있다. (제어 평면 문제로서의) DST 관리와 비교하여, DS 식별 및 RDS 생성은 실제 RDS 생성을 위한 "데이터 평면" 문제들과 더 유사하다.

제1 예에서, LFA들에서의 리액티브 DS 식별에 의한 DST 생성 프로세스가 논의된다. 이 예에서, DS 식별은 식별될 LFA들에서 원하는 DS들을 필요로 하는 DST 생성 요청이 있을 때까지 수행되지 않을 수 있다. 이것은 LFA들에서의 DSCS 에이전트들이 제한된 에너지 또는 처리 능력만을 갖는 시나리오 또는 LFA들에서의 DS들의 이용가능성이 빈번하게 변하는 시나리오에 적용가능할 수 있다(예를 들어, DS들이 이동 차량들에 장착되는 경우, 이들 DS들은 상이한 시간 간격들 동안 상이한 LFA들에서 이용가능할 수 있다는 점에서 상이한 LFA들에 걸쳐 이동할 수 있다).

도 6은 LFA들에서의 리액티브 DS 식별에 의한 DST 생성 프로세스에 대한 예시적인 절차를 도시한다:

단계 1에서, 이 예시적인 시스템에서, CN에 DSCS 에이전트가 존재한다. 사용자-1은 데이터 샘플 수집 요구를 가지며 SL에 의해 제공되는 DSCS를 이용하려고 의도한다. 따라서, 사용자-1은 CN의 DSCS 에이전트-1에 접촉하기로 결정한다.

단계 2에서, 사용자-1은 어떤 유형의 데이터 샘플을 수신하고자 하는지에 관한 정보와 함께 DST 생성 요청을 DSCS 에이전트-1에 전송한다. 특히, 메시지는 (표 1에 추가로 설명되는 바와 같이) 다음 파라미터들 중 하나 이상을 포함할 수 있다:

Targeted_Region;

Data_Sample_Frequency;

RDS_Production_Schedule; 및

RDS_Context.

원하는 RDS들에 포함될 각각의 DE에 대해, 요청은 이 DE에 대한 상세들을 설명하는 다음의 파라미터들을 가질 수 있다:

Raw_Data_Type;

Unit;

Data_Processing_Operation;

Customized_Processing_Details; 및

Quality_Requirements.

단계 3에서, 사용자-1로부터의 정보에 기반하여, DSCS 에이전트-1은 DST-1을 생성한다. DSCS 에이전트-1은 또한, "DST_Users"(예컨대, 사용자-1), "DST_Initiator"(예컨대, 사용자-1), 및 "Creating_DSCS_Agent_ID"(예컨대, DSCS 에이전트-1)를 포함하는, 사용자-1에 의해 제공되지 않는 DST-1에서 다른 정보를 구성할 필요가 있다. 그러나, 지금까지 DS들이 DST-1에 대해 식별되지 않았기 때문에, DST-1의 상태는 "DST_Status" 파라미터에서 "실행불가능"으로 설정될 수 있다. 따라서, DSCS 에이전트-1은 어느 LFA들이 이 DST-1에 관여되는지를 결정한다. 예를 들어, "Targeted_Region" 파라미터에 포함된 상세들에 기반하여, DSCS 에이전트-1은 사용자-1이 관심이 있는 지리적 영역이 통신 네트워크 관점에서 어느 LFA들에 대응하는지를 알아낼 수 있다. 이 예에서, 단지 하나의 LFA(예컨대, LFA-1)가 수반된다. 그에 추가하여, DST-1이 분할되지 않을 것이기 때문에, Type_of_DST는 R-DST의 값으로 설정될 수 있다. 다음으로, DSCS 에이전트-1은 DST-1에 대한 DS 식별 프로세스를 트리거링하기 위해 LFA-1에서의 LFNL 상의 DSCS 에이전트(예컨대, DSCS 에이전트-2)에 접촉할 필요가 있다.

단계 4에서, 원하는 DE들 각각에 관한 사용자-1로부터의 정보에 기반하여, DSCS 에이전트-1은, 원시 데이터 및 관련 품질 요건들에 대해 어떤 유형의 데이터 처리 동작이 수행될지와 같은, 다른 상세 정보와 함께 DST-1에 대한 DS 식별을 트리거링하라는 요청을 DSCS 에이전트-2에 전송한다. 즉, 이 경우 DSCS 에이전트-2는 DST-1의 "필드내(in-field) 관리자"이다. (시나리오 1에서 고려되는 바와 같이) 분할되지 않을 주어진 DST에 대해, 그 필드내 관리자는 대응하는 LFA들에서 DS 식별 및 RDS 생성을 수행하기 위한 중앙 제어기일 수 있다는 점에 유의한다. 특히, DST가 (이 경우에 DST-1과 같은) R-DST인 경우, 그 필드내 관리자는 이 DST 내의 대응하는 DE들의 원시 데이터가 (DST-1 내의 이들 DE들 각각에 대한 Data_Processing_Operation 파라미터들에 표시된 바와 같은 데이터 처리 동작들을 이용하여) 처리되는 위치일 수 있고, 이는 이 전체 DST-1에 대한 RDS의 생성을 초래한다.

단계 5에서, DSCS 에이전트-1로부터 요청을 수신한 후에, LFA-1에서의 DSCS 에이전트-2는 DST-1에서의 모든 DE들에 대해 원하는 DS들이 식별될 수 있는지를 알기 위해 DS 식별을 수행한다(예를 들어, DSCS 에이전트-2는 DS 식별을 수행하기 위해 LFA-1 내의 다른 LFN들을 조정/관리할 수 있다).

단계 6에서, DSCS 에이전트-2는 DS 식별 결과를 DSCS 에이전트-1에 반환한다. 이 예에서, 원하는 DS들이 DST-1에서의 모든 DE들에 대해 식별되었다고 가정된다. DS 식별이 실패한 경우(예를 들어, 원하는 DS들이 DST-1에서의 모든 DE들에 대해 식별되지 않은 경우), DST 생성 프로세스는 종료될 수 있고, DSCS 에이전트-1은 DST 생성이 성공적이지 않았다는 것을 (예를 들어, 단계 11에서) 사용자-1에게 확인응답할 수 있다.

단계 7에서, DSCS 에이전트-1은 또한, "In_Field_Manager_ID"(예를 들어, 이 예에서는 DSCS 에이전트-2)를 포함하는, DST-1에서 다른 정보를 구성할 필요가 있을 수 있다. DSCS는 또한 DST-1을 "DST_Status" 파라미터에서 "실행가능한" DST로서 마킹한다.

단계 8에서, 일단 DST-1이 완전히 구성되었다면, DSCS 에이전트-1은 필드 배치를 위해 DST-1을 DSCS 에이전트-2로 전송한다.

단계 9에서, DSCS 에이전트-2는 다가오는 RDS 생성 동작을 위해 DST-1에 대한 작업 스레드를 시작하기 위해 특정 셋업 또는 구성들을 수행한다. 예를 들어, 사용자-1이 특정 DE에 대한 원시 데이터를 처리하기 위한 코드 스니펫을 제공한 경우, 이러한 코드 스니펫은 LFA-1에서 LFNL에 의해 관리되는 다른 LFN들 또는 DSCS 에이전트-2에 설치될 수 있다.

단계 10에서, DSCS 에이전트-2는 DST-1의 필드 배치가 완료되었음을 확인한다.

대안으로서, 단계 5에서, DSCS 에이전트-1은 또한 단계 6 동안 DST-1에서의 모든 DE들에 대해 원하는 DS들이 식별되었다면 DST-1의 작업 스레드가 (단계 9에서와 같이) 직접 셋업될 수 있는지를 표시할 수 있다. 이 경우, 단계 8 및 단계 10은 필요하지 않을 수 있다.

단계 11에서, DSCS 에이전트-1은 DST-1이 성공적으로 생성되고 또한 이제 특정 정보(예컨대, DST_ID)와 함께 실행가능하다는 것을 사용자-1에게 확인응답한다.

제2 예에서는, LFA들에서 프로액티브 DS 식별에 의한 DST 생성 프로세스가 논의된다. 이 예에서, LFA들에서의 DSCS 에이전트들은 DST 생성 요청이 없더라도 사전에 DS 식별을 수행할 수 있다. 이러한 해결책은 LFA들에서의 DSCS 에이전트들이 충분한 에너지 및 강력한 처리 능력을 갖거나, DS들의 이용가능성들이 미리 식별될 수 있도록 자주 변경되지 않는 시나리오에 적용가능할 수 있다.

도 7은 LFA들에서 프로액티브 DS 식별에 의한 DST 생성 프로세스에 대한 예시적인 절차를 도시한다:

전제 조건으로서, DSCS 에이전트-2는 LFA-1의 실시간 DS 카탈로그를 DSCS 에이전트-1에 주기적으로 전송할 수 있다.

단계 1은 도 6의 단계 1과 동일할 수 있다.

단계 2는 도 6의 단계 2와 동일할 수 있다.

단계 3에서, 사용자-1로부터의 정보에 기반하여, DSCS 에이전트-1은 DST-1을 생성한다. DSCS 에이전트-1은 또한 "DST_Users"(예컨대, 사용자-1), "DST_Initiator"(예컨대, 사용자-1), "Creating_DSCS_Agent_ID"를 포함하는, 사용자-1에 의해 제공되지 않는, DST-1에서 일부 다른 정보를 구성할 필요가 있을 수 있다. DSCS 에이전트-1은 또한 어느 LFA들(이 예에서는 LFA-1)이 DST-1에 관여되어 있는지를 결정할 수 있고, 이후 DSCS 에이전트-1은 관여된 LFA들(이 예에서는 DSCS 에이전트-2)의 LFNL로부터 전송된 최신 DS 카탈로그를 체크할 수 있다. 이 카탈로그에 기반하여, 원하는 DS들이 DST-1에서의 모든 DE들에 대해 식별될 수 있는 경우, DST-1은 "실행가능한" DST로서 마킹될 수 있다. DST-1은 완전히 구성된 후에, 필드 배치를 위해 DSCS 에이전트-2(이는 이 예에서는 DST-1의 필드 관리자임)에 전송될 수 있다.

단계 4는 도 6의 단계 8과 동일할 수 있다.

단계 5는 도 6의 단계 9와 동일할 수 있다.

단계 6은 도 6의 단계 10과 동일할 수 있다.

단계 7은 도 6의 단계 11과 동일할 수 있다.

제3 예에서, DE 재이용을 통한 DST 생성이 논의된다. 이 예에서, 상이한 DST들은 DSCS 에이전트 상에서 이미 생성되었을 때, DST 저장소에 이들 DST들을 호스팅하거나 저장할 수 있다. 따라서, 생성될 새로운 DST(예컨대, DST-100)의 경우, 저장소에 저장된 하나 이상의 기존의 DST에 이미 포함되어 있는 DE들이 중첩되었을 수 있다. 그 결과, 이들 DE들은 DST-100을 생성하기 위해 재이용될 수 있고, 이는 재이용될 수 있는 DST-100에서 이들 DE들에 대한 DS 식별 프로세스를 수행하기 위한 상당한 노력들을 아낄 수 있다.

도 8은 DE 재이용을 통한 DST 생성 프로세스에 대한 예시적인 절차를 도시한다:

전제 조건으로서 DSCS 에이전트-1은 이미 생성된 모든 기존의 DST들을 저장하는 DST 저장소를 유지한다.

단계 1은 도 6의 단계 1과 동일할 수 있다.

단계 2는 도 6의 단계 2와 동일할 수 있다. 대안적으로, DSCS 에이전트-1은 DSCS 사용자들에게 액세스 인터페이스를 직접 제공하여, 그들이 저장소에 저장된 기존의 DST들을 체크하고 질의하게 할 수 있다. 이 경우, 사용자-1은 먼저 저장소에 질의하고 기존의 DST들에서의 어느 DE들이 재이용될 수 있는지를 분류할 수 있다. 그 다음, 이 단계에서, 원하는 RDS 사용자-1은 수신하고자 하는 것을 설명할 때, 기존의 DST들에서의 어느 DE들이 재이용되어야 하는지를 직접 표시할 수 있다.

단계 3에서, 사용자-1로부터의 정보에 기반하여, DSCS 에이전트-1은 DST-100을 생성한다. 사용자-1이 어느 DE들이 단계 2에서 재이용되어야 하는지를 표시하지 않았다면, DSCS 에이전트-1은 저장소를 추가로 검색하고 기존의 DST들에서의 어느 DE들이 DST-100에서 필요한 DE들에 대해 재이용될 수 있는지를 분류한다. 특히, 각각의 DE는 DST에서 정의될 때 다수의 특성 및 품질 요건을 갖기 때문에, 기존의 DST 내의 하나의 DE가 다른 새로이 생성된 DST에서 추가로 재이용될 수 있는지를 평가할 때 이 정보를 평가하는 것이 필요할 수 있다. 예를 들어, 사용자-1에 대해 생성된 DST-100이 3개의 DE를 갖는 것으로 가정하면(예를 들어, DST-1의 RDS는 다음의 포맷: (DE-1, DE-2, DE-3, RDS_Context)를 가짐), DST 저장소에서, 기존의 DST-1에서의 DE-6이 DST-100에서 DE-2로서 재이용될 수 있는 반면, DST-3에서의 DE-27이 DST-100에서의 DE-3으로서 이용될 수 있는 것이 가능한데, 그 이유는 모든 그들의 특성들 및 품질 요건들이 일치되기 때문이다. 기존의 DST들에서의 이러한 재이용된 DE들의 모든 상세한 설명들은 DST-100에 대해 복제될 수 있다. 그에 추가하여, 대응하는 파라미터들이 DST-100에서 이들 DE들 각각에 대해 구성될 수 있다. 예를 들어, "Reused" 파라미터는 DST-100의 DE-2 및 DE-3에 대해 "참"으로 설정될 수 있고, "Reused_Info" 파라미터는 각각 DST-100에서의 DE-2 및 DE-3에 대해 "DST-1에서의 DE-6" 및 "DST-3에서의 DE-27"로 설정될 수 있다.

단계 4에서, DSCS 에이전트-1은 또한, 기존의 DST들에서의 이용가능한 DE들이 재이용될 수 없는, DE들(예컨대, DST-100에서의 DE-1)에 대해서만 DS 식별 프로세스를 수행할 수 있다. 이 단계는 도 6의 단계들 4-6을 포함한다. 한편, "Reused" 파라미터는 DST-100에서의 DE-1에 대해 "거짓"으로 설정되어야 한다. 도 8에 도시된 이 예에서는, 하나의 LFA만이 관여되지만, 일반적으로 DS 식별 프로세스는 또한 후술되는 해결책을 이용함으로써 복수의 LFA들에 관여될 수 있다는 점에 유의한다.

단계 5는 도 6의 단계 7과 동일할 수 있다.

단계 6은 도 6의 단계들 8-10과 동일할 수 있다. 특히, DST-100에 대한 작업 스레드는 다른 것들에 의해 생성된 기존의 작업 스레드들을 활용하여 구축될 수 있으며 DST-100에서 이러한 재이용된 DE들에 대한 RDS 데이터를 생성하는 것을 담당한다.

단계 7은 도 6의 단계 11과 동일할 수 있다.

제4 예에서, R-DST를 통한 DST 생성이 논의된다. 이전 3개의 예에서, DST-1의 원시 데이터는 단일 LFA-1로부터 오는 것으로 가정되었다. 이 예에서, DST-1의 원시 데이터가 복수의 LFA들로부터 올 수 있는 더 진보된 시나리오가 고려된다. 이 경우, DST-1은 R-DST일 수 있고, 이는 복수의 S-DST로 분할될 수 있다. 특히, DST-1이 (예를 들어, 도 6 내지 도 8의 단계 3에서) 생성된 후, DSCS 에이전트-1은 어느 LFA들이 관여되는지를 알아낼 수 있고, S-DST는 관여된 LFA들 각각에 대해 추가로 생성될 수 있다. 각각의 S-DST에서, 이들 DE들의 원시 데이터가 이 S-DST의 대응하는 LFA로부터 수집될 것인 경우에만 DE들을 포함한다.

도 9는 R-DST 분할에 의한 DST 생성 프로세스에 대한 예시적인 절차를 도시한다:

단계 1에서, DSCS 에이전트-1은 사용자-1로부터 DST 생성 요청을 수신하고, DST-1이 생성되었다. 이 단계는 도 6 내지 도 8의 단계 3에 대응한다. 다음으로, DSCS 에이전트-1은 또한 어느 LFA들(예컨대, 이 예에서는 LFA-1 및 LFA-2)이 이 DST-1에 관여되는지를 결정한다.

단계 2에서, DST-1은 2개의 S-DST(예컨대, LFA-1에 대한 S-DST-1 및 LFA-2에 대한 S-DST-2)를 생성함으로써 추가로 분할되었다. DSCS 에이전트-1은 DST-1, S-DST-1 및 S-DST-2에서 관련 파라미터들을 구성한다. 예를 들어, S-DST-1 및 S-DST-2의 파라미터들은 다음의 예시적인 설정들을 가질 수 있다:

DST_Initiator: 개시자가 사용자-1이었던 그 부모 R-DST(예컨대, DST-1)에 기반하여 2개의 S-DST가 생성되기 때문에, 이들 2개의 S-DST의 DST 개시자는 또한 사용자-1일 수 있다.

DST_Users: 동일한 이유로, 이들 2개의 S-DST의 DST 사용자는 또한 이 예에서 사용자-1일 수 있다.

Type_of_DST: S-DST

Targeted_Region: S-DST-1에 대해, 그 표적화된 영역은 LFA-1일 수 있는 반면, S-DST-2의 표적화된 영역은 LFA-2일 수 있다.

Parent_DST_ID: S-DST-1 및 S-DST-2 모두의 부모 DST ID는 DST-1일 수 있다.

Creating_DSCS_Agent_ID: 이 예에서 DSCS 에이전트-1이다.

Data_Sample_Frequency: DST-1에서의 대응하는 설정과 동일하다.

DST_Status: DST-1에서의 대응하는 설정과 동일하다.

RDS_Production_Schedule: DST-1에서의 대응하는 설정과 동일하다.

RDS_Production_Trigger: DST-1에서의 대응하는 설정과 동일하다.

RDS_Context: DST-1에서의 대응하는 설정과 동일하다.

단계들 3a 및 3b에서, 각각의 S-DST에 대해, DS 식별 프로세스가 대응하는 LFA에서 수행될 수 있다(S-DST-1에 대한 단계 3a 및 S-DST-2에 대한 단계 3b). 이 단계의 경우, 도 6 내지 도 8과 관련하여 개시된 방법들이 완전히 재이용될 수 있다. 예를 들어, DSCS 에이전트-1은 LFA-1에서 DSCS 에이전트-2에 DS 식별 요청을 전송할 수 있거나, DSCS 에이전트-1은 DST 저장소에 저장된 기존의 DST들에서의 DE들을 재이용할 수 있다. 일단 DS 식별 프로세스들이 행해지면, DSCS 에이전트-1은 (예컨대, 이들 DST들의 상태들을 실행가능한 것으로 마킹하기 위해) DST-1, S-DST-1, 및 S-DST-2에서 관련 파라미터들을 추가로 구성할 수 있고, 이들을 필드에 배치할 준비가 되어 있다.

다음의 단계들(예컨대, LFA-1에 대한 단계들 4-6 및 LFA-2에 대한 단계들 7-9)은 일부 추가의 구성들의 추가를 갖는 이전의 도면들(예컨대, 도 6의 단계들 8-10)에서의 DST 필드 배치 관련 단계들과 유사하다. 대안적으로, LFA-1에 대한 단계들 4-6은 LFA-2에 대한 단계 7-9와 동시에 또는 그 후에 행해질 수 있다.

단계 4에서, DSCS 에이전트-1은 필드 배치를 위해 LFA-1에서 DSCS 에이전트-2에 S-DST-1을 전송한다.

단계 5에서, DSCS 에이전트-2는 S-DST-1에 대한 작업 스레드를 셋업하기 위한 구성들을 수행한다. 데이터가 처리되는 곳에 관한 일부 추가 구성들은 또한 단계 10에서 설명된 바와 같은 상세들에 기반하여 행해진다.

단계 6에서, DSCS 에이전트-2는 S-DST-1의 필드 배치가 셋업되는 것을 확인응답한다.

단계 7에서, DSCS 에이전트-1은 배치를 위해 LFA-2에서 DSCS 에이전트-3에 S-DST-2를 전송한다.

단계 8에서, DSCS 에이전트-3은 S-DST-2에 대한 작업 스레드를 셋업하기 위한 구성들을 수행한다. 데이터가 처리되는 곳에 관한 일부 추가 구성들은 단계 10에서 설명된 바와 같은 상세들에 기반하여 수행될 수 있다.

단계 9에서, DSCS 에이전트-3은 S-DST-2의 필드 배치가 완료되었음을 확인응답한다.

단계 10에서, DSCS 에이전트-1은 배치를 위해 FN의 DSCS 에이전트-4에 DST-1을 전송한다. DST-1이 복수의 S-DST로 분할되었을 때, RDS 생성 동안 데이터 처리가 수행되어야 하는 방법이 결정될 필요가 있을 수 있다.

일 예에서, DST-1은 R-DST일 수 있고, 그 필드내 관리자는 FN 상의 DSCS 에이전트-4일 수 있다. 특히, DST-1이 이미 2개의 S-DST로 분할되었기 때문에 DST-1에 대해 개시된 DS 식별 프로세스가 없을 수 있고, S-DST-1 및 S-DST-2에 대해서는 DS 식별이 수행될 수 있다. DSCS 에이전트-4는 특정 데이터 처리 동작들에만 관련될 수 있고, DST-1의 최종 RDS들은 DSCS 에이전트-4에서 생성될 수 있다.

다른 예에서, 필드내 관리자들은 각각 S-DST-1 및 S-DST-2에 대한 DSCS 에이전트-2 및 DSCS 에이전트-3일 수 있다. 이들 필드내 관리자들은 각각 대응하는 LFA들(예컨대, LFA-1 및 LFA-2)에서 S-DST-1 및 S-DST-2에 대한 DS 식별 프로세스를 담당할 수 있다. 그러나, S-DST에서의 특정 DE에 대해, DE-1에 대한 RDS 생성 프로세스들을 수행하는 것은 다음의 3가지 경우(예컨대, Case_1, Case_2 및 Case_3) 중 하나 이상을 포함할 수 있다:

Case_1에서, DE의 Data_Processing_Operation 파라미터들은 S-DST에서 설정되었고, 이 S-DST-1의 필드내 관리자는 또한 이 DE의 원시 데이터가 "완전히 처리"되는 위치일 수 있다. 이것은 필드내 관리자가 이 DE만을 포함하는 불완전한 RDS들을 생성할 수 있다는 것을 의미한다. 그 후, 이 S-DST의 필드내 관리자는 그 불완전한 RDS들을 그 부모 R-DST의 필드내 관리자로 전송할 수 있고, R-DST의 최종 RDS들은 상이한 LFA들로부터 수집된 불완전한 RDS들을 조립함으로써 생성될 수 있다.

도 10은 Case_1에 대한 예시적인 구현을 도시한다. 이 예에서, DST-1은 2개의 DE(예를 들어, DE-1 및 DE-2)를 갖는다. 예를 들어, DST-1의 RDS는 (DE-1, DE-2, RDS_Context)의 형태를 갖는다. 특히, DE-1 및 DE-2는 각각 마지막 3분에서의 LFA-1 및 LFA-2의 최대 온도이다. 따라서, DST-1은 2개의 S-DST(예컨대, S-DST-1 및 S-DST-2)로 분할되었다. 이들 2개의 S-DST는 LFA-1 내의 DSCS 에이전트-2 및 LFA-2 내의 DSCS 에이전트-3 상에 배치되었다. R-DST(예컨대, DST-1 자체)는 상위 레벨 FN의 DSCS 에이전트-4 상에 배치된다. DE-1 및 DE-2가 각각의 LFA들에서의 최대 온도를 계산하는데만 이용될 수 있기 때문에, LFA-1 및 LFA-2로부터 수집된 원시 데이터는 각각 DSCS 에이전트-2 및 DSCS 에이전트-3에 의해 완전히 처리될 수 있다. 다시 말해서, 각각의 LFA들에서의 최대 온도는 DSCS 에이전트-2 또는 DSCS 에이전트-3에서 직접 계산될 수 있다. 그 후, DSCS 에이전트-2는 불완전한 RDS(예를 들어, DE-1 부분에 대한 완전히 처리된 데이터)를 DSCS 에이전트-4(DSCS 에이전트-3과 동일함)로 전송할 수 있다. 마지막으로, DSCS 에이전트-4는 RDS_context에서의 정보에 기반하여 DSCS 에이전트-2로부터의 하나의 데이터 조각 및 DSCS 에이전트-3으로부터의 하나의 데이터 조각을 조립함으로써 DST의 각각의 단일 RDS를 생성할 수 있다.

Case_2에서, DE의 Data_Processing_Operation 파라미터들은 S-DST에서 설정되었고, 그 필드내 관리자는 원시 데이터에 대한 일부 데이터 처리를 수행할 수 있다. 그러나, 원시 데이터는 단지 "부분적으로 처리"될 수 있다. 그 후, 이 S-DST의 필드내 관리자는 부분적으로 처리된 데이터를 그 부모 R-DST의 필드내 관리자로 전송할 수 있고, 여기서 최종 RDS들은 상이한 LFA들로부터 수집된 부분적으로 처리된 데이터를 추가로 처리함으로써 생성될 수 있다.

도 11은 Case_2에 대한 예시적인 구현을 도시한다. 이 예에서, DST-1은 하나의 DE(예컨대, DE-1)만을 가지며, DST-1의 RDS는 (DE-1)의 형태를 갖는다. 특히, DE-1은 마지막 3분에서의 전체 시내 영역(이는 LFA-1 및 LFA-2에 의해 커버됨)의 최대 온도이다. 이 경우, DST-1은 또한 2개의 S-DST(예컨대, S-DST-1 및 S-DST-2)로 분할되었다. 이들 2개의 S-DST는 LFA-1 내의 DSCS 에이전트-2 및 LFA-2 내의 DSCS 에이전트-3 상에 배치되었다. R-DST(예컨대, DST-1 자체)는 상위 레벨 FN의 DSCS 에이전트-4 상에 배치된다. DE-1이 LFA-1 및 LFA-2 둘 모두를 커버하는 전체 영역에 대한 최대 온도를 계산하기 때문에, LFA-1 및 LFA-2로부터 수집된 원시 데이터는 각각 DSCS 에이전트-2 및 DSCS 에이전트-3에 의해 부분적으로만 처리될 수 있다. 예를 들어, DSCS 에이전트-2는 LFA-1로부터 수집된 원시 데이터를 처리할 수 있으며, 이것이 전체 영역(DSCS 에이전트-3에 대해 동일함)에 대한 최대 온도가 아니기 때문에 부분적으로 처리된 데이터인 LFA-1의 최대 온도만을 계산할 수 있다. DSCS 에이전트-4에서, 수집된 부분적으로 처리된 데이터에 기반하여 추가적인 데이터 처리가 필요할 수 있다. 예를 들어, 동일한 시간 간격 동안 LFA-1 및 LFA-2로부터 수집된 2개의 최대 온도 데이터가 주어지면, 이들 2개의 값 중 가장 큰 것이 전체 영역에 대한 최종 최대 온도일 수 있으며, 이는 DE-1에 대한 완전히 처리된 데이터일 수 있다.

Case_3에서, DE의 Data_Processing_Operation 파라미터들은 S-DST에서 설정되지 않았고, 그 필드내 관리자는 단순히 이 DE의 모든 원시 데이터를 그 부모 R-DST의 필드내 관리자에게 전달할 수 있고, 이는 예를 들어 상위 레벨 포그 노드 상의 DSCS 에이전트일 수 있다. 다시 말해서, 모든 원시 데이터는 R-DST의 필드내 관리자에서 처리될 수 있다.

도 11에 도시된 바와 같이 Case_2에 대한 동일한 예를 여전히 이용한다. 이때, DSCS 에이전트-2 및 에이전트-3은 충분한 데이터 처리 능력을 갖지 않을 수 있다. 따라서, S-DST-1 및 S-DST-2에서의 DE들의 Data_Processing_Operation 파라미터들은 설정되지 않을 수 있다. 이러한 구성을 통해, DSCS 에이전트-2 및 에이전트-3은 임의의 데이터 처리에 관여하지 않을 수 있다. 대신에, 이들은 모든 원시 데이터를 DSCS 에이전트-4로 직접 전달할 수 있다. DSCS 에이전트-4는 모든 데이터 처리를 수행하고 DST-1에 대한 RDS들을 생성하는 것일 수 있다.

일반적으로, DSCS 에이전트-4는 포그 계층구조 내의 LFN들보다 높은 임의의 노드 상에 호스팅될 수 있다. 일 예에서, DSCS 에이전트-4는 심지어 루트 CN 노드에 있을 수 있다(이 경우, DSCS 에이전트-4는 DSCS 에이전트-1과 동일하다). 전반적으로, DSCS 에이전트-4를 가능한 한 많이 에지에 배치하는 이점은 잠재적인 처리 및 통신 오버헤드를 절감하기 위해 로컬/분산 데이터 처리를 가능하게 한다는 것이다.

도 9로 돌아가면:

단계 11에서, FN 상의 DSCS 에이전트-4는 DST-1에 대한 작업 스레드를 셋업하기 위한 구성들을 수행한다.

단계 12에서, DSCS 에이전트-4는 DST-1의 필드 배치가 완료되었음을 확인응답한다. 이 단계 후에, DSCS 에이전트-1은 DST-1이 성공적으로 생성되었고 실행가능함을 DST-1의 사용자에게 확인응답할 수 있다.

도 9 내지 도 11은 DSCS 사용자들이 클라우드측으로부터인 것인 반면, IoT 원시 데이터 수집 및 처리가 LFA들에서 행해지는 예시적인 시나리오를 이용한다는 점에 유의한다. 사용자들이 LFA들과 직접 상호작용할 수 있는 추가적인 또는 대안적인 시나리오들이 이용될 수 있다는 것이 이해된다. 예를 들어, 이동 차량에 앉아 있는 사용자는 어떤 실시간 도시 날씨 및 오염 분석/모니터링 차트들을 보기를 원할 수 있다. 이 경우, 원하는 RDS들을 수집하기 위해, 사용자는 도로변 유닛 상에 호스팅된 DSCS 에이전트에 요청을 직접 전송할 수 있다. 사용자는 그들의 RDS 데이터 샘플 수집 요청을 FLA들에서의 DSCS 에이전트들에 직접 전송할 수 있다.

어느 DST 생성 접근법이 채택되는지에 상관없이, DS 식별은 DST에 대한 원하는 DS들을 식별하는 것일 수 있는 중요한 프로세스라는 것이 이해된다. DST는, 원하는 DS들이 이 DST에서의 모든 DE들에 대해 식별될 수 있는 경우에만 실행가능한 상태에 있을 수 있다. 특히, 주어진 실행가능한 DST에 대해, DSCS 에이전트는 필드에서의 DS들의 이용가능성들에 대한 동적 변경들이 존재할 수 있다는 사실을 고려하여, 모든 식별된 DS들이 여전히 이용가능한지 그리고/또는 원하는 품질 요건들을 충족시키는지를 추적할 필요가 있을 수 있다. 그렇지 않다면, 실행가능한 DST는 실행불가능한 DST가 될 수 있고, 새로운 DS 식별이 수행될 필요가 있을 수 있다.

DST 업데이트 및 삭제 프로세스를 위한 다수의 해결책이 개시된다. DST(및 그 관련 S-DST들)가 업데이트/삭제되는 경우, 이 DST는 먼저 "활성화된" 상태가 아니라 "실행가능한" 상태에 있을 필요가 있을 수 있다는 점에 유의한다. 다시 말해서, 활성화된 DST는 이 DST에 대해 임의의 DST 업데이트/삭제 프로세스를 수행하기 전에 먼저 비활성화될 필요가 있을 수 있다.

도 12는 기존의 DST(예컨대, DST-1)에 하나 이상의 새로운 DE를 추가하기 위한 DST 업데이트 프로세스에 대한 예시적인 절차를 도시한다. 이 예는 또한 기존의 DST에서 일부 정보를 업데이트하는데 이용될 수 있다는 점에 유의한다.

전제 조건으로서, DST-1은 사용자-1에 의해 생성되었고, DST-1의 RDS는 2개의 DE(예컨대, DE-1 및 DE-2)를 갖는다. DST-1은 2개의 S-DST(예컨대, S-DST-1 및 S-DST-2)로 분할되었고, 이는 LFA-1 내의 DSCS 에이전트-2 및 LFA-2 내의 DSCS 에이전트-3 상에 배치되었다(이것은 도 12에 도시되지 않음). 특히, S-DST-1은 DE-1 부분에 관련된 RDS들을 생성하는 것을 담당하는 반면, S-DST-2는 DE-2 부분에 관련된 RDS를 생성하는 것을 담당한다.

단계 1에서, 새로운 요구로 인해, 사용자-1은 기존의 DST-1에 하나 이상의 새로운 DE를 추가하려고 의도한다. 예를 들어, 기존의 DE-1 및 DE-2에 추가하여, 사용자-1은 또한 DE-3 및 DE-4를 DST-1에 추가하기를 원한다. 다시 말해서, 업데이트된 DST-1의 RDS는 (DE-1, DE-2, DE-3, DE-4, RDS_Context)의 형태를 가질 수 있다.

단계 2에서, 사용자-1은 필요한 정보와 함께 DST 업데이트 요청을 DSCS 에이전트-1에 전송한다. 특히, 메시지는 (예를 들어, 표 1에 도시된 바와 같은) 다음의 관련 파라미터들을 포함할 수 있다:

DST_ID: 이 파라미터는 어느 기존의 DST가 업데이트될 것인지를 표시한다.

Targeted_Region: 추가될 새로운 DE들이 표적화된 영역의 변경으로 이어지면, 이 파라미터는 또한 업데이트될 필요가 있을 수 있다. 예를 들어, DST-1에서의 이 파라미터에 이미 포함된 LFA-1 및 LFA-2에 더하여, 새로운 LFA-3이 관여될 수 있는데, 그 이유는 추가될 새로운 DE들의 부분이 LFA-3으로부터 수집될 수 있기 때문이다.

추가될 DE들 각각은 이 DE에 대한 상세들을 정의하는 다음의 파라미터들을 가질 수 있다:

Raw_Data_Type;

Unit;

Data_Processing_Operation;

Customized_Processing_Details; 및

Quality_Requirements.

새로운 DE들을 추가하는 대신에, 사용자-1은 단지 기존의 DST에서 일부 정보를 업데이트하기를 원할 수 있다(예컨대, 새로운 DE들을 추가하지 않음). 이 경우, 메시지는 다음과 같은 관련 파라미터들을 포함할 수 있다:

New_Parameter_Values: 이것은 업데이트될 파라미터들 및 그 새로운 값들을 포함한다.

단계 3에서, DSCS 에이전트-1은 먼저 DST-1(및 그 관련된 S-DST들)이 "활성화된" 상태에 있는지를 체크한다. 그렇다면, DSCS 에이전트-1은 먼저 DST-1(및 그 관련된 S-DST들)을 비활성화할 필요가 있을 수 있다. 그 후, 상이한 애플리케이션 시나리오들에 기반하여, DSCS 에이전트-1은 그 새로운 DE들을 추가하기 위한 적절한 동작들을 추가로 수행할 수 있다. 일반적으로, 아래에 상세히 설명되는 바와 같이 2개의 예시적인 사례가 있을 수 있다:

Case_1에서, DST-1은 다음 시나리오들을 위해 업데이트될 수 있다:

DST-1은 전술한 바와 같이 시나리오 1 하에서 생성되었고, 여기서 LFA들에서의 DSCS 에이전트들은 DST 생성 요청이 있을 때에만 DS 식별을 수행하기 시작한다. 이 사례에서, DS 식별을 위한 도 6에 도시된 절차의 단계들 3-6은 추가될 새로운 DE들에 대해 수행될 수 있다.

DST-1은 전술한 바와 같이 시나리오 2 하에서 생성되었고, 여기서 LFA들에서의 DSCS 에이전트들은 DST 생성 요청이 없더라도 DS 식별을 사전에 수행할 수 있다. 이 사례에서, DS 식별을 위한 도 7에 도시된 절차의 단계 3은 추가될 새로운 DE들에 대해 수행될 수 있다.

DST-1은 전술한 바와 같이 시나리오 3 하에서 생성되었고, 여기서 DST 저장소가 존재하고, 기존의 DST들 내의 하나 이상의 DE가 잠재적으로 재이용될 수 있다. 이 사례에서, DS 식별을 위한 도 8에 도시된 절차의 단계들 3-5는 추가될 새로운 DE들에 대해 수행될 수 있다.

DST-1은 전술한 바와 같이 시나리오 4 하에서 생성되었으며, 여기서 DST는 복수의 S-DST로 분할될 수 있다. 이 사례에서, DS 식별을 위한 도 9에 도시된 절차의 단계들 3은 추가될 새로운 DS들에 대해 수행될 수 있다. 도 12에 도시된 단계 3 이후의 나머지 단계들은 주로 이 시나리오에 기반한다는 점에 유의한다. 예로서, DE-3에 대한 원시 데이터는 LFA-2로부터 수집될 수 있다고 가정된다. 따라서, 기존의 S-DST-2는 새롭게 추가된 DE-3을 통합함으로써 업데이트될 수 있고, 업데이트된 S-DST-2는 또한 S-DST-2의 필드내 관리자에 배치될 필요가 있을 수 있다. 한편, 새로운 S-DST-3이 생성될 수 있는데, 그 이유는 DE-4에 대한 원시 데이터가 새로운 LFA-3으로부터 수집될 수 있기 때문이다. 따라서, S-DST-3은 필드 배치를 위해 LFA-3에서의 DSCS 에이전트-5로 전송될 수 있다. 또한, DST-1 자체는 또한 현재 DST-1이 3개의 S-DST로 분할되었기 때문에 업데이트될 필요가 있을 수 있고, 업데이트된 DST-1은 또한 필드 배치를 위해 DSCS 에이전트-4로 전송될 필요가 있을 수 있다.

Case_2에서, DST-1은 업데이트될 수 없다. DST-1은 사용자-1로부터의 DST 업데이트 요청으로 인해 업데이트되지 않을 수 있다는 점에 주목할 가치가 있다. DST-1이 현재 둘 이상의 사용자(예컨대, 단지 사용자-1에 의한 것만이 아님)에 의해 이용되고 있을 수 있는 것이 가능할 수 있다. 따라서, DST-1이 다른 사람들의 인식 없이 수정되면, 업데이트된 DST-1에 의해 생성된 RDS들은 사용자-1 이외의 사용자들에 의해 이해되지 않을 수 있다. 이 사례에서, Case_1에 도시된 바와 같은 임의의 동작들을 행하기 전에, 다음의 동작들이 먼저 수행될 필요가 있을 수 있다:

DSCS 에이전트-1은 DST-1의 DST_Users 파라미터에 표시된 바와 같이 DST-1의 모든 사용자들에 대해 체크할 필요가 있을 수 있다. DST-1은 모든 사용자들이 DST-1을 업데이트하는 것에 동의하는 경우에만 업데이트될 수 있다.

DST-1의 사용자들 모두가 DST-1의 업데이트에 동의하지 않는 경우, 이 업데이트 요청은 거부될 수 있다. 대안적으로, 다른 진보된 해결책은 DST-2의 DST_Users 파라미터가 사용자-1(사용자-1은 또한 DST-1의 사용자 리스트로부터 삭제될 수 있음)만을 포함할 수 있다는 점을 제외하고는, DST-1의 정확한 복제일 수 있는 새로운 DST-2를 생성하는 것이다. 그 다음, 새로운 DE들이 DST-2에 추가될 수 있다. 이 새롭게 생성된 DST-2에 의해, DSCS 에이전트-1은 추가로 DST-2를 복수의 S-DST로 분할할 수 있다. 따라서, DST-2의 이들 S-DST들을 배치할 때, 그 대응하는 작업 스레드들은 관련 LFA들의 필드내 관리자들에 의해 셋업될 수 있다. DST-2에서의 주어진 S-DST-X에 대해, 특정 구현들에 따라, DST-1에서의 S-DST-X의 작업 스레드는 완전히 재이용될 수 있고, 새로운 작업 스레드는 (이들 2개의 S-DST가 정확히 동일하기 때문에) 필요하지 않을 수 있다. 그러나, DST-2에서의 S-DST-X가 DST-1에서의 S-DST-X에 비해 새로운 DE들을 갖는다면, DST-1에서의 S-DST-X의 기존의 작업 스레드에 기반하여 새로운 작업 스레드가 구축될 수 있다.

새로운 DE들을 추가하는 대신에, 사용자-1은 (예를 들어, 하나 이상의 DE를 추가하는 것이 아니라) 단지 기존의 DST에서 일부 정보를 업데이트하기를 원할 수 있다. 이 경우, 위의 해결책들이 또한 재이용될 수 있다. 예를 들어, 사용자-1은 DST-1의 Data_Sample_Frequency 파라미터 또는 DST-1에서의 DE-1의 Quality_Requirements를 업데이트하고자 하는 경우, 이러한 파라미터들의 새로운 값들에 순응하도록 하기 위해 새로운 DS 식별 프로세스가 수행되도록 또한 트리거링할 수 있다. 일단 이러한 파라미터들이 업데이트되면, 업데이트된 DST-1은 재배치될 수 있고, 따라서 DST-1의 대응하는 작업 스레드는 최신/업데이트된 DST-1에 따라 동작하기 시작할 수 있다. 그러나, DST-1이 현재 다른 사용자들에 의해 공유된다는 사실로 인해 이러한 파라미터들에 대한 업데이트들이 행해질 수 없다면, 업데이트 요청은 거부될 수 있거나, 새로운 DST(들)가 생성될 수 있고, 이는 위에서 논의된 바와 같이 이러한 파라미터들의 새로운 값들을 포함한다.

Case_1과 관련하여 하나 이상의 새로운 DE를 추가할 때, 단계들 4-6은 단계 3 동안 하나 이상의 DE를 추가함으로써 DST-1이 업데이트되는 것으로 가정하는 단계들을 예시한다:

단계 4에서, DSCS 에이전트-1은 하나 이상의 새롭게 추가된 DE가 포함된 LFA-2에서의 DSCS 에이전트-3에 업데이트된 S-DST-2를 배치한다. 도 9의 단계들 7-9는 재이용될 수 있다.

단계 5에서, DSCS 에이전트-1은 LFA-3에서의 DSCS 에이전트-5에 새로운 S-DST-3을 배치한다.

단계 6에서, DSCS 에이전트-1은, 모든 새롭게 추가된 DE들이 포함된 FN 상의 DSCS 에이전트-4에 업데이트된 DST-1을 배치한다. 마찬가지로, 도 9의 단계들 10-12는 재이용될 수 있다.

Case_2의 경우, DST-1이 업데이트될 수 없고, 새로운 DST-2가 단계 3 동안 생성되는 경우, 새롭게 생성된 DST-2뿐만 아니라 그 관련된 S-DST들을 적절한 LFA들 또는 FN들에 배치하는 것이 행해질 필요가 있을 수 있다. 이 경우, DST 업데이트 프로세스는 DST 생성 프로세스로 변환된다.

단계 7에서, DSCS 에이전트-1은 DST-1이 업데이트되었음을 확인응답한다. 또는, 단계 3 동안 새로운 DST-2가 생성된다면, DSCS 에이전트-1은 사용자-1에게 새로운 DST가 그 새로운 요구를 서빙하기 위해 생성된다는 것을 알릴 수 있다. 이전에 DST-1이 단계 3 전에 "활성화된" 상태에 있었던 경우, DST-1은 재활성화될 수 있다.

기존의 DST에서 하나 이상의 DE를 삭제하거나 전체 DST를 삭제하기 위한 DST 업데이트 프로세스가 개시된다. 개시된 해결책은 DST 생성 프로세스 동안 논의된 바와 같은 상이한 시나리오들에 적용될 수 있다는 점에 유의한다.

도 13은 기존의 DST에서 하나 이상의 DE를 삭제하기 위한 DST 삭제 프로세스에 대한 예시적인 절차를 도시하고(이 절차는 또한 전체 DST를 삭제하는데 이용될 수 있음), 그 상세한 설명들은 다음과 같이 논의된다:

전제 조건으로서, DST-1이 사용자-1에 의해 생성되었고, DST-1의 RDS가 4개의 DE(예컨대, DE-1, DE-2, DE-3 및 DE-4)를 갖는다고 가정된다. DST-1은 2개의 S-DST(S-DST-1 및 S-DST-2)로 분할되었고, 이들은 LFA-1 내의 DSCS 에이전트-2 및 LFA-2 내의 DSCS 에이전트-3 상에 배치되었다. 특히, S-DST-1은 DE-1에 대한 RDS를 생성하는 것을 담당하는 반면, S-DST-2는 DE-2, DE-3, 및 DE-4에 대한 RDS를 생성하는 것을 담당한다(완전한 RDS들은 FN 상의 DSCS 에이전트-1에 의해 조립될 수 있다). DST-1 및 S-DST-2는 도 13에 도시된 예에서 주요 초점일 것이다.

단계 1에서, 새로운 요구로 인해, 사용자-1은 기존의 DST-1로부터 하나 이상의 DE를 삭제하려고 의도한다. 예를 들어, 사용자-1은 DST-1로부터 DE-3 및 DE-4를 삭제하기를 원한다.

단계 2에서, 사용자-1은 필요한 정보와 함께 DST 삭제 요청을 DSCS 에이전트-1에 전송한다. 특히, 메시지는 (예를 들어, 표 1에 도시된 바와 같이) 다음의 관련 파라미터들을 포함할 수 있다:

Deletion_List: 이것은 삭제될 DE들의 리스트이다. 전체 DST가 삭제될 것인 경우, 이 파라미터는 "모두"로 설정될 수 있다.

단계 3에서, DSCS 에이전트-1은 먼저 DST-1(및 그 관련된 S-DST들)이 "활성화된" 상태에 있는지를 체크한다. 그렇다면, DSCS 에이전트-1은 먼저 DST-1(및 그 관련된 S-DST들)을 비활성화할 필요가 있을 수 있다. 상이한 애플리케이션 시나리오들에 기반하여, DSCS 에이전트-1은 이들 DE들을 삭제하기 위한 적절한 동작들을 추가로 수행할 수 있다. 일반적으로, 삭제 리스트에서의 주어진 DE의 경우, 이것은 다음의 3가지 사례를 가질 수 있다:

Case_1의 경우, DST-1에서의 DE(예컨대, DE-3)가 삭제될 수 있고, 대응하는 동작들이 대응하는 LFA에서 취해질 필요가 있다. 이것은 다음의 가능한 시나리오들에서 발생한다:

1. 사용자-1은 DST-1의 유일한 사용자이고, 한편 DE-3은 임의의 다른 DST들에서도 결코 재이용되지 않았거나;

2. 사용자-1은 DST-1의 유일한 사용자이고, 이 DE-3은 다른 DST에서 초기에 생성된 재이용된 DE이다. 이 경우, DE-3을 삭제하고 업데이트된 S-DST-2를 LFA-2에서의 DSCS 에이전트-3에 배치함으로써 DST-1 및 S-DST-2를 업데이트하는 것이 필요할 수 있다.

Case_2의 경우, DST-1에서의 DE(예컨대, DE-4)가 삭제될 수 없고, 새로운 DST가 생성된다. 이것은 DST-1이 현재 둘 이상의 사용자들(예컨대, 단지 사용자-1에 의한 것만이 아님)에 의해 이용될 수 있는 시나리오에서 발생한다. 따라서, DST-1이 다른 사람들의 인식 없이 수정되면, 업데이트된 DST-1에 의해 생성된 RDS들은 사용자-1 이외의 사용자들에 의해 이해될 수 없다. 이 경우, 위에 도시된 바와 같이 임의의 동작들을 행하기 전에, 다음과 같은 동작들이 먼저 수행될 필요가 있다:

DSCS 에이전트-1은 DST-1의 DST_Users 파라미터에 표시된 바와 같이 DST-1의 모든 사용자들에 대해 체크할 필요가 있다. DST-1은 모든 사용자들이 DST-1을 업데이트하는 것에 동의하는 경우에만 이들 DE들을 삭제하기 위해 업데이트될 수 있다.

DST-1의 사용자들 모두가 DST-1로부터 DE들을 삭제하는데 동의하지 않는 경우, 삭제 요청은 거부될 수 있다. 대안적으로, 다른 해결책은 DST-2의 DST_Users 파라미터가 사용자-1(사용자-1은 또한 DST-1의 사용자 리스트로부터 삭제될 수 있음)만을 포함할 수 있다는 점을 제외하고는, DST-1의 정확한 복제일 수 있는 새로운 DST-2를 생성하는 것이다. 그 다음, 관련된 DE들은 DST-2로부터 삭제될 수 있다. 이 새롭게 생성된 DST-2에 의해, DSCS 에이전트-1은 추가로 DST-2를 복수의 S-DST들로 분할하고 필드 배치를 위해 이들을 전송할 수 있다.

Case_3의 경우, DST-1에서의 DE는 삭제될 수 없다. 이것은 사용자-1이 DST-1의 유일한 사용자이지만 이 DE가 다른 DST들에서 재이용되었던 시나리오에서 발생한다. 이 경우, 어떠한 동작도 이 DE에 대해 구체적으로 행해질 필요가 없다.

전반적으로, DSCS 에이전트-1은 삭제될 DE들 각각을 체크할 수 있다. 이들 중 임의의 하나가 위에 언급된 바와 같이 Case_2에 속하면, 새로운 DST가 생성될 수 있다. 그렇지 않고, 삭제될 DE들 모두가 Case_1 또는 Case_3에만 속하는 경우, 원래의 S-DST-2는 삭제될 이들 DE들 각각에 대한 적절한 동작들을 수행함으로써 그에 따라 수정될 수 있다.

사용자-1이 전체 DST-1을 삭제하기를 원하는 경우(예컨대, 모든 DE들을 삭제하는 경우), 전체 DST(및 대응하는 작업 스레드들)는 모든 DE들이 Case_1에 속하는 경우 실제로 삭제될 수 있다. 그렇지 않은 경우, 위의 Case_2 및 Case_3에 언급된 바와 같은 해결책들을 따를 수 있다.

단계들 4-5는 단계 3 동안 DST-1(및 S-DST-2)이 업데이트되었다고 가정하는 단계들을 예시한다.

단계 4에서, DSCS 에이전트-1은 필드 배치를 위해 LFA-2에서의 DSCS 에이전트-3에 업데이트된 S-DST-2를 전송하고, S-DST-2의 기존의 작업 스레드는 또한, S-DST-2에 대해 생성된 RDS 데이터가 삭제된 DE들을 포함하지 않을 수 있도록 수정될 수 있다.

단계 5에서, DSCS 에이전트-1은 필드 배치를 위해 FN 상의 DSCS 에이전트-4에 업데이트된 DST-1을 전송한다.

단계 3 동안 새로운 DST-2가 생성되었다면, DST-2는 물론 그 관련된 S-DST들을 적절한 LFA들에 배치할 필요가 있을 수 있고, DST 생성 프로세스에 대한 모든 이전 절차들이 재이용될 수 있다. 즉, 이 경우, DST 삭제 프로세스는 DST 생성 프로세스로 내부적으로 변환된다.

단계 6에서, DSCS 에이전트-1은 DST-1에서의 DE들 중 하나 이상이 삭제되었다는 것을 확인응답한다. 또는, 단계 3 동안 새로운 DST-2가 생성된다면, DSCS 에이전트-1은 그 요구에 기반하여 새로운 DST가 생성된다는 것을 사용자-1에게 알릴 수 있다.

주어진 DST-1에 대해, 사용자-1은 하나 이상의 기존의 DE를 동시에 삭제하면서 하나 이상의 새로운 DE를 추가하기를 원할 수 있다는 점에 주목할 가치가 있다. 이러한 경우에 대해, 도 12 및 도 13에 개시된 바와 같은 절차들은 함께 통합될 수 있다. 예를 들어, 도 12 및 도 13의 단계 2의 경우, 사용자-1은 하나 이상의 DE를 DST-1에 추가할 뿐만 아니라 DST-1로부터 하나 이상의 DE를 삭제할 필요가 있다는 것을 직접 표시할 수 있다. 이러한 DST 업데이트 요청을 수신한 후, DSCS 에이전트-1은, DE들을 추가하고 DE들을 삭제하는 것 모두를 위해 도 12 및 도 13에서 행해질 동작들을 조합할 수 있다. 이러한 방식으로, 사용자-1은 단지 하나의 DST 업데이트 요청을 전송할 수 있고, DSCS 에이전트-1은 도 12 및 도 13에 도입된 바와 같은 모든 필요한 동작들을 완료할 수 있다.

생성된 DST의 경우, 이것은 그 필드내 관리자에 배치된 후에, 여전히 활성화된 DST가 아닐 수 있다. 특히, DST의 RDS 생성 프로세스는 이 DST가 활성화될 때까지 시작되지 않는다. 도 14는 DST 상태의 상태 머신 모델을 도시한다. 예를 들어, DST는 생성되었을 때, "실행불가능한" 상태에 있을 수 있다. DS 식별이 이 DST에 대해 성공적으로 행해질 수 있다면, 이것은 "실행가능한" 상태로 변경될 수 있다. 유사하게, 실행가능한 DST의 경우, 그 원하는 DS(들) 중 임의의 것이 손실되거나 더 이상 이용가능하지 않은 경우, 이 DST는 "실행불가능한" 상태로 돌아갈 수 있고, 추가의 DS 식별이 수행될 필요가 있을 수 있다. 한편, DST 활성화 동작을 통해, 실행가능한 DST는 "활성화된" 상태에 있을 수 있고, 이는 실제 RDS 생성이 시작된다는 것을 의미한다.

일반적으로, DST를 활성화하기 위한 다수의 방식들이 있으며, 이들은 다음과 같이 열거된다(이것은 포괄적인 리스트가 아니다):

(1) 주어진 DST는 "RDS_Production_Schedule" 파라미터에 표시된 바와 같은 파라미터에 기반하여 활성화될 수 있다. 도 6에 도시된 예로서, 일단 DST-1이 LFA-1에서의 DSCS 에이전트-2에 배치되면, 이 에이전트는 DST-1에 대한 RDS 생성 스케줄을 알게 될 수 있고, 따라서 DSCS 에이전트-2는 이 스케줄에 기반하여 DST-1의 대응하는 작업 스레드를 활성화할 수 있다. 한편, DST가 활성화되거나 비활성화될 때마다, Creating_DSCS_Agent(예컨대, 도 6에 도시된 바와 같은 CN에서의 DSCS 에이전트-1) 상에 호스팅된 DST-1의 DST_Status 파라미터는 또한 그 최신 상태를 반영하기 위해 업데이트될 필요가 있을 수 있다.

한편, 주어진 DST가 분할되었으면, 위의 프로세스는 또한 그에 따라 수행될 수 있다. 도 10에 도시된 다른 예로서, DST-1은 2개의 S-DST(예컨대, S-DST-1 및 S-DST-2)로 분할되었다. 따라서, 모든 대응하는 작업 스레드들(예를 들어, FN 상의 DST-1, LFA-1에서의 LFNL 상의 S-DST-1 및 FLA-2에서의 LFNL 상의 S-DST-2에 대한 것들)은 또한 부모 R-DST(예컨대, DST-1)에서의 "RDS_Production_Schedule" 파라미터에 기반하여 활성화 또는 비활성화될 수 있다.

이 경우, 사용자가 DST를 생성하고 있을 때, 사용자는 DST 생성 요청의 전송 시에 그 RDS 전송 어드레스를 직접 제공할 수 있다(이것은 이후 "RDS_Sending_Address_List" 파라미터에 포함될 수 있다). 나중에, 다른 사용자가 또한 이러한 전체 DST를 재이용하기를 원한다면, 이 새로운 사용자는 단지 이 DST의 "DST_Users"에 그 ID를 추가함으로써 DSCS 에이전트에 요청을 전송하고, 또한 그 자신의 RDS 전송 어드레스를 "RDS_Sending_Address_List" 파라미터에 추가할 수 있다.

(2) 주어진 DST는 사용자로부터의 신호에 기반하여 활성화될 수 있다. 도 6에 도시된 예로서, "RDS_Production_Schedule" 파라미터가 임의의 값으로 설정되지 않을 수 있는 것이 가능하다. 따라서, 사용자-1은 트리거 요청을 DSCS 에이전트-1에 전송할 수 있고, DSCS 에이전트-1은 DST-1의 작업 스레드를 활성화하기 위해 LFA-1에서의 DSCS 에이전트-2에 트리거 요청을 추가로 전달할 수 있다. 대안적으로, DSCS 에이전트-1 자체는 RDS_Production_Trigger 파라미터에 지정된 바와 같은 특정 이벤트들에 기반하여 트리거 요청을 DSCS 에이전트-2에 전송할 수 있다. 예를 들어, 하나의 트리거는 DST-1의 임의의 사용자가 시스템에 로그인되는 한, DST-1이 활성화될 수 있는 것일 수 있다. 비활성화는 역방식으로 행해질 수 있다.

DST_Users 파라미터에 표시된 바와 같이 DST가 복수의 사용자에 의해 공유되는 경우, DST는 DST를 활성화 또는 비활성화하기 위한 다음의 메커니즘들을 가질 수 있다:

(표 1에 포함된 바와 같은 "DST_Status" 파라미터에 의해 표시된 바와 같이) 현재 활성화되지 않은 주어진 DST-1의 경우, 사용자-1은 앞서 언급한 바와 같이 트리거를 전송함으로써 이 DST-1을 직접 활성화할 수 있다. 특히, 이 사용자는 표 1에 도시된 바와 같이 그 RDS 전송 어드레스를 "RDS_Sending_Address_List" 파라미터에 추가할 수 있다.

나중에, DST-1의 다른 사용자-2가 또한 DST-1에 대한 RDS들을 수신하기를 원한다면, 사용자-2는 그 ID를 단지 이 DST의 "DST_Users"에 추가하고, DST-1이 이미 "활성화된" 상태에 있기 때문에 표 1에 나타낸 바와 같이 "RDS_Sending_Address_List" 파라미터에 그 RDS 전송 어드레스를 추가할 수 있다.

나중에, 사용자-1은 이제 DST-1에 대한 RDS들을 수신하기를 원하지 않으면, "RDS_Sending_Address_List" 파라미터를 검사함으로써 얼마나 많은 사용자들이 DST-1의 RDS를 현재 수신하고 있는지를 체크할 수 있다. 사용자-1이 현재 RDS들을 수신하고 있는 단지 한 명의 사용자가 아닌 경우, 사용자-1은 표 1에 도시된 바와 같이 "RDS_Sending_Address_List" 파라미터로부터 그 RDS 전송 어드레스를 단지 제거할 수 있다. 사용자-1이 DST-1에 대한 RDS들을 영구적으로 수신하기를 원하지 않는다면, 사용자-1은 "DST_Users" 파라미터로부터 그 ID를 추가로 제거할 수 있다.

사용자-2는 이제 DST-1에 대한 RDS들을 수신하기를 원하지 않는 경우, "RDS_Sending_Address_List" 파라미터를 검사함으로써 얼마나 많은 사용자들이 DST-1의 RDS를 현재 수신하고 있는지를 체크할 수 있다. 이제 사용자-2가 현재 DST-1의 RDS들을 수신하고 있는 단지 한 명의 사용자인 것을 알기 때문에, 사용자-2는 표 1에 도시된 바와 같이 "RDS_Sending_Address_List" 파라미터로부터 그 RDS 전송 어드레스를 제거할 뿐만 아니라, 이러한 DST-1을 실제로 비활성화시킬 수 있다(다시 말해, DST-1은 이 때에 실제로 비활성화될 수 있다). 사용자-2가 DST-1에 대한 RDS들을 영구적으로 수신하기를 원하지 않는다면, 사용자-2는 "DST_Users" 파라미터로부터 그 ID를 추가로 제거할 수 있다(특히, 사용자-2가 제거되고, "DST_Users"에 포함된 사용자가 없는 경우, DST-1이 비활성화되는 것이 아니라, 대신, 이 DST-1이 삭제될 수 있다).

(3) 주어진 DST는 또한 (RDS_Production_Trigger 파라미터에 표시된 바와 같이) LFA들에서 발생한 이벤트들에 기반하여 활성화될 수 있다. 도 6에 도시된 예로서, DST-1이 LFA-1에서의 실시간 잡음 레벨 모니터링과 관련된 생성된 RDS들에 대한 것인 경우, 교통 혼잡들이 LFA-1에서 검출될 때 DST-1이 그 필드내 관리자(예컨대, DSCS 에이전트-2)에 의해 활성화될 수 있는 것이 가능하다. DST-1이 활성화되면, DSCS 에이전트-2는 DST-1의 DST_Status 파라미터를 업데이트하기 위해 CN에서의 DSCS 에이전트-1에게 알릴 수 있다.

이 경우, 사용자는 DST를 생성할 때, DST 생성 요청의 전송 시에 그 RDS 전송 어드레스를 직접 제공할 수 있다(이것은 이후 "RDS_Sending_Address_List" 파라미터에 포함될 수 있다). 나중에, 다른 사용자가 또한 이러한 전체 DST를 재이용하기를 원한다면, 이 새로운 사용자는 단지 이 DST의 "DST_Users"에 그 ID를 추가함으로써 DSCS 에이전트에 요청을 전송하고, 또한 그 자신의 RDS 전송 어드레스를 "RDS_Sending_Address_List" 파라미터에 추가할 수 있다.

DST 상태가 변경될 때마다, 그 최신 상태는 DST 내의 "DST_Status" 파라미터에 반영될 수 있고, 필드 관리자들은 또한 특정 동작들을 수행할 필요가 있을 수 있다(예를 들어, 그 상태에 기반하여, 이들 DST들에 대한 대응하는 작업 스레드들을 보류/재개한다).

본 명세서에 개시된 방법들 및 시스템들은 아래 논의되는 바와 같이 oneM2M 기능적 아키텍처 실시예에서 구현될 수 있다.

개시된 DSCS 해결책은, 도 15에 도시된 바와 같이, oneM2M 서비스 계층에서의 새로운 CSF로서 간주될 수 있다. 상이한 유형들의 M2M 노드들은 IoT 디바이스들, M2M 게이트웨이들, M2M 서버들, 모바일 노드들(예컨대, 차량, 셀폰 등) 등과 같은 DSCS 서비스를 구현할 수 있다는 점이 이해되어야 한다. 특히, 이들 노드들에 대한 다양한/상이한 하드웨어/소프트웨어 능력들에 따라, 이들 노드들에 의해 구현되는 DSCS 서비스들의 능력들이 또한 변할 수 있다.

정의된 관련 엔티티들에 대한 oneM2M 실시예들은 다음과 같다:

데이터 소스(DS)는 oneM2M AE 또는 CSE일 수 있다. 따라서, AE 또는 CSE에 의해 생성되는 원시 데이터는 <container>, <timeSeries> 또는 <flexContainer> 리소스에 저장될 수 있고, 이는 DS 식별 프로세스 동안 oneM2M 리소스 발견을 통해 식별될 수 있다.

로컬 포그 노드(LFN)는 oneM2M CSE(예컨대, ASN-CSE)일 수 있고;

LFN 리더(LFNL) 및 포그 노드(FN)는 oneM2M CSE(예컨대 MN-CSE)일 수 있고;

클라우드 노드(CN)는 oneM2M CSE(예컨대 IN-CSE)일 수 있고;

DSCS 사용자는 oneM2M AE(예를 들어, IN-AE)일 수 있다.

<dscs>라고 불리는 새로운 리소스가 도 16에 도시되어 있다. <dscs>는 도 16에 도시되지 않은 서비스 계층 리소스들에 대한 공통 속성들을 포함한다. CSE는 DSCS 능력을 갖는 경우(예컨대, DSCS 에이전트가 이 CSE 상에서 실행되고 있는 경우), <dscs> 자식 리소스를 가질 수 있다. 모든 DSCS 관련 요청들은 이 리소스를 향할 수 있다. 예를 들어, 사용자는 DST 생성 요청을 CSE-1 상에서 호스팅되는 <dscs> 리소스에 전송할 수 있다. 유사하게, CSE-1은 생성된 DST-1을 배치하려고 할 때, 에지에서 다른 CSE-2에 의해 호스팅되는 <dscs> 리소스에 DST 배치 요청을 또한 전송할 수 있다.

DSCS를 노출시키기 위한 추가적인 또는 대안적인 방식은 <CSE> 리소스에 대해 정의되고 "dscs_capability"라고 불리는 새로운 속성을 이용하는 것이고, 이는 이 CSE가 DSCS 능력을 갖는지를 표시할 수 있다. 따라서, 모든 DSCS 관련 요청은 <CSEBase> 리소스를 향해 전송될 수 있다.

모든 리소스 속성들이 DST에 정의된 파라미터들에 대응하는 DST를 나타내기 위해 새로운 <dst> 리소스가 개시된다(DST에 대한 상세한 정의에 대한 표 1 참조).

<dst> 리소스는 표 2에 지정된 자식 리소스들을 포함할 수 있다.

<표 2>

위의 <dst> 리소스는 표 3에 지정된 속성들을 포함한다.

<표 3>

이하의 절차는 <dst> 리소스를 생성하는데 이용될 수 있다.

<표 4>

이하의 절차는 <dst> 리소스의 속성들을 검색하는데 이용될 수 있다.

<표 5>

이하의 절차는 <dst> 리소스의 속성들을 업데이트하는데 이용될 수 있다.

<표 6>

이하의 절차는 <dst> 리소스를 삭제하는데 이용될 수 있다.

<표 7>

<dstTriggering>는 표현을 갖지 않기 때문에 가상 리소스이다. 이것은 <dst> 리소스의 자식 리소스이다. 이 리소스는 부모 <dst> 리소스를 활성화 또는 비활성화하는데 이용된다. DST의 최신 상태는 <dst> 리소스의 "DST_status" 속성에 반영되어야 한다는 점에 유의한다.

<dstTriggering> 리소스는 부모 <dst> 리소스가 생성될 때 생성될 것이다.

검색 동작은 <dstTriggering>에 대해 적용가능하지 않을 수 있다.

업데이트 동작은 부모 <dst> 리소스를 활성화 또는 비활성화하는데 이용될 수 있다.

<표 8>

<dstTriggering> 리소스는 부모 <dst> 리소스가 호스팅 CSE에 의해 삭제될 때 삭제될 것이다. 삭제 동작은 Mca, Mcc 또는 Mcc'를 통해 적용가능하지 않다.

도 17에는, 사람 사용자가 자신의 이용에 기반하여 DST를 생성하는데 이용될 수 있는 GUI 인터페이스가 개시된다. 일반적으로, 이들 파라미터들은 DSCS 에이전트(이는 Creating_DSCS_Agent일 수 있음)에 전송될 수 있고, 여기서 DST가 그에 따라 생성될 수 있다. 즉, 이 사용자 인터페이스 상의 파라미터들은 도 6의 단계 2에서의 요청 메시지에서 운반될 파라미터들일 수 있다. 알 수 있듯이, 사용자는 표적화된 영역, RDS 생성 빈도, RDS 컨텍스트 등과 같은 전체 DST에 대한 일부 일반적인 정보를 지정할 수 있다. 한편, 사용자는 또한 DST 내의 각각의 DE에 대한 상세한 정의들을 입력할 수 있다. 사용자가 DST 내에 하나보다 많은 DE를 갖고자 하는 경우, 그/그녀는 더 많은 입력 영역이 이들 DE들에 대해 이 패널 상에 나타날 수 있도록 "더 많은 DE들 추가" 버튼을 클릭할 수 있다.

도 4에 도시된 스마트 도시 이용 사례 예를 다시 참조하면, 스마트 도시를 건설하기 위해, 도시 기관은 표준 기반 서비스 계층(SL) 플랫폼(예컨대, oneM2M)을 채택하고, 도로들/거리들, 공공 건물들, 버스들/지하철들 등과 같은 도시 공공 인프라스트럭처 상에 많은 IoT 센서들 및 디바이스들을 배치하였다. 제한된 예산으로 인해, 도시 기관은 또한 이 스마트 도시 계획에 대한 개인 조직들 및 개인들의 참여를 요청한다. 따라서, 개인 재산들(개인 자동차들, 셀폰들 등)에 설치된 이들 IoT 디바이스들은 또한 시스템 내에 통합되며, 이는 도시의 실시간 운영 상태를 반영하는 대량의 포괄적 IoT 데이터를 생성할 수 있다.

도시는 로컬 포그 영역들(LFA)이라고 지칭될 수 있는 CBD(Central Business District), 교외 주거 영역 등과 같은 많은 지리적 영역들을 가질 수 있다. 대규모 IoT 디바이스들이 이러한 LFA들에 배치될 수 있고, 대량의 IoT 데이터가 이러한 LFA들로부터 생성될 수 있다. 통신 네트워크 관점에서, 상이한 도시 영역들이 복수의 LFA를 구성한다(예컨대, 도 4에 도시된 바와 같이, CBD는 LFA-1에 대응하고, 교외 주거 영역은 LFA-2에 대응한다).

스마트 도시 제어 콘솔은 사용자들이 그들의 요구들에 기반하여 다양한 데이터 분석 요청들을 제기하게 하는 클라우드에 배치된다. 예를 들어, 조직-A로부터의 사용자는 주어진 영역(예컨대, 도 4에 도시된 바와 같이, 대규모 도로 작업 및 건물 건설 중인 영역인 LFA-X)에 대한 현재의 날씨 및 환경 오염 상태를 평가하고자 하는 데이터 샘플 수집 요청(DSCR-1로 표시됨)을 갖는다. 실제로, 데이터 분석 결과들은 일반적으로 다양한 차트들(예를 들어, 선 차트 또는 막대 차트)을 통해 표현된다. 사용자가 어떤 유형의 분석 차트들(예를 들어, 선 차트)을 보고자 하는지에 더하여, 사용자는 또한 데이터 샘플들이 어떤 것이어야 하는지, 어떤 입력들이 차트를 그리기 위한 것이어야 하는지 등을 지정할 수 있다. 차트들을 그리기 위한 이들 데이터 샘플들을 준비하기 위해, 관련된 원시 데이터는 데이터 소스들(DS들)이라고도 지칭되는 다양한 IoT 디바이스들로부터 수집될 필요가 있다. 스마트 도시 이용 사례에서, DS 예들은 온도 센서들, 습도 센서들, 오염 센서들, 잡음 센서들 등을 포함한다. 특히, 이러한 센서들 또는 디바이스들은 (사용자가 가입된) 조직-A 이외의 상이한 조직들에 의해 설치될 수 있다.

DSCR-1에서, 사용자는 LFA-X에 대한 선 차트를 보고자 하고, 매 3분마다 하나의 데이터 샘플을 요구한다고 가정할 수 있다. 특히, 각각의 데이터 샘플은 다음과 같은 2개의 데이터 요소에 의해 구성될 수 있으며, 이는 각각 품질 요건과 연관된다:

데이터 요소(DE)-1: 매 3분마다 샘플링된 LFA-X의 평균 온도이다.

DE-1의 품질 요건: 정확도를 보장하기 위해, 온도 판독치들이 LFA-X에 배치된 적어도 100개의 상이한 온도 센서로부터 수집될 필요가 있다.

DE-2: 매 3분마다 샘플링된 LFA-X의 평균 잡음 레벨이다.

DE-2의 품질 요건: 잡음 판독치들은 LFA-X에서 30개의 주요 교차로들에 배치된 잡음 센서들로부터 수집될 필요가 있다.

클라우드에 배치된 스마트 도시 제어 콘솔에 선 차트를 그리기 위해, (DE-1, DE-2, 타임스탬프)의 포맷을 갖는 데이터 샘플이 3분마다 필요할 수 있다. 이러한 데이터 샘플은 DSCR-1에 대한 RDS라고 지칭될 수 있다.

위의 이용 사례에 예시된 바와 같이 RDS들을 생성하기 위해, 대규모 IoT 원시 데이터가 LFA들에서 수집되고 처리될 필요가 있다. 포그 컴퓨팅 패러다임은 대규모 원시 데이터가 중앙집중화된 처리를 위해 클라우드측으로 이동될 필요가 없고 대신에, RDS들을 생성하기 위해 LFA들에서 처리될 수 있다는 의미에서 이러한 애플리케이션들을 지원하기 위한 좋은 맞춤이다.

사용자는 LFA들 내의 이용가능한 IoT DS들에 대한 지식을 갖지 않을 수 있다. 예를 들어, 스마트 도시 이용 사례에서, 배치된 SL 플랫폼은 또한 상이한 조직들 및 개인들로부터 많은 IoT DS들을 통합할 수 있다. 클라우드측으로부터의 사용자는 이러한 IoT DS들을 배치한 동일한 당사자가 아닐 수 있다. 사용자는 종종 (게이트웨이, 도로변 유닛들 등과 같은) 데이터 처리 능력을 갖는 LFA들에서의 많은 LFN들의 소유자가 아니고, 사용자는 통상적으로 원하는 데이터 처리 동작들에 대해 LFA들에서 임의의 LFN들을 구성하기 위한 어떠한 능력도 갖지 않는데, 그 이유는 이러한 LFN들이 상이한 당사자들 또는 조직들에 의해 소유될 수 있기 때문이다. 일부 기존의 IoT 에지 제품들(예컨대, Microsoft IoT 에지 또는 Amazon Greengrass)은 이러한 혼성 시나리오에서 효율적으로 작동할 수 없다는 점에 주목할 만하다. 예를 들어, 이러한 제품들은 사용자들이 이용가능한 DS들에 대한 완전한 지식 및 LFA들에서의 처리 노드들에 대한 완전한 구성 능력들 모두를 통상적으로 갖는 비교적 간단한 경우를 지원한다.

이러한 혼성 시나리오를 지원하기 위해, 일반적인 해결책은 IoT 시스템이 사용자들로부터 다양한 DSCR들을 수신할 수 있는 공통 데이터 샘플 수집 서비스를 제공할 수 있다는 것이다. 주어진 DSCR은 사용자가 어떤 유형의 RDS들을 수신하고자 하는지에 관한 모든 상세들을 설명한다. 그러나, 사용자는 이 DSCR을 서빙하기 위해 LFA들에서 발생하는 임의의 활동들에 참여하지 않을 수 있다. 다시 말해서, 사용자들은 단지 DSCR들을 IoT 시스템에 제출할 수 있고, 시스템은 사용자에게 RDS들을 전달하기 위한 모든 것을 처리할 것이다.

특정한 DSCR을 서빙할 때, 2개의 특정한 기술적 문제가 고려될 필요가 있을 수 있다:

DS 식별 프로세스: 주어진 DSCR에 대응하는 RDS 내의 각각의 DE에 대해, 이들이 이 주어진 DSCR에 대해 원하는 DS들인지를 결정하기 위해 발견 및/또는 평가될 필요가 있는 LFA 내의 수천 개의 잠재적인 DS들이 존재할 수 있다(이러한 프로세스는 DS 식별 프로세스라고 지칭된다). 이들 DS들을 식별하기 위해, 발견 능력들을 갖는 특정 LFN들이 이용될 수 있으며, 이는 DSD들(DS Discoverers)로서 동작할 수 있다. 예를 들어, oneM2M 시나리오에서, 리소스 발견 능력들을 갖는 임의의 AE들 또는 CSE들은 DSD로서 동작할 수 있다. 그러나, DS 식별 프로세스를 효율적인 방식으로 수행하는 것이 필수적이다. 주요 과제는 DSD들로서 동작할 수 있는 LFA들에서의 복수의 LFN들이 있을 수 있지만, 이러한 LFN들 각각은 상이한/제한된 DS 식별 능력들 또는 상이한 액세스 특권들을 가질 수 있다는 것이다. 예로서, 하나의 LFN은 특정 조직 A에 속하는 특정 DS들을 식별할 수 있는 반면 다른 LFN은 다른 조직 B에 속하는 특정 DS들만을 식별할 수 있다. 이들 LFN들 모두는 특정 DSCR을 돕기 위한 DSD들로서 동작할 수 있으며, 이는 두 개의 조직으로부터의 원하는 DS들을 식별하는데 필요할 수 있다. 따라서, LFA들에서의 복수의 LFN들이 주어진 DSCR에 대한 원하는 DS들을 식별하기 위해 이들 각각의 발견 능력들을 완전히 이용하고 통합하기 위해 함께 "협력적으로" 동작하는 것이 필요하다는 것을 알 수 있다. 그러나 현재, 상이한 DSD들의 다양한 DS 식별 능력들은 LFA들에서 협력적 DS 식별을 실현하기 위해 전체적인 방식으로 활용될 수 없다.

RDS 생성 프로세스: DS 식별 프로세스 후에, 다음 단계(RDS 생성 프로세스라고 지칭됨)는 원하는 DS들로부터 수집된 원시 데이터를 처리하고, RDS들을 생성하고, 이들을 사용자에게 전달하는 방법에 관한 것이다. 특히, DS들로부터 수집된 원시 데이터는 많은 양일 수 있고, 대규모 원시 데이터에 대한 데이터 처리는 협력적으로 행해질 필요가 있을 수 있다. LFN은 IoT 원시 데이터를 처리할 수 있다면 원시 데이터 프로세서(RDP)로서 동작할 수 있다. 그러나, 주요 과제는 RDP들로서 동작할 수 있는 LFA들에서의 복수의 LFN들이 있을 수 있고, 이러한 LFN들은 상이한 조직들에 속할 수 있고, 이러한 LFN들 각각은 상이한 및/또는 제한된 데이터 처리 능력들을 가질 수 있다(예컨대, 일부는 데이터 전처리만을 수행할 수 있고, 일부는 기본 데이터 집계 처리를 수행할 수 있는 반면, 일부는 진보된 데이터 분석 처리를 수행할 수 있음)는 것이다. 따라서, LFA들에서의 복수의 LFN들이 주어진 DSCR에 대한 RDS들을 생성하기 위해 이들 각각의 데이터 처리 능력들을 완전히 이용/통합하기 위해 함께 협력적으로 동작할 필요가 있다는 것을 또한 알 수 있다. 그러나 현재, DSCR들을 서빙하기 위한 LFA들에서 협력적 RDS 생성을 수행하기 위한 해결책이 없다.

본 명세서에는 포그 기반 서비스 계층(SL)에 대한 협력적 DS 식별 및 RDS 생성을 위한 방법들 및 시스템들이 개시된다. 이러한 방법들 및 시스템들은 다음을 포함할 수 있지만 이에 제한되지는 않는다:

협력적 데이터 소스(DS) 식별: DSCR에 대응하는 RDS 내의 각각의 DE에 대해, 이들이 이 DSCR을 서빙하기 위한 원하는 DS들인지를 결정하기 위해 발견 및/또는 평가될 필요가 있는 LFA 내의 수천 개의 잠재적인 DS들이 존재할 수 있다. 데이터 소스 발견들(DSD들)로서 동작할 수 있는 LFA 내의 상이한 LFN들은 상이한 DS 식별 및 발견 능력들을 가질 수 있다. 따라서, 주어진 DSCR에 대한 원하는 DS들을 식별하기 위해 하나 이상의 LFA에서의 (DSD들로서) 복수의 LFN들이 협력적으로 함께 작업하는 것을 허용하는 방법들 및 시스템들이 제공된다.

주어진 LFN은 DS 식별 능력들을 가질 수 있지만, (예를 들어, 원하는/식별된 DS로부터 데이터를 수집하기 위한) 데이터 수집 능력 또는 (예를 들어, RDS들을 생성하기 위해 원시 데이터를 처리하기 위한) 특정 데이터 처리 능력을 갖지 않을 수 있다. 따라서, 본 명세서에 개시된 DS 식별 프로세스는 주어진 DSCR에 의해 요구되는 바와 같이 RDS들 내의 각각의 DE에 대한 원하는 DS들을 식별하는 것을 지칭할 뿐만 아니라, 그 식별된 DS들로부터 원시 데이터를 수집하기 위한 원시 데이터 수집기들(RDC들)로서 동작할 수 있는 적절한 LFN들을 찾고 RDS들을 생성하기 위해 원시 데이터를 처리하기 위한 원시 데이터 프로세서들(RDP들)로서 동작할 수 있는 적절한 LFN들을 찾는 것을 지칭한다. 본 명세서에 개시된 협력적 DS 식별을 위한 해결책들은 RDC 발견 및 DS 식별 결과 통합 및 RDC/RDP 작업 할당을 갖는 DS 식별을 포함하지만 이에 제한되지 않는다.

협력적 RDS 생성: RDS 생성 절차 동안, 주요 작업은 수집된 원시 데이터를 처리하고 RDS들을 생성하는 방법에 관련된다. DS들로부터 수집된 원시 데이터는 많은 양일 수 있고, 대규모 원시 데이터에 대한 데이터 처리가 또한 협력적으로 수행될 필요가 있을 수 있다. 주어진 DSCR에 대해, 그 데이터 처리는 복수의 RDP들에 걸칠 수 있는데, 그 이유는 상이한 LFN들이 이 DSCR에 대한 RDS들을 생성하는데 요구되는 다양한 데이터 처리 능력들을 가질 수 있기 때문이다. 본 명세서에 개시된 협력적 RDS 생성을 위한 주요 해결책들은 주어진 DSCR에 대한 RDS 생성, 주어진 DE에 대한 RDS 생성, 및 주어진 DSCR에 대한 RDS 조립을 트리거링하는 것을 포함하지만 이에 제한되지는 않는다.

본 개시내용 전체에 걸쳐 사용되는 다수의 용어들에 대한 예시적인 정의들이 아래에 설명된다:

클라우드 노드(CN): 배치 계층구조에서 더 하위의 다른 포그 노드들의 동작들을 관리하는 클라우드 능력들을 갖는 노드이다. 본 개시내용에서, 용어 "클라우드"는 클라우드 노드를 지칭하는데 사용될 수 있다는 점에 유의한다. 클라우드는 함께 애플리케이션들에 대한 포그 서비스 계층을 가능하게 하는 상이한 포그 노드들 간의 상호작용들을 감독하고 관리한다.

데이터 샘플 수집 요청(DSCR): DSCS의 사용자는 DSCR에서 그 요구들을 지정할 수 있고, 이는 그들이 어떤 유형의 RDS들을 수신하고자 하는지에 관한 상세들을 포함할 수 있다.

RDS(Ready-to-use Data Sample): 주어진 DSCR에 대해, 그 대응하는 RDS들은 사용자가 (예컨대, 분석 차트들을 그리기 위해) 소비할 이용 준비 단계에서 이미 존재하는 데이터 샘플들을 지칭한다. RDS들은 LFA들에서 LFN들에 의해 수행되는 RDS 생성 프로세스들을 통해 획득될 수 있다. 예를 들어, 주어진 DSCR에 대해, DSCS는 포그 컴퓨팅 패러다임을 활용함으로써 RDS들을 생성하기 위해 효율적인 IoT 원시 데이터 수집 및 데이터 처리를 수행할 수 있다. 스마트 도시 이용 사례 예를 이용하면, DSCR-1에서의 DE-1(이는 마지막 3분에서의 LFA-1의 평균 온도임)의 경우, LFA-1에 배치된 DSCS는 LFA-1 내의 관여된 온도 센서들로부터 원시 데이터를 수집하고, 원시 데이터에 걸쳐 평균 집계 동작을 수행하고, DSCR-1의 모든 RDS들에 대한 DE-1 부분을 생성할 필요가 있다. DSCR-1의 모든 RDS에 대한 DE-2 부분은 또한 유사한 방식으로 생성될 수 있다. 컨텍스트 정렬을 통해, DE-1 부분에 대한 데이터 및 DE-2 부분에 대한 데이터는 RDS들을 생성하기 위해 그에 따라 조립될 수 있다. 예를 들어, DE-1 부분에 대한 하나의 데이터 조각과 DE-2 부분에 대한 하나의 데이터 조각이 동일한 3분 시간 간격에 대한 것이면, 이들 2개의 데이터 조각은 함께 조립되어 이 특정 3분 시간 간격에 대한 단일/완전한 RDS를 형성할 수 있다.

데이터 요소(DE): DSCR은 이 DSCR에 대응하는 단일 RDS에 어떤 DE들이 포함될 수 있는지를 정의한다(예컨대, 이것은 그 대응하는 RDS들이 어떤 모양인지를 설명할 수 있다). 즉, RDS는 그 대응하는 DSCR의 실제 데이터 샘플 인스턴스이다. 예로서, 다음과 같은 2개의 DE: DE-1(마지막 3분에서의 LFA-1의 평균 온도) 및 DE-2(마지막 3분에서의 LFA-1의 평균 잡음 레벨)를 갖는 DSCR-1을 고려한다. DSCR-1의 모든 RDS는 이들 2개의 DE(DE-1, DE-2, RDS_Contexts)를 가질 수 있으며, 여기서 RDS_Contexts는 이 RDS에 관한 상세한 컨텍스트 정보(예컨대, 이 특정 RDS가 어느 3분 시간 간격에 관련되는지)를 제공한다.

포그 노드(FN): 계산, 저장, 통신, 분석 등과 같은 임의의 포그 리소스를 갖는 노드이다. 포그 노드는 이러한 리소스들 중 적어도 하나를 가질 수 있고, 또한 포그 노드 상에서 실행 중인 다른 소프트웨어 또는 서비스들을 가질 수 있다. FN은 LFN들의 레벨보다 높은 하나의 레벨에 배치되는 것으로 가정된다. 클라우드 노드(CN)가 최고 레벨에 있는 여러 레벨들의 FN 배치들이 있을 수 있다. 스마트 도시 이용 사례 예에서, FN은 네트워크에서의 더 높은 레벨의 라우터일 수 있다.

로컬 포그 영역(LFA): 지리적 영역(예를 들어, 도시)은 상이한 애플리케이션 시나리오들에 따라 복수의 LFA로 분할될 수 있다. 스마트 도시 이용 사례 시나리오에서, 특정 주거 영역이 LFA일 수 있거나, 시내 영역 내의 CBD가 LFA일 수 있다.

로컬 포그 노드(LFN): LFN은 계산, 저장, 및 통신 능력을 갖는 LFA 내의 노드일 수 있다. LFN은 그 대응하는 LFA에서 LFN 리더(LFNL)와 통신 및/또는 상호작용할 수 있다. 예시적인 LFN은 사람의 셀폰, 이동 버스, 집의 홈 게이트웨이 등일 수 있다. LFN은 네트워크의 최저 레벨에 있는 FN의 유형이다. LFN은 동일한 LFA 내의 다른 LFN들과 상호작용/협력할 수 있고, 다양한 DS들로부터 IoT 데이터를 발견, 수집 및 처리하는 것을 수행할 수 있다.

LFN 리더(LFNL): 주어진 LFA는 그 영역에서 LFN 리더를 갖는다. LFNL은 그 LFA 내의 모든 LFN들의 활동들을 관리, 제어, 및/또는 조정하는 LFN이고, 더 높은 레벨 상에 있는 FN들에 접속될 수 있다. 스마트 도시 이용 사례 예에서, LFNL은 특정 주거 영역의 주요 게이트웨이일 수 있다.

DS 식별 프로세스: 주어진 DSCR에 대응하는 RDS 내의 각각의 DE에 대해, 이들이 이 DSCR에 대한 원하는 DS들인지를 결정하기 위해 발견 및/또는 평가될 필요가 있는 LFA 내의 수천 개의 잠재적인 DS들이 존재할 수 있다. 이러한 프로세스는 DS 식별 프로세스로 지칭될 수 있다.

RDS 생성 프로세스: RDS 생성 프로세스는 원하는 DS들로부터 수집된 원시 데이터를 처리하고 RDS들을 생성하는 방법을 지칭한다.

데이터 소스(DS): 노드는 IoT 데이터의 소스인 경우 DS일 수 있다. 예를 들어, 노드는 센서, 카메라, 신호등, 또는 데이터를 생성하는 임의의 IoT 디바이스일 수 있다. 도로변 유닛은 또한, 이것이 도로면과 관련된 센서 데이터를 생성하기 때문에 DS일 수 있다. 도로변 유닛은 또한 LFN일 수 있는데, 그 이유는 이것이 특정 데이터 처리 능력들을 수행할 수 있고/있거나 LFNL과 통신할 수 있기 때문이다. 일반적으로, 감지할 뿐만 아니라 컴퓨팅, 저장 및 통신 능력들도 갖는 LFA 내의 노드는 LFN뿐만 아니라 DS일 수 있다.

DSD(Data Source Discoverer): 이것은 논리적 역할이다. 주어진 LFN이 DS 식별 프로세스 동안 주어진 DSCR에 대한 DS들을 발견하는데 관여되는 경우, 이것은 이 DSCR에 대한 DSD로서 간주될 수 있다.

원시 데이터 수집기(RDC): 이것은 논리적 역할이다. 주어진 LFN이 주어진 DSCR을 서빙하기 위해 일부 DS들로부터 원시 데이터를 수집하는데 관여되는 경우, 이것은 이 DSCR에 대한 RDC로서 간주될 수 있다.

원시 데이터 프로세서(RDP): 이것은 논리적 역할이다. 주어진 LFN이 RDS 생성 프로세스 동안 주어진 DSCR에 대한 수집된 원시 데이터를 처리하는데 관여되는 경우, 이것은 이 DSCR에 대한 RDP로서 간주될 수 있다. 일반적으로, LFN은 동시에 RDC, DSD 및 RDP의 복수의 논리적 역할들을 할 수 있거나, 또는 이러한 논리적 역할들은 주어진 DSCR을 서빙할 때 상이한 LFN들에 의해 행해질 수 있다는 점에 유의한다. 특히, 3개의 상이한 논리적 역할을 정의함으로써, 상이한 작업들이 분리되고 상이한 역할들에 의해 수행될 수 있기 때문에 작업 협력이 용이해질 수 있다.

본 개시내용에서 제안된 아이디어들이 포그 관련 용어들을 사용하여 설명되지만, 본 개시내용에서 제안된 아이디어들이 또한 에지 시나리오에 적용될 수 있다는 점에 주목할 만하다. 예를 들어, LFA는 또한 에지에서의 특정 영역으로서 해석될 수 있고, LFN은 에지측에 있는 노드일 수 있고, LFNL은 에지에서의 게이트웨이 또는 에지에서의 도로변 유닛 등일 수 있다.

데이터 샘플 수집 서비스(DSCS)라고 불리는 서비스 계층에 대한 공통 서비스의 두 가지 핵심 특징이 본 명세서에 개시된다. DSCS의 상위 레벨 아키텍처가 도 18에 도시되어 있다. DSCS는 사용자들로부터 다양한 DSCR들을 수신하고 그 사용자들을 대신하여 모든 상세들을 처리할 수 있다. DSCR에서, 사용자는 데이터 샘플들에 관한 다양한 품질 요건들과 함께, 그 원하는 데이터 샘플들(예를 들어, RDS들)이 어떤 모양인지를 명확하게 묘사할 수 있다. (LFN, LFNL, FN 또는 CN과 같은) 서비스 계층 노드는 이 노드가 데이터 샘플 수집 관련 서비스를 제공하고자 하는 경우 DSCS 에이전트를 가질 수 있다. SL 노드 상의 DSCS 에이전트는 DSCS 사용자들과 상호작용할 수 있을 뿐만 아니라 사용자들에 의해 제기되는 DSCR들을 서빙하기 위해 다른 DSCS 에이전트들과 협력할 수 있는 소프트웨어 부분이다. DSCS에 의해, 일단 사용자들이 자신의 DSCR들을 제기하고 나면, 사용자들은 LFA들에서 자격있는 DS들을 식별하는 방법 및 원시 데이터 처리 및 RDS 생성을 위해 이들 LFA들에서 LFN들을 구성하는 방법에 관한 임의의 상세들에 관여될 필요가 없다. 도 18에 도시된 예로서, CN 내의 DSCS 에이전트는 사용자로부터 DSCR을 수신한 후에, 어느 LFA(들)가 관여되는지를 알아낼 수 있다. 사용자가 단지 특정 LFA(예컨대, 도 18의 좌측에 도시된 것)로부터 데이터 샘플들을 수집하기를 원한다면, 이 DSCR의 대응하는 작업은 그 LFA에서의 LFNL 상의 DSCS 에이전트에 할당될 수 있다. 이 LFNL은 본 명세서에 개시된 두 가지 특정한 기술적 문제(예컨대, DS 식별 및 RDS 생성)를 수반할 수 있는, 이 LFA 내의 모든 LFN들에 의해 수행될 활동들에 대한 중앙 제어기, 관리자, 및/또는 조정자로서 동작할 수 있다.

협력적 데이터 소스(DS) 식별: DSCR에 대응하는 RDS에서의 각각의 DE에 대해, 이들이 이 DSCR에 대한 원하는 DS들인지를 결정하기 위해 발견 및/또는 평가될 필요가 있는 LFA에서 수천 개의 잠재적인 DS들이 존재할 수 있다. LFA들에서의 LFN들은 상이한 DS 식별 능력들을 가질 수 있다. 따라서, LFA들에서의 복수의 LFN들이 주어진 DSCR에 대한 원하는 DS들을 식별하기 위해 협력적으로 함께 작업할 수 있다는 것이 본 명세서에 개시된다. LFN-1이 DS 식별 작업에 참여했고 주어진 DSCR-1에 대한 원하는 DS를 식별한다고 가정될 수 있다. 이 경우에, LFN-1은 DSD로서 동작하였다. 그러나, LFN-1은 그 제한된 작업부하 용량으로 인해 이 DS에 대한 원시 데이터 수집기(RDC)로서 추가로 동작하지 않을 수 있다. 따라서, 다른 LFN-2는 이 DS로부터 원시 데이터를 추가로 수집하는 것을 담당하는 RDC로서 동작할 필요가 있을 수 있다. 유사하게, LFN-2는 이 DS에 대한 원시 데이터 프로세서(RDP)로서 추가로 동작하지 않을 수 있다. 따라서, 다른 LFN-3은 이 DS로부터 수집된 원시 데이터의 추가 처리를 담당하는 RDP로서 동작할 필요가 있을 수 있다. 따라서, 본 개시내용에서 고려되는 DS 식별 프로세스는 주어진 DSCR에 의해 요구되는 바와 같이 RDS들 내의 각각의 DE에 대한 원하는 DS들을 식별하는 것을 지칭할 뿐만 아니라, 그 식별된 DS들에 대한 RDP들뿐만 아니라 RDC들로서 동작할 수 있는 적절한 LFN들을 찾는 것을 지칭한다.

협력적 RDS 생성: RDS 생성 프로세스 동안, 주요 작업은 수집된 원시 데이터를 처리하고, RDS들을 생성하고, 이들을 사용자에게 전달하는 방법에 관련된다. DS들로부터 수집된 원시 데이터는 많은 양일 수 있고, 대규모 원시 데이터에 대한 데이터 처리는 협력적으로 행해질 필요가 있을 수 있다(예컨대, IoT 데이터 처리는 주어진 RDS 생성 프로세스 동안 복수의 RDP들에 걸칠 수 있다). 예를 들어, RDP로서 동작하는 LFN-1은 예상치 못한 그리고/또는 큰 원시 데이터 도착으로 인해 일시적으로 과부하되는 경우, 그 데이터 처리의 일부를 현재 매우 가벼운 작업부하를 갖고 또한 RDP로서 동작할 수 있는 다른 LFN-2로 넘길 수 있다. 다른 예로서, LFN-1은 그 제한된 데이터 처리 능력으로 인해 일부 단순한 데이터 처리만을 수행할 수 있는 경우, 그 전처리된 데이터를 심층 데이터 처리를 위해 다른 더 강력한 RDP(예컨대, LFN-2)로 전송할 수 있다.

본 명세서에 개시된 방법들 및 시스템들을 이용하여, 상이한 LFN들은 DS 식별 프로세스 또는 RDS 생성 프로세스에 수반되는 상이한 역할들을 할 수 있다. 예를 들어, DSD들로서 동작하는 LFN들은 원하는 DS들을 발견하기 위해 함께 작업할 수 있다. 다른 노드들은 또한 원하는 DS들(DS 식별 프로세스 동안 식별됨)로부터 원시 데이터를 수집하고, 원시 데이터를 처리하고, RDS들을 생성하기 위한 RDC들 및/또는 RDP들로서 동작할 수 있다.

개시된 방법들은 혼성 포그 시나리오에서의 동적성 및 불확실성을 또한 고려한다는 것에 주목할 만하다. 예를 들어, 상이한 LFN들이 상이한 조직들에 속하고 상이한 주요 이용 목적들을 가질 수 있기 때문에, LFN들이 참여하고 DS 식별 또는 RDS 생성과 관련된 특정 작업에 기여하는 것을 유지하기 위한 엄격한 요건이 없다. 따라서, 주어진 작업에서, 상이한 LFN들로부터의 능력들은 이러한 LFN들이 협력적 방식으로 작업하게 하기 위해 함께 통합될 필요가 있을 수 있다.

도 18(및 이 개시내용의 다른 도면들)은 클라우드 내의 사용자가 DSCR을 CN의 DSCS 에이전트에 전송한다는 것을 보여준다. 사용자들은 추가적으로 또는 대안적으로 LFA들로부터 올 수 있고, 이러한 경우 사용자들은 그 DSCR들을 그 LFA들에서의 대응하는 LFNL들 상의 DSCS 에이전트에 전송할 수 있다는 것이 이해된다. 본 개시내용에서 제안된 절차들 및 해결책들은 또한 이 경우를 지원한다.

LFN 능력 등록 절차에서, 주어진 LFA 내의 LFNL은 LFA 내의 LFN들의 모든 활동들을 관리하거나 조정하는 것을 담당할 수 있다. 따라서, LFNL의 관리 작업을 용이하게 하기 위해, LFN들 각각은 DS 식별 및 RDS 생성에 관련된 임의의 작업들에 참여할 수 있기 전에 그 잠재적인 능력들을 LFNL에 먼저 보고 및/또는 등록할 필요가 있을 수 있다. 상이한 LFN들의 능력들/기능들의 이용이 최대화될 수 있으며, 그 이유는 이들 능력들이 상이한 DSCR들을 서빙할 때 공유될 수 있기 때문이다. 동일한 능력을 갖는 복수의 LFN이 추가적으로 또는 대안적으로 통합될 수 있고, 이는 DS 식별 및 RDS 생성 절차들을 수행할 때 확장성을 향상시킬 수 있다.

LFN 리더에 대한 LFN 능력 등록을 위한 예시적인 절차가 도 19에 도시되고 아래에 논의된다:

전제 조건으로서, LFN-1은 LFA-1에서 LFNL을 식별했을 수 있고, 이는 임의의 기존의 기술들에 기반할 수 있는 LFNL-1인 것으로 이해된다. 예를 들어, LFNL-1은 LFA-1 내의 모든 LFN들에 브로드캐스팅되어 이것이 이 LFA에서의 LFNL로서 선택되었다는 것을 주장할 수 있다.

단계 1에서, LFN-1 상의 DSCS 에이전트-2는 DS 식별 및 RDS 생성과 관련된 장래의 작업들에 참여하기 위해 LFNL-1 상의 DSCS 에이전트-1에 LFN-1의 능력들을 등록하려고 의도한다.

단계 2에서, DSCS 에이전트-2는 LFN-1의 잠재적인 능력들 및 식별자들에 관한 상세 정보를 포함하는 등록 요청을 DSCS 에이전트-1에 전송한다. LFNL에 보고된 정보는 LFN-1이 DSD, RDC 및 RDP에 관련된 역할들 중 임의의 것을 서빙할 수 있는지를 설명할 수 있다(주어진 LFN이 복수의 논리적 역할을 서빙할 수 있는 것이 가능하다). 이하의 예에서, 3개의 파라미터는 LFN-1이 잠재적인 DSD일 수 있는지를 설명한다:

DSD_Capability_List: 이 파라미터는 이를 DSD로서 가능하게 할 수 있는 LFN-1의 모든 능력들을 열거할 수 있다. 예를 들어, oneM2M 시스템에서, 주어진 CSE는 oneM2M 기본 리소스 발견 능력을 갖는 경우 DSD일 수 있다. 리소스 발견 능력은 이 파라미터에 추가적으로 또는 대안적으로 포함될 수 있다. 이 CSE가 진보된 시맨틱 리소스 발견 능력들을 가지면, 이러한 능력들은 이 파라미터에 포함될 수 있다.

DSD_Work_Schedule_Availability_List: "DSD_Capability_List"에 열거된 바와 같은 능력들 각각에 대해, 대응하는 작업 스케줄이 이 파라미터에 포함될 수 있다. 예를 들어, LFN-1은, LFN-1이 (제1 우선순위를 갖는) 이때 쯤에 그 자신의 조직으로부터의 큰 작업부하를 통상적으로 갖기 때문에, 10am-2pm 동안 협력적 DS 식별을 위해 그 진보된 시맨틱 리소스 발견 능력을 제공하기를 원하지 않을 수 있다.

DSD_Capability_Scope: 이 파라미터는 "DSD_Capability_List"에 열거된 바와 같은 DSD 능력들에 대한 임의의 제한, 제약, 또는 범위를 나타내는데 이용될 수 있다. 예를 들어, 이 파라미터는 LFN-1이 특정 노드들 상에서 또는 특정 위치들에서 DS 식별만을 수행할 수 있다는 것을 나타낼 수 있다. LFN-1이 LFN-1과 동일한 조직에 속하는 DS들만을 식별할 수 있는 것이 가능하다. 즉, LFN-1은 그 자신의 조직 내의 DS들만을 식별할 수 있다. 다른 예에서, LFN-1이 특정 지리적 영역 내에서(예컨대, LFA-1에 위치한 단일 건물에서) DS 식별만을 수행할 수 있는 것이 가능할 수 있다. 이러한 파라미터에 표시된 이러한 제한들 및/또는 제약들은 더 미세한 제한들 및/또는 제약들이 추가로 고려될 필요가 있을 수 있다는 점에서 단지 조잡하다는 점에 유의한다. 예를 들어, LFN-1이 단일 건물에서 DS 식별을 수행할 수 있지만, 이 건물에서 주어진 DS-1에 대해, LFN-1이 그 건물에서 이러한 특정 DS-1을 발견하도록 허용되는지를 정의하는 추가적인 발견 규칙들 또는 정책들을 가질 수 있는 것이 가능하다.

유사하게, 이하의 3개의 파라미터는 LFN-1이 잠재적인 RDC일 수 있는지를 설명한다:

RDC_Capability: 이 파라미터는 LFN-1이 IoT 원시 데이터 수집 능력을 갖는지를 전달하기 위한 것이다.

RDC_Work_Availability_Schedule: 이 파라미터는 LFN-1에 대한 RDC 능력의 작업 스케줄을 나타낸다. 예를 들어, LFN-1은, LFN-1이 (제1 우선순위를 갖는) 이때 쯤에 그 자신의 조직으로부터의 큰 작업부하를 통상적으로 갖기 때문에, 10am-2pm 동안 그 원시 데이터 수집 능력에 기여하기를 원하지 않을 수 있다.

RDC_Capability_Scope: 이 파라미터는 RDC 능력에 대한 임의의 제한, 제약, 또는 범위를 나타내는데 이용될 수 있다. 예를 들어, 이 파라미터는 LFN-1이 특정 노드들 상에서 또는 특정 위치들에서 원시 데이터만을 수집할 수 있다는 것을 나타낼 수 있다. LFN-1이 그 자신의 조직 내에서의 DS들로부터 원시 데이터만을 수집할 수 있는 것이 가능하다. 다른 예로서, LFN-1이 특정 지리적 영역에 배치된 DS들(예컨대, LFA-1에 위치한 단일 건물)로부터 원시 데이터만을 수집할 수 있는 것이 또한 가능하다.

유사하게, 이하의 3개의 파라미터는 LFN-1이 잠재적인 RDP일 수 있는지를 설명한다:

RDP_Capability_List: 이 파라미터는 이를 RDP로서 가능하게 할 수 있는 LFN-1의 모든 능력들을 열거하기 위한 것이다. 예를 들어, LFN-1은 (평균, 최대, 최소 동작들 등을 수행하는 것과 같은) 간단한 데이터 집계 능력을 지원할 수 있다. 따라서, 간단한 데이터 집계 능력이 이 파라미터에 포함될 수 있다. LFN-1이 또한 진보된 데이터 처리 능력들(예컨대, 분류, 회귀, 또는 다른 머신 학습 기반 접근법들)을 갖는 경우, 이 능력이 또한 이 파라미터에 포함될 수 있다.

RDP_Work_Schedule_Availability_List: "RDP_Capability_List"에 열거된 바와 같은 능력들 각각에 대해, 하나 이상의 대응하는 작업 스케줄이 또한 이 파라미터에 포함될 수 있다.

RDP_Capability_Scope: 이 파라미터는 "RDP_Capability_List"에 열거된 바와 같은 RDP 능력들에 대한 임의의 제한, 제약, 또는 범위를 나타내는데 이용될 수 있다. 예를 들어, 이 파라미터는 처리를 위해 데이터를 LFN-1에 전송 또는 입력할 때 특정 데이터 포맷이 이용되어야 한다는 것을 나타낼 수 있다. 따라서, 입력 데이터(예컨대, DS들로부터 수집된 원시 데이터)가 이 파라미터에 표시된 바와 같은 요구된 데이터 포맷과 호환가능하지 않다면, (예를 들어, LFN-2에 의해 동작된) 다른 RDP는 LFN-1 이전에 필요할 수 있으며, 이는 원래의 입력 데이터를 LFN-1에 의해 요구되는 원하는 데이터 포맷으로 먼저 변환할 수 있다.

추가적으로 또는 대안적으로, 각각의 LFN은 그 지리적 위치, 그 가입 조직 등과 같은 그 자신에 관한 일부 다른 컨텍스트 정보를 등록할 수 있다.

단계 3에서, DSCS 에이전트-1은 장래의 이용을 위해 LFN-1의 능력들을 기록한다. 능력 등록 표는 표 9에 도시된 모든 정보를 기록하기 위해 DSCS 에이전트-1 상에서 이용가능할 수 있다.

<표 9>

단계 4에서, DSCS 에이전트-1은 성공적인 등록을 확인응답한다. 다시 말해서, DSCS 에이전트-1은 이제 어느 LFN들이 DSD, RDC 및 RDP로서 동작할 수 있는지에 관하여 리소스 풀을 갖는다. 따라서, 미래의 DSCR들을 수신할 때, DSCS 에이전트-1은 이들 DSCR들을 서빙하기 위해 그 풀에서 이러한 리소스를 이용할 수 있다.

LFN은 표 9에 도시된 능력 등록 표에 대한 업데이트들에 또한 이르게 할 수 있는 그 능력(예컨대, 새로운 능력을 추가하는 것, 기존의 능력에 대한 작업 스케줄을 업데이트하는 것, 능력을 삭제하는 것 등)을 동적으로 업데이트할 수 있는 것이 가능하다. 업데이트 절차는 도 19에 도시된 절차와 유사할 수 있다.

예시적인 협력적 DS 식별 절차에서, LFNL이 DSCR을 수신할 때(예컨대, 사용자가 CN에 대한 DSCR을 제기했고, CN이 이 DSCR을 관련 LFNL에 추가로 할당했을 때), LFNL은 이 LFNL에 의해 관리되는 복수의 LFN에 의해 제공 및/또는 등록된 DS 식별 능력들을 이용함으로써 협력적 DS 식별 프로세스를 개시하기 시작할 수 있다. 일반적으로, 특정 협력적 DS 식별 프로세스는 아래에 더 상세히 논의되는 바와 같이 2개의 스테이지를 수반한다.

스테이지 1은 RDC 발견에 의한 DS 식별을 포함할 수 있다. 스테이지 1에서, 주요 작업은 특정 수신된 DSCR을 서빙할 수 있는 모든 원하는 DS들을 식별하는 것이다. 원하는 DS는 이 특정 DSCR의 대응하는 RDS들에서 특정 DE에 원시 데이터를 제공하는 엔티티일 수 있다. 그렇게 하기 위해, LFNL은 먼저 LFN 능력 등록 표에서 설명된 바와 같은 정보에 기반하여 DSD들로서 동작할 수 있는 LFN들의 리스트를 선택할 필요가 있을 수 있다. 그 후, LFNL은 그 선택된 DSD들을 지정하여 DS 식별 동작들을 협력적으로 수행한다. 많은 경우들에서, LFN-1은 DSD로서 동작할 수 있고 수신된 DSCR들에 대한 원하는 DS들을 식별할 수 있다. 그러나, 실제 RDS 생성 프로세스가 나중에 시작될 수 있기 때문에, LFN-1은 그때 쯤에 더 이상 이용가능하지 않을 수 있고, 따라서 다른 LFN-2는 나중의 원시 데이터 수집을 위한 RDC로서 서빙하는 것이 필요할 수 있다. 다른 가능성은 LFN-1이 그 작업 특수성이 단지 DS 식별이라는 의미에서 정교한 DS 식별 능력들을 구비한 특수 노드라는 것이다. 다시 말해서, LFN 물리적 노드 구현을 용이하게 하기 위해, 상이한 LFN들이 이들 각각의 작업 특수성들을 가질 수 있는 것이 가능하다. 따라서, DSD(예컨대, LFN-1)는 원하는 DS를 식별할 때, 또한 이 DS로부터 원시 데이터를 검색하는 것이 허용되는 사람에 관한 관련 정보를 수집할 필요가 있을 수 있고, 이러한 정보는 나중 스테이지에서 이 DS에 대한 적절한 RDC를 찾는데 필요할 수 있다. oneM2M을 예로 들면, <container-1> 리소스는 (원하는 DS로서) 온도 센서의 모든 판독치들을 저장하는 (DSD로서) CSE에 의해 발견되었다. CSE는 이 <container-1> 리소스에 관련된 액세스 제어 정책(ACP)을 체크할 수 있다. 예를 들어, <container-1> 리소스가 <ACP-1> 리소스에 설명된 액세스 제어 정책을 이용하고 있는 경우, CSE는 <ACP-1> 리소스를 추가로 체크하여, 어느 엔티티들이 <container-1> 리소스에 대한 "검색" 특권을 갖는지를 식별할 수 있다. LFN-1은 그 DS 식별 결과뿐만 아니라 RDC 후보들을 다시 LFNL에 전송할 수 있다.

일 예에서, 데이터 샘플 수집 서비스는, 데이터 샘플과 연관된 하나 이상의 데이터 요소를 식별하는 데이터 샘플 수집 요청을 수신하는 것; 데이터 요소들 중 적어도 하나에 대해, 적어도 하나의 데이터 요소에 대한 하나 이상의 데이터 소스를 식별하도록 구성된 하나 이상의 데이터 소스 발견기를 결정하는 것; 하나 이상의 데이터 소스 발견기에, 데이터 요소들 중 적어도 하나에 대한 하나 이상의 데이터 소스를 식별하라는 요청을 전송하는 것; 하나 이상의 데이터 소스 발견기로부터, 데이터 요소들 중 적어도 하나에 대한 하나 이상의 데이터 소스를 식별하는 데이터 소스 식별 결과를 수신하는 것; 데이터 소스 식별 결과에 기반하여, 데이터 소스로부터 원시 데이터를 수집하는 것 및 데이터 소스로부터 수집된 원시 데이터를 처리하는 것 중 적어도 하나를 수행하도록 구성된 로컬 포그 노드를 선택하는 것; 및 선택된 로컬 포그 노드에, 데이터 소스로부터 원시 데이터를 수집하는 것 및 데이터 소스로부터 수집된 원시 데이터를 처리하는 것 중 적어도 하나를 수행하라는 표시를 전송하는 것을 포함하는 동작들을 수행하도록 구성될 수 있다.

데이터 샘플 수집 요청은 데이터 샘플과 연관된 정보를 포함할 수 있고, 이 정보는 데이터 샘플들이 얼마나 빈번하게 생성되어야 하는지, 데이터 샘플 수집 요청이 구현되어야 하는 때의 스케줄, 데이터 샘플이 전송되어야 하는 곳의 식별자, 및 데이터 샘플과 연관되는 컨텍스트 정보 중 하나 이상을 포함한다. 하나 이상의 데이터 요소 중의 데이터 요소는 데이터 요소의 식별자, 데이터 요소에 대해 수집될 원시 데이터의 유형, 데이터 요소에 대한 원시 데이터와 연관된 단위, 및 데이터 요소에 대한 데이터 처리 동작 중 적어도 하나를 포함할 수 있다. 하나 이상의 데이터 소스를 식별하라는 요청은 식별할 데이터 소스의 유형 및 데이터 소스 식별을 수행하기 위한 작업 범위 중 적어도 하나를 포함할 수 있다. 데이터 소스 식별 결과는 데이터 소스의 데이터 속도, 데이터 소스의 데이터 단위, 데이터 소스의 지리 위치, 데이터 소스의 이용가능성 스케줄, 및 데이터 소스에 액세스하도록 구성되는 하나 이상의 로컬 포그 노드 중 적어도 하나를 포함할 수 있다. 데이터 소스로부터 원시 데이터를 수집하는 것 및 데이터 소스로부터 수집된 원시 데이터를 처리하는 것 중 적어도 하나를 수행하라는 표시는 작업 설명 및 작업 식별자 중 적어도 하나를 포함할 수 있다. 데이터 샘플 수집 서비스는 로컬 포그 노드, 로컬 포그 노드 리더, 포그 노드, 또는 클라우드 노드 중 하나에서 구현될 수 있다. 동작들은 복수의 데이터 소스 발견기로부터 수신된 하나 이상의 데이터 소스 식별 결과를 통합하는 것; 및 통합된 데이터 소스 식별 결과들에 기반하여, 데이터를 수집할 하나 이상의 데이터 소스의 리스트를 결정하는 것을 더 포함할 수 있다.

RDS 발견에 의한 DS 식별을 위한 예시적인 절차가 도 20에 도시되고 아래에서 추가로 논의된다.

단계 1에서, LFA-1 내의 LFNL-1 상의 DSCS 에이전트-1은 DSCR-1을 수신한다. 사용자가 LFA-1에 존재하는 경우, 사용자는 DSCR-1을 LFNL-1 상의 DSCS 에이전트-1에 직접 제기할 수 있거나, 또는 사용자는 클라우드 내에 있는 경우, DSCR-1을 CN 내의 다른 DSCS 에이전트에 제기할 수 있고, 그 후, DSCR-1을 처리를 위해 LFNL-1 상의 DSCS-1에 전달한다. 일반적으로, DSCR-1은 사용자가 어떤 종류의 RDS들을 수신하고자 하는지에 관한 모든 상세들을 설명한다. 아래에 도시된 바와 같이, DSCR은 다음과 같은 정보를 포함할 수 있다:

파라미터들의 제1 부분은 특정 DSCR-1의 RDS에 대한 전체 정보 및 요건들에 대한 것이다:

Data_Sample_Frequency: "Data_Sample_Frequency"는 얼마나 자주 RDS들이 생성되어야 하는지를 나타낸다. 예를 들어, 사용자는 매 1분마다 RDS를 필요로 할 수 있다. 스마트 도시 분석 이용 사례에서 이용되는 다른 예에서, 2개의 DE가 각각 매 3분마다 평균 온도 및 습도를 계산하는 것이기 때문에, RDS는 매 3분마다 생성되어야 한다.

RDS_Production_Schedule: 이것은 임의적 파라미터이다. "RDS_Production_Schedule"는 이 DSCR-1에 대한 RDS 생성이 수행되어야 하는 때를 나타낸다. 즉, DSCR-1의 RDS 생성 프로세스는 LFNL-1이 DSCR-1을 처리한 직후에 시작될 필요가 없다. 사실상, 이것은 DSCR-1의 RDS 생성을 어떻게 제어할지에 관한 접근법들 중 하나이다. 예를 들어, 이 파라미터는 RDS 생성이 매일 8am-10am과 5pm-8pm 사이에서만 수행되어야 한다는 것을 나타낼 수 있다. 대안적으로, RDS 생성을 제어하기 위한 다른 접근법은 특정 트리거들에 기반할 수 있다(예컨대, RDS 생성 프로세스는 특정 트리거링 요청에 기반하여 또는 특정 이벤트들에 기반하여 시작될 수 있다).

RDS_Contexts: 이 파라미터는, 이 DSCR의 모든 단일 RDS에 대해, 포함될 모든 DE들에 추가하여, 어떤 다른 컨텍스트 정보가 또한 RDS에 포함되어야 하는지를 나타낸다. 예를 들어, RDS에 타임스탬프 및 DSCR_ID 정보를 내장하는 것이 필요할 수 있으며, 따라서 다른 것들은 이 RDS가 어느 DSCR에 부합하는지 그리고 어느 시간 간격 동안 이 RDS가 생성되는지를 알 수 있다. 일반적으로, 임의의 유용한 컨텍스트 정보는 이들이 나중의 이용을 위해 필요한 경우 RDS들에서 운반되어야 한다. 따라서, 주어진 RDS-1은 다음의 형태를 가질 수 있다: RDS-1 = (DE-1, DE-2, .... DE-N, RDS-context-1, RDS-Context-2, ....).

RDS_Sending_Address_List: 이 속성은 이 DSCR-1의 RDS들이 전송될 수 있는 어드레스들의 리스트를 나타낸다. 예를 들어, 다음의 두 가지 사례가 있을 수 있다:

DSCR-1이 사용자로부터 직접 전송되었다면 DSCR-1의 RDS들은 사용자에게 전송될 수 있는 것이 가능하다. 이것은 DSCR-1이 처리 동안 분할되지 않는다는 의미에서 가장 간단한 사례이다.

더 진보된 시나리오에서, DSCR-1은 처리 동안 분할될 수 있는데, 그 이유는 DSCR-1에 대해 수집될 데이터가 상이한 LFA들로부터 올 수 있다는 사실로 인해 DSCR-1이 복수의 LFA와 상호작용할 수 있기 때문이다. 다음의 예를 고려하면, DSCR-1은 부모 DSCR을 2개의 DSCR(예컨대, DSCR-1a 및 DSCR-1b)로 분할함으로써 생성되었다. 즉, 사용자는 2개의 LFA(예컨대, LFA-1 및 LFA-2)를 커버하는 큰 지리적 영역을 수반하는 부모 DSCR-1을 원래 제기하였다. 따라서, 이 부모 DSCR-1은 적절히 처리되기 위해 분할되었다. 예를 들어, DSCR-1a의 작업이 LFA-1 내의 DS 식별 및 RDS 생성을 처리하는 것이기 때문에, DSCR-1a는 하위 DSCR들 중 하나이고 이것은 LFA-1에서의 LFNL-1에 전송되었다. 유사하게, DSCR-1b는 다른 LFA-2와 관련된 DS 식별 및 RDS 생성을 처리할 수 있다. 그 결과, DSCR-1a의 RDS들(부모 DSCR-1 관점에서, DSCR-1a의 RDS는 부모 DSCR-1에 대한 단지 부분적 RDS일 수 있음) 및 DSCR-1b는 부모 DSCR-1에 대한 RDS들을 생성하기 위해 RDP에 의해 함께 추가로 결합 및/또는 조립될 필요가 있을 수 있다. DSCR-1의 RDS_Sending_Address_List는 DSCR-1의 사용자에 의해 제공되는 RDS 수신 어드레스일 수 있다. DSCR-1a 및 DSCR-1b의 RDS_Sending_Address_List는 부모 DSCR-1에 대한 RDS 조립을 위한 RDP일 수 있다.

DSCR-1의 각각의 RDS는 DE들의 리스트를 가질 수 있다. RDS에서의 DE들 각각은 이 DE에 대한 모든 상세들을 정의하는 다음의 항목들을 가질 수 있다:

DE_ID: "DE_ID"는 이 DSCR-1에서의 DE의 식별자이다. 스마트 도시 분석 이용 사례에서 이용되는 예로서, DSCR의 각각의 RDS에 2개의 DE가 있고, DE-1 및 DE-2가 각각 이들의 DE_ID들이다.

Raw_Data_Type: 이것은 어떤 유형의 원시 데이터가 이 DE에 대해 수집되어야 하는지를 나타내기 위한 것이다. 스마트 도시 분석 이용 사례에서 이용되는 예로서, DE-1의 원시 데이터 유형은 온도일 수 있다.

Unit: 이것은 이 DE의 단위들이 무엇이어야 하는지를 나타내기 위한 것이다. 스마트 도시 분석 이용 사례에서 이용되는 예에 따르면, DE-1의 원시 데이터 유형은 온도이다. 특히, DE-1의 원시 데이터는 섭씨 또는 화씨로 있을 수 있지만, RDS들에서는 DE-1 부분이 섭씨(이는 DE-1의 단위임)여야 하는 것이 요구될 수 있다.

Data_Processing_Operation: 이것은 RDS에서의 주어진 DE에 대해 어떤 유형의 데이터 처리 동작들이 이 DE에 대해 수집된 원시 데이터에 걸쳐 수행되어야 하는지를 나타내기 위한 것이다. 공통 동작들은 평균, 최대, 최소 등을 포함하지만, 이들로 제한되지 않는다. 스마트 도시 분석 이용 사례에서 이용되는 예로서, DE-1의 데이터 처리 유형은 "평균 집계 동작의 수행"이어야 한다. 사용자는 또한 맞춤화된 데이터 처리 동작을 이용할 수 있다. 이 경우, 이 파라미터는 "맞춤화된"의 값을 가질 수 있다.

Customized_Processing_Details: "Data_Processing_Operation"이 "맞춤화된"의 값을 갖는 경우, 이 파라미터는 이러한 맞춤화된 데이터 처리 동작들을 어떻게 수행할지를 나타낼 수 있다. 예를 들어, 이것은 다음과 같은 동작들을 가질 수 있다:

사용자는 머신 학습 프로세스를 통해 획득되는 수학적 공식 또는 모델을 산출하고, 이 모델은 이 DE에 대해 수집된 원시 데이터를 처리하는데 이용될 수 있다. 이 경우, 공식은 이 파라미터에 직접 내장될 수 있다.

사용자는 그 자신의 데이터 처리 코드 스니펫을 가지며, 이는 이 DE에 대해 수집된 원시 데이터를 처리하기 위해 LFA에서 RDP에 의해 실행될 수 있다. 이 경우, 이 파라미터는 데이터 처리 코드 스니펫들의 저장소 위치(예컨대, URI)를 나타낼 수 있다.

Quality_Requirements: 이것은 이 DE에 대한 임의의 품질 요건들을 나타내기 위한 것이다. 스마트 도시 분석 이용 사례에서 이용되는 예로서, 단일 RDS에서의 DE-1에 대해, 정확도를 보장하기 위해 온도 판독치들이 LFA-X에 배치된 적어도 100개의 상이한 온도 센서로부터 수집될 필요가 있는 것이 요구된다.

단계 2에서, DSCS 에이전트-1은 (표 9에 도시된 바와 같이) LFN 능력 표를 체크하고 DSCR-1에 대한 DSD들로서 적절한 LFN들(예컨대, LFN-1)을 선택한다. 스마트 도시 분석 이용 사례에서 이용되는 예로서, 2개의 DE(예를 들어, DE-1 및 DE-2)는 각각 매 3분마다 평균 온도 및 습도를 계산할 수 있다. 따라서, 각각의 DE-1 및 DE-2에 대해, DSCS 에이전트-1은 하나 이상의 DSD의 리스트를 선택할 수 있다. 그렇게 하기 위해, DSCS 에이전트-1은 표 9에 나타낸 바와 같이 그 능력, 작업 스케줄뿐만 아니라 DSD 범위와 같은 잠재적인 DSD 후보들에 관한 상세한 정보를 체크할 필요가 있을 수 있다. LFA-X에 배치된 온도 센서들이 상이한 조직들에 속하는 경우에는 DE-1에 필요한 DS들을 식별하기 위해 복수의 DSD들이 필요할 수 있고, 선택된 DSD들 각각은 또한 특정한 능력 제한들을 갖는다(예컨대, 각각의 DSD는 동일한 조직에 속하는 특정한 DS들에 대해 DS 식별만을 수행할 수 있다). 다른 예로서, LFA-X는 매우 큰 지리적 영역을 커버할 수 있다. 따라서, 복수의 DSD가 필요할 수 있고, 이들 각각은 LFA-X에서 더 작은 영역에 대한 DS 식별을 수행할 수 있다. 일반적으로, 주어진 DE에 대한 DS 식별을 수행하기 위한 복수의 DSD를 필요로 하는 많은 다른 경우들이 있을 수 있고, 본 명세서에 개시된 방법들 및 시스템들은 이러한 경우들 모두에 적용될 수 있다.

전반적으로, DSCS 에이전트-1은 각각의 DE에 대한 DSD들의 리스트를 선택하고, 상세한 DS 식별 계획으로 선택된 DSD들 각각을 할당할 수 있으며, 이는 다음과 같은 정보를 포함할 수 있다:

어떤 유형들의 DS가 식별될 것인가에 대한 것이다. 예를 들어, 주어진 DE에 대해, 단계 1에서 도입된 바와 같은 "Raw_Data_Type"는 어떤 유형의 DS들이 식별될 것인지를 나타낸다. 주어진 DSD가 복수의 DE에 대한 잠재적인 DS들을 식별하는데 이용될 수 있는 것이 가능하다. 이러한 경우에, 주어진 DSD는 복수의 DS 식별 계획을 가질 수 있고, 이들 각각은 주어진 DE에 대응한다.

어떤 작업 범위에 대해 (예를 들어, 어느 조직 내에서 또는 어느 지리적 영역 등 내에서) DS 식별 동작들을 수행하는지에 대한 것이다.

DS에 대한 임의의 다른 요건이다. 스마트 도시 분석 이용 사례에서 이용되는 예에 따르면, DE-1은 매 3분마다 평균 온도를 계산할 것이다. 따라서, DE-1에 대해, DE-1의 잠재적인 DS들에 대한 요건들 중 하나는 (DS들로서의) 온도 센서들이 실내 온도 센서들이 아니라 실외 온도 센서들이어야 하는 것일 수 있다.

단계 3에서, 각각의 DE에 대해, DSCS 에이전트-1은 그 선택된 DSD들 각각에 대해 생성된 상세한 DS 식별 계획과 함께 그 DE에 대한 DS 식별 동작을 수행하라는 요청을 선택된 DSD들 각각(예컨대, LFN-1 상의 DSCS 에이전트-2)에 전송한다. 다시 말해서, 각각의 DE에 대해, 선택된 DSD들 각각에 대한 DS 식별 계획은 이들이 함께 작업하여 이 DE에 대한 DS 식별 작업을 협력적으로 달성할 수 있도록 상이하다. 선택된 DSD가 복수의 DE에 대한 DS 식별 작업들에 참여하는 경우, DSCS 에이전트-1은 상이한 DE들에 대한 모든 DS 식별 작업들이 포함되는 이 선택된 DSD에 단일 요청을 전송할 수 있다.

단계 4에서, 선택된 DSD들 각각 상의 DSCS 에이전트는 그 각각의 DS 식별 계획에 따라 DS 식별을 수행할 수 있다. 예를 들어, LFN-1 상의 DSCS 에이전트-2는 DS-1이 원하는 DS인지를 평가하기 위해(예를 들어, DS-1이 온도 센서인지, 그리고 DS-1이 실외에 위치하는지를 평가하기 위해) DS-1에 대한 DS 식별을 수행하는 것을 담당한다. LFN-1은 DS 식별을 수행하기 위해 DS-1에 액세스할 필요가 있을 수 있다. oneM2M을 예로 들면, (DSD로서) 시맨틱 가능 CSE-1은 온도 데이터 소스를 발견하고자 하는 경우, CSE-2 상에서 호스팅되는 (DS-1로서) <container-1> 리소스를 식별하기 위해 시맨틱 발견 메커니즘을 이용하고 온도 판독치들을 저장할 수 있다. 추가적으로 또는 대안적으로, DS-1은 CSE-1에 등록될 수 있고(예컨대, <container-1> 리소스는 CSE-1에 의해 호스팅되고), CSE-1은 DSD로서 동작할 수 있다. 이러한 경우에, CSE-1은 DS 식별을 위해 DS-1의 등록 정보를 직접 체크할 수 있고 DS-1과 대화할 필요가 없을 수 있다. DSD들 각각 상의 DSCS 에이전트는 또한 각각의 식별된/후보 DS에 관한 추가의 유용한 정보를 수집할 필요가 있을 수 있다. 관련 정보는 (DS-1을 예로 들면) 다음의 양태들을 포함할 수 있지만 이에 제한되지는 않는다:

DS-1의 데이터 속도;

DS-1의 데이터 단위;

DS-1의 지리적 위치;

DS-1로부터 원시 데이터를 검색할 액세스 권한들을 갖는 LFN들(즉, RDC 후보들이 됨); 및

DS-1의 이용가능성 스케줄.

단계 5에서, 선택된 DSD들 각각 상의 DSCS 에이전트(예컨대, LFN-1 상의 DSCS 에이전트-2)는 단계 4에서 도입된 바와 같은 식별된 DS들에 관한 관련 정보와 함께 그 DS 식별 결과를 다시 전송한다.

스테이지 2는 DS 식별 결과 통합 및 RDC/RDP 작업 할당을 포함할 수 있다. 스테이지 2에서, LFNL의 주요 작업은 스테이지 1 동안 DSD들로부터 모든 DS 식별 결과들을 통합하고, 각각의 DE들에 대한 원하는 DS들의 리스트를 결정하는 것이다. 다시 말해서, 원시 데이터는 그 선택된 DS들로부터 수집될 수 있다. 선택된 DS들 각각에 대해, LFNL은 스테이지 1 동안에 식별된 바와 같이 이 DS에 관한 관련 정보에 기반하여 적절한 RDC(들)를 이에 할당할 필요가 있을 수 있다. LFNL은 또한 선택된 DS들 각각에 대해 적절한 RDP들을 할당할 필요가 있을 수 있고, 이들 RDP들은 그 선택된 DS들의 원시 데이터를 처리하고 RDS들을 생성하는 것을 담당할 수 있다. DS 식별 결과 통합 및 RDC/RDP 작업 할당을 위한 예시적인 절차가 도 21에 도시되고 이하에서 논의된다.

단계 1에서, DSCS 에이전트-1은 DSCR-1에 대한 복수의 DSD로부터 DS 식별 결과들을 수신하였다(이것은 도 20의 단계 5의 결과이다). 예를 들어, DSCR-1의 RDS들 내의 각각의 DE에 대해, 상이한 DSD들에 의해 식별되었던 복수의 DS가 존재할 수 있다. 따라서, DSCS 에이전트-1은 DE 각각에 대한 모든 식별된 DS들을 평가할 수 있다. 식별된 DS들 모두가 DSCR-1에 대한 원하는 DS들로서 선택될 것은 아닐지라도, 모든 식별된 DS들이 DSCS 에이전트-1에 의해 기록될 수 있다는 것에 유의한다. 그 이유는 이러한 DS 식별 결과들이 다른/미래의 DSCR들을 서빙할 때 재이용될 수 있다는 것이다. 따라서, 스테이지 1에 대한 추가적인 개선 중 하나는, 도 20의 단계 2 동안, 특정 DSCR에 대한 DSD들로서 적절한 LFN들을 선택하기 전에, DSCS 에이전트-1은 먼저 DS 식별 결과 이력 기록들을 체크할 수 있고, 이전 DSCR들에 대해 식별된 임의의 기존의 DS들이 이 새로운 DSCR을 서빙하는데 재이용될 수 있는지를 알아볼 수 있다는 것이다. 이러한 방식으로, DS 식별 동작들의 오버헤드가 감소될 수 있다.

단계 2에서, DSCS 에이전트-1은 DE들 각각에 대한 원하는 DS들의 리스트를 선택한다. 이 단계는 이 DE에 대한 모든 식별된 DS들 중에서 원시 데이터가 어느 DS들로부터 수집될지를 선택하기 위해 수행될 수 있다.

주어진 DS에 대해, 고려되고 포함될 관련 정보는 (예를 들어, 도 20의 단계 4에서) DS 식별 프로세스 동안 획득되었을 수 있는 다음을 포함할 수 있다:

DS의 데이터 속도;

DS의 데이터 단위;

DS의 지리적 위치;

DS로부터 원시 데이터를 검색할 액세스 권한들을 갖는 LFN들; 및

DS의 이용가능성 스케줄.

스마트 도시 분석 이용 사례에서 이용되는 예로서, (매 3분마다의 평균 온도인) DE-1에 대해, (DE-1에 대한 DS 후보들로서) 200개의 온도 센서가 스테이지 1 동안 복수의 DSD들에 의해 식별되었고, 이러한 온도들이 LFA-X에 의해 커버되는 전체 지리적 영역에 걸쳐 분포되는 것으로 가정된다.

DE 그 자체에 관한 특정 정보가 또한 고려될 필요가 있을 수 있으며, 이는 (예를 들어, "Quality_Requirements" 파라미터에서) 도 20의 단계 1에서 도입된 바와 같이 DSCR-1에서 설명된 것이다. 스마트 도시 분석 이용 사례에서 이용되는 예에 따르면, DE-1에 대해, 정확도를 보장하기 위해 LFA-X에 배치된 적어도 100개의 상이한 온도 센서로부터 온도 판독치들이 수집될 필요가 있다는 것이 요구된다.

주어진 DE 및 그 대응하는 식별된 DS들 둘 다에 관한 정보를 고려함으로써, DSCS 에이전트-1은 어느 DS들이 원시 데이터가 수집될 원하는 DS들인지를 결정할 수 있다. 스마트 도시 분석 이용 사례에서 이용되는 예에 따르면, (매 3분마다의 평균 온도인) DE-1에 대해, (DS 후보들로서) LFA-X에서의 총 200개의 온도 센서 중에서 DE-1에 대한 원하는 DS들로서 100개의 온도 센서가 선택될 수 있다.

단계 3에서, 각각의 원하는 DS에 대해, DSCS 에이전트-1은 그에 대한 RDC를 추가로 선택한다. 일반적으로, 선택된 DS 각각에 대해 RDC가 필요하고, 이러한 RDC는 DS로부터 원시 데이터를 수집하고 처리를 위해 원시 데이터를 대응하는 RDP에 전송하는 것이다. 제안된 해결책을 보다 일반적으로 하기 위해, RDC 및 RDP가 단지 논리적 역할들이며, 따라서 LFN이 주어진 DS에 대한 RDC뿐만 아니라 이 DS에 대한 RDP일 수 있는 것도 가능하다는 점에 주목할 가치가 있다. 비록 원하는 DS들 각각에 대해 RDC가 선택될 수 있지만, 주어진 LFN은 복수의 DS들에 대한 RDC로서 동작할 수 있다. 다시 말해서, 주어진 LFN은 복수의 DS들로부터 데이터를 수집하는 것을 담당할 수 있다. 예시의 용이함을 위한 이하의 설명들에서, 주어진 DS에 대해, 그 RDC 및 RDP는 상이한 LFN들에 의해 취해질 수 있다고 가정된다.

각각의 원하는 DS에 대한 RDC를 추가로 선택하기 위해, 다음과 같은 정보가 평가될 필요가 있을 수 있다:

DSCS 에이전트-1은 (스테이지 1 동안 획득되었을 수 있는) 이 DS로부터 원시 데이터를 검색할 액세스 권한들을 갖는 어떤 LFN들에 관련한 DS에 대한 관련 정보를 체크할 필요가 있을 수 있다. 이러한 정보는 대략적인 또는 미세한 것으로 설명될 수 있다. 예로서, 주어진 DS-1은 DS-1과 동일한 조직에 속하는 임의의 LFN들이 DS-1로부터 데이터를 검색할 수 있는 것과 같은 대략적인 액세스 제어 정보를 가질 수 있다. 다른 예로서, 주어진 DS-1은 DS-1로부터 200 미터 내에 있는 임의의 LFN이 DS-1로부터 데이터를 검색할 수 있는 것과 같은 다른 대략적인 액세스 제어 정보를 가질 수 있다. 미세한 액세스 제어 정보의 경우, 특정 LFN들(예컨대, LFN-1 및 LFN-27)만이 DS-1로부터 데이터를 검색할 수 있는 것이 그 예일 수 있다. 다른 예는 (DS로서) 특정 <container> 리소스의 ACP 규칙들이 이 리소스에 대한 "검색" 특권을 갖는 (RDC 후보들로서) 특정 CSE들/AE들의 리스트를 표시하는 oneM2M 예일 수 있다.

DSCS 에이전트-1은 어느 LFN들이 RDC로서 동작할 수 있고 동작하려고 하는지를 식별하기 위해 LFN 능력 표를 체크할 필요가 있을 수 있다. 주어진 LFN이 정교한 DS 식별 능력을 가질 수 있지만, 기여할 의향이 없는 것이 가능하다. 이러한 경우에, 주어진 LFN은 그 능력들을 (LFN 능력 등록 프로세스에서 도입된 바와 같이) 대응하는 LFNL에 등록할 때, RDC로서 동작하고자 한다는 것을 표시하지 않을 수 있다. "Other_Context_Information" 파라미터는 그 가입 조직 및 그 지리적 위치 등과 같은 특정 LFN의 일반적인 컨텍스트를 설명한다.

특정 DS에 대한 액세스 제어 정보는 특정 LFN들과 관련된 액세스 특권 정보와 비교되어, 이 DE에 대한 RDC로서 적절한 LFN을 선택할 수 있다. 이전의 예를 계속하면, 주어진 LFN-1에 대해, DS-1과 동일한 조직에 가입되면, DS-1의 액세스 제어 규칙이 DS-1과 동일한 조직에 속하는 임의의 LFN들이 DS-1로부터 데이터를 검색할 수 있음을 정의하는 경우, LFN-1은 DS-1에 대한 RDC로서 선택될 수 있다(예컨대, DS-1의 액세스 제어 정책은 LFN-1의 액세스 특권과 일치된다). 신뢰성을 향상시키기 위해, 주어진 DS에 대해 복수의 RDC들이 선택될 수 있으며, 하나의 RDC가 이 DS에 대한 마스터 RDC로서 지정될 수 있는 반면, 다른 것들은 2차/백업 RDC들이라는 점에 유의한다. 그 결과, 마스터 RDC는 이 DS로부터 원시 데이터를 수집하기 위한 1차 또는 "마스터" RDC이지만, 마스터 RDC가 원시 데이터 수집을 수행할 수 없다면 2차 RDC들에 의해 대체될 수 있다.

단계 4에서, DSCS 에이전트-1은 각각의 DE에 대한 RDP 작업 할당 계획을 생성한다. 주어진 DE-1에 대한 예시적인 작업흐름은 다음과 같을 수 있다:

DE-1에 대해, DSCS 에이전트-1은 먼저 RDS들에서 DE-1의 DS들로부터 수집된 원시 데이터와 DE-1의 최종 형태 사이에서 얼마나 많은 데이터 처리 단계들이 필요한지를 알아낸다. 스마트 도시 분석 이용 사례에서 이용되는 예에 따르면, DE-1은 매 3분마다의 평균 온도이다. 즉, 단일 RDS에서, DE-1의 최종 형태는 "주어진 3분 시간 간격 동안의 LFA-X에 대한 평균 온도"인 반면, DE-1에 대한 원시 데이터는 그 3분 시간 간격 동안 복수의 온도 센서로부터 수집된 온도 판독치들이다. 따라서, 이 예는 두 가지 데이터 처리 단계를 가질 수 있다:

데이터 처리 단계 1: 하나의 온도 판독치 부분에 대해, 제1 처리는 온도 센서로부터 수집된 원래의 원시 데이터로부터 데이터 판독치 및 (타임스탬프와 같은) 다른 유용한 컨텍스트 정보를 추출하는 것이다. 다른 전처리도 필요할 수 있다. 예를 들어, DE-1의 최종 형태가 데이터가 섭씨인 것을 요구하면, 원시 데이터가 화씨인 경우 단위 변환이 필요하다. 따라서, RDP(들)는 RDC들에 의해 수집된 원시 데이터를 수신하기 위한 제1 레벨 RDP 노드인 이 단계에 대해 결정될 수 있다.

데이터 처리 단계 2: DE-1의 모든 원하는 DS들로부터 수집된 원시 데이터는, RDS들 각각에서의 DE-1의 최종 형태인, 매 3분마다의 평균 온도를 계산하기 위해 함께 처리될 필요가 있을 수 있다. 따라서, RDP(들)는 또한, 데이터 처리 단계 1에서 RDP(들)에 의해 출력된 처리된 데이터를 수신하기 위한 제2 레벨 RDP 노드인 이 단계에 대해 결정될 수 있다. 데이터가 더 많은 특정한 데이터 처리 동작들을 이용하여 추가로 처리될 필요가 있다면 이 단계 후에 추가적인 단계들이 있을 수 있다는 점에 유의한다.

다음 단계는 위에서 정의된 단계들 각각에 대해 적절한 LFN들을 선택하는 것이다. 예를 들어, 단계 1에 대해, 원시 데이터로부터 유용한 데이터 부분들을 추출하기 위해 특정 맞춤화된 데이터 처리 코드 스니펫이 필요할 수 있다. 따라서, RDP 후보들로서의 LFN들은 맞춤화된 코드 또는 소프트웨어가 실행될 수 있는 이러한 LFN들이다. 다른 예에서, 간단한 데이터 집계 능력들을 갖는 LFN들은 단계 2에 대한 RDP들로서 필요할 수 있다. DSCS 에이전트-1은 어느 LFN들이 위의 단계들 각각에 대한 RDP들로서 동작할 수 있는지를 식별하기 위해 LFN 능력 표를 추가로 체크할 수 있다. 수집 및/또는 처리될 원시 데이터가 많은 양일 수 있기 때문에, 복수의 LFN들이 특정 데이터 처리 단계들 각각에 대한 RDP들로서 필요하고 선택될 수 있다. 스마트 도시 분석 이용 사례에서 이용되는 예에 따르면, (매 3분마다의 평균 온도인) DE-1에 대해, 100개의 온도 판독치가 100개의 원하는 DS(예컨대, 온도 센서)로부터 수집될 수 있다. 2개의 LFN이 단계 1에 대한 2개의 RDP로서 선택되는 것이 가능하다. 각각의 RDP는 단계 1 동안 DS들의 절반(예컨대, 50개의 온도 센서)으로부터의 원시 데이터를 처리하는 것을 담당할 수 있다. 주어진 단계에 대한 복수의 RDP들이 있을 때, 하나의 RDP가 이 단계에 대한 마스터 RDP로서 지정될 수 있는 반면, 다른 RDP들은 2차/백업 RDP들이다. 그 결과, 마스터 RDP는 이 단계 동안 데이터 처리를 위한 주요 RDP이지만, 마스터 RDP가 요구되는 데이터 처리 동작들을 수행할 수 없다면 2차 RDP들로 대체될 수 있다. 마스터 RDP는 과부하되는 경우, 그 작업부하를 이러한 2차 RDP들에 또한 넘길 수 있다. 단계 2에 대해, 100개의 온도 판독치(이는 단계 1 후의 처리된 100개의 온도 판독치임)의 평균 값을 계산하는 것이기 때문에, 평균 동작은 단일 LFN에서 실행될 필요가 있을 수 있다. 따라서, 강력한 LFN이 단계 2에 대한 RDP로서 선택될 수 있다.

마지막 단계는 완전한 데이터 처리 흐름 계획을 구성하기 위해 상이한 데이터 처리 단계들에서 선택된 RDP들을 함께 연결하거나 링크하는 것이다. 복수의 RDP들이 제1 단계(예를 들어, 스마트 도시 분석 이용 사례에서의 단계 1)에 대해 선택될 때, DSCS 에이전트-1은 제1 단계에서 특정 RDP에 DS들 각각을 할당할 필요가 있을 수 있다. 다시 말해서, 주어진 DS로부터의 원시 데이터는 제1 단계에서의 처리를 위해 그 할당된 RDP로 전송되어야 한다. 제1 단계(예컨대, 단계 1)에 대해 하나의 RDP만이 선택되었다면, 모든 DS들의 원시 데이터는 제1 단계에서 이 단일 RDP에 전송될 수 있다. RDC들이 원하는 DS들로부터 원시 데이터를 수집하는 것을 담당하기 때문에, 주어진 DS에 대해, 그 대응하는 RDC는 RDC들이 처리를 위해 원시 데이터를 전송할 곳(예컨대, 어느 RDP들)을 알 수 있도록 이러한 RDP 할당 결정을 통지받을 필요가 있을 수 있다.

유사하게, 마지막 단계(예를 들어, 스마트 도시 분석 이용 사례에서의 단계 2)에서의 RDP들에 대해, DSCS 에이전트-1은 또한 처리된 데이터가 이 단계 후에 전송되어야 하는 곳을 결정할 필요가 있을 수 있다. 스마트 도시 분석 이용 사례에 따르면, 단계 2 동안 특정 3분에 대한 평균 온도 판독치가 생성될 때, 이는 이 데이터가 단지 DE-1에 대한 것이기 때문에 아직 완전한 RDS가 아니다. 완전한 RDS는 2개의 DE(예를 들어, DE-1 및 DE-2)를 포함할 수 있다. 따라서, 다음 단계는 (RDS-조립 RDP라고 하는 다른 RDP에 의해 행해질 수 있는) DE-1 및 DE-2의 최종 형태 데이터를 조립함으로써 완전한 RDS를 생성하는 것일 수 있다. 2개의 상이한/인접한 단계에서의 RDP들에 대해, DSCS 에이전트-1은 또한, 단계 i에서의 RDP에 의해 처리된 데이터 중 어느 것이 다음 단계 i+1에서의 어느 RDP로 전송되어야 하는지를 결정할 필요가 있을 수 있다.

마지막으로, DSCS 에이전트-1은 LFN을 RDS-조립 RDP로서 선택하고, 처리된 데이터를 각각의 DE에 대한 마지막 데이터 처리 단계에서 RDP들에 의해 수신하고 상이한 DE들의 데이터를 함께 조립하여 RDS들을 구성한다. 스마트 도시 이용 사례를 예로 들면, DE-1에 대해, 그 마지막 데이터 처리 단계의 출력된/처리된 데이터는 특정 3분 시간 간격 동안의 평균 온도일 수 있다. 이러한 데이터는 DE-2에 대한 다른 데이터(예컨대, 동일한 3분 시간 간격 동안의 평균 습도)와 조립될 수 있다. 이 예에서 RDS 정의에 따라, 각각의 RDS가 (DE-1, DE-2, 타임스탬프)의 포맷을 갖기 때문에, 2개의 데이터 부분은 완전한 RDS로서 함께 조립될 수 있다.

단계 5에서, (단계 3에서 결정된 바와 같이) 주어진/원하는 DS에 대한 (RDC들로서의) 선택된 LFN들 각각에 대해, DSCS 에이전트-1은 데이터 수집 작업들을 할당하기 위해 이러한 LFN들과 접촉할 수 있다. 예를 들어, DSCS 에이전트-1이 특정 LFN-1에 RDC 작업 할당 요청을 전송할 때, 다음의 정보는 특정 DS에 대한 예시적인 원시 데이터 수집 작업을 설명한다(즉, 특정 LFN에 대한 RDC 작업 할당은 복수의 DS에 대한 데이터 수집 작업들의 리스트를 포함할 수 있다):

작업 ID이다. 이것은 이 작업에 대한 특정 작업 ID이다. RDC는 제1 데이터 처리 단계에서의 RDP에 원시 데이터를 전송할 때, 어느 작업이 이 원시 데이터와 관련되는지를 나타낼 필요가 있을 수 있다(그리고 이 작업이 어느 DSCR 및 어느 DE에 관련되는지를 추가로 나타낼 수 있음).

DS의 ID(예컨대, URL)이다.

(예를 들어, 이 DS로부터 데이터를 수집할 때의) 데이터 수집 스케줄이다. 이 스케줄은 DSCR-1에 대한 RDS_Production_Schedule 파라미터와 정렬될 수 있다.

RDP의 ID이다. 이것은 DS의 원시 데이터가 전송되어야 하는 곳을 나타낸다. 다시 말해서, RDC는 DS로부터 원시 데이터를 수집하고 이 파라미터에 표시된 바와 같이 원시 데이터를 RDP에 전송할 수 있다.

일부 LFN들은 DSCS 에이전트-1에 의해 요구되는 바와 같이 작업 할당을 수락하지 못할 수 있는 것이 가능하다. 따라서, 이 단계 동안 복수의 협의 프로세스가 있을 수 있다.

단계 6에서, DSCS 에이전트-1은 DSCR-1에 관련된 특정 DE에 대한 RDC로서 LFN-1을 선택하고, LFN-1 상의 DSCS 에이전트-2는 RDC 할당을 확인응답한다.

단계 7에서, (단계 4에서 결정된 바와 같이) (RDP로서) 선택된 LFN들 각각에 대해, DSCS 에이전트-1은 데이터 처리 작업들을 할당하기 위해 이러한 LFN들과 접촉할 수 있다. 예를 들어, DSCS 에이전트-1은, LFN-2에 할당된 복수의 작업들을 또한 포함할 수 있는, 특정 LFN-2에 RDP 작업 할당 요청을 전송할 수 있다. 예를 들어, 주어진 LFN은 특정 DE에 대한 상이한 데이터 처리 단계들에서 RDP로서 동작할 수 있다. 더 일반적으로, 주어진 LFN은 상이한 DE들에 대한 데이터 처리를 위한 RDP로서 기능할 수 있다. 예를 들어, LFN-2는 DE-1에 대한 RDP로서 동작할 수 있고, 이 동안에 LFN-2는 DE-1의 데이터 처리 단계 1에 대한 요구된 데이터 처리를 수행한다. LFN-2는 또한 DE-2에 대한 RDP로서 동작할 수 있으며, 이 동안에 LFN-2는 DE-2의 데이터 처리 단계 2에 대한 요구된 데이터 처리를 수행한다. 어떤 LFN(예컨대, LFN-2)이 그 수반되는 작업들 각각에 대해 수행될 필요가 있는지를 설명하기 위해 다음과 같은 정보가 포함될 수 있다:

작업 ID: 이것은 이 작업에 대한 특정 작업 ID이다. 업스트림 데이터 전송기가 처리된 데이터를 다운스트림 데이터 수신기에 전송할 때, 어떤 작업이 이 처리된 데이터를 위한 것인지를 나타낼 필요가 있을 수 있다.

업스트림 데이터 전송기의 ID들 및 관련 작업 ID: 이것은 누가 처리된 데이터를 처리를 위해 LFN-2에 전송할 것인지를 나타내기 위한 것이다. 업스트림 전송기로부터 전송된 데이터는 또한 (업스트림 데이터 전송기에 의해 행해지는 작업의 ID인) 다른 작업 ID와 연관될 수 있다. 예를 들어, LFN-2가 DE-1에 대한 제1 데이터 처리 단계에 대한 RDP인 경우, DE-1의 RDC들은 DE-1의 원하는 DS들로부터 원시 데이터를 수집하고 이들을 처리를 위해 LFN-2로 전송할 업스트림 데이터 전송기들일 수 있다. 다른 예에서, LFN-2가 DE-1에 대한 제2 데이터 처리 단계에 대한 선택된 RDP인 경우, LFN-2의 업스트림 데이터 전송기들은, 제2 단계에 대한 처리를 수행하기 위해 그 처리된 데이터를 LFN-2에 전송하는, DE-1에 대한 제1 데이터 처리 단계에서의 RDP들일 수 있다. RDP로서 동작하는 LFN에 의해 RDC의 역할이 또한 취해질 수 있다는 점에 주목할 가치가 있다. 예를 들어, LFN-2는 특정 DE-1에 대한 원시 데이터를 수집하기 위한 RDC로서 선택되는 것이 가능하다. LFN-2는 또한 데이터 처리 능력들을 가질 수 있고, 또한 DE-1에 대한 제1 데이터 처리 단계에 대한 RDP로서 선택된다. 이 경우, LFN-2는 RDC 및 RDP 모두로서 조합된 역할을 한다.

Required_Data_Processing_Operation: 이것은 어떤 특정 데이터 처리 동작들이 수행될 것인지를 나타낸다. 맞춤화된 코드가 다운로드될 필요가 있다면, 이 파라미터는 또한 데이터 처리 코드를 다운로드할 곳을 나타낸다.

다운스트림 데이터 수신기의 ID들: 이것은 일단 LFN-2가 이러한 특정 작업에 대한 처리를 완료하면 처리된 데이터를 전송할 곳을 나타내기 위한 것이다. 예를 들어, LFN-2가 DE-1에 대한 제1 데이터 처리 단계에 대한 선택된 RDP인 경우, DE-1에 대한 제2 데이터 처리 단계에 대한 RDP들은 LFN-2에 의한 처리된 데이터에 기반하여 추가 데이터 처리 동작들을 수행하는 다운스트림 데이터 수신기들일 수 있다. LFN-2가 그 처리된 데이터를 그 다운스트림 데이터 수신기로 전송할 때, 이것은 또한 처리된 데이터를 LFN-2 자체에 의해 행해지는 작업의 ID(예컨대, 작업 ID에 정의된 바와 같음)인 작업 ID와 연관시킬 필요가 있을 수 있다.

일부 LFN들은 DSCS 에이전트-1에 의해 요구되는 바와 같이 작업 할당을 수락하지 못할 수 있는 것이 또한 가능하다. 따라서, 이 프로세스 동안 복수의 협의 단계가 있을 수 있다.

또한, 주어진 LFN에 대해, 이것이 RDC뿐만 아니라 주어진 DSCR을 서빙하기 위한 RDP로서 선택되면, DCCS 에이전트-1은 RDC 및 RDP 작업 할당을 위해 하나의 메시지를 이 LFN에만 전송할 수 있다. 이러한 경우에, 단계 5 및 단계 7이 결합될 수 있다.

단계 8에서, LFN-2 상의 DSCS 에이전트-3은 RDP 할당을 확인응답한다.

마지막으로, DSCS 에이전트-1은 DSCR-1에 대한 작업 할당 프로파일을 생성할 수 있으며, 이는 어느 LFN들이 각각의 DE에 대한 RDC들로서 선택되는지 또는 어느 LFN들이 DSCR-1에 대한 RDS들을 생성하는데 요구되는 데이터 처리 동작들을 위한 RDP들로서 선택되는지에 관한 모든 상세들을 포함할 수 있다.

협력적 RDS 생성 및 전달을 위한 방법들 및 시스템들이 본 명세서에 개시된다. 이하의 예에서, LFA에서 RDS 생성 프로세스를 시작하기 위한 프로세스가 개시된다.

주어진 DSCR에 대해, DS 식별 및 RDC/RDP 할당이 완료된 후에, 이 DSCR에 대한 RDS들을 생성하기 위해 즉시 시작할 필요가 없을 수 있다. 다시 말해서, RDS 생성은 (예를 들어, 트리거에 기반하여) 나중에 또는 특정 스케줄(예컨대, 도 21의 단계 1에 포함된 "RDS_Production_Schedule" 파라미터에 표시된 바와 같은 정보)에 기반하여 시작될 수 있다. 일반적으로, RDS 생성 활성화는 사용자에 의해 개시될 수 있다(예를 들어, RDS 생성 트리거는 CN으로부터 LFA들로 전송될 수 있다). 주어진 DSCR에 대해, LFNL은, 이 DSCR의 RDS들의 각각의 DE에 대해, 어느 DS들이 원하는 또는 선택된 DS들인지를 결정할 필요가 있을 수 있다. 추가적으로 또는 대안적으로, LFNL은 원하는 DS 각각에 대해, 어느 LFN이 선택된 RDC인지 그리고/또는 각각의 DE에 대해, 어느 LFN들이 이 DE의 원하는 DS들로부터 수집된 데이터를 처리하기 위한 선택된 RDP들인지를 결정할 필요가 있을 수 있다(이들 작업 할당들 모두는 협력적 DS 식별 프로세스의 스테이지 1 및 스테이지 2 동안 결정되었을 수 있다). 그 다음, LFNL은, 어느 특정 작업들이 현재 실행될 필요가 있는지에 관한 지침과 함께, 관련된 LFN들 각각에 트리거들을 전송할 수 있다.

일 예에서, 데이터 샘플 수집 서비스는, 특정 데이터 샘플 수집 요청과 연관된 데이터 샘플의 생성을 개시하라는 표시를 포함하는 트리거를 수신하는 것; 원시 데이터 수집을 수행하도록 구성된 적어도 하나의 로컬 포그 노드 및 원시 데이터 처리를 수행하도록 구성된 적어도 하나의 로컬 포그 노드를 결정하는 것; 원시 데이터 수집을 수행하도록 구성된 적어도 하나의 로컬 포그 노드에, 원시 데이터 수집을 개시하라는 표시를 전송하는 것; 원시 데이터 수집을 수행하도록 구성된 적어도 하나의 로컬 포그 노드로부터, 원시 데이터 수집이 개시되었다는 표시를 수신하는 것; 원시 데이터 처리를 수행하도록 구성된 적어도 하나의 로컬 포그 노드에, 원시 데이터 처리를 개시하라는 표시를 전송하는 것; 및 원시 데이터 처리를 수행하도록 구성된 적어도 하나의 로컬 포그 노드로부터, 원시 데이터 처리가 개시되었다는 표시를 수신하는 것을 포함하는 동작들을 수행하도록 구성될 수 있다.

원시 데이터 수집을 개시하라는 표시 및 원시 데이터 처리를 개시하라는 표시 각각은 작업 식별자를 포함할 수 있다. 트리거는 클라우드 노드로부터 수신될 수 있다. 원시 데이터 수집을 수행하도록 구성된 적어도 하나의 로컬 포그 노드 및 원시 데이터 처리를 수행하도록 구성된 적어도 하나의 로컬 포그 노드를 결정하는 것은 데이터 샘플 수집 서비스에 저장되는 작업 할당 프로파일에 액세스하는 것을 포함한다. 원시 데이터 수집을 수행하도록 구성된 적어도 하나의 로컬 포그 노드 및 원시 데이터 처리를 수행하도록 구성된 적어도 하나의 로컬 포그 노드는 동일한 로컬 포그 노드에서 구현될 수 있다. 데이터 샘플 수집 서비스는 로컬 포그 노드 리더에서 구현될 수 있다.

다른 예에서, 로컬 포그 노드는, 데이터 샘플 수집 서비스로부터, 원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나를 수행하라는 요청을 수신하는 것 - 데이터 샘플 수집 서비스는 로컬 포그 노드 리더에서 구현됨 -; 원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나를 개시하는 것; 및 원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나가 개시되었다는 표시를 데이터 샘플 수집 서비스에 전송하는 것을 포함하는 동작들을 수행하도록 구성될 수 있다.

원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나를 수행하라는 요청은 작업 식별자를 포함할 수 있다. 원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나를 수행하라는 요청을 수신하는 것은 원시 데이터 수집을 수행하라는 제1 요청을 수신하는 것 - 제1 요청은 제1 작업 식별자를 포함함 -, 및 원시 데이터 처리를 수행하라는 제2 요청을 수신하는 것 - 제2 요청은 제2 작업 식별자를 포함함 - 을 포함할 수 있다. 원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나를 수행하라는 요청은 데이터 샘플 수집 서비스에 저장된 작업 할당 프로파일에 기반할 수 있다. 데이터 처리 동작은 데이터 수집 동작의 적어도 부분적 완료에 기반하여 자동으로 수행될 수 있다. 원시 데이터 수집 및 원시 데이터 처리 동작들 중 적어도 하나를 수행하라는 요청은 데이터 샘플 수집 서비스에 저장된 스케줄에 기반할 수 있다.

LFA들에서 RDS 생성을 트리거링하기 위한 예시적인 절차가 도 22에 도시되고 아래에 설명된다:

단계 1에서, DSCS 에이전트-1은 DSCR-1에 대한 RDS 생성을 개시하기 위한 트리거를 수신한다. 예를 들어, DSCR-1을 개시한 사용자는 트리거 요청을 CN에 전송함으로써 이 DSCR-1을 직접 활성화할 수 있다. CN은 이 트리거 요청을 LFA-1에서의 LFNL에 추가로 전달할 수 있다.

단계 2에서, DSCS 에이전트-1은 어느 LFN들이 DSCR-1에 대한 RDC들/RDP들로서 관여되는지를 알아낸다. 특히, DSCS 에이전트-1은 RDC/RDP 작업 할당 동안 어느 LFN들이 RDC들 또는 RDP들로서 선택되는지에 관한 모든 상세들을 포함하는, (도 21에 도시된 절차의 끝에서 생성되는 바와 같은) DSCR-1의 작업 할당 프로파일을 체크할 수 있다.

단계 3에서, DSCS 에이전트-1은 원하는 DS들로부터 데이터 수집을 시작하기 위해 관여된 LFN들(이는 DSCR-1을 서빙하기 위한 RDC들로서 선택되었음)에 접촉한다. DSCR-1의 대응하는 RDS들의 각각의 DE에 대해, DSCS 에이전트-1은 어느 DS들이 각각의 DE에 대한 원하는 DS들인지를 체크할 수 있다. DSCS 에이전트-1은 추가적으로 또는 대안적으로 DSCR-1의 작업 할당 프로파일에 포함된 바와 같은 정보에 기반하여 어느 LFN이 DS들 각각에 대한 RDC로서 할당되었는지를 체크할 수 있다. 주어진 LFN이 복수의 DS에 대한 RDC일 수 있다는 것이 가능할 수 있다는 점에 유의한다. 따라서, DSCS 에이전트-1이 또한 모든 관여된 작업 ID들을 포함할 수 있는, (RDC로서) 특정 LFN에 활성화 트리거를 전송할 때, 이 LFN에 할당된 DSCR-1과 관련된 모든 데이터 수집 작업들이 시작될 수 있다.

단계 4에서, RDC들(예컨대, LFN-1)은 데이터 수집이 시작되었음을 확인응답한다. 주어진 LFN(예컨대, LFN-1)에 대해, RDC는 단계 3에서 표시된 바와 같은 작업 리스트에 따라 원시 데이터 수집 활동들을 시작할 수 있다.

단계 5에서, DSCS 에이전트-1은 (도 21에 도시된 절차의 끝에서 생성된 작업 할당 프로파일에 설명된 바와 같은) RDC/RDP 작업 할당 동안 구성된 데이터 처리 작업들을 시작하기 위해 (DSCR-1을 서빙하기 위한 RDP들로서 선택된) 관여된 LFN들에 접촉한다. DSCS 에이전트-1은 DSCR-1의 작업 할당 프로파일에 포함된 바와 같은 정보에 기반하여 어느 LFN들이 DSCR-1의 DE들 각각에 대한 할당된 RDP들인지를 체크할 수 있다. 유의할 점은, 주어진 DE에 대해, 특정 LFN이 이 DE의 복수의 데이터 처리 단계들 동안의 RDP일 수 있다는 것이다. 특정 LFN은 상이한 DE들에 대한 RDP일 수 있다. 따라서, DSCS 에이전트-1이 활성화 트리거를 모든 관여된 작업 ID들을 또한 포함하는, (RDP로서) 특정 LFN에 전송할 때, 이 LFN에 할당된 DSCR-1과 관련된 모든 데이터 처리 작업들이 이제부터 시작될 수 있다.

단계 6에서, RDP들(예컨대, LFN-2)은 DSCR-1을 서빙하기 위한 데이터 처리가 시작되었다는 것을 확인응답한다(예컨대, 처리를 위해 RDC들로부터 데이터를 수신할 준비가 되어 있다). 주어진 LFN(예컨대, LFN-2)에 대해, RDP는 단계 5에서 표시된 바와 같이 작업 리스트에 따라 데이터 처리 활동들을 시작할 수 있다. 대안으로서, 단계 5 및 단계 6은 단계 3 및/또는 단계 4 전에 수행될 수 있다.

대안적 해결책으로서, 단계 5 및/또는 단계 6은 트리거들을 RDC들로 전송하는 것만이 필요하다는 점에서 필요하지 않을 수 있다는 점에 유의한다. 그 이유는 RDC들이 DS들로부터 데이터를 수집하는 것들일 수 있고 처리를 위해 데이터를 전송할 곳을 알 수 있기 때문이다. 따라서, RDP들은 처음으로 RDC들로부터 전송된 데이터를 수신할 때 트리거링될 수 있다. 예를 들어, RDC가 데이터의 제1 배치를 RDP에 전송하고 있을 때, RDC는 RDP가 수신된 데이터를 처리하기 위해 그 대응하는 작업을 시작할 수 있도록 작업 ID를 포함할 수 있다.

DSCR-1의 RDS 생성이 도 21의 단계 1에 포함된 "RDS_Production_Schedule" 파라미터에 표시된 바와 같은 특정 스케줄에 기반하는 경우, DSCR-1을 서빙하기 위한 RDC들 또는 RDP들로서 선택된 하나 이상의 관여된 LFN은 작업 스케줄에 따라 자동으로 작업하기 시작할 수 있다.

주어진 DSCR에 대해 RDS 생성이 시작되면, 관여된 RDC들/RDP들은 작업하기 시작할 수 있다. 특정한 DE에 대한 실제 RDS 생성을 위한 예시적인 절차가 도 23에 도시되고 이하에서 설명된다. 이 절차는 스마트 도시 분석 이용 사례를 예로 들며, 여기서 단일 RDS에서의 DE-1은 매 3분마다의 평균 온도이다. 특히, 100개의 온도 센서가 이미 DE-1에 대한 원하는 DS들로서 식별되었다.

단계 1에서, RDC 작업 할당에 따라, (RDC로서) LFN-2 상의 DSCS 에이전트-3은 DS-1 내지 DS-50의 원시 데이터를 수집하는 것을 담당한다고 가정된다. DSCS 에이전트-3은 생성되는 새로운 데이터가 존재하는지를 알아보기 위해 DS-1 및 DS-50에 주기적으로 액세스할 수 있다. 추가적으로 또는 대안적으로, 검색 동작들을 수행함으로써 원하는 DS들로부터 원시 데이터를 수집하는 대신에, 이들 DS들이 그들의 새로운 데이터를 통지들을 통해 RDC에 전송할 수 있도록, RDC는 원하는 DS들에 가입할 수 있다.

단계 2에서, RDC 작업 할당에 따라, (RDC로서) LFN-1 상의 DSCS 에이전트-2는 DS-51 내지 DS-100의 원시 데이터를 수집하는 것을 담당한다고 가정된다.

단계 3에서, DSCS 에이전트-3은 (DS-1 내지 DS-50의 수집된) 원시 데이터를 DE-1의 제1 데이터 처리 스테이지에 대한 RDP로서 동작하고 있는 LFN-3에 전송한다. 특히, DSCS 에이전트-3이 데이터의 제1 배치를 LFN-3으로 전송하고 있을 때, 이것은 LFN-3이 수신된 데이터를 처리하는 방법을 알 수 있을 작업 ID를 포함할 수 있다.

단계 4에서, LFN-2 상의 DSCS 에이전트-3과 유사하게, DSCS 에이전트-2는 (DS-51 내지 DS-100의 수집된) 원시 데이터를 DE-1의 제1 데이터 처리 단계에 대한 RDP로서 동작하고 있는 LFN-3에 전송한다.

단계 5에서, LFN-3 상의 DSCS 에이전트-4는 DE-1의 제1 데이터 처리 단계에 대한 원시 데이터를 처리한다. 예를 들어, 제1 단계 동안의 주요 데이터 처리 동작은 원시 온도 판독치로 구성된 하나의 부분에 대한 것이다. RDP는 원래의 원시 데이터로부터 데이터 판독치 및 다른 유용한 컨텍스트 정보(예컨대, 타임스탬프)를 추출하는 것이다. DE-1의 최종 형태가 데이터가 섭씨인 것을 요구하는 경우, 원시 데이터가 원래 화씨이면 단위 변환이 수행될 수 있다.

단계 6에서, LFN-3 상의 DSCS 에이전트-4는 제1 데이터 처리 단계에 대한 그 데이터 처리를 완료하면, 처리된 데이터를 DE-1의 제2 데이터 처리 단계에 대한 RDP로서 동작하고 있는 LFN-4에 전송할 수 있다. 유사하게, LFN-3 상의 DSCS 에이전트-4가 그 처리된 데이터를 LFN-4에 전송하고 있을 때, 이것은 LFN-4가 수신된 데이터를 처리하는 방법을 알 수 있을 작업 ID를 포함할 수 있다.

단계 7에서, LFN-4 상의 DSCS 에이전트-5는 제2 데이터 처리 단계에 대한 데이터를 처리하고, 최종 형태일 수 있는 DE-1에 대한 데이터를 생성한다. DE-1에 대한 데이터는 DE-1의 최종 형태인, 특정 3분 시간 간격에서의 평균 온도 값이다. 따라서, LFN-4의 출력은 매 3분마다의 LFA-1의 평균 온도 값일 수 있으며, 이는 (예를 들어, LFN-2 및 LFN-3으로부터) 제1 데이터 처리 단계에서 2개의 RDP로부터 전송된 처리된 데이터에 기반하여 계산된다. 그 후, LFN-4 상의 DSCS 에이전트-5는 처리된 데이터를 DSCR-1의 대응하는 RDS-조립 RDP에 전송할 수 있으며, 이는 DSCR-1에 대한 최종 RDS들을 생성하는 최종 RDP이다. (RDC 또는 RDP로서 동작하는) LFN의 경우, 이것은 각각 2차 RDC들 또는 RDP들인 다수의 피어 LFN들과 연관될 수 있다. 따라서, 원래 선택된 RDC 또는 RDP가 예상되는 바와 같은 요구된 작업들을 수행할 수 없는 경우(예를 들어, 과부하되거나 작업을 중지하는 경우), 작업부하들은 대응하는 2차 RDC들 또는 RDP들로 넘겨질 수 있다.

RDC들/RDP들은 단지 "논리적" 엔티티들일 수 있다. 특히, 도 23에 도시된 예에서, (제안된 아이디어들의 일반성을 제한하지 않아야 하는) 예시의 용이함을 위해 상이한 LFN들에 의해 상이한 역할들이 행해질 수 있다. LFN이 제1 데이터 처리 단계에 대한 데이터 처리를 수행하기 위한 RDC 및 RDP 둘 다일 수 있는 것이 가능하다는 점이 이해된다. 예를 들어, DSCS 에이전트-3은 RDC 및 제1 단계의 RDP 둘 다로서 동작할 수 있다. 상이한 예시적인 구성으로서, 이제 DSCS 에이전트-3이 모든 100개의 DS로부터 데이터를 수집할 수 있다고 가정하면, DSCS 에이전트-3은 그 100개의 DS로부터 데이터를 수집하고, 원시 데이터에 걸쳐 평균 동작을 직접 수행하고, 처리된 데이터를 제2 단계의 RDP인, 추가 처리를 위한 DSCS 에이전트-5로 전송할 수 있다.

일단 데이터가 주어진 DE에 대해 완전히 처리되면, 이것은 그 최종 형태일 수 있고 조립될 준비가 될 수 있다. 주어진 DSCR에 대한 RDS 조립을 위한 예시적인 절차가 도 24에 도시되어 있고, 이하에서 추가로 논의된다. 도 24의 절차는 스마트 도시 분석 이용 사례를 예로 들며, 여기서 단일 RDS에서의 DE-1은 주어진 LFA-1에 대해 매 3분마다의 평균 온도이고, 단일 RDS에서의 DE-2는 동일한 주어진 LFA-1에 대해 매 3분마다의 평균 습도이다. 따라서, 도 24에서의 단계 7의 출력은 DE-1의 최종 형태이다.

단계 1(도 24의 단계 7로부터 계속됨)에서, LFN-4 상의 DSCS 에이전트-5는 제2 데이터 처리 단계에 대한 데이터를 처리하였고 DE-1에 대한 최종 형태의 데이터를 생성했다. DSCS 에이전트-5는 처리된 데이터를 조립을 위해 LFN-6으로 전송한다. 특히, LFN-4 상의 DSCS 에이전트-5로부터의 DE-1의 출력 데이터 각각은 나중의 RDS 조립 동안 이용될 수 있는 특정 컨텍스트 정보와 연관될 수 있다. 도 23의 단계 7 동안 생성된 DE-1의 주어진 데이터 부분에 대해, 연관된 정보는 계산된 평균 온도가 특정 3분 시간 간격에 대응한다는 것을 나타낼 수 있다.

단계 2에서, LFN-5 상의 DSCS 에이전트-6은 DE-2에 대한 최종 형태의 데이터를 생성한, DE-2의 마지막 데이터 처리 단계에서의 RDP인 것으로 가정된다. 여기서, DE-2는 매 3분마다의 평균 습도이다. 유사하게, DE-2의 최종 형태의 데이터 각각은 또한 나중의 RDS 조립 동안 이용될 수 있는 특정 컨텍스트 정보와 연관될 수 있다. DSCS 에이전트-6은 최종 RDS 조립을 위해 DE-2에 관련된 처리된 데이터를 LFN-6에 전송할 수 있다.

단계 3에서, LFN-6 상의 DSCS 에이전트-7은 DE-1 및 DE-2의 최종 형태의 데이터를 조립하고 DSCR-1에 대한 RDS들을 생성한다. DE-1에 대한 하나의 데이터 부분 및 DE-2에 대한 하나의 데이터 부분은 이들이 동일한 특정 3분 시간 간격에 관련되면 함께 조립될 수 있다. 그 결과, RDS는 DSCR-1에 설명된 바와 같은 RDS 정의에 따르는 (DE-1, DE-2, context_information)의 포맷으로 생성될 수 있다.

단계 4에서, 생성된 RDS들은 지정된 어드레스들로 전달된다. 전형적으로, RDS 전달은 다음과 같은 옵션들을 가질 수 있다:

옵션 1: RDS-조립 RDP는 RDS 데이터 샘플을 DSCR-1의 사용자에게 하나씩 전송할 수 있고;

옵션 2: RDS-조립 RDP는 일괄적(예컨대, 매 100개의 RDS 샘플)으로 RDS들을 전송할 수 있고;

옵션 3: RDS-조립 RDP는 DSCR-1의 사용자에 의해 요구되는 바와 같이 특정 시점에 RDS 데이터 샘플을 전송할 수 있고/있거나;

옵션 4: RDS-조립 RDP는 RDS들을 로컬로 저장하고, DSCR-1의 사용자가 데이터를 다시 빼낼 수 있게 할 수 있다.

제안된 DSCS 해결책은 도 15에 도시된 바와 같이 oneM2M 서비스 계층에서 새로운 CSF로서 간주될 수 있다. 상이한 유형들의 M2M 노드들은 IoT 디바이스들, M2M 게이트웨이들, M2M 서버들, 이동 노드들(예컨대, 차량, 셀폰 등) 등과 같은 DSCS 서비스를 구현할 수 있다는 점이 이해되어야 한다. 특히, 이들 노드들에 대한 다양한/상이한 하드웨어/소프트웨어 능력들에 따라, 이들 노드들에 의해 구현되는 DSCS 서비스들의 능력들이 또한 변할 수 있다.

데이터 소스(DS)는 oneM2M AE 또는 CSE일 수 있다. 따라서, AE 또는 CSE에 의해 생성된 원시 데이터는, DS 식별 프로세스 동안 oneM2M 리소스 발견을 통해 식별될 수 있는 <container>, <timeSeries> 또는 <flexContainer> 리소스에 저장될 수 있다.

로컬 포그 노드(LFN)는 oneM2M CSE(예컨대, ASN-CSE)일 수 있다.

LFN 리더(LFNL) 및 포그 노드(FN)는 oneM2M CSE(예컨대, MN-CSE)일 수 있다.

클라우드 노드(CN)는 oneM2M CSE(예컨대, IN-CSE)일 수 있다.

DSCS 사용자는 oneM2M AE(예컨대, IN-AE) 또는 CSE일 수 있다.

<dscs>라고 불리는 새로운 가상 리소스가 도 16에 도시되어 있다. CSE는 DSCS 능력들을 갖는 경우(예컨대, DSCS 에이전트가 이 CSE 상에서 실행되고 있는 경우), <dscs> 자식 리소스를 가질 수 있다. 모든 DSCS 관련 요청들은 이 리소스를 향해 이루어질 수 있다. 예를 들어, 사용자는 DSCR 생성 요청을 CSE-1 상에서 호스팅된 <dscs> 리소스에 전송할 수 있다. 유사하게, CSE-1은 DSCR-1에 대한 DS 식별을 수행하고자 할 때, DSCR-1을 LFA에서 다른 CSE-2에 의해 호스팅된 <dscs> 리소스에 전송할 수 있고, 이는 LFNL로서 동작하고, 이 LFA에서 LFN들에 의해 수행될 모든 DS 식별 및 RDS 생성 활동들을 관리 및 조정한다. (LFN으로서의) CSE가 LFNL로서 동작하는 다른 CSE에 그 능력을 등록할 때, LFNL 상에서 동작하는 CSE에 <lfnCapability> 리소스가 생성될 수 있다. 이 리소스는 주어진 LFN이 어떤 능력들을 제공할 수 있는지(예컨대, DSD, RDC 및/또는 RDP로서 동작할 수 있는지)에 관한 모든 정보를 설명할 수 있다. 또한, LFNL과 LFN 사이의 모든 통신들에 대해(예컨대, LFNL이 RDC 또는 RDP 관련 작업을 LFN에 할당하거나, 또는 LFNL이 LFN에 트리거를 전송하여 할당된 RDC 또는 RDP 관련 작업을 시작할 때), 요청 발신자(예컨대, LFNL로서 동작하는 CSE)는 그 요청들을 수신기(예컨대, LFNL에 의해 관리되는, LFN으로서 동작하는 CSE)의 <dscs> 리소스를 향해 전송할 수 있다.

DSCS를 노출시키는 대안적인 방법은 "dscs_capability"라고 불리는 새로운 속성이 <CSE> 리소스에 대해 정의되는 것이고, 이는 이 CSE가 DSCS 능력을 갖는지를 나타낼 수 있다. 따라서, 모든 DSCS 관련 요청들은 <CSEBase> 리소스를 향해 전송될 수 있다.

LFN의 능력을 기록하기 위해 새로운 <lfnCapability> 리소스가 제안된다(예컨대, LFN이 그 능력들을 대응하는 LFNL에 등록할 때, <lfnCapability> 리소스가 생성될 수 있다). 리소스 속성들은 표 9에 정의된 파라미터들에 대응할 수 있다.

통상적으로, LFN(예컨대, CSE-1)이 LFNL로서 동작하는 다른 CSE-2에 그 능력을 등록할 때, LFNL 상에서 동작하는 CSE-2에 <lfnCapability> 리소스가 생성될 수 있다. 예를 들어, <lfnCapability> 리소스는 CSE-2의 <CSEBase> 리소스의 자식 리소스로서 동작할 수 있다. 추가적으로 또는 대안적으로, <lfnCapability> 리소스는 LFN으로서 동작하는 CSE-1의 <remoteCSE> 리소스의 자식 리소스로서 동작할 수 있다.

"lfnCapability"라고 불리는 새로운 속성은 또한, CSE-1의 LFN 능력을 나타내는데 이용될 수 있는, LFN으로서 동작하는 CSE-1의 <remoteCSE> 리소스에 대해 정의될 수 있다. <lfnCapability> 리소스는 표 10에 지정된 자식 리소스들을 포함할 수 있다.

<표 10>

<lfnCapability> 리소스는 표 11에 지정된 속성들을 포함할 수 있다.

<표 11>

표 12에 도시된 절차는 <lfnCapability> 리소스를 생성하는데 이용될 수 있다.

<표 12>

표 13에 도시된 절차는 <lfnCapability> 리소스의 속성들을 검색하는데 이용될 수 있다.

<표 13>

표 14에 도시된 절차는 <lfnCapability> 리소스의 속성들을 업데이트하는데 이용될 수 있다.

<표 14>

표 15에 도시된 절차는 <lfnCapability> 리소스를 삭제하는데 이용될 수 있다.

<표 15>

사람 사용자가 DS 식별 및 RDS 생성 프로세스를 모니터링하는데 이용될 수 있는 예시적인 GUI 인터페이스가 도 25에 도시된다. 인터페이스를 이용하는 사용자는 어느 특정한 LFA를 체크하고자 하는지에 관한 어떤 일반적인 정보를 지정할 수 있다. 일 예에서, 사용자는 이 사용자 인터페이스를 이용하기 위한 2가지 방식을 가질 수 있다: 첫째, 사용자는 특정 역할(예컨대, RDC 또는 RDP)로서 동작하는 LFN들을 체크할 수 있다. 따라서, 선택된 역할로서 동작하는 모든 LFN들은 사용자가 검토하도록 표시될 수 있다. 둘째, 사용자는 특정 LFN의 ID를 직접 입력할 수 있다. 따라서, 이 LFN의 모든 등록된 능력들(예컨대, 그 RDC 능력, DSD 능력 또는 RDP 능력)은 검토를 위해 사용자에게 표시될 수 있다.

서비스 계층, 서비스 계층 디바이스, 서비스 계층 애플리케이션, 애플리케이션 엔티티 등과 같은, 도 1, 도 4 내지 도 14, 및 도 18 내지 도 24에 도시된 단계들을 수행하는 엔티티들 중 임의의 것은, 도 26c 또는 도 26d에 도시된 것들과 같은 컴퓨터 시스템 또는 무선 및/또는 네트워크 통신들을 위해 구성된 장치의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있는 논리적 엔티티들일 수 있다. 즉, 도 1, 도 4 내지 도 14, 및 도 18 내지 도 24에 도시된 방법(들)은 도 26c 또는 도 26d에 도시된 컴퓨터 시스템 또는 장치와 같은 장치의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행가능한 명령어들)의 형태로 구현될 수 있고, 그 컴퓨터 실행가능한 명령어들은 장치의 프로세서에 의해 실행될 때 도 1, 도 4 내지 도 14, 및 도 18 내지 도 24에 도시된 단계들을 수행한다. 도 1, 도 4 내지 도 14, 및 도 18 내지 도 24에 도시된 임의의 전송 및 수신 단계들은 장치의 프로세서 및 프로세서가 실행하는 컴퓨터 실행가능한 명령어들(예를 들어, 소프트웨어)의 제어 하에서 장치/엔티티의 통신 회로에 의해 수행될 수 있음을 또한 이해할 것이다.

도 26a는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 기기간(M2M), 사물 인터넷(IoT), 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT에 대한 구성 블록들을 제공하고, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버, 또는 M2M 서비스 플랫폼은 IoT/WoT의 구성요소 또는 장치는 물론 IoT/WoT 서비스 계층 등일 수 있다. 도 1 내지 도 25 중 임의의 것에 도시된 엔티티들 중 임의의 것은, 도 26a 내지 도 26d에 도시된 것들과 같은, 통신 시스템의 네트워크 장치를 포함할 수 있다.

서비스 계층은 네트워크 서비스 아키텍처 내의 기능적 계층일 수 있다. 서비스 계층들은 통상적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 있으며 클라이언트 애플리케이션들에게 부가 가치 서비스들을 제공한다. 서비스 계층은 또한 예를 들어, 제어 계층 및 전송/액세스 계층과 같은 하위 리소스 계층에서 코어 네트워크들에 인터페이스를 제공한다. 서비스 계층은 서비스 정의, 서비스 실행시간 가능화, 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함하는 복수의 카테고리의 (서비스) 능력들 또는 기능들을 지원한다. 최근에, 몇개의 산업 표준 기관들, 예컨대, oneM2M이 M2M 유형들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 기업, 및 홈 네트워크들과 같은 배치들에 통합시키는 것과 연관된 과제들을 해결하기 위해 M2M 서비스 계층들을 개발해오고 있다. M2M 서비스 계층은 애플리케이션들 및/또는 다양한 디바이스들에게 CSE 또는 SCL이라고 지칭될 수 있는, 서비스 계층에 의해 지원되는, 위에서 언급된 능력들 또는 기능들의 집합 또는 세트에 대한 액세스를 제공할 수 있다. 몇몇 예들은 다양한 애플리케이션들에 의해 공통으로 이용될 수 있는 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝 및 접속성 관리를 포함하지만 이들로 제한되지 않는다. 이들 능력들 및 기능들은 M2M 서비스 계층에 의해 정의된 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 이용하는 API들을 통해 이러한 다양한 애플리케이션들에 이용가능하게 된다. CSE 또는 SCL은, 하드웨어 및/또는 소프트웨어에 의해 구현될 수 있고, 다양한 애플리케이션들 및/또는 디바이스들(즉, 이러한 기능적 엔티티들 사이의 기능적 인터페이스들)이 이러한 능력들 또는 기능들을 이용하도록 하기 위해 이들에 노출되는 (서비스) 능력들 또는 기능들을 제공하는 기능적 엔티티이다.

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

도 26a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인 및 필드 도메인을 포함할 수 있다. 인프라스트럭처 도메인은 엔드-투-엔드 M2M 배치의 네트워크측을 지칭하고, 필드 도메인은 보통 M2M 게이트웨이 뒤에 있는 영역 네트워크들을 지칭한다. 필드 도메인 및 인프라스트럭처 도메인 둘 다는 다양하고 상이한 네트워크 장치들(예컨대, 서버들, 게이트웨이들, 디바이스 등)을 포함할 수 있다. 예를 들어, 필드 도메인은 M2M 게이트웨이들(14) 및 디바이스들(18)을 포함할 수 있다. 원하는 바에 따라, 임의의 수의 M2M 게이트웨이 디바이스들(14) 및 M2M 디바이스들(18)이 M2M/IoT/WoT 통신 시스템(10)에 포함될 수 있다는 것을 잘 알 것이다. M2M 게이트웨이 디바이스들(14) 및 M2M 디바이스들(18) 각각은, 통신 회로를 이용하여, 통신 네트워크(12) 또는 직접 무선 링크를 통해 신호들을 전송 및 수신하도록 구성되어 있다.

M2M 게이트웨이(14)는 무선 M2M 디바이스들(예컨대, 셀룰러 및 비-셀룰러)은 물론 고정형 네트워크 M2M 디바이스들(예컨대, PLC)이 통신 네트워크(12)와 같은 운영자 네트워크들 또는 직접 무선 링크를 통해 통신할 수 있게 한다. 예를 들어, M2M 디바이스들(18)은 데이터를 수집하고 데이터를, 통신 네트워크(12) 또는 직접 무선 링크를 통해, M2M 애플리케이션(20) 또는 다른 M2M 디바이스들(18)에게 전송할 수 있다. M2M 디바이스들(18)은 또한 M2M 애플리케이션(20) 또는 M2M 디바이스(18)로부터 데이터를 수신할 수 있다. 또한, 후술하는 바와 같이, 데이터 및 신호들은 M2M 서비스 계층(22)을 통해 M2M 애플리케이션(20)에 전송되고 M2M 애플리케이션(20)으로부터 수신될 수 있다. M2M 디바이스들(18) 및 M2M 게이트웨이들(14)은, 예를 들어, 셀룰러, WLAN, WPAN(예컨대, 지그비(Zigbee), 6LoWPAN, 블루투스(Bluetooth)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다. 예시적인 M2M 디바이스들은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카들, 스마트 계측기들, 게임 콘솔들, PDA들, 건강 및 피트니스 모니터들, 조명들, 서모스탯들, 가전기기들, 차고 문들 및 다른 액추에이터 기반 디바이스들, 보안 디바이스들, 및 스마트 콘센트들을 포함하지만, 이들로 제한되지는 않는다.

도 26b를 참조하면, 필드 도메인에서의 도시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이들(14), 및 M2M 디바이스들(18) 및 통신 네트워크(12)에게 서비스들을 제공한다. M2M 서비스 계층(22)이 원하는 바에 따라 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들(14), M2M 디바이스들(18), 및 통신 네트워크들(12)과 통신할 수 있다는 것을 잘 알 것이다. M2M 서비스 계층(22)은, 서버들, 컴퓨터들, 디바이스들 등을 포함할 수 있는, 네트워크의 하나 이상의 네트워크 장치에 의해 구현될 수 있다. M2M 서비스 계층(22)은 M2M 디바이스들(18), M2M 게이트웨이들(14) 및 M2M 애플리케이션들(20)에 적용되는 서비스 능력들을 제공한다. M2M 서비스 계층(22)의 기능들은, 예를 들어 웹 서버로서, 셀룰러 코어 네트워크, 클라우드 등에서 다양한 방식들로 구현될 수 있다.

도시된 M2M 서비스 계층(22)과 유사하게, 인프라스트럭처 도메인에는 M2M 서비스 계층(22')이 존재한다. M2M 서비스 계층(22')은 인프라스트럭처 도메인 내의 M2M 애플리케이션(20') 및 기본 통신 네트워크(12)에게 서비스들을 제공한다. M2M 서비스 계층(22')은 또한 필드 도메인 내의 M2M 게이트웨이들(14) 및 M2M 디바이스들(18)에게 서비스들을 제공한다. M2M 서비스 계층(22')이 임의의 수의 M2M 애플리케이션들, M2M 게이트웨이들 및 M2M 디바이스들과 통신할 수 있다는 것이 이해될 것이다. M2M 서비스 계층(22')은 상이한 서비스 제공자에 의해 서비스 계층과 상호작용할 수 있다. M2M 서비스 계층(22')은, 서버들, 컴퓨터들, 디바이스들, 가상 머신들(예컨대, 클라우드 컴퓨팅/저장소 팜들 등) 등을 포함할 수 있는, 네트워크의 하나 이상의 네트워크 장치에 의해 구현될 수 있다.

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

M2M 애플리케이션들(20 및 20')은, 이에 제한되는 것은 아닌, 운송, 건강 및 보건, 커넥티드 홈(connected home), 에너지 관리, 자산 추적, 그리고 보안 및 감시와 같은 다양한 산업들에서의 애플리케이션들을 포함할 수 있다. 전술한 바와 같이, M2M 서비스 계층, 디바이스들에 걸쳐 실행하는 것, 게이트웨이들, 서버들 및 시스템의 다른 네트워크 장치들은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 청구, 위치 추적/지오펜싱, 디바이스/서비스 발견, 및 레거시 시스템들의 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20 및 20')에 제공한다.

일반적으로, 도 26b에 도시된 서비스 계층들(22 및 22') 등의 서비스 계층은, 애플리케이션 프로그래밍 인터페이스들(API들) 및 기본 네트워킹 인터페이스들의 세트를 통해 추가 가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M과 oneM2M 아키텍처들 양쪽 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)이라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양하고 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(여기서 디바이스 SCL(DSCL)이라고 지칭됨), 게이트웨이(여기서 게이트웨이 SCL(GSCL)이라고 지칭됨), 및/또는 네트워크 노드(여기서 네트워크 SCL(NSCL)이라고 지칭됨) 내에 구현될 수 있다. oneM2M 서비스 계층은 CSF들(즉, 서비스 능력들)의 세트를 지원한다. 하나 이상의 특정한 유형의 CSF들의 세트의 인스턴스화는 상이한 유형들의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)라고 지칭된다. 3GPP(Third Generation Partnership Project)는 또한 MTC(machine-type communications)에 대한 아키텍처도 정의하였다. 그 아키텍처에서, 서비스 계층, 및 이것이 제공하는 서비스 능력들은 서비스 능력 서버(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL, 또는 NSCL에, 3GPP MTC 아키텍처의 SCS에, oneM2M 아키텍처의 CSF 또는 CSE에, 또는 네트워크의 어떤 다른 노드에 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들, 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함한, 네트워크 내의 하나 이상의 독립형 노드 상에서 실행되는 논리 엔티티(예컨대, 소프트웨어, 컴퓨터 실행가능한 명령어들 등)로서 또는 하나 이상의 기존의 노드의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그 구성요소의 인스턴스는 아래에 설명되는 도 26c 또는 도 26d에 도시되는 일반적인 아키텍처를 갖는 네트워크 장치(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.

게다가, 본 명세서에서 설명되는 방법들 및 기능들은 서비스들에 액세스하기 위해 SOA(Service Oriented Architecture) 및/또는 ROA(Resource-Oriented Architecture)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.

배치 관점에서, 서비스 계층은 본 명세서의 다양한 도면들에 도시된 바와 같은 서버들, 게이트웨이들 및 디바이스들을 포함하는 다양한 유형들의 네트워크 노드들 상에 배치될 수 있다. 서비스 계층 기능을 구현하거나 또는 다른 방식으로 서비스 계층의 인스턴스를 통합하는 임의의 이러한 노드, 서버, 게이트웨이, 디바이스, 장치, 또는 통신 네트워크의 다른 논리적 엔티티는 본 명세서에서 서비스 계층 엔티티로서 지칭될 수 있다.

도 26c는 도 26a 및 도 26b에 도시된 것과 같은 M2M 네트워크 내의 M2M 서버, 게이트웨이, 디바이스, 또는 다른 네트워크 장치로서 동작할 수 있는, 도 1 내지 도 25에 도시된 엔티티들 중 하나와 같은 네트워크 장치의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 도 26d에 도시된 바와 같이, 네트워크 장치(30)는 프로세서(32), 비이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시기들(42), 전원(48), 전역 포지셔닝 시스템(GPS) 칩셋(50), 및 다른 주변기기들(52)을 포함할 수 있다. 네트워크 장치(30)는 또한 트랜시버(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. 네트워크 장치(30)는, 실시예와 일관되면서 전술된 요소들의 임의의 하위조합을 포함할 수 있다는 것을 이해할 것이다. 이 네트워크 장치는, 도 1 내지 도 25와 관련하여 도시되고 설명된 방법들 및 동작들과 같이, 포그 기반 데이터 보호를 가능하게 하기 위한 데이터 샘플 템플릿(DST) 관리를 위한 방법들을 구현하는 장치일 수 있다.

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

도 26c에 도시된 바와 같이, 프로세서(32)는 그 통신 회로(예를 들어, 트랜시버(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능한 명령어들의 실행을 통해, 네트워크 장치(30)가 접속되는 네트워크를 통해 다른 네트워크 장치들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본 명세서(예컨대, 도 1 내지 도 25)에서 그리고 청구항들에서 설명된 전송 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 26c가 프로세서(32)와 트랜시버(34)를 별도의 구성요소들로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.

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

또한, 전송/수신 요소(36)가 도 26c에 단일 요소로서 도시되지만, 네트워크 장치(30)는 임의 수의 전송/수신 요소들(36)을 포함할 수 있다. 보다 구체적으로는, 네트워크 장치(30)는 MIMO 기술을 이용할 수 있다. 따라서, 실시예에서, 네트워크 장치(30)는 무선 신호들을 전송 및 수신하기 위한 2개 이상의 전송/수신 요소들(36)(예컨대, 복수의 안테나들)을 포함할 수 있다.

트랜시버(34)는 전송/수신 요소(36)에 의해 전송될 신호들을 변조하고, 전송/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 앞서 살펴본 바와 같이, 네트워크 장치(30)는 다중 모드 능력들을 가질 수 있다. 그러므로, 트랜시버(34)는 네트워크 장치(30)가 예를 들어, UTRA 및 IEEE 802.11과 같은 복수의 RAT들을 통해 통신하게 하는 복수의 트랜시버들을 포함할 수 있다.

프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 유형의 적절한 메모리로부터의 정보에 액세스하고 이에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 전술한 바와 같이, 그 메모리에 세션 컨텍스트를 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는, 서버 또는 홈 컴퓨터 상에서와 같이, 네트워크 장치(30) 상에 물리적으로 위치되지 않은 메모리로부터의 정보에 액세스하고 이에 데이터를 저장할 수 있다. 프로세서(32)는 디스플레이 또는 표시기들(42) 상의 조명 패턴들, 이미지들 또는 색상들을 제어하여 장치의 상태를 반영하거나 장치를 구성하고 특히 네트워크 장치와 통신하는 기본 네트워크들, 애플리케이션들 또는 다른 서비스들을 구성할 수 있다. 일 실시예에서, 디스플레이/표시기들(42)은 도 26d에 도시되고 본 명세서에 설명되는 그래픽 사용자 인터페이스를 제시할 수 있다.

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

프로세서(32)는 또한 GPS 칩셋(50)과 결합될 수 있으며, 이는 네트워크 장치(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된다. 네트워크 장치(30)는 실시예와 일관성을 유지하면서 임의의 적절한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 점이 이해될 것이다.

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

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

도 26c는 도 26a 및 도 26b에 도시된 것과 같은 M2M 네트워크 내의 M2M 서버, 게이트웨이, 디바이스, 또는 다른 네트워크 장치로서 동작할 수 있는, 도 1 내지 도 25에 도시되고 본 명세서에서 설명된 엔티티들과 같은 네트워크의 하나 이상의 네트워크 장치를 구현하는데 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다.

컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 컴퓨터 판독가능한 명령어들에 의해 제어될 수 있으며, 컴퓨터 판독가능한 명령어들은 소프트웨어의 형태로 어느 곳이나 있을 수 있거나, 어떤 수단에 의해서든 이러한 소프트웨어가 저장되거나 액세스된다. 이러한 컴퓨터 판독가능한 명령어들은 컴퓨팅 시스템(90)으로 하여금 작업하게 하기 위해, 중앙 처리 유닛(CPU)(91)과 같은, 프로세서 내에서 실행될 수 있다. 많은 공지된 워크스테이션들, 서버들, 및 개인용 컴퓨터들에서, 중앙 처리 유닛(91)은 마이크로프로세서로 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서를 포함할 수 있다. 코프로세서(81)는 추가 기능들을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개인 임의적인 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 세션 자격증명들을 수신하거나 세션 자격증명들을 기반으로 인증하는 것과 같이, E2E M2M 서비스 계층 세션들에 대해 개시되는 시스템들 및 방법들에 관련된 데이터를 수신, 생성 및 처리할 수 있다.

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

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

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

디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 표시하는데 이용된다. 이러한 시각적 출력은 텍스트, 그래픽들, 애니메이션 그래픽들, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 전송되는 비디오 신호를 생성하는데 요구되는 전자 구성요소들을 포함한다. 디스플레이(86)는, CPU(91)에 의해 실행되는 컴퓨터 실행가능한 명령어들과 조합하여, 도 26d 및 그 첨부 설명에 도시되고 설명된 그래픽 사용자 인터페이스를 생성하여 동작시킬 수 있다.

또한, 컴퓨팅 시스템(90)은 도 26a 내지 도 26d의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하여, 컴퓨팅 시스템(90)이 네트워크의 다른 장치들과 통신할 수 있게 하는데 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다. 통신 회로는, 단독으로 또는 CPU(91)와 조합하여, 본 명세서(예를 들어, 도 1 내지 도 25)에서 그리고 청구항들에서 설명된 전송 및 수신 단계들을 수행하는데 이용될 수 있다.

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

다음은 위의 설명에서 나타날 수 있는 서비스 계층 기술들에 관한 약어들의 리스트이다. 달리 지정되지 않는 한, 본 명세서에서 사용되는 약어들은 아래 열거된 대응하는 용어를 지칭한다:

<표 16>

다음은 위의 설명에서 나타날 수 있는 서비스 계층 기술들에 관한 용어들 및 정의들의 리스트이다. 달리 지정되지 않는 한, 본 명세서에서 사용되는 용어들 및 정의들은 아래에 열거된 대응하는 용어를 지칭한다:

<표 17>

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

Claims

데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법으로서,
데이터 샘플 템플릿을 생성하라는 요청을 수신하는 단계 - 상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 하나 이상의 데이터 요소와 연관된 정보를 포함함 -;
상기 하나 이상의 데이터 요소와 연관된 상기 정보에 기반하여, 상기 데이터 샘플 템플릿을 생성하는 단계;
상기 데이터 샘플 수집 서비스의 제2 에이전트에, 상기 하나 이상의 데이터 요소와 연관된 하나 이상의 데이터 소스를 식별하라는 요청을 전송하는 단계 - 상기 데이터 샘플 수집 서비스의 상기 제2 에이전트는 로컬 포그 노드 상에 위치됨 -;
상기 데이터 샘플 수집 서비스의 상기 제2 에이전트로부터, 상기 하나 이상의 데이터 소스와 연관된 정보를 수신하는 단계; 및
상기 하나 이상의 데이터 소스와 연관된 상기 정보에 기반하여, 상기 데이터 샘플 템플릿을 구성하는 단계
를 포함하는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
제1항에 있어서,
상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 생성될 데이터 샘플의 유형의 표시를 포함하는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
제2항에 있어서,
상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 하나 이상의 파라미터의 표시를 더 포함하고, 상기 하나 이상의 파라미터는,
상기 데이터 샘플과 연관된 표적화된 영역;
상기 데이터 샘플과 연관된 빈도;
상기 데이터 샘플과 연관된 생성 스케줄; 및
상기 데이터 샘플과 연관된 컨텍스트
를 포함하는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
제3항에 있어서,
상기 하나 이상의 파라미터에 기반하여, 복수의 로컬 포그 노드 중 어느 것을 표적으로 할지를 결정하는 단계를 더 포함하는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
제1항에 있어서,
상기 하나 이상의 데이터 요소와 연관된 상기 정보는,
상기 데이터 요소의 원시 데이터 유형;
상기 데이터 요소의 단위;
상기 데이터 요소의 데이터 처리 동작;
상기 데이터 요소의 하나 이상의 맞춤화된 처리 상세; 및
상기 데이터 요소의 하나 이상의 품질 요건
중 하나 이상을 포함하는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
제1항에 있어서,
상기 데이터 샘플 수집 서비스의 상기 제2 에이전트에, 구성된 데이터 샘플 템플릿을 전송하는 단계를 더 포함하는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
제6항에 있어서,
상기 데이터 샘플 수집 서비스의 상기 제2 에이전트는, 상기 구성된 데이터 샘플 템플릿에 기반하여, RDS(ready to use data sample)를 생성하도록 구성되는, 데이터 샘플 수집 서비스의 제1 에이전트에서 수행되는 방법.
프로세서 및 메모리를 포함하는 장치로서,
상기 메모리는 상기 프로세서에 의해 실행될 때, 상기 장치로 하여금 데이터 샘플 수집 서비스의 제1 에이전트를 구현하게 하는 컴퓨터 실행가능한 명령어들을 저장하고, 상기 데이터 샘플 수집 서비스의 상기 제1 에이전트는,
데이터 샘플 템플릿을 생성하라는 요청을 수신하는 것 - 상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 하나 이상의 데이터 요소와 연관된 정보를 포함함 -;
상기 하나 이상의 데이터 요소와 연관된 상기 정보에 기반하여, 상기 데이터 샘플 템플릿을 생성하는 것;
상기 데이터 샘플 수집 서비스의 제2 에이전트에, 상기 하나 이상의 데이터 요소와 연관된 하나 이상의 데이터 소스를 식별하라는 요청을 전송하는 것 - 상기 데이터 샘플 수집 서비스의 상기 제2 에이전트는 로컬 포그 노드 상에 위치됨 -;
상기 데이터 샘플 수집 서비스의 상기 제2 에이전트로부터, 상기 하나 이상의 데이터 소스와 연관된 정보를 수신하는 것; 및
상기 하나 이상의 데이터 소스와 연관된 상기 정보에 기반하여, 상기 데이터 샘플 템플릿을 구성하는 것
을 포함하는 동작들을 수행하도록 구성되는, 장치.
제8항에 있어서,
상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 생성될 데이터 샘플의 유형의 표시를 포함하는, 장치.
제9항에 있어서,
상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 하나 이상의 파라미터의 표시를 더 포함하고, 상기 하나 이상의 파라미터는,
상기 데이터 샘플과 연관된 표적화된 영역;
상기 데이터 샘플과 연관된 빈도;
상기 데이터 샘플과 연관된 생성 스케줄; 및
상기 데이터 샘플과 연관된 컨텍스트
를 포함하는, 장치.
제10항에 있어서,
상기 명령어들은, 실행될 때, 추가로 상기 데이터 샘플 수집 서비스의 상기 제1 에이전트로 하여금, 상기 하나 이상의 파라미터에 기반하여, 복수의 로컬 포그 노드 중 어느 것을 표적으로 할지를 결정하는 것을 포함하는 동작들을 수행하게 하는, 장치.
제8항에 있어서,
상기 하나 이상의 데이터 요소와 연관된 상기 정보는,
상기 데이터 요소의 원시 데이터 유형;
상기 데이터 요소의 단위;
상기 데이터 요소의 데이터 처리 동작;
상기 데이터 요소의 하나 이상의 맞춤화된 처리 상세; 및
상기 데이터 요소의 하나 이상의 품질 요건
중 하나 이상을 포함하는, 장치.
제8항에 있어서,
상기 명령어들은, 실행될 때, 추가로 상기 데이터 샘플 수집 서비스의 상기 제1 에이전트로 하여금, 상기 데이터 샘플 수집 서비스의 상기 제2 에이전트에, 구성된 데이터 샘플 템플릿을 전송하는 것을 포함하는 동작들을 수행하게 하는, 장치.
제13항에 있어서,
상기 데이터 샘플 수집 서비스의 상기 제2 에이전트는, 상기 구성된 데이터 샘플 템플릿에 기반하여, RDS를 생성하도록 구성되는, 장치.
프로세서에 의해 실행될 때, 데이터 샘플 수집 서비스의 제1 에이전트로 하여금 동작들을 수행하게 하는 명령어들을 저장하는 컴퓨터 판독가능한 저장 매체로서,
상기 동작들은,
데이터 샘플 템플릿을 생성하라는 요청을 수신하는 것 - 상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 하나 이상의 데이터 요소와 연관된 정보를 포함함 -;
상기 하나 이상의 데이터 요소와 연관된 상기 정보에 기반하여, 상기 데이터 샘플 템플릿을 생성하는 것;
상기 데이터 샘플 수집 서비스의 제2 에이전트에, 상기 하나 이상의 데이터 요소와 연관된 하나 이상의 데이터 소스를 식별하라는 요청을 전송하는 것 - 상기 데이터 샘플 수집 서비스의 상기 제2 에이전트는 로컬 포그 노드 상에 위치됨 -;
상기 데이터 샘플 수집 서비스의 상기 제2 에이전트로부터, 상기 하나 이상의 데이터 소스와 연관된 정보를 수신하는 것; 및
상기 하나 이상의 데이터 소스와 연관된 상기 정보에 기반하여, 상기 데이터 샘플 템플릿을 구성하는 것
을 포함하는, 컴퓨터 판독가능한 저장 매체.
제15항에 있어서,
상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 생성될 데이터 샘플의 유형의 표시를 포함하는, 컴퓨터 판독가능한 저장 매체.
제16항에 있어서,
상기 데이터 샘플 템플릿을 생성하라는 상기 요청은 하나 이상의 파라미터의 표시를 더 포함하고, 상기 하나 이상의 파라미터는,
상기 데이터 샘플과 연관된 표적화된 영역;
상기 데이터 샘플과 연관된 빈도;
상기 데이터 샘플과 연관된 생성 스케줄; 및
상기 데이터 샘플과 연관된 컨텍스트
를 포함하는, 컴퓨터 판독가능한 저장 매체.
제17항에 있어서,
상기 명령어들은, 실행될 때, 추가로 상기 데이터 샘플 수집 서비스의 상기 제1 에이전트로 하여금, 상기 하나 이상의 파라미터에 기반하여, 복수의 로컬 포그 노드 중 어느 것을 표적으로 할지를 결정하는 것을 포함하는 동작들을 수행하게 하는, 컴퓨터 판독가능한 저장 매체.
제15항에 있어서,
상기 하나 이상의 데이터 요소와 연관된 상기 정보는,
상기 데이터 요소의 원시 데이터 유형;
상기 데이터 요소의 단위;
상기 데이터 요소의 데이터 처리 동작;
상기 데이터 요소의 하나 이상의 맞춤화된 처리 상세; 및
상기 데이터 요소의 하나 이상의 품질 요건
중 하나 이상을 포함하는, 컴퓨터 판독가능한 저장 매체.
제15항에 있어서,
상기 명령어들은, 실행될 때, 추가로 상기 데이터 샘플 수집 서비스의 상기 제1 에이전트로 하여금, 상기 데이터 샘플 수집 서비스의 상기 제2 에이전트에, 구성된 데이터 샘플 템플릿을 전송하는 것을 포함하는 동작들을 수행하게 하는, 컴퓨터 판독가능한 저장 매체.