KR20170029540A - 중앙 하이브리드 무선 자체 구성화 네트워크를 구현하는 방법, 장치 및 시스템 - Google Patents

중앙 하이브리드 무선 자체 구성화 네트워크를 구현하는 방법, 장치 및 시스템 Download PDF

Info

Publication number
KR20170029540A
KR20170029540A KR1020177002867A KR20177002867A KR20170029540A KR 20170029540 A KR20170029540 A KR 20170029540A KR 1020177002867 A KR1020177002867 A KR 1020177002867A KR 20177002867 A KR20177002867 A KR 20177002867A KR 20170029540 A KR20170029540 A KR 20170029540A
Authority
KR
South Korea
Prior art keywords
client
client device
servers
gateway
possible paths
Prior art date
Application number
KR1020177002867A
Other languages
English (en)
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 KR20170029540A publication Critical patent/KR20170029540A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/12—Shortest path evaluation
    • H04L45/122—Shortest path evaluation by minimising distances, e.g. by selecting a route with minimum of number of hops
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/04—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources
    • H04W40/10—Communication route or path selection, e.g. power-based or shortest path routing based on wireless node resources based on available power or energy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
    • H04W40/12—Communication route or path selection, e.g. power-based or shortest path routing based on transmission quality or channel quality
    • Y—GENERAL 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
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE 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/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Abstract

하나 이상의 서버들을 포함하는 시스템에서 동작 가능한 원격통신 장치로서, 이 장치는 시스템 내의 클라이언트 장치이다. 이 장치는 클라이언트 장치에 대한 클라이언트 구성 상태를 상기 하나 이상의 서버에 제공하고; 하나 이상의 서버로부터 제1 서브 네트워크 구성 - 제1 서브 네트워크 구성은 하나 이상의 서버로부터 클라이언트 장치로의 적어도 하나의 경로를 포함하고, 클라이언트 구성 상태와 적어도 하나의 다른 클라이언트 장치의 적어도 하나의 다른 클라이언트 구성 상태에 기초함 - 을 획득하기 위해 구성 및 적응된다. 장치는 하나 이상의 서버를 통해 적어도 하나의 자원을 획득하기 위해 제1 서브 네트워크 구성에 지정된 경로를 사용할 수 있다.

Description

중앙 하이브리드 무선 자체 구성화 네트워크를 구현하는 방법, 장치 및 시스템{METHODS, DEVICES, AND SYSTEMS FOR IMPLEMENTING CENTRALIZED HYBRID WIRELESS SELF-ORGANIZING NETWORKS}
저작권 진술
이 특허 문헌에는 저작권 보호 대상이 포함되어 있다. 저작권 소유자는 이 특허 문서 또는 미국 특허 및 상표청 파일에 있는 관련 자료의 복제에 대해 이의를 제기하지 않고, 그 외에는 모든 저작권을 보유한다.
관련 출원과의 상호 참조
본 출원은 다음 출원들과 관련이 있고 다음 출원들에 대한 우선권을 주장한다: (i) "동적 무선 메시 네트워크를 구현하기 위한 방법 및 시스템"이라는 제목의 2014년 7월 1일자로 출원된 미국 특허 가출원 제62/019,545호, 그리고 (ii) "중앙 하이브리드 무선 자체 구성화 네트워크를 구현하기 위한 방법, 장치 및 시스템"이라는 제목의 2015년 6월 28일자로 출원된 미국 특허 가출원 제62/185,717호. 이 두 출원의 전체 내용은 본원에서 모든 면에서 참고 문헌으로 인용된다.
발명의 분야
본 발명품은 하이브리드 무선 자체 구성화 네트워크에 관한 것이고, 보다 상세하게, 이동 무선 통신 장치를 포함하는 하이브리드 무선 자체 구성화 네트워크에 관한 것이다.
스마트 폰, 휴대 전화 등과 같은 무선 원격통신 장치가 보편화되었다. 이러한 장치들은 더 이상 주로 음성 통신(예를 들어, 음성 전화 통화)에만 사용되지 않고, 본질적으로 휴대용 컴퓨터 장치이며 웹 브라우징 등을 포함하는 모든 종류의 데이터 통신에 사용된다.
무선 원격통신 장치의 사용의 증가 그리고 이들의 사용 특성은 모바일 데이터 및 서비스에 대한 수요를 크게 증가시켰다. 그러나 해당 인프라는 이 요구 사항을 따라 잡지 못했다. 무선 원격통신 장치는 주로 셀룰러 네트워크를 통해 데이터 소스에 접속하고, 셀룰러 캐리어(즉, 셀룰러 네트워크의 운영업체)는 셀룰러 네트워크만을 통해 모바일 데이터 및 서비스에 대한 요구를 충족할 수 없었다.
스마트 폰과 같은 무선 원격통신 장치의 사용자들은 너무 많은 사용자가 너무 적은 네트워크 자원을 사용하려고 시도할 때 종종 문제를 일으킨다. 예를 들어 셀룰러 기지국에서 채널을 요청하는 사용자가 너무 많으면 인터넷 트래픽이 느려지고 혼잡해질 수 있다. 셀룰러 전화의 제한과 관련 비용을 피하기 위해, 많은 무선 원격통신 장치 사용자는 가능한 경우 WiFi 또는 다른 비 셀룰러 접속 프로토콜로 전환한다. 이러한 유형의 전환은 일반적으로 비 셀룰러 접속 프로토콜(예 : 이름으로 WiFi 네트워크 선택)을 사용하기 위해 사용자의 조치에 의해 수행된다. WiFi 서비스는 현재 셀룰러 서비스보다 저렴하지만, 어느 특정 위치에서도 사용자들의 요구에 따라 WiFi 네트워크 자체 또한 압도될 수 있다. WiFi 연결은 일반적으로 무료가 아니며 이러한 접속과 관련된 비용으로 인해 WiFi 네트워크의 이용을 속도와 비용면에서 차선책으로 만들 수 있다. 본 명세서에서 사용되는 "비용"이라는 용어는 금융 비용을 포함 모든 비용을 가리킨다.
혼잡 문제에 대한 하나의 해결책은 사용자의 장치들이 셀룰러 네트워크 대신에 서로 직접 통신하는 메시 네트워크의 사용이다. 이러한 시스템 하에 트래픽은 데이터가 사용 가능한 고속 인터넷 연결로 전송될 때까지 한 사용자 장치에서 다른 장치로 전달될 수 있으며, 그 반대의 경우도 가능하다. (게이트웨이에서 요청 장치로).
메시 네트워크의 가장 심각한 문제 중 하나는 사용자 장치가 메시에서 사용할 라우트를 찾는 것이다. 메시 네트워크 사용 접속은 기본적으로 장치가 끝없는 요청을 통해 네트워크를 플러딩함으로 라우트를 구축하거나 각 장치가 전체 네트워크 연결을 업데이트하도록 한다. 이 두 가지 방식은 전송 성능면에서도 (불안정하거나 낮은 처리량 연결) 비효율적이고, 네트워크 장치의 배터리를 빠르게 소모시킨다.
제한된 네트워크 자원을 사용하려는 다중 무선 원격통신 장치들에 의해 일어나는 문제들을 극복할 필요가 있다. 또한 이러한 문제를 자동적이고 투명한 방식으로 극복하고 사용할 수 있는 자원을 효과적으로 활용할 필요가 있다. 또한 이러한 가능한 주어진 제약 사항 안에서 전체 네트워크에게 최적 서비스를 제공해야 할 필요가 있다.
구조체의 관련 요소의 작동과 기능의 방법들뿐만 아니라 다른 목적, 특징, 특성 및 방식들과 부품의 조합 및 제조의 경제 방식들은 이하의 설명 및 첨부된 청구항들을, 본 명세서의 일부를 형성하는 도면을 참조하여 고려하면 더욱 명백해질 것이다. 특별히 언급하지 않는 한 도면의 어느 것도 일정한 비례로 그려지지 않았다.
도 1은 본 발명의 바람직한 실시 예에 따른 시스템/프레임을 명시한다.
도 2a-2b는 본 발명의 바람직한 실시 예에 따른 중앙 설비의 논리적 조직을 명시한다.
도 3은 본 발명의 바람직한 실시 예에 따른 장치의 논리적 구성을 명시한다.
도 4a-4e는 도 1의 시스템의 구성 측면들 간의 통신 요소들을 명시한다.
도 5a-5e는 본 발명의 예시적인 동작 측면들을 나타내는 흐름도이다.
도 6a-6x 및 도 7은 본 발명의 바람직한 실시 예에 따른 동작 측면들을 명시한다.
도 8은 본 발명의 바람직한 실시 예에 따른 컴퓨터 시스템의 측면들을 명시한다.
<용어 및 약어>
본원에서 사용된 바와 같이, 달리 사용되지 않는 한, 하기 용어 또는 약어는 하기 의미를 갖는다.
AP는 액세스 포인트(일반적으로, 예를 들어 Wi-Fi 또는 관련 표준을 사용하여 네트워크에 접속을 허용 또는 지원하는 장치를 지칭함)를 의미한다.
API는 애플리케이션 프로그래밍 인터페이스를 의미한다.
배트맨(BATMAN- Better Approach To Mobile Ad-hoc Networking)은 분산형 메시 네트워크를 위한 라우팅 프로토콜인 "모바일 임시 네트워크 접근법"을 의미한다.
봉쥬르(Bonjour)는 애플의 제로 구성 네트워킹(Zero configuration networking, 서비스 발견, 어드레스 할당 및 호스트 이름 확인을 포함하는 기술들) 구현을 지칭한다.
GPS는 위성 위치확인 시스템(Global Positioning System)을 의미한다.
GSM은 이동 통신을 위한 글로벌 시스템를 의미한다.
햄 라디오(Ham Radio)는 아마추어 라디오를 지칭한다.
HTTP는 하이퍼 텍스트 전송 프로토콜을 의미한다.
HTTPS는 하이퍼 텍스트 전송 프로토콜 보안을 의미한다.
IMEI는 국제모바일 장비 식별코드를 의미한다.
IoT(Internet of Things)는 사물간 인터넷을 의미한다.
IP는 인터넷 프로토콜을 의미한다.
LAN은 근거리 통신망을 의미한다.
LTE는 4 세대 셀룰러 네트워크 표준인 Long-Term Evolution을 의미한다.
MAC은 통신망 매체 접근 제어를 의미한다.
MNO는 모바일 네트워크 운영자를 의미한다.
MSO는 다중 시스템 운영자 또는 여러 시스템의 운영자를 의미한다.
MVNO는 모바일 가상 네트워크 운영자를 의미한다.
NIC는 네트워크 인터페이스 카드를 의미한다.
OEM은 장비의 본 제조업체를 의미한다.
OLSR은 최적화된 링크 상태 라우팅을 의미한다.
OSI는 개방 시스템 상호접속을 의미한다.
RAM은 임의 추출 기억 장치를 의미한다.
RF는 라디오 무선 주파수를 의미한다.
SIM은 가입자 아이덴티티 모듈 또는 가입자 식별 모듈을 의미한다.
SON은 자체 구성 네트워크를 의미한다.
SSID는 서비스 세트 식별자(Service Set Identifier)를 의미한다.
TCP/IP는 전송 제어 프로토콜/인터넷 프로토콜을 의미한다.
VPN은 가상 사설망을 의미한다.
WLAN은 무선 근거리 통신망을 의미한다.
"메커니즘"은 임의의 장치(들), 프로세스(들), 절차(들), 서비스(들), 모듈(들), 또는 이들의 조합을 지칭한다. 메커니즘은 하드웨어, 소프트웨어, 펌웨어, 특수 목적 장치 또는 이들의 임의의 조합을 사용하여 구현될 수 있다. 메커니즘의 일부들은 단일 장치에 통합되거나 여러 장치에 분산될 수 있다. 메커니즘의 다양한 구성 요소는 함께 배치되거나 분산될 수 있다. 메카니즘은 다른 메카니즘으로 형성될 수 있다. 일반적으로, 본문에서 사용되는 "메커니즘"이라는 용어는 장치(들) 및/또는 프로세스(들) 및/또는 서비스(들)의 약어로 쓰인다.
개관
본 발명의 바람직한 예에 따른 시스템 또는 프레임 워크(100)은 도 1에서 설명된다. 다수의 장치들(102-1, 102-2, 102-3,... 102-n, 일반적으로 102)은 하나 이상의 게이트웨이들(106-1, 106-2,..., 일반적으로 106로 표기)과 하나 이상의 네트워크(108)를 통해 중앙 설비(104)(이하 상세히 설명됨)에 접속 가능하다. 중앙 설비에 등록된 장치는 클라이언트로서 지칭된다.
장치(102)는 무선 원격통신 장치이다. 본 출원에서는, 무선 원격통신 장치(또는 WTD)는 데이터 송신 및 수신이 가능한 임의의 장치를 지칭한다.
무선 원격통신 장치의 제한적이지 않은 예는 휴대폰(예를 들어, 셀 폰, 스마트 폰 등)을 포함한다. 무선 원격통신 장치라는 용어는 사용된 통신 프로토콜이나 시스템, 또는 데이터 유형에 의해 제한되지 않는다. 데이터는 음성 데이터, 이미지 데이터, 텍스트 데이터, 데이터, 비디오 데이터 등을 포함할 수 있다.
중앙 설비(104)는 하나 이상의 중앙 서버(110)(일반적으로 중앙 서버(110) 또는 서버(110)로 지칭 됨)와 하나 이상의 데이터베이스(112)(일반적으로 데이터베이스(들)(112)로 지칭됨)로 구성되어 있다. 중앙 서버(들)(110)는 하나의 컴퓨터, 컴퓨터들의 네트워크, 또는 분산되어 있는 시스템을 포함할 수 있다. "설비(104)"및/또는 "서버(들)(110)"에 대한 "중앙"이라는 용어는 설명의 목적으로 사용되며 시스템(100)의 요소들 간의 논리적인 관계를 암시하고, 구성 요소 간에 물질적 관계를 암시하거나 부과하지 않는다. 따라서, 중앙 설비(104)의 다양한 구성 요소들이 동일 위치에 있거나 중앙 서버(들)(110)의 구성 요소들이 동일 위치에 있을 필요는 없다. 또한, 데이터베이스(들)(112)가 서버(110)와 함께 배치될 필요는 없다.
본 출원에 설명된 바와 같이, 중앙 설비는 네트워크 가상화, 네트워크 토폴로지 결정, 전송 경로 결정, 경로 최적화, 전송 타이밍, 전송 채널, 원격 자원 통신, 클라이언트 장치와의 통신, 통신 오류 해결, 클라이언트 상태 구성 수정 또는 이들의 조합, 중 하나 이상을 수행할 수 있는 구성 요소 또는 요소들의 집합이다.
서버(110)들은 하나 이상의 콘텐츠 소스들(114)(예를 들어, 원격 웹 서버 등)과 통신할 수 있다.
각각의 장치(102)는 예를 들어 셀룰러, WiFi, 블루투스, 위성 등과 같은 무선/RF 통신을 위한 메커니즘을 포함하는 적어도 2개 이상의 통신 메커니즘(116)을 포함한다.
시스템(100)의 각 장치(102)는 애플리케이션(118)(이하에서보다 상세하게 설명 됨)을 포함한다.
다양한 클라이언트 장치(102) 및 게이트웨이(106)는 하나 이상의 하이브리드 네트워크 또는 서브 네트워크를 형성하거나 포함할 수 있다. 본 출원에서 사용되기로는, 장치(102)의 서브 네트워크는 각 장치가 세트 내의 적어도 하나의 다른 장치의 송신 또는 수신 범위에 있는 장치들의 집합을 지칭한다.
이들의 네트워크 또는 서브 네트워크들은 셀룰러, WiFi, 블루투스, 위성 등을 포함하는 다수의 무선 전송 유형을 걸쳐 동작할 수 있다는 점에서 하이브리드로 언급된다. 이러한 하나 이상의 네트워크의 회원 및 네트워크 토폴로지/접속성은 시간의 경과에 따라 계속 바뀐다. 하나 이상의 하이브리드 네트워크/서브 네트워크는 연결되지 않은 구성 요소를 가질 수 있는 하나의 하이브리드 네트워크로 간주될 수 있다.
네트워크 또는 서브 네트워크 내의 어느 2개의 노드 사이에도 경로가 있을 수 있다. 경로에는 방향이 있는 것으로 간주됨으로, 네트워크 또는 서브 네트워크의 어느 두 노드 N1와 N2에 대해 N1에서 N2로(때로는≪N1, N2≫로 표시)의 경로가 반드시 N2에서 N1로 (≪N2, N1≫)의 경로와 같을 필요는 없다. 경로의 방향은 일반적으로 전송 방향과 일치한다. 예를 들어, N1에서 N2로의 경로가 있다고 해도 N2에서 N1로의 경로는 없을 수도 있다. 따라서 이 경우에는, 노드(N1)는 노드(N2)와 통신할 수 있지만 그 반대는 할 수 없다. 본 출원에서 사용되기로는, 경로는 다른 통신 인터페이스를 사용하는 경로의 마디들이 있는 경우 하이브리드(하이브리드 경로)로 간주된다. 예를 들어, 노드 N1에서 노드 N3으로의 경로 ≪N1, N2, N3≫가 있는 경우, 경로의 마디 ≪N1, N2≫가 마디 ≪N2, N3≫과 다른 프로토콜 또는 인터페이스를 사용하면 경로 ≪N1, N2, N3≫는 하이브리드로 간주된다. 두 장치가 여러 인터페이스(예 : WiFi 및 Zigbee)를 사용하여 통신할 수 있는 경우 각 인터페이스는 각각의 경로에 해당한다. 예를 들어, 노드 N1이 WiFi와 Zigbee를 통해 노드 N2와 통신할 수 있는 경우 N1에서 N2로의 두 경로, 즉 WiFi 경로와 Zigbee 경로가 있다.
일반적으로, 그 경로에서 다른 경로의 마디와 다른 프로토콜 또는 인터페이스를 사용하는 경로의 마디가 있다면 그 경로는 하이브리드로 간주된다.
네트워크 또는 서브 네트워크에서, 2 개의 노드 사이에 중간 노드를 포함하지 않는 경로가 있는 경우 직접 연결된다. 이전과 마찬가지로, 노드 N1에서 노드 N2로의 직접 연결의 존재는 필연적으로 노드 N2에서 노드 N1로의 직접 연결의 존재를 암시하지 않을 수도 있다.
아래에서 상세히 설명되는 바와 같이, 될 수 있는 한 중앙 설비(104)는 클라이언트 장치(102) 및 게이트웨이(106)의 하이브리드 네트워크(들)의 가상 지도를 결정하고 유지한다. 이 가상 지도는 될 수 있는 한 등록된 클라이언트들의 물질적 무선 인터페이스, 클라이언트 위치, 게이트웨이 위치 및 기능, 장치의 배터리 잔량, 클라이언트 간의 잠재적 연결력, 클라이언트와 게이트웨이 간의 잠재적 연결 및 게이트웨이 간의 잠재적 연결력 중 하나 이상에 관한 정보를 제공한다.
예시적인 중앙 설비(104')가 도 2a에 보다 상세히 명시되어 있고, 그의 데이터베이스(들)(112')는 토폴로지 데이터베이스(들)(200), 클라이언트 정보 데이터베이스(들)(202), 장치 정보 데이터베이스(들)(204), 로컬 정보 데이터베이스(들)(206), 자원 데이터베이스(들)(208), 인터페이스 데이터베이스(들)(210) 및 기타/보조 데이터베이스(212)를 포함할 수 있다. 중앙 서버(들)(110)는 될 수 있는 한 다양한 데이터베이스(들)(112')에 접속하고 관리하기 위한 데이터베이스 접속 메커니즘(들)(216) 및 데이터베이스 관리 메커니즘(들)(218)을 포함한 데이터베이스 메커니즘(들)(214)을 포함한다. 시스템(100)은 데이터베이스(들)(112')의 종류 또는 구성 또는 구현에 의해, 또는 관리 및/또는 접속되는 방식에 의해 제한되지 않는다. 일부 데이터베이스는 다른 데이터베이스보다 더 빨리 접속될 필요가 있을 수 있으며, 그러한 데이터베이스의 일부는 예를 들어 RAM 등과 같은 고속 메모리에 서버(들)(110) 구내 상에 저장될 수 있다. 예를 들어, 토폴로지 데이터베이스(들)(200)는 네트워크의 가상 지도에 관한 정보를 저장하고 관리하는데 사용될 수 있고, 그러한 정보는(실질적으로, 실시간으로) 신속하게 액세스되고 업데이트될 필요가 있을 수 있다.
중앙 설비(104)의 중앙 서버(들)(110)상의 메커니즘은 다음 중 하나 이상을 포함하고 실행할 수 있다: (i) 특정 네트워크에서 인터페이스의 가상 지도의 수집 및 관리, (ii) 네트워크상 잠재적인 가상 연결 정보 수집 및 관리, (iii) 데이터 전송 및 활성의 최적화 경로 생성, (iv) 데이터 라우팅 서비스, (v) 데이터 안정성 서비스, (vi) 원격 데이터 요청 서비스 및 (vii) 보안 서비스.
예시적인 중앙 설비(104')는 되도록이면 경로 분석/결정 메커니즘(들)(220), 경로 관리자 메커니즘(들)(222), 데이터 관리자 메커니즘(들)(224), 자원 취급자 메커니즘(들)(226), 장치 관리 메커니즘(들)(228), 인터페이스/패킷 메커니즘(들)(230), 토폴로지 메커니즘(들)(232), 인증 메커니즘(들)(234), 및 기타/보조 메커니즘들(236)을 포함한다.
예시적인 중앙 설비(104')는 단지 예시로서 명시되어 있고, 통상의 기술자는 이 설명을 읽을 때 상이한 및/또는 다른 구성 및 구성 요소들이 사용될 수 있다는 것을 이해할 것이다.
도 2b는 도 2a의 중앙 설비의 예를 명시하고, 도 2a는 구성 요소 간의 연결 예를 명시한다.
서버(들)(110)는 될 수 있는 한 게이트웨이(106)로부터의 직접 연결(예를 들어, 셀룰러, WiFi 등을 통한) 또는 의사(擬似, pseudo) 게이트웨이를 통한 연결로서 시스템(100) 내의 장치(102)와 통신할 수 있다. 본 출원에서 의사 게이트웨이는 게이트웨이에 대한 직접 업링크 접속을 갖는 네트워크 내의 클라이언트 장치를 지칭한다. 의사 게이트웨이는 중앙 서버와의 연결을 사용하여 게이트웨이에 직접 연결되지 않은 다른 장치(들)의 요청 데이터를 중계할 수 있다. 실제로, 게이트웨이로의 직접 업링크 접속이 가능한 모든 클라이언트 장치가 의사 게이트웨이로서 동작하도록 선택되지는 않는다. 마찬가지로, 각각의 클라이언트(102)는 직접 연결을 통해 또는 게이트웨이 또는 의사 게이트웨이를 통해 중앙 서버(들)(110)와 통신할 수 있다. 의사 게이트웨이는 데이터를 요청한 클라이언트와 직접 연결되어 있거나 게이트웨이와 직접 연결되어 있는 다른 클라이언트를 통해 연결되어야 한다.
중앙 서버(들)(110)의 바람직한 예는 소프트웨어 및 하드웨어의 조합으로 위측에 설명된 기능을 제공하기는 하지만 하나 이상의 인터넷 접속 시스템(예를 들어, 웹 서버 또는 일련의 웹 서버)을 포함한다. 이러한 구현에서, 웹서버(들)는 백홀 소스(예를 들어, ISP로의 광섬유 케이블 접속)로부터 인터넷을 통해 데이터를 수신할 수 있다. 서버(110)는(예를 들어 TCP/IP 네트워킹을 통해) 게이트웨이(106), 클라이언트 장치(102) 및 원격 웹 서버와 직접 통신할 수 있다. 시스템의 다른 바람직한 예는 이러한 기능을 수행하도록 협력하는 장치들의 분산 네트워크를 포함할 수 있다. 한 가지 예는 인터넷을 사용하여 통신하고 무선 전송을 조정하는 일련의 지능형 WiFi 라우터를 포함할 수 있다.
각각의 서버는 컴퓨팅 장치 상에 있거나, 컴퓨팅 장치를 포함하거나, 컴퓨팅 장치 상에 구현될 수 있다. 컴퓨팅 장치에 대해서는 아래에서 자세히 설명한다.
그 구현에 상관없이, 중앙 설비(104)의 주요 책임은 다음 데이터들 중 적어도 몇 가지를 합하여 정보에 입각한 라우팅을 결정하며 네트워크상 데이터의 흐름을 조정하는 것이다. 클라이언트에 의해 제공된 토폴로지 데이터, 전송된 패킷의 전송 및 전송 오류 데이터, 및 중앙 설비(104)가 획득/사용할 수 있는 다른 데이터.
전형적인 클라이언트 장치(102)의 논리적인 구조가 도 3에 명시되고, 클라이언트 애플리케이션(혹은 클라이언트 소프트웨어)(336)(부분적으로 도 1의 애플리케이션(118)에 상응함) 및 클라이언트 저장 장치(338)를 포함한다. 클라이언트 애플리케이션(336)은 장치(102)에서 작동하는 소프트웨어를 주로 구현되는 메커니즘이다. 클라이언트 애플리케이션(336)은 시스템/관리 애플리케이션(340), 본 발명의 요소을 구현하는 애플리케이션(342)("APP"(342)라고도 함), 및 기타/보조 애플리케이션(344)을 포함할 수 있다. 클라이언트 저장소(338)는 클라이언트 장치(102)의 저장소일 수도 있거나, 클라이언트 애플리케이션(336)을 위한 특별 목적 저장소일 수도 있다. 클라이언트 저장소(338)는 시스템/관리 애플리케이션(336)의 사용을 위한 시스템/관리 데이터 저장소(346), APP(338)의 사용을 위한 APP 데이터 저장소(348) 및 기타/보조 애플리케이션(344)의 사용을 위한 기타/보조 데이터 저장소(350)를 포함할 수 있다. 여기에 설명된 애플리케이션 및 저장소의 명명 및 논리적 구조는 단지 예로서 제시되고, 또 다른 이름 및 조직 구조가 가능하며 본 명세서에서 고려된다.
다시 도1을 참조하면, 될 수 있는 한 각각의 장치(102)는 스마트 폰, 태블릿, 노트북, PDA(Personal Digital Assistant- 개인 디지털 정보 단말기) 또는 데이터를 송신 및/또는 수신하는 기능을 갖는 다른 장치와 같은 무선 원격통신 장치를 포함한다. 클라이언트 측 자체 구성화 네트워크(SON) 소프트웨어는 될 수 있는 한 WiFi Direct(직접), Bluetooth, Zigbee 또는 LTE-Direct(직접)와 같은 프로토콜들 하나 이상을 사용하는 하나 이상의 장치 드라이버를 통해 장치의 유선 및 무선 네트워크 인터페이스를 검출하고 활용하기 위해 장치의 운영 체제와 장치의 하드웨어와 통합된다. 상이한 및/또는 다른 프로토콜이 사용될 수 있고 본 명세서에서 고려될 수 있다.
바람직한 클라이언트 측 소프트웨어(예를 들어, APP(342))는 이와 같은 무선 인터페이스를 관리하고, 인접한 게이트웨이 및 장치의 집합을 검출 및 관리하고, 이 게이트웨이 및 피어들과 통신하기 위한 내부 라우팅 테이블 명령을 유지할 수 있다.
전술한 바와 같이, 각각의 장치(102)는 될 수 있는 한 적어도 두 개의 통신 메커니즘(들)(116)을 포함한다. 이들은 복수의 무선 주파수 대역 및 무선 프로토콜/표준들을 사용하는 메커니즘들을 포함할 수 있다. 이러한 주파수 또는 표준에는 2.4GHz 및 5Ghz 대역에서 작동하는 IEEE 802.11a, b, g, n, ac, ad, h, p, j, ah, y 및 표준, 셀룰러 GSM, LTE, 3GPP, HAM 라디오 및 APRS 대역, Zigbee 400MHz WiFi, 5.9Ghz 차량 통신 대역 및 임의의 다른 주파수를 포함할 수 있다.
각각의 장치(102)는 컴퓨팅 장치이거나, 컴퓨팅 장치를 포함하거나, 컴퓨팅 장치 상에 구현될 수 있다. 컴퓨팅 장치에 대해서는 아래에서 자세히 설명된다.
도 4a에서와 같이, 장치(102')(또는 D1)는 n 개의 무선 주파수 대역 및/또는 무선 프로토콜들을 포함하는 n 개의 통신 메커니즘을 포함할 수 있다. 각각의 주파수 대역/무선 프로토콜은 특정 대응 범위(도 4a의 도면에서 R1, R2, R3 ... Rn으로 표시됨)를 통해 무선 통신을 제공한다. 이 도면 및 다음 도면들에서, 도면을 단순화하기 위해, 장치들은 다이아몬드 형상으로 명시될 수 있고, 참조 사항들을 생략할 수 있다. 다양한 범위들은 원으로 명시되어 있지만, 임의의 특정 주파수 대역/무선 프로토콜의 범위는 균일하지 않을 수 있고 물질적 물체(장치를 보유하는 사람을 포함함)를 포함하는 다양한 요인들에 의해 영향을 받을 수 있다. 또한, 특정 장치는 동일한 주파수 대역/무선 프로토콜 하에 다른 송신 및 수신 범위를 가질 수 있다. 본 출원의 설명을 위해, 이러한 차이는 명시되지 않았다.
다양한 장치(102)는 다중 주파수 대역/무선 프로토콜을 사용하여 서로 직접 통신할 수 있다. 이 설명의 나머지 부분에서는 주파수 대역과 무선 프로토콜의 조합을 프로토콜이라고 한다. 도 4b에 제시된 예에서, 장치 D1은 제1 프로토콜 상에서는 범위 R1로, 제2 프로토콜 상에서는 범위 R2로, 제3 프로토콜 상에서는 범위 R3으로, 그리고 제4 프로토콜 상에서는 범위 R4로 통신할 수 있다. 장치 D2는 제1 프로토콜을 상에서 범위 R1'로, 제2 프로토콜 상에서는 범위 R2'로, 제3 프로토콜 상에서는 범위 R3'로 통신할 수 있다. 장치 D2는 장치 D1의 범위 R2, R3 및 R4 내에 있다. 장치 D1은 장치 D2의 범위 R1' 및 R2' 내에 있다. 장치 D2는 제4 프로토콜의 통신을 지원하지 않기 때문에, 장치 D1 및 D2는 제1, 제2 및 제3 프로토콜을 통해 통신할 수 있다. 그러나, 이 예에서, 장치 D1은 장치 D2의 범위 R3' 내에 있지 않으므로, 장치 D1및 D2가 제3 프로토콜을 위한 인터페이스를 공유하더라도, 장치 D2는 제3 프로토콜에서 장치 D1로부터의 수신이 가능하지만, 장치 D1는 제3 프로토콜을 사용하여 장치 D2로부터 통신을 수신할 수 없다. 즉, 제3 프로토콜을 사용하는 장치들 D1 및 D2 사이의 통신 경로는 단방향 경로이다. 마찬가지로 D2와 D1 사이의 통신은 D2가 R1 범위 내에 있지 않으므로 제1 프로토콜 하에 D2에서 D1로 단방향이다. 제2 및 제3 프로토콜을 사용하여 D1에서 D2로의 통신 경로가 이루어질 수 있다. 제1 및 제2 프로토콜을 사용하여 D2에서 D1로의 통신 경로가 이루어질 수 있다.
네트워크 내의 통신 경로는 방향을 포함한다. 따라서 장치 D1에서 장치 D2 (어느 특정 프로토콜 사용하여) 사이의 경로가 있을 수 있기 때문에 다른 방향(D2에서 D1로)에 경로가 있음을 의미하지 않으며 그 반대의 경우도 마찬가지다. 두 장치는 한 방향으로는 제1 프로토콜을 사용하고 다른 방향에서는 다른 제2 프로토콜을 사용하여 통신할 수 있다. 예를 들어, 두 장치 DA와 DB는 DA에서 DB로 프로토콜 P1을 사용하고 DB에서 DA로 다른 프로토콜 P2를 사용하여 통신할 수 있다.
도 4c 및 도 4d는 3개의 장치(D1, D2 및 D3)가 다양한 프로토콜을 통해 통신하는 예를 명시한다. 하나의 장치에서 다른 장치로의 화살표(예를 들어, D1에서 D2로)는 장치 D2가 하나 이상의 프로토콜로 장치 D1로부터의 전송을 수신할 수 있다는 것을 의미한다. 예를 들어, 장치 D1과 D2는 서로의 범위 내에 있어 D2가 Bluetooth, WiFi, LTE 및 Zigbee를 사용하여 D1에서 통신을 수신할 수 있다. 장치 D1과 D3은 D1이 WiFi로만 D3의 전송을 수신할 수 있는 범위 내에 있다.
도 4e는 서로 통신하는 3 개의 장치(D1, D2, D3)의 예를 도시한다. 장치 D1은 게이트웨이(106)를 통해 중앙 설비(들)(104)의 서버(110)와 통신한다. 각각의 장치는 셀룰러 시스템을 통해(예를 들어, 타워(152)를 통해) 중앙 설비 104에 연결할 가능성이 있다. 도 4e에서 다양한 프로토콜 및 전송 속도는 단지 예로서 명시된다.
본 발명의 바람직한 예는 연결의 종류에 상관없이 작동 가능하다. 네트워크의 토폴로지, 스펙트럼 요구 및 이용 가용성, 백홀 이용 가용성 및 네트워크 내의 영역들에 연결 가능성에 대한 실시간 및 완전한 또는 거의 완전한 정보를 갖는 중앙 설비(104)는 다수의 무선 주파수대와 무선 프로토콜에 대한 라우팅 및 연결 결정을 한다. 이러한 주파수 또는 표준에는 2.4GHz 및 5Ghz 대역에서 작동하는 IEEE 802.11a, b, g, n, ac, ad, h, p, j, ah, y 및 표준, 셀룰러 GSM, LTE, 3GPP, HAM 라디오 및 APRS 대역, Zigbee 400MHz WiFi, 5.9Ghz 차량 통신 대역 및 임의의 다른 주파수가 있을 수 있다. 중앙 서버 전송 결정해야 하는 요인들은 데이터가 전송되는 채널의 선택, 데이터 전송의 타이밍, 데이터가 전송되는 장치의 집합 및 순서, 채널 대역폭, 데이터가 방송되어야 하는 전력, 그리고/또는 다른 요인들을 포함한다.
본 발명의 바람직한 예는 현재 무선 네트워크에서 많은 문제점을 해결한다. 이러한 문제에는 서비스 영역의 신호가 좋지 않은 위치, 비효율적인 배터리 소모, 멀티 홉 메시 조정, 네트워크 최적화, 멀티 홉 네트워크의 효율적인 요금 청구, 및 장치가 다른 장치 및 게이트웨이와의 연결 방법 및 시기에 관한 결정이 포함된다. 예를 들어, 본 예는 임의의 주어진 송신에 대해 시스템의 일부 또는 전부의 총 배터리 소모량을 최소화하도록 시도할 수 있다.
하나의 중앙 설비(104)가 본 출원에 설명되었지만, 통상의 기술자는 다수의 중앙 설비가 시스템 또는 프레임 워크에 존재할 수 있음을 알 것이다. 예를 들어, MNO는 여러 중앙 시설을 지원하고 다양한 셀 타워에 하나 이상의 중앙 시설을 같이 위치시킬 수 있다. 그러한 경우 각 개별 중앙 시설의 범위는 적어도 부분적으로 시설이 위치한 셀 타워의 범위와 일치할 것이다. 다른 예에서, 중앙 설비(104)는 라우터 또는 그러한 장치에 위치될 수 있다.
<시스템의 작동>
시스템(100)의 작동이 여기에서 설명된다. 경우에 따라 클라이언트들 및 중앙 서버(들)의 작동을 별도로 설명한다. 중앙 서버(들)(110)는 둘 이상의 서버를 포함할 수 있지만, 다음의 설명은 단수의 "서버(110)"를 사용하여 이들 및 그들의 작동을 개별적으로 또는 집합적으로 지칭한다.
<장치 및 클라이언트>
본 출원에 사용되기로는, 장치는 데이터 전송이 가능한 무선 전기 원격통신 장치 - WTD(예를 들어, 스마트 폰, 태블릿, 무선 원격통신 장치, IoT 장치, WiFi 중계기, 또는 컴퓨터 장치 등)와 같은 개체를 지칭한다. 클라이언트는 중앙 설비(104)에 등록된 장치를 지칭한다.
부팅 단계
클라이언트 부팅
클라이언트(즉, 클라이언트 소프트웨어, 예를 들어, APP(142))는 될 수 있는 한 장치상에서 자동으로 시작된다. 장치의 운영 체제(OS), 부트 로더, 커널 또는 사용자 공간 응용 프로그램이 장치의 전원이 켜져 있는 동안 될 수 있는 한 배경에서 실행될 수 있는 클라이언트 소프트웨어를 시작한다.
장치는 될 수 있는 한 하드웨어에 하나 이상의 물질적 무선 인터페이스(예를 들어, 통신 메커니즘(들)(116)과 같은)를 제공한다. 이러한 인터페이스는 HAM 라디오 인터페이스, LTE호환 셀룰러 인터페이스, WiFi 인터페이스 및/또는 위성 인터페이스를 포함할 수 있다. 각 장치의 운영 체제는 각 장치의 하드웨어를 검색하여 운영 체제에 등록하고 장치에서 실행중인 소프트웨어에서 사용할 수 있도록 한다.
클라이언트 소프트웨어를 로딩할 때, 클라이언트 소프트웨어(예를 들어, APP(142))는 장치의 운영 체제에 물질적 무선 라디오 인터페이스 및 그들의 기능을 문의한다. 이러한 인터페이스와 기능은 일반적으로 장치의 운영 체제에서 무선 인터페이스로 관리되며 장치에서 실행되는 소프트웨어 프로그램에 드라이버, 프로토콜 및 기능을 제공한다. 이 정보는 클라이언트 소프트웨어에서 볼 수 있다. 그러한 인터페이스의 예는 WiFi 인터페이스, 셀룰러 인터페이스, 햄 무선 인터페이스 및 위성 인터페이스를 포함한다.
클라이언트 소프트웨어 인터페이스는, 예를 들어 장치의 메모리 내에, 장치 또는 그의 하드웨어의 추가 성능을 나타내는 합성 인터페이스들의 목록을 유지할 수 있다. 일례로 패킷 라우팅을 위한 장치의 기본 인터넷 연결을 사용하는 조정 인터페이스가 있다. 또 다른 예는 장치에 연결된 GPS 수신기로 네트워크하는 GPS 인터페이스가 있다. 합성 인터페이스는 장치의 하드웨어 기능에 의해 제한될 수 있다. 이러한 상황에서, 클라이언트 소프트웨어는 물질적 및 합성 인터페이스와 그들이 가상화하는 물질적 하드웨어의 기록(예를 들어, 소프트웨어 레코드)을 유지할 수도 있다. 예를 들어 WiFi 인터페이스와 기본 인터넷 인터페이스 모두 장치의 WiFi 하드웨어를 사용할 수 있다. 장치의 운영 체제 또는 클라이언트 소프트웨어는 이러한 종속성을 추적하고 선택적으로 이를 중앙 서버에 보고할 수 있다.
사용 가능한 무선 인터페이스의 리스트를 사용하여, 클라이언트 소프트웨어는 중앙 서버(들)(110)와 신뢰성 있는 통신 및/또는 도달이 가능한 인터페이스들을 식별한다. 이 인터페이스들은 중앙 서버(들)(110)로의 직접 연결로서 작용할 수 있는 것으로 내부적으로 표시될 수 있다.
클라이언트 소프트웨어는 또한 필요하다면/필요할 때 서버(들)(110)에 보고될 수 있는 다수의 장치들에 특정된 측정 항목들을 유지할 수 있다. 이러한 측정 항목들에는 클라이언트의 배터리 잔량, 클라이언트의 외부 전원 공급 여부, 안정적인 인터넷 연결 여부, 클라이언트의 IP 주소, 위치, 방향 및 동작 및/또는 기타 측정 항목이 포함될 수 있다. 또한 클라이언트 소프트웨어는 제조 번호, 장치 제조업체 및 모델, 소프트웨어 버전 또는 제조업체 특정 고유 식별자 또는 기타 식별자와 같은 식별 정보를 관리할 수 있다. 이 정보는 서버(들)(110)에 제공되어 장치 및 장치의 능력에 관한 정보를 확인 가능하게 만든다.
서버 부트
현재 바람직한 예에서, 중앙 서버(110)가 시작되고 일련의 초기 데이터 구조 또는 데이터베이스(예를 들어, 데이터베이스(112))를 구축 또는 접속하여 이들을 접속 가능하게 만든다. 이러한 데이터베이스에는 이전 세션(예 : 마지막으로 실행된 세션)의 정보, WiFi 핫스팟의 위치 및 기타 측정 항목, 셀룰러 기지국 및 서버 서비스 영역의 기타 게이트웨이, 자격이 있는 클라이언트의 데이터베이스, 클라이언트의 계정 및 결제 정보를 포함한다.
그 구성에 따라, 서버는 다음으로 외부 데이터베이스(예를 들어, 데이터베이스(들)(112)의 일부) 또는 서버에 일련의 원격 접속을 개시할 수 있고, 국부적으로 저장되거나 검색될 수 없는 추가 정보를 얻을 수 있다. 전형적인 예는 서버가 제조 번호, 핫 스폿 또는 장치의 MAC 주소, MMC(멀티 미디어 카드), IMEI 또는 SIM 관련 정보를 비롯한 클라이언트들의 국부적으로 저장된 정보들 또는 서버의 상태를 복원하거나 서비스 영역 내에서 서버의 기능을 초기화하는데 필요한 여러 가지 측정항목들을 포함하는 원격 데이터베이스(예를 들어, 장치 정보 데이터베이스(124) 및 로컬 정보 데이터베이스(126))로부터 문의하는 것을 포함한다.
서버(110)는 또한 자신의 성능, 네트워크 성능 또는 접속된 클라이언트의 성능을 추적하기 위해 하드웨어 또는 소프트웨어로 하나 이상의 이력 기록(로깅) 구조를 설정할 수 있다.
마지막으로, 중앙 서버(110)는 클라이언트로부터 데이터를 수신하기 위한 하나 이상의 청취 인터페이스를 호스팅하기 시작한다. 전형적인 예는 웹 서버의 특정 제어 포트에서 TCP/IP 연결을 청취하기 시작하는 TCP/IP 웹 서버가 있다.
제1 단계-스타트업, 등록, 인증
클라이언트 소프트웨어를 실행하는 장치는 중앙 설비(104) 또는 인터넷에 중앙 서버(들)(110)에 접속할 수 있는 인터페이스에 도달 가능성을 주기적으로 확인한다. 클라이언트 소프트웨어(예를 들어, APP(342))는 장치의 운영 체제가 제공하는 시스템 서비스를 이용해 네트워크 연결을 결정하는 데 사용할 수 있다. 예를 들어, Android 기반 장치에서 Android Connectivity Manager 서비스를 사용할 수 있다. iOS 핸드셋에서 CFNetworking 도달 가능성 서비스를 이 용도로 사용할 수 있다.
이러한 서비스는 서버(들)(110) 및/또는 서버(들)에 접속하는 게이트웨이(들)(106)에 도달하기 위해 애플의 봉쥬르(Bonjour) 네트워킹, 비콘 프레임 또는 다른 기술과 같은 기존의 네트워크 발견 서비스를 사용할 수 있다. 도달 가능성 업데이트를 제공하지 않는 인터페이스 또는 장치는 도달 가능성을 결정하기 위해 주기적으로 폴링될 수 있거나 특정 타임아웃을 가진 이러한 인터페이스에서 연결이 시도될 수 있다. 폴링 스케줄은 클라이언트 소프트웨어 상에 저장될 수 있으며 일반적으로 초 단위의 폴링 빈도 및/또는 타임아웃을 포함한다. 연결되지 않은 인터페이스에서 연결을 시도하면 장치는 미리 결정된 일정에 따라 인터페이스에서 주기적으로 하나 이상의 패킷을 전송하고 서버에서 등록 과정을 시작하기 위한 응답을 기다린다.
인터페이스 유형에 관계없이, 클라이언트 소프트웨어는 될 수 있는 한 각각의 인터페이스의 접속 스케줄에 따라 중앙 서버(들)(110)에 모든 적격한 인터페이스상의 접속을 동시에 시도한다. 이 정보는 유선 인터넷 연결 인터페이스, 사전 설정된 라디오 링크 인터페이스(예 : 캐리어에 대한 셀룰러 연결), 위성 인터페이스, 장거리 주파수(예 : AM/FM 라디오) 인터페이스, 다른 장치와 직접 연결 가능하거나 메시(meshing)가 가능한 네트워크 인터페이스, 셀룰러 또는 WiFi와 같은 인터넷 연결 인터페이스를 통해 전송될 수 있다. 그러한 접속 중에, 위성 공급자 또는 셀룰러 캐리어와 같은 중개자의 경우, 그 중개자와 서버(들)(110) 사이에 신뢰성 있는 접속이 성립된다는 것을 가정할 것이고, 프록시는 장치 및 서버(들)(110) 양자에 하나의 연결로서 표시된다. 전형적인 애플리케이션에서, 이러한 가정은 IP 기반 프로토콜을 구현하는 셀룰러 또는 WiFi 연결에 의해 충족된다.
중앙 서버(110)가 접속 요청을 수신하면(예를 들어, 패킷으로서), 이는 요청에 포함된 식별 정보를 등록된 클라이언트에 의해 관리되는 활성 접속 리스트와 비교한다. 요청 패킷의 형식이 잘못되었거나 읽을 수 없는 경우 패킷은 삭제된다.
요청 패킷이 미지의 장치로부터 오는 것이라면, 미등록 장치가 서버(110)에 접속되었다고 가정한다. 서버(110)는 이 미등록 장치에 대한 임시 인증 토큰을 발행하여 저장하고, 인증 토큰을 포함한 인증 응답 패킷으로 응답한다. 연결이 알려진 장치에서 발생한 경우 패킷은 네트워크의 가상 지도에 일치하는 인터페이스로 내부적으로 라우팅될 수 있다.
인증 토큰은 예를 들어 가변 길이의 문자, 숫자 또는 비트의 스트링일 수 있다. 토큰은 보안을 위해 특정 타임아웃 후에 만료되도록 설정할 수 있다.
장래의 클라이언트는 서버로부터 인증 응답 패킷을 수신하고 패킷으로부터 인증 토큰을 추출한다. 클라이언트는 장치의 인터페이스 목록에 있는 그 인터페이스의 연결 상태를 "보류"로 업데이트한다. 그러면 클라이언트는 인증 확인 패킷을 생성하고, 등록 토큰을 사용하여 연결 인터페이스를 등록하고, 중앙 서버에서 제2 응답 확인을 기다린다. 확인되면 요청 장치는 이 무선 장치를 제어 정보를 안정적으로 송수신할 수 있는 서버 연결 제어 인터페이스로 식별한다. 이것이 중앙 서버(110)에 등록하는 장치의 첫 인터페이스이면, 인터페이스는 주 제어 인터페이스로 지정된다.
라우팅 장치가 서버로의 직접 업링크를 통해 서버(들)(110)에 성공적으로 등록할 때, 라우팅 장치는 서버(들)(110)의 클라이언트가 된다. 장치가 서버/중앙 시설에 직접 업링크가 있는 것이 제일 좋지만, 장치는 의사 게이트웨이를 사용하여 서버에 등록할 수 있다. 클라이언트에서 실행되는 소프트웨어(예 : APP(342))는 그 후 장치 내부의 각 무선 라디오 및 네트워크 인터페이스의 기능을 검색 및 컴파일 한 다음 이 정보 또는 같은 정보를 제공하는 식별자와 같은 기타 측정 항목들을 주 제어 인터페이스를 통해 서버로 전송한다. 특정 인터페이스에 대한 프로세스는 제조업체의 사양에서 모든 물질적 기능을 결정할 수 있는 장치의 네트워크 인터페이스 카드(NIC)의 제조 번호를 대신 전달하거나 클라이언트가 임의의 수의 인코딩을 사용하여 유사한 정보를 보고 하며 더욱 수월해질 수 있다.
클라이언트는 중앙 서버에 각 인터페이스의 가상 지도에서 각 인터페이스의 초기 구성 상태를 제공하기 위해 이 등록 정보와 함께 사용 가능한 무선 라디오 및 주소, 로컬 IP 주소 및 인접한 또는 연결된 게이트웨이(알려진 경우)를 서버로 보고할 수 있다.
초기 또는 그렇지 않은 클라이언트의 구성 상태는 잠재적인 구성이 아닌 클라이언트의 실제 구성을 나타낸다.
이 시점에서, 클라이언트는 서버가 클라이언트를 완전히 등록하기 전에 유일한 ID 및/또는 공개 암호화 키를 서버(들)(110)에 제공해야 할 수도 있다. 이 ID 또는 키는 예를 들어 장치의 SIM 카드, 송수화기, ROM(Read-Only Memory)에 저장되거나 사용자가 계정 사용자 이름 및 암호로 입력할 수 있다. 클라이언트가 식별자를 보고하지 못하면 이후 통신을 위해 식별자가 클라이언트에 할당되거나 서버가 장치의 인증을 거부할 수 있다. 통상의 기술자에게 필요한 것과 같이 클라이언트와 서버 사이에서 제어 정보의 추가 교환이 교환될 수 있다.
제2 단계 -표준 실행
위에 설명된 등록 프로세스를 사용하여 하나 이상의 클라이언트가 서버(110)에 비동기적으로 접속하고 클라이언트들이 접속하며, 서버(110)는 각각의 클라이언트를 이전에 등록된 클라이언트와는 별도로 등록절차를 수행한다고 가정한다. 서버(110)는 장치, 보안 레벨, 위치, 또는 보고된 임의의 장치의 측정 항목에 따라 등록 프로세스를 선택적으로 추려나가면서 어떤 클라이언트가 접속할 수 있는지를 제한하거나 우선 순위화할 수 있다. 클라이언트가 등록되면 그들의 인터페이스는 네트워크의 범용 전반전인 가상 지도에 의해 저장되고 관리된다.
서버 실행 루프
서버(110)의 실행 루프의 예가 도 5a의 흐름도에 도시되어 있다. 위에 설명된 바와 같이, 그들의 스타트업의 일부로서, 중앙 서버(들)(110)는 클라이언트로부터 데이터를 수신하기 위한 하나 이상의 청취 인터페이스를 호스팅하기 시작한다. 중앙 서버는 장치로부터의 새로운 데이터 요청을 지속적으로 기다린다. 등록된 클라이언트들로부터의 데이터 요청은 서버(들)(110)가 클라이언트 인터페이스가 등록되었음을 확인할 수 있게 하는 정보를 포함해야 한다. 그러한 정보의 예는 데이터의 소스 IP 주소 또는 소스 MAC 주소일 수 있다. 데이터가 수신되면 데이터의 패킷 헤더에 보고된 소스 장치가 네트워크의 가상 지도에 있는 등록된 클라이언트 인터페이스 목록과 비교된다.
이제 도 5b-5c의 흐름도의 예를 참조하면, 인터페이스가 서버의 가상 네트워크 지도에 등록되어 있지 않으면 서버는 클라이언트 등록을 시도한다. 등록 절차는 어떤 형태로든 가능하며 사용자 식별, 장치 식별 및 기타 정보가 필요할 수 있다. 인터페이스가 특정 클라이언트에 등록되어 있으면, 데이터는 도 5c에 개략적으로 설명된 인터페이스 데이터 처리 과정으로 전달된다. 이 취급자에서 등록된 클라이언트 정보는 인터페이스를 사용하여 검색된다. 서버는 먼저 인터페이스를 사용하여 등록된 클라이언트 정보를 로드하고 데이터 요청의 유효성을 검증한다. 데이터 요청이 유효하지 않은 경우, 서버는 네트워크의 가상 지도로부터 클라이언트의 직접 다운링크 인터페이스를 로드하고, 유효하지 않은 패킷이 직접 연결을 통해 그 인터페이스에 수신되었다는 표시(예를 들어, 패킷)를 전송한다.
데이터 패킷이 유효한 경우, 서버는 데이터 패킷의 종류로부터 들어오는 데이터를 어떻게 처리할지를 결정한다. 전형적인 예에서, 토폴로지 업데이트, 경로 확인, 인터페이스 업데이트 및 장치 업데이트는 패킷에 포함된 정보를 사용하여 서버의 데이터베이스를 업데이트하고, 선택적으로 원격 위치로부터 정보를 요청하며, 경로 최적화 및 추가 라우트 해결같은 서버에 의해 수행될 계산 작업을 계획한다.
클라이언트로부터의 데이터 요청
서버(110)는 요청된 데이터를 받을 장치 102를 식별한다. 그런 다음 요청을 큐잉하고(queues) 요청된 데이터의 위치를 식별한다. 요청된 데이터는 예를 들어 원격 서버에서 호스팅되거나, 서버 내에서 국부적으로 호스팅되거나, 및/또는 네트워크 내의 개별 클라이언트 장치에서 호스팅될 수 있다. 요청된 데이터가 원격 서버 상에 있다면, 서버(110)는 요구된 데이터를 가져 온다. 일단 서버(110)가 원격 또는 로컬 소스로부터 요청된 데이터를 받으면, 서버는 요청된 데이터를 목적지 장치에 송신하는 라우트를 결정한다. 요청된 데이터가 네트워크 상의 클라이언트에서 호스팅되는 경우 서버는 요청된 데이터를 호스팅하는 클라이언트에서 대상 장치까지의 라우트를 결정한다. 통상의 기술자라면 이 설명을 읽고 이것은 안전한 서브넷의 생성을 허용하고, 네트워크 내의 장치들에 저장된 캐시 정보를 사용하여 클라우드 기반 콘텐츠 전달 네트워크(CDN)를 가능하게 한다는 것을 알 수 있을 것이다. 상기 시스템은 네트워크 내의 장치들에 데이터를 사전에 저장/캐싱할 수 있고, 곧 활발한 CDN을 형성할 수 있다.
또한, 중앙 설비는 가상 네트워크에서 처리될 각각의 클라이언트를 위한 스케줄을 결정하고 필요할 때 각각의 클라이언트를 위해 계산 작업을 수행하기도 한다. 본 발명의 전형적인 예들은 이웃하는 장치 데이터 요청들의 결과로서 생성된 새로운 라우트들이 클라이언트로 전송될 필요가 있는지와 클라이언트가 원격 서버들로부터 큐잉된 그들의 요청에 대한 응답을 받았는지 여부를 지속적으로 확인한다.
네트워크의 통합적 관점 형성
전체 네트워크 토폴로지의 통합적 관점은 다음과 함게 형성된다:
1) 각각의 장치는 패킷을 수신할 수 있는 다른 장치들을 결정한다. 방송된 패킷은 중계 또는 수신을 위해 어느 곳에서(즉, 어떤 장치) 패킷이 오고 누구에게 가는지에 대한 정보를 갖고 있다. 따라서 패킷을 받는 대상에 관계없이 패킷을 받는 장치는 주어진 시간에 어느 다른 장치를 들을 수 있는지 기록할 수 있다. 알 수 있는 바와 같이, 특정 장치는 시스템의 클라이언트가 아닌 다른 장치를 듣고 그로부터 패킷을 수신할 수 있다.
2) 각 장치는 그것이 들을 수 있는 장치들의 리스트 및 패킷들이 이들 장치들로부터 수신된 시간을 중앙 서버에 전송한다. 게이트웨이에 직접 연결되지 않은 장치의 경우 분산형 또는 기타 프로토콜을 사용하여 의사 게이트웨이에 직접 연결하거나 의사 게이트웨이에 연결된 다른 장치 체인을 통해 의사 게이트웨이에 연결할 수 있다.
3) 중앙 서버는 모든 개별 토폴로지 지도를 모아서 통합적 관점을 생성한다. 중앙 서버는 패킷이 수신되었을 때 찍힌 시간 도장을 방송 장치의 장소와 일치시켜 이력 토폴로지 지도에 알린다.
활성 경로 최적화
서버(110)는 각 클라이언트의 활성 전송 경로의 성능을 최적화할 수 있다. 서버는 클라이언트의 개별 토폴로지들의 집합을 통해 수집된 전체 네트워크 토폴로지의 통합적 관점을 유지함으로써 전체 네트워크의 성능을 최적화하는 알고리즘을 사용할 수 있다. 여기에는 흐름 및 처리량을 극대화하는, 전송 비용을 최소화하는, 전송을 완료하는 데 필요한 배터리 양을 최소화하는, 정체 및 충돌을 줄이는, 간섭을 줄이는, 클라이언트가 사용할 수 있는 채널을 네트워크 인터페이스 카드나 사용 가능한 안테나의 수로 표시된 대로 효율적으로 사용하는 등등의 최적화들이 포함될 수 있다. 이러한 최적화는 활성 경로를 모니터링하고 이러한 경로를 국부적 토폴로지, 전송 비용, 장치 수 및 데이터 수요 변화에 대한 업데이트와 같은 새로운 정보로 재구성하여 실시간으로 비동기적으로 발생할 수 있다. 새로운, 또는 보다 최적의 해답을 사용할 수 있게 되면 경로가 비동기적으로 교체될 수도 있다.
서버는 로컬 또는 원격 데이터베이스를 이용하여 이러한 최적화를 생성할 수 있다. 서버에는 데이터를 전송하는 데 최고의 라우트를 계산할 때 현재 네트워크 데이터 수요, 클라이언트 위치같은 정보나 셀 타워 위치, WiFi 핫스팟 위치 및 기타 게이트웨이 위치와 같은 원격 정보를 사용할 수 있다. 예를 들어, 서버는 주어진 시간에 주어진 영역에서 전송에 대한 지역 가격 정보를 얻기 위해 셀룰러 사업자의 서버에 문의할 수 있다.
사전 계산
라우트는 네트워크의 클라이언트가 데이터 요청을 함에 따라 실시간으로 중앙 설비(104)에 의해 계산될 수 있다. 대안으로, 대기 시간을 줄이기 위해서, 중앙 설비(104)는 네트워크의 실시간 토폴로지를 기초로 하여 라우트를 사전에 계산할 수도 있다. 네트워크 내의 클라이언트 또는 클라이언트들이 데이터를 요청하면, 전송에 적합한 것으로 결정된 사전 계산된 라우트 하나가 사전 계산된 라우트들의 집합으로부터 선택될 수 있다. 라우트의 사전 계산은 라우트 처리 요구를 분산시키기 위해 계획/사용될 수 있다, 따라서 처리 용량이 제한된 라우트에 갑작스러운 요청들이 넘쳐날 때, 요청이 처리될 수 있는 적절한 사전 계산된 라우트(들)로 서버에 요구를 감소시킬 수 있다. 인식할 수 있는 바와 같이, 시스템이 실제로 루트 요청의 갑작스러운 쇄도가 서버로 유입되는 것은 방지하지는 못하지만, 시스템은 들어오는 요청에 대해 하나 이상의 미리 계산된 라우트를 즉시 이용할 수 있게 함으로써 그러한 경우를 대비할 수 있다. 이러한 방식으로, 시스템은 라우팅 요청 큐가 형성되는 동안 초과 지연을 경험하는 요청들을 피할 수 있다. 또한 사전 계산은 대기 시간을 줄이는 데 유용할 수 있다. 초과 계산 능력이 있는 경우 처리와 관련된 지연 시간을 발생시키지 않으면서 충분한 라우트를 더 빨리 제공할 수 있다. 라우팅 요청의 큐가 있는 경우 미리 계산된 라우트와 이력 전송 지도들을 사용하면 큐의 크기를 줄일 수 있다. 또한 미리 계산된 라우트는 동적 환경에서는 만료되거나 운영 비용을 줄이기 위해 서버가 하나 이상의 클라이언트에 허용할 수 없는 대기 시간을 감지할 때만 수행될 수도 있다.
데이터는 클라이언트에게 전송될 서버(들) 상에 큐잉될 수 있다. 큐잉된 데이터는 될 수 있는 한 실시간으로 보내질 것이지만 서버 제한으로 인해 지연될 수 있다. 큐잉된 데이터는 될 수 있는 한 계산된 라우트를 통해 각 클라이언트에 전송된다. 계산된 라우트는 직접 다운 링크(예를 들어, 직접 셀룰러 또는 WiFi 연결을 통해 패킷을 송신하는 것), 우회적인 다운 링크(예를 들어, 네트워크의 피어 투 피어 부분을 통해 패킷을 송신하는 것), 또는 이들 모두를 동시에 이용할 수 있다.
클라이언트 실행 루프
중앙 서버(들)(110)에 등록이 완료된 장치들은 중앙 서버(들)의 클라이언트들이 된다. 클라이언트 소프트웨어는 도 5d에 명시된 절차에 따라 활동을 실행한다.
데이터 요청
등록된 클라이언트는 중앙 서버(110)에 등록된 직접 업링크 인터페이스를 통해 데이터를 요청한다. 데이터 요청은 클라이언트 소프트웨어, 장치의 운영 체제 혹은 장치의 사용자 인터페이스로부터 생길 수 있다. 전형적인 예에는 휴대폰이 웹 브라우저를 열어 웹페이지를 로딩하려는 예가 있다.
중앙 서버(들)(110)로의 직접 업링크가 없는 장치 혹은 클라이언트는 분산화된 장치 혹은 클라이언트로 지칭된다. 이러한 직접 업링크가 없는 장치들은 그들의 통신이 중앙 시설 104로부터 직접적으로 조정될 수 없기 때문에 분산화되었다고 한다. 분산화된 장치 혹은 클라이언트들의 집합은 분산화된 서브 네트워크를 형성할 수 있다.
분산화된 장치/분산화된 서브 네트워크의 클라이언트들로부터의 요청들은 분산화된 서브 네트워크를 사용하여 서버(들)(110)와의 직접 업링크 연결을 갖는 의사 게이트웨이로 보내질 수 있다. 예를 들어 BATMAN, OLSR, 혹은 비슷한 분산화된 통신 프로토콜을 사용할 수 있다. 의사 게이트웨이는 그 후 서버(들)(110)에 요청들을 보낼 수 있다.
그런 요청이 발생되면, 클라이언트 소프트웨어는 나가는 데이터 요청을 장치에 커널로부터 혹은 유저공간 애플로리케이션으로부터 가로채고, 데이터 요청을 클라이언트 소프트웨어로 보낸다. 클라이언트 소프트웨어는 주 혹은 최적의 직접 인터페이스를 식별하고, 데이터 요청을 직접 인터페이스상으로 서버에서 제공한 임의의 라우트 명령에 따라 중앙 서버로 보낸다.
추출 요청(서버상에서, 멀리 떨어진 독립체로부터)
현재 바람직한 예에서, 데이터 요청은 직접 업링크를 통해 인터넷으로 라우팅된다. 요청은 중앙 설비(104)로, 될 수 있는 한 인터넷을 통해 중계된다. 서버(110)는 이 업링크를 조정하기 위해 초기 업링크 라우트를 네트워크의 각 클라이언트에게 제공할 수 있으며, 또는 클라이언트는 제1의 등록된 직접 인터페이스를 직접 업링크로 이용하여 그들의 데이터 요청을 라우팅할 수 있다.
일부 경우, 중앙 설비는 요청하는 클라이언트가 데이터를 직접 업링크 연결로 업로드를 하는 대신에, 우회적인 경로를 통해 데이터 혹은 데이터 요청을 업로드하는 것이 최적으로 결정될 수도 있다. 그러한 경우의 예는 클라이언트가 대용량 파일을 업로드하려고 시도하는 경우 또는 업링크 채널에 심각한 혼잡이 있는 경우 또는 기타 이유가 있다. 이러한 경우 중앙 시설은 업로드 클라이언트가 데이터를 라우팅하는 데 우회적인 업링크 경로를 결정할 수 있다. 본 발명의 바람직한 예에서 이러한 라우팅 명령은 직접 다운링크를 통해 업로드 클라이언트에 전송될 수 있지만, 대안으로 이러한 라우팅 명령은 우회적인 경로를 통해 통신될 수도 있다.
직접 업링크를 통해 데이터를 업로드 하는 것이 효율적인지 아닌지에 관계 없이, 업로드 클라이언트는 서버가 우회적인 라우트를 통해 데이터를 업로드할 수 있는 라우트(예 : 경로, 채널, 타이밍, 범위 등)를 보내기 요청할 수 있다. 그러한 요청은 클라이언트가 업로드된 데이터가 중앙 서버(들)(110)를 통해 수신되고 처리될 필요가 없도록 안전한 서브 네트워크 전송을 생성하고자 하는 경우에 이루어질 수 있다.
도 5e는 네트워크 내의 클라이언트가 데이터(예를 들어, 자원)를 요청할 때 서버((110))에서의 전형적인 작업의 흐름을 나타낸다. 자원은 모든 종류의 데이터로 형성되거나 나타날 수 있으며, 시스템은 자원 또는 데이터의 종류 또는 자원 또는 데이터가 표기하는 것에 의해 제한되지 않는다. 자원의 예로는 웹 페이지, 이미지, 비디오, 문자, 오디오 등이 포함되며 이에 제한되지는 않는다. 자원은 정적 또는 동적(예 : 특정 요청마다 즉시 생성)일 수 있다. 자원에는 스트리밍 자원(예 : 스트리밍 오디오 및/또는 비디오 내용물)이 포함될 수 있다. 서버는 대상 목적지 또는 자원이 국부적, 원격 또는 다른 등록된 클라이언트인지 판별한다. 요청이 원격 인 경우, 인터넷 또는 원격 자원에 가능한 연결을 사용하여 자원을 가져온다. 자원이 국부적인 경우, 서버는 자원을 국부적으로 가져온다. 의도된 수신자도 클라이언트인 경우 서버는 업로드 라우트를 설정하고 대상 클라이언트에서 요청된 데이터를 가져오기 위한 요청을 수행할 수 있다.
몇몇의 경우, 예를 들어, 다수의 클라이언트가 동일한 자원을 요청할 때, 서버는 그 정보를 국부적으로 캐시하여 정보의 일련의 원격 다운로드를 피하려고 시도할 수 있다. 예를 들어 자원이 인기가 많아질 경우 시스템에서 WiFi 핫 스폿과 같은 게이트웨이에 직접 연결되는 장치로 많은 복사본을 내보낼 수 있다. 그런 다음, 해당 정보를 캐시한 장치 근처에 있지 않은 다른 장치가 해당 자원을 요청하면 중앙 서버는 해당 캐싱 장치에 이를 요청한 장치로 자원을 보내도록 알릴 수 있다. 서버는 또한 다수의 클라이언트에 효율적으로 서비스를 제공하기 위해 콘텐츠 제공자(예를 들어, 콘텐츠 출처(114))와의 접속을 확립할 수 있다. 이러한 시스템은 여러 클라이언트가 동시에 데이터를 스트리밍하는 비디오 컨텐트 공급자의 시스템일 수 있다.
데이터의 조절을 위한 원격서버에 라우트/경로/장치 정보 제공.
일부 경우, 다수의 요청 장치 102는 각각 원격 컨텐츠 제공자/서버 비디오(예를 들어, Netflix 등과 같은 컨텐츠 출처(114))로부터의 비디오와 같은 스트리밍 자원을 요청할 수 있다. 중앙 서버(110)는 원격 컨텐츠 제공자에게 네트워크에 관한 정보를 제공할 수 있다. 이 정보에는 클라이언트의 위치, 기능 또는 동기화 정보가 포함될 수 있다. 서버(110)는 또한 라우트의 성공적일 확률 및 정보가 어떻게 전송되고 있는지와 같은 라우트 계산의 결과를 제공할 수 있다. 원격 서버는 이 정보를 사용하여 라우팅 서버에 어느 콘텐츠가 제공되는지 결정할 수 있다. 예를 들어 비디오를 스트리밍할 때, 라우팅 서버는 네트워크상의 혼잡에 대한 정보를 통신할 수 있고, 원격 컨텐츠 제공자는 전송을 통해 더욱 낮은 비트 전송률의 비디오 스트림을 제공할 수 있다. 전송 중에 비트 전송률을 변경하거나 낮은 비트 전송률 비디오를 제공할때 서버가 높은 오류율 환경을 감지하거나 클라이언트가 곧 핸드오프를 수행하거나 연결 대기 시간이 좋지 않을 때 유용하다; 낮은 비트 전송률인 스트림으로 전환할 때 시스템이 비디오의 단절이나 프레임 손실을 일으키지 않고 비디오 스트리밍을 유지할 수 있다.
가상 서브넷
클라이언트가 서로 직접 데이터를 교환하고자 하는 상황이 있을 수 있다. 제1 클라이언트는 제2 클라이언트에 저장된 자원을 요청할 수 있고, 제1 클라이언트는 다른 클라이언트와의 통신 터널을 열기를 원할 수 있거나 또는 클라이언트들은 서로 안전하게, 그리고/또는 익명으로 데이터를 교환하기를 원할 수 있다. 또한 클라이언트는 자원의 위치를 알지 못해도 서버에 자원을 요청할 수 있다. 이러한 상황에서 서버는 하나 이상의 클라이언트를 사이에 가상 서브 네트워크를 만드는 과정을 수월하게 하고, 요청된 자원을 찾고, 네트워크에 다른 장치로부터 요청하는 클라이언트에게 요청된 자원을 제공하는 면에서 사용될 수 있다. 서버를 사용해 가상 서브 네트워크를 만드는 것에 한가지 장점은 가상 서브네트워크에서 제외된 장치들이 데이터를 보안 네트워크 상에 다른 장치에 안전하게 라우팅할 수 있는 것이다. 서버와의 피어-투-피어 전송 스케줄링은 또한 피어-투-피어 전송이 게이트웨이-대-장치 또는 게이트웨이-대-멀티 홉 네트워크 전송과 공존할 때 발생하는 간섭 문제를 완화한다. 마지막으로, 서버의 토폴로지 지도는 장치가 다른 장치와 그들의 자원을 검색할 수 있는 안전하고 익명의 방법을 제공한다. 여기서 서버는 장치의 연결 촉진자로 선택적으로 보안, 경로 라우팅 및 오류 해결을 처리한다.
이 절차의 응용중 하나는 제1 클라이언트가 자원(예를 들어, 이미지, 비디오, 파일 등)을 요청하고 중앙 설비(104)가 요청된 자원에 대한 접속을 제2 클라이언트에게 문의하는 경우에 발생한다. 그런 다음 중앙 서버는 현재 토폴로지 지도를 사용하여 자원에서 요청 클라이언트까지의 경로를 생성할 수 있다. 경우에 따라 경로는 하나 이상의 게이트웨이를 통하여, 하나 이상의 클라이언트를 통하여, 혹은 선택적으로 서버를 통하여 데이터를 라우팅할 수 있다. 장치, 사용자 또는 토폴로지 지도가 선호하는 경우 서버는 데이터가 인터넷이나 서버를 통해 이동하지 못하게 하는 경로를 생성한다. 이렇게 하는 것은 전송의 비밀성을 증가하고 왕복 의 지연을 줄일 수 있다. 또한 요청된 자원이 큰 경우 피어-투-피어 네트워크를 통해 정보를 라우팅하여 정체된 직접 업링크를 피하면 로컬 네트워크의 성능이 향상될 수 있다.
이 절차의 두 번째 응용은 사용자에 의해 모바일 환경에서 실시간으로 생성된 콘텐츠를 포함한다. 클라이언트는 생방송 비디오를 스트림하던가, 사진을 찍거나, 음성 통화에 참여하거나, 게임과 같은 공동 활동에 참여할 수 있다. 이러한 상황에서, 데이터가 서버(들)를 지나치고 가상 서브 네트워크에 있는 클라이언트들 사이에서 스트림될 수 있게 서버는 이 장치들을 가상 서브 네트워크로 결합할 수 있다. 제1 클라이언트와 제2 클라이언트가 물리적 공간에서 서로 가까이 있을 필요는 없다. 네트워크 상에 두 개 이상의 클라이언트 간에 통신을 설정하기 위한 유일한 요구 사항은 요청된 자원을 전송할 수 있는 라우트를 만들 수 있다는 것이다.
이러한 가상 서브 네트워크를 생성하고 유지하기 위해 서버는 토폴로지 지도와 클라이언트로의 활성 통신 경로를 활용한다. 클라이언트가 가상 서브 네트워크의 가입, 생성 또는 탈퇴를 요청하면, 서버는 하나 이상의 데이터베이스에서 각 가상 서브 내트워크의 상태와 각 네트워크에 있는 클라이언트들을 관리한다. 클라이언트 장치 간의 라우트는 통신 경로로 관리되고, 네트워크의 다른 활성 경로들과 함께 스케줄된다. 클라이언트는 가상 서브 네트워크의 다른 클라이언트에 데이터를 전송할 때 서버가 제공한 통신 경로를 사용한다. 가상 서브 네트워크로부터 제외된 클라이언트들도 가상 서브 네트워크를 연결하는 전송 라우트에 포함될 수 있다. 전송 라우트가 가상 서브 네트워크의 구성원이 아닌 장치를 포함하는 경우, 가상 서브 네트워크에서 보내지는 데이터를 가상 서브 네트워크의 구성원만이 해독할 수 있도록 암호화할 수 있다.
전송의 보안이 요구되거나 필요할 때, 서버는 통신을 보안하기 위해 클라이언트 사이의 암호 키의 교환을 수월하게 도울 수 있다. 또는 서버는 두 클라이언트 모두를 위한 VPN처럼 작동할 수 있고, 클라이언트들이 공유된 VPN 에 일부인 것처럼 클라이언트 간에 데이터를 라우팅할 수 있다.
전송의 익명이 요구되거나 필요할 때, 서버는 데이터가 절대 인터넷을 통해 이동하지 않도록 로컬 경로만을 제공할 수 있다. 여기에서 "익명"은 클라이언트 및/또는 그들이 송수신하는 데이터의 어느 정도의 익명성을 지칭한다. 대안으로, 예를 들어 장치들이 물리적 공간에 서로 가까이 있지 않을 때, 서버는 익명으로 인터넷을 통해 데이터가 절대 서버를 통과하지 못하게 경로를 제공할 수 있다.
클라이언트가 가상 서브 네트워크를 합류, 탈퇴, 생성 또는 가상 서브 네트워크의 변수들을 수정하려 요청할 때마다, 서버는 네트워크의 수정을 허용하거나 허용하지 않도록 선택할 수 있다. 서버는 클라이언트 장치들 사이에서의 그리고 가상 서브 네트워크에서의 정보 교류를 중재할 수 있다. 이에 일반적인 예는 가상 서브 네트워크에 합류하기 전에 장치의 사용자에게 비밀번호를 입력하게 하는 것이 있다. 또 다른 사용자의 개입을 요구하지 않는 예에서, 서버는 클라이언트에게 암호로 메시지를 서명하도록 요청할 수 있다. 이 암호와 요청의 추가 메타 데이터는 사용자를 인증할 수 있는 서버로 제공될 수 있다. 서버는 선택적으로 특정 작업의 성공 혹은 실패를 나타내기 위해 오류나 확인 메시지를 장치에 보고할 수 있다.
가상 서브 네트워크를 형성하고 그곳에 합류하는 과정에 있어서, 서버는 장치들에게 통합적인 토폴로지 지도의 정보를 그 과정을 돕기 위해 제공할 수 있다. 이는 근처의 장치들을 발견하는 데 도움이 될 수 있다. 여기서 장치들은 검색 장치의 통신 범위 밖에 있고 다른 클라이언트들을 통해 그 장치로 가는 경로가 있을 때 서버는 검색 장치의 존재를 다른 장치들을 통해 도달할 수 있는 장치에 보고할 수 있다.
출력 데이터 큐
원격 자원으로부터 수신된 데이터는 불완전하거나, 더 큰 데이터 스트림의 일부일 수 있거나, 또는 전체적으로 가져와야 될 필요가 있을 수 있다. 적어도 이런 이유로, 서버(110)는 이러한 클라이언트에게 나갈 출력 큐를 유지한다. 새 데이터가 클라이언트로 가야될 때 그 데이터는 데이터 큐에 삽입된다. 새로운 경로가 해결되면, 패킷 크기에 의해 결정된 일정량의 데이터가 버퍼에서 꺼내지고, 데이터 패킷은 클라이언트로 전송되도록 예약되며, 큐 내의 다음 항목이 큐 위치의 맨 앞으로 이동된다.
앞에 설명된 클라이언트의 버퍼의 능력의 필연적인 결과로써, 새로운 데이터가 원격 자원으로부터 수신될 때, 새로운 경로가 해결되거나, 아니면, 불완전한 전송 후에 데이터가 재송신될 때, 데이터의 업데이트된 라우팅 정보나 통신 변수들을 수정하고 정보를 버퍼 속으로 재삽입하는 것이 가능하다. 이렇게 함으로 중앙 서버가 버퍼된 데이터의 순서를 우선으로 다시 지정할 수 있다. 예를 들어 새로운 게이트웨이가 다시 사용 가능해지고 그 게이트웨이를 사용하는 새 경로가 해결되면, 각 전송의 패킷 크기가 증가될 수 있다. 서버는 새로운 패킷 크기를 수용하도록 클라이언트의 버퍼를 재구성할 수 있다. 마찬가지로, 서버는 전송 중에 두 장치 간의 연결의 품질이 증가했거나 이전에는 통신할 수 없었던 두 장치가 이제 통신할 수 있다고 판단할 수 있다. 이러한 네트워크 토폴로지의 변화로 인해 서버는 전송 라우트를 수정하여 네트워크의 흐름을 최적화할 수 있다.
경로 해결
중앙 설비(104)는 될 수 있는 한 가상 인터페이스 지도를 네트워크 내의 임의의 두 인터페이스(예를 들어 WiFi, 셀 등) 사이의 단방향 신호 강도 및/또는 연결 품질 결정하는 데 사용할 수 있다. 중앙 서버(100)는 규칙적으로 신호 강도, 연결 품질, 다른 장치로의 연결 개수, 사용 가능한 채널들, 방송 범위, 스펙트럼 사용, 통신의 금전적 비용, 통신을 완료하기 위해 필요한 배터리 측정 소모량, 그리고 다른 측정 항목들을 측정하고 결정함으로 임의의 두 인터페이스 사이의 통신 품질을 결정한다. 연결들의 품질을 집계하고 특정 한계치를 넘는 것으로 결정된 연결들만을 포함한 연결된 그래프를 작성함으로, 중앙 서버는 라우팅 결정을 위해 사용 가능한 가상 네트워크 사이의 통신들을 최적화하기 위해 라우팅 알고리즘을 실행할 수 있다. 중앙 서버가 네트워크를 통한 이전의 모든 통신과 큐잉된 또는 현재 발생하고 있는 통신의 기록을 갖고 있기 때문에, 서버는 임의의 통신에 사용할 수 있는 최적의 다운링크 및 업링크 경로를 결정할 수 있다. 중앙 서버는 특정 시간에 어느 채널에서 점유된 링크의 기록을 계산하고 관리한다.
다중-홉 경로는 중앙 서버의 네트워크의 가상 지도를 사용하여 계산되고 분배된다. 경우에 따라 전체 경로는 메시 네트워크 내에서 절대 전송되지 않으며 네트워크의 서버 가상 지도에만 존재한다. 이는 라우팅 명령이 직접 연결(아마 셀룰러)을 통해 전송 경로의 각 장치들에 중계되는 경우다. 장치가 라우팅 명령을 우회적인 경로로 수신할 경우, 장치는 일반적으로 전체 라우팅 경로를 알 것이다.
네트워크의 가상 지도를 관리하고 탐색하기 위해 알고리즘들이 선택적으로 사용된다. 바람직한 검색 라우팅 결정을 내리기 위한 알고리즘은 다음을 포함하고 다음에 제한되지 않는다: 시간 변화탐욕 알고리즘, 시변 최소 배터리 소비, 시변 최소 홉, 시변 최소 스펙트럼 사용, 시변 최대 흐름, 시변 빠른 경로, 시변 최소 전송 비용, 시변 최대 신뢰도. 몇 가지의 예에서는 라우팅 알고리즘은 전기 콘센트에 연결되어 있거나, 배터리 전력 잔량이 높은 장치 등을 선호하도록 구성될 수 있다.
몇 가지의 예에서, 중앙 설비는 각각의 클라이언트가 요청하고 수신한 데이터양에 비해서 각각의 클라이언트를 통해 얼마나 많은 양의 데이터가 지나갔는지 추적할 수 있다. 중앙 설비는 요청한 데이터가 전달한 데이터보다 많은 장치를 통해 데이터를 라우팅하는 것을 선호하도록 데이터를 라우팅할 수 있다. 다른 장치를 위해 전달한 데이터가 수신한 데이터보다 더 많은 장치들에게 우선적인 전송 상태, 무로 전송, 또는 시스템에서 사용할 수 있는 크레딧을 제공할 수 있다.
몇 가지 예에서, 시스템은 사용자들에게 다른 사용자들에게 데이터를 전달하는 것을 보상할 수 있다. 이러한 보상은 돈이나 추가의 데이터를 받을 수 있는 크레딧일 수 있다. 이것은 기업자가 시스템이 데이터를 라우팅할 수 있는 무선 전송 네트워크 만들기를 구축할 것이다.
다중 라우팅 알고리즘들은 특정 상황에 대해 최적화될 수 있는 알고리즘으로서 사용될 수 있다. 예를 들어, 스포츠 경기장 등과 같은 밀도가 높은 지역에 있는 클라이언트들 사이에서 데이터를 라우팅하기 위해 사용될 알고리즘들은 밀도가 희박한 지역에서 정보를 라우팅하는 알고리즘과는 크게 다를 것이다. 전자의 경우, 특수화된 알고리즘이 전체 네트워크의 처리량을 강조하되, 후자의 경우, 특화된 알고리즘은 보편적인 연결을 강조할 수 있다.
중앙 서버(110)는 직접 업링크 및/또는 다운링크 접속을 통하거나 클라이언트들의 피어-투-피어 네트워크를 통해 우회적으로 데이터를 보내는 것이 빠른지 결정할 수 있다. 두 시스템이 하나의 자원을 전달할 라우트를 만들 때 함께 작동할 수 있다. 본 발명의 바람직한 예는 기존의 무선 네트워크에 부가 적으로 적용될 것이다. 중앙 시설의 운영자는 더 빠르고, 더 안전하고, 더 효율적이거나, 다른 방법들보다 더 나은 경우 오직 우회적인 방법으로 정보를 보내기를 선택할 수 있을 것이다.
다중 게이트웨이
도 6a에 명시된 바와 같이, 중앙 서버는 요청된 자원을 전송하기 위해 또는 클라이언트가 자원을 업로드할 때 이용할 라우트를 계산하기 위해 동일하거나 동일하지 않은 유형(예를 들어, 하나의 셀룰러 게이트웨이 및 하나의 WiFi 게이트웨이 또는 2 개의 WiFi 게이트웨이)의 여러 게이트웨이 이용하기를 결정할 수 있다. 서버가 다중 게이트웨이를 사용하도록 선택하는 경우 서버는 자원을 대략 적절하게 분할하고 지정된 부분(들)을 각 게이트웨이로 보내고, 각 경로에 관련된 각 장치에 라우팅 명령을 분리한다.
하나의 게이트웨이, 여러 마디의 전송
일부 경우에, 게이트웨이는 직접 연결된 장치가 2개 이상일 수도 있다. 게이트웨이는 자원의 일부가 목적지 클라이언트로 중계되는 서버에 의해 결정된 바와 같이 분할된 자원을 연결된 장치로 전송할 수 있다. 예를 들어, 도 6b에서 도시된 바와 같이, 게이트웨이는 클라이언트(1 및 2)에 연결되었다. 클라이언트(3, 6 또는 7) 중 하나로 자원을 보낸다고 가정하자. 게이트웨이(서버 명령에 따라)는 자원의 일부를 클라이언트(1)를 통해 (예 : 경로 ≪1, 3, 등≫) 그리고 일부를 클라이언트(2)를 통해 (경로 ≪2, 4, 5, 3, 등≫을 통해) 보낼 수 있다. 이 접근법은 게이트웨이가 임의의 단일 접속 마디보다 높은 처리량 능력을 갖는 경우에 유용하며, 이는 접속 강도, 안테나의 개수 등을 포함하지만 이에 한정되지 않는 많은 다른 문제로 인한 것일 수 있다. 게이트웨이는 클라이언트(1 및 2)와의 연결 및 상호작용을 위해 다른 프로토콜을 사용할 수 있다.
다중 게이트웨이, 다중의 마디.
일반적인 경우, 서버(들)로부터 클라이언트로의 전송은 다수의 게이트웨이 및 다수의 노드를 사용할 수 있다. 즉, 전송은 다중 - 게이트웨이/다중 - 노드 전송의 임의의 조합을 사용할 수 있다. 이것의 예가 도 6e에 명시되어있다. 여기서, 클라이언트(7)로 가는 경로는 게이트웨이 G1 및 G2(다중 - 게이트웨이)를 동시에 사용할 수 있으며, 여기서 게이트웨이 G1은 경로 ≪1, 3, 6, 7≫ 및 ≪2, 4, 5, 3, 6, 7≫을 동시에 사용할 수 있다.
전송 이력- 데이터 흐름을 주어진 측정 항목에 대해 최적화
서버는 실시간으로 각 클라이언트들에 대한 측정 항목들을 연속적으로 관찰하고, 네트워크 내의 각 클라이언트들과 관련된 전송 이력을 기록할 수 있다. 이러한 측정 항목에는 클라이언트의 위치, 클라이언트가 데이터를 수신할 수 있는 다른 클라이언트들, 클라이언트의 사용 가능한 네트워크 인터페이스, 사용 가능한 안테나 수, 클라이언트가 데이터를 송수신할 수 있는 채널들, 킬로줄(kj) 단위의 잔량 및 예상 작동 시간 단위 잔량 양쪽의 배터리의 잔량, 등이 포함될 수 있고, 이것들에 한정되지는 않는다. 기록된 전송 이력은 다른 클라이언트들을 위해 데이터를 전달하면서 소비된 배터리 소모량, 및 다른 클라이언트들이 개별 클라이언트를 위해 데이터를 전달하면서 소비한 배터리 소모량, 성공적으로 수신된 전송들 및 과거에 성공적으로 발신된 전송들을 포함할 수 있고 이에 한정되지는 않는다. 서버는 이러한 측정 항목들 및 전송 이력을 사용하여 네트워크의 클라이언트 간에 효율적이고 안정적인 전송 라우트를 결정할 수 있다.
또한, 서버(110)는 장치들 간의 성공적인 및 실패한 전송의 이력을 컴파일할 수 있다. 이러한 이력은 라우트를 계산 및 사전계산할 때 유용한 추가 정보를 제공할 수 있다.
데이터가 클라이언트에게로 어떻게 보내져야 하는지를 결정하기 위해, 서버는 데이터의 출처로부터, 일반적으로 중앙 서버로부터 목적지까지의 라우트를 계산하고, 속도, 신뢰성, 자원 요구 및 다른 라우트들이 필요할 다른 요소들을 측정한다. 서버는 이 모든 요소의 중요성을 측정하고 자원을 보내야 하는 최상의 라우트를 결정한다.
전송 이력은 네트워크 내의 각 장치에게 중요하지만, 전송 이력의 또 다른 관점은 각 장치로부터가 아니라 네트워크에서 가로지른 각각의 지점으로부터에 의한다.
중앙 서버는 토폴로지 지도를 여러 지점들의 집합으로 고려할 수 있다. 장치가 특정 지점에 있을 때 중앙 서버는 여러 장치에서 해당 지점의 전송들의 측정 항목들을 기록한다. 따라서 중앙 서버가 적절한 이력 토폴로지 지도를 작성한 후에 네트워크의 장치 위치를 아는 것만으로 네트워크 토폴로지를 잘 이해할 수 있다. 중앙 서버가 이력 토폴로지 지도와 장치(들) 위치를 사용하여 라우팅 결정을 내리면, 장치가 주변 장치를 자주 피하지 않아도 됨으로 네트워크에 트래픽이 적어질 것이고 장치의 라디오가 더 오랜 시간 동안 꺼져 있을 수 있기 때문에 장치의 배터리 수명이 증가할 것이다. 이러한 종류의 이력 토폴로지 지도는 라우트를 사전에 계산할 때 매우 유용하다.
예:
도 6b는 게이트웨이를 통해 서버에 의해 조정된 당중-홉 네트워크를 도시한다. 각 클라이언트는 도해에 표시되지 않은 서버로의 직접 업링크와 서버서부터의 다운링크 연결을 가지고 있다고 가정한다. 이 예에서 물질적 네트워크는 특정 물질적 영역에서 1부터 7까지 번호가 매겨진 7 개의 클라이언트로 구성된다. 서버에 보고된 토폴로지 정보는 서버가 클라이언트의 실제 위치와 어느 클라이언트들이 어느 클라이언트와 전송을 수신할 수 있는지를 포함하는 네트워크의 지도를 형성할 수 있게 한다.
서버에 의한 바람직한 접근법의 예는 다음과 같다 :
1. 서버가 이 네트워크의 가상 지도를 만든다.
2. 서버는 요청 클라이언트로부터 일정 거리 이내에 있는 모든 게이트웨이를 식별하여 적어도 하나의 게이트웨이가 있을 때까지 게이트웨이 검색 반경을 확장한다.
3. 게이트웨이 검색 반경 내에서 발견된 각 게이트웨이마다, 서버는 시간 변화 탐욕 알고리즘, 시변 최대 흐름, 시변 최소 배터리 소비, 시변 빠른 경로, 시변 최소 전송 비용, 시변 최소 스펙트럼 사용, 시변 최소 홉, 시변 최대 신뢰도 등 여러 가지의 라우팅 알고리즘을 사용하여 게이트웨이로부터 목적 클라이언트에 라우트들을 결정한다.
4. 서버는 채널 및 타이밍 명령을 각 전송에 할당한다.
5. 이 채널 지정 및 타이밍 지시를 사용하여 서버는 다운로드가 완료될 속도를 예측한다.
6. 하나의 라우트가 특정 속도(일반적으로 직접 다운링크를 사용하여 달성할 수 있는 속도를 초과하는)를 도달하는 라우트를 추정한 후, 서버는 해당 라우트를 선택하고 선택한 라우트의 정보를 보낸다.
7. 해당 게이트웨이를 사용하는 라우트를 찾을 수 없거나 해당 게이트웨이를 사용하는 라우트 중 특정 속도보다 더 빠르거고/빠르거나 전송 비용, 신뢰성 또는 사전에 준비된 측정 항목들을 초과시키는 라우트가 없은 경우, 검색 범위를 확장한다. 서버가 특정 시간 내에 직접 다운링크보다 빠른 라우트를 찾지 못하면 서버는 직접 다운링크를 통해 데이터를 전송하도록 선택할 수 있다. 일부 예에서는, 장치들은 선택된 라우트가 가져야만 하는 조건들을 중앙 서버에 지시할 수 있다. 예를 들어, 장치는 전송이 무료인 경우에만 데이터를 수신하기를 원할 수 있고 그렇지 않으면 그러한 조건이 충족될 때까지 무기한 대기할 수 있다. 이러한 경우에, 중앙 서버는 일정 시간의 검색 후에 요청 처리를 중단할 수 있다. 이러한 경우, 장치는 중앙 서버에 요청을 계속할 수 있지만 중앙 서버는 초기 요청 시간에서 일정 시간이 지난 후에만 이러한 요청을 다시 고려할 수 있다. 통상의 기술자는 클라이언트가 업로드 또는 데이터 요청을 할 때와 같은 절대적 조건을 적용할 수 있음을 알 것이다. 예를 들어 셀룰러 및 WiFi 인터페이스를 모두 갖춘 클라이언트는 셀룰러 연결이 비싼 경우 셀룰러 연결을 통해 중앙 서버와 직접 연결하지 않기로 선택할 수 있다. 클라이언트는 의사 게이트웨이에 분산된 연결을 설정할 때까지 기다릴 수 있으며, 이러한 연결은 덜 비쌀 수 있다. 그러나, 클라이언트는 특정 기간(예를 들어, 24 시간) 후에 서버 또는 인터넷에 접속하지 못한 경우 셀룰러 인터페이스를 사용하여 직접 연결을 생성하거나 보다 긴급한 요청을 전송해야 하는 경우를 선택할 수 있다.
예를 들어 도 6b의 네트워크에 관해, 서버가 계산할 수 있는 잠재적 라우트의 한 목록이 표 1 (도 6c)의 목록일 수도 있다.
예시 끝.
이런 일반화된 라우팅 방법을 사용하여, 서버는 다수의 측정 항목, 라우팅 알고리즘 및 한계치를 사용하여 각각의 데이터 패킷을 적절하게 라우팅할 수 있다. 또한 경로가 선택되면 서버는 이전에 결정된 라우트에서 사용된 자원들을 고려하여 라우트들을 총 전송 시간을 줄이기 위해 보충 라우트를 만들기 위해 계속 계산할 수 있다.
본 발명에서, 라우트에는 두 가지 유형이 있다: 직접 및 우회적인 라우트. 직접 라우트는 요청된 데이터를 게이트웨이에서 대상 장치로 직접 다운링크를 통해 전송함으로써 완료되는 라우트다. 우회적인 라우트는 요청된 데이터를 다른 장치들과의 연결을 사용하여 목적 장치로 정보를 전달하는 중계 장치로 보내는 게이트웨이로 라우팅하여 완료되는 라우트다.
다중 "게이트웨이" 경로의 가상화
조합한 경로 유형도 네트워크의 가상 지도에서 경로를 생성할 때 가능한 해결책이고, 또한 특별히 주목해야 한다. 조합 경로는 여러 경로의 조합을 사용하여 새 경로를 만든다. 경로는 전송을 더 강하게 만들기 위해 여러 개의 게이트웨이를 동시에 통합할 수 있다. 제2 조합 경로는 전송을 더 강하게 만들기 위하여 하나의 클라이언트에게 데이터를 전달하려는 여러 클라이언트들을 포함할 수 있다. 마지막으로, 설명된 경로 유형의 선형 결합도 조합 경로를 묘사할 수 있다. 여기에는 다중 게이트웨이 경로와 직접 연결이 동시에 포함될 수 있다.
직접 여러 이웃에게 수신, 그리고 목적지로 수신
본 발명의 바람직한 예들에서, 서버는 하나의 클라이언트로 가는 주어진 자원 또는 스트림(예를 들어 파일 또는 스트림)을 분할하고 가능하면 그것을 클라이언트 주위의 모든 이웃에게 하나 이상의 직접 다운링크를 통해 보내는 것이 최상이라고 결정할 수 있다(도 6d에 도시된 바와 같이). 이는 개별 장치가 중앙 서버와의 연결이 좋지 않거나 존재하지 않거나 특정 다운로드의 대기 시간을 줄이기 위해 선택될 수 있기 때문일 수 있다. 이웃 장치들이 자원 또는 그 일부를 수신한 후에, 각각의 장치는 직접 다운링크를 통해 데이터를 수신하기 위해 사용하는 것과 다른 전송 표준을 사용하여 클라이언트(1)에게 적절한 시간에 데이터를 전송할 수 있다. 서버는 총 전송 시간을 줄이고 전체 네트워크 처리량을 증가시킬 수 있으므로 이 라우팅 체계를 선택할 수 있다.
예를 들어, 요청 클라이언트인 클라이언트(1) 및 그 이웃들이 다른 범위를 갖는 여러 네트워크 인터페이스를 갖고 있다면, 모든 인터페이스가 동시에 채용될 때 데이터가 더 빨리 전송될 수 있다. 예를 들어, 클라이언트(1)에 셀 라디오와 WiFi 라디오가 모두 있는 경우, 요청된 자원의 일부를 직접 다운링크를 통해 클라이언트(1)로 직접 보낼 수 있으며 요청된 자원의 다른 부분을 클라이언트(1)의 이웃들에게 직접 다운링크를 통해 보낼 수 있다. 그런 다음 클라이언트(1)의 이웃들은 클라이언트(1)가 직접 다운링크로 동시에 정보를 수신하는 동안 단거리 Wi-Fi 표준을 통해 클라이언트(1)에 요청된 자원을 보낼 수 있다. 이는 두 네트워크 인터페이스를 모두 사용하고 전체 전송 시간을 줄일 것이다.
이 경우에는 또한 시스템이 시스템에 일시적인 과도 용량이 있다고 결정한 경우 발생할 수 있다. 총 전송 시간을 줄임으로써 대상 클라이언트의 관점에서 다운로드가 더 빠르게 완료될 뿐만 아니라 네트워크도 전체 네트워크 처리량이 증가함에 따라 이익을 얻는다. 전송은 다른 전송에서 갑자기 더 잘 사용될 수 있는 네트워크 자원을 계속 사용하지 않는다.
선형 결합, 시간에 따라 변하는 라우트, 프로토콜/네트워크 인터페이스 핸드오프(예: 셀룰러에서 시작하고 WiFi로 전환)
하나의 게이트웨이가 상당한 전송의 악화가 없으면서 다수의 동시적 전송들을 수행하는 능력을 갖는 경우, 서버는 직접 다운링크 접속을 통해 요청된 자원의 일부를 제1 클라이언트에 전송하는 것이 가장 빠르거나 그렇지 않으면 가장 효율적이라고 결정할 수 있고, 남은 데이터는 피어-투-피어 연결을 사용하여 요청 클라이언트에 동시에 보낼 수도 있다.
상기 방법을 사용하여, 중앙 서버(110)는 모든 클라이언트들에게 특정의 서비스 품질을 실질적으로 보장할 수 있다. 전형적인 예에서, 서버는 먼저 셀룰러 접속과 같은 직접 다운링크를 통해 클라이언트로 데이터 패킷들의 스트림을 전송할 것이다. 이는 서버는 일단 제일 먼저 직접 연결인 최저 대기를 갖는 경로를 택하기 때문에 모든 네트워크 인터페이스가 서버에 등록되어 있으면 어느 기존 시스템에서 약 우세적인 대기 시간을 보장한다. 시간이 지남에 따라 경로는 지속적으로 최적화되고 다운로드가 진행되는 동안 저렴하고 효과적이며 만족스러운 지연 시간을 갖는 다른 경로가 더 많이 사용될 수 있다. 이를 위한 주요 사용 사례는 더 좋은 사용자 경험을 위해 비디오가 대기 시간이 짧은 LTE를 통해 비디오를 다운로드 하기 시작하고 나머지 비디오는 덜 비싸지만 대기 시간이 더 긴 WiFi 게이트웨이를 근원으로 한 멀티-홉 네트워크를 통해 요청 장치에 도달하는 경우가 있다. 본 출원에 사용 되기로는, "핸드오프"라는 용어는 인터페이스(예를 들어, WiFi를 셀룰러로 또는 그 반대로)를 바꾸면서 접속을 유지하는 과정을 지칭한다.
서버는 다중 경로를 통해 양 게이트웨이로부터 데이터를 송신하는 선택권이 있다. 예를 들어, 도 6e에서, 클라이언트(7)는 경로 [1,3,6,7]을 통해 게이트웨이G1로부터 그리고 경로 [8,7]을 통해 게이트웨이 G2로부터 동일한 스트림으로부터 패킷들을 동시에 수신할 수 있다.
서버가 경로에 포함된 클라이언트, 각 링크를 통한 전송 시간, 사용된 채널 및 각 클라이언트가 데이터를 송신 및 수신하는 데 사용해야 하는 인터페이스(들)를 결정할 때, 서버는 직접 다운링크로 경로의 각 클라이언트로의 전송의 송수신에 관한 중요한 라우팅 정보를 보낸다.
이 명령에는 다음을 포함할 수 있고, 그에 제한되지 않는다: 데이터를 수신할 것으로 예상되는 시간 대, 데이터를 수신할 채널, 데이터를 전송해야 하는 채널, 데이터를 전송해야 하는 시간 대, 전송을 위해 사용해야 하는 네트워크 인터페이스 카드, 데이터를 방송하기 위해 사용해야 하는 전력량(적용 가능한 경우), 패킷의 업데이트된 식별자, 전송 경로의 다음 클라이언트를 식별하는 정보, 데이터 전송에 사용된 프로토콜, 데이터를 전송할 하드웨어 또는 안테나들, 암호화 키들, 및 다른 중요한 전송 측정 항목들.
서버에 의해 전송 경로에 있도록 선택된 각각의 클라이언트는 그들이 전송 라우트의 일부인 것을 직접 다운링크를 통해 서버에게 통지받고, 데이터를 네트워크에서 어떻게 전달해야 하는지에 대한 전송 명령이 주어진다. 또는 장치가 메시 연결을 통해 우회적으로 서버로부터 명령을 수신할 수 있다. 이 경우에서 장치들은 전체 전송 라우트를 알 수도 있다.
클라이언트로의 데이터 송신
버퍼 송신
서버는 이러한 요청을 만족시키기 전에 클라이언트가 서버에 대해 여려 요청을 할 수 있다. 이는, 예를 들어, 원격 서버가 일이 밀리고 클라이언트가 추가 정보를 요청하기 전에 요청된 정보를 제공하지 못 할 때 발생할 수 있다. 등록된 각 클라이언트마다 서버가 유지 관리하는 데이터 버퍼가 이 문제를 해결할 수 있다. 정보를 클라이언트로 다시 라우트해야 하는 경우, 서버는 클라이언트의 출력 버퍼에 정보를 추가한다. 또한 서버는 정보가 서버에서 전송되기 전에 서버가 경로를 다시 계산해야 하는 경우 전송할 데이터의 위치와 길이를 저장할 수 있다.
예를 들어, 도 6f에 명시된 바와 같이, 서버는 클라이언트(1)에 갈 출력 큐를 유지할 수 있다. 새 데이터가 클라이언트(1)로 보내져야 하면, 데이터는 데이터 큐에 삽입된다. 새 경로가 해결되면 데이터가 버퍼에서 제거되고 데이터가 클라이언트로 전송되며 큐의 다음 항목이 맨 위 위치로 이동된다.
버퍼링된 데이터가 클라이언트에 전송되기 전에, 서버는 정보를 수정하고, 큐에서는 정보를 제거하거나, 필요함에 따라 정보의 순서를 재정리할 수 있다. 예를 들어, 네트워크에서 오류를 보고하면 발신 정보의 우선 순위를 다시 정렬할 수 있다. 이 경우 누락된 데이터는 네트워크의 큐잉된 다른 트래픽보다 우선시될 것이다. 데이터의 변경은 송신 데이터의 헤더가 새로운 토폴로지 정보로 인해 업데이트되어야 하는 송신 스케줄을 포함할 때 발생할 수 있다.
발신 데이터의 암호화
바람직한 예에서 대칭 및 비대칭 암호화를 사용하여 보안 통신을 돕는다. 네트워크 내의 요청 클라이언트 장치102가 암호화된 통신을 원하거나 필요로 한다면, 요청 클라이언트 장치102는 비대칭 키 한 쌍(예를 들어 Pretty-Good-Privacy(PGP)를 사용하여)을 생성하고 공개 키를 중앙 서버(110)에 업로드할 수 있다. 위에 설명된 초기 등록 절차 중에 서버와 클라이언트 간에 암호 키 혹은 여러 키들이 교환될 수 있다. 대안으로, 키는 보안 수준의 변경이 요청 별로 필요할 때 교환될 수도 있다. 요청 클라이언트 장치102는 또한 서버(110)의 공개 키를 수신할 수 있다. 대칭 키는 서버(110) 또는 클라이언트 요청 장치 102상에서 생성될 수 있고, 그러한 대칭 키는 상대의 공개 키로 암호화하고 암호환되어 정보를 직접 혹은 우회된 연결을 통해 보내는 식으로 전송될 수 있다.
장치들의 물질적 네트워크에서 데이터의 송수신.
서버(110)는 등록된 인터페이스에 도달하기 위해 하나 이상의 게이트웨이(106)와 통신할 수 있다. 시스템(100)에서 게이트웨이(106)의 주요 기능은 다른 네트워크 또는 서브 네트워크(유선 인터넷과 같은)로부터 무선 클라이언트로 또는 그 반대로 콘텐츠를 제공하는 것이다. 게이트웨이(106) 또는 네트워크 브리지의 한 예는 유선 데이터 선(예를 들어, 인터넷 서비스 제공자에 의해 제공되는)을 무선 로컬 영역 네트워크(LAN)에 연결시키는 표준 WiFi 라우터이다. 또는 게이트웨이는 전송 일정에 따라 혹은 무선 클라이언트들의 수신을 위하여 서버에서부터 무선 라디오를 통해 직접 바로 데이터를 방송할 수 있다. 게이트웨이(106)는 서버(110)에 의해 제공된 데이터의 헤더를 사용하여 데이터를 전송하는 방법(채널, 전송률, 인터페이스)을 결정하고 이러한 설정을 사용하여 전송하거나 클라이언트가 수신하기 전에 LTE, HSPA, Zigbee, 이더넷(Ethernet) 혹은 IP프로토콜과 같은 기본 표준화된 전송 방법을 사용할 수 있다. 본 발명의 전형적인 예는 액세스 포인트 모드(AP 모드)로 동작하는 IEEE 802.11 기반 WiFi 라우터를 사용하여 스테이션 모드(STA 모드)로 동작하는 장치들과 통신한다. 표준 무선 라우터의 소프트웨어를 패치하거나 업그레이드하여 서버의 새로운 이더넷, 네트워크 또는 전송 계층 패킷을 해석할 수 있다. 이러한 메시지에는 무선 클라이언트, 주파수 및 시간 조절과 같은 전송 정보 또는 전송 능력이 포함될 수 있다.
게이트웨이는 데이터를 무선 클라이언트에 송신하는 2 가지 방법이 있다. 게이트웨이는 통신을 위해 인터넷 트래픽을 전송하기 위한 표준 통신 방법(예 : WiFi 라우터의 라우팅 테이블)을 사용할 수 있다. 이렇게 하면 무선 클라이언트가 표준 인터넷 연결 및 라우터 설정을 통해 서버에서 정보를 수신할 수 있다. 이 시스템은 서버에서 전송된 데이터가 이더넷 표준과 인터넷 프로토콜 패킷에 포장되어 있고, 무선 클라이언트에게 인터넷 트래픽이 수신된다는 점에서 현재 네트워킹 표준과 역호환된다.
클라이언트의(미가공) 데이터 수신
네트워크의 클라이언트는 그들의 무선 인터페이스상에서 수동적으로 무선 패킷을 청취할 수 있다. 바람직한 예에서, 본 장치는 장치가 데이터의 의도된 수신자인지에 관계없이 모든 송신된 데이터를 수동적으로 청취한다. 이는 장치가 자신의 이웃(즉, 이웃 장치)을 결정할 수 있게 하여, 데이터를 수신하고 의도된 수신자가 아닌 장치들로의 단방향 링크 품질을 결정할 수 있게 장치로부터의 임의의 송신을 가능하게 한다. 이 기능은 대부분의 네트워크 인터페이스 카드(NIC)에서 비표준 기능으로 사용될 수 있지만 펌웨어, 소프트웨어 드라이버 또는 하드웨어를 수정하며 활성화될 수 있다. 몇몇 구현에서는 소프트웨어 정의 라디오의 경우와 같이 이 기능을 즉시 사용할 수 있는 수단을 제공한다.
클라이언트가 그들의 무선 라디오로 데이터를 수신할 때, 클라이언트의 각각의 라디오는 그 특정 주파수 대역 또는 채널에서 트래픽을 수신한다. 장치 하드웨어에서 수신 한 패킷은 일반적으로 장치 드라이버 및 네트워킹 스택(networking stack)으로 전송된다. 본 발명의 바람직한 예는, 패킷이 클라이언트 소프트웨어 모듈로 전달되는 예가 있다.
바람직한 예에서, 각각의 장치에서 송신된 데이터는 서버의 가상화가 연결의 종류에 상관 없는 것과 같이 연결 종류와 프로토콜에 관련이 없다. 즉, 여러 네트워크 인터페이스, 무선 표준, 무선 프로토콜 또는 무선 주파수를 경로의 따른 어느 전송을 위해 사용할 수 있으며 이들은 동일한 데이터 라우팅 작업을 사용하여 처리할 수 있다. 이것은 네트워크 인터페이스 카드가 패킷 탐지와 특정 패킷 유형 또는 프로토콜 전송을 위해 특정화되어 있는 현재 시스템과는 다르다. 본 예에는 클라이언트 소프트웨어는 다중 인터페이스 프레임 수신을 재구성 가능하고 동적으로 만든다. 예를 들어, 본 출원의 한 예로서는, 하드웨어는 물리 계층 프로토콜(WiFi 및 셀룰러 인터페이스를 예로 할 때, 802.11, 3GPP 등)을 읽을 수 있고, 소프트웨어 모듈은 어느 미가공 패킷이 하드웨어로부터 들어오는지에 따라 재구성 가능한 이더넷(계층 2), 네트워크(계층 3) 및 전송(계층 4) 계층 프로토콜을 사용할 수 있다.
동일한 하드웨어도 중앙 서버로부터의 명령에 따라 프로토콜을 바꿀 수 있다.
본 발명의 바람직한 예는 일반적으로 WiFi NICs, 그들의 드라이버 또는 호스트 운영 체제에서 구현되지 않은 미가공 프레임 감시와 전송 기능을 이용한다. 미가공 프레임 감시는 서버에게 보고될 수 있고 특정 영역에서 장치의 예상 다운르도 속도의 밀도를 계산하는 데 사용될 수 있는 특정 영역에서의 ACK 승인 패킷(acknowledgement packet)의 수신 빈도등과 같은 클라이언트 소프트웨어에게 유용한 측정 항목들을 제공할 수 있다.
수신된 패킷의 프로토콜이 접속 기반 프로토콜(WiFi를 통한 TCP와 같은)인 경우, 수신 클라이언트는 데이터 전송을 완료하기 위해 게이트웨이와 양방향으로 통신할 것이다.
데이터가 도착하면, 클라이언트는 데이터 완전성, 패킷이 자신을 위한 것인지, 그리고 패킷의 라우팅 방법을 결정할 확인 절차를 수행한다. 데이터 완전성은 패킷에 포함된 데이터를 확인 합산하고 그 결과를 패킷의 체크섬(check sum)과 비교하는 일반적인 방법을 사용하여 검증할 수 있다. 패킷이 제1 클라이언트를 대상으로 하는 경우 서버에서 추가된 헤더들이 제거되고 패킷은 클라이언트의 네트워크 스택으로 전달된다. 다음 의사(擬似) 코드는 클라이언트가 모든 무선 인터페이스에서 수신 한 새 데이터를 처리하는 방법을 보여 준다. 이 코드는 소프트웨어로 구현되거나 무선 NIC와 같은 내장된(embedded) 하드웨어의 명령으로 구현 될 수 있다.
패킷 처리 의사 코드
Figure pct00001
패킷 조각을 보고, 미완성 패킷 오류
접속 기반 프로토콜, 또는 802.11 데이터 및 관리 프레임 또는 이더넷 프레임과 같은 정의된 패킷 구조를 갖는 프로토콜의 경우, 송신 오류가 서버에 보고될 수 있다. 이러한 오류는, 예를 들어, 물질적 간섭 또는 패킷 충돌에 의해 일어날 수 있다. 물질적 간섭의 경우 서버는 일련의 실패한 전송을 물질적인 간섭으로 인식하고 가능한 경로 중에서 링크를 제거할 수도 있다. 패킷 충돌로 인해 오류가 지속되면 서버는 전송 매개 변수들을 수정하기 위해 간섭하는 클라이언트와의 안정적인 연결을 사용할 수 있다. 여기에는 무선 라디오, 전송 또는 전송률의 변경이 포함될 수 있다. 서버에 보고된 오류는 서버의 가상 네트워크 및 경로 해결책에 오류가 많이 발생하는 영역이나 오류가 많은 네트워크의 장치들이 있는 위치를 알려줄 수 있다.
국부적 토폴로지를 발견하는 클라이언트
네트워크 내의 클라이언트 단방향 전송 정보를 서버(110)에 보고할 때, 서버는 데이터를 전송하는 데 사용될 수 있는 모든 가능한 전송의 가상 지도를 만들 수 있다. 위에 설명된 바와 같이, 두 클라이언트 사이에 그들이 사용하여 통신할 수 있는 다수의 네트워크 인터페이스, 채널 및/또는 전송 방향을 나타내는 하나 초과의 단방향 링크 또는 경로가 존재할 수 있다. 두 클라이언트는 서로에게 가는 각각 하나 이상의 단방향 링크를 가질 수 있지만 항상 그렇지는 않다.
네트워크에서 모든 가능한 접속의 정확한 실시간 지도를 유지하기 위해, 서버는 하나 이상의 클라이언트를 하나 이상의 인터페이스상에서 방송을 청취하도록 지시하면서, 동시에 다른 클라이언트에게 특정 인터페이스(들)를 통해 데이터를 방송하게 할 수 있다. 이 방법은 제한되거나 오래된 토폴로지 정보를 향상 시키거나 새로운 영역의 토폴로지를 발견하는 데 사용될 수도 있다.
많은 경우에, 위치 정보도 토폴로지 정보와 함께 클라이언트들로부터 서버로 전송될 것이다. 이는 서버가 전송이 수신된 위치를 기록할 수 있게 한다. 이 정보를 다른 알려진 클라이언트의 위치와 결합하면 전체 네트워크에 대해 더 많은 정보가 담긴 지도가 만들어진다. 서버는 라우팅 결정을 향상시키는 데 사용할 수 있는 네트워크 지도를 유지 관리할 수 있다. 지도는 이력 및/또는 실시간 데이터를 기반으로 만들어질 수 있다. 지도는 성공 및 실패한 전송 기록, 그 전송들과 관련된 시간 및 타이밍, 통신하는 데 사용된 통신 클라이언트 및 인터페이스의 위치들이 포함될 수 있다. 서버는 이러한 전송 기록을 수집하여 어느 영역에 있는 신뢰할 수 있는 이력 지도가 있는 장치들에게 그들의 위치를 보고하게 함으로써 내트워크상에 실시간 연결들에 대한 정보가 있는 지도를 얻을 수 있다. 지도는 보다 나은 라우팅 결정을 제공할 뿐만 아니라 클라이언트가 토폴로지를 결정하기 위해 방송해야 하는 양을 제한할 수 있으며 클라이언트가 패킷을 수신하기 위해 인터페이스 카드의 전원을 켜 놓아야 하는 시간량을 제한하며, 이에 의해 네트워크의 정체를 줄이고, 클라이언트의 배터리 수명을 보존할 수 있다. 중앙서버가 국부적 이력 지도가 이력 지도 범위 안에 있는 국부 장치들의 사용 가능한 인터페이스에 사용되기 위해 충분히 상세하다고 판단하면, 중앙서버는 토폴로지를 결정하기 위해 클라이언트가 방송하는 빈도를 줄이도록 지시할 수 있다. 클라이언트가 자신의 위치를 중앙 서버에 계속 보고 하는 동안, 중앙 서버는 국부 네트워크의 실시간 토폴로지와 클라이언트들 사이의 연결 강도를 이력 토폴로지 지도와 클라이언트들의 실시간 위치를 결합하여 측정할 수 있다.
클라이언트가 분산형 모드에 있을 때, 중앙 서버는 분산형 클라이언트가 보다 양호한 접속 및 라우팅 결정을 하도록 돕기 위해 클라이언트에게 토폴로지 지도를 전송하도록 선택할 수 있다. 예를 들어, 이력 전송 기록의 토폴로지 지도와, 국부적 장치들의 장소, 사용 가능한 인터페이스 및 암호 키의 목록을 표시한 토폴로지 지도를 오버레이한 토폴로지 지도는 클라이언트들의 분산형 모드의 서비스 품질을 증가시킬 수 있다.
클라이언트는 이웃 클라이언트로부터 패킷이 수신된 신호 강도 및 송신의 신호대 잡음비(SNR-signal to noise ratio), 이들의 데이터 속도, 송신률, 대역폭, 이들의 평균, 또는 기타 물질적 계층의 측정 항목들과 같은 인터페이스에 특정한 측정 항목들을 보고할 수 있다. 인지형 라디오 및 기타 "스마트" 라디오는 사용 가능한 주파수 대역 또는 대역 간의 간섭과 같은 유용한 측정 항목들을 서버에 보고할 수도 있다. 이 정보는 클라이언트 소프트웨어의 국부적 토폴로지 데이터베이스와 중앙 서버의 토폴로지 업데이트에 통합될 수 있다.
클라이언트가 라우트를 수신할 때
전형적인 예에서, 클라이언트들은 직접 다운링크를 통해 중앙 서버로부터 라우트 정보를 주기적으로 수신한다. 그러나 라우팅 정보는 우회적 링크를 통해 클라이언트에게 전송될 수도 있다. 라우트 정보는 식별자, 클라이언트의 등록된 인터페이스들 중에서 하나의 전송 인터페이스, 전송을 수신할 때 사용할 다음 장치에 대한 식별자, 및 데이터를 라우팅하기 위한 전송 및/또는 일정 명령들을 포함할 수 있다. 라우트 명령은 장치가 여러 전송 경로에 동시에 참여할 수 있도록 돕는 동적인 그리고 재구성 가능한 규칙의 역할을 한다.
이 경로 기반 아키텍처는 또한 데이터 전송에 익명성을 제공한다. 각 전송의 원천 및 대상 클라이언트는 특정 전송의 라우트 식별자로만 식별된다.
서버로부터 수신된 경로는 클라이언트 소프트웨어 내부의 국부적 데이터베이스에 저장된다. 경로는 정렬하고 동적으로의 검색이 가능하며 장치가 장치 자체에서 라우팅 결정을 수행하지 않고도 다중 경로 전송에 참가할 수 있도록 한다.
클라이언트가 인터페이스 작업을 수신할 때
주기적으로 중앙 서버는 제어 패킷(control packet)을 특정 인터페이스 상에서 작업을 수행해야 할 등록된 클라이언트에게 발행할 수 있다. 그러한 인터페이스 작업은 WiFi 네트워크와 같은 인터페이스 게이트웨이를 스캔하고, 인터페이스의 라디오의 전원을 켜거나 끄거나 또는 라디오의 채널, 주파수, 대역폭, 청취 주소를 변경하거나, WiFi 직접(direct) 그룹을 생성하거나, WiFi 직접 그룹에 가입하거나, 또는 다른 작업들을 포함할 수 있다. 다른 인터페이스는 장치 별, 인터페이스 별로 다르게 인터페이스 명령에 응답할 수 있다.
인터페이스 명령에 대한 하나의 전형적인 예는, 클라이언트가 손상된 전송을 (아마도, 예를 들어, 충돌 패킷들로의 간섭의 결과로서의 손상) 보고할 때 발생한다. 서버는 전달하는 클라이언트가 성공적인 전송의 확률을 증가시키기 위해 전송 전력을 증가시켜야 되는지를 결정할 수 있다. 또는 서버는 간섭하는 클라이언트에게 전송 전력을 낮추라고 지시할 수 있다. 이 낮은 송신 전력은 장치의 하드웨어가 제한된 대기 시간으로 송신 전력을 낮추는 게 가능하면 새로운 경로로 전달될 수 있고 아니면 명령이 내려지기 전에 직접 다운링크를 통해 비동기적인 인터페이스 작업으로 전달될 수 있다. 동일한 절차는 네트워크의 다른 부분과의 패킷 충돌을 피하기 위해 전송의 채널 및 타이밍을 변경할 때 사용될 수도 있다.
패킷 라우팅
클라이언트 소프트웨어는 클라이언트의 모든 무선 인터페이스를 위해 데이터 라우팅을 관리한다. 전형적인 데이터 라우팅 함수가 아래 주어진다:
Figure pct00002
클라이언트 소프트웨어가 데이터를 수신할 때, 수신된 데이터의 헤더 내의 라우트 식별자는 국부적 라우트 데이터 베이스와 비교된다. 경로가 발견되지 않으면 소프트웨어는 데이터 자체에 서버의 라우팅 명령이 포함되어 있는지 확인하고 헤더 정보를 사용하여 국부적 라우트의 묘사를 만들고 저장한다.
네트워크의 임의의 클라이언트에 의해 수신된 데이터는 3 가지 종류 중 하나에 속한다. 자신을 위한 데이터, 라우팅될 데이터 및 클라이언트가 아무런 조치도 취하지 않아도 되는 데이터. 사용 가능한 경로가 없으면, 장치가 이미 목적지를 도달한 데이터를 다른 장치에서 수신하는 경우와 같이, 패킷은 삭제된다. 클라이언트는 패킷을 대상으로 추가 라우팅 조치를 취하지 않아야 된다.
전달되어야 하는 패킷
주어진 데이터 패킷의 라우트가 중앙 서버에 의해 미리 결정되었기 때문에, 클라이언트가 그에게 의도되지 않은 데이터가 수신되었지만 경로 목록에서 어느 경로가 이용 가능할 때, 패킷은 상기 경로에 포함된 전송 및/또는 스케줄링 세부사항들에 따라 재전송될 것이다. 경로가 재사용될 수 있으므로 서버로서부터 하나의 경로 명령으로 언제든지 수천 개의 데이터 패킷들도 처리할 수 있다. 서버는 네트워크의 각 라우트의 대한 만료 시간을 결정하고, 어떤 해당 조건에서 유효한지 여부를 확인하고, 네트워크의 가상 지도에 해당 정보들을 유지 관리한다. 이 정보는 필요한 경우 제어 정보로 클라이언트에게 전송되기도 한다.
자신을 위한 패킷.
세 번째 라우팅 경우는, 클라이언트가 수신한 패킷이 그 특정 클러이언트에 예정되어 있을 때이다. 수신되는 데이터의 라우트 ID가 클라이언트의 라우트 표에 있는 라우트와 일치하고, 그 라우트의 목적지가 그 클라이언트 자신으로 식별될 때, 그 패킷은 클라이언트로부터 소비된다. 어떤 경우에는 수신된 패킷은 비연결 프로토콜에 해당할 수 있다. 이 경우엔 클라이언트 소프트웨어는 데이터에서 라우팅 및 제어 헤더 정보를 제거하고 데이터를 장치의 네트워크 스택으로 전달한다.
순차적/동기적인 데이터 처리 -데이터 스트림의 조각 맞추기.
이 과정은 네트워킹 스택의 여로 계층에서 발생할 수 있다. 여기서 "데이터"와 "버퍼"는 OSI 모델에서 4계층 이상인 종점들 사이에서 송수신되는 데이터를 나타내고, "패킷"은 OSI 3계층 및 그 이하인 종점들에서 송수신되는 데이터를 나타낸다. 서버는 두 가지 경우의 패킷을 모두 처리한다. 이 부분에서는 저자들은 이 과정은 장치의 네트워크 스택으로 데이터를 보내는 것과 다른 과정이기 때문에 클라이언트 내에서 4계층 혹은 이상에서의 기능을 확장해 설명한다.
일반적으로, 신뢰할 수 있는 프로토콜을 사용하여 데이터를 요청 및 수신한다. (TCP/IP와 같은) 신뢰할 수 있는 프로토콜은 될 수 있는 한 연결 지향적이고, 원격 서버와 요청 장치 간에 교환되는 데이터의 올바른 순서와 완전성을 보장한다.
이러한 접속 - 기반 프로토콜에서, 오류는 종종 일어나고 오류 정정 및 재정렬할 메커니즘이 필요한다. 이러한 오류에는 충돌, 정확하지 않은 송신 및 수신하는 안테나들의 동기화, 간섭 또는 충분하지 않은 송신 전력 또는 수신 증폭들을 포함할 수 있다. 본 발명은 기존의 오류 해결 프로토콜(TCP/IP 네트워킹에서 사용되는 것과 같은)을 사용할 수 있다. 이 과정은 확인 응답 패킷(ACK)을 서버에 보내거나 직접 업링크 연결을 사용하여 원격 서버에 직접 전송하는 과정들을 포함한다. 또한, 이 과정은 수신 장치로부터 메시 네트워크를 통해 서버 또는 다른 원격 서버로 ACK 패킷을 전달하는 것을 포함할 수 있다.
이것의 바람직한 예는 수신하는 클라이언트만이 데이터가 송신된 것을 알고 있는 것인데 네트워크 내의 장치들 사이의 비연결 송신이 그것이다. 연결을 주로 하는 통신이 필요한 경우, 서버는 네트워크 내의 클라이언트들을 대신해 연결 유지 관리할 수 있고, 또는 클라이언트에게 원격서버와의 세션을 관리하도록 허용할 수 있다. 서버가 클라이언트와 원격 서버 간의 연결 세션을 관리할 때는 서버는 비연결 환경에서 오류를 해결하는 새로운 해결책을 제공한다. 오류 또는 완료된 데이터 전송은 서버를 사용하여 동기화하고 오류를 해결할 수 있다.
순차 번호를 이용해 완전성 보장
이러한 거래를 준비하는 하나의 가능한 방법은 서버와 동기화되는 순차 번호를 각 클라이언트를 위해 유지 관리하는 것이다. 이 동기화는 클라이언트가 서버에 처음 연결하거나 서버와 교환될 제어 패킷을 통해 주기적으로 발생할 수 있다. 이 방법을 사용하면 정보가 서버에서 전송될 때 해당 가상 클라이언트의 순차 번호가 전송할 데이터의 양에 따라 서버에 의해 내부적으로 업데이트된다. 그런 다음 해결된 대상 클라이언트로의 경로에 따라 서버 외부로 데이터가 전송된다. 클라이언트가 데이터를 수신하면 패킷 헤더에 포함된 데이터 동기화 오프셋과 패킷 길이를 사용하여 클라이언트가 데이터를 정렬하고 데이터 일부를 잃었는지 확인할 수 있다.
예
이러한 시스템의 예가 도 6g에 명시된다. 이 예에서 클라이언트(1)가 게이트웨이(1)의 전송 범위 내에 있고 클라이언트(2)가 동일하거나 다른 무선 인터페이스상에서 클라이언트(1)의 전송 범위 내에 있지만 게이트웨이(1)의 범위 내에 있지 않다. 클라이언트(1)과 클라이언트(2)가 중앙 서버와 통신할 수 있는 게이트웨이(2)에 도달할 수 있는 제2 무선 인터페이스가 있다고 가정한다.
도 6g에 명시되어있는 구체적인 예는 게이트웨이(1)의 역할을 하는 WiFi 핫스팟과 게이트웨이(2)의 역할을 하는 셀 타워이다. 클라이언트(1) 및 클라이언트(2)는 셀룰러와 WiFi 라디오를 둘 다 포함하는 모바일 장치다. 이 예에서는 서버가 인터넷을 통해 각 게이트웨이와 통신한다고 가정한다(광섬유 케이블 회선 또는 다른 백홀 소스 사용).
이 예에서, 전송 오류는 도면에 A, B, C, D, E 또는 F 중 임의의 링크에서 발생할 수 있다. 그러나 이 예에서 링크 A와 D는 필요한 경우 오류 해결 프로토콜을 구현할 수 있는 유선 양방향 링크라고 가정한다. TCP/IP를 포함하는 표준 인터넷 프로토콜은 그것의 창 크기 확장 선택권을 대기 시간을 최소화하면서 이러한 오류들을 해결할 수 있다.
위에서 설명된 통신 시스템을 사용하여, 제2 클라이언트는 제1 클라이언트를 통해 서버로부터 정보를 수신할 수 있다고 가정한다. 이 전송은 서버에 의해 생성된 경로 ≪A, B, E≫를 사용한다.
예를 들어 서버가 제2 클라이언트(2)를 위한 3개의 패킷을 발행하고 그것을 링크 A(도 6h-6i)를 통해 게이트웨이를 사용하여 전송한다고 가정하자. 제1 클라이언트(1)가 패킷 {1,3}을 수신하지만 패킷 {2}을 수신하지 못하였다고 가정하자. 제1 클라이언트(1)가 패킷 {2} 수신에 실패할 때 클라이언트는 오류를 생성한다. 클라이언트는 서버에 보낼 오류 요청 또는 표시를 구성한다. 최소한, 오류 요청 또는 표시는 오류 유형을 식별해야 한다. 본 출원의 예에서, 오류 요청 또는 표시는 또한 범위의 시작 위치 및 누락된 데이터의 길이를 나타낼 수 있다. 클라이언트는 직접 업링크 연결을 사용하여 경로 ≪C, D≫를 통해 서버에 오류를 알린다. 그런 다음 서버는 이 오류를 해결하는 방법을 결정할 수 있다. 제1 클라이언트에서 오류 알림을 수신하면 서버는 새 경로를 계산하고 이 새 경로를 통해 패킷 {2}를 다시 보낸다. 새로운 경로는 원래 경로 ≪A, B≫일 수도 있고 또는 다른 경로, 예를 들어 경로 ≪D, C≫(도 6j -6k)일 수도 있다.
두 번째 가능한 경우는 제2 클라이언트(2)가 패킷 {1} 또는 {3}(도 6l-6m)을 수신하지 못하면 발생한다. 도 6l의 예에서, 클라이언트(2)는 링크 F를 통해 서버에 패킷 {2-3}을 수신하지 못했다는 사실을 알릴 수 있다. 서버는 원래의 경로 ≪A, B, E≫ 또는 대체 경로 ≪D, F≫일 수 있는 새 경로를 패킷 {2-3}을 클라이언트(2)로 전송하기 위해 계산한다.
예시들 중에서, 제1 클라이언트는 그러한 시스템은 제2 클라이언트(의도된 수신 클라이언트)는 패킷들의 수와 순서에 관한 정보를 요구할지라도 패킷들의 수와 순서에 관한 정보를 가질 필요는 없다. 한마디로, 어느 경우에서는 클라이언트(1)는 패킷 전달 위치 이외의 패킷에 대한 정보를 아무것도 필요로 하지 않으며 클라이언트(2)만이 오류를 보고하고 해결 요청할 수 있다. 몰티 홉 경로에서 시스템이 어느 경로 마디에서 패킷이 실패했는지를 판별할 수 있기 때문에 클라이언트(1)도 오류를 보고하면 네트워크에 이익이 될 것이다.
이 정보는 그들이 예상해야 하는 패킷의 수 및 크기에 관한 정보를 네트워크 상의 장치들이 동기화하기 위해 게이트웨이(2)를 통한 직접 연결을 사용하여, 경로 ≪D, C≫ 및 ≪D, F≫를 통해, 가장 신뢰성 있게 전송될 수 있다.
예시들 중에서, 패킷 자체도 수신된 패킷의 순서 및 수를 확인하는데 사용될 수 있는 동기화 정보를 포함할 수 있다. 주어진 클라이언트 상에서, 예를 들어 도 6n에 명시된 바와 같이, 중앙 서버로부터 수신된 정보의 기록을 유지하는 수신 버퍼가 사용될 수 있다.
제1 클라이언트가 데이터 패킷을 수신할 때, 패킷은 전송되는 데이터의 동기화 오프셋 및 길이를 포함할 수 있다. 제1 클라이언트는 서버로부터 수신된 데이터량의 국부적 목록을 유지하고, 수신된 패킷의 길이만큼 수신 오프셋을 증가시킬 수 있다. 도 6n의 예에서는, 동기화 범위 1은 범위 0을 따른다. 따라서 장치는 새 오프셋까지 모든 데이터를 수신하였다.
제1 클라이언트가 정보를 수신하는 동안에, 데이터 범위 {2} 및 데이터 범위 {4}는 수신되지 않고 제1 클라이언트의 동기화 합계에서 오류를 생성한다. 이러한 오류로 인해 서버에서 전송된 데이터들이 조각화되고 조각 A 및 조각 B가 생긴다. 작은 데이터 패킷 {B, C, D, E} 및 패킷 {G}는 성공적으로 도착하고 즉시 제1 클라이언트의 네트워킹 스택으로 전달된다. 누락된 데이터 범위 {2, 4}는 오류를 생성하고 제1 클라이언트가 그것을 서버에 보고한다.
두 개 초과의 클라이언트로 상기 방법을 일반화하면, 몇몇 추가적인 오류 해결 방법이 구현 가능할 수 있다. 목적 클라이언트로 여러 경로를 사용할 수 있고 주어진 경로에서 오류가 발생하면 누락된 데이터가 제2 경로를 사용하여 다시 전송될 수 있다.
제1 클라이언트가 패킷 {3}을 수신하면, 동기화 오프셋 및 길이는 도 6o에 명시된 바와 같이 제1 클라이언트의 수신 버퍼에 틈을 남긴다. 그런 다음 제1 클라이언트는 누락된 데이터 범위를 현재 오프셋과 누락된 데이터 길이를 사용하여 계산하고 이 정보를 해결하기 위해 서버에 보고할 수 있다.
이 방법은 비동기적이고 비 순차적인 데이터 수신 및 소비를 허용한다. 단일 데이터 스트림은 해당 데이터가 사용 가능해질 때마다 상위 레벨 프로토콜에 의해 요청된 데이터를 제공할 수 있다. 예를 들어 패킷이 순서가 맞지 않거나 오류가 있는 비디오 버퍼링은 사용자에게 수신된 프레임을 덩어리로 전달될 수 있다. 예를 들어 사용자가 비디오 파일을 신속하게 검색하는 경우 이 방법이 다른 전달 방법보다 효율적이며 짧은 대기 시간을 경험할 수 있다.
완료 보고
다양한 클라이언트 및 게이트웨이는 서버로의 데이터 전송의 완료 및 업데이트된 장치들의 측정 항목(RSSI, 배터리 수명 등을 포함 함)들을 개별적으로 보고하도록 선택할 수 있다. 그러나 신뢰성 있는 연결이 제공되면 각 클라이언트 및/또는 게이트웨이는 데이터 전송 오류를 보고할 것이다. 전송 오류는 클라이언트가 예상된 패킷을 서버가 직접 다운링크를 통해 보낸 라우팅 일정에 표시된 일정 시간 내에 받지 못했을 때 오류로 결정된다. 이 과정은 서버로의 다양한 링크를 사용하여 무선 전송이 일어나는 동안 발생할 수 있다.
오류 취급- 패킷 재전송
오류가 네트워크에 의해 보고되고 재전송으로 해결될 필요가 있을 때, 서버는 그 버퍼링된 데이터를 이용하여 오류 해결을 용이하게 할 수 있다. 서버는 데이터 범위 0을 클라이언트에 전송하고, 전송 오프셋을 증가시킨 다음 데이터 범위 0에 대한 오류를 수신한다. 전송 오프셋은 데이터 범위 1에 남게 되지만 서버는 여전히 메모리에 있는 버퍼링된 데이터 범위 0을 사용하여, 데이터를 다시 가져올 필요없이 정보를 다시 보낼 수 있다.
데이터 패킷의 제1 클라이언트에 도착 정보는 동기화 정보 또는 패킷 도착의 확인과 함께 서버에 보고될 수 있다. 이 확인을 받지 못하면 서버는 그 특정 경로에 오류를 기록하고, 서버가 게이트웨이 또는 대상 클라이언트로의 다른 경로를 통해 데이터를 다시 보낼 수 있다.
제1 클라이언트가 게이트웨이(여기서는 WiFi 액세스 포인트)와 결합되고 제2 클라이언트가 WiFi 액세스 포인트와 결합되지 않지만 WiFi 액세스 포인트로부터의 전송 범위 내에 있는 경우를 고려한다.
이 예에서, 제1 클라이언트와 제2 클라이언트는 모두 게이트웨이로부터 패킷 A를 수신한다. 제1 클라이언트는 패킷의 대상을 자신으로 인식하고 패킷의 수신지를 원점을 인식한다. 그런 다음 패킷은 네트워킹 스택으로 전달된다. 제2 클라이언트는 패킷 A를 수신하고 또한 패킷이 제1 클라이언트로 향하는 것을 인식한다. 패킷을 폐기하는 대신 제2 클라이언트는 이제 게이트웨이에 의해 전송된 패킷 A의 전송 특성(소스, 신호대 잡음비, 채널, 전송률 및 프로토콜 정보와 같은)들을 기록한다. 결합 없이는, 제2 클라이언트는 게이트웨이에서 데이터를 수신하는 기능을 인식하게 된다. 품질은 전송의 수신된 신호 강도 또는 간단히 패킷의 수 또는 게이트웨이로부터 수신된 패킷의 수신 빈도에 의해 결정될 수 있다. 위에서 설명한 절차는 WiFi 액세스 포인트가 비콘 프레임을 사용하여 네트워크 이름을 방송하는 방법과 매우 유사하다. 액세스 포인트는 방송 주소 또는 관리 데이터 프레임을 사용하여 잠재 클라이언트에게 네트워크의 가용성 및 해당 네트워크에 연결할 때 상대적인 신호 강도를 알린다. 이 방송 절차는 장치 자체로 확장되어, 장치가 수동적으로 전송을 받으면서 다른 장치로부터 데이터를 수신하는 능력을 알 수 있게 한다.
마지막으로 성공한 클라이언트를 통해 오류 해결
바람직한 예는 데이터를 전달하기 위한 비 연결 방법을 설명하기 때문에, 이 절차는 이전에 데이터를 라우팅 한 피어들 사이의 오류를 직접 해결하기 위해 사용될 수 있다. 예를 들어, 제1 클라이언트 장치가 제2 클라이언트 장치에 정보를 송신할 필요가 있는 경우, 서버(110)는 제1 클라이언트 장치 102가 제2 클라이언트 장치102와 통신할 필요가 있다는 것을 직접 업링크를 통해 통지된다. 서버(110)는 이용 가능한 라디오 링크 및 인터넷의 접속을 고려하고, 네트워크 인터페이스 또는 무선 라디오의 임의의 조합을 통해 제1 클라이언트로부터 제2 클라이언트까지의 경로 또는 일련의 경로를 결정한다.
다른 클라이언트(예, 제3 클라이언트)가 게이트웨이를 통해 서버로부터 정보를 다운로드하고 다운로드된 정보를 메모리에 저장하는 경우를 고려한다. 서버는 나중에 사용하기 위해 콘탠츠를 사전에 다운로드하고 제3 클라이언트에 저장한다.
나중에 다른 클라이언트(예를 들어, 제4 클라이언트)가 서버로부터 데이터를 요청할 때, 서버는 네트워크에서 실시간으로 그 데이터를 전송할 수 있고, 위의 시스템에 설명된 것처럼 제3 클라이언트와 제4 클라이언트 사이의 전송을 이용하여 할 수 있다. 그러나 제3 클라이언트가 이미 인터넷에서 일부 데이터를 수신했으므로 이 데이터의 부분 집합이 제4 클라이언트에 의해 요청된 경우 서버는 제3 클라이언트에서 다운로드 한 데이터의 로컬 캐시를 사용할 수 있다. 서버는 제3 클라이언트에게 제4 클라이언트가 자신의 캐시에 저장된 데이터를 요청하고 있음을 안전하게 통지할 수 있고, 이용 가능한 전송 경로를 사용하여 제4 클라이언트에게 데이터를 방송하도록 제3 클라이언트에 지시할 수 있다.
도 6p의 예를 고려한다. 이 예에서 클라이언트(7)가 서버로부터 데이터를 요청했으며 서버는 경로 ≪1, 3, 6, 7≫을 통해 응답 패킷 A를 보낸다. 클라이언트(1, 3, 6)는 각각 패킷 A를 수신하여 전달했지만 클라이언트(6)가 클라이언트(7)에 정보를 전송할 때 오류가 발생했다. 클라이언트(7)는 오류를 서버에 알리고 서버는 데이터를 다시 보낼 경로를 결정한다.
경로 ≪2, 4, 5, 3, 6, 7≫, ≪1, 3, 6, 7≫ 및 저대역폭 게이트웨이가 모두 후보 경로이지만, 가장 효율적인 경로는 ≪6, 7≫이다. 저대역폭 연결(여기서는 셀룰러 네트워크)을 사용하여, 서버는 도 6q에서와 같이 클라이언트(6)에게 패킷 A를 클라이언트(7)에 재전송하도록 명령한다. 클라이언트(3), 클라이언트(1) 또는 심지어 게이트웨이도 데이터를 재전송하는 데 사용될 수 있다.
이 전략은 도 6r-6s에 명시된 바와 같이 네트워크상의 임의의 분기 경로로 일반화될 수 있다. 도 6r과 같이 클라이언트(2)와 클라이언트(4) 사이에서 전송이 실패하면, 도 6r에서, 클라이언트(1)가, 과거의 성공적인 클라이언트로서, 새로운 하위 경로 ≪1, 3, 4≫를 통해 패킷 A를 전송하기 위해 사용될 수 있다. 클라이언트가 정보를 캐싱할 수 있으면 정보를 성공적으로 수신 한 모든 클라이언트가 목적지로 데이터를 재전송하기 위해 사용될 수 있다. 캐시의 크기는 클라이언트에 따라 다를 수 있으며 오류가 발생하기 쉬운 영역에서는 서버를 수정할 수 있다.
제3 단계- 연결 종료
클라이언트 소프트웨어 및 중앙 서버 소프트웨어는 될 수 있는 한 클라이언트의 등록을 적절하게 끝내는 것이 바람직하다. 클라이언트의 주 직접 연결 업링크가 끊어지면, 예를 들어 셀룰러 서비스의 손실로, 클라이언트 소프트웨어는 동일하거나 다른 인터페이스를 사용하여 중앙 서버에 다시 연결을 시도한다. 장치의 전원이 꺼지거나 배터리가 부족한 경우와 같이 연결을 다시 설정할 수 없는 경우, 타임아웃 또는 연결이 끊어진 클라이언트에 의존하던 다른 장치들에게 보고받은 연결 오류를 통해 서버는 끊어진 연결을 감지한다. 연결이 끊긴 클라이언트는 네트워크의 가상 표시에서 등록이 취소된다. 클라이언트를 중계 장치로 사용하는 모든 경로는 무효화되고 모든 활성 경로는 다시 해결된다. 클라이언트 소프트웨어는 장치가 다음에 켜질 때 중앙 라우팅 서버에 다시 등록된다.
원격 장치/데이터베이스/서버와의 통신
원격 장치 및 데이터베이스와의 통신은 다양한 방법을 통해 달성될 수 있다. 서버에 정보를 제공할 수 있는 한 정보는 저장될 수 있고 토폴로지를 업데이트하여 라우팅을 향상시키는 데 사용할 수 있다. 원격 자원들은 클라이언트에 라우팅할 콘텐츠를 제공하는 데 이것이 주요한 기능이다. 클라이언트가 서버에서 정보를 요청할 때 정보는 종종 서버에 국부적으로 저장되어 있지 않다. 요청된 정보가 서버에 국부적으로 저장되어 있으면, 요청시 직접 전달할 수 있다.
정보가 서버 상에 존재하지 않으면, 원격 서버나 정보를 호스팅하는 클라이언트같은 원격 위치에서 획득하고, 요청하는 클라이언트(들)에게 제공하여야 한다. 경우에 따라 이 정보는 HTTP, FTP, AFP, SMB 또는 유사한 프로토콜과 같은 표준 네트워킹 프로토콜을 통해 원격 서버에서 직접 요청된다. 원격 사이트가 요청된 자원을 제공할 때 자원은 중앙 서버를 통해 요청 클라이언트로 라우팅된다. 서버는 필요할 때 자원을 패킷으로 분할하고 자원을 여러 덩어리로 제공할 수 있고, 자원의 일부 또는 전부를 버퍼하거나, 자원을 클라이언트에게 패킷 스트림으로 보내도록 선택할 수 있다.
자원이 원격 위치로의 접속을 나타낼 때, 요청 클라이언트로부터 수신된 패킷은 원격 장소로 직접 전송될 수 있다. 일반적으로 클라이언트가 스트리밍 데이터와 함께 사용할 원격 서버와의 TCP 연결을 요청할 때 발생한다. 이 경우에서 IP 및/또는 TCP 패킷은 마치 서버가 VPN 인 것처럼 원격 서버로 전달된다. 그 후로 원격 서버의 응답 패킷이 클라이언트로 라우팅된다. 어느 경우에서는 TCP/IP 헤더 수정이 필요할 수 있다. 이 기능은 데이터가 클라이언트 또는 원격 사이트로 라우팅되기 전에 서버에 의해 처리된다.
라우팅
본 발명의 바람직한 예에서, 중앙 설비(104)는 클라이언트들 간의 라우트 및 경로를 결정한다. 중앙 설비가 네트워크 요구와 토폴로지를 조사하고 어느 경로 마디가 경로에 포함되어야 한다고 결정한 후 클라이언트 사이의 통신이 필요하다고 결정할 때 두 클라이언트 사이의 전송이 발생할 수 있다. 따라서 두 클라이언트 사이의 경로 마디 하나는 임의의 특정 라우트에서 사용되거나 사용되지 않을 수 있으며 동일한 대상 클라이언트로 추가 정보를 전송할 때 사용되거나 사용되지 않을 수 있다. 클라이언트 간의 계층 구조를 제거하는 시스템은 노드 사이에 계층 구조를 구현하는 시스템보다 영역 내의 클라이언트들 사이에 더욱 많이 가능한 연결을 허용한다. 따라서 여기서 데이터를 전달할 수 있는 더 많은 경로가 있다. 중앙 시설은 네트워크 토폴로지 및 수요를 포함한 네트워크에 대한 실시간 정보를 완전하거나 거의 완벽하게 보유하고 있으므로, 전송될 각 데이터 패킷마다 요청 클라이언트에게 보낼 수 있는 가장 적합한 라우트 또는 라우트들(예 : 경로, 채널, 타이밍, 방송 범위 등)을 선택할 수 있다.
네트워크 흐름
중앙 설비 또는 서버는 네트워크를 통한 데이터의 흐름을 조절하는 역할을 한다. 서버는 다음 중 하나 이상의 조합을 수행한다: 전체 네트워크 토폴로지 지도의 유지 관리, 네트워크의 모든 클라이언트에 대해 이전의 및 큐잉된 전송 기록 보관, 채널 이용 가능성, 타이밍, 전송 속도, 네트워크 인터페이스, 전송 전력, 안테나, 경로, 방향, 사용 가능한 메모리 및 처리 시간을 포함하되 이에 제한되지 않는 측정 항목들을 사용하여 개별 및 전체 네트워크 데이터 흐름 최적화, 원격 장치 및 서버와 통신하고 요청된 데이터 회수, 네트워크 내의 각 클라이언트에 대한 라우팅 명령 결정, 장치와의 단방향 또는 양방향 통신, 클라이언트에게 라우팅 정보 제공, 전송 오류 해결.
저장된 정보
중앙 서버의 또 다른 능력은 관련 클라이언트 정보의 데이터베이스 관리다. 이 정보는 네트워크상의 클라이언트가 제공하거나, 네트워크의 과거 이력을 활용하거나, 서버에 국부적 또는 원격적으로 제공될 수 있다. 클라이언트는 다른 측정자료들보다도, 모델 번호, 제조 번호, 네트워크 인터페이스 수, 라드오 하드웨어, 네트워크 주소(예 : IP, MAC), 남은 배터리 수명, 클라이언트의 외부 전원 공급 여부 및 사용 가능한 저장소와 같은 정보를 서버에 직접 제공할 수 있다.
클라이언트에 의해 제공되는 정보에 더하여, 서버는 또한 경로를 계산하거나 토폴로지 지도를 구축하는데 사용될 정보를 국부적으로 또는 원격으로 회수할 수 있다. 국부적 정보는 제조 번호 및 안테나 구성에 따라 다른 무선 라디오의 전송 범위에 대한 검색 표를 포함할 수 있다. 대안으로, 데이터베이스는 클라이언트의 다른 모델들의 구성 또는 기타/보조 정보를 포함할 수 있다. 예를 들어 제3자 데이터베이스는 클라이언트의 각 스마트 폰에 대한 사양과 기능(예 : 블루투스, WiFi 등)을 제공할 수 있으므로 클라이언트는 제어 링크를 통해 서버에 이 정보를 제공하지 않아도 된다. 또한 서버는 동일한 모델의 클라이언트들의 네트워크에서의 수행 결과를 관찰하고 추적하여 보다 정확한 라우팅 결정을 내릴 수 있다. 서버에 저장된 정보는 정보가 들어오는 대로 서버가 내릴 라우팅 결정에 사용될 수 있다.
서버에 의해 조정된 업로드
서버는 고대역폭 다운로드 및 비교적 작은 업로드를 돕기로 설계되었지만, 서버는 직접 업링크에 의해 불가능할 때 업로드 기능을 지원할 수 있다. 한 가지 예는 장거리 햄 라디오 무선 전송을 수신할 수 있지만 원천으로 다시 전송할 수 없는 클라이언트다. 서버는 장거리 라디오을 사용하여 채널, 주파수를 조정하고 네트워크의 모든 클라이언트를 동기화할 수 있다. 또한 서버는 제어 링크를 사용하여 데이터를 전송하는 업로드 경로를 조정할 수 있다. 또는 셀룰러 네트워크에 업로드를 수행할 대역폭이 없는 경우, 업로드를 수행하는 경로의 모든 클라이언트에게 직접 다운링크를 통해 업로드 경로가 보고될 수 있다.
예를 들어, 도 6t의 도면을 참조하면, 클라이언트(5)가 데이터 업로드를 요청하고 저 대역폭 연결이 요청을 처리할 수 없는 경우, 중앙 서버는 클라이언트들(1, 3 및 5)에게 그들이 업로드 경로의 일부를 형성한다는 것을 알릴 수 있고, 서버는 경로 ≪5, 3, 1≫을 따라 게이트웨이로 다시 송신하도록 클라이언트(5)에게 지시할 수 있다. 서버는 다운로드와 마찬가지로 업로드를 조정하고 간섭을 방지하기 위해 다른 다운로드와 함께 경로를 스케줄할 수 있다. 위에 설명된 절차를 반대로 사용하여 오류를 해결할 수도 있다. 적용 가능한 기술들 중 이전에 성공한 클라이언트를 사용하여 오류를 해결하거나 전송 오류를 완화하기 위해 전송 특성을 조정하는 기술이 있을 수 있다.
오류 해결(마지막 성공적 클라이언트를 통해)
네트워크의 에러를 해결하기 위한 또 다른 방법은 서버로부터의 추가 명령과 함께 이전 기능을 이용한다. 우회적인 데이터 경로(즉, 직접 연결을 사용하지 않는 데이터 경로)로 인해 서버가 오류를 수신하면 서버는 마지막으로 성공한 클라이언트를 사용하여 오류를 해결할 수 있다. 이 경우에서는 서버가 요청된 데이터를 두 번째로 게이트웨이로 보내지 않는다. 데이터를 성공적으로 수신한 클라이언트는 데이터를 재방송할 지시를 받을 수 있다. 네트워크 토폴로지 및 기타 요소들의 변화에 따라 중앙 서버는 경로내의 장치들이 데이터 재방송을 시도하도록 선택하지 않고 대상 장치로의 마지막 성공 노드에서부터 라우트와 경로를 변경하도록 선택할 수 있다. 유사하게, 새로운 라우트와 경로가 마지막 성공적인 노드로부터 목적지 장치로 결정될 수 없는 경우 중앙 서버는 직접 다운링크를 통해 요청된 데이터를 전송할 것을 결정할 수 있다.
예를 들어, 도 6p의 네트워크를 고려한다. 이 예에서는 클라이언트(7)가 서버로부터 데이터를 요청했으며 서버가 경로 ≪1, 3, 6, 7≫을 통해 응답 패킷 A를 보낸다. 클라이언트(1, 3, 6)들이 각각 패킷 A를 수신하고 전달했지만 클라이언트(6)가 클라이언트(7)에 정보를 전송할 때 오류가 발생한다. 클라이언트(7)는 오류를 서버에 알리고 서버는 데이터를 다시 보낼 경로를 결정한다. 경로 ≪2, 4, 5, 3, 6, 7≫, ≪1, 3, 6, 7≫ 및 저대역폭 게이트웨이가 모두 후보 경로이지만, 가장 효율적인 경로는 단순히 ≪6, 7≫이다. 저 대역폭 접속(여기서는 셀룰러 네트워크)을 사용하여, 서버는, 도 6q에 명시된 바와 같이, 클라이언트(6)에게 패킷 A를 클라이언트(7)로 재전송하도록 명령한다. 당연히 클라이언트(3), 제1 클라이언트 또는 게이트웨이도 데이터를 재전송하는 데 사용될 수 있다.
콘텐츠 전달 네트워크의 촉진
클라이언트가 정보를 캐싱할 수 있는 경우, 정보를 성공적으로 수신한 임의의 클라이언트가 데이터를 목적지로 계속 재전송하는데 사용될 수 있다. 당연히 캐시의 크기는 클라이언트마다 다를 수 있으며 오류가 발생하기 쉬운 영역에서는 서버를 수정할 수 있다.
여기서, 서버는 게이트웨이를 통해 제4 클라이언트로의 경로를 고려하지만, 제3 클라이언트가 제4 클라이언트에 의해 요청된 데이터를 이미 갖고 있기 때문에, 제4 클라이언트에게 요청된 데이터를 제공하기 위해 단지 하나의 송신만이 필요하다.
모든 경우에서 적용 가능하지는 않지만, 동일한 컨텐츠가 동일한 클라이언트 간에 주기적으로 전송되는 경우, 이 절차는 매우 효율적이다. 예를 들어, 여러 무선 클라이언트가 인터넷으로부터 동일한 비디오 자원을 로드하는 경우 게이트웨이는 데이터를 인터넷에서 한 번만 다운로드한다. 게이트웨이가 서비스를 제공하는 노드가 비디오 자원을 요청할 때마다 서버는 이미 비디오를 다운로드 한 다른 클라이언트에게 데이터를 국부적으로 전송하도록 지시할 수 있다.
이 전략은, 중앙 서버의 라우팅 능력과 함께, 등록된 클라이언트가 분산형 메시 네트워크에서 노드로써 또한 작용할 수 있을 때 네트워크상의 임의의 분기 경로로 더 일반화될 수 있다.
중앙-분산형 브릿지
한 클라이언트가 중앙 설비에 요청하기 위한 직접 업링크가 없는 경우에, 직접 업링크가 있는 클라이언트들이 의사 게이트웨이로 표시 또는 등록될 수 있다. 중앙 설비로의 직접 업링크가 없는 클라이언트는 표준 분산 라우팅 방식(즉, 능동적 또는 리 액티브 라우팅) 및 알고리즘 또는 라우팅 프로토콜(예 : OLSR 또는 BATMAN)을 사용하여 중앙 설비로의 직접 업링크가 있는 클라이언트에게 그들의 업로드 요청을 전송할 수 있다. 적극적인 라우팅 방식을 사용하는 경우 분산형 메시 네트워크의 토폴로지 지도를 오직 분산형 메시 네트워크의 구성원으로서 실행되는 클라이언트의 범위 내에 있고 서버와 연결된 의사 게이트웨이로 중앙 서버에 업로드할 수 있다. 직접 업링크가 있고 서버에 연결된 클라이언트가 직접 업로드 링크 없는 클라이언트를 통해 업로드 요청을 받으면 그는 즉시 직접 업링크를 통해 요청을 중앙 설비로 전달할 수 있다. 그런 다음 중앙 설비는 서버에 직접 연결되어 있는 클라이언트 또는 게이트웨이를 통해 응답 데이터를 요청한 클라이언트로 다시 보내도록 선택할 수 있다. 서버는 분산 네트워크에 대한 완전한 네트워크 토폴로지 정보를 갖지 않을 수도 있지만, 데이터가 요청 클라이언트를 향하도록 라우팅될 수는 있다. 직접 업링크가 있는 중개 클라이언트는 패킷이 분산 네트워크의 경로를 통과할 때마다 완료됐다는 정보를 보고하여 패킷 수신의 성공 또는 실패 여부에 대한 정보를 서버에게 제공한다. 이러한 경우의 바람직한 예는 도 6u에 명시되었다.
도 6u에 명시된 장치들2-6과 같이 클라이언트가 서버로 직접 업링크를 생성할 수 없는 경우에, 또는 일련의 클라이언트를 통해 서버(110)를 도달할 때, 서버(100)에 요청을 제공하기 위해 업링크 성능들이 공유될 수 있다.
가장 간단한 경우는, 제2 클라이언트 장치와 연결된(무선 또는 다른 방법을 통해) 클라이언트 장치가 자신의 업링크 연결을 사용하여 제1 클라이언트 장치 대신에 서버로 요청을 전송하는 경우다.
도 6v에 명시된 바와 같이, 클라이언트 장치1은 직접 업링크 접속의 영역 밖에 있지만, 클라이언트 장치2는 서버(110)에 직접 접속할 수 있다. 클라이언트 장치1은 서버에 의해 지시되거나 또는 자동으로 하여 클라이언트(2)를 대신하여 서버로 요청을 전송할 수 있다. 이러한 요청에는 토폴로지 및 위치 정보의 업데이트, 배터리 잔량 정보 그리고 데이터, 오류 보고서와 데이터 업로드 요청이 포함된다. 서버가 네트워크에 클라이언트를 완전히 등록할 수 없고 데이터 전송을 직접 조정할 수는 없지만, 토폴로지 정보와 스펙트럼 사용을 컴파일할 때 클라이언트(1)가 제공한 데이터를 사용할 수 있다. 또한 서버는 클라이언트 장치를 데이터를 수신하도록 등록하지만 데이터가 목적지에 도달하지 않을 수도 있음을 알고 있다. 또한 서버는 라우트 처리, 스펙트럼 사용 또는 다른 네트워크 자원에 대해 더 높거나 낮은 우선 순위를 직접 관리할 수 없는 클라이언트에게 할당할 수 있다. 이 경우는 분산된 메시가 실제로 최상의 옵션인 경우를 포함한다.
라우팅 장치는 중앙 서버로와의 직접 업링크 및/또는 직접 다운링크를 설정할 수 있다. 직접 업링크가 있는 라우팅 장치는 또한 스스로 직접 업링크를 설정할 수 없는 다른 장치를 대신하여 요청을 서버(110)에 전달할 수 있다. 라우팅 장치는 서버로의 접속을 시작하여 네트워크 상에서 올라오고, 서버는 라우팅 장치를 장치 102를 사용하는 네트워크에 메시 네트워크로의 게이트웨이로 등록하기 위해 일련의 결합 통신을 시작한다. 이러한 결합 단계 동안, 보안 키, 인증서, 모델 및 제조 번호, 버전 및 프로토콜 정보는 라우팅 장치의 완전성을 검증하고 장래의 통신을 보장하기 위해 클라이언트에 의해 브리징된 분산형 메시 네트워크를 통해 장치102와 교환된다. 등록 과정는 직접 업링크 연결이 있는 클라이언트에 사용되는 절차와 유사하지만 IBSS(Independent Basic Service Set) 식별자 또는 현재 타이밍 동기화 기능 오프셋과 같은 분산 네트워크에 대한 추가 정보를 포함할 수 있다.
이 프레임워크는 도 6u에 명시된 일련의 연결이 직접 업링크 영역 외부에서 발생하는 경우로 더 확장될 수 있다. 이 경우에서는 표준 메시 네트워크가 클라이언트(1-6) 사이에 배포될 수 있고, 제1 클라이언트가 분산형 메시 네트워크로부터 정보를 서버로 라우팅할 수 있다. 제1 클라이언트는 분산 네트워크를 서버에 등록하거나 네트워크 상의 개별 클라이언트를 등록할 수 있다. 또한 제1 클라이언트는 네트워크에서 정보를 라우팅할 수 있는 자신의 기능을 서버에 알리고 자신이 어느 클라이언트와 통신할 수 있는지 보고할 수도 있다. 본질적으로, 제1 클라이언트는 메시 네트워크로의 게이트웨이의 기능 및 중앙 서버의 클라이언트의 기능을 동시에 갖는다. 장치가 메시 네트워크의 구성원, 게이트웨이 및 무선 게이트웨이의 클라이언트로서 기능할 수 있게 하는 것에는 동일한 채널 상에서의 동작 등 다수의 하드웨어 제한이 있고, 그러한 제한들은 여러 역할들의 완전한 호환이 가능하기 위해 필요하다. 장치는 주어진 네트워크 토폴로지에서 여러 역할을 유지하기 위해 신속하게 채널을 전환하도록 선택할 수 있으며 클라이언트가 여러 네트워크에 참여할 것을 요청할 때 서버를 사용하여 타이밍 및 채널 조정 문제를 해결할 수 있다. 다른 특정 상황들에서, 주어진 무선 인터페이스의 다중 안테나는 이러한 문제를 완화할 수 있고, 주어진 인터페이스가 동시에 여러 채널, 대역폭 또는 데이터 속도로 데이터를 송수신할 수 있게 한다. 그러나 종종 이러한 경우는 드라이버와 호스트 장치 커널에서 두 네트워크 모두에서 안정적인 연결을 보장하기 위해 특별한 주의가 필요하다.
물론, 네트워크 토폴로지가 목적지로의 경로를 제공한다면, 서버는 이전 구간들에서 설명된 비연결 방법을 사용하여 직접 업링크가 없는 클라이언트에게 데이터를 라우팅할 수 있다. 중앙 서버에서 클라이언트로의 직접 업링크와 다운 링크가 없는 경우, 중앙 서버에서 네트워크의 피어-투-피어 부분을 통해 우회적으로 라우팅 명령을 보낼 수 있다. 서버가 메시 네트워크의 한 클라이언트를 통해 가는 분산된 지점을 조정할 때 생기는 지연은 대부분 클라이언트에 적합하지 않은 대기 시간 및 성능 문제를 발생시킬 것으로 예상된다. 그러나 중앙 서버의 분산형 네트워크에 대한 지식은 서버의 네크워크 가상 지도에 도움이 될 것이다. 예를 들어, 특정 영역의 메시 네트워크에 대한 지식은 패킷 충돌로 인해 분산된 영역에서 전송 오류 가능성이 증가했음을 나타낼 수 있다.
예를 들어, 도 6w에 명시된 바와 같이, 클라이언트(1)가 그의 게이트웨이를 통해 WiFi 핫스팟에 연결되어 있고, 클라이언트(2)는 WiFi NIC와 셀룰러 칩이 있고, 제3 클라이언트는 셀룰러 칩이 있다고 하면, 제3 클라이언트는 클라이언트(1과 3)를 통해서 인터넷 패킷을 게이트웨이로부터 수신할 수 있다.
이 네트워킹 방식(도 6w에 명시된 바와 같이)의 이점은 게이트웨이에 연결된 백홀을 이용 가능하게 하고, 제1 클라이언트를 통해 클라이언트(2 및 3)에게도 이용 가능하게 한다. 이 경우에서 클라이언트(2)는 네트워크 브리지로도 작동하여 제1 클라이언트로부터 WiFi 패킷을 수신하고 이를 제3 클라이언트에게 셀룰러 패킷으로 재전송한다.
업링크 접속이 이용 가능할지라도, 일부 클라이언트들은 자신의 접속을 직접 관리하도록 선택할 수 있다. 여기에는 중앙형 전송과 함께 실행되는 분산형 연결 상태들도 있는 WiFi-직접 그룹이 포함된다. 예를 들어, 도 6x에 명시된 예를 고려한다. 이 예에서, 장치들(1-5)은 모두 업링크 사용 가능 범위 내에 있지만 클라이언트(1)와 클라이언트(5)만이 직접 업링크를 통해 통신하고 있다. 장치(4)와 클라이언트(5), 장치(3)과 클라이언트(5), 클라이언트(1)와 장치(2) 간에도 양방향 연결이 있다. 여기서 클라이언트(5)는 장치(3-5)로 구성된 서브 네트워크와 서버가 조정하는 네트워크에 동시에 참여할 수 있다. 마찬가지로 클라이언트(1)와 장치(2) 간의 양방향 연결은 서버의 조정 없이도 가능하다. 서버는 장치(2-4)를 직접 조정할 수 없지만 클라이언트(1)와 클라이언트(5)는 서버에 그들의 양방향 연결, 서브 네트워크 연결의 존재 및 사용 중인 주파수 또는 네트워크의 각 장치의 물질적 위치와 같은 하위 시스템의 사용 가능한 모든 측정 항목들을 보고할 수 있다. 서버는 이 정보를 사용하여 네트워크 상의 클라이언트를 지능적으로 조정하고 클라이언트(1) 및 클라이언트(5)를 통해 정보를 서브 네트워크에 제공할 수 있다.
클라이언트가 자신의 연결을 직접 관리하기로 선택하는 경우에도 토폴로지 정보 및 서비스 라우트를 다른 클라이언트에 보고할 수 있다. 한 가지 예는 자신의 무선 네트워크를 직접 호스팅하고 자체 구성 네트워크에 참여할 여부를 선택할 수 있는 무선 라우터이다. 이러한 클라이언트는 일반적인 클라이언트의 기능의 일부를 구현할 수 있으며 서버는 클라이언트가 게시한 모든 정보와 기능을 네트워크의 가상 지도에 사용할 수 있다. 한 가지 전형적인 예는 AP 모드에서 자신의 WiFi 네트워크를 직접 호스팅하고 자신의 네트워크를 기반으로 중앙 서버에 토폴로지 정보를 보고하고, 자신의 클라이언트 대처 방법에 대한 제안으로 해석하는 서버에서부터의 인터페이스 작동 명령을 받아들이는 스마트 WiFi 라우터이다. 또한 라우터는 자신의 네트워크에 클라이언트를 대신하여 등록함으로써 클라이언트를 노출시키지 않고 자신의 서브 네트워크를 통해 패킷을 라우팅할 수 있다. 이 방법은 특정 영역에 대한 토폴로지 정보를 중앙 서버에 제공하면서 향상된 보안 및 익명성을 제공할 것이다.
서버(들)의 일반 기능
중앙 설비(104)의 각 서버(110)는 이하에서 설명되는 시스템(800)과 같은 컴퓨터 시스템이다.
장치들의 일반 기능
각각의 통신 장치(102)는 이하에서 설명되는 컴퓨터 시스템(800)과 같은 컴퓨터 시스템이다. 통신 장치 102는 될 수 있는 한 하나 이상의 무선 인터페이스(예를 들어, 블루투스 구성 요소, WiFi 구성 요소, 3G/4G 구성 요소 등) 및 하나의 베이스밴드 프로세서(Baseband Processor, 라디오 제어용)를 포함한다.
클라이언트는 그들 주변의 데이터를 수신할 수 있다. 클라이언트 하드웨어에서 직접 또는 무선 NIC를 통해 우회적으로 클라이언트는 인접한 무선 장치로부터 무선 전송을 수신할 수 있다. 클라이언트는, 예를 들어 다중 안테나를 통하여, 여러 채널에서 동시에 데이터 수신하는 것을 도울 수 있다.
데이터 패킷이 클라이언트에게 전송되고 또 다른 클라이언트가 부근에 있는 경우에, 대상이 아닌 클라이언트는 데이터 조각을 가로채고 해석할 수 있다. 이 수신된 전송을 기록하고 이를 서버에 보고함으로써 서버는 해당 클라이언트에 대한 링크 품질을 보다 잘 결정할 수 있다. 클라이언트는 데이터에 포함된 헤더 정보를 사용하여 이 정보를 저장하거나 서버에 보고할 수 있다. 예를 들어 많은 클라이언트가 액세스 포인트에 동일한 채널로 연결되는 무선 네트워크에서 클라이언트는 액세스 포인트에서 다른 클라이언트로 지정된 802.11 데이터 패킷을 가로챌 수 있다. 802.11 데이터 헤더에는 패킷의 목적지와 전송에 참여하는 각 클라이언트의 소스 MAC 주소가 들어 있다. 전송에 관여하지 않는 감시 클라이언트는 데이터 패킷을 수신하고, 송신자 및 수신자 MAC 주소를 식별하고, 감시 클라이언트가 액세스 포인트로부터 전송된 패킷을 수신할 수 있음을 서버에 보고할 수 있다. 이 과정은 감시 클라이언트와 액세스 포인트 간에 어느 통신없이 발생할 수 있다.
추가적인 장치 성능은 주어진 무선 라디오 장치에 대한 송신 전력을 조절하는 것일 수 있다. 클라이언트는 서버의 명령 또는 전송 유형에 따라 전송 전원을 조절할 수 있다.
무선 라디오는 또한 다수의 주파수상에서 데이터를 청취하기 위해 그들의 수신 채널을 제 시간에 순환시킬 수 있다. 인지적 무선 장치는 트래픽량이 크거나 작은 주파수 또는 채널을 식별하는 데 사용될 수도 있다. 특히 전송이 서버에 의해 조정되지 않는 장치로 인해 공용 채널에 전송되는 데이터량이 많은 경우에 특히 위의 사용이 유용하다. 이 데이터는 클라이언트에서 컴파일하고 서버에게 통신될 수 있다.
무선 라디오 또는 안테나, 다중 라디오 또는 안테나는 데이터 통신을 위해 동시에 사용될 수 있다. 이러한 채널 본딩 또는 인터페이스 본딩은 장치의 하드웨어(많은 무선 NIC의 경우와 같이)에 의해 자동으로 처리되거나 제한되게 작동하는 다중 무선 라디오로 취급될 수 있다. 예를 들어 무선 NIC는 다중 안테나를 동시에 사용하여 동일한 데이터 스트림을 다중 수신 안테나를 사용하는 제2 클라이언트로 전송할 수 있다. 수신되면, 스트림들은 결합되어 클라이언트에 제공되는 최종 데이터 스트림을 형성할 수 있다. 또는 클라이언트가 NIC의 다중 안테나를 따로 알릴 수 있으며 클라이언트는 서버에게 안테나들이 동일한 NIC에서 시작되었음을 보고할 수 있다.
바람직한 애플리케이션의 예에서는, 장치들은 계층적 시스템에서 서로 직접 통신할 수 없다. 계층 구조는 중앙 서버의 도입을 통해 제거되므로 특정 영역의 무선 스펙트럼에 대한 효율성이 전반적으로 향상된다.
패킷 수신 + 가상 인터페이스
가장 일반적인 형태의 시스템의 클라이언트 측 구현은 5 가지 작업으로 요약될 수 있다.
1) 인터페이스 송신 패킷/데이터 -이 함수는 인수로서 임의의 양의 데이터를 취하여 무선 안테나로 전달한다.
2) 인터페이스 수신 패킷/데이터 -이 함수는 임의의 양의 데이터를 받고 그것을 클라이언트 소프트웨어로 전달한다.
3) 인터페이스 가져 오기 매개 변수 -이 함수는 무선 인터페이스에 기능 또는 현재 설정(예 : 채널 또는 최대 전송 단위(MTU))을 가상 인터페이스에 문의한다.
4) 인터페이스 설정 매개 변수 -이 함수는 가상 인터페이스(예를 들어, 무선 채널 변경)에서 특정 매개 변수를 설정한다.
5) 인터페이스 라우트 데이터 -이 함수는 패킷의 형태인 수신 데이터를 검사하고 데이터의 최종 목적지를 결정한다. 패킷이 특정 클라이언트에게 온 것이었으면 데이터는 소비된다. 그렇지 않은 경우 패킷은 재전송된다. 이러한 작업들 및 통상의 기술자가 할 수 있는 임의의 다른 작업들은 주어진 클라이언트의 가상 인터페이스를 구성한다. 각 가상 인터페이스는 데이터 전송 또는 수신 방식, 최소와 최대의 전송 단위 MTU(Minimum and Maximum Transmission Unit) 및 채널, 속도, 주파수, 프레임 또는 헤더 집계 또는 기타 유사한 기능과 같은 기본 하드웨어의 기능 등이 다를 수 있다. 서버에 등록되면 가상 인터페이스의 기능이 설정되고 무선 장치를 실행할 수 있다. 클라이언트 장치에는 여러 개의 가상 인터페이스가 동시에 작동할 수 있다. 그러한 동작을 구현하는 것은 어려울 수 있지만 원활한 경험을 위해 필요하다.
불행하게도, 현재는 대부분에 무선 장치들이 이러한 유형의 기능을 완전히 지원하지 못한다. 무선 하드웨어는 모든 경우에 이러한 기능을 사용할 수 있지만 이 기능을 방해하는 네트워킹 스택에 제한이 있다. 결과적으로 클라이언트 소프트웨어의 인터페이스 지원은 아키텍처에 의존하거나 특정 클라이언트 장치에서 이 5 가지 기능을 구현해야 할 수도 있다. 이 기능을 구현하기 위한 세 가지 일반적인 방법은 1) 주문 제작 하드웨어 2) 펌웨어 수정 및 3) 드라이버 수정을 들 수 있다. 통상의 기술자는 상이한 설명 및/또는 다른 구현 방법이 사용될 수 있음을 이해하고 인식할 것이다.
스마트 폰과 같은 모바일 장치는 종종 무선 데이터를 송신 및 수신하기 위해 소형 운영 체제를 실행하는 무선 네트워크 인터페이스 카드를 이용한다. 운영 체제는 표준 프로토콜 패킷(예 : 802.11 프레임 또는 3GPP/LTE 패킷)의 전송 및 수신을 단순화하는 작은 프로그램을 실행할 수 있다. 그러한 모바일 장치의 경우에, 무선 패킷의 수신 및 송신을 담당하는 펌웨어 프로그램은 될 수 있는 한 하나의 장치로부터 다른 장치로의 통신을 지원하도록 수정될 것이다. 이 것은 그러한 네트워크 카드의 비표준 기능이다. 펌웨어는 종종 컴파일되고 독점적이다. 리버스 엔지니어링 도구를 사용하면 이러한 펌웨어를 리버스 엔지니어링하여 맞춤형 수신 및 정보 전송을 달성하는 프로그램을 수정할 수 있다.
미가공 패킷 수신
스마트 폰과 같은 모바일 장치는 무선 데이터를 송신 및 수신하기 위해 소형 운영 체제를 실행하는 무선 네트워크 인터페이스 카드를 이용한다. 운영 체제는 표준 프로토콜 패킷(예 : 802.11 프레임 또는 3GPP/LTE 패킷)의 전송 및 수신을 단순화하는 작은 프로그램을 실행할 수 있다.
예를 들어 도 7에 명시된 바와 같이, 전형적인 예에서, 패킷 A, B, C 및 D가 클라이언트 장치 내부의 무선 네트워크 인터페이스 카드("NIC")에 의해 수신될 때, 무선 NIC는 무선으로 수신된 패킷을 맞출 책임이 있다. 패킷 A, B, C 및 D가 무선 NIC에 의해 수신될 때, 체크섬 또는 다른 품질 측정 항목에 의한 검증을 통과하지 못한 임의의 불완전한 데이터 조각는 불완전하다는 이유로 폐기된다.
다음으로, 전형적인 NIC 또는 클라이언트의 소프트웨어는 각각의 패킷의 목적지 및 원천에 MAC(Medium Access Control 매채접근제어) 계층 필터를 적용하고 이들을 클라이언트와 비교한다. 예시적인 경우에 따르면, 클라이언트는 단지 알려진 원천으로부터 송신되었고 클라이언트의 경로표와 일치하는 패킷만을 처리한다. 이 패킷은 오직 클라이언트가 전달 또는 소비(클라이언트가 대상일 경우)하기 위한 패킷이다. 이는 전송 오류가 클라이언트의 네트워크 스택에 일어나는 것을 방지하는 강력한 시스템이며 여러 클라이언트가 실수로 해당 클라이언트를 위한 정보가 아닌 정보를 처리하지 않고도 동일한 채널을 공유할 수 있게 해준다.
클라이언트의 NIC상에서 수신된 중앙 서버 또는 이웃 장치로부터의 패킷은 목적지, 원천 및 식별자를 제공한다. 이것은 송신자의 소스 IP 주소, 전송 장치의 소스 MAC 주소 또는 지그비(Zigbee) 주소일 수 있다. 이 정보는 클라이언트의 국부적 라우팅 표와 비교되며 패킷은 소비, 재전송 또는 폐기된다. 발신지, 목적지, 식별자 및 길이를 포함한 패킷의 정보와 전송 완성 여부는 나중에 서버에 보고하기 위해 조사되고 국부적 표에 기록될 수 있다.
이 구현들 중 일부의 한 가지 가능한 제한은 기존의 무선 네트워킹 스택과 새로운 변경의 동시성을 보존하는 것이다. 그러한 경우 적절한 라우팅 명령이 없으면 다른 장치의 간섭 또는 배터리의 방전이 일어날 수 있기 때문에, 대부분의 네트워크 API는 액세스 포인트에 연결되고 동시에 무선으로 데이터를 전송하도록 설계되지 않았다. WiFi direct는 펌웨어, 드라이버 및 커널공간 무선 네트워킹 스택을 여러 API에 장치 간의 피어-투-피어 연결을 허용하게 바꾼다. 미가공 프레임을 전송할 수는 없지만 WiFi direct는 피어 장치 간에 송수신 API를 노출한다. 불행하게도, 어느 구현에서는, WiFi direct 표준은 하나 이상의 WiFi 네트워크에 결합된 동시에 피어 장치를 수용하도록 만들어지지 않았다. 결과적으로, 커널은 피어 장치를 선호하도록 종종 액세스 포인트에 대한 연결을 끊고 장치 사용자에게 연결 해제하라는 오류 메시지를 표시한다. 이는 WiFi 네트워크에서 동료들에게 데이터를 내리는 기능을 심각하게 제한한다. WiFi 다수 역할 기능은 기본 WiFi direct 구현을 수정하여 장치의 운영 체제 또는 드라이버에 추가되는 것을 선호한다. 이 기능은 클라이언트 소프트웨어와 상호 작용할 수 있다.
또한, 중앙 서버는 동시성 문제가 있는 곳을 결정할 수 있으며, 가능한 경우 필요할 때 다른 인터페이스 카드를 사용하는 라우트가 효과적으로 동시 작동하도록 할 수 있다. 예를 들어, 서버는 특정 클라이언트를 통해 라우팅할 때 LTE-Direct 및 WiFi-Direct를 모두 사용할 수 있다. 이 클라이언트는 다른 주파수 대역을 사용하여 셀룰러 하드웨어와 WiFi 하드웨어를 동시에 사용할 수 있다. 결과적으로 한 클라이언트의 WiFi 백홀은 여러 인터페이스를 동시에 사용하여 여러 클라이언트가 사용할 수 있게 된다.
미가공 패킷 전송
무선 카드로부터 패킷을 재방송하기 위해, 카드는 될 수 있는 한 미리 설정된 접속이 없이 임의의 장치에게 패킷을 송신할 수 있도록 구성되어야 한다. 무선 카드는 액세스 포인트와 결합없이 무선으로 특수 패킷 프레임을 송신 또는 주입할 수 있다. 또한 이 작업을 위해 호스트 운영 체제 및/또는 호스트 커널과 드라이버를 수정해야 할 수도 있다. 이것은 또한 클라이언트 또는 서버가 사용되는 프로토콜에 따라 송신을 위한 타이밍 오프셋 또는 기능을 결정할 것을 필요로 할 수 있다. 이러한 변경은 장치가 수신 장치에 연결되거나 결합되지 않은 상태에서 한 장치에서 다른 장치로 사용자 지정 전송을 구현하는 데 필요할 수 있다. 서버의 지시에 따라 장치의 속도, 채널 또는 기타 물질적 모드 속성을 변경하려면 추가 수정이 필요할 수 있다.
그러한 이동 장치의 경우, 무선 패킷의 수신을 담당하는 펌웨어 프로그램은 될 수 있는 한 한 장치에서 다른 장치로의 미가공 프레임 전송을 지원하도록 수정될 것이다. 이것은 일부 네트워크 카드의 표준 기능이 아니다. 모바일 장치의 NIC 펌웨어는 종종 사전에 컴파일되고 독점적이다. 리버스 엔지니어링 도구들을 사용하면 이러한 펌웨어를 리버스 엔지니어링하여 프로그램을 수정하여 맞춤형 정보 전송을 실행할 수 있다.
드라이버/펌웨어 수정
일부 상황에서, 이러한 미가공 데이터 감지 및 방송 기능은 무선 카드의 드라이버 및/또는 호스트 운영 체제의 커널의 패치로 인해 활성화되어야 한다. 이 기술은 목적지 또는 원천에 관계없이 모든 패킷을 호스트 운영 체제에 보고하는 무선 카드에서 효과적이다. 때때로 장치에는 네트워크 문제를 진단하기 위한 디버깅 상황에서 사용되는 "모니터 모드"가 포함되며 대부분의 표준 카드에는 이 디버깅 기능이 있다. 어떤 경우에는 호스트 운영 체제의 커널도 무선 카드가 현재 채널에서 모든 전송을 수신하고 있음을 장치에 알리도록 설정을 변경 또는 수정해야 할 수도 있다. 이러한 변경 사항은 또한 호스트 장치가 대상 또는 원천 주소를 기반으로 들어오는 패킷을 필터링하지 않고 토폴로지 또는 메시 사용을 위해 네트워킹 스택이나 특수 소프트웨어로 모든 패킷을 전달하는 것을 필요로 한다.
그러한 이동 장치의 경우, 무선 패킷의 수신을 담당하는 펌웨어 프로그램은 될 수 있는 한 한 장치에서 다른 장치로의 미가공 프레임 수신을 지원하도록 수정될 것이다. 이것은 네트워크 카드의 표준 기능이 아니다. 펌웨어는 종종 사전에 컴파일되고 독점적이다. 리버스 엔지니어링 도구를 사용하면 이러한 펌웨어를 리버스 엔지니어링하여 프로그램을 수정하여 맞춤형 정보 수신을 실행할 수 있다.
NIC의 펌웨어를 다시 프로그래밍하는 하나의 방법은 IDA와 같은 도구를 사용하여 칩셋을 식별하고 펌웨어 바이너리를 분해하는 것이다. 기계 계층(어셈블리) 명령을 사용하여 공통 기능들을 식별하고 펌웨어 내에 있는 공통 함수들을 사용하여 특수 기능들을 구현할 수 있다. 네트워크 카드의 소프트웨어가 사용하는 전송, 수신 및 패킷 생성 기능뿐만 아니라 공통의 메모리 조작 기능을 식별한 후 장치의 표준 런타임 작업과 함께 일련의 특수 기능을 프로그래밍할 수 있다. 이 기능은 호스트 장치와 무선 라디오간에 패킷을 새 방향으로 돌려 장치에서 수신한 모든 전송을 호스트로 전달하고 호스트에서 보낸 특수 패킷은 NIC의 안테나에서 전송한다. 이 해결 방법은 NIC의 표준 작업들을 방해하지 않으며 전체 모니터링 및 주입 지원을 수행한다.
구현 및 성능
Motorola G(제1 세대)의 Android WiFi 및 WiFi-Direct
특정 상황에서, IEEE 802.11 표준(a, b, g, n, ac, ad 등)과 이 표준의 WiFi direct 확장은 클라이언트의 의도된 기능을 구현하기 위한 또 다른 방법을 제공한다. 저자들은 이러한 경우에서 시스템의 작동 방식, 구체적으로 루팅된 Android 장치를 시험하였다. 이 특수 제작 장치는 클라이언트 소프트웨어를 통해 네트워크 트래픽을 라우팅하도록 저수준 WiFi 스택이 수정된 Linux 기반 Android 커널의 수정 버전을 실행한다. WiFi 하위 시스템에 추가 수정에는 WiFi 및 WiFi direct 동시 실행 기능을 가능하게 하여, 이 예에서 설명된 다중-홉 데이터 전송 기회를 보여 준다. 현재 몇몇 핸드셋 만이 소프트웨어를 지원하지만, 이 핸드셋들은 모바일 시장의 상당한 부분을 구성한다. 이 절차는 다른 안드로이드 기반 핸드셋으로 확장될 수 있으며 장치 드라이버에서 전체 프레임 조정을 구현하기 위한 단계를 제공한다.
iPhone의 모니터 모드
IEEE 802.11 표준을 통한 사용자 지정 전송.
C/C ++로 작성된 라우팅 소프트웨어는 특정 장치의 하드웨어를 위해 더욱 최적화될 수 있다. 이를 입증하기 위해 저자들의 코드는 장치 간 통신, 라우팅 서버와의 통신, 가상 인터페이스 생성과 라우팅 논리의 통합에 필요한 새로운 패킷 구조를 일반적인 소프트웨어 라이브러리에 공식화하였다.
드라이버는 하드웨어의 전송 동작을 변경하기 위해 고유의 "매개 변수 취득"및 "매개 변수 설정" 기능을IOCtl(입력/출력 제어)의 형태로 구현했다. 특수 함수들은 사용자 공간 프로그램에서 불러올 수 있는 미가공 송신 및 수신 기능을 포함하도록 이 기능을 수정하였다. 이 수정은 100 줄 미만의 어셈블리 코드로 가능하였다.
펌웨어 수정의 결과로서, 펌웨어는 모든 수신된 데이터 프레임을 요청시 사용자 공간 클라이언트 프로그램에 보고하였다. 여기에는 네트워크에 참가할 때 사용되는 관리 및 제어 프레임, 전송 정보 요청, 동기화 수행에 사용되는 패킷을 포함한 장치를 위해 의도되지 않은 패킷도 포함되었다. 또한, 사용자 공간 프로그램은 미가공 프레임을 무선으로 주입할 수 있다. 사용자 공간과 구현 1에서의 라우팅 논리를 실행하는 UI를 결합하여 핵심 기능 5 개가 모두 달성되었다.
펌웨어 수정으로, 핸드셋은 무선 네트워크를 스캐닝하고 무선 네트워크에 합류하는 무선 기능을 보존하지만, 맞춤형 정보를 송수신하는 기능이 추가되었다. 이는 2.4GHz 대역의 채널 1, 6 및 11에서 장치 간에 시험 데이터를 전송하여 성공적으로 검증되었다. WiFi가 밀집한 환경에서 장치들이 동시에 네트워크에 연결되어 있는 동안 세 장치가 약 500kbps 속도로 미가공 프레임 형태로 데이터를 전달할 수 있었다. 이 속도는 동일하게 수정한 동일한 핸드셋간에 고정된 길이의 예측 가능한 문자열을 수십 번 전송하여 측정되었다. 마지막으로, 펌웨어 수정과 802.11프래임의 패킷 형식으로 이 장치들은 MAC(Media Access Control) 주소로 인접 장치들을 추적할 수 있었다. 따라서 사용자 공간 프로그램은 가상 인터페이스에게 현재 전송 범위에 있는 이웃에 대해 문의할 수 있다.
이 결과들은 상기의 모든 장치 요구 조건을 만족시키는 완전하게 작동하는 시스템을 구성한다. 추가된 기능은 패킷 주입 기능과 모니터 모드의 동시 작동으로 가장 잘 설명될 수 있다. 모니터 모드의 작동은 NIC로부터 ACK 패킷과 관리 프레임을 수신하는 것으로 데모되었으며, 패킷 삽입은 존재하지 않는 네트워크 SSID(Service Set Identifier)를 방송하는 Beacon 프레임을 만들고 해당 네트워크를 수정되지 않은 장치에 표시하며 데모되었다.
사물 인터넷 장치/라우터
본 예는 IoT(Internet of Things) 장치와 함께/에서 사용하기에 유용하다. 많은 IoT 장치는 연결이 저렴한 경우에만 경제적이다. 이는 많은 장치에서는 IoT 장치에게 셀룰러 또는 위성 연결과 같은 인터넷으로의 직접 업링크 또는 다운링크 연결을 제공할 네트워크 접속 비용을 지불하는 것이 경제적이지 않다는 것을 의미한다. 또한 종종 백홀, 경재적 또는 법적 이유 때문에 IoT 장치는 WiFi 핫스팟과 같이 IoT 장치가 인터넷으로의 저렴한 직접 연결할 수 있는 엑세스 포인트를 배치하기가 적절하지 않은 장소에 배치될 수도 있다. 라우터 및 IoT 장치는 BATMAN, OLSR 등과 같은 분산 라우팅 프로토콜을 사용하여 의사 게이트웨이와의 연결을 설정할 때까지 주변 클라이언트와 연결하도록 프로그래밍할 수 있다. 이 경우에는 IoT 장치는 직접 업링크가 없는 클라이언트의 역할을 한다. 이 방법은 종종 IoT 장치를 경제적으로 만드는 데 필요한 저렴한 연결을 제공한다. 설명된 시스템의 또 다른 구현의 예에는,
서버에 등록하고 주변 장치와의 분산된 것을 연결할 수 있게 돕는IoT 장치의 소프트웨어를 배치하며 IoT 장치들의 그룹이 직접 업링크 연결을 사용할 수 있게 한다.
설명된 소프트웨어를 IoT 장치들에 배치함으로써, 오직 그룹 내의 IoT 장치들 중 하나만 직접 업링크 능력 및 직접 업링크를 사용기 위해 등록이 된 인터페이스가 있으면 된다.
Beaglebones
북유럽 반도체 2.4 GHz 무선 트랜시버(Nordic Semiconductors 2.4 GHz wireless transceiver, nRF24L01) 및 Beagle Bone(Linux- 기반 마이크로 컨트롤러)을 사용한다. nRF24L01은 데이터 프레임 송수신 및 장치의 매개 변수와 설정을 가져오기를 위한 API를 현재 전송 채널로서 노출시킨다. 그러나, 장치의 펌웨어의 한계로 인해 특정 매개 변수는 수정할 수 없다. API는 전송, 프레임 크기, 전송 속도 또는 전송 전력의 승인 정책(ACK)을 거의 제어하지 않는다. 구현했을 때, 1Mb의 수준의 데이터를 전송할 때 장치의 응답 시간은 다소 예측할 수 없다. 또한, 오류를 제어하는 수단으로써 펌웨어 + API는 의도된 수신 기능을 단지 예측만 하고 제한된 주소들 밖에 없는 최상이 아닌 주소 지정 계획을 요구한다. 라우팅을 수행하기 위해 특수 전송을 위한 프로토타입 패킷 형식을 정의하는 C/C ++로 작성된 사용자 공간 라우팅 프로그램이 설치된다. 패킷 형식은 각 패킷의 헤더에 라우팅 정보(초기 장치로부터의 홉의 배열로), 채널 및 타이밍 정보를 통합한다. 각 패킷의 페이로드 길이도 저장된다. 또한 각 패킷에는 장치 간의 데이터 전송을 허용하는 여러 길이의 데이터 페이로드가 포함되어 있다. 시험을 거친 후 시스템은 약 40kbps의 속도로 오류없이 데이터를 전송한다. 이 속도는 이론상 최대인 112.5kbps의 30-50 % 효율을 나타낸다. 제한된 효율성과 최대 처리량은 크게 nRF24L01과 Beaglebone 프로세서 간에 사용되는 전송 프로토콜인 시스템의 배선으로 인해 일어난 것이다.
iOS 다중 피어
다른 프로토타입 클라이언트 시스템은 iOS SDK에서 Apple에 의해 제공되는 iOS MultipeerKit API를 사용하여 구성된다. MultipeerKit의 고수준 기능을 통해 개발자는 시스템이 관리하는 WiFi 및 블루투스 연결을 통해 iOS 장치간에 피어-투-피어 연결을 사용할 수 있다. MultipeerKit은 블루투스와 WiFi의 동시 작업을 허용하며 WiFi 네트워크에 연결된 동시에 피어-투-피어 연결을 허용한다.
본 시스템은 LAN 접속을 통해 기업 계층의 WiFi 네트워크에 연결된 중앙 서버로 시험하였다. 하나의 아이폰 6은 고대역폭 WiFi 네트워크에 연결되어 있고 다른 두 대의 전화기는 테스트 영역 내에서 알려진 WiFi 불감대 "WiFi Dead Zones"에서 시험되었다. 저대역폭의 장거리 WiFi 네트워크는 서버에 직접 연결되었다. 이것은 기업 WiFi 네트워크에서 격리된 서버로 되돌아가는 적절한 제어 링크를 제공하였다. 이 설정을 통해 각 장치는 서버에 직접 연결되었지만 기업 네트워크에 가까운 장치만 20Mbps를 초과하는 순수 다운로드 속도를 경험하였다.
2 개의 저대역폭 클라이언트 장치는 기업 네트워크의 범위를 벗어나 동일한 위치로 이동되었지만, 기업 네트워크에 연결된 중계 아이폰 6으로부터 20부터 100 피트(대략 6m-30m)까지의 범위에 위치하였다.
중앙 서버를 사용하여, 메시 경로는 저대역폭 장치 중 하나만을 위해 활성화되고, 다른 장치들은 제어용 변인으로 동작하였다.
이 단일 홉 시스템에서 메시가 활성화된 클라이언트는 제어와 비교하여 특정 야외 위치에서 데이터 속도가 10Mbps 이상 증가하는 것을 보았으며, 제어 장치가 제어 게이트웨이와 더 이상 통신할 수 없는 경우에도 계속 연결되었다. 메시 장치에서 50ft(15.24m) 이상 거리에서 기록된 최고 메시 속도는 15Mbps를 초과하였다. 도시 건물과 거리의 여러 위치에서 시험한 결과, 중앙 집중식 멀티 홉 기술을 사용하여 약 7Mbps의 평균 증가가 나타났다.
드라이버/라우터
바람직한 예는 IEEE 802.11 표준을 통한 반 특수 전송이다. 이 시스템의 세 번째 구현에서는 처음 세 프로토타입에 대한 지식이 더욱 통합된 시스템으로 결합된다. Linux의 몇몇 무선 드라이버, 특히 Atheros 무선 카드는 mac80211로 알려진 SoftMAC API에 크게 의존한다. 특정 무선 카드, 즉 Atheros 기반 하드웨어는 테스트 목적으로 펌웨어 수정과 유사한 기능을 허용하는 HAL(Hardware Abstraction Layer)을 제공한다. mac80211 프레임 워크를 사용하여 커널 공간 소프트웨어가 장치를 떠나는 프레임을 수정하고 생성할 수 있도록 링크 계층 전송을 드라이버에서 패킷이 실행하게 구성할 수 있다. 일부 무선 NIC의 경우 모든 프레임을 커널에 전달하도록 하드웨어를 구성하여 전체 모니터 모드 기능을 지원할 수 있다. 그리고, 커널은 하드웨어가 아닌 소프트웨어에서 필터링 및 라우팅을 제공한다.
컴퓨팅
위에서 명시되고 설명된 애플리케이션, 서비스, 메커니즘 및 동작은 하나 이상의 컴퓨터 또는 컴퓨터 시스템 또는 사용자 장치(예를 들어, 도 1의 장치들(102) 및 서버(들)(110)) 상에서 실행되는 소프트웨어로서, 적어도 부분적으로, 구현된다. 각각의 사용자 장치는 컴퓨터 시스템이거나 컴퓨터 시스템을 포함한다는 점을 이해해야 한다.
그러한 방법(그리고 다른 유형의 데이터)을 구현하는 프로그램은 다양한 방법으로 다양한 매체(예를 들어, 컴퓨터 판독 가능 매체)를 사용하여 저장되고 전송될 수 있다. 직접 프로그램된 전기 회로망 또는 특수 하드웨어는 다양한 예의 작동을 구현할 수 있는 소프트웨어 명령의 일부 또는 전부와 함께 또는 대신하여 사용될 수 있다. 따라서, 소프트웨어만이 아니라 하드웨어와 소프트웨어의 다양한 조합이 사용될 수 있다.
통상의 기술자는 본 출원을 읽으면 본 명세서에 설명된 다양한 절차들은, 예를 들어 적절하게 프로그래밍된 일반용 컴퓨터, 특수 컴퓨터 및 컴퓨팅 장치에 의해, 구현될 수 있음을 이해할 것이다. 하나 이상의 그러한 컴퓨터 또는 컴퓨팅 장치는 컴퓨터 시스템으로 지칭될 수 있다.
도 8(A)는 본 발명의 예가 구현되고 수행될 수 있는 컴퓨터 시스템(800)의 개략도이다.
본 예에 따르면, 컴퓨터 시스템(800)은 버스(802)(즉, 인터커넥트), 하나 이상의 프로세서(804), 주요 메모리 장치(806), 판독 전용 메모리(808), 선택적 이동식 저장 매체(810), 대용량 저장 매체(812), 하나 이상의 통신 포트(814), 위치 장치(들)(816) 및 하나 이상의 센서(818)를 포함할 수 있다. 통신 포트(들)(814)는 하나 이상의 네트워크(예를 들어 컴퓨터 네크워크, 셀룰러 네트워크 등)과 연결되어 있을 수 있고, 네트워크를 통해 컴퓨터 시스템(800)은 데이터를 송수신할 수 있다. 위치 장치(들)(815)는 장치의 위치를 결정하는 데 사용될 수 있는 GPS 장치 등을 포함한다.
본 출원에서 사용되는 "프로세서"는 아키텍처에 관계없이 하나 이상의 마이크로 프로세서, 중앙 처리 장치(CPU), 컴퓨팅 장치, 마이크로 컨트롤러, 디지털 신호 프로세서 또는 이와 유사한 장치 또는 이들의 조합을 의미한다. 프로세서의 작업을 수행하는 장치는 예를 들어 프로세서 및 작업을 수행하기에 적합한 입력 장치와 출력 장치와 같은 장치를 포함할 수 있다.
프로세서(들)(804)는 예를 들어, Intel® Itanium® 또는Itanium 2® 프로세서(들), AMD® Opteron® 또는 Athlon MP® 프로세서(들) 또는 Motorola® 라인의 프로세서들 등이 있다. 통신 포트(들)(814)는 모뎀 기반 전화 접속 연결과 함께 사용될 RS-232 포트, 10/100 이더넷 포트, 구리 또는 광섬유를 사용하는 기가비트 포트, 또는 USB 포트 등 중 임의의 것일 수 있다. 통신 포트(들)(814)는 LAN(Local Area Network), WAN(Wide Area Network), CDN(Content Delivery Network) 또는 컴퓨터 시스템(800)이 접속하는 임의의 네트워크와 같은 네트워크에 따라 선택될 수 있다. 컴퓨터 시스템(800)은 입/출력(I/O) 포트(820)를 통해 주변 장치(예를 들어, 표시 화면(822), 입력 장치(들)(824))와 통신할 수 있다. 주변 장치들 일부 또는 모두는 컴퓨터 시스템(800)에 통합될 수 있고, 입력 장치(들)(818)는 표시 화면(822)(예를 들어, 터치 스크린의 경우에)에 통합될 수 있다.
위치 장치(들)(816)는 GPS 칩셋을 포함할 수 있다. 하나 이상의 센서(818)는 가속도계 및 장치에 관한 정보를 결정하는 다른 센서를 포함할 수 있다.
주 메모리(806)는 랜덤 액세스 메모리(RAM) 또는 당업계에 일반적으로 알려진 임의의 다른 동적 저장 장치(들)일 수 있다. 판독 전용 메모리(808)는 프로세서(들)(804)에 대한 명령과 같은 정적 정보를 저장하기 위한 프로그램 가능한 판독 전용 메모리(PROM) 칩과 같은 임의의 정적 저장 장치(들)일 수 있다. 대용량 저장 장치(812)는 정보 및 명령을 저장하는 데 사용될 수 있다. 예를 들어 SCSI(Small Computer Serial Interface) Adaptec® 제품들과 같은 하드 디스크, 광 디스크, Adaptec® RAID 드라이브 제품들과 같은 RAID(Redundant Array of Independent Disks)와 같은 디스크 어레이, 또는 임의의 다른 대용량 저장 장치가 사용될 수 있다.
버스(802)는 프로세서(들)(804)를 다른 메모리, 저장 및 통신 블록들과 통신 가능하게 결합시킨다. 버스(802)는 사용되는 저장 장치에 따라 PCI/PCI-X, SCSI, USB(Universal Serial Bus) 기반 시스템 버스(또는 기타)와 같은 것들 일 수 있다. 이동식 저장 매체(810)는 임의의 종류의 외장형 하드 드라이브, CD-ROM(Compact Disc - Read Only Memory), CD-RW(Compact Disc - Re-Writable), DVD-ROM(Digital Versatile Disk - Read Only Memory) 등일 수 있다.
본 출원의 예는 하나 이상의 컴퓨터 프로그램일 수 있고, 그 컴퓨터 프로그램은 컴퓨터(또는 다른 전자 장치)가 작업을 수행하도록 프로그램하는 데 사용될 수 있는 명령들을 저장한 기계 판독 가능 매체를 포함할 수 있다. 본 출원에서 사용된 용어 "기계 판독 가능 매체"는 컴퓨터, 프로세서 또는 비슷한 장치에 의해 판독될 수 있는 데이터(예를 들어, 명령, 데이터 구조)를 제공하는 데 참여하는 임의의 매체, 매체들 또는 상이한 매체들의 조합을 지칭한다. 이러한 매체는 비휘발성 매체, 휘발성 매체 및 전송 매체를 포함하고 이에 한정되지 않는 여러 형태를 취할 수 있다. 비휘발성 매체는, 예를 들어 광학 또는 자기 디스크 및 기타 영구적 메모리를 포함한다. 휘발성 매체는 일반적으로 컴퓨터의 주 메모리를 구성하는 동적 랜덤 엑세스 메모리(RAM)를 포함한다. 전송 매체는 동축 케이블, 구리선 및 광섬유를 포함하며 프로세서에 연결된 시스템 버스를 구성하는 와이어를 포함한다. 전송 매체는 음향파, 광파 또는 무선 주파수(RF)와 적외선(IR) 데이터 통신 중에 생성되는 것과 같은 전자파 방사를 포함하거나 전달할 수 있다.
기계 판독 가능 매체는 플로피 디스켓, 광 디스크, CD ROM, 자기광 디스크, ROM, RAM, 소거 가능 프로그램 가능 판독 전용 메모리(EPROM), 전기적 소거 가능 프로그램 가능 판독 전용 메모리(EEPROM), 자기 또는 광학 카드, 플래시 메모리, 또는 전자 명령을 저장하기에 적합한 다른 유형의 매체/기계 판독 가능 매체일 수 있다. 또한, 본 출원의 예는 또한 컴퓨터 프로그램으로서 다운로드될 수 있으며, 이 프로그램은 반송파 또는 다른 전파 매체와 같은 데이터 신호들로 통신 링크(예를 들어, 모뎀 또는 네트워크 연결)를 통해 원격 컴퓨터에서 요청하는 컴퓨터로 전송될 수 있다.
다양한 형태의 컴퓨터 판독 가능 매체는 데이터(예를 들어, 연속적 명령들)를 프로세서로 운반하는 데 참여할 수 있다. 예를 들어, 데이터는: (i) RAM에서 프로세서로 전달될 수 있다; (ii) 무선 전송 매체를 통해 운반될 수 있다; (iii) 다양한 형식, 표준 또는 프로토콜에 따라 포맷 또는 전송될 수 있다; (iv) 당업체에 알려진 임의의 다양한 방법으로 암호화될 수 있다.
컴퓨터 판독 가능 매체는 이러한 방법들을 사용기에 적합한 프로그램 요소들을 (임의의 적절한 포맷으로) 저장할 수 있다.
도시된 바와 같이, 주요 메모리(806)는 본 출원에서 논의된 기능을 지원하는 애플리케이션(822)에 의해 인코딩된다(애플리케이션(822)은 하나 이상의 메카니즘의 기능의 일부 또는 전부를 제공하는 애플리케이션일 수 있다). 애플리케이션(들)(822)(및/또는 여기에 설명된 다른 자원들)은 데이터 및 논리 명령들(예를 들어, 메모리 또는 디스크와 같은 다른 컴퓨터 판독 가능 매체에 저장된 코드)과 같은 소프트웨어 코드로써 구현될 수 있고, 다음의 코드는 여기에 설명된 여러 예에 따른 프로세싱 기능성을 제공할 것이다.
예를 들어, 도 2a에 명시된 바와 같이, 애플리케이션(들)(822)은 서버 애플리케이션을 포함할 수 있다. 장치의 경우에, 도 3에 명시된 바와 같이, 애플리케이션(들)(822)은 애플리케이션들(136)을 포함할 수 있다.
하나의 예의 동작에서, 프로세서(들)(804)는 애플리케이션(822)의 논리 명령을 시작, 실행, 실행, 해석 또는 수행하기 위해, 예를 들어 버스(802)의 사용을 통해, 주요 메모리(806)에 접속한다. 애플리케이션(들)(822)의 실행은 애플리케이션과 관련된 메커니즘(들) 또는 서비스(들)의 프로세싱 기능을 생성한다. 즉, 프로세스(들)(824)는 컴퓨터 시스템(800) 내의 프로세서(들)(804)에서 수행되는 애플리케이션(들)(822)의 하나 이상의 부분을 나타낸다.
예를 들어, 프로세스(들)(824)는 장치 애플리케이션(들)(822) 중 하나 이상에 대응하는 장치 프로세스(들)를 포함할 수 있다.
본 출원에서 논의된 동작들을 수행하는 프로세스(들)(824)에 덧붙여, 다른 구현들은 애플리케이션(822)(예를 들어 아직 실행되지 않은 논리 명령 또는 데이터)를 포함한다. 애플리케이션(822)는 디스크 또는 광학 매체와 같은 컴퓨터 판독 가능 매체(예: 저장소)에 저장될 수 있다. 다른 예에 따르면, 애플리케이션(822)는 또한 펌웨어, 판독 전용 메모리(ROM) 또는, 이 예에서와 같이, 주요 메모리(806) 내에서 실행 가능한 코드(예를 들어, 랜덤 액세스 메모리 또는 RAM)일 수 있다. 예를 들어, 애플리케이션(822)는 또한 이동식 저장 매체(810), 판독 전용 메모리(808) 및/또는 대용량 기억 장치(812)에 저장될 수 있다.
통상의 기술자는 컴퓨터 시스템(800)이 하드웨어 자원의 할당 및 사용을 제어하는 운영 체제와 같은 다른 프로세스들 및/또는 소프트웨어 및 하드웨어 구성 요소를 포함할 수 있음을 이해할 것이다.
여기에서 논의된 바와 같이, 본 발명의 예는 다양한 단계 또는 동작을 포함한다. 이러한 다양한 단계들은 하드웨어 구성 요소에 의해 수행될 수 있거나 컴퓨터 실행가능 명령을 사용하여 구체화될 수 있고, 이것에 의하여 일반 또는 특수 목적 프로세서가 동작을 수행할 명령으로 다시 프로그램될 수 있다. 대안으로, 이 단계들은 하드웨어, 소프트웨어 및/또는 펌웨어의 조합에 의해 수행될 수 있다. "모듈"이라는 용어는 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합을 포함할 수 있는, 전부 포함 기능 구성품을 의미힌다.
통상의 기술자는, 이 설명을 읽을 때, 장치의 예가 기재된 프로세스의 일부(그러나 필연적으로 전부는 아님)를 수행할 수 있는 가능한 컴퓨터/컴퓨팅 장치를 포함할 수 있음을 쉽게 이해할 것이다.
프로그램 또는 데이터 구조를 저장하는 컴퓨터 판독 가능 매체의 예는 실행될 때 프로세서가 설명된 프로세스의 일부(그러나 필연적으로 전부는 아님)를 수행하는 프로그램을 저장하는 컴퓨터 판독 가능 매체를 포함한다.
프로세스가 본 명세서에 기재되는 경우, 통상의 기술자는 이러한 프로세스가 사용자 개입없이 동작할 수 있음을 알 것이다. 또 다른 예에서, 프로세스는 어느 정도의 인간의 개입을 포함할 수 있다(예를 들어, 한 단계가 인간의 보조에 의해 또는 인간의 도움으로 수행되는 경우).
실시간
통상의 기술자는 이 설명을 읽을 때, 용어 "실시간"은 거의 실시간 또는 충분히 실시간을 의미한다는 것을 이해할 것이다. 네트워크 기반 통신에는 네트워에 내재하는 지연(예를 들어, 네트워크 트래픽 및 거리에 의한)이 존재하며, 이러한 지연은 다양한 구성 요소에 도달하는 데이터의 지연을 일으킬 수 있다. 시스템에 내재하는 지연은 데이터의 실시간 특성을 변경하지 않는다. 경우에 따라 "실시간 데이터"라는 용어는 의도된 목적에 데이터를 유용하게 쓸 수 있도록 충분한 시간 내에 얻은 데이터를 의미할 수도 있다.
여기서 "실시간"이라는 용어가 사용될 수 있지만, 시스템은 이 용어가 실제로 얼마나 많은 시간이 소요되는지 구애받지 않는다는 것을 이해해야 한다. 어떤 경우에는, 실시간 계산은 온라인 계산, 즉 데이터가 도착함에 따라 응답을 생성하고, 연속적으로 들어오는 데이터를 일반적으로 따라 잡는 계산을 나타낼 수 있다. 용어 "온라인" 계산은 "오프라인" 또는 "배치" 계산과 비교될 수 있다.
본 출원에서 사용된 바와 같이, "부분"이라는 용어는 일부 또는 전부를 의미한다. 예를 들어, "X의 일부"에는 일부 "X"또는 모든 "X"가 포함될 수 있다. 대화의 맥락에서 "부분"이라는 용어는 대화의 일부 또는 전부를 의미한다.
청구 범위 부분을 포함하여 본원에서 사용되는 "적어도 몇은"이라는 문구는 "하나 이상"을 의미하며, 하나의 경우도 포함된다. 따라서, 예를 들어, "적어도 몇 ABC"라는 문구는 "하나 이상의 ABC"를 의미하며, 하나의 ABC의 경우도 포함된다.
청구 범위 부분을 포함하여 본원에서 사용되는 "―에 기반된"이라는 문구는 "―의 일부에 기반된" 또는 "적어도 일부는 -에 기반된"을 의미하며 제한적이지 않다. 따라서, 예를 들어, "요소 X에 기반된"이라는 문구는 "부분적으로 요소 X에 기반된" 또는 "요소 X에 적어도 부분적으로 기반된"을 의미한다. "단지"라는 단어가 구체적으로 언급되지 않는 한, 구절 "X에 기반된"은 "단지 X에 기반된"을 의미하지 않는다.
청구 범위에서를 포함하여, 본원에서 사용되는 "―를 사용하다"는 "적어도 ―를 사용함"을 의미하며 배타적이지 않다. 따라서, 예를 들어, "X를 사용하는"은 "적어도 X를 사용하는"을 의미한다. "단지"라는 단어가 구체적으로 언급되지 않는 한, 구절 "X를 사용하는"은 "단지 X를 사용함"을 의미하지 않는다.
일반적으로, 청구 범위 부분을 포함하여, 본 출원에서 사용되는 "유일한"이라는 단어가 구절에서 사용되지 않는 한, 구절은 그러한 의미를 뜻하지 않는다.
청구 범위 부분을 포함하여, 본 명세서에서 사용되는 "구별되는"이라는 문구는 "적어도 부분적으로 구별된다"를 의미한다. 특별히 언급되지 않는 한, 구별되는 것은 완전히 별개의 것을 의미하지 않는다. 따라서, 예를 들어, "X는 Y와 구별된다"라는 구는 "X는 적어도 부분적으로 Y와 구별된다"를 의미하며 "X는 Y와 완전히 구별된다"는 의미는 아니다. 따라서 여기에 사용된 바로는, 청구 범위 부분을 포함하여, "X는 Y와 구별된다"는 문구는 X가 적어도 어떤 식으로는 Y와 다르다는 것을 의미한다.
청구 범위 부분을 포함하여, 본 출원에서 사용된 바로는, 목록(또는 리스트)은 오직 하나의 항목(또는 아이템)도 포함할 수 있으며, 달리 언급되지 않는 한, 다수 항목의 목록은 임의의 특정 방식으로 정렬될 필요는 없다. 목록에는 중복된 항목도 포함될 수 있다. 예를 들어, 본 출원에 사용되는 바로는 "XYZ들의 목록"이라는 문구는 하나 이상의 "XYZ들"을 포함할 수 있다.
설명 및 청구 범위 부분에서 "제1", "제2", "제3" 등의 단어는 구별 또는 식별하기 위해 사용되며, 일련의 또는 수치적 제한을 나타내지 않는다는 것을 알아야 한다. 마찬가지로 문자 또는 숫자 표시("(a)", "(b)"또는 "(i)", "(ii)" 등)은 식별 또는 식별을 돕기 위해 사용되며, 일련, 번호 또는 수치적 제한 또는 순서를 표시하지 않는다.
특별히 명시되고 기술되지 않는다면, 임의의 흐름도에서 임의의 라벨된 박스들 중 어느 순서도 암시되지 않는다. 연결이 끊어진 상자가 다이어그램에 표시될 때 해당 상자와 관련된 활동들은 전체적 또는 부분적 병렬 수행을 포함하여 어떤 순서로 수행될 수 있다.
본 발명은 현재 가장 실용적이고 바람직한 예를 사용하여 설명되었지만, 본 발명은 개시된 예들에 한정되지 않으며, 반대로, 첨부된 청구 범위의 사상 및 범위 내에 포함되는 다양한 변경 및 동등한 구성들을 포함한다.

Claims (203)

  1. 하나 이상의 서버를 포함하는 시스템에서 동작 가능한 원격통신 장치로서, 상기 장치는 상기 시스템 내의 클라이언트 장치이고, 상기 장치는,
    상기 클라이언트 장치에 대한 클라이언트 구성 상태를 상기 하나 이상의 서버에 제공하고,
    상기 하나 이상의 서버로부터 제1 서브 네트워크 구성 - 상기 제1 서브 네트워크 구성은 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 적어도 하나의 경로를 포함하고, 상기 제1 서브 네트워크 구성은 상기 클라이언트 구성 상태와 적어도 하나의 다른 클라이언트 장치의 적어도 하나의 다른 클라이언트 구성 상태에 기초함 - 을 획득하기 위해 구성 및 적응되고,
    상기 장치는 상기 하나 이상의 서버를 통해 적어도 하나의 자원을 획득하기 위해 상기 제1 서브 네트워크 구성에 지정된 경로를 사용할 수 있는, 장치.
  2. 제1항에 있어서, 상기 클라이언트 장치에 대한 클라이언트 구성 상태는 상기 클라이언트 장치에 대한 식별 정보를 포함하거나 이 식별 정보에 기초하는, 장치.
  3. 제1항 또는 제2항에 있어서, 상기 클라이언트 장치에 대한 클라이언트 구성 상태는 상기 클라이언트가 적어도 단방향으로 통신할 수 있는 다른 장치들에 대한 정보를 포함하거나 이 정보에 기초하는, 장치.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서,
    상기 하나 이상의 서버로부터 클라이언트 장치로의 상기 적어도 하나의 경로는 하나 이상의 팩터에 기초하여 결정되었고, 상기 하나 이상의 팩터는,
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    를 포함하는, 장치.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 하나의 게이트웨이를 포함하는, 장치.
  6. 제4항에 있어서, 상기 적어도 하나의 게이트웨이가 인터넷에 접속되는, 장치.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서, 상기 장치에 대한 상기 제1 서브 네트워크 구성이 또한 다수의 다른 클라이언트 장치의 클라이언트 구성들에 기초하는, 장치.
  8. 제1항 내지 제7항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 하이브리드 경로를 포함하는, 장치.
  9. 제8항에 있어서, 상기 하이브리드 경로가 별개의 통신 인터페이스들을 사용하는 경로의 마디들을 포함하는, 장치.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 하나 이상의 중간 클라이언트 장치를 포함하는, 장치.
  11. 제10항에 있어서, 상기 적어도 하나의 경로가 적어도 두 개의 게이트웨이를 포함하는, 장치.
  12. 제1항 내지 제11항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크 구성이 이전에 알려진 성공한 네트워크 구성에 기초하는, 장치.
  13. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 클라이언트 장치는 상기 적어도 하나의 자원을, 적어도 부분적으로, 상기 적어도 하나의 경로의 일부를 통해 획득하는, 장치.
  14. 제1항 내지 제13항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로는 상기 클라이언트 장치와 다른 적어도 하나의 제1 장치를 포함하는, 장치.
  15. 제14항에 있어서, 상기 경로 상의 상기 적어도 하나의 제1 장치는 상기 하나 이상의 서버에 의해 상기 적어도 하나의 자원의 적어도 일부의 사본을 갖는 것으로 가정되는, 장치.
  16. 제14항 또는 제15항에 있어서, 상기 적어도 하나의 경로는 적어도 두 개의 게이트웨이를 포함하고, 상기 클라이언트 장치는 상기 적어도 하나의 자원을 상기 적어도 두 개의 게이트웨이를 통해 획득하는, 장치.
  17. 제16항에 있어서, 상기 두 개의 게이트웨이는 셀룰러 게이트웨이들, 비-셀룰러 무선 게이트웨이들, 및 위성 게이트웨이들 중에서 선택되는, 장치.
  18. 제16항 또는 제17항에 있어서, 상기 적어도 두 개의 게이트웨이는 적어도 하나의 다른 게이트웨이와는 별개의 프로토콜을 사용하는 적어도 하나의 게이트웨이를 포함하는, 장치.
  19. 제18항에 있어서, 상기 하이브리드 게이트웨이들은 제1 게이트웨이와 제2 게이트웨이를 포함하고, 상기 제1 게이트웨이와 제2 게이트웨이는 하이브리드인, 장치.
  20. 제19항에 있어서, 상기 제1 게이트웨이는 셀룰러 게이트웨이 장치를 포함하고, 상기 제2 게이트웨이는 비-셀룰러 게이트웨이를 포함하는, 장치.
  21. 제19항 또는 제20항에 있어서, 상기 제2 게이트웨이는 WiFi 게이트웨이를 포함하는, 장치.
  22. 제19항 내지 제21항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 상기 적어도 두 개의 게이트웨이를 통해 상기 하나 이상의 서버에 의해 결정된 비율로 상기 적어도 하나의 자원을 획득하는, 장치.
  23. 제22항에 있어서, 상기 비율이
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상에 기초하는, 장치.
  24. 제16항 내지 제23항 중 어느 한 항에 있어서, 상기 장치는 상기 적어도 하나의 자원을 상기 적어도 두 개의 게이트웨이를 통해 인터리브 방식으로 획득하는, 장치.
  25. 제16항 내지 제24항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 제1 부분 및 제2 부분을 포함하며, 상기 제2 부분은 상기 제1 부분과 다르며, 상기 클라이언트 장치는, 적어도 부분적으로, 상기 제1 게이트웨이를 통해 제1 부분을 획득하고, 상기 클라이언트 장치는, 적어도 부분적으로, 상기 제2 게이트웨이를 통해 상기 제2 부분을 획득하는, 장치.
  26. 제1항 내지 제25항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크 구성에 지정된 상기 적어도 하나의 경로는 다수의 서브 경로를 포함하고, 상기 다수의 서브 경로는 제1 서브 경로, 및 상기 제1 서브 경로와 다른 제2 서브 경로를 포함하고, 상기 클라이언트 장치는 상기 적어도 하나의 자원을 상기 제1 서브 경로와 상기 제2 서브 경로를 통해 획득하는, 장치.
  27. 제26항에 있어서, 상기 제1 서브 경로는 제1 게이트웨이를 포함하고, 상기 제2 서브 경로는 상기 제1 게이트웨이와 다른 제2 게이트웨이를 포함하는, 장치.
  28. 제26항 또는 제27항에 있어서, 상기 클라이언트 장치는 상기 제1 서브 경로를 통해 상기 적어도 하나의 자원의 제1 부분을 획득하고 상기 제2 서브 경로를 통해 상기 적어도 하나의 자원의 제2 부분을 획득하는, 장치.
  29. 제28항에 있어서, 상기 제1 부분이 상기 제2 부분과 구별되는, 장치.
  30. 제1항 내지 제29항 중 어느 한 항에 있어서, 상기 클라이언트 장치는 상기 클라이언트 장치로부터 상기 하나 이상의 서버로의 요청에 대한 응답으로 상기 적어도 하나의 자원을 획득하는, 장치.
  31. 제30항에 있어서, 상기 요청이 HTTP 또는 HTTPS 요청을 포함하는, 장치.
  32. 제1항 내지 제31항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 스트리밍 자원을 포함하는, 장치.
  33. 제1항 내지 제32항 중 어느 한 항에 있어서, 상기 장치는
    상기 하나 이상의 서버로부터의 명령어에 대한 응답으로, 상기 하나 이상의 서버에 상기 클라이언트 장치에 대한 업데이트된 클라이언트 구성 상태를 제공하는, 장치.
  34. 제33항에 있어서, 상기 업데이트된 클라이언트 구성 상태는 상기 클라이언트 장치가 적어도 단방향으로 통신할 수 있는 다른 장치들에 대한 상기 정보를 포함하거나 이 정보에 기초하는, 장치.
  35. 제1항 내지 제34항 중 어느 한 항에 있어서, 상기 장치는
    다른 장치들 - 상기 클라이언트 장치가 상기 다른 장치들과 통신할 수 있음 - 에 대한 정보를 결정하도록 더 구성 및 적응되는, 장치.
  36. 제35항에 있어서, 상기 장치가 상기 하나 이상의 서버로부터의 명령어에 대한 응답으로 다른 장치들에 대한 상기 정보를 결정하는, 장치.
  37. 제1항 내지 제36항 중 어느 한 항에 있어서, 상기 장치는
    상기 하나 이상의 서버들로부터 상기 제1 서브 네트워크 구성과 구별되는 수정된 서브 네트워크 구성을 획득하는, 장치.
  38. 제37항에 있어서, 상기 수정된 서브 네트워크 구성이 상기 제1 서브 네트워크 구성의 상기 적어도 하나의 경로 상의 적어도 하나의 장치로부터의 클라이언트 구성 정보에 기초하여 결정된, 장치.
  39. 제38항에 있어서, 적어도 하나의 장치 - 이 적어도 하나의 장치로부터 클라이언트 구성 정보가 획득됨 - 가 상기 클라이언트 장치를 포함하는, 장치.
  40. 제37항 내지 제39항 중 어느 한 항에 있어서, 상기 수정된 서브 네트워크 구성은 제1 서브 네트워크 구성 내에 있지 않은 적어도 하나의 새로운 경로를 포함하는, 장치.
  41. 제40항에 있어서, 상기 적어도 하나의 새로운 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상에 기초하여 선택되는, 장치.
  42. 제1항 내지 제41항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크가 메시 네트워크를 포함하는, 장치.
  43. 제1항 내지 제42항 중 어느 한 항에 있어서, 상기 하나 이상의 서버 중 적어도 일부는 적어도 하나의 게이트웨이와 함께 배치되는, 장치
  44. 제43항에 있어서, 상기 적어도 하나의 게이트웨이는 셀룰러 타워들을 포함하는, 장치.
  45. 제43항 또는 제44항에 있어서, 상기 셀룰러 타워 및 상기 하나 이상의 서버들 중 적어도 일부는 모바일 네트워크 운영자(MNO)에 의해 운영되는, 장치.
  46. 제1항 내지 제43항 중 어느 한 항에 있어서, 상기 하나 이상의 서버 중 적어도 일부는 무선 액세스 포인트 또는 라우터와 함께 배치되는, 장치.
  47. 제1항 내지 제46항 중 어느 한 항에 있어서, 상기 클라이언트 장치에 대한 상기 클라이언트 구성 상태는 (i) 클라이언트 장치의 배터리 전력 잔량, (ii) 클라이언트 장치가 외부에서 전원이 공급되는지의 여부, (iii) 클라이언트 장치가 안정된 인터넷 접속을 가지고 있는지의 여부, (iv) 클라이언트 장치의 IP 주소, (v) 클라이언트 장치의 위치, (vi) 클라이언트 장치의 방향, (vii) 클라이언트 장치의 모션 상태, (viii) 다른 장치들에 관한 정보 - 상기 클라이언트는 상기 다른 장치들과 적어도 단방향으로 통신할 수 있음 -, (ix) 클라이언트의 하드웨어의 상태 중 하나 이상을 포함하거나 이 하나 이상에 기초하는, 장치.
  48. 제1항 내지 제47항 중 어느 한 항에 있어서, 상기 하나 이상 서버들로부터 상기 클라이언트 장치로의 상기 적어도 하나의 경로는 의사 게이트웨이를 포함하는, 장치.
  49. 제1항 내지 제48항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 하나의 게이트웨이로의 직접 연결을 갖는, 장치.
  50. 제1항 내지 제49항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 하나의 셀룰러 게이트웨이로의 직접 연결을 갖는, 장치.
  51. 제1항 내지 제50항 중 어느 한 항에 있어서, 상기 장치가 무선 원격통신 장치이거나 또는 이 무선 원격통신 장치를 포함하는, 장치.
  52. 제1항 내지 제51항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택된, 장치.
  53. 하나 이상 서버를 포함하는 시스템의 원격통신 장치에서 동작 가능한 컴퓨터 구현 방법으로서, 상기 장치는 상기 시스템에서 클라이언트 장치이고,
    상기 방법은,
    상기 클라이언트 장치에 대한 클라이언트 구성 상태를 상기 하나 이상의 서버에 제공하는 단계,
    상기 하나 이상의 서버로부터 제1 서브 네트워크 구성 - 상기 제1 서브 네트워크 구성은 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 적어도 하나의 경로를 포함하고, 상기 제1 서브 네트워크 구성은 상기 클라이언트 구성 상태와 적어도 하나의 다른 클라이언트 장치의 적어도 하나의 다른 클라이언트 구성 상태에 기초함 - 을 획득하는 단계를 포함하고,
    상기 클라이언트 장치는 상기 하나 이상의 서버를 통해 적어도 하나의 자원을 획득하기 위해 상기 제1 서브 네트워크 구성에 지정된 경로를 사용할 수 있는, 방법.
  54. 제53항에 있어서, 상기 클라이언트에 대한 상기 제1 서브 네트워크 구성이 다수의 다른 클라이언트 장치들의 클라이언트 구성들에 기초하는, 방법.
  55. 제53항 또는 제54항에 있어서, 상기 적어도 하나의 경로가 하이브리드 경로를 포함하는, 방법.
  56. 제55항에 있어서, 상기 하이브리드 경로가 별개의 통신 인터페이스들을 사용하는 경로 마디들을 포함하는, 방법.
  57. 제53항 내지 제56항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 하나의 중간 클라이언트를 포함하는, 방법.
  58. 제53항 내지 제57항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로는
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택된, 방법.
  59. 제53항 내지 제58항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 하나의 게이트웨이를 포함하는, 방법.
  60. 제59항에 있어서, 상기 적어도 하나의 경로가 적어도 두 개의 게이트웨이를 포함하는, 방법.
  61. 제53항 내지 제60항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 하나의 의사 게이트웨이를 포함하는, 방법.
  62. 제53항 내지 제61항 중 어느 한 항에 있어서, 제1 서브 네트워크 구성이 이전에 알려진 성공한 네트워크 구성에 기초하는, 방법.
  63. 제53항 내지 제62항 중 어느 한 항에 있어서, 상기 장치에 대한 상기 제1 서브 네트워크 구성이 적어도 하나의 다른 클라이언트 장치의 클라이언트 구성에 기초하는, 방법.
  64. 제53항 내지 제63항 중 어느 한 항에 있어서, 상기 클라이언트 장치는 상기 적어도 하나의 자원을, 적어도 부분적으로, 적어도 하나의 경로의 일부를 통해 획득하는, 방법.
  65. 제53항 내지 제64항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로는 상기 클라이언트 장치와 다른 적어도 하나의 제1 장치를 포함하는, 방법.
  66. 제65항에 있어서, 상기 경로 상의 상기 적어도 하나의 제1 장치는 상기 하나 이상의 서버에 의해 상기 적어도 하나의 자원의 적어도 일부의 사본을 갖는 것으로 가정되는, 방법.
  67. 제64항 내지 제66항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로는 적어도 두 개의 게이트웨이를 포함하고, 상기 클라이언트는 상기 적어도 하나의 자원을 상기 적어도 두 개의 게이트웨이를 통해 획득하는, 방법.
  68. 제67항에 있어서, 상기 두 개의 게이트웨이는 셀룰러 게이트웨이들, WiFi 게이트웨이들 중에서 선택되는, 방법.
  69. 제67항 또는 제68항에 있어서, 상기 적어도 두 개의 게이트웨이는 적어도 하나의 다른 게이트웨이와는 별개의 프로토콜을 사용하는 적어도 하나의 게이트웨이를 포함하는, 방법.
  70. 제69항에 있어서, 상기 제1 게이트웨이는 셀룰러 게이트웨이를 포함하고, 상기 제2 게이트웨이는 비-셀룰러 게이트웨이를 포함하는, 방법.
  71. 제69항 또는 제70항에 있어서, 상기 제2 게이트웨이는 WiFi 게이트웨이를 포함하는, 방법.
  72. 제68항 내지 제71항 중 어느 한 항에 있어서, 상기 클라이언트가 상기 적어도 두 개의 게이트웨이를 통해 상기 하나 이상의 서버에 의해 결정된 비율로 상기 적어도 하나의 자원을 획득하는, 방법.
  73. 제72항에 있어서, 상기 비율이
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상에 기초하는, 방법.
  74. 제68항 내지 제73항 중 어느 한 항에 있어서, 상기 장치는 상기 적어도 하나의 자원을 상기 적어도 두 개의 게이트웨이를 통해 인터리브 방식으로 획득하는, 방법.
  75. 제68항 내지 제74항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 제1 부분 및 제2 부분을 포함하며, 상기 제2 부분은 상기 제1 부분과 다르며, 상기 클라이언트 장치는, 적어도 부분적으로, 상기 제1 게이트웨이를 통해 제1 부분을 획득하고, 상기 클라이언트 장치는, 적어도 부분적으로, 상기 제2 게이트웨이를 통해 상기 제2 부분을 획득하는, 방법.
  76. 제53항 내지 제75항 중 어느 한 항에 있어서, 상기 클라이언트 장치는 상기 클라이언트 장치로부터 상기 하나 이상의 서버로의 요청에 대한 응답으로 상기 적어도 하나의 자원을 획득하는, 방법.
  77. 제76항에 있어서, 상기 요청이 HTTP 또는 HTTPS 요청을 포함하는, 방법.
  78. 제53항 내지 제77항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 스트리밍 자원을 포함하는, 방법.
  79. 제53항 내지 제78항 중 어느 한 항에 있어서,
    상기 하나 이상의 서버로부터의 명령어에 대한 응답으로, 상기 하나 이상의 서버에 상기 클라이언트 장치에 대한 업데이트된 클라이언트 구성 상태를 제공하는, 방법.
  80. 제53항 내지 제79항 중 어느 한 항에 있어서, 상기 방법은
    상기 하나 이상의 서버로부터의 명령에 대한 응답으로, 클라이언트 장치가 통신할 수 있는 다른 장치들에 대한 정보를 결정하고, 상기 업데이트된 클라이언트 구성 상태가 클라이언트가 적어도 단방향으로 통신할 수 있는 다른 장치들에 대한 상기 정보를 포함하거나 또는 이 정보에 기초하는, 방법.
  81. 제53항 내지 제80항 중 어느 한 항에 있어서, 상기 방법은
    상기 하나 이상의 서버들로부터 상기 제1 서브 네트워크 구성과 구별되는 수정된 서브 네트워크 구성을 획득하는, 방법.
  82. 제81항에 있어서,
    상기 수정된 서브 네트워크 구성이 상기 제1 서브 네트워크 구성의 상기 적어도 하나의 경로 상의 적어도 하나의 장치로부터의 클라이언트 구성 정보에 기초하여 결정된, 방법.
  83. 제82항에 있어서, 적어도 하나의 장치 - 이 적어도 하나의 장치로부터 클라이언트 구성 정보가 획득됨 - 가 상기 클라이언트 장치를 포함하는, 방법.
  84. 제81항 내지 제83항 중 어느 한 항에 있어서, 상기 수정된 서브 네트워크 구성은 제1 서브 네트워크 구성 내에 있지 않은 적어도 하나의 새로운 경로를 포함하는, 방법.
  85. 제81항 내지 제84항 중 어느 한 항에 있어서, 상기 수정된 서브 네트워크 구성이 클라이언트가 통신할 수 있는 다른 장치들에 대한 정보에 기초하여 결정된, 방법.
  86. 제81항 내지 제85항 중 어느 한 항에 있어서, 상기 적어도 하나의 새로운 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택된, 방법.
  87. 제53항 내지 제86항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크가 메시 네트워크를 포함하는, 방법.
  88. 제53항 내지 제87항 중 어느 한 항에 있어서, 상기 하나 이상의 서버 중 적어도 일부는 적어도 하나의 게이트웨이와 함께 배치되는, 방법.
  89. 제53항 내지 제88항 중 어느 한 항에 있어서, 상기 하나 이상의 서버 중 적어도 일부는 무선 액세스 포인트 또는 라우터와 함께 배치되는, 방법.
  90. 제88항에 있어서, 상기 적어도 하나의 게이트웨이는 셀룰러 타워들을 포함하는, 방법.
  91. 제90항에 있어서, 상기 셀룰러 타워 및 상기 하나 이상의 서버들 중 적어도 일부는 모바일 네트워크 운영자(MNO)에 의해 운영되는, 방법.
  92. 제53항 내지 제91항 중 어느 한 항에 있어서, 상기 클라이언트 장치에 대한 상기 클라이언트 구성 상태는 (i) 클라이언트의 배터리 전력 잔량, (ii) 클라이언트가 외부에서 전원이 공급되는지의 여부, (iii) 클라이언트가 안정된 인터넷 접속을 가지고 있는지의 여부, (iv) 클라이언트의 IP 주소, (v) 클라이언트의 위치, (vi) 클라이언트의 방향, (vii) 클라이언트의 모션 상태, (viii) 다른 장치들에 관한 정보 - 클라이언트 장치는 상기 다른 장치들과 통신할 수 있음 -, (ix) 클라이언트의 하드웨어의 상태 중 하나 이상을 포함하거나 이 하나 이상에 기초하는, 방법.
  93. 제53항 내지 제92항 중 어느 한 항에 있어서, 상기 클라이언트 장치에 대한 클라이언트 구성 상태는 상기 클라이언트 장치에 대한 식별 정보를 포함하거나 이 식별 정보에 기초하는, 방법.
  94. 제53항 내지 제93항 중 어느 한 항에 있어서, 상기 클라이언트 장치에 대한 클라이언트 구성 상태는 상기 클라이언트가 통신할 수 있는 다른 장치들에 대한 정보를 포함하거나 이 정보에 기초하는, 방법.
  95. 제53항 내지 제94항 중 어느 한 항에 있어서, 상기 하나 이상 서버들로부터 상기 클라이언트 장치로의 상기 적어도 하나의 경로는 의사 게이트웨이를 포함하는, 방법.
  96. 제53항 내지 제95항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 하나의 셀룰러 게이트웨이로의 직접 연결을 갖는, 방법.
  97. 제53항 내지 제96항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 하나의 게이트웨이로의 직접 연결을 갖는, 방법.
  98. 제53항 내지 제96항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 다른 클라이언트 장치들을 위한 의사 게이트웨이로서 작동하는, 방법.
  99. 제53항 내지 제98항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 무선 원격통신 장치인, 방법.
  100. 제53항 내지 제99항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크 구성에 지정된 상기 경로는 다수의 서브 경로를 포함하고, 상기 다수의 서브 경로는 제1 서브 경로, 및 상기 제1 서브 경로와 다른 제2 서브 경로를 포함하고, 상기 클라이언트 장치는 상기 적어도 하나의 자원을 상기 제1 서브 경로와 상기 제2 서브 경로를 통해 획득하는, 방법.
  101. 제100항에 있어서, 상기 제1 서브 경로는 제1 게이트웨이를 포함하고, 상기 제2 서브 경로는 상기 제1 게이트웨이와 다른 제2 게이트웨이를 포함하는, 방법.
  102. 제100항 또는 제101항에 있어서, 상기 클라이언트 장치는 상기 제1 서브 경로를 통해 상기 적어도 하나의 자원의 제1 부분을 획득하고 상기 제2 서브 경로를 통해 상기 적어도 하나의 자원의 제2 부분을 획득하는, 방법.
  103. 제102항에 있어서, 상기 제1 부분이 상기 제2 부분과 구별되는, 방법.
  104. 제59항에 있어서, 상기 적어도 하나의 게이트웨이는 인터넷에 접속되는, 방법.
  105. 제53항 또는 제104항에 있어서, 적어도 하나의 서버를 통해 그리고 상기 제1 서브 네트워크 구성에서 지정된 경로의 적어도 일부를 통해 적어도 하나의 자원을 획득하는, 방법.
  106. 일시적이지 않은 컴퓨터 판독 가능 매체에 저장된 컴퓨터 판독 가능 명령어들을 갖는 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 판독 가능 명령어들은 컴퓨터 구현 방법을 구현할 명령어들을 포함하고, 상기 방법은 하나 이상의 서버를 포함하는 시스템의 무선 원격통신 장치 상에서 동작 가능하고,
    상기 방법은 제1항 내지 제105항 중 어느 한 항의 방법을 포함하는, 컴퓨터 프로그램 제품.
  107. 하나 이상의 서버를 포함하는 시스템에서 작동 가능한 컴퓨터 구현 방법으로서, 상기 하나 이상의 서버는 하드웨어와 함께 소프트웨어를 포함하고, 상기 하드웨어는 적어도 하나 이상의 프로세서와 메모리를 포함하고, 상기 방법은
    클라이언트 장치에 대한 클라이언트 구성 상태를 획득하는 단계 - 상기 클라이언트 장치는 상기 시스템에 등록된 원격통신 장치임 -;
    상기 클라이언트 구성 상태에 기초하여, 상기 클라이언트에 대한 제1 서브 네트워크 구성을 결정하는 단계 - 상기 제1 서브 네트워크 구성은 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 적어도 하나의 경로를 포함함 -; 및
    상기 제1 서브 네트워크 구성을 상기 클라이언트 장치에 제공하는 단계
    를 포함하는, 방법.
  108. 제107항에 있어서, 상기 클라이언트 장치에 대한 상기 제1 서브 네트워크는 또한 하나 이상의 다른 클라이언트 장치의 클라이언트 구성들에 기초하는, 방법.
  109. 제107항 또는 제108항에 있어서, 상기 적어도 하나의 경로가 하이브리드 경로를 포함하는, 방법.
  110. 제107항 내지 제109항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 하나 이상의 중간 클라이언트를 포함하는, 방법.
  111. 제107항 내지 제110항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택되는, 방법.
  112. 제107항 내지 제111항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 하나의 게이트웨이 장치를 포함하는, 방법.
  113. 제112항에 있어서, 상기 적어도 하나의 경로가 적어도 두 개의 게이트웨이 장치를 포함하는, 방법.
  114. 제107항 내지 제113항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크 구성이 이전에 알려진 성공한 네트워크 구성에 기초하는, 방법.
  115. 제107항 내지 제114항 중 어느 한 항에 있어서, 상기 장치에 대한 상기 제1 서브 네트워크 구성이 적어도 하나의 다른 클라이언트 장치의 클라이언트 구성에 기초하는, 방법.
  116. 제107항 내지 제115항 중 어느 한 항에 있어서,
    상기 클라이언트 장치로부터의 요청에 대한 응답으로, 적어도 하나의 자원이 상기 클라이언트 장치에 제공되게 하는 단계를 더 포함하고, 상기 적어도 하나의 자원이 상기 클라이언트 장치에, 적어도 부분적으로, 상기 적어도 하나의 경로의 일부를 통해 제공되는, 방법.
  117. 제107항 내지 제116항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 상기 클라이언트 장치와 다른 적어도 하나의 제1 장치를 포함하는, 방법.
  118. 제116항 또는 제117항 중 어느 한 항에 있어서, 적어도 하나의 자원의 적어도 일부를 상기 클라이언트 장치에 제공함에 의해 적어도 하나의 자원이 상기 클라이언트 장치에 제공되게 하는 단계를 더 포함하는, 방법.
  119. 제117항 또는 제118항에 있어서, 적어도 부분적으로, 상기 경로 상의 상기 적어도 하나의 제1 장치에 의해, 적어도 하나의 자원이 상기 클라이언트 장치에 제공되도록 하는 단계를 더 포함하는, 방법.
  120. 제119항에 있어서, 상기 경로 상의 상기 적어도 하나의 제1 장치가 상기 적어도 하나의 자원의 적어도 일부의 사본을 갖는 것으로 알려진, 방법.
  121. 제116항 내지 제120항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 두 개의 게이트웨이 장치를 포함하고, 상기 적어도 하나의 자원이 상기 적어도 두 개의 게이트웨이 장치를 통해 상기 클라이언트 장치에 제공되는, 방법.
  122. 제121항에 있어서, 상기 적어도 두 개의 게이트웨이 장치가 셀룰러 게이트웨이 장치들, WiFi 게이트웨이 장치들 중에서 선택되는, 방법.
  123. 제121항 또는 제122항에 있어서, 상기 적어도 두 개의 게이트웨이 장치가 하이브리드 게이트웨이 장치를 포함하는, 방법.
  124. 제123항에 있어서, 상기 하이브리드 게이트웨이 장치들이 제1 게이트웨이 장치 및 제2 게이트웨이 장치를 포함하고, 상기 제1 게이트웨이 장치 및 제2 게이트웨이 장치는 하이브리드인, 방법.
  125. 제124항에 있어서, 상기 제1 게이트웨이 장치가 셀룰러 게이트웨이 장치를 포함하고, 상기 제2 게이트웨이 장치가 비-셀룰러 게이트웨이 장치를 포함하는, 방법.
  126. 제124항 또는 제125항에 있어서, 상기 제2 게이트웨이 장치가 무선 액세스 포인트 또는 라우터를 포함하는, 방법.
  127. 제121항 내지 제126항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원이 상기 적어도 두 개의 게이트웨이 장치를 통해 상기 하나 이상의 서버에 의해 결정된 비율로 상기 클라이언트 장치에 제공되는, 방법.
  128. 제127항에 있어서, 상기 비율이
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하는, 방법.
  129. 제121항 내지 제128항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원이 상기 적어도 두 개의 게이트웨이 장치를 통해 상기 클라이언트 장치에 인터리브 방식으로 제공하는, 방법.
  130. 제121항 내지 제129항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 초기 부분과 나머지 부분을 포함하고, 상기 나머지 부분은 상기 초기 부분과 다르고, 상기 초기 부분은 상기 클라이언트 장치에, 적어도 부분적으로, 상기 제1 게이트웨이 장치에 의해 제공되고, 상기 나머지 부분은 상기 클라이언트 장치에, 적어도 부분적으로, 상기 제2 게이트웨이 장치에 의해 제공되는, 방법.
  131. 제116항 내지 제130항 중 어느 한 항에 있어서, 상기 클라이언트로부터의 상기 요청이 상기 적어도 하나의 자원에 대한 요청을 포함하는, 방법.
  132. 제116항 내지 제131항 중 어느 한 항에 있어서, 상기 요청이 HTTP 또는 HTTPS 요청을 포함하는, 방법.
  133. 제116항 내지 제132항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 스트리밍 자원을 포함하는, 방법
  134. 제107항 내지 제133항 중 어느 한 항에 있어서,
    클라이언트 구성 정보를 상기 제1 서브 네트워크 구성의 상기 적어도 하나의 경로 상의 적어도 하나의 장치로부터 획득하는 단계;
    상기 제1 서브 네트워크 구성을 상기 클라이언트 구성 정보에 기초하여 수정하여 상기 제1 서브 네트워크 구성과 다른 수정된 서브 네트워크 구성을 형성하는 단계; 및
    상기 수정된 서브 네트워크 구성을 상기 클라이언트 장치에 제공하는 단계
    를 더 포함하는, 방법.
  135. 제134항에 있어서, 적어도 하나의 장치 - 이 적어도 하나의 장치로부터 클라이언트 구성 정보가 획득됨 - 가 상기 클라이언트 장치를 포함하는, 방법.
  136. 제135항에 있어서, 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 클라이언트 구성 정보를 제공하라는 요청에 대한 응답으로 상기 클라이언트 구성 정보가 상기 클라이언트 장치로부터 획득된, 방법.
  137. 제134항 내지 제136항 중 어느 한 항에 있어서, 상기 수정된 서브 네트워크 구성은 상기 제1 서브 네트워크 구성 내에 있지 않은 적어도 하나의 새로운 경로를 포함하는, 방법.
  138. 제134항 내지 제137항 중 어느 한 항에 있어서, 상기 적어도 하나의 새로운 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택되는, 방법.
  139. 제136항 내지 제138항 중 어느 한 항에 있어서,
    상기 클라이언트 장치로부터의 제2 요청에 대한 응답으로, 적어도 하나의 자원이 상기 클라이언트 장치에 제공되게 하는 단계를 더 포함하고, 상기 적어도 하나의 제2 자원이, 적어도 부분적으로, 상기 적어도 하나의 새로운 경로의 일부를 통해 상기 클라이언트 장치에 제공되는, 방법.
  140. 제139항에 있어서, 상기 적어도 하나의 제2 자원이 상기 적어도 하나의 제1 자원과 구별되는, 방법.
  141. 제107항 내지 제140항 중 어느 한 항에 있어서,
    상기 서브 네트워크 구성의 양태들을 모니터링하는 단계; 및
    상기 서브 네트워크 구성을 상기 모니터링에 적어도 부분적으로 기초하여 수정하는 단계를 더 포함하는, 방법.
  142. 제107항 내지 제141항 중 어느 한 항에 있어서, 상기 서브 네트워크가 메시 네트워크인, 방법.
  143. 제107항 내지 제142항 중 어느 한 항에 있어서, 상기 하나 이상의 서버들 중 적어도 일부가 적어도 하나의 게이트웨이 장치와 같이 함께 배치되는, 방법.
  144. 제143항에 있어서, 상기 적어도 하나의 게이트웨이 장치가 셀 타워를 포함하는, 방법.
  145. 제143항 또는 제144항에 있어서, 상기 셀 타워 및 상기 하나 이상의 서버들 중 적어도 일부는 모바일 네트워크 운영자(MNO)에 의해 운영되는, 방법.
  146. 제107항 내지 제143항 중 어느 한 항에 있어서, 상기 하나 이상의 서버들 중 적어도 일부가 라우터와 함께 배치되는, 방법.
  147. 제107항 내지 제146항 중 어느 한 항에 있어서, 상기 클라이언트 장치에 대한 상기 클라이언트 구성 상태는 (i) 클라이언트의 배터리 전력 잔량, (ii) 클라이언트가 외부에서 전원이 공급되는지의 여부, (iii) 클라이언트가 안정된 인터넷 접속을 가지고 있는지의 여부, (iv) 클라이언트의 IP 주소, (v) 클라이언트의 위치, (vi) 클라이언트의 방향, (vii) 클라이언트의 모션 상태, (viii) 클라이언트의 하드웨어의 상태 중 하나 이상을 포함하는, 방법.
  148. 제107항 내지 제147항 중 어느 한 항에 있어서, 클라이언트 장치에 대한 클라이언트 구성 상태는 클라이언트 장치에 대한 식별 정보를 포함하는, 방법.
  149. 제107항 내지 제148항 중 어느 한 항에 있어서, 클라이언트 장치의 클라이언트 구성 상태는 클라이언트가 통신할 수 있는 다른 장치들에 대한 정보를 포함하는, 방법.
  150. 제107항 내지 제149항 중 어느 한 항에 있어서, 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 상기 적어도 하나의 경로는 의사 게이트웨이를 포함하는, 방법.
  151. 제107항 내지 제150항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 하나의 셀룰러 게이트웨이로의 직접 연결을 갖는, 방법.
  152. 제107항 내지 제151항 중 어느 한 항에 있어서,
    상기 원격통신 장치를 상기 시스템에 상기 클라이언트 장치로서 등록하는 단계를 더 포함하는, 방법.
  153. 제107항 내지 제152항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 두 개의 통신 프로토콜을 지원하는, 방법.
  154. 제107항 내지 제153항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 무선 원격통신 장치를 포함하는, 방법.
  155. 일시적이지 않은 컴퓨터 판독 가능 매체에 저장된 컴퓨터 판독 가능 명령어들을 갖는 컴퓨터 프로그램 제품으로서, 상기 컴퓨터 판독 가능 명령어들은 컴퓨터 구현 방법을 구현할 명령어들을 포함하고, 상기 방법은 하나 이상의 서버를 포함하는 시스템의 무선 원격통신 장치에서 동작 가능하고,
    상기 방법은 제1항 내지 제154항 중 어느 한 항의 방법을 포함하는, 컴퓨터 프로그램 제품.
  156. 하나 이상의 서버를 포함하는 시스템으로서, 상기 하나 이상의 서버가
    무선 원격통신 장치를 상기 시스템에 상기 클라이언트 장치로서 등록하고;
    클라이언트 장치에 대한 클라이언트 구성 상태를 획득하고;
    상기 클라이언트 구성 상태에 기초하여, 상기 클라이언트 장치에 대한 제1 서브 네트워크 구성을 결정하고 - 상기 제1 서브 네트워크 구성은 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 적어도 하나의 경로를 포함함 -; 및
    상기 제1 서브 네트워크 구성을 상기 클라이언트 장치에 제공하기 위해
    구성 및 적응되는, 시스템.
  157. 제156항에 있어서, 상기 클라이언트에 대한 상기 제1 서브 네트워크는 또한 하나 이상의 다른 클라이언트 장치의 클라이언트 구성들에 기초하는, 시스템.
  158. 제156항 또는 제157항에 있어서, 상기 적어도 하나의 경로가 하이브리드 경로를 포함하는, 시스템.
  159. 제156항 내지 제158항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 하나 이상의 중간 클라이언트들을 포함하는, 시스템.
  160. 제156항 내지 제159항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택되는, 시스템.
  161. 제156항 내지 제160항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 하나의 게이트웨이 장치를 포함하는, 시스템.
  162. 제161항에 있어서, 상기 적어도 하나의 경로가 적어도 두 개의 게이트웨이 장치를 포함하는, 시스템.
  163. 제156항 내지 제162항 중 어느 한 항에 있어서, 상기 제1 서브 네트워크 구성이 이전에 알려진 성공한 네트워크 구성에 기초하는, 시스템.
  164. 제156항 내지 제163항 중 어느 한 항에 있어서, 상기 하나 이상의 서버가 추가로,
    상기 클라이언트 장치로부터의 요청에 대한 응답으로, 적어도 하나의 자원이 상기 클라이언트 장치에 제공되게 하기 위해 구성 및 적응되는 - 상기 적어도 하나의 자원이 상기 클라이언트 장치에, 적어도 부분적으로, 상기 적어도 하나의 경로의 일부를 통해 제공됨 -, 시스템.
  165. 제156항 내지 제164항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로는 상기 클라이언트 장치와 다른 적어도 하나의 제1 장치를 포함하는, 시스템.
  166. 제164항 또는 제165항에 있어서, 상기 하나 이상의 서버가 추가로,
    적어도 하나의 자원의 적어도 일부가 상기 클라이언트 장치에 제공됨에 의해 상기 적어도 하나의 자원이 상기 클라이언트 장치에 제공되게 하기 위해 구성 및 적응되는, 시스템.
  167. 제165항 또는 제166항에 있어서, 상기 하나 이상의 서버가 추가로,
    적어도 부분적으로, 상기 경로 상의 상기 적어도 하나의 제1 장치에 의해, 적어도 하나의 자원이 상기 클라이언트 장치에 제공되게 하기 위해 구성 및 적응되는, 시스템.
  168. 제167항에 있어서, 상기 경로 상의 상기 적어도 하나의 제1 장치가 상기 적어도 하나의 자원의 적어도 일부의 사본을 갖는 것으로 알려진, 시스템.
  169. 제164항 내지 제168항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 적어도 두 개의 게이트웨이 장치를 포함하고, 상기 적어도 하나의 자원이 상기 적어도 두 개의 게이트웨이 장치를 통해 상기 클라이언트 장치에 제공되는, 시스템.
  170. 제169항에 있어서, 상기 적어도 두 개의 게이트웨이 장치가 셀룰러 게이트웨이 장치들, WiFi 게이트웨이 장치들 중에서 선택되는, 시스템.
  171. 제169항 또는 제170항에 있어서, 상기 적어도 두 개의 게이트웨이 장치가 상이한 통신 프로토콜들에 대한 게이트웨이 장치들을 포함하는, 시스템.
  172. 제171항에 있어서, 상기 하이브리드 게이트웨이 장치들이 제1 게이트웨이 장치 및 제2 게이트웨이 장치를 포함하고, 상기 제1 게이트웨이 장치 및 제2 게이트웨이 장치는 하이브리드인, 시스템.
  173. 제172항에 있어서, 상기 제1 게이트웨이 장치가 셀룰러 게이트웨이 장치를 포함하고, 상기 제2 게이트웨이 장치가 비-셀룰러 게이트웨이 장치를 포함하는, 시스템.
  174. 제172항 또는 제173항에 있어서, 상기 제2 게이트웨이 장치가 WiFi 게이트웨이 장치를 포함하는, 시스템.
  175. 제169항 내지 제174항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원이 상기 적어도 두 개의 게이트웨이 장치를 통해 상기 하나 이상의 서버에 의해 결정된 비율로 상기 클라이언트 장치에 제공되는, 시스템.
  176. 제175항에 있어서, 상기 비율이
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하는, 시스템.
  177. 제14항 내지 제21항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원이 상기 적어도 두 개의 게이트웨이 장치를 통해 상기 클라이언트 장치에 인터리브 방식으로 제공되는, 시스템.
  178. 제169항 내지 제177항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 초기 부분과 나머지 부분을 포함하고, 상기 나머지 부분은 상기 초기 부분과 다르고, 상기 초기 부분은 상기 클라이언트 장치에, 적어도 부분적으로, 상기 제1 게이트웨이 장치에 의해 제공되고, 상기 나머지 부분은 상기 클라이언트 장치에, 적어도 부분적으로, 상기 제2 게이트웨이 장치에 의해 제공되는, 시스템.
  179. 제164항 내지 제178항 중 어느 한 항에 있어서, 상기 클라이언트로부터의 상기 요청이 상기 적어도 하나의 자원에 대한 요청을 포함하는, 시스템.
  180. 제164항 내지 제179항 중 어느 한 항에 있어서, 상기 요청이 HTTP 또는 HTTPS 요청을 포함하는, 시스템.
  181. 제164항 내지 제180항 중 어느 한 항에 있어서, 상기 적어도 하나의 자원은 스트리밍 자원을 포함하는, 시스템.
  182. 제156항 내지 제181항 중 어느 한 항에 있어서, 상기 하나 이상의 서버가 추가로,
    클라이언트 구성 정보를 상기 제1 서브 네트워크 구성의 상기 적어도 하나의 경로 상의 적어도 하나의 장치로부터 획득하고;
    상기 제1 서브 네트워크 구성을 상기 클라이언트 구성 정보에 기초하여 수정하여 상기 제1 서브 네트워크 구성과 다른 수정된 서브 네트워크 구성을 형성하고;
    상기 수정된 서브 네트워크 구성을 상기 클라이언트 장치에 제공하기 위해
    구성 및 적응되는, 시스템.
  183. 제182항에 있어서, 적어도 하나의 장치 - 이 적어도 하나의 장치로부터 클라이언트 구성 정보가 획득됨 - 가 상기 클라이언트 장치를 포함하는, 시스템.
  184. 제182항 또는 제183항에 있어서, 상기 수정된 서브 네트워크 구성은 상기 제1 서브 네트워크 구성 내에 있지 않은 적어도 하나의 새로운 경로를 포함하는, 시스템.
  185. 제182항 내지 제184항 중 어느 한 항에 있어서, 상기 수정된 서브 네트워크 구성이 상기 제1 서브 네트워크 구성의 토폴로지 변화에 기초하는, 시스템.
  186. 제156항 내지 제185항 중 어느 한 항에 있어서, 상기 장치에 대한 상기 제1 서브 네트워크 구성이 적어도 하나의 다른 클라이언트 장치의 클라이언트 구성에 기초하는, 시스템.
  187. 제182항 내지 제186항 중 어느 한 항에 있어서, 상기 적어도 하나의 새로운 경로가
    (a) 특정 사업자들의 세트;
    (b) WiFi 연결;
    (c) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트 장치들의 전력 상태;
    (d) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전원에 연결된 클라이언트 장치들;
    (e) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 전송 비용;
    (f) 하나 이상 서버들로부터 상기 클라이언트 장치로의 가능한 경로들 상의 스펙트럼 사용;
    (g) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 클라이언트들의 예상 배터리 소모;
    (h) 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 다수의 홉/중계;
    (i) 상기 하나 이상 서버로부터 상기 클라이언트 장치로의 가능한 경로들에 대한 예상 신뢰도 또는 오류율 또는 서비스 품질;
    (j) 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 가능한 경로들 상의 예상된 전송 속도
    중 하나 이상을 유리하게 하기 위해 선택되는, 시스템.
  188. 제156항 내지 제187항 중 어느 한 항에 있어서, 상기 하나 이상의 서버가 추가로,
    상기 서브 네트워크 구성의 양태들을 모니터링하고 상기 서브 네트워크 구성을 상기 모니터링에 적어도 부분적으로 기초하여 수정하기 위해 구성 및 적응되는, 시스템.
  189. 제156항 내지 제188항 중 어느 한 항에 있어서, 상기 서브 네트워크가 메시네트워크를 포함하는, 시스템.
  190. 제156항 내지 제189항 중 어느 한 항에 있어서, 상기 하나 이상의 서버들 중 적어도 일부가 적어도 하나의 게이트웨이 장치와 같이 함께 배치되는, 시스템.
  191. 제190항에 있어서, 상기 적어도 하나의 게이트웨이 장치가 셀 타워를 포함하는, 시스템.
  192. 제191항에 있어서, 상기 셀 타워 및 상기 하나 이상의 서버들 중 적어도 일부는 모바일 네트워크 운영자(MNO)에 의해 운영되는, 시스템.
  193. 제156항 내지 제188항 중 어느 한 항에 있어서, 상기 하나 이상의 서버들 중 적어도 일부가 라우터와 함께 배치되는, 시스템.
  194. 제156항 내지 제193항 중 어느 한 항에 있어서, 상기 클라이언트 장치에 대한 상기 클라이언트 구성 상태는 (i) 클라이언트의 배터리 전력 잔량, (ii) 클라이언트가 외부에서 전원이 공급되는지의 여부, (iii) 클라이언트가 안정된 인터넷 접속을 가지고 있는지의 여부, (iv) 클라이언트의 IP 주소, (v) 클라이언트의 위치, (vi) 클라이언트의 방향, (vii) 클라이언트의 모션 상태, (viii) 클라이언트의 하드웨어의 상태 중 하나 이상을 포함하거나 또는 이 하나 이상에 기초하는, 시스템.
  195. 제156항 내지 제194항 중 어느 한 항에 있어서, 클라이언트 장치에 대한 클라이언트 구성 상태는 클라이언트 장치에 대한 식별 정보를 포함하거나 또는 이 식별 정보에 기초하는, 시스템.
  196. 제156항 내지 제195항 중 어느 한 항에 있어서, 클라이언트 장치에 대한 클라이언트 구성 상태는 클라이언트가 통신할 수 있는 다른 장치들에 대한 정보를 포함하거나 또는 이 정보에 기초하는, 시스템.
  197. 제156항 내지 제196항 중 어느 한 항에 있어서, 상기 하나 이상의 서버로부터 상기 클라이언트 장치로의 상기 적어도 하나의 경로는 의사 게이트웨이를 포함하는, 시스템.
  198. 제156항 내지 제197항 중 어느 한 항에 있어서, 상기 클라이언트 장치가 적어도 하나의 셀룰러 게이트웨이로의 직접 연결을 갖는, 시스템.
  199. 제156항 내지 제198항 중 어느 한 항에 있어서, 상기 하나 이상의 서버가 추가로,
    클라이언트들에 대한 데이터를 버퍼링하고, 버퍼링된 데이터는 상기 하나 이상의 경로를 통해 전송하기 위해 구성 및 적응되는, 시스템.
  200. 제199항에 있어서, 상기 하나 이상의 서버가 추가로,
    상기 클라이언트에 대한 전송 오류를 해결하기 위해 클라이언트들의 버퍼링된 데이터를 사용하기 위해 구성 및 적응되는, 시스템.
  201. 제156항 내지 제200항 중 어느 한 항에 있어서, 상기 하나 이상의 서버가 추가로,
    전체 네트워크의 통합된 토폴로지 지도를 업데이트하기 위해 적어도 하나의 클라이언트로의 직접 접속을 이용하기 위해 구성 및 적응되는, 시스템.
  202. 제156항 내지 제201항 중 어느 한 항에 있어서, 상기 적어도 하나의 경로가 사전 계산되는, 시스템.
  203. 제156항 내지 제202항 중 어느 한 항에 있어서, 상기 하나 이상의 서버가 추가로,
    네트워크 내의 클라이언트들 사이에 단방향 링크들을 조립하여 네트워크의 종합적인 그래프를 생성하기 위해 구성 및 적응되는, 시스템.
KR1020177002867A 2014-07-01 2015-06-29 중앙 하이브리드 무선 자체 구성화 네트워크를 구현하는 방법, 장치 및 시스템 KR20170029540A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462019545P 2014-07-01 2014-07-01
US62/019,545 2014-07-01
US201562185717P 2015-06-28 2015-06-28
US62/185,717 2015-06-28
PCT/US2015/038251 WO2016003868A1 (en) 2014-07-01 2015-06-29 Methods, devices, and systems for implementing centralized hybrid wireless self-organizing networks

Publications (1)

Publication Number Publication Date
KR20170029540A true KR20170029540A (ko) 2017-03-15

Family

ID=55019866

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177002867A KR20170029540A (ko) 2014-07-01 2015-06-29 중앙 하이브리드 무선 자체 구성화 네트워크를 구현하는 방법, 장치 및 시스템

Country Status (4)

Country Link
EP (1) EP3164968B1 (ko)
KR (1) KR20170029540A (ko)
ES (1) ES2913209T3 (ko)
WO (1) WO2016003868A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10375213B2 (en) 2014-07-01 2019-08-06 Trinity Mobile Networks, Inc. Centralized hybrid wireless self-organizing networks

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10542476B2 (en) 2017-07-13 2020-01-21 Nokia Solutions And Networks Oy Selecting communication paths for application server queries of devices
EP3731369B1 (en) * 2019-04-24 2023-08-02 Hitachi Energy Switzerland AG Determining a network map defining a structure of a network
CN111478802B (zh) * 2020-03-30 2023-04-28 芯海科技（深圳）股份有限公司 配网处理方法、装置、系统、计算机设备和存储介质
CN113873678A (zh) * 2020-09-10 2021-12-31 华为技术有限公司 传输数据的方法和电子设备

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7484008B1 (en) * 1999-10-06 2009-01-27 Borgia/Cummins, Llc Apparatus for vehicle internetworks
US7941157B2 (en) * 2005-11-15 2011-05-10 Robert Bosch Gmbh Hybrid localization in wireless networks
US7966650B2 (en) * 2008-02-22 2011-06-21 Sophos Plc Dynamic internet address assignment based on user identity and policy compliance
US8223649B2 (en) * 2008-03-25 2012-07-17 Intel Corporation Method and apparatus for sending a packet from a source node to a destination node in the same broadcast domain
KR101620678B1 (ko) * 2011-05-20 2016-05-12 애플 인크. 하이브리드 네트워크 환경들에서 클라이언트 서버 인터액션을 위한 장치 및 방법들
GB2507161B (en) * 2012-08-19 2014-11-12 Box Inc Enhancement of upload and/or download performance based on client and/or server feedback information
US20150304411A1 (en) * 2012-09-20 2015-10-22 Telcordia Technologies, Inc. Self-Organizing Distributed Service Overlay for Wireless Ad Hoc Networks
US9113352B2 (en) * 2012-09-25 2015-08-18 Parallel Wireless, Inc. Heterogeneous self-organizing network for access and backhaul

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10375213B2 (en) 2014-07-01 2019-08-06 Trinity Mobile Networks, Inc. Centralized hybrid wireless self-organizing networks

Also Published As

Publication number Publication date
WO2016003868A1 (en) 2016-01-07
ES2913209T3 (es) 2022-06-01
EP3164968A4 (en) 2017-12-27
EP3164968B1 (en) 2022-02-16
EP3164968A1 (en) 2017-05-10

Similar Documents

Publication Publication Date Title
US10880407B2 (en) Centralized hybrid wireless self-organizing networks
US10798702B2 (en) Periodic frames for control plane data to manage multi-band wireless networking system
US9253015B2 (en) Transparent proxy architecture for multi-path data connections
US9432990B2 (en) Hybrid mesh network
KR101961049B1 (ko) 타임 슬롯화 채널 홉핑 네트워크에서의 효율적인 중앙 집중식 자원 및 스케줄 관리
US20120057456A1 (en) Method and apparatus for distributed communication using short range and wide range communication links
JP2007505553A (ja) 無線ネットワーキングシステムおよび方法
EP3164968B1 (en) Methods, devices and systems for implementing centralized hybrid wireless self-organizing networks
TW200904211A (en) Backhaul network for femto base stations
Chen et al. Routing for cognitive radio networks consisting of opportunistic links
WO2011078646A1 (en) Client load balancing, power management, and mobility in hierarchical wireless mesh networks
JP2012253750A (ja) ＭｉＡＮ及びＭｉＡＮ帯域幅集約方法並びに集約システム
EP1955498B1 (en) System, switch and method for data communication in a wireless network
Castignani et al. Urban 802.11 community networks for mobile users: Current deployments and prospectives
US20080165692A1 (en) Method and system for opportunistic data communication
Braun et al. Multihop wireless networks
Du et al. Interference-constrained routing over P2P-share enabled multi-hop D2D networks
Veni et al. Mobile ad hoc network
Barz et al. Improved community network node design using a DLEP based radio-to-router interface
US20230261994A1 (en) System for Reducing Rerouting Time in MANET Using Virtual Buffer Zone Technique
US7583611B1 (en) System and method to support communication between non-cognitive radios and cognitive radios
Jin et al. Bapu: efficient and practical bunching of access point uplinks
Duan Cooperative data transfers for 5G networks.
CN102170651B (zh) 可信802.11dsr邻节点探测及维护方法
van den Berg et al. Multi-hop wireless networks