12 AT commands

27.0603GPPMobile Station (MS) supporting Packet Switched servicesPacket domainRelease 17TS

3GPP TS 27.007 defines commands that a TE may use to control a MT supporting Packet Switched services, via either a non-multiplexed character-stream interface or a mutliplexed character stream interface (27.010). A non-multiplexed character stream interface places certain limitations on the functionality of the interface. For example, it is not possible for the MT to send control information to the TE or for the TE to send commands to the MT whilst the interface is in the V.250 online data state unless the layer 2 protocol itself supports this feature. However, a manufacturer-specific escape mechanism may be provided to enable the TE to switch the MT into the V.250 online command state. It is anticipated that MTs will vary widely in functionality. At one extreme, a class A or PS/CS MT might support multiple PDP types as well as circuit switched data, and use multiple external networks and QoS profiles. At the other extreme a class C or PS MT might support only a single PDP type using a single external network, and rely on the HLR to contain the context definition.

A comprehensive set of Packet Domain -specific AT commands is defined in 3GPP TS 27.007 to provide the flexibility needed by the more complex MT. The commands are designed to be expandable to accommodate new PDP types and interface protocols, merely by defining new values for many of the parameters. Multiple contexts may be activated if the interface link-layer protocol is able to support them. The commands use the extended information and error message capabilities described in 3GPP TS 27.007.

For MTs of intermediate complexity, most commands have simplified forms where certain parameters may be omitted.

For the simplest MTs, and for backwards compatibility with existing communications software, it is possible to control access to the Packet Domain using existing modem-compatible commands. A special dial-string syntax is defined for use with the D command. This "modem compatible" mode of operation is described in 3GPP TS 27.007.

Subclause 12.2 contains examples of command sequences for a number of applications.

Annex A of the present document lists the AT commands for the Packet Domain. They are fully defined in 3GPP TS 27.007.

12.1 General on AT commands

The following subclauses describe how the AT commands are used for the Packet Domain. The AT commands themselves are fully described in 3GPP TS 27.007. Reference to the particular AT command names are shown only for clarity. In all case refer to 3GPP TS 27.007 for the latest descriptions.

12.1.1 Interaction of AT commands, Packet Domain management and PDPs

State machines may be used to describe the behaviour of:

– AT commands (ITU-T V.250);

– PDP context management (3GPP TS 23.060);

– PDP startup, data transfer and termination (Packet Data Protocol specifications);

– the layer 2 protocol (if any) used across the TE-MT interface (layer 2 protocol specifications).

This subclause does not attempt to describe in detail how these state machines interact but rather to give some general guidance on their relationships.

12.1.1.1 AT commands and responses

AT commands may be issued and responses received by the TE only when the TE and MT are in V.250 command state.

The possibility of suspending the PDP and/or layer 2 protocol and entering V.250 online command state is not considered here; neither is the use of a multiplexed interface where the PDP and the AT commands use separate logical channels.

12.1.1.2 PDP and layer 2 protocol operation

The PDP (across the TE-MT interface) may startup, transfer data and terminate only when the TE and MT are in V.250 online data state. It may be necessary to startup a layer 2 protocol across the interface before starting the PDP. The PDP startup procedure may provide information needed for the PDP context activation procedure (see subclause 10.1.1.3.2).

12.1.1.3 Management of Packet Switched services

A particular PDP may be used to transfer data only when a context is active for that PDP. Before a context can be activated, the MT must be attached to the Packet Domain network.

In order to provide flexibility and support a variety of types of MT and PDP, AT commands are provided which give the TE explicit control over attachment and detachment (+CGATT), and context activation and deactivation (+CGACT) procedures. These commands allow the TE to retain control of the MT, and receive status information from the MT, after these actions have been performed.

12.1.1.3.1 PS attachment

The MT may be attached and detached using the +CGATT command. However, it may not be necessary to use the command since attachment may occur:

– on power up or reset;

– when an attempt is made to activate a context either explicitly (+CGACT) or as a result of a PDP startup -procedure;

– when the mobile class is changed (+CGCLASS).

Similarly, detachment may occur:

– as a result of a PDP termination procedure (if no other Packet Switched services are active);

– when the mobile class is changed (+CGCLASS).

12.1.1.3.2 PDP context activation

Certain information must be provided to the network in order for a context activation attempt to be successful. The TE may provide some of this information to the MT during the PDP startup procedure rather than through AT command procedures. In this case the context activation cannot be initiated by the +CGACT command but rather on receipt of the appropriate information during the PDP startup.

12.1.2 Use of default context parameter values

The activate context request message sent by the MT to the network contains a number of parameters whose values can usefully be set by the TE. Under certain circumstances the values for some or all of the parameters need not be provided by the TE, either via AT commands or the PDP startup procedure. The storage of context information in the SIM is not considered in the present document. Rules concerning what values shall be sent by the MT to the network under various circumstances are given in 3GPP TS 23.060.

One particular rule that is designed to simplify operation in modem compatibility mode is that if there is only one PDP context subscription in the HLR then all of PDP type, PDP address and APN may be omitted.

12.1.2.1 PDP type

This may be omitted:

– when the MT supports only one PDP type (it will be provided by the MT); or

– according to the rules given in 3GPP TS 23.060.

12.1.2.2 PDP address (of the MS)

This shall be omitted when:

– a dynamic address is required; or

– according to the rules given in 3GPP TS 23.060.

12.1.2.3 Access Point Name

This may be omitted:

– according to the rules given in 3GPP TS 23.060.

12.1.2.4 QoS Requested

This may be omitted when:

– the default subscribed QoS is acceptable.

When the application in the TE requires streaming or conversational QoS, then the MS shall at least explicitly request the traffic class and should explicitly request the guaranteed bit rate and the maximum bit rate.

12.1.2.5 PDP Configuration Options

These shall be omitted:

– when none are required for the PDP concerned; or

– according to the rules given for the PDP.

12.2 Example command sequences for dial-compatibility mode

12.2.1 PPP in dial compatibility mode

12.2.1.1 Mobile initiated IP context activation

In this mode of operation, the MT behaves like an originating modem and accepts the normal V.250 commands associated with placing and clearing a call to a dial-up PPP server. Although the procedures for setting up the IP context are initiated from the mobile end, IP-based sessions, for example the File Transfer Protocol (FTP), may be initiated from either end once the context is active.

For this example it is assumed that:

– the user has subscribed to only one PDP context (of type IP) and therefore no context parameter values are needed;

– the MT supports only PPP at the MT-TE interface and therefore no layer 2 protocol need be specified.

A possible sequence of events is:

– the MT begins in V.25 command state:

– TE -> MT: AT<Packet Domain-specific configuration commands, if required>;

– MT -> TE: OK.

– the TE sends a dial command requesting the Packet Switched service:

– TE -> MT: ATD*99#;

– MT -> TE CONNECT.

– the MT enters V.250 online data state:

– TE starts up PPP (LCP exchange);

– TE -> MT: LCP Configure-request;

– MT -> TE: LCP Configure-ack:

– PPP Authentication may take place (optional);

– TE starts up IP (NCP for IP exchange):

– TE -> MT: NCP(IP) Configure-request;

– MT <-> network: MT performs the PS-attach procedure if the MT is not currently attached;

– MT <-> network: MT performs the IP context activation procedure;

– MT -> TE: NCP(IP) Configure-ack;

– TE <-> MT< – > network: IP packets may now be transferred.

– TE stops IP (optional):

– TE-> MT: NCP(IP) Terminate-Request ); this

– MT<-> network: MT performs the IP context deactivation procedure); is

– MT -> TE: NCP(IP) Terminate-Ack ) optional.

– TE stops PPP:

– TE-> MT: LCP Terminate-Request;

– MT <-> network: MT performs the IP context deactivation procedure if it has not already done so;

– MT <-> network: MT may perform the PS-detach procedure if no other Packet Switched services are active;

– MT -> TE: LCP Terminate-Ack.

– the MT returns to V.250 command state and issues the final result code :

– MT -> TE NO CARRIER.

The TE may recognise this as a return to V.250 command state. However, if it is using procedures intended for controlling modems, it may attempt to force a disconnect since in the modem case it cannot rely on the remote modem dropping the carrier. It will use some combination of:

– TE -> MT: TE drops circuit 108/2 (Data Terminal Ready);

– TE -> MT: escape sequence (e.g. +++);

– TE -> MT: ATH.

The MT should respond according to V.250 even if it is already in command state.

If the connection is lost at any time, the MT shuts down PPP, returns to V.250 command state and issues the final result code:

– MT -> TE NO CARRIER.

12.2.1.2 Network requested IP context activation

In this mode of operation, the MT behaves like an answering modem and accepts the normal V.250 commands associated with answering a call to a PPP server. Although the procedures for setting up the IP context are initiated from the network end, IP-based sessions, for example the File Transfer Protocol (FTP), may be initiated from either end once the context is active.

Two example sequences of events are given, for the cases of automatic and manual answering:

Case 1: automatic answering

The MT begins in V.250 command state:

– TE -> MT: AT<Packet Domain -specific configuration commands, if required >.

The TE sets automatic answering mode:

– TE -> MT: ATS0=1:

– MT <- > network: MT performs the PS-attach procedure if the MT is not currently attached.

Subsequently:

– network -> MT: Request PDP Context Activation message;

– MT -> TE: RING.

The MT returns the intermediate result code:

– MT -> TE CONNECT,

and enters V.250 online data state.

The TE and MT perform the PPP and IP startup procedures which include the MT requesting the network to activate the IP context.

Case 2: manual answering

The MT begins in V.250 command state:

– TE -> MT: AT<Packet Domain -specific configuration commands, if required >.

The TE sets manual answering mode and requests a PS-attach (if necessary):

– TE -> MT: ATS0=0;

– TE -> MT: AT+CGATT=1;

– MT <- > network: MT performs the PS-attach procedure if the MT is not currently attached;

– network -> MT: Request PDP Context Activation message;

– MT -> TE: RING.

The TE answers manually:

– TE -> MT: ATA;

– MT -> TE CONNECT,

and enters V.250 online data state.

The TE and MT perform the PPP and IP startup procedures which include the MT requesting the network to activate the IP context:

or the TE rejects the connection:

– TE -> MT: ATH.

and remains in V.250 command state.