Mobile Originated SMS (MO SMS)- Receiving Messages Transmitted by the Mobile Station

Mobile Originated SMS (MO SMS)- Receiving Messages Transmitted by the Mobile Station

Last updated: December 3, 2008

This section is only applicable to lab applications and the test application with a required feature license.

This section describes the test set's support for mobile originated short message service (MO SMS). The topics discussed in this section include:

Receiving Messages from the Mobile Station

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.)

Transportation

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 Transportation field contains the value GSM . This indicates that GSM protocol layers were used to deliver this message from the mobile station.

Last Received Message Parameters

The header and message elements of mobile originated SMS Submit messages made available to you by the test set are described below.

Message Content (TP-User Data) Handling

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.

The following queries are provided for retrieving the contents of received MO SMS messages:

Test Set Configuration for Mobile Originated SMS

You can configure the following parameters in the test set to control handling of mobile originated SMS messages:

Message Loopback

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.

This feature also allows you to perform basic tests on data formats such as binary or UCS2 as the data type received from the mobile station is returned to it using the loopback feature.

Message Queue

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.

To provide complete test support for concatenated SMS, a queuing capability for MO SMS messages is provided in the test set via the GPIB interface.

Parameter GPIB Command
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?

Using the message queue

When MO SMS message queuing is ON, any received SMS-SUBMIT message from the mobile station are placed into a queue rather than overwriting existing results. The queue functions as follows:

  • You can extract messages from the queue in the order they were received from the mobile station. Only the results from the last message extracted from the queue are made available for query at any one time.
  • When a controller is finished reading the results for the current message it must inform the test set that it is finished with that message via the CALL:SMService:PTPoint:MORiginated:QUEue:NEXT command. When this command is received at the test set, the message at the head of the queue is extracted (if one exists) and its results become available for query. If no messages are present in the queue at this point then the previously available results are instead cleared.
  • When queuing messages, interrupts/polling function as follows:
    • If a message is received from the mobile station when no previous messages results are available (i.e. no previous messages have been received or a controller has indicated that it has finished reading ALL previously received messages) the newly received message's results are immediately made available for query and an interrupt is generated / polling bit is set to 1.
    • If a message is received from the mobile station when a previous message's results are still available then the message is added to the queue and no interrupt is generated/polling bit does not change (i.e. remains at 1).
    • Upon receipt of the CALL:SMService:PTPoint:MORiginated:QUEue:NEXT command informing the test set that the controller is finished reading the current message, the polling bit remains set if there was a message waiting in the queue, the results of which have now been extracted and are available for query. If no further messages were waiting in the queue at this point then the polling bit is cleared back to 0.
    • It should be noted that when queuing is `ON', no interrupts are ever generated for messages arriving at the test set when a previous messages results are still available. It is the users responsibility to make use of the polling bit to ensure such messages are all read by a controller before exiting an instance of the interrupt/polling procedure.

       
    NOTE
    When MO SMS message queuing is OFF, interrupts occur and the polling bit is set at the time each MO message is received from the mobile station. The polling bit used varies depending on the state of message queuing, if message queuing is ON then the CONDition bit should be used, if message queuing is OFF the EVENt bit should be used (which is cleared to 0 after being read). While message queuing is OFF, the CONDition bit is glitched (from 0 to 1 then back to 0) each time a message is received.
       

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.

Message queuing does not effect the operation of the existing MO loopback feature.

Related Topics

Mobile Terminated SMS (MT SMS)- Sending a Message to the Mobile Station

Responding to Mobile Originated SMS Messages

STATus:OPERation