IrREADY IrModem profile V1

8 DIALING AND CONTROL INTEROPERABILITY REQUIREMENTS

The Dialing and Control capabilities are provided by a subset of the ITU-T V.250 recommendation. This chapter points at the features of V.250 that are mandatory to support, as well as some deviations from V.250 that the IrModem Profile mandates. Optional features are also proposed.

8.1 AT Command set used

To guarantee that basic functionality can always be provided, it is required that a GW device supports the commands as defined in the following table.

16

Note 1: If a device supports only a default value, this command is permitted.

C: Connection completion timeout may be governed by national regulations. The default value shall be chosen in accordance.

All other commands are optional.

8.2 Result codes

The result codes that shall be supported by the GW device are:

17

9 SERIAL PORT PROFILE REQUIREMENTS

9.1 In case of Cell Phone or Modem

The serial port profile is used with DT as DevA and GW as DevB.

The serial port profile shall be used with the service 9-Wire.

9.2 In case of Terminal Adapter

Further requirements are imposed on the way reception of flow control parameters shall be implemented in the IrCOMM instances on both the DT and the GW. An additional IAS entry is required.

The serial port profile is used with DT as DevA and TA as DevB.

The serial port profile shall be used with the service 3-Wire.

The serial port profile may be used with the service 9-Wire.

9.3 Communication settings negotiation

The GW function must be able to accommodate the following communication settings, if requested by the DT:

Data speed: 300 / 600 / 1200 / 2400 / 4800 / 9600 / 19200 bps

Data format: 8N1 / 7E1 / 7O1 / 7N2 (character length, parity, stop bit )

When IrTA receives port communication settings on the control channel, it must set itself in accordance send the same parameters back to the serial port emulation entity on the DT to confirm the settings.

It IrTA can not set itself with the requested parameters, it must maintain its previous settings and send their values to the serial port emulation entity on the DT.

Upon establishment of the IrCOMM link, the following default settings are to be used:

Data rate: 9600 bps Flow control: RTS/CTS Data format: 8N1

XON/XOFF character: 0x11/0x13 (VT / CR)

ENQ/ACK character: 0x05 / 0x06 (ENQ / ACK)

Settings negotiation in IrTA can only be performed using the IrCOMM Control capability of IrCOMM, i.e. communication settings can never be negotiated as part of the connection request/response process.

9.4 Flow control requirements

9.4.1 Incase of Cell Phone or Generic Modem

No usage should be made of the DSR/DTR or ENQ/ACK flow control mechanism. XON/XOFF software flow control and RTS/CTS hardware flow control are the two allowed mechanisms.

When it comes to how the various flow control parameters are used, a lot of issues are implementation specific.

Hardware flow control parameters can be dealt with entirely by the IrCOMM implementation or could be passed to the above dialing and control entity for processing. Some IrCOMM implementation does control the flow of data coming from and going to the dialing and control entity they are locally serving. Others are completely submitted to the dialing and control entity.

18

The IrModem profile however imposes a few requirements on some of the possible behaviors ( see [IrCOMM] 14.3.2 for a description of the terminology ):

•If the local IrCOMM instance scans for XON/XOFF characters in the data flow coming from the local client, then XON/XOFF characters shall be acted upon by the local IrCOMM instance and not be forwarded to the remote IrCOMM instance. (They are stripped out of the user data field of the IrCOMM frames).

•If the local IrCOMM instance scans for XON/XOFF characters in the data flow coming from the remote IrCOMM instance, then XON/XOFF characters shall be forwarded to the local client, no matter whether they are also acted upon by the local IrCOMM instance or not.

•If the local IrCOMM implementation scans for RTS (or CTS depending on the DT or GW nature of the device) signal changes coming from its local client, the changes shall be transmitted to the host IrCOMM instance, no matter whether they are also acted upon by the local IrCOMM instance.

•If the local IrCOMM implementation scans for RTS (or CTS) signal changes coming from the host IrCOMM instance, the changes shall be transmitted to the local client, no matter whether they are acted upon by the local IrCOMM instance or not.

More, it is highly recommended to make sure that:

•Each IrCOMM instance should scan for XON/XOFF characters in both the data flows coming from the local client and the host IrCOMM instance.

•Same recommendation for RTS (CTS)

9.4.2 Incase of Terminal Adapter

The 3 wire service does not transmit non-data circuits states, but it emulates them locally for the application that is using IrCOMM.

No usage should be made of the DSR/DTR or ENQ/ACK flow control mechanisms. XON/XOFF software flow control and RTS/CTS hardware flow control are the only authorized mechanisms.

On the DT side:

Upon opening of an IrCOMM link between the TA and the DT, the serial port emulation shall set CTS, DSR, CD and RI at “ON” for the modem driver to know the link is available.

When the modem driver wishes to terminate an IrCOMM link, it sends a “ DTR to “OFF” “ request to the serial port emulation. The serial port emulation then performs the IrCOMM disconnection.

A change of CTS, DSR, CD and RI status to “OFF” is an indication from the serial port emulation to the DT modem driver that the IrCOMM link as been cut.

On the TA side:

If XON/XOFF is chosen as flow control method in IrTA, software flow control information must never be sent to the DT. Instead, the IrTA shall always enforce flow control in accordance.

Otherwise (especially when RTS/CTS is the chosen flow control method) XON/XOFF characters are transparently sent to the DT.

9.5 Network disconnect

The GW conveys a network disconnect to the DT by setting the DTR signal from to “OFF”

9.6 IAS Requirements

Support for IrDA Plug'n Play [PnP] is optional but recommended. By adding an object of Class PnP in the IAS entries on the GW side, we allow for checking by the DT that the right modem is installed.

19

10 TEST GUIDELINE

10.1 Introduction of tests

10.1.1Purpose

This section specifies the test guideline used to verify an IrDA Serial Port and IrModem device. The goal of this document is to ensure interoperability between various Serial Port and IrModem devices and products.

10.1.2Scope

The tests described in this document do not verify the lower layers of the IrDA stack. They target only the over IrCOMM application layers such as AT Commands [V250].

10.1.2.1 SERIAL PORT TEST SCOPE

The Serial Port Test Guideline was defined in IrCOMM Compliance Tests[IrCOMM Test] , You must follow this guidelines.

10.1.3Device Types

A type 1 device is inspected by monitoring the transmission and reception of Application Data stream in the infrared beam. The state of the control signals is often communicated through a high level API. Wherever possible, these API’s can be used to examine the control signal state changes.

A device of type 2 is tested by examining both the I Application Data sent over the infrared beam, and by examining the states of the control signals on the wire.

10.2 Environment

10.2.1Hardware

The following list includes examples of the type of hardware that is required:

•Device Under Test (DUT)

•PC or another device to generate test frames.(IrDA Test Equipment)

•IR Frame Monitor for tracing low level IR frames

20

10.2.2Software

The following list includes examples of the type of software that is required:

•IrCOMM Test program (PC) or Built in Test programs (IrDA Test Equipment).

10.2.3Typical Test Environment

The following figure includes examples of the type of typical test environment.

10.2.3.1 TYPE-1 DEVICE TEST ENVIRONMENT

IR Frame

Monitor

10.2.3.2 TYPE-2 DEVICE TEST ENVIRONMENT

Type 2 Device Test Environments

10.3 Overview Compliance Tests

The test scenarios assume that the device under test is an IrModem or IrTA device, and that the tester is software running on an IrCOMM frame generator.

10.3.1What Tests Apply to Your Product?

The IrModem specification defines various applications (Type-1, Type-2,Cell Phone, IrTA, Modem, etc.) and levels of support. The tests that your product must pass depend on the level of support that your product offers. See the following sections.

10.3.1.1 GW / INITIATOR/RESPONDER

The tests items have been named according to test groups.

21

10.3.1.2 IRMODEM PROTOCOL LEVELS

As defined in IrModem, data can be exchanged through IrCOMM entities.

The tests have been named according to the level being verified.

IrCOMM_V250_xx V.25 ter (AT Command) level

10.3.2General Test Steps

The majority of the tests involve transferring data streams and DTE/DCE controls signals between the device under test and the IrDA test equipment. The following steps should be performed.

1.Switch on the device under test, and activate the IR port if appropriate.

2.Switch on the IrDA test equipment.

3.Point the IrDA ports at each other. Ensure that they are within the operating distances defined for the devices.

4.Generate an IAS Get Value By Class request from the device. There are some types of Class and Attribute. Choice one of them.

(4_CK) For a serial emulation (used by 3-Wire or 9-Wire) device, Generate an IAS Get Value By Class request from the device, for the IrCOMM class, and attribute IrDA:TinyTP:LsapSel. If the test is a responder test, then the tester should make the request.

(4_3R) For a printer or serial device (used by 3-Wire Raw), generate an IAS Get Value By Class request from the device for the IrCOMM class and attribute IrDA:IrLMP:LsapSel. If the test is a responder test, then the tester should make the request.

5.Make a connection from the device to the LSAP returned in the response to the Get Value By Class request. If the test is a responder test, then the tester should make the connection.

6.Generate the IrCOMM Data/Control requests from the IrDA test equipment or device under test.

7.Verify that the data was transferred without any problems.

10.4 IrModem Application Tests over IrCOMM

These tests are mandatory for all devices with IrModem.

10.4.1Test Sequence

1.General Test Steps 1-6.

2.Generate a test item V.25 command stream from Tester.

3.Verify and check command response at the Tester.

22

10.4.1.1 V.25 TER COMMAND TEST

23

11 TEST RESULT TEMPLATE

Remarks:

24

25