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