院前医疗急救的无线通信方法及系统

摘要

本说明书一个或多个实施例提供一种院前医疗急救的无线通信方法及系统，当救护车接到急救任务时，启动急救模式的无线通信系统功能；在急救模式下，救护车可将选取的最优前往路线和最优返程路线通过应用服务器传送至云服务器，由云服务器更新各地图应用中的救护车位置及其选定的最优前往路线，便于沿途车辆及时避让救护车；同时，运送病人的途中，可将病人的各项身体指标监测结果通过应用服务器传送到医院急救端，方便医生尽快制定治疗方案，从而提高急救病人的救治效率。

说明书

技术领域

本说明书一个或多个实施例涉及无线通信技术领域，尤其涉及一种院前医疗急救的无线通信方法及系统。

背景技术

传统的院前医疗急救中，救护车赶往急救地将病人转运至医院，在转运途中可以进行简单的生命体征监测和急救措施，病人到院后仍需经过大量的检查，主治医生才能根据检查结果制定抢救方案。包括转运路程、各项检查等在内的整个流程需要花费较长的时间，很可能错过抢救病人的最佳时机。

发明内容

有鉴于此，本说明书一个或多个实施例的目的在于提出一种院前医疗急救的无线通信方法及系统，以提高院前急救的效率。

基于上述目的，本说明书一个或多个实施例提供了院前医疗急救的无线通信方法，应用于救护车端，包括：

接收急救任务时，生成急救标识；

建立与应用服务器的连接；

在选取从医院到急救地的最优前往路线之后，将所述最优前往路线通过所述应用服务器发送至云服务器，以使所述云服务器根据所述最优前往路线更新救护车在地图应用中的前往路线；

在获得病人的身体指标监测结果后，将所述身体指标监测结果通过所述应用服务器发送至医院急救端，以使医生从所述医院急救端获取所述身体指标监测结果、根据所述身体指标监测结果制定治疗方案；

在选取从急救地到医院的最优返程路线之后，将所述最优返程路线通过所述应用服务器发送至所述云服务器，以使所述云服务器根据所述最优返程路线更新救护车在地图应用中的返程路线。

可选的，选取所述最优前往路之后，还包括：

通过所述应用服务器与所述医院急救端建立音视频数据连接，以使医生通过所述医院急救端与所述救护车端进行音视频通话、根据通话内容和所述身体指标监测结果制定治疗方案。

可选的，选取所述最优前往路之后，还包括：

通过所述应用服务器从健康档案数据库中获取健康档案数据，将所述健康档案数据发送至所述医院急救端，以使医生根据所述健康档案数据、身体指标监测结果和/或通话内容制定治疗方案。

可选的，所述方法还包括：

将所述急救标识、健康档案数据、身体指标监测结果和/或通话内容，通过所述应用服务器发送至所述云服务器。

可选的，所述建立与应用服务器的连接，包括：

从鉴权服务器获取随机数；

根据所述随机数和预设的鉴权信息，生成验证码；

向代理服务器发送注册与鉴权请求，所述注册与鉴权请求中包括所述验证码、所述救护车端的身份信息；

所述代理服务器将所述注册与鉴权请求发送至查询服务器，由所述查询服务器根据所述身份信息对所述救护车端进行身份验证和权限验证；

如果所述身份验证通过，且所述救护车端具有急救模式权限，所述查询服务器选取目标应用服务器；

所述代理服务器向所述目标应用服务器发送鉴权请求，所述鉴权请求包括所述验证码；

所述目标应用服务器从所述鉴权服务器获取所述随机数和所述鉴权信息；根据所述随机数和所述鉴权信息生成校验验证码，将所述校验验证码和所述验证码进行比较，如果二者一致，通过所述代理服务器向所述救护车端发送鉴权成功响应。

本说明书实施例还提供一种院前医疗急救的无线通信系统，包括：

救护车端，用于接收急救任务时，生成急救标识；建立与应用服务器的连接；在选取从医院到急救地的最优前往路线之后，将所述最优前往路线发送至应用服务器；在获得病人的身体指标监测结果后，将所述身体指标监测结果发送至应用服务器；以及在选取从急救地到医院的最优返程路线之后，将所述最优返程路线发送至所述应用服务器；

应用服务器，用于将所述最优前往路线发送至云服务器；将所述身体指标监测结果发送至医院急救端；将所述最优返程路线发送至云服务器；

云服务器，用于根据所述最优前往路线和所述最优返程路线更新救护车在地图应用中的前往路线和返程路线；

医院急救端，用于接收所述身体指标监测结果，以使医生从所述医院急救端获取所述身体指标监测结果、根据所述身体指标监测结果制定治疗方案。

可选的，所述应用服务器，用于建立所述救护车端与所述医院急救端之间的音视频数据连接，以使医生通过所述医院急救端与所述救护车端进行音视频通话、根据通话内容和所述身体指标监测结果制定治疗方案。

可选的，所述应用服务器，用于从健康档案数据库中获取健康档案数据，将所述健康档案数据发送至所述医院急救端；

所述医院急救端，用于接收所述健康档案数据，以使医生根据所述健康档案数据、身体指标监测结果和/或通话内容制定治疗方案。

可选的，所述应用服务器，用于将所述急救标识、健康档案数据、身体指标监测结果和/或通话内容发送至所述云服务器。

可选的，所述救护车端与应用服务器建立连接的方法，包括：

从鉴权服务器获取随机数；

根据所述随机数和预设的鉴权信息，生成验证码；

向代理服务器发送注册与鉴权请求，所述注册与鉴权请求中包括所述验证码、所述救护车端的身份信息；

所述代理服务器将所述注册与鉴权请求发送至查询服务器，由所述查询服务器根据所述身份信息对所述救护车端进行身份验证和权限验证；

如果所述身份验证通过，且所述救护车端具有急救模式权限，所述查询服务器选取目标应用服务器；

所述代理服务器向所述目标应用服务器发送鉴权请求，所述鉴权请求包括所述验证码；

所述目标应用服务器从所述鉴权服务器获取所述随机数和所述鉴权信息；

根据所述随机数和所述鉴权信息生成校验验证码，将所述校验验证码和所述验证码进行比较，如果二者一致，通过所述代理服务器向所述救护车端发送鉴权成功响应。

从上面所述可以看出，本说明书一个或多个实施例提供的院前医疗急救的无线通信方法及系统，当救护车接到急救任务时，启动急救模式的无线通信系统功能；该模式下，救护车可将选取的最优前往路线和最优返程路线通过应用服务器传送至云服务器，由云服务器更新各地图应用中的救护车位置及其选定的最优前往路线，便于沿途车辆及时避让救护车；同时，运送病人的途中，可将病人的各项身体指标监测结果通过应用服务器传送到医院急救端，方便医生尽快制定治疗方案，从而提高急救病人的救治效率。

附图说明

为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书一个或多个实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书一个或多个实施例的无线通信系统的拓扑图；

图2为本说明书一个或多个实施例的方法流程示意图；

图3为本说明书一个或多个实施例的急救应用的功能框图；

图4为本说明书一个或多个实施例的急救模式下的无线通信系统框图；

图5为本说明书一个或多个实施例的与应用服务器建立连接的方法流程示意图；

图6为本说明书另一个实施例的方法流程示意图；

图7为本说明书一个或多个实施例的电子设备示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本说明书一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本说明书一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

如图1所示，本实施例的无线通信方法基于无线通信系统实现，系统包括救护车端、应用服务器、云服务器、医院急救端、急救控制中心和健康档案数据库，各主体基于通信系统建立通信连接。例如，各主体基于4G或5G通信系统建立数据连接，能够实现院前医疗急救过程中的实时数据传输、音视频通信、数据汇聚、数据访问等，为提高急救效率提供系统和技术支持。

如图1-3所示，本说明书一个或多个实施例提供一种院前医疗急救的无线通信方法，应用于救护车端，方法包括：

S201：接收急救任务时，生成急救标识；

S202：建立与应用服务器的连接；

本实施例中，当急救控制中心接到急救电话后，调度距离急救地最近的救护车前往救助，救护车端接到急救任务后，生成本次急救任务的急救标识，利用该急救标识记录关联有关本次急救任务的所有数据和过程；同时，启动急救应用，建立与应用服务器的数据连接，开启急救模式下的无线通信系统功能。

S203：在选取从医院到急救地的最优前往路线之后，将最优前往路线通过应用服务器发送至云服务器，以使云服务器根据最优前往路线更新救护车在地图应用中的前往路线；

本实施例中，救护车端通过定位单元和本地安装的地图应用，确定到达急救地的最优前往路线，将选取的最优前往路线发送至应用服务器，由应用服务器将最优前往路线上传至云服务器，云服务器根据最优前往路线更新各地图应用的前往路线。

一些方式中，云服务器可将救护车位置及其最优前往路线在各个地图应用中同步显示出来，以便沿途车辆可以根据实时地图及时获知救护车的行驶路线，为车辆合理选取路线、及时避让救护车提供依据。可选的，可以特定的救护车标识和特定的最优前往路线样式在地图应用中显示，例如，以红十字标识显示救护车，以特定颜色显示救护车的最优前往路线等，具体的显示方式不做限定。

S204：在获得病人的身体指标监测结果后，将身体指标监测结果通过应用服务器发送至医院急救端，以使医生从医院急救端获取身体指标监测结果、根据身体指标监测结果制定治疗方案；

本实施例中，当救护车到达急救地，将病人转移到救护车中后，由医护人员利用车内监测设备对病人进行各项身体指标的监测，并获得各项身体指标监测结果。一些方式中，根据救护车内配置的监测设备，可以对病人进行血压、血项、心电图、超声监测部位等身体指标项的检测。在获得各项身体指标监测结果后，及时将身体指标监测结果上传至救护车端，救护车端将身体指标监测结果发送至应用服务器，由应用服务器将身体指标监测结果发送至医院急救端。这样，在病人的转运途中即可进行常规的身体检查，并将检查结果传送到医院急救端，方便医生通过医院急救端及时获取病人的各项身体指标监测结果，根据病情制定治疗方案。

S205：在选取从急救地到医院的最优返程路线之后，将最优返程路线通过应用服务器发送至云服务器，以使云服务器根据最优返程路线更新救护车在地图应用中的返程路线。

本实施例中，当救护车到达急救地，将病人转移到救护车中后，救护车端通过定位单元和本地安装的地图应用，确定从急救地到医院的最优返程路线，将选取的最优返程路线发送至应用服务器，由应用服务器将最优返程路线上传至云服务器，云服务器根据最优返程路线更新各地图应用的返程路线。方便沿途车辆根据地图应用获知救护车的行驶路线，为车辆合理选取路线、及时避让救护车提供依据，从而避免救护车在运送病人的路途中发生堵车等情况，尽快将病人送至医院。

本实施例提供的院前医疗急救的无线通信方法，当救护车接到急救任务时，启动急救模式的无线通信系统功能。在急救模式下的系统功能，救护车可将选取的最优前往路线和最优返程路线通过应用服务器传送至云服务器，由云服务器更新各地图应用中的救护车位置及其选定的最优前往路线，便于沿途车辆及时避让救护车；同时，运送病人的途中，可将病人的各项身体指标监测结果通过应用服务器传送到医院急救端，方便医生尽快制定治疗方案，从而提高急救病人的救治效率。

一些实施例中，选取最优前往路之后，还包括：

通过应用服务器与医院急救端建立音视频数据连接，以使医生通过医院急救端与救护车端进行音视频通话、根据通话内容和身体指标监测结果制定治疗方案。

本实施例中，在救护车运送病人的途中，救护车端可通过应用服务器与医院急救端建立音视频数据连接，即医生可在医院与救护车内的医护人员进行音视频通话，方便医生及时了解病人的病情，进而根据了解的情况和传回医院的身体指标监测结果制定治疗方案。

一些实施例中，选取最优前往路之后，还包括：

通过应用服务器从健康档案数据库中获取健康档案数据，将健康档案数据发送至医院急救端，以使医生根据健康档案数据、身体指标监测结果和/或通话内容制定治疗方案。

本实施例中，在救护车运送病人的途中，医护人员了解病人的基本信息后，可利用救护车端通过应用服务器与健康档案数据库建立数据连接，从健康档案数据库下载病人的健康档案数据，进一步将健康档案数据发送至医院急救端，这样，医生可通过医院急救端获取病人的健康档案数据，再结合实时监测的身体指标监测结果和音视频通话内容，全面了解病情，便于尽快制定合理的治疗方案。

可选的，健康档案数据可以从医院的健康档案数据库中查询获取，如果医院没有查询到病人的相关档案数据，则由云服务器从其他医院或医疗机构的健康档案数据库中查询获取。

一些实施例中，方法还包括：将急救标识、健康档案数据、身体指标监测结果和/或通话内容，通过以应用服务器发送至云服务器。即，救护车端将本次救治病人的所有急救数据和过程，包括急救标识及其对应的病人的健康档案数据、身体指标监测结果和/或音视频通话内容全部通过应用服务器上传至云服务器，将全部急救信息备份，可用于后续治疗参考，也可为医患纠纷提供证据。

一些实施方式中，无线通信系统基于IMS(IP Multimedia Subsystem)多媒体系统框架实现，该框架是基于4G或5G网络下的应用层服务，支持语音、视频、数据等业务的融合，能够满足多样化的通信需求。该系统框架包括用户UE、IMS核心网络层和应用层，IMS核心网络层包括代理服务器P-CSCF、查询服务器I-CSCF、应用服务器S-CSCF等。接入IMS系统时，用户UE需要经过二次注册与鉴权，流程复杂繁琐，不适用于急救模式，而IMS系统自有的紧急模式由于所支持的功能单一，也无法满足救护车急救场景下多重功能的需求。

如图4所示，在本实施例提供的无线通信系统中，用户UE包括救护车端、医院急救端、急救控制中心、云服务器和健康档案数据库等，在急救模式下，这些用户UE具有各自的紧急标识，并作为紧急用户端在统一数据管理服务器UDM中注册，UDM中保存各紧急用户端的身份信息，并配置急救模式权限。IMS核心网络层包括支持急救模式的代理服务器P-CSCF-E、查询服务器I-CSCF-E、应用服务器S-CSCF-E等，各服务器除具有一般性常规功能外(包括，代理服务器P-CSCF-E提供代理功能，能够接收业务请求并转发；查询服务器I-CSCF-E提供路由查询和分配应用服务器功能；应用服务器S-CSCF-E提供业务支持等)，还能够实现急救模式的无线通信功能，例如，在急救模式下，紧急用户端可以简化的注册鉴权流程建立与应用服务器的连接，并由应用服务器提供包括音视频通信、实时数据传输、数据汇聚等多重业务功能。另外，本实施例的无线通信系统还包括统一数据管理服务器UDM、鉴权服务器AUSF和策略与计费规则服务器PCRF，其中，UDM用于存储紧急用户端的身份数据和鉴权信息，AUSF用于提供急救模式下的用户鉴权，PCRF用于保障急救业务的服务质量。

如图4、5所示，一些实施例中，当救护车端启动急救模式时，各个紧急用户端建立与应用服务器的连接，启动无线通信系统的急救模式。以救护车端为例，建立与应用服务器的连接的方法包括：

从鉴权服务器获取随机数；

根据随机数和预设的鉴权信息，生成验证码；

向代理服务器发送注册与鉴权请求，注册与鉴权请求中包括验证码、救护车端的身份信息；

代理服务器将注册与鉴权请求发送至查询服务器，由查询服务器根据身份信息对救护车端进行身份验证和权限验证；

如果身份验证通过，且救护车端具有急救模式权限，查询服务器选取目标应用服务器；

代理服务器向目标应用服务器发送鉴权请求，鉴权请求包括验证码；

目标应用服务器从鉴权服务器获取随机数和鉴权信息；

根据随机数和鉴权信息生成校验验证码，将校验验证码和验证码进行比较，如果二者一致，通过代理服务器向救护车端发送鉴权成功响应。

本实施例提供了救护车端与应用服务器建立连接的方法，具体包括：救护车端向鉴权服务器AUSF发送获取随机数的请求，鉴权服务器生成随机数，并返回给救护车端；救护车端根据随机数和自身的鉴权信息生成验证码；救护车端向代理服务器P-CSCF-E发送注册与鉴权请求，该请求中包括验证码；代理服务器P-CSCF-E保存该验证码，并向查询服务器I-CSCF-E发送注册请求，该注册请求中包括救护车端的身份信息，查询服务器I-CSCF-E向统一数据管理服务器UDM发送验证请求，该验证请求包括救护车端的身份信息，统一数据管理服务器UDM根据接收的身份信息对救护车端进行身份验证和权限验证，包括救护车端是否为紧急用户，是否具有急救模式权限；如果救护车端的身份验证通过，且具有急救模式的权限，统一数据管理服务器UDM向查询服务器I-CSCF-E发送验证通过响应；查询服务器I-CSCF-E收到验证通过响应后，选取合适的应用服务器S-CSCF-E，将该应用服务器I-CSCF-E的地址以注册成功响应发送给代理服务器P-CSCF-E；代理服务器P-CSCF-E按照该地址向应用服务器I-CSCF-E发送鉴权请求，该鉴权请求包括验证码；应用服务器保存验证码，并向鉴权服务器AUSF请求获取救护车端的随机数和鉴权信息，鉴权服务器AUSF将救护车端的随机数和鉴权信息返回给应用服务器，应用服务器根据接收的随机数和鉴权信息生成校验验证码，将校验验证码和鉴权请求中的验证码进行比较，如果二者一致，则救护车端鉴权成功，后续由应用服务器为救护车端提供相关业务功能，包括实时数据传输、数据访问、数据汇聚等功能。可见，上述过程中，紧急用户端与应用服务器建立连接仅需一次鉴权过程，而无需二次注册与鉴权，通过为紧急用户端开设“绿色通道”，能够简化注册与鉴权流程，满足急救模式下的通信连接需求。

如图6所示，基于急救模式下的无线通信系统，实现院前医疗急救的无线通信方法，包括：

S601：急救中心接到急救电话，调度距离最近的救护车前往急救地救治；

S602：救护车端接收急救任务，生成急救标识，开启急救模式下的无线通信功能，该模式下包括救护车端在内的各紧急用户端建立与应用服务器的连接；

S603：救护车端利用定位单元和地图应用，选取最优前往路线，并将最优前往路线经过应用服务器传输至云服务器，由云服务器根据最优前往路线更新各地图应用，在地图应用中显示救护车标识和最优前往路线；

S604：救护车抵达急救地，判断病人是否有生命体证，如果没有则急救模式结束；

S605：病人有生命体证，将病人转移至救护车上，选取从急救地到医院的最优返程路线，并将最优返程路线经应用服务器传输至云服务器，由云服务器根据最优返程路线更新各地图应用，在地图应用中显示救护车标识和最优返程路线；

S606：利用各种监测设备监测病人的身体指标，获得身体指标监测结果，并将身体指标监测结果通过应用服务器传输至医院急救端；

S607：通过应用服务器与医院急救端建立音视频通信连接，医生在医院急救端根据通话内容和病人的身体指标监测结果，远程指导急救措施；

S608：通过应用服务器从健康档案数据库查询并调取病人的健康档案数据，将健康档案数据传输至医院急救端，便于医生根据通话内容、健康档案数据和身体指标监测结果，制定全面的抢救方案；

S609：救护车到达医院，转移病人，医生按照制定的抢救方案对病人进行抢救工作；将本次急救任务的急救标识、最优前往路线、最优返程路线、音视频通话内容、健康档案数据和身体指标监测结果等数据全部上传至云服务器。

本说明书实施例提供的无线通信方法，各紧急用户端基于无线通信系统实现急救模式下的无线通信功能，紧急用户端仅需一次注册与鉴权即可与应用服务器建立连接，由应用服务器提供急救过程中的实时数据传输、数据汇聚和数据访问等多重功能，为及时有效的救治病人提供技术支持，提高救治效率。

需要说明的是，本说明书一个或多个实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本说明书一个或多个实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

需要说明的是，上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

结合图1所示，本说明书一个或多个实施例还提供一种无线通信系统，包括：

救护车端，用于接收急救任务时，生成急救标识；建立与应用服务器的连接；在选取从医院到急救地的最优前往路线之后，将所述最优前往路线发送至应用服务器；在获得病人的身体指标监测结果后，将所述身体指标监测结果发送至应用服务器；以及在选取从急救地到医院的最优返程路线之后，将所述最优返程路线发送至所述应用服务器；

应用服务器，用于将所述最优前往路线发送至云服务器；将所述身体指标监测结果发送至医院急救端；将所述最优返程路线发送至云服务器；

云服务器，用于根据所述最优前往路线和所述最优返程路线更新救护车在地图应用中的前往路线和返程路线；

医院急救端，用于接收所述身体指标监测结果，以使医生从所述医院急救端获取所述身体指标监测结果、根据所述身体指标监测结果制定治疗方案。

上述实施例的系统用于实现前述实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

图7示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述实施例中相应的方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本说明书一个或多个实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本说明书一个或多个实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本说明书一个或多个实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本说明书一个或多个实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。