LTE学习之路(5)——物理层

帧结构

LTE支持的两种无线帧

类型1:应用于FDD

类型2:应用于TDD

FDD类型无线帧结构

 

FDD类型无线帧长为10ms,如上图所示。每帧分为10个相同大小的子帧,每个子帧又分为两个相同大小的时隙,即每个FDD无线帧帧含有20个相同大小的时隙,每个时隙为0.5ms。普通CP配置下,一个时隙包含7个连续的OFDM符号(Symbol)。

TDD类型无线帧结构

 

在TDD帧结构中,一个长度为10ms的无线帧由2个长度为5ms的半帧构成,每个半帧由5个长度为1ms的子帧构成,其中包括4个普通子帧和1个特殊子帧。普通子帧由两个0.5ms的时隙组成,而特殊子帧由3个特殊时隙(DwPTS、GP和UpPTS)组成。

注意

  • 子帧0和子帧5只能用于下行传输
  • 5ms切换周期配置时子帧1和子帧6用作特殊子帧
  • 10ms切换周期配置时子帧1用作特殊子帧
  • UpPTS之后的第一个常规子帧只能用于上行传输

作为TDD系统的一个特点,时间资源在上下行方向上进行分配,TDD帧结构支持7种不同的上下行时间比例分配(配置0~6),可以根据系统业务量的特性进行配置,支持非对称业务。这7种配置中包括4种5ms周期和3种10ms周期。

 

 “D”代表此子帧用于下行传输,“U”代表此子帧用于上行传输,“S”是由DwPTS、GP 和UpPTS组成的特殊子帧。  

  特殊子帧中DwPTS和UpPTS的长度是可配置的,满足DwPTS、GP和UpPTS总长度为1ms。

  对于5ms的上下行切换周期,子帧0、5、DwPTS一定走下行。对于10ms上下行切换周期,每个半帧都有DwPTS,只在第1个半帧内有GP和UpPTS,第2个半帧的DwPTS长度为1ms。UpPTS和子帧2用作上行,子帧7和9用作下行。

物理资源

 基本时间单位

 

注:基本时间单位的来源,请参考问题集锦(1)中的问题1的相关解释

 天线端口

  • LTE使用天线端口来区分空间上的资源。天线端口的定义是从接收机的角度来定义的,即如果接收机需要区分资源在空间上的差别,就需要定义多个天线端口。天线端口与实际的物理天线端口没有一一对应的关系。
  • 由于目前LTE上行仅支持单射频链路的传输,不需要区分空间上的资源,所以上行还没有引入天线端口的概念。
  • 目前LTE下行定义了三类天线端口,分别对应于天线端口序号0~5。

             小区专用参考信号传输天线端口:天线端口0~3

             MBSFN参考信号传输天线端口:天线端口4

             终端专用参考信号传输天线端口:天线端口5

 资源单元 (REResource Element)

     对于每一个天线端口,一个OFDM或者SC-FDMA符号上的一个子载波对应的一个单元叫做资源单元;

 资源粒子组 (REGResource Element Group)

     REG=4RE

 资源块 (RBResource Block)

     一个时隙中,频域上连续的宽度为180kHz的物理资源称为一个资源块;

     LTE系统最常见的调度单位,上下行业务信道都以RB为单位进行调度。RB = 84RE

 资源栅格 (Resource Grid)

     一个时隙中传输的信号所占用的所有资源单元构成一个资源栅格,它包含整数个PRB,也可以用包含的子载波个数和OFDM或者SC-FDMA符号个数来表示。

 信道

空中接口(Uu口)

空中接口是指终端与接入网之间的接口,简称Uu口,通常也称为无线接口。在LTE中,空中接口是终端UE和eNodeB之间的接口。

空中接口协议主要是用来建立、重配置和释放各种无线承载业务的。空中接口是一个完全开放的接口,只要遵守接口规范,不同制造商生产的设备就能够互相通信。

空中接口协议栈主要分为三层两面,三层是指物理层、数据链路层、网络层,两面是指控制平面和用户平面。从用户平面看,主要包括物理层、MAC层、RLC层、PDCP层;从控制平面看,除了以上几层外,还包括RRC层,NAS层。RRC协议实体位于UE和ENB网络实体内,主要负责对接入层的控制和管理。NAS控制协议位于UE和移动管理实体MME内,主要负责对非接入层的控制和管理。空中接口协议栈具体结构如下图所示。

                

               空中接口用户面协议栈结构                                                                        空中接口控制面协议栈结构

信道定义及其功能

信道可以认为是不同协议层之间的业务接入点(SAP),是下一层向它的上层提供的服务。

LTE沿用了UMTS里面的三种信道:逻辑信道传输信道物理信道

从协议栈的角度来看,物理信道是物理层的,传输信道是物理层和MAC层之间的,逻辑信道是MAC层和RLC层之间的。

  • 逻辑信道:传输什么内容,比如广播信道(BCCH),即用来传广播消息的;
  • 传输信道:怎样传,比如说下行共享信道DL-SCH,也就是业务甚至一些控制消息都是通过共享空中资源来传输的,它会指定MCS,空间复用等等方式,也就说是告诉物理层如何去传这些信息;
  • 物理信道:信号在空中传输的承载,比如PBCH,也就是在实际的物理位置上采用特地的调制编码方式来传输广播消息了。

物理信道

LTE定义的下行物理信道主要有如下6种类型:

(1) 物理下行共享信道(PDSCH):用于承载下行用户信息和高层信令。

(2) 物理广播信道(PBCH):用于承载主系统信息块信息,传输用于初始接入的参数。

(3) 物理多播信道(PMCH):用于承载多媒体/多播信息。

(4) 物理控制格式指示信道(PCFICH):用于承载该子帧上控制区域大小的信息。

(5) 物理下行控制信道(PDCCH):用于承载下行控制的信息,如上行调度指令、下行数据传输是指、公共控制信息等。

(6) 物理HARO指示信道(PHICH):用于承载对于终端上行数据的ACK/NACK反馈信息,和HARO机制有关。

LTE定义的上行物理信道主要有如下3种类型:

(1) 物理上行共享信道(PUSCH):用于承载上行用户信息和高层信令。

(2) 物理上行控制信道(PUCCH):用于承载上行控制信息。

(3) 物理随机接入信道(PRACH):用于承载随机接入前道序列的发送,基站通过对序列的检测以及后续的信令交流,建立起上行同步。

传输信道

物理层通过传输信道向MAC子层或更高层提供数据传输服务,传输信道特性由传输格式定义。传输信道描述了数据在无线接口上是如何进行传输的,以及所传输的数据特征。如数据如何被保护以防止传输错误,信道编码类型,CRC保护或者交织,数据包的大小等。

LTE定义的下行传输信道主要有如下4种类型:

(1) 广播信道(BCH):用于广播系统信息和小区的特定信息。使用固定的预定义格式,能够在整个小区覆盖区域内广播。

(2) 下行共享信道(DL-SCH):用于传输下行用户控制信息或业务数据。能够使用HARQ;能够通过各种调制模式,编码,发送功率来实现链路适应;能够在整个小区内发送;能够使用波束赋形;支持动态或半持续资源分配;支持终端非连续接收以达到节电目的;支持MBMS业务传输。

(3) 寻呼信道(PCH):当网络不知道UE所处小区位置时,用于发送给UE的控制信息。能够支持终端非连续接收以达到节电目的;能在整个小区覆盖区域发送;映射到用于业务或其他动态控制信道使用的物理资源上。

(4) 多播信道(MCH):用于MBMS用户控制信息的传输。能够在整个小区覆盖区域发送;对於单频点网络支持多小区的MBMS传输的合并;使用半持续资源分配。

LTE定义的上行传输信道主要有如下2种类型:

 (1) 上行共享信道(UL-SCH):用于传输下行用户控制信息或业务数据。能够使用波束赋形;有通过调整发射功率、编码和潜在的调制模式适应链路条件变化的能力;能够使用HARQ;动态或半持续资源分配。

 (2) 随机接入信道(RACH):能够承载有限的控制信息,例如在早期连接建立的时候或者RRC状态改变的时候。

逻辑信道

逻辑信道定义了传输的内容。MAC子层使用逻辑信道与高层进行通信。

逻辑信道通常分为两类:即用来传输控制平面信息的控制信道和用来传输用户平面信息的业务信道。而根据传输信息的类型又可划分为多种逻辑信道类型,并根据不同的数据类型,提供不同的传输服务。

LTE定义的控制信道主要有如下5种类型:

(1) 广播控制信道(BCCH):该信道属于下行信道,用于传输广播系统控制信息。

(2) 寻呼控制信道(PCCH):该信道属于下行信道,用于传输寻呼信息和改变通知消息的系统信息。当网络侧没有用户终端所在小区信息的时候,使用该信道寻呼终端。

(3) 公共控制信道(CCCH):该信道包括上行和下行,当终端和网络间没有RRC连接时,终端级别控制信息的传输使用该信道。

(4) 多播控制信道(MCCH):该信道为点到多点的下行信道,用于UE接收MBMS业务。

(5) 专用控制信道(DCCH):该信道为点到点的双向信道,用于传输终端侧和网络侧存在RRC连接时的专用控制信息。

LTE定义的业务信道主要有如下2种类型:

(1) 专用业务信道(DTCH):该信道可以为单向的也可以是双向的,针对单个用户提供点到点的业务传输。

(2) 多播业务信道(MTCH):该信道为点到多点的下行信道。用户只会使用该信道来接收MBMS业务。

信道映射关系

                                      上行方向                                                                             下行方向

            

 

                                                                                    传输信道与物理信道之间的映射关系

                                                          传输信道与逻辑信道之间的映射关系

基于OFDM的基本下行/上行传输机制

  • 下行传输机制是基于传统OFDM(采用循环前缀:Cyclic Prefix,CP)的;
  • 正常情况下的OFDM子载波间隔 ;
  • 一个时隙间隔内的12个连续子载波相当于一个下行RB(180kHz);
  • 在频域中,每个载波或小区中的RB个数 的范围可表示为: ;
  • 还有一种缩减的子载波间隔 ,这只适用于MBMS-dedicated cell;
  • 在子载波间隔 的情况下,CP的长度分为2种(常规/扩展),分别对应于每个时隙slot下的7个OFDM Symbols和6个OFDM Symbols;

正常CP:

扩展CP:

其中,

  • 在子载波间隔为 的情况下,CP的长度只有1种,即:,对应于每个时隙slot下的3个OFDM Symbols

                       

上下行正常CP配置( )下时隙结构如下:

上下行扩展CP配置( )下时隙结构如下:

下行扩展CP配置( )下时隙结构如下:

 

1 RRC协议功能

  • 为NAS层提供连接管理,消息传递等服务;
  • 对接入网的底层协议实体提供参数配置的功能;
  • 负责UE移动性管理相关的测量、控制等功能

2 RRC状态

  • RRC_IDLE

           PLMN选择;

           NAS配置的DRX过程;

           系统信息广播和寻呼;

           邻小区测量;

           小区重选的移动性;

           UE获取一个TA区内的唯一标识;

           eNB内无终端上下文

  • RRC_CONNECTION

           网络侧有UE的上下文信息;

           网络侧知道UE所处小区;  

           网络和终端可以传输数据;

           网络控制终端的移动性;

           邻小区测量;

           存在RRC连接:

                UE可以从网络侧收发数据,监听共享信道上指示控制授权的控制信令;

                UE可以上报信道质量给网络侧;

                UE可以根据网络配置进行DRX

3 RRC协议承载——SRB(signaling radio bearers—信令无线承载)

4 RRC连接建立过程

  • 触发原因

          处于IDLE状态下的UE需转变为连接状态时发起该过程,如:呼叫、响应寻呼、TAU、Attach等

  • RRC连接建立成功流程

Step1:RRC连接请求:UE通过UL_CCCH在SRB0上发起,携带UE的初始(NAS)标识和建立原因等,该消息对应于随机接入过的Msg3;

Step2:RRC连接建立:eNB通过DL_CCCH在SRB0上发送,携带SRB1的完整配置信息,该消息对应随机接入过程的Msg4;

Step3:RRC连接建立完成:UE通过UL_DCCH在SRB1上发送,携带上行方向NAS消息,如Attach Request、TAU Request、Service Request、Detach Request等,eNB根据这些消息进行S1口建立

5  RRC连接建立失败过程

上述Step2中,如果eNB拒绝为UE建立RRC连接,则通过DL_CCCH在SRB0上回复一条RRC连接拒绝消息

6  RRC连接重建过程

  • 触发原因:

           当处于RRC连接状态但出现切换失败、无线链路失败、完整性保护失败、RRC重配置失败等情况时,触发该过程

  • RRC连接重建立成功流程

Step1:RRC连接重建请求:UE通过UL_CCCH在SRB0上发起,携带UE的初始AS层初始标识信息和重建立原因,该消息对应随机接入过程的Msg3;

Step2:RRC连接重建:eNB通过DL_CCCH在SRB0上回复,携带SRB1的完整配置信息,该消息对应随机接入过程的Msg4;

Step3:RRC连接重建立完成:UE通过UL_DCCH在SRB1上发送,不携带任何实际信息,只起到RRC层确认的功能

7  RRC连接重建拒绝过程

上述Step2中,如果eNB中没有UE的上下文信息,则拒绝为UE重建RRC连接,则通过DL_CCCH在SRB0上回复一条RRC连接重建立拒绝消息

8  RRC连接重配置过程

  • 触发原因

          当需要发起对SRB和DRB的管理、低层参数配置、切换执行和测量控制时,触发该过程

  • RRC连接重配置过程

Step1:RRC连接重配置:eNB通过DL_CCCH在SRB1上发送,根据功能的不同携带不同的配置信息内容,一条消息中可以携带体现多个功能的信息单元;

Step2:RRC连接重配置完成:UE通过UL_DCCH在SRB1上发送,不携带任何实际信息,只起到RRC层确认的功能

9  RRC连接重配置异常过程

若UE无法执行RRC连接重配置消息中的内容,则UE回退到收到该消息前的配置,并发起RRC连接重建立过程

10  RRC连接释放过程

  • 触发原因

            网络希望解除于UE的RRC连接时,触发该过程

  • RRC连接释放过程

           RRC连接释放:eNB通过DL_DCCH在SRB1上发送,可选择携带重定位信息和专用优先级分配信息(用于控制UE的小区选择和小区重选)

  • 本地释放

            某些情况下,UE的RRC层根据NAS层的指示主动释放RRC连接,不通知网络侧而主动进入空闲状态,如NAS层鉴权过程中没有通过鉴权检查。

 

 

1 系统消息包含:

 

主信息块(Master Information Block,MIB)

 

多个系统信息块(System Information Blocks,SIBs)

2 MIB

 

  • 承载于BCCH——>BCH——>PBCH上
  •  
  • 包括有限个用以读取其他小区信息的最重要、最常用的传输参数(如:系统带宽、系统帧号、PHICH配置信息)
  •  
  • 时域:紧邻同步信道,以10ms为周期重传4次
  •  
  • 频域:位于系统带宽中央的72个子载波(1.08MHz)

3  SIBs

 

  • 除MIB外的系统信息,包括SIB1~SIB12;
  • 除SIB1外,SIB2~SIB12均由SI(System Information)承载;
  • SIB1是除MIB外最重要的系统信息,固定以20ms为周期重传4次,即SIB1在每两个无线帧(20ms)的子帧#5中重传(SFN mod 2=0,SFN mod 8不等于0)一次,如果满足SFN mod 8=0时,SIB1的内容可能改变,新传一次;
  • SIB1和所有SI消息均承载在BCCH——>DL-SCH——>PDSCH上;
  • SIB1的传输通过携带SI-RNTI(SI-RNTI每个小区都相同)的PDCCH调度完成;
  • SIB1中的SchedulingInfoList携带所有SI的调度消息,接收SIB1以后,即可接收其他SI消息。

 

1 LTE中,需要识别3个主要的同步需求

  •  符号和帧定时的捕获,通过它来确定正确的符号起始位置(如设置DFT窗位置);
  •  载波频率同步,需要它来减少或消除频率误差的影响(注:频率误差是由本地振荡器在发射端和接收端间的频率不匹配和UE移动导致的多普勒偏移造成的);
  •  采样时钟的同步

2 两个物理信号

  • 主同步信号(PSS,Primary Synchronization Signal)
  • 和辅同步信号(SSS,Secondary Synchronization Signal)

注:对于这两个信号的检测,不仅使得时间和频率获得同步,也为UE提供了小区的物理标识及循环前缀的长度,以及通知UE该小区是使用TDD还是FDD方式。

  • 在FDD小区内,PSS总是位于无线帧的第1个和第11个时隙的最后一个OFDM符号上,使得UE在不考虑循环前缀(CP)长度下获得时隙边界定时;SSS直接位于PSS之前;
  • 在TDD小区内,PSS位于每个无线帧的第3个和第13个时隙上,从而SSS比PSS早3个符号

                                  图1 PSS与SSS的位置

3 UE开机流程

  图2 UE开机流程

4 小区搜索过程

     eNB一直处于开机状态,UE无论开机还是mobility,都通过小区搜索(cell search)实现时、频同步,同时获得PCI(Physical Cell Identity)。然后读PBCH,得到系统帧号和带宽信息,以及PHICH的配置等系统消息,具体步骤如下:

  • 一般来说应该UE先对可能存在小区的频率范围内测量小区信号强度RSSI,据此找到一个可能存在小区的中心频点;
  • 然后在这个中心频点周围收PSS和SSS,这两个信号和系统带宽没有限制,配置是固定的,而且信号本身以5ms为周期重复,并且是ZC序列,具有很强的相关性,因此可以直接检测并接收到,据此可以得到小区Id,同时得到小区定时的5ms边界;
  • 5ms边界得到后,根据PBCH的时频位置,使用滑窗方法盲检测,一旦发现CRC校验结果正确,则说明当前滑动窗就是10ms的帧边界,并且可以根据PBCH的内容得到系统帧号和带宽信息,以及PHICH的配置;
  • 至此,UE实现了和eNB的定时同步。

    当获取了PBCH信息后,要获得更多的无线信道参数等还要接受其余的SIB信息,这些信息在PDSCH上发送:

  • 接收PCFICH,此时该信道的时频资源就是固定已知的了,可以接收并解析得到PDCCH的symbol数目;
  • 接收PHICH,根据PBCH中指示的配置信息接收PHICH;
  • 在控制区域内,除去PCFICH和PHICH的其他CCE上,搜索PDCCH并做译码;
  • 检测PDCCH的CRC中的RNTI,如果为SI-RNTI,则说明后面的PDSCH是一个SIB,于是接收PDSCH,译码后将SIB上报给高层协议栈;
  • 不断接收SIB,HLS会判断接收的系统消息是否足够,如果足够则停止接收SIB

至此,小区搜索过程才差不多结束。

5 UE随机接入过程

  • 为什么要进行随机接入过程??

          申请上行资源

          UE通过随机接入与基站进行信息交互,完成后续操作(如呼叫、资源请求、数据传输等操作)

          实现与系统的上行时间同步

          随机接入的性能直接影响到用户体验,能够适应各种应用场景、快速接入、容纳更多用户的方案

  • 随机接入过程包括:

         随机接入前导(Preamble)的发送

         随机接入响应

注:Preamble——>当UE收到eNB的广播信息需要接入时,从序列集中随机选择一个preamble序列发给eNB,然后eNB根据不同的前导序列来区分不同的UE

  • UE侧随机接入流程

Step1解析传输请求,获得随机接入配置信息

Step2选择preamble序列

1)基于竞争的随机接入:随机选择preamble

2)无竞争的随机接入:由高层指定preamble

Step3按照指定功率发送preamble

Step4盲检用RA-RNTI标识的PDCCH

 --检测到,接收对应的PDSCH并将信息上传;

 --否则直接退出物理层随机接入过程,由高层逻辑决定后续操作;

 

               图3 UE侧随机接入流程

5.1 基于竞争的随机接入流程

     图4 基于竞争的RA流程

Step1UE端通过在特定的时频资源上,发送可以标识其身份的preamble序列,进行上行同步

说明:

eNB可以选择64个preamble码中的部分或全部用于竞争接入;

Msg1承载于PRACH上

Step2基站端在对应的时频资源对preamble序列进行检测,完成序列检测后,发送随机接入响应。

说明:

Msg2由eNB的MAC层组织,并由DL_SCH承载;

一条Msg2可同时响应多个UE的随机接入请求;

eNB使用PDCCH调度Msg2,并通过RA-RNTI进行寻址,RA-RNTI由承载Msg1的PRACH时频资源位置决定;

Msg2包含上行传输定时提前量,为Msg3分配的上行资源,临时C-RNTI等;

Step3UE端在发送preamble序列后,在后续的一段时间内检测基站发送的随机接入响应;UE在检测到属于自己的随机接入响应,该随机接入响应中包含UE进行上行传输的资源调度信息

说明:

UE在接收Msg2后,在其分配的上行资源上传输Msg3,并映射到UL-SCH上的CCCH逻辑信道上发送;

针对不同场景,Msg3包含不同的内容:

    • 初始接入:携带RRC层生成的RRC连接请求,包含UE的S-TMSI或随机数;
    • 连接重建:携带RRC层生成的RRC连接重建请求,C-RNTI和PCI;
    • 切换:传输RRC层生成的RRC切换完成消息以及UE的C-RNTI;
    • 上/下行数据到达:传输UE的C-RNTI。

 

Step4基站发送冲突解决响应,UE判断是否竞争成功

                                        图5 竞争判决

5.2 基于非竞争的随机接入流程

  图6 基于非竞争的RA流程

Step1基站根据此时的业务需求,给UE分配一个特定的preamble序列。(该序列不是基站在广播信息中广播的随机接入序列组)

说明:

对于切换场景,eNB通过RRC信令通知UE;

对于下行数据到达和辅助定位场景,eNB通过PDCCH通知UE

Step2UE接收到信令指示后,在特定的时频资源发送指定的preamble序列

Step3基站接收到随机接入preamble序列后,发送随机接入响应。进行后续的信令交互和数据传输。

6 UE附着过程(Attach)

  • Attac的功能

     向EPC注册EPS业务或non-EPS服务;

     为UE分配IP,建立UE和PDN GW之间的缺省承载(default bearer),使得UE的IP连接永远在线.(always-on IP connectivity);

     还可激活多个专用承载(dedicated bearers);

     Attach过程中产生安全上下文,投入使用后,对NAS信令进行安全保护

  • UE开机Attach过程

                            图7 UE开机Attach流程

Step1:处于RRC_IDLE的UE进行Attach过程,首先发起随机接入过程,即Msg1消息;

Step2:eNB检测到Msg1消息后,向UE发送随机接入响应消息,即Msg2消息;

Step3:UE收到随机接入响应后,根据Msg2的TA调整上行发送时机,向eNB发送RRC Connection Request消息;

Step4:eNB向UE发送RRC Connection Setup消息,包含建立SRB1承载信息和无线资源配置信息;

Step5:UE完成SRB1承载和无线资源配置,向eNB发送RRC Connection Setup Complete消息,包含NAS层Attach Request消息;

Step6:eNB选择MME,向MME发送Initial UE Message消息,包含NAS层Attach Request消息;

Step7:MME向eNB发送Initial Context Setup Request消息,请求建立默认承载,包含NAS层Attach Accept、Activate Default EPS Bearer Context Request消息;

Step8:eNB接收到Initial Context Setup Request消息,如果不包含UE能力信息,则eNB向UE发送UE Capability Enquiry消息,查询UE能力;

Step9:UE向eNB发送UE Capability Information,报告UE的能力信息;

Step10:eNB向MME发送UE Capability Information Indication消息,更新MME的UE能力信息;

Step11:eNB根据Initial Context Setup Request消息中UE支持的安全信息,向UE发送Security Mode Command消息,进行安全激活;

Step12:UE向eNB发送Security Mode Complete消息,表示安全激活完成;

Step13:eNB根据Initial Context Setup Request消息中的ERAB建立信息,向UE发送RRC Connection Reconfiguration消息进行UE资源重配,包括重配SRB1和无线资源配置,建立SRB2、DRB(包括默认承载)等;

Step14:UE向eNB发送RRC Connection Reconfiguration Complete消息,表示资源配置完成;

Step15:eNB向MME发送Initial Context Setup Response响应消息,表明UE上下文建立完成;

Step16:UE向eNB发送UL Information Transfer消息,包含NAS层Attach Complete、Activate Default EPS Bearer Context Accept消息;

Step17:eNB向MME发送上行直传UL NAS Transport消息,包含NAS层Attach Complete、Activate Default EPS Bearer Context Accept消息;

说明:

步骤1~5建立RRC连接,步骤6、9完成S1连接,完成这些标志着NAS signaling connection建立完成

  • 进一步理解Attach过程

                            图8 Attac流程进一步理解

Step1:在已经建立NAS信令连接基础上,UE通过向MME发送 ATTACH REQUEST 消息来发起attach规程;该消息中包含:IMSI或GUTI、last visited TAI、UE network capbility、PDN IP option、connect type等

Step2:如果UE最新连接的(新)MME与最后一次离开网络时连接的(旧)MME相比已经发生改变,新MME就会向旧MME发送一个ID请求来申请当前UE的IMSI,用于为当前UE重新分配GUTI。

Step3:如果新MME和旧MME都不能识别当前的UE,那么新MME会给UE发送一个ID请求,随后,UE应告诉新MME自己的IMSI。

Step4:如果当前网络中没有UE的安全上下文,那么MME会发起一个鉴权规程,UE和MME相互鉴权之后会在两侧产生相关的安全下文。(漫游情况下,MME应从HSS获取UE的签约信息等内容)

Step5:鉴权结束后,MME可能发送移动设备标识检查请求到EIR(Equipment  Identity Register)(MME的经营可能会检查EIR中的移动设备标识,至少在漫游时,MME应将移动设备标识传给HSS)。

Step6:如果MME中有激活的承载上下文(比如之前连接尝试失败时已经创建了承载),那么MME会发送消息到各个P-GW来删除这些无效的承载上下文。

Step7:由于位置已经变化(MME变化),新MME就发送一个位置更新请求到HSS(指明MME标识、IMSI和ME标识等)。

Step8:新MME向HSS发送位置更新请求后,旧的MME就可以删除其中保存的UE的位置信息以及相应的承载上下文。

Step9:HSS向新MME回送一个位置更新响应,来指明位置更新的状态。若HSS拒绝位置更新,那么MME就拒绝UE的attach请求。

Step10:位置更新完毕后,新MME就可以与PDN-GW之间建立默认承载,建立默认承载后P-GW就为UE创建了PDN地址、EPS承载标识、协议配置选项等,并将相关消息返回给MME,S-GW可以缓存一些来自P-GW的下行数据包。

Step11:MME接受attach及附着完成:MME通过eNB将APN、GUTI、PDN地址、TAI列表等信息反馈给UE,并请求UE建立无线承载;UE完成无线承载建立后向MME返回一个完成消息指明attach完成。

7 Detach过程

Detach过程完成UE在网络侧的注销和所有EPS承载的删除;

UE/MME/S-GW/HSS均可发起Detach过程;

若网络侧长时间没有获得UE的信息,则会发起隐式的Detach过程,即核心网将该UE的所有承载释放而不通知UE

7.1 UE发起Detach过程

                                    图9 UE发起的Detach流程

Step1:处在RRC_CONNECTION状态的UE进行Detach过程,向eNB发送UL NAS Transfer消息,包含NAS层Detach Request信息;

Step2:eNB向MME发送上行直传UL NAS Transport 消息,包含NAS层Detach Request信息;

Step3:MME向S-GW发送Delete Session Request,以删除EPS承载;

Step4:S-GW向MME发送Delete Session Response,以确认EPS承载删除;

Step5:MME向eNB发送下行直传DL NAS Transport消息,包含NAS层Detach Accept信息;

Step6:eNB向UE发送DL Information Transfer消息,包含NAS层Detach Accept信息;

Step7:MME向eNB发送UE Context Release Command消息,请求eNB释放UE上下文;

Step8:eNB接收到UE Context Release Command消息,向UE发送RRC Connection Release消息,释放RRC连接;

Step9:eNB释放UE上下文信息,向MME发送UE Context ReleaseComplete消息进行响应

7.2 MME发起Detach过程

                  图10 MME发起的Detach流程

8 Service Request过程

  • 作用

当UE无RRC连接且有上行数据发起需求时

当UE处于ECM  IDLE状态且有下行数据到达时

      在S1接口上建立S1承载,在Uu接口上建立数据无线承载

  • 说明:

当UE发起Service Request时,需先发起随机接入过程;

Service Request由RRC Connection Setup Complete携带上去;

当下行数据到达时,网络侧先对UE进行呼叫,随后UE发起随机接入过程,并发起Service Request过程;

UE发起Service Request相当于主叫过程;

下行数据到达发起的Service Request相当于被叫接入

                                图11 Service Request流程

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章