Sie sind auf Seite 1von 33

EVDO RevA Subject_VT

Course Objectives
To learn about the basic situation of VT service
To get a good knowledge of EVDO RevA VT service networking
structure; as well as protocol structure of the media plane and
control plane.
To get a good knowledge of VT service registration, call
procedure analysis and some abnormal process.
To learn about VT service performance analysis and get a good
knowledge of definition and measurement standards of each
indicator.

Contents
1 EVDO RevA VT.........................................................................................................................................1
1.1 Introduction to VT Service..................................................................................................................1
1.2 VT Networking Structure....................................................................................................................4
1.2.1 VT The Control Plane and Media Plane of VT Architecture...................................................5
1.2.2 Development of VT SIP Architecture......................................................................................7
1.2.3 QoS Demands of VT................................................................................................................8
1.2.4 VT Terminal..............................................................................................................................9
1.3 VT Analysis of VT Registration Call Procedure...............................................................................10
1.3.1 VT Registration.......................................................................................................................10
1.3.2 Call Procedure of VT..............................................................................................................15
1.3.3 Abnormal Situations in VT Call.............................................................................................21
1.3.4 Summary of VT Call procedure.............................................................................................24
1.4 VT Performance Analysis..................................................................................................................25
1.4.1 Requirements of VT Performance..........................................................................................25
1.4.2 Analysis of Practical data for VT Performance......................................................................26

1 EVDO RevA VT
Knowledge point

Learn about the basic situation of VT service.

Get a good knowledge of EVDO RevA VT service networking structure, as well


as protocol structures of the media plane and control plane.

Get a good knowledge of VT service registration, call procedure analysis and


some abnormal processes.

Learn about VT service performance analysis and get a good knowledge of


definition and measurement standard of each indicator.

1.1 Introduction to VT Service


Video Telephony (VT) is a new multi-media function applied to mobile phone,
implementing bi-directional video call based on SIP protocol. It permits bi-directional
transmission of audio and video in packet exchange networks.

VT video call can be applied in many fields to enable us to add video element in many
applications on the basis of 2G, which brings us brand-new communication experience.

Based on the following analysis of video call market demands, we say that video call
2

Chapter 1 EVDO RevA VT

will win the favor and support of a great many users in 3G market.

VT technology has the following features:

Video codes:
MPEG-4 Simple Profile Level 0
H.263 Profile 0/3 Level 10
Under the pre-set condition, the terminal prefers MPEG-4 as video code.
However, if the opposite end supports only H.263 protocol, the terminal will use
H.263. The preset value can be modified by terminal manufactories based on
actual situations.

Audio codes:
AMR-NB
EVRC

Video size:
Video image size supports QCIF (176*144) in both directions.
Mobile vendors can modify their VT terminals into QVGA (320*240) display.

EVDO RevA Subject_VT

1.2 VT Networking Structure

SIP (Session Initiation Protocol) has been adopted as the control protocol of VT service
and written into IP multi-media protocol of 3GPP2. Thus the equipment supporting VT
service must support SIP protocol stack to implement SIP signaling exchange for multimedia session setup between endpoints. Besides SIP, VT equipment needs VT software
to implement coding, decoding as well as realtime transmittion and reception of voice
and video flows.
Besides supporting SIP equipment, the network needs to make some modification to
support SIP session and call. Although RAN and PDSN are not modified since SIP
does not exchange signaling between them, some new equipments are required, such as
SIP server and gateway.
The following figure shows the structure of a trial networking

Chapter 1 EVDO RevA VT

1.2.1 VT The Control Plane and Media Plane of VT Architecture


Besides the SIP based control plance, the VT architecture also contains a media plane
(RTP based on UDP) for media stream transport.

Contorl plane
VT control plane is mainly applied for creation and management of VT calls. It
uses SIP (Application Layer Control Protocol) to create, modify and terminate
the sessions at SIP endpoint. The endpoint carrying session description initiates
SIP requests, which permits the participater to negotiate about the consistent
data type. To transport the messages between SIP endpoints, an SIP server is
needed. To be simple, SIP is used to locate and connect endpoints of VT
sessions, and create consistent format for message exchange so as to guarantee
appropriate path information for VT sessions.
SIP registration server is the first SIP entity equipment to connect for
communication when VT application service is started. It is mainly applied to
receive registration requests sent by equipment and save received messages
(such as IP address, location and validity) in the local server of the database.
5

EVDO RevA Subject_VT

User location and validity messages are stored in the local server and accessed
by SIP proxy server.
SIP proxy server is an intermediate entity applied for routing. It guarantees that
SIP requests can be transmitted to other SIP entities for further processing of
these requests.
SIP redirection server, as how it is named, returns a redirection response after
receiving a retrial request. It provides users with the information of the next hop
or multiple Hops.
Media signaling gateway is used to convert SIP singling into SS7 singling.
Media gateway is used to adjust or convert other codes of media transport
protocol, foir example, convert EVRC in audio into AMR, or G.711, and
MPEG-4 in video into H.263.
VT networks should be able to provide the functions of the above four types of
SIP servers.

Media plane
Besides SIP-based control plane, VT architecture also contains a media plane
(UDP-based RTP), which is applied for transport of media.
Media plane is mainly used to transmit video flow and audio flow between VT
terminals. Since it is realtime communication, it runs over realtime RTP and user
data packet protocol (UDP). TRP provides a sequence number to check packet
loss and reorganization. RTP also has a time mark to synchronize audio flow and
video flow since they are transmitted via independent RTP session. UDP
6

Chapter 1 EVDO RevA VT

protocol instead of TCP is selected because it doesnt implement TCP slow start,
congestion control or retransmission packet error and provides better realtime
communication performance.

1.2.2 Development of VT SIP Architecture

SIP minimal configuration: with this configuration, VT call between different carriers
is feasible only when two terminals both use the same media format.

EVDO RevA Subject_VT

SIP configuration supporting internetwork call: with this configuration, call between
networoks with different protocols is supported. Terminal call of different media
formats is also supported.

AT 3GPP2 IMS architecture is specified as the IP core platform for future CDMA
network. A mian purpose to use IMS is to integrate compound data service into the
public core based on SIP signaling so as to meet multiple suppy demands of various
applications and the demands of core network elements.
The funcions of CSCFs are similar to those of SIP proxy server. MRFP mainly takes
charge of media format conversion of equipment. MFRC controls the connection from
MRFP interface to CSCF to determine conversion demands of media and MRFP
indicator.

1.2.3 QoS Demands of VT


Although VT application usually just needs 60kbps bandwidth or even less, which is
much less than other multi-media services, to achieve good user experience, VT service
8

Chapter 1 EVDO RevA VT

has higher requirement of delay and jitter. VT generates three kinds of RLP (Radio
Link Protocol) flow during the application process: audio flow, video flow and SIP
flow, which are used to carry audio signal, video signal and SIP signaling respectively.
Audio data packet has service constraint over delay (usually end-to-end delay should
be less than 300ms). Video data packet is also important but not so strict with the delay
(good performance with 500ms1s delay).
Though QoS features are extremely necessary for VT service, technically VT can be
applied over Rel.0 1XEV-DO which doesnt support QoS because Rel.0 1XEV-DO is
only an application using SIP and RTP to implement data packet session. But we have
to understand an important thing: Rel.0 1XEV-DO is only a BE system. Call quality
will drop with the increase of load. In the network with load, VT realtime data packets
will compete with data packets of other services such as e-mail, HTTP which have
flexible requirements of delay and jitter. Therefore, data packet priority feature is in
urgent need for VT call in 1XEV-DO network with load to keep high quality call.
Development stages of VT QoS:
Non-QoS 1xEV-DO Rel.0
It is recommended to be applied in trial network with empty load, which hasnt been
put into commercial use
Software QoS 1xEV-DO Rel.0
It is recommended to be applied in the network has low requirements on VT service. In
network environment with load, it cannot provide good call quality, but reduce the
impact on pure BE network.
Full 1xEV-DO Rev.A QoS
It is recommend to provide full VT service. The reverse capacity of Rev.A is obviously
increased. At the same time packet delay is reduced. Adopting new wireless QoS
standard, it can provide high quality and capacity solution.

1.2.4 VT Terminal
Qualcomm VT terminal has two kinds of chips based on MSM6550 and MSM6800
chips respectively. The terminal needs to be configured with regular DO mobile
parameter (such as PRL and data session passwords) before they are put into use. With
PRL and authentication information set, when it is power on, the terminal can lock up
signal; successfully implement Session negotiation and authentication access. But it
9

EVDO RevA Subject_VT

cannot automatically initiate VT service registration. To make the terminal


automatically initiate VT registration, QPST software is needed to implement a series
of file configuration and interface, parameter setting.

1.3 VT Analysis of VT Registration Call Procedure


1.3.1 VT Registration
Registration: Set up PPP connection. Set up video flow, audio flow and SIP flow. Then
open SIP flow. The mobile registers by exchange between SIP flow and SIP server.

Registration: Set up signaling procedure of video flow, audio flow and SIP flow.

10

Chapter 1 EVDO RevA VT

1.

Mobile implements bring up (which is also called register). Mobile begins


to take PPP negotiation with PDSN. After successful negotiation, PDSN store
the user on SubscriberQoSProfile of PDSN AAA and send it to PCF by
A11SessionUpdate messageSno215. SubscriberQoSProfile is crucial to the
setup of Reservation later since it has ProfileID list for the user. PCF send
SubscriberQoSProfile message to AN by A9UpdateA8 messageSno216.

2.

Then by GAUP message (Sno222) the mobile initiates setup of audio flow and
video flow (the setup request of video flow and audio flow is put in one GUAP
message and sent out, while the setup request of SIP flow is put into another
GUAP message and sent out). The message carries ProfileID corresponding to
audio flow and video flow. The value for ProfileID is configured in mobile file.
The ProfileID corresponding to audio flow is 257.
Receiving GAUP request from the mobile, AN will authenticate ProfileID in
GAUP based on ProfileID list in SubscriberQoSProfile. If the requesting
ProfileID is in the ProfileID list, it passes the authentication and AN sends
GAUP Accept (Sno223) to the mobile. Otherwise, AN sends GAUP Reject to
the mocile.

3.

Then AN select one ProfileID from a pile of them sent by the mobile as a
ProfileID currently adopted. It sends the corresponding QoSAttributeSetId to the
mobile by a GAUP request (Sno224). Since the QoSAttributeSetId is
encapsulated in ResQoSResponseRecord field of GAUP request, we usually call
11

EVDO RevA Subject_VT

this GAUP request message as GAUP Response.


Then we implement RLP and RTCMAC paramter negotiation. RLP parameter
and RTCMAC parameter are sent to the mobile by two different GAUP message
(Sno225 and Sno226). Receiving the messages, the mobile sends two GAUP
Accept (Sno227 and Sno228) as response respectively.
And A interface is updated. That is to say QoS status change at the empty
interface is notified to PDSN with the procedure as follows:
TP sends AvrSetupA8Sno230to SSAP,
BSSAP sends A9SetupA8Sno232to PCF,
PCF sends A11RegRequestSno233to PDSN
PDSN responds A11RegReplySno235to PCF,
PCF responds A9ConnectA8Sno236to BSSAP,
BSSAP responds AvrSetupA8AckSno237to TP.
By far video flow and audio flow setup is completed.
Teh setup procedure for SIP flow is the same with the above, so it will not be
repeated here.
When video flow, audio flow and SIP flwo setup are all completed, the mobile
opens SIP flow by ReservationOnRequest message (Sno253). AN takes the
following steps to open Reservation request:
1 Acceptance control
AN sends AbiscfUpdateReservation message (Sno257) to BTS, requesting
distribution of empty interface and Abis interface resource. BTS determines
whether to accept the request based on the current resource situation. As shown
in the following figure, it can be known whether the request is accepted based
on whether the Cause field is 0 in AbiscrUpdateReservationAck message
(Sno258) responds by BTS. 0 indicates the request is accepted. Non-zero
indicates the cause value for rejection. In the figure ReservationLabel 2 of both
obverse ane reverse are accepted.
2 Setting overload control paramter
This step is paramter invoking with no corresponding signaling.
12

Chapter 1 EVDO RevA VT

There are two purposes to set overload control paramter:


For QoS flow, we need to determine whether to permit openning of new QoS
flow based on current SDU resource utilization.
For BE flow, we need to implement flow adjustment. We set paratmer of
flow adjuster in this step.
3 Opening obverse logic flow for obverse Reservation.
AN sends AbistfOctetOrPacketBasedOpenFlow message (Sno259) to BTS,
requesting

to

open

obverse

logic

flow.

BTS

sends

AbistrOctetOrPacketBasedOpenFlowAck message (Sno260) as a response.


In which OpenFlowResult field indicates the processing result. 0 indicates
success and non-zero indicates the failure cause.
4 Updating A interface
This step is similar to A interface update at the moment of Reservation setup
except SetupA8 is UpdateA8 here.
When the above four steps are completed, AN sends ReservationAccept
message (Sno267) to the mobile, which means SIP flow is succesfully opened.
When SIP flow is successfully opened, SIP registration process is started.
The mobile sends registration message to SIP server via this flow. The first step
of VT call procedure is completed when response of successful SIP server
registration is received. That is to say, mobile registration is successful.

Packet Sniffing of Ethreal signaling


UE1 (terminal) sends Register message to the outbound proxy carrying IP
address of UE1. Receiving Register message, outbound proxy responds with 100
Trying to indicate that the message is received. Then it forward the Register
message to teh registrar to implement registration and authentication. It responds
with 200 OK when it completes this. In simple netwrok architecture, outbound
proxy and registrar could be one entity, for example, SIP Server or IMS.

13

EVDO RevA Subject_VT

14

Chapter 1 EVDO RevA VT

1.3.2 Call Procedure of VT


Originating a call: The caller opens video flow and audio flow; sends message to SIP
server via SIP flow; and requests to setup session with the called. The called also opens
video flow and audio flow when it receives message from SIP server.

Originating a call: the basic procedure of VT call

15

EVDO RevA Subject_VT

The

caller

requests

to

open

video

flow

and

video

flow

by

sending

ReservationOnRequest message (Sno301, Sno302). The processing procedure of the


message of the site has been described in above registration so it will not be
discussed any more here. After the processing is done, the site sends
ReservationAccept message (Sno332, Sno333) to the mobile.
The caller starts SIP signaling exchange with SIP server when it successfully opens
video flow and audio flow. The exchange procedure is shown in the following figure:

16

Chapter 1 EVDO RevA VT

1.

UE1 (the caller) dials the number of the called. Pressing the call button, the
caller starts to setup empty interface connection and activate Reservation of
audio and video. It sends INTITE message containing information of SDP audio
and video coding/decoding type and bandwidth.

2.

Outbound proxy responds with 100 trying when it receives INVITE message to
indicate the message is received. It also forwards INIVTE message to UE2 (the
called).

3.

Receiving INVITE message, UE2 (the called) activates reserved QoS resource
17

EVDO RevA Subject_VT

for the audio flow and video flow of media coder/decoder it supports.
Completed resource reservatoin, UE2 sends 180 Ringing message, which
contains audio and video coding/decoding type and bandwidth that UE2
supports and uses.

4.

Outbound proxy forwards 180 Ringing of UE2 (the called) to UE1 (the caller).
At this time UE1 (the caller) can hearthe ring back tone. If in step 1 the INVITE
message coarries Supported head domain contaning 100rel label, and in step c
the 180 Ringing message carries Require head domain containing 100rel label,
UE1 (the caller) will send a PRACK message to respond to 180 Ringing.

5.

Outbound proxy forwards PRACK message to UE2 (the called), who match
PRACK with 180 Ringing. If they can be well matched, UE2 plays the ring,
telling the user there is a call coming in; and responds with 200 OK message.

6. Outbound proxy forwards 200 OK message to UE1 (the caller).

18

Chapter 1 EVDO RevA VT

7.

UE2 (the called) user hears the ring. UE2 (the called) sends 200 OK message
when it answers the call. At this time UE2 sets up coder/decoder and starts to
deliver media flow data.

8.

Outbound proxy forwards 200 OK message to UE1 (the caller). At this time
UE1 (the caller) sets up coder/decoder, and starts to deliver media flow data and
responds with ACK message to indicate the whole call setup is accomplished.
19

EVDO RevA Subject_VT

The picture sniffed of multi-flow rate when video call is set up (sniffed by Qualcomm
QXDM).

Multi-flow rate in RLP layer of VT in call

20

Chapter 1 EVDO RevA VT

Physical layer rate of VT in call

1.3.3 Abnormal Situations in VT Call


Abnormal situations in VT call procedure can be divided into empty interface
abnormality and SIP abnormality based on the layer of signaling exchange. The
following are abnormalities we usually meet.
Empty interface abnormality:
The empty interface procedure involved in VT call is setup and opening of audio flow,
video flow and SIP flow.
Flow setup failure
There are two situations for flow setup failure. One is the site responds the mobile with
GAUP Reject message. The other is the site initiates SessionClose.
GAUP Reject symptom: AN sending GAUP Reject when it receives GAUP request
from mobile means flow flow setup fails.
Method to locate: Profile authentication failure. When Profile corresponding to
Reservation that the mobile request to set up can meet the following two conditions at
the same time, the authencitaion is successful. The authenctication fails when any one
of them is not satisfied.
(1) The requested Profile is configured in PDSN AAA.
(2) The requested Profile is condifured in StdProfile of AN OMC.
Measure: check which Profile doesnt meet the above conditions based on the above
21

EVDO RevA Subject_VT

method, and then configure them well.


SessionClose
Symptom: most SessionClose occurs at the moment when A interface connection is set
up, and the subsidiary connection is rejected.
Version Measure: this is caused by low version of IOS configured in AN OMC. IOS
versoin should be configured as IOS5.
We have described the procedure to open Reservation in above normal call procedure:
1 Acceptance control
2 Setting overload control paramter
3 Opening obverse logic flow for obverse Reservation
4 Updating A interface
Flow openning will fails if one of the above steps fails.
Generally speaking, step 2 and 4 wont fail (by far failure at these two steps has turned
out to be code BUG which cannot be avoided by configuration modification). So we
focus on step 1 and 3.
Acceptance control failure:
Symptom: If BTS carries non-zero Cause field in AbiscrUpdateReservationAck
message that it responds when AN sends AbiscfUpdateReservation message to it,
acceptance control fails.
Method to locate: Cause field indicates failure cause. The most common failure cause
is Cause = , which indicates inadequate resource,
Measure: to solve inadequate resource, we can configure a smaller rate corresponding
to the profile (the Profile orresponding to the Reservation causes acceptance control
failure) in background StdProfile parameter table. Physical layer rate (bps) in the
following figure is just the rate we are talking about.
Obverse logic flow openning failure
Symptom:

If

BTS

carries

non-zero

OpenFlowResult

field

in

AbistrOctetOrPacketBasedOpenFlowAck message that it responds when AN sends


AbistfOctetOrPacketBasedOpenFlow message to it, openning of logic flow fails.
Method to locate: OpenFlowResult field indicates failure cause. The most common
22

Chapter 1 EVDO RevA VT

failure cause is OpenFlowResult = , which indicates RLP ID check fails.


Measure: to solve RLP ID check failure, configure RLP ID Length field corresponding
to each QoSClass paramter based on the following table.

SIP abnormality:
The SIP abnormalities occur in current test are as follows:
1.

The mobile doesnt set up connection or doesnt initiate SIP registration


procedure when it is power on. This may caused by incorrect configuration of
terminal VT configuration file and QXDM setting items. We should take correct
configuration based on EV-DO Rev.A Wireless Network-based VT Service
Debugging Scheme by Zhang Jian.

2.

The mobile fails to initiate SIP registration when it is power on. Sniff packets on
SIP Server by sinshark. Find the received Register message from AT and 100
Trying responded by SIP Server. But 200 OK is not responded. Problems
concerned about SIP should be found out.

3.

Two VT terminals dial to each other. The called responds with 488 (Not
Acceptable Here) when it receives INVITE. VT configuration file of the caller
and the called should be checked. And the consistency of configuration of audio
and video should be checked.

Abnormality in VT data transmission:


Part of the problems occured before in VT data transmission are imported by code.
They have already been modified or avoided. So here we only discuss basic data
23

EVDO RevA Subject_VT

analysis and collection when audio/video quality problem arise in data transmission.
Whether the audio and video flow are delivered by the major connection can be
determined directly by QXDM Log message at AT side. Check HDR MultiFlow RLP
Forward Statistics/HDR MultiFlow RLP Reverse Statistics and HDR MultiFlow RLP
Forward Throughput/HDR MultiFlow RLP Reverse Throughput we can see how each
flow works. In audio and video transmission process, if there is only one flow exists in
the above statistics and graph, audio and video are not in the right status. We need to
analyze signaling to find out the reason.
We need to collect PPP information of the caller, the called and the site side, as well as
the log information related to RTP. Compare the detailed analysis of delay, packet loss
and packet check.

1.3.4 Summary of VT Call procedure


In the DO RevA wireless network-based VT service, three types of QoS flows are
involved: SIP flow, Audio flow and Video flow. SIP signaling flow works to implement
VT service registration, VT service call and release. Audio flow works to transmit voice
flow. And Video flow works to transmit video flow.
The ProfileID for SIP signaling flwo, Audio flow and Video flow are 1280, 257, and
773 respectively.
Current implementation procedure for DO A wireless network-based VT service is as
follows:
The legal terminal powers on and successfully launches UATI (Unicast AT Identifier)
request to AN;
The terminal holds Session negotiation with AN, and completes configuration of each
protocol parameter at the empty interface.
The terminal takes access authentication by AN AAA, and successfully obtains
ProfileID from PDSN AAA.
The terminal passes authentication, and immediately and automatically implements VT
service registration. It in advance configures MFPA and RTCMAC parameters relevant
to SIP signaling flow, audio flow and video flow needed by VT service. And it opens
SIP signaling flow and successfully registers user information into VT Ser.
User dials the number of the other party (registered user) by the terminal and has a
24

Chapter 1 EVDO RevA VT

successful VT service call.

1.4 VT Performance Analysis


1.4.1 Requirements of VT Performance
Delay requirement:
Generally speaking, the voice quality acceptable for users requires a delay not more
than 300ms. As for video in VT application, although it is also realtime communication,
it has better flexibility on delay. Compared with voice, video delay is not that easy for
user to perceive. For rmost users, 500ms to 1s video packet delay is still acceptable. In
other words, to achieve good VT user experience, voice should be offered higher
quality to keep the smaller delay for voice in the call.
De-jitter buffer
De-jitter buffer works to store the received media data. It enables the received TRP
packets with different delay can export smooth audio or video. Larger buffer can solve
more jitter but brings about larger end-to-end delay.
Audio: de-jitter buffer is usually 300ms for Release 0 configuration. Self-adaptive dejitter jitter buffer also can be configured since it may influence end-to-end delay.
As for Revision A configuration, self-adaptive de-jitter buffer configuration is adopted.
Video: de-jitter buffer is usually 300ms for Release 0 configuration. Self-adaptive dejitter jitter buffer also can be configured since it may influence end-to-end delay.
The buffer for Revision A configuration is usually 180ms. Self-adaptive de-jitter buffer
configuration is also recommended.
Audio and video replay time difference for de-jitter buffer should be not more than
300ms.
A/V Sync
Audio packet and video packet use different IP packet to transmit in the network,
possibly via differnt network paths. We have to find out a solution to make sure that the
audio and video data generated at the sending side are replayed at the same time.
Qualcomm mobile uses time mark provided by RTP to synchronize audio flow and
video flow.
25

EVDO RevA Subject_VT

Source description packet (RTCP SDES) of RTCP (Realtime Transmission Control


Protocol) contains RTP time mark and wall clock. In the video and audio report at the
sending end, wall clcok is consistent. The receiving end can synchronize audio adn
video based on RTCP reoprt of the sending end.
Packet error ratio of audio and video:
Check packet loss and packet sequence based on sequence number of the packets.

1.4.2 Analysis of Practical data for VT Performance

26

Chapter 1 EVDO RevA VT

27

EVDO RevA Subject_VT

28

Chapter 1 EVDO RevA VT

29

EVDO RevA Subject_VT

Throughput per user at RLP layer of VT:

30

Chapter 1 EVDO RevA VT

31

Das könnte Ihnen auch gefallen