EVDOConnectioDrops_CallProcessing

© 2006 Sprint Nextel. All rights reserved.

EVDO Connection Drops Analysis (Part I)

Muenge LounduSan Diego RF EngineeringEVDO POC

Objectives

2 © 2006 Sprint Nextel. All rights reserved.

• Describe Connection Drop Scenarios

• Identify Connection Drop Signatures through log file analysis

• Develop a methodology to identify Connection Drops through log file analysis


Basic Call Setup Flow – Connection Request

AT

Page

BTS RNC (OHM/SFM)

Figure 1. Normal Setup Response to Page

Send Page

Route Update & Connection Request (UATI)

ACK Allocate Traffic ChannelReq

TCA

Send DRC + Pilot and ramp up RTC

RTCAck

Traffic Channel Complete

Ack

Allocate Traffic ChannelResp

DRC Cover Ind

Send TCATraffic Channel Assignment

Mobile Acquire Ind

Send RTC Ack

TCC

Configuration Negotiation procedures


Configuration Negotiation Procedures

AT RNC (OHM/SFM)

ConfigurationComplete

ConfigurationRequests/Responses

ConfigurationComplete

ConfigurationRequests/Responses

SoftConfigurationComplete PersonalityIndexStore=‘0’ (main),

Continue = ‘1’

ConfigurationRequest

ConfigurationResponse

Figure 2. Session Configuration Negotiation

Personality 0 Negotiation


A12 Ran Authentication and Session Setup

AT

Configuration Negotiation

RNC AAA

Figure 3. Successful RAN Authentication (A12 Access Accept)

RAN-PPP Negotiation (LCP)

CHAP Challenge

A12 Access Request

CHAP Success

AT initiates with XON Request

CHAP Response

A12 Access Accept

RAN-PPP Termination (LCP)

RAN Authentication is completed

PDSN

PDSN-PPP Setup (A11/A10)

XonRequest

XonResponse

EVDO Connection Drop/Close Types


Connection Drops occur at:

• Air Link

• Between the AT and the EVDO RNC

• PPP Level

• Between the AT and the PDSN

• Mobile IP Level

• Between the Mobile IP client, Foreign Agent and Home Agent


EVDO Air Link Connection Close Scenarios

An Air Link connection drop is typically independent of PPP, Mobile IP, and Session states.

The Air Link may be closed due to normal scenarios, or it may be closed due to weak RF conditions. Normal scenarios are the followings:

• At the end of Session Configuration

• AN wants to change the AT Personality

• RLP Inactivity Timer Expires

• User desired

The AT and the AN may give up on a connection when the AT cannot hear the AN reliably, or the AN cannot hear the AT reliably. When the AT cannot hear the AN, this is due to a weak Forward Link. When the AN cannot hear the AT, it is due to a weak Reverse Link.


The AT and the AN may give up on a connection when the AT cannot hear the AN reliably, or the AN cannot hear the AT reliably.

When the AT cannot hear the AN, this is due to a weak Forward Link.

• Control Channel Supervision Failures

• DRC Supervision Failures

• Hand down to 1xRTT (3G1x)

When the AN cannot hear the AT, it is due to a weak Reverse Link.

• Indicated by Forward Traffic Valid Bit

EVDO Air Link Connection Close Scenarios


Connection Close – Session Configuration

Configuration Negotiation is the process of the AT and the AN negotiating a set of EVDO Protocols, Protocol Subtypes, and Attribute values.

In Release 0, after the AT receives the ConfigurationComplete message from the AN, it sends a ConnectionClose to cause the newly negotiated set of Protocols, Subtypes and Attribute values to go into effect.

In Rev A, the AT after the AT receives the ConnectionClose after it receives a SoftConfigurationComplete message with Continue=0 to cause the newly negotiated set of Protocols, Subtypes and Attribute values to go into effect.


Connection Close – Session Configuration


Connection Close – Personality Switch

The AN will send the AttributeUpdateRequest message with the SessionConfigurationToken indicating the Personality that the AN wants the AT to switch to. The Personality will not go into effect until the connection closes.

In the next example, while the AT is in traffic, the AN sends the AttributeUpdateRequest with the SessionConfigurationToken and then sends ConnectionClose and TrafficChannelAssignment at the same time. The AT responds to the ConnectionClose and then starts transmitting Pilot+DRC using the new Personality. The AN responds with RTCAck indicating that it can hear the AT and the Connection is setup.


Connection Close – Personality Switch


Connection Close – RLP Inactivity

The RAN monitor the activity on the AT forward and Reverse Traffic Channels to determine whether the AT is in dormant mode. This timer is reset whenever there is data movement at the RLP Layer between the AN and the AT. If there is inactivity for a period defined by the dormancy timer, a ConnectionClose message is sent and the AT is released of its assigned traffic channel and enters the dormant mode.

The entity with the smaller timer value will initiate the ConnectionClose.

While in dormant mode, the AT can only monitor the Control Channel during its wake-up cycle. During this mode, the AT monitors Page messages and will respond to KeepAliveRequest messages over the Access Channel. The AT transitions back to the active state when the user has a message to send, or when the AT is responding to Page message.


Connection Close – RLP Inactivity


Control Channel Supervision

When a Connection is active, the AT monitors both broadcast and AT-directed (unicast) messages transmitted over the Forward Control Channel on the selected EVDO Channel listed in the SectorParameters message.

The Control Channel, which is interlaced with the transmission of traffic data, is transmitted every 426.66 ms for a 13.33 ms duration.

There are twelve Control Channel cycles within 5.12 seconds. On the occurrence of every twelfth control channel cycle (time slot) which occurs every 5.12 seconds, the AT transitions from the Sleep Sub-State to the Monitor Sub-State for the 13.33 ms control channel cycle time slot to exchange synchronous capsules with the AN. To prevent loss of this exchange, the AT cannot change its Active Set Pilot at a time that causes it to miss a synchronous Control Channel capsule. There are 12 Control Channel cycles within 5.12 seconds.

If the AT does not receive a Synchronous Control Channel capsule for 12 Control Channel cycles (5.12 seconds), the Control Channel Supervision fails and the AT tears down the connection. The AT does not send a ConnectionClose message in this case.

The AT will enter the Network System Determination with a System Loss indication after a Control Channel Supervision failure.


Control Channel

Traffic Channel

5.12 seconds

426.66 ms13.33 ms

Figure 4. Sleep Mode Slotted Control Cycle

The QuickConfig message is one of the messages broadcast by on the Forward Control Channel to indicate a change in the overhead messages contents and to provide frequently changing information.

It informs the AT about certain important parameters, such as Color Code, and indication that the Forward Traffic Channel for a particular MAC index is valid.

It appears more often than any other overhead message (that is why it is called quick!) and designed to assist AT that is waking up from “sleep” mode to process system overhead messages or for handoff processing. The QuickConfig message is sent in every Control Channel Cycle (every 256 slots or 426 ms).

Control Channel Supervision


Weak Forward LinkControl Channel Supervision Failure

In the next example, the EVDO Connection Release is generated on the AT when the Connection Release is logged.

This is typically due to low SINR in the Forward Link caused by:

• Pilot pollution

• low signal power in the Forward Link

Only the radio resources would be released. The PPP and the Session would not be torn down.


Weak Forward LinkControl Channel Supervision Failure

AT monitors the Control

Channel continuously. Synchronous

capsules occur every 256 slots or 426.66 ms

No Control Channel

messaged received for

5.12 seconds.


Weak Forward LinkDRC Supervision Failure

If the AT is on the EVDO Traffic Channel, it may send a NULL DRC to indicate that it does not want to receive any data from the network while it is monitoring 3G1x Paging Channel.

The DRC Supervision timer is activated when the AT transmits a NULL Rate DRC. The AT shall the DRC Supervision timer for TFTCMDRCSupervision (240 ms) when it transmits a NULL Rate DRC.

If the AT requests a non-null rate while the DRC supervision timer is active, it shall disable the timer.

If the DRC Supervision timer expires, the AT shall disable the Reverse Traffic Channel transmitter and set the Reverse Traffic Channel Restart timer for time TFTCMPRestartTx (5.12 secs).

If the AT generates consecutive non-null DRC values for more than NFTCMPRestartTx (16) slots, the AT shall disable the Reverse Traffic Channel Restart timer and shall enable the Reverse Traffic Channel Transmitter.

If the Reverse Traffic Channel Restart timer expires, the AT shall return a SupervisionFailed indication and transition to Inactive State.





From the picture:

• The AT transmits a NULL DRC at 15:23:48.2 and enables the DRC Supervision timer.

• The AT is unable to request a NON-NULL DRC during the supervision period.

• The AT disables the RTC Transmitter at 15:23:48.4.

• The AT is unable to request consecutive NON-NULL DRC for 16 slots.

• The AT drops the connection at 15:23:53.6 (5.12 seconds after disabling the RTC Transmitter).

In this example, DRC Supervision disadvantaged the user because PN 33 and PN 36 Pilot strengths rose above PilotAdd while the AT’s RTC Transmitter was turned off.


Weak Reverse LinkForward Traffic Valid Bit

Message ID: 1Time: 06/21/07 08:11:51.257Latitude: 32.946345 Longitude: -117.212094Channel: Control broadcastMessage: Quick configurationACK_SEQ: 255MSG_SEQ: 255ACK_REQ: -Band: 1Channel number: 50Pilot PN: 474Sync CC flag: 1 <Message was received on synchronous control channel capsule> Layer: ConnectionProtocol: Overhead MessagesSubtype: Overhead MessagesMessage: Quick configuration Color code: 78Sector ID24: 6147Sector signature: 2Access signature: 1Redirect: 0RPC count 63 to 0: 2Forward traffic channel valid: MAC index: 63 62 FTC valid: 1 1RPC count 127 to 64 included: 1RPC count 127 to 64: 2Forward traffic channel valid: MAC index: 127 126 FTC valid: 1 1


In the TrafficChannelAssignment message, the AT receives:

• MAC Index for each sector in the Active Set.

• The relationship (soft or softer) of the sector to each other.

The QuickConfiguration message conveys the status of the Forward Traffic Channel. Using the Forward Traffic Valid Bit:

• 1 means the connection is valid.

• 0 means the connection is not valid.

•If FTCValid is set to zero on that Control Channel, the AT must change Air Link state from Connected to Idle.

Weak Reverse LinkForward Traffic Valid Bit


Weak Reverse LinkIdentifying Forward Traffic Valid = 0


Weak Reverse LinkIdentifying Forward Traffic Valid = 0

Identifying Forward Traffic Valid = 0 involves looking at different parts of the AT log file.

First you need to identify when the AT’s air link state changes from Connected to Idle. In this example, the Connection Release Packet was logged on the AT.

After identifying that the AT’s air link connection changed from the Connected to the Idle state:

• Review back in time to the last TrafficChannel Assignment message that the AT received.

• Note the MAC Indexes for all the Pilots in the Active Set.

• Find the last QuickConfig message the AT received before the Connection was released.

• Determine if the FTValid Bit for the MAC Index on that sector is set to 0.


Connection DropHybrid AT Hand Down to 1x3G

When the hybrid AT is in the Connected state and detects a prolonged weak EVDO signal, it will hand down to 1x3G.

Hand down means that the AT will send a ConnectionClose (Best Effort) to EVDO system, and initiate a Service Option 33 call on 1x3G network.


Connection CloseDebugging Methodology

• ConnectionClose message sent:

• At the end of Session Configuration

• AN wants to change the AT’s Personality

• RLP Inactivity Time expires

• User desired

• No ConnectionClose message sent:

• Weak Forward Link

• Control Channel Supervision Failures

• DRC Supervision Failures

• Hand down to 1x3G – connection close BE

• Weak Reverse Link

• Indicated by Forward Traffic Valid Bit


THANK YOU!

Documents

EVDOConnectioDrops_CallProcessing