LTE

http://www.tutorialspoint.com/lte/lte_layers_data_flow.htm:详细介绍了数据流在LTE各层中的流向以及pdu、sdu的解释等。


异频或异系统重选小区

对于异系统或者异频点的小区之间的重选

在sib5里面

InterFreqCarrierFreqList

{

 dl-CarrierFreq 38250 //邻小区的频点

 q-RxLevMin -64 //用来计算邻小区Squal

 threshX-High 11,//如果邻小区的优先级高于服务小区且目标小区是utran或lte,则当邻小区的Squal> threshX-High 且目标小区的 Srxlev> threshX-High 时会重选到这个小区

 threshX-Low 11,//如果邻小区的优先级低于服务小区且目标小区是utran或lte,则当邻小区的Squal> threshX-Low 且服务小区的Squal<threshServingLow 时会重选到这个小区

}

threshServingLow这个值在sib3里面广播

cellReselectionServingFreqInfo

{

 threshServingLow 3  //当服务小区的Squal<threshServingLow时可能会有重选

 cellReselectionPriority 7 //服务小区重选时的优先级

 s-NonIntraSearch 5 //当邻小区优先级低于或等于服务小区且是异频之间时,如果服务小区的Srxlev> s-NonIntraSearch时是不会执行小区重选测量的。如果没有广播这个值,也会执行性测量

}

如果邻小区优先级高于服务小区,则一定会执行小区重选测量。


同频重选

Sib3里有一个

s-IntraSearch-v920

{

s-IntraSearchP-r9 30        //相当于文档中提到的SIntraSearchP

 s-IntraSearchQ-r9 8   //相当于文档中提到的SIntraSearchQ

}

当服务小区的 Srxlev>SIntraSearchP 并且Squal>SIntraSearchQ时是不会执行同频之间的测量的


RLC

UM的发送实例做的事情有:

对从协议栈上层传入RLC的SDU 进行分段、级联,同时增加RLC头

RLC的头部包括sequence number and length indicators (LI)


UM的接收实例要做的事情有:

根据SN(sequence number)重新排序收到的PDU

去除RLC的头部信息之后,将RLC的pdu的data 部分 重新收集到一起,之后再去除分段和解开级联信息,然后传给PDCP


对于AM模式接收和发送则相对于UM模式0增加了一些功能

发送里面:

发送出去的PDUs要放在retransmission buffer ,目的是为了出错时能重发

当一个ACK收到了时,就清除retransmission buffer 里面相应的段信息,如果收到了NAK,则重发丢失的PDUs

并且,AM模式里面对要重新发送的PDUs是可以重新分段成独立的PDU之后再发出去的,只是他们有相同的SN


接收里面:

当发送端请求查询peer的包接收情况 (RLC 的PDU里有一种PDU是属于控制PDU,用来查询接收端的接收情况)

或者 接收端明显检测到丢包了时会触发接收端发送状态报告, 告诉对方哪些包收到了,哪些丢失了。Status PDU is sent by receiving AM entity to acknowledge PDUs received and to indicate missing PDUs or missing PDU segments


pdcp

pdcp分为 data pdu 和 controll pdu

而data pdu又可以按照里面数据性质的不同分为 srb pdu 和 drb pdu,前者承载信令消息,后者承载用户面数据信息  

   srb pdu里面会有完整性保护,数据部分后边要附加一个32bit的MAC-I

controll pdu包括PDCP status report,解释如下

PDCP status report is sent after PDCP is reestablished (only for RLC AM u-plane bearers). And can be sent in both directions

切换或者rrc重建都可能会引起PDCP Reordering  when packets are received out of order


mac

mac header的size和内容根据逻辑信道的类型来定,头部里的一些参数解释如下

TCTF:逻辑信道类型,只有当逻辑信道映射到FACH和RACH时才有

C/T:当多个逻辑信道复用到一个专用逻辑信道时,这个作为逻辑信道的标识

对于LTE传输信道简单多了,上行只有RACH 和UL-SCH,下行有PCH,BCH,DL-SCH具体逻辑信道到传输信道地映射可以参考

http://blog.sina.com.cn/s/blog_5eba1ad10100gw03.html



Why No Service is shown during DDS change on a particular SIM?

In DSDS design only one subscription can act as designated data subscription (DDS) which will register for PS services.
Data call must be originated on DDS subscription, DDS change can be done from DSDS menu on UI.

When changing the DDS from one subscription to another PS detach is performed on the previous subscription.PS attach is performed on next subscription.

In a scenario where DDS is changed from SIM1 to SIM2.If SIM1 is registered with CS+PS services and SIM2 with CS service.

During the DDS change from SIM1 to SIM2,PS detach will perform on SIM1 and do the PS attach on SIM2.SIM1 will show NO service temporarily till attach accept on SIM2.

The SIM1 is OOS due to active connection on the other SUB, which is DSDS limitation due to single radio.

dsds and dsda feature can refer 80-NJ044-1_A_DSDS_DSDA_Use_Case


信道化码和扰码的区别:
下行:下行链路中通常使用8192个扰码,序号分别为0-8191,这些扰码分成512个小组,每个小组包含一个PSC和15个SSC。主扰码序号为16×k(k=0,1,2......511)。下行链路的512个主扰码可以进一步分为64个扰码组,每个组8个主扰码。在下行,基站发送信息时,先将用户数据与各自的CH(信道化码)相乘也称为扩频,然后加扰,之后发给UE。所以CH起到一个扩频的作用,经过扩频后的速率变为3.84Mbps/s,同时用来标识物理信道ID。通过CH的正交性来区分不同用户的信息。注意加扰不会继续增大速率。
上行:不同用户如果服务相同,可以采用相同的CH,通过不同的扰码来区分。在上行方向CH只是简单的用来扩频
详细的解释可以参考http://www.doc88.com/p-048673463501.html

上行链路,分配专用信道的时候,UTRAN会通知UE使用哪一个上行链路的扰码,每个UE分配且只分配一个扰码,从而达到区分用户的作用。


LTE的帧结构以及概念:

TD-LTE中,每帧时长为10ms,分成10个子帧,每个子帧由两个时隙为0.5ms的半帧组成。这0.5ms又分为7个时间片,所以一帧有20个时隙.

参考图可以从下面网址查看:http://www.tutorialspoint.com/lte/lte_ofdm_technology.htm

资源块RB: 它是一个12×7的矩形,其中12行是带宽为15kHz的12个子载波。在这个资源块中,每列就称为一个OFDM符号,共有7列,所以一个资源块一般可容纳7OFDM符号,至于单元格一般称为资源粒子(Resource element)。

符号,Symbol。是调制后的符号,代表1~N个比特(1、2、3、6对应BPSK、QPSK、16QAM、64QAM的调制方式),映射到1个RE上传送;可以认为符号在时间上是1个OFDM 符号,频率上是1个子载波15KHz。
OFDM Symbol。时间上是0.5/7 ms(约为71us),频率上是整个带宽BW。

一个资源块的长度为一个时隙地长度,频域的宽度为12个子载波。

一个资源粒子时域的长度为一个符号的时间长度,频域地宽度为一个15kb的子载波宽度。

TTI:时间为1ms占用连续的两个时隙。

SFN: system frame number

subframe number: 和上面地SFN是不同的,一帧分为10个子帧

RSRP(Reference Signal ReceivingPower):是在某个Symbol内承载Reference Signal的所有RE上接收到的信号功率的平均值;

RSSI(Received Signal StrengthIndicator): 则是在这个Symbol内接收到的所有信号(包括导频信号和数据信号,邻区干扰信号,噪音信号等)功率的平均值

RSRQ(Reference Signal ReceivingQuality): 则是RSRP和RSSI的比值,当然因为两者测量所基于的带宽可能不同,会用一个系数来调整,也就是 RSRQ =N*RSRP/RSSI.

DCI:Downlink Control Information即下行控制信息。在PDCCH上传输。DCI的格式由transmission mode 和RNTI type决定。PDCCH的CRC会用不同的RNTI来绕码。不同的逻辑信道承载不同的信息类型,同样对应着不同的RNTI TYPE。比如

系统消息:SI-RNTI

寻呼消息:P-RNTI

随机接入回复:RA-RNTI

CSIChannel State Information):UE上报给eNodeB的信道状态信息,由CQIChannelQuality Indicator)、PMIPrecodingMatrix Indicator)、PTIPrecodingType Indicator)和RIRandIndication)组成,其所占的时频资源是由eNodeB来控制的。


LTE速率计算方法。转载于http://www.mscbsc.com/10008813/viewspace-29990.html

   在LTE的帧结构中,都有资源块的概念。一个资源块的带宽为180kHz,由12个带宽为15kHz的子载波组成,在时域上为一个时隙(0.5ms),所以1个RB在时频上实际上是1个0.5ms,带宽180kHz的载波。同时LTE的传输时间间隔(TTI)为1ms。

   有两种循环前缀,一种是一般循环前缀(Normal CP),一个时隙里可以传7个OFDM;另一种是扩展循环前缀(Extended CP),一个时隙里可以传6个OFDM。MSCBSC 移动通信论坛,Q:A)@.q8?+E!o
Extended CP可以更好的抑制多径延迟造成的符号间干扰、载频间干扰,但是它一个时隙只能传6个OFDM,和Normal CP相比代价是更低的系统容量,在LTE中默认使用Normal CP。

一个OFDM符号的数据承载能力就取决于调制方式,分别为2/4/6个bit(对应QPSK,16QAM,64QAM)。

LTE在20MHz带宽下RB数为100个,在1.4MHz带宽时为6个,1.4MHz定义为最小频宽是因为PBCH,PSCH,SSCH最少都要占用6个RB。

在20MHz带宽的情况下,可以有的RB数目=20MHz/180KHz=111个,要除去冗余可用的RB数也就是100个。


LTE 20M带宽下可以达到的速率也有可能超过100Mb/s 的由来如下:

一个时隙(0.5ms)内传输7个OFDM符号,即在1ms内传输14个OFDM符号,一个资源块(RB)有12个子载波(即每个OFDM在频域上也就是15KHZ),所以1ms内(二个RB)的OFDM个数(我的理解是RE的个数)为=14*12=168个, 它下行采用OFDM技术,且采用64QAM调制方式,则每个OFDM(RE)包含6个bits,则20M带宽时下行速率为:mscbsc 移动通信论坛拥有30万通信专业人员,超过50万份GSM/3G等通信技术资料,是国内领先专注于通信技术和通信人生活的社区。.F,d,H.O/]*f
<符号的bits数>*<1ms(2个RB)中的OFDM数>*<20M带宽的RB个数>*<1000ms/s>=6*168*100*1000=100800000Bits/s=100Mbwww.mscbsc.com*o&R6w8Y#^.S)g
因为我们前面说了,20MHz带宽理论值可以有111个RB的,所以LTE 20M带宽下可以达到的速率也有可能超过100Mb。(摘自leeje的回答)

LTE的时间单元Ts=1/(15000*2048)秒,(15kHz的子载波带宽,2048个子载波,总带宽为15000*2048=30720000Hz)


LTE频点的计算公式如下:

中移动指定TD-LTE工作频段:
工作频段        频段值                要求
Band 40        2300-2400MHz        必选
Band 38        2570-2620MHz        必选

工作频段        F_low        N_Offs        N_Earfcn
Band 40        2300               38650          38650~39649
Band 38        2570               37750                37750~38249
TD-LTE的频点编号从36000开始,F_c代表载波中心频率(MHz),F_low代表频带内的起始频率,N_Offs代表上频带内的起始频点号码。N_Earfcn:频点编号
F_c=F_low + 0.1*(N_Earfcn – N_Offs)
例:假如某小区freq_info: 38700 则对应的F_c=2300 +0.1*(38700-38650)=2305MHz,然后通过MIB获取小区bandwidth.


随机接入相关的知识:

 在LTE系统中,UE与网络必须处于同步(上行/下行)状态才能进行通信。UE与网络间的下行同步是在小区选择过程中UE通过接收该小区的参考信号获得的,上行同步需要通过成功的随机接入过程才能获得,这样才能为上行数据传输分配资源。

随机接入过程开始前,物理层需要接收到高层(MAC或者RRC)的控制以及数据信息,譬如当前可用的前导码格式,选择接入的时隙资源,随机接入响应的窗口大小,发射前导的功率步长,发送前导的最大次数,发送前导的初始功率等

在基于竞争的随机接入过程中,需要能够完成物理层的上行同步过程。和基于非竞争随机接入的本质区别在于发起随机接入前UE是否收到来自网络分配的专用随机接入资源

基于竞争的随机接入:

  (1) 上行链路在RACH资源上发送随机接入前导;一个子帧里面可以有多个PRACH,具体选择哪个通过PRACH_Config 和PRACH resource index,和ra-PRACH-MaskIndex来配置,PRACH resource index :指示在哪一个子帧上发送,ra-PRACH-MaskIndex:指示在特定子帧的哪一个PRACH index上发送。

  (2) MAC层产生随机接入响应在DL-SCH和PDCCH上传输;其中PDCCH上会传送一个RA-RNTI,当然不是显式的传输,而是编码在DCI里面,其作用是eNB检测Preamble的时频位置,对应到PRACH_Config中的索引,由于随机接入请求是UE发出的,所以UE是知道这个值的,UE会解码PDCCH上地RA-RNTI来匹配是不是发给自己的。找到之后,则说明接入被响应,再依据PDCCH上的指示去PDSCH上读取RA Response消息(MSG2)。MSG2里会包含一个T-RNTI用来标识ue

 (3) 在UL-SCH上传输MSG3,这个里面包含了一个UE生成地特定ID,用来竞争解决,RRCConnectionrequest包含在这个竞争解决消息里;

 (4) 下行竞争解决MSG4,如果ENb同意ue的接入,则发送回MSG3里的ID。同时有可能分配一个C-RNTI来标识用户,如果没有分配的话,UE会将之前的T-RNTI升级为C-RNTI。如果是在RRC_CONNECTED状态,C-RNTI已经分配给UE了,所以在RRC连接请求里要包含C-RNTI。

基于非竞争的随机接入,它包括三个步骤:

  (1) 通过专有的下行信令通知随机接入前导的分配;(2) 上行链路中在PRACH上发送随机接接前导;(3)基站 在DL-SCH上传输随机接入响应。

http://wenku.baidu.com/link?url=Bk9zwH2mlN6LNecBxiLX8PYan2J2-d-V8emUGCpVup0uZQQjV49cMK53m1rGdyPJH9QV0LKY3xfi5ij5GubkwjQVSUd50QEbAFiKLzFtfmC :很详细



HARQ相关地知识

NDI,指的是DCI中的NDI(New Data Indication),在PDCCH中传输。因为LTE采用了HARQ技术,可以对上次传输失败的数据包进行重传。
那么UE如何知道本次传输的包是重传数据包还是首传数据包呢?所以要进行NDI指示,其是一个bit,一个bit位的翻转如由0变为1表示这是一个新的传输块。
NDI toggled就是翻转的意思。

上行HARQ,即上行传输用户数据,下行反馈结果,下面转自:http://blog.sina.com.cn/s/blog_927cff010101c01a.html
在上行传输过程中,如果有在PDCCH中有UL grant,则NDI有翻转时,表示UE下一个包可以传输新的包,而不管PHICH上的ACK/NACK
在LTE中,eNodeB使用PHICH来告诉UE是否成功接收PUSCH,一个上行TB对应一个PHICH。上行支持2中传输模式:TM 1(只支持单天线传输)和 TM2(支持空分复用)。
如果使用TM2,则每个子帧有2个HARQ process,即每个子帧里有两个PHICH。上行使用同步HARQ,但重传可以是自适应的,也可以是非自适应的。
1.上行HARQ使用同步(synchronous)、非自适应(non-adaptive):
 由于上行重传总是发生在可预知的子帧上,所以根据timing关系可以直接推导出使用的HARQ process。并且在非自适应重传时,重传与与前一次传输使用相同的PRB资源和
MCS。因此下行只需要PHICH这一种控制信令,而不需要PDCCH(UL grant),从而降低了开销。
2.上行自适应(adaptive)重传
  此时eNodeB不仅会发送PHICH,还会发送PDCCH(UL grant)以指示重传所使用的新的PRB资源和MCS。
  如果上行同时支持自适应和非自适应HARQ,则要求对应同一上行子帧的PHICH和PDCCH拥有相同的timing,即在同一子帧中发送。如果不满足该条件,则UE不知道是该听从
  PHICH还是该等待UL grant而不管PHICH,实现的复杂度会大增。

下行

接收方可以从物理层收到发送方传递过来地HARQ信息,里面可能就包括了NDI参数。

同步HARQ是指一个HARQ进程的传输(重传)是发生在固定的时刻,由于接收端预先已知传输的发生时刻,因此不需要额外的信令开销来标示HARQ进程的序号

异步HARQ是指一个HARQ进程的传输可以发生在任何时刻,接收端预先不知道传输的发生时刻,因此HARQ进程的处理序号需要连同数据一起发送。

Downlink Assignment Index (DAI)字段,用于告诉UE在HARQ反馈窗口内有多少个子帧包含下行传输。用于下行HARQ,这个字段包含在DCI里面

下行传输所对应的HARQ上行反馈里,一个上行子帧里可能包含对应多个下行子帧的ack/nack信息,包含的下行子帧集合就是:HARQ反馈窗口.


一直以为rrc连接请求完成和attach request是分开传送的,其实不是

rrcConnectionSetupComplete会把pdnConnectivityRequest和attachrequest消息带上,并不仅仅是应答。且pdnConnectivityRequest是在attach request的container中包含的。这个PDN连接请求是用来建立默认承载的,所以不需要带上APN,网络会在随后的激活默认承载请求中告诉UE使用的APN是什么。只需要告诉网络UE支持的IP地址类型就行。

Esm information request 会请求UE把自己的信息传给网络,包括用来建数据业务的APN

ESM information response

lte_esm_msg

  esm_info_res

    acc_pt_name_incl = 1 (0x1)

    access_point_name

      num_acc_pt_val = 6 (0x6)

      acc_pt_name_val[0] = 5 (0x5) (length)

      acc_pt_name_val[1] = 51 (0x33) (3)

      acc_pt_name_val[2] = 103 (0x67) (g)

      acc_pt_name_val[3] = 110 (0x6e) (n)

      acc_pt_name_val[4] = 101 (0x65) (e)

      acc_pt_name_val[5] = 116 (0x74) (t)

    prot_config_incl = 1 (0x1)

    prot_config

      ext = 1 (0x1)

      conf_prot = 0 (0x0)

      num_recs = 3 (0x3)

      sm_prot[0]

       protocol_id = 49699 (0xc223) (CHAP)

        prot_len = 21 (0x15)

        chap_prot

          code = 1 (0x1)

          identifier = 0 (0x0)

          rfc1994_chap_challenge

            value_size = 16 (0x10)

            value[0] = 203 (0xcb)

            value[1] = 148 (0x94)

            value[2] = 85 (0x55)

            value[3] = 85 (0x55)

            value[4] = 203 (0xcb)

            value[5] = 148 (0x94)

            value[6] = 85 (0x55)

            value[7] = 85 (0x55)

            value[8] = 203 (0xcb)

            value[9] = 148 (0x94)

            value[10] = 85 (0x55)

            value[11] = 85 (0x55)

            value[12] = 203 (0xcb)

            value[13] = 148 (0x94)

            value[14] = 85 (0x55)

            value[15] = 85 (0x55)

            name_size = 0 (0x0)

      sm_prot[1]

        protocol_id = 49699 (0xc223) (CHAP)

        prot_len = 21 (0x15)

        chap_prot

          code = 2 (0x2)

          identifier = 0 (0x0)

          rfc1994_chap_resp

            value_size = 16 (0x10)

            value[0] = 72 (0x48)

            value[1] = 92 (0x5c)

            value[2] = 10 (0xa)

            value[3] = 216 (0xd8)

            value[4] = 252 (0xfc)

            value[5] = 147 (0x93)

            value[6] = 23 (0x17)

            value[7] = 42 (0x2a)

            value[8] = 96 (0x60)

            value[9] = 56 (0x38)

            value[10] = 94 (0x5e)

            value[11] = 92 (0x5c)

            value[12] = 172 (0xac)

            value[13] = 190 (0xbe)

            value[14] = 37 (0x25)

            value[15] = 230 (0xe6)

            name_size = 0 (0x0)

      sm_prot[2]

        protocol_id = 32801 (0x8021) (IPCP)

        prot_len = 16 (0x10)

        ipcp_prot

          ipcp_prot_id = 1 (0x1) (CONF_REQ)

          identifier = 0 (0x0)

          rfc1332_conf_req

            num_options = 2 (0x2)

            conf_options[0]

              type = 129 (0x81)

              rfc1877_primary_dns_server_add

                length = 6 (0x6)

                ip_addr = 0 (0x0) (0.0.0.0)

            conf_options[1]

              type = 131 (0x83)

              rfc1877_sec_dns_server_add

                length = 6 (0x6)

                ip_addr = 0 (0x0) (0.0.0.0)

      num_recs2 = 4 (0x4)

      sm_container[0]

        container_id = 13 (0xd) (DNS Server IPv4 Address Requestt)

        container_len = 0 (0x0)

      sm_container[1]

        container_id = 10 (0xa) (IP address allocation via NAS signalling)

        container_len = 0 (0x0)

      sm_container[2]

        container_id = 5 (0x5) (NWK Req Bearer Control indicator)

        container_len = 0 (0x0)

      sm_container[3]

        container_id = 16 (0x10) (Ipv4 Link MTU Request)

        container_len = 0 (0x0)

在建立LTE数据连接(非IMS)时,在附着请求消息里会有PDN连接请求,但是这个请求里不包含APN信息;

之后网络会下发esm information request 要求手机把apn报上去

手机接到请求后发esm information response 告诉网络APN(代表要和哪个PDN来建立连接)

网络下发activate default eps bearer context requst (这个消息里包含之前发给网络的APN)来激活默认承载,且会告诉UE网络分配给UE的QCI(LTE数据默认承载使用的QCI=8,IMS对应的默认承载使用的QCI=5),UE收到这个消息后会和自己配置的APN进行比对,如果相同就发attach accept(这个消息里会包含activate default eps bearer context accept)。


LTE 中的Data Centric 和 Voice Centric含义

http://cache.baiducontent.com/c?m=9d78d513d9981eee4fece4690d60c0676910dd217dc3975521dbc90ed5264c40347bfeeb797f4513d3b23d3c5dfc5e5c9da16b2d200357e6c7d5c9578de5cf7d388f53317618d64510d51dadc84426947f9051feaf6ebdfcaf6c&p=936ddf16d9c104ff57ee947f500d8d&newp=8d769a479c9b13ff57ee947f55648f231610db2151d4d4156b82c825d7331b001c3bbfb423231a01d2c47c6604a54358ebf13777310621a3dda5c91d9fb4c57479c27f66&user=baidu&fm=sc&query=IMS-VOPS&qid=d00025b00001cbe8&p1=1


如果开机时数据业务没打开且RRC连接没建立,则在手动打开数据开关的额时候会给网络发service request,但是这个消息里不用再带APN了。QIE

如果RRC没有释放,则只需要进行RRC 连接重配置就行。


SIB的逻辑信道是BCCH, 传输信道是通过DL-SCH传的


  • 1
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

yiqingyang2012

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值