监测网络中的拥塞状态的制作方法

文档序号:7553661阅读:219来源:国知局
专利名称:监测网络中的拥塞状态的制作方法
技术领域
本申请涉及网络节点、网络节点中的方法以及计算机可读介质。
背景技术
无线网络包括与至少一个网络节点通信的至少一个终端。例如,在UMTS (通用移动电信系统)中,节点B与至少一个用户设备(UE)通信。在LTE (长期演进)中,演进型节点B CeNodeB)与至少一个UE通信。在包括从终端到网络节点的传送的上行链路方向上,网络节点中的调度器确定终端何时可以将数据传送到网络。由从终端发送到网络的调度请求(SR)告警网络节点中的调度器终端有数据要传送的事实。如果网络节点接收比它有资源去服务的调度请求更多的调度请求,则不去满足一些终端的调度请求。在此情况下,终端必须在本地缓冲器中存储它已经准备好传送的数据并且重新提交调度请求。缓冲器大小具有有限的极限并且在拥塞事件中终端可能填满它的缓冲器。一旦它的缓冲器填满,则终端必须丢掉分组,这对终端功能性有负面影响。因此提供一种用于监测网络中的拥塞状态的改进的方法和器件。通过参考并入本文的3GPP技术规格36.321版本8.4.0描述了演进通用陆地无线接入(E-UTRA)媒体接入控制(MAC)协议。此技术规格从功能的观点描述了 MAC架构和MAC实体。E-UTRA定义了两个MAC实体;一个在UE中和一个在E-UTRAN中。这些MAC实体处理多个传输信道。此技术规格描述如何在E-UTRA网络中执行调度。

发明内容
提供一种安排为监测由终端作出的连续堵塞调度尝试的数量的网络节点。然后,当连续堵塞调度尝试的数量超过阈值时,网络节点可以识别特定终端的拥塞事件。设置阈值以使在终端的缓冲器溢出之前识别拥塞。如果网络节点正在经历拥塞,则经历拥塞的终端的数量将增加,这是因为网络节点将不能够满足由连接到该网络节点的终端作出的所有调度请求。因此,可以由正在经历拥塞的连接到网络节点的终端的数量超过阈值来识别该网络节点中的拥塞。如果网络节点正在经历拥塞,则通过标记发送到所连接的终端的分组来将此情况通信到所连接的终端。可以通过连接到网络节点的终端减少它们的连接的数据率来改善该网络节点中的拥塞。网络节点可以是节点B或eNodeB。终端可以是无线通信装置或用户设备。另外提供一种网络节点中的方法,该方法包括:监测由终端作出的连续堵塞调度尝试的数量;以及当连续堵塞调度尝试的数量超过阈值时,识别终端的拥塞事件。也提供一种承载指令的计算机可读介质,当计算机逻辑执行该指令时,使所述计算机逻辑实现任何以上限定的方法。


现在将参考附图仅以示例的方式来描述用于监测网络节点拥塞状态的方法和器件,在附图中:
图1图示用于UE 100与eNodeB 150之间的通信的多个传送时间间隔(TTI);
图2图示TCP的典型使用;
图3示出标准MCS 310和保守MCS 320的信道位使用的相对比例;
图4a和图4b示出传送流中的连续堵塞事件的数量与端到端延迟之间的关系;
图5示出概述本文所描述的过程的流程图;以及 图6图示与网络节点150通信的多个终端100。
具体实施例方式提供一种方法来基于连续子帧的数量的观察而获取关于终端中的拥塞状态的信息,拥塞状态下禁止由网络节点服务的终端发送或接收数据。然后此信息可用于用拥塞通知来标记数据流。另外,提供一种方法,其中监测连接到网络节点的所有终端的拥塞状态以便确定该网络节点的拥塞状态。在长期演进(LTE)网络中,调度器位于演进型节点B (eNodeB)的媒体接入控制(MAC)层中。为调度上行链路中的终端,调度器在物理下行链路控制信道(PDCCH)上发送上行链路许可,其规定要使用哪个资源块(RB)和哪种传输格式。在网络中操作的终端使用两种机制即调度请求(SR)或缓冲器状态报告(BSR)来向eNodeB供应关于它的缓冲器中的数据的信息。SR是在控制信道(物理上行链路控制信道(PUCCH)或随机接入信道(RACH))上传送的一个位的通知而BSR在数据信道(物理上行链路共享信道,PUSCH)上通常与用户数据一起传送。在eNodeB的MAC层内的调度器调度由eNodeB服务的终端的上行链路传送。每个终端包含用于缓冲数据的缓冲器而终端等待传送时隙来将数据传送到eNodeB。终端通知eNodeB它有想要传送的数据。如果终端有用于在任何传送时间间隔(TTI)中配置的调度请求的有效PUCCH资源,则它在适当的时候发送一个位的调度请求。否则,终端发起随机接入过程并且取消所有未决的调度请求。图1图示用于UE 100与eNodeB 150之间的通信的多个传送时间间隔(TTI )。在t =2 ms处,在UE 100中形成准备好传送到eNodeB 150的数据分组120。终端100可使用PUCCH来将调度请求(SR)发送到eNodeB 150,但可能只在由D-SR间隔确定的预定时间点处这样做。生成用于传送的数据分组的时间与传送调度请求的时间之间的延迟可以与D-SR间隔一样大。在t =5 ms处,第一 SR时隙来到UE 100并且它将SR传送101到eNodeB 150。eNodeB 150从UE 100接收SR并且在调度延迟102之后许可要传送103 (G)到UE 100的允许。在t =17 ms处,eNodeB 150使用HXXH (物理下行链路控制信道)来将它指示到UE100。在t =21ms处,UE 100使用PUSCH来将数据分组120传送104(T)到eNodeB 150。由eNodeB 150接收此传送,但它是不准确的或不完全的,并且因此在t =25 ms处,eNodeB 150使用PHICH (物理HARQ指示符信道,HARQ =混合自动重复请求)来将未确认消息105 (N)发送到 UE 100。在 t =29 ms 处,UE 100 将数据分组重传 106 (R)到 eNodeB 150。eNodeB150成功接收数据分组并且在t =33 ms处,eNodeB 150将确认107 (A)发送到UE 100。使用终端之间的共享资源的分组交换网络可能经历拥塞。当共享资源的入口节点的业务总和超过相同共享资源的出口节点的业务总和时,将发生拥塞。拥塞的典型示例出现在具有特定数量的连接的路由器中。即使路由器具有足够的处理能力来根据估计的链路吞吐量而重新路由该业务,当前链路吞吐量也可能约束来自路由器的外出链路可以应对的业务量。因此,路由器的缓冲器将开始填满并且最终它们将溢出。现在网络经历拥塞并且强制路由器丢掉分组,如以下所解释的。任何路由节点的正常行为提供缓冲器,它可以管理输入/输出链路容量中的一定量的变化并且因此吸收小的拥塞事件。然而,当拥塞足够严重时,路由节点将最终丢掉分组。传输协议可用于减轻被丢掉的分组的影响。传送控制协议(TCP)是面向连接的拥塞控制协议。对于TCP业务,由于没有接收到被丢掉的分组的ACK,发送器将检测到那个特定分组并且将发生重传。另外,TCP协议具有内建的速率自适应特征,当发生分组丢失并且在IP层上发生重传时,该内建的速率自适应特征将降低传送位速率。因此,TCP可以被视为可靠的并且很适合响应网络拥塞。图2图示TCP的典型使用,其中将包含文件传递协议(FTP)数据的分组从终端210发送201到文件服务器220。一旦接收到分组,文件服务器200将确认消息发送202到终端210。确认消息可包含用于下一 TCP分组的可接受的序列号范围。用户数据报协议(UDP)是无连接传输协议,它只提供具有端到端校验和的多路服务。因此,UDP业务不具有与TCP类似的机制来响应拥塞。因为没有任何特定分组的递送是有保证的,所以UDP业务固有地不可靠。除非使用由UDP提供的传输服务的应用层具有允许此情况的某个特殊特征,否则将不重传丢失的UDP分组。尽管应用层机制可实现对拥塞的某个形式的响应,但是m)P自身不以任何方式响应网络拥塞。数据报拥塞控制协议(DCCP)是提供拥塞受控不可靠数据报的双向单播连接的传输协议。DCCP适合于传递相当大数据量并且可以受益于及时性和可靠性之间的折衷上的控制的应用。对于固定分组交换网络,当在链路上提供的负载达到接近链路容量的值时,链路典型地被认为是拥塞的。换句话说,拥塞定义为其中网络链路接近被字节传送完全利用的状态。这主要是因为链路容量是随时间的常数,并且因为入口和出口链路的物理特性是类似的。当所提供的负载超过链路容量时,传送器必须开始丢掉分组,除非有可能缓冲数据直至情况改善。如果在一段时间上保持拥塞状况,则缓冲器占有可增长到超过传送器的缓冲器容量,在此时除了丢掉分组之外没有其它可用手段。在例如无线LAN (IEEE 802.11 a/b/g))或移动网络(例如高速分组接入(HSPA)、长期演进(LTE)以及全球微波接入互操作性(WiMAX)网络)等无线网络中;定义拥塞比简单地根据可以传送的位的数量涉及容量更复杂。无线网络中的拥塞可以定义为其中传送信道接近被完全利用的状态。例如,在LTE的情况下,基站(eNodeB)将在MAC层上管理到移动终端(用户设备,UE)的重传,其将影响eNodeB在任何给定时刻上可以提供吞吐量的业务量。在UE处的成功的接收所需的重传越多,可用于为其它终端提供吞吐量的可用资源(例如,传送功率、可用的传送时隙的数量)越少。在LTE的情况下,通过为物理信道选择适当的调制和编码方案(MCS),基站(eNodeB)也将管理添加多少冗余来保护数据免受传送错误。然后eNodeB匹配产生的位与多个资源块(RB)。为传送选择的MCS越保守(例如,用于处于差的无线电状况的UE),可用于为终端提供吞吐量的可用资源块越少。传送信道的总容量分布在具有不同无线电状况的不同接收器之间;这意味着通过变化保护对终端有用的数据(例如IP分组等有效载荷数据)所必需的冗余(重传、信道编码)的水平,部分消耗共享资源。在图3图示此情况,图3示出标准MCS 310和保守MCS 320的信道位使用的相对比例。这两种编码方案使用相同数量的信道位用于循环冗余校验(CRC)311、321。标准MCS 310中的有效载荷位312的数量大于保守MCS 320中的有效载荷位322的数量。这是因为保守MCS 320需要比标准MCS 310所需的信道编码位313更多的信道编码位323。以上论述集中在从终端到网络节点的通信中的上行链路传送。应该注意到,类似原理适用于下行链路传送。对于每个TTI,用于LTE节点的典型的调度器将检查小区中的所有UE来确定它们是否有要发送的数据。然后,在可调度UE列表中列出有要发送的数据的UE。在低负载的情况下,将非常快地为每个UE许可传送资源。然而,随着网络负载增力口,将更难以为UE许可传送资源。在此情况下,则一些UE将被堵塞而不能传送。哪个UE被堵塞取决于以下因素,例如:信道质量或调度器类型。根据在本文所公开的方法,对于每个UE, eNodeB记录UE被堵塞而不能传送的连续TTI的数量。当UE已经提交·调度请求但eNodeB没有许可那个请求时,该UE被视为被堵塞而不能传送。如果UE被堵塞而不能传送的连续TTI的数量超过给定阈值,则引发拥塞事件。通过以下伪代码的帮助可理解调度器的功能性,为每个TTI (Ims)运行该代码。
权利要求
1.一种网络节点,安排为监测由终端作出的连续堵塞调度尝试的数量,并且当连续堵塞调度尝试的所述数量超过阈值时,识别所述终端的拥塞事件。
2.如权利要求1所述的网络节点,其中所述网络节点监测由多个终端作出的连续堵塞调度尝试的所述数量。
3.如权利要求2所述的网络节点,其中当具有同时引发的拥塞事件的终端的数量超过第二阈值时,所述网络节点识别所述网络节点的拥塞事件。
4.如权利要求3所述的网络节点,其中所述第二阈值是所述多个终端的比例。
5.如上述权利要求中的任一项所述的网络节点,其中在所述网络节点的协议栈的第一层执行所述终端的拥塞事件的所述识别,并且响应于终端的拥塞事件的识别,所述网络节点将通知发送到所述网络节点的所述协议栈的第二层,所述第二层高于所述第一层。
6.如上述权利要求中的任一项所述的网络节点,其中响应于终端的拥塞事件的识别,用拥塞指示符来标记所述终端的数据分组。
7.如上述权利要求中的任一项所述的网络节点,其中响应于终端的拥塞事件的所述识别,所述网络节点在从所述终端接收的分组的IP报头中设置标志。
8.如上述权利要求中的任一项所述的网络节点,其中响应于终端的拥塞事件的所述识别,所述网络节点在所述终端的至少一个数据分组上作出明确拥塞通知。
9.如权利要求1到5中的任一项所述的网络节点,其中响应于所述终端的拥塞事件的所述识别,丢掉所述终端的至少一个数据分组。
10.一种网络节点中的方法,所述方法包括: 监测由终端作出的连续堵塞调度尝试的数量;以及 当连续堵塞调度尝试的所述数量超过阈值时,识别所述终端的拥塞事件。
11.如权利要求10所述的方法,其中所述方法还包括监测由多个终端作出的连续堵塞调度尝试的所述数量。
12.如权利要求10或11所述的方法,其中所述方法还包括当具有同时引发的拥塞事件的终端的数量超过第二阈值时,识别所述网络节点的拥塞事件。
13.如权利要求12所述的方法,其中所述第二阈值是所述多个终端的比例。
14.如权利要求10到13中的任一项所述的方法,其中在所述网络节点的协议栈的第一层执行所述终端的拥塞事件的所述识别,并且响应于终端的拥塞事件的识别,所述方法包括通知所述网络节点的所述协议栈的第二层,所述第二层高于所述第一层。
15.如权利要求10到14中的任一项所述的方法,其中响应于终端的拥塞事件的识别,用拥塞指示符来标记所述终端的数据分组。
16.如权利要求10到15中的任一项所述的方法,其中响应于终端的拥塞事件的所述识别,所述方法还包括在从所述终端接收的分组的IP报头中设置标志。
17.如权利要求10到16中的任一项所述的方法,其中响应于终端的拥塞事件的所述识别,所述方法还包括在所述终端的至少一个数据分组上作出明确拥塞通知。
18.如权利要求10到14中的任一项所述的方法,其中响应于所述终端的拥塞事件的所述识别,丢掉所述终端的至少一个数据分组。
19.一种承载指令的计算机可读介质,当计算机逻辑执行所述指令时,使所述计算机逻辑实现由权利要求10到18限定的方法中的任一个。
全文摘要
一种网络节点,安排为监测(531)由终端作出的连续堵塞调度尝试的数量(532),并且当连续堵塞调度尝试的数量超过阈值时(533),识别终端的拥塞事件(534)。
文档编号H04L12/801GK103181130SQ201080070033
公开日2013年6月26日 申请日期2010年11月8日 优先权日2010年11月8日
发明者I.约翰松, S.万施泰特 申请人:瑞典爱立信有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1