CN102656852B - 用于高速数字用户线软件下载的系统和方法 - Google Patents

Abstract

提供了用于高速数字用户线软件下载的系统和方法。在一个实施例中，提供了一种数字用户线（DSL）收发器单元。所述收发器单元包括：至少一个DSL收发器，其中所述至少一个DSL收发器通过至少一个DSL对实现了嵌入操作信道（EOC）和数据通路；用于存储通过所述DSL对传送的软件文件的第一存储器，其中所述软件文件包括报头和至少一个文件记录；以及用于存储准备表格的第二存储器，其中所述准备表格为在所述数据通路上通信的多个信道建立时隙分配，包括准备软件下载信道从而通过所述数据通路将所述软件文件从所述第一存储器传输至目标单元。

Description

用于高速数字用户线软件下载的系统和方法

背景技术

全球数字用户线（DSL）提供了通过电话网络布线的数字数据传输。全球DSL经常采用提供额外的特征和功能的新的软件版本来更新。下载这些升级可能费时、昂贵，并且经常要求对区间（span）内的每一单元升级。一种对单元升级的方法是通过到访每一单元的实际位置并在现场对该单元升级而实现的。将该单元从其外壳插槽实际移除，移除存储器并采用新的软件版本对存储器重新编程，并且将升级后的单元返回到其插槽。电话公司的员工通常必须到访经常为向下的检查孔的位置。

另一种对远程单元升级的方法是通过DSL嵌入操作信道（EOC）从中央局位置下载新的软件版本升级。EOC是按照DSL标准定义的少量带宽，其中向其分配DSL帧以创建虚拟信道。然而，通过DSL EOC下载更新过慢，因为EOC信道以不足4Kbps运行而目标文件可能大于1兆字节（MB）。因此，实际到访每一单元并在现场对该单元升级或者通过DSL EOC下载升级是费时且昂贵的。

出于上文给出的理由以及出于下文陈述的对于本领域技术人员而言在阅读并理解了本说明书后将变得显而易见的其他理由，在本领域中需要一种SHDSL数据通路上的更快下载机制。

发明内容

下面的说明书提供了一种通过SHDSL的软件下载。这一发明内容是以举例的方式而不是以限制的方式给出的。其仅被提供用于帮助读者理解下面的说明书中描述的至少一个实施例的一些方面。

提供了用于高速数字用户线软件下载的系统和方法。在一个实施例中，提供了一种数字用户线（DSL）收发器单元。所述收发器单元包括：至少一个DSL收发器，其中所述至少一个DSL收发器通过至少一个DSL对实现了嵌入操作信道（EOC）和数据通路；用于存储通过所述DSL对传送的软件文件的第一存储器，其中所述软件文件包括报头和至少一个文件记录；以及用于存储准备（provisioning）表格的第二存储器，其中所述准备表格为在所述数据通路上通信的多个信道建立了时隙分配，包括准备软件下载信道从而通过所述数据通路将所述软件文件从所述第一存储器传输至目标单元。

附图说明

关于下面的描述、所附权利要求和附图，更好地理解这些以及其他特征、方面和优点，其中：

图1是用于实现本发明的一个实施例的SHDSL收发器单元（STU）区间的方框图；

图2是通过SHDSL链路的软件下载机制的本发明的一个实施例的方框图；

图3是在从STU-C到STU-R的成功软件下载期间处于STU-C和STU-R之间的系统数据流的一个实施例的图；

图4是针对单对DSL配置的XTU准备时隙分配的一个实施例的方框图；

图5是发送器过程的本发明的一个实施例的流程图；

图6是接收器过程的本发明的一个实施例的流程图；以及

图7A和7B是处于SHDSL收发器单元（STU）区间内的单元的本发明的一个实施例的方框图。

对所描述的各种特征进行描绘，以凸显与所公开的实施例相关的特征。贯穿本说明书的图以及文字，类似的附图标记表示类似的元件。

具体实施方式

在下面的具体实施方式中，参考构成了其部分的附图，在附图中通过其中可以实践本发明的具体示例性实施例的方式示出。对这些实施例给出了充分详细的描述，从而使本领域技术人员能够实践本发明，并且要理解可以利用其他实施例并且可以做出逻辑、机械和电学的改变而不背离本发明的范围。因此，不要在限制的意义上考虑下面的详细描述。

本发明的实施例提供了一种用于数字用户线（DSL）系统的新的软件下载机制，其允许通过单对高速数字用户线（SHDSL或G.SHDSL）数据通路下载系统软件修订。这相对于现有升级措施使下载时间改善了一个数量级或更大。可以通过将软件文件编码成G.SHDSL 链路上的有效载荷而将新的文件版本从中央局发送至倍增器单元（这里也称为再生器单元）和远程单元。软件下载涉及取得中央局处的SHDSL收发器单元（STU-C）上的固件文件并通过G.SHDSL链路将所述文件下载至目标单元，所述目标单元可以是远端处的SHDSL收发器单元（STU-R）或者SHDSL再生器单元（SRU）。在一个实施例中，数据通路中的软件下载涉及通过G.SHDSL帧的有效载荷区域来下载固件文件。G.SHDSL帧的有效载荷区域正常是为用户以及应用端口数据的传输而保留的。在本发明的一个实施例中，在数据通路内创建专用下载信道，其与其他有效载荷信道（例如，E1或以太网信道）共存，而不干扰它们的操作。在另一实施例中，专用下载信道利用整个G.SHDSL有效载荷区域。这一实施例提供了极快的下载，但是在处于操作时是服务影响的。下文将更加详细地描述两种实施例。

系统软件下载中涉及的固件文件通常是针对目标创建的可执行代码。每一固件文件在报头内具有与其相关的各种属性，包括版本编号和用于在下载完成时确认文件完整性的CRC多项式。将每一文件划分成记录和子记录的序列，从而使下载更易管理。例如，在一个实施例中，最大包尺寸为64字节。为每一记录分配唯一记录编号，在下载期间将所述唯一记录编号与所述记录一起发送。记录还含有CRC多项式，从而允许接收器查错并报告给发送器。

图1是用于实现本发明的一个实施例的SHDSL收发器单元（STU）区间100的方框图。区间100包括通过能够支持G.SHDSL或SHDSL的电话网络的布线而连接的多个单元。这些单元至少包括中央局处的SHDSL收发器单元（STU-C）110和远端处的SHDSL收发器单元（STU-R）130。区间100包括处于STU-C 110和STU-R 130之间的端到端链路101。如针对图1的实施例所示，区间100还可以任选包括在120-1到120-N处示出的构成了链路101的一个或多个SHDSL再生器单元（SRU）。一般而言，SRU（例如诸如SRU120-1）的作用在于通过对其沿链路101接收的信号中继而提高区间100的可能范围。SRU 120-1到120-N双向工作，并且能够沿任一方向同时对信号进行中继。SHDSL标准在单个区间100内支持上至八个SRU。其他DSL标准在单个区间100内支持其他数量的SRU。在一个实施例中，尽管G.SHDSL标准支持八个SRU，但是区间100仅实现了两个SRU。然而，本发明的实施例可以在区间100内包括任何数量的SRU，包括没有SRU。

本发明的实施例提供了用于将位于发送单元（诸如STU-C 110）上的软件文件通过SHDSL链路102传送至目标单元的系统和方法，所述目标单元可以是STU-R 130或者SRU 120-1到120-N之一。STU-R的软件要求通常不同于SRU的软件要求，因而STU-R 130和SRU 120-1通常单独下载它们的软件。因此，区间内的每一单元均单独下载其软件升级。例如，在STU-C 110正在将软件更新下载至STU-R 130时，SRU 120-1不是下载该软件更新，而是通过传递（或者中继）消息而执行正常操作。本说明书中使用的术语“固件”和“软件”是同义词并且是指被创建为在目标上运行的可执行单元。

在其他实施例中，通过DSL链路102将一个或多个转发器（未示出）连接至所述区间。还将通往所述一个或多个转发器的数据通路配置成实现从STU-C 110或者STU-R 130到所述一个或多个转发器的软件下载。

为了采用新的软件对所述单元升级，一个实施例涉及通过SHDSL链路102将STU-C上的固件文件下载至目标单元，所述目标单元可以是STU-R 130或SRU 120-1。固件文件是针对目标创建的可执行单元。STU-R的软件要求通常不同于SRU的软件要求，因而STU-R 130和SRU 120-1通常单独下载它们的软件。换言之，SRU 120-1中的软件不会在STU-C 110中或在STU-R 130中工作。STU-C和STU-R软件版本经常是相同的，但不必相同。

图2是示出了源自STU-C 201到目标STU-R 202的软件下载的方框图。尽管图2示出了将STU-C 201直接连接至STU-R 202，但是本领域普通技术人员在阅读了本说明书之后将理解，在STU-C 201和STU-R 202之间可以存在一个或多个居间的SRU（诸如SRU 120-1到120-N）而对下述描述没有影响。在其他实施例中，软件下载的目标可以是SRU。在这种情况下，目标SRU将按照与下文针对STU-R 202描述的相同的方式接收下载文件。在又其他实施例中，可以如下文所述，采用以针对STU-C 201描述的方式的文件发送运行和以针对STU-R 202描述的方式的文件接收运行来执行软件“上载”（即，例如向STU-C 201的传送）。

本发明的实施例使STU-C 201能够通过利用数据通路230提供文件210向STU-R 202的软件下载。即，通过将软件文件编码成数据通路230上的有效载荷，将软件升级从STU-C 201发送至STU-R 202。利用数据通路230进行软件下载相对于先前的下载方法改善了下载时间。如上所述，本发明的实施例提供了两种软件下载选择。选择1在数据通路230内创建要被配置成进行软件下载的专用信道，其不消耗数据通路230的整个带宽。选择1允许保持在SHDSL链路102上运行的任何现有服务（即，这一选择与其他有效载荷信道共存），但是提供低于第二种选择的总吞吐量。选择2是使用数据通路230的整个带宽进行下载的专用下载。选择2提供了极快的下载，但是影响当前在数据通路230上运行的服务。

在一个实施例中，在操作中，将文件210存储在STU-C 201上。如图2所示，将文件210划分成报头212和多个记录220-1到220-N。报头212包括版本编号和用于在完成下载时确认文件完整性的循环冗余校验（CRC）多项式。将文件210划分成记录220-1到220-N使得对文件210的下载更易管理，原因在于每一记录220-1到220-N的更小尺寸。向每一记录220-1到220-N分配唯一记录编号，在下载期间将所述记录编号与记录220-1到220-N一起发送。每一记录220-1到220-N还含有其自身的CRC多项式，所述多项式允许目标查错并报告给发送器。可以对记录220-1到220-N本身进一步细分。将基于所使用的系统的具体能力来确定每一记录220-1到220-N的包尺寸。在一个实施例中，最大包尺寸为64字节。

如下文关于图3进一步解释的，通过EOC 232将报头212作为数据包240下载。文件记录220-1到220-N被分割成多个包250-1到250-N并通过数据通路230传输。重新组装数据包250-1到250-N，并将其作为文件记录260-1到260-N存储在STU-R 202上的目的地址。

图3是示出了STU-C 201和STU-R 202之间的数据流300的一个实施例的图（假定成功软件下载而没有错误）。可以按照四个阶段讨论数据流300示出的软件下载。阶段1（301）包括通过EOC 232的通信，其执行DSL线路的初始信道设置。阶段2（302）包括通过EOC 232的通信，其协调下载，并且使用现有EOC消息收发信道。这涉及发送器通过如下方式告知接收器其正准备发送文件：在文件报头内提供文件级细节，包括固件版本编号和记录的数量。阶段3（303）包括通过数据通路230的通信用于基于在阶段1（301）内建立的DSL线路的初始信道设置来交换文件记录220-1到220-N。最后，阶段4（304）提供在下载结束时向STU-C 201报告有关下载成功与否的响应。下文更加详细地讨论这些阶段中的每一个。

在阶段1（301）内，通过识别和保留软件下载信道来设置初始信道。在最初设置DSL链路102的准备时，阶段1可以发生在软件下载之前的任何时间。本领域普通技术人员将认识到，DSL链路102可以是在扩展的持续时间内建立的。因而，阶段1可能发生在进入阶段2之前数年。阶段1（301）包括XTU准备请求和XTU准备响应。文中使用的“XTU”是用于任何类型的收发器单元的通用术语。例如，本领域普通技术人员在阅读了本说明书后将认识到，SHDSL系统（ITU-T G.991.2）中的两个收发器单元是STU-C和STU-R，而HDSL系统（ITU-T G.991.1）中的两个收发器单元是网络终端单元（NTU）和线路终端单元（LTU）。因此，文中使用XTU来命名可以在很多系统中通用的消息。将使用STU-C 201作为发送单元而使用STU-R 202作为接收单元继续这一例子。

在阶段1中，发送单元STU-C 201向接收单元STU-R 202发送XTU准备请求。所述XTU准备请求为链路102上通信的每一信道建立时隙分配，包括针对软件下载信道的准备。STU-R 202向STU-C 201返回XTU准备响应，以确认识别并保留了信道时隙分配。本领域普通技术人员在阅读了本说明书之后将认识到，XTU准备请求是STU-C和STU-R之间的正常准备的部分，其通常发生在系统启动期间。利用本发明的实施例，对XTU准备请求进行修改以包括用于分配软件下载信道的信息。在XTU准备请求消息和任何后续的软件下载之间没有任何定时连接。这意味着，可以在阶段1完成之后数星期、数月或者数年执行软件下载。也可以传输后续的XTU准备请求以实现系统配置的变化（例如，再分配时隙）。

表1给出了示例性XTU准备请求消息。在讨论表1以及接下来的后续表格的细节之前，表格的内容和格式的解释是说明性的。首先，所述表格在左列上列举了八进制值而在右列上列举了与所述八进制值相关的功能。其次，通过SHDSL链路发送的所有消息都具有格式相同的报头。针对EOC消息的一个标准包括指示信息类型的消息识别（Id）字段。所有权消息使用消息Id字段来指示“所有权”并且使用子Id字段来指示其是哪一“所有权”消息。有两种类型的所有权消息，包括由消息Id 112指示的所有权请求和由消息Id 240指示的所有权响应。

表1示出了XTU准备请求的例子，其包括准备处于八位组4-19的线路通信信道和处于八位组20和21的软件下载信道。一旦在阶段2内启动了实际软件下载，那么对于实现选择1而言，八位组20识别出分配给软件下载信道的时隙的数量，而八位组21指示所述信道在DSL帧内的起始位置。备选地对于选择2而言，则将全部有效载荷用于软件下载，这是通过将八位组20和21两者均设定为零而准备的。  

表1。

在图4中大体在400处示出了对于一个实施例而言由XTU准备请求设置的时隙分配。如450处大体所示，通过数据通路230的传输包括通过开销消息（在406处大体所示）隔开的有效载荷块（在402处大体所示）。每一开销消息406的长度为一定数量的字节，其使得块402相互区分开，并且还携带诸如警报、EOC信息、错误校验等的额外信息。如455处大体所示，在这一具体实施例中，每一有效载荷块402还包括十二个子块404-1到404-12。每一子块404-1到404-12又包括十六个时隙。在其他实施例中，有效载荷块402可以包括数量更多或更少的子块，并且每一子块可以含有数量更多或更少的时隙。

在460处大体所示，可基于诸如用户的期望接口和带宽要求的因素对分配给DSL线路上的每一信道（例如，E1，以太网）的时隙的数量进行配置。在图4的例子中，向E1信道分配6个时隙（示为410-1和410-12处的TS 1-TS 6）。向以太网信道分配4个时隙（示为420-1和420-12处的TS 7-TS 10）。N×64信道分配了4个时隙（示为430-1和430-12处的TS 11-TS 14）。相应地，表1所示的XTU准备请求的八位组4-19将指示：向E1分配了从时隙1开始的6个时隙（6，1），向以太网分配了从时隙7开始的4个时隙（4，7），并且向N×64分配了从时隙11开始的4个时隙（4，11）。在图4所示的实施例中，向软件下载信道分配了在440-1和440-12处示出的2个时隙（示为440-1和440-12处的TS 15-TS 16）。相应地，表1所示的XTU准备请求的八位组20将指示向软件下载信道分配了2个时隙，而八位组21将指示软件下载信道开始于时隙15（2，15）。尽管具体示出了子块404-1和404-12的分配，但是本领域普通技术人员在阅读了本说明书后将认识到子块404-2和404-11将具有与404-1和404-12相同的分配。

图4所示的具体实施例实现了选择1。即，软件下载可以与E1、以太网和N×64信道上的传输同时发生，因为软件下载信道不利用分配给其他这些信道的任何时隙。如果实现选择2（例如，通过将八位组20和21二者设定为零），那么在正常操作期间，E1、以太网和N×64信道将在分配给它们的时隙上操作，如460处所示。然后，在启动软件下载（下文在阶段2内进行讨论）时，软件信道将在软件下载的持续时间内占用所有的16个时隙（TS 1-16）。在这一周期期间，E1、以太网和N×64信道实际将关闭。一旦完成了软件下载，那么E1、以太网和N×64信道将在它们的分配时隙上恢复通信。

分配给软件下载信道440的时隙越多，数据包可以发送得越快。对于具有两个或更多对的DSL系统而言，由于交错字节，时隙分配将变得更加复杂，但是本领域普通技术人员在阅读了本说明书后将认识到，本说明书的教导将同样好地适用于这样的配置。

返回至图3，阶段2（302）涉及EOC消息收发信道232上的通信以启动和协调软件下载。STU-C 201通过EOC信道232向目标STU-R 202发送数据通路软件下载请求。表2所示的数据通路软件下载请求包括来自文件210的文件报头212的信息，诸如固件版本编号、将发送的文件记录（220-1到220-N）的数量以及针对文件210的校验和。因而，下载请求是所发送的用于启动软件下载的第一消息。如表2所示，STU-C 201将向数据通路软件下载请求中插入与目标收发器单元（即，这里例子中的STU-R 202）相关的目的地址。

表2示出了示例性数据通路软件下载请求。八位组4设定软件下载模式。值01告知目标将在由XTU准备请求准备的软件下载信道上发生软件下载。例如，如果XTU准备请求为软件下载信道准备了时隙TS 15和TS 16，那么八位组4的01值通知目标记录220-1到220-N将通过时隙TS 15和TS 16到达而其他信道（例如，E1、以太网和N×64）将不受干扰。换言之，这将实现选择1。作为对比，八位组4的02值告知目标优先于XTU准备请求的准备。作为替代，全部的DSL有效载荷帧都将专用于软件下载。换言之，八位组4的02值将强制选择2。在一个实施例中，如果将八位组4设定为02，那么使用八位组4a来指示将用于软件下载的时隙的数量。在一个实施例中，如果将八位组4设定为01（选择1），那么八位组4a将不存在。

在一个实施例中，目标STU-R 202将审查STU-C 201正请求传送的文件的版本编号。如果所述版本编号与当前存在于STU-R 202内的软件相同或者比其更早的版本，那么STU-R 202将拒绝STU-C 201的软件下载请求。这是为了防止安装过时的软件。然而，在一些情况下，系统操作员将想要重新加载更早的软件版本或者重新加载当前版本。这可能发生于在当前版本中识别出漏洞（bug）或错误并且需要快速恢复功能时。对于这样的场合，八位组5启动强制模式。如果在下载报头中给出的文件软件版本是与当前在目标上执行的固件文件相同的（或者更早的）版本，那么强制模式指示目标是否应当接受软件下载而不管其版本编号如何。例如，在一个实施例中，八位组5中的值00允许目标拒绝具有相同或者更早版本编号的软件。八位组5中的值02命令目标不要拒绝具有相同或者更早版本编号的软件。八位组5中的值02强制目标接受下载，并重新加载相同（或者更早）版本的软件。

数据通路软件下载请求八位组6-69含有来自报头312的有关要下载的文件的信息，诸如文件校验和、记录的数量等。  

表2。

作为响应，由STU-R 202发送接受下载或拒绝下载的数据通路软件下载响应。与数据通路软件下载请求消息类似，将数据通路软件下载响应作为标准HDLC格式化的EOC消息在EOC信道232上发送。表3示出了示例性数据通路软件下载响应。八位组4指示下载的状态。01指示系统准备好下载，而255指示系统不能遵从。  

表3。

如下文指示的，在软件下载期间通常将发送数据通路软件下载响应两次。第一次将处于阶段2的末尾以指示目标STU-R 202准备好接收数据通路230上的软件下载。第二次将处于阶段4的末尾以指示完成的下载的结果。

阶段3（303）涉及文件记录220-1和220-N通过数据通路230的实际传送。所述传送将要么与其他信道上的传输同时发生为软件下载（即选择1），要么通过将全部DSL有效载荷帧专用于软件下载而发生（即选择2）。将阶段3中的消息的格式化为EOC消息（如下面的表4和表5中所示），除非它们是在数据通路230的时分复用（TDM）时隙上发送的。在一个实施例中，所述消息是高级数据链路控制（HDLC）字节编码的，并且包括源地址和目的地址。目的地址是由发送器分配的，并且具有与等价EOC信道上使用的相同的目的地址值。

表4示出了STU-C 201通过数据通路230向STU-R 202发送的示例性软件下载包请求。在一个实施例中，每一软件下载包请求包括要传送的文件210的64字节片段。假定无错误发生，那么重复地发送软件下载包请求消息，直到完成文件210向STU-R 202的传送为止。软件下载包请求的每种情况都需要来自目标的明确确认，以验证文件210的64字节片段得到了完整、准确的传送。为了促进这一验证，软件下载包请求消息的八位组6和7含有针对由所述软件下载包请求携带的64字节片段的校验和值。所述目标使用这一校验和值来验证所述软件下载包请求的数据完整性。  

表4。

因而通过数据通路230将整个文件下载到目标。所述目标STU-R 202响应于每一软件下载包请求而向发送器STU-C 201发送接受或者拒绝64字节片段下载的软件下载包响应。如果接受了下载，那么发送器通过软件下载包请求发送接下一对应片段。在一个实施例中，如果不接受下载，目标STU-R 202发送报告下载失败的软件下载包响应，并放弃软件下载。

表5示出了示例性软件下载包响应。八位组5基于先前接收到的软件下载包请求来指示下载的状态。八位组5的00值指示软件下载完成（结束）。八位组值01通知STU-C 201上一软件下载包请求成功地传送了其软件片段，并请求STU-C 201继续发送下一软件下载包请求。八位组值02指示发生了错误，并放弃软件下载。  

表5。

阶段4（304）提供在下载结束时向STU-C 201报告有关下载成功与否的响应。目标STU-R 202通过EOC 222向STU-C 201传输第二数据通路软件下载响应（如表3中所示），从而向发送器报告整个下载的成功或失败。这一阶段4数据通路软件下载响应要么包括对发送器的肯定应答，要么包括对发送器的EOC信道错误报告，以指示是否成功地接收了整个文件。在一个实施例中，目标STU-R 202计算整个下载软件文件的校验和，并对照数据通路软件下载请求中的报头212提供的文件校验和对其进行验证。如果校验和不匹配，那么目标STU-R 202通过阶段4的数据通路软件下载响应来传达下载失败。

图5是示出了发送器收发器单元实现的本发明的一个实施例的方法的流程图。图5的方法允许发送器DSL收发器利用DSL数据通路的时隙而不是EOC将文件的软件下载提供给DSL接收器。出于示例性目的，以STU-C作为软件发送器和STU-R作为软件接收器描述了发送器过程。然而，在其他实施例中，STU-R将是发送器，而接收器将是STU-C或SRU。即，通过将软件文件编码成数据通路上的有效载荷而将软件升级从STU-C发送至STU-R。利用数据通路进行软件下载相对于先前通过EOC的下载方法改善了下载时间。如上所述，本发明的实施例提供了两种软件下载选择。选择1在数据通路内创建专用信道，所述信道被配置为进行软件下载，其不消耗数据通路的全部带宽。选择1允许保持在DSL链路上运行的任何现有服务，但是提供低于第二种选择的总吞吐量。选择2是使用数据通路的全部带宽进行下载的专用下载。选择2提供了极快的下载，但是影响当前在数据通路上运行的任何服务。

所述过程在阶段1中的502处开始于在EOC上交换XTU准备消息。如上所述，XTU准备请求为在DSL链路上通信的每一信道建立时隙分配，包括准备软件下载信道。STU-R向STU-C返回XTU准备响应，从而确认识别并保留了信道时隙分配。

一旦完成了准备，所述过程继续至504以确定何时新的软件版本可用于下载至一个或多个目标。

在有可用的新的软件版本（在504处确定）时，所述过程继续至506，从而通过EOC向目标单元发送数据通路软件下载请求。例如，由STU-C通过EOC信道向目标STU-R发送数据通路软件下载请求。所述数据通路软件下载请求（诸如表2中所示）包括来自所要传送的文件的报头的信息，诸如固件版本编号、将发送的文件记录的数量和文件的校验和。如表2所示，在一个实施例中，STU-C将与目标相关的目的地址插入到数据通路软件下载请求中。因而，处于发送器和目标之间的任何居间装置都将简单地传递所述消息。

所述过程继续至508，其中发送器确定是否接受数据通路软件下载请求。在一个实施例中，这是基于通过EOC接收到数据通路软件下载响应而确定的。如果不接受数据通路软件下载请求，那么所述过程继续至510从而报告下载失败，并放弃下载尝试。可以向用户报告下载失败。例如，在想要的软件下载的版本编号早于当前安装的软件或者与当前安装的软件相同时，目标可以拒绝数据通路软件下载请求。在这种情况下，如上所述，数据通路软件下载请求可以强制目标接受下载。在一个实施例中，将在超时周期内未接收到数据通路软件下载响应视为错误，并且所述方法继续至510。

在接受数据通路软件下载请求（在508处确定）时，所述过程继续至512（并进入阶段3），从而在所述数据通路内发送软件下载包请求。在一个实施例中，随着第一包被发送，所述发送单元将指示记录的索引编号和指示子记录的编号重置为0。一旦接收到所述包，就使索引编号递增。

在将所述包发送至STU-R之后，所述方法继续至516，从而从STU-R接收软件下载包响应。软件下载包响应可以指示1)软件下载完成，2)上一软件下载包请求成功地传送了其软件片段并请求STU-C继续发送下一软件下载包请求，或者3)产生了错误并放弃软件下载。

在软件下载包响应请求STU-C继续发送下一软件下载包请求（在518处确定）时，所述方法返回至512，从而在数据通路内发送下一软件下载包请求。在软件下载包响应指示发生了错误（在520处确定）时，所述过程继续至524，从而向用户报告下载失败并放弃下载尝试。在一个实施例中，将在超时周期内未接收到软件下载包响应视为错误，并且所述方法继续至524。

在软件下载包响应指示该软件下载完成而没有错误时，所述过程继续至522（进入阶段4），从而在下载结束时通过EOC接收数据通路软件下载响应。所述数据通路软件下载响应提供在下载结束时向STU-C报告有关下载是否成功的响应。因而，所述过程继续至526，以确定所述数据通路软件下载响应是否是肯定的。这一阶段4数据通路软件下载响应要么包括对发送器的肯定应答，要么包括对发送器的EOC信道错误报告，以指示是否成功地接收了整个文件。在一个实施例中，目标STU-R计算整个下载软件文件的校验和，并对照数据通路软件下载请求中的报头提供的文件校验和对其进行验证。如果校验和不匹配，那么目标STU-R通过阶段4的数据通路软件下载响应来传达下载失败。在一个实施例中，将在下载结束时在超时周期内未接收到数据通路软件下载响应视为错误，并且所述方法继续至524。

图6是示出了接收器单元实施的本发明的一个实施例的方法的流程图。图6的方法允许发送器DSL收发器通过利用DSL数据通路的时隙而不是EOC而将文件的软件下载提供给DSL接收器。出于示例性目的，以STU-C作为软件发送器和STU-R作为软件接收器描述了发送器过程。然而，在其他实施例中，STU-R将是发送器，而接收器将是STU-C或和SRU。

所述过程开始于602，交换XTU准备消息。如上所述，XTU准备请求为在DSL链路上通信的每一信道建立时隙分配，包括准备软件下载信道。STU-R向STU-C返回XTU准备响应，以确认识别并保留了信道时隙分配。

如上所述，本发明的实施例提供了两种软件下载选择。选择1在数据通路内创建专用信道，所述信道被配置为进行软件下载，其不消耗数据通路的全部带宽。选择1允许保持在DSL链路上运行的任何现有服务，但是提供低于第二种选择的总吞吐量。选择2是使用数据通路的全部带宽进行下载的专用下载。选择2提供了极快的下载，但是影响当前在数据通路上运行的任何服务。

一旦完成了准备，所述过程继续至610，在EOC上接收数据通路软件下载请求。所述数据通路软件下载请求命令接收单元基于由XTU准备请求提供的准备而预备在数据通路上进行软件下载。在一个实施例中，如上文所述，数据通路软件下载请求能够优先于XTU准备请求提供的准备，从而实现专用下载。

所述过程继续至612，确定是否接受数据通路软件下载请求。如果不接受数据通路软件下载请求，那么所述过程继续至614以向发送器报告下载失败，并放弃下载尝试。在一个实施例中，报告下载失败包括向STU-C发送指示不接受数据通路软件下载请求的数据通路软件下载响应。例如，在想要的软件下载的版本编号早于当前安装的软件或者与当前安装的软件相同时，目标可以拒绝数据通路软件下载请求。在这种情况下，如上所述，数据通路软件下载请求可以强制目标接受下载。在STU-R接受数据通路软件下载请求时，所述过程继续至620，向STU-C发送指示接受数据通路软件下载请求的数据通路软件下载响应。在这一点上，接收器进入阶段3，从而开始通过DSL数据通路接收软件下载。

接下来，所述过程继续至630，通过数据通路接收软件下载包请求消息。

如果通过软件下载包请求接收到的软件包没有错误（这在635处通过CRC或校验和验证确定）并且基于来自文件报头的信息，预期额外的软件下载包请求（在636处校验），那么所述方法继续至638从而发送指示上一软件下载包请求成功地传送了其软件片段的软件下载包响应，并且请求发送器继续发送下一软件下载包请求。如果通过软件下载包请求接收到的软件包没有错误（这在635处通过CRC或校验和验证确定）并且基于来自文件报头的信息，是最后预期的软件下载包请求（在636处校验），那么所述过程继续至640从而进入阶段4，发送指示软件下载完成的软件下载包响应。如果通过软件下载包请求接收到的软件包并非无错误（这在635处通过CRC或校验和验证确定）或者在超时周期内未接收到预期的软件下载包请求，那么所述过程继续至643，向用户报告下载失败。

所述方法在642中进入阶段4，确定下载文件是否是无错误的。在一个实施例中，目标计算整个下载软件文件的校验和，并对照数据通路软件下载请求中的报头提供的文件校验和对其进行验证。在校验和不匹配时，那么所述过程继续至644，通过EOC借助数据通路软件下载响应传达下载失败。否则，在下载文件无错误时，所述过程继续至646，通过EOC发送指示完成了成功的软件下载的数据通路软件下载响应。

为了提供与关于图1-6描述的收发器单元相关的额外细节，图7A和7B是SHDSL收发器单元（STU）区间内的单元的本发明的一个实施例的方框图。图7A是根据本发明的一种实现的STU 700的方框图。在一个实施例中，STU-C和STU-R使用相同的硬件。每一STU的功能取决于STU中的软件。换言之，每一STU的功能可用单元的软件配置。因此，图7A中描绘的STU 700的实施例可以是STU-C或STU-R。

STU 700包括中央处理单元（CPU）702以及存储器704和710。在一个实施例中，CPU 702是微控制器。在图7A的实施例中，存储器704是静态随机存取存储器（SRAM），而存储器710是闪速存储器，但是可以使用其他类型的存储器。SRAM 704包括存储用于设置下载信道的准备信息的准备表格706。CPU 700用来实现固件文件720，所述固件文件是用由CPU 700执行的软件712实现的。软件712还包括用于STU 700的应用软件。在启动时，将软件文件从闪速存储器710加载到SRAM 704内以供执行，因为闪速存储器710比SRAM 704慢。

固件文件720是固件升级或者是要存储固件升级的地方。例如，如果STU 700是具有用于STU-R（充当目标）的升级的STU-C（充当服务器），那么固件文件720为升级文件。如果STU 700是需要升级的STU-R，那么固件文件720将被升级替代。在要下载固件文件720时，将固件文件720作为单独文件存储在闪速存储器710内并将其从闪速存储器710传送至SRAM 704。将固件文件720按照小的部分移动到SRAM 704，从而构造成包格式。

在软件下载的一个实施例中，重写固件文件720中的任何现有文件。在这一实施例中，如果下载失败，那么所述卡实际上受到破坏且无法工作。因而，在STU 700中实现两个存储器704（诸如两个闪速存储体）。将固件文件720作为新的文件下载到一个存储器704上，其允许STU 700在下载失败的情况下退回到在目的地720处存储的旧文件。

STU 700还包括字段可编程门阵列（FPGA）730以及DSL收发器740-1到740-M。FPGA 730包括高级数据链路控制（HDLC）控制器734，其对原始帧（没有标志、CRC或填充）进行格式化并将所述帧插入到数据通路内。FPGA还包括用于对接收到的信号进行复用和解复用的复用器736。DSL收发器740每一个提供G.SHDSL对，上至M对，其中M是正整数。DSL收发器740-1到740-M分别包括EOC控制器742-1到742-M，DSL成帧器744-1到744-M以及模拟前端（AFE）746-1到756-M。DSL成帧器744从处于一个方向上的各个位流以及处于相反方向上的位流创建时隙图。AFE 746从DSL收发器740输出受到相位幅度调制的模拟信号。

在一些实施例中，在用于FPGA 730的SRAM 704中对数据通路的消息进行部分构造。在SRAM 704中没有对所述消息进行完全构造，因为FPGA 730在某些任务上优于CPU 702。通过DSL收发器740将STU 700连接至DSL链路。FPGA 730允许STU使用DSL链路的数据通路进行软件下载。在软件下载或上载期间，CPU 702与FPGA 730通信并向DSL收发器740请求EOC访问。SRU 700还包括三个用户端口。这些端口包括以太网端口750、N×64端口752和E1端口754。根据需要，使用适当的接口和互连使STU的部件相互通信耦合。

图7A还示出了通过SRU 700的消息流的实施例。短划线对应于数据通路消息流而点线对应于EOC消息流。下文将关于软件下载的各阶段更加详细地描述所述消息流。

图7B是根据本发明的一种实现的SRU 760的方框图。与STU 700类似，SRU 760包括CPU 762、SRAM 764和闪速存储器770。SRAM 764包括含有与软件下载信道相关的信息的准备表格766。闪速存储器770包括软件772，其包括用于SRU 760和固件文件774的应用软件。将SRU 760配置成从STU-C或STU-R下载固件或软件更新。固件文件774是这样的使用文中描述的软件下载的升级的目的地。在一个实施例中，SRU 760通过DSL链路连接至STU-C并且还通过DSL链路连接至STU-R。

CPU 762与DSL收发器780通信。DSL收发器780还包括HDLC控制器782、复用器784-1和784-2以及收发器790-1到790-M。这些部件执行与STU 700的类似部件相似的功能。收发器780对接收到的信号再生。与STU 700不同，SRU 760不具有以太网和E1用户端口。SRU是双向的。短划线表示数据通路消息流，点线表示EOC信道消息流，而宽线表示有效载荷流。根据需要，使用适当的接口和互连使SRU 760的部件相互通信耦合。

软件下载的实施例也可以与SHDSL以外的技术一起工作，所述技术包括但不限于高比特率数字用户线（HDSL）、包括ADSL G.992.1标准的非对称数字用户线（ADSL）以及包括VDSL G.993.2标准的超高比特率数字用户线（VDSL）。

适当的存储装置或介质704、710、764和770包括例如非易失性存储器形式，例如包括半导体存储装置（诸如可擦可编程只读存储器（EPROM）、电可擦可编程只读存储器（EEPROM）和闪速存储装置）、磁盘（诸如本地硬盘和可拆卸盘）和光盘（诸如紧致盘－只读存储器（CD-ROM）盘）。此外，所述存储装置或介质704、710、764和770不需要分别相对于收发器单元700和760处于本地。而且，在这样的实施例的一种实现中，存储器704和764包括现在已知的或者以后开发的任何适当随机存取存储器（RAM）形式，诸如动态随机存取存储器（DRAM）。在其他实施例中，使用其他类型的存储器。

已经出于举例的目的给出了本说明书，并且本说明书并非旨在穷举或限于所公开的实施例。可以使关于具体实施例描述的方面与其他实施例结合或者替代其他实施例的方面。可能出现各种变化和修改，所述变化和修改落在所附权利要求的范围内。因此，显然旨在本发明仅受权利要求及其等同物限制。

Claims (20)

1.一种通过数字用户线（DSL）数据通路下载软件的方法，所述方法包括：

与目标单元交换准备请求消息，所述准备请求消息包括为在DSL数据通路上通信的多个信道提供时隙分配的准备请求，所述多个信道包括用于传输供目标单元执行以升级所述目标单元的可执行指令的软件文件的软件下载信道，其中所述软件下载信道不与用户端口关联；

在嵌入操作信道（EOC）上向目标单元发送数据通路软件下载请求，以启动软件文件的软件下载；

确定何时接受了数据通路软件下载请求；

在接受了数据通路软件下载请求时，在DSL数据通路的软件下载信道中将一个或多个软件下载包请求从DSL收发器单元发送到所述目标单元，所述软件下载包请求每一个包括针对目标单元的所述可执行指令的软件文件的至少一部分；

其中所述软件下载包请求中的每一个在所述DSL收发器单元处发起；

响应于所述一个或多个软件下载包请求中的每一个，在DSL数据通路的软件下载信道中接收来自目标单元的一个或多个软件下载包响应；

基于所述一个或多个软件下载包响应，确定何时完成了软件文件的下载；以及

接收报告是否将软件文件无错误地传输至目标单元的数据通路软件下载响应；

其中所述准备请求在各个DSL帧的有效负载块中分配各个子块的时隙。

2.根据权利要求1所述的方法，其中所述准备请求在DSL数据通路内识别并保留软件下载信道；其中所述数据通路软件下载请求指示用于向目标单元发送软件下载包请求的软件下载模式。

3.根据权利要求1所述的方法，其中所述准备请求识别并保留整个DSL数据通路用于软件下载信道；其中所述数据通路软件下载请求指示用于向目标单元发送软件下载包请求的软件下载模式。

4.根据权利要求1所述的方法，还包括：

从目标单元接收指示识别并保留了软件下载信道的准备响应。

5.根据权利要求1所述的方法，还包括：

其中所述数据通路软件下载请求包括来自软件文件的软件报头的信息，包括含有针对所述软件文件的校验和、版本编号以及文件记录数量的群组中的至少一项。

6.根据权利要求1所述的方法，还包括：

将所述软件文件划分成多个记录；以及

为所述多个记录中的每一个分配唯一标识符。

7.根据权利要求6所述的方法，还包括：

针对所述多个记录中的每一个向所述目标单元传输软件下载包请求。

8.根据权利要求8所述的方法，还包括：

其中所述数据通路软件下载请求包括命令目标单元接受软件下载的强制模式选择。

9.根据权利要求1所述的方法，其中在DSL数据通路的软件下载信道中发送一个或多个软件下载包请求还包括通过DSL数据通路中的时分复用（TDM）时隙向目标单元传输。

10.根据权利要求1所述的方法，其中所述软件文件还包括循环冗余校验（CRC）多项式。

11.根据权利要求1所述的方法，其中所述DSL包括单对高速数字用户线（SHDSL）、高比特率数字用户线（HDSL）、非对称数字用户线（ADSL）和超高比特率数字用户线（VDSL）之一。

12.一种数字用户线（DSL）收发器单元，所述收发器单元包括：

至少一个DSL收发器，其中所述至少一个DSL收发器通过至少一个DSL对实现嵌入操作信道（EOC）和数据通路；

用于存储通过所述DSL对传送至目标单元供该目标单元执行以升级所述目标单元的可执行指令的软件文件的第一存储器，其中所述软件文件包括报头和至少一个文件记录；以及

用于存储准备表格的第二存储器，其中所述准备表格为在所述数据通路上通信的多个信道建立时隙分配，包括准备在所述至少一个DSL对上的数据通路的软件下载信道从而通过所述数据通路将所述软件文件的至少一个文件记录从所述第一存储器传输至目标单元，其中所述DSL收发器单元被配置为将所述至少一个文件记录分段成多个在所述DSL收发器单元处发起的分组，用于在所述软件下载信道上传输；

其中所述软件文件的报头通过EOC从所述第一存储器传输至目标单元；

其中所述DSL收发器单元被配置为在所述EOC上将数据通路软件下载请求发送到所述目标单元以发起所述软件文件的软件下载；

其中所述准备表格建立各个DSL帧的有效负载块中的各个子块的时隙分配。

13.根据权利要求12所述的DSL收发器单元，其中所述多个信道还包括含有以太网信道、E1信道和N×64信道的集合中的至少一项。

14.根据权利要求12所述的DSL收发器单元，还包括：

其中所述收发器单元是中央局处的SHDSL收发器单元（STU-C）或者远端处的SHDSL收发器单元（STU-R）之一；并且

其中所述目标单元是STU-C、STU-R或者SHDSL再生器单元（SRU）之一。

15.根据权利要求12所述的DSL收发器单元，还包括处理器，其中所述处理器命令所述至少一个DSL收发器向目标DSL单元传输XTU准备请求。

16.根据权利要求15所述的DSL收发器单元，其中所述XTU准备请求指示分配给软件下载信道的时隙数量以及所述信道在DSL帧内的起始位置。

17.一种数字用户线（DSL）收发器单元，所述收发器单元包括：

至少一个DSL收发器，其中所述至少一个DSL收发器通过至少一个DSL对实现嵌入操作信道（EOC）和数据通路；

用于存储固件升级文件的第一存储器；

用于存储准备表格的第二存储器，其中所述准备表格为在所述数据通路上通信的多个信道建立时隙分配，包括准备所述至少一个DSL对上的数据通路的软件下载信道从而在通过所述EOC接收到数据通路软件下载请求之后通过所述数据通路接收可执行指令的软件文件的至少一个文件记录，其中所述软件下载信道被准备，用于接收多个在DSL收发器单元处发起的分组，所述多个分组从所述DSL收发器单元被传送，每个分组包括所述软件文件的至少一部分；

处理器，其中所述处理器将通过所述数据通路接收到的软件文件的至少一个文件记录和通过EOC接收到的软件文件的报头存储到所述第一存储器内；

其中所述处理器执行所述软件文件以更新所述收发器单元的固件；以及

其中所述准备表格建立各个DSL帧的有效负载块中的各个子块的时隙分配。

18.根据权利要求17所述的DSL收发器单元，还包括：

其中将所述处理器配置成基于在EOC中接收数据通路软件下载请求而监测软件下载信道中的软件下载包请求。

19.根据权利要求17所述的DSL收发器单元，其中所述第一存储器存储在DSL收发器接收来自发送器DSL收发器单元的软件下载时对所述收发器单元的固件重写的软件升级。

20.根据权利要求17所述的DSL收发器单元，还包括：

其中所述处理器命令所述至少一个DSL收发器响应于接收到的XTU准备请求而向发送器DSL收发器单元传输XTU准备响应；并且

其中在所述至少一个DSL收发器从所述发送器DSL收发器单元接收到数据通路软件下载请求并且处理器确定接受所述数据通路软件下载请求时，所述至少一个DSL收发器通过EOC向所述发送器DSL收发器单元传输数据通路软件下载响应。