The 3D View command in Global Mapper allows registered users to view gridded elevation data and any overlying raster or vector data in a true perspective 3D manner. When selected, the 3D View command displays a window containing a 3D view of the data in the current Global Mapper view. Any imagery or vector data being drawn on top of the elevation grid(s) in the main Global Mapper view will automatically be draped on top of the elevation data in the 3D View window.The image below depicts a sample of the 3D View window displayed using 250K USGS DEM data for Salt Lake City, UT overlaid with DOQ satellite imagery from the TerraServer import command under the File menu. The 3D View window contains a toolbar with command buttons allowing you to modify the default view. You can use the mouse to rotate the view around as well as zoom in. The arrow keys on the toolbar allow you to pan the data visible in the 3D view in any direction. The zoom in and out buttons allow you to zoom in or out on the center of the 3D view. Additional buttons are also available for modifying the vertical exaggeration, displaying water, and saving the 3D view contents to a Windows BMP, TIFF, PNG, or JPG file.

The contents of the 3D View window will always reflect what is visible in the main Global Mapper view. This means that as you pan and zoom around the main Global Mapper view, the contents of the 3D View window will pan and zoom around as well. The reverse is also true in that the pan and zoom buttons on the 3D View window will cause the main Global Mapper view to pan and zoom as well. Another example of the 3D view is displayed below. This time, it is several 24K USGS DLGs for Blue Springs, MO overlaid on several 24K USGS DEMs for the same area.

The PathProfile/LOS command selects the 3D path profile/LOS (line of sight) tool as the current tool. This tool allows you to get a vertical profile along a user-specified path using loaded elevation datasets. In addition, registered users can perform line of sight calculations along the defined path. To define the path along which to generate the 3D path profile, first select the path profile tool as your current tool. Press and release the left mouse button at the position where you wish to start the path. Move the mouseto the next position that you want to include in the path profile, then press the left mouse button again. Right click on the last location in the path profile to complete selecting points and display the Path Profile/Line of Sight dialog (pictured below). The Path Profile/Line of Sight dialog will appear displaying the 3D path profile of the selected path. Any points along the path that did not have elevation data underneath will be treated as an elevation of zero. You can also generate 3D path profiles for existing line features by selecting the line feature in the Digitizer Tool, right clicking, then selecting the Generate Path Profile From Line option on the menu that is displayed.

The Path Profile/Line of Sight dialog displays the 3D path profile and provides several options related to the profile. A vertical scale is displayed on the left hand side of the profile window. The start and end coordinates of the path are displayed at the top of the profile window. If more than two points are in the path, the intermediate points will be marked in the profile window with a yellow dot. These intermediate points can be toggled on and off using an option available by right clicking on the path profile window. Also note that this dialog is resizable. Right clicking on the profile window brings up an options menu allowing the user to change the start and end positions, select the units (meters or feet) to display the elevations in, configure display of the path profile, and display a dialog containing details about the path. These options are also available under the Options menu on the dialog. The File menu contains options allowing you to save the path profile/line of sight data to a file. The individual options are described below. The Save To Bitmap... option allows registered users to save the contents of the path profile window to aWindows bitmap (BMP) file for use in other applications.

A vast majority of the operators are currently designing and dimensioning GPRS networks. Therefore, the operators are eager to get information on expected link bit rates achievable when introducing GPRS prior to the actual deployment. By introducing a new measure to TEMS Investigation, the users are pro- vided a means of estimating the expected GPRS downlink bit rates by per- forming measurements on a speech channel.

GPRS is a general packet radio service which is intended for GSM net- works. All logical channels, whether GPRS or GSM, use the same symbol modulation: Gaussian minimum shift keying (GMSK). In fact, the radio interface is not altered at all. Besides from different channel coding and different interleaving, the behaviour is very similar seen from a physical layer point of view. This has the implication that it is possible to perform measurements on a speech channel and estimate the performance on a cer- tain GPRS packet data traffic channel.

When GPRS is initially introduced, the interference encountered by GPRS users is typically dominated by speech users. Gradually, as the number of GPRS users increase, this assumption may become invalid. However, by performing measurements and predictions today, the results obtained are likely to reflect the scenario at the initial stage of GPRS deployment.

Each radio block in GPRS consists of four consecutive radio bursts. Each radio block carries 456 bits. These bits are used for data bits (payload), con- trol bits and in most cases some bits for channel error protection. The prob- ability of receiving an erroneous block depends on the current channel quality and the amount of channel protection. The achieved link bit rate is determined by the amount of data bits carried by the radio block, but also on the block error rate (BLER). GPRS provides four different coding schemes (CS). An illustration of the block error rates for CS-1 to CS-4 is shown in figure 1. It is clearly seen that CS-1 is most robust to poor channel quality.

Figure 1. Block Error Probability for different C/I ratios and coding schemes

Even though CS-1 is most robust at poor channel qualities, the peak bit rate for CS-1 is much lower than for example CS-4. Figure 2 shows the resulting link bit rates for the different coding schemes for varying channel qualities. Figure 2 assumes a two-time-slot mobile moving at 50km/h in a radio environment corresponding to a typical urban channel. For good qualities, that is high C/I levels, the peak bit rates are clearly seen. These peak rates are those which can be utilized by upper layer protocols.

Figure 2. Link bit rates for different C/I ratios and coding schemes

To be able to provide error free delivery of the radio blocks, a protocol for handling retransmissions is incorporated in GPRS. This is handled by the RLC protocol. Due to protocol limitations, such as limited transmitter win- dow size, it may happen that the transmitter becomes unable to transmit incoming radio blocks for periods of time. This is referred to as stalling of the protocol, and the implication is that the resulting link bit rate is reduced. Hence, the link bit rate does not only depend on the actual BLER, but also on the behaviour of the RLC protocol. This document does not further describe the background of stalling. For example, [1] describes stalling in detail.

Figure 3 illustrates the link bit rate reduction due to protocol stalling. The scenario shown assumes a two-slot mobile, a polling interval of 20 radio blocks and a round trip delay of 120ms. The results without regarding pro- tocol stalling is shown with dashed lines in figure 3. It can be seen that the link bit rate for CS-4 is reduced over almost the entire operating range. CS-1, on the contrary, is only affected for rather poor qualities.

Figure 3. Bit rate reduction due to protocol stalling. Results accounting for protocol stall- ing are shown with solid lines.

The estimation procedure is essentially performed by utilizing information from the physical layer. This information is produced by the mobile receiver and is collected for each received radio burst by using an ordinary GSM traffic channel. Utilizing information from four consecutive radio bursts, the block error probability (BLEP) for each of the coding schemes (CS-1 to CS-4) is estimated. The BLEP of a certain radio block is highly dependent on the distribution of errors over the corresponding four bursts. For example, consider two radio blocks (A and B) encountering the same mean quality. Further, assume that A has no variation during its four bursts, while B has one very poor burst but the other three bursts have quite good quality. If the mean quality is low, B yields a better block error probability than A thanks to interleaving. By using this high time resolu- tion information (burst-wise) makes it possible to obtain good accuracy of the estimation of the would-be performance.

Since there exists no real GPRS systems, the BLEP estimation procedure is derived based on computer simulations of the physical layer. Different radio environments, as well as different interference characteristics, are considered when developing the BLEP estimator.

Furthermore, as indicated in figure 3, the resulting link bit rate depends on the behaviour of the RLC protocol. In TEMS Investigation, the link bit rate estimation procedure also takes into account the parameters men- tioned in section 1. The number of time slots, round trip delay and polling interval are input by the TEMS user. In addition, it is also possible to replay a log file with an arbitrary protocol parameter setting to examine the impact of different system configurations. For example, the influence of different round trip delays is possible to examine by replaying a previ- ously recorded log file with varying round trip delay times.

To illustrate the usage of GPRS predictions, the results from a test drive in a live 1/1-reuse network is shown in figure 4. The number of hopping fre- quencies is 15 and the mobile speed is approximately 50km/h. The left plot shows the estimated throughput without considering RLC protocol stalling. The right plot shows the estimated link bit rates with the same assumptions regarding the RLC protocol as mentioned in section 2, that is, a two-slot mobile, 20 blocks polling interval and 120ms round trip delay. It is seen in figure 4 that CS-4 is clearly best when RLC limitations is not regarded. However, when the protocol limitations are taken into account the right plot reveals that CS-4 is no longer best suited. It is seen that CS-3 is best and it is also noted that CS-3 is not significantly better than CS-2.