英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料
基于泛欧移动应急应用协议(PEMEA)的下一代应急服务:利用移动定位和上下文信息
Urban Sedlar ,1 James Winterbottom,2 Bostjan Tavcar,3 Janez Sterle ,4 Jaka Cijan , 1and Mojca Volk 1
在这篇论文中，我们分析了在移动设备和传感器无处不在的时代，下一代112应急服务的需求，并介绍了我们的试验台的设计、实现和试验结果，这是在H2020项目NEXES中开发的。该系统利用了一个多跳位置感知的PEMEA路由网络，该网络可以找到地理上最近的负责任公共服务应答点(PSAP)，并支持跨境应用程序漫游。我们的参考移动实现利用了多种设备和基于网络的定位技术，两者相结合，都优于传统的基于蜂窝基站的定位，并提供了一种检测欺诈呼叫的方法。该系统具有可扩展性，可在初始应急会话建立后建立多种通信渠道;我们用一个可互操作的基于WebRTC的视频电话演示了这一点。结果显示了基于PEMEA的超顶应急服务的可行性和灵活性，在与现有解决方案进行比较时显示了较高的用户接受度，从而为此类系统的进一步推出铺平了道路。
1.介绍
近年来，无处不在的传感和定位增强了对普通人群的一些应用。例如，web搜索引擎通常根据用户的位置定制结果;附近的活动和商店通过社交网络和广告平台进行推广。商业应用甚至扩展到基于先进的Wi-Fi网络模型和蓝牙信标的室内定位。
然而，世界各地的紧急服务仍主要依赖于基于网络的移动电话跟踪，这种跟踪利用了细胞识别、细胞覆盖、三角测量或三边测量。这种方法的精度最多在几百米的范围，这比以前的固定电话号码到位置的映射要差得多。为了改善应急服务，需要一个更好的位置，这必须通过部署更密集的基站[2]或其他传感器或机制来提供，在手机本身实现[3-5]。
后一种选择在今天已经可行;现成的手机通常使用全球导航卫星系统(GNSS)接收器[6]，可以在大型众包数据库中查找附近的Wi-Fi接入点[7]和蜂窝id，这些数据库由苹果、谷歌或Combain等公司提供。如今，利用这种基于手机的定位的通用紧急呼叫解决方案要么是基于SMS，要么是基于http，要么是专有的绑定到特定PSAP的应用程序(例如，绑定到全国性PSAP的全国性移动应用程序)。
在本文中，我们描述了如何部署和测试基于数据的紧急呼叫端到端系统，该系统基于一个新的泛欧洲移动紧急应用(PEMEA)[8]的漫游能力标准。所述的测试平台包括一个移动应用程序，该应用程序具有一个后端服务器、PEMEA网络节点、一个PSAP系统和多个over- top和遗留通信服务，从PSTN和SIP调用到WebRTC视频呼叫。
在第二节中，我们将研究这一领域的相关工作。第3节概述了我们从各种系统涉众那里得到的需求。第4节介绍了系统设计，第5节介绍了实现细节。在第6节中，我们从技术和用户的角度对系统进行了评估。在第7节中，我们提供结束语。
2.相关工作
多个倡议和项目一直试图解决联系紧急服务和提供更好的信息更快的[9]问题。欧洲紧急电话号码协会(EENA)发布的NG112长期定义[10]文件主要关注于整合当今的异构电信系统，如遗留电话网络、基于IP的电信管理语音服务(如LTE语音)和专用紧急服务互联网协议网络(ESInet)。这些系统大多以电信语音为中心，将使用网关和一些专门的功能元素进行互连，用于呼叫路由、媒体转码、位置信息交换等。作为对未来的展望，与over- top (OTT)系统的集成也是可以预见的，比如基于web的解决方案，但是这些解决方案目前在实践中并不存在，只是最近才开始出现标准。各种研究项目正在将这个空间扩展到老年人和残疾人的无障碍获取、社会媒体整合、触觉学、自动呼叫等方面[11 -14]。
在这样的系统中，可能进行的基本数据交换已经为语音呼叫提供了一系列的可能的好处，从更高效，更不易出错的数据收集（每秒计数）开始[3、15、16]，到带有eCall的汽车领域到发生大型事件时在PSAP端自动分类的可能性[20]。
数据传递的实际机制通常在国家层面上得到解决，通过基于事件的消息传递或使用带有中央数据库的位置和信息平台(例如，波兰PLI CBD)，在运营商和PSAPs之间进行集成。
在移动领域一个引人注目的和最近的标准是高级移动定位(AML) (ETSI技术报告(TR) EMTEL-00035)，它被认为是对传统应急系统的增强。目前，市场上的大多数移动设备(基于Android和iOS)都支持AML，但只有少数国家支持目前支持它。当拨打紧急号码时，AML通常使用不可见的用户文本或二进制短信[21]发送与紧急事件相关的数据。也可以将其配置为将数据发布到REST API。
在这一领域的其他创新解决方案包括使用文本到语音的方式将预置信息和位置信息通过语音自动传递给调度程序，以及使用专有信息存储库来存储这些信息。另一种可能性是E.164号到URI映射(ENUM)标准，该标准将电话号码标识映射到域名系统(DNS)中的记录;这在一些国家已经实现，可以用于发现存储用户位置的位置信息服务器(LIS)。我们认为，这些解决方案在所需的灵活性和法规方面都不太合适。
此外，这些解决方案都没有充分解决国际漫游的问题。这不仅是因为旅行者数量的增加，还因为它最终实现了移动应用程序的可交换性。因此，一个小型的PSAP可以利用另一个地区或国家开发的更高质量的应用程序。最近公布的PEMEA标准[8,22,23]解决了这一问题，这也是电信应急基础设施系统与OTT世界实现互联的重要的第一步。在本文中，我们试图证明PEMEA在实际应用中的可行性。此外，我们的目标是证明它可以扩展到支持各种通信技术;我们特别关注基于web的OTT技术，它可以提供一个安全可靠的紧急服务生态系统，同时为新的开发人员和服务提供足够的开放。
3.需求工程
我们通过需求工程的过程定义了我们的设计指导方针和约束，并得到了许多现实世界中的紧急系统涉众的帮助，包括112个PSAP操作人员、第一反应人员、第三方解决方案开发人员和设备供应商。在此过程中，我们组织了多个工作坊和桌面练习来收集需求，并在系统实施之前和实施过程中进行反馈。除了一般要求可靠运作、方便使用、向来电者提供足够的回应、支援GNSS定位、支援视讯通讯，以迎合失聪及重听人士的需要外，我们亦提出多项不太明显的要求及特点:
(i)使用多种技术进行定位(基于设备:GNSS、Wi-Fi和基于移动网络)
(ii)有足够资料私隐的医疗资料传送:只可按需传送资料给救护车服务调度员，而无须经过中介人
(iii)能够捕捉尽可能多的上下文信息(电池电量、网络类型、数据下行和上行速度)，以指导进一步的通信决策和约束
(iv)国际漫游，使连接至其后端的应用程序可在海外使用
(v) PSAP本身的内容和基于web的服务(如基于web的调查)的轻松可扩展性
(vi)聊天、媒体(图片、上传视频)应存储在目的地PSAP的前提下
(vii)所有音频和视频通信都应记录并储存在目的地PSAP的前提下。
基于这些需求，系统设计被不断地细化，直到满足了需求，并且大多数现有的和期望的过程可以从头到尾执行。
4.系统设计
图1展示了系统的最终端到端体系结构，以及三组主要的消息流。在下面的部分中，我们将描述体系结构的每个子集。
4.1 PEMEA网络
该架构的核心部分如图1所示。PEMEA架构由基本的路由元素，即PEMEA Service Provider (PSP)组件组成。每个PSP可以是紧急消息的入口节点(称为始发PSP或oPSP)，也可以是与PSAP通信的出口节点(在本例中称为终止PSP或tPSP)。相同的节点可以在更高的级别上操作，并在psp之间转发消息，然后它将成为聚合服务提供商(ASP)。带有预定义格式的消息在psp和asp之间传递，称为紧急数据终端(EDS)消息。EDS在PEMEA规范[22]中使用XML模式定义，包括发送方的地理坐标，以及一些与路由相关的信息(生存时间、跳转列表等)。在PEMEA节点之间传递的所有信息都通过SSL REST api进行通信，这些API使用X.509证书进行相互身份验证。
为了保护系统，PEMEA希望所有进入和退出节点分别使用完全限定的Doman Name (FQDN)白名单来信任它们的源和目的地。
4.2 数据源和目标
EDS格式的紧急消息源称为应用程序提供者(AP)。在大多数情况下，一个来源应该是一个移动应用程序后端(中继所有用户的数据)，而不是一个单独的移动应用程序。相互认证和白名单机制可以很容易地阻止一个发送大量欺诈性呼叫的流氓后端。为了存储位置，可以使用位置信息服务器(LIS)，在我们的示例中，它与AP一起配置。
在网络的另一端，出口节点应该是PSAP。这里没有数据格式的要求，并且期望在个案的基础上与现有的私有PSAP软件进行集成。此外, 根据国家具体情况，PSAP通常在不同的层次结构中运行。接收到的数据可以在PSAP之间转发，从而可以共享同一组数据和通信通道。
4.3多媒体通信
PEMEA系统本身只是用来建立一个基本会话。没有通过PEMEA节点发送任何多媒体或附加通信。相反，源AP提供一组回调统一资源标识符(URI)，可用于建立多媒体流、触发调用和交换辅助数据。图1显示了通过回调URI建立媒体会话的过程：PSAP直接通知AP，一个Web实时通信(WebRTC)会话正在一个WebRTC Web应用程序中以一个提供的统一资源定位符(URL)地址进行。一旦移动应用程序和PSAP控制台打开相同的web视图，就可以使用基于web的技术建立通信会话。这使得部署实时多媒体通信、文本聊天或任何基于web的协作都变得很容易。其他参与者(如2级PSAPs、医务人员和消防员)也可以通过使用临时会话令牌打开聊天室的唯一URL来参与讨论。由于任何实际的通信服务都托管在PSAP管理和规范的基础设施上，因此它还允许记录会话，并在很大程度上解决了数据管理、数据保留和审计的问题。
4.4敏感的数据交换
传递初始PEMEA消息后，任何类型的数据交换都直接在PSAP和AP之间进行，但是，为了防止甚至阻止AP都无法访问敏感的相关数据(照片、媒体、医疗信息，类似)，实现更安全的机制，从图1可明显看出，如下:对敏感数据的请求被发送到AP，然后转发到移动应用程序。该请求包括在PSAP控制下的一个端点，在该端点可以安全地存放数据。在下一步中，应用程序请求用户允许存储私有数据，如果用户允许，数据将直接从移动应用程序发送到PSAP控制的端点。
5.试点实施
以下部分详细介绍了我们的试验实现，其最终目标是能够在与现实世界的涉众一起的大型演示活动中对系统进行评估。
5.1移动应用程序
Android手机应用程序有一个大的SOS/112(112是欧洲标准的紧急电话号码，相当于美国的911。有关更多信息，请访问http://www.eena.org/)按钮以启动呼叫。此外，该应用程序还包含一个详细的个人资料表单，用户可以事先提供所有相关的联系方式或医疗信息(见图3) 数据模型的灵感来自苹果公司在IOS系统上的Medical ID，该功能还暗示了将未来的紧急服务应用程序深度集成到移动操作系统后的外观。
5.2手机应用程序的后端
应用程序后端(AP)作为到PEMEA网络的链接，当移动应用程序位于NAT/防火墙之后时，作为从外部世界到达移动应用程序的中继。此外，我们将其与电信基础设施集成，以从移动网络本身获取另一个位置数据点。这些数据可以验证或使手机报告的位置无效。对于每一个紧急会议，后端服务器生成多个令牌和设立多个代理的url,这样所有通信发送到代理url传递回移动应用。最后，后端组装PEMEA Emergency Data Send （PEDS）消息,它然后转发到原始PEMEA服务提供者节点(oPSP)。
5.3基于GIS的消息路由的PEMEA PSP
PEMEA PSP元素是根据规范[22]从零开始开发的，并在与NEXES[14]项目合作伙伴的互操作性测试期间进行了测试。PSP元素接收传入的EDS消息，分析出位置，并将消息转发到一个已知的端点、另一个PSP或一个ASP元素(默认网关)(当没有更好的路由时)。PSP被设置为服务于斯洛文尼亚的13个地区(图4)，基于它们的形状文件，并使用PostGIS查询来确定一个位置是否属于这些地区。
5.4 PSAP
为了接收呼叫并发起进一步的通信，我们开发了一个简化的PSAP控制台，它具有基于超文本标记语言(HTML)的前端。使用web技术可以更容易地将已建立的紧急会议升级到其他基于web的通道，如HTML信息显示、基于websocket的聊天和WebRTC视频通信。
5.5多媒体:WebRTC服务器
多媒体通信是通过WebRTC实现的，WebRTC是一个基于html5的实时通信堆栈，在大多数现代web浏览器中都可以使用。我们使用WebRTC，因为它易于创建多党视频聊天室，并且要求简单，以加入第一个响应方的此类呼叫;对于WebRTC，只需要一个现代的Web浏览器。
然而，WebRTC是通过点对点的设计实现的，这意味着即使在法规要求的情况下，媒体也不容易被记录。因此，我们使用了一个稍微修改过的架构，用一个服务器代替一个对等点;然后，服务器充当通信的中心点，提供音频/视频混合和录制。基于开源的Kurento WebRTC服务器的带有活动视频聊天室的移动应用程序屏幕如图2(d)所示。
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[235870]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
