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).