CN114980059A - 多设备联合呼叫方法和装置 - Google Patents

Abstract

本申请实施例提供一种多设备联合呼叫方法和装置，方法包括：第一设备建立与第二设备的短距通信；第一设备根据短距通信，获取第二设备的相关信息；第一设备向第三设备发送第二设备的相关信息和第一设备的相关信息；第一设备接收来自第三设备的寻呼；其中，寻呼为第三设备根据第二设备的相关信息和第一设备的相关信息发送的。这样，在第二设备的电量不足或出现异常等情况下，第二设备可以通过第一设备实现紧急信息的可靠发送，使得第三设备通过解析第二设备的相关信息和第一设备的相关信息，向第一设备发送寻呼并可以获得与救援相关的信息，从而派遣人员展开救援。

Description

多设备联合呼叫方法和装置

技术领域

本申请涉及智能驾驶技术领域，尤其涉及一种多设备联合呼叫方法和装置。

背景技术

在车辆发生碰撞的时候，为了使得车辆内用户及时得到救援，用户可以通过终端设备实现紧急呼叫。例如，基于终端设备上集成的高级移动设备定位(advanced mobilelocation，AML)，在AML开启的情况下，用户在拨打紧急电话时，一方面，终端设备会与报警平台建立语音通话；另一方面，终端设备会自动采集位置信息，并向救援平台上报位置信息、手机号或被叫号码等信息，从而救援平台可以向报警平台发送所获得的信息，从而报警平台可以根据接收的信息展开救援。

但是，通过终端设备实现紧急呼叫的方式存在限制；例如，当终端设备的电量不足时，可能使得上报信息的过程出现中断，导致救援平台无法获得准确的位置信息；或者，当终端设备出现一定程度的损坏时，不能支持实现有效的紧急呼叫，导致无法向救援平台上报位置信息。

发明内容

本申请实施例提供一种多设备联合呼叫方法和装置，应用于智能驾驶技术领域，方法包括：第一设备建立与第二设备的短距通信；第一设备根据短距通信，获取第二设备的相关信息；第一设备向第三设备发送第二设备的相关信息和第一设备的相关信息；第一设备接收来自第三设备的寻呼；其中，寻呼为第三设备根据第二设备的相关信息和第一设备的相关信息发送的。这样，在第二设备的电量不足或出现异常等情况下，第二设备可以通过第一设备实现紧急信息的可靠发送，从而第三设备通过解析第二设备的相关信息和第一设备的相关信息，向第一设备发送寻呼并可以获得与救援相关的信息，从而派遣人员展开救援。

第一方面，本申请实施例提供一种多设备联合呼叫方法，该方法包括：第一设备建立与第二设备的短距通信；第一设备根据短距通信，获取第二设备的相关信息；第一设备向第三设备发送第二设备的相关信息和第一设备的相关信息；第一设备接收来自第三设备的寻呼；其中，寻呼为第三设备根据第二设备的相关信息和第一设备的相关信息发送的。这样，在第二设备的电量不足或出现异常等情况下，第二设备可以通过第一设备实现紧急信息的可靠发送，从而第三设备通过解析第二设备的相关信息和第一设备的相关信息，向第一设备发送寻呼并可以获得与救援相关的信息，从而派遣人员展开救援。

一种可能的实现方式中，第一设备建立与第二设备的短距通信，包括：第一设备接收来自第二设备的连接建立请求；第一设备根据连接建立请求以及第一签约信息，验证第二设备的身份，第一签约信息用于指示允许第一设备协助呼叫第三设备的至少一个被协助设备；在第二设备的身份验证通过的情况下，第一设备建立与第二设备的短距通信。这样，第一设备可以通过该短距通信，获取第二设备的相关信息。

一种可能的实现方式中，连接建立请求包括请求原因，第一签约信息还包括第一设备允许建立短距通信的条件；第一设备根据连接建立请求以及第一签约信息，验证第二设备的身份，包括：在请求原因与条件匹配，且至少一个被协助设备包括第二设备的情况下，第二设备的身份验证通过。这样，第一设备可以根据接收的请求原因，正确地与发送该请求原因的第一设备建立短距通信。

一种可能的实现方式中，请求原因包括：第二设备检测到碰撞事件、第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。

一种可能的实现方式中，寻呼为语音通话的寻呼，该方法还包括：第一设备基于寻呼自动开启接听。

一种可能的实现方式中，上述接听为免提式接听。这样，用户可以基于免提式接听，通过语音通话上报自己周围的情况，从而提升救援效率。

一种可能的实现方式中，第一设备建立与第二设备的短距通信之前，该方法还包括：第一设备接收来自第三设备的短距通信功能开启指示；第一设备根据短距通信功能开启指示开启第一设备的短距通信功能。这样，第一设备在没有打开短距通信功能的情况下，可以根据短距通信功能开启指示开启短距通信功能。

一种可能的实现方式中，第一设备的相关信息包括下述的一种或多种：第一设备的位置信息、与第一设备相关的时间戳信息、第一设备的联系方式信息、第一设备的识别号码或第一设备的轨迹信息；或者，

第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

第二方面，本申请实施例提供一种多设备联合呼叫方法，该方法包括：第三设备接收来自第一设备的寻呼请求消息，寻呼请求消息包括第一设备的相关信息和第二设备的相关信息；第三设备根据寻呼请求消息，向第一设备发送寻呼。这样，第三设备可以通过寻呼了解第一设备周围的情况，同时，可以根据接收的信息实现紧急救援。

一种可能的实现方式中，第三设备根据寻呼请求消息，向第一设备发送寻呼，包括：第三设备向在第二设备发送寻呼无响应的情况下，向第一设备发送寻呼。这样，第三设备可以通过第一设备了解第一设备周围的情况，提升救援效率。

一种可能的实现方式中，第三设备根据寻呼请求消息，向第一设备发送寻呼之前，该方法还包括：第三设备接收来自第二设备的短距通信请求；第三设备根据短距通信请求以及第二签约信息，验证第一设备的身份，第二签约信息用于指示允许协助第二设备呼叫第三设备的至少一个协助设备；在第一设备的身份验证通过的情况下，第三设备向第一设备发送短距通信功能开启指示。这样，第三设备可以在第一设备没有开启短距通信功能的情况下，指示第一设备开启短距通信功能。

一种可能的实现方式中，第三设备根据短距通信请求以及签约信息，验证第一设备的身份，包括：在第一设备为协助设备的情况下，第一设备的身份验证通过。这样，第三设备可以正确地向第二设备发送短距通信功能开启指示。

一种可能的实现方式中，第一设备的相关信息包括下述的一种或多种：第一设备的位置信息、与第一设备相关的时间戳信息、第一设备的联系方式信息、第一设备的识别号码或第一设备的轨迹信息；或者，

第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

一种可能的实现方式中，寻呼为语音通话的寻呼。

第三方面，本申请实施例提供一种多设备联合呼叫方法，该方法包括：第二设备向第一设备发送连接建立请求；第二设备根据连接建立请求，与第一设备建立短距通信；第二设备基于短距通信，向第一设备发送第二设备的相关信息；

其中，连接建立请求包括请求原因，请求原因包括：第二设备检测到碰撞事件、第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。

一种可能的实现方式中，第二设备与第一设备发送连接建立请求之前，该方法还包括：第二设备向第三设备发送短距通信请求。

一种可能的实现方式中，第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

一种可能的实现方式中，第二设备向第一设备发送连接建立请求，包括：第二设备基于预设条件自动触发连接建立请求的发送。

第四方面，本申请实施例提供一种多设备联合呼叫装置，该多设备联合呼叫装置可以是第一设备，也可以是第一设备内的部件、芯片或者芯片系统。该多设备联合呼叫装置可以包括处理单元和通信单元。当该多设备联合呼叫装置是第一设备时，该处理单元可以是处理器，该通信单元可以是通信接口或接口电路。该多设备联合呼叫装置还可以包括存储单元，该存储单元可以是存储器。该存储单元用于存储指令，该处理单元执行该存储单元所存储的指令，以使该第一设备实现第一方面或第一方面的任意一种可能的实现方式中描述的一种多设备联合呼叫方法。当该多设备联合呼叫装置是第一设备内的部件、芯片或者芯片系统时，该处理单元可以是处理器，该通信单元可以是通信接口。例如，通信接口可以为输入/输出接口、管脚或电路等。该处理单元执行存储单元所存储的指令，以使该第一设备实现第一方面或第一方面的任意一种可能的实现方式中描述的一种多设备联合呼叫方法。该存储单元可以是该芯片内的存储单元(例如，寄存器、缓存等)，也可以是该第一设备内的位于该芯片外部的存储单元(例如，只读存储器、随机存取存储器等)。

示例性的，处理单元，用于建立与第二设备的短距通信；通信单元，用于根据短距通信，获取第二设备的相关信息；通信单元，用于向第三设备发送第二设备的相关信息和第一设备的相关信息；通信单元，用于接收来自第三设备的寻呼；其中，寻呼为第三设备根据第二设备的相关信息和第一设备的相关信息发送的。

一种可能的实现方式中，通信单元，具体用于接收来自第二设备的连接建立请求；处理单元，具体用于根据连接建立请求以及第一签约信息，验证第二设备的身份，第一签约信息用于指示允许第一设备协助呼叫第三设备的至少一个被协助设备；处理单元，具体用于在第二设备的身份验证通过的情况下，建立与第二设备的短距通信。

一种可能的实现方式中，连接建立请求包括请求原因，第一签约信息还包括第一设备允许建立短距通信的条件；处理单元，具体用于：在请求原因与条件匹配，且至少一个被协助设备包括第二设备的情况下，第二设备的身份验证通过。

一种可能的实现方式中，请求原因包括：第二设备检测到碰撞事件、第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。

一种可能的实现方式中，寻呼为语音通话的寻呼，处理单元，具体用于基于寻呼自动开启接听。

一种可能的实现方式中，上述接听为免提式接听。

一种可能的实现方式中，通信单元，还用于接收来自第三设备的短距通信功能开启指示；处理单元，还用于根据短距通信功能开启指示开启第一设备的短距通信功能。

一种可能的实现方式中，第一设备的相关信息包括下述的一种或多种：第一设备的位置信息、与第一设备相关的时间戳信息、第一设备的联系方式信息、第一设备的识别号码或第一设备的轨迹信息；或者，

第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

第五方面，本申请实施例提供一种多设备联合呼叫装置，该多设备联合呼叫装置可以是第三设备，也可以是第三设备内的部件、芯片或者芯片系统。该多设备联合呼叫装置可以包括处理单元和通信单元，通信单元可以理解为接收单元和发送单元。当该多设备联合呼叫装置是第三设备时，该处理单元可以是处理器，该通信单元可以是通信接口或接口电路。该多设备联合呼叫装置还可以包括存储单元，该存储单元可以是存储器。该存储单元用于存储指令，该处理单元执行该存储单元所存储的指令，以使该第三设备实现第二方面或第二方面的任意一种可能的实现方式中描述的一种多设备联合呼叫方法。当该多设备联合呼叫装置是第三设备内的部件、芯片或者芯片系统时，该处理单元可以是处理器，该通信单元可以是通信接口。例如，通信接口可以为输入/输出接口、管脚或电路等。该处理单元执行存储单元所存储的指令，以使该第三设备实现第二方面或第二方面的任意一种可能的实现方式中描述的一种多设备联合呼叫方法。该存储单元可以是该芯片内的存储单元(例如，寄存器、缓存等)，也可以是该第三设备内的位于该芯片外部的存储单元(例如，只读存储器、随机存取存储器等)。

示例性的，接收单元，用于接收来自第一设备的寻呼请求消息，寻呼请求消息包括第一设备的相关信息和第二设备的相关信息；发送单元，用于根据寻呼请求消息，向第一设备发送寻呼。

一种可能的实现方式中，发送单元，具体用于在向第二设备发送寻呼无响应的情况下，向第一设备发送寻呼。

一种可能的实现方式中，接收单元，还用于接收来自第二设备的短距通信请求；处理单元，用于根据短距通信请求以及第二签约信息，验证第一设备的身份，第二签约信息用于指示允许协助第二设备呼叫第三设备的至少一个协助设备；发送单元，具体用于在第一设备的身份验证通过的情况下，向第一设备发送短距通信功能开启指示。

一种可能的实现方式中，处理单元，具体用于：在第一设备为协助设备的情况下，第一设备的身份验证通过。

一种可能的实现方式中，第一设备的相关信息包括下述的一种或多种：第一设备的位置信息、与第一设备相关的时间戳信息、第一设备的联系方式信息、第一设备的识别号码或第一设备的轨迹信息；或者，

第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

一种可能的实现方式中，寻呼为语音通话的寻呼。

第六方面，本申请实施例提供一种多设备联合呼叫装置，该多设备联合呼叫装置可以是第二设备，也可以是第二设备内的部件、芯片或者芯片系统。该多设备联合呼叫装置可以包括处理单元和通信单元。当该多设备联合呼叫装置是第二设备时，该处理单元可以是处理器，该通信单元可以是通信接口或接口电路。该多设备联合呼叫装置还可以包括存储单元，该存储单元可以是存储器。该存储单元用于存储指令，该处理单元执行该存储单元所存储的指令，以使该第二设备实现第三方面或第三方面的任意一种可能的实现方式中描述的一种多设备联合呼叫方法。当该多设备联合呼叫装置是第二设备内的部件、芯片或者芯片系统时，该处理单元可以是处理器，该通信单元可以是通信接口。例如，通信接口可以为输入/输出接口、管脚或电路等。该处理单元执行存储单元所存储的指令，以使该第二设备实现第三方面或第三方面的任意一种可能的实现方式中描述的一种多设备联合呼叫方法。该存储单元可以是该芯片内的存储单元(例如，寄存器、缓存等)，也可以是该第二设备内的位于该芯片外部的存储单元(例如，只读存储器、随机存取存储器等)。

示例性的，通信单元，用于向第一设备发送连接建立请求；处理单元，用于根据连接建立请求，与第一设备建立短距通信；通信单元，用于基于短距通信，向第一设备发送第二设备的相关信息；

其中，连接建立请求包括请求原因，请求原因包括：第二设备检测到碰撞事件、第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。

一种可能的实现方式中，通信单元，还用于向第三设备发送短距通信请求。

一种可能的实现方式中，第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

一种可能的实现方式中，通信单元，具体用于基于预设条件自动触发连接建立请求的发送。

第七方面，本申请实施例提供一种多设备联合呼叫装置，该装置包括存储器和处理器，存储器存储计算机程序指令，处理器运行计算机程序指令，以实现如第一方面至第三方面任意的实现方式描述的多设备联合呼叫方法。

第八方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序或指令，当计算机程序或指令在计算机上运行时，使得计算机执行如第一方面至第三方面的任意一种实现方式中描述的多设备联合呼叫方法。

第九方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在处理器上运行时，使得多设备联合呼叫装置执行第一方面至第三方面的任意一种实现方式中描述的多设备联合呼叫方法。

第十方面，本申请实施例提供一种多设备联合呼叫系统，该系统包括如下中任一个或多个：第四方面及第四方面的各种可能的实现方式中描述的多设备联合呼叫装置，第五方面及第五方面的各种可能的实现方式中描述的多设备联合呼叫装置，第六方面及第六方面的各种可能的实现方式中描述的多设备联合呼叫装置。

第十一方面，本申请提供一种芯片或者芯片系统，该芯片或者芯片系统包括至少一个处理器和通信接口，通信接口和至少一个处理器通过线路互联，至少一个处理器用于运行计算机程序或指令，以进行第一方面至第三方面任意的实现方式中任一项所描述的多设备联合呼叫方法。其中，芯片中的通信接口可以为输入/输出接口、管脚或电路等。

在一种可能的实现中，本申请中上述描述的芯片或者芯片系统还包括至少一个存储器，该至少一个存储器中存储有指令。该存储器可以为芯片内部的存储单元，例如，寄存器、缓存等，也可以是该芯片的存储单元(例如，只读存储器、随机存取存储器等)。

应当理解的是，本申请的第二方面至第十一方面与本申请的第一方面的技术方案相对应，各方面及对应的可行实施方式所取得的有益效果相似，不再赘述。

附图说明

图1为现有技术中的一种紧急呼叫方式的示意图；

图2为现有技术中的一种紧急呼叫方式的示意图；

图3为本申请实施例提供的一种紧急呼叫场景的示意图；

图4为本申请实施例提供的一种多设备联合呼叫方法的流程示意图；

图5为本申请实施例提供的一种多设备联合呼叫方法的流程示意图；

图6为本申请实施例提供的一种多设备联合呼叫方法的流程示意图；

图7为本申请实施例提供的一种多设备联合呼叫方法的流程示意图；

图8为本申请实施例提供的一种多设备联合呼叫装置的结构示意图；

图9为本申请实施例提供的多设备联合呼叫设备的硬件结构示意图；

图10为本申请实施例提供的一种便携终端设备的结构示意图；

图11为本申请实施例提供的一种芯片的结构示意图。

具体实施方式

为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。例如，第一芯片和第二芯片仅仅是为了区分不同的芯片，并不对其先后顺序进行限定。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请实施例中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b，或c中的至少一项(个)，可以表示：a，b，c，a-b，a-c，b-c，或a-b-c，其中a，b，c可以是单个，也可以是多个。

在车辆发生碰撞时，为了使得车辆内用户及时得到救援，用户需要发起紧急呼叫，这样，基于发起的紧急呼叫，可以得到救援人员的救援，从而减少财产损失，降低人员伤亡。

一种可能的实现方式中，可以通过车辆内用户的终端设备，实现紧急呼叫。其中，终端设备的操作系统上集成了高级移动设备定位(advanced mobile location，AML)技术，AML技术是一种基于位置的紧急定位技术，这样，基于AML技术可以缩短救援平台确认用户位置所需的时间，从而缩短救援人员的抵达时间。

示例性的，图1为现有技术中的一种紧急呼叫方式的示意图，如图1所示，在AML开启状态下，用户在拨打紧急号码时，通过公共电信网，一方面，终端设备会与报警平台建立语音通话；另一方面，终端设备的操作系统会自动采集终端设备的位置信息，并自动向救援平台上报位置信息、手机号或被叫号码等信息，这样，救援平台向报警平台发送所获得的信息，从而报警平台可以及时派遣救援人员展开救援。其中，紧急号码可以包括110或120等，报警平台可以包括110报警平台或120报警平台等，救援平台可以包括公共安全应答点(public safety answering point，PSAP)等。

另一种可能的实现方式中，可以通过车载紧急呼叫(emergency call，eCall)装置，实现紧急呼叫。其中，eCall装置可以为厂商预安装好在车辆中的，也可以为用户自己安装在车辆中的。

示例性的，图2为现有技术中的一种紧急呼叫方式的示意图，如图2所示，当车辆发生碰撞等交通事故时，通过公共电信网，车载eCall装置可以自动启动带内紧急呼叫(in-band eCall)，建立车辆到报警平台的语音通信链路，语音通信链路用于实现车辆与报警平台之间的语音通话，由于语音通话中合成了位置信息、车辆识别号码(vehicleidentification number，VIN)等最小数据集(minimum data set，MSD)，这样，救援人员可以通过MSD，及时展开救援。其中，报警平台可以包括110报警平台或120报警平台等。

但是，通过终端设备实现紧急呼叫的方式，可能存在以下问题：在终端设备的电量不足时，可能使得上报信息的过程出现中断，导致救援平台无法获得准确的位置信息；在终端设备出现一定程度的损坏时，不能支持实现有效的紧急呼叫，导致无法向救援平台上报位置信息；进一步地，针对顺风车等共享出行存在的安全隐患，通过终端设备实现紧急呼叫时，若终端设备被遗弃，可能无法向救援平台上报正确的位置信息。

通过车载eCall装置实现紧急呼叫的方式，可能存在以下问题：在车载eCall装置的电量不足时，可能使得上报信息的过程出现中断，导致报警平台无法获得准确的位置信息；在车载eCall装置出现一定程度的损坏时，不能支持实现有效的紧急呼叫，导致无法向报警平台上报位置信息。

基于此，本申请实施例提供一种多设备联合呼叫方法，第一设备可以通过与第二设备之间的短距通信，获取第二设备的相关信息，并向第三设备发送第二设备的相关信息和第一设备的相关信息，从而第三设备基于获取的相关信息，向第一设备发送寻呼。这样，在第二设备的电量不足或出现异常等情况下，第二设备可以通过第一设备实现紧急信息的可靠发送，使得第三设备通过解析第二设备的相关信息和第一设备的相关信息，向第一设备发送寻呼并可以获得与救援相关的信息，从而派遣人员展开救援。

本申请实施例的方法应用于紧急呼叫场景，示例性的，图3为本申请实施例提供的一种紧急呼叫场景的示意图，如图3所示，该场景中包括第一设备、第二设备和第三设备，第一设备可以为便携终端设备或者车载设备等，第二设备可以为便携终端设备或者车载设备等，第三设备可以为公共安全应答点(public safety answering point，PSAP)中的设备；其中，第一设备与第二设备的具体内容，与实现紧急呼叫的场景有关。

例如，场景A：用户的车辆发生碰撞等交通事故，由于车载设备的电量不足或者出现一定程度的损坏，不能支持实现有效的紧急呼叫，因而，可以通过用户的便携终端设备实现紧急呼叫。该场景A中，第一设备为便携终端设备，第二设备为车载设备。其中，便携终端设备可以为手机或智能手表等，车载设备可以为车载终端等。可以理解，便携终端设备与车载设备的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

场景B：用户在行驶中发生危险，用户的便携终端设备的电量不足或者被限制使用等，不能支持实现有效的紧急呼叫，可以通过车载设备实现紧急呼叫。该场景B中，第一设备为车载设备，第二设备为便携终端设备。车载设备与便携终端设备的内容，可以参考上述内容的描述，在此不再赘述。可以理解，便携终端设备与车载设备的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

结合上述场景A和场景B，在第二设备的电量不足或出现异常等情况下，第一设备可以协助第二设备，通过与第三设备之间的寻呼，实现紧急呼叫。

在第二设备需要向第一设备发送信息时，第二设备可以通过与第一设备之间的短距通信链路，将信息发送给第一设备，从而第一设备将从第二设备接收的信息转发给第三设备。

在第一设备需要向第三设备发送信息时，第一设备将从第二设备接收的信息以及自身的信息发送给第三设备，从而第三设备基于获取的消息，向第一设备发送寻呼，实现紧急呼叫。

需要说明的是，第一设备包括通信模块和卫星定位模块等，第二设备包括通信包括和卫星定位模块等。可以理解，第一设备和第二设备中所包括的其他模块，可以根据实际应用场景设定，本申请实施例不作限定。

通信模块具有短距通信功能，用于第一设备建立与第二设备之间的短距通信，从而使得第一设备可以通过短距通信链路接收来自第二设备的第二设备的相关信息；或者，用于第二设备与第一设备建立短距通信，使得第二设备可以通过短距通信链路向第一设备发送第二设备的相关信息。

卫星定位模块具有定位功能，可以通过北斗卫星和/或全球定位系统(globalpositioning system，GPS)等，实现对第一设备或第二设备的定位。

例如，当车辆发生碰撞等交通事故时，则第一设备的卫星定位模块向GPS发送位置信息请求，触发GPS获取位置信息，从而实现对第一设备的定位。可以理解，GPS获取位置信息的具体实现方式，本申请实施例不作限定。

需要说明的是，第二设备的卫星定位模块实现对第二设备的定位的过程，与第一设备的卫星定位模块实现对第一设备的定位的过程类似，在此不再赘述。可以理解，第二设备的卫星定位模块实现对第二设备的定位的实现方式，也可以根据实际应用场景设定，本申请实施例不作限定。

下面以具体的实施例对本申请实施例的技术方案以及本申请实施例的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以独立实现，也可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

示例性的，图4为本申请实施例提供的一种多设备联合呼叫方法的流程示意图，如图4所示，可以包括以下步骤：

S401：第一设备建立与第二设备的短距通信。

本申请实施例中，短距通信用于第一设备与第二设备之间传输消息，从而实现信息共享；第一设备建立与第二设备的短距通信的一种可能的实现方式为：第一设备基于蓝牙(bluetooth)建立与第二设备的短距通信。

示例性的，在第一设备且第二设备开启蓝牙的情况下，第一设备查找第一范围内的设备，在找到第二设备后，通过在第一设备上输入与第二设备相关的个人识别码(personal identification number，PIN)，在PIN输入正确的情况下，第一设备与第二设备连接成功，从而第一设备建立与第二设备的短距通信；其中，第一范围可以指的是第一设备周围50米的范围。可以理解，第一范围的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定；第一设备基于蓝牙建立与第二设备的短距通信的具体实现方式，本申请实施例不作限定。

例如，以上述场景A为例时，第一设备为便携终端设备，第二设备为车载设备，则S401可以描述为：便携终端设备建立与车载设备的短距通信，其中，便携终端设备建立与车载设备的短距通信的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，第二设备为便携终端设备，则S401可以描述为：车载设备建立与便携终端设备的短距通信，其中，车载设备建立与便携终端设备的短距通信的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

S402：第一设备根据短距通信，获取第二设备的相关信息。

本申请实施例中，第二设备可以为便携终端设备或者车载设备等，因而，在第二设备不同时，第二设备的相关信息的具体内容也不同。

例如，在上述场景A中，第二设备为车载设备，则第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的识别号码或第二设备的轨迹信息等。

其中，第二设备的位置信息用于指示车载设备的位置，可以包括车载设备的经度和纬度等，或者可以理解为，第二设备的位置信息用于指示用户所在的位置，可能的方式中，第二设备的位置信息包括车载设备的经度、纬度以及高程；与第二设备相关的时间戳信息可以包括车载设备发送相关信息的时间等，第二设备的识别号码可以包括车辆识别号码(vehicle identification number，VIN)等，VIN中可以包括车辆的生产厂家、年代、车型、车身型式或者组装地点等信息，第二设备的轨迹信息可以包括车辆因移动而形成的路线信息等。可以理解，第二设备的相关信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

在上述场景B中，第二设备为便携终端设备，则第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因等。可以理解，第二设备的相关信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

其中，第二设备的位置信息、与第二设备相关的时间戳信息或第二设备的轨迹信息的内容，可以参考上述内容适应描述，在此不再赘述；第二设备的联系方式信息可以包括便携终端设备的手机号码、便携终端设备上的联系人信息或者用户利用便携终端设备所拨打的号码信息等，第二设备被协助呼叫第三设备的原因用于指示第二设备出现异常，该原因可以包括第二检测到碰撞事件或者第二设备检测到求救事件等。可以理解，第二设备的相关信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

可能的实现中，第二设备的相关信息中还可以包括频率指示信息，这样，当第一设备获取第二设备的相关信息后，第一设备可以以该频率向第三设备发送信息。例如，频率可以为10赫兹(Hz)，可以理解，频率的具体值也可以根据实际应用场景设定，本申请实施例不作限定。

本申请实施例中，第一设备根据短距通信，获取第二设备的相关信息，可以包括以下几种可能的实现方式：

第一种可能的实现方式中，第一设备根据短距通信，周期性地接收来自第二设备的第二设备的相关信息。

示例性的，在用户驾驶车辆的过程中，第二设备采集了相关信息，由于第一设备建立了与第二设备的短距通信，因而，第二设备可以通过短距通信链路向第一设备周期性的发送第二设备的相关信息，周期性的时间可以为5分钟，这样，第二设备可以每隔5分钟接收来自第二设备的第二设备的相关信息。可以理解，周期性的时间的具体值，也可以根据实际应用场景设定，本申请实施例不作限定；第一设备根据短距通信，周期性地接收来自第二设备的第二设备的相关信息的具体实现方式，本申请实施例不作限定。

第二种可能的实现方式中，基于一定的触发条件，第一设备根据短距通信，接收来自第二设备的第二设备的相关信息。

示例性的，在用户驾驶车辆的过程中，第二设备采集了相关信息，若触发条件为车辆发生了碰撞，则基于第二设备与第二设备之间的短距通信，第二设备向第一设备发送第二设备的相关信息，从而，第一设备接收来自第二设备的第二设备的相关信息。可以理解，触发条件的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

例如，以上述场景A为例时，第一设备为便携终端设备，第二设备为车载设备，则S402可以描述为：便携终端设备根据短距通信，获取车载设备的相关信息；其中，便携终端设备根据短距通信，获取车载设备的相关信息的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，第二设备为便携终端设备，则S402可以描述为：车载设备根据短距通信，获取便携终端设备的相关信息；其中，车载设备根据短距通信，获取便携终端设备的相关信息的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

S403：第一设备向第三设备发送第二设备的相关信息和第一设备的相关信息。

本申请实施例中，第一设备可以为便携终端设备或者车载设备等，因而，在第一设备不同时，第一设备的相关信息的内容也不同。

例如，在上述场景A中，第一设备为便携终端设备，第一设备的相关信息的内容，与第二设备为便携终端设备时的相关信息的内容类似，在此不再赘述。可以理解，第一设备的相关信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

在上述场景B中，第一设备为车载设备，第一设备的相关信息的内容，与第二设备为车载设备时的相关信息的内容类似，在此不再赘述；可能的实现中，第一设备的相关信息还可以包括第一设备的联系方式，该联系方式信息与第二设备为便携终端设备时的联系方式信息相同。可以理解，第一设备的相关信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

具体的，第一设备向第三设备发送第二设备的相关信息和第一设备的相关信息的一种可能的实现方式为：第一设备周期性的向第三设备发送第二设备的相关信息和第一设备的相关信息。

示例性的，由于第一设备周期性地接收来自第二设备的第二设备的相关信息，因而，第一设备在接收第二设备的相关信息，且收集了第一设备的相关信息后，也可以周期性的向第三设备发送第二设备的相关信息和第一设备的相关信息，周期性的时间可以为7分钟，这样，第三设备可以每隔7分钟接收来自第一设备的第二设备的相关信息和第一设备的相关信息。可以理解，周期性的时间的具体值，也可以根据实际应用场景设定，本申请实施例不作限定；第一设备向第三设备发送第二设备的相关信息和第一设备的相关信息的具体实现方式，本申请实施例不作限定。

例如，以上述场景A为例时，第一设备为便携终端设备，第二设备为车载设备，第三设备为PSAP，则S403可以描述为：便携终端设备向PSAP发送车载设备的相关信息和便携终端设备的相关信息；其中，便携终端设备向PSAP发送车载设备的相关信息和便携终端设备的相关信息的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，第二设备为便携终端设备，第三设备为PSAP，则S403可以描述为：车载设备向PSAP发送便携终端设备的相关信息和车载设备的相关信息；其中，车载设备向PSAP发送便携终端设备的相关信息和车载设备的相关信息的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

S404：第一设备接收来自第三设备的寻呼。

本申请实施例中，寻呼可以包括语音通话的寻呼等，基于该寻呼，第一设备可以自动接通免提，并开启采集车辆内的语音信息，从而使得第一设备可以及时向第三设备上报周围的情况。可以理解，寻呼的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

本申请实施例中，寻呼为第三设备根据第二设备的相关信息和第一设备的相关信息发送的，因而，第一设备接收来自第三设备的寻呼的可能的实现方式为：第三设备根据第二设备的相关信息和第一设备的相关信息向第一设备发送寻呼，适应的，第一设备接收来自第三设备的寻呼。

示例性的，第三设备接收来自第一设备的第二设备的相关信息和第一设备的相关信息后，第三设备通过解析第一设备的相关信息和第二设备的相关信息，若第三设备向第二设备发送寻呼，但是，第二设备无响应，第三设备可以向第一设备发送寻呼，适应的，第一设备接收来自第三设备的寻呼。可以理解，第一设备接收来自第三设备的寻呼的具体实现方式，本申请实施例不作限定。

示例性的，第三设备接收来自第一设备的第二设备的相关信息和第一设备的相关信息后，第三设备通过解析第一设备的相关信息和第二设备的相关信息，直接向第一设备发送寻呼，适应的，第一设备接收来自第三设备的寻呼。可以理解，第一设备接收来自第三设备的寻呼的具体实现方式，可以根据实际应用场景设定，本申请实施例不作限定。

例如，以上述场景A为例时，第一设备为便携终端设备，第三设备为PSAP，则S404可以描述为：便携终端设备接收来自PSAP的寻呼；其中，便携终端设备接收来自PSAP的寻呼的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，第三设备为PSAP，则S404可以描述为：车载设备接收来自PSAP的寻呼；其中，车载设备接收来自PSAP的寻呼的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

综上所述，在本申请实施例中，第一设备通过与第二设备的短距通信，可以转发第一设备的相关信息，实现紧急信息的可靠发送，使得第三设备通过解析第二设备的相关信息和第一设备的相关信息，向第一设备发送寻呼并可以获得与救援相关的信息，从而派遣人员展开救援。

在图4所示的实施例的基础上，以上述场景A为例，示例性的，图5为本申请实施例提供的一种多设备联合呼叫方法的流程示意图，在本申请实施例中，第一设备为便携终端设备，第二设备为车载设备，第三设备为PSAP，便携终端设备可以协助车载设备呼叫PSAP，或者可以理解为，车载设备可以被便携终端设备协助呼叫PSAP。

如图5所示，可以包括以下步骤：

S501：车载设备向便携终端设备发送连接建立请求。

本申请实施例中，连接建立请求包括请求原因等，请求原因可以包括：第二设备检测到碰撞事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。可以理解，请求原因的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

其中，第二设备检测到碰撞事件可以理解为：车载设备通过碰撞传感器检测到碰撞的冲击力大于或等于第一阈值，则车载设备检测到碰撞事件。其中，第一阈值的具体值，可以根据实际应用场景设定，本申请实施例不作限定。

其中，第二设备的电量不足可以理解为：车载设备的电量小于第二阈值；其中，第二阈值的具体值，可以根据实际应用场景设定，本申请实施例不作限定。

其中，第二设备为被协助设备可以理解为：车载设备出现异常情况，车载设备可以在其他设备的协助下实现紧急呼叫，则车载设备为被协助设备，其他设备为协助设备；其中，异常情况可以包括车载设备电量不足等情况，可以理解，异常情况的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

本申请实施例中，车载设备向便携终端设备发送连接建立请求，可能的实现方式为：第二设备基于预设条件自动触发连接建立请求的发送。

示例性的，在预设条件为车载设备呼叫PSAP失败时，车载设备可以自动触发连接建立请求的发送；可以理解，车载设备向便携终端设备发送连接建立请求的具体实现方式，本申请实施例不作限定。

需要说明的是，预设条件的具体内容可以与请求原因中的至少一个相同，预设条件的具体内容也可以根据实际应用场景设定，本申请实施例不作限定。

本申请实施例中，车载设备向便携终端设备发送连接建立请求的可能实现方式为：车载设备通过蓝牙、绿牙、车联网无线通信技术(vehicle to everything，V2X)、无线保真(wireless fidelity，WIFI)等方式，向便携终端设备发送连接建立请求。

示例性的，在便携终端设备且车载设备开启蓝牙的情况下，车载设备查找第二范围内的设备，在找到便携终端设备后，通过在车载设备上输入与便携终端设备相关的PIN，在PIN输入正确的情况下，车载设备可以向便携终端设备发送连接建立请求；其中，第二范围可以指的是车载设备周围30米的范围。可以理解，第二范围的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定；车载设备通过蓝牙向便携终端设备发送连接建立请求的具体实现方式，本申请实施例不作限定。

S502：便携终端设备根据连接建立请求以及第一签约信息，验证车载设备的身份。

本申请实施例中，第一签约信息包括用于指示允许便携终端设备协助呼叫PSAP的至少一个被协助设备等；可以理解，第一签约信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

本申请实施例中，第一签约信息还包括便携终端设备允许建立短距通信的条件，因而，便携终端设备根据连接建立请求以及第一签约信息，验证车载设备的身份，可能的实现方式为：在请求原因与条件匹配，且至少一个被协助设备包括车载设备的情况下，车载设备的身份验证通过。

示例性的，便携终端设备允许建立短距通信的条件包括请求原因中的至少一项，且便携终端设备协助呼叫PSAP的至少一个被协助设备包括车载设备，则判定请求原因与条件匹配，且至少一个被协助设备包括车载设备，从而车载设备的身份验证通过。

S503：在车载设备的身份验证通过的情况下，便携终端设备建立与车载设备的短距通信。

示例性的，在车载设备的身份验证通过的情况下，便携终端设备可以通过蓝牙建立与车载设备的短距通信，便携终端设备通过蓝牙建立与车载设备的短距通信的实现方式，可以参考S401的内容适应描述，在此不再赘述。可以理解，便携终端设备建立与车载设备的短距通信的实现方式，也可以根据实际应用场景设定，本申请实施例不作限定。

S504：车载设备向便携终端设备发送车载设备的相关信息。

相应的，便携终端设备接收来自车载设备的车载设备的相关信息。

S505：便携终端设备向PSAP发送车载设备的相关信息和便携终端设备的相关信息。

相应的，PSAP接收来自便携终端设备的车载设备的相关信息和便携终端设备的相关信息，车载设备的相关信息和便携终端设备的相关信息的内容，可以参考上述内容的描述，在此不再赘述。

S506：PSAP根据车载设备的相关信息和便携终端设备的相关信息，向便携终端设备发送寻呼。

本申请实施例中，PSAP根据车载设备的相关信息和便携终端设备的相关信息，向便携终端设备发送寻呼的可能的实现方式为：PSAP在向车载设备发送寻呼无响应的情况下，向便携终端设备发送寻呼。

示例性的，PSAP收到便携终端设备发送的信息后，PSAP可以向车载设备建立链路连接实现语音通话，当车载设备由于电量不足或出现异常等原因无法连接时，PSAP向便携终端设备发送寻呼，实现紧急呼叫。

S507：便携终端设备基于寻呼自动开启接听。

本申请实施例中，接听可以为免提式接听，这样，在用户因受伤而无法使用便携终端设备的语音通话时，便携终端设备可以自动接听来自PSAP的寻呼，实现紧急呼叫免提通话，从而使得PSAP可以根据该免提通话，采集语音信息，了解便携终端设备周围的情况，提升救援效率。

需要说明的是，便携终端设备PSAP发送车载设备的相关信息和便携终端设备的相关信息后，便携终端设备也可以自动开启接听。

需要说明的是，本申请实施例的S501和S502、S504和S507是可选步骤，可以根据实际应用场景设置可选步骤的一个或多个，本申请实施例各步骤之间的先后顺序也可以根据实际应用场景进行调整，本申请实施例对此不作具体限定。

综上所述，在本申请实施例中，便携终端设备接收来自车载设备的连接建立请求，并根据连接建立请求以及第一签约信息，在验证车载设备的身份通过的情况下，从而便携终端设备建立与车载设备的短距通信，使得车载设备可以向便携终端设备发送相关信息，从而便携终端设备可以向PSAP发送车载设备的相关信息和便携终端设备的相关信息，这样，PSAP可以根据车载设备的相关信息和便携终端设备的相关信息，在向车载设备发送寻呼无响应的情况下，可以向便携终端设备发送寻呼，由于便携终端设备自动开启了接听，因而，便携终端设备可以自动接听来自PSAP的寻呼，实现紧急呼叫免提通话，从而保证了在车载设备电量不足等的情况下，通过便携终端设备实现紧急呼叫。

在图4所示的实施例的基础上，以上述场景B为例，示例性的，图6为本申请实施例提供的一种多设备联合呼叫方法的流程示意图，在本申请实施例中，第一设备为车载设备，第二设备为便携终端设备，第三设备为PSAP，车载设备可以协助便携终端设备呼叫PSAP，或者可以理解为，便携终端设备可以被车载设备协助呼叫PSAP。

如图6所示，可以包括以下步骤：

S601：便携终端设备向车载设备发送连接建立请求。

本申请实施例中，连接建立请求包括请求原因等，请求原因可以包括：第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。可以理解，请求原因的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

其中，第二设备检测到求救事件可以理解为：用户通过便携终端设备向报警平台拨打电话，则便携终端设备检测到求救事件。可以理解，便携终端设备检测到求救事件的具体实现方式，本申请实施例不作限定。

其中，第二设备的电量不足可以理解为：用户的便携终端设备的电量小于第三阈值，第三阈值的具体值，可以根据实际应用场景设定，本申请实施例不作限定。

其中，第二设备为被协助设备可以理解为：便携终端设备出现异常情况，便携终端设备可以在其他设备的协助下实现紧急呼叫，则便携终端设备为被协助设备，其他设备为协助设备；其中，异常情况可以包括便携终端设备电量不足等情况；可以理解，异常情况的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

需要说明的是，搭乘顺风车的用户通过便携终端设备向报警平台拨打电话时，在通话被挂断且便携终端设备的位置信息不变的情况下，由于便携终端设备检测到了求救事件，因而便携终端设备可以通过该顺风车内的车载设备实现紧急呼叫。

本申请实施例中，便携终端设备向车载设备发送连接建立请求的实现方式，可以参考S501的内容适应描述，在此不再赘述；可以理解，便携终端设备向车载设备发送连接建立请求的实现方式，也可以根据实际应用场景设定，本申请实施例不作限定。

S602：车载设备根据连接建立请求以及第一签约信息，验证便携终端设备的身份。

本申请实施例中，S602可以参考图5对应的S502的内容适应描述，在此不再赘述；

需要说明的是，在验证便携终端设备的身份时，若用户搭乘的是顺风车，可以通过用户搭乘顺风车时注册的手机信息，验证用户的便携终端设备的身份；或者，可以通过该顺风车车主的手机信息，手机信息中包括位置信息等，因而，通过该位置信息查找第三范围内的设备，验证便携终端设备的身份；其中，第三范围可以指的是该位置信息周围15米的范围，可以理解，第三范围的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

S603：在便携终端设备的身份验证通过的情况下，车载设备建立与便携终端设备的短距通信。

S604：便携终端设备向车载设备发送便携终端设备的相关信息。

S605：车载设备向PSAP发送便携终端设备的相关信息和车载设备的相关信息。

S606：PSAP根据便携终端设备的相关信息和车载设备的相关信息，向车载设备发送寻呼。

S607：车载设备基于寻呼自动开启接听。

本申请实施例中，S603-S607可以参考图5所示的实施例的S503-S507的内容适应描述，在此不再赘述，与图5所示的实施例不同的是，在图6所示的实施例中，第一设备为车载设备，第二设备为便携终端设备。

综上所述，在本申请实施例中，车载设备接收来自便携终端设备的连接建立请求，并根据连接建立请求以及第一签约信息，在验证便携终端设备的身份通过的情况下，从而车载设备建立与便携终端设备的短距通信，使得便携终端设备可以向车载设备发送相关信息，从而车载设备可以向PSAP发送车载设备的相关信息和便携终端设备的相关信息，这样，PSAP可以根据车载设备的相关信息和便携终端设备的相关信息，向车载设备发送寻呼，由于车载设备自动开启了接听，因而，车载设备可以自动接听来自PSAP的寻呼，实现紧急呼叫免提通话，从而保证了在便携终端设备电量不足等的情况下，通过车载设备实现紧急呼叫。

在图4-图6所示的实施例的基础上，示例性的，图7为本申请实施例提供的一种多设备联合呼叫方法的流程示意图，本申请实施例的方法可以在S401、S501或者S601之前执行，如图7所示，可以包括以下步骤：

S701：第二设备向第三设备发送短距通信请求。

相应地，第三设备接收来自第二设备的短距通信请求，短距通信请求用于第二设备请求与第一设备建立短距通信，从而使得第二设备基于建立的短距通信，向第一设备发送第二设备的相关信息，本申请实施例对第二设备向第三设备发送短距通信请求的实现方式，不作限定。

例如，以上述场景A为例时，第二设备为车载设备，第三设备为PSAP，则S701可以描述为：车载设备向PSAP发送短距通信请求；其中，车载设备向PSAP发送短距通信请求的具体实现方式，本申请实施例不作限定。

以上述场景B为例时，第二设备为便携终端设备，第三设备为PSAP，则S701可以描述为：便携终端设备向PSAP发送短距通信请求；其中，便携终端设备向PSAP发送短距通信请求的具体实现方式，本申请实施例不作限定。

S702：第三设备根据短距通信请求以及第二签约信息，验证第一设备的身份。

本申请实施例中，第二签约信息用于指示允许协助第二设备呼叫第三设备的至少一个协助设备。可以理解，第二签约信息的具体内容，也可以根据实际应用场景设定，本申请实施例不作限定。

本申请实施例中，第三设备根据短距通信请求以及第二签约信息，验证第一设备的身份的可能的实现方式为：在第一设备为协助设备的情况下，第一设备的身份验证通过。例如，第二签约信息中包括第一设备的身份信息，从而判断第一设备为协助设备，则第一设备的身份验证通过。

例如，以上述场景A为例时，第一设备为便携终端设备，第三设备为PSAP，则S702可以描述为：PSAP根据短距通信请求以及第二签约信息，验证便携终端设备的身份；其中，PSAP根据短距通信请求以及第二签约信息，验证便携终端设备的身份的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，第三设备为PSAP，则S702可以描述为：PSAP根据短距通信请求以及第二签约信息，验证车载设备的身份；其中，PSAP根据短距通信请求以及第二签约信息，验证车载设备的身份的实现方式，可以参考上述内容适应描述，也可以根据实际应用场景设定，本申请实施例不作限定。

S703：在第一设备的身份验证通过的情况下，第三设备向第一设备发送短距通信功能开启指示。

相应地，第一设备接收来自第三设备的短距通信功能开启指示，短距通信功能开启指示用于指示第一设备开启短距通信功能，从而使得第二设备可以和第一设备之间建立短距通信；本申请实施例对第三设备向第一设备发送短距通信功能开启指示的具体实现方式，不作限定。

例如，以上述场景A为例时，第一设备为便携终端设备，第三设备为PSAP，则S703可以描述为：在便携终端设备的身份验证通过的情况下，PSAP向便携终端设备发送短距通信功能开启指示；其中，PSAP向便携终端设备发送短距通信功能开启指示的具体实现方式，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，第三设备为PSAP，则S703可以描述为：在车载设备的身份验证通过的情况下，PSAP向车载设备发送短距通信功能开启指示；其中，PSAP向车载设备发送短距通信功能开启指示的具体实现方式，本申请实施例不作限定。

S704：第一设备根据短距通信功能开启指示开启第一设备的短距通信功能。

本申请实施例中，第一设备开启短距通信后，第二设备可以向第一设备发送第一设备的相关信息，进而第二设备向第三设备发送第一设备的相关信息和第一设备的相关信息，使得第三设备通过解析第二设备的相关信息和第一设备的相关信息，向第一设备发送寻呼。

例如，以上述场景A为例时，第一设备为便携终端设备，则S704可以描述为：便携终端设备根据短距通信功能开启指示开启便携终端设备的短距通信功能；其中，便携终端设备开启便携终端设备的短距通信功能的具体实现方式，本申请实施例不作限定。

以上述场景B为例时，第一设备为车载设备，则S704可以描述为：车载设备根据短距通信功能开启指示开启车载设备的短距通信功能；其中，车载设备开启车载设备的短距通信功能的具体实现方式，本申请实施例不作限定。

综上所述，在本申请实施例中，第三设备接收来自第二设备的短距通信请求，并根据短距通信请求以及第二签约信息，在验证第一设备的身份通过的情况下，向第一设备发送短距通信功能开启指示，使得第一设备可以根据短距通信功能开启指示开启第一设备的短距通信功能，使得第二设备可以和第一设备建立短距通信，并可以根据该短距通信发送相关信息，从而提升救援效率。

上面结合图4-图7，对本申请实施例的方法进行了说明，下面对本申请实施例提供的执行上述方法的多设备联合呼叫装置进行描述。本领域技术人员可以理解，方法和装置可以相互结合和引用，本申请实施例提供的一种多设备联合呼叫装置可以执行上述多设备联合呼叫方法中第一设备的步骤，另一种多设备联合呼叫装置可以执行上述实施例中的多设备联合呼叫方法中第二设备所执行的步骤，再一种多设备联合呼叫装置可以执行上述实施例中的多设备联合呼叫方法中第三设备执行的步骤。

下面以采用对应各个功能划分各个功能模块为例进行说明：

示例性的，图8为本申请实施例提供的一种多设备联合呼叫装置的结构示意图，该多设备联合呼叫装置80可以是本申请实施例中的第一设备、第二设备或第三设备，也可以为应用于第一设备、第二设备或第三设备中的部件、芯片或芯片系统。

如图8所示，多设备联合呼叫装置80包括：处理单元801和通信单元802；其中，通信单元802用于支持多设备联合呼叫装置执行信息发送或接收的步骤，处理单元801用于支持多设备联合呼叫装置执行信息处理的步骤。

示例性的，以应用于第一设备的多设备联合呼叫装置为例，处理单元，用于建立与第二设备的短距通信；通信单元，用于根据短距通信，获取第二设备的相关信息；通信单元，用于向第三设备发送第二设备的相关信息和第一设备的相关信息；通信单元，用于接收来自第三设备的寻呼；其中，寻呼为第三设备根据第二设备的相关信息和第一设备的相关信息发送的。

一种可能的实现方式中，通信单元，具体用于接收来自第二设备的连接建立请求；处理单元，具体用于根据连接建立请求以及第一签约信息，验证第二设备的身份，第一签约信息用于指示允许第一设备协助呼叫第三设备的至少一个被协助设备；处理单元，具体用于在第二设备的身份验证通过的情况下，建立与第二设备的短距通信。

一种可能的实现方式中，连接建立请求包括请求原因，第一签约信息还包括第一设备允许建立短距通信的条件；处理单元，具体用于：在请求原因与条件匹配，且至少一个被协助设备包括第二设备的情况下，第二设备的身份验证通过。

一种可能的实现方式中，请求原因包括：第二设备检测到碰撞事件、第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。

一种可能的实现方式中，寻呼为语音通话的寻呼，处理单元，具体用于基于寻呼自动开启接听。

一种可能的实现方式中，上述接听为免提式接听。

一种可能的实现方式中，通信单元，还用于接收来自第三设备的短距通信功能开启指示；处理单元，还用于根据短距通信功能开启指示开启第一设备的短距通信功能。

一种可能的实现方式中，第一设备的相关信息包括下述的一种或多种：第一设备的位置信息、与第一设备相关的时间戳信息、第一设备的联系方式信息、第一设备的识别号码或第一设备的轨迹信息；或者，

第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

示例性的，以应用于第三设备的多设备联合呼叫装置为例，通信单元可以理解为接收单元和发送单元，接收单元，用于接收来自第一设备的寻呼请求消息，寻呼请求消息包括第一设备的相关信息和第二设备的相关信息；发送单元，用于根据寻呼请求消息，向第一设备发送寻呼。

一种可能的实现方式中，发送单元，具体用于在向第二设备发送寻呼无响应的情况下，向第一设备发送寻呼。

一种可能的实现方式中，接收单元，还用于接收来自第二设备的短距通信请求；处理单元，用于根据短距通信请求以及第二签约信息，验证第一设备的身份，第二签约信息用于指示允许协助第二设备呼叫第三设备的至少一个协助设备；发送单元，具体用于在第一设备的身份验证通过的情况下，向第一设备发送短距通信功能开启指示。

一种可能的实现方式中，处理单元，具体用于：在第一设备为协助设备的情况下，第一设备的身份验证通过。

一种可能的实现方式中，第一设备的相关信息包括下述的一种或多种：第一设备的位置信息、与第一设备相关的时间戳信息、第一设备的联系方式信息、第一设备的识别号码或第一设备的轨迹信息；或者，

第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

一种可能的实现方式中，寻呼为语音通话的寻呼。

示例性的，以应用于第二设备的多设备联合呼叫装置为例，通信单元，用于向第一设备发送连接建立请求；处理单元，用于根据连接建立请求，与第一设备建立短距通信；通信单元，用于基于短距通信，向第一设备发送第二设备的相关信息；

其中，连接建立请求包括请求原因，请求原因包括：第二设备检测到碰撞事件、第二设备检测到求救事件、第二设备的电量不足或者第二设备为被协助设备中的至少一项。

一种可能的实现方式中，通信单元，还用于向第三设备发送短距通信请求。

一种可能的实现方式中，第二设备的相关信息包括下述的一种或多种：第二设备的位置信息、与第二设备相关的时间戳信息、第二设备的联系方式信息、第二设备的识别号码、第二设备的轨迹信息或者第二设备被协助呼叫第三设备的原因。

一种可能的实现方式中，通信单元，具体用于基于预设条件自动触发连接建立请求的发送。

在一种可能的实施例中，多设备联合呼叫装置还可以包括：存储单元803。处理单元801、通信单元802、存储单元803通过通信总线相连。

存储单元803可以包括一个或者多个存储器，存储器可以是一个或者多个设备、电路中用于存储程序或者数据的器件。

存储单元803可以独立存在，通过通信总线与多设备联合呼叫装置具有的处理单元801相连；存储单元803也可以和处理单元801集成在一起。

多设备联合呼叫装置可以用于多设备联合呼叫设备、电路、硬件组件或者芯片中。

以多设备联合呼叫装置可以是本申请实施例中的第一设备、第二设备或第三设备的部件、芯片或芯片系统为例，则通信单元802可以是输入或者输出接口、管脚或者电路等，存储单元803可以存储第一设备、第二设备或第三设备侧的方法的计算机执行指令，以使处理单元801执行上述实施例中第一设备、第二设备或第三设备侧的方法。

本申请实施例提供了一种多设备联合呼叫装置，该多设备联合呼叫装置包括一个或者多个模块，用于实现上述图4-图7中所包含的步骤中的方法，该一个或者多个模块可以与上述图4-图7中所包含的步骤中的方法的步骤相对应。

具体的，本申请实施例中，由第一设备执行的方法中的每个步骤，第一设备中存在执行该方法中每个步骤的单元或者模块，由第二设备执行的方法中的每个步骤，第二设备中存在执行该方法中每个步骤的单元或者模块，由第三设备执行的方法中的每个步骤，第三设备中存在执行该方法中每个步骤的单元或者模块。例如，对于执行对该多设备联合呼叫装置的动作进行控制或处理的模块可以称为处理模块，对于执行对在多设备联合呼叫装置侧进行消息或数据处理的步骤的模块可以称为通信模块。

示例性的，图9为本申请实施例提供的多设备联合呼叫设备的硬件结构示意图，如图9所示，该多设备联合呼叫设备包括处理器901，通信线路904以及至少一个通信接口(图9中示例性的以通信接口903为例进行说明)。

处理器901可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1501中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1501可以是通用处理器、数字信号处理器(digital signal processing，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field-programmable gate array，FPGA)或者其它可编程逻辑器件或者协处理器中的一个或多个。可以实现或者执行本申请实施例中的公开的各方法、步骤。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

通信线路904可包括在上述组件之间传送信息的电路。

通信接口903，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线局域网(wireless local area networks，WLAN)等。

本申请实施例中，处理器901可以用于执行上述方法实施例中第一设备、第二设备或第三设备执行的步骤。

示例性的，处理器901应用于第一设备，用于执行S401和S403；或者处理器901用于执行S502、S503、S505和S507；或者处理器901用于执行S602、S603、S605和S607；或者处理器901用于执行S704；或者本申请实施例所描述的第一设备可能执行的其他过程。

示例性的，处理器901应用于第二设备，用于执行S402；或者处理器901用于执行S501和S504；或者处理器901用于执行S601和S604；或者处理器901用于执行S701；或者本申请实施例所描述的第二设备可能执行的其他过程。

示例性的，处理器901应用于第三设备，用于执行S404；或者处理器901用于执行S506；或者处理器901用于执行S606；或者处理器901用于执行S702和S703；或者本申请实施例所描述的第三设备可能执行的其他过程。

可能的，该多设备联合呼叫设备还可以包括存储器902。

存储器902可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路904与处理器相连接，存储器也可以和处理器集成在一起。

其中，存储器902用于存储执行本申请方案的计算机执行指令，并由处理器901来控制执行。处理器901用于执行存储器902中存储的计算机执行指令，从而实现本申请实施例提供的多设备联合呼叫方法。

可能的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

在具体实现中，作为一种实施例，处理器901可以包括一个或多个CPU，例如图9中的CPU0和CPU1。

在具体实现中，作为一种实施例，多设备联合呼叫设备可以包括多个处理器，例如图9中的处理器901和处理器905。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

示例性的，图10为本申请实施例提供的一种便携终端设备(下述简称终端)的结构示意图，如图10所示，终端包括至少一个处理器1011、至少一个收发器1012。在一种可能的示例中，终端还可以包括至少一个存储器1013、输出设备1014、输入设备1015和一个或多个天线1016。处理器1011、存储器1013和收发器1012相连。天线1016与收发器1012相连，输出设备1014、输入设备1015与处理器1011相连。

本申请实施例中的存储器，例如，存储器1013，可以包括如下至少一种类型：只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(Electrically erasable programmabler-only memory，EEPROM)。

在一种可能的示例中，存储器还可以是只读光盘(compact disc read-onlymemory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器1013可以是独立存在，与处理器1011相连。在另一种示例中，存储器1013也可以和处理器1011集成在一起，例如集成在一个芯片之内。其中，存储器1013能够存储执行本申请实施例的技术方案的程序代码，并由处理器1011来控制执行，被执行的各类计算机程序代码也可被视为是处理器1011的驱动程序。例如，处理器1011用于执行存储器1013中存储的计算机程序代码，从而实现本申请实施例中的技术方案。

收发器1012可以用于支持终端与车载设备或者终端与第三设备之间射频信号的接收或者发送，收发器1012可以与天线1016相连。收发器1012包括发射机Tx和接收机Rx。具体地，一个或多个天线1016可以接收射频信号，该收发器1012的接收机Rx用于从天线接收射频信号，并将射频信号转换为数字基带信号或数字中频信号，并将该数字基带信号或数字中频信号提供给处理器1011，以便处理器1011对该数字基带信号或数字中频信号做进一步的处理，例如解调处理和译码处理。此外，收发器1012中的发射机Tx还用于从处理器1011接收经过调制的数字基带信号或数字中频信号，并将该经过调制的数字基带信号或数字中频信号转换为射频信号，并通过一个或多个天线1016发送射频信号。具体地，接收机Rx可以选择性地对射频信号进行一级或多级下混频处理和模数转换处理以得到数字基带信号或数字中频信号，下混频处理和模数转换处理的先后顺序是可调整的。发射机Tx可以选择性地对经过调制的数字基带信号或数字中频信号时进行一级或多级上混频处理和数模转换处理以得到射频信号，上混频处理和数模转换处理的先后顺序是可调整的。其中，数字基带信号和数字中频信号可以统称为数字信号。

处理器1011可以是基带处理器，也可以是CPU，基带处理器和CPU可以集成在一起，或者分开。

处理器1011可以用于为终端实现各种功能，例如，用于对通信协议以及通信数据进行处理，或者用于对整个终端设备进行控制，执行软件程序，处理软件程序的数据；或者用于协助完成计算处理任务，例如，对图形图像处理或者音频处理等；或者处理器1011用于实现上述功能中的一种或者多种。

结合上述实施例所描述的多设备联合呼叫方法，在第一设备为便携终端设备时，处理器1011可以执行上述方法实施例中第一设备执行的步骤；在第二设备为便携终端设备时，处理器1011可以执行上述方法实施例中第二设备执行的步骤。

输出设备1014和处理器1011通信，可以以多种方式来显示信息。例如，输出设备1014可以是液晶显示器(liquid crystal display，LCD)、发光二级管(light emittingdiode，LED)显示设备、阴极射线管(cathode ray tube，CRT)显示设备、或投影仪(projector)等。输入设备1015和处理器1011通信，可以以多种方式接受用户的输入。例如，输入设备1015可以是鼠标、键盘、触摸屏设备或传感设备等。

示例性的，图11为本申请实施例提供的一种芯片的结构示意图。芯片110包括一个或两个以上(包括两个)处理器1110和通信接口1130。

在一些实施方式中，存储器1140存储了如下的元素：可执行模块或者数据结构，或者他们的子集，或者他们的扩展集。

本申请实施例中，存储器1140可以包括只读存储器和随机存取存储器，并向处理器1110提供指令和数据。存储器1140的一部分还可以包括非易失性随机存取存储器(non-volatile random access memory，NVRAM)。

本申请实施例中，处理器1110可以通过调用存储器1140存储的操作指令(该操作指令可存储在操作系统中)，控制第一设备、第二设备或第三设备执行相应的操作。其中，处理器1110可以称为中央处理单元(central processing unit，CPU)。

本申请实施例中，存储器1140、通信接口1130以及存储器1140通过总线系统1120耦合在一起。其中，总线系统1120除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。为了便于描述，在图11中将各种总线都标为总线系统1120。

结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。其中，软件模块可以位于随机存储器、只读存储器、可编程只读存储器或带电可擦写可编程存储器(electricallyerasable programmable read only memory，EEPROM)等本领域成熟的存储介质中。该存储介质位于存储器1140，处理器1110读取存储器1140中的信息，结合其硬件完成上述方法的步骤。

在上述实施例中，存储器存储的供处理器执行的指令可以以计算机程序产品的形式实现。其中，计算机程序产品可以是事先写入在存储器中，也可以是以软件形式下载并安装在存储器中。

计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，DSL)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包括一个或多个可用介质集成的服务器、数据中心等数据存储设备。例如，可用介质可以包括磁性介质(例如，软盘、硬盘或磁带)、光介质(例如，数字通用光盘(digital versatile disc，DVD))、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

本申请实施例还提供了一种计算机可读存储介质。上述实施例中描述的方法可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。计算机可读介质可以包括计算机存储介质和通信介质，还可以包括任何可以将计算机程序从一个地方传送到另一个地方的介质。存储介质可以是可由计算机访问的任何目标介质。

作为一种可能的设计，计算机可读介质可以包括紧凑型光盘只读储存器(compactdisc read-only memory，CD-ROM)、RAM、ROM、EEPROM或其它光盘存储器；计算机可读介质可以包括磁盘存储器或其它磁盘存储设备。而且，任何连接线也可以被适当地称为计算机可读介质。例如，如果使用同轴电缆，光纤电缆，双绞线，DSL或无线技术(如红外，无线电和微波)从网站，服务器或其它远程源传输软件，则同轴电缆，光纤电缆，双绞线，DSL或诸如红外，无线电和微波之类的无线技术包括在介质的定义中。如本文所使用的磁盘和光盘包括光盘(CD)，激光盘，光盘，数字通用光盘(digital versatile disc，DVD)，软盘和蓝光盘，其中磁盘通常以磁性方式再现数据，而光盘利用激光光学地再现数据。上述的组合也应包括在计算机可读介质的范围内。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (37)

1.一种多设备联合呼叫方法，其特征在于，所述方法包括：

第一设备建立与第二设备的短距通信；

所述第一设备根据所述短距通信，获取所述第二设备的相关信息；

所述第一设备向第三设备发送所述第二设备的相关信息和所述第一设备的相关信息；

所述第一设备接收来自所述第三设备的寻呼；其中，所述寻呼为所述第三设备根据所述第二设备的相关信息和所述第一设备的相关信息发送的。

2.根据权利要求1所述的方法，其特征在于，所述第一设备建立与第二设备的短距通信，包括：

所述第一设备接收来自所述第二设备的连接建立请求；

所述第一设备根据所述连接建立请求以及第一签约信息，验证所述第二设备的身份，所述第一签约信息用于指示允许所述第一设备协助呼叫所述第三设备的至少一个被协助设备；

在所述第二设备的身份验证通过的情况下，所述第一设备建立与所述第二设备的短距通信。

3.根据权利要求2所述的方法，其特征在于，所述连接建立请求包括请求原因，所述第一签约信息还包括所述第一设备允许建立短距通信的条件；所述第一设备根据所述连接建立请求以及第一签约信息，验证所述第二设备的身份，包括：

在所述请求原因与所述条件匹配，且所述至少一个被协助设备包括所述第二设备的情况下，所述第二设备的身份验证通过。

4.根据权利要求3所述的方法，其特征在于，所述请求原因包括：所述第二设备检测到碰撞事件、所述第二设备检测到求救事件、所述第二设备的电量不足或者所述第二设备为所述被协助设备中的至少一项。

5.根据权利要求1-4任一项所述的方法，其特征在于，所述寻呼为语音通话的寻呼，所述方法还包括：

所述第一设备基于所述寻呼自动开启接听。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述第一设备建立与第二设备的短距通信之前，所述方法还包括：

所述第一设备接收来自所述第三设备的短距通信功能开启指示；

所述第一设备根据所述短距通信功能开启指示开启所述第一设备的短距通信功能。

7.根据权利要求1-6任一项所述的方法，其特征在于，所述第一设备的相关信息包括下述的一种或多种：所述第一设备的位置信息、与所述第一设备相关的时间戳信息、所述第一设备的联系方式信息、所述第一设备的识别号码或所述第一设备的轨迹信息；或者，

所述第二设备的相关信息包括下述的一种或多种：所述第二设备的位置信息、与所述第二设备相关的时间戳信息、所述第二设备的联系方式信息、所述第二设备的识别号码、所述第二设备的轨迹信息或者所述第二设备被协助呼叫所述第三设备的原因。

8.一种多设备联合呼叫方法，其特征在于，所述方法包括：

第三设备接收来自第一设备的寻呼请求消息，所述寻呼请求消息包括所述第一设备的相关信息和第二设备的相关信息；

所述第三设备根据所述寻呼请求消息，向所述第一设备发送寻呼。

9.根据权利要求8所述的方法，其特征在于，所述第三设备根据所述寻呼请求消息，向所述第一设备发送寻呼，包括：

所述第三设备在向所述第二设备发送寻呼无响应的情况下，向所述第一设备发送所述寻呼。

10.根据权利要求8或9所述的方法，其特征在于，所述第三设备根据所述寻呼请求消息，向所述第一设备发送所述寻呼之前，所述方法还包括：

所述第三设备接收来自所述第二设备的短距通信请求；

所述第三设备根据所述短距通信请求以及第二签约信息，验证所述第一设备的身份，所述第二签约信息用于指示允许协助所述第二设备呼叫所述第三设备的至少一个协助设备；

在所述第一设备的身份验证通过的情况下，所述第三设备向所述第一设备发送短距通信功能开启指示。

11.根据权利要求10所述的方法，其特征在于，所述第三设备根据所述短距通信请求以及第二签约信息，验证所述第一设备的身份，包括：

在所述第一设备为所述协助设备的情况下，所述第一设备的身份验证通过。

12.根据权利要求8-11任一项所述的方法，其特征在于，所述第一设备的相关信息包括下述的一种或多种：所述第一设备的位置信息、与所述第一设备相关的时间戳信息、所述第一设备的联系方式信息、所述第一设备的识别号码或所述第一设备的轨迹信息；或者，

所述第二设备的相关信息包括下述的一种或多种：所述第二设备的位置信息、与所述第二设备相关的时间戳信息、所述第二设备的联系方式信息、所述第二设备的识别号码、所述第二设备的轨迹信息或者所述第二设备被协助呼叫所述第三设备的原因。

13.根据权利要求8-12任一项所述的方法，其特征在于，所述寻呼为语音通话的寻呼。

14.一种多设备联合呼叫方法，其特征在于，所述方法包括：

所述第二设备向第一设备发送连接建立请求；

所述第二设备根据所述连接建立请求，与所述第一设备建立短距通信；

所述第二设备基于所述短距通信，向所述第一设备发送所述第二设备的相关信息；

其中，所述连接建立请求包括请求原因，所述请求原因包括：所述第二设备检测到碰撞事件、所述第二设备检测到求救事件、所述第二设备的电量不足或者所述第二设备为被协助设备中的至少一项。

15.根据权利要求14所述的方法，其特征在于，所述第二设备与第一设备发送连接建立请求之前，所述方法还包括：

所述第二设备向第三设备发送短距通信请求。

16.根据权利要求14或15所述的方法，其特征在于，所述第二设备的相关信息包括下述的一种或多种：所述第二设备的位置信息、与所述第二设备相关的时间戳信息、所述第二设备的联系方式信息、所述第二设备的识别号码、所述第二设备的轨迹信息或者所述第二设备被协助呼叫所述第三设备的原因。

17.根据权利要求14-16任一项所述的方法，其特征在于，所述第二设备向第一设备发送连接建立请求，包括：所述第二设备基于预设条件自动触发所述连接建立请求的发送。

18.一种多设备联合呼叫装置，其特征在于，所述装置包括处理单元和通信单元；

所述处理单元，用于建立与第二设备的短距通信；

所述通信单元，用于根据所述短距通信，获取所述第二设备的相关信息；

所述通信单元，用于向第三设备发送所述第二设备的相关信息和所述第一设备的相关信息；

所述通信单元，用于接收来自所述第三设备的寻呼；其中，所述寻呼为所述第三设备根据所述第二设备的相关信息和所述第一设备的相关信息发送的。

19.根据权利要求18所述的装置，其特征在于，所述通信单元，具体用于接收来自所述第二设备的连接建立请求；

所述处理单元，具体用于根据所述连接建立请求以及第一签约信息，验证所述第二设备的身份，所述第一签约信息用于指示允许所述第一设备协助呼叫所述第三设备的至少一个被协助设备；

所述处理单元，具体用于在所述第二设备的身份验证通过的情况下，建立与所述第二设备的短距通信。

20.根据权利要求19所述的装置，其特征在于，所述连接建立请求包括请求原因，所述第一签约信息还包括所述第一设备允许建立短距通信的条件；所述处理单元，具体用于：

在所述请求原因与所述条件匹配，且所述至少一个被协助设备包括所述第二设备的情况下，所述第二设备的身份验证通过。

21.根据权利要求20所述的装置，其特征在于，所述请求原因包括：所述第二设备检测到碰撞事件、所述第二设备检测到求救事件、所述第二设备的电量不足或者所述第二设备为所述被协助设备中的至少一项。

22.根据权利要求18-21任一项所述的装置，其特征在于，所述寻呼为语音通话的寻呼，所述处理单元，具体用于基于所述寻呼自动开启接听。

23.根据权利要求18-22任一项所述的装置，其特征在于，所述通信单元，还用于接收来自所述第三设备的短距通信功能开启指示；

所述处理单元，还用于根据所述短距通信功能开启指示开启所述第一设备的短距通信功能。

24.根据权利要求18-23任一项所述的装置，其特征在于，所述第一设备的相关信息包括下述的一种或多种：所述第一设备的位置信息、与所述第一设备相关的时间戳信息、所述第一设备的联系方式信息、所述第一设备的识别号码或所述第一设备的轨迹信息；或者，

所述第二设备的相关信息包括下述的一种或多种：所述第二设备的位置信息、与所述第二设备相关的时间戳信息、所述第二设备的联系方式信息、所述第二设备的识别号码、所述第二设备的轨迹信息或者所述第二设备被协助呼叫所述第三设备的原因。

25.一种多设备联合呼叫装置，其特征在于，所述装置包括接收单元和发送单元；

所述接收单元，用于接收来自第一设备的寻呼请求消息，所述寻呼请求消息包括所述第一设备的相关信息和第二设备的相关信息；

所述发送单元，用于根据所述寻呼请求消息，向所述第一设备发送寻呼。

26.根据权利要求25所述的装置，其特征在于，所述发送单元，具体用于在向所述第二设备发送寻呼无响应的情况下，向所述第一设备发送所述寻呼。

27.根据权利要求25或26所述的装置，其特征在于，所述接收单元，还用于接收来自所述第二设备的短距通信请求；

所述装置还包括处理单元，所述处理单元，用于根据所述短距通信请求以及第二签约信息，验证所述第一设备的身份，所述第二签约信息用于指示允许协助所述第二设备呼叫所述第三设备的至少一个协助设备；

所述发送单元，具体用于在所述第一设备的身份验证通过的情况下，向所述第一设备发送短距通信功能开启指示。

28.根据权利要求27所述的装置，其特征在于，所述处理单元，具体用于在所述第一设备为所述协助设备的情况下，所述第一设备的身份验证通过。

29.根据权利要求25-28任一项所述的装置，其特征在于，所述第一设备的相关信息包括下述的一种或多种：所述第一设备的位置信息、与所述第一设备相关的时间戳信息、所述第一设备的联系方式信息、所述第一设备的识别号码或所述第一设备的轨迹信息；或者，

所述第二设备的相关信息包括下述的一种或多种：所述第二设备的位置信息、与所述第二设备相关的时间戳信息、所述第二设备的联系方式信息、所述第二设备的识别号码、所述第二设备的轨迹信息或者所述第二设备被协助呼叫所述第三设备的原因。

30.根据权利要求25-29任一项所述的装置，其特征在于，所述寻呼为语音通话的寻呼。

31.一种多设备联合呼叫装置，其特征在于，所述装置包括通信单元和处理单元；

所述通信单元，用于向第一设备发送连接建立请求；

所述处理单元，用于根据所述连接建立请求，与所述第一设备建立短距通信；

所述通信单元，用于基于所述短距通信，向所述第一设备发送所述第二设备的相关信息；

其中，所述连接建立请求包括请求原因，所述请求原因包括：所述第二设备检测到碰撞事件、所述第二设备检测到求救事件、所述第二设备的电量不足或者所述第二设备为被协助设备中的至少一项。

32.根据权利要求31所述的装置，其特征在于，所述通信单元，还用于向第三设备发送短距通信请求。

33.根据权利要求31或32所述的装置，其特征在于，所述第二设备的相关信息包括下述的一种或多种：所述第二设备的位置信息、与所述第二设备相关的时间戳信息、所述第二设备的联系方式信息、所述第二设备的识别号码、所述第二设备的轨迹信息或者所述第二设备被协助呼叫所述第三设备的原因。

34.根据权利要求31-33任一项所述的装置，其特征在于，所述通信单元，具体用于基于预设条件自动触发所述连接建立请求的发送。

35.一种多设备联合呼叫装置，其特征在于，包括存储器和处理器，所述存储器存储计算机程序指令，所述处理器运行所述计算机程序指令以执行权利要求1-17任一项所述的方法。

36.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令被运行时，实现如权利要求1-7中任一项所述的多设备联合呼叫方法，或实现如权利要求8-13中任一项所述的多设备联合呼叫方法，或实现如权利要求14-17中任一项所述的多设备联合呼叫方法。

37.一种计算机程序产品，其特征在于，当所述计算机程序产品在处理器上运行时，使得多设备联合呼叫装置执行权利要求1-17任一项所述的方法。

Images