在td-scdma系统中,寻呼过程主要使用以下哪些物理信道

在td-scdma系统中,寻呼过程主要使用以下哪些物理信道,第1张

逻辑信道是MAC子层向上层提供的服务,表示承载的内容是什么(what),,按信息内容划分,分为两大类:控制信道和业务信道。 传输信道表示承载的内容怎么传,以什么格式传,分为两大类:专用传输信道和公用传输信道. LONG TERM物理层协议根据传的内容和占用资源方式(频率和时间等)的不同定义了不同的物理信道,即按照将传输信道的不同的数据流按不同处理方式进行相关处理和数据的传输。其实信道、链路等等都是人为的概念,是对一系列数据流或调制后的信号的分类名称,其名称是以信号的功用来确定的。逻辑信道定义传送信息的类型,这些信息可能是独立成块的数据流,也可能是夹杂在一起但是有确定起始位的数据流,这些数据流是包括所有用户的数据。传输信道是在对逻辑信道信息进行特定处理后再加上传输格式等指示信息后的数据流,这些数据流仍然包括所有用户的数据。物理信道则是将属于不同用户、不同功用的传输信道数据流分别按照相应的规则确定其载频、扰码、扩频码、开始结束时间等进行相关的 *** 作,并在最终调制为模拟射频信号发射出去;不同物理信道上的数据流分别属于不同的用户或者是不同的功用。链路则是特定的信源与特定的用户之间所有信息传送中的状态与内容的名称,比如说某用户与基站之间上行链路代表二者之间信息数据的内容以及经历的一起 *** 作过程。链路包括上行、下行等。简单来讲,逻辑信道={所有用户(包括基站,终端)的纯数据集合}传输信道={定义传输特征参数并进行特定处理后的所有用户的数据集合}物理信道={定义物理媒介中传送特征参数的各个用户的数据的总称}打个比方,某人写信给朋友,逻辑信道=信的内容传输信道=平信、挂号信、航空快件等等物理信道=写上地址,贴好邮票后的信件2 逻辑信道、传输信道和物理信道分别有哪些?8逻辑信道: MAC通过逻辑信道为上层提供数据传送服务。逻辑信道 通常可以分为两类:控制信道和业务信道。控制信道用于传输控制平面信息,而业务信道用于传输用户平面信息。其中,控制信道包括: 广播控制信道(BCCH):广播系统控制信息的下行链路信道。 寻呼控制信道(PCCH):传输寻呼信息的下行链路信道。 专用控制信道(DCCH):传输专用控制信息的点对点双向信道,该信道在UE有RRC连接时建立。 公共控制信道(CCCH):在RRC连接建立前在网络和UE之间发送控制信息的双向信道。(是双向吗?下行也这样使用?)(我个人认为是双向的见MAC层结构)多播控制信道MCCH: 从网络到UE的MBMS调度和控制信息传输使用点到多点下行信道。业务信道包括:  专用业务信道(DTCH):专用业务信道是为传输用户信息的,专用于一个UE的点对点信道。该信道在上行链路和下行链路都存在。 多播业务信道(MTCH):点到多点下行链路。传输信道:物理层通过传输信道为上层提供数据传送服务。物理层支持的传输信道:下行共享信道DL-SCH: 支持HARQ,AMC,可以广播,可以波束赋形,可以动态或半静态资源分配,支持DTX,支持MBMS(FFS)寻呼信道PCH: 支持DRX(UE省电),广播广播信道 BCH多播信道MCH: 广播,支持SFN合并,支持半静态资源分配(如分配长CP帧)控制格式指示CFIHARQ指示 HI下行控制信息 DCI上行共享信道UL-SCH: 支持HARQ,AMC,可以波束赋形(可能不需要标准化),可以动态或半静态资源分配随机接入信道RACH: 有限信息,存在竞争上行控制信息 UCI根据传的内容和占用资源方式(频率和时间等)的不同LONG TERM物理层协议定义了不同的物理信道。各物理信道传输的内容和调制方式各不相同。 下行物理信道有:PDSCH: 下行物理共享信道,承载下行数据传输和寻呼信息。PBCH: 物理广播信道,传递UE接入系统所必需的系统信息,如带宽天线数目、小区ID等PMCH: 物理多播信道,传递MBMS(单频网多播和广播)相关的数据PCFICH:物理控制格式指示信道,表示一个子帧中用于PDCCH的OFDM符号数目PHICH:物理HARQ指示信道, 用于NodB向UE 反馈和PUSCH相关的 ACK/NACK信息。PDCCH: 下行物理控制信道,用于指示和PUSCH,PDSCH相关的格式,资源分配,HARQ信息,位于子帧的前n个OFDM符号,n<=3.上行物理信道有:PUSCH:物理上行共享信道PRACH:物理随机接入信道,获取小区接入的必要信息进行时间同步和小区搜索等PUCCH :物理上行控制信道,UE用于发送ACK/NAK,CQI,SR,RI信息。3- 传输信道是如何映射到物理信道的?物理层有6个下行物理信道,3个上行物理信道。传输信道和物理信道的映射关系如下表:下行物理层信道与传输信道的映射关系如下表:传输信道物理信道下行共享信道 DL-SCH物理下行共享信道PDSCH寻呼信道PCH物理下行共享信道PDSCH广播信道 BCH物理广播信道PBCH多播信道MCH物理多播信道PMCH控制信息物理信道控制格式指示CFI物理控制格式指示信道PCFICHHARQ指示 HI物理HARQ指示信道 PHICH下行控制信息 DCI物理下行控制信息信道PDCCH上行物理信道有:PUSCH:物理上行共享信道PRACH:物理随机接入信道,获取小区接入的必要信息进行时间同步和小区搜索等PUCCH :物理上行控制信道,UE用于发送ACK/NACK,CQI,SR,RI信息。传信道信道/ 控制信息物理信道上行共享信道 UL-SCH物理上行共享信道 PUSCH随机接入信道 物理随机接入信道PRACH上行控制信息 UCIPUCCH、PUSCH

公共传输信道有六种类型: BCH, FACH, PCH, RACH, USCH, DSCH

广播信道(BCH)是一个下行传输信道,用于广播系统和小区的特有信息.

寻呼信道(PCH)是一个下行传输信道,用于当系统不知道移动台所在的小

区位置时,承载发向移动台的控制信息。

前向接入信道(FACH)是一个下行传输信道,用于当系统知道移动台所在的

小区位置时,承载发向移动台的控制信息。

FACH也可以承载一些短的用户信息数据包。

随机接入信道(RACH)是一个上行传输信道,用于承载来自移动台的控制

信息。RACH也可以承载一些短的用户信息数据包

专用信道(DCH) 是一个用于在UTRAN和UE之间承载的用户或控制信息

的上/下行传输信道。

Paging Type 1是在网络侧对处于空闲态UE下发的寻呼消息,Paging Type 2是网络侧对处于Cell DCH和Cell FACH状态下的UE下发的寻呼消息。

我在现场测试是遇到过几次这样的问题,就是主叫Call Proceeding之后,被叫恰好从GSM网络重选回TD网络,正在做位置更新,且已经lacation update accept complete,在RRC connection release之前,被叫收到网络侧寻呼,正是Paging Type 2,而UE收到寻呼消息之后,并没有Paging Response,而是直接RRC connection release了并转入空闲了,从而造成主叫未接通。此现象多发生在TD覆盖边缘区域,请问为什么UE明明已经收到寻呼消息了,但是不响应寻呼呢?

这种由于位置更新导致的未接通很常见也很多,以前我们这边每次拉网都会出现很多,后来做了RNC入POOL之后有明显减少,不过还是会有,只能减小出现几率但是无法完全消除,对于这种问题一般忽略不计吧?具体原因楼主可以跟坛子里查查,有类似的帖子,我也保存过一些,现在贴过来方便大家学习:

“mscpool 目前在解决位置更新造成的未接通方面优势在哪?求专家做答。谢谢先。

位置更新引起未接通问题成因:

a.位置更新前:

i.被叫:MS到了新的LA读取系统消息,还未发起并完成LAU,寻呼从原LA下发了。

ii.被叫:第一次寻呼采用TMSI,而手机做位置更新会重新分配TMSI,在此完成前TMSI寻呼无效。

iii.主叫:跨MSC后未完成位置更新,起呼时CM Service Reject(IMSI unknown in VLR)。b.位置更新中:

手机在做位置更新或在收(发)短信时,SDCCH被占用。用户处于专用模式下,无法监听PCH信道所以收不到寻呼消息造成寻呼失败。

c.位置更新后:

在寻呼的时候MS发生了跨局的位置区/路由区更新,而寻呼消息仍在原局的位置区/路由区下发,导致UE无法收到寻呼消息。原因是:对于MSC内位置更新造成的第1次寻呼失败,可以将第2次寻呼设为IMSI+Global寻呼(如果设为local的话,并不去VLR里面查MS所在LA,从原LA下发寻呼,将再次失败),则MSC内的位置更新和周期性位置更新都可以通过第2次寻呼寻呼到用户。而跨局的位置更新还是不能解决,因为第2次寻呼,是不会转交给新的MSC/VLR来执行的。

——如果启用MSC POOL,在网络下发第二次寻呼时,被叫手机已经位置区更新成功,MSC POOL更新了被叫手机的位置区信息,寻呼通过新位置区下发,被叫手机能够收到寻呼消息。

被叫做位置更新导致未接通

的根本原因是?

1说是位置更新占用了MS的SDCCH

2说是位置更新时,MS不属于前后任一一个LAC,无法有效寻呼

何解为真?

搜索到的论坛网优的提问回答:

位置更新过程中用户处于专用模式下,无法监听PCH信道所以收不到寻呼消息造成寻呼失败。其实对于位置更新造成的寻呼失败可以将第2次寻呼开成全局寻呼,这样的话局内的位置更新和周期性位置更新都可以通过二次寻呼寻呼到用户,效果不错。当然跨局的位置更新还是没招的。”


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/bake/11438623.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-16
下一篇 2023-05-16

发表评论

登录后才能评论

评论列表(0条)

保存