# Combined Access Barring Scheme for IoT Devices Using Bayesian Estimation
## 2 Random Access Procedure in LTE-A  
As mentioned earlier that the first step in getting access to the LTE-A network is the random access (RA). RA in LTE-A has two types namely contention free and contention based. In contention free RA, the devices have priorities and those devices do not contend for the channel. The channel is already reserved for them. But these devices form very small percentage of total number of devices. In practice, the general IoT devices do not have priorities. They need to contend for the channel for RA process to have a success. So that is why we chose contention based RA in our paper. This is where almost all of the devices lie and hence our choice is realistic. We consider only contention based RA in this paper and from here on, RA represent the contention based RA unless specified. RA process in LTE-A/5G is a four step procedure and depends on the exchange of four messages between IoT device and eNodeB as mentioned in release 15 [16]. As mentioned in release 16 [17], in 5G, the RA procedure consists of two steps in which 1 st and 3 rd message of four step process are combined to make 1 st message of two step RA process. Then 2 nd and 4 th message of four step RA are combined to make 2 nd message of two step RA process. Two step RA procedure helps in reducing delay in ultra reliable low latency communication (URLLC) applications [18]. As our proposed scheme can be applied any of the two, here we consider four step RA procedure. The eNodeB broadcasts (\(R\leq\) 64) RA preambles and then the four steps among IoT devices and eNodeB are as follows:  
* **RA preamble transmission:** At this step, each IoT device selects one of the \(R\) RA preambles and transmits it to the eNodeB along with its RA radio network temporary identity (RA-RNTI). eNodeB use this identity to further communicate with the IoT devices. It is possible that two or more IoT devices may select the same preamble and at this step, eNodeB is unaware of this scenario. * **RA response (RAR) message reception:** At this step eNodeB sends RAR message to the IoT device in response to the reception of Msg 1 from the corresponding device. If RAR is not received by the IoT device within a certain time (12 ms at maximum), it sends Msg 1 again. In addition, eNodeB assigns temporary cell RNTI (C-RNTI) to the IoT device for furhter communication. Other information such as timing advance, uplink grant resource etc is also provided to IoT device from eNodeB at this step. * **Connection request message transmission:** If RAR is received and decoded successfully by IoT device, it sends connection request message to eNodeB. This message contains temporary mobile subscriber identity (TMSI) along with other information. TMSI is requied by eNodeB for the transmission of the next message because it is possible that C-RNTI is assigned to more than one IoT devices by eNodeB if these devices have selected same preamble in first step. * **Contention resolution message reception:** If connection request message is received and decoded successfully by the eNodeB, it sends contention resolution to the IoT device. If contention resolution message is received and decoded by the IoT device, then RA process is said to have completed successfully after which scheduled access can take place. The whole process is presented in Figure 2.  
It is possible that more than one, say two, devices select same preamble. Then when both the IoT devices send connection request message to eNodeB, the eNodeB is unable to decode the message successfully and a collision happens. It is assumed that in the case of collision, eNodeB is not able to decode connection request message from either of the two devices. The eNodeB does not send contention resolution message to any of the collided IoT devices. After time out of their respective timers, the collided IoT devices declare that collision has happened and then start from Msg 1 again. Please note that eNodeB is unable to detect collision till reception of connection request message.