wdp and wcmp wireless data gateway adaptation · 04/08/1999 · wdp and wcmp wireless data gateway...

32
WDP and WCMP Wireless Data Gateway Adaptation Proposed 04-August-1999 © Wireless Application Protocol Forum Ltd. 1999. Terms and conditions of use are available from the Wireless Application Protocol Forum Ltd. Web site http://www.wapforum.org/docs/copyright.htm Wireless Application Protocol WDP and WCMP Adaptation for access of a WAP Proxy Server to a Wireless Data Gateway Wireless Application Protocol WDP and WCMP Adaptation for access of a WAP Proxy Server to a Wireless Data Gateway

Upload: vuquynh

Post on 04-Jun-2019

225 views

Category:

Documents


0 download

TRANSCRIPT

WDP and WCMPWireless Data Gateway Adaptation

Proposed 04-August-1999

© Wireless Application Protocol Forum Ltd. 1999. Terms and conditionsof use are available from the Wireless Application Protocol Forum Ltd. Web site

http://www.wapforum.org/docs/copyright.htm

Wireless Application ProtocolWDP and WCMP Adaptation for access of a WAP

Proxy Server to a Wireless Data Gateway

Wireless Application ProtocolWDP and WCMP Adaptation for access of a WAP

Proxy Server to a Wireless Data Gateway

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

.

Disclaimer:

This document is a preliminary draft document and is subject to change.

Proposed Version, 04-August-1999 Page 3 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

Table of Contents

1 SCOPE .......................................................................................................................................................5

2 DOCUMENT STATUS .............................................................................................................................6

2.1 COPYRIGHT NOTICE ..............................................................................................................................62.2 ERRATA................................................................................................................................................62.3 COMMENTS...........................................................................................................................................6

3 REFERENCES ..........................................................................................................................................7

3.1 NORMATIVE REFERENCES ......................................................................................................................7

4 ABBREVIATIONS....................................................................................................................................8

5 TERMINOLOGY......................................................................................................................................9

6 GENERAL...............................................................................................................................................10

7 SMPP ADAPTATION.............................................................................................................................11

7.1 GENERAL WDP/WCMP ADAPTATION REQUIREMENTS.........................................................................117.1.1 Underlying transport protocol.....................................................................................................117.1.2 Support for More Messages to Send............................................................................................117.1.3 Support for ‘non Store-and-Forward’ messages ..........................................................................117.1.4 Support for transferring binary data............................................................................................117.1.5 Segmentation and Reassembly (SAR) .........................................................................................127.1.6 WCMP Support ..........................................................................................................................137.1.7 Alert Notification .......................................................................................................................13

7.2 MANDATORY SMPP PDUS .................................................................................................................147.2.1 DATA_SM.................................................................................................................................147.2.2 GENERIC_NACK .....................................................................................................................147.2.3 BIND .........................................................................................................................................157.2.4 UNBIND....................................................................................................................................16

7.3 OPTIONAL SMPP PDUS ......................................................................................................................177.3.1 ENQUIRE_LINK .......................................................................................................................177.3.2 ALERT_NOTIFICATION..........................................................................................................17

7.4 DETAILED PARAMETER VALUE RECOMMENDATIONS.............................................................................187.4.1 BIND_TRANSCEIVER .............................................................................................................187.4.2 BIND_TRANSMITTER.............................................................................................................197.4.3 BIND_RECEIVER.....................................................................................................................207.4.4 UNBIND....................................................................................................................................207.4.5 ENQUIRE_LINK .......................................................................................................................217.4.6 DATA_SM (WAP Proxy Server initiated) ..................................................................................217.4.7 DATA_SM (Wireless Data Gateway initiated)............................................................................237.4.8 DATA_SM (Delivery Receipt from Wireless Data Gateway) ......................................................247.4.9 ALERT_NOTIFICATION..........................................................................................................26

APPENDIX A. STATIC CONFORMANCE REQUIREMENT....................................................................27

A.1 WAP proxy/server support ..................................................................................................................28A.2 Wireless Data Gateway support...........................................................................................................30

APPENDIX B. HISTORY AND CONTACT INFORMATION ....................................................................32

Proposed Version, 04-August-1999 Page 4 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

Proposed Version, 04-August-1999 Page 5 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

1 Scope

This document specifies the WDP and WCMP adaptation over the underlying access protocol between a WAPProxy Server and a Wireless Data Gateway (such as an SMSC or a USSD server).

The tunnel protocol in the WAP architecture is based on a subset of the Short Message Peer-to-Peer Protocol(SMPP), version 3.4. SMPP includes support for the SMS bearer service (across the various network types) andthe USSD bearer service (GSM network only).

This document details the elements of the SMPP protocol that are required and sufficient for carrying WDP andWCMP data units between a WAP Proxy Server and a Wireless Data Gateway. The Wireless Data Gateway isresponsible for relaying the WDP and WCMP data units to and from the WAP capable wireless device (such as amobile station).

Figure 1.1 shows a general model of the WAP protocol architecture and how SMPP fits into that architecture.

SMS -TL

WDP/WCMP

Adaptation

WTP

WSP

WAE

SMS - TL

Subnetwork

SMPP

Subnetwork

SMPP

WSP

WAE Apps onother servers

Wireless Data Gateway

WAPProxy ServerMobile

WDP/WCMP

Adaptation

WTP

IWF

WTLS

Adapt Adapt

WTLS

Figure 1.1 SMPP Tunnel in the WAP Architecture

Proposed Version, 04-August-1999 Page 6 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

2 Document StatusThis document is available online in the following formats:

• PDF format at URL, http://www.wapforum.org/.

2.1 Copyright Notice© Copyright Wireless Application Protocol Forum, Ltd, 1999.Terms and conditions of use are available from the Wireless Application Protocol Forum Ltd. website athttp://www.wapforum.org/docs/copyright.htm.

2.2 ErrataKnown problems associated with this document are published at http://www.wapforum.org/.

2.3 CommentsComments regarding this document can be submitted to the WPG working group in the manner published athttp://www.wapforum.org/.

Proposed Version, 04-August-1999 Page 7 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

3 References

3.1 Normative references[SMPP34] Short Message Peer-to-Peer Protocol (SMPP) Specification. Version 3.4, Issue 1.1.

http://www.smpp.org.

[WAE] "Wireless Application Environment Specification", WAP Forum, 16 June 1999.http://www.wapforum.org

[WAP] “Wireless Application Protocol Architecture Specification”, WAP Forum, 30 April 1998.http://www.wapforum.org

[WCMP] "Wireless Control Message Protocol Specification", WAP Forum, 14 May 1999.http://www.wapforum.org

[WDP] "Wireless Datagram Protocol Specification", WAP Forum, 14 May 1999.http://www.wapforum.org

[WTP] "Wireless Transaction Protocol Specification, WAP Forum, 11 June 1999.http://www.wapforum.org

Proposed Version, 04-August-1999 Page 8 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

4 AbbreviationsFor the purposes of this specification the following abbreviations apply.

CDMA Code Division Multiple AccessDPF Delivery Pending FlagETSI European Telecommunication Standardisation InstituteGSM Global System for Mobile CommunicationGPRS General Packet Radio ServiceiDEN Integrated Digital Enhanced NetworkIE Information ElementIP Internet ProtocolLSB Least Significant BitsMAP Mobile Application PartME Mobile EquipmentMSISDN Mobile Subscriber ISDN (Telephone number or address of device)MO Mobile OriginatedMS Mobile StationMT Mobile TerminatedMMS More Messages to SendMSB Most Significant BitPDU Protocol Data UnitSAR Segmentation and ReassemblySME Short Message EntitySME-IF Short Message Entity InterfaceSMPP Short Message Peer-to-PeerSMSC Short Message Service CentreSMS Short Message ServiceTCP/IP Transmission Control Protocol/Internet ProtocolTDMA Time Division Multiple AccessUDH User-Data Header (see GSM 03.40)UDHI User-Data Header Indication (see GSM 03.40)UDP User Datagram ProtocolUSSD Unstructured Supplementary Service DataWAE Wireless Application EnvironmentWAP Wireless Application ProtocolWCMP Wireless Control Message ProtocolWDP Wireless Datagram ProtocolWSP Wireless Session ProtocolWTP Wireless Transaction Protocol

Proposed Version, 04-August-1999 Page 9 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

5 TerminologyThis specification uses the following words for defining the significance of each particular requirement:

MUSTThis word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirementof the specification.

MUST NOTThis phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of thespecification.

SHOULDThis word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particularcircumstances to ignore a particular item, but the full implications must be understood and carefullyweighed before choosing a different course.

SHOULD NOTThis phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons inparticular circumstances when the particular behaviour is acceptable or even useful, but the fullimplications should be understood and the case carefully weighed before implementing any behaviourdescribed with this label.

MAYThis word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may chooseto include the item because a particular marketplace requires it or because the vendor feels that itenhances the product while another vendor may omit the same item. An implementation which does notinclude a particular option MUST be prepared to interoperate with another implementation which doesinclude the option, though perhaps with reduced functionality. In the same vein an implementationwhich does include a particular option MUST be prepared to interoperate with another implementationwhich does not include the option (except, of course, for the feature the option provides.)

Proposed Version, 04-August-1999 Page 10 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

6 General

The protocol between a WAP Proxy Server and a Wireless Data Gateway is required to be “wireless networktechnology independent”. This assures a true isolation from the network type and device type used. It also assuresthe end-to-end nature of the Wireless Data Protocol (WDP) and Wireless Control Message Protocol (WCMP) thatare “tunnelled” between the WAP Proxy Server and the Mobile Station.

This document defines in an unambiguous manner how SMPP shall be implemented for a proper interworking inthis context.

The following sections describe the protocol elements to be used, specific values of parameters to be used andrecommends optional features.

Proposed Version, 04-August-1999 Page 11 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7 SMPP AdaptationNote:- This section of the document defines those specific elements of SMPP v3.4 which are required for

WAP applications. It is intended that this document be used in conjunction with SMPP ProtocolSpecification v3.4 [SMPP34] (available from http://www.smpp.org).

7.1 General WDP/WCMP adaptation requirements

7.1.1 Underlying transport protocolThe underlying transport protocol for access between a Wireless Data Gateway and a WAP Proxy Server isTCP/IP. TCP/IP provides a reliable connection-oriented transport. Other protocols supported by SMPP, such asX.25, may also be used for the underlying transport connection.

7.1.2 Support for More Messages to SendSome wireless network technologies allow a Wireless Data Gateway to keep a short message transaction openbetween the Gateway MSC and the MS in the case where there are more messages waiting to be sent from theWireless Data Gateway to the MS. This feature is commonly referred to as “More Messages to Send”.

In a WAP system there are typically more than one mobile terminated message in the response from the WAPProxy Server to the MS. The capability for the WAP Proxy Server to indicate that there are further messages forthe MS could crucially improve the response time perceived by the user.

SMPP allows WAP Proxy Servers to set a more_msgs_to_send indicator on a per message basis. Independently ofthis SMPP parameter setting, Wireless Data Gateway implementations may choose (as an implementationoption) to intelligently set the MMS parameter on the air interface when a multiple-fragment WDP message isbeen sent to the MS, i.e. without a specific indication from the WAP Proxy Server to set it.

7.1.3 Support for ‘non Store-and-Forward’ messagesTraditionally Wireless Data Gateways securely stored messages to a non-volatile disk file system beforedelivering them. Many interactive WAP applications do not require this feature and indeed the increased latencyincurred may be undesirable, and perhaps even prohibitive, in many applications.

SMPP allows the WAP Proxy Server to send a datagram message using the data_sm PDU. Wireless DataGateways implementations MAY choose not to securely store the WDP/WCMP datagram. A WAP Proxy Serverrequests datagram mode by setting the esm_class parameter in data_sm to the value corresponding to “datagrammode”.

7.1.4 Support for transferring binary dataWDP and WCMP messages are encoded in binary format. The adaptation layers in the Wireless Data Gatewayand WAP Proxy Server MUST set the SMPP data_coding parameter to “8-bit binary” (0x04).Some WAP Proxy Servers may encode WDP datagrams in textual format. In this case, the WAP Proxy ServerMAY set the SMPP data_coding parameter to another character coding set scheme (e.g. IA5/ASCII).

Proposed Version, 04-August-1999 Page 12 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.1.5 Segmentation and Reassembly (SAR)The WDP Tunnel Requirements allows various options for the Segmentation and Reassembly of WDPdatagrams.

1. The WAP Proxy Server is performing Segmentation and Reassembly

When sending a WDP datagram to the wireless device, the WAP Proxy Server segments the WDP datagramprior to tunnelling it over the SMPP connection to the Wireless Data Gateway. Each of the segments istransmitted in a separate data_sm PDU to the Wireless Data Gateway. In this case, the WAP Proxy ServerMUST include the sar_msg_ref_num, sar_total_segments and the sar_segment_seqnum parameters in thedata_sm PDU.When a WAP Proxy Server is receiving a WDP datagram from the wireless device, it can receive it in theform of a number of segments. Each segment is sent by the Wireless Data Gateway as message payload inseparate data_sm PDUs. In this case, the Wireless Data Gateway MUST include the sar_msg_ref_num,sar_total_segments and the sar_segment_seqnum parameters in the data_sm PDU. The WAP Proxy Serverreassembles the complete WDP datagram once it has received all segments.

2. The Wireless Data Gateway implements a Segmentation and Reassembly function for WDP Datagrams.

When sending a WDP datagram to the wireless device, the WAP Proxy Server sends a complete datagram ina single data_sm PDU to the Wireless Data Gateway. In this case, the WAP Proxy Server MUST notinclude the sar_msg_ref_num, sar_total_segments and the sar_segment_seqnum parameters in the data_smPDU.

When a WAP Proxy Server is receiving a WDP datagram from the wireless device, it will receive it as acomplete datagram from the Wireless Data Gateway. In this case, the Wireless Data Gateway MUST notinclude the sar_msg_ref_num, sar_total_segments and the sar_segment_seqnum parameters in the data_smPDU.

3. Dual Segmentation and Reassembly

This is a special case of SAR where both the WAP Proxy Server and the Wireless Data Gateway perform theSegmentation and Reassembly of a WDP datagram. In this scenario, the WAP Proxy Server transmits theWDP datagram as a sequence of segments over the SMPP tunnel to the Wireless Data Gateway. As animplementation option, the Wireless Data Gateway then reassembles the segments back into one completeWDP datagram, before it forwards the WDP datagram over the wireless interface. Depending on thetechnology of the wireless device, the Wireless Data Gateway may have to re-segment the datagram fortransmission over the wireless interface.Similarly, the Wireless Data Gateway may reassemble a WDP datagram received as a series of segments overthe wireless interface and then re-segment the WDP datagram for delivery over the SMPP tunnel to the WAPProxy Server.

The adaptation for the transmission of the WDP datagram segments over the SMPP tunnel is exactly thesame as option 1 above for both directions of WDP datagram flow. In essence, the Dual Segmentation andReassembly is an implementation option for the Wireless Data Gateway and no extra special adaptation isrequired.

Proposed Version, 04-August-1999 Page 13 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.1.6 WCMP SupportWhen sending a WCMP message to the MS, the WAP Proxy Server MUST indicate this to the Wireless DataGateway by setting the payload_type parameter in data_sm to “WCMP” (0x01). The WCMP message is carriedin the message_payload parameter. On receiving a data_sm with payload_type set to “WCMP”, the WirelessData Gateway will transmit the WCMP messages to the wireless device using the network dependent mechanismas defined in [WCMP].

The Wireless Data Gateway can also relay a WCMP message from the wireless device to the WAP Proxy Server.In this case, the Wireless Data Gateway MUST set the payload_type parameter in data_sm to “WCMP” (0x01).The WCMP message is carried in the message_payload parameter.

7.1.7 Alert NotificationA WAP Proxy Server can request that the Wireless Data Gateway set a Delivery Pending Flag (DPF) for thedelivery failure of a WDP datagram over the wireless interface. The exact delivery failure conditions aretechnology dependent (e.g. GSM allows a DPF to be set for “memory capacity exceeded”) and Wireless DataGateway implementation specific. However, in general the failure condition can be characterised as being a“device unavailable” failure.

SMPP allows the WAP proxy server to request this setting on a per-datagram basis using the set_dpf parameterin the data_sm PDU.

The Wireless Data Gateway SHOULD then send an alert notification to the WAP Proxy Server when it or thewireless network infrastructure (e.g. HLR) detects that device has become available. It should be noted that theWireless Data Gateway only sends this alert when the DPF setting for the wireless device had been requested in aprevious data_sm operation.

The alert_notification PDU is used to send the alert to the WAP Proxy Server.

Proposed Version, 04-August-1999 Page 14 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.2 Mandatory SMPP PDUsThis section documents the SMPP PDUs that are mandatory for WDP/WCMP data tunnelling between a WAPProxy Server and a Wireless Data Gateway.

7.2.1 DATA_SMThe data_sm PDU is used to carry WDP and WCMP datagrams. The type of payload is indicated via thepayload_type parameter. Both the Wireless Data Gateway and the WAP Proxy Server MUST be capable ofsending the data_sm PDU.

A WAP Proxy Server MAY select a delivery mode when tunnelling datagrams to the Wireless Data Gateway.The delivery mode indicates to the Wireless Data Gateway the mechanism to be used for delivering the datagramto the wireless device. The delivery mode is indicated in the esm_class parameter (message mode settings). Thedelivery modes available in data_sm for WAP datagrams are as follows:

1. Store and ForwardThis mode allows the WAP Proxy Server to request the Wireless Data Gateway to securely store thedatagram until it is delivered or until it expires. This mode may be used for “push” applications. The WAPProxy Server can control the expiration time by specifying the qos_time_to_live parameter in the data_smPDU.

2. DatagramThis mode allows the WAP Proxy Server to request the Wireless Data Gateway to relay the datagram to theMS, without necessarily securing the datagram for long-term storage. This mode is designed for “interactiveapplications”. The WAP Proxy Server can control the lifetime of the datagram in the Wireless Data Gatewayby specifying the qos_time_to_live parameter in the data_sm PDU..

The data_sm PDU also supports the various options for location of the Segmentation and Reassembly function inthe WAP network. See section 7.1.5.

Section 7.4.7 details the individual parameter settings for the data_sm PDU for both the “mobile terminated”and “mobile originated” directions.

7.2.2 GENERIC_NACKThe GENERIC_NACK PDU is sent by the Wireless Data Gateway or the WAP Proxy Server to indicate thefollowing SMPP protocol error conditions encountered when processing an SMPP request PDU.

• Invalid command_length. The length of the SMPP request PDU is not correct.• Unknown command_id. The SMPP request PDU is either unknown or not supported.• Corrupted SMPP PDU. The SMPP request PDU is detected to be corrupt.

Proposed Version, 04-August-1999 Page 15 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.2.3 BINDThe WAP Proxy Server must establish an SMPP session with a Wireless Data Gateway prior to the transmissionof WDP/WCMP messages over the link. There are two mechanisms for setting up SMPP sessions. Only onemechanism MUST be supported.

The first mechanism allows the WAP Proxy Server to issue both a bind_transmitter PDU and/or a bind_receiverPDU to set up distinct SMPP sessions for the different directions of WDP message flow.The second mechanism allows a WAP Proxy Server to set up a single SMPP session for two-way WDP datagramflow using the bind_transceiver PDU.

7.2.3.1 BIND_TRANSCEIVERThe bind_transceiver PDU is used to establish a duplex messaging session between a WAP Proxy Server and aWireless Data Gateway. The WAP Proxy Server can send datagrams to a wireless device (e.g. MS) and shouldbe able to receive datagrams from a wireless device over a transceiver session.

The WAP Proxy Server provides identification and authentication information as part of the sessionestablishment. See 7.4.1 for more details.

As an option, Wireless Data Gateways MAY allow trusted WAP Proxy Servers to establish an SMPP sessionwithout providing a password.

7.2.3.2 BIND_TRANSMITTERThe bind_transmitter PDU is used to establish a one way messaging session between a WAP Proxy Server and aWireless Data Gateway. The WAP Proxy Server can only send datagrams to a wireless device (e.g. MS) over atransmitter session.

The WAP Proxy Server provides identification and authentication information as part of the sessionestablishment. See 7.4.2 for more details.

As an option, Wireless Data Gateways MAY allow trusted WAP Proxy Servers to establish an SMPP sessionwithout providing a password.

7.2.3.3 BIND_RECEIVERThe bind_receiver PDU is used to establish a one-way messaging session between a WAP Proxy Server and aWireless Data Gateway. The WAP Proxy Server will only receive datagrams originated from a wireless device(e.g. MS) over an SMPP receiver session.

The WAP Proxy Server provides identification and authentication information as part of the sessionestablishment. See 7.4.3 for more details.

As an option, Wireless Data Gateways MAY allow trusted WAP Proxy Servers to establish an SMPP sessionwithout providing a password.

Proposed Version, 04-August-1999 Page 16 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.2.4 UNBINDThe UNBIND PDU is used by either the WAP Proxy Server or the Wireless Data Gateway to terminate the SMPPsession. Thereafter the node should disconnect the link at TCP level.

Proposed Version, 04-August-1999 Page 17 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.3 Optional SMPP PDUsThis section documents the SMPP PDUs that are implementation options for WDP/WCMP data tunnellingbetween a WAP Proxy Server and a Wireless Data Gateway.

7.3.1 ENQUIRE_LINKThis PDU can be used by both the WAP Proxy Server and the Wireless Data Gateway to test the peer to peercommunications and sanity level of an SMPP link. When implemented, the node sending the enquire_link PDUshould note the following:

• The enquire_link PDU need only be sent after a certain idle (i.e. inactivity) period has been detected on thelink. This period is defined using the SMPP enquire_link_timer.

• If a response is not received within a certain time period (defined by the SMPP response_timer), the nodeshould disconnect the link at TCP/IP level.

7.3.2 ALERT_NOTIFICATIONThis PDU is used by the Wireless Data Gateway to send an alert notification to the WAP Proxy Server. AWireless Data Gateway sends an alert notification when it detects that a wireless device has become available andfor which a DPF setting had been previously requested (by the WAP Proxy Server) in a failed datagram deliveryto that wireless device.

The alert_notification PDU contains the address of the wireless device and the originating WDP entity addressin the datagram which requested the DPF setting.

Proposed Version, 04-August-1999 Page 18 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.4 Detailed Parameter Value RecommendationsThis section provides the recommended parameter values for the subset of the SMPP PDUs that are required forWDP and WCMP data tunnelling. Only those SMPP parameters that are mandatory or optional for WAPapplication are documented in this section.

Note:- This section of the document defines those specific elements of SMPP Protocol Specification v3.4which are required for WAP applications. This section does not document generic SMPP details suchas the SMPP header format. The reader should refer to the SMPP specification [SMPP34] for thisgeneric information.

7.4.1 BIND_TRANSCEIVER

The bind_transceiver operation is used by a WAP Proxy Server to establish a duplex messaging session to aWireless Data Gateway. The following tables provide the recommended parameter settings for the request andresponse PDUs.

7.4.1.1 BIND_TRANSCEIVER Request

Parameter M/O Size(bytes)

RecommendedValue

Comment

system_id M 1 - 15 identificationstring

Identifies the WAP Proxy Server

password M 1 - 9 any characterstring

Trusted WAP Proxy Servers thatdo not need to send a passwordcan set this parameter to NULL.

system_type M 1 - 12 “WAP” Indicates that the connectingsystem is a WAP Proxy Server.

addr_ton M 1 Any TON for WAP Proxy Serveraddress

addr_npi M 1 Any. NPI for WAP Proxy Serveraddress

address_range M 1 - 40 WAP ProxyServer addressdigits

A single address which identifiesthe WAP Proxy Server. This couldbe for example an IP address or ashort code telephone numberassigned to the WAP Proxy Serverby the service provider.

7.4.1.2 BIND_TRANSCEIVER Response

Parameter M/O Size(bytes)

RecommendedValue

Comment

system_id M 1 - 15 identificationstring

Identifies the Wireless DataGateway

sc_interface_version M 1 0x34 Wireless Data Gateways shouldset the SMPP protocol version tov3.4.

Proposed Version, 04-August-1999 Page 19 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.4.2 BIND_TRANSMITTER

The bind_transmitter operation is used by a WAP Proxy Server to establish a one way messaging session to aWireless Data Gateway. The following tables provide the recommended parameter settings for the request andresponse PDUs.

7.4.2.1 BIND_TRANSMITTER Request

Parameter M/O Size(bytes)

RecommendedValue

Comment

system_id M 1 - 15 identificationstring

Identifies the WAP Proxy Server

password M 1 - 9 passwordcharacter string

Trusted WAP Proxy Servers thatdo not need to send a passwordcan set this parameter to NULL.

system_type M 1 - 12 “WAP” Indicates that the connectingsystem is a WAP Proxy Server.

addr_ton M 1 Any TON for WAP Proxy Serveraddress

addr_npi M 1 Any. NPI for WAP Proxy Serveraddress

address_range M 1 - 40 WAP ProxyServer addressdigits

A single address which identifiesthe WAP Proxy Server. This couldbe for example an IP address or ashort code telephone numberassigned to the WAP Proxy Serverby the service provider.

7.4.2.2 BIND_TRANSMITTER Response

Parameter M/O Size(bytes)

RecommendedValue

Comment

system_id M 1 - 15 identificationstring

Identifies the Wireless DataGateway

sc_interface_version M 1 0x34 Wireless Data Gateways shouldset the SMPP protocol version tov3.4.

Proposed Version, 04-August-1999 Page 20 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.4.3 BIND_RECEIVER

The bind_receiver operation establishes a one way messaging session to a Wireless Data Gateway for receivingWDP and WCMP datagrams originated by wireless devices. The following tables provide the recommendedparameter settings for the request and response PDUs.

7.4.3.1 BIND_RECEIVER Request

Parameter M/O Size(bytes)

RecommendedValue

Comment

system_id M 1 - 15 identificationstring

Identifies the WAP Proxy Server

password M 1 - 9 passwordcharacter string

Trusted WAP Proxy Servers thatdo not need to send a passwordcan set this parameter to NULL.

system_type M 1 -12 “WAP” Indicates that the connectingsystem is a WAP Proxy Server.

addr_ton M 1 Any TON for WAP Proxy Serveraddress

addr_npi M 1 Any. NPI for WAP Proxy Serveraddress

address_range M 1 - 40 WAP ProxyServer addressdigits

A single address which identifiesthe WAP Proxy Server. This couldbe for example an IP address or ashort code telephone numberassigned to the WAP Proxy Serverby the service provider.

7.4.3.2 BIND_RECEIVER Response

Parameter M/O Size(bytes)

RecommendedValue

Comment

system_id M 1 - 15 identificationstring

Identifies the Wireless DataGateway

sc_interface_version M 1 0x34 Wireless Data Gateways shouldset the SMPP protocol version tov3.4.

7.4.4 UNBIND

The unbind operation clears down an SMPP session between a WAP Proxy Server and a Wireless Data Gateway.

Both the unbind and unbind_resp PDUs only contain an SMPP header part.

Proposed Version, 04-August-1999 Page 21 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.4.5 ENQUIRE_LINK

The enquire_link operation is used by a WAP Proxy Server and a Wireless Data Gateway to test the peer to peercommunications and sanity level of an SMPP session.

Both the enquire_link and enquire_link_resp PDUs only contain an SMPP header part.

7.4.6 DATA_SM (WAP Proxy Server initiated)

A WAP Proxy Server uses the data_sm PDU to send a WDP or a WCMP message to a Wireless Data Gateway.The Wireless Data Gateway should return a data_sm_resp PDU once it has accepted the message.

7.4.6.1 DATA_SM (WAP Proxy Server -> Wireless Data Gateway) The following table provides the recommended values to be used by a WAP Proxy Server when sending adata_sm.

Parameter M/O Size(bytes)

RecommendedValue

Comment

service_type M 5 “WAP” Indicates SMS application serviceis WAP

source_addr_ton M 1 0x00 (Unknown) International directory numbersource_addr_npi M 1 0x00 (Unknown)

0x01 (E.164)0x0E (IP)

WAP Proxy Server can indicatethe associated numbering plan ofits own address.

source_addr M 0 – 64 Address digits address digits of WAP ProxyServer

dest_addr_ton M 1 0x01 International directory numberdest_addr_npi M 1 0x01 E164 numbering plandest_addr M 1 – 64 Directory

number digitsThis is the MSISDN of the MS

esm_class M 1 0x000x01

Store and Forward modeDatagram mode

registered_delivery M 1 0x000x01

No SMSC receipt requestedSMSC Delivery Receipt requested

data_coding M 1 0x040x00 – 0x0F

8-bit binaryother character sets.

source_port M 2 0 – 65535 UDP port of originating WDPentity

dest_port M 2 0 – 65535 UDP port of destination WDPentity

sar_msg_ref_num O 2 0 – 65535 MUST be present if WAP ProxyServer is segmenting the WDPmessage.

sar_total_segments O 1 2 – 255 MUST be present if WAP ProxyServer is segmenting the WDPmessage

sar_segment_seqnum O 1 1 – 255 MUST be present if WAP ProxyServer is segmenting the WDP

Proposed Version, 04-August-1999 Page 22 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

messagemore_msgs_to_send O 1 0x01 SHOULD be present if WAP

Proxy Server has further WDP(segments) to send.

dest_addr_subunit O 1 0x00 (unknown)0x02 (ME)

WAP Proxy Server MAY includethis parameter to direct theWDP/WCMP within the MS

dest_network_type O 1 Any WAP Proxy Server MAY includethis parameter to direct theWDP/WCMP to a particularwireless network type

dest_bearer_type O 1 Any WAP Proxy Server MAY includethis parameter to request theWireless Data Gateway to select aparticular bearer for theWDP/WCMP.

qos_time_to_live O 4 Any MAY be used to request theperiod of time that the WirelessData Gateway should retain theWDP message if it fails to getdelivered

payload_type O 1 0x00 (WDP)0x01 (WCMP)

This parameter MUST be presentand set to 0x01 for a WCMPmessage

message_payload M 1 –65535

user data WDP or WCMP content

set_dpf O 1 0x00 or0x01

Do not set DPFSetting of DPF requested.

7.4.6.2 DATA_SM_Resp (Wireless Data Gateway -> WAP Proxy Server) The following table provides the recommended values to be used by a Wireless Data Gateway when returning adata_sm_resp.

Parameter M/O Size(bytes)

RecommendedValue

Comment

message_id M 1 – 64 Any The message ID is the WirelessData Gateway’s handle to thedatagram. It should be consideredas an opaque value.

additional_status_info_text O 1 – 255 Textual string A Wireless Data Gateway mayinclude a diagnostic text string forfailure scenarios

Proposed Version, 04-August-1999 Page 23 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.4.7 DATA_SM (Wireless Data Gateway initiated)A Wireless Data Gateway uses the data_sm operation to send a WDP or a WCMP message to a WAP ProxyServer.

7.4.7.1 DATA_SM (Wireless Data Gateway -> WAP Proxy Server)The following table provides the recommended values to be used by a Wireless Data Gateway when sending adata_sm.

Parameter M/O Size(bytes)

RecommendedValue

Comment

service_type M 5 “WAP” Indicates SMS application serviceis WAP

source_addr_ton M 1 0x01 (Int.) International directory numbersource_addr_npi M 1 0x01 (E.164) all MS’s have E.164 directory

numberssource_addr M 0 – 64 address digits directory number digits of

wireless devicedest_addr_ton M 1 0x00 (unknown) International directory numberdest_addr_npi M 1 0x00 (unknown)

0x01 (E.164 )0x0E (IP)

WAP Proxy Server can either beaddressed via an IP address or atelephone number address.Otherwise set to “unknown”

dest_addr M 1 – 64 address digits Address digits of WAP ProxyServer

esm_class M 1 0x00 no special message moderegistered_delivery M 1 0x00 no acknowledgements/receiptsdata_coding M 1 0x04

0x00 – 0x0F8-bit binaryOther character sets.

source_port M 2 0 – 65535 UDP port of originating WDPentity

dest_port M 2 0 – 65535 UDP port of destination WDPentity

sar_msg_ref_num O 2 0 – 65535 MUST be present if WAP ProxyServer is reassembling the WDPmessage.

sar_total_segments O 1 2 – 255 MUST be present if WAP ProxyServer is reassembling the WDPmessage

sar_segment_seqnum O 1 1 – 255 MUST be present if WAP ProxyServer is reassembling the WDPmessage

source_network_type O 1 Any Wireless Data Gateway MAYinclude this parameter to indicatethe type of wireless interface overwhich the datagram was received.

source_bearer_type O 1 Any Wireless Data Gateway MAYinclude this parameter to indicate

Proposed Version, 04-August-1999 Page 24 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

the type of wireless bearer overwhich the datagram was received.

payload_type O 1 0x00 (WDP)0x01 (WCMP)

This parameter MUST be presentand set to 0x01 for a WCMPmessage.

message_payload M 1 –65535

user data WDP or WCMP content

7.4.7.2 DATA_SM_Resp (WAP Proxy Server -> Wireless Data Gateway)The following table provides the recommended values to be used by a WAP Proxy Server when returning adata_sm_resp.

Parameter M/O Size(bytes)

RecommendedValue

Comment

message_id M 1 – 64 0x00 (NULL) The Wireless Data Gateway doesnot need a handle to the WDP orWCMP datagram.

additional_status_info_text O 1 – 255 Textual string A WAP Proxy Server may includea diagnostic text string for failurescenarios

7.4.8 DATA_SM (Delivery Receipt from Wireless Data Gateway)

A Wireless Data Gateway uses the data_sm operation to send a final delivery receipt to the WAP Proxy Server.

7.4.8.1 DATA_SM (Wireless Data Gateway -> WAP Proxy Server) The following table provides the recommended values to be used by a Wireless Data Gateway when sending aDelivery Receipt

Parameter M/O Size(bytes)

RecommendedValue

Comment

service_type M 5 “WAP” Indicates SMS application serviceis WAP

source_addr_ton M 1 0x01 (Int.)source_addr_npi M 1 0x01 (E.164) all MS’s have E.164 directory

numberssource_addr M 0 – 64 address digits directory number digits of

wireless device to which thereceipt pertains

dest_addr_ton M 1 0x00 (unknown)dest_addr_npi M 1 0x00 (unknown)

0x01 (E.164 )0x0E (IP)

WAP Proxy Server can either beaddressed via an IP address or atelephone number address.Otherwise set to “unknown”

dest_addr M 1 – 64 address digits Address digits of WAP ProxyServer

Proposed Version, 04-August-1999 Page 25 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

esm_class M 1 0x04 indicates that data_sm contains adelivery receipt

registered_delivery M 1 0x00 no acknowledgementsdata_coding M 1 0x00 (default)

0x01 (ASCII)Should be set to 0x01 whenproviding an ASCII text string (inthe message payload) that furtherdescribes the delivery receipt.Otherwise set to 0x00 if a textstring is not included in themessage payload.

receipted_message_id M 1 – 64 Any The Wireless Data Gateway’shandle to the original WDPmessage. See 7.4.6.2

message_state M 1 Any Indicates state of the WDPmessage being receipted.

network_error_code O 3 network specificerror code

MAY be included by the WirelessData Gateway to provide furtherinformation for a WDP, whichfailed due to a wireless networkerror.

message_payload O 1 – 255 text string Descriptive textual string fordelivery receipt. MAY be includedfor informational purposes.

7.4.8.2 DATA_SM Response PDUThe following table provides the recommended values to be used by a WAP Proxy Server when returning adata_sm response for a Delivery Receipt.

Parameter M/O Size(bytes)

RecommendedValue

Comment

message_id M 1 – 64 0x00 (NULL) No handle required for a DeliveryReceipt.

Proposed Version, 04-August-1999 Page 26 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

7.4.9 ALERT_NOTIFICATION

A Wireless Data Gateway uses the alert_notification operation to send an alert to the WAP Proxy Serverindicating that the wireless device has become available.

7.4.9.1 ALERT_NOTIFICATION PDUThe following table provides the recommended values to be used by a Wireless Data Gateway when sending analert.

Parameter M/O Size(bytes)

RecommendedValue

Comment

source_addr_ton M 1 0x01 (Int.)source_addr_npi M 1 0x01 (E.164) all MS’s have E.164 directory

numberssource_addr M 0 – 64 address digits directory number digits of

wireless device that has becomeavailable

esme_addr_ton M 1 any TON for the source address in theoriginal datagram (data_sm)

esme_addr_npi M 1 any TON for the source address in theoriginal datagram (data_sm).

esme_addr M 1 – 64 address digits Address digits of WAP ProxyServer

ms_availability_status O 1 0x00 (available) The availability status of thewireless device

Proposed Version, 04-August-1999 Page 27 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

Appendix A. Static Conformance RequirementThis static conformance clause defines a minimum set of features that can be implemented to ensure that theimplementation will be able to inter-operate. This static conformance clause applies to the use of SMPP for WAPonly. A feature can be optional or mandatory. If a SMPP implementation does not support an optional feature,transmission should occur without error.

Proposed Version, 04-August-1999 Page 28 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

A.1 WAP proxy/server support

Identifier Function PDU / Capability Reference Mandatory/Optional

SMPP_PS_001 Datagramtransmission(binary encoded)

data_sm ,data_sm_resp andgeneric_nack PDUs

7.2.1, 7.2.27.4.6

M

SMPP_PS_002 Datagram reception(binary encoded)

data_sm ,data_sm_resp andgeneric_nack PDUs

7.2.1, 7.2.2,7.4.7

M

SMPP_PS_003 WCMP transmission payload_typeparameter in data_smPDU

7.1.6, 7.4.6.1 O

SMPP_PS_004 WCMP reception payload_typeparameter in data_smPDU

7.1.6, 7.4.7.1 O

SMPP_PS_005 Bind Transceiver bind_transceiver,bind_transceiver_respPDUs

7.2.3.1,7.4.1

M (note 1)

SMPP_PS_006 Bind Transmitter &Bind Receiver

bind_transmitter,bind_transmitter_resp,bind_receiver,bind_receiver_respPDUs

0,7.2.3.3,7.4.2,7.4.3

M (note 1)

SMPP_PS_007 Unbind unbind andunbind_resp PDUs

7.2.4 M

SMPP_PS_008 Enquire Link enquire_link andenquire_link_respPDUs

7.3.1 O

SMPP_PS_009 Text based encodingof WDP and WCMPmessages

data_coding parameterin data_sm

7.1.47.4.6.1,7.4.7.1

O

SMPP_PS_010 More messages tosend

more_msgs_to_sendparameter in data_sm

7.1.2,7.4.6.1

O

SMPP_PS_011 Request Store andforward mode

esm_class parameter indata_sm

7.2.1,7.4.6.1

O

SMPP_PS_012 Request datagrammode

esm_class parameter indata_sm

7.2.1,7.4.6.1

M

SMPP_PS_013 Segmentation and re-assembly

SAR parameters indata_sm

7.1.5,7.4.6.1,7.4.7.1

O

SMPP_PS_014 Request SMSCDelivery Report

registered_deliveryparameter in data_sm

7.4.6.1 O

SMPP_PS_015 Receive SMSCDelivery Report

esm_class ,receipted_message_idand message stateparameters in data_sm

7.4.8 O

SMPP_PS_016 specification ofnetwork type for peerwireless device

dest_network_type ,source_network_typeparameters in data_sm

7.4.6.1,7.4.7.1

O

Proposed Version, 04-August-1999 Page 29 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

Identifier Function PDU / Capability Reference Mandatory/Optional

SMPP_PS_017 specification ofbearer type for peerwireless device

dest_bearer_type ,source_bearer_typeparameters in data_sm

7.4.6.1,7.4.7.1

O

SMPP_PS_018 specification ofvalidity period on aper message basis

qos_time_to_liveparameter in data_sm

7.4.6.1 O

SMPP_PS_019 DPF request andprocessing of AlertNotifications

alert_notification PDUand set_dpf parameterin data_sm PDU

7.1.7, 7.3.2,7.4.6.1, 7.4.9

O

Notes

1. Only one of these Functional Units need be implemented (see section 7.2.3).

Proposed Version, 04-August-1999 Page 30 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

A.2 Wireless Data Gateway support

Identifier Function PDU / Capability Reference Mandatory/Optional

SMPP_DG_001 Datagramtransmission(binary encoded)

data_sm ,data_sm_resp andgeneric_nack PDUs

7.2.1, 7.2.2,7.4.7

M

SMPP_DG_002 Datagram reception(binary encoded)

data_sm ,data_sm_resp andgeneric_nack PDUs

7.2.1, 7.2.2,7.4.6

M

SMPP_DG_003 WCMP transmissionto WAP Proxy Server

payload_typeparameter in data_smPDU

7.1.6, 7.4.7.1 O

SMPP_DG_004 WCMP receptionfrom WAP ProxyServer

payload_typeparameter in data_smPDU

7.1.6, 7.4.6.1 O

SMPP_DG_005 Bind Transceiver bind_transceiver,bind_transceive_respPDUs

7.2.3.1,7.4.1

M (note 1)

SMPP_DG_006 Bind Transmitter &Bind Receiver

bind_transmitter,bind_transmitter_resp,bind_receiver,bind_receiver_respPDUs

0,7.2.3.3,7.4.2,7.4.3

M (note 1)

SMPP_DG_007 Unbind unbind andunbind_resp PDUs

7.4.4 M

SMPP_DG_008 Enquire Link enquire_link andenquire_link_respPDUs

7.3.1 O

SMPP_DG_009 Text based encodingof WDP and WCMPmessages

data_coding parameterin data_sm

7.1.47.4.7.1,7.4.6.1

O

SMPP_DG_010 More messages tosend

more_msgs_to_sendparameter in data_sm

7.1.2,7.4.6.1

O

SMPP_DG_011 Store and forwardmode

esm_class parameter(“store and forward”)in data_sm

7.2.1,7.4.6.1

O

SMPP_DG_012 Datagram mode(no secure storage)

esm_class parameter(“datagram”) indata_sm

7.2.1,7.4.6.1

M

SMPP_DG_013 Segmentation and re-assembly

SAR parameters indata_sm

7.1.57.4.6.1,7.4.7.1

O

Proposed Version, 04-August-1999 Page 31 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

Identifier Function PDU / Capability Reference Mandatory/Optional

SMPP_DG_014 Generate SMSCDelivery Reports

registered_deliveryparameter in data_sm(request in originalmessage).

esm_class ,receipted_message_idand message stateparameters in data_smPDU (for DeliveryReceipt message).

7.4.6.1

7.4.7.1

O

SMPP_DG_015 (blank)SMPP_DG_016 processing of

network type for peerwireless device

dest_network_type,source_network_typeparameters in data_sm

7.4.6.1,7.4.7.1

O

SMPP_DG_017 processing of bearertype for peer wirelessdevice

dest_bearer_type ,source_bearer_typeparameters in data_sm

7.4.6.17.4.7.1

O

SMPP_DG_018 processing of validityperiod on a permessage basis

qos_time_to_liveparameter in data_sm

7.4.6.1 O

SMPP_PS_019 DPF setting andgeneration of AlertNotifications

alert_notification PDUand set_dpf parameterin data_sm PDU

7.1.7, 7.3.2,7.4.6.1, 7.4.9

O

Notes

1. Only one of these Functional Units need be implemented (see section 7.2.3).

Proposed Version, 04-August-1999 Page 32 (32)

Copyright Wireless Application Forum, Ltd, 1999All rights reserved.

Appendix B. History and Contact Information

Document history

Date Status Comment

23-July-1999 Draft First Version

27-July-1999 Draft Added SCR in Appendix . John Murtagh ([email protected])

29-July-1999 Draft Updates following review in WAP Message Centre Protocol DC teleconference (28th July1999). John Murtagh ([email protected])

03-August-1999 InitialReleasev1.0

Additional updates following review in WAP Message Centre Protocol DC teleconference(28th July 1999).

John Doyle ([email protected])

Contact Information

http://www.wapforum.org/[email protected]