Over The Air Parameter Administration (OTAPA)
2.11 Packet Data Calls
2
Data services are grouped into two categories: circuit-oriented (includes Asynchronous
3
Data and Group-3 Fax services) and packet. Call flows applicable to packet data calls are
4
described in this section. See [14] for valid service options. Note some service options are
5
only valid for Intergeneration Handoff (handoff between systems supporting packet data
6
services based on ANSI/TIA/EIA/IS-95-B and systems supporting packet data service
7
based on TIA/EIA/IS-2000). Intergeneration Handoffs are described in section 2.16.
8
For all calls supporting packet data services, a Packet Data Serving Node (PDSN) exists
9
that interfaces between the transmission of the data in the fixed network and the
10
transmission of the data over the air interface. The PDSN interfaces to the BS through a
11
Packet Control Function (PCF), which may or may not be co-located with the BS.
12
For purposes of the protocol of this standard, there are three packet data service states:
13
Active/Connected, Dormant, and Null/Inactive. In the Active/Connected State, a physical
14
traffic channel exists between the mobile station and the base station, and either side may
15
send data. In the Dormant State, no physical traffic channel exists between the mobile
16
station and the base station, but the PPP link between the mobile station and the PDSN is
17
maintained. In the Null/Inactive State, there is no traffic channel between the mobile
18
station and the base station and no PPP link between the mobile station and the PDSN.
19
Active / Connected
State
Dormant State
Null/Inactive State
20
Figure 2.11-1 Packet Data Service State Transitions
21
A1 and A8 connections are maintained during the Active / Connected State and released
22
during transition to Dormant or Null/Inactive State. The A10 connection is maintained
23
during the Active/Connected and the Dormant State.
24
As part of the support for the Dormant State, the TIA/EIA/IS-2000 air interface supports
25
a Data Ready to Send indicator that is used on Origination. When a mobile station sends
26
an origination request with a packet data service option specified, it includes the Data
1
Ready to Send (DRS) bit. This indicator is set to 1 on initial call setup and when the
2
terminal transitions from Dormant to Active because it has data to send and is requesting
3
the establishment of a traffic channel. The DRS bit is set to 0 to indicate that the terminal
4
has crossed a Packet Zone boundary while dormant, and is sending the origination
5
request to update the network as to its current location. On receipt of an origination with
6
the DRS bit set to 1, the BS will initiate the call setup procedure as described in Section
7
3.11.4.2.1, which will normally result in the establishment of a traffic channel and in the
8
A8 and A10 bearer connections being established. Note, traffic channels are not
9
established for Common Channel Packet Data (CCPD) Service. See Section 3.11.5.6 for
10
the call flow.
11
When the BS receives an origination with the DRS bit set to 0, the BS will delay the
12
establishment of a traffic channel until after the A8 and A10 bearer connection
13
establishment procedures are complete. During the A8 bearer connection establishment
14
procedure, the BS will indicate to the PCF that a DRS=0 has been received through the
15
use of the Data Ready Indicator element in the A9-Setup-A8 message. If the PCF has
16
data from the network to deliver to the terminal, it will indicate this by setting the Cause
17
element in the A9-Connect-A8 message to the Data Ready to Send value. The BS will
18
then establish a traffic channel to the terminal and complete a normal call setup procedure
19
as in Section 3.11.4.2.1.
20
If the PCF does not have data, it indicates that the A8 is not to be established by sending
21
the A9-Release-A8 Complete message to the BS. The BS will then return an Assignment
22
Failure message to the MSC with the Cause value set to Packet Call Going Dormant.
23
Upon receipt of the Assignment Failure message, the MSC returns a Clear Command to
24
the BS with the Cause value set to Do Not Notify Mobile. The BS sends a Clear
25
Complete message to the MSC upon receipt of the Clear Command message.
26
A CCPD Device requests CCPD Mode from the network by sending an Origination
27
Message to the BS with the SDB_DESIRED_ONLY bit set to 1 and the
28
FCH_SUPPORTED and DCCH_SUPPORTED bits set to 0. An A8 bearer connection is
29
not required. PPP connection setup and Mobile IP Registration (if required) are
30
performed using Short Data Bursts over common channels to exchange the messages.
31
Upon successful completion of these procedures, the mobile’s packet data service
32
instance transitions from the Null/Inactive to Dormant state. A CCPD Device’s packet
33
data service state shall never transition to the Active/Connected state. Upon successful
34
establishment of the packet data session, the CCPD device and network may exchange
35
small amounts of data over common channels. Mobile IP Registration is not required for
36
CCPD applications that do not require mobility.
37
An IS-2000 mobile may request Common Channel Packet Data (CCPD) Service from the
38
network by setting the SDB_DESIRED_ONLY and TCH-SUPPORTED bits in the
39
Origination Message to 1. If the BS agrees to support the mobile’s request for CCPD
40
Mode, PPP connection setup and MIP registration are performed over common channels
41
using Short Data Bursts. An A8 bearer connection is not required. Upon successful
42
completion of these procedures, the mobile’s packet data service state transitions from
43
the Null to the Dormant State.
44
See section 3.11 and accompanying subsections for call flows associated with packet
45
data.
46
2.11.1 Packet Data Assumptions
1
This standard makes certain assumptions regarding packet data service; please see section
2
3.11.1 for a list of these assumptions.
3
2.11.2 Previous and Current Access Network Identifiers
4
(PANID/CANID)
5
The selected PDSN needs to know whether a mobile is being handed off by a PCF that
6
was not previously using this PDSN for the connection, in order to determine if PPP
7
reconfiguration and Mobile IP registration are required. The information used to make
8
this determination consists of the PZID, SID or NID (PZID), System ID (SID) and
9
Network ID (NID) values, which are also referred to as the Access Network Identifiers.
10
The PCF is uniquely identified by the Current Access Network Identifiers (CANID) and
11
every PCF knows its CANID value. Anytime a mobile crosses into a new region, where
12
the region is defined by the Access Network Identifiers, it must re-register with that
13
Access Network.
14
See section 3.11.2 for more details.
15
2.11.3 PDSN Selection Algorithm
16
This algorithm is assumed to be used for initial PDSN assignment and PDSN reselection
17
in this standard. See section 3.11.3 for details.
18
2.11.4 A8/A9 Interface Call Flows
19
See section 3.11.4 for details of A8/A9 call flows.
20
2.11.5 A10/A11 Interface Call Flows
21
The A10/A11 interface uses Mobile IP messages for managing the A10 connections. The
22
MS initiates a packet data call by sending an IS-2000 Origination Message. Normal voice
23
service authentication procedures are followed for the subscriber, and then a traffic
24
channel is established with the mobile. After connection of a packet data service option,
25
RLP synchronization between the mobile station and the BS proceeds. The BS/PCF
26
initiates setup of an A10 connection with the PDSN by sending an A11-Registration
27
Request message on the A11 interface. The PDSN may accept or reject the connection
28
setup request. If the connection setup request is acceptable, the PDSN returns an
A11-29
Registration Reply message with an accept indication, and the packet data call is
30
connected through the just established A10 connection.
31
With the A10 connection in place, link layer/network layer frames pass over this
32
connection in both directions via Generic Routing Encapsulation (GRE) framing. The
33
PDSN accepts these frames, strips the GRE, and processes them as normal incoming
34
frames for the appropriate interface and protocol. The other direction behaves
35
analogously, with the PDSN encapsulating the link layer/network layer frames in GRE,
36
and the PCF stripping the GRE before passing the frames over to the upper layer. At this
37
point, there is a point-to-point link layer/network layer connection between the MS and
38
the PDSN.
39
In order to setup an A10 connection, the PCF sends an A11-Registration Request
40
message to the PDSN. This message includes a PCF Session Identifier (PCF SID) to be
used by the PDSN as the Key in the GRE header when sending data frames on the A10
1
connection. The PCF Session Identifier (PCF SID) is unique only within the PCF entity.
2
In the A11-Registration Reply message, the PDSN assigns a PDSN Session Identifier
3
(PDSN SID) to be used by the PCF as the Key in the GRE header when sending data
4
frames on the A10 connection. If both the PCF and the PDSN support a Session Identifier
5
Version higher than 0, the PDSN SID may be different from the PCF SID. This allows
6
the PDSN to choose a PDSN SID that is unique within the PDSN. Otherwise, the PDSN
7
SID shall be identical to the PCF SID, thereby maintaining backwards compatibility. The
8
PCF will also use the MN Session Reference ID (MN-SRID) which is passed from the
9
mobile on each origination and which, together with the Mobile Identifier, can be used to
10
identify a packet data service session for a specific mobile across PCFs and PDSNs. In
11
the A11-Registration Request message, the PCF sets the Home Address field to zeros.
12
The IP source address (IP header) and the Care-of-Address field of the A11-Registration
13
Request message are set to the IP address of the PCF. The IP destination address in the IP
14
header and the Home Agent field in the A11-Registration Request message are set to the
15
address of the PDSN designated for the call. The PCF Session Identifier (PCF_SID), link
16
layer/network layer protocol type identifier, MN Session Reference ID and MS_ID of the
17
MS are set in the Session Specific Extension of the A11-Registration Request message.
18
The A10 bearer connection is used for the transport of user data for a packet data session.
19
Link layer/network layer frames are carried between the PCF and the PDSN encapsulated
20
in GRE packets, which in turn are carried over IP. The PCF-Address and the
PDSN-21
Address are used in the source address and destination address fields of the IP header
22
used with the GRE packet. In the bearer traffic direction from the PDSN to the PCF, the
23
key field in the GRE header contains the PCF Session Identifier (PCF SID), and indicates
24
which packet data bearer connection a particular payload packet belongs to. In the bearer
25
traffic direction from the PCF to the PDSN, the key field in the GRE header contains the
26
PDSN Session Identifier (PDSN SID).
27
When the PDSN SID is unique within the PDSN, the PDSN can use it to identify which
28
bearer connection the packet belongs to. Otherwise, the PDSN may use the combination
29
of the PCF Address and the PDSN SID parameters of each received packet in order to
30
identify the associated packet data bearer connection.
31
The A11-Registration Request messages and A11-Registration Reply messages are
32
defined by [56] with extension elements defined in [17]. The A11-Registration Update
33
messages and A11-Registration Acknowledge messages are also defined in [17].
34
See section 2.11.5 for call flows related to this interface.
35
2.11.6 Version Interoperability Control
36
The architectural assumptions for the A10-A11 interface version control scheme for a
37
communicating PDSN-PCF pair are:
38
♦ The architectural principle, in [56] on which the A10-A11 interface is based, shall
39
not be violated.
40
♦ The latest IOS version shall be backward compatible with older supported IOS
41
versions.
42
The structure of the mandatory elements shall not change in revisions of the IOS
43
standard. See section 3.11.6.2 for details of how version control is implemented on the
44
A10/A11 interface.
45
See section 3.11.6.1 for a description of the call flow demonstrating how version control
1
is implemented on the A8/A9 interface.
2
2.11.7 Support of Short Data Bursts
3
IS-2000 defines short data bursts as messages or data associated with a data service that
4
consist of a small number of frames that are transmitted to a mobile with a dormant
5
packet data service instance. Short Data Bursts are not supported across packet zone
6
boundaries. Data may be lost if a mobile station moves to a new packet zone shortly after
7
transmitting a Short Data Burst (SDB). Mobile terminated data may also be lost if a
8
mobile moves to a new packet zone after a short data burst is sent to the BS/PCF from the
9
PDSN, but before it has been transmitted to the mobile. The BS shall ensure that multiple
10
mobile originated short data bursts from the same mobile shall be sent to the PCF in the
11
order in which they were received from the mobile.
12
See section 3.11.7 for call flows describing this feature.
13
2.11.8 Support for Common Channel Packet Data (CCPD)
14
The Common Channel Packet Data (CCPD) feature supports packet data call setup,
15
dormant mode handoffs, and data transmission using Short Data Bursts over Common
16
Channels. Short Data Bursts are specified in [33].
17
A CCPD Device is a data-only mobile that doesn’t support traffic channels. Any
18
signaling or data to be exchanged between a CCPD device and the network shall occur
19
over IS-2000 Common Channels. A CCPD capable mobile is a cdma2000 mobile that
20
supports CCPD Mode. A CCPD capable mobile may request CCPD Mode from the
21
network when the amount of data to be transmitted is expected to be small and
22
infrequent. The BS may deny CCPD Mode to a CCPD capable mobile.
23
A CCPD Device or a CCPD Capable mobile operating in CCPD Mode may be referred to
24
as a CCPD mobile. Messages and data exchanged between a CCPD mobile and the
25
network are sent over Common Channels encapsulated within Short Data Bursts. This
26
includes PPP Connection, Mobile IP Registration (if required), and Packet data. For
27
CCPD applications that do not require mobility (telemetry applications for example)
28
Mobile IP Registration is not required and Simple IP may be used. Messages and data
29
exchanged between the PCF and the BS shall be sent over the A9 signaling channel,
30
therefore an A8 bearer connection is not required. CCPD mobiles are authenticated via
31
the ADDS Transfer/ADDS Transfer Ack messages, therefore an SCCP connection is not
32
required to support a CCPD call.
33
A CCPD mobile originating a CCPD call setup or CCPD dormant mode handoff shall be
34
authenticated once by the network at the start of the procedure. A CCPD mobile shall not
35
be authenticated again upon subsequent Short Data Burst transmissions in support of the
36
CCPD call setup or CCPD dormant mode handoff procedure.
37
The BS may initiate CCPD Mode for a CCPD capable mobile, even though a CCPD
38
mobile may not have explicitly requested CCPD Mode from the network by setting the
39
SDB_DESIRED_ONLY bit to 1 in the Origination Message. The BS may use this
40
procedure for dormant mode handoffs for example. The BS responds to the Mobile’s
41
Origination Message with a Short Data Burst rather than assigning a traffic channel for
42
the call. Subsequent communication between the MS and the network occurs using Short
43
Data Bursts over Common Channels.
44
For call flows associated with this feature, see section 3.11.8.
1