January 11, 1999
TITLE:
The IP Modem Interface Standard
DRAFT
January 11, 1999
SOURCE:
Portable Computer and Communications Association
Modem Standards Committee
P.O. Box 924
Brookdale, California 95007 U.S.A
Telephone: (408) 338-0924
Fax: (408) 338-7806
Contact:
Jim Panian, Editor 919 472-7220, panian@rtp.ericsson.se.
Christopher Burke, 425 487-5917, burke@ipSA.mot.com
Emil Sturniolo,
330 723-9099, emils@wrq.com
Peter Rysavy,
206 517-5654
Copyright  1999 PCCA. All Rights Reserved.
Page 1
January 11, 1999
TABLE OF CONTENTS
1
SCOPE .................................................................................................................................................... 4
2
REFERENCES ...................................................................................................................................... 4
3
TERMINOLOGY .................................................................................................................................. 4
3.1
3.2
3.3
COMMONLY USED TERMS ........................................................................................................ 4
SUPPORTING DEFINITIONS ....................................................................................................... 5
OPEN ISSUES................................................................................................................................. 6
4
REQUIREMENTS ................................................................................................................................ 6
5
IP MODEM ARCHITECTURE .......................................................................................................... 7
5.1
INTERNET DIAL-UP NETWORKING ......................................................................................... 7
5.2
GSM “FAST CONNECT” WIRELESS INTERNET ACCESS ....................................................... 8
5.3
CDPD WIRELESS INTERNET ACCESS ...................................................................................... 8
5.4
EMBEDDED INTERNET: THE IP MODEM ARCHITECTURE .................................................. 9
5.4.1
Description ............................................................................................................................ 10
5.4.2
Other Service Agents ............................................................................................................. 11
5.4.3
Alternatives and cost effectiveness ........................................................................................ 12
5.4.4
Additional advantages/applications ...................................................................................... 12
6
IP MODEM IMPLEMENTATION ................................................................................................... 14
6.1
INTRODUCTION ......................................................................................................................... 14
6.2
VIRTUAL CHANNELS....................................................................................................................... 14
6.3
IP MODEM APPLICATION MODEL .......................................................................................... 15
6.4
IP MODEM INTERFACE IS A SIMPLE ROUTER ..................................................................... 16
6.5
LOCALLY HOSTED SERVICE AGENT ..................................................................................... 16
6.6
CLASSES OF OPERATION.................................................................................................................. 17
6.7
IP ADDRESS ASSIGNMENTS TO THE IP MODEM ............................................................................... 17
6.7.1
IP modem uses statically assigned IP addresses ................................................................... 17
6.7.2
IP modem uses self-administered IP addresses. .................................................................... 17
6.7.3
IP modem uses a limited broadcast address. ......................................................................... 17
6.8
IP ADDRESS ASSIGNMENT TO THE DTE .......................................................................................... 17
6.8.1
IP modem transfers the IP address to DTE by restarting PPP.............................................. 18
6.8.2
IP modem provides a dummy IP address and functions as a proxy ...................................... 18
6.8.3
IP modem provides a Virtual Private Network ...................................................................... 19
6.9
REQUIREMENTS FOR A DCE IMPLEMENTING IP MODEM .................................................................. 20
6.10 REQUIREMENTS FOR A DTE INTERFACING TO AN IP MODEM ................................................. 20
7
REQUIREMENTS FOR A MINIMAL IMPLEMENTATION OF IP MODEM ......................... 20
8
AT COMMANDS ................................................................................................................................ 22
8.1
8.2
8.3
8.4
8.5
8.6
9
AT +WIPC - CONFIGURE THE IP MODEM INTERFACE ........................................................... 22
AT +WIPM - INTERROGATE THE IP MODEM INTERFACE ...................................................... 24
AT +WIPA – ASSIGN AN IP ADDRESS TO A SERVICE AGENT ......................................................... 26
AT +WIPT – CONTEXT MANAGEMENT.......................................................................................... 28
AT+WDSM46 – WIRELESS DATA STACK MULTIPLE SCANNING PRIORITY LIST ............................. 30
COMPOUND PARAMETER IP_SPEC ................................................................................................. 32
SCENARIOS ........................................................................................................................................ 34
9.1
9.2
CDPD PC CARD IS CONFIGURED TO INVOKE THE IP MODEM INTERFACE ................... 34
A DISCONNECTION CANCELS THE IP MODEM INTERFACE ............................................. 36
Copyright  1999 PCCA. All Rights Reserved.
Page 2
January 11, 1999
Copyright  1999 PCCA. All Rights Reserved.
Page 3
January 11, 1999
1
SCOPE
This is the draft PCCA IP modem standard.
2
REFERENCES
Table 1. References
/1/
/2/
/3/
/4/
/5/
/6/
/7/
/8/
PCCA STD-101, Data Transmission Systems and Equipment - Serial Asynchronous Automatic
Dialing and Control for Character Mode DCE on Wireless Data Services. June, 1995 (PCCA
STD-101)
Framework For A Standard DTE-DCE Interface Using Internet Protocols To Deliver Integrated
Multimedia Services, Burke and Sturniolo. September, 1997
PCCA ANX-101 L, Command Set Extensions for CDPD Modems. March, 1998 (Annex L)
Internet Protocol. Internet RFC 791, J. Postel. September, 1981 (RFC 791)
Requirements for Internet hosts - communication layers. Internet RFC 1122, R.T. Braden.
October, 1989 (RFC 1122)
Requirements for Internet hosts - application and support. Internet RFC 1122, R.T. Braden.
October, 1989 (RFC 1123)
Internet Protocol, Version 6 (IPv6) Specification. Internet RFC 1883, S. Deering & R. Hinden.
December 1995 (RFC 1883)
Microsoft Windows 95 Dial-Up Networking 1.2 Upgrade PPTP Information Technical Details
on Use of PPTP Tunnels, Microsoft Corporation, 1996.
3 TERMINOLOGY
3.1
COMMONLY USED TERMS
IP Modem -
Service Agent -
A Virtual Remote End System within an IP Modem, with which the
DTE interacts by means of IP datagrams transferred across the DDL
having a specified IP address, protocol type, and port number/frame
type (whichever is applicable).1
SA-DCE -
Service Agent DCE. An IP Modem incorporating at least one service
agent.
DDL -
1
DCE which, in at least one operating mode, generates and interprets
Internet Protocol (IP) datagrams conveyed over the DDL, typically by
means of one or more Virtual Remote End Systems. See also Service
Agent DCE (SA-DCE).
DTE-DCE Data Link. The communication circuit and procedures
between DCE and DTE, which are assumed to provide at least halfduplex, substantially reliable bi-directional transfer of an octet stream.
All other attributes of the DDL are irrelevant to general architectural
principles of the IP Modem.
ICMP or GRE do not use port numbers but frames types to demultiplex the data stream.
Copyright  1999 PCCA. All Rights Reserved.
Page 4
January 11, 1999
Network -
Service -
A means of interconnecting two or more End Systems. The means of
interconnection and interconnection protocols (whether data, voice,
audio, video, integrated services, virtual, etc.) are irrelevant to general
architectural principles of the IP Modem.
Any task performed by an End System on behalf of a user, another End
System, or itself. Typical services include data conversion, I/O, data
distribution, routing, database access, notification, etc.
AT Command Service Agent A service agent that provides a standards-based IP interface to an AT
command set interpreter (e.g. by accepting AT commands encapsulated
in UDP, and by issuing responses encapsulated in UDP).
PPTP-
3.2
PPTP is a tunneling protocol defined by the PPTP Forum that allows
PPP packets to be encapsulated within Internet Protocol (IP) packets
and forwarded over any IP network, including the Internet itself. PPTP
provides support for virtual LAN connection establishment/release and
encapsulation of higher level protocol frames within the Generic
Routing Encapsulation (GREv2) over IP. GREv2 encapsulation is
connectionless, and is carried directly on top of IP. PPTP provides for
congestion control using a sliding window mechanism.
SUPPORTING DEFINITIONS
DTE -
Data Terminal Equipment. Any terminal, computer, or information
appliance capable of providing commands and data to operate DCE.
DTE does not necessarily incorporate a user interface, but may. Typical
DTE performs computing, service, and user interface functions.
DCE -
Data Circuit-Terminating Equipment. Any device (e.g. wireless modem,
smart phone) that connects DTE to one or more real or virtual
Networks. The phrase “circuit-terminating” is historical and does not
imply any operating characteristic of any Network. DCE does not
necessarily incorporate a user interface, but may. Typical DCE
interconnect with and transfer information between real or Virtual
Remote End Systems.
End System -
A generalized system component which performs the combined
functions of DTE and DCE. DTE and DCE interconnected via a DDL
form an End System, but the designation End System does not imply
incorporation of either DCE or DTE.
NOTE: Although PCCA STD-101 distinguishes between an End System
and an Intermediate System, the distinction is irrelevant with respect to
general architectural principles of the IP Modem; the term End System
is used in this document for either type of system.
Local End System -
Term used to discuss interactions among End Systems. The Local End
System is the end system being discussed; the Remote End System is
the “other” End System with which it interacts.
Copyright  1999 PCCA. All Rights Reserved.
Page 5
January 11, 1999
3.3
Remote End System -
Term used to discuss interactions among End Systems. An End System
connected to another through a Network. See Local End System.
VRES-
Virtual Remote End System. An End System indistinguishable from a
Remote End System, but implemented internally to the Local End
System (e.g. by software or other means within the DCE). Typically
used to implement a service agent.
Virtual Channel -
A communications path between an application on the DTE and a
service agent.
OPEN ISSUES
1.
2.
3.
We need to architect the Directory service agent. The service location protocol is a
possibility; or a lightweight directory service.
Can 1.X addresses be reserved for use by IP modem service agents?
Can DHCP be used to assign IP addresses to the DTE as IP addresses assigned by the
network change when the IP modem attaches to different IP networks?
4 REQUIREMENTS
1.
2.
3.
4.
5.
Describe a next-generation model of fixed and mobile computing services consistent with
projected evolution of computing, mobility, telecommunication, and Internet architectures.
Enable multiple applications on a DTE to interact simultaneously with a SA-DCE. Some
examples are:
 Phonebook management
 SMS management
 User interface menus provided for PC card wireless modems.
 Battery level/signal strength
Provide a well-defined Internet integrated services migration path for legacy AT commandbased telecommunication applications (e.g. data, fax, voice telephony, DCE-based phonebook,
mobile short messaging and control panel functions), with minimal application impact.
Support time-constrained applications such as voice, video, and interactive gaming.
Support multiple, simultaneous applications that perform circuit-switched data/fax and packetbased protocols that use AT commands.
5
Copyright  1999 PCCA. All Rights Reserved.
Page 6
January 11, 1999
6 IP MODEM ARCHITECTURE
The IP Modem architecture results from simple extension of the Internet dial-up networking paradigm, and
is fully consistent with PCCA STD-101 (Dialing and Control for Character Mode DCE on Wireless Data
Services), PCCA ANX-101 L (Command Extensions for CDPD Modems), and contemporary wireless
Internet remote access techniques such as those used by GSM and CDPD.
6.1
INTERNET DIAL-UP NETWORKING
Figure 1 illustrates the dial-up networking paradigm familiar to most Internet users.
Service
(FTP Sites)
DTE
ISP
DCE
IP
IP
IP
over
V.24
IP
over
V.24
V.42
V.42
Modem
Bank
PSTN
“The Internet”
IP
IP
IP
Service
(email Hosts)
Service
(WWW Sites)
Service
(FAX Servers)
Figure 1. Internet Dial-Up Networking Paradigm
The DTE and DCE of Figure 1 are interconnected by an RS-232 or similar communication port using V.24
circuits. A DTE application or service opens an Internet connection, causing the DTE to issue AT
commands to the DCE. These AT commands instruct the DCE to dial the telephone number of an Internet
Service Provider (ISP). Dialing and subsequent data link protocol negotiation creates a durable two-way
circuit between the DCE and a modem bank connected to the ISP. The DCE informs the DTE that the
circuit is available by transmitting a CONNECT code; the modem bank similarly informs the ISP of the
connection. The DCE and modem bank then switch themselves to a mode in which they can transceive data.
The ISP is capable of routing internet traffic (IP datagrams) between the DTE and other Internet-enabled
sites, such as WWW sites or an email host. Both the ISP and the DTE expect to transmit and receive IP
datagrams and certain other signaling (such as call termination) on the circuit.
The DTE composes IP datagrams and forwards them to the DCE, which forwards them to the modem bank,
which forwards them to the ISP, which forwards them to the desired Internet site, host, or server. Once the
circuit has been established, a host, site, or server reverses the path to send datagrams to the DTE. The
circuit persists until either the DTE or the ISP “hangs up”, disconnecting the DTE from the Internet. Both
the DCE and the modem bank respond to a “hang up” by preparing themselves to process future AT
commands.
Most of this behavior is invisible to the user of the DTE. However, since telephone calls aren’t guaranteed
to work (e.g. busy signal, system failure, improper cabling) the DCE often provides feedback to the DTE or
directly to the user during dialing.
Copyright  1999 PCCA. All Rights Reserved.
Page 7
January 11, 1999
6.2
GSM “FAST CONNECT” WIRELESS INTERNET ACCESS
Several techniques are used to access the Internet using a GSM phone. One new technique, “fast connect”,
uses slightly different connections than those of Figure 1. Every effort is made to conceal these differences
from the user (and from DTE application software); the illusion of dial-up networking is preserved. Figure 2
illustrates the GSM “fast connect” wireless internet access paradigm.
Service
(FTP Sites)
DTE
IP
over
V.24
IP
IP
IWF
DCE
GSM
“The Internet”
GS M
GSM
Network
IP
IP
IP
Service
(email Hosts)
Service
(WWW Sites)
Service
(FAX Servers)
Figure 2. GSM “Fast Connect” Wireless Internet Access Paradigm
As in Figure 1, the DTE and DCE of Figure 2 are interconnected by an RS-232 or similar communication
port using V.24 circuits. A DTE application or service opens an Internet connection, causing the DTE to
issue AT commands to the DCE. These AT commands instruct the DCE to dial the telephone number of an
Interworking Function (IWF) maintained by the GSM network operator. The DCE is specially designed to
interact directly with the IWF, rather than with the PSTN. Dialing and subsequent data link protocol
negotiation creates a durable two-way circuit between the DCE and the IWF. The DCE informs the DTE
that the circuit is available by transmitting a CONNECT code; the IWF is implicitly aware of the
connection. The DCE and IWF then switch themselves to a mode in which they can transceive data.
The IWF is capable of routing internet traffic (IP datagrams) between the DTE and other Internet-enabled
sites, such as WWW sites or an email host. Both the IWF and the DTE expect to transmit and receive IP
datagrams and certain other signaling (such as call termination) on the circuit.
The DTE composes IP datagrams and forwards them to the DCE, which forwards them to the IWF, which
forwards them to the desired Internet site, host, or server. Once the circuit has been established, a host, site,
or server reverses the path to send datagrams to the DTE. The circuit persists until either the DTE or the
IWF “hangs up”, disconnecting the DTE from the Internet. The DCE responds to a “hang up” by preparing
itself to process future AT commands.
6.3
CDPD WIRELESS INTERNET ACCESS
CDPD and other packet switched networks also offer wireless internet access, using a topology that differs
from both dial-up access and GSM remote access. Both the PSTN and GSM are circuit-switched, whereas
CDPD is packet-switched.
The idea of dial-up networking might seem superfluous on a packet-switched network, but every effort is
made in CDPD to preserve the illusion of dial-up networking, in order to make the technology more
familiar to the user (and to DTE applications). Figure 3 illustrates the paradigm.
Copyright  1999 PCCA. All Rights Reserved.
Page 8
January 11, 1999
Service
(FTP Sites)
DTE
IP
over
V.24
DCE +
ISP VRES
IP
“The Internet”
IP
over
CDPD
IP
IP
CDPD
Network
IP
IP
Service
(email Hosts)
Service
(WWW Sites)
Service
(FAX Servers)
Figure 3. CDPD Wireless Internet Access Paradigm
Compare Figure 3 to Figure 2. The GSM IWF is missing, replaced by a Mobile Data Intermediate System
(MDIS) internal to the CDPD network. The MDIS acts like an Internet bridge / router, giving the
appearance that the CDPD network is fully integrated into the Internet.
Next, compare Figure 3 to Figure 1. The ISP is missing, replaced by a Virtual Remote End System (VRES)
incorporated into the DCE and emulating an Internet Service Provider.
The circuit-switched connection provided by the PSTN (Figure 1) or the GSM Network (Figure 2) is
replaced in CDPD (Figure 3) by a software state machine within the DCE. This state machine simply keeps
track of what AT commands the DTE issues; when an appropriate ATD command is issued, the state
machine places the DCE into a mode in which it can transceive data.
While in data transceiving mode (corresponding to the On-Line Data State of a conventional telephone
modem) software within the DCE transfers data received from the DTE to the internal VRES instead of
over the CDPD network. The VRES interprets the data stream exactly as an ISP would, i.e. as a series of IP
datagrams encapsulated in SLIP or PPP. It removes the encapsulation, and used CDPD protocols to forward
each IP datagram to the MDIS. The MDIS then forwards the datagram to the addressed Internet site, host,
or server. Traffic from a site, host, or server follows the reverse path.
The DTE disconnects from CDPD in the same way as it does for dial-up or GSM, but the internal
processing within the DCE is quite different for CDPD. Instead of signaling a “hang up” to the MDIS, the
CDPD modem simply adjusts its internal state machine and prepares to accept additional AT commands.
Metricom’s Ricochet wireless network employs similar techniques, and similar techniques have been
proposed for future packet-switched GSM systems (iDEN, GPRS, UMTS).
6.4
EMBEDDED INTERNET: THE IP MODEM ARCHITECTURE
Figures 1 through 3 illustrate the continuous evolution of the AT command set Internet access paradigm for
Data Circuit-Terminating Equipment (DCE). The IP Modem Architecture extrapolates this evolutionary
trend, integrating portions of the Internet itself into the DCE (requirement 1) while supporting legacy
applications and providing an Internet-friendly interface to non-internet communication services
(requirement 2, 3).
Copyright  1999 PCCA. All Rights Reserved.
Page 9
January 11, 1999
Figure 3 introduced the idea of a VRES inside of the DCE, offering services previously provided by an ISP
on the other side of the wired or wireless network. Moving the ISP into the DCE gives the DCE control
over datagram routing, opening the door to implementing an “intranet” and a “firewall” within the DCE, as
shown in Figure 4.
To DTE
DDL (AT Commands, IP Datagrams, Other)
AT State
Machine
AT Cmd
Svc. Agent
AT Cmd
Interpreter
IP
IP
Internal IP
Router
DCE Virtual
Intranet
IP
ISP VRES
IP
IP
IP
DCE
Other Net.
Svc. Agent
To native services
of other network
Other Svc.
Agent
to additional
service agents
To native +WS 46
network services
+WS46 Bridge
Service Agent
IP over ???
IP to Internet via
+WS 46 network
Figure 4. IP Modem Architecture (DCE Only)
6.4.1 Description
Figure 4 illustrates the IP Modem Architecture. The DCE described in Figure 4 can be used in various
system configurations such as those shown in Figure 1, Figure 2, or Figure 3 if appropriate Service Agents
are included.
The DCE behaves as an IP modem only for specific settings of +WS45 and +WS46. The remainder of this
description assumes that the appropriate +WS45 and +WS46 settings are selected.
The DTE and DCE are interconnected via a DTE-DCE Data Link, DDL, as defined elsewhere in this
document. The DDL is used to convey AT Commands, IP Datagrams, and possibly other (legacy) types of
information between DTE and DCE.
The DCE services the DDL using an AT State Machine. The AT State Machine keeps track of the current
settings of +WS45 and +WS46, other parameter settings, and whether the IP Modem is in Command State,
On-Line Command State, or On-Line Data State. When the modem is in Command State or On-Line
Command State, the AT State Machine monitors for state changes (e.g. disconnect, ring) but passes all other
data to the AT Command Interpreter, which processes AT commands, updates internal parameter values,
executes action commands, and returns responses. When the modem is in On-Line Data State, the AT State
Machine monitors for state changes (e.g. via +++ or a drop in the DTR modem control line) but passes all
other data to the Internal IP Router. In other words, in an IP Modem the ATD command connects the DTE
to the Internal IP Router, not to the communication network. The Internal IP Router, and portions of the AT
State Machine, are equivalent to the ISP Virtual Remote End System (ISP VRES) described for CDPD
modems.
Copyright  1999 PCCA. All Rights Reserved.
Page 10
January 11, 1999
The Internal IP Router may reserve a range of IP addresses (e.g. 1.x.x.x, 10.x.x.x, or limited broadcast
addresses under IPv4) for use on the DCE Virtual Intranet. Datagrams with destination addresses in this
range are "routed" onto the DCE Virtual Intranet; all other datagrams are "routed" to the correct +WS46
service agent. The router can be extremely simple; one simple implementation is a switch statement that
invokes different subroutines based on the value of the destination IP Address field of the datagram.
The DCE Virtual Intranet is simply an internal message passing discipline: IP datagrams are passed (e.g. as
an interprocess message) to a corresponding software entity (e.g. a task) that implements one or more
service agents based upon a given IP address and transport information .
There is no inherent need for ICMP, RARP, PPP, or other supporting internet protocols for service agents
that are always “reachable” and there are never any transmission errors or transmission inefficiencies on this
virtual internet. However, supporting Internet protocols such as ICMP, RARP, or PPP may be needed for
service agents that may pop in or out of existence based upon services dynamically available based upon the
service provider an IP modem is currently connected to. service agents need not implement most of the
communication protocols required of standard Internet hosts (DNS, FTP, SNMP, etc.). Typical service
agents will need to support either UDP or TCP (e.g. using a reentrant TCP/IP library), and that some may
wish to use ICMP to report buffer overflow and related run-time errors. Real-time applications may require
RSVP and related protocols. Despite its simplified implementation, the DCE Virtual Intranet looks exactly
like a local IP subnet from the DTE’s vantage point, and satisfies the spirit (but probably not the letter...) of
applicable sections of Internet standards /4/, /5/, /6/, /7/.
The +WS46 service agent handles transfer of IP datagrams to and from the Internet, using the network
currently selected by +WS46. This might be implemented as a single task that “knows” the current setting of
+WS46 and behaves accordingly, or it might be implemented as a collection of tasks, one of which is
instantiated based on the setting of +WS46; other implementations are possible. The +WS46 service agent
passes IP datagrams received from the Internal IP Router across the network, and passes IP datagrams
received from the network to the Internal IP Router.
The +WS46 service agent may be arbitrarily complex. For example, it may have an address on the DCE
Virtual Intranet to allow run-time configuration by the DTE or other service agents, and it may use a priori
knowledge of network attributes and availability to implement support for +WS46=15 (multiple concurrent
WDSs). It may provide an Internet interface to non-IP functions of the selected network (e.g. two-way realtime voice communication) by performing transcoding, filtering, and buffering functions.
In the voice example, the Internal Internet Router could support the RSVP bandwidth reservation protocol
across the DDL. There’s never more than one hop between a service agent and the DTE, so resource
reservation is relatively simple and predictable. The DTE would reserve bandwidth on the DDL, and the
+WS46 service agent would use the reserved DDL bandwidth to pass encapsulated CODEC data to the
DTE for audio processing and presentation by a DTE-based digital signal processor. Similarly, the DTE
would use reserved DDL bandwidth to pass processed microphone audio to the service agent for
transmission over the network. The service agent would handle call setup and teardown, under control of a
DTE application.
6.4.2 Other Service Agents
Many kinds of service agents are possible. For example, a service agent in the IP Modem (not necessarily a
mobile or portable device) could implement an Internet FAX server, storing received Group 3 FAX in
internal memory, for subsequent transmission to the DTE as MIME-encapsulated TIFF. Another service
agent could implement an internal WWW site containing the user interface of the modem’s control panel,
allowing the user interface to run either on a built-in keyboard and display (e.g. smart phone) or on a
connected laptop or desktop computer. A service agent could continuously monitor a secondary
Copyright  1999 PCCA. All Rights Reserved.
Page 11
January 11, 1999
communication channel (e.g. a paging receiver) independently of the setting of +WS46, to provide out-ofband notifications to the user, the DTE, or other service agents.
One specialized service agent is the AT Command Service Agent. This type of service agent processes IPencapsulated AT commands and legacy data streams from the DTE. The DCE may instantiate multiple AT
Command service agents to execute concurrently within a single IP Modem. Potentially one instantiation
can be in On-Line Data State, while another is in On-Line Command State. Also, potentially two
instantiations can have conflicting AT parameter settings, or one instantiation can attempt to execute an
action command having unfortunate side effects on another instantiation. The rules for instantiating and
managing concurrency in AT Command service agents are implementation dependent.
Why build an AT Command service agent, when contradicts a major objective of the IP Modem effort
(alignment of modem architecture with Internet architecture)? Answer: The AT Command service agent
provides a way to support legacy modem applications concurrently with new, IP-based applications. This
requires either minor (one hopes) modification of the legacy application (i.e. to send and receive data using
a socket instead of COM: port interrupt service routine), or implementation of a custom DDL driver that
interposes on the IP datagram stream between DTE and DCE, implementing Virtual COM: Ports for
unmodified legacy applications.
Virtual COM: Ports is a programming technique that can be used on operating systems that provide a
hardware-independent, high-performance device driver interface allowing multiple serial data
communication ports. The basic trick is to write a device driver that advertises itself as a serial port driver,
but that actually sends and receives data by some other means - in this case, encapsulated within UDP/IP
and interleaved with other DDL traffic on datagram boundaries. The subtle timing, memory management,
and operating system interface issues that must be mastered before writing a Virtual COM: Port driver are
beyond the scope of this document, but the art is well-known; numerous examples of success can be found
in commercial products and on the Internet (for example, TCPSerial for the Macintosh).
6.4.3 Alternatives and cost effectiveness
Any architecture is potentially more expensive to develop, but less expensive to maintain, than a highlyoptimized non-architected solution. The IP Modem Architecture should have better economics than handoptimized code in any environment where the modem feature set changes rapidly and multiple modem
features (e.g. voice, fax, and short message) must interoperate concurrently.
Alternatives such as EMP (a simple HDLC-based protocol) and Virtual COM: Ports (a specialized
Windows driver operating in concert with EMP), have been proposed by other standards organizations as a
means to operate multiple legacy features concurrently. The stated implementation requirements for EMP
and Virtual COM: Ports are much lower than current IP Modem estimates, but EMP is much less capable
than IP Modem of providing integrated Internet access. The Virtual COM: Port technique is highly specific
to a particular computing platform; it works with Windows, but does it work with Windows CE, PalmOS,
OS9, or GEOS? Also, it’s relatively difficult to attach a new application using the Virtual COM: Port
scheme, due to a proposed static mapping of COM: port IDs to device functions (e.g. COM4: might be
FAX, COM5: might be coded voice).
In contrast, the use of IP for multiplexing is compatible with any operating system platform that supports
TCP/IP, without special drivers, and it provides a simple way of attaching a new application at the nearuniversal TCP/IP Sockets interface.
6.4.4 Additional advantages/applications
What can be done with a DCE-based “intranet”? For one thing, the DCE can provide concurrent access to
multiple services (e.g. simultaneous voice and FAX, simultaneous data transmission and control panel
monitoring) by incorporating a “server” (service agent) for each service and using IP as a multiplexing
Copyright  1999 PCCA. All Rights Reserved.
Page 12
January 11, 1999
protocol. In most cases, it’s a simple matter to encapsulate whatever protocol was used previously (whether
AT commands, or Group 3 Fax data, or voice CODEC data) in UDP over IP.
Just as the ISP, a Remote End System, could be moved into the DCE without impacting DTE applications
or the user, the IP Modem Architecture allows other Remote End Systems (such as a web site or a FAX
server) to migrate into the DCE.
Multiplexing using IP overcomes a painful limitation of AT commands: their modality. In many modern
networks (e.g. CDPD, GPRS, UMTS) AT modality is imposed artificially on the DTE-DCE interface -- to
increase compatibility with legacy applications, and for lack of a better alternative. IP multiplexing
preserves AT modality during connection and disconnection from the Internet, but eliminates modality
when modality hurts most: during data communication.
For example, an AT modem is either in command state, or in data state (ATD, ATH, ATA, ATO and +++); it
is either in FAX mode, Data mode, or SMS mode (+FCLASS and +WS45); it connects either via a
telephone line, or cellular, or packet data (+WS46). IP multiplexing allows the modem to be in all of these
modes and states at once, by assigning each set of functions to a different VRES and allowing the VRES to
share access to the DDL on a per-datagram basis.
DTE memory and computing power are almost always more economical than DCE memory and computing
power. For this reason it might make sense to implement some or all of the IP Modem Architecture inside
of the DTE, rather than or in addition to inside of the DCE.
Copyright  1999 PCCA. All Rights Reserved.
Page 13
January 11, 1999
7 IP MODEM IMPLEMENTATION
7.1
INTRODUCTION
The IP modem architecture enables one or more SA-DCE to simultaneously communicate with multiple
applications on a DTE. For example, application #1 on the DTE can perform remote menuing, battery level,
and signal strength display. Application #2 on the DTE can perform SMS management. Application #3 (a
web browser) on the DTE can be connected to the World Wide Web. The IP modem interface exists
between the DTE and the DCE. Support of the IP modem interface is determined by the DTE issuing the
AT +WIPM command while the DCE is in the AT command state. If the modem supports an IP modem
interface, the AT+WIPM modem command will return a list of service agents supported by the DCE that
are directly addressable by the DTE using standard Internet Protocol (IP) packet encapsulation. Once the
device is determined capable of providing an IP modem interface, the DTE issues the commands
AT+WS46=15 and +WS45=[3,4,18,19] to invoke either IP with SLIP/CSLIP encapsulation or negotiate IP
encapsulation over PPP when on-line data mode is entered.. The DTE must then perform a dial operation
(ATD) to transition the DCE into connected state (i.e. on-line data mode) before the SA-DCE expects IP
frames.
7.2
VIRTUAL CHANNELS
A SA-DCE presents a virtual channel to a single application on the DTE. The IP modem model provides
for a number of virtual channels to be established between applications on the DTE and SA-DCEs on the IP
modem.
Virtual Channel 1
DTE
Application #1
DCE-SA #1
Virtual Channel 2
DTE
Application #N
Virtual Channel N
DCE-SA #2
Figure 1. Virtual channels
Copyright  1999 PCCA. All Rights Reserved.
Page 14
January 11, 1999
7.3
IP MODEM APPLICATION MODEL
The IP Modem architecture supports both Native IP (Internet-aware) and legacy (AT command set, serial
port-aware) DTE applications.
Native IP applications such as the Web Browser shown in Figure 2 interact directly with the DTE TCP/IP
protocol stack via Sockets or a similar standard interface. They are completely unaware of the presence of
an IP Modem.
Two techniques allow sharing of an IP Modem among multiple Com Port applications. Com Port
applications are legacy applications that expect to take total control of a modem connected to a serial port,
changing between command and data state and reconfiguring the modem at will.
The first technique is illustrated in Figure 2. SMS AT Application* and Phonebook Application* have been
modified by their respective software authors to use Sockets to tunnel AT commands and data to an AT
Command service agent within the IP Modem, instead of sending AT commands and data over a dedicated
serial port. The level of modification required with this technique depends on the internal structure of the
application; in any case, the modification makes the application “IP Modem-aware”.
SMS AT
Application*
Phonebook
AT
Application*
Web Browser
Application
Sockets
UDP or TCP
IP
PPP or SLIP
Physical Layer – Serial Link
Figure 2. Native IP Applications on the DTE
Figure 3 illustrates interfacing of unmodified Com Port applications to the IP Modem. A Virtual Com Port
Driver is installed into the DTE operating system. This driver advertises itself to applications as providing
support for additional serial I/O ports (e.g. COM5: - COM8: for four ports on a Windows® machine), but
actually transmits and receives data by encapsulating it in UDP/IP and forwarding it to predetermined AT
Command service agents. The Virtual Com Port Driver permanently maps a given COM: port to a given
service agent; for example, the SMS service agent might always map to COM5:, while the Phonebook
service agent might always map to COM:7. It is up to the user to properly configure each application to use
the correct COM: port..
Copyright  1999 PCCA. All Rights Reserved.
Page 15
January 11, 1999
SMS AT
Application
Web Browser
Application
encapsulation
Sockets
UDP or TCP
IP
PPP or SLIP
Virt.ComPortDriver
Physical Layer – Serial Link
Figure 3. Com Port Applications and Virtual Com Port Driver on the DTE
7.4
IP MODEM INTERFACE IS A SIMPLE ROUTER
When IP modem mode is selected by the DTE, the DCE in essence is acting as a simple router. For each
frame that the IP modem interface receives, based on address/protocol port tuple, it forwards it to the
correct destination. If the destination IP address is the same as the IP modem address, then the IP packet is
handled locally by the DCE or a specific SA-DCE within the DCE. If the destination IP address is not the
same as the IP modem address, then the IP frame is forwarded onto the IP network (if connected) over the
selected AT+WS46 network. If the DCE is not connected to an IP network, then the packet is dropped or
optionally the DCE will return a ICMP error to speed up awareness by the DTE application that its service
request cannot be satisfied. IP packets received from the IP network are routed directly to the DTE.
Note: Some implementations of UDP allow for more then one sender/receiver on a specified port if the
SO_REUSE_ADDR socket option is used when allocating a socket on the DTE. Due to this fact,
serialization of the AT command syntax can not be guaranteed when used in this mode of operation. This
behavior is no different than two applications sending data to the same serial port at the same time.
Problems may arise where multiple UDP applications that issue AT commands on the DTE get assigned
the same UDP port number on the DTE. When the DTE applications try to select the source port
themselves, they can be allocated the same DTE port number. To avoid this situation and to assure unique
port numbers are assigned, a zero local port should be specified by each UDP application. Each application
can then issue get sock name call to obtain its unique port assignment. Assigning unique port numbers to
each DTE UDP application that issues AT commands assures that a single AT command SA-DCE can
distinguish between multiple applications using it. For example, an AT command SA-DCE can distinguish
between two DTE UDP applications by looking for the source IP address/source UDP port of a frame that
contains an AT command.
7.5
LOCALLY HOSTED SERVICE AGENT
The SA-DCE performs a service agent function when it executes an action on the behalf of the requesting
DTE application (a.k.a. an agent). An example of this might be sending a short message. The SA-DCE acts
as a service agent by providing a well-defined interface to the DTE while interacting with a specific
network to realize the request of sending the short message.
Copyright  1999 PCCA. All Rights Reserved.
Page 16
January 11, 1999
In the preferred embodiment, each SA-DCE is accessible at the same IP address and is demultiplexed based
on the required transport protocol (i.e. TCP/UDP/etc.) and pre-defined port number. The list of available
agents/services and the IP address and port number where they reside can be enumerated via the AT+WIPM
command. Alternatively, a range of IP addresses may be reserved by the PCCA for use with a bank of IP
modem SA-DCEs. that communicate with a single DTE. In this implementation each SA agent will be
uniquely accessible by the DTE using the corresponding IP address/transport port tuple. A set of welldefined UDP ports may be reserved for use on the SA-DCE for generic service agent applications such as
an AT command service agent . An AT command service agent application uses predefined AT commands
to control both the global and dynamic behavior of the DCE. Device Note: There may also be other generic
service agent applications defined by the PCCA and assigned to other UDP or TCP ports such for services
such as messaging, voice, or fax as described in /2/.
7.6
CLASSES OF OPERATION
It is possible for an IP modem to offer one to multiple connections to the Internet simultaneously. The
following classes, based upon those used by GSM standards to classify GPRS wireless packet data modems,
are used to identify the connectivity capabilities of an IP Modem.

An IP modem in class-A mode of operation implements multiple connections to the Internet
simultaneously.

An IP modem in class-B mode of operation monitors multiple control channels for possible
connections to the Internet but can only operate one connection at a time.

An IP modem in class-C mode of operation exclusively operates a single connection to the
Internet at a time.
7.7
IP ADDRESS ASSIGNMENTS TO THE IP MODEM
An IP modem must have at least one IP address assigned to it. There are several alternatives, which are
implementation dependent:
7.7.1 IP modem uses statically assigned IP addresses
The IP modem may be given one or more statically assigned IP addresses. The IP modem might be assigned
a single IP address where SA-DCEs are distinguished by port number. Alternatively, the IP modem might
be assigned a set of IP addresses where the SA-DCEs are distinguished by IP address. This is a simple
implementation technique but becomes problematic when it is desired to have a single DTE communicate
with multiple IP modems over different ports. An AT command to change the IP addresses of an IP modem
is defined in this standard, see 0 AT +WIPA – Assign an IP Address to a Service Agent on page 26.
7.7.2 IP modem uses self-administered IP addresses.
The IP modem uses a self-administered address (10.xxx.xxx.xxx or 1.xxx.xxx.xxx). The DTE obtains the
“real” IP address via PPP or through static assignment. The SA-DCEs on the IP modem are distinguished
by port number. Collisions can occur if two DCEs communicating with the same DTE have the same selfadministered address.
7.7.3 IP modem uses a limited broadcast address.
The IP modem uses a limited broadcast address (255.255.255.255 or 0.0.0.0). A limited broadcast address
packet sent by the DTE would not be sent to the network by the IP modem. The DTE obtains its “real” IP
address via PPP or through static assignment. The SA-DCEs on the IP modem are distinguished by port
number. Collisions can occur if two DCEs communicating with the same DTE have SA-DCEs using the
same port number. Only non-connection oriented sessions are allowed.
7.8
IP ADDRESS ASSIGNMENT TO THE DTE
The DTE is assigned an IP address through traditional mechanisms: static assignment or dynamically
through PPP or DHCP. The DTE maintains its IP address according to the policy of the ISP. However,
Copyright  1999 PCCA. All Rights Reserved.
Page 17
January 11, 1999
since an IP modem may provide attachments to the same ISP over different networks (GUTS, GSM Fast
connect, TDMA circuit-switched data) or offer attachment to the same ISP at different times, then the
DTE’s IP address may change. There are several solutions to this problem.
7.8.1 IP modem transfers the IP address to DTE by restarting PPP
When the IP modem is acting as a Virtual Remote End System (VRES); emulating an Internet Service
Provider, then the change in IP address must be conveyed by the IP modem to the DTE. This can be
accomplished by having the IP modem restart IPCP causing a new IP address negotiation between the IP
modem and DTE at the IPCP sublayer of PPP.
To obtain the IP address to provide to the DTE requires some complexity to be built into the IP modem. For
example, if obtaining the IP address from an ISP using PPP, the IP modem may have to be configured to
request parameters such default DNS assignment; scripting to provide authentication information; or offer
the user a pop-up box on the DTE to enter authentication information.
7.8.2 IP modem provides a dummy IP address and functions as a proxy
The IP modem provides a dummy IP address to the DTE as a part of PPP negotiation or with DHCP at
start-up. The DTE always uses the dummy IP address when communicating with SA-DCEs on the IP
modem. The IP modem may contact an ISP when the IP modem receives a packet that isn't destined for a
SA-DCE, or when the IP modem is explicitly instructed to do so by the DTE. The IP modem will receive
the real IP address when it contacts the ISP. From that point on, the IP modem swaps the dummy IP
address with the real IP address for outgoing packets, and performs the reverse operation for incoming
packets.
The weakness in this approach becomes evident when applications on the DTE such as FTP use the dummy
IP address of the DTE as part of its protocol exchange. The FTP client on the DTE would see the dummy
IP address instead of the real IP address and use that as part of its protocol exchange with the FTP server.
The FTP client sends the DTE IP address/port tuple to the FTP server when requesting a file transfer. The
FTP server uses the tuple to make a passive connection back to the FTP client. Once the connection is
established, the FTP client sends a "stor" or "retr" command to either put or get the specified file. It is the
encoding of the dummy IP address in the data stream that causes the problem. Placing an application level
proxy within the IP modem can solve the FTP problem. However, it is unknown how many other
applications won't work correctly because they use the host IP address in a similar fashion to that of FTP.
Copyright  1999 PCCA. All Rights Reserved.
Page 18
January 11, 1999
7.8.3 IP modem provides a Virtual Private Network
IP, IPX,
NBF
IP, IPX,
NBF
PPP
PPP
PPTP
PPTP
IP
IP
IP
IP
PPP
PPP
*
*
V.34, etc.
V.34, etc.
*
*
Client
IP
WAN
IP
Modem
Modem
ISP
Figure 2. IP Modem implements a VPN
IP modem offers a virtual private network (VPN) function with PPTP or L2TP. With this solution, the DTE
is communicating directly with the ISP over the VPN provided by the IP modem. The DTE obtains its IP
address directly from the ISP without intervention by the IP modem.
IP, IPX,
NBF
IP, IPX,
NBF
PPP
PPP
PPTP
PPTP
VPN
SA-DCE
IP
IP
IP
IP
IP
IP
PPP
PPP
PPP
PPP
*
*
V.34, etc.
V.34, etc.
*
.*
*
*
Client
Modem
IP
Modem
IP
WAN
ISP
IP
WAN /
LAN
Server
on
Home
Network
Figure 3. IP modem offers a VPN service agent (VPN SA-DCE)
Copyright  1999 PCCA. All Rights Reserved.
Page 19
January 11, 1999
Using the VPN approach as shown in Figure 2 precludes somebody from actually running a VPN to access
a home network over the Internet. One solution shown in Figure 3 is to have the IP modem provide a VPN
service agent. When the user desires to run a real VPN, the DTE dials into the IP modem and gets a selfadministered 10.x.x.x IP address with PPP or DHCP. Then, a special VPN SA-DCE is instructed by the
DTE to dial and contact the ISP just to establish a link. The presentation of "userid" and "password" for
PPP authentication must be presented back to the DTE through some mechanism.
Therefore, the link between the IP modem and ISP is hidden. Then, the VPN is really presented between the
DTE and the far-end remote access server at the home network. The IP stack on the client uses PPTP to
tunnel a path through the Internet back to its home network. The IP address is obtained by the client from
its home network via the PPP layer that runs on top of PPTP.
Note: Any IP traffic originating in the DTE must first be routed via the VPN and then out from the home
network to the Internet.
7.9
REQUIREMENTS FOR A DCE IMPLEMENTING IP MODEM
Multiplexing using IP doesn’t magically solve the problem of providing concurrent services when the
underlying network is incapable of so doing.
Additional platform requirements depend on the bandwidth and statefulness of each supported application
layer protocol. If the application was previously running on a DCE architecture other than IP Modem (e.g. a
digital voice application such as GSM), migration to the IP Modem Architecture is not expected to increase
platform performance requirements.
7.10 REQUIREMENTS FOR A DTE INTERFACING TO AN IP MODEM
The IP stack on the DTE must add the AT +WIPM command to its AT command initialization string that it
sends to the SA-DCE. Based on the response to the +WIPM by the SA-DCE the application will set
+WS46=15 and +WS45 to indicate the appropriate DTE-DCE interface. If the SA-DCE supports IP
Modem this will cause the SA-DCE to invoke the IP modem interface when on-line data state is entered.
An application that wishes to use the SA-DCE as a service agent must know either the host name or IP
address where the SA-DCE resides. TCP/IP stacks may use a local configuration file that maps host name
to IP address. The IP modem host name to IP modem address mapping must be placed into the
configuration file for applications that wish to use a host name. Also, the DTE application must know the
UDP port numbers to be used to address the AT command service agent applications on the SA-DCE. Note
this information can be gained by parsing the enumerated info text list returned by the AT+WIPM
command. Note: Since the list of services provided by the DCE may not be constant (i.e. dynamic in
nature), the list must also be accessible from the on-line state via reissuing the AT+WIPM command to the
AT command service agent, or through some other method not yet define at the time of this writing.
8 Requirements for a Minimal Implementation of IP Modem
This standard does not intend to constrain the sophistication or level of complexity of an IP modem
implementation. However, the following section provides a description of the functionality that might be
present in a minimal implementation of IP modem:

Possible to pre-configure service agents with AT commands prior to invocation of SLIP or PPP
between the DTE and DCE.

Implementation of AT command service agents are not required. Service agents can use any
protocol running over IP services.

Enable the IP modem to be configured to select which order of +WS46 service agents to use when
attempting a connection to the Internet.
Copyright  1999 PCCA. All Rights Reserved.
Page 20
January 11, 1999
To meet these requirements, the concept of context is introduced. Prior to invoking PPP or SLIP, a DTE
may set up a context to send AT commands to specific service agent to enable configuration prior to
invoking the IP modem interface. The AT+WIPM command returns a context identifier
subparameter. A context identifier is a handle that captures the IP address, port number, and protocol tuple
that is associated with each service agent. The context identifier is later used with AT+WIPT command to
set a context.
The AT+WDSM46 command may be used to preconfigure the IP modem to attempt connections to the
Internet using a prioritized succession of +WS46 service agents.
Copyright  1999 PCCA. All Rights Reserved.
Page 21
January 11, 1999
9 AT COMMANDS
9.1
AT +WIPC - CONFIGURE THE IP MODEM INTERFACE
Parameter Command Syntax:
Description
Sets IP Modem
interface parameters.
Command
AT+WIPC = <error_mode>,
"<ip_modem_class>"
Test Command
Read Command
AT+WIPC=?
AT+WIPC?
Possible Responses
+WIPC: (0,1), ("A","B","C")
+WIPC: <error_mode>, "<ip_modem_class>"
Description:
Allows a DTE to configure the behavior of the IP modem interface. This command can be extended with
additional sub-parameters in the future. Applications should provide compatibility for such future
extensions.
Applicability:
This command may be executed from either the AT command (serial) interface or when the DCE is
behaving as an IP modem.
Abortability:
This command is abortable.
Defined values:
Table 2. <error mode> parameter
<error mode>
0
1
<ip_modem_class>
"A"
"B"
"C"
Description
Undeliverable packet is dropped by the DCE. No ICMP error is returned.
Default.
Undeliverable packets on the DCE will return an ICMP error to the source
application on the DTE.
Description
An IP modem in class-A mode of operation implements multiple connections to
the Internet simultaneously.
An IP modem in class-B mode of operation monitors multiple control channels
for possible connections to the Internet but can only operate one connection at
a time.
An IP modem in class-C mode of operation exclusively operates a single
connection to the Internet at a time. Default.
Result codes:
Table 3. Result Codes
Result Code
OK
ERROR
Description
Acknowledges execution of a command.
Command not recognized, command line maximum length
Copyright  1999 PCCA. All Rights Reserved.
Page 22
January 11, 1999
Result Code
Description
exceeded, parameter value invalid, or other problem with
processing the command line
Execution Time:
Not critical.
Implementation:
Mandatory.
Copyright  1999 PCCA. All Rights Reserved.
Page 23
January 11, 1999
9.2
AT +WIPM - INTERROGATE THE IP MODEM INTERFACE
Action Command Syntax:
Description
Interrogates the
characteristics and
capabilities of the IP
modem interface.
Syntax
AT+WIPM=<type_class>
[,<sub_type>]
Possible Responses
+WIPM: <context_ID>,
<type_class>,<sub_type>,<protocol>,<persistence>,<IP_Spec>,
<CR>
…
+WIPM: <context_ID>,
<type_class>,<sub_type>,<protocol>,<persistence>,<IP_Spec>,
<CR>
Test Command
AT+WIPM=?
+WIPM: (set of supported <type_class>es), (set of supported
<sub_type>s)
Description:
Allows a DTE to determine if the SA-DCE supports the IP modem interface. If the IP modem interface is
supported, this command will return all necessary information regarding each SA supported by this SADCE.
Applicability:
This command may be executed from either the AT command (serial) interface or when the DCE is
behaving as an IP modem.
Abortability:
This command is abortable.
Defined Values:
Table 4. Defined Values
<Field>
<context_ID>
<type_class>
Description
Identifies a service agent. Each service agent has a unique IP address, port
number, and protocol tuple.
0 – default context: DTE-DCE interface. No communication to a service agent.
Default.
1-n – identifies a context that correspond to a service agent.
Identifies the type of service agents that information responses were requested
for.
0 – Directory service agent. Returns information responses for every service
agent. Default.
1 – AT command service agent. Returns information responses for every AT
command service agent.
2 – GUTS service agent. Returns information responses for every GUTS service
agent.
3 – V.80 service agent. Returns information responses for every V.80 service
agent.
4 - +WS46 service agent/AT command service agent.
Copyright  1999 PCCA. All Rights Reserved.
Page 24
January 11, 1999
<Field>
Description
5 - +WS46 service agent
6 to 128 – reserved by this standard.
128 to 256 – reserved for manufacturer specific use.
<sub_type>
Identifies more specifically the service offering of a specific service agent.
Possible values are those from the AT+WS46 <n> subparameter.
<protocol>
<IP_Spec>
“TCP” or “UDP”. UDP is the Default.
The IP address. See 0 Compound Parameter IP_Spec on page 32.
<persistence>
0 – Static. A static service agent is always available in the IP modem. Default.
1 – Dynamic. A dynamic service agent appears only when the underlying
service is present. For example, a dynamic SMS service agent might only appear
when a mobile station is within range of a network that supports SMS.
Result codes:
Table 5. Result Codes
Result Code
OK
ERROR
Description
Acknowledges execution of a command.
Command not recognized, command line maximum length
exceeded, parameter value invalid, or other problem with
processing the command line
Execution Time:
Not timing critical.
Implementation:
Mandatory.
9.3
Copyright  1999 PCCA. All Rights Reserved.
Page 25
January 11, 1999
AT +WIPA – ASSIGN AN IP ADDRESS TO A SERVICE AGENT
9.4
Parameter Command Syntax:
Description
Assigns an IP
address to a SADCE.
Syntax
AT+WIPA=<context_ID>,
<IP_Spec>
Possible Responses
Test Command
Query Command
AT+WIPA=?
AT+WIPA?
+WIPA: (set of <context_ID>s), (set of<IP_Spec>)
+WIPA: <context_ID>, <IP_Spec><cr><lf>
….
+WIPA: <context_ID>, <IP_Spec><cr><lf>
Description:
Allows a DTE to assign a unique IP address to a service agent (SA-DCE). This might be required when a
DTE is communicating with more than one IP modem (DCE) and IP address assignment collisions would
otherwise occur among SA-DCEs on the multiple IP modems. If the IP modem interface is supported, this
command will return all necessary information regarding each SA supported by this SA-DCE.
Applicability:
This command may be executed from either the AT command (serial) interface or when the DCE is
behaving as an IP modem.
Abortability:
This command is abortable.
Defined Values:
Table 6. Defined Values
<Field>
<context_ID>
<IP_Spec>
Description
Identifies a service agent. Each service agent has a unique IP address, port
number, and protocol tuple.
0 – default context: DTE-DCE interface. No communication to a service agent.
Default.
1-n – identifies a context that correspond to a service agent.
The IP address. See 0 Compound Parameter IP_Spec on page 32.
Result codes:
Table 7. Result Codes
Result Code
OK
ERROR
Description
Acknowledges execution of a command.
Command not recognized, command line maximum length
exceeded, parameter value invalid, or other problem with
processing the command line
Copyright  1999 PCCA. All Rights Reserved.
Page 26
January 11, 1999
Execution Time:
Not timing critical.
Implementation:
Mandatory.
9.5
Copyright  1999 PCCA. All Rights Reserved.
Page 27
January 11, 1999
AT +WIPT – CONTEXT MANAGEMENT
9.6
Parameter Command Syntax:
Description
Sets/releases a
context.
Syntax
AT+WIPT=<context_ID>,
<configure>
Possible Responses
Test Command
Query Command
AT+WIPT=?
AT+WIPT?
+WIPT: (set of <context_ID>s), (set of <configure>s)
+WIPT: <context_ID>, <configure>
Description:
Allows a DTE to set up a context to a service agent. When a context to a service agent is established, the
DTE can send AT commands directly to the service agent prior to the invocation of the IP modem interface
(SLIP or PPP established).
A service agent is identified by the <context_ID>, which is returned in response to AT+WIPM. The
<configure> parameter enables a context to start or end.
Only a single context is active at a time.
Applicability:
This command is executed from either the AT command (serial) interface; not when the DCE is behaving as
an IP modem.
Abortability:
This command is abortable. A context is aborted to the default context by reception of ATZ or AT&F.
Defined Values:
Table 8. Defined Values
<Field>
<context_ID>
<configure>
Description
Identifies a service agent. Each service agent has a unique IP address, port
number, and protocol tuple.
0 – default context: DTE-DCE interface. No communication to a service agent.
Default.
1-n – identifies a context that correspond to a service agent.
0 – Context inactive. Default.
1 – Context active.
Result codes:
Table 9. Result Codes
Result Code
OK
ERROR
Description
Acknowledges execution of a command.
Command not recognized, command line maximum length
Copyright  1999 PCCA. All Rights Reserved.
Page 28
January 11, 1999
Result Code
Description
exceeded, parameter value invalid, or other problem with
processing the command line
Execution Time:
Not timing critical.
Implementation:
Optional.
9.7
Copyright  1999 PCCA. All Rights Reserved.
Page 29
January 11, 1999
9.8
AT+WDSM46 – WIRELESS DATA STACK MULTIPLE
SCANNING PRIORITY LIST
Parameter Command Syntax:
Description
Sets a priority list of +WS46
service agents for scanning and
connecting to the Internet.
Queries the current priority list.
Syntax
AT+WDSM46=<context_ID>,
<context_ID>,…<context_ID>
Queries the supported values for
the priority list.
AT+WDSM46=?
AT+WDSM46?
Possible Responses
+WDSM46: list of supported
<context_ID>s
+WDSM46: (set of
supported <context_ID>s)
Description:
Enables the setting of a prioritized list for scanning and connecting using different +WS46 service agents.
An individual +WS46 service agent is identified by a <context_ID>. This parameter is in effect if the
wireless terminal is configured for Multiple Concurrent WDSs (AT+WS46=15). However, this parameter
may be set and queried even when AT+WS46 is set to a value other than 15.
The highest priority +WS46 service agents appear first in the subparameter list. The default value of the
AT+WDSM46 parameter is 0 meaning "“no selected +WS46 service agent."
For example: AT+WDSM46=4,14,17 sets the +WDSM46 parameter. When the wireless terminal is set for
Multiple Concurrent WDSs (AT+WS46=15) and the DTE requests a mobile originated call, the DCE will
attempt to make a connection with +WS46 service agents in the order specified by +WDSM46. If an
attempt to the highest priority +WS46 service agent is not successful, then the DCE will attempt to connect
to the next system in the priority list. If all systems are attempted unsuccessfully, then an appropriate result
code is returned such as NO CARRIER.
Abortability:
This command is not abortable.
Defined values:
Table 10. <context_ID> parameter.
<context_ID>
Integer
Description
Identifies a service agent. Each service agent has a unique IP address, port
number, and protocol tuple.
0 – default context: DTE-DCE interface. No communication to a service
agent. Default.
1-n – identifies a context that correspond to a service agent.
Result codes:
Copyright  1999 PCCA. All Rights Reserved.
Page 30
January 11, 1999
Table 11. Result Codes
Result Code
OK
ERROR
Description
Acknowledges execution of a command.
Command not recognized, command line maximum length
exceeded, parameter value invalid, or other problem with
processing the command line
Execution Time:
Not timing critical.
Implementation:
Optional.
Copyright  1999 PCCA. All Rights Reserved.
Page 31
January 11, 1999
9.9
COMPOUND PARAMETER IP_SPEC
The compound parameter IP_Spec is used to represent Internet Protocol version 4 (IPv4) and version 6
(IPv6) addresses. The format for this compound data type is as defined below:
<IP_Spec>
<address>[,[<port >][,[<type>]]]
<address >
For IPv4 addresses, a formatted string:
“[<v4_part>][,[<modifier_part>]]” Default.
For IPv6 addresses, a formatted string:
“[<v6_part>][,[<modifier_part>]]”
<port>
A decimal integer in the range 1 to 65535, indicating an internet port
number (typically a TCP or UDP port number). The Default value of
this sub-parameter is command-specific.
<type>
A decimal integer, identifying the address family, one of:
138
indicates an IPv6 format for <address>
142
indicates an IPv4 format for <address>. Default.
The default value of this sub-parameter is manufacturer-specific, and may
be context-sensitive.
<v4_part>
A 32-bit IPv4 address, represented using ASCII / IA5 characters in the
dotted decimal format described on page 5 of Internet RFC 9902, Assigned
Numbers. For example, the 32-bit address indicated by hexadecimal
AA227145 would be represented as 176.34.112.69.
<v6_part>
A 128-bit IPv6 address, represented using ASCII / IA5 characters in any of
the formats described in Section 2.2 of Internet RFC 1884, IP Version 6
Addressing Architecture. For example, the 128-bit address indicated by
hexadecimal 108000000000000000080800200C417A could be represented
as 1080::8:800:200C:417A or in any other format allowed by RFC
1884.
<modifier_part>
A single ASCII / IA5 character identifying the type of address, one of:
S
indicates a station (unicast) address. Default.
M
indicates a multicast address.
B
indicates a broadcast address.
A
indicates an anycast address (IPv6).
Other values for this character are reserved for future standardization. If
absent, the address is assumed to be a station address.
Note that IPv6 as defined in RFC 1883 subsumes all IPv4 addresses into the IPv6 address space. This leads
to the possibility of multiple valid representations of an IPv4 address can
2
Although RFC 990 has been obsoleted by RFC 1700 and others, it is the most recent version of the
Assigned Numbers RFC to provide an explicit definition of dotted decimal format. More recent versions
use identical address formatting, but refer to “normal Internet dotted decimal notation” without providing a
definition.
Copyright  1999 PCCA. All Rights Reserved.
Page 32
January 11, 1999
The DCE displays the current value of an IP_Spec compound parameter using any of several
implementation-dependent formats subject to four rules:
1.
The display format for an IP_Spec shall correspond to an allowed input format for an IP_Spec;
2.
If the command accepts a <modifier_part>, and the <modifier_part> is set to station, display of the ,S
suffix is optional;
3.
No trailing commas will be displayed;
4.
IPv6 as defined in RFC 1883 subsumes all IPv4 addresses into the IPv6 address space. The leading 96
bits of an IPv4 address represented in IPv6 space are all zeros. The DCE may choose (manufacturer’s
option) to display IPv4 addresses as either IPv4 or IPv6 addresses, using any format allowed by RFC
1884, regardless of which format was used to enter the IP_Spec compound parameter to the DCE.
Non-exhaustive examples of allowable display formats for the IPv4 station IP address 123.45.0.6 and port
number 7 include:
“123.045.000.006,S”,00007,142 (optional zeros, family and type displayed)
“123.045.000.006”,00007
(opt. zeros, IPv4 and type station implied)
“123.45.0.6”,7
(no optional zeros; type not accepted)
“123.45.0.6”
(port number and type not accepted)
“123.45.0.6,S”
(port number not accepted, type displayed)
“::7B23:6,S”,7,138
(Displayed as IPv6 address, preferred form)
“::123.45.0.6,S”,7,138
(Displayed as IPv6 address, alternative form)
“0000:0000:0000:0000:0000:0000:7B23:0006,S”,00007,138
(Displayed as canonical IPv6 address)
The range of valid values for an IP_Spec parameter is displayed (e.g. in response to =?) as :
“(address),(A,B,M,S)”,(0-65535),(138,142)
Several additional rules apply to range reporting for the IPv4_Spec:
1. The letters (address) are displayed literally, and indicate that either a <v4_part> or a <v6_part>
may be entered.
2. All commands using the IP_Spec compound parameter shall permit entry of any value in the supported
range for <address>, <port>, and <type>.
3. All commands using the IP_Spec compound parameter shall support at least one value for each of the
subparameters <address>, <port>, and <type>.
4. Unsupported values of any subparameter may be excluded from the range display, so long as at least
one value is supported. For example, a command supporting only IPv4 station addressing with no
meaning assigned to the <port> field may report:
“(address),(S)”,(0),(142)
As a second example, many commands will omit 0 from the range of valid values for <port>
Copyright  1999 PCCA. All Rights Reserved.
Page 33
January 11, 1999
10 SCENARIOS
10.1 CDPD PC CARD IS CONFIGURED TO INVOKE THE IP MODEM
INTERFACE
Description
A CDPD PC Card is configured to invoke the IP modem interface.
Table 12. CDPD PC Card is configured to invoke the IP modem interface.
AT Command/Response
AT+WIPC=1
OK
AT+WIPC?
+WIPC: 1, "C:
OK
AT +WIPM=0
SA-DCE Mode
Command State
Comment
Enable ICMP
Command State
The IP modem will return
ICMP errors; the IP modem is
class C.
Device is IP modem capable
with three internal SA’s:
 Directory service agent at
IP address 1110 and UDP
port 7.
 +WS46 service agent/AT
command service agent at
IP address 1110 and UDP
port 7.
 AT command service agent
that supports TDMA AT
commands at IP address
1110 and UDP port 8086.
 GUTS service agent at IP
address 1111 and UDP
port 8083.
A priority list for connecting to
the Internet is configured:
1. Using the +WS46 TDMA
service agent with
<context_ID>=2.
2. Using the GUTS service
agent with
<context_ID>=4.
The context with the +WS46
TDMA service agent is
activated.
Command State
+WIPM: 1,0,0,”UDP”,0,”1.1.1.0”,7
+WIPM: 2,4,14,”UDP”,0,”1.1.1.0”,7
+WIPM: 3,1,14;”UDP”,0,”1.1.1.0”,8086
+WIPM: 4,2,14,”UDP”,1,”1.1.1.1”, 8083
OK
AT+WDSM46=2,4
OK
Command State
AT+WIPT=2,1
OK
Command State
context active
with the +WS46
TDMA service
agent.
Command State
context active
with the +WS46
TDMA service
agent.
Command State
AT ……
OK
AT+WIPT=2,0
Copyright  1999 PCCA. All Rights Reserved.
AT commands from TDMA IS136-350 are used to configure
the GPRS packet data service.
The context with the +WS46
Page 34
January 11, 1999
OK
AT+WIPT=4,1
OK
AT…..
OK
ATZ
OK
Command State
context active
with the GUTS
TDMA service
agent.
Command State
context active
with the GUTS
TDMA service
agent.
Command State
AT+WIPA=1,”1.1.1.10”,7
OK
AT +WS45=3
OK
Command State
AT +WS46=15
OK
ATD
CONNECT
Select Multiple
WDS stacks
IP modem
interface.
On-line data
state.
IP modem
interface.
On-line data
state.
IP/SLIP frames
IP/SLIP mode.
Copyright  1999 PCCA. All Rights Reserved.
TDMA service agent is
deactivated.
The context with the GUTS
TDMA service agent is
activated.
AT commands from TIA IS136-350 are used to configure
the GUTS service.
The GUTS AT command
parameters are reset to their
default values. The context with
the GUTS service agent is
terminated.
The DTE assigns the Directory
service agent a new IP address.
The SA-DCE is instructed to
use SLIP as the DTE - DCE
interface protocol when the SADCE enters on-line data mode.
Select the network independent
mode.
The IP modem interface is
invoked: IP/SLIP.
The DTE and SA-DCE
exchange IP/SLIP frames. The
DTE applications now
communicate directly with each
SA as required.
Page 35
January 11, 1999
10.2 A DISCONNECTION CANCELS THE IP MODEM INTERFACE
Description
The IP stack on the DTE is shut down. This disables the IP modem interface.
Table 13. CDPD PC Card is configured to invoke the IP modem interface.
AT Command
DTR drops
OK


SA-DCE Mode
AMPS Analog
Cellular – Voice
Mode
Not connected to
DTE.
Copyright  1999 PCCA. All Rights Reserved.
Comment
The SA-DCE detects that the
DTE is no longer connected.
Page 36