我是靠谱客的博主 能干香水,最近开发中收集的这篇文章主要介绍[4G&5G专题-79]:流程 - 4G LTE 寻呼流程Paging,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

目录

第1章 L3层信令架构

1.1 RAN协议栈

1.2 信令流与数据流

1.3 信道映射

1.4 连接管理

1.5 手机附着的整体流程

1.6 无线承载

1.7 RRC连接状态

第2章 寻呼概述

2.1 什么是寻呼

2.2 寻呼的条件

2.3 寻呼的触发源与触发条件

第3章寻呼流程

3.1 寻呼流程概述

3.2 MME 寻呼消息的内容

第4章 基站如何发送寻呼消息

4.1 寻呼信道

4.2 下行物理共享信道PD-SCH

第5章 终端如何接收寻呼消息:DRX

5.1 非连续接收的由来

5.2 DRX的分类

5.3 寻呼消息的响应


第1章 L3层信令架构

1.1 RAN协议栈

1.2 信令流与数据流

1.3 信道映射

1.4 连接管理

1.5 手机附着的整体流程

1.6 无线承载

Radio Bearer (RB)是RRC层的概念,是基站为UE分配的不同层协议实体及配置的总称,包括PDCP协议实体、RLC协议实体、MAC协议实体和PHY分配的一系列资源等。

RRC层的无线承载分为小区系统级静态无线承载和手机专有级动态无线承载。

RB是Uu接口连接eNodeB和UE的通道(包括PHY、MAC、RLC和PDCP),任何在Uu接口上传输的数据都要经过RB。RB包括SRB和DRB。

SRB是系统的信令消息实际传输的通道,

DRB是用户数据实际传输的通道。

RRC是管理RB的协议实体,通过RRC信令的交互完成RB的建立、修改以及释放等功能。

通俗的讲RRC连接指的是UE和eNodeB之间建立的SRB1,因为标准规定SRB0是不需要建立的,UE在RRC_IDLE状态就可以获得SRB0的配置和资源,如果需要可以直接使用。

系统中业务发起的过程是:

(0)SRB0:SRB0是缺省承载,UE在随机接入成功后,进入RRC_IDLE时,该承载就建立起来。

(1)通过默认信令承载SRB0,建立手机与基站之间业务信令承载SRB1,SRB1建立之后UE就进入RRC_Connected状态;

(2)通过业务信令承载SRB1,建立手机与核心网之间的NAS信令承载SRB2;SRB2专门用于传输核心网NAS信令; RRCConnectionSetup消息用于建立SRB1.

(3)通过业务信令承载SRB1,建立手机与基站之间业务数据承载DRB1或DRB2, 不同的业务数据,需要建立不同的DRBx。

(4)在业务传输过程中,通过SRB1进行管理

(5)当业务结束后,通过业务信令承载SRB1上传输的信令,可以将所有的DRB、SRB1和2,使得UE进入到RRC_IDLE状态,在需要时UE唯一可以使用的资源就是SRB0,而且需要在完成随机接入之后进行。

1.7 RRC连接状态

RRC idle:随机接入成功,但手机和基站时间还没有建立RRC信令连接。

RRC Connected:手机和基站时间建立起RRC信令连接。手机可以通过RRC连接发送信令请求,基站也可以通过RRC连接给手机发送信令。

也就是,基站为终端分配号了用于传送RRC信令的空口无线资源。

第2章 寻呼概述

2.1 什么是寻呼

所谓寻呼Paing,就是网络(接入网或核心网)寻找手机唤醒手机的过程。

因为手机是移动的,其位置是动态变化的,且手机可能异常关机或进入低功耗状态,手机并非时时刻与基站或核心网保持RRC连接。

网络中有其他用户需要呼叫手机时,网络就需要找到该手机,且然后唤醒手机, 通知该手机,申请上行资源,重新建立RRC连接。

2.2 寻呼的条件

该手机的RRC连接已经释放,处于RRC idle状态,也就是说SRB1和SRB2、DRB等承载都已经释放,基站一侧只为该终端保留了SRB0承载的资源。

这时候才需要发起寻呼流程,通知终端发起新的RRC连接。

如果手机已经处于RRC连接状态,基站只需要通过SRB1、核心网只需要通过SRB2承载通知手机即可,并通过已有的DRB承载发送数据。

2.3 寻呼的触发源与触发条件

(1)MME触发

  • 核心网侧要发送数据,给处于 RRC_IDLE 状态下的UE,如有用户呼叫该UE

MME发送寻呼消息时,eNodeB根据寻呼消息中携带的UE的跟踪区列表(TAL)消息,通过逻辑信道PCCH向其下属于TAL的所有小区发送寻呼消息来寻呼UE。

寻呼消息包含指示寻呼来源的域,以及UE标识。UE标识可以是S-TMSI或IMSI

LTE采用跟踪区的方式,记录终端的位置。之所以没有采用小区的方式,是因为LTE小基站,区小区的覆盖范围小,如果按照小区的方式跟踪UE的位置,导致位置更新过于频繁。

  • 核心网侧有地震海啸警报系统(ETWS)需要通知处于RRC_IDLE 状态下的UE

(2)基站触发

  • 接入网侧有MIB、SIBx消息更新,如频点发生改变、邻区发生变化,需要及时唤醒终端,读取新的MIB和SIBx消息。

系统消息变更时,eNodeB将通过寻呼系统消息通知小区内的所有EMM注册态的UE,并在紧随的下一个系统消息修改周期中发送更新的系统消息。

两者触发源不同,但是在空口的寻呼机制相同。

第3章寻呼流程

3.1 寻呼流程概述

å¨è¿éæå¥å¾çæè¿°

  1. SGW收到一个可知UE的下行数据,但是与这个UE之间没有用户面的连接(即SGW的上下文数据指示中没有下行用户面的TEID)时,SGW先缓存这些数据,并确认哪个MME为这个UE提供服务
  2. SGW向MME发送Downlink Data Notification消息,这个节点与UE有控制面连接
  3. 如果UE注册到MME,则MME向UE注册的TA列表所属的所有eNodeB发送寻呼消息。
  4. eNodeB收到MME的寻呼消息,则eNodeB对UE发起寻呼
  5. 当UE处于空闲态时,UE在E-UTRAN中响应寻呼,从而执行Service Request过程
  6. UE在RRC Connection Setup过程中,发送NAS消息Service Request(封装在RRC消息里)给eNodeB,eNodeB再转发这个NAS消息给MME
  7. MME可以选择触发安全流程(鉴权、加密)
  8. MME发送S1-AP Initial Context Setup Request 消息(携带SGW Address、EPS Bearer QoS、Security Context、Handover Restriction List)给eNodeB,用于激活S1口承载
  9. eNodeB将建立无线侧承载,eNodeB发送 RRC Connection Reconfiguration消息给UE,UE回复 RRC Connection Reconfiguration Complete消息给eNodeB
  10. 此时eNodeB 将UE的上行数据转发给SGW,SGW再把上行数据转发给PDN GW
  11. eNodeB发送一个S1-AP消息 Initial Context Setup Complete给MME,在这个消息里,eNodeB下行数据的TEID会包含在里面
  12. MME发送一个Modify Bearer Request 消息给SGW,在这个消息里包含eNodeB的地址、S1 TEID等。这时候Serving GW可以传送下行数据给UE了
  13. 最后,SGW发送一个Modify Bearer Response消息给MME
     

在上述流程中,核心网-》基站-》UE, 先下发寻呼消息,唤醒UE。

唤醒UE之后,UE发起RRC连接请求,这个与UE的Attach流程相似,本章不再探讨。

本文主要深入探讨一下核心网是如何通过寻呼消息唤醒UE的。

3.2 MME 寻呼消息的内容

备注:

  • MME只在UE所处的跟踪列表下的所有基站下进行寻呼。
  • MME的寻呼消息不仅仅发送给一个基站,可能会发送给多个基站

第4章 基站如何发送寻呼消息

4.1 寻呼信道

寻呼消息是RRC消息,通过专门的寻呼逻辑信道和传输信道进行传输,物理层并没有专有的寻呼信道,物理层是通过物理下行共享信道发送的。

寻呼消息的发送路径如下:PCCH -> PCH -> PDSCH。

4.2 下行物理共享信道PD-SCH

(1)时频资源

注意:

只要终端进行过随机接入流程,即使终端处于RRC IDLE态,在基站侧也是有上下文的,也就是说,在基站的管辖范围内。基站为终端也预留了SRB0默认的信令承载。

当终端需要发起RRC连接请求时,就可以通过SRB0信令承载发起信令流程,申请更多的上行资源。

(2)传输内容

  • 下行业务数据
  • 寻乎指示
  • 控制信令
  • 系统SIB消息

第5章 终端如何接收寻呼消息:DRX

5.1 非连续接收的由来

非连续接收(DRX,Discontinuous Reception)基于包的数据流通常是突发性的,在一段时间内有数据传输,但在接下来的一段较长时间内没有数据传输。

在没有数据传输的时候,可以通过停止连续接收PDCCH或PDSCH信道(此时会停止PDCCH/PD-SCH盲检)来降低功耗,而是采用间隙性的唤醒,从而提升电池使用时间。

5.2 DRX的分类

UE在一段时间里停止监听PDCCH信道,DRX分两种:

(1)IDLE态的DRX

当UE处于IDLE状态下的非连续性接收,由于处于IDLE状态时,已经没有RRC连接以及用户的专有资源,因此这个主要是监听寻呼信息与广播信道,只要定义好固定的周期,就可以达到非连续接收的目的。但是UE要监听用户数据的信道,则必须从IDLE状态先进入唤醒状态。

在Idle-DRX模式中,UE没有无线资源连接,主要完成对寻呼信道和广播信道监听,为了达到非连续接收,只需配置好固定睡眠周期。

空闲模式下的DRX周期分为激活期和睡眠期。

(2)ACTIVE态的DRX

也就是UE处在RRC-CONNECTED 状态下的DRX, 可以优化系统资源配置,更重要的是可以节约手机功率,而不需要通过让手机进入到RRC_IDLE 模式来达到这个目的,例如一些非实时应用,像web浏览,即时通信等,总是存在一段时间,手机不需要不停的监听下行数据以及相关处理,那么DRX就可以应用到这样的情况,另外由于这个状态下依然存在RRC连接,因此UE要转到支持状态的速度非常快。

在Connected-DRX模式中,UE有三种状态,分别处于活跃期,短DRX周期(浅睡眠期)和长DRX周期(深睡眠期)。

在活跃期,UE处于功率消耗模;在浅、深睡眠期,UE处于功率节省模式。

5.3 寻呼消息的响应

一旦终端监控到寻呼自己的消息,就从idle唤醒,发起RRC连接的请求,这个过程与Attch流程类似。

详细见:<<[4G&5G专题-78]:流程 - 4G LTE 核心网的Attach流程>>

[4G&5G专题-78]:流程 - 4G LTE 核心网的Attach流程_文火冰糖的硅基工坊的博客-CSDN博客

最后

以上就是能干香水为你收集整理的[4G&5G专题-79]:流程 - 4G LTE 寻呼流程Paging的全部内容,希望文章能够帮你解决[4G&5G专题-79]:流程 - 4G LTE 寻呼流程Paging所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(56)

评论列表共有 0 条评论

立即
投稿
返回
顶部