Beruflich Dokumente
Kultur Dokumente
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
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
will win the favor and support of a great many users in 3G market.
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.
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
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
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
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.
SIP minimal configuration: with this configuration, VT call between different carriers
is feasible only when two terminals both use the same media format.
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.
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
Registration: Set up signaling procedure of video flow, audio flow and SIP flow.
10
1.
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
to
open
obverse
logic
flow.
BTS
sends
13
14
15
The
caller
requests
to
open
video
flow
and
video
flow
by
sending
16
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
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.
18
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
The picture sniffed of multi-flow rate when video call is set up (sniffed by Qualcomm
QXDM).
20
If
BTS
carries
non-zero
OpenFlowResult
field
in
SIP abnormality:
The SIP abnormalities occur in current test are as follows:
1.
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.
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.
26
27
28
29
30
31