HT72-DB413-1 Ver. 1.1 QC01e M2 System Overview StudentGuide

Introduction to QChat
System Overview
Qualcomm Confidential and Proprietary.

QualcommConfidentialandProprietary
MaycontainU.S.andinternationalexportcontrolledinformation
In module one, we looked at the QChat system and how it is used. In module two, we
examine how the system works the end-to-end system components, their relationships,
and the protocols that support them.
QChat is a Voice-over-IP (VoIP) application that operates over a standard air interface and
packet data network infrastructure. The QChat System includes the following:
Radio Network
High-bandwidth, low-latency data network
QChat Application Servers (QAS)
QChat Client software loaded on handsets
Third-party components and software
To support successful integration of all these systems, QChat provides a series of Preferred
Vendor Requirements, (PVRs). These guidelines for vendors of the third party components
give the recipe for maximum system performance, scalability, and reliability.
The QChat Ecosystem includes QChat handsets, QChat application server (QAS)
components, and other components that must be integrated for full-featured operation.
Operator Wide Area Network

Comprises existing components in the Operator network, as well as QChat recommended
components.
QChat Core Network
Comprises the database and the QChat component that stores the location of every
subscriber in the QChat system.
QChat Regional Network
Comprises multiple servers within each QChat component, as well as multiple DNS and
SIP Registration Manager Servers.
Packet Core Network
Comprises standard components used to provide mobile data functionality
Radio Network
Base stations and controllers provide standards based RF interface
Radio network integration is very important and ensures proper standards/options are
supported, configured, and optimized to achieve the best-in-class PTT performance for
QChat.
Qualcomm provides a requirements document and support for vendors to design, develop,
and integrate the radio network.
Operator Wide Area Network

Comprises existing components in the Operator network, as well as QChat recommended
components such as the presence and voicemail servers.
QChat Core Network
Comprises the database and the QChat component that stores the location of every
subscriber in the QChat system. Multiple servers are configured to support each
components
p
function.
QChat Regional Network
Comprises multiple servers within each QChat component, as well as multiple DNS and
SIP Registration Manager Servers. Depending on the servers functionality, Qualcomm
recommends a configuration such as round-robin for load balance.
10
Platform Independent Architecture:

Best performance, enables uniform and integrated user experience
Consistent operation across all platforms and shorter time-to-market (TTM)
QChat client is portable across multiple platforms from feature phones to smart
phones
Supports native OS as well as high-level OS like Android
Platform specific adaptation layers offer seamless integration with OEM
applications such as the UI, address book, etc.
Comprehensive set of interfaces that facilitate carrier/OEM specific customizations to tones,
persistent storage, and concurrency management
Dynamically adapts to the capabilities of available serving system
11
Push to Talk (PTT) Software

A fundamental component of the QChat PTT System
PTT handset software
Set of libraries that implement QChat functionality,
functionality residing in the AMSS
Manages communication between the QChat handset and the QChat server
The hub around which all QChat activity takes place
Receives PTT key events
Communicates with a PTT UI application and facilitates PTT calls
Manages
M
registration
i t ti and
d understands
d t d th
the network
t
k state
t t
12
QChat-Aware Companion Applications can be developed by the OEM or a third

party
The UI application is the User Interface for all of QChat activities
The provisioning application is responsible for provisioning user and system data
The OEM reference customization app provides persistent storage and supports
tone customization
Application Adaptation Layer supports Android (QAAL) or Brew MP (QBAL)
Universal Porting Kit (UPK) provides QChat air interface optimizations and a
reference PTT handler
OEM Concurrency Management provides necessary customizations to the OEM
layer that might be required for QChat functionality. Such customizations are
implemented by the OEM.
13
14
The central, or core, deployment of the QChat System components consists of a Home
Dispatcher (HD), a Core Lawful Intercept Server (CLIS), and the User/Group DFE. These
components are centrally located in the carriers network and are accessible by all of the
regional deployments. The central components aid in the location of roaming users and the
initiation of inter-regional and inter-carrier QChat calls.
The regional deployment of the QChat System components consists of one or more
Regional Dispatchers (RD)
(RD), a Media Control Unit Complex (MCC)
(MCC), a regional LIS
LIS, one or
more RULSs, and optionally a Regional Presence Distributor (RPD), and a Regional
Gateway. Each regional deployment of the QChat System components requires a carrierprovided DNS server to support QChat Services.
Some of the components necessary for QChat operation are not provided by Qualcomm,
such as a Presence Server
Server, Carrier Database
Database, and Authentication Server (AAA)
(AAA).
15
16
17
The illustration provides a sample message flow, involving six components of the QAS. The
sample call is an inter-regional direct (1:1) call. The dotted lines represent events that occur
independent of user registrations and calls. The solid lines represent the message flow
for using QChat. The message flow begins in the upper left corner with the originator (Joe)
powering on the phone.
In subsequent pages we will examine the role of each component in the message flow
process. This
Thi illustration
ill t ti shows
h
th
the overallll process. W
We will
ill b
break
k it d
down step-by-step
t b t and
d
examine what each component is doing and how the components interact with each other.
18
The Regional Location Server (RLS) registers and authenticates QChat users. The users
device needs to be registered to receive and/or make QChat calls. When a user powers on
the phone:
The QChat Client interacts with the DNS to gather IP address information
A SIP REGISTER message is sent to the RLS, which is a Session Initiation
g
server. A SIP registration
g
server p
processes and
Protocol ((SIP)) registration
maintains registrations. Registration binds the QChat user address to its IP
address
The user is then ready to begin initiating or receiving a QChat call
The RLS propagates the users information to the Regional Dispatcher (RD),
which we will consider next.
Note: Additional steps for authenticating the user and handset are covered later.
19
20
The Regional Location Server communicates with the Regional Dispatcher (RD), the next
component examined.
The RD handles call setup requests in a given region. The RD maintains active user
records including location (IP address), groups, and call state. The RD is also directly
responsible for the allocation of the Media Control Complex (MCC) to handle the voice data
traffic for calls.
21
The call flow diagram adds the Regional Dispatcher (RD) to the message flow.
The diagram shows two independent processes:

The solid lines show the client registration process we discussed earlier and
which is discrete for each QChat registration
The dotted lines represent the RD subscription to the RLS, which is a process that
occurs p
periodically
y and is independent
p
of the call registration
g
p
process. Upon
p
power up, and then again at regular intervals, the RD subscribes itself to the local
RLS by sending a SIP SUBSCRIBE message to the RLS.
22
Two messages that use SIP are SUBSCRIBE and NOTIFY:

The SIP SUBSCRIBE message is used to sign-up or subscribe QChat for SIP
registration services. Mobile devices register with QChat by first contacting the
RLS. However, the RLS must already know of the existence of the QChat system,
specifically the RD, before the user can access QChat services.
The SIP NOTIFY message is sent by the RLS to the RD, specifying the state of
the subscription -- active, pending, or terminated. It is also sent anytime a user
registers or when the RD-to-RLS subscription information needs to be updated.
23
The DFE is QChats interface into the service providers central provisioning database. It
provides an interface for the other components to retrieve centrally stored information about
users and predefined groups. The key fields stored are user address, call restrictions,
preemption rank, and group definitions and memberships. For QChat 4.x, this information
can be accessed by a standard ODBC or XDMS interface.
If XDMS is used for the interface, the RD handles retrieval of group information without DFE
involvement. The specific interface used is configurable at the DFE.
The RD contacts the DFE as part of the authentication process, obtaining all of a users key
security details. The RD may also contact the DFE regularly and download the DFEs
regional group definitions, including user names. This use of the DFE for obtaining group
information assumes an ODBC interface. If an XDMS interface is used, the RD retrieves the
group definitions directly from the User/Group database.
24
25
25
The Home Dispatcher (HD) stores location information about every active user in the
carriers QChat system. In this way, the system allows users to roam from region to region
while maintaining QChat service.
26
The illustration shows the Home Dispatcher (HD) added to the message flow.
The HD maintains data of all users registered in a carriers network. The HD converts user
URIs into a current IP address. When the RD receives a new registration for a QChat user,
it relays that information to the HD. When the RD knows the users full information, it sends
an INFO message to the originating user, informing that QChat services are available.
The call registration process is now complete and a call can begin.
27
28
Lets take a moment to revisit our original call flow diagram. So far, we have looked in detail
at the registration part of the call. Next well look at the call itself, the components involved,
and the message flow.
29
After the INFO message has been sent, we move from the Registration process to the Call
process. A Push-To-Talk call may now be placed. Recall that our example is for a direct
call that goes across regions.
In this example:
1. The originator places a call to jack@ourdomain. Jack is in the same domain as Joe
the originator.
2. This request
q
is sent to the Regional
g
Dispatcher.
p
Remember the jjob of the regional
g
dispatcher is call setup.
3. The Regional Dispatcher then acknowledges and processes this request.
4. If the Regional Dispatcher does not recognize a member, or if the target member is from
a different region, (as shown by the regional boundary dotted line in the illustration) it
will ask the Home Dispatcher to locate the member. In the fact the RD recognizes that
while Joe is in the region Jack is not, so the RD queries the HD for Jacks location.
5. Once the Regional Dispatcher knows all of the members, it sends an announcement to
the targets.
6. When the incoming call announcement is acknowledged by the targets, the RD sends a
status message to the originator that the call is about to begin, and the user hears a
tone to indicate they may begin speaking.
30
The MCC is the media controller of the QChat system. This component takes direction from
the RD. The MCC allows the QChat system to:
Send information from a single originator to multiple targets
Determine who has floor control
Log all calls for billing purposes
31
The illustration is a continuation of the previous illustration. Once the RD sends the
STATUS message to the originator, the call can begin. All voice data passes through a
Media Control Unit Complex. The RD chooses which MCC will handle the call. The MCC
then sends a CONTACT message to both the Originator and the Target. This message
contains all of the relevant information to allow the handsets to speak directly to the MCC.
When the Originator and the Target have acknowledged this information, the pipe is set
up for media. Now Real Time Protocol (RTP) messages containing voice data are sent from
the originator to the MCC, which relays those packets to the intended target(s).
32
32
The Regional Usage Log Server (RULS) logs call activity on the QChat system in
preparation for export to the carriers billing system. The RULS is a Regional QChat
component.
The Regional Usage Log Server (RULS) collects usage events from the local MCC and RD
for a given region. It formats and stores these events in Usage Data Record (UDR) files,
which can be imported into the carriers billing system. UDRs can be output as binary or
plain text files.
plain-text
files Every region has its own RULS
RULS, and RULSs do not interconnect
interconnect. We cover
the fields contained in an UDR in another course.
33
The MCC and the RD keep track of calls by saving Usage Data Events (UDE). The RD
keeps track of call setup attempts, and the MCC logs all in-call details. These records are
received by the RULS and converted into Usage Data Records (UDRs), which can be used
by the Carriers billing system.
This is the end of the message flow for the sample call.
34
This plain English version of the message flow shows the major events in a direct call,
from QChats discovery of the RLS to the initiation of voice Real-Time Transport Protocol
(RTP) traffic by the MCC. This diagram includes all the components we have examined so
far.
35
This message flow shows the messages and protocols used to initiate a QChat call. Lets walk
through it again
again, step
step-by-step.
by step
We are assuming that Joe has just powered on his phone or crossed a regional boundary so he has
to register. Hes asking where am I? Whats not shown here is the phone querying the DNS, and
the DNS has indicated by IP address where the RLS and the RD are.
Now the originator sends his message to the RLS, I want to register on your network. The RLS
sends a SIP NOTIFY message saying Hey, RD, Joe is in our network. The RD acknowledges, and
then queries the DFE Hey
Hey, are we going to let Joe have QChat service in our network?
network? The DFE
answers back Oh, we know him, and hes paid his bill. The RD lets the HD know, Hey, Joe is in my
region. The HD acknowledges that, and then we let Joe know, Okay, you are registered. What that
looks like depends on the service provider. For example, a message may appear on the mobile
device indicating that registration is successful.
Now, Joe wants to make a call. He wants to call Jack in another region. He sends a call setup
request to the regional dispatcher. The RD recognizes Joe but not Jack, so it queries the HD. The
HD replies, Oh,
O thats
Jack at this IP address. The RD sends a message to the target to indicate a
call coming in. The target acknowledges. The RD lets the originator know, Okay, we have queried
that phone, you can start talking.
In the meantime, the RD is setting up the media path by telling the MCC, Please take care of the
media for this call. The MCC acknowledges. At this point, the RD actually logs a call attempt to the
RULS, and the RD is done. The MCC then sends contact messages to all members of the call,
saying, II will handle this media for you.
you. As those targets acknowledge, the MCC sets up the pipe to
carry the voice data between Joe and Jack.
36
The Regional Gateway (RG) supports inter-carrier calls between users on different QChat
carrier networks. The RG is an optional component.
37
The Interoperability Enhanced Regional Gateway (IERG) can be installed to support

interoperability between QChat and another PTT technology (i.e. iDEN). The presence of
the IERG causes the QAS to become the Interoperability Enhanced QAS (IEQAS).
38
The Client Activity Tracer (CAT) is an optional component. It is a diagnostic tool that allows
an operator to collect detailed information about calls in which a traced user is a participant.
CAT collects trace responses from specific QAS components that are involved in
call processing and logs them to a file
A trace can be created or deleted by the operator via the OMC
OMC-QC
QC
A trace should be automatically deleted after the expiration of its TTL or when a
call ends
The components that supply information to the CAT are actually subcomponents of the:
RD
RG
MCC
RULS
39
40
41
42
Protocols divide and manage the QChat interface and communication tasks based on
functionality and are intended to operate over standard IP stacks.
QChat uses open Internet standard protocols to increase flexibility and achieve
interoperability between QChat and other similar IP-based products. Standard protocols
used include:
DNS Domain Name System
SIP Session Initiation Protocol
RTP Real-Time Transport Protocol
Where the use of existing open standards cannot meet system performance requirements,
a standardized application-specific protocol layer is designed to meet those needs.
Proprietary protocols used include:
QSP QChat
QCh t Signaling
Si
li Protocol
P t
l
MTL Message Transport Layer
43
44
45
46

HT72-DB413-1 Ver. 1.1 QC01e M2 System Overview StudentGuide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

HT72-DB413-1 Ver. 1.1 QC01e M2 System Overview StudentGuide

Caricato da

Copyright:

Formati disponibili

Introduction to QChat

Qualcomm Confidential and Proprietary.

Operator Wide Area Network

Operator Wide Area Network

Platform Independent Architecture:

Push to Talk (PTT) Software

QChat-Aware Companion Applications can be developed by the OEM or a third

The diagram shows two independent processes:

Two messages that use SIP are SUBSCRIBE and NOTIFY:

The Interoperability Enhanced Regional Gateway (IERG) can be installed to support

Potrebbero piacerti anche