em

Introduction to LTE, Technology Background, and Previous

Telecom Technologies
Day 1

Cellular Network Basics

Cellular network/telephony is a radio-based technology; radio waves are electromagnetic waves that
antennas propagate. Most signals are in the 850 MHz, 900 MHz, 1800 MHz, and 1900 MHz frequency
bands.

Cellular Network

• Base stations transmit to and receive from mobiles at the assigned spectrum.
• Multiple base stations use the same spectrum (spectral reuse).
• The service area of each base station is called a cell.
• Each mobile terminal is typically served by the ‘closest’ base stations.
• Hand off when terminals move.

4
em

Cellular Network Generations

It is useful to think of cellular Network/telephony in terms of generations:

• 0G: Briefcase-size mobile radio telephones

• 1G: Analog cellular telephony
• 2G: Digital cellular telephony
• 3G: High-speed digital cellular telephony (including video telephony)
• 4G: IP based “anytime, anywhere” voice, data, and multimedia telephony at faster data rates than
3G (deployments started in 2012–2015)

The Multiple Access Problem

• The base stations need to serve many mobile terminals at once (both downlink and uplink).
• All mobiles in the cell need to transmit to the base station.
• Interference among different senders and receivers.
• So we need multiple access schemes.

5
em

Multiple Access Schemes

Three orthogonal Schemes:

• Frequency Division Multiple Access (FDMA)

• Time Division Multiple Access (TDMA)
• Code Division Multiple Access (CDMA)

Frequency Division Multiple Access

• Each mobile is assigned a separate frequency channel for the duration of the call.
• Sufficient guard band is required to prevent adjacent channel interference.
• Usually, mobile terminals will have one downlink frequency band and one uplink frequency band.
• Different cellular network protocols use different frequencies.
• Frequency is a precious and scare resource. We are running out of it.
• Cognitive radio

6
em

Time Division Multiple Access

• Time is divided into slots and only one mobile terminal transmits during each slot.
• Each user is given a specific slot. No competition in cellular network.
• Unlike Carrier Sensing Multiple Access (CSMA) in Wi-Fi.

Code Division Multiple Access

• Use of orthogonal codes to separate different transmissions.

• Each symbol of bit is transmitted as a larger number of bits using the user specific code –
Spreading.
• Bandwidth occupied by the signal is much larger than the information transmission rate, but all
users use the same frequency band together.

7
em

2G (GSM)

• Abbreviation for Global System for Mobile Communications.

• Concurrent development in USA and Europe in the 1980s.
• The European system was called GSM and deployed in the early 1990s.

GSM Channels

• Physical Channel: Each time slot on a carrier is referred to as a physical channel.

• Logical Channel: Variety of information is transmitted between the MS and BTS.
• Different types of logical channels: Traffic Channel and Control Channel.

GSM Frequencies

• Originally designed on 900 MHz range, now also available on 800 MHz, 1800 Mhz, and 1900 MHz
ranges.
• Separate Uplink and Downlink frequencies.
• One example channel on the 1800 MHz frequency band, where RF carriers are spaced every 200
MHz.

8
em

GSM Architecture

Mobile Station (MS)

• MS is the user’s handset and has two parts.

• Mobile Equipment
• Radio equipment
• User interface
• Processing capability and memory required for various tasks
• Call signaling
• Encryption
• SMS
• Equipment IMEI number
• Subscriber Identity Module

9
em

Subscriber Identity Module

• A small smart card.

• Encryption codes needed to identify the subscriber.
• Subscriber IMSI number.
• Subscriber’s own information (telephone directory).
• Third party applications (banking, etc.).
• Can also be used in other systems besides GSM, e.g., some WLAN access points accept SIM based
user authentication.

Base Station Subsystem

• Transcoding Rate and Adaptation Unit (TRAU)

• Performs coding between the 64 kbps PCM coding used in the backbone network
and the 13 kbps coding used for the Mobile Station (MS).
• Base Station Controller (BSC)
• Controls the channel (time slot) allocation implemented by the BTSs.
• Manages the handover within BSS area.
• Knows which mobile stations are within the cell and informs the MSC/VLR about
this.
• Base Transceiver System (BTS)
• Controls several transmitters.
• Each transmitter has 8 time slots, some used for signaling, on a specific frequency.

10
em

Network and Switching Subsystem

• The backbone of a GSM network is a telephone network with additional cellular network
capabilities.
• Mobile Switching Center (MSC)
• A typical telephony exchange (ISDN exchange) which supports mobile
communications.
• Visitor Location Register (VLR)
• A database, part of the MSC.
• Contains the location of the active Mobile Stations.
• Gateway Mobile Switching Center (GMSC)
• Links the system to PSTN and other operators.
• Home Location Register (HLR)
• Contains subscriber information, including authentication information in
Authentication Center (AuC).
• Equipment Identity Register (EIR)
• International Mobile Station Equipment Identity (IMEI) codes for blacklisting stolen
phones, etc.

Home Location Register

• One database per operator.

• Contains all the permanent subscriber information.
• MSISDN (Mobile Subscriber ISDN number) is the telephone number of the
subscriber.
• International Mobile Subscriber Identity (IMSI) is a 15 digit code used to identify
the subscriber.
• It incorporates a country code and operator code.
• IMSI code is used to link the MSISDN number to the subscriber’s SIM (Subscriber
Identity Module).
• Charging information.
• Services available to the customer.
• Also the subscriber’s present Location Area Code, which refers to the MSC, which can connect to
the MS.

11
em

Other Systems

• Operations Support System

• The management network for the whole GSM network.
• Usually vendor dependent.
• Very loosely specified in the GSM standards.
• Value added services
• Voice mail.
• Call forwarding.
• Group calls.
• Short Message Service Center
• Stores and forwards the SMS messages.
• Like an E-mail server.
• Required to operate the SMS services.

Location Updates

• The cells overlap and usually a mobile station can ‘see’ several transceivers (BTSs).
• The MS monitors the identifier for the BSC controlling the cells.
• When the mobile station reaches a new BSC’s area, it requests a location update.
• The update is forwarded to the MSC, entered into the VLR, the old BSC is notified, and an
acknowledgment is passed back.

Handoff (Handover)

• When a call is in process, the changes in location need special processing.

• Within a BSS, the BSC, which knows the current radio link configuration (including feedback from
the MS), prepares an available channel in the new BTS.
• The MS is told to switch over to the new BTS.
• This is called a hard handoff.
• In a soft handoff, the MS is connected to two BTSs simultaneously.

12
em

Roaming

• When a MS enters another operators network, it can be allowed to use the services of this operator.
• Operator to operator agreements and contracts.
• Higher billing.
• The MS is identified by the information in the SIM card and the identification request is forwarded
to the home operator.
• The home HLR is updated to reflect the MS’s current location.

GSM Services

• Voice, 3.1 kHz.

• Short Message Service (SMS) – 1985 GSM standard that allows messages of maximum 160
characters (including spaces) to be sent between handsets and other stations.
• Over 2.4 billion people use SMS; multi-billion dollar industry.
• General Packet Radio Service (GPRS)
• GSM upgrade that provides IP-based packet data transmission at up to 114 kbps.
• Users can “simultaneously” make calls and send data.
• GPRS provides “always on” internet access and the Multimedia Messaging Service
(MMS) whereby users can send rich text, audio, video messages to each other.
• Performance degrades as number of users increase.
• GPRS is an example of 2.5G telephony – 2G service similar to 3G.

13
em

Evolution from 2G

Service Roadmap

14
em

GSM Evolution to 3G

UMTS

• Universal Mobile Telecommunications System (UMTS).

• UMTS is an upgrade from GSM via GPRS or EDGE.
• The standardization work for UMTS is carried out by Third Generation Partnership Project (3GPP).
• Data rates of UMTS are:
• 144 kbps for rural
• 384 kbps for urban outdoor
• 2048 kbps for indoor and low range outdoor
• Virtual Home Environment (VHE).

15
em

UMTS Frequency Spectrum

UMTS Band:

• 1900-2025 MHz and 2110-2200 MHz for 3G transmission.

• In the US, 1710–1755 MHz and 2110–2155 MHz will be used instead, as the 1900 MHz band was
already used.

UMTS Architecture

16
em

UMTS network architecture consists of three domains:

• Core Network (CN): Provide switching, routing, and transit for user traffic.
• UMTS Terrestrial Radio Access Network (UTRAN): Provides the air interface access method for
user equipment.
• User Equipment (UE): Terminals work as air interface counterpart for base stations. The various
identities are: IMSI, TMSI, P-TMSI, TLLI, MSISDN, IMEI, IMEISV.

UTRAN

• Wide band CDMA technology is selected for UTRAN air interface.

• WCDMA
• TD-SCDMA
• Base stations are referred to as Node-B and control equipment for Node-B is called Radio Network
Controller (RNC).
• Functions of Node-B are
• Air Interface Tx/Rx
• Modulation/Demodulation
• Functions of RNC are:
• Radio Resource Control
• Channel Allocation
• Power Control Settings
• Handover Control
• Ciphering
• Segmentation and reassembly

3.5G (HSPA)

• High Speed Packet Access (HSPA) is an amalgamation of two mobile telephony protocols, High
Speed Downlink Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA), that
extends and improves the performance of existing WCDMA protocols.
• 3.5G introduces many new features that will enhance the UMTS technology in future. 1xEV-DV
already supports most of the features that will be provided in 3.5G. These include:
• Adaptive Modulation and Coding
• Fast Scheduling
• Backward compatibility with 3G
• Enhanced Air Interface

17
em

4G (LTE)

• LTE stands for Long Term Evolution.

• Next Generation mobile broadband technology.
• Promises data transfer rates of 100 Mbps.
• Based on UMTS 3G technology.
• Optimized for All-IP traffic.

Comparison of LTE Speed

18
em

Major LTE Radio Technologies

• Uses Orthogonal Frequency Division Multiplexing (OFDM) for downlink.

• Uses Single Carrier Frequency Division Multiple Access (SC-FDMA) for uplink.
• Uses Multi-input Multi-output(MIMO) for enhanced throughput.
• Reduced power consumption.
• Higher RF power amplifier efficiency (less battery power used by handsets).

LTE Architecture

19
em

LTE versus UMTS

Functional changes compared to the current UMTS architecture.

MME functions

• NAS signaling.
• NAS signaling security.
• Inter CN node signaling for mobility between 3GPP access networks (terminating S3).
• UE Reachability in ECM-IDLE state (including control and execution of paging retransmission).
• Tracking Area list management.
• Mapping from UE location (e.g., TAI) to time zone, and signaling a UE time zone change
associated with mobility.
• PDN GW and Serving GW selection.
• MME selection for handovers with MME change.
• SGSN selection for handovers to 2G or 3G 3GPP access networks.
• Roaming (S6a towards home HSS).
• Authentication.
• Authorization.
• Bearer management functions including dedicated bearer establishment.
• Lawful interception of signaling traffic.
• Warning message transfer function (including selection of appropriate eNodeB).
• UE Reachability procedures.

20
em

SGW Functions

• The local Mobility Anchor point for inter-eNodeB handover.

• Sending of one or more “end marker” to the source eNodeB, source SGSN, or source RNC
immediately after switching the path during inter-eNodeB and inter-RAT handover, especially to
assist the reordering function in eNodeB.
• Mobility anchoring for inter-3GPP mobility (terminating S4 and relaying the traffic between 2G/3G
system and PDN GW).
• ECM-IDLE mode downlink packet buffering and initiation of network triggered service request
procedure.
• Lawful Interception.
• Packet routing and forwarding
• Transport level packet marking in the uplink and the downlink, e.g., setting the DiffServ Code
Point, based on the QCI of the associated EPS bearer.
• Accounting for inter-operator charging. For GTP-based S5/S8, the Serving GW generates
accounting data per UE and bearer.
• Interfacing OFCS according to charging principles and through reference points specified in TS
32.240.

PGW Functions

• Per-user based packet filtering (e.g., by deep packet inspection).

• Lawful Interception.
• UE IP address allocation.
• Transport level packet marking in the uplink and downlink, e.g., setting the DiffServ Code Point,
based on the QCI of the associated EPS bearer.
• Accounting for inter-operator charging.
• UL and DL service level charging as defined in TS 23.203 [6] (e.g., based on SDFs defined by the
PCRF, or based on deep packet inspection defined by local policy).
• Interfacing OFCS according to charging principles and through reference points specified in TS
32.240.
• UL and DL service level gating control as defined in TS 23.203 [6].
• UL and DL service level rate enforcement as defined in TS 23.203 [6] (e.g., by rate
policing/shaping per SDF).

21
em

• DL rate enforcement based on AMBR (e.g., by rate policing/shaping per aggregate of traffic of
SDFs associated with Non-GBR QCIs).
• DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same
GBR QCI (e.g. by rate policing/shaping).
• DHCPv4 (server and client) and DHCPv6 (client and server) functions.
• The network does not support PPP bearer type in this version of the specification. Pre-Release 8
PPP functionality of a GGSN may be implemented in the PDN GW.

22
em

Introduction to LTE Nodes and Polaris Networks Emulators

Day 2

Introduction to LTE Nodes

eNodeB:

The Single E-UTRAN Node: The E-UTRAN OFDM-based structure is quite simple. It is only composed
of one network element – the eNodeB (evolved Node B). The 3G RNC (Radio Network Controller)
inherited from the 2G BSC (Base Station Controller) has disappeared from E-UTRAN and the eNodeB is
directly connected to the Core Network using the S1 interface. As a consequence, the features supported by
the RNC have been distributed between the eNodeB or the Core Network MME or Serving Gateway
entities.

The X2 Interface: A new interface (X2) has been defined between eNodeBs, working in a meshed way
(meaning that all Node Bs may possibly be linked together). The main purpose of this interface is to
minimize packet loss due to user mobility. As the terminal moves across the access network, unsent or
unacknowledged packets stored in the old eNodeB queues can be forwarded or tunneled to the new
eNodeB thanks to the X2 interface. From a high-level perspective, the new E-UTRAN architecture is
actually moving towards WLAN network structures and Wi-Fi or WiMAX Base Stations.

EnodeB Functionalities

• Header compression and user plane ciphering.

• MME selection when no routing to an MME can be determined from the information provided by
the UE.
• UL bearer level rate enforcement based on UE-AMBR and MBR via means of uplink scheduling
(e.g., by limiting the amount of UL resources granted per UE over time).
• DL bearer level rate enforcement based on UE-AMBR.
• UL and DL bearer level admission control.
• Transport level packet marking in the uplink, e.g., setting the DiffServ Code Point, based on the
QCI of the associated EPS bearer.
• ECN-based congestion control.

PGW:

The PDN Gateway is responsible for IP address allocation for the UE, as well as QoS enforcement and
flow-based charging according to rules from the PCRF. It is responsible for the filtering of downlink user
packets into the different QoS-based bearers. This is performed based on Traffic Flow Templates (TFTs).
The PGW performs QoS enforcement for guaranteed bit rate (GBR) bearers. It also serves as the mobility
anchor for interworking with non-3GPP technologies such as CDMA2000 and WiMAX networks.

23
em

SGW:

All user IP packets are transferred through the Serving Gateway, which serves as the local mobility anchor
for the data bearers when the UE moves between eNodeBs. It also retains the information about the bearers
when the UE is in the idle state (known as “EPS Connection Management — IDLE” [ECM-IDLE]) and
temporarily buffers downlink data while the MME initiates paging of the UE to re-establish the bearers. In
addition, the SGW performs some administrative functions in the visited network such as collecting
information for charging (for example, the volume of data sent to or received from the user) and lawful
interception. It also serves as the mobility anchor for interworking with other 3GPP technologies such as
general packet radio service (GPRS) and UMTS.

MME:

The Mobility Management Entity is the control node that processes the signaling between the UE and the
CN. The protocols running between the UE and the CN are known as the Non Access Stratum (NAS)
protocols.

PCRF:

The Policy Control and Charging Rules Function is responsible for policy control decision making, and for
controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF),
which resides in the PGW. The PCRF provides the QoS authorization (QoS class identifier [QCI] and bit
rates) that decides how a certain data flow will be treated in the PCEF and ensures that this is in
accordance with the user’s subscription profile.

HSS:

The Home Subscriber Server contains the users’ SAE subscription data such as the EPS-subscribed QoS
profile and any access restrictions for roaming. It also holds information about the PDNs to which users
can connect. This could be in the form of an access point name (APN – which is a label according to DNS
naming conventions describing the access point to the PDN) or a PDN address (indicating subscribed IP
addresses). In addition, the HSS holds dynamic information such as the identity of the MME to which the
user is currently attached or registered. The HSS may also integrate the authentication center (AUC),
which generates the vectors for authentication and security keys.

24
em

Polaris Networks LTE Emulators

LTE Emulators

• Polaris Networks Emulators for eNodeB, MME, SGW, PGW, HSS, PCRF are software based tools,
using which an end-to-end LTE network can be simulated using a single PC.
• Implemented as FSM, so that the Emulator can be used in place of real LTE equipment in a lab
testing environment.
• Supports standard LTE features and operations (Attach, Detach, Default/Dedicated Bearer,
Handover, etc.) to test eNodeB, MME, SGW, PGW for completeness of feature implementation.
• User friendly GUI; also includes scripting API for test automation.
• Capable of handling high data loads from external traffic generators.
• Can be used for testing Failure scenarios.

eNodeB Emulator

• eNodeB Implementation designed for lab use and for testing UE, eNodeB, MME, SGW, and inter-
RAT handovers with SGSN.
• Implemented on Linux; code is written in ISO C and is designed to be easily portable.
• Provides a Tcl interface to configure, control, and monitor the emulated eNodeB.
• Allows multiple eNodeB nodes to be emulated on a single computer.

Protocols and Network Interfaces implemented by the eNodeB Emulator:

25
em

LTE EPC Emulator

• EPC Emulator comprises the MME, SGW, and PGW Emulators. MME Emulator includes HSS and
PGW Emulator includes PCRF functions.
• Implemented as State Machines, so that EPC Emulator can be used in place of real EPC in a lab
testing environment.
• Polaris Networks EPC Emulators are software based tools, using which a complete LTE core
network can be simulated using a single PC.
• Supports standard LTE features and operations (Attach, Detach, Default/Dedicated Bearer,
Handover, etc.) to test eNodeB, MME, SGW, PGW, HSS for completeness of feature
implementation.

LTE lab set-up with real and emulated nodes:

26
em

The Polaris Networks LTE Emulators are 3GPP Release 10 compliant solutions that can be used to
simulate LTE infrastructure elements – eNodeB, MME, SGW, PGW, HSS, PCRF. The test suite can also
simulate the UEs and comes with an internal traffic generator to simulate the traffic over the network. The
emulated MME, SGW, PGW, HSS, and PCRF nodes can be used with real eNodeBs and real UEs too. All
the nodes can be deployed on a single machine or on multiple machines or virtual machines in distributed
fashion. Each of the installations can simulate multiple nodes. For example, in one MME installation, one
can simulate 10 MME instances.

All the nodes are connected with each other over standard 3GPP interfaces. Tools like Wireshark can be
used to study the packets that are being sent from one node to another.

The test solution can deliberately create errors in parts of the network. For example, it can be set to not
accept any more attach request or any S1-MME connection. Once this mode is set the packets being
exchanged in this situation can be studied.

This is a state machine based solution, and very closely replicates real network elements. The user can also
see different statistics for network operations.

It comes with programming APIs, which can be used to automate operations usually done manually by
using the GUI.

The features supported by the supplied version of the software are listed below in brief. The details about
the features and instructions on how to use them can be found in the supporting documents. Using some of
the features may require some additional software/equipment.

The supporting documents are:

• Console User Guide

• Programmers Guide
• Application Notes

Feature Function
No.
1 Features Supported
1.01 S1-Setup
1.02 S1-Reset
1.03 UE Attach – Initial Attach
1.04 UE Attach with old GUTI
1.05 SCTP Multi-homing on S1-MME
1.06 UE IPv4 address assignment via DHCP – PGW Requested
1.07 UE IPv4 address assignment via DHCP – UE Requested
1.08 UE Detach – UE Initiated
1.09 UE Context Release
1.10 Service Request
1.11 UE Requested Bearer Resource Allocation
1.12 UE Requested Bearer Resource Modification
1.13 Dedicated Bearer Setup – Network Initiated
1.14 Bearer Modification – Network Initiated

27
em

1.15 Bearer Release – Network Initiated

1.16 Downlink Data Notification / Paging
1.17 Tracking Area Update
1.18 S1-Based Handover (with MME/SGW Relocation)
1.19 X2-Based Handover
1.20 Multiple PDN Connectivity
1.21 PDN Disconnection
1.22 IPv6 and IPv4v6 PDN Connectivity
1.23 Trace
1.24 Overload
1.25 Location Reporting
1.26 SGW Selection based on Tracking Area
1.27 Closed Subscriber Groups and Open, Closed and Hybrid
Access control to support Home eNB
1.28 UE Detach - HSS Initiated
1.29 HSS Initiated Subscriber Modification
1.30 Roaming - Home Routed
1.31 Roaming with Local Breakout
1.32 MME Configuration Update
1.33 CMAS
1.34 Warning Message Transmission
1.35 Emergency Session
1.36 PMIP based S5
1.37 Interworking with Release 8 GERAN/UMTS Networks
1.38 Network Recovery from peer node failure
1.39 CSFB (3GPP Access and Trusted non-3GPP Access) -
including SMS and voice call (without PS HO)
1.40 CSFB (3GPP Access) - PS Handover
1.41 IMS based VoLTE
1.42 Support for Relay eNodeB
1.43 Multimedia Priority Services and Access Class
1.44 Service Restoration from Network Failure
1.45 Radio Resource Management Functions in MME
1.46 RAN Information Management in MME
1.47 Access Restriction
1.48 eMBMS
1.49 IPv6 for Signaling in Control Plane
1.50 Interworking with trusted non-3GPP Network

2 Interfaces Supported
2.01 S1-MME
2.02 S1-U
2.03 S11
2.04 S10
2.05 S5/S8
2.06 SGi
2.07 S6a

28
em

2.08 S13
2.09 SBc
2.10 S12
2.11 S4
2.12 S3
2.13 Gxc
2.14 SGs
2.15 S102
2.16 Rx
2.17 Gx
2.18 S9
2.19 S2a
2.20 S6b
2.21 STa
2.22 Gxa
2.23 M1
2.24 M3
2.25 Sm
2.26 SGmb
2.27 SGi-mb
2.28 S14
2.29 Zh
2.30 Cx

3 Additional Features
3.01 ICMP and UDP traffic generation using internal traffic
generator
3.02 Simulation of abnormal and failure scenarios for
negative testing
3.03 Procedure and Packet statistics for each protocol
3.04 Protocol timer configuration
3.05 Separate IP Address for each 3GPP interface
3.06 Wireshark Integration

29
em

Using Polaris Networks Emulators for Basic Functions

The Emulators have features that can be used for learning about the LTE network in great detail. The
Emulators suite comes with application notes that you can access from the help menu in the Console. The
Application Notes document describes how to use the features.
The screenshots below show that all the Emulator nodes have been deployed on a single machine (IP
address 192.168.25.210) on different ports (5679 – 5685). This is the setup for all the exercises that follow.
All the instances of the nodes that are created are given alias IP addresses in 10.10.10.x series.

Exercise 1: Starting all LTE Nodes

Prerequisites: Emulators installed on system.

Open terminal and log in as “root” user in Fedora-19/Ubuntu with password “polaris” or “mcte”.

Screenshots of Fedora boot-up:

1. After system start, initially the Emulators Screen looks like this:

Figure 1

30
em

2. Press “Enter” to get the User ID and Password prompt:

Figure 2

3. Open terminal:

Figure 3

31
em

4. Go to “root” user prompt in terminal:

Figure 4

5. Start Polaris LTE Emulators one by one:

Figure 5

32
em

6. Verify that the LTE Emulators are running successfully.

Figure 6

• Start the MME Emulator on a free port (a). Example: 5682.

• Go to directory /opt/polaris-lte-emulator/server

• Type ./start.sh –mme 5682

• Check that the process has started by noting the output of the above command and then typing ps. It
should show that the mme_controller process is running. Refer to Figures 5 and 6.

• Similarly, start the HSS Emulator on a free port (b). Example: 5680.

• Start the SGW Emulator on a free port (c). Example: 5683.

• Start the PGW Emulator on a free port (d). Example: 5686.

• Start the PCRF Emulator on a free port (e). Example: 5692.

• Start the eNodeB Emulator on a free port (f). Example: 5678.

33
em

Exercise 2: Connecting to Emulators Using the Console

Prerequisites: Exercise 1 – Emulators running.

1. Type ifconfig where the emulators are running and note the IP Address of the system.

2. Open the Polaris Networks Emulators Console by typing console and press enter.

Figure 7

3. To discover Emulators that are active in your LAN(s):

Click the button on the Tool Bar. Set the following parameters in the dialog box that opens up.

Parameter Description
Broadcast Address (or Network Broadcast IP address to which the Console will send a Discover
Address/Mask) Request.
Port Range or List UDP port number or port range which the Console will use to send the
Discover Request.

Click Ok. The Console adds the discovered Emulators to the Nodes pane. It also saves the Broadcast
Address and Port Number that you entered, and uses this information to discover Emulators automatically
the next time you start the Console.

4. To connect to an Emulator:

In the Nodes pane, right-click on a node that has been discovered already, and choose Connect from the
context menu. The node's icon turns green if the connection is successful. If the Console loses this
connection, the icon turns red.

Alternatively:
Select the node in the Nodes pane and click the button on the Tool Bar.

Enter the IP Address and Port of the NetTest system in the Connect dialog box, and click Ok.

34
em

5. Right click on the MME and connect it at port 'a' as in exercise 1.

6. Connect the HSS at port 'b' as in exercise 1.

7. Connect the SGW at port 'c' as in exercise 1.

8. Connect the PGW at port 'd' as in exercise 1.

9. Connect the PCRF at port 'e' as in exercise 1.

Exercise 3: IP Address Planning for LTE nodes

Objective: Plan a unique IP for each of the LTE nodes – eNodeB, MME, HSS, SGW, PGW, PCRF.

Prerequisites: Exercises 1 and 2 – Emulators running in backend and connected to Console.

Figure 8: Typical setup with all nodes running on the same system. Note that all the nodes have different logical IPs.

35
em

Sub Exercise 1: Configure the MME from the Console

Objective: Complete the basic configuration for the Polaris Networks LTE MME.

1. Right click on the MME and configure 'PLMN' called 'TestNetwork' in the MME connected to the
Console. Set the MCC and MNC for the PLMN as '123' and '45' (a TestNetwork for MCTE).

2. Next, right click on the MME PLMN and add a 'New' MME.

3. Next, right click on the MME added in step 2. Configure MME parameters. Some standard values
are already provided by Polaris by default, but you have to input the 'Interfaces'.

4. Use the MME IP that was planned. All the interfaces can be given one IP to start with, which
should be unique in the system.

5. Similarly, planned IP must be provided for the MME neighbor.

Figure 9

36
em

In the “Interfaces” tab type the IP addresses for all MME interfaces. For example, 10.90.90.20.

Figure 10

In the “Neighbor” tab configure MME neighbors and click Ok to create a New MME.

Figure 11

As shown in Figure 11, we planned the IP address of HSS, SGW, and PGW to be 10.90.90.23, 10.90.90.21,
and 10.90.90.22.

37
em

Sub Exercise 2: Configure the HSS from the Console

Objective: Complete the basic configuration for the Polaris Networks LTE HSS.

1. Right click on the HSS and configure 'PLMN' called 'TestNetwork' in the HSS connected to the
Console. Set the MCC and MNC for the PLMN as '404' and '30' (Vodafone uses this).

2. Next, right click on the HSS PLMN and add a 'New' HSS.

3. Next, right click on the HSS added in step 2. Configure HSS parameters. Some standard values are
already provided by Polaris by default, but you have to input the 'Interfaces'.

4. Use the HSS IP that was planned. All the interfaces can be given one IP to start with, which should
be unique and in the same subnet in the system.

5. Similarly, planned IP must be provided for the HSS neighbor.

Figure 12

38
em

Sub Exercise 3: Configure SPR from the Console

1. Right click on SPR and add a 'PDN Context'. Set the parameters and click Ok to select other
default values.

Figure 13

2. Right click on SPR and add a 'Subscription Profile'. In the “PDN” tab “Add” PDN_Context_1
and click Ok as shown in Figure 14.

Figure 14

39
em

3. Right click on the Subscription Profile created in Step 2 and select 'Register Subscriber Group'.
Here, accept the default values to add one or more Subscribers for initial experiments. You can
experiment with the values if you are familiar with subscriber parameters.

Figure 15

Sub Exercise 4: Configure the SGW from the Console

Objective: Complete the basic configuration for the Polaris Networks LTE SGW.

1. Right click on SGW and configure 'PLMN' called 'TestNetwork' in the SGW connected to the
Console. Set the MCC and MNC for the PLMN as '404' and '30' (Vodafone uses this).

2. Right click on the SGW PLMN and add a 'New' SGW.

3. Right click on the SGW added in step 2. Configure SGW parameters. Some standard values are
already provided by Polaris by default, but you have to input the 'Interfaces'.

4. Use the SGW IP that was planned. All the interfaces can be given one IP to start with, which should
be unique in the system.

5. Similarly, planned IPs must be provided for the SGW neighbors.

40
em

Sub Exercise 5: Configure the PGW from the Console

Objective: Complete the basic configuration for the Polaris Networks LTE PGW.

1. Right click on PGW and configure 'PLMN' called 'TestNetwork' in the PGW connected to the
Console. Set the MCC and MNC for the PLMN as '404' and '30' (Vodafone uses this).

2. Right click on the PGW PLMN and add a 'New' PGW.

3. Right click on the PGW added in step 2. Configure PGW parameters. Some standard values are
already provided by Polaris by default, but you have to input the 'Interfaces'.

4. Use the PGW IP that was planned. All the interfaces can be given one IP to start with, which should
be unique in the system.

5. Similarly, planned IPs must be provided for the PGW neighbors.

Figure 16: The PDN name should be the same as the PDN profile previously created in SPR

Sub Exercise 6: Configure the PCRF from the Console

Objective: Complete the basic configuration for the Polaris Networks LTE PCRF.

1. Right click on PCRF and configure 'PLMN' called 'TestNetwork' in the PCRF connected to the
Console. Set the MCC and MNC for the PLMN as '404' and '30' (Vodafone uses this).

2. Right click on the PCRF PLMN and add a 'New' PCRF.

3. Right click on the PCRF added in step 2. Configure PCRF parameters. Some standard values are
already provided by Polaris by default, but you have to input the 'Interfaces'.

4. Use the PCRF IP that was planned. All the interfaces can be given one IP to start with, which
should be unique in the system.

5. Similarly, planned IPs must be provided for the PCRF neighbors.

41
em

Sub Exercise 7: Configure the eNodeB from the Console

Objective: Complete the basic configuration for the Polaris Networks LTE eNodeB.

1. Right click on eNodeB and configure 'PLMN' called 'TestNetwork' in the eNodeB connected to the
Console. Set the MCC and MNC for the PLMN as '404' and '30' (Vodafone uses this).

2. Right click on the eNodeB PLMN and add a 'New' eNodeB.

3. Right click on the eNodeB added in step 2. Configure eNodeB parameters. Some standard values
are already provided by Polaris by default, but you have to input the 'Interfaces'.

4. Use the eNodeB IP that was planned. All the interfaces can be given one IP to start with, which
should be unique in the system.

5. Similarly, planned IPs must be provided for the eNodeB neighbors.

Figure 17: In the Cells tab click on the Red + sign and accept the default values by clicking Ok

Once the above Exercises are done the LTE infrastructure provisioning is completed.

42
em

Exercise 4: Connecting MME and eNodeB over S1 Link

Objective: Make the S1-Setup connection between eNodeB and MME.

Prerequisites: Exercise 3 – All the nodes are configured.

1. Right click on the connected Emulated eNodeB node and click on S1-Setup. Provide MME IP (as
configured in above exercise) in the pop-up box and click Ok.

2. Verify that the S1 link has become green.

3. Click on eNodeB emulator and check the logs to see that S1 setup is successful.

4. Click on created MME and S1AP statistics tab and verify that the S1 links number is 1.

Figure 18

Figure 19

43
em

Exercise 5: Attaching a UE
Objective: Create a Polaris Networks simulated UE and Attach it.

Prerequisites: Exercises 3 and 4 – All the nodes configured and eNodeB and MME connected.

1. Right click on the eNodeB PLMN, TestNetwork, and add a UE. Provide the parameters that were
provided while registering the UE in HSS/SPR Subscription profile during the previous exercises.
If you entered the default values, they will match automatically.

2. After UE creation, right click on the UE and click Attach. Provide default values in the pop-up box
and click Ok. This should attach the UE.

3. The UE icon is shown in green if the UE Attach procedure is successful and in red if the Attach
procedure fails. The Properties pane on the right shows the EMM Status and the ECM Status.

4. Click on the eNodeB emulator and check the logs to see that UE attach is successful.

5. Click on eNodeB’s S1 link and verify that the number of connected UEs is 1.

Figure 20

44
em

Exercise 6: Capturing Packets Using Wireshark

Wireshark is a very useful tool for monitoring the network for dataflow and debugging network issues.
This exercise will help you to capture packets between any two LTE nodes for detailed analysis.

Prerequisites: Wireshark (Version 10 or higher) installed on the system.

Wireshark can be downloaded from: http://www.wireshark.org/download.html

The Console features integrated support for the use of Wireshark.

1. To capture packets using Wireshark, click the button on the Tool Bar.

2. In the Start Packet Capture dialog box, set the following parameters.

Parameter Description
Open Wireshark Select one of the two radio buttons.
Window/Run in background
Program Click this button to locate the wireshark program file on your computer.
Capture File Click this button to set the directory in which captured packets are saved.
Hide Unused Interfaces Check this box to remove any interfaces not currently in use from the list.
Uncheck it to display all interfaces.
Interface Check the box next to an interface to capture packets on it.
IP Address The IP address of the interfaces.
Emulator The emulators by which the interfaces are being used.
3GPP Interfaces The 3GPP interfaces available for packet capture on a certain emulated
node.
Protocols to capture The protocols for which packet data can be captured on a certain interface.
Select the Protocols to When you highlight an interface by left-clicking on, a number of check
capture on the highlighted boxes appear at the bottom of the dialog box, corresponding to the
interface protocols associated with that interface. Check or uncheck the boxes as
desired to set which protocols are to be captured.

3. Click Ok and Wireshark Capture will begin.

45
em

You can now repeat Exercises 4-5 and see the captured packets for different operations. You can also note
the heartbeat messages being exchanged between different nodes.

Figure 21: Wireshark capture for S1-MME setup and UE attach

46