Sushant_Project_Report

2011ECA1470 Page 1
Connectem Inc. | Sushant Mittal
GURU NANAK DEV UNIVERSITY, AMRITSAR
Automation of LTE Call Flows
and
Development of Policy and Charging Rules Function (PCRF)
Simulator
PROJECT REPORT
Submitted By : Submitted To :
Sushant Mittal Dr. Butta Singh
2011ECA1470
In fulfilment of 6 Months Industrial Training
At
Connectem Software Systems Private Limited, Mahape Navi-
Mumbai

2011ECA1470 Page 2
Intentionally Blank

2011ECA1470 Page 3
ACKNOWLEDGEMENT
I have taken efforts in this project. However, it would not have been possible without the kind
support and help of many people. I would like to extend my sincere thanks to all of them.
I am highly indebted to Mr. Mayank Khanna, Senior Member of Technical Staff at
Connectem Software Systems Private Limited for his guidance and constant supervision as
well as for providing necessary information regarding the project & also for their support in
completing the project.
I would also like to thank Mr. Amit Chawre, Director Connectem Software Systems Private
Limited for providing me opportunity for training and also the guidance related to project.
I would like to express my gratitude towards my parents & teachers of Guru Nanak Dev
University R. C. Jalandhar for their kind co-operation and encouragement which help me in
completion of this project.
I would like to express my special gratitude and thanks to entire Connectem Team for giving
me such attention and time.
My thanks and appreciations also go to my colleague in developing the project and people
who have willingly helped me out with their abilities.
Thanks & Regards
Mr. Sushant Mittal
Guru Nanak Dev University
Regional Campus, Jalandhar.
Punjab.
sushantmittal.sm@gmail.com

2011ECA1470 Page 4
CONTENTS
No. Particulars Page
1. Connectem – Overview 6 – 8
i). Vision 6
ii). Solutions 6
iii). Partners 8
2. LTE (4G) 9 – 16
i). History and Evolution 9
ii). LTE Network Reference Model (Architecture) 11
iii). LTE Entities 12
iv). EPC Entities 12
v). Interfaces 14
vi). Protocol Stacks 15
3. LTE Identifiers 17 – 21
i). UE Identifiers 17
ii). NE Identifiers 20
4. LTE Call Flows 21 – 23
i). Attach 21
ii). Detach 22
iii). S1 Release 23
iv). Service Request 23
v). Handover 23
5. Robot Framework 24 – 25
i). Features 24
ii). Architecture 24
iii). File Structure 24
6. Automation of LTE Call Flows 25 – 45
i). Need for Automation 27
ii). Robot Framework 27

2011ECA1470 Page 5
iii). Tshark 44
iv). PERL Scripts 45
7. Policy and Charging Control (PCC) 46 – 47
i). PCC Architecture 46
ii). PCC Rules and its purposes 46
8. PCRF Simulator 48 – 57
i). Seagull 48
ii). Implementation 49
iii). Wrapper Code to Run PCRF Simulator 49
9. Bibliography 58

2011ECA1470 Page 6
Connectem – Overview
Connectem Inc. was founded by industry veterans in 2011 who identified a way to bring the
advances in Virtualization techniques and Software Defined Networking Principles to the
Mobile Wireless Network.
The VCM Platform is one of the truly unique innovations in Mobile Infrastructure in years.
With this platform carriers for the first time can economically address the growth in services,
in number of IP endpoints and in the associated signaling.
Connectem VCM is fundamentally changing the way wireless devices connect to a powerful
and elastic network. We believe new world problems cannot be resolved by old world
models. Therefore we have created VCM.
i). Vision
To be the Prime Driver in an communicating world. This means a world in which all people
can use voice, data, images and video to share ideas and information whenever and wherever
they want.
The Company is headquartered in US and a subsidiary in India.
ii). Solutions:
a). INTELLIGENT SIGNALING SOLUTION
Mobile operators have a finite set of resources (such as spectrum and network
capacity) to quench the data thirst of their customer and congestion on a mobile
network is inevitable. Increasing the spectrum and higher cell density are needed but
so are better methods of device segregation and signaling management.
Just like in many cities where roads were built centuries ago that now need to
accommodate an explosion of vehicles, building new roads helps but traffic
segregation and traffic signaling system are needed to avoid the congestion and fully
optimize the limited resources, in this case the roads.
Connectem VCM (Virtual Core for Mobile) Platform brings this concept of traffic
control to 3G and LTE networks without requiring changes in the end-user devices.

2011ECA1470 Page 7
VCM employs innovative solutions to avoid congestion and signaling storms while
high priority users are assured access. It is important to note that data overload can
slowdown the networks but signaling overload will crash it.
As an example, with VCM software an „attach‟ request from a device can be
processed at least four times faster and thereby improving the overall network's
admission rate. Traditionally, data communication is typically user initiated towards
the network. As use cases for network to device communication emerge such as M2M
communication, today's signaling assumptions will no longer be valid.
VCM includes innovation on network initiated techniques. This approach not only
optimizes the network to device signaling, it does so with more comprehensive
flexibility in the use of mobile identities such as phone numbers or subscriber identity.
b) MOBILE DATA DEVICES: Efficient Scaling Solution
As more and more content is becoming digital and devices are becoming more
powerful the mobile device is playing a central role in how digital media is consumed
around the world. Interestingly, consumers & enterprises are not only consuming but
also producing content at an exponential pace.
Introduction of data oriented smart devices like tablets, eReaders and interactive
gaming consoles create a different dynamic for the Mobile ecosystem. Digital media
companies are creating a new set of “Connected Devices” and marketing directly to
consumers. The content available through such devices in conjunction with mobile
broadband access dramatically increases the perceived value for the consumer.
Mobile Service Provides are cognizant of the fact that voice, text messaging and
broadband access product lines are maturing or mature, and will have to be replaced
by other revenue sources. “Connected Devices” look very attractive to them, however
the consumer is typically engaged with the associated digital media company
providing the device rather than the service provider providing connectivity.
According to some industry pundits the solution will come from a closer relationship
between carriers and business partners. Virtual Core for Mobile is enabling new
business partnerships.
The Connectem VCM architecture and software has been developed with the best
practices of the Internet industry in mind. The elasticity addresses the capacity needs
while APIs to the applications make it inherently suitable for the cooperative
ecosystem.

2011ECA1470 Page 8
This new software architecture will enable the quick adoption of new business models
in the Mobile ecosystem. Virtualization in this case allows an operator to quickly
create a Business Partner specific network where their devices interact independent of
any other virtual network the operator might have created for another partner. By
providing services dedicated to the Partner needs they can both attract these business
partners to their network and maintain visibility such that they can jointly work on
optimizing their network efficiency. Moreover, it allows both operators and business
partner to expand their traditional roles.
iv). Partners
Connectem believes that if you want to be relevant in Network Functions Virtualization then
you need to support industry partnerships. The partners are Amdocs, Amethon, Clavister,
Cyan Inc., IBM, Procera Networks, Red Hat, VMWare and many more.

2011ECA1470 Page 9
LTE (4G)
i). History and Evolution
The original use of mobile phones has been transformed over the last 10 to 15 years. The
advent of different types of higher data rate technologies began a shift in revenue from voice
to data for telecommunication companies. The growing demand to be able to use the Internet
anywhere, anytime, led to the development of higher bandwidth technologies.
The first generation of mobile communications started with the Advanced Mobile Phone
Systems (AMPS), which was an analogue system. AMPS can be thought of as 1G. From
there, we progressed to GSM and CDMA-one (pretty much regarded as 2G) and then to
UMTS and EV-DO, which are 3G technologies. The latest technologies that are regarded as
candidates for 4G are LTE (from the 3GPP group) and LTE Advanced (After Release 10).

2011ECA1470 Page 10

2011ECA1470 Page 11
ii) LTE Network Reference Model (Architecture)
The LTE network called Evolved Packet System (EPS) is an end-to-end (E2E) all IP
network. EPS is divided into two parts - LTE part which deals with the technology related to
a radio access network (E-UTRAN) and EPC part which deals with the technology related to
a core network. An E2E all IP network means that all traffic flows – from a UE all the way to
a PDN.
Following figure shows an LTE network reference model, consisting of LTE entities (UE and
eNB) and EPC entities (S-GW, P-GW, MME, HSS, PCRF, SPR, OCS and OFCS). A PDN is
an internal or external IP domain of the operator that a UE wants to communicate with, and
provides the UE with services such as the Internet or IP Multimedia Subsystem (IMS).

2011ECA1470 Page 12
iii). LTE Entities:
1. User Equipment (UE): User equipment is any device used directly by an end-
user to communicate. It can be a hand-held telephone, a laptop computer equipped
with a mobile broadband adapter or any other device. A UE connects to an eNB over
the LTE-Uu interface.
2. Evolved Node B (eNodeB): An eNB provides users with the radio interfaces and
performs Radio Resource Management (RRM) functions such as dynamic resource
allocation (scheduler), eNB measurement configuration and provision, radio
admission control, connection mobility control and Radio Bearer (RB) control and
Inter-Cell Interference Coordination (ICIC).
iv). EPC Entities:
1. Mobility Management Entity (MME): An MME is the main control entity
for the E-UTRAN. It communicates with an HSS for user authentication and user
profile download, and provides UEs with EPS Mobility Management (EMM) and
EPS Session Management (ESM) functions using NAS signalling. The main functions
supported by a MME are as follows:
 NAS signalling (EMM, ESM and NAS Security)
 User authentication and roaming with HSS over the S6a interface
 Mobility management (paging, Tracking Area List (TAI) management and
handover management)
 EPS bearer management.

2011ECA1470 Page 13
2. Serving Gateway (S-GW): Serving GW is the gateway which terminates the
interface towards E-UTARN. For each UE associated with the EPS, at given point of
time, there is a single Serving GW.
SGW is responsible for handovers with neighboring eNodeB's, also for data transfer
in terms of all packets across user plane.
SGW functions include:
 The local Mobility Anchor point for inter-eNodeB handover.
 Mobility anchoring for inter-3GPP mobility.
 Packet routing and forwarding.
 Transport level packet marking in the uplink and the downlink based on the QCI.
3. Packet Data Network Gateway (P-GW): A P-GW provides a UE with access
to a PDN by assigning an IP address from the address space of the PDN. The P-GW
serves as the mobility anchor point for handover between 3GPP and non-3GPP. It also
performs policy enforcement, packet filtering and charging based on the PCC rules
provided by a PCRF. The main functions supported by a P-GW are as follows:
 IP routing and forwarding
 Per-SDF/Per-User based packet filtering
 UE IP address allocation
 Mobility anchoring between 3GPP and non-3GPP
 PCEF functions
 Charging per-SDF/per-User
4. Home Subscriber Server (HSS): An HSS is the central DB where user profiles
are stored. It provides user authentication information and user profiles to the MME.
5. Policy and Charging Rules Function (PCRF): Policy and Charging Rules
Function (PCRF) is the part of the Evolved Packet Core (EPC) that support service
data flow detection, policy enforcement and flow-based charging. After an EPS
session is established or modified then the policy of how charging is to be done is
applied. This procedure is called Policy and Charging Control (PCC).
6. Subscriber Profile Repository (SPR): The Subscription Profile
Repository contains subscriber/subscription information. This information is per-PDN
basis and includes-
 Subscriber's allowed services.
 Information on subscribers allowed QoS (MBR and GBR).
 Subscriber's charging related information.
 Subscriber category
The Sp reference point resides between SPR and PCRF. It allows the PCRF to request
subscription information related to a subscriber's service/session.
7. Online Charging System (OCS): The Online Charging System is a credit
management system for pre-paid charging. An OCS provides-

2011ECA1470 Page 14
 Real-time credit control.
 Charging functions based on volume, time and event.
8. Offline Charging System (OFCS): The Offline Charging System is used for
offline charging. The OFCS receives charging events from PCEF over Gz interface
and generates Charging Data Records (CDRs) which are sent to the billing system.
v). Interfaces
REFERENCE
POINT
PROTOCOL DESCRIPTION
LTE-Uu E-UTRA
(Control plane and User plane)
An interface for the control and user
planes between a UE and an E-
UTRAN (eNB). The signaling
connection over the LTE-Uu is the
RRC connections represented by
Signaling Radio Bearers (SRBs), and
the user plane connection is the logical
channels represented by Data Radio
Bearers (DRBs).
X2 X2-AP (control plane)
GTP-U (user plane)
An interface for the control and user
planes between two eNBs. It is used
during X2 handover and/or for Self
Organizing Network (SON)-related
functions. X2-AP protocol is used in
the control plane and a GTP-U tunnel
per bearer is provided for data
forwarding in the use plane.
S1-U GTP-U An interface for the user plane
between an E-UTRAN (eNB) and an
S-GW. It provides a GTP tunnel per
bearer.
S1-MME S1-AP An interface for the control plane
between an E-UTRAN (eNB) and an
MME.
S11 GTP-C An interface for the control plane
between an MME and an S-GW. It
provides a GTP tunnel per user.
S5 GTP-C (control plane)
GTP-U (user plane)
An interface defined between an S-
GW and a P-GW for the control plane
and user plane. The S5 interface
provides a GTP tunnel per bearer for
the user plane and GTP tunnel
management (creation, modification
and deletion) per user for the control
plane. For inter-PLMN, however, an
S8 interface is used instead. The S8
interface is out of the scope of this
document and will be described in
other LTE interworking document to

2011ECA1470 Page 15
follow.
S6a Diameter An interface for the control plane
between an HSS and an MME. It
exchanges user subscription and
authentication information.
Sp Diameter An interface for the control plane
between an SPR and a PCRF.
Gx Diameter An interface for the control plane
between a PCRF and a P-GW. It
transfers policy control and charging
rules from the PCRF to the P-GW to
support QoS policy and charging
control.
Gy Diameter An interface for the control plane
between an OCS and a P-GW.
Gz GTP‟ An interface for the control plane
between an OFCS and a P-GW.
SGi IP An interface for the control and user
planes between a P-GW and a PDN.
The IETF-based IP packet forwarding
protocols are used in the user plane
while DHCP and RADIUS/Diameter
protocols are used in the control plane.
vi). Protocol Stacks
1. User Plane Protocol Stacks:

2011ECA1470 Page 16
2. Control Plane Protocol Stacks:

2011ECA1470 Page 17
LTE Identifiers
In LTE network, different IDs are used to identify each entity depending on their relationship
with other IDs just like different names and titles are used to refer to a person. Features of
these LTE IDs will be explained in terms of their creation time, attribute type
(permanent/temporary) and ranges within which they are uniquely identified.
Creation Time: Creation time of an LTE ID can be one of the following:
 When commissioned upon equipment installation.
 When provisioned by the operator before or during service operation.
 When created on-demand as a user accesses to the network or uses services.
Type: An LTE ID can have an attribute type, either a permanent value that stays fixed once
set, or a temporary one that changes whenever activated. The ones allocated by being
commissioned or provisioned have permanent values while others allocated on-demand as a
user accesses to the network or uses services have temporary values.
Range (within which IDs are uniquely identified): Each LTE ID is uniquely identified across
the world, operator networks, entities or channels.
LTE Identifiers are classified into 3 basic categories:
i). User Equipment (UE) Identifiers
a). Public Land Mobile Network (PLMN) ID: PLMN ID indicates the network that a user
has subscribed to. It consists of an MCC (Mobile Country Code) and an MNC (Mobile
Network Code). The three-digit MCC identifies the country where the mobile network in use
is located. An MNC identifies the operator of a mobile communication network and is
allocated by each country.

2011ECA1470 Page 18
b). International Mobile Subscriber Identity (IMSI): IMSI is a unique number identifying
a mobile subscriber globally. An IMSI is composed of a PLMN ID that indicates the network
the user subscribes to and a Mobile Subscriber Identification Number (MSIN) that is assigned
by the operator.
c). Globally Unique Temporary Identifier (GUTI): An IMSI is a permanent and unique ID
that identifies a mobile subscriber. There might be security problems if it is frequently
exposed over the radio link. For security enhancement, a Globally Unique Temporary
Identifier (GUTI) is allocated to a UE by an MME when the UE attaches to the Network, and
used instead of the IMSI to identify the UE.
d). IP Address: ID Necessary to Connect to a PDN: An IP address, also called as a “PDN
address” is allocated by an LTE network to a UE in order for the UE to connect to a PDN (i.e.
an IP network) when the UE initially attaches to the LTE network. Because a UE can be
connected to more than one PDN through an LTE network depending on the services, the
LTE network allocates each UE a different IP address per each PDN the UE is connected to.

2011ECA1470 Page 19
e). C-RNTI: ID required to distinguish UEs within a Cell: Cell Radio Network Temporary
Identifier (C-RNTI) is allocated to a UE by an eNB in a cell controlled by the eNB and is
effective only within the serving cell. UEs in the cell are uniquely identified by their C-RNTI.
A new C-RNTI is allocated when the UE leaves the current cell and moves to a new cell.
f). Paired UE S1AP IDs needed to distinguish UEs over the S1-MME Interface: S1AP
layer handles the control messages between an eNB and an MME over an S1-MME interface.
Many UEs stay connected to an eNB at the same time. And the eNB uses the same S1 link for
all the S1AP control messages it exchanges with an MME with respect to the UEs. So, in
order to tell which S1AP message is for which UE, an eNB allocates an ID (eNB UE S1AP
ID) to each UE when it sends the first S1AP message for a UE to an MME. Likewise, one
MME exchanges S1AP messages with many eNBs (e.g. more than hundreds) and through
many S1 links concurrently. Again, in order to tell which S1AP message is for which UE in
which eNB, the MME allocates an ID (MME UE S1AP ID) to each UE when it sends the
first message for a UE to an eNB.
g). Paired UE X2AP IDs needed to distinguish UEs over the X2 Interface: X2AP layer
handles the control messages (X2AP messages) between two neighbour eNBs over an X2
interface.
During each handover of UEs between two neighbour eNBs, the X2AP messages from the
UEs are delivered to the peer eNB using the same X2 link. The first time an eNB (source
eNB or target eNB) sends a X2AP message to a peer eNB, the eNB assigns an ID to each UE
and sends the message with the ID in order to show for which UE the X2AP message is. A
source eNB allocates an “Old eNB UE X2AP ID” to its first message (Handover Request

2011ECA1470 Page 20
message) to a target eNB, which also allocates a “New eNB UE X2AP ID” to its first
response message (Handover Request Acknowledge message) to the source eNB.
ii). Network Equipment (NE) Identifiers
a). IDs to Identify Mobility Management Entity (MME): GUMMEI, MMEI, MMEGI
and MMEC:
An MMEI (MME Identifier) is used when identifying an MME in the network of an.
However, a GUMMEI (Globally Unique MME Identifier), combination of a PLMN ID and
an MMEI, is used when identifying an MME outside of the network of the operator. In case
of an MME group formed by the operator, an MMEI consist of an MMEGI (MME Group
Identifier) that represents an MME group, and an MMEC (MME Code) that represents a
particular MME in the MME group.

2011ECA1470 Page 21
b). IDs to identify eNB: eNB ID and Global eNB ID:
An eNB ID is used for identifying an eNB within an operator‟s network only, whereas a
Global eNB ID, combination of a PLMN ID and an eNB ID, is used for identifying one
outside the network.
LTE Call Flows
i). Attach
1. The User turns on the UE and attempts initial attach to the network. Immediately
after being turned on, the UE is in EMM-Deregistered, ECM-Idle and RRC-Idle
state.
2. After performing PLMN and cell search, it synchronizes to a cell and sends an
“Attach Request (UE ID = IMSI)” message that includes IMSI as UE ID to the
MME. Then, it enters EMM-Registered, ECM-Connected and RRC-Connected
state.
3. Mutual authentication between the UE and network (MME) are performed through
Authentication Vectors generated by HSS. Once mutually authenticated, the MME
downloads a subscription profile from the HSS.
4. Now MME starts performing NAS security setup for secure delivery of messages
between UE and MME.
5. After that it carries out Location Update procedure to HSS to indicate in which
MME UE is registered.
6. Then it begins creating an EPS session and default EPS bearer using the profile.
While creating a default EPS bearer, the network assigns the UE an ID to use for
attaching to the LTE network/PDN or registering its location. At this time, the P-
GW assigns a UE IP address and the MME assigns a GUTI and TAI list. Such
information (i.e. IP address, GUTI and TAI list) is delivered by the MME to the
UE, as included in an “Attach Accept” message.

2011ECA1470 Page 22
7. If the initial attach succeeds, the User stays in EMM-Registered, ECM-
Connected and RRC-Connected state and may use the service (e.g. Internet). If it
fails, the MME notifies the UE of such failure by sending an Attach Reject”
message, and the UE transits to EMM-Deregistered, ECM-Idle and RRC-Idle
state.
ii). Detach
Once the UE made the initial attach to the network, it stays in EMM-Registered, ECM-
Connected and RRC-Connected state. Then later it may need to detach, or to be detached,
from the network. A detach request can be initiated by a UE, MME or HSS. The UE transits
to EMM-Deregistered, ECM-Idle and RRC-Idle state once detached from the network.
Detach can be categorized as one of the following cases depending on where detach
triggering is detected:
1) Detach Case 1: UE-initiated Detach
UE can initiate detach:
 if UE is turned off.
 if a USIM card is removed from UE.
 if UE is attempting to use a non-EPS service.
2) Detach Case 2: MME-initiated Detach
MME-initiated detach can be further divided into explicit detach and implicit detach. In case
of explicit detach, MME notifies UE of its intent to detach in advance by sending a Detach
Request message, and informs the UE whether it has to attach the network again or not after
detach. In case of implicit detach, however, the MME initiates detach procedures without
notification (i.e. without sending a Detach Request message) because the UE is not capable of
communicating with the MME.
MME can initiate:
i) Explicit Detach

2011ECA1470 Page 23
 for an operator‟s O&M (Operation & Maintenance) purposes
 if re-authentication fails
 if it cannot provide the resources allocated to a user
ii) Implicit Detach
 if it is not able to communicate with a user because of poor radio link quality (e.g.
radio link failure)
3) Detach Case 3: HSS-initiated Detach
HSS can initiate detach:
 if the user profile provisioned in HSS is changed, and thus the one saved in MME
also has to be changed
 if an operator is trying to restrict access by an illegal UE (e.g. a stolen device) to
its network
iii). S1 Release
After the successful initial attach to the LTE network, the UE uses a service in EMM-
Registered, ECM-Connected and RRC-Connected state. If it stops using the service for a
certain period of time, the S1 bearer and S1 signalling connection are released, and the UE
transits to Idle state, entering EMM-Registered, ECM-Idle and RRC-Idle state. User
inactivity can be detected by a UE or by an MME.
iv). Service Request
This is the case where new user traffic is generated for the UE in Idle (EMM-Registered,
ECM-Idle and RRC-Idle) state. New user traffic can be uplink traffic from the UE or
downlink traffic from the network. The UE transits to active (EMM-Registered, ECM-
Connected and RRC-Connected) state through a service request procedure, and then can
receive or send user traffic. The service request procedure can be triggered either by a UE or
by a network.
v). Handover
The greatest advantage of a wireless device (mobile device) over a wired one is that its user
can travel while using services on it. This mobility has allowed users to conveniently use
services in any place, whether at home or on the go, at any time they want. Because of this
benefit, wireless users have already outnumbered wired phone users. Mobile subscribers can
use services while on the go thanks to the fact that mobile networks support handovers. User
Equipment (UE) can switch from one base station/cell to another without losing any
incoming or outgoing data, and communicate with the network without interruption during
such switch (i.e. by performing a handover). This ensures its user is seamlessly served no
matter which cell the user is connected to.

2011ECA1470 Page 24
Robot Framework
Robot Framework is a Python-based, extensible keyword-driven test automation framework
for end-to-end acceptance testing. It can be used for testing distributed, heterogeneous
applications, where verification requires touching several technologies and interfaces.
i). Features
 Enables easy-to-use tabular syntax for creating test cases in a uniform way.
 Provides ability to create reusable higher-level keywords from the existing keywords.
 Provides easy-to-read result reports and logs in HTML format.
 Is platform and application independent.
 Supports creating data-driven test cases.
 Has built-in support for variables, practical particularly for testing in different
environments.
 Provides tagging to categorize and select test cases to be executed.
 Provides test-case and test-suite -level setup and teardown.
ii). Architecture
Robot Framework is a generic, application and technology independent framework. It has a
architecture illustrated in the diagram below.
The test data is in simple, easy-to-edit tabular format. When Robot Framework is started, it
processes the test data, executes test cases and generates logs and reports.
iii). File Structure
 Test cases are created in test case files or simply written in a test suite. A test suite
file consists of various test cases.
 A test case file automatically creates a test suite containing the test cases in that
file.
 A directory containing test case files forms a higher-level test suite. Such a test
suite directory has suites created from test case files as its sub test suites.

2011ECA1470 Page 25
 A test suite directory can also contain other test suite directories, and this
hierarchical structure can be as deeply nested as needed.
In addition to this, there are:
 Test libraries containing the lowest-level keywords.
 Resource files with variables and higher-level user keywords.
 Also the keywords defined in one resource file can be used in another one.
 There is also a provision to use a common resource file for various test suites.
Automation of LTE Call Flows
i). Need For Automation:
 Repetitive test cases during each build release can be performed.
 Speed up testing to accelerate releases.
 Machines can work 24x7 but humans can‟t.
 Allow testing to happen more frequently.
 Avoids Human Redundancy error.
 Reduce cost of testing by reducing human labour.
 Improve test coverage.
 Ensure consistency.
 Improve reliability of testing.
ii). Robot Framework:
Robot Framework is a Python-based, extensible keyword-driven test automation framework
for end-to-end acceptance testing and acceptance-test-driven development (ATDD). It can be
used for testing distributed, heterogeneous applications, where verification requires touching
several technologies and interfaces.
Why Robot Framework:
 Enables easy-to-use tabular syntax for creating test cases in a uniform way.
 Provides ability to create reusable higher-level keywords from the existing
keywords.
 Provides easy-to-read result reports and logs in HTML format.
 Is platform and application independent.
 Provides a simple library for creating customized libraries which can be
implemented natively with either Python or Java.
 Supports creating data-driven test cases.
 Provides tagging to categorize and select test cases to be executed.
 Enables easy integration with setup.
 Provides test-case and test-suite -level setup and teardown.

2011ECA1470 Page 26
Arrangements of Files and Folders:
Test cases are created in test case files or simply written in a test suite. A test suite file
consists of various test cases. A test case file automatically creates a test suite containing the
test cases in that file. A directory containing test case files forms a higher-level test suite.
Such a test suite directory has suites created from test case files as its sub test suites. A test
suite directory can also contain other test suite directories, and this hierarchical structure can
be as deeply nested as needed. There are test libraries containing the lowest-level keywords,
resource files with variables and higher-level user keywords. Also the keywords defined in
one resource file can be used in another one. There is also a provision to use a common
resource file for various test suites.

2011ECA1470 Page 27
Structure of common resource file
 The other resource files are also included in this file including the Robot Framework
libraries.

2011ECA1470 Page 28
How to run Robot Framework
 On the Robot Framework VM open the RF by ride.py &.
 Following Window will open.

2011ECA1470 Page 29
 Go to file menu and select open directory.

2011ECA1470 Page 30
 Select the directory from where you want to run the test cases.

2011ECA1470 Page 31
 After selecting directory, select the automation suite you want to run.
 You can either run the complete suite or can run test cases with particular tags. To
run test cases select the test cases and press Start.

2011ECA1470 Page 32
 You will view the events that are occurring in following window. From here you
can debug the test cases whether they are running properly or not.

2011ECA1470 Page 33
 After the execution of test cases the Report and Log files are generated at the
/tmp/ directory of Robot Framework VM.
 Report and the log files having html format can be viewed on your browser
window.
Report:

2011ECA1470 Page 34
Logs:
 You can debug test failure causes through these logs.

2011ECA1470 Page 35
SAMPLE TEST SUITE FOR ATTACH TEST CASES
*** Settings ***
Suite Setup Open connection and login to ng4t
Suite Teardown Shutdown Ng4t
Resource automation-suite-common-resources.txt
Library BuiltIn
Library OperatingSystem
*** Test Cases ***
Execute Imsi Attach
[Documentation] This test procedure verifies successful UE-Initiated E-UTRAN IMSI attach.
[Tags] Sanity Attach Regression
Open connection and login to cli
Open connection and login to seagull
Start Seagull start_server.sh
Open connection and login to Gx-Sim
Start Gx-Sim start-Sim-Initial-Gx
Sleep 11 sec
Open connection and login to mme
Start Trace attachImsi.txt
Switch Connection NG4T
Check S1ap Setup
Clear Ng4t Stats
Execute Test Case tc_6_1_1
Capture And Verify Stat Nas Output Attach
Switch Connection CLI
Start CLI
Verify Attach By Imsi
${UeIp}= Return UE_IP From CLI
${DpeIp}= Return DPE_IP From CLI

2011ECA1470 Page 36
Leave CLI
Open connection and login to PDN_VM
Write ping ${UeIp} -c 5
Sleep 8 sec
${Ping-Result}= Read
Should Match Regexp ${Ping-Result} .*5 packets transmitted, 5 received, 0% packet loss.*
Switch Connection NG4T
End Test Execution
Capture And Verify Stat Nas Output Detach
Switch Connection CLI
Start CLI
Verify Detach By Imsi
Leave CLI
Switch Connection MME
Stop Trace
Validate IE filehandling1.pl fileOut.txt
Switch Connection SEAGULL
Stop Seagull
Switch Connection GX-SIM
Stop Gx-Sim
[Teardown] Cancel Test Execution

2011ECA1470 Page 37
SAMPLE COMMON RESOURCE FILE
*** Settings ***
Library SSHLibrary
Library BuiltIn
Library String
Resource automation-suite-detach-resources.txt
Resource automation-suite-s1-setup-s1-reset-resources.txt
Resource automation-suite-idle-mode-resources.txt
Resource automation-suite-handover-resources.txt
Resource automation-suite-serv_req-resources.txt
Resource HA/automation-suite-HA-resources.txt
Resource automation-suite-Gx-Interface-resources.txt
Resource automation-suite-S6a-Interface-resources.txt
*** Variables ***
${NG4T_HOST_IP} 192.168.0.200
${NG4T_USERNAME} installng4t
${NG4T_PASSWORD} ng4t!!
${PROMPT} $
${NG4T_DIR} cd /home/installng4t/enb-sushant/
${TSHARK_DIR} cd /root/wireshark-new/wireshark/
${TRACE_DIR} /home/Automation-Trace/
${PERL_DIR} /home/Automation-Scripts/
${MME_VM_HOST_IP} 192.168.0.103
${MME_VM_USERNAME} root
${MME_VM_PASSWORD} root123
${DPE_VM_HOST_IP} 192.168.0.105
${DPE_VM_USERNAME} root
${DPE_VM_PASSWORD} root123
${SC1_VM_HOST_IP} 192.168.0.101

2011ECA1470 Page 38
${SC1_VM_USERNAME} root
${SC1_VM_PASSWORD} root123
${SC2_VM_HOST_IP} 192.168.0.102
${SC2_VM_USERNAME} root
${SC2_VM_PASSWORD} nitish123
${PL3_VM_HOST_IP} 192.168.0.103
${PL3_VM_USERNAME} root
${PL3_VM_PASSWORD} root123
${PL5_VM_HOST_IP} 192.168.0.105
${PL5_VM_USERNAME} root
${PL5_VM_PASSWORD} root123
Open connection and login to SC1
Open Connection ${SC1_VM_HOST_IP} prompt=# alias=SC1
Login ${SC1_VM_USERNAME} ${SC1_VM_PASSWORD}
Open connection and login to SC2
Open Connection ${SC2_VM_HOST_IP} prompt=# alias=SC2
Login ${SC2_VM_USERNAME} ${SC2_VM_PASSWORD}
Open connection and login to PL3
Open Connection ${PL3_VM_HOST_IP} prompt=# alias=PL3
Login ${PL3_VM_USERNAME} ${PL3_VM_PASSWORD}
Open connection and login to PL5
Open Connection ${PL5_VM_HOST_IP} prompt=# alias=PL5
Login ${PL5_VM_USERNAME} ${PL5_VM_PASSWORD}

2011ECA1470 Page 39
SAMPLE RESOURCE FILE FOR ATTACH TEST CASES
*** Settings ***
Library SSHLibrary
Library BuiltIn
Library String
Resource automation-suite-idle-mode-resources.txt
*** Keywords ***
Return UE_AMBR_DL From CLI
Write show subscriber imsi ${IMSI}
Sleep 2 sec
${UE_AMBR_Verify}= Read
${UE_AMBR}= Get Lines Containing String ${UE_AMBR_Verify} UE AMBR DL/UE AMBR UL
${UE_AMBR}= Fetch From Right ${UE_AMBR} :
${UE_AMBR_DL}= Fetch From Left ${UE_AMBR} /
[Return] ${UE_AMBR_DL}
Return UE_AMBR_UL From CLI
Sleep 2 sec
${UE_AMBR_Verify}= Read
${UE_AMBR}= Get Lines Containing String ${UE_AMBR_Verify} UE AMBR DL/UE AMBR UL
${UE_AMBR}= Fetch From Right ${UE_AMBR} :
${UE_AMBR_UL}= Fetch From Right ${UE_AMBR} /
[Return] ${UE_AMBR_UL}
Return APN_AMBR_DL From CLI
Sleep 2 sec
${APN_AMBR_Verify}= Read
${APN_AMBR}= Get Lines Containing String ${APN_AMBR_Verify} APN AMBR DL/APN AMBR UL

2011ECA1470 Page 40
${APN_AMBR}= Fetch From Right ${APN_AMBR} :
${APN_AMBR_DL}= Fetch From Left ${APN_AMBR} /
[Return] ${APN_AMBR_DL}
Return APN_AMBR_UL From CLI
Sleep 2 sec
${APN_AMBR_Verify}= Read
${APN_AMBR}= Get Lines Containing String ${APN_AMBR_Verify} APN AMBR DL/APN AMBR UL
${APN_AMBR}= Fetch From Right ${APN_AMBR} :
${APN_AMBR_UL}= Fetch From Right ${APN_AMBR} /
[Return] ${APN_AMBR_DL}
Return ERAB_ID From CLI
Sleep 2 sec
${ERAB_ID_Verify}= Read
${ERAB_ID}= Get Lines Containing String ${ERAB_ID_Verify} Bearer-type/Bearer-id
${ERAB_ID}= Fetch From Right ${ERAB_ID} /
[Return] ${ERAB_ID}
Return QOS From CLI
Sleep 2 sec
${QOS_Verify}= Read
${QOS}= Get Lines Containing String ${QOS_Verify} QCI/ARP
${QOS}= Fetch From Right ${QOS} :
${QCI}= Fetch From Left ${QOS} /
[Return] ${QCI}
Return AUTH-VECTOR-RAND From S6a
Write cat /home/Automation-Scripts/fileOutAuthVectorsMatch.txt
${AUTH_Verify}= Read

2011ECA1470 Page 41
${RAND}= Get Lines Containing String ${AUTH_Verify} RAND
${RAND}= Fetch From Right ${RAND} :
[Return] ${RAND}
Return AUTH-VECTOR-AUTN From S6a
${AUTN}= Get Lines Containing String ${AUTH_Verify} AUTN
${AUTN}= Fetch From Right ${AUTN} :
[Return] ${AUTN}
Return AUTH-VECTOR-XRES From S6a
${XRES}= Get Lines Containing String ${AUTH_Verify} XRES
${XRES}= Fetch From Right ${XRES} :
[Return] ${XRES}

2011ECA1470 Page 42
iii). TShark
TShark is a network protocol analyser. It lets you capture packet data from a live network, or
read packets from a previously saved capture file, either printing a decoded form of those
packets to the standard output or writing the packets to a text file. We can apply checks on
this file for testing purpose to verify that the AVP‟s or IE‟s that are being exchanged are right
or wrong.
 TShark is able to detect, read and write the same capture files that are supported
by Wireshark.
 Tshark can be used with various packet filters. This is very helpful if want to
capture the packets for some specific protocols only.
 Tshark is excellent tool for testing the AVP‟s or IE‟s transferred among the nodes.
 Tshark also provides an option to specify the packet filter and interface on which
you want to capture the packets.
 Tshark can be run from the terminal using following command
tshark -f ${protocol} -V > ${TRACE_DIR}${filename}
This command provides tester to capture the packets by applying the desirable packet filter
and save the output to the file.
Example:
 For dumping the output in a file use following :

2011ECA1470 Page 43
iv). PERL Scripts:
For verifying the AVPs or IEs that are captured in trace using the tshark utility, perl scripts
were created and integrated with Robot Framework. These scripts are placed on those VMs
where the trace is being captured under the directory /home/Automation-Scripts/. All the
scripts were placed at the VMs according to the functionality of component running on that
VM. These scripts uses the captured traces at input and generates an output file in result.
 These perl scripts checked the values of the AVPs and IEs captured using the
tshark and passes the results to the output file from where Robot framework reads
the final results and carry out the final testing of value and looks for the keyword
“PASS” in this output file.
 If the Robot Framework is able to find “PASS” it precedes or if it is unable to find
“PASS” it just fails the test case.
 We can debug the reason of failure from the output file.
SAMPLE OUTPUT FILE
Message : Attach request (0x41)
Procedure Code : id-initialUEMessage (12)
ENB-UE-S1AP ID : 0
Tracking area code same in Attach Request and Attach Accept
TAC: 000d
MCC : Croatia (Republic of) (219)
MNC : VIPnet/VIPnet d.o.o. (10)
RRC-Establishment-Cause : mo-Signalling (3)
Protocol Discriminator : EPS mobility management messages (7)
EPS attach type : EPS attach (1)
Request type : Initial request (1)
Type of identity : IMSI (1)
Procedure Transaction Identity : 1
PDN Type : IPv4 (1)
###########################################################
Message : Authentication request (0x52)

2011ECA1470 Page 44
RAND value: b5598b014f670ad37d8c5d95010092d2
AUTN value: f47647ebdb378000f68c3a7c0a3ec05f
MME-UE-S1AP ID : 573121053
###########################################################
Message : Authentication response (0x53)
RES: 16d4e737e9abdd1a
###########################################################
Message : Security mode command (0x5d)
UE security capabilities and UE network capabilities are same.
GPRS encryption algorithm GEA1: Supported
GPRS encryption algorithm GEA2: Supported
###########################################################
Message : Security mode complete (0x5e)
###########################################################
Message : Attach accept (0x42)
UE-AMBR DL : 1500
UE-AMBR UL : 1500
APN-AMBR DL : 14 kbps
APN-AMBR UL : 4 kbps
e-RAB-ID : 5
QCI : 5
gTP-TEID : 01000000
Transport Layer Address= 192.168.100.211
Attach Result : EPS only (1)
PDN Type : IPv4 (1)
PDN IP Address : 172.16.100.3
Type of identity : GUTI (6)
ID UESecurity Capability : (107)
Encryption Algorithm : c000
Integrity Protection Algorithm : c000
ID Security Key : (73)
##########################################################

2011ECA1470 Page 45
=================================================
IE Value
=================================================
=================================================
IMSI 219104567891230
ATTACH TYPE EPS attach (1)
PDN TYPE IPv4 (1)
MCC Croatia (Republic of) (219)
MNC VIPnet/VIPnet d.o.o. (10)
TAC
QCI QCI 5 (5)
UE AMBR :
Downlink 1500
Uplink 1500
APN AMPR :
Downlink 14 kbps
Uplink 4 kbps
S1AP ID :
ENB UE S1AP ID 0
MME UE S1AP ID 573121053
GUTI
TRANS ADDR 192.168.100.211
GTP TE ID 01000000
ERABID 5
Internet Protocol Version 4
=================================================
RESULT PASS
=================================================

2011ECA1470 Page 46
Policy and Charging Control (PCC)
i). PCC Architecture
Policy Control and Charging (PCC) functionality comprises of Policy and Charging Rules
Function (PCRF), Policy and Charging Enforcement Function (PCEF), Serving Gateway,
Online Charging System (OCS), Offline Charging System (OFCS) and Subscription Profile
Repository (SPR). These functional entities are shown in Figure with their logical reference
points.
ii). PCC Rules and its Purposes
The purpose of the PCC rule is-
 to detect a packet belonging to an SDF to map that packet to proper IP-CAN bearer in
downlink and uplink direction
 to identify the service
 to provide appropriate applicable charging
 to provide policy control
There are 2 different types of PCC rules -
 Dynamic PCC rules - These PCC rules are dynamically provisioned by PCRF to
PCEF over Gx interface.
 Pre-defined PCC rules - These PCC rules are pre-configured in the PCEF. The PCRF
can advise the PCEF to activate a set of PCC rules over Gx interface.
A PCC rules consists of -
1. a rule name - the rule name is used to reference a PCC rule during communication
between PCRF and PCEF
2. service identifier - the service identifier is used to identify a service or service
component the SDF relates to
3. SDF filter(s) - the SDF filters are used to select the traffic for which the rule applies

2011ECA1470 Page 47
4. precedence - order of the SDF filter; dynamic rule takes precedence over pre-defined
rule in case of same precedence
5. gate status - whether the SDF detected should be allowed to pass or blocked
6. QoS parameters - includes the QCI, the ARP and bitrates for uplink and downlink
7. charging key and charging parameters - online or offline charging
8. monitoring key - identifies a monitoring control instance that shall be used for usage
monitoring control of the SDFs
The Subscription Profile Repository (SPR) contains subscriber/subscription
information. This information is per-PDN basis and includes-
 Subscriber's allowed services
 Information on subscriber's allowed QoS (MBR and GBR)
 Subscriber's charging related information
 Subscriber category
The Sp reference point resides between SPR and PCRF. It allows the PCRF to request
subscription information related to a subscriber's service/session.
The Online Charging System (OCS) is a credit management system for pre-paid charging.
Within OCS lies a functional entity called Service Data Flow Based Credit Control Function
which performs online credit control function. The PCEF interacts with OCS to check out
credit and report credit status over Gy interface.
The Offline Charging System (OFCS) is used for offline charging. The OFCS receives
charging events from PCEF over Gz interface and generates Charging Data Records (CDRs)
which are sent to the billing system.

2011ECA1470 Page 48
PCRF Simulator:
i). Seagull
Seagull is a free, Open Source multi-protocol traffic generator test tool. Seagull is a powerful
traffic generator for functional and performance tests for almost any kind of protocol.
Seagull comes with several protocol families embedded in the source code:
 Binary/TLV (Diameter, Radius and many 3GPP and IETF protocols)
 External library (TCAP, SCTP)
 Text (XCAP, HTTP, H248 ASCII)
Protocols are then implemented on top of those protocol families using user editable XML
dictionaries. Those dictionaries describe how messages and parameters are encoded,
allowing a great flexibility.
A Seagull scenario - written in XML - describes the messages that are sent and received. It
also indicate the behaviour to adopt if a message is unexpected or a check on a parameter
fails.
Seagull supports currently the following protocols:
 Diameter over IPv4
 HTTP over IPv4
 Radius (subset) over IPv4.
Seagull has the following features:
 Multi-protocol traffic generator.
 Protocols of the same family are described in an XML, user editable, dictionary
(messages, parameters).
 Support of IP (UDP/TCP), SCTP, SSL/TLS and SS7/TCAP transports.
 Portable programming (tested and supported on Linux and Windows).
 Scenarios are described using XML files.
 Multi-threaded for performances and reliability.
 Dynamically adjustable scenario rate.
 Pause and restart of traffic.
 Smooth (no new scenarios then wait for on-going scenarios to end) or brutal end.
 Scenario display with message counters.
 Message and parameters checking possible.
 Multiple Seagull instances can be synchronized in the middle of scenario.
 Statistics: timer between two messages, scenario length, scenario rate, successful
scenarios, failed scenarios (with reason).

2011ECA1470 Page 49
ii). Implementation
 Dictionary: To design a PCRF simulator the messages that are being exchanged
between the PCRF and PCEF need to added into the dictionary file that is situated at
the path /opt/seagull/diameter-pcrf/config/ named as base_cc.xml.
Also the various Attribute Value Pairs (AVPs) that are being sent or received by
PCRF are defined in this dictionary. In the definition we give the AVP code, Flag,
Type, Vendor ID if the AVP is vendor specific. This is necessary so that seagull can
interpret the message. Each and every AVP that is sent or received has to defined in
this file otherwise the Seagull will generate a error message of Unknown AVP code.
 Scenario: There are various scenario files that are present under the directory
/opt/seagull/diameter-pcrf/scenario/. Each scenario files consists of the message
sequence i.e. it tells which message to send when it receives a message from PCEF. If
it receives Capabilities Exchange Request (CER) then in response it will send
Capabilities Exchange Answer (CEA). We could even restore some AVPs from the
received message and send them along with PCRF message. Also other functions like
Event Triggers, Charging Rules Install/Remove can be sent from PCRF.
 Run: There are various scripts to run Seagull under directory /opt/seagull/diameter-
pcrf/run/. From here you can call any of the desired Scenario file according to the
requirement.
iii). Wrapper Code to Run PCRF Simulator:
For starting various Run scripts recursively and effectively a wrapper code in python script
naming pcrf.py placed in directory /opt/seagull/diameter-pcrf/run/ is written. This script is
executed using 2 arguments, python file name IP address of the server. Whenever the python
script is run the following menu appears:

2011ECA1470 Page 50
First of all it checks whether the entered IP address is valid IP address or not. If it is
valid the script writes this IP address in the file conf.server.xml under the directory
/opt/seagull/diameter-pcrf/run/.
After IP is written to file the menu appears listing the 5 choices of Event-Triggers,
Charging-Rules, RAR, Soak-and-Performance and Exit.
 Event-Triggers :
You can configure triggers on the policy and charging enforcement function (PCEF)
so that the PCEF notifies the policy and charging enforcement function (PCRF) about
changes in access network. By default, the PCEF enables any event triggers that are
received from the PCRF in a Credit Control Answer (CCA) or Re-Authorization
Request (RAR) message. When you configure event triggers on the PCEF, the PCEF
adds these PCEF configured event triggers to the PCRF provisioned event triggers.
The supported event triggers are listed when choice 1 is selected:
From here we can select the event trigger that are to be send by the PCRF in Credit Control
Answer (CCA) – Update.
Suppose you select the choice 1 i.e. TAI-CHANGE, then this event trigger will be
triggered in CCA-Update and following screen will appear:

2011ECA1470 Page 51
Choose „y‟(Yes) if you want to continue or if you want to enter another choice choose
„n‟(No).
After you choose „y‟, the PCRF simulator starts and following screen appears :

2011ECA1470 Page 52
You can also view which messages are being exchanged over Gx interface by
pressing „3‟.
For exit press „Esc‟ from keyboard. You can also press „q‟ for it.
After exit the PCRF simulator screen appears and you can even choose another
options too.
You can get back to the previous menu by selecting the Exit option.
 Charging-Rules:
If you want to install or remove the charging rule then select the second choice from
the main menu.
The following sub-menu is displayed:
If you want to install the charging rule select 1 or if you want to remove the installed
rule select 2.
After this the PCRF simulator will run and PCRF will send the CCA-Update in which
Charging Rule Install/Remove AVP will be present asking the VCM to
Install/Remove the charging Rule.

2011ECA1470 Page 53
 (Re-Auth Request) RAR :
If After the connection establishment i.e. CER/CEA if PCRF wants to send any of the
Event-Trigger or Charging-Rule it will send it through RAR.
For running RAR we have to select the choice 3 from the main menu and then run the
PCRF simulator.
 Soak-and-Performance:
If one wants to perform various test cases like that of Soak and performance where no
event trigger or charging rule provisioning is required, then choice 4 is appropriate
one. It will run PCRF simulator.
 EXIT
To exit from the PCRF simulator choose the choice 5.
WRAPPER CODE
#!/usr/bin/python
import ConfigParser
import subprocess
import os
Choice = 0
Choices = 0
Choicess = 0
config = ConfigParser.ConfigParser()
config.read('/opt/seagull/diameter-pcrf/run/pcrf.ini')
print "**************************************************************"
print "* PCRF-Simulator *"
print "**************************************************************"
print "Kindly Enter your Choice."
print "1.","EVENT-TRIGGERS",config.get("SECTIONS", "EVENT-TRIGGERS")

2011ECA1470 Page 54
print "2.","CHARGING-RULES",config.get("SECTIONS", "CHARGING-RULES")
print "3.","RAR",config.get("SECTIONS", "RAR")
feature = raw_input("Enter Your Choice:")
for i in range(0,50):
if (feature == '1'or feature == '2'or feature == '3'):
break
elif (feature == "" ):
feature = raw_input("Please Enter Choice:")
else:
print "Wrong Choice"
feature = raw_input("Enter Choice:")
if feature == '1':
print "SUPPORTED EVENT TRIGGERS"
print "1.","TAI-CHANGE","(",config.get("EVENT-TRIGGERS", "TAI-CHANGE"),")"
print "2.","ECGI-CHANGE","(",config.get("EVENT-TRIGGERS", "ECGI-CHANGE"),")"
print "3.","DEFAULT-EPS-BEARER-QoS-CHANGE","(",config.get("EVENT-TRIGGERS", "DEFAULT-EPS-BEARER-
QOS-CHANGE"),")"
print "4.","OUT-OF-CREDIT","(",config.get("EVENT-TRIGGERS", "OUT-OF-CREDIT"),")"
print "5.","USAGE-REPORT","(",config.get("EVENT-TRIGGERS", "USAGE-REPORT"),")"
print "6.","NO-EVENT-TRIGGER","(",config.get("EVENT-TRIGGERS", "NO-EVENT-TRIGGER"),")"
print "7.","QoS-Change","(",config.get("EVENT-TRIGGERS", "QOS-CHANGE"),")"
print "8.","REVALIDATION-TIMEOUT","(",config.get("EVENT-TRIGGERS", "REVALIDATION-TIMEOUT"),")"
Choice = raw_input("Enter Your Choice:")
for j in range(0,50):
if (Choice == '1' or Choice == '2' or Choice == '3' or Choice == '4' or Choice == '5' or Choice == '6' or Choice ==
'7'or Choice == '8'):
break
elif (Choice == "" ):
Choice = raw_input("Please Enter Choice:")
else:
Choice = raw_input("Enter Correct Choice:")

2011ECA1470 Page 55
print "you entered ", Choice
print config.get("SCENARIO-EVENT-TRIGGERS", Choice)
print "Do You Want To Continue (y/n)"
var = raw_input("(y/n):")
elif feature == '2':
print "1.","CHARGING-RULE-INSTALL","(",config.get("CHARGING-RULES", "CHARGING-RULE-INSTALL"),")"
print "2.","CHARGING-RULE-REMOVE","(",config.get("CHARGING-RULES", "CHARGING-RULE-REMOVE"),")"
Choices = raw_input("Enter Your Choice:")
for k in range(0,50):
if (Choices == '1' or Choices == '2'):
break
elif (Choices == "" ):
Choices = raw_input("Please Enter Choice:")
else:
Choices = raw_input("Enter Correct Choice:")
print "you entered ", Choices
print config.get("SCENARIO-CHARGING-RULES", Choices)
elif feature == '3':
print "1.","RAR",config.get("RAR", "RAR")
Choicess = raw_input("Enter Your Choice:")
for l in range(0,50):
if (Choicess == '1'):
break
elif (Choicess == "" ):
Choicess = raw_input("Please Enter Choice:")
else:
Choicess = raw_input("Enter Correct Choice:")
print "you entered ", Choicess
print config.get("SCENARIO-RAR", Choicess)

2011ECA1470 Page 56
if var == 'y':
if Choice == '1':
os.system("./start_server_TAI_Change_cc.sh")
os.system("./pcrf.py")
elif Choice == '2':
os.system("./start_server_ECGI_Change_cc.sh")
elif Choice == '3':
os.system("./start_server_Default_EPS_Bearer_QoS_Change_cc.sh")
elif Choice == '4':
os.system("./start_server_Out_Of_Credit_cc.sh")
elif Choice == '5':
os.system("./start_server_Usage_Report_cc.sh")
elif Choice == '6':
os.system("./start_server_No_Event_Trigger_cc.sh")
elif Choice == '7':
os.system("./start_server_QoS_Change_cc.sh")
elif Choice == '8':
os.system("./start_server_Revalidation_Timeout_cc.sh")
elif Choices == '1':
os.system("./start_server_Charging_Rule_Install_cc.sh")
elif Choices == '2':
os.system("./start_server_Charging_Rule_Remove_cc.sh")

2011ECA1470 Page 57
elif Choicess == '1':
os.system("./start_server_RAR_cc.sh")
elif var == 'n':
exit
else:
exit

2011ECA1470 Page 58
Bibliography
Books:
1. SAE and Evolved Packet Core – Magnus Olsson
2. From GSM to LTE – Martin Sauter
3. Unix Concepts and Applications – Sumitabha Das
Online Reference:
1. http://www.stackoverflow.com/
2. http://www.netmanias.com/
3. http://www.tutorialspoint.com/python/
4. https://sites.google.com/site/amitsciscozone/home/lte-notes/pcc-architecture
5. http://robotframework.org/robotframework/#user-guide
6. http://www.lteandbeyond.com/2012/01/lte-attach-procedure.html/

Sushant_Project_Report

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Sushant_Project_Report

Semelhante a Sushant_Project_Report (20)

Sushant_Project_Report