KR102101319B1 - 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측 - Google Patents

과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측 Download PDF

Info

Publication number
KR102101319B1
KR102101319B1 KR1020187024490A KR20187024490A KR102101319B1 KR 102101319 B1 KR102101319 B1 KR 102101319B1 KR 1020187024490 A KR1020187024490 A KR 1020187024490A KR 20187024490 A KR20187024490 A KR 20187024490A KR 102101319 B1 KR102101319 B1 KR 102101319B1
Authority
KR
South Korea
Prior art keywords
node
service layer
service
data
availability
Prior art date
Application number
KR1020187024490A
Other languages
English (en)
Other versions
KR20180098426A (ko
Inventor
쉬 리
광 루
리쥔 둥
데일 엔. 시드
훙쿤 리
윌리엄 로버트 4세 플린
필립 브라운
카탈리나 엠. 믈라딘
Original Assignee
콘비다 와이어리스, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 콘비다 와이어리스, 엘엘씨 filed Critical 콘비다 와이어리스, 엘엘씨
Publication of KR20180098426A publication Critical patent/KR20180098426A/ko
Application granted granted Critical
Publication of KR102101319B1 publication Critical patent/KR102101319B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/04Processing captured monitoring data, e.g. for logfile generation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/12Arrangements for remote connection or disconnection of substations or of equipment thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14Network analysis or design
    • H04L41/147Network analysis or design for predicting network behaviour
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/0091Signaling for the administration of the divided path
    • H04L5/0092Indication of how the channel is divided
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5009Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H04L41/5012Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF] determining service availability, e.g. which services are available at a certain point in time
    • H04L41/5016Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF] determining service availability, e.g. which services are available at a certain point in time based on statistics of service availability, e.g. in percentage or over a given time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/70Reducing energy consumption in communication networks in wireless communication networks
    • Y02D70/00

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Mining & Analysis (AREA)
  • Probability & Statistics with Applications (AREA)
  • Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Selective Calling Equipment (AREA)
  • Telephonic Communication Services (AREA)

Abstract

노드 가용성 추정 서비스는 M2M/IoT 네트워크의 서비스 계층에서 사용될 수 있다. 부가가치 서비스들은 이런 노드 가용성 정보를 레버리지화하여 M2M/IoT 시스템에 대한 에너지 효율뿐만 아니라 운영 지능, 서비스 품질, 통신 오버 헤드를 향상시킬 수 있다. 실시간 데이터 수집(DC) 컴포넌트는 서비스 계층(예를 들어, 다른 기존의 CSF)에서 입력 소스들로부터 실시간 데이터를 수집할 수 있다. 노드 가용성 컴포넌트를 추정하기 위한 데이터 처리(DP)는 DC에 의해 수집된 데이터에 기초하여 노드 가용성을 추정하기 위한 데이터 처리를 실행할 수 있다. 노드 가용성 서비스 프로비저닝 컴포넌트(SP)는 DP로부터의 추정된 노드 가용성 결과들을 저장하고 이들을 "노드 가용성 추정 서비스들" 측면에서 서비스 클라이언트들에 노출할 수 있다.

Description

과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측{NETWORK NODE AVAILABILITY PREDICTION BASED ON PAST HISTORY DATA}
도 1은 서비스 계층(102)을 지원하는 예시적인 프로토콜 스택(100)을 도시하는 도면이다. 프로토콜 스택 관점에서, 서비스 계층들(102)은 전형적으로 애플리케이션 프로토콜 계층(104)의 상부에 계층화되고, 부가가치 서비스들을 클라이언트 애플리케이션들에 제공한다. 따라서, 서비스 계층들(102)은 종종 '미들웨어(middleware)' 서비스들로 분류된다.
M2M/IoT 서비스 계층은, 특히 M2M/IoT 타입의 디바이스들 및 애플리케이션들을 목표로 삼은 서비스 계층의 한 타입의 예이다. 도 2는 네트워크 내의 M2M/IoT 서비스 계층 인스턴스들(service layer instances)의 예시적인 배치 시나리오를 도시하는 도면이다. 이 예에서, 서비스 계층 인스턴스(202)는 서비스 계층의 실현이고, 다수의 서비스 계층 인스턴스는 다양한 네트워크 노드(게이트웨이들 및 서버들) 상에 배치된다. 서비스 계층 인스턴스들은 부가가치 서비스들을 네트워크 애플리케이션들, 디바이스 애플리케이션들뿐만 아니라 네트워크 노드들 자체에 제공한다.
최근, 여러 산업 표준 단체들(예를 들어, oneM2M)은 M2M/IoT 타입들의 디바이스들 및 애플리케이션들을 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크와 같은 배치들에 통합하는 것과 연관되는 도전 과제들을 다루기 위해 M2M/IoT 서비스 계층들을 개발하고 있다. M2M 서비스 계층은 애플리케이션들 및 디바이스들에게 서비스 계층에 의해 지원되는 M2M 중심 능력들의 집합(collection)에 대한 액세스를 제공할 수 있다. 그런 능력들의 몇몇 예는, 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝(provisioning), 및 접속성 관리를 포함한다. 이 능력들은 M2M 서비스 계층에 의해 정의되는, 메시지 포맷들, 리소스 구조들 및 리소스 표현들을 사용하는 API들을 통해 애플리케이션들에 이용 가능하게 될 수 있다.
oneM2M의 목적 및 목표는, 다양한 하드웨어 및 소프트웨어 내에 용이하게 내장되고 해당 분야에서의 다양한 디바이스를 전 세계의 M2M 애플리케이션 서버들과 접속시키는데 의존될 수 있는 공통 M2M 서비스 계층에 대한 필요성을 다루는 기술적 사양들을 개발하는 것이다.
도 3은 공통 서비스 기능들(Common Service Functions)(CSFs)(즉, 서비스 능력들)의 세트를 지원하는 oneM2M 공통 서비스 계층(302)을 도시하는 도면이다. 하나 이상의 특정 타입의 CSF들의 세트의 인스턴스화(instantiation)는 상이한 타입의 네트워크 노드들 상에서 호스팅될 수 있는 공통 서비스 엔티티(Common Services Entity)(CSE)(304)로 지칭되고, 예를 들어 인프라구조 노드(Infrastructure Node)(IN), 중간 노드(Middle Node)(MN) 및 애플리케이션 특정 노드(Application-Specific Node)(ASN) CSE는 IN-CSE, MN-CSE 및 ASN-CSE로 명명된다.
도 4는 리소스 지향 아키텍처(Resource-Oriented Architecture)(RoA) 설계 원리에 부합하는 oneM2M 서비스 계층을 도시하는 도면이다. oneM2M RoA RESTful 아키텍처(도 4에 도시된 바와 같은) 내에서는, CSF들이 "리소스들"의 세트로서 표현된다. 리소스는, Create, Retrieve, Update, 및 Delete와 같은 RESTful 방법들을 통해 조작될 수 있는 표현을 갖는 아키텍처 내의 고유하게 어드레스 지정 가능한 요소이다. 이들 리소스는 URI(Universal Resource Identifier)들을 이용하여 어드레스 지정 가능하게 된다. 리소스는 자식 리소스(들) 및 속성(들)을 포함할 수 있다. 자식 리소스는 부모 리소스와 포함 관계(containment relationship)를 갖는 리소스이다. 부모 리소스 표현은 그의 자식 리소스(들)에 대한 참조들을 포함한다. 자식 리소스의 수명은 부모의 리소스 수명에 의해 제한된다. 각각의 리소스는 리소스의 정보를 저장하는 한 세트의 "속성들"을 지원한다.
도 5는 RESTful 기반이 아닌 레거시 배치를 위한 M2M 서비스 컴포넌트 아키텍처를 도시한다. 이런 M2M 서비스 컴포넌트 아키텍처는 주로, CSE(502)가 서비스 컴포넌트들의 세트로서 보여지는 인프라구조 도메인에 적합하다. 서비스 계층 내에는, 다양한 M2M 서비스가 포함되며 다수의 서비스가 서비스 컴포넌트들로 그룹화될 수 있다. 기존의 기준점들 외에, 서비스-간 기준점(inter-service reference point) Msc(504)가 도입된다. (Msc 기준점(504)을 통과하는) M2M 서비스 컴포넌트들 간의 통신은 서비스 지향 아키텍처(SoA)-기반 소프트웨어 시스템들을 구축하기 위한 가장 보편적인 기술인 웹 서비스 접근법을 이용한다.
많은 M2M/IoT 디바이스는 제한된 배터리 전력, 작은 메모리 풋 프린트 및 낮은 처리량 링크들의 일부 조합을 갖는 것으로 알려졌다. 이에 따라, 이들 디바이스 중 많은 디바이스가 "슬리피(sleepy)"이고, 때때로 에너지 절약을 위해 슬리피 모드로 들어간다. 이것은 대부분의 이전 연구에서 고려되는 노드 비가용성(node unavailability)을 야기하는 주된 문제가 된다.
무선 센서 네트워크(wireless sensor network )(WSN)는 감지 및 컴퓨팅 능력을 갖는 다수의 저전력 디바이스로 구성되는 전형적인 M2M 영역 네트워크이다. 많은 센서 네트워크 시스템에서, 네트워크 노드들의 파워 서플라이(power supply)는 일반적으로 배터리들과 같은 소모성 전원(depletable power source)이다. 센서 네트워크들의 수명을 늘리기 위해, 하나의 전력 관리 방안은 각각의 네트워크 노드가 무선 채널을 청취하기 위해 주기적으로 기상하도록 요구하는 것이다. 예를 들어, S-MAC은 무선 센서 네트워크용으로 설계된 유명한 매체 액세스 제어(Medium Access Control)(MAC) 프로토콜이다. S-MAC에서는, 각 노드가 잠시 동안 수면(sleep)으로 들어간 후, 기상해서 다른 노드가 해당 노드와 얘기하기를 원하는지 알고자 청취한다. 수면 중에 노드는 자신의 라디오를 턴오프하고 나중에 기상하기 위해 타이머를 설정한다. 청취 및 수면을 위한 지속 기간은 상이한 애플리케이션 시나리오들에 따라 선택될 수 있고, 노드들은 동기화를 위해 바로 이웃들(immediate neighbors) 모두에게 방송함으로써 자신의 스케줄들을 교환한다. 기상 상태(awake state) 동안, 다수의 이웃이 노드와 얘기하기를 원할 경우, 그들은 반송파 감지 다중 액세스 방식을 이용하여 매체와 경쟁해야 할 필요가 있다.
전력 관리 방식의 다른 접근법은, 노드가 수면 모드로 들어갈 때 저전력 대기(stand-by) 하드웨어 컴포넌트를 이용하여 환경을 감시(watch)하는 것이다. 예를 들어, 노드는, 노드가 수면할 때, 대기 무선 송수신기 서브 시스템을 이용하여 무선 채널을 청취할 수 있다. 대기 무선 송수신기가 무선 신호를 수신할 때, 이는 노드를 기상시킨다. 그렇지 않으면, 노드는 계속 수면한다.
M2M/IoT 이용 사례들(예를 들어, 스마트 객체들을 인터넷에 접속하는 것)에 관한 기존 인터넷 프로토콜들의 단점 및 문제점들이 확인되었다. 예를 들어, 현재 인터넷 프로토콜들의 주요 단점은, 그들이 슬리피 노드들에 대한 지원이 부족하다는 것이다. 즉, 네트워크 노드들은 항상 완전한 전력이 공급되는 것으로 가정되는데, 불행하게도 (본질적으로 리소스가 제한되고, 배터리-구동되며, 대부분의 시간을 수면하는) 많은 M2M/IoT 타입의 디바이스에서는 그렇지 않다. 이에 따라, 최근에는 M2M/IoT 네트워크들을 지원하기 위해 인터넷의 아키텍처 및 프로토콜들을 향상시키도록 많은 관심과 주의가 주어졌다. 예를 들어, 이전 시스템에서는, 라우터가 IPv6 슬리피 노드를 제어하고 외부 네트워크들로/로부터 패킷을 전달할 수 있는 수면 모드 제어의 메커니즘을 설명하거나, 또는 슬리피 노드가 지원하는 6LoWPAN ND(Neighbor Discovery) 프로토콜의 향상을 설명한다.
IETF 제한 애플리케이션 프로토콜(Constrained Application Protocol)(CoAP)은 스마트 홈을 위해 배치된 무선 센서 네트워크들과 같은 제한된 노드들/네트워크들을 위해 특별히 최근에 개발된 애플리케이션 프로토콜이다. 이것은 관심의 증가를 끌었으며 IoT 시스템을 위한 유망한 메시징 프로토콜이 되었다. 특히, 슬리피 노드들을 지원하기 위한 CoAP 프로토콜을 향상시키도록 일부 작업이 수행되었다.
전술한 CoAP 프로토콜 향상 이외에도, IETF 제한된 RESTful 환경(Constrained RESTful Environments)(CoRE) 작업 그룹 내의 슬리피 노드들을 지원하기 위한 다른 노력이 또한 이루어졌다. 예를 들어, 아이디어들 중 하나는, 슬리피 노드들이 이들의 리소스들의 리스트(이들의 수면 관련 상태와 더불어)를 중앙(논-슬리피(non-sleepy)) RD 서버 상에 등록/업데이트할 수 있는 RD(Resource Directory) 메커니즘을 채택하는 것이다. 이를 통해 클라이언트들은, 슬리피 노드에 대한 RD로부터 리소스들의 리스트를 발견하고, 표적 리소스(targeted resource)가 슬리피 노드 상에 위치하는지, 슬리피 노드가 현재 수면 모드에 있는지, 또는 슬리피 노드가 언제 다시 기상 상태에 있을지를 결정할 수 있다. 다른 예는, 슬리피 노드가 MS 리소스 트리에 리소스들을 생성하도록 허용하는 웹 서버인 미러 서버(Mirror Server)(MS)에 관한 것이다. 특히, 에너지 효율성을 위해, 수면 노드는 클라이언트 전용 엔드포인트이므로, 자체적으로 콘텐츠를 제공할 수 없다. 즉, MS는 슬리피 노드와 클라이언트 간의 메일박스로서의 역할을 한다.
도 6은 oneM2M 기능적 아키텍처 사양로부터 <schedule>(602)이라고 불리는 리소스를 도시하는 도면이다. <schedule> 리소스(602)는 그 부모 리소스의 맥락에서 스케줄링 정보를 표현한다. <schedule>(602)가 <node> 리소스의 자식일 때, <scheduleElement> 리소스(604)에 저장된 수면 스케줄 정보를 표현할 수 있으므로, 서비스 계층은 노드가 수면 중임을 인식할 수 있다.
전술한 것을 배경 정보로 하여, 본 출원은 노드 가용성 추정 서비스를 가능하게 하는 새로운 방법 및 시스템을 개시한다.
실시예들은 노드 가용성 추정을 지원하는 서비스 계층에서의 새로운 서비스를 포함한다. 다수의 새로운 부가가치 서비스는 M2M/IoT 시스템들에 대한 에너지 효율성뿐만 아니라, 운영 지능, 서비스 품질, 통신 오버헤드를 향상시키는 이런 노드 가용성 정보를 레버리지(leverage)화할 수 있다.
일 실시예에서, 서비스 계층에서의 노드 가용성 추정(Node Availability Estimation)(NAE) 서비스는 3가지 주요 컴포넌트를 갖는다: 실시간 데이터 수집 컴포넌트(DC), 노드 가용성 컴포넌트를 추정하기 위한 데이터 처리(DP) 및 노드 가용성 서비스 프로비저닝 컴포넌트(SP).
DC는 서비스 계층에서의 입력 소스들(예를 들어, 다른 기존의 CSF들)로부터 실시간 데이터를 수집할 수 있다. DC는 데이터 수집 관계, 정책 수립 및 관련된 새로운 메시지 구조를 위한 절차; 데이터 수집 및 보고와, 관련된 새로운 메시지 구조를 위한 절차; 및 데이터 수집 관계 및 정책 업데이팅을 위한 절차를 이용할 수 있다.
DP는 DC에 의해 수집된 데이터에 기초하여 노드 가용성을 추정하기 위한 데이터 처리를 실행할 수 있다. DP의 기능적 아키텍처는, 정보 추론, 정보 융합, 입력 포맷 파싱(Input Format Parsing), 노드 가용성 추정기(estimator)의 구축, 노드 가용성 추정, 추정기 평가 및 데이터 수집 전략 결정, 및 출력 생성 및 피드백 수집을 포함하는 다수의 모듈을 포함할 수 있다.
SP는 DP로부터의 추정된 노드 가용성 결과들을 저장할 수 있고, "노드 가용성 추정 서비스들"의 관점에서 이들을 서비스 클라이언트들에 노출시킬 수 있다. SP는 서비스 프로비저닝 포털(service provisioning portal)일 수 있다.
다수의 DC, DP 및 SP는, 2개의 DP 사이에서 데이터 수집에 대한 협력(collaboration)을 포함하는 협력 및 데이터 공유와, 2개의 DP와 2개의 SP 사이에서 서비스 프로비저닝 및 추정 결과 공유에 대한 협력을 위해 서로 상호 작용할 수 있다.
노드 가용성 인식 세션 확립, 지능형 스토어 및 전송 리소스 프리페칭, 및 서비스 계층에 의해 지원되는 사전 대비적 노드 트리거링(proactive node triggering)을 포함하는 다수의 새로운 부가가치 서비스가 제공될 수 있다.
실시예들은 oneM2M 기능적 아키텍처 실시예, oneM2M 서비스 컴포넌트 아키텍처 실시예, oneM2M 서비스 계층 내의 입력 소스들로부터의 데이터 수집에 대한 실시예, DP의 정보 추론 모듈 및 정보 융합 모듈에서 실행되는 데이터 처리에 대한 실시예, 및 새로운 리소스들을 정의함으로써 노드 가용성 추정 서비스 프로비저닝의 oneM2M 실시예를 포함할 수 있다.
이 요약은 아래의 상세한 설명에서 추가로 설명되는 개념들의 선택을 간단한 형태로 소개하기 위해 제공된다. 이 요약은 청구된 주제의 핵심 특징들 또는 필수 특징들을 식별하도록 의도되지 않으며, 어떤 것도 청구된 주제의 범위를 한정하도록 이용되는 것으로 의도되지 않는다. 또한, 청구된 주제는 본 개시내용의 모든 부분에서 언급된 임의의 또는 모든 단점을 해결하는 제한 사항으로 한정되지 않는다.
첨부 도면과 함께 예로서 주어진 다음의 설명으로부터 더 상세한 이해가 이루어질 수 있다.
도 1은 서비스 계층을 지원하는 예시적인 프로토콜 스택을 도시하는 도면이다.
도 2는 네트워크 내의 M2M/IoT 서비스 계층 인스턴스들의 예시적인 배치 시나리오를 도시하는 도면이다.
도 3은 공통 서비스 기능들(CSFs)의 세트를 지원하는 oneM2M 공통 서비스 계층을 도시하는 도면이다.
도 4는 리소스 지향 아키텍처(RoA) 설계 원리들에 부합하는 oneM2M 서비스 계층을 도시하는 도면이다.
도 5는 RESTful 기반이 아닌 레거시 배치를 고려하도록 개발된 M2M 서비스 컴포넌트 아키텍처를 도시한다.
도 6은 oneM2M 기능적 아키텍처 사양으로부터 <schedule>이라 불리는 리소스를 도시하는 도면이다.
도 7은 상이한 노드 비가용성 사례들(unavailability cases)을 갖는 M2M/IoT 시스템을 도시하는 도면이다.
도 8은 노드 가용성 정보가 없는 비효율적인 리소스 검색 동작들을 갖는 이용 사례를 도시하는 도면이다.
도 9a는 NAE가 어떻게 서비스 계층에 적응하는지에 대한 일 실시예를 도시하는 도면이다.
도 9b는 NAE의 기능적 아키텍처를 도시하는 도면이다.
도 10은 NAE, 및 논리 및 물리적 노드들과 관련된 용어를 예시하는 도면이다.
도 11은 데이터 수집 관계 및 정책 수립을 위한 예시적인 절차를 예시하는 흐름도이다.
도 12는 DC로부터 송신된 요청에 대한 예시적인 일반적 메시지 구조를 도시하는 도면이다.
도 13은 데이터 수집 및 보고를 위한 예시적인 절차를 예시하는 흐름도이다.
도 14는 데이터 보고 메시지에 대한 일반적 메시지 구조를 도시하는 도면이다.
도 15는 데이터 수집 관계 및 정책 업데이팅을 위한 예시적인 절차를 나타내는 흐름도이다.
도 16은 DP의 예시적인 일반적 아키텍처를 도시하는 도면이다.
도 17은 구성된 노드 가용성 추정기 함수의 간단한 예를 도시하는 도면이다.
도 18은 SP에서의 서비스 프로비저닝 방법을 예시하는 흐름도이다.
도 19는 DC로부터 클라이언트로의 예시적인 응답 메시지를 나타내는 도면이다.
도 20은 노드 가용성 인식 세션 확립을 위한 절차를 예시하는 흐름도이다.
도 21은 지능형 스토어 및 전송 프리페칭에 대한 절차를 예시하는 흐름도이다.
도 22는 사전 대비적 노드 트리거링을 위한 예시적인 절차를 나타내는 흐름도이다.
도 23은 다수의 DC, DP 및 SP 간의 상호 작용들을 도시하는 도면이다.
도 24는 데이터 수집 프로세스에서 협력하는 2개의 DP를 나타내는 흐름도이다.
도 25는 서비스 프로비저닝 프로세스에서 협력하는 2개의 DP와 서로 간에 정보를 공유하는 2개의 SP를 나타내는 흐름도이다.
도 26a-26b는 NAE 서비스를 지원하기 위해 기존의 oneM2M 기능적 아키텍처를 향상시키기 위한 예시적인 실시예들을 도시하는 도면들이다.
도 27은 oneM2M 서비스 컴포넌트 아키텍처에서 NAE의 구현 아키텍처를 도시하는 도면이다.
도 28은 oneM2M 서비스 계층에서의 NAE의 예시적인 데이터 수집, 처리 및 노드 가용성 서비스 프로비저닝 실시예들을 예시하는 도면이다.
도 29는 oneM2M 서비스 계층에서의 예시적인 데이터 처리 실시예를 나타내는 도면이다.
도 30a 및 도 30b는 실시예들에서 이용될 수 있는 예시적인 리소스들을 나타내는 도면들이다.
도 31은 일 실시예의 그래픽 사용자 인터페이스의 도면이다.
도 32a는 하나 이상의 개시된 실시예가 구현될 수 있는, 예시적인 머신-대 머신(machine-to machine)(M2M), 사물 인터넷(Internet of Things)(IoT) 또는 사물 웹(Web of Things)(WoT) 통신 시스템을 도시하는 도면이다.
도 32b는 하나 이상의 개시된 실시예가 구현될 수 있는 예시적인 M2M 서비스 계층을 도시하는 도면이다.
도 32c는 UE 또는 다른 디바이스와 같은 예시적인 디바이스를 도시하는 도면이다.
도 32d는 개시된 실시예들의 노드들 또는 논리 엔티티들 중 임의의 것을 구현하는데 사용될 수 있는 예시적인 컴퓨터 시스템 또는 서버를 도시하는 도면이다.
도 7은 상이한 노드 비가용성 사례들을 갖는 M2M/IoT 시스템을 도시하는 도면이다. 도 7에 도시된 기능성은, 예를 들어 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 노드의 메모리에 저장되고 그 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있음이 이해된다.
대부분의 종래 시스템은 리소스 제한 디바이스들에 대한 에너지 효율 설계 원리에 의해 주로 야기되는 물리적 노드 수면 문제에 초점을 둔다. 슬리피 노드들로 한정되는 대신에, 실시예들은, 노드 개념이 물리적 노드뿐만 아니라 논리 노드를 참조함으로써 확장될 수 있다는 점에서 "노드 가용성"에 관한 것이며, 예를 들어, 서비스 계층 인스턴스 또는 애플리케이션 인스턴스(예를 들어, oneM2M 도메인 내의 각각의 CSE 또는 AE)는, 실제로 물리적 디바이스 상에서 실행되는 소프트웨어 모듈일 수 있다.
주어진(물리적/논리적) 노드에서는, 다음과 같은 원인으로 인해 비가용성이 초래될 수 있다.
Figure 112018084155826-pat00001
디바이스(702)는 물리적 노드 자체가 (PHY 계층에서) 이용 가능하지 않도록 수면 상태로 들어간다. 이것은 이전 섹션에서 논의된 고전적인 사례이다.
Figure 112018084155826-pat00002
기본 네트워크는, 노드가 격리되어 다른 피어들과 상호 작용할 수 없게 되는(즉, 네트워크 계층에서 이용 가능할 수 없게 되는) 일상적인 동작들(예를 들어, 리소스들을 해제하기 위한 셀룰러 네트워크들에서의 정상 접속 해지 동작(normal connection torn-down operation)) 또는 네트워크 문제들(예를 들어, 네트워크 트래픽 정체)을 갖는다.
Figure 112018084155826-pat00003
디바이스(704)는, 상위 계층 실행 소프트웨어가 무선 인터페이스로부터 수신된 임의의 정보에 응답할 수 없도록 자신의 컴퓨팅 리소스들(예를 들어, CPU, RAM 등)을 모두 소비한다. 유사하게, 디바이스 상의 특정 소프트웨어 모듈은 충돌(crash)(예를 들어, 소프트웨어 에러)될 수 있거나, 또는 운영 체제에 의해 디스에이블될 수 있다. 상기 2가지 경우(즉, 서비스 및 애플리케이션 계층에서 이용 가능하지 않은 경우)에 대해, 소프트웨어가 서비스 계층 인스턴스(예를 들어, CSE)와 관련되는 경우, 이 CSE는 이용 가능하지 않을 것이다. 이와 대조적으로, 소프트웨어가 애플리케이션 인스턴스(예를 들어, AE)와 관련되는 경우, 이 AE만이 이용 가능하지 않게 될 것이다.
서비스 계층 관점에서, 본 명세서에서 고려되는 노드 개념은 물리적 디바이스 또는 논리 노드(예를 들어, oneM2M 콘텍스트 내의 CSE 또는 AE) 중 어느 하나일 수 있다. 따라서 "노드가 이용 가능함"은, 노드가 다른 피어들과 상호 작용하고 통신할 수 있음을 의미한다. "노드"의 확장된 개념으로 인해, 에너지 효율성 목적을 위해 수면하는 물리적 노드(예를 들어, 센서들)와 같은 고전적인 이유 외에도 많은 새로운 요인들이 노드 비가용성을 초래할 수 있다.
노드 가용성 정보는 M2M/IoT 시스템들 내의 서비스 계층에서 효율적인 종단 간 통신(end-to-end communications)에 매우 중요하다. 예를 들어, CSE(예로서, CSE-1)는, CSE-2가 오랫동안 이용 가능하지 않음을 알게 되면, CSE-2에 접촉을 시도하는 대신 CSE-2에 대한 통신 접속 요청을 개시하지 않고 실패된 접속 확립 동작으로 끝나도록 지능적으로 선택할 수 있다. 특히, 노드 가용성 지식은 즉시 명확하지 않거나 미리 알려지지 않는 경우가 종종 있다(예를 들어, 물리적 노드는 고정된 수면 스케줄을 갖지 않을 수 있거나, 또는 논리 노드는 소프트웨어 오버로딩이나 에러와 같은 런타임 문제들로 인해 수시로 이용할 수 없게 될 수 있다). 따라서, 그런 노드 가용성 정보가 서비스 계층에서 누락될 때의 근본적인 질문은, 노드 가용성을 어떻게 추정할 것인가? 이다. 기존 서비스 계층에는 노드 가용성을 추정할 수 있는 능력이 없으며, 이러한 고유한 피처를 제공하기 위해 서비스 계층을 어떻게 향상시킬지를 다루는 작업도 이전엔 없었다.
크로스 프로토콜 스택 노드 가용성. 노드 가용성이 프로토콜 스택을 통해 지원될 수 있지만(다음에 언급된 바와 같이 반응적 방식으로), 노드 가용성을 추정하는 관점에서 노드 가용성을 사전에 대처하는 방법은 하위 계층들의 임의의 기존 작업들의 범위에 있지 않는다. 예를 들어, MAC 계층은 에너지 절약을 위해 슬리피 노드 지원을 가능하게 할 수 있지만, 예를 들어 CSE 인스턴스에 대한 소프트웨어 에러로 인해 서비스 계층에서 CSE 비가용성 이벤트를 인식하지 못하거나 이해할 수 없다. 특히, MAC 계층은 타이머들을 갖는다는 의미에서 상위 계층에서 비가용성 문제를 종종 반응적으로 다루며, 타이머들에 의해 표시된 대시 기간 이후에 상위 계층으로부터 응답이 얻지 못하면 무선 리소스들(PHY & MAC)을 해제할 수 있다. 마찬가지로, 네트워크 계층에서의 기존 작업은 수면 노드 지원이 있는 IPv6 이웃 검색에 초점을 맞추었지만, 상위 계층에서의 CSE 비가용성 이벤트도 역시 이들의 범위에 있지 않는다. MAC 계층에서, IP 계층은 타임 아웃 후에 리소스를 해제하기 위해 타이머들을 이용함으로써 상위 계층에서 비가용성 문제를 반응적으로만 처리할 수 있다. 한편, 서비스 계층에서 수면이 구성되지 않은 경우, 슬리피 노드의 가용성을 위해 서비스 계층이 하위 계층들에게 질의할 수 있는 것은 사실이다. 그러나 디바이스들이 미리 정의된/명확한 수면 스케줄 없이 이벤트-구동 방식으로 작동되는 경우(대부분의 M2M/IoT 시나리오들에서의 경우), 하위 계층들은 현재 시간에 대한 노드 가용성(즉, 현재 무슨 일이 일어나고 있는지)만을 제공할 수 있고, 추정된 가용성 패턴이나 스케줄을 제공할 수 없다. 전반적으로, (이들 접속 개시자들에 더 근접하는) 서비스 계층이 노드 가용성을 추정할 수 있는 능력을 갖는다면, 사전 대비적으로 종료할 수 있거나, 또는 가능한 노드 비가용성에 기인한 낮은 성공 확률을 갖는 요청들에 대한 접속 확립 프로세스를 시작조차 하지 않는 것이 바람직할 것이다. 이런 방식으로, 서비스 계층은 접속이 확립될 수 없다는 것을 반응적으로 파악하기 위해 하위 계층에 의존할 필요가 없다.
서비스 계층 노드 가용성. 서비스 계층 자체를 수평적으로 검사하는 것으로, 이것은 노드 가용성 추정을 현재 지원하지 않는다. 노드 가용성 추정이 수직 네트워크 스택을 검사함으로써 서비스 계층에서 수행되었다면 이롭지만, 불행하게도 기존 서비스 계층은 그런 서비스를 지원하지 않는다. <schedule> 리소스가 노드 수면 스케줄을 나타내기 위해 oneM2M 서비스 계층에서 정의되었지만, 이 정보를 어떻게 얻었는지는 완전히 조사되지 않은 것이 사실이다. 지금까지는, 노드 수면 스케줄이 노드들에 의해 보고되고 미리 알려졌으며(즉, 이미 사용 준비가 되어 있음), 특히 런타임 소프트웨어 에러로 인해 CSE가 이용 가능하지 않게 되는 경우가 명확하지 않다고 종종 가정했다. 그보다 앞서, 이전에 언급한 것보다 더 도전적이고 일반적인 경우는, 노드들이 명확하거나 미리 정의된 스케줄을 전혀 갖지 않을 수도 있다는 것이다. 이런 경우, 노드 가용성 추정은 서비스 계층에서 인에이블되어야 한다. 또한, 노드 가용성 추정을 위한 양호한 후보로서 서비스 계층을 고유한 위치에 있게 하는 많은 실시간 데이터(노드 가용성을 직접적으로 반영하지는 않지만 노드 가용성을 추정하기 위한 데이터 소스로서 매우 유용할 수 있음)를 제공하는 서비스 계층(기본 네트워크들 및 하위 계층들과 상호작용함)에는 기존 엔터티들이 많이 존재한다.
기존 서비스 계층은 노드 가용성에 의해 영향을 받을 수 있는 부가가치 서비스를 용이하게 할 수 없다. 노드 가용성 문제를 처리할 때 서비스 계층에서의 많은 기존 동작은 충분히 지능적이지 않을 수 있다. 이 섹션에서는 도 8에 도시된 바와 같은 대표적인 일례를 간략하게 나타낼 뿐이다.
도 8은 노드 가용성 정보가 없는 비효율적인 리소스 검색 동작들을 갖는 사용 사례를 도시하는 도면이다. 도 8에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리 노드에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 8에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 8에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 8에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
인프라구조 도메인(즉, IN-CSE(804)) 내의 CSE 상의 AE-1(802)은 그 애플리케이션 동작 요구 사항에 따라, 영역 네트워크에 있는 10개의 상이한 디바이스(예를 들어, Device-1 내지 Device-10) 상에서 10개의 CSE(예를 들어, CSE-1 내지 CSE-10)로부터 리소스들(예를 들어, Data-1 내지 Data-10)을 검색하도록 요구된다. CSE-1 내지 CSE-9가 이들의 리소스들을 방금 MN-CSE(806)에 보고했다고 가정하면, AE-1(802)은 MN-CSE(806)로부터 직접 이들의 리소스들(즉, Data-1 내지 Data-9)을 쉽게 획득할 수 있다. 그러나 현재 MN-CSE(806) 상에 저장된 Data-10가 이미 오래되었다면, MN-CSE(806)는 CSE-10으로부터 다시 Data-10을 검색해야 할 수도 있다. 그러나 Device-10이 이미 긴 시간을 수면하고 있었고 그 수면 스케줄이 서비스 계층에 미리 정의되고 보고(예를 들어, MN-CSE 내의 <schedule> 리소스에 저장)되지 않은 경우, 이러한 리소스 검색 동작은 하위 계층 메커니즘이 이 경우에 도움이 될 수 없다면 성공하지 못할 수 있다. 예를 들어, 프록시 또는 미러 서버가 수면 노드를 지원하기 위한 IETF CoRE 작업 그룹에 의해 애플리케이션 프로토콜 계층에서 구현되지만, AE-1은, 미러 서버 또는 프록시에 저장된 리소스가 오래되었을 경우에도 여전히 Device-10에 접촉해야 할 필요가 있을 수 있다. 따라서 Device-10 상의 성공적이지 못한 동작은 이전의 모든 노력(즉, CSE-1과 CSE-9 사이에서 Data-1 내지 Data-9의 성공적인 검색)을 무효로 할 것이고, AE-1에 대한 전체 동작의 실패를 초래할 것이다. 그 보다 앞서, 이전 동작들에서 소비된 네트워크 리소스들은 모두 어떤 이익을 가져 오지 않고 낭비된다. 실제로, 서비스 계층이 노드 가용성을 어떻게든 추정할 수 있다면, 상기 동작들은 본질적으로 개선될 수 있고 동작 요구 사항 인식 리소스 검색 동작(부가가치 서비스로서)이 인에이블될 수 있다. 전반적으로, 기존의 작업에서는 노드 가용성 문제를 처리할 때 어떤 부가가치 서비스들이 서비스 계층에 의해 인에이블될 수 있는지를 구체적으로 조사하지 않았다.
이하의 계산들의 일부에 대한 이론적인 배경으로서, 주어진 표적 변수 y(시간 t의 함수임)에 대한, 그것의 현재 및 미래 값들은 과거 시간 단위들에서의 이력 값들에 기초하여 추정될 수 있다.
공식적으로, 주어진 관심 노드 i에 대해, 부울 변수 yi(t)는 시간 단위 t(현재 시간 단위가 tc라고 가정)에서 노드 i의 가용성을 나타내기 위해 정의된다. 예를 들어, yi(t)=1은 노드 i가 시간 단위 t에서 이용 가능한 반면, yi(t)=0은 노드 i가 이용 가능하지 않은 것을 의미한다. 노드 i의 가용성을 추정하기 위해서는 추정기를 구축할 필요가 있다. 사실, yi(t)의 추정기는 시간 단위 t의 함수(fi(t)로 표시됨)로 공식화될 수 있는데, 이는 다음과 같이 주어진다:
Figure 112018084155826-pat00004
fi(t)는 다항식, 선형 또는 비선형 등일 수 있는 t의 함수일 수 있고, 다수의 파라미터, 즉, an, an-1, ... a1, a0을 포함한다는 것을 알 수 있다. 처음에, 이들 파라미터는 임의의 구체적인 값을 갖지 않는다. 특히, "추정기 구축 프로세스"는 곡선 피팅, 시계열 분석 등과 같은 상이한 기술을 기반으로 이들 파라미터의 값을 결정하기 위해 이전 시간 단위들(예를 들어, yi(tc-1), yi(tc-2), ... yi(tc-k))에서 yi(t)의 이력 데이터를 이용하는 것이다. 구체적인(concrete) fi(t)가 형성되면(즉, 모든 파라미터 an, an-1, ... a1, a0가 구체적인 수치 값들을 가지면), 이것은 tc에 대한 노드 i의 가용성 및 tc 이후의 미래 시간 단위를 추정하기 위한 추정기로서 이용될 수 있다. 이것은, 시간 단위 t'≥tc가 주어지면 추정기 fi가 시간 단위 t'에서 추정된 노드 가용성으로서 간주될 수 있는 일치하는 y(t')를 출력할 것이기 때문이다.
단지 간단한 예로서, 노드 i는, 과거 20의 시간 단위 동안 4의 시간 단위를 수면한 다음 다시 수면으로 가지 전에 또 다른 6의 시간 단위에 기상하는 다음의 이력 가용성 스케줄을 갖는다고 가정한다. 이들 정보에 기초하여, 추정기는 구축될 수 있고 다음과 같은 구체적인 표현을 가질 수 있다(즉, 전체 수학식에는 임의의 결정되지 않은 파라미터들이 없다. MOD가 모듈로 연산을 나타내는 것에 유의한다):
Figure 112018084155826-pat00005
따라서, 현재 또는 미래의 시간 단위 t를 수학식 2에 입력함으로써, 0 또는 1 값을 출력할 것이고, 이것은 그 시간 단위에서의 노드 i의 추정된 노드 가용성이다.
노드 가용성 추정(NAE) 서비스는, 각각의 컴포넌트가 개별 기능성을 갖는다는 의미에서 느슨하게 결합된 방식(loosely-coupled way)으로 구현될 수 있다. 도 9a는 NAE가 어떻게 서비스 계층에 적응하는지에 대한 일 실시예를 도시하는 도면이다. 도 9a 및 다수의 다음 도면에서는, oneM2M 서비스 계층을 예로써 사용할 것이다. 본 명세서가 oneM2M의 예에 초점을 맞추지만, 설명된 실시예들은 oneM2M에 한정되지 않으며 임의의 서비스 계층으로 일반화될 수 있다.
도 9a의 예에서, NAE(902)는 CSF로 간주될 수 있다. NAE(902)는 기존 CSF들(예를 들어, 세션 관리 CSF, 통신 관리 전달 처리(Communication Management Delivery Handling)(CMDH) CSF 등)과 상호 작용함으로써 노드 가용성 추정을 달성할 수 있다. NAE(902)가 배치되는 방식(중앙 집중 방식 또는 분산 방식)에 따라, 상이한 기준점들(예를 들어, mac, mcc, mcc' 또는 mcn)이 영향을 받을 것이다.
도 9b는 NAE(902)의 기능적 아키텍처를 도시하는 도면이다. 도 9b의 예에서, NAE(902)는 3개의 컴포넌트를 갖는다.
데이터 수집(Data Collection)(DC)(904). 노드 가용성을 도출 또는 추정하기 위해, NAE(902)는 DC(904)를 이용하여 입력 소스들(예를 들어, oneM2M 서비스 계층에서 기존 CSF들일 수 있음)로부터 실시간 데이터를 수집할 수 있다. DC(904)와 DP(906) 사이의 상호 작용은 다음과 같을 수 있다: 한편으로, DC(904)는 수집된 데이터를 데이터 처리(Data Processing)(DP)(906) 컴포넌트에 입력하는데, 여기서 수집된 데이터는 상이한 노드들의 가용성을 추정하기 위해 처리될 것이고; 반면에, DP(906)는 노드 가용성 추정 결과들의 정확성 또는 신뢰도(confidence)를 평가함으로써 데이터 수집 전략에 관해 DC(904)에게 동적으로 또한 통지한다. 즉, DC(904)는 DP(906)에 의해 제공된 데이터 수집 전략에 따라 입력 소스들로부터 데이터를 수집할 수 있다.
데이터 처리(DP)(906). DP(906)는 (예를 들어, 데이터 해석, 정보 추론, 정보 융합, 노드 가용성 추정기의 구축 등과 같은) 다수의 처리 단계를 실행할 수 있고, DC(904)로부터 수집된 데이터에 기초하여 노드 가용성에 대한 추정된 결과들을 산출할 수 있다. 또한, DP(906)는 추정된 결과들의 정확성을 평가한 다음, DC(904)에 대한 동작 가이드라인인 데이터 수집 전략을 동적으로 조정할 수 있다.
서비스 프로비저닝(Service Provisioning)(SP)(908). DP(906)는 노드 가용성 정보를 질의하기 위한 포털(여기서 클라이언트들은 NAE(902)와 상호 작용할 수 있음)인 SP(908)에 노드 가용성 추정 결과들을 출력할 수 있다. 특히, DP(906)는 추정된 노드 가용성 정보를 "노드 가용성 추정 서비스들"로서 서비스 클라이언트들에게 제공한다.
도 9b의 예에는, 입력 소스들 또는 서비스 클라이언트들 사이의 상호 작용 루프가 존재한다. 특히, 한편으로, DC(904)와 상호 작용할 때, 입력 소스들(910)(예를 들어, NAE에 속하지 않는, oneM2M 서비스 계층 내의 기존 CSF들)은 성능, 구성, 이벤트 로그, 에러 보고, 통계 등과 관련된 데이터와 같은 다양한 실시간 데이터를 DC(904)에 제공한다. 다른 한편으로, SP(908)에 의해 제공되는 노드 가용성 추정 서비스들에 액세스할 때, 이들 CSF는 NAE(902)의 서비스 클라이언트들(910)이기도 하다.
도 9a-9b에 도시된 기능성은 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능한 명령어들)의 형태로 구현될 수 있음이 이해되어야 한다.
도 10은 NAE, 및 논리 및 물리적 노드에 관련된 용어를 예시하는 도면이다. 후술하는 바와 같이, 표적 노드는 oneM2M 서비스 계층 내의 CSE와 같은 논리 노드일 수 있고, 반면에 CSE는 하나 이상의 특정한 타입의 CSF들의 세트를 구현하는 인스턴스이다. NAE는 다른 CSF(예로서, CSF-1)와 상호 작용할 수 있으며, 이것은 2개의 CSE(NAE 및 CSF-1을 각각 구현함) 사이의 통신을 수반할 수 있다. "노드의 추정된 가용성"을 논의할 때, 이것은 일반적으로 물리적 노드 또는 논리 노드(AE 또는 CSE와 유사함)를 지칭한다. 그러나, 예를 들어 실시간 데이터가 어떻게 수집될 수 있는지와, 추정된 결과들이 어떻게 제공되는지에 관한 NAE의 설계 세부 사항을 논의할 때, 그 논의는 표현의 편의를 위해 CSF의 맥락을 가질 수 있다.
DC(904)는 DP에 의해 만들어진 데이터 수집 전략에 따라 입력 소스들로부터 데이터를 수집할 수 있다. 전형적으로, 데이터 수집 전략 내의 한 항목에는 다음과 같은 정보가 포함될 수 있다(그러나 이에 국한되지 않음):
- 소스, 예를 들어 DC(904)가 데이터를 수집하고자 하는 입력 소스(예를 들어, oneM2M 서비스 계층 내의 세션 관리 CSF).
- 관심 노드, 예를 들어 그 가용성을 추정하기 위해 NAE(902)가 관심을 갖는 노드.
- 관심 데이터, 예를 들어 DC(904)가 소스로부터 수집하고자 하는 관심 노드의 데이터 타입, 예로써, 전술한 세션 관리 CSF(소스로서)로부터 수집될 수 있는 CSE-1(즉, 관심 노드)의 세션 로그 데이터.
- 메시지 포맷, 즉 데이터 교환에 사용될 포맷.
- 초기 정책에서의 바람직한 값이 충족될 수 없다면, 바람직한 데이터 보고 빈도, 지속 기간, 우선순위 및 최소 수용 QoS 요구 사항에 관한 정책.
데이터 수집 전략 내의 각각의 항목에 대해, DC(904)는 대응하는 입력 소스들과 상호 작용할 수 있다. 특히, 이하 후술되는 바와 같이, 데이터 수집 프로세스 동안에는 세 가지 절차가 수반될 수 있다.
도 10에 도시된 기능성은 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능한 명령어들)의 형태로 구현될 수 있음이 이해되어야 한다.
DC(904)가 전술한 바와 같이 데이터 수집 전략 내의 항목에 따라 입력 소스로부터 데이터를 수집할 필요가 있을 때, 소스와의 데이터 수집 관계가 개시될 수 있다. 도 11은 데이터 수집 관계 및 정책 수립을 위한 예시적인 절차를 나타내는 흐름도이다.
도 11의 단계 1에서, DP(906)는 새로운 데이터 수집 전략을 결정한다. 데이터 전략은 데이터베이스 테이블과 유사하며 각 항목에는 소스, 관심 노드, 관심 데이터, 데이터 교환 포맷 및 데이터 수집 정책 등과 같은 다수의 속성으로 정의된 데이터 수집 요구가 포함되어 있다고 생각될 수 있다. 실제적인 데이터 교환 포맷은 다양한 구현 선택에 달려 있다.
도 11의 단계 2에서, DP(906)는 임의의 데이터 수집 동작들을 실행하기 위한, DC(904)에 대한 트리거 또는 가이드라인인 데이터 수집 전략에 관해 DC(904)에게 통지한다. 즉, DC(904)는 데이터 수집에 대한 자체 결정을 내리지 않고 DP(906)로부터의 데이터 전략을 따르기만 한다(이러한 기능성 분할 설계 원리는 느슨한 접속 시스템들(loose-coupled systems)을 구축하는 데 유용하다).
도 11의 단계 3에서, 데이터 수집 전략을 수신한 후에, DC(904)는 이것을 항목별로 체크하고, 취해질 필요한 동작들을 결정한다. 데이터 수집 전략에서 각각의 특정한 항목을 처리할 때, 두 가지 사례가 있을 수 있다: 사례 1) DC(904)는 이 항목에 표시된 요구를 충족시키기 위해(이 섹션에서 설명한 대로) 새로운 데이터 수집 관계를 개시할 필요가 있다. 사례 2) DC(904)는 해당 항목에 의해 표시된 요구를 충족시키기 위해 기존 데이터 수집 관계만을 업데이트할 필요가 있다.
도 11의 단계 4에서, DC(904)는 새로운 데이터 수집 관계를 확립하기 위한 요청을 소스에 송신한다. 도 12는 이 단계에서 사용되는 요청에 대한 예시적인 일반적 메시지 구조를 도시하는 도면으로, 이 구조는 주로 데이터 수집 전략의 각 항목의 속성들을 운반한다. 특히, 수신기 ID(1202)는 메시지 수신기를 나타낼 수 있다. oneM2M 서비스 계층을 예로 들면, 이는 특정 CSF(즉, 소스로서)를 지원하는 CSE 인스턴스의 CSE-ID일 수 있다. 타입 도메인(1204)은, 이 요청 메시지가 데이터 수집 관계 및 정책 수립을 위해 NAE(902)로부터 온 것임을 나타낼 수 있다. 페이로드 부분(1206)은 서브 메시지들의 리스트를 운반하며(서브 메시지들 각각은 사례 1에 속하는 항목에 대응함), 모든 대응하는 항목은 (수신기 ID에 의해 표시된 바와 같은) 동일한 소스를 갖는다. (도 12의 하단에 표시된) 각각의 서브 메시지는 다음과 같은 정보를 포함한다: 1) 노드 ID는 관심 노드가 어느 것인지를 나타내고; 2) 이 노드와 관련하여 어떤 데이터가 수집될 필요가 있는지('D' 도메인은 수집될 n 개의 관심 데이터를 기술하기 위해 다음과 같은 필드들이 사용되는 것을 나타냄); 3) 'T' 도메인은 데이터 수집 프로세스의 지속 기간을 기술하기 위해 다음과 같은 하나의 필드가 사용되는 것을 나타내고; 4) 이 데이터 수집 관계에 관한 정책은 'P' 도메인 이후의 m 개의 필드에 의해 기술된다.
도 11의 단계 5에서, 주어진 데이터 수집 관계에 대해서는, 정책에 표시된 바와 같은 QoS 요구 사항이 소스에 의해 충족/만족될 수 없는 가능성이 있다. 이에 따라, 각 데이터 수집 관계에 대한 소스와 DC(904) 사이에는 수차례의 협상 프로세스가 있을 수 있다. 다시 말해서, DC(904)는 초기 요청 메시지에 바람직한 QoS 요구 사항들 및 정책을 먼저 포함할 것이지만, DC(904)는, DC(904) 및 소스 모두가 QoS 요구 사항들 및 정책에 대한 일관된 합의를 달성할 때까지 충족될 수 없다면 타협할 수 있다. 그러나 최소 허용 QoS가 심지어 충족될 수 없다면, DC(904)는 그러한 데이터 수집 관계를 확립하는 것을 포기할 수 있다.
도 11의 단계 6에서, 일관된 QoS 요구 사항 합의를 달성할 때, 소스는 관련된 실시간 데이터를 DC(904)에 적절히 보고하기 위해 새로운 확립된 데이터 수집 관계를 지원하기 위한 새로운 트리거들을 정의할 수 있다.
도 11의 단계 7에서, 일단 새로운 트리거들이 소스에 의해 설정되면, 데이터 수집 관계가 성공적으로 확립되었고, 나중에 참조하기 위해 "dataCollectionRelationshipID"와 연관되었음을 나타내기 위한 확인을 DC(904)에 다시 송신할 수 있다.
도 11의 단계 8에서, 초기 데이터 수집 전략이 DP(906)에 의해 결정되고 QoS 요구 사항이 DC(904)에 의해 소스와 협상할 때 수정될 수 있기 때문에, DC(904)는 그 인식을 위한 확인을 DP(906)에 다시 송신할 수도 있다.
도 11에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 11에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 11에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 11에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 13은 데이터 수집 및 보고를 위한 예시적인 절차를 나타내는 흐름도이다. 일단 데이터 수집 관계가 확립되면, DC(904)는 소스들로부터 보고하는 데이터를 수신할 수 있다.
도 13의 단계 1에서, 마지막 섹션에서 언급한 바와 같이, (예를 들어, DC가 관심이 있는 데이터의 특정 조각(specific piece)이 보고되었을 때) 일부 트리거들은 소스들 내에 정의될 수 있다(도 11의 단계 7 참조). 이에 따라, DC가 관심이 있는 새로운 데이터가 기록될 때, 데이터 보고 동작을 트리거할 수 있다.
도 13의 단계 2에서는, 새로운 데이터가 소스로부터 DC로 송신된다. 도 14는 이 단계에서 사용되는 데이터 보고 메시지에 대한 일반적 메시지 구조를 도시하는 도면이다. 특히, 송신자 ID(1402)는 데이터가 어디서 오는지를 나타낼 수 있다. 페이로드 부분(1404)은 서브 메시지들(이들 각각은 진행 중인 데이터 수집 관계에 대한 데이터 보고 레코드에 대응함)의 리스트를 또한 운반한다. 각각의 서브 메시지(도 14의 하단에 표시됨)에서는 다음과 같은 정보를 포함한다: 1) dataCollectionRelationshipID는 데이터와 관련되는 기존 데이터 관계를 나타내고; 2) 노드 ID는 데이터가 어떤 노드와 관련되는지를 나타내고; 3) 'D' 도메인 이후의 필드들은 관심 데이터의 수 n이다. oneM2M 서비스 계층에서 기존의 CSF들로부터 어떻게 데이터를 수집하는지를 예시하는 서브 메시지의 구체적인 실시예가 아래에 설명된다. 대안적으로, 도 14에 도시된 바와 같이 다양한 관심 노드와 관련된 데이터를 하나의 메시지에 넣는 대신에, 소스는 각각의 관심 노드에 대한 데이터를 모을 수 있고, 각각의 메시지는 하나의 노드와 관련된 데이터만을 포함할 수 있다.
도 13의 단계 3에서, 소스로부터 새로운 데이터를 수신한 후, DC(904)는 먼저 데이터 무결성을 체크한 다음 유용한 정보를 추출함으로써 데이터를 해석할 수 있다.
도 13의 단계 4에서, DC(904)는 성공적인 데이터 수신 동작을 위한 확인을 소스에 다시 송신한다.
도 13의 단계 5에서, DC(904)는 또한 추가 처리를 위해 데이터를 DP(906)에 전송한다.
도 13에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 13에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 13에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 13에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 15는 데이터 수집 관계 및 정책 업데이팅을 위한 예시적인 절차를 나타내는 흐름도이다. DC(904)가 소스와의 진행 중인 데이터 수집 관계를 이미 가질 수 있지만 새로 수신된 데이터 수집 전략을 충족시키기 위해 필요한 수정이 요구되는 것은 가능하다. 이러한 경우, DC(904)는 단지 업데이트 요청만을 송신할 필요가 있다. 이 섹션에서는 데이터 수집 관계 및 정책 업데이트를 위한 대응하는 절차를 제시한다.
도 15의 단계들 1-3은 도 11의 단계들 1-3과 동일하다.
도 15의 단계 4에서, 기존 데이터 수집 관계(즉, 도 11의 단계 3에서 논의된 바와 같은 사례 2)에 대해 업데이트하도록 요구될 때, DC(904)는 업데이트 요청을 소스에 송신할 것이다. 한편, 모든 정보를 송신하는 대신, DC(904)는 요구된 변경과 연관되는 dataCollectionRelationshipID 만을 송신할 필요가 있다. oneM2M 서비스 계층으로부터 일례를 취하면, DC(904)는, 관심 노드(예컨대, CSE-1)에 대한 데이터 수집 지속기간을 연장할 필요가 있는 세션 관리 CSF를 나타낼 수 있다. 그 외에도, 데이터 수집 업데이트는 더 많은 데이터 요소를 수집하거나, 데이터 보고 빈도, 우선순위를 수정하거나, 또는 현재 데이터 수집 관계를 종결하도록 요구할 수 있다. 또한, 업데이트 요청의 메시지 포맷은 도 12에 표시된 메시지 포맷과 매우 유사할 수 있으므로(dataCollectionRelationshipID를 포함하는 필드를 서브 메시지에 추가하기만 하면 됨), 간결한 표현을 위해 본 명세서에 표시되지 않는다.
도 15의 단계 5에서는, 소스가 업데이트 요청을 수락하면, 대응하는 트리거들에 대해 수정을 행하여 그러한 변경을 반영한다. 업데이트 요청의 경우, 일관된 서비스 품질(Quality of Service)(QoS) 요구 사항 합의를 달성하기 전에 DC(904)와 소스 간에 협상 프로세스(도 11과 동일함)가 있을 수 있다. 도 15는 이 프로세스를 반영하지 않는다.
도 15의 단계 6에서, 트리거들이 업데이트 요청에 기초하여 성공적으로 재구성되면, 소스는 DC(904)에 확인을 다시 송신할 것이다.
도 15의 단계 7에서, DC(904)는 또한, 그 인지를 위한 확인을 DP(908)에 다시 송신할 것이다.
도 15에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 15에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 15에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 15에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 16은 DP(906)의 예시적인 일반적 아키텍처를 도시하는 도면이다. 도 16에 도시된 기능성은 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능한 명령어들)의 형태로 구현될 수 있음이 이해되어야 한다.
이 예시적인 아키텍처는 상이한 서브 기능성들을 갖는 다수의 모듈을 갖는다. DP(906)는 입력 소스들로부터의 수집된 데이터에 기초하여 노드 가용성을 추정할 수 있다. 도 16은 상이한 모듈들 간의 정보 흐름(화살표로 표시됨)을 또한 도시한다. 이것들은 모두 본 명세서에서 제안한 신규한 아이디어이다. 또한, 후속 섹션에서는 각각의 모듈들의 실시예들의 설계 세부 사항을 소개하여 단계별로 노드 가용성을 어떻게 추정할 수 있는지를 설명할 것이다. 특히, 각각의 모듈의 세부 사항들(예를 들어, 데이터를 사전 처리하는 방식, 다항 모델을 이용하여 추정기를 구축하는 방식 등)을 소개하기 위해 특정 기술이 일례로서 사용되지만, 임의의 기술이나 접근법이 DP(906)의 모듈들 각각을 구현하기 위해 사용될 수 있으며 일반적인 접근법이 없다는 것에 유의해야 한다.
모듈 A(1602)는 정보 추론 모듈이다. 모듈 A(1602)는 DC(904)로부터 다양한 실시간 데이터를 수신할 수 있다; 이 데이터는 추정기를 구축하는데 사용될 수 있는 정규화된 값(예를 들어, 노드 가용성을 나타내기 위한 부울 값 "0" 또는 "1")으로 변환될 수 있다. 관심 노드 i와 관련된 데이터 j의 주어진 조각에 대해, yi,j(t)(부울 변수)는 시간 단위 t≤tc(tc는 현재 시간으로서 표시됨)에서 노드 가용성으로서 정의되며, 이것은 데이터 j로부터 정보를 추출함으로써 추론된다. yi,j(t)에 대한 값을 결정하기 위해, 데이터 j에서의 정보에 기초하여 yi,j(t)에 대해 "0" 또는 "1"을 설정할지를 추론하는 추론 프로세스가 필요하다. oneM2M 서비스 계층에서 예를 든다면, (세션 관리 CSF로부터 수집된) 데이터 j가, AE1이 [0, t1] 동안 AE2와 통신하고 있다는 것을 나타내는 경우, [0, t1] 동안 각각의 시간 t에 대해 "1"을 yi,j(t)에 설정함으로써, AE1이 [0, t1] 동안 이용 가능하다는 것이 추론될 수 있다. 이러한 추론 프로세스는 최선의 노력으로 실행될 수 있으므로, 실제 상태가 데이터의 특정 조각에만 기초하여 올바르게 추론될 수 없는 가능성이 있게 된다. 따라서, 대응하는 데이터 융합 프로세스는, 다음 섹션에서 논의되는 바와 같이, 정보 충실도를 향상시키기 위해 사용될 수 있다.
데이터 j에 포함된 정보에 기초하여 노드 i에 대한 변수 yi,j(t)에 대해 "0" 또는 "1" 값을 추론한 후에, 모듈 A(1602)에서의 추가 추론 단계는, 노드 i와 직접 관련된 소정 데이터가 다른 노드들의 가용성을 간접적으로 반영할 수 있다는 의미에서, 데이터 재사용과 관련된다. 예를 들어, 물리적 노드 Device-1이 [0, t1] 동안 수면으로 인해 이용 가능하지 않다고 추론되는 경우, CSE-1 및 AE-1의 둘 다가 Device-1에서 실행 중이라면 이들 중 어느 하나가 이용 가능하지 않을 수 있다고 추론될 수도 있다. 결과적으로, Device-1과 관련된 데이터의 한 조각은 또한, 논리 노드들 CSE-1 및 AE-1의 가용성을 추정하기 위해 이용될 수 있다.
모듈 B(1604)는 정보 융합 모듈이다. 모듈 B(1604)의 초점은 여전히, 특정한 시간 단위 t≤tc에서 노드 i의 이력 가용성에 있다. 사실, 주어진 시간 단위 t≤tc에서는, 노드 i의 가용성과 관련되는 많은 데이터 조각(예로써, W)이 있을 수 있다. 결과적으로, 그러한 데이터 각각으로부터, 이것은 대응하는 yi,j(t)를 가지며 그러한 yi,j(t)의 세트는 리스트 Yi(t)로 표시될 수 있으며, 이것은
Figure 112018084155826-pat00006
에 의해 주어진다. Yi(t)에 대해, 모듈 B(1604)는 리스트 Yi(t)를 단일 부울 값으로 변환함으로써 데이터 융합 동작(임의의 기존의 정교한 플러그-인 기술을 레버리지화할 수 있음)을 실행할 것이고, 이는 최종적으로 yi(t)의 값으로 간주될 것이다. 예를 들어, Yi(t)가 수학식 4에 표시된 콘텐츠를 갖는다고 가정하면, 이것은 시간 단위 t≤tc에서 노드 i의 가용성과 관련된 데이터의 13개 조각에 기초하여 획득된다.
Figure 112018084155826-pat00007
데이터 융합 프로세스 후에, Yi(t)는 단일 "0"에 융합될 것이고, 이것은 시간 단위 t에서 노드 i가 이용 가능하지 않음을 이들 대부분이 나타내기 때문에 yi(t)에 할당된다.
모듈 C(1606)는 노드 가용성 추정기를 구축하는데 사용되는 알고리즘에 대한 입력 포맷 파싱 모듈(Input Format Parsing module)이다. 주어진 노드 i에 대해, 마지막 섹션에 도시된 것과 같은 프로세스를 반복함으로써, 모듈 B에서 상이한 이전 시간 단위들(즉, tc-1, tc-2... tc-k)에 대해 다수의 yi(t)가 결정될 수 있다. yi(t)의 이러한 이력 값들은 다음과 같이 주어지는 순서 리스트 Li(tc, k)로서 정의될 수 있다:
Figure 112018084155826-pat00008
Li(tc, k)는 이제 추정기 모델링 알고리즘을 위해 거의 준비된 입력이다. 예를 들어, 어떤 관련된 실시간 데이터도 DC(904)로부터 수집될 수 없기 때문에, 일부 이력 시간 단위들에 대해서는 yi(t)의 값이 결정될 수 없다는 것에 유의해야 한다. 한편, 추정기를 구축하기 위해 모듈 D(1608)에서 사용되는 알고리즘의 입력 포맷 요구 사항에 따라, 모듈 C는 Li(t, k)를 요구된 포맷으로 파싱할 필요가 있다. 예를 들어, Li(t, k)는 스트링, 테이블 또는 2-튜플 리스트(tuple list) 등으로서 알고리즘에 직접 입력될 수 있다.
모듈 D(1608)는 노드 가용성 추정기 구축 모듈이다. 모듈 D(1608)의 작업(job)은 노드 가용성 추정기(즉, 이전 섹션에서 논의된 바와 같이, 다수의 이력 가용성 정보(즉, Li(t, k))가 주어진다는 의미에서 수학식 1에 정의된 바와 같은 노드 i에 대한 함수 fi(t))를 구축하는 것이고, 모듈 D(1608)는 함수 fi(t)의 파라미터들(즉, an, an-1, ... a1, a0)에 대한 값들을 결정한다.
여기서는, 이전의 예를 재사용하는, 추정기를 구축하는 방법을 설명하기 위한 간단한 예를 보여줄 뿐이다. 노드 i가 지난 20의 시간 단위 동안, 4의 시간 단위를 수면한 다음에 다시 수면으로 가기 전에 또 다른 6의 시간 단위에 기상하는 다음과 같은 이력 가용성 스케줄을 가짐을 알 수 있다. 즉, 수학식 5에서 정의된 순서 리스트 Li(tc, k)는 다음과 같은 콘텐츠를 갖는다:
Figure 112018084155826-pat00009
추정기를 구축하기 위해, 먼저 후보/프로토타입 함수가 선택될 필요가 있고, 프로토타입 함수가 일반적으로 이력 데이터의 것과 유사한 경향을 가져야 한다는 것이 주요 고려 사항이다. 예를 들어, 이력 데이터가 선형 트렌드를 반영하는 경우, 프로토타입 함수도 선형 표현식을 가져야 한다. 이 예에서, 노드 이력 가용성 스케줄이 일부 주기성을 반영하고, yi(t)가 부울-값 함수이기 때문에, 수학식 7에 표시된 다음과 같은 프로토타입 함수가 선택될 수 있다(실제로, 프로토타입 함수를 선택하는 방법은 주로 도메인 지식/경험에 달려 있다).
Figure 112018084155826-pat00010
수학식 7의 프로토타입 함수 내의 파라미터들은 이 시점에서 결정되지 않고, MOD가 수학식 2에서 논의된 바와 같이 모듈로 연산임을 기억하자. 다음으로, 이력 데이터를 이용함으로써, 수학식 7 내의 모든 파라미터에 대한 값들, 즉 a0, a1, ... a5를 결정하기 전에 소정량의 알고리즘 반복이 실행될 것이다(이 반복 프로세스는 종종 기성 소프트웨어(예를 들어, Matlab 등)에 의해 실행된다). 특히, 값 선택 원리는, 반복 프로세스 동안 이들 파라미터에 대한 최적 값들을 검색할 때 특정 함수 곡선이 이력 데이터에 어떻게 적응하는지를 평가할 수 있는 것에 있다. 예를 들어, 특정 파라미터 설정을 갖는 후보 함수의 경우에는, 후보 함수에 의해 출력된 이력 시간 단위들(즉, tc-1, tc-2 ... tc-k)에 대한 계산된 노드 가용성(yi~(tc-1), yi~(tc-2)... yi~(tc-k)로 표시됨)과, 이력 노드 가용성의 실제 값들, 즉 수학식 6에 표시된 바와 같은 yi(tc-1), yi(tc-2)... yi(tc-k) 사이의 편차를 측정할 필요가 있다. 마지막으로, 특정 파라미터 설정은, 수학식 8에 표시된 바와 같이 모든 이력 시간 단위에 대한 최소 합계 편차를 갖는다는 의미에서 바람직한 파라미터 설정이 될 것이다(간단히 말하자면, 이 함수는 이력 데이터에 가장 잘 맞는 결과를 갖는 함수이다).
Figure 112018084155826-pat00011
파라미터들의 값들이 결정된 후, 프로토타입 함수는 이제 추정기가 될 것이다(수학식 9의 우측 부분에 표시된 바와 같이, 수학식 7에 나타난 모든 파라미터는 수치 값들을 가짐).
Figure 112018084155826-pat00012
사실, 이러한 추정기 구축 프로세스는 시간 소모적일 수 있으며, 정확한 추정기 fi(t)의 관점에서 바람직한 결과를 획득하기 위해 상당한 계산 리소스들을 필요로 할 수 있다. 따라서, 추정기 구축 프로세스의 속도를 높이기 위해, 증분 구축 접근 방식(incremental building approach)이 항상 제안된다. 좀 더 정확히 말하자면, 처음부터 시작해서 fi(t)의 파라미터들에 대한 값들을 결정하는 대신, 기존 추정기 f'i(t)(존재하는 경우, 오래된 이력 데이터에 기초하여 구축됨)는, f'i(t) 내의 파라미터들의 모든 값들이 DC(904)로부터의 새롭게 수신된 데이터를 조합하여 교정되고 최종적으로 f'i(t)를 새로운 추정기 fi(t)로 업그레이드할 수 있는 기준이 될 수 있다. 또한, 추정기 구축 동안, 알고리즘 반복의 각각의 라운드는 상당한 시간이 걸릴 수 있으므로, 모듈 D(1608)는 필요할 때만 새로운 추정기 구축 프로세스만을 개시할 것이다.
모듈 E(1610)는 노드 가용성 추정 모듈이다. 모듈 D(1608)가 노드 i에 대한 추정기 fi(t)를 산출한 후에, 모듈 E(1610)는 추정기를 사용하여 t≥tc(tc는 현재 시간 단위임을 기억한다)에 대한 노드 i의 가용성을 추정할 것이다. 수학식 1에서 정의된 y=fi(t)가 t의 구체적인 함수이고 y가 노드 가용성을 나타내기위한 부울 변수이기 때문에, t를 입력하면 fi(t)의 출력은 해당 시간 단위에서 노드 i의 추정된 가용성이 될 것이다.
모듈 D(1608) 및 모듈 E(1610)의 주요 아이디어를 예시하기 위해, 도 17은 주어진 노드 i에 대한 대응하는 프로세스를 설명하는 간단한 예를 도시한다. 도면에 도시된 바와 같이, 과거 시간 단위들(모듈 C(1606)로부터 획득됨)에서의 이력 가용성 데이터(파란색 점들로 표시됨)의 리스트에 기초하여, 추정기가 구축될 수 있고, 이것은 도 17에서 실선 곡선으로 도시된다. 한편, 점선 적색 곡선은 미래 시간 단위들을 입력하여 실선 부분으로부터 연장되는데, 즉 적색 곡선 상의 녹색 점들은 미래 시간 단위들에 대한 추정된 가용성이다(실제로, 추정기는 다음의 하나 또는 여러 시간 단위에 대한 가용성을 추정하는 경우에만 정확할 수 있다).
모듈 F(1612)는 추정기 평가 및 데이터 수집 전략 결정 모듈이다. 노드 가용성 추정의 정확성에 영향을 미칠 수 있는 몇 가지 요인이 있음에 유의해야 한다. 첫째, 모듈 D(1608)에 충분한 이력 노드 가용성 입력이 부족하면(예를 들어, 많은 노드 가용성 데이터가 많은 과거 시간 단위에 대해 누락되면), 추정기는 부정확성의 측면에서 본질적인 결함으로 구축될 수 있다. 둘째, 주어진 노드 i와 주어진 시간 단위 t에 대해, DC(904)에 의해 수집된 상이한 데이터의 조각들이 노드 가용성에 대해 상이한 의견을 가질 수 있고 모듈 B(1604)가 이러한 상이한 의견들을 융합하도록 설계되었기 때문에, 다양한 노이즈 또는 바이어스로 인해 이력 노드 가용성을 추론할 때 에러가 존재할 수 있는 가능성이 매우 높다. 마지막으로, 모든 이력 가용성 데이터가 정확하고 또한 충분하다고 가정하더라도, 이것은, 대응하는 추정기 fi(t)(모듈 D(1608)에 의해 구축됨)가 미래시간 단위들에 대한 노드 가용성을 추정하기에 여전히 정확할 수 있음을 반드시 의미하지 않은데, 그 이유는 추정기를 구축하는데 사용된 알고리즘 또는 접근법의 성능에 크게 의존하기 때문이다.
따라서, 추정기 fi(t)를 이용하면, 추정된 노드 가용성 결과는 0과 1 사이의 10진수 값일 수 있는 신뢰도 값과 연관될 수 있다. 한편으로, 일부 추정된 결과들(예를 들어, 노드 CSE-1에 관한 가용성)은 매우 낮은 신뢰도 값을 가지며, DP(906) 내의 모듈 F(1612)는, CSE-1의 추정된 가용성의 신뢰도를 향상시키기 위해 DC(904)가 CSE-1과 관련된 더 많은 데이터를 수집하도록 암시할 것이다(다음 데이터 수집 전략에 그러한 요구를 나타냄으로써). 다른 한편으로, 모듈 F(1612)는 SP(908)로부터 피드백을 또한 수집할 수 있으며, 그 SP로부터 서비스 클라이언트들은 추정된 노드 가용성을 자신들의 목적을 위해 질의한다. 예를 들어, SP(908)는 CSE-2의 추정된 가용성이 향상될 필요가 있다고 보고할 수 있는데, 그 이유는 현재 많은 클라이언트가 낮은 신뢰도로 인해 이 정보를 활용할 수 없기 때문이다. 대안적으로, SP(908)는, 클라이언트가 이전 시간 간격에서 Device-1에 액세스하려고 시도했음을 모듈 F(1612)에 보고할 수 있지만(SP(908)에 의해 제공된 추정된 가용성이 Device-1이 이용 가능하다는 것을 보여주기 때문에), 동작은 결국 실패한다(즉, 추정된 가용성은 부정확하다). 전반적으로, 모듈 F(1612)는 데이터 수집 전략을 동적으로 조정할 것이며, 이는 이전 섹션에서 논의된 가이드라인으로서 DC(904)에 전달될 것이다.
모듈 G(1614)는 출력 생성 및 피드백 수집 모듈이다. 모듈 G(1614)는 모듈 F(1612)로부터의 추정된 결과들을 클라이언트가 이해할 수 있는 포맷으로 래핑(wrapping)할 것이다. 그 후, 이들 결과는 SP(908)로 전달될 것이다. 예를 들어, 시간 단위 10과 20 사이에서 AE1(1232의 ID를 가짐)의 추정된 가용성은 다음과 같은 포맷으로 기술될 수 있다.
Figure 112018084155826-pat00013
또한, 모듈 G(1612)는 앞서 언급한 바와 같이 SP(908)로부터 수집된 피드백 정보를 파싱할 수 있다.
DP(904)로부터 노드 가용성 추정 결과들을 수신한 후, SP(908)는 노드 가용성 추정 서비스와 같은 정보를 클라이언트들에 제공할 수 있다. 도 18은, 도 18에 도시된, SP(908)에서의 서비스 프로비저닝의 방법을 예시하는 흐름도이다.
도 18의 단계 1에서, 클라이언트가 자신의 필요에 따라 주어진 노드에 대한 가용성 정보를 알 필요가 있을 때, 클라이언트는, 그런 정보가 즉시 명확하지 않는 경우 도움을 위해 NAE(902)에 접촉할 것이다.
도 18의 단계 2에서, 클라이언트는 질의 요청을 NAE(902)에 송신한다. 통상적으로, 질의 요청 내의 메시지 요소들은 다음과 같은 정보(그러나 이에 국한되지 않음)를 포함할 수 있다:
- 관심 노드 ID: 노드의 식별자.
- 관심 시간 간격: 클라이언트가 관심있는 시간 기간.
- 신뢰도 요구 사항: 예를 들어, 추정된 가용성 정보에 대한 최소 수용 신뢰도(minimum accepted confidence).
도 18의 단계 3에서, 클라이언트로부터 요청을 수신한 후, NAE(902)는, 요청이 충족될 수 있는지를 알기 위해 자신의 리포지토리를 체크할 것이다. 요청은, 예를 들어 1) SP(908)가 관심 노드와 관련된 임의의 추정된 가용성 정보를 갖고 있지 않거나; 또는 2) 추정된 가용성의 신뢰도가 너무 낮아 클라이언트의 요구 사항을 충족하지 못하는 경우, 거부될 것이다.
이 예에서 대안적인 사용 예는, 단계 2 동안, 특정 노드의 가용성을 질의하는 대신에, 클라이언트가 노드 타입의 측면에서 자신의 요구만을 지정할 수 있다는 것이다. 즉, 해당 타입의 임의의 노드는 현재 사용할 수 있는 한 클라이언트를 서빙할 수 있다. 그 후, 단계 3에서, NAE(902)는 이 요청을 서빙하기 위해 특정한 이용 가능 노드를 선택하는 것을 담당할 것이다.
도 18의 단계 4에서, DC(904)는, 요청이 충족될 수 있는 경우 클라이언트에게 필요한 정보를 다시 송신하거나, 설명과 함께 거부 통지를 송신한다. 특히, 응답 메시지는 도 19에 도시된 바와 같은 구조를 가질 수 있고, 이러한 메시지의 실시예는 수학식 10에 표시된 예와 유사한 정보를 가질 수 있다.
상기 풀 기반 서비스 프로비저닝(pull-based service provisioning)에 덧붙여, 대안적으로, 푸시 기반 서비스 프로비저닝은, 클라이언트가 NAE(902)에 대한 주어진 관심 노드에 대해 가입을 확립할 수 있고 NAE(902)가 클라이언트에 대한 노드 가용성에 대해 임의의 업데이트를 주기적으로 보고할 것이라는 의미로 또한 설계될 수 있다.
도 18에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 18에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 18에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 18에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
서비스 계층에서 제안된 새로운 NAE(902) 서비스에 기초하여, 여러 부가가치 서비스는 NAE(902)에 의해 인에이블될 수 있다. 도 20은 노드 가용성 인식 세션 확립을 위한 절차를 예시하는 흐름도이다. NAE(902)가 서비스 계층에서 구현되면, 가용성 인식 세션 관리 서비스를 지원할 수 있으며, 구체적인 예가 도 20에 도시되어 관련 절차를 예시한다. 도 20에 예시된 바와 같이, CSE-1(2004) 상에서 실행 중인 AE-1(2002)가 원격 CSE-2(2008)(실제로는, 예를 들어 소프트웨어 충돌로 인해 사용할 수 없음) 상에서 실행 중인 다른 AE-2(2006)와 상호 작용하려고 할 때, 이는 세션 확립 요청을 이것의 로컬 CSE-1(2004)에 먼저 송신한다. 세션 확립 프로세스를 즉시 초기화하는 대신, CSE-1(2004)는 (NAE(902) 서비스를 구현하는) CSE-2(2008)에서 AE-2(2006)의 추정된 가용성을 질의함으로써 그러한 동작의 성공 확률을 먼저 평가한다. NAE(902)로부터, CSE-1(2004)는, AE-2(2006)가 이용 가능하지 않을 가능성이 크다고 통지받으며, 이에 기초하여 CSE-1(2004)는 진행하지 않기로 결정할 것이다. 결과적으로, AE-1의 요청은 그 로컬 CSE-1(2004)로부터 직접 거부될 것이다.
도 20에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 20에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 20에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 20에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 21은 지능형 스토어-및-전송 프리페칭을 위한 절차를 도시하는 흐름도이다. 서비스 계층에서 제안된 NAE(902) 서비스를 이용하여, 더 지능적인 스토어-및-전송 리소스 프리페칭을 지원할 수 있다. 관련 절차를 예시하기 위한 구체적인 예가 도 21에 도시된다. 실제로, 주어진 논리 노드 AE(2102)에 대해, NAE(902)는 그 가용성을 추정할 수 있을 뿐만 아니라, DC(904)로부터 수집된 데이터에 기초하여 그 활동 행위/패턴을 추정하는 것이 가능하다. 도 21에 도시된 바와 같이, CSE-1(2104)은 가까운 장래에 AE-1(2102)(CSE-1 상에서 실행 중임)의 추정된 활동이 무엇인지를 질의하여 MN-CSE(2106) 상에서 실행 중인 NAE(902)와 접촉한다. NAE(902)로부터 리턴된 추정된 결과를 이용하여, CSE(2104)는, AE-1(2102)가 아마도 시간 단위 t1 무렵에 원격 CSE-2(2106)로부터 Resource-A를 페치할 필요가 있음을 알게 된다. 이어서, CSE-1(2104)는 NAE(902)에게 추가로 질의하고, CSE-2(2106)가 아마도 시간 t1 무렵에 이용 가능하지 않을 것임을 알게 된다. 따라서, CSE-2(2106)의 비가용성 이벤트를 반응적으로 처리하는 대신, CSE-1(2104)에서의 캐싱 CSF는, 이것이 이용할 수 없게 되기 전에 CSE-2(2106)로부터 사전 대비적으로 Resource-A를 검색할 것이다. 결과적으로, 나중에 AE-1(2102)이 리소스 검색 요청을 CSE-1(2104)에 송신할 때, CSE-1(2104)은 AE-1의 요청을 충족시키기 위해 프리-페칭된 콘텐츠를 직접 사용할 수 있다. 이러한 의미에서, CSE-2(2106)가 현재 이용할 수 없더라도, Resource-A는 AE-1(2102)에 제공되는데, 즉 NAE(902)의 도움으로, CSE-2(2106)의 비가용성 문제는 AE-1(2102)에서 숨겨진다. 도 8과 관련하여 논의된 바와 같은 이전에 언급된 사용 사례를 재검토하기 위해 되돌아가면, 그러한 부가가치 서비스는 도 8의 문제를 해결하는데 사용될 수 있다(하나의 리소스 검색 동작(CSE-10 상의)의 실패는 (CSE-1 내지 CSE-9에서 리소스들을 검색하는 측면에서) 이전의 모든 노력을 무효화한다). 예를 들어, 프리페칭 동작은 CSE-10 상에서 리소스를 검색하기 위해 실행될 수 있어, 필요한 모든 리소스가 AE-1의 동작 요구 사항에 의해 요구되는 바와 같이 AE-1에 의해 성공적으로 검색될 수 있다. 대안적으로, 도 8의 문제에 대한 다른 해결책은, 이 섹션에서 논의된 캐싱 및 프리페칭 메커니즘에 의존하지 않고도, NAE(902)만을 이용함으로써 MN-CSE가 Device-1 내지 Device-10에 관한 가용성 정보를 AE-1로 리턴하고 AE-1이 10개의 디바이스 상에서 모든 리소스를 검색할 수 있도록 적절한 스케줄을 결정하게 하는 것이다.
도 21에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 21에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 21에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 21에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 22는 사전 대비적 노드 트리거링(proactive Node Triggering)을 위한 예시적인 절차를 도시하는 흐름도이다. 도 22에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 22에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 22에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 22에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
서비스 계층에서 제안된 NAE 서비스(902)를 이용하여, 사전 대비적 노드 트리거링 서비스가 인에이블될 수 있고, 구체적인 예가 도 22에 도시되어 관련 절차를 예시할 수 있다. 도 22에 도시된 바와 같이, 처음 5개의 단계는 도 21에 도시된 것과 유사하다. NAE(902)로부터 CSE-1은, AE-1의 애플리케이션 요구 사항에 따라 빈번하게(그러나 고정된 작업 스케줄의 측면에서는 주기적이지 않음) 감지 커맨드들을 특정 작업들을 위한 Device-1(2202)에 푸시할 필요가 있으며 다음 푸싱 시간이 차후 시간 t에 있다는 것을 알게 되는 상황이 있다. 그러나 NEA는 Device-1(2202)이 그 시간 무렵에 아마도 이용 가능하지 않음을 나타낸다. 따라서, (잠재적인 지연을 야기할 수 있는) 시간 t에서 AE-1의 푸싱 요청을 수신할 때 Device-1(2202)을 반응적으로 트리거링하는 대신에, CSE-1(2204)은, 예를 들어 oneM2M 서비스 계층 내의 네트워크 서비스 노출(Network Service Exposure), 서비스 실행 및 트리거링(Service Execution and Triggering)(NSSE) CSF를 이용함으로써, 적절한 시간 단위(t보다 조금 더 이른 t'로 불림)에서 트리거 메시지를 기본 네트워크들(2208)에 사전 대비적으로 스케줄링하기로 결정할 수 있다. 마지막으로, 기본 네트워크들은 Device-1(2202)를 기상시킬 것이다. 이러한 트리거에 의해, Device-1(2202)은 시간 t에서 즉시 이용 가능할 수 있고, 중요한 이점은 Device-1(2202)이 불필요한 에너지 소모를 초래하는 너무 일찍 기상할 필요가 없다는 것이다. 결과적으로, AE-1(2206)은 펌웨어를 성공적으로 Device-1(2202)에 푸시할 뿐만 아니라 에너지 효율성 목적도 달성된다.
클라이언트는 전체적으로 또는 NAE(902)에 의해 제공된 추정된 노드 가용성에 기초하여 그들의 동작 결정을 내릴 필요가 없다. 노드 가용성 추정은 신뢰도가 낮거나 언젠가 사용 준비가 되어 있지 않은 정보가 존재한다는 측면에서 충분히 정확하지 않을 수 있다. 이러한 경우에 실제 지능적인 결정을 내리고 NAE(902)의 가능한 추정 부정확성을 치유하기 위해, 노드 가용성을 전체적으로 평가하기 위한, 다음을 포함하는 더 많은 정보가 고려될 수 있다:
1) 하위 계층들로부터의 크로스 계층 정보 보고들은 또한, 대부분의 시간에 이들이 수면 상태에 머물러 있다는 의미에서 매우 낮은 듀티 사이클을 갖는 이러한 디바이스들에 특히 유용할 수 있다. 그러한 경우, NAE(902)에 의해 제공되는 이러한 노드들의 추정된 가용성은 항상 이용 가능하지 않을 수 있다(사실은 이용 가능했었다). 그러나 MAC/PHY 계층에서, 그들은 (예를 들어, 스케줄링된 채널 폴링 기술을 이용하여) 다른 피어들과의 통신에 참여하기 위해 매우 짧은 시간 슬롯에서 이용 가능하게 될 수 있다.
2) 컨텍스트 정보도 일부 경우에 유용하다. 예를 들어, 클라이언트가 하나의 홉 범위 내에만 있는 노드에 접촉해야 할 필요가 있고 NAE(902)가 그 노드를 이용할 수 없다고 추정했다면(그러나 매우 낮은 신뢰도를 가짐), 클라이언트는, 네트워크 트래픽이 가벼운 경우(네트워크 트래픽 상태를 악화시키지 않을 수 있음) 여전히 노드에 접촉을 시도할 수 있다(많은 오버 헤드를 유도하지 않을 수 있음).
3) 최신 런타임 정보. NAE(902)가 데이터를 수집한 후 노드 가용성을 추정하는 데는 항상 시간이 걸리기 때문에, 어느 정도 시간 지연 효과가 있을 수 있다. 따라서, 클라이언트가 최신 증거를 가지고 있다면(예를 들어, 표적 노드의 방송 패킷을 방금 엿들었다면), 표적 노드가 아마도 이용 가능하다는 결론을 내리는 것이 충분히 좋을 수 있다.
전반적으로, 노드 가용성을 결정할 때, NAE(902)에 의해 제공된 추정된 결과들뿐만 아니라 전술한 바와 같은 다른 종류의 정보도 고려될 필요가 있음을 알 수 있다. 상이한 시나리오 및 애플리케이션에 따라, 클라이언트는 상기 정보(예를 들어, 상이한 우선순위들에서, 상이한 가중치들 등을 가짐)를 이용하는 상이한 전략들을 가질 것이다.
도 23은 다수의 DC(2302 및 2304), DP(2306 및 2308) 및 SP(2310 및 2312) 간의 상호 작용을 도시하는 도면이다.
도 23을 참조하면, 임의의 3개의 컴포넌트(하나의 DC, 하나의 DP 및 하나의 SP의 관점에서)는, 이들 모두가 함께 협력하여 이전 섹션에서 논의된 바와 같이 노드 가용성 추정 함수를 달성하는 경우 NAE로 간주될 수 있다는 점에서, 각각의 컴포넌트가 다수의 엔티티와 상호 작용할 수 있음을 알 수 있다. 예를 들어, DC(2202)는 다수의 DP(2306 및 2308)에 대한 실시간 데이터를 수집할 수 있는 반면, DP(2306)는 추정 결과들을 다수의 SP(2310 및 2312)에 제공할 수 있다. 이들 상호 작용(즉, DC와 DP, DP와 SP)에 대한 관련 절차들 및 메시지 구조들은 이전 섹션에서 제안된 것들과 동일하다. 이 섹션은 주로 2개의 DP(2306 및 2308)와 2개의 SP(2310 및 2312) 사이의 상호 작용들을 고려할 것이다.
도 23에 도시된 기능성은 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능한 명령어들)의 형태로 구현될 수 있음이 이해되어야 한다.
도 24는 데이터 수집 프로세스에 대해 협력하는 2개의 DP(2306 및 2308)를 예시하는 흐름도이다. 도 24에 도시된 바와 같이, DP-1(2306) 및 DP-2(2308) 둘 다가 이러한 데이터 수집 전략들을 DC들(2302 및 2304)에 직접 송신하는 대신에 새로운 데이터 수집 전략을 가질 때, 2개의 DP(2306 및 2308)는 먼저 이들의 데이터 수집 전략을 교환하고 협상 프로세스를 수행한다. 이러한 협상 프로세스의 잠재적 이점은 다음과 같다: 1) 2개의 DP(2302 및 2309)는 협상 프로세스 동안 검출되고 병합될 수 있는 동일한 데이터 수집 작업을 가질 수 있다; 2) 상이한 DP들은 이용 가능한 컴퓨팅 리소스들의 양이 상이할 수 있으므로, 노드 가용성 추정 작업은 이들 간에 균형을 이룰 수 있다; 3) 유사하게, 상이한 DC들이 데이터 수집을 위해 상이한 작업 부하를 가질 수 있기 때문에, DP들은 이들의 데이터 수집 전략을 조정하여 상이한 DC들에 대한 작업 부하들의 균형을 이룰 수도 있다; 4) 2개의 데이터 수집 전략이 동일한 관심 노드에 대해 상이한 타입의 데이터를 수집하려는 경우, 그런 데이터 수집 작업들을 함께 결합하고 처리를 위해 모든 데이터를 하나의 DP(2306)로 송신하는 것은 추정 결과의 정확성을 크게 향상시킬 수 있다. 마지막으로, 단계 5에 예시된 협상 프로세스에 기초하여, DP-1(2306) 및 DP-2(2308)는 이들의 조정된 데이터 수집 전략을 DC-1(2302) 및 DC-2(2304)(단지 일례임)에 각각 송신할 것이다.
도 24에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 24에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 24에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 24에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 25는 서비스 프로비저닝 프로세스에 대해 협력하는 2개의 DP(2306 및 2308), 및 서로 간에 정보를 공유하는 SP들(2310 및 2312)을 예시하는 흐름도이다. 도 25에 도시된 바와 같이, DP-1(2306) 및 DP-2(2308)가 새로운 추정 결과들을 가질 때, 결과들을 SP들(2310 및 2312)에 직접 출력하는 대신에, 2개의 DP(2306 및 2308)는 먼저 협상 프로세스를 실행하고, 그 동안 이들은, 예를 들어 상이한 SP들 또는 다른 요인들에서 로드 밸런싱 문제들을 고려함으로써 어느 추정 결과들이 어느 SP들(2310 및 2312)에 저장될 것인지를 결정할 것이다. 따라서, DP-1(2306) 및 DP-2(2308)는 협상 프로세스에 기초하여 이들의 결과들을 대응하는 SP들(도면에 도시된 바와 같이, 예를 들어 SP-1(2310) 및 SP-2(2312))에 출력할 것이다. 정보 공유 측면에서 상이한 SP들(2310 및 2312) 간의 협력이 또한 존재하는데, 이는 상이한 SP들이 노드 가용성 정보의 상이한 조각들을 저장할 수 있기 때문이다. 결과적으로, 클라이언트가 특정 노드에 대한 가용성 질의를 SP-2(2312)에 송신할 때, SP-2(2312)는 그러한 정보를 갖지 않지만 SP-1(2310)은 가질 수 있는 가능성이 있다. 그 후, SP-2(2312)는 이 요청을 SP-1(2310)로 전송할 것이고, 결국 SP-1(2310)은 클라이언트가 필요로 하는 가용성 정보를, 이 정보를 공유함으로써 SP-2(2312)에 제공할 수 있다.
도 25에 예시된 단계들을 수행하는 엔티티들은, 도 32c 또는 도 32d에 도시된 것들과 같은 네트워크 노드 또는 컴퓨터 시스템의 프로세서 상에서 실행되고 그 메모리에 저장되는 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있는 논리 엔티티들임을 이해해야 한다. 즉, 도 25에 예시된 방법(들)은 도 32c 또는 도 32d에 도시된 노드 또는 컴퓨터 시스템(그 노드의 프로세서에 의해 실행될 때, 컴퓨터 실행 가능 명령어들은 도 25에 예시된 단계들을 수행함)과 같은 네트워크 노드의 메모리에 저장된 소프트웨어(즉, 컴퓨터 실행 가능 명령어들)의 형태로 구현될 수 있다. 도 25에 예시된 임의의 전송 및 수신 단계들은 노드의 프로세서의 제어하에 있는 노드의 통신 회로 및 그것이 실행하는 컴퓨터 실행 가능 명령어들(예를 들어, 소프트웨어)에 의해 수행될 수 있음을 또한 이해해야 한다.
도 26a-26b는 NAE 서비스를 지원하기 위해 기존의 oneM2M 기능적 아키텍처를 향상시키기 위한 예시적인 실시예를 도시하는 도면이다. 도 26a-26b에 도시된 바와 같이, NAE는 CSE에서의 새로운 CSF일 수 있다. NAE를 배치하기 위한 2가지 옵션이 설명된다.
한편으로, NAE(2602)가 중앙 집중 방식으로 배치되는 경우(즉, 도 26a에 도시된 바와 같이, DC(2604), DP(2606) 및 SP(2608)의 관점에서 NAE(2602)의 3가지 컴포넌트 모두가 CSE(2610) 내의 단일 노드에서 구현되는 경우), CSE(2610)는 MN-CSE 또는 IN-CSE 중 어느 하나일 수 있다. 특히, NAE(2602)의 DP(2606) 컴포넌트에서 실행되는 노드 가용성을 추정하는데 필요한 컴퓨팅 리소스를 고려하면, NAE(2602)를 IN-CSE 내에 두는 것이 바람직한 선택일 수 있다. NAE(2602)의 인트라 및 인터 통신들(intra and inter communications)은 다음과 같이 설명된다:
NAE(CSE-1에 의해 제공됨)가 다른 CSE(2612)(CSE-2로 불림)에 의해 제공되는 다른 CSF와 통신할 필요가 있을 때, mcc 인터페이스를 통과할 것이다. 예를 들어, 다음과 같은 사례들이 있을 수 있다:
사례-1: 도 11과 관련하여 논의된 바와 같이 데이터 수집 관계 및 정책 수립을 위한 절차와 관련이 있는 경우, 수반된 객체들은 DC 및 데이터 소스이고, 이들 간에 교환될 메시지의 구조는 도 12에 도시된다.
사례-2: 도 13의 데이터 수집 및 보고를 위한 절차와 관련이 있는 경우, 수반된 객체들은 또한 DC 및 데이터 소스이며, 이들 사이에서 교환될 메시지의 구조는 도 14에 도시된다.
사례-3: 도 15에서 논의된 바와 같은 데이터 수집 관계 및 정책 업데이팅을 위한 절차와 관련이 있는 경우, 수반된 객체들은 DC 및 데이터 소스이고, 이들 사이에 교환될 메시지의 구조는, 도 15의 단계 4에서 논의된 바와 같은 dataCollectionRelationshipID과 더불어 도 12에 도시된다.
사례-4: 섹션 5.4의 도 18에 논의된 바와 같은 서비스 프로비저닝을 위한 절차와 관련이 있는 경우, 수반된 객체들은 SP와 CSE 클라이언트이며, 이들 사이에서 교환될 메시지의 구조는 도 18의 단계 2(질의 메시지와 관련됨) 및 도 19에서 정의된 구조(응답 메시지와 관련됨)에서 논의된다.
NAE(2606)가 동일한 CSE(2610)에 의해 제공되는 CSF와 통신할 필요가 있거나, NAE(2602) 내의 3개의 컴포넌트가 서로 상호 작용할 필요가 있을 때, 통신은 mff 인터페이스를 통과할 것이며, mff 인터페이스는 동일한 서비스 계층 내의 상이한 서비스 기능들 간의 통신을 지정한다.
NAE(2602) 서비스(CSE-1(2610)에 의해 제공됨)가 동일한 CSE-1(2610) 상에 있는 AE에 의해 질의될 때, 이것은 mac 인터페이스를 통과할 것이다. 이것은 주로 도 18과 관련하여 논의된 서비스 프로비저닝을 위한 절차와 관련되지만 수반된 객체들은 SP 및 AE 클라이언트(위에서 언급한 사례-4에서의 CSE 대신)이다. 이들 사이에서 교환될 메시지의 구조들은 사례-4에 도시된 것들과 동일하다.
한편, NAE는, 3개의 필수 컴포넌트(DC, DP 및 SP)가 상이한 노드 내에 상주할 수 있고 또한 섹션 5.6에 논의된 바와 같이 다수의 DC, DP 및 SP 사이에서 상호 작용을 가질 수 있다는 점에서, (도 26b에 도시된 바와 같이) 분산 방식으로 배치될 수 있다. 예를 들어, DC는 최종 노드들을 포함하는 모든 노드 상에 있을 수 있는 반면에, DP 및 SP는 MN-CSE 및 In-CSE 상에 배치될 수 있다(그 이유는 앞에서 설명한 것과 유사하다). NAE의 인트라 및 인터 통신들은 다음과 같이 설명된다:
DC(2620)(CSE-1(2622)에 배치됨)가 상이한 CSE(CSE-2(2624)로 불림)에 의해 제공되는 다른 CSF(NAE의 DC에서 데이터 수집을 위한)와 통신할 필요가 있을 때, 그것은 mcc 인터페이스를 통과할 것이다. 앞에서 설명한 4가지 사례(사례-1 내지 사례-4)도 관련 개체들 및 교환될 메시지의 구조들과 관련하여 적용된다.
DC(2620)(CSE-1(2622)에 배치됨)가 동일한 CSE에 의해 제공되는 다른 CSF와 통신할 필요가 있을 때, 그것은 mff 인터페이스를 통과할 것이다. 앞에서 설명한 4가지 사례(사례-1 내지 사례-4)는 mff 인터페이스에 계속 적용된다.
동일한 CSE-1(2622) 상에 있는 AE(2628)에 의해 SP(2626)(CSE-1(2622)에 의해 배치됨)이 질의될 때, 그것은 mac 인터페이스를 통과할 것이다. 이는 주로 도 18과 관련하여 논의된 서비스 프로비저닝을 위한 절차와 관련이 있으며, 수반된 객체들은 SP(2626) 및 AE(2628) 클라이언트이다. 이들 사이에서 교환될 메시지의 구조들은 사례-4에서 도시된 것과 동일하다.
다른 CSE-2(2624) 상에 있는 AE(2630)에 의해 SP(2626)(CSE-1(2632)에 의해 배치됨)이 질의될 때, 그것은 mcc 및 mac 인터페이스 모두를 통과할 것이다. 다시 말하지만, 이는 서비스 프로비저닝과 관련이 있으며, 이들 사이에서 교환될 메시지의 구조들은 사례 -4에 도시된 것과 동일하다.
NAE의 임의의 2개의 컴포넌트(즉, DC, DP 및 SP) 간의 통신의 경우, 이들은, 이들이 동일한 CSE에 배치되면 mff 인터페이스를 통과할 것이고, 그렇지 않으면 mcc 인터페이스를 통과할 것이다. 예를 들어, DC와 DP 간의 상호 작용의 경우, 이들 사이의 메시지 구조들은 도 12에 도시된 것(DC가 수집된 데이터를 DP에 입력할 때 사용되는 것), 및 DP가 데이터 수집 전략을 DC에 송신할 때 사용되는 메시지 요소들과 유사할 수 있다.
도 26a-26b에 도시된 기능성은 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능한 명령어들)의 형태로 구현될 수 있음이 이해되어야 한다.
도 27은 oneM2M 서비스 컴포넌트 아키텍처에서 NAE(2702)의 구현 아키텍처를 도시하는 도면이다. 도면에 도시된 바와 같이, NAE(2702)는 'Msc' 기준점(2704)을 통해 다른 컴포넌트들과 상호 작용될 수 있는, '노드 가용성 추정 컴포넌트'(2702)라 불리는 개별 서비스 컴포넌트를 삽입함으로써 구현될 수 있다.
도 27에 도시된 기능성은 아래에 설명되는 도 32c 또는 32d에 도시된 것 중 하나와 같이, M2M 네트워크의 노드(예를 들어, 서버, 게이트웨이, 디바이스, 또는 다른 컴퓨터 시스템)의 메모리에 저장되고 그 노드의 프로세서 상에서 실행되는 소프트웨어(즉, 컴퓨터 실행 가능한 명령어들)의 형태로 구현될 수 있음이 이해되어야 한다.
도 28은 oneM2M 서비스 계층에서 NAE(2702)의 예시적인 데이터 수집, 처리 및 노드 가용성 서비스 프로비저닝 실시예들을 도시하는 도면이다. DC는 입력 소스들로부터 실시간 데이터를 수집한다. oneM2M 도메인의 문맥에서, 이들 엔티티는 기존 CSF들일 수 있다. 특히, 많은 기존 CSF들이 리소스들로서 노출되기 때문에, 도 28에서는 최신 oneM2M 기능적 아키텍처 사양에 따라 NAE가 어느 특정 리소스들로부터 실시간 데이터를 수집할 수 있는지를 도시한다. 특히, 도 28은 oneM2M 서비스 계층에서 기존 CSF들로부터 데이터를 수집하는 방법을 예시함으로써 데이터 보고 메시지(도 14에 정의된 바와 같은)의 구체적인 실시예이다. 예를 들어, NAE가 (oneM2M 서비스 계층에서 <delivery> 리소스로서 표현되는) CMDH CSF로부터 데이터를 수집할 필요가 있을 때, 이것은 CSE 또는 AE와 관한 데이터를 수집할 수 있다. 관심 데이터와 관련하여, "소스" 및 "타겟"은 누가 이러한 <delivery> 리소스와 관련되는지를 나타내고(분명히, 그들 중 하나는 관심 노드이어야 함), "수명(lifespan)"은 전달 기간(duration of the delivery)을 나타내고, "deliveryMetaData"은 전달 상태를 나타낸다. 유사하게, NAE는 <node> 리소스로부터 데이터를 수집할 수 있다. 대응하는 관심 노드는 물리적 노드일 수 있으며, 관심 데이터는 노드의 "메모리 사용", "저장", "전력" 및 "수면 스케줄"(NAE가 데이터를 수집할 수 있는 리소스들의 다른 타입인, <schedule> 리소스로 기술됨)을 포함할 수 있다.
도 29는 oneM2M 서비스 계층에서의 예시적인 데이터 처리 실시예를 나타내는 도면이다. DP는 DC로부터의 수집된 데이터에 기초하여 노드 가용성을 추정할 수 있다. 도 29는, 1) 3개의 상이한 데이터 조각으로부터 노드 가용성 정보를 추론하는 방법(DP의 모듈 A에서 행해짐), 및 2) 3개의 데이터로부터 추출된 정보를 융합하는 방법(DP의 모듈 B에서 행해짐)에 관한 실시예를 도시한다. 도 29에 도시된 바와 같이, DC는 상이한 소스들로부터 3개의 데이터를 수신한다. 예를 들어, Data-1은 AE-1(즉, 관심 노드)에 관한 것이며 서비스 통계 수집 레코드로부터 수집된다. Data-2는 CSE-1(즉, 관심 노드)에 관한 것이고 세션 관리 기능으로부터 수집된다.
관심 노드 i(이 예에서는 AE-1 또는 CSE-1일 수 있음) 및 그것의 관련된 각각의 데이터 j(즉, AE-1에 대한 Data-1, CSE-1에 대한 Data-2 및 Data-3)에서, 모듈 A는 추론 프로세스를 실행할 것이고, 각 요소 데이터는 변수 yi,j(t)에 대해 "0" 또는 "1" 값으로 추론되고, 이 변수는 데이터 j가 추출된 정보만을 기초로 하는, 시간 단위 t에서의 노드 i의 가용성을 나타내는 부울 변수이다. 추론 결과들은 도 29의 세그먼트들 I, Ⅱ 및 Ⅲ에 도시된다. 예를 들어, Data-1에 기초하여, t=1과 t=10 사이의 시간 단위에서 yAE-1,Data-1(t)=1이 추론된다. Data-2에 기초하여 t=7과 t=20 사이의 시간 단위에서 yCSE-1,Data-2(t)=1이 추론된다. Data-3에 기초하여, 시간 단위 t=8에 대해서만 yCSE-1,Data-3(t)=1이 추론된다. 특히, yAE-1,Data-1(t)=1로부터, 모듈 A는 t=1과 t=10 사이의 시간 단위에서 yCSE-1,Data-1(t)=1을 추가로 추론할 것이다. 이것은, 노드 i에 직접 관련된 주어진 정보가 또한 간접적으로 다른 관련 노드들의 가용성을 반영할 수 있다는 의미에서, 전술한 바와 같은 데이터 재사용 프로세스이다. 예를 들어, AE-1이 [t=1, t=10] 동안 이용 가능하고 AE-1이 실제로 CSE-1에 의해 유지되므로, CSE-1도 [t=1, t=10] 동안 이용 가능하다고(도 29의 세그먼트 IV에 도시됨) 또한 추론될 수 있다.
다음으로, 당분간 초점은 CSE-1에만 집중되고, 집중된 시간 단위는 t=8에 대해서만이다. 시간 단위 t=8에서 CSE-1의 가용성과 관련된 3가지 추론 결과가 있기 때문에, 이들 3가지 추론 결과는 DP의 모듈 B에서 융합될 것이고(즉, 도 29의 세그먼트 V), 융합된 노드 가용성 결과(즉, yi(t))는 세그먼트 VI에 도시된다.
도 30a 및 도 30b는 실시예들에서 사용될 수 있는 예시적인 리소스들을 도시하는 도면들이다. 이들 리소스는 SP에서 프로비저닝 노드 가용성 추정 서비스로 판독될 수 있고, 도 30a는 리소스 <estimatedAvailability>(3002)를 도시하고; 도 30b는 리소스 <estimatedAvailabilityElement>(3004)를 도시한다. 일반적으로, <estimatedAvailability>(3002)는 리소스 <CSEBase> 아래에 있을 수 있다. 한편, <estimatedAvailability>(3002) 자체는 다수의 자식 <estimatedAvailabilityElement>(3004) 리소스를 포함할 수 있다. 특히, 각각의 <estimatedAvailabilityElement>(3004) 리소스는 하나의 추정된 노드 가용성 결과를 표현하기 위한 것이고, 이 리소스의 속성들은 수학식 10에 리스트된 데이터 요소들에 대응한다. 대안적으로, 추정된 노드 가용성 결과는 또한 새로운 속성, 예를 들어, 신뢰도 등을 추가함으로써 기존 <schedule> 리소스에 저장될 수 있다.
그래픽 사용자 인터페이스(Graphical User Interfaces)(GUI)들과 같은 인터페이스들은 사용자가 서비스 계층에서 노드 가용성 추정 서비스와 관련된 기능성들을 제어 및/또는 구성하는 것을 돕기 위해 사용될 수 있다. 도 31은 인터페이스(3102)를 도시하는 도면이다. 인터페이스(3102)는 아래에 설명된 도 32c-32d에 도시된 것들과 같은 디스플레이들을 이용하여 생성될 수 있음을 이해해야 한다.
DP 내부의 일반적인 아키텍처에서 논의된 바와 같이, 도 16에 도시된 바와 같은 모듈 D는, 노드 가용성 추정기(즉, 이전 섹션에서 논의된 바와 같이 다수의 이력 가용성 정보(즉, Li(t, k))가 주어진다는 의미에서 함수 fi(t))를 구축하는데 사용된다. 모듈 D는 함수 fi(t)의 이러한 파라미터들(즉, an, an-1, ... a1, a0)의 값들을 결정하는 것이다.
임의의 이용 가능한 솔루션이 추정기를 구축하기 위한 플러그-인으로서 사용될 수 있음에 주목할 필요가 있다(다시 말해서, 본 개시내용은 모듈 D를 구현하기 위한 임의의 특정 접근법으로 제한되지 않는다). 따라서, 임의의 플러그-인 솔루션의 경우, 사용자들은 추정기를 구축하려고 시작하기 전에 일부 구성을 수행해야 할 필요가 있을 수 있다. 그러므로, 예를 들어 어떤 기본 함수 fi(t)를 사용할지, 함수 fi(t)의 파라미터들(즉, an, an-1, ... a1, a0)의 초기 값들을 어떻게 설정하는지와 같은, 사용자가 구성하는 편리한 방식을 제공하기 위해, 그래픽 사용자 인터페이스(GUI)의 관점에서 사용자 제어 패널이 제공될 수 있다. 도 31은 요구들에 기초하여 쉽게 확장될 수 있는, 파라미터들의 초기 값들뿐만 아니라 사용될 기본 함수 fi(t)를 사용자가 선택할 수 있도록 하는 예시적인 GUI(3102)를 도시한다.
예시적인 M2M/IoT/WoT 통신 시스템
도 32a는 하나 이상의 개시된 실시예가 구현될 수 있는, 머신-투-머신(M2M), 사물 인터넷(IoT) 또는 사물 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술들은 IoT/WoT를 위한 블록들의 구축을 제공하며, 임의의 M2M 디바이스, M2M 게이트웨이, M2M 서버 또는 M2M 서비스 플랫폼은 IoT/WoT의 컴포넌트 또는 노드는 물론 IoT/WoT 서비스 계층 등이 될 수 있다. 통신 시스템(10)은 개시된 실시예들의 기능성을 구현하는데 사용될 수 있고, 그래픽 사용자 인터페이스(3102)를 생성하기 위한 논리 엔티티들뿐만 아니라, 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 기능성 및 논리 엔티티들을 포함할 수 있다.
도 32a에 도시된 바와 같이, 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), 위성 네트워크, 홈 네트워크, 또는 엔터프라이즈 네트워크와 같은 다른 네트워크들을 포함할 수 있다.
도 32a에 도시된 바와 같이, 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 애플리케이션(20)으로부터 M2M 서비스 계층(22)을 통해 송수신될 수 있다. M2M 단말 디바이스들(18) 및 게이트웨이들(14)은, 예를 들어 셀룰러, WLAN, WPAN(예를 들어, 지그비(Zigbee), 6LoWPAN, 블루투스(Bluetooth)), 직접 무선 링크, 및 유선을 포함하는 다양한 네트워크들을 통해 통신할 수 있다.
예시적인 M2M 단말 디바이스들(18)은 태블릿들, 스마트폰들, 의료 디바이스들, 온도 및 날씨 모니터들, 커넥티드 카들, 스마트 미터들, 게임 콘솔들, 개인용 정보 단말기들, 건강 및 피트니스 모니터들, 라이트들, 온도 조절기들, 어플라이언스들, 차고 도어들 및 다른 액추에이터-기반 디바이스들, 보안 디바이스들 및 스마트 아울렛들을 포함하지만, 이에 한정되지는 않는다.
도 32b를 참조하면, 필드 도메인에서의 예시된 M2M 서비스 계층(22)은 M2M 애플리케이션(20), M2M 게이트웨이 디바이스들(14), M2M 단말 디바이스들(18), 및 통신 네트워크(12)에 대한 서비스들을 제공한다. 통신 네트워크(12)는 개시된 실시예의 기능성을 구현하는데 사용될 수 있고, 그래픽 사용자 인터페이스(3102)를 생성하기 위해 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 기능성 및 논리 엔티티들을 포함할 수 있다. M2M 서비스 계층(22)은, 예를 들어 후술되는 도 32c 및 도 32d에 예시된 디바이스들을 포함하는, 하나 이상의 서버, 컴퓨터, 디바이스, 가상 머신(예를 들어, 클라우드/스토리지 팜 등) 또는 그와 유사한 것에 의해 구현될 수 있다. 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').
또한, 도 32b를 참조하면, M2M 서비스 계층들(22 및 22')은, 다양한 애플리케이션들 및 버티컬들(verticals)이 레버리지화할 수 있는 서비스 전달 능력들의 코어 세트를 제공한다. 이들 서비스 능력은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호 작용하고 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 과금, 서비스/디바이스 발견 등과 같은 기능들을 수행할 수 있게 한다. 본질적으로, 이들 서비스 능력은 이들 기능성을 구현하는 애플리케이션들의 부담을 덜어줌으로써 애플리케이션 개발을 간소화하고 비용 및 출시 시간을 단축할 수 있다. 서비스 계층들(22, 22')은 또한, 서비스 계층들(22, 22')이 제공하는 서비스들과 관련하여 M2M 애플리케이션들(20, 20')이 다양한 네트워크(12, 12')를 통해 통신 가능하도록 한다.
본 출원의 방법들은 서비스 계층(22 및 22')의 일부로서 구현될 수 있다. 서비스 계층(22 및 22')은 애플리케이션 프로그래밍 인터페이스들(Application Programming Interfaces)(APIs) 및 기본 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층이다. ETSI M2M 및 oneM2M 양쪽 모두는 본 출원의 접속 방법들을 포함할 수 있는 서비스 계층을 이용한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)라고 지칭된다. SCL은 M2M 디바이스(여기서, 그것은 디바이스 SCL(DSCL)이라고 지칭된다), 게이트웨이(여기서 그것은 게이트웨이 SCL(GSCL)이라고 지칭된다), 및/또는 네트워크 노드(여기서 그것은 네트워크 SCL(NSCL)이라고 지칭된다) 내에 구현될 수 있다. oneM2M 서비스 계층은 한 세트의 공통 서비스 기능들(Common Service Functions)(CSFs)(즉, 서비스 능력들)을 지원한다. CSF들 중의 하나 이상의 특정 타입들의 세트의 인스턴스화(instantiation)는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라구조 노드, 미들 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(Common Services Entity)(CSE)로서 지칭될 수 있다. 또한, 본 출원의 접속 방법들은, 본 출원의 접속 방법들과 같은 서비스들에 액세스하기 위해 서비스 지향 아키텍처(Service Oriented Architecture)(SOA) 및/또는 리소스 지향 아키텍처(resource-oriented architecture)(ROA)를 이용하는 M2M 네트워크의 일부로서 구현될 수 있다.
일부 실시예에서, M2M 애플리케이션들(20 및 20')은 개시된 시스템들 및 방법들과 함께 이용될 수 있다. M2M 애플리케이션들(20 및 20')은 UE 또는 게이트웨이와 상호 작용하는 애플리케이션들을 포함할 수 있고, 또한 다른 개시된 시스템들 및 방법들과 함께 이용될 수 있다.
일 실시예에서, 그래픽 사용자 인터페이스(3102)를 생성하기 위한 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 논리 엔티티들은 도 32b에 도시된 바와 같이, M2M 서버, M2M 게이트웨이 또는 M2M 디바이스와 같은 M2M 노드에 의해 호스팅된 M2M 서비스 계층 인스턴스 내에 호스팅될 수 있다. 예를 들어, 그래픽 사용자 인터페이스(3102)를 생성하기 위한 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 논리 엔티티들은 M2M 서비스 계층 인스턴스 내에서 또는 기존 서비스 능력 내의 서브 기능으로서 개별 서비스 능력을 포함할 수 있다.
M2M 애플리케이션들(20 및 20')은, 예를 들어 제한 없이, 수송, 건강 및 건강관리, 접속된 홈, 에너지 관리, 자산 추적, 및 보안과 감시 등과 같은 다양한 산업에서의 애플리케이션들을 포함할 수 있다. 앞서 언급한 바와 같이, 시스템의 디바이스들, 게이트웨이들, 서버들 및 다른 노드들에 걸쳐 실행되는 M2M 서비스 계층은, 예를 들어 데이터 수집, 디바이스 관리, 보안, 과금, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능들을 지원하고, 이러한 기능들을 서비스들로서 M2M 애플리케이션들(20, 20')에 제공한다.
일반적으로, 서비스 계층들(22 및 22')은 애플리케이션 프로그래밍 인터페이스(API)들 및 기본 네트워킹 인터페이스들의 세트를 통해 부가가치 서비스 능력들을 지원하는 소프트웨어 미들웨어 계층을 정의한다. ETSI M2M과 oneM2M 아키텍처들 양쪽 모두는 서비스 계층을 정의한다. ETSI M2M의 서비스 계층은 SCL(Service Capability Layer)라고 지칭된다. SCL은 ETSI M2M 아키텍처의 다양한 상이한 노드들에서 구현될 수 있다. 예를 들어, 서비스 계층의 인스턴스는 M2M 디바이스(여기서 이것은 DSCL(device SCL)로서 지칭됨), 게이트웨이(여기서 이것은 GSCL(gateway SCL)로서 지칭됨) 및/또는 네트워크 노드(여기서 이것은 NSCL(network SCL)로서 지칭됨) 내에서 구현될 수 있다. oneM2M 서비스 계층은 한 세트의 공통 서비스 기능(CSF)(즉, 서비스 능력)들을 지원한다. CSF들의 하나 이상의 특정 타입들의 세트의 인스턴스화는 상이한 타입들의 네트워크 노드들(예를 들어, 인프라구조 노드, 미들 노드, 애플리케이션 특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(CSE)로서 지칭된다. 3세대 파트너쉽 프로젝트(Third Generation Partnership Project)(3GPP)는 또한 머신 타입 통신(machine-type communication)(MTC)들에 대한 아키텍처를 정의했다. 그 아키텍처에서, 서비스 계층, 및 이것이 제공하는 서비스 능력들은 서비스 능력 서버(Service Capability Server)(SCS)의 일부로서 구현된다. ETSI M2M 아키텍처의 DSCL, GSCL 또는 NSCL에서, 3GPP MTC 아키텍처의 서비스 기능 서버(SCS)에서, oneM2M 아키텍처의 CSF 또는 CSE에서, 또는 네트워크의 일부 다른 노드에서 구현되든 간에, 서비스 계층의 인스턴스는, 서버들, 컴퓨터들 및 다른 컴퓨팅 디바이스들 또는 노드들을 포함하는, 네트워크 내의 하나 이상의 독립형 노드들 상에서 실행하는 논리 엔티티(예를 들어, 소프트웨어, 컴퓨터 실행가능 명령어들 등)로서, 또는 하나 이상의 기존의 노드들의 일부로서 구현될 수 있다. 예로서, 서비스 계층 또는 그의 컴포넌트의 인스턴스는 아래 설명되는 도 32c 또는 도 32d에 예시되는 일반적인 아키텍처를 가지는 네트워크 노드(예를 들어, 서버, 컴퓨터, 게이트웨이, 디바이스 등) 상에서 실행되는 소프트웨어의 형태로 구현될 수 있다.
또한, 그래픽 사용자 인터페이스(3102)를 생성하기 위한 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 본 출원의 논리 엔티티들은 서비스 지향 아키텍처(SOA) 및/또는 리소스 지향 아키텍처(ROA)를 이용하여 본 출원의 서비스에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.
도 32c는 M2M 디바이스(18), M2M 게이트웨이(14), M2M 서버 등과 같은 M2M 네트워크 노드(30)의 예시적인 하드웨어/소프트웨어 아키텍처의 블록도이다. 노드(30)는 그래픽 사용자 인터페이스(3102)를 생성하기 위한 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 논리 엔티티들을 실행 또는 포함할 수 있다. 디바이스(30)는 도 32a-32b에 도시된 바와 같은 M2M 네트워크의 일부 또는 비-M2M 네트워크의 일부일 수 있다. 도 32c에 도시된 바와 같이, M2M 노드(30)는 프로세서(32), 비-이동식 메모리(44), 이동식 메모리(46), 스피커/마이크로폰(38), 키패드(40), 디스플레이, 터치패드, 및/또는 표시자들(42), 전원(48), 글로벌 포지셔닝 시스템(GPS) 칩셋(50), 및 다른 주변 장치(52)를 포함할 수 있다. 노드(30)는 또한 송수신기(34) 및 전송/수신 요소(36)와 같은 통신 회로를 포함할 수 있다. M2M 노드(30)는 실시예와의 일관성을 유지하면서 상기 요소들의 임의의 서브-조합을 포함할 수 있다는 것이 이해될 것이다. 이 노드는 본 명세서에서 설명된 SMSF 기능성을 구현하는 노드일 수 있다.
프로세서(32)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연관되는 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, ASIC(Application Specific Integrated Circuit)들, FPGA(Field Programmable Gate Array) 회로들, 임의의 다른 타입의 집적 회로(IC), 상태 머신 등일 수 있다. 일반적으로, 프로세서(32)는 노드의 다양한 요청된 기능들을 수행하기 위해 노드의 메모리(예를 들어, 메모리(44) 및/또는 메모리(46))에 저장되는 컴퓨터 실행가능 명령어들을 실행할 수 있다. 예를 들어, 프로세서(32)는 신호 코딩, 데이터 처리, 전력 제어, 입/출력 처리, 및/또는 M2M 노드(30)가 무선 또는 유선 환경에서 작동할 수 있게 하는 임의의 다른 기능성을 수행할 수 있다. 프로세서(32)는 애플리케이션-계층 프로그램들(예를 들어, 브라우저들) 및/또는 무선 액세스-계층(RAN) 프로그램들 및/또는 다른 통신 프로그램들을 실행할 수 있다. 프로세서(32)는 또한, 예를 들어 액세스-계층 및/또는 애플리케이션 계층 등에서의 인증, 보안 키 동의, 및/또는 암호화 동작들과 같은 보안 동작들을 수행할 수 있다.
도 32c에 도시된 바와 같이, 프로세서(32)는 그것의 통신 회로(예를 들어, 송수신기(34) 및 전송/수신 요소(36))에 결합된다. 프로세서(32)는, 컴퓨터 실행가능 명령어들의 실행을 통해, 노드(30)가 이것이 접속되는 네트워크를 통해 다른 노드들과 통신하게 하기 위해 통신 회로를 제어할 수 있다. 특히, 프로세서(32)는 본 명세서 및 청구항들에 기재된 전송 및 수신 단계들을 수행하기 위해 통신 회로를 제어할 수 있다. 도 32c가 프로세서(32)와 송수신기(34)를 별도의 컴포넌트들로서 묘사하고 있지만, 프로세서(32)와 송수신기(34)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 이해할 것이다.
전송/수신 요소(36)는 M2M 서버들, 게이트웨이들, 디바이스 등을 포함하는 다른 M2M 노드들에 신호들을 전송하거나, 또는 이들로부터 신호들을 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 전송/수신 요소(36)는 RF 신호들을 전송 및/또는 수신하도록 구성되는 안테나일 수 있다. 전송/수신 요소(36)는 WLAN, WPAN, 셀룰러 등과 같은, 다양한 네트워크들 및 에어 인터페이스들을 지원할 수 있다. 일 실시예에서, 전송/수신 요소(36)는, 예를 들어 IR, UV, 또는 가시광 신호들을 전송 및/또는 수신하도록 구성되는 방출기/검출기일 수 있다. 또 다른 실시예에서, 전송/수신 요소(36)는 RF 신호 및 광신호 양쪽 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 무선 또는 유선 신호들의 임의의 조합을 전송 및/또는 수신하도록 구성될 수 있다는 것을 이해할 것이다.
또한, 전송/수신 요소(36)는 도 32c에 단일 요소로서 도시되지만, M2M 노드(30)는 임의의 수의 전송/수신 요소들(36)을 포함할 수 있다. 더 구체적으로, M2M 노드(30)는 MIMO 기술을 이용할 수 있다. 따라서, 일 실시예에서, M2M 노드(30)는 무선 신호들을 전송 및 수신하기 위한 둘 이상의 전송/수신 요소(36)(예를 들어, 다수의 안테나)를 포함할 수 있다.
송수신기(34)는 전송/수신 요소(36)에 의해 전송될 신호들을 변조하고, 전송/수신 요소(36)에 의해 수신되는 신호들을 복조하도록 구성될 수 있다. 앞서 언급한 바와 같이, M2M 노드(30)는 다중-모드 능력들을 가질 수 있다. 따라서, 송수신기(34)는 M2M 노드(30)가, 예를 들어 UTRA 및 IEEE 802.11과 같은 다수의 RAT를 통해 통신할 수 있게 하기 위한 다수의 송수신기들을 포함할 수 있다.
프로세서(32)는 비이동식 메모리(44) 및/또는 이동식 메모리(46)와 같은 임의의 타입의 적절한 메모리로부터의 정보에 액세스하고 여기에 데이터를 저장할 수 있다. 예를 들어, 프로세서(32)는 전술한 바와 같이, 그것의 메모리에 세션 상황(session context)을 저장할 수 있다. 비이동식 메모리(44)는 RAM(random-access memory), ROM(read-only memory), 하드 디스크, 또는 임의의 다른 타입의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는 SIM(subscriber identity module) 카드, 메모리 스틱, SD(secure digital) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(32)는 M2M 노드(30) 상에, 예를 들어 서버 또는 홈 컴퓨터 상에 물리적으로 위치하지 않은 메모리로부터의 정보에 액세스하고 여기에 데이터를 저장할 수 있다. 프로세서(32)는 디스플레이 또는 표시자들(42) 상의 조명 패턴들, 이미지들 또는 컬러들을 제어하여 M2M 서비스 계층 세션 마이그레이션 또는 공유의 상태를 반영하거나 또는 사용자로부터 입력을 획득하거나 또는 노드의 세션 마이그레이션 또는 공유 능력들 또는 설정들에 관한 정보를 사용자에게 표시하도록 구성될 수 있다. 다른 예에서, 디스플레이는 세션 상태에 관한 정보를 나타낼 수 있다. 본 개시내용은 oneM2M 실시예에서, RESTful 사용자/애플리케이션 API를 정의한다. 디스플레이 상에 표시될 수 있는 그래픽 사용자 인터페이스는 API의 상부에 계층화되어, 사용자가, 본 명세서에서 설명된 기본 서비스 계층 세션 기능성을 통해, E2E 세션, 또는 그것의 마이그레이션 또는 공유를 대화식으로(interactively) 확립하고 관리하게 할 수 있다.
프로세서(32)는 전원(48)으로부터 전력을 수신할 수 있고, M2M 노드(30) 내의 다른 컴포넌트들에 전력을 분배하고/하거나 제어하도록 구성될 수 있다. 전원(48)은 M2M 노드(30)에 전력을 공급하기 위한 임의의 적절한 디바이스일 수 있다. 예를 들어, 전원(48)은 하나 이상의 드라이 셀 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-이온) 등), 태양광 전지들, 연료 전지들 등을 포함할 수 있다.
프로세서(32)는 또한 M2M 노드(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성되는 GPS 칩셋(50)에 접속될 수 있다. M2M 노드(30)는 실시예와의 일관성을 유지하면서 임의의 적절한 위치-결정 방법에 의해 위치 정보를 취득할 수 있다는 것이 이해될 것이다.
프로세서(32)는 다른 주변 장치(52)에 더 접속될 수 있는데, 이러한 주변장치는, 추가적인 피처, 기능성, 및/또는 유선 또는 무선 연결성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있다. 예를 들어, 주변 장치(52)는, 가속도계, e-나침반, 위성 송수신기, 센서, (사진 또는 비디오를 위한) 디지털 카메라, USB(universal serial bus) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, Bluetooth® 모듈, FM(frequency modulated) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
도 32d는 M2M 서버, 게이트웨이, 디바이스 또는 다른 노드와 같은 M2M 네트워크의 하나 이상의 노드를 구현하기 위해 또한 이용될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)은 컴퓨터 또는 서버를 포함할 수 있고, 주로 소프트웨어의 형태로 어느 곳이나 있을 수 있는 컴퓨터 판독가능 명령어들에 의해, 또는 어떤 수단에 의해서든 저장되거나 액세스되는 이러한 소프트웨어에 의해 제어될 수 있다. 컴퓨팅 시스템(90)은 그래픽 사용자 인터페이스(3102)를 제공하기 위한 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 논리 엔티티들을 실행하거나 포함할 수 있다. 컴퓨팅 시스템(90)은, 예를 들어 M2M 디바이스, 사용자 장비, 게이트웨이, 모바일 케어 네트워크의 노드들을 포함하는 임의의 다른 노드들 또는 UE/GW, 서비스 계층 네트워크 애플리케이션 제공자, 단말 디바이스(18), 또는 M2M 게이트웨이 디바이스(14)일 수 있다. 이러한 컴퓨터 판독 가능 명령어들은, 중앙 처리 유닛(CPU)(91)과 같은 프로세서 내에서 실행되어, 컴퓨팅 시스템(90)이 작업을 수행하게 할 수 있다. 많은 공지된 워크스테이션, 서버, 및 개인용 컴퓨터에서, 중앙 처리 유닛(91)은 마이크로프로세서로 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 다수의 프로세서를 포함할 수 있다. 코프로세서(coprocessor)(81)는 추가 기능을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개인 옵션의 프로세서이다. CPU(91) 및/또는 코프로세서(81)는, 세션 크리덴셜(session credential)들에 기초한 인증 또는 세션 크리덴셜들의 수신과 같은, E2E M2M 서비스 계층 세션들에 대해 개시된 시스템들 및 방법들과 관련되는 데이터를 수신하고, 생성하고, 처리할 수 있다.
동작에 있어서, CPU(91)는 명령어들을 페치, 디코드, 및 실행하고, 컴퓨터의 주 데이터 전송 경로인 시스템 버스(80)를 통해 다른 리소스들로/로부터 정보를 전송한다. 이러한 시스템 버스는 컴퓨팅 시스템(90) 내의 컴포넌트들을 접속하고 데이터 교환을 위한 매체를 정의한다. 시스템 버스(80)는 전형적으로 데이터를 송신하기 위한 데이터 라인들, 어드레스들을 송신하기 위한 어드레스 라인들, 및 인터럽트를 송신하고 시스템 버스를 작동시키기 위한 제어 라인들을 포함한다. 이러한 시스템 버스(80)의 예는 PCI(Peripheral Component Interconnect) 버스이다.
시스템 버스(80)에 접속되는 메모리들은 랜덤 액세스 메모리(RAM)(82) 및 판독 전용 메모리(ROM)(93)를 포함한다. 이러한 메모리들은 정보의 저장 및 검색을 허용하는 회로를 포함한다. ROM들(93)은 일반적으로 쉽게 수정될 수 없는 저장된 데이터를 포함한다. RAM(82)에 저장된 데이터는 CPU(91) 또는 다른 하드웨어 디바이스들에 의해 판독 또는 변경될 수 있다. RAM(82) 및/또는 ROM(93)에 대한 액세스는 메모리 제어기(92)에 의해 제어될 수 있다. 메모리 제어기(92)는 명령어들이 실행됨에 따라 가상 어드레스들을 물리적 어드레스들로 변환하는 어드레스 변환 기능을 제공할 수 있다. 메모리 제어기(92)는 또한 시스템 내의 프로세스들을 분리하고 시스템 프로세스들을 사용자 프로세스들과 분리하는 메모리 보호 기능을 제공할 수 있다. 따라서, 제1 모드에서 실행되는 프로그램은 그 자신의 프로세스 가상 어드레스 공간에 의해 매핑된 메모리에만 액세스할 수 있고; 그 프로그램은, 프로세스들 간에 메모리 공유가 설정되지 않는 한 다른 프로세스의 가상 어드레스 공간 내의 메모리에 액세스할 수 없다.
또한, 컴퓨팅 시스템(90)은 CPU(91)로부터 프린터(94), 키보드(84), 마우스(95), 및 디스크 드라이브(85)와 같은 주변 장치들로 명령어들을 통신할 책임이 있는 주변 장치 제어기(83)를 포함할 수 있다.
디스플레이 제어기(96)에 의해 제어되는 디스플레이(86)는 컴퓨팅 시스템(90)에 의해 생성되는 시각적 출력을 표시하는 데 사용된다. 이러한 시각적 출력은 텍스트, 그래픽, 애니메이션 그래픽, 및 비디오를 포함할 수 있다. 디스플레이(86)는 CRT 기반 비디오 디스플레이, LCD 기반 평면 패널 디스플레이, 가스 플라즈마 기반 평면 패널 디스플레이, 또는 터치 패널로 구현될 수 있다. 디스플레이 제어기(96)는 디스플레이(86)에 송신되는 비디오 신호를 생성하는 데 요구되는 전자 컴포넌트들을 포함한다.
또한, 컴퓨팅 시스템(90)은 도 32a 및 도 32b의 네트워크(12)와 같은 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하여, 컴퓨팅 시스템(90)이 네트워크의 다른 노드들과 통신할 수 있게 하기 위해 이용될 수 있는, 예를 들어 네트워크 어댑터(97)와 같은 통신 회로를 포함할 수 있다.
본 명세서에 설명된 임의의 또는 모든 시스템, 방법 및 프로세스는, 컴퓨터 판독 가능 저장 매체 상에 저장된 컴퓨터 실행 가능 명령어들(즉, 프로그램 코드)의 형태로 구현될 수 있으며, 그 명령어들이, 예를 들어 M2M 서버, 게이트웨이, 디바이스 등을 포함하는 M2M 네트워크의 노드와 같은 머신에 의해 실행될 때, 본 명세서에 설명된 시스템, 방법 및 프로세스를 수행 및/또는 구현하는 것을 이해해야 한다. 구체적으로, 게이트웨이, UE, UE/GW, 또는 모바일 코어 네트워크, 서비스 계층 또는 네트워크 애플리케이션 제공자의 노드들 중 임의의 노드의 동작들을 포함하는, 전술한 단계들, 동작들, 또는 기능들 중 임의의 것은 그러한 컴퓨터 실행가능 명령어들의 형태로 구현될 수 있다. 그래픽 사용자 인터페이스(3102)를 생성하기 위한 논리 엔티티들뿐만 아니라 노드 가용성 추정기(902), DC(904), DP(906) 및/또는 SP(908)와 같은 논리 엔티티들은 컴퓨터 판독 가능 저장 매체 상에 저장된 컴퓨터 실행 가능 명령어들의 형태로 구현될 수 있다. 컴퓨터 판독 가능 저장 매체는 임의의 비일시적인(즉, 유형 또는 물리적) 방법, 또는 정보 저장을 위한 기술로 구현된 휘발성 및 불휘발성, 이동식 및 비이동식 매체 모두를 포함하지만, 이러한 컴퓨터 판독 가능 저장 매체는 신호를 포함하지 않는다. 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 다른 광디스크 스토리지, 자기 카세트, 자기 테이프, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 원하는 정보를 저장하는데 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 유형의 또는 물리적 매체를 포함하지만, 이들에 한정되지 않는다.
도면들에 예시된 바와 같이, 본 개시내용의 주제의 바람직한 실시예들을 설명함에 있어서, 특정 용어가 명료성을 위해 채택된다. 그러나 청구된 주제는 그렇게 선택된 특정 용어로 한정되는 것으로 의도되지 않고, 각각의 특정 요소가 유사한 목적을 달성하기 위해 유사한 방식으로 동작하는 모든 기술적 등가물을 포함하는 것으로 이해되어야 할 것이다.
이렇게 기재된 설명은 예들을 이용하여 최상의 모드를 포함하는 본 발명을 개시하고, 또한 본 기술분야의 통상의 기술자가 임의의 디바이스들 또는 시스템들을 제조하고 이용하는 것과 임의의 포함된 방법들을 수행하는 것을 포함한 본 발명을 실행할 수 있게 한다. 본 발명의 특허 가능한 범위는 청구항에 의해 정의되고, 본 기술분야의 통상의 기술자에게 발생하는 다른 예들을 포함할 수 있다. 이러한 다른 예들은, 청구항들의 문자 그대로의 표현과 상이하지 않은 요소들을 가지는 경우, 또는 이들이 청구항들의 문자 그대로의 표현과 실질적인 차이가 없는 등가적 요소들을 포함하는 경우, 청구항들의 범위 내에 있는 것으로 의도된다.

Claims (20)

  1. 프로세서 및 메모리를 포함하는 장치로서,
    상기 장치는 상기 장치의 메모리에 저장된 컴퓨터 실행 가능 명령어들을 더 포함하고, 상기 컴퓨터 실행 가능 명령어들은, 상기 장치의 프로세서에 의해 실행될 때 상기 장치로 하여금,
    통신 네트워크의 서비스 계층 엔티티의 가용성(availability)에 관한 과거 이력 데이터를 수신하게 하고,
    상기 과거 이력 데이터에 기초하여, 상기 서비스 계층 엔티티가 특정 시간에 가용하게 될 것인지 또는 비가용하게 될 것인지를 추정하게 하며,
    상기 추정을 하나 이상의 클라이언트 디바이스에 의해 액세스될 수 있는 서비스 계층 엔티티 가용성 추정 서비스(service layer entity availability estimation service)로서 제공하게 하는, 장치.
  2. 제1항에 있어서,
    상기 수신하는 것, 상기 추정하는 것 및 상기 제공하는 것은 상기 장치의 서비스 계층 엔티티 가용성 추정 모듈에서 수행되는, 장치.
  3. 제1항에 있어서,
    상기 컴퓨터 실행 가능 명령어들은, 상기 장치의 프로세서에 의해 실행될 때 상기 장치로 하여금 또한 상기 추정의 정확성(accuracy) 또는 신뢰도(confidence) 중 하나를 평가하게 하는, 장치.
  4. 제3항에 있어서,
    상기 평가는 데이터 수집 전략을 조정하거나 새로운 데이터 수집 전략을 생성하는데 사용되는, 장치.
  5. 장치에 의해 수행되는 방법으로서,
    통신 네트워크의 서비스 계층 엔티티의 가용성(availability)에 관한 과거 이력 데이터를 수신하는 단계;
    상기 과거 이력 데이터에 기초하여, 상기 서비스 계층 엔티티가 특정 시간에 가용하게 될 것인지 또는 비가용하게 될 것인지를 추정하는 단계; 및
    상기 추정을 하나 이상의 클라이언트 디바이스에 의해 액세스될 수 있는 서비스 계층 엔티티 가용성 추정 서비스로서 제공하는 단계
    를 포함하는, 방법.
  6. 제5항에 있어서,
    상기 수신하는 단계, 상기 추정하는 단계 및 상기 제공하는 단계는 상기 장치의 서비스 계층 엔티티 가용성 추정 모듈에서 수행되는, 방법.
  7. 제5항에 있어서,
    상기 추정의 정확성 또는 신뢰도 중 하나를 평가하는 단계
    를 더 포함하는 방법.
  8. 제7항에 있어서,
    상기 평가는 데이터 수집 전략을 조정하거나 새로운 데이터 수집 전략을 생성하는데 사용되는, 방법.
  9. 제2항에 있어서,
    상기 서비스 계층 엔티티 가용성 추정 모듈은 다른 서비스 계층 엔티티의 공통 서비스 기능으로서 구현되는, 장치.
  10. 제1항에 있어서,
    상기 과거 이력 데이터는 상기 서비스 계층 엔티티와 관련되는 성능, 구성, 이벤트 로그들, 에러 보고들 및 통계 중 하나 이상과 관련되는 데이터를 포함하는, 장치.
  11. 제1항에 있어서,
    상기 서비스 계층 엔티티가 특정 시간에 가용하게 될 것인지 또는 비가용하게 될 것인지를 추정하는 것은 데이터 해석, 정보 추론 및 정보 융합 중 하나 이상을 수행하는 것을 포함하는, 장치.
  12. 제6항에 있어서,
    상기 서비스 계층 엔티티 가용성 추정 모듈은 다른 서비스 계층 엔티티의 공통 서비스 기능으로서 구현되는, 방법.
  13. 제5항에 있어서,
    상기 과거 이력 데이터는 상기 서비스 계층 엔티티와 관련되는 성능, 구성, 이벤트 로그들, 에러 보고들 및 통계 중 하나 이상과 관련되는 데이터를 포함하는, 방법.
  14. 제5항에 있어서,
    상기 서비스 계층 엔티티가 특정 시간에 가용하게 될 것인지 또는 비가용하게 될 것인지를 추정하는 단계는 데이터 해석, 정보 추론 및 정보 융합 중 하나 이상을 수행하는 단계를 포함하는, 방법.
  15. 컴퓨터 실행가능 명령어들을 포함하는 컴퓨터 판독가능 저장 매체로서,
    상기 컴퓨터 실행가능 명령어들은, 장치의 프로세서에 의해 실행될 때 상기 장치로 하여금,
    통신 네트워크의 서비스 계층 엔티티의 가용성에 관한 과거 이력 데이터를 수신하게 하고,
    상기 과거 이력 데이터에 기초하여, 상기 서비스 계층 엔티티가 특정 시간에 가용하게 될 것인지 또는 비가용하게 될 것인지를 추정하게 하며,
    상기 추정을 하나 이상의 클라이언트 디바이스에 의해 액세스될 수 있는 서비스 계층 엔티티 가용성 추정 서비스로서 제공하게 하는, 컴퓨터 판독가능 저장 매체.
  16. 제15항에 있어서,
    상기 수신하는 것, 상기 추정하는 것 및 상기 제공하는 것은 상기 장치의 서비스 계층 엔티티 가용성 추정 모듈에서 수행되는, 컴퓨터 판독가능 저장 매체.
  17. 제16항에 있어서,
    상기 서비스 계층 엔티티 가용성 추정 모듈은 다른 서비스 계층 엔티티의 공통 서비스 기능으로서 구현되는, 컴퓨터 판독가능 저장 매체.
  18. 제15항에 있어서,
    상기 컴퓨터 실행 가능 명령어들은, 상기 장치의 프로세서에 의해 실행될 때 상기 장치로 하여금 또한 상기 추정의 정확성 또는 신뢰도 중 하나를 평가하게 하는, 컴퓨터 판독가능 저장 매체.
  19. 제18항에 있어서,
    상기 평가는 데이터 수집 전략을 조정하거나 새로운 데이터 수집 전략을 생성하는데 사용되는, 컴퓨터 판독가능 저장 매체.
  20. 제15항에 있어서,
    상기 과거 이력 데이터는 상기 서비스 계층 엔티티와 관련되는 성능, 구성, 이벤트 로그들, 에러 보고들 및 통계 중 하나 이상과 관련되는 데이터를 포함하는, 컴퓨터 판독가능 저장 매체.
KR1020187024490A 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측 KR102101319B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462018941P 2014-06-30 2014-06-30
US62/018,941 2014-06-30
PCT/US2015/038503 WO2016004011A1 (en) 2014-06-30 2015-06-30 Network node availability prediction based on past history data

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020167036707A Division KR20170013334A (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020197003110A Division KR102137598B1 (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측

Publications (2)

Publication Number Publication Date
KR20180098426A KR20180098426A (ko) 2018-09-03
KR102101319B1 true KR102101319B1 (ko) 2020-04-16

Family

ID=53546743

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020197003110A KR102137598B1 (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측
KR1020187024490A KR102101319B1 (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측
KR1020167036707A KR20170013334A (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020197003110A KR102137598B1 (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020167036707A KR20170013334A (ko) 2014-06-30 2015-06-30 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측

Country Status (6)

Country Link
US (2) US10250457B2 (ko)
EP (2) EP3162003B1 (ko)
JP (2) JP6470770B2 (ko)
KR (3) KR102137598B1 (ko)
CN (2) CN113098736A (ko)
WO (1) WO2016004011A1 (ko)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10432748B2 (en) 2014-07-16 2019-10-01 Tensera Networks Ltd. Efficient content delivery over wireless networks using guaranteed prefetching at selected times-of-day
US11095743B2 (en) 2014-07-16 2021-08-17 Tensera Networks Ltd. Optimized content-delivery network (CDN) for the wireless last mile
US10659332B2 (en) * 2014-11-26 2020-05-19 Nxp Usa, Inc. Network node, a communication system and associated methods
US10104567B2 (en) 2016-05-31 2018-10-16 At&T Intellectual Property I, L.P. System and method for event based internet of things (IOT) device status monitoring and reporting in a mobility network
US10355945B2 (en) * 2016-09-21 2019-07-16 International Business Machines Corporation Service level management of a workload defined environment
US10599479B2 (en) 2016-09-21 2020-03-24 International Business Machines Corporation Resource sharing management of a field programmable device
US10572310B2 (en) 2016-09-21 2020-02-25 International Business Machines Corporation Deploying and utilizing a software library and corresponding field programmable device binary
US10417012B2 (en) 2016-09-21 2019-09-17 International Business Machines Corporation Reprogramming a field programmable device on-demand
CN107453941B (zh) * 2017-06-21 2020-02-18 深圳市盛路物联通讯技术有限公司 一种终端设备的物联网数据上报频率的控制及系统
US11540140B2 (en) * 2018-05-15 2022-12-27 Apple Inc. Neighbor awareness networking time slot allocation
CN108881171A (zh) * 2018-05-21 2018-11-23 赵慧卿 一种基于异步时分复用技术的多路视频并发流优化方法
CN109297491A (zh) * 2018-09-06 2019-02-01 西安云景智维科技有限公司 一种室内定位导航方法及系统
US11132357B1 (en) * 2018-09-14 2021-09-28 State Farm Mutual Automobile Insurance Company Big-data view integration platform
US10542582B1 (en) * 2018-11-27 2020-01-21 Honeywell International Inc. Wireless communication with adaptive responsiveness
KR20200098421A (ko) * 2019-02-11 2020-08-20 현대자동차주식회사 M2m 시스템에서 복합 이벤트 처리 관리 방법 및 장치
KR102158100B1 (ko) 2019-03-08 2020-09-22 (주)엔키아 이상 감지를 이용한 모니터링 자동화 방법 및 장치
CN109982420B (zh) * 2019-05-07 2021-12-14 肇庆学院 一种基于监测行为规则的无线传感器网络休眠调度方法
CN110636471A (zh) * 2019-09-23 2019-12-31 上海大学 一种基于wsn技术的监测系统
WO2021258110A1 (en) * 2020-06-19 2021-12-23 Viavi Solutions Inc. Determining a parameter characteristic of a state of a user equipment via autonomous scaling of input data resolution and aggregation
EP4047879A1 (en) * 2021-02-18 2022-08-24 Nokia Technologies Oy Mechanism for registration, discovery and retrieval of data in a communication network
US11790300B2 (en) 2021-08-03 2023-10-17 State Farm Mutual Automobile Insurance Company Systems and methods for generating insurance business plans

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070037609A1 (en) * 2005-08-11 2007-02-15 Toshiba America Research, Inc. Reducing power consumption of wi-fi enabled mobile devices
US20080313110A1 (en) * 2007-06-13 2008-12-18 International Business Machines Corporation Method and system for self-calibrating project estimation models for packaged software applications
US20140122878A1 (en) * 2012-10-30 2014-05-01 Kt Corporation Security management in m2m area network

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1111888A (zh) * 1993-11-01 1995-11-15 莫托罗拉公司 选择优选通信资源的方法
JP3726310B2 (ja) * 1995-06-01 2005-12-14 富士ゼロックス株式会社 情報通信システム
JP3319341B2 (ja) * 1997-06-20 2002-08-26 日本電気株式会社 データ共有システム
US20020133614A1 (en) * 2001-02-01 2002-09-19 Samaradasa Weerahandi System and method for remotely estimating bandwidth between internet nodes
JP2003296274A (ja) * 2002-03-29 2003-10-17 Fujitsu Ltd データ取得システム
AU2004301426B2 (en) * 2003-07-14 2008-10-23 Orative Corporation System and method for active mobile collaboration
US20050091369A1 (en) * 2003-10-23 2005-04-28 Jones Michael D. Method and apparatus for monitoring data storage devices
US7631225B2 (en) 2004-10-01 2009-12-08 Cisco Technology, Inc. Approach for characterizing the dynamic availability behavior of network elements
US7342900B2 (en) 2004-05-19 2008-03-11 Hewlett-Packard Development Company, L.P. Apparatus and method for estimating device availability
EP1987648A1 (en) 2006-02-21 2008-11-05 Thomson Licensing Peer-to-peer video content distribution network based on personal network storage
US20080034105A1 (en) * 2006-08-02 2008-02-07 Ist International Inc. System and method for delivering contents by exploiting unused capacities in a communication network
CN100469033C (zh) * 2006-11-07 2009-03-11 北京四达时代软件技术股份有限公司 一种信道网络中信息播发调度方法
CN101563904A (zh) * 2006-12-19 2009-10-21 艾利森电话股份有限公司 在服务供应网络中提供服务的技术
JP2008154143A (ja) * 2006-12-20 2008-07-03 Sony Corp 受信データ記録システム、受信機、受信機の制御方法、レコーダ、データ記録方法およびプログラム
JP4925994B2 (ja) * 2007-10-12 2012-05-09 シャープ株式会社 無線テレコントロールシステム
US20090161243A1 (en) * 2007-12-21 2009-06-25 Ratnesh Sharma Monitoring Disk Drives To Predict Failure
CN101309208B (zh) * 2008-06-21 2010-12-01 华中科技大学 一种适用于网格环境的基于可靠性代价的作业调度系统
JP5200725B2 (ja) * 2008-07-18 2013-06-05 株式会社リコー 電子機器の再生支援システム
US8171134B2 (en) * 2009-03-18 2012-05-01 At&T Intellectual Property I, L.P. Methods and apparatus to characterize and predict network health status
WO2011106925A1 (en) * 2010-03-01 2011-09-09 Nokia Corporation Method and apparatus for estimating user characteristics based on user interaction data
US20120169482A1 (en) * 2011-01-05 2012-07-05 Ian Chen System and Method for Selecting a Device for Remote Control Based on Determined Navigational State of a Remote Control Device
CN102123052B (zh) * 2011-03-30 2013-05-29 北京星网锐捷网络技术有限公司 业务系统可用性评估方法及系统
JP5454516B2 (ja) * 2011-06-13 2014-03-26 コニカミノルタ株式会社 情報処理装置、設定変更方法およびプログラム
CN103621115B (zh) * 2011-07-01 2019-05-14 瑞典爱立信有限公司 用于通信处理的节点和方法
BR112014005333A2 (pt) * 2011-09-09 2017-04-11 Numerex Corp método e sistema para determinar a localização de um objeto móvel
JP5586567B2 (ja) * 2011-11-07 2014-09-10 三菱電機株式会社 無線ネットワークシステム、制御方法及びプログラム
US9647949B2 (en) * 2012-06-22 2017-05-09 University Of New Hampshire Systems and methods for network transmission of big data
CN103595741A (zh) * 2012-08-14 2014-02-19 中国科学院声学研究所 一种p2p流媒体中的节点及优化节点邻居节点表的方法
US9298337B2 (en) * 2013-02-07 2016-03-29 Google Inc. Mechanism to reduce accidental clicks on online content
CN103501320B (zh) * 2013-09-18 2017-04-26 北京航空航天大学 一种利用失效日志计算存储集群可用性的方法
WO2015065258A1 (en) * 2013-11-01 2015-05-07 Telefonaktiebolaget L M Ericsson (Publ) Managing radio traffic load
CN104954271B (zh) * 2014-03-26 2018-11-30 国际商业机器公司 Sdn网络中的数据包处理方法和装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070037609A1 (en) * 2005-08-11 2007-02-15 Toshiba America Research, Inc. Reducing power consumption of wi-fi enabled mobile devices
US20080313110A1 (en) * 2007-06-13 2008-12-18 International Business Machines Corporation Method and system for self-calibrating project estimation models for packaged software applications
US20140122878A1 (en) * 2012-10-30 2014-05-01 Kt Corporation Security management in m2m area network

Also Published As

Publication number Publication date
JP2019068478A (ja) 2019-04-25
EP3544238A3 (en) 2019-11-20
JP2017531335A (ja) 2017-10-19
US20190182126A1 (en) 2019-06-13
EP3162003A1 (en) 2017-05-03
JP6842477B2 (ja) 2021-03-17
KR20190015599A (ko) 2019-02-13
EP3544238B1 (en) 2021-04-14
JP6470770B2 (ja) 2019-02-13
KR20170013334A (ko) 2017-02-06
CN106664219B (zh) 2021-04-16
EP3544238A2 (en) 2019-09-25
CN106664219A (zh) 2017-05-10
CN113098736A (zh) 2021-07-09
KR20180098426A (ko) 2018-09-03
US10637747B2 (en) 2020-04-28
EP3162003B1 (en) 2019-05-01
KR102137598B1 (ko) 2020-07-24
WO2016004011A1 (en) 2016-01-07
US20180159746A1 (en) 2018-06-07
US10250457B2 (en) 2019-04-02

Similar Documents

Publication Publication Date Title
KR102101319B1 (ko) 과거 이력 데이터에 기초하는 네트워크 노드 가용성 예측
EP3320752B1 (en) M2m clustering management
US10225710B2 (en) Cross-layer context management
CN106797392B (zh) M2m-iot服务的发布和发现
EP3332513A1 (en) Service element host selection
EP3912329B1 (en) Automated service layer message flow management in a communications network

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application
A107 Divisional application of patent
J201 Request for trial against refusal decision
J301 Trial decision

Free format text: TRIAL NUMBER: 2019101000334; TRIAL DECISION FOR APPEAL AGAINST DECISION TO DECLINE REFUSAL REQUESTED 20190130

Effective date: 20200305

S901 Examination by remand of revocation
GRNO Decision to grant (after opposition)
GRNT Written decision to grant