srsLTE源码分析 UE_03 代码中的接口

92 阅读 0 评论 61 点赞

我是靠谱客的博主烂漫鸵鸟，最近开发中收集的这篇文章主要介绍srsLTE源码分析 UE_03 代码中的接口，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

上一篇中，介绍了srsLTE UE代码中的一些关键的类，本篇会从继续探究一下这些类中的接口，接口对于理解代码是如何运行的至关重要，由于代码中的接口较为繁杂，本文挑选了一些比较重要的接口进行了整理，来帮助读者理解这些接口的调用关系。

提供给RRC接口

首先，先来介绍RRC的相关接口，从图中可以看出，RRC是整个协议栈的控制核心，NAS、PDCP、RLC、MAC、PHY都给RRC提供了调用接口，这和RRC在协议栈中的作用是有关的，RRC在整个AS（UE< -- >eNB）的接入过程中起着关键的作用，且处于AS侧协议的顶层位置(RRC、PDCP、RLC、MAC、PHY)。NAS层是和核心网进行协议交互的对等实体，因此，NAS层不包含在AS里面。从接口也可以看出RRC负责的部分的工作：如建立承载、配置、小区搜索、测量配置、切换等。PDCP，RLC、MAC、PHY都是提供了reset接口，RRC可以根据情况将协议栈复位。

这里有个有趣的问题，PDCP和RLC都给RRC提供了write_sdu的接口，这是为什么原因呢？这里就要说到信令承载了，SRB0、SRB1的区别？

SRB0:UE在开始接入前，没有建立任何承载，这是只有默认的SRB0（CCCH）承载用于发送RRC的信令，比如随机接入的MSG3（UE –> eNB）信令就是在SRB0上进行发送。

SRB1:在MSG4(eNB ->UE)信令里面会携带建立SRB1承载的内容，MSG4之后，SRB1承载就建立成功，RRC信令就会在SRB1承载上发送，当然SRB1也可以顺便携带NAS信令。

LTE 上行架构图

但从上面的简单描述，读者可能还不了解SRB0和SRB1的区别，还是再看一次LTE上行的架构图。SRB0没有加密和完整性保护，SRB1是有的，因此，SRB1的安全性更高。SRB0采用的TM模式(透传)，SRB1采用的时AM模式，会采用ARQ重传，可靠性更高。从图中也可以看出，RRC的SRB0上的信令直接发给RLC，而没有经过PDCP，SRB1上的信令都是发给PDCP的。因此，RLC和PDCP都给RRC提供了write_sdu的接口，这是因为SRB0和SRB1的不同性质导致。

RRC提供的接口

RRC提供的接口，读者可以自行先了解一下，RRC给PDCP和RLC都提供了write_pdu的接口，这个原因和上面的原因是一致的。通过这个接口，RRC就可以收到基站的RRC信令。

上行数据发送的接口调用流程

最后，以上行数据发送为例，大致的来看一下，各层的接口是如果工作的，这里省略了大多数的细节，只保留了关键的部分。从图中可以看出，gw类read tun接口从内核得到应用数据的IP数据包，通过PDCP提供的 write_sdu接口，gw将IP数据包转给PDCP进行处理，PDCP进行加密、ROHC(可选)、封装PDCP头等工作；PDCP在通过RLC提供的write_sdu接口，把数据送给RLC处理，RLC进行分段，加RLC头等工作，这个数据包就暂时告一段落了，RLC不会主动把报文发送给MAC。

某个TTI，物理层检测到基站的DCI0的上行调度，会在合适的时机（都是有调度时序的约束，后续再讲）进行上行调度，PHY层会调用MAC提供的new_grant_ul接口，这个接口会调用MUX模块进行逻辑信道复用，最终会调用到RLC提供的read_pdu接口（这里是一个回调的方式，实现比较隐蔽），在加上MAC头，最后将数据转给PHY再进行处理。

至此，srsLTE UE系列的开头就大致介绍完了，主要是给读者了解下宏观的一些内容，如果您对srsLTE有所了解的话，可能有比较深的感触，如果只是初学者的话，可能会有比较大的障碍。下篇开始，就开始深入代码，从代码角度探究协议的工作细节，为照顾到一些初入门的读者，在讲解代码之前，会花一下篇幅介绍下响应的理论基础。

如果您也期待后续的文章的话，请关注和收藏作者，您的支持，是我最大的动力。