You must enable the HTTP interface in the test set. This can be done via a GPIB command (see CALL:SMService:HTTProtocol:INPut ) or from the test set's front panel (see Enabling the HTTP Interface for Mobile Terminated SMS ).
When setting up any of these clients, it is necessary to specify the IP Address and port number on which the test set is listening for incoming messages. These parameters are always to be configured as follows:
The parameters and values variables provides the content of the SMS message as well as additional information for header configuration and test set configuration. All configurable parameters and values are detailed in Request URL Parameters .
|SMS Message Content Type||Mandatory Parameters|
|8 or 16 bit data||DATA and/or UDH|
|PIDHEX or PID|
|DCSHEX or DCS|
|Parameter||Use and expected value||Inclusion|
|TEXT||0-160 character string of 7-bit text characters. The underlying character codes specified here are used directly when sending the message OTA and will be interpreted by a receiving mobile station as per the ETSI default Alphabet specification.||This parameter must be included in all HTTP requests to send 7-bit text based SMS messages. It must not be included in the same request as either of the DATA or UDH parameters outlined below.|
|DATA||0-280 ASCII formatted hex characters (the length of the combined UDH and DATA values must not exceed 280 characters)||One or both of these parameters must be included in all HTTP requests to send binary SMS messages. The UDH and data for a message may be encoded as a single hex string and specified via either of these parameters, or may instead be specified separately and sent via both parameters. Neither of these parameters may be present in the same request as the TEXT parameter outlined above.|
|UDH||0-280 ASCII formatted hex characters representing the User Data Header to be included in the message content (the length of the combined UDH and DATA parameters must not exceed 280 characters)|
|UDHI||The User Data Header Indicator (TP-UDHI) of the message. Should be either 0 or 1 to indicate the presence of a User Data Header in the message content. If a UDH parameter (see above) containing a non-empty value is present in the request URL, the UDHI used when sending the message OTA is always 1 regardless of the presence/value of the this parameter.||Optional (Default = 0)|
|PIDHEX||The Protocol Identifier (TP-PID) of the message as a string of hex characters||Both of these parameters are optional but at most one may be included in any request. (Default = 0)|
|PID||The Protocol Identifier (TP-PID) of the message as a decimal number|
|DCSHEX||The Data Coding Scheme (TP-DCS) of the message as a string of hex characters||Both of these parameters are optional but at most one may be included in any request. (Default = 0)|
|DCS||The Data Coding Scheme (TP-DCS) of the message as a decimal number|
|SENDER||The phone number of the sending client as a 0 - 20 character ASCII formatted string of BCD digits from 0-9, *, #, a, b, c||Optional (Default = 1000)|
|MMTS||The More Messages to Send value for the SMS PDU header. Should be either 0 or 1.||Optional (Default = 1)|
|SRI||The Status Report Indication value for the SMS PDU header. Should be either 0 or 1.||Optional (Default = 0)|
|RPATH||The reply path value for the SMS PDU header. Should be either 0 or 1.||Optional (Default = 0)|
|TRANSPORT||The transport mechanism to use when sending the message, valid value is either `GSM' or `GPRS'.||Optional (Default = Whatever SMS transport is currently set for use in the instrument receiving the request)|
or, the test set also allows you to include the User Data Header as part of the `DATA' parameter as explained in the table Request URL Parameters . Therefore, the HTTP request URL could instead be configured as follows:
If POST is used as the request method, the URL request parameters detailed in Request URL Parameters are not included in the request URL, but are included in the request body instead. Therefore, the request URL in POST requests contains only `sms/send'.