Monday, August 24, 2015

Optimization phase | Network Planning

Once the planning and implementation are complete, it is very common practice to run drive tests for the planned sites. Drive tests verify the predictions made by the planning tools, and the results from the drive tests are compared against the results from the simulations. Fine tuning is performed after the drive tests to ensure that the deviation in the results between simulation and drive tests is minimal.

A part of the drive test, parameters like reference signal receive power (RSRP), reference signal received quality (RSRQ), or SINR the UL and DL throughputs at different points of the cell are noted. The results are then compared with the SNR predictions made by the planning tool and deviations are noted and tuned wherever required.

Coverage Planning
Coverage planning targets for the complete service area are tested to ensure there are no coverage holes (i.e., the UE never experiences a no-service condition within the entire service area). Coverage plans, however, do not take into consideration any quality of service that the user experiences within a cell or site. The end aim is to provide the count of the resources or eNodeBs and cells that are required for the complete service area.

Some of the most important aspects that need to be considered as a part of the coverage planning are:

1.       The eNodeB transmitting power and the type of cell that is being planned. The eNodeB transmitting power is the key for any coverage planning, and the transmitting power will vary based on the cell size. For example, a macro cell will have a transmission power of 10 watts per port (40 watts per cell in cases of MIMO cells). The DL coverage cell radius should be derived based on the transmission power of the antenna added with the gains (antenna gain, diversity gain, etc.) with the assumption of path loss (receiver loss, propagation loss, etc.). Cell radius calculation will be covered in detail in the link budget calculation section.

2.       The eNodeB receiver sensitivity. In the uplink, in order to calculate the cell radius, one of the most important parameters that the operator relies on is the receiver sensitivity of the eNodeB. The eNodeB receiver sensitivity is a deciding factor for the maximum allowed path loss between the UE and the eNodeB in the uplink direction, beyond which the eNodeB cannot differentiate accurately between signal and noise. Better receiver sensitivity of the eNodeB will directly result in a larger cell radius (coverage radius) in the uplink. The 3GPP 36.141 defines the test for deriving the reference sensitivity of a receiver.

The specification also requires that a receiver sensitivity of less than -100.8 decibel milliwatts (dbm) is acceptable. However, many vendors have a receiver sensitivity value of around -102 dbm or better.

3.       UE receiver sensitivity and transmission power. Similar to the eNodeB receiver sensitivity, UE receiver sensitivity is an important factor in determining the DL cell radius for coverage planning. Typically for a macro cell, the UL cell radius will be a limiting factor in comparison with the DL cell radius simply because of the difference in the transmission powers. In LTE category 2 UE and onward, the maximum uplink transmit power is 23 db.

4.       Terrain. Terrain is an important consideration for any site planning and will impact the absorption or attenuation capability of a site. For example, a site with irregular heights will not have linear loss and is subjected to shadow areas or reflection, whereas a site with fairly regular height will have a more predictable linear loss. Similarly, the indoor to outdoor ratio of a site also makes a difference when it comes to cell radius calculation (i.e., the penetration losses for an indoor user is higher compared with that for an outdoor user); therefore, planning an urban cell will be subject to more losses due to a higher percentage of indoor to outdoor users in comparison with a rural cell.


Monday, May 28, 2012

Unsolicited Grant Service with Activity Detection



The UGS-AD algorithm is designed to support real-time service flows that generate fixed-size data packets on a semi-periodic basis (e.g., VoIP using on–off voice codec). It incorporates activity detection, which makes it suitable for use with on/off voice codecs. The algorithm uses combined features of UGS and rtPS. UGS-AD has two scheduling modes: UGS and rtPS, and can switch between these modes depending on the status of the voice users (on or off). On initialization of VoIP services, this algorithm starts with the rtPS mode. While in rtPS mode, if the voice user requests bandwidth size of zero bytes, the BS maintains this (rtPS) mode. However if the user requests bandwidth size greater than zero, the BS switches its mode to UGS. While in UGS mode, if the voice user requests bandwidth size = 0, the BS switches to rtPS, and if the user requestsbandwidth greater than zero, the BS stays in UGS. By switching between rtPS and UGS modes, the UGS-AD algorithm significantly addresses the problem of UL resources wastage in the UGS algorithm, and the MAC over head and access delay in the rtPS. This is however only for the case where the voice user uses voice codecs with only two data rates (on–off). Where voice codecs with variable data rates like EVRC is used, resources wastage still occur in the UGS-AD algorithm. In this case, the wastage occurs during the on duration, when full resources is assigned eventhough the variable data rate of voice codecs means that it will not operate at full rate for all of the time the resources is allocated. The operation of the UGS-AD algorithm is illustrated in Figure 1.



 
Figure 1: UL resource allocation using UGS-AD algorithm.

Thursday, May 24, 2012

Real-Time Polling Service | QoS Scheduling



The rtPS algorithm is designed to support real-time service flows, such as MPEG video or tele-conference, that generate variable size data packets periodically. In this algorithm, the BS assigns UL resources that are sufficient for unicast bandwidth request to the voice users. This is called the polling process. The duration for which the BS continues to poll an SS with rtPS connection is negotiated in the initialization process of the connection. The SSs utilize the assigned polling resources to send their bandwidth requests, reporting the exact bandwidth need for their rtPS connection. The BS in response then allocates the exact bandwidth requested to the SS for transmission of the data. Figure 1 illustrates this dynamic polling process.

 
Figure 1: Polling process in rtPS.
Because rtPS always carry out polling process, it is able to adaptively determine suitable resource allocation from frame to frame. This adaptive request-grant process goes on until the connection is terminated. Because of the dynamic request-grant process, the algorithm has more optimum data transport efficiency than the UGS algorithm. The algorithm is able to dynamically follow all data rate of the voice codec without any resource wastage as illustrated in Figure 2 (allocated and utilized resources are equal). This is a major advantage over the UGS algorithm. The drawback of the rtPS algorithm however is that the dynamic polling process causes MAC overhead and access delay. Hence rtPS has more MAC overhead and larger access delay than the UGS.

 
Figure 2: UL resource allocation using rtPS algorithm.
Related Posts with Thumbnails