IrREADY IrModem profile V1

IrREADY Serial Port Profile / IrModem Profile Draft Version 0.9

6

4 IRCOMM INTEROPERABILITY REQUIREMENTS

4.1 Service Types

The following requirements are imposed on any device wishing to support the IrDA Serial Port Profile:

4.2 Service Interface

*as part of the data field of the IrCOMM frames

**includes data rate, data format ( character length, stop bits, parity type ), flow control settings, XON/XOFF character choice and ENQ/ACK character choice.

O1: the implementation of these features in the IrCOMM instance as such is optional. Notice however that it is mandatory for DevB as a whole to be able to respond to the signals coming from DevA. If this ability is not embedded in the IrCOMM instance, it must be offered by the application that makes use of this IrCOMM instance.

4.3 Control Parameters

4.3.1 Packet size considerations

Data to be sent by IrCOMM must fit the IrLAP packet size ( minus 4 bytes of overhead of IrLMP, TinyTP and Control Channel header ). Whereas user data is just a stream of of bytes to be pushed across the link without any modification, particular care must be taken to control parameters, which are multi bytes entities and must fit within a single IrLAP packet.

7

4.3.2 Service Type Control parameter

The service type parameter must be sent from DevA to DevB immediately after the discovery operation in the control channel of the TTP connect request. (It is mandatory for DevB to monitor incoming packets for control channel information)

4.3.3 Port Communication Settings parameters

4.3.3.1 AT CONNECTION ESTABLISHMENT:

If the default values for the communication settings (as defined in [IrCOMM] ) are not the optimal ones for DevA and DevA supports the sending of communication settings parameters, DevA must send the parameters it wishes before any actual user data sending can take place. DevB answers by either sending back the same communication settings or disconnecting. If the default values for the communication settings are not the optimal ones for DevB, DevB must send the parameters it wishes before any actual data sending. DevA can reply either by applying the new settings and sending back those settings or by ignoring the request from DevB, thus enforcing the link to behave in the default way.

It is implementation dependent whether these parameters are sent in the connect/connect-response frame or in the first data frames.

4.3.3.2 DURING DATA TRANSFER:

If communication settings parameters change during the course of a connection, the device that initiates these changes must inform the other device ( using the control channel of the IrCOMM frame ), which naturally implies that it supports the sending of communication settings parameters. When receiving new communication settings from DevA, DevB shall either apply the settings or disconnect the link. When receiving new communication settings from DevB, DevA shall either ignore the new settings, or apply them and send them back to DevB.

4.3.4 V.24 Control Parameters

4.3.4.1 AT CONNECTION ESTABLISHMENT

Prior to any data sending, the initial state of the V24 link must be sent to the other device using the DTE line settings or DCE line settings control parameters (provided initiating RS232 control parameters is supported). The delta bits shall all be set to 0 (no change). It is implementation dependent whether these parameters are sent in the connect/connect-response frames or in the first data frames.

If one of the devices (d) does not support the sending of V.24 control parameters, the other device (D) must assume that the V24 status on (d) allows for (D) to send and receive data to and from (d).

8

5 IRDA LOW LEVEL LAYER REQUIREMENTS

5.1 Physical Layer

Devices are allowed to support the short-range option as described in [IrPHY]

5.2 IrLAP

No special requirement on the IrLAP layer as described in [IrLAP].

5.3 IrLMP / Tiny-TP Requirements

DevB devices shall return the hint bit for IrCOMM in the device info field of the discovery frames. If DevB is a printer, it shall also return the hint bit for printers. If DevB is a modem, it shall also return the hint bit for modems.

Tiny TP and IrLMP/LAP combined form the IrDA transport layer.

The steps involved in setting up a Tiny TP connection with DevB are:

1.DevA discovers DevB if no IrLAP connection is already active between them.

2.DevA queries the IAS of DevB for the IrCOMM IAS entry.

3.DevA performs a Tiny TP connect request to the LSAP-SEL retrieved in step 2.

If there is already an existing IrLAP link between the 2 devices, then step 1 can be skipped.

If an IrCOMM connection already exists between DevA and DevB then any attempt by DevA to establish another connection shall trigger a TinyTP disconnection indication. It is implementation dependent and optional whether a request for an additional IrCOMM connection can be issued by DevB and properly processed by DevA.

Note that if the service to be used is the 3-Wire raw service, then the LSAP-SEL to connect to is not the TinyTP:LSAP-SEL but the IrLMP:LSAP-SEL. Step 3 is also replaced by a LMP connect to this IrLMP:LSAP-SEL.

5.3.1 Discovering DevB

DevA must discover DevB using the IrLMP discovery service described in [IrLMP] unless it already has an IrLAP connection to another device in which case DevB is this other device.

5.3.2 Establishing a Tiny TP Connection

DevA must establish a Tiny TP connection DevB using the Connect request procedure described in [TINYTP]

5.4 IAS Requirements

The GW device must have an IAS object for IrCOMM. This object shall belong to the class IrDA:IrCOMM.

This object shall have one attribute of name "IrDA:TinyTP:Lsap-Sel", of type integer and of value the Lsap that is tied to the IrCOMM layer that provides the suitable service type.

9

This object shall also have one attribute of name "Parameters", which is a collection of one or more parameters characterizing an IrCOMM service. Their description can be found in [IRCOMM], 6.2.2.

The Service Type parameter shall have at least bit 1 or bit 2 set to 1 (support for at least one of 3-wire and 9-wire)

The Port Type parameter shall have at least bit 0 set to 1 (serial port)

The Fixed Port Name parameter is optional and shall only be used if the virtual com port is to be used with a particular (set of ) well-know device(s).

If the service 3-Wire Raw is also supported, then it is mandatory to also have in the IrDA:IrCOMM object an attribute of name IrDA:IrLMP:Lsap-Sel", of type integer and of value the Lsap that is tied to the IrCOMM layer when 3-Wire Raw service is active.

10

6 IR MODEM PROFILE OVERVIEW

The basic scenario covered by this profile is the usage of the infrared link offered by the IrDA technology to transport user data and control signaling between a device acting as gateway to a public telecommunication network and a device willing to receive and send data through this network.

6.1 In Case of Generic Cell Phone or Modems

In case of the Modem, This profile is built upon the IrDA Serial Port Profile and is based on [V250] and [GSM0707]. The present chapter details further the user scenario and provide the general framework for the profile. The subsequent chapters detail how the Serial Port Profile is used and what kind of support is required for [V250] and [GSM0707].

6.2 In Case of Terminal Adapters

In case of the Terminal Adapter, This profile is built upon the IrDA Serial Port Profile and is based on [V250] and [V110]. The present chapter details further the user scenario and provide the general framework of the profile. The subsequent chapters detail how the Serial Port Profile is used and what kind of [V250] and [V110] support is required

6.3 Configuration and Roles

User Data

Control Signalling

Figure 2 IrDA Dial Up example between a mobile phone and a laptop PC

The following roles are defined for this profile.

Gateway (GW) – This is the device that provides access to the public network. Typical devices acting as Gateway are cellular phones and modems. The GW is the function that relays control sequence and user data between the remote receiving device and the DT device. The TA and GW functions can be implemented physically in one device, like the Japanese public phones for instance where the GW is the modem function of the public phone.

Data Terminal (DT) – This is the device that uses the dial-up services of the Gateway. Typical devices acting as data terminals are laptop PCs, desktop PCs and PDAs.

For purposes of mapping the Dial-Up Networking profile to the conventional modem system architecture, the GW is considered Data Circuit Endpoint (DCE) and the DT is considered Data Terminal Endpoint (DTE). ). Seen from the GW function, the terminal adapter is actually a DT device that terminates the v.24

11

6.4 User Scenarios

The Ir Modem Profile covers the following two usage cases:

•The GW is used by the DT as a wireless modem for connecting to a dial-up internet access server or any other server offering dial-up based services (typically the inter-working function of a public telephone network).

•The GW is used by the DT to receive data calls.

•The device that offers TA and GW services is used by the DT as a wireless modem for connecting to a dial-up Internet access server or any other server offering dial-up based services.

The following restrictions apply to this profile:

In case of incoming call, this profile does not provide to the GW the ability to report to the DT the nature of the incoming call.

Only one call at a time is supported

The profile only supports point-to-point configurations

This profile does not support multiple instances of its implementation in the same device.

This profile does not provide any kind of security at all. Neither authentication/authorization procedures nor encryption of transported data are proposed.

6.5 Protocol Stack

6.5.1 In Case of Generic Cell Phone or Modems

12

6.5.2 In Case of Generic Cell Phone or Modems

V24 hardware interface

The fundamental difference between the Serial Port Emulation entity and the IrTA Service Entity is that the Serial Port Emulation and the above application are talking via an API (software v24 interface like VCOMM for instance), whereas the IrTA Service Entity is a Serial Port Controller that conveys control parameters to the GW device using the hardware control signals of the cable link between the TA and the GW (hardware V.24 interface).

IrDA Hardware is governed by the [IrPHY]

IrLAP is the link level protocol specified in [IrLAP].

IrLMP is a multiplexing layer specified in [IrLMP]

Tiny TP provide flow control and is specified in [TINYTP]

IAS is the Information Access Service specified in [IrLMP]

IrCOMM provides the emulation of a serial cable as defined in [IrCOMM]

Dialing and control is the commands and procedures used for dialing and control over the reliable asynchronous link provided by the lower layers. Dialing and control is using a subset of the ITU-T V.250 protocol (referred to as V.25ter until February 1998)

Modem emulation and Modem driver are respectively the entity emulating the modem and the driver software in the DT.

Serial port emulation provides the commands and procedures used for dialing and control over the reliable asynchronous link provided by the lower layers. Dialing and control is using a subset of the ITU-T V.250 protocol (referred to as V.25ter until February 1998)

IrTA service entity maps v.24 signals sent by the GW via a physical serial cable to TinyTP and IrCOMM control signals. See the dedicated Annex in [IrCOMM]

13

6.6 Conformance

If conformance to this profile is claimed, all capabilities indicated mandatory for this profile should be supported in the specified manner. This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities, and optional and conditional capabilities for which support is indicated, are subject to verification as part of the IrReady certification program.

14

7 APPLICATION LAYER

The services provided by an application claiming support for the IrDA IR Modem Profile shall be:

15