KR101175689B1 - 다중-전송 구조에 대한 버퍼 제어 - Google Patents

Abstract

단말 구조상의 네트워크 (Network on Terminal Architecture (NoTA))에서 동작하는 어떤 활성의 통신 애플리케이션들에게 투명한 방식으로 자동화된 접속 관리를 위한 시스템이 개시된다. 애플리케이션 레벨 엔티티가 인터페이스를 경유하여 상위 레벨 통신 구조에게 요청을 함으로써 다른 노드를 액세스할 수 있을 것이다. 상기 상위 레벨 구조는, 하나 또는 그 이상의 전송들을 경유하여 다른 기기와의 통신을 설립함으로써 통신을 관리하도록 구성된 하위 레벨 구조와 인터액트할 수 있을 것이다. 적어도 하나의 실시예에서, 전송이 실패할 때에 손실되고 있는 데이터에 대한 보호를 하기 위해서, 상기 전송이 실패했을 때에 전송-독립적인 버퍼로부터 전송-특정 버퍼로 전달된 데이터를 저장하는 것을 포함하여, 준비가 된다. 실패가 발생하면, 상기 저장된 데이터는 다른 전송을 이용하여 송신되기 위해 즉시 포워딩 될 수 있을 것이다.

Description

다중-전송 구조에 대한 버퍼 제어 {Buffer control for multi-transport architectures}

본 발명은 통신 구조에 관한 것이며, 더 상세하게는, 하나 또는 그 이상의 전송 (transport)들을 사용하는 기기들 사이에서의 접속을 설립하기 위한 구조에 관한 것이다.

일반적으로, 소프트웨어 프로그램들은 프로세서에 의해 실행되는 명령어 세트들을 포함할 수 있을 것이며, 출력의 결과를 내는 계산 또는 결정을 할 때에 사용할 용도의 입력 (예를 들면, 데이터)을 수신하기 위해 또한 조직된다. 소프트웨어 기술은 이런 개별적인 명령어 세트들을 프로그램 모듈들로 변환하여 결국은 서로 집적되어 더 복잡한 프로그램을 형성하도록 발전된다. 오늘날의 더욱 복잡한 소프트웨어 프로그램들은, 예를 들면 자기 저장부 또는 광학 저장부 내에 저장된 것과 같은 로 (raw) 데이터, 알려진 유형의 다양한 사용자 인터페이스들을 통한 사용자 입력, 전자 센서 및/또는 전자기 센서로부터 전자적인 정보로 변환된 측정 정보 또는 모니터 정보 등과 같은 다양한 형상의 입력을 수신할 수 있을 것이다.

몇몇 예들에서, 프로그램들은 다른 소프트웨어 애플리케이션들에 의해 사용될 수 있는 데이터를 생성하도록 구성될 수 있을 것이다. 그러나, 어떤 프로그램은 한 프로그램으로부터 다른 프로그램으로 정보를 운반하도록 제공될 수 있을 것이다. 그 프로그램이 생성되기 전에 그런 관계가 알려지면, 그러면 한 프로그램의 출력을 다른 프로그램의 입력으로 변환하기 위한 특수한 전략이 고안될 수 있을 것이다. 전통적으로, 이런 전략은 기능적이지만 엄격한 소프트웨어 애플리케이션들로 이끌 것이며, 그런 애플리케이션들은 기능성, 플랫폼, 구조 등에서의 변경으로 인한 빈번한 그리고 아마도 실질적인 교정을 필요로 한다.

근래에, 프로그램들 사이에 정보를 공유하기 위한 더 유연한 모듈러 구조가 나타난다. 이런 프로그램들은 기기 동작 전체를 중단되지 않게 하면서 교정되거나 교체될 수 있는 모듈러 프로그램 유닛들 또는 "노드들"을 사용한다. 특히, 몇몇 노드들은 공유 메모리 공간에 정보를 저장할 수 있을 것이며, 다른 노드들은 저장된 정보를 그 공유 메모리 공간으로부터 읽을 수 있을 것이며 또는 이런 기능들을 결합할 수 있을 것이다. 다른 유형의 노드들은 통신 서비스들을 제공하기 위해 또한 특화될 수 있을 것이다. 이런 전략을 이용하여, 프로그램 엘리먼트들을 변경하는 것은 (예를 들면, 하나 또는 그 이상의 노드들을 변경, 추가 또는 삭제하는 것은) 다른 노트들과 능동적으로 통신을 하고 있는 노트들에는 영향을 끼치지 않을 수 있을 것이며, 그리고 정보는 단일의 위치에 저장될 수 있을 것이면서도 모든 노드들로부터 액세스 가능할 수 있을 것이기 때문에 메모리 사용은 최적화될 수 있을 것이다.

이런 전략이 단일의 기기 플랫폼에서 개념적으로 구현될 수 있지만, 노드들을 상이한 기기들 상에서 연결시키기 위한 실제의 솔루션은 현재는 존재하지 않는다. 한 노드가 다른 노드와 교신할 수 있는 전송 (transport) (예를 들면, 무선 통신 매체)의 설립을 용이하게 하는 것에 관한 문제점들이 현재 존재한다. 또한, 예를 들어, 환경적인 간섭, 범위 및/또는 트래픽 문제로 인하여, 선택된 전송이 이용 가능하지 않게 되면, 현재 실행들의 애플리케이션 하에서 완전히 새로운 접속 설정이 고안되어야만 할 것이다. 추가로, 다른 전송이 수동으로 설정되었거나 또는 원래의 전송으로의 자동화된 백업으로서 설정되었다고 해도, 대안의 전송이 이용 가능하지 않다면 (예를 들면, 문제점을 또한 겪고 있는 특별한 전송이면), 실질적인 위험은 여전히 존재한다. 실패가 나고 있는 또는 실패한 전송을 지원하는 자원들에 이미 할당된 데이터는 회복될 수 없기 때문에, 리스크는 손실 데이터 (예를 들면, 결손된 패킷들)에 관해서 또한 존재할 수 있을 것이며, 그러므로, 이 정보는 재전송 그리고/또는 다시 생성되어야만 할 수 있을 것이다. 이런 회복 프로세스는 불가피하게 시스템 자원들을 차지할 것이며 그리고 다음의 어떤 이어지는 데이터도 늦어지게 해서 상기 통신 기기에 의해 제공되는 전반적인 서비스 품질 (quality of service (QoS) )에 부정적인 영향의 결과를 가져오게 할 것이다.

본 발명의 목적은, 상기의 문제점을 해결할 수 있도록, 다수의 전송 (transport)들을 사용하는 기기들 사이에서의 효율적으로 접속을 설립하기 위한 방안을 제공하는 것이다.

본 발명은 단말 구조상의 네트워크 (Network on Terminal Architecture (NoTA))에서 동작하는 어떤 통신 애플리케이션들에도 투명할 수 있는 방식으로 자동화된 접속 관리를 위한 방법, 컴퓨터 프로그램, 기기 및 시스템을 적어도 포함할 수 있을 것이다. 애플리케이션 노드와 같은 애플리케이션 레벨 엔티티 (entity)는 상위 레벨 인터페이스를 통해서 상위 레벨 통신 구조로 요청을 함으로써 다른 노드에 액세스할 수 있을 것이다. 그러면 상기 상위 레벨 구조는, 예를 들면, 특별한 통신 전송을 경유하여 다른 기기 상의 프로그램 엘리먼트 (element)로의 접속을 용이하게 하기 위해 하위 레벨 구조와 인터액트 (interact)할 수 있을 것이다.

본 발명의 적어도 하나의 실시예에서, 다른 기기로의 전송을 위한 하나 또는 그 이상의 애플리케이션 및/또는 서비스 레벨 엔티티들로부터 제공되는 정보는 처음에는 전송-독립적인 데이터 버퍼 내에 저장될 수 있을 것이다. 나중에, 예를 들면, 이 정보를 다른 기기로 운반하기 위해서 특별한 전송이 선택된 후에, 상기 정보는 상기 선택된 전송에 대응하는 하위 레벨 전송-특정 데이터 버퍼로의 송신을 위한 준비의 일부로서 포워딩될 수 있을 것이다. 상기 전송-특정 버퍼는 그러면 상기 선택된 전송을 경유하여 다른 기기로 송신될 수 있을 것이다.

상기의 예에 따라, 상기 선택된 전송에서 마주칠 수 있을 가능한 문제점들을 고려하는 전략이 채택될 수 있을 것이다. 상기 선택된 전송을 이용하여 진행된 통신 링크에, 예를 들면, 통신 라인의 물리적인 단선, 서비스 범위 밖으로 이동, 주변의 간섭 등으로 인해서 고장이 발생할 수 있을 것이다. 결과적으로, 송신을 위해서 준비된 상기 전송-특정 버퍼로 이미 전달된 정보는 손실될 수 있을 것이다. 이런 상황을 고려하여, 본 발명의 다양한 실시예들은 상기 전송-특정 데이터 버퍼로 가장 최근에 전달되었던 상기 정보의 사본을 상기 송신이 성공적이라는 것을 전송-관련된 자원들이 검증할 수 있을 때까지 상기 전송-독립적인 데이터 버퍼 내에 유지할 수 있을 것이다. 이런 방식으로, 실패한 전송에 응답하는 교정 행동이 신속하게 수행될 수 있을 것이며, 이는 QoS에 가해지는 어떤 영향을 줄일 수 있을 것이다.

더 상세하게는, 상기 전송-독립적인 데이터 버퍼는 수신 메시지에 대한 어떤 종류의 확인이 다른 기기로부터 수신된 이후에 이전에-전달된 정보의 상기 유지된 사본을 삭제하기만 할 수 있을 것이다. 이는, 예를 들면, 어떤 문턱 조건이 충족될 때까지 전송 그 자체가 상기 정보를 다시 송신할 것을 또한 시도할 수 없다고 말하는 것은 아니다. 그러나, 상기 현재 선택된 전송이 실행 가능한 링크를 더 이상 제공할 수 없다는 결정이 내려지면, 본 발명의 다양한 실시예들은 그러면 대안의 전송과의 링크를 설립하기 위한 조치를 할 수 있을 것이다. 상기 새롭게 선택된 전송을 이용하여 새로운 접속이 설립된 후에, 상기 전송-독립적인 데이터 버퍼는 이전의 전송이 실패했을 때에 손실될 수 있었을 상기 정보의 상기 유지된 사본을, 다시 송신하기 위해 준비된 상기 새롭게 선택된 전송에 대응하는 전송-특정 데이터 버퍼로 송신할 수 있을 것이다.

정보를 송신하는 중에 다양한 원인으로 인해서 송신이 실패하는 경우, 본 발명을 통해서, 상기 실패한 송신으로 인해서 손실되었을 정보를 새로운 전송 과정을 통해서 다시 송신할 수 있어서, 네트워크의 QoS 및 안정성을 향상시킬 수 있도록 한다.

본 발명은 첨부된 도면들과 결합하여 고려된 다양한 실시예들에 대한 다음의 상세한 설명으로부터 또한 이해될 것이다.
도 1a는 본 발명의 적어도 하나의 예시적인 실시예에 따른 예시적인 기기-내 (intra-device) 단말 구조상의 네트워크 (Network on Terminal Architecture (NoTA))를 개시한다.
도 1b는 본 발명의 적어도 하나의 예시적인 실시예에 따라 화이트보드-유형 교환 서비스를 포함하는 기기-간 (inter-device) 단말 구조상의 네트워크 (Network on Terminal Architecture (NoTA))의 다양한 예시적인 계층들의 구조적인 도면을 개시한다.
도 2는 본 발명의 적어도 하나의 예시적인 실시예에 따른 기초적인 접속 설립을 위한 예시적인 필요성을 개시한다.
도 3a는 본 발명의 적어도 하나의 예시적인 실시예에 따른 통신 설립의 구조적인 예를 개시한다.
도 3b는 본 발명의 적어도 하나의 예시적인 실시예에 따라, 다른 기기에 있는 타겟 서비스로의 액세스를 설립하는 일 예를 개시한다.
도 4는 본 발명의 적어도 하나의 예시적인 실시예에 따라 정보가 운반될 수 있을 다양한 인터페이스들 및 소프트웨어 레벨들 중의 일 예를 도시한다.
도 5는 본 발명의 적어도 하나의 예시적인 실시예에 따른 하위 레벨 통신 구조를 위한 예시적인 구성을 개시한다.
도 6은 본 발명의 적어도 하나의 예시적인 실시예에 따른 접속 설립의 일 예를 도시한다.
도 7은 본 발명의 적어도 하나의 예시적인 실시예에 따른 버퍼 레벨 조건 팩터들의 일 예를 도시한다.
도 8은 본 발명의 적어도 하나의 예시적인 실시예에 따라, 버퍼 레벨들을 제어하기 위한 하나 이상의 무선 전송들을 활용하는 일 예를 개시한다.
도 9는 본 발명의 적어도 하나의 예시적인 실시예에 따른 다중-전송 통신의 일 예를 개시한다.
도 10a는 본 발명의 적어도 하나의 예시적인 실시예에 따라, 데이터를 포함하는 복수의 버퍼들에 결부된 예시적인 통신 시나리오를 개시한다.
도 10b는 본 발명의 적어도 하나의 예시적인 실시예에 따른 버퍼들 사이에서의 정보 라우팅의 예를 도시한다.
도 10c는 본 발명의 적어도 하나의 예시적인 실시예에 따른 메시지 라우팅 상에서의 선택된 전송에서의 손실의 적어도 하나의 영향을 개시한다.
도 11a는 본 발명의 적어도 하나의 예시적인 실시예에 따른 전송 실패 보호를 포함하는 버퍼들 사이에서의 정보 라우팅의 일 예를 개시한다.
도 11b는 본 발명의 적어도 하나의 예시적인 실시예에 따라, 도 11a에 관하여 설명된 전송 실패 보호의 다른 일 예를 도시한다.
도 11c는 본 발명의 적어도 하나의 예시적인 실시예에 따른 전송 실패 동안에 전송 실패 보호 행동의 일 예를 개시한다.
도 12는 본 발명의 적어도 하나의 예시적인 실시예에 따른 예시적인 정보 핸들링 프로세스의 흐름도를 개시한다.

아래에서 본 발명이 다수의 예시적인 실시예들에서 설명되지만, 첨부된 청구범위에서 설명된 것과 같은, 본 발명의 사상과 범위를 벗어나지 않으면서도 상기 실시예들에서 다양한 변화들이 만들어질 수 있다.

I. 단말 구조상의 네트워크 (Network on Terminal Architecture (NoTA))

단말 구조상의 네트워크 (Network on Terminal Architecture (NoTA))는 유선 및/또는 무선 (예를 들면, 모바일) 기기들을 포함하는 다양한 전자 장치들에서 사용 가능한 서비스 기반의 상호접속-중심 플랫폼이다. NoTA에 병합된 상기 상호접속-중심 해결책은 어떤 물리적인 서브-시스템이 다중의 병렬 접속들을 유지하면서도 다른 서브-시스템과 직접 통신하도록 허용할 수 있을 것이다. 기초가 되는 물리적인 매체에 대해서 최적화된 단순한 스위치들로 인해서 직접 접속들이 가능하다. NoTA 상호접속 구조 및 관련된 인터페이스들은 서비스 및 데이터 통신을 위해서 최적화된 복잡성 및 성능일 수 있을 것이며, 그리고 서로 다른 통신 매체 기술들이 활용될 수 있도록 설계될 수 있을 것이다.

도 1a는 단일 기기 (100)에서 구현된 NoTA의 일 예를 개시한다. 상기 NoTA 플랫폼 구조는, 예를 들면, 참조번호 104에서 보이는 것과 같이 상호접속들을 경유하여 서로 접속된 서브 시스템들 (102)로 구성된다. 도 1a의 참조번호 102'에서와 같이 서브시스템들이 다른 서브시스템들과 직접적으로 접속되는 것 역시 가능하다. 접속된 구성은 서브시스템들이 동작 동안에 빈번하게 협응하는 시나리오들에서 존재할 수 있을 것이다. 도 1a는 서브시스템들 (102, 102')로 매핑될 수 있을 서비스 노드들 (SN) (106) 및 애플리케이션 노드들 (AN) (108) (예를 들면, PN, RN 및 AG)을 또한 개시한다. NoTA 환경에서의 서브시스템들은 대응하는 서브시스템에서 동작하는 서비스들 및/또는 애플리케이션들을 구현하기 위해 필요한 모든 자원들 (예를 들면, 컴퓨팅, 소프트웨어, 주변 기기들 등)을 망라할 수 있을 것이다.

이제 도 1b를 참조하면, 적어도 하나의 실시예에 따라 다중-기기 시스템에 적용될 수 있을 NoTA에 대한 더 상세한 개시가 이제 개시된다. 일반적인 구조가 다음의 3가지 예시적인 동작 레벨들에 관하여 설명될 수 있을 것이다: 화이트보드 (110), 빌보드 (122) 및 접속 지도 (140). 화이트보드 (110)는 이 구조에서 가장 상위의 레벨을 포함할 수 있을 애플리케이션 및 서비스 레벨의 일 예이다. 이 레벨에서, 동작 그룹들 (112)은 화이트보드 (114) 및 다양한 애플리케이션 노드들 (108)을 포함하여 형성될 수 있을 것이다. 애플리케이션 노드들 (108)은 복수의 무선 통신 기기들 상에서 존재하는 애플리케이션에 대응할 수 있을 것이며, 그리고 그런 애플리케이션들 사이에서, 예를 들면, 화이트보드 (114)로 데이터를 위치시키고 그리고 그 화이트보드로부터 정보를 삭제함으로써 정보를 교환하기 위해 활용될 수 있을 것이다. 예를 들면, 상기 다양한 노드들은 정보를 화이트보드 (114)로 위치시킬 수 있을 프로액티브 노드들 (proactive nodes (PN) (116), 화이트보드 (114)로부터 정보를 취할 수 있을 리액티브 노드들 (reactive nodes (RN)) 및 상기 특수 애플리케이션에 따라서 PN 또는 RN 모드 중의 어느 하나로 동작할 수 있을 에이전트 노드를 (agent nodes (AG))로 구성될 수 있을 것이다. 정보 시맨틱 인터프리터 (Information semantics interpreter (ISI)) (118)는 서로 다른 화이트보드들 (114)을 같이 링크시키기 위해서 활용될 수 있을 것이다. 이런 구성들을 활용하여, 화이트보드 (114)는 많은 비호환성들을 극복하게 하는 애플리케이션 인터액션을 위한 표준화된 수단을 제공할 수 있을 것이다.

빌보드 레벨 (124)는 하나 또는 그 이상의 기기들 상에서 이용 가능한 서비스들 사이의 인터액션을 활용할 수 있을 것이다. 서비스들 (134) 및 이런 서비스들을 활용할 수 있을 클라이언트들 (136)은 서비스 도메인 (126)에서 조직될 수 있을 것이다. 적어도 하나의 시나리오에서, 서비스 도메인들 (126)은 UPnP, BT SDP, Bonjour 등과 같은 특수한 프로토콜에 대응할 수 있을 것이다. 가가 서비스 도메인 (126)에서, 서비스들 (134)은 서비스 노드들 (SN) (130)에 의해 표현될 수 있을 것이며, 그리고 마찬가지로, 애플리케이션 노드들 (AN) (132)은 애플리케이션들에 대응하기 위해 설립될 수 있을 것이다. 또한, 서비스 도메인들 (126)은 서비스 형이상학 인터프리터들 (service ontology interpreters (SOI)) (128)을 활용하여 인터액트할 수 있을 것이다. 서비스 도메인 (138)이 (예를 들면, 서비스 도메인들 (126)로의 액세스 정보를 제공하기 위해) 다른 무선으로-링크된 기기 상에 존재하는 경우에도, SOI (128)는 서비스 도메인들 (126)로 하여금 다른 서비스 도메인들 (예를 들면, 참조번호 138)과 인터액트할 것을 허용할 수 있을 것이다.

접속 지도 (144)는 탑 레벨을, 예를 들면 화이트보드 (110) 그리고 빌보드 레벨 (122)에서 빌보드-유형 서비스들을 지원하기 위해 자원들을 공유하는 것에 참여하는 서로 다른 기기들에 대한 접속 방법/가능성 및 위상 (topology)을 정의할 수 있을 것이다. 본 발명의 적어도 하나의 예시적인 실시예들에서, 기기들 (144)은 직접적으로 접속된 그룹들 (142)에서 링크될 수 있을 것이다. 직접적으로 접속된 기기 (Dev)들의 그룹들 (142)은 블루투스 피코넷 (Bluetooth™ piconet), WLAN 네트워크, wUSB 링크 등을 통해서 접속된 기기들을 포함할 수 있을 것이다. 직접적으로 접속된 기기들의 그릅 (142)은 게이트웨이 (GW) (146)에 의해 또한 링크될 수 있을 것이다.

II. 서브시스템들을 연결시킬 수 있을 기초가 되는 통신 엘리먼트들 (Underlying communication elements that may couple subsystems)

애플리케이션 및/또는 서비스 노드들을 포함하는 노드-간 인터액션의 예들이 설명되었지만, 상기 기기들이 유선 또는 무선 통신을 경유하여 어떻게 연결될 수 있는가에 대해서 또는 이 접속의 관리에 대해서는 상세한 설명이 전혀 제공되지 않았다. 도 2는 애플리케이션 및/또는 서비스 노드들이 서로 다른 기기들 (200, 202) 상에 위치할 수 있을 예의 시나리오를 개시한다. 화이트보드 섹션들 (152A 및 152B)은, 상기 노드들이 공통 메모리 공간을 경유하여 인터액트할 수 있을 그런 공통 메모리 공간을 이상적으로 제공하는 이런 기기들 상에 또한 각각 상주한다. 그러나, 화이트보드 (152)의 형상에서 공통의 메모리 공간과의 인터액션은 화이트보드 섹션들 152A 및 152B 사이에서의 무선 접속을 설립하는 것에 초기에 종속될 수 있을 것이다.

두 개의 섹션들 152A 및 152B로 분할된 예시적인 화이트보드 (152)가 본 발명의 개시를 설명하는 것을 위해 활용될 수 있을 것이지만, 노드 인터액션을 용이하게 하는 것은 이 시나리오로 특별하게 한정되지 않는다. 예를 들면, 화이트보드 섹션 152A와 연결된 프로액티브 노드 (PN) (210)가 도 2에서 도시된 것과 같은 화이트보드 섹션 152B와 인터액트하기 위해 SN (212, 214)을 활용할 수 있을 것이지만, 화이트보드 152A는 (예를 들면, 프린터 서비스처럼, 어떤 애플리케이션이 필요한 기기에 액세스하도록 허용하기 위해) PN (210)이 서비스 도메인 (126) 또는 본 발명의 다양한 실시예들에 따라서 상기에서 설명된 것과 같은 어떤 다른 예시적인 서브시스템 (102)과 같은 다른 공유 메모리 공간들에 액세스하는 것을 허용할 수 있을 것이다. 노드/기기 구성에 관계없이, 노드들 간의 인터액션은 국지적으로 상호접속된 서브시스템들의 관점에서 단일 기기 상에서 문제가 될 수 있을 것이다. 그러나, 이런 인터액션은, 예를 들면, 하나 또는 그 이상의 무선 전송들을 통해서 링크된 복수의 기기들과는 더욱 어려워질 수 있을 것이다.

도 3a는 본 발명의 적어도 하나의 예시적인 실시예에 따라, NoTA를 구현하는데 있어서 활용될 수 있을 기초가 되는 논리적인 구조의 일 예를 도시한다. NoTA는 상호접속 (312)에 의해 연결된 복수의 서브시스템들 (예를 들면, 참조번호 300 및 350)로서 구성될 수 있을 것이다. 이전에 제시된 것처럼, 하위의 동작 레벨에 의해 설립될 수 있을 그리고 관리될 수 있을 기기들 사이에서의 통신 링크는, 어떤 통신 구성에서 상위 레벨들을 실제로 결부시키지 않으면서도, 동일 공유 메모리 공간 (화이트보드) (152)의 섹션들 (152A, 152B)과 같은 상위 레벨 서브시스템들에 대한 메시지들의 라우팅을 용이하게 할 수 있을 것이다.

NoTA 상호접속 (312)은 두 개의 계층들을 포함할 수 있을 것이다: 높은 상호 접속 (High Interconnect (H_IN)) 계층 (302) 및 낮은 상호접속 (Low Interconnect (L_IN)) 계층 (304). 이것들은 대응하는 H_IN (352) 및 L_IN (354)에 스위치 (310)에 의해 연결된다. 다양한 통신 계층들은 인터페이스들 (도 3에서 약자 "IF")을 통해서 또한 인터액트할 수 있을 것이다. 예를 들면, H_IF (380)는 애플리케이션 레벨 및 H_IN (302/352) 사이의 인터페이스로서 동작할 수 있을 것이며, L_IF (382)는 H_IN (302/352) 및 L_IN (304/354) 사이에서의 인터페이스로서 동작할 수 있을 것이다. 하위 상호접속 계층 (304)은 ISO/OSI 계층들 Ll - L4을 포함할 수 있을 것이며 그리고 상위로의 전송 소켓 유형 인터페이스를 제공할 수 있을 것이다. 상위의 상호접속 계층 (302)은 L_IN (304) 그리고 참조번호 300 및 350과 유사한 서브시스템들에 존재하는 상위 레벨 애플리케이션 노드들 (AN) (306) 그리고 서비스 노드들 (SN) (308) 사이에서의 미들웨어로서 행동할 수 있을 것이다. 중요한 H_IN (302) 기능은 클라이언트 노드들 (AN (306) 또는 SN (308))에게, (탑 레벨에서 투명한) 후자의 위치를 개시하지 않으면서도, 서비스들로의 직접 액세스를 제공하는 것을 포함할 수 있을 것이다. 모든 통신 설립은 접속-지향 (connection-oriented)일 수 있을 것이며, 이는 어떤 서비스 또는 데이터 통신이 일어나기 이전에 접속 셋업 절차들이 먼저 수행되어야만 한다는 것을 의미한다. 보안 특징들이 대응이 확인된 위협들에 추가된다. NoTA는 기기-간 서비스 액세스를 제공하기 위해 사용될 수 있을 구조이며, 서비스들 및 애플리케이션들 모두를 제공하는 독립적인 서브시스템들을 구축하는 것을 가능하게 한다. 예시적인 일 실시예에서, 서브-시스템 간의 통신에 결부된 여러 개별적인 NoTA 기기들이 존재할 수 있을 것이다.

이전에 설명된 구조를 활용하면서, 본 발명의 예시적인 적어도 하나의 실시예에 따라, 무선 링크를 경유하여 다른 기기 상의 서비스로의 액세스를 설립하는 예는 도 3b에서 개시된다. 기기 (200) 내의 서브시스템의 애플리케이션/서비스 레벨에서의 노드는 서비스에 액세스하기를 원한다. 상기 서비스는, 예를 들면, 서비스 설명 (service description (SID))에 의해 식별될 수 있을 것이다. 이 서비스 설명은 상기 원하는 서비스를 위치시키고 그 서비스로의 액세스를 설립하기 위해서 사용될 수 있을 것이다. 상기 H_IN 레벨에서, 상기 SID는 상기 서비스가 존재하는 서브시스템을 또한 식별할 수 있을 상호접속 어드레스 (Interconnect Address (IA))로 매핑될 수 있을 것이다. 이 예에서, 상기 원하는 서비스는 타겟 기기 (202) 내의 서브시스템 (350) 내에 위치한다. 상기 서브시스템을 갖춘 H_IN 레벨 접속이 이 서비스를 제공하도록 만들기 위해, 상기 기기들 사이에서의 접속을 만들기 위해 적합한 전송 (transport)이 선택되어야만 한다. 그러면 상기 IA는 상기 선택된 전송으로 L_IN (304)에서 매핑될 수 있을 것이다. 도 3b의 예에서, 상기 기기들이 유선 접속에 의해 연결되지 않았기 때문에, 무선 링크가 설립되어야만 한다. 이 무선 링크는 상기 무선 전송을 경유한 접속 (312)을 통해서 설립된다. 일단 기기들 (200, 202)이 무선으로 연결되면, 서브시스템 (300, 350) 사이의 H_IN 레벨 접속이 가능할 수 있을 것이다. H_IN 레벨 (352)에서, 서비스 사용을 협상하기 위해 대응 H_IN 프로토콜이 이용 가능하다. 상기 (SID -> MA) 그리고 (IA -> 전송) 매핑은 상기 필요한 서비스를 제공하는 적절한 서브시스템 (예를 들면, 참조번호 350의 서브시스템)과의 접속을 구축하기 위해 서브시스템 (300)에서만 사용된다. 결과적으로, 상단 (upper) 레벨 (예를 들면, 애플리케이션/서비스 레벨) 액세스는 기기 (200) 내의 요청 노드로부터 이 요청을 충족시킬 수 있는 서비스로 설립될 수 있을 것이며, 이는 상기 서비스가 상기 기기 (202) 내에 존재한다고 해도 그러하다. 이 액세스는 하나 또는 그 이상의 전송들을 경유하여 더 낮은 레벨 링크 설립에 의해 용이하게 될 수 있을 것이다.

III. 예시적인 접속 관리 구조들 (Exemplary connection management structures)

적어도 하나의 실시예에 따른 본 발명은 다양한 구조 컴포넌트들의 기능 및 컴포넌트 관계들의 면에서 설명될 수 있을 것이다. 도 4는 다양한 통신 레벨들의 인터액션 및 본 발명의 적어도 하나의 예시적인 실시예에 따라서 각 레벨 및 대응 인터페이스에 의하여 수행될 수 있을 기능들의 예들을 설명한다. 예를 들면, 참조번호 400은 도 1a에 보이는 것과 참조번호 108과 같은 다양한 애플리케이션 노드들 (AN)을 지지하는 접속들의 셋업 및 설립을 용이하게 할 수 있을 예시적인 서비스 노드 (SN)를 개시한다. 상기 탑 애플리케이션 레벨 및 H_IN 레벨 (404) 사이의 인터페이스는 H_IF 인터페이스 레벨 (402)을 경유하여 서비스 액세스, 등록 및 통신 스트림 액세스를 제공할 수 있을 것이다. 본 발명의 적어도 하나의 예시적인 실시예에 따라, 서비스들은 서비스 신원 (Service Identification (SID))에 의해 식별된다. 그러면 H_IN 레벨 (404)은 기기-기기 액세스 및 L_INup 레벨 (408)로의 통신 인터페이스 액세스를 L_IF 인터페이스 레벨 (406)을 경유하여 획득할 수 있을 것이다. 상기 H_IN 레벨 액세스는 높은 레벨 미들웨어 계층에서 서로 다른 기기들/서브시스템들을 분리하는 상호접속 어드레스 (Interconnect Address (IA))에 의해 식별될 수 있을 것이다. 일반적인 접속 제어 인터페이스 L_IFdown 레벨 (410)은 그러면 전송-독립적인 L_INup 레벨 (408)로부터, 참조번호 414에서 개시된 것과 같이 전송-특정 L_IN 어댑터들을 포함하는 L_INdown (412)로의 액세스를 제공할 수 있을 것이다. 본 발명의 다양한 실시예들에서, 각 통신 매체 (예를 들면, 전송 (418))에 대한 특정 L_IN 어댑터 (414)가 존재할 수 있을 것이며, 상기 통신 매체 각각은 전송-특정 제어 인터페이스 (416)에 의해 링크된다. 그러면, 예를 들면, 모바일 기기에서 지원되는 유선 및/또는 무선 전송들 (418)은 통신하기 위해 기기 물리 (PHY) 계층 (420)에서의 물리적인 하드웨어 및/또는 대응 소프트웨어를 활용할 수 있을 것이다. 전체적으로, 상기 서비스 레벨은 상이한 서비스들을 식별하기 위해 SID를 활용할 수 있을 것이다. 그러면, H_IN 레벨 미들웨어 계층은 이 SID를 어떤 IA로 매핑하며, 상기 IA는 상기 각각의 서비스가 높은 레벨 미들웨어 계층에서 액세스될 수 있는 곳인 기기/서브시스템의 어드레스에 대응한다. 그러면, L_INup 레벨 (408)은 이 IA를, 상기 IA에 대응하는 기기/서브시스템으로의 접속을 제공하는 하나 또는 그 이상의 물리적인 접속들 (예를 들면, 전송들)에 매핑할 수 있을 것이다. 그러면, L_INdown 레벨 (410)은 상기 특정 전송과 물리적인 접속들을 설립할 수 있을 것이다.

도 5는, 본 발명의 적어도 하나의 예시적인 실시예에 따른, 예시적인 낮은 상호접속 구조 (L_IN) (304)를 도시한다. L_IN (304)은 L_IF 인터페이스 (382)를 경유하여 H_IN (302)로 서비스를 제공할 수 있을 것이며, 그리고 통합된 L_INup 통신 구조 (408) 및 하나 또는 그 이상의 L_INdown 통신 구조 (412)를 포함할 수 있을 것이다. L_INdown (412)은 기기 내에서 활용될 수 있을 전송 (418) 각각에 대응하는 적어도 하나의 L_INdown 어댑터 (414)를 또한 포함할 수 있을 것이다. 결과적으로, L_INup (408)은 전송-독립적일 것이며 (예를 들면, L_INup 동작은 사용 중인 상기 전송에 의존하여 변하지 않는다), 반면에 L_INdown (412) 내의 L_INdown 어댑터 (414)는 각 전송 (418)과 함께 사용되기 위해 특별하게 구성될 수 있을 것이다. 각 L_INdown 어댑터 (414)는 하나 또는 그 이상의 L_IFdown 인터페이스 (410)를 통해서 L_INup (408)로 서비스를 제공할 수 있을 것이다. L_IFdown 인터페이스들 (410)은 주소 지정 및 액세스 매커니즘을 제외하면 각 전송 (418)에 대해 유사하게 구성될 수 있을 것이다.

L_INup (408)은 본 발명의 실시예들에서 복수의 기능들을 수행할 수 있을 것이다. 예를 들면, 활성화 및 비활성화는 상기 통신 구조의 이 계층에서 제어될 수 있을 것이다. 상기 L_IN 활성화 프로세스는 상기 L_IF (382)를 통해서 제어된다. 상기 활성화 프로세스 동안에, 상기 L_IN (304)는 무선 및/또는 유선 전송들을 L_IN 전송들로서 이용할 수 있도록 구성될 수 있을 것이다. 성공적인 활성화의 결과, L_IN (304)는 현존하는 자원 관리자들 (Resource Managers (IArm))을 위한 상호접속 어드레스 (IA)들은 물론이고 하나의 상호접속 어드레스를 결정하는 것이 가능할 수 있을 것이다. L_INup (408)는 이 활성화 동안에 L_INdown (412)로 제공된 질의 서비스들을 이용할 수 있을 것이다.

액티브일 때에, L_IN (304)는 L_IN 네트워크 접속의 손실을 탐지하는 것이 가능할 수 있을 것이다. 결과적으로, 어떤 이전에 할당된 IA 및 IArms 는, 예를 들면, 동일한 또는 상이한 전송을 이용하여 상기 네트워크 접속에 자동적으로 다시 접속하기 위해 릴리즈 (release)될 수 있을 것이다. 상기 비활성화 프로세스 역시 L_IF (382)를 통해서 제어된다. 상기 비활성화 프로세스에서, L_IN (304)는 모든 이용 가능한 전송들에 관해서 비활성화된다. 이 프로세스 동안에, 상기 IA는 릴리즈된다.

상기 L_IN 접속 생성 프로세스는 도 6에서 보이는 것과 같은 상이한 기기들 사이에서의 L_IN-레벨 접속을 설립할 수 있을 것이다. 이 접속은 종단 포인트들 사이에서의 상이한 유형들의 전송 기술들을 활용할 수 있을 것이다. 일반적으로, 상기 노드들이 인터액트하는 인터페이스들이 전송-독립적일 수 있을 것이기 때문에, 전송을 선택하는 것은 애플리케이션 레벨에서 투명할 수 있을 것이다. 그러나, (예를 들면, 상기 NoTA 구조에서 AN (306) 및 SN (308)에 의해 표현되는) 애플리케이션들과 서비스들은 L_IN 계층 (304)이 제공할 수 있을 접속에 관한 요구 사항 (requirement)들 또는 필요한 특성들을 가질 수 있을 경우들이 존재할 수 있을 것이다. 그러므로, L_IF 인터페이스 (382)는 각 접속을 모니터링하기 위한 서비스 품질 (quality of service (QoS)) 파라미터 셋업을 가능하게 하기 위한 매커니즘을 갖출 수 있을 것이다. 이 레벨에서, 데이터를 운반하기 위해 사용되는 전송 기술은 이런 레벨에서는 선택되지 않을 것이기 때문에, 서비스 파라미터들의 품질은 실제의 전송으로 제한되지 않을 수 있을 것이다. 오히려, 상기 QoS 요구 사항들은, 상위 프로토콜들이 사용할 수 있을 실제의 접속의 추출들인, L_IN 통신 인스턴스 생성 (instantiation) 또는 "소켓 (socket)"으로 매핑될 수 있을 것이다. 상기 접속 요구 사항들은, 예를 들면, 버퍼 상태 기반의 전송 선택 및 플로우 (flow) 제어를 이용하여 달성될 수 있을 것이다. 상기 인터페이스는 전송-특정 파라미터들을 주소 지정할 필요는 없다. 대신 상기 요구 사항들 또는 희망들은 더 범용의 방석으로 설명될 수 있을 것이다.

L_IN이 자신의 기능을 수행하도록 하기 위해, 기본적인 L_INup - L_INup 접속 프로토콜들이 정의될 수 있을 것이다. 이것들 모두는 L_INup 통신 구조 (408)에 의해 활용될 수 있을 것이며, 그래서 상기 L_INdown 어댑터 (412)를 구현하는 것을 단순하게 만든다 (이는, 예를 들면, 어떤 일반적인 L_INdown - L_INdown 피어 프로토콜들로 필요로 하지 않기 때문이다). 다음의 L_INup 프로토콜들은 두 개의 개별 기기들 (예를 들면, 도 6에서 보이는 것과 같은 기기들 (200, 202))에서 존재하는 L_IN 통신 구조들 사이에서의 통신을 용이하게 하기 위해 정의될 수 있을 것이다.

각 기기에 대해 유일한 접속 주소들을 할당하고 그리고 식별하는 수단을 제공할 수 있을 프로토콜은 본 발명의 적어도 하나의 예시적인 실시예에 따르는 상호 접속 주소 결정 프로토콜 (Interconnect Address Resolution Protocol (IARP))로 불릴 수 있을 것이다.

소켓들 사이에서 데이터 접속 설립 및 분리를 설립하기 위한 수단을 제공하는 프로토콜은 본 발명의 적어도 하나의 예시적인 실시예에 따른 기기 액세스 프로토콜 (Device Access Protocol (DAP))로 불릴 수 있을 것이다.

기기들 사이에서 접속 지도 (connectivity map)-유형 정보를 교환하기 위한 수단을 제공하는 프로토콜이 존재할 수 있을 것이다. (예를 들면, 상기 기기 환경에서의 접속에 관한) 이 정보는 상기 기기들을 통해서 정보를 배포할 때에 최적의 접속 방법을 선택하기 위해 또한 활용될 수 있을 것이다. 이 프로토콜은 본 발명의 예시적인 일 실시예에 따르는 접속 환경 프로토콜 (Connectivity Environment Protocol (CEP))로 불릴 수 있을 것이다.

IARP는 애드-혹 (ad-hoc) 통신 접속 등에서 기기들의 네트워크 내에서 기기-사이의 NoTA 구조 상호 접속 어드레스 (Interconnect Address (IA)) 결정을 제공하도록 규정될 수 있을 것이다. IARP는 유일한 IA를 검색하고 릴리즈하기 위해 4개의 메시지들을 포함할 수 있을 것이다. 도 6의 예에서, 접속이 설립될 때에, 상기 IA 결정 프로세스는 기기들 사이에서의 IA 어드레스 할당을 처리할 수 있을 것이다. 어드레스 결정은 IARP를 접속 설립을 지원하기 위한 하나의 자원으로서 활용할 수 있을 것이다. 어드레스 결정은 수동의 설정을 전혀 필요로 하지 않으면서 분산되고/자율적일 수 있을 것이며 또는 중앙화될 수 있을 것이다. 데이터 배송 프로세스는 송신 기기 및 수신 기기 사이에서의 데이터 흐름 제어를 관리할 수 있을 것이다. L_IF 링-버퍼 기반의 소켓들은 이 프로세스에서 사용될 수 있을 것이다. 데이터 배송 프로세스는 전송-간의 스위칭을 이용하여 더 신뢰성있는 데이터 배송을 제공하기 위해 접속 손실 검출 및 회복 프로세스를 또한 구현할 수 있을 것이다.

DAP는 접속 초기화, 생성 및 분리를 제공할 수 있을 것이다. L_IN 계층 내부 인터페이스 L_IFdown (410)는 DAP가 개별 전송에 액세스하기 위한 균일한 방식을 제공할 수 있을 것이다. 각 전송은 L_IFdown 인터페이스 (410)를 구현하는 어댑터 (412)를 필요로 한다. 도 6은 상기 구조가 어떻게 전송-독립적인 기기-내부 도메인 (예를 들면, L_INup (408))으로부터 전송-독립적인 기기-간의 도메인 (예를 들면, L_INdown (412))으로 크기가 변하는지를 보여준다. 예를 들면, 상기 도시된 통신 계층들은, H_IN (302) 그리고 L_INdown (412)을 전송-독립적인 L_INup 통신 구조 (408)를 경유하여 직접 연결시킬 수 있을, 연결된 데이터 소켓들 (600)일 수 있을 것이다.

전송-간의 (inter-transport) 스위치 트리거링 결정들은 상기 송신 (TX) 및 수신 (RX) 버퍼 채움 레벨들을 모니터링하여 얻어진 상태 정보를 고려하여 제어될 수 있을 것이다. 모든 데이터 운반은 "최고 노력 Best Effort" (BE) 유형으로 간주될 수 있을 것이다. 그러면, NoTA의 전반적인 구현의 복잡도를 관리 가능하게 여전히 유지하면서도, 일부 간단한 QoS 클래스들 (예를 들면, BE, 낮은-지연 배송, 최소화 된 전력 소모 등)을 도입하는 것이 가능할 수 있을 것이다. 상기 접속 손실 및 회복 프로세스는, 상기 전송 레벨에서 동작하는 자원들의 원래의 능력들의 일부로서 처리될 수도 있을 복원 절차 및 재접속 절차를 위해서 활용될 수 있었을, L_IN 통신 구조 (304)에서의 보충적인 행동이다.

상기 접속 셋업, 데이터 배송 및 접속 회복 솔루션들의 일부는 주변 환경에서의 접속에 관한 공유의 배포 정보를 상기 CEP 프로토콜에 의해 포함할 수 있을 것이다. 이 방법은 다른 주변의 기기들이 사용하는 이용 가능한 접속 기술들에 관한 정보를 검색할 수 있을 것이며 그리고 액세스 기기들 및 서비스들로의 최적의 전송을 선택할 때에 스마트한 결정을 하는 절차들을 가능하게 한다. 도 6에서, L_INup - to - L_INup 프로토콜 통신을 가능하게 하기 위한 제어 소켓들 (602)이 기기-간의 통신을 촉진시키는 IARP, DAP 및 CEP 프로토콜들과 인터액트하는 것이 보인다.

상기 L_INdown 통신 구조 (412)는 다른 통신-관련된 기능성을 제공할 수 있을 것이다. 예를 들면, 질의 동작은 전송-특정 접속 기회들에 관련된 정보를 제공할 의도인 L_INdown 내부 기능일 수 있을 것이다. 이 기능성은 전반적인 공간/근접/이웃 접속에 관한 정보가 획득될 수 있는 접속 지도들 및 장면 (scene)과 강하게 연결될 수 있을 것이다. 상기 질의 기능은 접속을 설립하는 동안에 주로 채택된다.

데이터 배송 프로세스는 동일한 전송 피어 엔티티들 사이에서의 (예를 들면, 도 6에 보이는 것과 같은 L_INup 통신 구조들 사이에서의) 데이터 흐름 제어를 다룰 수 있을 것이다. 동일한 링 버퍼들이 L_IF에 관해서 이전에 설명된 경우에서와 같이 사용될 수 있을 것이다. 전송-특정 접속 손실 및 회복 프로세스는 L_INdown (412)에서 또한 구현될 수 있을 것이다. 상기 구현은 적용된 전송 기술에 실질적으로 의존할 수 있을 것이다.

IV. 통신 관리 (Communication management)

도 7은 예시적인 일 실시예에 따른 본 발명의 예시적인 구현을 개시하며, 이 경우 서비스들 (예를 들면, SN (700)에 의해 표현된 서비스들)은 일반적인 송신 버퍼 (702)로 데이터를 산출할 수 있을 것이다. 참조번호 200의 기기로부터 참조번호 202의 기기로의 단-방향 무선 송신이 설명을 위해서 도 7에서 개시되었지만, 본 발명은 이런 특정한 예로 제한되지 않으며, 그리고 유선 또는 무선 통신을 경유하여 양-방향 통신을 관리하기 위해 구현될 수 있을 것이다. 또한, 도 7이 상호접속 구조 (312) 위에 위치한 일반 버퍼들 (702) 그리고 L_IN 레벨 (304) 내에 위치한 전송-특정 버퍼들 (704)의 일 예를 개시하지만, 다른 가능한 구성들은, 예를 들면, L_IN 레벨 (304)에 또한 상주하는 일반 버퍼 (702)를 포함할 수 있을 것이다. 하드웨어 및/또는 소프트웨어로 구현된 다양한 제어 엘리먼트들 (도시되지 않음)은 참조번호 706, 708, 712 및 714에서 그래픽으로 도시된 것과 같이 버퍼 상태를 모니터링할 수 있을 것이다. 더 나아가, 본 발명이 고정된 버퍼 크기로 설명될 것이지만, 본 발명의 다양한 실시예들은 고려될 수 있을 동적인 버퍼 할당을 또한 병합할 수 있을 것이다.

이런 제어 엘리먼트들은, 예를 들면, 구현하기에 적절한 하나 또는 그 이상의 무선 전송들을 버퍼 레벨을 포함하는 다양한 팩터들에 따라서 식별할 수 있을 것이다. 도 7에 도시된 예시적인 시나리오에서, SN은 참조번호 706에서 보이는 것과 같은 레벨에서 동작하고 있는 일반 버퍼 (706)로 정보를 산출한다. 그러나, 무선 전송 (750)의 속도의 한계로 인해서, 상기 전송 특정 버퍼 (704)는 풀 (full)에 접근하고 있다. 이는 버퍼들 (712, 714)을 정보에 굶주리게 하여 그 버퍼들에 또한 영향을 끼칠 수 있을 것이다. 결과적으로, 전력, 프로세싱 용량 등과 같은 자원들은, 예를 들면, 통신이 초기에 설립되었을 때에 활용되었던 동일한 전송일 수 있을 상기 무선 전송에 의해 부과된 한계들로 인해서 비효율적으로 활용될 수 있을 것이다.

그러나, 본 발명의 예시적인 적어도 하나의 실시예에 따라, 하나 또는 그 이상의 무선 전송들을 협력하여 동작시키는 것은 그런 문제의 시나리오를 해결하는데 도움이 될 수 있을 예시적인 구현이 도 8에서 개시된다. 예를 들면, 서비스 검색 및 초기화 동안에, 낮은 전력의 낮은 속도 무선 전송 (750)이 활용될 수 있을 것이다. 참조번호 700의 서비스가 인에이블될 때에, 높은 속도의 서비스 데이터는 전송 (750)을 통해서 효율적으로 배송될 수 없기 때문에, 일반 버퍼 (706)는 가득 채우기 시작할 수 있을 것이다. 그러나, 적어도 하나의 실시예에 따라, 다양한 제어 엘리먼트들은 참조번호 800의 전송으로의 스위치를 협상하기 위해 참조번호 750의 전송을 활용할 수 있을 것이다. 예를 들면, L_INup (408)은 빠른 속도 전송 (800)이 사용될 수 있으며 그리고 빠른 속도 전송 (800)으로의 스위치를 용이하게 할 수 있을 것이라고 (예를 들면, 이전에 언급된 접속 지도 (140)를 통해서) 결정할 수 있을 것이다. 상기 활성 전송을 베어러 (800)로 스위칭한 후에, 상기 접속 속도는 훨씬 더 빠를 수 있을 것이며, 그러므로, 다양한 버퍼들의 오버플로우가 방지될 수 있을 것이다. 동일한 전략이 수신 기기(들) 특성들을 기반으로 하여 또한 구현될 수 있을 것이며, 이는 빈번하게 비워진 버퍼들 (712, 714)은 수신된 데이터의 양이 데이터 이용자 (예를 들면, 이 예에서는 참조번호 202의 기기)의 관점에서는 너무 낮다는 것을 나타낼 수 있을 것이다. 이 특성은, 예를 들면, 현재 사용되는 특별한 전송에 종속적인 상이한 상황들을 가리킬 수 있을 것이다. 낮은 속도의 전송이 채택된 경우의 시나리오에서, 상기 전송의 한계 속도는 데이터를 운반하는데 있어서 병목을 생성할 수 있을 것이다. 그런 상황에서, 더 나은 데이터-처리 용량을 구비한 더 빠른 전송을 채택하는 것이 유리할 수 있을 것이다. 그러나, 수신하는 측의 버퍼들의 거의 비어있다는 결정이 내려질 때에, 빠른 속도 및/또는 용량 전송이 이미 사용되었으면, 송신되고 있는 데이터의 양이 상기 전송을 통해서 들어오는 데이터의 안정된 스트림을 생성하기에는 너무 작다는 것이 문제일 수 있을 것이다. 이런 경우에, 전력을 유지하면서도 데이터를 운반하기 위해, 더 낮은 전력 및/또는 용량의 전송이 선택될 수 있을 것이다.

상기 스위치를 수행하기 위한 결정은 여러 가지 팩터들을 기반으로 하여 구헌될 수 있을 것이며 그리고 활용되고 있는 본 발명의 특별한 구성을 고려하여 구현될 수 있을 것이다. 예를 들면, 비어있는 (또는 풀 (full)인) 얼마간의 버퍼들 및/또는 시간 구간 당, (예를 들면, 버퍼를 채우는 레벨을 모니터링한 것을 기반으로 하여 결정된) 필요한 추정 비트-레이트 (예를 들면, 버퍼를 채우는 레벨을 모니터링한 것을 기반으로 하여 결정된) 등. 추가로, 하나의 전송으로부터 다른 전송으로 스위치하는 것을 수행하기 위한 요청은 어느 하나의 말단 (TX 또는 RX)에 의해 트리거될 수 있을 것이다. 푸시 (push) 유형의 구성의 경우에 (예를 들면, 참조번호 200의 기기들로부터의 스트림은 참조번호 202의 기기 내 저장부로 푸시된다), 상기 TX 측이 스위치를 더 개시할 것 같다. 풀 (pull) 시스템들에서 (예를 들면, 참조번호 200의 기기들로부터 참조번호 202의 기기로 데이터가 풀되고 있다), 상기 RX 측이 스위치를 개시할 수 있을 것이다. 어느 하나의 경우에, 하나 또는 그 이상의 전송들을 구현하는 것은 도 8에서 참조번호 706, 708, 712 및 714에서 보이는 것과 같은 버퍼 레벨을 균형잡는 것으로 귀결될 수 있을 것이며, 그리고 결과적으로, 기기 자원들의 최적화로 귀결될 수 있을 것이다.

다른 예시적인 이용은 전송 (800)을 활용하는 동안에 통신이 급격하게 손실되고 그래서 몇몇의 "대체 (fallback)" 절차가 필요한 경우를 포함할 수 있을 것이다. 이 절차는 링크 (800)의 셋업 단계 동안에 협상될 수 있을 것이다. 이 절차에서, 참조번호 800의 링크가 손실되면 (특정 팩터들에 따라서) 참조번호 750의 링크가 사용될 수 있을 것이라는 것이 확인될 수 있을 것이다. 그러나, 예를 들면, 전송이 오류의 패킷을 배송하는 경우에, 전송 프로토콜들은 패킷 재송신을 제어하지 않을 수 있을 것이다. 적어도 하나의 경우에, 베어러 (bearer)가 한 기기로부터 다른 기기로 성공적으로 데이터 패킷을 운반하고 있을 수 있지만, 베어러 오류-검사 메커니즘이 알아채지 못한 패킷 내 오류가 존재할 수 있다. 동일한 이유로, 전송 (800)을 위해 이미 큐 (queue) 안에 있는 패킷은, 데이터가 여전히 TX 버퍼 (704) 내에 있다고 하더라도, 링크가 손실되면 손실된다. 이런 상황에서, 상기 데이터는 버퍼 (704)로부터 복원되어 그리고 참조번호 705의 전송을 이용하여 다시 송신되는 것이 바람직할 것이다.

전력 소모의 관점에서, 짧은 시간 동안에 많은 양의 비트들을 이동시키기 위해 높은 비트 레이트의 접속을 활용하는 것이 유익할 수 있을 것이다. 이는 TX 버퍼 (704)가 의도적으로 채워지며 그리고 (예를 들면, 공급자 애플리케이션이 상기 증가된 속도를 지원할 수 있는가의 여부에 종속하는) 높은 레이트의 통신 링크를 이용하여 비워진다는 것을 의미한다. 그러나, 참조번호 800의 전송은, 적어도 하나의 경우에, 동작상의 효율을 증가시키는 슬립 모드를 지원하지 않을 수 있을 것이라는 것을 생각할 수 있으며, 이는 TX 버퍼 (704)가 다시 채워질 때까지 대기 시간 동안에 실질적인 전력이 소모될 것이라는 것을 의미할 수 있을 것이다. 이런 종류의 예시적인 상황에서, 낮은 속도의 무선 슬립 모드가 활용될 수 있을 것이며, 이는 참조번호 750의 전송이 TX 버퍼 (704)가 채워지고 있는 시간 동안에는 활성이라는 것을 의미할 수 있을 것이다. 이런 활동성은 이전에 제시된 것과 같이 참조번호 200의 기기 내의 다양한 하드웨어 엘리먼트들 및/또는 소프트웨어 엘리먼트들에 의해 제어될 수 있을 것이다.

전송 제어는 수신 측 흐름 팩터들의 관점에서 또한 구현될 수 있을 것이다. TX 버퍼 (704)에 대응하는 전송-특정 RX 버퍼는 채워질 수 있을 것이며, 수신기-측 데이터 흐름 제어 문제들로 귀결된다. 그런 상황에서, 상기 TX 측은 자신의 송신을 중단할 수 있을 것이다. 상기 링크가 높은 비트 레이트 링크이면 (예를 들면, 참조번호 800의 전송), 더 늦은 전송 (750)은 "GO" 신호가 다시 발행될 때까지 활성화 되어야만 한다고 협상하는 것이 유익할 수 있을 것이다. 접속 제어 엘리먼트들이 무선 동작을 모니터하는 것이 또한 가능하다. 어느 한쪽(TX 또는 RX)은 낮은 전력 전송 모드를 트리거할 수 있을 것이다. 그러나, 상기 RX 측이 흐름 제어를 발행했고, 그래서, 들어오고 있는 (incoming) 데이터를 상기 TX 측처럼 빠르게 처리할 수 없기 때문에, 높은 비트 레이트 링크의 TX 버퍼의 채워진 상태에도 불구하고, 그 높은 비트 레이트 링크를 사용하려고 시도하는 것이 아무 소용도 없다는 것을 상기 TX 측 제어는 이제 이해할 수 있을 것이다.

V. 프로액티브 제어 (Proactive control)

상기에서 설명된 리액티브 제어 방법론에 추가하여, 프로액티브 제어 역시 본 발명의 적어도 하나의 실시예에 따라서 구현될 수 있을 것이다. 도 9는 기기 1 내지 기기 4를 개시한다. 이 예에서, 기기 1은 개인용 발신기, 개인용 디지털 보조기 (PDA), 무선 테블릿 기기 등과 같이 다양한 무선 전송들을 지원할 수 있는 제어 기기일 수 있을 것이다. 기기 2는 블루투스 (Bluetooth™ (BT)) 및 극저전력 블루투스 (Ultra Low Power Bluetooth™ (ULP-BT))를 이용하여 통신할 수 있는 저전력 온도 센서일 수 있을 것이다. 기기 3은 BT 및 초광대역 (Ultra Wide Band (UWB))을 경유하여 통신할 수 있는 디스플레이 (예를 들면, LCD 디스플레이)일 수 있을 것이다. 기기 4는 ULP-BT, WLAN 및 UWB를 경유하여 통신할 수 있는 파일 서버 (예를 들면, 비디오 서버)일 수 있을 것이다.

처음에, 기기 1과 저전력 매체를 이용하는 다른 기기들 사이에서 접속이 설립될 수 있을 것이다. 이는 도 9에서 ULP-BT 링크 및 BT 링크를 이용하여 보여진다. 이 초기 링크는, 예를 들면, 다른 기기들에 관한 정보 (예를 들면, 지원되는 매체들, 이용 가능한 애플리케이션들 등)를 획득하기 위해 설립될 수 있을 것이다. 그렇지 않으면, 기기 1은 (예를 들면, 이전의 접속들로부터) 다른 기기들의 능력들을 이미 알고 있을 수 있을 것이다. 기기 2의 경우에, 작은 양의 데이터만이 교환되고 있다. 그러므로, 기기 1 그리고 기기 2는 전력을 보존하기 위해 ULP-BT를 활용하는 것을 계속할 수 있을 것이다. 반면에, 기기 1과 기기 4 사이에서의 가능한 접속 기술들은 ULP-BT, WLAN 및 UWB를 포함한다. ULP-BT는 비디오 스트리밍용으로는 너무 느리다고 할 수 있는 저전력/속도 전송이며, 그래서 최선의 전송은 WLAN 또는 UWB 중의 어느 하나일 것이다. UWB는 비디오 스트리밍을 위해서 필요한 것보더 훨씬 더 빠른 데이터 레이트를 제공할 수 있으며, 그래서, UWB는 상기 비디오 스트리밍 동안에 아이들 (idle) 모드 (예를 들면, 어떤 송신이나 수신도 없음)에서 많은 시간을 낭비할 것이다. 비활성 구간들 동안의 UWB 전력 소모는 ULP-BT와 비교하면 아주 더 많으며, 그 결과 전력을 낭비한다. 그러면 최적의 해결책은 UWB를 스트리밍 비디오의 송신 및 수신에만 사용하고, 그리고 UWB 활성 상태 및 관련된 웨이크-업 싸이클 제어를 다루기 위해서는 ULP-BT를 사용하는 것이다.

본 발명의 다양한 실시예들에 따라서 이용 가능한 두 가지의 가능한 제어 구현들의 존재한다. 첫 번째 예시의 구현은 비디오 스트리밍의 시작 부분에서 이미 듀티 싸이클을 협상할 수 있을 것이다. 그러면, ULP-BT의 역할은 도 9에 보이는 것과 같은 비디오 스트리밍 링크를 셋업하고, 그리고 (예를 들면, 그래서 정확한 순간에 깨울 수 있도록 UWB 무선으로) 타이밍 레퍼런스를 제공하는 것일 수 있다. 이런 종류의 시나리오는 활성 단계와 비활성 단계 사이의 타이밍이 고정될 수 있는 상황에서 사용될 수 있을 것이다. 이런 예시의 시나리오에 따른 동작은 일부 상황들에서는 도전적일 수 있을 것이다. 예를 들면, 접속 패턴들이 상기 서비스의 시작 부분에서 고정되면, 그 접속 동안에 파라미터들 중의 어느 것이 변경되면 상기 접속 패턴들을 변경하거나 수정하는 것은 힘들 수 있을 것이다. 서비스의 데이터 레이트가 (예를 들면, 데이터의 짧은 버스트들을 포함하는 산발적인 것을 포함하여)버스트 (burst)한 상황에서 특히 도전적이다. 그런 시나리오의 좋은 하나의 예는 비디오 스트리밍이다 (예를 들면, 처리량이 저하되면 부드러운 비디오 스트리밍 품질을 유지하기 위해 활성 구간이 증가하도록 한다). 그러므로, 그런 유형들의 상황들에 대해 더 나은 타이밍 제어를 제공하는 가능한 다른 동작 모드를 가지는 것이 좋을 것이다.

두 번째의 예시적인 구현에 따라, 도 9에서 보이는 것과 같이, 상기 시스템은 WAN 재활성화를 비동기식으로 제어하기 위해 ULP-BT를 활용함으로써 동작할 수 있을 것이다. 이 예에서, ULP-BT 그리고 WLAN 둘 다가 활성화된다. 상기 ULP-BT 무선은 상기 WLAN 비활성 구간들 동안에 사용될 수 있을 것이며, 그리고 높은 비트 레이트가 필요하면 (예를 들면, 애플리케이션 데이터가 생성되면) ULP-BT는 WLAN 무선을 트리거하여 깨울 수 있을 것이다. 일단 상기 ULP-BT 무선 링크를 통해서 활성화되면, WLAN 무선들은, 예를 들면, RTS/CTS (Request-to-Send / Clear-to-Send) 메커니즘을 활용하여 물리적인 채널에서 통신할 수 있을 것이다. 이런 유형의 전략은 비동기식 TX/RX 행동을 관리하기 위해 사용될 수 있을 것이다. 다른 예에서는 UWB가 사용되지만 그러나 UWB 무선은 동면 모드로 진입하는 경우의 시나리오를 포함할 수 있을 것이다. 활성의 낮은 전력 ULP-BT 링크를 통해서 시그날링될 때에, 상기 UWB 무선들은 활성 모드로 복귀할 수 있을 것이며 그리고 다른 무선으로 연결된 기기들로부터 상기 ULP-BT 링크를 통해서 제공될 수 있는 정보에 따라서 충분한 방송 (air) 시간을 확보할 수 있다. 이 정보 교환은 UWB 접속 셋업 및/또는 재설립에 필요한 시간을 줄일 수 있을 것이다. 비디오 스트리밍 시나리오에서, 동작은 다음과 같을 수 있을 것이다: 상기 스트림 콘텐트의 첫 번째 비디오 패킷은 상기 UWB 링크를 통해서 상기 비디오 서버로부터 기기 1로 전송된다. 일단 패킷이 수신되면, UWB 무선은 아이들 모드로 진입할 수 있을 것이다. 그러면, 상기 수신 기기가 상기 스트림의 이전 비디오 패킷이 그 마지막으로 다가서고 있다는 것을 알아차릴 때에, 상기 비디오 스트림을 수신하는 기기의 상기 ULP-BT 무선은 상기 스트림의 다음 비디오 패킷의 UWB 링크를 통한 전송을 착수하기 위해 사용될 수 있을 것이다. 이 동작은 더 많은 전력 사용 UWB 무선들이 대부분의 시간을 아이들 모드에 남아있도록 하는 것을 가능하게 할 수 있을 것이며, 결과적으로, 무선 연결된 기기들에서의 전력 보존을 아주 크게 향상시킬 수 있을 것이다.

예를 들면, ULP-BT를 통해서 WLAN 또는 WUB 무선을 제어하는 것은 다음과 같이 조정될 수 있을 것이다: ULP-BT 접속이 생성되었을 때에, 하나의 논리 링크가 접속 제어 채널로서 예약될 수 있을 것이다. 이 채널은 기기들 사이의 접속에 관한 정보를 운반할 수 있을 것이다. 이 채널에서, 예를 들면, 접속 지도 정보가 교환될 수 있을 것이다. 추가로, 이 채널은 제어 목적으로 타이밍 정보 (예를 들면, 전송 깨움 (transport awakening) 및 기기들 사이에서의 동기화 레퍼런스 포인트 배송)를 제공하는 것을 가능하게 할 수 있을 것이다. 이런 접속 정보는 어떤 이용 가능한 전송을 사용하여 교환될 수 있을 것이며, 그리고 더 나은 초기 전송 선택, 더 빠른 서비스 발견, 최적의 전송 매체 선택, 전송 핸드오버 등을 제공하기 위해 많은 상이한 애플리케이션들과 함께 사용될 수 있을 것이다. 접속 지도 (140)는 링크 셋업, 링크 유지 및 데이터 배송 동안에 이용 가능한 복수의 베러어들로부터 활성 베어러를 선택할 때에 또한 유익할 수 있을 것이다. 예를 들면, 도 9에서의 일부 포인트에서, 기기 1의 사용자는 영화를 보기를 원해서 기기 4 및 ULP-BT를 이용하는 스트리밍 서비스를 발견할 수 있을 것이다. 상기 두 기기들은 비디오 스트리밍용의 공중망 (air) 인터페이스를 제공하기 위한 대역폭 성능 요구 사항 때문에 UWB가 사용될 것이라는 것을 협상할 수 있을 것이다. 데이터 배송 동안에, 상기 UWB 무선은 데이터를 수신하기 위해 기기 1에서 활성화될 수 있을 것이지만, 상기에서 설명된 것과 같이, 비활성화 구간 동안에 (예를 들면, 어떤 데이터도 배송되지 않을 때), ULP-BP는 상기 링크가 활동하도록 유지하기 위해 "졸음 (doze)"에서 이용될 수 있을 것이다. 데이터 배송 동안에 더 높은 데이터 레이크가 일단 다시 필요하게 되면, 그러면 상기 UWB 무선은 다시 활성화될 수 있을 것이다. 기기 1이 어떤 포인트에서 UWB 무선 범위 밖으로 이동하게 될 때에, 기기 1이 대안의 높은 레이트 전송을 사용하도록 결정할 수 없다면 상기 비디오 스트리밍 서비스는 이용 가능하지 않게 될 것이다. 이 예의 경우에, 기기 1 및 기기 4 둘 다 WLAN을 지원하며, 이는 UWB 대신에 사용될 수 있을 것이다. 결과적으로, 상기 기기들에서의 제어 엘리먼트들은 백업 전송을 협상할 수 있을 것이며 그리고 이전에서와 같이 필요한 경우에는 계속할 수 있을 것이다.

특히 도 9에서 보이는 예시의 시나리오에서, 이런 절차의 다른 이점은 그 무선 활성 정보가 기기들에서 다중무선 제어를 최적으로 수행하기 위해 사용될 수 있을 것이라는 점이다. 본 발명의 다양한 실시예들에서 다른 기기의 활성 정보가 공유될 수 있을 것이지만, 초기의 다중무선 제어는 기기 내부의 파라미터들에 의존했다. 이 정보는, 상기 기기들의 전체적인 접속 상황을 고려하여, 사용되는 활성 기술들의 협상 그리고 그 기술들의 타이밍 동기화를 포함할 수 있을 것이다. 이는 두 기기들 모두에서의 최대로 최적화된 전반적인 서비스 품질 그리고 전력 소비를 가능하게 할 수 있을 것이다.

VI. 예시적인 전송 스위칭 (Exemplary transport switching)

도 10a는 본 발명의 적어도 하나의 예시적인 실시예에 따른 예시적인 통신 구성을 개시한다. 추가적인 상세한 내용이 일반 버퍼 (702)에 주어지며, 이 버퍼는 전송-독립적인 (예를 들면, 사용 중인 특별한 전송에 의해 동작이 영향을 받지 않는다) 그리고 전송-특정 버퍼 (704)일 수 있다. 상기에서 제시된 것과 같이, 설명을 위해서, 참조번호 200의 기기로부터 참조번호 202의 기기로의 단-방향 무선 전송이 도 10a에서 개시되었지만, 본 발명은 그런 특정한 예로 제한되는 것이 아니며, 그리고 유선 또는 무선 통신을 경유하는 양-방향 통신을 관리하도록 구현될 수 있을 것이다.

도 10a의 예에서, 일반 버퍼 (702)는 송신을 위한 정보를 포함할 수 있을 것이다. 예시적인 데이터 유닛들 A, B, C.. 은 도 10a에서 개시되며, 이 경우에 이 유닛들은, 예를 들면, 다른 기기 (예를 들면, 참조번호 202의 기기)상의 서브시스템에서의 다른 노드로의 송신용 데이터 패킷들일 수 있다. 도 10a에서 송신용의 모든 정보는 일반 버퍼 (702)에 현재 존재한다. 그러나, 예시의 데이터 운송 그리고 전송 실패 또는 스위칭로 인한 영향, 예를 들면, 접속 파라미터들에서의 변경이 이 데이터 운송에 가져올 수 있을 영향이 도 10a 내지 도 10c에 관하여 이제 설명될 것이다.

도 10b는 참조번호 200의 기기 내 애플리케이션 및/또는 서비스 레벨로부터 참조번호 202의 기기 내 대응 레벨의 노드로 운반되고 있는 데이터의 예를 개시한다. 일반 버퍼 (702)는 데이터 유닛 A를 전송-특정 버퍼 (704)로 릴리즈 (release)한다. 계속해서, 전송-특정 버퍼 (704)는 전송 링크 (750)를 통한 참조번호 202의 기기로의 운송을 위해서 데이터 유닛 A를 릴리즈한다. 데이터 A는 전송-특정 버퍼 (704)에서 보유 미정 확인 모드에서 또한 보인다. 다른 말로 하면, 전송-특정 버퍼 (704)는 참조번호 202의 기기로부터 (예를 들면, 리턴 패킷의 모습으로) 수령 확인을 수신할 때까지 데이터 A의 사본을 유지할 것이다. 이 시점에서, 데이터 A의 사본은 삭제될 수 있을 것이다. 그러나, 어떤 수령도 수신되지 않으면, 그러면 상기 선택된 전송은, 예를 들면, 문턱값 조건 (threshold condition)이 충족될 때까지 데이터 A를 다시 송신할 수 있을 것이다. 정보의 재송신을 통제하는 문턱값 조건들의 예들은 재시도들의 횟수, 타임아웃 구간 등을 포함할 수 있을 것이다.

그러나, 특별한 전송을 이용하여 설립된 접속이 부서질 수 있을 몇몇의 경우들에서, 또는 대안으로, 상기 접속에 관련된 파라미터들은 상기 접속을 유지하기 위해 다른 전송이 더욱 바람직한 전송이 될 수 있는 방식으로 변경될 수 있을 것이다. 예를 들면, 유선 전송은 매체 (예를 들면, 케이블)의 물리적인 단선으로 인한 고장을 경험할 수 있을 것이다. 비슷하게, 무선 전송은 특수한 전송의 송신 범위를 벗어난 기기, 동일한 기기 내에서의 또는 이웃한 무선 기기들에서의 다른 무선들로부터의 간섭, 전자기적인 방사 등으로 인한 접속 손실을 경험할 수 있을 것이다. 그런 단선의 예가 도 10c에 관하여 보인다. 도 10c에서, 선택된 전송을 통해서 설립된 링크 (750)가 손실되었다. 이 예에서 전송 제어 레벨에서 관련된 하드웨어 및/또는 소프트웨어가 성공하지 못한 상기 링크를 다시 설립하기 위해 시도할 것이라는 것을 또한 가정할 수 있을 것이다 (예를 들면, 상기 재시도들을 통제하는 상기 문턱 조건이 충족되었다).

도 10c의 예에서, 링크 (750)의 손실은 전송-특정 버퍼 (704)에서 데이터 A를 포기할 수 있을 것이다. 이 데이터는 일반 버퍼 (702)로 회복될 수 없을 것이기 때문에, 그 데이터는 손실될 것으로 간주될 수 있을 것이다. 데이터 A의 상기 손실을 조정하기 위해, 참조번호 200의 기기는 데이터 A를 다시 생성해야만 할 것이다. 이는 데이터 A가 다시 생성되어 송신될 때까지 데이터 B, C .. 이 지연되어야만 한다는 점에서 전반적인 통신에 영향을 미칠 수 있을 것이다. 데이터 A를 복수하는 것에 관련된 상기의 행동들 모두는 결과적으로 참조번호 200에서 수행되고 있는 통신의 전반적인 QoS에 영향을 미칠 수 있을 것이며, 그리고, 그렇기 때문에, 통신에 대한 전송에 의존하고 있는 어떤 애플리케이션 및/또는 서비스의 전반적인 동작에 영향을 미칠 수 있을 것이며,

그러나, 본 발명의 다양한 예시적인 실시예들은 데이터의 손실로 인해서 초래되는 기기 동작들 상에서 과도하게 해가 되는 영향을 피하기 위한 전략을 상기 NoTA 구조의 유연함을 차입함으로써 제공할 수 있을 것이다. 도 10a와 구조적으로 유사할 수 있는 내용이 개시된 도 11a를 이제 참조한다. 그러나, 도 11a에서 데이터 A가 전송-특정 버퍼 (704)로 전달된 이후에 데이터 A의 사본은 일반 버퍼 (702)에서 보유될 수 있을 것이다. 데이터 A의 상기 "사본"은 상기 정보를 수신했던 참조번호 202의 기기로부터 확인이 수신될 때까지 보유될 수 있을 것이다. 이 프로세스의 예가 도 11b에 개시된다.

도 11b는 성공적인 트랜잭션의 일 예를 보여준다. 더 상세하게는, 정보는 참조번호 200의 기기 내의 전송-특정 버퍼 (704)로부터 참조번호 202의 기기 내의 대응 전송-특정 버퍼 (704)로 전송 링크 (750)를 경유하여 송신되고 있다. 이 예에서, 데이터 A는 참조번호 202의 기기에서 수신되었으며, 이는, 예를 들면, 참조번호 202의 기기로부터 참조번호 200의 기기로 송신되는 수령 확인 패킷에 의해 확인될 수 있을 것이다. 성공적인 트랜잭션의 결과, TX 버퍼는 비워질 것이며 송신될 다음 데이터 유닛 (예를 들면, 데이터 B)을 받을 수 있을 것이다. 상기에 목록화된 동작 (예를 들면, 확인 패킷 수령 또는 데이터 B를 전송-특정 버퍼 (704)로 받아들임)의 어느 하나가 일반 버퍼 (702)에게 상기 트랜잭션이 성공적이라는 것을 알리는 지시로서 사용될 수 있을 것이다. 대안으로, 전송-특정 버퍼 (704)는 이전의 트랜잭션이 성공적이었다는 것을 나타내는 메시지를 일반 버퍼 (702)에게 송신할 수 있을 것이다. 일반 버퍼 (702)는 그러면 자신이 가지고 있던 데이터 A의 사본을 삭제할 수 있을 것이며 그리고 송신된 다음 데이터 유닛의 사본을 보유할 수 있을 것이다.

이전에 선택된 전송이 실패를 겪고, 또는 대안으로, 상기 접속에 관련된 파라미터들이 변경되어 상기 이전에 선택된 전송이 더 이상 바람직하지 않게 되며, 그리고 전송 스위치가 발생할 것으로 결정되는 경우인 상황에서, 본 발명의 적어도 하나의 실시예에 따른 상기 예시의 구성의 효과가 도 11c에 관련하여 보여진다. 도 10c와 유사하게, 이전에 선택된 전송을 통한 원래의 링크 (750)가 실패하고, 데이터 A를 송신하거나 회복하기 위한 어떤 수단도 남겨놓지 않고 데이터 A를 전송-특정 버퍼 (704)에 남겨놓는다. 그러나, 일반 버퍼 (702)가 데이터 A의 사본을 유지하고 있기 때문에, 교정 행동이 신속하게 시작될 수 있을 것이다. 이 시나리오에서, 새로운 링크는 대응하는 전송-특정 버퍼 (1100)를 가진 다른 전송과 함께 설립된다. 그러면 일반 버퍼 (702)는 데이터 A를 링크 (800)를 통해서 전송-특정 버퍼 (1100)로 다시 포워딩할 수 있을 것이다.

일반 버퍼 (702)는 성공적인 트랜잭션이 상기 새로운 전송 링크 (800)를 통해서 확인될 때까지는 데이터 A에 대한 정보를 삭제하지 않는다는 것에 유의하는 것이 중요하다. 그러므로, 일단 전송-특정 버퍼 (1100)는 확인을 수신하고 그리고/또는 새로운 데이터 유닛을 받아들일 준비가 되면, 일반 버퍼 (702)는 데이터 A를 삭제하고 그리고 송신을 위해 새로운 데이터 유닛을 포워딩한다 (예를 들면, 데이터 B). 상기에서 이전에 설명된 프로세스에서와 같이, 일반 버퍼 (702)는 성공적인 트랜잭션이 확인될 때까지는 데이터 B의 사본을 저장할 것이다. 그렇지 않으면, 필요하다면 새로운 전송이 선택될 수 있을 것이며, 그리고 데이터 B는 송신을 위해 대응하는 전송-특정 버퍼로 전달될 수 있을 것이다.

본 발명의 적어도 하나의 실시예에 따라, 데이터 사본들을 저장하기 위해 일반 버퍼 (702)에 유보된 메모리를 릴리즈하는 원칙은 사용되는 특별한 전송(들)에 종속되어 변할 수 있을 것이다. 예를 들면, 수신하는 측에서 데이터의 일부 양을 수신한 것을 나타내는 (예를 들면, 송신이 성공적이었다) 다양한 방법들이 존재할 수 있을 것이기 때문에, 그러면, 확인된 수신 데이터의 실제의 양 역시 변할 수 있을 것이다. 더 상세하게는, 일반 버퍼 (702)의 입도 (granularity) 및 전송-특정 버퍼 (704)는 다를 수 있을 것이며, 그래서, 일반 버퍼 메모리가 릴리즈될 때에 특별한 고려가 필요할 수 있을 것이다. 다른 말로 하면, 일반 버퍼 (702) 내에서 동시에 유지될 수 있을 데이터 사본들의 개수는 사용되고 있는 전송(들)의 속도, 상기 전송(들)이 오류 교정을 지원하는 가의 여부, 상기 전송(들)의 송신 데이터 유닛 크기 등과 같은 다양한 전송-특정 팩터들에 종속될 수 있을 것이다.

본 발명의 적어도 하나의 예시적인 실시예에 따른 프로세스 흐름을 설명하는 흐름도가 도 12에 관해서 이제 개시된다. 이 예에서, 기기 내에서의 애플리케이션 및/또는 서비스들이 다른 기기들의 자원들과 인터액트 (interact) 하기를 원한다. 단계 1200에서, 상기 애플리케이션 및/또는 서비스 레벨로부터의 통신에 대한 요청이 인지될 수 있을 것이다. 그러면, 송신될 데이터는 일반 버퍼 내에 저장될 수 있을 것이며, 단계 1202에서, 이는 (아마도 작은 증분 (increment)들로 또는 유닛들 내에서) 전송-특정 버퍼로 전달될 수 있을 것이다. 그러면, 단계 1204에서 상기 전송-특정 버퍼는 상기 정보를 송신하기 위해 상기 선택된 전송에 액세스할 수 있을 것이며, 상기 트랜잭션은, 예를 들면, 유선 또는 무선 전송을 사용하여 처리된다.

단계 1206에서, 단계 1204에서 송신된 상기 정보가 성공적으로 수신되었는가의 여부에 관한 결정을 할 수 있을 것이다. 이는, 예를 들면, 수신되는 수령 확인 메시지에 의해 확인이 될 수 있을 것이다. 수령이 확인되지 않으면, 단계 1208에서 상기 전송이 상기 데이터를 다시 송신할 것을 시도해야만 하는가의 여부에 관한 결정을 해야 할 수 있을 것이다. 이 결정은 상기에서 설명된 것과 같은 문턱조건의 관점에서 만들질 수 있을 것이다. 재시도를 하기 위한 상기 옵션이 이용 가능하면, 상기 전송은 상기 정보가 단계 1210에서 다시 송신되도록 트리거할 수 있을 것이다. 상기 정보는 단계 1204에서 송신될 수 있을 것이며, 그리고 성공적인 데이터 송신을 검증하는 것은 단계 1206에서 다시 발행한다.

목표 기기에서 데이터 수령이 확인되면, 상기 이전에 송신된 데이터의 사본은 단계 1212에서 삭제될 수 있을 것이다. 단계 1214에서 결정된 것과 같이 송신될 더 이상의 데이터가 남아있으면, 그러면 상기 프로세스는, 상기 다음 데이터 유닛이 상기 일반 버퍼로부터 상기 전송-특정 버퍼로 전달될 수 있을 단계 1202로 돌아갈 수 있을 것이며, 그리고 본 발명의 적어도 하나의 예시적인 실시예에 따라서, 상기 전달된 데이터의 사본은 상기 일반 버퍼 내에 저장될 수 있을 것이다. 그러나, 전송 실패가 발생한 것은 대안의 흐름을 트리거할 수 있을 것이다.

예를 들면, 상기 송신된 데이터가 단계 1206에서 결정된 것과 같이 성공적으로 수신되지 않았으면 그리고 다시 시도하는 것이 이용 가능하지 않으면 (예를 들면, 상기 전송이 쓸모가 없기 때문에, 재시도들에 관한 문턱 조건이 실현되지 않았기 때문에 등), 그러면, 단계 1218에서, 전송 스위치 (예를 들면, 전송 스위치 (310))가 상기 시스템의 구성에서 인에이블되었는가의 여부에 관해서 결정이 될 수 있을 것이다. 이 구성은 상기 NoTA 시스템에 참여한 하나 또는 그 이상의 기기들 상에 존재할 수 있을 것이며, 그리고 상기 기기의 특수 구성 및 기능들 (예를 들면, 사용자 인터페이스 능력)에 종속적인 기기들 중의 일부 또는 모두에서 설정될 수 있을 것이다. 상기 전송 스위치가 단계 1218에서 설정되지 않으면, 그러면 상기 프로세스는 단계 1200에서 다음의 통신 요구 사항을 준비하면서 단계 1216 (도 12에서 동일-페이지 레퍼런스 "A"로서 보여짐)에서 종결될 수 있을 것이다. 대안으로, 상기 스위치가 단계 1218에서 인에이블되면, 그러면 전송 변경은 단계 1220에서 트리거될 수 있을 것이다. 이용 가능한 전송들에 관한 정보는 단계 1222에서 얻어질 수 있을 것이며 그래서 전송이 선택될 수 있을 것이다. 본 발명의 적어도 하나의 예시적인 실시예에서, 이 정보는, 예를 들면, 각 이용 가능한 전송의 전달될 정보로의 적용 가능성, 상기 환경의 상태들 (예를 들면, 간섭), 상기 기기의 상태 (예를 들면, 전력 레벨) 등을 기반으로 하여 주문될 수 있을 것이다. 전송을 선택한 것은 단계 1224에서 검증될 수 있을 것이다. 예를 들면, 특성들을 기반으로 하는 가장 적합한 전송이 이미 최대 사용 레벨에서 동작하고 있기 때문에, 다른 활성 통신들과 간섭할 수 있을 것이기 때문에 등의 이유로 사용 가능하지 않은 상황이 존재할 수 있을 것이다. 결과적으로, 상기 프로세스는 상기 전송 정보를 어떻게 해서든지 새롭게 하고 그리고 다른 전송을 선택하기 위해 단계 1222로 돌아갈 수 있을 것이다.

일단 적절한 전송이 선택되고 그리고 사용하기 위해 이용 가능한 것으로 또한 결정이 되면, 그러면 단계 1226에서, 상기 새로운 전송을 이용하여 통신 링크가 설립될 수 있을 것이다. 그러면, 상기 일반 버퍼는 상기 성공적으로 송신되지 않은 데이터의 저장된 사본을 상기 새롭게 선택된 전송에 대응하는 전송-특정 버퍼로 단계 1228에서 전달할 수 있을 것이다. 그러면, 상기 프로세스 흐름은 상기 데이터가 상기 전송-특정 버퍼로부터 그 데이터의 목적지 (예를 들면, 다른 기기)로 상기 새로운 전송을 경유하여 송신될 수 있을 (도 12에서 동일-페이지 레퍼런스 "B"로서 보이는) 단계 1204로 돌아갈 수 있을 것이며, 그리고 상기 송신된 데이터, 이제는 대안의 전송을 이용하여 송신되고 있는 상기 송신 데이터가 상기 목적지 기기에서 성공적으로 수신되었는가의 여부에 관해서 단계 1206에서 다시 결정될 수 있을 것이다.

여기에서 개시된 본 발명의 다양한 실시예들의 관점에서, 전송-독립적인 그리고 전송-특정 데이터 버퍼들의 결합된 구현으로부터 여러 가지 이점들이 실현될 수 있을 것이다. 예를 들면, 편리한 접속 설립 및 데이터 재송신은 하나 또는 그 이상의 활성 전송들이 실패하거나 또는 접속을 위한 활성 전송을 스위치하기 위한 결정이 만들어지는 경우인 시나리오에서 실현될 수 있을 것이다. 적어도 하나의 예시적인 시나리오에서, 전송에서 문제점들이 있을 때에 블루투스를 경유한 송신을 기다리는 데이터가 손실될 수 있을 것이다. 그러나, 블루투스 데이터 버퍼 내에서 포기된 송신되지 않은 데이터의 사본은 상기 일반 데이터 버퍼 내에 여전히 존재할 수 있을 것이다. "로 (raw)" 데이터가 상기 전송-독립적인 일반 데이터 버퍼 내에서 여전히 이용 가능하기 때문에, 이 백업 데이터 사본은 블루투스-포맷의 데이터 패킷들을 회복하여 전송-독립적인 포맷으로 변환하려고 시도하는 부담 없이 대안의 전송 (예를 들면, WLAN)으로 즉시 할당될 수 있을 것이다. 또한, 상기 일반 데이터 버퍼 내에 저장된 데이터는 전송-적합한 패킷들로 분해될 수 있을 것이며, 그래서 대응 데이터가 그 목적지에 성공적으로 도달했다는 표시를 상기 일반 데이터 버퍼가 수신할 때마다, 상기 일반 데이터 버퍼 내에 저장된 상기 사본은 제거될 수 있을 것이다. 블루투스 전송이 상기 데이터를 성공적으로 송신할 수 없는 경우인 상기의 예시적인 시나리오에서, 상기 데이터가 다른 전송으로 재할당되었다는 표시는 상기 블루투스 무선 제어 엔티티에게로 제공될 수 있을 것이며 그래서 상기 대안의 전송을 경유하여 성공적으로 송신되었던 상기 데이터는 상기 블루투스 버퍼로부터 제거될 수 있을 것이다.

따라서, 본 발명이 관련된 기술 분야에서 통상의 지식을 가진 자들에게는 본 발명의 사상 및 범위로부터 벗어나지 않으면서도 포맷과 상세한 내용에서의 다양한 변경들이 만들어질 수 있다는 것은 명백할 것이다. 본 발명의 넓음과 범위는 상기에서-설명된 예시적인 실시예들에 의해 제한되지 않아야 하며, 이하에서의 청구범위 및 등가물에 따라서만 경계가 정해져야만 한다.

Claims (27)

1. 정보를 전송-독립적인 데이터 버퍼로부터 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 전달하고, 이 경우 상기 전달된 정보의 사본은 상기 전송-독립적인 데이터 버퍼 내에서 유지되며;
   상기 정보를 대응하는 전송을 이용하여 상기 전송-특정 버퍼로부터 송신하고;
   상기 전송을 경유하여 송신된 상기 정보가 의도된 수신자에 의해 성공적으로 수신되었다는 것을, 하나 이상의 전송-특정 팩터들을 기반으로 하여 검증하고; 그리고
   상기 정보가 성공적으로 수신되었으면, 상기 전송-독립적인 데이터 버퍼 내에서 유지된 상기 전달된 정보의 상기 사본을 삭제하는 것을 포함하는 방법.
2. 제1항에 있어서,
   상기 전송-독립적인 데이터 버퍼 그리고 상기 하나 이상의 전송-특정 데이터 버퍼들은 동일한 기기 내에 존재하는, 방법.
3. 제1항에 있어서,
   상기 정보는 기기 상에서의 애플리케이션 또는 서비스로부터의 통신 요청에 응답하여 상기 전송-독립적인 데이터 버퍼로부터 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 송신되는, 방법.
4. 제1항에 있어서,
   상기 전송을 통해서 송신된 상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되었다고 검증하는 것은 다른 기기로부터의 확인 패킷을 수신하는 것을 포함하는, 방법.
5. 제1항에 있어서, 상기 방법은,
   문턱 조건이 충족될 때까지 상기 정보를 상기 전송에 대응하는 상기 전송-특정 데이터 버퍼로부터 재송신하는 것을 더 포함하는, 방법.
6. 제1항에 있어서, 상기 방법은,
   상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되지 않았으면 새로운 전송을 선택하는 것을 더 포함하는, 방법.
7. 제6항에 있어서, 상기 방법은,
   상기 전달된 정보의 상기 사본을 상기 새로운 전송에 대응하는 전송-특정 데이터 버퍼로 포워딩하는 것을 더 포함하는, 방법.
8. 컴퓨터 프로그램을 저장하는 컴퓨터-독출가능 매체로서,
   상기 컴퓨터 프로그램은,
   정보를 전송-독립적인 데이터 버퍼로부터 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 전달하게 하고, 그리고 상기 전달된 정보의 사본을 상기 전송-독립적인 데이터 버퍼 내에서 유지하게 하도록 구성된 코드;
   상기 정보를 대응 전송을 이용하여 상기 전송-특정 버퍼로부터 송신하게 하도록 구성된 코드;
   상기 전송을 경유하여 송신된 상기 정보가 의도된 수신자에 의해 성공적으로 수신되었다는 것을, 하나 이상의 전송-특정 팩터들을 기반으로 하여 검증하게 하도록 구성된 코드; 그리고
   상기 정보가 성공적으로 수신되었으면, 상기 전송-독립적인 데이터 버퍼 내에서 유지된 상기 전달된 정보의 상기 사본을 삭제하게 하도록 구성된 코드를 포함하는, 컴퓨터-독출가능 매체.
9. 제8항에 있어서,
   상기 전송-독립적인 데이터 버퍼 그리고 상기 하나 이상의 전송-특정 데이터 버퍼들은 동일한 기기 내에 존재하는, 컴퓨터-독출가능 매체.
10. 제8항에 있어서,
    상기 코드는 기기 상에서의 애플리케이션 또는 서비스로부터의 통신 요청에 응답하여 상기 전송-독립적인 데이터 버퍼로부터 상기 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 정보를 송신하는 것이 트리거되게 하도록 구성된, 컴퓨터-독출가능 매체.
11. 제8항에 있어서,
    상기 코드는 상기 전송을 통해서 송신된 상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되었다고 검증하는 것이 다른 기기로부터의 확인 패킷을 수신하도록 구성된 코드를 포함하게 하도록 구성된, 컴퓨터-독출가능 매체.
12. 제8항에 있어서,
    문턱 조건이 충족될 때까지, 상기 전송에 대응하는 상기 전송-특정 데이터 버퍼로부터 정보를 재송신하게 하도록 구성된 코드를 더 포함하는, 컴퓨터-독출가능 매체.
13. 제8항에 있어서,
    상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되지 않았으면 새로운 전송을 선택하게 하도록 구성된 코드를 더 포함하는, 컴퓨터-독출가능 매체.
14. 제13항에 있어서,
    상기 전달된 정보의 상기 사본을 상기 새로운 전송에 대응하는 전송-특정 데이터 버퍼로 포워딩하게 하도록 구성된 코드를 더 포함하는, 컴퓨터-독출가능 매체.
15. 하나 이상의 무선 전송들을 지지하도록 구성된 적어도 하나의 통신 모듈; 및
    상기 적어도 하나의 통신 모듈에 연결된 프로세서를 포함하는 장치로서,
    상기 프로세서는 상기 장치로 하여금,
    정보를 전송-독립적인 데이터 버퍼로부터 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 전달하고, 그리고 상기 전달된 정보의 사본을 상기 전송-독립적인 데이터 버퍼 내에서 유지하고;
    상기 정보를 대응하는 전송을 이용하여 상기 전송-특정 버퍼로부터 송신하고;
    상기 전송을 경유하여 송신된 상기 정보가 의도된 수신자에 의해 성공적으로 수신되었다는 것을, 하나 이상의 전송-특정 팩터들을 기반으로 하여 검증하고; 그리고
    상기 정보가 성공적으로 수신되었으면, 상기 전송-독립적인 데이터 버퍼 내에서 유지된 상기 전달된 정보의 상기 사본을 삭제하는 것을 적어도 수행하게 하도록 구성된, 장치.
16. 제15항에 있어서,
    상기 전송-독립적인 데이터 버퍼 그리고 상기 하나 이상의 전송-특정 데이터 버퍼들은 동일한 장치 내에 존재하는, 장치.
17. 제15항에 있어서, 상기 프로세서는 상기 장치로 하여금,
    상기 장치 상에서의 애플리케이션 또는 서비스로부터의 통신 요청에 응답하여 상기 전송-독립적인 데이터 버퍼로부터 상기 하나 이상의 전송-특정 데이터 버퍼들로 정보를 송신하게 하도록 또한 구성된, 장치.
18. 제15항에 있어서, 상기 프로세서는 상기 장치로 하여금,
    상기 전송을 통해서 송신된 상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되었다고 검증하기 위해 다른 장치로부터의 확인 패킷을 수신하게 하도록 또한 구성된, 장치.
19. 제15항에 있어서, 상기 프로세서는 상기 장치로 하여금,
    문턱 조건이 충족될 때까지, 상기 전송에 대응하는 상기 전송-특정 데이터 버퍼로부터 정보를 재송신하게 하도록 또한 구성된, 장치.
20. 제15항에 있어서, 상기 프로세서는 상기 장치로 하여금,
    상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되지 않았으면 새로운 전송을 선택하게 하도록 또한 구성된, 장치.
21. 제20항에 있어서, 상기 프로세서는 상기 장치로 하여금,
    상기 전달된 정보의 상기 사본을 상기 새로운 전송에 대응하는 전송-특정 데이터 버퍼로 포워딩하게 하도록 또한 구성된, 장치.
22. 정보를 전송-독립적인 데이터 버퍼로부터 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 전달하는 수단으로, 이 경우 상기 전달된 정보의 사본은 상기 전송-독립적인 데이터 버퍼 내에서 유지되는, 전달 수단;
    상기 정보를 대응 전송을 이용하여 상기 전송-특정 버퍼로부터 송신하는 수단;
    상기 전송을 경유하여 송신된 상기 정보가 의도된 수신자에 의해 성공적으로 수신되었다는 것을, 하나 이상의 전송-특정 팩터들을 기반으로 하여 검증하는 수단; 그리고
    상기 정보가 성공적으로 수신되었으면, 상기 전송-독립적인 데이터 버퍼 내에서 유지되는 상기 전달된 정보의 상기 사본을 삭제하는 수단을 포함하는 장치.
23. 제22항에 있어서,
    상기 전송-독립적인 데이터 버퍼 그리고 상기 하나 이상의 전송-특정 데이터 버퍼들은 동일한 기기 내에 존재하는, 장치.
24. 제22항에 있어서, 상기 장치는,
    문턱 조건이 충족될 때까지 상기 정보를 상기 전송에 대응하는 상기 전송-특정 데이터 버퍼로부터 재송신하는 수단을 더 포함하는, 장치.
25. 제22항에 있어서, 상기 장치는,
    상기 정보가 상기 의도된 수신자에 의해 성공적으로 수신되지 않았으면 새로운 전송을 선택하는 수단을 더 포함하는, 장치.
26. 제25항에 있어서, 상기 장치는,
    상기 전달된 정보의 상기 사본을 상기 새로운 전송에 대응하는 전송-특정 데이터 버퍼로 포워딩하는 수단을 더 포함하는, 장치.
27. 프로세서, 전송-독립적인 일반 데이터 버퍼 그리고 하나 이상의 전송-특정 데이터 버퍼들을 포함하는 제1 기기; 및
    제2 기기;를 포함하는 시스템으로서,
    상기 제1 기기의 상기 프로세서는 상기 제1 기기로 하여금. 상기 일반 데이터 버퍼로부터 상기 하나 이상의 전송-특정 데이터 버퍼들 중의 적어도 하나로 정보를 전달하게 하고, 그리고 상기 전달된 정보의 사본을 상기 일반 데이터 버퍼 내에서 유지하게 하도록 구성되며;
    상기 제1 기기의 프로세서는 상기 제1 기기로 하여금, 상기 적어도 하나의 전송-특정 데이터 버퍼로부터 상기 제2 기기로 대응 전송을 이용하여 정보를 송신하게 하도록 또한 구성되며;
    상기 제1 기기의 프로세서는 상기 제1 기기로 하여금, 상기 전송을 경유하여 송신된 상기 정보가 상기 제2 기기에 의해 성공적으로 수신되었다는 것을 하나 이상의 전송-특정 팩터들을 기반으로 하여 검증하게 하도록 또한 구성되고; 그리고
    상기 정보가 성공적으로 수신되었으면, 상기 제1 기기의 프로세서는 상기 제1 기기로 하여금, 상기 전송-독립적인 데이터 버퍼 내에서 유지된 상기 전달된 정보의 상기 사본을 삭제하게 하도록 또한 구성된, 시스템.

Images