1
Cellular Networks and Mobile Computing
COMS 6998-7, Spring 2014
Instructor: Li Erran Li
(lierranli@cs.columbia.edu)
http://www.cs.columbia.edu/~lierranli/coms
6998-7Spring2014/
3/7/2014: Introduction to Cellular Networks
Review of Previous Lecture
• What are the different approaches of
virtualization?
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
2
Review of Previous Lecture
• What are the different approaches of
virtualization?
– Bear-metal hypervisor, hosted hypervisor, container
(Linux LXC, Samsung Knox)
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
3
Bare-Metal Hypervisor
poor device support / sharing
OS
Kernel
OS
Kernel
OS
Kernel
Hypervisor / VMM
Hardware
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Jason Nieh et al.
4
Hosted Hypervisor
poor device
performance
OS
OS
OS
Hypervisor / VMM
Host OS Kernel
kernel
module
emulated
devices
Hardware
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Jason Nieh et al.
5
Review of Previous Lecture
(Cont’d)
• What approach does Cell use?
• What are the key design choices for Cell’s
extremely low overhead?
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
6
Review of Previous Lecture
(Cont’d)
• Device namespace
– It is designed to be used by individual device drivers or
kernel subsystems to tag data structures and to register
callback functions. Callback functions are called when a
device namespace changes state.
– Each VP uses a unique device namespace for device
interaction.
• Cells leverages its foreground-background VP usage
model to register callback functions that are called
when the VP changes between foreground and
background state.
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
7
Device Namespaces
VP 1
safely, correctly
multiplex
access to
devices
VP 3
•••
Cellular Networks and Mobile Computing
(COMS 6998-10)
•••
Android...
RTC / Alarms
Audio/Video
Sensors
Input
Power
Framebuffer
Cell Radio
WiFi
GPU
device namespaces
Linux
Kernel
3/7/14
VP 2
Courtesy: Jason Nieh et al.
8
Review of Previous Lecture
(Cont’d)
• How to run iOS applications on Android OS?
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
9
Cider Architecture
• Interaction between app and OS is
defined by kernel app binary
interface (ABI)
– ABI includes: binary loader, async signal
delivery, and syscall
• Mach-O binary loader built into
Linux kernel
– Kernel tags current thread with iOS
persona
• Persona is an execution mode (exec foreign
or domestic code) assigned to each thread
• Translation layer for async signal
(illegal instruction, segmentation
fault) delivery
• Multiple syscall interface
– Wrapper mapping arguments from XNU
structures to Linux ones
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
10
Duct Tape
• Mach IPC missing in Linux
• Duct tape to the rescue
– Direct compilation of unmodified foreign kernel source code
into domestic kernel
– Direct translates foreign Kernel API such as sync, memory
allocation, processing control into domestic kernel API
• Duct tape has three steps:
– Create three distinct coding zones: foreign, domestic, duct
tape
• No cross access between foreign and domestic
• Cross access between foreign (domestic) and duct tape
– Identify foreign symbols conflicting with domestic code
– Remap conflicting symbols to unique domestic ones
• Duct tape advantages: easy to maintain and reusable
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
11
Duct Tape (Cont’d)
• Cider uses duct tape to add three subsystems
– pthread: differ from Linux, use kernel-level support
for mutexes, semaphores and condition variables
– Mach IPC: direct compilation; rewrite recursive
queuing structures
– Apple’s I/O Kit device driver framework
• Source code at:
http://www.opensource.apple.com/source/xnu/xnu2050.18.24/iokit/
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
12
Diplomatic Functions
• Mobile apps often use closed proprietary
hardware and software stacks
– OpenGL ES libraries directly communicate with GPU
through proprietary software and hardware
interfaces using device-specific ioctls (Android) or
opaque IPC messages (iOS)
• How to direct access to proprietary hardware?
• Diplomatic function temporarily switches the
persona of a calling thread to exec domestic
functions from within foreign app
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
13
Review of Previous Lecture
(Cont’d)
• What are the most expensive flash memory
operations?
– Random read
– Random write
– Sequential write
– Sequential read
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
14
• Performance for random
I/O significantly worse
than seq; inherent with
flash storage
• Mobile flash storage
classified into speed
classes based on
sequential throughput
 Random write performance is
orders of magnitude worse
Vendor
(16GB)
Speed
Class
Cost
US $
Seq
Write
Rand
Write
Transcend
2
26
4.2
1.18
RiData
2
27
7.9
0.02
Sandisk
4
23
5.5
0.70
Kingston
4
25
4.9
0.01
Wintec
6
25
15.0
0.01
A-Data
6
30
10.8
0.01
Patriot
10
29
10.5
0.01
PNY
10
29
15.3
0.01
Performance MB/s
Random versus Sequential
Disparity
Consumer-grade SD performance
For several popular apps, substantial
fraction of I/O is random writes (including web browsing!)
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Nitin Agrawal et al.
15
Syllabus
• Mobile App Development (lecture 1,2,3)
– Mobile operating systems: iOS and Android
– Development environments: Xcode, Eclipse with Android SDK
– Programming: Objective-C and android programming
• System Support for Mobile App Optimization (lecture 4,5)
– Mobile device power models, energy profiling and ebug debugging
– Core OS topics: virtualization, storage and OS support for power and context management
• Interaction with Cellular Networks (lecture 6,7,8)
– Basics of 3G/LTE cellular networks
– Mobile application cellular radio resource usage profiling
– Measurement-based cellular network and traffic characterization
• Interaction with the Cloud (lecture 9,10)
– Mobile cloud computing platform services: push notification, iCloud and Google Cloud
Messaging
– Mobile cloud computing architecture and programming models
• Mobile Platform Security and Privacy (lecture 11,12,13)
– Mobile platform security: malware detection and characterization, attacks and defenses
– Mobile data and location privacy: attacks, monitoring tools and defenses
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
16
Outline
Goal of this lecture: understand the basics of current
networks and future directions
• Current Cellular Networks
–
–
–
–
–
–
Introduction
Radio Aspects
Architecture
Power Management
Security
QoS
• What Is Next?
• A Clean-Slate Design: Software-Defined Cellular
Networks
• Conclusion and Future Work
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
17
Cellular Networks Impact our Lives
More Mobile Connection
More Infrastructure
Deployment
1010100100001011001
0101010101001010100
1010101010101011010
1010010101010101010
0101010101001010101
More Mobile Users
3/7/14
More Mobile
Information
Sharing
Cellular Networks and Mobile Computing
(COMS 6998-10)
18
Global Convergence
• LTE is the major technology for future mobile
broadband
– Convergence of 3GPP and 3GPP2 technology tracks
– Convergence of FDD and TDD into a single technology track
D-AMPS
3GPP
PDC
GSM
WCDMA
IS-95
HSPA
TD-SCDMA
HSPA/TDD
cdma2000
EV-DO
3GPP2
IEEE
WiMAX
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
LTE
FDD and TDD
?
19
3GPP introduction
• 3rd Generation Partnership Program
– Established in 1998 to define UMTS
– Today also works on LTE and access-independent
IMS
– Still maintains GSM
• 3GPP standardizes systems
– Architecture, protocols
• Works in releases
– All specifications are consistent within a release
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
20
3GPP way of working
Stage 1
Requirements
• “It shall be possible to...”
• “It shall support…”
E.g., 22-series specs
Stage 2
Architecture
Stage 3
Protocols
• Nodes, functions
• Reference points
• Procedures (no errors)
E.g., 23-series
specs
• Message formats
• Error cases
E.g., 29-series
specs
Specification numbering example:
3GPP TS 23.401 V11.2.0
Updated after a meeting
TS=Technical Specification (normative)
TR=Technical Report (info only)
Release
Spec. number • Consistent set of specs per releas
• New release every 1-2 years
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Zoltán Turányi
21
3GPP specification groups
3G/LTE
2G
3/7/14
System
Cellular Networks and Mobile Computing
(COMS 6998-10)
Protocols
22
Starting points on 3GPP
specifications
• http://www.3gpp.org/specification-numbering
– Pointers to the series of specifications
– Architecture documents in 23-series
• Main architecture references
– 23.002 – Overall architecture reference
– 23.401 – Evolved Packet Core with LTE access, GTPbased core
– 23.060 – 2G/3G access, and integration to Evolved
Packet Core
– 23.402 – Non-3GPP access, and PMIP-based core
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Zoltán Turányi
23
Example
A base station
with 3 sectors
(3 cells)
Courtesy: Zoltán Turányi
Key challenges
• Large distances
– Terminals do not see each other
– Tight control of power and timing needed
– Highly variable radio channel – quick adaptation needed
• Many users in a cell
– A UMTS cell can carry roughly 100 voice calls on 5 MHz
– Resource sharing must be fine grained – but also flexible
• Quality of Service with resource management
– Voice – low delay, glitch-free handovers
– Internet traffic – more, more, more
• Battery consumption critical
– Low energy states, wake-up procedures
– Parsimonious signaling
Courtesy: Zoltán Turányi
26
Radio basics
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
LTE air interface
• The key improvement in LTE radio is the use of OFDM
• Orthogonal Frequency Division Multiplexing
– 2D frame: frequency and time
– Narrowband channels: equal fading in a channel
• Allows simpler signal processing implementations
– Sub-carriers remain orthogonal under multipath
One resource block
propagation
One resource element
12 subcarriers during one slot
(180 kHz × 0.5 ms)
12 subcarriers
Time domain structure
Frame (10 ms)
One OFDM
symbol
One slot
3/7/14
time
Cellular Networks and Mobile Computing
(COMS 6998-10)
Slot (0.5 ms)
Subframe (1 ms)
27
LTE air interface: Downlink
1
T
T large compared to
channel delay
spread
Orthogonal Frequency Division
Multiple Access (OFDM)
Closely spaced sub-carriers without guard
band
 Each sub-carrier undergoes (narrow
band) flat fading
- Simplified receiver processing
Frequency
Narrow Band (~10 Khz)
Wide Band (~ Mhz)
 Frequency or multi-user diversity through
coding or scheduling across sub-carriers
 Dynamic power allocation across sub-
carriers allows for interference mitigation
Sub-carriers remain orthogonal under
across cells
multipath propagation
 Orthogonal multiple access
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Harish Vishwanath
28
LTE air interface: Uplink
 Users are carrier
User 1
synchronized to the base
 Differential delay between
users’ signals at the base
need to be small compared
to symbol duration
W
 Efficient use of spectrum by multiple
User 2
users
 Sub-carriers transmitted by different
users are orthogonal at the receiver
- No intra-cell interference
User 3
 CDMA uplink is non-orthogonal
since synchronization requirement is
~ 1/W and so difficult to achieve
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Harish Vishwanath
29
LTE air interface: Multiplexing
Each color represents a user
Each user is assigned a
frequency-time tile which
consists of pilot sub-carriers and
data sub-carriers
Block hopping of each user’s tile
for frequency diversity
Typical pilot ratio: 4.8 % (1/21)
for LTE for 1 Tx antenna and
9.5% for 2 Tx antennas
Time
Pilot sub-carriers
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Harish Vishwanath
30
LTE Scheduling
• Assign each Resource Block to one of the terminals
– LTE – channel-dependent scheduling in time and frequency
domain
– HSPA – scheduling in time-domain only
data1
data2
data3
data4
Time-frequency fading, user #2
Time-frequency fading, user #1
User #1 scheduled
User #2 scheduled
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Zoltán Turányi
31
Architecture
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
32
UMTS Architecture
PS Core Network
CS
CN
MSC
Gi
GGSN
Gn/Gp
SGSN
IuCS
•First-hop router
•GW towards external PDNs
•VPN support over Gi
•IP address management
•Policy Control
•Manage CN procedures
•HSS connection (authenticator)
•Idle mode state
•Lawful Intercept
•Bearer management
IuPS
RNC
•Real-time radio control
•Radio Resource Management
•Soft handover
•UP Ciphering
•Header Compression
Iub
NodeB
•L1
•HSPA scheduling
3G Radio Access Network
• Why separate RAN and CN?
–
–
–
–
Two CNs with same RAN
Multiple RANs with same CN
Modularization
Independent scaling, deployment
and vendor selection
• Why two GSNs?
– Roaming: traffic usually taken home
– Independent scaling, deployment
and vendor selection
– User can connect to multiple PDNs
GPRS – Generic Packet Radio Service
GGSN – Gateway GPRS Support Node
SGSN – Serving GPRS Support Node
RNC – Radio Network Controller
PDN – Packet Data Network
CN – Core Network
PS – Packet Switched
CS – Circuit Switched
MSC – Mobile Switching Center
HSS – Home Subscriber Server
Drivers for change
CS
CN
MSC
Overhead of
PS Coreseparate
Network CS core
when bulk of
Gi
•First-hop router
•GW towards
external PDNs
traffic
is PS
GGSN
Gn/Gp
SGSN
IuCS
•VPN support over Gi
•IP address management
•Policy Control
•Manage CN procedures
•HSS connection (authenticator)
•Idle mode state
•Lawful Intercept
•Bearer management
Too many
specialized data
plane nodes
IuPS
RNC
•Real-time radio control
•Radio Resource Management
•Soft handover
•UP Ciphering
•Header Compression
Complex, realtime RAN
Iub
NodeB
•L1
•HSPA scheduling
Vendor lock-in
due to
3G Radio Access Network
proprietary Iub
features
Courtesy: Zoltán Turányi
From 3G to EPC/LTE architecture
Only two data
PS Core Network plane nodes in the
typical case.
CS
MSC
Gi
SGi
GGSN
PDN GW
SGW
Packet Data Network GW
Serving GW
Gn/Gp
S11
SGSN
IuCS
Evolved Packet Core (EPC)
IuPS
RNC
control plane
Data plane/control
plane split for
better scalability.
MME
Mobility
Management
Entity
PS only
S1-UP
S1-CP
Iub
NodeB
3G Radio
Access Network
eNodeB eNodeB – Evolved Node B
RNC functions
moved down to
base station
LTE Radio
Access Network
Courtesy: Zoltán Turányi
35
Why separate SGW and PDN GW?
Evolved Packet Core (EPC)
SGi
PDN GW
Packet Data Network GW
S5/S8
SGW
Serving GW
S11
MME
S1-UP
Mobility
Management
Entity
S1-CP
eNodeB eNodeB – Evolved Node B
LTE Radio
Access Network
SGW and PDN GW separate in
some special cases:
• Roaming:
• PDN GW in home network,
• SGW in visited network
• Mobility to another region in a
large network
• Corporate connectivity
Courtesy: Zoltán Turányi
36
Interworking with 3G
SGi
HSS
PDN GW
S5
Gn
SGW
S11
MME
SGSN
MSC
IuCS
IuPS
S1-U
S1-CP
RNC
Iub
eNodeB
UE
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
NodeB
MSC – Mobile Switching Center
Courtesy: Zoltán Turányi
37
Interworking with
non-3GPP accesses
SGi
HSS
PDN GW
S5
Gn
S2
SGW
S11
MME
SGSN
MSC
IuCS
IuPS
Non-3GPP
Access
(cdma2000, WiMax,
WiFi)
S1-U
S1-CP
Iub
eNodeB
UE
3/7/14
RNC
Cellular Networks and Mobile Computing
(COMS 6998-10)
NodeB
PMIP – Proxy Mobile IP
Courtesy: Zoltán Turányi
38
Debate of 2006:
GTP vs. PMIP
SGi
HSS
PDN GW
GTP
GTP?
GTP
S5
Gn
PMIP
PMIP?
S2
PMIP
SGW
S11
MME
SGSN
MSC
IuCS
IuPS
Non-3GPP
Access
(cdma2000, WiMax,
WiFi)
S1-U
S1-CP
GTP
Iub
eNodeB
UE
3/7/14
RNC
Cellular Networks and Mobile Computing
(COMS 6998-10)
NodeB
• Conclusion: Specify both
Courtesy: Zoltán Turányi
39
EPC + LTE: 23.401
EPC + 2G/3G: 23.060
SGi
HSS
PDN GW
GTP
S5
Gn
GTP
SGW
S11
MME
SGSN
MSC
IuCS
IuPS
S1-U
S1-CP
RNC
GTP
Iub
eNodeB
NodeB
UE
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Zoltán Turányi
40
41
EPC + non-3GPP: 23.402
SGi
HSS
PDN GW
S5
S2
PMIP
Non-3GPP
Access
(cdma2000, WiMax,
WiFi)
PMIP
SGW
S1-U
S11
MME
S1-CP
GTP
eNodeB
UE
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
EPC – Evolved Packet Core
Courtesy: Zoltán Turányi
Access Procedure
• Cell Search
Base station
– Base station broadcasts
synchronization signals and cell
system information (similar to
WiFi)
– UE obtains physical layer
information
• UE acquires frequency and
synchronizes to a cell
• Determine the start of the
downlink frame
• Determine the cell identity
UE 1
UE 2
• Random access to establish a
radio link
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
42
Random Access
Client
Base station
Core network
Step 1: random access request (pick one of 64 preambles)
Step 2: random access response
Adjust uplink timing
Step 3: transmission of mobile ID
Only if UE is not known in Base station
Step 4: contention resolution msg
If ID in msg matches UE ID, succeed.
If collision, ID will not match!
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
43
Random Access (Cont’d)
Why not carrier sensing like
WiFi?
•Base station coverage is much
larger than WiFi AP
Base station
– UEs most likely cannot hear
each other
•How come base station can
hear UEs’ transmissions?
– Base station receivers are much
more sensitive and expensive
3/7/14
UE 2
UE 1
Cellular Networks and Mobile Computing
(COMS 6998-10)
44
Modes of operation
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
45
Connected mode
•
•
•
•
Used during communication
Signaling connection exists between network and UE
Both CN and RAN keeps state about the UE
UE location is tracked on a cell granularity
– Needed to deliver the data
• Network controlled mobility
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
SGW
MME
46
Network controlled mobility
SGW
5
MME
• Procedure
1.
2.
3.
4.
5.
•
UE measures nearby cells
UE sends measurement reports to network
Network decides on and controls handover
Handover is prepared by network
Handover executes
5
3.
4.
1. 5
1.
2.
1.
5
Reason: To allow the network to tune handovers
1.
2.
3.
4.
5.
6.
Select proper target cell
Network has additional information for handover decision
Collect and analyze data for cell planning and troubleshooting
Penalize ping-ponging UEs
Penalize microcells for fast UEs
Cell breathing
Courtesy: Zoltán Turányi
47
Idle Mode
• Used when the UE is not communicating
• UE location is tracked on a Tracking Area (TA) granularity
– eNodeBs advertise their TA
– UE periodically listens to advertisements (every few seconds)
– UE sends Tracking Area Update (TAU) to MME, when TA
changes
– TAU also sent periodically (e.g., once every 2 hours)
• No eNodeB state is kept for UE
• When traffic arrives to the UE,
the UE is paged
48
PAGING
• UE periodically checks if data is available for it
– Wakes up, (re)selects cell, reads broadcast and the paging
channel
– Exact timing is pseudo-random per UE
› If packet arrives to SGW…
– …it buffers the packet
– …and notifies MME.
– MME sends a Paging Request to all eNodeBs
in the TA of the UE
– eNodeBs page the UE on its paging slot
locally
– UE responds with a Service Request…
– …eNodeB state is built up…
– …and UE is moved to connected state.
PDN GW
SGW
Courtesy: Zoltán Turányi
MME
UE
49
Idle mode issues
• Idle mode is a great power-saving feature
– A system-wide feature
– Also saves a lot of RAN resources
• Balancing of TA size is needed
– Too large: many paging messages
– Too small: many TAU messages from UE
– Lot of optimizations: per-UE TA, overlapping TA, etc.
• Connected  Idle transitions are costly
– Usually a timeout is used to go to idle
• Not a good fit for chatty packet traffic
• Easy to attack: an IP address range scan wakes up everyone
– Key application design goal: reduce chattyness
• The Phone OS also has responsibility
– However, can be very effective when combined with DRX
Cellular Networks and Mobile Computing
(COMS 6998-10)
50
LTE RRC State Machine
• UE runs radio resource
control (RRC) state
machine
• Two states: IDLE,
CONNECTED
• Discontinuous reception
(DRX): monitor one
subframe per DRX cylce;
receiver sleeps in other
subframes
3/7/14
Courtesy:Morley Mao
51
UMTS RRC State Machine
• State promotions have promotion delay
• State demotions incur tail times
Tail Time
Delay: 1.5s
Delay: 2s
Channel
Radio
Power
IDLE
Not
allocated
Almost
zero
CELL_FACH
Shared,
Low Speed
Low
CELL_DCH
Dedicated,
High Speed
High
Tail Time
3/7/14
Courtesy: Feng Qian
Cellular Networks and Mobile Computing
(COMS 6998-10)
52
Why Power Consumptions of RRC States
so different?
• IDLE: procedures based on reception rather
than transmission
– Reception of System Information messages
– Reception of paging messages with a DRX cycle
(may trigger RRC connection establishment)
– Location and routing area updates (requires RRC
connection establishment)
• CONNECTED: need to continuously receive, and
sent whenever there is data
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
53
Security
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
54
The SIM card
• Subscriber Identity Module
– Usually embedded in a physical SIM card
• Initially specified in 1990 for GSM (freeze date of TS 11.11)
• Carries subscriber credentials
– IMSI: International Mobile Subscriber Identity – 14-15 digits
• MCC: Mobile Country Code – 3 digits
• MNC: Mobile Network Code – 2 or 3 digits
• Rest of the digits identify the subscriber
– Keying material (essentially symmetric keys)
• In the network HSS stores subscriber data
– Including keying and phone number (MSISDN)
• Enables roaming and phone replacement
– Key features in GSM
MSISDN – Mobile Subscriber ISDN Number
55
KEY hierarchy
AuC
SGi
HSS
PDN GW
USIM / AuC
K
S5
CK, IK
AKA procedure
UE / HSS
SGW
MME
S11
KASME
UE / MME
S1-U
S1-CP
KNASenc
KNASint
KeNB / NH
UE / eNB
eNodeB
UE
USIM
KUPint
KUPenc
KRRCint
KRRCenc
AuC – Authentication Centre
AKA – Authentication and Key Agreement
CK: Encryption, IK: integrity Protection
ASME: Access Security Management Entity
NH – Next Hop
Courtesy: Zoltán Turányi
56
Authentication at initial attach
UE
eNodeB
1: Attach Request
(GUTI or IMSI)
MME
PDN GW
HSS
old MME
2: Identity Request
(GUTI)
3: Identity Response
(IMSI)
4: Identity Request
(GUTI)
5: Identity Response
(IMSI)
7: KASME
computed
SGW
6: Security functions (incl. AKA)
8: KASME
computed
9: Update Location Request
10: Update Location Ack
(subscription data)
11: Create Sesstion Request
12: Create Sesstion Request
13: IP address allocation
15: Create Sesstion Response 14: Create Sesstion Response
16: Attach Accept
+ keying
17: KeNB
received
18: Attach Accept
19: KeNB
computed
20: Attach Complete
21: First uplink packet
22: Modify Bearer
23: First downlink packet
http://msc-generator.sourceforge.net v3.4.18
57
handover
USIM / AuC
UE
source eNB
target eNB
MME
K
SGW PDN GW
CK, IK
User Data
UE / HSS
1: Measurement
report
KASME
UE / MME
2: Handover decision
KNASenc
3: Handover
Request
{NH, NCC}
KNASint
KeNB / NH
UE / eNB
4: Allocate TEID
6: handover
command
5: Handover
Request Ack
7: SN Status
Transfer
KUPint
User Data
•
buffer DL data
User Data
9: Path Switch
Request
User Data
•
10: Modify Bearer
Request
end marker
stop fw
stop fw
11: Modify Bearer
12: Path Switch
Response
Request Ack
13: UE Context
(new
{NH,
NCC}
pair)
Release
http://msc-generator.sourceforge.net v3.4.18
•
•
•
KRRCint
MME pre-calculates NH keys
–
–
8: Sync+RRC complete
KUPenc
From KASME and NCC
NCC: NH Chaining Counter
3: Source eNodeB sends
{NH, NCC} to target eNodeB
Target eNB uses NH for KeNB
UE also calculates new KeNB
12: MME sends next
{NH, NCC} to target eNB
KRRCenc
59
QoS architecture
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
59
Bearers
SGi
• A bearer is a L2 packet transmission
channel
–
–
–
–
HSS
PDN-GW
S5
…to a specific external Packet Data Network,
…using a specific IP address/prefix,
…carrying a specific set of IP flows (maybe all)
…providing a specific QoS.
SGW
MME
S11
S1-U
S1-CP
eNodeB
• In 2G/3G also known as “PDP Context”
• Bearer setup is explicitly signaled
UE
– In LTE one bearer is always set up at
attachment
See more in: 23.107
QoS concept and architecture
Cellular Networks and Mobile Computing
(COMS 6998-10)
Courtesy: Zoltán Turányi
60
Traffic to the same
external network
Bearers
IP microflows
A set of
IP microflows
Traffic with the
same IP address
A set of or IPv6 prefix
IP microflows
with the same QoS
Service Data Flow
Service Data Flow
External networks
PDN 1
PDN
connection
APN
traffic
Terminal
traffic
Service Data Flow dedicated
bearer
Service Data Flow
PDN 2
APN1 SGi
default
bearer
All traffic of a UE
SGi APN2
PDN GW PDN GW
Dedicated bearer: bearer with special QoS
Default bearer: rest of traffic with default QoS
SGW
MME
eNodeB
Two default bearers
to different APNs
UE
Courtesy: Zoltán Turányi
PDN – Packet Data Network
APN – Access Point Name 61
Why then no QoS today?
(Apart from voice)
• Terminal apps do not use QoS
– Original IP socket API has minimal QoS features
• No widespread QoS mechanism in fixed networks
• Usually IP app developers do not care about network QoS
– A number of QoS API failures
• Conceptual difficulties
– QoS must be authorized and charged
• QoS can only be effectively decided in the face of its price
– Complex QoS descriptors
• Determining QoS parameters is challenging
– E.g., 10-3 or 10-4 bit error rate?
– Yet not flexible enough to cater for e.g., VBR video
62
#1: Simple parameters
QCI
• QCI: QoS Class Indicator
– Scalar value encompassing
all packet treatment aspects
– 9 mandatory,
operators can define new
• MBR: Max bitrate
• GBR: Guaranteed bitrate
Resource
Type
1
(NOTE 3)
2
(NOTE 3)
3
(NOTE 3)
4
(NOTE 3)
5
(NOTE 3)
6
(NOTE 4)
7
(NOTE 3)
Priority
2
4
Packet
Delay
Budget
(NOTE 1)
100 ms
150 ms
Packet
Error Loss
Rate
(NOTE 2)
10
10
Example Services
-2
Conversational Voice
-3
Conversational Video (Live Streaming)
-3
Real Time Gaming
-6
Non-Conversational Video (Buffered Streaming)
-6
IMS Signalling
GBR
3
5
50 ms
300 ms
10
10
1
100 ms
10
6
300 ms
10
7
100 ms
10
300 ms
10
-6
Non-GBR
8
(NOTE 5)
9
(NOTE 6)
-3
8
9
-6
Video (Buffered Streaming)
TCP-based (e.g., www, e-mail, chat, ftp, p2p file
sharing, progressive video, etc.)
Voice,
Video (Live Streaming)
Interactive Gaming
Video (Buffered Streaming)
TCP-based (e.g., www, e-mail, chat, ftp, p2p file
sharing, progressive video, etc.)
– If nonzero, admission control is performed
• ARP: Allocation and Retention Priority
– priority (scalar): Governs priority at establishment and handover
– pre-emption capability (flag): can this bearer pre-empt another?
– pre-emption vulnerability (flag): can another bearer pre-empt this one?
• AMBR: Aggregated Maximum bitrate
– Both a per-terminal and per-APN value
Source: 23.401, 23.203
GPRS Enhancements for E-UTRAN
63
Policy and Charging Control Architecture
#2: Network initiated bearers
• Allow a network application request QoS
– Terminal app can remain QoS un-aware
– Network can fully control QoS provided & payment charged
No QoS API
1. Session setup
App
LTE
UE
3. Bearer
setup
App
LTE + EPC
2. Request QoS
Network
• First specified in Release 7 for 3G
– Not all terminals support it
• Mandatory mode in LTE
Courtesy: Zoltán Turányi
64
Policy and Charging
• Policy and Charging Rules
Function
– Decides on QoS and
Charging
– Controls gating
– Service Policy Based on
• Request
• Subscription data
– Makes no resource
decisions
App
•Flow descriptor (5-tuple)
•Bandwidth
•Application (voice/video/etc.)
Rx
SGi
PCRF
PDN GW
Gx
•Flow descriptor (5-tuple)
•QoS descriptor
•Charging rules
•Gating (on/off)
S5
SGW
MME
S11
S1-U
S1-MME
eNodeB
UE
Courtesy: Zoltán Turányi
65
What Is Next?
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
66
LTE Evolution
• LTE-A – meeting and exceeding IMT-Advanced
requirements
– Carrier aggregation
– Enhanced multi-antenna support
LTE-C
– Relaying
– Enhancements for heterogeneous deployments
Rel-14
Rel-13
LTE-B
Rel-12
LTE-A
Rel-11
LTE
Rel-10
Rel-9
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Rel-8
67
LTE Evolution
• LTE-B
– Work starting fall 2012
• Topics (speculative)
– Device-to-device communication
– Enhancements for machine-to-machine
communication
LTE-B
– Green networking: reduce energy use
LTE-A
– And more…
LTE
LTE-C
Rel-14
Rel-13
Rel-12
Rel-11
Rel-10
Rel-9
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
Rel-8
68
Outline
Goal of this lecture: understand the basics of
current networks and future directions
• Current Cellular Networks
• What Is Next?
• A Clean-Slate Design: Software-Defined Cellular
Networks
– Radio Access Networks
– Core Networks
– Wide Access Networks
• Conclusion and Future Work
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
69
A Clean-Slate Design:
Software-Defined Radio Access
Networks
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
70
Carrier’s Dilemma
Exponential Traffic Growth
8
Exabyte
11.2
12
Annual Growth 83%
10
6
Shannon
Shannon (3dB)
4
6
4.7
3
2.8
0.5 0.9
0.0 0.0 0.1 0.2
2
1.6
1
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
0
2007
4G
0
-15
-12.5
-10
-5
-2.5
0
2.5
5
7.5
10
12.5
15
17.5
20
4
•
7
5
7.4
8
2
Limited Capacity Gain
Poor wireless connectivity if left unaddressed
71
LTE Radio Access Networks
• Goal: high capacity wide-area wireless network
– Dense deployment of small cells
Base Station (BS)
Serving Gateway
Packet Data
Network Gateway
User Equipment (UE)
Serving Gateway
Internet
72
access
core
Dense and Chaotic Deployments
• Dense: high SNR per user leads to higher
capacity
o
Small cells, femto cells, repeaters, etc
73
Problems
•
Current LTE distributed control plane is ill-suited
o Hard to manage inter-cell interference
•
o Hard to optimize for variable load of cells
Dense deployment is costly
o Need to share cost among operators
o Maintain direct control of radio resources
o Lacking in current 3gpp RAN sharing standards
74
SoftRAN: Big Base Station Abstraction
Big Base Station
Radio Element 1
time
controller
frequency
Radio Element 2
time
time
Radio Element 3
frequency
time
frequency
75
Radio Resource Allocation
3D Resource Grid
time
Flows
76
SoftRAN: SDN Approach to RAN
Coordination :
X2 Interface
Control Algo
Control Algo
PHY & MAC
PHY & MAC
Control Algo
PHY & MAC
BS1
BS3
Control Algo
PHY & MAC
BS2
Control Algo
BS5
PHY & MAC
BS4
77
SoftRAN: SDN Approach to RAN
Control Algo
Operator Inputs
Network OS
RadioVisor
PHY & MAC
PHY & MAC
PHY & MAC
RE3
RE1
RE5
PHY & MAC
Radio Element
(RE)
RE2
PHY & MAC
RE4
78
SoftRAN Architecture Summary
CONTROLLER
RAN Information Base
Periodic Updates
Controller
API
•
•
•
RADIO ELEMENTS
Interference
Map
Bytes
Rate
Queue
Size
Flow
Records
Network
Operator
Inputs
QoS
Constraints
Radio
Element
API
Radio Element
3D Resource Grid
POWER
FLOW
Radio Resource
Management
Algorithm
Frequency
79
SoftRAN Architecture: Updates
• Radio element -> controller (updates)
– Flow information (downlink and uplink)
– Channel states (observed by clients)
• Network operator -> controller (inputs)
– QoS requirements
– Flow preferences
80
SoftRAN Architecture: Controller Design
• RAN information base (RIB)
– Update and maintain global network view
• Interference map
• Flow records
• Radio resource management
– Given global network view: maximize global utility
– Determine RRM at each radio element
81
SoftRAN Architecture: Radio Element API
• Controller -> radio element
– Handovers to be performed
– RF configuration per resource block
• Power allocation and flow allocation
– Relevant information about neighboring radio
elements
• Transmit Power being used
82
Refactoring Control Plane
• Controller responsibilities:
- Decisions influencing global network state
• Load balancing
• Interference management
• Radio element responsibilities:
- Decisions based on frequently varying local
network state
• Flow allocation based on channel states
83
SoftRAN Advantages
• Logically centralized control plane:
– Global view on interference and load
• Easier coordination of radio resource management
• Efficient use of wireless resources
– Plug-and-play control algorithms
• Simplified network management
– Smoother handovers
• Better user-experience
84
SoftRAN: Evolving the RAN
• Switching off radio elements based on load
– Energy savings
• Dynamically splitting the network into Big-BSs
– Handover radio elements between Big-BSs
85
Implementation: Modifications
• SoftRAN is incrementally deployable with
current infrastructure
– No modification needed on client-side
– API definitions at base station
• Femto API : Standardized interface between scheduler
and L1 (http://www.smallcellforum.org/resourcestechnical-papers)
• Minimal modifications to FemtoAPI required
86
RadioVisor Design
•
Slice manager
o
Traffic to
Slice
Mapping
3D Resource
Grid
Allocation &
Isolation
RadioVisor
•
Slice
Manager
•
Slice configuration, creation,
modification, deletion and multi-slice
operations
Traffic to slice mapping at RadioVisor
and radio elements
3D resource grid allocation and
isolation
o
Considers traffic demand, interference
graph and policy
87
Slice Manager
•
•
•
Slice definition
o Predicates on operator, device, subscriber, app
attributes
o
A slice can be all M2M traffic of operator 1
Slice configuration at data plane and control plane
o PHY and scheduler: narrow band PHY for M2M slice
o Interference management algorithm
Slice algebra to support flexible slice operations
o Slice merge, split, (un)nest, duplicate
88
•
•
Slices present resource
demands every time window
Max min fair allocation
Example
o Red slice entitles 2/3 and
demands 2/3 RE1 only
o Blue slice entitles 1/3 and
demand 1/3 RE2 and 1 RE3
Interference
Edge
Radio
Element 1
Radio
Radio
Element 2 Element 3
Frequency
•
Resource Grid Allocation and
Isolation
89
Conclusion
•
•
•
Dense deployment calls for central control of radio
resources
Deployment costs motivate RAN Sharing
We present the design of RadioVisor
o Enables direct control of per slice radio resources
o Configures per slice PHY and MAC, and
interference management algorithm
o Supports flexible slice definitions and operations
A Clean-Slate Design:
Software-Defined Cellular Core
Networks
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
91
Cellular Core Network Architecture
Base Station (BS)
Serving Gateway
Packet Data
Network Gateway
User Equipment (UE)
Serving Gateway
access
core
Internet
92
SoftCell Overview
Simple hardware
+ SoftCell software
Controller
Internet
93
SoftCell Design Goal
Fine-grained service policy for diverse app needs
»
»
Video transcoder, content filtering, firewall
M2M services: fleet tracking, low latency medical
device updates
with diverse needs!
94
Characteristics of Cellular Core
Networks
1. “North south” traffic pattern
2. Asymmetric edge
3. Traffic initiated from low-bandwidth access
edge
Gateway Edge
Internet
~1 million Users
~10 million flows
~400 Gbps – 2 Tbps
Access
Edge
~1K Users
~10K flows
~1 – 10 Gbps
95
Challenge: Scalability
Packet classification: decide which service policy
to be applied to a flow
» How to classify millions of flows per second?
Traffic steering: generate switch rules to implement
policy paths, e.g. traversing a sequence of
middleboxes
» How to implement million of paths?
• Limited switch flow tables: ~1K – 4K TCAM, ~16K – 64K
L2/Ethernet
Network dynamics: setup policy paths for new
users and new flow?
96
SoftCell: Design-in-the-Large
Controller
1. Scalable system design
»
»
Classifying flows at access
edge
Offloading controller tasks
to switch local agent
2. Intelligent algorithms
»
»
LA
LA
Gateway Edge
LA
Enforcing policy
LA
consistency under mobility
Multi-dimension
Access
Edge
aggregation to reduce
~1K Users
~10K flows
switch rule entries
~1 million
Users
~10 million
flows
~up to 2 Tbps
~1 – 10 Gbps
97
Multi-Dimensional Aggregation
Use multi-dimensional tags rather than flat tags
Policy Tag
BS ID
User ID
Aggregate
Aggregate
Aggregate
flows that
flows going
flows going
share a
to the same to the same
common
Users.
(group of)
policy (even
base
across Users
stations
Exploit
andlocality
BSs)in network topology and traffic pattern
Selectively match on one or multiple dimensions
» Supported by the multiple tables in today’s switch chipset
98
Conclusion and Future Work
• SoftCell uses commodity switches and middelboxes to build
flexible and cost-effective cellular core networks
• SoftCell cleanly separates fine-grained service policies from
traffic management policies
• SoftCell achieves scalability with
Data Plane
Control Plane
Asymmetric Edge Design
Multi-dimensional Aggregation
Hierarchical Controller Design
• Deploy SoftCell in real test bed
• Exploit multi-stage tables in modern switches
– Reduce m×n rules to m+n rules
99
A Clean-Slate Design:
Software-Defined WAN
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
100
Current Mobile WANs
• Organized into rigid and very large regions
• Minimal interactions among regions
• Centralized policy enforcement at PGWs
Two Regions
101
Mobile WANs Problems
• Suboptimal routing in large carriers
– Lack of sufficiently close PGW is a major cause of path inflation
• Lack of support for seamless inter-region mobility
– Users crossing regions experience service interruption
• Scalability and reliability
– The sheer amount of traffic and centralized policy enforcement
• Ill-suited to adapt to the rise of new applications
– E.g., machine-to-machine
– All users’ outgoing traffic traverses a PGW to the Internet, even for reaching
a user served by a close base station in a neighbor region
102
SoftMoW Motivation
Question: How to make the packet core scalable, simple, and flexible for tens of
thousands of base stations and millions of mobile users?
• Mobile networks should have fully connected core topology, small logical regions,
and more egress points
• Operators should leverage SDN to manage the whole network with a logicallycentralized controller:
– Directs traffic through efficient network paths that might cross region
boundaries
– Handles high amount of intra-region signaling load from mobile users
– Supports seamless inter-region mobility and optimizes its performance
– Performs network-wide application-based such as region optimization
103
SoftMoW Solution
• Hierarchically builds up a network-wide control plane
– Lies in the family of recursive SDN designs (e.g. XBAR, ONS’13)
• In each level, abstracts both control and data planes and exposes a set of
“dynamically-defined” logical components to the control plane of the level
above.
– Virtual Base stations (VBS), Gigantic Switches (GS), and Virtual Middleboxes
(VMB)
Union of
Coverage
Latency
Matrix
Sum of
capacities
VBS
GS
VMB
Core Net
Radio Net
Policy
104
SoftMoW Solution
• New Dynamic Feature: In each level, the control logic can
modify its logical components for optimization purposes
– E.g., merge/spilt and move operations
GSW2
GSW1
VBS1
GSW1
VBS1
VBS2
GSW1
GSW3
Merge/Split
GSW2
VBS2
VBS3
GSW2
Move and Split
VBS3
105
First Level-SoftMoW Architecture
• Replace inflexible and expensive hardware devices (i.e., PGW, SGW) with SDN
switches
• Perform distributed policy enforcement using middle-box instances
• Partition the network into independent and dynamic logical regions
• A child controller manages the data plane of each regions
Events GS Rules &
Actions
Bootstrapping
phase:
based on location
and processing
capabilities of child
controllers
Agent A
Local
Apps
Child A
NIB
E2
E3
Boundary
M
1
Region A
E1
M
M
M
2
4
BS1
M
3
Region B
I1
7
9
5
BS2
M
BS3
6
BS4
E4
M
M
8
M
10
BS5
M
BS6
106
Second Level-SoftMoW Architecture
• A parent runs a global link discovery protocol
– Inter-region links are not detected by BDDP and LLDP
• A parent participates in the inter-domain routing protocol
• A parent builds virtual middlebox chains and egress-point policies, and dictates
to GSs
Events GS Rules &
Actions
Agent A
I-Mobility
Manager
Local
Apps
Middlebox Egress
Optimizer Selection
Child A
NIB
E2
E3
Boundary
M 1
Region A
E1
M 3
M 2
M
4
BS1
6
Region B
I1
7
E4
M
8
M
GS
Protocol
E1
M
9
5
BS2
BS3
BS4
M
10
BS5
BS6
E2
E3
E4
-----
M M
M M
M
BGP
sessions
Parent
NIB
M
Region
Optimizer
2M M
Internal
VBS1
GSA
Border
VBS
1
I1
GSB
2M M
Border Internal
VBS
2 VBS2
107
Hierarchical Traffic Engineering
• A parent pushes a global label into each traffic group
• Child controllers perform label swapping
o Ingress point: pop the global label and push some local labels for intra-region paths
o Egress point: pop the local labels and push back the global label
Events GS Rules &
Actions
Push W
I-Mobility
Manager
Middlebox
Optimizer
Agent A
Egress
Selection
Region
Optimizer
Parent
NIB
GS
Protocol
E1
E2
E3
Latency
(P1,E2)=300
Latency
(P1,E4)=100
2M M
GSA
Internal
VBS1
Push W
Border
VBS
1
I1
E2
GSB
E3
Boundary
M 1
Region A
E1
E4
M M
M M
Child A
NIB
Pop W2
Push W
-----
Web
Voice
BGP
sessions
Local
Apps
Pop W1
M 2
Region B
I1
M 3
M
6
7
E4
M
8
M
2M M
GS
Rules
Border Internal
VBS
VBS2
2
M
4
BS1
Pop W
Push W1
M
5
BS2
Pop W
9
BS3
BS4
M
M
10
BS5
BS6
Push W2
108
Time-of-day Handover Optimization
Q: How can an operator reduce inter-region handovers in peak hours?
E1
GSA
M
GSA
M M
VBS1
VBS1
VBS2
Border
VBS2
Abstraction
update
coordination
Child A
Child B
E2
Parent
E3
E4
E3
Boundary
M
M 1
Region A
E1
E2
Internal
VBS2
VBS2
Handover
graph
E1
3M M
GSB
Border
VBS
1
Min Cut
300 Border 1000 Border 2000 Internal
Internal
E4
M 2M
E3
E2
M 2
Region B
I1
M 3
6
7
M
8
M
M M
M M
2M M
GSA
I1
GSB
2M M
GS Rule:
Move Border VBS1
M
4
M
BS2
BS1
Internal
VBS1
Border
VBS1
Border Internal
VBS2 VBS
2
New
Border
9
5
BS3
Old
Border
BS4
M
M
10
BS5
BS6
109
Conclusion
SoftMoW:
• Brings both simplicity and scalability to the
control plane of very large cellular networks
– decouples control and data planes at multiple levels
( focused only on two levels here)
• Makes the deployment and design of networkwide applications feasible
– E.g., seamless inter-region mobility, time-of-day
handover optimization, region optimization, and
traffic engineering
110
Summary
• Mobile computing depends on cellular
networks
• Cellular network performance still far from
meeting demands of mobile computing
• Cellular network architecture is evolving to
meet demands of mobile computing
– SDN and NFV
• AT&T’s domain 2.0
3/7/14
Cellular Networks and Mobile Computing
(COMS 6998-10)
111