专利名称：基于随路控制命令的数据下载方法
技术领域：
本发明涉及数据通信，具体涉及通信系统中下载数据的方法，更具体地是，涉及一种在蜂窝电信系统中基站控制器和基站间以及基站内部子单元间下载数据的方法。
背景技术：
传统技术从完成下载功能出发，将通讯双方分为主控节点和受控节点。受控节点需要从主控节点下载数据，而主控节点上可存放受控节点的所需数据信息，或者可以从其余地方获取受控节点的数据信息。在蜂窝电信系统中，任何单元都可以根据实际情况充当主控节点或受控节点。比如基站控制器是主控节点，而基站是受控节点；另一方面，在基站内部众多的子单元中，可以有充当主控节点的子单元和受控节点的子单元。
从主控节点向受控节点进行数据下载，传统方式一般采用Client/Server(客户端/服务器)模式，由作为Client的受控节点，向主控节点(即Server)请求数据信息；主控节点可以根据受控节点的请求决定是否需要进行数据下载。一般地，可分3个步骤数据下载开始、分段下载、下载结束。主控节点需要将大量数据传送到受控节点，对于这种不平衡节点间的数据传输，常规做法是主控节点在进行段下载时，使用滑窗发送，发送N(N＞1)段数据包后，等待受控节点的1个应答消息。在网络传送能力允许的前提下，N越大，则效率越高，下载耗时越小。
比如参照GSM(Globe System for Mobile Communication全球移动通信系统)标准协议12.21，BSC→BTS的软件下载核心步骤如下(a)、主控节点在下载开始通知受控节点关于WindowSize(发送窗口)的大小；(b)、主控节点可发送WindowSize个Segment(数据段、数据包)(需要说明的是，最后一轮数据包传送时，连续发送的Segment数完全可能小于或等于WindowSize)；(c)、受控节点逐个接收主控节点的数包，在收全WindowSize个Segment后(或者收完最后若干个Segment后)回应一个ACK(Acknowledge确认消息)；(d)、主控节点重复步骤(b)，直至整个数据下载结束。
上述现有下载方法简单可行，在一般情况下运作正常，但是存在如下缺陷一旦网络丢包，主控节点的发送窗口将停止移动。无论是主控节点的任何一个数据包出现丢失，使得受控节点侧无法收全WindowSize个数据包而发送应答，或是受控节点的应答消息丢失，都会导致主控节点收不到受控节点的确认，而不得不重新发送上述WindowSize个Segment。理论和实践上这都是一种较低效的处理方法。而现实中，网络丢包的问题是不可避免的，所以改进上述方法非常必要。通过专利检索，尚未有针对上述情况予以改进的下载方法。
发明内容
本发明要解决的技术问题在于，针对现有下载方法中的上述缺点，提供一种基于随路控制命令的数据下载方法，在采用本方法进行数据下载时，在出现网络丢包的情况下，主控节点可以尽可能移动滑窗，无需重新发送已经成功发送的数据包；提高下载过程中系统的容错能力。
为解决上述技术问题，本发明提供的基于随路控制命令的数据下载方法包括如下步骤开始下载步骤受控节点向主控节点提出数据信息请求；主控节点进行判断是否需要进行数据下载；如果是，主控节点启动受控节点的数据下载流程；分段下载步骤主控节点连续发送N帧(即窗口大小个数据包)，同时在最后一帧中随路附加控制命令“强制应答”标志位，通知受控节点回应确认；然后设置定时器，等待受控节点的确认；受控节点逐个接受主控节点的数据包，当检测到“强制应答”标志置位时，根据接收窗口内各帧的接收情况生成“接收状态列表”，向主控节点确认；主控节点根据受控节点的应答信息，进行判断若数据已经传送完毕，则下载结束；否则，更新其“重发列表”和“新发列表”，将上述两个列表合并为“滑窗发送列表”，重复分段下载步骤，进行新一轮发送；
下载结束步骤主控节点通知受控节点，整个数据下载流程结束。
在上述本发明提供的下载方法中，设主控节点的发送窗口大小为N(N＞＝1)，受控节点的接收窗口大小为R(R＞＝1)。N和R之间没有限制关系。
当R很大时，意味着“接收状态列表”较长，可能使受控节点回应的ACK消息超过网络传输能力。事实上，由于主控节点每次最多连续发送N个帧(即可能有N帧或者最后的E帧)，而且只关心当前发送帧的接收情况，所以不论R的大小，“接收状态列表”的长度可以不超过N。由于这和主、受控节点的具体实现相关，故在以下描述中，仍只针对“接收状态列表”长度＝R来进行分折。
根据滑窗理论中接收窗口的移动法则可知对于受控节点，若数据段序号落入接收窗口内，则是可接收帧，进行数据接收处理；若在当前可接收帧前的所有帧都已成功接收，则滑窗后移。受控节点接收窗口前的数据都是已经成功接收的，接收窗口内的是可以接收的，而接收窗口后的是不能接收的。主控节点根据“接收状态列表”可知，所有序号位于其列表前的帧已经被成功接收。
为描述方便，不妨假设主控节点连续发送{1，2，3，…N}帧后，受控节点的接收窗口停在{M1，M1+1，…M1+R-1}上，显然M1帧没有接收到。设在此接收窗口中有i(0＜＝i＜＝R)个实际发送的帧受控节点没有收到，则可以有如下推论如果i＝0，则M1＝N+1；如果i＞0，设丢失序号为{M1，M2，…Mi}，M1＜M2…＜Mi＜＝
M1+R-1，Mi＜＝N，其中M1，M2…Mi不一定连续；对于受控节点，可分两种情况情况(a)如果第N帧收到，受控节点检测到随路指令一“强制应答”标志置位，则向主控节点确认“接收状态列表”{M1，M1+1，…M1+R-1}，如下所示M1M1+R-1
则主控节点根据此列表，记录上轮发送失败的序号{M1，M2，…Mi}(长度为i，且Mi＜N)，生成“重发列表”{M1，M2，…Mi}，以及本轮需要发送的“新发列表”{S，…S+(N-i-1)}(共N-i个)。其中，S＝Min(Mi+R，N+1)。生成新的N帧“滑窗发送列表”{M1，M2，…Mi，S，…S+(N-i-1)}，滑窗后移。
举例说明设N＝10，R＝8，(i)若受控节点没有收到序号为2，4，7的帧，则i＝3，{M1，M2，…Mi}即为{2，4，7}，M1＝2；主控节点收到如下形式的“接收状态列表”后，S＝10，将发送{2，4，7，10，11，…16}。若下一次受控节点收到序号为2的数据包时，则接收窗口就移动到{4，5，…11}，以此类推。
2 9
(ii)若受控节点没有收到序号为9的帧，则i＝1，{M1，M2，…Mi}即为{9}，M1＝9；主控节点收到如下形式的“接收状态列表”后，S＝11，将发送{9，11，12…，19}。
9 16
(iii)若受控节点没有收到序号为1～8的帧，则i＝8，{M1，M2，…Mi}即为{1，2，…8}，M1＝i；主控节点收到“接收状态列表”后，将重发{1，2，3…N}，此时发送端滑停止移动。
情况(b)如果受控节点没有收到第N帧，从而检测不到“强制应答”标志，或者受控节点的确认丢失，则主控节点将重发{1，2，3…N}，发送窗口没有移动。
由此可以得出结论1)当接收窗口R足够大时(R＞＝N-1)，a)发送窗口是否发生移动在最坏情况下(即受控节点没有收到主控节点的第N帧，或者其确认丢失)，发送窗口停止移动，主控节点重发所有的数据包；其它情况下，窗口发生了后移。解决了现有技术中发送窗口停止后移的问题。在丢包概率为m的情况下，可以大致比较如下现有技术出现“发送窗口停止移动”的概率为(N+1)m；改进方法出现“发送窗口停止移动”的概率为2m。
b)发送窗口移动程度发送方仅重发接收方上一轮没有收到的帧，效率很高。网络丢帧越少，则发送方的“重发队列”越短，“新发列表”越长，发送窗口后移越大。不妨以一个极端情况来说明当上轮发送丢失了一个数据包时，则发送方仅重发1个数据包；然而在现有下载方法中，发送方仍重发N个数据包，浪费带宽。
2)当R＜(N-1)时，此时由于接收方对于落在接收窗口后面的数据包是不予接收的，所以如果{1，2，…N}中的前R个数据包丢失，发送方也会出现发送窗口停止移动。这样1)中所述的改进方法中出现“发送窗口停止移动”的概率就需要调整为2m+mR3)接收方可以根据实际情况决定R。典型地，若R＝1，则接收方只允许顺序接收数据包，仅接收期望的下一帧而拒绝任何其它帧；若检测到“强制应答”，则将自己的期待序号向主控节点进行确认；主控方将以此为滑窗起点重传后续所有的帧。类似于“后退N帧协议”。虽然浪费了一定的带宽，但是受控节点无需额外的缓冲区来保存出错帧以后的那些帧，而且实现起来比较简单。
通过上述分折可知，采用本发明所供的方法，与现有技术相比，具有如下优点由主控节点在分段下载的数据内容中附加随路信令，受控节点解析此随路信令指示来回应ACK；使得在出现网络丢包的情况下，主控节点可以尽可能移动滑窗，无需重新发送已经成功发送的数据包；提高了下载过程中系统容错能力。
图1是采用本发明的包括软件包在内的蜂窝通信基站系统用于下载软件的组件框图；图2是本发明下载方法的下载过程示意图；图3是本发明下载方法中主控节点进行单个或多个软件下载操作的流程图；图4是图3所示流程图中主控节点进行单个软件下载的具体步骤流程图；图5是图4所示流程图中主控节点进行数据段滑窗发送的具体步骤流程图；图6是本发明下载方法中受控节点执行下载操作的具体步骤流程图。
具体实施例方式
由于数据同步和软件下载基本类似，所以下面仅结合软件下载对本发明的具体实施方式
作进一步详细的描述。其中，下载开始、下载结束、激活版本等步骤为本领域技术人员所熟知，且不属于本发明详细说明的范围，所以在下面的描述中将不再详述。
其中类似的部件用相同的参考字符来标识。本发明将针对在蜂窝通信基站系统中的应用来描述，但是不限于这样的用途。更确切地说，所提供的实施方式仅是为了说明本发明的具体应用过程。
图1所示为蜂窝通信基站系统中那些与本发明有关的组件。如图中所示，BSC101(基站控制器)连接到多个，也就是n个BTS103-1(基站)，…，103-n(以下用参考号103统称)中。BSC101存放BTS103的软件版本(以下用参考号121统称)。每个BTS103包括多个子单元。根据在完成软件下载功能中的角色，子单元可分主控子单元(用参考号113统称)和受控子单元(参考号114)。同时，主控子单元又作为受控节点从主控节点BSC101下载BTS的软件版本。在BTS103-1中，主控子单元是113-1，受控子单元是114-1-1，…，114-1-mi；在BTS103-n中，主控单元是113-n，受控单元是114-n-1…，114-n-mn。一般地，给定的BTS103-x中的子单元114-x的数目与任何其它BTS中的子单元数目无关，因此表示为值mx。不同BTS中的主控单元113可能具备完全不同的功能与结构，同一BTS103中的子单元114也可能具备完全不同的功能与结构；这里仅仅从软件下载的角度将其区分为主控和受控两大类。比如主控子单元可能是“基站操作维护单元OMU”，受控子单元可能是“基站收发单元TRU”。BSC向OMU下载BTS相关软件版本，而OMU又同时具备向TRU下载软件的功能。
BSC101通过相应的通信连接116-1，…，116-n与每个子单元113-1，…，113-n相连。通信连接可以是多路复用的PCM时隙，也可以是包括物理连接上的OSI第二层数据链路。另一方面，在BTS103中，主控子单元113和受控子单元114之间通信连接115可能是总线方式或者是多路复用的PCM时隙。无论如何，BSC101和BTS103之间，以及BTS内部子单元113和114之间通信连接的具体实现方式和本发明无关，所以此处不进行详细说明。本发明适用于任何允许BSC101和每个BTS103的子单元113之间，以及子单元113和114之间存在逻辑独立的通信链路的协议或配置。比如LAPD(LinkAccess Protocol on D Channel D信道上的链路接入规程)和HDLC(High level Data Link Control高速数据链路控制)。逻辑上，通过116，所有的子单元113可以直接对等地在星形结构中连接到BSC。本发明不限于这种设计，而是包括任何这样的方案其中BSC101正好控制与之通信的那个子单元113(以及子单元所处的BTS103)。类似地，BTS103中的受控子单元114都在逻辑上可以直接对等地在星形结构中连接到主控单元113。
下面通过图3所示流程图，进一步说明多个可能事件中的一个触发软件的下载过程，这样的事件包括受控节点向主控节点发送软件请求，主控节点经判断认为应该向受控节点下载版本；从BSC操作员发出命令，请求将下载操作指向所选择的BTS103。
无论何种方式，主控节点在获得需要向受控节点进行下载的版本列表后，将如步骤303所示，从列表中的第一个版本开始启动受控节点下载过程假设需要进行{V1，…，Vk}共K(＞＝1)个版本的下载，那么主控节点将重复K次单个版本的下载过程。在步骤305，主控节点调用“单个版本下载”过程，这个过程(下面将结合图4和图5做更详细地描述)通过“下载开始”、“段下载”、“下载结束”等消息完成一个版本的下载流程。然后，步骤307确定下载处理是否已经针对版本列表{V1…，Vk}中的每个版本执行。如果如此，那么下载处理地程将转向步骤311。否则，在步骤309选择下一个版本后，要重复步骤305～307的处理。在步骤311，主控节点将向受控节点发送“激活版本”的命令来激活所有下载的版本，然后结束下载。虽然只说明了主控节点一次处理一个受控节点的下载过程，但是这并非本发明所要求的；主控节点还可以适应同时并发地处理所有受控节点的下载。
为描述方便，不妨设发送窗口大小为N；接收窗口大小为R；数据段总共为TOTAL个数据包；数据包的序号从0开始；“当前滑窗发送列表”为{{M1，M2….，Mi}，{S，S+1….，S+L-i-1}}，其中“重发列表”i(i＞＝0)帧，“新发列表”L-i帧，L除了最后一轮滑窗发送为E(0＜E＜＝N)外，其余时候均为N。
图4所示为图3中单个版本下载过程的具体步骤流程图；首先，主控节点在向受控节点发送“下载开始”命令，受控节点将产生一个响应，然后向主控节点返回此响应，主控节点接收到该响应，然后进行初始设置“重发列表”为空表，“新发列表”的起点S0＝0，这样“当前滑窗发送列表”即等于“新发列表”{S0，S0+1….，S0+N-1}。
在步骤409，通过调用“数据段滑窗发送”过程(下面参考图5做更详细描述)，完成第一批“段下载”消息的滑窗发送。另一方面，受控单元收到“段下载”消息后，产生“段下载应答”，向主控节点返回此响应，主控节点接收到该响应。
在步骤413，根据其中的“接收状态列表”解析出受控节点的上轮接收遗漏列表，生成临时“重发列表”{M1，M2…，Mi′}′，“发送列表”起点S′，以及发送窗口大小L′(要么为N，要么为E)。而后合成“新滑窗发送列表”{{M1，M2，…，Mi′}′，{S′，S′+1，…，S′+L′-i′-1}}。其中0＜＝i′＜R，i′＜L，Mi′＜S+L-i-1，S′＝min(Mi′+1，S+L-i)，S′+L′-i′-1＜TOTAL。若i′＝0且S′＞＝TOTAL，则L′＝0；在步骤415，主控节点判断是否数据段都已经下载完毕。若“新滑窗发送列表”为空表，即L′＝0，则表示所有的数据段已经下载完毕，“段下载”过程可以中止，此时主控节点将转入步骤423，向受控节点发送“下载结束”命令。受控节点收到“下载结束”消息后，根据图6产生“下载结束”应答，主控节点在步骤425接收到此消息后，则成功完成单个版本的下载过程，返回到过程调用点(即执行在图3所示步骤307重新开始)。否则说明需要继续发送“段下载”消息，则进入步骤419。
在步骤419，主控节点需要进行判断是否需要丢弃此应答消息。此刻可以将所有的发送数据包分为3段所有成功发送的数据包——“当前滑窗发送列表”前的数据包段(以下称为A列表)，已完成发送正在等待确认的数据包——“当前滑窗发送列表”，尚未发送的数据包——“当前滑窗发送列表”后的数据包段。如果根据受控节点“接收状态列表”生成的“新滑窗发送列表”包含于{A列表∪“当前滑窗发送列表”}，说明此应答可以丢弃，即直接转入步骤411，继续等待受控节点的“段下载应答”；否则如步骤419所示，更新“当前滑窗发送列表”(此后表示需要完成发送的数据包)，进入新一轮滑窗发送(步骤421)。然后重复步骤411，继续等待受控节点的“段下载应答”。
图5所示为数据段滑窗发送过程的具体流程步骤；在滑窗发送中，因为需要连续发送“窗口大小”个(L)“段下载”消息，所以由步骤503～517构成一个执行循环，每次发送一条“段下载”消息，循环“窗口大小”次。在步骤503设置执行循环的初始值为0，以及“当前发送序号”等于“当前滑窗发送列表”的第一个元素。在步骤505组装“段下载”消息，准备将序号为“当前发送序号”的数据包传给受控节点。步骤507为判断是否需要随路控制命令即“强制应答”标志置位。如前所述，当数据包是当前“滑窗发送列表”的最后一项(显然上述条件包含如下情况当前数据包是整个软件版本“段下载”消息的最后一条)，应将“强制应答”置位(步骤509)，然后在步骤511进行“段下载”消息发送；否则直接转入步骤511。发送一条“段下载”消息后，在步骤513，从“当前滑窗发送列表”中取下一个元素，更新“当前发送序号”。在步骤515，滑窗循环变量前移一个。步骤517中，对于滑窗循环变量进行判断，若已经完成了“窗口大小”个消息的传送，说明此轮滑窗发送完成，从而在步骤519返回到过程调用点(即，执行在步骤411重新开始)。否则转入步骤505，准备进行下一条“段下载”消息的发送。
图6描述了受控节点处理软件下载的具体步骤流程；在步骤601，受控节点等待从主控节点接收一条消息，当主控节点开始“单个版本下载”过程(图4中的步骤403)，受控单元接收到主控单元的“下载启动”消息，如步骤603所示，由此导致步骤605的执行，受控节点进行启动准备同时将接收窗口的起点初始值设置为0，然后在步骤607向主控节点发送“下载启动应答”消息。
下一条消息可能是“段下载”消息，则在步骤611接收它。然后进行可接收判断，如果“发送序号”没有落入接收窗口内(步骤613)，或者此序号的数据包已经接收过(步骤615)，则无需再进行接收处理，直接进入步骤625处理。否则，在步骤617接收，将数据包中的段信息存放在缓冲区内或者存储区中。
在步骤619，判断是否可以移动接收窗口。若此序号前存在没有接收的数据包，则接收窗口无法后移，直接进入步骤623。否则在步骤621，将滑窗后移直到出现没有接收的序号为止，然后才到步骤623。在步骤623，更新“接收状态列表”。
在步骤625，解析出“段下载”消息中的“强制应答”标志位，若置位则在步骤627向主控节点发送“段下载应答”消息，将自己的“接收状态列表”上报给主控节点。否则跳过步骤627。
再考虑受控单元等待来自主控单元消息的情况(步骤601)，在所有的“段下载”消息完毕后将是“下载结束”消息，受控单元在步骤631接收此消息，在步骤633进行下载结束处理，而后在步骤635向主控节点回应“下载结束确认”消息。
同样地，在下载结束后，受控节点等待主控节点的“激活版本”消息，在步骤637接收它，然后进行“激活版本”的相关处理(步骤639)，向主控节点回应“激活版本确认”(步骤641)，此时由于整个下载流程结束，受控节点进入步骤643，完成版本的更新。
实际上，受控节点可以根据消息的先后顺序设置状态跃迁，比如在接收“下载开始”后才接收“段下载”消息，然后才是“下载结束”命令等等。本发明不再给出详细说明。
权利要求
1.一种基于随路控制命令，用于在主控结点和受控结点之间进行数据下载方法，其特征在于，包括如下步骤1)开始下载受控节点向主控节点提出数据信息请求；主控节点进行判断是否需要进行数据下载；如果是，主控节点启动受控节点的数据下载流程；2)分段下载包括如下步骤a)主控节点连续发送与窗口大小对应的N帧数据包，同时在最后一帧中随路附加控制命令“强制应答”标志位，通知受控节点回应确认，然后设置定时器，等待受控节点的确认；b)受控节点逐个接受主控节点的数据包，当检测到“强制应答”标志置位时，根据接收窗口内各帧的接收情况生成“接收状态列表”，向主控节点确认；c)主控节点根据受控节点的应答信息，进行判断若数据已经传送完毕，则下载结束；否则，更新其“重发列表”和“新发列表”，将上述两个列表合并为“滑窗发送列表”，重复分段下载步骤，进行新一轮数据发送；3)下载结束主控节点通知受控节点，整个数据下载流程结束。
2.根据权利要求1所述下载方法，其特征在于，所述开始下载步骤中还包括下列步骤主控节点确定向受控节点下载的数据信息；将下载操作指向所选择的受控节点；主控节点获得需要向受控节点进行下载的版本或者数据列表，从列表中的第一个项目开始启动受控节点数据下载过程；主控节点重复单项数据的下载过程；主控节点向受控节点发送激活版本的命令激活所有下载的版本，或者数据生效的指示用以生效下载的数据，结束下载。
3.根据权利要求1所述下载方法，其特征在于，所述分段下载步骤还包括如下步骤受控节点产生一个响应，然后向主控节点返回此响应，主控节点接收到该响应，然后进行初始设置使“重发列表”为空表，“新发列表”的起点为S0＝0；调用数据段滑送窗发送，完成第一批段下载消息的滑窗发送；受控单元收到段下载消息后，产生段下载应答，向主控节点返回此响应；如果受控单元已收到第N帧，受控节点检测到随路指令强制应答标志置位，则向主控节点确认“接收状态列表”{M1，M1+1，…M1+R-1}，主控节点根据此列表，记录上轮发送失败的序号{M1，M2，…Mi}(长度为i，且Mi＜N)，生成“重发列表”{M1，M2，…Mi}，以及本轮需要发送的“新发列表”{S，…S+(N-i-1)}(共N-i个)；生成新的N帧“滑窗发送列表”{M1，M2，…Mi，S，…S+(N-i-1)}，滑窗后移；若受控节点没有收到其中的几帧，假设N＝10，R＝8时，丢失序号为2，4，7的帧，则i＝3，{M1，M2，…Mi}即为{2，4，7}，M1＝2；主控节点收到如下所示的“接收状态列表”后，S＝10，将发送{2，4，7，10，11，…16}；若下一次受控节点收到序号为2的数据包时，则接收窗口就移动到{4，5，…11}，以此类推；若受控节点没有收到序号为9的帧，则i＝1，{M1，M2，…Mi}即为{9}，M1＝9；主控节点收到如下形式的“接收状态列表”后，S＝11，将发送{9，11，12，…，19}；若受控节点没有收到序号为1～8的帧，则i＝8，{M1，M2，…Mi}即为{1，2，…8}，M1＝1；主控节点收到“接收状态列表”后，将重发{1，2，3，…N}，此时发送端滑窗停止移动。如果受控节点没有收到第N帧，从而检测不到“强制应答”标志，或者受控节点的确认丢失，则主控节点将重发{1，2，3，…N}，发送窗口不移动；主控节点判断是否数据段都已经下载完毕，若新滑窗发送列表为空表，则表示所有的数据段已经下载完毕，段下载过程中止；主控节点向受控节点发送下载结束命令；主控节点在接收到受控节点的应答消息后，则完成单个版本的下载过程，返回到过程调用点；否则继续发送段下载消息。
4.根据权利要求3所述下载方法，其特征在于，所述数据段滑窗发送步骤中还包括如下步骤；设置执行循环的初始值为0，使当前发送序号等于当前滑窗发送列表的第一个元素；组装段下载消息，将序号为当前发送序号的数据包传给受控节点；判断是否需要随路控制命令即强制应答标志置位；如果数据包是当前滑窗发送列表的最后一项，则将强制应答置位，然后进行段下载消息发送；否则直接发送段下载消息；在发送完一条段下载消息后，从当前滑窗发送列表中取下一个元素，更新当前发送序号；滑窗循环变量前移一个，对滑窗循环变量进行判断，若已经完成了窗口大小个消息的传送，说明此轮滑窗发送完成，返回到过程调用点，否则准备进行下一条段下载消息的发送。
5.根据权利要求1所述下载方法，其特征在于，所述下载方法中受控节点的下载步骤还包括如下步骤；受控节点等待从主控节点接收一条消息，当主控节点开始单个版本下载过程，受控节点接收到主控节点的下载启动消息，受控节点进行启动准备，同时将接收窗口的起点初始值设置为0；向主控节点发送下载启动应答消息；对接收到的段下载消息进行可接收判断，如果发送序号没有落入接收窗口内，或者此序号的数据包已经接收过，则无需再进行接收处理，直接判断是否需要向主控节点发送应答消息，否则，进行接收处理，将数据包中的段信息存放在缓冲区内或者存储区中；判断是否可以移动接收窗口，若此序号前存在没有接收的数据包，则接收窗口无法后移，直接更新接收状态列表；否则移动接收窗口，将滑窗向后移动，直到出现没有接收的序号为止，更新接收状态列表；解析出段下载消息中的强制应答标志位，若置位，则向主控节点发送段下载应答消息，将接收状态列表上报给主控节点；主控节点发送下载结束消息，受控节点接收到此消息，进行下载结束处理，向主控节点回应下载结束确认消息。
6.根据权利要求1-5之一所述下载方法，其特征在于，所述主控节点可以是对一个受控节点进行数据下载处理，还可以同时对多个受控节点进行数据下载处理。
全文摘要
一种在主控结点和受控结点之间进行数据下载的方法，包括如下步骤受控节点提出数据信息请求；主控节点启动数据下载流程；主控节点在最后一帧中随路附加控制命令强制应答标志位，通知受控节点回应确认，然后设置定时器，等待受控节点的确认；受控节点逐个接受主控节点的数据包，当检测到标志置位时，根据接收窗口内各帧的接收情况生成接收状态列表，向主控节点确认；主控节点根据受控节点的应答信息，调整滑窗发送列表。采用本发明的上述方法，受控节点可通过解析此随路信令指示来回应主控节点，在出现网络丢包的情况下，主控节点可以尽可能移动滑窗，无需重新发送已经成功发送的数据包，进而提高了下载过程中系统容错能力。
文档编号H04W4/12GK1499868SQ0214516
公开日2004年5月26日 申请日期2002年11月8日 优先权日2002年11月8日
发明者曾玲玲, 刁坚波 申请人:深圳市中兴通讯股份有限公司