KR101321204B1 - 무선 네트워크를 통한 응급 호출 데이터 전송 장치 및 방법 - Google Patents

Abstract

응급 호출과 같은 상위-우선순위 호출과 관련하여 유용한 데이터를 제공하는 방법 및 장치를 제공한다. 일 실시예에서, 데이터는 응급 호출의 음성 또는 사용자 데이터 스트림(예를 들어, RTP 패킷으로 전달됨) 내에 산재되어 있는 RTCP(RTP Control Protocol) 패킷과 같은 하나 이상의 실시간 프로토콜 패킷 내에 삽입되는 데이터(예를 들어, MSD 또는 FSD)를 포함한다. 사용자 데이터와 동일한 전송 연결을 사용하여 시작측 단말기[예를 들어, IVS(in-vehicle system)]로부터 PSAP(Public Safety Answering Point)로 데이터 부분을 신뢰성있게 전송하는 장치 및 방법이 기술되어 있다.

Description

무선 네트워크를 통한 응급 호출 데이터 전송 장치 및 방법{APPARATUS AND METHODS FOR TRANSMISSION OF EMERGENCY CALL DATA OVER WIRELESS NETWORKS}

우선권

본 출원은 발명의 명칭이 본 발명과 동일한 2009년 2월 10일자로 출원된 미국 특허 출원 제12/368,947호를 기초로 우선권을 주장하며, 이 출원은 전체 내용이 참조 문헌으로서 본 명세서에 포함된다.

저작권

이 특허 문서의 개시 내용의 일부분은 저작권 보호를 받는 내용을 포함하고 있다. 저작권 소유자는 임의의 자가 특허청 특허 파일 및 기록에 나와 있는 그대로 특허 문서 또는 특허 개시 내용을 복제 재현하는 것에 대해서는 이의를 갖지 않지만, 그렇지 않은 경우에는 모든 저작권을 보유한다.

본 발명은 일반적으로 무선 통신 시스템의 분야에 관한 것이다. 보다 상세하게는, 예시적인 일 양태에서, 본 발명은 무선 네트워크 내에서 응급 또는 유사한 호출 데이터를 전송하는 것에 관한 것이다.

예를 들어, 셀룰러 이동 통신 시스템과 같은 디지털 무선 시스템은 실시간 및 비실시간 서비스 둘다를 사용자에게 제공한다. 실시간 서비스의 예는, 예를 들어, 음성 전화 호출 및 화상 전화 호출을 포함하는 반면, 비실시간 서비스는 다양한 유형의 메시징 서비스(예를 들어, SMS, MMS, 이메일) 또는 현재 상태 서비스(예를 들어, "채팅")를 포함한다. 디지털 셀룰러 이동 통신은 회선 교환 네트워크 아키텍처(CS 도메인)에서 또는 패킷 교환 네트워크 아키텍처(PS 도메인)에서 실현될 수 있다. CS 도메인 호출에서는, 예를 들어, 디지털 음성 데이터를 교환하기 위해, 사용자 데이터 교환이 일어날 수 있기 전에 "회선" 또는 연속 연결이 생성되어야 할 필요가 있다. 회선 교환 네트워크는 하나의 단말기를 이동 셀룰러 네트워크(들) 및 CS 도메인 코어(백본) 네트워크를 통해 다른 단말기에 연결한다. 다양한 공지된 제어 프로토콜을 통해 수반된 네트워크 요소들 간에 연결 설정이 수행된다. 연결이 설정되면, 한 단말기에 의해 셀룰러 이동 네트워크로 전송되는 디지털 사용자 데이터는 연결 경로를 따라 네트워크를 통해 상대방 단말기로 전송된다. 회선 교환 경로는 연결의 지속기간 동안 변하지 않은 채로 있으며, 호출의 라우팅을 변경하기 위해 호출 중간에 어떤 수정도 행해질 수 없다.

PS 도메인 호출(예를 들어, VoIP 호출)은 CS 도메인 호출과 같이 "하드 연결(hard connectivity)"을 갖지 않는다. 그 대신에, PS 도메인 호출은 네트워크 레벨에서 유연하게 라우팅되고, 기본 전송 경로가 사전 정의되어 있지 않고 동적으로 변할 수 있다. PS 도메인 호출은 패킷화되고 네트워크 요소의 "클라우드"를 통해 따로따로 전송되며, 따라서 모든 데이터 패킷이 소스 단말기 및 목적지 단말기 둘다의 라우팅가능 네트워크 주소(예를 들어, 인터넷 프로토콜 또는 IP 주소)를 포함한다. 패킷 교환 네트워크의 통상적인 구현은 각각의 전송 데이터 패킷에 인터넷 프로토콜(IP) 라우팅 정보를 삽입할 수 있다. 이 라우팅은 흔히 IP-라우팅이라고 한다. 네트워크 레벨에서 볼 때, IP-라우팅은 비연결형(connectionless)이지만, PS 도메인 호출은 유형, 품질, 형식, 교환된 데이터의 코딩 및/또는 품질, 대역폭은 물론, 기본 전송 스트림의 다른 파라미터와 같은 다양한 파라미터를 협상하기 위해 데이터 전송 이전에 응용 프로그램/세션 계층에서 연결 설정을 필요로 할 수 있다(통상적으로 연결 설정을 수행할 수 있다).

CS 및 PS 도메인은 그의 구조 및 동작 방법에 직접 관련된 몇가지 상이한 차이점을 가진다. 앞서 살펴본 바와 같이, CS 도메인 호출은 동작 내내 "고정된" 회선을 유지하고, 따라서 CS 호출은 (데이터 전송이 고정된 전송 파라미터를 갖는 동일한 경로를 따르기 때문에) 일정한 허용 오차 내에서 그의 데이터 전송을 위한 적절히 일관된 타이밍을 가진다. 게다가, CS 호출은 자연히 선형이고, 각각의 전송이 그보다 앞선 전송(predecessor)에 순차적으로 뒤따른다. PS 도메인 호출은, 패킷이 그의 목적지로 유연하게 라우팅되는 것, 불규칙적인 대역폭 또는 용량, 및 데이터가 라우팅되어 지나가는 일련의 홉의 다양한 지연으로 인해, CS 도메인 호출과 상당히 다르다. 따라서, PS 호출에 있어서 데이터 패킷과 연관된 타이밍 및 지연이 넓은 범위에 걸쳐 변한다. 그에 따라, 음성 또는 비디오 데이터와 같은 실시간 데이터를 전달하는 데이터 패킷은 보통 타이밍 정보의 추출을 가능하게 하는 프로토콜에 삽입된다.

예를 들어, 흔히 사용되는 RTP(Real Time Transport Protocol)는, 그 중에서도, 이러한 타이밍 정보를 포함하고, 셀룰러 이동 네트워크의 PS 도메인 내에서 실시간 음성 및 비디오 데이터 전송에 흔히 사용된다. RTP 및 RTCP 둘다는 어드레싱, 오류 검출 및/또는 오류 정정 메커니즘과 같은 보다 광범위한 전송 계층 요구사항을 처리하는 시스템 내에서 사용하기 위한 것이다. RTP 및 RTCP 패킷이 삽입되는 가장 흔히 사용되는 프로토콜은 UDP(User Datagram Protocol) 및 TCP(Transport Control Protocol)이다. 차이점 중에서도 특히, TCP는 오류 정정 메커니즘에 의한 신뢰할 수 있는 전송 및 QoS(quality of service, 서비스 품질)를 제공하는 반면, UDP는 이러한 보장을 제공하지 않는다. TCP의 부가 기능은 더 많은 메시징 오버헤드는 물론 네트워크 구성요소 내에 "상태 메모리"를 요구한다. UDP는 보다 간단하고 보다 효율적이지만, 그의 베어러(bearer)에 따라 손실이 있고 불규칙적일 수 있다. UDP는 세그먼트를 전송 또는 수신하는 데 어떤 핸드쉐이킹(handshaking)도 필요로 하지 않으며, 따라서 일반적으로 "비연결(connectionless)"로서 분류될 수 있다. RTP는 통상적으로 UDP와 함께 사용되는데, 그 이유는 이 2개의 프로토콜이 보완적 특징을 갖고 있기 때문이다. 대부분의 사용 경우에, TCP의 부가적인 신뢰성이 RTP에서 낭비될 것이고, 정확한 전달을 보장하기 위해 필요한 부가의 시간이 오류 정정의 이점을 무효화시킬 것이다(대부분의 RTP 시스템에서 늦은 패킷이 폐기됨).

응급 및 기타 상위 우선순위 호출

셀룰러 이동 네트워크에서의 통상의 서비스(예컨대, 음성 통화)가 특정의 수락 전제조건(acceptance pre-condition) 하에서만 설정된다. 이들 전제조건은 (신원에 관한) 사용자의 인증, 특정의 서비스에 대한 사용자의 권한 부여, 사용자의 계정 상태의 검사, 및 통신 사업자가 요구된 리소스를 사용자에게 제공할 수 있는 것 또는 제공하려는 의향을 포함할 수 있다. 네트워크 내에 존재하는 조건은 물론 전제조건[예를 들어, 인증, 허가 및 과금(authentication, authorization, and accounting)]과 관련한 이동 단말기의 상태에 따라, 호출 설정 시간이 지연될 수 있거나 호출이 완전히 거부될 수 있다. 상위 우선순위 호출(예를 들어, 화재, 의료 응급 상황 또는 경찰과 같은 응급 서비스 지원을 요청하기 위해 거는 응급 호출)의 경우에, 응급 호출은 임의의 지연 또는 방해를 방지하기 위해 상위 우선순위 처리를 부여받을 수 있다.

응급 호출은 요청되거나 검출될 수 있고, 단말기는 호출 설정 요청에서 응급 호출을 설정하고자 한다는 것을 나타내거나, 대안으로서 네트워크는 목적지 주소가 (예를 들어, 사용자가 911을 다이얼링하는 것 등에 의해) 응급 서비스에 대한 요청인지를 판정할 수 있다. 어느 상황에서든지, 응급 호출을 설정하라는 요청을 수신한 후에, 네트워크는 그 요청을 높은 우선순위로 다루고 처리를 신속히 한다. 응급 호출을 설정하는 것에 부가하여, 네트워크가 종단 지점에 응급 호출의 발신자에 관한 부가의 정보(예컨대, 지리적 위치 등)를 제공하기 위해 다른 절차를 시작할 수 있는 것이 가능하다. 많은 셀룰러 네트워크는 (예를 들어, 사용자가 인증될 필요를 없애주는 것 등에 의해) 최소의 전제조건 집합으로 설정될 수 있는 "응급 호출"을 정의하고 있다.

eCall 및 강화된 911(E911)

관련 표준 단체 및 정부 기관으로부터의 다양한 지도에 따라, 또 하나의 부류의 응급 통신은 소위 "eCall"(유럽) 또는 강화된 911 호출(북미)을 포함하고, 후자는 또한 무선 E911 및 VoIP E911을 포함한다. 예를 들어, 전체 내용이 참조 문헌으로서 본 명세서에 포함되고 유럽 eCall 시스템을 기술하는, 2004년 5월 28일자의 "Memorandum of Understanding for Realisation of Interoperable In-Vehicle eCall"라는 제하의 European Commission Memorandum of Understanding, eSafety Forum and eCall Driving Group 및 관련 구현 표준을 참조하기 바란다.

예를 들어, 상기한 유럽 시스템 하에서, eCall은 자동차 사고와 같은 사건의 탐지 후에 차량의 탑승자에 의해 수동으로 또는 차량내 시스템(In-Vehicle System, IVS)에 의해 자동으로 발생되는 IVS로부터의 응급 호출이다. eCall은 IVS로부터 2세대(2G) 또는 3세대(3G) 모바일 네트워크를 거쳐 PSAP(Public Safety Answering Point)로 전송된다. 응급 호출과 함께, 관련 상황, 예를 들어, 자동차에 의해 자동으로 발생되거나 자동차로부터 도출되는 정보를 기술하는 MSD(Minimum Set of Data)가 PSAP로 전송된다. MSD에 주어지는 정보는 자동차의 고정확도 위치[통상적으로 GNSS(Global Navigation Satellite System) 송수신기로 측정됨], 탑승자의 수, 사고의 결과로서 자동차가 전복되었는지 여부 등을 포함할 수 있다. 초기의 eCall 또는 E911 서비스의 종래 기술의 구현이 CS 도메인에서 동작한다는 것에 유의한다.

예시적인 MSD의 형식이 도 1에 나타내어져 있다. 알 수 있는 바와 같이, MSD 내의 정보 요소의 일부분이 선택적이기 때문에, MSD(100)의 크기가 변할 수 있다. 구체적으로는, 선택적 데이터 필드(102)의 내용은 XML(Extensible Markup Language) 코드이기만 하면 되고, 이 필드의 길이는 소정의 범위 내에서 변할 수 있다. 그러나, MSD(100)에 대한 최대 데이터 크기는 140 바이트이다.

MSD에 대한 다른 대안은 기본 전송 메커니즘이 더 큰 크기의 eCall 데이터가 전송될 수 있게 하는 경우 전송될 수 있는 FSD(Full Set of Data)이다. 따라서, 본 명세서에서 사용되는 바와 같이, "eCall 데이터"라는 용어는 eCall 연결 내에서 전송되는(음성 데이터와 함께 일 수 있음) MSD, FSD 또는 임의의 다른 데이터를 말한다.

데이터(예를 들어, MSD 또는 FSD)의 전송을 위한 몇가지 잠재적인 옵션이 존재한다. 이들 옵션은 다음과 같은 것들을 포함한다: (i) SMS(Short Message Service), (ii) UUS(User to User Signaling), (iii) USSD(Unstructured Supplementary Service Data), (iv) GSM(Global Systems for Mobile communications) CS 데이터, (v) DTMF(Dual-Tone Multi-Frequency), 및 (vi) 대역내 모뎀/시그널링 응용 프로그램(In-band modem/Signaling Application). 그러나, 이들 해결책은 적시에 그리고 패킷 교환 네트워크 상에서의 리디렉션 또는 재라우팅 없이 응급 호출과 함께 MSD를 전송하는 적절한 기능을 제공하지 못한다. 결과적으로, 이들 결점을 해결할 향상된 장치 및 방법이 필요하다.

본 발명은 무선(예를 들어, 셀룰러) 통신 네트워크 내에서 응급 또는 유사한 호출 데이터를 전송하는 개선된 장치 및 방법을 제공함으로써 상기한 필요성을 만족시킨다.

본 발명의 제1 양태에서, 패킷 교환 동작을 하도록 구성된 네트워크 내에서 응급 호출을 제공하는 방법이 개시되어 있다. 일 실시예에서, 네트워크는 실질적으로 실시간 패킷 교환 동작을 제공하고, 응급 호출은 제1 스트림 및 하나 이상의 제2 스트림을 갖는 복합 스트림(composite stream)을 포함한다. 제1 스트림이 실질적으로 연속하여 제공되고, 적어도 제1 스트림 및 하나 이상의 제2 스트림을 사용하여 복합 스트림이 형성된다. 세션이 설정되고, 세션은 복합 스트림을 라우팅하도록 구성되며, 복합 스트림은 세션을 통해 전송된다.

한 변형에서, 세션은 세션 시작 프로토콜을 이용하여 설정되는 실시간 세션을 포함한다.

다른 변형에서, 제1 스트림은 복수의 음성 패킷을 포함하고, 하나 이상의 제2 스트림은 복수의 데이터 패킷을 포함한다. 음성 패킷을 생성하기 위해 음성 신호를 실질적으로 연속하여 인코딩함으로써 실질적으로 연속적인 스트림이 제공된다.

또 다른 변형에서, 하나 이상의 제2 스트림의 제공이 실질적으로 불연속적이거나 일정하지 않은 방식으로 수행되며, 이 실질적으로 불연속적인 방식은 적어도 하나의 소스로부터 단지 주기적으로 또는 간헐적으로 데이터를 제공한다.

또 다른 변형에서, 복합 스트림, 제1 스트림 및 하나 이상의 제2 스트림이 패킷화되고, 제1 스트림의 하나 이상의 패킷 사이에 제2 스트림의 하나 이상의 패킷을 산재시킴으로써 복합 스트림이 형성된다.

또 다른 변형에서, 산재시키는 것은 멀티플렉싱 알고리즘을 사용하여 수행된다.

또 다른 변형에서, 적어도 제1 스트림 및 하나 이상의 제2 스트림을 사용하여 복합 스트림을 형성하는 것은 제1 스트림의 적어도 일부분을 복수의 RTP 패킷을 배치하는 것, 하나 이상의 제2 스트림의 적어도 일부분을 복수의 RTCP 패킷에 배치하는 것, 및 RTP 패킷 사이에 RTCP 패킷을 산재시키는 것에 의해 달성된다.

다른 변형에서, 네트워크는 3GPP IMS-호환 셀룰러 네트워크를 포함하고, 세션은 SIP(Session Initiation Protocol)를 사용하여 설정된다.

본 발명의 제2 양태에서, 패킷 교환 동작을 할 수 있는 네트워크 내에서 응급 호출을 제공하는 장치가 개시되어 있다. 일 실시예에서, 이 장치는 (음성을 연속하여 포착하고 복수의 제1 패킷으로 디지털적으로 분석하도록 구성된) 마이크, 장치 또는 장치가 실려 있는 플랫폼과 연관된 하나 이상의 파라미터를 하나 이상의 제2 패킷으로 인코딩하도록 구성된 하나 이상의 센서, 무선 네트워크를 통해 복수의 패킷을 전송하도록 구성된 무선 송신기, 송신기와 데이터 통신하고 있는 프로세서, 및 복수의 명령어를 갖는 컴퓨터 프로그램을 포함하도록 구성된 매체를 포함하는 컴퓨터 판독가능 장치를 포함한다. 복수의 명령어는, 프로세서에 의해 실행될 때, 적어도 부분적으로 복수의 제1 패킷 사이에 하나 이상의 제2 패킷을 산재시키는 것으로부터 전송을 위한 복수의 패킷을 발생한다. 명령어는 또한 산재된 복수의 제1 패킷 및 하나 이상의 제2 패킷을 저장 없이 라우팅하고 산재된 복수의 패킷을 무선 송신기를 통해 전송하도록 구성된 세션을 설정한다.

한 변형에서, 전송을 위한 복수의 패킷의 발생은 복수의 제3 패킷을 발생하는 것을 포함하고, 제3 패킷은 산재된 복수의 제1 패킷 및 하나 이상의 제2 패킷으로부터 도출된다.

다른 변형에서, 장치는 또한 무선 네트워크로부터 복수의 패킷을 수신하도록 구성된 무선 수신기, 및 수신된 복수의 패킷으로부터 음성을 디지털적으로 합성하도록 구성된 스피커를 포함한다.

또 다른 변형에서, 장치는 또한 스피커 서브시스템, 무선 네트워크로부터 복수의 패킷을 수신하도록 구성된 수신기 장치, 및 네트워크로부터 수신된 복수의 패킷을 음성 성분과 데이터 성분으로 분리하도록 구성된 분리 장치를 포함한다. 분리 장치는 음성 성분을 스피커 서브시스템에 제공하고, 데이터 성분으로부터 하나 이상의 제2 패킷의 수신의 상태를 결정하도록 구성되어 있다.

또 다른 변형에서, 장치는 실질적으로 한명 이상의 탑승자를 수송하도록 구성된 차량 내에 하우징되어 있다.

또 다른 변형에서, 장치는 위성-기반 위치 결정 수신기(예를 들어, GPS 수신기)를 포함한다. 하나 이상의 센서는 (i) 충돌을 탐지하도록 구성된 가속도계, (ii) 차량 전복을 탐지하도록 구성된 가속도계, 및/또는 (iii) 차량 탑승을 판정하도록 구성된 센서를 포함할 수 있다.

다른 변형에서, 무선 네트워크는 3GPP IMS(IP Multimedia Core Network Sub-System) 요구사항에 부합하는 셀룰러 네트워크이고, 세션은 SIP(Session Initiation Protocol)를 사용하여 설정된다.

또 다른 변형에서, 복수의 제1 패킷 사이에 하나 이상의 제2 패킷을 산재시키는 것은 복수의 RTP 패킷 사이에 하나 이상의 RTCP 패킷을 산재시키는 것을 포함하며, 하나 이상의 RTCP 패킷은 MSD(Minimum Set of Data)를 포함한다.

본 발명의 제3 양태에서, 패킷 교환 네트워크 내에서 응급 호출을 수신하도록 구성된 네트워크 장치가 개시되어 있다. 일 실시예에서, 이 장치는 장치와 데이터 통신하고 있는 IP(internet protocol) 네트워크를 통해 제1 및 제2 복수의 패킷을 수신하도록 구성된 네트워크 인터페이스, 인터페이스와 데이터 통신하고 있는 프로세서, 및 복수의 명령어를 갖는 컴퓨터 프로그램을 포함하도록 구성된 매체를 포함하는 컴퓨터 판독가능 장치를 포함한다. 프로세서에 의해 실행될 때, 이들 명령어는 통신 세션에 대한 요청을 수신하고(세션은 제1 및 제2 복수의 패킷의 전송을 용이하게 하도록 구성됨), 세션을 설정하며, 세션을 통해 제1 및 제2 복수의 패킷을 수신하고, 제1 복수의 패킷으로부터 실질적으로 실시간 사용자 데이터를 추출하며, 제2 복수의 패킷으로부터 응급-관련 데이터를 추출한다.

한 변형에서, 네트워크 장치는 스피커를 가지며 스피커를 통해 오디오를 재생하도록 구성된 오디오 모듈을 더 포함하며, 오디오는 추출된 실질적으로 실시간 사용자 데이터로부터 도출된다.

다른 변형에서, 패킷 교환 네트워크는 3GPP IMS(IP Multimedia Core Network Sub-System)를 포함하고, 세션은 적어도 SIP(Session Initiation Protocol)를 사용하여 설정된다.

다른 변형에서, 제1 및 제2 복수의 패킷은 각각 산재된 RTP 패킷 및 RTCP 패킷이다.

또 다른 변형에서, RTCP 패킷의 적어도 일부분은 MSD(Minimum Set of Data)를 포함한다. 또 다른 변형에서, 응급-관련 데이터는 MSD(Minimum Set of Data)를 포함한다.

또 다른 변형에서, 네트워크 장치는 PSAP(Public Safety Answering Point)의 일부이다.

본 발명의 제4 양태에서, 패킷 교환 동작을 할 수 있는 네트워크 내에서 상위-우선순위 호출을 하는 방법이 개시되어 있다. 일 실시예에서, 이 방법은 실질적으로 연속적인 사용자 데이터 스트림 및 상위-우선순위 이벤트와 관련된 복수의 데이터를 제공하는 단계를 포함한다. 사용자 데이터 스트림의 적어도 일부분은 제1 패킷화된 프로토콜 구조 내에 배치되고, 상위-우선순위 이벤트와 관련된 데이터의 적어도 일부분은 제2 패킷화된 프로토콜 구조 내에 배치된다. 제1 및 제2 프로토콜 구조는 산재되어 있고, 복합 스트림은 통신 세션을 통해 네트워크를 거쳐 전송된다.

한 변형에서, 상위-우선순위 호출은 응급 호출이고, 상위-우선순위 이벤트에 관련된 데이터는 MSD(Minimum Set of Data)를 포함한다.

다른 변형에서, 네트워크는 3G 셀룰러 네트워크이고, 전송은 먼저 세션 설정 프로토콜(session establishment protocol)을 통해 적어도 하나의 세션을 설정함으로서 수행된다.

다른 변형에서, 제1 패킷화된 프로토콜은 실시간 전송 프로토콜이고, 제2 패킷화된 프로토콜은 실시간 제어 프로토콜을 포함한다.

또 다른 변형에서, 이 방법은 이벤트에 따라 실질적으로 육상 차량 내에 배치된 전송 장치에 의해 실질적으로 자동으로 시작된다. 이 이벤트는, 예를 들어, (i) 차량 충돌, (ii) 차량 전복, 및/또는 (iii) 차량 화재를 포함할 수 있다.

또 다른 변형에서, 사용자 데이터는 비디오 데이터 및 음성 데이터 둘다를 포함한다.

또 다른 변형에서, 상위-우선순위 이벤트와 관련된 데이터는 호출 시의 제1 엔터티에 대한 실질적으로 정확한 위치 데이터를 포함하고, 정확한 위치 데이터는 네트워크 주소에만 기초하는 것은 아니다.

본 발명의 제5 양태에서, 응급 호출을 전달하도록 구성된 통신 장치가 개시되어 있다. 일 실시예에서, 전달은 신뢰할 수 있는 패킷화된 프로토콜 전송을 사용하고, 하나 이상의 응급 호출이 네트워크로부터 패킷화된 데이터를 수신하고 데이터를 처리하도록 구성된 엔터티로 전송된다. 이 장치는 무선 송신기, 및 송신기와 통신하고 있는, 패킷화된 데이터가 네트워크를 통해 전송되게 하도록 구성된 장치를 포함한다. 패킷화된 데이터는 실질적으로 실시간 사용자 데이터를 전달하는 제1 패킷, 및 제1 패킷이 산재되어 있고 응급-관련 데이터를 전달하는 제2 패킷을 포함하고, 제1 및 제2 패킷은 상이한 프로토콜에 따라 형식 지정되어 있다. 이들 상이한 프로토콜 각각은 상기한 신뢰할 수 있는 전송을 제공하도록 구성된 서비스 품질 요구사항을 지원한다.

한 변형에서, 응급-관련 데이터는 호출 시의 통신 장치에 대한 정확한 위치 데이터(네트워크 주소에 기초하거나 기초하지 않을 수 있음)를 포함한다.

본 발명의 제6 양태에서, 소스로부터 목적지로 응급 호출을 라우팅하는 방법이 개시되어 있다. 일 실시예에서, 이 방법은 회선 교환 네트워크 경로 및 패킷 교환 네트워크 경로 둘다가 호출을 라우팅하는 데 이용가능한지를 판정하고, 경로들 둘다가 이용가능한 경우, 경로들 중 적어도 하나의 경로가 적어도 하나의 선택 기준에 대해 평가된다. 경로들 중 하나의 경로가 이 평가에 적어도 부분적으로 기초하여 선택되고, 호출이 선택된 경로를 통해 라우팅된다. 패킷 교환 경로만이 이용가능한 경우, 호출이 패킷 교환 경로를 통해 라우팅된다.

본 발명의 다른 양태에서, 네트워크 제어기 및 다중-모드(예를 들어, CS-지원 및 PS-지원) 무선 네트워크를 통해 응급 데이터를 라우팅하는 관련 방법이 개시되어 있다. 일 실시예에서, 네트워크 제어기는 하나 이상의 기준에 기초하여 2가지 옵션(CS 또는 PS) 중 어느 것이 최적인지를 평가하고 이어서 그 도메인을 통해 데이터를 라우팅하도록 구성된 논리를 포함한다. 예를 들어, CS 도메인은 기술적 이유 또는 기타 이유로 이용가능하지 않을 수 있으며, 그에 따라, PS 도메인 eCall이 선택될 것이다.

본 발명의 또 다른 양태에서, 저장 매체를 갖는 컴퓨터 판독가능 장치가 개시되어 있다. 특정 변형에서, 이 장치는 하드 디스크 드라이브(HDD), CD-ROM, 또는 프로그램 또는 데이터 메모리 집적 회로(IC)의 형태를 취하고, 본 명세서에 기술된 기능의 다양한 양태를 구현하는 하나 이상의 컴퓨터 프로그램을 저장한다.

이하에 제공되는 첨부 도면 및 예시적인 실시예에 대한 상세한 설명을 참조하면, 본 발명의 기타 특징 및 이점이 기술 분야의 당업자에 의해 즉각 이해될 것이다.

도 1은 종래 기술의 MSD(Minimum Set of Data) 패킷과 연관된 패킷 구조의 그래픽 표현이다.
도 2는 본 발명에 따른, 응급 호출 데이터를 실시간 음성 호출 내에 삽입하는 일반화된 응급 호출 프로세스의 일 실시예를 나타내는 논리 흐름도이다.
도 2a는 본 발명에 따른, 응급 호출 데이터를 라우팅하는 도메인 중재/선택 프로세스의 일 실시예를 나타내는 논리 흐름도이다.
도 3은 종래 기술에 따른, 일반적인 RTP(Real Time Protocol) 응용 프로그램 패킷을 나타낸 도면이다.
도 3a는 본 발명에 따른, IVS(In-Vehicle System)에 대한 응급 호출 서비스를 제공하도록 구성된 RTP(Real Time Protocol) 응용 프로그램 패킷의 패킷 형식의 한 예시적인 실시예를 나타낸 도면이다.
도 3b는, 사전 정의된 값을 갖는 복수의 예시적인 설정가능 필드를 보여주는, IVS(In-Vehicle System)에 대한 응급 호출 서비스를 제공하도록 구성된 RTP(Real Time Protocol) 응용 프로그램 패킷의 패킷 형식의 다른 예시적인 실시예를 나타낸 도면이다.
도 3c는, 패킷 순서를 설정하도록 구성된 필드를 보여주는, IVS(In-Vehicle System)에 대한 응급 호출 서비스를 제공하도록 구성된 RTP(Real Time Protocol) 응용 프로그램 패킷의 패킷 형식의 또 다른 예시적인 실시예를 나타낸 도면이다.
도 3d는 IVS(In-Vehicle System)에 대한 응급 호출 서비스를 제공하도록 구성된 RTP(Real Time Protocol) 응용 프로그램 패킷의 확장가능 패킷 형식의 일 실시예를 나타낸 도면이다.
도 4는 IVS(In-Vehicle System)에 대한 응급 호출 서비스를 제공하도록 구성된, 본 발명에 따른 SIP(Session Initiation Protocol)-기반 호출 설정 프로세스의 한 예시적인 실시예를 도식적으로 나타낸 도면이다.
도 5는 예시적인 셀룰러 PSAP 시스템이 본 발명의 일 실시예에 따른 방법 및 장치를 이용하여 IVS와 통신하는 것을 도식적으로 나타낸 도면이다.
도 6a는 본 발명에 따른 PSAP 장치의 일 실시예를 나타낸 블록도이다.
도 6b는 본 발명에 따른 육상 차량(자동차) 내에 배치된 IVS 장치의 일 실시예를 나타낸 블록도이다.

이제부터 도면들을 참조할 것며, 도면들 전체에 걸쳐 동일한 참조 번호가 동일한 부분을 참조한다.

개요

본 발명은, 그 중에서도, 상위 우선순위 호출과 관련하여 유용한 데이터를 제공하는 방법 및 장치를 개시한다. 일 실시예에서, 데이터는 응급 호출(eCall)의 음성 데이터 스트림을 포함하는 RTCP(RTP Control Protocol) 패킷 내에 삽입되는 MSD(minimum set of data)이다. 음성 데이터와 동일한 전송 연결을 사용하여 단말기(IVS)로부터 PSAP(Public Safety Answering Point)로 MSD 데이터 부분을 신뢰성있게 전송하는 장치 및 방법이 기술되어 있다. 게다가, 원하는 경우, MSD 데이터 패킷이 수정되거나 변경될 수 있지만, 음성 데이터 패킷은 그대로 있을 수 있다.

한 측면에서, 본 발명은 또한 유익하게도 현재의 셀룰러 네트워크 배포가, 또한 응급 서비스 인프라를 지원하기 위해 그다지 변경을 할 필요 없이, 자연적으로 회선 교환(CS) 서비스로부터 패킷 교환(PS) 서비스로 발전할 수 있게 한다. 게다가, 이러한 구현은 CS 도메인 및 PS 도메인 둘다에 걸쳐 있는 시스템의 다양한 단계에 적당하다.

일 실시예에서, 타이밍, 패키징 및 기타 목적을 위해 이미 RTP를 이용하고 있는 패킷 교환 음성(또는 다른 실시간 데이터) 연결이 이용된다. 구체적으로는, RTP 패킷 스트림이 RTCP(RTP Control Protocol)의 패킷과 함께 주기적으로 삽입되고, 이러한 RTCP 패킷은 수신 품질 및 소스 설명과 같은 파라미터를 포함하는 다른 참여자에 관한 관련 정보를 각각의 참여자에게 제공한다.

다른 변형에서, MSD 데이터 패킷에 대해 사용하기 위해, 신뢰할 수 있는 데이터 전송, 오류 정정, 재전송 및/또는 데이터 복원과 같은 패킷 교환 데이터 전송의 이점이 이용된다. 통상적으로 음성 데이터 스트림의 전위에 첨부하거나 후위에 첨부하도록 데이터 스트림을 연접하는, 데이터 전송을 음성과 함께 패키징하는 다른 방법과 달리, RTCP 프로토콜과 관련하여 "산재" 방식이 이용되며, 즉 데이터 스트림이 음성 스트림 내에 산재되고, 따라서 MSD의 지속적인 업데이트, MSD의 다중 재전송 등과 같은 특징이 실현될 수 있다.

다른 양태에서, 개시된 장치 및 방법은 상세하게는 셀룰러 네트워크의 기존의 프레임워크 내에서 동작하도록 구성된다. 셀룰러 네트워크에 의해 부과되는 한계를 고려하여, 표준화된 eCall 데이터 전송에 대한 타이밍 제약조건이 준수되어야만 한다. 유익하게도, 다양한 음성 코더 데이터(voice coder data) 및/또는 기술을 지원하기 위해 기존의 프로토콜 스택에 대한 어떤 수정도 필요하지 않다. 개시된 발명이 네트워크 구성요소에 의한 비음성 데이터의 수정을 가능하게 하는 반면, 본 시스템이 올바르게 동작하는 데 이러한 수정이 필요하지는 않다. 그러나, 보다 중요한 것은, 트랜스코딩 또는 기타 이러한 프로세스에 수반되거나 그에 의해 야기되는 오류를 방지하기 위해, 음성 데이터가 패킷화된 채로 있고 수정 없이 전송될 수 있다는 것이다.

또 다른 유익한 양태에서, 데이터의 라우팅은 관련 엔터티들[예를 들어, eCall과 관련하여 IVS(In-Vehicle System)와 PSAP] 사이에서 종단간 방식으로 행해지고, 데이터 라우팅을 위해 어떤 부가의 네트워크 구성요소 또는 저장 장치도 필요하지 않다. (일반적으로 앞서 기술한 "저장 및 전달" 동작 모드에 속하는) 데이터를 전송하는 데 사용되는 다른 방법과 달리, eCall을 보완하기 위해 전송되는 데이터는 타이밍 요구사항을 준수할 수 있고, (예를 들어, 사용자의 홈 네트워크로) 불필요하게 재라우팅되는 일 업이 즉각 전송될 수 있다.

예시적인 실시예의 상세한 설명

본 발명의 예시적인 실시예에 대해 이제부터 상세히 설명한다. 이들 실시예가 주로 예시적인 IVS(In Vehicle System)와 PSAP(Public Safety Answering Point) 사이에서의 통신과 관련하여 논의되고 있지만, 본 발명의 원리가 예시적인 IVS 및 PSAP의 시스템 이외의 시스템에서 적용될 수 있다는 것을 이해할 것이다. 예를 들어, 3G 휴대 전화와 같은 현세대 사용자 장비(UE)는 eCall 데이터를 수신측 장치(예컨대, E911 운영자)에 효과적으로 전달하는 데 필요한 정보를 발생할 수 있다.

게다가, 본 발명은 임의의 관할 또는 시스템(예를 들어, eCall 대 E911 등)으로 결코 제한되지 않으며, 말 그대로 이러한 어떤 상황에서도 이용될 수 있다.

또한, 주로 RTP(Real-Time Transport Protocol) 및 RTCP(RTP Control Protocol)[전체 내용이 참조 문헌으로서 본 명세서에 포함된, 2003년 7월자의 " RTP : A Transport Protocol for Real - Time Applications "라는 제하의 RFC 3550(됨)를 참조할 것]와 관련하여 기술되어 있지만, 본 발명의 다양한 실시예에서 다른 프로토콜로 용이하게 대체될 수 있고, 본 개시의 내용이 주어지면 다른 방식으로 당업자에게는 명백하게 될 것임을 이해할 것이다. 제한이 아니라 예로서, RTSP[전체 내용이 참조 문헌으로서 본 명세서에 포함된, 1998년 3월자의 " Real Time Streaming Protocol ( RTSP )"라는 제하의 RFC 2326를 참조], SRTP[전체 내용이 참조 문헌으로서 본 명세서에 포함된, 2004년 3월자의 " The Secure Real - time Transport Protocol ( SRTP )"라는 제하의 RFC 3711를 참조]), SCTP[전체 내용이 참조 문헌으로서 본 명세서에 포함된, 2007년 9월자의 " Stream Control Transmission Protocol"라는 제하의 RFC 4960를 참조], 및/또는 ZRTP[역시 전체 내용이 참조 문헌으로서 본 명세서에 포함된, 2008년 10월 25일자의 " ZRTP : Media Path Key Agreement for Secure RTP - draft - zimmermann - avt - zrtp -10"를 참조] 프로토콜이 본 발명에 따라 사용될 수 있다.

마지막으로, 본 발명의 특정 실시예가 자동차 또는 트럭과 같은 지상-기반 차량과 관련하여 기술되어 있지만, 본 발명이 결코 그것으로 제한되지 않으며, 레일(기차), 비행기, 선박 및 모터사이클을 포함하지만 이들로 제한되지 않는 다른 차량 또는 비차량 패러다임에 용이하게 적용될 수 있다.

방법

이제 도 2를 참조하면, 상위 우선순위 호출(예컨대, 이하에서 정의되는 "eCall")이 패킷 교환 네트워크에 의해 지원될 수 있도록, 음성 패킷 스트림이 산재되어 있는 데이터[예를 들어, MSD(minimum set of data)]를 전송하는 일반화된 프로세스(200)의 제1 실시예가 예시되어 있다. 본 명세서에서 사용되는 바와 같이, "상위 우선순위"라는 용어는 일반적으로 다른 트래픽보다 더 높은 긴급성 또는 우선순위를 갖는 호출 또는 기타 전송을 말하지만, 그것으로 제한되지 않는다. 상위 우선순위 호출의 한 예는 경찰, 화재, 의료 등의 지원에 대한 응급 호출이다. 상위 우선순위 호출의 다른 예는 높은 우선순위를 갖거나 통신 매체에 대한 액세스를 필요로 하는 법 집행 요원, 소방 대원, 군인, 정부 기관 등 또는 임의의 다른 개인 또는 그룹 간의 호출(심지어 일상적인 호출)에 관한 것일 수 있다.

"eCall"이라는 용어는, 본 명세서에서 사용되는 바와 같이, 그 중에서도, IM(IP Multimedia) 응급 서비스를 지원하는 데 필요한 요소를 포함하는 IMS(IP Multimedia Core Network Subsystem)에서의 응급 서비스에 대한 "단계 2" 서비스 설명을 기술하는, 전체 내용이 참조 문헌으로서 본 명세서에 포함된, "Technical Specification -3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 8)"라는 제하의 3GPP TS 23.167 V8.1.0(2008년 9월자)에 기술된 응급 호출 및 서비스를 제한됨이 없이 말한다. 전체 내용이 참조 문헌으로서 본 명세서에 포함된, ITU-T 권고안 I.130은 통신 서비스를 특징지우는 3-단계 방법을 기술하고 있고, 전체 내용이 참조 문헌으로서 본 명세서에 포함된, ITU-T 권고안 Q.65는 이 방법의 단계 2를 정의하고 있다. TS 23.167 V8.1.0는 또한 IMS 응급 서비스를 프로비전하는 데 중요한 액세스 네트워크 양태를 다루고 있다. IMS 응급 서비스에 관련되어 있는 다른 3GPP 규격은 TS 23.228(일반 IMS), 및 TS 23.234(3GPP/WLAN 연동을 기술함) 및 TS 23.271(위치 확인 서비스)을 포함하며, 이들 각각은 전체 내용이 참조 문헌으로서 본 명세서에 포함된다. 역시 전체 내용이 참조 문헌으로서 본 명세서에 포함된, TS 25.301은 UMTS 지상 무선 액세스 네트워크(UMTS Terrestrial Radio Access Network)에 대한 전체적인 설명을 포함한다.

IMS 응급 서비스에 관련되어 있는 다른 비3GPP 규격은 각각 앞서 전체 내용이 참조 문헌으로서 본 명세서에 포함된, 3GPP2 C.S0024-A 및 3GPP2 X.S0011에 규정되어 있는 3GPP2 cdma2000 HRPD IP-CAN을 포함한다.

프로세스(200)의 단계(202)에서, 상위 우선순위 호출이 행해진다. 한 예시적인 실시예에서, 호출은 클라이언트 또는 사용자 장치에 의해 자동으로 시작되고, 사건 탐지의 경우에 응급 호출을 자동으로 트리거하는 차량과 같은 응급 호출 상태를 할당받는다. 본 명세서에서 사용되는 바와 같이, "클라이언트 장치" 및 "사용자 장치"라는 용어는 휴대 전화, 스마트폰(예를 들어, iPhone™), iMac™, Mac Pro™, Mac Mini™ 또는 MacBook™과 같은 개인용 컴퓨터(PC), 및 데스크톱, 랩톱 또는 다른 것이든지 미니컴퓨터는 물론, 핸드헬드 컴퓨터, PDA, 비디오 카메라, 셋톱 박스, PMD(personal media device), IVS(in-vehicle system)와 같은 모바일 장치, 또는 이들의 임의의 조합을 포함할 수 있지만, 이들로 제한되지 않는다.

또 다른 변형에서, 지원을 요청하기 위해 응급 호출을 다이얼링하는 사용자와 같은 사용자에 의해 호출이 행해진다.

응급 상태가 호출에 할당되는 시점(및 그에 사용되는 메커니즘)은 호출을 하는 방법 또는 호출이 행해진 네트워크에 따라 달라질 수 있다. 한 변형에서, 응급 호출 상태는, 예컨대 이러한 상태를 나타내는 데이터(예를 들어, 소정의 값을 갖는 데이터 필드, 설정되어 있는 플래그 등)를 예컨대 메시지 헤더에 포함시키는 것에 의해, 발신측 당사자에 의해 즉각 플래깅된다. 대안의 경우에, 호출이 특수 호출로서 행해질 수 있다. 예를 들어, (전체 내용이 참조 문헌으로서 본 명세서에 포함된 3GPP TS 24.008에 따른) CS-응급 호출에서, 호출 제어 엔터티는 (보통의 호출을 위한 SETUP 메시지를 전송하는 것과는 달리) 호출을 설정하기 위해 EMERGENCY SETUP 메시지를 전송한다. (전체 내용이 참조 문헌으로서 본 명세서에 포함된 3GPP TS 24.229에 따른) 다른 예시적인 IMS-응급 호출에서, UE는 (전체 내용이 참조 문헌으로서 본 명세서에 포함된 RFC 5031에 규정되어 있는) 최상위-레벨 서비스 유형의 "sos"를 갖는 URN(Uniform Resource Name) 서비스를 사용한다. 또 다른 대안의 실시예에서, 연결의 라우팅 정보의 하나 이상의 구성요소는 응급 호출 상태를 결정하는 데 사용된다. 한가지 이러한 변형에서, 패킷이 그의 라우팅 정보(예를 들어, 911과 같은 지정된 번호를 다이얼링하는 사용자 또는 UE와 같은 소스 또는 목적지)로 인해 가로채기되고 응급 호출로서 취급되는 경우와 같이, 응급 호출 상태가 네트워크 엔터티에 의해 할당된다.

프로세스(200)의 단계(204)에서, 네트워크 액세스가 시작된다. 한 예시적인 실시예에서, 셀룰러 서비스에 대해 보통 사용되는 인증 및 허가 절차가 생략되거나 신속히 처리된다. 네트워크는 호출이 응급 상태를 부여받아야 한다는 표시를 IVS로부터 수신할 수 있거나, 네트워크는 라우팅 정보에 기초하여 호출이 응급 우선순위로 행해져야 하는지를 결정할 수 있다. 또한, 이러한 액세스는 "연결-기반"일 수 있거나, 대안으로서 "비연결"일 수 있다. 통상적인 전송 기술 중 임의의 것을 사용하여 이러한 네트워크 액세스가 시작될 수 있다. 본 명세서에서 사용되는 바와 같이, "전송"이라는 용어는, 예를 들어, TCP(transport control protocol), UDP(user datagram protocol), DCCP(datagram congestion control protocol), RTP/RTCP(real-time transport protocol/real-time transport control protocol), 및 SCTP(stream control transmission protocol)와 같은, 물리 인터페이스(PHY)를 통해 데이터를 전송할 수 있는 임의의 전송 프로토콜을 말한다. 이러한 네트워크 액세스는 이후부터 전송 스트림이라고 하며, 로컬 소스, 로컬 목적지, 체크섬 필드, 및 데이터 필드와 같은 데이터를 포함하는 하나 이상의 패킷을 최소한 포함한다. 로컬 소스는, 예시적인 실시예에서, IVS 네트워크 주소일 것이고, 로컬 목적지는 PSAP(반드시 라우팅 센터일 필요는 없음)의 주소일 것이다.

단계(206)에서, 실시간 프로토콜(예컨대, RTP, RTSP 등)이 설정되거나 전송 스트림 상에 계층화된다. 이하에서 더 상세히 기술되는 바와 같이, 이러한 실시간 프로토콜은, 해석될 때, 특정의 시간 및/또는 시간 지정 이벤트(예를 들어, 각자의 시간 값 또는 지수를 갖는 패킷)의 순서를 식별하는 정보를 최소한 포함한다.

프로세스의 단계(208)에서, 2개 이상의 "스트림"이 발생되고, 그 중 적어도 하나가 기계-판독가능 데이터 스트림이고, 그 중 적어도 하나가 음성 또는 다른 이러한 페이로드(사용자) 데이터의 디지털화된 표현이다. 본 명세서에서 사용되는 바와 같이, "스트림"이라는 용어는 실질적으로 연속적인 및 비연속적인(예를 들어, 주기적인 또는 간헐적인) 데이터 흐름 둘다를 말하는 데 사용될 수 있다.

이상의 프로세스의 한 구현에서, ACELP, QCELP, RCELP, LD-CELP(예를 들어, G.728) 등 중 하나와 같은 CELP(code-excited linear prediction)-기반 음성 코더(보코더)가 아날로그 마이크를 통해 수신되는 사용자의 음성을 디지털화하는 데 사용된다. 기계-판독가능 데이터 스트림은 다른 네트워크 구성요소에 의해 여전히 판독가능하고 기록가능한 반면, 음성의 디지털 표현은 다른 네트워크 구성요소에 의한 수정으로부터 보호된다.

프로세스의 단계(210)에서, 실시간 프로토콜을 사용하여, 네트워크를 통해 전송하기 위해 2개의 스트림이 산재된다. 구체적으로는, 한 변형에서, 기계-판독가능 데이터 스트림으로부터의 데이터가 하나 이상의 RTCP 패킷 내에 삽입되고, 이 RTCP 패킷이 이어서 사용자 데이터 패킷 스트림 내에 삽입되거나 산재된다(예를 들어, RTP 패킷은 상기한 디지털화된 음성을 전달함). 이 산재는 데이터 멀티플렉싱(예를 들어, 멀티플렉서 또는 인터리버가 하나의 데이터 스트림을 하나 이상의 다른 데이터 스트림 내에 분산시키는 데 사용되는 경우) 및/또는 피기백(예를 들어, 데이터가 기존의 스트림에 첨부되거나 다른 방식으로 부착되는 경우)과 같은 방법을 비롯한, 디지털 기술 내에 통상적인 임의의 수의 방식을 사용하여 달성될 수 있다.

단계(212)에서, 기계-판독가능 데이터 및 음성의 디지털 표현의 조합을 포함하는 산재된 스트림을 전달하는 세션이 시작된다. 예를 들어, SIP(본 명세서에 나중에 기술됨)와 같은 세션-기반 프로토콜을 비롯한 다양한 메커니즘이 이 세션을 설정하는 데 사용될 수 있다. 이 세션은 단일 네트워크 연결을 통해 수행되고, 여기서 네트워크 경로는 소스 종단점(IVS) 및 목적지 종단점(PSAP)에 의해 특징지워진다. 네트워크 내의 경로가 복수의 전송 계층 연결 사이의 "홉"을 사용하여 구성될 수 있지만, 이 경로는 기계-판독가능 데이터 및 음성의 디지털 표현 둘다에 대해 여전히 동일하다. 즉, 종단점들 사이의 경로가 변할 수 있지만, 기계-판독가능 데이터 및 디지털화된 음성 또는 기타 "페이로드"에 대해 항상 동일할 것이다.

게다가, 다중-스트림 세션이 실시간으로 수행되고, 음성 및 데이터 둘다가 응급 호출 상태 처리의 이득을 본다.

PSAP에서 수신 시에, 2개 이상의 데이터 스트림이 디멀티플렉싱, ID 그리고 따라서 각각의 패킷이 어느 스트림에 속하는지를 나타내는 그의 헤더에 존재하는 데이터에 기초하여 패킷(예를 들어, RTCP 패킷 대 RTP 패킷)을 라우팅하는 것, 또는 또 다른 공지된 메커니즘을 통하는 등에 의해 분리된다. 적어도 부분적으로 IVS에 관련된 하나 이상의 파라미터를 결정하기 위해 기계-판독가능 데이터 스트림이 처리된다. 음성의 디지털 표현이 통신 사업자 또는 음성 인식 시스템에 분배, 저장, 및/또는 재생을 위한 가청 신호로 재구성된다.

예시된 실시예가 디지털화된 음성과 관련하여 기계-판독가능 데이터 스트림을 이용하지만, 스트림의 보조 성분이 디지털화된 음성이 아니고 다른 유형의 디지털화된 콘텐츠(예를 들어, 비디오, 파일 데이터 등과 같은 다른 미디어)인 경우에도 본 발명이 똑같이 성공적으로 실시될 수 있고 본 발명이 음성 데이터로만 제한되지 않는다는 것을 이해할 것이다. 예를 들어, IVS 시스템 장치 또는 센서(본 명세서에서 나중에 더 상세히 기술됨) 중 하나가, 원하는 경우, PSAP로 전송될 수 있는 이미지 또는 비디오 데이터의 패킷 스트림을 발생할 수 있는 카메라를 포함할 수 있다.

차량이 도단되는 경우와 같이 음성 및/또는 비디오가 수동으로 또는 사용자 몰래 획득될 수 있고 온-보드 마이크 및/또는 카메라가 도둑 몰래 음성/비디오 데이터를 PSAP 또는 기타 엔터티로 스트리밍하는 데 사용된다는 것에 또한 유의한다.

게다가, 본 발명의 특정 실시예에서, 심지어 RTP-콘텐츠 없이 RTCP를 사용하는 것이 가능할 수 있다. 이러한 실시예가, 예를 들어, 자동으로 시작되도록 설계되고 이벤트(예를 들어, VIN, AGPS에 의해 확인되는 차량 위치 등을 전송하는 도난 탐지 및 보고 시스템)에 관련된 소정의 데이터만을 전송하는 호출과 같이, "페이로드" 자체 없이 실시될 수 있다.

게다가, 임의의 "페이로드"의 통신은 무선(예를 들어, 셀룰러) 시스템 내에서의 한 예시적인 M2M 구현에 대해 M2M(machine-to-machine) 다양성을 가질 수 있으며, 예를 들어, 전체 내용이 참조 문헌으로서 본 명세서에 포함된 2008년 8월 29일자로 출원된, 발명의 명칭이 "Methods and Apparatus for Machine-to-Machine Based Communication Service Classes"인 공동-소유의 동시 계류 중인 미국 특허 출원 제12/231,095호를 참조하기 바란다. 또한, M2M 데이터 통신이 본 발명에서의 "페이로드"의 기초를 제공할 수 있는 반면, 또한 주어진 호출을 "응급"(또는 보다 일반적으로 상위 우선순위) 및 "M2M" 둘다로서 분류하는 것이 이상의 개시 내용에 기술된 유형의 상이한 호출 처리 및 라우팅 결정의 기초로서 사용될 수 있다는 것을 이해할 것이다. 예를 들어, 성질상 M2M 및 "응급" 둘다인 호출은 사람-기반 호출보다 낮은 우선순위를 부여받을 수 있는데, 그 이유는 기계(즉, 호출의 발신기)와 연관된 응급이 사람 목숨을 구하는 것보다 낮은 우선순위를 갖는 것으로 가정되기 때문이다. 그러나, 호출을 시작하는 M2M "기계"가 사람의 목숨에 악영향을 줄 수 있는 중요한 인프라, 예를 들어, 대도시 지역 또는 병원과 연관된 배전소 변압기, 임박한 고장을 나타내는 교량 응력/변형 센서 등과 연관된 것인 경우와 같이, 항상 이러하지는 않을 수 있다. 따라서, 본 발명은 RTCP 또는 유사한 패킷에 삽입된 데이터 부분 뿐만 아니라 M2M 데이터(즉, 시작측 기계의 부모 장치에 관련된 시작측 기계에 의해 발생되고 RTP 또는 "페이로드" 패킷 내에 삽입됨)는 호출 처리, 우선순위 부여, 및/또는 라우팅을 구별하기 위한 기초로서 사용될 수 있다.

이제 도 2a를 참조하여, CS 도메인 네트워크와 PS 도메인 네트워크 사이에서 중재하고 선택하는 방법의 일 실시예가 기술된다. 본 발명이 특히 패킷 교환 네트워크 도메인에 걸쳐 동작하도록 구성된다는 것을 이해할 것인 반면, 그럼에도 불구하고 CS-도메인 서비스도 이용가능한 경우가 있을 수 있다. 따라서, 항상 단순히 PS-도메인 전송을 기본으로 하기보다는, 본 발명의 다른 변형은 한 도메인 또는 다른 도메인을 사용하여 응급 호출을 하기로 결정하기 전에 선택 또는 중재 논리를 이용한다. 이 논리는, 예를 들어, 네트워크 장치(예를 들어, 호출 라우팅 제어기) 상에 또는 클라이언트 장치(예를 들어, IVS) 자체 내에 또는 둘다에 구현될 수 있다.

도 2a에 도시된 바와 같이, 방법(250)의 제1 단계(252)는 회선 교환 및 패킷 교환 네트워크 경로 둘다가 호출을 라우팅하는 데 이용가능한지를 판정한다. 이 데이터는 하드-코딩될 수 있거나(예를 들어, 네트워크 인프라에 기초하고 따라서 변하지 않음), 대안으로서 하나 이상의 상태 표시기에 기초할 수 있다. 예를 들어, 회선 교환 전송이 네트워크 인프라의 일부로서 포함될 수 있지만, 그 전송이 (예를 들어, 유지 관리, 장비 고장, 또는 아주 높은 부하/혼잡으로 인해) 현재 이용가능하지 않을 수 있다.

단계(254)에 따라, CS-도메인 및 PS-도메인 둘다가 이용가능한 경우, 선택 논리는 그 다음에 경로들 중 적어도 하나의 경로를 적어도 하나의 선택 기준에 대해 평가한다(단계 256). 예를 들어, 한 변형에서, 이들 경로 둘다가 (늦게 도착하는 패킷과 같은 PS 도메인에서 패킷 전송과 연관된 대기시간 또는 CS 도메인에서 종단간 회선을 설정하는 데 있어서의 긴 지연으로 나타내어질 수 있는) 혼잡이 있는지 평가된다. 대안으로서, 이 평가는 계층적 방식을 이용하는 것을 포함할 수 있고, 예를 들어, 혼잡이 있는지 PS 도메인만을 평가하고, 이어서 만족스러운 경우, PS 도메인을 사용하고 그렇지 않은 경우 CS 도메인을 사용한다. 예를 들어, 혼잡/대기시간, 신뢰성, 이용가능한 데이터 기능/페이로드 등 2개 이상의 평가 기준이 또한 사용될 수 있다. 수많은 상이한 평가 방식 및 기준이 본 개시 내용이 주어진 경우 당업자라면 이해할 것이다.

단계(258)에 따라, 2개의 경로 중 하나(또는 둘다)가 (호출의 우선순위 및 잠재적인 신뢰성/대기시간 문제에 따라) 단계(256)의 이상의 평가에 기초하여 선택되고, 호출이 단계(260)에 따라 선택된 도메인(들)을 통해 라우팅된다.

도 2 및 도 2a의 이상의 예시적인 방법은 앞서 언급한 기존의 데이터 전송 해결 방안[즉, SMS(Short Message Service), UUS(User to User Signaling), USSD(Unstructured Supplementary Service Data), GSM(Global Systems for Mobile communications) CS 데이터, DTMF(Dual-Tone Multi-Frequency), 및 대역내 모뎀/시그널링 응용)에 대한 본 발명의 이점들 중 다수를 강조하고 있다. 구체적으로는, SMS는 한 단말기로부터 다른 단말기로의 셀룰러 네트워크를 통한 140 바이트 메시지의 신뢰할 수 없는 전송을 사용한다. SMS 메시지는 네트워크 리소스의 더 나은 관리를 용이하게 하기 위해 저장 및 전달 시스템을 사용하여 네트워크에서 처리되지만, SMS의 한가지 주된 단점은 단문 메시지가 사용자의 홈 네트워크의 SMS 센터로 라우팅되는 반면, eCall이 바람직하게는 (로밍 가입자를 가능하게 하기 위해) 방문된 네트워크 내에서 처리되어야 한다는 것이다. eCall을 시작하는 로밍 사용자는 현재 그의 SMS가, 전달 이전에 저장하기 위해, 그의 홈 네트워크로 라우팅된다. SMS 라우팅의 간접적인 처리는 다른 eCall 메커니즘과의 통합을 위해 상당한 수정을 필요로 한다. SMS의 다른 단점은 그의 비교적 신뢰성없는 서비스이고, SMS가 전달을 보장하지 않으며 전달 시간을 규정하지 않고, 수신자로부터 송신자로의 피드백이 선택적이고, 적시이거나 신뢰할 수 있는 것이 아닐 수 있다. 마지막으로, SMS는 인증을 위해 모바일 장치 내에 존재하는 SIM(Subscriber Identity Module)에 의존한다. 이들 단점 각각은 유리하게도 본 명세서에 개시된 기술에 의해 극복된다.

유사하게, UUS는 호출 설정 동안에 또는 그 직후에 작은 데이터 부분의 사용자간 시그널링(user-to-user signaling)을 가능하게 하는 다른 서비스이다. UUS는 전송되는 데이터의 양을 제한한다. 어떤 UUS 유형에서, MSD가 아주 제한적인 32 바이트로 감소될 필요가 있을 것이다. 게다가, 통신 사업자는 널리 배포된 UUS를 갖고 있지 않으며, 현재의 네트워크 장비에 대한 업그레이드가 비용이 많이 들고 어려울 것이다. UUS는 호출 제어 프로토콜의 일부로서 구현되는 서비스이고, CS 도메인 호출에서 또는 ISDN(Integrated Services Digital Network)과 같은 고정 회선 프로토콜에서만 이용가능하다. PS 도메인에서, 이는 현재 이용가능하지 않으며, 현재의 네트워크 통신 사업자는 명시적으로 응급 호출에 대해 UUS를 허용하지 않는다.

USSD는 UUS와 유사한 표준이고, 몇가지 유사한 특징을 가진다. USSD는 180 바이트 이상의 정보의 전송을 가능하게 한다. USSD는 독립적으로 또는 언제라도 진행 중인 호출을 보충하도록 동작할 수 있다. UUS 및 SMS와 거의 유사하게, USSD 전송은 홈 네트워크로 라우팅되고, 따라서 로밍 동안 eCall 처리를 위한 USSD에 대한 수정은 eCall을 방문된 네트워크로 재라우팅해야만 한다. USSD는 현재, UUS와 같이, 응급 호출에 사용하는 데 금지되어 있다. USSD는 또한 CS 도메인 프로토콜의 일부로서 구현되고, 셀룰러 네트워크에서 CS 도메인 호출에서만 이용가능하다(PS 도메인에서는 이용가능하지 않음).

eCall 동작에 적당하지 않은 다른 레거시 회선 교환 데이터 전송 기법은 GSM CS 데이터 및 DTMF(Dual Tone Multi Frequency)를 포함한다. GSM CS 데이터는 CS 도메인에서 9.6 kbps 데이터 전송률로 동작할 수 있다. 안타깝게도, GSM CS 데이터 호출에 대한 설정 시간은 eCall 서비스의 요구사항을 초과하고, GSM CS 데이터는 CS 도메인 내에서만 동작할 수 있다(GSM은 CS 기반 네트워크임). DTMF는 MSD를 아주 느리게 전달하는 데 실시가능하게 사용될 수 있지만, 180 바이트를 전송하는 데 36초보다 많이 소요될 것이다. 게다가, DTMF는 신뢰할 수 없으며, 오류 정정을 제공하지 않는다.

대역내 모뎀 시그널링이 현재 사용되는 방법이고, 미국에서 사용되는 OnStar™ 시스템에서 얼마간의 상업적 성공을 거두었다. MSD는 설정 음성 연결을 사용하여 호출의 시작에서 대역내로 전송된다. 따라서, 라우팅 및 어드레싱이 네트워크에 대한 문제가 아니며, MSD가 PSAP(Public Safety Answering Point)에 의해 항상 수신된다. 안타깝게도, IVS 단말기는 물론 PSAP 둘다가 MSD 데이터를 음성 스트림으로부터 디코딩하는 데 얼마간의 노력이 소요될 수 있다. 또한, 특정 네트워크에서, 네트워크는 IVS와 PSAP 사이의 지원되는 음성 코덱이 잠재적으로 불일치할 수 있기 때문에 음성 데이터를 하나의 음성 코덱으로부터 다른 음성 코덱으로 트랜스코딩해야만 한다. 이 트랜스코딩 프로세스는 eCall MSD 데이터 부분 내로 오류를 유입시킬 수 있거나, 트랜스코딩이 음성 스트림 내에 삽입된 인식되지 않는 데이터 전송 아티팩트를 생성하는 경우 심지어 완전히 실패할 수 있다.

이상의 내용에 기초하여, 레거시 및 종래의 방식에 대한 본 명세서에 개시된 기술의 많은 이점이 곧바로 명백하다.

RTCP APP 패킷 프로토콜

한 예시적인 구현에서, 본 발명은 전송될 데이터[예를 들어, MSD(Minimum Set of Data)]를 eCall 음성 연결 내에서 전송되는 RTCP(RTP Control Protocol) 패킷 내에 배치하는 것을 생각하고 있다. RTCP 패킷의 타이밍 및 빈도수가, 그 중에서도, 전체 내용이 참조 문헌으로서 본 명세서에 포함된 "RTP, Audio and Video for the Internet" Colin Perkins; Addison-Wesley, 2003 ISBN 0-672-32249-8 2003 및 앞서 본 명세서에 포함된 RFC 3550에 기술되어 있다.

대부분의 RTP 구현은 얼마간의 사소한 오버헤드를 필요로 한다. 구체적으로는, 수신기에서의 수신 품질에 관한 어떤 정보가 송신자가 실시간으로 효율적으로 전송하는 데 사용될 수 있다. 또한, 수신기는 세션의 다른 참여자에 관한 정보를 필요로 할 수 있으며, 이러한 정보는, 예를 들어, 다른 참여자가 송신자인지, 수신자인지 또는 둘다인지에 관한 예시적인 상세를 포함할 수 있다. 제어 데이터는 또한 주기적으로 전달되고, 연관된 RTCP(RTP Control Protocol)는 이 부가의 제어 정보가, RTP-삽입된 사용자 데이터 패킷의 스트림 내에, 삽입된 데이터로서 언제 어떻게 주입되는지를 정의하고 기술한다. 따라서, RTCP는, 다른 대안과 비교할 때, 패킷의 수 및 전송되는 데이터의 양을 증가시킨다. 그러나, RTCP 시그널링은 보통 실시간 스트림의 총 데이터 대역폭의 5% 미만을 소모한다.

IVS와 PSAP 사이에서 12.8 kbps로 동작하는 양방향 음성 연결에서, RTCP 패킷이 대략 매초 한번씩 전송될 것으로 예상될 수 있다. 연결의 시작에서, 제1 RTCP 패킷은 이 구간(0.5 초)의 절반 후에 전송될 것이다.

RTCP는 다음과 같은 5가지 패킷 유형을 정의한다: (1) 수신자 보고, (2) 송신자 보고, (3) 소스 설명, (4) 멤버쉽 관리, 및 (5) 응용 프로그램-정의(APP) 패킷 유형. 처음 4개의 패킷 유형이 정의된 구조를 갖고 패킷 구조의 확장을 허용하지 않는 반면, APP 패킷 유형이 응용 프로그램-관련 정보를 수용하도록 유연하게 정의된다. 그에 따라, 본 발명의 한 예시적인 실시예에서, IVS(In Vehicle System)로부터 PSAP(Public Safety Answering Point)로 MSD를 전송하기 위해 RTCP APP 패킷 유형이 이용된다.

이제 도 3을 참조하면, 종래 기술의 RTP APP 패킷(300)은 다수의 정보 요소로 이루어져 있다. 구체적으로는, 제1 정보 요소(302)는 프로토콜의 버전 [V]을 식별하고, RTP 및 RTCP 프로토콜의 현재 버전에서, 이 값이 통상적으로 2(이진값으로 10#b로 표현됨)로 설정될 것이다. 제2 정보 요소(304)는 이 개별 RTCP 패킷이 제어 정보의 일부는 아니지만 길이 필드에 포함되는 어떤 부가의 패딩 옥텟(padding octet)을 포함하는지를 식별하는 패딩 비트 [P]이다. 패딩의 마지막 옥텟은 몇개의 패딩 옥텟이 무시되어야 하는지의 카운트이다. 예를 들어, RTP APP 패킷(300)이 8 옥텟인 경우, 마지막 옥텟은 비트 56 내지 63을 포함한다. 다른 예에서, 길이가 12 옥텟인 경우, 마지막 옥텟은 비트 88 내지 95를 포함한다.

제3 정보 요소(306)가 일련의 APP 패킷이 하나의 고유 이름 하에서 또는 임의의 응용 프로그램-의존적인 데이터에 대해 정의될 수 있게 하기 위해 서브유형으로서 사용될 수 있는 서브유형 [서브유형]이다.

제4 정보 요소(308)는, 이 예에서, 값 [204](이진값으로 11001100#b로서 표현됨)로 나타내어지는 RTCP APP 패킷을 나타내는 패킷 유형 [PT]이다.

제5 정보 요소(310)는 헤더와 임의의 패딩을 포함하는 32-비트 워드에서의 RTCP 패킷의 길이 필드 [길이] - 1이다.

제6 정보 요소(312)는 동일한 사람에 의해 정의되고 및/또는 동일한 목적을 위해 사용되는 일련의 RTCP APP 패킷을 정의하는 이름 필드 [이름]이다.

제7 정보 요소(314)는 응용 프로그램에 의해 사용되는(즉, RTCP APP 처리에 의해 사용되지 않는) 제한이 없는 필드인 응용 프로그램-의존적 데이터 [응용 프로그램-의존적 데이터]이다. 응용 프로그램-의존적 데이터 길이에 대한 한가지 특정의 요구사항은, 32-비트 워드 경계와 정확하게 들어맞도록, 그 길이가 32 비트의 배수이다.

이제 도 3a 내지 도 3d를 참조하면, 본 발명에 따른, eCall 데이터를 삽입하는 데 사용되는 예시적인 RTP APP 패킷(350) 형식의 다양한 실시예가 예시되어 있다. 도 3의 종래 기술의 패킷과 유사하게, 제1 정보 요소(352)는 프로토콜의 버전 [V]을 식별하고, RTP 및 RTCP 프로토콜의 현재 버전에서, 이 값이 통상적으로 2(이진값으로 10#b로 표현됨)로 설정될 것이다.

마찬가지로, 제2 정보 요소(354)는 이 개별 RTCP 패킷이 제어 정보의 일부는 아니지만 길이 필드에 포함되는 어떤 부가의 패딩 옥텟을 포함하는지를 식별하는 패딩 비트 [P]이다.

제3 요소는 서브유형 필드(이하에서 더 상세히 기술됨)이다.

제4 정보 요소(358)는, 이 예에서, 값 [204](이진값으로 11001100#b로서 표현됨)로 나타내어지는 RTCP APP 패킷을 나타내는 패킷 유형 [PT]이다.

제5 정보 요소(360)는 헤더와 임의의 패딩을 포함하는 32-비트 워드에서의 RTCP 패킷의 길이 필드 [length] - 1이다.

도 3a 및 도 3b는 RTCP APP 패킷 유형의 예시적인 실시예를 나타내고 있다. 기존의 RTCP APP 패킷 형식(350)을 최적으로 사용하기 위해, 이름 필드(362)(도 3a) 내에 모든 eCall-정의 패킷을 공통의 문자열 값(예를 들어, "eCal")을 유지한다. 또한, eCall 서비스에 대해 정의된 서브유형 필드(356) 값은 MSD(Minimum Set of Data), FSD(Full Set of Data) 등과 같은 상이한 데이터 형식을 구별할 수 있다. 대안으로서, 다른 구현은, 이름 필드(362)에서, eCall에 관련되어 있는 패킷 및 패킷에 포함된 데이터의 유형 둘다를 나타낼 수 있다. 서브유형 필드(356)는 이어서, 예를 들어, MSD 또는 FSD의 처음 5 비트와 같은 다른 목적을 위해 사용될 수 있다(도 3b에 도시됨).

RTP 및 RTCP는, 본 실시예에서, 앞서 기술한 바와 같이, (TCP와 달리) 송신된 패킷이 정확하게 수신되었다는 것을 송신자에게 보장하지 않는 UDP 전송 프로토콜을 통해 전송된다. 특정 상황에서, 수신자에 의한 ACK(acknowledgement), 즉 (i) 패킷이 손상되지 않고 적시에 수신되었다는 것 또는 (ii) (예를 들어, 패킷이 오염되거나, 늦거나, 누락되었다는) 실패 모드(failure mode)를 제공하는 것이 바람직할 수 있다. 한 예시적인 실시예에서, 수신자에 의한 성공적인 수신을 확인 응답하는 데 RTCP APP 패킷이 사용될 수 있다. (도 3a 내지 도 3d에 나타낸 바와 같이) RTCP APP 패킷의 임의의 것에서, RTCP 형식은 서브유형 필드 값(356) 또는 적절한 이름 필드 값(362)을 정의함으로써 확인 응답을 용이하게 전달한다는 것에 유의한다.

이제 도 3c 및 도 3d를 참조하여, 또 다른 대안의 실시예에서, eCall 데이터의 수신자(예를 들어, PSAP)는, 2개 이상의 메시지가 송신자(예를 들어, IVS)에 의해 송신되는 경우, 특정의 eCall 데이터 메시지를 확인 응답할 수 있다. 서브유형 필드(356) 내의 패킷 번호의 추가 및 패킷 번호를 적절한 확인 응답 메시지에 상관시키는 참조는 따라서 다수의 메시지의 적절한 순차적 수신 및 구별을 가능하게 할 것이다. 패킷 번호의 전송은, 예를 들어, eCall 데이터 패킷 또는 그의 대응하는 확인 응답 패킷에 대한 도 3c에 도시된 바와 같은 서브유형-필드(356)를 통해 달성될 수 있다. 대안으로서, 패킷 번호는 도 3d에 도시된 바와 같은 응용 프로그램-관련 데이터 필드(364)에 포함될 수 있다.

부가의 실시예에서, PSAP는 IVS에 eCall 데이터의 업데이트를 요청하는 기능을 가질 수 있다. 업데이트 메시지는 확인 응답 패키지와 유사한 형식(또는 PSAP로부터 IVS로 전송하도록 되어 있는 임의의 패킷 유형)으로 구성될 수 있다. 업데이트 요청은 또한 업데이트되어야 하는 정보를 지정하는 표시를 포함할 수 있고, 이러한 업데이트는, 예를 들어, 특정의 동적 조건을 폴링하는 데 사용될 수 있다. 한 이러한 변형에서, 오버헤드를 감소시키기 위해 요청된 정보(또는 마지막 업데이트 이후로 변경된 정보)만이 전송된다. 게다가, 이 정보는 응용 프로그램-관련 데이터 필드(364) 또는, 원하는 경우, 다른 위치 내에 캡슐화될 수 있다.

또 다른 구현에서, 140 바이트의 데이터를, 제1 RTCP 패킷으로 전송되는 제1 부분 및 제1 부분과 별개인 하나 이상의 RTCP 패킷으로 전송되는 제2 부분으로 분할함으로써 eCall 데이터의 지정된 부분에 대한 보다 빠른 전송 요구사항이 수용될 수 있다. 제1 및 제2 데이터 길이의 임의의 조합이 이용될 수 있다. 한 이러한 예에서, 제1 패킷은 전체가 38 바이트보다 크지 않는 MSD의 처음 5개 정보 요소를 포함할 수 있고, 제2 부분은 크기가 최대 106 바이트인 나머지 부분을 포함할 수 있다. 보다 작은 제1 패킷은 아주 신속하게 전송되고, 제2 나머지 패킷은 IVS에 의해 스케줄링되는 그 다음 RTCP 전송에서 전송될 수 있다.

게다가, 논의된 이전의 실시예에 부가하여, 2개 이상의 eCall 메커니즘을 지원하는 셀룰러 이동 네트워크는 또한 어느 eCall 메커니즘이 이용되어야 하는지를 나타내기 위해 다양한 메시징 형식을 지원할 수 있다. 특정의 eCall 세션에 대해 어느 메커니즘이 적용가능한지를 식별하기 위해, 이러한 표시가 호출 설정 동안에 행해질 것이다.

대안으로서, 메커니즘의 협상은 또한 호출 설정 동안에 행해질 수 있다. 세션 정보를 기술하고 초기화하는 데 사용되는 한가지 보편적인 프로토콜은 공지된 SIP(Session Initiation Protocol)이다. IMS(IP-based Multimedia Core-Network Sub-System)는 SIP에 기초한 네트워크 아키텍처이고, IMS는 이동 셀룰러 네트워크에서 세션 설정, 조작 및 종료의 방법을 정의한다. 구체적으로는, PS 도메인 호출은 통상적으로 임의의 실제의 데이터를 전송하기 전에 SIP를 사용하여 IMS-프레임워크 내에서 협상되고 설정된다. 그 중에서도, 전체 내용이 참조 문헌으로서 본 명세서에 포함된, "Technical Specification - 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 8)"라는 제하의 3GPP TS 23.228 V8.6.0 (2008-09)를 참조하기 바란다. SIP 내에서, SDP(Session Description Protocol)는 주어진 세션과 연관된 파라미터를 정의하는 데 사용된다.

SIP 프레임워크 내에서, 어느 eCall 데이터 시그널링 메커니즘이 사용되는지를 나타내기 위해 세션 설명에 "a-라인"(속성 라인)을 추가하는 것이 가능하다. 예를 들어, 2가지 지원되는 형식(예를 들어, RTCP를 통한 대역내 시그널링 및 음성 코덱)이 이용가능한 시스템에서, 2개의 개별적인 스트림 유형이 적절한 a-라인 기술자로 표시될 수 있다.

a=eCallDataTxMechanism:InBandRTCP

a=eCallDataTxMechanism:InBandVCodec

적절한 응답이, 예를 들어, 네트워크 내에 존재하는 선택 논리에 기초하여 2가지 스트림 옵션 중 하나를 선택할 것이다. 이 선택은, 예를 들어, 호출측 장치, 네트워크 최적화 또는 동작 기준, 대기시간 등의 고유 기능에 기초할 수 있다.

그러나, 특히 SIP와 관련하여, 1차 SIP RPC(RFC 3261)가 리소스 우선순위화를 지원하지 않지만, 호출 우선순위화와 관련하여 SIP의 기능을 확장하도록 구성된 보충 RFC[전체 내용이 참조 문헌으로서 본 명세서에 포함된, 2006년 2월자의 "Communications Resource Priority for the Session Initiation Protocol (SIP)" 제하의 RFC 4412]가 있다는 것에 유의한다. 구체적으로는, RFC 4412는 장치가 호출이 다운스트림 요소에 의해 "상위 우선순위"로 취급되도록 요청할 수 있는 2개의 새로운 SIP 헤더 필드를 정의한다.

예

이하의 예는 또한, 음성 및 대역내 시그널링 데이터 스트림 둘다를 이용하여 eCall을 시작하고 처리하는 데 사용되는, 상기한 RTCP APP 프로토콜의 패킷 구조 및 메시징 형식의 한 예시적인 구현을 설명하고 있다.

일 실시예에 따르면, 패킷 교환 호출을 시작하기 위해, IVS(In Vehicle System)는 기지국과의 통신을 설정한다. 특정 다중-모드 시스템에서, (예를 들어, CS 및 PS 네트워크 둘다가 중복하거나 양쪽 기능이 이용가능한 경우와 같이) IVS는 그 자신을 패킷 교환 장치라고 밝힐 필요가 있을 수 있다. 기지국은 IVS에게 전용의 물리 트래픽 리소스(예를 들어, 시간 슬롯, 주파수 대역, 코드 도메인 등) 및 논리 채널을 제공한다. 논리 채널의 할당은 IVS가 할당된 전용의 물리 트래픽 소스를 통해 전송되는 논리 채널을 통해 IMS(IP-based Multimedia Core-Network Sub-System)와 통신할 수 있게 한다.

IVS는 SIP(session initiation protocol)를 사용하여 PSAP와의 호출을 시작한다. 음성 또는 eCall 데이터가 설정된 세션을 통해 교환될 수 있기 전에, 도 4에 예시된 유형의 메시지 교환이 행해져야만 한다. 도 4에 나타낸 메시징에서, SIP 메시지의 모든 내용이 보다 명백한 설명을 위해 상세히 제공되어 있지 않다는 것에 유의한다.

도 4의 예시적인 교환에서 나타낸 바와 같이, IVS는 연관된 IP 및 UDP 헤더를 갖는 IP 패킷 내에 캡슐화되어 있는 초기 SIP INVITE 요청(402)을 전송한다. SIP INVITE 요청은 호출되는 단말기(예를 들어, PSAP)의 목적지 주소를 포함하고, 호출된 단말기가 호출 세션(예를 들어, eCall)에 참여하도록 초대되어 있다는 것을 나타낸다. 도 4는 또한 본 명세서에서 앞서 기술된 SIP INVITE 메시지의 세션 설명 내에서 이용되는 커스텀 "a-라인"을 나타내고 있다. 도 4의 예시적인 SIP INVITE는, 본 발명의 원리에 따른, 대역내 음성 코덱 시그널링 또는 대역내 RTCP에서와 같이, 응급 관련 데이터를 전송하기 위한 상기한 a-라인 둘다를 포함한다.

통상적으로, 기지국은 액세스 제어, 허가 및 과금을 위해 다양한 엔터티로 INVITE 요청을 전송할 것이다. eCall 상황에서, 네트워크 엔터티는 액세스, 허가 및 과금 단계 중 일부 또는 전부를 선택적으로 건너뛰거나 선점할 것이다. 이 선택은 또한 호출의 유형 또는 우선순위에 기초하여 동적으로 변화될 수 있고, 예를 들어, "응급" 호출은 건너뛴 상기한 단계들 모두를 가질 수 있지만, 상위-우선순위이지만 비응급 호출은 특정의 목적을 달성하기 위해 이들 단계 중 일부를 이용할 수 있다(예를 들어, 상위-우선순위 법 집행부간 전송은 "스푸핑" 또는 유사한 공격이 일어나지 않도록 인증을 이용할 수 있다).

SIP RINGING 응답(403)은, PSAP가 위치 확인되고 INVITE 요청을 수신하면, 선택적으로 PSAP로부터 반환될 수 있다.

eCall이 PSAP에 의해 수신된 경우, PSAP는 SIP 200 OK 응답(404)을 반환한다. 200 OK 응답(404)이 수신되면, IVS는 OK 응답을 확인 응답하기 위해 SIP ACK 메시지(406)를 전송한다. 200 OK(404)는 PSAP가 선택한 양쪽 옵션으로부터의 선택을 포함한다. 도시된 바와 같이, PSAP는 RTCP 시그널링을 선택하였다. 이 시점에서, 호출이 설정되고, 산재된 음성 및 기타 실시간 데이터의 통신이 진행할 수 있다.

MSD 데이터의 전송

이제 도 5를 참조하면, 세션 설정이 완료된 후에(예를 들어, 도 4의 SIP 교환이 음성 및 데이터 성분을 갖는 세션을 성공적으로 중재한 후에), IVS와 PSAP 사이의 예시적인 메시징 흐름(500)이 수행될 수 있다. 502a, 502b에서 코딩된 음성 프레임을 포함하는 RTP 패킷을 전송함으로써 음성 데이터의 교환이 시작된다. 나중에 스케줄링된 시각(T₁)에서, 단계(504)에 따라 제1 RTCP 패킷이 전송된다. 이 패킷은, 일 실시예에서, 도 3a 내지 도 3d와 관련하여 본 명세서에서 앞서 기술된 바와 같이, RTCP APP 패킷(350)을 포함한다.

본 발명의 한 예시적인 실시예에서, 이하의 정보 요소는 단계(504)에서 전송된 제1 RTCP APP(2) 패킷에 설정되어 있다: (i) 이름(362) = eCal, (ii) 서브유형(356) = MSD-Data, 및 (iii) 패킷번호(응용 프로그램 관련 필드(364)의 처음 8 비트 = 0(영). 응용 프로그램 관련 필드(364)의 나머지는 나머지 MSD를 포함한다.

제1 RTCP APP (2) 패킷이 발생된 후에, 추가의 RTCP 패킷이 후속 구간에서 생성된다. 이들 구간은, 일 구현에서, 사실상 주기적이지만, 패킷이 꼭 그러해야 한다는 특정의 요구사항은 없다. 시각(T₂)의 규칙적인 구간을 이용하는 것은 IVS와 PSAP 사이의 RTCP 패킷의 처리를 단순화시킬 것이다. 주기적인 RTCP 패킷 전송 사이에서, 단계(502c, 502d, 502e 등)에 나타낸 바와 같이, RTP 음성 패킷은 계속하여 전송될 수 있다.

예시된 실시예에서, PSAP로부터의 성공적인 수신의 확인 응답이 수신되는 때와 같은 시점까지 발생된 RTCP 패킷은 eCall 데이터에 대한 APP 패킷을 포함한다. 도 5에 도시된 바와 같이, 504에서 PSAP는 제1 RTCP APP (2) 패킷을 수신하고, 단계(506)에서 PSAP는 제1 RTCP APP (2) 패킷을 수신한 것에 응답하여 성공적인 수신을 확인 응답하기 위해 RTCP APP (3) 패킷을 발생한다. RTCP APP (3) 패킷(ACK)은 다음과 같은 설정된 본 발명의 정보 요소와 함께 전송된다: 이름(362) = "eCal", 서브유형(356) = ACK, 패킷 0을 확인 응답하는 패킷번호[응용 프로그램 관련 필드(364)의 처음 8 비트 = 0(영)]. 응용 프로그램 관련 필드의 나머지는 비어 있다.

도 5의 가설적인 예에서, 단계(506)에서 전송된 ACK (3)가 공중 인터페이스에서의 장애 또는 간섭으로 인해 손실되어 있다[단계(506)에서의 "X"를 참조할 것]. IVS는 차후의 확인 응답을 예상하고, 따라서 IVS는 확인 응답이 올바르게 및/또는 적시에 수신되지 않았는지를 검출한다. 따라서, 사전 스케줄링된 시각(T₂)에서, 다음과 같은 정보 요소로 이루어진 제2 RTCP APP (4) 패킷이 단계(508)에서 전송된다. 이름(362) = "eCal", (2) 서브유형(356) = MSD-데이터, 패킷번호[응용 프로그램 관련 필드(364)의 처음 8 비트] = "1". 응용 프로그램 관련 필드의 나머지는 MSD를 포함한다. 이 패킷은 단계(510)에서 다음과 같은 것을 포함하는 RTCP APP 패킷 (5)와 함께 PSAP에 의해 수신되고 확인 응답된다: 이름(362) = "eCal", 서브유형(356) = ACK, 패킷 1을 확인 응답하는 패킷번호[응용 프로그램 관련 필드(364)의 처음 8 비트 = 1]. 응용 프로그램 관련 필드는 비어 있는 채로 있다. IVS에 의한 확인 응답의 성공적인 수신 후에, eCall 데이터의 전송이 종료되고, 단계(502e)에서 음성 패킷이 교환되기 시작한다.

요청된 업데이트 절차

또한, 선택적인 업데이트 요청 절차가 도 5에 나타내어져 있다. 구체적으로는, 단계(512)에서, PSAP는 MSD의 업데이트를 요청하고, 특정 상황에서, PSAP는 업데이트를 필요로 할 수 있는데, 그 이유는 MSD 내의 정보가 동적으로 변하고 있을 수 있기 때문이다. 그에 따라, 다음과 같은 정보 요소를 포함하는 RTCP APP (6) 패킷이 단계(512)에서 전송된다: 이름(362) = "eCal", 서브유형(356) = UPDT, 패킷번호[응용 프로그램 관련 필드(364)의 처음 8 비트]. 응용 프로그램 관련 필드의 나머지는 비어 있는 채로 있다.

IVS는 단계(514)에서 다음과 같은 필드 항목을 포함하는 업데이트된 RTCP APP 패킷 (7)으로 요청에 답변한다: 이름(362) = "eCal", 서브유형(356) = MSD - 데이터, 패킷번호 = 2. 응용 프로그램 관련 필드의 나머지는 업데이트된 MSD를 포함한다.

대안의 실시예에서, 단계(512)에서 전송된 업데이트 요청 RTCP APP 패킷 (6)은 FSD가 이용가능한지를 알아보기 위한 요청을 시작할 수 있고, 이용가능한 경우, 514에서 전송된 RTCP APP 패킷 (7)이 또한 서브유형에 FSD-데이터를 나타낼 수 있다(그리고 응용 프로그램 관련 필드에 FSD를 포함할 수 있다). 또한, 가장 최근에 계산된 MSD에서의 임의의 정보가 전송된 마지막 MSD와 상이한 한, 단계(504, 508)에서 전송된 패킷과 유사하게 IVS가 계속하여 MSD 패킷을 전송하는 것이 생각되지만, 다른 논리 또는 기준이 적용될 수 있다(예를 들어, n개의 연속적인 패킷 또는 구간에 대해 아무런 변경이 없음).

세그먼트화된 패킷

대안의 구현에서, eCall 데이터는 2개 이상의 RTCP 패킷으로 세그먼트화될 수 있다. 예를 들어, 다음과 같은 정보를 포함하는 제1 패킷이 구성되도록 504에서 전송된 RTCP 패킷 (2)의 정보 요소가 변할 수 있다: 이름(362) = "eCal", 서브유형(356) = MSD-데이터-세그먼트화됨, 패킷번호 = 0, 세그먼트번호의 필드 = 0. 응용 프로그램 관련 필드의 나머지는 MSD의 처음 38 바이트를 포함한다.

그 후에, 나중에, 다음과 같은 것을 포함하는 제2 세그먼트화된 패킷이 생성된다: (1) 이름(362) = "eCal", 서브유형(356) = MSD-데이터-세그먼트화됨, 패킷번호 = 0, 세그먼트번호 = 1`, 및 MSD의 나머지 부분을 포함하는 응용 프로그램 관련 필드의 나머지. 단계(506)에서, 확인 응답 메시지는 이어서 양쪽 세그먼트가 PSAP에 수신된 후에만 전체 패킷 0(즉, 양쪽 세그먼트)을 확인 응답할 것이다. ACK는 패킷 및/또는 세그먼트가 확인 응답되는 것을 명시해야만 한다. 그에 따라, 한 변형에서, ACK는 패킷 번호 및 세그먼트 번호 둘다를 포함할 수 있다. IVS에 의해 확인 응답이 수신되지 않은 경우, IVS는 (양쪽 세그먼트를 포함하는) 새로운 MSD를 발생할 것이다.

예시적인 네트워크 장치

이제부터 도 6a를 참조하면, 본 발명의 방법을 구현하는 데 유용한 예시적인 네트워크 장치[예를 들어, PSAP(Public Safety Answering Point) 서브시스템](600)가 도시되어 있다.

장치(600)의 예시된 실시예는 중앙 데이터베이스(604)와 연결되어 있고 프로세서(606), 동작 메모리(608), 전원(610) 및 외부 네트워크 인터페이스(612)를 포함하는 하나 이상의 서버 유닛을 포함한다. 본 명세서에서 사용되는 바와 같이, "네트워크 인터페이스" 또는 "인터페이스"라는 용어는 통상적으로, FireWire(예를 들어, FW400, FW800 등), USB(예를 들어, USB2), 이더넷(예를 들어, 10/100, 10/100/1000(기가비트 이더넷), 10-Gig-E 등), MoCA, 직렬 ATA(예를 들어, SATA, e-SATA, SATAII), Ultra-ATA/DMA, Coaxsys(예를 들어, TVnet™, 무선 주파수 튜너(예를 들어, 대역내 또는 OOB, 케이블 모뎀 등), WiFi(802.11a,b,g,n), WiMAX(802.16), PAN(802.15), IrDA 또는 다른 무선 계열의 인터페이스를 포함하지만 이들로 제한되지 않는, 구성요소, 네트워크 또는 프로세스와의 임의의 신호, 데이터, 또는 소프트웨어 인터페이스를 말한다.

한 구성에서, 도 6a의 서버 유닛은 외부 버스(614)에 의해 연결되어 있다.

도시된 바와 같이, 중앙 데이터베이스(604)는 많은 개별 기계 간에 분산되어 있지만, 하나의 논리적으로 일관된 데이터베이스로서 기능한다. 중앙 데이터베이스는 컴퓨터 판독가능 매체(예를 들어, 하드 디스크 드라이브/RAID 어레이, 플래시 메모리 등)에 저장되어 있는 고유 식별자의 목록, 그리고 대응하는 현재 및 과거 데이터[예를 들어, MSD(minimum set of data)]를 포함한다.

프로세서 서브시스템(606)은 마이크로프로세서(CPU), 디지털 신호 처리기, RISC 코어, FPGA(field programmable gate array), 및/또는 복수의 처리 구성요소를 포함할 수 있다. 본 명세서에서 사용되는 바와 같이, "마이크로프로세서" 및 "디지털 프로세서"라는 용어는 일반적으로 DSP(digital signal processor), RISC(reduced instruction set computer), 범용(CISC) 프로세서, 마이크로프로세서, 게이트 어레이(예를 들어, FPGA), PLD, RCF(reconfigurable compute fabric), 어레이 프로세서, 보안 마이크로프로세서, 및 ASIC(application-specific integrated circuit)를 포함하지만 이들로 제한되지 않는 모든 유형의 디지털 처리 장치를 포함하기 위한 것이다. 이러한 디지털 프로세서는 하나의 단일 IC 다이 내에 포함되어 있거나 다수의 구성요소에 걸쳐 분산되어 있을 수 있다.

처리 서브시스템은 또한 내부 캐시 메모리(606A)를 포함할 수 있다. 처리 서브시스템은 논리 중앙 데이터베이스(604), 로컬 메모리 서브시스템(608), 및 예를 들어 네트워킹 또는 데이터 버스 프로토콜을 통한 다른 로컬 또는 원격 엔터티와의 통신을 위한 외부 네트워크 인터페이스(612)에 연결되어 있다.

메모리 서브시스템(608)은, 예를 들어, 비휘발성 구성요소(예를 들어, ROM, 플래시 등) 및 휘발성 구성요소(예를 들어, RAM, DDR-RAM, QDR-RAM 등)를 포함할 수 있는 하나 이상의 메모리 구성요소를 포함할 수 있다. "메모리"라는 용어가 ROM, PROM, EEPROM, DRAM, SDRAM, DDR/2 SDRAM, EDO/FPMS, RLDRAM, SRAM, "플래시" 메모리(예를 들어, NAND/NOR), 및 PSRAM(이것으로 제한되지 않음)을 비롯한, 디지털 데이터를 저장하도록 구성되어 있는 임의의 유형의 집적 회로 또는 기타 저장 장치를 포함할 수 있다는 것을 이해할 것이다. 메모리 서브시스템은 또한, 고속 데이터 액세스를 용이하게 하기 위해, 컴퓨터 기술 분야에 공지된 유형의 DMA 타입 하드웨어(608A)를 포함할 수 있다.

예시된 PMS(power management subsystem, 전원 관리 서브시스템)(610)는 서버 유닛에 전원을 제공하고, 집적 회로 및/또는 복수의 개별 전기 구성요소를 포함할 수 있다. 본 명세서에서 사용되는 바와 같이, "집적 회로(IC)"라는 용어는, 공정 또는 베이스 물질[Si, SiGe, CMOS 및 GaAs를 제한됨이 없이 포함함]에 상관없이, 임의의 집적 레벨[ULSI, VLSI, 및 LSI를 제한됨 없이 포함함]을 갖는 임의의 유형의 장치를 말한다. IC는, 예를 들어, 메모리 장치(예를 들어, DRAM, SRAM, DDRAM, EEPROM/플래시, 및 ROM), 디지털 프로세서, SoC 장치, FPGA, ASIC, ADC, DAC, 송수신기, 메모리 제어기, 및 기타 장치는 물론, 이들의 임의의 조합을 포함할 수 있다.

또한, 중단 없이 장치를 이용할 수 있게 만들어주기 위해, 원하는 경우, 백업용으로 장애-극복(fail-over) 또는 중복 시스템[도시되지 않은 UPS(uninterruptible power supply, 무정전 전원 공급 장치)를 포함함]이 또한 이용될 수 있다.

예시된 장치는 또한, 응급 상태에 관한 정보가 네트워크 전체에 걸쳐, 그리고 원하는 경우 다른 유형의 네트워크로 용이하게 전파될 수 있도록, 다른 장치(예를 들어, 네트워크 통신 사업자의 다른 응급 서비스 장치, 네트워크 브리지, 게이트웨이 등)와 직접 또는 간접적으로 데이터 통신하고 있을 수 있다.

예시적인 IVS 장치

이제부터 도 6b를 참조하여, 본 발명에 따른 예시적인 클라이언트 장치(650)가 기술된다. 예시된 실시예에서, 클라이언트 장치는 IVS(In-Vehicle System)(650)를 포함하지만, 다른 유형의 장치가 똑같이 성공적으로 사용될 수 있다는 것을 이해할 것이다.

예시된 IVS 장치(650)는, 그 중에서도, 하우징, 셀룰러 네트워크를 통해 데이터를 적어도 전송 및 수신할 수 있는 무선기(652), 차량의 탑승자로부터 음성 통신을 수신하고 다운스트림 또는 역통신(reverse communication)을 재생하는 마이크 및 스피커 어셈블리(654), 차량 상태에 관한 데이터를 수집하도록 구성된 하나 이상의 센서(656), 및 본 명세서에서 앞서 기술된 방법 및 프로토콜에 따라 무선기를 통해 셀룰러 네트워크에 대한 연결을 시작하고 음성 및 데이터 스트림을 전송할 수 있는 처리 장치(658)를 포함한다.

장치(650)는 또한, 앞서 기술한 음성 전송과 유사하게 패킷화하여 네트워크를 통해 다른 "실시간'" 스트림으로서 전송하기 위해, 영상 데이터를 수집하고 이 데이터를 처리 서브시스템(658)에 제공할 수 있는 비디오 또는 카메라 서브시스템(도시 생략)을 포함할 수 있다. 게다가, 음성 및 비디오 스트림은 음성 및 비디오의 동기화를 제공하는, 패킷화된 데이터 네트워킹 기술 분야의 당업자에게 공지된 ITU 표준 H.323 또는 유사한 프로토콜 등에 의해 조정된 방식으로 재생되도록 시간적으로 관련되어 있을 수 있다.

앞서 기술한 제어 프로토콜 및 음성 데이터 인터리빙 기능이 원하는 경우 클라이언트(또는 대안으로서 클라이언트와 통신하고 있는 전용 또는 다기능 장치) 내에서 다양한 정도로 수행될 수 있다. 예시된 실시예에서, 이러한 기능이 소프트웨어로 수행되지만, 펌웨어/하드웨어 실시예도 생각되고 있다. 본 명세서에서 사용되는 바와 같이, "소프트웨어" 및 "컴퓨터 프로그램"이라는 용어는 기능을 수행하는 임의의 시퀀스 또는 사람 또는 기계 인지가능 단계를 제한됨이 없이 포함할 수 있다. 이러한 프로그램은, 예를 들어, C/C++, Fortran, COBOL, PASCAL, 어셈블리 언어, 마크업 언어(예를 들어, HTML, SGML, XML, VoXML) 등은 물론, CORBA(Common Object Request Broker Architecture), Java™(J2ME, Java Beans 등을 포함함), BREW(Binary Runtime Environment) 등과 같은 객체-지향 환경을 비롯한 거의 모든 프로그래밍 언어 또는 환경에서 작성될 수 있다.

장치(650)의 일 실시예에서, 차량 상태에 관한 데이터를 수집하도록 구성된 하나 이상의 센서는 또한 (i) GPS(Global Positioning Service) 수신기(656A), (ii) 충돌 및/또는 새시 위치를 결정하기 위해 새시 내에 배치된 하나 이상의 가속도계(656B), 및 (iii) 차량의 탑승을 판정하는 센서(656C)를 포함한다. GPS 수신기는 임의의 주어진 때의 비교적 정밀한 차량 위치를 제공하는 반면, 가속도계는 충격 또는 기타 사건(예를 들어, 전복 사고)이 발생했는지를 판정한다. 탑승 데이터는, 그 중에서도, 사건이 있었을 때 차량 탑승자가 있었는지(그로써 탑승자가 없었던 경우 우선순위를 변경할 수 있음) 및 탑승자의 수(그로써, 예를 들어, 적당한 수의 응급 차량 또는 서비스 요원을 급파할 수 있음)를 결정하는 데 사용된다. 원하는 경우, 예를 들어, 차량의 다양한 구성요소의 변형을 탐지하는 응력/변형 센서, 차량 환경(예를 들어, 물에 빠짐, 화재 등)의 조건을 탐지하는 온도 및 기타 환경 센서 등을 비롯한 다른 센서도 역시 사용될 수 있고, 이들 부가의 센서는 또한 임의의 발신 데이터 전송을 위한 입력 또는 페이로드 데이터를 제공할 수 있다.

무선기/모뎀(656A) 서브시스템은 디지털 기저대역, 아날로그 기저대역, 수신 프런트엔드 및 송신 프런트엔드를 포함한다. 이 장치는 안테나 어셈블리 및 듀플렉스 구성요소를 더 포함하고, 듀플렉스 구성요소는 안테나 동작을 전환하는 간단한 스위치를 포함할 수 있다. 스위치는 또한 개별 구성요소를 포함할 수 있다. 특정의 아키텍처가 기술되어 있지만, 일부 실시예에서, 본 개시 내용에 주어진 기술 분야의 당업자라면 이해하는 바와 같이, 어떤 구성요소가 생략될 수 있거나 다른 방식으로 서로 병합될 수 있다(예컨대, 3G 디지털 RF에 사용되는 유형과 같이 RF 수신 및 RF 송신 겸용).

사용자 인터페이스 시스템(654)이 선택적으로 제공되고, 터치 스크린, LCD 디스플레이, 백라이트를 포함하지만 이들로 제한되지 않는 임의의 수의 공지된 I/O를 포함할 수 있다. IVS 시스템에서, 이 시스템이 일반적으로, 통신을 용이하게 하기 위해, 최소한 차량의/으로부터의 음성 스트림 또는 기타 사운드 샘플링을 발생하는 수단(즉, 마이크), 및 가청 메시지를 합성하는 수단(즉, 스피커)을 제공한다는 것을 이해할 것이다. 일부 경우에, I/O 서브시스템이 단지 모니터링을 위해, 예컨대, 차량의 탑승자가 무의식으로 되어 말을 할 수 없는 경우 또는 네트워크 통신 사업자 또는 법 집행부에 의한 수동 모니터링을 위해, 예컨대 자동차 털이, 유괴 등이 있을 때 탑승자가 트리거할 수 있는 "무음 경보"가 차량에 장착되어 있는 경우에 사용될 수 있다는 것을 이해할 것이다.

장치의 예시된 실시예는 디지털 신호 처리기, 마이크로프로세서/CPU, RISC 코더, FPGA(field programmable gate array), 또는 하나 이상의 기판 상에 탑재된 복수의 처리 구성요소와 같은 하나 이상의 프로세서를 갖는 응용 프로그램 마이크로프로세서 서브시스템(658)을 포함한다. 처리 서브시스템은 또한 내부 캐시 메모리를 포함할 수 있다. 처리 서브시스템은, 예를 들어, SRAM, 플래시 및 SDRAM 구성요소를 포함할 수 있는 메모리를 포함하는 메모리 서브시스템과 데이터 통신하고 있다. 메모리 서브시스템은, 기술 분야에 공지된 바와 같이, 데이터 액세스를 용이하게 하기 위해 DMA 유형 하드웨어의 하나 이상을 구현할 수 있다.

한 예시적인 장치에서, IVS는 PSAP와의 eCall을 시작하기 위해 (예를 들어, 프로그램 메모리에 저장된 알고리즘을 통해) 내부 논리를 이용하도록 구성된다. eCall이 설정되면, IVS는 차량 전체에 걸쳐 분포되어 있는 상기한 센서로부터 판독된 데이터가 산재되어 있는 연속적인 음성 또는 기타 페이로드 트래픽을 제공한다. 음성(또는 페이로드) 및 센서 데이터에 대한 제어는 처리 서브시스템에 의해 제공된다.

한 이러한 실시예에서, 가속도계가 (충돌을 나타내는) 소정의 임계값보다 큰 가속도 값을 탐지하는 경우와 같이, eCall은 충돌을 탐지하는 차량의 센서들(656) 중 하나 이상의 센서에 의해 자동으로 시작된다. 예를 들어, 주변 온도의 급격한 저하(물에 잠수하는 것을 나타냄), 차량의 전복(전복 사고), 후드 아래 또는 실내의 온도의 급격한 증가(가능하게는 엔진 또는 기타 화재, 또는 창문이 열려 있는 아주 뜨거운 날과 같은 질식 상황), 엔진 동작 동안 차량 내에서의 활동이 없음(예를 들어, 의료 또는 기타 조건으로 인해 잠재적으로 운전자가 죽은 것을 나타냄) 등을 비롯한 임의의 수의 다른 시나리오가 이러한 호출을 트리거하는 데 사용될 수 있다. 대안의 실시예에서, 차량이 견인 지원을 필요로 하는 경우와 같이, eCall이, 차량 내의 탑승자들 중 하나에 의해 시작된다.

무선 모뎀 서브시스템은 셀룰러 호출을 시작하고, 네트워크 메시징을 제공하는 전송 계층은 물론 실시간 통신 링크를 설정한다. 호출 처리에 대한 제어는 무선 모뎀 서브시스템에서 또는 처리 서브시스템에서 수행될 수 있다. 무선 모뎀 서브시스템이 셀룰러 호출을 시작하는 것에 응답하여, 네트워크 엔터티는, 앞서 기술된 바와 같이, 우선적이고 신속한 처리 절차를 제공해야만 한다.

eCall의 설정 이후에, 2개 이상의 스트림이 발생된다. 이들 스트림 중 적어도 하나는 사용자 인터페이스 마이크 어셈블리에 의해 발생된 음성 호출 스트림이고, 빈번하지 않고 및/또는 산발적 방식 등에 기초하여, 데이터 스트림으로서 전송하기 위해 나머지 스트림(들)이 각각의 모니터링된 센서에 의해 발생된다. 처리 서브시스템은, 앞서 기술한 바와 같이, 무선기/모뎀 서브시스템에 대한 2개의 스트림을 중재한다.

또한, 클라이언트 장치(650)의 예시적인 실시예가 위치 확인을 위한 GPS(또는 AGPS) 수신기를 갖는 것으로 기술되어 있지만, 다른 기법이, 상기한 GPS 수신기 대신에 또는 그와 함께, 이용될 수 있다는 것을 이해할 것이다. 예를 들어, 그 전체 내용이 참조 문헌으로서 본 명세서에 포함된, 2008년 9월 30일자로 출원되고 발명의 명칭이 "Methods and Apparatus for Resolving Wireless Signal Components"인, 공동 소유의 동시 계류 중인 미국 특허 출원 제12/286,646호에 기술된, SFN(Single Frequency Network), 예를 들어, WiMAX 네트워크 내의 위치 확인을 위한 방법 및 장치는 본 발명에 따라 모바일 클라이언트 위치 데이터를 제공하는 데 사용될 수 있다. 구체적으로는, 상기한 출원은 무선 네트워크가 개별 송신기의 기여를 해결하기 위해, 예를 들어, GPS 위성과 같은 외부 장치에 의지하지 않고 그의 위치를 결정하기 위해 수신기(예를 들어, UE)에 의해 사용될 수 있는 데이터를 발생할 수 있게 하는 방법 및 장치를 개시한다. 일 실시예에서, 무선 네트워크는 SFN(single frequency network)을 포함하고, 고유한 기지국 식별자가 데이터 내에 삽입되며 UE가 경로 특성(예컨대, 경로 대기시간 및 도달 방향)을 계산하여 그의 위치를 삼각측량할 수 있게 하는 방식으로 인코딩된다.

게다가, 수신기가 실내에 있을 때 또는 터널, 육교 등과 같은 구조물로 가려지거나 차폐될 때 GPS가 때때로 동작할 수 없기 때문에, 셀룰러-기반 위치 확인 기법이 GPS에 대한 "대체물"로서(또는 반대로) 사용될 수 있거나, 응급 서비스 등이 올바른 위치로 전송되도록 하기 위해 이 2가지 기법이 서로에 대해 확인 방법으로서 사용될 수 있다(차량 조작자가 구두로 응답할 수 없거나 자신이 위치하는 곳을 정확히 모르는 것으로 가정함).

심지어 상기한 GPS- 또는 SFN-기반 기법 없이, 기존의 셀룰러 기술이 그럼에도 불구하고 적어도 모바일 장치 또는 UE가 현재 네트워크 내의 어느 셀과 연관되어 있는지를 적어도 해결할 수 있다. 따라서, 이 정보는 위치의 결정을 위해 또는 다른 시스템에 의해 제공되는 다른 "고정된" 또는 추정된 위치의 확인을 위해서도 사용될 수 있다. 예를 들어, IVS가 "잠수" 센서를 장비하고 있고 IVS가 마지막으로 통신하고 있는 셀 사이트 또는 기지국이 알려져 있는 경우, 이 정보는 차량이 어디에 있는지를 대략 알기 위해(즉, 그 특정의 셀 사이트의 범위 내에서 수중을 탐색하기 위해) PSAP/응급 요원에 의해 사용될 수 있다. 이러한 정보(예를 들어, 셀 사이트 ID 등)가 본 명세서에 기술된 기법을 사용하여 PSAP로 전송되는 데이터(예를 들어, "사이트 연관" 필드 등) 내에 용이하게 포함될 수 있다.

비즈니스 방법

본 발명의 다른 양태에서, 패킷 교환 네트워크 내에서 상기한 응급 호출 서비스에 관련된 비즈니스를 하는 방법이 개시되어 있다.

일 실시예에서, 본 발명에 의해 가능하게 되는 무선기/모뎀 기능이 시판되고 네트워크 통신 사업자 및/또는 제3자를 위해 이용될 수 있다. 예를 들어, 장치 제조업체 또는 서비스 공급자는, PS 및 CS/PS 유형 네트워크 중 어느 하나 또는 그 둘다 내에서 응급 호출 서비스를 제공할 수 있는지에 기초하여, 자신의 제품 또는 서비스를 다른 것에 대해 구별할 수 있다. 상기한 IVS 시스템 기능은 또한 구별의 기초로서 또는 더 높은 가격을 지원하기 위해, 위치 및/또는 서비스 계획에 상관없이, 사고가 있는 경우 소비자의 차량이 응급 호출을 시작할 수 있을 것이라는 보장을 소비자에게 제공함으로써 사용될 수 있다. 가입자는 외견상 이러한 기능에 대한 초기 가격 또는 진행 중인 가입비와 관련하여 추가로 지불할 의향이 있을 것이다.

다른 양태에서, 본 발명에 의해 가능하게 되는 IVS 내에서 응급 호출에 대한 실시간 패킷화된 데이터 서비스의 보충적 성질은 가입자 사용에서 더 많은 유연성을 제공할 수 있다. 다양한 서비스를 분배하는 기회가 응급 도어 잠금 열기, 무음 송신기[예를 들어, "로-잭(lo-jack)"] 추적, 응급 좌표/방향, 및 사용자의 편의상 제공되는 임의의 다른 각종의 의사-응급 서비스와 같은 선택적인 서비스를 포함할 수 있다.

본 발명의 특정 양태가 방법의 단계들의 구체적인 순서와 관련하여 기술되어 있지만, 이들 설명이 본 발명의 보다 광범위한 방법을 예시한 것에 불과하고 특정의 응용에서 필요한 바에 따라 수정될 수 있다는 것을 이해할 것이다. 특정의 단계가 특정의 상황 하에서 불필요하거나 선택적으로 될 수 있다. 또한, 특정의 단계 또는 기능이 개시된 실시예에 추가될 수 있거나, 2개 이상의 단계의 수행 순서가 치환될 수 있다. 모든 이러한 변형이 본 명세서에 개시되고 청구된 본 발명 내에 포함되는 것으로 생각된다.

상기한 상세한 설명이 다양한 실시예에 적용되는 본 발명의 새로운 특징을 도시하고, 기술하며 지적하고 있지만, 예시된 장치 또는 프로세스의 형태 및 상세에서의 다양한 생략, 대체 및 변경이 본 발명을 벗어나지 않고 당업자에 의해 행해질 수 있다는 것을 이해할 것이다. 이상의 설명은 본 발명을 수행하는 현재 생각되는 최상의 형태에 대한 것이다. 이 설명은 결코 제한하기 위한 것이 아니며, 본 발명의 일반 원리를 설명하는 것으로 보아야 한다. 본 발명의 범위는 특허청구범위를 참조하여 결정되어야 한다.

Claims (40)

1. 실시간 패킷 교환 동작을 하도록 구성된 네트워크 내에서 응급 호출을 클라이언트 장치에 의해 제공하는 방법으로서,
   상기 응급 호출은 제1 스트림 및 하나 이상의 제2 스트림을 갖는 복합 스트림을 포함하고, 상기 방법은,
   상기 제1 스트림을 연속적인 방식으로 생성하는 단계;
   상기 하나 이상의 제2 스트림을 생성하는 단계;
   적어도 상기 제1 스트림 및 상기 하나 이상의 제2 스트림을 사용하여 상기 복합 스트림을 형성하는 단계;
   세션을 설정하는 단계 - 상기 세션은 상기 복합 스트림을 라우팅하도록 부가적으로 구성됨 -; 및
   상기 세션을 통해 상기 복합 스트림을 전송하는 단계
   를 포함하는 방법.
2. 제1항에 있어서, 상기 세션은 세션 시작 프로토콜을 이용하여 설정되는 실시간 세션을 포함하는 방법.
3. 제1항에 있어서, 상기 제1 스트림은 복수의 음성 패킷으로 이루어져 있고, 상기 하나 이상의 제2 스트림은 복수의 데이터 패킷으로 이루어져 있는 방법.
4. 제1항에 있어서, 상기 하나 이상의 제2 스트림을 제공하는 단계는 불연속적인 또는 비지속적인 방식으로 수행되는 방법.
5. 제4항에 있어서, 상기 불연속적인 방식은 주기적으로 그리고 간헐적으로만 적어도 하나의 소스로부터 데이터를 제공하며, 상기 데이터는 위치 데이터를 포함하고, 상기 적어도 하나의 소스는 GPS 수신기를 포함하는 방법.
6. 제1항에 있어서, 상기 복합 스트림, 상기 제1 스트림 및 상기 하나 이상의 제2 스트림은 패킷화되는 방법.
7. 제6항에 있어서, 상기 형성하는 단계는 상기 제1 스트림의 하나 이상의 패킷 사이에 상기 제2 스트림의 하나 이상의 패킷을 산재시킴으로써 상기 복합 스트림을 형성하는 단계를 포함하는 방법.
8. 제7항에 있어서, 상기 산재시키는 것은 멀티플렉싱 알고리즘을 사용하여 수행되는 방법.
9. 제1항에 있어서,
   상기 제1 스트림의 적어도 일부분을 제1 패킷화된 프로토콜 구조체 내에 배치하는 단계;
   상기 하나 이상의 제2 스트림을 제2 패킷화된 프로토콜 구조체 내에 배치하는 단계; 및
   상기 전송하는 단계 이전에, 상기 제1 및 제2 프로토콜 구조체를 산재시켜 상기 복합 스트림의 적어도 일부를 형성하는 단계
   를 더 포함하며,
   상기 제1 스트림은 연속적인 사용자 데이터 스트림을 포함하고,
   상기 하나 이상의 제2 스트림의 적어도 일부분은 상위-우선순위 이벤트에 관련되는 방법.
10. 제9항에 있어서, 상기 네트워크는 3G 셀룰러 네트워크를 포함하고, 상기 전송하는 단계는 먼저 세션 설정 프로토콜(session establishment protocol)을 통해 적어도 하나의 세션을 설정하는 단계를 포함하는 방법.
11. 제10항에 있어서, 상기 제1 패킷화된 프로토콜은 실시간 전송 프로토콜을 포함하고, 상기 제2 패킷화된 프로토콜은 실시간 제어 프로토콜을 포함하는 방법.
12. 제9항에 있어서, 상기 사용자 데이터는 비디오 데이터 및 음성 데이터 둘다를 포함하는 방법.
13. 제9항에 있어서, 상위-우선순위 이벤트에 관련된 상기 하나 이상의 제2 스트림의 적어도 일 부분은 상기 응급 호출 시의 제1 엔터티에 대한 정확한 위치 데이터를 포함하는 방법.
14. 제13항에 있어서, 상기 정확한 위치 데이터는 네트워크 주소 외에 임의의 정보에도 기초할 수 있는 방법.
15. 패킷 교환 동작을 할 수 있는 네트워크 내에서 응급 호출을 하는 장치로서,
    연속적으로 음성을 포착하고 복수의 제1 패킷으로 디지털적으로 분해하도록 구성된 장치;
    상기 장치 또는 상기 장치가 실려 있는 플랫폼과 연관된 하나 이상의 파라미터를 하나 이상의 제2 패킷으로 인코딩하도록 구성된 하나 이상의 센서;
    무선 송신기 - 상기 송신기는 무선 네트워크를 통해 복수의 패킷을 전송하도록 구성됨 -;
    상기 송신기와 데이터 통신하고 있는 프로세서; 및
    복수의 명령어를 갖는 컴퓨터 프로그램을 포함하도록 구성된 매체를 포함하는 컴퓨터 판독가능 장치
    를 포함하고, 상기 복수의 명령어는, 상기 프로세서에 의해 실행될 때,
    상기 복수의 제1 패킷 사이에 상기 하나 이상의 제2 패킷을 산재시키는 것으로부터 전송을 위한 상기 복수의 패킷을 생성하고,
    세션을 설정하며 - 상기 세션은 상기 산재된 복수의 제1 패킷 및 하나 이상의 제2 패킷을 라우팅하도록 구성됨 -,
    상기 무선 송신기를 통해 상기 산재된 복수의 패킷을 전송하는 장치.
16. 제15항에 있어서, 전송을 위한 상기 복수의 패킷을 생성하는 것은 복수의 제3 패킷을 생성하는 것을 포함하고, 상기 제3 패킷은 상기 산재된 복수의 제1 패킷 및 하나 이상의 제2 패킷으로부터 도출되는 장치.
17. 제15항에 있어서, 상기 장치는,
    상기 무선 네트워크로부터 복수의 패킷을 수신하도록 구성된 무선 수신기; 및
    상기 수신된 복수의 패킷으로부터 음성을 디지털적으로 합성하도록 구성된 스피커
    를 더 포함하는 장치.
18. 제15항에 있어서, 상기 장치는 스피커 서브시스템, 상기 무선 네트워크로부터 복수의 패킷을 수신하도록 구성된 수신기 장치, 및 상기 네트워크로부터 수신된 상기 복수의 패킷을 음성 성분과 데이터 성분으로 분리하도록 구성된 분리 장치를 더 포함하고, 상기 분리 장치는,
    (i) 상기 음성 성분을 상기 스피커 서브시스템에 제공하고,
    (ii) 상기 데이터 성분으로부터 상기 하나 이상의 제2 패킷의 수신의 상태를 결정하도록 구성되는 장치.
19. 패킷 교환 네트워크 내에서 응급 호출을 수신하도록 구성된 네트워크 장치로서,
    상기 장치와 데이터 통신하고 있는 IP(internet protocol) 네트워크를 통해 제1 및 제2 복수의 패킷을 수신하도록 구성된 네트워크 인터페이스;
    상기 인터페이스와 데이터 통신하고 있는 프로세서; 및
    복수의 명령어를 갖는 컴퓨터 프로그램을 포함하도록 구성된 매체를 포함하는 컴퓨터 판독가능 장치
    를 포함하고, 상기 복수의 명령어는, 상기 프로세서에 의해 실행될 때,
    통신 세션에 대한 요청을 수신하고 - 상기 세션은 상기 제1 및 제2 복수의 패킷의 전송을 용이하게 하도록 구성됨 -,
    상기 세션을 설정하고,
    상기 세션을 통해 상기 제1 및 제2 복수의 패킷을 수신하고,
    상기 제1 복수의 패킷으로부터 실시간 사용자 데이터를 추출하며,
    상기 제2 복수의 패킷으로부터 응급-관련 데이터를 추출하는 네트워크 장치.
20. 제19항에 있어서, 스피커를 가지며 상기 스피커를 통해 오디오를 재생하도록 구성된 오디오 모듈을 더 포함하고, 상기 오디오는 상기 추출된 실시간 사용자 데이터로부터 도출되는 네트워크 장치.
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제
37. 삭제
38. 삭제
39. 삭제
40. 삭제

Images