lte寻呼小结
- 格式:pptx
- 大小:545.83 KB
- 文档页数:16
LTE外场寻呼事情事件处理经验与手段摘要本文库文档旨在分享关于LT E外场寻呼事情事件处理的经验与手段。
通过探讨寻呼事情事件的背景和重要性,介绍处理此类事件的步骤和技巧,并提供实用的解决方案。
导言随着LT E技术的发展,寻呼事情事件在L TE外场网络中变得越来越普遍。
了解并有效处理这些事件对于维护网络性能和提供优质服务至关重要。
本文将探讨如何识别和处理L TE外场寻呼事情事件,并分享解决问题的经验与技巧。
1.寻呼事情事件背景L T E外场网络中的寻呼事情事件指的是发生在网络中的寻呼消息传输不成功或有延迟的情况。
这种事件可能导致通信中断、呼叫失败、网络容量低下以及用户不满等问题。
因此,及时准确地处理寻呼事情事件对于网络运营商至关重要。
2.寻呼事情事件处理步骤针对LT E外场寻呼事情事件,以下是一些处理步骤的建议:2.1事件识别首先,需要通过网络监控系统或分析工具来识别寻呼事情事件。
通过监测数据和指标,可以确定是否存在寻呼消息传输不成功或有延迟的情况。
2.2问题定位一旦识别出寻呼事情事件,需要进一步确定问题的具体位置和原因。
这可能需要对网络设备、信号传输和配置进行详细的分析和排查。
2.3数据分析在问题定位的基础上,进行深入的数据分析,以了解寻呼消息在何处丢失或延迟。
通过对相关数据的仔细检查,可以确定潜在的故障点并找出解决方案。
2.4故障排除一旦确定了故障点,需要采取相应的措施来解决问题。
可能的解决方案包括调整网络配置、更新软件版本、优化信号传输或设备更换等。
2.5维护和监控处理寻呼事情事件后,应定期进行维护和监控,以确保问题的持续解决和网络的健康运行。
及时跟踪和处理事件可以有效减少用户投诉和提高网络性能。
3.寻呼事情事件处理技巧为了更高效地处理LT E外场寻呼事情事件,以下是一些实用的技巧:3.1建立应急响应流程创建一套完善的应急响应流程,包括事件识别、问题定位、数据分析和故障排除等环节。
在实际操作中,运营商可以通过培训和模拟演练来提高团队的应急响应能力。
The UE may use Discontinuous Reception (DRX) in idle mode in order to reduce power consumption. One Paging Occasion (PO) is a subframe where there may beP-RNTI transmitted on PDCCH addressing the paging message. One Paging Frame (PF) is one Radio Frame, which may contain one or multiple Paging Occasion(s). When DRX is used the UE needs only to monitor one PO per DRX cycle.PF and PO is determined by following formulae using the DRX parameters provided in System Information:PF is given by following equation:SFN mod T= (T div N)*(UE_ID mod N)Index i_s pointing to PO from subframe pattern defined in 7.2 will be derived from followingcalculation:i_s = floor(UE_ID/N) mod NsSystem Information DRX parameters stored in the UE shall be updated locally in the UE whenever the DRX parameter values are changed in SI. If the UE has no IMSI, for instance when making an emergency call without USIM, the UE shall use as default identity UE_ID = 0 in the PF and i_s formulas above.The following Parameters are used for the calculation of the PF and i_s: - T: DRX cycle of the UE. T is determined by the shortest of the UE specific DRX value, if allocated by upper layers, and a default DRX value broadcast in system information. If UEspecific DRX is not configured by upper layers, the default value is applied.- nB: 4T, 2T, T, T/2, T/4, T/8, T/16, T/32.- N: min(T,nB)- Ns: max(1,nB/T)- UE_ID: IMSI mod 1024.IMSI is given as sequence of digits of type Integer (0..9), IMSI shall in the formulae above be interpreted as a decimal integer number, where the first digit given in the sequence represents the highest order digit.For example:IMSI = 12 (digit1=1, digit2=2)In the calculations, this shall be interpreted as the decimal integer "12", not "1x16+2 = 18".PCCH-Config ::= SEQUENCE {defaultPagingCycle ENUMERATED {rf32, rf64, rf128, rf256}, nB ENUMERATED {fourT, twoT, oneT, halfT, quarterT, oneEighthT,oneSixteenthT, oneThirtySecondT}。
LTE基站寻呼拥塞率问题分析处理【摘要】实际现网由于用户量不多,基站负荷较小,4G网络在当前的业务需求以及寻呼策略下,一般的不太容易出现拥塞。
本例中描述的是一起单站信道板(BPL)故障导致寻呼拥塞,由面到点,再通过后台打印进程内容定位出故障位置。
给处理寻呼拥塞积累了一些分析思路。
【关键字】寻呼拥塞寻呼消息堆积【故障现象】在滁州日常KPI指标统计中,发现4月22日的网络的寻呼拥塞率从平时的0.00%突变到0.01%。
图1 滁州整网寻呼拥塞率【告警信息】检查告警信息,发现并没有大规模基站故障告警,只有部分零散的新开基站存在告警,但不会导致整网的寻呼拥塞率高。
【原因分析】寻呼拥塞率KPI分析:寻呼拥塞率=寻呼记录发送不成功次数/混户籍路应发送次数*100%主要是指eNB由于资源限制原因导致寻呼消息发送失败的情况。
由于目前现网是网络容量大于需求,正常情况下不会出现寻呼拥塞。
从核心网的同事了解到当前的寻呼策略是按照最近一次活动的TA寻呼和TA LIST寻呼相结合的。
第一次在最近一次活动的TA下寻呼一次,如果寻呼不到,则在相应的TA LIST 范围内进行寻呼。
表1 LTE网络寻呼的参数设置导致寻呼拥塞的原因可能有:无线测配置的寻呼参数配置失当或者网络的TA划分不合理:检查寻呼参数设置如下:表2 现网寻呼参数的设置其中nB和T属于协议参数,别的属于算法参数;广播的基站所用的寻呼周期(T),在UE使用时还有一个参数,叫做UE的专用寻呼周期,两者取小作为UE的实际使用的寻呼周期。
该UE的专用寻呼周期(取值范围与小区寻呼周期的相同)来自于UE 自己上报的NAS消息,在寻呼UE时,由核心网在寻呼消息中通知基站。
2、硬件配置问题:由面到点,查询全网的寻呼拥塞率指标,发现全部集中在滁州学院宿舍楼室分的8槽位BPL板的4/5/6三个小区,如下图:图2 滁州学院宿舍楼室分寻呼拥塞率综上,检查滁州学院宿舍楼的参数配置,可以排除寻呼信道不够用的情况;检查滁州学院宿舍楼室分的TAC规划,网管配置跟规划的一致,同个TAC下只有28个站点,排除TAC规划问题。
LTE零碎小知识整理X-RNTI(1)SI-RNTI:系统消息(2)P-RNTI:寻呼(3)RA-RNTI:标示用户发随机接入前导所使用的资源块(4)C-RNTI:用户业务(5)TPC-PUCCH—RNTI: PUCCH上行功控信息(6)TPC-PUSCH—RNTI: PUSCH上行功控信息(7)SPS C-RNTI的用法和C-RNTI是一样的,只是使用半静态调度的时候才用;P-RNTI C-RNTI可以在一个子帧里存在,paging的P-RNTI是所有UE共用的见36321的表格。
P-RNTI是FFFE, SI-RNTI是FFFF, 对于所有UE是共用的。
因为手机需要X-RNTI对PDCCH进行盲检DCI,而对于手机来说,每个subframe只可能有一个DCI,所以在UE-Specified Space里面,手机只存在一个RNTI.但是在Common Search Space,手机可以用的公共的RNTI (例如P-RNTI) 不过,PDCCH本身是盲检测的,如果再加上需要在common search space搜索公共的RNTI,UE的开销会是很大的。
在随机接入的过程中,UE会选择一个前导码和时频资源发送前导码-Msg1,发送的子帧位于PRACH资源的位置可以推算出RA-RNTI;RA-RNTI= 1 + t_id+10*f_id;见MAC协议。
基站收到终端的前导后根据收到前导的PRACH时频资源位置推算RA-RNTI,并以该RA-RNTI加扰PDCCH,并发送随机接入响应-Msg2,该Msg2-RAR 中包含了TC-RNTI,是基站为终端分配的临时调度ID(temporal C-RNTI/C-RNTI),用于终端和网络的进一步通信。
MSG3, MSG4省略,当终端随机接入成功后就会将TC-RNTI升级为C-RNTI。
基站要寻呼UE 就通过P-RNTI加扰PDCCH,并指示DAI,UE会解码PDCCH,并根据DAI的信息找到寻呼的下行数据;基站与终端建立连接后(connected),通过C-RNTI或SPS-RNTI进行PDCCH的加扰解扰,进而获得调度信息,截获相应子帧的业务数据。
LTE网络寻呼容量评估目录1概述1.1TAC介绍LTE网络现行寻呼策略为:精准寻呼+普通的寻呼,即UE上次驻留的eNodeB发起寻呼->精准寻呼2S响应超时寻呼下级,最近TAC ->精准寻呼2S响应超时寻呼下级,TAL->精准寻呼2S响应超时重新寻呼, TAL ->寻呼6S超时后重新寻呼,TAL ->寻呼6S超时后寻呼失败。
注:若UE在一个eNodeB下的驻留时间小于2分钟(eNodeB粘性时长),MME将跳过该UE对应的寻呼规则中“最近eNodeB”的寻呼范围,直接跳转到下一级范围(TAC或TA List)进行寻呼。
TAC区作为LTE网络寻呼过程中重要的一环,配置即不能过大也不能过小:过大:会导致核心侧、无线侧资源消耗过大,引起过载、挤占业务信道资源或需要的配置过高问题。
过小:会导致TAC级寻呼成功率偏低、从而触发过多不心要的TAC List级寻呼,并导致TAC编号资源紧张。
1.2TAC区约束条件TAC区最大寻呼能力需要考虑以下2方面的约束条件:1、核心侧MME现网配置条件下的寻呼能力。
2、无线侧寻呼对空口资源占用合理比例下的寻呼能力。
2TAC寻呼能力分析2.1核心侧MME分析核心网进行TAC合并的条件是,一个TAL下挂基站数量不超过150,否则在用户数突增情况下可能造成MME侧设备的负荷问题。
TAL下TAC数量减少对核心网设备负荷的影响在5%左右。
统计现网TAL下挂基站数目情况,150个基站以上的TAL数目达到53个,其中衡水最高达到一个TAL下面825个BBU(TAL:18929),部分过大的TAL需要进行分裂后再进行TAC合并。
按照现网TAL的基站容量对TAL进行了级别分类,建议分批次进行TAL裂分:2.2无线侧空口分析LTE寻呼信息主要由PDSCH(业务信道)承载,因此PDCCH容量无压力,重点分析PDSCH能力如下。
目前现网配置:1、寻呼周期为秒。
2、寻呼标识采用S-TMSI(每用户占用约42bit)。
一、LTE语音相关1.基础概念CS语音:在2G/3G网络中,语音一般由电路域交换(Circuit Switch,CS)系统提供,因此我们一般也称之为CS语音。
IMS语音: 当IP多媒体子系统(IP Multi-media Subsystem,IMS)出现后,我们将IMS提供的语音业务称之为IMS语音,一般也可以称之为PS(分组域交换,Packet Switch)语音,这是因为IMS需要通过分组域交换网络提供的IP通道与用户终端进行交互。
一般认为,IMS语音是LTE/EPS阶段提供的标准语音服务方案。
全IP网络:随着IP技术的发展,电信网络逐渐废弃了传统七号信令网络,而全面转向全IP网络,以第三代伙伴项目(3GPP,3rd GenerationPartnership Project)组织为例,LTE 将采用全IP 化核心网,抛弃了当前2G/3G系统中的电路交换域,而将分组交换域进行研究,从而定义了全IP的长期演进/演进分组系统网络LTE/EPS(Long TermEvolution/Evolved PacketSystem[1])。
因此在LTE/EPS网络中CS语音将不可用。
由于语音业务对时延的要求比较高, 在目前的3G 及其以前的系统中, 都通过电路域承载。
利用专用资源。
语音业务通过IP 承载已经成为发展趋势。
在LTE( Long Term Evolution) 系统中, 只存在分组域, 语音业务通过VoIP( Voice over Internet Protocol) 承载。
2.LTE语音实现方案LTE 将采用全IP 化核心网,从而带来对传统电路域语音业务承载的变革。
CS回退(CS FallBack)技术。
使用CS 回退技术可把语音业务从LTE 网络转移到传统的2G 或3G 网络,通过传统的电路域进行语音承载。
缺点:CS 回退过程中将发生inter- RAT 小区选择或切换,因此带来较大的呼叫建立延迟,且CS 回退要求2G/3G 网络与E- UTRAN 网络重叠覆盖,没有传统2G/3G 网络的新兴运营商无法采用此方案。
移动lte个人工作总结在过去的一段时间里,我一直致力于移动LTE网络的优化工作。
在这个过程中,我学到了很多新知识,也积累了丰富的工作经验。
现在,我想对我的工作进行总结和反思。
首先,我主要的工作内容是对移动LTE网络进行优化。
这包括对网络覆盖范围、信号质量、数据传输速率等方面进行调整和改进。
我通过数据分析和现场测试,发现了一些网络问题,并提出了相应的解决方案。
通过我的努力,我们的LTE网络的性能得到了显著提升,用户体验也得到了改善。
在工作中,我还深入研究了LTE网络的相关技术,包括蜂窝网络原理、基站配置、天线优化等方面。
通过学习这些知识,我对LTE网络的工作原理和优化方法有了更深入的理解,也为我的工作提供了更多的思路和方法。
在工作中,我也遇到了一些挑战和困难。
在一些复杂的网络问题上,我花了很多时间进行思考和尝试,但并没有找到很好的解决方案。
尽管如此,我并没有放弃,而是坚持不懈地去寻找问题的根源,并最终找到了解决问题的方法。
这个过程让我更加坚定了自己的决心和毅力。
在未来的工作中,我会继续努力学习,跟上新技术的发展,不断提升自己的专业水平。
同时,我也会继续坚持对LTE网络进行深入的优化工作,为用户提供更好的网络体验。
希望能够在未来的工作中取得更好的成绩,为公司的发展做出更大的贡献。
在过去的一段时间里,我一直致力于移动LTE网络的优化工作。
在这个过程中,我学到了很多新知识,也积累了丰富的工作经验。
现在,我想对我的工作进行总结和反思。
首先,我要感谢团队合作。
在LTE网络的优化工作中,团队合作起着至关重要的作用。
我们一起分析问题,讨论解决方案,共同努力实现网络的改善。
团队的支持和合作使得我们的工作进展顺利,也让我感受到了团队的力量。
在这段时间的工作中,我主要的任务是对LTE网络进行优化。
我们将重点放在了网络覆盖范围、信号质量、数据传输速率等方面。
经过不断的数据分析和现场测试,我们成功地发现了一些网络问题,并提出了相应的解决方案。
eNB上,寻呼相关的参数有两个,作为广播消息在SIB2中传递给UE:其中defaultPagingCycle即T,决定DRX周期即寻呼周期,单位为rf(无限帧,10ms),取值范围是32、64、128和256。
值越大,RRC_IDLE状态下UE的电力消耗越少,但是相应的,寻呼消息的平均延迟越大,接通的时延也越大。
nB表征寻呼密度,取值范围是4T、2T、T、T/2、T/4、T/8、T/16、T/32,图中oneT表示每个无线帧有1个子帧用于寻呼,如果设置为T/32则表示每32个无线帧有1个子帧用于寻呼,该值决定了LTE系统的寻呼容量。
nB的取值表征寻呼组的数量,如T取值128,nB取值T,则相当于将所有的用户分为128个寻呼组,如果T取值64,nB取值T/4,则分为16个寻呼组,寻呼组越多,每个组中用户数量越少。
LTE寻呼在物理信道PDSCH信道传输,每个寻呼信道最多可以寻呼16个用户,根据nB 的取值,可以计算出小区的寻呼容量:由于移动通信寻呼的突发性,一般要求网络的寻呼负荷不超过50%的寻呼容量,因此,在进行网络规划、参数规划的时候,需要考虑综合TAC、用户分布等因素,规划寻呼参数:一般情况下,LTE小区寻呼参数建议设置:–T=64或者128,nB=T此时,寻呼周期640/1280ms,寻呼容量:1600次/秒特殊场景(如大型活动、比赛现场),需要对某些小区的寻呼参数进行优化调整,可以采用的方案如下:–nB:增大nB,提高小区寻呼容量,减少寻呼拥塞,如nB→2T/4T–T:T值越大,寻呼时延越长,寻呼组增加,每个寻呼信道中的用户越少,反之寻呼时延缩短,每个寻呼信道用户增加,可能导致某个时刻一个寻呼组寻呼的用户超过16个,反而增加的寻呼时延,因此,可以根据实际用户的数量,调整T值。
7.6 LTE寻呼7.6.1寻呼概述网络可以向空闲状态发送寻呼,也可以向连接状态的UE发送寻呼。
寻呼过程可以由核心网触发,也可以由eNodeB触发。
在LTE网络中,发送寻呼主要有如下几种场景(1)发送寻呼信息给RRC_IDLE状态的UE。
这种情况下寻呼过程是由核心网触发,用于通知某个UE接收寻呼请求(2)通知RRC_IDLE/RRC_CONNECTED状态下的UE系统信息改变。
这种情况下寻呼过程是由eNodeB触发,用于通知系统信息更新。
(3)通知UE关于ETWS(地震、海啸预警系统)信息。
寻呼还可以发送地震、海啸预警系统信息、商业移动告警服务。
(4)通知UE关于CMAS(商业移动告警服务)通知信息。
7.6.2寻呼过程处于Idle模式下的终端,根据网络广播的相关参数使用非连续接收(DRX)的方式周期性地去监听寻呼消息。
终端在一个DRX的周期内,可以只在相应的寻呼无线帧上的寻呼时刻先去监听PDCCH上是否携带有P—RNTI,进而去判断相应的PDSCH上是否有承载寻呼消息。
如果在PDCCH上携带有P—RNTI,就按照PDCCH 上指示的PDSCH的参数去接收PDSCH物理信道上的数据;而如果终端在PDCCH上未解析出P—RNTI,则无需再去接收PDSCH物理信道,就可以依照DRX周期进入休眠。
寻呼DRX是指处在RRC空闲状态的UE不连续地监测寻呼信道(PCH)。
它的主要优点就是实现手机较低功耗、较低的延迟和较低的网络负荷。
在连接(Connected)模式下,终端需要根据网络配置的相关参数(如Short DRX Cycle和Long DRX Cycle等)周期性地去监听PDCCH信道。
7.6.3寻呼帧和寻呼时机RRC_IDLE状态下的UE在特定的子帧(1ms)监听PDCCH,这些特定的子帧称为寻呼时机(PO,Pag-ing Occasion),这些子帧所在的无线帧(10ms)称为寻呼帧(PF,Paging Frame)。
河西CSFB用户无法做被叫寻呼问题分析故障现象:1月18日iPhone5S被叫CSFB测试中发现,在河西区域路测被叫接通率只有30%,现场技术人员马上组织对问题进行跟踪和定位。
组网情况:目前TDD-LTE组网图入下:其中EnodeB为中兴设备,MME为华为设备,MSCserver为诺西设备。
目前采用的CSFB技术原理如下:TD-LTE/TD-SCDMA/GSM(GPRS)多模单待手持终端在给MME发送的附着请求消息中携带支持CSFB能力的指示。
MME在收到用户的联合附着请求后,在进行EPS附着的同时,会推导出其相关CS域的VLR信息,并向这个VLR 发起位置更新请求,VLR收到位置更新请求以后,会将该用户标记为已经进行EPS附着了,并保存用户的MME的IP地址,这样,VLR中就创建了用户的VLR与MME间的SGs关联。
随后,MSC Server/VLR会进行CS域位置更新并把用户的TMSI和LAI(位置区标识)传给MME,从而在MME中建立SGs关联。
最后,MME把VLR给用户分配的TMSI以及LAI等信息包含在附着请求接受消息中发送给UE,此时就表明用户的联合附着已经成功了。
联合附着成功之后,启用CSFB能力的用户在TD-LTE网络中就可以处理电路域业务了。
故障现象分析:在现场测试发现除iPhone5s外,lg-E785,中兴9810,华为D2手机都存在70%以上的未接通概率,从测试的情况上基本上可以排除是终端问题,或是终端设备与中兴网络设备的配合问题。
在终端不能做被叫时发现主叫CSFB是正常的,并且手机终端可以正常上网。
通过数据核查和主叫CSFB正常的现象我们初步排除enode测数据配置问题。
1月19日,中兴组织人员联合移动公司技术支持人员在河西区域再次进行测试并跟踪信令分析。
现场情况发现如果TAU正常时被叫能正常接通并CSFB 至GSM网络,TAU失败被叫就无法正常接通。
正常时信令截图如下:我们可以发现UE主动上报RRC请求并且扩展服务请求也成功,但是在TAU 失败时,MME上没有任何信令,如下是TAU请求失败信令:在故障时我们在enodeb测也会发现UE释放请求,S1 Application Protocol (S1ap)里面显示接口建立步骤失败。
一、LTE语音相关1.基础概念CS语音:在2G/3G网络中,语音一般由电路域交换(Circuit Switch,CS)系统提供,因此我们一般也称之为CS语音。
IMS语音: 当IP多媒体子系统(IP Multi-media Subsystem,IMS)出现后,我们将IMS提供的语音业务称之为IMS语音,一般也可以称之为PS(分组域交换,Packet Switch)语音,这是因为IMS需要通过分组域交换网络提供的IP通道与用户终端进行交互。
一般认为,IMS语音是LTE/EPS阶段提供的标准语音服务方案。
全IP网络:随着IP技术的发展,电信网络逐渐废弃了传统七号信令网络,而全面转向全IP网络,以第三代伙伴项目(3GPP,3rd GenerationPartnership Project)组织为例,LTE 将采用全IP 化核心网,抛弃了当前2G/3G系统中的电路交换域,而将分组交换域进行研究,从而定义了全IP的长期演进/演进分组系统网络LTE/EPS(Long TermEvolution/Evolved PacketSystem[1])。
因此在LTE/EPS网络中CS语音将不可用。
由于语音业务对时延的要求比较高, 在目前的3G 及其以前的系统中, 都通过电路域承载。
利用专用资源。
语音业务通过IP 承载已经成为发展趋势。
在LTE( Long Term Evolution) 系统中, 只存在分组域, 语音业务通过VoIP( Voice over Internet Protocol) 承载。
2.LTE语音实现方案LTE 将采用全IP 化核心网,从而带来对传统电路域语音业务承载的变革。
CS回退(CS FallBack)技术。
使用CS 回退技术可把语音业务从LTE 网络转移到传统的2G 或3G 网络,通过传统的电路域进行语音承载。
缺点:CS 回退过程中将发生inter- RAT 小区选择或切换,因此带来较大的呼叫建立延迟,且CS 回退要求2G/3G 网络与E- UTRAN 网络重叠覆盖,没有传统2G/3G 网络的新兴运营商无法采用此方案。
1、LTE 相关信道映射信道类型信道名称PBCH(物理播送信道〕TD-S 类似信道PCCPCH功能简介MIB•传输上下行数据调度信令•上行功控命令掌握信道PDCCH〔下行物理掌握信道) HS-SCCH•寻呼消息调度授权信令•RACH 响应调度授权信令业务信道PHICH(HARQ 指示信道〕PCFICH〔掌握格式指示信道〕PRACH〔随机接入信道〕PUCCH〔上行物理掌握信道〕PDSCH〔下行物理共享信道〕PUSCH〔上行物理共享信道〕ADPCHN/APRACHHS-SICHPDSCHPUSCH传输掌握信息 HI〔ACK/NACK)指示 PDCCH 长度的信息用户接入恳求信息传输上行用户的掌握信息,包括 CQI, ACK/NAK反响,调度恳求等。
闭环功控参数 TCP下行用户数据、RRC 信令、SIB、寻呼消息上行用户数据、用户掌握信息反响,包括CQI,PMI,RI规律信道:播送,寻呼,多播,掌握,业务(即掌握和业务两大类)传输信道:播送,寻呼,多播,共享特殊子帧包含三个部分:DwPTS(downlink pilot time slot),GP(guard period),UpPTS(uplink pilot time slot)。
DwPTS 传输的是下行的参考信号,也可以传输一些掌握信息。
UpPTS 上可以传输一些短的RACH 和SRS 的信息。
GP 是上下行之间的保护时间。
调制方式:PCFICH QPSKPHICH BPSKPBCH QPSKPDCCH QPSKPDSCH QPSK, 16QAM, 64QAMPUCCH BPSK, QPSKPUSCH QPSK, 16QAM, 64QAMPRACH 不用星座图,用ZC 序列.2、LTE 小区搜寻流程:PSS >SSS >RS >BCH.Mode 传输模式技术描述应用场景1 单天线传输信息通过单天线进展发送无法布放双通道室分系统的室内站2 放射分集3 开环空间复用闭环空间复用同一信息的多个信号副本分别通过多个衰落特性相互独立的信道进展发送终端不反响信道信息,放射端依据预定义的信道信息来确定放射信号需要终端反响信道信息,放射端承受该信息进展信号预处理以产生空间独立性信道质量不好时,如小区边缘信道质量高且空间独立性强时4 信道质量高且空间独立性强时。
LTE系统消息,语音业务和attach信令一、LTE系统消息LTE系统消息主要包括MIB和SIB,如下所示:MIB: 下行链路带宽,SFN和PHICH信道配置信息SIB1:小区接入信息和SIB(除了SIB1)的调度信息SIB2:小区接入bar信息以及无线信道配置参数SIB3:服务小区重选信息SIB4:同频邻区重选信息SIB5:异频重选信息SIB6: UTRAN重选信息SIB7: GERAN重选信息SIB8: CDMA2000重选信息SIB9: HOME ENB IDSIB10~SIB11: ETMS (Earthquake and Tsunami WarningSystem)通知二、附着信令流程及中文释义Attach附着信令流程:Attach request附着请求rrcConnectionRequest RRC(Radio Resource Control,无线资源控制)连接请求rrcConnectionSetup RRC连接建立rrcConnectionSetupComplete RRC连接设置完成rrcConnectionReconfiguration rrc连接重配置dl Information Transfer DL信息传输rrc Connection Reconfiguration Complete rrc连接重配置完成Security protected NAS message 安全保护的NAS(Non-AccessStratum,非接入层)消息Authentication request认证请求Authentication response验证响应ulInformationTransfer UL信息传输dlInformationTransfer DL信息传输Security protected NAS message安全保护的NAS消息Security mode command安全模式命令Security mode complete安全模式完成ulInformationTransfer UL信息传输ueCapabilityEnquiry UE能力查询ueCapabilityInformation UE能力信息securityModeCommand安全模式命令rrcConnectionReconfiguration RRC连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成Security protected NAS message安全保护的NAS消息Attach accept附着接受Activate default EPS bearer context request激活默认EPS承载上下文请求Activate default EPS bearer context accept激活默认EPS承载上下文接受Attach complete附着完成ulInformationTransfer UL信息传输rrcConnectionReconfiguration RRC连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成attach去附着信令流程:Detach request去附着请求ulInformationTransfer UL信息传输dlInformationTransfer DL信息传输Security protected NAS message安全保护的NAS消息Detach accept去附着接受rrcConnectionRelease rrc连接释放PDN connectivity request PDN(Packet Switched Public DataNetwork,分组交换公共数据网)连接请求三、呼叫主被叫业务信令流程及中文释义UE主叫信令流程:Extended service request扩展服务请求rrcConnectionRequest RRC连接请求rrcConnectionSetup RRC连接建立rrcConnectionSetupComplete RRC连接建立完成rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成securityModeCommand安全模式命令rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成rrcConnectionRelease rrc连接释放UE被叫信令流程:systemInformationBlockType1系统信息块类型1 systemInformationBlockType1系统信息块类型1 Paging寻呼Extended service request扩展服务请求rrcConnectionRequest RRC连接请求rrcConnectionSetup RRC连接建立rrcConnectionSetupComplete RRC连接建立完成rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成securityModeCommand安全模式命令rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成(含鉴权信令流程)systemInformationBlockType1系统信息块类型1 Paging寻呼Extended service request扩展服务请求rrcConnectionRequest RRC连接请求rrcConnectionSetup RRC连接建立rrcConnectionSetupComplete RRC连接建立完成rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成dlInformationTransfer DL信息传输Security protected NAS message安全保护的NAS消息Authentication request认证请求Authentication response验证响应ulInformationTransfer UL信息传输dlInformationTransfer DL信息传输Security protected NAS message安全保护的NAS消息Security mode command安全模式命令Security mode complete安全模式完成ulInformationTransfer UL信息传输securityModeCommand安全模式命令rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成rrcConnectionReconfiguration rrc连接重配置rrcConnectionReconfigurationComplete rrc连接重配置完成。
竭诚为您提供优质文档/双击可除lte,寻呼协议篇一:td-lte系统的寻呼机制与容量td-lte系统的寻呼机制与容量寻呼是移动通信的关键过程,对于空闲状态(RRc-idle)的终端,系统使用寻呼类型1消息(pagingtype1)通过公共信道寻呼ue;对于连接状态下(RRc-connected)的终端,系统使用寻呼类型2消息(pagingtype2)直接在业务信道上通知ue。
一、寻呼消息lte系统中的寻呼消息中可以携带三类参数:寻呼的终端id列表、系统消息改变指示标识及地震海啸预警指示标识(etws)。
pagingmessagepaging::=sequence{ pagingRecordlistpagingRecordlistoptional,--needonsysteminfomodificationenumeRated{true}optional,--ne edonetws-indicationenumeRated{true}optional,--needon noncriticalextensionpaging-v890-iesoptional}paging-v890-ies::=sequence{latenoncriticalextensionoctetstRingoptional,--needo pnoncriticalextensionpaging-v920-iesoptional}paging-v920-ies::=sequence{cmas-indication-r9enumeRated{true}optional,--needon noncriticalextensionsequence{}optional--needop }pagingRecordlist::=sequence(size(1..maxpageRec))oFp agingRecordpagingRecord::=sequence{ue-identitypagingue-identity,cn-domainenumeRated{ps,cs},...}pagingue-identity::=choice{s-tmsis-tmsi,imsiimsi,...}1.寻呼的终端id列表根据lte规范,寻呼消息最多可以携带16个ue_id。
【关键字】总结1.系统消息定义系统消息system information是指这样的一些信息:他表示的是当前小区或网络的一些特性及用户的一些公共特征,与特定用户无关。
通过接受系统的系统信息,移动用户可以得到当前网络,小区的一些基本特征,系统可以在小区中通过特定的系统广播,可以标识出小区的覆盖范围,给出特定的信道信息。
2.系统消息的类型系统消息可以分为3种类型,如下1.主信息快(MIB),由众多IE组成,包含一定能够数量的最基本信息且被传输最多次数的信息2.系统信息块(SIB1),由众多IE组成,包含评估一个UE是否被允许接入到一个小区的相关信息,并定义了其他SI的相关调度信息3.系统信息(SI),有众多IE组成,用于传送一个或多个SIB信元(SIB2——SIB8)3.系统消息的映射调度系统消息的调度4.系统消息的获得1.触发系统消息获得的原因UE应该在下列情况下应用系统消息的获得过程:➢在开机选择小区的时候,或在从另一种RAT进入E—UTRA之后,进行小区的选择或重选。
➢从丢失覆盖后恢复➢收到一个更新通知,系统消息已经改变➢超过最大有效时间(6小时)5.系统消息内容1.MIB(master information block)↓↓MIB(MasterInformationBlock)RRC-MSG..msg0> 07 00000111 T....struBCCH-BCH-Message//BCH传输消息......struBCCH-BCH-Message........message1> A8 101-----..........dl-Bandwidth:n100 (5):系统带宽(100RB,20MHz)..........phich-Config:PHICH配置信息---0----............phich-Duration:normal (0)----10--............phich-Resource:one (2) :对应PHICH的参数Ng, ={1/6, 1/2, 1, 2} 0]!@7v,`&g$q"^/^------002> E0 111000--..........systemFrameNumber:00111000(38):系统帧号------003> 00 00000000 ..........spare:0000000000(00 00)1.SIB1↓↓SIB1(SystemInformationBlock1)RRC-MSG..msg0> 06 00000110 T....struBCCH-DL-SCH-Message//SCH共享信道消息......struBCCH-DL-SCH-Message........message1> 50 0------- *..........c1-1------ *............systemInformationBlockType1--010--- *..............cellAccessRelatedInfo:小区接入相关信息-----0-- *................plmn-IdentityList------002> 51 0------- *..................PLMN-IdentityInfo....................plmn-Identity-1------ *......................mcc:460--0100--........................MCC-MNC-Digit:0x4 (4)------013> 80 10------........................MCC-MNC-Digit:0x6 (6)--0000--........................MCC-MNC-Digit:0x0 (0)......................mnc:00------0- *-------04> 01 000-----........................MCC-MNC-Digit:0x0 (0)---0000-........................MCC-MNC-Digit:0x0 (0)-------1 ....................cellReservedForOperatorUse:notReserved (1):小区非驻留5> 806> 0C 00001100 ................trackingAreaCode:0(80 0C):TAC7> 818> 61 011000019> 23 0010001110> D8 1101----...........cellIdentity:11101(08 16 12 3D):CI----1---................cellBarred:notBarred (1):小区未被禁止-----0--................intraFreqReselection:allowed (0):同频重选允许------0-................csg-Indication:FALSE..............cellSelectionInfo:小区选择信息-------0 *11> 1A 000110--................q-RxLevMin:-0x40 (-64):最小电平?------1012> 70 0111----..............freqBandIndicator:0x28 (40):使用频段//TDD频段号:36~42..............schedulingInfoList:指示SIB2~13的目录信息----000013> 10 0------- *................SchedulingInfo-001----..................si-Periodicity:rf16 (1)..................sib-MappingInfo:sib映射信息----000014> 81 1------- *-00000--....................SIB-Type:sibType3 (0):SIB3..............tdd-Config------0115> 3E 0-------................subframeAssignment:sa2 (2):子帧配置类型SA2-0111---................specialSubframePatterns:ssp7 (7):特殊子帧配置类型SSP7-----110 ..............si-WindowLength:ms40 (6)16> 30 00110---..............systemInfoValueTag:0x6 (6)-----000 *!! Can not explain:17> 00 0000000018> 00 0000000019> 00 000000002.SIB2IE SystemInformationBlockType2 包括公共信道和共享信道的信息。
1名称:LTE 寻呼黑洞小区分析提交人:万付增提交日期:2014-08-18软件版本: V3 20 00 45 硬件版本:ENODEB 5116********************************************************************************************************************故障现象:近期德州区域CSFB 寻呼成功率较低,针对这个问题,进行了分析。
可能原因:寻呼黑洞小区分析思路GSM-MSC 部分GSM 的MSC 侧的两个counters ,分别为SGsAP-Paging-request (步骤1)和SGsAP-service-request (步骤4)对应到LTE 部分涉及到两个网元,MME 和eNodeB ;MME 部分(NOKIA DO 信令分析数据(20140804-0810-19点)) 从NOKIA 拿到的MME 侧统计能看到cs 域寻呼丢弃数以及LAC 寻呼数;MME侧统计寻呼超时,据反映NOKIA网络设定T3413为9s;针对寻呼成功率低问题,需要从如下方面进行分析:1一方面主要从LTE侧分析。
2、另一方面主要从2G侧分析。
影响寻呼建立成功率的因素主要有:1)弱覆盖,被叫未收到寻呼消息,终端无响应。
2)未配置最佳2G邻区,导致起呼过程中频繁发起小区更新重选。
3)TAC、LAC区域规划不合理,导致起呼过程中发起位置更新。
4)干扰问题。
5)2G拥塞。
6)设备告警等。
问题分析:下表为8月9日与8月10日寻呼黑洞小区数对比:下图为8月9日与8月10日寻呼黑洞小区数对比:38月9日与8月10日相比,大唐区域的寻呼黑洞小区数基本没有差异。
下图为8月9日与8月10日寻呼超时数对比:从上图9号和10号的数据对比中可以看出,大唐的寻呼丢弃数下降了近600次。
从以下几个原因进行分析:1、TAC 、LAC 区域规划不合理,导致起呼过程中发起位置更新。
eNB上,寻呼相关的参数有两个,作为广播消息在SIB2中传递给UE:其中defaultPagingCycle即T,决定DRX周期即寻呼周期,单位为rf(无限帧,10ms),取值范围是32、64、128和256。
值越大,RRC_IDLE状态下UE的电力消耗越少,但是相应的,寻呼消息的平均延迟越大,接通的时延也越大。
nB表征寻呼密度,取值范围是4T、2T、T、T/2、T/4、T/8、T/16、T/32,图中oneT表示每个无线帧有1个子帧用于寻呼,如果设置为T/32则表示每32个无线帧有1个子帧用于寻呼,该值决定了LTE系统的寻呼容量。
nB的取值表征寻呼组的数量,如T取值128,nB取值T,则相当于将所有的用户分为128个寻呼组,如果T取值64,nB取值T/4,则分为16个寻呼组,寻呼组越多,每个组中用户数量越少。
LTE寻呼在物理信道PDSCH信道传输,每个寻呼信道最多可以寻呼16个用户,根据nB 的取值,可以计算出小区的寻呼容量:由于移动通信寻呼的突发性,一般要求网络的寻呼负荷不超过50%的寻呼容量,因此,在进行网络规划、参数规划的时候,需要考虑综合TAC、用户分布等因素,规划寻呼参数:一般情况下,LTE小区寻呼参数建议设置:–T=64或者128,nB=T此时,寻呼周期640/1280ms,寻呼容量:1600次/秒特殊场景(如大型活动、比赛现场),需要对某些小区的寻呼参数进行优化调整,可以采用的方案如下:–nB:增大nB,提高小区寻呼容量,减少寻呼拥塞,如nB→2T/4T–T:T值越大,寻呼时延越长,寻呼组增加,每个寻呼信道中的用户越少,反之寻呼时延缩短,每个寻呼信道用户增加,可能导致某个时刻一个寻呼组寻呼的用户超过16个,反而增加的寻呼时延,因此,可以根据实际用户的数量,调整T值。
像其他GSM、WCDMA系统一样,LTE系统在空闲态UE使用DRX(不连续接收-睡眠、唤醒机制)功能减少功率消耗,增加电池寿命。
为了达到这一目的,UE从SIB2中获取DRX相关信息,然后根据DRX周期UE监测PDCCH信道,查看是否有寻呼消息,如果PDCCH信道指示有寻呼消息,那么UE解调PCH信道去看寻呼消息是否属于自己。
在这个过程,UE如何根据DRX周期确认在哪一无线帧、哪一子帧去监测PDCCH 信道?寻呼时刻(PO)如何获取呢?寻呼的通知由 PDCCH DCI 格式 1C 通知 UE PDCCH的通知上携带P-RNTI,表示这是寻呼消息。
具体的被寻呼的UE ID承载在PCH上的寻呼消息中,PCH映射到PDSCH 信道上,UE ID是IMSI或者是MME分配的S-TMSI。
为了降低RRC_IDLE 状态下UE的电力消耗,UE使用非连续接收方式接收寻呼消息RRC_IDLE状态下的UE在特定的子帧监听PDCCH这些特定的子帧称为寻呼时机PO。
这些子帧所在的无线帧称为寻呼帧PF。
与PF 和PO 相关的两个参数是T和nB 这两个参数由系统消息SIB2通知UE。
PF的确定: SFN mod T= (T divN)*(UE_ID mod N) (1)PO的确定: i_s = floor(UE_ID/N) modNs (2)根据公式1和2计算出PF 和PO 的具体位置后,UE开始监听相应子帧的PDCCH 如果发现有 P-RNTI则根据PDCCH指示的RB分配和调制编码方式从同一子帧的PDSCH上获取寻呼消息。
如果寻呼消息含有本UE 的ID则发起寻呼响应,否则在间隔T 个无线帧后继续监听相应子帧的PDCCH。
T:UE的非连续接收周期T=min(Tc,Tue),其中Tc,Tue 分别表示核心网和无线侧设置的寻呼周期,一般情况无线侧的寻呼周期小于核心网周期,默认等于无线侧寻呼周期DefaultPagingCycle,该参数从SIB2中读取。