Maximum number of users that can be served by an eNodeB per cell simultaneously ? 1* Hi I want to know the maximum number of users that can be served by an eNodeB per cell simultaneously knowing that I have two information: 1 - @ 10 MHz -> 50 RBs: A subscriber uses 2 RBs so 25 users / cell that can connect at the same time 2 - to 1 eNodeB Type BTS3900: Maximum users per cell = 1200 Active users (RRC connected) and I must enter the maximum number of user in the atoll software, I have not figured out which of these two numbers I use?
2* I think, Some of the RBs will be used for Signalling & Controlling also. That is also need to be considered. 3* A similar discussion has already taken place in the 3GPP Standards group here: http://www.linkedin.com/groups/Plz-anyone-help-me-How-1180727.S.217555082
4* the following tool can be used to calculate the number of PDSCH PRBs in any configuration: http://paul.wad.homepage.dk/LTE/pdsch_calc.html
5* Other key factors to be looked at are: 1.) the offered data-rate to the simultaneous connected users, and 2.) activity factor of the users Factor #1 will have a dependency on scheduler, and on RF conditions experienced by the user. Factor #2 will have a dependency on whether the assigned RB can be reused/shared amongst multiple users, and if so...how many. I reckon your concern is not about the offered data rate to the users, and are merely trying to gauge the total # users that can be served simultaneously. Considering Data-Only users and considering 3-sectors per eNB....the count of 50 is inaccurate. It will approach ~1k/eNB considering 10MHz BW and assuming 2x2 MIMO. (i.e. in the range of 300-400 users per sector)
6* This will also depend on the max number of tokens that can be assigned to Base Station.
there are many factors that limits the number of users at the eNodeB. one of the main factors are the the periodic SRS reporting. if the setting for Periodic SRS is very low (User has to report every 5ms for example) the number of users whom can be scheduled will be very low. this will cause RRC-reject by the eNodeB 7* assuming SRS is used, you have to check the periodicity, then calculate the maximum number of scheduled users. mostly, if we are talking about a 2012-released-eNodeB, you'll find the number high enough to match the maximum controllable RRC connections (400 or 1200 in your case)
8* Roughly 65000 users can be assigned unique C-RNTIs, so that's the closest to an absolute limit that I can come up with. I suppose the maximum number of users who could possibly be receiving traffic at any time is limited by the number of available resource blocks (1 per user), up to 1200 in a 20 MHz channel. I think the PDCCH can just about squeeze this many allocations in, give or take a couple hundred.
9* As example in question is Huawei product BTS3900, possible number of RRC Connected users is determined by LBBP board type (for LBBPd total number of those users is 3600 per board, if 1 board servs 3 cells, this gives metioned 1200 per cell). Approximately: How many users can be scheduled in 1 TTI? Let's check PDCCH capacity (20MHz, 2x2 MIMO, CFI=3, Hg=1/6, in frames when no transmission of SIBs, paging, RAR...): ((1200-400(Reference Signals in PDCCH area))+2*1200)-16(PCFICH symbols)-3*12(PHICH resources for 100RBs and Ng=1/6)=3148symbols=3148/4=787REGs or 787/9=87.4 CCEs~87CCEs. PDCCH has ratio 2:1 for DCIs for DL scheduling/UL scheduling (this can be adjusted dynamicaly if adjustment switch for DL/UL CCE ratio is ON on eNB). This means 58CCEs can be occupied with DCIs for DL scheduling, and 29 with DCI0 for UL scheduling. If each DCI occupy 1 CCE (best case), we can have 58 UEs scheduled for DL and 29 for UL transmission in 1ms on 20MHz from PDCCH limit. But, in this case, for Ng=1/6, 3 PHICH groups are available (8UEs per 1 group can recieve ACk/NACk for their UL transmission), so 3*8=24(<29) UEs can transmit in UL in 1ms. This UEs (if they are scheduled for DL transmission as well) can feedback ACK/NACK for DL transmission via PUSCH control symbols. Other UEs (59-24=35) need to use PUCCH to transmit ACK/NACk feedbach...
Anyway, this rough calculation shows that this number is smaller than RB number... @Mohammad: I believe you meaned 100 instead of 1200...
10* Since the question relates to design, you need to tell the planning tool how many users the eNB can serve at one instant of time and not haw many RRC connected users the eNB can have. Planning tools are time agnostic and all they need to know is how many users need to be served at an instant t0. For this reason you should go with the proposed #1 approach. However that number is still theoretical and you can get the practical number from the equipment manufacturer if they are willing to share it with you.
11* Obviously, it's a dynamic number when considering the wireless channel condition variability. Another important thing is that while with either ul or dl traffic, the signal consumption cannot be avoided such as measurement and HARQ. QoS and buffer size are also given the contribution to the scheduler priorities for UEs...
12* Number of Active users depends on Implementation of LTE system. Its challenge for LTE developers because stability depends on the number of active users in the system. In 3GPP spec's its not mentioned the number of active users supported by LTE system.
13* @Ljubisa & @Khader 100 seems a bit low. from what i'm seeing on live networks, some cells on 20MHz can handle up to 150 users. I've personally seen 200 users. you have to consider the aggregation level when it comes to PDCCH..
14* @Moh'd: I believe we probably didn't understood each other. My brief calculation was based on how many users can be simultaneously scheduled in 1 TTI. You will agree that in 1ms, 200 users can not be scheduled on 20MHz? May be 200 users in 1 cell can perform download "simultaneously", but not simultaneously on 1ms level. And if we include aggregation level of DCIs (1,2,4 or 8 CCEs) in calculation (even if it would be to complicated to calculate), our possible number of scheduled users in 1ms will even decrease compared with results from upper calculation. I considered only best case from capacity point of view (1 DCI takes 1 CCE), even if this is not possible even in theory.
15* @Ljubisa i believe the whole point of conflict here is returning to the main question of "users being served by the eNodeB". I agree totally with the theoretical calculation per TTI. however, we might have
to consider the varying scheduling times. not all users can be or will be scheduled for every TTI. As far as i recall, the limitation in this case (from downlink perspective) is for the eNodeB to be able to schedule the user within a frame (10ms)
16* @Moh'd: As main question "users being served by eNB simulteneously" is a bit general, for me, at least, is too difficult to realize all the limitations which eNB is facing to overcome when schedule many UEs. One is for sure: eNB must be able to accomplish configured maximum number of HARQ retransmissions to UE inside RLC reordering timer. On my equipment, maximum number of retransmissions is 4, and reordering timer is 50ms, so (including initial transmission), eNB must be able to schedule 1 UE 5 times in 50ms, which gives that eNB must be able to schedule 1 UE at least each 10ms, as you already mentioned... Someone from development side would probably be able to bring more light in this.
