Mobile Originated SMS messages are received by the test set after being transmitted over the air by the mobile station. The test set displays much of the content of these messages on the front panel, makes them available for query via GPIB, or when using the HTTP interface, acts as the SMSC and routes the message to a receiving entity. (See HTTP Interface Configuration for Mobile Originated SMS for more information about using the HTTP interface with MO SMS messages.)
If the SMS message is originated by the mobile station, the transportation mechanism that was used by the mobile station is displayed on the front panel display and can also be queried (See CALL:SMService:PTPoint:MORiginated[:MESSage]:TRANsport? ).
As an example, in the following graphic you can see the details for the
Last Received Message
. Notice that the
field contains the value
. This indicates that GSM protocol layers were used to deliver this message from the mobile station.
To provide uplink support for any format of message encoding, the content of all types of received MO SMS messages can be retrieved via GPIB. Unless predetermined, it is necessary to query a received message's format or data coding scheme results before determining how the contents should be interpreted.
The raw content of each MO SMS message received by the test set is made available for query as an ASCII formatted string of hex characters. This hex string represents the entire TP-UD from the message and includes any User Data Header and fill bits that may be present in the content. To aid in extracting any present header data from the content, the User Data Header Length query (see CALL:SMService:PTPoint:MORiginated[:MESSage]:UDHLength? ) is provided which returns the length (in bytes) of the received messages user data header. For example, if this query returns <x> then the first <x> * 2 characters of the returned hex string are the user data header.
For messages encoded as 7-bit text (with or without a User Data Header), a separate query is also provided to return the ASCII string representing the actual text in the message. Note that this returned string does not include any User Data Header or fill bits found in the original content, only the ASCII representation of the actual text in the message content is returned. This query returns an empty string for all non 7-bit text based messages received.
This feature gives you the ability to simulate the complete transfer of an SMS message from an originating mobile station to a destination mobile station through the network. The test set takes the message it receives from the mobile station and sends it back to the mobile station.
Individual messages from a larger concatenated message or otherwise may arrive at the test set within relatively short periods of time from one another. If an external controller responding to these messages via a polling or interrupt mechanism does not react quickly enough to the arrival of each message, it is conceivable that results for some individual messages may be overwritten in the test set before the controller has had time to extract them. In this scenario, messages can effectively be lost and it may not be possible to rebuild a complete concatenated message at the controller.
|Turn message queuing ON and OFF||CALL:SMService:PTPoint:MORiginated:QUEue[:STATe]|
|Extract the next message from the queue||CALL:SMService:PTPoint:MORiginated:QUEue:NEXT|
|Query the current number of messages in the queue||CALL:SMService:PTPoint:MORiginated:QUEue:COUNt?|
The maximum number of messages that can be present in the queue at any one time is 255 individual (non concatenated) messages. This guarantees queuing in the worst case for a single maximum size concatenated message regardless of external controller synchronization. In reality it is unlikely the queue will ever hold this many messages when used with the interrupt or polling mechanisms as the rate messages can be received from the mobile station is limited and a controller should be extracting and handling messages at a similar speed if not faster than they are received from the mobile station. In the case of a queue overflow, a GPIB error is returned and the newly arrived message is discarded. A status bit is included in the SMS STATus subsystem to enable interrupts/polling based on overflow of the queue, see STATus:OPERation:FEATures:COMMon:SMService Register Bit Assignments for further details.