KR102047197B1 - 사물 인터넷을 위한 광역 서비스 발견 - Google Patents

사물 인터넷을 위한 광역 서비스 발견 Download PDF

Info

Publication number
KR102047197B1
KR102047197B1 KR1020187003237A KR20187003237A KR102047197B1 KR 102047197 B1 KR102047197 B1 KR 102047197B1 KR 1020187003237 A KR1020187003237 A KR 1020187003237A KR 20187003237 A KR20187003237 A KR 20187003237A KR 102047197 B1 KR102047197 B1 KR 102047197B1
Authority
KR
South Korea
Prior art keywords
dns
service
server
message
iot
Prior art date
Application number
KR1020187003237A
Other languages
English (en)
Other versions
KR20180024003A (ko
Inventor
샤밈 아크바 라만
충강 왕
리쥔 둥
꾸앙 리
광 루
쉬 리
주오 첸
Original Assignee
콘비다 와이어리스, 엘엘씨
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 콘비다 와이어리스, 엘엘씨 filed Critical 콘비다 와이어리스, 엘엘씨
Publication of KR20180024003A publication Critical patent/KR20180024003A/ko
Application granted granted Critical
Publication of KR102047197B1 publication Critical patent/KR102047197B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery
    • H04L61/1541—
    • H04L61/1511—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/59—Network arrangements, protocols or services for addressing or naming using proxies for addressing
    • H04L61/6013—
    • H04L67/16—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Abstract

클라우드 기반 DNS-SD 아키텍처는, 특히 별개의 LAN들을 함께 링크하여 정규 인터넷 DNS와는 별개의 클라우드 기반 DNS-SD 서버 및 휴면 노드 처리를 포함하는 서비스 발견 관점으로부터의 가상 발견 구역을 형성한다. 한 예에서, 클라우드 기반 DNS-SD 서버는 정규 인터넷 DNS 서버와는 별개이다. 이 클라우드 DNS-SD 서버는, 특히 가상 발견 구역에서의 서비스 발견을 위한 사설 IaaS(Infrastructure as a Service)로서 운영될 수 있다.

Description

사물 인터넷을 위한 광역 서비스 발견
관련 출원의 상호참조
본 출원은, 참조로 그 내용을 본 명세서에 포함시키는, 발명의 명칭이 "Wide Area Service Discovery For Internet Of Things"인, 2015년 7월 6일 출원된 미국 가출원번호 제62/188,781호의 우선권 혜택을 주장한다.
도메인 네임 시스템(Domain Name System)
DNS(Domain Name System)는 인터넷에 접속된 (호스트라고도 하는) 디바이스들에 관한 정보의 분산형 데이터베이스이다. 구체적으로는, DNS는 (니모닉 디바이스(mnemonic device)로서 사용되는) 사람이 판독할 수 있는 네임과 (인터넷 라우팅에 사용되는) IP 주소 사이의 매핑 정보를 포함한다.
● 예 1: 웹 사이트 네임 "www.google.com"은 IP 주소 "74.125.224.72"로 매핑된다
● 예 2: 전자메일 주소 "john.smith@bestcompany.com"는 IP 주소 "208.49.79.242"로 매핑된다.
이 정보는 DNS 자원 레코드(Resource Record)(RR)라고 불리는 DNS 데이터베이스 엔트리에 저장된다. DNS 서버는 DNS 레코드에 저장된 인터넷에 접속된 디바이스들(호스트들)에 관한 정보를 제공함으로써 클라이언트 질의에 응답한다. 가장 흔한 질의는 네임을 IP 주소로 변환하는 것이다. 이 기능을 DNS 네임 해결(DNS name resolution)이라고 한다. 기술적으로, 해결된 네임을 FQDN이라고 한다. 여기서 논의될 다른 유형의 가능한 DNS 질의도 역시 있다.
DNS에 대한 반-수동(semi-manual) 방식은 초기에는 작동했지만, 인터넷에 접속된 호스트들의 수가 기하급수적으로 증가하기 시작하면서 잘 확장되지 못했다. 따라서, DNS를 정의하는 일련의 핵심 IETF 표준으로 이어진 더욱 자동적이며 확장가능한 솔루션을 결정하기 위한 조사가 있었다. 참조로 그 전체 내용을 본 명세서에 포함시키는 RFC 1034 및 RFC 1035를 참조한다.
오늘날의 DNS는 전 세계적으로 위치한 많은 컴퓨터 서버에 분산된 분산형 데이터베이스이다. 이 데이터베이스는 도메인 네임의 개념을 중심으로 구성된다(예를 들어, ".com"은 도메인 네임의 일부이고 "www.bestcompany.com"은 FQDN이다). 각각의 도메인 네임은 본질적으로, 도메인 네임공간이라 불리는 큰 거꾸로 된 트리 내의 경로이다(도 1 참조). 도메인은 전체 공간의 하위-트리이다. 트리 구조는 최상단에 하나의 (논리적) 루트(root)를 갖는다. 트리의 깊이는 127 레벨로 제한된다. 트리 내의 각각의 노드는 최대 63 글자까지의 텍스트 라벨 네임을 갖는다.
도메인 네임은, 항상, 리프 노드(leaf node)로부터 루트를 향하는 쪽으로 판독되고, 도트(dot)는 경로 내의 네임들을 분리한다. 따라서, 예를 들어 FQDN "www.bestcompany.com"의 경우 ".com"은 트리의 최상단에 있으며 최상단 레벨 도메인(Top Level Domain)(TLD)이라고 한다. 그 다음, "bestcompany"가 트리에서 그 다음 아래에 있고, "www"가 트리의 최하단 리프에 있다.
앞서 언급된 바와 같이, DNS 데이터베이스 엔트리는 RR이라 불리는 포맷으로 저장된다. RR은 도메인 또는 특정한 도메인 네임(FQDN)으로 구성된다. FQDNS는 궁극적으로 물리적 네트워크 디바이스와 연관되는 반면, 도메인(예를 들어, ".com")은 디바이스들의 그룹을 식별하는데 사용된다. RR에 포함된 디바이스와 관련된 정보 유형별로 분류된 다양한 유형의 RR이 있다. 일부 예시적인 DNS RR들이 표 1에 열거되어 있다.
Figure 112018011523083-pct00001
Figure 112018011523083-pct00002
DNS 질의 및 응답은 통상적으로 포트 53 상에서 UDP 패킷을 통해 직접 전송된다. TCP 전송 옵션도 존재하지만 전형적으로 상당히 짧은 트랜잭션인 DNS 질의/응답에 대해 권장되는 옵션은 아니다. DNS는 도 2에 도시된 바와 같이 3개의 컴포넌트를 갖는 단일 메시지 포맷을 정의한다.
3개의 컴포넌트는, 헤더 부분(105), 질문 부분(107), 및 응답 부분(109)이다. 헤더 부분(105)과 관련하여, 메시지 유형 및 가변 부분의 크기를 기술하는 필드들을 갖는 고정된 12 바이트 헤더가 있다. 질문 부분(107)은 DNS 네임 서버에 전송되는 정보에 대한 하나 이상의 질의를 포함한다. 응답 부분(109)은, 응답(111), 권한(authority)(112) 및 추가(113)와 같은, 질문 부분(107) 내의 질의/질문에 대한 응답으로서 3개의 하위 컴포넌트에 하나 이상의 RR을 포함한다. 응답(111)은 질문에 직접 대답하는 RR(들)이다. 권한(112)은 해결 프로세스를 계속하는데 사용될 수 있는 권한 있는(authoritative) DNS 네임 서버를 가리키는 RR(들)이다. 추가(113)는 원래의 질문에 응답하는데 엄격하게 필요하지 않은 질의에 관련된 추가 정보를 포함하는 RR(들)이다.
도 3은 사용자가 웹 브라우징을 수행함으로써 개시되는 DNS 조회에 대한 전형적인 메시지 시퀀스 도면을 나타낸다. 단계 121에서, 랩탑(130)의 사용자는 최신 Google 비즈니스 뉴스를 읽기를 원한다. 이 정보는 랩탑(130)의 브라우저(131)와 연관된 사용자 인터페이스를 통해 입력된다. 브라우저(131)는 "google.com"의 IP 주소를 얻을 필요가 있음을 인식한다. 따라서, 브라우저(131)는 이 요청과 함께 랩탑(130)의 DNS 클라이언트(132)와 콘택한다. 단계 122에서, 일단 DNS 클라이언트(131)가 요청을 얻으면, 이것은 FQDN = "google.com"을 갖는 DNS 메시지 질의를 형성한다. 이 질의는 인터넷(120)을 통해 디폴트 DNS 서버(133)에 전송된다. DNS 서버(133)의 IP 주소는 DNS 클라이언트(132)에서 이미 이용가능할 수 있다. DNS 서버(133)의 IP 주소는, 랩탑에서 미리 준비되었거나 DHCP와 같은 프로토콜에 의해 랩탑 부팅 프로세스에서 검색되었을 수 있다.
단계 123에서, DNS 서버(133)는 단계 122의 수신된 질의에 대한 내부 조회를 수행하고 ".com" 도메인의 서버가 DNS 서버(134)라고 결정한다. 따라서 (RR을 포함하는) DNS 메시지는 DNS 클라이언트(132)에 다시 전송되어 DNS 클라이언트(132)가 재귀적 탐색을 수행해야 하고 동일한 질의로 DNS 서버(134)와 콘택해야 한다는 것을 통보한다. 단계 124에서, DNS 클라이언트는 단계 122의 유사한 정보를 갖는 DNS 메시지를 DNS 서버(134)에 전송한다. 이 예에서, DNS 서버(134)는 권한 있는 도메인 서버이므로 더 이상의 재귀는 필요하지 않다. 단계 125에서, DNS 서버(125)는 요청된 "google.com" 서버의 IP 주소(74.125.224.72)를 포함하는 "A" RR을 포함하는 단계 124에 대한 응답과 함께 DNS 메시지를 전송할 것이다. 단계 126에서, DNS 클라이언트(132)는 DNS 메시지로부터의 "google.com" IP 주소를 브라우저(131)에 전송한다. 단계 127에서, 브라우저(131)는, "google.com" IP 주소(74.125.224.72)에 직접 HTTP Get 요청을 전송하여 최신 뉴스일 수 있는 원하는 콘텐트를 회수한다. 단계 128에서, "google.com" 서버는 적절한 최신 비즈니스 뉴스 콘텐츠를 갖는 HTTP 응답과 함께 응답한다.
DNS-SD
DNS-서비스 발견(DNS-Service Discovery)(DNS-SD)은 DNS에 최근에 추가된 비교적 새로운 특징이다. DNS-SD는, 일반적인 네임 해결 기능 외에도 이용가능한 로컬 네트워크 IP 기반 서비스를 발견하기 위한 DNS의 이용을 말한다. 예를 들어, IP를 통해 액세스될 수 있는 로컬 네트워크 내의 가용 프린터들에 대해 DNS-SD에 질의한다. 구체적으로는, 클라이언트가 이 메커니즘에 대해 찾고 있는 서비스 유형(예를 들어, 인쇄)이 주어지면, 클라이언트는 표준 DNS-질의를 사용하여 주어진 도메인에서 그 원하는 서비스의 디바이스들(명명된 인스턴스들)의 로컬 목록을 발견할 수 있다. IETF 표준화된 솔루션에 대한 상업용 조짐은 Apple Computer의 "AppleTalk"(때로는 "Bonjour"라고도 함)라고 불리는 것이었다. 그 전체가 참조로 본 명세서에 포함되는 RFC 676을 참조한다.
IETF에서, IP "서비스"는, 서비스 네임(예를 들어, FTP, HTTP), 전송 프로토콜(예를 들어, UDP, TCP), 및 전송 프로토콜의 포트 번호를 포함하는 3개의 정보의 조합에 의해 인식된다. 알려진 인터넷 IP 서비스들의 광범위한 레지스트리(extensive registry)는 IETF에 의해 서비스 네임 및 전송 프로토콜 포트 번호 레지스트리에서 유지된다. 그 전체가 참조로 본 명세서에 포함되는 http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml을 참조한다.
기술적으로, DNS-SD는 2개의 기능으로 구성된다. 제1 기능은 멀티캐스트 DNS(mDNS)라고 한다. mDNS는, 어떠한 종래의 유니캐스트 DNS 서버도 없을시에 로컬 IP 멀티캐스트 기능을 사용함으로써 로컬 네트워크 DNS 동작을 수행할 수 있는 능력을 제공한다. 따라서, 디바이스들은, 전용 DNS 서버들이 질의에 응답할 것(예를 들어, 프린터는 인쇄 서비스를 찾는 멀티캐스트 DNS 질의에 직접 응답할 것이다)을 요구하는 대신에, 로컬 IP 멀티캐스트 DNS 질의 자체에 직접 응답할 수 있다. mDNS는 또한, 디바이스들이 링크-로컬 멀티캐스트를 사용하여 그들의 지원되는/변경된 서비스들을 적극적으로 광고하는 것을 허용한다. 또한, mDNS는 DNS 네임공간의 일부를 로컬 이용(예를 들어, 새로운 ".local" 도메인)을 위해 비워두도록 지정하며, 연회비를 지불할 필요가 없고, 이들 네임에 대해 응답하도록 위임을 설정하거나 기타의 방식으로 기존의 DNS 서버를 구성할 필요가 없다. 그 전체가 참조로 본 명세서에 포함되는 RFC 6762를 참조한다.
제2 기능은 그 자체로 (약간 혼동스럽게) DNS-SD라고 불린다. 이것은 RFC 6763(그 전체가 참조로 포함됨)에 기술되어 있으며, 서비스 발견 질의를 지원하기 위해 DNS 레코드 구조 내에서 요구되는 변경을 명시한다(예를 들어, DNS가 고전적 네임 해결 질의 이상을 지원하도록 구성). 이것은 또한, 주어진 도메인의 특정한 서비스에 대해 질의하기 위해 순수 유니캐스트 모드에서 사용될 수 있다. 그러나, 이 유니캐스트 모드는 오늘날 일반적인 서비스 발견 기능으로서 사용되지 않는다.
DNS-SD 및 mDNS의 조합은 통상적으로, 네트워크에서의 동적 멀티캐스트 서비스 발견의 정황에서 사용될 때 단지 "DNS-SD"라고 지칭된다. 서비스 발견은 클라이언트가 멀티캐스트 질의를 전송하고 요청된 IP 기반 서비스를 지원하는 디바이스들로부터 직접 응답(유니캐스트)을 수신하는 클라이언트에 의해 직접 필요에 따라 수행된다. 이 서비스 발견은 로컬 네트워크를 위해 작동한다(예를 들어, 복수의 LAN에 걸쳐 동적으로 서비스를 발견할 수 없음).
도 4는 전형적인 DNS-SD 메시지 흐름을 나타낸다. 단계 141에서, 사용자는 워드 프로세서(136)로부터의 컬러 문서를 인쇄하기를 원한다. 워드 프로세서(136)는 컬러 프린터(예를 들어, 컬러 프린터(139))의 IP 주소를 획득할 필요가 있음을 인식한다. 따라서 워드 프로세서(136)는 이 요청과 함께 랩탑(130) 내의 DNS 클라이언트(132)에 메시지를 전송한다. 단계 142에서, 일단 DNS 클라이언트(132)가 요청을 획득하고 나면, DNS 클라이언트(132)는 그 요청 "컬러 프린터"를 찾고 있다는 것을 나타내는 DNS-SD(멀티캐스트) 메시지 질의를 형성해야 한다고 결정한다. 이 질의는 랩탑(130)이 접속된 LAN(140)을 통해 IP 멀티캐스트에 의해 전송된다. IP 멀티캐스트 메커니즘은 LAN(140)에 접속된 모든 디바이스에 DNS-SD 질의를 자동으로 배포한다(메시지는 LAN(140)을 넘어서는 안된다). (UDP 포트 53을 통해 전송되는) 표준 DNS 질의와는 달리, UDP 포트 5353을 통해 멀티캐스트 DNS-SD 질의가 전송된다. 또한, 멀티캐스트 DNS-SD 도메인은, "ColorPrinter.local"과 같은 ".local" 접미사로 끝나는 FQDN을 갖는 것으로서 명시된다.
단계 143에서, LAN(140) 내의 복수의 디바이스는 DNS-SD 멀티캐스트 질의를 수신하지만, 여기서, 컬러 프린터(139)만이 일치하는 서비스 유형을 갖는다. 컬러 프린터(139)는, 요청된 서비스 서버의 IP 주소(예를 들어, 192.168.0.11)를 포함하는 DNS-SD 메시지(유니캐스트) 응답을 전송한다. 단계 144에서, 랩탑(130)의 DNS 클라이언트(132)는 컬러 프린터(139)의 IP 주소를 워드 프로세서(136)에 전송한다. 단계 145에서, 워드 프로세서(136)는 HTTP Post 요청을 컬러 프린터(139)의 IP 주소에 직접 전송하여 첨부물이 인쇄되도록 요청한다. 단계 146에서, 컬러 프린터(139)는 첨부물이 성공적으로 인쇄되었다는 것을 표시하는 성공적인 HTTP 응답 코드 (201)로 응답한다.
앞서 언급된 바와 같이, DNS-SD는 주로 로컬 네트워크에서 IP 기반의 서비스를 발견하는데 사용된다. DNS-SD는 3개의 표준 DNS RR을 조합하여, 대개 포인터 레코드(PTR), 서비스 로케이터 레코드(SRV) 및 텍스트 레코드(TXT)를 포함하는 서비스들을 식별한다. DNS-SD 탐색은, 클라이언트가 주어진 도메인에 대한 PTR 레코드에서 특정한 서비스 유형을 찾기 위해 탐색 파라미터에서 명시하는 DNS 질의를 전송하는 것을 포함한다. 그 다음, DNS-SD 서버는 SRV RR에서 서비스 인스턴스에 도달할 수 있는 타겟 디바이스(호스트) 네임과 포트 뿐만 아니라 보조 정보(TXT RR)를 제공하는 0개 이상의 SRV/TXT 쌍 세트를 반환한다. 그러면, 타겟 디바이스의 IP 주소는 연관된 "A" 또는 "AAAA" 레코드로부터 획득될 수 있다.
하이브리드 DNS-SD 프록시
최근의 초안 하이브리드 유니캐스트/멀티캐스트 DNS 기반 서비스 발견은, IP 기반의 서비스들의 선택적인 광역 발견을 허용하기 위해 하이브리드 프록시를 사용하는 것을 제안한다. 그 전체가 참조로 본 명세서에 포함되는 http://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00을 참조한다. 구체적으로, 이 초안은 mDNS를 사용하여 로컬 네트워크에서 DNS-SD 서비스들을 발견하고 응답들을 집계하며 다른 LAN에 있는 요청 클라이언트에 다시 응답하는 프록시를 제안한다. 이것은 역시 (논쟁의 여지가 있고 아직 IETF에서 협의되지 않은) DNS의 명명 시스템에 대한 중요한 변경을 요구할 것이다. 현재, DNS 도메인 네임은 이전에 설명한 바와 같이 궁극적으로 주어진 디바이스와 연관된다. 하이브리드 유니캐스트/멀티캐스트 DNS-기반의 서비스 초안이 승인된다면, 개개의 디바이스 대신에, LAN(예를 들어, 로컬 링크)이 명명되는 것을 허용하여(예를 들어, "4thFloor.Building1.companyX.com"), 주어진 서비스를 탐색하기 위해 질의받을 수 있게 할 수 있다.
도 5는 하이브리드 DNS-SD 프록시 시나리오에 대한 예시적인 흐름을 나타낸다. 단계 151에서, 컬러 프린터를 탐색하기 위해 특정한 "명명된" LAN(예를 들어, BestCompany의 3층)에 질의가 전송될 것이 요구된다. 단계 152 내지 단계 154에서, 보통의 (유니캐스트) DNS 질의 메커니즘은, 질의가 주어진 LAN(140)(예를 들어, BestCompany의 3층)에 대한 DNS-SD 프록시(150)로 포워딩되게 할 것이다. 단계들 155 내지 156에서, DNS-SD 프록시(150)는 mDNS 요청을 트리거한다. LAN(140) 내의 디바이스들은 DNS-SD 멀티캐스트 질의를 수신하지만, (컬러 프린터의) 일치하는 서비스 유형을 갖는 컬러 프린터(139)만이 응답할 것이다. 컬러 프린터(139)는 요청받은 서비스 서버의 IP 주소를 포함하는 DNS-SD 메시지(유니캐스트) 응답을 전송한다. 단계들 157 내지 158에서, IP 주소를 갖는 DNS 응답은 다시 워드 프로세서(136)로 중계된다. 단계 159에서, 워드 프로세서(136)는 HTTP Post 요청을 컬러 프린터(139)의 IP 주소에 직접 전송하여 첨부물이 인쇄되도록 요청한다.
DNS-SD는 현재 로컬 네트워크 내의 IP 기반의 서비스들(예를 들어, 프린터, 팩스 등)을 발견하고 광고할 수 있지만, LAN들에 걸쳐 작동하는 시스템에 대한 필요성이 있다.
본 명세서에서는, 특히, 별개의 LAN들을 함께 링크하여 정규 인터넷 DNS와는 별개의 클라우드 기반 DNS-SD 서버 및 휴면 노드 처리를 포함하는 서비스 발견 관점으로부터의 가상 발견 구역을 형성하는 클라우드 기반 DNS-SD 아키텍처가 개시된다. 한 예에서, 클라우드 기반 DNS-SD 서버는 정규 인터넷 DNS 서버와는 별개이다. 이 클라우드 DNS-SD 서버는, 특히 가상 발견 구역에서의 서비스 발견을 위한 사설 IaaS(Infrastructure as a Service)로서 운영될 수 있다.
IoT 디바이스 및 IoT 게이트웨이는 (예를 들어, 휴면 노드 처리를 위한) DNS-SD 질의 및 응답을 처리하고, 또한 다른 유형의 DNS 질의(예를 들어, 표준 DNS 네임 해결 질의)와 구별한다. 절차들은 가상 발견 구역 및 제어 노드(예를 들어, DSN-SD 서버, IoT 게이트웨이)를 정의하고 구성한다. 한 예에서, 다양한 제어 노드들에서 OAM 절차들을 통해 구성이 발생할 수 있다. 또 다른 예에서, 구성은 제어 노드들 사이의 시그널링에 기초한 동적 네트워크 자기-구성 접근법을 통해 발생할 수 있다. 사용자 인터페이스는 가상 발견 구역들을 그래픽으로 디스플레이할 수 있다.
방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 서비스에 대한 DNS-SD 질의를 제1 LAN으로부터 수신하고; DNS-SD 질의를 수신하는 것에 응답하여, 제2 LAN 상에서 서비스에 관한 정보를 제공하기 위한 수단을 갖는다.
방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 서비스에 대한 요청을 제공하고; 요청에 대한 응답을 수신하기 위한 수단을 가지며, 응답은 서비스와 연관된 디바이스에 관한 휴면 노드 정보를 포함한다.
본 요약은, 이하의 상세한 설명에서 더 설명되는 선발된 개념들을 간략화된 형태로 소개하기 위해 제공되는 것이다. 본 요약은, 청구 대상의 핵심 피쳐나 본질적 피쳐들을 식별하기 위함도 아니고, 청구 대상의 범위를 제한하기 위해 사용되는 것도 아니다. 또한, 청구 대상은 본 개시의 임의의 부분에서 언급된 임의의 또는 모든 단점을 해결하는 한도로 제한되지 않는다.
첨부된 도면과 연계하여, 예를 통해 주어지는 이하의 상세한 설명으로부터 더 상세한 이해를 얻을 수 있다. 이하에서:
도 1은 예시적인 DNS 데이터베이스 구조를 나타낸다;
도 2는 3개의 컴포넌트를 갖는 예시적인 단일 메시지 DNS 포맷을 나타낸다;
도 3은 사용자가 웹 브라우징을 수행함으로써 개시되는 DNS 조회에 대한 예시적인 메시지 시퀀스 도면을 나타낸다;
도 4는 예시적인 DNS-SD 메시지 흐름을 나타낸다;
도 5는 하이브리드 DNS-SD 프록시 시나리오에 대한 예시적인 흐름을 나타낸다;
도 6은 예시적인 광역 서비스 발견 시스템을 나타낸다;
도 7은 가상 발견 구역에서의 프린터 발견을 위한 예시적인 흐름을 나타낸다;
도 8은 시스템 기동에 사용될 수 있는 예시적인 방법을 나타낸다;
도 9는 시스템 동작을 위한 예시적인 방법을 나타낸다;
도 10은 가상 발견 구역을 자기-구성하는 예시적인 국면을 나타낸다;
도 10은 가상 발견 구역을 자기-구성하는 또 다른 예시적인 국면을 나타낸다;
도 11은 가상 발견 구역을 자기-구성하는 또 다른 예시적인 국면을 나타낸다;
도 12는 휴면 노드 처리를 포함할 수 있는 예시적인 광역 서비스 발견 구현을 나타낸다;
도 13은 DNS RR을 사용하여 휴면 노드 시나리오를 처리하기 위한 예시적인 흐름을 나타낸다;
도 14는 광역 서비스 발견과 연관된 예시적인 사용자 인터페이스를 나타낸다;
도 15a는 개시된 주제가 구현될 수 있는 예시적인 머신-대-머신(machine-to-machine)(M2M) 또는 사물 인터넷(Internet of Things)(IoT) 통신 시스템의 시스템도이다;
도 15b는 도 15a에 나타낸 통신 시스템 내에서 사용될 수 있는 예시적인 M2M/IoT 단말 또는 게이트웨이 디바이스의 시스템도이다;
도 15c는 도 15a의 통신 시스템의 양태들이 구현될 수 있는 예시적인 컴퓨팅 시스템의 블록도이다;
도 15d는 도 15a에 나타낸 M2M/IoT 통신 시스템 내에서 사용될 수 있는 예시적인 아키텍처를 나타낸다.
본 명세서에는 IoT 시나리오들에 대해 로컬 네트워크를 넘어서 작동하는 DNS 서비스 발견(DNS-SD)이 개시된다. DNS-SD는 현재 로컬 네트워크에서 IP 기반 서비스(예를 들어, 프린터, 팩스 등)를 발견하고 광고할 수 있지만 LAN들에 걸쳐서는 작동하지 않는다. 그러나, 많은 IoT 시나리오에서 이것은 충분하지 않다. 서비스 네임의 예는, "온도 센서" 또는 "전등 스위치" 또는 "도어 잠금"이다. 또한, RFC 7252에 언급된 전송 프로토콜(예를 들어, CoAP를 사용하는 IoT 서비스를 위한 UDP) 및 포트 번호(예를 들어, 디폴트 UDP CoAP 포트는 5683)에 관한 다른 서비스들도 논의된다.
이하, 종래의 DNS-SD 기술의 소정 제약 또는 제한에 대해 논의한다. 종래의 DNS-SD는, (예를 들어, mDNS가 요구되지 않고) 서비스를 탐색하기 위해 DNS 서버에 직접 질의하는 엄격한 유니캐스트 방법을 지원하고 LAN들에 걸쳐 작동할 수 있다. 그러나 이러한 유니캐스트 접근법은 여러 가지 이유로 범용 서비스 발견 접근법으로서 간주되지 않는다. 제1 이유는 특정한 서비스를 탐색하는 클라이언트가 어떤 도메인을 탐색할지를 결정할 수 있는 방법과 연관된 문제를 다룬다. 유니캐스트의 경우 어느 도메인을 탐색할 것인지를 알 필요가 있다. 많은 또는 모든 도메인을 탐색하는 무차별 대입 접근법은, 너무 많은 시그널링과 서비스 발견에서 더 중요한 잠재적으로 상당한 지연을 초래할 것이다. "현재" 도메인을 탐색하는 단순한 접근법은 서비스가 그 곳에 등록되지 않은 경우 기회 손실을 초래할 수 있다.
제2 이유는 디바이스들이 그들의 지원 서비스에 관한 정보로 DNS 서버들을 자동으로 갱신할 수 있는 방법과 연관된 문제를 다룬다. DNS RR을 업데이트하는 것은 클라이언트와 업데이트하려는 DNS 서버 사이에서 상당히 복잡한 보안 연관을 요구한다. 이 강력한 보안 연관은, 예를 들어 보안 증서의 수동 구성을 요구할 수 있기 때문에, 프린터, IoT 디바이스 등과 같은 간단한 기성품 디바이스로는 가능하지 않다. 인간 운영자가 이 정보를 모두를 DNS 서버에 수동으로 입력하는 것은, 서비스들 및 디바이스들의 규모와 예상되는 동적 특성으로 인해, 많은 경우에 실용적이지 않은 것으로 간주된다.
종래의 DNS-SD는 서버에 질의하기 위한 mDNS 방법을 지원한다. 종래의 DNS-SD와 연관된 mDNS는 로컬 링크 내에서 서비스 발견에 대해 잘 작동하는 것으로 간주될 수 있지만, 로컬 링크 외부에서는 작동하지 않도록 명시적으로 제한된다. 이러한 제약에 대한 이유는, mDNS 기능은 IETF에 의한 로컬 링크 IP 멀티캐스트 주소에 대해서만 할당된다는 것이다(RFC 6763의 22절 참조). 일반적으로, 서비스 발견을 위해 LAN을 넘어선 멀티캐스팅은 많은 시나리오에서 상당한 네트워크 혼잡을 야기할 것으로 예상되므로 IETF에 의해 명시적으로 금지된다. 본 명세서에서 논의된 바와 같이, 로컬 링크는 통상적으로 LAN 또는 LAN의 서브섹션과 동일하다. 링크는 통상적으로, 복수의 디바이스가 접속되는 Ethernet 또는 WiFi와 같은 공유된 전송 매체이다. 종종 링크는 단일 계층 2(브로드캐스트) 도메인으로 변환된다(그러나 브리지들과 같이 L2 디바이스들에 의해 확장될 수 있음). 일반적으로, 로컬 링크는 패킷을 중계하기 위해 계층 3 IP 라우터를 요구하지 않는다. 본 명세서에서, 간소화를 위해, 간단히, "LAN" 또는 "로컬 네트워크"라는 용어는 "로컬 링크"라는 용어와 바꾸어 쓸 수 있다.
IoT라는 용어는, 현재 표준화된 프로토콜을 사용하여 전체 인터넷 내에 완전히 통합될 수 있는 지점까지 주로 전용 M2M 시스템의 진화를 기술하는 용어이다. 본 명세서에서는, IoT 시나리오를 위해 로컬 네트워크를 넘어서 작동하도록 DNS-SD를 사용하는 접근법(광역 서비스 발견)이 개시된다. 로컬 네트워크를 벗어나는 발견을 요구하는 많은 IoT 시나리오에서, 현재 DNS-SD로는 충분하지 않다. 예를 들어, 스마트 그리드(예를 들어, 네트워킹된 전기 유틸리티) 운영자가 도시 전역에 IoT 디바이스를 배치한다면, 운영자는 전체 배치에 걸쳐(예를 들어, 복수의 LAN에 걸쳐) 서비스의 공통 발견을 원할 것이며, 이것은 지금까지 충족될 수 없었던 요구사항이다.
"Extensions for Scalable DNS SD - Charter for WG"이라는 제목의 IETF 문서는, "가정, 캠퍼스, 및 기업 네트워크를 포함하는 많은 시나리오에서 DNS-SD/mDNS 프로토콜 수트가 사용된다. 그러나, 제로 구성 mDNS 프로토콜은, 설계에 의해 링크-로컬 멀티캐스트 범위로 제약되므로, 원격 링크 상에서 서비스를 발견하는데 사용할 수 없다"라고 기재하면서, 이 문제를 명시하고 있다. 그 전체가 참조로 본 명세서에 포함되는 http://datatracker.ietf.org/wg/dnssd/charter를 참조한다.
전술된 문제점들을 해결하려고 시도하는 하이브리드 DNS-SD 프록시는, 요구시 (예를 들어, DNS-SD 질의시에) 빈번한 mDNS 멀티캐스트 트래픽을 개시하는 것을 포함하는 단점을 갖는다. 도달해야 할 디바이스 또는 네트워크가 많아서 더 높은 오버헤드 트래픽을 야기하기 때문에 빈번한 멀티캐스트는 IoT 환경에 맞게 확장되지 않는다. 또한, 많은 IoT 디바이스들은 종종 휴면 상태일 수 있으므로 많은 멀티캐스트 DNS-SD 질의를 놓칠 수 있다.
또한, 하이브리드 DNS-SD 프록시는, IoT 배치에 대해 최적화된 IoT 특정 아키텍처(예를 들어, RD) 및 IoT 특정 프로토콜(예를 들어, CoAP)을 사용하지 않으며, 그에 따라 이들 IoT 특정 노드들 및 프로토콜들에 비해 더 높은 오버헤드 및 비효율을 야기한다.
따라서, 종래의 DNS-SD 서비스 발견 접근법은, 서로 어떤 논리적 관계를 갖는 복수의 LAN에 걸친 서비스 발견(예를 들어, 어떤 제한 내에서의 광역 서비스 발견)을 가능하게 하는 더 효율적인 메커니즘(DNS-SD)를 지원하도록 상당히 변경될 수 있다.
본 명세서에서 논의된 광역 서비스 발견은 자원 디렉토리(resource directory)(RD)를 활용할 수 있다. (RD)는 IoT 환경을 위해 다른 서버 상에서 보유된 자원들(예를 들어, URI들)의 서술(description)을 호스팅하는 서버이다. 그 전체가 참조로 본 명세서에 포함되는 CoRE 자원 디렉토리 http://tools.ietf.org/html/draft-ietf-core-resource-directory-02(이하에서는 CoRE Resource Directory(자원 디렉토리))를 참조한다. 자원 디렉토리는, 이들 자원들에 대해 중앙집중형 조회가 수행되는 것을 허용한다. 보통의 Google 유형의 웹 탐색은 IoT 환경에서 효율적으로 작동하지 않는다고 추정된다. 대신에, RD는 RESTful CoAP 인터페이스를 지원하여 디바이스들이 그들의 자원들 뿐만 아니라 관련 메타데이터를 등록하는 것을 허용한다. 또한, 디바이스의 자원들 사이의 관계가 저장될 수 있다. 별도의 RESTful 인터페이스는, 제3자 클라이언트가 RD를 탐색하여 그 주어진 탐색 기준을 충족하는 자원을 찾는 것(발견하는 것)을 허용한다. 그 다음, 일단 RD에 의해 탐색 결과가 제공되고 나면 제3자 클라이언트는 자원(URI)으로 직접 이동할 수 있다.
CoRE 자원 디렉토리는 어느 한 수단에 의해 CoAP 서비스의 발견을 허용하는 RD 필드와 종래의 DNS-SD 필드의 간단한 매핑을 정의한다. 구체적으로는, 특별 클라이언트가 먼저 RD로부터 CoAP 서비스의 표준 RD 조회를 수행할 수 있도록 제안한다. 그러면, 클라이언트는 응답을 받고 종래의 DNS-SD에서 정보의 유니캐스트 등록을 수행할 수 있다. 위에서 언급한 바와 같이, 이것은 DNS 인프라스트럭처와의 복잡한 보안 연관을 확립할 수 있는 클라이언트를 요구한다. 따라서, 클라이언트는 단순한 IoT 디바이스일 수 없지만 특별 목적 관리 구성 클라이언트일 가능성이 크다.
도 6은 예시적인 광역 서비스 발견 시스템(160)을 나타낸다. LAN(170), LAN(175), 및 LAN(180)은, 각각, 게이트웨이(171), 게이트웨이(176), 및 게이트웨이(181)를 포함한다. LAN(170)과 같은 각각의 LAN은, 게이트웨이(예를 들어, 게이트웨이(171))와 국지적으로 통신가능하게 접속된 IoT 디바이스(예를 들어, IoT 디바이스(172)), 및 인터넷(162)과 통신가능하게 접속된 게이트웨이를 포함할 수 있다. 광역 서비스 발견 시스템(160) 내의 게이트웨이(171)와 같은 게이트웨이는 CoAP RD 또는 유사한 기능을 지원할 수 있다. 인터넷(162)은 DNS 서버(161) 및 IoT 서비스 클라우드(166)와 통신가능하게 접속된다. IoT 서비스 클라우드(166)는, 특히, 빅 데이터 분석(163), 스토리지(164), 및 IoT DNS-SD 서버(165)를 포함할 수 있다. 시스템(160)의 다양한 LAN 내의 IoT 디바이스들은, 제3 자 IoT 디바이스 서비스 발견 서버(예를 들어, IoT DNS-SD 서버(165))에 의해 관리되는 가상 발견 프로세스에서 협력할 수 있는 소유자 또는 운영자(예를 들어, 비즈니스, 유틸리티 등)를 가질 수 있다. 표준 DNS 네임 해결은 인터넷(162)의 기존("정규") DNS 인프라스트럭처에 의해 여전히 수행될 수 있다. LAN(170) 및 LAN(180)은 동일한 가상 발견 구역(167) 내에 있다.
본 명세서에서 더 상세하게 논의되는 바와 같이, DNS-SD 질의는 2-단계 프로세스로 수행될 수 있다. 먼저 동일한 LAN 내에서 국지적으로 서비스를 발견하려는 시도가 이루어진다. 이것이 성공적이지 않으면, 질의는 IoT DNS-SD 서버(165)로 라우팅될 수 있다. 이 클라우드 기반 IoT DNS-SD 서버(165)는 가상 발견 구역(167) 내의 IoT 디바이스들에 대한 서비스 발견 질의에 응답할 수 있다.
본 명세서에서 논의된 바와 같이, 광역 서비스 발견 시스템(160)은 LAN을 넘어 설정된 가상 발견 구역을 가능하게 한다. 이 예에서, LAN(170) 및 LAN(180)은 가상 발견 구역(167) 내로 함께 엮여지는 2개의 물리적으로 분리된 (인접하지 않은) LAN이다. 가상 발견 구역(167)에서, 서비스 발견은 전체 구역 내의 모든 디바이스들에 걸쳐 인에이블될 수 있다. 이 구역은 임의의 크기일 수 있고 요구되는 만큼의 LAN들을 포함할 수 있다. 또한, 하나의 가상 발견 구역(167)만이 도 6에 도시되어 있지만, 정의된 복수의 가상 발견 구역이 존재할 수 있다(대개 그럴 것이다). 예를 들어, 도시되지는 않았지만, LAN(175) 및 LAN(180)은 별개의 가상 발견 구역에 있을 수 있다.
계속 도 6을 참조하면, 서비스들은 주어진 IoT 가상 발견 구역(167) 외부의 발견에 대해 노출되지 않는다. 가상 발견 구역은 중첩되거나 중첩되지 않을 수 있다. 따라서, 2개의 중첩하는 구역들의 일부가 되는 서비스는 이들 구역들 각각에서 발견될 수 있다. 또 다른 예에서, 주어진 가상 발견 구역은 복수의 고전적인 mDNS 도메인을 포함할 수 있다. 고전적인 mDNS 도메인은 단일 서브넷 또는 LAN이다. 주어진 가상 발견 구역은 통상적으로 복수의 LAN을 포함한다.
도 7, 도 10, 도 11 내지 도 13, 및 기타의 도면들에 나타낸 단계들을 수행하는 엔티티들은, 도 15c에 나타낸 것들과 같은 디바이스, 서버, 또는 컴퓨터 시스템의 프로세서의 메모리에 저장되고 프로세서 상에서 실행되는 소프트웨어(예를 들어, 컴퓨터-실행 가능한 명령어)의 형태로 구현될 수 있는 논리적 엔티티일 수도 있다는 것을 이해해야 한다. 즉, 도 7, 도 10, 도 11 내지 도 13, 및 기타의 도면들에 나타낸 방법(들)은 도 15c에 도시된 디바이스 또는 컴퓨터 시스템과 같은 컴퓨팅 디바이스의 메모리에 저장된 소프트웨어(예를 들어, 컴퓨터-실행 가능한 명령어)의 형태로 구현될 수 있으며, 이 컴퓨터 실행 가능한 명령어는, 컴퓨팅 디바이스의 프로세서에 의해 실행될 때, 도 7, 도 10, 도 11 내지 도 13 및 기타의 도면들에 나타낸 단계들을 수행한다. 한 예에서, M2M 디바이스들의 상호작용에 관하여 이하에서 더 상세히 논의되는 바와 같이, 도 10의 디바이스(172)는 도 15a의 M2M 단말 디바이스(18) 상에 상주할 수 있는 반면, 도 10의 IoT DNS-SD 서버(165)는 도 15a의 M2M 게이트웨이 디바이스(14) 상에 상주할 수 있다.
도 7은 가상 발견 구역 내의 프린터의 발견을 위한 예시적인 흐름을 나타낸다. 단계 191에서, DNS-SD 질의가 IoT 디바이스(182)로부터 게이트웨이(181)로 전송된다. IoT 디바이스(182)는 자동차에 위치한 컴퓨팅 디바이스일 수 있다. 단계 191의 질의는 홈 오피스 컬러 프린터(예를 들어, IoT 디바이스(172))를 사용하기 위한 요청일 수 있다. 단계 192에서, 게이트웨이(181)는 LAN(180)을 탐색하고 요청된 서비스를 발견하지 못한다. 단계 193에서, 게이트웨이(181)는 단계 192의 결과에 기초하여 IoT DNS-SD 서버(165)에 질의해야 한다고 결정한다. 게이트웨이(181)는 CoAP RD를 포함할 수 있다. 단계 194에서, 게이트웨이(181)는 IoT DNS-SD 서버(165)에 질의를 전송한다. 이 질의는 본질적으로 단계 191의 질의를 반영할 수 있다. 단계 194의 이 질의에서, IoT 디바이스(172)(예를 들어, 홈 오피스의 컬러 프린터)의 위치를 요구할 수 있다. 단계 195에서, IoT DNS-SD 서버(165)는 홈 오피스 컬러 프린터(IoT 디바이스(172))가 IoT DNS-SD 서버(165)에 등록되어 있다고 결정할 수 있다. 단계 196에서, 게이트웨이(181)는 IoT 디바이스(172)의 IP 주소 또는 IoT 디바이스(172)의 가용성을 나타내는 정보를 포함할 수 있는 DNS-SD 응답을 수신한다. 게이트웨이(181)에서 수신된 IP 주소는 공개 고유 IP 주소일 수 있다. 게이트웨이(181)는 네트워크 주소 변환(network address translation)(NAT)을 통해 공개 IP 주소를 사설 IP 주소로 변환할 수 있다. 이후의 요청(예를 들어, 단계(198))은 디바이스들 사이의 IP 통신을 가능하게하기 위해 종래의 NAT 원리를 사용하는 사설 IP 주소일 수 있다. 다른 종래의 IP 통신 시나리오들도 고려해 볼 수 있다. 단계 197에서, 게이트웨이(181)는 단계 196에서 수신된 IP 주소를 IoT 디바이스(182)에 전송한다. 단계 198에서, IoT 디바이스(182)는 IoT 디바이스(172)에 요청된 문서를 인쇄하기 위한 데이터를 전송한다. 단계 198의 요청은 첨부물을 포함하는 CoAP POST 요청일 수 있다.
도 7의 흐름은 다음의 이용 사례와 관련될 수 있다. 자동차의 운전자는 일과 후 저녁에 집으로 향하고 있다. 그녀는 집에 도착하면 중요한 예산 스프레드시트를 검토해야 한다는 것을 기억한다. 그 다음, 운전자는 음성 명령으로 자동차 컴퓨터에게 자신의 전자 메일로부터의 문서를 "홈 오피스 컬러 프린터"로 인쇄할 것을 지시한다. 그러면, 자동차 컴퓨터는 "홈 오피스 컬러 프린터"에 대한 표준 DNS-SD 발견 질의를 전송한다. 이 프린터는 자동차가 접속되어 있는 LAN에서는 발견되지 않는다. (도 7의 191 참조) 그 다음, 자동차는 클라우드 DNS-SD 서버가 가상 발견 구역에 접속된 다른 모든 디바이스를 알 것이라는 것을 알고 있기 때문에, 질의는, 자동차 IoT 게이트웨이에 의해 셀룰러 접속을 통해 IoT 클라우드 DNS-SD 서버로 포워딩된다. (도 7의 단계 194 참조) 클라우드 DNS-SD 서버에서 홈 오피스 컬러 프린터는 이전에 등록되었으므로, 클라우드 DNS-SD 서버는 그 프린터의 요구되는 정보(IP 주소 포함)를 전송함으로써 질의에 성공적으로 응답한다. (도 7의 단계들 196 및 197 참조) 자동차 컴퓨터는 스프레드시트를 인쇄하기 위해 즉시 홈 프린터에 직접 요청을 전송한다. (도 7의 단계 198 참조)
도 7의 논의를 계속 참조하면, IoT 디바이스(172)(예를 들어, 프린터)에 대한 사설 주소를 갖는 중간 솔루션이 지원될 수 있다. 이러한 상황에서, 프린터에 대해 발견될 IP 주소는 실제로 홈 게이트웨이(게이트웨이(171))에 할당되고 클라우드 서버(IoT DNS-SD 서버(165))에 등록될 것이다. 그 다음 게이트웨이(171)(또는 이와 유사한 디바이스)는 자동차로부터 인쇄 요청을 수신할 것이고(단계 198), 프린터에 국지적으로 할당된 내부(사설) IP 주소로 변환할 것이다. 이것은 네트워크 주소 변환(NAT) 접근법을 사용한다. 예를 들어, 게이트웨이(171)는 매핑을 알고 있을 수 있다. 다른 디바이스들은 게이트웨이(171)가 서비스를 제공한다고 생각할 수 있다.
도 7의 이용 사례는, 특히 간단한 디바이스에 대해, 종래의 DNS-SD 기술을 사용하여 효율적으로 달성되지 않을 것이다. 홈 프린터와 같은 간단한 디바이스는, 특히 비용 및 소유자에 대한 복잡성, 및 보안 위험 때문에 공중 인터넷 DNS 레코드에 거의 입력되지 않는다. 하이브리드 DNS-SD 프록시 접근법은 또한, 자동차 운전자가 방금 "홈 프린터" 대신에 "임의의 프린터"를 지정한 경우 이동하는 자동차로부터 질의할 DNS-SD 프록시가 분명하지 않기 때문에 어려울 것이다. 가상 발견 구역의 경우 도메인은 전체 구역이다. 도 9의 설명에 따르면, 현재의 LAN으로부터 시작하여, 전체 구역 내에 탐색이 있다는 것을 의미한다.
도 8은 시스템 기동에 사용될 수 있는 예시적인 방법(200)을 나타낸다. 단계 201에서, DNS-SD 서버는 앞서 논의된 바와 같이 구성된다. 이것은 가상 발견 구역의 소유자 또는 운영자에 의해 개시될 수 있다. 가상 발견 구역은 IoT 로컬 네트워크와 연관될 수 있다. 예를 들어, 결합된 도 6의 LAN(170) 및 LAN(180)은 가상 발견 구역(예를 들어, 동일한 소유자 또는 운영자)일 수 있다. 또 다른 예에서, LAN(180) 및 LAN(170)은, 협력하는 소유자(또는 운영자)들의 그룹이 서로를 신뢰하고 IoT 서비스를 공유하기 때문에 가상 발견 구역을 형성할 수 있다. 협력의 이유는 비즈니스 관계 때문일 수 있다. 소유자는, 예를 들어, 주택 소유자, 사업자 또는 공공 유틸리티일 수 있다. 클라우드 DNS-SD 서버 자체는, Amazon™ 또는 Google™과 같은 클라우드 서버 공급자에서 실행될 수 있다. 한 예에서, 클라우드 DNS-SD는 IoT 고객을 타겟으로 하는 클라우드 제공자의 IaaS로서 제공될 수 있다.
단계 202에서, 가상 발견 구역은 IoT 네트워크(들)의 운영자 또는 소유자에 의해 정의될 수 있다. 이것은 클라우드 DNS-SD 서버와 게이트웨이들의 그룹 사이에 연관을 정의함으로써 달성될 수 있다. 예를 들어, 도 6을 참조하면, 가상 발견 구역 1(미도시) = {IoT DNS-SD 서버(165), 게이트웨이(171) 및 게이트웨이(176)}이고; 가상 발견 구역 2(예를 들어, 가상 발견 구역(167)) = {IoT DNS-SD 서버(165), 게이트웨이(171) 및 게이트웨이(181)}이다. 가상 구역들의 정의는 IoT 네트워크를 위해 존재하는 종래의 OAM 인터페이스(예를 들어, SNMP)를 통해 구성되거나 프로그래밍될 수 있다. 요약하면, OAM 인터페이스를 통해, DNS-SD 서버(165) 및 관련 게이트웨이는 정의된 가상 발견 구역 관계를 갖는다. 각각의 노드는 상이한 운영자들 사이의 전반적인 협력 관계의 정황에서 각각의 운영자에 의해 구성될 수 있다. 여기서 논의되는 노드는 임의의 주어진 박스(예를 들어, 게이트웨이, 디바이스, DNS 서버 등)를 의미한다. 이 구성 프로세스의 일부로서, 게이트웨이(예를 들어, 게이트웨이(171))에는, 클라우드 DNS-SD 서버(예를 들어, DNS-SD 서버(165)) 호스트 네임 및 클라우드 DNS-SD 서버에 액세스하거나 여기에 기입하기 위해 필요한 임의의 보안 증서가 제공될 수 있다. DNS-SD 서버(165)는 클라우드에 있기 때문에 단일의 물리적 노드에 상주할 필요는 없다는 점에 유의해야 한다. 표준 클라우드 기능은 부하 균형 목적과 같이 필요에 따라 이것을 분산시킬 수 있다. 이것은 게이트웨이(예를 들어, 게이트웨이(171)) 및 IoT 디바이스(예를 들어, IoT 디바이스(172))에 대해 투명하게 이루어질 수 있다.
단계 203에서, 각각의 LAN 세그먼트 내의 (게이트웨이의 일부일 수 있는) CoAP RD가 채워진다. LAN 내의 디바이스들은 그들의 URI를 RD에 등록한다. 그 전체가 참조로 본 명세서에 포함되는 RFC 6690에서 논의되는 링크 포맷 메시지를 참조한다. URI들 및 연관된 정보는, CoRE Resource Directory의 9절에서 논의된 바와 같이 RD에 의해 그들의 연관된 DNS-SD RR 포맷으로 매핑될 수 있다. RD는 CoAP 및 HTTP 기반의 서비스에 관한 정보를 저장할 수 있다.
단계 204에서, 각각의 게이트웨이(예를 들어, 게이트웨이(171))는 어느 DNS-SD 레코드를 클라우드 DNS-SD 서버(예를 들어, IoT DNS-SD 서버(165))로 내보내기를 원하는지를 결정할 것이다. 이전 문장은, 일단 CoAP RD 레코드가 안정되고 나면(예를 들어, 임계 기간 동안 새로운 RD 업데이트가 없음) 발생할 수 있다. 게이트웨이(171)의 RD가 작다면(예를 들어, 비교적 적은 양의 레코드를 포함한다면), 게이트웨이(171)의 RD는, 간소화를 위해, 그 모든 레코드를 IoT DNS-SD 서버(165)로 내보내기로 결정할 수 있다. 게이트웨이(171)의 RD가 비교적 많은 양의 정보를 포함한다면, 모든 레코드를 내보내는 것은 비효율적일 수 있다. 이 경우, 게이트웨이(171)가 (예를 들어, 애플리케이션 지식에 의해) LAN(170) 외부의 디바이스들에게 관심대상이 될 것임을 인지하는 몇몇 주요 서비스를 갖는다면, 게이트웨이(171)는 이들 특정한 레코드들을 IoT DNS-SD 서버(165)에만 내보낼 것이다. RD에서 DNS-SD 서버로 레코드를 내보내는 종래의 프로세스는 CoRE Resource Directory의 9.6 절에서 설명된 바와 같이 사용될 수 있다. 따라서, IoT DNS-SD 서버(165)는 본 명세서에서 논의된 새로운 RR뿐만 아니라 종래의 DNS RR로 채워질 것이다. 또한 상기 프로세스 이후에 RD의 레코드들에 대한 관련 업데이트가 이루어진다면, RD는 새로운 RR만을 DNS-SD에 내보낼 수 있다.
도 9는 예시적인 시스템 동작 국면을 나타낸다. 도 8과 연관된 단계들은 시스템 동작 국면에 있도록 보존될 수 있다. 이하의 단계들은 예시의 목적을 위해 도 6의 정황에서 고려된다. 단계 211에서, LAN(170)의 IoT 디바이스(172)에 의한 DNS 질의가 있다. 단계 212에서, 게이트웨이(171)는 단계 211의 질의가 서비스 발견 DNS 질의인지를 결정할 수 있다. 단계 213에서, 단계 211의 질의가 종래의 DNS 질의(예를 들어, 네임 결정 질의)인 것으로 결정되면, 인터넷 상의 DNS 서버(161)에 질의가 이루어진다.
단계 215에서, 단계(211)의 질의가 서비스 발견 DNS 질의라면, LAN(170) 내의 로컬 질의가 발생할 수 있다. 예를 들어, 이 로컬 질의는 특히 CoAP RD의 탐색 또는 LAN(170) 내의 다른 모든 디바이스에 대한 mDNS 멀티캐스트 질의의 개시일 수 있다.
제1 예에서, IoT 디바이스(172)는 LAN(170) 내의 모든 다른 디바이스들에 mDNS 멀티캐스트 질의를 직접 개시하기로 결정할 수 있다. 이 경우, 게이트웨이(171)는 보통의 IoT 디바이스로서 동작하는 것 이외의 것을 수행할 필요는 없고, 주어진 서비스를 지원한다면 mDNS 질의에 응답할 수도 있다. 제2 예에서, IoT 디바이스(172)는 유니캐스트 DNS-SD 질의를 수행하기로 결정할 수 있다. 게이트웨이(171)가 유니캐스트 DNS-SD 요청을 수신하면, 게이트웨이(171)는 이를 인터셉트하고, 서비스가 자신의 로컬 CoAP RD 데이터베이스에서 발견될 수 있는지를 먼저 확인하려고 시도할 것이다. 이전에 언급한 바와 같이, 이것이 CoRe Resource Directory의 9절에서 설명되는 한 RD와 DNS-SD 레코드 사이의 간단한 매핑이다. 로컬 질의의 선택(예를 들어, RD로의 mDNS 또는 유니캐스트 DNS-SD)은 IoT 디바이스(172)의 애플리케이션 로직에 달려있다.
단계 216에서, 서비스가 LAN(170) 내에서 발견되는지에 대한 결정이 이루어진다. 단계 217에서, 단계 211의 질의에서 요청된 서비스가 LAN(170)에서 발견된다면, 게이트웨이(171) 또는 다른 로컬 디바이스는 DNS-SD 응답으로 요청 IoT 디바이스(172)에 응답한다. 단계 219에서, 단계 211의 질의에서 요청된 서비스가 LAN(170)에서 발견되지 않는다면, 게이트웨이(171)는 요청하는 IoT 디바이스(172)에 즉시 응답하지 않을 수 있다. 그 대신에, 게이트웨이(171)는 요청된 서비스가 가상 발견 구역 내의 다른 곳에서 (예를 들어, 가상 발견 구역(167) 내의 LAN(180) 내에서) 발견될 수 있는지를 알기 위해 유니캐스트 DNS-SD 질의를 IoT DNS-SD 서버(165)에 포워딩할 수 있다. 게이트웨이(171)가 수 개의 중첩하는 발견 가상 구역에 속할 수도 있다는 점에 유의한다. 따라서, IoT DNS-SD 서버(165)가 단계 217의 질의를 수신하면, IoT DNS-SD 서버(165)는 이 특정한 질의가 탐색하기를 원하는 가상 발견 구역에 관한 결정을 할 것이다. 이 결정은, 부하 균형, 보안 증서 또는 기타 요인에 기초할 수 있다. 중첩하는 발견 가상 구역이 탐색되는 것을 허용하기 위해 IoT DNS-SD 서버(165)의 디폴트 구성이 있을 수 있다.
단계 221에서, 서비스가 가상 발견 구역(167)의 다른 곳에서 발견되었다면, 게이트웨이(171)는 IoT DNS-SD 서버(165)로부터 DNS-SD 응답을 수신하고 응답을 요청 IoT 디바이스(172)에 포워딩한다.
단계 223에서, IoT 디바이스(172)는 응답을 조사하고, 본 명세서에서 논의된 휴면여부 상태를 갖는 반환된 새로운 RR 레코드를 조사함으로써 요청된 서비스를 수행할 수 있는 서버가 현재 휴면 중인지 깨어 있는지(또는 비교적 짧은 시간에 깨어날 것인지)를 체크한다. 서버가 휴면중이면, 게이트웨이(171)를 통해 IoT 디바이스(172)는 동일한 가상 발견 구역 내의 어딘가에 있는 또 다른 서버를 찾으려고 시도할 것이다.
단계 219에서, 구역 내의 임의의 곳에서 어떠한 이용가능한 깨어 있는 서비스 서버가 없다면, IoT 디바이스(172)는 정규 인터넷 DNS 서버(161)에 DNS-SD 요청을 전송하도록 게이트웨이(171)를 트리거할 수 있다. IoT 디바이스(172)는 애플리케이션 타이밍이나 기타의 요구조건에 따라 다양한 DNS-SD 요청을 트리거하기를 원하는 횟수를 결정할 수 있다. 단계 225에서, IoT 디바이스(172)는 필요에 따라 서비스 서버와 콘택한다.
이하에서는 디바이스에 대한 휴면 모드와 연관된 시그널링 변경을 논의한다. 본 명세서에서 논의된 바와 같이, DNS의 프로토콜 요소는 RR의 개념이다. 이들 RR은 개개의 디바이스 뿐만 아니라 DNS 도메인의 특성을 기술한다. 예를 들어, "A" 레코드는 디바이스(호스트)의 IPv4 주소를 제공하고, "MX" 레코드는 주어진 도메인에 대한 전자메일 서버 네임을 제공한다.
IETF 표준에 적용될 수 있는 시그널링 변경이 이하에 제공된다. 일반 DNS RR 포맷은 표 4에서와 같다. 그 전체 내용이 참조로 본 명세서에 포함되는, RFC 1035 및 http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml (이하 DNS 파라미터)로부터의 서포트를 참조한다.
Figure 112018011523083-pct00003
이제 IoT 디바이스 휴면 특성을 저장하기 위해 하기 표와 표 5에서와 같이 ("IOTSLEEPINFO"라 불리는) 새로운 DNS RR을 정의한다.
Figure 112018011523083-pct00004
여기서:
1. RR 유형 = IOTSLEEPINFO(이것은 새로운 RR 유형임)
2. 현재 휴면 상태 = 0(깨어 있음), 또는 1(휴면중)
3. 휴면 기간 = IoT 디바이스가 휴면 중일 수 있는 시간 구간(예를 들어, 초)을 나타내는 32 비트 부호없는 정수(또는 다른 길이의 정수). 0 값은 휴면 기간이 알려지지 않았다는 것을 의미한다.
4. 휴면 주기 = 휴면 기간들의 시작 사이의 시간 구간(예를 들어, 초)을 나타내는 16 비트 부호없는 정수. 0 값은 휴면 주기가 알려지지 않았다는 것을 의미할 수 있다.
5. 클래스 = 인터넷
상기에서 정의된 새로운 RR(IOTSLEEPINFO)은, 본 명세서에서 소개된 보통의 인터넷 DNS 인프라스트럭처 또는 새로운 클라우드 DNS-SD 서버에 저장될 수 있다. 따라서, 새로운 RR(IOTSLEEPINFO)은 새로운 클라우드 DNS-SD 서버 뿐만 아니라 고전적인 DNS 인프라스트럭처에도 상당한 가치가 있을 수 있다. 이하(예를 들어, 도 13)에는 휴면 노드를 처리하는 것에 관한 추가적인 논의가 있다.
이하에는 가상 발견 구역 구성을 위한 대안들이 있다. 여기서는, 가상 발견 구역을 생성하고 구성하는 방법에 관한 OAM 기반의 접근법이 제공된다. 대안적인 접근법은, 제어 노드들(예를 들어, IoT DSN-SD 서버, IoT 게이트웨이들) 사이의 시그널링에 기초하여, 이하에서 논의되는 바와 같이, 동적 네트워크 자기-구성(자동) 접근법에 대한 것일 수 있다. 여기서 논의되는 다른 접근법들이 자동으로 수행될 수 있다는 점에 유의한다. 도 10은 도 6의 시스템을 참조하여 가상 발견 구역을 자기-구성하는 예시적인 국면을 나타낸다. 단계 231에서, LAN(170)은 동적으로(자동으로) 형성될 수 있다. 예를 들어, 화재 동안 소방서에 의해 배치되는 802.15 온도 센서 네트워크. 단계 232에서, CoAP POST 요청과 같은 메시지가 전송될 수 있다. 예를 들어, 새로운 IoT LAN(170)이 생성되면, 그 게이트웨이(171)는 LAN(170)이 방금 생성되었다는 것을 통보하는 CoAP 기반의 애플리케이션 메시지를 IoT DNS-SD 서버(165)에 자동으로 전송할 수 있다. 단계 232의 메시지는, LAN(170)에 가상 발견 구역(167)이 할당되어야 한다는 요청을 포함하고 가상 발견 구역(167)을 형성하기 위한 요건을 포함할 수 있다. 단계 232의 메시지는 또한, 물리적 GPS 좌표(예를 들어, 게이트웨이(171) 좌표) 및 LAN(170) 내의 IoT 디바이스(172) 및 IoT 디바이스(173)에 의해 지원되는 키 서비스와 같은 LAN (170)에 관한 정보를 포함할 수 있다. 단계 232의 메시지는 또한, LAN(170)에 의한 물리적 커버리지를 나타낼 수 있다. 물리적 커버리지는 지리적 영역(예를 들어, 건물, GPS 좌표, 도시, 주 등)과 연관될 수 있다. (게이트웨이(171)와 함께 위치한) CoAP RD는, 또 다른 CoAP 기반의 애플리케이션 메시지를 (나중에) 전송하여 LAN(170) 내의 디바이스들에 관한 정보(예를 들어, 그들의 IP 주소) 및 그들의 자원이나 서비스들에 대한 정보를 채울 수 있다. 본 명세서에서 CoAP의 이용은 예시이다. 한 대안은 HTTP 메시지를 사용하여 동일한 기능을 수행하는 것일 것이다.
단계 233에서, IoT DNS-SD 서버(165)는 어느 가상 발견 구역을 LAN(170)과 연관시킬지를 결정한다. 가상 발견 구역은 공통 DNS-SD 서비스 발견 구역이 있는 LAN들의 논리적 그룹화이다. 어느 구역을 새로운 LAN에 할당할지의 결정은 예를 들어 LAN의 GPS 좌표에 관해 이루어질 수 있다. 즉, 클라우드 DNS-SD 서버(IoT DNS-SD 서버(165))는 소정의 지리적 영역을 커버하는 가상 발견 구역을 생성할 수 있다. 또한 액세스 허용, 가입된 서비스와 같은 다른 요인들이 고려될 수도 있다. 복수의 가상 발견 구역이 할당된다면, 단계 234의 메시지는 복수의 식별자 및 복수의 가상 발견 구역들의 각각의 가상 발견 구역에 속하는 디바이스들 또는 서비스들의 목록을 포함할 수 있다. (게이트웨이(171)가 새로이 생성된 LAN(170)을 IoT DNS-SD 서버(165)에 보고하는 프로세스 동안 식별자를 제안할 수 있지만) 가상 발견 구역(167)의 식별자는 IoT DNS-SD 서버(165)에 의해 결정될 수 있고, 예를 들어, 새로운 LAN(170)의 GPS 또는 기타의 좌표 + 그 서비스들의 해시(hash)일 수 있다. 지리는, LAN(170)의 단일의 디바이스, LAN(170)의 디바이스들의 평균이나 기타의 임계 지리(예를 들어, LAN 상의 평균 디바이스들이 지리적 경계에 있음), 주로 게이트웨이(171)의 지리적 위치 등과 연관될 수 있다. 이하는, 새로이 생성된 LAN에 대한 가상 발견 구역을 할당하는 몇 가지 예이다. 제1 예에서, 각각의 가상 발견 구역이 소정의 물리적 영역과 연관될 수 있다. LAN이 그 커버리지 내에 있다면 새로이 생성된 LAN에는 기존의 가상 발견 구역이 할당된다. 제2 예에서, IoT DNS-SD 서버는 2개 이상의 가상 발견 구역을 새로이 생성된 LAN에 할당할 수 있다. 복수의 LAN의 할당에 대한 이유는, LAN의 커버리지가 너무 크거나 사생활보호, 보안 또는 기타의 관심사가 있는 경우와 연관될 수 있다.
단계 234에서, CoAP 기반의 애플리케이션 메시지와 같은 메시지가 전송된다. 이 메시지는 할당된(예를 들어, 가상 발견 구역(167)에 할당된) 가상 발견 구역과 연관된 정보를 포함할 수 있다. 단계 234의 메시지는 할당된 가상 발견 구역(167)의 식별자를 포함할 수 있다. 단계 235에서, LAN(170)은 가상 발견 구역(167)의 할당을 수락 또는 거절할 수 있다.
도 11은 가상 발견 구역을 자기-구성하는 또 다른 예시적인 국면을 나타낸다. 단계 241에서, LAN(170)을 해체(예를 들어, 이전 예에서 화재가 진화된 후 며칠)하거나 LAN(170)을 가상 발견 구역(167)과 연관해제될 것이라는 결정이 있을 수 있다. 예를 들어, 화재 동안 소방서에 의해 배치된 802.15 온도 센서 네트워크는 더 이상 필요하지 않으며 폐기될 것이다. 단계 242에서, 게이트웨이(171)는, CoAP 기반의 애플리케이션 메시지와 같은 메시지를 IoT DNS-SD 서버(165)에 전송한다. 단계 242의 메시지는 LAN(170)이 가상 발견 구역(167)으로부터 연관해제될 것을 요구하는 요청을 포함한다. 한 예에서, (애플리케이션 데이터: - 가상 발견 구역(167)으로부터 LAN(170)의 연관해제 요청). 단계 243에서, IoT DNS-SD 서버(165)는 단계 242의 메시지를 수신하고, 메시지가 정확한 허가를 갖는다면, 가상 발견 구역(167)으로부터 LAN(170)을 적절히 연관해제한다. 단계 244에서, 삭제 또는 다른 고려 사항의 확인을 포함하는 메시지가 전송된다. 단계 244의 메시지는 CoAP DELETE 응답일 수 있다. 단계 245에서, 게이트웨이(171)는 LAN(170)을 해체하거나 IoT DNS-SD 서버(165)로부터 연관해제하는데 필요한 임의의 단계를 계속할 수 있다.
계속 도 11을 참조하면, 기존의 가상 발견 구역에 대한 조정을 야기할 수 있는 몇 가지 경우가 있다. 다음은 몇 가지 예이다. 제1 예에서, IoT 디바이스(172) 또는 그 지원되는 디바이스들이 이용가능하지 않을 때, 대응하는 게이트웨이(171)(또는 CoAP RD)는 CoAP 기반의 애플리케이션 메시지와 같은 메시지를 전송하여 IoT DNS-SD 서버(165)를 업데이트할 수 있다. 그 결과, IoT 디바이스(172) 또는 그 서비스는 IoT DNS-SD 서버(165)에 의해 유지되는 레코드들로부터 제거될 것이다. 제2 예에서, IoT 디바이스(172)가 그 휴면 스케쥴을 변경할 때, 게이트웨이(171)(또는 CoAP RD)는 CoAP 기반의 애플리케이션 메시지를 전송하여 새로운 휴면 정보를 클라우드 DNS-SD 서버에 보고할 것이다. 그 결과, 클라우드 DNS-SD는 DNS-SD 레코드를 업데이트할 것이다. 제3 예에서, LAN(170) 내에서 고려되는 게이트웨이(171) 또는 IoT 디바이스(172)가 그 좌표 또는 물리적 위치를 변경할 때, 게이트웨이(171)(또는 CoAP RD)는 CoAP 기반의 애플리케이션 메시지를 전송하여 새로운 좌표를 IoT DNS-SD 서버(165)에 전송할 것이다. 그 결과, IoT DNS-SD 서버(165)는, 1) 현재의 가상 발견 구역(167)을 게이트웨이(171)에 유지하거나(예를 들어, 물리적 좌표가 많이 변경되지 않으면), 2) 새로운 가상 발견 구역을 게이트웨이(171)에 할당하거나(예를 들어, 새로운 물리적 좌표의 변경이 임계값을 초과하는 경우), 3) 또 다른 기존의 가상 발견 구역과 병합되거나(예를 들어, 새로운 물리적 좌표가 또 다른 기존의 가상 발견 구역과 중첩하는 경우), 또는 4) 기존의 또 다른 가상 발견 구역으로 분할할 수 있다(예를 들어, 새로운 물리적 좌표가 기존의 가상 발견 구역과 중첩하고 그 곳에 이미 너무 많은 디바이스가 있는 경우). 게이트웨이(171) 또는 LAN(170) 내의 다른 디바이스들은 가상 발견 구역의 할당을 거부할 수 있다.
도 12는 휴면 노드 처리를 포함할 수 있는 예시적인 광역 서비스 발견 구현을 나타낸다. 예시적인 시나리오는 복수의 LAN에 걸친 도시 전역 배치를 동반한 스마트 그리드 운영자를 위한 휴면 노드 처리를 포함할 수 있다. 대안으로서, 이것은, 도시 전역 배치를 위해 함께 협력하고 있는 협력 스마트 그리드 운영자들의 그룹(각자는 제한된 수의 LAN을 소유함)일 수 있다. 이하에서 더 상세하게 논의되는 도 12의 정황은, 주로 IETF 관련 시그널링, 및 광역 서비스 발견을 지원하는데 사용되는 노드들 내의 연관된 처리 로직에 중점을 둔다.
예시의 목적을 위해, 다음과 같은 시나리오에서 도 12를 고려한다. LAN(170)(예를 들어, 주어진 이웃을 커버하는 로컬 네트워크) 내의 가정용 계량기(예를 들어, IoT 디바이스(172))는 현재 전기 요금 (비용) 정보를 위해 폴링하기 위해 휴면 중에 있지 않은(예를 들어, 깨어있는) 전기 요금 (비용) 서버를 발견할 필요가 있다. 가정용 계량기는 정기적으로 이를 수행하여 주택 소유자에게 최신 요금 정보를 디스플레이할 필요가 있다. 제어기(예를 들어, 제어기(174) 또는 제어기(183))라고 불리는 소정의 디바이스들은 요금 정보를 제공할 수 있다.
앞서 언급된 계량기-제어기 시나리오를 참조하여, 도 13은 앞서 언급된 "IOTSLEEPINFO"라 불리는 DNS RR을 사용하여 휴면 노드 시나리오를 처리하기 위한 예시적인 흐름을 나타낸다. 단계 251에서, "요금 정보 서버"에 대한 요청이 전송된다. 단계 252에서, 게이트웨이(171)는 RD를 체크하고 LAN(170) 내에서 서비스를 찾으려고 시도한다. 단계 253에서, 게이트웨이(171)는 요금 정보가 제어기(174)에 있다는 사실을 제공하는 응답을 전송한다. 응답은 또한, 제어기(174)에 관한 휴면 정보(예를 들어, IOTSLEEPINFO - 표 5)를 제공하는 DNS RR을 포함할 수 있다. 단계 254에서, IoT 디바이스(172)(예를 들어, 가정용 계량기)는 새로운 IOTSLEEPINFO RR을 체크하고 제어기(174)가 현재 휴면 중이라고 결정한다. 단계 255에서, "요금 정보 서버"를 찾는 요청을 포함하는 메시지가 전송된다. 단계 255에서의 요청은 단계 251의 요청과 유사할 수 있다. 단계 256에서, 게이트웨이(171)는 응답이 단계 253에서 RD로부터 제공되었다고 결정할 수 있으므로, 다음 단계는 IoT DNS-SD 서버(165)에 질의하는 것이다.
도 13을 계속 참조하면, 단계 257에서, 가상 발견 구역(167)에 위치한 "요금 정보 서버"에 대한 요청을 포함하는 메시지가 전송된다. 단계 258에서, IoT DNS-SD 서버(165)는 제어기(183)가 "요금 정보 서버"로서 이전에 등록되었다고 결정한다.
단계 259에서, 또 다른 "요금 정보 서버"(예를 들어, 제어기(183)@74.125.224.72)에 대한 콘택 정보(예를 들어, IP 주소)를 포함하는 메시지가 전송된다. 단계 260에서, 단계 259의 정보가 IoT 디바이스(172)에 포워딩된다. 단계 261에서, IoT 디바이스(172)는 제어기(183)가 깨어 있다고 결정한다. 이러한 깨어 있는 상태는 단계 260의 메시지를 동반하는 DNS RR을 조사함으로써 결정될 수 있다. 단계 262에서, 현재의 전기 요금을 요청하는 메시지가 전송된다.
메시지는 CoAP GET 요청일 수 있다. 단계 263에서, IoT 디바이스(172)는 단계 262로부터의 것을 나타내는 메시지를 수신할 수 있다. 단계 263의 메시지는 현재의 전기 요금 데이터와 함께 CoAP GET 응답을 포함할 수 있다.
계속 도 12 및 도 13을 참조하여, 이하에서는, 앞서 언급된 계량기 휴면 시나리오에 대한 추가 고려 사항이 제공된다. 가정용 계량기(IoT 디바이스(172))로부터 게이트웨이(171)로의 DNS-SD 질의일 수 있는 단계 251의 요청은, 동일한 LAN(170) 내의 제어기(174)가 요금 정보를 제공하는 요구된 서비스를 지원함을 알게 한다. 그러나, 단계 253의 메시지에 포함될 수 있는 "IOTSLEEPINFO" RR은, 제어기(174)가 현재 휴면 중이고 허용가능한 임계값보다 긴 시간 동안 휴면을 계속할 것이라는 것을 나타낸다. 단계 255에서, 또 다른 요청(DNS-SD 질의)이 게이트웨이(171)에게 이루어질 수 있다. 단계 256에서, 이전의 요청들이 고려된다. 게이트웨이(171)는 (소정의 캐싱 기간 동안) 이전의 질의들을 추적할 필요가 있으며, 최근에 유사한 질의에 대한 응답이 제공된 것을 알고 있다. 따라서, 이전의 응답은 만족스럽지 않은 것으로 가정하여, 이제 IoT DNS-SD 서버(165)에게 질의하여 가상 발견 구역(167) 내의 어떤 다른 곳의 다른 요금 정보 서버를 찾는다. 대안으로서, 단계 252 내지 단계 255는 스킵될 수 있고 게이트웨이(171)는 요청된 요금 정보를 위해 또 다른 제어기에 질의할지를 결정하기 위해 적절한 DNS RR(IOTSLEEPINFO) 및 다른 선호사항을 직접 조사할 수 있다.
IoT DNS-SD 서버(165)가 단계 257의 질의를 수신하면, 단계 258에서, 이 특정한 질의를 위해 탐색하기를 원하는 가상 발견 구역에 관한 결정을 내려야 할 것이다. 이것은, 예를 들어, (단계 257의 질의를 운반하는 메시지에 포함될 수 있는) 게이트웨이(171)의 발신 IP 주소를 조사함으로써 달성될 수 있다. 한 예에서, 게이트웨이(171)의 IP 주소로부터, IoT DNS-SD 서버(165)는 자신의 내부 데이터 구조에 의해 가상 발견 구역으로의 RR의 매핑을 결정할 수 있다. 본 명세서에서 언급된 바와 같이, 가상 발견 구역들은 게이트웨이들(및 이들의 대응하는 디바이스들)의 그룹과 클라우드 DNS-SD 서버(예를 들어, IoT DNS-SD 서버(165)) 사이의 관계로서 정의된다. 도 13에 나타낸 바와 같이, IoT DNS-SD 서버는 상이한 LAN(LAN(180)) 내의 다른 요금 정보 서버(예를 들어, 제어기(183))로 단계 259에서 응답한다. 계량기는 이 제어기(180)가 현재 IOTSLEEPINFO RR에 대해 휴면 중이지 않아서 제어기에 직접 질의하고 원하는 요금 정보를 얻을 수 있다는 것을 알 수 있다. 대안으로서, 전술된 바와 같이, 계량기(IoT 디바이스(172))는 IOTSLEEPINFO RR을 수신하지 못할 수도 있고, IoT DNS-SD 서버(165)에 의해 제공된 주소에 그 요청을 전송할 수도 있다.
도 14는 여기서 논의된 광역 서비스 발견과 관련된 예시적인 그래픽 사용자 인터페이스를 나타낸다. 디스플레이(270)(또한 디스플레이(42))는 사용자가 IoT DNS-SD 서버(165)의 OAM 시스템의 일부와 인터페이스하는 것을 허용할 수 있다. 디스플레이(270)는 터치 스크린일 수 있고 IoT DNS-SD 서버(165)의 제공자가 그 연관된 가상 발견 구역을 그래픽으로 디스플레이하는 것을 허용한다. 디스플레이(270)의 272에서, 예를 들어, 도 12, 도 6 등에 도시된 바와 같이, 주어진 가상 발견 구역에 포함된 LAN들의 그래픽 보기를 제공한다. 디스플레이(270)의 271에서, 여기서 논의된 바와 같이, 광역 서비스 발견과 연관된 명령, 변수, 입력, 출력, 흐름, 성공 및 실패의 텍스트 표현이 있을 수 있다. 다음은 그 예이다 : 가상 발견 구역 167 = {IoT DNS-SD 서버 165, LAN 170, LAN 180}. 가상 발견 구역은 OAM에 의해 또는 다른 방식으로 동적으로 생성되었을 수 있다.
또한, IoT DNS-SD 서버(165)의 제공자는 LAN들의 다양한 소유자들에 의한 가상 발견 구역들의 원격 뷰를 허용할 수 있다. 이들 뷰들은, LAN의 소유자가 랩탑이나 스마트 폰에서 암호 또는 기타 보안 증서를 사용하여 액세스할 수 있는 웹 인터페이스를 통해 볼 수 있다. 한 예에서, 도 12와 유사한 정황에서, 개개의 LAN은 (도시 전역 배치를 위해 함께 협력하고 있는) 상이한 스마트 그리드 운영자들에 의해 소유되었다고 가정한다. 운영자-A는, LAN-1, LAN-2 및 LAN-3(미도시)을 소유하고, 운영자 -B는 LAN-4 및 LAN-5를 소유한다. 그 다음, 운영자-A 또는 운영자-B 중 하나는 (도 12와 유사한) 가상 발견 구역의 그래픽 뷰 또는 텍스트 표현을 얻을 수 있다.
도 15a는, 광역 서비스 발견과 연관된 하나 이상의 개시된 개념(예를 들어, 특히, 도 6 내지 도 14)이 구현될 수 있는 예시적인 머신-대-머신(M2M), 사물의 인터넷(IoT) 또는 사물의 웹(WoT) 통신 시스템(10)의 도면이다. 일반적으로, M2M 기술은, IoT/WoT를 위한 구축 블록들을 제공하며, 임의의 M2M 디바이스, 또는 M2M 게이트웨이는 IoT/WoT의 컴포넌트일 수 있다.
도 15a에 도시된 바와 같이, M2M/IoT/WoT 통신 시스템(10)은 통신 네트워크(12)를 포함한다. 통신 네트워크(12)는, 고정된 네트워크(예를 들어, Ethernet, Fiber, ISDN, PLC 등) 또는 무선 네트워크(예를 들어, WLAN, 셀룰러 등) 또는 이종 네트워크들의 네트워크일 수 있다. 예를 들어, 통신 네트워크(12)는, 음성, 데이터, 비디오, 메시징, 브로드캐스트 등과 같은 콘텐츠를 복수의 사용자에게 제공하는 복수의 액세스 네트워크로 구성될 수 있다. 예를 들어, 통신 네트워크(12)는, CDMA(code division multiple access) TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), 단일 캐리어 FDMA(SC-FDMA) 등과 같은 하나 이상의 채널 액세스 방법을 사용할 수 있다. 또한, 통신 네트워크(12)는, 예를 들어, 코어 네트워크, 인터넷, 센서 네트워크, 산업용 제어 네트워크, 개인 영역 네트워크, 융합된 개인 네트워크, 위성 네트워크, 홈 네트워크, 또는 기업 네트워크와 같은 다른 네트워크들을 포함할 수 있다.
도 15a에 도시된 바와 같이, M2M/ IoT/WoT 통신 시스템(10)은 인프라스트럭처 도메인(Infrastructure Domain) 및 필드 도메인(Field Domain)을 포함할 수 있다. 인프라스트럭처 도메인이란 단-대-단 M2M 배치의 네트워크측을 말하고, 필드 도메인이란, 대개는 M2M 게이트웨이 뒤쪽의, 영역 네트워크(area network)를 말한다. 필드 도메인은 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 디바이스(18)와 게이트웨이(14)는, 예를 들어, 셀룰러, WLAN, WPAN(예를 들어, Zigbee, 6LoWPAN, Bluetooth), 직접 무선 링크, 및 와이어라인을 포함한 다양한 네트워크를 통해 통신할 수 있다.
도 15b는, 광역 서비스 발견에서 사용될 수 있는 M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14)와 같은 예시적인 M2M 디바이스(30)의 시스템도이다. 도 15b에 도시된 바와 같이, M2M 디바이스(30)는, 프로세서(32), 트랜시버(34), 전송/수신 요소(36), 스피커/마이크로폰(38), 키패드(40), 디스플레이/터치패드(42), 비이동식 메모리(44), 이동식 메모리(46), 전원(48), GPS(global positioning system) 칩셋(50), 및 기타의 주변기기(52)를 포함할 수 있다. M2M 디바이스(30)는 개시된 주제와 일관성을 유지하면서 전술된 요소들의 임의의 하위-조합을 포함할 수 있다는 것을 이해할 것이다. M2M 디바이스(30)(예를 들어, IoT 디바이스(172), 제어기(174), 게이트웨이(171), IoT DNS-SD 서버(165) 등)는 광역 서비스 발견을 위한 개시된 시스템 및 방법을 수행하는 예시적인 구현일 수 있다.
프로세서(32)는, 범용 프로세서, 특별 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(digital signal processor)(DSP), 복수의 마이크로프로세서, DSP 코어와 연계한 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 주문형 집적 회로(Application Specific Integrated Circuit)(ASIC), 필드 프로그래머블 게이트 어레이(Field Programmable Gate Array)(FPGA) 회로, 기타 임의 타입의 집적 회로(IC), 상태 머신 등일 수 있다. 프로세서(32)는, 신호 코딩, 데이터 처리, 전력 제어, 입력/출력 처리, 및/또는 M2M 디바이스(30)가 무선 환경에서 동작할 수 있게 하는 기타 임의의 기능을 수행할 수 있다. 프로세서(32)는, 전송/수신 요소(36)에 결합될 수 있는 트랜시버(34)에 결합될 수 있다. 도 15b는 프로세서(32)와 트랜시버(34)를 별개의 컴포넌트로서 도시하고 있지만, 프로세서(32)와 트랜시버(34)는 전자 팩키지 또는 칩 내에 함께 통합될 수도 있다는 것을 이해할 것이다. 프로세서(32)는 애플리케이션-계층 프로그램(예를 들어, 브라우저) 또는 무선 액세스-계층(RAN) 프로그램 또는 통신을 수행할 수 있다. 프로세서(32)는, 인증, 보안 키 협의와 같은 보안 동작 또는 예를 들어, 액세스-계층 또는 애플리케이션 계층에서의 암호 동작을 수행할 수 있다.
전송/수신 요소(36)는, M2M 플랫폼(22)에 신호를 전송하거나 이로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 전송/수신 요소(36)는 RF 신호를 전송 또는 수신하도록 구성된 안테나일 수 있다. 전송/수신 요소(36)는, WLAN, WPAN, 셀룰러 등과 같은 다양한 네트워크 및 에어 인터페이스를 지원할 수 있다. 한 예에서, 전송/수신 요소(36)는, 예를 들어, IR, UV, 또는 가시광 신호를 전송 또는 수신하도록 구성된 방출기/검출기일 수도 있다. 역시 또 다른 예에서, 전송/수신 요소(36)는 RF 및 광 신호 양쪽 모두를 전송 및 수신하도록 구성될 수 있다. 전송/수신 요소(36)는 임의 조합의 무선 또는 유선 신호를 전송 또는 수신하도록 구성될 수 있다는 것을 이해할 것이다.
또한, 전송/수신 요소(36)가 도 15b에서는 단일 요소로서 도시되어 있지만, M2M 디바이스(30)는 임의 개수의 전송/수신 유닛(36)을 포함할 수 있다. 더 구체적으로는, M2M 디바이스(30)는 MIMO 기술을 채용할 수도 있다. 따라서, 한 예에서, M2M 디바이스(30)는, 무선 신호를 전송 및 수신하기 위한 2개 이상의 전송/수신 요소(36)(예를 들어, 복수의 안테나)를 포함할 수도 있다.
트랜시버(34)는, 전송/수신 요소(36)에 의해 전송되는 신호를 변조하고 전송/수신 유닛(36)에 의해 수신되는 신호를 복조하도록 구성될 수 있다. 앞서 언급한 바와 같이, M2M 디바이스(30)는 멀티-모드 능력을 가질 수도 있다. 따라서, 트랜시버(34)는, M2M 디바이스(30)가, 예를 들어, UTRA 및 IEEE 802.11과 같은 복수의 RAT를 통해 통신할 수 있게 하기 위한 복수의 트랜시버를 포함할 수 있다.
프로세서(32)는, 비이동식 메모리(44) 또는 이동식 메모리(46)와 같은 임의의 타입의 적절한 메모리로부터 정보를 액세스하거나, 여기에 데이터를 저장할 수도 있다. 비이동식 메모리(44)는, 랜덤 액세스 메모리(RAM), 판독-전용 메모리(ROM), 하드 디스크, 또는 기타 임의 타입의 메모리 저장 디바이스를 포함할 수 있다. 이동식 메모리(46)는, 가입자 신원 모듈(subscriber identity module)(SIM), 메모리 스틱, 보안 디지털(secure digital)(SD) 메모리 카드 등을 포함할 수 있다. 다른 예들에서, 프로세서(32)는, 서버 또는 가정용 컴퓨터와 같은, M2M 디바이스(30)에 물리적으로 위치해 있지 않은 메모리로부터 정보를 액세스하거나, 여기서 데이터를 저장할 수도 있다. 프로세서(32)는 본 명세서에서 설명된 예들 중 일부에서 LMS가 성공적인지 또는 실패인지(예를 들어, IOTSLEEPINFO RR 또는 LAN 외부이지만 가상 발견 구역 내의 디바이스에 도달)에 응답하여 디스플레이 또는 표시기(42) 상의 점등 패턴, 이미지 또는 색상을 제어하거나, 가상 발견 구역 또는 연관된 방법 및 컴포넌트들의 상태를 나타내도록 구성될 수 있다. 디스플레이 또는 표시기(42) 상의 제어 점등 패턴, 이미지 또는 색상은, 본 명세서에서 예시되거나 논의된 도면들(예를 들어, 도 6 내지 도 14 등)에서의 방법 흐름들 또는 컴포넌트들 중 임의의 것의 상태를 반영할 수 있다. 본 명세서에는, 광역 서비스 발견의 메시지 및 절차가 개시된다. 메시지 및 절차는 사용자가 입력 소스(예를 들어, 스피커/마이크로폰(38), 키패드(40) 또는 디스플레이/터치 패드(42))를 통해 광역 서비스 발견 관련 정보를 요청하고, 특히, 디스플레이(42) 상에 디스플레이될 수 있는 광역 서비스 발견 정보를 요청, 구성, 또는 질의하기 위한 인터페이스/API를 제공하도록 확장될 수 있다.
프로세서(32)는, 전원(48)으로부터 전력을 수신할 수 있고, M2M 디바이스(30) 내의 다른 컴포넌트들에 전력을 분배 및/또는 전력을 제어하도록 구성될 수 있다.
전원(48)은 M2M 디바이스(30)에 전력을 공급하기 위한 임의의 적절한 장치일 수 있다. 예를 들어, 전원(48)은, 하나 이상의 건식 셀 배터리(예를 들어, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬-이온(Li-ion) 등), 태양 전지, 연료 전지 등을 포함할 수 있다.
프로세서(32)는 또한, M2M 디바이스(30)의 현재 위치에 관한 위치 정보(예를 들어, 경도 및 위도)를 제공하도록 구성된 GPS 칩셋(50)에 결합될 수 있다. M2M 디바이스(30)는 본 명세서에서 개시된 정보와 여전히 일치되면서 임의의 적절한 위치-결정 방법을 통해 위치 정보를 취득할 수 있다는 점을 이해할 것이다.
프로세서(32)는 또한, 추가적인 피쳐, 기능 또는 유선이나 무선 접속을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수도 있는 다른 주변기기(52)에도 결합될 수도 있다. 예를 들어, 주변기기(52)는, 가속도계, e-나침반, 위성 트랜시버, 센서, (사진 또는 비디오용) 디지털 카메라, USB(Universal Serial Bus) 포트, 진동 디바이스, 텔레비전 트랜시버, 핸즈프리 헤드셋, Bluetooth® 모듈, 주파수 변조(FM) 무선 유닛, 디지털 음악 재생기, 매체 재생기, 비디오 게임 플레이어 모듈, 인터넷 브라우저 등을 포함할 수 있다.
전송/수신 요소(36)는, 센서, 가전 제품과 같은 다른 장치 또는 디바이스, 스마트 시계 또는 스마트 의류와 같은 웨어러블 디바이스, 의료 또는 e헬스(eHealth) 디바이스, 로봇, 산업 장비, 드론, 자동차, 트럭, 기차 또는 비행기와 같은 운송 수단에서 구체화될 수 있다. 전송/수신 요소(36)는, 주변기기들(52) 중 하나를 포함할 수 있는 상호접속 인터페이스와 같은, 하나 이상의 상호접속 인터페이스를 통해 이러한 장치나 디바이스의 다른 컴포넌트들, 모듈들, 또는 시스템들에 접속될 수 있다.
도 15c는, 예를 들어, 도 15a의 플랫폼이 구현될 수 있는 예시적인 컴퓨팅 시스템(90)의 블록도이다. 컴퓨팅 시스템(90)(예를 들어, M2M 단말 디바이스(18) 또는 M2M 게이트웨이 디바이스(14))은 컴퓨터 또는 서버를 포함할 수 있고, 주로, 소프트웨어 형태일 수 있는 컴퓨터 판독 가능한 명령어에 의해, 또는 심지어, 이러한 소프트웨어가 저장되거나 액세스되는 어떠한 수단에 의해 제어될 수 있다. 이러한 컴퓨터 판독 가능한 명령어는 중앙 처리 장치(CPU)(91) 내에서 실행되어 컴퓨팅 시스템(90)이 작업을 할 수 있게 한다. 많은 공지된 워크스테이션, 서버 및 개인용 컴퓨터에서, 중앙 처리 유닛(91)은 마이크로프로세서라 불리는 단일-칩 CPU에 의해 구현된다. 다른 머신들에서, 중앙 처리 유닛(91)은 복수의 프로세서를 포함할 수도 있다. 코프로세서(81)는, 추가적인 기능을 수행하거나 CPU(91)를 보조하는, 메인 CPU(91)와는 별개의, 선택사항적 프로세서이다. CPU(91) 또는 코프로세서(81)는 DNS-SD 질의를 수신하는 것과 같은, 광역 서비스 발견을 위한 개시된 시스템 및 방법에 관련된 데이터를 수신, 생성 및 처리할 수 있다.
동작시, 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)은, 도 15a의 네트워크(12)와 같은, 외부 통신 네트워크에 컴퓨팅 시스템(90)을 접속하는데 사용될 수 있는 네트워크 어댑터(97)를 포함할 수 있다.
도 15d를 참조하여, 필드 도메인 내의 예시된 M2M 서비스 계층(22)은, M2M 애플리케이션(20)(예를 들어, IoT 디바이스(172)의 애플리케이션), 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')은 하나 이상의 서버, 컴퓨터, 가상 머신(예를 들어, 클라우드/계산/스토리지 팜(farm) 등) 등에 의해 구현될 수 있다.
또한 도 15d를 참조하면, M2M 서비스 계층들(22 및 22')은 다양한 애플리케이션 및 버티컬(vertical)이 사용할 수 있는 핵심 세트의 서비스 전달 능력을 제공한다. 이들 서비스 능력들은 M2M 애플리케이션들(20 및 20')이 디바이스들과 상호작용하고, 데이터 수집, 데이터 분석, 디바이스 관리, 보안, 요금청구, 서비스/디바이스 발견 등의 기능을 수행할 수 있게 한다. 본질적으로, 이들 서비스 능력은 애플리케이션으로부터 이들 기능들을 구현하는 부담을 제거하므로, 애플리케이션 개발을 간소화하고 출시를 위한 비용과 시간을 줄인다. 서비스 계층들(22 및 22')은 또한, M2M 애플리케이션들(20 및 20')이, 서비스 계층들(22 및 22')이 제공하는 서비스와 관련하여 다양한 네트워크들(12 및 12')을 통해 통신하게 할 수 있다.
일부 예에서, M2M 애플리케이션들(20 및 20')은, 본 명세서에서 논의된 바와 같이, 광역 서비스 발견을 사용하여 통신하는 바람직한 애플리케이션들을 포함할 수 있다. M2M 애플리케이션들(20 및 20')은, 제한없이, 수송, 건강 및 웰빙, 접속된 홈, 에너지 관리, 자산 추적, 및 보안 및 감시와 같은, 다양한 산업에서의 애플리케이션을 포함할 수 있다. 앞서 언급된 바와 같이, M2M 서비스 계층, 디바이스들에 걸친 실행, 게이트웨이, 및 시스템의 기타의 서버들은, 예를 들어, 데이터 수집, 디바이스 관리, 보안, 요금청구, 위치 추적/지오펜싱(geofencing), 디바이스/서비스 발견, 및 레거시 시스템 통합과 같은 기능을 지원하고, 이들 기능을 서비스로서 M2M 애플리케이션(20 및 20')에 제공한다.
본 출원의 광역 서비스 발견은 서비스 계층의 일부로서 구현될 수 있다. 서비스 계층은, 한 세트의 애플리케이션 프로그래밍 인터페이스(API)와 기저 네트워킹 인터페이스를 통해 가치-부가된 서비스 능력을 지원하는 미들웨어 계층이다. M2M 엔티티(예를 들어, 하드웨어 상에 구현되는 디바이스, 게이트웨이 또는 서비스/플랫폼과 같은 M2M 기능 엔티티)는 애플리케이션 또는 서비스를 제공할 수 있다. ETSI M2M과 oneM2M 양쪽 모두 본 출원의 광역 서비스 발견을 포함할 수 있는 서비스 계층을 사용한다. oneM2M 서비스 계층은 한 세트의 공통 서비스 기능(Common Service Function)(CSF)(즉, 서비스 능력)을 지원한다. 한 세트의 하나 이상의 특정한 타입의 CSF의 구체화는 상이한 타입의 네트워크 노드들(예를 들어, 인프라스트럭처 노드, 중간 노드, 애플리케이션-특정 노드) 상에서 호스팅될 수 있는 공통 서비스 엔티티(Common Services Entity)(CSE)라고 언급된다. 또한, 본 출원의 광역 서비스 발견은, 서비스 중심 아키텍처(Service Oriented Architecture)(SOA) 및/또는 자원 중심 아키텍처(resource-oriented architecture)(ROA)를 사용하여 본 출원의 광역 서비스 발견과 같은 서비스들에 액세스하는 M2M 네트워크의 일부로서 구현될 수 있다.
본 명세서에서 논의된 바와 같이, 용어 "서비스 계층"은 네트워크 서비스 아키텍처 내의 기능 계층으로서 간주될 수 있다. 서비스 계층은, 통상반적으로 HTTP, CoAP 또는 MQTT와 같은 애플리케이션 프로토콜 계층 위에 있으며, 클라이언트 애플리케이션에 부가 가치 서비스를 제공한다. 서비스 계층은 또한, 예를 들어 제어 계층 및 전송/액세스 계층과 같은 하위 자원 계층에서 코어 네트워크에 대한 인터페이스를 제공한다. 서비스 계층은, 서비스 정의, 서비스 런타임 가능화, 정책 관리, 액세스 제어, 및 서비스 클러스터링을 포함한 복수의 범주의 (서비스) 능력 또는 기능을 지원한다. 최근에는, 몇몇 업계 표준 기관, 예를 들어 oneM2M이, M2M 유형의 디바이스들 및 애플리케이션들의 인터넷/웹, 셀룰러, 엔터프라이즈, 및 홈 네트워크 등의 배치로의 통합과 연관된 문제를 해결하기 위해 M2M 서비스 계층을 개발해 왔다. M2M 서비스 계층은, CSE 또는 서비스 능력 계층(Service Capability Layer, SCL)이라고 지칭될 수 있는 서비스 계층에 의해 지원되는 위에서 언급된 능력 또는 기능의 모음 또는 집합에 대한 액세스를 애플리케이션 또는 다양한 디바이스에 제공할 수 있다. 몇 가지 예는, 보안, 과금, 데이터 관리, 디바이스 관리, 발견, 프로비저닝, 및 다양한 애플리케이션에 의해 흔하게 사용될 수 있는 접속 관리를 포함하지만, 이것으로 제한되는 것은 아니다. 이러한 능력 또는 기능은 M2M 서비스 계층에 의해 정의된 메시지 포맷, 자원 구조 및 자원 표현을 사용하는 API를 통해 이러한 다양한 애플리케이션에 이용가능하게 된다. CSE 또는 SCL은, 하드웨어 또는 소프트웨어로 구현될 수 있고 다양한 애플리케이션 또는 디바이스(예를 들어, 이러한 기능 엔티티들 사이의 기능 인터페이스들)에 노출된 능력 또는 기능을 제공(서비스)하여 다양한 애플리케이션 또는 디바이스가 이러한 능력 또는 기능을 사용하게 하는 기능 엔티티이다.
여기서 설명된 시스템들, 방법들, 및 프로세스들 중 임의의 것 또는 전부는 컴퓨터 판독 가능한 저장 매체에 저장된 컴퓨터 실행 가능한 명령어(즉, 프로그램 코드)의 형태로 임베딩될 수 있고, 명령어는, 컴퓨터, 서버, M2M 단말 디바이스, M2M 게이트웨이 디바이스와 같은 머신에 의해 실행될 때, 여기서 설명된 시스템, 방법, 및 프로세스를 수행 및/또는 구현한다는 것을 이해할 것이다. 구체적으로는, 전술된 단계들, 동작들 또는 기능들 중 임의의 것은 이러한 컴퓨터 실행 가능한 명령어의 형태로 구현될 수 있다. 컴퓨터 판독 가능한 저장 매체는, 정보 저장을 위한 임의의 방법이나 기술로 구현된 휘발성 및 비휘발성의, 이동식 또는 비이동식 매체 양쪽 모두를 포함하지만, 이러한 컴퓨터 판독 가능한 저장 매체는 신호를 포함하지 않는다. 컴퓨터 판독 가능 매체로서는, RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타의 메모리 기술, CD-ROM, DVD, 또는 기타의 광학 디스크 스토리지, 자기 카셋트, 자기 테이프, 자기 디스크 저장 또는 기타의 자기 저장 디바이스, 또는 컴퓨터에 의해 액세스될 수 있고 원하는 정보를 저장하는데 사용될 수 있는 기타 임의의 물리적 매체가 포함되지만, 이것으로만 제한되는 것은 아니다.
본 개시내용의 주제 ―광역 서비스 발견― 의 바람직한 방법, 시스템, 또는 장치를 설명하는데 있어서, 도면들에 예시된 바와 같이, 특정한 전문용어는 명료성을 위해 채용된 것이다. 그러나, 청구 대상은 이와 같이 선택된 특정한 전문용어로 제한되고자 함은 아니고, 각각의 특정한 요소는 유사한 목적을 달성하는 유사한 방식으로 동작하는 모든 기술적 균등물을 포함한다는 것을 이해해야 한다. 본 개시내용은, IoT 이용 사례들에 대해 제안된 솔루션을 이용하는 것에 중점을 둔다는 점에 유의해야 한다. 그러나, 본 발명은 유사한 속성을 갖는 비-IoT 시나리오에도 적용될 수 있다는 것을 자명하다.
본 명세서에서 설명된 다양한 기술들은, 하드웨어, 펌웨어, 소프트웨어, 또는 적절한 경우, 이들의 조합과 연계하여 구현될 수 있다. 이러한 하드웨어, 펌웨어 및 소프트웨어는, 통신 네트워크의 다양한 노드들에 위치한 장치들에 상주할 수 있다. 이 장치들은 본 명세서에서 설명된 방법을 수행하기 위해 단독으로 또는 서로 조합하여 작동할 수 있다. 본 명세서에서 사용될 때, 용어 "장치", "네트워크 장치", "노드", "디바이스", "네트워크 노드" 등은 서로 바꾸어 사용될 수 있다.
상기의 설명은, 최상의 모드를 포함한 본 발명을 개시하고 또한 본 기술분야의 통상의 기술자가, 임의의 디바이스 또는 시스템을 제작하고 사용하며 임의의 포함된 방법을 수행하는 것을 포함한, 본 발명을 실시할 수 있게 하는 예들을 사용하고 있다. 본 발명의 특허가능한 범위는, 청구항들에 의해 정의되며, 본 기술분야의 통상의 기술자에게 가능한 다른 예(예를 들어, 단계를 건너 뛰거나, 단계들을 결합하거나, 본 명세서에 개시된 예시적인 방법들 사이에 단계들을 추가하는 것)를 포함할 수 있다. 이러한 다른 예들은, 청구항의 자구(literal language)와 상이하지 않은 구조적 요소를 포함하거나, 청구항의 자구와 사소한 차이를 갖는 균등한 구조적 요소를 포함한다면, 청구항의 범위 내에 드는 것이다.
특히, 본 명세서에서 설명된 방법, 시스템, 및 장치는, 광역 서비스 발견을 위한 수단을 디바이스들에 제공할 수 있다. 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 제1 로컬 영역 네트워크 상에서 제1 메시지 ―제1 메시지는 서비스에 대한 요청을 포함함― 를 수신하고; 서비스가 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정하며; 서비스가 제1 로컬 영역 네트워크 상에 위치하지 않는다는 결정에 응답하여, 서비스에 대한 요청을 포함하는 제2 메시지를 서버에 제공하고; 서비스와 연관된 정보를 포함하는 제3 메시지를 수신하기 위한 수단을 갖는다. 제1 메시지는, 서비스에 대한 요청을 포함하는 복수의 메시지들 중 하나일 수 있고, 복수의 메시지는 멀티캐스트 DNS에 의해 전송될 수 있다. 서버는 DNS-SD를 위한 서버로서 작동할 수 있다. 서비스와 연관된 정보는 서비스의 주소를 포함할 수 있다. 서비스와 연관된 정보는 서비스의 가용성 표시를 포함할 수 있다. 서비스는 원격 디바이스 상에 위치할 수 있고 원격 디바이스는 제2 로컬 영역 네트워크 상에 위치할 수 있다. 서버는 광역 네트워크에 위치할 수 있다. 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 서비스와 연관된 정보를 클라이언트 디바이스에 제공하기 위한 수단을 가지며, 클라이언트 디바이스는 제1 메시지를 통해 서비스의 요청자임을 나타낸다. 제1 메시지는 DNS-SD 질의일 수 있다. 제3 메시지는 제2 메시지에 대한 DNS-SD 응답일 수 있다. 방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 제한된 애플리케이션 프로토콜(CoAP) 자원 디렉토리의 질의에 기초하여 서비스가 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정하기 위한 수단을 갖는다. 제2 메시지는 가상 발견 구역의 할당을 위한 요청을 포함할 수 있다. 제3 메시지는 가상 발견 구역의 할당을 포함할 수 있다. (단계들의 제거 또는 추가를 포함한) 이 단락의 모든 조합은, 상세한 설명의 다른 부분들과 일치하는 방식으로 고려된다.
방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 서비스에 대한 DNS-SD 질의를 제1 LAN으로부터 수신하고; DNS-SD 질의를 수신하는 것에 응답하여, 제2 LAN 상에서 서비스에 관한 정보를 제공하기 위한 수단을 갖는다.
방법, 시스템, 컴퓨터 판독 가능한 저장 매체, 또는 장치는, 서비스에 대한 요청을 제공하고; 요청에 대한 응답을 수신하기 위한 수단을 가지며, 응답은 서비스와 연관된 디바이스에 관한 휴면 노드 정보를 포함한다.
본 명세서에서 설명된 주제는 예시로서 제공된 것이다. 예시되고 설명된 예와 응용을 따르지 않고(예를 들어, 단계들을 건너 뛰거나 추가하는 것), 및 개시된 주제의 진정한 사상과 범위를 벗어나지 않고, 본 명세서에서 설명된 주제에 대한 다양한 수정 및 변경이 이루어질 수 있다.

Claims (20)

  1. 장치로서,
    프로세서; 및
    상기 프로세서에 결합된 메모리
    를 포함하고, 상기 메모리는, 상기 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 동작들을 수행하게 하는 실행 가능한 명령어들을 포함하며,
    상기 동작들은:
    제1 로컬 영역 네트워크 상에서 제1 디바이스로부터 제1 메시지 - 상기 제1 메시지는 서비스에 대한 도메인 네임 시스템-서비스 발견(domain name system-service discovery)(DNS-SD) 질의를 포함함 - 를 수신하는 동작;
    상기 서비스가 상기 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정하는 동작;
    상기 서비스가 상기 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정한 것에 응답하여, 상기 서비스에 대한 DNS-SD 질의를 포함하는 제2 메시지를 서버에 제공하는 동작
    - 상기 서버는 가상 발견 구역(virtual discovery zone) 상에서 DNS-SD 서버로서 동작하고 상기 가상 발견 구역에서의 서비스들을 위한 서비스 발견 질의들에 응답하도록 구성되고, 그리고
    - 상기 가상 발견 구역은 전체 가상 발견 구역에서의 서비스들에 대한 서비스 발견들을 가능하게 하는 공통 DNS-SD 서비스 발견 구역이 있는 로컬 영역 네트워크들의 논리적 그룹화임-; 및
    요청된 서비스가 가상 발견 구역 내의 다른 곳에서 발견되었다는 결정에 응답하여, 상기 DNS-SD 서버로부터 상기 제2 메시지에 대한 DNS-SD 응답을 포함하는 제3 메시지를 수신하고 상기 제3 메시지를 상기 제1 디바이스에 포워드하는 동작 - 상기 제3 메시지는 상기 요청된 서비스와 연관된 정보를 포함하고, 상기 제3 메시지는 상기 요청된 서비스를 호스트하는 디바이스의 휴면 특성을 제공하는 DNS 자원 레코드(Resource Record)를 더 포함하고, 상기 휴면 특성은 현재 휴면 상태, 휴면 기간, 또는 휴면 주기를 포함함-
    을 포함하는, 장치.
  2. 삭제
  3. 삭제
  4. 제1항에 있어서, 상기 서비스와 연관된 상기 정보는 상기 서비스의 주소를 포함하는, 장치.
  5. 제1항에 있어서, 상기 서비스와 연관된 상기 정보는 상기 서비스의 가용성의 표시를 포함하는, 장치.
  6. 제1항에 있어서, 상기 서비스는 원격 디바이스 상에 위치하고, 상기 원격 디바이스는 제2 로컬 영역 네트워크 상에 위치하는, 장치.
  7. 제1항에 있어서, 상기 서버는 광역 네트워크 상에 위치하는, 장치.
  8. 제1항에 있어서, 서버는 서비스로서의 인프라스트럭처(infrastructure as a service)(IAAS)인, 장치.
  9. 제1항에 있어서, 로컬 영역 네트워크가 생성될 때 메시지에서 상기 DNS-SD 서버에 대한 가상 발견 구역의 할당을 요청하고 상기 DNS-SD 서버로부터 상기 가상 발견 구역의 할당을 수신하는 동작들을 더 포함하는 장치.
  10. 삭제
  11. 삭제
  12. 제1항에 있어서, 상기 서비스가 상기 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정하는 동작은 제한된 애플리케이션 프로토콜(CoAP) 자원 디렉토리의 질의에 기초하는, 장치.
  13. 삭제
  14. 삭제
  15. 컴퓨팅 디바이스에 의해 실행될 때 상기 컴퓨팅 디바이스로 하여금 동작들을 수행하게 하는 컴퓨터 실행 가능한 명령어들을 포함하는 컴퓨터 판독 가능한 저장 매체로서, 상기 동작들은:
    제1 로컬 영역 네트워크 상에서 제1 디바이스로부터 제1 메시지 - 상기 제1 메시지는 서비스에 대한 도메인 네임 시스템-서비스 발견(domain name system-service discovery)(DNS-SD) 질의를 포함함 - 를 수신하는 동작;
    상기 서비스가 상기 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정하는 동작;
    상기 서비스가 상기 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정한 것에 응답하여, 상기 서비스에 대한 DNS-SD 질의를 포함하는 제2 메시지를 서버에 제공하는 동작
    - 상기 서버는 가상 발견 구역(virtual discovery zone) 상에서 DNS-SD 서버로서 동작하고 상기 가상 발견 구역에서의 서비스들을 위한 서비스 발견 질의들에 응답하도록 구성되고, 그리고
    상기 가상 발견 구역은 전체 가상 발견 구역에서의 서비스들에 대한 서비스 발견들을 가능하게 하는 공통 DNS-SD 서비스 발견 구역이 있는 로컬 영역 네트워크들의 논리적 그룹화임-; 및
    요청된 서비스가 가상 발견 구역 내의 다른 곳에서 발견되었다는 결정에 응답하여, 상기 DNS-SD 서버로부터 상기 제2 메시지에 대한 DNS-SD 응답을 포함하는 제3 메시지를 수신하고 상기 제3 메시지를 상기 제1 디바이스에 포워드하는 동작 - 상기 제3 메시지는 상기 요청된 서비스와 연관된 정보를 포함하고, 상기 제3 메시지는 상기 요청된 서비스를 호스트하는 디바이스의 휴면 특성을 제공하는 DNS 자원 레코드(Resource Record)를 더 포함하고, 상기 휴면 특성은 현재 휴면 상태, 휴면 기간, 또는 휴면 주기를 포함함-
    을 포함하는, 컴퓨터 판독 가능한 저장 매체.
  16. 제15항에 있어서, 로컬 영역 네트워크가 생성될 때 메시지에서 상기 DNS-SD 서버에 대한 가상 발견 구역의 할당을 요청하고 상기 DNS-SD 서버로부터 상기 가상 발견 구역의 할당을 수신하는 동작들을 더 포함하는, 컴퓨터 판독 가능한 저장 매체.
  17. 제15항에 있어서, 상기 서비스가 상기 제1 로컬 영역 네트워크 상에 위치하지 않는다고 결정하는 것은 CoAP(constrained application protocol) 자원 디렉토리(resource directory)의 질의에 기초하는 것인, 컴퓨터 판독 가능한 저장 매체.
  18. 제15항에 있어서, 상기 서비스와 연관된 상기 정보는 상기 서비스의 주소를 포함하는, 컴퓨터 판독 가능한 저장 매체.
  19. 제15항에 있어서, 상기 서비스와 연관된 상기 정보는 상기 서비스의 가용성의 표시를 포함하는, 컴퓨터 판독 가능한 저장 매체.
  20. 제15항에 있어서, 상기 서비스는 원격 디바이스 상에 위치하고, 상기 원격 디바이스는 제2 로컬 영역 네트워크 상에 위치하는, 컴퓨터 판독 가능한 저장 매체.
KR1020187003237A 2015-07-06 2016-07-06 사물 인터넷을 위한 광역 서비스 발견 KR102047197B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201562188781P 2015-07-06 2015-07-06
US62/188,781 2015-07-06
PCT/US2016/041029 WO2017007783A1 (en) 2015-07-06 2016-07-06 Wide area service discovery for internet of things

Publications (2)

Publication Number Publication Date
KR20180024003A KR20180024003A (ko) 2018-03-07
KR102047197B1 true KR102047197B1 (ko) 2019-11-20

Family

ID=56557895

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187003237A KR102047197B1 (ko) 2015-07-06 2016-07-06 사물 인터넷을 위한 광역 서비스 발견

Country Status (6)

Country Link
US (1) US10715482B2 (ko)
EP (1) EP3320671B1 (ko)
JP (1) JP2018520598A (ko)
KR (1) KR102047197B1 (ko)
CN (1) CN107852430B (ko)
WO (1) WO2017007783A1 (ko)

Families Citing this family (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10530739B2 (en) * 2015-10-20 2020-01-07 Samsung Electronics Co., Ltd. Method and apparatus for address resolution of multicast/broadcast resources using domain name systems
US11297153B2 (en) * 2016-03-22 2022-04-05 At&T Mobility Ii Llc Evolved packet core applications microservices broker
US10387248B2 (en) * 2016-03-29 2019-08-20 International Business Machines Corporation Allocating data for storage by utilizing a location-based hierarchy in a dispersed storage network
US10412177B2 (en) * 2016-03-30 2019-09-10 Konica Minolta Laboratory U.S.A., Inc. Method and system of using IPV6 neighbor discovery options for service discovery
WO2018112212A1 (en) * 2016-12-14 2018-06-21 Idac Holdings, Inc. System and method to register fqdn-based ip service endpoints at network attachment points
US10575250B2 (en) * 2016-12-15 2020-02-25 Cable Television Laboratories, Inc. Normalization of data originating from endpoints within low power wide area networks (LPWANs)
US20180198544A1 (en) * 2017-01-11 2018-07-12 Qualcomm Incorporated Content provider network interface
US11895200B2 (en) * 2017-03-24 2024-02-06 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Access to an operator panel over an out-of-band local network domain
US20180295094A1 (en) * 2017-04-05 2018-10-11 Linkedin Corporation Reducing latency during domain name resolution in networks
WO2018186718A1 (en) * 2017-04-07 2018-10-11 Samsung Electronics Co., Ltd. A method and apparatus for reducing latency of network protocols
US10439877B2 (en) * 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
JP6495381B2 (ja) * 2017-06-27 2019-04-03 ソフトバンク株式会社 サーバ装置、サーバ装置がＩｏＴデバイスと通信する方法、コンピュータプログラム、通信システムおよびＩｏＴデバイス
JP7081257B2 (ja) * 2017-09-20 2022-06-07 京セラドキュメントソリューションズ株式会社 情報処理装置及び情報処理プログラム
JP7146379B2 (ja) * 2017-10-03 2022-10-04 キヤノン株式会社 印刷方法、音声制御システムおよびプログラム
JP7119370B2 (ja) * 2017-12-26 2022-08-17 ブラザー工業株式会社 制御プログラム、および端末装置
WO2019145043A1 (en) * 2018-01-26 2019-08-01 Telefonaktiebolaget Lm Ericsson (Publ) Node, another node, and methods performed thereby for supporting domain name system over constrained application protocol
US11381947B2 (en) * 2018-04-06 2022-07-05 Telefonaktiebolaget Lm Ericsson (Publ) Thing description to resource directory mapping
CN109040234A (zh) * 2018-08-01 2018-12-18 佛山市苔藓云链科技有限公司 一种物联网的局域网络建立装置及方法
CN109327513B (zh) * 2018-09-21 2021-12-17 京东方科技集团股份有限公司 交互方法、装置及计算机可读存储介质
CN109446439B (zh) * 2018-09-30 2022-09-06 青岛海尔科技有限公司 一种资源目录的选择方法、装置、系统及存储介质
CN112840621A (zh) * 2018-10-16 2021-05-25 通力股份公司 在电梯和自动扶梯中的数据网络服务发现
WO2020091737A1 (en) * 2018-10-30 2020-05-07 Hewlett Packard Enterprise Development Lp Software defined wide area network uplink selection with a virtual ip address for a cloud service
KR20200055848A (ko) 2018-11-13 2020-05-22 동명대학교산학협력단 CoAP를 이용한 마이크로그리드 운용 시스템 및 그 방법
WO2020102585A1 (en) * 2018-11-14 2020-05-22 Eventstream, Inc. Network services platform system, method, and apparatus
EP3895031A4 (en) * 2018-12-15 2022-07-20 Telefonaktiebolaget LM Ericsson (publ) EFFICIENT NETWORK ADDRESS TRANSLATION (NAT) IN CLOUD NETWORKS
US11109197B2 (en) * 2019-02-09 2021-08-31 Richard Lamb Short message service for internet devices
US11243722B2 (en) 2019-02-11 2022-02-08 Cisco Technology, Inc. System and method of providing universal mobile internet proxy printing
US10862857B2 (en) * 2019-03-27 2020-12-08 Cisco Technology, Inc. System and method of using a global discovery service to enable routing of packets from a source container to a destination container
CN113647061A (zh) * 2019-03-29 2021-11-12 Oppo广东移动通信有限公司 设备发现方法、装置、控制终端及物联网辅助设备
EP3949354B1 (en) * 2019-04-02 2023-09-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for service discovery
DE102019126486A1 (de) * 2019-10-01 2021-04-01 Perinet GmbH Verfahren zur Identifikation von Diensten in einem Netzwerk mit Internet-of-Things Sensoren/Aktoren
DE102019126686B4 (de) * 2019-10-02 2022-01-20 Perinet GmbH Verfahren zur Kommunikation mit Internet-of-Things Geräten in einem Netzwerk
JP2021081875A (ja) * 2019-11-15 2021-05-27 株式会社リコー 情報処理システム、情報処理方法、情報処理装置及び出力装置
WO2021116732A1 (en) * 2019-12-10 2021-06-17 Telefonaktiebolaget Lm Ericsson (Publ) Mechanism to enable third party services and applications discovery in distributed edge computing environment
CA3181810A1 (en) * 2020-06-30 2022-01-06 Mark Stephen GRIFFITHS Method for providing multicast dns services across ip subnet boundaries
US11622006B2 (en) * 2020-11-04 2023-04-04 Panduit Corp. Single pair ethernet sensor device and sensor network
US11122131B1 (en) * 2020-11-18 2021-09-14 At&T Intellectual Property I, L.P. Edge cloud resource location using enhanced DNS service
CN112637068B (zh) * 2020-12-04 2021-09-21 广州爱浦路网络技术有限公司 网络数据转发方法、计算机装置、计算机网络和存储介质
CN112491933A (zh) * 2020-12-25 2021-03-12 四川虹微技术有限公司 一种局域网加密通信方法和存储介质
US20220271966A1 (en) * 2021-02-24 2022-08-25 Toshiba Tec Kabushiki Kaisha System and method for mobile device fleet management
CN112738296B (zh) * 2021-03-02 2022-09-20 中国建设银行股份有限公司 一种域名解析方法和域名解析系统
CN113132219B (zh) * 2021-03-26 2022-07-12 杭州芯博士网络科技有限公司 一种用于物联网终端的网络快速访问方法及物联网网络装置
US11863518B2 (en) 2021-11-24 2024-01-02 Oracle International Corporation Methods, systems, and computer readable media for automatic domain name system (DNS) configuration for 5G core (5GC) network functions (NFs) using NF repository function (NRF)
US11652782B1 (en) * 2021-11-24 2023-05-16 Oracle International Corporation Methods, systems, and computer readable media for dynamically updating domain name system (DNS) records from registered network function (NF) profile information
US20230308467A1 (en) * 2022-03-24 2023-09-28 At&T Intellectual Property I, L.P. Home Gateway Monitoring for Vulnerable Home Internet of Things Devices
US20230308413A1 (en) * 2022-03-25 2023-09-28 Arista Networks, Inc. Discovering services across networks based on a multicast domain name system protocol
CN117424928B (zh) * 2023-12-18 2024-03-12 成都索贝数码科技股份有限公司 网络设备和资源分享的方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140269703A1 (en) * 2013-03-15 2014-09-18 Cable Television Laboratories, Inc. mDNS-DNS ARCHITECTURE
JP2015046716A (ja) * 2013-08-27 2015-03-12 日本電信電話株式会社 通信ノード及びネットワークシステム及び機器制御方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3575369B2 (ja) * 1999-07-21 2004-10-13 日本電気株式会社 アクセスルーティング方法及びアクセス提供システム
JP4816572B2 (ja) * 2007-05-30 2011-11-16 富士ゼロックス株式会社 仮想ネットワーク接続システム及び装置
KR101894614B1 (ko) * 2011-03-03 2018-09-03 아이오티 홀딩스, 인크. 발견된 서비스 공급자와 제휴된 서비스에 접근하는 방법 및 장치
US20130205018A1 (en) * 2012-02-06 2013-08-08 Samsung Electronics Co., Ltd. Extending service discovery into cloud computing
US9787778B2 (en) * 2012-07-05 2017-10-10 Aruba Networks, Inc. Geographic proximity based service discovery
US10284659B2 (en) * 2013-01-25 2019-05-07 Apple Inc. Hybrid unicast/multicast DNS-based service discovery
CN105340247B (zh) * 2013-04-09 2020-10-16 罗伯特·博世有限公司 用于计算机网络中网络容变服务发现的方法
US9917905B2 (en) * 2013-05-13 2018-03-13 International Business Machines Corporation Location-based domain name system service discovery
KR101850802B1 (ko) * 2013-05-16 2018-04-20 콘비다 와이어리스, 엘엘씨 향상된 발견을 위한 시스템들 및 방법들
US9030965B2 (en) * 2013-06-05 2015-05-12 Sprint Communications Company L.P. Communication system to provide selective access to a wireless communication device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140269703A1 (en) * 2013-03-15 2014-09-18 Cable Television Laboratories, Inc. mDNS-DNS ARCHITECTURE
JP2015046716A (ja) * 2013-08-27 2015-03-12 日本電信電話株式会社 通信ノード及びネットワークシステム及び機器制御方法

Also Published As

Publication number Publication date
CN107852430A (zh) 2018-03-27
EP3320671A1 (en) 2018-05-16
US10715482B2 (en) 2020-07-14
WO2017007783A1 (en) 2017-01-12
KR20180024003A (ko) 2018-03-07
US20180191666A1 (en) 2018-07-05
CN107852430B (zh) 2021-08-03
EP3320671B1 (en) 2020-09-02
JP2018520598A (ja) 2018-07-26

Similar Documents

Publication Publication Date Title
KR102047197B1 (ko) 사물 인터넷을 위한 광역 서비스 발견
US10404601B2 (en) Load balancing in the internet of things
US10742592B2 (en) Dynamic DNS-based service discovery
US10863422B2 (en) Mechanisms for ad hoc service discovery
KR102046700B1 (ko) 메시지 버스 서비스 디렉토리
US9769034B2 (en) Method and apparatus for policy based routing in information centric networking based home networks
US9407567B2 (en) Enabling external access to multiple services on a local server
US10798779B2 (en) Enhanced CoAP group communications with selective responses
EP2936891B1 (en) Method, control node, gateway and computer program for enabling communication with a newly detected device
US11792090B2 (en) Service layer support for multiple interface nodes
US20210274025A1 (en) Communication protocol discover method in constrained application protocol (coap)

Legal Events

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