ht72-db413-1 ver. 1.1 qc01e m2 system overview studentguide

Introduction to QChat Introduction to QChatSystem Overview

1 MaycontainU.S.andinternationalexportcontrolledinformationQualcommConfidentialandProprietaryQualcomm Confidential and Proprietary.

2 MaycontainU.S.andinternationalexportcontrolledinformationQualcommConfidentialandProprietary

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 NetworkQChat 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 function.p

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.


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


Push to Talk (PTT) Software

A fundamental component of the QChat PTT System

PTT handset software

Set of libraries that implement QChat functionality residing in the AMSS Set of libraries that implement QChat 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

M i t ti d d t d th t k t t Manages registration and understands the network state


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) 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.


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) a Media Control Unit Complex (MCC) a regional LIS one orRegional Dispatchers (RD), a Media Control Unit Complex (MCC), a regional 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 carrier-provided DNS server to support QChat Services.

Some of the components necessary for QChat operation are not provided by Qualcomm, such as a Presence Server Carrier Database and Authentication Server (AAA)such as a Presence Server, Carrier Database, and Authentication Server (AAA).


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 Thi ill t ti h th ll W ill b k it d t b t dprocess. This illustration shows the overall process. We will break it down step-by-step and

examine what each component is doing and how the components interact with each other.


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 Protocol (SIP) registration server. A SIP registration server processes and ( ) g g pmaintains 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.


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.


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 periodically and is independent of the call registration process. Upon p y p g p ppower up, and then again at regular intervals, the RD subscribes itself to the local RLS by sending a SIP SUBSCRIBE message to the RLS.


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.


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.


25 MaycontainU.S.andinternationalexportcontrolledinformationQualcommConfidentialandProprietary 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.


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.


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.


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 is sent to the Regional Dispatcher. Remember the job of the regional q g p j gdispatcher 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.


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


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 fromthe originator to the MCC, which relays those packets to the intended target(s).

32 MaycontainU.S.andinternationalexportcontrolledinformationQualcommConfidentialandProprietary 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 Every region has its own RULS and RULSs do not interconnect We coverplain-text files. Every region has its own RULS, and RULSs do not interconnect. We cover the fields contained in an UDR in another course.


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.


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.


This message flow shows the messages and protocols used to initiate a QChat call. Lets walk through it again step by stepthrough it again, 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 are we going to let Joe have QChat service in our network? The DFEthen queries the DFE Hey, are we going to let Joe have QChat service in our 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

O HD replies, Oh, 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, I will handle this media for you. As those targets acknowledge, the MCC sets up the pipe to


saying, I will handle this media for you. As those targets acknowledge, the MCC sets up the pipe to carry the voice data between Joe and Jack.

The Regional Gateway (RG) supports inter-carrier calls between users on different QChat carrier networks. The RG is an optional component.


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).


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-QC A trace can be created or deleted by the operator via the OMC 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 RG

MCC

RULS


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 QCh t Si li P t l QSP QChat Signaling Protocol

MTL Message Transport Layer


ht72-db413-1 ver. 1.1 qc01e m2 system overview studentguide

Documents