Openlte Open source Code structure analysis (II.)

Some of the configuration of eNodeB and the code structure are described below:

One, ENODEB configuration structure

|| Control process (pass ENB configuration command) | | ---"| | ENB working with configuration commands for the configuration process | |

1. Run the LTE_FDD_ENODEB Process in a tab window (start the eNodeB worker process)

2, in another tab window to run the control process, you can use the Connection tool (TELENT,NC, etc.) to connect the Lte_fdd_enodeb process (port fixed to 30000, Telnet connection to the native sample, using the command for Telnet 127.0.0.1 30000) To complete the configuration operation, including starting, terminating the base station operation in the LTE_FDD_ENODEB process, reading, setting the parameters needed in the operation of the base station;

Two, code important entity layer Description

2.1 Interface Layer

ENB provides an interface to handle configuration commands from outside;

2.2 Msgq Entity

Provides a unified Messaging management entity for processing, receiving, storing, and sending messages for each protocol layer;

2.3 Radio Layer

1, radio the Start function creation thread (RADIO_THREAD) to handle the data frame transceiver; The Radio_interface interface of the PHY layer entity is called in the thread function to process the upstream and downstream data, and the Radio_interface will further include the , the downstream processing, in the processing of the downstream data, when the user data processing, will use the DL_SCHED_MUTX lock:

Dl_sched_mutex_lock ()

Dl_sched_mutex_unlock ()

2.4 PHY Layer

The start function defines the interface for Mac data processing, and the thread lock is applied when the downstream scheduling type data is processed:

Boost::mutex::scoped_lock Lock (Dl_sched_mutex)

2.5 RB Agreement Entity

The 1,msg will contain a pointer to the RB, pointing to the specific RB

1, a UE will only define a certain data of the RB entity (up to 3 srb,8 DRB), each RB will define a message queue for each sub-layer (such as, RRC,PDCP,RLC,MAC);

RB_ID is completed in the GW Agreement entity, the current code is simplified processing, in the GW layer will only fill ID=1:GW will be filled in the RB_ID message, and has been included in the subsequent PDB flow between the various protocol entities passed:

Gw->pdcp->rlc->mac

2, the current processing protocol sub-layer m from the message passed the query to RB, from the RB to the current processing protocol sub-layer m queue of message data, according to the current processing protocol sub-layer m processing mechanism for processing, The completed Message data unit (SDU of the next adjacent sub-layer) is then processed and stored into the message data queue of the next protocol sub-layer n, which is defined by the RB, and the message header is passed to the next neighboring sub-layer of n communication defined by the Protocol sub-layer, and the second neighboring protocol sub-layer n receives the incoming m message Will trigger the operation of the hand_m_msg, but also processing the message header, take SDU, processing and then construct the next layer of SDU, and then send a message down a protocol layer to trigger the next layer of processing, for example, RLC processing after the operation of this protocol layer to the MAC layer to send message operations:

Lte_fdd_enb_msg::send (RLC_MAC_OLMQ, * *)

3, until the message to the MAC layer, the processing method is different:

1, rb_id needs to be converted to mac_id with different processing methods:

SDB_READY->RB->GET_RB_ID ()

2, after the upper layer of the SDB data processing, will only be stored in the scheduler queue, as follows:

Add_to_dl_sched_queue

does not actively send messages to the PHY layer, the PHY layer will trigger the MAC layer scheduling mechanism based on the PHY layer mechanism, and then remove the PDU from the dispatch queue to send;

2.6 User Entity

Manage user's parameter attributes, such as identity, ability, bearer, etc.

2.7 Security mechanisms

EIA algorithm

The 33220 KDF algorithm is as follows:

Derivedkey = hamc-sha-256 (key,s)

Using the SHA2_HMAC implementation in security:

In the code, it seems that the key generated by the up face is not used, and is only stored in HSS, with some questions:

The user surface key uses the end point is the base station, should save the base station side to be suitable;

Third, interaction between Entities 3.1 radio and PHY entities

Radio_thread->radio_thread_func->radio_interface (This function is provided by the PHY layer and is here through while (loops are called))->process_dl/ Process_ul

Wherein, the UL sends the frame to the Mac; DL calls send in radio (called UHD Tx-stream) for sending

The member BOOST::INTERPROCESS:MESSAGE_QUEUE*PHY_MAC_OLMQ defined in the PHY class is used to host the messages passed by the PHY to the MAC layer (including various types of physical channels (Prach,pusch, PUCCH), and a message called Read_to_send, which focuses on the ready_to_send message that the PHY layer has finished processing the uplink or downlink sub-frames, it needs to inform the MAC layer that it has waited for the next sub-frame to be processed. The MAC layer gets the message sent by reading PHY_MAC_OLMQ, and when the message type is read_to_send, a dispatch operation is performed, mainly to configure the subframe resource;

3.2 MessageQueue Example

The upper layer sends a message to the queue through the Send function, with the following main procedures:

A) PHY layer instantiation object: Mac_comm_msgq=newlte_fdd_end_msgq ("MAC_PHY_OLMQ", CB);

b) The MAC layer defines the Boost object MAC_PHY_OLMQ and sends a message to the object queue:

1) mac_phy_olmq->send (&msg_sizeof (msg), 0)

2) lte_fdd_enb_msg::send (MAC_PHY_OLMQ;

The PHY layer invokes a callback function when instantiating a Mac_comm_msgq object:

Messageq->receive_thread->callback (that is, Handle_mac_message, and callback until the message that receives the stop parameter sent by the interface terminates processing) Handle_dl_schedulehandle_ul_schedule which:

Handle_dl_schedule handles downstream scheduling related operations, mainly to the MAC scheduler function has been assembled in the frame copy to a specific location, and provided to the subsequent PROCESS_DL function in the encapsulation user_data when used, the following code operation:

memcpy (&PDCCH.ALLOC[PDCCH. N_alloc],&dl_schedule[subfn].ul_allocations.alloc[i],

The purpose of Handle_ul_schedule is to encapsulate Phich. Because the Phich package requires scheduling information based on the MAC layer. The following comment are available:

for (i=0; i<ul_schedule[ul_subframe.num].decodes. N_alloc; i++)

{

Determine PHICH indecies

3.3 Lte_fdd_enb_msgq object Msgq and Boost object olmq

The layer m interacts with the neighboring N-layer, needs to define a M_N_OLMQ, and sends the message data to the M_N_OLMQ; The n layer defines a corresponding M_COMM_MESQ (the string name is M_N_OLMQ when instantiated), so that the n layer is in m_comm_ You can get the message data from the M layer in Mesq:

The following are examples:

To instantiate a boost object in the protocol layer MAC layer:

MAC_PHY_OLMQ = Newboost::interprocess::message_queue (boost::interprocess:open_only *

In the PHY layer, MSGQ is defined as follows:

mac_comm_msgq= new Lte_fdd_enb_msgq ("MAC_PHY_OLMQ", CB);

In the subsequent MSGQ (specialized Class) processing operation Receive_thread, the MSGQ string name corresponds to the boost of "MAC_PHY_OLMQ":

Boost::interprocess::message_queue MQ (Boost::interprocess::open_only,msgq->msgq_name.c_str ());

Not to be continued ... Welcome all of you are also concerned about this project friends pointing communication ~

Openlte Open source Code structure analysis (II.)