用于利用弹性连接策略进行移动会话建立的方法和设备与流程

文档序号:15744609发布日期:2018-10-23 22:54阅读:135来源:国知局

示意性实施例总体上涉及一种用于利用弹性重新连接策略进行移动会话建立的方法和设备。



背景技术:

当车辆正在行驶时,车辆远程信息处理单元提供对车辆计算系统的连接和远程资源访问。典型地借助于车载蜂窝调制解调器或本地用户装置,远程信息处理控制单元(TCU)连接到远程服务传输网络(SDN),以获取原始设备制造商(OEM)远程信息处理服务。这可包括但不限于音乐、广告、车辆软件更新、诊断传输以及任何其它形式的有用数据发送和接收。

在常用模型中,为了在TCU与SDN之间建立连接,TCU将与移动运营商的核心网络和消息队列(MQ)遥测传输(MQTT)建立会话。MQTT是会话层协议。TCU利用消息代理(AKA(认证和密钥协商)MQTT)来建立会话,TCU通过消息代理与SDN进行通信。消息代理可以是与SDN分离的实体或者与SDN集成。

到移动运营商的核心网络和/或MQTT代理的连接可能因为任意数量的原因而失败。如果失败发生在重要时间(例如,当TCU正在传输客户请求的数据时),则这导致服务中断且可降低客户体验。虽然用于连接和重试的一些范例已经存在,但是它们可能缺少能够帮助确保弹性重新连接策略的方面。



技术实现要素:

在第一示意性实施例中,一种系统包括处理器,处理器被配置为:对分组数据(PD)连接尝试第一次数的尝试,在每个未成功尝试之间存在预定短延迟。处理器还被配置为:响应于在第一次数的尝试失败之后的另一失败的连接尝试,延迟基于预定长延迟减去先前失败的连接尝试的总持续时间而确定的更长的预定延迟;重复尝试和延迟步骤,直到连接被建立为止。

在第二示意性实施例中,一种计算机实现的方法包括:唤醒关闭的车辆;请求MQTT连接。所述方法还包括:等待持续基于预期的连接时间的预定超时时间段,直到请求的MQTT连接被建立为止。所述方法还包括:响应于建立MQTT连接,启动计时器;在MQTT连接建立之后,发送队列中待处理的任何车辆警告;除非车辆在计时器到期之前已被提供动力,否则在计时器到期之后结束MQTT连接。

根据本发明的一个实施例,所述方法还包括:在超时时间段到期之后且在MQTT请求尚未被建立的情况下,去除MQTT连接请求;响应于检测到车辆已被提供动力,请求新的MQTT连接。

根据本发明的一个实施例,响应于车辆保持关闭,响应于确定先前的多次连接尝试尚未超出重试计数器而请求新的MQTT连接。

在第三示意性实施例中,一种系统包括车辆处理器,车辆处理器被配置为:响应于车辆点火,请求MQTT连接。车辆处理器还被配置为:等待持续第一计时器的持续时间,第一计时器的持续时间基于用于建立MQTT连接的期望的时间量而被预先确定;在第一计时器到期之后,去除MQTT连接请求。车辆处理器还被配置为:等待持续第二计时器的持续时间,第二计时器的持续时间基于期望使得另一MQTT请求不因为与先前的MQTT连接请求过于接近而被拒绝的延迟而被预先确定。此外,车辆处理器被配置为:重复所述请求、等待第一计时器、去除请求以及等待第二计时器的步骤,直到请求的MQTT连接被建立为止。

根据本发明的一个实施例,第一计时器被设置为30秒。

附图说明

图1示出了示意性的车辆计算系统;

图2示出了用于MQTT连接尝试的示意性处理;

图3示出了示意性重新连接尝试处理;

图4示出了另一示意性重新连接尝试处理;

图5示出了示意性MQTT重试处理。

具体实施方式

根据需要,在此公开具体实施例;然而,应理解的是,所公开的实施例仅为示意性的,并且可以以多种形式和替代形式实施。附图无需按比例绘制;可夸大或最小化一些特征以示出特定组件的细节。因此,此处所公开的具体结构和功能细节不应被解释为限制,而仅仅作为用于教导本领域技术人员以多种形式利用要求保护的主题的代表性基础。

图1示出了用于车辆31的基于车辆的计算系统(VCS)1的示例框式拓扑图。这种基于车辆的计算系统1的示例为由福特汽车公司制造的SYNC系统。设置有基于车辆的计算系统的车辆可包含位于车辆中的可视前端界面4。如果所述界面设置有例如触摸敏感屏幕,则用户还能够与所述界面进行交互。在另一示意性实施例中,通过按钮按压或具有自动语音识别和语音合成的口语对话系统来进行交互。

在图1所示的示意性实施例1中,处理器3控制基于车辆的计算系统的至少一部分操作。设置在车辆内的处理器允许对命令和例程进行车载处理。另外,处理器连接到非持久性存储器5和持久性存储器7两者。在此示意性实施例中,非持久性存储器是随机存取存储器(RAM),持久性存储器是硬盘驱动器(HDD)或闪存。一般说来,持久性(非暂时性)存储器可包括当计算机或其它装置掉电时保持数据的所有形式的存储器。这些存储器包括但不限于:HDD、CD、DVD、磁带、固态驱动器、便携式USB驱动器和任何其它适当形式的持久性存储器。

处理器还设置有允许用户与处理器进行交互的多个不同的输入。在此示意性实施例中,麦克风29、辅助输入25(用于输入33)、USB输入23、GPS输入24、屏幕4(其可为触摸屏显示器)和蓝牙输入15全部被提供。还提供输入选择器51,以允许用户在各种输入之间进行切换。对于麦克风和辅助连接器两者的输入在被传送到处理器之前,由转换器27对所述输入进行模数转换。尽管未示出,但是与VCS进行通信的众多车辆组件和辅助组件可使用车辆网络(诸如但不限于CAN总线)向VCS(或其组件)传送数据并传送来自VCS(或其组件)的数据。

对系统的输出可包括但不限于视觉显示器4以及扬声器13或立体声系统输出。扬声器连接到放大器11,并通过数模转换器9从处理器3接收其信号。还可分别沿19和21所示的双向数据流产生到远程蓝牙装置(诸如个人导航装置(PND)54)或USB装置(诸如车辆导航装置60)的输出。

在一示意性实施例中,系统1使用蓝牙收发器15与用户的移动装置53(例如,蜂窝电话、智能电话、PDA或具有无线远程网络连接能力的任何其它装置)进行通信(17)。移动装置随后可被用于通过例如与蜂窝塔57的通信(55)来与车辆31外部的网络61进行通信(59)。在一些实施例中,蜂窝塔57可以是WiFi接入点。

移动装置与蓝牙收发器之间的示例性通信由信号14表示。

可通过按钮52或类似的输入来指示移动装置53与蓝牙收发器15进行配对。相应地,CPU被指示车载蓝牙收发器与移动装置中的蓝牙收发器进行配对。

可利用例如与移动装置53关联的数据计划、话上数据或DTMF音在CPU3与网络61之间传送数据。可选地,可期望包括具有天线18的车载调制解调器63,以便在CPU 3与网络61之间通过语音频带传送数据(16)。移动装置53随后可被用于通过例如与蜂窝塔57的通信(55)来与车辆31外部的网络61进行通信(59)。在一些实施例中,调制解调器63可与蜂窝塔57建立通信20,以与网络61进行通信。作为非限制性示例,调制解调器63可以是USB蜂窝调制解调器,并且通信20可以是蜂窝通信。

在一个示意性实施例中,处理器设置有包括用于与调制解调器应用软件进行通信的API(Application ProgramInterface,应用程序接口)的操作系统。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件,以完成与(诸如在移动装置中发现的)远程蓝牙收发器的无线通信。蓝牙是IEEE 802PAN(个域网)协议的子集。IEEE 802.11LAN(局域网)协议包括WiFi并与IEEE802PAN具有相当多的交叉功能。两者都适合于车辆内的无线通信。可在该领域使用的另一通信方式是自由空间光通信(诸如IrDA)和非标准化消费者红外(IR)协议。

在另一实施例中,移动装置53包括用于语音频带或宽带数据通信的调制解调器。在话上数据的实施例中,当移动装置的所有者可在数据被传送的同时通过装置说话时,可实施已知为频分复用的技术。在其它时间,当所有者没有在使用装置时,数据传送可使用整个带宽(在一个示例中是300Hz至3.4kHz)。尽管频分复用对于车辆与互联网之间的模拟蜂窝通信而言会是常见的并仍在被使用,但其已经很大程度上被用于数字蜂窝通信的码域多址(CDMA)、时域多址(TDMA)、空域多址(SDMA)的混合体所替代。如果用户具有与移动装置53关联的数据计划,则所述数据计划可允许宽带传输且系统可使用宽得多的带宽(加速数据传送)。在另一实施例中,移动装置53被安装至车辆31的蜂窝通信装置(未示出)所替代。在另一实施例中,移动装置(ND)53可以是能够通过例如(而不限于)802.11g网络(即,WiFi)或WiMax网络进行通信的无线局域网(LAN)装置。

在一个实施例中,传入数据可经由话上数据或数据计划通过移动装置,通过车载蓝牙收发器,并进入车辆的内部处理器3。例如,在某些临时数据的情况下,数据可被存储在HDD或其它存储介质7上,直至不再需要所述数据时为止。

可与车辆进行接口连接的其它的源包括:具有例如USB连接56和/或天线58的个人导航装置54、具有USB 62或其它连接的车辆导航装置60、车载GPS装置24或具有与网络61的连接能力的远程导航系统(未示出)。USB是一类串行联网协议中的一种。IEEE 1394(火线TM(苹果)、i.LINKTM(索尼)和LynxTM(德州仪器))、EIA(电子工业协会)串行协议、IEEE 1284(Centronics端口)、S/PDIF(索尼/飞利浦数字互连格式)和USB-IF(USB开发者论坛)形成了装置-装置串行标准的骨干。多数协议可针对电通信或光通信来被实施。

此外,CPU可与各种其它的辅助装置65进行通信。这些装置可通过无线连接67或有线连接69来连接。辅助装置65可包括但不限于个人媒体播放器、无线保健装置、便携式计算机等。

此外或可选地,可使用例如WiFi(IEEE 803.11)收发器71将CPU连接到基于车辆的无线路由器73。这可允许CPU在本地路由器73的范围内连接到远程网络。

除了由位于车辆中的车辆计算系统执行示例性处理之外,在某些实施例中,还可由与车辆计算系统通信的计算系统来执行示例性处理。这样的系统可包括但不限于:无线装置(例如,但不限于,移动电话)或通过无线装置连接的远程计算系统(例如,但不限于,服务器)。这样的系统可被统称为与车辆关联的计算系统(VACS)。在某些实施例中,VACS的特定组件可根据系统的特定实施来执行处理的特定部分。通过示例而并非限制的方式,如果处理具有与配对的无线装置进行发送或者接收信息的步骤,则很可能由于无线装置不会与自身进行信息的“发送和接收”,而使得无线装置不执行该处理的这一部分。本领域的普通技术人员将理解何时不适合对给定解决方案应用特定的计算系统。

在此讨论的示意性实施例中的每一个实施例中,示出了可由计算系统执行的处理的示例性的、非限制的示例。针对每个处理,执行处理的计算系统出于执行处理的有限目的而变成被配置为专用处理器以执行处理是可行的。所有的处理不需要全部被执行,并且被理解为是可被执行以实现本发明的要素的多种类型的处理的示例。可根据需要向示例性处理添加额外的步骤或从示例性处理去除额外的步骤。

针对附图中描述的示出示意性处理流程的示意性实施例,应注意的是,通用处理器可被临时用作专用处理器,以用于执行通过这些附图示出的部分或全部示例性方法的目的。当执行提供用于执行所述方法的部分或全部步骤的指令的代码时,处理器可被临时改用为专用处理器,直到所述方法完成时为止。在另一示例中,在适当的程度上,根据预先配置的处理器运行的固件可使处理器充当为了执行所述方法或所述方法的某种合理变型的目的而被提供的专用处理器。

示意性实施例提出调节全功率/待命模式和低功率模式的连接和重试策略,其中,关注点至少部分是功率维护。

在全功率/待命模式下,示意性处理被设计为对于可能的失败情况是弹性的,同时,使可用网络资源最优化且遵循运营商要求。由于在高效重新请求网络资源与被考虑可由网络主动连接之间可能存在细线,所以动态策略包括以可配置的“短PD(分组数据)延时计时器”的间隔尝试激活PDN(公共数据网络)连接三次(或者其它合理次数),随后重置“网络访问装置”,以解决任何可能的调制解调器内部失败或应用到调制解调器的失败,随后进行第四次尝试。在该策略的第一阶段期间,脉冲计时器可运行以计算用于完成该阶段的时间段。脉冲计时器的值可从可配置的“长PD延迟”计时器中被减去,并且调制解调器等待长延迟的提醒,随后重复该策略。

在低功率模式下,关注点包括消耗尽可能少的功率,同时保持有效的连接机制。因此,当TCU遇到在该水平的失败时,TCU不重新尝试对网络“访问点”的分组数据连接请求。与此同时,TCU可容忍针对网络的可配置计时器延迟“连接超时”,以建立与MQTT的会话,并且在失败的情况下,可重试可配置次数的尝试。

图2示出了用于MQTT连接尝试的示意性处理。在该示例中,在201,处理检测到点火开关接通状态。因此,处理可在驾驶员启动车辆时尝试MQTT连接。在请求MQTT连接之前,在203,处理可对在该处理中使用的任何变量进行初始化。这些可包括用户/OEM可配置变量,在该情况下,变量包括延迟计时器值和连接延长时间值。

处理请求MQTT连接,并且在205,处理设置第一计时器A。处理使用该计时器确定在处理去除MQTT请求之前有待发生的连接尝试的时间量。在该示例中,计时器可被设置为30秒,但是任何适当的计时器值也可被使用。在经过30秒期间,在207,处理尝试连接到MQTT代理。

如果在209连接尝试不成功,则在211,处理确定计时器A是否已到期。只要有时间剩余,则处理继续连接尝试。一旦计时器到期,则处理在213去除连接尝试,并在215启动第二计时器B。该第二计时器是延迟计时器,并且代表在处理重试连接尝试之前的时延量。一旦在217计时器B到期且获得合适的延迟,则在205,处理重试连接尝试。在该示例中,基于与上面讨论的延迟计时器值进行的比较来确定计时器B运行的时间量。例如,延迟可基于合理预期的MQTT响应时间来被预配置。

如果连接尝试在由计时器A设置的时间内成功,则在219,处理启动计时器C,计时器C是MQTT会话将在点火开关断开状态之后存在的时间量。在221,处理将计时器C已经运行的时间与针对连接延长时间值设置的值进行比较,以确定MQTT会话是否应该保持。一旦计时器C的值超出延长值,则在223,处理终止MQTT会话。

图3示出了示意性重新连接尝试处理。该处理可与存在的重新连接尝试处理类似。在该示例中,在301,处理请求分组数据(PD)连接。与图2类似地,在303,处理对执行所需的任何变量进行初始化。这些值可基于用户或OEM针对变量配置的值,在该示例中,值包括延迟计时器和尝试总计数。

在该示例中,在305,处理对尝试计数器清零,在307,处理将活跃变量设置为“真”。这指示仍需要分组数据连接。在309,处理随后尝试建立PD连接。如果在311成功,则处理退出,已建立期望的连接。

如果连接尝试不成功,则在313,处理确定尝试计数器是否低于尝试总计数可被配置阈值以下。如果计数器在所述阈值以上,则在325,处理将延迟计时器设置为可配置预定值。如果计数器在阈值最大计数以下,则在315,处理使计数器增加,并且在317,处理基于计数器值来引用查找表,以确定适当的延迟时间。

在该示例中,示意性查找表作为317A在图3中被示出。如可从表317A中看出的,延迟值随计数的增加而逐渐增加。这意味着成功的尝试在激活之前经历增加的延迟。

在设置针对延迟的适当时间之后,在319,处理将活跃标志(指示正在进行的连接尝试)设置为假。在321,处理随后激活计数器(在323,计数器运行直到计时器值超过设置的延迟值为止)。然后,连接尝试重复执行。

图4示出了另一示意性重新连接尝试处理。该处理代表在图3中示出的处理的替代处理,并且该替代处理可获取通过图3的处理无法获得的效率。在该示例中,在401,处理接收用于激活PD环境或PD连接尝试的请求。

再次,在403,处理对再次也可由用户/OEM配置的有用变量集进行初始化。在该示例中,处理设置短延迟、长延迟和计数值。处理在405也对尝试计数器清零,并且在407对脉冲计时器进行初始化。

在该示例中,处理使用脉冲计数器来测量突发请求所需的总时间量。该值随后从延迟计时器中被减去,以获取调节由突发尝试占用的时间量的延迟值。

在409,处理尝试PD环境激活/PD连接尝试。对于通过默认载体进行的LTE(长期演进技术)通信(总是在TCU与无线网络网关之间的逻辑路径上进行通信),该激活可包括:在使用Jasper接入点名称(APN)到达MQTT代理之后,TCU应用请求连接到调制解调器TCP/IP堆栈。对于利用额外载体的LTS(长期支持技术)连接(例如,WiFi),这可包括设置新的载体信道。对于3G通信,这可包括PD环境激活和IP地址的获取。

在前述情境下的失败可基于尝试的连接类型而不同。对于LTE通信,常见的失败可能与内部TCU/调制解调器接口问题有关。对于利用额外载体的3G和LTS通信,失败可能由网络问题引起。

如果在411连接尝试成功,则在413,处理重置所有计数器和计时器和/或丢弃它们的值。如果连接尝试不成功,则在415,处理可使尝试计数器增加。如果在417尝试计数仍在预定义阈值以下,则在423,处理可将延迟设置为短延迟值(因为总突发尝试的数量尚未尝试完)。如果在419尝试计数器为阈值(最后一次突发尝试),则处理在421可尝试通过循环飞行模式(禁用所有连接)来尝试休息,随后在423将延迟值设置为短计时器。该周期性重置解决了可通过对系统进行重置而克服的任何问题,在前面的附图中缺少这种重置。

如果尝试计数已超出阈值,则在425,处理可基于长延迟值减去当前脉冲计时器值(先前在突发情况中连接尝试的时间段)来设置延迟值。处理随后在427停止脉冲计时器,并在429重置尝试计数器。

此时,无论延迟被设置为长延迟还是短延迟,在431,处理开始针对在433由延迟设置指定的时间段的延迟计时器。一旦延迟已结束,则在435,处理确定延迟是与长延迟对应还是与短延迟对应。如果延迟是长延迟,则处理循环回重置脉冲计时器(407),然而,如果延迟是短延迟(在可允许数量的突发尝试内的尝试),则处理循环回该尝试以在409激活PD环境。在后面的情况中,脉冲延迟计时器仍测量针对突发的总时间量。

图5示出了示意性MQTT重试处理。在该示例中,处理包括唤醒和警告检查处理。例如,该处理在车辆处于低功率状态时(诸如当车辆未上电时)是有用的。车辆可检测警告或以其它方式接收唤醒命令,在任意实例中可能需求使用连接以用于报告。

在该示例中,处理在501接收唤醒命令并在503建立PD连接。处理还在505对用于MQTT请求尝试的计数器进行清零,并在507发起MQTT代理连接尝试。

在509,处理启动计时器并使计数器增加,随后在511等待以查看连接尝试是否成功。如果处理未连接,则在513,处理确定计时器是否已达到阈值。如果处理在未连接的情况下达到计时器阈值,则在515,处理去除连接尝试请求,并进行至533以确定低功率注册(LPR)条件是否被满足,这将在下面进行讨论。为了启发目的,FPO代表全功率开启,FPS代表全功率待命。

如果处理能够连接,则在517,处理重置计时器并将尝试计数器清零。处理将还重启计时器,以用于追踪MQTT会话的长度。在519,连接的处理确定在队列中是否存在任何待处理的警告。如果在队列中不存在任何待处理的警告,则在521,处理保持MQTT连接活跃持续指定计时器量。这可允许在该时间期间发生的任何警告将被立即排队。一旦计时器到期,则处理检查以查看LPR条件是否被满足。如果在队列中存在一个或更多个警告,则在523,处理将警告发送到适当方。在525,处理随后等待,直到警告被确认为止,此时,在529,处理将警告从队列中清除。当处理正在等待时,在527,处理考虑是否发生超时。该警告发布和等待时间段继续,直到在531运行计时器超过MQTT阈值为止。此时,在533,处理考虑LPR的条件是否被满足。

如果LPR的条件被满足,则在535,只要尝试计数器处于指定的重试阈值以下,则处理将重试连接尝试。如果在535计数超出阈值,则在537,处理将断开PD连接并且结束。如果LPR的条件不满足(如果车辆处于全功率下),则处理将保持连接(如果已建立),或者保持连接尝试(如果连接尚未被建立)。

通过使用示意性实施例,弹性且稳健的连接尝试和重新连接尝试可在全功率或低功率车辆状态下被处理。与此同时,延迟可被最小化,并且可针对解决一些问题所需的重置做出调整。这帮助使客户延迟和可能的打扰最小化,同时提供一致的连接。

尽管上面描述了示例性的实施例,但并不意在这些实施例描述本发明的所有可能形式。更确切地,说明书中使用的词语为描述性词语而非限制性词语,并且应理解的是,可在不脱离本发明的精神和范围的情况下做出各种改变。此外,可以以逻辑方式组合各种实现的实施例的特征,以产生在此公开的实施例的情境适当的变型。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1