JP6630719B2 - 車両開始型緊急呼 - Google Patents
車両開始型緊急呼 Download PDFInfo
- Publication number
- JP6630719B2 JP6630719B2 JP2017502996A JP2017502996A JP6630719B2 JP 6630719 B2 JP6630719 B2 JP 6630719B2 JP 2017502996 A JP2017502996 A JP 2017502996A JP 2017502996 A JP2017502996 A JP 2017502996A JP 6630719 B2 JP6630719 B2 JP 6630719B2
- Authority
- JP
- Japan
- Prior art keywords
- telematics
- terminal
- data
- vehicle
- emergency call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000011664 signaling Effects 0.000 claims description 327
- 238000004891 communication Methods 0.000 claims description 233
- 230000009471 action Effects 0.000 claims description 191
- 230000004044 response Effects 0.000 claims description 150
- 238000000034 method Methods 0.000 claims description 104
- 230000005540 biological transmission Effects 0.000 claims description 48
- 230000003213 activating effect Effects 0.000 claims description 31
- 239000000446 fuel Substances 0.000 claims description 9
- 238000009877 rendering Methods 0.000 claims description 8
- 239000003795 chemical substances by application Substances 0.000 claims description 5
- 230000004397 blinking Effects 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 71
- 230000006870 function Effects 0.000 description 67
- 238000012360 testing method Methods 0.000 description 30
- 230000007246 mechanism Effects 0.000 description 28
- 238000012545 processing Methods 0.000 description 28
- 230000001960 triggered effect Effects 0.000 description 27
- 238000000926 separation method Methods 0.000 description 20
- 230000000875 corresponding effect Effects 0.000 description 19
- 230000000977 initiatory effect Effects 0.000 description 16
- 108010007100 Pulmonary Surfactant-Associated Protein A Proteins 0.000 description 15
- 102100027773 Pulmonary surfactant-associated protein A2 Human genes 0.000 description 15
- 230000001413 cellular effect Effects 0.000 description 15
- 238000012546 transfer Methods 0.000 description 15
- 238000003491 array Methods 0.000 description 12
- 238000012790 confirmation Methods 0.000 description 12
- 208000014674 injury Diseases 0.000 description 12
- 230000008569 process Effects 0.000 description 12
- 230000003068 static effect Effects 0.000 description 10
- 238000004458 analytical method Methods 0.000 description 9
- 230000008901 benefit Effects 0.000 description 8
- 230000006378 damage Effects 0.000 description 8
- 238000007405 data analysis Methods 0.000 description 8
- 208000027418 Wounds and injury Diseases 0.000 description 7
- 238000001514 detection method Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 7
- 239000000284 extract Substances 0.000 description 7
- 238000005259 measurement Methods 0.000 description 7
- 230000003416 augmentation Effects 0.000 description 6
- 230000008520 organization Effects 0.000 description 6
- HNQBPUIXFDQDRJ-UHFFFAOYSA-N N-ethyl-N-(2-hydroxyethyl)nitrosamine Chemical compound CCN(N=O)CCO HNQBPUIXFDQDRJ-UHFFFAOYSA-N 0.000 description 5
- 230000008733 trauma Effects 0.000 description 5
- 230000001276 controlling effect Effects 0.000 description 4
- 238000013480 data collection Methods 0.000 description 4
- 238000012552 review Methods 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 230000006978 adaptation Effects 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 238000006731 degradation reaction Methods 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000007774 longterm Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 238000013519 translation Methods 0.000 description 3
- 208000034188 Stiff person spectrum disease Diseases 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 230000034994 death Effects 0.000 description 2
- 231100000517 death Toxicity 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000001976 improved effect Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 208000012112 ischiocoxopodopatellar syndrome Diseases 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000000704 physical effect Effects 0.000 description 2
- 230000003449 preventive effect Effects 0.000 description 2
- 230000008093 supporting effect Effects 0.000 description 2
- 241000501754 Astronotus ocellatus Species 0.000 description 1
- 102100035024 Carboxypeptidase B Human genes 0.000 description 1
- 101000946524 Homo sapiens Carboxypeptidase B Proteins 0.000 description 1
- 206010061245 Internal injury Diseases 0.000 description 1
- 229920010524 Syndiotactic polystyrene Polymers 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 230000009118 appropriate response Effects 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 238000000576 coating method Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000011521 glass Substances 0.000 description 1
- 239000000383 hazardous chemical Substances 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 239000006249 magnetic particle Substances 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 239000002245 particle Substances 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000002490 spark plasma sintering Methods 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000000472 traumatic effect Effects 0.000 description 1
- 235000019801 trisodium phosphate Nutrition 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
- G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
- G05D1/0011—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots associated with a remote control arrangement
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
- H04M3/5116—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing for emergency applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/0024—Services and arrangements where telephone services are combined with data services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q9/00—Arrangements in telecontrol or telemetry systems for selectively calling a substation from a main station, in which substation desired apparatus is selected for applying a control signal thereto or for obtaining measured values therefrom
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/50—Connection management for emergency connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
- H04W8/24—Transfer of terminal data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2207/00—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place
- H04M2207/18—Type of exchange or network, i.e. telephonic medium, in which the telephonic communication takes place wireless networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2242/00—Special services or facilities
- H04M2242/04—Special services or facilities for emergency applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2242/00—Special services or facilities
- H04M2242/30—Determination of the location of a subscriber
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/025—Services making use of location information using location based information parameters
- H04W4/027—Services making use of location information using location based information parameters using movement velocity, acceleration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/029—Location-based management or tracking services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- Multimedia (AREA)
- Emergency Management (AREA)
- General Business, Economics & Management (AREA)
- Marketing (AREA)
- General Engineering & Computer Science (AREA)
- Environmental & Geological Engineering (AREA)
- Public Health (AREA)
- Health & Medical Sciences (AREA)
- Aviation & Aerospace Engineering (AREA)
- Databases & Information Systems (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Automation & Control Theory (AREA)
- Telephonic Communication Services (AREA)
- Alarm Systems (AREA)
- Emergency Alarm Devices (AREA)
Description
相互参照
本出願は、2014年7月23日に出願した、Gellensによる「Asserting Support for Telematics Capabilities in Vehicle Emergency Call Systems」という名称の米国仮特許出願第62/028,234号、および2014年10月24日に出願した、Gellensによる「Vehicle-Initiated Emergency Calls」という名称の米国仮特許出願第62/068,590号の優先権の利益を主張し、前記出願の両方がすべての目的のために全体的に参照により本明細書に組み込まれ、前記出願の各々が本出願の譲受人に譲渡されている。
本出願は、2014年7月23日に出願した、Gellensによる「Asserting Support for Telematics Capabilities in Vehicle Emergency Call Systems」という名称の米国仮特許出願第62/028,234号、および2014年10月24日に出願した、Gellensによる「Vehicle-Initiated Emergency Calls」という名称の米国仮特許出願第62/068,590号の優先権の利益を主張し、前記出願の両方がすべての目的のために全体的に参照により本明細書に組み込まれ、前記出願の各々が本出願の譲受人に譲渡されている。
本開示は、車両緊急呼システムに関し、より詳細には、車両緊急呼システムにおけるテレマティクス能力のサポートをアサートすることに関する。車両緊急呼システムによっては、テレマティクスデータ(たとえば、センサ読取値および他のデータ)が処理のためにインテリジェント車両端末から中央サービスに送信され得る。たとえば、衝突に遭っている車両に関連する端末が、ロケーションおよびエアバッグ展開データを、ワイヤレス通信システムを介して、緊急サービス要求に関連する緊急応答機関(PSAP:public safety answering point)に送信することがある。システムによっては、データがサードパーティサービスセンターに送信されることがあり、次いでサードパーティサービスセンターがデータの一部または全部をPSAPに伝達することがある。
本開示はまた、PSAPがさらに車両端末に返信し得る、テレマティクスデータに関連するメタデータ(「制御データ」と呼ばれることがある)に関する。たとえば、PSAPは、テレマティクスデータが良好に受信されたことの確認応答を送ることがある。メタデータは、あるテレマティクスデータを送ること、または再送すること、車両ドアの鍵を開けること、車両のライトを照らすことなどのような、1つまたは複数のアクションの実施を求める車両端末向けの要求を含むこともできる。しかしながら、様々な車両の広範囲の機能のために、PSAPは、どのタイプのアクションを車両端末が実施することが可能であるか、可能ではないかを認識していないことがある。そのため、PSAPは、車両端末が要求されたアクションを実際に実施することができるかどうかを知らずに、車両端末に多くの要求を送ること、または単一の要求を何回も送ることがある。他の場合には、PSAPは、車両端末があるアクションを実施することができることを認識していないので、あるタイプの要求を決して送らないことがある。
説明する特徴は一般に、車両緊急呼システムにおけるテレマティクス能力のサポートをアサートするための1つまたは複数の改善されたシステム、方法、および/または装置に関する。車両端末の緊急呼車載システム(IVS)などの第1のエンドポイントは、そのテレマティクス能力を、ワイヤレス通信システムを介して緊急呼応答機関などの第2のエンドポイントに送信することができる。テレマティクス能力は、第1のエンドポイントが実施することが可能であるアクションのすべてまたはサブセットを含むことができ、たとえば、第1のエンドポイントがIVSである場合、能力は、応答機関に追加データを送ること、および/または外部車両システムを作動させること(たとえば、車両のライトを照らすこと、クラクションを鳴らすことなど)を含むことができる。
場合によっては、テレマティクス能力は、要求が送信されるべきフォーマットに対応する(たとえば、そのようなフォーマットと実質的に同等である)フォーマットにおいて送信され得る。たとえば、能力は、拡張マークアップ言語(XML)要素としてフォーマットされ、1つまたは複数の子XML要素が、可能な各アクションに対応することがある。ある場合には、応答機関がIVSからテレマティクス能力を受信すると、応答機関は、適切なフォーマットにおいて、たとえば、要求データ構造においてルートXML要素としてアクションに対応する子XML要素のうちの1つを使用して、IVSに1つまたは複数の要求を送ることができる。様々な例では、IVSはテレマティクス能力を、応答機関との緊急呼を確立する際に招待およびデータセットとともに応答機関に送信することができ、またはIVSはテレマティクス能力を、能力の送信を求める応答機関からの要求に応答して、緊急呼が確立された後に(もしくは呼確立中に)応答機関に送信することができる。
車両緊急呼システムにおけるワイヤレス通信のための方法について説明し、方法は、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第1のエンドポイントから車両緊急呼システムにおける第2のエンドポイントにテレマティクス能力のセットを送信するステップを含む。
車両緊急呼システムにおけるワイヤレス通信のための装置について説明し、装置は、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第1のエンドポイントから車両緊急呼システムにおける第2のエンドポイントにテレマティクス能力のセットを送信するための手段を含む。
また、車両緊急呼システムにおけるワイヤレス通信のための別の装置について説明し、装置は、プロセッサと、プロセッサと電子通信しているメモリと、メモリに記憶された命令とを含み、命令はプロセッサによって、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第1のエンドポイントから車両緊急呼システムにおける第2のエンドポイントにテレマティクス能力のセットを送信するように実行可能である。
ワイヤレスデバイスにおける車両緊急呼システムにおけるワイヤレス通信のための非一時的コンピュータ可読媒体が開示され、非一時的コンピュータ可読媒体は、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第1のエンドポイントから車両緊急呼システムにおける第2のエンドポイントにテレマティクス能力のセットを送信するためのコンピュータ実行可能コードを記憶する。
方法、装置、および/またはコンピュータプログラム製品のいくつかの例では、第1のエンドポイントは緊急呼車載システム(IVS)であり得、第2のエンドポイントは緊急呼応答機関であり得る。テレマティクス能力のセットは、緊急呼IVSが実施することが可能である少なくとも1つのアクションを含むことができ、少なくとも1つのアクションは、テレマティクスデータを収集および/もしくは送信すること、車両の状態に影響を与えるアクションを実施すること、車両の構成要素をアクティブ化すること、車両の構成要素を非アクティブ化すること、車両のイグニションをオフにすること、車両のイグニションをオンにすること、車両の燃料供給をオフにすること、車両の燃料供給をオンにすること、一次バッテリもしくは他のバッテリもしくは他の電源を切断すること、一次バッテリもしくは他のバッテリもしくは他の電源を接続すること、ドアの鍵を開けること、ドアの鍵を閉めること、車両のクラクションをアクティブ化すること、外部可聴音をアクティブ化すること、車両のライトをアクティブ化すること、車両の点滅灯をアクティブ化すること、パワーウィンドウを作動させること、録音メッセージを再生すること、メディアをレンダリングすること、テキストメッセージを表示すること、カメラをアクティブ化すること、カメラを非アクティブ化すること、またはそれらの組合せのうちの1つまたは複数を含むことができる。
いくつかの例では、テレマティクス能力のセットは、少なくとも1つのアクションの実施を求める要求を緊急呼IVSが受け入れる要求データ構造に対応する能力データ構造において、緊急呼応答機関に送信され得る。能力データ構造は、要求データ構造のフォーマットと実質的に同等にフォーマットされ得、かつ/または能力データ構造は、拡張マークアップ言語(XML)要素としてフォーマットされ得る。さらに、少なくとも1つのアクションを定義する少なくとも1つの子XML要素が、能力XML要素データ構造に含められ得る。
いくつかの例では、少なくとも1つのアクションに対応するパラメータがテレマティクス能力のセットに含められ得、パラメータは、少なくとも1つのアクションのサポートされる態様を定義する。テレマティクス能力のセットは、能力拡張マークアップ言語(XML)要素として送信され得、能力XML要素は、少なくとも1つのアクションを定義する少なくとも1つの子XML要素を含み、少なくとも1つのアクションに対応するパラメータは、少なくとも1つのアクションに対応する少なくとも1つの子XML要素内のXML属性として含まれる。テレマティクス能力のセットは、能力拡張マークアップ言語(XML)要素として送信され得、能力XML要素は、少なくとも1つのアクションを定義する少なくとも1つの子XML要素を含み、少なくとも1つのアクションに対応するパラメータは、少なくとも1つのアクションに対応する少なくとも1つの子XML要素内のさらなる子XML要素として含まれる。
いくつかの例では、テレマティクス能力のセットは緊急呼IVSによって、少なくとも1つのアクションに関連する車両構成要素の動作状態に少なくとも部分的に基づいて動的に再構成され得、かつ/またはテレマティクス能力のセットは、緊急呼IVSのメーカー、車両のメーカー、テレマティクスサービスプロバイダ、もしくは別の指定エンティティのうちの1つもしくは複数によって動的に構成可能であり得る。
緊急呼IVSが実施することが可能である1つまたは複数の緊急呼関連アクションが、テレマティクス能力のセットに含められ得る。また、アクションの実施を求める要求が緊急呼応答機関から受信され得、要求はテレマティクス能力のセットに少なくとも部分的に基づくものであり、IVSが要求されたアクションを実施したかどうかに関して、緊急呼応答機関に指示が送信され得る。
いくつかの例では、緊急呼IVSが実施することが可能である緊急呼関連アクションのサブセットが、テレマティクス能力のセットに含められ得、サブセットは、緊急呼IVSのユーザによって必要とされる支援のカテゴリに少なくとも部分的に基づいて決定される。アクションの実施を求める要求が緊急呼応答機関から受信され得、要求はテレマティクス能力のセットに少なくとも部分的に基づくものであり、アクションが実施され得る。
いくつかの例では、招待およびデータセットが、緊急呼応答機関との緊急呼を確立するために送信され得、その場合にテレマティクス能力のセットが招待およびデータセットとともに送信される。データセットは、テレマティクスデータの最小セットであり得る。
いくつかの例では、招待およびデータセットが、緊急呼応答機関との緊急呼を確立するために送信され得、招待に応答して能力のセットの送信を求める応答機関からの要求が受信され得、招待への応答の確認応答とともにテレマティクス能力のセットが送信され得る。テレマティクス能力のセットは、緊急呼の確立中または確立後に送信され得る。
いくつかの例では、緊急呼応答機関との緊急呼を確立するための招待およびデータセットが送信され得、テレマティクス能力のセットの送信を求める緊急呼応答機関による要求に応答して、緊急呼が確立された後にテレマティクス能力のセットが送信され得る。
さらに、車両緊急呼システムにおけるテレマティクスデータを通信するための方法について説明し、方法は、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第2のエンドポイントにおいて、車両緊急呼システムにおける第1のエンドポイントからテレマティクス能力のセットを受信するステップと、アクションの実施を求める要求を第1のエンドポイントに送信するステップであって、アクションの実施を求める要求は、受信されたテレマティクス能力のセットに少なくとも部分的に基づく、ステップとを含む。
車両緊急呼システムにおけるテレマティクスデータを通信するための装置について説明し、装置は、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第2のエンドポイントにおいて、車両緊急呼システムにおける第1のエンドポイントからテレマティクス能力のセットを受信するための手段と、アクションの実施を求める要求を第1のエンドポイントに送信するための手段であって、アクションの実施を求める要求は、受信されたテレマティクス能力のセットに少なくとも部分的に基づく、手段とを含む。
車両緊急呼システムにおけるテレマティクスデータを通信するための別の装置について説明し、装置は、プロセッサと、プロセッサと電子通信しているメモリと、メモリに記憶された命令とを含み、命令はプロセッサによって、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第2のエンドポイントにおいて、車両緊急呼システムにおける第1のエンドポイントからテレマティクス能力のセットを受信するステップと、アクションの実施を求める要求を第1のエンドポイントに送信するステップであって、アクションの実施を求める要求は、受信されたテレマティクス能力のセットに少なくとも部分的に基づく、ステップとを行うように実行可能である。
車両緊急呼システムにおけるテレマティクスデータを通信するための非一時的コンピュータ可読媒体について説明し、非一時的コンピュータ可読媒体は、通信セッションシグナリングプロトコルにより車両緊急呼システムにおける第2のエンドポイントにおいて、車両緊急呼システムにおける第1のエンドポイントからテレマティクス能力のセットを受信するステップと、アクションの実施を求める要求を第1のエンドポイントに送信するステップであって、アクションの実施を求める要求は、受信されたテレマティクス能力のセットに少なくとも部分的に基づく、ステップとを行うためのコンピュータ実行可能コードを記憶する。
方法、装置、および/またはコンピュータプログラム製品のいくつかの例では、第1のエンドポイントは緊急呼車載システム(IVS)であり得、第2のエンドポイントは緊急呼応答機関であり得る。また、いくつかの例では、緊急呼の確立を求めるIVSからの要求が受信され得、緊急呼応答機関によって緊急呼IVSに、テレマティクス能力のセットの送信を求める要求が送信され得る。
上記では、以下の発明を実施するための形態がよりよく理解され得るように、本開示による例の特徴および技術的利点についてかなり広く概説した。追加の特徴および利点は、以下で説明される。開示する概念および特定の例は、本開示の同じ目的を実行するために他の構造を変更または設計するための基礎として容易に利用され得る。そのような等価な構造は、添付の特許請求の範囲の範囲から逸脱しない。本明細書で開示する概念の特性、それらの編成と動作方法の両方は、添付の図とともに検討されると、関連する利点とともに以下の説明からよりよく理解されよう。図の各々は、特許請求の範囲の限界を定めるものとしてではなく、例示および説明のみの目的で与えられる。
本発明の性質および利点のさらなる理解が、以下の図面を参照することによって実現され得る。添付の図面では、類似の構成要素または特徴は、同じ参照ラベルを有する場合がある。さらに、同じタイプの様々な構成要素は、参照ラベルの後に、複数の類似の構成要素を区別するダッシュおよび第2のラベルを付けることによって、区別され得る。本明細書内で第1の参照ラベルのみが使用される場合、その説明は、第2の参照ラベルとは無関係に、同じ第1の参照ラベルを有する類似の構成要素のうちのいずれか1つに適用可能である。
車両緊急呼システムにおけるテレマティクス能力のサポートをアサートするための1つまたは複数の改善されたシステム、方法、および/または装置に一般に関係する特徴について説明する。一例では、車両端末の車載システム(IVS)が、通信セッションシグナリングプロトコルを使用して緊急呼応答機関(たとえば、緊急応答機関(PSAP: public safety answering point))にテレマティクス能力のセットを送信し得る。テレマティクス能力のセットは、応答機関にテレマティクスデータを送ること/再送すること、および/または外部車両システムを作動させることを含む、IVSが実施することが可能である1つまたは複数のアクションを含むことができる。一実施形態では、テレマティクス能力は、XMLデータ構造など、IVSが対応するアクションを実行することを応答機関が要求することができるフォーマットに対応するフォーマットにおいて、応答機関に送信される。
IVSからテレマティクス能力のセットを受信した後、応答機関は、サポートされるアクションのうちの1つまたは複数をIVSが実行することを要求することによって、応答し得る。要求は、いくつかの実施形態では特定のIVSに合わせられてよく、それにより、応答機関とIVSとの間のシグナリングの量が減り得る。
以下の説明は例を提供し、特許請求の範囲で述べられる範囲、適用可能性、または構成を限定するものではない。本開示の趣旨および範囲から逸脱することなく、論じられる要素の機能および構成に変更を加えることができる。様々な実施形態は、様々な手順または構成要素を、適宜、省略、置換、または追加することができる。たとえば、説明する方法は、説明する順序とは異なる順序で実施されてよく、様々なステップが追加され、省略され、または組み合わされてよい。また、いくつかの実施形態に関して説明する特徴が、他の実施形態と組み合わされてよい。
図1Aは、通信セッションシグナリングプロトコルにより送信されたシグナリングメッセージを通じて端末110と中央サービス(たとえば、緊急応答機関(PSAP)160)との間でテレマティクスデータおよび関連(テレマティクス)メタデータを交換するために使用され得る例示的なワイヤレスネットワークシステム100を示している。後述する図1Bは、図1Aにおけるシステム100の態様の例を示している。いくつかの実施形態では、パケットベースの電話(たとえば、ボイスオーバーインターネットプロトコル(VoIP)、オールIP次世代ネットワーク(NGN)など)を使用して、たとえば、通信セッションシグナリングプロトコル(たとえば、セッション開始プロトコル(SIP))により、端末と中央サービスとの間でテレマティクスデータとメタデータの両方を交換することができる。
テレマティクスデータは、処理のために(中央サービスに送信するために車両などの)端末において生成、収集または記憶されるデータを広く指すことができる。テレマティクスデータは、限定はしないが、車両診断データ(たとえば、ロケーションデータ、エアバッグ展開データ、衝突または衝撃センサデータ、エンジンセンサデータなど)を含むことができる。いくつかの実施形態では、テレマティクスデータの受信側は、中央サービスではなく別のデバイス(たとえば、PC、ラップトップ、モバイル電話、他の車両、他の固定端末またはモバイル端末)であってよく、その場合に受信側はテレマティクスデータを記憶し、それを何らかの方法で処理するか、またはデータを受信の時点または後の時点に中央サービスなどの別のエンティティに転送することができる。転送の一例として、中央サービスとのセッションを確立することができないテレマティクスデータのソースは、中央サービスと連絡することができる何らかの中間デバイスとのセッションを確立することがある。
本明細書および特許請求の範囲で使用するテレマティクスメタデータは、端末と中央サービスとの間で送信されるテレマティクスデータに関連する制御データまたは他のデータを広く指すことができる。たとえば、テレマティクスメタデータは、限定はしないが、テレマティクスデータが中央サービスにおいて受信されたかどうかの確認応答、テレマティクスデータの再送信を求める要求、異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービスによって実行されたアクションを記述した補助データなどを含むことができる。多くの場合、端末によるテレマティクスデータの送信の試みに応答して、テレマティクスメタデータが中央サービスから端末に送信され得る一方、テレマティクスメタデータは端末によって送信されることもある。
通信セッションまたはセッションは、エンドポイントまたは参加者(たとえば、モバイルデバイスおよび中央サーバ)の間のオーディオ、ビデオまたは他のメディアコンテンツのストリーミングを目的としたエンドポイントまたは参加者の間の一時的または半永続的な対話型情報交換を広く指すことができる。
図1Aに示すネットワークシステム100は、訪問先ネットワーク102、ホームネットワーク104、およびサードパーティネットワーク106を含むことができる。訪問先ネットワーク102は、訪問先パブリックランドモバイルネットワーク(V-PLMN)、サービングネットワークなどと呼ばれることもある。ホームネットワーク104は、ホームPLMN(H-PLMN)と呼ばれることもある。訪問先ネットワーク102は、以下の説明の多くで仮定されているように、端末110のホームネットワーク104からローミングしていてよい端末110のサービングネットワークであり得る。端末110がローミングしていない場合に、訪問先ネットワーク102およびホームネットワーク104が同じネットワークであることがある。
訪問先ネットワーク102は、無線アクセスネットワーク(RAN)120、モバイル交換センター(MSC)/ビジターロケーションレジスタ(VLR)130、および簡略化のために図1Aに示されていない他のネットワークエンティティを含むことができる。RAN120は、Global System for Mobile Communications(GSM(登録商標))ネットワーク、広帯域符号分割多元接続(WCDMA(登録商標))ネットワーク、汎用パケット無線サービス(GPRS)アクセスネットワーク、Long Term Evolution(LTE)ネットワーク、CDMA 1Xネットワーク、High Rate Packet Data(HRPD)ネットワーク、Ultra Mobile Broadband(UMB)ネットワークなどであり得る。WCDMA(登録商標)およびGPRSは、Universal Mobile Telecommunication System(UMTS)の一部である。GSM(登録商標)、WCDMA(登録商標)、GPRS、およびLTEは、「3rd Generation Partnership Project」(3GPP)という名称の組織からの文書に記載されている。CDMA 1XおよびHRPDは、cdma2000の一部であり、cdma2000およびUMBは、「3rd Generation Partnership Project 2」(3GPP2)という名称の組織からの文書に記載されている。MSC130は、回線交換呼のための交換機能を実行することができ、ショートメッセージサービス(SMS)メッセージをルーティングすることもできる。VLR130は、訪問先ネットワーク102に登録している端末に関する登録情報を記憶することができる。いくつかのタイプのRAN(たとえば、LTE、GPRSまたはHRPD RAN)の場合、MSC/VLR130は他のエンティティに、たとえば、GPRSの場合にはServing GPRS Support Node(SGSN)またはLTEの場合にはモビリティ管理エンティティ(MME)に取って代わられ得る。
ホームネットワーク104は、ホームロケーションレジスタ(HLR)/認証センター(AC)140および簡単にするために図1Aに示されていない他のネットワークエンティティを含むことができる。HLR140は、ホームネットワーク104のサービスに加入している端末に関する加入情報を記憶することができる。AC140は、ホームネットワーク104のサービスに加入している端末に関する認証を実行することができる。いくつかのネットワークでは、HLR140はホーム加入者サーバ(HSS)に取って代わられ得る。場合によっては、端末110が通常の通信サービスに加入していない場合、たとえば緊急呼を行うことのみに制限されている場合に、ホームネットワーク104がないことがある。
サードパーティネットワーク106は、ルータ150(たとえば、PSAP選択的ルータ)、中央サービス160(たとえば、PSAP)、公衆交換電話網(PSTN)170、および場合によっては図1Aに示されていない他のネットワークエンティティを含むことができる。ルータ150は、MSC130と中央サービス160との間で呼をルーティングすることができる。中央サービス160は、緊急呼に応じる責任を負ってよく、緊急センター(EC)と呼ばれることもある。中央サービス160は、政府機関、たとえば郡または市によって、または政府機関のために運営または所有され得る。PSTN170は、電話180などの従来型の有線電話に電話サービスを提供することができる。いくつかの例では、サードパーティネットワーク106は、中央サービス160(たとえば、PSAP)と通信するように構成され得る少なくとも1つのサードパーティ中央サービス(図示せず)を含むこともできる。たとえば、サードパーティ中央サービスは、自動車メーカーによって運営される民間サービス、または自動車メーカーの系列の民間サービスであり得る。いくつかの例では、サードパーティ中央サービスは、端末110からの一部または全部の緊急呼を受信し、適切な場合にはPSAP中央サービス160にデータまたは呼を転送することができる。
図1Aは、訪問先ネットワーク102およびホームネットワーク104に存在し得るネットワークエンティティの一部のみを示している。たとえば、訪問先ネットワーク102は、パケット交換呼および他のサービスをサポートするネットワークエンティティならびに端末のロケーションを取得するのを支援するロケーションサーバを含むことができる。
端末110は、固定式または移動式であってよく、GSM(登録商標)およびCDMA 1Xにおける移動局(MS)、WCDMA(登録商標)およびLTEにおけるユーザ機器(UE)、HRPDにおけるアクセス端末(AT)、セキュアユーザプレーンロケーション(SUPL)におけるSUPL対応端末(SET)、加入者ユニット、局などと呼ばれることもある。端末110は、セルラー電話もしくは他のワイヤレス通信デバイス、パーソナル通信システム(PCS)デバイス、パーソナルナビゲーションデバイス(PND)、個人情報マネージャ(PIM)、携帯情報端末(PDA)、ラップトップ、またはワイヤレス通信および/またはナビゲーション信号を受信することができる他の適切なモバイルデバイスなどのデバイスであり得る。
端末110はまた、衛星信号受信、支援データ受信、および/または位置関連処理がそのデバイスにおいて行われるか、またはパーソナルナビゲーションデバイス(PND)において行われるかにかかわらず、短距離ワイヤレス接続、赤外線接続、有線接続、または他の接続によってなど、PNDと通信する1つまたは複数のデバイスを含むことができる。また、端末110は、衛星信号受信、支援データ受信、および/または位置関連処理がそのデバイスにおいて行われるか、サーバにおいて行われるか、またはネットワークに関連する別のデバイスにおいて行われるかにかかわらず、インターネット、Wi-Fi、または他のネットワークを介してなど、サーバとの通信が可能であるワイヤレス通信デバイス、コンピュータ、ラップトップなどを含むすべてのデバイスを含むものとする。上記における動作可能な任意の組合せも含まれる。端末110は、車両190に永続的に取り付けることができる(場合によっては車両190の一部である)、緊急呼に専用のものであるか、またはより広い機能セットを扱う、緊急呼車載システム(IVS)であり得る。端末110は、車両に取り付けられたセンサもしくは車両に取り付けられたセンサのための制御ユニット、または(たとえばワイヤレス手段を介して)端末110にテレマティクスデータを送ることが可能で、場合により端末110から中央サーバへのセッションを引き起こすことが可能なテレマティクスデータの何らかの他のソースなど、図1Aに示されていない1つまたは複数の他のデバイスに関連付けられ得る。
端末110は、ホームネットワーク104のサービスに加入していてよく、図1Aに示すように訪問先ネットワーク102においてローミングしていることがある。端末110は、訪問先ネットワーク102においてRAN120から信号を受信してもよいし、またはRANと通信して通信サービスを取得してもよい。端末110は、ローミングしていないとき(図1Aに示されていない)に通信サービスを求めてホームネットワーク104と通信することもある。いくつかの実施形態では、端末110は、中央サービス160との間でセッションが必要とされ得る時点まで、RAN120からの信号を監視するが、RAN120と通信しないことがある。そのような実施形態は、訪問先ネットワーク102に対するシグナリング負荷を低減し、端末110のユーザへの購読課金(subscription charger)を回避または最小化するのに有利であり得る。端末110は、衛星測位システム(SPS)の一部であり得る1つまたは複数の衛星195からの信号を受信することもできる。SPSは、エンティティが、地上または上空での自身のロケーションを、送信機から受信された信号に少なくとも部分的に基づいて特定することを可能にするように配置された、送信機のシステムを含むことができる。そのような送信機は、設定された数のチップの繰返し擬似ランダム雑音(PN)コードによりマークされた信号を送信することができ、地上の制御局、ユーザ機器、および/または宇宙ビークルに配置され得る。
特定の例では、そのような送信機は、地球を周回する衛星ビークル(SV)に配置され得る。たとえば、全地球測位システム(GPS)、Galileo、GlonassまたはCompassのようなある配置の全地球航法衛星システム(GNSS)におけるSVは、その配置における他のSVにより送信されるPNコードと区別できるPNコードによりマークされる信号を(たとえば、GPSのように衛星ごとに異なるPNコードを用いて、またはGlonassのように異なる周波数で同一のコードを用いて)、送信することができる。特定の態様によれば、本明細書で提示する技術は、SPSのための全地球システム(たとえばGNSS)には限定されない。たとえば、本明細書で提供する技術は、たとえば、日本の準天頂衛星システム(QZSS)、インドのインド地域航法衛星システム(IRNSS)、中国の北斗などのような様々な地域システム、および/または、1つまたは複数の全地球および/または地域航法衛星システムと関連し得る、または場合によってはこれらとともに使用できるようにされ得る、様々な補強システム(たとえば、静止衛星型衛星航法補強システム(SBAS))に対して適用されてもよく、またはそれらのシステムにおいて使用できるようにされてもよい。
限定ではなく例として、SBASは、たとえば、広域補強システム(WAAS)、European Geostationary Navigation Overlay Service(EGNOS)、運輸多目的衛星用衛星航法補強システム(MSAS)、GPS Aided Geo Augmented Navigation、またはGPS and Geo Augmented Navigationシステム(GAGAN)などのような、インテグリティ情報、差分修正などを提供する、補強システムを含み得る。したがって本明細書で使用する場合、SPSは1つまたは複数の全地球および/または地域航法衛星システムおよび/または補強システムの任意の組合せを含むことがあり、またSPS信号はSPS信号、SPS様信号、および/またはそのような1つまたは複数のSPSに関連する他の信号を含んでよい。端末110は、衛星195からの信号を測定し、衛星の擬似距離測定値を取得することができる。端末110は、RAN120における基地局からの信号を測定し、基地局のタイミングおよび/または信号強度の測定値を取得することもできる。擬似距離測定値、タイミング測定値、および/または信号強度測定値は、端末110の位置推定値を導出するために使用され得る。位置推定は、ロケーション推定、位置決定などとも呼ばれ得る。
端末110は、端末に割り当てられた一意の番号である国際モバイル機器識別情報(IMEI)を有し得る。端末110は、ユーザのサービス加入に使用され得る。サービス加入は、GSM(登録商標)およびUMTSネットワークの加入に割り当てられた一意の番号である国際モバイル加入者識別情報(IMSI)に関連付けられ得る。サービス加入はまた、サービス加入の電話番号であるモバイル加入者統合サービスデジタルネットワーク番号(MSISDN)に関連付けられ得る。IMSIは、HLR140の加入者データベースにおけるサービス加入のキーとして使用され得る。MSISDNは他のユーザによって、サービス加入に使用される端末110に呼を接続するためにダイヤルされ得る。IMSI、MSISDN、および他の加入情報は、端末110に挿入され得る加入者識別モジュール(SIM)または汎用加入者識別モジュール(USIM)に記憶され得る。端末110はまた、SIM/USIMを有しないことがあり、この場合に端末110はIMEIのみを有するが、IMSIもMSISDNも有しないことがある。
ワイヤレスネットワークは、様々なタイプの緊急呼をサポートすることができる。1つのタイプは、ユーザが北米の911および欧州の112などの周知の緊急電話番号をダイヤルすることによって発信する「通常の」緊急呼を含むことができる。別のタイプはeCallを含むことができ、これは、上述の特性を有することがあり、中央サービスへのテレマティクスデータの転送ならびに端末110のユーザと中央サービスとの間の音声および/または他のメディア通信のサポートを含み得る緊急呼である。eCallのサポートは、欧州連合によって、また世界の他の地域および/または国によって必要とされることがある。eCallは、呼を発する方法およびeCallを確立するために送られ、eCallを処理するために使用され得る追加の緊急関連データは、通常の緊急呼とは異なり得る。たとえば、追加データは、eCallがどのように開始されたか(たとえば、ユーザによって手動で開始されたか、またはセンサデータまたはセンサトリガに応答して自動的に開始されたか)、車両タイプおよび車両識別番号(VIN)、タイムスタンプ、位置推定および位置信頼フラグ、移動方向、(たとえば、シート占有センサによる)乗客の数、他の乗客データ(たとえば、締められたシートベルト)、端末110のサービスプロバイダ(存在する場合)、トリガタイプ(たとえば、展開されたエアバッグ、バンパーセンサ、火災表示灯、転覆、または他の状況検出など)、ならびに場合により他の情報を示し得る。追加データにより、端末の正確な地理的ロケーションを中央サービス160に提供することが可能になることもある。別のタイプは、いくつかの態様ではeCallとは異なる車両緊急呼を含み得る。
いくつかの例では、端末110は、中央サービス160(たとえば、PSAP)に対する緊急呼を開始するように構成され得る。緊急呼は、ユーザからの手動入力に応答して、または1つまたは複数の検出された状況(たとえば、展開されたエアバッグ、衝突センサ、火災表示灯、転覆、または他の状況検出など)に応答して開始され得る。緊急呼を開始するために、端末110は、通信セッションシグナリングプロトコル、たとえばセッション開始プロトコル(SIP)、Extensible Messaging and Presence Protocol(XMPP)、Googleトーク、スカイプ、OSCAR、もしくはMicrosoft Messenger Service、または別の通信セッションシグナリングプロトコルを使用して、中央サービス160またはサードパーティ中央サービス(図示せず)との間でパケットベースの呼(たとえば、音声呼、テキスト、IMまたはビデオ通信を伴うパケットベースのデータ呼など)を確立することができる。端末110は、通信セッションシグナリングプロトコルにより第1のシグナリングメッセージにおいてテレマティクスデータのセットを送信することができ、中央サービス160またはサードパーティ中央サービスは、通信セッションシグナリングプロトコルにより第2のシグナリングメッセージを介して、テレマティクスデータが中央サービスにおいて受信されたかどうかの確認応答、テレマティクスデータの再送信を求める要求、異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービスによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータなど、テレマティクスデータのセットに関するメタデータで応答することができる。このようにして、テレマティクスデータおよび関連テレマティクスメタデータの送信は、音声および/または他のメディア(たとえば、インスタントメッセージ(IM)、テキスト、ビデオなど)通信とは別個に生じることがあり、したがって、メディアストリーム(たとえば、メディアチャネル)を中断する必要はない。その上、テレマティクスデータおよび関連テレマティクスメタデータは、端末110と中央サービスとの間で、音声チャネル変調により可能である場合よりもはるかに効率的および迅速に交換され得る。さらに、テレマティクスデータおよび関連テレマティクスメタデータは、セッションおよび/または音声チャネルとの関連付けまたは協調が可能である(たとえば、テレマティクスデータおよび関連テレマティクスメタデータは、音声チャネルを扱っている同じPSAPの間で交換され得る)。
いくつかの実施形態では、端末110は、通信セッションシグナリングプロトコルを使用して中央サービス160(たとえば、緊急呼応答機関またはPSAP)にテレマティクス能力のセットを送信するように構成され得る。一例では、端末110は、第1のシグナリングメッセージにおいてテレマティクスデータのセットとともに能力を送信することができる一方、他の実施形態では、端末110は、たとえば、能力のセットの送信を求める中央サービスからの要求に応答して、後続のシグナリングメッセージにおいて能力を送信することができる。
能力のセットは、端末(たとえば、車両の緊急IVS)が実施することが可能である1つまたは複数のアクション、たとえば、追加のテレマティクスデータを収集すること、車両の状態に影響を与えるアクションを実施すること、車両の構成要素をアクティブ化すること、車両の構成要素を非アクティブ化すること、車両のイグニションをオフにすること、車両のイグニションをオンにすること、車両の燃料供給をオフにすること、車両の燃料供給をオンにすること、ドアの鍵を開けること、ドアの鍵を閉めること、車両のクラクションをアクティブ化すること、外部可聴音をアクティブ化すること、車両のライトをアクティブ化すること、車両の点滅灯をアクティブ化すること、パワーウィンドウを作動させること、録音メッセージを再生すること、メディアをレンダリングすること、テキストメッセージを表示すること、カメラをアクティブ化すること、カメラを非アクティブ化すること、またはそれらの組合せを含み得る。
以下でより詳細に説明するように、能力のセットは、1つまたは複数のアクションの実施を求める要求を緊急呼IVSが受け入れる要求データ構造に対応する能力データ構造において送信され得る。一例では、能力データ構造は、要求データ構造と実質的に同等であり得る。また、一例では、能力データ構造は、拡張マークアップ言語(XML)要素としてフォーマットされ得る。能力データ構造がXML要素である場合、1つまたは複数のアクションはそれぞれ、能力XMLデータ構造内の子XML要素として含まれ得、随意に、アクションに対応するパラメータ(たとえば、アクションが実行されるべき持続時間、またはアクションに関係する別のパラメータ)が子XML要素のパラメータである。別の例では、パラメータは、可能なアクションに対応する子XML要素内の子XML要素として含まれ得る。XMLフォーマッティングは能力データ構造をフォーマットする1つの方法にすぎないこと、および多くの他の方法が企図され、本開示の範囲内にあることが諒解されよう。
いくつかの実施形態では、端末110が実施することが可能であるアクションを有する能力データ構造を端末110に送信させることで、異なる車両によって、または経時的に同じ車両によってサポートされる多種多様なアクションを受け入れることができる。このようにして、所与の端末110によってサポートされる能力のセットは、経時的に再構成され得る。たとえば、IVSのメーカー、車両のメーカー、テレマティクスサービスプロバイダ、または別の指定エンティティは、特定の端末110に関連する能力のセットを再構成することができる。別の例では、能力のセットはIVS自体によって、アクションに関連する車両構成要素の動作状態に少なくとも部分的に基づいて動的に再構成され得る(たとえば、事故の間にヘッドライトが損傷したことをIVSが認識した場合、IVSは、中央サービス160に送信される能力のセットから、ライトを照らすことを除去し得る)。
図1Bは、図1Aに示すシステム100の態様の一例であり得る、様々な実施形態による、LTE/LTE-Advancedネットワークアーキテクチャを示す図である。LTE/LTE-Aネットワークアーキテクチャは、発展型パケットシステム(EPS)101と呼ばれることがあり、いくつかの実施形態では、図1Aの端末110と中央サービス160との間でデータを送信するために使用され得る。図1BのEPS101は、1つまたは複数の端末110-a(たとえば、ユーザ機器(UE))、発展型UMTS Terrestrial Radio Access Network(E-UTRAN)115、発展型パケットコア(EPC)125、ホーム加入者サーバ(HSS)135を含むことができ、他のIPサービスおよびネットワーク175に接続することができる。EPS101は、他のアクセスネットワークと相互接続し得るが、簡単にするために、それらのエンティティ/インターフェースは示されていない。図示のように、EPS101はパケット交換サービスを提供するが、当業者が容易に諒解するように、本開示の全体を通して提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。
E-UTRAN115は、基地局105-a(たとえば、発展型ノードB(eNB))および他の基地局105-bを含むことができる。基地局105-aは、端末110-aへのユーザプレーンプロトコル終端および制御プレーンプロトコル終端を提供することができる。端末110-aは、図1Aの端末110の一例であってよい。基地局105-aは、X2インターフェース(たとえば、バックホール)を介して他の基地局105-bに接続され得る。基地局105-aは、EPC125へのアクセスポイントを端末110-aに提供することができる。基地局105-aは、S1インターフェースによってEPC125に接続され得る。EPC125は、1つまたは複数のモビリティ管理エンティティ(MME)145、1つまたは複数のサービングゲートウェイ155、および1つまたは複数のパケットデータネットワーク(PDN)ゲートウェイ165を含むことができる。MME145は、端末110-aとEPC125との間のシグナリングを処理する制御ノードである。概して、MME145は、ベアラおよび接続の管理を行い、端末110-aなどの端末のモビリティを管理することができる。すべてのユーザIPパケットは、サービングゲートウェイ155を通じて転送されてよく、サービングゲートウェイ155自体は、PDNゲートウェイ165に接続され得る。PDNゲートウェイ165は、端末のIPアドレス割振りならびに他の機能を提供することができる。PDNゲートウェイ165は、EPS101のためにオペレータによって所有され運営されるIPサービスを含む他のIPサービスおよびネットワーク175に接続され得る。他のIPサービスおよびネットワーク175は、インターネット、イントラネット、IPマルチメディアサブシステム(IMS)、およびパケット交換(PS)ストリーミングサービス(PSS)を含み得る。他のIPサービスおよびネットワーク175は、緊急サービスIPネットワーク(ESInet)185を含むこともでき、ESInet185は、何らかの公共(たとえば、公共安全)組織によって、または当該組織のために所有または運営され得る。
PDNゲートウェイ165はまた、プロキシ呼セッション制御機能(P-CSCF:Proxy-Call Session Control Function)103に接続され得る。P-CSCF103は、緊急呼セッション制御機能(E-CSCF:Emergency-Call Session Control Function)109に接続され得る。いくつかの例(たとえば、エンタープライズネットワーク)では、P-CSCF103は、サービング呼セッション制御機能(S-CSCF:Serving-Call Session Control Function)107を通じてE-CSCF109に接続され得る。P-CSCF103、E-CSCF109、およびS-CSCF107は、EPS101のためのIMSの一部であり得る。端末110-aがIMSデバイスである場合、端末110-aはそのセルラーキャリアのネットワークにINVITEを送ることができる(たとえば、端末110-aはP-CSCF103にINVITEを送ることができ、P-CSCF103はE-CSCF109にINVITEを転送することができ、E-CSCF109は緊急サービスネットワーク(ESInet)185にINVITEを転送することができ、ESInet185は適切なPSAP(たとえば、中央サービス160-a)を判断し、そこにINVITEを転送することができる)。
ESInet185は、中央サービス160-a(たとえば、PSAP)を含むことができ、これは図1Aの中央サービス160の一例であってよい。中央サービス160-aは、緊急サービスルーティングプロキシ(ESRP:Emergency Services Routing Proxy)111に接続され得る。ESRP111は、緊急呼ルーティング機能(ECRF:Emergency Call Routing Function)113に接続され得る。
端末110-aは、たとえば、多入力多出力(MIMO)、多地点協調(CoMP)または他の方式を通じて、複数の基地局105と共同通信するように構成され得る。MIMO技法は基地局上の複数のアンテナおよび/または端末上の複数のアンテナを使用して、マルチパス環境を利用することで、複数のデータストリームを送信する。CoMPは、端末のための送信品質全体を改善するとともに、ネットワークおよびスペクトルの利用を増大させるための、複数の基地局による送信および受信の動的協調のための技法を含む。
いくつかの例では、端末110-aは、中央サービス160-a(たとえば、PSAP)に対する緊急呼を開始するように構成され得る。緊急呼は、ユーザからの手動入力に応答して、または1つまたは複数の検出された状況(たとえば、展開されたエアバッグ、衝突センサ、火災表示灯、転覆、または他の状況検出など)に応答して開始され得る。緊急呼は、通信セッションシグナリングプロトコル(たとえば、SIP)に関係するシグナリングの第1のセット117(たとえば、テレマティクス情報を含み得る)および通信セッションに関係するシグナリングの第2のセット119(たとえば、音声/データ)を含むことができる。基地局105-aは、シグナリングの第1のセット117およびシグナリングの第2のセット119をサービングゲートウェイ155にルーティングすることができる。サービングゲートウェイ155は、シグナリングの第1のセット117およびシグナリングの第2のセット119をPDNゲートウェイ165にルーティングすることができる。PDNゲートウェイ165は、シグナリングの第1のセット117をP-CSCF103にルーティングすることができ、シグナリングの第2のセット119を中央サービス160にルーティングすることができる。P-CSCF103は、シグナリングの第1のセット117をE-CSCF109にルーティングすることができる。場合によっては(たとえば、エンタープライズネットワークでは)、P-CSCF103は、シグナリングの第1のセット117をS-CSCF107経由でE-CSCF109にルーティングすることができる。E-CSCF109は、シグナリングの第1のセット117をESRP111にルーティングすることができる。ESRP111は、シグナリングの第1のセット117を中央サービス160-aにルーティングすることができる。したがって、テレマティクスデータおよび関連テレマティクスメタデータは、セッションおよび/またはメディアストリームとの関連付けまたは協調が可能である(たとえば、テレマティクスデータおよび関連テレマティクスメタデータは、メディアストリームを扱っている同じPSAPの間で交換され得る)。メディアストリームは、音声、メッセージ単位テキスト(たとえば、IM)、文字単位テキスト(たとえば、ストリーミングテキスト、リアルタイムテキスト)、オーディオ、ビデオを含む任意のストリーミングメディア、および/またはテキストメッセージなどの任意の非ストリーミングメディアを含むことができる。場合によっては、メディアストリームと呼ばれ得るものにおいて交換されるメディアは、非ストリーミングメディアのみを搬送することができる。
上記のように、端末に対応する能力のセットも、端末110-aから送信され得る。能力のセットは、シグナリングの第1のセット117または第2のセット119の一方または両方において転送され得る。
図2は、本システムおよび方法による、端末110-bの一実施形態を示すブロック図200である。端末110-bは、図1Aの端末110および/または図1Bの端末110-aの一例であってよい。端末110-bは、端末受信機モジュール205、テレマティクスデータシグナリングモジュール210、および端末送信機モジュール215を含むことができる。これらの構成要素の各々は、互いに通信していてよい。端末110-bは、図2に示されていない他のモジュールを含むことができ、たとえば、車両に関連する状況および事象を検出するためのセンサならびにGPS衛星から受信したワイヤレス信号から端末のロケーションを推定または判断することを可能にするための受信機およびプロセッサを含むことができる。
端末110-bのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一構成では、端末受信機モジュール205は、セルラー受信機を含むことができ、基地局105から送信を受信することができる。一例では、端末受信機モジュール205は、テレマティクスメタデータを含むように適合されている、通信シグナリングプロトコルに関するシグナリングメッセージを受信することができる。テレマティクスデータシグナリングモジュール210は、適合されたシグナリングメッセージからテレマティクスメタデータを抽出することができる。テレマティクスデータシグナリングモジュール210は、テレマティクスデータを含むように通信シグナリングプロトコルに関するシグナリングメッセージを適合することもできる。通信シグナリングプロトコルに関する適合されたシグナリングメッセージは、端末送信機モジュール215を介して送信され得る。テレマティクスデータシグナリングモジュール210に関する詳細については、以下で説明する。
図3は、本システムおよび方法による、端末110-cの一実施形態を示すブロック図300である。端末110-cは、図1A、図1B、および/または図2に示す端末110の一例であってよい。端末110-cは、前述のように、端末受信機モジュール205、テレマティクスデータシグナリングモジュール210-a、および端末送信機モジュール215を含むことができる。これらの構成要素の各々は、互いに通信していてよい互いに通信していてよい。
端末110-cのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一実施形態では、テレマティクスデータシグナリングモジュール210-aは、テレマティクスデータモジュール315を含むことができる。テレマティクスデータモジュール315は、テレマティクスデータを生成および/または取得することができる。テレマティクスデータモジュール315は、テレマティクスメタデータを受信することもできる。いくつかの例では、テレマティクスデータモジュール315は、受信したテレマティクスメタデータに基づいてテレマティクスデータを取得することができる。
テレマティクスデータシグナリングモジュール210-aは、セッション制御モジュール310を含むこともできる。セッション制御モジュール310は、1つまたは複数のシグナリングメッセージを使用して、通信セッションを制御および/または促進することができる。いくつかの実施形態では、セッション制御モジュール310は、通信セッションシグナリングプロトコルに従ってセッション情報を通信することによって、通信セッションを制御および/または促進することができる。一例では、セッション制御モジュール310は、信号情報のセット(たとえば、第1のセット)を含むシグナリングメッセージを生成することができる。セッション制御モジュール310は、信号情報のセット(たとえば、第2のセット)を含むシグナリングメッセージを取得することもできる。
一実施形態では、テレマティクスデータシグナリングモジュール210-aは、セッション/テレマティクスメタデータ分離モジュール305を含むことができる。前述のように、シグナリングメッセージが、セッション情報とともにテレマティクスデータおよび/またはテレマティクスメタデータを含むように適合され得る。たとえば、シグナリングメッセージが、セッション情報の第2のセットおよびテレマティクスメタデータの第1のセットを含むように適合され得る。セッション/テレマティクスメタデータ分離モジュール305は、適合されたシグナリングメッセージからテレマティクスメタデータを抽出することができる。セッション/テレマティクスメタデータ分離モジュール305は、セッション制御モジュール310に(たとえば、シグナリングメッセージの形で)セッション情報を提供することができ、テレマティクスデータモジュール315にテレマティクスメタデータを提供することができる。
テレマティクスデータシグナリングモジュール210-aは、セッション/テレマティクスデータ結合モジュール320を含むこともできる。セッション/テレマティクスデータ結合モジュール320は、テレマティクスデータモジュール315からのテレマティクスデータを含むように、セッション制御モジュール310によって生成されたシグナリングメッセージを適合することができる。一例では、適合されたシグナリングメッセージは、セッション情報の第1のセットおよびテレマティクスデータの第1のセットを含むことができる。適合されたシグナリングメッセージは、端末送信機モジュール215を介して送信され得る。
図4は、本システムおよび方法による、端末110-dの一実施形態を示すブロック図400である。端末110-dは、図1A、図1B、図2、および/または図3の端末110の一例であってよい。一構成では、端末110-dは、端末受信機モジュール205、テレマティクスデータシグナリングモジュール210-b、および端末送信機モジュール215を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
端末110-dのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一例では、端末110-dは、少なくとも、テレマティクスデータを収集し、中央サービスとの通信セッションを確立し、通信セッションシグナリングプロトコルの適合された使用を通じて中央サービスにテレマティクスデータを送信し、通信セッションシグナリングプロトコルの適合された使用により中央サービスからテレマティクスメタデータを受信し、受信されたテレマティクスメタデータに基づいて一定のアクションを実行するように構成され得る。
テレマティクスデータシグナリングモジュール210-bは、セッション制御モジュール310-aを含むことができる。セッション制御モジュール310-aは、SIP/SDPモジュール405およびセッション実施モジュール410を含むことができる。SIP/SDPモジュール405は、中央サービスとの通信セッションを交渉し、セットアップし、管理し、かつ終了させるように構成され得る。SIP/SDPモジュール405は、中央サービスとの間でセッション関連シグナリングデータを通信するためにSIPシグナリングメッセージヘッダコンテンツおよびSDPコンテンツを生成することができる。セッション実施モジュール410は、メディアコンテンツ(たとえば、音声呼のためのオーディオデータ、ビデオ呼のためのオーディオおよびビデオデータ、音声またはビデオを伴うか、または伴わない、テキストを伴う呼のためのテキストデータ)を受信し、交渉されたセッションに従って中央サービスにパケットのストリームとしてメディアコンテンツを送信し、かつ交渉されたセッションに従って中央サービスからメディアコンテンツを含むパケットのストリームを受信するように構成され得る。
テレマティクスデータシグナリングモジュール210-bは、テレマティクスデータモジュール315-aを含むこともできる。テレマティクスデータモジュール315-aは、テレマティクスデータ収集モジュール430、テレマティクスデータメッセージモジュール425、テレマティクスメタデータ分析モジュール415、および外部システム制御モジュール420を含むことができる。テレマティクスデータ収集モジュール430は、端末110-dに関連するシステムまたはデバイスからテレマティクスデータを収集することができる。たとえば、端末110-dが車両に関連付けられる場合、テレマティクスデータ収集モジュール430は、車両タイプおよび車両識別番号(VIN)、1つもしくは複数のタイムスタンプ、位置推定および関連する信頼度、移動方向、(たとえば、締められたシートベルトによる)乗客の数、端末のサービスプロバイダ(存在する場合)、トリガタイプ(たとえば、展開されたエアバッグ、バンパーセンサ、手動トリガ、火災表示灯、転覆、または他の状況検出など)、ならびに/または本明細書で説明する原理の特定の適用に適したものであり得る他の関連情報に関係するデータを収集することができる。
テレマティクスデータモジュール315-aのテレマティクスデータメッセージモジュール425は、中央サービスによって理解されるプロトコルに従って中央サービスに送信するためにテレマティクスデータをフォーマットすることができる。いくつかの例では、テレマティクスデータメッセージモジュール425は、中央サービスに送信するためにテレマティクスデータの標準セットをコンパイルすることができる。追加または代替として、テレマティクスデータメッセージモジュール425は、中央サービスに送信するために中央サービスから要求された特定のテレマティクスデータのセットをコンパイルするように構成され得る。
テレマティクスデータモジュール315-aは、テレマティクスメタデータ分析モジュール415をさらに含むことができる。テレマティクスメタデータ分析モジュール415は、中央サービスに送信されたテレマティクスデータに関連する中央サービスから受信されたテレマティクスメタデータに基づいて実行され得るアクションを識別するために、テレマティクスメタデータを分析することができる。識別されるアクションは、具体的に中央サービスによって要求されること、またはテレマティクスメタデータ分析モジュール415によって、受信されたテレマティクスメタデータに基づいて推測されることがある。たとえば、テレマティクスメタデータは、テレマティクスデータの再送信、テレマティクスデータの異なるセットの送信、またはテレマティクスデータのセットの更新バージョンの送信を求める要求を含むことができる。テレマティクスメタデータ分析モジュール415は、適切なテレマティクスメタデータおよび/または適切な命令をテレマティクスデータメッセージモジュール425および/または外部システム制御モジュール420に提供することができる。
テレマティクスデータモジュール315-aの外部システム制御モジュール420は、中央サービスに送信されたテレマティクスデータに関連する中央サービスから受信されたテレマティクスメタデータに基づいて、1つまたは複数のアクションを実行するように構成され得る。端末110-dが車両に関連付けられ、検出された衝突に応答して中央サービスにテレマティクスデータが送信される例を再び参照すると、テレマティクスメタデータは、車両およびその搭乗者に関する一定の予防アクションまたは救助アクションの実行を求める命令を含むことができる。そのようなアクションは、限定はしないが、追加のテレマティクスデータを収集すること、車両のイグニションをオフもしくはオンにすること、車両の燃料供給をオフもしくはオンにすること、車両のドアの鍵を開けること、もしくは閉めること、車両のクラクションをアクティブ化すること、外部可聴音を再生すること、車両のライト(たとえば、ヘッドライト、ランニングライト)をオンにすること、車両の内部(たとえば、車内)ライトをオンにすること、車両の点滅灯(たとえば、4方向、緊急点滅灯、警告ライト)をオンにすること、パワーウィンドウを作動させること、中央サービスから受信されたか、もしくは110-dに記憶された録音メッセージを再生すること、メディアをレンダリングすること(たとえば、テキスト読み上げをレンダリングすること、中央サービスによって送られたメディアを再生すること、中央サービスによって送られた命令によって参照され、かつ/または当該命令に関連するメディアを再生すること)、中央サービスから受信されたか、もしくは110-dに記憶されたテキストメッセージを表示すること、または他の適切なアクションを含み得る。クラクションをアクティブ化すること、外部可聴音を再生すること、ライトをオンにすること、および/または点滅灯をオンにすることなどにより、車両のロケーションの非常要員に警告すること、または通知することができることに留意されたい。
テレマティクスデータシグナリングモジュール210-bは、セッション/テレマティクスメタデータ分離モジュール305を含むことができる。セッション/テレマティクスメタデータ分離モジュール305は、変更されたSIPまたは他の通信セッションシグナリングプロトコルメッセージを(たとえば、端末受信機モジュール205を介して)受信することができ、SIP/SDP(または他のプロトコル)情報をテレマティクスメタデータメッセージから分離することができる。いくつかの実施形態では、セッション/テレマティクスメタデータ分離モジュール305は、上で説明したように、SIP/SDP(または他のプロトコル)情報をSIP/SDPモジュール405に提供することができ、1つまたは複数のテレマティクスメタデータメッセージをテレマティクスメタデータ分析モジュール415に提供することができる。一例では、セッション/テレマティクスメタデータ分離モジュール305は、変更されたSIPメッセージの様々な部分を、変更されたSIPメッセージのヘッダからの情報に基づいて識別することができる。この例では、セッション/テレマティクスメタデータ分離モジュール305は、上で説明したように、SIP/SDP情報として識別された部分をSIP/SDPモジュール405に提供することができ、テレマティクスメタデータメッセージとして識別された部分をテレマティクスメタデータ分析モジュール415に提供することができる。
テレマティクスデータシグナリングモジュール210-bは、セッション/テレマティクスデータ結合モジュール320を含むこともできる。セッション/テレマティクスデータ結合モジュール320は、上で説明したように、SIP/SDPモジュール405からのSIP/SDP(または他のプロトコル)情報およびテレマティクスデータメッセージモジュール425からの1つまたは複数のテレマティクスデータメッセージを結合して、変更されたSIPまたは他の通信セッションシグナリングプロトコルメッセージにすることができる。端末送信機モジュール215は、生成されたシグナリングメッセージを中央サービスに送信することができる。
図5A、図5B、および図5Cは、セッションデータとテレマティクスデータの両方を搬送するために変更されたセッション開始プロトコル(SIP)要求メッセージの一例を示している。図5Aは、要求メッセージの例示的なフォーマット500の図を示しており、図5Bおよび図5Cは、図5Aのフォーマットに基づく例示的なSIP要求メッセージ550の内容の図を示している。図5A、図5B、および図5Cの例は、変更され転用されたSIP要求メッセージの文脈で記述されているが、本明細書の原理を他の通信セッションシグナリングプロトコル(たとえば、XMPP、Googleトーク、MSNなど)を変更または拡張するために、または新しい通信セッションシグナリングプロトコルの土台として使用できることが理解されよう。
セッションデータとテレマティクスデータの両方を搬送するためにSIPプロトコルを転用することによって、テレマティクスデータは、関連呼の中断またはその品質の劣化を伴うことなく中央サービスに効率的に送信され得る。図5Aに示すように、変更されたSIP要求メッセージフォーマット500は、要求ライン505、ヘッダ510、セッション情報のセット515(たとえば、セッションパラメータ、セッションデータ)、およびテレマティクスデータのセット520を含むことができる。SIPプロトコルは、Internet Engineering Task Force(IETF)によって、RFC3261などのいくつかのRequest For Comments標準において定義されている。これらの標準は、INVITEメッセージ、ACKメッセージ、BYEメッセージ、CANCELメッセージ、OPTIONSメッセージ、REGISTERメッセージ、PRACKメッセージ、SUBSCRIBEメッセージ、NOTIFYメッセージ、PUBLISHメッセージ、INFOメッセージ、REFERメッセージ、MESSAGEメッセージ、およびUPDATEメッセージを含む、いくつかのSIP要求および応答メッセージを定義している。本フォーマット500は、これらのメッセージの各々に、ならびに他のタイプの要求および応答メッセージに使用され得る。
図5Bの例では、図5Aのフォーマットに基づく変更されたSIP INVITEメッセージ550-aが、たとえば、端末によって、同時に中央サービスとの呼または他の通信セッションを要求し、テレマティクスデータをその中央サービスに送信するために使用され得る。このようにして、中央サービスが端末との呼を確立することが不可能な(または拒絶する)場合でも、中央サービスによってテレマティクスデータが受信され得る。
例示的なSIP INVITEメッセージ550-aの要求ライン505-aは、メッセージ550-aを要求として識別し、行われている要求のタイプ(たとえば、INVITE)を明示することができる。要求メッセージのヘッダ510-aは、要求のソース、要求の予定受信側(たとえば、緊急サービスURN)、呼識別子、ソースに関する連絡先情報、呼連続番号、本文におけるデータのタイプの指示、およびメッセージの長さを定義することができる。本例では、ヘッダ510-aは、本文が混合データを含むことを明示することができ、文字列"-----NextPart-----"は、本文における異なるタイプのデータの間の境界を示している。本例では、メッセージの本文は、セッション情報515-aとテレマティクスデータ520-aの両方を含む。本例が一般に含まれ得るヘッダフィールドのすべてを示していないことがあることに留意されたい。
セッション情報515-aは、端末と中央サービスとの間の提案されたセッションに関するパラメータのリストを含むことができる。たとえば、SIP INVITEメッセージ550-aは、VoIPオーディオ呼をセットアップするためのセッション記述プロトコル(SDP:Session Description Protocol)パラメータのセットを含むことができる。
テレマティクスデータ520-aは、中央サービスに送信される端末に関連するセンサ読取値、記憶または記録されたデータ、および他のデータを含むことができる。いくつかの例では、テレマティクスデータは、セッションのセットアップおよび維持に直接関係しないことがある。したがって、中央サービスがSIP INVITEメッセージ550-aのセッション情報515-a部分における呼の提案されたパラメータを拒否した場合、または他の理由でセッションを確立することが不可能な場合でも、中央サービスは依然として、テレマティクスデータ520-aを受信し処理することができる。本例では、SIP INVITEメッセージ550-aは、車両における自動または手動のトリガに基づいてPSAPサービスとの緊急呼を提案することができる。パラメータセッション情報515-aとともに送信されるテレマティクスデータ520-aは、車両および/またはその搭乗者のステータスならびに緊急呼をトリガした事象に関係するいくつかの測定値を含むことができる。図5Bの例に示すように、テレマティクスデータ520-aは、ステータスコード、積荷タイプ、端末に関連するメーカー固有識別子、車両のロケーション、車両の現在または以前の速度、車両の方向、およびチェックサムを含むことができる。いくつかの例では、テレマティクスデータ520-aは、eCallの最小データセット(MSD)または緊急呼データの他の標準セット、たとえばある国もしくは地域(たとえば、欧州連合)によって、またはある国もしくは地域のために定義されているようなセットを含むことができる。
図5Cは、図5Bの変更されたSIP要求メッセージ550-aに似た例示的な変更されたSIP要求メッセージ550-bを示している。ただし、図5Cの例では、セッション情報515-bは、プレゼンス情報データフォーマット-ロケーションオブジェクト(PIDF-LO:Presence Information Data Format-Location Object)を含むことができ、テレマティクスデータ520-bは、eCallDataオブジェクト535を含むことができる。一例では、eCallDataオブジェクト535は、ヘッダ510-bにおけるタグ530によって参照され得る。一例では、ヘッダ510-bにおけるタグ530は、eCallDataオブジェクト535のコンテンツ-ID(すなわち、1234567890@rosebud.example.com)を使用して、eCallDataオブジェクト535を参照することができる。図5Cの例では、ヘッダ510-bは、INVITEが緊急呼と自動的にトリガされたeCallの両方を対象としていることを示す指示525を含むこともできる。
図6は、本システムおよび方法による、中央サービス160-bの一実施形態を示すブロック図600である。中央サービス160-bは、図1Aおよび/または図1Bの中央サービス160の一例であってよい。中央サービス160-bは、中央サービス受信機モジュール605、テレマティクスメタデータシグナリングモジュール610、および中央サービス送信機モジュール615を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
中央サービス160-bのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一構成では、中央サービス受信機モジュール605は、セルラー受信機および/またはネットワークインターフェースカード(NIC)を含むことができ、他のIPサービスおよびネットワーク175または任意の他のIP接続サービスを介して通信を受信することができる。一例では、中央サービス受信機モジュール605は、テレマティクスデータを含むように適合されている、通信シグナリングプロトコルに関するシグナリングメッセージを受信することができる。テレマティクスメタデータシグナリングモジュール610は、適合されたシグナリングメッセージからテレマティクスデータを抽出することができる。テレマティクスメタデータシグナリングモジュール610は、テレマティクスメタデータを含むように通信シグナリングプロトコルに関するシグナリングメッセージを適合することもできる。通信シグナリングプロトコルに関する適合されたシグナリングメッセージは、中央サービス送信機モジュール615を介して送信され得る。テレマティクスメタデータシグナリングモジュール610に関する詳細については、以下で説明する。別の構成では、中央サービス受信機モジュール605は、たとえば図1BにおけるESRP111からの、有線手段を介したパケットデータの受信をサポートすることができる。
図7は、本システムおよび方法による、中央サービス160-cの一実施形態を示すブロック図700である。中央サービス160-cは、図1A、図1B、および/または図6に示す中央サービス160の一例であってよい。中央サービス160-cは、前述のように、中央サービス受信機モジュール605、テレマティクスメタデータシグナリングモジュール610-a、および中央サービス送信機モジュール615を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
中央サービス160-cのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一実施形態では、テレマティクスメタデータシグナリングモジュール610-aは、テレマティクスメタデータモジュール710を含むことができる。テレマティクスメタデータモジュール710は、テレマティクスメタデータを生成および/または取得することができる。テレマティクスメタデータモジュール710は、テレマティクスデータを受信することもできる。いくつかの例では、テレマティクスメタデータモジュール710は、受信されたテレマティクスデータに基づいてテレマティクスメタデータを生成することができる。
テレマティクスメタデータシグナリングモジュール610-aは、セッション制御モジュール310-bを含むこともできる。セッション制御モジュール310-bは、図3および/または図4に示すセッション制御モジュール310の一例であってよい。一例では、セッション制御モジュール310-bは、信号情報のセット(たとえば、第1のセット)を含むシグナリングメッセージを取得することができる。セッション制御モジュール310-bは、信号情報のセット(たとえば、第2のセット)を含むシグナリングメッセージを生成することもできる。
一実施形態では、テレマティクスメタデータシグナリングモジュール610-aは、セッション/テレマティクスデータ分離モジュール705を含むことができる。前述のように、シグナリングメッセージが、セッション情報とともにテレマティクスデータおよび/またはテレマティクスメタデータを含むように適合され得る。たとえば、シグナリングメッセージが、セッション情報の第1のセットおよびテレマティクスデータの第1のセットを含むように適合され得る。セッション/テレマティクスデータ分離モジュール705は、適合されたシグナリングメッセージからテレマティクスデータを抽出することができる。セッション/テレマティクスデータ分離モジュール705は、セッション制御モジュール310-bに(たとえば、シグナリングメッセージの形で)セッション情報を提供することができ、テレマティクスメタデータモジュール710にテレマティクスデータを提供することができる。
テレマティクスメタデータシグナリングモジュール610-aは、セッション/テレマティクスメタデータ結合モジュール715を含むこともできる。セッション/テレマティクスメタデータ結合モジュール715は、テレマティクスメタデータモジュール710からのテレマティクスメタデータを含むように、セッション制御モジュール310-bによって生成されたシグナリングメッセージを適合することができる。一例では、適合されたシグナリングメッセージは、セッション情報の第2のセットおよびテレマティクスメタデータの第1のセットを含むことができる。適合されたシグナリングメッセージは、中央サービス送信機モジュール615を介して送信され得る。
図8は、本システムおよび方法による、中央サービス160-dの一実施形態を示すブロック図800である。中央サービス160-dは、図1A、図1B、図6、および/または図7に示す中央サービス160の一例であってよい。一構成では、中央サービス160-dは、中央サービス受信機モジュール605、テレマティクスメタデータシグナリングモジュール610-b、および中央サービス送信機モジュール615を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
中央サービス160-dのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一例では、中央サービス160-dは、少なくとも、通信セッションシグナリングプロトコルの適合された使用により端末からテレマティクスデータを受信し、端末との通信セッションを確立し、受信されたテレマティクスデータの内容に基づいてテレマティクスメタデータを生成し、通信セッションシグナリングプロトコルの適合された使用により端末にテレマティクスメタデータを送信するように構成され得る。いくつかの例では、中央サービス160-dは、受信されたテレマティクスデータに基づいて一定のアクションを実行するよう、テレマティクスメタデータを介して端末に指示することもできる。
テレマティクスメタデータシグナリングモジュール610-bは、セッション制御モジュール310-cを含むことができる。セッション制御モジュール310-cは、図3、図4、および/または図7に示すセッション制御モジュール310の一例であってよい。セッション制御モジュール310-cは、SIP/SDPモジュール405-aおよびセッション実施モジュール410-aを含むことができる。SIP/SDPモジュール405-aは、端末との通信セッションを交渉し、セットアップし、管理し、かつ終了させるように構成され得る。SIP/SDPモジュール405-aは、端末との間でセッション関連シグナリングデータを通信するためにSIPシグナリングメッセージヘッダコンテンツおよびSDPコンテンツを生成することができる。セッション実施モジュール410-aは、メディアコンテンツ(たとえば、音声呼のためのオーディオデータ、ビデオ呼のためのオーディオおよびビデオデータ、テキスト呼のためのテキストデータ)を受信し、交渉されたセッションに従って端末にパケットのストリームとしてメディアコンテンツを送信し、かつ交渉されたセッションに従って端末からメディアコンテンツを含むパケットのストリームを受信するように構成され得る。
テレマティクスメタデータシグナリングモジュール610-bは、テレマティクスメタデータモジュール710-aを含むこともできる。テレマティクスメタデータモジュール710-aは、テレマティクスデータ分析モジュール805、中央サービスアクションモジュール810、端末アクションモジュール820、およびテレマティクスメタデータメッセージモジュール815を含むことができる。
テレマティクスデータ分析モジュール805は、端末からテレマティクスデータを受信し、1つまたは複数のルールからなるセットを適用して、テレマティクスデータの性質を識別し、テレマティクスデータに応答して実行すべき適切なアクションを判断することができる。たとえば、端末が車両に関連付けられる場合、テレマティクスデータ分析モジュール805は、車両タイプおよび車両識別番号(VIN)、1つもしくは複数のタイムスタンプ、位置推定および関連する信頼度、移動方向、(たとえば、締められたシートベルトによる)乗客の数、端末のサービスプロバイダ(存在する場合)、トリガタイプ(たとえば、展開されたエアバッグ、バンパーセンサ、手動トリガ、火災表示灯、転覆、または他の状況検出など)、ならびに/または本明細書で説明する原理の特定の適用に適したものであり得る他の関連情報に関係するテレマティクスデータを分析することができる。一構成では、テレマティクスデータ分析モジュール805は、分析されたテレマティクスデータおよび/または命令を中央サービスアクションモジュール810および/または端末アクションモジュール820に提供することができる。
中央サービスアクションモジュール810は、分析されたテレマティクスデータに基づいて、中央サービス160-dにおいて識別されたアクションを実行することができ、かつ端末アクションモジュール820は、テレマティクスデータに基づく一定のアクションの実行を求める端末向け命令を生成することができる。テレマティクスメタデータメッセージモジュール815は、受信されたテレマティクスデータに基づいて端末に送信するためのテレマティクスメタデータのセットを生成することができる。テレマティクスメタデータメッセージモジュール815は、端末による中央サービス160-dへのテレマティクスデータの送信の検出済み試みに応答して、端末に送信するためのテレマティクスメタデータのセットをさらに生成することができる。さらに、テレマティクスメタデータメッセージモジュール815は、端末によって理解されるプロトコルに従って端末に送信するためにテレマティクスメタデータをフォーマットすることができる。上記のように、テレマティクスメタデータは、テレマティクスデータが中央サービス160-dにおいて受信されたかどうかの確認応答もしくは否定応答、テレマティクスデータ(たとえば、以前のバージョンおよび/または現在のバージョン)の再送信を求める要求、異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービスによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータなどの情報を含むことができる。
端末が車両に関連付けられ、検出された衝突、クラッシュ、転覆または他の状況に応答して中央サービス160-dに対する緊急呼を開始する例を参照すると、テレマティクスデータ分析モジュール805は衝突のタイプおよび重大度を示すテレマティクスデータを端末から受信することができ、中央サービスアクションモジュール810は、衝突に関する情報を緊急サービス(または他の適切な宛先)に提供(たとえば、転送)することができ、端末アクションモジュール820は、車両の燃料供給をオフにして、録音メッセージを再生すること、または支援が行われようとしていることを示す(たとえば、中央サービス160-dからの、または端末によって記憶された)テキストメッセージを表示すること、メディアをレンダリングすること(たとえば、テキスト読み上げをレンダリングすること)などを求める端末向け命令を生成することができる。次いでテレマティクスメタデータメッセージモジュール815は、端末に送信するためのテレマティクスメタデータのセットを生成することができ、このテレマティクスメタデータは、テレマティクスデータの受信を確認応答し、端末アクションモジュール820によって生成された命令を提供し、かつ/または端末に他の関連情報(たとえば、オペレータが音声および/または他のメディア呼を取ることが可能になるまでの推定時間、緊急サービスが到着するまでの推定時間など)を提供する。
一実施形態では、テレマティクスメタデータシグナリングモジュール610-bは、セッション/テレマティクスデータ分離モジュール705を含むことができる。セッション/テレマティクスデータ分離モジュール705は、変更されたSIPまたは他の通信セッションシグナリングプロトコルメッセージを(たとえば、中央サービス受信機モジュール605を介して)受信することができ、SIP/SDP(または他のプロトコル)情報をテレマティクスデータメッセージから分離することができる。いくつかの実施形態では、セッション/テレマティクスデータ分離モジュール705は、上で説明したように、SIP/SDP情報をSIP/SDPモジュール405-aに提供することができ、1つまたは複数のテレマティクスデータメッセージをテレマティクスデータ分析モジュール805に提供することができる。一例では、セッション/テレマティクスデータ分離モジュール705は、変更されたSIPメッセージの様々な部分を、変更されたSIPメッセージのヘッダからの情報に基づいて識別することができる。この例では、セッション/テレマティクスデータ分離モジュール705は、上で説明したように、SIP/SDP(または他のプロトコル)情報として識別された部分をSIP/SDPモジュール405-aに提供することができ、テレマティクスデータメッセージとして識別された部分をテレマティクスデータ分析モジュール805に提供することができる。
テレマティクスメタデータシグナリングモジュール610-bは、セッション/テレマティクスメタデータ結合モジュール715を含むこともできる。セッション/テレマティクスメタデータ結合モジュール715は、上で説明したように、SIP/SDPモジュール405-aからのSIP/SDP(または他のプロトコル)情報およびテレマティクスメタデータモジュール710-aからの1つまたは複数のテレマティクスメタデータメッセージを結合して、変更されたSIPまたは他の通信セッションシグナリングプロトコルメッセージにすることができる。中央サービス送信機モジュール615は、生成されたシグナリングメッセージを端末に送信することができる。
図9A、図9B、図9C、図9D、図9E、および図9Fは、セッションデータとテレマティクスメタデータの両方を搬送するために変更されたセッション開始プロトコル(SIP)応答メッセージの一例を示している。図9A〜図9FのSIP応答メッセージは、図5A〜図5Cの記述によるSIP要求メッセージを受信したことに応答して、中央サービス160から端末110に送信され得る。
セッションデータとテレマティクスメタデータの両方を搬送するためにSIPプロトコルを転用することによって、テレマティクスメタデータは、関連呼の中断またはその品質の劣化を伴うことなく端末に効率的に送信され得る。図9Aは、応答メッセージの例示的なフォーマット900の図を示している。図9B、図9C、図9D、図9E、および図9Fは、図9Aのフォーマットに基づく例示的なSIP応答メッセージ950a〜eの図を示している。図9A、図9B、図9C、図9D、図9E、および図9Fの例は、変更され転用されたSIP応答メッセージの文脈で記述されているが、本明細書の原理を他の通信セッションシグナリングプロトコル(たとえば、XMPP、Googleトーク、MSNなど)を変更または拡張するために、または新しい通信セッションシグナリングプロトコルの土台として使用できることが理解されよう。
変更されたSIP応答メッセージフォーマット900は、SIP要求メッセージに応答してシグナリングメッセージを生成するために使用され得る。図9Aに示すように、変更されたSIP応答メッセージフォーマット900は、ステータスライン905、ヘッダ910、セッションデータのセット915、およびテレマティクスメタデータのセット920を含むことができる。SIPプロトコルは、いくつかの応答メッセージ、仮応答、成功した応答、宛先変更応答、およびクライアント失敗応答を定義する。本フォーマット900は、これらのメッセージタイプの各々に、および他のタイプの応答メッセージに使用され得る。
図9Bの例では、図9Aのフォーマットに基づく変更されたSIP200(OK)メッセージ950-aが、たとえば、中央サービスによって、図5Bおよび/または図5Cの変更されたSIP INVITEメッセージ550を受信したことに応答して、提案されたVoIPセッションを中央サービスが受け入れることを示すために使用され得る。SIP200(OK)メッセージ950-aはさらに、SIP INVITEメッセージ550において送信されたテレマティクスデータの受信を確認応答するメタデータを端末に提供することができる。SIP200(OK)メッセージ950-aはまた、(たとえば、緊急サービスが通知されており、音声確認待ちであることを示す)追加情報を提供することができる。
例示的なSIP200(OK)シグナリングメッセージ950-aのステータスライン905-aは、メッセージ950-aをSIP応答として識別し、行われている応答のタイプ(たとえば、OK)を明示することができる。応答メッセージのヘッダ910-aは、端末および中央サービスの識別情報、呼識別子、端末および中央サービスに関する連絡先情報、呼連続番号、本文におけるデータのタイプの指示、および応答メッセージ950-aの長さを提供することができる。本例では、ヘッダ910-aは、本文が混合データを含むことを明示することができ、文字列"-----NextPart-----"は、本文における異なるタイプのデータの間の境界を示している。本例では、メッセージの本文は、セッションデータ915-aとテレマティクスメタデータ920-aの両方を含む。
セッションデータ915-aは、端末と中央サービスとの間の提案されたセッションに関する合意されたパラメータのリストを含むことができる。これらのセッションパラメータは、VoIPオーディオ呼のためのセッション記述プロトコル(SDP)パラメータのセットであり得る。
テレマティクスメタデータ920-aは、中央サービスにおいてSIP INVITEシグナリングメッセージ550で受信されたテレマティクスデータに関係する情報を含むことができる。前述のように、テレマティクスメタデータ920-aは、テレマティクスデータが中央サービスにおいて受信されたかどうかの確認応答、テレマティクスデータの再送信を求める要求、異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービスによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータを含むことができる。車両に関連する端末からPSAPサービスに行われた緊急呼の例を参照すると、図9Bに示すテレマティクスメタデータ920-aは、テレマティクスデータが受信されたことの確認応答、および緊急サービスが通知されていること、および音声呼待ちであることを示すステータスコードを含むことができる。
図9Cは、図9Bの変更されたSIP応答メッセージ950-aに似た例示的な変更されたSIP応答メッセージ950-bを示している。ただし、図9Cの例では、テレマティクスメタデータ920-bは、端末に関連する任意の車両に関する一定のアクションの実行を求める端末向け命令をさらに含むことができる。したがって、図9Cのテレマティクスメタデータ920-bは、車両のイグニションをオフにすること、車両の燃料ポンプをオフにすること、車両のドアの鍵を開けること、および車両の搭乗者に対する命令の指定された録音を再生することを求める命令を含むことができる。いくつかの構成では、端末に対する命令は、人間から来ることがある。たとえば、呼を取っている人間は、コマンドが端末に送られるようにすることがあり、このコマンドは、更新テレマティクスデータまたは追加テレマティクスデータを求める要求、所定のメッセージまたは完全に動的なメッセージ(たとえば、人間がその場でタイプしたもの)を含む(たとえば、テキストを表示すること、テキスト読み上げをレンダリングすること、録音を再生すること、メディアを再生することによって)車両に通知される1つまたは複数のメッセージ、ドアの鍵を閉めること/開けること、ライト/クラクションをトリガすることなどを含み得る。
図9Dは、図9Bの変更されたSIP応答メッセージ950-aに似た例示的な変更されたSIP応答メッセージ950-cのステータスライン905-cおよびヘッダ910-cを示している。ただし、図9Cの例では、ヘッダ910-cは、eCallMetaData用P-ヘッダ925をさらに含む。この例では、eCallMetaData用P-ヘッダ925は、指定IDを伴うデータの受信を確認応答する確認応答930、静的メッセージの再生を求めるコマンド935、通知される(たとえば、ライトを照らす、クラクションを鳴らす、音を立てる、など)ことを求めるコマンド940、およびeCall data AltSet1を送ることを求めるコマンド945を含むことができる。一例では、静的メッセージは端末および/または既知のロケーションに記憶され得る。
図9Eは、図9Bの変更されたSIP応答メッセージ950-aに似た例示的な変更されたSIP応答メッセージ950-dを示している。本例では、ヘッダ910-dは、図9DのeCallMetaData用P-ヘッダ925に似たeCallMetaData用P-ヘッダ925-aを含むことができる。ただし、図9Eの例では、eCallMetaData用P-ヘッダ925-aは、動的メッセージの再生を求めるコマンド955、および再生されるべき動的メッセージのコンテンツID(すなわち、5432154321@example.gov)を示す参照960を含むことができる。この例では、応答メッセージ950-dの本文(たとえば、テレマティクスメタデータ920-d)に動的メディアが含まれ得る。上記で示したように、動的メディアオブジェクト965は、指定のコンテンツIDを有することがあり、指定のコンテンツIDによって参照され得る。
図9Fは、図9Bの変更されたSIP応答メッセージ950-aに似た例示的な変更されたSIP応答メッセージ950-eを示している。ただし、図9Fの例では、本文(たとえば、テレマティクスメタデータ920-e)にテレマティクスメタデータ(たとえば、eCallメタデータ)が含まれ得る。本例は、静的メッセージと動的メッセージの両方がテレマティクスメタデータオブジェクト(たとえば、eCallMetaDataオブジェクト)に含まれ得ることをさらに示している。この例では、ヘッダ910-eは、本文(たとえば、テレマティクスメタデータ920-e)中のテレマティクスメタデータオブジェクト975を参照するタグ970を含むことができる。たとえば、タグ970は、テレマティクスメタデータオブジェクト975のコンテンツID(すなわち、9876543210@example.gov)を参照することによってテレマティクスメタデータオブジェクト975を参照することができる。この例では、テレマティクスメタデータ920-eは、テレマティクスメタデータオブジェクト975を含むことができる。本例では、テレマティクスメタデータオブジェクト975は、指定IDを伴うデータの受信を確認応答する確認応答930-a、静的メッセージの再生を求めるコマンド935-a、動的メッセージの再生を求めるコマンド955-a、動的メディアオブジェクト965-a、通知される(たとえば、ライトを照らす、クラクションを鳴らす、音を立てる、など)ことを求めるコマンド940-a、およびeCall data AltSet1を送ることを求めるコマンド945-aを含むことができる。一構成では、テレマティクスメタデータオブジェクト975は、マークアップ言語(たとえば、拡張マークアップ言語(XML))を使用して形成され得る。テレマティクスメタデータオブジェクト975はASN.1、JSON、MIMEなど多くの他の符号化または構造化機構を使用して形成され得ることに留意されたい。
図5A、図5B、図5C、図9A、図9B、図9C、図9D、図9E、および図9Fの例は、テレマティクスデータを搬送する変更されたSIP要求メッセージおよびテレマティクスメタデータを搬送する変更されたSIP応答メッセージの例を示しているが、当業者は、いずれのタイプのメッセージもテレマティクスデータまたはテレマティクスメタデータを搬送し得ることを認識されよう。たとえば、いくつかの例では、端末は、中央サービスからの要求に応答するメッセージにおいて、テレマティクスデータを中央サービスに送信することができる。同様に、いくつかの例では、中央サービスは、端末への要求メッセージにおいてテレマティクスメタデータを端末に送信することができる。追加または代替の例では、要求メッセージまたは応答メッセージはテレマティクスデータとテレマティクスメタデータの両方を含むことができる。
図10は、通信セッションシグナリングプロトコルを使用するテレマティクスデータおよびテレマティクスメタデータの交換に関する端末110-eと中央サービス160-eとの間の通信交換の一例の図である。端末110-eは、図1A、1B、図2、図3、および/または図4の端末110の一例であってよく、中央サービス160-eは、図1A、1B、図6、図7、および/もしくは図8の中央サービス160(たとえば、PSAP)または別の中央サービスの一例であってよい。いくつかの例では、中央サービス160-eは、1つまたは複数のサーバによって実装され得る。
通信セッションシグナリングプロトコルは、背後にあるトランスポート層とは無関係であるように設計されたアプリケーション層プロトコルであり得る。したがって、いくつかの例では、通信セッションシグナリングプロトコルは、いくつかの異なるトランスポート層プロトコルに適合することができる。いくつかの例では、端末110-eと中央サービス160-eとの間の初期シグナリングメッセージがプロキシサーバのうちの1つまたは複数の間で転送され得るように、1つまたは複数のプロキシサーバが端末110-eと中央サービス160-eとの間に配設され得る。明瞭にするために、そのようなプロキシサーバは、本明細書に関連する図に示されていない。メッセージ交換を受信、転送、再生、変更し、あるいはメッセージ交換に関与する他の(たとえば、追加の)エンティティ(たとえば、SIPシグナリングの場合、バックトゥバックユーザエージェント、セッションボーダーコントローラなど)があり得ることに留意されたい。図10では、通信セッションシグナリングプロトコルは、SIP、XMPP、Googleトーク、スカイプなどであってよく、背後にあるトランスポート層は、ユーザデータグラムプロトコル(UDP)オーバーIPもしくは伝送制御プロトコル(TCP)オーバーIPまたはトランスポートプロトコルの何らかの他のセットであってよい。
端末110-eは、通信セッションをセットアップし管理するために、通信セッションシグナリングプロトコルにより中央サービスと通信することができる。本例では、端末110-eおよび中央サービス160-eは、端末110-eに関連するユーザと中央サービス160-eに関連するオペレータとの間の(音声および/または他のメディアを搬送する)呼のためのVoIPセッションを確立するために通信することができる。図10に示すように、端末110-eは、中央サービス160-eにセッション開始シグナリングメッセージを送信することができる。セッション開始シグナリングメッセージは、端末110-eとのVoIPセッションに参加するよう中央サービス160-eを招待することができる。端末110-eは、端末110-eに関連するユーザからの手動要求に応答してセッション開始メッセージを送信することができる。たとえば、端末110-eに関連する車両の搭乗者は、中央サービス160-eをVoIPセッションに招待するよう端末110-eにシグナリングする車両中の緊急呼ボタンを押すことができる。追加または代替として、端末110-eは、1つまたは複数の検出または推測された状況または事象(たとえば、展開されたエアバッグ、衝突センサ、エンジン診断データ、エンジンの火災、車両の火災、転覆、または他の状況など)に応答して、中央サービス160-eにセッション開始メッセージを送信することができる。
セッション開始メッセージは、提案されたセッションに関する詳細およびパラメータ(たとえば、ネットワークアドレス、ポート番号、メディアのタイプ、タイミング、サポートされるストリーミングプロトコル、帯域幅など)を含むことができる。端末110-eと中央サービス160-eとの間の提案されたセッションに関するこのセッションデータセットに加えて、端末デバイス110-eは、中央サービス160-eに送信されるセッション開始メッセージにテレマティクスデータを付加(たとえば、追加)することができる。テレマティクスデータは、端末110-eと通信している1つまたは複数のセンサからの読取値および/または端末110-eによって記憶、判断、計算および/または受信された他のデータを含むことができる。いくつかの例では、テレマティクスデータは、eCallまたは他の緊急呼の間にPSAPに一般に送信されるデータを含むことができる。たとえば、テレマティクスデータは、eCallがどのように開始されたか、車両タイプおよび車両識別番号(VIN)、タイムスタンプ、位置推定および位置信頼フラグ、移動方向、(たとえば、シート占有センサによる)乗客の数および関連データ(たとえば、シートベルトが締められたシート)、端末のサービスプロバイダ(存在する場合)、トリガタイプ(たとえば、展開されたエアバッグ、バンパーセンサ、火災表示灯、転覆、または他の状況検出など)、ならびに/または本明細書で説明する原理の特定の適用に適したものであり得る他の関連情報のうちの少なくとも1つまたは複数を含むことができる。
中央サービス160-eは、テレマティクスデータが付加されたセッション開始メッセージを受信すると、提案されたセッションを受け入れるか、または拒否するかを判断することができる。本例では、中央サービス160-eは、提案されたセッションに関するさらなるパラメータおよびデータを提供することに加えて、当該セッションが受け入れられたことを示すセッション確認メッセージを通信セッションシグナリングプロトコルにより送信することができる。加えて、端末110-eに送信されるセッション確認メッセージは、中央サービス160-eによってセッション開始メッセージにおいて受信されたテレマティクスデータのセットに関連するテレマティクスメタデータのセットを含むことができる。代替例では、中央サービス160-eは、(たとえば、テレマティクスメタデータを送信するために特に使用される通信セッションシグナリングプロトコルメッセージで、異なるタイプの通信セッションシグナリングプロトコルメッセージに付加されて)別個のメッセージで端末110-eにテレマティクスメタデータを送信することができる。テレマティクスメタデータは、たとえば、テレマティクスデータが中央サービス160-eにおいて受信されたかどうかの確認応答、中央サービス160-eへのテレマティクスデータ(たとえば、以前のバージョンおよび/もしくは現在のバージョン)の再送信を求める要求、中央サービス160-eへの異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービス160-eによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータを含むことができる。
端末110-eは、テレマティクスメタデータを受信し、受信されたテレマティクスメタデータの内容に基づいて適切なアクションを実行することができる。いくつかの例では、テレマティクスメタデータは、テレマティクスデータの受信を確認するだけであることがあり、端末110-eは、テレマティクスメタデータに応答したアクションを一切実行しないことがある。他の例では、端末110-eは、中央サービス160-eからのテレマティクスメタデータにおける要求に応答すること、または受信されたテレマティクスメタデータに基づいて実行すべきアクションを識別するためにルールのセットを調べることができる。
加えて、端末110-eは、セッション開始メッセージとセッション確認メッセージの両方におけるセッションデータおよびパラメータに基づいて、中央サービス160-eとのVoIPセッションを確立することができる。端末110-eおよび中央サービス160-eは、端末110-eのユーザと中央サービス160-eのオペレータとの間で(音声および/または他のメディアデータを搬送する)呼を実施するためにリアルタイムトランスポートプロトコル(RTP)または別のストリーミングプロトコルを使用して、音声および/または他のメディアデータを含むパケットのストリームを交換することができる。VoIPセッションは、テキスト、メッセージ単位のテキスト(インスタントメッセージングなど)と文字単位のテキスト(リアルタイムテキストと呼ばれることの多い、ストリーミングテキスト)の両方、および/またはビデオを含む任意のメディアを搬送することができる。たいていのメディアはストリームされるが、VoIPセッションは、ストリームされないメディアをストリームされるメディアの追加または代替として搬送することもできることに留意されたい。
VoIPセッションを終わらせるために、中央サービス160-eは、通信セッションシグナリングプロトコルにより端末110-eにセッション終了シグナリングメッセージを送信することができる。端末110-eは、セッション終了シグナリングメッセージを受信すると、中央サービス160-eにセッション終了確認シグナリングメッセージを送信することができ、セッションは終了し得る。
図11は、a)VoIP呼のセットアップとb)テレマティクスデータおよびテレマティクスメタデータの交換の両方のために通信セッションシグナリングプロトコルを使用する端末110-fと中央サービス160-fとの間の通信交換1100の一例の図である。以前の例と同様に、通信セッションシグナリングプロトコルは、テレマティクスデータおよびテレマティクスメタデータを搬送するために変更されたSIPのバージョンであり得る。(図11には示されていない)他の例では、他の通信セッションシグナリングプロトコルが使用され得る。
端末110-fは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-fは、図1Aの中央サービス(たとえば、PSAP)160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。いくつかの例では、中央サービス160-fは、1つまたは複数のサーバによって実装され得る。加えて、いくつかの例では、端末110-fと中央サービス160-fとの間で通信セッションシグナリングプロトコルメッセージを転送するために、1つまたは複数のプロキシサーバが端末110-fと中央サービス160-fとの間に配設され得る。
第1の段階では、端末110-fは、中央サービス160-fにSIP INVITEメッセージを送信することができる。いくつかの例では、SIP INVITEメッセージは、図5A、図5B、および図5Cを参照しながら上述した変更されたSIP要求メッセージの一例であってよい。SIP INVITEメッセージは同時に、パラメータの提案されたセットを有する提案されたVoIPセッションに中央サービス160-fを招待し、端末110-fから中央サービス160-fにテレマティクスデータのセットを伝達することができる。いくつかの例では、端末110-fは車両に関連付けられることがあり、車両における検出された状況または車両の搭乗者による緊急呼を求める手動要求に応答して、中央サービス160-fにSIP INVITEメッセージを送信することができる。
第2の段階では、中央サービス160-fは、端末110-fにSIP STATUS 200(OK)メッセージを送信することによってSIP INVITEメッセージに応答することができる。SIP STATUS 200(OK)メッセージは同時に、提案されたVoIPセッションに同意し、中央サービス160-fによるテレマティクスデータの受信を確認応答するテレマティクスメタデータを端末110-fに伝達することができる。第3の段階では、端末110-fは、中央サービス160-fからのテレマティクスメタデータを含むSIP STATUS 200(OK)メッセージを受信すると、中央サービス160-fにSIP ACKメッセージを送信することができる。第4の段階では、SIP INVITEメッセージ、SIP STATUS 200(OK)メッセージ、およびSIP ACKメッセージにおいて合意されたパラメータに従って、端末110-fと中央サービス160-fとの間で音声および/または他のメディア通信を搬送するセッションデータのパケットをストリームすることによって、VoIPセッションが実施され得る。第5の段階では、中央サービス160-fが端末110-fにSIP BYEメッセージを送信することによって、VoIPセッションが終了し得る。端末110-fは、第6の段階において、中央サービス160-fにSIP STATUS 200(OK)応答メッセージを送信することによって、セッションの終了を確認することができる。他の例では、端末110-fがVoIPセッションの終了を開始することがあり、中央サービス160-fが端末110-fにSIP STATUS 200(OK)応答メッセージを送信することがある。
図12は、a)VoIP呼のセットアップとb)テレマティクスデータおよびテレマティクスメタデータの交換の両方のために通信セッションシグナリングプロトコルを使用する端末110-gと中央サービス160-gとの間の通信交換1200の一例の図である。以前の例と同様に、通信セッションシグナリングプロトコルは、テレマティクスデータおよびテレマティクスメタデータを搬送するために変更されたSIPのバージョンであり得る。他の例では、他の通信セッションシグナリングプロトコルが使用され得る。
端末110-gは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-gは、図1Aの中央サービス160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。いくつかの例では、中央サービス160-gは、1つまたは複数のサーバによって実装され得る。加えて、いくつかの例では、端末110-gと中央サービス160-gとの間で通信セッションシグナリングプロトコルメッセージを転送するために、1つまたは複数のプロキシサーバが端末110-gと中央サービス160-gとの間に配設され得る。
第1の段階では、端末110-gは、中央サービス160-gにSIP INVITEメッセージを送信することができる。いくつかの例では、SIP INVITEメッセージは、図5A、図5B、および図5Cを参照しながら上述した変更されたSIP要求メッセージの一例であってよい。SIP INVITEメッセージは同時に、パラメータの提案されたセットを有する提案されたVoIPセッションに中央サービス160-gを招待し、端末110-gから中央サービス160-gにテレマティクスデータのセットを伝達することができる。いくつかの例では、端末110-gは車両に関連付けられることがあり、車両における検出された状況または車両の搭乗者による緊急呼を求める手動要求に応答して、中央サービス160-gにSIP INVITEメッセージを送信することができる。
第2の段階では、中央サービス160-gは、端末110-gにSIP STATUS 200(OK)メッセージを送信することによってSIP INVITEメッセージに応答することができる。SIP STATUS 200(OK)メッセージは同時に、提案されたVoIPセッションに同意し、中央サービス160-gによるテレマティクスデータの受信を確認応答するテレマティクスメタデータを端末110-gに伝達することができる。第3の段階では、SIP INVITEメッセージおよびSIP STATUS 200(OK)メッセージにおいて合意されたパラメータに従って、端末110-gと中央サービス160-gとの間で音声および/または他のメディア通信を搬送するセッションデータのパケットをストリームすることによって、VoIPセッションが実施され得る。
第4の段階では、中央サービス160-gは、追加のテレマティクスメタデータとともにSIP INFOメッセージを端末110-gに送信することができる。一例では、追加のテレマティクスメタデータは、初期のSIP INVITEメッセージに含まれていたものを越えた追加のテレマティクスデータを要求することができる。別の例では、追加のテレマティクスメタデータは、端末110-gおよび/または車両が実行すべき命令をさらに含むことができる。第5の段階では、端末110-gは、要求された追加のテレマティクスデータとともにSIP STATUS 200(OK)メッセージを中央サービス160-gに送信することができる。
第6の段階では、中央サービス160-gが端末110-gにSIP BYEメッセージを送信することによって、VoIPセッションが終了し得る。端末110-gは、第7の段階において、中央サービス160-gにSIP STATUS 200(OK)応答メッセージを送信することによって、セッションの終了を確認することができる。他の例では、端末110-gがVoIPセッションの終了を開始することがあり、中央サービス160-gが端末110-gにSIP STATUS 200(OK)応答メッセージを送信することがある。
図13は、a)VoIP呼のセットアップとb)テレマティクスデータおよびテレマティクスメタデータの交換の両方のために通信セッションシグナリングプロトコルを使用する端末110-hと中央サービス160-hとの間の通信交換1300の別の例の図である。以前の例と同様に、通信セッションシグナリングプロトコルは、テレマティクスデータおよびテレマティクスメタデータを搬送するために変更されたSIPのバージョンであり得る。他の例では、他の通信セッションシグナリングプロトコルが使用され得る。
端末110-hは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-hは、図1Aの中央サービス160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。いくつかの例では、中央サービス160-hは、1つまたは複数のサーバによって実装され得る。加えて、いくつかの例では、端末110-hと中央サービス160-hとの間で通信セッションシグナリングプロトコルメッセージを転送するために、1つまたは複数のプロキシサーバが端末110-hと中央サービス160-hとの間に配設され得る。
第1の段階では、端末110-hは、中央サービス160-hにSIP INVITEメッセージを送信することができる。SIP INVITEメッセージは、以前の図を参照しながら上述した変更されたSIP要求メッセージの一例であってよい。SIP INVITEメッセージは同時に、パラメータの提案されたセットを伴うVoIPセッションに中央サービス160-hを招待し、端末110-hから中央サービス160-hにテレマティクスデータのセットを伝達することができる。
第2の段階では、中央サービス160-hは、端末110-hにSIP STATUS 180(Ringing)応答メッセージを送信することによって、SIP INVITEメッセージに応答することができる。いくつかの例では、SIP STATUS 180(Ringing)応答メッセージは、中央サービス160-hがVoIP呼に応じる人間オペレータを呼び出そうとしていることを示すことができる。中央サービス160-hが呼に応じる人間オペレータと連絡することができない場合、中央サービス160-hは、第3の段階において、端末110-hにSIP STATUS 486(Busy)応答メッセージを送信することができる。代替例では、中央サービス160-hはSIP STATUS 200(OK)応答メッセージにより呼を受け入れるが、人間オペレータが対応可能になるまで待つ間、呼を順番待ちの列に置くことがある。SIP STATUS 486(Busy)応答メッセージあるいはSIP STATUS 200(OK)応答メッセージは、端末110-hから中央サービス160-hに送信されたテレマティクスデータに関係するテレマティクスメタデータを含むことができる。
テレマティクスメタデータは、テレマティクスデータが中央サービス160-hによって受信されたことを端末110-hに確認応答することができる。したがって、端末110-hは、いくつかの例では、テレマティクスデータが中央サービス160-hにおいて成功裏に受信されている(たとえば、良好な状態で受信されている)ことを端末110-hのユーザに示すことができる。したがって、中央サービス160-hに関連するオペレータが音声および/または他のメディア呼を取ることが可能ではない場合でも、ユーザは、テレマティクスデータが中央サービス160-hにおいて受信されているという保証を得ることができる。いくつかの他の実施形態では、端末110-hを管理しているユーザがいない場合(たとえば、呼が端末110-hによって、センサデータに応答して引き起こされた場合)、テレマティクスメタデータ確認応答は、テレマティクスデータが受信されており、そのため端末110-hが自動再試行(automatic repeat attempt)を試みる必要がないことを端末110-hに確認することができる。これにより、多くのそのような端末110-hが、たとえば、非常に深刻な出来事(たとえば、ハイウェイでの複数の車両の玉突き衝突)または地震、ハリケーン、津波または山火事などの災害状況に応答して、同時に緊急呼を発し、テレマティクスデータを送ろうとしているときに、中央サービス160-hに対する負荷を低減することができる。
一例では、中央サービス160-hは、テレマティクスデータが良好な状態で受信されている(たとえば、良好に受信されている)かどうかを判断することができる。良好な状態の例として、(たとえば、エラーのない送信の結果としての)データの送信されたセットの完全な受信があり得る。データの完全でないセットが良好な状態と見なされる場合がある一方、データの完全でないセットが良好な状態と見なされない場合もある。場合によっては、良好な状態の判断は、テレマティクスデータが送信された状況(たとえば、テレマティクスデータの受信されたセットの内容によって判断される)に基づき得る。追加または代替として、良好な状態の判断は、値が互いに整合しているかどうか、または一般的な範囲と整合しているかどうか、ロケーションデータが高い十分な信頼を有しているかどうか、テレマティクスデータが十分に最新のものであるかどうか、などのような要素に基づき得る。ある場合には、良好な状態の判断は、中央サービス160-hにおいて人間(たとえば、オペレータ)によって下され得る。他の場合には、良好な状態の判断は、(たとえば、中央サービスによって)自動的に下され得る。
たとえば、車両緊急発呼システムに関連する端末110-hの例に戻ると、車両の搭乗者は、衝突に遭い、中央サービス160-hへの緊急音声および/または他のメディア呼が望まれることを示す手動指示を端末110-hに提供することがある。中央サービス160-hに送信されるテレマティクスデータは、少なくとも、車両の緯度および経度ならびに衝突が生じていることを示す指示を含み得る。中央サービス160-hが大量の呼に直面していて、呼に応じる人間オペレータを提供することができない場合であっても、車両の搭乗者は、搭乗者のロケーションおよび衝突に関する情報が中央サービス160-hにおいて受信されたという保証を受け取ることができる。たとえば、端末110-hは、(たとえば、データが中央サービス160-hにおいて受信されたことをユーザに通知するよう端末110-hに命令する)テレマティクスメタデータを含むSIP STATUS 486(Busy)メッセージを受信することがある。いくつかの例では、テレマティクスメタデータは、端末110-hを通じてユーザに、緊急サービスが送り出されている(またはユーザのエリアにあって、他の出来事に対応しており、その後ユーザの世話をすることになる)ことを示すメッセージまたは車両内にとどまることを求める命令を含む他の有用な情報を通信することもできる。一例では、テレマティクスメタデータは、追加または代替として、(安全のために)イグニションを止めること、もしくはドアの鍵を閉めること、または(緊急サービスが車両のロケーションを特定できるように)ライトを照らすことなどの命令を車両に提供することができる。
第4の段階では、中央サービス160-hは、オペレータが端末110-hのユーザとのVoIP呼に参加することが可能であると判断することがあり、呼がまだ順番待ちの列にないか、または保留となっていない場合、中央サービス160-hは、新しいVoIPセッションを提案するSIP INVITEメッセージを端末110-hに送信することによって、端末110-hへのコールバックを試みることができる。SIP INVITEメッセージは、受信されたテレマティクスデータに関係するテレマティクスメタデータの追加セットを含むことができる。本例では、テレマティクスメタデータの追加セットは、中央サービス160-hがテレマティクスデータの最新バージョンを評価できるように端末110-hがテレマティクスデータを再送信することを求める要求を含むことができる。
第5の段階では、端末110-hは、要求された更新テレマティクスデータも含むSIP STATUS 200(OK)メッセージを中央サービス160-hに送信することによって、中央サービス160-hによって提案された新しいVoIPセッションへの招待を受け入れることができる。第6の段階では、中央サービス160-hは、更新テレマティクスデータの受信を確認応答するテレマティクスメタデータの新しいセットとともにSIP ACKを端末110-hに送信することができる。第7の段階では、端末110-hと中央サービス160-hとの間のVoIP呼が、1つまたは複数のVoIPセッションデータストリームにおいて生じ得る。呼の終わりに、中央サービス160-hは、端末110-hにSIP BYEメッセージを送信することができ、端末110-hは、中央サービス160-hにSIP STATUS 200(OK)メッセージを送信することによって、呼の終了を確認応答することができる。
代替例では、中央サービス160-hは、段階3において、端末110-hにSIP STATUS 486(Busy)メッセージを送信した後、端末110-hとの呼セッションを確立しないこともある。それでも、端末110-hは、段階3において受信されたテレマティクスメタデータに依拠して、テレマティクスデータが中央サービス160-hによって受信されており、適切なアクションが実行されていると判断することができる。
図14は、a)VoIP呼のセットアップとb)テレマティクスデータおよびテレマティクスメタデータの交換の両方のために通信セッションシグナリングプロトコルを使用する端末110-iと中央サービス160-iとの間の通信交換1400の別の例の図である。以前の例と同様に、通信セッションシグナリングプロトコルは、テレマティクスデータおよびテレマティクスメタデータを搬送するために変更されたSIPのバージョンであり得る。他の例では、他の通信セッションシグナリングプロトコルが使用され得る。
端末110-iは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-iは、図1Aの中央サービス160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。いくつかの例では、中央サービス160-iは、1つまたは複数のサーバによって実装され得る。加えて、いくつかの例では、端末110-iと中央サービス160-iとの間で通信セッションシグナリングプロトコルメッセージを転送するために、1つまたは複数のプロキシサーバが端末110-iと中央サービス160-iとの間に配設され得る。
第1の段階では、端末110-iは、中央サービス160-iにSIP INVITEメッセージを送信することができる。SIP INVITEメッセージは同時に、パラメータの提案されたセットを伴う提案されたVoIPセッションに中央サービス160-iを招待し、端末110-iから中央サービス160-iにテレマティクスデータのセットを伝達することができる。第2の段階では、中央サービス160-iは、端末110-iにSIP STATUS 180(Ringing)応答メッセージを送信することができる。第3の段階では、中央サービス160-iは、提案されたVoIPセッションの受け入れを示すために、端末110-iにSIP STATUS 200(OK)メッセージを送信することができる。SIP STATUS(OK)メッセージは、端末110-iによって送信されたテレマティクスデータが受信されていない(たとえば、良好に受信されていない)ことを示すテレマティクスメタデータ(すなわち、NAK応答)を含むこともある。場合によっては、テレマティクスメタデータは、端末向け命令、メッセージなどをさらに含むことができる。したがって、第4の段階では、端末110-iは、VoIPセッションを確認し、テレマティクスデータを再送信するSIP ACKメッセージを送信することができる。いくつかの例では、再送信されるテレマティクスデータは、SIP INVITEメッセージとともに当初送られたテレマティクスデータと同じものであり得る。代替として、再送信されるテレマティクスデータは、更新されてよく、あるいは当初のテレマティクスデータとは異なってよい。
第5の段階では、中央サービス160-iは、再送信されたテレマティクスデータが中央サービス160-iにおいて受信されていることを確認応答するテレマティクスメタデータを含むSIP STATUS 183(SESSION IN PROGRESS)メッセージを送信することができる。第6の段階では、端末110-iと中央サービス160-iとの間でストリーミング音声および/または他のメディアデータが交換され得る交渉されたVoIPセッションによってVoIP呼が実施され得る。第7の段階であるVoIP呼の終わりには、中央サービス160-iは、端末110-iにSIP BYEメッセージを送信することができる。第8の段階では、端末110-iは、VoIPセッションが終了していることを確認するためにSIP STATUS 200(OK)メッセージにより応答することができる。
図15は、a)VoIP呼のセットアップとb)テレマティクスデータおよびテレマティクスメタデータの交換の両方のために通信セッションシグナリングプロトコルを使用する端末110-jと中央サービス160-jとの間の通信交換1500の別の例の図である。以前の例と同様に、通信セッションシグナリングプロトコルは、テレマティクスデータおよびテレマティクスメタデータを搬送するために変更されたSIPのバージョンであり得る。他の例では、他の通信セッションシグナリングプロトコルが使用され得る。
端末110-jは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-jは、図1Aの中央サービス160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。いくつかの例では、中央サービス160-jは、1つまたは複数のサーバによって実装され得る。加えて、いくつかの例では、端末110-jと中央サービス160-jとの間で通信セッションシグナリングプロトコルメッセージを転送するために、1つまたは複数のプロキシサーバが端末110-jと中央サービス160-jとの間に配設され得る。
第1の段階では、端末110-jは、中央サービス160-jにSIP INVITEメッセージを送信することができる。SIP INVITEメッセージは同時に、パラメータの提案されたセットを伴う提案されたVoIPセッションに中央サービス160-jを招待し、端末110-jから中央サービス160-jにテレマティクスデータのセットを伝達することができる。第2の段階では、中央サービス160-jは、端末110-jにSIP STATUS 180(Ringing)応答メッセージを送信することができる。SIP STATUS 180(Ringing)応答メッセージは、テレマティクスデータが中央サービス160-jにおいて受信されていることを確認応答するテレマティクスメタデータを含むこともできる。第3の段階では、中央サービス160-jは、提案されたVoIPセッションの受け入れを示すために、端末110-jにSIP STATUS 200(OK)メッセージを送信することができる。第4の段階では、端末110-jは、中央サービス160-jにSIP ACKメッセージを送信することができ、第5の段階では、交渉されたVoIPセッションによってVoIP呼が実施され得る。
第6の段階では、中央サービス160-jは、追加のテレマティクスメタデータとともにSIP INFOメッセージを端末110-jに送信することができる。追加のテレマティクスメタデータは、初期のSIP INVITEメッセージに含まれていたものを越えた追加のテレマティクスデータを要求することができる。第7の段階では、端末110-jは、要求された追加のテレマティクスデータとともにSIP STATUS 200(OK)メッセージを中央サービス160-jに送信することができる。第8の段階では、中央サービス160-jは、追加のテレマティクスデータの受信を確認応答するテレマティクスメタデータのセットとともにSIP INFOメッセージを端末110-jに送信することができる。第9の段階では、端末110-jは、SIPプロトコルに沿ってSIP INFOメッセージへの応答として、SIP STATUS 200(OK)メッセージを中央サービス160-jに送信することができる。第10の段階では、交渉されたVoIPセッションが継続し得る。
いくつかの例では、段階6から9は、VoIPセッションデータストリームを中断することなく生じ得る。したがって、中央サービス160-jと端末110-jとの間で、テレマティクスデータおよびテレマティクスメタデータを搬送するSIPメッセージが交換されるのとほぼ同時に、音声および/または他のメディアを搬送するデータが交換され得る。いくつかの例では、段階6から9において中央サービス160-jと端末110-jとの間で送信されるSIP INFOメッセージおよびSIP STATUS 200(OK)メッセージは、VoIPセッションに関する有用なデータを搬送しないことがあり、むしろ、テレマティクスデータおよびテレマティクスメタデータを搬送することを唯一の目的として生成および/または送信され得る。代替として、段階6から9におけるSIP INFOメッセージおよびSIP STATUS 200(OK)メッセージは、端末110-jと中央サービス160-jとの間で重要なセッション情報または再交渉されたセッションパラメータを搬送することができる。
第11の段階であるVoIP呼の終わりには、端末110-jは、中央サービス160-jにSIP BYEメッセージを送信することができる。第12の段階では、中央サービス160-jは、VoIPセッションが終了していることを確認するためにSIP STATUS 200(OK)メッセージにより応答することができる。
図16は、例示的なワイヤレス端末110-kのブロック図を示している。端末110-kは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。本例のワイヤレス端末110-kは、プロセッサモジュール1605、メモリ1610、テレマティクスデータシグナリングモジュール210-c、トランシーバモジュール1625、およびアンテナ1630を含むことができる。これらの構成要素の各々は、直接または間接的に(たとえば1つまたは複数のバスを介して)、互いに通信可能に結合され得る。
上で説明したように、トランシーバモジュール1625は、アンテナ1630および/または1つもしくは複数の有線リンクもしくはワイヤレスリンクを介して、1つまたは複数のネットワークと双方向通信するように構成される。トランシーバモジュール1625は、データを変調し、変調されたデータを送信のためにアンテナ1630に提供し、かつアンテナ1630から受信されたデータを復調するように構成されたモデムを含み得る。端末110-kは単一のアンテナを含み得るが、端末110-kは、複数のリンクのための複数のアンテナ1630を含み得る。
メモリ1610は、ランダムアクセスメモリ(RAM)および読取り専用メモリ(ROM)を含み得る。メモリ1610は、実行されると、様々な機能をプロセッサモジュール1605に実施させるように構成された命令を含むコンピュータ可読コンピュータ実行可能ソフトウェアコード1615を記憶することができる。代替として、ソフトウェアコード1615は、プロセッサモジュール1605によって直接実行可能ではなくてもよいが、(たとえばコンパイルされ実行されると)本明細書で説明した機能を端末110-kに実施させるように構成されてもよい。
プロセッサモジュール1605は、インテリジェントハードウェアデバイス、たとえば、Intel(登録商標)Corporation、AMD(登録商標)、またはQualcomm(登録商標)によって作られるような中央処理装置(CPU)、マイクロコントローラ、特定用途向け集積回路(ASIC)などを含み得る。図16のアーキテクチャによれば、端末110-kは、テレマティクスデータシグナリングモジュール210-cをさらに含むことができる。モジュール210-cは、図2、図3、および/または図4に示すテレマティクスデータシグナリングモジュール210の一例であってよい。テレマティクスデータシグナリングモジュール210-cは、シグナリングモジュール1620を含むことができる。シグナリングモジュール1620はトランシーバモジュール1625に、生成されたシグナリングメッセージを中央サービスに送信させることができる。加えて、シグナリングモジュール1620はトランシーバモジュール1625に、変更されたSIPまたは他の通信セッションシグナリングプロトコルメッセージを中央サービスから受信させることができる。
図17は、中央サービス160-kを実装する例示的なデバイスのブロック図を示している。中央サービス160-kを実装するデバイスは、サーバまたは他のコンピュータベースのデバイスであり得る。中央サービス160-kは、図1Aの中央サービス160または以前の図を参照しながら上述した1つもしくは複数の他の中央サービス160の一例であってよい。本例の中央サービス160-kは、プロセッサモジュール1605-a、メモリ1610-a、テレマティクスメタデータシグナリングモジュール610-c、およびネットワークインターフェースコントローラ(NIC)1705を含むことができる。これらの構成要素の各々は、直接または間接的に、互いに通信可能に結合され得る。
メモリ1610-aは、ランダムアクセスメモリ(RAM)および読取り専用メモリ(ROM)を含み得る。メモリ1610-aは、実行されると、様々な機能をプロセッサモジュール1605-aに実施させるように構成された命令を含むコンピュータ可読コンピュータ実行可能ソフトウェアコード1615-aを記憶することができる。代替として、ソフトウェアコード1615-aは、プロセッサモジュール1605-aによって直接実行可能ではなくてもよいが、(たとえばコンパイルされ実行されると)本明細書で説明した機能を中央サービス160-kに実施させるように構成されてもよい。
中央サービス160-kは、テレマティクスメタデータシグナリングモジュール610-cを含むことができる。モジュール610-cは、図6、図7、および/または図8に示すテレマティクスメタデータシグナリングモジュール610の一例であってよい。テレマティクスメタデータシグナリングモジュール610-cは、シグナリングモジュール1620-aを含むことができる。シグナリングモジュール1620-aはNIC1705に、生成されたシグナリングメッセージを端末110に送信させることができる。加えて、シグナリングモジュール1620-aはネットワークインターフェースカード1705に、変更されたSIPまたは他の通信セッションシグナリングプロトコルメッセージを端末から受信させることができる。
図18は、テレマティクスデータおよび/またはテレマティクスメタデータを通信するための方法1800の一実施形態を示すフローチャートである。明快にするために、図1A、図1B、図2、図3、図4、図10、図11、図12、図13、図14、図15、および/または図16の端末110を参照しながら方法1800について説明する。一実装形態では、図2、図3、図4および/または図16のテレマティクスデータシグナリングモジュール210は、端末110の機能要素を制御するためのコードからなる1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。
ブロック1805では、通信セッションシグナリングプロトコルにより第1のデバイスから第2のデバイスに第1のシグナリングメッセージが送信され得る。一例では、第1のシグナリングメッセージは、少なくとも、第1のデバイスと第2のデバイスとの間の通信セッションに関係するセッション情報の第1のセットおよび第1のデバイスに関するテレマティクスデータの第1のセットを含むことができる。いくつかの例では、第1のデバイスは、以前の図を参照しながら説明した端末110のうちの1つまたは複数であってよく、第2のデバイスは、以前の図を参照しながら説明した中央サービス160のうちの1つまたは複数であってよい。通信セッションシグナリングプロトコルは、たとえば、以前の例で説明したセッション開始プロトコル(SIP)の変更バージョン、または別の適用可能な通信セッションシグナリングプロトコル(たとえば、XMPP、Googleトーク、スカイプなど)であり得る。通信セッションは、端末と中央サービスとの間のVoIP呼であり得る。場合によっては、通信セッションは、メディアストリームの内部のストリーミングメディア(音声、ビデオ、ストリーミングまたは文字単位テキストなど)ならびにメディアストリームの外部の任意のメディア(テキストメッセージなど)を交換することができる。一例では、通信セッションは、非ストリーミングメディアのみを搬送することができる。
ブロック1810では、通信セッションシグナリングプロトコルにより第1のデバイスにおいて第2のシグナリングメッセージが受信され得る。一例では、第2のシグナリングメッセージは、第1のシグナリングメッセージにおいて送信されたテレマティクスデータの第1のセットの内容に基づくメタデータを含むことができる。テレマティクスメタデータは、限定はしないが、テレマティクスデータが中央サービス160において受信されたかどうかの確認応答、テレマティクスデータの再送信を求める要求、異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービスによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータを含むことができる。
したがって、方法1800は、テレマティクスデータおよび/またはテレマティクスメタデータを通信することを実現し得る。方法1800は一実装形態にすぎず、方法1800の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
図19は、通信セッションシグナリングプロトコルにおいて使用されるシグナリングメッセージを変更することによって、テレマティクスデータおよび/またはテレマティクスメタデータを通信するための方法1900の一実施形態を示すフローチャートである。明快にするために、図1A、図1B、図2、図3、図4、図10、図11、図12、図13、図14、図15、および/または図16の端末110を参照しながら方法1900について説明する。一実装形態では、図2、図3、図4および/または図16のテレマティクスデータシグナリングモジュール210は、端末110の機能要素を制御するためのコードからなる1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。図19の方法1900は、図18の方法1800の一例であってよい。
ブロック1905では、端末において車両状態(たとえば、クラッシュ、火災、エアバッグ展開、転覆、または他の状況)、機能不全、または手動トリガが検出され得る。ブロック1910では、端末に通信可能に結合された1つまたは複数のセンサからの入力に基づいて、車両に関するテレマティクスデータの第1のセットが生成され得る。ブロック1915では、ボイスオーバーインターネットプロトコル(VoIP)呼セッションに中央サービス(たとえば、PSAP)を招待するために、端末においてSIP INVITEメッセージのヘッダが生成されてよく、このヘッダは、関連メッセージ本文がマルチパートフォーマットを有することを示す。ブロック1920では、端末において、提案されたセッションに関するパラメータのセットを含むセッション記述プロトコル(SDP)メッセージが生成され得る。ブロック1925では、SDPメッセージおよびテレマティクスデータの第1のセットを結合して、SIP INVITEメッセージのメッセージ本文にし、SDPメッセージをSIP INVITEメッセージの本文の第1の部分とし、テレマティクスデータをSIP INVITEメッセージの本文の第2の部分とすることができる。ブロック1930では、中央サービスにSIP INVITEメッセージが送信され得る。一例では、端末は、緊急要求を処理する責任を負うエンティティ(キャリアのネットワーク内のエンティティなど)にINVITEを送ることができ、そのエンティティは、INVITEを処理するか、または中央サービス(たとえば、PSAP)に転送することができる。
ブロック1935では、PSAP中央サービスデバイスからSIP STATUS 486(Busy)応答メッセージが受信され得る。一例では、応答メッセージは、メッセージ本文の第1の部分およびメッセージ本文の第2の部分におけるテレマティクスデータの第1のセットの受信を確認応答するテレマティクスメタデータのセットを含むマルチパート本文を含むことができる。SIP STATUS 486(Busy)応答メッセージは、メッセージ本文にSDP情報を含まないことがある(たとえば、メッセージ本文の第1の部分は空であり得るか、またはテレマティクスメタデータのセットはメッセージ本文の第1の部分にあり得るか、もしくはメッセージ本文における内容のみであり得る)ことに留意されたい。いくつかの例では、端末は、第2のシグナリングメッセージのヘッダから、SIP STATUS 486(Busy)応答メッセージの本文はマルチパートフォーマットにあると判断し得る。端末は、SIP STATUS 486(Busy)応答メッセージのヘッダ中の情報に基づいて、メッセージ本文の第1の部分およびメッセージ本文の第2の部分をさらに識別することができる。場合によっては、他のSTATUS応答が使用され得る。
ブロック1940では、VoIP呼セッションに関して、端末においてPSAP中央サービスデバイスからSIP INVITEメッセージが受信されてよく、SIP INVITEメッセージの本文は、端末に追加のテレマティクスデータを要求するテレマティクスメタデータのセットを含み得る。代替として、テレマティクスメタデータは端末において、別個のシグナリングメッセージで受信され得る。ブロック1945では、センサおよび/またはテレマティクスデータの他のソースからの入力に基づいて、車両に関してテレマティクスデータの第2のセットが生成され得る。ブロック1950では、端末においてSIP STATUS 200(OK)応答メッセージのヘッダが生成され得る。一例では、ヘッダは、関連メッセージ本文がマルチパートフォーマットを有することを示し得る。ブロック1955では、PSAP中央サービスデバイスによって提案されたセッションに関するパラメータを含むSDPメッセージが生成され得る。ブロック1960では、SDPメッセージおよびテレマティクスデータの第2のセットが結合されて、SIP STATUS 200(OK)メッセージのメッセージ本文にされ得る。ブロック1965では、端末から中央サービスにSIP STATUS 200(OK)応答メッセージが送信され得る。ブロック1970では、端末において中央サービスからSIP ACKメッセージが受信されてよく、ブロック1975では、端末と中央サービスとの間でVoIPセッションが確立され得る。
したがって、方法1900は、テレマティクスデータおよび/またはテレマティクスメタデータの通信を実現し得る。方法1900は一実装形態にすぎず、方法1900の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
図20は、テレマティクスデータおよび/またはテレマティクスメタデータを通信するための方法2000の一実施形態を示すフローチャートである。明快にするために、図1A、図1B、図6、図7、図8、図10、図11、図12、図13、図14、図15、および/または図17の中央サービス160を参照しながら方法2000について説明する。一実装形態では、図6、図7、図8および/または図17のテレマティクスメタデータシグナリングモジュール610は、中央サービス160の機能要素を制御するためのコードからなる1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。
ブロック2005では、通信セッションシグナリングプロトコルにより第2のデバイスにおいて第1のデバイスから第1のシグナリングメッセージの少なくとも一部分が受信され得る。一実施形態では、第1のシグナリングメッセージは、少なくとも、第1のデバイスと第2のデバイスとの間の通信セッションに関係するセッション情報の第1のセットを有することができる。第1のシグナリングメッセージは、少なくとも、第1のデバイスに関するテレマティクスデータの第1のセットを有することもできる。いくつかの例では、第1のデバイスは、以前の図を参照しながら説明した端末110のうちの1つまたは複数であってよく、第2のデバイスは、以前の図を参照しながら説明した中央サービス160のうちの1つまたは複数であってよい。通信セッションシグナリングプロトコルは、たとえば、以前の例で説明したセッション開始プロトコル(SIP)の変更バージョン、または別の適用可能な通信セッションシグナリングプロトコル(たとえば、XMPP、Googleトーク、スカイプなど)であり得る。通信セッションは、端末と中央サービスとの間のVoIP呼であり得る。場合によっては、通信セッションは、メディアストリームの内部のストリーミングメディア(音声、ビデオ、ストリーミングまたは文字単位テキストなど)ならびにメディアストリームの外部の任意のメディア(テキストメッセージなど)を交換することができる。一例では、通信セッションは、非ストリーミングメディアのみを搬送することができる。
ブロック2010では、第1のシグナリングメッセージに応答して、通信セッションシグナリングプロトコルにより第1のデバイスに第2のシグナリングメッセージが送信されてよく、この第2のシグナリングメッセージは、第1のシグナリングメッセージにおいて受信されたテレマティクスデータの第1のセットの内容に基づくメタデータを有する。
したがって、方法2000は、通信セッションシグナリングプロトコルにおいて使用されるシグナリングメッセージを変更することによって、テレマティクスデータおよび/またはテレマティクスメタデータを通信することを実現し得る。方法2000は一実装形態にすぎず、方法2000の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
図21は、通信セッションシグナリングプロトコルにおいて使用されるシグナリングメッセージを変更することによって、テレマティクスデータおよび/またはテレマティクスメタデータを通信するための方法2100の一実施形態を示すフローチャートである。明快にするために、図1A、図1B、図6、図7、図8、図10、図11、図12、図13、図14、図15、および/または図17の中央サービス160を参照しながら方法2100について説明する。一実装形態では、図6、図7、図8および/または図17のテレマティクスメタデータシグナリングモジュール610は、中央サービス160の機能要素を制御するためのコードからなる1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。図21の方法2100は、図20の方法2000の一例であってよい。
ブロック2105では、中央サービス(たとえば、PSAP)において、車両に関連する端末からSIP INVITEメッセージが受信され得る。SIP INVITEメッセージの本文は、SDPメッセージおよび車両に関するテレマティクスデータのセットを含むことができる。ブロック2110では、中央サービスにおいてオペレータが音声はおよび/または他のメディア呼を受け入れることが可能であるかどうかについての判断が下される。オペレータが対応可能である場合(ブロック2110、YES)、ブロック2115において、中央サービスは端末にSIP STATUS 200(OK)応答メッセージを送信することができ、このSIP STATUS 200(OK)応答メッセージは、テレマティクスデータの受信を確認応答するメタデータを含む。代替として、メタデータは、別個のシグナリングメッセージで端末に送信され得る。ブロック2120では、端末からSIP ACKメッセージが受信されてよく、ブロック2125では、端末との間でVoIPセッションまたは他の通信が確立され得る。
一方、オペレータが呼を受け入れることが可能ではない場合(ブロック2110、NO)、ブロック2130において、PSAP中央サービスデバイスは端末にSIP STATUS 485(BUSY)応答メッセージを送信することができ、この応答メッセージは、テレマティクスデータの受信を確認応答するメタデータを含む。ブロック2135では、オペレータが対応可能になったとき、中央サービスは端末にSIP INVITEメッセージを送信することができ、この場合、SIPメッセージの本文は、SDPメッセージおよびテレマティクスデータの再送信を要求するメタデータを含む。ブロック2140では、中央サービスは、端末からSIP STATUS 200(OK)応答メッセージを受信することができ、この場合、SIP STATUS 200(OK)応答メッセージの本文は、SDPメッセージおよびテレマティクスデータの第2のセットを含む。ブロック2145では、端末にSIP ACKメッセージが送信されてよく、ブロック2125では、端末との間でVoIPセッションまたは他の通信が確立され得る。
したがって、方法2100は、テレマティクスメタデータの通信を実現し得る。方法2100は一実装形態にすぎず、方法2100の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
図22は、本開示による、端末110-lの実施形態を示すブロック図2200である。端末110-lは、図1Aの端末110および/または図1Bの端末110-aの一例であってよく、たとえば、端末は、車両の緊急呼車載システム(IVS)であってよい。端末110-lは、端末受信機モジュール2205、テレマティクスデータシグナリングモジュール2210、および端末送信機モジュール2215を含むことができる。これらの構成要素の各々は、互いに通信していてよい。端末110-lは、図22に示されていない他のモジュールを含むことができ、たとえば、車両に関連する状況および事象を検出するためのセンサならびにGPS衛星から受信したワイヤレス信号から端末のロケーションを推定または判断することを可能にするための受信機およびプロセッサを含むことができる。
端末110-lのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一構成では、端末受信機モジュール2205は、セルラー受信機を含むことができ、(上述したように、中央サービス160と通信していてよい)基地局105から送信を受信することができる。一例では、端末受信機モジュール2205は、テレマティクスメタデータを含むように適合されている、通信シグナリングプロトコルに関するシグナリングメッセージを受信することができる。テレマティクスデータシグナリングモジュール2210は、適合されたシグナリングメッセージからテレマティクスメタデータを抽出すること、1つまたは複数の外部システムをアクティブ化すること、中央サービス160に送られるべきテレマティクスデータを収集すること、中央サービス160に送信され得る端末に関連する能力のセットを維持することなどができる。送信機モジュール2215は、基地局105を介して中央サービス160にテレマティクスデータ、能力データなどを送信するように構成され得る。
図23は、本開示による、端末110-mの実施形態を示すブロック図2300である。端末110-mは、図1A、図1B、および/または図22に示す端末110の一例であってよい。端末110-mは、前述のように、端末受信機モジュール2205、テレマティクスデータシグナリングモジュール2210-a、および端末送信機モジュール2215を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
端末110-mのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一実施形態では、テレマティクスデータシグナリングモジュール2210は、セッション制御モジュール2305、テレマティクスデータモジュール2310、外部システムモジュール2315、および能力モジュール2320を含むことができる。
セッション制御モジュール2305は、1つまたは複数のシグナリングメッセージを使用して、通信セッションを制御および/または促進することができる。いくつかの実施形態では、セッション制御モジュール2305は、通信セッションシグナリングプロトコルに従ってセッション情報を通信することによって、通信セッションを制御および/または促進することができる。一例では、セッション制御モジュール2305は、信号情報のセットを含むシグナリングメッセージを生成することができる。セッション制御モジュール2305は、信号情報のセットを含むシグナリングメッセージを取得することもできる。
セッション制御モジュール2305はまた、中央サービス160との通信セッションを交渉し、セットアップし、管理し、かつ終了させるように構成され得る。セッション制御モジュール2305は、中央サービスとの間でセッション関連シグナリングデータを通信するためにSIPシグナリングメッセージヘッダコンテンツおよびSDPコンテンツを生成することができる。セッション制御モジュール2305はまた、メディアコンテンツ(たとえば、音声呼のためのオーディオデータ、ビデオ呼のためのオーディオおよびビデオデータ、音声またはビデオを伴うか、または伴わない、テキストを伴う呼のためのテキストデータ)を受信し、交渉されたセッションに従って中央サービスにパケットのストリームとしてメディアコンテンツを送信し、かつ交渉されたセッションに従って中央サービスからメディアコンテンツを含むパケットのストリームを受信するように構成され得る。
テレマティクスデータモジュール2310は、テレマティクスデータを生成および/または取得することができる。テレマティクスデータモジュール2310は、テレマティクスメタデータを受信することもできる。いくつかの例では、テレマティクスデータモジュール2310は、受信したテレマティクスメタデータに基づいてテレマティクスデータを取得することができる。
テレマティクスデータモジュール2310は、端末110-mに関連するシステムまたはデバイスからテレマティクスデータを収集することができる。たとえば、端末110-mが車両に関連付けられる場合、テレマティクスデータモジュール2310は、車両タイプおよび車両識別番号(VIN)、1つもしくは複数のタイムスタンプ、位置推定および関連する信頼度、移動方向、(たとえば、シートベルトが締められた)乗客の数、端末のサービスプロバイダ(存在する場合)、トリガタイプ(たとえば、展開されたエアバッグ、バンパーセンサ、手動トリガ、火災表示灯、転覆、または他の状況検出など)、ならびに/または本明細書で説明する原理の特定の適用に適したものであり得る他の関連情報に関係するデータを収集することができる。テレマティクスデータモジュール2310は、中央サービス160によって理解されるプロトコルに従って中央サービス160に送信するためにテレマティクスデータをフォーマットすることもできる。いくつかの例では、テレマティクスデータモジュール2310は、中央サービスに送信するためにテレマティクスデータの標準セットをコンパイルすることができる。追加または代替として、テレマティクスデータモジュール2310は、中央サービスに送信するために中央サービスから要求された特定のテレマティクスデータのセットをコンパイルするように構成され得る。
テレマティクスデータモジュール2310はまた、中央サービス160に送信されたテレマティクスデータに関連する中央サービスから受信されたテレマティクスメタデータに基づいて実行され得るアクションを識別するために、テレマティクスメタデータを分析するように構成され得る。識別されるアクションは、具体的に中央サービスによって要求されること、またはテレマティクスデータモジュール2310によって、受信されたテレマティクスメタデータに基づいて推測されることがある。たとえば、テレマティクスメタデータは、テレマティクスデータの再送信、テレマティクスデータの異なるセットの送信、またはテレマティクスデータのセットの更新バージョンの送信を求める要求を含むことができる。テレマティクスデータモジュール2310は、適切なテレマティクスメタデータおよび/または適切な命令を外部システム制御モジュール2315に提供することができる。
外部システムモジュール2315は、中央サービスに送信されたテレマティクスデータに関連する中央サービスから受信されたテレマティクスメタデータに基づいて、1つまたは複数のアクションを実行するように構成され得る。たとえば、端末110-mが車両に関連付けられ、検出された衝突に応答して中央サービスにテレマティクスデータが送信される場合、テレマティクスメタデータは、車両およびその搭乗者に関する一定の予防アクションまたは救助アクションの実行を求める命令を含むことができる。そのようなアクションは、限定はしないが、追加のテレマティクスデータを収集すること、車両のイグニションをオフもしくはオンにすること、車両の燃料供給もしくは電源(たとえば、ドライブトレインバッテリ)をオフもしくはオンにすること、車両のドアの鍵を開けること、もしくは閉めること、車両のクラクションをアクティブ化すること、外部可聴音を再生すること、車両のライト(たとえば、ヘッドライト、ランニングライト)をオンにすること、車両の内部(たとえば、車内)ライトをオンにすること、車両の点滅灯(たとえば、4方向、緊急点滅灯、警告ライト)をオンにすること、パワーウィンドウを作動させること、中央サービスから受信されたか、もしくは端末110-mに記憶された録音メッセージを再生すること、メディアをレンダリングすること(たとえば、テキスト読み上げをレンダリングすること、中央サービスによって送られたメディアを再生すること、中央サービスによって送られた命令によって参照され、かつ/または当該命令に関連するメディアを再生すること)、中央サービスから受信されたか、もしくは端末110-mに記憶されたテキストメッセージを表示すること、車両のカメラを有効もしくは無効にすること、または他の適切なアクションを含み得る。クラクションをアクティブ化すること、外部可聴音を再生すること、ライトをオンにすること、および/または点滅灯をオンにすることなどにより、車両のロケーションの非常要員に警告すること、または車両が通知を受けるのを支援することができることに留意されたい。図23に関して、外部システムモジュール2315は、端末110-mが中央サービス160からアクションの実施を求める明示的な要求を受信した後にアクションを実施することができ、または中央サービス160からのメッセージからアクションが実施されるべきであると推測することができる。
能力モジュール2320は、端末110-mに関連するテレマティクス能力のセットを、能力のセットが図1Aの中央サービス160に提供され得るように記憶および/または生成するように構成され得る。上記のように、テレマティクス能力は、テレマティクスデータを収集し送ること、および/または外部システムモジュール2315を介してアクションを実行することを含む、端末110-mが実施することが可能であるアクションを含むことができる。いくつかの例では、中央サービス160は、収集され能力モジュール2320に記憶された受信された能力のセットに基づいて、端末110-mに提供される要求を適合することがある一方、他の実施形態では、中央サービス160は、端末110-mに提供される要求をそのように適合しないことがある。
いくつかの実施形態では、能力モジュール2320およびセッション制御モジュール2305は、中央サービス160との緊急呼を確立するために招待およびデータセット(たとえば、最小データセットなどのテレマティクスデータ)を送信するために一緒に動作するように構成され得、その場合にテレマティクス能力のセットが招待およびデータセットとともに送信される。他の実施形態では、能力モジュール2320およびセッション制御モジュール2305は、テレマティクス能力のセットの送信を求める中央サービス160による要求に応答して、緊急呼が確立された後にテレマティクス能力のセットを送信するために一緒に動作するように構成され得る。さらに他の実施形態では、能力モジュール2320およびセッション制御モジュール2305は、緊急呼の確立を求める招待への応答の確認応答とともにテレマティクス能力のセットを送信するために一緒に動作するように構成され得る。一般に、能力モジュール2320およびセッション制御モジュール2305は、緊急呼の確立前、確立中、または確立後のいつでも、能力のセットを送るように構成され得る。
図24は、本開示による、端末110-nの実施形態を示すブロック図2400である。端末110-nは、図1A、図1B、図22、および/または図23に示す端末110の一例であってよい。一構成では、端末110-nは、端末受信機モジュール2205、テレマティクスデータシグナリングモジュール2210-b、および端末送信機モジュール2215を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
端末110-nのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
図24に示すように、能力モジュール2320-a(図23における能力モジュール2320の1つまたは複数の態様の一例であってよい)は、データ構造フォーマッティングサブモジュール2405、サブセットサブモジュール2410、および/または再構成サブモジュール2415のうちの1つまたは複数を含むことができる。データ構造フォーマッティングサブモジュール2405は、1つまたは複数のアクションの実施を求める要求(たとえば、セッション制御モジュール2305、テレマティクスデータモジュール2310、および/または外部システムモジュール2315によって解釈可能な要求)を端末110-nが受け入れる要求データ構造に対応するデータ構造において、能力モジュール2320-aによって記憶された能力のセットをフォーマットするように構成され得る。一実施形態では、データ構造フォーマッティングサブモジュール2405は、要求データ構造と実質的に同等に能力データ構造をフォーマットすることができる一方、他の実施形態では、能力データ構造は、要求データ構造に似ているにすぎないことがある(たとえば、1つまたは複数の構成要素、構造、データ表現またはプログラミング言語などを共有することがある)。
特定の一実施形態では、データ構造フォーマッティングサブモジュールは、端末送信機モジュール2215を介して中央サービス160に送信され得る拡張マークアップ言語(XML)要素として能力データ構造をフォーマットするように構成され得る。能力XML要素は、中央サービス160にテレマティクスデータを送ること、および/または端末110-nに関連する何らかのシステムをアクティブ化するために外部システムモジュール2315を利用することなど、端末110-nが実施し得るアクションをそれぞれ定義する1つまたは複数の子XML要素を含むことができる。能力XML要素は、一定のアクションが実行されるべきである持続時間(たとえば、クラクションを10分間鳴らす)、サポートされるデータのタイプ(たとえば、端末110-nが車両の乗客に提示し得るビデオ、オーディオ、またはテキストの符号化)などのような、可能なアクションのうちの1つまたは複数に対応する1つまたは複数のパラメータを含むこともできる。パラメータは、各アクションXML子要素内のXML属性として実装されてよく、かつ/またはアクションXML子要素とともにさらなるXML子要素として実装されてよい。
サブセットサブモジュール2410は、端末110-nが実施することが可能である緊急呼アクションのすべてまたはサブセットのみを能力モジュール2320-aに送信させるように構成され得る。サブセットサブモジュール2410は、いくつかの実施形態では能力のすべてを送信するように構成されてよいが、代替的に、どのように緊急呼が開始されるかに基づいて能力のいくつかのサブセットのみを送るように構成されてよい。たとえば、緊急呼が、たとえば、検出された衝突に基づいて端末110-nによって自動的に開始される場合、サブセットサブモジュール2410は、中央サービス160に送信するために端末110-nに関連するテレマティクスまたは緊急呼能力のすべてを提供することができる。他方では、乗客がボタンを手で押すことによって緊急呼がアクティブ化される場合、サブセットサブモジュール2410は、中央サービスに送信するために緊急呼能力のサブセットのみを提供するように構成されてよく、サブセットは、緊急呼システムのユーザによって必要とされる支援のカテゴリに少なくとも部分的に基づく。たとえば、ユーザが緊急ボタンを押した場合に、サブセットサブモジュール2410は、すべての緊急呼能力を送信するように構成され得る一方、ユーザが支援ボタンを押した場合に、サブセットサブモジュール2410は、中央サービス160に送信するために端末110-nの能力全体の1つまたは複数の限定的サブセットを提供するように構成され得る。
再構成サブモジュール2415は、中央サービス160に送信するために能力モジュール2320-aに記憶または収集されたテレマティクス能力のセットを再構成するように構成され得る。一例では、再構成サブモジュール2415は、テレマティクス能力のセットを、能力のセットにおけるアクションに関連する車両構成要素の動作状態に少なくとも部分的に基づいて更新するように構成され得る。たとえば、車両の特定の構成要素が事故で損傷した場合、再構成サブモジュール2415は、能力のセットから損傷した構成要素に関連する能力を除去するように構成され得る。別の例では、再構成サブモジュール2415は、端末110-nに関連し、かつ/または中央サービス160によってサポートされる新しい能力または変更された能力に基づいて、IVSのメーカー、車両のメーカー、テレマティクスサービスプロバイダ、または別の指定エンティティのうちの1つまたは複数から構成命令を受信するように構成され得る。
図25Aおよび図25Bは、セッション情報とテレマティクスデータの両方を搬送するために使用され得るセッション開始プロトコル(SIP)要求メッセージの例を示し、図25Cは、SIP要求メッセージに含められ得るテレマティクス能力データ構造の一例を示している。上述のように、テレマティクス能力のセットは、緊急呼の確立前、確立中、または確立後を含む、多くの異なる時間に送信され得ることが理解されよう。図25A〜図25Cは、一例、すなわち、緊急呼の確立中に中央サービス160にテレマティクス能力のセットが送信される場合を示しているにすぎず、本開示は、もちろん、中央サービス160にテレマティクス能力のセットが送信される任意の時間に適合され得る。図25A〜図25Cの例は、XML要素を伴うSIP要求メッセージの文脈で記述されているが、本明細書の原理は、他の通信セッションシグナリングプロトコル(たとえば、XMPP、Googleトーク、MSNなど)を変更または拡張するために、または新しい通信セッションシグナリングプロトコルの土台として使用されてよく、他のデータ構造またはデータ表現を使用してもよいことが理解されよう。
ここで特に図25Aを参照すると、要求メッセージの例示的なフォーマット2500の図が示されている。SIP要求メッセージフォーマット2500は、要求ライン2505、ヘッダ2510、セッション情報2515(たとえば、セッションパラメータ、セッションデータ)、テレマティクスデータ2520、さらにテレマティクス能力データ2525を含むことができる。SIPプロトコルは、Internet Engineering Task Force(IETF)によって、RFC3261などのいくつかのRequest For Comments標準において定義されている。これらの標準は、INVITEメッセージ、ACKメッセージ、BYEメッセージ、CANCELメッセージ、OPTIONSメッセージ、REGISTERメッセージ、PRACKメッセージ、SUBSCRIBEメッセージ、NOTIFYメッセージ、PUBLISHメッセージ、INFOメッセージ、REFERメッセージ、MESSAGEメッセージ、およびUPDATEメッセージを含む、いくつかのSIP要求および応答メッセージを定義している。本フォーマット2500は、これらのメッセージの各々に、ならびに他のタイプの要求および応答メッセージに使用され得る。
ここで図25Bの例を参照すると、図25Aのフォーマットに基づく変更されたSIP INVITEメッセージ2500-aが、たとえば、端末によって、同時に中央サービスとの呼または他の通信セッションを要求し、テレマティクスデータをその中央サービスに送信し、さらにテレマティクス能力のセットをその中央サービスに送信するために使用され得る。このようにして、中央サービスは、どのアクションを端末110がサポートし、実施することが可能であるかを知ることができる。
例示的なSIP INVITEメッセージ2500-aの要求ライン2505-aは、メッセージ2500-aを要求として識別し、行われている要求のタイプ(たとえば、INVITE)を明示することができる。要求メッセージのヘッダ2510-aは、要求のソース、要求の予定受信側(たとえば、緊急サービスURN)、呼識別子、ソースに関する連絡先情報、呼連続番号、本文におけるデータのタイプの指示、およびメッセージの長さを定義することができる。本例では、ヘッダ2510-aは、本文が混合データを含むことを明示することができ、文字列"--boundary1--"は、本文における異なるタイプのデータの間の境界を示している。本例では、メッセージの本文は、セッション情報2515-a、テレマティクスデータ2520-a、およびテレマティクス能力データ2525-aを含む。本例が一般に含まれ得るヘッダフィールドのすべてを示していないことがあることに留意されたい。
セッション情報2515-aは、端末と中央サービスとの間の提案されたセッションに関するパラメータのリストを含むことができる。たとえば、SIP INVITEメッセージ2500-aは、VoIPオーディオ呼をセットアップするためのセッション記述プロトコル(SDP)パラメータのセットを含むことができる。
テレマティクスデータ2520-aは、中央サービスに送信される端末に関連するセンサ読取値、記憶または記録されたデータ、および他のデータを含むことができる。いくつかの例では、テレマティクスデータは、セッションのセットアップおよび維持に直接関係しないことがある。したがって、中央サービスがSIP INVITEメッセージ2500-aのセッション情報2515-a部分における呼の提案されたパラメータを拒否した場合、または他の理由でセッションを確立することが不可能な場合でも、中央サービスは依然として、テレマティクスデータ2520-aを受信し処理することができる。本例では、SIP INVITEメッセージ2500-aは、車両における自動または手動のトリガに基づいてPSAPサービス160との緊急呼を提案することができる。テレマティクスデータ2520-aは、車両および/またはその搭乗者のステータスならびに緊急呼をトリガした事象に関係するいくつかの測定値を含むことができる。図25Bの例に示すように、テレマティクスデータ2520-aは、ステータスコード、積荷タイプ、端末に関連するメーカー固有識別子、車両のロケーション、車両の現在または以前の速度、車両の方向、およびチェックサムを含むことができる。いくつかの例では、テレマティクスデータ2520-aは、eCallの最小データセット(MSD)または緊急呼データの他の標準セット、たとえば、標準もしくは業界団体によって、またはある国もしくは地域のために定義されているようなセットを含むことができる。
SIP INVITEメッセージ2500-aは、能力データオブジェクト2530を含むこともでき、ここで図25Cを参照しながら、その一例2530-aについて説明する。図25Cでは、能力データオブジェクト2530-aは、XMLルートヘッダ<capabilities>、複数の要求子XML要素2535-a-1、2535-a-2、2535-a-3、2535-a-4、2535-a-5、2535-a-6を含み、</capabilities>で閉じる。要求子XML要素2535-a-1、2535-a-2、2535-a-3、2535-a-4、2535-a-5、2535-a-6の各々は、場合によっては1つまたは複数のパラメータとともに、アクションを定義する。
たとえば、第1の要求子XML要素2535-a-1は、(たとえば、車両の無線機またはインフォテインメントディスプレイ上に)静的メッセージを表示することに関連するアクション"msg-static"を定義し、アクションのパラメータとしてXML属性を含み、属性は、サポートされる最高の静的メッセージであり得るmsgidである。第2の要求子XML要素2535-a-2は、(たとえば、車両の無線機またはインフォテインメントディスプレイ上に)カスタムメッセージを表示することに関連するアクション"msg-custom"を定義し、サポートされるデータタイプがテキストデータタイプであることをさらに明示する。第3の要求子XML要素2535-a-3は、車両の無線機またはオーディオシステムにオーディオファイルをレンダリングさせることに関連するアクション"play-audio"を定義し、サポートされるデータタイプが3gpp、3gpp2、amr、およびevrcの登録済み多目的インターネットメール拡張(MIME)オーディオサブタイプを含むことをさらに明示する。第4の要求子XML要素2535-a-4は、車両のライトを照らすことに関連するアクション"lights-flash"を定義する。第4の要求子XML要素2535-a-4は、どのライトを車両が照らすことが可能であるか(内部、外部前方、外部後方)も明示し、サポートされる持続時間パラメータを定義する。第5の要求子XML要素2535-a-5は、中央サービス160にテレマティクスデータを送ることを求める車両向けの要求に関連するアクション"send-data"を定義し、どのデータセットが送られ得るかを明示する。第6の要求子XML要素は、カメラをアクティブ化することに関連するサポートされるアクション"enable camera"を定義し、どのカメラがサポートされるか(たとえば、バックアップカメラ、ブラインドスポットカメラ、インテリアカメラなど)、およびビデオメディアのサポートされる送信フォーマット(たとえば、H.264、3gpp、3gpp2)をさらに明示する。
図25A〜図25Cは、能力データオブジェクト2530がSIP INVITEメッセージ2500-aにおいて送信される一例について説明してきたが、他の実装形態では、能力データオブジェクト2530は、それ自体のメッセージを含む異なるメッセージにおいて送られ得ることに留意されたい。また、図25Cに示すXML構造および例示的なアクションは、1つの可能な実装形態の一例として本明細書で提供されているが、他のデータ構造フォーマットおよび追加のアクションも本明細書で企図される。さらに、明快にするために上記で説明していないが、車両とPSAPとの間の通信は、認証などの様々なセキュリティ機能を含むことができることを理解されたい。たとえば、セルラーネットワークを介して発せられたeCallまたは他の緊急呼として車両によって開始されたセッション内でPSAP要求が受信されたとき、送信元が実際にPSAPであることのより高い信頼度がある。コールバックなどの他の状況においてPSAP要求が受信された場合、コールバックが実際にPSAPからのものであることを確認する際の信頼性問題は、より複雑である。(どちら側が呼を開始したか、および呼の手段に関係なく適用可能な)1つの手法は、PSAPまたは緊急サービスプロバイダが、既知の緊急サービス認証局によって発行された、IVSがルート認証を確認できる認証を使用して本文部分にサインすることである。
図26は、本開示による、中央サービス160-lの実施形態を示すブロック図2600である。中央サービス160-lは、図1Aおよび/または図1Bの中央サービス160の一例であってよい。中央サービス160-lは、中央サービス受信機モジュール2605、テレマティクスメタデータシグナリングモジュール2610、および中央サービス送信機モジュール2615を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
中央サービス160-lのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一構成では、中央サービス受信機モジュール2605は、セルラー受信機および/またはネットワークインターフェースカード(NIC)を含むことができ、図1Bにおける他のIPサービスおよびネットワーク175または任意の他のIP接続サービスを介して通信を受信することができる。一例では、中央サービス受信機モジュール2605は、テレマティクスデータを含むように適合されている、通信シグナリングプロトコルに関するシグナリングメッセージを受信することができる。テレマティクスメタデータシグナリングモジュール2610は、適合されたシグナリングメッセージからテレマティクスデータを抽出することができる。テレマティクスメタデータシグナリングモジュール2610は、(何らかのアクションの実行を求める端末向けの要求を含むこともできる)テレマティクスメタデータを含むように通信シグナリングプロトコルに関するシグナリングメッセージを適合することもできる。通信シグナリングプロトコルに関する適合されたシグナリングメッセージは、中央サービス送信機モジュール2615を介して送信され得る。別の構成では、中央サービス受信機モジュール2605は、たとえば図1BにおけるESRP111からの、有線手段を介したパケットデータの受信をサポートすることができる。
図27は、本開示による、中央サービス160-mの実施形態を示すブロック図2700である。中央サービス160-mは、図1A、図1B、および/または図26に示す中央サービス160の一例であってよい。中央サービス160-mは、前述のように、中央サービス受信機モジュール2605、テレマティクスメタデータシグナリングモジュール2610-a、および中央サービス送信機モジュール2615を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
中央サービス160-mのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
一実施形態では、テレマティクスメタデータシグナリングモジュール2610-aは、テレマティクスメタデータモジュール2705を含むことができる。テレマティクスメタデータモジュール2705は、テレマティクスメタデータを生成および/または取得することができる。テレマティクスメタデータモジュール2705は、テレマティクスデータを受信することもできる。いくつかの例では、テレマティクスメタデータモジュール2705は、受信されたテレマティクスデータに基づいてテレマティクスメタデータを生成することができ、端末に関連する受信された能力のセットに基づいて、メタデータに含めるべき要求を生成することができる。
テレマティクスメタデータシグナリングモジュール2610-aは、セッション制御モジュール2305-aを含むこともできる。セッション制御モジュール2305-aは、図23および/または図24に示すセッション制御モジュール2305の一例であってよい。一例では、セッション制御モジュール2305-aは、信号情報のセットを含むシグナリングメッセージを取得することができる。セッション制御モジュール2305-aは、(テレマティクスメタデータモジュール2705によって生成された要求を含み得る)信号情報のセットを含むシグナリングメッセージを生成することもできる。セッション制御モジュール2305-aはまた、緊急呼の確立を求める端末からの要求を受信するように構成され得る。いくつかの実施形態では、端末に対応する能力のセットは、緊急呼の確立を求める要求とともに受信され得る。他の実施形態では、能力のセットは、緊急呼の確立を求める要求とともに受信されることはないが、代わりに、セッション制御モジュール2305-aは、端末のテレマティクス能力のセットを中央サービス160-mに送信することを求める端末向けの、端末に送信されるべき要求を生成するように構成され得る。
図28は、本開示による、中央サービス160-nの実施形態を示すブロック図2800である。中央サービス160-nは、図1A、図1B、図26、および/または図27に示す中央サービス160の一例であってよい。一構成では、中央サービス160-nは、中央サービス受信機モジュール2605、テレマティクスメタデータシグナリングモジュール2610-b、および中央サービス送信機モジュール2615を含むことができる。これらの構成要素の各々は、互いに通信していてよい。
中央サービス160-nのこれらの構成要素は、適用可能な機能のいくつかまたはすべてをハードウェアで実施するように適合された、1つまたは複数の特定用途向け集積回路(ASIC)により個別にまたは集合的に実装され得る。代替的に、それらの機能は、1つまたは複数の他の処理ユニット(またはコア)によって、1つまたは複数の集積回路上で実施され得る。他の実施形態では、当技術分野で知られている任意の方法でプログラムされ得る、他のタイプの集積回路(たとえば、構造化/プラットフォームASIC、フィールドプログラマブルゲートアレイ(FPGA)、および他のセミカスタムIC)が使用され得る。各ユニットの機能は、1つまたは複数の汎用プロセッサまたは特定用途向けプロセッサによって実行されるようにフォーマットされたメモリ内で具体化された命令により、全体的にまたは部分的に実施することもできる。
テレマティクスメタデータシグナリングモジュール2610-bは、セッション制御モジュール2305-aを含むことができ、セッション制御モジュール2305-aは、図27に示すセッション制御モジュール2305の一例であってよい。セッション制御モジュール2305-aは、端末との間でセッション関連シグナリングデータを通信するためにSIPシグナリングメッセージヘッダコンテンツおよびSDPコンテンツを生成することを含め、端末との通信セッションを交渉し、セットアップし、管理し、かつ終了させるように構成され得る。セッション制御モジュール2305-aはまた、メディアコンテンツ(たとえば、音声呼のためのオーディオデータ、ビデオ呼のためのオーディオおよびビデオデータ、テキスト呼のためのテキストデータ)を受信し、交渉されたセッションに従って端末にパケットのストリームとしてメディアコンテンツを送信し、かつ交渉されたセッションに従って端末からメディアコンテンツを含むパケットのストリームを受信するように構成され得る。
テレマティクスメタデータシグナリングモジュール2610-bは、テレマティクスメタデータモジュール2705-aを含むこともでき、テレマティクスメタデータモジュール2705-aは、データ構造フォーマッティングサブモジュール2405-a、適合サブモジュール2805、および要求サブモジュール2810を含むことができる。
データ構造フォーマッティングサブモジュール2405-aは、端末から能力のセットを受信し、端末に返送すべき適切な要求を(たとえば、受信された能力のセットのフォーマットに従って)策定することができる。たとえば、ネストされたXMLフォーマット(たとえば、図25C参照)において能力のセットが受信された場合、データ構造フォーマッティングサブモジュール2405-aは、能力XML要素から要求子XML要素を抽出し、要求データ構造を、中央サービス160-nが端末に要求を送る際に利用できるようにすることができる。代替的に、データ構造フォーマッティングサブモジュール2405-aは、1つのフォーマット(たとえば、JSON)において能力のセットを受信し、別のフォーマット(たとえば、XML)に従って中央サービス160-nのためにセットを再フォーマットすることができる。
適合サブモジュール2805は、端末から能力のセットを受信することもでき、受信された能力のセットに基づいて、どのタイプの要求が端末に送られるかを適合するように構成され得る。たとえば、一実施形態では、端末がテキストを表示することが可能であるが、オーディオを再生することが可能ではないことを能力のセットが示す場合、適合サブモジュール2805は、本来であればオーディオファイルとして送られていたものを、端末によって表示され得るテキストファイルに適合することができる。別の例として、中央サービス160-nに緊急呼に対応可能である電話対応オペレータがいない場合、適合サブモジュール2805は、たとえば、安全性を高めるための予防措置を含むアクションのデフォルトセットを端末に送るように構成され得る。他方では、電話対応オペレータが対応可能である場合、適合サブモジュール2805は、受信された能力のセットを構文解析し、どのコマンドおよびそれらのコマンドに関するどのパラメータを端末に送るかを電話対応オペレータが選択できるように、端末の能力の各々(または能力のうちの1つもしくは能力のセットの抽象化もしくは一般化)を電話対応オペレータに提示することができる。
要求サブモジュール2810は、データ構造フォーマッティングサブモジュール2405-a、適合サブモジュール2805、電話対応オペレータなどによる通知に従い、受信された能力のセットおよび/または受信されたテレマティクスデータに基づいて、一定のアクションの実行を求める端末向けの要求を生成することができる。要求は、中央サービス送信機モジュール2615によって端末に送信されるテレマティクスメタデータに含められ得る。適合サブモジュール2805または要求サブモジュール2810は、アクションまたはアクションの一般化の実施を求める車両向けの電話対応オペレータによる要求を受信することもでき、要求を車両の特定の能力にマッピングすることができる。たとえば、それぞれのモジュール(2805/2810)が、様々なライト(場合によっては、ヘッドランプ、ランニングランプ、ターンシグナル、ブレーキランプ、およびハザードランプ)を照らす能力を含む車両能力のセットを受信した場合、モジュールは、「車両ライトを照らす」として、電話対応オペレータへの提示のために要求を一般化することができ、一般化または抽象化されたアクションの実施を求める車両向けの電話対応オペレータによる要求を受信すると、モジュールは、どの能力を呼び出すかを選択することができる。そのため、たとえば、電話対応オペレータが車両にそのライトを照らすことを要求した場合、モジュールは、ライトの優先順位付きまたは順序付きリストを使用して、合致する能力のうちのどれを呼び出すかを選択することができ、またはリストを使用せずに選択することができる(たとえば、車両によって報告された第1のサポートされるライトを選ぶことができる)。そのため、発呼者が車両にライトを照らすことを要求し、車両がたとえばヘッドランプ、ランニングランプ、ターンシグナル、ブレーキランプ、およびハザードランプを照らすことが可能であるとき、モジュールは、照らすべきてヘッドランプおよびブレーキランプを選択する。
図29Aおよび図29Bは、セッションデータとテレマティクスメタデータ(1つまたは複数のアクションの実行を求める端末向けの要求を含む)の両方を搬送し得るセッション開始プロトコル(SIP)応答メッセージの例を示している。図29A〜図29BのSIP応答メッセージは、図25A〜図25Cの記述によるSIP要求メッセージを受信したことに応答して、中央サービス160から端末110に送信され得る。
図29Aは、応答メッセージの例示的なフォーマット2900の図を示しており、図29Bは、図29Aのフォーマットに基づく例示的なSIP応答メッセージ2900-aを示している。図29Aおよび図29Bの例は、SIPプロトコルおよびXMLデータ構造を参照しながら記述されているが、本明細書の原理を他の通信セッションシグナリングプロトコル(たとえば、XMPP、Googleトーク、MSNなど)を変更または拡張するために、または新しい通信セッションシグナリングプロトコルの土台として使用でき、また、他のデータ構造を実装するためにも使用できることが理解されよう。
SIP応答メッセージフォーマット2900は、SIP要求メッセージに応答してシグナリングメッセージを生成するために使用され得る。図29Aに示すように、SIP応答メッセージフォーマット2900は、要求ライン2905、ヘッダ2910、セッションデータのセット2915、およびテレマティクスメタデータのセット2920を含むことができ、テレマティクスメタデータのセット2920は、テレマティクスデータを送ること、端末に関連する外部システムを作動させることなどを含む、何らかのアクションの実行を求める端末向けの1つまたは複数の要求を含む。SIPプロトコルは、いくつかの応答メッセージ、仮応答、成功した応答、宛先変更応答、およびクライアント失敗応答を定義する。本フォーマット2900は、これらのメッセージタイプの各々に、および他のタイプの応答メッセージに使用され得る。
図29Bの例では、図29Aのフォーマットに基づく変更されたSIP200(OK)メッセージ2900-aが、たとえば、中央サービスによって、図25Bの変更されたSIP INVITEメッセージ2500-aを受信したことに応答して、提案されたセッションを中央サービスが受け入れることを示すために使用され得る。SIP200(OK)メッセージ2900-aはさらに、SIP INVITEメッセージ2550において送信されたテレマティクスデータの受信を確認応答するメタデータを端末に提供することができる。SIP200(OK)メッセージ2900-aはまた、(たとえば、緊急サービスが通知されており、音声確認待ちであることを示す)追加情報、(端末によって実施されるべき要求を含む)メタデータなどを提供することができる。
例示的なSIP200(OK)シグナリングメッセージ2900-aのステータスライン2905-aは、メッセージ2900-aをSIP応答として識別し、行われている応答のタイプ(たとえば、OK)を明示することができる。応答メッセージのヘッダ2910-aは、端末および中央サービスの識別情報、呼識別子、端末および中央サービスに関する連絡先情報、呼連続番号、本文におけるデータのタイプの指示、および応答メッセージ2900-aの長さを提供することができる。本例では、ヘッダ2910-aは、本文が混合データを含むことを明示することができ、文字列"--boundary1--"は、本文における異なるタイプのデータの間の境界を示している。本例では、メッセージの本文は、セッションデータ2915-aとテレマティクスメタデータ2920-aの両方を含み、テレマティクスメタデータは、アクションの実施を求める端末向けの1つまたは複数の要求を含む。
セッションデータ2915-aは、端末と中央サービスとの間の提案されたセッションに関する合意されたパラメータのリストを含むことができる。これらのセッションパラメータは、VoIPオーディオ呼のためのセッション記述プロトコル(SDP)パラメータのセットであり得る。
テレマティクスメタデータ2920-aは、SIP INVITEシグナリングメッセージ2500-aの中で中央サービスにおいて受信されたテレマティクスデータに関係する情報を含むことができる。前述のように、テレマティクスメタデータ2920-aは、テレマティクスデータが中央サービスにおいて受信されたかどうかの確認応答、テレマティクスデータの再送信を求める要求、異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行を求める要求、中央サービスによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータを含むことができる。車両に関連する端末からPSAPサービスに行われた緊急呼の例を参照すると、図29Bに示すテレマティクスメタデータ2920-aは、テレマティクスデータが受信されたことの確認応答、緊急サービスが通知されていることを示すステータスコードまたは他の指示、音声呼待ちであることの指示などを含むことができる。
特に図29Bの例を参照すると、テレマティクスメタデータ2920-aは、複数の要求2925-a-1、2925-a-2、2925-a-3、2925-a-4、2925-a-5、2925-a-6を含む。例示のために、図29Bのメタデータ2920-aに示す要求2925-a-1、2925-a-2、2925-a-3、2925-a-4、2925-a-5、2925-a-6は、図25Cにおける能力XML要素2530-aの要求子XML要素2535-a-1、2535-a-2、2535-a-3、2535-a-4、2535-a-5、2535-a-6に対応する。第1の要求2925-a-1は、22のメッセージIDを有する静的メッセージの表示を求める端末向けの要求である。図29Bにおける第1の要求2925-a-1のフォーマットは、図25Cにおける第1の要求子XML要素2535-a-1のフォーマットに対応する、すなわち、両方は実質的に同等のXMLフォーマットにあり、唯一異なる点は、第1の要求2925-a-1が、図25Cにおける能力XML要素2530-a内の子XML要素である代わりに、図29BにおけるeCall-要求XML要素内の子XML要素であることが諒解されよう。ただし、第1の要求2925-a-1は子要素として含まれる必要はなく、それ自体のルート要素であってもよいことが諒解されよう。
図29Bにおける第2の要求2925-a-2は、図25Cにおける第2の要求子XML要素2535-a-2に対応し、カスタムメッセージの表示を求める端末向けの要求であり、メッセージは、端末から中央サービスに送信された能力のセットにおいて第2の要求子XML要素2535-a-2によって明示されるようなテキストフォーマットとしての第2の要求2925-a-2内の子XML要素として提供される。同様に、図29Bにおける第3の要求2925-a-3は、図25Cにおける第3の要求子XML要素2535-a-3に対応し、オーディオファイルの再生を求める端末向けの要求であり、オーディオは、端末から中央サービスに送信された能力のセットにおいて第3の要求子XML要素2535-a-3によって明示されるような3gppフォーマットにおける第3の要求2925-a-3内の子XML要素として提供される。
図29Bにおける第4の要求2925-a-4は、図25Cにおける第4の要求子XML要素2535-a-4に対応し、不確定な持続時間にわたって車両の外部ライトおよびフロントライトを照らすことを求める端末向けの要求であり、ライトの選択および持続時間は、端末から中央サービスに送信された能力のセットにおいて第4の要求子XML要素2535-a-4によって明示されるような第4の要求2925-a-4内のXML属性として提供される。図29Bにおける第5の要求2925-a-5は、図25Cにおける第5の要求子XML要素2535-a-5に対応し、中央サービスに代替のデータセットを送ることを求める端末向けの要求であり、送信されるべきデータのタイプは、端末から中央サービスに送信された能力のセットにおいて第5の要求子XML要素2535-a-5によって明示されるような第5の要求2925-a-5内のXML属性として提供される。図29Bにおける第6の要求2925-a-6は、図25Cにおける第6の要求子XML要素2535-a-6に対応し、インテリアカメラを有効にすること、およびH.264フォーマットにおいてビデオフィードを送信することを求める端末向けの要求であり、カメラの選択および送信フォーマットは、端末から中央サービスに送信された能力のセットにおいて第6の要求子XML要素2535-a-6によって明示されるような第6の要求2925-a-6内のXML属性として提供される。ビデオフィードの送信は、SIP re-INVITEを使用することによって実施されてよく、その場合に送信フォーマットは、SDP属性を使用して交渉され、送信フォーマットは、要求から省かれてよく、またはre-INVITEにおけるSDP属性の初期セットは、要求において示された送信フォーマットに基づき得る。
図25A、図25B、図25C、図29A、および図29Bの例は、XMLデータ構造を使用してテレマティクスデータおよびメタデータを搬送するSIP要求メッセージの例を示しているが、他の通信セッションシグナリングプロトコルおよび他のデータ構造フォーマットが使用されてよいことを当業者は認識されよう。
図30は、通信セッションシグナリングプロトコルを使用するテレマティクスデータ、能力、およびテレマティクスメタデータ(端末110-oが何らかのアクションを実行することの中央サービス160-oからの要求を含む)の交換に関する端末110-oと中央サービス160-oとの間の通信交換の一例の図である。端末110-oは、上述した端末110の一例であってよく、中央サービス160-oは、上述した中央サービス160の一例であってよい。いくつかの例では、中央サービス160-oは、1つまたは複数のサーバによって実装され得る。
通信セッションシグナリングプロトコルは、背後にあるトランスポート層とは無関係であるように設計されたアプリケーション層プロトコルであり得る。したがって、いくつかの例では、通信セッションシグナリングプロトコルは、いくつかの異なるトランスポート層プロトコルに適合することができる。いくつかの例では、端末110-oと中央サービス160-oとの間の初期シグナリングメッセージがプロキシサーバのうちの1つまたは複数の間で転送され得るように、1つまたは複数のプロキシサーバが端末110-oと中央サービス160-oとの間に中間物として配設され得る。明快にするために、そのようなプロキシサーバは、本明細書に関連する図に示されていない。メッセージ交換を受信、転送、再生、変更し、あるいはメッセージ交換に関与する他の(たとえば、追加の)エンティティ(たとえば、SIPシグナリングの場合、バックトゥバックユーザエージェント、セッションボーダーコントローラなど)があり得ることに留意されたい。図30では、通信セッションシグナリングプロトコルは、SIP、XMPP、Googleトーク、スカイプなどであってよく、背後にあるトランスポート層は、ユーザデータグラムプロトコル(UDP)オーバーIPもしくは伝送制御プロトコル(TCP)オーバーIPまたはトランスポートプロトコルの何らかの他のセットであってよい。
端末110-oは、通信セッションをセットアップし管理するために、通信セッションシグナリングプロトコルにより中央サービスと通信することができる。端末110-oおよび中央サービス160-oは、端末110-oに関連するユーザと中央サービス160-oに関連するオペレータ(自動オペレータまたは人間オペレータであり得る)との間の(音声および/または他のメディアを搬送する)緊急呼のためのセッションを確立するために通信することができる。図30に示すように、端末110-oは、中央サービス160-oにセッション開始シグナリングメッセージを送信することができる。セッション開始シグナリングメッセージは、端末110-oとの緊急呼セッションに参加するよう中央サービス160-oを招待することができる。端末110-oは、端末110-oに関連するユーザからの手動要求に応答してセッション開始メッセージを送信することができる。たとえば、端末110-oに関連する車両の搭乗者は、中央サービス160-oをVoIPセッションに招待するよう端末110-oにシグナリングする車両中の緊急呼ボタンを押すことができる。追加または代替として、端末110-oは、1つまたは複数の検出または推測された状況または事象(たとえば、展開されたエアバッグ、衝突センサ、エンジン診断データ、エンジンの火災、車両の火災、転覆、または他の状況など)に応答して、中央サービス160-oにセッション開始メッセージを自動的に送信することができる。
セッション開始メッセージは、提案されたセッションに関する詳細およびパラメータ(たとえば、ネットワークアドレス、ポート番号、メディアのタイプ、タイミング、サポートされるストリーミングプロトコル、帯域幅など)を含むことができる。端末110-oと中央サービス160-oとの間の提案されたセッションに関するこのセッションデータセットに加えて、端末デバイス110-oは、中央サービス160-oに送信されるセッション開始メッセージにテレマティクスデータを付加(たとえば、追加)することができる。テレマティクスデータは、端末110-oと通信している1つまたは複数のセンサからの読取値および/または端末110-oによって記憶、判断、計算および/または受信された他のデータを含むことができる。いくつかの例では、テレマティクスデータは、eCallまたは他の緊急呼の間にPSAPに一般に送信されるデータを含むことができる。たとえば、テレマティクスデータは、eCallがどのように開始されたか、車両タイプおよび車両識別番号(VIN)、タイムスタンプ、位置推定および位置信頼フラグ、移動方向、(たとえば、シート占有センサによる)乗客の数および関連データ(たとえば、シートベルトが締められたシート)、端末のサービスプロバイダ(存在する場合)、トリガタイプ(たとえば、展開されたエアバッグ、バンパーセンサ、火災表示灯、転覆、または他の状況検出など)、ならびに/または本明細書で説明する原理の特定の適用に適したものであり得る他の関連情報のうちの少なくとも1つまたは複数を含むことができる。
端末110-oは、いくつかの例ではセッション開始メッセージおよびテレマティクスデータとともにテレマティクス能力のセットを送信することもできる。テレマティクス能力は、たとえば、上記のように、(追加の)テレマティクスデータを送ること、または端末110-oにおいて何らかの物理的アクションを実施することを含む、端末110-oが実施することができるアクションを含むことができる。
中央サービス160-oは、テレマティクスデータが付加されたセッション開始メッセージを受信すると、提案されたセッションを受け入れるか、または拒否するかを判断することができる。本例では、中央サービス160-oは、提案されたセッションに関するさらなるパラメータおよびデータを提供することに加えて、当該セッションが受け入れられたことを示すセッション確認メッセージを通信セッションシグナリングプロトコルにより送信することができる。さらに、端末110-oに送信されたセッション確認メッセージは、テレマティクスメタデータのセットを含むことができ、テレマティクスメタデータのセットは、テレマティクスデータが中央サービス160-oにおいて受信されたかどうかの確認応答、中央サービス160-oへのテレマティクスデータ(たとえば、以前のバージョンおよび/もしくは現在のバージョン)の再送信を求める要求、中央サービス160-oへの異なるテレマティクスデータの送信を求める要求、何らかの他のアクションの実行(たとえば、外部システムを作動させること)を求める要求、中央サービス160-oによって実行されたアクションを記述した補助データ、および/または他の関連テレマティクスメタデータを含むことができる。代替例では、中央サービス160-oは、(たとえば、テレマティクスメタデータを送信するために特に使用される通信セッションシグナリングプロトコルメッセージで、異なるタイプの通信セッションシグナリングプロトコルメッセージに付加されて)別個のメッセージで端末110-oに、アクション要求を含むテレマティクスメタデータを送信することができる。
端末110-oは、テレマティクスメタデータを受信し、受信されたテレマティクスメタデータに基づいて、中央サービス160-oによって要求されたアクションを実行することができる。いくつかの例では、テレマティクスメタデータは、テレマティクスデータの受信を確認するだけであることがあり、端末110-oは、テレマティクスメタデータに応答したアクションを一切実行しないことがある。他の例では、端末110-oは、中央サービス160-oからのテレマティクスメタデータにおける要求に応答すること、または受信されたテレマティクスメタデータに基づいて実行すべきアクションを識別するためにルールのセットを調べることができる。
加えて、端末110-oは、セッション開始メッセージとセッション確認メッセージの両方におけるセッションデータおよびパラメータに基づいて、中央サービス160-oとのデータセッション(たとえば、VoIP)を確立することができる。端末110-oおよび中央サービス160-oは、端末110-oのユーザと中央サービス160-oのオペレータとの間で(音声および/または他のメディアデータを搬送する)呼を実施するためにリアルタイムトランスポートプロトコル(RTP)または別のストリーミングプロトコルを使用して、音声および/または他のメディアデータを含むパケットのストリームを交換することができる。データセッションは、テキスト、メッセージ単位のテキスト(インスタントメッセージングなど)と文字単位のテキスト(リアルタイムテキストと呼ばれることの多い、ストリーミングテキスト)の両方、および/またはビデオを含む任意のメディアを搬送することができる。たいていのメディアはストリームされるが、VoIPセッションは、ストリームされないメディアをストリームされるメディアの追加または代替として搬送することもできることに留意されたい。
中央サービス160-oと端末110-oとの間でデータセッションが確立されている間はいつでも、中央サービス160-oによって端末110-oに追加要求が提供され得る。ただし、中央サービス160-oは端末110-oに関連する受信された能力のセットを記憶することができるので、図30に示すセッションで能力のセットが再び送信される必要はない場合があることが諒解されよう。しかしながら、データセッションが終了し、新しいセッションが再確立されると、端末110-oは、中央サービス160-oに能力のセットを再び送ることができる。他の実施形態では、端末110-oは、同じデータセッションまたは異なるデータセッションの間に中央サービス160-oに更新された能力のセット(セット全体または能力の変更部分のセットのみのいずれか)を送ることができる。
図30に戻ると、VoIPセッションを終わらせるために、中央サービス160-oは、通信セッションシグナリングプロトコルにより端末110-oにセッション終了シグナリングメッセージを送信することができる。端末110-oは、セッション終了シグナリングメッセージを受信すると、中央サービス160-oにセッション終了確認シグナリングメッセージを送信することができ、セッションは終了し得る。
図31は、テレマティクスデータ、能力、およびテレマティクスメタデータ(要求を含む)を交換するために通信セッションシグナリングプロトコルを使用する端末110-pと中央サービス160-pとの間の通信交換3100の一例の図である。端末110-pは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-pは、図1Aの中央サービス(たとえば、PSAP)160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。
図31に示す通信交換3100は、図30に示す通信交換3000に似ており、異なる点として、図31では、セッション開始メッセージ、テレマティクスデータ、およびテレマティクス能力を受信したことに応答して、中央サービス160-pは、随意に何らかのテレマティクスメタデータ(たとえば、安全関連アクションを実行すること、車両の搭乗者に有益なメッセージを表示することなどを求める要求)とともに、ビジーメッセージにより応答する。後のある時点、たとえば、オペレータが緊急呼に対して支援可能であるとき、中央サービスは、随意に追加のテレマティクスメタデータとともに、端末110-pに招待メッセージを送信する。端末110-pは、セッション確認応答メッセージを送信することによって応答することができるが、少なくともいくつかの実施形態では、テレマティクス能力データは初期セッション開始メッセージとともにすでに送られて中央サービスによって受信されているので、テレマティクス能力データを再送する必要はないことがある。他の実施形態では、端末110-pはそれでも、中央サービス160-pに能力を再送信することができる。いくつかの状況では、中央サービスは、中央サービスがビジーメッセージにより応答したときから中央サービスが招待メッセージを送信するときの間に、端末に(セッションに関連しない)中間メッセージを送ることができる。
図32は、テレマティクスデータ、能力、およびテレマティクスメタデータ(要求を含む)を交換するために通信セッションシグナリングプロトコルを使用する端末110-qと中央サービス160-qとの間の通信交換3200の一例の図である。端末110-qは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-qは、図1Aの中央サービス(たとえば、PSAP)160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。
図32に示す通信交換3200は、図30および図31に示す通信交換3000、3100に似ており、異なる点として、図32では、テレマティクス能力のセットは、初期セッション開始メッセージおよびテレマティクスデータとともに中央サービス160-qに送信されることはなく、代わりに、端末の能力のセットの送信を求める端末向けの中央サービスからの要求に応答して、セッション確認応答メッセージとともに送られる。
図33は、テレマティクスデータ、能力、およびテレマティクスメタデータ(要求を含む)を交換するために通信セッションシグナリングプロトコルを使用する端末110-rと中央サービス160-rとの間の通信交換3300の一例の図である。端末110-rは、図1Aの端末110または以前の図を参照しながら上述した他の端末110のうちの1つの一例であってよい。中央サービス160-rは、図1Aの中央サービス(たとえば、PSAP)160または以前の図を参照しながら上述した他の中央サービス160のうちの1つの一例であってよい。
図33に示す通信交換3300は、中央サービス160-rが端末110-rに送ることができる要求および端末110-rが中央サービスに返送することができる応答のタイプのいくつかの例を示している。たとえば、中央サービス160-rから端末110-rに送られたテレマティクスメタデータが、あるテレマティクスデータの再送を求める要求を含む場合、端末110-rは、要求されたテレマティクスデータを中央サービス160-rに再送することによって応答することができる。他方では、中央サービス160-rから端末110-rに送られたテレマティクスメタデータが、追加のテレマティクスデータまたは異なるテレマティクスデータの送信を求める要求を含む場合、端末110-rは、要求された追加のテレマティクスデータまたは異なるテレマティクスデータを中央サービス160-rに送ることによって応答することができる。別の例として、中央サービス160-rから端末110-rに送られたテレマティクスデータが、物理的アクションの実施を求める要求を含む場合、端末110-rは、そのアクションを実施し、随意に、要求を受信したことの確認応答および/もしくはアクションが端末110-rによって実施されたことの確認を送ることによって、またはアクションを実施することが不可能な場合、アクションが端末110-rによって実施されなかったことの確認を送ることによって、応答することができる。
図34は、様々な実施形態による端末110-sの図を示している。端末110-sは、上述した端末110の1つまたは複数の態様の一例であってよい。図34に示す端末110-sは、アンテナ3430、トランシーバモジュール3425、プロセッサモジュール3405、およびメモリ3410(ソフトウェア3415を含む)を含み、それらはそれぞれ、(たとえば、1つまたは複数のバス3445を介して)互いに直接または間接的に通信し得る。
トランシーバモジュール3425は、アンテナ3430および/または1つもしくは複数のワイヤレス通信リンクを介して、(図1Aおよび図1Bを参照しながら上述したように、中央サービスへの接続を提供することができる)ネットワーク120と双方向通信するように構成され得る。トランシーバモジュール3425は、パケットを変調し、変調されたパケットを送信のためにアンテナ3430に提供し、かつアンテナ3430から受信されたパケットを復調するように構成されたモデムを含み得る。いくつかの実施形態では、端末110-sは単一のアンテナ3430を含み得るが、他の実施形態では、端末110-sは代替的に、複数のワイヤレス送信を同時に送信および/または受信することが可能な複数のアンテナ3430を含み得る。したがって、端末110-sは、1つまたは複数のネットワーク120エンティティと同時に通信することが可能であり得る。
メモリ3410は、ランダムアクセスメモリ(RAM)および/または読取り専用メモリ(ROM)を含み得る。メモリ3410は、実行されると、本明細書で説明する様々な機能(たとえば、能力のセットを送信すること、アクションの実施を求める要求を受信することなど)をプロセッサモジュール3405に実施させるように構成された命令を含むコンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード3415を記憶することができる。代替として、ソフトウェア/ファームウェアコード3415は、プロセッサモジュール3405によって直接実行可能ではなくてもよいが、(たとえば、コンパイルされ実行されると)本明細書で説明した機能をコンピュータに実施させるように構成されてもよい。プロセッサモジュール3405は、インテリジェントハードウェアデバイス、たとえば、中央処理装置(CPU)、マイクロコントローラ、特定用途向け集積回路(ASIC)などを含み得、ランダムアクセスメモリ(RAM)および読取り専用メモリ(ROM)を含み得る。
図34における端末110-sは、上述したテレマティクスデータシグナリングモジュール2210の一例であってよいテレマティクスデータシグナリングモジュール2210-cも含む。テレマティクスデータシグナリングモジュール2210-cは、同じく上述した能力モジュール2320の一例であってよい能力モジュール2320-bを含む。
図35は、様々な実施形態による中央サービス(たとえば、PSAP)160-sの図を示している。中央サービス160-sは、上述した中央サービス160の1つまたは複数の態様の一例であってよい。図35に示す中央サービス160-sは、ネットワークインターフェースコントローラ(NIC)3505、プロセッサモジュール3505、およびメモリ3510(ソフトウェア3515を含む)を含み、それらはそれぞれ、(たとえば、1つまたは複数のバス3545を介して)互いに直接または間接的に通信し得る。
NIC3505は、(図1Aおよび図1Bを参照しながら上述したように、1つまたは複数の端末への接続を提供することができる)ネットワーク120と双方向通信するように構成され得る。メモリ3510は、ランダムアクセスメモリ(RAM)および/または読取り専用メモリ(ROM)を含み得る。メモリ3510は、実行されると、本明細書で説明する様々な機能(たとえば、能力のセットを受信すること、アクションの実施を求める要求を送信することなど)をプロセッサモジュール3505に実施させるように構成された命令を含むコンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード3515を記憶することができる。代替として、ソフトウェア/ファームウェアコード3515は、プロセッサモジュール3505によって直接実行可能ではなくてもよいが、(たとえば、コンパイルされ実行されると)本明細書で説明した機能をコンピュータに実施させるように構成されてもよい。プロセッサモジュール3505は、インテリジェントハードウェアデバイス、たとえば、中央処理装置(CPU)、マイクロコントローラ、特定用途向け集積回路(ASIC)などを含み得、ランダムアクセスメモリ(RAM)および読取り専用メモリ(ROM)を含み得る。
NIC3505は、(図1Aおよび図1Bを参照しながら上述したように、1つまたは複数の端末への接続を提供することができる)ネットワーク120と双方向通信するように構成され得る。メモリ3510は、ランダムアクセスメモリ(RAM)および/または読取り専用メモリ(ROM)を含み得る。メモリ3510は、実行されると、本明細書で説明する様々な機能(たとえば、能力のセットを受信すること、アクションの実施を求める要求を送信することなど)をプロセッサモジュール3505に実施させるように構成された命令を含むコンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード3515を記憶することができる。代替として、ソフトウェア/ファームウェアコード3515は、プロセッサモジュール3505によって直接実行可能ではなくてもよいが、(たとえば、コンパイルされ実行されると)本明細書で説明した機能をコンピュータに実施させるように構成されてもよい。プロセッサモジュール3505は、インテリジェントハードウェアデバイス、たとえば、中央処理装置(CPU)、マイクロコントローラ、特定用途向け集積回路(ASIC)などを含み得、ランダムアクセスメモリ(RAM)および読取り専用メモリ(ROM)を含み得る。
図35における中央サービス160-sは、上述したテレマティクスメタデータシグナリングモジュール2610の一例であってよいテレマティクスメタデータシグナリングモジュール2610-cも含む。テレマティクスメタデータシグナリングモジュール2610-cは、同じく上述した要求サブモジュール2810の一例であってよい要求サブモジュール2810-aを含む。
図36は、本開示の様々な態様による、車両緊急呼システムにおけるテレマティクス能力のサポートをアサートするための方法3600の一例を示すフローチャートである。明快にするために、上述した端末110のうちの1つまたは複数の態様を参照しながら方法3600について以下で説明する。いくつかの例では、端末110は、コードの1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。追加または代替として、端末110は、専用ハードウェアを使用して、以下で説明する機能のうちの1つまたは複数を実施することができる。
ブロック3605では、方法3600は、通信セッションシグナリングプロトコルにより第1のエンドポイント(たとえば、緊急呼IVS)から第2のエンドポイント(たとえば、緊急呼応答機関)に能力のセットを送信するステップを含むことができる。一実施形態では、能力のセットは、端末(たとえば、緊急呼IVS)が実施することができる1つまたは複数のアクションを含むことができ、通信セッションシグナリングプロトコルは、上述したようにSIPであってよい。ブロック3610では、方法3600は、アクションの実施を求める要求、たとえば、アクションの実施を求める緊急呼応答機関からの要求を受信するステップを含むことができる。ブロック3615では、方法3600は、要求されたアクションを実施するステップを含むことができる。ブロック3605〜3615における動作は、上述したテレマティクスデータシグナリングモジュール2210によって実行され得る。
方法3600は一実装形態にすぎず、方法3600の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
図37は、本開示の様々な態様による、車両緊急呼システムにおけるテレマティクス能力のサポートをアサートするための方法3700の一例を示すフローチャートである。明快にするために、上述した端末110のうちの1つまたは複数の態様を参照しながら方法3700について以下で説明する。いくつかの例では、端末110は、コードの1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。追加または代替として、端末110は、専用ハードウェアを使用して、以下で説明する機能のうちの1つまたは複数を実施することができる。
ブロック3705では、方法3700は、アクションの実施を求める要求を端末の緊急呼IVSが受け入れる要求データ構造に対応する能力データ構造において能力のセットをフォーマットするステップを含むことができる。ブロック3710では、方法3700は、緊急呼応答機関などの中央サービスに能力データ構造を送信するステップを含むことができる。ブロック3705〜3710における動作は、上述したテレマティクスデータシグナリングモジュール2210によって実行され得る。
方法3700は一実装形態にすぎず、方法3700の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
図38は、本開示の様々な態様による、テレマティクス能力がアサートされると受信し、行動するための方法3800の一例を示すフローチャートである。明快にするために、上述した中央サービス160のうちの1つまたは複数の態様を参照しながら方法3800について以下で説明する。いくつかの例では、中央サービス160は、コードの1つまたは複数のセットを実行して、以下で説明する機能を実施することができる。追加または代替として、中央サービス160は、専用ハードウェアを使用して、以下で説明する機能のうちの1つまたは複数を実施することができる。
ブロック3805では、方法3800は、通信セッションシグナリングプロトコルにより第2のエンドポイント(たとえば、緊急呼応答機関)において、第1のエンドポイント(たとえば、緊急呼IVS)から能力のセットを受信するステップを含むことができる。一実施形態では、能力のセットは、端末(たとえば、緊急呼IVS)が実施することができる1つまたは複数のアクションを含むことができ、通信セッションシグナリングプロトコルは、上述したようにSIPであってよい。ブロック3810では、方法3800は、アクションの実施を求める要求、たとえば、アクションの実施を求める緊急呼応答機関からの要求を送信するステップを含むことができる。ブロック3805〜3810における動作は、上述したテレマティクスメタデータシグナリングモジュール2610によって実行され得る。
方法3800は一実装形態にすぎず、方法3800の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
いくつかの例では、方法3600、3700、3800のうちの2つ以上からの態様が、組み合わされてよい。方法3600、3700、および3800は例示的な実装形態にすぎず、方法3600、3700、および3800の動作は、他の実装形態が可能であるように並べ替えられ、または場合によっては変更され得ることに留意されたい。
いくつかの実施形態では、(クラッシュもしくは他の重大な出来事の場合に自動的に、または車両の搭乗者によって手動で呼び出された)車両によって発せられた緊急呼をサポートするために、またクラッシュまたは出来事に関係する車両、センサ、およびロケーションデータを伝達するために、IPベースの緊急サービス機構が使用され得る。そのような呼は、手動でトリガされる場合でも、「自動衝突通知」(ACN:Automatic Crash Notification)または「先進自動衝突通知」(AACN:Advanced Automatic Crash Notification)と呼ばれ得る。「先進」という修飾語は、より豊富なデータセットを搬送する能力を指し得る。
また、(必ずしもクラッシュがあるとは限らないとしても、「クラッシュデータ」と呼ばれ得る)車両、センサ、およびロケーションデータに関してMIMEコンテンツタイプおよび緊急呼追加データブロックが登録され得る。データフォーマット、内容、および構造に関する外部仕様の一例についても以下で説明する。
本開示では、以下の略語が使用され得る。3GPP:3rd Generation Partnership Project、AACN:先進自動衝突通知、ACN:自動衝突通知、APCO:Association of Public-Safety Communications Officials、EENA:European Emergency Number Association、ESInet:緊急サービスIPネットワーク、GNSS:全地球航法衛星システム(全地球測位システムすなわちGPSを含む様々なそのようなシステムを含む)、IVS:車載システム、MNO:モバイルネットワークオペレータ、NENA:National Emergency Number Association、TSP:テレマティクスサービスプロバイダ、VEDS:車両緊急データセット
(たとえば、クラッシュの場合に)車載システムによって行われた緊急呼は、緊急サービスが迅速に、また多くの場合により良いロケーションで応答できるようにすることによって、道路での死亡および負傷を大幅に低減するのを支援することができる。
車両の搭乗者は、自分がどこにいるかを知らないことがあり、または大まかなロケーションのみを知っていることがあり、または自分のロケーションを表現もしくは伝達することが可能ではないことがある。これは特に、夜間、主要都市にいないとき、はっきり示された道路標識がそのエリアにないとき、または見慣れないエリアにいるときに当てはまる。車両のクラッシュ、火災、または他の出来事によっては、搭乗者は、負傷している、動けない、または自分のセルフォンに届かないので緊急呼を開始することが可能ではないことがある。観測者がいないエリアにおいて車両のクラッシュまたは出来事が発生することがあり、場合によっては、観測者がたまたま近くにいるようになるまでに長い時間期間があり得る。
一部の車両は、機能の中でも、クラッシュの場合に自動的に、または緊急呼ボタンに応答して手動で緊急呼を発するテレマティクスシステムを備え得る。そのようなシステムは、車両に関する位置情報を提供するために、衛星ベースの測位技術、セルラーベースの測位技術、慣性センサ、ジャイロスコープなどを利用する搭載ロケーション判断システムを有し得る。そのような内蔵システムは、より確実なパワー、より大きいまたは特殊なアンテナを有する能力、車両ガラスコーティングによる劣化、他の車両システムからの干渉などを回避または最小化するように工作される能力のような、車両に統合されていることの恩恵を利用することができる。これらの利点は、統合されたシステムが、そのロケーションをより確実に、より正確に、またはより迅速に推定または判断すること、およびセルラー通信呼をより確実に確立し維持することを可能にし得る。したがって、PSAPは、緊急時に車両がある場所の良好な推定値を提供され得る。安全性の恩恵と対応可能な追加の機能およびサービス(たとえば、リモートエンジン診断、リモートドアロック解除、盗まれた車両の追跡および無効化など)の両方のために、そのようなシステムを採用する車両メーカーが増えている。
そのようなシステムの一般的な用語は、「自動衝突通知」(ACN)または「先進自動衝突通知」(AACN)である。「ACN」は、一般的な用語として本明細書で使用される。ACNシステムは、一般に「クラッシュデータ」(この用語は、クラッシュがなかった場合でも一般に使用される)と呼ばれる、出来事に固有のある量のデータを送信することができる。異なるシステムは異なる量のクラッシュデータを送信するが、システムおよびPSAPの間の相互運用性を実現するために、標準化されたフォーマット、構造、および機構が必要とされ得る。
一部の車載テレマティクスシステムは、(一般に、PSAP電話対応オペレータに何らかのクラッシュデータを口頭で提供するための人間電話対応オペレータまたは自動システムのいずれか、あるいは場合によっては専有機構に依存している)PSAPにクラッシュデータを直接伝達する標準ベースの能力を欠いていることがある。PSAP電話対応オペレータは、最初に、呼が車両出来事に関係することを理解する必要があり得、たいていの場合、次いでデータを聞き、転写し得る。そのようなシステムは、PSAP電話対応オペレータが、クラッシュまたは他のデータを同時に受信すること、および車両の搭乗者と通信し、または車両からの音を聞くことを可能にしないことがある。
一般に次世代呼、特に緊急呼への移行は、クラッシュデータを呼とともに提示すること、およびPSAPによって自動的に処理し、統合的、自動的に電話対応オペレータに提供することを可能にすることによって、緊急時のクラッシュデータの範囲、広さ、信頼性、および有用性を改善する機会を提供する。そのようなシステムは、クラッシュおよびロケーションデータを、呼が割り当てられるかまたは応じられるときにPSAP電話対応オペレータに提示することを可能にし、それにより相当な時間を節約し、車両の搭乗者との即時の通信を可能にし得る。さらに、車両メーカーは、(ロケーションベースサービス、マルチメディアエンターテインメントシステム、および道路沿いの支援アプリケーションを含む、緊急使用と非緊急使用の両方のための車両とサービスセンターとの間の遠隔測定など)望む場合に内部使用目的でデータ送信するために同じ標準化された機構を利用する機会を提供される。
次世代ACNは、そのような呼を呼セットアップ中にそのようなものとして認識し処理する機会を提供し、そのような呼は、次いで、データを処理することが可能なPSAPにルーティングされ得、その場合に車両データは、電話対応オペレータが状況を判断し状況に応答するのを支援するために利用可能である。
ACN呼は、搭乗者によって開始されるか、自動的にトリガされるかのいずれかであり得る。(「ACN」の「A」は、「Automatic」を表すが、この用語は、車載システム(IVS)によって発せられた、出来事関連データならびに音声を搬送する呼のクラスを指すために使用され得る。)自動的にトリガされた呼は、車のクラッシュまたは何らかの他の重大な出来事(たとえば、転覆または火災)を示すことがあり、負傷のリスクのより大きい推定を伝え得る。手動でトリガされた呼は、(損傷したドライバまたは道路の破片など)重大な危険の報告であり得、状況に応じて異なる応答を必要とし得る。手動でトリガされた呼はまた、誤った(たとえば、偶発的な)呼である可能性がより高く、したがって、PSAPによる異なる処理の対象となり得る。
本明細書では、次世代ACNの実現を支援するための、IPベースの緊急呼のための機構について説明する。
Association of Public-Safety Communications Officials(APCO)およびNational Emergency Number Association(NENA)は、車両緊急データセット(VEDS)と呼ばれ得る出来事関連の車両データの標準化されたセットを共同で開発した。欧州標準化委員会(CEN)は、eCallの最小データセット(MSD)を定義した。そのようなデータは、クラッシュデータと呼ばれ得るが、クラッシュ以外の出来事でも当てはまる。
VEDSおよびeCall MSDは、車両関連データの送信、交換、および解釈のための標準データセットを提供することができる。標準データフォーマットは、データをIVSによって生成し、PSAP、緊急応答者、および医療施設(外傷レベルの患者ケアを行うことが可能な施設を含む)によって解釈することを可能にし得る。標準データフォーマットは、エアバッグ展開、車両のロケーション、車両が転覆事故に巻き込まれたかどうか、クラッシュの潜在的な深刻度および車両の搭乗者の深刻な負傷の可能性を示すことができる様々なセンサデータなどのような出来事関連情報を含むことができる。このデータは、PSAPおよび緊急応答者に、必要とされ得る応答のタイプについてより良好に知らせることができる。そのような情報は、負傷した患者の現場トリアージに関する連邦ガイドラインに最近含められた。これらのガイドラインは、事故現場にいる応答者が、深刻な体内損傷の存在の可能性を識別し、患者をどのように、またどこに移送する必要があるかについての重要な決定を下すのを助けるように設計されている。
以下の説明では、'application/EmergencyCallData.VEDS+xml'MIMEコンテンツ-タイプについて述べ、緊急呼追加データレジストリにおける'VEDS'エントリについて述べる。
VEDSはXML構造であり得る。'application/EmergencyCallData.VEDS+xml'MIMEコンテンツ-タイプは、それを識別するために使用され得る。緊急呼追加データレジストリにおける'VEDS'エントリは、SIPセッションまたはセッションセットアップ内で呼-情報ヘッダフィールドにおいてVEDSデータを伝達するための'purpose'パラメータ値を構成するために使用され得る。
VEDSは、異なるニーズを受け入れることができる多目的構造であってよい。ただし、追加のデータセットが必要とされると判断された場合、追加のデータブロックを有効にするためのいくつかの例示的なステップについて、以下でごく簡単に要約する。
標準化されたフォーマットおよび符号化(XMLなど)が標準化機関(SDO:Standards Development Organization)によって定義され発表され得る。
MIMEコンテンツ-タイプが、それのために(通常は'Application'メディアタイプの下で、かつ'EmergencyCallData.'で始まるサブタイプを伴って)登録され得る。
ブロックのエントリが緊急呼追加データブロックサブレジストリに追加されてよく、レジストリエントリは、('EmergencyCallData'プレフィックスおよび'+xml'などのあらゆるサフィックスを含まない)MIMEサブタイプのルートであってよい。
次世代車載システム(IVS)は、標準化された登録済みフォーマット(VEDSまたは上述した追加のブロックなど)でクラッシュデータを符号化し、MIME本文部分としてINVITEまたは他のメッセージにクラッシュデータを添付することによってクラッシュデータを送信することができる。本文部分は、本文部分のコンテンツ-タイプヘッダフィールドにおけるそのMIMEコンテンツ-タイプ('application/EmergencyCallData.VEDS+xml'など)によって識別され得る。本文部分は、本文部分におけるコンテンツ-IDヘッダフィールドに記載され得る一意の識別子を割り当てられ得る。INVITEまたは他のメッセージは、INVITEまたは他のメッセージのトップレベルにおける呼-情報ヘッダフィールドを追加する(または呼-情報ヘッダフィールドに付加する)ことによって、クラッシュデータを含むものとして示され得る。呼-情報ヘッダフィールドは、本文部分の一意の識別子を参照するCID URL、およびレジストリエントリごとにクラッシュデータとしてデータを識別する'purpose'パラメータを含むことができ、'purpose'パラメータの値は、EmergencyCallData'および('EmergencyCallData'プレフィックスおよび'+xml'などのあらゆるサフィックスを含まない)MIMEタイプのルート(たとえば、'purpose=EmergencyCallData.VEDS')であってよい。
本明細書で説明する機構は、ACN呼として識別可能であり、相互運用可能な方法で1つまたは複数の標準化されたクラッシュデータオブジェクトを搬送する緊急呼を発するために使用され得る。
自動クラッシュ通知システムを含む、車載システムによって緊急呼を発するための現在の(回線交換またはレガシー)システムは、ロケーションおよび場合によってはテレマティクスデータをPSAPに伝達する限定的能力を有し得る。たいていのそのようなシステムは、「テレマティクスサービスプロバイダ」(TSP)、「直接」、および「ペアリングされたハンドセット」として本明細書で説明する、3つのアーキテクチャモデルのうちの1つを使用する。これらの3つのモデルについて以下に示す。
TSPモデル(図39に示す図3900参照)では、緊急呼と非緊急呼の両方がテレマティクスサービスプロバイダ(TSP)3910に対して発せられてよく、専有技術がTSP3910へのデータ転送(専有帯域内モデムなど)に使用されてよい。
緊急時には、TSP電話対応オペレータがPSAP3915との橋渡しをし、ロケーション、クラッシュデータ(衝撃度、外傷の予測など)、および他のデータ(車両の説明など)をPSAP電話対応オペレータに口頭で伝えることができ、またはセルラー緊急呼の場合と同様の機能を使用してロケーションデータを送信し、クラッシュおよび他のデータを口頭で伝えることができる。通常、車両IVS3905、TSP3910、およびPSAP3915の間で3方向音声呼が確立され、PSAP電話対応オペレータ、TSP電話対応オペレータ、および車両の搭乗者(気付かない可能性がある)の間での通信が可能になり得る。
ペアリングされたモデル(図40に示す図4000参照)では、IVS4005は、以前ペアリングされたハンドセット4010とのBluetooth（登録商標）リンクを使用して、(たとえば、9-1-1などの標準的な緊急電話番号をダイヤルすることによって)PSAP4015との緊急呼を確立し、次いでテキスト読み上げによりPSAP4015にロケーションデータを通信することができ、クラッシュデータは伝達されなくてよい。一部のそのようなシステムは、自動音声プロンプトメニュー(たとえば、「これは車両からの自動緊急呼です。車両への音声経路を開くには1を押してください、ロケーション読出しを聞くには2を押してください」)を使用して、電話対応オペレータがテキスト読み上げによるロケーションデータを要求できるようにし得る。
直接モデル(図41に示す図4100参照)では、IVS4105は、9-1-1などの標準的な緊急電話番号をダイヤルすることによってPSAP4110との緊急呼を直接発することができる。そのようなシステムは、テキスト読み上げによりPSAP4110にロケーションデータを通信することができ、クラッシュデータは伝達されなくてよい。
本開示は、PSAPへの例示的なインターフェース、すなわち、どのようにACN緊急呼がセットアップされ得、出来事関連データ(車両、センサ、およびロケーションデータを含む)がPSAPに送信され得るかについて説明する。(たとえば、仕様を再使用するため。)直接モデルの場合、これは(車両とPSAPとの間の)エンドツーエンドの説明であり得る。TSPモデルの場合、これは、(TSPとPSAPとの間の)右側について説明し、(車両とTSPとの間の)左側は、関与するエンティティ(すなわち、IVSおよびTSPベンダー)に任せられてよく、その場合に、関与するエンティティは、右側の場合と同じ機構を使用してよい(または使用しなくてもよい)。
米国および他の地域でのACNシステムは現在義務化されていないが、欧州は、車載システムによる緊急呼のための義務化および標準化されたシステムを有することに留意されたい。この汎欧州システムは「eCall」として知られている。複数の地域で動作するように設計された車両は、eCallならびに他のACNシステムをサポートすることができる。他の地域がそれら自体の仕様またはデータフォーマットを考案した場合、複数地域型車両が同様にそれらをサポートすることができる。eCallと一般化されたACN機構の両方は、多くの点で互換性があり得るが、Request-URI、送られる特定のデータブロック、または他の点で相違し得る。他の相違点は、たとえば、PSAPによる、データの送信もしくは他のアクションの実行を求める要求、または送られたデータのPSAPによる確認応答の処理を求める要求、または車両が能力を表すことを求める要求などに対するサポートの量を含み得る。
次世代(オールIP)技術への車載システムによって発せられた緊急呼の移行は、そのような呼を識別するための、また呼とともにクラッシュデータを提示するための標準化された機構を提供することができる。これは、ACN呼およびクラッシュデータをPSAPによって自動的に処理し、統合的、自動的に電話対応オペレータに提供することを可能にし得る。
TSPモデルを使用する車両メーカーは、緊急呼と非緊急呼の両方のために車両とTSPとの間でテレマティクスデータを搬送するための同じ機構を利用することを選び得る。
次世代IVSは、車両データが添付されたACNタイプの緊急呼を示すRequest-URIとともに3GPP IMSソリューションを使用して緊急呼を確立することができ、MNOは、呼を緊急呼として認識し、それをESInetにルーティングすることができ、ESInetは、車両データを伴うACNとして呼を認識することができ、呼をNG-ACN対応可能PSAPにルーティングすることができ、当該PSAPは、呼とともに送られた車両データを解釈し、それを電話対応オペレータに提供することができる。ESInetを有しない地域では、MNOは、呼をACN対応可能PSAPにルーティングすることができる。ESInetを有する地域では、ESInetは、そのような呼を、他の緊急呼とは異なる形でルーティングすることができる。
(上記で述べたように)次世代ACN呼を識別し、特別に処理する必要性から、新しいサービスURN子が「sos」サブサービス内に登録され得る。これらのURNは、NG-ACN呼が識別される機構を提供することができ、(ポリシーに応じて異なる処置の対象となり得る)手動でトリガされたNG-ACN呼と自動的にトリガされたNG-ACN呼との間で区別することができる。そのようなサービスURNの例は、'urn:service:sos.vehicle.automatic'、'urn:service:sos.vehicle.manual'、'urn:service:sos.eCall.automatic'、および'urn:service:sos.eCall.manual'であり得る。
北米では、ESInetの外のクライアントによって実施されたルーティングクエリは、サブサービスを伴わない「sos」と同等に「sos」のすべてのサブサービスを扱うことができる。しかしながら、Request-URIヘッダフィールドは、サブサービスすべてを保持することができ、ESInetまたはPSAP内でのルートおよび処理決定は、サブサービスを考慮に入れることができる。たとえば、複数の協力するPSAPを有する地域では、NG-ACN対応可能であるPSAP、または車両関連出来事を専門とするPSAPにNG-ACN呼がルーティングされ得る。
本開示は、どのように3つのアーキテクチャモデルが次世代(オールIP)に移行され得るかについて論じる。
本開示は、どのように3つのアーキテクチャモデルが次世代(オールIP)に移行され得るかについて論じる。
TSPモデル(図42に示す図4200参照)では、IVS4205は、専有設計に基づくプロトコルまたはIETFなどの業界仕様もしくは他の仕様を再使用するプロトコルのいずれかを使用して、TSP4210にクラッシュおよびロケーションデータを送信することができる。緊急時には、TSP電話対応オペレータがPSAP4215との橋渡しをし、(たとえば、IETF仕様を使用して)PSAP4215にクラッシュおよび他のデータを送信することができる。車両IVS4205、TSP4210、およびPSAP4215の間で3方向呼があり、PSAP電話対応オペレータ、TSP電話対応オペレータ、および車両の搭乗者(気付かない可能性がある)の間での通信が可能になり得る。
車両メーカーおよびTSPは、車両からTSPにクラッシュおよびロケーションデータを送信するために、TSPからPSAPにそのようなデータを送信するための本明細書で説明するものと同じ仕様(たとえば、IETF)を使用することを選ぶことができる。
ペアリングされたモデル(図43に示す図4300参照)では、IVS4305は、以前ペアリングされたハンドセット4310へのBluetooth（登録商標）リンクを使用して、PSAP4315との緊急呼を確立することができ、ハンドセットにロケーション、クラッシュ、または他のデータを伝達することができ、次いでハンドセットは、本明細書で説明するように、PSAPにそのようなデータを送信することができる。
直接モデル(図44に示す図4400参照)では、IVS4405は、たとえば、IETF仕様を使用して直接、PSAP4410にクラッシュデータを通信することができる。
車載システムによって発せられた緊急呼のコンテキストでは、車は、内蔵GNSS受信機を備えることができる。さらに、車両は、性質上移動するものであり、固定アドレスに結び付けられない。これらの理由により、緊急呼内で送られ得るロケーション情報は、測地のみであってよい。以下のロケーション形状が実装され得る。2-Dおよび3-D点、円、および楕円。基準座標系(CRS)も使用され得る。車両の移動方向を示し得る<direction>要素は、送り出しに有益であり得、したがって、それは含まれ得る。<heading>要素は、実装され得、含まれ得る。
車載システムによる呼がセルラーネットワークを介して発せられ得、セルラーネットワークは、発信デバイスによって緊急呼INVITEにおいて送られたロケーションを無視し、代わりに(多くの場合、発信デバイスと協調して判断された)それら自体のロケーションを添付することがある。IVSは、呼INVITEにロケーションデータを添付することができる。標準化されたクラッシュデータ構造は、車両によって判断されたロケーションを含むことができる。これにより、セルラーネットワークによって(多くの場合、IVSと協調して)判断されたロケーションと車両によって判断されたロケーションの両方をPASPが確認できるようになり得る。
本開示は、テスト呼機能を利用することが可能であり得る。そのようなテスト呼は、いくつかの点、すべての点、または大半の点において実際の緊急呼と同一であるが、実際の緊急呼から区別可能であり得る。
ACN呼は、呼処理のすべての段階でそのようなものとして容易に識別可能であり得、自動トリガか手動トリガかは知られ得る。ACN呼は、標準化されたクラッシュデータの存在、(PSAP動作プロセスにとって意味合いを持ち得る)車載システムによって呼が発せられることが知られ得るという事実、および特に自動的呼の場合に、深刻な負傷の可能性、ひいては外傷対応サービスの必要性を示し得る情報を含む、いくつかの点で一般的な緊急呼とは異なる。呼がACNであり、さらに、それが自動的に呼び出されたか、手動で呼び出されたかを知っていることは、呼、状況、および車両の搭乗者に関する一連の意味合いを伴い得る。車載システムによる呼は、一般的な緊急呼の特定のサブクラスと見なされ得、そのような呼に対応する技術的能力および運用能力を有するPSAPによって処理される必要があり得る。(これは特に、米国などの環境に当てはまり、そのような環境では、多くのPSAPがあり、個々のPSAPは、一連の能力を有し、PSAPは、サービス提供において互いに協力することができる。)技術的能力は、標準化されたクラッシュデータを認識し、処理する能力を含むことができる。運用能力は、深刻な負傷の可能性を判断し、適切に応答する(たとえば、外傷対応医療応答者、またはクラッシュした車両から搭乗者を救出し、ガソリンもしくは他の危険物を扱うようにトレーニングされ準備できた応答者を送り出すこと、犠牲者を外傷対応センターに移送すること、受け取り側施設に注意を出すこと、など)ためのトレーニングおよびプロセスを含むことができる。
ACN呼は一般的な緊急呼とはかなり異なり得るので、またそのような呼は(技術的に、クラッシュデータを解釈および利用するように、また随意に、車両システムによって発せられた緊急呼を処理するように準備できた)専門のPSAPによって処理される必要があり得るので、本開示は、「SOS車両」など、ACN/車クラッシュに対するSOSサブサービスについて説明する。サブサービスを使用することは、呼がACNであることを示すことができ、クラッシュまたは他の重大な出来事(火災など)に起因して自動的に発せられた呼を、車両の搭乗者によって手動で呼び出された呼から区別するための(たとえば、「SOS.vehicle.automatic」および「SOS.vehicle.manual」)さらなる子要素について、本明細書で論じる。自動呼出しと手動呼出しとの間の区別についても論じ、自動的にトリガされた呼は、車クラッシュまたは何らかの他の重大な出来事(火災など)を示すことができ、したがって、負傷のリスクのより大きい推定、ひいては(外傷または火災など)特定の応答者の必要性を伝え得る。手動でトリガされた呼は、(損傷したドライバまたは道路の破片など)重大な危険の報告であり得、状況に応じて異なる応答を必要とし得る。手動でトリガされた呼はまた、誤った(たとえば、偶発的な)呼である可能性がより高いことがあり、したがって、PSAPによる異なる処理の対象となり得る。
次世代車載システム(IVS)は、標準化された登録済みフォーマットにおいてクラッシュデータを符号化し、追加データブロックとしてINVITEまたは他のメッセージにクラッシュデータを添付することによってクラッシュデータを送信することができる。ブロックは、そのMIMEコンテンツ-タイプによって識別され、ブロックに対応する'purpose'パラメータ値を有する呼-情報ヘッダにおけるCID URLによって指し示され得る。
これを実装するためのステップは、以下を含み得る。クラッシュデータのセットがSDOまたは適切な組織によって標準化され得、クラッシュデータセットに関するMIMEコンテンツ-タイプが、IANAなどの適切なレジストラに登録され得る。データが特に緊急呼で使用するためのものである場合、MIMEタイプは、'application'または'EmergencyCallData.'で始まるサブタイプを有する他のタイプの下にあり得る。データフォーマットがXMLである場合、名前は、'+xml'のサフィックスを有し得る。その項目は、緊急呼追加データレジストリに登録され得る。緊急-呼-固有フォーマットの場合、登録済み名前は、('EmergencyCallData'プレフィックスおよび'+xml'などのあらゆるサフィックスを含まない)MIMEコンテンツ-タイプのルートであってよい。
緊急呼を発するとき、クラッシュデータセットが作成され符号化され得る。本文部分のコンテンツ-タイプヘッダフィールドにおけるそのMIMEコンテンツ-タイプによって識別されたMIME本文部分として、緊急呼INVITEまたは他のメッセージにクラッシュデータセットが添付され得る。本文部分は、本文部分のコンテンツ-IDヘッダフィールドにおける一意の識別子ラベルを割り当てられ得る。INVITEまたは他のメッセージのトップレベルにおける呼-情報ヘッダフィールドは、クラッシュデータを参照し、(緊急呼追加データレジストリに登録される)そのMIMEルートによってそれを識別することができる。クラッシュデータは呼-情報ヘッダフィールドにおいて、クラッシュデータ本文部分に割り当てられた一意のコンテンツ-IDを含むCID URLによって参照され得る。クラッシュデータは呼-情報ヘッダフィールドにおいて、緊急呼追加データレジストリにおける特定のクラッシュデータエントリと連結された'EmergencyCallData.'を値とする'purpose'パラメータによって識別され得る。
呼-情報ヘッダフィールドは、単にクラッシュデータを参照するためのものである(したがって1つのURLのみを有する)か、または他のデータを参照する他のURLも含むかのいずれかであり得る。
同じステップに従うことによって、追加のクラッシュデータセットが含まれ得る。
車両緊急データセット(VEDS)は、Association of Public-Safety Communications Officials(APCO)およびNational Emergency Number Association(NENA)によって定義されたXML構造[VEDS]であり得る。'application/EmergencyCallData.VEDS+xml'MIMEコンテンツ-タイプは、それを識別するために使用され得る。緊急呼追加データレジストリにおける'VEDS'エントリは、呼-情報ヘッダにおいてVEDSデータを伝達するための'purpose'パラメータ値を構成するために使用され得る。欧州標準化委員会(CEN)は、XML表現を含むeCallの最小データセット(MSD)を定義した。'application/EmergencyCallData.eCall.MSD+xml'MIMEコンテンツ-タイプは、MSDを識別するために使用され得る。緊急呼追加データレジストリにおける「eCall.MSD」エントリは、呼-情報ヘッダにおいてeCall MSDデータを伝達するための'purpose'パラメータ値を構成するために使用され得る。
VEDSデータまたはMSDは、'EmergencyCallData.VEDS'または'EmergencyCallData.eCall.MSD'の'purpose'パラメータを有するタイプCIDの呼-情報URLによって参照され得るMIMEコンテンツタイプ'application/EmergencyCallData.VEDS+xml'または'application/EmergencyCallData.eCall.MSD+xml'を有する本文部分として添付され得る。
車両とPSAPとの間の経路に沿ったエンティティは、呼をACN呼として識別し、それを適切に処理することが可能であり得る。PSAPは、値が'EmergencyCallData.'で始まる'purpose'パラメータに関して呼-情報ヘッダフィールドを調べることによって、INVITEまたは他のメッセージに添付されたクラッシュデータならびに任意の他の追加データを識別することが可能であり得る。PSAPは、'purpose'パラメータ値をチェックすることによって、(たとえば、ポリシーまたは能力に基づいて)処理可能で関心があるデータにアクセスすることが可能であり得る。
緊急サービスIPネットワーク(ESInet)は、緊急サービス局によって、または緊急サービス局のために運営されるネットワークであり得る。ESInetは、緊急呼のルーティングおよびPSAPへの配信前の処理を扱うことができる。NENAによって採用されたNG9-1-1アーキテクチャならびにEENAによって採用されたNG1-1-2アーキテクチャでは、各PSAPは、1つまたは複数のESInetに接続され得る。各発信ネットワークも、1つまたは複数のESInetに接続され得る。ESInetは、緊急呼のルーティングおよび処理を制御することができるポリシーベースのルーティングルールを維持することができる。ESInet内のそのようなルールの集中化は、発信ネットワークの責任と緊急サービスネットワークの責任との間の分離の明確化をもたらし、緊急サービス局による緊急呼の処理に対する柔軟性および制御の向上をもたらすことができる。これは、緊急呼がルーティングまたは処理される方法の変更を必要とする異例の状況(たとえば、天災によるPSAPの閉鎖)に迅速に反応すること、ならびにそのようなルーティングに影響を与える長期的変更を行うこと(たとえば、翻訳もしくは中継サービスを必要とする呼を特別に処理するための、または車載システムによって発せられた次世代緊急呼を処理する地域内のいくつかのPSAPを指定するための協力的な措置)に徐々に慣れる(ease in)ことをより容易にし得る。
ESInetを使用する環境では、発信ネットワークは、緊急呼のサービスURNが「sos」であるか、または「sos」で始まることを検出し、すべてのタイプの緊急呼をESInetに渡す必要があるにすぎないことがある。その場合にESInetは、そのような呼を適切なPSAPにルーティングする責任を負い得る。ESInetを有しない環境では、緊急サービス局および発信キャリアは、そのような呼がどのようにルーティングされるかを判断する必要があり得る。
本明細書で説明する実施形態は、テスト呼機能を利用することが可能であり得る。
「test.」で始まるサービスURNは、自動テストを求める要求を示すことができる。たとえば、「urn:service:test.sos.vehicle.automatic」は、そのようなテスト機能を示すことができる。
親サービスURNとしての「test」および子としての「sos」を使用してテスト呼が発せられ得るので、そのような呼は、緊急呼として扱われなくてよく、そのため一部の機能は適用されなくてよい(サービスを欠く(「non-service-initialized」または「NSI」)デバイスが緊急呼に利用可能である場合の、そのようなデバイスのプリエンプションまたはサービスアベイラビリティなど)ことに留意されたい。MNOおよびPSAPは、テスト呼を認識し、必要なだけ多くの機能をテストする形でテスト呼を扱うことができる。たとえば、緊急ACN呼の場合と同じPSAPにテストACN呼がルーティングされてよく、IVSはPSAPにテレマティクスデータおよび/または能力データを送信することができ、PSAPはIVSに確認応答および/または要求を送信することができる。テスト呼は、車両の搭乗者とPSAPにおける自動機器との間の音声通信を可能にし得る。PSAPは、車両から送信されたオーディオを録音することができ、録音されたオーディオを車両に返送することができ、または車両からの録音されたオーディオの前、代わりに、もしくは後に他のオーディオを送信することができる。
図45は、ロケーション情報およびクラッシュデータ(VEDSデータなど)が両方ともSIP INVITEメッセージに添付され得る、車両4505によって発せられた緊急呼を示している。INVITEは、'urn:service:sos.vehicle.automatic'または他のサービスURNを含む要求URIを有することができ、したがって、ACNタイプの緊急呼として認識されてよく、要求URIが'urn:service:sos'で始まるので、1つのタイプの緊急呼として認識されてもよい。モバイルネットワークオペレータ(MNO)4510は、任意の緊急呼と同様に、緊急サービスIPネットワーク(ESInet)4515に呼をルーティングすることができる。ESInet4515は、ACNとして呼を処理し、(ロケーション情報と、それがACNであるという事実とを使用して)適切なACN対応可能PSAP4525に呼をルーティングすることができる。(ESInetがない展開では、MNO4510自体が、適切なACN対応可能PSAP4525に直接ルーティングする必要があり得る。)呼は、ESInet4515へのエントリポイントとして緊急サービスルーティングプロキシ(ESRP)4520によって処理され得る。ESRP4520は、適切なACN対応可能PSAP4525に呼をルーティングすることができ、そこで呼が電話対応オペレータによって受信され得る。
図46の図4600に示す例は、ロケーション情報(PIDF-LO)および(VEDSデータとしての)クラッシュデータとともに伝達されているSIP緊急呼INVITEを示している。
発信デバイスによってロケーション情報が提供される緊急サービスシステムと同様に、意図的に(たとえば、緊急サービスインフラストラクチャに対するサービス拒否攻撃の場合)または機能不全のデバイスに起因して、ロケーションが不正確である可能性がある。
本開示によれば、URN'urn:service:sos.vehicle'または'urn:service:sos.eCall'が、サブサービス'sos'レジストリの下で登録され得る。
このサービス識別子は、緊急応答機関(PSAP)に届くことがあり、その場合にPSAPは、車両の事故に関係する緊急性に適した支援を送り出すことができる。以下のサブサービスも登録され得る。
urn:service:sos.vehicle.manual - このサービスURNは、車両センサ(「クラッシュ」)データを搬送している緊急呼が、ドライバまたは乗客の手動対話に基づいて車載システム(IVS)によって発せられていることを示し得る。
urn:service:sos.vehicle.automatic - このサービスURNは、車両センサ(「クラッシュ」)データを搬送している緊急呼が、たとえばクラッシュに起因して自動的にトリガされた車載システム(IVS)によって発せられていることを示し得る。
eCallサービスのためのurn:service:sos.ecall.manualおよびurn:service:sos.ecall.automaticなど、様々なタイプのACN呼のためにさらなる同様のサブサービスも登録され得る。
また、本開示によれば、図47の図4700に示すように、新しいMIMEタイプが登録され得る。また、本開示によれば、緊急呼追加データレジストリに'VEDS'エントリが追加され得る。
本明細書で説明するいくつかの実施形態では、(一般に「eCall」と呼ばれる)欧州委員会のeSafetyイニシアチブの下で定義された次世代の汎欧州車載緊急呼サービスをサポートするために、IPベースの緊急サービス機構が使用され得る。eCallは、車両によって発せられる特別な形式の緊急呼のための標準化および義務化されたシステムである。eCall展開は、欧州連合加盟国において近い将来に必要とされ、eCall(およびeCall対応システム)は他の地域でも展開中である。eCallは、統合された音声経路と、車両、センサ(たとえば、クラッシュ関連)、およびロケーションデータの標準化されたセットとを提供する。eCallは、特殊な形式の緊急呼として認識され処理され得、車両データを処理することが可能な、車両からの緊急呼を処理するトレーニングを受けた専門的なeCall対応可能緊急応答機関(PSAP)にルーティングされ得る。
eCallは、いくつかの実施形態では回線交換セルラー電話を介して機能することができるが、次世代eCall(NG-eCall、これはパケット交換eCallまたはPS-eCallと呼ばれることがある)が使用されることもあり、本開示は、IPベースの緊急サービスインフラストラクチャ内のeCallをどのようにサポートするかの例示的な方法について説明することによって、その仕組みを支援することができる。MIMEコンテンツタイプおよび緊急呼追加データも登録され得る。
本開示では、以下の略語が使用され得る。3GPP:3rd Generation Partnership Project、CEN:欧州標準化委員会、EENA:European Emergency Number Association、ESInet:緊急サービスIPネットワーク、IMS:インターネットマルチメディアサブシステム、IVS:車載システム、MNO:モバイルネットワークオペレータ、MSD:最小データセット、PSAP:緊急応答機関。
本開示は、標準RFC6443およびRFC6881において説明されるような、緊急呼の枠組み内の次世代eCall(NG-eCall、これはパケット交換eCall(PS-eCall)およびオールIP eCallと呼ばれることもある)のシグナリング、データ交換、およびプロトコルニーズについて説明し得る。eCallは、3GPPおよびCENのこれらの仕様によって明示され得る。eCallサービスは、セルラーワイヤレス通信を介して行われるが、本開示は、セルラー固有の詳細についても、クライアントドメイン選択(たとえば、回線交換かパケット交換か)についても述べない。したがって、本開示の範囲は、3GPP IMS緊急呼などのSIPベースの環境内で行われるeCallについて説明することを含み得る。しかしながら、本明細書で説明する技法は、他の車両開始型緊急呼システムにも適している可能性があることを理解されたい。
複数の地域向けに設計された車両は、eCallおよび他の先進自動衝突通知システムをサポートし得る。そのようなシステムは、eCall対応であり得るが、Request-URLおよび送られる特定のデータセット、または他の点で異なることがある。
(たとえば、クラッシュの場合に)車両から行われた緊急呼は、緊急サービスが出来事、車両の状態、車両のロケーションを認識し、車両の搭乗者との音声チャネルを持つことを可能にすることによって、道路での死亡および負傷を低減するのを支援することができる。これは、迅速かつ適切な応答を可能にし得る。
欧州委員会によるeCallのイニシアチブは、1990年代後半に考えられ、新しい車両における準拠した車載システム(IVS)の実装および近い将来の欧州連合加盟国におけるeCallの展開を求める欧州議会の決定へと進化した。eCall(およびeCall対応システム)は、他の地域でも採用されつつある。
汎欧州eCallシステムは、車両による緊急呼のための標準化および義務化された機構を提供する。eCallは、そのような呼が車載システムによって発せられ、ネットワークによって認識および処理され、電話対応オペレータが状況を判断し状況に応答するのを支援するために車両データが提供され得る専門のPSAPにルーティングされるための手順を確立する。したがって、eCallは、車両、センサ(たとえば、クラッシュ関連)、およびロケーションデータの標準セットを提供することができる。
eCallは、ユーザによって開始されるか、自動的にトリガされるかのいずれかであり得る。自動的にトリガされたeCallは、車のクラッシュまたは何らかの他の重大な出来事(たとえば、火災)を示すことがあり、負傷のリスクのより大きい推定を伝え得る。手動でトリガされたeCallは、重大な危険の報告であり得、自動的にトリガされたeCallとは異なる応答を必要とし得る。手動でトリガされたeCallはまた、誤った(たとえば、偶発的な)呼である可能性がより高く、したがって、PSAPによる異なる処理の対象となり得る。
eCallは、GSM（登録商標）(2G)またはUMTS(3G)を介した3GPP回線交換呼として(3GPPおよびCENによって)標準化され得る。呼セットアップにおける1つまたは複数のフラグ(たとえば、eCallフラグ)は、呼をeCallとして示すことができ、呼が自動的にトリガされたか、それとも手動でトリガされたかをさらに示すことができる。呼はeCall対応可能PSAPにルーティングされ得、車両とPSAPとの間で音声チャネルが確立され得、音声チャネル内で車両、センサ(たとえば、クラッシュ関連)、およびロケーションデータの定義されたセット(最小データセット、すなわちMSD)を搬送するためにeCall帯域内モデムが使用され得る。PSAPがMSDの成功裏の受信を確認応答するために、また随意に、(たとえば、車両または車両の搭乗者の状態またはロケーションが変化したかどうかをチェックするために)新しいMSDを送ることを車両に要求するために、同じ帯域内機構が使用され得る。次世代eCall(NG-eCall、これはパケット交換eCallまたはPS eCallとも呼ばれる)の作業が現在進行中である。この作業の一環として、欧州電気通信標準化機構(ETSI)は、オールIP環境におけるeCallのサポートに関する所見および勧告を盛り込んだ技術報告書を発表した。NG-eCallはオールIPであってよく、呼に関連する追加データとして車両データおよび他のeCall固有データを搬送することができる。
NG-eCallに関するMSG技術報告書の勧告は、呼をeCallとして、またeCallデータを搬送するものとして識別する追加の要素を伴い、データを搬送するための機構を伴って3GPP IMS緊急呼を使用することである。3GPP IMS緊急サービスは、マルチメディアをサポートし、音声、テキスト、およびビデオを搬送する能力を提供することができる。この能力は、マルチメディア緊急サービス(MMES)と呼ばれ得る。eCallの開始および処理に関与する様々なエンティティが次世代eCall、レガシーeCall、または両方をサポートし得る移行期間が存在することがある。この移行期間は、数年またはそれよりも長く続く可能性がある。
全体的なeCall要件は、CENによって、また3GPPによって明示され得る。車両データに固有の要件も明示され得る。便宜上、要件のうちのいくつかについて、以下でごく簡単に要約する。
eCallは、以下を必要とし得る。呼は、eCall(本質的に緊急呼である)として認識される。呼セットアップは、呼が手動でトリガされたか、それとも自動的にトリガされたかを示すことができる。車両とPSAPとの間の音声チャネル。本質的に呼とともにMSDを搬送する(MSDは、音声と同じ電話対応オペレータが入手可能である必要がある)。PSAPがMSDの受信を確認応答する能力。車両が新しいMSDを生成し送信することをPSAPが要求する能力。最初のeCallが行われた後に車両の搭乗者に再度連絡することができるPSAPの能力。および/または(PSAPにルーティングされ得るが、緊急呼として扱われず、電話対応オペレータによって処理されない)テスト呼を実行する能力。
NG-eCallは、多くの潜在的改善をもたらすことができるが、これらは現在のEU規則によって求められていないことがある。NG-eCallがもたらし得る改善は、以下を含む。さらなるデータ(たとえば、拡張MSDまたはMSDプラス追加のデータセット)を搬送する能力。ビデオを処理する能力。テキストを処理する能力。PSAPが車両構成要素(たとえば、クラッシュ現場の状況の視覚的判断のための(後ろ向きのカメラまたはブラインドスポットカメラなどの)搭載カメラ)にアクセスする能力。アクションを実行する(たとえば、クラクションを鳴らす、イグニションを無効にする、ドアの鍵を開ける/閉める)ことをPSAPが車両に要求する能力。および/または(MSDが帯域内モデムを使用して転送されることはないので)音声チャネルのオーディオミューティングを回避する能力。
汎欧州eCallは、最小データセット(MSD)と呼ばれ得る、車両関連データの標準化および義務化されたセットを提供することができる。欧州標準化委員会(CEN)は、このデータを明示し得る。回線交換eCallは、ASN.1符号化を使用することができる。しかしながら、XML符号化が、SIPメッセージにおける使用により適していることがあるので、本明細書ではXML符号化について説明する。
SIIP緊急呼にデータのブロックを添付するための一般的な機構も確立され得る。本開示は、SIIP緊急呼においてeCall MSDを搬送するためにその機構を利用する。
本開示は、MSDをSIPにおいて搬送することを可能にし得る、'application/emergencyCallData.eCall.MSD+xml'MIMEコンテンツ-タイプについて説明する。本明細書はまた、SIPベースのeCall緊急呼などにおいてそのようなものとしてMSDを認識することを可能にし得る、緊急呼追加データブロックレジストリへの'eCall.MSD'エントリについて説明する。追加データセットが(たとえば、将来に、または他の地域において)定義され、本明細書で説明する機構を使用して送信される場合、シグナリングチャネルの使用が適切であることを確かめるために、呼の間の送信のサイズおよび/または頻度が評価され得る。
回線交換eCall(図48に示す図4800参照)では、IVS4805は、(呼がeCallであることのほか、呼が手動でトリガされたか、それとも自動的にトリガされたかも示し得る)eCallフラグを搬送する特別な形式の112緊急呼を発することができ、モバイルネットワークオペレータ(MNO)は、eCallフラグを認識し、呼をeCall対応可能PSAP4810にルーティングすることができ、車両データが(音声チャネルにおいて)eCall帯域内モデムを介してPSAP4810に送信され得る。
NG-eCallをサポートする車載システム(IVS)は、明示されたようにMSDを符号化し、MIME本文部分としてINVITEにMSDを添付することによってMSDを送信することができる。本文部分は、本文部分のコンテンツ-タイプヘッダフィールドにおけるそのMIMEコンテンツ-タイプ('application/emergencyCallData.eCall.MSD+xml')によって識別され得る。本文部分は、本文部分におけるコンテンツ-IDヘッダフィールドに記載される一意の識別子を割り当てられ得る。INVITEは、INVITEのトップレベルにおける呼-情報ヘッダフィールドを追加する(または呼-情報ヘッダフィールドに付加する)ことによって、MSDを含むものとして示され得る。この呼-情報ヘッダフィールドは、本文部分の一意の識別子を参照するCID URL、およびレジストリエントリごとにeCall MSDとしてデータを識別する'purpose'パラメータを含むことができ、'purpose'パラメータの値は、'emergencyCallData.'および('emergencyCallData'プレフィックスおよび'+xml'などのあらゆるサフィックスを含まない)MIMEタイプのルート(たとえば、'purpose=emergencyCallData.eCall.MSD')であってよい。
NG-eCall(図49に示す図4900参照)の場合、IVS4905は、車両データが添付されたeCallタイプの緊急呼を示すRequest-URIとともに3GPP IMSソリューションを使用して緊急呼を確立することができ、MNOまたはESInetは、eCall URNを認識し、呼をNG-eCall対応可能PSAP4910にルーティングすることができ、PSAP4910は、呼とともに送られた車両データを解釈し、それを電話対応オペレータに提供することができる。
本開示は、「sos」サブサービス内の新しいサービスURN子について説明し得る。これらのURNは、eCallが識別され得る機構を提供することができ、(ポリシーに応じて異なる処置の対象となり得る)手動でトリガされたeCallと自動的にトリガされたeCallとの間で区別することができる。2つのそのようなサービスURNは、urn:service:sos.ecall.automaticおよびurn:service:sos.ecall.manualである。
eCallsは、(必要とされる応答のタイプにとって意味合いを有する)特別なタイプの緊急呼であり、特別に指定されたPSAPによって処理される必要があり得るので、eCallsのルーティングルールは、他の緊急呼のルーティングルールとは異なり得る。ESInetを使用する環境では、発信ネットワークは、(「SOS」サービスURNを含む要求URIを有し得る)ESInetにすべてのタイプの緊急呼を渡すことができる。その場合にESInetは、そのような呼を適切なPSAPにルーティングする責任を負い得る。ESInetを有しない環境では、緊急サービス局および発信ネットワークは、そのような呼がどのようにルーティングされるかを共同で判断することができる。
本明細書で説明する緊急サービスIPネットワーク(ESInet)は、緊急サービス局によって運営されるネットワークであり得る。ESInetは、緊急呼のルーティングおよびPSAPへの配信前の処理を扱うことができる。EENAによって採用されたNG1-1-2アーキテクチャでは、各PSAPは、1つまたは複数のESInetに接続され得る。各発信ネットワークも、1つまたは複数のESInetに接続され得る。ESInetは、緊急呼のルーティングおよび処理を制御するポリシーベースのルーティングルールを維持することができる。ESInet内のそのようなルールの集中化は、発信ネットワークの責任と緊急サービスネットワークの責任との間の分離をもたらすことができ、緊急サービス局による緊急呼の処理に対する柔軟性および制御の向上をもたらすことができる。これは、緊急呼がルーティングまたは処理される方法の変更を必要とする異例の状況(たとえば、天災によるPSAPの閉鎖)に迅速に反応すること、ならびにそのようなルーティングに影響を与える長期的変更を行うこと(たとえば、翻訳または中継サービスを必要とする呼を特別に処理するための協力的な措置)に徐々に慣れることをより容易にし得る。ESInetは、(IP緊急呼をレガシー非IP PSAPと相互作用させる能力と同様の)IP PSAPではないeCall対応可能PSAPに対応するためにNG-eCallをレガシーeCallと相互作用させる能力をサポートすることができる。IP PSAPではない、ESInetに結び付けられていないレガシーeCall対応可能PSAPをサポートするために、発信ネットワークは、eCallおよび手動指示または自動指示に基づいて、(たとえば、適切なレガシーeCall対応可能PSAPへの相互接続を有する相互作用施設に)eCall自体をルーティングする能力を必要とし得ることに留意されたい。
eCallは、テスト呼を発する能力を含むことができる。テスト呼は、ある程度eCallとして認識され、扱われる呼であり、緊急呼の処置を受けなくてよく、電話対応オペレータによって処理されなくてよい。テスト呼機能により、IVSおよびユーザは、eCallが音声通信により成功裏に確立され得ることを確認することができる。IVSは、MSDが成功裏に受信されたことを確認することもできる。
「test.」で始まるサービスURNは、テスト呼を示すことができる。eCallの場合、「urn:service:test.sos.ecall」は、そのようなテスト機能を示すことができる。本開示は、eCallテスト呼の「urn:service:test.sos.ecall」について説明する。
現在のeCallテスト呼機能は、非緊急電話番号であってよく、そのため、緊急呼として扱われなくてよい。MNOは、必要なだけ多くの機能をテストする形で、「test」サービスURNにおける車両呼を扱うことができる。
NG-eCallを処理する能力を有するPSAPは、テスト呼を受け入れ、MSDが成功裏に受信された場合に確認応答を送ることができる。そのようなPSAPは、メディアループバックをサポートすることに加えて、(たとえば、呼がPSAPに到着したことをいう)オーディオクリップを再生することもできる。
eCallは、IVSによって送られたMSDの成功裏の受信をPSAPが確認応答する能力、およびIVSがMSDを送ることをPSAPが要求する能力(たとえば、電話対応オペレータは、車両の状態またロケーションが変化したかどうかを確認するために新しいMSDを求める要求を開始することができる)を含むことができる。PSAPは、ドアの鍵を閉めること、または開けること、クラクションを鳴らすこと、ライトを照らすこと、搭載カメラ(リアフォーカスまたはブラインドスポットなど)からのビデオストリームを開始することなどのような、他の要求を車両に送ることもできる。
IVSからPSAPにMSDを搬送するための機構は、PSAPからIVSに制御データのブロックを搬送するために使用されてもよい。(eCallメタデータとも呼ばれる)このeCall制御ブロックは、eCall固有要素を含むXML構造であり得る。PSAPが、IVSによってSIP要求において送られたMSDまたは他のデータに応答したeCall制御ブロックを送る必要があるとき、制御ブロックは、その要求(たとえば、INVITE)へのSIP応答において送られ得る。PSAPが、IVSによって送られたMSDまたは他のデータへの即時の応答ではないeCall制御ブロックを送る必要があるとき、制御ブロックは、確立されたセッション内でSIP INFOメッセージにおいてPSAPからIVSに送信され得る。IVSは、INFOメッセージに返答して、任意の要求されたデータ(新しいMSDなど)を送ることができる。この機構は、PSAPがIVSにeCall固有データを送り、IVSが応答することを可能にし得る。応答メッセージにおいて送られた制御データが、新しいMSDもしくは他のデータブロックを送ること、または送ること以外のアクションを実施することをIVSに要求する場合、IVSは、セッション内でINFOメッセージにおいて、要求されたデータまたはアクションに関する確認応答を送ることができる(IVSは、re-INVITEを使用することもできるが、それは、セッションまたはメディアのいかなる態様も変化していないときには不要である)。
この機構は、以下を含み得る:eCall制御オブジェクトのXML定義、(たとえば、追加の要素が、それらの名前空間を追加することによって含められることを可能にする)制御オブジェクト定義に新しい要素が追加され得る拡張機構、制御オブジェクトのMIMEタイプ登録(したがって、それはSIPメッセージおよび応答において搬送され得る)、SIPメッセージ内の緊急呼固有データとして制御ブロックが認識され得るような、緊急呼追加データブロックサブレジストリにおけるエントリ、ならびに/またはInfoメッセージ内の制御ブロックを許容するInfo-Package登録。
eCall制御ブロックは、確認応答、要求、および能力情報の送信を可能にし得るXMLデータ構造であり得る。それは、特定のMIMEコンテンツタイプを有するSIP本文部分において搬送され得る。様々なトップレベル要素が、eCall制御ブロック内で使用するために定義されてよく、以下で例について説明する。
ack:いずれかの側によって送られる制御ブロックにおいて使用され得る。PSAPは、IVSによって送られたデータセットの受信を確認応答するために、これを使用することができる。IVSは、PSAPによる要求が他の方法で確認応答される(PSAPがデータを送ることを車両に要求し、車両がそうした場合、そのデータは成功の確認応答の働きをし得る)ことのないとき、その要求の受信を確認応答するために、これを使用することができる。
capabilities:車両能力をPSAPに通知するために(初期INVITEにおいて、または必要に応じて後に)IVSからPSAPに送られる制御ブロックにおいて使用され得る。子要素は、車両によってサポートされるアクションおよびデータタイプのすべてまたは複数またはサブセットを含むことができ、いくつかの実施形態では、利用可能なカメラ、ランプ、他の機器などのすべてまたはいくつかを含むこともできる。
request:PSAPによってIVSに送られる制御ブロックにおいて使用され得、アクションの実施を車両に要求することができる。
IVSおよびPSAPは、以下の例のような様々なアクションをサポートすることができる。データオブジェクトを送信する、静的(所定の)メッセージを再生および/もしくは表示する、動的テキスト(アクションにおいて供給されたテキスト)を話す/表示する、動的オーディオ(SIP本文部分において、もしくはアクションにおいて供給されたメディア)を再生する、ならびに/またはライトを照らす、クラクションを鳴らす、ドアの鍵を閉める/開ける、窓の鍵を閉める/開ける/窓を開ける/閉める、燃料ポンプを有効/無効にする。
'ack'要素は、オブジェクトが確認応答されていることを示すことができ、成功または失敗を報告することができる。'capabilities'要素は、IVSによってサポートされるアクションを示すための子'request'要素を有し得る。
'request'要素は、任意の必要とされる情報を供給し得る要求を示すための属性を含むことができ、動的メッセージのためのテキストを含み得る'text'子要素を含むことができる。'action'属性は、特定のアクションを示すことができる。IANAレジストリ、または他の適切なレジストラのレジストリが、許容された値を含むように確立され得る。
新しい要素、子要素、および属性が、それら自体のサブ名前空間とともに定義され得る。いくつかの要素および属性の許容された値を明示するために、IANAまたは他の適切なレジストリが使用され得る。これらの機構は、拡張を可能にし得る。
制御ブロックは、(あらかじめ録音されたオーディオメッセージなどの)メディアを再生するための'request'アクションを含まなくてよい。そのような場合、この目的で1方向メディアストリームを確立するためにSIP-INVITE機構が使用され得る。
'ack'要素はPSAPによって、eCallデータオブジェクトの受信を確認応答するために送信され得る。'ack'要素は、PSAPによって送られてよく、IVSによって送られたデータオブジェクトの一意のIDを参照することができ、PSAPが受信を成功と見なすかどうかをさらに示すことができる。データオブジェクトを送信すること以外であり得るアクションの実施をIVSに要求した'request'要素の受信を確認応答し得る'ack'要素が、IVSによってPSAPに送信されることもある(たとえば、メッセージの表示を求める要求は確認応答され得るが、データオブジェクトの送信を求める要求は、データオブジェクト自体が確認応答としての働きをし得るので、別個の'ack'要素の送信につながらないことがある)。'ack'要素は、IVSによって送られてよく、確認応答されている要求の一意のIDを参照することができ、要求が成功裏に実施されたかどうかをさらに示すことができる。
'ack'要素は、図50の図5000に示すような属性を含むことができ、図51の図5100に示すような子要素をさらに含むことができる。
'capabilities'要素はIVSによって、その能力をPSAPに示すために送信され得る。能力要素に使用され得る例示的な子要素が、図52の図5200に示されている。
'request'要素は、単独で、または'capabilities'要素の子として、1回または複数回現れ得る。'request'要素において使用され得る例示的な属性および子要素が、それぞれ図53Aおよび図53Bの図5300および図5305に示されている。'request'要素は、それぞれ図54Aおよび図54Bの図5400および図5405に示すような子要素を有し得る。図55の図5500は、本開示に従って使用され得る仕様をさらに含む。
'emergencyCallData.eCall'INFOパッケージについて、本明細書で説明する。両方のエンドポイント(IVSおよびPSAP機器)は、eCallデータまたは制御ブロックを搬送するINFOメッセージを受信する能力を示すために、Recv-Infoヘッダフィールドを'emergencyCallData.eCall'に設定することができる。
'emergencyCallData.eCall'INFOパッケージのサポートは、サブタイプが'emergencyCallData.eCall.'で始まり得る本文部分において搬送され得る、eCallデータまたは制御ブロックを受信する能力を示すことができる。'application/emergencyCallData.eCall.MSD+xml'MIMEタイプを有する、eCallデータブロックなど定義された様々なデータブロック、および/または'application/emergencyCallData.eCall.control+xml'MIMEタイプを有する、eCall制御ブロックなどの様々な制御ブロックがあってよく、追加ブロックがさらに定義され得る。eCall制御ブロックは、IVSがその能力を示す能力を含むことができ、そのため追加のeCallまたは他のデータブロックが定義される場合、IVSは、IVSがどれをサポートするかを示すことができる。
INFOの使用は、INFOの意図および効果を(SIP MESSAGE、メディアプレーン、または非SIPプロトコルなどの)他の手法と比較した要件の分析に基づき得る。特に、eCallデータおよび制御ブロックの移送は、SIPにより確立された緊急セッション中に行われてよく、通常、初期INVITEおよびその応答において搬送されてよく、INFOの使用は、データブロックまたは要求が後で呼の間に送られる必要があるときに発生し得る。MESSAGEが使用され得る一方、それはINFOの場合のようにSIPセッションに結び付けられなくてよい。re-INVITEが使用されることもあるが、通常、セッションを変更するために使用される。SUBSCRIBE/NOTIFYが使用され得る。しかしながら、他の実施形態では、INFOが使用され得る。
eCallデータまたは制御ブロックを搬送するINFO要求メッセージは、'emergencyCallData.eCall'に設定されたInfo-Packageヘッダフィールドを有し得る。INFO要求メッセージは、eCallデータまたは制御を含む本文部分の一意の識別子を参照するCID URL、およびブロックを識別する'purpose'パラメータを含む呼-情報ヘッダフィールドによって、eCallデータまたは制御ブロックを含むものとして示され得る。eCallデータまたは制御ブロックは、INFO要求メッセージにおいて搬送され得るので、本文部分は、「Info-Package」に設定されたContent-Dispositionヘッダフィールドを搬送することもできる。
緊急呼関連追加データが、本文が現れ得る任意のSIP要求または応答メッセージに含まれ得る。したがって、INFO応答メッセージは、(本文部分の一意の識別子を参照するCID URL、およびブロックを識別する'purpose'パラメータを含む呼-情報ヘッダフィールドを有する)eCallデータまたは制御ブロックを含むことができる。eCallデータまたは制御ブロックがINFO応答メッセージに含められるとき、eCallデータまたは制御ブロックは、INFOパッケージ関連データとしてではなく、緊急呼追加データとして含められ得る。
図56は、eCallの一例による図5600を示している。呼は、要求URI'urn:service:sos.ecall.automatic'サービスURNを使用することができ、したがってeCallとして、さらに、クラッシュまたは他の重大な出来事に起因してIVS5605によって自動的に呼び出されたものとして認識され得る。この例では、発信ネットワーク5610は、(ESInetを有する環境における任意の緊急呼と同様に)呼をESInet5615にルーティングすることができる。ESInet5615は、適切なNG-eCall対応可能PSAP5625に呼をルーティングすることができる。緊急呼は、ESInet5615へのエントリポイントとしてESInetの緊急サービスルーティングプロキシ(ESRP)5620によって受信され得る。ESRP5620は、PSAP5625に呼をルーティングすることができ、そこで呼が電話対応オペレータによって受信され得る。ESInetがない展開では、発信ネットワーク5610は、適切なNG-eCall対応可能PSAP5625に呼を直接ルーティングすることができる。
図57は、MSDを含むSIP eCall INVITEの一例を示す図5700を示している。他の場所で説明した様々なセキュリティ考慮事項は、ここでも当てはまり得る。
eCallなどのACN呼は、2つの形式のロケーションデータ、すなわち、(ネットワークのみによって、または発信デバイスと協調して、または場合によっては完全に発信デバイスによって判断され得る)本質的にIMS緊急呼の一部であるネットワーク提供型ロケーション、およびMSD内のIVS供給型ロケーションを搬送することができる。これは、特に2つのロケーションが別個に判断されるときに、PSAPにとって有用であり得る。ネットワーク提供型ロケーションがセルサイトに限定される状況でも、これは、MSDに含まれるデバイス供給型ロケーションに対するサニティチェックとして有用であり得る。
端末デバイスによって提供されるロケーションまたは端末デバイスと協調して判断されるロケーションに関する信頼性問題がさらに考慮され得る。
PSAPが車両に確認応答および要求を送る機構は、信憑性の考慮を必要とすることがあり、セルラーネットワークを介して発せられたeCall緊急呼として車両によって開始されたセッション内でPSAP要求が受信されたとき、送信元が実際にPSAPであることのより高い信頼度があり得る。コールバックなどの他の状況においてPSAP要求が受信された場合、コールバックが実際にPSAPからのものであることを確認する際の信頼性問題は、より複雑であり得る。(どちら側が呼を開始したか、および呼の手段に関係なく適用可能な)さらなる安全措置は、PSAPまたは緊急サービスプロバイダが、既知の緊急サービス認証局によって発行された、IVSがルート認証を確認できる認証を使用して本文部分にサインすることであり得る。
eCall制御ブロックのXMLスキーマの一例について、ここで説明する。図58は、一例を示す図5800を示している。URN'urn:service:sos.ecall'は、サブサービス'sos'レジストリの下で登録され得る。
このサービスは、(特殊な車載システムによって発せられ、車両およびクラッシュまたは出来事に関係するデータの標準化されたセットを搬送する)緊急呼のタイプを識別することができ、呼を、そのような呼を処理する技術的能力および運用能力を有する専門の緊急応答機関(PSAP)に向ける必要があり得る。以下のような2つのサブサービスも登録され得る。urn:service:sos.ecall.manual:このサービスURNは、eCallがドライバまたは乗客の手動対話に基づいてトリガされていることを示すことができる。urn:service:sos.ecall.automatic:このサービスURNは、eCallが、たとえば、クラッシュまたは他の重大な出来事(たとえば、火災)に起因して自動的にトリガされていることを示すことができる。
URN'urn:service:test.sos.ecall'も、サブサービス'test'レジストリの下で登録され得る。また、本開示によれば、図59の図5900に示すように、MIMEコンテンツタイプとしてapplication/emergencyCallData.eCall.MSD+xmlが追加され得る。また、本開示によれば、図60の図6000に示すように、MIMEコンテンツタイプとしてapplication/emergencyCallData.eCall.control+xmlが追加され得る。
'eCall.MSD'エントリも、緊急呼追加データブロックレジストリに追加され得る。また、'eCall.control'エントリも、緊急呼追加データブロックレジストリに追加され得る。また、emergencyCallData.eCallも、「セッション開始プロトコル(SIP)パラメータ」の下でInfoパッケージレジストリに追加され得る。
図61は、新しいXML名前空間を登録するために使用され得る図6100を示している。同様に、図62は、新しいXML名前空間を登録するために使用され得る図6200を示している。'eCall制御データ'と呼ばれる新しいレジストリが確立されてもよく、以下で説明するように、このレジストリのためにサブレジストリが作成されてよい。
本開示によれば、「eCall制御アクションレジストリ」と呼ばれるサブレジストリが作成され得る。このレジストリは、「エキスパートレビュー」ルールの下で作用し得る。専門家は、提案されたアクションが車両の範囲内にあり、他のアクションから十分に区別可能であると判断し、アクションが明確かつ十分に説明されていると判断し得る。アクションの説明に関して、発表済みのしっかりした文書が参照され得る。
このレジストリの内容は名前を含むことができ、名前は、eCall制御'request'要素の'action'属性において使用され得る識別子であり得る。レジストリは、アクションの説明を含むこともできる。これは、発表済みのしっかりした文書の参照であり得る。説明は、属性または子要素が随意であるか、それとも必須であるかを明示することができ、車両によって実行されるべきアクションを説明することができる。eCall制御アクションの例示的なセットが、図63の表6300に示されている。
また、本開示によれば、「eCall静的メッセージレジストリ」と呼ばれる新しいサブレジストリが作成され得る。準拠した車両は、車両によってサポートされる言語に翻訳された静的メッセージをサポートすることが期待され得るので、そのようなメッセージの数を制限することは重要であり得る。レジストリは、「発表物必要」ルールの下で作用することができ、このルールは、しっかりした公的文書を必要とすることがあり、発表物のエキスパートレビューを示唆し得る。専門家は、文書が適切な緊急サービス団体(たとえば、NENA、EENA、APCO)によって発表されていると判断し、提案されたメッセージが他のメッセージから十分に区別可能であると判断し得る。
このレジストリの内容はIDを含むことができ、IDは、eCall制御'request'要素の'msgid'属性において使用され得る整数識別子であり得る。レジストリの内容はメッセージを含むこともでき、これはメッセージのテキストであってよい。メッセージは、英語でレジストリに記載されてよく、車両は、車両によってサポートされる言語への翻訳を実施することが期待され得る。
新しいメッセージがレジストリに追加されたとき、メッセージテキストが登録者によって決定されてよく、IANAまたは別の適切なレジストラはIDを割り当てることができる。各メッセージは、そのIDとして連続する整数値を割り当てられ得る。これによりIVSは、単一の整数値によって、IVSがその値またはより低い値を有するすべてのメッセージをサポートすることを示すことが可能になり得る。値の初期セットの一例が、図64の表6400に示されている。
また、「eCall理由レジストリ」と呼ばれる新しいサブレジストリが作成されてよく、このサブレジストリは、'ActionResult'要素の'reason'属性の値を含み得る。このレジストリは、「エキスパートレビュー」ルールの下で作用し得る。専門家は、提案された理由が他の理由から十分に区別可能であると判断し、提案された説明が理解可能で正しく表現されていると判断し得る。
このレジストリの内容はIDを含むことができ、IDは、'ActionResult'要素の'reason'属性において使用するための、理由を識別する短い文字列であり得る。レジストリの内容は説明を含むこともでき、これは理由の説明であってよい。値の初期セットの一例が、図65の表6500に示されている。
また、「eCallランプ-IDレジストリ」と呼ばれる新しいサブレジストリが、たとえば、自動車ランプ(ライト)の名前を標準化するために作成され得る。このレジストリは、「エキスパートレビュー」ルールの下で作用し得る。専門家は、提案されたランプ名が明瞭に理解可能であり、他のランプ名から十分に区別可能であると判断し得る。
このレジストリの内容は名前を含むことができ、名前は、eCall制御'request'要素の'lamp-ID'属性において使用され得る識別子であり得る。レジストリの内容は説明を含むこともでき、これはランプ(ライト)の説明であってよい。値の初期セットの一例が、図66の表6600に示されている。
添付の図面に関して上述した発明を実施するための形態は、例について説明しており、実装され得るか、または特許請求の範囲内に入る例のみを表すものではない。本明細書に使われる場合、「例および例示的」という用語は、「一例、実例、または例示として役立つ」ことを意味し、「好ましい」または「他の例よりも有利な」を意味するものではない。発明を実施するための形態は、説明した技法の理解をもたらす目的で、具体的な詳細を含む。しかしながら、これらの技法は、これらの具体的な詳細なしに実施され得る。場合によっては、説明した例の概念を曖昧にするのを回避するために、周知の構造および装置がブロック図の形式で示されている。
多種多様な技術および技法のうちのいずれかを使用して、情報および信号が表され得る。たとえば、上記の説明全体にわたって言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁界もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表され得る。
本明細書の開示に関して説明した様々な例示的なブロックおよび構成要素は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、ASIC、FPGAもしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明した機能を実施するように設計されたそれらの任意の組合せを用いて実装または実施され得る。汎用プロセッサはマイクロプロセッサとすることができるが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械とすることができる。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。
本明細書で説明した機能は、ハードウェア、プロセッサによって実行されるソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。プロセッサで実行されるソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、またはコンピュータ可読媒体を介して1つまたは複数の命令またはコードとして送信され得る。他の例および実装形態が、本開示および添付の特許請求の範囲の範囲および趣旨の中にある。たとえば、ソフトウェアの性質により、上で説明した機能は、プロセッサ、ハードウェア、ファームウェア、ハードワイヤリング、またはこれらの任意の組合せによって実行されるソフトウェアを使用して、実装され得る。機能を実装する機構はまた、機能の一部が異なる物理的ロケーションで実装されるように分散された状態を含む、様々な位置に物理的に位置していてもよい。特許請求の範囲を含めて本明細書で使用する場合、「および/または」という用語は、2つ以上の項目の列挙で用いられるとき、列挙される項目のうちのいずれか1つを単独で利用できること、または列挙される項目のうちの2つ以上からなる任意の組合せを利用できることを意味する。たとえば、構成が、構成要素A、B、および/またはCを含むものとして説明される場合には、その構成は、A単体、B単体、C単体、AとBとの組合せ、AとCとの組合せ、BとCとの組合せ、またはA、B、およびCの組合せを含むことができる。また、特許請求の範囲を含めて本明細書で使用する場合、「のうちの少なくとも1つ」または「のうちの1つまたは複数」などの句によって修飾される項目の列挙で用いられる「または」は、たとえば、「A、B、またはCのうちの少なくとも1つ」という列挙が、AまたはBまたはCまたはABまたはACまたはBCまたはABC(すなわち、AおよびBおよびC)を意味するように、選言的な列挙を示す。
コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、汎用または専用コンピュータによってアクセスできる任意の利用可能な媒体とすることができる。限定ではなく例として、コンピュータ可読媒体は、RAM、ROM、EEPROM、フラッシュメモリ、CD-ROM、もしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または命令またはデータ構造の形態の所望のプログラムコード手段を搬送または記憶するために使用され得、汎用もしくは専用コンピュータまたは汎用もしくは専用プロセッサによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、ソフトウェアが、ウェブサイト、サーバ、または他のリモートソースから、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または、赤外線、無線およびマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または、赤外線、無線およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含まれる。
本開示の上記の説明は、当業者が本開示を作成または使用できるようにするために提供される。本開示への様々な修正が当業者には容易に明らかになることになり、本明細書に定義する一般原理は、本開示の範囲を逸脱することなしに他の変形形態に適用され得る。したがって、本開示は、本明細書で説明した例および設計に限定するものではなく、本明細書で開示する原理および新規の特徴に一致する最も広い範囲を与えられるべきである。
100 ワイヤレスネットワークシステム
101 発展型パケットシステム(EPS)
102 訪問先ネットワーク
103 プロキシ呼セッション制御機能(P-CSCF)
104 ホームネットワーク
105 基地局
106 サードパーティネットワーク
107 サービング呼セッション制御機能(S-CSCF)
109 緊急呼セッション制御機能(E-CSCF)
110 端末
110-a 端末
110-l 端末
110-m 端末
110-n 端末
110-o 端末
110-p 端末
110-q 端末
110-r 端末
110-s 端末
111 緊急サービスルーティングプロキシ(ESRP)
113 緊急呼ルーティング機能(ECRF)
115 発展型UMTS Terrestrial Radio Access Network(E-UTRAN)
117 シグナリングの第1のセット
119 シグナリングの第2のセット
120 無線アクセスネットワーク(RAN)
125 発展型パケットコア(EPC)
130 モバイル交換センター(MSC)/ビジターロケーションレジスタ(VLR)
135 ホーム加入者サーバ(HSS)
140 ホームロケーションレジスタ(HLR)/認証センター(AC)
145 モビリティ管理エンティティ(MME)
150 ルータ
155 サービングゲートウェイ
160 緊急応答機関(PSAP)、中央サービス、PSAP中央サービス
160-l 中央サービス
160-m 中央サービス
160-n 中央サービス
160-o 中央サービス
160-p 中央サービス
160-q 中央サービス
160-r 中央サービス
160-s 中央サービス(たとえば、PSAP)
165 パケットデータネットワーク(PDN)ゲートウェイ
170 公衆交換電話網(PSTN)
175 他のIPサービスおよびネットワーク
180 電話
185 緊急サービスIPネットワーク(ESInet)、緊急サービスネットワーク(ESInet)
190 車両
195 衛星
200 ブロック図
205 端末受信機モジュール
210 テレマティクスデータシグナリングモジュール
215 端末送信機モジュール
300 ブロック図
305 セッション/テレマティクスメタデータ分離モジュール
310 セッション制御モジュール
315 テレマティクスデータモジュール
320 セッション/テレマティクスデータ結合モジュール
400 ブロック図
405 SIP/SDPモジュール
410 セッション実施モジュール
415 テレマティクスメタデータ分析モジュール
420 外部システム制御モジュール
425 テレマティクスデータメッセージモジュール
430 テレマティクスデータ収集モジュール
500 フォーマット、変更されたSIP要求メッセージフォーマット
505 要求ライン
510 ヘッダ
515 セッション情報のセット
520 テレマティクスデータのセット
525 指示
530 タグ
535 eCallDataオブジェクト
550 SIP要求メッセージ、変更されたSIP INVITEメッセージ、SIP INVITEメッセージ、SIP INVITEシグナリングメッセージ
600 ブロック図
605 中央サービス受信機モジュール
610 テレマティクスメタデータシグナリングモジュール
615 中央サービス送信機モジュール
700 ブロック図
705 セッション/テレマティクスデータ分離モジュール
710 テレマティクスメタデータモジュール
715 セッション/テレマティクスメタデータ結合モジュール
800 ブロック図
805 テレマティクスデータ分析モジュール
810 中央サービスアクションモジュール
815 テレマティクスメタデータメッセージモジュール
820 端末アクションモジュール
900 フォーマット、変更されたSIP応答メッセージフォーマット
905 ステータスライン
910 ヘッダ
915 セッションデータのセット
920 テレマティクスメタデータのセット
925 eCallMetaData用P-ヘッダ
930 確認応答
935 コマンド
950-a 変更されたSIP200(OK)メッセージ、メッセージ、SIP200(OK)メッセージ、SIP200(OK)シグナリングメッセージ、応答メッセージ、変更されたSIP応答メッセージ
950-b, c, d, e 変更されたSIP応答メッセージ
955 コマンド
960 参照
965 動的メディアオブジェクト
970 タグ
975 テレマティクスメタデータオブジェクト
1100, 1200, 1300, 1400, 1500 通信交換
1605 プロセッサモジュール
1610 メモリ
1615 コンピュータ可読コンピュータ実行可能ソフトウェアコード、ソフトウェアコード
1615-a コンピュータ可読コンピュータ実行可能ソフトウェアコード、ソフトウェアコード
1620 シグナリングモジュール
1625 トランシーバモジュール
1630 アンテナ
1705 ネットワークインターフェースコントローラ(NIC)
1800, 1900, 200, 2100 方法
2200 ブロック図
2205 端末受信機モジュール
2210 テレマティクスデータシグナリングモジュール
2210-a テレマティクスデータシグナリングモジュール
2210-b テレマティクスデータシグナリングモジュール
2210-c テレマティクスデータシグナリングモジュール
2215 端末送信機モジュール、送信機モジュール
2300 ブロック図
2305 セッション制御モジュール
2305-a セッション制御モジュール
2310 テレマティクスデータモジュール
2315 外部システムモジュール、外部システム制御モジュール
2320 能力モジュール
2320-a 能力モジュール
2320-b 能力モジュール
2400 ブロック図
2405 データ構造フォーマッティングサブモジュール
2405-a データ構造フォーマッティングサブモジュール
2410 サブセットサブモジュール
2415 再構成サブモジュール
2500 フォーマット、SIP要求メッセージフォーマット
2500-a SIP INVITEメッセージ、メッセージ、SIP INVITEシグナリングメッセージ
2505 要求ライン
2505-a 要求ライン
2510 ヘッダ
2510-a ヘッダ
2515 セッション情報
2515-a セッション情報
2520 テレマティクスデータ
2520-a テレマティクスデータ
2525 テレマティクス能力データ
2525-a テレマティクス能力データ
2530 能力データオブジェクト
2530-a 能力データオブジェクト、能力XML要素
2535-a-1 要求子XML要素、第1の要求子XML要素
2535-a-2 要求子XML要素、第2の要求子XML要素
2535-a-3 要求子XML要素、第3の要求子XML要素
2535-a-4 要求子XML要素、第4の要求子XML要素
2535-a-5 要求子XML要素、第5の要求子XML要素
2535-a-6 要求子XML要素、第6の要求子XML要素
2550 SIP INVITEメッセージ
2600 ブロック図
2605 中央サービス受信機モジュール
2610 テレマティクスメタデータシグナリングモジュール
2610-a テレマティクスメタデータシグナリングモジュール
2610-b テレマティクスメタデータシグナリングモジュール
2610-c テレマティクスメタデータシグナリングモジュール
2615 中央サービス送信機モジュール
2700 ブロック図
2705 テレマティクスメタデータモジュール
2705-a テレマティクスメタデータモジュール
2800 ブロック図
2805 適合サブモジュール
2810 要求サブモジュール
2810-a 要求サブモジュール
2900 フォーマット、SIP応答メッセージフォーマット
2900-a SIP応答メッセージ、SIP200(OK)メッセージ、SIP200(OK)シグナリングメッセージ、メッセージ、応答メッセージ
2905 要求ライン
2905-a ステータスライン
2910 ヘッダ
2910-a ヘッダ
2915 セッションデータのセット
2915-a セッションデータ
2920 テレマティクスメタデータのセット
2920-a テレマティクスメタデータ、メタデータ
2925-a-1 要求、第1の要求
2925-a-2 要求、第2の要求
2925-a-3 要求、第3の要求
2925-a-4 要求、第4の要求
2925-a-5 要求、第5の要求
2925-a-6 要求、第6の要求
3000 通信交換
3100 通信交換
3200 通信交換
3300 通信交換
3405 プロセッサモジュール
3410 メモリ
3415 ソフトウェア、コンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード、ソフトウェア/ファームウェアコード
3425 トランシーバモジュール
3430 アンテナ
3445 バス
3505 ネットワークインターフェースコントローラ(NIC)、プロセッサモジュール
3510 メモリ
3515 ソフトウェア、コンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード、ソフトウェア/ファームウェアコード
3545 バス
3600 方法
3700 方法
3800 方法
3900 図
3905 車両IVS
3910 テレマティクスサービスプロバイダ(TSP)
3915 PSAP
4000 図
4005 IVS
4010 ハンドセット
4015 PSAP
4100 図
4105 IVS
4110 PSAP
4200 図
4205 IVS、車両IVS
4210 TSP
4215 PSAP
4300 図
4305 IVS
4310 ハンドセット
4315 PSAP
4400 図
4405 IVS
4410 PSAP
4505 車両
4510 モバイルネットワークオペレータ(MNO)
4515 緊急サービスIPネットワーク(ESInet)
4525 ACN対応可能PSAP
4520 緊急サービスルーティングプロキシ(ESRP)
4600 図
4700 図
4800 図
4805 IVS
4810 eCall対応可能PSAP、PSAP
4900 図
4905 IVS
4910 NG-eCall対応可能PSAP、PSAP
5000 図
5100 図
5200 図
5300 図
5305 図
5400 図
5405 図
5500 図
5600 図
5605 IVS
5610 発信ネットワーク
5615 ESInet
5620 緊急サービスルーティングプロキシ(ESRP)
5625 NG-eCall対応可能PSAP、PSAP
5700 図
5800 図
5900 図
6000 図
6100 図
6200 図
6300 表
6400 表
6500 表
6600 表
101 発展型パケットシステム(EPS)
102 訪問先ネットワーク
103 プロキシ呼セッション制御機能(P-CSCF)
104 ホームネットワーク
105 基地局
106 サードパーティネットワーク
107 サービング呼セッション制御機能(S-CSCF)
109 緊急呼セッション制御機能(E-CSCF)
110 端末
110-a 端末
110-l 端末
110-m 端末
110-n 端末
110-o 端末
110-p 端末
110-q 端末
110-r 端末
110-s 端末
111 緊急サービスルーティングプロキシ(ESRP)
113 緊急呼ルーティング機能(ECRF)
115 発展型UMTS Terrestrial Radio Access Network(E-UTRAN)
117 シグナリングの第1のセット
119 シグナリングの第2のセット
120 無線アクセスネットワーク(RAN)
125 発展型パケットコア(EPC)
130 モバイル交換センター(MSC)/ビジターロケーションレジスタ(VLR)
135 ホーム加入者サーバ(HSS)
140 ホームロケーションレジスタ(HLR)/認証センター(AC)
145 モビリティ管理エンティティ(MME)
150 ルータ
155 サービングゲートウェイ
160 緊急応答機関(PSAP)、中央サービス、PSAP中央サービス
160-l 中央サービス
160-m 中央サービス
160-n 中央サービス
160-o 中央サービス
160-p 中央サービス
160-q 中央サービス
160-r 中央サービス
160-s 中央サービス(たとえば、PSAP)
165 パケットデータネットワーク(PDN)ゲートウェイ
170 公衆交換電話網(PSTN)
175 他のIPサービスおよびネットワーク
180 電話
185 緊急サービスIPネットワーク(ESInet)、緊急サービスネットワーク(ESInet)
190 車両
195 衛星
200 ブロック図
205 端末受信機モジュール
210 テレマティクスデータシグナリングモジュール
215 端末送信機モジュール
300 ブロック図
305 セッション/テレマティクスメタデータ分離モジュール
310 セッション制御モジュール
315 テレマティクスデータモジュール
320 セッション/テレマティクスデータ結合モジュール
400 ブロック図
405 SIP/SDPモジュール
410 セッション実施モジュール
415 テレマティクスメタデータ分析モジュール
420 外部システム制御モジュール
425 テレマティクスデータメッセージモジュール
430 テレマティクスデータ収集モジュール
500 フォーマット、変更されたSIP要求メッセージフォーマット
505 要求ライン
510 ヘッダ
515 セッション情報のセット
520 テレマティクスデータのセット
525 指示
530 タグ
535 eCallDataオブジェクト
550 SIP要求メッセージ、変更されたSIP INVITEメッセージ、SIP INVITEメッセージ、SIP INVITEシグナリングメッセージ
600 ブロック図
605 中央サービス受信機モジュール
610 テレマティクスメタデータシグナリングモジュール
615 中央サービス送信機モジュール
700 ブロック図
705 セッション/テレマティクスデータ分離モジュール
710 テレマティクスメタデータモジュール
715 セッション/テレマティクスメタデータ結合モジュール
800 ブロック図
805 テレマティクスデータ分析モジュール
810 中央サービスアクションモジュール
815 テレマティクスメタデータメッセージモジュール
820 端末アクションモジュール
900 フォーマット、変更されたSIP応答メッセージフォーマット
905 ステータスライン
910 ヘッダ
915 セッションデータのセット
920 テレマティクスメタデータのセット
925 eCallMetaData用P-ヘッダ
930 確認応答
935 コマンド
950-a 変更されたSIP200(OK)メッセージ、メッセージ、SIP200(OK)メッセージ、SIP200(OK)シグナリングメッセージ、応答メッセージ、変更されたSIP応答メッセージ
950-b, c, d, e 変更されたSIP応答メッセージ
955 コマンド
960 参照
965 動的メディアオブジェクト
970 タグ
975 テレマティクスメタデータオブジェクト
1100, 1200, 1300, 1400, 1500 通信交換
1605 プロセッサモジュール
1610 メモリ
1615 コンピュータ可読コンピュータ実行可能ソフトウェアコード、ソフトウェアコード
1615-a コンピュータ可読コンピュータ実行可能ソフトウェアコード、ソフトウェアコード
1620 シグナリングモジュール
1625 トランシーバモジュール
1630 アンテナ
1705 ネットワークインターフェースコントローラ(NIC)
1800, 1900, 200, 2100 方法
2200 ブロック図
2205 端末受信機モジュール
2210 テレマティクスデータシグナリングモジュール
2210-a テレマティクスデータシグナリングモジュール
2210-b テレマティクスデータシグナリングモジュール
2210-c テレマティクスデータシグナリングモジュール
2215 端末送信機モジュール、送信機モジュール
2300 ブロック図
2305 セッション制御モジュール
2305-a セッション制御モジュール
2310 テレマティクスデータモジュール
2315 外部システムモジュール、外部システム制御モジュール
2320 能力モジュール
2320-a 能力モジュール
2320-b 能力モジュール
2400 ブロック図
2405 データ構造フォーマッティングサブモジュール
2405-a データ構造フォーマッティングサブモジュール
2410 サブセットサブモジュール
2415 再構成サブモジュール
2500 フォーマット、SIP要求メッセージフォーマット
2500-a SIP INVITEメッセージ、メッセージ、SIP INVITEシグナリングメッセージ
2505 要求ライン
2505-a 要求ライン
2510 ヘッダ
2510-a ヘッダ
2515 セッション情報
2515-a セッション情報
2520 テレマティクスデータ
2520-a テレマティクスデータ
2525 テレマティクス能力データ
2525-a テレマティクス能力データ
2530 能力データオブジェクト
2530-a 能力データオブジェクト、能力XML要素
2535-a-1 要求子XML要素、第1の要求子XML要素
2535-a-2 要求子XML要素、第2の要求子XML要素
2535-a-3 要求子XML要素、第3の要求子XML要素
2535-a-4 要求子XML要素、第4の要求子XML要素
2535-a-5 要求子XML要素、第5の要求子XML要素
2535-a-6 要求子XML要素、第6の要求子XML要素
2550 SIP INVITEメッセージ
2600 ブロック図
2605 中央サービス受信機モジュール
2610 テレマティクスメタデータシグナリングモジュール
2610-a テレマティクスメタデータシグナリングモジュール
2610-b テレマティクスメタデータシグナリングモジュール
2610-c テレマティクスメタデータシグナリングモジュール
2615 中央サービス送信機モジュール
2700 ブロック図
2705 テレマティクスメタデータモジュール
2705-a テレマティクスメタデータモジュール
2800 ブロック図
2805 適合サブモジュール
2810 要求サブモジュール
2810-a 要求サブモジュール
2900 フォーマット、SIP応答メッセージフォーマット
2900-a SIP応答メッセージ、SIP200(OK)メッセージ、SIP200(OK)シグナリングメッセージ、メッセージ、応答メッセージ
2905 要求ライン
2905-a ステータスライン
2910 ヘッダ
2910-a ヘッダ
2915 セッションデータのセット
2915-a セッションデータ
2920 テレマティクスメタデータのセット
2920-a テレマティクスメタデータ、メタデータ
2925-a-1 要求、第1の要求
2925-a-2 要求、第2の要求
2925-a-3 要求、第3の要求
2925-a-4 要求、第4の要求
2925-a-5 要求、第5の要求
2925-a-6 要求、第6の要求
3000 通信交換
3100 通信交換
3200 通信交換
3300 通信交換
3405 プロセッサモジュール
3410 メモリ
3415 ソフトウェア、コンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード、ソフトウェア/ファームウェアコード
3425 トランシーバモジュール
3430 アンテナ
3445 バス
3505 ネットワークインターフェースコントローラ(NIC)、プロセッサモジュール
3510 メモリ
3515 ソフトウェア、コンピュータ可読コンピュータ実行可能ソフトウェア/ファームウェアコード、ソフトウェア/ファームウェアコード
3545 バス
3600 方法
3700 方法
3800 方法
3900 図
3905 車両IVS
3910 テレマティクスサービスプロバイダ(TSP)
3915 PSAP
4000 図
4005 IVS
4010 ハンドセット
4015 PSAP
4100 図
4105 IVS
4110 PSAP
4200 図
4205 IVS、車両IVS
4210 TSP
4215 PSAP
4300 図
4305 IVS
4310 ハンドセット
4315 PSAP
4400 図
4405 IVS
4410 PSAP
4505 車両
4510 モバイルネットワークオペレータ(MNO)
4515 緊急サービスIPネットワーク(ESInet)
4525 ACN対応可能PSAP
4520 緊急サービスルーティングプロキシ(ESRP)
4600 図
4700 図
4800 図
4805 IVS
4810 eCall対応可能PSAP、PSAP
4900 図
4905 IVS
4910 NG-eCall対応可能PSAP、PSAP
5000 図
5100 図
5200 図
5300 図
5305 図
5400 図
5405 図
5500 図
5600 図
5605 IVS
5610 発信ネットワーク
5615 ESInet
5620 緊急サービスルーティングプロキシ(ESRP)
5625 NG-eCall対応可能PSAP、PSAP
5700 図
5800 図
5900 図
6000 図
6100 図
6200 図
6300 表
6400 表
6500 表
6600 表
Claims (15)
- 車両緊急呼システムにおけるワイヤレス通信のための方法であって、
通信セッションシグナリングプロトコルにより前記車両緊急呼システムにおける第1のエンドポイントから前記車両緊急呼システムにおける第2のエンドポイントにテレマティクス能力のセットを送信するステップと、
前記第1のエンドポイントが実施することが可能である少なくとも1つのアクションの実施を求める要求を前記第1のエンドポイントが受け入れる要求データ構造に対応する能力データ構造において、テレマティクス能力の前記セットを送信するステップと
を含む、方法。 - 前記要求データ構造のフォーマットと同等であるか、または前記要求データ構造の前記フォーマットにおいて1つまたは複数の構成要素、構造、データ表現またはプログラミング言語などを共有するように前記能力データ構造をフォーマットするステップ
をさらに含む、請求項1に記載の方法。 - 拡張マークアップ言語(XML)要素として前記能力データ構造をフォーマットするステップ
をさらに含む、請求項1に記載の方法。 - 前記少なくとも1つのアクションを定義する少なくとも1つの子XML要素を前記能力のXML要素データ構造に含めるステップ
をさらに含む、請求項3に記載の方法。 - 前記第1のエンドポイントは緊急呼車載システム(IVS)であり、前記第2のエンドポイントは緊急呼応答機関であり、テレマティクス能力の前記セットは、緊急呼の確立中または確立後に送信される、請求項1に記載の方法。
- 前記第1のエンドポイントは緊急呼車載システム(IVS)であり、前記第2のエンドポイントは緊急呼応答機関であり、前記方法はさらに、
前記緊急呼応答機関との緊急呼を確立するために招待およびデータセットを送信するステップと、
テレマティクス能力の前記セットの送信を求める前記緊急呼応答機関による要求に応答して、前記緊急呼が確立された後にテレマティクス能力の前記セットを送信するステップと
をさらに含む、請求項1に記載の方法。 - 車両緊急呼システムにおけるワイヤレス通信のための装置であって、
プロセッサと、
前記プロセッサと電子通信しているメモリと、
前記メモリに記憶された命令と
を含み、前記命令は前記プロセッサによって、
通信セッションシグナリングプロトコルにより前記車両緊急呼システムにおける第1のエンドポイントから前記車両緊急呼システムにおける第2のエンドポイントにテレマティクス能力のセットを送信し、
前記第1のエンドポイントが実施することが可能である少なくとも1つのアクションの実施を求める要求を前記第1のエンドポイントが受け入れる要求データ構造に対応する能力データ構造において、テレマティクス能力の前記セットを送信する
ように実行可能である、装置。 - 前記第1のエンドポイントは緊急呼車載システム(IVS)であり、前記第2のエンドポイントは緊急呼応答機関である、請求項7に記載の装置。
- 前記少なくとも1つのアクションは、
テレマティクスデータを収集すること、テレマティクスデータを送信すること、車両の状態に影響を与えるアクションを実施すること、車両の構成要素をアクティブ化すること、車両の構成要素を非アクティブ化すること、車両のイグニションをオフにすること、車両のイグニションをオンにすること、車両の燃料供給をオフにすること、車両の燃料供給をオンにすること、一次バッテリもしくは他のバッテリもしくは他の電源を切断すること、一次バッテリもしくは他のバッテリもしくは他の電源を接続すること、ドアの鍵を開けること、ドアの鍵を閉めること、車両のクラクションをアクティブ化すること、外部可聴音をアクティブ化すること、車両のライトをアクティブ化すること、車両の点滅灯をアクティブ化すること、パワーウィンドウを作動させること、録音メッセージを再生すること、メディアをレンダリングすること、テキストメッセージを表示すること、カメラをアクティブ化すること、カメラを非アクティブ化すること、またはそれらの組合せ
のうちの1つまたは複数を含む、請求項7に記載の装置。 - 前記メモリは、前記プロセッサによって、
前記少なくとも1つのアクションに対応するパラメータをテレマティクス能力の前記セットに含めるステップであって、前記パラメータは、前記少なくとも1つのアクションのサポートされる態様を定義する、ステップ
を行うように実行可能である命令をさらに含む、請求項7に記載の装置。 - 前記メモリは、前記プロセッサによって、
前記緊急呼IVSが実施することが可能である緊急呼関連アクションのサブセットをテレマティクス能力の前記セットに含めるステップであって、前記サブセットは、前記緊急呼IVSのユーザによって必要とされる支援のカテゴリまたは前記車両の状態のうちの少なくとも1つに少なくとも部分的に基づいて決定される、ステップ
を行うように実行可能である命令をさらに含む、請求項8に記載の装置。 - 前記メモリは、前記プロセッサによって、
アクションの実施を求める要求を前記緊急呼応答機関から受信するステップであって、前記要求はテレマティクス能力の前記セットに少なくとも部分的に基づく、ステップと、 前記アクションを実施するステップと
を行うように実行可能である命令をさらに含む、請求項8に記載の装置。 - 前記メモリは、前記プロセッサによって、
前記緊急呼応答機関との緊急呼を確立するために招待およびデータセットを送信するステップと、
前記招待に応答して能力の前記セットの送信を求める前記応答機関からの要求を受信するステップと、
前記招待への前記応答の確認応答とともにテレマティクス能力の前記セットを送信するステップと
を行うように実行可能である命令をさらに含む、請求項8に記載の装置。 - 車両緊急呼システムにおけるテレマティクスデータを通信するための方法であって、
通信セッションシグナリングプロトコルにより前記車両緊急呼システムにおける第2のエンドポイントにおいて、前記車両緊急呼システムにおける第1のエンドポイントからテレマティクス能力のセットを受信するステップと、
前記第1のエンドポイントが実施することが可能である少なくとも1つのアクションの実施を求める要求を前記第1のエンドポイントが受け入れる要求データ構造に対応する能力データ構造において、テレマティクス能力の前記セットを受信するステップと、
アクションの実施を求める要求を前記第1のエンドポイントに送信するステップであって、前記アクションの実施を求める前記要求は、前記受信されたテレマティクス能力のセットに少なくとも部分的に基づく、ステップと
を含む、方法。 - 車両緊急呼システムにおけるテレマティクスデータを通信するための装置であって、
プロセッサと、
前記プロセッサと電子通信しているメモリと、
前記メモリに記憶された命令と
を含み、前記命令は前記プロセッサによって、
通信セッションシグナリングプロトコルにより前記車両緊急呼システムにおける第2のエンドポイントにおいて、前記車両緊急呼システムにおける第1のエンドポイントからテレマティクス能力のセットを受信するステップと、
前記第1のエンドポイントが実施することが可能である少なくとも1つのアクションの実施を求める要求を前記第1のエンドポイントが受け入れる要求データ構造に対応する能力データ構造において、テレマティクス能力の前記セットを受信するステップと、
アクションの実施を求める要求を前記第1のエンドポイントに送信するステップであって、前記アクションの実施を求める前記要求は、前記受信されたテレマティクス能力のセットに少なくとも部分的に基づく、ステップと
を行うように実行可能である、装置。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201462028234P | 2014-07-23 | 2014-07-23 | |
| US62/028,234 | 2014-07-23 | ||
| US201462068590P | 2014-10-24 | 2014-10-24 | |
| US62/068,590 | 2014-10-24 | ||
| PCT/US2015/041817 WO2016014844A1 (en) | 2014-07-23 | 2015-07-23 | Vehicle-initiated emergency calls |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2017524298A JP2017524298A (ja) | 2017-08-24 |
| JP2017524298A5 JP2017524298A5 (ja) | 2018-08-23 |
| JP6630719B2 true JP6630719B2 (ja) | 2020-01-15 |
Family
ID=53794509
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2017502996A Active JP6630719B2 (ja) | 2014-07-23 | 2015-07-23 | 車両開始型緊急呼 |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US10057750B2 (ja) |
| EP (1) | EP3172904B1 (ja) |
| JP (1) | JP6630719B2 (ja) |
| KR (1) | KR102058276B1 (ja) |
| CN (1) | CN106537931B (ja) |
| BR (1) | BR112017000648A2 (ja) |
| CA (1) | CA2952835C (ja) |
| WO (1) | WO2016014844A1 (ja) |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9521526B2 (en) * | 2012-09-28 | 2016-12-13 | Qualcomm Incorporated | Controlling the transfer of telematics data using session related signaling |
| US10111078B2 (en) * | 2014-12-18 | 2018-10-23 | Qualcomm Incorporated | Techniques to support emergency calls with over-the-top service provider |
| US9813540B2 (en) * | 2015-01-27 | 2017-11-07 | Hyundai Motor Company | Method of computing statistical vehicle data using mobile terminal and apparatus for performing the same |
| US10547730B2 (en) * | 2015-11-11 | 2020-01-28 | Ford Global Technologies, Llc | Method and apparatus for vehicular emergency call |
| KR20170056337A (ko) * | 2015-11-13 | 2017-05-23 | 현대자동차주식회사 | 차량 및 그 제어 방법 |
| KR101780286B1 (ko) * | 2015-12-09 | 2017-09-21 | 현대자동차주식회사 | Avn의 동작 방법, avn, 이를 포함하는 차량 |
| US10499229B2 (en) * | 2016-01-24 | 2019-12-03 | Qualcomm Incorporated | Enhanced fallback to in-band mode for emergency calling |
| US10623914B2 (en) | 2016-02-17 | 2020-04-14 | Tracfone Wireless, Inc. | Device, system, and process for providing real-time short message data services for mission critical communications |
| CN105761425B (zh) * | 2016-03-24 | 2019-09-03 | 腾讯科技（深圳）有限公司 | 求救方法、系统及装置 |
| US10863315B2 (en) * | 2016-06-07 | 2020-12-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic allocation and de-allocation of MSISDN to vehicles |
| US9942702B1 (en) | 2016-07-14 | 2018-04-10 | Sprint Communications Company L.P. | Device location determination when attached to one or more wireless repeaters |
| US10187923B2 (en) * | 2016-09-22 | 2019-01-22 | T-Mobile Usa, Inc. | Provisioning access points to mobile devices for emergency calls |
| WO2018066731A1 (ko) | 2016-10-07 | 2018-04-12 | 삼성전자 주식회사 | 통화 기능을 수행하는 단말 장치 및 방법 |
| GB2559139B (en) * | 2017-01-26 | 2020-07-29 | Jaguar Land Rover Ltd | Apparatus and method for incident response |
| US11562606B2 (en) | 2017-02-02 | 2023-01-24 | Cyber Physical Systems LLC | Accident-severity scoring device, method, and system |
| US10129326B1 (en) * | 2017-06-23 | 2018-11-13 | T-Mobile Usa, Inc. | Emergency calling with a telephony application |
| EP3439353A1 (en) * | 2017-08-04 | 2019-02-06 | Deutsche Telekom AG | Method for performing end-to-end testing of an emergency call or quality management system or an emergency call or quality management functionality, mobile communication network, and system, program and computer program product |
| PL3462767T3 (pl) * | 2017-09-29 | 2021-12-20 | Deutsche Telekom Ag | Sposób przeprowadzania testu systemu połączeń alarmowych, sieć komunikacji mobilnej, program i produkt w postaci programu komputerowego |
| US10813143B2 (en) | 2017-11-09 | 2020-10-20 | Ford Global Technologies, Inc. | Multiple event-based vehicle communications |
| CN108012246A (zh) * | 2017-12-07 | 2018-05-08 | 三星电子（中国）研发中心 | 一种车载紧急呼叫系统及其提供实时生命体征数据的方法 |
| US10887737B2 (en) | 2017-12-21 | 2021-01-05 | Polaris Industries Inc. | Vehicle-to-vehicle communication system |
| CN108337291B (zh) * | 2017-12-28 | 2021-08-17 | 蔚来(安徽)控股有限公司 | 车辆远程服务系统和方法、处理装置和存储装置 |
| US10917771B2 (en) * | 2018-01-08 | 2021-02-09 | Ford Global Technologies, Llc | System for smart child seat vehicle integration |
| US10609541B1 (en) | 2018-04-27 | 2020-03-31 | Mbit Wireless, Inc. | Method and apparatus for emergency alert in client devices |
| FR3085094A1 (fr) * | 2018-08-20 | 2020-02-21 | Psa Automobiles Sa | Procede de partage automatique des telecommunications entre un boitier telematique embarque dans un vehicule automobile et un telephone mobile externe |
| KR102110191B1 (ko) * | 2018-08-22 | 2020-05-13 | 주식회사텔러스 | 확장 사고 정보를 전송하는 차량 긴급 구난 장치 및 그 방법 |
| SE542551C2 (en) * | 2018-10-05 | 2020-06-02 | Skyresponse Ab | Method, Receiving interface, computer program and computer program product for grouping incoming alarm calls |
| US10820349B2 (en) | 2018-12-20 | 2020-10-27 | Autonomous Roadway Intelligence, Llc | Wireless message collision avoidance with high throughput |
| US10816635B1 (en) | 2018-12-20 | 2020-10-27 | Autonomous Roadway Intelligence, Llc | Autonomous vehicle localization system |
| US10814474B2 (en) | 2018-12-20 | 2020-10-27 | Autonomous Roadway Intelligence, Llc | Identification and localization of mobile robots |
| US11218584B2 (en) * | 2019-02-22 | 2022-01-04 | Rapidsos, Inc. | Systems and methods for automated emergency response |
| DE102019202662B4 (de) | 2019-02-27 | 2021-01-14 | Volkswagen Aktiengesellschaft | Verfahren zur Überprüfung der Funktionsfähigkeit einer Notrufeinrichtung eines Kraftfahrzeugs sowie Kraftfahrzeug zur Durchführung des Verfahrens |
| CN113728589B (zh) * | 2019-04-25 | 2022-10-28 | 微芯片技术股份有限公司 | 改变有线局域网中的主节点以及相关系统、方法和设备 |
| US10939471B2 (en) | 2019-06-13 | 2021-03-02 | David E. Newman | Managed transmission of wireless DAT messages |
| US10820182B1 (en) | 2019-06-13 | 2020-10-27 | David E. Newman | Wireless protocols for emergency message transmission |
| US10713950B1 (en) | 2019-06-13 | 2020-07-14 | Autonomous Roadway Intelligence, Llc | Rapid wireless communication for vehicle collision mitigation |
| CN110717999B (zh) * | 2019-10-08 | 2023-08-29 | 北京百度网讯科技有限公司 | 通信方法、装置、电子设备及存储介质 |
| KR20210054162A (ko) | 2019-11-05 | 2021-05-13 | 삼성전자주식회사 | 호 연결 시간을 단축하는 방법 및 이를 위한 전자 장치 |
| US20210192862A1 (en) * | 2019-12-18 | 2021-06-24 | Toyota Motor Engineering & Manufacturing North America, Inc. | Automated operator interface |
| US11070670B1 (en) * | 2020-01-16 | 2021-07-20 | RapidDeploy, Inc. | Platform for emergency event subscriptions |
| EP3910991B1 (en) * | 2020-05-15 | 2022-08-17 | Deutsche Telekom AG | PERFORMING A TEST OF AN EMERGENCY CALL (OR QUALITY MANAGEMENT FUNCTIONALITY) BASED ON A PREDEFINED TEST IDENTIFIER USED FOR INITIATING A CORRESPONDING PACKET-SWITCHED CALL BY A TEST MOBILE COMMUNICATION DEVICE REGISTERED
WITH A PRIVATE OR NON-PUBLIC MOBILE COMMUNICATION NETWORK |
| JP7518693B2 (ja) * | 2020-07-31 | 2024-07-18 | 株式会社Subaru | 車両の自動緊急通報システムに用いられるサーバ装置 |
| JP7458265B2 (ja) * | 2020-07-31 | 2024-03-29 | 株式会社Subaru | 自動通報機能を有する車両 |
| DE202021105162U1 (de) * | 2020-09-25 | 2021-11-29 | Manuel Eckert | System zur Übermittlung positionsbezogener Notrufe von bzw. aus Fahrzeugen zu einer Leitstelle und zur Kommunikation zwischen Fahrzeuginsassen und einer Leitstelle |
| US11665211B2 (en) * | 2020-11-02 | 2023-05-30 | Mediatek Singapore Pte. Ltd. | Apparatuses and methods for call addition control |
| WO2022125863A1 (en) * | 2020-12-11 | 2022-06-16 | RapidDeploy, Inc. | Outbound sms notifications to emergency callers |
| US11558730B1 (en) * | 2021-05-13 | 2023-01-17 | T-Mobile Usa, Inc. | Providing user equipment (UE) location information during an emergency call |
| EP4096181B1 (en) * | 2021-05-25 | 2023-11-15 | Unify Patente GmbH & Co. KG | Method and network system for defeating media-coordinated attacks on emergency call networks |
| US12062275B2 (en) | 2021-12-01 | 2024-08-13 | Hartford Fire Insurance Company | System and method for telematics accounts on-the-ground safety |
| KR20240038375A (ko) * | 2022-09-16 | 2024-03-25 | 삼성전자주식회사 | 긴급 통화를 위한 알림을 제공하는 디바이스 및 그 방법 |
| CN115701894B (zh) * | 2022-12-27 | 2023-10-24 | 蔚来汽车科技(安徽)有限公司 | 通话方法、通话系统及计算机存储介质 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8682279B2 (en) * | 2004-05-07 | 2014-03-25 | Interdigital Technology Corporation | Supporting emergency calls on a wireless local area network |
| EP2189012A1 (en) * | 2007-08-15 | 2010-05-26 | Telefonaktiebolaget LM Ericsson (PUBL) | Method and system for adding information to an emergency call |
| DE102008015840A1 (de) * | 2007-12-06 | 2009-06-10 | Continental Teves Ag & Co. Ohg | Fahrzeugnotruf zur Übermittlung zusätzlicher oder geänderter Daten |
| US9426293B1 (en) * | 2008-04-02 | 2016-08-23 | United Services Automobile Association (Usaa) | Systems and methods for location based call routing |
| US8265022B2 (en) * | 2009-02-10 | 2012-09-11 | Apple Inc. | Apparatus and methods for transmission of emergency call data over wireless networks |
| US8391829B2 (en) * | 2010-06-10 | 2013-03-05 | General Motors Llc | Remote vehicle data access during a multi-way call with a vehicle telematics unit |
| US8787869B2 (en) * | 2011-07-20 | 2014-07-22 | Airbiquity Inc. | Wireless emergency call (ECALL) devices and ECALL service subscription management |
| US9521526B2 (en) | 2012-09-28 | 2016-12-13 | Qualcomm Incorporated | Controlling the transfer of telematics data using session related signaling |
| US20150109997A1 (en) * | 2013-10-21 | 2015-04-23 | Alexander Sirotkin | Apparatus, system and method of interfacing between a cellular manager and a wlan access device |
-
2015
- 2015-07-23 CN CN201580039919.4A patent/CN106537931B/zh active Active
- 2015-07-23 BR BR112017000648A patent/BR112017000648A2/pt not_active IP Right Cessation
- 2015-07-23 US US14/807,663 patent/US10057750B2/en active Active
- 2015-07-23 KR KR1020177001876A patent/KR102058276B1/ko active IP Right Grant
- 2015-07-23 CA CA2952835A patent/CA2952835C/en active Active
- 2015-07-23 EP EP15748121.9A patent/EP3172904B1/en active Active
- 2015-07-23 JP JP2017502996A patent/JP6630719B2/ja active Active
- 2015-07-23 WO PCT/US2015/041817 patent/WO2016014844A1/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| CA2952835C (en) | 2021-02-16 |
| BR112017000648A2 (pt) | 2017-11-14 |
| US20160029197A1 (en) | 2016-01-28 |
| WO2016014844A1 (en) | 2016-01-28 |
| KR102058276B1 (ko) | 2019-12-20 |
| US10057750B2 (en) | 2018-08-21 |
| CN106537931B (zh) | 2020-03-03 |
| CA2952835A1 (en) | 2016-01-28 |
| KR20170033312A (ko) | 2017-03-24 |
| CN106537931A (zh) | 2017-03-22 |
| EP3172904B1 (en) | 2019-05-01 |
| JP2017524298A (ja) | 2017-08-24 |
| EP3172904A1 (en) | 2017-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6630719B2 (ja) | 車両開始型緊急呼 | |
| JP6126228B2 (ja) | セッション関連シグナリングを使用するテレマティクスデータの転送の制御 | |
| US10111078B2 (en) | Techniques to support emergency calls with over-the-top service provider | |
| JP6086508B2 (ja) | ワイヤレスネットワークを経て非常コールデータを送信するための装置及び方法 | |
| US8532606B2 (en) | Method and system for providing an emergency location service using interoperability between IMS core and access network | |
| Oorni et al. | In-vehicle emergency call services: eCall and beyond | |
| CN103416100B (zh) | 用于支持紧急通信的重新建立的方法、设备、系统和计算机程序产品 | |
| CN110945963A (zh) | 用于改善针对处于仅eCall模式的移动设备的移动性的系统和方法 | |
| Rebahi et al. | Towards a next generation 112 testbed: The EMYNOS ESInet | |
| WO2017000132A1 (en) | Techniques to support emergency calls with over-the-top service provider | |
| Gellens et al. | Next-Generation Vehicle-Initiated Emergency Calls | |
| Tschofenig | ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen Expires: March 25, 2017 NeuStar, Inc. | |
| Gellens et al. | Next-Generation Vehicle-Initiated Emergency Calls, draft-ietf-ecrit-car-crash-12. txt | |
| Gellens et al. | RFC 8148: Next-Generation Vehicle-Initiated Emergency Calls |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170124 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180709 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180709 |
|
| A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20190613 |
|
| A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20190718 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190724 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190729 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20191011 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20191111 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20191209 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6630719 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |