All Phone

used to connect to database). If osql does not work in
the root directory, go to e.g. C:\MSSQL7\Binn\
directory first.
3. Type ‘use GSMSGW’ and press enter.
4. Type ‘go’ and press enter (go-command executes
previously given sql-clause).
5. Type “INSERT INTO SEND_QUEUE (TO_PHONE, MESSAGE) VALUES
(’+358407335153', ‘Test sending SMS’)” and press enter.
6. Type ‘go’ and press enter. If SMS Gateway is running an
SMS message should be sent to given phone. Phone numbers
have to be in international format.
7. You can exit osql by typing ‘exit’.
There is a PDF manual included in the evaluation version download. In the manual you can see examples how to access the database from e.g. a Visual Basic program or VB Script ASP pages by using ADO.
2) How to send SMS from a Visual Basic program?
Aspicore SMS Gateway uses a logical database called GSMSGW within MSSQL service. You need to insert your text messages into the SEND_QUEUE table in the database GSMSGW. You can do this from your application by executing an SQL “INSERT” statement as you execute any other MSSQL statements or queries. Example (if you have an active connection to the database GSMSGW):
INSERT INTO SEND_QUEUE (USER_ID, TO_PHONE, MESSAGE) VALUES (’Demo App’, ‘+358401234567', ‘Sample Message’)
Source code of a small VB 6 sample application is here.
Aspicore SMS Gateway takes care of sending the inserted message to the recipient via the connected GSM phone. No connection to a SMSC is required. You only need a compatible GSM phone, a data cable and a SIM card to the phone. The SIM card must have the SMS service activated, in some cases you need to make one voice call with a new SIM card before the SMS service gets activated.
3) How do I install SMS Gateway to use an existing SQL Server 7 database (or MSDE) that is located in another computer?
3.1) Choose custom setup intead of typical setup in the installation program. Uncheck MSDE component. Otherwise install normally.
3.2) When the setup program has finished, do not start Aspicore SMS Gateway yet. Go to folder C:\Program Files\Aspicore SMSGW\DB_Scripts\ (or the corresponding folder in your machine according to your setup). You should have a SQL script file named GSMSGW.sql in that folder. Run the script in the SQL server computer with osql.exe or with the Query Analyzer of the MS SQL Server.
3.3) Adjust the ConnectString in C:\Program Files\Aspicore SMSGW\Bin\GSMSGW.ini (or in the corresponding folder in your machine according to your setup). You should change the word “(local)” in the SERVER=(local) setting with the network name of the computer where your SQL database is running. E.g. SERVER=COMPANY_SERVER.
3.4) Now you can launch Aspicore SMS Gateway Interactive to finalize your configuration settings as described in the user’s manual.
4) One of the following messages appears in the operating system’s event log:
4.1) “Error: ProcessSendQueue: Problem polling database”
Action: Check that your SQL engine is running. (The service MSSQLServer status is “Started”.)
Check ConnectString in C:\Program Files\Aspicore SMSGW\Bin\GSMSGW.ini. Run the database creation script GSMSGW.sql again, if necessary. (It deletes all old data from the database GSMSGW.)
4.2) “Error: PollSIM: Problem with phone SIM card polling”
or
“Error: Framing Error”
The phone cable has probably been disconnected.
Action: Check that the phone is powered up and the cable is connected.
If the Aspicore SMS Gateway is running as a service: Stop the SMSGW service and start it again e.g. with the SMS Service Manager.
If you are using Aspicore SMS Gateway Interactive: Exit the application and start it again. Ensure that the GSM Device connection has been activated.
5) Error message dialog box “Problem polling database. Check your database connection and make sure that the SMSQLServer service is running.” when selecting “File…Connect GSM Device”
Possible cause: The standard Aspicore GSMSGW.ini file assumes that your security settings in Microsoft SQL Server are as follows: Authentication: “SQL Server and Windows”
If you are using the MSDE that was included in our package, there should not be a problem. However, if you are using an existing Microsoft SQL Server, you should check your security settings. Right click your SQL server in the Enterprise Manager tree view. Choose Properties. Choose tab “Security”.
Action: If your setting is “Windows only”, you need to modify the ConnectString in GSMSGW.ini as follows:
BEFORE CHANGES:
ConnectString=DRIVER=SQL Server; UID=SMS_GW; PWD=SMS_GW; DATABASE=GSMSGW; APP=Global SMS Gateway; SERVER=(local)
AFTER CHANGES:
ConnectString=DRIVER=SQL Server; UID=Administrator; Trusted_Connection=Yes; DATABASE=GSMSGW; APP=Global SMS Gateway; SERVER=(local)
Change the word Administrator above to the Windows user name, which you used for Windows login.
Or simpy delete the UID and PWD fields from the ConnectString as follows:
ConnectString=DRIVER=SQL Server; DATABASE=GSMSGW; APP=Global SMS Gateway; SERVER=(local)
6) “+CMS ERROR:28? or similar when trying to send SMS messages:
Action: Check your SMS Service Center number in the Aspicore SMS Gateway configuration.
7) Cannot receive SMS messages.
Action: Send one message first with the SIM card you are using for receiving. Sending one message may be necessary to activate the SMS service on your SIM card.
8) My evaluation software sends empty SMS messages.
Earlier evaluation versions used to add advertisement text starting with *Aspicore to every sent message. Some GSM operators treat messages starting with an asterisk (*) in a special way, which may cause the receiver to get an empty message.
Action: Download newer evaluation version. Version 1.2.27 (28.3.2002) does not any more add an asterisk (*) to the beginning of the sent messages.
9) Cannot use infrared interface to connect the phone with Aspicore SMS Gateway.
For serious use we recommend a GSM phone with serial cable or a GSM modem with serial cable. However, you can evaluate Aspicore SMS Gateway with a GSM phone, which only has an infrared interface. To do this, you need drivers, which make your PC’s infrared port to be seen as a virtual COM port. This is a bit tricky in Windows 2000. There are non-Microsoft Windows 2000 IrCOMM drivers around, which cause our software to hang. If your infrared port is not yet mapped as a virtual COM port, we recommend IrCOMM2k from from Jan Kiszka for Windows 2000 and Windows XP. Alternative try: Microsoft Knowledge Base Q252795.
10) Cannot connect to Nokia 5110 or Nokia 6110.
Have you got Nokia Data Suite 3.0 installed?
Make sure that you are using the correct COM port number in SMS Gateway Settings. You can check, which is the correct COM port number as follows:
Open the Windows Control Panel. Double-click the System applet. Activate the Hardware tab. Press the Device Manager button. Open the Modems node in the tree view. Double-click Nokia GSM Data 3.0. Activate the Modem tab. Now you see the COM port number, which Nokia Data Suite 3.0 is using for its virtual COM port. E.g. “Port: COM3?. You must use the same COM port number in Aspicore SMS Gateway settings. You must not use directly the physical COM port.
Make also sure, that neither the Hyperterminal nor any of the Nokia Data Suite 3.0 programs are running, when you are using the Aspicore SMS Gateway.
11) Database polling stops with Nokia Data Suite.
Normally there is a blinking message “Database: Polling” in the status panel of SMS Gateway Interactive. In the version 1.2.29 this message stops blinking in certain cases with Nokia phones and says instead: “Database: Not polling”. At the same time, a new message appears in the application event log. The end of the event message says: “OnComm: GSM device was unplugged or power was switched off. Please check your GSM device.”
This issue concerns you, if your version of AspicoreSMSGW.exe is 1.2.0.29 and you are using a Nokia phone or especially Nokia Data Suite. The cause of the error is, that version 1.2.29 monitors the COM port handshake signals trying to detect low battery or cable disconnection/reconnection situations. Especially Nokia Data Suite seems to generate short peaks to the DSR handshake signal level causing SMS Gateway to stop database polling.
Action: Download newer evaluation version. Version 1.2.30 (14.5.2002) does not halt database polling based on the handshake signal levels.
12) Example of using database triggers.
Here is an example of using triggers in SQL. This example simply sends an autoreply message to the same GSM number from which it received an SMS containing the keyword ‘TEST’ in the beginning of the message.
Aspicore SMS Gateway stores the incoming message first to RECEIVE_QUEUE and then it copies the same information to the RECEIVE_HISTORY table. The trigger should be created to the RECEIVE_HISTORY table instead of RECEIVE_QUEUE, because otherwise the trigger will interfere the copying process done by Aspicore SMS Gateway.
Here is the script:
USE GSMSGW
GO
CREATE TRIGGER [TEST_TRIGGER] ON [RECEIVE_HISTORY] FOR INSERT AS
IF EXISTS (SELECT * FROM INSERTED WHERE MESSAGE LIKE ‘TEST%’)
BEGIN
INSERT INTO SEND_QUEUE (USER_ID, TO_PHONE, MESSAGE)
SELECT ‘AutoReply’, INSERTED.FROM_PHONE,
‘Thank you for using Aspicore SMS Gateway.’ FROM INSERTED
END
GO
Save this to a file and run it from command prompt with osql-program:
osql -E -e -i C:\temp\CreateTestTrigger.sql
The example is rather simple, but you’ll get the idea of using triggers. You can easily add e.g. some SELECT-clauses instead of the automated autoreply ‘Thank you for…’-message to fetch some data from other database table and then send this data back with sms (you just have to make sure that SMS_GW database user has all the necessary permissions to access these tables).
WARNING: If an error occurs in your trigger code, the database engine does automatically a rollback for the whole enclosing transaction. This means, that the INSERT INTO RECEIVE_HISTORY statement, which Aspicore SMS Gateway internally tries to execute, will be cancelled. Keep you trigger routine as simple and fail-safe as possible! A failure in the trigger code can affect the normal operation of Aspicore SMS Gateway.
13) Error at the command line “AT+CMGF=1?.
Symptoms: When you press the “Test” button on the “GSM Settings” page, the modem replies with an error to the command “AT+CMGF=1?.
Cause: The SMS Gateway uses “Text Mode” message format when it communicates with the GSM modem. You must use a GSM phone or modem supporting “Text mode” (According to the GSM standard 07.05) to be able to successfully execute the “AT+CMGF=1? command. Some GSM phones support only “PDU mode”.
You can list the modes your phone supports by giving the command “AT+CMGF=?” e.g. with HyperTerminal or with SMS Gateway menu option File / Diagnostics. The GSM modem replies with a list of supported modes. The value 0 represents PDU mode and the value 1 text mode. The list must contain the value 1, if the phone is going to be used with Aspicore SMS Gateway.
14) Aspicore SMS Gateway version history
You can find Aspicore SMS Gateway version history from here.
15) Aspicore SMS Gateway sends the same message over and over again
This is a known problem in version 1.2.33 and earlier, when something causes a primary key violation in the SEND_HISTORY table.
Symptoms: Aspicore SMS Gateway isn’t deleting the messages in the SEND_QUEUE table, and as a result, it sends the same message over and over again until someone manually deletes the message from the database.
Cause: If there for some reason already exists a duplicate record with the same ID in the SEND_HISTORY table, then the procedure within the gateway, which tries to delete the already sent message from the SEND_QUEUE, might fail. (The procedure first tries to add the record into SEND_HISTORY and then delete it from SEND_QUEUE.)
Solution: Delete all the records from the SEND_HISTORY table.
16) Using Nokia 9210 Communicator
You must activate the Fax modem application behind the Extras button of Nokia 9210, before you can use the Communicator with Aspicore SMS Gateway.
We have used 9210 with the following settings in the 9210 Fax modem application:
Connection type: Cable 19200
Status: Active
Note, that status must be ACTIVE! (In the Fax modem main view, press ACTIVATE button.) (There is an inactivity timeout of 20 minutes in the Nokia 9210 Fax modem activation.)
(Further settings in our Nokia Fax modem application:
8 data bits,
Operating system: Windows 2000 > No
Note, that we have Windows 2000 setting as NO in our Nokia 9210, although in fact our PC is running Windows 2000.)
17) Beware of the Slammer Worm
Aspicore SMS Gateway installs MSDE 1.0 into your computer by default. This database engine is vulnerable to the very aggressively spreading W32.Slammer virus, if you have a direct connection to the Internet and do not apply protective measures.
The Slammer virus does not destroy your data, but it blocks your network with a denial of service attack and starts immediately spreading itself to the neighboring unprotected systems. Luckily the virus can be removed relatively easily.
To protect your system against worm attacks, it is highly recommended to use a firewall between your SMS Gateway computer and the Internet. To isolate Slammer attacks, you should block incoming and outgoing UDP port 1434 packets at your firewall.
It is also recommended to install the security patch for Microsoft SQL Server 7.0 as instructed in Microsoft Security Bulletin MS02-061. This patch makes the system immune to the Slammer worm.
How to know, if a MSSQL system has been patched against the Slammer virus? You can resolve, whether your system is up to date by executing the following SQL statement:
SELECT @@VERSION
You can execute this e.g. either with the MS SQL Server Query Analyzer or with the osql.exe utility. The latter is included with MSDE 1.0.
The MSSQL7 engine, which has been fixed with MS02-061 responds with version number 7.00.1077. On the other hand, the SQL Server 2000 with SP3 (including Slammer protection) responds with version number 8.00.760.
More information about Slammer worm can be found at PSS Security Response Team Alert - New Worm: W32.Slammer

You do not need to worry about Slammer even without any extra measures, if
* you are constantly disconnected from the Internet or if
* you are connected to a LAN, which is properly protected by a firewall.
18) SMS Gateway stops receiving SMS messages.
Symptoms:
*When started, SMS Gateway stores received SMS messages into the RECEIVE_QUEUE table, as it should. After the program has been running for some time, receiving stops working while sending out messages still work.
You can resume the receiving function by giving command “File”/”Disconnect GSM Device”, turning the power off from your GSM device and back on again and then giving command “File”/”Connect GSM Device”
* Occassionally SMS Gateway inserts AT commands into sent messages
Cause:
An SMS message has been received at the same time as another SMS message was being sent. This occassionally caused lost messages or corrupted sent messages with the default settings of version 1.2.33 and earlier.
If the value of the New Message Indication paramater in the GSM Settings tab of the Settings window is 1, then the GSM device rejects received message, if it is received exactly the same time while another message is being sent by the SMS Gateway. Afterwards, the operator’s SMSC starts buffering the subsequent received messages and does not send them to your GSM device until you make the “Disconnect” and “Connect” maneuver described above.
SMS Gateway version 1.2.33 and earlier had a bug, which in some rare cases caused corruption of the message being sent, if another message was received almost the same time.
Action:
Set the value of 2 to the New Message Indication paramater in the GSM Settings tab of the Settings window. (You can also change this value by editing the file GSMSGW.ini with a text editor like Notepad. Edit the row “Mode=1? to be “Mode=2?.) Check that your GSM device accepts the new value by observing the Receive History window during the “Connect GSM Device” function. The GSM device should answer OK to the AT+CNMI command
Make note of your SMS Gateway registration info from the register menu. Uninstall your current version. Download version 1.2.44 or above from Aspicore web site. Install the new version and enter the same registration data as in the previous version.
19) Allowed COM port range.
If you cannot see your USB cellular modem COM port in the Aspicore SMS Gateway communications settings drop-down list box, check the COM port number from Windows Device Manager / Modems node, double-click your cellular modem name, activate the Modem tab. If the COM port number is greater than 16, try uninstalling your cellular modem driver and reinstalling the driver so that the COM port number becomes between COM 1 and COM 16.
Only COM port numbers between 1 and 16 are supported by Aspicore SMS Gateway.
If none of the above points helped, you can send us the following three files:
* C:\Program Files\Aspicore SMSGW\DB_Scripts\Create_SMSGW_Database.log
* C:\WINNT\SMSGW_SETUP.log
* C:\Program Files\Aspicore SMSGW\Bin\GSMSGW.ini
they may contain some information, which helps us detecting further your problem.

Cell-phone viruses are at the threshold of their effectiveness. At present, they can't spread very far and they don't do much damage, but the future might see cell-phone bugs that are as debilitating as computer viruses. In this article, we'll talk about how cell-phone viruses spread, what they can do and how you can protect your phone from current and future threats.
Cell-phone Virus Basics
A cell-phone virus is basically the same thing as a computer virus -- an unwanted executable file that "infects" a device and then copies itself to other devices. But whereas a computer virus or worm spreads through e-mail attachments and Internet downloads, a cell-phone virus or worm spreads via Internet downloads, MMS (multimedia messaging service) attachments and Bluetooth transfers. The most common type of cell-phone infection right now occurs when a cell phone downloads an infected file from a PC or the Internet, but phone-to-phone viruses are on the rise.
Current phone-to-phone viruses almost exclusively infect phones running the Symbian operating system. The large number of proprietary operating systems in the cell-phone world is one of the obstacles to mass infection. Cell-phone-virus writers have no Windows-level marketshare to target, so any virus will only affect a small percentage of phones.
Infected files usually show up disguised as applications like games, security patches, add-on functionalities and, of course, pornography and free stuff. Infected text messages sometimes steal the subject line from a message you've received from a friend, which of course increases the likelihood of your opening it -- but opening the message isn't enough to get infected. You have to choose to open the message attachment and agree to install the program, which is another obstacle to mass infection: To date, no reported phone-to-phone virus auto-installs. The installation obstacles and the methods of spreading limit the amount of damage the current generation of cell-phone virus can do.
Protecting Your Phone
The best way to protect yourself from cell-phone viruses is the same way you protect yourself from computer viruses: Never open anything if you don't know what it is, haven't requested it or have any suspicions whatsoever that it's not what it claims to be. That said, even the most cautious person can still end up with an infected phone. Here are some steps you can take to decrease your chances of installing a virus:
Turn off Bluetooth discoverable mode. Set your phone to "hidden" so other phones can't detect it and send it the virus. You can do this on the Bluetooth options screen.
Check security updates to learn about filenames you should keep an eye out for. It's not fool-proof -- the Commwarrior program generates random names for the infected files it sends out, so users can't be warned not to open specific filenames -- but many viruses can be easily identified by the filenames they carry. Security sites with detailed virus information include:
F-Secure McAfee Symantec
Some of these sites will send you e-mail updates with new virus information as it gets posted.
Install some type of security software on your phone. Numerous companies are developing security software for cell phones, some for free download, some for user purchase and some intended for cell-phone service providers. The software may simply detect and then remove the virus once it's received and installed, or it may protect your phone from getting certain viruses in the first place. Symbian has developed an anti-virus version of its operating system that only allows the phone's Bluetooth connection to accept secure files.
Although some in the cell-phone industry think the potential problem is overstated, most experts agree that cell-phone viruses are on the brink of their destructive power. Installing a "security patch" that ends up turning your phone into a useless piece of plastic is definitely something to be concerned about, but it could still get worse. Future possibilities include viruses that bug phones -- so someone can see every number you call and listen to your conversations -- and viruses that steal financial information, which would be a serious issue if smartphones end up being used as payment devices (see Bankrate.com: Paying by cell phone on the way). Ultimately, more connectivity means more exposure to viruses and faster spreading of infection. As smartphones become more common and more complex, so will the viruses that target them.

Cell Phone Codes
Electronic Serial Number (ESN) - a unique 32-bit number programmed into the phone when it is manufactured
Mobile Identification Number (MIN) - a 10-digit number derived from your phone's number
System Identification Code (SID) - a unique 5-digit number that is assigned to each carrier by the FCC
While the ESN is considered a permanent part of the phone, both the MIN and SID codes are programmed into the phone when you purchase a service plan and have the phone activated.
When you first power up the phone, it listens for an SID (see sidebar) on the control channel. The control channel is a special frequency that the phone and base station use to talk to one another about things like call set-up and channel changing. If the phone cannot find any control channels to listen to, it knows it is out of range and displays a "no service" message.
When it receives the SID, the phone compares it to the SID programmed into the phone. If the SIDs match, the phone knows that the cell it is communicating with is part of its home system.
Along with the SID, the phone also transmits a registration request, and the MTSO keeps track of your phone's location in a database -- this way, the MTSO knows which cell you are in when it wants to ring your phone.
The MTSO gets the call, and it tries to find you. It looks in its database to see which cell you are in.
The MTSO picks a frequency pair that your phone will use in that cell to take the call.
The MTSO communicates with your phone over the control channel to tell it which frequencies to use, and once your phone and the tower switch on those frequencies, the call is connected. Now, you are talking by two-way radio to a friend.
As you move toward the edge of your cell, your cell's base station notes that your signal strength is diminishing. Meanwhile, the base station in the cell you are moving toward (which is listening and measuring signal strength on all frequencies, not just its own one-seventh) sees your phone's signal strength increasing. The two base stations coordinate with each other through the MTSO, and at some point, your phone gets a signal on a control channel telling it to change frequencies. This hand off switches your phone to the new cell.
Let's say you're on the phone and you move from one cell to another -- but the cell you move into is covered by another service provider, not yours. Instead of dropping the call, it'll actually be handed off to the other service provider.
If the SID on the control channel does not match the SID programmed into your phone, then the phone knows it is roaming. The MTSO of the cell that you are roaming in contacts the MTSO of your home system, which then checks its database to confirm that the SID of the phone you are using is valid. Your home system verifies your phone to the local MTSO, which then tracks your phone as you move through its cells. And the amazing thing is that all of this happens within seconds.

The less amazing thing is that you may be charged insane rates for your roaming call. On most phones, the word "roam" will come up on your phone's screen when you leave your provider's coverage area and enter another's. If not, you'd better study your coverage maps carefully -- more than one person has been unpleasantly surprised by the cost of roaming. Check your service contract carefully to find out how much you're paying when you roam.
Note that if you want to roam internationally, you'll need a phone that will work both at home and abroad. Different countries use different cellular access technologies. More on those technologies later. First, let's get some background on analog cell-phone technology so we can understand how the industry has developed.

Make task or to-do lists
Keep track of appointments and set reminders
Use the built-in calculator for simple math
Send or receive e-mail
Get information (news, entertainment, stock quotes) from the Internet
Play games
Watch TV
Send text messages
Integrate other devices such as PDAs, MP3 players and GPS receivers
But have you ever wondered how a cell phone works? What makes it different from a regular phone? What do all those terms like PCS, GSM, CDMA and TDMA mean? In this article, we will discuss the technology behind cell phones so that you can see how amazing they really are. If you are thinking about buying a cell phone, be sure to check out How Buying a Cell Phone Works to learn what you should know before making a purchase.
To start with, one of the most interesting things about a cell phone is that it is actually a radio -- an extremely sophisticated radio, but a radio nonetheless. The telephone was invented by Alexander Graham Bell in 1876, and wireless communication can trace its roots to the invention of the radio by Nikolai Tesla in the 1880s (formally presented in 1894 by a young Italian named Guglielmo Marconi). It was only natural that these two great technologies would eventually be combined.
Cell-phone Frequencies
In the dark ages before cell phones, people who really needed mobile-communications ability installed radio telephones in their cars. In the radio-telephone system, there was one central antenna tower per city, and perhaps 25 channels available on that tower. This central antenna meant that the phone in your car needed a powerful transmitter -- big enough to transmit 40 or 50 miles (about 70 km). It also meant that not many people could use radio telephones -- there just were not enough channels.
The genius of the cellular system is the division of a city into small cells. This allows extensive frequency reuse across a city, so that millions of people can use cell phones simultaneously.
A good way to understand the sophistication of a cell phone is to compare it to a CB radio or a walkie-talkie.
Full-duplex vs. half-duplex - Both walkie-talkies and CB radios are half-duplex devices. That is, two people communicating on a CB radio use the same frequency, so only one person can talk at a time. A cell phone is a full-duplex device. That means that you use one frequency for talking and a second, separate frequency for listening. Both people on the call can talk at once.
Channels - A walkie-talkie typically has one channel, and a CB radio has 40 channels. A typical cell phone can communicate on 1,664 channels or more!
Range - A walkie-talkie can transmit about 1 mile (1.6 km) using a 0.25-watt transmitter. A CB radio, because it has much higher power, can transmit about 5 miles (8 km) using a 5-watt transmitter. Cell phones operate within cells, and they can switch cells as they move around. Cells give cell phones incredible range. Someone using a cell phone can drive hundreds of miles and maintain a conversation the entire time because of the cellular approach.
In a typical analog cell-phone system in the United States, the cell-phone carrier receives about 800 frequencies to use across the city. The carrier chops up the city into cells. Each cell is typically sized at about 10 square miles (26 square kilometers). Cells are normally thought of as hexagons on a big hexagonal grid
Each cell has a base station that consists of a tower and a small building containing the radio equipment. We'll get into base stations later. First, let's examine the "cells" that make up a cellular system

Since the DMTF's Desktop and Mobile Working Group (DMWG) was announced, the group has attracted more than 180 members from over different companies, demonstrating a strong commitment by vendors and users across the industry to collaborate on this effort. Statements of support for the new DASH Initiative have been provided by AMD, Avocent, Broadcom, Dell, HP, IBM, Intel, Microsoft, Novell, NVIDIA, Symantec, and WBEM Solutions.
DMTF's Web Services for Management (WS-Management) specification (DSP0226) describes a general SOAP-based protocol for managing systems such as PCs, servers, devices, Web services and other applications, and other manageable entities. Its goal is to: (1) Constrain Web services protocols and formats so that Web services can be implemented with a small footprint in both hardware and software management services' (2) Define minimum requirements for compliance without constraining richer implementations; (3) Ensure composability with other Web services specifications; (4) Minimize additional mechanisms beyond the current Web service architecture.
The common set of operations defined by WS-Management as central to all systems management supports facilities to [i] Get, put (update), create, and delete individual resource instances, such as settings and dynamic values; [ii] Enumerate the contents of containers and collections, such as large tables and logs; [iii] Subscribe to events emitted by managed resources; [iv] Execute specific management methods with strongly typed input and output parameters.
For addressing, WS-Management uses WS-Addressing endpoint references (also known as EPRs) as the addressing model for individual resource instances. WS-Management also defines a default endpoint reference format for use in addressing resources. In cases where this default addressing model is not appropriate, such as systems with well-established EPR formats or with opaque EPRs retrieved from a discovery service, services may use those service-specific addressing models, as long as they are based on WS-Addressing.
According to the published DASH Technical Note as detailed in the White Paper, "The WS-Management protocol stack for DASH is based on the Web Services. The network and physical layers are the two bottommost layers in the stack. The transport layers that carry SOAP messages are next in the stack. These layers include TCP, which provides reliable, stream-oriented data transport; TLS, which provides various security attributes, and HTTP 1.1, which provides user authentication and request-response semantics. TCP and HTTP 1.1 are required by DASH. TLS support is conditional on support for security profiles that require it. At the next layer, SOAP/XML messaging is handled. The security profiles specified in the DASH Implementation Requirements Specification define the security mechanisms required. Above the SOAP/XML layer is the data transfer layer, which is based on multiple Web Services specifications. These are WS-transfer, WS-Enumeration, and WS-Eventing for transferring the management information. The top three layers represent the WS-Management applications. The DASH profiles are mapped over the WS-Management protocol stack using the WS-Management CIM Binding. Protocol stack for DASH:
A key benefit of the DASH Initiative is that it delivers more secure desktop and mobile management. DASH embraces industry standard network and transport layer encryption, authentication, and authorization mechanisms, and establishes standard profiles for roles, authorization, and account management. The authorization and access control is based on the roles assigned, and privileges associated with, the user accounts. Operational roles include 'Read only User,' which allows a user to only perform query and read operations on the managed elements; 'Operator,' which permits a user to perform read, write, and execute operations on the managed elements; and 'Administrator,' which adds to the operator role capabilities to perform user account management."
DASH Architecture
Excerpts from Systems Management Architecture for Mobile and Desktop Hardware White Paper. Version 1.0.0a/Version 1.0.01i. Status: Informational. Publication Date: February 26, 2007. Reference: DSP2014.
The Desktop and mobile Architecture for System Hardware (DASH) is a DMTF Management Initiative that represents a suite of specifications which standardize the manageability interfaces for mobile and desktop hardware. The DASH suite of specifications defines the interfaces for management in the form of protocols and profiles for representing mobile and desktop hardware. This document is an architectural white paper and describes the concepts used in managing mobile and desktop platforms which adhere to the DASH Implementation Requirements.
The document lays forth the basic principles required for understanding and implementing the DMTF Web Services for Management (WS-Management) interface as applied to this environment. The framework is composed of technologies defined in multiple standard specifications, including the WS-Man Specification, the DASH Implementation Requirements Specification, and a variety of profiles (Section 7) which are applicable to this environment. The focus of this architecture is to enable the management of desktop and mobile computing re-sources in a standard manner across any Manageability Access Point implementation, independent of operating system state.
DASH contains the models, mechanisms, and semantics necessary to manage mobile and desktop computers in use today, independent of service state. This includes the architectural, service and operations models, and covers boot and firmware update as well as service discovery. The profiles contain the required classes, instances, properties and methods necessary to manage systems. The transport and management protocols allow implementers to determine the communication requirements for compliant systems. Discovery and security requirements described help to understand their aspects in relation to the profiles and protocols. And the use cases should help implementers understand the communications that take place in certain circumstances. All of these combine in DASH to deliver the syntax and semantics necessary to manage desktop and mobile computer systems.
Architecture Overview: Desktop and mobile systems management in today's enterprise environments is comprised of a disparate set of tools and applications which administrators can use to manage the multitude of networked desktop and mobile computers. In many cases, these tools are specialized and adapted to each individual environment, installation and product in the environment. Currently, the CIM Schema provides a feature-rich systems management environment. In its cur-rent form, it also places a burden on those vendors attempting to implement the CIM Schema and CIM-XML Protocol to support systems hardware management. This has resulted in lack of inter-operability and acceptance of solutions in the desktop and mobile systems hardware management solution space, particularly in the out-of-band and out-of service cases. In addition, the resulting Out-of-Band and Out-of-Service management solutions are different from the operating system's representation and management of the system. The Desktop and mobile Architecture for System Hardware (DASH) Management Initiative supports a suite of specifications which include architectural semantics, industry standard proto-cols and a set of profiles to standardize the management of desktop and mobile systems independent of machine state, operating platform or vendor. By creating industry standard protocols, interoperability is facilitated over the network and the syntax and semantics of those protocols are facilitated to be interoperable by products which adhere to those standards. Because it is based on the CIM Schema, the DASH Management Initiative leverages the richness of CIM. By creating industry standard profiles, the richness of the CIM Schema can be applied in a consistent manner by all vendors.
Extra emphasis has been placed in the development of DASH to enable lightweight implementations which are architecturally consistent. This has been done to enable a full spectrum of implementations without sacrificing the richness of the CIM heritage. This includes software-only solutions and small footprint firmware solutions. Emphasis has been placed on ensuring that these implementations will be interoperable, independent of implementation, CPU architecture, chipset solutions, vendor or operating environment.
Management Protocol: DASH supports the Web Services for Management Protocol, as defined in the WS-Management Specification, as the management protocol for transporting DASH messages. WS-Management is a specification of a core set of Web Services to expose a common set of system management operations...
The three data transfer models used by DASH and WS-management are:
WS-Transfer: defines a mechanism for acquiring XML-based representations of entities. It defines the following resource operation using SOAP messages.
Get: is used to fetch a one-time snapshot representation of a resource.
Put: is used to update a resource by providing a replacement representation.
Create: is used to create a resource and provide its initial representation.
Delete: is used to delete a resource.
WS-Management in addition defines the rename operation and fragment level transfer for fragment-level access of resources.
WS-Enumeration: is a SOAP-based protocol for enumeration. Using this protocol, the data source can provide a session abstraction called the enumeration context. The consumer can then request XML element information over a span of one of more SOAP messages using the enumeration context. The enumeration context is represented as XML data. The following operations (defined as SOAP request/response messages) are supported using this model
Enumerate: to initiate an enumeration and receive an enumeration context.
Pull: to pull a sequence of elements of a resource.
Release: to release an enumeration context (graceful).
WS-Eventing: is a SOAP-based protocol for one web service to register interest and receive messages about events from another web service. The operations supported by WS-Eventing include Subscribe, Renew, GetStatus, Unsubscribe, and SubscriptionEnd. WS-Management defines heartbeats as pseudo-events. WS-Management also defines a book-mark mechanism for keeping a pointer to a location in the logical event stream. The delivery modes defined for events are: Push, Push with Acknowledgement (PushWithAck), Batched, and Pull.
Standardized Message Content: In order to foster greater interoperability between different implementations of management instrumentation and the applications that subscribe for and receive events, a set of standardized event message content has been defined. The event message content is specified in XML documents according to the DMTF Message Registry Schema. Message Registry entries consist of definitions for a message ID, message string, message arguments, perceived severity, and defining organization. Each Message in a registry represents a particular event type. DASH 1.0 uses message registries for the Message IDs, perceived Severity and interpretations of MessageArgs for each MessageID..."
From the DASH Announcement
Excerpts from the DMTF announcement March 22, 2007: "DMTF Announces DASH Initiative. Leading Technology Standards Body Delivers Innovative Framework for the Management of Desktop and Mobile Systems."
The Distributed Management Task Force, Inc. (DMTF), the industry organization leading the development, adoption and promotion of interoperable management initiatives and standards, today announced details of its Desktop and Mobile Architecture for System Hardware (DASH) Initiative — a forthcoming suite of specifications that takes full advantage of the DMTF's Web Services for Management (WS-Management) specification — delivering standards-based Web services management for desktop and mobile client systems. Through the DASH Initiative, the DMTF will provide the next generation of standards for secure out-of-band and remote management of desktop and mobile systems.
As outlined in a white paper released today, the DASH Initiative will deliver a set of specifications that provides architectural semantics, industry standard protocols and a set of profiles to standardize the secure management of desktop and mobile systems independent of machine state, operating platform or vendor. By tapping into the power of WS-Management, which enables a common way for systems to access and exchange management information across the entire IT infrastructure, DASH integrates desktop and laptop management into an end-to-end management solution. In addition, DASH works in concert with the DMTF's widely-implemented Common Information Model (CIM), so that it is easily incorporated into existing management environments.
"Since the DMTF's Desktop and Mobile Work Group (DMWG) was announced, the group has attracted more than 180 members from over 35 different companies, reflecting enormous support from the industry," said Winston Bumpus, president, DMTF. "The result is DASH, a significant step forward that utilizes the latest technologies to provide an advanced framework for desktop and mobile management. By delivering an interoperable approach and relief for this key pain point in the distributed enterprise, DASH will facilitate new levels of efficiency and help reduce costs."
Industry Support for DASH
Broadcom
"As an original founder, a long-time driver and a key contributor to the DMWG and the DASH Initiative, Broadcom is committed to providing standard-based management solutions to our enterprise customers," said Greg Young, vice president and general manager of Broadcom's High-Speed Controller line of business. "As a result, Broadcom is one of the first in the industry to provide DASH solutions in 2007 as part of our industry-leading line of Gigabit-Ethernet controller chips. Our support for DASH reinforces our commitment to the DMTF standards and to driving emerging standard-based technology."
Dell
"Dell is a founder and co-chair of the DMTF Desktop and Mobile Working Group because we want to help customers simplify systems management," said Margaret Franco, director, Dell business desktops. "DASH specifications, along with standards-based hardware, like Dell Precision workstations, OptiPlex desktops and Latitude notebooks, will deliver advanced systems management capabilities, support richer IT usage models and help customers manage costs."
HP
"This industry-wide DASH effort will further HP's goal of reducing the total cost of technology ownership for business customers," said Alan Reed, vice president, Business PC Research and Development, HP. "The advancement and standardization of Web services-based management will solve some of the most difficult client management scenarios by enabling always-available, secure, and agentless management on HP Compaq business desktop, notebook and workstation platforms."
IBM
"DASH is a great complement to IBM Director and our suites of industry-leading systems management tools," said Dr. Tom Bradicich, IBM Fellow and vice president, Systems Technology, Blade, Rack and x86 Servers. "By leveraging DMTF Management Profiles, the DASH Initiative will provide advanced manageability of client systems."
Intel
"As a leader in industry standards for PC manageability for over two decades and as a founding member of the DMTF, Intel supports DASH as another advancement for IT as we move into the WS-Management era," said Gregory Bryant, vice president and general manager of Intel's Digital Office Platform Division. "Intel vPro technology was originally designed to support a seamless transition to this new standard, and our 2007 product roadmap enables one of the industry's first DASH and WS-Management supported enterprise PCs through our next-generation Intel vPro technology."
Microsoft
"Microsoft is excited to see DASH and the WS-Management standard introduce XML Web services into the arena of desktop and mobile management," said Larry Orecklin, general manager of System Center marketing, Microsoft. "We have been a strong advocate of standards, such as WS-Management, as part of our Dynamic Systems Initiative (DSI) and have accelerated the adoption of these technologies in Windows Vista and our System Center family of management solutions."
Novell
"With an ever growing mobile work force, secure Web services-based management is critical to keeping cost and complexity in check," said Alan Murray, vice president of product management at Novell. "The DASH specifications will provide Novell systems management solutions with a consistent interface for managing software and hardware assets for desktops and mobile devices."
Symantec
"Interoperable, secure, and functionally rich management of multi-vendor desktop and mobile hardware is very important to Symantec," said Mark Bregman, chief technology officer of Symantec Corporation. "As a leader in providing platform agnostic infrastructure software, we support the DMTF in providing a comprehensive framework for interoperable desktop management through this specification."
WBEM Solutions
"WBEM Solutions plans to add support for the DMTF DASH Initiative to our standards-based management solutions and products," said Troy Biegger, vice president of Marketing and Sales, WBEM Solutions, Inc. "As the industry leader of DMTF standards-based commercial management solutions, DASH support in our product and service offerings will provide our customers with enterprise-level management capabilities for desktop and mobile management."
AMD
"As a founding member of the DASH working group and key contributor to the specification, AMD is pleased to see the broad adoption of DASH in the industry," said Terri Hall, vice president, Software Alliances and Solutions, AMD. "AMD continues its standards leadership by developing a comprehensive set of DASH test tools, available to all vendors, to ensure DASH solutions in the market are truly interoperable and realize the full value of DASH to IT customers."
Avocent
"Avocent will support the DMTF's new DASH management Initiative for desktops and mobile systems, and we look forward to working with our customers and partners to deliver products based on this new Web services-based standard," said Dave Perry, executive vice president, Avocent Corporation. "DASH will help extend standardized management capabilities into these new domains — reducing the complexity for our joint IT customers."
NVIDIA
"We are happy to support the DMTF's DASH in our nForce Media and Communication Processors," said Manoj Gujral, general manager for Commercial Platforms, NVIDIA Corporation. "By providing a unified and comprehensive framework for desktop and mobile management — from the necessary protocols to the helpful DMTF profiles — DASH delivers renewed simplicity, which will allow NVIDIA to deliver common management benefits to end users of Intel and AMD platforms built with NVIDIA nForce core-logic solutions."
About the DMTF
With more than 3,500 active participants representing 39 countries and nearly 200 organizations, the Distributed Management Task Force, Inc. (DMTF) is the industry organization leading the development, adoption and promotion of interoperable management initiatives and standards. DMTF management technologies include the Common Diagnostic Model (CDM), Desktop and mobile Architecture for System Hardware (DASH) and Systems Management Architecture for Server Hardware (SMASH) Initiatives, as well as Web-Based Enterprise Management (WBEM) — including protocols such as CIM-XML and Web Services for Management (WS-Management) — which are all based on the Common Information Model (CIM).

I first fell in love with computers when my parents bought me a Commodore 64, a fairly nice computer for the time. Thanks to Moore's law, and the relentless pace of development, the average cell phone is now more powerful than that machine from just 20 some years ago. While it's understandable that many people just want to make phone calls, think of all the programs out there waiting to be written that take advantage of the fact that you almost always have a cell phone with you. I think I'm just beginning to scratch the surface of what's possible, especially as phones continue to get faster, and have better connections to the internet.
I became interested in writing cell phone applications several years ago, after a rainy day high in the Italian Dolomites near Cortina d'Ampezzo - my old phone ended up in a mud puddle and died, leading me to purchase a new phone with J2ME (Java) capabilities. Writing applications in Java was okay, but I thought to myself that it would be an interesting experiment to try and create a scripting language that runs on top of the J2ME (now known as Java Micro Edition or Java ME) environment.
When I created Hecl, I did so with several goals in mind:
Make it even easier and faster for experienced programmers to create cell phone applications.
Make it possible for novice programmers to create cell phone applications without the burden of dealing with Java.
Hecl has other benefits too - it's faster to develop applications, because you don't have to recompile after each change. In the hands of a clever programmer, it's also possible to do interesting things with Hecl because of its interpreted nature. You could start an application on your phone, and download additional bits of code off the web.
The aim of this tutorial is to help you create cell phone applications, so let's get started right away. You'll need a few things first:
Sun's Java. This is heading towards free software, but isn't quit there yet. If you run Ubuntu, like me, you can get Java with apt: apt-get install sun-java5-jdk, if you've added the "multiverse" repositories to your /etc/apt/sources.list file: deb
Sun's WTK toolkit. While you don't need the tools to compile Hecl (unless you want to hack on it!), you do want the emulator, so that you don't have to load your app onto your phone each time you want to test it. It's not open source software (yet?), but it does run on Linux, Mac and Windows, and of course it is free.
Hecl itself. You can get it from the Sourceforge download page.
Note
Hecl is always improving, so you should also consider checking out Hecl directly from subversion: svn co https://hecl.svn.sourceforge.net/svnroot/hecl/trunk/hecl hecl
Sun's WTK requires installation - you can put it somewhere like /opt, so it won't get mixed up with the rest of your system. The installation process is very simple - just say yes to a few questions, and you're done. Hecl doesn't require installation: everything you need is already there in the distribution.
To see if everything's working, you can try launching the emulator with the sample application: /opt/WTK2.5.1/bin/emulator -classpath build/j2me/final/cldc1.1-midp2.0/Hecl.jar Hecl
Hecl J2ME MIDP1.0 Commands
alert — Creates an alert
choicegroup — Displays a choicegroup in the current form
cmd — Adds a command to a form/listbox/textbox
datefield — Displays an datefield in the current form
exit — Exits the application
form — Creates a form
gauge — Displays an gauge in the current form
getindex — Fetches a reference to the N'th element in a given form/listbox
getprop — Fetches the value of a given property from a widget
listbox — Creates a listbox
noscreen — Runs without a current screen widget
screenappend — Appends an item to a form or listbox
setcurrent — Displays an alert/form/listbox/textbox
setindex — Sets the indexth element in a form/listbox to specified item
setprop — Sets a given property of a widget
string — Adds a string to the current form.
stringitem — Displays a stringitem in the current form
textbox — Creates a textbox
textfield — Displays a textfield in the current form
Note
Hecl has different GUI commands for the MIDP1.0 (older phones) and MIDP2.0 (newer). We are in the process of documenting the MIDP2.0 commands.
Commands available in the J2ME MIDP1.0 version of Hecl to interact with the phone. Look in the midp10/examples directory for examples of these commands and widgets in use.
Hecl Java ME MIDP2.0 Commands
lcdui.alert — Pops up an alert
lcdui.canvas — Creates a canvas
lcdui.choicegroup — Creates a group of potential choices that can be added to a form.
lcdui.command — Creates a command that can be attached to a screen
lcdui.date — Date/Time widget for lcdui forms
$eventcmd — Command/object describing a Canvas event.
lcdui.font — Font information and manipulation command.
lcdui.form — Creates a form that can contain various widgets
lcdui.gauge — Creates a gauge widget that can be attached to a form.
lcdui.image — Creates an image.
lcdui.imageitem — An item that can contain an image, in order to attach it to a form.
lcdui.list — Creates a full-screen list
lcdui.settings — Returns or sets information about the graphical environment.
lcdui.spacer — Creates a spacer element in a form.
lcdui.stringitem — Creates a string item that can be added to a form.
lcdui.textbox — Creates a text box for editing larger blocks of text.
lcdui.textfield — Creates a small text editing widget that can be attached to a form.
lcdui.ticker — Creates a ticker that scrolls horizontally.

Hacking Hecl's Java ME code
Since Java ME comes in several flavors that Hecl can be compiled for, it's necessary to understand what Hecl does, and how it does it.
JavaME has two layers that are of interest to us, "CLDC" and "MIDP". CLDC is available in 1.0 and 1.1 configurations, whereas MIDP comes in 1.0 and 2.0 configurations. The most common configurations are CLDC 1.0 and MIDP 1.0, CLDC 1.0 and MIDP 2.0, and CLDC 1.1 with MIDP 2.0. Here are the Wikipedia entries describing CLDC and MIDP.
Hecl tries to match code to system resources: in other words, the code in the midp10/ and midp10gui (MIDP 1.0) directories is smaller, simpler, and has fewer features than the code in midp20 and midp20gui (MIDP 2.0), reflecting the fact that many 1.0 devices only allow very small jar files ("midlets").
For MIDP 1.0, the midp10gui directory contains the GUICmds.java, which has most of the functionality that maps J2ME functionality to Hecl and back. The midp10/Hecl.java file contains the code that starts up Hecl on the cell phone. For MIDP 2.0, the midp20gui directory contains the GUI commands, and midp20/Hecl.java is where the application is launched from on the phone.
In order to be able to deal with all these different versions, Hecl is more or less forced to utilize a Java preprocessor, which explains all the ifdef's in the code. The various symbols are defined in the settings.xml file.
To compile different combinations of things, Hecl makes a couple of property files available that are used like so:
ant -propertyfile ./cldc10midp10.properties midlet
Which compiles the CLDC 1.0 / MIDP 1.0 version of Hecl and places the jar in the jars/cldc1.0-midp1.0/ directory, or:
ant -propertyfile ./cldc11midp20.properties midlet
Which compiles the CLDC 1.1 / MIDP 2.0 version, and places the jar in the jars/cldc1.1-midp2.0/ directory.

CDMA technology is based on a form of transmission known as Direct Sequence Spread Spectrum (DSSS). This form of transmission originally used for military and police communications because the transmissions were difficult to detect in many instances, and even if they were received they were very difficult to decipher without the correct codes. However the possibilities of using this technology to provide a multiple access scheme for mobile telecommunications and have now been exploited in a major way.
Previous cellular telecommunications technologies used either frequency division multiple access (FDMA) where different users were allocated different frequencies, or time division multiple access (TDMA) where they were allotted different time slots on a channel. CDMA is different. Using the CDMA system, different users are allocated different codes to provide access to the system. It can be likened to many different people standing in a room talking to others in many different languages. Although the ambient noise level is very high, it is nevertheless still possible to pick out someone speaking in the same language as yourself.
DSSS basics
The key element of code division multiple access CDMA is its use of DSSS. In essence the required data signal is multiplied with what is known as a spreading or chip code data stream. This has a higher data rate than the data itself and it enables the overall signal to be spread over a much wider bandwidth. Signals with high data rates occupy wider signal bandwidths than those with low data rates.
To decode the signal and receive the original data, the CDMA signal is multiplied with the spreading code to regenerate the original data. When this is done, then only the data with that was generated with the same spreading code is regenerated, all the other data that is generated from different spreading code streams is ignored
This is a powerful principle and using code division multiple access technique, it is possible to transmit several sets of data independently on the same carrier and then reconstitute them at the receiver without mutual interference. In this way a base station can communicate with several mobiles on a single channel. Similarly several mobiles can communicate with a single base station, provided that in each case an independent spreading code is used.
The CDMA spreading codes can either be a random number (or pseudo random), or more usually orthogonal codes are used. Two codes are said to be orthogonal if when they are multiplied together and then the result is added over a period of time they sum to zero. For example a codes 1 -1 -1 1 and 1 -1 1 -1 when multiplied together give 1 1 -1 -1 which gives the sum zero. Although pseudo random number codes can be used there is possibility of data errors being introduced into the system.
Advantages
There are several advantages to using code division multiple access CDMA. The main reason for its acceptance is that it enables more users to use a given amount of spectrum. Its use also enables adjacent base stations to operate on the same channel, allowing more efficient use of the spectrum and it provides for an easier handover.
In view of these advantages CDMA has been adopted for all the 3G technologies and will be around for many years to come.

Radio waves are created due to the movement of electrical charges in antennas. As they are created, these waves radiate away from the antenna. All electromagnetic waves travel at the speed of light. The major differences between the different types of waves are the distances covered by one cycle of the wave and the number of waves that pass a certain point during a set time period. The wavelength is the distance covered by one cycle of a wave. The frequency is the number of waves passing a given point in one second. For any electromagnetic wave, the wavelength multiplied by the frequency equals the speed of light. The frequency of an RF signal is usually expressed in units called hertz (Hz). One Hz equals one wave per second. One kilohertz (kHz) equals one thousand waves per second, one megahertz (MHz) equals one million waves per second, and one gigahertz (GHz) equals one billion waves per second.
RF energy includes waves with frequencies ranging from about 3000 waves per second (3 kHz) to 300 billion waves per second (300 GHz). Microwaves are a subset of radio waves that have frequencies ranging from around 300 million waves per second (300 MHz) to three billion waves per second (3 GHz).
How is radiofrequency energy used?
Probably the most important use of RF energy is for telecommunications. Radio and TV broadcasting, wireless phones, pagers, cordless phones, police and fire department radios, point-to-point links and satellite communications all rely on RF energy.
Other uses of RF energy include microwave ovens, radar, industrial heaters and sealers, and medical treatments. RF energy, especially at microwave frequencies, can heat water. Since most food has a high water content, microwaves can cook food quickly. Radar relies on RF energy to track cars and airplanes as well as for military applications. Industrial heaters and sealers use RF energy to mold plastic materials, glue wood products, seal leather items such as shoes and pocketbooks, and process food. Medical uses of RF energy include pacemaker monitoring and programming.
How is radiofrequency radiation measured?
RF waves and RF fields have both electrical and magnetic components. It is often convenient to express the strength of the RF field in terms of each component. For example, the unit "volts per meter" (V/m) is used to measure the electric field strength, and the unit "amperes per meter" (A/m) is used to express the magnetic field strength. Another common way to characterize an RF field is by means of the power density. Power density is defined as power per unit area. For example, power density can be expressed in terms of milliwatts (one thousandth of a watt) per square centimeter (mW/cm2 or microwatts (one millionth of a watt) per square centimeter (µW/cm2).
The quantity used to measure how much RF energy is actually absorbed by the body is called the Specific Absorption Rate or SAR. The SAR is a measure of the rate of absorption of RF energy. It is usually expressed in units of watts per kilogram (W/kg) or milliwatts per gram (mW/g).
What biological effects can be caused by RF energy?
The biological effects of radiofrequency energy should not be confused with the effects from other types of electromagnetic energy.
Very high levels of electromagnetic energy, such as is found in X-rays and gamma rays can ionize biological tissues. Ionization is a process where electrons are stripped away from their normal locations in atoms and molecules. It can permanently damage biological tissues including DNA, the genetic material. Ionization only occurs with very high levels of electromagnetic energy such as X-rays and gamma rays. Often the term radiation is used when discussing ionizing radiation (such as that associated with nuclear power plants).
The energy levels associated with radiofrequency energy, including both radio waves and microwaves, are not great enough to cause the ionization of atoms and molecules. Therefore, RF energy is a type of non-ionizing radiation. Other types of non-ionizing radiation include visible light, infrared radiation (heat) and other forms of electromagnetic radiation with relatively low frequencies.
Large amounts of RF energy can heat tissue. This can damage tissues and increase body temperatures. Two areas of the body, the eyes and the testes, are particularly vulnerable to RF heating because there is relatively little blood flow in them to carry away excess heat.
The amount of RF radiation routinely encountered by the general public is too low to produce significant heating or increased body temperature. Still, some people have questions about the possible health effects of low levels of RF energy. It is generally agreed that further research is needed to determine what effects actually occur and whether they are dangerous to people. In the meantime, standards-setting organizations and government agencies are continuing to monitor the latest scientific findings to determine whether changes in safety limits are needed to protect human health.
FDA, EPA and other US government agencies responsible for public health and safety have worked together and in connection with WHO to monitor developments and identify research needs related to RF biological effects.
What levels of RF energy are considered safe?
Various organizations and countries have developed standards for exposure to radiofrequency energy. These standards recommend safe levels of exposure for both the general public and for workers. In the United States, the FCC has used safety guidelines for RF environmental exposure since 1985.
The FCC guidelines for human exposure to RF electromagnetic fields are derived from the recommendations of two expert organizations, the National Council on Radiation Protection and Measurements (NCRP) and the Institute of Electrical and Electronics Engineers (IEEE). In both cases, the recommendations were developed by scientific and engineering experts drawn from industry, government, and academia after extensive reviews of the scientific literature related to the biological effects of RF energy.
Many countries in Europe and elsewhere use exposure guidelines developed by the International Commission on Non-Ionizing Radiation Protection (ICNIRP). The ICNIRP safety limits are generally similar to those of the NCRP and IEEE, with a few exceptions. For example, ICNIRP recommends different exposure levels in the lower and upper frequency ranges and for localized exposure from certain products such as hand-held wireless telephones. Currently, the World Health Organization is working to provide a framework for international harmonization of RF safety standards.
The NCRP, IEEE, and ICNIRP all have identified a whole-body Specific Absorption Rate (SAR) value of 4 watts per kilogram (4 W/kg) as a threshold level of exposure at which harmful biological effects may occur. Exposure guidelines in terms of field strength, power density and localized SAR were then derived from this threshold value. In addition, the NCRP, IEEE, and ICNIRP guidelines vary depending on the frequency of the RF exposure. This is due to the finding that whole-body human absorption of RF energy varies with the frequency of the RF signal. The most restrictive limits on whole-body exposure are in the frequency range of 30-300 MHz where the human body absorbs RF energy most efficiently. For products that only expose part of the body, such as wireless phones, exposure limits in terms of SAR only are specified.
The exposure limits used by the FCC are expressed in terms of SAR, electric and magnetic field strength, and power density for transmitters operating at frequencies from 300 kHz to 100 GHz. The specific values can be found in two FCC bulletins, OET Bulletins 56 and 65: http://www.fcc.gov/oet/info/documents/bulletins/#56; http://www.fcc.gov/oet/info/documents/bulletins/#65
Why has the FCC adopted guidelines for RF exposure?
The FCC authorizes and licenses products, transmitters, and facilities that generate RF and microwave radiation. It has jurisdiction over all transmitting services in the U.S. except those specifically operated by the Federal Government. While the FCC does not have the expertise to determine radiation exposure guidelines on its own, it does have the expertise and authority to recognize and adopt technically sound standards promulgated by other expert agencies and organizations, and has done so . (Our joint efforts with the FDA in developing this website is illustrative of the kind of inter-agency efforts and consultation we engage in regarding this health and safety issue.)
Under the National Environmental Policy Act of 1969 (NEPA), the FCC has certain responsibilities to consider whether its actions will significantly affect the quality of the human environment. Therefore, FCC approval and licensing of transmitters and facilities must be evaluated for significant impact on the environment. Human exposure to RF radiation emitted by FCC-regulated transmitters is one of several factors that must be considered in such environmental evaluations. In 1996, the FCC revised its guidelines for RF exposure as a result of a multi-year proceeding and as required by the Telecommunications Act of 1996.
Radio and television broadcast stations, satellite-earth stations, experimental radio stations and certain wireless communication facilities are required to undergo routine evaluation for RF compliance when they submit an application to the FCC for construction or modification of a transmitting facility or renewal of a license. Failure to comply with the FCC's RF exposure guidelines could lead to the preparation of a formal Environmental Assessment, possible Environmental Impact Statement and eventual rejection of an application. Technical guidelines for evaluating compliance with the FCC RF safety requirements can be found in the FCC's OET Bulletin 65. http://www.fcc.gov/oet/info/documents/bulletins/#65
Low-powered, intermittent, or inaccessible RF transmitters and facilities are normally excluded from the requirement for routine evaluation for RF exposure. These exclusions are based on standard calculations and measurement data indicating that a transmitting station or equipment operating under the conditions prescribed is unlikely to cause exposures in excess of the guidelines under normal conditions of use. Such exclusions are not exclusions from compliance, but, rather, exclusions from routine evaluation. The FCC's policies on RF exposure and categorical exclusion can be found in Section 1.1307(b) of the FCC's Rules and Regulations [(47 CFR 1.1307(b)].
How can I obtain the Specific Absorption Rate (SAR) value for my wireless phone?
The FCC requires that wireless phones sold in the United States demonstrate compliance with human exposure limits adopted by the FCC in 1996. The relative amount of RF energy absorbed in the head of a wireless telephone-user is given by the Specific Absorption Rate (SAR), as explained above. The FCC requires wireless phones to comply with a safety limit of 1.6 watts per kilogram (1.6 W/kg) in terms of SAR.
Information on SAR for a specific phone model can be obtained for many recently manufactured phones using the FCC identification (ID) number for that model. The FCC ID number is usually printed somewhere on the case of the phone. Sometimes it may be necessary to remove the battery pack to find the number. Once you have the ID number, go to the following Web address: www.fcc.gov/oet/fccid. On this page, you will see instructions for entering the FCC ID number. Type the FCC ID number exactly as requested (the Grantee Code is the first three characters, the Equipment Product Code is the rest of the FCC ID number). Then click on "Start Search." The "Grant of Equipment Authorization" for your telephone should appear. Read through the grant for the section on "SAR Compliance," "Certification of Compliance with FCC Rules for RF Exposure" or similar language. This section should contain the value(s) for typical or maximum SAR for your phone.
Phones and other products authorized since June 2, 2000, should have the maximum SAR levels noted directly on the "Grant of Equipment Authorization." For phones and products authorized between about mid-1998 and June 2000, detailed information on SAR levels is typically found in the exhibits associated with the grant. Once a grant is accessed, the exhibits can be viewed by clicking on "View Exhibit." Grants authorized prior to 1998 are not part of the electronic database but, rather, have been documented in the form of paper records.
The FCC database does not list phones by model number. However, consumers may find SAR information from other sources as well. Some wireless phone manufacturers make SAR information available on their own Web sites. In addition, some non-government Web sites provide SARs for specific models of wireless phones. However, the FCC has not reviewed these sites and makes no guarantees of their accuracy. Finally, phones certified by the Cellular Telecommunications and Internet Association (CTIA) are required to provide SAR information to consumers in the instructional materials that come with the phones.
Do hands-free kits for wireless phones reduce risks from exposure to RF emissions?
Since there are no known risks from exposure to RF emissions from wireless phones, there is no reason to believe that hands-free kits reduce risks. Hands-free kits can be used with wireless phones for convenience and comfort. These systems reduce the absorption of RF energy in the head because the phone, which is the source of the RF emissions, will not be placed against the head. On the other hand, if the phone is mounted against the waist or other part of the body during use, then that part of the body will absorb more RF energy. Wireless phones marketed in the U.S. are required to meet safety requirements regardless of whether they are used against the head or against the body. Either configuration should result in compliance with the safety limit.
Do wireless phone accessories that claim to shield the head from RF radiation work?
Since there are no known risks from exposure to RF emissions from wireless phones, there is no reason to believe that accessories that claim to shield the head from those emissions reduce risks. Some products that claim to shield the user from RF absorption use special phone cases, while others involve nothing more than a metallic accessory attached to the phone. Studies have shown that these products generally do not work as advertised. Unlike "hand-free" kits, these so-called "shields" may interfere with proper operation of the phone. The phone may be forced to boost its power to compensate, leading to an increase in RF absorption. In February 2002, the Federal trade Commission (FTC) charged two companies that sold devices that claimed to protect wireless phone users from radiation with making false and unsubstantiated claims. According to FTC, these defendants lacked a reasonable basis to substantiate their claim.
What are wireless telephone base stations?
Fixed antennas used for wireless telecommunications are referred to as cellular base stations, cell stations, PCS ("Personal Communications Service") stations or telephone transmission towers. These base stations consist of antennas and electronic equipment. Because the antennas need to be high in the air, they are often located on towers, poles, water tanks, or rooftops. Typical heights for freestanding base station towers are 50-200 feet.
Some base stations use antennas that look like poles, 10 to 15 feet in length, that are referred to as "omni-directional" antennas. These types of antennas are usually found in rural areas. In urban and suburban areas, wireless providers now more commonly use panel or sector antennas for their base stations. These antennas consist of rectangular panels, about 1 by 4 feet in dimension. The antennas are usually arranged in three groups of three antennas each. One antenna in each group is used to transmit signals to wireless phones, and the other two antennas in each group are used to receive signals from wireless phones.
At any base station site, the amount of RF energy produced depends on the number of radio channels (transmitters) per antenna and the power of each transmitter. Typically, 21 channels per antenna sector are available. For a typical cell site using sector antennas, each of the three transmitting antennas could be connected to up to 21 transmitters for a total of 63 transmitters. However, it is unlikely that all of the transmitters would be transmitting at the same time. When omni-directional antennas are used, a cellular base station could theoretically use up to 96 transmitters, but this would be very unusual, and, once again, it is unlikely that all transmitters would be in operation simultaneously. Base stations used for PCS communications generally require fewer transmitters than those used for cellular radio transmissions, since PCS carriers usually have a higher density of base station antenna sites.
Are wireless telephone base stations safe?
The electromagnetic RF signals transmitted from base station antennas stations travel toward the horizon in relatively narrow paths. For example, the radiation pattern for an antenna array mounted on a tower can be likened to a thin pancake centered around the antenna system. The individual pattern for a single array of sector antennas is wedge-shaped, like a piece of pie. As with all forms of electromagnetic energy, the power decreases rapidly as one moves away from the antenna. Therefore, RF exposure on the ground is much less than exposure very close to the antenna and in the path of the transmitted radio signal. In fact, ground-level exposure from such antennas is typically thousands of times less than the exposure levels recommended as safe by expert organizations. So exposure to nearby residents would be well within safety margins.
Cellular and PCS base stations in the United States are required to comply with limits for exposure recommended by expert organizations and endorsed by government agencies responsible for health and safety. Measurements made near cellular and PCS base station antennas mounted on towers have confirmed that ground-level exposures are typically thousands of times less than the exposure limits adopted by the FCC. In fact, in order to be exposed to levels at or near the FCC limits for cellular or PCS frequencies an individual would essentially have to remain in the main transmitted radio signal (at the height of the antenna) and within a few feet from the antenna. This is, of course, very unlikely to occur.
When cellular and PCS antennas are mounted on rooftops, RF levels on that roof or on others near by would probably be greater than those typically encountered on the ground. However, exposure levels approaching or exceeding safety guidelines should be encountered only very close to or directly in front of the antennas. In addition, for sector-type antennas, typically used for such rooftop base stations, RF levels to the side and in back of these antennas are insignificant. General guidelines on antenna installations and circumstances that might give rise to a concern about an facility's conformance with FCC regulations can be found in A Local Government Official's Guide to Transmitting Antenna RF Emission Safety: Rules, Procedures, and Practical Guidance. This Guide can be accessed at: http://www.fcc.gov/oet/rfsafety.
Who regulates exposure to radiation from microwave ovens, television sets and computer monitors?
The Food and Drug Administration is responsible for protecting the public from harmful radiation emissions from these consumer products.
Does the FCC routinely monitor radiofrequency radiation from antennas?
The FCC does not have the resources or the personnel to routinely monitor the emissions for all the thousands of transmitters that are subject to FCC jurisdiction. However, the FCC does have measurement instrumentation for evaluating RF levels in areas that may be accessible to the public or to workers. If there is evidence for potential non-compliance with FCC exposure guidelines for a FCC-regulated facility, staff from the FCC's Office of Engineering and Technology or the FCC Enforcement Bureau can conduct and investigation, and, if appropriate, perform actual measurements. Circumstances that could give rise to a concern about an facility's conformance with FCC regulations can be found in in A Local Government Official's Guide to Transmitting Antenna RF Emission Safety: Rules, Procedures, and Practical Guidance. This Guide can be accessed at: http://www.fcc.gov/oet/rfsafety. Potential exposure problems should be brought to the FCC's attention by contacting the FCC RF Safety Program at: 202-418-2464 or by e-mail: rfsafety@fcc.gov.
Does the FCC maintain a database that includes information on the location and technical parameters of all the transmitting towers it regulates?
Each of the FCC Bureaus maintains its own licensing database system for the service(s) it regulates (e.g., television, cellular service, satellite earth stations.) The FCC issues two types of licenses: site specific and market based. In the case of site specific licensed facilities, technical operating information is collected from the licensee as part of the licensing process. However, in the case of market based licensing (e.g., PCS, cellular), the licensee is granted the authority to operate a radio communications system in a geographic area using as many facilities as are required, and the licensee is not required to provide the FCC with specific location and operating parameters of these facilities.
Information on site specific licensed facilities can be found the "General Menu Reports" (GenMen) at http://gullfoss2.fcc.gov/cgi-bin/ws.exe/genmen/index.hts.
The various FCC Bureaus also publish on at least a weekly basis, bulk extracts of their licensing databases. Each licensing database has its own unique file structure. These extracts consist of multiple, very large files. The FCC's Office of Engineering and Technology (OET) maintains an index to these databases at http://www.fcc.gov/oet/info/database/fadb.html. Entry points into the various databases include frequency, state/county, latitude/longitude, call-sign and licensee name. For further information on the Commission's existing databases, you can contact Donald Campbell at dcampbel@fcc.gov or 202-418-2405.
Can local and state governmental bodies establish limits for RF exposure?
Although some local and state governments have enacted rules and regulations about human exposure to RF energy in the past, the Telecommunications Act of 1996 requires the Federal Government to control human exposure to RF emissions. In particular, Section 704 of the Act states that, "No State or local government or instrumentality thereof may regulate the placement, construction, and modification of personal wireless service facilities on the basis of the environmental effects of radio frequency emissions to the extent that such facilities comply with the Commission's regulations concerning such emissions." Further information on federal authority and FCC policy is available in a fact sheet from the FCC's Wireless Telecommunications Bureau at www.fcc.gov/wtb.
Do wireless phones pose a health hazard?
The available scientific evidence does not show that any health problems are associated with using wireless phones. There is no proof, however, that wireless phones are absolutely safe. Wireless phones emit low levels of radiofrequency energy (RF) in the microwave range while being used. They also emit very low levels of RF when in the stand-by mode. Whereas high levels of RF can produce health effects (by heating tissue), exposure to low level RF that does not produce heating effects causes no known adverse health effects. Many studies of low level RF exposures have not found any biological effects. Some studies have suggested that some biological effects may occur, but such findings have not been confirmed by additional research. In some cases, other researchers have had difficulty in reproducing those studies, or in determining the reasons for inconsistent results.
What is FDA's role concerning the safety of wireless phones?
Under the law, FDA does not review the safety of radiation-emitting consumer products such as wireless phones before they can be sold, as it does with new drugs or medical devices. However, the agency has authority to take action if wireless phones are shown to emit radiofrequency energy (RF) at a level that is hazardous to the user. In such a case, FDA could require the manufacturers of wireless phones to notify users of the health hazard and to repair, replace or recall the phones so that the hazard no longer exists.
Although the existing scientific data do not justify FDA regulatory actions, FDA has urged the wireless phone industry to take a number of steps, including the following:
Support needed research into possible biological effects of RF of the type emitted by wireless phones;
Design wireless phones in a way that minimizes any RF exposure to the user that is not necessary for device function; and
Cooperate in providing users of wireless phones with the best possible information on possible effects of wireless phone use on human health
FDA belongs to an interagency working group of the federal agencies that have responsibility for different aspects of RF safety to ensure coordinated efforts at the federal level. The following agencies belong to this working group:
National Institute for Occupational Safety and Health
Environmental Protection Agency
Federal Communications Commission
Occupational Safety and Health Administration
National Telecommunications and Information Administration
The National Institutes of Health participates in some interagency working group activities, as well.
FDA shares regulatory responsibilities for wireless phones with the Federal Communications Commission (FCC). All phones that are sold in the United States must comply with FCC safety guidelines that limit RF exposure. FCC relies on FDA and other health agencies for safety questions about wireless phones.
FCC also regulates the base stations that the wireless phone networks rely upon. While these base stations operate at higher power than do the wireless phones themselves, the RF exposures that people get from these base stations are typically thousands of times lower than those they can get from wireless phones. Base stations are thus not the primary subject of the safety questions discussed in this document.
What kinds of phones are the subject of this update?
The term “wireless phone” refers here to hand-held wireless phones with built-in antennas, often called “cell,” “mobile,” or “PCS” phones. These types of wireless phones can expose the user to measurable radiofrequency energy (RF) because of the short distance between the phone and the user’s head. These RF exposures are limited by Federal Communications Commission safety guidelines that were developed with the advice of FDA and other federal health and safety agencies. When the phone is located at greater distances from the user, the exposure to RF is drastically lower because a person's RF exposure decreases rapidly with increasing distance from the source. The so-called "cordless phones," which have a base unit connected to the telephone wiring in a house, typically operate at far lower power levels, and thus produce RF exposures well within the FCC's compliance limits.
What are the results of the research done already?
The research done thus far has produced conflicting results, and many studies have suffered from flaws in their research methods. Animal experiments investigating the effects of radiofrequency energy (RF) exposures characteristic of wireless phones have yielded conflicting results that often cannot be repeated in other laboratories. A few animal studies, however, have suggested that low levels of RF could accelerate the development of cancer in laboratory animals. However, many of the studies that showed increased tumor development used animals that had been genetically engineered or treated with cancer-causing chemicals so as to be pre-disposed to develop cancer in the absence of RF exposure. Other studies exposed the animals to RF for up to 22 hours per day. These conditions are not similar to the conditions under which people use wireless phones, so we don’t know with certainty what the results of such studies mean for human health.
Three large epidemiology studies have been published since December 2000. Between them, the studies investigated any possible association between the use of wireless phones and primary brain cancer, glioma, meningioma, or acoustic neuroma, tumors of the brain or salivary gland, leukemia, or other cancers. None of the studies demonstrated the existence of any harmful health effects from wireless phone RF exposures. However, none of the studies can answer questions about long-term exposures, since the average period of phone use in these studies was around three years.
What research is needed to decide whether RF exposure from wireless phones poses a health risk?
A combination of laboratory studies and epidemiological studies of people actually using wireless phones would provide some of the data that are needed. Lifetime animal exposure studies could be completed in a few years. However, very large numbers of animals would be needed to provide reliable proof of a cancer promoting effect if one exists. Epidemiological studies can provide data that is directly applicable to human populations, but 10 or more years’ follow-up may be needed to provide answers about some health effects, such as cancer. This is because the interval between the time of exposure to a cancer-causing agent and the time tumors develop - if they do - may be many, many years. The interpretation of epidemiological studies is hampered by difficulties in measuring actual RF exposure during day-to-day use of wireless phones. Many factors affect this measurement, such as the angle at which the phone is held, or which model of phone is used.
What is FDA doing to find out more about the possible health effects of wireless phone RF?
FDA is working with the U.S. National Toxicology Program and with groups of investigators around the world to ensure that high priority animal studies are conducted to address important questions about the effects of exposure to radiofrequency energy (RF).
FDA has been a leading participant in the World Health Organization International Electromagnetic Fields (EMF) Project since its inception in 1996. An influential result of this work has been the development of a detailed agenda of research needs that has driven the establishment of new research programs around the world. The Project has also helped develop a series of public information documents on EMF issues.
FDA and the Cellular Telecommunications & Internet Association (CTIA) have a formal Cooperative Research and Development Agreement (CRADA) to do research on wireless phone safety. FDA provides the scientific oversight, obtaining input from experts in government, industry, and academic organizations. CTIA-funded research is conducted through contracts to independent investigators. The initial research will include both laboratory studies and studies of wireless phone users. The CRADA will also include a broad assessment of additional research needs in the context of the latest research developments around the world.
What steps can I take to reduce my exposure to radiofrequency energy from my wireless phone?
If there is a risk from these products--and at this point we do not know that there is--it is probably very small. But if you are concerned about avoiding even potential risks, you can take a few simple steps to minimize your exposure to radiofrequency energy (RF). Since time is a key factor in how much exposure a person receives, reducing the amount of time spent using a wireless phone will reduce RF exposure.
If you must conduct extended conversations by wireless phone every day, you could place more distance between your body and the source of the RF, since the exposure level drops off dramatically with distance. For example, you could use a headset and carry the wireless phone away from your body or use a wireless phone connected to a remote antenna
Again, the scientific data do not demonstrate that wireless phones are harmful. But if you are concerned about the RF exposure from these products, you can use measures like those described above to reduce your RF exposure from wireless phone use.
What about children using wireless phones?
The scientific evidence does not show a danger to users of wireless phones, including children and teenagers. If you want to take steps to lower exposure to radiofrequency energy (RF), the measures described above would apply to children and teenagers using wireless phones. Reducing the time of wireless phone use and increasing the distance between the user and the RF source will reduce RF exposure.
Some groups sponsored by other national governments have advised that children be discouraged from using wireless phones at all. For example, the government in the United Kingdom distributed leaflets containing such a recommendation in December 2000. They noted that no evidence exists that using a wireless phone causes brain tumors or other ill effects. Their recommendation to limit wireless phone use by children was strictly precautionary; it was not based on scientific evidence that any health hazard exists.
What about wireless phone interference with medical equipment?
Radiofrequency energy (RF) from wireless phones can interact with some electronic devices. For this reason, FDA helped develop a detailed test method to measure electromagnetic interference (EMI) of implanted cardiac pacemakers and defibrillators from wireless telephones. This test method is now part of a standard sponsored by the Association for the Advancement of Medical instrumentation (AAMI). The final draft, a joint effort by FDA, medical device manufacturers, and many other groups, was completed in late 2000. This standard will allow manufacturers to ensure that cardiac pacemakers and defibrillators are safe from wireless phone EMI.
FDA has tested hearing aids for interference from handheld wireless phones and helped develop a voluntary standard sponsored by the Institute of Electrical and Electronic Engineers (IEEE). This standard specifies test methods and performance requirements for hearing aids and wireless phones so that that no interference occurs when a person uses a “compatible” phone and a “compatible” hearing aid at the same time. This standard was approved by the IEEE in 2000.
FDA continues to monitor the use of wireless phones for possible interactions with other medical devices. Should harmful interference be found to occur, FDA will conduct testing to assess the interference and work to resolve the problem.
Which other federal agencies have responsibilities related to potential RF health effects?
Certain agencies in the Federal Government have been involved in monitoring, researching or regulating issues related to human exposure to RF radiation. These agencies include the Food and Drug Administration (FDA), the Environmental Protection Agency (EPA), the Occupational Safety and Health Administration (OSHA), the National Institute for Occupational Safety and Health (NIOSH), the National Telecommunications and Information Administration (NTIA) and the Department of Defense (DOD).
By authority of the Radiation Control for Health and Safety Act of 1968, the Center for Devices and Radiological Health (CDRH) of the FDA develops performance standards for the emission of radiation from electronic products including X-ray equipment, other medical devices, television sets, microwave ovens, laser products and sunlamps. The CDRH established a product performance standard for microwave ovens in 1971 limiting the amount of RF leakage from ovens. However, the CDRH has not adopted performance standards for other RF-emitting products. The FDA is, however, the lead federal health agency in monitoring the latest research developments and advising other agencies with respect to the safety of RF-emitting products used by the public, such as cellular and PCS phones.
The FDA's microwave oven standard is an emission standard (as opposed to an exposure standard) that allows specific levels of microwave leakage (measured at five centimeters from the oven surface). The standard also requires ovens to have two independent interlock systems that prevent the oven from generating microwaves the moment that the latch is released or the door of the oven is opened. The FDA has stated that ovens that meet its standards and are used according to the manufacturer's recommendations are safe for consumer and industrial use. More information is available from: www.fda.gov/cdrh.
The EPA has, in the past, considered developing federal guidelines for public exposure to RF radiation. However, EPA activities related to RF safety and health are presently limited to advisory functions. For example, the EPA now chairs an Inter-agency Radiofrequency Working Group, which coordinates RF health-related activities among the various federal agencies with health or regulatory responsibilities in this area.
OSHA is responsible for protecting workers from exposure to hazardous chemical and physical agents. In 1971, OSHA issued a protection guide for exposure of workers to RF radiation [29 CFR 1910.97]. However, this guide was later ruled to be only advisory and not mandatory. Moreover, it was based on an earlier RF exposure standard that has now been revised. At the present time, OSHA uses the IEEE and/or FCC exposure guidelines for enforcement purposes under OSHA's "general duty clause" (for more information see: http://www.osha-slc.gov/SLTC/radiofrequencyradiation/index.html
NIOSH is part of the U.S. Department of Health and Human Services. It conducts research and investigations into issues related to occupational exposure to chemical and physical agents. NIOSH has, in the past, undertaken to develop RF exposure guidelines for workers, but final guidelines were never adopted by the agency. NIOSH conducts safety-related RF studies through its Physical Agents Effects Branch in Cincinnati,Ohio.
The NTIA is an agency of the U.S. Department of Commerce and is responsible for authorizing Federal Government use of the RF electromagnetic spectrum. Like the FCC, the NTIA also has NEPA responsibilities and has considered adopting guidelines for evaluating RF exposure from U.S. Government transmitters such as radar and military facilities.
The Department of Defense (DOD) has conducted research on the biological effects of RF energy for a number of years. This research is now conducted primarily at the U.S. Air Force Research Laboratory located at Brooks Air Force Base, Texas. The DOD Web site for RF biological effects information is listed with other sites in conjunction with a question on other sources of information, below.
Who funds and carries out research on the biological effects of RF energy?
Research into possible biological effects of RF energy is carried out in laboratories in the United States and around the world. In the U.S., most research has been funded by the Department of Defense, due to the extensive military use of RF equipment such as radar and high-powered radio transmitters. In addition, some federal agencies responsible for health and safety, such as the Environmental Protection Agency (EPA) and the U.S. Food and Drug Administration (FDA), have sponsored and conducted research in this area. At the present time, most of the non-military research on biological effects of RF energy in the U.S. is being funded by industry organizations. More research is being carried out overseas, particularly in Europe.
In 1996, the World Health Organization (WHO) established the International EMF Project to review the scientific literature and work towards resolution of health concerns over the use of RF technology. WHO maintains a Web site that provides extensive information on this project and about RF biological effects and research (www.who.ch/peh-emf).
FDA, EPA and other US government agencies responsible for public health and safety have worked together and in connection with WHO to monitor developments and identify research needs related to RF biological effects.
How does FCC Audit Cell Phone RF?
After FCC grants permission for a particular cellular telephone to be marketed, FCC will occasionally conduct “post-grant” testing to determine whether production versions of the phone are being produced to conform with FCC regulatory requirements. The manufacturer of a cell phone that does not meet FCC’s regulatory requirements may be required to remove the cell phone from use and to refund the purchase price or provide a replacement phone, and may be subject to civil or criminal penalties. In addition, if the cell phone presents a risk of injury to the user, FDA may also take regulatory action. The most important post-grant test, from a consumer’s perspective, is testing of the RF emissions of the phone. FCC measures the Specific Absorption Rate (SAR) of the phone, following a very rigorous testing protocol. As is true for nearly any scientific measurement, there is a possibility that the test measurement may be less than or greater than the actual RF emitted by the phone. This difference between the RF test measurement and actual RF emission is because test measurements are limited by instrument accuracy, because test measurement and actual use environments are different, and other variable factors. This inherent variability is known as “measurement uncertainty.” When FCC conducts post-grant testing of a cell phone, FCC takes into account any measurement uncertainty to determine whether regulatory action is appropriate. This approach ensures that when FCC takes regulatory action, it will have a sound, defensible scientific basis.
FDA scientific staff reviewed the methodology used by FCC to measure cell phone RF, and agreed it is an acceptable approach, given our current understanding of the risks presented by cellular phone RF emissions. RF emissions from cellular phones have not been shown to present a risk of injury to the user when the measured SAR is less than the safety limits set by FCC (an SAR of 1.6 w/kg). Even in a case where the maximum measurement uncertainty permitted by current measurement standards was added to the maximum permissible SAR, the resulting SAR value would be well below any level known to produce an acute effect. Consequently, FCC’s approach with measurement uncertainty will not result in consumers being exposed to any known risk from the RF emitted by cellular telephones.
FDA will continue to monitor studies and literature reports concerning acute effects of cell phone RF, and concerning chronic effects of long-term exposure to cellular telephone RF (that is, the risks from using a cell phone for many years). If new information leads FDA to believe that a change to FCC’s measurement policy may be appropriate, FDA will contact FCC and both agencies will work together to develop a mutually-acceptable approach