Here's the hardware you will need for a desktop testing kit:
- A good clock reference with frequency stability no worse then 100ppb. ClockTamer is a good example of such reference clock.
- A computer running Linux or Mac OS X with a USB-2.0 port and libusrp installed. We recommend against Dell laptops because their hardware tends to couple a lot of noise into the USRP via the USB cables, at least in some models. We have had our best results with Apple PowerBooks and MacBooks. We have not tested a lot of desktop machines, but generally have had better success with them than with desktops. Virtual machines are not likely to work, nor is Cygwin. We would be interested in reports of what systems tend to work best.
- USRP daughter board:
- UHD distribution: Refer to [[OpenBTSExpandedDboard]USRP1 Expanded Daughterboard Support]] for details.
- SourceForge distribution: Two RFX900 daughter cards for GSM 850/900 operation. The ISM band filter on the RFX900 will need to be removed. A stock USRP with a 64 MHz crystal oscillator will not function correctly in the 1800/1900 bands, so there is no use for an RFX1800. You can convert your RFX1800 into an RFX900 with the command
burn-db-eeprom -A --force -t rfx900
- It's recommended to have two daughterboards boards to minimize crosstalk between the receive and transmit sections. When installing RFX daughter cards in the USRP, there will be an "A" board (installed on "TXA" and "RXA") and a "B" board (installed on "TXB" and "RXB").
OpenBTS will transmit on the "A" board, on the "TX/RX" connector.
OpenBTS will receive on the "B" board, on the "RX2" connector.
- Antennas with SMA connectors to fit the USRP and matched to whatever cellular band you intend to use. The VERT900 antenna, also available from Ettus works fine. Or just do a Google search for "cellular antenna SMA" and see what pops out. (You actually only need one antenna for desktop development work.)
- At least two GSM phones. Our preferred testing phone is a DCT-3 series Nokia. We say at least two phones, but for full-load testing of a single-ARFCN system you need seven.
- SIMs. Every phone needs a SIM. The requirements for the SIMs depend on the band in which you chose to operate and are discussed below.
Need a visual of that? Here's a laptop, USRP and a couple of DCT-3 test phones:
The recommended testing configuration is to operate in a cellular band not used in your area and use test phones that do not support your local cellular bands. This arrangement forces your test phone to camp to your basestation. It also prevents you from inadvertently attracting phones from the local licensed carriers. For example, to test in North America, you might use the EGSM900 band or the DCS1800 band and use a phone that does not support GSM850 or PCS1900.
If you do operate in a band that is also used by cellular carriers in your area, you will need to use SIMs from a carrier that does not offer service in you area and has no roaming agreements with carriers in your area. You can then use network parameters matched to the SIM and, hopefully, your test phones will ignore the local network and phones from your local network will ignore you.
If you do not operate in a band that is used by cellular carriers in your area, you can use any SIM you want.
If you want any flexibility at all in your choice of SIMs, you will need to use unlocked phones.
Be aware of power levels and local regulations. Here are some technical guidelines:
- Operate in a cellular band not used by your local carriers. This will reduce your likelihood of interfering with their service and will make your own test more controllable.
- Do not use a transmit antenna. Plenty of power leaks out of the USRP for close-range testing. In fact, using a transmit antenna causes a lot of transmit power to couple into the receiver, reducing receiver performance and limiting uplink range. (I realize that photo above shows two antennas, but you will get better results without the transmit antenna.)
- Do use a receive antenna. Remember that GSM uses active uplink power control. The more sensitive your receiver is, the less power the BTS will need to request from the phone.
- Keep the phones close to the USRP. Again, keeping the distance short (less than 2m) will allow the BTS to control the phone down to minimum power.
- Be aware of local radio applications and avoid their spectrum. This is especially important for air navigation and air traffic control radar systems. Perform a spectrum survey to know what frequencies are in use in your area. Check you regulator's licensing database to know who holds licenses in your area.
- Test indoors to limit propagation.
- Use a test phone with an RSSI display. You should not need received power levels above -80 dBm for desktop protocol testing.
However, these are only technical pointers to help you comply with your local regulations. They are not legal advice on the regulations themselves. That is entirely your responsibility.
To make your phone choose OpenBTS even if other networks try to steal your connection you should:
- Change your OpenBTS settings to show identity of some NON local operator, preferably some non-existent one, and start your OpenBTS.
- In your phone's menu find "Network selection" item somewhere in "Settings" menu. You sill see that it's set to "Automatic".
- Change item value to "Manual". Phone will start searching for available networks. It will take some time, be patient.
- When a window with available network operators appear, choose your OpenBTS network. It may hide under some strange name like "MCC 123 MNC 89" or "USA MNC 234" or with the name which is different from you set in OpenBTS.config, because phones use internal DB of MCC/MNC to operator name pairs and at this point just can't sense the name you set for OpenBTS in its config.
- From now on this phone will try to camp to OpenBTS ONLY until you change this in network settings to other manual network or to "Automatic".
PS If you change MCC&MNC in your OpenBTS setup, don't forget to update network settings in your test phones accordingly.