专利名称：通过无线网络传送紧急呼叫数据的装置和方法
技术领域：
本发明一般地涉及无线通信系统领域。更具体地，在一个示例性方面，本发明旨在无线网络中紧急或类似的呼叫数据的传送。
背景技术：
数字无线系统，例如蜂窝移动通信系统，为用户提供了实时和非实时服务。实时服务的示例包括例如语音电话呼叫和视频电话呼叫，而非实时服务包括各种类型的消息服务 (例如SMS，MMS，电子邮件)或在席服务(presence service)(例如“聊天”)。数字蜂窝移动通信可以以电路交换网络架构(CS域)或以包交换网络架构(PS域)来实现。CS域呼叫需要在用户数据交换能够发生之前，创建“电路”或持续连接；例如来交换数字语音数据。电路交换网络通过移动蜂窝网络和CS域核心(骨干)网络将一个终端连接至另一终端。通过各种已知的控制协议在所涉及的网络单元之间执行连接建立。一旦连接被建立，由一个终端传送至蜂窝移动网络的数字用户数据沿连接路由通过网络被传输至另一终端。电路交换路径在连接的持续期间保持不变；在呼叫中间不能进行修改来改变该呼叫的路由。PS域呼叫(诸如VoIP呼叫)不具有类似于CS域呼叫的“硬连接”。相反，PS域呼叫在网络级被灵活地路由；下层的传输路由没有被预定义并且可以动态改变。PS域呼叫被打包(packetize)并通过网络元素的“云”而逐包地传输；因此，每个数据包包括源和目的地终端的可路由网络地址(例如因特网协议或IP地址)。包交换网络的典型实现方式可以在每个传送数据包中嵌入因特网协议(IP)路由信息。这种路由通常被称作IP路由。在网络级看来，IP路由是无连接的；然而，PS域呼叫在数据传输之前可能需要(并且通常执行) 在应用/会话层上建立连接，以协商各种参数，诸如类型、质量、格式、交换的数据和/或质量的编码、带宽、以及下层的传输流的其它参数。CS和PS域具有与其结构和运行方法直接相关的多个截然不同之处。如上所述， CS域呼叫在整个运行过程中保持“固定”电路；因此，CS呼叫对于其数据传送具有在一定容差内的合理的一致的定时(因为数据传送是沿着具有固定传送参数的相同路由)。此外， CS呼叫天生是线性的；每个传送按顺序地跟随其前任。PS域呼叫明显不同于CS域模型，这是由于至其目的地的包的灵活路由、不规律的带宽或容量、以及数据被路由经过的中继段 (hop)集合的不同延迟。因此，与数据包相关的定时和延迟对于PS呼叫是在很宽的范围上变化的。因此，携带诸如语音或视频数据之类的实时数据的数据包通常嵌入在使得能够提取定时信息的协议中。例如，通常使用的实时传输协议(RTP)包含这样的定时信息(以及其它信息)，并且通常被用于蜂窝移动网络的PS域中的实时语音和视频数据传送。RTP和RTCP都旨在应用在处理更广泛传输层要求的系统中，这些要求诸如寻址、检错和/或纠错机制。RTP和RTCP 包所嵌入的最通常使用的协议是用户数据报协议(UDP)和传输控制协议(TCP)。其不同之一在于，TCP提供具有纠错机制的可靠传输和QoS (服务质量)，而UDP不提供这样的保证。 TCP的附加的功能需要更多的消息开销，以及网络部件中的“状态存储”。UDP更为简单并且更加高效，但是可能会取决于其载体而有损失并且不规律。UDP不需要任何握手来发送或接收段，因此UDP也可以被一般地归类为“无连接”。RTP通常与UDP结合使用，作为具有互补特征的两个协议。在大部分的应用情况下，TCP的附加可靠性在RTP上将被浪费；保证正确递送所需的额外时间将抵消纠错的任何好处(在大部分RTP系统中，迟到的包被丢弃)。紧急和其它高优先级呼叫蜂窝移动网络中的正常服务(例如语音呼叫)仅在某些接受先决条件下被建立。 这些先决条件可以包括认证用户(关于身份)、就特定服务授权用户、检查用户的账户状态、以及运营商向该用户授予所需资源的能力或意愿。根据网络中存在的条件以及移动终端关于先决条件(例如，认证、授权和结算)的状态，呼叫建立时间可以被延迟或该呼叫可以被完全拒绝。在高优先级呼叫(例如请求紧急服务帮助的紧急呼叫，诸如火警、医疗紧急情况或呼叫警察)的情况下，紧急呼叫可以被给予较高的优先级来处理以防止任何延迟或阻碍。紧急呼叫可以被请求或被检测；终端在呼叫建立请求中指出其需要建立紧急呼叫，或者，网络可以确定目的地址是对紧急服务的请求(例如通过用户拨打911等)。在任一情况下，在已经接收到建立紧急呼叫的请求之后，网络以高优先级对待该请求，并且加速处理。除了建立紧急呼叫之外，网络还有可能可以启动其它处理来提供具有关于紧急呼叫的发起者的附加信息(诸如地理位置等)的端点。许多蜂窝网络已经定义了可以使用最小的先决条件集合(例如，通过避免需要用户被认证等)来建立的“紧急呼叫”。eCall 和增强 911(E911)根据相关标准团体和政府机构的各种指导，紧急通信的另一分类包括所谓的 “eCall”(欧洲)或增强911呼叫(北美)，后者还包括无线E911和VoIP E911。例如， 见 2004 年 5 月 28 曰 eSafety Forum 禾口 eCall Driving Group 的名为"Memorandum of Understanding for Realisation of Interoperable In-Vehicle eCall，，的欧洲谅角军备忘录(European Commission Memorandum of Understanding)以及相关实施标准，其全部内容通过引用结合于此，其描述了欧洲eCall系统。例如，在上述欧洲系统中，eCall是来自车载系统(IVS)的紧急呼叫，其可以在检测到诸如汽车事故之类的事件之后，由车辆的乘客手动产生或由IVS自动产生。eCall由 IVS经过第二代QG)或第三代(3G)移动网络发送至公共安全应答点(PSAP)。与紧急呼叫一起，描述相关情况的最小数据集(MSD)被发送至PSAP ；例如，由汽车自动生成或从汽车获得的信息。在MSD中给出的信息可以包括车的高精度位置(通常使用内置的全球导航卫星系统(GNSS)收发器测量)、乘客的数量、该车是否由于事故已经翻转等。注意，初始的eCall或E911服务的现有技术实施方式是在CS域中操作。图1中示出了示例性MSD的格式。如图所示，MSD 100的大小可以改变，因为MSD 中的信息元素的一部分是可选的。具体的，可选数据(Optional Data)字段102的内容仅需要为可扩展标记语言(XML)代码；允许该字段的长度在规定的范围内变化。然而，MSD 100 的最大数据大小是一百四十(140)字节。MSD的另一替代物是完整数据集(FSD)，其可以在下层传输机制允许更大尺寸的 eCall数据被传送的情况下被发送。因此，如在此所使用的，术语“eCall数据”表示MSD、 FSD或在eCall连接中被传送的任何其它数据(其可以与语音数据相协调)。数据(例如MSD或FSD)的传送存在多个可能的选项。这些选项包括⑴短消息服务(SMS) ； (ii)用户到用户信令(UUS) ； (iii)非结构化补充服务数据(USSD) ； (iv)全球移动通信系统(GSM)CS数据；(ν)双音多频(DTMF)；以及(vi)带内调制解调/信令应用。 然而，这些方案都不能提供足够的能力来以及时的并且无需在包交换网络上重定向或重路由的方式与紧急呼叫相结合地传输最小数据集。因此，需要能够解决这些缺点的改进的装置和方法。
发明内容
本发明通过提供用于在无线(例如蜂窝)通信网络中传送紧急或类似呼叫数据的改进的装置和方法来满足上述需求。在本发明的第一方面，披露了一种在适于包交换操作的网络中提供紧急呼叫的方法。在一个实施例中，所述网络提供基本实时的包交换操作，以及所述紧急呼叫包括具有第一流和一个或多个第二流的复合流。第一流以基本连续的方式被提供，复合流至少使用第一流和一个或多个第二流形成。会话被建立；该会话适于路由该复合流，后者通过该会话被发送。在一个变型中，该会话包括使用会话发起协议建立的实时会话。在另一变型中，第一流包括多个语音包，以及一个或多个流包括多个数据包。基本连续的流是通过基本连续地编码语音信号以产生语音包而提供的。在又一变型中，提供一个或多个第二流是以基本不连续或非持续的方式被执行的，这种基本不连续的方式仅仅周期性或间歇性地提供来自至少一个源的数据。在再一变型中，复合流、第一流和一个或多个第二流被打包，并且通过将第一流的一个或多个包与第二流的一个或多个包穿插来形成所述复合流。在又一变型中，使用多路复用算法来执行穿插。在另一变型中，至少使用第一流和一个或多个第二流形成复合流是通过在多个 RTP包中布置第一流的至少一些部分、在多个RTCP包中布置一个或多个第二流的至少一些部分、以及将RTP包与RTCP包进行穿插来实现的。在又一变型中，网络包括3GPP IMS兼容的蜂窝网络，并且所述会话是使用会话发起协议(SIP)建立的。在本发明的第二方面，公开了一种在能够进行包交换操作的网络中进行紧急呼叫的装置。在一个实施例中，该装置包括麦克风(适于连续捕获语音并将所述语音数字分解为多个第一包)；一个或多个传感器，适于将与该装置或承载该装置的平台相关的一个或多个参数编码为一个或多个第二包；无线发射器，适于通过无线网络发送多个包；与该发射器进行数据通信的处理器；以及计算机可读装置，包括适于包含计算机程序的介质，所述计算机程序具有多个指令。这些多个指令在被处理器执行时，至少部分地基于多个第一包与一个或多个第二包的穿插而产生用于发送的多个包。这些指令还建立会话，该会话适于不存储地路由所穿插的多个第一包和一个或多个第二包，以及通过无线发射器发送所穿插的多个包。在一个变型中，产生用于发送的多个包包括产生多个第三包，该第三包从所穿插的多个第一包和一个或多个第二包得出。在另一变型中，该装置还包括无线接收器，其适于接收来自无线网络的多个包；以及扬声器，其适于由所接收的多个包数字合成语音。在又一变型中，该装置还包括扬声器子系统；接收器装置，适于接收来自无线网络的多个包；以及分离装置，适于将从网络接收的多个包分离成语音分量和数据分量。分离装置适于将语音分量提供至扬声器子系统，由数据分量确定一个或多个第二包的接收状态。在再一变型中，该装置基本上被容纳在适于运送一个或多个乘客的车辆内。在又一变型中，该装置包括基于卫星的位置确定接收器(例如，GPS接收器)。该一个或多个传感器可以包括(i)适于检测碰撞的加速度计；(ii)适于检测车辆翻转的加速度计；和/或(iii)适于确定车辆占用情况的传感器。在另一变型中，无线网络是与3GPP IP多媒体核心网络子系统(IMS)要求兼容的蜂窝网络，并且所述会话是使用会话发起协议(SIP)建立的。在又一变型中，多个第一包与一个或多个第二包的穿插包括将多个RTP包与一个或多个RTCP包穿插，该一个或多个RTCP包包括最小数据集(MSD)。在本发明的第三方面，公开了一种被配置为在包交换网络中接收紧急呼叫的网络装置。在一个实施例中，该装置包括网络接口，其适于通过与该装置进行数据通信的互联网协议(IP)网络接收第一多个包和第二多个包；与接口进行数据通信的处理器；以及计算机可读装置，包括适于包含计算机程序的介质，所述计算机程序具有多个指令。当由处理器执行时，这些指令接收对通信会话的请求(该会话适于帮助传输第一多个包和第二多个包)，建立会话，通过会话接收第一多个包和第二多个包，从第一多个包中提取基本实时的用户数据，以及从第二多个包中提取紧急情况相关数据。在一个变型中，网络装置还包括音频模块，该音频模块具有扬声器并且适于通过扬声器播放出音频，所述音频从所提取出的基本实时的用户数据中得出。在另一变型中，包交换网络包括3GPP IP多媒体核心网络子系统(IMQ，并且所述会话是至少使用会话发起协议(SIP)建立的。在另一变型中，第一多个包和第二多个包分别是相穿插的RTP包和RTCP包。在另一变型中，RTCP包的至少一部分包括最小数据集(MSD)。在另一变型中，紧急情况相关数据包括最小数据集(MSD)。在又一变型中，该网络装置是公共安全应答点(PSAP)的一部分。在本发明的第四方面，公开了一种在能够进行包交换操作的网络中进行高优先级呼叫的方法。在一个实施例中，该方法包括提供基本连续的用户数据流和涉及高优先级事件的多个数据。用户数据流的至少一些部分被布置在第一打包协议结构中，涉及高优先级事件的数据的至少一些部分被布置在第二打包协议结构中。第一和第二协议结构是穿插的，并且复合流经由通信会话通过网络被发送。在一个变型中，高优先级呼叫是紧急呼叫，涉及高优先级事件的数据包括最小数据集(MSD)。在另一变型中，网络是3G蜂窝网络，并且所述发送是通过经由会话建立协议首先建立至少一个会话来执行的。在另一变型中，第一打包协议是实时传输协议，第二打包协议包括实时控制协议。在又一变型中，该方法根据事件由基本上布置在陆地车辆中的发送装置基本上自动地发起。该事件可以包括例如(i)车辆碰撞；( )车辆翻转；和/或(iii)车辆起火。
在另一变型中，用户数据包括视频和语音数据两者。在另一变型中，涉及高优先级事件的数据包括在呼叫时第一实体的基本准确的位置数据，该准确的位置数据不仅仅基于网络地址。在本发明的第五方面，公开了适于传送紧急呼叫的电信装置。在一个实施例中，该传送使用可靠的打包协议传输，并且一个或多个紧急呼叫被发送至适于从网络接收打包数据并处理该数据的实体。该装置包括无线发射器，以及与该发射器通信并且适于使打包数据在网络上传送的装置。打包数据包括携带基本实时的用户数据的第一包，以及与第一包穿插并携带紧急情况相关数据的第二包，第一包和第二包根据不同协议被格式化。这些不同协议中的每一个都支持适于提供上述可靠传输的服务质量要求。在一个变型中，紧急情况相关数据包括在呼叫时所述电信装置的准确位置数据 (其可能基于或可能不基于网络地址)。在本发明的第六方面，公开了一种将紧急呼叫从源路由至目的地的方法。在一个实施例中，该方法确定是否电路交换和包交换网络路由都可用于路由该呼叫；如果两个路由都可用，则根据至少一个选择标准来评估所述路由中的至少一个。至少部分基于该评估来选择所述路由之一，并且通过所选的路由来路由该呼叫。如果仅包交换路由可用，则通过包交换路由来路由该呼叫。在本发明的另一方面，公开了通过多模式(例如能够CS和PS的)无线网络来路由紧急数据的网络控制器和相关方法。在一个实施例中，该网络控制器包括适于基于一个或多个标准来评估两个选项(CS或PS)中的哪个最优并且然后通过该域来路由数据的逻辑器。例如，CS域可能由于技术或其它原因不可用，因此PS域eCall将被选择。在本发明的又一方面中，公开了一种具有存储介质的计算机可读装置。在某些变型中，该装置采用硬盘驱动器(HDD)、CD-ROM、或程序或数据存储集成电路(IC)的形式，并且存储实现在此描述的功能的各方面的一个或多个计算机程序。本领域的技术人员通过参考附图和下面给出的示例性实施例的具体描述，将立刻认识到本发明的其它特征和优点。
图1是与现有技术的最小数据集(MSD)包相关的包结构的图形示意。图2是示出了根据本发明的用于将紧急呼叫数据嵌入在实时语音呼叫中的一般化紧急呼叫过程的一个实施例的逻辑流程图。图2A是示 出了根据本发明的用于路由紧急呼叫数据的域仲裁/选择过程的一个实施例的逻辑流程图。图3示出了根据现有技术的一般的实时协议(RTP)应用包。图3A示出了根据本发明的适于为车载系统(IVS)提供紧急呼叫服务的实时协议 (RTP)应用包的包格式的一个示例性实施例。图3B示出了适于为车载系统(IVS)提供紧急呼叫服务的实时协议(RTP)应用包的包格式的又一个示例性实施例，示出了多个具有预定义值的示例性可设置字段。图3C示出了适于为车载系统(IVS)提供紧急呼叫服务的实时协议(RTP)应用包的包格式的另一个示例性实施例，示出了适于建立包排序的字段。图3D示出了适于为车载系统(IVS)提供紧急呼叫服务的实时协议(RTP)应用包的可扩展包格式的一个实施例。图4图示了根据本发明的基于会话发起协议(SIP)的呼叫建立过程的一个示例性实施例，适于提供车载系统(IVS)的紧急呼叫服务。图5是使用根据本发明的一个实施例的方法和装置的与IVS通信的示例性蜂窝 PSAP系统的图形示意。图6A是示出了根据本发明的PSAP装置的一个实施例的框图。图6B是示出了根据本发明的布置在陆地车辆(汽车)内的IVS装置的一个实施例的框图。
具体实施例方式现在参考附图，所有附图中类似的标号表示类似的部件。概述除了其它内容之外，本发明公开了提供与高优先级呼叫相关联的有用数据的方法和装置。在一个实施例中，数据是嵌入在包括紧急呼叫(eCall)的语音数据流的RTP控制协议(RTCP)包内的最小数据集(MSD)。所描述的装置和方法用于通过使用与语音数据相同的传输连接来将MSD数据部分可靠地从终端(IVS)发送至公共安全应答点(PSAP)。此外， 如果需要，MSD数据包可以被修改或改变，但是语音数据包括保持原样。在一方面，本发明还有利地使得当前蜂窝网络配置能够使用，以自然从电路交换 (CS)服务演进至包交换(PS)服务，而且不需要显著修改就能支持紧急服务基础结构。此夕卜，这样的实施方式适于跨CS域和PS域的各种等级的系统。 在一个实施例中，已经使用RTP用于定时、封装和其它目的的包交换语音(或其它实时数据)连接被充分利用。具体的，RTP包流被周期性地嵌入RTP控制协议(RTCP)包； 这样的RTCP包为每个参与方提供关于其它参与方的相关信息，包括诸如接收质量和源描述之类的参数。 在另一变型中，诸如可靠数据传送、纠错、重传和/或数据恢复等包交换数据传输的优点被充分利用以与MSD数据包一起使用。与将数据传送与语音封装在一起的其它方法 (这些方法通常将数据流连接到语音数据流的前缀或后缀)不同，“穿插(interspersing)” 方法被应用在RTCP协议的环境中；即，数据流穿插在语音流中，因此使得诸如持续更新MSD、多次重传MSD等的特征可以被实现。在另一方面，所公开的装置和方法特别适于在蜂窝网络的现有框架中运行。根据蜂窝网络所带来的限制，用于标准化的eCall数据传送的定时约束必须被观察到。有利的是，不需要对现存的协议栈进行修改以支持各种语音编码器数据和/或技术。尽管所公开的本发明使得非语音数据能够通过网络部件被修改，但是对于正确的系统操作不一定需要这样的修改。然而，更重要的是，语音数据保持被分成包，并且能够不修改地被发送，以防止与代码转换或其它这样的处理伴随而来的错误或由其导致的错误。在另一有利方面，数据的路由在相关实体(例如，在eCall的情况下，车载系统 (IVS)和PSAP)之间端到端地发生；对于数据路由，不一定需要附加的网络部件或存储。与用于传送数据的其它方法(通常属于前面所述的“存储和转发”操作模式)不同，被传送以补充eCall的数据能够服从定时要求，并且能够被立即传送而不会被不必要地重新路由 (例如，至用户的家庭网络)。示例性实施例的详细描述下面详细描述本发明的示例性实施例。尽管主要在示例性的车载系统(IVS)和公共安全应答点(PSAP)之间的通信的环境下讨论这些实施例，但是应该认识到本发明的原理可以应用在这些示例性的IVS和PSAP之外的系统中。例如，当代用户设备(UE)，例如3G 蜂窝电话，能够生成将eCall数据有效传送至接收设备(例如E911接线员)所必需的信息。此外，本发明不局限于任何管辖或系统(例如eCall对E911等)，而是可以应用在任何这样的环境中。此外，尽管主要在实时传输协议(RTP)和RTP控制协议(RTCP)(见RFC 3550，日期为 2003 年 7 月，题目为“RTP :A Transport Protocol for Real-Time Applications，，， 其全部内容通过引用结合于此)的背景下进行讨论，但是应该理解在本发明的各种实施例中，其它协议可以容易地作为代替，并且对于得知本公开的内容的本领域技术人员来说是显而易见的。例如但不限于，RTSP(见RFC 2326，日期为1998年3月，题目为“Real Time Streaming Protocol (RTSP) ”，其全部内容通过引用结合于此)，SRTP(见RFC 3711，日期为 2004 年 3 月，题目为"The Secure Real-time Transport Protocol (SRTP)，，，其全部内容通过引用结合于此)，SCTP(见RFC 4960，日期为2007年9月，题目为“Stream Control Transmission Protocol”，其全部内容通过引用结合于此)，和/或ZRTP(见“ZRTP =Media Path Key Agreement for Secure RTP-draft-zimmermann-avt-zrtp-10，，，日期为 2008 年 10月25日，同样其全部内容通过引用结合于此)协议可以与本发明兼容使用。最后，尽管参考诸如汽车或卡车等基于陆地的车辆描述了本发明的特定实施例， 但是本发明不限于此，而是可以容易地应用于其它车辆或非车辆示例，包括但不限于有轨车(火车)、飞机、船舶和摩托车。方法现在参考图2，示出了一般化过程200的第一实施例，用于传输与语音包流相穿插的数据(诸如，最小数据集或MSD)，从而高优先级呼叫(例如“eCall”，下面定义)可以被包交换网络支持。如在此所使用的，术语“高优先级”通常表示但不限于比其它业务具有更高紧急度或优先级的呼叫或其它传送。高优先级呼叫的一个示例是需要警察、消防、医疗等帮助的紧急呼叫。高优先级呼叫的另一示例可能涉及执法部门、消防队、军事人员、政府机构等的成员之间或者对访问通信介质具有较高的优先权或需要的任何其它个人或团队之间的呼叫(甚至是例行呼叫)。在此使用的术语“eCall”表示但不限于尤其是在题目为“Technical Specification-3rd Generation Partnership Project ；Technical Specification Group Services and System Aspects ；IP Multimedia Subsystem(IMS)emergency sessions (Release 8)，，的 3GPP TS 23. 167 V8. 1. 0(日期为 2008 年 9 月)中阐述的紧急呼叫和服务，其全部内容通过引用结合于此，其描述了用于IP多媒体核心网络子系统(IMS) 中的紧急服务的“阶段2”服务描述，包括支持IP多媒体(IM)紧急服务必须的元素。ITU-T Recommendation I. 130 (其全部内容通过引用结合于此)描述了表征电信服务的三阶段方法，而ITU-T Recommendation Q. 65 (其全部内容通过引用结合于此)定义了该方法的阶段 2。TS 23.167 V8. 1.0还覆盖了对于提供IMS紧急服务而言关键的接入网络方面。其它涉及IMS紧急服务的3GPP规范包括TS 23. 228 (总体IMS)，以及TS 23. 234 (描述3GPP/WLAN 交互工作)以及TS 23. 271 (位置服务)，上述每个的全部内容都通过引用结合于此。TS 25. 301 (同样全部内容通过引用结合于此)包括对UMTS陆地无线接入网络的整体描述。其它涉及IMS紧急服务的非3GPP规范包括3GPP2 cdma2000 HRPD IP-CAN，其在 3GPP2 C. S0024-A和3GPP2 X. S0011中说明，上述的每个的全部内容都通过引用结合于此。在过程200的步骤202，进行了高优先级呼叫。在一个示例性实施例中，该呼叫由客户或用户设备自动发起，并被分配以紧急呼叫状态，诸如车辆在检测到事故的情况下自动触发紧急呼叫。如在此所使用的，术语“客户设备”和“用户设备”可以包括但不限于蜂窝电话、智能电话(例如iPhone )、个人计算机(PC)(诸如iMac , Mac Pro 、Mac Mini 或 Mac Book )、微计算机(无论是桌上型、膝上型或其它)、以及移动设备(诸如手持计算机、 PDA、摄像机、机顶盒、个人媒体设备(PMD)、车载系统或任何上述组合)。在另一变型中，该呼叫由用户进行，例如用户拨打紧急呼叫以请求帮助。紧急状态被分配给该呼叫的点(以及所借助的机制)可以根据呼叫进行的方法或进行了该呼叫的网络而不同。在一个变型中，紧急呼叫状态立即由发起方标记，例如通过例如在消息头部中包括表示这样状态的数据(例如具有规定值的数据字段、被置位的标记等)。在替换的情况下，该呼叫可以作为特殊呼叫被进行。例如，在CS紧急呼叫(根据3GPP TS 24. 008(其全部内容都通过引用结合于此)，呼叫控制实体发送EMERGENCY SETUP(紧急建立)消息以建立该呼叫(与正常呼叫情况下发送SETUP (建立)消息相对)。在另一示例中，IMS紧急呼叫(根据3GPP TS 24. 229，其全部内容通过引用结合于此)，UE使用具有顶级服务类型“sos”的统一资源名(URN)服务(如RFC 5031中规定，其全部内容通过引用结合于此)。在另一可选实施例中，连接的路由信息的一个或多个部分被用于确定紧急呼叫状态。在一个这样的变型中，紧急呼叫状态由网络实体分配，例如包被截获并由于其路由信息(例如，源或目的地，诸如用户或UE拨打诸如911之类的指定号码)而被认为是紧急呼叫的情况。在过程200的步骤204，网络接入被启动。在一个示例性实施例中，通常用于蜂窝服务的认证和授权过程被绕过或加速。网络可以从IVS接收表示该呼叫应被给予紧急状态的指示，或者网络可以基于路由信息来确定该呼叫应被赋予紧急优先级。此外，这样的接入可以是“基于连接的”，或可替换地为“无连接的”。这样的网络接入可以使用任何通常的传输技术来启动。如在此所使用的，术语“传输”表示但不限于能够通过物理接口(PHY)传送数据的任何传输协议，诸如传输控制协议(TCP)、用户数据报协议(UDP)、数据报拥塞控制协议(DCCP)、实时传输协议/实时传输控制协议(RTP/RTCP)、以及流控制传送协议(SCTP)。 这样的网络接入以下被称作传输流，并且至少包括一个或多个包括数据的包，所述数据诸如是本地源、本地目的地、校验和字段和数据字段。本地源在该示例性实施例中是IVS网络地址，而本地目的地将是PSAP (不一定是路由中心)的地址。在步骤206，实时协议(例如RTP、RTSP等)在传输流上被建立或分层布置。如下面将具体描述的，这样的实时协议至少包括在被解释时标识具体时间的信息和/或一串有时间的事件(例如具有特定时间值或索引的包)。在过程的步骤208，两个或多个“流”被产生，其中至少一个是机器可读数据流，以及其中至少一个是语音或其它这样的净荷(用户)数据的数字化(例如，压缩)表示。如在此所使用的，术语“流”可以被用于表示基本连续的和非连续的(例如周期性的或间歇的) 数据流。在上述过程的一个实施方式中，基于码激励线性预测(CELP)的语音编码器(音码器)，例如ACELP、QCELP、RCELP、LD-CELP (例如G. 728)等之一，被用于数字化通过模拟麦克风接收的用户语音。机器可读数据流保持由其它网络部件可读和可写，而语音的数字表示被保护以防止被其它网络部件修改。在过程的步骤210中，两个流相穿插以便使用实时协议通过网络传送。具体地， 在一个变型中，来自机器可读数据流的数据被嵌入在一个或多个RTCP包中，然后被插入或穿插到用户数据包流(例如，携带上述数字化语音的RTP包)中。这种穿插可以使用数字领域中常用的任何数量的方法来实现，包括诸如数据复用(例如，其中多路复用器或交错器(interleave!·)被用于将一个数据流分布在一个或多个其它数据流中)，和/或搭载 (piggybacking)(例如，其中数据被附加或附着至现存的流上)。在步骤212，发起携带有包括机器可读数据和语音的数字表示的组合的穿插流的会话。各种机制可以被用于建立该会话，包括例如，基于会话的协议，诸如SIP(后面将描述)。在单个网络连接上进行该会话，其中网络路径由源端点(IVS)和目的地端点(PSAP) 表征。尽管网络内的路径可以使用多个传输层连接之间的“中继段”来构建，但是对于机器可读数据和语音的数字表示，路径保持完全相同。即，端点之间的路径可能改变，但是对于机器可读数据和数字化语音或其它“净荷”，其总是完全相同。此外，多流会话(multi-streamed session)被实时进行，并且语音和数据都被给予紧急呼叫状态处理的有利待遇。一旦在PSAP接收，例如通过多路解复用、基于位于其头部中表示身份(例如RTCP 包还是RTP包)进而每个包属于哪个流的数据或其它已知机制来路由包，两个或更多个数据流被分开。机器可读数据流被处理以至少部分确定与IVS相关的一个或多个参数。语音的数字表示被重建为可听的信号，用于分配、存储和/或回放给接线员或语音识别系统。应该理解，尽管示出的实施例使用机器可读数据流结合数字化语音，但是本发明可以在流的第二成分不是数字化语音而是其它类型的数字化内容(例如，诸如视频、文件数据等其它媒体)的情况下同样成功实施，本发明不仅仅局限于语音数据。例如，IVS系统设备或传感器之一(在此后面将更具体描述的)可以包括相机，如果需要，其可以产生能够被发送至PSAP的图像或视频数据的包流。注意，语音和/或视频可以被动获取，或在用户不知道的情况下获取，例如，车辆已经被盗窃时，板载麦克风和/或相机被用于将语音/视频数据流传输至PSAP或其它实体，而盗贼并不知道。此外，在本发明的某些实施例中，使用RTCP可能是可行的，即使没有RTP内容。这样的实施例可以被实施而没有“净荷”本身；例如，呼叫被设计为自动发起并且只传送与事件有关的规定数据(例如盗窃检测和报告系统，其发送由AGPS探知的VIN、车辆位置，等)。此外，任何“净荷”的传输可以具有M2M(机器到机器)种类；见，例如共同拥有和共同未决的2008年8月29日提交的美国专利申请第12/231，095号，题目为“Methods and Apparatus for Machine-to-Machine Based Communication Service Classes",^t^nP 内容通过引用结合于此，作为在无线(例如蜂窝)系统中的一个示例性M2M实施方式。此外，尽管M2M数据传输可以在本发明中提供“净荷”的基础，但是应该理解给定呼叫被归类为“紧急”(或更一般地，高优先级)和“M2M”这二者可以被用作上述公开中描述的类型的不同的呼叫处理和路由决定的基础。例如，本质上既是M2M又是“紧急”的呼叫可以被给予比基于人类的呼叫低的优先级，这是因为假设与机器(即，呼叫的激励者)相关的紧急事件具有比救助人类生命更低的优先级。然而，可能不总是这样的情况，例如，在M2M “机器”发起呼叫是与可能不利地影响人类生命的紧急的基础结构相关的情况下，例如，与大城市区域或医院相关的电力配电站变压器、指示有危急故障的桥梁应力/应变传感器等。因此，本发明设想，不仅是嵌入在RTCP或类似包中的数据部分，而且M2M数据(S卩，由发起机器产生的与其所属设备有关的并且嵌入到RTP或“净荷”包中的数据)也能够被用作区分呼叫处理、确定优先级和/或路由的基础。现在参考图2A，描述在CS域网络和PS域网络之间进行仲裁和选择的方法的一个实施例。尽管应该理解本发明尤其适于在包交换网络域上进行操作，但是仍然存在CS域服务也可用的情况。因此，不同于总是简单地默认PS域传输，本发明的另一变型在决定使用一个域还是另一域来进行紧急呼叫之前，采用选择或仲裁逻辑。该逻辑可以例如在网络装置(例如呼叫路由控制器)上或在客户设备(例如IVS)本身内或在两者上实现。如图2A所示，方法250的第一步骤252确定是否电路交换网络和包交换网络路径都可用于路由呼叫。该数据可以被硬编码(例如基于网络基础结构，因此是非变量)，或者可替换地基于一个或多个状态指示器。例如，电路交换传输可以被包括作为网络基础结构的一部分；然而，该传输可能当前不可用(例如，由于维护、设备故障或非常高的负荷/拥塞)ο根据步骤254，如果CS域和PS域路径都可用，则选择逻辑接下来根据至少一个选择标准评估路由中的至少一个(步骤256)。例如，在一个变型中，两个路由都被评估其拥塞 (在PS域中，其可以由与包传输相关的等待时间表示，例如晚到达的包，或在CS域中，可以由建立端到端电路的长延迟表示)。可替换地，该评估可以包括采用分层方法；例如，仅评估PS域的拥塞，如果满足，则使用PS域，否则使用CS域。也可以使用不止一个评估标准； 例如拥塞/等待时间；可靠性；可用数据容量/净荷等。知晓本公开的本领域技术人员能够意识到无数不同的评估机制和标准。根据步骤258，基于上面步骤256的评估选择两个路由之一(或两者，取决于呼叫的优先级和潜在的可靠性/等待时间问题)，然后根据步骤260，在所选的域上路由该呼叫。上面图2和2A的示例性方法强调了本发明相对于先前提到的数据传送的已有解决方案(即，短消息服务(SMS)；用户到用户信令(UUS)；非结构化补充服务数据(USSD)；全球移动通信系统(GSM)CS数据；双音多频(DTMF)；以及带内调制解调/信令应用)的许多优点。具体的，SMS使用的是通过蜂窝网络从一个终端向另一个终端传输一百四十(140)字节消息的不可靠传输。SMS消息在网络中使用存储和转发系统来处理，以有助于更好地管理网络资源；然而，SMS的一个主要缺点是短消息被路由至用户的归属网络(home network) 的SMS中心，而eCall优选地应当在拜访网络(Visited Network)中处理(以使能漫游订户)。发起eCall的漫游用户目前将其SMS路由至其归属网络以便存储，然后转发。SMS路由的这种间接处理需要进行大量修改来与其它eCall机制集成。SMS的另一缺点是其相对不可靠的服务；SMS既不能保证递送，也不能规定递送时间；从接收方至发送方的反馈是可选的，并且可能不及时或不可靠。最后，SMS依赖于移动设备中存在的订户身份模块(SIM) 进行认证。这些缺点中的每个都被在此公开的技术有利地克服。类似地，UUS是另一种服务，其允许在呼叫建立期间或紧接其后的小部分数据的用户到用户信令。UUS限制传输的数据量。在一些UUS类型中，MSD需要被减少至高度限制的三十二(32)字节。另外，运营商还没有广泛地部署UUS;对当前网络设备的升级将是昂贵和困难的。USS是一种作为呼叫控制协议的一部分而实施的服务，并且仅在CS域呼叫中或在像综合服务数字网(ISDN)那样的固定线路协议中可用。在PS域中，其当前不可用，并且当前网络运营商明确地不允许UUS用于紧急呼叫。USSD是类似于UUS的标准，并且具有一些类似的特征。USSD允许传送一百八十 (180)字节或更多信息。USSD可以独立地操作，或可以在任何时间补充正在进行的呼叫。与 UUS和SMS非常类似，USSD传送被路由至归属网络，因此在漫游过程中为了进行eCall处理而对USSD的修改必须将eCall重新路由至拜访网络。USSD类似于UUS，当前被禁止在紧急呼叫中被使用。USSD也作为CS域协议的一部分被实施，并且仅在蜂窝网络的CS域中可用 (PS域中不可用)。其它不适于eCall操作的传统电路交换数据传送技术包括GSM CS数据，以及双音多频(DTMF)。GSM CS数据能够在CS域中以9. 6kbps数据传输速度操作。不幸的是，GSM CS 数据呼叫的建立时间超过eCall服务的要求，并且GSM CS数据仅在CS域中可操作(GSM是基于CS的网络)。DTMF可以可行地被用于非常慢地携带MSD;然而，需要超过三十六(36) 秒的时间来传送一百八十(180)字节。此外，DTMF不可靠，并且不提供纠错。带内调制解调信令是当前使用的方法，并且已经在美国使用的OnStar 系统中取得一些商业成功。MSD在呼叫开始时使用建立的语音连接在带内被传送。因此，路由和寻址对于网络不是问题，MSD总是被公共安全应答点(PSAP)接收。不幸的是，IVS终端和PSAP 都必须进行一些努力来解码来自语音流的MSD数据。此外，在某些网络中，由于IVS和PSAP 之间支持的语音编解码可能不匹配，网络必须将来自一个语音编解码器的语音数据转换为另一代码。这种代码转换的过程可能将错误引入eCall MSD数据部分；或者甚至在代码转换产生嵌入在语音流中的无法识别的数据传送缺陷(artifact)的情况下完全失败。基于上面所述，在此公开的技术相对于传统和惯用方法的许多优点是明显的。RTCP APP 包协议
在一个示例性实施方式中，本发明设想将要被发送的数据(例如最小数据集 (MSD))放置在在eCall语音连接内发送的RTP控制协议(RTCP)包中。RTCP包的定时和频
Audio and Video for the Internet" Colin Perkins ；Addison-ffesley, 2003 ISBN 0-672-32249-8 2003和前面结合于此的RFC 3550中描述，其全部内容通过引
用结合于此。大部分RTP实施方式需要一些小开销。具体的，一些关于在接收方的接收质量的信息可以被用于使发送方进行有效的实时发送。此外，接收方可能需要关于该会话的其它参与者的信息；这样的信息可以包括例如关于其它参与者是否为发送方、接收方或两者的具体信息。控制数据还周期性地被传送；相关的RTP控制协议(RTCP)定义并描述了该附加控制信息如何以及何时作为嵌入数据被注入到RTP嵌入的用户数据包的流中。因此，当与其它替换方式比较时，RTCP增加了包的数量，以及被发送的数据量。然而，RTCP信令通常消耗少于实时流的总数据带宽的百分之五(5% )。对于以12. 8kbps操作的在IVS和PSAP之间的双向语音连接，可以预期RTCP包大约每秒发送一次。在连接的开始，第一 RTCP包将在该间隔的一半(0.5秒)之后被发送。RTCP定义了 5种包类型，包括(1)接收方报告；(2)发送方报告；(3)源描述；(4) 成员管理；以及(5)应用定义的(APP)包类型。前四种包类型具有定义好的结构，并且不允许包结构的扩展，而APP包类型是灵活定义的，以适应应用特有的信息。因此，在本发明的一个示例性实施例中，RTCP APP包类型被用于从车载系统(IVS)向公共安全应答点(PSAP) 传输MSD。现在参考图3，现有技术RTP APP包300格式包括多个信息元素。具体的，第一信息元素302标识协议的版本[V]，在RTP和RTCP协议的当前版本中，该值通常被设置为2 (用二进制表示为10#b)。第二信息元素304是填充位[P]，其标识该单独RTCP包在尾部是否包含一些附加的填充八位字节，这些填充八位字节不是控制信息的一部分但是被包括在长度字段中。填充的最后八位字节是关于多少填充八位字节应当被忽略的计数。例如，如果 RTP APP包300是八个(8个)八位字节，最后的八位字节包括位56至63。在另一示例中， 如果长度是十二个(12个)八位字节，则最后的八位字节是位88至95。第三信息元素306是子类型[子类型]，其可以被用作允许一组APP包被定义在一个唯一名称下的子类型，或用于任何依赖于应用的数据。第四信息元素308是包类型[PT]，表示RTCP APP包，在该示例中被表示为具有值 [204] ( 二进制表示为 11001100#b)。第五信息元素310是32位字减一(1)的RTCP包的长度字段[长度]，其包括头部和任何填充。第六信息元素312是名称字段[名称]，其定义了由相同的人定义的和/或为相同目的所使用的一组RTCP APP包。第七信息元素314是依赖于应用的数据[依赖于应用的数据]，其是由应用使用 (即，不由RTCP APP处理使用)的末端开口(open ended)字段。依赖于应用的数据长度的一个特定要求是其是三十二(32)位的倍数，从而恰好适合32位字边界。下面参考图3A-D，示出了根据本发明的用于嵌入eCall数据的示例性RTP APP包 350格式的各种实施例。类似于图3的现有技术包，第一信息元素352标识协议的版本[V]，在RTP和RTCP协议的当前版本中，该值通常被设置为二( 二进制表示为10#b)。 类似的，第二信息元素354是填充位[P]，其确定该单个RTCP包在尾部是否包含一
些附加的填充八位字节，这些填充八位字节不是控制信息的一部分，但是被包括在长度字段中。第三元素是子类型字段(下面将具体描述)。第四信息元素358是包类型[PT]，表示RTCP APP包，在该实例中被表示为具有值 [204](以二进制表示为 11001100#b)。第五信息元素360是32位减一(1)的RTCP包的长度字段[长度]，其包括头部和任何填充。图3A和图3B示出了 RTCP APP包类型的示例性实施例。为了最佳地使用现有的 RTCP APP包格式350，所有eCall定义的包在名称字段362中保持共同的字符串值(例如 "eCal")(图3A)。此外，为eCall服务定义的子类型字段356的值可以区分不同的数据类型，诸如最小数据集(MSD)、完整数据集(FSD)等。可替换地，其它实施方式可以在名称字段 362中指出该包是eCall特有的以及包含在该包中的数据的类型。子类型字段356然后可以被用于其它目的，例如MSD或FSD的前五位(如图3B中所示)。RTP和RTCP在本实施例中通过UDP传输协议被传送，如前所述的，其不向发送方保证发送的包已经被正确接收(与TCP不同)。在某些情况下，可能期望由接收方提供确认 (ACK) ；BP, (i)包已经被完整且及时地接收，或者(ii)故障模式(例如包被破坏、迟到或丢失)。在一个示例性实施例中，RTCP APP包可以被用于由接收方确认成功接收。注意，在任何RTCP APP包中(如图3A-D所示)，RTCP格式容易通过定义子类型字段值356或适当的名称字段值362来表达确认。下面参考图3C和图3D，在另一替换实施例中，如果多于一个消息被发送方(例如 IVS)发送，则eCall数据的接收方(例如PSAP)可以被使能确认特定的eCall数据消息。 在子类型字段356中增加的包编号以及将该包编号与适当的确认消息相关联的索引将因此允许正确地按顺序接收和区分多个消息。包编号的传输可以通过例如用于eCall数据包或其相应确认包的如图3C中示出的子类型字段356来实现。可替换地，包编号可以被包括在如图3D中示出的应用特有数据字段364中。在一个另外的实施例中，PSAP可以具有从IVS请求更新eCall数据的能力。更新消息可以以类似于确认包(或任何适于从PSAP传送至IVS的包格式)的格式构建。更新请求还可以包含规定应该被更新的信息的指示；这样的更新可以被用于例如轮询特定动态状态。在一个这样的变型中，仅所请求的信息(或自从上次更新已经改变的信息)被发送以减少开销。此外，该信息可以被封装在应用特有数据字段364或根据需要的其它位置中。在另一实施方式中，通过将一百四十(140)字节数据分解成在第一 RTCP包中发送的第一部分和在与第一 RTCP包分开的一个或多个RTCP包中发送的第二部分，来适应eCall 数据的指定部分的快速传送要求。第一和第二数据长度的任何组合可以被使用。在一个这样的示例中，第一包可以包含总计不大于三十八(38)字节的MSD的前5个信息元素，而第二部分可以包含大小最多为一百零六(106)字节的剩余部分。较小的第一包被非常快速地发送，以及第二剩余包可以在由IVS安排的接下来的RTCP传送中被发送。此外，除了上面实施例所述的，支持多于一个eCall机制的蜂窝移动网络还可以支持用于指示哪个eCall机制应被使用的各种消息格式。这样的指示将发生在呼叫建立过程中，以识别哪个机制可以用于特定eCall会话。可替换的，在呼叫建立过程中还可以进行机制协商。用于描述和初始化会话信息的一个常用的协议是已知的会话发起协议(SIP)。基于IP的多媒体核心网络子系统(IMS) 是基于SIP的网络结构；IMS定义了移动蜂窝网络中的会话建立、操作和终止的方法。具体地，在传输任何实际数据之前，通常在IMS构架中使用SIP协商和建立PS域呼叫。尤其参见 3GPP TS 23.228 V8. 6. 0 (2008-09)，题目为“Technical Specif ication-3rd Generation Partnership Project ；Technical Specification Group Services and System Aspects ； IP Multimedia Subsystem(IMS) ；Stage 2 (Release 8) ”，其全部内容通过引用结合于此。 在SIP中，会话描述协议(SDP)被用于定义与给定会话相关联的参数。在SIP构架中，可以在会话描述中增加“a-line”(属性行)以指示哪个eCall数据信令机制被使用。例如，在存在两种可用的支持格式(例如，RTCP上的带内信令以及语音编解码)的系统中，两个分开的流类型可以用适当的a-line描述符来表示a = eCalIDataTxMechanism:InBandRTCPa = eCalIDataTxMechani smInBandVCodec适当的响应将基于例如位于网络中的选择逻辑来选择两个流选项中的一个。该选择可能基于例如呼叫设备的固有能力、网络优化或操作标准、等待时间等。然而，注意到，在SIP的特定环境中，主要的SIP RFC (RFC 3261)不支持资源优先级；然而，存在补充的RFC(2006年2月的RFC 4412，题目为“Communications Resource Priority for the Session Initiation Protocol (SIP) ”，其全部内容通过引用结合于此)，其被设计为在呼叫优先级方面扩展SIP的能力。具体地，RFC 4412定义了两个新的 SIP头部字段，允许设备请求下游元素以“高优先级”处理呼叫。TiM下面的示例进一步示出了上述RTCP APP协议的包结构和消息格式的一个示例性实施方式，其用于发起和处理eCal 1，使用语音和带内信令数据流。根据一个实施例，为了发起包交换呼叫，车载系统(IVS)建立与基站的通信。在某些多模式系统中，IVS可以被要求将其自己标识为包交换设备(例如CS和PS网络重叠时， 或两种能力都可用时)。基站赋予IVS专用物理通信资源(例如时隙、频带、码域等)以及逻辑信道。逻辑信道的分配使得IVS能够与基于IP的多媒体核心网络子系统(IMS)通过该逻辑信道通信，其在被分配的专用物理通信资源上被发送。IVS使用会话发起协议(SIP)发起与PSAP的呼叫。在语音或eCall数据可以通过所建立的会话被交换之前，必须发生图4中所示类型的消息交换。注意，在图4中示出的消息发送中，没有具体给出SIP消息的所有内容以便更清楚地示意。如图4的示例性交换所示，IVS发送初始SIP INVITE请求402，其封装在具有相关的IP和UDP头部的IP包中。SIP INVITE请求包括被呼叫终端(例如PSAP)的目的地址，并且表示所呼叫的终端被邀请参与呼叫会话(例如eCall)。图4还示出了用在前面所述的SIP INVITE消息的会话描述中的定制“a-line”。根据本发明的原理，图4的示例性 SIP INVITE包括上面提及的用于传送紧急相关数据的两条a-line，作为带内语音编解码信令或带内RTCP。
19
通常，基站将发送INVITE请求至用于接入控制、授权和结算的各个网络实体。在 eCall情况下，这些网络实体将选择性地跳过或预占接入、授权和结算阶段中的一些或所有。该选择也可以根据呼叫的类型或优先级而动态改变；例如“紧急”呼叫可以将上述所有阶段都跳过，而高优先级但是非紧急呼叫可以使用一部分这些阶段来实现特定目的(例如高优先级的内部法律执行传输可以使用认证以保证“电子欺骗”或类似的攻击不会发生)。一旦已经被定位并已经接收到INVITE请求，SIP RINGING响应403可以可选地从 PSAP被返回。一旦eCall已经被PSAP接受，则其返回SIP 2000K响应404。一旦2000K响应404 被接收到，则IVS发送SIP ACK消息406以确认该OK响应。2000K 404包含PSAP从两个选项中进行的选择。如图所示，PSAP已经选择了 RTCP信令。在此，该呼叫已经建立，并且穿插的语音和其它实时数据的通信能够被处理。MSD数据的传送下面参考图5，在会话建立已经完成(例如图4的SIP交换已经成功仲裁具有语音和数据分量的会话)后，执行IVS和PSAP之间的示例性消息流500。语音数据的交换在 502a、502b通过传输包含编码的语音帧的RTP包开始。在预定时间(T1)之后，第一 RTCP包按照步骤504发送。在一个实施例中，该包包含如前面参考图3A-3D所述的RTCP APP包 350。在本发明的一个示例性实施例中，下面的信息元素在步骤504发送的第一 RTCP APP(2)包中被设置⑴名称362 = eCal，(ii)子类型356 = MSD-Data,以及(iii)包编号(应用特有字段364的前八(8)位)=0 (零)。应用特有字段364的剩余部分包含剩下的 MSD。在第一 RTCP APP (2)包已经产生之后，其它RTCP包在后续间隔中被产生。在一个实施方式中，这些间隔实际上是周期性的，尽管没有特定要求包必须如此。使用规则的间隔时间(T2)将简化IVS和PSAP之间的RTCP包的处理。在周期性的RTCP包传送之间，RTP语音包可以继续被发送，例如在步骤502c、502d、502e等中所示。在示出的实施例中，所产生的RTCP包包含用于eCall数据的APP包，直到接收到来自PSAP的关于成功接收的确认的点。如图5所示，PSAP在步骤504接收第一 RTCP APP (2) 包；PSAP响应于接收到第一 RTCP APP (2)包，在步骤506产生RTCP APP (3)包，以确认成功接收。RTCP APP(3)包(ACK)被发送时具有下面创新性的信息元素集合名称362 =“eCal”; 子类型356 = ACK,包编号(应用特有字段364的前八⑶位)=0 (零)，以确认包0 ；剩余的应用特有字段为空。在图5的假定示例中，在步骤506发送的ACK(3)由于在空中接口中的故障或干扰 (见步骤506的“X”)被丢失。IVS期望随后的确认；这样，IVS发现该确认没有被正确和 /或按时接收。因此，在预定时间(T2)之后，第二 RTCP APP(4)包在步骤508被发送，包括下面的信息元素名称362 ="eCal"； (2)子类型356 = MSD-Data，包编号(应用特有字段 364的前八⑶位)=“1”(一)；剩余的应用特有字段包括MSD。该包在步骤510被PSAP 接收并使用RTCP APP包(5)确认，RTCP APP包(5)包括名称362 = “eCal”，子类型356 =ACK，包编号(应用特有字段364的前八(8)位)=“1”(一)，以确认包1 ；剩余的应用特有字段留为空。在IVS成功接收该确认之后，停止eCall数据的传送，并且语音包在步骤502e继续被交换。请求更新过稈图5还示出了可选的更新请求过程。具体的，在步骤512，PSAP请求更新MSD ；在某些情况下，PSAP可能请求更新，因为MSD中的信息可能在动态改变。因此，RTCP APP (6) 包在步骤512被发送，包括下面的信息元素名称362 = “eCal”，子类型356 = UPDT，包编号(应用特有字段364的前八(8)位)。剩余的应用特有字段留为空。IVS在步骤514以更新的RTCP APP包(7)应答该请求，RTCP APP包(7)包括下面的字段条目名称362 =、011”；子类型356 = 1^0-0站 包编号=2(二)。剩余的应用特有字段包含更新的MSD。在可替换实施例中，在步骤512发送的更新请求RTCP APP包(6)可以发起请求以查看FSD是否可用，以及如果可用，则在514处发送的RTCP APP包(7)还可以在子类型中指示FSD-数据(以及在应用特有字段中包含FSD)。还可以设想，只要在最近计算出的MSD 中的任何信息不同于最后发送的MSD(然而也可以使用其它逻辑或标准(例如η个连续包或间隔没有改变，等等))，IVS就继续发送类似于在步骤504和508发送的MSD包。分段的包(Segmented Packets)在可替换实施方式中，eCal 1数据可以被分段成多于一个RTCP包。例如，在504发送的RTCP包(2)的信息元素可以改变，从而第一包被构建为包括下面的信息名称362 = “eCal，，，子类型356 = MSD-Data-Segmented,包编号=0 (零)，用于段编号的字段=0 (零)， 剩余的应用特有字段包含MSD的前三十八(38)字节。此后，在稍后的时间，第二分段的包被产生，包括(1)名称362 =“eCal”；子类型 356 = MSD-Data-Segmented，包编号=0(零)，段编号=1 ( 一)，以及应用特有字段的剩下部分包含MSD的剩余部分。在步骤506，仅在两个段都已经在PSAP处被接收到之后，确认消息才确认完整包0(即，两个段)。ACK必须指出被确认的包和/或段。因此，在一个变型中，ACK可以包含包编号和段编号。如果IVS没有接收到确认，则其将产生新的MSD(包含两个段)。示例性网络装置下面参考图6a，示出了在实施本发明的方法中有用的示例性网络装置(例如公共安全应答点(PSAP)子系统)600。所示出的装置600的实施例包括一个或多个服务器单元，其与中央数据库604连接并包括处理器606、可操作的存储器608、电源610以及外部网络接口 612。如在此所使用的，术语“网络接口 ”或“接口 ”通常表示与部件、网络或程序进行接口的任何信号、数据或软件接口，包括但不限于Fireffire (例如FW400.FW800等)、USB (例如USB2)、以太网(例如， 10/100，10/100/1000 (吉比特以太网)，IO-Gig-E 等)、MoCA、串行 ATA(例如 SATA、e_SATA、 SATAII)、Ultra-ATA/DMA、Coaxsys (例如Tvnet )、射频调谐器(例如带内或00B、线缆调制解调器等)、WiFi (802. 11a，b，g，η)、WiMAX (802. 16)、PAN(802. 15)、IrDA 或其它无线族。在一种配置中，图6a的服务器单元由外部总线614连接。如图所示，中央数据库604可以分布在多个单独机器中，但是作为一个逻辑相关数据库工作。中央数据库包括独有标识符的列表，以及对应的存储到计算机可读介质(例如硬盘驱动器/RAID阵列、闪存等)的当前和历史数据(例如最小数据集或MSD)。
处理器子系统606可以包括微处理器(CPU)、数字信号处理器、RISC核、现场可编程门阵列、和/或多个处理部件。如在此所使用的，术语“微处理器”和“数字处理器”通常意味着包括所有类型的数字处理设备，包括但不限于数字信号处理器(DSP)、精简指令集计算机(RISC)、通用目的(CISC)处理器、微处理器、门阵列(例如FPGA)、PLD、可重构计算机构造(RCF)、阵列处理器、安全微处理器、以及专用集成电路(ASIC)。这样的数字处理器可以包含在单个单一 IC芯片上，或分布在多个部件上。处理子系统还可以包括内部高速缓冲存储器606A。该处理子系统连接至逻辑中央数据库604、本地存储器子系统608、以及外部网络接口 612，从而经由例如联网或数据总线协议与其它本地或远程实体通信。存储器子系统608可以包括一个或多个存储器部件，其可以例如包括非易失性 (例如ROM、闪存等)以及易失性(例如RAM、DDR-RAM、QDR-RAM等)部件。应该理解术语 “存储器”可以包括任何类型的集成电路或适于存储数字数据的其它存储设备，包括但不限于 ROM、PROM、EPROM、DRAM、SDRAM、DDR/2 SDRAM、EDO/FPMS、RLDRAM、SRAM、“闪速”存储器 (例如NAND/N0R)以及PSRAM。存储器子系统还可以包括计算机领域已知类型的DMA类型硬件608A，以有利于更快的数据存取。所示的功率管理子系统(PMS)610为服务器单元提供功率，并且可以包括集成电路和/或多个分立电部件。如在此所使用的，术语“集成电路(IC)”表示具有任何等级的集成(包括但不限于ULSI、VLSI和LSI)并且无论什么工艺或基材(包括但不限于Si、SiGe、 CMOS和GaAs)的任何类型的设备。IC例如可以包括存储设备(例如DRAM、SRAM、DDRAM、 EEPROM/闪存、和ROM)、数字处理器、SoC设备、FPGA、ASIC、ADC、DAC、收发器、存储器控制器以及其它设备，及其任意组合。如果愿意，故障切换或冗余系统(包括不间断电源或UPS，未示出)也可以被用于后备，从而进一步有助于使该装置不间断地可用。所示的装置还可以直接或间接与其它装置(例如网络运营商的其它紧急服务装置、网络桥、网关等)进行数据通信，从而关于紧急状态的信息可以容易地在网络上作为整体被传播，如果愿意甚至可以传播到其它类型的网络。示例性IVS装置下面参考图6b，描述根据本发明的示例性客户端装置650。在示出的实施例中，客户端装置包括车载系统(IVS)650，但是应该理解其它类型的装置可以同样成功使用。所示的IVS装置650除了其它部件外，还包括壳体；能够通过蜂窝网络至少发送和接收数据的无线装置652 ；麦克风和扬声器组件654，用于接收来自车辆乘客的语音通信并向下游播放或反向通信；一个或多个传感器656，适于收集关于车辆状态的数据；以及处理设备658，其能够通过无线装置发起至蜂窝网络的连接，并且根据前面所述的方法和协议传送语音和数据流。装置650还可以包括视频或相机子系统(未示出)，其可以收集图像数据并将该数据提供至处理子系统658，用于在网络上作为类似于前述语音传输的另一“实时”流进行打包和传送。此外，语音和视频流可以是时间相关的，从而以协调的方式被播放，例如通过ITU 标准H. 323或打包数据网络领域的技术人员已知的类似的协议，其提供了语音和视频的同
上面所述的控制协议和语音数据交错功能可以根据需要在客户端中(或可替换地在与客户端通信的专用或多功能设备中)以不同的程度被执行。在示出的实施例中，这样的功能以软件来实现，然而也可以预见到固件/硬件实施例。如在此所使用的，术语“软件”和“计算机程序”可以包括但不限于执行功能的任何人类或机器可识别步骤序列。这样的程序实质上可以以任何编程语言或环境来呈现，包括例如C/C++、Fortran, COBOL、 PASCAL、汇编语言、标记语言(例如HTML、SGML、XML、VoXML)等，以及面向对象的环境，诸如公共对象请求代理体系结构(CORBA)、Java (包括J2ME，Java Beans等)、二进制运行时环境(BREW)等等。在装置650的一个实施例中，适于收集关于车辆状态的一个或多个传感器还包括(i)全球定位服务(GPS)接收器656A，(ii) 一个或多个加速度计656B，其位于底盘内以确定碰撞和/或底盘位置，以及(iii)用于确定车辆的占用情况的传感器656C。GPS接收器提供任何时刻的车辆的相对精确位置，而加速度计确定是否已经发生撞击或其它事件 (例如翻转事故)。除其它功能以外，占用情况数据还可以用于确定在事件发生的时刻车辆是否被占用(从而允许在车辆没有被占用的情况下改变优先级)以及确定乘客的数量(从而允许例如派遣适当数量的救援车或服务人员)。如果愿意，也可以使用其它传感器，包括例如应力/应变传感器来检测车辆的各个部件的变形，温度和其它环境传感器来检测车辆环境的状态(例如淹没在水中或着火等)等等；这些附加的传感器还可以为外发的数据传输提供输入或净荷数据。无线/调制解调652子系统包括数字基带、模拟基带、RX前端和TX前端。该装置还包括天线组件和双工部件；双工部件可以包括简单的开关，用于在天线操作之间进行切换。 该开关还可以包括分立部件。尽管讨论了具体结构，但是知晓本公开的本领域普通技术人员应该理解，在一些实施例中，一些部件可以被去除或者可以与其它部件合并(例如RF RX 和RF TX结合，就像用于3G数字RF的类型)。用户接口系统654可选地被提供，并且可以包括任何数量的已知1/0，包括但不限于触摸屏、LCD显示器、背光，等等。应该意识到在IVS系统中，该系统通常至少提供用于产生语音流或来自车辆的其它语音采样的装置(例如麦克风)，以及用于合成可听消息的装置(例如扬声器)，从而有利于通信。应该理解，在一些情况下，I/O子系统可以仅被用于监视，例如在车辆的乘客呈现无知觉并且不能讲话的情况下，或者用于由网络运营商或执法部门被动监视(例如车辆装配有乘客可以在被劫车、绑架等时触发的“无声警报”的情况)。示出的本装置的实施例包括具有一个或多个处理器的应用微处理器子系统658， 所述处理器诸如数字信号处理器、微处理器/CPU、RISC核、现场可编程门阵列、或安装在一个或多个衬底上的多个处理部件。处理子系统还可以包括内部高速缓冲存储器。处理子系统与包括存储器的存储器子系统进行数据通信，所述存储器例如可以包括SRAM、闪存、以及 SDRAM部件。存储器子系统可以采用一个或多个DMA类型硬件，从而如本领域已知的那样有利于数据存取。在一个示例性装置中，IVS适于使用内部逻辑(例如通过存储在程序存储器中的算法)来发起与PSAP的eCall。一旦建立eCall，IVS提供连续的语音或其它净荷流量，其中穿插有从分布在整个车辆中的上述传感器中读取的数据。由处理子系统提供对语音(或净荷)和传感器数据的控制。在一个这样的实施例中，eCall由检测到碰撞的车辆的一个或多个传感器656自动发起，例如当加速度计检测到大于规定阈值(其表示碰撞)的加速度值时。任何数量的其它情景可以被用来触发这样的呼叫，包括例如环境温度的快速下降(表示淹没在水中)、 车辆的反转(翻转事故)、引擎罩下面或内部的温度快速上升(可能是引擎或其它着火，或窒息情况，诸如在非常热的天气窗户卷起)、引擎运行时车辆中无活动(可能表示司机由于例如医学或其它情况已经失去知觉)等等。在可替换实施例中，eCall由车辆中的一个乘客发起，例如当车辆需要拖车帮助时。无线调制解调子系统发起蜂窝呼叫，并建立用于提供网络消息的传输层，以及实时通信链路。对呼叫处理的控制可以在无线调制解调子系统或处理子系统处执行。响应于无线调制解调子系统发起蜂窝呼叫，网络实体应当如上所述地提供优先的加速的处理过程。建立eCall之后，产生两个或更多个流。这些流中的至少一个是由用户接口麦克风组件产生的语音呼叫流，剩下的流(一个或多个)由各个监控传感器产生以作为数据流传送(诸如，不经常或偶尔地)。处理子系统如上所述地仲裁两个流并传送至无线/调制解调子系统。还应该理解，尽管客户设备650的示例性实施例被描述为具有用于定位的GPS (或 AGPS)接收器，但是其它技术也可以被采用，其代替上述GPS接收器或与之配合使用。例如， ^ 2008 ^9^ 30 HiI^WIS "Methods and Apparatus for Resolving Wireless Signal Components”的共同拥有和共同未决美国专利申请第12/286，646号(其全部内容通过引用结合于此)中描述的在诸如WiMAX网络的单频网络(SFN)中用于定位的方法和装置可以与本发明一起使用以提供移动客户端定位数据。具体地，上述应用披露了这样的方法和装置，其使得无线网络能够产生可以被接收方(例如UE)使用以分析各个发射方的贡献的数据，从而确定其位置而不求助于诸如GPS卫星的外部设备。在一个实施例中，无线网络包括单频网络(SFN)，并且唯一基站标识符被嵌入在数据中，并以允许UE计算出路径特征(例如路径等待时间和到达方向)从而用三角法确定其位置的方式被编码。此外，由于GPS在接收器位于室内或被诸如隧道、高架等结构遮蔽或阻挡时，有时不能工作，所以基于蜂窝的定位技术可以被用作GPS的“后备”(或反过来)，或者两种技术可以以互为验证的方式使用，从而保证紧急服务等被发送至正确位置(假设车辆操作员不能口头响应，或者不知道他们所在的确切位置)。现有蜂窝技术，即使没有上述基于GPS或SFN的技术，仍然能够至少分析网络中移动单元或UE当前与哪个小区相关联。因此，该信息也可以被使用以确定位置或确认由其它系统提供的另一“固定”或估计的位置。例如，如果IVS装配有“淹没”传感器，并仅知道与 IVS最后通信的小区位置或基站，该信息可以被PSAP/紧急事务工作者使用来粗略地知道车辆在哪里(即，查找该特定小区位置覆盖范围内的水域)。使用在此描述的技术(例如 “位置关联”字段或类似物)，这样的信息(例如小区位置ID或类似物)可以被容易地包括在发送至PSAP的数据中。商业方法在本发明的另一方面，公开了与包交换网络内的上述紧急呼叫服务相关的商业方法。在一个实施例中，由本发明使能的无线/调制解调能力可以被商业化并且被充分利用以使网络运营商和/或第三方获利。例如，设备制造商或服务提供商可以根据其能力使其产品或服务区别于其它制造商或供应商，以提供在PS和CS/PS类型网络之一或两者内的紧急呼叫服务。上述IVS系统能力也可以被用作区分或支持更高价格的基础；通过向消费者保证他们的车辆将能够在发生事故的情况下发起紧急呼叫，而不论其位置和/或服务计划。订购者明显愿意在初始价格或持续的订购费用方面为这种能力支付更多。在另一方面，本发明实现的用于在IVS内的紧急呼叫的实时打包数据服务的补充特性可以在订购者使用上提供更大的灵活性。分配出各种服务的机会可以包括可选服务， 例如紧急门锁打开、无声发射器(例如lo-jack)跟踪、紧急坐标/方位、以及为订购者的方便而提供的任何其它类似紧急服务。应该理解尽管以方法的特定顺序的步骤描述了本发明的某些方面，但是这些描述仅是示例性地示出了本发明的更宽泛的方法，并且可以根据特定应用的需要来修改。某些步骤在某些情形下可能不必要或是可选的。因此，某些步骤或功能可以被添加至所公开的实施例，或者两个或更多个步骤的执行顺序可以被重新排列。所有这些变型都被认为是包括在这里公开和声明的本发明之内。尽管上面具体描述已经示出、描述和指出应用至各个实施例的本发明的新颖特征，但是应该理解本领域的技术人员可以对所示出的设备或过程的形式和细节上进行各种省略、替换和改变，而不背离本发明。上述描述是当前设想的执行本发明的最优方式。该描述不是用于限制，而是用于示出本发明的一般原理。本发明的范围应参考权利要求来确定。
权利要求
1.一种在适于基本实时包交换操作的网络中提供紧急呼叫的方法，所述紧急呼叫包括具有第一流和一个或多个第二流的复合流，所述方法包括以基本连续的方式提供第一流； 提供一个或多个第二流；至少使用所述第一流和所述一个或多个第二流来形成复合流； 建立会话，其中所述会话还适于路由所述复合流；以及通过所述会话发送所述复合流。
2.根据权利要求1所述的方法，其中所述会话包括使用会话发起协议建立的实时会话。
3.根据权利要求1所述的方法，其中所述第一流包括多个语音包，并且所述一个或多个第二流包括多个数据包。
4.根据权利要求3所述的方法，其中所述基本连续的方式包括基本连续地编码语音信号以产生所述语音包。
5.根据权利要求1所述的方法，其中所述提供一个或多个第二流是以基本不连续或非持续的方式被执行的。
6.根据权利要求5所述的方法，其中所述基本不连续的方式包括仅仅周期性地或间歇性地提供来自至少一个源的数据。
7.根据权利要求6所述的方法，其中所述数据包括位置数据，并且所述至少一个源包括GPS接收器。
8.根据权利要求1所述的方法，其中所述复合流、所述第一流和所述一个或多个第二流被打包。
9.根据权利要求8所述的方法，其中所述形成动作包括通过将所述第一流的一个或多个包与所述第二流的一个或多个包穿插来形成所述复合流。
10.根据权利要求9所述的方法，其中所述穿插是使用多路复用算法来执行的。
11.根据权利要求1所述的方法，其中所述至少使用所述第一流和所述一个或多个第二流来形成复合流包括在多个RTP包中布置所述第一流的至少一些部分；在多个RTCP包中布置所述一个或多个第二流的至少一些部分；以及将所述RTP包与所述RTCP包穿插。
12.根据权利要求1所述的方法，其中所述网络包括3GPPIMS兼容的蜂窝网络，并且所述会话是使用会话发起协议(SIP)建立的。
13.根据权利要求1所述的方法，还包括在第一打包协议结构中布置所述第一流的至少一些部分； 在第二打包协议结构中布置所述一个或多个第二流；以及在所述发送动作之前，将所述第一协议结构与所述第二协议结构穿插以形成所述复合流的至少一部分；其中所述第一流包括基本连续的用户数据流；并且其中所述一个或多个第二流的至少一部分涉及高优先级事件。
14.根据权利要求13所述的方法，其中涉及高优先级事件的数据包括最小数据集(MSD)。
15.根据权利要求13所述的方法，其中所述网络包括3G蜂窝网络，并且所述发送包括通过会话建立协议首先建立至少一个会话。
16.根据权利要求15所述的方法，其中所述第一打包协议包括实时传输协议，所述第二打包协议包括实时控制协议。
17.根据权利要求13所述的方法，其中所述方法根据事件由基本上布置在陆地车辆中的发送装置基本上自动地发起。
18.根据权利要求17所述的方法，其中所述事件选自以下项(i)碰撞；(ii)车辆翻转；和(iii)车辆起火。
19.根据权利要求13所述的方法，其中所述用户数据包括视频和语音数据两者。
20.根据权利要求13所述的方法，其中涉及高优先级事件的数据包括在呼叫时第一实体的基本准确的位置数据。
21.根据权利要求20所述的方法，其中，所述准确的位置数据不仅仅基于网络地址。
22.—种在能够进行包交换操作的网络中进行紧急呼叫的装置，所述装置包括 麦克风，适于连续捕获语音并将所述语音数字分解为多个第一包；一个或多个传感器，所述传感器适于将与所述装置或承载所述装置的平台相关联的一个或多个参数编码为一个或多个第二包；无线发射器，其中所述发射器适于通过无线网络发送多个包； 与所述发射器进行数据通信的处理器；以及计算机可读装置，包括适于包含计算机程序的介质，所述计算机程序具有多个指令，所述多个指令在被所述处理器执行时至少部分地基于所述多个第一包与所述一个或多个第二包的穿插而产生用于发送的多个包；建立会话，其中所述会话适于路由所穿插的多个第一包和一个或多个第二包；以及通过所述无线发射器发送所穿插的多个包。
23.根据权利要求22所述的装置，其中，所述产生用于发送的多个包包括产生多个第三包，所述第三包从所穿插的多个第一包和一个或多个第二包得出。
24.根据权利要求22所述的装置，其中，所述装置还包括 无线接收器，所述接收器适于接收来自所述无线网络的多个包；以及扬声器，适于由所接收的多个包数字合成语音。
25.根据权利要求22所述的装置，其中，所述装置还包括扬声器子系统；接收器装置， 适于接收来自所述无线网络的多个包；以及分离装置，适于将从所述网络接收的所述多个包分离成语音分量和数据分量，所述分离装置适于(i)将所述语音分量提供至所述扬声器子系统；以及( )由所述数据分量确定所述一个或多个第二包的接收状态。
26.根据权利要求22所述的装置，其中，所述装置基本上被容纳在适于运送一个或多个乘客的车辆内。
27.根据权利要求沈所述的装置，其中，所述装置包括基于卫星的位置确定接收器，并且一个或多个传感器包括以下的一种或多种(i)适于检测碰撞的加速度计；( )适于检测车辆翻转的加速度计；以及(iii)适于确定车辆占用情况的传感器。
28.根据权利要求22所述的装置，其中，所述无线网络包括与3GPPIP多媒体核心网络子系统(IMS)要求兼容的蜂窝网络，并且所述会话是使用会话发起协议(SIP)建立的。
29.根据权利要求22所述的装置，其中，所述多个第一包与所述一个或多个第二包的穿插包括将多个RTP包与一个或多个RTCP包穿插，所述一个或多个RTCP包包括最小数据集(MSD)。
30.一种被配置为在包交换网络中接收紧急呼叫的网络装置，所述装置包括网络接口，适于通过与所述装置进行数据通信的互联网协议(IP)网络接收第一多个包和第二多个包；与所述接口进行数据通信的处理器；以及计算机可读装置，包括适于包含计算机程序的介质，所述计算机程序具有多个指令，所述多个指令在被所述处理器执行时接收对通信会话的请求，所述会话适于帮助传输所述第一多个包和第二多个包； 建立会话；通过所述会话接收所述第一多个包和第二多个包； 从所述第一多个包中提取基本实时的用户数据；以及从所述第二多个包中提取紧急情况相关数据。
31.根据权利要求30所述的网络装置，还包括音频模块，所述音频模块具有扬声器并且适于通过所述扬声器播放出音频，所述音频从所提取的基本实时的用户数据中得出。
32.根据权利要求30所述的网络装置，其中所述包交换网络包括3GPPIP多媒体核心网络子系统(IMS)，并且所述会话是至少使用会话发起协议(SIP)建立的。
33.根据权利要求30所述的网络装置，其中所述第一多个包和第二多个包分别包括相穿插的RTP包和RTCP包。
34.根据权利要求M所述的网络装置，其中所述RTCP包的至少一部分包括最小数据集 (MSD)。
35.根据权利要求30所述的网络装置，其中所述紧急情况相关数据包括最小数据集 (MSD)。
36.根据权利要求30所述的网络装置，其中所述网络装置包括公共安全应答点 (PSAP)。
37.一种电信装置，适于使用可靠的打包协议传输将紧急呼叫传送至适于从网络接收打包数据并处理所述数据的实体，所述装置包括无线发射器；以及与所述发射器通信并且适于使打包数据在网络上传送的装置，所述打包数据包括携带基本实时的用户数据的第一包，以及与所述第一包穿插并携带紧急情况相关数据的第二包；其中所述第一包和第二包根据不同协议被格式化；以及所述不同协议中的每一个都支持适于提供可靠性的服务质量要求。
38.根据权利要求37所述的电信装置，其中所述紧急情况相关数据包括在呼叫时所述电信装置的准确位置数据。
39.根据权利要求38所述的电信装置，其中所述准确位置数据不仅仅基于网络地址。
40.一种将紧急呼叫从源路由至目的地的方法，所述方法包括 确定是否电路交换和包交换网络路由都可用于路由所述呼叫； 如果两个路由都可用(i)根据至少一个选择标准来评估所述路由中的至少一个； ( )至少部分基于所述评估来选择所述路由之一； (iii)通过所选的路由来路由所述呼叫；以及如果仅包交换路由可用，则通过所述包交换路由来路由所述呼叫。
全文摘要
用于提供与诸如紧急呼叫的高优先级呼叫相关联的有用数据的方法和装置。在一个实施例中，该数据包括嵌入在诸如RTP控制协议(RTCP)包的一个或多个实时协议包中的数据(例如MSD或FSD)，其与紧急呼叫的语音或用户数据流(在例如RTP包中携带)相穿插。描述了通过使用与用户数据相同的传输连接，可靠地将来自发起端(例如车载系统)的数据部分发送至公共安全应答点(PSAP)的装置和方法。
文档编号H04M1/725GK102362476SQ201080013284
公开日2012年2月22日 申请日期2010年2月9日 优先权日2009年2月10日
发明者M·汉斯 申请人:苹果公司