Big Computer Vs Tiny Computer (Computer on a Chip)

IP-CAN Session Establishment - Gx

1. The PCEF receives an Establish IP-CAN Session Request
    
2. The PCEF starts a new Gx session by sending a CCR to the PCRF using the CC-Request-Type AVP set to the value INITIAL_REQUEST. The PCEF provides UE identity information, PDN identifier, the UE IPv4 address and/or UE IPv6 address prefix and, if available, the PDN connection identifier, IP-CAN type, RAT type and/or the default charging method. The PCEF provides, when available, the Default-EPS-Bearer-QoS and the APN-AMBR to the PCRF.
    
3. The PCRF stores the information received in the CCR.
4. If the PCRF requires subscription-related information and does not have it, the PCRF sends a request to the SPR in order to receive the information.
    
5. The SPR replies with the subscription related information containing the information about the allowed service(s), QoS information and PCC Rules information.
    
6. The PCRF selects or generates PCC Rule(s) to be installed. The PCRF may also make a policy decision by deriving an authorized QoS and by deciding whether service flows described in the PCC Rules are to be enabled or disabled.
    
7. The PCRF provisions the PCC Rules to the PCEF using CCA. The PCRF may also provide event triggers listing events for which the PCRF desires PCC Rule Requests. Furthermore, the PCRF may provide authorized QoS including the APN-AMBR and the Default-EPS-Bearer-QoS, User Location
   Information, user CSG information (if received from the BBERF).
   
   If usage monitoring is enabled, the PCRF may provide the applicable thresholds for usage monitoring control at PCEF within the Usage-Monitoring-Information AVP.
    
8. The PCEF installs the received PCC Rules. The PCEF also enforces the authorized QoS and enables or disables service flows according to the flow status of the corresponding PCC Rules. If QoS information is received per
   QCI, PCEF sets the upper limit accordingly for the MBR that the PCEF assigns to the non-GBR bearer(s) for that QCI.
    
9. The PCEF sends a response to the Establish IP-CAN Session Request
   
   

    PCRF Gx explained here

Diameter Interfaces and their Specs

Interface	Network location	Supported version
Diameter Base Protocol		IETF RFC 3588, 4960, 793
Diameter Commands for 3GPP		IETF RFC 3589
Diameter Credit Control App		IETF RFC 4006
NASREQ Support for Network Access Server		IETF RFC 4005
EAP Support for Extensible Authentication Protocol		IETF RFC 4072
Mobile IPv4 Support for Diameter Mobile IPv4		IETF RFC 4004
Diameter Mobile IPv6		IETF RFC 5447
Diameter SIP Application		IETF RFC 4740
Sh interface	Between AS and HSS, Subscription and Authentication Data – IMS	3GPP TS 29.328 & TS 29.329
Sd interface	Between PCRF and TDF (Traffic Detection Function)	3GPP TS 29.212
Sy interface	Between PCRF and OCS/OFCS, Policy and Charging Control over Sy reference point	3GPP TS 29.219
Dh interface	Between AS and SLF	3GPP TS 29.328 & TS 29.329
Rf interface	Between AS and OFCS, postpaid charging	RFC 4006, 3GPP TS 32.225 & TS 32.299
Ro interface	Between AS and OCS, online charging in IMS & LTE	RFC 4006, 3GPP TS 32.225 & TS 32.299
Re interface	Between OCF and Rating function	3GPP TS 32.296
Cx interface	Between CSCF and HSS, Subscription and Authentication Data – IMS	3GPP TS 29.228 & TS29.229
Dx interface	Between CSCF and SLF	3GPP TS 29.228 & TS29.229
Sp interface	Between PCRF and SPR	3GPP TS 23.203, TS 29.328 & TS 29.329
Rx interface	Between AF and the PCRF, QoS and Policy	3GPP TS 23.203 & TS 29.214
Gx interface	Between PCEF and the PCRF, QoS and Policy	3GPP TS 29.212 & TS 23.203
Gy interface	Between OCS and PCEF, online charging	3GPP TS 32.299, TS 32.251 & RFC 4006
Gz interface	Between PCEF and OFCS	3GPP TS 32.240, TS 32.295
Gq interface	Between AF and PDF	3GPP TS 29.209
Gi interface	Between Packet Domain and an external packet data network	3GPP TS 29.061
SGi interface	Between the EPC based PLMN and the packet data network	3GPP TS 29.061
Zh interface	Between BSF and HSS	3GPP TS 29.109 & TS 33.220
Zh interface	Between BSF and HSS (used between operators)	3GPP TS 29.109 & TS 33.220
Dz interface	Between BSF and SLF	3GPP TS 29.109 & TS 33.220
Zn interface	Between BSF and NAF	3GPP TS 29.109 & TS 33.220
Zn' interface	Between BSF and Zn Proxy	3GPP TS 29.109 & TS 33.220
Dw interface	Between the 3GPP AAA Server and an SLF	3GPP TS 29.234
Wa interface	Between the WLAN AN and the 3GPP AAA Proxy	3GPP TS 29.234
Wd interface	Between the 3GPP AAA Proxy and 3GPP AAA Server	3GPP TS 29.234
Wx interface	Between the 3GPP AAA Server and the HSS	3GPP TS 29.234
Wm interface	Between the 3GPP AAA Server and the PDG	3GPP TS 29.234
Wg interface	Between the 3GPP AAA Server/Proxy and the WAG	3GPP TS 29.234
Pr interface	Between the 3GPP AAA Server and the PNA	3GPP TS 29.234
Wm interface	Between the 3GPP AAA Server and the PDG	3GPP TS 29.234
Gmb interface	Between GGSN and BM-SC	3GPP TS 29.061
Mz interface	Mz is the roaming variant of the Gmb reference point with the same functionality	3GPP TS 29.061
Bi interface	CCF to BS	3GPP TS TS 32.225
MM10 interface	Multimedia Messaging Service (MMS)	OMA MM10 interface
Ty interface	Between AGW and PCRF	3GPP2 TSG-X X.S0013-014
Tx interface	Between AF and PCRF	3GPP2 TSG-X X.S0013-013
S6a interface	Between MME and HSS, Subscription and Authentication Data	3GPP TS 29.272
S6b interface	Between the 3GPP AAA Server/Proxy and the PDN GW	3GPP TS 23402
S6d interface	Between SGSN and HSS, Subscription and Authentication Data	3GPP TS 29.272
S7c interface	Transfer of (QoS) policy information from PCRF to the S-GW.	3GPP TS 32820, TS 23402
S9 interface	Between PCRF in the HPLMN (H PCRF) and a PCRF in the VPLMN (V PCRF)	3GPP TS 23.203 & TS 29.215
S13 and S13' interface	Between EIR and MME/SGSN	3GPP TS 29.272
Gxa interface	PCRF and the BBERF	3GPP TS 23.203
Gxb interface	Between ePDG and vPCRF	3GPP TS 23.203
Gxc interface	BPCRF and the BBERF	3GPP TS 23.203
SWa interface	Between an un-trusted non-3GPP IP access and the 3GPP AAA Server/Proxy	3GPP TS 23402
SWd interface	Between the 3GPP AAA Proxy and 3GPP AAA Server	3GPP TS 23402
SWn interface	Between Untrusted Non-3GPP IP Access and ePDG	3GPP TS 23402
SWm interface	Between the 3GPP AAA Server/Proxy and the ePDG	3GPP TS 23402
SWx interface	Between the 3GPP AAA Server and the HSS	3GPP TS 23402
Sta interface	Between a trusted non-3GPP IP access and the 3GPP AAA Server/Proxy	3GPP TS 23402
H2 interface	Between the 3GPP AAA Server and the HA	3GPP TS 23402
Gq’ interface	Between AF and RACS	ETSI TS 183.017
E2 interface	Between AF and NASS	ETSI TS 283 035
E4 interface	Between NASS and RACS	ETSI TS 283 034
E5 interface	Between UAAF – UAAF	ETSI TS 282 004
Re interface	Between RCEF and RACS	ETSI TS 183 060
A3 interface	Between UAAF and AMF	ETSI TS 282 004
A4 interface	Between CLF and UAAF	ETSI TS 282 004
Rr interface	x-RACF	03196-NGN-R3
Zh interface	Generic Authentication Architecture (GAA)	PKT-SP-29.109
Zn interface	Generic Authentication Architecture (GAA)	PKT-SP-29.109
Cx interface	CSCF- HSS	PKT-SP-29.229
Dx interface	CSCF- SLF	PKT-SP-29.229
Pkt-laes-2 interface	Session Control Element — DF (electronic surveillance requirements)	PKT-SP-ES-INF-I01
P-CSCF- PAM Interface	Between P-CSCF – PAM	PKT-SP-QOS-I02-080425, 3GPP TS 23.203 & TS 29.214
Pkt-mm-2 interface	Policy Server — CMTS	3GPP TS 29.212 & TS 23.203
TC-6	Based on 3GPP Rx	MSF-IA-DIAMETER.010-FINAL
TC-7	Based on 3GPP Ty	MSF-IA-DIAMETER.014-FINAL
TC-8	Based on 3GPP Tx	MSF-IA-DIAMETER.013-FINAL
TC-9	Based on 3GPP Rq	MSF-IA-DIAMETER.005-FINAL
TC-10	Based on 3GPP Gx	MSF-IA-DIAMETER.012-FINAL
TC-11	Based on 3GPP e4	MSF-OA-DIMATER.011-FINAL
DB-0	Based on 3GPP Cx/Dx	MSF-IA-DIAMETER.006-FINAL
DB-2	Based on 3GPP Sh/Dh	MSF-IA-DIAMETER.003-FINAL
BI-1	Based on 3GPP Rf	MSF-IA-BILLING.001-FINAL
LOC-1	Based on 3GPP e2	MSF-IA.DIAMETER.008-FINAL
Rw interface	Between the Policy Decision Physical Entity (PD-PE) and the Policy Enforcement Physical Entity (PE-PE)	ITU Q.3303.3
Rs interface	Between Service Control Physical Entity (SC-PE) and Resource and Admission Control Physical Entity (RAC-PE)	ITU Q.3301

PacketCable, 3GPP, CableLabs, IMS ??!!!

PacketCable ?? -> Multimedia over Cable internet 

PacketCable is an industry consortium founded by CableLabs with the goal of defining standards for the cable television modem access industry. CableLabs leads this initiative for interoperable interface specifications in order to deliver real-time multimedia services over two-way cable networks. Built on top of the industry’s DOCSIS (Data Over Cable Service Interface Specifications) cable modem infrastructure, PacketCable networks use the Internet Protocol (IP) to enable a wide range of multimedia services, such as Voice over IP (IP telephony), multimedia conferencing, interactive gaming, and general multimedia applications.

A DOCSIS network with PacketCable extensions enables cable operators to deliver data and voice traffic efficiently using a single high-speed, quality-of-service (QoS)-enabled broadband (cable) architecture.

The PacketCable effort dates back to 1997 when cable operators identified the need for a real-time multimedia architecture to support the delivery of advanced multimedia services over the DOCSIS architecture.


PacketCable is a CableLabs specification effort designed to support the convergence of voice, video, data, and mobility technologies. There are tens of millions of cable broadband customers, and the capability of the network to provide innovative services beyond high-speed Internet access is ever-increasing. In particular, real-time communication services based on the IP protocols, such as Voice over Internet Protocol (VoIP), are rapidly evolving and consumers are embracing a wide-range of client devices and media types. It is expected that new technologies, such as Video over IP communications and the ability to display voice and video mail message notifications on a TV-set, will change the way communication and entertainment services are offered. These cutting edge technologies will present exciting new opportunities for cable operators to offer high-value services to consumers in a cost-effective manner.

PacketCable defines an architecture and a set of open interfaces that leverage emerging communications technologies, such as the IETF Session Initiation Protocol (SIP) [RFC 3261], to support the rapid introduction of new IP-based services onto the cable network. A modular approach allows operators to flexibly deploy network capabilities as required by their specific service offerings, while maintaining interoperability across a variety of devices from multiple suppliers. Intentionally non service-specific, the platform should provide the basic capabilities necessary for operators to deploy services in areas such as:

• Enhanced Residential VoIP and IP Video Communications – Capabilities such as video telephony; call treatment based on presence, device capability, identity; and 'Click to dial' type of features;

• Cross Platform Feature Integration – Capabilities such as caller's name and number identification on the TV and call treatment from the TV;

• Mobility services and Integration with Cellular and Wireless Networks – Capabilities such as call handoff and roaming between PacketCable VoIP over WiFi and wireless-cellular networks; voice-mail integration; and single E.164 number (e.g., telephone number);

• Multimedia Applications – Capabilities such as QoS-enabled audio and video streaming;

• Commercial Services Extensions – Capabilities such as PBX extension; IP Centrex Services to small to medium-sized businesses; and VoIP trunking for enterprise IP-PBXs;

• Residential SIP Telephony Extensions – Capabilities such as traditional telephony features (e.g., call waiting, caller ID), operator services, and emergency services.

3GPP IMS?? -> Multimedia Over Wireless Network (LTE)

The 3rd Generation Partnership Project (3GPP) unites [Six] telecommunications standard development organizations (ARIB, ATIS, CCSA, ETSI, TTA, TTC), known as “Organizational Partners” and provides their members with a stable environment to produce the Reports and Specifications that define 3GPP technologies.

The project covers cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, quality of service - and thus provides complete system specifications. The specifications also provide hooks for non-radio access to the core network, and for interworking with Wi-Fi networks.
3GPP specifications and studies are contribution-driven, by member companies, in Working Groups and at the Technical Specification Group level.
The Four Technical Specification Groups (TSG) in 3GPP are;

• Radio Access Networks (RAN),
• Service & Systems Aspects (SA),
• Core Network & Terminals (CT) and
• GSM EDGE Radio Access Networks (GERAN).

CableLabs and 3GPP :

The PacketCable architecture is based on the 3GPP IMS architecture, with some incremental extensions. Extensions include use of additional or alternate functional components compared with the IMS architecture, as well as enhancements to capabilities provided by the IMS functional components. Some of the PacketCable enhancements to the IMS include:

• Support for Quality of Service (QoS) for IMS-based applications on DOCSIS access networks, leveraging thePacketCable Multimedia architecture [MM TR];

• Support for additional access signaling security and UE authentication mechanisms;

• Support for provisioning, activation, configuration, and management of UEs;

• Support for regulatory requirements such as number portability, preferred carrier, and PacketCable lawful interception.

PacketCable IMS Architecture:

 

 3GPP IMS Architecture:

PacketCable IMS call flow:

1. UE registration with S-CSCF via P-CSCF
2. UE1 calls UE2
3. P-CSCF triggers AAR to PAM and PCRF (Rx Interface )
4. PCRF installs flow in CMTS
5.  ==== RTP data flow  ====
6. End

Aim of PacketCable 2.0:

The general aim of PacketCable 2.0 is to allow cable operators to deliver all manner of IP-based applications (data, video, and voice) seamlessly across its traditional wired and forthcoming wireless infrastructures.

References :

• Google Kadavul
• CableLabs
• 3GPP

What is an Automation & Automation Framework ???

What is Test Automation ?

Test automation refers to anything that streamlines the testing process and facilitates things to move along more quickly and with less delay. It is the use of software to perform various test activities like controlling test execution, performing test analysis, and generating test reports. Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.

What is Test Automation Framework ?

An automated test framework may be loosely defined as a set of abstract concepts, processes, procedures and environment in which automated tests will be designed, created and implemented. In addition, it includes the physical structures used for test creation and implementation, as well as the logical interactions among those components.

Benefits:

Software changes are unavoidable. In the current competitive environment, these changes need to be implemented quickly. Organizations are looking for techniques to help reduce the timeframes for making these changes while still meeting quality objectives and maintaining certain quality levels. One way to shorten the testing timeframe is to reuse previous test cases and/or scripts andonly make modifications to these assets as required by the functional needs. In this way, the tester does not need to build these items from scratch. Additional time savings can be achieved by automating the execution of pre-existing test cases. Having an automated test suite that can run unattended and reused for every release will save a lot of time and effort and improve test coverage and quality of the delivered solution.

Types of Automation Framework,

Modular Framework:

This can be further divided into two types,

Test Script Modular Framework -- The Test Script Modular Framework is the most basic of the frameworks. In object-oriented programming (OOP), an abstraction layer in front of a component hides the details of the component. This insulates the application from modifications in the component and provides modularity in the application design. When working with test scripts (in any language or proprietary environment), this can be achieved by creating small, independent scripts that represent modules, sections, and functions of the AUT. Then, these small scripts are taken and combined in a hierarchical fashion to construct larger tests. The use of this framework will yield a higher degree of modularity and add to the overall maintainability of the test scripts.


Library Architecture Framework -- The test library architecture framework is very similar to the test script modularity framework and offers the same advantages, but it divides the application-under-test into procedures and functions instead of scripts. This framework requires the creation of library files that represent modules, sections, and functions of the application-under-test. These library files are then called directly from the test case script.

Keyword-Driven or Table-Driven Testing Framework:

Keyword-driven testing and table-driven testing are interchangeable terms that refer to an application-independent automation framework. This framework requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.

Data-Driven Testing Framework:

Data-driven testing is a framework where test input and output values are read from data files (datapools, ODBC sources, cvs files, Excel files, DAO objects, ADO objects, and such) and are loaded into variables in captured or manually coded scripts. In this framework, variables are used for both input values and output verification values. Navigation through the program, reading of the data files, and logging of test status and information are all coded in the test script.

Hybrid Test Automation Framework:

The most commonly implemented framework is a combination of all of the above techniques, pulling from their strengths and trying to mitigate their weaknesses. This hybrid test automation framework is what most frameworks evolve into over time and multiple projects.