时间:2024-05-22
李小文,邵明苗
(重庆邮电大学 通信与信息工程学院,重庆 400065)
Femtocell是放置在家庭环境中的无线接入设备,借助于固定宽带接入作为其回程网络,由网络侧的Femtocell网关汇聚并提供标准的面向移动核心网的接口,工作于授权频段,发射功率较小,覆盖半径也较小,能有效缓解无线带宽的紧张情况。
当用户从一个Femtocell切换到Macrocell时,如果能够尽可能地减少不必要的切换,并且能够支持无缝切换时,用户将感受不到业务的中断。用DL SIT和数据包的丢失数来评估切换过程。在现今的3GPP标准中,硬切换流程同样能够适用于从Femtocell到Macrocell的切换过程。切换过程中将下行链路的数据从源基站发送到目标基站能有效减少包丢失。
[1]中提出了一种无缝切换的方案。UE(User Equipment)将所有满足切换的目标小区罗列起来,维持一个动态的目标小区列表。如果目标小区列表不是空的,那么在切换之前UE将数据发送给所有包含在目标小区列表中的小区,以减少下行链路的服务中断时间。但是由于目标小区列表可能会很庞大,并且可能存在不必要切换的问题(例如终端从A小区切换到B小区后,又迅速地切换到小区C),这种方案会消耗大量的缓存空间。
综合上述所有因素,本文基于对现行3GPP标准进行较少的修改的原则,提出一种方案减少切换过程中的DL SIT。相比于参考文献[1]中提出的方案,本文提出的方案首先可以避免不必要的切换,并且在切换已经激活的时候才触发数据多播过程,因此能够有效地节约缓存空间。
在标准3GPP提供的切换过程中,一旦切换的触发条件得到满足,源eNodeB/HeNodeB将会向核心网中的MME(Mobility Management Entity)发送切换请求,继而MME向目标eN-
odeB/HeNodeB发送切换请求。如果目标基站接受本次切换,则发送切换请求确认信息到MME,继而MME发送切换命令到源基站。源基站接收到切换命令后,将会发送RRC(Radio Resource Control)连接重配置指令到UE,该指令携带UE切换所需的相关信息。同时源基站还会将接收/发送的数据包的序列号信息发送到目标基站。此后源基站开始将从核心网接收到下行数据包转发给目标基站。当用户成功地访问了目标小区后,UE发送RRC连接重配置完成指令以指示切换成功。此后,UE可以恢复上行数据包的发送。如果从源基站转发的数据包已经成功到达目标基站,则下行数据发送也可以恢复;否则,当第一个转发数据包到目标基站时,才恢复下行数据包的发送。当UE成功附着到目标小区后,目标小区将改变下行数据链路,即SGW(Serving Gateway)直接下发数据到目标小区,而不再是先下发到源小区,再由源小区转发到目标小区。最后目标小区通知源小区释放资源。
图1 优化的切换过程
优化的切换流程如图1所示。当MME接收到来自源小区的切换请求时,MME将会决定目标小区,并且向目标小区发送切换请求。当目标小区接收到切换请求时,为了防止进行不必要的切换,首先判断本次切换是不是不必要切换。
如果是不必要切换(假设终端从A小区切换到B小区后,又迅速地切换到小区C),且不必要切换的次数已经达到门限值,小区B则向MME回复切换拒绝信息,并且包括推荐的目标小区C。同时基站B增加Hys(Hysteresis Parameter)和 TTT(Trigger Time Parameters),并向基站C发送信息,指示小区C减小Hys和 TTT,增加Ocn。终端重新测量后将会向小区C发起切换请求。
一段时间后,如果基站B判决在新的切换参数下,在很短的时间内发生不必要切换的概率很小,或是不必要切换的次数在门限值内,则基站B指示基站A停止上报状态报告。
如果本次切换不是不必要切换,则目标基站向MME反馈切换请求确认信息。MME收到该信息后通知源基站,并且向SGW发送多播请求。此后SGW将同时把下行数据包发送给源小区和目标小区。目标小区将维持一个接收缓存器来存储这些下行数据。这里不再通过MME发送数据包的序列号信息到目标小区,也不再通过SGW转发下行数据包到目标小区,取而代之的是源小区将在RRC连接重配置信息中包含数据包序列号状态并发送给UE。当UE在源小区中去附着之后,将直接丢弃接收到的数据包。当UE同步到目标小区后,UE将会发送携带数据包序列号状态的RRC连接重配置完成信息给目标小区。根据接收到的数据包序列号状态信息,目标小区立即判断下一个要发送的数据包的序列号,并且同时开启上行和下行数据发送。此后,目标小区将重新使用在标准中定义的指令来停止SGW的多播发送。
因为切换过程中没有数据转发,当UE在源小区去附着之后,到达源小区的数据包如果没有在目标小区中缓存将会丢失。在后面的仿真中将会看到丢失包的数目很小。事实上针对实时性业务这种包丢失现象可以忽略不计。
从DL SIT和包丢失数两方面来分析优化的切换方案。对于包丢失数,能够估计出为避免切换中的包丢失所需要的缓存大小N。这样的分析方法可以适用于从Macrocell切换到 Femtocell,或从 Femtocell切换到 Macro-cell时的情形。
两个实体之间的延迟D按如下定义:DeNB,MME和 DeNB,SGW具有同样的分布,且是关于随机变量x的函数。DHeNB,MME和DHeNB,SGW具有同样的分布,且是关于随机变量y的函数。从UE接收到RRC连接重配置信息到目标小区接收到RRC连接重配置完成信息的这段时间称为切换执行时间,用变量DHO_exec表示,是关于随机变量h的函数。MME与SGW之间的时间延迟很小,可忽略不计。
采用参考文献[3-4]中提出的x、y、h的密度函数,如下:
这里,d 可以代表x、y 或 h,Nd、αd,j、kd,j、λd,j决 定 分布 的
在3GPP提供的方案中,数据转发的延迟由随机变量U=x+y表示,并且密度函数是fU(t)。DL SIT取决于U和h之间的最大数。数据包在UE或基站内部的延迟不计算在内,因为这与切换过程无关。DL SIT可以通过下面公式计算:
对于本文提议的方案,当UE连接到目标小区后,如果目标小区缓存器不是空的,将会立即恢复对话。否则只有当多播数据到达目标小区后才恢复对话。当SGW端的多播被启动后,数据包到达目标基站的时间是DHeNB,SGW,从此刻开始到UE初始化到源小区的去附着过程,并同步到目标小区的时间是关于随机变量y+y′+x的函数。DL SIT是由h和y"-(y+y′+x)的最大值来决定的 。 y"和 y′都与 y 有同 样的 分布。 令 L=y"-(y+y′+x),密度函数用fL(t)表示,则得到DL SIT的计算公式如下:
假设在t0时刻SGW接收到数据多播信令,从此刻到UE从源小区去附着的延迟是关于随机变量y+y′+x的函数。对于SGW在t0时刻之前发送的数据包,却在UE接收到切换命令之后才到达的数据包将会丢失。假设到达SGW的数据包服从泊松分布,到达率为λp。ti代表第i个数据包从SGW到源小区的时刻。Ti=t0-ti满足厄朗分布,密度函数如下:
它对应的拉普拉斯变换如下:
第i个数据包的发送时延是关于随机变量 xi的函数,其中xi与x有同样的分布。NL代表源小区丢失的包数目。令Wi=y+y′+x+Ti,其对应的密度函数为 fWi(t)。从而得到丢包数目的计算公式如下:
其中FWi(s)是fWi(t)的拉普拉斯变换。
在仿真过程中,设置 αd,j=0.5,Kd,j=2,其中 j=1,2,λd,1=2λd,2,d 代表x、y 和 h。 E[x]=10 ms,E[h]=20 ms;数据包的到达率 λp的取值范围在1/10ms-1~1/40 ms-1。
从图2可以看出,在3GPP标准提出的方案中,随着E[y]的增加DL SIT也大幅度地增加,但是利用本文提出的改进方案DL SIT只是轻微的增加,性能得到改善。
图2 从 Femtocell切换到 Macrocell:DL SIT
从图3可以看出,随着E[y]的增加,丢包数会增加,但是即使E[y]增加到150 ms时候,包丢失的数目也不超过5个。
本文提出了一种基于数据多播的改进的Femtomacro切换方案,仿真结果显示优化切换方案与3GPP的标准切换方案相比,在减少DL SIT和包丢失数方面都得到了可观的改善。
图3 从 Femtocell切换到 Macrocell:包丢失数
参考文献
[1]RATH A,PANWAR S.Fast handover in cellular networks with femtocell[C].in Proc.2012 IEEE ICC.
[2]KIM D,SAWHNEY M,LEE H,et al.A velocitybased bicasting handover scheme for 4G mobile systems[C].in Proc.2008 IWCMC.
[3]PANG A C,LIN Y B,TSAI H M,et al.Serving radio network controller relocation for UMTS all-IP network[J].IEEE J.Sel.Areas Commun.,2004,22(4):617-629.
[4]FANG Y,CHLAMTAC I.Teletraffic analysis and mobility modeling of PCS networks[J].IEEE Trans.Commun.,1999,47(7):1062-1072.
[5]3GPP TS 36.331,Evolved Universal Terrestrial Radio Access(E-UTRA);Radio Resource Control(RRC)protocol specification,v9.0.0[Z].2009-09.
我们致力于保护作者版权,注重分享,被刊用文章因无法核实真实出处,未能及时与作者取得联系,或有版权异议的,请联系管理员,我们会立即处理! 部分文章是来自各大过期杂志,内容仅供学习参考,不准确地方联系删除处理!