对eNodeB的一些配置以及代码结构进行说明，如下：
一，eNodeB配置结构
|| 控制进程（传递eNB配置命令）|| ---》 || eNB按照配置进程的配置命令工作 ||
1， 在一个Tab窗口运行LTE_fdd_eNodeB进程（启动eNodeB工作进程）
2， 在另一个Tab窗口运行控制进程，可使用连接工具（Telent,nc等）连接LTE_fdd_eNodeB进程（端口固定为30000，以Telnet连接本机示例，使用命令为Telnet 127.0.0.1 30000）来完成配置操作，包括启动，终止LTE_fdd_eNodeB进程中的基站操作，读取，设置基站操作中需要的参数；
二，代码重要实体层说明
2.1 Interface层
eNB提供的接口，处理来自外部的配置命令；
2.2 MsgQ实体
提供统一的消息管理实体，对于各个协议层的消息进行处理，接收，存储，发送；
2.3 Radio层
1， Radio的Start函数创建线程（radio_thread）来处理数据帧收发；在线程函数中会调用Phy层实体的radio_interface接口来处理上，下行数据，在radio_interface中会进一步地包含上，下行处理，在处理上下行数据中，当对user data进行处理时，会用到dl_sched_mutx锁：
Dl_sched_mutex_lock()
Dl_sched_mutex_unlock()
2.4 Phy层
Start函数中会定义对于Mac数据处理的接口，在进而处理下行调度类型数据时，会应用线程锁：
boost::mutex::scoped_lock lock(dl_sched_mutex)
2.5 Rb协议实体
1，Msg会包含Rb的指针，指向特定的Rb
1， 一个UE只会定义一定数据的RB实体（最多3个SRB，8个DRB）,每个RB中会为每个协子层定义一个消息队列（如，RRC，PDCP，RLC，MAC）；
Rb_Id的填写在gw协议实体中完成，目前代码中作了简化处理，在gw层只会填写id=1：gw将rb_id会被填写进消息中，并一直在包含在后续pdb流中各个的协议实体间传递：
Gw->pdcp->rlc->mac
2， 当前处理协议子层m从传递的消息中查询到RB后，从RB中取出对应当前处理协议子层m队列中的消息数据，按照当前处理协议子层m的处理机制进行处理，然后再次处理完成后的消息数据单元（下一相邻子层的SDU）存储到RB定义的对应到下一协议子层n的消息数据队列中；并构造消息头传递到协议子层定义的与下一相邻子层n通信的m_n_olmq中下一相邻协议子层n接收到来m的消息后，会触发hand_m_msg的操作，也是处理消息头，取SDU，处理完后再构造下一层的SDU，再向下一协议层发送消息触发下一层的处理，例如，rlc处理完本协议层的操作后向mac层发送消息操作：
LTE_fdd_enb_msg::send(rlc_mac_olmq, **)
3， 直到消息到了mac层，处理方式有不同：
1， rb_id需要转换为mac_id，处理方式有不同：
sdb_ready->rb->get_rb_id()
2， 上层发下来的SDB数据处理后，只是会存储在scheduler队列中，如下：
Add_to_dl_sched_queue
不会主动向phy层发送消息，phy层会基于phy层的机制来触发mac层的调度机制，进而从调度队列中依次取出PDU进行发送；
2.6 User实体
管理用户的参数属性；例如标识，能力，承载等；
2.7 安全机制
Eia算法
33220中KDF算法如下：
Derivedkey = HAMC-SHA-256(Key，S)
在Security中使用sha2_hmac实现：
在代码中好像没有对up面生成的key使用，而且只是保存在Hss中，有些疑问：
用户面的key使用终点是基站，应该保存基站侧才合适；
三，实体之间交互
3.1 Radio与Phy实体之间交互
Radio_thread->radio_thread_func->radio_interface（此函数是由Phy层提供，并且此处是通过while(循环一直调用)）->process_dl/process_ul
其中，UL发送到MAC的帧；DL调用radio中的send(调用uhd的tx-stream)进行发送
Phy类中定义的成员boost::interprocess:message_queue*phy_mac_olmq用来承载Phy给MAC层传递的消息（包括各种类型物理信道（PRACH,PUSCH,PUCCH）的解码后的内容以及一种全称为read_to_send的消息），此处重点说明一下ready_to_send消息，即Phy层处理完了上行或者下行子帧的发送，需要告知MAC层其已经等待好处理下一子帧；MAC层通过读取phy_mac_olmq进行获取发送的消息；当获取到消息类型为read_to_send时，则会执行调度操作，主要为配置子帧资源；
3.2 MessageQueue举例
上层通过send函数向该queue中发送message，主要操作过程如下：
a) Phy层实例化对象：mac_comm_msgq=newLTE_fdd_end_msgq(“mac_phy_olmq”,cb);
b) Mac层定义了boost对象mac_phy_olmq，再向该对象队列中发送消息：
1） mac_phy_olmq->send(&msg_sizeof(msg),0)
2） LTE_fdd_enb_msg::send(mac_phy_olmq；
Phy层在实例化mac_comm_msgq对象时，会调用回调函数：
Messageq->receive_thread->callback(即handle_mac_message，并且callback直到接收到Interface发送的Stop参数的消息才终止处理)->handle_dl_schedulehandle_ul_schedule 其中：
Handle_dl_schedule处理下行调度相关操作，主要是将MAC中Scheduler函数中已经组装好的帧拷贝到具体的位置；并提供给后续process_dl函数中封装user_data时使用，有以下代码操作：
memcpy(&pdcch.alloc[pdcch.N_alloc],&dl_schedule[subfn].ul_allocations.alloc[i],
handle_ul_schedule的目的是为了封装phich。因为phich的封装需要基于MAC层的调度信息。有以下Comment:
for(i=0; i<ul_schedule[ul_subframe.num].decodes.N_alloc; i++)
{
// Determine PHICH indecies
3.3 LTE_fdd_enb_msgq对象Msgq与boost对象olmq
层m为与相邻n层交互，需要定义一个m_n_olmq，并向m_n_olmq发送消息数据；n层会定义一个相应的m_comm_mesq(实例化的时候，其string名称即为m_n_olmq)，这样n层在m_comm_mesq中即可获取来自m层的消息数据：
具体操作如下实例：
在协议层mac层中实例化boost对象：
Mac_phy_olmq = newboost::interprocess::message_queue(boost::interprocess:open_only *
在Phy层中msgq定义如下：
Mac_comm_msgq= new LTE_fdd_enb_msgq(“mac_phy_olmq”,cb);
在后续msgq(专用类)的处理操作receive_thread中，通过msgq的string name对应到”mac_phy_olmq”这个boost:
Boost::interprocess::message_queue mq(boost::interprocess::open_only,msgq->msgq_name.c_str());
未完待续。。。欢迎各位也在关注这个项目的朋友指点交流~
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
